JP7761768B2 - 通信制御方法 - Google Patents

Description

本開示は、セルラ通信システムに用いる通信制御方法に関する。

セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Third Generation Partnership Project）において、ＩＡＢ（Integrated Access and Backhaul）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、非特許文献１参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。

３ＧＰＰ ＴＳ ３８．３００ Ｖ１７．１．０（２０２２－０６）

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、基地局が、ユーザ装置に対して、ターゲットセル毎にＲＡＣＨレスハンドオーバによる接続が許可されているか否かを表す許可情報を含む条件付き再設定を送信するステップを有する。

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ドナーノードが、実行指示を受けて実行する実行条件を含む条件付き再設定を、移動中継ノード配下のユーザ装置へ送信するステップを有する。また、前記通信制御方法は、ドナーノードが、実行指示の送信を指示する送信指示を、移動中継ノードへ送信するステップを有する。更に、前記通信制御方法は、移動中継ノードが、送信指示を受信したことに応じて、実行指示をユーザ装置へ送信するステップを有する。

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ドナーノードが、移動中継ノード配下の複数のユーザ装置に共通する共通設定を含む第１メッセージを移動中継ノードへ送信するステップを有する。また、前記通信制御方法は、ドナーノードが、移動中継ノード配下の各ユーザ装置の個別設定を含む第２メッセージを移動中継ノードへ送信するステップを有する。更に、前記通信制御方法は、移動中継ノードが、共通設定と個別設定とを含むＲＲＣ再設定メッセージを各ユーザ装置へ送信するステップを有する。

図１は、一実施形態に係るセルラ通信システムの構成例を示す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を示す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を示す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を示す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を示す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を示す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を示す図である。 図９は、第１実施形態に係る動作例を表す図である。 図１０は、第１実施形態に係る他の動作例を表す図である。 図１１は、第２実施形態に係る解決策２の動作例を表す図である。 図１２は、第２実施形態に係る動作例を表す図である。 図１３は、第２実施形態に係る他の動作例を表す図である。 図１４（Ａ）と図１４（Ｂ）は、第３実施形態に係るグループハンドオーバの動作例を表す図である。 図１５は、第３実施形態に係る動作例を表す図である。 図１６は、第３実施形態に係る他の動作例を表す図である。 図１７は、伝統的なハンドオーバの例（上）及びグループ再設定の例（下）を示す図である。 図１８は、サービス中断の削減のための解決策１を示す図である。 図１９は、サービス中断の削減のための解決策２を示す図である。

図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。

［第１実施形態］
（セルラ通信システムの構成）
一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（New Radio）である。但し、セルラ通信システム１には、ＬＴＥ（Long Term Evolution）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。

図１は、一実施形態に係るセルラ通信システム１の構成例を示す図である。

図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：User Equipment）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。

以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。

なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。

５ＧＣ１０は、ＡＭＦ（Access and Mobility Management Function）１１及びＵＰＦ（User Plane Function）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Non-Access Stratum）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。

各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。以下では、セルと基地局とを区別しないで用いる場合がある。

各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。

各ｇＮＢ２００は、集約ユニット（ＣＵ：Central Unit）と分散ユニット（ＤＵ：Distributed Unit）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。

セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ２００－１（又はドナーノード。以下、「ドナーノード」と称する場合がある。）は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。

図１において、ＩＡＢノード３００－１がドナーノード２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。

ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末及び／又はタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、飛行体若しくは飛行体に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１において、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーノード２００－１と間接的に通信する。

図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係例を示す図である。

図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Mobile Termination）とを有する。

ＩＡＢ－ＭＴのＮＲ Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーノード２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。

ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーノード２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。

また、１つ又は複数のホップを介して、ドナーノード２００に接続されている全てのＩＡＢノード３００は、ドナーノード２００をルートとする有向非巡回グラフ（ＤＡＧ：Directed Acyclic Graph）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード２００は、バックホールリンクとアクセスリンクのネットワークを介して、ＵＥ１００に対して、ネットワークアクセスを提供するｇＮＢである。

（基地局の構成）
次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を示す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。

無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。

ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。

制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。なお、制御部２３０は、以下に示す各実施形態において、ｇＮＢ２００における各処理又は各動作を行ってもよい。

（中継ノードの構成）
次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を示す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。

無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。

無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。

制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。なお、制御部３２０は、以下に示す各実施形態において、ＩＡＢノード３００における各処理又は各動作を行ってもよい。

（ユーザ装置の構成）
次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を示す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。

無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。

制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。なお、制御部１２０は、以下に示す各実施形態において、ＵＥ１００における各処理を行うようにしてもよい。

（プロトコルスタックの構成）
次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。

図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Medium Access Control）レイヤと、ＲＬＣ（Radio Link Control）レイヤと、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤと、ＲＲＣ（Radio Resource Control）レイヤと、ＮＡＳ（Non-Access Stratum）レイヤとを有する。

ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。

ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ：Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ））及び割当リソースブロックを決定する。

ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。

ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーノード２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。

ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーノード２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーノード２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーノード２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。

図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーノード２００がＣＵ及びＤＵに分割されている一例を示す。

図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーノード２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Backhaul Adaptation Protocol）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。

各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Protocol Data Unit）は、バックホールＲＬＣチャネル（ＢＨ ＮＲ ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。

図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。

なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。

また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。

（移動ＩＡＢノード）
現在、３ＧＰＰでは、移動ＩＡＢノード（ｍｏｂｉｌｅ ＩＡＢ ｎｏｄｅ）の導入に向けた検討が開始されている。移動ＩＡＢノードとは、例えば、移動しているＩＡＢノードである。移動ＩＡＢノードは、移動可能なＩＡＢノードであってもよい。或いは、移動ＩＡＢノードは、移動する能力を有するＩＡＢノードであってもよい。或いは、移動ＩＡＢノードは、現在静止しているものの、将来移動することが確実な（又は将来移動することが予想される）ＩＡＢノードであってもよい。

移動ＩＡＢノードによって、例えば、移動ＩＡＢノード配下のＵＥ１００が移動ＩＡＢノードの移動に伴って移動しながら、移動ＩＡＢノードからサービスの提供を受けることが可能となる。例えば、乗り物に乗車しているユーザ（又はＵＥ１００）が、乗り物に設置された移動ＩＡＢノードを介して、サービスの提供を受けるケースなどが想定される。

一方、移動ＩＡＢノードに対して、移動することがないＩＡＢノードも存在する。このようなＩＡＢノードを、中間ＩＡＢノード（ｉｎｔｅｒｍｅｄｉａｔｅ ＩＡＢ ｎｏｄｅ）と称する場合がある。中間ＩＡＢノードは、例えば、移動しないＩＡＢノードである。或いは、中間ＩＡＢノードは、静止したＩＡＢノードでもよい。中間ＩＡＢノードは、静止ＩＡＢノード（ｓｔａｔｉｏｎａｒｙ ＩＡＢ ｎｏｄｅ）であってもよい。或いは、中間ＩＡＢノードは、設置場所に設置されたまま静止した（又は移動しない）ＩＡＢノードであってもよい。或いは、中間ＩＡＢノードは、移動することなく静止したＩＡＢノードであってもよい。中間ＩＡＢノードは、固定ＩＡＢノードであってもよい。

移動ＩＡＢノードは、中間ＩＡＢノードに接続することもできる。また、移動ＩＡＢノードは、ドナーノードに接続することもできる。一方、移動ＩＡＢノードは、移動（ｍｉｇｒａｔｉｏｎ又はハンドオーバ）により接続先を変更することも可能である。接続元は、中間ＩＡＢノードでもよい。当該接続元は、ドナーノードでもよい。また、接続先は、中間ＩＡＢノードでもよい。当該接続先は、ドナーノードでもよい。

なお、以下では、移動ＩＡＢノードの移動（ｍｉｇｒａｔｉｏｎ）と、移動ＩＡＢノードのハンドオーバ（ｈａｎｄｏｖｅｒ）とを区別しないで用いる場合がある。

（ＲＡＣＨレスハンドオーバ）
３ＧＰＰでは、ＲＡＣＨレスハンドオーバ（ＲＡＣＨ－ｌｅｓｓ ＨＯ）について規定されている（例えば、３ＧＰＰ ＴＳ ３６．３００ Ｖ１４．１３．０ （２０２０－１２））。ＲＡＣＨレスハンドオーバとは、ランダムアクセスプロシージャ（ｒａｎｄｏｍ ａｃｃｅｓｓ ｐｒｏｃｅｄｕｒｅ）をスキップしたハンドオーバのことである。ＲＡＣＨレスハンドオーバでは、例えば、以下のような処理が行われる。

