JP7328458B2 - 通信制御方法、中継ノード及びプロセッサ - Google Patents

Description

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

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

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って前記複数の中継先ノードの中からデータ中継先を選択することと、前記中継ノードが、所定条件が満たされた場合、前記ルーティング設定に従わずに前記データ中継先を選択するローカルルーティングを実行することと、を有する。前記所定条件は、前記複数の中継先ノードのいずれかから障害発生通知を受信したという条件を含む。

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、配下にユーザ装置を有する中継ノードが、第１ドナー基地局から第２ドナー基地局への接続切替を行うことと、前記接続切替を行っても、前記ユーザ装置と前記第１ドナー基地局との間のＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続を前記第２ドナー基地局経由で継続することと、前記第１ドナー基地局が、前記ＲＲＣ接続を用いて、前記第２ドナー基地局へのハンドオーバを指示するハンドオーバ指令を前記第２ドナー基地局経由で前記ユーザ装置に送信することとを有する。

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、前記複数の中継先ノードに含まれる対象中継ノードのデータ中継容量に関する容量情報を前記対象中継ノードから受信することと、前記中継ノードが、前記容量情報に基づいて前記データ中継を制御することとを有する。

第４の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って、前記複数の中継先ノードの中からデータ中継先を選択することと、前記中継ノードが、前記ルーティング設定を変更するためのルーティング設定変更要求を前記ドナー基地局に送信することとを有する。

第５の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法であって、中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定に従って、前記複数の中継先ノードの中からデータ中継先を選択することと、前記中継ノードが、所定条件が満たされた場合、前記ルーティング設定に従わずに前記データ中継先を選択するローカルルーティングを実行することと、前記ローカルルーティングに関する履歴情報を前記ドナー基地局に送信することとを有する。

実施形態に係るセルラ通信システムの構成を示す図である。 ＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を示す図である。 実施形態に係るｇＮＢ（基地局）の構成を示す図である。 実施形態に係るＩＡＢノード（中継ノード）の構成を示す図である。 実施形態に係るＵＥ（ユーザ装置）の構成を示す図である。 ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックを示す図である。 Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。 Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。 第１実施形態に係る動作を示す図である。 第１実施形態に係るハンドオーバ指令伝送時におけるプロトコルスタックを示す図である。 第２実施形態に係るアップストリーム中継動作を説明するための図である。 第２実施形態に係るアップストリーム中継動作を示す図である。 第２実施形態に係るダウンストリーム中継動作を説明するための図である。 第２実施形態に係るダウンストリーム中継動作を示す図である。 第２実施形態の変更例１の動作を示す図である。 第２実施形態の変更例２の動作を示す図である。 ＢＨ ＲＬＦ通知のタイプを示す図である。 子孫ノードへの再確立を回避するための特定された解決策を示す図である。 ｈｏｐ－ｂｙ－ｈｏｐ ＲＬＣ ＡＲＱの場合のＵＬデータのロスレス配信のメカニズムの比較を示す図である。 ＵＬステータス配信の導入のオプションを示す図である。

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

（セルラ通信システムの構成）
まず、実施形態に係るセルラ通信システムの構成について説明する。図１は、実施形態に係るセルラ通信システム１の構成を示す図である。

セルラ通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）セルラ通信システムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システム１には、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。

図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、基地局（ｇＮＢと呼ばれる）２００と、ＩＡＢノード３００とを有する。ＩＡＢノード３００は、中継ノードの一例である。

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

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

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

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

各ｇＮＢ２００は、Ｘｎインターフェイスと呼ばれる基地局間インターフェイスを介して、隣接関係にある他のｇＮＢ２００と相互に接続される。図１において、ｇＮＢ２００－１がｇＮＢ２００－２と接続される一例を示している。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕ（ＧＰＲＳ Ｔｕｎｎｅｌｌｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｕｓｅｒ Ｐｌａｎｅ）レイヤ及びＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）レイヤに代えて、Ｆ１ＡＰ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤ及びＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤを有する。

（第１実施形態）
次に、上述のようなセルラ通信システム１の構成を前提として、セルラ通信システム１の動作について説明する。

第１実施形態において、ＩＡＢノード３００（具体的には、ＩＡＢ－ＭＴ）がドナーｇＮＢ２００間で接続切替を行うシナリオを想定する。ＩＡＢノード３００は、移動可能なＩＡＢノード３００であってもよい。接続切替とは、ハンドオーバ又はＲＲＣ再確立をいう。ハンドオーバとは、ＲＲＣコネクティッド状態にあるＩＡＢ－ＭＴがセルを切り替える動作をいう。ＲＲＣ再確立とは、ＲＲＣコネクティッド状態にあるＩＡＢ－ＭＴが無線リンク障害の検知に応じて他セルと再接続する動作をいう。以下において、接続切替がハンドオーバである一例について説明するが、接続切替がＲＲＣ再確立であってもよい。

ＩＡＢノード３００がドナーｇＮＢ２００間で接続切替を行うシナリオにおいて、このＩＡＢノード３００の配下のＵＥ１００の動作が問題になる。具体的には、ＩＡＢノード３００がドナーｇＮＢ２００間で接続切替を行う場合、このＩＡＢノード３００の配下のＵＥ１００に新たな動作が必要になり得る。しかしながら、後方互換性の観点からは、ＵＥ１００の動作に変更を加えることは好ましくない。

第１実施形態は、ＵＥ１００側には透過的に、ネットワーク側（ＩＡＢノード側）における動作変更だけでドナーｇＮＢ２００間でのＩＡＢノード３００の接続切替（例えば、ハンドオーバ）を実現する実施例である。このようなハンドオーバは、インターＣＵハンドオーバと呼ばれてもよい。

具体的には、第１実施形態において、第１に、配下にＵＥ１００を有するＩＡＢノード３００は、第１ドナー基地局であるソースドナーｇＮＢ２００Ｓから、第１ドナー基地局と異なる第２ドナー基地局であるターゲットドナーｇＮＢ２００Ｔへのハンドオーバを行う。第２に、当該ハンドオーバを行っても、ＵＥ１００とソースドナーｇＮＢ２００Ｓとの間のＲＲＣ接続をターゲットドナーｇＮＢ２００Ｔ経由で継続する。第３に、ソースドナーｇＮＢ２００Ｓは、当該ＲＲＣ接続を用いて、ターゲットドナーｇＮＢ２００Ｔへのハンドオーバを指示するハンドオーバ指令をターゲットドナーｇＮＢ２００Ｔ経由でＵＥ１００に送信する。

すなわち、ＵＥ１００とソースドナーｇＮＢ２００との間のＲＲＣ接続（及びＰＤＣＰ接続）は、ターゲットドナーｇＮＢ２００経由で確立状態が継続され、ソースドナーｇＮＢ２００Ｓは、当該接続を用いてハンドオーバ指令をＵＥ１００に送信する。これにより、ＵＥ１００に動作変更を加えることなく、ドナーｇＮＢ２００間でのＩＡＢノード３００のハンドオーバを実現できる。

第１実施形態において、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間にデータパスを確立してもよい。ＩＡＢノード３００のハンドオーバからＵＥ１００のハンドオーバの完了までにおいて、このデータパスを介してＵＥ１００のデータの転送処理（すなわち、データフォワーディング）を行ってもよい。これにより、先にＩＡＢノード３００のハンドオーバを実行し、その後にＵＥ１００のハンドオーバを行っても、ＵＥ１００のデータの消失を防止できる。

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

図９に示すように、ステップＳ１０１において、ＵＥ１００は、ソースドナーｇＮＢ２００ＳとのＲＲＣ接続を確立した状態（ＲＲＣコネクティッド状態）にある。

ステップＳ１０２において、ＩＡＢノード３００（ＩＡＢ－ＭＴ）は、ソースドナーｇＮＢ２００ＳとのＲＲＣ接続を確立した状態（ＲＲＣコネクティッド状態）にある。ＩＡＢノード３００とソースドナーｇＮＢ２００Ｓとの間に少なくとも１つの中間ＩＡＢノードが介在してもよい。ＵＥ１００は、ＩＡＢノード３００（ＩＡＢ－ＤＵ）の配下にある。すなわち、ＵＥ１００は、ＩＡＢノード３００（ＩＡＢ－ＤＵ）のセルを自身のサービングセルとしている。

