JP7636601B2 - 通信制御方法、移動ｉａｂノード、プログラム、チップセット及びセルラ通信システム - Google Patents

Description

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

セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（登録商標。以下同じ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．５．０（２０２１－０３）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードを配下に有する第１通信ノードが、第２通信ノードに対して、前記中継ノードにおいて使用可能なセルＩＤ（Ｉｄｅｎｔｉｔｙ）を問い合わせることを含む。また、前記通信制御方法は、第２通信ノードが、問い合わせに応じて、中継ノードにおいて使用可能なセルＩＤのうち、第２通信ノードで使用可能なセルＩＤと衝突しないセルＩＤを決定し、決定したセルＩＤを第１通信ノードへ送信することを含む。更に、前記通信制御方法は、第１通信ノードが、決定したセルＩＤを中継ノードへ送信することを含む。更に、前記通信制御方法は、中継ノードが、決定したセルＩＤを用いて移動処理を実行することを含む。

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、現在使用するセルが使用できなくなることを検知することを含む。また、前記通信制御方法は、中継ノードが、使用できなくなるセルのセルＩＤを、中継ノードの子ノード及び／又はユーザ装置へ送信することを含む。

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ソースドナーノードが、時間をトリガ条件に含む条件付きハンドオーバ（Ｔｉｍｅ－ｔｒｉｇｇｅｒｅｄ ＣＨＯ（Ｃｏｎｄｉｔｉｏｎａｌ Ｈａｎｄｏｖｅｒ））をターゲットドナーノードへ要求する要求メッセージを送信することを含む。前記通信制御方法は、ターゲットドナーノードが、要求メッセージを受信したことに応じて、要求を受け入れる受け入れメッセージをソースドナーノードへ送信することを含む。前記通信制御方法は、ソースドナーノードは、受け入れメッセージを受信したことに応じて、時間余裕で条件付きハンドオーバを実行するよう中継ノードを設定することを含む。

第４の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、現在使用するセルＩＤを示す第１セルＩＤと、変更後のセルＩＤを示す第２セルＩＤとを報知することを含む。また、前記通信制御方法は、中継ノードが、第１セルＩＤのセルにアクセスする中継ノードの子ノード及び／又は第１セルＩＤのセルにアクセスするユーザ装置を、第２セルＩＤのセルへハンドオーバさせることを含む。更に、前記通信制御方法は、中継ノードが、子ノード及び／又はユーザ装置をハンドオーバさせた後、第１セルＩＤの報知を停止することを含む。

第５の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第１通信ノードが、第１通信ノードに隣接する隣接ノードから受信した隣接セルのＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）設定に基づいて、当該隣接セルのＰＲＡＣＨ設定と衝突しないＰＲＡＣＨ設定を決定することを有する。また、前記通信制御方法は、第１通信ノードが、決定したＰＲＡＣＨ設定を中継ノードへ送信することを含む。

図１は、一実施形態に係るセルラ通信システムの構成例を表す図である。 図２は、一実施形態に係るＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を表す図である。 図３は、一実施形態に係るｇＮＢ（ドナーノード）の構成例を表す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を表す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を表す図である。 図６は、一実施形態に係るＩＡＢ－ＭＴのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）接続に関するプロトコルスタックの例を表す図である。 図７は、一実施形態に係るＦ１－Ｕプロトコルに関するプロトコルスタックの例を表す図である。 図８は、一実施形態に係るＦ１－Ｃプロトコルに関するプロトコルスタックの例を表す図である。 図９（Ａ）と図９（Ｂ）は、第１実施形態に係るセルＩＤ（のリスト）の送信例を表す図である。 図１０は、第１実施形態に係る具体例を表す図である。 図１１は、第１実施形態に係る動作例を表す図である。 図１２は、第１実施形態の第１変形例に係る動作例を表す図である。 図１３は、第１実施形態の第２変形例に係る動作例を表す図である。 図１４は、第１実施形態の第３変形例に係る動作例を表す図である。 図１５（Ａ）と図１５（Ｂ）は、第１実施形態の第３変形例に係るＦ１コンテナの例を表す図である。 図１６は、第２実施形態に係る動作例を表す図である。 図１７は、第３実施形態に係る動作例を表す図である。 図１８は、第４実施形態に係る動作例を表す図である。 図１９は、第５実施形態に係るＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）リソースの衝突例を表す図である。 図２０は、第５実施形態に係る動作例を表す図である。 図２１は、第５実施形態の第１変形例に係る動作例を表す図である。 図２２は、第５実施形態の変形例２に係る動作例を表す図である。

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

（セルラ通信システムの構成）
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システムは３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システムにおける無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システムは、６Ｇなど、将来のセルラ通信システムも適用されてよい。

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

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

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

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

５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。

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

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

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

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

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

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

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

図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｉｏｎ）とを有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤと、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤとを有する。

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

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

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

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

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

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

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

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

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

なお、ドナーノード２００のＣＵは、ＩＡＢノード３００とドナーノード２００のＤＵへのＦ１インターフェイスを終端する、ドナーノード２００のｇＮＢ－ＣＵ機能である。また、ドナーノード２００のＤＵは、ＩＡＢ ＢＡＰサブレイヤをホストし、ＩＡＢノード３００へワイヤレスバックホールを提供する、ドナーノード２００のｇＮＢ－ＤＵ機能である。

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

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

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

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

（ＰＣＩ Ｃｏｌｌｉｓｉｏｎについて）
セルを識別するＩＤ（Ｉｄｅｎｔｉｔｙ）として、ＮＣＧＩ（ＮＲ Ｃｅｌｌ Ｇｌｏｂａｌ ＩＤ）がある。ＮＣＧＩは、ＮＲセルをグローバルに識別するために用いられる。ＮＣＧＩは、セルが属するＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ） ＩＤと、セルのＮＣＩ（ＮＲ Ｃｅｌｌ Ｉｄｅｎｔｉｔｙ）とから構成される。ＮＣＧＩは、事業者識別番号であるＰＬＭＮ ＩＤを含み、かつ、ＮＣＩも含むため、ＮＣＧＩを用いることで、全世界で一意に、セルを識別することが可能である。そのため、ＮＣＧＩの衝突（Ｃｏｌｌｉｓｉｏｎ）は発生しない。

ＮＣＩについても、ｇＮＢ ＩＤとセルＩＤとにより構成され、ＰＬＭＮ内でｇＮＢセルを一意に識別することが可能である。そのため、ＮＣＩの衝突も基本的には発生しない。

他方、ＰＣＩ（Ｐｈｙｓｉｃａｌ Ｃｅｌｌ ＩＤ）は、５Ｇでは、１００８個、用意されているが、ＰＬＭＮ内で一意に識別することが可能な態様とはなっていない。

現在、３ＧＰＰでは、ＩＡＢノード３００が移動するＭｏｂｉｌｅ ＩＡＢについて検討されている。ＩＡＢノード３００の移動は、当該ＩＡＢノード３００を管理するドナーノード２００内において行われる場合もあれば、ドナーノード２００とは異なるドナーノードへ移動する場合もある。

このようなＩＡＢノード３００の移動によって、同一のＰＣＩを有する異なるＩＡＢノードと近接する場合がある。このような近接により、異なるＩＡＢノード配下の各々のセルが同一のＰＣＩを用いて処理する場合がある。

従って、ＩＡＢノード３００の移動により、ＰＣＩ Ｃｏｌｌｉｓｉｏｎが発生する場合がある。ＰＣＩ Ｃｏｌｌｉｓｉｏｎにより、以下のような不具合が発生する場合がある。

すなわち、ＵＥ１００は、セルサーチにおいて最適ではないセルを選択する場合がある。ＵＥ１００は、セルサーチの際に、ＰＳＳ（Ｐｒｉｍａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）とＳＳＳ（Ｓｅｃｏｎｄａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）とを用いてＰＣＩを計算する。ＰＣＩ Ｃｏｌｌｉｓｉｏｎにより、ＵＥ１００は、実際は異なるセルを同一セルのＰＣＩとして計算する。そのため、ＵＥ１００は、最適ではないセルを選択する場合がある。また、ＵＥ１００は、ＰＳＳとＳＳＳの受信自体に時間がかかる場合もある。

更に、ＵＥ１００は、ＰＣＩ Ｃｏｌｌｉｓｉｏｎにより、ハンドオーバに失敗する場合がある。すなわち、ソース基地局２００は、Ｍｅａｓｕｒｅｍｅｎｔ Ｒｅｐｏｒｔに含まれるＰＣＩに基づいて、ハンドオーバ処理を行うと、正しいターゲットセルではない別のセルへＵＥ１００をハンドオーバさせてしまう場合がある。

第１実施形態では、ＩＡＢノード３００の移動によるＰＣＩ Ｃｏｌｌｉｓｉｏｎの発生を抑制することを目的としている。

（セルＩＤとＰＣＩについて）
ＰＣＩとセルＩＤとは異なる概念である。ＰＣＩは、上述したように、５Ｇでは、予め用意された１００８個のいずれかに該当するＩＤである。他方、セルＩＤは、ＰＬＭＮのサブセットに関連づけられ、ＳＩＢ１（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ ｔｙｐｅ １）により報知されるＩＤである。

ただし、以下では、特に断らない限り、ＰＣＩとセルＩＤとを区別しないで用いる場合がある。また、ＰＣＩとセルＩＤとをまとめて、セルＩＤと称する場合もある。これらの点は、第１実施形態だけではなく、第２実施形態以降も同様である。なお、ＰＣＩとセルＩＤとを区別する場合は、セルＩＤを、Ｃｅｌｌ ＩＤと称する場合がある。