すなわち、ＲＡＣＨレスハンドオーバが設定されたＵＥ１００は、ソースセルから、ＲＲＣ接続再設定（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを受信する。そして、当該ＵＥ１００は、ＲＲＣ接続再設定メッセージに含まれるターゲットセルに対して、ランダムアクセス（ＲＡＣＨ）プロシージャを実行することなく同期する。その後、ＵＥ１００は、ＲＲＣ接続再設定メッセージに含まれる上りリソースを利用して、ＲＲＣ接続再設定完了（ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージをターゲットセルへ送信して、ハンドオーバプロシージャを終了する。

ＲＡＣＨレスハンドオーバではランダムアクセスプロシージャがスキップされるため、ＵＥ１００では、ランダムアクセスプロシージャが実行される場合と比較して、ハンドオーバの実行時間の遅延を改善させることができる。

（条件付きハンドオーバ）
一般的なハンドオーバにおいては、ＵＥ１００がサービングセル及び／又は隣接セルの無線状態の測定値をｇＮＢ２００に報告し、この報告に基づいてｇＮＢ２００が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をＵＥ１００に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。

これに対し、条件付きハンドオーバは、予め設定されたトリガ条件が満たされると、ＵＥ１００は、当該トリガ条件に対応する候補セルへのハンドオーバを自律的に実行することが可能である。このため、一般的なハンドオーバにおける通信途絶などの問題を解決できる。

条件付きハンドオーバの設定は、条件付き再設定（ｃｏｎｄｉｔｉｏｎａｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）により行われる。条件付き再設定は、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージに含まれる情報要素（ＩＥ）の一つである。条件付き再設定は、例えば、ドナーノード２００のＣＵからＩＡＢノード３００のＩＡＢ－ＭＴとＵＥ１００とへ、ＲＲＣ再設定メッセージを送信することで設定が行われる。条件付き再設定は、条件付きハンドオーバで利用される候補セル及び実行条件を含む。実行条件には１つ以上のトリガ条件を含む。ＩＡＢノード３００のＩＡＢ－ＭＴとＵＥ１００とは、トリガ条件が満たされると、候補セルへのハンドオーバの実行を開始する。

（第１実施形態に係る通信制御方法）
移動ＩＡＢノードが、自身のハンドオーバにより、移動ＩＡＢノード配下のＵＥ１００について一斉にハンドオーバを行わせる場合がある。

移動ＩＡＢノード自身のハンドオーバにより、移動ＩＡＢノードの接続先となるセルのセルＩＤが変わる。ハンドオーバによって、移動ＩＡＢノードの接続先のセルＩＤが変わることで、移動ＩＡＢノード配下のＵＥ１００の接続先となるセルＩＤも変えた方が、移動ＩＡＢノード配下のＵＥ１００の管理が容易となることが考えられる。そのため、上述したようなケースが想定される。

このようなケースにおいて、移動ＩＡＢノード配下のＵＥ１００において、当該移動ＩＡＢノードに対する距離（又は位置）が変わらないのであれば、当該ＵＥ１００に対して、ＲＡＣＨレスハンドオーバを行わせた方が、ハンドオーバプロシージャの実行時間を短縮させることが可能となる。

一般に、ＲＲＣ設定を行うのは、ＣＵである。他方、セルを管理するのは、ＤＵである。

例えば、ｇＮＢ２００（又はドナーノード）のＤＵは、当該ＤＵが管理するセルの中で、タイミングアドバンス（ＴＡ）値が同じになるセルを把握している場合もある。また、例えば、移動ＩＡＢノードのＩＡＢ－ＤＵは、上述したように、配下のＵＥ１００との距離を把握している場合もある。

しかし、ＣＵ（ｇＮＢ２００のＣＵ又はドナーノード２００のＣＵ）は、セルの状況を把握していないため、ＵＥ１００に対してＲＡＣＨレスハンドオーバを適切に設定することができない場合がある。この場合、ＵＥ１００は、ネットワークへ適切に接続することができない。

そこで、第１実施形態では、ＵＥ１００がネットワークへ適切に接続できるようにすることを目的としている。

そのため、第１実施形態では、基地局（例えばｇＮＢ２００又はドナーノード２００）が、ユーザ装置（例えばｇＮＢ２００配下のＵＥ１００又は移動ＩＡＢノード３００Ｍ配下のＵＥ１００）に対して、ターゲットセル毎にＲＡＣＨレスハンドオーバによる接続が許可されているか否かを表す許可情報を含む条件付き再設定を送信する。

これにより、ＵＥ１００では、ハンドオーバの際に、どのターゲットセルへ接続すればＲＡＣＨレスハンドオーバが可能かを判定することができる。そのため、ＵＥ１００では、ターゲットセルがＲＡＣＨレスハンドオーバによる接続が許可されていれば、当該ターゲットセルに対してＲＡＣＨレスハンドオーバを実行することができる。よって、ＵＥ１００は、ネットワークへ適切に接続することができる。

（第１実施形態に係る動作例）
図９は、第１実施形態に係る動作例を表す図である。図９に示す例では、ＵＥ１００は、移動ＩＡＢノード３００Ｍ配下のＵＥであり、移動ＩＡＢノード３００Ｍのハンドオーバに伴い、ハンドオーバする例を表している。

この場合、ＵＥ１００にとって、ソースセルは、移動ＩＡＢノード３００Ｍがハンドオーバ前に接続していたセル（例えば、ドナーノード２００のＤＵが管理するセル）である。また、ＵＥ１００にとって、ターゲットセルは、移動ＩＡＢノード３００Ｍがハンドオーバにより接続した先のセル（例えば、ドナーノード２００のＤＵが管理するセルでもよい。当該ターゲットセルは、当該ＤＵ配下の中間ＩＡＢノード３００ＳのＩＡＢ－ＤＵが管理するセルでもよい）となる。

図９に示すように、ステップＳ１０において、ＵＥ１００は、ドナーノード２００のＣＵ（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）に対して、自身がＲＡＣＨレスハンドオーバを実行する能力を有していることを表すＲＡＣＨレスハンドオーバ能力情報を送信してもよい。ＲＡＣＨレスハンドオーバ能力情報は、ＵＥ１００がＲＡＣＨレスハンドオーバをサポートしていることを表す情報であってもよい。ＵＥ１００は、ＲＡＣＨレスハンドオーバ能力情報を含むＲＲＣメッセージを、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信してもよい。そして、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、当該ＲＲＣメッセージを含むＦ１メッセージを、ドナーノード２００のＣＵへ送信してもよい。

ステップＳ１１において、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、自身が管理するセルの中で、ＲＡＣＨレスハンドオーバが可能なセルの組合せを表す組合せ情報を、ドナーノード２００のＣＵへ送信する。移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、当該組合せ情報を含むＦ１メッセージを、ドナーノード２００のＣＵへ送信してもよい。
なお、ステップＳ１１に先立ち、ドナーノード２００のＣＵは、移動ＩＡＢノード３００Ｍに対して、当該組合せ情報の要求を行ってもよい。この場合、ドナーノード２００のＣＵは、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵに対して、当該組合せ情報の要求を含むＦ１メッセージを送信してもよい。

第１に、当該セルの組合せは、地理的に同じ場所に存在するセル同士でもよい。例えば、ソースセルとターゲットセルが物理的に同一である場合である。若しくは、例えば、ＵＥ１００が移動ＩＡＢノード３００Ｍのハンドオーバに伴って移動するものの、ＵＥ１００の移動ＩＡＢノード３００Ｍに対する位置は変わらない場合などである。

第２に、当該セルの組合せは、第１セルと第２セルとでタイミングアドバンス（ＴＡ）値が同じになるセル同士でもよい。ＵＥ１００がソースセルからターゲットセルへ移動する場合において、ソースセルからＵＥ１００への距離と、ターゲットセルからＵＥ１００への距離が同一の場合、ＴＡ値が同じになる。このようなソースセルとターゲットセルとの組合せが、組合せ情報に表されてもよい。移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、配下のＵＥ１００の過去のハンドオーバの履歴から、ＴＡ値が同じになるセルの組合せを把握してもよい。

第３に、当該セルの組合せは、移動ＩＡＢノード３００Ｍのハンドオーバによる変更前後のセルの組合せでもよい。例えば、移動ＩＡＢノード３００Ｍが第１セルから第２セルへハンドオーバした場合、第１セルと第２セルの組合せを、ＲＡＣＨレスハンドオーバが可能なセルの組合せとしてもよい。