ステップＳ１０３において、ＩＡＢノード３００（ＩＡＢ－ＭＴ）は、ソースドナーｇＮＢ２００ＳからターゲットドナーｇＮＢ２００ＴへのＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）又はハンドオーバ（Ｈａｎｄｏｖｅｒ）を行う。ここではＩＡＢノード３００（ＩＡＢ－ＭＴ）がハンドオーバを行うと仮定して説明を進める。

ステップＳ１０４において、ＩＡＢノード３００（ＩＡＢ－ＭＴ）は、ハンドオーバの結果、ターゲットドナーｇＮＢ２００ＴとのＲＲＣ接続を確立する。

この時点では、ＵＥ１００のＲＲＣレイヤ及びＰＤＣＰレイヤは、ソースドナーｇＮＢ２００との接続状態が残っている。このため、ＵＥ１００は、ターゲットドナーｇＮＢ２００Ｔとの通信はＣプレーン及びＵプレーンいずれも行うことができない。

ここで、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間でトンネル（すなわち、データフォワーディングのパス）を形成する。このトンネルは、基地局間インターフェイス上に設定されてもよいし、コアネットワークを介して設定されてもよい。

ステップＳ１０５において、ＵＥ１００は、上りリンクのユーザデータ（Ｕｓｅｒ ｄａｔａ）をＩＡＢノード３００に送信する。ＩＡＢノード３００は、ユーザデータを受信する。

ステップＳ１０６において、ＩＡＢノード３００は、ＵＥ１００からのユーザデータをターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００Ｔは、ユーザデータを受信する。

ステップＳ１０７において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１０６で受信したユーザデータをソースドナーｇＮＢ２００Ｓに転送する（Ｄａｔａ ｆｏｒｗａｒｄｉｎｇ）。ソースドナーｇＮＢ２００Ｓは、ユーザデータを受信する。

ステップＳ１０８において、ソースドナーｇＮＢ２００Ｓは、ステップＳ１０７で受信したユーザデータをコアネットワークのＵＰＦ１２に転送する。

ステップＳ１０９において、ソースドナーｇＮＢ２００Ｓは、下りリンクのユーザデータ（Ｕｓｅｒ ｄａｔａ）をコアネットワークのＵＰＦ１２から受信する。

ステップＳ１１０において、ソースドナーｇＮＢ２００Ｓは、ステップＳ１０９で受信したユーザデータをターゲットドナーｇＮＢ２００Ｔに転送する（Ｄａｔａ ｆｏｒｗａｒｄｉｎｇ）。ターゲットドナーｇＮＢ２００Ｔは、ユーザデータを受信する。

ステップＳ１１１において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１１０で受信したユーザデータをＩＡＢノード３００に転送する。ＩＡＢノード３００は、ユーザデータを受信する。

ステップＳ１１２において、ＩＡＢノード３００は、ステップＳ１１１で受信したユーザデータをＵＥ１００に送信（中継）する。

このように、ＵＥ１００とソースドナーｇＮＢ２００Ｓとの間のユーザデータの送受信は、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間のトンネル及びターゲットドナーｇＮＢ２００Ｔ経由で継続する。

ステップＳ１１３において、ソースドナーｇＮＢ２００Ｓは、ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの間のトンネルを介して、ターゲットドナーｇＮＢ２００ＴへのハンドオーバをＵＥ１００に指示するハンドオーバ指令（ＨＯ Ｃｏｍｍａｎｄ）をターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００は、ハンドオーバ指令を受信する。

ステップＳ１１４において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１１３で受信したハンドオーバ指令を含むＲＲＣメッセージ（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）をＵＥ１００に送信する。具体的には、ターゲットドナーｇＮＢ２００Ｔは、当該ＲＲＣメッセージをＩＡＢノード３００経由でＵＥ１００に送信する。ＵＥ１００は、当該ＲＲＣメッセージを受信する。

図１０は、ハンドオーバ指令伝送時におけるプロトコルスタックを示す図である。図１０に示すように、ソースドナーｇＮＢ２００ＳのＲＲＣレイヤからＵＥ１００のＲＲＣレイヤに対して、ターゲットドナーｇＮＢ２００Ｔ及びＩＡＢノード３００経由でハンドオーバ指令（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）を伝送する。ソースドナーｇＮＢ２００ＳとターゲットドナーｇＮＢ２００Ｔとの通信は基地局間通信で行われる。図１０ではＧＴＰの例を示しているが、これに限らない。例えば、Ｘｎ－ＡＰであってもよく、この場合、ハンドオーバ指令はＸｎ－ＡＰメッセージのＲＲＣコンテナに内包されて（カプセル化されて）伝送される。

図９に戻り、ステップＳ１１５において、ＵＥ１００は、ハンドオーバ指令に応じて、ハンドオーバ完了を示すＲＲＣメッセージ（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）をターゲットドナーｇＮＢ２００Ｔに送信する。具体的には、ＵＥ１００は、当該ＲＲＣメッセージをＩＡＢノード３００経由でターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００Ｔは、当該ＲＲＣメッセージを受信する。ここで、ＵＥ１００は、ＩＡＢノード３００の配下にあり続けているため、ランダムアクセスプリアンブルの送信及びランダムアクセスレスポンスの受信を省略したＲＡＣＨ－ｌｅｓｓハンドオーバを行ってもよい。この場合、ハンドオーバ指令においてＲＡＣＨ－ｌｅｓｓハンドオーバがＵＥ１００に指示されてもよい。

ステップＳ１１６において、ＵＥ１００は、ハンドオーバの結果、ターゲットドナーｇＮＢ２００ＴとのＲＲＣ接続を確立する。この時点から、ＵＥ１００のユーザデータはターゲットドナーｇＮＢ２００Ｔとの通信に切り替わる。

ステップＳ１１７において、ＵＥ１００は、上りリンクのユーザデータ（Ｕｓｅｒ ｄａｔａ）をＩＡＢノード３００に送信する。ＩＡＢノード３００は、ユーザデータを受信する。

ステップＳ１１８において、ＩＡＢノード３００は、ステップＳ１１７で受信したユーザデータをターゲットドナーｇＮＢ２００Ｔに送信する。ターゲットドナーｇＮＢ２００Ｔは、ユーザデータを受信する。

ステップＳ１１９において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１１８で受信したユーザデータをコアネットワークのＵＰＦ１２に転送する。

ステップＳ１２０において、ターゲットドナーｇＮＢ２００Ｔは、下りリンクのユーザデータ（Ｕｓｅｒ ｄａｔａ）をコアネットワークのＵＰＦ１２から受信する。

ステップＳ１２１において、ターゲットドナーｇＮＢ２００Ｔは、ステップＳ１２０で受信したユーザデータをＩＡＢノード３００に転送する。ＩＡＢノード３００は、ユーザデータを受信する。

ステップＳ１２２において、ＩＡＢノード３００は、ステップＳ１２１で受信したユーザデータをＵＥ１００に送信（中継）する。

（第２実施形態）
次に、第２実施形態について、上述の実施形態との相違点を主として説明する。

第２実施形態は、ＩＡＢトポロジ内での負荷分散（ｌｏａｄ ｂａｌａｎｃｉｎｇ）に関する実施形態である。ＩＡＢノード３００は、基本的にルーティングテーブル（ＢＡＰルーティングＩＤ及びパスＩＤ）によりＩＡＢトポロジ内のパスが半固定的に決定されており、ドナーｇＮＢ２００のＣＵがルーティングテーブルを一括管理している。しかしながら、複数パスを効率的に用いることができれば、より動的な負荷分散が可能になると考えられる。

第２実施形態において、ＩＡＢノード３００は、複数の中継先ノード（複数のパス）のそれぞれのデータ中継容量を考慮して効率的なデータ中継を行う。具体的には、第２実施形態において、中継元ノードから複数の中継先ノードへデータ中継を行うＩＡＢノード３００は、当該複数の中継先ノードに含まれる対象ＩＡＢノード３００のデータ中継容量に関する容量情報を受信する。そして、ＩＡＢノード３００は、受信した容量情報に基づいてデータ中継を制御する。

容量情報は、複数の中継先ノードに含まれる対象ＩＡＢノード３００の次ホップのノードが複数存在するか否かを示す情報を含んでもよい。対象ＩＡＢノード３００の次ホップのノードが複数存在する場合、対象ＩＡＢノード３００はデータ中継容量が大きいとみなすことができる。このため、このような対象ＩＡＢノード３００に対して優先的にデータを中継することで、複数パスを効率的に用いることができる。