（セルＩＤの通知について）
セルＩＤは、ｇＮＢ－ＤＵに対しては、ＯＡＭ（Ｏｐｅｒａｔｉｏｎｓ， Ａｄｍｉｎｉｓｔｒａｔｉｏｎ， ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）により設定される。

他方、ｇＮＢ－ＤＵは、ｇＮＢ－ＣＵへ、セルＩＤ（のリスト）を送信することが可能である。図９（Ａ）は、第１実施形態に係るセルＩＤ（のリスト）の送信例を表す図である。図９（Ａ）は、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージを用いて、セルＩＤ（のリスト）を送信する例を表している。なお、Ｆ１ Ｓｅｔｕｐは、ｇＮＢ－ＤＵとｇＮＢ－ＣＵとにおいて、Ｆ１インターフェイス上で正確に相互運用するために、必要なアプリケーションデータを交換する場合に用いられる。Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージは、そのようなＦ１ Ｓｅｔｕｐを要求するためのメッセージである。

図９（Ａ）に示すように、ステップＳ１において、ｇＮＢ－ＤＵは、当該セルのセルＩＤ（のリスト）を含むＦ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージを、ｇＮＢ－ＣＵへ送信する。ステップＳ２において、ｇＮＢ－ＣＵは、アクティブ化するセルＩＤ（のリスト）を含むＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを、ｇＮＢ－ＤＵへ送信する。

図９（Ｂ）は、第１実施形態に係るセルＩＤ（のリスト）の送信例を表す図である。図９（Ｂ）では、ｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージを用いて、セルＩＤ（のリスト）を送信する例を表す図である。なお、ｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅは、ｇＮＢ－ＤＵとｇＮＢ－ＣＵとの間において、Ｆ１インターフェイス上で正確に相互運用するために、必要なアプリケーションデータを更新する場合に用いられる。ｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージは、そのような更新を行うために用いられるメッセージである。

図９（Ｂ）に示すように、ステップＳ３において、ｇＮＢ－ＤＵは、追加、変更、及び／又は削除するセルのセルＩＤ（のリスト）を含むｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージを、ｇＮＢ－ＣＵへ送信する。ステップＳ４において、ｇＮＢ－ＣＵは、アクティブ化、及び非アクティブ化するセルのセルＩＤ（のリスト）を含むｇＮＢ－ＤＵＣｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ Ａｃｋｎｏｗｌｅｄｇｅメッセージを、ｇＮＢ－ＤＵへ送信する。

このように、セルＩＤの決定権は、ＯＡＭ又はｇＮＢ－ＤＵにある。ｇＮＢ－ＣＵは、主に、ｇＮＢ－ＤＵからの要求に対して、アクティブ化するか否かを制御している。

（第１実施形態の動作例）
第１実施形態は、セルラ通信システム１で用いる通信制御方法を含む。通信制御方法は、中継ノード（例えば、ＩＡＢノード３００）を配下に有する第１通信ノード（例えば、ソースドナーノード２００－１）が、第２通信ノード（例えば、ターゲットドナーノード２００－２）に対して、中継ノードにおいて使用可能なセルＩＤ（Ｉｄｅｎｔｉｔｙ）を問い合わせる。次に、第２通信ノードが、問い合わせに応じて、中継ノードにおいて使用可能なセルＩＤのうち、第２通信ノードで使用可能なセルＩＤと衝突しないセルＩＤを決定し、決定したセルＩＤを第１通信ノードへ送信する。次に、第１通信ノードが、決定したセルＩＤを中継ノードへ送信する。そして、中継ノードが、決定したセルＩＤを用いて移動処理を実行する。

具体的には、以下のようになる。すなわち、最初に、ソースドナーノード２００－１は、ＩＡＢノード３００において使用可能なセルＩＤを含むＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージをターゲットドナーノード２００－２へ送信する。次に、ターゲットドナーノード２００－２が、ＩＡＢノード３００において使用可能なセルＩＤのうち、ターゲットドナーノード２００－２において使用可能なセルＩＤと衝突しないセルＩＤを決定する。次に、ターゲットドナーノード２００－２は、当該セルＩＤを含むＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージをソースドナーノード２００－１へ送信する。ソースドナーノード２００－１は、当該セルＩＤを含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージをＩＡＢノード３００へ送信する。そして、ＩＡＢノード３００は、当該セルＩＤを用いて、ターゲットドナーノード２００－２への移動処理（具体的には接続処理）を実行する。

図１０は、第１実施形態に係る具体例を表す図である。図１０は、ＩＡＢノード３００が、ソースドナーノード２００－１からターゲットドナーノード２００－２へ移動する例を表している。

図１０に示すように、ソースドナーノード２００－１は、ＩＡＢノード３００において使用可能なセルＩＤ（ＰＣＩ＃２とＰＣＩ＃３）を、ターゲットドナーノード２００－２へ送信する。ターゲットドナーノード２００－２は、ＩＡＢノード３００が使用可能なセルＩＤのうち、自ノード２００－２で使用可能なセルＩＤ（ＰＣＩ＃２）と衝突しないセルＩＤ（ＰＣＩ＃３）を決定する。ターゲットドナーノード２００－２は、ソースドナーノード２００－１を介して、ＩＡＢノード３００へ、決定したセルＩＤ（ＰＣＩ＃３）を通知する。

このように、第１実施形態では、ＩＡＢノード３００は、ＩＡＢノード３００において使用可能なセルＩＤのうち、ターゲットドナーノード２００－２において使用可能なセルＩＤと衝突しないセルＩＤを、ターゲットドナーノード２００－２から受信する。そのため、当該セルＩＤを用いて移動処理を行うことで、ＰＣＩ Ｃｏｌｌｉｓｉｏｎを抑制することができる。

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

ただし、図１１に示す動作が行われる前に、ＯＡＭによって、自局が使用可能なセルＩＤがＩＡＢノード３００に設定されているものとする。

セルＩＤは、セルＩＤのリストであってもよい。当該リストには、複数のセルＩＤが含まれる。当該リストには、アクティブなセルのセルＩＤと非アクティブなセルのセルＩＤとが含まれてもよい。もしくは、当該リストには、アクティブなセルのセルＩＤと非アクティブなセルのセルＩＤのいずれか一方のセルＩＤが含まれてもよい。

また、セルＩＤは、使用可能なセルＩＤの範囲によって示されてもよい。例えば、使用可能なセルＩＤの範囲として、「ＰＣＩ＃１からＰＣＩ＃３」などがある。

このように、セルＩＤには、セルＩＤのリスト及び／又はセルＩＤの範囲が含まれてもよい。

また、図１１に示す動作が行われる前に、ＩＡＢノード３００は、自局が使用可能なセルＩＤをソースドナーノード２００－１へ通知しているものとする。ＩＡＢノード３００のＩＡＢ－ＤＵは、自局が使用可能なセルＩＤを含むＦ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージをソースドナーノード２００－１のＣＵへ送信してもよい。また、ＩＡＢノード３００のＩＡＢ－ＤＵは、自局が使用可能なセルＩＤを含むｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージをソースドナーノード２００－１のＣＵへ送信してもよい。

なお、図１１に示す例は、Ｘｎハンドオーバを想定している。

図１１に示すように、ステップＳ１０において、ソースドナーノード２００－１は、配下のＩＡＢノード３００を、ｍｉｇｒａｔｉｏｎ（又はハンドオーバ。以下では、「ハンドオーバ」と称する場合がある。）させることを決定する。ハンドオーバは、ソースドナーノード２００－１からターゲットドナーノード２００－２へのハンドオーバである。

ステップＳ１１において、ソースドナーノード２００－１は、ＩＡＢノード３００が使用可能なセルＩＤを含むＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージを、ターゲットドナーノード２００－２へ送信する。当該使用可能なセルＩＤは、セルＩＤのリストでもよい。当該使用可能なセルＩＤには、それぞれのセルＩＤがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルＩＤは、使用禁止のセルＩＤとして通知されてもよい。この送信が、ＩＡＢノード３００で使用可能なセルＩＤをターゲットドナーノード２００－２へ問い合わせることに対応する。なお、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージは、Ｘｎメッセージの一例である。

ステップＳ１２において、ターゲットドナーノード２００－２は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージを受信したことに応じて、ＩＡＢノード３００が使用可能なセルＩＤのうち、ターゲットドナーノード２００－２で使用可能なセルＩＤと衝突しないセルＩＤを決定する。

ステップＳ１３において、ターゲットドナーノード２００－２は、決定したセルＩＤを含むＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージを、ソースドナーノード２００－１へ送信する。当該決定したセルＩＤは、セルＩＤのリストでもよい。当該決定したセルＩＤには、それぞれのセルＩＤをアクティブ化するのか非アクティブ化するのかの情報が含まれていてもよい。もしくは、当該決定したセルＩＤは、使用禁止のセルＩＤとして通知されてもよい。Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージは、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージに対する応答メッセージであって、Ｘｎメッセージの一例である。当該決定したセルＩＤは、ターゲットドナーノード２００－２が生成したＲＲＣメッセージ（例えばＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）に含まれてもよい。当該決定したセルＩＤは、当該メッセージはカプセル化されて（すなわち当該Ｘｎメッセージのコンテナに格納されて）、送信されてもよい。

ステップＳ１４において、ソースドナーノード２００－１は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージを受信したことに応じて、決定したセルＩＤを含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージを、ＩＡＢノード３００へ送信する。ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージは、ＲＲＣメッセージの一例である。