組合せ情報には、以上のようなセルの組合せがリスト形式で含まれてもよい。当該セルの組合せは、当該セルのセルＩＤの組合せにより表されてもよい。

組合せ情報には、セルの組合せ毎に、ＵＥ１００がＲＡＣＨレスハンドオーバを実行する際に適用するＴＡ値が含まれてもよい。或いは、当該ＴＡ値は組合せ情報とは別に送信されてもよい。

ステップＳ１２において、ドナーノード２００のＣＵは、ＵＥ１００に対して、条件付き再設定を設定する。例えば、ドナーノード２００のＣＵは、組合せ情報に基づいて、条件付き再設定を含むＲＲＣメッセージ（例えばＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージ）を生成し、当該ＲＲＣメッセージを含む（又はカプセル化した）Ｆ１メッセージを移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信する。移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵでは、当該Ｆ１メッセージから当該ＲＲＣメッセージを抽出して、当該ＲＲＣメッセージをＵＥ１００へ送信する。

条件付き再設定は、ターゲットセル毎にＲＡＣＨレスハンドオーバによる接続が許可されているか否かを表す許可情報を含む。許可情報は、ターゲットセル毎にＲＡＣＨレスハンドオーバの実行が許可されているか否かを表してもよい。

第１に、ドナーノード２００のＣＵは、組合せ情報（ステップＳ１１）に基づいて、組合せ対象のセルを、ＲＡＣＨレスハンドオーバによる接続が許可されたターゲットセルとしてもよい。若しくは、ドナーノード２００のＣＵは、組合せ情報に含まれないセルを、ＲＡＣＨレスハンドオーバによる接続が許可されていないターゲットセルとしてもよい。若しくは、ドナーノード２００のＣＵは、組合せ情報に基づいて、ターゲットセルのＴＡ値が、ソースセルのＴＡ値と同じ値と判定した場合に、当該ターゲットセルに対してＲＡＣＨレスハンドオーバによる接続を許可してもよい。

第２に、許可情報がＲＡＣＨレスハンドオーバによる接続を許可することを表している場合、当該ターゲットセルに対してＲＡＣＨレスハンドオーバの実行が指示されていることを表してもよい。若しくは、ＵＥ１００固有のＰＲＡＣＨリソースが条件付き再設定に含まれないことで、暗示的に、ＲＡＣＨレスハンドオーバの実行が指示されていることを表してもよい。若しくは、ＵＥ１００がターゲットセルへＲＲＣ再設定完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージを送信するための無線リソース（ＰＵＳＣＨリソース）が条件付き再設定に含まれることで、ＲＡＣＨレスハンドオーバの実行が指示されていることを表してもよい。

ステップＳ１３において、ＵＥ１００は、条件付き再設定のトリガ条件が満たされたことで、条件付き再設定を実行する。その際、ＵＥ１００は、許可情報に基づいて、ターゲットセルにＲＡＣＨレスハンドオーバによる接続が許可されているか否かを確認する。ＵＥ１００は、ターゲットセルに対してＲＡＣＨレスハンドオーバによる接続が許可されていることを確認すると、当該ターゲットセルに対して、ＲＡＣＨレスハンドオーバを実行し、当該ターゲットセルへ接続する。一方、ＵＥ１００は、ターゲットセルに対してＲＡＣＨレスハンドオーバによる接続が許可されていないことを確認すると、ターゲットセルに対してランダムアクセスプロシージャを実行し、当該ターゲットセルへ接続する。

（第１実施形態に係る他の例１）
第１実施形態では、許可情報が条件付き再設定に含まれる例を説明したが、これに限定されない。例えば、許可情報は、条件付きハンドオーバではなく、通常のハンドオーバの実行するためのＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージに含まれてもよい。この場合、ドナーノード２００のＣＵは、組合せ情報（ステップＳ１１）に基づいて、許可情報を含むＲＲＣ再設定メッセージを生成し、当該ＲＲＣ再設定メッセージを含むＦ１メッセージを移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信する。そして、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、当該ＲＲＣ再設定メッセージをＵＥ１００へ送信する。ＵＥ１００は、当該ＲＲＣ再設定メッセージを受信したことに応じて、条件付きハンドオーバではなく、通常のハンドオーバプロシージャを実行する。この際、ＵＥ１００は、第１実施形態と同様に、許可情報に基づいて、ターゲットセルについてＲＡＣＨレスハンドオーバが可能か否かを確認し、以降の処理を行う。

（第１実施形態に係る他の例２）
また、第１実施形態では、ドナーノード２００と移動ＩＡＢノード３００ＭとＵＥ１００との間で、条件付き再設定が設定される例を説明したが、これに限定されない。例えば、ｇＮＢ２００とＵＥ１００との間で、条件付き再設定が設定されてもよい。

図１０は、第１実施形態に係る他の動作例を表す図である。図１０に示す例では、ＵＥ１００が、ｇＮＢ２００のＤＵが管理するソースセルから、ｇＮＢ２００のＤＵが管理するターゲットセルへ条件付きハンドオーバを実行する例を表している。

ＵＥ１００は、第１実施形態と同様に、ＲＡＣＨレスハンドオーバ能力情報を、ｇＮＢ２００のＣＵへ送信してもよい（ステップＳ１５）。この場合、ＵＥ１００は、ＲＡＣＨレスハンドオーバ能力情報を含むＲＲＣメッセージをｇＮＢ２００のＤＵへ送信し、ｇＮＢ２００のＤＵは、当該ＲＲＣメッセージを含むＦ１メッセージをｇＮＢ２００のＣＵへ送信してもよい。

そして、ｇＮＢ２００のＤＵは、組合せ情報を（含むＦ１メッセージを）、ｇＮＢ２００のＣＵへ送信する（ステップＳ１６）。組合せ情報には、第１実施形態と同様に、ＲＡＣＨレスハンドオーバが可能なセルの組合せが含まれる。

ｇＮＢ２００のＣＵでは、組合せ情報に基づいて、許可情報を含む条件付き再設定を生成し、当該条件付き再設定を、ＵＥ１００へ送信する（ステップＳ１７）。ｇＮＢ２００のＣＵは、当該条件付き再設定を含むＲＲＣメッセージを生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、ｇＮＢ２００のＤＵへ送信してもよい。ｇＮＢ２００のＤＵは、当該Ｆ１メッセージから当該ＲＲＣメッセージを抽出して、当該ＲＲＣメッセージをＵＥ１００へ送信してもよい。

そして、ＵＥ１００は、トリガ条件が満たされた場合、条件付き再設定を実行し、条件付きハンドオーバを実行する（ステップＳ１８）。ＵＥ１００は、許可情報に基づいて、ターゲットセルがＲＡＣＨレスハンドオーバの接続が許可されていることを確認した場合、ターゲットセルに対してＲＡＣＨレスハンドオーバを実行する。一方、ＵＥ１００は、許可情報に基づいて、ターゲットセルがＲＡＣＨレスハンドオーバの接続が許可されていないことを確認した場合、ターゲットセルに対してランダムアクセスプロシージャを実行する。

図１０のケースにおいても、第１実施形態と同様に、ＵＥ１００は、ターゲットセルに対して接続することが可能となるため、ネットワークへの接続を適切に行うことが可能となる。

（第１実施形態に係る他の例３）
第１実施形態では、移動ＩＡＢノード３００Ｍの例で説明したが、例えば、移動ＩＡＢノード３００Ｍに代えて、ＩＡＢノード（中間ＩＡＢノード３００Ｓ又はアクセスＩＡＢノード。アクセスＩＡＢノードは、ＵＥ１００をサービングしているＩＡＢノードのことである。）でも実施可能である。例えば、図９において、移動ＩＡＢノード３００Ｍを、中間ＩＡＢノード３００Ｓに読み替えることで実施可能である。

（第１実施形態に係る他の例４）
第１実施形態に係る他の例２では、ｇＮＢ２００とＵＥ１００との間で実施される例について説明したが、例えば、ドナーノード２００と移動ＩＡＢノード３００Ｍとの間で実施することも可能である。例えば、図１０において、ｇＮＢ２００をドナーノード２００と読み替え、ＵＥ１００を移動ＩＡＢノード３００Ｍと読み替えることで実施可能である。この場合、ドナーノード２００のＤＵが、ドナーノード２００のＣＵへ組み合わせ情報を送信する（ステップＳ１６）。そして、ドナーノード２００のＣＵが、組合せ情報に基づいて、許可情報を含む条件付き再設定を生成し、当該条件付き再設定を移動ＩＡＢノード３００ＭのＩＡＢ－ＭＴへ送信する（ステップＳ１７）。