ＩＡＢノード３００は、複数の中継先ノードのそれぞれについて容量情報を受信し、受信した容量情報に基づいて、複数の中継先ノードに対するデータ送信比率を制御してもよい。例えば、ＩＡＢノード３００は、データ中継容量が大きい中継先ノードに対して多くのデータを中継し、データ中継容量が小さい他の中継先ノードに対して少ないデータを中継する。

上述のように、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定（ルーティングテーブル）に従って複数の中継先ノードの中からデータ中継先を選択する。ＩＡＢノード３００は、所定条件が満たされた場合、ルーティング設定に従わずにデータ中継先を選択するローカルルーティングを実行してもよい。ここで、所定条件は、複数の中継先ノードのいずれかから障害発生通知又はローカルルーティング要求を受信したという条件を含んでもよい。

このように、ＩＡＢノード３００は、基本的にはドナーｇＮＢ２００Ｓからの設定に従ってルーティングを行い、中継先ノードの障害発生時又は要求発生時にはＩＡＢノード３００自らローカルルーティングを行うことにより、状況に応じて適切な中継先ノードにデータを中継可能になる。

（１）アップストリーム中継動作
第２実施形態に係るアップストリーム中継動作について説明する。

図１１は、第２実施形態に係るアップストリーム中継動作を説明するための図である。アップストリーム中継動作において、ＩＡＢノード３００の中継元ノードは当該ＩＡＢノード３００の子ノードであり、ＩＡＢノード３００の中継先ノードは当該ＩＡＢノード３００の親ノードである。

図１１に示すように、ＩＡＢノード３００と、他のＩＡＢノード３００ａ乃至３００ｇと、ドナーｇＮＢ２００とを含むＩＡＢトポロジが形成されている。ＩＡＢノード３００は、子ノード（ＵＥ１００であり得る）から上りリンクパケット（ＵＬ ｐａｃｋｅｔ）を受信する。ＩＡＢノード３００は、受信した上りリンクパケットを、ドナーｇＮＢ２００から設定されたルーティング設定と、当該上りリンクパケットのヘッダに含まれる情報（ＢＡＰルーティングＩＤ）とに基づいて、親ノードであるＩＡＢノード３００ａ及び／又はＩＡＢノード３００ｂに中継する。

ＩＡＢノード３００ａ乃至３００ｇのそれぞれは、自ノードの次ホップのノードが複数存在するか否かを示す情報を自ノードの容量情報として子ノードに送信する。アップストリーム中継動作において、このような容量情報を「ＢＨ接続情報」と呼ぶ。ＢＨ接続情報の具体例については後述する。このようなＢＨ接続情報を各ＩＡＢノード３００が子ノードに送信することにより、子ノードは、自身の親ノードの潜在的な容量を把握できるため、ローカルルーティング時において効率的なデータ中継を行うことができる。

自ノードの次ホップのノードが１つであるＢＨを「シングルＢＨ」と呼び、自ノードの次ホップのノードが２つであるＢＨを「デュアルＢＨ」と呼ぶ。図１１の例において、ＩＡＢノード３００ｂ、３００ｃ、３００ｅ、３００ｆ、及び３００ｇのそれぞれはシングルＢＨである。一方、ＩＡＢノード３００ａ及び３００ｄのそれぞれはデュアルＢＨであり、シングルＢＨに比べてデータ中継容量が大きいとみなすことができる。なお、デュアルＢＨは、デュアルコネクティビティにより二重で接続が確立された状態であってもよい。

例えば、ＩＡＢノード３００は、親ノード（ＩＡＢノード３００ａ、３００ｂ）のＢＨ接続情報に基づいて送信比率を決定する。ＩＡＢノード３００ａがデュアルＢＨであって、ＩＡＢノード３００ｂがシングルＢＨであるため、親ノードの総ＢＨリンク数は３である。このため、ＩＡＢノード３００は、ローカルルーティングを行う場合、ＩＡＢノード３００ａに対する送信比率を「２／３」に設定し、ＩＡＢノード３００ｂに対する送信比率を残りの「１／３」に設定する。なお、ある親ノードの送信比率をゼロに設定してもよい。この場合、送信比率の決定は、パス選択（パス切替）とみなすことができる。

図１２は、第２実施形態に係るアップストリーム中継動作を示す図である。この動作はＩＡＢノード３００により実行され、そのうちの少なくとも一部がＢＡＰレイヤ及び／又はＩＡＢ－ＭＴにより実行されてもよい。

図１２に示すように、ステップＳ２０１において、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う。

ステップＳ２０２において、ＩＡＢノード３００は、ローカルルーティングの開始条件が満たされたか否かを判定する。例えば、開始条件は次のいずれかである。開始条件を定めるパラメータ（閾値等）は、ドナーｇＮＢ２００からＩＡＢノード３００に設定されてもよい。

・親ノードからＢＨの障害発生通知を受信したという条件：
例えば、親ノードにおけるＢＨの障害発生通知は、ＢＡＰレイヤのメッセージであるＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎにより親ノードからＩＡＢノード３００に送信される。ＢＨの障害発生通知は、親ノードのＢＨでＲＬＦ（Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）が発生したことを示す通知であってもよいし、親ノードがＢＨのＲＬＦからのリカバリ処理中であることを示す通知であってもよいし、親ノードのＢＨのＲＬＦからのリカバリに失敗したことを示す通知であってもよい。

・ある親ノードへの上りリンクスループットが一定以下に低下したという条件：
例えば、ある親ノードに対してＩＡＢノード３００が送信したスケジューリング要求（ＳＲ）が一定回数以上無視された（例えば、上りリンクグラントが来なかった）場合が本条件に該当してもよい。親ノード同士の上りリンクスループットを比較して、過去一定期間上りリンクスループットに一定以上の差（偏り）が発生した場合（かつ、その状態が一定期間以上継続した場合）が本条件に該当してもよい。ある親ノードの上りリンクスループットが一定値以下となった場合（かつ、その状態が一定期間以上継続した場合）が本条件に該当してもよい。

・親ノードからローカルルーティング要求を受信したという条件：
ローカルルーティング要求は、ＢＡＰレイヤのメッセージにより親ノードから送信されてもよい。ローカルルーティング要求は、Ｆ１メッセージ又はＲＲＣメッセージによりドナーｇＮＢ２００から親ノード経由で送信されてもよい。ＩＡＢノード３００は、親ノードからのローカルルーティング要求に対して応答を送信してもよいし、後述の送信比率を親ノードに通知してもよい。

当該ローカルルーティング要求は、ローカルルーティングを行う対象となるベアラ（又はＲＬＣチャネル、又は論理チャネル）の識別子を含んでもよい。ＩＡＢノード３００は、対象のベアラ（又はＲＬＣチャネル、又は論理チャネル）についてローカルルーティングを行い、対象外のベアラ（又はＲＬＣチャネル、又は論理チャネル）についてはローカルルーティングを行わない（すなわち、ルーティングテーブルに従ったルーティングを行う）。

・ＩＡＢノード３００又はその子ノードの上りリンクバッファ量が一定以上になった（かつ、その状態が一定期間以上継続した）という条件：
例えば、ＩＡＢノード３００は、子ノードから受信するバッファ状態報告（ＢＳＲ）に基づいて子ノードの上りリンクバッファ量を把握できる。ＢＳＲは、当該子ノードのさらに子ノード（すなわち、孫ノード）の上りリンクバッファ量を加味したものであってもよい。ＢＳＲが示す上りリンクバッファ量が一定以上になった場合（かつ、その状態が一定期間以上継続した場合）が本条件に該当してもよい。

ローカルルーティングの開始条件が満たされない場合（ステップＳ２０２：Ｎｏ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを継続する（ステップＳ２０１）。