ステップＳ１５において、ＩＡＢノード３００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージを受信したことに応じて、決定したセルＩＤをアクティブ化する。ＩＡＢノード３００は、セルＩＤのアクティブ化と連動して、ターゲットドナーノード２００－２に対してアクセスを開始する。なお、ステップＳ１５において、ＩＡＢノード３００は、アクティブ化したセルＩＤ以外のセルＩＤを非アクティブ化してもよい。

図１１に示す例は、ＩＡＢノード３００がハンドオーバにより、ドナーノード２００－１，２００－２間で移動する場合について説明した。例えば、ＩＡＢノード３００の親ノード３００－Ｐ１，３００－Ｐ２間でＩＡＢノード３００がハンドオーバする場合でもよい。ＩＡＢノード３００の上位ノード間でＩＡＢノード３００がハンドオーバする場合でもよい。また、ｇＮＢ－ＣＵ間でＩＡＢノード３００がハンドオーバする場合でもよい。いずれの場合も、各メッセージが、親ノード３００－Ｐ１，３００－Ｐ２間、上位ノード間、ｇＮＢ－ＣＵ間、ＩＡＢノード３００と親ノード間、ＩＡＢノード３００と上位ノード間、ＩＡＢノード３００のＤＵとｇＮＢ－ＣＵ間で交換されてもよい。

以降、第１実施形態における第１の別の実施形態を説明するが、当該実施形態についても、このようなドナーノード２００－１，２００－２間のハンドオーバ以外の例が用いられてもよい。

（第１実施形態の第１変形例）
次に、第１実施形態の第１変形例について説明する。第１実施形態では、ソースドナーノード２００－１がターゲットドナーノード２００－２に、ＩＡＢノード３００において使用可能なセルＩＤの問い合わせる例について説明した。第１実施形態の第１変形例は、ソースドナーノード２００－１がＡＭＦ１１へ問い合わせる例である。

具体的には、以下のようになる。すなわち、最初に、ソースドナーノード２００－１が、ＩＡＢノード３００において使用可能なセルＩＤを含む第１メッセージをＡＭＦ１１へ送信する。次に、ＡＭＦ１１が、ＩＡＢノード３００において使用可能なセルＩＤのうち、ＡＭＦ１１配下で使用可能なセルＩＤと衝突しないセルＩＤを決定する。そして、ＡＭＦ１１は、決定したセルＩＤを含む第２メッセージをソースドナーノード２００－１へ送信する。ソースドナーノード２００－１は、決定したセルＩＤを含むＨａｎｄｏｖｅｒ ＣｏｍｍａｎｄメッセージをＩＡＢノード３００へ送信し、ＩＡＢノード３００は、決定したセルＩＤを用いてターゲットドナーノード２００－２への移動処理（具体的には接続処理）を実行する。

第１変形例も、ＩＡＢノード３００は、自局で使用可能なセルＩＤのうち、ＡＭＦ１１配下で使用可能なセルＩＤと衝突しないセルＩＤをＡＭＦ１１から受信する。そのため、ＩＡＢノード３００は、ＡＭＦ１１配下のターゲットドナーノード２００－２へ移動する場合であっても、ＰＣＩ Ｃｏｌｌｉｓｉｏｎを抑制することができる。

図１２は、第１実施形態の第１変形例に係る動作例を表す図である。図１２に示す動作例における事前設定も、第１実施形態の動作例（図１１）と同様である。

図１２に示すように、ステップＳ２０において、ソースドナーノード２００－１は、ＩＡＢノード３００をソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバさせることを決定する。

ステップＳ２１において、ソースドナーノード２００－１は、ＩＡＢノード３００において使用可能なセルＩＤを含む第１メッセージを、ＡＭＦ１１へ送信する。当該使用可能なセルＩＤは、セルＩＤのリストでもよい。当該使用可能なセルＩＤには、それぞれのセルＩＤがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルＩＤは、使用禁止のセルＩＤとして通知されてもよい。第１メッセージは、ＮＧメッセージの一例であって、新規メッセージである。第１メッセージは、ＩＡＢ ｍｉｇｒａｔｉｏｎ ｉｎｑｕｉｒｙメッセージと称する場合がある。ＩＡＢ ｍｉｇｒａｔｉｏｎ ｉｎｑｕｉｒｙメッセージの送信が、ＩＡＢノード３００で使用可能なセルＩＤのＡＭＦ１１への問い合わせに該当する。

ステップＳ２２において、ＡＭＦ１１は、ＩＡＢ ｍｉｇｒａｔｉｏｎ ｉｎｑｕｉｒｙメッセージの受信に応じて、ＩＡＢノード３００において使用可能なセルＩＤのうち、ＡＭＦ１１配下で使用可能なセルＩＤと衝突しないセルＩＤを決定する。

ステップＳ２３において、ＡＭＦ１１は、決定したセルＩＤを含む第２メッセージをソースドナーノード２００－１へ送信する。第２メッセージも、ＮＧメッセージの一例であって、新規メッセージである。第２メッセージは、ＩＡＢ ｍｉｇｒａｔｉｏｎ ｉｎｑｕｉｒｙ Ｒｅｓｐｏｎｓｅメッセージと称する場合がある。

ステップＳ２５において、ソースドナーノード２００－１は、ＩＡＢ ｍｉｇｒａｔｉｏｎ ｉｎｑｕｉｒｙ Ｒｅｓｐｏｎｓｅメッセージの受信に応じて、ターゲットドナーノード２００－２との間で、Ｘｎハンドオーバ準備手順を実行する。Ｘｎハンドオーバ準備手順は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージの送受信と、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージの送受信を含む。

ステップＳ２６において、ソースドナーノード２００－１は、ＡＭＦ１１で決定したセルＩＤを含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージを、ＩＡＢノード３００へ送信する。

ステップＳ２７において、ＩＡＢノード３００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージの受信に応じて、決定したセルＩＤをアクティブ化する。ＩＡＢノード３００は、アクティブ化したセルＩＤを用いて、ターゲットドナーノード２００－２に対してアクセスを開始する。

（第１実施形態の第２変形例）
次に、第１実施形態の第２変形例について説明する。第１実施形態と、第１実施形態の第１変形例では、Ｘｎハンドオーバの例について説明した。第１実施形態の第２変形例は、ＮＧハンドオーバを適用した場合の例である。Ｘｎハンドオーバでは、ハンドオーバ手順が、主に、ドナーノード２００－１，２００－２間で行われた。ＮＧハンドオーバでは、ＡＭＦ１１などの５ＧＣ１０に含まれる装置もハンドオーバ手順に含まれる。

具体的には、第１通信ノードがソースドナーノード２００－１であり、第２通信ノードがＡＭＦ１１の例である。また、中継ノードがＩＡＢノード３００の例である。最初に、ソースドナーノード２００－１は、ＩＡＢノード３００において使用可能なセルＩＤを含むＨａｎｄｏｖｅｒ ＲｅｑｕｉｒｅｄメッセージをＡＭＦ１１へ送信する。次に、ＡＭＦ１１は、ＩＡＢノード３００において使用可能なセルＩＤのうち、ＡＭＦ１１配下で使用可能なセルＩＤと衝突しないセルＩＤを決定する。ＡＭＦ１１は、決定したセルＩＤを含む第１Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージをソースドナーノード２００－１へ送信する。そして、ソースドナーノード２００－１が、決定したセルＩＤを含む第２Ｈａｎｄｏｖｅｒ ＣｏｍｍａｎｄメッセージをＩＡＢノード３００へ送信し、ＩＡＢノード３００が、決定したセルＩＤを用いてターゲットドナーノード２００－２への接続処理を実行する。

第２変形例においても、ＩＡＢノード３００は、自局で使用可能なセルＩＤのうち、ＡＭＦ１１配下で使用可能なセルＩＤと衝突しないセルＩＤをＡＭＦ１１から受信する。そのため、ＩＡＢノード３００は、ＡＭＦ１１配下のターゲットドナーノード２００－２へ移動する場合であっても、ＰＣＩ Ｃｏｌｌｉｓｉｏｎを抑制することができる。

なお、第２変形例では、ＡＭＦ１１に代えて、５ＧＣ１０に含まれる他の装置（例えば、ＵＰＦ１２）であってもよい。

図１３は、第１実施形態の第２変形例に係る動作例を表す図である。図１３に示す動作例における事前設定も、第１実施形態の動作例（図１１）と同様である。

ステップＳ３０において、ソースドナーノード２００－１は、ＩＡＢノード３００をソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバさせることを決定する。

ステップＳ３１において、ソースドナーノード２００－１は、ＩＡＢノード３００において使用可能なセルＩＤを含むＨａｎｄｏｖｅｒ ＲｅｑｕｉｒｅｄメッセージをＡＭＦ１１へ送信する。Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージは、ＮＧプロトコルのメッセージである。当該使用可能なセルＩＤは、セルＩＤのリストでもよい。当該使用可能なセルＩＤには、それぞれのセルＩＤがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルＩＤは、使用禁止のセルＩＤとして通知されてもよい。

ステップＳ３２において、ＡＭＦ１１は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｉｒｅｄメッセージの受信に応じて、ＩＡＢノード３００において使用可能なセルＩＤのうち、ＡＭＦ１１配下で使用可能なセルＩＤと衝突しないセルＩＤを決定する。

ステップＳ３３において、ＡＭＦ１１は、決定したセルＩＤを含むＨａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージを、ソースドナーノード２００－１へ送信する。Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージも、ＮＧプロトコルのメッセージである。なお、ＡＭＦ１１は、ターゲットドナーノード２００－２との間でもハンドオーバに関連するメッセージの交換を行うが、図１３では省略されている。