［第２実施形態］
次に、第２実施形態について説明する。

第１実施形態では、移動ＩＡＢノード３００Ｍがハンドオーバする際に、配下のＵＥ１００を一斉にハンドオーバさせるケースがあることについて説明した。

このようなケースでは、移動ＩＡＢノード３００Ｍが配下の各ＵＥ１００へ、ハンドオーバの実行を指示するため、ＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを一斉に送信する場合がある。

しかし、移動ＩＡＢノード３００Ｍが当該メッセージを一斉に送信する場合、当該送信がない場合と比較して、各ＵＥ１００へ個別に当該メッセージが送信されるため、ダウンリンク方向の無線リソースの負荷が高くなる。また、移動ＩＡＢノード３００Ｍ配下のＵＥ１００では、当該メッセージの一斉送信により、サービスの中断が発生する可能もある。

そのため、３ＧＰＰでは、サービス中断を低減するための２つの解決策（「Ｓｏｌｕｔｉｏｎ １ ｆｏｒ ｒｅｄｕｃｔｉｏｎ ｏｆ ｓｅｒｖｉｃｅ ｉｎｔｅｒｒｕｐｔｉｏｎ」及び「Ｓｏｌｕｔｉｏｎ ２ ｆｏｒ ｒｅｄｕｃｔｉｏｎ ｏｆ ｓｅｒｖｉｃｅ ｉｎｔｅｒｒｕｐｔｉｏｎ」）について提案されている。このうち、解決策１は仕様化されている。

図１１は、解決策２（Ｓｏｌｕｔｉｏｎ ２ ｆｏｒ ｒｅｄｕｃｔｉｏｎ ｏｆ ｓｅｒｖｉｃｅ ｉｎｔｅｒｒｕｐｔｉｏｎ）の動作例を表す図である。図１１に示す例では、ドナーノード２００のＣＵ（ＩＡＢ－ｄｏｎｏｒ－ＣＵ）が、ＩＡＢノード３００と、その子ノード３００－Ｃと、その孫ノード３００－ＧＣとに対して、ＲＲＣ再設定メッセージを送信し、ＩＡＢノード３００と子ノード３００－Ｃと孫ノード３００－ＧＣがハンドオーバする例を表している。

２つの解決策では、いずれも、各ＩＡＢノード３００，３００－Ｃ，及び３００－ＧＣのハンドオーバが行われる前に、ドナーノード２００のＣＵが、ＲＲＣ再設定メッセージを送信する例となっている。各ＩＡＢノード３００，３００－Ｃ，及び３００－ＧＣに対して、事前にＲＲＣ再設定メッセージが送信されているため、当該メッセージが一斉に送信される場合と比較して、負荷分散を図ることができる。また、負荷分散により、各ＩＡＢノード３００，３００－Ｃ，及び３００－ＧＣ配下のＵＥ１００に対するサービス中断を軽減させることが可能となる。

なお、図１１に示すように、解決策２では、ＲＲＣ再設定メッセージの実行が子ノードのＩＡＢ－ＭＴで保留される解決策となっている。この場合、子ノードのＩＡＢ－ＭＴは、親ノード（すなわち、当該ＩＡＢノード）のＤＵからの指示（Ｉｎｄｉｃａｔｉｏｎ）を受けて、当該メッセージの実行を開始する。

一方、解決策１では、ＲＲＣ再設定メッセージの転送が親ＩＡＢノードのＩＡＢ－ＤＵで保留（又はバッファリング）される解決策となっている。解決策１では、ある条件が満たされると、保留されていた当該メッセージが送信される。

第２実施形態では、解決策２に着目する。解決策２について、移動ＩＡＢノード３００Ｍとその配下のＵＥ１００との関係でみると、例えば、以下のようになる。

すなわち、ドナーノード２００のＣＵは、移動ＩＡＢノード３００Ｍの配下のＵＥ１００に対して、ＲＲＣ再設定メッセージを送信する。そして、移動ＩＡＢノード３００ＭのＤＵは、実行指示（図１１に示す「Ｉｎｄｉｃａｔｉｏｎ」）をＵＥ１００へ送信する。ＵＥ１００は、当該実行指示を受けて、ＲＲＣ再設定メッセージの実行を開始する。

しかしながら、移動ＩＡＢノード３００ＭのＤＵは、実行指示（図１１に示す「Ｉｎｄｉｃａｔｉｏｎ」）の送信をどのタイミングで行えばよいかわからない。実行指示の送信タイミングが適切ではない場合、ＵＥ１００は、ターゲットセルに適切に接続できない。そのため、ＵＥ１００は、ネットワークに適切に接続できない場合がある。

そこで、第２実施形態では、第１実施形態と同様に、ＵＥ１００がネットワークに適切に接続できるようにすることを目的としている。

第２実施形態では、ドナーノード２００のＣＵが、ＵＥ１００に対して、条件付き再設定（ｃｏｎｄｉｔｉｏｎａｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）を設定し、その後、移動ＩＡＢノード３００Ｍに対して、実行指示の送信指示を送信する。そして、移動ＩＡＢノード３００Ｍでは、当該送信指示を受信したことに応じて実行指示をＵＥ１００へ送信する。ＵＥ１００では、当該実行指示を受信することで、条件付き再設定の実行を開始する。

具体的には、第１に、ドナーノード（例えばドナーノード２００）が、実行指示を受けて実行する実行条件を含む条件付き再設定を、移動中継ノード（例えば移動ＩＡＢノード３００Ｍ）配下のユーザ装置（例えばＵＥ１００）へ送信する。第２に、ドナーノードが、実行指示の送信を指示する送信指示を、移動中継ノードへ送信する。第３に、移動中継ノードが、送信指示を受信したことに応じて、実行指示をユーザ装置へ送信する。

これにより、例えば、移動ＩＡＢノード３００Ｍでは、ドナーノード２００からの送信指示を受けて、実行指示をＵＥ１００へ送信することができるため、ＵＥ１００に対して適切なタイミングで実行指示を送信することができる。従って、ＵＥ１００では、適切なタイミングで条件付き再設定を実行して、ターゲットセルへのハンドオーバを行うことが可能になる。よって、ＵＥ１００は、ネットワークへ適切に接続することができる。

（第２実施形態に係る動作例）
図１２は、第２実施形態に係る動作例を表す図である。

なお、図１２では、移動ＩＡＢノード３００Ｍが、ソース親ノード（Ｓｏｕｒｃｅ Ｐａｒｅｎｔ）３００－Ｓからターゲット親ノード（Ｔａｒｇｅｔ Ｐａｒｅｎｔ）３００－Ｔへハンドオーバする例を表している。また、図１２では、移動ＩＡＢノード３００Ｍのハンドオーバに伴って、配下のＵＥ１００もハンドオーバする例を表している。ソース親ノード３００－Ｓ及びターゲット親ノード３００－Ｔは、ドナーノード２００配下の中間ＩＡＢノード３００Ｓであってもよい。

図１２に示すように、ステップＳ２０において、ドナーノード２００のＣＵは、条件付き再設定をＵＥ１００へ設定する。例えば、ドナーノード２００のＣＵは、条件付き再設定を含むＲＲＣメッセージ（例えばＲＲＣ再設定（ＨＯコマンド）メッセージ）を生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信する。移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、当該Ｆ１メッセージから条件付き再設定を含むＲＲＣメッセージを抽出し、当該ＲＲＣメッセージをＵＥ１００へ送信する。

条件付き再設定には、１つの設定を１つのエントリとして、複数のエントリが含まれてもよい。当該複数のエントリの少なくとも１つについては、「実行指示により実行する」（又は「実行指示を受信した場合に実行する」）という実行条件が含まれる。これにより、ＵＥ１００では、当該実行条件については、条件付き再設定を受信しても実行を開始するのではなく、移動ＩＡＢノード３００Ｍからの実行指示を受けて実行を開始することになり、上述した解決策２に対応する動作が可能となる。

ステップＳ２１において、ドナーノード２００のＣＵは、実行指示の送信指示を移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信する。

第１に、ドナーノード２００のＣＵは、送信指示を含むＲＲＣメッセージを生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信してもよい。若しくは、ドナーノード２００のＣＵは、送信指示を含むＦ１メッセージを、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ送信してもよい。