一方、ローカルルーティングの開始条件が満たされた場合（ステップＳ２０２：Ｙｅｓ）、ＩＡＢノード３００は、ローカルルーティングに関する動作を開始する。なお、ＩＡＢノード３００は、ドナーｇＮＢ２００からローカルルーティングの実行が許可されている場合のみ、ローカルルーティングを実行できるとしてもよい。この許可は、ＢＡＰレイヤのメッセージ（ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ）、システム情報（ＳＩＢ１）、又はＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ等で行われる。ローカルルーティングの実行可否は、ベアラ（ＲＬＣ ｃｈａｎｎｅｌ）ごとに設定されてもよいし、全てのベアラに一括設定されてもよい。このような設定と共に、上記のいずれの条件を適用するのか、及びその条件判定に用いる閾値が設定されてもよい。

ステップＳ２０３において、ＩＡＢノード３００は、各親ノードのＢＨ接続情報を受信する。なお、ステップＳ２０３は、ステップＳ２０２の前に行われてもよい。

親ノードのＢＨ接続情報は、当該親ノードがシングルＢＨであるのか又はデュアルＢＨであるのか（又はトリプルＢＨであるのか）を示す情報を含んでもよい。親ノードのＢＨ接続情報は、当該親ノードのＢＨの数を示す数値を含んでもよい。ＢＨ接続情報は、各ＢＨリンクのキャパシティに関する情報をさらに含んでもよい。各ＢＨリンクのキャパシティに関する情報は、例えば、各ＢＨリンクの帯域幅、コンポーネントキャリア数、及び周波数帯のうち少なくとも１つを示す情報であってもよいし、各ＢＨリンクの平均スループット（或いは、最大スループット、ＧＢＲ（Ｇｕａｒａｎｔｅｅｄ Ｂｉｔ Ｒａｔｅ）等）を示す情報であってもよい。

ＢＨ接続情報は、親ノードからＩＡＢノード３００に送信されてもよい。例えば、ＢＨ接続情報は、親ノードが送信するＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ又はシステム情報（例えばＳＩＢ１）に含まれる情報要素であってもよい。親ノードは、自身がデュアルＢＨ（又はトリプルＢＨ）である場合はＢＨ接続情報を送信し、シングルＢＨの場合はＢＨ接続情報を送信しないとしてもよい。ＩＡＢノード３００は、ＢＨ接続情報の送信有無により、シングルＢＨ及びデュアルＢＨを判別する。

或いは、ＢＨ接続情報は、ドナーｇＮＢ２００からＩＡＢノード３００に送信されてもよい。ドナーｇＮＢ２００が送信するＲＲＣメッセージ（例えばＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）又はＦ１メッセージ（例えばＤＬ Ｉｎｆｏｒｍａｔｉｏｎ Ｔｒａｎｓｆｅｒ）に含まれる情報要素であってもよい。

ステップＳ２０４において、ＩＡＢノード３００は、ステップＳ２０３で受信したＢＨ接続情報に基づいて、上りリンクのパケット送信比率を決定する。上述の例のように、ＩＡＢノード３００は、一方の親ノードがデュアルＢＨであって、他方の親ノードがシングルＢＨである場合、当該一方の親ノードに対する送信比率を「２／３」に設定し、当該他方の親ノードに対する送信比率を「１／３」に設定する。ここで、例えば送信比率を０対１に設定する場合、送信先をスイッチした（ローカルスイッチした）と考えられる。ＩＡＢノード３００は、ＢＨ接続情報に含まれる情報（例えば、各ＢＨリンクのキャパシティに関する情報）に基づいて、送信比率を調整又は決定してもよい。ＩＡＢノード３００は、各親ノードに対する過去の送信スループット履歴（或いは、子ノードへの上りリンクグラント履歴（すなわち、受信スループット））に基づいて送信比率を調整又は決定してもよい。

ステップＳ２０５において、ＩＡＢノード３００は、ステップＳ２０４で決定（及び調整）した送信比率に基づいて、上りリンクパケットのローカルルーティングを行う。ＩＡＢノード３００は、ローカルルーティングを行った上りリンクパケットのヘッダを変更してもよい。例えば、ＢＡＰヘッダにおいて、ルーティングＩＤの変更を行ってもよく、ローカルルーティングが行われたことを示す識別子を付与してもよい。

ステップＳ２０６において、ＩＡＢノード３００は、ローカルルーティングの終了条件が満たされたか否かを判定する。終了条件は、上述の開始条件の逆の条件とすることができる。例えば、親ノードからＢＨのリカバリ成功通知を受信したという条件、ある親へのスループットが回復したという条件、ローカルルーティング停止要求を受信したという条件、及び子ノード（及び孫ノード）のバッファ状態が改善したという条件のうち、少なくとも１つである。終了条件は、ドナーｇＮＢ２００からローカルルーティング許可が取り消された（不許可に設定された）という条件を含んでもよい。

ローカルルーティングの終了条件が満たされていない場合（ステップＳ２０６：Ｎｏ）、ＩＡＢノード３００は、ローカルルーティングを継続する（ステップＳ２０５）。一方、ローカルルーティングの終了条件が満たされた場合（ステップＳ２０６：Ｙｅｓ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う（ステップＳ２０１）。

（２）ダウンストリーム中継動作
第２実施形態に係るダウンストリーム中継動作について説明する。

図１３は、第２実施形態に係るダウンストリーム中継動作を説明するための図である。ダウンストリーム中継動作において、ＩＡＢノード３００の中継元ノードは当該ＩＡＢノード３００の親ノードであり、ＩＡＢノード３００の中継先ノードは当該ＩＡＢノード３００の子ノードである。ダウンストリーム中継動作においては、上述のアップストリーム中継動作における親ノードと子ノードとを入れ替えればよい。なお、図１３において、各ＩＡＢノード３００がデュアルＢＨであって、ＩＡＢノード３００と宛先ノード（Ｄｅｓｔｉｎａｔｉｏｎ）との間に４つのパスが存在する一例を示している。

図１４は、第２実施形態に係るダウンストリーム中継動作を示す図である。この動作はＩＡＢノード３００により実行され、そのうちの少なくとも一部がＢＡＰレイヤ及び／又はＩＡＢ－ＤＵにより実行されてもよい。ここでは、アップストリーム中継動作との相違点を主として説明する。

図１４に示すように、ステップＳ３０１において、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う。

ステップＳ３０２において、ＩＡＢノード３００は、ローカルルーティングの開始条件が満たされたか否かを判定する。例えば、開始条件は次のいずれかである。開始条件を定めるパラメータ（閾値等）は、ドナーｇＮＢ２００からＩＡＢノード３００に設定されてもよい。ＩＡＢノード３００は、ドナーｇＮＢ２００からローカルルーティングが許可（設定）されている場合のみ、ローカルルーティングが実行可能であってもよい。当該許可は、Ｆ１メッセージ（Ｆ１ＡＰ）、ＲＲＣメッセージ、又はＢＡＰメッセージにより行われてもよい。当該許可は、ベアラ（ＲＬＣ ｃｈａｎｎｅｌ）ごとに設定されてもよいし、全てのベアラに一括設定されてもよい。当該許可は、指示であってもよい。また、下記の条件のうちいずれの条件を適用するのか、及びその条件判定に用いる閾値が設定されてもよい。

・あるパスのスループットが一定以下に低下した場合（かつ、その状態が一定期間以上継続した）という条件。

・ある子ノードの無線状態が悪くなった（かつ、その状態が一定期間以上継続した）という条件：
例えば、ＩＡＢノード３００は、子ノードからの測定報告及び／又は子ノードに対するスケジューリング結果（ＭＣＳ等）から無線状態を判定してもよい。

・ある子ノードの利用可能バッファサイズが一定値を下回った（かつ、その状態が一定期間以上継続した）という条件：
例えば、ＩＡＢノード３００のＩＡＢ－ＤＵは、Ｆｌｏｗ ｃｏｎｔｒｏｌ ｐｏｌｌｉｎｇ ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを子ノードへ送信し、Ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを子ノードから受信する。そして、ＩＡＢノード３００（ＩＡＢ－ＤＵ）は、Ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵで示される利用可能バッファサイズ（空きバッファ量）を特定し、判定を行う。

ローカルルーティングの開始条件が満たされない場合（ステップＳ３０２：Ｎｏ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを継続する（ステップＳ３０１）。