ステップＳ３４において、ソースドナーノード２００－１は、Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄメッセージの受信に応じて、決定したセルＩＤを含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージをＩＡＢノード３００へ送信する。

ステップＳ３５において、ＩＡＢノード３００は、ＡＭＦ１１で決定したセルＩＤをアクティブ化し、アクティブ化したセルＩＤを用いて、移動処理を行う。具体的には、ＩＡＢノード３００は、当該セルＩＤを用いてターゲットドナーノード２００－２への接続処理を実行する。

（第１実施形態の第３変形例）
次に、第１実施形態の第３変形例を説明する。第１実施形態の第３変形例では、ＩＡＢノード３００のドナーノード２００－２に対するＦ１ Ｓｅｔｕｐを、ドナーノード２００－１を介して行う例である。そして、第１実施形態の第３変形例では、このようなＦ１ Ｓｅｔｕｐがハンドオーバ手順内で行われる例を表している。

具体的には、第１通信ノードはソースドナーノード２００－１であり、第２通信ノードはターゲットドナーノード２００－２の例を表している。また、中継ノードはＩＡＢノード３００の例を表している。最初に、ソースドナーノード２００－１は、ＩＡＢノード３００に対してＦ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージの送信を指示する。次に、ＩＡＢノード３００は、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージをカプセル化した第３メッセージをソースドナーノード２００－１へ送信する。Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージには、ＩＡＢノード３００で使用可能なセルＩＤが含まれる。次に、ソースドナーノード２００－１は、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージをカプセル化したＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージをターゲットドナーノード２００－２へ送信する。次に、ターゲットドナーノード２００－２は、Ｈａｎｄｏｖｅｒ ＲｅｑｕｅｓｔメッセージからＩＡＢノード３００において使用可能なセルＩＤを取り出し、当該セルＩＤのうち、ターゲットドナーノード２００－２において使用可能なセルＩＤと衝突しないセルＩＤを決定する。そして、ターゲットドナーノード２００－２は、決定したセルＩＤを含むＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージをカプセル化したＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージをソースドナーノード２００－１へ送信する。次に、ソースドナーノード２００－１は、決定したセルＩＤを含むＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージをカプセル化したＨａｎｄｏｖｅｒ ＣｏｍｍａｎｄメッセージをＩＡＢノード３００へ送信する。そして、ＩＡＢノード３００は、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージに含まれるセルＩＤを用いて、ターゲットドナーノード２００－２へ移動処理を実行する。

このように、第３変形例においても、ＩＡＢノード３００は、自局で使用可能なセルＩＤのうち、ターゲットドナーノード２００－２において使用可能なセルＩＤと衝突しないセルＩＤを、ターゲットドナーノード２００－２から受信する。そのため、ＩＡＢノード３００は、ターゲットドナーノード２００－２へハンドオーバする場合であっても、ＰＣＩ Ｃｏｌｌｉｓｉｏｎを抑制することができる。

図１４は、第１実施形態の第３変形例に係る動作例を表す図である。事前設定などは、第１実施形態と同様である。図１４に示す例では、Ｘｎハンドオーバの例を表している。

図１４に示すように、ソースドナーノード２００－１は、配下のＩＡＢノード３００をソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバさせることを決定する。

ステップＳ４１において、ソースドナーノード２００－１は、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージの送信を、ＩＡＢノード３００へ指示する。具体的には、ソースドナーノード２００－１のＣＵは、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｉｒｅｄメッセージを、ＩＡＢノード３００のＩＡＢ－ＭＴへ送信する。Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｉｒｅｄメッセージは、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージの送信を指示することを示す新規のＲＲＣメッセージである。

なお、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｉｒｅｄメッセージは、Ｆ１ＡＰプロトコルのメッセージであってもよい。この場合、ソースドナーノード２００－１のＣＵは、当該メッセージを、ＩＡＢノード３００のＩＡＢ－ＤＵへ送信する。

ステップＳ４２において、ＩＡＢノード３００のＩＡＢ－ＭＴは、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｉｒｅｄメッセージの受信に応じて、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを、ソースドナーノード２００－１のＣＵへ送信する。Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージは、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｉｒｅｄメッセージに対する応答メッセージであって、新規なＲＲＣメッセージである。この場合、ＩＡＢノード３００のＩＡＢ－ＭＴは、当該メッセージに含まれるＦ１ＡＰコンテナに、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージをカプセル化して、当該メッセージを送信する。図１５（Ａ）は、当該メッセージに含まれるＦ１ＡＰコンテナの例を表している。Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージには、ＩＡＢノード３００において使用可能なセルＩＤが含まれる。なお、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージは、Ｆ１ＡＰプロトコルメッセージでもよい。

図１４に戻り、なお、Ｆ１ Ｓｅｔｕｐ ＲｅｑｕｉｒｅｄメッセージがＲＲＣのメッセージの場合、ＩＡＢノード３００のＩＡＢ－ＭＴは、ＩＡＢノード３００のＩＡＢ－ＤＵに対して取得指示を通知し、ＩＡＢ－ＤＵからＦ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージを取得するようにしてもよい。

ステップＳ４３において、ソースドナーノード２００－１は、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージの受信に応じて、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージをターゲットドナーノード２００－２へ送信する。この際、ソースドナーノード２００－１は、Ｆ１ Ｓｅｔｕｐ ＲｅｓｐｏｎｓｅメッセージのＦ１ＡＰコンテナから、カプセル化されたＦ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージを取り出し、Ｈａｎｄｏｖｅｒ ＲｅｑｕｅｓｔメッセージのＦ１ＡＰコンテナに挿入する。図１５（Ｂ）は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージ（Ｘｎメッセージ）に含まれるＦ１ＡＰコンテナの例を表している。

図１４に戻り、ステップＳ４４において、ターゲットドナーノード２００－２は、Ｈａｎｄｏｖｅｒ ＲｅｑｕｅｓｔメッセージのＦ１ＡＰコンテナから、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージを取り出し、自局に対するＦ１ Ｓｅｔｕｐを行う。また、ターゲットドナーノード２００－２は、Ｆ１ Ｓｅｔｕｐ ＲｅｑｕｅｓｔメッセージからＩＡＢノード３００で使用可能なセルＩＤを取り出し、当該セルＩＤのうち、ターゲットドナーノード２００－２において使用可能なセルＩＤと衝突しないセルＩＤを決定する。

ステップＳ４５において、ターゲットドナーノード２００－２は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージをソースドナーノード２００－１へ送信する。この際、ターゲットドナーノード２００－２は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージ（Ｘｎメッセージ）に含まれるＦ１コンテナに、決定したセルＩＤを含むＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージをカプセル化して送信する。当該使用可能なセルＩＤは、セルＩＤのリストでもよい。当該使用可能なセルＩＤには、それぞれのセルＩＤがアクティブ化されているか非アクティブ化されているかの情報が含まれていてもよい。もしくは、当該使用可能なセルＩＤは、使用禁止のセルＩＤとして通知されてもよい。

ステップＳ４６において、ソースドナーノード２００－１は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージの受信に応じて、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ ＡｃｋｎｏｗｌｅｄｇｅメッセージのＦ１コンテナから、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを取り出す。そして、ソースドナーノード２００－１は、取り出したＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージのＦ１コンテナに、カプセル化する。ソースドナーノード２００－１のＣＵは、カプセル化したＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージを、ＩＡＢノード３００のＩＡＢ－ＭＴへ送信する。

ステップＳ４７において、ＩＡＢノード３００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージからＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを取り出し、更に、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージから、ターゲットドナーノード２００－２で決定したセルＩＤを取り出す。そして、ＩＡＢノード３００は、取り出したセルＩＤをアクティブ化する。ＩＡＢノード３００は、セルＩＤのアクティブ化と連動して、ターゲットドナーノード２００－２に対して移動処理（具体的には、接続処理）を実行する。

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

第１実施形態で説明したように、ＩＡＢノード３００のｍｉｇｒａｔｉｏｎにより、ＩＡＢノード３００において使用するセルＩＤが変更される場合がある。当該ＩＡＢノード３００を親ノードに持つ子ノード３００－Ｃ及び／又はＵＥ１００は、親ノード（ＩＡＢノード３００）における変更後のセルＩＤを知ることはできない。一方、子ノード３００－Ｃ及び／又はＵＥ１００は、変更後のセルＩＤを使用する場合、当該セルＩＤに対してセル再選択処理、又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ（ＲＲＣ接続再設定）処理を行う。しかし、ＩＡＢノード３００の全ての子ノード３００－Ｃ及び／又はＵＥ１００が、一斉に、ＲＲＣ接続再設定処理を開始すると、ＲＡＣＨのプリアンブル衝突が発生したり、リソース全体が逼迫したりする場合がある。このため、ＵＥ１００に提供中のサービスが瞬断する場合がある。

そこで、第２実施形態は、子ノード３００－Ｃ及び／又はＵＥ１００に対して、親ノードのセルＩＤ変更に伴う処理を抑制することを目的としている。

そのため、第２実施形態では、中継ノード（例えば、ＩＡＢノード３００－Ｐ）は、現在使用するセルが使用できなくなることを検知する。そして、中継ノードは、使用できなくなるセルのセルＩＤを、中継ノードの子ノード（例えば、子ノード３００－Ｃ）及び／又はユーザ装置（例えば、ＵＥ１００）へ送信する。