第２に、送信指示には、当該送信指示の送信先となるＵＥ１００のＵＥ識別子が含まれてもよい。また、送信指示には、当該送信指示の送信対象となる条件付き再設定の識別子（ｃｏｎｄｉｔｉｏｎａｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ識別子）が含まれてもよい。当該識別子は、例えば、複数の条件付き再設定のうち、少なくともいずれかの条件付き再設定に対して送信対象とするかを指示する情報を表している。若しくは、送信指示には、当該送信指示の送信対象となる条件付き再設定内のリストのエントリ番号が含まれてもよい。

第３に、送信指示には、即座に実行指示を送信することを表す指示が含まれてもよい。若しくは、送信指示には、条件付きハンドオーバ実行時において実行指示を送信することを表す指示が含まれてもよい。若しくは、送信指示には、ハンドオーバ実行時において実行指示を送信することを表す指示が含まれてもよい。若しくは、送信指示には、ＲＲＣ再設定完了（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ）メッセージの送信時において実行指示を送信することを表す指示が含まれてもよい。

ステップＳ２２において、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、ＵＥ１００へ、実行指示を送信する。例えば、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、送信指示（ステップＳ２１）において指定されたＵＥ１００に対して、送信指示において指定された条件付き再設定についての実行指示を送信する。

実行指示は、ＭＡＣ制御要素（ＭＡＣ ＣＥ：MAC control element）に含めて送信されてもよい。当該実行指示は、ＢＡＰ制御ＰＤＵ（ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ）に含めて送信されてもよい。また、実行指示には、実行対象となる条件付き再設定の識別子（ｃｏｎｄｉｔｉｏｎａｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ識別子）が含まれる。当該識別子は、例えば、複数の条件付き再設定のうち、少なくともいずれかの条件付き再設定を実行すべきかを表す情報を表している。若しくは、実行指示には、実行対象となる条件付き再設定内のリストのエントリ番号が含まれてもよい。

ステップＳ２３において、ＵＥ１００は、指定された条件付き再設定を実行し、ターゲットセルへのハンドオーバを実行する。

（第２実施形態に係る他の例１）
第２実施形態では、移動ＩＡＢノード３００Ｍについて説明したが、これに限定されない。例えば、移動ＩＡＢノード３００Ｍに代えて、中間ＩＡＢノード３００Ｓであっても実施可能である。この場合、中間ＩＡＢノード３００Ｓ配下のＵＥ１００が、条件付き再設定を実行することで、中間ＩＡＢノード３００Ｓが管理するサービングセルから、中間ＩＡＢノード３００Ｓが管理するターゲットセル（又は他の中間ＩＡＢノード３００Ｓが管理するターゲットセル）へハンドオーバを実行することが可能となる。例えば、図１２において、移動ＩＡＢノード３００Ｍを、中間ＩＡＢノード３００Ｓと読み替えることで、図１２に示す動作例を実施することができる。

（第２実施形態に係る他の例２）
また、第２実施形態では、ＵＥ１００と移動ＩＡＢノード３００Ｍとドナーノード２００との間で条件付き再設定が設定される例について説明したが、これに限定されない。例えば、ＵＥ１００とｇＮＢ２００との間においても、第２実施形態で説明した条件付き再設定が適用可能である。

図１３は、第２実施形態に係る他の動作例を表す図である。

図１３に示すように、ｇＮＢ２００のＣＵは、第２実施形態と同様に、条件付き再設定をＵＥ１００に対して設定する（ステップＳ２５）。条件付き再設定に含まれるエントリの少なくとも１つには、「実行指示により実行する」という実行条件が含まれることは第２実施形態と同様である。ＵＥ１００は、第２実施形態と同様に、当該エントリについては、条件付き再設定が設定されてもすぐには実行することはなく、実行指示を受信するまで待つことになる。

そして、ｇＮＢ２００のＣＵは、実行指示の送信指示をｇＮＢ２００のＤＵへ送信する（ステップＳ２６）。送信指示の内容及び送信指示に含まれる情報も第２実施形態と同様でもよい。

ｇＮＢ２００のＤＵは、送信指示を受信したことに応じて、実行指示をＵＥ１００へ送信する（ステップＳ２７）。ＵＥ１００では、実行指示を受信したことで、第２実施形態と同様に、指示された実行条件を開始し、ターゲットセルへのハンドオーバを実行する（ステップＳ２８）。

［第３実施形態］
次に、第３実施形態について説明する。

現在、３ＧＰＰでは、移動ＩＡＢノード３００Ｍのグループハンドオーバ（ｇｒｏｕｐ ｈａｎｄｏｖｅｒ）について検討する予定となっている。グループハンドオーバとは、複数のＵＥ１００が１つのグループとして、当該グループによって一斉に行われるハンドオーバのことである。移動ＩＡＢノード３００Ｍのグループハンドオーバでは、移動ＩＡＢノード３００Ｍもグループに含まれて、ハンドオーバ対象となる。

図１４（Ａ）と図１４（Ｂ）は、第３実施形態に係るグループハンドオーバの動作例を表す図である。このうち、図１４（Ａ）では、ソースドナーノード（Ｓｏｕｒｃｅ ＩＡＢ－ｄｏｎｏｒ）２００－Ｓが、各ＵＥ１００－１，…，１００－ｎと移動ＩＡＢノード３００Ｍとに対して、ハンドオーバコマンドであるＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを各々送信する例である。

一方、図１４（Ｂ）は、ソースドナーノード２００－Ｓは、移動ＩＡＢノード３００Ｍに対して、グループ再設定（ＧｒｏｕｐＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージ（含むＦ１メッセージ）を送信する。グループ再設定メッセージは、例えば、グループハンドオーバの設定情報を含む。グループ再設定メッセージは、例えば、グループハンドオーバの指示を示すメッセージとなっている。移動ＩＡＢノード３００Ｍは、グループ再設定メッセージを、各ＵＥ１００－１，…，１００－ｎへ送信する。

図１４（Ｂ）に示す例では、ソースドナーノード２００－Ｓから移動ＩＡＢノード３００Ｍへ、１つのＦ１メッセージにより、グループハンドオーバの設定情報が送信される。ソースドナーノード２００－Ｓから移動ＩＡＢノード３００Ｍへ、ＵＥ１００－１，…，１００－ｎ毎に個別のメッセージ（Ｆ１メッセージ）が送信される場合（図１４（Ａ））と比較して、１つのＦ１メッセージにより、複数ＵＥ１００－１，…，１００－ｎに対してグループハンドオーバの設定を行うことができる。そのため、図１４（Ｂ）に示す例では、図１４（Ａ）に示す例と比較して、Ｆ１シグナリングの負荷軽減を図ることができる。特に、ＩＡＢに関しては、Ｆ１シグナリングも無線となるため、有線で行われる場合と比較して、Ｆ１シグナリングの負荷軽減も有効と考えられる。

一方、移動ＩＡＢノード３００Ｍは、Ｒｅｌ－１８専用のＵＥ１００ではなく、Ｒｅｌ－１７以前のＵＥ１００の接続も許容されることが前提となっている。そのため、少なくとも、移動ＩＡＢノード３００Ｍからは、グループハンドオーバ用の新たなＲＲＣ再設定メッセージではなく、Ｒｅｌ－１７以前のＵＥ１００も受信可能なＲＲＣ再設定メッセージが送信されることが望ましい。

そこで、第３実施形態では、移動ＩＡＢノード３００Ｍでは、ドナーノードから、グループ共通の共通設定とＵＥ個別の個別設定とを受信すると、これらを結合し、Ｒｅｌ－１７以前のＵＥ１００も受信可能なＲＲＣ再設定メッセージを各ＵＥ１００へ送信する例について説明する。

具体的には、第１に、ドナーノード（例えばソースドナーノード２００－Ｓ）が、移動中継ノード（例えば移動ＩＡＢノード３００Ｍ）配下の複数のユーザ装置（例えばＵＥ１００）に共通する共通設定を含む第１メッセージを移動中継ノードへ送信する。第２に、ドナーノードが、移動中継ノード配下の各ユーザ装置の個別設定を含む第２メッセージを移動中継ノードへ送信する。第３に、移動中継ノードが、共通設定と個別設定とを含むＲＲＣ再設定メッセージを各ユーザ装置へ送信する。

これにより、例えば、共通設定を含むメッセージは、１つのメッセージにより、グループ内のＵＥ１００への共通設定が可能となる。このため、図１４（Ａ）で示すようにＵＥ毎に各々メッセージが送信される場合と比較して、第２実施形態では、Ｆ１シグナリングの低減を図ることができる。