一方、ローカルルーティングの開始条件が満たされた場合（ステップＳ３０２：Ｙｅｓ）、ＩＡＢノード３００は、ローカルルーティングに関する動作を開始する。ＩＡＢノード３００は、ルーティング設定の中から宛先（Ｄｅｓｔｉｎａｔｉｏｎ）が同一である異なるパスを選択し、当該パスに対応するＩＡＢノードへ下りリンクパケットを送信してもよい。また、ＩＡＢノード３００は、ローカルルーティングを行った下りリンクパケットのヘッダを変更してもよい。例えば、ＢＡＰヘッダにおいて、ルーティングＩＤの変更を行ってもよく、ローカルルーティングが行われたことを示す識別子を付与してもよい。

ステップＳ３０３において、ＩＡＢノード３００は、各子ノードから利用可能バッファサイズ情報を受信してもよい。

ステップＳ３０４において、ＩＡＢノード３００は、ダウンストリームパスの選択及び／又は子ノードへの送信比率を決定する。具体的には、ＩＡＢノード３００は、記憶しているルーティング設定の中から、同一の宛先を有する他のパスを選択する。ＩＡＢノード３００は、複数のパスを選択してもよく、この場合、上述のアップストリーム中継動作と同様にして送信比率を決定してもよい。ドナーｇＮＢ２００からＩＡＢノード３００に対して、選択可能なパスの組み合わせが予め設定されていてもよい。

ステップＳ３０５において、ＩＡＢノード３００は、ステップＳ３０４の結果に応じてローカルルーティングを行う。

ステップＳ３０６において、ＩＡＢノード３００は、ローカルルーティングの終了条件が満たされたか否かを判定する。終了条件は、上述の開始条件の逆の条件とすることができる。例えば、あるパスのスループットが一定以上に回復したという条件、子ノードの無線状態が一定以上に回復したという条件、子ノードの利用可能バッファサイズが一定以上に回復したという条件のうち、少なくとも１つである。終了条件は、ドナーｇＮＢ２００からローカルルーティング許可が取り消された（不許可に設定された）という条件を含んでもよい。

ローカルルーティングの終了条件が満たされていない場合（ステップＳ３０６：Ｎｏ）、ＩＡＢノード３００は、ローカルルーティングを継続する（ステップＳ３０５）。一方、ローカルルーティングの終了条件が満たされた場合（ステップＳ３０６：Ｙｅｓ）、ＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に基づいたルーティングを行う（ステップＳ３０１）。

（第２実施形態の変更例１）
次に、第２実施形態の変更例１について、上述の実施形態との相違点を主として説明する。

上述の第２実施形態において、ＩＡＢノード３００により実行されたローカルルーティングの内容（いつ実行されたか及び何回実施されたか）についてはドナーｇＮＢ２００が把握できない虞がある。ローカルルーティングが実行された場合、ドナーｇＮＢ２００によるルーティング設定に不備がある、或いはＩＡＢトポロジ内で障害が発生した可能性がある。このため、ローカルルーティングの内容をドナーｇＮＢ２００が把握できることが好ましい。これにより、例えばドナーｇＮＢ２００がルーティング設定を最適化することが可能になる。

本変更例において、中継元ノードから複数の中継先ノードへデータ中継を行うＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に従って、複数の中継先ノードの中からデータ中継先を選択する。ＩＡＢノード３００は、所定条件が満たされた場合、ルーティング設定に従わずにデータ中継先を選択するローカルルーティングを実行する（第２実施形態を参照）。ＩＡＢノード３００は、このローカルルーティングに関する履歴情報（すなわち、ローカルルーティングの内容を示す情報）をドナーｇＮＢ２００に送信する。

図１５は、第２実施形態の変更例１の動作を示す図である。

図１５に示すように、ステップＳ４０１において、ＩＡＢノード３００は、ローカルルーティングを行う。

ステップＳ４０２において、ＩＡＢノード３００は、ステップＳ４０１で実行したローカルルーティングに関する情報（ローカルルーティング情報）を保存する。ＩＡＢノード３００は、ローカルルーティングを行うたびにそのローカルルーティング情報を保存する。

ローカルルーティング情報は、ローカルルーティングの実行時刻を示すタイムスタンプ、ローカルルーティングの実行場所を示す位置情報（緯度経度高度）、ローカルルーティングの実行時の無線状況を示す情報のうち、少なくとも１つを含んでもよい。ローカルルーティング情報は、ローカルルーティングによる変更前後のルーティングＩＤ（パスＩＤ及びＤｅｓｔｉｎａｔｉｏｎ）を含んでもよい。ローカルルーティング情報は、接続中のＩＡＢトポロジのトポロジＩＤ（ドナーｇＮＢ ＩＤ、ｇＮＢ－ＣＵ ＩＤでもよい）を含んでもよい。ローカルルーティング情報は、ローカルルーティングを実行した理由（又は条件）を示す情報を含んでもよい。ローカルルーティング情報は、ローカルルーティングを行っていた期間（開始時間、終了時間）及び／又はローカルルーティングを行った回数を示す情報を含んでもよい。なお、ローカルルーティング情報は、ＢＡＰレイヤで保存してもよいし、ＢＡＰレイヤからＲＲＣレイヤに都度報告されてＲＲＣレイヤで保存されてもよい。

ステップＳ４０３において、ＩＡＢノード３００は、ステップＳ４０２で保存したローカルルーティング情報をドナーｇＮＢ２００へ送信する。ローカルルーティング情報は、例えばＲＲＣメッセージによりＩＡＢノード３００から送信される。当該ローカルルーティング情報は、ドナーｇＮＢ２００からの要求に応じて、応答メッセージとして送信されてもよい。例えば、当該ローカルルーティング情報は、ＵＥ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｑｕｅｓｔに対する、ＵＥ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｓｐｏｎｓｅとして送信されてもよい。

（第２実施形態の変更例２）
次に、第２実施形態の変更例２について、上述の実施形態との相違点を主として説明する。本変更例は、ＩＡＢノード３００からの要求によりドナーｇＮＢ２００がＩＡＢノード３００のルーティング設定を変更する実施例である。

本変更例において、中継元ノードから複数の中継先ノードへデータ中継を行うＩＡＢノード３００は、ドナーｇＮＢ２００から設定されたルーティング設定に従って、複数の中継先ノードの中からデータ中継先を選択する。ＩＡＢノード３００は、ルーティング設定を変更するためのルーティング設定変更要求をドナーｇＮＢ２００に送信する。

図１６は、第２実施形態の変更例２の動作を示す図である。

図１６に示すように、ステップＳ５０１において、ＩＡＢノード３００は、ルーティング設定変更要求をドナーｇＮＢ２００に送信する。ルーティング設定変更要求は、ルーティング変更を希望する旨の通知であってもよい。ルーティング設定変更要求は、ＲＲＣメッセージ又はＦ１（Ｆ１ＡＰ）メッセージであってもよい。ルーティング設定変更要求は、アップストリームルーティング変更の場合とダウンストリームルーティング変更の場合とで別々に規定されてもよい。当該ルーティング設定変更要求は、ドナーｇＮＢ２００から送信が許可されている場合のみ送信できる、としてもよい。

ＩＡＢノード３００は、上述の第２実施形態で説明したローカルルーティングの開始条件と同じ条件が満たされたことをトリガとして、ルーティング設定変更要求を送信してもよい。どのような条件及び判定閾値を用いるかは、ドナーｇＮＢ２００からＩＡＢノード３００に設定されてもよい。ＩＡＢノード３００は、ドナーｇＮＢ２００からルーティング設定変更要求の送信が許可（設定）されている場合のみルーティング設定変更要求の送信を行うとしてもよい。

ルーティング設定変更要求は、ルーティング設定変更が必要となった理由（又は条件）を示す情報、設定変更対象のルーティングＩＤ（パスＩＤ、Ｄｅｓｔｉｎａｔｉｏｎ）、設定変更対象のＲＬＣ Ｃｈａｎｎｅｌ ＩＤ（ベアラＩＤ、ＬＣＩＤでもよい）のうち、少なくとも１つを含んでもよい。

アップストリームルーティング変更の場合、ＩＡＢノード３００は、自身のＢＳＲ値をルーティング設定変更要求に含めてもよい。また、ＩＡＢノード３００は、デュアルＢＨ（デュアルコネクティビティ）の場合、親ノードごと（パス毎）にＢＳＲ値をルーティング設定変更要求に含めてもよい。ＩＡＢノード３００は、自身の子ノードのＢＳＲ値又はそれが加味された自身のＢＳＲ値をルーティング設定変更要求に含めてもよい。このようなＢＳＲ値の送信は、ＩＡＢトポロジ内の各ＩＡＢノード３００が定期的にドナーｇＮＢ２００に対して行ってもよい。