これにより、例えば、子ノード３００－Ｃ及び／又はＵＥ１００は、使用できなくなるセルのセルＩＤを受信しても、少なくとも、セル再選択処理、ＲＲＣ接続再設定処理、及びＲＬＦ（Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）処理を行わないようにすることで、セルＩＤ変更に伴う処理を抑制させることができる。

図１６は、第２実施形態に係る動作例を表す図である。図１６は、ドナーノード２００の配下にＩＡＢノード３００－Ｐが存在する例を表している。また、図１６は、ＩＡＢノード３００－Ｐの子ノードとしてＩＡＢノード３００－Ｃが存在する、及び／又は、ＩＡＢノード３００－Ｐとアクセスリンクで接続されたＵＥ１００が存在する例を表している。

ステップＳ５０において、ＩＡＢノード３００－Ｐは、ドナーノード２００から、変更後のセルＩＤを含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージを受信してもよい。ステップＳ５０は、第１実施形態のステップＳ１４（図１１）、第１実施形態の第１変形例のステップＳ２６（図１２）、第１実施形態の第２変形例のステップＳ３４（図１３）、又は第１実施形態の第３変形例のステップＳ４６（図１４）等であってもよい。変更後のセルＩＤに代えて、使用可能なセルＩＤ、使用不可能なセルＩＤ、アクティブ化するセルＩＤ、又は非アクティブ化するセルＩＤであってもよい。ドナーノード２００に代えて、ＩＡＢノード３００－Ｐの親ノード又は上位ノードであってもよい。

ステップＳ５１において、ＩＡＢノード３００－Ｐは、現在使用中のセルが使用できなくなることを検知する。ＩＡＢノード３００－Ｐは、現在使用中のセルが非アクティブ化される（又は使用不可能となる）ことをドナーノード２００から通知（例えば、ステップＳ５０）を受けて、現在使用中のセルが使用できなくなることを検知してもよい。又は、ＩＡＢノード３００－Ｐは、ステップＳ５０により、変更後のセルＩＤの通知を受けて、現在使用中のセルが使用できなくなることを検知してもよい。なお、ＩＡＢノード３００－Ｐは、現在使用中のセルが継続して使用できる場合は、当該セルのセルＩＤを使用し続けることになる。以降の処理は、現在使用中のセルが使用できなくなった場合を想定している。

ステップＳ５２において、ＩＡＢノード３００－Ｐは、継続して使用することができなくなるセルのセルＩＤを、子ノード３００－Ｃ及び／又はＵＥ１００へ送信する。

この場合、ＩＡＢノード３００－Ｐは、当該セルＩＤを含むＳＩＢ１を報知することで当該送信が行われてもよい。また、ＩＡＢノード３００－Ｐは、当該セルＩＤを含むＲＲＣメッセージ又はＦ１ＡＰメッセージなどを送信することで当該送信が行われてもよい。

通知する内容も、継続して使用することができなくなるセルのセルＩＤに代えて、当該セルが使用できなくなることを表す情報、当該セルのセルＩＤが変更されることを表す情報、又はタイミング情報が含まれてもよい。当該セルのセルＩＤが変更されることを表す情報には、変更後のセルＩＤが含まれてもよい。変更後のセルＩＤそのものが、当該セルのセルＩＤが変更されることを表す情報そのものであってもよい。また、タイミング情報は、非アクティブになるタイミングを表す情報、又はセルＩＤが変更になるタイミングを表す情報であってもよい。タイミング自体は、ＳＦＮ（Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）及び／又は時間（１秒等）で表されてもよい。

ステップＳ５３において、子ノード３００－Ｃ及び／又はＵＥ１００は、当該セルＩＤを受信したことに応じて、現在使用中のセルのセルＩＤが変更されても、所定処理を行わないようにする。所定処理は、少なくとも、ＲＬＦ検知、セル再選択処理、及びＲＲＣ接続再設定処理のいずれかひとつ以上を含む。子ノード３００－Ｃ及び／又はＵＥ１００が、所定処理を行わないことで、セルＩＤ変更に伴う処理を抑制できる。この場合、子ノード３００－Ｃ及び／又はＵＥ１００は、ソフトハンドオーバーとして、セルＩＤの変更を認識し、当該セルに対する設定処理などをそのまま継続して使用してもよい。

なお、ステップＳ５３において、子ノード３００－Ｃ及び／又はＵＥ１００は、セルＩＤ変更後、ＲＲＣ接続再設定処理を行ってもよい。ただし、セルＩＤ変更に伴う処理を抑制するため、子ノード３００－Ｃ及び／又はＵＥ１００は、新セルＩＤに対して、ＲＡＣＨ－ｌｅｓｓハンドオーバを行ってもよい。

また、ステップＳ５３は、子ノード３００－Ｃ及び／又はＵＥ１００が、ＩＡＢノード３００－Ｐに対して、ＲＲＣコネクティッド状態であることを前提とした動作を説明した。例えば、子ノード３００－Ｃ及び／又はＵＥ１００は、アイドル状態の場合又はインアクティブ状態の場合、新セルＩＤに対するセル再選択処理を行うことになる。そのため、図１６に示す動作例は、子ノード３００－Ｃ及び／又はＵＥ１００が、アイドル状態の場合又はインアクティブ状態であることを前提としてもよい。

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

第２実施形態では、ＩＡＢノード３００－Ｐにおいて現在使用中のセルのセルＩＤが使用できなくなることを、子ノード３００－Ｃ及び／又はＵＥ１００へ通知する例について説明した。この場合、子ノード３００－Ｃ及び／又はＵＥ１００は、そのような通知を受けて、すぐに、ハンドオーバ処理を行うと、自局においてセルＩＤの変更を完了する前に、ハンドオーバ処理を開始してしまう場合もある。とくに、第１実施形態で説明したＨＯ Ｃｏｍｍａｎｄを受信したＩＡＢノード３００は、時間的余裕もなく、セルＩＤを変更する前に、ハンドオーバ処理を行う場合もある。

そこで、第３実施形態では、時間をトリガ条件に含む条件付きハンドオーバを用いて、ＩＡＢノード３００がハンドオーバする例について説明する。このような条件付きハンドオーバを、Ｔｉｍｅ－ｔｒｉｇｇｅｒｅｄ ＣＨＯ（Ｃｏｎｄｉｔｉｏｎａｌ Ｈａｎｄｏｖｅｒ）と称する場合がある。

具体的には、ソースドナーノード２００－１は、時間をトリガ条件に含む条件付きハンドオーバをターゲットドナーノード２００－２へ要求する要求メッセージを送信する。次に、ターゲットドナーノード２００－２は、要求メッセージを受信したことに応じて、要求を受け入れる受け入れメッセージをソースドナーノード２００－１へ送信する。そして、ソースドナーノード２００－１は、受け入れメッセージを受信したことに応じて、時間をトリガ条件に含む条件付きハンドオーバを実行するよう中継ノード（例えば、ＩＡＢノード３００）を設定する。

これにより、例えば、ＩＡＢノード３００は、ソースドナーノード２００－１から、セルＩＤ変更の通知（図１６のステップＳ５２）を受けても、当該時間経過後に、ハンドオーバ処理を実行することができる。そのため、ＩＡＢノード３００は、例えば、セルＩＤを変更した後で、ハンドオーバ処理を実行でき、ハンドオーバ処理を適切に行うことが可能となる。

ここで、条件付きハンドオーバについて説明する。

（条件付きハンドオーバ）
条件付きハンドオーバは、１つ以上のハンドオーバ実行条件（又はトリガ条件）が満たされたときに実行されるハンドオーバである。条件付きハンドオーバの設定は、ハンドオーバの候補セル及びハンドオーバのトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件の複数の組み合わせを複数含んでもよい。

トリガ条件は、例えば、イベントＡ３と呼ばれるイベント及びイベントＡ５と呼ばれるイベントのうち少なくとも一方が指定される。イベントＡ３は、隣接セルの無線状態がサービングセルの無線状態よりも所定量（所定オフセット）以上に良好であるというイベントである。イベントＡ５は、サービングセルの無線状態が第１閾値よりも劣化し、且つ、隣接セルの無線状態が第２閾値よりも良好であるというイベントである。

第３実施形態では、上述したように、条件付きハンドオーバのトリガ条件に、時間（又は時間余裕。以下では、「時間余裕」と称する場合がある。）を含めるようにしている。

（第３実施形態の動作例）
図１７は、第３実施形態に係る動作例を表す図である。図１７は、ＩＡＢノード３００が、ソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバする場合の例を表している。

図１７に示すように、ステップＳ６０において、ＩＡＢノード３００は、時間余裕の必要量をソースドナーノード２００－１へ通知してもよい。例えば、ＩＡＢノード３００は、ＲＲＣメッセージ又はＦ１ＡＰメッセージなどに、時間余裕の必要量を含めて送信してもよい。

時間余裕の必要量とは、例えば、ＩＡＢノード３００が、時間をトリガ条件に含む条件付きハンドオーバを実行する際に要求する時間のことである。時間余裕の必要量は、ＳＦＮ及び／又は時間単位（１秒など）で表されてよい。

ステップＳ６１において、ソースドナーノード２００－１は、ＩＡＢノード３００をソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバさせることを決定する。