また、例えば、ＵＥ１００へ送信されるメッセージは、Ｒｅ－１７以前のＵＥ１００も受信可能なＲＲＣ再設定メッセージが用いられている。そのため、Ｒｅ－１７以前のＵＥ１００についても、グループハンドオーバにより、ターゲットセルへ適切に接続することができる。よって、ＵＥ１００は、第１実施形態と同様に、ネットワークへ適切に接続することが可能となる。

（第３実施形態に係る動作例）
図１５は、第３実施形態に係る動作例を表す図である。

図１５に示す例では、移動ＩＡＢノード３００Ｍが、ソースドナーノード（Ｓｏｕｒｃｅ ＩＡＢ－ｄｏｎｏｒ）２００－Ｓからターゲットドナーノード（Ｔａｒｇｅｔ ＩＡＢ－ｄｏｎｏｒ）２００－Ｔへ、ハンドオーバが行われる例を表している。また、図１４に示す例では、移動ＩＡＢノード３００Ｍ配下のＵＥ１００－１，…，１００－ｎも、移動ＩＡＢノード３００Ｍのハンドオーバに伴い、１つのグループとなってグループハンドオーバを行う例を表している。以下では、複数のＵＥ１００－１，…，１００－ｎにより形成されて、グループハンドオーバが行われるグループを、「ＵＥグループ」と称する場合がある。

図１５に示すように、ステップＳ３０において、ソースドナーノード２００－ＳのＣＵは、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ、ＵＥグループの共通設定を送信する。

第１に、ソースドナーノード２００－ＳのＣＵは、共通設定を含むＲＲＣメッセージ（例えばＲＲＣ再設定メッセージ）を生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、移動ＩＡＢノード３００Ｍへ送信してもよい。若しくは、ソースドナーノード２００－ＳのＣＵは、共通設定を含むＦ１メッセージを移動ＩＡＢノード３００Ｍへ送信してもよい。いずれの場合も、当該Ｆ１メッセージは、第１メッセージの一例である。

第２に、共通設定には、ＵＥグループに属するＵＥ１００－１，…，１００－ｎで共通の設定が含まれる。当該設定は、設定値そのものでもよい。当該設定は、情報要素（ＩＥ）として表されてもよい。共通設定を含むメッセージには、ＵＥグループの識別子を表すＵＥグループ識別子が含まれてもよい。また、共通設定を含むメッセージには、ＵＥグループに属するＵＥ１００のＵＥ識別子のリストが含まれてもよい。ＵＥグループ識別子及び／又はＵＥ識別子のリストは、共通設定に含まれてもよい。

ステップＳ３１において、ソースドナーノード２００－ＳのＣＵは、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵへ、ＵＥグループの個別設定を送信する。

第１に、ソースドナーノード２００－ＳのＣＵは、個別設定を含むＲＲＣメッセージ（例えばＲＲＣ再設定メッセージ）を生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、移動ＩＡＢノード３００Ｍへ送信してもよい。若しくは、ソースドナーノード２００－ＳのＣＵは、個別設定を含むＦ１メッセージを移動ＩＡＢノード３００Ｍへ送信してもよい。いずれの場合も、当該Ｆ１メッセージは第２メッセージの一例である。

第２に、個別設定には、ＵＥグループに属するＵＥ１００－１，…，１００－ｎ毎に個別の設定が含まれる。当該設定は、設定値そのものでもよい。当該設定は、情報要素（ＩＥ）として表されてもよい。個別設定を含むメッセージには、ＵＥグループに属するＵＥ１００のＵＥ識別子が含まれる。当該ＵＥ識別子は、個別設定の対象となるＵＥ１００を表している。当該ＵＥ識別子は、個別設定に含まれてもよい。

ステップＳ３２において、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、共通設定と個別設定とを結合し、共通設定と個別設定とを含むＲＲＣ再設定メッセージを生成する。当該ＲＲＣ再設定メッセージは、Ｒｅｌ－１７以前のＵＥ１００も受信可能なＲＲＣ再設定メッセージである。

なお、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵでは、共通設定と個別設定とで同一の設定が含まれる場合、個別設定の設定を優先することで、同一の設定が、共通設定と個別設定との双方に含まれないようにしてもよい。

そして、移動ＩＡＢノード３００ＭのＩＡＢ－ＤＵは、生成したＲＲＣ再設定メッセージを、ＵＥグループに属する各ＵＥ１００－１，…，１００－ｎへ送信する。

その後、ステップＳ３３において、移動ＩＡＢノード３００ＭのＩＡＢ－ＭＴと、各ＵＥ１００－１，…，１００－ｎとは、ターゲットドナーノード（Ｔａｒｇｅｔ ＩＡＢ－ｄｏｎｏｒ）２００－Ｔへ、ＲＲＣ再設定完了メッセージを送信し、グループハンドオーバを完了させる。

（第３実施形態の他の例１）
第３実施形態では、移動ＩＡＢノード３００Ｍ配下のＵＥ１００においてグループハンドオーバが行われる例について説明したがこれに限定されない。例えば、ｇＮＢ２００配下のＵＥ１００においてもグループハンドオーバが行われてもよい。

図１６は、第３実施形態に係る他の動作例を表す図である。

図１６においては、ｇＮＢ２００配下のＵＥ１００－１，…，１００－ｎがＵＥグループを形成し、当該ＵＥ１００－１，…，１００－ｎにおいてグループハンドオーバが行われる例を表している。

図１６に示すように、ｇＮＢ２００のＣＵは、ｇＮＢ２００のＤＵへ、共通設定を送信する（ステップＳ３５）。ｇＮＢ２００のＣＵは、第３実施形態と同様に、共通設定を含むＲＲＣメッセージ（例えばＲＲＣ再設定メッセージ）を生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、ｇＮＢ２００のＤＵへ送信してもよい。若しくは、ｇＮＢ２００のＣＵは、第３実施形態と同様に、共通設定を含むＦ１メッセージを、ｇＮＢ２００のＤＵへ送信してもよい。共通設定自体は、第３動作例と同一でもよい。

また、ｇＮＢ２００のＣＵは、ｇＮＢ２００のＤＵへ、個別設定を送信する（ステップＳ３６）。ｇＮＢ２００のＣＵは、第３実施形態と同様に、個別設定を含むＲＲＣメッセージ（例えばＲＲＣ再設定メッセージ）を生成し、当該ＲＲＣメッセージを含むＦ１メッセージを、ｇＮＢ２００のＤＵへ送信してもよい。若しくは、ｇＮＢ２００のＣＵは、第３実施形態と同様に、個別設定を含むＦ１メッセージを、ｇＮＢ２００のＤＵへ送信してもよい。個別設定自体は、第３実施形態と同一でもよい。

そして、ｇＮＢ２００のＤＵは、共通設定と個別設定とを結合して、共通設定と個別設定とを含むＲＲＣ再設定メッセージを、各ＵＥ１００－１，…，１００－ｎへ送信する（ステップＳ３８）。当該ＲＲＣ再設定メッセージが、Ｒｅｌ－１７以前のＵＥ１００においても受信可能なＲＲＣ再設定メッセージであることは第３実施形態と同様である。各ＵＥ１００－１，…，１００－ｎは、ターゲットセルに対して、ＲＲＣ再設定完了メッセージを送信し、ハンドオーバを完了させる（ステップＳ３８）。

［その他の実施形態］
ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭ又はＤＶＤ－ＲＯＭ等の記録媒体であってもよい。

また、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ：Ｓｙｓｔｅｍ ｏｎ ａ ｃｈｉｐ）として構成してもよい。

本開示で使用されている「に基づいて（ｂａｓｅｄ ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「含む（ｉｎｃｌｕｄｅ）」、及び「備える（ｃｏｍｐｒｉｓｅ）」の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。

以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、各実施形態、各動作例、又は各処理などは、矛盾しない範囲で適宜組み合わせることも可能である。

本願は、米国仮出願第６３／３９５９４０号（２０２２年８月８日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

（第１付記）
（付記１）
セルラ通信システムで用いる通信制御方法であって、
基地局が、ユーザ装置に対して、ターゲットセル毎にＲＡＣＨレスハンドオーバによる接続が許可されているか否かを表す許可情報を含む条件付き再設定を送信するステップ、を有する
通信制御方法。

（付記２）
前記基地局はドナーノードであり、前記ユーザ装置は移動中継ノード配下のユーザ装置である
付記１記載の通信制御方法。

（付記３）
前記移動中継ノードが、前記ＲＡＣＨレスハンドオーバによる接続が可能なセルの組合せを表す組合せ情報を、前記ドナーノードへ送信するステップ、を更に含み、
前記条件付き再設定を送信するステップは、前記基地局が、前記組合せ情報に基づいて、前記条件付き再設定を送信するステップを含む、
付記１又は付記２に記載の通信制御方法。