ダウンストリームルーティング変更の場合、ＩＡＢノード３００は、自身の利用可能バッファサイズ値及び／又は自身の子ノードの利用可能バッファサイズ値（Ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ値）をルーティング設定変更要求に含めてもよい。このような利用可能バッファサイズ値の送信は、ＩＡＢトポロジ内の各ＩＡＢノード３００が定期的にドナーｇＮＢ２００に対して行ってもよい。

ステップＳ５０２において、ドナーｇＮＢ２００は、ステップＳ５０１で受信したルーティング設定変更要求に応じてＩＡＢノード３００のルーティング設定を変更する。ＩＡＢノード３００は、必要に応じて、ＩＡＢノード３００のハンドオーバ（すなわち、ＩＡＢトポロジ変更）を行ってもよい。

なお、ＩＡＢノード３００は、ルーティング設定変更要求を送信した際にタイマを始動し、このタイマが満了するまで次のルーティング設定変更要求の送信が禁止されてもよい。このタイマのタイマ値は、ドナーｇＮＢ２００からＩＡＢノード３００に対して設定されてもよい。

（その他の実施形態）
上述の実施形態及び変更例は、別々の実施形態及び変更例を相互に組み合わせて実施可能である。また、第２実施形態の変更例１及び２は、第２実施形態と併用してもよいし、第２実施形態とは別に実施してもよい。

上述の実施形態及び変更例において、ＩＡＢによる中継伝送を例として説明したがこれに限られず、その他の中継伝送システムに適用してもよい。例えば、上述の実施形態及び変更例に係る動作を、リレーノード（レイヤ３中継ノード）、サイドリンクリレー（ユーザ装置間の直接通信に用いるサイドリンクを使った中継ノード）などに適用してもよい。

上述の実施形態において、セルラ通信システム１が５Ｇセルラ通信システムである一例について主として説明した。しかしながら、セルラ通信システム１における基地局はＬＴＥ基地局であるｅＮＢであってもよい。また、セルラ通信システム１におけるコアネットワークはＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されてもよい。

上述の実施形態及び変更例に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。

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

（付記）
（導入）
ＮＲ ｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）に関する改訂されたワークアイテムが承認された。いくつかの目的は次の通りである。

トポロジ適応の拡張
・シグナリング負荷を軽減するための機能拡張を含む、堅牢性及び負荷分散を強化するためのインタードナーＩＡＢノード移動のための手順の仕様。
・ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性に対する拡張の仕様。
トポロジ、ルーティング、及びトランスポートの機能拡張
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。

この付記では、バックホールリンク品質の想定、ＢＨ ＲＬＦインジケーションの拡張、ＢＨ ＲＬＦ回復及びセル（再）選択、及びロスレス配信の拡張の観点から、Ｒｅｌ－１７ ｅＩＡＢのトポロジ適応拡張の最初の考慮事項について議論する。

（議論）
（バックホールリンク品質の想定）
Ｒｅｌ－１５の研究段階で、ＴＲは、要件の背景の１つとして、「無線バックホールリンクは、車両などの移動物体、季節の変化（葉）、インフラストラクチャの変化（新しい建物）などによる閉塞に対して脆弱である。このような脆弱性は、物理的に静止しているＩＡＢノードにも当てはまる。」と述べている。そのため、ＴＲでキャプチャされたように、マルチホップ／無線バックホールに起因するさまざまな課題とこれらの潜在的な解決策が研究された。

所見１：Ｒｅｌ－１５の研究では、不安定なバックホールリンクによって引き起こされるさまざまな課題とこれらの潜在的な解決策が特定され、ＴＲ３８．８７４で十分にキャプチャされた。

Ｒｅｌ－１６の規範的なワークでは、ＩＡＢノードは静止している、即ち、「固定ＩＡＢノード」であると想定された。そのため、バックホール（ＢＨ）は、ミリ波を介したバックホールリンク及び／又は管理されていない方法で展開される可能性のあるローカルエリアＩＡＢノードの場合でも、適切に設計された展開で十分に安定した。そのため、ＢＨ ＲＬＦの基本機能、即ち、ＢＨ ＲＬＦインジケーション（別名、「回復失敗」のタイプ４）及びＲＲＣ再確立、ＭＣＧ／ＳＣＧ障害インジケーション、及び／又は条件付きハンドオーバなどの既存機能と組み合わされた回復手順のみが規定された。

所見２：Ｒｅｌ－１６ ＩＡＢでは、十分に安定したバックホールリンクを持つ固定ＩＡＢノードのみが想定された。

Ｒｅｌ－１７の拡張では、意図されたユースケースの1つは「モバイルＩＡＢノード」であり、ＷＩＤに明示的に記載されていなくても、「インタードナーＩＡＢノード移動」の一部である可能性がある。さらに、「ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能」及び「トポロジの冗長性に対する拡張」のようなＷＩＤにおけるサブ目的は、ＢＨリンクが安定していないことを明確に意図しており、移動及びＢＨ ＲＬＦはＲｅｌ－１７展開のシナリオで頻繁に発生する。従って、Ｒｅｌ－１７の議論によれば、ＲＡＮ２は最初にＢＨリンクの想定について共通の理解を有するべきである。

提案１：ＲＡＮ２は、バックホールリンクの品質が動的に変化することを想定すべきである。従って、バックホールＲＬＦは、Ｒｅｌ－１７ ｅＩＡＢのようにまれなケースではない。

（ＢＨ ＲＬＦインジケーションの拡張）
Ｒｅｌ－１６のＥメールディスカッションでは、図１７に示すような４種類のＢＨ ＲＬＦ通知が議論された。

最後に、タイプ４の「回復失敗」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして規定され、これにより、子ＩＡＢ－ＭＴはＢＨリンク上のＲＬＦを考慮し、ＲＬＦ回復手順を開始する。

所見３：Ｒｅｌ－１６では、タイプ４の「回復障害」のみがＢＨ ＲＬＦインジケーションとして規定された。

一方で、多くの企業は依然として他の種類のインジケーションが有益であると考えていたので、それはＥメールでさらに議論された。１３社中８社がタイプ２の「回復を試みている」を導入することを好み、他の２社はＲｅｌ－１７で議論されると考えた。従って、大多数の企業は、Ｒｅｌ－１７にタイプ２のインジケーションを導入する準備ができていると考えていると見なされ得る。ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ、ＳＩＢ１、又はその両方を使用することなどによって、タイプ２のインジケーションを送信する方法は、更なる検討が必要である。なお、タイプ１及びタイプ２は全く同じ意味である。

提案２：ＲＡＮ２は、ＢＨ ＲＬＦインジケーションのタイプ２の「回復を試みている」が導入されていることに合意すべきである。ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ、ＳＩＢ１、又はその両方を介して送信されるかは更なる検討が必要である。

さらに、１３社のうち９社が、Ｒｅｌ－１７でもタイプ３の「ＢＨリンク回復」について議論することに合意した。詳細には、そのような明示的なインジケーションは本当に必要かが検討され得る。例えば、タイプ２のインジケーションがＳＩＢ１を介して送信される場合、ＢＨリンクがＲＬＦの下にない（即ち、「回復される」）と、インジケーションはブロードキャストされなくなる。従って、ダウンストリームＩＡＢノード及びＵＥは、ＳＩＢ１にタイプ２のインジケーションがないことに基づいてＢＨリンクが回復したかどうかを認識するであろう。もちろん、タイプ３のインジケーションがＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを介して送信される場合、ダウンストリームＩＡＢノードがＢＨリンク回復をすばやく知ることができるという利点がある。但し、この場合、ＵＥはＢＡＰレイヤを持たないため、事実を知ることができない。従って、ＲＡＮ２は、タイプ３のインジケーションが必要かを議論すべきである。

提案３：提案３に合意できる場合、ＲＡＮ２は、ＢＨ ＲＬＦがなくなったときの明示的なＢＨ ＲＬＦインジケーション、即ち、タイプ３の「ＢＨリンク回復」が導入されるかについて議論すべきである。