ステップＳ６２において、ソースドナーノード２００－１は、時間をトリガ条件に含む条件付きハンドオーバを要求する。ソースドナーノード２００－１は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージを利用して、当該要求を送信してもよい。Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージが、当該条件付きハンドオーバをターゲットドナーノード２００－２へ要求する要求メッセージであってもよい。ソースドナーノード２００－１は、時間余裕の必要量を、当該要求とともに送信してもよい。ＩＡＢノード３００の時間余裕の必要量は、予めソースドナーノード２００－１が保持してもよい。ＩＡＢノード３００の時間余裕の必要量は、ステップＳ６０のようにＩＡＢノード３００から受信してもよい。

ステップＳ６３において、ターゲットドナーノード２００－２は、当該条件付きハンドオーバの要求を受信したことに応じて、当該条件付きハンドオーバの受け入れを決定する。ターゲットドナーノード２００－２は、当該要求に時間余裕の必要量が含まれている場合は、当該必要量に対して、時間余裕の量を決定してもよい。なお、当該要求に時間余裕の必要量が含まれていない場合は、ソースドナーノード２００－１において、時間余裕の必要量に対して、時間余裕の量を決定してもよい。

なお、時間余裕の量は、例えば、時間余裕の必要量に対して、当該条件付きハンドオーバにおいて実際に用いられる時間のことである。時間余裕の量も、例えば、ＳＦＮで表されても良いし、時間単位で表されてもよい。

ステップＳ６４において、ターゲットドナーノード２００－２は、当該条件付きハンドオーバの受け入れをソースドナーノード２００－１へ送信する。ターゲットドナーノード２００－２は、当該条件付きハンドオーバの受け入れを、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージを利用して送信してもよい。当該Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージが、当該要求を受け入れる受け入れメッセージであってもよい。なお、ターゲットドナーノード２００－２は、時間余裕の量を決定した場合は、決定した時間余裕の量を、当該Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージに含めて送信する。また、当該Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージには、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ設定が含まれる。

ステップＳ６５において、ソースドナーノード２００－１は、当該条件付きハンドオーバの受け入れを受信したことに応じて、ＩＡＢノード３００に対して、当該条件付きハンドオーバを設定する。例えば、ソースドナーノード２００－１は、ＲＲＣ ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＩＡＢノード３００へ送信することで設定が行われる。ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、ソースドナーノード２００－１又はターゲットドナーノード２００－２で決定した時間余裕の量が含まれる。また、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、ステップＳ６４で受信したＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ設定が含まれる。

ＩＡＢノード３００では、当該条件付きハンドオーバに用いられるトリガ条件として、時間余裕の量が設定される。ここで、時間余裕の量は、２つの意味がある。

第１に、ＩＡＢノード３００は、所定時間から、当該時間余裕の量が経過した後、条件付きハンドオーバのトリガ条件（例えば、イベントＡ３等）を評価する場合である。この場合、時間余裕の量が、トリガ条件の監視を開始する前の時間余裕を表している。例えば、ＩＡＢノード３００は、所定時間から１秒（時間余裕の量）経過後、条件付きハンドオーバの他のトリガ条件（例えば、イベントＡ３）の監視を開始し、当該他のトリガ条件を満たすと、ターゲットドナーノード２００－２へのアクセスを開始する。

第２に、当該時間余裕の量が経過した後に、ハンドオーバが実行される場合である。この場合、時間余裕の量がトリガ条件となっている。例えば、ＩＡＢノード３００は、所定時間から１秒（時間余裕の量）経過後、ターゲットドナーノード２００－２へのアクセスを開始する。

なお、ＩＡＢノード３００は、当該時間をトリガ条件に含む条件付きハンドオーバが設定された際、当該時間経過中（例えば対応するタイマの動作中）は、他の条件（例えば無線状況の変化）に従った条件付きハンドオーバの評価を停止してもよい。これにより、時間余裕の間に、意図せず別のセルへアクセスする（別の条件付きハンドオーバを実行する）ことを防止することができる。

なお、所定時間は、ＩＡＢノード３００が、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ（ステップＳ６５）を受信した時間でもよい。所定時間は、ドナーノード２００－１，２００－２から設定された時間でもよい。

ステップＳ６６において、ＩＡＢノード３００は、当該条件付きハンドオーバを実行する。

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

第４実施形態は、ＩＡＢノード３００が、子ノード３００－Ｃ及び／又はＵＥ１００へ、現在使用しているセルのセルＩＤと、新たなセルＩＤとを報知する例である。

具体的には、中継ノード（例えば、ＩＡＢノード３００）は、現在使用するセルＩＤを示す第１セルＩＤと、変更後のセルＩＤを示す第２セルＩＤとを報知する。次に、中継ノードは、第１セルＩＤのセルにアクセスする中継ノードの子ノード（例えば、子ノード３００－Ｃ）及び／又はユーザ装置（例えば、ＵＥ１００）を、第２セルＩＤのセルへハンドオーバさせる。そして、中継ノードは、子ノード及び／又はユーザ装置をハンドオーバさせた後、第１セルＩＤの報知を停止する。

これにより、子ノード３００－Ｃ及び／又はＵＥ１００は、現在使用しているセルＩＤと、変更後の新セルＩＤとを把握して、その後、適切にハンドオーバ処理を行うことが可能となる。

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

図１８に示すように、ステップＳ７０において、ＩＡＢノード３００－Ｐは、ｍｉｇｒａｔｉｏｎする際に、ドナーノード２００から、変更後のセルＩＤを受信してもよい。変更後のセルＩＤに代えて、使用可能なセルＩＤ、使用不可能なセルＩＤ、アクティブ化するセルＩＤ、又は非アクティブ化するセルＩＤであってもよい。ステップＳ７０は、第１実施形態のステップＳ１４（図１１）、第１実施形態の第１変形例のステップＳ２６（図１２）、第１実施形態の第２変形例のステップＳ３４（図１３）、又は第１実施形態の第３変形例のステップＳ４６（図１４）などであってもよい。

ステップＳ７１において、ＩＡＢノード３００－Ｐは、現在使用しているセルのセルＩＤと並行して、新たなセルのセルＩＤを報知する。新たなセルのセルＩＤとは、例えば、ＩＡＢノード３００－Ｐのハンドオーバにより、新たにアクセスするセルのセルＩＤのことである。新たなセルのセルＩＤは、現在ＩＡＢノード３００－Ｐが使用するセルＩＤとは異なる変更後のセルＩＤでもよい。

ステップＳ７２において、ＩＡＢノード３００－Ｐは、ＰＳＳとＳＳＳとを報知することで、現在使用しているＰＣＩと、新たなＰＣＩとを報知してもよい。

ステップＳ７３において、ＩＡＢノード３００－Ｐは、ＳＩＢ１を用いて、現在使用しているＣｅｌｌ ＩＤと、新たなＣｅｌｌ ＩＤとを報知してもよい。

ステップＳ７４において、ＩＡＢノード３００－Ｐは、現在使用しているセルから新たなセルへ、子ノード３００－Ｃ及び／又はＵＥ１００をハンドオーバさせる。この際、ＩＡＢノード３００－Ｐは、ＲＡＣＨ－ｌｅｓｓハンドオーバを設定するようにしてもよい。又は、ＩＡＢノード３００－Ｐは、第２実施形態で説明したソフトハンドオーバ（図１６のステップＳ５３）を設定するようにしてもよい。

ステップＳ７５において、ＩＡＢノード３００－Ｐは、配下の全ての子ノード３００－Ｃ及び／又はＵＥ１００を新セルへハンドオーバさせた後、現在使用しているセルのセルＩＤの報知を停止する。例えば、ＩＡＢノード３００－Ｐは、配下の全ての子ノード３００－Ｃ及び／又はＵＥ１００からハンドオーバ完了メッセージを受信すると、現在使用しているセルのセルＩＤの報知を停止する。

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

第１実施形態では、ＩＡＢノード３００がｍｉｇｒａｔｉｏｎすることで、ＰＣＩ Ｃｏｌｌｉｓｉｏｎが発生する場合について説明した。第５実施形態では、ＩＡＢノード３００がｍｉｇｒａｔｉｏｎすることで、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）のリソースが衝突する場合の例について説明する。

図１９は、第５実施形態に係るＰＲＡＣＨリソースの衝突例を表す図である。図１９は、ＩＡＢノード３００が、ソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバする場合の例を表している。

ＩＡＢノード３００がハンドオーバする前は、ドナーノード２００－１と近接した位置に位置する。ＩＡＢノード３００－２のＰＲＡＣＨリソースＲ２と、ＩＡＢノード３００－１のＰＲＡＣＨリソースＲ１とは、衝突しないリソース配置となっている。このため、ドナーノード２００－１とＩＡＢノード３００との間に位置するＵＥ１００は、ドナーノード２００－１に対してランダムアクセス手順を実行して、ドナーノード２００－１と接続することができる。また、当該ＵＥ１００は、ＩＡＢノード３００に対してランダムアクセス手順を実行して、ＩＡＢノード３００に接続することも可能となる。

他方、ＩＡＢノード３００がハンドオーバすると、ＩＡＢノード３００は、ドナーノード２００－２に近接した位置に移動する。ＩＡＢノード３００のＰＲＡＣＨリソースＲ２と、ドナーノード２００－２のＰＲＡＣＨリソースＲ３とは、そのリソース範囲が重複する。このため、ＵＥ１００は、ＰＲＡＣＨリソースＲ２を用いて、ＲＡＣＨプリアンブル（ｍｅｓｓａｇｅ１）を送信しても、ＩＡＢノード３００は、干渉によって、ＲＡＣＨプリアンブルを受信することができない場合がある。仮に、ＩＡＢノード３００とドナーノード２００－２が、ともに、ＵＥ１００から送信されたＲＡＣＨプリアンブルを受信した場合、ＩＡＢノード３００及びドナーノード２００－２は、双方ともＲＡＣＨレスポンス（ｍｅｓｓａｇｅ２）をＵＥ１００へ送信する。ＵＥ１００は、ＲＡＣＨレスポンスを双方から受信するため不定状態になる。そのため、ＵＥ１００は、ＩＡＢノード３００へのランダムアクセス手順を失敗し、ＩＡＢノード３００へ接続できなくなる。