（付記４）
前記組合せ情報を送信するステップは、前記移動中継ノードが、前記組合せ毎のタイミングアドバンス値を送信するステップを含む
付記１乃至付記３のいずれかに記載の通信制御方法。

（付記５）
セルラ通信システムで用いる通信制御方法であって、
ドナーノードが、実行指示を受けて実行する実行条件を含む条件付き再設定を、移動中継ノード配下のユーザ装置へ送信するステップと、
前記ドナーノードが、前記実行指示の送信を指示する送信指示を、前記移動中継ノードへ送信するステップと、
前記移動中継ノードが、前記送信指示を受信したことに応じて、前記実行指示を前記ユーザ装置へ送信するステップと、を有する
通信制御方法。

（付記６）
前記実行指示を送信するステップは、前記移動中継ノードが、複数の前記条件付き再設定のうち少なくともいずれかの前記条件付き再設定を実行すべきかを表す情報を含む前記実行指示を送信するステップを含む
付記５記載の通信制御方法。

（付記７）
セルラ通信システムで用いる通信制御方法であって、
ドナーノードが、移動中継ノード配下の複数のユーザ装置に共通する共通設定を含む第１メッセージを前記移動中継ノードへ送信するステップと、
前記ドナーノードが、前記移動中継ノード配下の各前記ユーザ装置の個別設定を含む第２メッセージを前記移動中継ノードへ送信するステップと、
前記移動中継ノードが、前記共通設定と前記個別設定とを含むＲＲＣ再設定メッセージを前記各ユーザ装置へ送信するステップと、を含む
通信制御方法。

（第２付記）
１． 導入
ＲＡＮ＃９４ｅは、移動ＩＡＢに関する新しいワークアイテムを承認しました。そのＷＩＤはＲＡＮ＃９６で以下のように改訂された。

このワークアイテムの詳細な目標は以下の通りである。
・ＩＡＢノードのモビリティを可能にするための移行／トポロジ適応手順を定義する。これには、移動ＩＡＢノード全体の相互ドナー間移行（完全な移行）も含まれる。
・ＩＡＢノードとそのサーブされたＵＥのモビリティを強化する。これには、グループモビリティに関連する側面が含まれる。周囲のＵＥを対象とした最適化はない。
注意：解決策では、ＩＡＢノードモビリティに固有の機能強化を除き、Ｒｅｌ－１７での議論がすでに行われているトピックや、そのトピックがＲｅｌ－１７から除外されているトピックに触れないようにする必要がある。
・ＩＡＢノードのモビリティによる干渉の緩和、例えば参照信号や制御信号（ＰＣＩ、ＲＡＣＨなど）の衝突を避ける必要がある。
注意：作業開始時には、ＲＡＮ３とＲＡＮ２とは、移動ＩＡＢノードがステーショナリ（中間）ＩＡＢノードに接続するシナリオと、移動ＩＡＢノードが直接ＩＡＢドナーに接続するシナリオとの間での潜在的な複雑さについて議論すべきである。

以下の原則が尊重されるべきである。
－移動ＩＡＢノードはレガシーＵＥにサービスを提供可能とする必要がある。
－移動ＩＡＢの最適化を提供する解決策には、Ｒｅｌ－１８ＵＥの拡張機能が必要となる場合があるが、そのような拡張機能に下位互換性がある場合に限る。

Ｒｅｌ－１８の主要な課題の１つは、移動ＩＡＢノードの移行中に複数の子孫ＵＥのハンドオーバを効率的に実行する方法である。この付記では、ＵＥハンドオーバの観点から、移動ＩＡＢのモビリティ強化に関する最初の議論が提供される。

２． 議論
２．１ グループ再設定
グループＵＥのモビリティは、移動ＩＡＢの可能な強化策の１つとして期待されている。なぜなら、移動ＩＡＢノードが新しいＩＡＢドナーに移動する際には、多くのＵＥが同時にハンドオーバされる必要があるからである。

現行の仕様では、ハンドオーバは専用のシグナリング、すなわちＲＲＣ再設定と同期によって示される。これは、複数の個別のメッセージが同時に各ＵＥに送信されることを意味する。したがって、シグナリングのオーバーヘッドや遅延を削減するための候補として、グループ再設定が考えられる。これにより、１つのメッセージで複数のＵＥを再設定することが期待されている。

グループ再設定は、既にＲｅｌ－１７ＭＢＳで「共通ＲＲＣ構造」として議論され、以下の要約が提供された。

共通のＲＲＣ構造に関する要約
結論
ＲＲＣ設定の共通化は実現不可能との意見が１６対５と大多数を占めた。報告者の観点からは、それを妨げる技術的な制限はないようだが、これを行うことには大きな反対があるようである。一般的な理解では、共通のＲＲＣ構造を採用することでＵｕ信号のオーバーヘッドが増えるが、Ｆ１／Ｅ１信号にはメリットがあるとされている。しかし、企業の立場を考慮すると、現行のＲＲＣ信号構造を維持することが提案されている。

提案２：現行のＣＲＲＲＣ構造を維持し、共通のＲＲＣ構造を進めない（すなわち、ＲＲＣＣＲへの影響はない）。

ポイントは、ＵＥは個別のＲＲＣ再設定を受信する必要があり、それに加えてグループＲＲＣ再設定を受信する必要があるということである。そのため、ＭＢＳではＵｕ信号に対してはあまりメリットがない（むしろデメリット）という共通の見解があったが、Ｆ１／Ｅ１信号にはいくらかのメリットがある可能性がある。その結果、ＲＡＮ２は現行の構造を維持することを決定した。つまり、個別のＲＲＣ再設定のみで行う。

Ｐ２の場合、ＲＡＮ２は合意される場合、ＲＲＣは引き続き専用のＵＥ設定を使用すると仮定している。

移動ＩＡＢに対しても同様の懸念が適用される。つまり、異なるＵＥには異なる設定があり、１つのグループ再設定では異なるＵＥの異なる設定を処理できない。Ｆ１信号の削減もＭＢＳよりも移動ＩＡＢの方が有用であるが、バックホールリンクは一般的にＦＲ２上で仮定されているため、アクセスリンクの信号削減が依然としてより重要である。

ＷＩＤには明確に「Ｒｅｌ－１７の議論がすでに行われ、そのトピックがＲｅｌ－１７から除外された場所には触れないように、ＩＡＢノードの移動性に特化した改善を除いて、解決策を避けるべきである」と記載されているため、ＲＡＮ２はＲｅｌ－１８移動ＩＡＢにおいてグループ再設定（又は共通のＲＲＣ構造）を再度開く必要はない、少なくともＲＡＮ２の観点からはそうである。

提案１：ＲＡＮ２は、移動ＩＡＢノードの移動に伴うＵＥのハンドオーバについて、現状通り個別のＲＲＣ再設定のみを使用することに合意すべきである。

２．２ レガシーＵＥのためのハンドオーバ
ＷＩＤ（Ｗｏｒｋ Ｉｔｅｍ Ｄｅｓｃｒｉｐｔｉｏｎ）に示されているように、「移動ＩＡＢノードはレガシーＵＥに対応する必要がある。」したがって、ＲＡＮ２はレガシーＵＥのためのハンドオーバ方法について検討すべきである。

ＲＡＮ３は、Ｒｅｌ－１７におけるドナー間ＩＡＢノードの移行中のサービス中断の削減に対して２つの解決策を有していた。そのうち、解決策１は図１７に示されている。

解決策１では、ＩＡＢ－ＤＵはハンドオーバ完了時に子ノードへのＲＲＣ再設定メッセージを保留する。ＲＡＮ２は両方の解決策がさらなる議論を必要とすると結論付けましたが、解決策１の方が解決策２よりも全体的な影響が少ないと判断しました。

もちろん、解決策１なしでＵＥのハンドオーバを実行することもできる。ただし、Ｒｅｌ－１７のＩＡＢノードの問題と同様に、子孫ＵＥのハンドオーバが関与するため、解決策１が適用されない場合、ＵＥは移動中のＩＡＢノードの移行中にサービスの中断を経験することになる。したがって、ＲＡＮ２は、ドナー間移動ＩＡＢノードの移行中にレガシーＵＥのサービス中断を削減するために、ドナー内移行のための解決策１が再利用されると仮定する必要がある。

提案２：ＲＡＮ２は、Ｒｅｌ－１７のドナー内ＩＡＢノードの移行中のサービス中断を削減するための解決策１がレガシーＵＥのハンドオーバに再利用できると仮定すべきである。

