特開 2022-185020 通信システム、セントラルユニット、およびユーザ装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022185020

(43)【公開日】2022-12-13

(54)【発明の名称】通信システム、セントラルユニット、およびユーザ装置

(51)【国際特許分類】

   H04W 76/15 20180101AFI20221206BHJP

   H04W 72/04 20090101ALI20221206BHJP

   H04W 16/28 20090101ALI20221206BHJP

   H04W 88/08 20090101ALI20221206BHJP

【ＦＩ】

H04W76/15

H04W72/04 111

H04W16/28

H04W88/08

【審査請求】有

【請求項の数】8

【出願形態】ＯＬ

(21)【出願番号】P 2022154353

(22)【出願日】2022-09-28

(62)【分割の表示】P 2018559625の分割

【原出願日】2017-12-28

(31)【優先権主張番号】P 2016255832

(32)【優先日】2016-12-28

(33)【優先権主張国・地域又は機関】JP

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

２．ＷＣＤＭＡ

(71)【出願人】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(74)【代理人】

【識別番号】100088672

【弁理士】

【氏名又は名称】吉竹 英俊

(74)【代理人】

【識別番号】100088845

【弁理士】

【氏名又は名称】有田 貴弘

(72)【発明者】

【氏名】下田 忠宏

(72)【発明者】

【氏名】望月 満

(57)【要約】

【課題】通信効率を高めることができる通信システムを提供する。
【解決手段】通信システムは、ユーザ装置２０２と、前記ユーザ装置２０２と無線通信するディストリビューテッドユニット（ＤＵ）８０２と、前記ＤＵ８０２に接続されるセントラルユニット（ＣＵ）８０３と、を備える。前記ＣＵ８０３は、前記ＤＵ８０２による前記ユーザ装置２０２との無線通信に用いられるＲＲＣパラメータを、前記ＤＵ８０２に送信する。
【選択図】図８

【特許請求の範囲】

【請求項1】

ユーザ装置と、
前記ユーザ装置と無線通信するディストリビューテッドユニット（ＤＵ）と、
前記ＤＵに接続されるセントラルユニット（ＣＵ）と、を備える通信システムであって、
前記ＣＵは、前記ＤＵによる前記ユーザ装置との無線通信に用いられるＲＲＣパラメータを、前記ＤＵに送信する
通信システム。

【請求項2】

前記ＲＲＣパラメータは、スケジューリングリクエスト（ＳＲ）の周期及びオフセットに関するパラメータである
請求項１に記載の通信システム。

【請求項3】

前記ＲＲＣパラメータは、Ａｃｋ／Ｎａｃｋレペティションに関するパラメータである
請求項１に記載の通信システム。

【請求項4】

前記ＲＲＣパラメータは、サウンディング参照信号（ＳＲＳ）に関するパラメータである
請求項１に記載の通信システム。

【請求項5】

前記ＲＲＣパラメータは、チャネル品質インジケータ（ＣＱＩ）／チャネル状態情報（ＣＳＩ）に関するパラメータである
請求項１に記載の通信システム。

【請求項6】

前記ＲＲＣパラメータは、無線リンク制御（ＲＬＣ）に関するパラメータである
請求項１に記載の通信システム。

【請求項7】

ユーザ装置と、
前記ユーザ装置と無線通信するディストリビューテッドユニット（ＤＵ）と、
前記ＤＵに接続されるセントラルユニット（ＣＵ）と、を備える通信システムにおける前記セントラルユニットであって、
前記ＤＵによる前記ユーザ装置との無線通信に用いられるＲＲＣパラメータを、前記ＤＵに送信する
セントラルユニット。

【請求項8】

ユーザ装置と、
前記ユーザ装置と無線通信するディストリビューテッドユニット（ＤＵ）と、
前記ＤＵに接続されるセントラルユニット（ＣＵ）と、を備える通信システムにおける前記ユーザ装置であって、
前記ＣＵから受信したＲＲＣパラメータを用いて無線通信を実行する前記ＤＵと無線通信する
ユーザ装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、通信システム、セントラルユニット、およびユーザ装置に関する。

【背景技術】

【0002】

移動体通信システムの規格化団体である３ＧＰＰ（3rd Generation Partnership Project）において、無線区間についてはロングタームエボリューション（Long Term Evolution：ＬＴＥ）と称し、コアネットワークおよび無線アクセスネットワーク（以下、まとめて、ネットワークとも称する）を含めたシステム全体構成については、システムアーキテクチャエボリューション（System Architecture Evolution：ＳＡＥ）と称される通信方式が検討されている（例えば、非特許文献１～５）。この通信方式は３．９Ｇ（3.9 Generation）システムとも呼ばれる。

【0003】

ＬＴＥのアクセス方式としては、下り方向はＯＦＤＭ（Orthogonal Frequency Division Multiplexing）、上り方向はＳＣ－ＦＤＭＡ（Single Carrier Frequency Division Multiple Access）が用いられる。また、ＬＴＥは、Ｗ－ＣＤＭＡ（Wideband Code Division Multiple Access）とは異なり、回線交換を含まず、パケット通信方式のみになる。

【0004】

非特許文献１（５章）に記載される、３ＧＰＰでの、ＬＴＥシステムにおけるフレーム構成に関する決定事項について、図１を用いて説明する。図１は、ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。図１において、１つの無線フレーム（Radio frame）は１０ｍｓである。無線フレームは１０個の等しい大きさのサブフレーム（Subframe）に分割される。サブフレームは、２個の等しい大きさのスロット（slot）に分割される。無線フレーム毎に１番目および６番目のサブフレームに下り同期信号（Downlink Synchronization Signal）が含まれる。同期信号には、第一同期信号（Primary Synchronization Signal：Ｐ－ＳＳ）と、第二同期信号（Secondary Synchronization Signal：Ｓ－ＳＳ）とがある。

【0005】

３ＧＰＰでの、ＬＴＥシステムにおけるチャネル構成に関する決定事項が、非特許文献１（５章）に記載されている。ＣＳＧ（Closed Subscriber Group）セルにおいてもｎｏｎ－ＣＳＧセルと同じチャネル構成が用いられると想定されている。

【0006】

物理報知チャネル（Physical Broadcast Channel：ＰＢＣＨ）は、基地局装置（以下、単に「基地局」という場合がある）から移動端末装置（以下、単に「移動端末」という場合がある）などの通信端末装置（以下、単に「通信端末」という場合がある）への下り送信用のチャネルである。ＢＣＨトランスポートブロック（transport block）は、４０ｍｓ間隔中の４個のサブフレームにマッピングされる。４０ｍｓタイミングの明白なシグナリングはない。

【0007】

物理制御フォーマットインジケータチャネル（Physical Control Format Indicator Channel：ＰＣＦＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＣＦＩＣＨは、ＰＤＣＣＨｓのために用いるＯＦＤＭ（Orthogonal Frequency Division Multiplexing）シンボルの数を、基地局から通信端末へ通知する。ＰＣＦＩＣＨは、サブフレーム毎に送信される。

【0008】

物理下り制御チャネル（Physical Downlink Control Channel：ＰＤＣＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＣＣＨは、後述のトランスポートチャネルの１つである下り共有チャネル（Downlink Shared Channel：ＤＬ－ＳＣＨ）のリソース割り当て（allocation）情報、後述のトランスポートチャネルの１つであるページングチャネル（Paging Channel：ＰＣＨ）のリソース割り当て（allocation）情報、ＤＬ－ＳＣＨに関するＨＡＲＱ（Hybrid Automatic Repeat reQuest）情報を通知する。ＰＤＣＣＨは、上りスケジューリンググラント（Uplink Scheduling Grant）を運ぶ。ＰＤＣＣＨは、上り送信に対する応答信号であるＡｃｋ（Acknowledgement）／Ｎａｃｋ（Negative Acknowledgement）を運ぶ。ＰＤＣＣＨは、Ｌ１／Ｌ２制御信号とも呼ばれる。

【0009】

物理下り共有チャネル（Physical Downlink Shared Channel：ＰＤＳＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＤＳＣＨには、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）、およびトランスポートチャネルであるＰＣＨがマッピングされている。

【0010】

物理マルチキャストチャネル（Physical Multicast Channel：ＰＭＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＭＣＨには、トランスポートチャネルであるマルチキャストチャネル（Multicast Channel：ＭＣＨ）がマッピングされている。

【0011】

物理上り制御チャネル（Physical Uplink Control Channel：ＰＵＣＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＣＣＨは、下り送信に対する応答信号（response signal）であるＡｃｋ／Ｎａｃｋを運ぶ。ＰＵＣＣＨは、ＣＱＩ（Channel Quality Indicator）レポートを運ぶ。ＣＱＩとは、受信したデータの品質、もしくは通信路品質を示す品質情報である。またＰＵＣＣＨは、スケジューリングリクエスト（Scheduling Request：ＳＲ）を運ぶ。

【0012】

物理上り共有チャネル（Physical Uplink Shared Channel：ＰＵＳＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＵＳＣＨには、トランスポートチャネルの１つである上り共有チャネル（Uplink Shared Channel：ＵＬ－ＳＣＨ）がマッピングされている。

【0013】

物理ＨＡＲＱインジケータチャネル（Physical Hybrid ARQ Indicator Channel：ＰＨＩＣＨ）は、基地局から通信端末への下り送信用のチャネルである。ＰＨＩＣＨは、上り送信に対する応答信号であるＡｃｋ／Ｎａｃｋを運ぶ。物理ランダムアクセスチャネル（Physical Random Access Channel：ＰＲＡＣＨ）は、通信端末から基地局への上り送信用のチャネルである。ＰＲＡＣＨは、ランダムアクセスプリアンブル（random access preamble）を運ぶ。

【0014】

下り参照信号（リファレンスシグナル（Reference Signal）：ＲＳ）は、ＬＴＥ方式の通信システムとして既知のシンボルである。以下の５種類の下りリファレンスシグナルが定義されている。セル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）、ＭＢＳＦＮ参照信号（MBSFN Reference Signal）、ＵＥ固有参照信号（UE-specific Reference Signal）であるデータ復調用参照信号（Demodulation Reference Signal：ＤＭ－ＲＳ）、位置決定参照信号（Positioning Reference Signal：ＰＲＳ）、チャネル状態情報参照信号（Channel State Information Reference Signal：ＣＳＩ－ＲＳ）。通信端末の物理レイヤの測定として、リファレンスシグナルの受信電力（Reference Signal Received Power：ＲＳＲＰ）測定がある。

【0015】

非特許文献１（５章）に記載されるトランスポートチャネル（Transport channel）について、説明する。下りトランスポートチャネルのうち、報知チャネル（Broadcast Channel：ＢＣＨ）は、その基地局（セル）のカバレッジ全体に報知される。ＢＣＨは、物理報知チャネル（ＰＢＣＨ）にマッピングされる。

【0016】

下り共有チャネル（Downlink Shared Channel：ＤＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＤＬ－ＳＣＨは、基地局（セル）のカバレッジ全体への報知が可能である。ＤＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。準静的なリソース割り当ては、パーシステントスケジューリング（Persistent Scheduling）ともいわれる。ＤＬ－ＳＣＨは、通信端末の低消費電力化のために通信端末の間欠受信（Discontinuous reception：ＤＲＸ）をサポートする。ＤＬ－ＳＣＨは、物理下り共有チャネル（ＰＤＳＣＨ）へマッピングされる。

【0017】

ページングチャネル（Paging Channel：ＰＣＨ）は、通信端末の低消費電力を可能とするために通信端末のＤＲＸをサポートする。ＰＣＨは、基地局（セル）のカバレッジ全体への報知が要求される。ＰＣＨは、動的にトラフィックに利用できる物理下り共有チャネル（ＰＤＳＣＨ）のような物理リソースへマッピングされる。

【0018】

マルチキャストチャネル（Multicast Channel：ＭＣＨ）は、基地局（セル）のカバレッジ全体への報知に使用される。ＭＣＨは、マルチセル送信におけるＭＢＭＳ（Multimedia Broadcast Multicast Service）サービス（ＭＴＣＨとＭＣＣＨ）のＳＦＮ合成をサポートする。ＭＣＨは、準静的なリソース割り当てをサポートする。ＭＣＨは、ＰＭＣＨへマッピングされる。

【0019】

上りトランスポートチャネルのうち、上り共有チャネル（Uplink Shared Channel：ＵＬ－ＳＣＨ）には、ＨＡＲＱ（Hybrid ARQ）による再送制御が適用される。ＵＬ－ＳＣＨは、ダイナミックあるいは準静的（Semi-static）なリソース割り当てをサポートする。ＵＬ－ＳＣＨは、物理上り共有チャネル（ＰＵＳＣＨ）へマッピングされる。

【0020】

ランダムアクセスチャネル（Random Access Channel：ＲＡＣＨ）は、制御情報に限られている。ＲＡＣＨは、衝突のリスクがある。ＲＡＣＨは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）へマッピングされる。

【0021】

ＨＡＲＱについて説明する。ＨＡＲＱとは、自動再送要求（Automatic Repeat reQuest：ＡＲＱ）と誤り訂正（Forward Error Correction）との組合せによって、伝送路の通信品質を向上させる技術である。ＨＡＲＱには、通信品質が変化する伝送路に対しても、再送によって誤り訂正が有効に機能するという利点がある。特に、再送にあたって初送の受信結果と再送の受信結果との合成をすることで、更なる品質向上を得ることも可能である。

【0022】

再送の方法の一例を説明する。受信側にて、受信データが正しくデコードできなかった場合、換言すればＣＲＣ（Cyclic Redundancy Check）エラーが発生した場合（ＣＲＣ＝ＮＧ）、受信側から送信側へ「Ｎａｃｋ」を送信する。「Ｎａｃｋ」を受信した送信側は、データを再送する。受信側にて、受信データが正しくデコードできた場合、換言すればＣＲＣエラーが発生しない場合（ＣＲＣ＝ＯＫ）、受信側から送信側へ「Ａｃｋ」を送信する。「Ａｃｋ」を受信した送信側は次のデータを送信する。

【0023】

非特許文献１（６章）に記載される論理チャネル（ロジカルチャネル：Logical channel）について、説明する。報知制御チャネル（Broadcast Control Channel：ＢＣＣＨ）は、報知システム制御情報のための下りチャネルである。論理チャネルであるＢＣＣＨは、トランスポートチャネルである報知チャネル（ＢＣＨ）、あるいは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。

【0024】

ページング制御チャネル（Paging Control Channel：ＰＣＣＨ）は、ページング情報（Paging Information）およびシステム情報（System Information）の変更を送信するための下りチャネルである。ＰＣＣＨは、通信端末のセルロケーションをネットワークが知らない場合に用いられる。論理チャネルであるＰＣＣＨは、トランスポートチャネルであるページングチャネル（ＰＣＨ）へマッピングされる。

【0025】

共有制御チャネル（Common Control Channel：ＣＣＣＨ）は、通信端末と基地局との間の送信制御情報のためのチャネルである。ＣＣＣＨは、通信端末がネットワークとの間でＲＲＣ接続（connection）を有していない場合に用いられる。下り方向では、ＣＣＣＨは、トランスポートチャネルである下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。上り方向では、ＣＣＣＨは、トランスポートチャネルである上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされる。

【0026】

マルチキャスト制御チャネル（Multicast Control Channel：ＭＣＣＨ）は、１対多の送信のための下りチャネルである。ＭＣＣＨは、ネットワークから通信端末への１つあるいはいくつかのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられる。ＭＣＣＨは、トランスポートチャネルであるマルチキャストチャネル（ＭＣＨ）へマッピングされる。

【0027】

個別制御チャネル（Dedicated Control Channel：ＤＣＣＨ）は、１対１にて、通信端末とネットワークとの間の個別制御情報を送信するチャネルである。ＤＣＣＨは、通信端末がＲＲＣ接続（connection）である場合に用いられる。ＤＣＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）にマッピングされる。

【0028】

個別トラフィックチャネル（Dedicated Traffic Channel：ＤＴＣＨ）は、ユーザ情報の送信のための個別通信端末への１対１通信のチャネルである。ＤＴＣＨは、上りおよび下りともに存在する。ＤＴＣＨは、上りでは上り共有チャネル（ＵＬ－ＳＣＨ）へマッピングされ、下りでは下り共有チャネル（ＤＬ－ＳＣＨ）へマッピングされる。

【0029】

マルチキャストトラフィックチャネル（Multicast Traffic channel：ＭＴＣＨ）は、ネットワークから通信端末へのトラフィックデータ送信のための下りチャネルである。ＭＴＣＨは、ＭＢＭＳ受信中の通信端末のみに用いられるチャネルである。ＭＴＣＨは、マルチキャストチャネル（ＭＣＨ）へマッピングされる。

【0030】

ＣＧＩとは、セルグローバル識別子（Cell Global Identifier）のことである。ＥＣＧＩとは、Ｅ－ＵＴＲＡＮセルグローバル識別子（E-UTRAN Cell Global Identifier）のことである。ＬＴＥ、後述のＬＴＥ－Ａ（Long Term Evolution Advanced）およびＵＭＴＳ（Universal Mobile Telecommunication System）において、ＣＳＧ（Closed Subscriber Group）セルが導入される。

【0031】

ＣＳＧ（Closed Subscriber Group）セルとは、利用可能な加入者をオペレータが特定しているセル（以下「特定加入者用セル」という場合がある）である。特定された加入者は、ＰＬＭＮ（Public Land Mobile Network）の１つ以上のセルにアクセスすることが許可される。特定された加入者がアクセスを許可されている１つ以上のセルを「ＣＳＧセル（ＣＳＧ ｃｅｌｌ（ｓ））」と呼ぶ。ただし、ＰＬＭＮにはアクセス制限がある。

【0032】

ＣＳＧセルは、固有のＣＳＧアイデンティティ（CSG identity：ＣＳＧ ＩＤ）を報知し、ＣＳＧインジケーション（CSG Indication）にて「ＴＲＵＥ」を報知するＰＬＭＮの一部である。予め利用登録し、許可された加入者グループのメンバーは、アクセス許可情報であるところのＣＳＧ ＩＤを用いてＣＳＧセルにアクセスする。

【0033】

ＣＳＧ ＩＤは、ＣＳＧセルまたはセルによって報知される。ＬＴＥ方式の通信システムにＣＳＧ ＩＤは複数存在する。そして、ＣＳＧ ＩＤは、ＣＳＧ関連のメンバーのアクセスを容易にするために、通信端末（ＵＥ）によって使用される。

【0034】

通信端末の位置追跡は、１つ以上のセルからなる区域を単位に行われる。位置追跡は、待受け状態であっても通信端末の位置を追跡し、通信端末を呼び出す、換言すれば通信端末が着呼することを可能にするために行われる。この通信端末の位置追跡のための区域をトラッキングエリアと呼ぶ。

【0035】

３ＧＰＰにおいて、Ｈｏｍｅ－ＮｏｄｅＢ（Ｈｏｍｅ－ＮＢ；ＨＮＢ）、Ｈｏｍｅ－ｅＮｏｄｅＢ（Ｈｏｍｅ－ｅＮＢ；ＨｅＮＢ）と称される基地局が検討されている。ＵＴＲＡＮにおけるＨＮＢ、およびＥ－ＵＴＲＡＮにおけるＨｅＮＢは、例えば家庭、法人、商業用のアクセスサービス向けの基地局である。非特許文献２には、ＨｅＮＢおよびＨＮＢへのアクセスの３つの異なるモードが開示されている。具体的には、オープンアクセスモード（Open access mode）と、クローズドアクセスモード（Closed access mode）と、ハイブリッドアクセスモード（Hybrid access mode）とが開示されている。

【0036】

また３ＧＰＰでは、リリース１０として、ロングタームエボリューションアドヴァンスド（Long Term Evolution Advanced：ＬＴＥ－Ａ）の規格策定が進められている（非特許文献３、非特許文献４参照）。ＬＴＥ－Ａは、ＬＴＥの無線区間通信方式を基本とし、それにいくつかの新技術を加えて構成される。

【0037】

ＬＴＥ－Ａシステムでは、１００ＭＨｚまでのより広い周波数帯域幅（transmission bandwidths）をサポートするために、二つ以上のコンポーネントキャリア（Component Carrier：ＣＣ）を集約する（「アグリゲーション（aggregation）する」とも称する）、キャリアアグリゲーション（Carrier Aggregation：ＣＡ）が検討されている。ＣＡについては、非特許文献１に記載されている。

【0038】

ＣＡが構成される場合、ＵＥはネットワーク（Network：ＮＷ）と唯一つのＲＲＣ接続（RRC connection）を有する。ＲＲＣ接続において、一つのサービングセルがＮＡＳモビリティ情報とセキュリティ入力を与える。このセルをプライマリセル（Primary Cell：ＰＣｅｌｌ）と呼ぶ。下りリンクで、ＰＣｅｌｌに対応するキャリアは、下りプライマリコンポーネントキャリア（Downlink Primary Component Carrier：ＤＬ ＰＣＣ）である。上りリンクで、ＰＣｅｌｌに対応するキャリアは、上りプライマリコンポーネントキャリア（Uplink Primary Component Carrier：ＵＬ ＰＣＣ）である。

【0039】

ＵＥの能力（ケーパビリティ（capability））に応じて、セカンダリセル（Secondary Cell：ＳＣｅｌｌ）が、ＰＣｅｌｌとともに、サービングセルの組を形成するために構成される。下りリンクで、ＳＣｅｌｌに対応するキャリアは、下りセカンダリコンポーネントキャリア（Downlink Secondary Component Carrier：ＤＬ ＳＣＣ）である。上りリンクで、ＳＣｅｌｌに対応するキャリアは、上りセカンダリコンポーネントキャリア（Uplink Secondary Component Carrier：ＵＬ ＳＣＣ）である。

【0040】

一つのＰＣｅｌｌと一つ以上のＳＣｅｌｌとからなるサービングセルの組が、一つのＵＥに対して構成される。

【0041】

また、ＬＴＥ－Ａでの新技術としては、より広い帯域をサポートする技術（Wider bandwidth extension）、および多地点協調送受信（Coordinated Multiple Point transmission and reception：ＣｏＭＰ）技術などがある。３ＧＰＰでＬＴＥ－Ａのために検討されているＣｏＭＰについては、非特許文献１に記載されている。

【0042】

また、３ＧＰＰにおいて、将来の膨大なトラフィックに対応するために、スモールセルを構成するスモールｅＮＢ（以下「小規模基地局装置」という場合がある）を用いることが検討されている。例えば、多数のスモールｅＮＢを設置して、多数のスモールセルを構成することによって、周波数利用効率を高めて、通信容量の増大を図る技術などが検討されている。具体的には、ＵＥが２つのｅＮＢと接続して通信を行うデュアルコネクティビティ（Dual Connectivity；略称：ＤＣ）などがある。ＤＣについては、非特許文献１に記載されている。

【0043】

デュアルコネクティビティ（ＤＣ）を行うｅＮＢのうち、一方を「マスターｅＮＢ（略称：ＭｅＮＢ）」といい、他方を「セカンダリｅＮＢ（略称：ＳｅＮＢ）」という場合がある。

【0044】

モバイルネットワークのトラフィック量は、増加傾向にあり、通信速度も高速化が進んでいる。ＬＴＥおよびＬＴＥ－Ａが本格的に運用を開始されると、更に通信速度が高速化されることが見込まれる。

【0045】

さらに、高度化する移動体通信に対して、２０２０年以降にサービスを開始することを目標とした第５世代（以下「５Ｇ」という場合がある）無線アクセスシステムが検討されている。例えば、欧州では、ＭＥＴＩＳという団体で５Ｇの要求事項がまとめられている（非特許文献５参照）。

【0046】

５Ｇ無線アクセスシステムでは、ＬＴＥシステムに対して、システム容量は１０００倍、データの伝送速度は１００倍、データの処理遅延は１０分の１（１／１０）、通信端末の同時接続数は１００倍として、更なる低消費電力化、および装置の低コスト化を実現することが要件として挙げられている。

【0047】

このような要求を満たすために、３ＧＰＰでは、リリース１４として、５Ｇの規格検討が進められている（非特許文献６～１０参照）。５Ｇの無線区間の技術は、「New Radio（略称：ＮＲ） Access Technology」と称され、いくつかの新たな技術が検討されている（非特許文献１１～１４参照）。例えば、ＲＲＣを伴わないモビリティ、アナログビームフォーミングやハイブリッドビームフォーミングによるマルチビームフォーミング（ＭＢＦ）、ネットワークスライシングなどが検討されている。

【先行技術文献】

【非特許文献】

【0048】

【非特許文献1】３ＧＰＰ ＴＳ ３６．３００ Ｖ１４．０．０

【非特許文献2】３ＧＰＰ Ｓ１－０８３４６１

【非特許文献3】３ＧＰＰ ＴＲ ３６．８１４ Ｖ９．０．０

【非特許文献4】３ＧＰＰ ＴＲ ３６．９１２ Ｖ１３．０．０

【非特許文献5】“Scenarios, requirements and KPIs for 5G mobile and wireless system”、［online］、平成２５（２０１３）年４月３０日、ＩＣＴ－３１７６６９－ＭＥＴＩＳ／Ｄ１．１、［平成２８年１２月８日検索］、インターネット<https://www.metis2020.com/documents/deliverables/>

【非特許文献6】３ＧＰＰ ＴＲ ２３．７９９ Ｖ１．１．０

【非特許文献7】３ＧＰＰ ＴＲ ３８．８０１ Ｖ０．４．０

【非特許文献8】３ＧＰＰ ＴＲ ３８．８０２ Ｖ１．０．０

【非特許文献9】３ＧＰＰ ＴＲ ３８．８０４ Ｖ０．４．０

【非特許文献10】３ＧＰＰ ＴＲ ３８．９１２ Ｖ０．０．２

【非特許文献11】３ＧＰＰ Ｒ２－１６４６７０

【非特許文献12】３ＧＰＰ ＴＳ ３６．３３１ Ｖ１４．０．０

【非特許文献13】３ＧＰＰ Ｒ１－１６５３６４

【非特許文献14】３ＧＰＰ Ｒ２－１６５５４２

【発明の概要】

【発明が解決しようとする課題】

【0049】

ＮＲでは、ＲＲＣを伴わないモビリティが検討されている。ＬＴＥに比べて高い周波数を用いるＮＲでは、ビームを形成して狭い範囲に電力を集中させ、１つまたは複数のビームを用いることによって、必要なカバレッジをカバーする。ＵＥの移動にともなってビームの移動が頻繁に発生するので、ＲＲＣを伴わないモビリティによって、ビーム間移動に伴うシグナリングを少なくする。

【0050】

ＮＲにおける、複数のビーム、あるいは複数のＴＲＰ（Transmission/Reception Point）を用いた通信においては、各ビーム、あるいは各ＴＲＰによって、通信可能な空間が分離されている。このような場合についてＲＲＣのパラメータをどのように扱うかは、開示されていない。そのため、通信可能な空間がセル内で分離されても、セル内に収容可能なＵＥ数を増加させることができない。

【0051】

また、通信用の無線リソースとして複数のキャリアを集めて使用するキャリアアグリゲーション（ＣＡ）をＮＲに適用する場合、セルのどのビームをアグリゲーションしたらよいかが不明となってしまうので、ｇＮＢはＵＥに対してＣＡを設定できない。そのため、多くの無線リソースを使用できなくなり、ＵＥに対して、高速、大容量の通信サービスを提供できなくなってしまう。

【0052】

また、ＬＴＥにおいて、高速および大容量の通信サービスを提供するための技術として用いられているＤＣ（Dual Connectivity）では、マスター基地局（Master eNB：ＭｅＮＢ）からセカンダリ基地局（Secondary eNB：ＳｅＮＢ）のベアラ設定を要求していた。このベアラ設定要求には、Ｅ－ＲＡＢパラメータを用いていた。ところが、５Ｇにおいては、ネットワークスライシングを用いるので、ＣＮ－ＲＡＮ間ではフローベース制御を用い、ＲＡＮではベアラベース制御を用いることが議論されている。このことにより、Ｅ－ＲＡＢがなくなるので、ＭｇＮＢ（Master gNB）からＳｇＮＢ（Secondary gNB）へのベアラ設定要求方法が不明となってしまう。したがって、５Ｇにおいては、ＤＣを使用できず、無線リソースの使用効率を大きく減少させる。

【0053】

本開示の一の目的は、ＮＲにおいて、ＵＥの収容数を増加させるとともに、ＵＥにおいて高速および大容量の通信を可能とする通信システムを提供することである。

【課題を解決するための手段】

【0054】

本開示に係る通信システムは、ユーザ装置と、ディストリビューテッドユニット（ＤＵ）と、セントラルユニット（ＣＵ）と、を備える。

【0055】

前記ＤＵは前記ユーザ装置と無線通信する。前記ＣＵは前記ＤＵに接続される。

【0056】

前記ＣＵは、前記ＤＵによる前記ユーザ装置との無線通信に用いられるＲＲＣパラメータを、前記ＤＵに送信する。

【0057】

本開示に係るセントラルユニット（ＣＵ）は、ユーザ装置と、前記ユーザ装置と無線通信するディストリビューテッドユニット（ＤＵ）と、前記ＤＵに接続される前記ＣＵと、を備える通信システムにおける前記ＣＵである。

【0058】

前記ＣＵは、前記ＤＵによる前記ユーザ装置との無線通信に用いられるＲＲＣパラメータを、前記ＤＵに送信する。

【0059】

本開示に係るユーザ装置は、前記ユーザ装置と、前記ユーザ装置と無線通信するディストリビューテッドユニット（ＤＵ）と、前記ＤＵに接続されるセントラルユニット（ＣＵ）と、を備える通信システムにおける前記ユーザ装置である。

【0060】

前記ユーザ装置は、前記ＣＵから受信したＲＲＣパラメータを用いて無線通信を実行する前記ＤＵと無線通信する。

【発明の効果】

【0061】

本開示に係る通信システムによれば、通信効率を高めることができる。

【0062】

本開示に係るセントラルユニットによれば、高い通信効率を有する通信システムを構成することができる。

【0063】

本開示に係るユーザ装置によれば、高い通信効率を有する通信システムを構成することができる。

【0064】

本発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。

【図面の簡単な説明】

【0065】

【図1】ＬＴＥ方式の通信システムで使用される無線フレームの構成を示す説明図である。

【図2】３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。

【図3】本発明に係る通信端末である図２に示す移動端末２０２の構成を示すブロック図である。

【図4】本発明に係る基地局である図２に示す基地局２０３の構成を示すブロック図である。

【図5】本発明に係るＭＭＥの構成を示すブロック図である。

【図6】ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。

【図7】マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。

【図8】実施の形態１について、複数のビームあるいはＴＲＰによる通信可能な空間の分離を示す図である。

【図9】実施の形態２について、ビーム／ＴＲＰ切り替えをＭＡＣシグナリングを用いて行う場合のシーケンス図である。

【図10】実施の形態３について、ビーム／ＴＲＰ切り替えをＭＡＣシグナリングを用いて行う場合のシーケンス図である。

【図11】実施の形態４について、ビーム／ＴＲＰ切り替えをＭＡＣシグナリングを用いて行う場合のシーケンス図である。

【図12】実施の形態６について、ｇＮＢにおいてビーム単位で設定するＣＡのアーキテクチャを説明する図である。

【図13】実施の形態６について、ＲＲＣシグナリングを用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図14】実施の形態６について、ＲＲＣシグナリングを用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図15】実施の形態６の変形例１について、ビームのａｃｔ／ｄｅａｃｔ情報のＭＡＣ ＣＥの一例を示す図である。

【図16】実施の形態６の変形例１について、ＭＡＣシグナリングを用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図17】実施の形態６の変形例１について、ＭＡＣシグナリングを用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図18】実施の形態６の変形例２について、Ｌ１／Ｌ２制御信号を用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図19】実施の形態６の変形例２について、Ｌ１／Ｌ２制御信号を用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図20】実施の形態６の変形例２について、Ｌ１／Ｌ２制御信号を用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。

【図21】実施の形態７について、ＤＣ（ＳＣＧベアラ）設定方法を説明する図である。

【図22】実施の形態７について、ＤＣ（スプリットベアラ）設定方法を説明する図である。

【図23】実施の形態７について、ＤＣ（ＳＣＧベアラ）設定シーケンスの一例を示す図である。

【図24】実施の形態７について、ＤＣ（ＳＣＧベアラ）設定シーケンスの一例を示す図である。

【図25】実施の形態７の変形例１について、ＰＤＵセッション毎のＤＣ（ＳＣＧベアラ）設定方法を説明する図である。

【図26】実施の形態７の変形例１について、ＰＤＵセッション毎のＤＣ（ＳＣＧベアラ）設定方法を説明する図である。

【図27】実施の形態７の変形例１について、ＤＣ（スプリットベアラ）設定方法を説明する図である。

【図28】実施の形態７の変形例１について、他のＤＣ（スプリットベアラ）設定方法を説明する図である。

【図29】実施の形態７の変形例１について、他のＤＣ（スプリットベアラ）設定方法を説明する図である。

【図30】実施の形態７の変形例２について、ＰＤＵセッション毎のＤＣ（ＳＣＧベアラ）設定方法を説明する図である。

【図31】実施の形態７の変形例２について、ＰＤＵセッション毎のＤＣ（スプリットベアラ）設定方法を説明する図である。

【発明を実施するための形態】

【0066】

実施の形態１．
図２は、３ＧＰＰにおいて議論されているＬＴＥ方式の通信システム２００の全体的な構成を示すブロック図である。図２について説明する。無線アクセスネットワークは、Ｅ－ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）２０１と称される。通信端末装置である移動端末装置（以下「移動端末（User Equipment：ＵＥ）」という）２０２は、基地局装置（以下「基地局（E-UTRAN NodeB：ｅＮＢ）」という）２０３と無線通信可能であり、無線通信で信号の送受信を行う。

【0067】

ここで、「通信端末装置」とは、移動可能な携帯電話端末装置などの移動端末装置だけでなく、センサなどの移動しないデバイスも含んでいる。以下の説明では、「通信端末装置」を、単に「通信端末」という場合がある。

【0068】

移動端末２０２に対する制御プロトコル、例えばＲＲＣ（Radio Resource Control）と、ユーザプレイン、例えばＰＤＣＰ（Packet Data Convergence Protocol）、ＲＬＣ（Radio Link Control）、ＭＡＣ（Medium Access Control）、ＰＨＹ（Physical layer）とが基地局２０３で終端するならば、Ｅ－ＵＴＲＡＮは１つあるいは複数の基地局２０３によって構成される。

【0069】

移動端末２０２と基地局２０３との間の制御プロトコルＲＲＣ（Radio Resource Control）は、報知（Broadcast）、ページング（paging）、ＲＲＣ接続マネージメント（RRC connection management）などを行う。ＲＲＣにおける基地局２０３と移動端末２０２との状態として、ＲＲＣ＿ＩＤＬＥと、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤとがある。

【0070】

ＲＲＣ＿ＩＤＬＥでは、ＰＬＭＮ（Public Land Mobile Network）選択、システム情報（System Information：ＳＩ）の報知、ページング（paging）、セル再選択（cell re-selection）、モビリティなどが行われる。ＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、移動端末はＲＲＣ接続（connection）を有し、ネットワークとのデータの送受信を行うことができる。またＲＲＣ＿ＣＯＮＮＥＣＴＥＤでは、ハンドオーバ（Handover：ＨＯ）、隣接セル（Neighbour cell）の測定（メジャメント（measurement））などが行われる。

【0071】

基地局２０３は、ｅＮＢ２０７と、Ｈｏｍｅ－ｅＮＢ２０６とに分類される。通信システム２００は、複数のｅＮＢ２０７を含むｅＮＢ群２０３－１と、複数のＨｏｍｅ－ｅＮＢ２０６を含むＨｏｍｅ－ｅＮＢ群２０３－２とを備える。またコアネットワークであるＥＰＣ（Evolved Packet Core）と、無線アクセスネットワークであるＥ－ＵＴＲＡＮ２０１とで構成されるシステムは、ＥＰＳ（Evolved Packet System）と称される。コアネットワークであるＥＰＣと、無線アクセスネットワークであるＥ－ＵＴＲＡＮ２０１とを合わせて、「ネットワーク」という場合がある。

【0072】

ｅＮＢ２０７は、移動管理エンティティ（Mobility Management Entity：ＭＭＥ）、あるいはＳ－ＧＷ（Serving Gateway）、あるいはＭＭＥおよびＳ－ＧＷを含むＭＭＥ／Ｓ－ＧＷ部（以下「ＭＭＥ部」という場合がある）２０４とＳ１インタフェースにより接続され、ｅＮＢ２０７とＭＭＥ部２０４との間で制御情報が通信される。一つのｅＮＢ２０７に対して、複数のＭＭＥ部２０４が接続されてもよい。ｅＮＢ２０７間は、Ｘ２インタフェースにより接続され、ｅＮＢ２０７間で制御情報が通信される。

【0073】

Ｈｏｍｅ－ｅＮＢ２０６は、ＭＭＥ部２０４とＳ１インタフェースにより接続され、Ｈｏｍｅ－ｅＮＢ２０６とＭＭＥ部２０４との間で制御情報が通信される。一つのＭＭＥ部２０４に対して、複数のＨｏｍｅ－ｅＮＢ２０６が接続される。あるいは、Ｈｏｍｅ－ｅＮＢ２０６は、ＨｅＮＢＧＷ（Home-eNB GateWay）２０５を介してＭＭＥ部２０４と接続される。Ｈｏｍｅ－ｅＮＢ２０６とＨｅＮＢＧＷ２０５とは、Ｓ１インタフェースにより接続され、ＨｅＮＢＧＷ２０５とＭＭＥ部２０４とはＳ１インタフェースを介して接続される。

【0074】

一つまたは複数のＨｏｍｅ－ｅＮＢ２０６が一つのＨｅＮＢＧＷ２０５と接続され、Ｓ１インタフェースを通して情報が通信される。ＨｅＮＢＧＷ２０５は、一つまたは複数のＭＭＥ部２０４と接続され、Ｓ１インタフェースを通して情報が通信される。

【0075】

ＭＭＥ部２０４およびＨｅＮＢＧＷ２０５は、上位装置、具体的には上位ノードであり、基地局であるｅＮＢ２０７およびＨｏｍｅ－ｅＮＢ２０６と、移動端末（ＵＥ）２０２との接続を制御する。ＭＭＥ部２０４は、コアネットワークであるＥＰＣを構成する。基地局２０３およびＨｅＮＢＧＷ２０５は、Ｅ－ＵＴＲＡＮ２０１を構成する。

【0076】

さらに３ＧＰＰでは、以下のような構成が検討されている。Ｈｏｍｅ－ｅＮＢ２０６間のＸ２インタフェースはサポートされる。すなわち、Ｈｏｍｅ－ｅＮＢ２０６間は、Ｘ２インタフェースにより接続され、Ｈｏｍｅ－ｅＮＢ２０６間で制御情報が通信される。ＭＭＥ部２０４からは、ＨｅＮＢＧＷ２０５はＨｏｍｅ－ｅＮＢ２０６として見える。Ｈｏｍｅ－ｅＮＢ２０６からは、ＨｅＮＢＧＷ２０５はＭＭＥ部２０４として見える。

【0077】

Ｈｏｍｅ－ｅＮＢ２０６が、ＨｅＮＢＧＷ２０５を介してＭＭＥ部２０４に接続される場合および直接ＭＭＥ部２０４に接続される場合のいずれの場合も、Ｈｏｍｅ－ｅＮＢ２０６とＭＭＥ部２０４との間のインタフェースは、Ｓ１インタフェースで同じである。

【0078】

基地局２０３は、１つのセルを構成してもよいし、複数のセルを構成してもよい。各セルは、移動端末２０２と通信可能な範囲であるカバレッジとして予め定める範囲を有し、カバレッジ内で移動端末２０２と無線通信を行う。１つの基地局２０３が複数のセルを構成する場合、１つ１つのセルが、移動端末２０２と通信可能に構成される。

【0079】

図３は、本発明に係る通信端末である図２に示す移動端末２０２の構成を示すブロック図である。図３に示す移動端末２０２の送信処理を説明する。まず、プロトコル処理部３０１からの制御データ、およびアプリケーション部３０２からのユーザデータが、送信データバッファ部３０３へ保存される。送信データバッファ部３０３に保存されたデータは、エンコーダー部３０４へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部３０３から変調部３０５へ直接出力されるデータが存在してもよい。エンコーダー部３０４でエンコード処理されたデータは、変調部３０５にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部３０６へ出力され、無線送信周波数に変換される。その後、アンテナ３０７から基地局２０３に送信信号が送信される。

【0080】

また、移動端末２０２の受信処理は、以下のように実行される。基地局２０３からの無線信号がアンテナ３０７により受信される。受信信号は、周波数変換部３０６にて無線受信周波数からベースバンド信号に変換され、復調部３０８において復調処理が行われる。復調後のデータは、デコーダー部３０９へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部３０１へ渡され、ユーザデータはアプリケーション部３０２へ渡される。移動端末２０２の一連の処理は、制御部３１０によって制御される。よって制御部３１０は、図３では省略しているが、各部３０１～３０９と接続している。

【0081】

図４は、本発明に係る基地局である図２に示す基地局２０３の構成を示すブロック図である。図４に示す基地局２０３の送信処理を説明する。ＥＰＣ通信部４０１は、基地局２０３とＥＰＣ（ＭＭＥ部２０４など）、ＨｅＮＢＧＷ２０５などとの間のデータの送受信を行う。他基地局通信部４０２は、他の基地局との間のデータの送受信を行う。ＥＰＣ通信部４０１および他基地局通信部４０２は、それぞれプロトコル処理部４０３と情報の受け渡しを行う。プロトコル処理部４０３からの制御データ、ならびにＥＰＣ通信部４０１および他基地局通信部４０２からのユーザデータおよび制御データは、送信データバッファ部４０４へ保存される。

【0082】

送信データバッファ部４０４に保存されたデータは、エンコーダー部４０５へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部４０４から変調部４０６へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部４０６にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部４０７へ出力され、無線送信周波数に変換される。その後、アンテナ４０８より一つもしくは複数の移動端末２０２に対して送信信号が送信される。

【0083】

また、基地局２０３の受信処理は以下のように実行される。一つもしくは複数の移動端末２０２からの無線信号が、アンテナ４０８により受信される。受信信号は、周波数変換部４０７にて無線受信周波数からベースバンド信号に変換され、復調部４０９で復調処理が行われる。復調されたデータは、デコーダー部４１０へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部４０３あるいはＥＰＣ通信部４０１、他基地局通信部４０２へ渡され、ユーザデータはＥＰＣ通信部４０１および他基地局通信部４０２へ渡される。基地局２０３の一連の処理は、制御部４１１によって制御される。よって制御部４１１は、図４では省略しているが、各部４０１～４１０と接続している。

【0084】

図５は、本発明に係るＭＭＥの構成を示すブロック図である。図５では、前述の図２に示すＭＭＥ部２０４に含まれるＭＭＥ２０４ａの構成を示す。ＰＤＮ ＧＷ通信部５０１は、ＭＭＥ２０４ａとＰＤＮ ＧＷとの間のデータの送受信を行う。基地局通信部５０２は、ＭＭＥ２０４ａと基地局２０３との間のＳ１インタフェースによるデータの送受信を行う。ＰＤＮ ＧＷから受信したデータがユーザデータであった場合、ユーザデータは、ＰＤＮ ＧＷ通信部５０１から、ユーザプレイン通信部５０３経由で基地局通信部５０２に渡され、１つあるいは複数の基地局２０３へ送信される。基地局２０３から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部５０２から、ユーザプレイン通信部５０３経由でＰＤＮ ＧＷ通信部５０１に渡され、ＰＤＮ ＧＷへ送信される。

【0085】

ＰＤＮ ＧＷから受信したデータが制御データであった場合、制御データは、ＰＤＮ ＧＷ通信部５０１から制御プレイン制御部５０５へ渡される。基地局２０３から受信したデータが制御データであった場合、制御データは、基地局通信部５０２から制御プレイン制御部５０５へ渡される。

【0086】

ＨｅＮＢＧＷ通信部５０４は、ＨｅＮＢＧＷ２０５が存在する場合に設けられ、情報種別によって、ＭＭＥ２０４ａとＨｅＮＢＧＷ２０５との間のインタフェース（ＩＦ）によるデータの送受信を行う。ＨｅＮＢＧＷ通信部５０４から受信した制御データは、ＨｅＮＢＧＷ通信部５０４から制御プレイン制御部５０５へ渡される。制御プレイン制御部５０５での処理の結果は、ＰＤＮ ＧＷ通信部５０１経由でＰＤＮ ＧＷへ送信される。また、制御プレイン制御部５０５で処理された結果は、基地局通信部５０２経由でＳ１インタフェースにより１つあるいは複数の基地局２０３へ送信され、またＨｅＮＢＧＷ通信部５０４経由で１つあるいは複数のＨｅＮＢＧＷ２０５へ送信される。

【0087】

制御プレイン制御部５０５には、ＮＡＳセキュリティ部５０５－１、ＳＡＥベアラコントロール部５０５－２、アイドルステート（Idle State）モビリティ管理部５０５－３などが含まれ、制御プレインに対する処理全般を行う。ＮＡＳセキュリティ部５０５－１は、ＮＡＳ（Non-Access Stratum）メッセージのセキュリティなどを行う。ＳＡＥベアラコントロール部５０５－２は、ＳＡＥ（System Architecture Evolution）のベアラの管理などを行う。アイドルステートモビリティ管理部５０５－３は、待受け状態（アイドルステート（Idle State）；ＬＴＥ－ＩＤＬＥ状態、または、単にアイドルとも称される）のモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の１つあるいは複数の移動端末２０２のトラッキングエリアの追加、削除、更新、検索、トラッキングエリアリスト管理などを行う。

【0088】

ＭＭＥ２０４ａは、１つまたは複数の基地局２０３に対して、ページング信号の分配を行う。また、ＭＭＥ２０４ａは、待受け状態（Idle State）のモビリティ制御（Mobility control）を行う。ＭＭＥ２０４ａは、移動端末が待ち受け状態のとき、および、アクティブ状態（Active State）のときに、トラッキングエリア（Tracking Area）リストの管理を行う。ＭＭＥ２０４ａは、ＵＥが登録されている（registered）追跡領域（トラッキングエリア：Tracking Area）に属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。ＭＭＥ２０４ａに接続されるＨｏｍｅ－ｅＮＢ２０６のＣＳＧの管理、ＣＳＧ ＩＤの管理、およびホワイトリストの管理は、アイドルステートモビリティ管理部５０５－３で行われてもよい。

【0089】

次に通信システムにおけるセルサーチ方法の一例を示す。図６は、ＬＴＥ方式の通信システムにおいて通信端末（ＵＥ）が行うセルサーチから待ち受け動作までの概略を示すフローチャートである。通信端末は、セルサーチを開始すると、ステップＳＴ６０１で、周辺の基地局から送信される第一同期信号（Ｐ－ＳＳ）、および第二同期信号（Ｓ－ＳＳ）を用いて、スロットタイミング、フレームタイミングの同期をとる。

【0090】

Ｐ－ＳＳとＳ－ＳＳとを合わせて、同期信号（Synchronization Signal：ＳＳ）という。同期信号（ＳＳ）には、セル毎に割り当てられたＰＣＩに１対１に対応するシンクロナイゼーションコードが割り当てられている。ＰＣＩの数は５０４通りが検討されている。この５０４通りのＰＣＩを用いて同期をとるとともに、同期がとれたセルのＰＣＩを検出（特定）する。

【0091】

次に同期がとれたセルに対して、ステップＳＴ６０２で、基地局からセル毎に送信される参照信号（リファレンスシグナル：ＲＳ）であるセル固有参照信号（Cell-specific Reference Signal：ＣＲＳ）を検出し、ＲＳの受信電力（Reference Signal Received Power：ＲＳＲＰ）の測定を行う。参照信号（ＲＳ）には、ＰＣＩと１対１に対応したコードが用いられている。そのコードで相関をとることによって他セルと分離できる。ステップＳＴ６０１で特定したＰＣＩから、該セルのＲＳ用のコードを導出することによって、ＲＳを検出し、ＲＳの受信電力を測定することが可能となる。

【0092】

次にステップＳＴ６０３で、ステップＳＴ６０２までで検出された一つ以上のセルの中から、ＲＳの受信品質が最もよいセル、例えば、ＲＳの受信電力が最も高いセル、つまりベストセルを選択する。

【0093】

次にステップＳＴ６０４で、ベストセルのＰＢＣＨを受信して、報知情報であるＢＣＣＨを得る。ＰＢＣＨ上のＢＣＣＨには、セル構成情報が含まれるＭＩＢ（Master Information Block）がマッピングされる。したがって、ＰＢＣＨを受信してＢＣＣＨを得ることで、ＭＩＢが得られる。ＭＩＢの情報としては、例えば、ＤＬ（ダウンリンク）システム帯域幅（送信帯域幅設定（transmission bandwidth configuration：dl-bandwidth）とも呼ばれる）、送信アンテナ数、ＳＦＮ（System Frame Number）などがある。

【0094】

次にステップＳＴ６０５で、ＭＩＢのセル構成情報をもとに該セルのＤＬ－ＳＣＨを受信して、報知情報ＢＣＣＨの中のＳＩＢ（System Information Block）１を得る。ＳＩＢ１には、該セルへのアクセスに関する情報、セルセレクションに関する情報、他のＳＩＢ（ＳＩＢｋ；ｋ≧２の整数）のスケジューリング情報が含まれる。また、ＳＩＢ１には、トラッキングエリアコード（Tracking Area Code：ＴＡＣ）が含まれる。

【0095】

次にステップＳＴ６０６で、通信端末は、ステップＳＴ６０５で受信したＳＩＢ１のＴＡＣと、通信端末が既に保有しているトラッキングエリアリスト内のトラッキングエリア識別子（Tracking Area Identity：ＴＡＩ）のＴＡＣ部分とを比較する。トラッキングエリアリストは、ＴＡＩリスト（TAI list）とも称される。ＴＡＩはトラッキングエリアを識別するための識別情報であり、ＭＣＣ（Mobile Country Code）と、ＭＮＣ（Mobile Network Code）と、ＴＡＣ（Tracking Area Code）とによって構成される。ＭＣＣは国コードである。ＭＮＣはネットワークコードである。ＴＡＣはトラッキングエリアのコード番号である。

【0096】

通信端末は、ステップＳＴ６０６で比較した結果、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれるＴＡＣと同じならば、該セルで待ち受け動作に入る。比較して、ステップＳＴ６０５で受信したＴＡＣがトラッキングエリアリスト内に含まれなければ、通信端末は、該セルを通して、ＭＭＥなどが含まれるコアネットワーク（Core Network，ＥＰＣ）へ、ＴＡＵ（Tracking Area Update）を行うためにトラッキングエリアの変更を要求する。

【0097】

コアネットワークを構成する装置（以下「コアネットワーク側装置」という場合がある）は、ＴＡＵ要求信号とともに通信端末から送られてくる該通信端末の識別番号（ＵＥ－ＩＤなど）をもとに、トラッキングエリアリストの更新を行う。コアネットワーク側装置は、通信端末に更新後のトラッキングエリアリストを送信する。通信端末は、受信したトラッキングエリアリストに基づいて、通信端末が保有するＴＡＣリストを書き換える（更新する）。その後、通信端末は、該セルで待ち受け動作に入る。

【0098】

スマートフォンおよびタブレット型端末装置の普及によって、セルラー系無線通信によるトラフィックが爆発的に増大しており、世界中で無線リソースの不足が懸念されている。これに対応して周波数利用効率を高めるために、小セル化し、空間分離を進めることが検討されている。

【0099】

従来のセルの構成では、ｅＮＢによって構成されるセルは、比較的広い範囲のカバレッジを有する。従来は、複数のｅＮＢによって構成される複数のセルの比較的広い範囲のカバレッジによって、あるエリアを覆うように、セルが構成されている。

【0100】

小セル化された場合、ｅＮＢによって構成されるセルは、従来のｅＮＢによって構成されるセルのカバレッジに比べて範囲が狭いカバレッジを有する。したがって、従来と同様に、あるエリアを覆うためには、従来のｅＮＢに比べて、多数の小セル化されたｅＮＢが必要となる。

【0101】

以下の説明では、従来のｅＮＢによって構成されるセルのように、カバレッジが比較的大きいセルを「マクロセル」といい、マクロセルを構成するｅＮＢを「マクロｅＮＢ」という。また、小セル化されたセルのように、カバレッジが比較的小さいセルを「スモールセル」といい、スモールセルを構成するｅＮＢを「スモールｅＮＢ」という。

【0102】

マクロｅＮＢは、例えば、非特許文献７に記載される「ワイドエリア基地局（Wide Area Base Station）」であってもよい。

【0103】

スモールｅＮＢは、例えば、ローパワーノード、ローカルエリアノード、ホットスポットなどであってもよい。また、スモールｅＮＢは、ピコセルを構成するピコｅＮＢ、フェムトセルを構成するフェムトｅＮＢ、ＨｅＮＢ、ＲＲＨ（Remote Radio Head）、ＲＲＵ（Remote Radio Unit）、ＲＲＥ（Remote Radio Equipment）またはＲＮ（Relay Node）であってもよい。また、スモールｅＮＢは、非特許文献７に記載される「ローカルエリア基地局（Local Area Base Station）」または「ホーム基地局（Home Base Station）」であってもよい。

【0104】

図７は、マクロｅＮＢとスモールｅＮＢとが混在する場合のセルの構成の概念を示す図である。マクロｅＮＢによって構成されるマクロセルは、比較的広い範囲のカバレッジ７０１を有する。スモールｅＮＢによって構成されるスモールセルは、マクロｅＮＢ（マクロセル）のカバレッジ７０１に比べて範囲が小さいカバレッジ７０２を有する。

【0105】

複数のｅＮＢが混在する場合、あるｅＮＢによって構成されるセルのカバレッジが、他のｅＮＢによって構成されるセルのカバレッジ内に含まれる場合がある。図７に示すセルの構成では、参照符号「７０４」または「７０５」で示されるように、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２が、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１内に含まれる場合がある。

【0106】

また、参照符号「７０５」で示されるように、複数、例えば２つのスモールセルのカバレッジ７０２が、１つのマクロセルのカバレッジ７０１内に含まれる場合もある。移動端末（ＵＥ）７０３は、例えばスモールセルのカバレッジ７０２内に含まれ、スモールセルを介して通信を行う。

【0107】

また図７に示すセルの構成では、参照符号「７０６」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２とが複雑に重複する場合が生じる。

【0108】

また、参照符号「７０７」で示されるように、マクロｅＮＢによって構成されるマクロセルのカバレッジ７０１と、スモールｅＮＢによって構成されるスモールセルのカバレッジ７０２とが重複しない場合も生じる。

【0109】

さらには、参照符号「７０８」で示されるように、多数のスモールｅＮＢによって構成される多数のスモールセルのカバレッジ７０２が、１つのマクロｅＮＢによって構成される１つのマクロセルのカバレッジ７０１内に構成される場合も生じる。

【0110】

ＬＴＥのハンドオーバにおいて、移動先にてＵＥが用いるパラメータ（例えば、セルＩＤなど）を移動先セルが生成し、生成されたパラメータは移動元のセルからＵＥに対してＲＲＣシグナリングとして通知される（非特許文献１参照）。

【0111】

ＮＲにおいては、ビームを用いた通信が検討されている。ＮＲにおいては、ＵＥの移動によってＵＥが帰属するビームが頻繁に切り替わることから、ＵＥのビーム間移動において、ＲＲＣを用いないモビリティが検討されている（非特許文献１１参照）。

【0112】

また、３ＧＰＰでは、ｇＮＢが二つのユニットに分離されることが提案されている（非特許文献７参照）。当該二つのユニットを各々ＣＵ（Central Unit）とＤＵ（Distributed Unit）と称する。ＣＵに複数のＤＵが接続される。例えば、ＣＵはＰＤＣＰ、ＲＬＣ、ＭＡＣおよびＨ－ＰＨＹを有することが提案されている。ＤＵはＬ－ＰＨＹを有することが提案されている。他の方法として、ＣＵがＰＤＣＰを有し、ＤＵがＲＬＣ、ＭＡＣ、ＰＨＹを有すること、あるいは、ＣＵがＰＤＣＰおよびＨ－ＲＬＣを有し、ＤＵがＬ－ＲＬＣ、ＭＡＣおよびＰＨＹを有することが提案されている。ＴＲＰはＤＵと同じ機能を有してもよい。ＤＵあるいはＴＲＰは一つまたは複数のビームを構成する。

【0113】

また、ＵＥのビームあるいはＴＲＰ（Transmission/Reception Point）間の移動においては、ＴＲＰがレイヤ２の機能を持つ場合について、セル間モビリティ、すなわち、ＲＲＣシグナリングを用いたモビリティを行い、また、ＴＲＰがレイヤ２の機能を持たない場合について、ビーム間モビリティ、すなわち、ＲＲＣシグナリングを用いないモビリティを行うことが検討されている（３ＧＰＰ Ｒ２－１６７０２４（以下「参考文献１」という）参照）。

【0114】

ＮＲにおける、複数のビーム、あるいは複数のＴＲＰを用いた通信においては、各ビーム、あるいは各ＴＲＰによって、通信可能な空間が分離されている。

【0115】

図８は、複数のビームあるいはＴＲＰによる、通信可能な空間の分離を示す図である。図８において、ｇＮＢ８００は、１つのＣＵ（Central Unit）および２つのＤＵ（Distributed Unit）により構成される。ＤＵ＃１ ８０１およびＤＵ＃２ ８０２はそれぞれＣＵ８０３に接続されている。ＤＵは、ＴＲＰであってもよい。

【0116】

図８において、ＤＵ＃１はビーム＃１ ８０４、ビーム＃２ ８０５およびビーム＃３ ８０６を持ち、ＤＵ＃２はビーム＃４ ８０７、ビーム＃５ ８０８、ビーム＃６ ８０９およびビーム＃７ ８１０を持つ。セル８１１、すなわち、ｇＮＢが通信可能な空間は、ビーム＃１ ８０４～ビーム＃７ ８１０によって互いに分離されている。

【0117】

図８において、１つのＤＵが用いられてもよいし、複数のＤＵが用いられてもよい。また、ＣＵとＤＵとが分離されておらず、１つの装置として構成されていてもよい。

【0118】

ところが、前述のように、１つのセルが各ビームあるいは各ＴＲＰによって空間分離されている場合について、ＲＲＣのパラメータをどのように扱うかは、開示されていない。

【0119】

本実施の形態１では、このような問題を解決する方法を開示する。

【0120】

一つのセルに属するビーム、あるいはＴＲＰ内では、１つのＵＥに対して同じＲＲＣパラメータを共有する。ＲＲＣパラメータは、非特許文献１２の６．３．２節に示すものであってもよい。ＲＲＣパラメータは、例えば、ＳＲに関するものであってもよいし、Ａｃｋ／Ｎａｃｋレペティション（repetition）に関するものであってもよいし、サウンディング参照信号（Sounding Reference Signal：ＳＲＳ）に関するものでもよいし、ＣＱＩ／ＣＳＩに関するものでもよい。

【0121】

ＲＲＣパラメータの共有にあたり、ｇＮＢのＣＵは、該セル内の各ＴＲＰにＲＲＣパラメータを通知するとよい。この通知は、特に、物理レイヤに関するＲＲＣパラメータについて行ってもよい。物理レイヤに関するＲＲＣパラメータは、例えば、ＳＲＳの周波数リソースを示すものであってもよい。このようにすることで、各ＴＲＰにおける変調および復調を容易にすることができる。

【0122】

あるいは、一つのセルに属するビーム、またはＴＲＰ内でビームスイーピングに必要なパラメータを共有してもよい。ビームスイーピングに必要なパラメータとしては、例えば、ビームスイーピングの周期であってもよいし、ビームスイーピング１回あたりの継続時間であってもよいし、１つのビームに要する時間であってもよい。前述のパラメータを、新たなＲＲＣパラメータとして設けてもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号受信を容易にすることができる。

【0123】

ＣＵは、該セル内の各ＴＲＰに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、各ＴＲＰにおけるビームスイーピング信号の送信を容易にすることができる。

【0124】

前述において、ＣＵからＴＲＰへのＲＲＣパラメータ通知には、例えば、ＣＰＲＩ（Common public radio interface）の制御ワードの領域を用いてもよい。該制御ワードは、ＣＵ－ＤＵ間インタフェースにＣＰＲＩを用いているときに使用するとよい。このことによって、ＣＰＲＩ上でＣＵとＤＵを流れるユーザデータの帯域を圧迫せずに、ＲＲＣパラメータを通知することができる。

【0125】

前述において、ＣＵからＴＲＰへのＲＲＣパラメータ通知には、ＡＳＮ．１（Abstract Syntax Notation One）のフォーマットを用いてもよいし、他のフォーマットを用いてもよい。ＡＳＮ．１を用いることによって、ＤＵは、ＲＲＣシグナリングと同じフォーマットでＴＲＰにパラメータを通知できるので、ＤＵのＴＲＰへのＲＲＣパラメータ通知の処理が簡単になる。

【0126】

本実施の形態１によって、１つのセル内に複数のビームあるいはＴＲＰが存在するときにおいても、ＣＵにおいてＲＲＣパラメータを管理することができる。また、セル内のビーム間、あるいはＴＲＰ間で同じＲＲＣパラメータを共有することによって、ＣＵにおける無線リソース管理を簡単にすることができる。

【0127】

実施の形態１によれば、例えば、通信端末装置と、通信端末装置と無線ビームを用いて無線通信を行う基地局装置とを含み、基地局装置によって構成されるセルは、基地局装置の配下にある複数の無線ビームによって、空間分離されており、基地局装置は、通信端末装置に対して用いるＲＲＣ（Radio Resource Control）パラメータを、同じセルに属する複数の無線ビームで共有する、通信システムが提供される。なお、複数の無線ビームは、図８に例示したように複数のＤＵ（言い換えるとＴＲＰ）によって形成されてもよいし、１つのＤＵによって形成されてもよい。

【0128】

この構成によれば、通信端末装置に対して用いるＲＲＣパラメータを、基地局装置によって構成されるセルを空間分離する複数の無線ビームのうちの２つ以上で共有する。このため、前述のように、無線リソース管理を簡単にすることができる。ここで、上記構成は、前述のように、様々に変形することが可能である。また、実施の形態１では同じセルに属する全ての無線ビームでＲＲＣパラメータを共有する例を述べたが、上記構成はこの例に限定されるものではない（例えば、後述の実施の形態８およびその変形例を参照）。

【0129】

実施の形態２．
実施の形態１においては、セル内の異なるビーム間あるいは異なるＴＲＰ間でＲＲＣパラメータを共有することを示したが、ＲＲＣパラメータを共有しないこととしてもよい。ＲＲＣパラメータは、実施の形態１と同様のものであってもよい。このことによって、異なるビームあるいは異なるＴＲＰの圏内に存在する異なるＵＥが、同じＲＲＣパラメータを競合せずに用いることができるようになるので、セルにおけるＵＥ収容数を増やすことができる。

【0130】

ところが、実施の形態１に記載のＣＵとＤＵの分離において、例えばＣＵがＰＤＣＰ、ＲＬＣ、ＭＡＣおよびＨ－ＰＨＹを有する場合、セル内のビーム間移動あるいはＴＲＰ間移動においては、実施の形態１に記載のように、ＲＲＣシグナリングを使用することができない。そのため、ＲＲＣパラメータをｇＮＢからＵＥに通知することができない。ＣＵとＤＵとが分離されていない基地局装置においても同様に、セル内のビーム間移動において、ＲＲＣパラメータをｇＮＢからＵＥに通知することができない。このことにより、セルにおけるＵＥ収容数を増やすことができないという問題が生じる。

【0131】

本実施の形態２では、このような問題を解決する方法を開示する。

【0132】

ＣＵからＵＥに対し、予めセル内のビームあるいはＴＲＰ（以下、ビーム／ＴＲＰと記載することがある）で使用するＲＲＣパラメータを通知する。ＣＵは該通知を、ＲＲＣシグナリングで行うとよい。ＣＵは該通知を、ＵＥのＲＲＣ接続開始時に行ってもよいし、ＲＲＣパラメータ変更時に行ってもよい。

【0133】

ＣＵは、ビーム／ＴＲＰの切り替えにおいて、ＵＥにビーム／ＴＲＰ切り替え指示を通知する。該切り替え指示に、移動先ビーム／ＴＲＰを表す識別子を含めるとよい。ＣＵはＵＥに、該切り替え指示を、Ｌ１／Ｌ２シグナリングで通知してもよいし、ＭＡＣシグナリングで通知してもよい。

【0134】

このようにすることによって、ＣＵは、ビーム／ＴＲＰの切り替えに伴うパラメータ変更を少ないシグナリング量で実現することが可能となる。

【0135】

前述におけるＲＲＣパラメータの通知は、ＵＥの近傍のビーム／ＴＲＰにおいて用いるＲＲＣパラメータのみで構成されてもよい。前述の近傍のビーム／ＴＲＰは、ＵＥが存在するビーム／ＴＲＰに隣接するビーム／ＴＲＰを含んでもよい。また、該通知に含まれるＲＲＣパラメータは、ＵＥが存在するビーム／ＴＲＰにて使用するパラメータと異なるパラメータのみで構成されてもよい。このようにすることで、該通知のサイズを小さくすることができる。

【0136】

他の方法を開示する。ビームあるいはＴＲＰの切り替えにおいて、ＣＵは、ＵＥに、移動先ビーム／ＴＲＰで用いるＲＲＣパラメータを通知する。該通知は、移動元ビーム／ＴＲＰを介して行ってもよい。ＲＲＣパラメータは、実施の形態１と同様、非特許文献１２の６．３．２節に示すものであってもよい。ＲＲＣパラメータは、例えば、ＳＲに関するものであってもよいし、Ａｃｋ／Ｎａｃｋレペティション（repetition）に関するものであってもよいし、サウンディング参照信号（Sounding Reference Signal：ＳＲＳ）に関するものでもよいし、ＣＱＩ／ＣＳＩに関するものでもよい。

【0137】

このようにすることによって、前述におけるＣＵからＵＥへのＲＲＣシグナリングが不要となるため、ビーム／ＴＲＰの切り替えを少ないシグナリング量で実現することが可能となる。

【0138】

ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。ビームスイーピングに必要なパラメータは、実施の形態１に示すものとしてもよい。該通知は、移動元ビーム／ＴＲＰを介して行ってもよい。ビームスイーピングに必要なパラメータは、移動先ビーム／ＴＲＰにおけるパラメータとしてもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0139】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、ビームスイーピングに必要なパラメータを迅速に通知することが可能となる。

【0140】

ＣＵは、移動元ビーム／ＴＲＰを介して、ＵＥに、ビーム／ＴＲＰの切り替え指示（以下、単に「切り替え指示」という場合がある）を通知する。切り替え指示には、移動先ビーム／ＴＲＰを示す識別子を含めてもよい。また、切り替え指示には、ビーム／ＴＲＰを切り替えるタイミングを示す情報を含めてもよい。

【0141】

前述において、移動先ビーム／ＴＲＰをＣＵが決定するにあたり、ＵＥからＣＵに通知されるビーム測定結果を用いてもよい。該測定結果は、例えば、ビーム受信強度であってもよいし、ビーム受信品質であってもよい。

【0142】

切り替え指示には、移動先ビーム／ＴＲＰを示す識別子を含めなくてもよい。ＣＵおよびＵＥは、ビーム／ＴＲＰの測定結果によって自動的に移動先ビーム／ＴＲＰを決めてもよい。ビーム／ＴＲＰの測定結果は、例えば、各ビームの受信強度であってもよいし、受信品質であってもよい。このようにすることで、切り替え指示のシグナリング量を削減することができる。

【0143】

前述における、ＳＲに関するＲＲＣパラメータとして、以下の（１）～（３）を示す。

【0144】

（１）ＳＲのＲＢ（Resource Block）およびコードを決めるパラメータ。例えば、非特許文献１２に記載のｓｒ－ＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＩｎｄｅｘ。

【0145】

（２）ＳＲの送信周期およびサブフレームオフセット。例えば、非特許文献１２に記載のｓｒ－ＣｏｎｆｉｇＩｎｄｅｘ。

【0146】

（３）前述の（１）、（２）の組み合わせ。

【0147】

前述の（１）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＳＲに用いるＲＢの位置が他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0148】

前述の（２）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＳＲ送信タイミングが他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0149】

前述の（２）において、ＳＲ送信のサブフレームオフセットのみを変更してもよい。また、サブフレームオフセットの変更において、サブフレームオフセットの情報のみを通知してもよい。このようにすることで、移動先ビーム／ＴＲＰにおける複数のＵＥのＳＲ送信について、ＵＥ間の競合回避のための、ＣＵによる調整が容易になる。また、サブフレームのオフセットの情報のみの通知によって、ＣＵからＵＥに送信するビット量を削減することができる。

【0150】

前述の（１）～（３）として通知されるパラメータは、値そのものであってもよいし、あるいは、値の変更量であってもよい。値そのものを用いることで、ＣＵからＵＥへのパラメータ通知の処理が容易になる。また、値の変更量を用いることで、パラメータ通知に要するビット数を削減することができる。

【0151】

ＣＵは、ＵＥに対し、前述の（１）～（３）を含むＲＲＣパラメータのうちで、複数のパラメータを同時に通知してもよい。このことによって、通知に要するシグナリングの量を削減することができる。

【0152】

また、ＣＵは、ＵＥに対し、前述の（１）～（３）を含むＲＲＣパラメータを別々に通知してもよい。このことによって、少ない送信リソースにおいてもパラメータを通知することが可能となる。

【0153】

ＣＵはＵＥに対し、ＳＲに関するＲＲＣパラメータとして、ＳＲの最大再送回数を示すパラメータを通知してもよいし、通知しなくてもよい。最大再送回数を示すパラメータは、例えば、非特許文献１２に記載のｄｓｒ－ＴｒａｎｓＭａｘであってもよい。パラメータを通知することによって、例えば、伝搬環境が悪いときにパラメータを小さな値に変更することによって、ＵＥは、ＳＲ再送回数超過後のランダムアクセス処理に早く移行することができる。これにより、ビーム／ＴＲＰの移動の処理を早く完了させることができる。

【0154】

ＣＵは、ＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前にＲＲＣパラメータが変更されることを防ぐことができるため、例えば、ＳＲ送信において、前述のパラメータ変更による移動元ＴＲＰ／ビームへのＳＲ不達を防ぐことができる。

【0155】

ＣＵは、ＲＲＣパラメータの通知について、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0156】

ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＲＲＣパラメータの値を初期値に戻してもよい。初期値への変更は、例えば、移動元ビーム／ＴＲＰからＵＥへのパラメータの通知が失敗したときに行ってもよい。初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。このようにすることで、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは初期値を用いてＣＵと通信を継続することが可能となる。

【0157】

あるいは、前述において、ＣＵおよびＵＥは、パラメータの値を保持してもよい。パラメータ値の保持は、例えば、ＣＵからＵＥへのパラメータの通知が失敗したときに行ってもよい。このようにすることで、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは変更前のＲＲＣパラメータを用いることができる。このため、例えば、移動先ビーム／ＴＲＰにおいて移動元ビーム／ＴＲＰと同じＲＲＣパラメータを用いている場合において、ＵＥは移動先ビーム／ＴＲＰへのＳＲ不達を防ぐことができる。

【0158】

前述において、ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。その通知には、ＲＲＣシグナリングを用いてもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このようにすることで、ＣＵは、配下のＵＥのＲＲＣパラメータの使用状況に応じて、柔軟にパラメータを設定することが可能となる。

【0159】

ＣＵは、ＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0160】

あるいは、ＣＵは、ＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＣＵは、ＲＲＣパラメータの送達確認後に、切り替え指示をＵＥに通知することができる。このため、例えば、ＳＲに関するＲＲＣパラメータの不達による、ＵＥからのＳＲ不達および再送回数超過によるランダムアクセスの実行を回避することができる。

【0161】

あるいは、ＣＵは、切り替え指示の通知の後に、ＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0162】

ＣＵは、ＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0163】

あるいは、ＣＵは、ＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。また、ＣＵはパラメータの送達確認後に切り替え指示をＵＥに通知可能となるので、例えば、パラメータの不達によるＵＥからのＳＲ不達およびＳＲ再送回数超過によるランダムアクセスの実行を回避することができる。

【0164】

ＣＵは、ＲＲＣパラメータを移動先ビーム／ＴＲＰに通知してもよい。実施の形態１と同様、該通知には、例えば、ＣＰＲＩの制御ワードの領域を用いてもよいし、ＡＳＮ．１のフォーマットを用いてもよいし、他のフォーマットを用いてもよい。このことによって、実施の形態１と同様の効果に加え、例えば、ビーム／ＴＲＰへの切り替え直後において、移動先ビーム／ＴＲＰはＵＥからのＳＲのデコードを迅速に行うことができる。

【0165】

ＣＵは、切り替え指示を、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのビーム／ＴＲＰ切り替え通知を迅速に行うことができる。

【0166】

あるいは、ＣＵは、切り替え指示を、ＭＡＣシグナリングを用いて通知してもよい。ＣＵは、自身が用いるビーム／ＴＲＰの切り替えを、切り替え指示に対するＵＥからのＡｃｋ受信後に行ってもよい。ＵＥは、通信先ビーム／ＴＲＰの切り替えを、切り替え指示に対するＡｃｋ送信後に行ってもよい。このことにより、ＣＵからＵＥへの切り替え指示の通知の信頼性が向上し、ＵＥが、ｇＮＢとのリンク喪失によって、ＲＬＦ（Radio Link Failure）となる可能性を低下させることができる。

【0167】

前述の、ＭＡＣシグナリングを用いた切り替え指示の通知において、ＣＵは、移動元ビーム／ＴＲＰからＵＥへの切り替え指示のＨＡＲＱ再送回数超過時に、ビーム／ＴＲＰを切り替えてもよい。ビーム／ＴＲＰの切り替えは、切り替え指示に対するＵＥからのＡｃｋ／Ｎａｃｋが判別不能である場合に行うとよい。このことによって、移動元ビーム／ＴＲＰが切り替え指示に対するＵＥからのＡｃｋ信号を受信し損ねた場合について、ＵＥにおける通信先ビーム／ＴＲＰ切り替えとともにｇＮＢにおいてもビーム／ＴＲＰを切り替えることができる。それにより、ＵＥにおけるｇＮＢとのリンク喪失を防ぐことができる。

【0168】

あるいは、前述において、ＣＵは、移動元ビーム／ＴＲＰからＵＥへの切り替え指示のＨＡＲＱ再送回数超過時に、ビーム／ＴＲＰを切り替えなくてもよい。この場合において、ＵＥは、ｇＮＢとのリンク喪失によるＲＬＦから復旧した後に、再度移動元ビーム／ＴＲＰと通信を行うこととしてもよい。このことにより、ＣＵにおけるビーム切り替え制御が簡単になる。

【0169】

図９は、ＣＵから移動元ビーム／ＴＲＰを介してＳＲに関するパラメータを通知する場合のビーム／ＴＲＰ切り替えを表すシーケンス図である。図９は、ＣＵからＵＥへ、ＳＲに関するパラメータおよび切り替え指示を、ＭＡＣシグナリングを用いて通知する例について示す。また、図９において、ＣＵ配下の移動元ビーム／ＴＲＰをＳ－ｂｅａｍ／ＴＲＰと表記し、ＣＵ配下の移動先ビーム／ＴＲＰをＴ－ｂｅａｍ／ＴＲＰと表記している。また、図９において、矢印の中にある黒丸は通信に用いられるビーム／ＴＲＰを示している。

【0170】

図９によれば、ビーム／ＴＲＰの切り替え前のステップＳＴ９０１において、ＵＥは、Ｓ－ｂｅａｍ／ＴＲＰを介して、ＣＵとユーザデータを送受信する。

【0171】

図９のステップＳＴ９０２において、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介して、ＵＥにＳＲパラメータを通知する。この通知には、ＭＡＣシグナリングを用いる。Ｌ１／Ｌ２シグナリングを用いてもよい。また、ＳＲパラメータは、非特許文献１２に示すｓｒ－ＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＩｎｄｅｘを含んでもよいし、非特許文献１２に示すｓｒ－ＣｏｎｆｉｇＩｎｄｅｘを含んでもよい。ステップＳＴ９０３において、ＵＥは、ＳＲパラメータの通知に対するＡｃｋをＳ－ｂｅａｍ／ＴＲＰを介してＣＵに通知する。ＵＥからの受信結果がＮａｃｋであった場合、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介してＳＲパラメータを再送してもよい。

【0172】

図９のステップＳＴ９０４において、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介して、ＵＥに切り替え指示を通知する。切り替え指示の通知には、ＭＡＣシグナリングを用いる。Ｌ１／Ｌ２シグナリングを用いてもよい。ＣＵは、切り替え指示に、Ｔ－ｂｅａｍ／ＴＲＰを示す情報を含めてもよい。ステップＳＴ９０５において、ＵＥは、切り替え指示に対するＡｃｋをＳ－ｂｅａｍ／ＴＲＰを介してＣＵに通知する。ＵＥからの受信結果がＮａｃｋであった場合、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介して切り替え指示を再送してもよい。

【0173】

図９のステップＳＴ９０６において、ＵＥは、通信先のビーム／ＴＲＰをＳ－ｂｅａｍ／ＴＲＰからＴ－ｂｅａｍ／ＴＲＰに切り替える。ステップＳＴ９０７において、ＣＵは、ビーム／ＴＲＰをＳ－ｂｅａｍ／ＴＲＰからＴ－ｂｅａｍ／ＴＲＰに切り替える。ステップＳＴ９０８において、ＣＵは、Ｔ－ｂｅａｍ／ＴＲＰを介して、ＵＥとユーザデータを通信する。

【0174】

ＵＥは、上り信号を移動元のビーム／ＴＲＰに送信してもよい。上り信号は、ＣＵからのＲＲＣパラメータの通知のＬ１／Ｌ２シグナリングに対する応答であってもよい。また、上り信号は、ＣＵからの切り替え指示のＬ１／Ｌ２シグナリングに対する応答であってもよい。上り信号として、応答用のＬ１／Ｌ２シグナリングを新たに設けてもよい。前述の応答として、新しい上り制御情報（ＵＣＩ）を設けてもよい。このことによって、ＣＵからのＲＲＣパラメータの通知あるいは切り替え指示にＬ１／Ｌ２シグナリングを用いていても、ＣＵはＵＥへの送達確認を行うことができる。それにより、前述のＬ１／Ｌ２シグナリングの信頼性を向上させることができる。

【0175】

あるいは、ＵＥは、上り信号を移動先のビーム／ＴＲＰに送信してもよい。上り信号は、ＵＥにおけるビーム／ＴＲＰ切り替えの確認用の信号としてもよい。確認用の信号を、ＳＲの周波数リソースを用いて送信してもよい。あるいは、ＳＲを、確認用の信号として送信してもよい。このことにより、上り信号のための周波数リソースを節約することができる。

【0176】

あるいは、新しいＵＣＩを送信してもよい。新しいＵＣＩのリソースとして、ＣＵがＵＥ毎に割り当ててもよい。ＣＵは、ＵＥからの応答が必要な通知に、該ＵＣＩリソースの情報を含めてもよい。応答が必要な通知としては、例えば、切り替え通知であってもよいし、パラメータ変更通知であってもよい。このようにすることによって、ＣＵは、リソースの空き状況に応じて柔軟に新しいＵＣＩのリソースをＵＥに割り当てることが可能となる。

【0177】

新しいＵＣＩのリソースの他の例として、セル内のＵＥが共通に使用するための共通リソースを用意してもよい。該共通リソースは、例えば、ＰＲＡＣＨを用いてもよいし、ＳＲ用共通リソースを用意してもよいし、他の共通リソースを設けてもよい。このことにより、ＣＵは、新しいＵＣＩのリソースについての情報をＵＥに通知する必要がなくなるため、シグナリング量を少なくすることができる。

【0178】

前述の上り信号として、ＵＥは移動先のビーム／ＴＲＰに、ＳＲを最小の周期で送信してもよい。このことにより、ＵＥが通信先のビーム／ＴＲＰを切り替えたことの確認を低遅延で行うことができる。

【0179】

前述において、ＣＵは、同じビーム／ＴＲＰの圏内に存在しているＵＥが共通して使用するためのＳＲ用共通リソースを確保してもよい。ＵＥは、ＳＲの送信を、ＳＲ用共通リソースを用いて行ってもよい。ＳＲ用共通リソースは、ＵＥ同士の競合を許容するもの（contention-based）であってもよい。ＳＲ用共通リソースの位置は、予め規格で定めてもよいし、ＣＵが配下のＵＥに通知してもよい。この通知は、報知であってもよいし、ＵＥ個別の通知であってもよい。前述における、ＵＥ個別の通知は、ＲＲＣ個別シグナリングであってもよい。このようにすることで、ＵＥは、ＲＲＣパラメータ受信失敗時においても、ＣＵに対してビーム／ＴＲＰ切り替えを行ったことを通知することが可能となる。

【0180】

ＵＥは、ＳＲ共通リソースとして、通信先ビーム／ＴＲＰ切り替え時におけるＳＲに関するＲＲＣパラメータの初期値を用いてもよい。このようにすることで、ＵＥは、ＲＲＣパラメータ受信失敗時においても、ＣＵに対してビーム／ＴＲＰ切り替えを行ったことを通知することが可能となる。

【0181】

前述において、ＵＥは、ＳＲＳを移動先のビーム／ＴＲＰに送信してもよい。ＳＲＳは、非周期的（Aperiodic）なものであってもよいし、周期的（Periodic）なものであってもよい。ＵＥは、ＳＲＳを予め定める回数分、移動先のビーム／ＴＲＰに送信してもよい。この送信回数は、規格で定めてもよいし、予めＣＵからＵＥに通知してもよい。前述の通知はＲＲＣシグナリングを用いて行ってもよい。このようにすることで、ＵＥは、ＣＵに送信する上りユーザデータがない場合においても、ＣＵに通信先ビーム／ＴＲＰ切り替えをしたことを通知することが可能となる。

【0182】

ＣＵは、ＵＥにおける通信先ビーム／ＴＲＰ切り替えの有無を、前述のＳＲを用いて判断してもよい。例えば、ＣＵは、ＵＥからＳＲ通知がない場合に、ＵＥが通信先ビーム／ＴＲＰを切り替えていないと判断してもよい。ＣＵは、移動元ビーム／ＴＲＰから、ＲＲＣパラメータおよび切り替え指示を再度通知してもよい。この再度の通知は、前述の判断結果を用いて行ってもよい。このことによって、例えば、ＵＥがＳＲに関するパラメータあるいは切り替え指示を受信し損ねることによって発生するＲＬＦあるいはランダムアクセス処理を防ぐことができる。それにより、ビーム／ＴＲＰ切り替えの時間を短縮することができる。

【0183】

ＣＵは、ＵＥへの上り信号の送信の要求有無を、ＵＥに通知してもよい。該要求有無は、移動元ビーム／ＴＲＰへの上り信号と、移動先ビーム／ＴＲＰへの上り信号とのそれぞれに対するものであってもよい。該要求有無は、ＣＵからＵＥへの切り替え指示に含めてもよい。このようにすることによって、例えば、通信品質が良いときにＵＥからの応答を不要とすることができるので、シグナリング量を削減可能となる。

【0184】

ＣＵは、ＵＥへのＲＲＣパラメータの通知を、複数回行ってもよい。このことにより、パラメータ通知の信頼性を向上させることができる。この通知回数は、規格で定めてもよいし、予めｇＮＢからＵＥに通知してもよい。前述の通知は、ＲＲＣシグナリングを用いて行ってもよい。

【0185】

ＣＵは、ＵＥへのＲＲＣパラメータの通知の送信電力を増加させてもよい。このことにより、パラメータ通知の信頼性向上を少ない通知回数で実現させることができる。電力の増加量については、規格で定めてもよいし、予めＣＵよりＵＥに通知してもよい。前述の通知は、ＲＲＣシグナリングを用いて行ってもよい。

【0186】

ＵＥへの切り替え指示通知についても、ＲＲＣパラメータの通知と同様、複数回送信してもよいし、電力を増加させてもよい。このことにより、切り替え指示通知の信頼性を向上させることができる。

【0187】

ＵＥは、移動元ビーム／ＴＲＰから受信したＲＲＣパラメータの通知を用いて、通信先のビーム／ＴＲＰの切り替えを行ってもよい。ビーム／ＴＲＰの切り替えは、ビームスイーピングおよびランダムアクセスを伴ってもよい。ビーム／ＴＲＰの切り替えは、ＲＲＣパラメータのうち１つ以上の受信を用いて行ってもよい。ビーム／ＴＲＰの切り替えは、ＵＥが前述のパラメータを１つ以上受信してから、予め定める時間が経過してから行ってもよい。前述の予め定める時間は、規格で定めてもよいし、予めＣＵよりＵＥに通知してもよい。この通知は、ＲＲＣシグナリングを用いて行ってもよい。このことによって、ＣＵからＵＥへの切り替え指示をＵＥが正しく受信できない場合においても、ＵＥは通信先のビーム／ＴＲＰを切り替えることが可能となる。また、ＣＵからＵＥへの切り替え通知の再送に要する時間が不要となる。

【0188】

前述において、ＣＵは、パラメータの通知に移動先ビーム／ＴＲＰを示す情報を含めてもよい。このようにすることで、ＣＵからＵＥへの切り替え指示をＵＥが正しく受信できない場合におけるＵＥのビーム／ＴＲＰ切り替えにおいて、ＵＥが切り替え先のビーム／ＴＲＰを探す時間を短縮することが可能となる。

【0189】

ＵＥからのＳＲ送信について、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲを無効としてもよい。ＣＵは、ビーム／ＴＲＰ切り替えがＳＲ受信と上りスケジューリンググラント送信との間に発生するときに、ＳＲを無効としてもよい。前述において、ＵＥは、移動先ビーム／ＴＲＰにＳＲを再送してもよい。このことによって、ＵＥにおけるＳＲ送信処理の実装を容易にすることができる。

【0190】

あるいは、前述の、ＵＥからのＳＲ送信後のビーム／ＴＲＰ切り替えについて、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲを有効としてもよい。ＣＵは、ＳＲに対する上りスケジューリンググラントを、移動先ビーム／ＴＲＰよりＵＥに送信してもよい。このことによって、ビーム／ＴＲＰ切り替え発生時における上りデータ通信を円滑に行うことができる。

【0191】

前述におけるＳＲを有効とするかどうかを、規格で定めてもよい。あるいは、ＣＵからＵＥに通知してもよい。この通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。この通知は、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、切り替え通知と併せて行ってもよい。このことによって、ＣＵにおける上りデータ通信のスケジューリングを柔軟に行うことができる。

【0192】

ＣＵからＵＥへの上りスケジューリンググラント通知について、ＣＵおよびＵＥは、移動元ビーム／ＴＲＰから送信された上りスケジューリンググラントを無効としてもよい。ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替えが上りスケジューリンググラントと上りユーザデータとの間に発生するときに、上りスケジューリンググラントを無効としてもよい。前述において、ＣＵは、移動先ビーム／ＴＲＰから、上りスケジューリンググラントを再送してもよい。あるいは、ＵＥは、移動先ビーム／ＴＲＰに対し、ＳＲ送信からやり直してもよい。前述において、ＵＥがＳＲ送信からやり直すかどうかについて、規格で定めてもよい。あるいは、ｇＮＢからＵＥに通知してもよい。前述の通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。前述の通知は、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、切り替え通知と併せて行ってもよい。このことにより、ｇＮＢは移動先ビーム／ＴＲＰにおける上りリソース使用状況に応じたスケジューリングを行うことが可能となる。

【0193】

あるいは、前述の、ＣＵからＵＥへの上りスケジューリンググラント通知後のビーム／ＴＲＰ切り替えについて、ＣＵおよびＵＥは、移動元ビーム／ＴＲＰから送信された上りスケジューリンググラントを有効としてもよい。ＵＥは、上りスケジューリンググラントを用いて、移動先ビーム／ＴＲＰに上りユーザデータを送信してもよい。このことにより、ＣＵ、ＵＥ間のシグナリング量を削減することができる。

【0194】

前述における上りスケジューリンググラントを有効とするかどうかを、規格で定めてもよいし、あるいは、ＣＵからＵＥに通知してもよい。ＣＵからＵＥへの通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。上りスケジューリンググラントを有効にする場合の例として、スケジューリンググラントにて示される上りリソースを、移動先ビーム／ＴＲＰが該ＵＥに対して使用可能である場合としてもよい。前述の通知は、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、切り替え通知と併せて行ってもよい。このことにより、ＣＵは、移動先ビーム／ＴＲＰにおける上りリソース使用状況に応じたスケジューリングを、少ないシグナリングで行うことが可能となる。

【0195】

ＵＥからＣＵへの上りユーザデータ送信について、ＣＵは、移動元ビーム／ＴＲＰにてＵＥより受信した上りユーザデータに対するＡｃｋ／Ｎａｃｋを移動先ビーム／ＴＲＰからＵＥに送信してもよい。前述における移動先ビーム／ＴＲＰからのＡｃｋ／Ｎａｃｋ送信は、ビーム／ＴＲＰ切り替えがＵＥからの上りユーザデータ送信とＣＵからのＡｃｋ／Ｎａｃｋ通知との間に発生するときに行ってもよい。このことによって、上りユーザデータ送信後のビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0196】

本実施の形態２により、セル内のビーム／ＴＲＰ間移動においてＲＲＣパラメータをＣＵからＵＥに通知することを可能とし、ビーム／ＴＲＰによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ＲＲＣシグナリングによる通知に比べて、パラメータを迅速に通知することが可能となる。

【0197】

実施の形態２において、ＣＵとＤＵが分離されている基地局装置を例として示したが、ＣＵとＤＵが分離されていない基地局装置について適用してもよい。該基地局装置は、ビーム間でＲＲＣパラメータを共有しない基地局装置であってもよい。実施の形態２を該基地局装置に適用するにあたり、ＣＵをｇＮＢに読み替えてもよい。このようにすることで、セル内のビーム間移動においてＲＲＣパラメータをｇＮＢから移動元ビームを介してＵＥに通知することを可能とし、ビームによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ｇＮＢからＵＥにパラメータを迅速に通知することが可能となる。

【0198】

また、実施の形態２において、移動元ビーム／ＴＲＰよりＲＲＣパラメータをＵＥに通知する基地局装置を例として示したが、他のビーム／ＴＲＰよりＲＲＣパラメータを通知してもよい。前述の、他のビーム／ＴＲＰは、例えば、制御情報送信用のビーム／ＴＲＰであってもよい。このようにすることで、例えば、ユーザデータ送受信用と制御情報送受信用のビーム／ＴＲＰが存在する基地局装置において、ＲＲＣパラメータを少ないシグナリング量で通知することが可能となる。このため、ビーム移動におけるＲＲＣパラメータ通知を迅速に行うことが可能となる。

【0199】

実施の形態２によれば、例えば、通信端末装置と、通信端末装置と無線ビームを用いて無線通信を行う基地局装置とを含み、基地局装置によって構成されるセルは、基地局装置の配下にある複数の無線ビームによって、空間分離されており、通信端末装置が第１の無線ビームの圏内から第２の無線ビームの圏内に移動する場合、基地局装置は、通信端末装置に対して用いるＲＲＣ（Radio Resource Control）パラメータを、第１の無線ビーム用の第１のＲＲＣパラメータから、第２の無線ビーム用の第２のＲＲＣパラメータに変更する、通信システムが提供される。なお、複数の無線ビームは、図８に例示したように複数のＤＵ（言い換えるとＴＲＰ）によって形成されてもよいし、１つのＤＵによって形成されてもよいし、あるいは、ＣＵとＤＵが統合された基地局装置によって形成されてもよい。

【0200】

この構成によれば、通信端末装置に対して用いる無線ビームの変更に応じて、通信端末装置に対して用いるＲＲＣパラメータを変更する。このため、前述のように、通信端末装置の収容数を増加させることができる。

【0201】

ここで、上記構成は、前述のように、様々に変形することが可能である。例えば、基地局装置は、複数の無線ビームを出力する少なくとも１つのＤＵ（Distributed Unit）と、少なくとも１つのＤＵを制御するＣＵ（Central Unit）とを含み、ＣＵがＭＡＣ（Medium Access Control）機能を有しており、ＣＵは、第２のＲＲＣパラメータを通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、通信端末装置に通知することと、を行う、通信システムが提供される。あるいは、基地局装置は、複数の無線ビームを出力する機能およびＭＡＣ機能を有しており、基地局装置は、第２のＲＲＣパラメータを通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、通信端末装置に通知することと、を行う、通信システムが提供される。

【0202】

また、以下の変形例１～３で述べるように、様々な変形が提供される。

【0203】

実施の形態２の変形例１．
実施の形態２においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて適用してもよい。

【0204】

前述における、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータとして、以下の（１）～（３）を示す。

【0205】

（１）ＵＥからのＡｃｋ／Ｎａｃｋの反復回数。例えば、非特許文献１２に記載のｒｅｐｅｔｉｔｉｏｎＦａｃｔｏｒ。

【0206】

（２）Ａｃｋ／Ｎａｃｋ反復送信のＲＢを決めるパラメータ。例えば、非特許文献１２に記載のｎ１ＰＵＣＣＨ－ＡＮ－Ｒｅｐ。

【0207】

（３）前述の（１）、（２）の組み合わせ。

【0208】

前述の（１）によれば、伝搬状況に応じてＡｃｋ／Ｎａｃｋの反復回数を変えることで、特に、伝搬環境が悪い状況下において、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋ通知の信頼性を高めることができる。

【0209】

前述の（２）によれば、ＵＥのビーム／ＴＲＰ間移動による、Ａｃｋ／Ｎａｃｋレペティションに用いるＲＢが他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0210】

前述の（１）～（３）として通知されるパラメータは、値そのものであってもよいし、あるいは、値の変更量であってもよい。

【0211】

本変形例１において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態２と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知するＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知の方法は、実施の形態２に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。

【0212】

ＣＵはＵＥに対し、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータとして、再送データのバンドリング有無を示すパラメータを通知してもよいし、通知しなくてもよい。バンドリング有無を示すパラメータは、例えば、非特許文献１２に記載のｔｄｄ＿ＡｃｋＮａｃｋＦｅｅｄｂａｃｋＭｏｄｅであってもよい。バンドリング有無を示すパラメータを通知すれば、例えば、伝搬環境が悪いときに、再送のバンドリングを無効とすることによって、ＣＵは、送達確認がとれたユーザデータの再送を抑えることができる。

【0213】

実施の形態２と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0214】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。

【0215】

ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前のＡｃｋ／Ｎａｃｋ送信において、パラメータ変更による移動元ＴＲＰ／ビームへのＡｃｋ／Ｎａｃｋ送信の信頼性低下を防ぐことができる。

【0216】

実施の形態２と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0217】

ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは初期値あるいは変更前のＲＲＣパラメータを用いることができる。このため、ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティションにおける信頼性を高めることができる。

【0218】

実施の形態２と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0219】

あるいは、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの送達確認後に、切り替え指示をＵＥに通知することができる。その結果、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの不達が、ＵＥからの反復Ａｃｋ／Ｎａｃｋ不達をもたらすこと、および、ＵＥからの反復Ａｃｋ／Ｎａｃｋ不達がＡｃｋ／Ｎａｃｋ通知の信頼性を低下させることを、回避することができる。

【0220】

あるいは、ＣＵは、切り替え指示の通知の後に、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて、切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0221】

ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0222】

あるいは、ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。また、ＣＵはパラメータの送達確認後に切り替え指示をＵＥに通知可能となるので、パラメータの不達によるＵＥからの反復Ａｃｋ／Ｎａｃｋ不達を回避し、Ａｃｋ／Ｎａｃｋ送信の信頼性を高めることができる。

【0223】

また、切り替え通知についても、実施の形態２と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態２と同様の効果を得ることができる。

【0224】

Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図９のステップＳＴ９０２におけるＳＲに関するパラメータを、Ａｃｋ／Ｎａｃｋレペティションに関するパラメータに置き換えればよい。

【0225】

実施の形態２と同様、ＣＵはＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、Ａｃｋ／Ｎａｃｋレペティションの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0226】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからの下りユーザデータに対するＡｃｋ／Ｎａｃｋを、移動先ビーム／ＴＲＰに通知してもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋの通知は、下りユーザデータとＡｃｋ／Ｎａｃｋとの間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ処理を円滑に行うことができる。

【0227】

ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションにおいて、ＣＵは、移動元ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋと、移動先ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋとの両方を用いてもよいし、片方のみを用いてもよい。Ａｃｋ／Ｎａｃｋの利用は、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションの間にビーム／ＴＲＰが切り替わった時に行うとよい。前述において、どのビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋを用いるかについて、予め規格で定めてもよいし、ＣＵにて適宜切り替えてもよい。前述において、移動元ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋと、移動先ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋとの両方を用いることによって、Ａｃｋ／Ｎａｃｋレペティションの間にビーム／ＴＲＰが切り替わる場合においても、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋ通知の信頼性を高めることができる。また、前述において、移動元ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋと、移動先ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋとのうちの片方のみを用いることによって、ＣＵにおけるＡｃｋ／Ｎａｃｋレペティションの合成処理が不要となる。それにより、ＣＵにおけるＡｃｋ／Ｎａｃｋ受信処理が簡単になる。

【0228】

ＣＵは、ＵＥから移動元ビーム／ＴＲＰに送信されたＡｃｋ／Ｎａｃｋレペティションを用いた下りユーザデータのＵＥへの再送を、移動先ビーム／ＴＲＰを介して行ってもよい。該再送は、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションと、ＣＵからＵＥへの下りユーザデータの再送との間で、ビーム／ＴＲＰが切り替わった時に行ってもよい。このことによって、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ再送処理を円滑に行うことができる。

【0229】

本変形例１を用いることで、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータのＵＥへの通知を可能とし、ビーム／ＴＲＰによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ＲＲＣシグナリングによる通知に比べて、パラメータを迅速に通知することが可能となる。

【0230】

実施の形態２の変形例２．
実施の形態２においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＳＲＳに関するＲＲＣパラメータについて適用してもよい。

【0231】

前述における、ＳＲＳに関するＲＲＣパラメータとして、以下の（１）～（７）を示す。

【0232】

（１）ＳＲＳに使用する帯域。例えば、非特許文献１２に記載のｓｒｓ－Ｂａｎｄｗｉｄｔｈ。

【0233】

（２）ＳＲＳの周波数ホッピングを行う帯域。例えば、非特許文献１２に記載のｓｒｓ－ＨｏｐｐｉｎｇＢａｎｄｗｉｄｔｈ。

【0234】

（３）ＳＲＳの周波数軸上における位置。例えば、非特許文献１２に記載のｆｒｅｑＤｏｍａｉｎＰｏｓｉｔｉｏｎ。

【0235】

（４）ＳＲＳの周期およびサブフレームオフセット。例えば、非特許文献１２に記載のｓｒｓ－ＣｏｎｆｉｇＩｎｄｅｘ。

【0236】

（５）ＳＲＳの送信におけるＣｏｍｂの位置。例えば、非特許文献１２に記載のｔｒａｎｓｍｉｓｓｉｏｎＣｏｍｂ。

【0237】

（６）ＳＲＳのサイクリックシフト。例えば、非特許文献１２に記載のｃｙｃｌｉｃＳｈｉｆｔ。

【0238】

（７）前述の（１）～（６）の組み合わせ。

【0239】

前述の（１）によれば、ビーム／ＴＲＰ内のＵＥ数に応じてＳＲＳに使用する帯域を変えることによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0240】

前述の（２）によれば、ビーム／ＴＲＰ内のＵＥ数に応じてＳＲＳの周波数ホッピングを行う帯域を柔軟に変更することによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0241】

前述の（３）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＳＲＳの周波数軸上の位置が他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0242】

前述の（４）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＳＲＳ送信タイミングが他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0243】

前述の（５）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＳＲＳのＣｏｍｂの位置が他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0244】

前述の（６）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＳＲＳのサイクリックシフト量が他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0245】

前述の（４）において、ＳＲＳ送信のサブフレームオフセットのみを変更してもよい。また、サブフレームオフセットの変更において、サブフレームオフセットの情報のみを通知してもよい。このようにすることで、移動先ビーム／ＴＲＰにおける複数のＵＥのＳＲＳ送信について、ＵＥ間の競合回避のためのＣＵによる調整が容易になる。また、サブフレームのオフセットの情報のみの通知によれば、ＣＵからＵＥに送信するビット量を削減することができる。

【0246】

前述の（１）～（７）として通知されるパラメータは、値そのものであってもよいし、あるいは、値の変更量であってもよい。値そのものを用いることで、ＣＵからＵＥへのパラメータ通知の処理が容易になる。また、値の変更量を用いることで、パラメータ通知に要するビット数を削減することができる。

【0247】

本変形例２において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態２と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する、ＳＲＳに関するＲＲＣパラメータの通知方法は、実施の形態２に記載のＲＲＣパラメータの通知と同じ方法を適用してもよい。

【0248】

ＣＵはＵＥに対し、ＳＲＳに関するＲＲＣパラメータとして、ＳＲＳの連続送信の有無を示すパラメータを通知してもよいし、通知しなくてもよい。連続送信の有無を示すパラメータは、例えば、非特許文献１２に記載のＤｕｒａｔｉｏｎであってもよい。前述のパラメータを通知することによって、ＣＵは、ＳＲＳのリソースのＵＥへの割り当てを柔軟に行うことができる。

【0249】

実施の形態２と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0250】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。

【0251】

ＣＵは、ＳＲＳに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＳＲＳに関するＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前のＳＲＳ送信において、パラメータ変更によるＣＵへのＳＲＳ不達によって発生するランダムアクセス動作および上り通信レート低下を防ぐことができる。

【0252】

実施の形態２と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0253】

ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＳＲＳに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことによって、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは初期値あるいは変更前のＲＲＣパラメータを用いることで、ＵＥから移動先ビーム／ＴＲＰへのＳＲＳ不達を防ぐことができる。

【0254】

実施の形態２と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0255】

あるいは、ＣＵは、ＳＲＳに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＣＵは、ＳＲＳに関するＲＲＣパラメータの送達確認後に、切り替え指示をＵＥに通知することができる。その結果、ＳＲＳに関するＲＲＣパラメータの不達がもたらすＵＥからＣＵへのＳＲＳ不達を回避し、上り通信レートの低下およびランダムアクセスの発生を回避することができる。

【0256】

あるいは、ＣＵは、切り替え指示の通知の後に、ＳＲＳに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0257】

ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0258】

あるいは、ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。また、ＣＵはパラメータの送達確認後に切り替え指示をＵＥに通知可能となるので、パラメータの不達によるＵＥからＣＵへのＳＲＳ不達を回避し、上り通信レートの低下およびランダムアクセスの発生を回避することができる。

【0259】

また、切り替え通知についても、実施の形態２と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことのより、実施の形態２と同様の効果を得ることができる。

【0260】

ＳＲＳに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図９のステップＳＴ９０２におけるＳＲに関するパラメータを、ＳＲＳに関するパラメータに置き換えればよい。

【0261】

実施の形態２と同様、ＣＵはＵＥへのＳＲＳに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、ＳＲＳに関するパラメータ通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0262】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからのＳＲＳ送信指示に対するＳＲＳ送信を、移動先ビーム／ＴＲＰによって行ってもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＳＲＳ送信は、ＳＲＳ送信指示とＳＲＳ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。また、前述におけるＳＲＳ送信は、非周期的（Aperiodic）なＳＲＳ送信について行ってもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときのＳＲＳ送信処理を円滑に行うことができる。

【0263】

ＣＵは、ＵＥから移動元ビームに送信したＳＲＳを無効としてもよい。ＳＲＳを無効とする動作は、ＳＲＳ送信の後にビーム／ＴＲＰが切り替わったときに行うとよい。ＣＵはＵＥに、ＳＲＳ送信指示を再送してもよい。ＵＥは、移動先ビーム／ＴＲＰに対してＳＲＳを再送してもよい。このことによって、ＣＵは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0264】

前述したＵＥからのＳＲＳ再送は、ＵＥが自律的に行ってもよい。このことによって、ＣＵはビーム／ＴＲＰ切り替え後のＳＲＳを迅速に取得できる。前述において、ＵＥが自律的にＳＲＳを再送するかどうかは、規格で定めてもよいし、ＣＵからＵＥにＲＲＣシグナリングで予め通知してもよいし、ＣＵからＵＥへの切り替え指示通知と併せて通知してもよい。

【0265】

本変形例２を用いることで、ＳＲＳに関するＲＲＣパラメータのＵＥへの通知を可能とし、ビーム／ＴＲＰによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ＲＲＣシグナリングによる通知に比べて、パラメータを迅速に通知することが可能となる。

【0266】

実施の形態２の変形例３．
実施の形態２においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて適用してもよい。

【0267】

前述における、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータとして、以下の（１）～（５）を示す。

【0268】

（１）ＣＱＩのＲＢを決めるパラメータ。例えば、非特許文献１２に記載のｃｑｉ－ＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＩｎｄｅｘ。

【0269】

（２）ＣＱＩ、ＰＭＩ（Precoding Matrix Indicator）の周期およびサブフレームオフセット。例えば、非特許文献１２に記載のｃｑｉ－ｐｍｉ－ＣｏｎｆｉｇＩｎｄｅｘ。

【0270】

（３）ＲＩ（Rank Indicator）の周期およびサブフレームオフセット。例えば、非特許文献１２に記載のｒｉ－ＣｏｎｆｉｇＩｎｄｅｘ。

【0271】

（４）Ａｃｋ／ＮａｃｋとＣＱＩの同時送信の可否。例えば、非特許文献１２に記載のｓｉｍｕｌｔａｎｅｏｕｓＡｃｋＮａｃｋＡｎｄＣＱＩ。

【0272】

（５）前述の（１）～（４）の組み合わせ。

【0273】

前述の（１）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＣＱＩに用いるＲＢの位置が他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0274】

前述の（２）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＣＱＩ、ＰＭＩ送信タイミングが他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0275】

前述の（３）によれば、ＵＥのビーム／ＴＲＰ間移動による、ＲＩ送信タイミングが他のＵＥと競合するのを防ぐことによって、１つのビーム／ＴＲＰにおける収容ＵＥ数を増やすことができる。

【0276】

前述の（４）によれば、移動先のビーム／ＴＲＰ間移動における上りデータスケジューリングの状況に応じて、Ａｃｋ／ＮａｃｋとＣＱＩの同時送信の可否を柔軟に設定可能とすることによって、ＵＥがＡｃｋ／ＮａｃｋとＣＱＩを効率的にＣＵに送信することが可能となる。

【0277】

前述の（２）において、ＣＱＩ、ＰＭＩのサブフレームオフセットのみを変更してもよい。また、サブフレームオフセットの変更において、サブフレームオフセットの情報のみを通知してもよい。このようにすることで、移動先ビーム／ＴＲＰにおける複数のＵＥのＣＱＩ／ＣＳＩ送信について、ＵＥ間の競合回避のためのＣＵによる調整が容易になる。また、サブフレームのオフセットの情報のみの通知によれば、ＣＵからＵＥに送信するビット量を削減することができる。

【0278】

前述の（４）において、前述の（２）と同様、ＲＩのサブフレームオフセットのみを変更してもよい。また、サブフレームオフセットの変更において、サブフレームオフセットの情報のみを通知してもよい。このようにすることで、前述と同様の効果を得ることができる。

【0279】

前述の（１）～（５）として通知されるパラメータは、値そのものであってもよいし、あるいは、値の変更量であってもよい。値そのものを用いることで、ＣＵからＵＥへのパラメータ通知の処理が容易になる。また、値の変更量を用いることで、パラメータ通知に要するビット数を削減することができる。

【0280】

実施の形態２と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0281】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。

【0282】

本変形例３において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態２と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの通知方法は、実施の形態２に記載のＲＲＣパラメータの通知と同じ方法を適用してもよい。

【0283】

ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前のＣＱＩ／ＣＳＩ送信において、パラメータ変更によるＣＵへのＣＱＩ／ＣＳＩ不達によって発生する下り通信レート低下を防ぐことができる。

【0284】

実施の形態２と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0285】

ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このようにすることで、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは初期値あるいは変更前のＲＲＣパラメータを用いることができる。このため、例えば、移動先ビーム／ＴＲＰにおいて移動元ビーム／ＴＲＰと同じＲＲＣパラメータを用いている場合において、ＵＥは移動先ビーム／ＴＲＰへのＣＱＩ／ＣＳＩ不達を防ぐことができる。

【0286】

実施の形態２と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0287】

あるいは、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの送達確認後に、切り替え指示をＵＥに通知することができる。その結果、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの不達がもたらすＵＥからＣＵへのＣＱＩ不達を回避し、下り通信レートの低下を回避することができる。

【0288】

あるいは、ＣＵは、切り替え指示の通知の後に、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0289】

ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0290】

あるいは、ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。また、ＣＵはパラメータの送達確認後に切り替え指示をＵＥに通知可能となるので、パラメータの不達によるＵＥからＣＵへのＣＱＩ／ＣＳＩ不達を回避し、下り通信レートの低下を回避することができる。

【0291】

また、切り替え通知についても、実施の形態２と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことのより、実施の形態２と同様の効果を得ることができる。

【0292】

ＣＱＩ／ＣＳＩに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図９のステップＳＴ９０２におけるＳＲに関するパラメータを、ＣＱＩ／ＣＳＩに関するパラメータに置き換えればよい。

【0293】

実施の形態２と同様、ＣＵはＵＥへのＣＱＩ／ＣＳＩに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、ＣＱＩ／ＣＳＩに関するパラメータ通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0294】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからのＣＱＩ／ＣＳＩ送信指示に対するＣＱＩ／ＣＳＩ送信を、移動先ビーム／ＴＲＰによって行ってもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＣＱＩ／ＣＳＩ送信は、ＣＱＩ／ＣＳＩ送信指示とＣＱＩ／ＣＳＩ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。また、前述におけるＣＱＩ／ＣＳＩ送信は、非周期的（Aperiodic）なＣＱＩ／ＣＳＩ送信について行ってもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときのＣＱＩ／ＣＳＩ送信処理を円滑に行うことができる。

【0295】

ＣＵは、ＵＥから移動元ビームに送信したＣＱＩ／ＣＳＩを無効としてもよい。ＣＱＩ／ＣＳＩを無効とする動作は、ＣＱＩ／ＣＳＩ送信の後にビーム／ＴＲＰが切り替わったときに行うとよい。ＣＵはＵＥに、ＣＱＩ／ＣＳＩ送信指示を再送してもよい。ＵＥは、移動先ビーム／ＴＲＰに対してＣＱＩ／ＣＳＩを再送してもよい。このことによって、ＣＵは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0296】

前述したＵＥからのＣＱＩ／ＣＳＩ再送は、ＵＥが自律的に行ってもよい。このことによって、ＣＵはビーム／ＴＲＰ切り替え後のＣＱＩ／ＣＳＩを迅速に取得できる。前述において、ＵＥが自律的にＣＱＩ／ＣＳＩを再送するかどうかは、規格で定めてもよいし、ＣＵからＵＥにＣＱＩ／ＣＳＩシグナリングで予め通知してもよいし、ＣＵからＵＥへの切り替え指示通知と併せて通知してもよい。

【0297】

本変形例３を用いることで、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータのＵＥへの通知を可能とし、ビーム／ＴＲＰによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ＲＲＣシグナリングによる通知に比べて、パラメータを迅速に通知することが可能となる。

【0298】

実施の形態３．
実施の形態２においては、ｇＮＢが移動元ビーム／ＴＲＰからＲＲＣパラメータをＵＥに通知することを示した。ＮＲにおいては、広い周波数帯域を確保するため、ＬＴＥよりも高い周波数の使用が検討されている。高い周波数を用いる場合、障害物などの影響により通信状況が急激に悪化することがある。このとき、ビーム／ＴＲＰ切り替えにおいて、ＲＲＣパラメータ通知あるいは切り替え通知が間に合わなくなると、ｇＮＢとＵＥとの間の無線リンクが喪失するという問題が生じる。

【0299】

本実施の形態３では、このような問題を解決する方法を開示する。

【0300】

ＣＵは、ＲＲＣパラメータのＵＥへの通知を、移動先ビーム／ＴＲＰを介して行う。ＣＵからＵＥへの切り替え指示の通知は、移動元ビーム／ＴＲＰを介して行う。ＣＵからのＲＲＣパラメータ通知を移動先ビーム／ＴＲＰを介して行う点で、実施の形態２と異なる。

【0301】

ＣＵからＵＥへのＲＲＣパラメータの通知は、ＣＵからＵＥへの切り替え通知の後に行うとよい。このようにすることで、ＵＥは通信先ビーム／ＴＲＰを切り替えた後で、前述のＲＲＣパラメータを円滑に取得することが可能となる。

【0302】

ＲＲＣパラメータは、実施の形態２と同様、非特許文献１２の６．３．２節に示すものであってもよい。ＲＲＣパラメータは、例えば、ＳＲに関するものであってもよいし、Ａｃｋ／Ｎａｃｋレペティション（repetition）に関するものであってもよいし、サウンディング参照信号（Sounding Reference Signal：ＳＲＳ）に関するものでもよいし、ＣＱＩ／ＣＳＩに関するものでもよい。

【0303】

ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。ビームスイーピングに必要なパラメータは、実施の形態１に示すものとしてもよい。ビームスイーピングに必要なパラメータの通知は、移動元ビーム／ＴＲＰを介して行ってもよい。ビームスイーピングに必要なパラメータは、移動先ビーム／ＴＲＰにおけるパラメータとしてもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0304】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、実施の形態２と同様、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、ビームスイーピングに必要なパラメータを迅速に通知することが可能となる。

【0305】

前述における、ＳＲに関するＲＲＣパラメータは、実施の形態２において（１）～（３）に示したものであってもよい。また、実施の形態２と同様、ＣＵはＵＥに対し、ＳＲに関するＲＲＣパラメータとして、ＳＲの最大再送回数を示すパラメータを通知してもよいし、通知しなくてもよい。このことによって、実施の形態２と同様の効果を得ることができる。

【0306】

ＣＵからＵＥに対するＲＲＣパラメータの通知には、実施の形態２と同様、Ｌ１／Ｌ２シグナリングを用いてもよい。このようにすることによって、ＣＵからＵＥに対して迅速な通知が可能となる。また、ｇＮＢのビーム／ＴＲＰの切り替えによってＵＥからＣＵへのＡｃｋ／Ｎａｃｋの応答に用いる周波数リソースが変わった場合においても、ＣＵからＵＥに対して前述のＲＲＣパラメータを通知することが可能となる。

【0307】

あるいは、前述において、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態２と同様、前述のＲＲＣパラメータを少ないシンボル数で送ることが可能となるとともに、パラメータ通知の信頼性が向上する。また、例えば、前述のパラメータの不達による、ＵＥからのＳＲ不達および再送回数超過によるランダムアクセスの実行を回避することができる。

【0308】

あるいは前述において、ＲＲＣシグナリングを用いてもよい。このことにより、ＲＲＣパラメータを予めＣＵからＵＥに通知することが可能となるため、ビーム／ＴＲＰ切り替え時におけるＲＲＣパラメータ通知が不要となる。これによりシグナリング量を少なくすることが可能となる。移動先ビーム／ＴＲＰからＵＥにＲＲＣパラメータを通知する点で、前述の方法は非特許文献１と異なる。

【0309】

ＣＵからＵＥに対する切り替え指示の通知の方法には、実施の形態２と同様、Ｌ１／Ｌ２シグナリングを用いてもよい。あるいは、ＭＡＣシグナリングを用いてもよい。このことにより、ＵＥへのビーム／ＴＲＰ切り替え通知を迅速に行うことができる。また、ＭＡＣシグナリングを用いることにより、前述の通知の信頼性を向上させることができる。

【0310】

ＣＵは、ＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0311】

実施の形態２と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＲＲＣパラメータの値を初期値に戻してもよいし、当該パラメータの値を保持してもよい。パラメータ値の保持は、例えば、ＣＵからＵＥへのパラメータの通知が失敗したときに行ってもよい。パラメータ値の初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。前述において、ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよいし、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このようにすることで、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは変更前のＲＲＣパラメータを用いることができる。このため、例えば、移動先ビーム／ＴＲＰにおいて移動元ビーム／ＴＲＰと同じＲＲＣパラメータを用いている場合において、ＵＥは移動先ビーム／ＴＲＰへのＳＲ不達を防ぐことができる。

【0312】

実施の形態２と同様、ｇＮＢは、移動元ビーム／ＴＲＰからＵＥへの切り替え指示のＨＡＲＱ再送回数超過時に、ビーム／ＴＲＰを切り替えてもよいし、切り替えなくてもよい。それぞれの場合について、実施の形態２と同様の効果を得ることができる。

【0313】

図１０は、ＣＵから移動先ビーム／ＴＲＰを介してパラメータを通知する場合のビーム／ＴＲＰ切り替えを表すシーケンス図である。図１０は、ＣＵからＵＥへ、パラメータおよび切り替え指示を、ＭＡＣシグナリングを用いて通知する例について示す。また、図１０において、ＣＵ配下の移動元ビーム／ＴＲＰをＳ－ｂｅａｍ／ＴＲＰと表記し、ＣＵ配下の移動先ビーム／ＴＲＰをＴ－ｂｅａｍ／ＴＲＰと表記している。また、図１０において、矢印の中にある黒丸は通信に用いられるビーム／ＴＲＰを示している。図９と同一のステップには同一のステップ番号を付して、共通する説明を省略する。

【0314】

図１０において、ビーム／ＴＲＰ切り替え前は、ＵＥは、Ｓ－ｂｅａｍ／ＴＲＰを介してＣＵとユーザデータを送受信する（ステップＳＴ９０１）。

【0315】

図１０のステップＳＴ２００１において、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介して、ＵＥに切り替え指示を通知する。切り替え指示の通知には、ＭＡＣシグナリングを用いる。Ｌ１／Ｌ２シグナリングを用いてもよい。ＣＵは、切り替え指示に、Ｔ－ｂｅａｍ／ＴＲＰを示す情報を含めてもよい。ステップＳＴ２００２において、ＵＥは、切り替え指示に対するＡｃｋをＳ－ｂｅａｍ／ＴＲＰを介してＣＵに通知する。ＵＥからの受信結果がＮａｃｋであった場合、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介して切り替え指示を再送してもよい。

【0316】

図１０のステップＳＴ２００３において、ＣＵは、Ｔ－ｂｅａｍ／ＴＲＰを介して、ＵＥにＳＲパラメータを通知する。この通知には、ＭＡＣシグナリングを用いる。Ｌ１／Ｌ２シグナリングを用いてもよい。また、ＳＲパラメータは、非特許文献１２に示すｓｒ－ＰＵＣＣＨ－ＲｅｓｏｕｒｃｅＩｎｄｅｘを含んでもよいし、非特許文献１２に示すｓｒ－ＣｏｎｆｉｇＩｎｄｅｘを含んでもよい。ステップＳＴ２００４において、ＵＥは、ＳＲパラメータの通知に対するＡｃｋをＳ－ｂｅａｍ／ＴＲＰを介してＣＵに通知する。ＵＥからの受信結果がＮａｃｋであった場合、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介してＳＲパラメータを再送してもよい。

【0317】

ＵＥは、上り信号を移動元のビーム／ＴＲＰに送信してもよい。上り信号は、ＣＵからの切り替え指示のＬ１／Ｌ２シグナリングに対する応答であってもよい。上り信号として、応答用のＬ１／Ｌ２シグナリングを新たに設けてもよい。前述の応答として、新しい上り制御情報（ＵＣＩ）を設けてもよい。このことによって、ＣＵからの切り替え指示にＬ１／Ｌ２シグナリングを用いていても、ＣＵはＵＥへの送達確認を行うことができる。それにより、前述のＬ１／Ｌ２シグナリングの信頼性を向上させることができる。

【0318】

新しいＵＣＩについては、実施の形態２と同様としてもよい。このことにより、実施の形態２と同様の効果を得ることができる。

【0319】

あるいは、ＵＥは、上り信号を移動先のビーム／ＴＲＰに送信してもよい。ＣＵおよびＵＥは、上り信号を、ＵＥにおけるビーム／ＴＲＰ切り替えの確認用の信号として用いてもよい。上り信号は、ＣＵからのＲＲＣパラメータ通知のＭＡＣシグナリングに対する応答であってもよい。あるいは、ＣＵからのＲＲＣパラメータ通知のＬ１／Ｌ２シグナリングに対する応答であってもよい。上り信号として、応答用のＬ１／Ｌ２シグナリングを新たに設けてもよい。前述の応答として、新しい上り制御情報（ＵＣＩ）を設けてもよい。このことによって、ＣＵからの切り替え指示にＬ１／Ｌ２シグナリングを用いていても、ＣＵはＵＥへの送達確認を行うことができる。それにより、前述のＬ１／Ｌ２シグナリングの信頼性を向上させることができる。

【0320】

実施の形態２と同様、ＣＵは、ＵＥへの上り信号の送信の要求有無を、ＵＥに通知してもよい。該要求有無は、移動元ビーム／ＴＲＰへの上り信号と、移動先ビーム／ＴＲＰへの上り信号とのそれぞれに対するものであってもよい。該要求有無は、ＣＵからＵＥへの切り替え指示に含めてもよい。このようにすることによって、例えば、通信品質が良いときにＵＥからの応答を不要とすることができるので、シグナリング量を削減可能となる。

【0321】

ＵＥは、前述の確認用の信号を、ＳＲの周波数リソースを用いて送信してもよい。あるいは、ＳＲを、前述の確認用の信号として送信してもよい。このことにより、上り信号のための周波数リソースを節約することができる。

【0322】

実施の形態２と同様に、ＵＥは、前述のＳＲを、最小の周期で送信してもよい。このことにより、ＵＥが通信先のビーム／ＴＲＰを切り替えたことの確認を低遅延で行うことができる。

【0323】

実施の形態２と同様に、ＣＵは、同じビーム／ＴＲＰの圏内に存在しているＵＥが共通して使用するためのＳＲ用共通リソースを確保してもよい。ＵＥは、ＳＲの送信を、ＳＲ用共通リソースを用いて行ってもよい。ＳＲ用共通リソースは、ＵＥ同士の競合を許容するもの（contention-based）であってもよい。このようにすることで、ＵＥは、ＲＲＣパラメータ受信失敗時においても、ＣＵに対してビーム／ＴＲＰ切り替えを行ったことを通知することが可能となる。

【0324】

ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時における、ＳＲに関するＲＲＣパラメータの初期値を、ＳＲ用共通リソースの位置としてもよい。ＵＥは、ＳＲを、ＳＲ用共通リソースを用いて移動先ビーム／ＴＲＰに通知してもよい。このことにより、ＵＥは、通信先ビーム／ＴＲＰ切り替え後すぐにＣＵにＳＲを送信することができるので、通信先ビーム／ＴＲＰ切り替え後すぐにＣＵに上りユーザデータを送信することができる。このことにより、ビーム／ＴＲＰ切り替え時における上り通信の遅延を少なくすることができる。

【0325】

実施の形態２と同様に、ＵＥは、ＳＲＳを移動先のビーム／ＴＲＰに送信してもよい。ＳＲＳは、非周期的（Aperiodic）なものであってもよいし、周期的（Periodic）なものであってもよい。ＵＥは、ＳＲＳを予め定める回数分、移動先のビーム／ＴＲＰに送信してもよい。この送信回数は、規格で定めてもよいし、予めＣＵからＵＥに通知してもよい。このことにより、ＵＥは、ＣＵに送信する上りユーザデータがない場合においても、ＣＵに通信先ビーム／ＴＲＰ切り替えをしたことを通知することが可能となる。

【0326】

実施の形態２と同様に、ＣＵは、ＵＥにおける通信先ビーム／ＴＲＰ切り替えの有無を、前述のＳＲを用いて判断してもよい。ＣＵは、移動元ビーム／ＴＲＰから、ＳＲに関するパラメータおよび切り替え指示を再度通知してもよい。このことによって、ＵＥがＳＲに関するパラメータあるいは切り替え指示を受信し損ねることによって発生するＲＬＦあるいはランダムアクセスを防ぐことができる。それにより、ビーム／ＴＲＰ切り替えの時間を短縮することができる。

【0327】

実施の形態２と同様に、ＣＵは、ＵＥへのパラメータの通知を、複数回行ってもよい。また、ＣＵは、ＵＥへのパラメータの通知の送信電力を増加させてもよい。このことにより、パラメータ通知の信頼性を向上させることができる。

【0328】

ＵＥからのＳＲ送信について、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲを無効としてもよい。ＣＵは、ビーム／ＴＲＰ切り替えがＳＲ受信と上りスケジューリンググラント送信との間に発生するときに、ＳＲを無効としてもよい。前述において、ＵＥは、移動先ビーム／ＴＲＰにＳＲを再送してもよい。ＳＲの再送は、ＣＵからＵＥへのＲＲＣパラメータ通知を受信した後に行うとよい。このことによって、ＵＥからの再送ＳＲがＣＵにて不達となることを防ぐことができる。

【0329】

あるいは、実施の形態２と同様、ＵＥからのＳＲ送信後のビーム／ＴＲＰ切り替えについて、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲを有効としてもよい。このことによって、ビーム／ＴＲＰ切り替え発生時における上りデータ通信を円滑に行うことができる。

【0330】

ＣＵからＵＥへの上りスケジューリンググラント通知について、実施の形態２と同様、ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替えが上りスケジューリンググラントと上りユーザデータとの間に発生するときに、上りスケジューリンググラントを無効としてもよい。前述において、ＣＵは、移動先ビーム／ＴＲＰから、上りスケジューリンググラントを再送してもよい。あるいは、ＵＥは、移動先ビーム／ＴＲＰに対し、ＳＲ送信からやり直してもよい。ＳＲの再送は、ＣＵからＵＥへのＲＲＣパラメータ通知を受信した後に行うとよい。このことによって、ＵＥからの再送ＳＲがＣＵにて不達となることを防ぐことができる。

【0331】

前述において、ＣＵおよびＵＥは、前述のグラントを有効としてもよい。グラントを有効にする場合のＣＵおよびＵＥの動作は、実施の形態２と同様である。このことにより、ＣＵ、ＵＥ間のシグナリング量を削減することができる。

【0332】

前述における上りスケジューリンググラントを有効とするかどうかを、規格で定めてもよいし、あるいは、ＣＵからＵＥに通知してもよい。ｇＮＢからＵＥへの通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。上りスケジューリンググラントを有効にする場合の例として、スケジューリンググラントにて示される上りリソースを、移動先ビーム／ＴＲＰが該ＵＥに対して使用可能である場合としてもよい。前述の通知は、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、切り替え通知と併せて行ってもよい。このことにより、ＣＵは、移動先ビーム／ＴＲＰにおける上りリソース使用状況に応じたスケジューリングを、少ないシグナリングで行うことが可能となる。

【0333】

ＵＥからＣＵへの上りユーザデータ送信について、ＣＵは、移動元ビーム／ＴＲＰにてＵＥより受信した上りユーザデータに対するＡｃｋ／Ｎａｃｋを移動先ビーム／ＴＲＰからＵＥに送信してもよい。前述における移動先ビーム／ＴＲＰからのＡｃｋ／Ｎａｃｋ送信は、ビーム／ＴＲＰ切り替えがＵＥからの上りユーザデータ送信とｇＮＢからのＡｃｋ／Ｎａｃｋ通知との間に発生するときに行ってもよい。ＵＥからのＡｃｋ／Ｎａｃｋ通知は、ＣＵからＵＥへのＲＲＣパラメータ通知の前に行ってもよいし、後に行ってもよい。あるいは、Ａｃｋ／Ｎａｃｋ通知が、前述のパラメータ通知と、前述のパラメータ通知に対するＵＥからＣＵへのＡｃｋ／Ｎａｃｋ応答との間に行ってもよい。このことによって、上りユーザデータ送信後のビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0334】

本実施の形態３により、実施の形態２に示した効果に加えて、移動元ビーム／ＴＲＰとＵＥとの間の通信環境が急速に悪化する場合においても、ＣＵからＵＥに対するＲＲＣパラメータ通知を行うことができる。その結果、例えば、ＳＲの不達によるＵＥのランダムアクセス処理発生を抑えることができる。

【0335】

実施の形態２と本実施の形態３とを組み合わせて用いてもよい。すなわち、ＣＵは、ＲＲＣパラメータを移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらから送信するかを切り替えてもよい。このようにすることによって、ＣＵはＲＲＣパラメータを送信するビーム／ＴＲＰを通信環境に応じて柔軟に変えることが可能となる。

【0336】

ＲＲＣパラメータを移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらから送信するかについて、ＣＵは予めＵＥに準静的に設定してもよい。該通知には、ＲＲＣシグナリングを用いてもよい。このことにより、伝搬状況に応じてＲＲＣパラメータの通知経路を柔軟に設定することができる。

【0337】

あるいは、ＣＵから動的に設定してもよい。例えば、ＣＵは、切り替え指示にＲＲＣパラメータを移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらから送信するかを示す情報を含めてＵＥに通知してもよい。ＵＥは、該通知を用いて、ＲＲＣパラメータを受信してもよい。このようにすることによって、ＵＥは、ＲＲＣパラメータの受信先を明示的に知ることが可能になるため、ＲＲＣパラメータ通知取得の信頼性を高めることができる。

【0338】

あるいは、規格により暗黙的に決定してもよい。例えば、ＵＥは、切り替え指示受信前は移動元ビーム／ＴＲＰよりＲＲＣパラメータを受信し、切り替え指示受信後は移動先ビーム／ＴＲＰよりＲＲＣパラメータを受信するとしてもよい。このようにすることによって、ＲＲＣパラメータを移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらから受信するかを示す情報のＣＵからＵＥへの通知が不要になる。

【0339】

実施の形態３において、ＣＵとＤＵが分離されている基地局装置を例として示したが、ＣＵとＤＵが分離されていない基地局装置について適用してもよい。該基地局装置は、ビーム間でＲＲＣパラメータを共有しない基地局装置であってもよい。実施の形態３を該基地局装置に適用するにあたり、ＣＵをｇＮＢに読み替えてもよい。このようにすることで、セル内のビーム間移動においてＲＲＣパラメータをｇＮＢから移動先ビームを介してＵＥに通知することを可能とし、ビームによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ｇＮＢからＵＥにパラメータを迅速に通知することが可能となる。

【0340】

実施の形態３によれば、実施の形態２と同様に、例えば、通信端末装置と、通信端末装置と無線ビームを用いて無線通信を行う基地局装置とを含み、基地局装置によって構成されるセルは、基地局装置の配下にある複数の無線ビームによって、空間分離されており、通信端末装置が第１の無線ビームの圏内から第２の無線ビームの圏内に移動する場合、基地局装置は、通信端末装置に対して用いるＲＲＣ（Radio Resource Control）パラメータを、第１の無線ビーム用の第１のＲＲＣパラメータから、第２の無線ビーム用の第２のＲＲＣパラメータに変更する、通信システムが提供される。なお、複数の無線ビームは、図８に例示したように複数のＤＵ（言い換えるとＴＲＰ）によって形成されてもよいし、１つのＤＵによって形成されてもよいし、あるいは、ＣＵとＤＵが統合された基地局装置によって形成されてもよい。

【0341】

この構成によれば、通信端末装置に対して用いる無線ビームの変更に応じて、通信端末装置に対して用いるＲＲＣパラメータを変更する。このため、前述のように、通信端末装置の収容数を増加させることができる。

【0342】

ここで、上記構成は、前述のように、様々に変形することが可能である。特に実施の形態３によれば、例えば、基地局装置は、複数の無線ビームを出力する少なくとも１つのＤＵ（Distributed Unit）と、少なくとも１つのＤＵを制御するＣＵ（Central Unit）とを含み、ＣＵがＭＡＣ（Medium Access Control）機能を有しており、ＣＵは、第２のＲＲＣパラメータを、第２の無線ビームによって、通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、通信端末装置に通知することと、を行う、通信システムが提供される。あるいは、基地局装置は、複数の無線ビームを出力する機能およびＭＡＣ機能を有しており、基地局装置は、第２のＲＲＣパラメータを、第２の無線ビームによって、通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、通信端末装置に通知することと、を行う、通信システムが提供される。

【0343】

また、以下の変形例１～３で述べるように、様々な変形が提供される。

【0344】

実施の形態３の変形例１．
実施の形態３においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて適用してもよい。

【0345】

前述における、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータは、実施の形態２の変形例１と同じとしてもよい。

【0346】

本変形例１において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態３と同じとしてもよい。また、ＣＵが移動先ビーム／ＴＲＰを介してＵＥに通知するＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知の方法は、実施の形態３に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このようにすることで、ＵＥは通信先ビーム／ＴＲＰを切り替えた後で、前述のＲＲＣパラメータを円滑に取得することが可能となる。

【0347】

実施の形態３と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態３と同様でよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0348】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0349】

実施の形態３と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0350】

実施の形態３と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0351】

ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0352】

あるいは、ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0353】

また、切り替え通知についても、実施の形態３と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0354】

Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図１０のステップＳＴ２００３におけるＳＲに関するパラメータを、Ａｃｋ／Ｎａｃｋレペティションに関するパラメータに置き換えればよい。

【0355】

実施の形態３と同様、ＣＵはＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、Ａｃｋ／Ｎａｃｋレペティションの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0356】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからの下りユーザデータに対するＡｃｋ／Ｎａｃｋを、移動先ビーム／ＴＲＰに通知してもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋの通知は、下りユーザデータとＡｃｋ／Ｎａｃｋとの間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ処理を円滑に行うことができる。

【0357】

前述において、ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋの通知は、ＣＵからＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータ通知を受信した後に、行ってもよい。このことにより、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションによって設定される２回目以降のＡｃｋ／Ｎａｃｋを受信することが可能となるので、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋ通知の信頼性を高めることができる。

【0358】

ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションにおいて、ＣＵは、移動元ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋのみを用いてもよい。Ａｃｋ／Ｎａｃｋの利用は、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションの間にビーム／ＴＲＰが切り替わった時に行うとよい。このことによって、Ａｃｋ／Ｎａｃｋレペティションの間にビーム／ＴＲＰが切り替わる場合について、ＣＵにおけるＡｃｋ／Ｎａｃｋ受信処理を円滑に行うことができる。

【0359】

あるいは、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションにおいて、ＣＵは、移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとの両方から受信したＡｃｋ／Ｎａｃｋを有効としてもよい。前述において、ＵＥは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを受信した後で、移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティション送信を行うとよい。このことによって、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋ通知の信頼性を高めることができる。

【0360】

前述において、ＣＵが移動先ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋを用いるかについて、予め規格で定めてもよいし、ＣＵにて適宜切り替えてもよい。このことによって、例えば、伝搬環境に応じて柔軟に切り替えることで、効率的なＡｃｋ／Ｎａｃｋ受信を可能とする。

【0361】

前述において、ＣＵが移動先ビーム／ＴＲＰにて受信したＡｃｋ／Ｎａｃｋを用いるかについて、ＣＵからＵＥに通知してもよい。該通知は、ＲＲＣシグナリングを用いてもよいし、ＣＵからＵＥへの切り替え通知と併せて通知してもよい。このことによって、例えば、ＣＵが移動元ビーム／ＴＲＰのみを用いるときに、ビーム／ＴＲＰ切り替え後にＵＥはＡｃｋ／Ｎａｃｋレペティションを送信する必要がなくなるので、シグナリング量の削減が可能となる。

【0362】

ＣＵは、ＵＥから移動元ビーム／ＴＲＰに送信されたＡｃｋ／Ｎａｃｋレペティションを用いた下りユーザデータのＵＥへの再送を、移動先ビーム／ＴＲＰを介して行ってもよい。該再送は、ＵＥからＣＵへのＡｃｋ／Ｎａｃｋレペティションと、ＣＵからＵＥへの下りユーザデータの再送との間で、ビーム／ＴＲＰが切り替わった時に行ってもよい。このことによって、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ再送処理を円滑に行うことができる。

【0363】

本変形例１を用いることで、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態３と同じ効果を得ることができる。

【0364】

実施の形態３の変形例２．
実施の形態３においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＳＲＳに関するＲＲＣパラメータについて適用してもよい。

【0365】

前述における、ＳＲＳに関するＲＲＣパラメータは、実施の形態２の変形例２と同じとしてもよい。

【0366】

本変形例２において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態３と同じとしてもよい。また、ＣＵが移動先ビーム／ＴＲＰを介してＵＥに通知するＳＲＳに関するＲＲＣパラメータ通知の方法は、実施の形態３に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このようにすることで、ＵＥは通信先ビーム／ＴＲＰを切り替えた後で、前述のＲＲＣパラメータを円滑に取得することが可能となる。

【0367】

実施の形態３と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0368】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0369】

実施の形態３と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0370】

実施の形態３と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＳＲＳに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0371】

ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0372】

あるいは、ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0373】

また、切り替え通知についても、実施の形態３と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0374】

ＳＲＳに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図１０のステップＳＴ２００３におけるＳＲに関するパラメータを、ＳＲＳに関するパラメータに置き換えればよい。

【0375】

実施の形態３と同様、ＣＵはＵＥへのＳＲＳに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、ＳＲＳに関するパラメータ通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0376】

ＵＥは、移動先ビーム／ＴＲＰへのＳＲＳ送信について、ＣＵから移動先ビーム／ＴＲＰを介して送信されるＳＲＳに関するパラメータを受信した後に、行ってもよい。このことによって、ＵＥにおけるＳＲＳに関するパラメータの受信前に行う、移動先ビーム／ＴＲＰにて受信できないＳＲＳの送信を抑えることができる。

【0377】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからのＳＲＳ送信要求を有効としてもよい。前述における、ＣＵからのＳＲＳ送信要求を有効とする動作は、ＳＲＳ送信要求とＳＲＳ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ処理を円滑に行うことができる。

【0378】

あるいは、前述において、ＵＥは、ＳＲＳ送信要求を無効としてもよい。前述において、ＣＵは、移動先ビーム／ＴＲＰを介してＳＲＳ送信要求をＵＥに再送してもよい。このことによって、ＣＵは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0379】

ＵＥからＣＵへのＳＲＳ送信において、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲＳを無効としてもよい。無効とする動作は、ＵＥからＣＵへのＳＲＳ送信のあとにビーム／ＴＲＰが切り替わった時に行ってもよい。ＣＵはＵＥに、移動先ビーム／ＴＲＰを介してＳＲＳ送信要求を通知してもよい。該通知は、非周期的（Aperiodic）なＳＲＳにおいて用いてもよい。このことによって、ＣＵは、ビーム／ＴＲＰ切り替えを正しく反映した上り通信レートを用いて、ＵＥと通信を行うことができる。

【0380】

本変形例２を用いることで、ＳＲＳに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態３と同じ効果を得ることができる。

【0381】

実施の形態３の変形例３．
実施の形態３においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて適用してもよい。

【0382】

前述における、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータは、実施の形態２の変形例３と同じとしてもよい。

【0383】

本変形例３において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態３と同じとしてもよい。また、ＣＵが移動先ビーム／ＴＲＰを介してＵＥに通知するＣＱＩ／ＣＳＩに関するＲＲＣパラメータ通知の方法は、実施の形態３に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このようにすることで、ＵＥは通信先ビーム／ＴＲＰを切り替えた後で、前述のＲＲＣパラメータを円滑に取得することが可能となる。

【0384】

実施の形態３と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0385】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0386】

実施の形態３と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0387】

実施の形態３と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0388】

ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0389】

あるいは、ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0390】

また、切り替え通知についても、実施の形態３と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0391】

ＳＲＳに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図１０のステップＳＴ２００３におけるＳＲに関するパラメータを、ＣＱＩ／ＣＳＩに関するパラメータに置き換えればよい。

【0392】

実施の形態３と同様、ＣＵはＵＥへのＣＱＩ／ＣＳＩに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、ＣＱＩ／ＣＳＩに関するパラメータの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0393】

ＵＥは、移動先ビーム／ＴＲＰへのＣＱＩ／ＣＳＩ送信について、ＣＵから移動先ビーム／ＴＲＰを介して送信されるＣＱＩ／ＣＳＩに関するパラメータを受信した後に、行ってもよい。このことによって、ＵＥにおけるＣＱＩ／ＣＳＩに関するパラメータの受信前に行う、移動先ビーム／ＴＲＰにて受信できないＣＱＩ／ＣＳＩの送信を抑えることができる。

【0394】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからのＣＱＩ／ＣＳＩ送信要求を有効としてもよい。前述における、ＣＵからのＣＱＩ／ＣＳＩ送信要求を有効とする動作は、ＣＱＩ／ＣＳＩ送信要求とＣＱＩ／ＣＳＩ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ処理を円滑に行うことができる。

【0395】

あるいは、前述において、ＵＥは、ＣＱＩ／ＣＳＩ送信要求を無効としてもよい。前述において、ＣＵは、移動先ビーム／ＴＲＰを介してＣＱＩ／ＣＳＩ送信要求をＵＥに再送してもよい。このことによって、ＣＵは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0396】

ＵＥからＣＵへのＣＱＩ／ＣＳＩ送信において、ＣＵは、移動元ビーム／ＴＲＰにて受信したＣＱＩ／ＣＳＩを無効としてもよい。無効とする動作は、ＵＥからＣＵへのＣＱＩ／ＣＳＩ送信の後に、ビーム／ＴＲＰが切り替わった時に行ってもよい。ＣＵはＵＥに、移動先ビーム／ＴＲＰを介してＣＱＩ／ＣＳＩ送信要求を通知してもよい。該通知は、非周期的（Aperiodic）なＣＱＩ／ＣＳＩにおいて用いてもよい。このことによって、ＣＵは、ビーム／ＴＲＰ切り替えを正しく反映した下り通信レートを用いてＵＥと通信を行うことができる。

【0397】

本変形例３を用いることで、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態３と同じ効果を得ることができる。

【0398】

実施の形態４．
実施の形態２と異なり、例えば、ＣＵがＰＤＣＰを有し、ＤＵがＲＬＣ、ＭＡＣおよびＰＨＹを有する場合、あるいは、ＣＵがＰＤＣＰおよびＨ－ＲＬＣを有し、ＤＵがＬ－ＲＬＣ、ＭＡＣおよびＰＨＹを有する場合、セル内のビーム間移動あるいはＴＲＰ間移動においてＲＲＣシグナリングを用いてＲＲＣパラメータを通知することができる。

【0399】

ところが、ＮＲにおいて、ビームフォーミングを用いていることから、セル内のビーム／ＴＲＰ間移動が頻繁に発生する。そのため、ＲＲＣシグナリングが頻繁に発生し、通信効率が低下するといった問題が生じる。

【0400】

本実施の形態４では、このような問題を解決する方法を開示する。

【0401】

実施の形態２と同様、ＣＵからＵＥに対し、予めセル内のビームあるいはＴＲＰ（以下、ビーム／ＴＲＰと記載することがある）で使用するＲＲＣパラメータを通知する。ＣＵは該通知を、ＲＲＣシグナリングで行うとよい。ＣＵは、ビーム／ＴＲＰの切り替えにおいて、ＵＥにビーム／切り替え指示を通知する。該切り替え指示に、移動先ビーム／ＴＲＰを表す識別子を含めるとよい。ＣＵはＵＥに、該切り替え指示を、Ｌ１／Ｌ２シグナリングで通知してもよいし、ＭＡＣシグナリングで通知してもよい。このようにすることによって、ＣＵは、ビーム／ＴＲＰの切り替えに伴うパラメータ変更を少ないシグナリング量で実現することが可能となる。

【0402】

実施の形態２と同様、該通知に含まれるＲＲＣパラメータは、ＵＥが存在するビーム／ＴＲＰ近傍のものであってもよい。前述の近傍のビーム／ＴＲＰは、ＵＥが存在するビーム／ＴＲＰに隣接するビーム／ＴＲＰを含んでもよい。また、該通知に含まれるＲＲＣパラメータは、ＵＥが存在するビーム／ＴＲＰにて使用するパラメータと異なるパラメータのみで構成されていてもよい。このようにすることで、該通知のサイズを小さくすることができる。

【0403】

他の方法を開示する。ビームあるいはＴＲＰ切り替えにおいて、ＣＵは移動元ビーム／ＴＲＰを介して、ＵＥに、移動先ビーム／ＴＲＰで用いるＲＲＣパラメータを通知する。該通知にあたり、ＣＵと移動元ビーム／ＴＲＰとの間の通知に、ＣＵ－ＤＵ間インタフェースを用いてもよい。また、移動元ビーム／ＴＲＰとＵＥとの間の通知に、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。

【0404】

前述において、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知することにより、ＵＥへのパラメータ通知を迅速に行うことができる。また、ＭＡＣシグナリングを用いることにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0405】

ＣＵは、ＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0406】

あるいは、ＣＵは、ＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＣＵは、ＲＲＣパラメータの送達確認後に、切り替え指示をＵＥに通知することができる。このため、例えば、ＳＲに関するＲＲＣパラメータの不達による、ＵＥからのＳＲ不達および再送回数超過によるランダムアクセスの実行を回避することができる。

【0407】

あるいは、ＣＵは、切り替え指示の通知の後に、ＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0408】

移動元ＴＲＰは、ＣＵに対し、パラメータの送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、パラメータの通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、切り替え指示をＵＥに通知してもよい。このようにすることによって、パラメータの不達時の切り替え指示通知を防ぐことができるため、例えば、ＵＥからのＳＲ不達および再送回数超過によるランダムアクセスの実行を回避することができる。

【0409】

ＲＲＣパラメータは、実施の形態１と同様、非特許文献１２の６．３．２節に示すものであってもよい。ＲＲＣパラメータは、例えば、ＳＲに関するものであってもよいし、Ａｃｋ／Ｎａｃｋレペティション（repetition）に関するものであってもよいし、サウンディング参照信号（Sounding Reference Signal：ＳＲＳ）に関するものでもよいし、ＣＱＩ／ＣＳＩに関するものでもよい。

【0410】

実施の形態２と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。ビームスイーピングに必要なパラメータは、実施の形態１に示すものとしてもよい。該通知は、移動元ビーム／ＴＲＰを介して行ってもよい。ビームスイーピングに必要なパラメータは、移動先ビーム／ＴＲＰにおけるパラメータとしてもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0411】

実施の形態２と同様、ＣＵは、移動元ビーム／ＴＲＰを介して、ＵＥに、ビーム／ＴＲＰの切り替え指示（以下、単に「切り替え指示」という場合がある）を通知する。切り替え指示には、移動先ビーム／ＴＲＰを示す識別子を含めても、含めなくてもよい。また、切り替え指示には、ビーム／ＴＲＰを切り替えるタイミングを示す情報を含めてもよい。

【0412】

ＣＵからＵＥへの切り替え指示の通知には、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。前述において、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知することにより、ＵＥへの切り替え指示通知を迅速に行うことができる。また、ＭＡＣシグナリングを用いることにより、多値変調が可能となるので、切り替え指示を少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、切り替え指示通知の信頼性が向上する。

【0413】

移動元ＴＲＰは、ＣＵに対し、切り替え指示の送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、切り替え指示の通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、ビーム／ＴＲＰを切り替えてもよい。このようにすることによって、切り替え指示の不達時のビーム／ＴＲＰ切り替え防ぐことができるため、ＵＥのｇＮＢとのリンク喪失によるＲＬＦ発生を回避することができる。

【0414】

前述において、ＳＲに関するＲＲＣパラメータは、実施の形態２にて開示した（１）～（３）としてもよい。また、ＣＵはＵＥに対し、ＳＲに関するＲＲＣパラメータとして、ＳＲの最大再送回数を示すパラメータを通知してもよいし、通知しなくてもよい。このことによって、実施の形態２と同様の効果を得ることができる。

【0415】

実施の形態２と同様、ＣＵはＵＥに対し、ＲＲＣパラメータのうち、複数のパラメータを同時に通知してもよい。このことによって、通知に要するシグナリングの量を削減することができる。

【0416】

また、実施の形態２と同様、ＣＵはＵＥに対し、ＲＲＣパラメータを別々に通知してもよい。このことによって、少ない送信リソースにおいてもパラメータを通知することが可能となる。

【0417】

ＣＵは、ＲＲＣパラメータを移動先ビーム／ＴＲＰに通知してもよい。実施の形態１と同様、該通知には、例えば、ＣＰＲＩの制御ワードの領域を用いてもよいし、ＡＳＮ．１のフォーマットを用いてもよいし、他のフォーマットを用いてもよい。このことによって、実施の形態１と同様の効果に加え、例えば、ビーム／ＴＲＰへの切り替え直後において、移動先ビーム／ＴＲＰはＵＥからの上りユーザデータの復号を迅速に行うことができる。

【0418】

実施の形態２と同様、ＣＵは、ＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0419】

実施の形態２と同様、ＣＵは、ＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＲＲＣパラメータを保持してもよい。このようにすることで、例えば、ＵＥは、ＴＲＰ／ビーム切り替え前のＳＲ送信において、前述のパラメータ変更による移動元ＴＲＰ／ビームへのＳＲ不達を防ぐことができる。

【0420】

ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替え時に、ＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このようにすることで、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは変更前のＲＲＣパラメータを用いることができる。このため、例えば、移動先ビーム／ＴＲＰにおいて移動元ビーム／ＴＲＰと同じＲＲＣパラメータを用いている場合において、ＵＥは移動先ビーム／ＴＲＰへのＳＲ不達を防ぐことができる。

【0421】

実施の形態２と同様、ＣＵは、移動元ビーム／ＴＲＰからＵＥへの切り替え指示のＨＡＲＱ再送回数超過時に、ビーム／ＴＲＰを切り替えてもよいし、切り替えなくてもよい。それぞれの場合について、実施の形態２と同様の効果を得ることができる。

【0422】

図１１は、ＣＵから移動元ビーム／ＴＲＰを介してＳＲに関するパラメータを通知する場合のビーム／ＴＲＰ切り替えを表すシーケンス図である。図１１は、ＣＵからＵＥへ、ＳＲに関するパラメータおよび切り替え指示を、ＭＡＣシグナリングを用いて通知する例について示す。また、図１１において、ＣＵ配下の移動元ビーム／ＴＲＰをＳ－ｂｅａｍ／ＴＲＰと表記し、ＣＵ配下の移動先ビーム／ＴＲＰをＴ－ｂｅａｍ／ＴＲＰと表記している。また、図１１において、矢印の中にある黒丸は通信に用いられるビーム／ＴＲＰを示している。図９と同一のステップには同一のステップ番号を付して、共通する説明を省略する。

【0423】

図１１のステップＳＴ３００１において、ＣＵはＳ－ｂｅａｍ／ＴＲＰに対し、ＵＥに通知するＳＲパラメータを通知する。パラメータの通知には、ＣＵ－ＤＵ間インタフェースを用いてもよい。ステップＳＴ３００２において、Ｓ－ｂｅａｍ／ＴＲＰはＵＥに、前述のパラメータを通知する。パラメータのＳ－ｂｅａｍ／ＴＲＰからＵＥへの通知には、ＭＡＣシグナリングを用いる。Ｌ１／Ｌ２シグナリングを用いてもよい。ステップＳＴ３００３において、ＵＥはＳ－ｂｅａｍ／ＴＲＰに、ＳＲパラメータ通知に対するＡｃｋを通知する。Ａｃｋの通知には、上り制御信号を用いてもよい。

【0424】

図１１のステップＳＴ３００４において、ＣＵはＳ－ｂｅａｍ／ＴＲＰに対し、ＵＥに通知する切り替え指示を通知する。切り替え指示の通知には、ＣＵ－ＤＵ間インタフェースを用いてもよい。ステップＳＴ３００５において、Ｓ－ｂｅａｍ／ＴＲＰはＵＥに対し、切り替え指示を通知する。切り替え指示のＳ－ｂｅａｍ／ＴＲＰからＵＥへの通知には、ＭＡＣシグナリングを用いる。Ｌ１／Ｌ２シグナリングを用いてもよい。ステップＳＴ３００６において、ＵＥは、切り替え指示に対するＡｃｋをＳ－ｂｅａｍ／ＴＲＰに通知する。ＵＥからの受信結果がＮａｃｋであった場合、ＣＵは、Ｓ－ｂｅａｍ／ＴＲＰを介して切り替え指示を再送してもよい。

【0425】

実施の形態２と同様、ＵＥは、上り信号を移動元のビーム／ＴＲＰに送信してもよい。上り信号は、ＣＵからのパラメータの通知のＬ１／Ｌ２シグナリングに対する応答であってもよい。また、ＣＵからの切り替え指示のＬ１／Ｌ２シグナリングに対する応答であってもよい。上り信号として、応答用のＬ１／Ｌ２シグナリングを新たに設けてもよい。前述の応答として、新しい上り制御情報（ＵＣＩ）を設けてもよい。このことによって、ＣＵからのパラメータの通知あるいは切り替え指示にＬ１／Ｌ２シグナリングを用いていても、ＣＵはＵＥへの送達確認を行うことができる。それにより、前述のＬ１／Ｌ２シグナリングの信頼性を向上させることができる。

【0426】

新しいＵＣＩについては、実施の形態２と同様としてもよい。このことにより、実施の形態２と同様の効果を得ることができる。

【0427】

前述において、移動元ビーム／ＴＲＰは、ＣＵに対し、前述の応答用のＬ１／Ｌ２シグナリングを受信したことを示す情報を通知してもよい。このことにより、ＵＥがパラメータの通知、あるいは、切り替え指示を正しく受信したことを、ＣＵが把握することができる。それにより、ビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0428】

ＣＵからＵＥへの、ＭＡＣシグナリングを用いたＲＲＣパラメータ通知に関して、移動元ビーム／ＴＲＰは、ＲＲＣパラメータ通知に対してＡｃｋを受信したことを示す情報を、ＣＵに対して通知してもよい。ＣＵは、通知された情報を用いて、使用するビーム／ＴＲＰを切り替えてもよい。このことにより、ＵＥがＲＲＣパラメータ通知を正しく受信したことをＣＵが把握することができるので、ビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0429】

ＣＵからＵＥへの、ＭＡＣシグナリングを用いた切り替え指示の通知に関して、移動元ビーム／ＴＲＰは、切り替え指示の通知に対してＡｃｋを受信したことを示す情報を、ＣＵに対して通知してもよい。ＣＵは、通知された情報を用いて、使用するビーム／ＴＲＰを切り替えてもよい。このことにより、ＵＥが切り替え指示を正しく受信したことをＣＵが把握することができるので、ビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0430】

実施の形態２と同様、ＵＥは、上り信号を移動先のビーム／ＴＲＰに送信してもよい。上り信号は、ＵＥにおけるビーム／ＴＲＰ切り替えの確認用の信号としてもよい。確認用の信号を、ＳＲの周波数リソースを用いて送信してもよい。あるいは、ＳＲを、確認用の信号として送信してもよい。このことによって、ＣＵからの切り替え指示にＬ１／Ｌ２シグナリングを用いていても、ＣＵはＵＥへの送達確認を行うことができる。それにより、前述のＬ１／Ｌ２シグナリングの信頼性を向上させることができる。

【0431】

前述において、ＵＥは、ＳＲを最小の周期で送信してもよい。このことにより、ＵＥが通信先のビーム／ＴＲＰを切り替えたことの確認を低遅延で行うことができる。

【0432】

前述において、ＣＵは、同じビーム／ＴＲＰの圏内に存在しているＵＥが共通して使用するためのＳＲ用共通リソースを確保してもよい。ＵＥは、ＳＲの送信を、ＳＲ用共通リソースを用いて行ってもよい。ＳＲ用共通リソースは、ＵＥ同士の競合を許容するもの（contention-based）であってもよい。ＳＲ用共通リソースの位置は、予め規格で定めてもよいし、ＣＵが配下のＵＥに通知してもよい。この通知は、報知であってもよいし、ＵＥ個別の通知であってもよい。前述における、ＵＥ個別の通知は、ＲＲＣ個別シグナリングであってもよい。このようにすることで、ＵＥは、ＲＲＣパラメータ受信失敗時においても、ＣＵに対してビーム／ＴＲＰ切り替えを行ったことを通知することが可能となる。

【0433】

実施の形態２と同様、ＵＥは、ＳＲ共通リソースの位置を、前述の、通信先ビーム／ＴＲＰ切り替え時におけるＳＲに関するＲＲＣパラメータの初期値としてもよい。このようにすることで、ＵＥは、ＲＲＣパラメータ受信失敗時においても、ＣＵに対してビーム／ＴＲＰ切り替えを行ったことを通知することが可能となる。

【0434】

前述において、ＵＥは、ＳＲＳを移動先のビーム／ＴＲＰに送信してもよい。ＳＲＳは、非周期的（Aperiodic）なものであってもよいし、周期的（Periodic）なものであってもよい。ＵＥは、ＳＲＳを予め定める回数分、移動先のビーム／ＴＲＰに送信してもよい。この送信回数は、規格で定めてもよいし、予めＣＵからＵＥに通知してもよい。この通知はＲＲＣシグナリングを用いて行ってもよい。このことにより、ＵＥは、ＣＵに送信する上りユーザデータがない場合においても、ＣＵに通信先ビーム／ＴＲＰ切り替えをしたことを通知することが可能となる。

【0435】

実施の形態２と同様、ＣＵは、ＵＥにおける通信先ビーム／ＴＲＰ切り替えの有無を、前述のＳＲを用いて判断してもよい。例えば、ＣＵは、ＵＥからＳＲ通知がない場合に、ＵＥが通信先ビーム／ＴＲＰを切り替えていないと判断してもよい。ＣＵは、移動元ビーム／ＴＲＰから、パラメータおよび切り替え指示を再度通知してもよい。この再度の通知は、前述の判断結果を用いて行ってもよい。このことによって、例えば、ＵＥがＳＲに関するパラメータあるいは切り替え指示を受信し損ねることによって発生するＲＬＦあるいはランダムアクセスを防ぐことができる。それにより、ビーム／ＴＲＰ切り替えの時間を短縮することができる。

【0436】

実施の形態２と同様、ＣＵは、ＵＥへのパラメータの通知を、複数回行ってもよい。あるいは、ＣＵは、ＵＥへのパラメータの通知の送信電力を増加させてもよい。このことにより、パラメータ通知の信頼性を向上させることができる。パラメータ通知の回数は、規格で定めてもよいし、予めＣＵよりＵＥに通知してもよい。この通知は、ＲＲＣシグナリングを用いて行ってもよい。

【0437】

実施の形態２と同様、ＵＥへの切り替え指示通知についても、パラメータの通知と同様、複数回送信してもよいし、電力を増加させてもよい。このことにより、切り替え指示通知の信頼性を向上させることができる。

【0438】

実施の形態２と同様、ＵＥは、ＣＵより受信したパラメータの通知を用いて、通信先のビーム切り替えを行ってもよい。ビーム切り替えは、ビームスイーピングおよびランダムアクセスを伴ってもよい。ビーム切り替えは、パラメータのうち１つ以上の受信を用いて行ってもよい。ビーム切り替えは、ＵＥがパラメータを１つ以上受信してから、予め定める時間が経過してから行ってもよい。前述の予め定める時間は、規格で定めてもよいし、予めＣＵよりＵＥに通知してもよい。この通知は、ＲＲＣシグナリングを用いて行ってもよい。このことによって、ＣＵからＵＥへの切り替え指示をＵＥが正しく受信できない場合においても、ＵＥは通信先のビームを切り替えることが可能となる。また、ＣＵからＵＥへの切り替え通知の再送に要する時間が不要となる。

【0439】

ＵＥからのＳＲ送信について、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲを無効としてもよい。ＣＵは、ビーム／ＴＲＰ切り替えがＳＲ受信と上りスケジューリンググラント送信との間に発生するときに、ＳＲを無効としてもよい。前述において、ＵＥは、移動先ビーム／ＴＲＰにＳＲを再送してもよい。このことによって、ＵＥからの再送ＳＲがＣＵにて不達となることを防ぐことができる。

【0440】

あるいは、前述の、ＵＥからのＳＲ送信後のビーム／ＴＲＰ切り替えについて、ＣＵは、移動元ビーム／ＴＲＰにて受信したＳＲを有効としてもよい。移動元ビーム／ＴＲＰは、ＳＲを移動先ビーム／ＴＲＰに転送してもよい。この転送は、ＣＵを経由してもよい。前述において、ＳＲの代わりに、ＳＲを受信したことを示す情報を用いてもよい。このようにすることによって、ビーム／ＴＲＰ切り替えがＳＲ受信と上りスケジューリンググラント送信との間に発生するときにおいても、ＵＥにおける、ＳＲ送信と、上りスケジューリンググラント受信と、上りユーザデータ送信とを含む一連の流れを円滑に行うことができる。

【0441】

ＣＵからＵＥへの上りスケジューリンググラント通知について、ＣＵおよびＵＥは、移動元ビーム／ＴＲＰから送信された上りスケジューリンググラントを無効としてもよい。ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替えが上りスケジューリンググラントと上りユーザデータとの間に発生するときに、上りスケジューリンググラントを無効としてもよい。前述において、移動先ビーム／ＴＲＰはＵＥに、上りスケジューリンググラントを再送してもよい。前述の上りスケジューリンググラントの再送において、移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、ＵＥに対する上りスケジューリンググラントの再送を要求してもよい。あるいは、ＵＥは、移動先ビーム／ＴＲＰに対し、ＳＲ送信からやり直してもよい。前述において、ＵＥがＳＲ送信からやり直すかどうかについて、規格で定めてもよい。あるいは、ＣＵからＵＥに通知してもよい。前述の通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。前述の通知は、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、切り替え通知と併せて行ってもよい。このことにより、ＵＥは、上りユーザデータ送信に用いる移動先ビーム／ＴＲＰの上りリソース使用状況に応じた上りスケジューリンググラントを受信することが可能となる。

【0442】

あるいは、前述の、移動元ビーム／ＴＲＰからＵＥへの上りスケジューリンググラント通知後のビーム／ＴＲＰ切り替えについて、ＣＵおよびＵＥは、移動元ビーム／ＴＲＰから送信された上りスケジューリンググラントを有効としてもよい。移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、上りスケジューリンググラントについての情報を通知してもよい。ＵＥは、上りスケジューリンググラントを用いて、移動先ビーム／ＴＲＰに上りユーザデータを送信してもよい。このことにより、ＣＵ、ＵＥ間のシグナリング量を削減することができる。

【0443】

前述における上りスケジューリンググラントを有効とするかどうかを、規格で定めてもよいし、あるいは、ＣＵからＵＥに通知してもよい。ｇＮＢからＵＥへの通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。上りスケジューリンググラントを有効にする場合の例として、スケジューリンググラントにて示される上りリソースを、移動先ビーム／ＴＲＰが該ＵＥに対して使用可能である場合としてもよい。移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、上りスケジューリンググラントについての情報を通知してもよい。このことにより、移動先ビーム／ＴＲＰは、上りスケジューリンググラントを有効にするか無効にするかを判断することができるようになるので、柔軟なスケジューリングが可能となる。

【0444】

前述の通知をＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、前述の通知を切り替え通知と併せて行ってもよい。このことにより、ＣＵは、移動先ビーム／ＴＲＰにおける上りリソース使用状況に応じたスケジューリングを、少ないシグナリングで行うことが可能となる。

【0445】

ＵＥからＣＵへの上りユーザデータ送信について、移動先ビーム／ＴＲＰは、移動元ビーム／ＴＲＰがＵＥから受信した上りユーザデータに対するＡｃｋ／Ｎａｃｋを、ＵＥに送信してもよい。前述における移動先ビーム／ＴＲＰからＵＥへのＡｃｋ／Ｎａｃｋ送信は、ビーム／ＴＲＰ切り替えがＵＥからの上りユーザデータ送信と上りユーザデータに対するＡｃｋ／Ｎａｃｋ通知との間に発生するときに行ってもよい。前述において、移動元ビーム／ＴＲＰは、上りユーザデータに対するＡｃｋ／Ｎａｃｋを示す情報を、移動先ビーム／ＴＲＰに通知してもよい。このことによって、上りユーザデータ送信後のビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0446】

また、移動元ビーム／ＴＲＰは、ＵＥから受信した上りユーザデータの復号結果に関する情報を、移動先ビーム／ＴＲＰに通知してもよい。この情報は、例えば、上りユーザデータの軟判定値であってもよい。このことによって、移動先ビーム／ＴＲＰは、上りユーザデータの初送受信結果と再送受信結果とを合成して復号することができる。それにより、受信エラーとなる確率を低くすることができる。

【0447】

本実施の形態４により、ＣＵがＰＤＣＰを有し、ＤＵがＲＬＣ、ＭＡＣおよびＰＨＹを有する場合、あるいは、ＣＵがＰＤＣＰおよびＨ－ＲＬＣを有し、ＤＵがＬ－ＲＬＣ、ＭＡＣおよびＰＨＹを有する場合についても、実施の形態２と同じ効果を得ることができる。また、前述の場合において、ビーム／ＴＲＰ間のシグナリング量を削減することができる。

【0448】

実施の形態４において、ＣＵとＤＵが分離されている基地局装置を例として示したが、ＣＵとＤＵが分離されていない基地局装置について適用してもよい。該基地局装置は、ビーム間でＲＲＣパラメータを共有しない基地局装置であってもよい。また、該基地局装置は、例えば、ビーム毎に異なるＨＡＲＱスケジューリングを行う基地局装置であってもよいし、ビーム毎に異なるＲＬＣレイヤを有する基地局装置であってもよいし、前述の両方を組み合わせたものであってもよい。実施の形態４を該基地局装置に適用するにあたり、ＣＵをｇＮＢに読み替えてもよい。このようにすることで、セル内のビーム間移動においてＲＲＣパラメータをｇＮＢから移動元ビームを介してＵＥに通知することを可能とし、ビームによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ｇＮＢからＵＥにパラメータを迅速に通知することが可能となる。

【0449】

また、実施の形態４において、移動元ビーム／ＴＲＰよりＲＲＣパラメータをＵＥに通知する基地局装置を例として示したが、他のビーム／ＴＲＰよりＲＲＣパラメータを通知してもよい。前述の、他のビーム／ＴＲＰは、例えば、制御情報送信用のビーム／ＴＲＰであってもよい。このようにすることで、例えば、ユーザデータ送受信用と制御情報送受信用のビーム／ＴＲＰが存在する基地局装置において、ＲＲＣパラメータを少ないシグナリング量で通知することが可能となるため、ビーム移動におけるＲＲＣパラメータ通知を迅速に行うことが可能となる。

【0450】

実施の形態４によれば、実施の形態２と同様に、例えば、通信端末装置と、通信端末装置と無線ビームを用いて無線通信を行う基地局装置とを含み、基地局装置によって構成されるセルは、基地局装置の配下にある複数の無線ビームによって、空間分離されており、通信端末装置が第１の無線ビームの圏内から第２の無線ビームの圏内に移動する場合、基地局装置は、通信端末装置に対して用いるＲＲＣ（Radio Resource Control）パラメータを、第１の無線ビーム用の第１のＲＲＣパラメータから、第２の無線ビーム用の第２のＲＲＣパラメータに変更する、通信システムが提供される。なお、複数の無線ビームは、図８に例示したように複数のＤＵ（言い換えるとＴＲＰ）によって形成されてもよいし、１つのＤＵによって形成されてもよいし、あるいは、ＣＵとＤＵが統合された基地局装置によって形成されてもよい。

【0451】

この構成によれば、通信端末装置に対して用いる無線ビームの変更に応じて、通信端末装置に対して用いるＲＲＣパラメータを変更する。このため、前述のように、通信端末装置の収容数を増加させることができる。

【0452】

ここで、上記構成は、前述のように、様々に変形することが可能である。特に実施の形態４によれば、例えば、基地局装置は、複数の無線ビームを出力する少なくとも１つのＤＵ（Distributed Unit）と、少なくとも１つのＤＵを制御するＣＵ（Central Unit）とを含み、少なくとも１つのＤＵがＭＡＣ（Medium Access Control）機能を有しており、ＣＵは、第２のＲＲＣパラメータを、第１の無線ビームによって、Ｌ１／Ｌ２シグナリングまたはＭＡＣシグナリングを用いて、通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、Ｌ１／Ｌ２シグナリングまたはＭＡＣシグナリングを用いて、通信端末装置に通知することと、を行う、通信システムが提供される。前述において、ＤＵは、ＲＬＣ（Radio Link Control）機能を有していてもよい。また、他の例として、基地局装置は、複数の無線ビームを出力する機能、ＭＡＣ機能を有しており、基地局装置は、第２のＲＲＣパラメータを通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、通信端末装置に通知することと、を行う、通信システムが提供される。

【0453】

また、以下の変形例１～４で述べるように、様々な変形が提供される。

【0454】

実施の形態４の変形例１．
実施の形態４においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて適用してもよい。

【0455】

前述における、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータは、実施の形態２の変形例１と同じとしてもよい。

【0456】

本変形例１において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態４と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知するＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知の方法は、実施の形態４に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0457】

実施の形態４と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態４と同様でよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0458】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0459】

実施の形態４と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前のＡｃｋ／Ｎａｃｋ送信において、パラメータ変更による移動元ＴＲＰ／ビームへのＡｃｋ／Ｎａｃｋ送信の信頼性低下を防ぐことができる。

【0460】

実施の形態４と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0461】

実施の形態４と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0462】

実施の形態４と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0463】

あるいは、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＵＥにおいてビーム／ＴＲＰ切り替え後に変更前のパラメータが適用されることを回避することが可能となり、ＵＥからの反復Ａｃｋ／Ｎａｃｋ不達をもたらすこと、および、ＵＥからの反復Ａｃｋ／Ｎａｃｋ不達がＡｃｋ／Ｎａｃｋ通知の信頼性を低下させることを、回避することができる。

【0464】

あるいは、ＣＵは、切り替え指示の通知の後に、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて、切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0465】

ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0466】

あるいは、ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0467】

実施の形態４と同様、移動元ＴＲＰは、ＣＵに対し、パラメータの送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、パラメータの通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、切り替え指示をＵＥに通知してもよい。このようにすることによって、パラメータの不達によるＵＥからの反復Ａｃｋ／Ｎａｃｋ不達を回避し、Ａｃｋ／Ｎａｃｋ送信の信頼性を高めることができる。

【0468】

また、切り替え通知についても、実施の形態４と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0469】

Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図１１のステップＳＴ３００１およびＳＴ３００２におけるＳＲに関するパラメータを、Ａｃｋ／Ｎａｃｋレペティションに関するパラメータに置き換えればよい。

【0470】

実施の形態４と同様、ＣＵはＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、パラメータの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0471】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからの下りユーザデータに対するＡｃｋ／Ｎａｃｋの通知を、移動元ビーム／ＴＲＰに対しても移動先ビーム／ＴＲＰに対しても行わなくてもよい。前述のＵＥの動作は、下りユーザデータとＡｃｋ／Ｎａｃｋとの間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。移動元ビーム／ＴＲＰは、前述の下りユーザデータを移動先ビーム／ＴＲＰに転送してもよい。移動先ビーム／ＴＲＰは、前述の下りユーザデータをＵＥに送信してもよい。このようにすることによって、ビーム／ＴＲＰ切り替えによる下りユーザデータの欠落を防ぐことができる。

【0472】

他の例として、ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからの下りユーザデータに対するＡｃｋ／Ｎａｃｋの通知を、移動先ビーム／ＴＲＰに対して行ってもよい。前述のＡｃｋ／Ｎａｃｋの通知は、下りユーザデータとＡｃｋ／Ｎａｃｋとの間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。移動先ビーム／ＴＲＰは、前述のＡｃｋ／Ｎａｃｋ受信結果を移動元ビーム／ＴＲＰに通知してもよい。このようにすることによって、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータに関するシグナリング量を削減することができる。

【0473】

前述において、移動元ビーム／ＴＲＰは、前述の下りユーザデータを移動先ビーム／ＴＲＰに転送してもよい。前述の転送は、下りユーザデータに対してＵＥからＮａｃｋの通知を受信したときに行ってもよい。移動先ビーム／ＴＲＰは、転送された下りユーザデータを用いてＵＥに再送を行ってもよい。このようにすることによって、ビーム／ＴＲＰ切り替えにおける下りユーザデータの再送処理を円滑に行うことができる。

【0474】

移動元ビーム／ＴＲＰは、ＵＥから受信したＡｃｋ／Ｎａｃｋの判断について、自ビーム／ＴＲＰにおける受信結果のみを用いてもよいし、移動先ビーム／ＴＲＰにおける受信結果と併せて用いてもよい。移動先ビーム／ＴＲＰは、ＵＥからのＡｃｋ／Ｎａｃｋ受信結果を移動元ビーム／ＴＲＰに転送してもよい。前述の動作は、ＵＥから移動元ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティションの間にビーム／ＴＲＰが切り替わった時に行うとよい。移動元ビーム／ＴＲＰにおける受信結果のみを用いることによって、ＵＥからのＡｃｋ／Ｎａｃｋレペティションの受信動作を迅速に行うことができる。移動先ビーム／ＴＲＰにおける受信結果と併せて用いることによって、移動元ビーム／ＴＲＰにおけるＡｃｋ／Ｎａｃｋレペティションの信頼性を高めることができる。移動元ビーム／ＴＲＰが自ビーム／ＴＲＰにおける受信結果のみを用いるか、移動先ビーム／ＴＲＰにおける受信結果と併せて用いるかについて、規格で定めてもよいし、ＣＵにて適宜切り替えてもよい。ＣＵにて適宜切り替えることにより、例えば、移動元ビーム／ＴＲＰにおける伝搬状況に応じて適切な受信動作を選択することができるため、ｇＮＢにおけるＡｃｋ／Ｎａｃｋレペティションの受信処理の柔軟性を高めることができる。

【0475】

前述において、移動元ビーム／ＴＲＰの代わりに移動先ビーム／ＴＲＰがＡｃｋ／Ｎａｃｋレペティションの受信処理を行ってもよい。移動先ビーム／ＴＲＰは、自ビーム／ＴＲＰにおける受信結果のみを用いてもよいし、移動元ビーム／ＴＲＰにおける受信結果と併せて用いてもよい。移動元ビーム／ＴＲＰは、ＵＥからのＡｃｋ／Ｎａｃｋ受信結果を移動元ビーム／ＴＲＰに転送してもよい。このようにすることによって、前述と同様の効果を得ることができる。移動先ビーム／ＴＲＰが自ビーム／ＴＲＰにおける受信結果のみを用いるか、移動先ビーム／ＴＲＰにおける受信結果と併せて用いるかについて、規格で定めてもよいし、ＣＵにて適宜切り替えてもよい。

【0476】

前述において、Ａｃｋ／Ｎａｃｋ受信動作を移動元ビーム／ＴＲＰ、移動先ビーム／ＴＲＰのどちらが行うか、規格で定めてもよいし、予めＣＵが決定してもよい。このようにすることによって、移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとの間におけるＡｃｋ／Ｎａｃｋの受信結果の齟齬による誤動作を防ぐことができる。

【0477】

移動先ビーム／ＴＲＰは、ＵＥから移動元ビーム／ＴＲＰに送信されたＡｃｋ／Ｎａｃｋレペティションを用いた下りユーザデータのＵＥへの再送を行ってもよい。該再送は、ＵＥから移動元ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティションと、ＵＥへの下りユーザデータの再送との間で、ビーム／ＴＲＰが切り替わった時に行ってもよい。移動元ビーム／ＴＲＰは移動先ビーム／ＴＲＰに、再送データを転送してもよい。このことによって、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ再送処理を円滑に行うことができる。

【0478】

本変形例１を用いることで、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態４と同じ効果を得ることができる。

【0479】

実施の形態４の変形例２．
実施の形態４においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＳＲＳに関するＲＲＣパラメータについて適用してもよい。

【0480】

前述における、ＳＲＳに関するＲＲＣパラメータは、実施の形態２の変形例２と同じとしてもよい。

【0481】

本変形例２において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態４と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知するＳＲＳに関するＲＲＣパラメータ通知の方法は、実施の形態４に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0482】

実施の形態４と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態４と同様でよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0483】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0484】

実施の形態４と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＳＲＳに関するＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前のＳＲＳ送信において、ＳＲＳ不達によって発生するランダムアクセス動作および上り通信レート低下を防ぐことができる。

【0485】

実施の形態４と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0486】

実施の形態４と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＳＲＳに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0487】

実施の形態４と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0488】

あるいは、ＣＵは、ＳＲＳに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＵＥにおいてビーム／ＴＲＰ切り替え後に変更前のＳＲＳに関するＲＲＣパラメータが適用されることを回避することが可能となり、ＵＥからのＳＲＳ不達をもたらすこと、および、ＵＥからのＳＲＳ不達がランダムアクセス動作を発生させ、上り通信レートを低下させることを、回避することができる。

【0489】

あるいは、ＣＵは、切り替え指示の通知の後に、ＳＲＳに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて、切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0490】

ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0491】

あるいは、ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0492】

実施の形態４と同様、移動元ＴＲＰは、ＣＵに対し、パラメータの送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、パラメータの通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、切り替え指示をＵＥに通知してもよい。このようにすることによって、パラメータの不達によるＵＥからのＳＲＳ不達を回避し、ランダムアクセス動作の発生および上り通信レートの低下を防ぐことができる。

【0493】

また、切り替え通知についても、実施の形態４と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0494】

ＳＲＳに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図１１のステップＳＴ３００１およびＳＴ３００２におけるＳＲに関するパラメータを、ＳＲＳに関するパラメータに置き換えればよい。

【0495】

実施の形態４と同様、ＣＵはＵＥへのＳＲＳに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、パラメータ通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0496】

ＵＥは、移動元ビーム／ＴＲＰから受信したＳＲＳ送信指示に対するＳＲＳ送信を、移動先ビーム／ＴＲＰに対して行ってもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＳＲＳ送信は、ＳＲＳ送信指示とＳＲＳ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。また、前述におけるＳＲＳ送信は、非周期的（Aperiodic）なＳＲＳ送信について行ってもよい。移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、ＵＥに対してＳＲＳ送信を指示したことを通知してもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときのＳＲＳ送信処理を円滑に行うことができる。

【0497】

前述において、ＵＥは、移動元ビーム／ＴＲＰから受信したＳＲＳ送信指示を無効としてもよい。このようにすることによって、移動元ビーム／ＴＲＰから移動先ビーム／ＴＲＰに対するシグナリングを削減することができる。

【0498】

移動元ビーム／ＴＲＰは、ＵＥから自ビームに送信したＳＲＳを無効としてもよい。ＳＲＳを無効とする動作は、ＳＲＳ送信の後にビーム／ＴＲＰが切り替わったときに行うとよい。このことによって、移動先ビーム／ＴＲＰは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0499】

本変形例２を用いることで、ＳＲＳに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態４と同じ効果を得ることができる。

【0500】

実施の形態４の変形例３．
実施の形態４においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて適用してもよい。

【0501】

前述における、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータは、実施の形態２の変形例３と同じとしてもよい。

【0502】

本変形例３において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態４と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知するＣＱＩ／ＣＳＩに関するＲＲＣパラメータ通知の方法は、実施の形態４に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0503】

実施の形態４と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態４と同様でよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0504】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0505】

実施の形態４と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを保持してもよい。このようにすることで、ＵＥは、ＴＲＰ／ビーム切り替え前のＣＱＩ／ＣＳＩ送信において、ＣＱＩ／ＣＳＩ不達によって発生する下り通信レート低下を防ぐことができる。

【0506】

実施の形態４と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0507】

ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＲＲＣパラメータの初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0508】

実施の形態４と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよい。このことにより、ビーム／ＴＲＰ切り替えにおけるシグナリング量を削減することができる。

【0509】

あるいは、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。このことにより、ＵＥにおいてビーム／ＴＲＰ切り替え後に変更前のＣＱＩ／ＣＳＩに関するＲＲＣパラメータが適用されることを回避することが可能となり、ＵＥからのＣＱＩ／ＣＳＩ不達をもたらすこと、および、ＵＥからのＣＱＩ／ＣＳＩ不達が下り通信レートを低下させることを、回避することができる。

【0510】

あるいは、ＣＵは、切り替え指示の通知の後に、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて、切り替えタイミングをＵＥに通知するとよい。このことにより、ＵＥにおいて通信先のビーム／ＴＲＰを切り替える処理に時間を要する場合についても、円滑な切り替えを可能とする。

【0511】

ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0512】

あるいは、ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0513】

実施の形態４と同様、移動元ＴＲＰは、ＣＵに対し、パラメータの送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、パラメータの通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、切り替え指示をＵＥに通知してもよい。このようにすることによって、パラメータの不達によるＵＥからのＣＱＩ／ＣＳＩ不達を回避し、下り通信レートの低下を防ぐことができる。

【0514】

また、切り替え通知についても、実施の形態４と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0515】

ＣＱＩ／ＣＳＩに関するＲＲＣパラメータ通知および切り替え指示のシーケンスの一例として、図１１のステップＳＴ３００１およびＳＴ３００２におけるＳＲに関するパラメータを、ＣＱＩ／ＣＳＩに関するパラメータに置き換えればよい。

【0516】

実施の形態４と同様、ＣＵはＵＥへのＣＱＩ／ＣＳＩに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、パラメータ通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0517】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＱＩ／ＣＳＩ送信指示に対するＣＱＩ／ＣＳＩ送信を、移動先ビーム／ＴＲＰに対して行ってもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＣＱＩ／ＣＳＩ送信は、ＣＱＩ／ＣＳＩ送信指示とＣＱＩ／ＣＳＩ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。また、前述におけるＣＱＩ／ＣＳＩ送信は、非周期的（Aperiodic）なＣＱＩ／ＣＳＩ送信について行ってもよい。移動元ビーム／ＴＲＰは、ＵＥにＣＱＩ／ＣＳＩ送信指示を行ったことを示す情報を、移動先ビーム／ＴＲＰに対して通知してもよい。このことにより、移動元ビーム／ＴＲＰ、移動先ビーム／ＴＲＰおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときのＣＱＩ／ＣＳＩ送信処理を円滑に行うことができる。

【0518】

移動元ビーム／ＴＲＰは、ＵＥから自ビームに送信したＣＱＩ／ＣＳＩを無効としてもよい。ＣＱＩ／ＣＳＩを無効とする動作は、ＣＱＩ／ＣＳＩ送信の後にビーム／ＴＲＰが切り替わったときに行うとよい。移動元ビーム／ＴＲＰは、ＵＥにＣＱＩ／ＣＳＩ送信指示を行ったことを示す情報を、移動先ビーム／ＴＲＰに対して通知してもよい。移動先ビーム／ＴＲＰはＵＥに、ＣＱＩ／ＣＳＩ送信指示を再送してもよい。ＵＥは、移動先ビーム／ＴＲＰに対してＣＱＩ／ＣＳＩを再送してもよい。このことによって、移動先ビーム／ＴＲＰは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0519】

本変形例３を用いることで、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態４と同じ効果を得ることができる。

【0520】

実施の形態４の変形例４．
実施の形態４においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＲＬＣに関するＲＲＣパラメータについて適用してもよい。

【0521】

前述における、ＲＬＣに関するＲＲＣパラメータとして、以下の（１）～（８）を示す。

【0522】

（１）ＲＬＣ ＰＤＵの再送要否を判断するためのタイマ。例えば、非特許文献１２に記載のＴ－ＰｏｌｌＲｅｔｒａｎｓｍｉｔ。

【0523】

（２）ＲＬＣの送信側エンティティが受信側エンティティにポーリング（Polling）を送る間隔として用いるＲＬＣ ＰＤＵ個数。例えば、非特許文献１２に記載のＰｏｌｌＰＤＵ。

【0524】

（３）ＲＬＣの送信側エンティティが受信側エンティティにポーリング（Polling）を送る間隔として用いるＲＬＣ ＰＤＵデータ量。例えば、非特許文献１２に記載のＰｏｌｌＢｙｔｅ。

【0525】

（４）ＲＬＣのＡＲＱにおける最大再送回数。例えば、非特許文献１２に記載のｍａｘＲｅｔｘＴｈｒｅｓｈｏｌｄ。

【0526】

（５）ＲＬＣ ＰＤＵのリオーダリングに用いるタイマ。例えば、非特許文献１２に記載のＴ－ｒｅｏｒｄｅｒｉｎｇ。

【0527】

（６）ＲＬＣ ステータスＰＤＵの最小送信間隔。例えば、非特許文献１２に記載のＴ－ＳｔａｔｕｓＰｒｏｈｉｂｉｔ。

【0528】

（７）ＲＬＣ ＰＤＵのシーケンス番号のサイズ。例えば、非特許文献１２に記載のＳＮ－ＦｉｅｌｄＬｅｎｇｔｈ。

【0529】

（８）前述の（１）～（７）の組み合わせ。

【0530】

前述の（１）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいて、ＲＬＣ ＰＤＵの再送要否を判断するためのタイマの値を小さくすることによって、ＵＥとＣＵの間の通信における遅延を小さくすることができる。

【0531】

前述の（２）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいてポーリング間のＲＬＣ ＰＤＵ個数を小さくすることによって、ＵＥとＣＵの間の通信における遅延を小さくすることができる。

【0532】

前述の（３）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいてポーリング間のＲＬＣ ＰＤＵサイズを小さくすることによって、ＵＥとＣＵの間の通信における遅延を小さくすることができる。

【0533】

前述の（４）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいてＲＬＣＰＤＵの最大再送回数を大きくすることによって、ＲＬＣ ＰＤＵ送受信の信頼性を高めることができる。

【0534】

前述の（５）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいてリオーダリングに用いるタイマの値を大きくすることによって、ＲＬＣ ＰＤＵの欠落を防ぐことができる。

【0535】

前述の（６）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいてステータスＰＤＵの送信間隔を短くすることによって、低遅延、かつ、高信頼性な通信を確保することができる。

【0536】

前述の（７）によれば、例えば、伝搬環境が不安定なビーム／ＴＲＰにおいてシーケンス番号のサイズを大きくすることによって、ＲＬＣ ＰＤＵの欠落を防ぐことができる。

【0537】

本変形例１において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態４と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知するＲＬＣに関するＲＲＣパラメータ通知の方法は、実施の形態４に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0538】

実施の形態４と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態４と同様でよい。このようにすることで、実施の形態４と同様の効果を得ることができる。

【0539】

ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0540】

実施の形態４と同様、ＣＵは、ＲＬＣに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＲＬＣに関するＲＲＣパラメータを保持し、ＴＲＰ／ビーム切り替え後に変更後のパラメータを用いてもよい。このようにすることで、ＴＲＰ／ビーム切り替え前において、ＲＬＣに関するＲＲＣパラメータの変更に伴って発生するＵＥおよび移動元ビーム／ＴＲＰのＲＬＣ再構築を防ぐことができ、それに伴う通信ロスを防ぐことができる。

【0541】

実施の形態４と同様、ＣＵは、ＲＬＣに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0542】

実施の形態４と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＲＬＣに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。該初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。前述において、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよいし、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0543】

実施の形態４と同様、ＣＵは、ＲＬＣに関するＲＲＣパラメータと切り替え指示とを一緒にＵＥに通知してもよいし、ＲＬＣに関するＲＲＣパラメータの通知後に、切り替え指示をＵＥに通知してもよい。あるいは、ＣＵは、切り替え指示の通知の後に、ＲＬＣに関するＲＲＣパラメータをＵＥに通知してもよい。この場合において、ＣＵは、切り替え指示と併せて、切り替えタイミングをＵＥに通知するとよい。このことにより実施の形態４と同様の効果を得ることができる。

【0544】

ＣＵは、前述のＲＬＣに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0545】

あるいは、ＣＵは、前述のＲＬＣに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0546】

実施の形態４と同様、移動元ＴＲＰは、ＣＵに対し、パラメータの送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、パラメータの通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、切り替え指示をＵＥに通知してもよい。このようにすることによって、パラメータの不達によるＲＬＣの誤動作を防ぐことができる。

【0547】

また、切り替え通知についても、実施の形態４と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0548】

実施の形態４と同様、ＣＵはＲＬＣに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、パラメータの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0549】

ＣＵおよびＵＥは、切り替え指示の通知とともにユーザデータの送受信を止めてもよい。ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替え完了後にユーザデータの送受信を再開してもよい。このようにすることによって、ＲＬＣ再構築によるデータの欠落を防ぐことができる。

【0550】

本変形例４を用いることで、ＲＬＣに関するＲＲＣパラメータのＵＥへの通知を迅速に行うことができる。また、ビーム／ＴＲＰの伝搬環境に応じて適切な値を設定可能となるため、ＲＬＣレイヤにおける通信の遅延が低減し、かつ、信頼性が向上する。

【0551】

実施の形態５．
実施の形態４においては、例えば、ＣＵがＰＤＣＰを有し、ＤＵがＲＬＣ、ＭＡＣおよびＰＨＹを有する場合、あるいは、ＣＵがＰＤＣＰおよびＨ－ＲＬＣを有し、ＤＵがＬ－ＲＬＣ、ＭＡＣおよびＰＨＹを有する場合において、移動元ビーム／ＴＲＰからＲＲＣパラメータをＵＥに通知することを示した。前述の場合について、移動先ビーム／ＴＲＰからＲＲＣパラメータをＵＥに通知してもよい。

【0552】

移動先ビーム／ＴＲＰは、ＲＲＣパラメータをＵＥに通知する。移動元ビーム／ＴＲＰは、ＵＥへの切り替え指示を通知する。

【0553】

移動先ビーム／ＴＲＰからＵＥへのＲＲＣパラメータの通知は、移動元ビーム／ＴＲＰからＵＥへの切り替え通知の後に行うとよい。このようにすることで、ＵＥは通信先ビーム／ＴＲＰを切り替えた後で、ＲＲＣパラメータを円滑に取得することが可能となる。

【0554】

ＲＲＣパラメータは、実施の形態２と同様、非特許文献１２の６．３．２節に示すものであってもよい。ＲＲＣパラメータは、例えば、ＳＲに関するものであってもよいし、Ａｃｋ／Ｎａｃｋレペティション（repetition）に関するものであってもよいし、サウンディング参照信号（Sounding Reference Signal：ＳＲＳ）に関するものでもよいし、ＣＱＩ／ＣＳＩに関するものでもよい。

【0555】

前述における、ＳＲに関するＲＲＣパラメータは、実施の形態２において（１）～（３）に示したものであってもよい。また、実施の形態２と同様、ＣＵはＵＥに対し、ＳＲに関するＲＲＣパラメータとして、ＳＲの最大再送回数を示すパラメータを通知してもよいし、通知しなくてもよい。このことによって、実施の形態２と同様の効果を得ることができる。

【0556】

ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。ビームスイーピングに必要なパラメータは、実施の形態１に示すものとしてもよい。ビームスイーピングに必要なパラメータの通知は、移動元ビーム／ＴＲＰを介して行ってもよい。ビームスイーピングに必要なパラメータは、移動先ビーム／ＴＲＰにおけるパラメータとしてもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0557】

移動先ビーム／ＴＲＰからＵＥに対するＲＲＣパラメータ通知には、実施の形態２と同様、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、ビームスイーピングに必要なパラメータを迅速に通知することが可能となる。

【0558】

あるいは前述において、実施の形態３と同様、ＲＲＣシグナリングを用いてもよい。このことにより、ＲＲＣパラメータを予めＣＵからＵＥに通知することが可能となるため、ビーム／ＴＲＰ切り替え時におけるＲＲＣパラメータ通知が不要となる。これによりシグナリング量を少なくすることが可能となる。

【0559】

移動元ビーム／ＴＲＰからＵＥに対する切り替え指示の通知の方法には、実施の形態２と同様、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、ＵＥへのビーム／ＴＲＰ切り替え通知を迅速に行うことができる。また、ＭＡＣシグナリングを用いることにより、前述の通知の信頼性を向上させることができる。

【0560】

実施の形態５と同様、移動元ＴＲＰは、ＣＵに対し、切り替え指示の送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、切り替え指示の通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、ビーム／ＴＲＰを切り替えてもよい。このようにすることによって、切り替え指示の不達時のビーム／ＴＲＰ切り替えを防ぐことができるため、ＵＥのＣＵとのリンク喪失によるＲＬＦ発生を回避することができる。

【0561】

ＣＵは、ＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0562】

前述の、ＭＡＣシグナリングを用いた切り替え指示の通知において、実施の形態２と同様、ＣＵは、移動元ビーム／ＴＲＰからＵＥへの切り替え指示のＨＡＲＱ再送回数超過時に、ビーム／ＴＲＰを切り替えてもよい。ビーム／ＴＲＰの切り替えは、切り替え指示に対するＵＥからのＡｃｋ／Ｎａｃｋが判別不能である場合に行うとよい。このことによって、移動元ビーム／ＴＲＰが切り替え指示に対するＵＥからのＡｃｋ信号を受信し損ねた場合について、ＵＥにおける通信先ビーム／ＴＲＰ切り替えとともにｇＮＢにおいてもビーム／ＴＲＰを切り替えることができる。それにより、ＵＥにおけるｇＮＢとのリンク喪失を防ぐことができる。

【0563】

実施の形態２と同様、ＵＥは、上り信号を移動元のビーム／ＴＲＰに送信してもよい。上り信号は、ＣＵからの切り替え指示のＬ１／Ｌ２シグナリングに対する応答であってもよい。上り信号として、応答用のＬ１／Ｌ２シグナリングを新たに設けてもよい。前述の応答として、新しい上り制御情報（ＵＣＩ）を設けてもよい。このことによって、実施の形態２に記載したことと同様の効果を得ることができる。

【0564】

新しいＵＣＩについては、実施の形態２と同様としてもよい。このことにより、実施の形態２と同様の効果を得ることができる。

【0565】

前述において、実施の形態４と同様、移動元ビーム／ＴＲＰは、ＣＵに対し、応答用のＬ１／Ｌ２シグナリングを受信したことを示す情報を通知してもよい。このことにより、ＵＥが切り替え指示を正しく受信したことをＣＵが把握することができるので、ビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0566】

移動元ビーム／ＴＲＰからＵＥへの、ＭＡＣシグナリングを用いた切り替え指示の通知に関して、移動元ビーム／ＴＲＰは、切り替え指示の通知に対してＡｃｋを受信したことを示す情報を、ＣＵに対して通知してもよい。ＣＵは、通知された情報を用いて、使用するビーム／ＴＲＰを切り替えてもよい。このことにより、ＵＥが切り替え指示を正しく受信したことをＣＵが把握することができるので、ビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0567】

実施の形態２と同様、ＵＥは、上り信号を移動先のビーム／ＴＲＰに送信してもよい。上り信号は、ＵＥにおけるビーム／ＴＲＰ切り替えの確認用の信号としてもよい。確認用の信号を、ＳＲの周波数リソースを用いて送信してもよい。あるいは、ＳＲを、確認用の信号として送信してもよい。このことによって、移動先ビーム／ＴＲＰは、ＵＥの通信先ビーム／ＴＲＰを切り替えたことを確認したうえで、ＲＲＣパラメータを通知することができる。それにより、ＲＲＣパラメータ通知のＵＥへの送達の信頼性が向上する。

【0568】

ＵＥから移動先ビーム／ＴＲＰへのＳＲ送信、ＳＲ用共通リソース、および、ＳＲＳ送信については、実施の形態２と同じであるため、記載を省略する。

【0569】

ＣＵがＵＥにおける通信先ビーム／ＴＲＰ切り替えの有無の判断することについては、実施の形態２と同じであるため、記載を省略する。

【0570】

送信元ビーム／ＴＲＰは、ＵＥへの切り替え指示通知を複数回送信してもよいし、電力を増加させてもよい。このことにより、切り替え指示通知の信頼性を向上させることができる。

【0571】

送信先ビーム／ＴＲＰは、ＵＥへのパラメータの通知を、複数回行ってもよいし、電力を増加させてもよい。このことにより、前述のパラメータ通知の信頼性を向上させることができる。

【0572】

ＵＥからのＳＲ送信について、移動元ビーム／ＴＲＰは、ＵＥから受信したＳＲを無効としてもよい。移動元ビーム／ＴＲＰは、ビーム／ＴＲＰ切り替えがＳＲ受信と上りスケジューリンググラント送信との間に発生するときに、ＳＲを無効としてもよい。前述において、ＵＥは、移動先ビーム／ＴＲＰにＳＲを再送してもよい。ＵＥからのＳＲ再送は、移動先ビーム／ＴＲＰからＳＲに関するＲＲＣパラメータを受信した後に行うとよい。このことによって、ＵＥから移動先ビーム／ＴＲＰに送信する再送ＳＲが、移動先ビーム／ＴＲＰにて不達となることを、回避することができる。

【0573】

あるいは、前述において、移動元ビーム／ＴＲＰは、ＵＥから受信したＳＲを有効としてもよい。移動元ビーム／ＴＲＰは、ＳＲを移動先ビーム／ＴＲＰに転送してもよい。この転送は、ＣＵを経由してもよい。前述において、ＳＲの代わりに、ＳＲを受信したことを示す情報を用いてもよい。このようにすることによって、ビーム／ＴＲＰ切り替えがＳＲ受信と上りスケジューリンググラント送信との間に発生するときにおいても、ＵＥにおける、ＳＲ送信と、上りスケジューリンググラント受信と、上りユーザデータ送信とを含む一連の流れを円滑に行うことができる。このことにより、移動先ビーム／ＴＲＰからＳＲに関するＲＲＣパラメータが通知されるのを待たずに、上りスケジューリンググラントを受信し、上りユーザデータ送信を行うことができる。それにより、上りユーザデータ通信における遅延を少なくすることができる。

【0574】

移動先ビーム／ＴＲＰはＵＥに、上りスケジューリンググラントとＳＲに関するＲＲＣパラメータとを同時に通知してもよい。このことにより、移動先ビーム／ＴＲＰからＵＥへのシグナリング量を少なくすることができるとともに、上りユーザデータ通信における遅延を少なくすることができる。

【0575】

ＣＵからＵＥへの上りスケジューリンググラント通知について、ＣＵおよびＵＥは、移動元ビーム／ＴＲＰから送信された上りスケジューリンググラントを無効としてもよい。ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替えが上りスケジューリンググラントと上りユーザデータとの間に発生するときに、上りスケジューリンググラントを無効としてもよい。前述において、移動先ビーム／ＴＲＰはＵＥに、上りスケジューリンググラントを再送してもよい。上りスケジューリンググラントの再送において、移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、ＵＥに対する上りスケジューリンググラントの再送を要求してもよい。あるいは、ＵＥは、移動先ビーム／ＴＲＰに対し、ＳＲ送信からやり直してもよい。ＳＲの再送は、ＣＵからＵＥへのＲＲＣパラメータ通知を受信した後に行うとよい。このことによって、ＵＥからの再送ＳＲがＣＵにて不達となることを防ぐことができる。

【0576】

前述において、ＵＥがＳＲ送信からやり直すかどうかについて、規格で定めてもよいし、あるいは、ＣＵからＵＥに通知してもよい。ｇＮＢからＵＥへの通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。前述の通知は、ＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、切り替え通知と併せて行ってもよい。このことにより、ＵＥは、上りユーザデータ送信に用いる移動先ビーム／ＴＲＰの上りリソース使用状況に応じた上りスケジューリンググラントを受信することが可能となる。

【0577】

あるいは、前述の、移動元ビーム／ＴＲＰからＵＥへの上りスケジューリンググラント通知後のビーム／ＴＲＰ切り替えについて、ＣＵおよびＵＥは、移動元ビーム／ＴＲＰから送信された上りスケジューリンググラントを有効としてもよい。ＵＥは、上りスケジューリンググラントを用いて、移動先ビーム／ＴＲＰに上りユーザデータを送信してもよい。このことにより、ＣＵ、ＵＥ間のシグナリング量を削減することができる。

【0578】

前述における上りスケジューリンググラントを有効とするかどうかを、規格で定めてもよいし、あるいは、ＣＵからＵＥに通知してもよい。ｇＮＢからＵＥへの通知は、予めＲＲＣシグナリングで行ってもよいし、ＭＡＣシグナリングで行ってもよいし、Ｌ１／Ｌ２シグナリングで行ってもよい。上りスケジューリンググラントを有効にする場合の例として、スケジューリンググラントにて示される上りリソースを、移動先ビーム／ＴＲＰが該ＵＥに対して使用可能である場合としてもよい。移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、上りスケジューリンググラントについての情報を通知してもよい。このことにより、移動先ビーム／ＴＲＰは、上りスケジューリンググラントを有効にするか無効にするかを判断することができるようになるので、柔軟なスケジューリングが可能となる。

【0579】

前述の通知をＭＡＣシグナリングあるいはＬ１／Ｌ２シグナリングで行う例では、前述の通知を切り替え通知と併せて行ってもよい。このことにより、ＣＵは、移動先ビーム／ＴＲＰにおける上りリソース使用状況に応じたスケジューリングを、少ないシグナリングで行うことが可能となる。

【0580】

ＵＥからＣＵへの上りユーザデータ送信について、移動先ビーム／ＴＲＰは、移動元ビーム／ＴＲＰがＵＥから受信した上りユーザデータに対するＡｃｋ／Ｎａｃｋを、ＵＥに送信してもよい。前述における移動先ビーム／ＴＲＰからＵＥへのＡｃｋ／Ｎａｃｋ送信は、ビーム／ＴＲＰ切り替えがＵＥからの上りユーザデータ送信と上りユーザデータに対するＡｃｋ／Ｎａｃｋ通知との間に発生するときに行ってもよい。前述において、移動元ビーム／ＴＲＰは、上りユーザデータに対するＡｃｋ／Ｎａｃｋを示す情報を、移動先ビーム／ＴＲＰに通知してもよい。このことによって、上りユーザデータ送信後のビーム／ＴＲＰ切り替えを円滑に行うことができる。

【0581】

また、移動元ビーム／ＴＲＰは、ＵＥから受信した上りユーザデータの復号結果に関する情報を、移動先ビーム／ＴＲＰに通知してもよい。この情報は、例えば、上りユーザデータの軟判定値であってもよい。このことによって、移動先ビーム／ＴＲＰは、上りユーザデータの初送受信結果と再送受信結果とを合成して復号することができる。それにより、受信エラーとなる確率を低くすることができる。

【0582】

本実施の形態５により、ＣＵがＰＤＣＰを有し、ＤＵがＲＬＣ、ＭＡＣおよびＰＨＹを有する場合、あるいは、ＣＵがＰＤＣＰおよびＨ－ＲＬＣを有し、ＤＵがＬ－ＲＬＣ、ＭＡＣおよびＰＨＹを有する場合についても、実施の形態２と同じ効果を得ることができる。また、移動元ビーム／ＴＲＰとＵＥとの間の通信環境が急速に悪化する場合においても、ＣＵからＵＥに対するＲＲＣパラメータ通知を行うことができる。その結果、例えば、ＳＲの不達によるＵＥのランダムアクセス処理発生を抑えることができる。

【0583】

実施の形態２と実施の形態３の組み合わせと同様、実施の形態４と本実施の形態５と組み合わせて用いてもよい。すなわち、ＣＵは、ＲＲＣパラメータを移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらから送信するかを切り替えてもよい。このようにすることによって、ＣＵはＲＲＣパラメータを送信するビーム／ＴＲＰを通信環境に応じて柔軟に変えることが可能となる。

【0584】

実施の形態２と実施の形態３の組み合わせと同様、ＲＲＣパラメータを移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらから送信するかについて、ＣＵは予めＵＥに準静的に設定してもよいし、ＣＵから動的に設定してもよいし、規格により暗黙的に決定してもよい。このようにすることによって、実施の形態２と実施の形態３の組み合わせと同様の効果を得ることができる。

【0585】

実施の形態５において、ＣＵとＤＵが分離されている基地局装置を例として示したが、ＣＵとＤＵが分離されていない基地局装置について適用してもよい。該基地局装置は、ビーム間でＲＲＣパラメータを共有しない基地局装置であってもよい。また、該基地局装置は、例えば、ビーム毎に異なるＨＡＲＱスケジューリングを行う基地局装置であってもよいし、ビーム毎に異なるＲＬＣレイヤを有する基地局装置であってもよいし、前述の両方を組み合わせたものであってもよい。実施の形態５を該基地局装置に適用するにあたり、ＣＵをｇＮＢに読み替えてもよい。このようにすることで、セル内のビーム間移動においてＲＲＣパラメータをｇＮＢから移動先ビームを介してＵＥに通知することを可能とし、ビームによって空間分離がされているセルにおけるＵＥ収容数を増加させることができる。また、ｇＮＢからＵＥにパラメータを迅速に通知することが可能となる。

【0586】

実施の形態５によれば、実施の形態２と同様に、例えば、通信端末装置と、通信端末装置と無線ビームを用いて無線通信を行う基地局装置とを含み、基地局装置によって構成されるセルは、基地局装置の配下にある複数の無線ビームによって、空間分離されており、通信端末装置が第１の無線ビームの圏内から第２の無線ビームの圏内に移動する場合、基地局装置は、通信端末装置に対して用いるＲＲＣ（Radio Resource Control）パラメータを、第１の無線ビーム用の第１のＲＲＣパラメータから、第２の無線ビーム用の第２のＲＲＣパラメータに変更する、通信システムが提供される。なお、複数の無線ビームは、図８に例示したように複数のＤＵ（言い換えるとＴＲＰ）によって形成されてもよいし、１つのＤＵによって形成されてもよいし、あるいは、ＣＵとＤＵが統合された基地局装置によって形成されてもよい。

【0587】

この構成によれば、通信端末装置に対して用いる無線ビームの変更に応じて、通信端末装置に対して用いるＲＲＣパラメータを変更する。このため、前述のように、通信端末装置の収容数を増加させることができる。

【0588】

ここで、上記構成は、前述のように、様々に変形することが可能である。特に実施の形態５によれば、例えば、基地局装置は、複数の無線ビームを出力する少なくとも１つのＤＵ（Distributed Unit）と、少なくとも１つのＤＵを制御するＣＵ（Central Unit）とを含み、少なくとも１つのＤＵがＭＡＣ（Medium Access Control）機能を有しており、基地局装置は、第２のＲＲＣパラメータを、第２の無線ビームによって、Ｌ１／Ｌ２シグナリングまたはＭＡＣシグナリングを用いて、通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、Ｌ１／Ｌ２シグナリングまたはＭＡＣシグナリングを用いて、通信端末装置に通知することと、を行う、通信システムが提供される。前述において、ＤＵは、ＲＬＣ（Radio Link Control）機能を有していてもよい。また、他の例として、基地局装置は、複数の無線ビームを出力する機能、ＭＡＣ機能を有しており、基地局装置は、第２のＲＲＣパラメータを、第２の無線ビームによって、通信端末装置に通知することと、第１の無線ビームから第２の無線ビームへの切り替え指示を、第１の無線ビームによって、通信端末装置に通知することと、を行う、通信システムが提供される。

【0589】

また、以下の変形例１～４で述べるように、様々な変形が提供される。

【0590】

実施の形態５の変形例１．
実施の形態５においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて適用してもよい。

【0591】

前述における、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータは、実施の形態２の変形例１と同じとしてもよい。

【0592】

本変形例１において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態５と同じとしてもよい。また、ＣＵが移動先ビーム／ＴＲＰを介してＵＥに通知するＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータ通知の方法は、実施の形態５に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態５と同じ効果を得ることができる。

【0593】

実施の形態５と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態３と同様でよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0594】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態５と同じ効果を得ることができる。

【0595】

実施の形態５と同様、ＣＵは、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0596】

実施の形態５と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、移動元ビーム／ＴＲＰからＵＥへのパラメータ通知が失敗したときにおいても、ＵＥは初期値あるいは変更前のＲＲＣパラメータを用いることができるため、ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティションにおける信頼性を高めることができる。

【0597】

ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0598】

あるいは、ＣＵは、前述のＡｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0599】

また、切り替え通知についても、実施の形態２と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態２と同様の効果を得ることができる。

【0600】

移動元ビーム／ＴＲＰからＵＥに対する切り替え指示の通知の方法には、実施の形態５と同様、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態５にて示したことと同様の効果を得ることができる。

【0601】

実施の形態５と同様、移動元ＴＲＰは、ＣＵに対し、切り替え指示の送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、切り替え指示の通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、ビーム／ＴＲＰを切り替えてもよい。このようにすることによって、切り替え指示の不達時のビーム／ＴＲＰ切り替えを防ぐことができるため、ＵＥのｇＮＢとのリンク喪失によるＲＬＦ発生を回避することができる。

【0602】

実施の形態５と同様、ＣＵはＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、Ａｃｋ／Ｎａｃｋレペティションの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0603】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからの下りユーザデータに対するＡｃｋ／Ｎａｃｋの通知を、移動元ビーム／ＴＲＰに対しても移動先ビーム／ＴＲＰに対しても行わなくてもよい。前述のＵＥの動作は、下りユーザデータとＡｃｋ／Ｎａｃｋとの間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。移動元ビーム／ＴＲＰは、前述の下りユーザデータを移動先ビーム／ＴＲＰに転送してもよい。移動先ビーム／ＴＲＰは、前述の下りユーザデータをＵＥに送信してもよい。このようにすることによって、ビーム／ＴＲＰ切り替えによる下りユーザデータの欠落を防ぐことができる。

【0604】

他の例として、ＵＥは、移動元ビーム／ＴＲＰから受信したＣＵからの下りユーザデータに対するＡｃｋ／Ｎａｃｋの通知を、移動先ビーム／ＴＲＰに対して行ってもよい。前述のＡｃｋ／Ｎａｃｋの通知は、下りユーザデータとＡｃｋ／Ｎａｃｋとの間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。移動先ビーム／ＴＲＰは、前述のＡｃｋ／Ｎａｃｋ受信結果を移動元ビーム／ＴＲＰに通知してもよい。このようにすることによって、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータに関するシグナリング量を削減することができる。

【0605】

前述において、移動元ビーム／ＴＲＰは、前述の下りユーザデータを移動先ビーム／ＴＲＰに転送してもよい。前述の転送は、下りユーザデータに対してＵＥからＮａｃｋの通知を受信したときに行ってもよい。移動先ビーム／ＴＲＰは、転送された下りユーザデータを用いてＵＥに再送を行ってもよい。このようにすることによって、ビーム／ＴＲＰ切り替えにおける下りユーザデータの再送処理を円滑に行うことができる。

【0606】

移動先ビーム／ＴＲＰからＵＥへの該下りユーザデータの再送は、ＣＵからＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータ通知を受信した後に、行ってもよい。このことにより、移動先ビーム／ＴＲＰは、Ａｃｋ／Ｎａｃｋレペティションによって設定される２回目以降のＡｃｋ／Ｎａｃｋを受信することが可能となるので、ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋ通知の信頼性を高めることができる。

【0607】

ＵＥから移動先ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋの通知は、前述と同様、移動先ビーム／ＴＲＰからＵＥへのＡｃｋ／Ｎａｃｋレペティションに関するパラメータ通知を受信した後に、行ってもよい。このことにより、前述と同様の効果を得ることができる。

【0608】

移動元ビーム／ＴＲＰは、ＵＥから受信したＡｃｋ／Ｎａｃｋの判断について、自ビーム／ＴＲＰにおける受信結果のみを用いてもよいし、移動先ビーム／ＴＲＰにおける受信結果と併せて用いてもよい。移動先ビーム／ＴＲＰは、ＵＥからのＡｃｋ／Ｎａｃｋ受信結果を移動元ビーム／ＴＲＰに転送してもよい。前述の動作は、ＵＥから移動元ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティションの間にビーム／ＴＲＰが切り替わった時に行うとよい。移動元ビーム／ＴＲＰにおける受信結果のみを用いることによって、ＵＥからのＡｃｋ／Ｎａｃｋレペティションの受信動作を迅速に行うことができる。移動先ビーム／ＴＲＰにおける受信結果と併せて用いることによって、移動元ビーム／ＴＲＰにおけるＡｃｋ／Ｎａｃｋレペティションの信頼性を高めることができる。移動元ビーム／ＴＲＰが自ビーム／ＴＲＰにおける受信結果のみを用いるか、移動先ビーム／ＴＲＰにおける受信結果と併せて用いるかについて、規格で定めてもよいし、ＣＵにて適宜切り替えてもよい。ＣＵにて適宜切り替えることにより、例えば、移動元ビーム／ＴＲＰにおける伝搬状況に応じて適切な受信動作を選択することができるため、ｇＮＢにおけるＡｃｋ／Ｎａｃｋレペティションの受信処理の柔軟性を高めることができる。

【0609】

前述において、移動元ビーム／ＴＲＰの代わりに移動先ビーム／ＴＲＰがＡｃｋ／Ｎａｃｋレペティションの受信処理を行ってもよい。移動先ビーム／ＴＲＰは、自ビーム／ＴＲＰにおける受信結果のみを用いてもよいし、移動元ビーム／ＴＲＰにおける受信結果と併せて用いてもよい。移動元ビーム／ＴＲＰは、ＵＥからのＡｃｋ／Ｎａｃｋ受信結果を移動元ビーム／ＴＲＰに転送してもよい。このようにすることによって、前述と同様の効果を得ることができる。移動先ビーム／ＴＲＰが自ビーム／ＴＲＰにおける受信結果のみを用いるか、移動先ビーム／ＴＲＰにおける受信結果と併せて用いるかについて、規格で定めてもよいし、ＣＵにて適宜切り替えてもよい。

【0610】

前述において、Ａｃｋ／Ｎａｃｋ受信動作を移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとのどちらが行うか、規格で定めてもよいし、予めＣＵが決定してもよい。このようにすることによって、移動元ビーム／ＴＲＰと移動先ビーム／ＴＲＰとの間におけるＡｃｋ／Ｎａｃｋの受信結果の齟齬による誤動作を防ぐことができる。

【0611】

移動先ビーム／ＴＲＰは、ＵＥから移動元ビーム／ＴＲＰに送信されたＡｃｋ／Ｎａｃｋレペティションを用いた下りユーザデータのＵＥへの再送を行ってもよい。該再送は、ＵＥから移動元ビーム／ＴＲＰへのＡｃｋ／Ｎａｃｋレペティションと、ＵＥへの下りユーザデータの再送との間で、ビーム／ＴＲＰが切り替わった時に行ってもよい。移動元ビーム／ＴＲＰは移動先ビーム／ＴＲＰに、再送データを転送してもよい。このことによって、ビーム／ＴＲＰ切り替えが発生するときの下りユーザデータ再送処理を円滑に行うことができる。

【0612】

本変形例１を用いることで、Ａｃｋ／Ｎａｃｋレペティションに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態５と同じ効果を得ることができる。

【0613】

実施の形態５の変形例２．
実施の形態５においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＳＲＳに関するＲＲＣパラメータについて適用してもよい。

【0614】

前述における、ＳＲＳに関するＲＲＣパラメータは、実施の形態２の変形例２と同じとしてもよい。

【0615】

本変形例２において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態５と同じとしてもよい。また、ＣＵが移動先ビーム／ＴＲＰを介してＵＥに通知するＳＲＳに関するＲＲＣパラメータ通知の方法は、実施の形態５に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0616】

実施の形態５と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0617】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0618】

実施の形態５と同様、ＣＵは、ＳＲＳに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0619】

実施の形態５と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＳＲＳに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0620】

ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0621】

あるいは、ＣＵは、前述のＳＲＳに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0622】

また、切り替え通知についても、実施の形態３と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0623】

実施の形態５と同様、ＣＵはＵＥへのＳＲＳに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、ＳＲＳに関するパラメータ通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0624】

ＵＥは、移動先ビーム／ＴＲＰへのＳＲＳ送信について、ＣＵから移動先ビーム／ＴＲＰを介して送信されるＳＲＳに関するパラメータを受信した後に、行ってもよい。このことによって、ＵＥにおけるＳＲＳに関するパラメータの受信前に行う、移動先ビーム／ＴＲＰにて受信できないＳＲＳの送信を抑えることができる。

【0625】

ＵＥは、移動元ビーム／ＴＲＰから受信したＳＲＳ送信指示に対するＳＲＳ送信を、移動先ビーム／ＴＲＰに対して行ってもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＳＲＳ送信は、ＳＲＳ送信指示とＳＲＳ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。また、前述におけるＳＲＳ送信は、非周期的（Aperiodic）なＳＲＳ送信について行ってもよい。移動元ビーム／ＴＲＰは、移動先ビーム／ＴＲＰに、ＵＥに対してＳＲＳ送信を指示したことを通知してもよい。このことにより、ＣＵおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときのＳＲＳ送信処理を円滑に行うことができる。

【0626】

前述において、ＵＥは、移動元ビーム／ＴＲＰから受信したＳＲＳ送信指示を無効としてもよい。このようにすることによって、移動元ビーム／ＴＲＰから移動先ビーム／ＴＲＰに対するシグナリングを削減することができる。

【0627】

移動元ビーム／ＴＲＰは、ＵＥから自ビームに送信したＳＲＳを無効としてもよい。ＳＲＳを無効とする動作は、ＳＲＳ送信の後にビーム／ＴＲＰが切り替わったときに行うとよい。このことによって、移動先ビーム／ＴＲＰは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0628】

本変形例２を用いることで、ＳＲＳに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態５と同じ効果を得ることができる。

【0629】

実施の形態５の変形例３．
実施の形態５においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて適用してもよい。

【0630】

前述における、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータは、実施の形態２の変形例３と同じとしてもよい。

【0631】

本変形例３において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態５と同じとしてもよい。また、ＣＵが移動先ビーム／ＴＲＰを介してＵＥに通知するＣＱＩ／ＣＳＩに関するＲＲＣパラメータ通知の方法は、実施の形態５に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態５と同じ効果を得ることができる。

【0632】

実施の形態５と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。このようにすることで、ＵＥはビーム／ＴＲＰ間移動におけるビームスイーピング信号の受信を容易にすることができる。

【0633】

前述において、ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0634】

実施の形態５と同様、ＣＵは、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0635】

実施の形態５と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。ＵＥのビーム／ＴＲＰ切り替え時のパラメータの値を、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよい。あるいは、初期値に戻すか、あるいは保持するかについての情報を、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0636】

ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0637】

あるいは、ＣＵは、前述のＣＱＩ／ＣＳＩに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0638】

また、切り替え通知についても、実施の形態３と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態３と同様の効果を得ることができる。

【0639】

実施の形態５と同様、ＣＵはＵＥへのＣＱＩ／ＣＳＩに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、ＣＱＩ／ＣＳＩに関するパラメータの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0640】

ＵＥは、移動先ビーム／ＴＲＰへのＣＱＩ／ＣＳＩ送信について、ＣＵから移動先ビーム／ＴＲＰを介して送信されるＣＱＩ／ＣＳＩに関するパラメータを受信した後に、行ってもよい。このことによって、ＵＥにおけるＣＱＩ／ＣＳＩに関するパラメータの受信前に行う、移動先ビーム／ＴＲＰにて受信できないＣＱＩ／ＣＳＩの送信を抑えることができる。

【0641】

ＵＥは、移動元ビーム／ＴＲＰから受信したＣＱＩ／ＣＳＩ送信指示に対するＣＱＩ／ＣＳＩ送信を、移動先ビーム／ＴＲＰに対して行ってもよい。前述における、ＵＥから移動先ビーム／ＴＲＰへのＣＱＩ／ＣＳＩ送信は、ＣＱＩ／ＣＳＩ送信指示とＣＱＩ／ＣＳＩ送信との間にビーム／ＴＲＰ切り替えが発生するときに行ってもよい。また、前述におけるＣＱＩ／ＣＳＩ送信は、非周期的（Aperiodic）なＣＱＩ／ＣＳＩ送信について行ってもよい。移動元ビーム／ＴＲＰは、ＵＥにＣＱＩ／ＣＳＩ送信指示を行ったことを示す情報を、移動先ビーム／ＴＲＰに対して通知してもよい。このことにより、移動元ビーム／ＴＲＰ、移動先ビーム／ＴＲＰおよびＵＥにおいて、ビーム／ＴＲＰ切り替えが発生するときのＣＱＩ／ＣＳＩ送信処理を円滑に行うことができる。

【0642】

移動元ビーム／ＴＲＰは、ＵＥから自ビームに送信したＣＱＩ／ＣＳＩを無効としてもよい。ＣＱＩ／ＣＳＩを無効とする動作は、ＣＱＩ／ＣＳＩ送信の後にビーム／ＴＲＰが切り替わったときに行うとよい。移動元ビーム／ＴＲＰは、ＵＥにＣＱＩ／ＣＳＩ送信指示を行ったことを示す情報を、移動先ビーム／ＴＲＰに対して通知してもよい。移動先ビーム／ＴＲＰはＵＥに、ＣＱＩ／ＣＳＩ送信指示を再送してもよい。ＵＥは、移動先ビーム／ＴＲＰに対してＣＱＩ／ＣＳＩを再送してもよい。このことによって、移動先ビーム／ＴＲＰは、ビーム／ＴＲＰ切り替え後の伝搬状況に適したスケジューリングを行うことができるようになる。

【0643】

本変形例３を用いることで、ＣＱＩ／ＣＳＩに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態５と同じ効果を得ることができる。

【0644】

実施の形態５の変形例４．
実施の形態５においては、ＳＲに関するＲＲＣパラメータの通知を中心に記載したが、ＲＬＣに関するＲＲＣパラメータについて適用してもよい。

【0645】

前述における、ＲＬＣに関するＲＲＣパラメータとして、実施の形態４の変形例４に示す（１）～（８）を用いてもよい。

【0646】

本変形例４において、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知する切り替え通知の方法および通知内容は、実施の形態５と同じとしてもよい。また、ＣＵが移動前ビーム／ＴＲＰを介してＵＥに通知するＲＬＣに関するＲＲＣパラメータ通知の方法は、実施の形態５に記載のＲＲＣパラメータ通知と同じ方法を適用してもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0647】

実施の形態５と同様、ＣＵはＵＥに、ビームスイーピングに必要なパラメータを通知してもよい。パラメータの通知方法についても、実施の形態５と同様でよい。このようにすることで、実施の形態５と同様の効果を得ることができる。

【0648】

ＣＵからＵＥへの、ビームスイーピングに必要なパラメータの通知は、Ｌ１／Ｌ２シグナリングを用いてもよいし、ＭＡＣシグナリングを用いてもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0649】

実施の形態５と同様、ＣＵは、ＲＬＣに関するＲＲＣパラメータのＵＥへの通知に、ＴＲＰ／ビーム切り替えによるパラメータ切り替えであることを示す識別子を含めてもよい。ＵＥは、変更前のＲＬＣに関するＲＲＣパラメータを保持し、ＴＲＰ／ビーム切り替え後に変更後のパラメータを用いてもよい。このようにすることで、ＴＲＰ／ビーム切り替え前において、ＲＬＣに関するＲＲＣパラメータの変更に伴って発生するＵＥおよび移動元ビーム／ＴＲＰのＲＬＣ再構築を防ぐことができ、それに伴う通信ロスを防ぐことができる。

【0650】

実施の形態５と同様、ＣＵは、ＲＬＣに関するＲＲＣパラメータについて、移動先ビーム／ＴＲＰにおいても同じ値を用いるパラメータの通知を行わないでもよい。このようにすることで、パラメータ通知によるシグナリング量を削減することができる。

【0651】

実施の形態５と同様、ＣＵおよびＵＥは、ＵＥのビーム／ＴＲＰ切り替え時に、ＲＬＣに関するＲＲＣパラメータの値を初期値に戻してもよいし、保持してもよい。該初期値は、規格で定めてもよいし、ＣＵからＵＥに予めＲＲＣシグナリングで通知してもよい。前述において、初期値に戻すか、あるいは保持するかについて、規格で定めてもよいし、ＣＵからＵＥに予め通知してもよいし、ＣＵからＵＥに切り替え指示と併せて通知してもよい。このことにより、実施の形態４と同様の効果を得ることができる。

【0652】

ＣＵは、前述のＲＬＣに関するＲＲＣパラメータを、Ｌ１／Ｌ２シグナリングを用いてＵＥに通知してもよい。このことにより、ＵＥへのパラメータ通知を迅速に行うことができる。

【0653】

あるいは、ＣＵは、前述のＲＬＣに関するＲＲＣパラメータを、ＭＡＣシグナリングを用いて通知してもよい。このことにより、多値変調が可能となるので、パラメータを少ないシンボル数で通知できる。また、ＨＡＲＱ再送制御が行われるので、パラメータ通知の信頼性が向上する。

【0654】

実施の形態５と同様、移動先ＴＲＰは、ＣＵに対し、パラメータの送達確認が取れたことを示す情報を通知してもよい。前述の情報の通知は、パラメータの通知にＭＡＣシグナリングを用いている場合に行ってもよい。ＣＵは、前述の情報を用いて、切り替え指示をＵＥに通知してもよい。このようにすることによって、パラメータの不達によるＲＬＣの誤動作を防ぐことができる。

【0655】

また、切り替え通知についても、実施の形態５と同様、ＣＵからＵＥに対し、Ｌ１／Ｌ２シグナリングを用いて通知してもよいし、ＭＡＣシグナリングを用いて通知してもよい。このことにより、実施の形態５と同様の効果を得ることができる。

【0656】

実施の形態５と同様、ＣＵはＲＬＣに関するパラメータの通知を、複数回送ってもよいし、送信電力を増加させてもよい。このことにより、パラメータの通知の信頼性を高めることができる。ＣＵからＵＥへの切り替え指示についても同様である。

【0657】

ＣＵおよびＵＥは、切り替え指示の通知とともにユーザデータの送受信を止めてもよい。ＣＵおよびＵＥは、ビーム／ＴＲＰ切り替えおよびＲＬＣに関するパラメータの送受信完了後にユーザデータの送受信を再開してもよい。このようにすることによって、ＲＬＣ再構築によるデータの欠落を防ぐことができる。

【0658】

本変形例４を用いることで、ＲＬＣに関するＲＲＣパラメータのＵＥへの通知に関して、実施の形態５と同じ効果を得ることができる。

【0659】

実施の形態６．
通信用の無線リソースとして複数のキャリアを集めて使用するキャリアアグリゲーション（CA）と言われる技術がある。ＣＡでは、一つのＵＥに対して、一つのＰＣｅｌｌと、一つ以上のＳＣｅｌｌとからなるサービングセルの組が構成される。このためＣＡの設定はセル単位で行われる。ｅＮＢからＵＥへのＣＡの設定は、ＣＡを行うセル単位のパラメータを通知することで行われる。

【0660】

ＮＲ（New Radio）では、基地局（本明細書では、５Ｇの基地局をｇＮＢと称する）が複数のアンテナを用いて狭範囲なビームを形成するビームフォーミングを利用して通信を行うことが提案されている。例えば、ｇＮＢは、図４に示すアンテナ４０８を、多素子アンテナによって構成する。ｇＮＢは、多素子アンテナの一部または全部の複数のアンテナを用いて、予め定める方向にビームを形成する。狭範囲なビーム形成を行うことによって、電波到達範囲を広くすることが可能となる。

【0661】

ＣＡを行うセルが複数のビームの運用をサポートした場合、ＣＡをセルの識別子だけで設定しても、セルのどのビームをアグリゲーションしたらよいかが不明となってしまう。このため、ｇＮＢはＵＥに対してＣＡを設定できず、多くの無線リソースを使用できなくなってしまう。ＵＥに対して、高速および大容量の通信サービスを提供できなくなってしまう。

【0662】

本実施の形態６ではこのような問題を解決する方法を開示する。

【0663】

ＣＡの設定をビーム単位にする。一つのビームが用いられてもよいし、複数のビームが用いられてもよい。ｇＮＢはＵＥに対して、ＳＣｅｌｌの設定時に、どのビームを用いるかを通知する。

【0664】

図１２は、ｇＮＢにおいてビーム単位で設定するＣＡのアーキテクチャを説明する図である。ｇＮＢはＰＤＣＰ、ＲＬＣ、ＭＡＣおよびＰＨＹのプロトコルで構成されている。ＰＨＹ機能は二つに分割されてもよい。当該二つのＰＨＹ機能を各々Ｈ－ＰＨＹとＬ－ＰＨＹと称す。

【0665】

３ＧＰＰでは、ｇＮＢが二つのユニットに分離されることが提案されている（非特許文献７参照）。当該二つのユニットを各々ＣＵ（Central Unit）とＤＵ（Distributed Unit）と称する。ＣＵに複数のＤＵが接続される。例えば、ＣＵはＰＤＣＰ、ＲＬＣ、ＭＡＣおよびＨ－ＰＨＹを有することが提案されている。ＤＵはＬ－ＰＨＹを有することが提案されている。ＴＲＰはＤＵと同じ機能を有してもよい。Ｂｎ（ｎは自然数）はビームを構成することを示している。ＤＵあるいはＴＲＰは一つまたは複数のビームを構成する。

【0666】

ｇＮＢはＵＥに対して、一つのＰＣＣ（Primary Component Carrier）と一つまたは複数のＳＣＣ（Secondary Component Carrier）によって、ＣＡを行う。ＰＣＣを用いたセルがＰＣｅｌｌである。ＳＣＣを用いたセルがＳＣｅｌｌである。ｇＮＢはＵＥに対して、一つのＰＣｅｌｌと一つまたは複数のＳＣｅｌｌによって、ＣＡを行う、と表現される場合もある。各セルはＭＡＣの最下位に位置するＨＡＲＱを個別に有し、その上位でアグリゲーションされる。各セルはＰＨＹ以下の機能を個別に有する。

【0667】

ＣＡの設定をビーム単位で行う場合、ＰＣｅｌｌ内あるいはＳＣｅｌｌ内のどのビームを用いてＣＡを行うかを設定する。図１２の例では、ｇＮＢは、ＰＣｅｌｌのＴＲＰ１のビーム１と、ＰＣｅｌｌのＴＲＰ２のビーム２と、ＳＣｅｌｌのＴＲＰ１のビーム１およびビーム２と、ＳＣｅｌｌのＴＲＰ２のビーム１とを用いて、ＵＥに対するＣＡを行う。

【0668】

このようにＣＡの設定をビーム単位で行うことによって、ビームフォーミングがサポートされるセルを、ＣＡに用いるセルとすることが可能となる。このため、ＵＥに対して多くの無線リソースが使用可能となり、高速および大容量の通信を行うことが可能となる。

【0669】

ビーム単位のＣＡ設定方法について開示する。

【0670】

ビーム単位のＣＡの設定においてＲＲＣシグナリングを用いる。ビームに関する情報を設けて、ｇＮＢはＵＥに対して、ＲＲＣシグナリングで通知する。ビームに関する情報を、ＳＣｅｌｌの設定用メッセージに含めてもよい。例えば、ＲＲＣ接続再設定メッセージに、ビームに関する情報を含めてもよい。ＳＣｅｌｌ追加変更用あるいはＳＣｅｌｌ解放用のパラメータ内に、ビームに関する情報を含めてもよい。

【0671】

ビームに関する情報は、ＵＥがビームを特定できる情報であればよい。例えば、ビームでビーム個別のＲＳが送信されるような場合、ＵＥがビーム個別のＲＳを受信することでビームを特定できる。このような場合、ビームに関する情報として、ビーム個別のＲＳ（ビームＲＳ（BRS））構成がある。また、例えば、ビームに識別子がつけられており、ビーム識別子とビーム個別のＲＳ構成とが関連付けられている場合、ビームに関する情報としてビーム識別子としてもよい。また、ビーム識別子を設定するビーム数でリナンバリングしたビームインデックスを設けてもよい。

【0672】

ｇＮＢはＵＥに対して、これらのビームに関する情報を、ＣＡに用いるＳＣｅｌｌと対応付けて通知する。ｇＮＢはＵＥに対して、ＵＥがＳＣｅｌｌ内でモニタするビームに関する情報を通知する。ＵＥは、該情報を受信することで、ＳＣｅｌｌ内でモニタするビームを認識することができる。ＲＲＣで設定したＳＣｅｌｌとビームとの対応関係は、再度設定されるまで維持される。

【0673】

ｇＮＢはＵＥに対して、ＭＡＣ制御シグナリングによって、ＳＣｅｌｌのアクティベーション（act）／デアクティベーション（deact）を行う。ＵＥは、ＭＡＣ制御シグナリングによってＳＣｅｌｌがａｃｔ／ｄｅａｃｔされた場合、ＲＲＣシグナリングで受信したＳＣｅｌｌに対応付けられたビームがａｃｔ／ｄｅａｃｔされたとみなす。ＵＥは、ａｃｔされたＳＣｅｌｌに対応付けられたビームをモニタする。ＵＥはビームをモニタすることで自ＵＥ宛の情報の有無を検出する。例えば、ＵＥはビームの物理下り制御チャネル（PDCCH）を受信して、自ＵＥ宛のスケジューリング情報の有無を検出する。

【0674】

ＵＥは、ＲＲＣシグナリングで通知されたＳＣｅｌｌのＳＳ（Synchronization Signal）を受信して同期を行う。この際、ＳＣｅｌｌのいずれかのビームでＳＳを受信して同期を行う。ＵＥは、同期の後、ＲＲＣシグナリングで通知されたＳＣｅｌｌに対応付けられたビームのビーム識別子とＢＲＳ構成とのうちの少なくとも一方を用いて、ＳＣｅｌｌ内でモニタするビームを検出する。ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0675】

他の方法として、ＵＥは、ＭＡＣ制御シグナリングで通知されたａｃｔされたＳＣｅｌｌのＳＳ（Synchronization Signal）を受信して同期を行ってもよい。この際、該ＳＣｅｌｌのいずれかのビームでＳＳを受信して同期を行う。ＵＥは、同期の後、ＲＲＣシグナリングで通知されたＳＣｅｌｌに対応付けられたビームのビーム識別子とＢＲＳ構成とのうちの少なくとも一方を用いて、ＳＣｅｌｌ内でモニタするビームを検出する。ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0676】

ｇＮＢはＵＥに対して、該ビームのＰＤＣＣＨを用いてスケジューリング情報を通知することが可能となる。このようにすることで、ｇＮＢはＵＥに対して、どのビームを用いて通信を行うかを通知することが可能となり、ＵＥは、どのビームをモニタすればよいか、どのビームを用いて通信を行えばよいかを認識可能となる。

【0677】

従来のようにＳＣｅｌｌのみの通知であったならば、ＳＣｅｌｌにアクセスした後に、ＳＣｅｌｌ内のどのビームを使うかを設定しなければならい。このため、ＳＣｅｌｌにアクセスする処理に加え、使用するビームを選択する処理を行わなくてはならない。したがって、ＣＡの開始までに時間がかかってしまう。

【0678】

本実施の形態６で開示したように、ＣＡを設定する際にどのビームを用いてＣＡを行うかを特定することによって、ＣＡの開始までの時間を低減することが可能となる。早期にＣＡを開始できるので、より高容量の通信が可能となる。

【0679】

なお、どのビームで通信を行うかをｇＮＢが認識する方法として、ＵＥが、ＣＡ設定以前に、ＳＣｅｌｌのビーム毎のメジャメントを予め行うとよい。ＵＥは、該測定結果をｇＮＢに通知するとよい。該通知は、例えば、周期的に行われてもよいし、イベントトリガに応じて行われてもよいし、ｇＮＢの要求に応じて行われてもよい。

【0680】

図１３および図１４は、ＲＲＣシグナリングを用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。図１３と図１４とは、境界線ＢＬ５２１の位置で、つながっている。図１３および図１４では、ｇＮＢがＵＥに対して、ＰＣｅｌｌとＳＣｅｌｌとを用いてＣＡを行う場合について示している。また、ＰＣｅｌｌではビーム１とビーム２とが構成され、ＳＣｅｌｌではビーム１とビーム２とビーム３とが構成されている場合について示している。ステップＳＴ５２０１において、ＵＥはｇＮＢとＰＣｅｌｌのビーム１を介して通信を行っている。

【0681】

ステップＳＴ５２０２において、ｇＮＢはＵＥに対して、ＰＣｅｌｌのビーム１によって、ＣＡ用ＳＣｅｌｌの設定情報および該ＳＣｅｌｌに対応付けたビームに関する情報を通知する。この通知には、ＲＲＣ個別シグナリングを用いる。従来のＬＴＥではＣＡ用ＳＣｅｌｌの設定情報の通知にＲＲＣ個別シグナリングを用いているので、該メッセージにビームに関する情報を加えるのみでよい。ビーム毎の設定用の制御の複雑化を抑制することができる。

【0682】

ステップＳＴ５２０２において、ＳＣｅｌｌに対応付けて通知するビームは、ＵＥと通信を行うビームとするとよい。ＳＣｅｌｌに対応付けて通知するビームは、ＵＥに物理下り制御チャネルをモニタさせたいビームとするとよい。ＳＣｅｌｌに対応付けて通知するビームは、ＵＥにアクセスさせたいビームとするとよい。このようにすることで、ｇＮＢはＵＥに対して、ＳＣｅｌｌの中でどのビームで通信を行うかを、ＵＥに対して通知することが可能となり、ＵＥは、ＳＣｅｌｌの中の通信を行うビームを特定することが可能となる。

【0683】

ＳＣｅｌｌの各ビームは周期的にＳＳを送信する（ステップＳＴ５２０３～ＳＴ５２０４を参照）。また、ＳＣｅｌｌの各ビームは周期的にＢＲＳを送信する（ステップＳＴ５２０６～ＳＴ５２０８を参照）。ＢＲＳは予め決められたパターンの周波数と時間リソースとのうちの少なくとも一方によって送信されてもよい。

【0684】

ステップＳＴ５２０９において、ｇＮＢは、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＭＡＣ制御シグナリングを用いる。ａｃｔ／ｄｅａｃｔ情報はＭＡＣ ＣＥに含めて通知する。ステップＳＴ５２１０において、ＵＥは、ａｃｔされたＳＣｅｌｌのＳＳを受信して同期を行う。ステップＳＴ５２１１において、ＵＥは、ＲＲＣ個別シグナリングで通知されたＳＣｅｌｌに対応付けられたビームのビーム識別子とＢＲＳ構成とのうちの少なくとも一方を用いて、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５２１２において、ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0685】

ステップＳＴ５２０９においてＰＣｅｌｌのビーム１によってＳＣｅｌｌのａｃｔ情報を通知したｇＮＢは、ステップＳＴ５２１３において、ＵＥに対して、ＳＣｅｌｌのビーム１から下りスケジューリング情報を通知する。この通知にはＬ１／Ｌ２制御信号が用いられる。ステップＳＴ５２１４において、ｇＮＢはＵＥに対して、該スケジューリング情報に従って、下りデータを送信する。ＵＥは、ステップＳＴ５２１３においてＳＣｅｌｌのビーム１から受信したスケジューリング情報に従って、ステップＳＴ５２１４においてＳＣｅｌｌのビーム１から下りデータを受信する。

【0686】

ＳＣｅｌｌを介して上り送信を行いたいＵＥは、ステップＳＴ５２１５において、ＳＣｅｌｌのビーム１でＰＲＡＣＨ送信を行いｇＮＢとの間でＲＡ処理を行う。物理下り制御チャネル（PDCCH）の指示によるＲＡ処理を行ってもよい。ステップＳＴ５２１６において、ＵＥはＳＣｅｌｌのビーム１に対して上りデータ送信を開始する。ＳＣｅｌｌを介して上り送信を行いたいＵＥは、ＰＲＡＣＨではなく、ＳＲを送信してもよい。上り同期が行われている場合、ＴＡを再度取得する必要が無い場合などに有効である。ｇＮＢが既に上りデータがＵＥに存在することを認識している場合は、ｇＮＢはＵＥに対して、ＳＣｅｌｌのビーム１から上りスケジューリング情報を通知する。ＵＥはｇＮＢに対して、該スケジューリング情報に従って、上りデータを送信する。

【0687】

ＵＥからのＰＲＡＣＨ送信を、ＵＥが通信するビームを検出した後に行ってもよい。ここではステップＳＴ５２１１の処理の後で検出したビームに対してＰＲＡＣＨ送信を行うとよい。あるいは、ＵＥからのＰＲＡＣＨ送信を、ＰＤＣＣＨ受信後下りスケジューリング情報受信前に行ってもよい。ここではステップＳＴ５２１２の処理の後で検出したビームに対してＰＲＡＣＨ送信を行うとよい。早期に上りデータ通信を開始可能となる。

【0688】

続けて、図１４を参照して、ｇＮＢがＵＥと通信を行うビームをＳＣｅｌｌ内で変更する場合のシーケンスについて一例を開示する。ステップＳＴ５２１７において、ｇＮＢはＵＥと通信を行うビームの変更を決定する。例えば、ｇＮＢのＲＲＣ機能部が決定してもよい。ｇＮＢがＵＥと通信を行うビームをどのビームに変更するかを決定する方法として、前述に開示した、どのビームと通信を行うかをｇＮＢが認識する方法を適用するとよい。ステップＳＴ５２１８において、ｇＮＢはＵＥに対して、ＰＣｅｌｌのビーム１によって、ＣＡ用ＳＣｅｌｌの設定情報および該ＳＣｅｌｌに対応付けたビームに関する情報を通知する。ビームに関する情報は、変更後の情報とする。この通知には、ＲＲＣ個別シグナリングを用いる。

【0689】

ｇＮＢはＵＥに対して、ＣＡ用ＳＣｅｌｌの設定情報および変更したビームに関する情報を、ＰＣｅｌｌのビーム１によって通知することを開示したが、ＳＣｅｌｌのビーム１によって通知してもよい。ｇＮＢは、どちらの通信品質が良好かを判断し、通信品質の良好なビームを用いて通知するようにしてもよい。

【0690】

ＰＣｅｌｌのビームによって通知する場合、ＳＣｅｌｌのビームの通信品質の急激な劣化の影響を受けることなく、ｇＮＢはＵＥに対してＣＡ用ＳＣｅｌｌの設定情報および変更したビームに関する情報を通知可能となる。ＵＥは、ｇＮＢから通知されたビームに変更することが可能となる。

【0691】

例えば、ＳＣｅｌｌが高周波数で狭カバレッジで運用されている場合、ＵＥのブロッキングや移動によって通信品質が急激に悪化しやすい。このような場合、ｇＮＢはＰＣｅｌｌのビームを用いて通知するとよい。

【0692】

ＳＣｅｌｌの各ビームは周期的にＳＳを送信する（ステップＳＴ５２１９～ＳＴ５２２１を参照）。また、ＳＣｅｌｌの各ビームは周期的にＢＲＳを送信する（ステップＳＴ５２２２～ＳＴ５２２４を参照）。ＢＲＳは予め決められたパターンの周波数と時間リソースとのうちの少なくとも一方によって送信されてもよい。

【0693】

ステップＳＴ５２２５において、ｇＮＢは、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＭＡＣ制御シグナリングを用いる。ａｃｔ／ｄｅａｃｔ情報はＭＡＣ ＣＥに含めて通知する。ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報に変更がない場合はこの通知を省略してもよい。ステップＳＴ５２２６において、ＵＥは、ａｃｔされたＳＣｅｌｌのＳＳを受信して同期を行う。ａｃｔされたＳＣｅｌｌに変更がない場合、および、既に同期が行われている場合は、この処理を省略してもよい。

【0694】

ステップＳＴ５２２７において、ＵＥは、ＲＲＣ個別シグナリングで通知されたＳＣｅｌｌに対応付けられた変更後のビームのビーム識別子とＢＲＳ構成とのうちの少なくとも一方を用いて、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５２２８において、ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0695】

ステップＳＴ５２２９において、ｇＮＢはＵＥに対して、ＳＣｅｌｌのビーム２から下りスケジューリング情報を通知する。この通知にはＬ１／Ｌ２制御信号が用いられる。ステップＳＴ５２３０において、ｇＮＢはＵＥに対して、該スケジューリング情報に従って、下りデータを送信する。ＵＥは、ステップＳＴ５２２９においてＳＣｅｌｌのビーム２から受信したスケジューリング情報に従って、ステップＳＴ５２３０においてＳＣｅｌｌのビーム２から下りデータを受信する。

【0696】

ＳＣｅｌｌを介して上り送信を行いたいＵＥは、ステップＳＴ５２３１において、ＳＣｅｌｌのビーム２でＰＲＡＣＨ送信を行いｇＮＢとの間でＲＡ処理を行う。ステップＳＴ５２３２において、ＵＥはＳＣｅｌｌのビーム２に対して上りデータ送信を開始する。ＰＲＡＣＨではなく、ＳＲを送信してもよい。上り同期が行われている場合、ＴＡを再度取得する必要が無い場合などに有効である。ｇＮＢが既に上りデータがＵＥに存在することを認識している場合は、ｇＮＢはＵＥに対して、ＳＣｅｌｌのビーム２から上りスケジューリング情報を通知する。ＵＥはｇＮＢに対して、該スケジューリング情報に従って、上りデータを送信する。

【0697】

このようにすることで、ＵＥと通信を行うＳＣｅｌｌのビームを、ビーム１からビーム２に変更することが可能となる。

【0698】

本実施の形態６で開示した方法とすることで、ｇＮＢとＵＥとは、ＳＣｅｌｌのビームを特定して通信を行うことが可能となる。ｇＮＢはＵＥに対して、ＰＣｅｌｌのビームとＳＣｅｌｌのビームとでＣＡを設定可能となる。ｇＮＢがＵＥに対してＣＡを設定することによって、使用する無線リソースを増大できる。このため、ＵＥに対して、高速および大容量の通信サービスを提供可能となる。

【0699】

また、ＵＥは、ＳＣｅｌｌのＳＳを受信した後に、通信を行うビームを選択する処理を実行する必要がない。ＵＥは、ｇＮＢに対して、ＳＣｅｌｌのどのビームを受信しているかを通知する必要が無い。このため、ＵＥは早期に通信するビームを特定でき、ＳＣｅｌｌの追加処理および修正処理を低遅延で行うことが可能となる。

【0700】

実施の形態６によれば、例えば、通信端末装置と、通信端末装置と無線ビームを用いて無線通信を行う基地局装置とを含み、基地局装置によって構成されるセルは、基地局装置の配下にある複数の無線ビームによって、空間分離されており、基地局装置は、無線ビーム単位で、キャリアアグリケーションを設定する、通信システムが提供される。なお、複数の無線ビームは、図８に例示したように複数のＤＵ（言い換えるとＴＲＰ）によって形成されてもよいし、１つのＤＵによって形成されてもよい。

【0701】

この構成によれば、無線ビーム単位でキャリアアグリケーションが設定される。このため、前述のように、ビームフォーミングがサポートされるセルをキャリアアグリゲーションに用いるセルとすることが可能となり、使用する無線リソースを増大することができる。それにより、高速および大容量の通信サービスを提供可能となる。

【0702】

ここで、上記構成は、前述のように、および、以下の変形例１～２で述べるように、様々に変形することが可能である。

【0703】

実施の形態６の変形例１．
ＮＲでは広帯域な周波数リソースを確保するために、高い周波数帯域での運用が要求されている。高い周波数帯域では、ｇＮＢのアンテナとＵＥとの間のブロッキングによるチャネル品質の急峻な劣化が生じやすい。また、高い周波数帯域では伝搬ロスが大きくなるので、狭カバレッジのビームが用いられる。狭カバレッジのビームの運用では、ＵＥの移動にともなってビームの変更が頻繁に生じることになる。

【0704】

実施の形態６で開示した方法では、ＣＡ時にＵＥがモニタするビームの設定および変更の時に、ＲＲＣシグナリングが必要となる。このため、アグリゲーションするビームの設定および変更に時間を要することとなり、所望のビームでの通信までの遅延が大きくなる。遅延が大きいと、ブロッキングおよびＵＥの移動によるビームの設定および変更の処理が間に合わず、ＳＣｅｌｌでの通信を継続することができなくなる場合が生じる。

【0705】

本変形例１では、このような問題を解決する方法を開示する。

【0706】

ｇＮＢはＵＥに対して、ＲＲＣシグナリングによって、ＳＣｅｌｌが構成可能なビームを通知する。実施の形態６では、ＲＲＣシグナリングによって、ＵＥがモニタするビームを通知した。本変形例１では、ＳＣｅｌｌが構成可能なビームを通知する。言い換えると、ｇＮＢはＵＥに対して、ＣＡとして設定可能なＳＣｅｌｌにおける、ＣＡとして構成可能なビームを通知する。この通知はＵＥ個別に行ってもよい。通知するビームに関する情報は、実施の形態６のビームに関する情報を適用するとよい。

【0707】

ｇＮＢはＵＥに対して、ＭＡＣシグナリングで、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する。ＲＲＣシグナリングで通知したＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知するとよい。

【0708】

このようにすることで、ＵＥは、どのＳＣｅｌｌをモニタするかを認識することが可能となる。しかしこれだけでは、該ＳＣｅｌｌのどのビームで通信を行ったらよいかが不明となる。

【0709】

ｇＮＢはＵＥに対して、ＭＡＣシグナリングで、ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を通知する。ＭＡＣシグナリングでａｃｔしたＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を通知するとしてもよい。ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報ではなく、ａｃｔするビームの情報を通知してもよい。ビームの情報としてビームの識別子がある。

【0710】

ＣＡを行うビームを変更する場合、ビームのａｃｔ／ｄｅａｃｔ設定を変更するとよい。ｇＮＢはＵＥに対して、変更したビームのａｃｔ／ｄｅａｃｔ情報を通知するとよい。ＭＡＣ制御情報として、ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を設けてもよい。ａｃｔするＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を設けてもよい。

【0711】

ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報と、ビームのａｃｔ／ｄｅａｃｔ情報とを一つのＭＡＣ ＣＥとしてもよい。情報量を削減でき、ＣＡ設定の処理を簡単化可能となる。

【0712】

ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報と、ビームのａｃｔ／ｄｅａｃｔ情報とを異なるＭＡＣ ＣＥとしてもよい。ＣＡの設定ではなく、ＳＣｅｌｌ内のビームの変更時の設定において、ビームのａｃｔ／ｄｅａｃｔのＭＡＣ ＣＥだけを使用することが可能となる。ビーム変更時の情報量を削減でき、ビーム変更処理を簡単化可能となる。

【0713】

ビームのａｃｔ／ｄｅａｃｔ情報をＭＡＣ ＣＥとする場合の例を開示する。一つのセルで構成可能なビーム数の最大値を決めておく。ＲＲＣシグナリングでＳＣｅｌｌが構成するビームを通知する際のビームに関する情報に、ＳＣｅｌｌが構成するビームに対して０から最大値までのビームインデックスを付与する。言い換えるとリナンバリングする。ビームＩＤおよびＢＲＳに、ビームインデックスを関連付ける。例えば、一つのセルで最大７ビーム構成可能とする。セルが構成するビームに、ビーム＃０からビーム＃６までインデックスを付与する。

【0714】

図１５は、ビームのａｃｔ／ｄｅａｃｔ情報のＭＡＣ ＣＥの一例を示す図である。一つのセルに最大７つのビームまで構成可能とする場合を示している。ＭＡＣ ＣＥは８ビットから構成される。Ｒはリザーブ用のビットである。Ｂ０からＢ６はビーム毎のａｃｔ／ｄｅａｃｔを示すビットである。例えば、１がａｃｔ、０がｄｅａｃｔとしてもよい。Ｂ０からＢ６は、ＲＲＣシグナリングで設定されたビーム毎のビームインデックスである。

【0715】

ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報が各々８ビットで構成される。これらの情報がＳＣｅｌｌのインデックス順に連結される。ｄｅａｃｔされたＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報は、全ビームｄｅａｃｔとしてもよい。あるいは、ａｃｔするＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報のみを、連結するようにしてもよい。連結方法は静的に規格などで予め決めておくとよい。ｇＮＢとＵＥとの両方が該方法を認識することが可能となる。

【0716】

このようにビームのａｃｔ／ｄｅａｃｔ情報をＭＡＣ ＣＥとすることで、ｇＮＢはＵＥに対して、ＭＡＣシグナリングによって、ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を通知することが可能となる。

【0717】

図１６および図１７は、ＭＡＣシグナリングを用いたビーム単位のＣＡの設定シーケンスの一例を示す図である。図１６と図１７とは、境界線ＢＬ５４１の位置で、つながっている。図１６および図１７に示すシーケンスは、図１３および図１４に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。

【0718】

ステップＳＴ５４０１において、ｇＮＢはＵＥに対して、ＰＣｅｌｌのビーム１によって、ＣＡ用ＳＣｅｌｌの設定情報および該ＳＣｅｌｌに対応付けたビームに関する情報を通知する。この通知には、ＲＲＣ個別シグナリングを用いる。ステップＳＴ５４０１において、ＳＣｅｌｌに対応付けて通知するビームは、ＣＡにおいてＵＥに対して構成可能なビームとするとよい。このようにすることで、ｇＮＢはＵＥに対して、ＳＣｅｌｌの中でどのビームがＣＡで構成可能かをＵＥに対して通知することが可能となる。

【0719】

ステップＳＴ５４０２において、ｇＮＢはＵＥに対して、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＭＡＣ制御シグナリングを用いる。ａｃｔ／ｄｅａｃｔ情報はＭＡＣ ＣＥに含めて通知する。ステップＳＴ５４０３において、ｇＮＢはＵＥに対して、ａｃｔしたＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＭＡＣ制御シグナリングを用いる。ａｃｔ／ｄｅａｃｔ情報はＭＡＣ ＣＥに含めて通知する。

【0720】

ステップＳＴ５４０４において、ＵＥは、ａｃｔされたＳＣｅｌｌのＳＳを受信して同期を行う。ステップＳＴ５４０５において、ＵＥは、各ビームのＢＲＳを受信し、ＲＲＣシグナリングによって通知された、ＳＣｅｌｌで構成可能なビームの情報（具体的には、ビーム識別子とＢＲＳ構成とのうちの少なくとも一方と、ビームインデックス）、および、ＭＡＣシグナリングによって通知された、ａｃｔするビームの情報（具体的にはビームインデックス）から、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５４０６において、ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0721】

このようにして、ｇＮＢはＵＥと、ＳＣｅｌｌのビーム１を介して通信を行うことが可能となる。

【0722】

続けて、図１７を参照して、ｇＮＢがＵＥと通信を行うビームをＳＣｅｌｌ内で変更する場合のシーケンスについて一例を開示する。ステップＳＴ５４０７において、ｇＮＢはＵＥと通信を行うビームの変更を決定する。例えば、ｇＮＢのＭＡＣ機能部が決定してもよい。ステップＳＴ５４０８において、ｇＮＢはＵＥに対して、ＰＣｅｌｌのビーム１によって、変更後のビームのａｃｔ／ｄｅａｃｔ情報を通知する。該情報は、ＭＡＣ ＣＥに含められ、ＭＡＣシグナリングによって通知される。

【0723】

ｇＮＢはＵＥに対して、変更後のビームのａｃｔ／ｄｅａｃｔ情報を、ＳＣｅｌｌのビーム１によって通知してもよい。ｇＮＢは、どちらの通信品質が良好かを判断し、通信品質の良好なビームを用いて通知するようにしてもよい。

【0724】

ＰＣｅｌｌのビームによって通知する場合、ＳＣｅｌｌのビームの通信品質の急激な劣化の影響を受けることなく、ｇＮＢはＵＥに対してＣＡ用ＳＣｅｌｌの設定情報および変更したビームに関する情報を通知可能となる。ＵＥは、ｇＮＢから通知されたビームに変更することが可能となる。

【0725】

ステップＳＴ５４０９において、ＵＥは各ビームのＢＲＳを受信し、ＲＲＣシグナリングによって通知された、ＳＣｅｌｌで構成可能なビームの情報（具体的には、ビーム識別子とＢＲＳ構成とのうちの少なくとも一方と、ビームインデックス）、および、ＭＡＣシグナリングによって通知された、変更後のａｃｔするビームの情報（具体的にはビームインデックス）から、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５４１０において、ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0726】

このようにすることで、ＵＥと通信を行うＳＣｅｌｌのビームを、ビーム１からビーム２に変更することが可能となる。

【0727】

本変形例１で開示した方法とすることで、ＭＡＣシグナリングによってビームのａｃｔ／ｄｅａｃｔを実行可能となる。

【0728】

このため、ＵＥがビームのメジャメントを行ってから、通信品質の良好なビームを用いたＣＡが開始されるまでの遅延を低減できる。したがって、ブロッキングおよびＵＥの移動による急激な通信品質の悪化により、ＳＣｅｌｌで通信が開始できないという問題の発生を低減可能となる。

【0729】

また、ＵＥがビームのメジャメントを行ってから、通信品質の良好なビームへの変更までの遅延を低減できる。したがって、ブロッキングおよびＵＥの移動による急激な通信品質の悪化により、ＳＣｅｌｌで通信断の発生を低減可能となる。

【0730】

このように、ビームの設定および変更に時間を要することなく、所望のビームを用いた通信までの遅延を低減できる。したがって、ビームの設定および変更の処理時間を短縮でき、ブロッキングおよびＵＥの移動によるＳＣｅｌｌでの通信開始不可および通信断の発生を低減可能となる。

【0731】

実施の形態６の変形例２．
変形例１で述べた問題を解決する他の方法を開示する。

【0732】

ｇＮＢはＵＥに対して、ＲＲＣシグナリングによって、ＳＣｅｌｌが構成可能なビームを通知する。実施の形態６では、ＲＲＣシグナリングでＵＥがモニタするビームを通知した。本変形例２では、ＳＣｅｌｌが構成可能なビームを通知する。言い換えると、ｇＮＢはＵＥに対して、ＣＡとして設定可能なＳＣｅｌｌにおける、ＣＡとして構成可能なビームを通知する。この通知はＵＥ個別に行ってもよい。通知するビームに関する情報は、実施の形態６のビームに関する情報を適用するとよい。

【0733】

ｇＮＢはＵＥに対して、Ｌ１／Ｌ２制御信号で、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する。ＲＲＣシグナリングで通知したＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知するとよい。ｇＮＢはＵＥに対してＬ１／Ｌ２制御信号で通知することで、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔを低遅延で通知することが可能となる。

【0734】

ｇＮＢがＵＥに対してＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する他の方法として、ＭＡＣシグナリングで通知する方法としてもよい。実施の形態６の変形例１で開示した方法を適用するとよい。この場合、再送制御が行われるため低受信誤り率で通知することが可能となる。

【0735】

このようにすることで、ＵＥは、どのＳＣｅｌｌをモニタするかを認識することが可能となる。しかしこれだけでは、該ＳＣｅｌｌのどのビームで通信を行ったらよいかが不明となる。

【0736】

ｇＮＢはＵＥに対して、Ｌ１／Ｌ２制御信号で、ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を通知する。Ｌ１／Ｌ２制御信号でａｃｔしたＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を通知するとしてもよい。ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報ではなく、ａｃｔするビームの情報を通知してもよい。ビームの情報としてビームの識別子がある。

【0737】

ＣＡを行うビームを変更する場合、ビームのａｃｔ／ｄｅａｃｔ設定を変更するとよい。ｇＮＢはＵＥに対して、変更したビームのａｃｔ／ｄｅａｃｔ情報を通知するとよい。Ｌ１／Ｌ２制御情報として、ＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を設けてもよい。ａｃｔするＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報を設けてもよい。

【0738】

ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報とＳＣｅｌｌが構成するビームのａｃｔ／ｄｅａｃｔ情報とのうちの少なくとも一方をＤＣＩとしてもよい。ｇＮＢからＵＥに対して下りリンクで該情報を通知する。ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報と、ビームのａｃｔ／ｄｅａｃｔ情報とを一つのＤＣＩに含めてもよい。情報量を削減でき、ＣＡ設定の処理を簡単化可能となる。

【0739】

ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報と、ビームのａｃｔ／ｄｅａｃｔ情報とを異なるＤＣＩとしてもよい。ＣＡの設定ではなく、ＳＣｅｌｌ内のビームの変更時の設定において、ビームのａｃｔ／ｄｅａｃｔのＭＡＣ ＣＥだけを使用することが可能となる。ビーム変更時の情報量を削減でき、ビーム変更処理を簡単化可能となる。

【0740】

これらの情報用にＤＣＩに新たなフォーマットを設けてもよい。

【0741】

ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報、および、ビームのａｃｔ／ｄｅａｃｔ情報として、ビームインデックスを用いるとよい。実施の形態６の変形例１と同様に、ビットマップとしてもよい。情報量を削減できる。

【0742】

ビームのａｃｔ／ｄｅａｃｔ情報の通知方法について開示する。

【0743】

ｇＮＢは、ＵＥに対して、ＳＣｅｌｌのＬ１／Ｌ２制御情報で、ビームのａｃｔ／ｄｅａｃｔ情報を通知する。ａｃｔするビームの情報を通知してもよい。ＵＥは、ａｃｔされたＳＣｅｌｌのビームを受信する。例えば、受信電力あるいは受信品質の高いビームを受信する。ＵＥは、受信したビームのＢＲＳからビームＩＤを特定し、特定したビームＩＤをｇＮＢに通知する。あるいは、ＵＥは受信したビームでＰＲＡＣＨ送信を行いＲＡ処理を起動することによって、ビームＩＤをｇＮＢに通知してもよい。ＵＥは該ビームをモニタする。

【0744】

ＵＥからビームＩＤを受信したｇＮＢはＵＥに対して、該ビームのＬ１／Ｌ２制御信号で、ＵＥに対してａｃｔするビームを通知する。ＵＥは、ａｃｔされたビームをモニタする。ＵＥは、ａｃｔされたビームの物理下り制御チャネルを受信する。一つのビームが用いられてもよいし、複数のビームが用いられてもよい。このようにすることで、ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を、ＵＥが認識することが可能となる。

【0745】

前述の方法では、ｇＮＢがＣＡの開始を決定し、ＵＥに対してＣＡを行うＳＣｅｌｌのａｃｔを通知した後に、ＵＥとｇＮＢとの間でビームを特定する処理を行うことになる。したがって、ＵＥが実際にＣＡを設定されたセルと通信を行えるようになるまで遅延が生じてしまう。

【0746】

ビームのａｃｔ／ｄｅａｃｔ情報の他の通知方法について開示する。

【0747】

ｇＮＢは、ＵＥに対して、ＰＣｅｌｌのＬ１／Ｌ２制御情報で、ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知する。ａｃｔするＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知してもよい。ＳＣｅｌｌのａｃｔするビームの情報を通知してもよい。ＵＥは、ＰＣｅｌｌから通知されたＳＣｅｌｌのビームをモニタする。ＵＥは、ａｃｔされたビームの物理下り制御チャネルを受信する。一つのビームが用いられてもよいし、複数のビームが用いられてもよい。このようにすることで、ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を、ＵＥが認識することが可能となる。

【0748】

例えば、ａｃｔしているＳＣｅｌｌの情報と、該ＳＣｅｌｌ内でａｃｔするビームの情報とを、同じＤＣＩ内に関連付けて含めるようにしてもよい。ｇＮＢがＵＥに対して、これらの情報を同時に通知することによって、ＵＥは、ＳＣｅｌｌと同期を実行するのにあわせてＢＲＳを受信し、それにより、モニタするビームを特定して該ビームの物理下り制御チャネルを受信することが可能となる。短時間でＵＥはＳＣｅｌｌのビームをモニタ可能となる。

【0749】

ＰＣｅｌｌの物理下り制御チャネルに対して、ＳＣｅｌｌのビームの情報を含むＤＣＩをマッピングしてもよい。ＰＣｅｌｌの情報が含まれるＤＣＩと、ＳＣｅｌｌの情報が含まれるＤＣＩとを異ならせ、該ＳＣｅｌｌの情報が含まれるＤＣＩにビームの情報を含ませてもよい。

【0750】

前述の２つのビームのａｃｔ／ｄｅａｃｔ情報の通知方法を組合せてもよい。組合せた場合の例を開示する。

【0751】

ｇＮＢはＵＥに対して、ＰＣｅｌｌのＬ１／Ｌ２制御情報で、ＳＣｅｌｌのａｃｔする一つのビーム情報を通知する。ａｃｔしているＳＣｅｌｌの情報と、該ＳＣｅｌｌ内でａｃｔするビームの情報とを、同じＤＣＩ内に関連付けて含めるようにしてもよい。ＵＥは、ＰＣｅｌｌから通知されたＳＣｅｌｌの一つのビームをモニタする。ＵＥはａｃｔされた一つのビームの物理下り制御チャネルを受信する。

【0752】

ｇＮＢはＵＥに対して、Ｓｃｅｌｌの該一つのビームのＬ１／Ｌ２制御信号で、ａｃｔするビームの情報を通知する。あるいは、ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知してもよい。一つのビームが用いられてもよいし、複数のビームが用いられてもよい。ＵＥは、ａｃｔされたビームをモニタする。ＵＥは、ａｃｔされたビームの物理下り制御チャネルを受信する。

【0753】

この方法においては、ＵＥがＳＣｅｌｌ内のビームのａｃｔ／ｄｅａｃｔ情報を受信するためにｇＮＢに対して上り信号を送信する必要がない。このため、ＵＥは、ＳＣｅｌｌ内でどのビームを使用するかを、早期に特定可能となる。また、ＵＥの消費電力を低減可能となる。

【0754】

図１８～図２０は、Ｌ１／Ｌ２制御信号を用いたビーム単位のＣＡの設定シーケンスの一例を示す図であり、前述の２つのビームのａｃｔ／ｄｅａｃｔ情報の通知方法を組合せた場合の例である。図１８～図２０は、境界線ＢＬ５５１，Ｌ５５２の位置で、つながっている。図１８～図２０に示すシーケンスは、図１６および図１７に示すシーケンスと同一のステップを含んでいるので、同一のステップについては同一のステップ番号を付して、共通する説明を省略する。

【0755】

ステップＳＴ５５０１において、ｇＮＢはＵＥに対して、ＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＬ１／Ｌ２制御信号を用いる。ａｃｔ／ｄｅａｃｔ情報はＤＣＩに含めて通知する。ステップＳＴ５５０２において、ｇＮＢはＵＥに対して、ａｃｔしたＳＣｅｌｌの一つのビームのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＬ１／Ｌ２制御信号を用いる。ａｃｔ／ｄｅａｃｔ情報はＤＣＩに含めて通知する。

【0756】

ステップＳＴ５５０３において、ＵＥは、ａｃｔされたＳＣｅｌｌのＳＳを受信して同期を行う。ステップＳＴ５５０４において、ＵＥは各ビームのＢＲＳを受信し、ＲＲＣシグナリングによって通知された、ＳＣｅｌｌで構成可能なビームの情報（具体的には、ビーム識別子とＢＲＳ構成とのうちの少なくとも一方と、ビームインデックス）、および、ＰＣｅｌｌからのＬ１／Ｌ２制御信号によって通知された、ａｃｔする一つのビームの情報（具体的にはビームインデックス）から、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５５０５において、ＵＥは、モニタする一つのビームの物理下り制御チャネル（PDCCH）を受信する。

【0757】

このようにして、ｇＮＢはＵＥと、ＳＣｅｌｌのビーム１を介して通信を行うことが可能となる。

【0758】

図１９を参照し、ステップＳＴ５５０６において、ｇＮＢはＵＥに対して、ＳＣｅｌｌのビーム１を介してＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知する。この通知にはＬ１／Ｌ２制御信号を用いる。ａｃｔ／ｄｅａｃｔ情報はＤＣＩに含めて通知する。

【0759】

ステップＳＴ５５０７において、ＵＥは各ビームのＢＲＳを受信し、ＲＲＣシグナリングによって通知された、ＳＣｅｌｌで構成可能なビームの情報（具体的にはビーム識別子とＢＲＳ構成とのうちの少なくとも一方と、ビームインデックス）、および、ＳＣｅｌｌからのＬ１／Ｌ２制御信号によって通知された、ＳＣｅｌｌのａｃｔするビームの情報（具体的にはビームインデックス）から、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５５０８において、ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0760】

このようにして、ｇＮＢはＵＥと、ＳＣｅｌｌのビーム２を介して通信を行うことが可能となる。

【0761】

続けて、図２０を参照して、ｇＮＢがＵＥと通信を行うビームをＳＣｅｌｌ内で変更する場合のシーケンスについて一例を開示する。ステップＳＴ５５０９において、ｇＮＢはＵＥと通信を行うビームの変更を決定する。例えば、ｇＮＢのＳＣｅｌｌのＰＨＹ機能部が決定してもよい。ステップＳＴ５５１０において、ｇＮＢはＵＥに対して、ＳＣｅｌｌのビーム１によって、変更後のビームのａｃｔ／ｄｅａｃｔ情報を通知する。該情報は、ＤＣＩに含められ、Ｌ１／Ｌ２制御信号によって通知される。

【0762】

ｇＮＢはＵＥに対して、変更後のビームのａｃｔ／ｄｅａｃｔ情報を、ＰＣｅｌｌのビーム１によって通知してもよい。ｇＮＢは、どちらの通信品質が良好かを判断し、通信品質の良好なビームを用いて通知するようにしてもよい。

【0763】

ＰＣｅｌｌのビームによって通知する場合、ＳＣｅｌｌのビームの通信品質の急激な劣化の影響を受けることなく、ｇＮＢはＵＥに対して変更したビームに関する情報を通知可能となる。ＵＥは、ｇＮＢから通知されたビームに変更することが可能となる。

【0764】

ステップＳＴ５５１１において、ＵＥは各ビームのＢＲＳを受信し、ＲＲＣシグナリングによって通知された、ＳＣｅｌｌで構成可能なビームの情報（具体的にはビーム識別子とＢＲＳ構成とのうちの少なくとも一方と、ビームインデックス）、および、ＳＣｅｌｌからのＬ１／Ｌ２制御信号によって通知された、変更後のａｃｔするビームの情報（具体的にはビームインデックス）から、ＳＣｅｌｌ内でモニタするビームを検出する。ステップＳＴ５５１２において、ＵＥは、モニタするビームの物理下り制御チャネル（PDCCH）を受信する。

【0765】

このようにすることで、ＵＥと通信を行うＳＣｅｌｌのビームを、ビーム２からビーム３に変更することが可能となる。

【0766】

このように、ビームの情報を通知するのにＬ１／Ｌ２制御信号を用いるので、実施の形態６およびそれの変形例１に比べてさらにダイナミックに、アグリゲーションするビームの設定および変更が可能となる。このため、ビームの設定および変更に要する時間をさらに削減でき、所望のビームを用いた通信までの遅延をさらに低減できる。したがって、ビームの設定および変更の処理時間をさらに短縮でき、ブロッキングおよびＵＥの移動によるＳＣｅｌｌでの通信開始不可および通信断の発生を低減可能となる。

【0767】

前述の方法において、ＰＣｅｌｌで通知するＳＣｅｌｌのビームとしてベストなビームを特定して設定しなくてもよい。通信可能な通信品質を有するビームを設定すればよい。ＳＣｅｌｌの該ビームを用いたＣＡを開始した後に、ＳＣｅｌｌで通知するビームの変更においてベストなビームを設定すればよい。ＳＣｅｌｌと通信を開始した後のＳＣｅｌｌビームのメジャメントになるのでＵＥでのメジャメント処理が簡易になり、また低消費電力化できる。

【0768】

前述の方法では、ｇＮＢはＵＥに対して、ＰＣｅｌｌのＬ１／Ｌ２制御情報で、ＳＣｅｌｌのａｃｔする一つのビーム情報を通知することを開示した。ＳＣｅｌｌのａｃｔする一つのビーム情報に限らず、複数のビーム情報であってもよい。ｇＮＢはＵＥに対して、ＰＣｅｌｌのＬ１／Ｌ２制御情報で、ＳＣｅｌｌのａｃｔする複数のビーム情報を通知してもよい。

【0769】

ＵＥは、ＰＣｅｌｌから通知されたＳＣｅｌｌの複数のビームをモニタする。ＵＥはａｃｔされた複数のビームの物理下り制御チャネルを受信する。

【0770】

ｇＮＢはＵＥに対して、Ｓｃｅｌｌの該複数のビームのうちの一つのビームのＬ１／Ｌ２制御信号で、ａｃｔするビームの情報を通知する。あるいは、ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知してもよい。一つのビームが用いられてもよいし、複数のビームが用いられてもよい。ＵＥは、ａｃｔされた該複数のビームをモニタするため、該複数のビームのうちの一つのビームで送信されるＬ１／Ｌ２制御信号を受信できる。

【0771】

ＳＣｅｌｌのａｃｔするビームを複数のビームとすることで、いくつかのビームの通信品質が悪化したとしても他のビームで、ａｃｔするビームの情報を通知することが可能となる。高信頼で安定した通信を行うことが可能となる。

【0772】

実施の形態６から実施の形態６の変形例２までで開示した方法を適宜組合せてもよい。例えば、ｇＮＢはＵＥに対して、ＰＣｅｌｌでＳＣｅｌｌのａｃｔ／ｄｅａｃｔ情報をＭＡＣシグナリングによって通知し、ｇＮＢはＵＥに対して、ＰＣｅｌｌで、ＡｃｔしたＳＣｅｌｌのａｃｔする一つのビームに関する情報をＭＡＣシグナリングによって通知し、ＵＥが、ａｃｔしたＳＣｅｌｌのａｃｔする一つのビームと通信を開始し、その後に、Ｌ１／Ｌ２制御信号を用いてＳＣｅｌｌでＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報を通知する。

【0773】

ａｃｔするＳＣｅｌｌおよびａｃｔするビームの情報を、ＭＡＣシグナリングを用いて通知することで、ＵＥでの受信誤り率を低減できる。このため、ＣＡの設定を確実に行うことが可能となるので、ｇＮＢとＵＥとの間での誤動作を低減できる。ＳＣｅｌｌのビームのａｃｔ／ｄｅａｃｔ情報をＬ１／Ｌ２制御信号を用いて通知することで、ＵＥにダイナミックに低遅延で通知することが可能となる。たとえ高い周波数での運用におけるブロッキングによって、あるいはＵＥの移動によって、通信に適するビームが頻繁に変わるような場合であっても、ＣＡを行うビームを低遅延で設定および変更することが可能となる。

【0774】

このように、実施の形態６から実施の形態６の変形例２までで開示した方法を適宜組合せることによって、刻々と変化する電波伝搬状況に応じて低遅延で、ＣＡを行うビームを設定および変更することが可能となる。

【0775】

実施の形態７．
ＬＴＥにおけるデータフローは、ＣＮ（Core Network）からＲＡＮ（Radio Access Network）にわたってベアラベースで行われている。各ノード間でベアラが設定される（非特許文献１参照）。ＬＴＥではＥＰＳベアラとＤＲＢ（Data Radio Bearer）とは１対１マッピングであった。

【0776】

しかし、５Ｇにおけるデータフローについては、ＣＮ－ＲＡＮ間ではフローベース制御を行うこと、および、ＲＡＮではベアラベース制御を行うことが議論されている（３ＧＰＰ Ｒ２－１６６８９２（以下「参考文献２」という）参照）。ＣＮ－ＲＡＮ間の制御がフローベース制御となった場合、従来Ｐ－ＧＷとＵＥとの間で設定されていたＥＰＳベアラ、および、従来Ｓ－ＧＷとＵＥとの間で設定されていたＥ－ＲＡＢは設定されなくなる。しかし、ＲＡＮではベアラベースの制御が維持されることになったので、データ用のＲａｄｉｏ ＢｅａｒｅｒとしてＤＲＢが設定されることになる。

【0777】

５Ｇでは、サービスフローというよりもＱｏＳ（Quality of Service）フローを用いることが検討されている（参考文献２参照）。３ＧＰＰでは、ＱｏＳフローのためにパケット毎にＱｏＳマーキングを用いることが、規格として決定された。ＱｏＳマーキングはスカラ値で設定される。したがって、異なるサービス／セッションであっても同じＱｏＳを有する場合は、同じＱｏＳフローに分類される。また、複数のＱｏＳフローを一つのＤＲＢにマッピングすることを可能にすることが検討されている。

【0778】

このため、ＲＡＮのノードであるｇＮＢは、一つまたは複数の異なるＰＤＵ（Protocol Data Unit）セッションからのトラフィックを、一つのＤＲＢにマッピングすることになる。ｇＮＢは、ＰＤＵセッションからのトラフィックのＱｏＳに応じてＤＲＢを設定する。ｇＮＢは、ＰＤＵセッションからのデータを、設定したＤＲＢにマッピングする。

【0779】

ここでは、５ＧでのＣＮをＮＧ-ＣＮと称する。ＮＧ－ＣＮ傘下のｇＮＢでＤＣ（Dual Connectivity）が設定される場合について検討する。ＤＣはベアラ毎に設定される。ＤＣでは３つのベアラタイプがサポートされる。ＭＣＧ（Master Cell Group）ベアラ、ＳＣＧ（Secondary Cell Group）ベアラ、スプリットベアラである（非特許文献１参照）。従来のＬＴＥにおけるＤＣでは、ＭｅＮＢ（Master eNB）がＳｅＮＢ（Secondary eNB）のベアラ設定を要求する。

【0780】

しかし、従来のベアラ設定要求は、Ｅ－ＲＡＢパラメータを用いて行われていた。しかし、５ＧにおけるＮＧ－ＣＮではＥ－ＲＡＢが無くなった。したがって、ＤＣにおけるベアラ設定要求にＥ－ＲＡＢパラメータを用いることはできなくなってしまう。このため、ＤＣの設定方法（例えば、ＭｇＮＢ（Master gNB）からＳｇＮＢ（Secondary gNB）へのベアラの設定要求方法、および、ＳｇＮＢにおけるＤＣ用ベアラの設定方法）が不明になるという問題が発生する。

【0781】

本実施の形態７ではこのような問題を解決する方法を開示する。

【0782】

ＳｇＮＢが、ＰＤＵセッションのＱｏＳに関する情報を用いて、ＤＣ用ベアラ設定を行う。ＭｇＮＢはＳｇＮＢに対して、ＮＧ－ＣＮ（ＣＰ）より通知されたＰＤＵセッションに関する情報に含まれるＱｏＳに関する情報を用いてベアラ設定要求を行う。３ＧＰＰでは、ＰＤＵセッション設立において、ＮＧ－ＣＮ（ＣＰ）からｇＮＢに対して、ＰＤＵセッションに関する情報を通知することが検討されている。ＰＤＵセッションに関する情報として、ＰＤＵセッションのコンテキストを通知すること、および、ＰＤＵセッションコンテキストにＱｏＳに関する情報が含まれることが検討されている（非特許文献６参照）。このようなＰＤＵセッションに関する情報に含まれるＱｏＳに関する情報を用いてもよい。

【0783】

ＳｇＮＢは、ＭｇＮＢからベアラ設定要求とともに、あるいはベアラ設定要求メッセージに含められて通知されたＰＤＵセッションコンテキスト内のＱｏＳに関する情報を用いて、ＤＣ用のＤＲＢを設定する。スプリットベアラを設定する場合、ＭｇＮＢは、ＰＤＵセッションコンテキスト内のＱｏＳに関する情報の値を変更し、変更後の値をＳｇＮＢに通知してもよい。ＭｇＮＢ側のベアラとＳｇＮＢ側のベアラとでＰＤＵセッションに要求されるＱｏＳを満たすように、ＤＣ用のＤＲＢを設定すればよい。

【0784】

ＭｇＮＢはＳｇＮＢに対して、ＤＣを行うＰＤＵセッションのセッション識別子を通知してもよい。ＰＤＵセッションのＱｏＳに関する情報と関連付けてＰＤＵセッション識別子を通知するとよい。ベアラ設定要求とともに、あるいは、ベアラ設定要求メッセージに含めて通知してもよい。

【0785】

ＤＣを行うＰＤＵセッション識別子を通知することで、ＳｇＮＢは、ＮＧ－ＣＮにおけるどのＰＤＵセッションに対してＤＣを行うのかを認識することができる。ＳｇＮＢで、ＤＣを行うＰＤＵセッションとＤＲＢとのマッピングを可能にする。

【0786】

ＰＤＵセッションコンテキスト内のＱｏＳに関する情報の例として、３ＧＰＰでは以下のようなパラメータが提案されている（非特許文献６参照）。これらのＱｏＳに関する情報を用いてもよい。

【0787】

（１）フロー優先度指標、
（２）フロー優先度レベル、
（３）パケット優先度指標、
（４）パケット破棄優先度指標、
（５）最大フロービットレート、
（６）保証フロービットレート、
（７）セッションビットレート、
（８）ＱｏＳ指標。

【0788】

ＰＤＵセッションに関する情報のＱｏＳに関する情報として、ＱＣＩを設けてもよい。ＰＤＵセッションに関する情報のＱｏＳに関する情報として、許容遅延に関する情報を設けてもよい。ＭｇＮＢはＳｇＮＢに対して、ＮＧ－ＣＮ（ＣＰ）より通知されたＰＤＵセッションに関する情報に含まれるＱＣＩ情報や許容遅延に関する情報を用いて、ベアラ設定要求を行ってもよい。

【0789】

前述したように、ＤＲＢに複数のＰＤＵセッションが含まれる場合がある。したがって、ＤＣを設定するＤＲＢに複数のＰＤＵセッションが含まれる場合がある。このような場合、ＭｇＮＢはＳｇＮＢに対して、複数のＰＤＵセッションのＰＤＵセッションコンテキスト内のＱｏＳに関する情報を通知するとよい。ＳｇＮＢは、ＭｇＮＢから受信した複数のＰＤＵセッションコンテキスト内のＱｏＳに関する情報を用いて、ＤＣ用のＤＲＢを設定する。

【0790】

図２１は、本実施の形態７におけるＤＣ（ＳＣＧベアラ）設定方法を説明する図である。図２１の左側の（ａ）は、ＭｇＮＢを用いたＭＣＧベアラ設定時の状態であり、ＤＣを設定する前の状態としてもよい。図２１の右側の（ｂ）は、ＳｇＮＢを用いたＳＣＧベアラ設定時の状態であり、ＤＣ（ＳＣＧベアラ）を設定した状態としてもよい。

【0791】

ＮＧ－ＵＰＦは、ＮＧ－ＣＮのＵ－Ｐｌａｎｅのファンクションを示す。図では下りリンクについて示している。状態（ａ）では、ＮＧ－ＵＰＦからＭｇＮＢに対して２つのＰＤＵセッションフローが設定される場合について示している。２つのＰＤＵセッションフローをＰＤＵセッション＃１とＰＤＵセッション＃２とする。ＭｇＮＢでは、２つのＰＤＵセッションに対して一つのＤＲＢ＃Ｍ１が設定され、マッピングされる。

【0792】

状態（ｂ）に示すように、ＤＣ（ＳＣＧベアラ）が設定されることによって、ＭＣＧベアラからＳＣＧベアラにスイッチされる。ＤＣはベアラ毎に設定されるので、ＳｇＮＢにおいてＤＲＢ＃Ｓ１が設定され、ＭｇＮＢのＤＲＢ＃Ｍ１がＳｇＮＢのＤＲＢ＃Ｓ１にスイッチされる。このため、ＭｇＮＢのＤＲＢ＃Ｍ１にマッピングされていた全ＰＤＵセッションが、ＤＲＢ＃Ｓ１にマッピングされる。

【0793】

ＮＧ－ＵＰＦは、ＤＣ（ＳＣＧベアラ）が設定されることによって、ＤＲＢ＃Ｍ１にマッピングされていた全ＰＤＵセッションを、ＭｇＮＢからＳｇＮＢにパススイッチする。ＮＧ－ＣＮ、ｇＮＢ、ＵＥ間でＤＣを設定する。

【0794】

図２２は、本実施の形態７におけるＤＣ（スプリットベアラ）設定方法を説明する図である。

【0795】

図２２の左側の（ａ）は、ＭｇＮＢを用いたＭＣＧベアラ設定時の状態であり、ＤＣを設定する前の状態としてもよい。状態（ａ）は図２１の状態（ａ）と同じなので説明を省略する。図２２の右側の（ｂ）は、ＳｇＮＢを用いたスプリットベアラ設定時の状態であり、ＤＣ（スプリットベアラ）を設定した状態としてもよい。

【0796】

状態（ｂ）に示すように、ＤＣ（スプリットベアラ）が設定されることによって、ＭＣＧベアラからスプリットベアラにスイッチされる。ＤＣはベアラ毎に設定されるので、ＭｇＮＢのＤＲＢ＃Ｍ１が、ＭｇＮＢによって設定されるＤＲＢ＃Ｍ３と、ＳｇＮＢによって設定されるＤＲＢ＃Ｓ５とに、スプリットされる。このため、ＭｇＮＢのＤＲＢ＃Ｍ１にマッピングされていた全ＰＤＵセッションが、ＤＲＢ＃Ｍ３とＤＲＢ＃Ｓ５とにスプリットされてマッピングされる。

【0797】

ＮＧ－ＵＰＦは、ＤＣ（スプリットベアラ）が設定された場合は、ＤＲＢ＃Ｍ１にマッピングされていた全ＰＤＵセッションを、ＭｇＮＢからＳｇＮＢにパススイッチする必要は無く、ＭｇＮＢのままでよい。このように、ＤＣ（スプリットベアラ）は、ｇＮＢ、ＵＥ間で設定される。

【0798】

図２３および図２４は、本実施の形態７におけるＤＣ（ＳＣＧベアラ）設定シーケンスの一例を示す図である。図２３と図２４とは、境界線ＢＬ６３１の位置で、つながっている。ＳｇＮＢがＤＲＢマッピングを行う。２つのＰＤＵセッションが設立され、これら２つのＰＤＵセッションが１つのＤＲＢにマッピングされる場合について示している。図２３および図２４では、ＰＤＵセッションとしているが、ＰＤＵセッションの代わりに、ＱｏＳによって構成されたＱｏＳフローに適用してもよい。

【0799】

ステップＳＴ６３０１において、ＮＧ－ＣＰＦはＭｇＮＢに対してＰＤＵセッション要求を行う。ＮＧ－ＣＰＦは、ＮＧ－ＣＮのＣ－Ｐｌａｎｅのファンクションを示す。ＰＤＵセッション要求においてＰＤＵセッションコンテキストを通知する。ＰＤＵセッションコンテキスト内にＱｏＳに関する情報を含む。ここでは、ＰＤＵセッション＃１とする。

【0800】

ステップＳＴ６３０２において、ＭｇＮＢはＰＤＵセッション＃１用のＤＲＢを設定する。ＱｏＳに関する情報などを考慮してＤＲＢを設定する。ステップＳＴ６３０３，ＳＴ６３０４において、ＭｇＮＢはＵＥに対して、ＤＲＢ設定に関する情報を通知する。これにより、ＵＥはＭｇＮＢとの間でＤＲＢを設定する。ステップＳＴ６３０６，ＳＴ６３０５において、ＮＧ－ＵＰＦとＭｇＮＢとの間およびＭｇＮＢとＵＥとの間で、データ通信が行われる。ＭｇＮＢはＰＤＵセッションとＤＲＢとのマッピングを行う。

【0801】

ステップＳＴ６３０７において、ＮＧ－ＣＰＦはＭｇＮＢに対して、ＰＤＵセッション＃１とは異なるＰＤＵセッション要求を行う。ここでは、ＰＤＵセッション＃２とする。ステップＳＴ６３０８において、ＭｇＮＢはＰＤＵセッション＃２用のＤＲＢを設定する。ＱｏＳに関する情報などを考慮してＤＲＢを設定する。ここでは、既存のＰＤＵセッション＃１のために設定したＤＲＢにマッピングする場合について示す。ＰＤＵセッション＃１とＰＤＵセッション＃２とが同じＤＲＢにマッピングされることになる。

【0802】

既存のＤＲＢを用いることになるので、ＵＥに対して新たなＤＲＢの設定は不要となる。ステップＳＴ６３１０，ＳＴ６３０９において、ＮＧ－ＵＰＦとＭｇＮＢとの間およびＭｇＮＢとＵＥとの間で、データ通信が行われる。ＭｇＮＢはＰＤＵセッションとＤＲＢとのマッピングを行う。ＭｇＮＢはＰＤＵセッション＃１とＰＤＵセッション＃２とを同じＤＲＢにマッピングする。

【0803】

ステップＳＴ６３１１において、ＭｇＮＢはＵＥに対してＤＣ（ＳＣＧベアラ）を設定することを決定する。ステップＳＴ６３１２において、ＭｇＮＢは、ＳｇＮＢに対して、ＳｇＮＢ追加要求メッセージを通知する。ＳｇＮＢ追加要求メッセージにＰＤＵセッションのＱｏＳに関する情報を含める。ＭｇＮＢは、ＮＧ－ＣＰＦからＰＤＵセッション要求時に通知されたＰＤＵセッションのＱｏＳに関する情報を用いるとよい。ここでは、ＰＤＵセッションコンテキストに含まれるＱｏＳに関する情報とする。

【0804】

ベアラ毎にＤＣを設定するために、ＳｇＮＢ追加要求メッセージに、ＤＣを行うＤＲＢにマッピングされる全ＰＤＵセッションのＱｏＳに関する情報を含める。ここでは、ＰＤＵセッション＃１のＱｏＳに関する情報と、ＰＤＵセッション＃２のＱｏＳに関する情報とを含める。

【0805】

また、ＭｇＮＢはＳｇＮＢに対して、ＳｅＮＢ追加要求メッセージに、ＰＤＵセッション識別子を含めて通知してもよい。ＰＤＵセッション識別子と、各々のＱｏＳに関する情報とを、関連付けて通知してもよい。このようにすることで、ＳｇＮＢはどのＰＤＵセッションがどのＱｏＳであるかを認識することが可能となる。

【0806】

ステップＳＴ６３１３において、ＳｇＮＢは、ＭｇＮＢから受信したＰＤＵセッションのＱｏＳに関する情報を考慮してＤＲＢを設定する。ここでは、ＰＤＵセッション＃１とＰＤＵセッション＃２との両方のＱｏＳに関する情報を考慮して、ＤＲＢを設定する。ＳｇＮＢは、ＤＲＢを設定する際に、自ノードの負荷などを考慮してもよい。ＳｇＮＢにおいて、ＰＤＵセッション＃１とＰＤＵセッション＃２との両方のＱｏＳに見合うＤＲＢを設定できない場合は、ＭｇＮＢに対してＳｇＮＢ追加要求に対する拒否メッセージを通知してもよい。拒否メッセージに、拒否理由を含めるとよい。例えば、過負荷などの理由がある。

【0807】

ステップＳＴ６３１４において、ＳｇＮＢはＭｇＮＢに対して、ＤＣを行うＤＲＢ設定を通知する。ＤＲＢ設定は、ＳＣＧ設定のＳＣＧベアラ設定情報に含めて、通知するとよい。ステップＳＴ６３１５，ＳＴ６３１６において、ＭｇＮＢはＵＥに対して、ＳｇＮＢのＤＲＢ設定に関する情報を通知する。これによりＵＥはＳｇＮＢとの間でＤＲＢを設定する。ＵＥとの間でＤＲＢ設定を含むＳＣＧ設定を行ったＭｇＮＢは、ステップＳＴ６３１７において、ＳｇＮＢに対して、ＳｇＮＢ再設定が完了したことを通知する。ステップＳＴ６３１８において、ＵＥはＳｇＮＢに対してＲＡ処理を行う。ＵＥは上りも含めてＳｇＮＢとの通信が可能となる。

【0808】

ステップＳＴ６３１９において、ＭｇＮＢはＳＮ（シーケンス番号）ステータスを転送する。ＰＤＵセッション＃１とＰＤＵセッション＃２とのデータにあわせてＳＮを設け、該ＳＮのステータスを転送する。他の方法として、ＰＤＵセッション毎にＳＮを設けて、ＰＤＵセッション毎のＳＮステータスを転送してもよい。例えば、ＰＤＵセッション＃１のデータとＰＤＵセッション＃２のデータとのそれぞれに対して個別にＳＮを設け、該二つのＳＮのステータスを転送する。このようにすることで、ＳｇＮＢはＭｇＮＢでのデータ処理状態を、ＰＤＵセッション毎に認識することが可能となる。

【0809】

ＮＧ－ＵＰＦからの下りデータは、まだＭｇＮＢに対して送信されている。このため、ステップＳＴ６３２０においてＭｇＮＢは、ＮＧ－ＵＰＦからのデータをＳｇＮＢに転送する。ＤＣを設定したＤＲＢにマッピングされる全ＰＤＵセッションのデータを転送する。

【0810】

ステップＳＴ６３２１においてＭｇＮＢは、ＮＧ－ＣＰＦに対して、ＰＤＵセッションスイッチ指示を通知する。ＭｇＮＢはＮＧ－ＣＰＦに対して、ＰＤＵセッションをＳｇＮＢにスイッチすることを要求する。ＤＣを設定したＤＲＢにマッピングされる全ＰＤＵセッション識別子、ＭｇＮＢ識別子、ＳｇＮＢ識別子、ＳｇＮＢのアドレスなどを通知するとよい。ここでは、ＰＤＵセッション識別子として、ＰＤＵセッション＃１およびＰＤＵセッション＃２の識別子を通知する。

【0811】

ステップＳＴ６３２２においてＮＧ－ＣＰＦは、ＮＧ－ＵＰＦに対して、ＰＤＵセッションスイッチ指示を通知する。ＮＧ－ＣＰＦはＮＧ－ＵＰＦに対して、ＰＤＵセッションをＳｇＮＢにスイッチすることを要求する。通知する情報は、ステップＳＴ６３２１で通知された情報と同じとしてもよい。

【0812】

ステップＳＴ６３２２においてＰＤＵセッションスイッチ指示を受信したＮＧ－ＵＰＦは、ステップＳＴ６３２３において、エンドマーカをつけたパケットをＭｇＮＢに対して通知する。ＭｇＮＢは該パケットをＳｇＮＢに転送する。これにより、ＳｇＮＢはＭｇＮＢから転送されるデータが最後であることを認識する。ＰＤＵセッション毎にエンドマーカをつけて送信してもよい。ＰＤＵセッション毎に並行してデータが送信されている場合に有効である。

【0813】

エンドマーカをつけたパケットをＭｇＮＢに対して送信したＮＧ－ＵＰＦは、ステップＳＴ６３２２において通知されたＰＤＵセッションのデータ送受信先を、ＭｇＮＢからＳｇＮＢに変更する。ここでは、ＤＣを設定したＤＲＢにマッピングされる全ＰＤＵセッションのデータ送受信先を、ＭｇＮＢからＳｇＮＢに変更する。

【0814】

ステップＳＴ６３２４において、ＮＧ－ＣＰＦはＭｇＮＢに対して、ＰＤＵセッションスイッチを行ったことを確認する通知を行う。ステップＳＴ６３２６，ＳＴ６３２５において、ＮＧ－ＵＰＦとＳｇＮＢとの間およびＳｇＮＢとＵＥとの間で、データ通信が行われる。ＳｇＮＢはＰＤＵセッションとＤＲＢとのマッピングを行う。ＳｇＮＢはＰＤＵセッション＃１とＰＤＵセッション＃２とを同じＤＲＢにマッピングする。ＱｏＳフローに適用した場合、ＳｇＮＢがＱｏＳフローからＤＲＢのマッピングを行う。

【0815】

スプリットベアラのＤＣを設定する場合のシーケンスは、一例として、図２３および図２４のシーケンスの一部を変更するとよい。ステップＳＴ６３１１において、ＭｇＮＢはＵＥに対して、ＤＣ（スプリットベアラ）を設定することを決定する。ステップＳＴ６３１２において、ＭｇＮＢはＳｇＮＢに対して、ＰＤＵセッションのＱｏＳに関する情報を含んだＳｇＮＢ追加要求メッセージを通知する。このＰＤＵセッションのＱｏＳに関する情報として、ＭｇＮＢは、ＮＧ－ＣＰＦからＰＤＵセッション要求時に通知されたＰＤＵセッションのＱｏＳに関する情報を用いてもよいことを示した。

【0816】

スプリットベアラの場合、ＮＧ－ＣＰＦからＰＤＵセッション要求時に通知されたＰＤＵセッションのＱｏＳに関する情報を変更してＳｇＮＢに通知してもよい。また、ステップＳＴ６３１５において、ＭｇＮＢはＵＥに対して、ＳｇＮＢのＤＲＢ設定に関する情報を通知する。ここで、ＭｇＮＢは、ＵＥとの間のベアラ設定を、ＤＣ前のＭｇＮＢとＵＥとの間のベアラの設定から変更して、通知してもよい。ＭｇＮＢはＵＥに対して、ＭｇＮＢとＵＥとの間のＤＲＢ設定と、ステップＳＴ６３１４においてＳｇＮＢから通知されたＳｇＮＢとＵＥとの間のＤＲＢ設定とを、通知するとよい。これによりＵＥはスプリットベアラを設定することが可能となる。

【0817】

スプリットベアラの場合、ＵＥに対するベアラが、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとに、スプリットされる。スプリットされた、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとをあわせて、ＰＤＵセッションのＱｏＳが満たされればよい。このため、前述のような処理とするとよい。

【0818】

ＤＣを設定するＤＲＢにマッピングされる全ＰＤＵセッションのＱｏＳに関する情報を変更してもよいし、一部のＰＤＵセッションのＱｏＳに関する情報を変更してもよい。また、ＰＤＵセッションのＱｏＳに関する情報のうち全部の情報を変更してもよいし、一部の情報を変更してもよい。ＭｇＮＢは自ノードの負荷などに応じて設定を柔軟に変更してＳｇＮＢに対してＳｇＮＢ追加要求を行うことが可能となる。

【0819】

また、スプリットベアラでは、ＭＣＧベアラからＳＣＧベアラにベアラをスイッチするための処理（ステップＳＴ６３１９～ＳＴ６３２４参照）は不要となる。これは、スプリットベアラではＭｇＮＢでベアラがスプリットされるので、ＮＧ－ＵＰＦとＭｇＮＢとの間のＰＤＵセッションは変更不要となるからである。

【0820】

スプリットベアラの設定後のデータ通信は、ステップＳＴ６３２５，ＳＴ６３２６ではなくなる。ステップＳＴ６３１０のＮＧ－ＵＰＦとＭｇＮＢとの間のデータ通信は維持され、ＭｇＮＢとＵＥとの間のデータ通信が、ＭｇＮＢとＵＥとの間のデータ通信と、ＭｇＮＢとＳｇＮＢとの間およびＳｇＮＢとＵＥとの間のデータ通信との２つにスプリットされる。

【0821】

このようにすることで、ＣＮ－ＲＡＮ間の制御がフローベース制御になり、ＲＡＮの制御がベアラベース制御になり、ＮＧ－ＣＮでＥ－ＲＡＢが無くなる一方、ｇＮＢとＵＥとの間でＤＲＢが設定されるような場合にも、ＵＥに対してＤＣを設定可能となる。また、ＳｇＮＢがＰＤＵセッションのＱｏＳに関する情報からＤＲＢを設定することによって、ＳｇＮＢの状況を考慮したＤＲＢ設定が可能となる。ＳｇＮＢのリソース使用効率を向上させることが可能となる。

【0822】

実施の形態７によれば、例えば、通信端末装置と、通信端末装置と無線通信可能に接続される複数の基地局装置と、通信端末装置と各基地局装置との通信を管理するコアネットワークとを含み、通信端末装置と接続されている第１の基地局装置が、第２の基地局装置に対して、通信端末装置用のベアラを設定するように要求する場合、第１の基地局装置は、コアネットワークからＰＤＵセッションについて取得したＱｏＳ（Quality of Service）に関する情報を、第２の基地局装置に通知し、第２の基地局装置は、通知されたＱｏＳに関する情報に基づいて、通信端末装置用のベアラを設定する、通信システムが提供される。

【0823】

この構成によれば、第５世代（５Ｇ）無線アクセスシステムについて、デュアルコネクティビティ（ＤＣ）を設定可能となる。

【0824】

ここで、上記構成は、前述のように、および、以下の変形例１～２で述べるように、様々に変形することが可能である。

【0825】

本実施の形態７で示した問題を解決するために、ＳｇＮＢがＰＤＵセッションのＱｏＳに関する情報を用いてＤＣ用ベアラ設定を行う方法について前述した。

【0826】

前述の方法では、一つのＤＲＢに複数のＰＤＵセッションが構成される場合、ＤＣはＤＲＢ毎の設定であるので、一つのＤＲＢについてＤＣを行うために、ＤＲＢに含まれる全ＰＤＵセッションの情報をＭｇＮＢとＳｇＮＢとの間で通知しなければならない。このため、通知しなければならない情報量が増大してしまう。

【0827】

ここでは、本実施の形態７で示した問題を解決する他の方法を開示する。

【0828】

ＭｇＮＢが、ＰＤＵセッションのＱｏＳに関する情報を用いて、ＤＣ用ベアラ設定を行う。ＭｇＮＢは、ＤＣ用ベアラ設定に関する情報を用いて、ＳｇＮＢに対してＳｇＮＢ追加要求を行う。ＳｇＮＢは、ＭｇＮＢから通知されたＤＣ用ベアラ設定に関する情報を用いて、ＤＣ用のＤＲＢを設定する。スプリットベアラを設定する場合、ＭｇＮＢは、ＤＣ用ベアラ設定に関する情報の値を変更して、ＳｇＮＢに通知してもよい。ＭｇＮＢ側のベアラとＳｇＮＢ側のベアラとによって、ＰＤＵセッションに要求されるＱｏＳを満たすように、ＤＣ用のＤＲＢを設定すればよい。

【0829】

ＭｇＮＢはＳｇＮＢに対して、ＤＣを行うＰＤＵセッションのセッション識別子を通知してもよい。ＭｇＮＢはＳｇＮＢに対して、ＤＣを行うＤＲＢに含まれるＰＤＵセッションの識別子を通知してもよい。ＰＤＵセッションのＱｏＳに関する情報と関連付けてＰＤＵセッション識別子を通知するとよい。ベアラ設定要求とともに、あるいは、ベアラ設定要求メッセージに含めて通知してもよい。

【0830】

このようにすることで、ＳｇＮＢは、ＮＧ－ＣＮにおけるどのＰＤＵセッションに対してＤＣを行うのかを認識することができる。ＳｇＮＢで、ＰＤＵセッションとＤＣを行うＤＲＢとのマッピングを可能にする。

【0831】

ＤＣ用ベアラ設定に関する情報例として以下のようなパラメータがあげられる。

【0832】

（１）ＲＬＣ構成、
（２）論理チャネル識別子、
（３）論理チャネル構成、
（４）論理チャネルビットレート、
（５）ＱＣＩ。

【0833】

ＤＣ用ベアラ設定に関する情報として、上りリンクにおいては、ｇＮＢがＵＥに対して通知するＤＲＢ設定情報を用いてもよい。従来のＬＴＥでｅＮＢがＵＥに対して通知するＤＲＢ設定情報を用いてもよい。例えば、従来のＬＴＥでは、非特許文献１２に開示されたパラメータがある。これらのＱｏＳに関する情報を用いてもよい。

【0834】

ＤＣを設定するベアラに複数のＰＤＵセッションが含まれる場合も、ＭｇＮＢはＳｇＮＢに対して、一つのＤＣ用ベアラのベアラ設定に関する情報のみを通知すればよい。ＭｇＮＢが設定した一つのＤＣ用ベアラのベアラ設定に関する情報を通知すればよい。このため、ＭｇＮＢからＳｇＮＢに対してＰＤＵセッション毎のＱｏＳに関する情報を通知しなくてもよく、通知に要する情報量を削減することが可能となる。

【0835】

ＳＣＧベアラを設定する場合、前述のように、ＭｇＮＢはＳｇＮＢに対して、ＤＣを設定するＤＲＢについて、ＭｇＮＢが設定したＤＲＢ設定に関する情報を通知すればよい。スプリットベアラの場合、スプリットされた、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとをあわせて、ＰＤＵセッションのＱｏＳが満たされればよい。このため、ＭｇＮＢは、ＭｇＮＢが設定したベアラ設定に関する情報を変更してＳｇＮＢに通知してもよい。また、ＭｇＮＢは、ＵＥとの間のベアラ設定を、ＤＣ前のＭｇＮＢとＵＥとの間のベアラの設定から変更して、通知してもよい。

【0836】

ＤＣ用ベアラのベアラ設定に関する情報の全てを変更してもよいし、一部のみを変更してもよい。ＭｇＮＢは自ノードの負荷などに応じて設定を柔軟に変更してＳｇＮＢに対してＳｇＮＢ追加要求を行うことが可能となる。

【0837】

ＭｇＮＢがＰＤＵセッションのＱｏＳに関する情報を用いてＤＣ用ベアラ設定を行う場合のＤＣ（ＳＣＧベアラ）設定シーケンスは、一例として、図２３および図２４シーケンスの一部を修正するとよい。

【0838】

図２３のステップＳＴ６３１２において、ＭｇＮＢがＳｇＮＢに対して通知するＳｇＮＢ追加要求メッセージに、ＰＤＵセッションのＱｏＳに関する情報ではなく、ＭｇＮＢがステップＳＴ６３０８で設定したＤＲＢ設定に関する情報を含める。

【0839】

また、ステップＳＴ６３１３において、ＳｇＮＢは、ＭｇＮＢから通知されたＤＲＢ設定に関する情報を考慮してＤＲＢを設定する。ＳｇＮＢは、ＤＲＢを設定する際に、自ノードの負荷などを考慮してもよい。ＳｇＮＢにおいて、ＭｇＮＢから通知されたＤＲＢ設定に関する情報に見合うＤＲＢを設定できない場合は、ＭｇＮＢに対してＳｇＮＢ追加要求に対する拒否メッセージを通知してもよい。拒否メッセージに、拒否理由を含めるとよい。例えば、過負荷などの理由がある。

【0840】

ＤＣ（スプリットベアラ）設定シーケンスの一例として、さらに、前述のＳｇＮＢがＤＲＢマッピングを行う方法で開示したＤＣ（スプリットベアラ）設定シーケンスへの変更を同様に行うとよい。

【0841】

このようにすることで、ＣＮ－ＲＡＮ間の制御がフローベース制御になり、ＲＡＮの制御がベアラベース制御になり、ＮＧ－ＣＮでＥ－ＲＡＢが無くなる一方、ｇＮＢとＵＥとの間でＤＲＢが設定されるような場合にも、ＵＥに対してＤＣを設定可能となる。

【0842】

また、ＭｇＮＢからＳｇＮＢに対してＰＤＵセッション毎のＱｏＳに関する情報を通知しなくてもよく、通知に要する情報量を削減することが可能となる。また、ＭｇＮＢがＰＤＵセッションのＱｏＳに関する情報からＤＲＢを設定することによって、ＭｇＮＢの状況を考慮したＤＲＢ設定要求が可能となる。ＭｇＮＢのリソース使用効率を向上させることが可能となる。

【0843】

以上に鑑みると、実施の形態７によれば、さらに次のような通信システムが提供される。例えば、通信端末装置と、通信端末装置と無線通信可能に接続される複数の基地局装置と、通信端末装置と各基地局装置との通信を管理するコアネットワークとを含み、通信端末装置と接続されている第１の基地局装置が、第２の基地局装置に対して、通信端末装置用のベアラを設定するように要求する場合、第１の基地局装置は、コアネットワークからＰＤＵセッションについて取得したＱｏＳ（Quality of Service）に基づいて、通信端末装置用のベアラを設定し、設定したベアラに関する情報を第２の基地局装置に通知する、通信システムが提供される。

【0844】

この構成によれば、第５世代（５Ｇ）無線アクセスシステムについて、デュアルコネクティビティ（ＤＣ）を設定可能となる。

【0845】

ここで、上記構成は、前述のように、および、以下の変形例１～２で述べるように、様々に変形することが可能である。

【0846】

実施の形態７の変形例１．
従来は、セッション毎にＥ－ＲＡＢが構成され、Ｅ－ＲＡＢ毎にＤＲＢが構成された。ＤＣはＥ－ＲＡＢ毎に設定可能であったので、一つのＵＥに対して複数のセッションが構成された場合も、ＰＤＵセッション毎にＤＣの設定が可能であった。

【0847】

しかし、複数のＰＤＵセッションに対して一つのＤＲＢを構成可能とした場合、セッション毎にＤＣを設定することが不可能となってしまう。

【0848】

セッションによっては、ＤＣにおいてどのベアラタイプを用いた方がよいかは異なる場合がある。例えば、低遅延が要求されるセッションにはＭＣＧベアラが適す。ＳｇＮＢへの転送が発生しないからである。また、例えば、高容量が要求されるセッションには、ＳＣＧベアラあるいはスプリットベアラが適す場合がある。ＳｇＮＢが高周波数で広帯域なキャリアを構成するような場合、ＳｇＮＢを用いることで高容量を得られるからである。

【0849】

しかし、セッション毎のＤＣ設定が不可能となった場合、このような効果を得られなくなってしまう問題が発生する。

【0850】

本変形例１では、このような問題を解決する方法を開示する。

【0851】

ＤＣをＰＤＵセッション毎に設定可能とする。ＭｇＮＢはＳｇＮＢに対して、ＰＤＵセッション毎にＤＣ設定を行う。ＤＣ（ＳＣＧベアラ）を設定する場合について、ＤＣ設定方法を開示する。ＭｇＮＢはＳｇＮＢに対して、ＮＧ－ＣＮ（ＣＰ）から通知された、ＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定要求を行う。この方法は実施の形態７で開示した方法を適用できる。

【0852】

ＭｇＮＢは、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションのＱｏＳに関する情報を用いて、ベアラを再設定する。ＳｇＮＢは、ＭｇＮＢから受信したＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定を行う。ＭｇＮＢはＵＥに対して、ＤＣを行うＰＤＵセッションに対してＳｇＮＢで設定されたベアラ設定と、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションに対してＭｇＮＢで再設定されたベアラ設定とを通知する。

【0853】

ＵＥは、通知されたベアラ設定に応じて、ＤＣを行うＰＤＵセッションに対するベアラ設定と、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションに対するベアラ設定とを行う。このようにＤＣを設定することで、ＰＤＵセッション毎のＤＣ設定が可能となる。

【0854】

ＭｇＮＢが、ＤＣを行うＰＤＵセッションを除いたＰＤＵセッションのＱｏＳに関する情報を用いて、ベアラを再設定することを開示したが、ベアラの再設定を行わなくてもよい。ＭｇＮＢは、ＤＣを行う前に、ＤＣを行うＰＤＵセッションを含めたＱｏＳを満たすようにベアラを設定しているので、ＤＣを行うＰＤＵセッションを除いたＰＤＵセッションのＱｏＳを満たすことも可能である。この場合、ＭｇＮＢからＵＥに対して、ＭｇＮＢで再設定されたベアラ情報を通知しなくてもよい。このようにすることで、ＭｇＮＢからＵＥへ通知する情報量を削減することが可能となる。

【0855】

図２５は、本変形例１におけるＰＤＵセッション毎のＤＣ（ＳＣＧベアラ）設定方法を説明する図である。図２５の左側の（ａ）は、ＭｇＮＢを用いたＭＣＧベアラ設定時の状態であり、ＤＣを設定する前の状態としてもよい。状態（ａ）は図２１の状態（ａ）と同じなので説明を省略する。図２５の右側の（ｂ）は、ＰＤＵセッション毎にＳｇＮＢを用いたＳＣＧベアラ設定時の状態であり、一つのＰＤＵセッションに対してＤＣ（ＳＣＧベアラ）を設定した状態としてもよい。

【0856】

状態（ｂ）に示すように、一つのＰＤＵセッション＃２に対してＤＣ（ＳＣＧベアラ）が設定されることによって、ＭＣＧベアラからＳＣＧベアラにスイッチされる。ＳｇＮＢでＤＣが設定されるＰＤＵセッション＃２のためのＤＲＢ＃Ｓ２が設定される。また、ＭｇＮＢではＤＣが設定されるＰＤＵセッション＃２を除いたＰＤＵセッション＃１のためのＤＲＢ＃Ｍ２が再設定される。ＰＤＵセッション＃１に対してはＭＣＧベアラが再設定されることになる。このＰＤＵセッション＃１はＳｇＮＢにスイッチされない。

【0857】

ＮＧ－ＵＰＦは、ＰＤＵセッション＃２のＤＣ（ＳＣＧベアラ）が設定されることで、ＤＲＢ＃Ｍ１にマッピングされていたＰＤＵセッション＃２を、ＭｇＮＢからＳｇＮＢにパススイッチする。このようにＮＧ－ＣＮ、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣを設定する。

【0858】

図２６は、本変形例１におけるＰＤＵセッション毎のＤＣ（ＳＣＧベアラ）設定方法を説明する図である。図２６の左側の状態（ｂ）は図２５の状態（ｂ）と同じなので説明を省略する。図２６の右側の（ｃ）は、ＰＤＵセッション毎にＳｇＮＢを用いたＳＣＧベアラ設定時の状態であり、二つのＰＤＵセッションに対してＤＣ（ＳＣＧベアラ）を設定した状態としてもよい。

【0859】

状態（ｃ）に示すように、ＭｇＮＢのＰＤＵセッション＃１に対してＤＣ（ＳＣＧベアラ）が設定されることによって、ＭＣＧベアラからＳＣＧベアラにスイッチされる。ＳｇＮＢでは、既にＤＣが設定されているＰＤＵセッション＃２と、ＭｇＮＢからスイッチされたＰＤＵセッション＃１のためのＤＲＢ＃Ｓ１とが再設定される。ＳｇＮＢでは複数のＰＤＵセッションに対して一つのＤＲＢが設定される。

【0860】

ＮＧ－ＵＰＦは、ＰＤＵセッション＃１のＤＣ（ＳＣＧベアラ）が設定されることで、ＤＲＢ＃Ｍ２にマッピングされていたＰＤＵセッション＃１を、ＭｇＮＢからＳｇＮＢにパススイッチする。このようにＮＧ－ＣＮ、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣを設定する。

【0861】

ＤＣ（スプリットベアラ）を設定する場合について、ＤＣ設定方法を開示する。

【0862】

ＭｇＮＢはＳｇＮＢに対して、ＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定要求を行う。スプリットベアラの場合、ＵＥに対するベアラが、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとに、スプリットされる。スプリットされた、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとをあわせて、ＰＤＵセッションのＱｏＳが満たされればよい。

【0863】

このため、ＮＧ－ＣＰＦからＰＤＵセッション要求時に通知されたＰＤＵセッションのＱｏＳに関する情報を変更してＳｇＮＢに通知してもよい。この方法は実施の形態７で開示した方法を適用できる。

【0864】

また、ＭｇＮＢは、ＳｇＮＢとＤＣ（スプリットベアラ）を行うＰＤＵセッションのＱｏＳに関する情報を考慮して、ベアラを再設定してもよい。ＭｇＮＢは、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションのＱｏＳに関する情報と、ＤＣによってＳｇＮＢとベアラスプリットを行うＰＤＵセッションのＱｏＳに関する情報とを考慮して、ベアラを再設定してもよい。

【0865】

ＳｇＮＢは、ＭｇＮＢから受信したＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定を行う。ＭｇＮＢはＵＥに対して、ＤＣを行うＰＤＵセッションに対してＳｇＮＢで設定されたベアラ設定と、ＭｇＮＢで再設定したベアラ設定とを通知する。ＵＥは、通知されたベアラ設定に応じて、ＭｇＮＢおよびＳｇＮＢに対するベアラ設定を行う。これにより、ＤＣを行うＰＤＵセッションに対するベアラ設定と、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションに対するベアラ設定とを行うことになる。

【0866】

ＭｇＮＢでＰＤＵセッション毎にＳＮをつけることで、ＤＣを行うＰＤＵセッションに対してのみ、データをＭｇＮＢとＳｇＮＢとでスプリットすることが可能となる。このようにＤＣを設定することで、ＰＤＵセッション毎のＤＣ設定が可能となる。

【0867】

ＭｇＮＢが、ＳｇＮＢとＤＣ（スプリットベアラ）を行うＰＤＵセッションのＱｏＳに関する情報を考慮して、ベアラを再設定してもよいことを開示したが、ベアラの再設定を行わなくてもよい。ＭｇＮＢは、ＤＣを行う前に、ＤＣ（スプリットベアラ）を行うＰＤＵセッションを含めたＱｏＳを満たすようにベアラを設定しているので、ＤＣ（スプリットベアラ）を行うＰＤＵセッションを除いたＰＤＵセッションのＱｏＳを満たすことも可能である。この場合、ＭｇＮＢからＵＥに対して、ＭｇＮＢで再設定されたベアラ情報を通知しなくてもよい。このようにすることで、ＭｇＮＢからＵＥへ通知する情報量を削減することが可能となる。

【0868】

図２７は、本変形例１におけるＤＣ（スプリットベアラ）設定方法を説明する図である。図２７の左側の（ａ）は、ＭｇＮＢを用いたＭＣＧベアラ設定時の状態であり、ＤＣを設定する前の状態としてもよい。状態（ａ）は図２２の状態（ａ）と同じなので説明を省略する。図２７の右側の（ｂ）は、ＰＤＵセッション毎にＳｇＮＢを用いたスプリットベアラ設定時であり、一つのＰＤＵセッションに対してＤＣ（スプリットベアラ）を設定した状態としてもよい。

【0869】

状態（ｂ）に示すように、一つのＰＤＵセッション＃２に対して、ＤＣ（スプリットベアラ）が設定されることによって、ＭＣＧベアラからスプリットベアラにスイッチされる。ＳｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃２のためのＤＲＢ＃Ｓ６が設定される。また、ＭｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃２と、ＰＤＵセッション＃１とのためのＤＲＢ＃Ｍ４が再設定される。このようにすることで、ＤＲＢの視点で見ると、ＤＲＢ＃Ｍ４とＤＲＢ＃Ｓ６とによってスプリットベアラが設定される。ＰＤＵセッションの視点で見ると、ＰＤＵセッション毎に、ＰＤＵセッション＃１に対してはＭＣＧベアラが再設定され、ＰＤＵセッション＃２に対してはスプリットベアラが設定されることになる。

【0870】

ＮＧ－ＵＰＦは、ＤＣ（スプリットベアラ）が設定された場合は、ＤＲＢ＃Ｍ１にマッピングされていた全ＰＤＵセッションを、ＭｇＮＢからＳｇＮＢにパススイッチする必要は無く、ＭｇＮＢのままでよい。このように、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣが設定される。

【0871】

ＤＣ（スプリットベアラ）を設定する場合について、他のＤＣ設定方法を開示する。

【0872】

前述のＤＣ設定方法では、スプリットベアラ設定後のＭｇＮＢで一つのベアラを設定した。ＤＣ（スプリットベアラ）を設定しないＰＤＵセッションと、ＤＣ（スプリットベアラ）を設定するＰＤＵセッションとに対して、一つのＤＲＢを設定した。

【0873】

他のＤＣ設定方法として、ＤＣ（スプリットベアラ）を設定しないＰＤＵセッションと、ＤＣ（スプリットベアラ）を設定するＰＤＵセッションとに対して、各々ベアラを設定する。このようにすることで、ＤＣ（スプリットベアラ）を設定するＰＤＵセッションについてベアラの変更を容易にすることが可能となる。例えば、ＭＣＧベアラからスプリットベアラへの変更処理、および、スプリットベアラから再度ＭＣＧベアラへの変更処理が、他のＰＤＵセッションおよびＤＣを設定しないＰＤＵセッションのためのベアラの設定とは独立して行われることになる。

【0874】

ＭｇＮＢはＳｇＮＢに対して、ＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定要求を行う。また、ＭｇＮＢにおいても、ＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定を行う。スプリットベアラの場合、ＵＥに対するベアラが、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとに、スプリットされる。スプリットされた、ＭｇＮＢとＵＥとの間のベアラと、ＳｇＮＢとＵＥとの間のベアラとをあわせて、ＰＤＵセッションのＱｏＳが満たされればよい。

【0875】

このため、ＮＧ－ＣＰＦからＰＤＵセッション要求時に通知されたＰＤＵセッションのＱｏＳに関する情報を変更してＳｇＮＢに通知してもよい。この方法は実施の形態７で開示した方法を適用できる。

【0876】

ＭｇＮＢは、ＳｇＮＢとＤＣ（スプリットベアラ）を行うＰＤＵセッションを除いた他のＰＤＵセッションのＱｏＳに関する情報を考慮して、ＤＣを行うＰＤＵセッションのためのベアラとは別に、ベアラを再設定する。複数のＰＤＵセッションに対してＤＣを行わない場合および複数のＰＤＵセッションに対してＤＣを行う場合の各々について、全ＰＤＵセッションに対して一つのベアラを設定してもよいし、ＰＤＵセッション毎にベアラを設定してもよいし、ＰＤＵセッショングループ毎にベアラを設定してもよい。

【0877】

ＳｇＮＢは、ＭｇＮＢから受信したＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定を行う。ＭｇＮＢはＵＥに対して、ＤＣを行うＰＤＵセッションに対してＳｇＮＢで設定されたベアラ設定と、ＭｇＮＢで再設定したＤＣを行わないＰＤＵセッションのためのベアラ設定と、ＤＣを行うＰＤＵセッションのベアラ設定とを通知する。

【0878】

ＵＥは、通知されたベアラ設定に応じて、ＭｇＮＢおよびＳｇＮＢに対するベアラ設定を行う。これにより、ＤＣを行うＰＤＵセッションに対するベアラ設定と、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションに対するベアラ設定とを行うことになる。ＭｇＮＢでＰＤＵセッション毎にＳＮをつけることで、ＤＣを行うＰＤＵセッションに対してのみ、データをＭｇＮＢとＳｇＮＢとでスプリットすることが可能となる。

【0879】

ＭｇＮＢで、ＤＣ（スプリットベアラ）を行わないＰＤＵセッションとＤＣ（スプリットベアラ）を行うＰＤＵセッションに対して各々ベアラを設定することを開示した。これに対し、ＤＣを行っているＰＤＵセッションに対してスプリットベアラから再度ＭＣＧベアラにする処理において、ＤＣ（スプリットベアラ）を行っていなかったＰＤＵセッションと、一つのベアラに設定してもよい。ＭｇＮＢにおいて、複数のＤＲＢ設定を行う必要がなくなるため、制御を容易にすることが可能となる。

【0880】

このようにＤＣを設定することで、ＰＤＵセッション毎のＤＣ設定が可能となる。

【0881】

図２８は、他のＤＣ（スプリットベアラ）設定方法を説明する図である。図２８の左側の（ａ）は、ＭｇＮＢを用いたＭＣＧベアラ設定時の状態であり、ＤＣを設定する前の状態としてもよい。状態（ａ）は図２２の状態（ａ）と同じなので説明を省略する。図２８の右側の（ｂ）は、ＰＤＵセッション毎にＳｇＮＢを用いたスプリットベアラ設定時の状態であり、一つのＰＤＵセッションに対してＤＣ（スプリットベアラ）を設定した状態としてもよい。

【0882】

状態（ｂ）に示すように、一つのＰＤＵセッション＃２に対して、ＤＣ（スプリットベアラ）が設定されることによって、ＭＣＧベアラからスプリットベアラにスイッチされる。ＳｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃２のためのＤＲＢ＃Ｓ７が設定される。また、ＭｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃２のためのＤＲＢ＃Ｍ６と、ＤＣが設定されないＰＤＵセッション＃１のためのＤＲＢ＃Ｍ５とが、再設定される。このようにすることで、ＤＲＢの視点で見ると、ＤＲＢ＃Ｍ６とＤＲＢ＃Ｓ７とによってスプリットベアラが設定される。ＰＤＵセッションの視点で見ると、ＰＤＵセッション毎に、ＰＤＵセッション＃１に対してはＤＲＢ＃Ｍ５によってＭＣＧベアラが再設定され、ＰＤＵセッション＃２に対してはＤＲＢ＃Ｍ６とＤＲＢ＃Ｓ７とによってスプリットベアラが設定されることになる。

【0883】

ＮＧ－ＵＰＦは、ＤＣ（スプリットベアラ）が設定された場合は、ＤＲＢ＃Ｍ１にマッピングされていた全ＰＤＵセッションを、ＭｇＮＢからＳｇＮＢにパススイッチする必要は無く、ＭｇＮＢのままでよい。このように、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣが設定される。

【0884】

図２９は、他のＤＣ（スプリットベアラ）設定方法を説明する図である。図２９の左側の状態（ｂ）は、図２８の状態（ｂ）と同じなので説明を省略する。図２９の右側の（ｃ）は、ＰＤＵセッション毎にスプリットベアラを設定する状態であり、２つのＰＤＵセッションに対してＤＣ（スプリットベアラ）を設定した状態としてもよい。

【0885】

状態（ｃ）に示すように、ＭｇＮＢのＰＤＵセッション＃１に対して、ＤＣ（スプリットベアラ）が設定されることによって、ＭＣＧベアラからスプリットベアラにスイッチされる。ＳｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃１のためにＤＲＢ＃Ｓ８が設定される。ＳｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃１と既にＤＣ（スプリットベアラ）が設定されているＰＤＵセッション＃２とのために、一つのＤＲＢ＃Ｓ８が再設定される。ＳｇＮＢでは、複数のＰＤＵセッションに対して一つのＤＲＢが設定される。ＭｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃１のためのＤＲＢ＃Ｍ７が再設定される。

【0886】

このようにすることで、ＤＲＢの視点で見ると、ＤＲＢ＃Ｍ７とＤＲＢ＃Ｓ８とでスプリットベアラが設定され、同様にＤＲＢ＃Ｍ６とＤＲＢ＃Ｓ８とによってスプリットベアラが設定される。ＰＤＵセッションの視点で見ると、ＰＤＵセッション毎に、ＰＤＵセッション＃１に対してはＤＲＢ＃Ｍ７とＤＲＢ＃Ｓ８とによってスプリットベアラが再設定され、ＰＤＵセッション＃２に対してはＤＲＢ＃Ｍ６とＤＲＢ＃Ｓ８とによってスプリットベアラが設定されることになる。

【0887】

ＮＧ－ＵＰＦは、ＤＣ（スプリットベアラ）が設定された場合は、ＤＲＢ＃Ｍ５にマッピングされていた全ＰＤＵセッションを、ＭｇＮＢからＳｇＮＢにパススイッチする必要は無く、ＭｇＮＢのままでよい。このように、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣが設定される。

【0888】

本変形例１で開示した方法とすることで、複数のＰＤＵセッションに対して一つのＤＲＢを構成可能とした場合にも、セッション毎にＤＣを設定することが可能となる。このため、セッション毎に適したベアラタイプのＤＣを設定することが可能となり、セッション毎に要求される性能を効率良く満たすことが可能となる。

【0889】

ＰＤＵセッション毎にＤＣを設定する方法を開示したが、複数のＰＤＵセッションに対してＤＣを設定してもよい。ＭｇＮＢからＳｇＮＢに対して、ＤＣを行う複数のＰＤＵセッション毎のＱｏＳに関する情報を用いて、ベアラ設定要求を行うとよい。一つのベアラ設定要求メッセージにＤＣを行う複数のＰＤＵセッション毎のＱｏＳに関する情報を含めて通知してもよい。設定方法は本変形例で開示した方法を適宜適用するとよい。

【0890】

一つまたは複数のＰＤＵセッションを一つのグループとして、ＰＤＵセッショングループ毎にＤＣを設定してもよい。ＭｇＮＢからＳｇＮＢに対して、ＤＣを行うＰＤＵセッショングループに含まれる一つまたは複数のＰＤＵセッションのＱｏＳに関する情報を用いて、ベアラ設定要求を行うとよい。一つのベアラ設定要求メッセージにＤＣを行うＰＤＵセッショングループのＱｏＳに関する情報を含めて通知してもよい。設定方法は本変形例で開示した方法を適宜適用するとよい。

【0891】

前述に開示した方法では、ＳｇＮＢがＰＤＵセッションのＱｏＳに関する情報を用いてＤＣ用ベアラ設定を行う。他の方法として、ＭｇＮＢがＰＤＵセッションのＱｏＳに関する情報を用いてＤＣ用ベアラ設定を行い、ＭｇＮＢはＤＣ用ベアラ設定に関する情報を用いて、ＳｇＮＢに対してＳｇＮＢ追加要求を行うようにしてもよい。実施の形態７で開示した方法を適宜適用するとよい。

【0892】

このようにすることで、実施の形態７と同様に、通知に要する情報量を削減することが可能となる。また、ＭｇＮＢの状況を考慮したＤＲＢ設定要求が可能となる。ＭｇＮＢのリソース使用効率を向上させることが可能となる。

【0893】

実施の形態７の変形例２．
ＰＤＵセッション毎にＤＣを設定する場合でも、ＳｇＮＢで複数のＰＤＵセッションのために一つのベアラが設定されてしまう。例えば、図２６および図２９に示すような場合である。このような場合、例えば、ＳＣＧベアラからＭＣＧベアラに戻す場合、言い換えるとベアラタイプの変更を行う場合に、ＳｇＮＢでベアラの再設定が必要となる。このため、ベアラの設定処理が複雑となってしまう。高い頻度でＤＣのベアラタイプの変更が生じる場合、ＤＣ設定処理が複雑となってしまう。

【0894】

本変形例２では、このような問題を解決する方法を開示する。

【0895】

ＳｇＮＢは、ＤＣを行うベアラ設定、または、ＤＣを行うＰＤＵセッションのためのベアラ設定を、ＰＤＵセッション毎に行う。ＰＤＵセッション識別子とＤＲＢ識別子とを１対１対応になるよう設定してもよい。ＤＣを設定する場合について、ＤＣ設定方法を開示する。

【0896】

ＭｇＮＢはＳｇＮＢに対して、ＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いてベアラ設定要求を行う。この方法は実施の形態７で開示した方法を適用できる。ＭｇＮＢは、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションのＱｏＳに関する情報を用いて、ベアラを再設定する。

【0897】

ＳｇＮＢは、ＭｇＮＢから受信したＤＣを行うＰＤＵセッションのみのＱｏＳに関する情報を用いて、ベアラ設定を行う。ＵＥに対して既に他のＰＤＵセッションのためのベアラが設定されていた場合は、ＤＣを行うＰＤＵセッションのために該ベアラとは異なるベアラを設定する。ＭｇＮＢはＵＥに対して、ＳｇＮＢで設定されたベアラ設定と、ＭｇＮＢで再設定されたベアラ設定とを通知する。

【0898】

ＵＥは、通知されたベアラ設定に応じて、ＤＣを行うＰＤＵセッションに対するベアラ設定と、ＤＣを行うＰＤＵセッションを除いた他のＰＤＵセッションに対するベアラ設定とを行う。このようにＤＣを設定することで、ＰＤＵセッション毎にベアラが設定されるＤＣ設定が可能となる。

【0899】

ＭｇＮＢが、ＤＣを行うＰＤＵセッションを除いたＰＤＵセッションのＱｏＳに関する情報を用いて、ベアラを再設定することを開示したが、ベアラの再設定を行わなくてもよい。ＭｇＮＢは、ＤＣを行う前に、ＤＣを行うＰＤＵセッションを含めたＱｏＳを満たすようにベアラを設定しているので、ＤＣを行うＰＤＵセッションを除いたＰＤＵセッションのＱｏＳを満たすことも可能である。この場合、ＭｇＮＢからＵＥに対して、ＭｇＮＢで再設定されたベアラ情報を通知しなくてもよい。このようにすることで、ＭｇＮＢからＵＥへ通知する情報量を削減することが可能となる。

【0900】

図３０は、本変形例２におけるＰＤＵセッション毎のＤＣ（ＳＣＧベアラ）設定方法を説明する図である。図３０の左側の状態（ｂ）は図２６の状態（ｂ）と同じなので説明を省略する。図３０の右側の（ｃ）は、ＰＤＵセッション毎に異なるＳｇＮＢを用いたＳＣＧベアラ設定時の状態であり、２つのＰＤＵセッションに対してＤＣ（ＳＣＧベアラ）を設定した状態としてもよい。

【0901】

状態（ｃ）に示すように、ＭｇＮＢのＰＤＵセッション＃１に対して、ＤＣ（ＳＣＧベアラ）が設定されることによって、ＭＣＧベアラからＳＣＧベアラにスイッチされる。ＳｇＮＢでは、既にＤＣが設定されているＰＤＵセッション＃２のためのＤＲＢ＃Ｓ４とは別に、ＭｇＮＢからスイッチされたＰＤＵセッション＃１のためのＤＲＢ＃Ｓ３が設定される。ＳｇＮＢでは複数のＰＤＵセッションに対して個別にＤＲＢが設定される。

【0902】

ＮＧ－ＵＰＦは、ＰＤＵセッション＃１のＤＣ（ＳＣＧベアラ）が設定されることによって、ＤＲＢ＃Ｍ２にマッピングされていたＰＤＵセッション＃１を、ＭｇＮＢからＳｇＮＢにパススイッチする。このようにＮＧ－ＣＮ、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣを設定する。

【0903】

図３１は、本変形例２におけるＰＤＵセッション毎のＤＣ（スプリットベアラ）設定方法を説明する図である。図３１の左側の状態（ｂ）は図２９の状態（ｂ）と同じなので説明を省略する。図３１の右側の（ｃ）は、ＰＤＵセッション毎にスプリットベアラを設定した状態であり、２つのＰＤＵセッションに対してＤＣ（スプリットベアラ）を設定した状態としてもよい。

【0904】

状態（ｃ）に示すように、ＭｇＮＢのＰＤＵセッション＃１に対して、ＤＣ（スプリットベアラ）が設定されることによって、ＭＣＧベアラからスプリットベアラにスイッチされる。ＳｇＮＢでは、既にＤＣ（スプリットベアラ）が設定されているＰＤＵセッション＃２のためのＤＲＢ＃Ｓ９とは別に、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃１のためにＤＲＢ＃Ｓ１０が設定される。ＳｇＮＢでは複数のＰＤＵセッションに対して個別にＤＲＢが設定される。ＭｇＮＢでは、ＤＣ（スプリットベアラ）が設定されるＰＤＵセッション＃１のためのＤＲＢ＃Ｍ７が再設定される。

【0905】

このようにすることで、ＤＲＢの視点で見ると、ＤＲＢ＃Ｍ７とＤＲＢ＃Ｓ１０とによってスプリットベアラが設定され、同様にＤＲＢ＃Ｍ６とＤＲＢ＃Ｓ９とによってスプリットベアラが設定される。ＰＤＵセッションの視点で見ると、ＰＤＵセッション毎に、ＰＤＵセッション＃１に対してはＤＲＢ＃Ｍ７とＤＲＢ＃Ｓ１０とによってスプリットベアラが再設定され、ＰＤＵセッション＃２に対してはＤＲＢ＃Ｍ６とＤＲＢ＃Ｓ９とによってスプリットベアラが設定されることになる。

【0906】

ＮＧ－ＵＰＦは、ＤＣ（スプリットベアラ）が設定された場合は、ＤＲＢ＃Ｍ５にマッピングされていた全ＰＤＵセッションを、ＭｇＮＢからＳｇＮＢにパススイッチする必要は無く、ＭｇＮＢのままでよい。このように、ｇＮＢ、ＵＥ間でＰＤＵセッション毎のＤＣが設定される。

【0907】

このようにすることで、ＰＤＵセッション毎にＤＣを設定する場合でも、ＳｇＮＢで複数のＰＤＵセッションのために個別のベアラを設定することが可能となる。このため、例えばベアラタイプの変更を行う場合に、ＳｇＮＢでベアラの再設定が不要となる。高い頻度でＤＣのベアラタイプの変更が生じる場合でも、ベアラの設定処理を容易にし、ＤＣ設定処理を容易にすることが可能となる。

【0908】

ＤＣを行うベアラ設定、または、ＤＣを行うＰＤＵセッションのためのベアラ設定を、ＰＤＵセッション毎に行う方法を開示したが、この方法は静的に規格などで予め決めておいてもよい。この方法を行うために、なんらシグナリングを必要とせず、ＵＥ、ＭｇＮＢ、ＳｇＮＢ、ＮＧ－ＣＮ間で共通認識を得ることが可能となる。

【0909】

あるいは、この方法を行うか否かを設定可能としてもよい。ＤＣを行うベアラ設定、または、ＤＣを行うＰＤＵセッションのためのベアラ設定を、ＰＤＵセッション毎に行うか否かを設定可能とする。ＳｇＮＢが、ＤＣを行うベアラ設定、または、ＤＣを行うＰＤＵセッションのためのベアラ設定を、ＰＤＵセッション毎に行うか否かを設定してもよい。ＳｇＮＢの負荷状況等を考慮して設定可能となる。例えば、ＳｇＮＢにおける最大設定可能ＤＲＢ数に応じて、ＳｇＮＢでのＤＣ用のベアラ設定をＰＤＵセッション毎に行うか否かを、設定してもよい。ＳｇＮＢの最大設定可能ＤＲＢ数をオーバするような場合、ＰＤＵセッション毎に行わないように設定するとよい。

【0910】

また、ＳｇＮＢが、ＭｇＮＢからの要求を考慮してＰＤＵセッション毎に行うか否かを設定してもよい。

【0911】

このようにすることで、ＳｇＮＢでのＤＣ用のベアラ設定をＰＤＵセッション毎に行うか否かを柔軟に設定可能となる。

【0912】

ＳｇＮＢが、ＭｇＮＢからの要求を考慮して設定する方法について開示する。

【0913】

ＤＣ用にＳｇＮＢで設定されるベアラを、ＰＤＵセッション毎にするか否かを示す情報（ベアラ個別設定情報と称する）を設ける。例えば、ベアラ個別設定情報用に１ビットを割り当て、該ビットの状態が“１”の場合はＰＤＵセッション毎に設定し、該ビットの状態が“０”の場合はＰＤＵセッション毎に設定しないとしてもよい。

【0914】

ＭｇＮＢは、ＳｇＮＢに対してベアラ個別設定該情報を通知する。ベアラ個別設定該情報は、ＭｇＮＢがＳｇＮＢに対してＤＣ設定時に通知するＳｇＮＢ追加要求メッセージに含めて通知するとよい。ＳｇＮＢは、ＭｇＮＢから受信したベアラ個別設定情報に応じて、ＤＣ用のベアラ設定を、ＰＤＵセッション毎に設定するか否かを判断する。ベアラ個別設定情報がＰＤＵセッション毎に設定することを示す場合、ＳｇＮＢはＰＤＵセッション毎にベアラを設定する。ベアラ個別設定情報がＰＤＵセッション毎に設定することを示さない場合、ＳｇＮＢは複数のＰＤＵセッションのために一つのＤＲＢに設定する。

【0915】

このようにすることで、ＭｇＮＢが、ＳｇＮＢでのＤＣ用のベアラ設定をＰＤＵセッション毎に行うか否かを設定可能とすることができる。これによれば、ＳｇＮＢでのベアラ設定をより柔軟に行うことが可能になる。このため、サービスによるベアラタイプ変更の頻度に適したベアラ設定が可能となる。ＤＣ設定制御を容易にし、ＳｇＮＢのリソースを効率的に使用できる。

【0916】

他の方法として、ＭｇＮＢでのベアラとＰＤＵセッションとの対応情報（ベアラ－セッション対応情報）を、ＤＣを行うベアラに対して、または、ＤＣを行うＰＤＵセッションに対して設けるとよい。ベアラ－セッション対応情報は、ＭｇＮＢがＳｇＮＢに対してＤＣ設定時に通知する、ＳｇＮＢ追加要求メッセージに含めて通知するとよい。ＳｇＮＢは、ＭｇＮＢから受信したベアラ－セッション対応情報を考慮して、ＤＣ用のベアラ設定を行うとよい。

【0917】

このようにすることで、ＳｇＮＢが、ＳｇＮＢでのＤＣ用のベアラ設定をＰＤＵセッション毎に行うか否かを、ＭｇＮＢでの設定を考慮して、設定可能とすることができる。これによれば、ＳｇＮＢでのベアラ設定をより柔軟に行うことが可能になる。このため、サービスによるベアラタイプ変更の頻度に適したベアラ設定が可能となる。ＤＣ設定制御を容易にし、ＳｇＮＢのリソースを効率的に使用できる。

【0918】

ＭｇＮＢが、ＳｇＮＢに対してＤＣ用のベアラ設定をＰＤＵセッション毎に行うことを要求するか否かを判断するための指標として、例えば、ＤＣ設定、修正あるいは解除を頻繁に行うか、などがある。ベアラの変更など、ＤＣの変更が頻繁にある場合、ＤＣを行うＰＤＵセッション毎にベアラを設定した方が、他のＰＤＵセッションと一緒にベアラを設定するよりも、制御を容易にできる。ＤＣの設定や解除が頻繁に行われる場合も同様である。したがって、ＤＣ設定、修正あるいは解除を頻繁に行うような場合、ＭｇＮＢは、ＳｇＮＢに対してＤＣ用のベアラ設定をＰＤＵセッション毎に行うことを要求すると判断するとよい。

【0919】

ＤＣ設定、修正あるいは解除を頻繁に行うか否かを判断する指標として、以下に３つの例を開示する。

【0920】

（１）ＤＣを設定するＵＥの移動速度、
（２）ＤＣに用いるｇＮＢやｇＮＢのセルのカバレッジ範囲の大きさ、
（３）ＤＣに用いるｇＮＢがビーム運用か否か。

【0921】

前述の（１）で、ＤＣを設定するＵＥの移動速度が速い場合、セル間やｇＮＢ間の移動が頻繁に生じることになる。セル間やｇＮＢ間の移動により、ＤＣの設定および解除が頻繁に行われることになる。したがって、ＤＣを設定するＵＥの移動速度が速い場合、ＭｇＮＢが、ＳｇＮＢに対してＤＣ用のベアラ設定をＰＤＵセッション毎に行うことを要求するよう判断してもよい。

【0922】

前述の（２）で、ＤＣに用いるｇＮＢやｇＮＢのセルのカバレッジ範囲の大きさが小さい場合、セル間やｇＮＢ間の移動が頻繁に生じることになる。セル間やｇＮＢ間の移動により、ＤＣの設定および解除が頻繁に行われることになる。したがって、ＤＣに用いるｇＮＢやｇＮＢのセルのカバレッジ範囲の大きさが小さい場合、ＭｇＮＢが、ＳｇＮＢに対してＤＣ用のベアラ設定をＰＤＵセッション毎に行うことを要求するよう判断してもよい。

【0923】

前述の（３）で、ＤＣに用いるｇＮＢがビーム運用の場合、ビーム間の移動が頻繁に生じることになる。ビーム間の移動により、ＤＣの設定修正が頻繁に行われることになる。したがって、ＤＣに用いるｇＮＢがビーム運用の場合、ＭｇＮＢが、ＳｇＮＢに対してＤＣ用のベアラ設定をＰＤＵセッション毎に行うことを要求するよう判断してもよい。

【0924】

ＳｇＮＢがＭｇＮＢからの要求を考慮して、ＳｇＮＢでのＤＣ用のベアラ設定をＰＤＵセッション毎に行うか否かを設定する方法を開示した。ＭｇＮＢからＤＣ用のベアラ設定をＰＤＵセッション毎に行うことを要求された場合、ＳｇＮＢは、その要求に対してリジェクトしてもよい。例えば、自ｇＮＢにおける最大設定可能ＤＲＢ数をオーバするような場合、リジェクトするとよい。ＳｇＮＢはＭｇＮＢに対してリジェクトを通知する。リジェクトメッセージに、理由情報を含めてもよい。理由情報は、最大設定可能ＤＲＢ数のオーバ、などである。

【0925】

リジェクトメッセージを受信したＭｇＮＢは、例えば、ベアラ個別設定情報をＰＤＵセッション毎に設定することを示さないようにして、再度ＳｇＮＢに対してＤＣ用ベアラ設定を要求してもよい。あるいは、リジェクトメッセージを通知したＳｇＮＢをＤＣに用いるのをやめてもよい。

【0926】

このようにすることで、ＳｇＮＢの負荷状況等を反映させたＤＣを設定することが可能となる。システム全体としてスループットを向上させることが可能となる。

【0927】

本変形例２で開示した方法は、ｇＮＢとの間で行う処理において適宜適用してもよい。ＤＣ用に限定しなくてもよい。例えば、ハンドオーバ（ＨＯ）処理の際に適用するとよい。ベアラ設定をＰＤＵセッション毎にするか否かを示す情報（ベアラ個別設定情報と称する）を設け、Ｓ－ｇＮＢ（ＨＯ元ｇＮＢ：Ｓｏｕｒｃｅ－ｇＮＢ）はＴ－ｇＮＢ（ＨＯ先ｇＮＢ：Ｔａｒｇｅｔ－ｇＮＢ）に対してベアラ個別設定該情報を通知する。ベアラ個別設定情報は、例えばＳ－ｇＮＢからＴ－ｇＮＢに通知するＨＯ要求メッセージに含めて通知するとよい。Ｔ－ｇＮＢはＳ－ｇＮＢから受信したベアラ個別設定情報に応じて、ベアラ設定をＰＤＵセッション毎に設定するか否かを判断する。

【0928】

あるいは、Ｓ－ｇＮＢでのベアラとＰＤＵセッションとの対応情報（ベアラ－セッション対応情報）を、Ｓ－ｇＮＢがＴ－ｇＮＢに対して通知する、ＨＯ要求メッセージに含めて通知するとよい。ＳｇＮＢは、ＭｇＮＢから受信したベアラ－セッション対応情報を考慮して、ベアラ設定を行うとよい。このようにすることで、ＨＯ処理などによって、ＵＥが通信を行うｇＮＢが変更になる場合も、サービス毎に適したベアラ設定が可能となる。

【0929】

本変形例２で開示した方法は、ＮＧ－ＣＮとｇＮＢとの間で行う処理において適宜適用してもよい。ＤＣ用に限定しなくてもよい。例えば、セッション設立処理の際に適用するとよい。ベアラ設定をＰＤＵセッション毎にするか否かを示す情報（ベアラ個別設定情報と称する）を設け、ＮＧ－ＣＮはｇＮＢに対してベアラ個別設定該情報を通知する。

【0930】

ベアラ個別設定情報は、例えばＮＧ－ＣＰＦからｇＮＢに通知するセッション設立応答メッセージに含めて通知するとよい。ｇＮＢはＮＧ－ＣＮから受信したベアラ個別設定情報に応じて、ベアラ設定をＰＤＵセッション毎に設定するか否かを判断する。このようにすることで、ＮＧ－ＣＮがｇＮＢとセッションを設立するような場合にも、サービス毎に適したベアラ設定が可能となる。

【0931】

ＬＴＥと５Ｇとのインタワークが検討されている。ＬＴＥのｅＮＢと５ＧのｇＮＢとがＤＣによって接続されることが検討されている（３ＧＰＰ ＲＰ－１６１２６６（以下「参考文献３」という）参照）。ＣＮがＮＧ－ＣＮの場合に、ＮＧ－ＣＮに接続されるＬＴＥのｅＮＢに、フローベースからベアラベースに変換する機能を追加するとよい。ｅＮＢに対して実施の形態７から実施の形態７の変形例２までで開示した方法を適用可能となる。ＣＮがＥＰＣの場合はベアラベースとなるため適用は不要である。

【0932】

実施の形態７から実施の形態７の変形例２まででは、ＳｇＮＢ追加要求メッセージについて開示したが、ＳｇＮＢ修正要求メッセージを利用してもよい。ＳｇＮＢでのＤＣ用ベアラ設定変更時に適用することで、同様の効果を得ることができる。

【0933】

実施の形態８．
実施の形態１では、セル内全ビームにおいて同じＲＲＣパラメータを用いることを開示した。他の方法として、複数のＴＲＰ／ビーム内で同じＲＲＣパラメータとしてもよい。一つまたは複数のＴＲＰで構成する一つまたは複数のビームでビームグループを構成し、ビームグループ内の全ビームにおいて同じＲＲＣパラメータを用いるとしてもよい。同じＲＲＣパラメータを設定する一つまたは複数のビームの集合を、ビームグループとしてもよい。

【0934】

ビームグループの設定方法について開示する。ビームグループは静的に設定される。予めシステムとして決めておくとよい。例えば、一つのＴＲＰが構成するビームでビームグループを構成する。例えば、隣接するカバレッジを有する複数のビームでビームグループを構成する。カバレッジが隣接しているセル内のビーム１、ビーム２およびビーム３をビームグループ１とし、同じく、カバレッジが隣接しているセル内のビーム４、ビーム５、ビーム６およびビーム７をビームグループ２とする、等である。静的に設定したビームグループ内のビーム間で同じＲＲＣパラメータを用いる。

【0935】

ビームグループのＲＲＣパラメータの設定方法について開示する。

【0936】

ビームグループ内のビームで同じＲＲＣパラメータが設定されることを予め規格等で決めておくとよい。セルはＵＥに対して、通信を行うビーム（サービングビームと称する場合がある）を介して、同じＲＲＣパラメータが設定される複数のビームのＴＲＰ／ビームの識別子を通知する。ビームグループとして識別子を設定してもよく、その場合、ビームグループの識別子およびビームグループ内のビームの識別子を通知してもよい。

【0937】

このようにすることで、ＵＥはどのビームがサービングビームと同じＲＲＣが設定されているかを認識することが可能となる。ビームグループ内で同じＲＲＣパラメータが設定されるため、ビーム毎のＲＲＣパラメータ設定が不要となる。セルはＵＥに対して、同じＲＲＣパラメータが設定されるビームを特定するための情報のみを通知すればよい。通知に必要となる情報量を削減することが可能となる。

【0938】

ビームグループのＲＲＣパラメータの他の設定方法を開示する。セルはＵＥに対して、サービングビームを介して、複数のビームのＴＲＰ／ビームの識別子とビーム毎に設定するＲＲＣパラメータを通知する。同じＲＲＣパラメータを設定する場合は同じＲＲＣパラメータを通知する。このようにすることで、ＵＥはどのビームが同じＲＲＣが設定されているかを認識することが可能となる。通知に必要な情報量は多くなるが、ビーム毎にＲＲＣパラメータの設定が可能となるため、ビーム毎のＲＲＣパラメータの変更を容易にすることができる。

【0939】

ビームグループのＲＲＣパラメータの他の設定方法を開示する。セルはＵＥに対して、サービングビームを介して、複数のビームのＴＲＰ／ビームの識別子とビーム毎に設定するＲＲＣパラメータがサービングビームと同じか否かを通知する。同じＲＲＣパラメータを設定する場合は同じことを示す情報を通知する。このようにすることで、ＵＥはどのビームがサービングビームと同じＲＲＣが設定されているかを認識することが可能となる。このようにすることで、ビーム毎にＲＲＣパラメータを通知する必要が無いため、通知に必要な情報量を削減することが可能となる。

【0940】

ＲＲＣパラメータの全部を同じとしてもよいし一部を同じとしてもよい。同じにするＲＲＣパラメータは実施の形態１で開示したＲＲＣパラメータとするとよい。

【0941】

ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ内でビーム間モビリティが発生した場合、ターゲットＲＲＣパラメータの設定は不要となる。ビーム間移動にともなうＲＲＣパラメータの設定を不要とする。このようにすることで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0942】

ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ外へのビーム間モビリティが発生した場合、ターゲットＲＲＣパラメータの設定が必要となる。この場合、実施の形態２から実施の形態５の変形例３で開示した方法を適宜適用するとよい。このようにすることで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0943】

同じＲＲＣパラメータを設定するビームグループの他の設定方法について開示する。ビームグループは準静的あるいは動的に設定される。ビームグループをＵＥ毎に準静的あるいは動的に設定可能とする。セルはＵＥに対してＵＥ毎にビームグループを設定する。セルはＵＥに対して設定したビームグループを、サービングビームを介して通知する。

【0944】

ビームグループの通知方法として、ＲＲＣシグナリングを用いてもよい。あるいは、ＭＡＣシグナリングを用いてもよい。あるいは、Ｌ１／Ｌ２制御シグナリングを用いてもよい。あるいは、これらを組合せてもよい。ビームグループのＲＲＣパラメータの設定方法は前述の方法を適用するとよい。

【0945】

セルはＵＥに対して設定するビームグループを変更してもよい。電波伝搬状況に応じてビームグループを変更するとよい。

【0946】

ＵＥ毎に設定するビームグループの例を示す。同じＲＲＣパラメータを設定するビームグループとして、サービングビームとＵＥがモニタするビームを設定しても良い。あるいは、予め、サービングビームとＵＥがモニタするビームとで同じＲＲＣパラメータを設定するビームグループを構成することを規格等で決めておいてもよい。

【0947】

セルはＵＥに対して、ＵＥのサービングビームとＵＥがモニタするビームとで同じＲＲＣパラメータを設定する。セルはＵＥに対してＵＥがモニタするビームを通知する。これにより、ＵＥは、同じＲＲＣパラメータを設定するビームを認識することができる。

【0948】

ＵＥとサービングビームとの間の通信品質が急激に悪化した場合、セルはＵＥを、ＵＥがモニタしているビームへ移動させてもよい。ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ内でのビーム間モビリティとなるため、ターゲットＲＲＣパラメータの設定は不要となる。ビーム間移動にともなうＲＲＣパラメータの設定を不要とする。ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0949】

ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ外へのビーム間モビリティが発生した場合、ターゲットＲＲＣパラメータの設定が必要となる。この場合、実施の形態２から実施の形態５の変形例３で開示した方法を適宜適用するとよい。このようにすることで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0950】

ＵＥ毎に設定するビームグループの他の例を示す。ＵＥは複数のビームと通信を行ってもよい。このような場合、同じＲＲＣパラメータを設定するビームグループとして、ＵＥが通信を行う複数のビーム（複数のサービングビーム）を設定しても良い。あるいは、予め、複数のサービングビームで同じＲＲＣパラメータを設定するビームグループを構成することを規格等で決めておいてもよい。

【0951】

ＵＥはセルと一つのサービングビームで通信を行う。セルはＵＥに対して、該サービングビームを介して、通信を行う一つまたは複数の他のビームを通知する。これにより、ＵＥは、同じＲＲＣパラメータを設定するビームを認識することができる。

【0952】

ＵＥと一つのサービングビームとの間の通信品質が急激に悪化した場合、セルは他のサービングビームを用いてＵＥと通信を行う。セルはＵＥを他のサービングビームへ移動させてもよい。ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ内でのビーム間モビリティとなるため、ターゲットＲＲＣパラメータの設定は不要となる。ビーム間移動にともなうＲＲＣパラメータの設定を不要とする。ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0953】

すでにＵＥは他のビームで通信を行っている状態であるため、セルはＵＥに対して移動指示を通知しなくてもよい。セルはＵＥに対して、通信品質が急激に悪化したビームを用いた通信を行わず、他のビームで通信を行うようにすればよい。ＵＥは、通信品質が急激に悪化したビームではなく、他の通信を行っているビームで通信を行うことができる。

【0954】

このような場合、ビーム間移動と称さない場合もある。しかし、このような場合、ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ内で通信するビームの変更となるため、ターゲットＲＲＣパラメータの設定は不要となる。通信するビームの変更にともなうＲＲＣパラメータの設定を不要とする。ＲＲＣシグナリングを伴わない通信するビームの変更を可能とする。

【0955】

ＵＥに対して、同じＲＲＣパラメータが設定されているビームグループ外へのビーム間モビリティが発生した場合、ターゲットＲＲＣパラメータの設定が必要となる。この場合、実施の形態２から実施の形態５の変形例３で開示した方法を適宜適用するとよい。このようにすることで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0956】

実施の形態８の変形例１．
ビームグループが設定されるような場合に、同じＲＲＣパラメータを設定せずに、ビーム毎に異なるＲＲＣパラメータを設定してもよい。異なるＲＲＣパラメータを設定する場合は、ビーム間移動時のビーム毎のＲＲＣパラメータ設定方法は、実施の形態２から実施の形態５の変形例３で開示した方法を適宜適用するとよい。このようにすることで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0957】

例えば、ビームグループとして、サービングビームとＵＥがモニタするビームを設定した場合、ビームグループ内でのビーム間移動とビームグループ外へのビーム間移動とがあるが、いずれもサービングビームの移動になる。この場合、移動元ビームから移動先ビームへのモビリティとなる。したがって、実施の形態２から実施の形態５の変形例３で開示した方法を適用することで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0958】

例えば、ビームグループとして、ＵＥが通信を行う複数のビーム（複数のサービングビーム）を設定した場合、セルはＵＥに対して、予めビーム毎のＲＲＣパラメータを設定する。ＵＥはセルと一つのサービングビームで通信を行う。セルはＵＥに対して、該サービングビームを介して、通信を行う一つまたは複数の他のビームを通知する。他のビームの通知とともに、各ビームのＲＲＣパラメータを通知するとよい。他のビームのＴＲＰ／ビームの識別子とビーム毎に設定するＲＲＣパラメータを通知する。

【0959】

このようにすることで、ＵＥは、通信を行う複数のビームのＲＲＣパラメータを設定することが可能となる。ビームグループ内でのビーム間移動あるいはビームグループ内での通信するビームの変更の場合でも、ＵＥは、予め通知されたビーム毎のＲＲＣパラメータを設定して通信を行えばよい。

【0960】

ビームグループ外へのビーム間移動の場合、サービングビームの移動になる。この場合、移動元ビームから移動先ビームへのモビリティとなる。したがって、実施の形態２から実施の形態５の変形例３で開示した方法を適用することで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0961】

ビームグループとして、ＵＥが通信を行う複数のビーム（複数のサービングビーム）が設定される場合、ビームグループ内でプライマリビームおよびセカンダリビームを設けてもよい。プライマリビームはＵＣＩ（Uplink Control Information）の送信に用いるビームとするとよい。あるいは、プライマリビームは制御情報の通信に用いるビームとしてもよい。あるいは、プライマリビームはＮＡＳの通信に用いるビームとしてもよい。

【0962】

このような場合、プライマリビームの変更が発生する場合がある。元セカンダリビームをプライマリビームに変更する。このような場合、移動元ビームにプライマリビームを対応させ、移動先ビームに、プライマリビームに変更するセカンダリビームを対応させ、実施の形態２から実施の形態５の変形例３を適用するとよい。このようにすることで、ＲＲＣシグナリングを伴わないビーム間移動を可能とする。

【0963】

ビームグループとして、ＵＥが通信を行う複数のビーム（複数のサービングビーム）を設定した場合、移動元ビームで設定されたビームグループから移動先ビームで設定されるビームグループへのビームグループ間の移動が行われてもよい。あるいは、ビームグループの変更が行われてもよい。セルはＵＥに対して、ビームグループ間の移動あるいはビームグループの変更を行う。

【0964】

ビームグループ間の移動あるいはビームグループの変更が行われる場合、予め、移動先のビームグループ内のビームのＲＲＣパラメータ、あるいは、変更後のビームグループ内のビームのＲＲＣパラメータを通知しておいてもよい。これらの通知は、ＵＥのビームグループの移動あるいは変更の際、あるいは、ＵＥのビームグループの移動あるいは変更に先立って行われるとよい。

【0965】

例えば、ビームグループ内の所定の数のサービングビームの通信品質が所定の閾値を下回った場合としてもよい。サービングビームの通信品質として、下り通信の受信電力あるいは受信品質でもよい。ＵＥが測定するとよい。あるいは、上り通信の受信電力あるいは受信品質でもよい。セルが測定するとよい。

【0966】

このようにすることで、セルはＵＥに対して、ビームグループ内ビームのＲＲＣパラメータの通知を行うことができる。ＵＥは、受信したＲＲＣパラメータを用いて、通知されたビームグループ内のビームと通信を開始することが可能となる。複数のサービングビームの通信品質が急激に悪化したとしても、ビームグループの移動あるいは変更が可能となり、早期に通信が可能となる。

【0967】

例えば、ビームグループとして、サービングビームとＵＥがモニタするビームを設定した場合、予めビームグループ内複数（全てであってもよい）ビームのＲＲＣパラメータを通知しておいてもよい。実施の形態２で開示した、ＲＲＣシグナリングによる近傍のビームのＲＲＣパラメータを通知する方法を適宜適用するとよい。実施の形態２を適用する場合、近傍のビームのＲＲＣパラメータを通知する代わりに、ビームグループ内複数のビームのＲＲＣパラメータを通知する、とするとよい。

【0968】

ビームグループ内複数ビームのＲＲＣパラメータの通知は、ＵＥのビーム間移動に先立って行われるとよい。例えば、サービングビームの通信品質が所定の閾値を下回った場合としてもよい。あるいは、ビームグループ内のＲＲＣパラメータが変更となった場合としてもよい。サービングビームの通信品質として、下り通信の受信電力あるいは受信品質でもよい。ＵＥが測定するとよい。あるいは、上り通信の受信電力あるいは受信品質でもよい。セルが測定するとよい。

【0969】

このようにすることで、サービングビームの通信品質の急激な悪化により、ビーム間移動指示がＵＥに対して通知されないような場合に有効となる。あるいは、ビーム間移動指示において、移動先ビームの通知をしなくて済む。移動先ビームを一つに決定する必要がなくなる。

【0970】

ＵＥは、通信品質の急激な悪化あるいはビーム間移動指示により、予めＲＲＣパラメータを通知されたビームのうちのどのビームをモニタしてもよい。セルは予めＲＲＣパラメータを通知したビームのうちのどのビームを用いて通信をはじめてもよい。ＵＥは予めＲＲＣパラメータが通知されているため、早期に通信が可能となる。

【0971】

３ＧＰＰにおいて、グループベースドのビームマネージメントが議論されている。物理レイヤでのメジャメントによりビームグループが構成されることが提案されている。このビームグループに対して、実施の形態８から実施の形態８の変形例１で開示したＲＲＣパラメータの設定方法を適宜適用してもよい。同様の効果を得ることができる。

【0972】

物理レイヤでのメジャメントによりビームグループが構成されるため、無線リソースも物理レイヤで取り扱うとよい。例えば、実施の形態１で開示したＲＲＣパラメータで設定する無線リソースがある。このような場合、ＲＲＣレイヤと物理レイヤとの間でビームグループの情報の通知が行われてもよい。あるいは、ＲＲＣレイヤと物理レイヤとの間でＲＲＣパラメータの通知が行われてもよい。

【0973】

また、ＭＡＣレイヤはスケジューリング機能を有する。したがって、ＭＡＣレイヤとＲＲＣレイヤとの間、あるいはＭＡＣレイヤとＰＨＹレイヤとの間で、ビームグループの情報の通知、あるいは、ＲＲＣパラメータの通知が行われてもよい。これらの通知方法は、実施の形態２から実施の形態５で開示した、ＣＵとＤＵとの間での通信方法を適宜適用するとよい。このようにすることで、レイヤ間で必要となる情報の通知を行うことができる。

【0974】

前述の各実施の形態およびその変形例は、本発明の例示に過ぎず、本発明の範囲内において、各実施の形態およびその変形例を自由に組合せることができる。また各実施の形態およびその変形例の任意の構成要素を適宜変更または省略することができる。

【0975】

例えば、前述の各実施の形態およびその変形例において、サブフレームは、第５世代基地局通信システムにおける通信の時間単位の一例である。スケジューリング単位であってもよい。前述の各実施の形態およびその変形例において、サブフレーム単位として記載している処理を、ＴＴＩ単位、スロット単位、サブスロット単位、ミニスロット単位として行ってもよい。

【0976】

本発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、本発明がそれに限定されるものではない。例示されていない無数の変形例が、本発明の範囲から外れることなく想定され得るものと解される。

【符号の説明】

【0977】

２００ 通信システム、２０２ 通信端末装置、２０３，８００ 基地局装置、８０２ ＤＵ（Distributed Unit）、８０３ ＣＵ（Central Unit）、８０４～８１０ ビーム（無線ビーム）、８１１ セル。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】