これに対して、第５実施形態では、最初に、第１通信ノード（例えば、ソースドナーノード２００－１）が、第１通信ノードに隣接する隣接ノードから受信した隣接ノードのＰＲＡＣＨ設定に基づいて、当該隣接ノードのＰＲＡＣＨ設定と衝突しないＰＲＡＣＨ設定を決定する。次に、第１通信ノードが、決定したＰＲＡＣＨ設定を中継ノード（例えば、ＩＡＢノード３００）へ送信する。そして、ソースドナーノード２００－１は、ターゲットドナーノード２００－２との間でハンドオーバ処理を実行し、中継ノードは、決定したＰＲＡＣＨ設定を、ターゲットドナーノード２００－２に対して適用する。

例えば、図１９の例では、ソースドナーノード２００－１は、隣接ノードのＰＲＡＣＨ設定として、ターゲットドナーノード２００－２のＰＲＡＣＨ設定（例えば、ＰＲＡＣＨリソースＲ３）を受信する。ソースドナーノード２００－１は、自局のＰＲＡＣＨ設定（例えば、ＰＲＡＣＨリソースＲ１）と、ターゲットドナーノード２００－２のＰＲＡＣＨ設定（例えば、ＰＲＡＣＨリソースＲ３）とで重複しないＰＲＡＣＨ設定（例えば、ＰＲＡＣＨリソースＲ４）を決定する。そして、ソースドナーノード２００－１は、当該ＰＲＡＣＨ設定を、ＩＡＢノード３００へ送信する。

ＩＡＢノード３００は、ターゲットドナーノード２００－２に対して、当該ＰＲＡＣＨ設定を適用しても、ＰＲＡＣＨリソースはいずれとも重複しないため、ターゲットドナーノード２００－２へ適切にアクセスすることができる。従って、ソースドナーノード２００－１は、ＰＲＡＣＨリソースの重複を抑制するように当該リソースを制御することができる。

なお、図１９の例において、ソースドナーノード２００－１が当該ＰＲＡＣＨ設定を決定する例を説明したが、ターゲットドナーノード２００－２が当該ＰＲＡＣＨ設定を決定してもよい。後者は、第５実施形態の第１変形例で説明する。

（ＰＲＡＣＨ設定の通知）
ここで、ＰＲＡＣＨ設定（ＰＲＡＣＨ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）の通知の例について説明する。ＰＲＡＣＨ設定は、セルにおけるＰＲＡＣＨリソースを示している。ＰＲＡＣＨ設定は、具体的には、リソースの開始周波数、サブキャリアスペーシング（ＳＣＳ）、周波数ドメイン長などが含まれる。

ｇＮＢ－ＤＵは、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージに、各セルのＰＲＡＣＨ設定を含めて、ｇＮＢ－ＣＵへ送信することができる。また、ｇＮＢ－ＤＵは、ｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージに、各セルのＰＲＡＣＨ設定を含めて、ｇＮＢ－ＣＵへ送信することができる。

更に、ｇＮＢ－ＣＵは、ＲＡＣＨ Ｏｐｔｉｍｉｚａｔｉｏｎのために、他のｇＮＢのＣＵへ、ＰＲＡＣＨ設定を通知することも可能である。これにより、ソースドナーノード２００－１は、ターゲットドナーノード２００－２のＰＲＡＣＨ設定を、ターゲットドナーノード２００－２から受信できる。また、ターゲットドナーノード２００－２も、ソースドナーノード２００－１のＰＲＡＣＨ設定を、ソースドナーノード２００－１から受信できる。

（第５実施形態の動作例）
次に、第５実施形態の動作例を説明する。図２０は、第５実施形態に係る動作例を表す図である。ただし、図２０に示す動作例が行われる前に、ソースドナーノード２００－１は、隣接ドナーノードのＰＲＡＣＨ設定として、ターゲットドナーノード２００－２のＰＲＡＣＨ設定を受信しているものとする。

なお、以下の動作例では、ドナーノード２００－１，２００－２間でＩＡＢノード３００がハンドオーバする例について説明する。ただし、第１実施形態と同様に、それ以外の例が適用されてもよい。すなわち、親ノード３００－Ｐ１，３００－Ｐ２間でＩＡＢノード３００がハンドオーバする場合でもよい。上位ノード間でＩＡＢノード３００がハンドオーバする場合でもよい。また、ｇＮＢ－ＣＵ間でＩＡＢノード３００がハンドオーバする場合でもよい。いずれの場合も、各メッセージが、親ノード３００－Ｐ１，３００－Ｐ２間、上位ノード間、ｇＮＢ－ＣＵ間、ＩＡＢノード３００と親ノード間、ＩＡＢノード３００と上位ノード間、ＩＡＢノード３００のＤＵとｇＮＢ－ＣＵ間で交換されてもよい。

図２０に示すように、ステップＳ８０において、ソースドナーノード２００－１は、ＩＡＢノード３００がソースドナーノード２００－１からターゲットドナーノード２００－２へハンドオーバすることを決定する。

ステップＳ８１において、ソースドナーノード２００－１は、隣接ドナーノードのＰＲＡＣＨ設定に基づいて、ＩＡＢノード３００のＰＲＡＣＨ設定を決定する。具体的には、ソースドナーノード２００－１は、ターゲットドナーノード２００－２のＰＲＡＣＨ設定と、自ソースドナーノード２００－１のＰＲＡＣＨ設定とが衝突しないＰＲＡＣＨ設定を決定する。

ステップＳ８２において、ソースドナーノード２００－１は、決定したＰＲＡＣＨ設定をＩＡＢノード３００へ送信する。ソースドナーノード２００－１は、当該ＰＲＡＣＨ設定を含むＲＲＣメッセージ及び／又は当該ＰＲＡＣＨ設定を含むＦ１ＡＰメッセージを送信してもよい。この場合、ソースドナーノード２００－１は、当該ＰＲＡＣＨ設定をハンドオーバ後に適用する旨の識別子を当該メッセージに含めて送信してもよい。ＩＡＢノード３００では、決定したＰＲＡＣＨ設定を受信しても、ターゲットドナーノード２００－２へのハンドオーバが完了するまで、当該ＰＲＡＣＨ設定の適用を保留してもよい。もしくは、ＩＡＢノード３００では、ＰＲＡＣＨ設定を受信すると即座に当該ＰＲＡＣＨ設定を適用してもよい。

ステップＳ８３において、ソースドナーノード２００－１は、ターゲットドナーノード２００－２との間で、Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ手順を実行する。

ステップＳ８４において、ソースドナーノード２００－１は、Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ手順を終了すると、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージをＩＡＢノード３００へ送信する。

ステップＳ８５において、ＩＡＢノード３００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージの受信に応じて、ステップＳ８２で受信したＰＲＡＣＨ設定を適用する。ＩＡＢノード３００は、例えば、当該メッセージ受信時、ターゲットドナーノード２００－２へのアクセス開始時、又は、当該アクセス完了時に、当該ＰＲＡＣＨ設定を適用してもよい。

（第５実施形態の第１変形例）
次に、第５実施形態の第１変形例について説明する。

第５実施形態では、ソースドナーノード２００－１が、リソース衝突が発生しないＰＲＡＣＨ設定を決定する例を説明した。第５実施形態の第１変形例は、ターゲットドナーノード２００－２が、リソース衝突が発生しないＰＲＡＣＨ設定を決定する例である。

具体的には、第１通信ノード（例えば、ターゲットドナーノード２００－２）が、第１通信ノードに隣接する隣接ノードから受信した隣接セルのＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）設定に基づいて、当該隣接セルのＰＲＡＣＨ設定と衝突しないＰＲＡＣＨ設定を決定する。そして、第１通信ノードが、決定したＰＲＡＣＨ設定を中継ノード（例えば、ＩＡＢノード３００）へ送信する。

第５実施形態の第１変形例も、第５実施形態と同様に、ＩＡＢノード３００は、当該ＰＲＡＣＨ設定を適用して、ターゲットドナーノード２００－２にアクセスしても、ＰＲＡＣＨ設定が重複しないため、適切にアクセスすることができる。従って、第５実施形態の第１変形例も、ターゲットドナーノード２００－２は、ＰＲＡＣＨリソースの重複を抑制するように当該リソースを制御することができる。

図２１は、第５実施形態の第１変形例に係る動作例を表す図である。ただし、図２１に示す動作例が行われる前に、ターゲットドナーノード２００－２は、隣接ドナーノードのＰＲＡＣＨ設定として、ソースドナーノード２００－１のＰＲＡＣＨ設定を受信しているものとする。

図２１に示すように、ステップＳ９０において、ソースドナーノード２００－１は、ＩＡＢノード３００がハンドオーバを行うことを決定する。

ステップＳ９１において、ソースドナーノード２００－１は、ターゲットドナーノード２００－２へ、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージを送信する。この場合、ソースドナーノード２００－１は、ＩＡＢノード３００のＰＲＡＣＨ設定をＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔメッセージに含めて送信してもよい。ターゲットドナーノード２００－２が、隣接ドナーノードのＰＲＡＣＨ設定として、ソースドナーノード２００－１のＰＲＡＣＨ設定を事前に受信していない場合も考えられるからである。