提案２及び／又は提案３に合意できる場合、インジケーションを受信したＩＡＢ－ＭＴのＢＨリンクの回復下における動作を検討すべきである。ＩＡＢ－ＭＴは、タイプ２を受信するとＳＲを削減/停止し、タイプ３を受信する（即ち、親ＩＡＢノードでＢＨ ＲＬＦがなくなる）と動作を再開することが提案された。これは、親ノードがＢＨリンクを回復しようとするときに望ましいＩＡＢ－ＭＴの動作の1つである。全てのＲＢを中断するなど、他のＩＡＢ－ＭＴの動作も可能であると想定される。

提案４：ＲＡＮ２は、ＩＡＢ－ＭＴがタイプ２のインジケーションを受信した後、スケジューリング要求を削減/停止し、親ノードでＢＨ ＲＬＦがなくなった場合に、スケジューリング要求を再開することに合意すべきである。

提案５：ＲＡＮ２は、親ノードがＢＨリンクを回復しようとしている間、他のＩＡＢ－ＭＴの動作がある場合について、議論すべきである。

インジケーションを送信するＩＡＢ－ＤＵに関して、ＩＡＢノードのBHリンクがRLF下にある場合、タイプ２のＢＨ ＲＬＦインジケーションを送信することが想定される。このＢＨリンクでＲＬＦが発生するとインジケーションが送信されるため、単一接続のＢＨの場合は簡単である。しかしながら、二重接続のＢＨの場合は少し複雑になる。例えば、ＩＡＢノードがＭＣＧでＲＬＦを検出すると、ＭＣＧ障害情報手順を開始するが、ＳＣＧは引き続きＢＨリンクとして機能するため、この時点でタイプ２のインジケーションを送信する必要がない可能性がある。Ｔ３１６の満了などで、ＭＣＧ障害情報手順が失敗した場合、ＩＡＢ－ＭＴはＲＲＣ再確立を開始するため、この時点でタイプ２のインジケーションが送信される。従って、タイプ２のインジケーションは、ＭＣＧ／ＳＣＧ障害情報がトリガされたときではなく、ＲＲＣ再確立が開始されたときに送信される。いずれにせよ、これはＩＡＢ－ＤＵの動作を対象としているため、仕様にキャプチャするかどうか／どのようにキャプチャするかを慎重に検討すべきである。即ち、ステージ２、ステージ３で、ｎｏｔｅを追加するか或いは何もキャプチャする必要がないかを検討すべきである。

提案６：ＲＡＮ２は、ＩＡＢ－ＤＵがＲＬＦ回復手順のいずれかを開始するときではなく、ＲＲＣ再確立を開始するときに、タイプ２のＢＨ ＲＬＦインジケーションを送信する可能性があることに合意すべきである。

提案７：ＲＡＮ２は、仕様でＩＡＢ-ＤＵの動作（即ち、提案６）をキャプチャするかどうか/どのようにキャプチャするかについて議論すべきである。

（ＢＨ ＲＬＦ回復及びセル（再）選択の拡張）
ＲＲＣ再確立手順では、ＩＡＢ－ＭＴは、適切なセルを見つけるために、最初にセル選択手順を実行する。このセル選択手順では、ＩＡＢ－ＭＴが子孫ノードを選択する可能性があるなど、潜在的な課題がＲｅｌ－１６で指摘された。従って、それはＥメールディスカッションで議論された。

図１８に示すように、考えられる５つの解決策について、ラポーターの見解とともに議論及び要約した。

結論は、「Ｒｅｌ－１６ではこのトピックに関してこれ以上のアクションは取らない」であった。これは、ＲＡＮ２が「オプション４：ＢＨ接続がない場合、ＲＲＣ再確立は失敗するため、何も必要ない」に合意したことを意味する。オプション４は、失敗（Ｔ３０１の満了）を待ち、最終的にアイドルに移動する必要があるため、ＢＨ ＲＬＦ回復にさらに時間が必要である場合でも、Ｒｅｌ－１６の展開シナリオでは受け入れ可能であった。

所見４：Ｒｅｌ－１６では、ＩＡＢノードが子孫ノードに対してＲＲＣ再確立要求を試行した場合、ＩＡＢノードはその失敗を待ち、最終的にアイドルに移動する必要がある。

Ｒｅｌ－１７では、提案１の観点から、セル（再）選択及びＲＲＣ再確立が頻繁に発生する可能性がある。従って、準最適な動作、即ち、所見４に従う動作は、ＩＡＢトポロジの安定性及びサービス継続性の観点からパフォーマンスが大幅に低下を引き起こすであろう。従って、ＢＨ ＲＬＦ回復中のＩＡＢ－ＭＴの動作を最適化するために、上記のメールディスカッションのラポーターが述べているように、「このトピックについては、Ｒｅｌ－１７で再度議論され得る」。

提案８：ＲＡＮ２は、不適切なノード（例えば、子孫ノード）への再確立を回避するために、セル（再）選択の最適化が検討されることに合意すべきである。

上記のオプション４を除いて特定された解決策の中で、共通概念は、セル選択の目的で、ＩＡＢ－ＭＴはホワイトリストまたはブラックリストのいずれかの種類で提供されることであると見なされ得る。例えば、「インタードナーＩＡＢノードの移動」によって、トポロジ変更がＲｅｌ－１７で頻繁に発生する可能性があることを考えると、ホワイトリストとブラックリストには、トポロジ及びＩＡＢノードの位置に応じて長所と短所とがある。

例えば、ＩＡＢドナーの近くのＩＡＢノード、即ち、ＤＡＧトポロジの最上位の観点からは、候補ノードの数が少なく、場合によってはＩＡＢドナーＤＵのみであるため、ホワイトリストを提供する方が合理的である。

しかしながら、ＩＡＢドナーから遠く離れたＩＡＢノード、即ち、ＤＡＧトポロジの最下位からの観点である別の例では、ホワイトリストに膨大な数の候補ノードを含める必要がある可能性がある。代わりに、ブラックリストは、例えば、懸念されるＩＡＢノードのダウンストリームＩＡＢノードのみを含み、場合によっては少数の子ＩＡＢノードのみを含むため、この場合はオーバーヘッドが少ないという利点がある。

ホワイトリストの懸念事項の１つは、Ｒｅｌ－１７の「インタードナーＩＡＢノードの移動」の性質上、異なる／隣接するＩＡＢトポロジに属する候補ＩＡＢノードを含める必要がある場合があり、リストのサイズが大きくなる可能性があることである。一方で、ダウンストリームＩＡＢノードは同じＩＡＢトポロジに属していることは言うまでもないため、ブラックリストはそれを気にする必要がない。

所見５：ホワイトリスト及びブラックリストには、ＩＡＢノードのトポロジ及び位置に応じて長所と短所とがある。

従って、セル選択の目的で子ＩＡＢノードに情報を提供する場合、ＩＡＢドナー（又は親ＩＡＢノード）がホワイトリスト又はブラックリストのどちらかを選択できることが望ましい。なお、当該情報は、セル再選択の目的で再利用することが有益であると考えられる。

提案９：ＲＡＮ２は、子孫ノードへの再確立を回避するために、セル選択の目的でＩＡＢ－ＭＴにホワイトリスト又はブラックリスト（即ち、選択構造）が提供されることに合意すべきである。これらのリストをセル再選択手順にも使用できるかは更なる検討が必要である。

提案９に合意できる場合、情報、即ち、ホワイトリスト又はブラックリストの提供方法をさらに検討すべきである。オプション１は、ＣＨＯ設定を想定しており、いくつかの拡張が必要になる可能性がある。オプション２は、追加のインジケーションを想定しており、例えば、タイプ２のＢＨ ＲＬＦインジケーションなどである。オプション３は、既存設定にはないトポロジ全体の情報を提供することを想定している。オプション５は、ＯＡＭによる設定を想定しているが、ラポーターが指摘したように、これは疑わしい。

Ｒｅｌ－１７の想定（即ち、提案１）、即ち、トポロジ変更が発生したら、親ＩＡＢノード又はＩＡＢドナーが子ＩＡＢノードにリストを提供すべきであることを再度考慮すると、ホワイトリスト／ブラックリストの提供方法は動的な方法であるべきである。従って、オプション５、即ち、ＯＡＭは除外すべきである。どの方法、即ち、オプション１、２、又は３のうちのどの方法を拡張のベースラインにするかは、更なる検討が必要である。