２．３ 条件付き再設定
個々のＲＲＣ再設定がＵＥに同時に送信される場合、多くのＲＲＣメッセージとそれに対応する応答により、無線リソースの負荷が増加する可能性がある。負荷分散、つまり時間領域の分散のために、条件付き再設定は有用と考えられる。これは、ＩＡＢドナーが移動中のＩＡＢノードの事前再設定を行うことで、ＩＡＢドナーが多くの同時メッセージ送信を回避できるようにするためである。Ｒｅｌ－１７のサービス中断の削減のための解決策２にも類似した解決策がある。

所見１：条件付き再設定は、ＩＡＢドナーがＲＲＣ再設定メッセージを時間領域で分散させるのに役立つ可能性がある。

移動ＩＡＢ－ＤＵがセルをどのように処理するかに依存し、ＲＡＮ３の決定による部分もあるが、移動ＩＡＢノードの移行後、移動ＩＡＢ－ＤＵがセルＩＤを変更する必要がある可能性が考えられる。例えば、ターゲットのトポロジでＰＣＩの衝突を回避するために変更が必要な場合である。この場合、ＵＥも古いセル（消滅するセル）から新しいセル（利用可能になるセル）へと移動する必要があるが、両方のセルは同じ移動ＩＡＢ－ＤＵによって管理される。このような「セルシフト」に対して、条件付き再設定が従来のＨＯコマンドよりも効果的であると考えられる。

所見２：移動ＩＡＢノードの移行によりサービングセルＩＤが変更される場合、条件付き再設定が効率的に機能する可能性がある。

上記の例を考慮して（これらに限定されるものではないが）、条件付き再設定の改良はＲＡＮ２で議論する価値があってもよい。例えば、既存のトリガ条件が移動ＩＡＢに再利用可能かどうかを検討することが挙げられる。

提案３：ＲＡＮ２は、ＵＥへの条件付き再設定を移動ＩＡＢノードの移動性向上のために強化できるかどうかを検討すべきである。

２．４ ＲＡＣＨレスハンドオーバ
現行の仕様では、ＵＥはＨＯコマンドを受信するとまずランダムアクセスプロシージャを開始する必要がある。ただし、ターゲットセルがソースセルと同じである場合、つまり同じＩＡＢ－ＤＵが両方のセルを処理する場合、セルＩＤのみが異なる可能性がある。この場合、タイミングアドバンス値も両方のセルで同じであるため、ＰＲＡＣＨ送信は不要である。ＲＡＮ２は、ＲＡＣＨレスハンドオーバを移動ＩＡＢの移動性向上のために仕様化するかどうかを検討すべきである。ＲＡＣＨレスハンドオーバは、Ｒｅｌ－１８ＵＥにのみ適用されるので、注意する必要がある。

提案４：ＲＡＮ２は、移動ＩＡＢノードの移動により、Ｒｅｌ－１８ＵＥのＲＡＣＨレスハンドオーバが有用かどうかを検討すべきである。

２．５ ロスレスハンドオーバ
検討段階では、ホップ・バイ・ホップＡＲＱによるパケット損失の問題が議論された。この問題は、「ホップ・バイ・ホップホールリンクの障害後にＩＡＢトポロジの変更が実行されたとき、またはＣＵ間ハンドオーバが発生したとき」に観察された。Ｒｅｌ－１６／１７では、固定（静止）ＩＡＢノードを使用した展開の仮定ではまれなケースであると考えられるため、これは追求されなかった。

Ｒｅｌ－１８の移動ＩＡＢでは、もし常に移動ＩＡＢノードがアクセスＩＡＢノードである場合、このようなパケットロスは依然として稀なケースとして考えられる。ＷＩＤの正当化部分には、「移動ＩＡＢノードには子孫のＩＡＢノードがないため、つまりＵＥのみをサービングしている」という仮定が記載されている。したがって、このような仮定はＲＡＮ２によって確認されるべきである。

提案５：ＲＡＮ２は、移動ＩＡＢノードが常にアクセスＩＡＢノードであることを確認し、そのためにＲｅｌ－１８移動ＩＡＢにおいてホップ・バイ・ホップＡＲＱによるパケットロスが稀なケースであることを確認すべきである。

一般的なパケットロスに関しては、レガシーなハンドオーバでも、ＵＥのＰＤＣＰサブレイヤーが現在と同様にデータの回復を処理できる。そのため、移動ＩＡＢノードの移動によるＵＥのロスレスなハンドオーバに向けた改善は予定されていない。

提案６：ＲＡＮ２は、移動ＩＡＢノードの移動によるロスレスなハンドオーバにおいて、既存のＵＥのＰＤＣＰデータ回復を使用できることに合意すべきであり、つまり改善は必要ないとする。

２．６ その他の側面
ＷＩＤは、移動ＩＡＢノードがＵＥのみをサポートすると述べている。

・移動ＩＡＢノードは子ノードを持たず、つまりＵＥのみをサポートする必要がある。

この制限を確実にするために、既存のＩＡＢサポートＩＥを再利用することができる。つまり、移動ＩＡＢノードはＳＩＢ１でこのＩＥを設定しないようにすることで、他のＩＡＢノードのアクセスを防止し、ＵＥのアクセスを許可する。問題は、そのような制限が仕様にどのように記載されているかである。Ｓｔａｇｅ－２の仕様で明確な記述があると、移動ＩＡＢの実装において混乱を避けるのに役立つと考えられる。

提案７：ＲＡＮ２は、このリリースで移動ＩＡＢノードとして機能する場合、ＩＡＢノードがＳＩＢにＩＡＢサポートＩＥを設定しないようにすることをＳｔａｇｅ－２の仕様に記述することに合意すべきである。

Claims (6)

1. セルラ通信システムで用いる通信制御方法であって、
   基地局が、ユーザ装置に対して、ターゲットセル毎にＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）レスハンドオーバの設定が可能な条件付き再設定を送信すること、を有し、
   前記条件付き再設定は、条件付きハンドオーバの設定を示し、
   前記条件付き再設定で設定されるターゲットセルのそれぞれは、前記基地局が形成するセル又は前記基地局以外の他の基地局が形成するセルである
   通信制御方法。
2. セルラ通信システムの基地局であって、
   ユーザ装置に対して、ターゲットセル毎にＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）レスハンドオーバの設定が可能な条件付き再設定を送信する送信部、を有し、
   前記条件付き再設定は、条件付きハンドオーバの設定を示し、
   前記条件付き再設定で設定されるターゲットセルのそれぞれは、前記基地局が形成するセル又は前記基地局以外の他の基地局が形成するセルである
   基地局。
3. セルラ通信システムのユーザ装置であって、
   ターゲットセル毎にＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）レスハンドオーバの設定が可能な条件付き再設定を基地局から受信する受信部と、
   前記条件付き再設定に従って、前記ＲＡＣＨレスハンドオーバを実行する制御部と、を有し、
   前記条件付き再設定は、条件付きハンドオーバの設定を示し、
   前記条件付き再設定で設定されるターゲットセルのそれぞれは、前記基地局が形成するセル又は前記基地局以外の他の基地局が形成するセルである
   ユーザ装置。
4. ユーザ装置と基地局とを有するセルラ通信システムであって、
   前記基地局が、前記ユーザ装置に対して、ターゲットセル毎にＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）レスハンドオーバの設定が可能な条件付き再設定を送信し、
   前記ユーザ端末が、前記条件付き再設定を受信し、
   前記条件付き再設定は、条件付きハンドオーバの設定を示し、
   前記条件付き再設定で設定されるターゲットセルのそれぞれは、前記基地局が形成するセル又は前記基地局以外の他の基地局が形成するセルである
   セルラ通信システム。
5. セルラ通信システムの基地局に、
   ユーザ装置に対して、ターゲットセル毎にＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）レスハンドオーバの設定が可能な条件付き再設定を送信する処理、を実行させ、
   前記条件付き再設定は、条件付きハンドオーバの設定を示し、
   前記条件付き再設定で設定されるターゲットセルのそれぞれは、前記基地局が形成するセル又は前記基地局以外の他の基地局が形成するセルである
   プログラム。
6. 基地局のチップセットであって、
   ユーザ装置に対して、ターゲットセル毎にＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）レスハンドオーバの設定が可能な条件付き再設定を送信すること、を含み、
   前記条件付き再設定は、条件付きハンドオーバの設定を示し、
   前記条件付き再設定で設定されるターゲットセルのそれぞれは、前記基地局が形成するセル又は前記基地局以外の他の基地局が形成するセルである
   チップセット。