ステップＳ９２において、ターゲットドナーノード２００－２は、隣接セルのＰＲＡＣＨ設定に基づいて、ＩＡＢノード３００のＰＲＡＣＨ設定を決定する。具体的には、ターゲットドナーノード２００－２は、ソースドナーノード２００－１のＰＲＡＣＨ設定と、自ターゲットドナーノード２００－２のＰＲＡＣＨ設定とが衝突しないＰＲＡＣＨ設定を決定する。

ステップＳ９３において、ターゲットドナーノード２００－２は、決定したＰＲＡＣＨ設定を含むＨａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージをソースドナーノード２００－１へ送信する。

ステップＳ９４において、ソースドナーノード２００－１は、Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅメッセージを受信したことに応じて、決定したＰＲＡＣＨ設定を含む、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージを、ＩＡＢノード３００へ送信する。

ステップＳ９５において、ＩＡＢノード３００は、ターゲットドナーノード２００－２で決定したＰＲＡＣＨ設定を適用する。ＩＡＢノード３００は、第５実施形態と同様に、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）メッセージ受信時、ターゲットドナーノード２００－２へのアクセス開始時、又は、当該アクセス完了時に、当該ＰＲＡＣＨ設定を適用してもよい。

（第５実施形態の第２変形例）
次に、第５実施形態の第２変形例を説明する。

第５実施形態と、第５実施形態の第１変形例では、ＩＡＢノード３００がハンドオーバする際の例について説明した。第５実施形態の第２変形例では、ハンドオーバではなく、ＩＡＢノード３００の電源オン後の例について説明する。

具体的には、最初に、中継ノード（例えば、ＩＡＢノード３００）が、電源をオンにする。次に、中継ノードは、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージをドナーノード（例えば、ドナーノード２００）へ送信する。次に、ドナーノードは、隣接ドナーノードのＰＲＡＣＨ設定と、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔに含まれる中継ノードのＰＲＡＣＨ設定とに基づいて、隣接セルのＰＲＡＣＨ設定と衝突しないＰＲＡＣＨ設定を決定する。そして、ドナーノードは、決定したＰＲＡＣＨ設定を含むＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージを中継ノードへ送信する。

ＩＡＢノード３００は、ドナーノード２００において隣接ドナーノードと衝突しないＰＲＡＣＨ設定を、ドナーノード２００から受信するため、当該ＰＲＡＣＨ設定を用いて、ドナーノード２００にランダムアクセス手順を適切に行うことが可能となる。従って、第５実施形態の第２変形例も、ターゲットドナーノード２００－２は、ＰＲＡＣＨリソースの重複を抑制するように当該リソースを制御することができる。

図２２は、第５実施形態の第２変形例に係る動作例を表す図である。ただし、図２２に示す動作例も、事前設定として、ドナーノード２００は、隣接ドナーノードのＰＲＡＣＨ設定を受信しているものとする。

図２２に示すように、ステップＳ１００において、ＩＡＢノード３００は、電源をオンにする。電源オンに代えて、ＩＡＢノード３００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＨＯ Ｃｏｍｍａｎｄ）を受信して、ドナーノード２００とＲＲＣ接続を確立してもよい。

ステップＳ１０１において、ＩＡＢノード３００は、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージをドナーノード２００へ送信する。当該メッセージには、ＩＡＢノード３００のＰＲＡＣＨ設定が含まれる。Ｍｏｂｉｌｅ ＩＡＢの場合、当該メッセージには、ＰＲＡＣＨ設定を必ず含めるようにしてもよい。

ステップＳ１０２において、ドナーノード２００は、隣接ドナーノードのＰＲＡＣＨ設定に基づいて、ＩＡＢノード３００のＰＲＡＣＨ設定を確認する。具体的には、ドナーノード２００は、ＩＡＢノード３００のＰＲＡＣＨ設定が、隣接ドナーノードのＰＲＡＣＨ設定と衝突するか否かを確認する。ドナーノード２００は、衝突しなければ、以降の処理を行うことなく終了する。以下では、衝突するものとして説明する。

ステップＳ１０３において、ドナーノード２００は、隣接ドナーノードのＰＲＡＣＨ設定と衝突しないＰＲＡＣＨ設定を決定する。具体的には、ドナーノード２００は、自ドナーノード２００と、隣接ドナーノードのＰＲＡＣＨ設定とが衝突しないＰＲＡＣＨ設定を決定する。

この場合、ドナーノード２００は、当該ＰＲＡＣＨ設定を決定することに代えて、Ｆ１ Ｓｅｔｕｐ Ｆａｉｌｕｒｅメッセージを、ＩＡＢノード３００へ送信してもよい。この場合、ドナーノード２００は、ＩＡＢノード３００のＰＲＡＣＨ設定がＮＧであること、又は当該ＰＲＡＣＨ設定が衝突すること、を表す理由（Ｃａｕｓｅ）を、Ｆ１ Ｓｅｔｕｐ Ｆａｉｌｕｒｅメッセージに含めて送信してもよい。ＩＡＢノード３００は、Ｆ１ Ｓｅｔｕｐ Ｆａｉｌｕｒｅメッセージを受信した場合、他のＰＲＡＣＨ設定を再考するようにしてもよい。ＩＡＢノード３００は、他のＰＲＡＣＨ設定をドナーノード２００へ送信し、ステップＳ１０１以降を繰り返すようにしてもよい。

ステップＳ１０４において、ドナーノード２００は、決定したＰＲＡＣＨ設定を含むＦ１ Ｓｅｔｕｐ ＲｅｓｐｏｎｓｅメッセージをＩＡＢノード３００へ送信する。

ステップＳ１０５において、ＩＡＢノード３００は、ドナーノード２００で決定したＰＲＡＣＨ設定を適用する。ＩＡＢノード３００は、ドナーノード２００へのアクセス開始時、又は、当該アクセス完了時に、当該ＰＲＡＣＨ設定を適用してもよい。

図１２に示す動作例において、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージ（ステップＳ１０１）及びＦ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージ（ステップＳ１０４）の例を説明した。

Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージに代えてｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージ、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージに代えてｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ Ａｃｋｎｏｗｌｅｄｇｅメッセージであってもよい。この場合、ＩＡＢノード３００のＰＲＡＣＨ設定がｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージに含まれ、決定したＰＲＡＣＨ設定がｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ Ａｃｋｎｏｗｌｅｄｇｅメッセージに含まれる。

また、Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージに代えてｇＮＢ－ＣＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージ、Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージに代えてｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ Ａｃｋｎｏｗｌｅｄｇｅメッセージであってもよい。この場合、ＩＡＢノード３００のＰＲＡＣＨ設定がｇＮＢ－ＣＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージに含まれ、決定したＰＲＡＣＨ設定がｇＮＢ－ＤＵ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ Ａｃｋｎｏｗｌｅｄｇｅメッセージに含まれる。

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

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

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

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

本願は、日本国特許出願第２０２１－１１４４９９号（２０２１年７月９日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

１ ：移動通信システム
１０ ：５ＧＣ
１１ ：ＡＭＦ
１００ ：ＵＥ
１１０ ：無線通信部
１２０ ：制御部
２００（２００－１，２００－２）：ｇＮＢ（ドナーノード）
２１０ ：無線通信部
２２０ ：ネットワーク通信部
２３０ ：制御部
３００ ：ＩＡＢノード
３１０ ：無線通信部
３２０ ：制御部

Claims (5)

1. セルラ通信システムで用いる通信制御方法であって、
   移動可能な移動ＩＡＢノードが、前記移動ＩＡＢノードにおいて使用可能な第１セルＩＤがＯＡＭにより設定されることと、
   ドナーノードが、第２セルＩＤを含むＦ１メッセージを、前記移動ＩＡＢノードへ送信することと、を有し、
   前記第２セルＩＤは、前記ドナーノードで使用可能なセルＩＤのうち前記第１セルＩＤと衝突しないセルＩＤである
   通信制御方法。
2. セルラ通信システムにおいて移動可能な移動ＩＡＢノードであって、
   前記移動ＩＡＢノードにおいて使用可能な第１セルＩＤがＯＡＭにより設定される制御部と、
   第２セルＩＤを含むＦ１メッセージをドナーノードから受信する受信部と、を有し、
   前記第２セルＩＤは、前記ドナーノードで使用可能なセルＩＤのうち前記第１セルＩＤと衝突しないセルＩＤである
   移動ＩＡＢノード。
3. セルラ通信システムにおいて移動可能な移動ＩＡＢノードに、
   前記移動ＩＡＢノードにおいて使用可能な第１セルＩＤがＯＡＭにより設定される処理と、
   第２セルＩＤを含むＦ１メッセージをドナーノードから受信する処理と、
   を実行させ、
   前記第２セルＩＤは、前記ドナーノードで使用可能なセルＩＤのうち前記第１セルＩＤと衝突しないセルＩＤである
   プログラム。
4. セルラ通信システムにおいて移動可能な移動ＩＡＢノードのチップセットであって、
   前記移動ＩＡＢノードにおいて使用可能な第１セルＩＤがＯＡＭにより設定されることと、
   第２セルＩＤを含むＦ１メッセージをドナーノードから受信することと、
   を実行し、
   前記第２セルＩＤは、前記ドナーノードで使用可能なセルＩＤのうち前記第１セルＩＤと衝突しないセルＩＤである
   チップセット。
5. 請求項２に記載の移動ＩＡＢノードを有するセルラ通信システム。

Images