提案１０：ＲＡＮ２は、トポロジが変更されるたびに、ホワイトリスト／ブラックリストが親ＩＡＢノード又はＩＡＢドナーによって動的に提供されることに合意すべきである。詳細は更なる検討が必要である。

（ロスレス配信の拡張）
Ｒｅｌ－１５の研究段階では、マルチホップＲＬＣ ＡＲＱの課題が、ＴＲのセクション８．２．３で議論され、キャプチャされた。Ｒｅｌ－１６では、プロトコルスタックは分離されていないＲＬＣ層を有するＩＡＢに対して定義された。つまり、Ｒｅｌ－１６では、ｅｎｄ－ｔｏ－ｅｎｄ ＡＲＱは除外され、ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱが採用された。

ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱに関しては、ｅｎｄ－ｔｏ－ｅｎｄの信頼性、即ち、ＵＬパケットのロスレス配信における課題が特定された。図１９に示すように、３つの解決策が特定され、評価された。

Ｒｅｌ－１６では、第１の解決策である「ＰＤＣＰプロトコル／手順の変更」はＲｅｌ－１５ UEに影響を与えるため、採用されなかった。

第２の解決策である「中間ＩＡＢノードでバッファリングされたＰＤＣＰ ＰＤＵの再ルーティング」は、ＢＡＰレイヤでの実装選択としてサポートされた。さらに、ＢＡＰレイヤは、「例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングすることは、実装依存」で実行してもよい。これらのＢＡＰ実装は、Ｒｅｌ－１６展開シナリオの「ほとんど」の場合、即ち、固定ＩＡＢノードを使用した場合、パケット損失を回避するために考慮されたが、例えば、図１９のように完全ではなかった。

第３の解決策である「ＵＬステータス配信の導入」は、図１９に引用されている評価結果を考慮して、ＵＬデータのロスレス配信を保証するための約束された解決策であった。アイデアは、ＵＥへのＲＬＣ ＡＲＱを遅延させ、ＵＥでのＰＤＣＰデータ回復が必要なときに開始されるようにすることであった。しかしながら、固定ＩＡＢノードが想定されていたため、トポロジ変更によりＵＬパケットがドロップされることはまれであると見なされていたため、Ｒｅｌ－１６では規定されなかった。

Ｒｅｌ－１７の想定を考えると、即ち、提案１の観点から、Ｒｅｌ－１７で頻繁に発生するトポロジ変更中にULパケットを損失することがもはやまれではないため、第３の解決策をさらに検討すべきである。従って、ＲＡＮ２は、ＴＲでキャプチャされた結果に加えて、Ｌ２マルチホップネットワーク内でロスレス配信を保証するための拡張メカニズムについて議論すべきである。

提案１１：ＲＡＮ２は、ＴＲ３８．８７４で特定される解決策、即ち、何らかの形式の「ＵＬステータス配信」に基づいてトポロジ変更が頻繁に発生する可能性がある条件下で、ロスレス配信を保証するメカニズムを導入することに合意すべきである。

第３の解決策、即ち、「ＵＬステータス配信の導入」の詳細については、図２０に示すように、ＥメールディスカッションでＣ－１及びＣ－２の２つのオプションについて議論した。

上記のＣ－１に関して、マルチホップＬ２ネットワークを介したｅｎｄ－ｔｏ－ｅｎｄのシグナリング転送のために、ＩＡＢドナーからの「確認」をＢＡＰ又はＲＲＣで規定する必要があると想定される。従って、このオプションを規定するためには、比較的高い標準的な取り組みが必要になるであろう。

上記のＣ－２に関して、ＩＡＢトポロジで十分に機能する場合、ＯＡＭがこのオプションを使用して全てのＩＡＢノードを設定すると想定される必要があっても、ＲＬＣ ＡＣＫをＵＥ（又はダウンストリームＩＡＢノード）に送信する場合、最終的にＩＡＢ－ＤＵ実装に依存するため、Ｒｅｌ－１６ ＩＡＢノードに対しても実際に実装可能である。さらに、ｈｏｐ－ｂｙ－ｈｏｐフィードバックを想定し、追加のＣｏｎｔｒｏｌ ＰＤＵを想定しないため、Ｃ－１よりも簡単である。従って、Ｃ－２は、ＵＬパケットのロスレス配信のためのＲｅｌ－１７の拡張ベースラインであるべきである。

所見６：「ＵＬステータス配信の導入」の解決策であるＣ－２は、Ｒｅｌ－１７の拡張ベースラインとなる可能性があり、これは、Ｒｅｌ－１６に対しても実装可能である。

但し、Ｒｅｌ－１７は、ＵＬパケット損失を引き起こす動的なトポロジ変更を想定すべきであるため、Ｒｅｌ－１７の拡張はＣ－２を標準のサポート機能としてサポートするであろう。少なくともステージ２の仕様では、Ｃ－２に基づく全体的なメカニズムを説明すべきである。それ以外の場合、３ＧＰＰ標準では、ＩＡＢノードのハンドオーバ中にロスレス配信が保証されない。さらに、ステージ３ではＲＬＣ及び／又はＢＡＰなどの小さな変更が予想されますが、ＩＡＢノードの内部動作と見なされるため、詳細を規定しない可能性もある。

提案１２：ＲＡＮ２は、ステージ２でＵＬパケットをロスレス配信するためのＲＬＣ ＡＲＱメカニズムを規定することに合意すべきである。これは、親ＩＡＢノードからＡＣＫを受信する前に、子ノード／ＵＥへのＡＣＫの送信を遅らせる（即ち、Ｃ－２）。ステージ３で規定するかどうか／どのように規定するかは更なる検討が必要である。

Claims (3)

1. セルラ通信システムで用いる通信制御方法であって、
   中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードが、ドナー基地局から設定されたルーティング設定と、前記中継元ノードから受信したデータパケットのヘッダに含まれる情報とに従って前記複数の中継先ノードの中から第１中継先ノードを選択することと、
   前記中継ノードが、所定条件が満たされた場合、前記複数の中継先ノードの中から、前記第１中継先とは異なる中継先ノードを選択するローカルリルーティングを実行することと、を有し、
   前記第１中継先ノードが前記中継ノードの親ノードである場合、前記所定条件は、前記第１中継先ノードのバックホールリンクで無線リンク障害が発生したことを示す障害発生通知を前記第１中継先ノードから受信したという条件を含み、
   前記第１中継先ノードが前記中継ノードの子ノードである場合、前記所定条件は、前記第１中継先ノードから受信した情報が示すバッファ量が一定基準を満たすという条件を含む
   通信制御方法。
2. 中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードであって、
   ドナー基地局から設定されたルーティング設定と、前記中継元ノードから受信したデータパケットのヘッダに含まれる情報とに従って前記複数の中継先ノードの中から第１中継先ノードを選択する制御部を備え、
   前記制御部は、所定条件が満たされた場合、前記複数の中継先ノードの中から、前記第１中継先とは異なる中継先ノードを選択するローカルリルーティングを実行し、
   前記第１中継先ノードが前記中継ノードの親ノードである場合、前記所定条件は、前記第１中継先ノードのバックホールリンクで無線リンク障害が発生したことを示す障害発生通知を前記第１中継先ノードから受信したという条件を含み、
   前記第１中継先ノードが前記中継ノードの子ノードである場合、前記所定条件は、前記第１中継先ノードから受信した情報が示すバッファ量が一定基準を満たすという条件を含む
   中継ノード。
3. 中継元ノードから複数の中継先ノードへデータ中継を行う中継ノードを制御するプロセッサであって、
   ドナー基地局から設定されたルーティング設定と、前記中継元ノードから受信したデータパケットのヘッダに含まれる情報とに従って前記複数の中継先ノードの中から第１中継先ノードを選択する処理と、
   所定条件が満たされた場合、前記複数の中継先ノードの中から、前記第１中継先とは異なる中継先ノードを選択するローカルリルーティングを行う処理と、を実行し、
   前記第１中継先ノードが前記中継ノードの親ノードである場合、前記所定条件は、前記第１中継先ノードのバックホールリンクで無線リンク障害が発生したことを示す障害発生通知を前記第１中継先ノードから受信したという条件を含み、
   前記第１中継先ノードが前記中継ノードの子ノードである場合、前記所定条件は、前記第１中継先ノードから受信した情報が示すバッファ量が一定基準を満たすという条件を含む
   プロセッサ。

Images