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

Description

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

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

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、親ノードと子ノードとの間に介在する中継ノードが、前記親ノード又は前記子ノードから、フロー制御フィードバックメッセージを受信することを有する。また、前記通信制御方法は、前記中継ノードが、前記フロー制御フィードバックメッセージを受信後、一定期間経過したことに応じて、前記フロー制御フィードバックメッセージを送信した前記親ノード又は前記子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行することを有する。

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、親ノードと子ノードとの間に介在する中継ノードが、前記親ノード又は前記子ノードへ、データパケットの転送を試みることを有する。また、前記通信制御方法は、前記中継ノードが、一定期間、前記データパケットの転送ができなかった場合、前記親ノード又は前記子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行することを有する。

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、フロー制御フィードバックメッセージを受信したこと、前記中継ノードと他の中継ノードとの間のバックホールリンク間の障害発生通知を受信したこと、及び一定期間、データパケットの転送ができなかったこと、の少なくとも１つの実行条件が満たされたことに応じて、前記他の中継ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行することを有する。また、前記通信制御方法は、前記中継ノードが、前記ローカルリルーティングを実行後、停止条件が満たされたことに応じて、前記ローカルリルーティングを停止することを有する。

第４の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に第１の中継ノードを有するドナー基地局が、前記第１の中継ノードへ、ローカルリルーティングに関する第１のメッセージを送信することと、前記第１の中継ノードが、前記第１のメッセージの受信に応じて、ローカルリルーティングに関する動作を行うこととを有する。

図１は、一実施形態に係るセルラ通信システムの構成例を表す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を表す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を表す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を表す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を表す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を表す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を表す図である。 図９は、第１実施形態におけるローカルリルーティングの例を表す図である。 図１０は、第１実施形態におけるローカルリルーティングの例を表す図である。 図１１は、第１実施形態の動作例を表す図である。 図１２は、第２実施形態におけるローカルリルーティングの例を表す図である。 図１３は、第２実施形態におけるローカルリルーティングの例を表す図である。 図１４は、第２実施形態における動作例を表す図である。 図１５は、第３実施形態におけるローカルリルーティングの例を表す図である。 図１６は、第３実施形態におけるローカルリルーティングの例を表す図である。 図１７は、第３実施形態における動作例を表す図である。 図１８は、第４実施形態における停止指示の例を表す図である。 図１９は、第４実施形態における停止指示の例を表す図である。 図２０は、第４実施形態における動作例を表す図である。 図２１は、第５実施形態におけるローカルリルーティングの例を図である。 図２２は、第５実施形態の動作例を表す図である。 図２３は、第６実施形態のＩＡＢノードによる通知の例を表す図である。 図２４は、第６実施形態の動作例を表す図である。 図２５は、第７実施形態の動作例を表す図である。 図２６は、第７実施形態の他の動作例を表す図である。 図２７は、第８実施形態の動作例を表す図である。 図２８は、第９実施形態の動作例を表す図である。 図２９は、第１０実施形態における動作例を表す図である。 図３０は、第１１実施形態における動作例を表す図である。 図３１は、第１２実施形態の動作例を表す図である。 図３２は、ＢＨ ＲＬＦ通知のタイプを示す図である。 図３３は、拡張されたＢＨ ＲＬＦインジケーションの送信オプションを示す図である。 図３４は、ＣＨＯの実行に関する図である。 図３５は、子孫ノードへの再確立を回避するための特定されたソリューションを示す図である。 図３６は、ｈｏｐ－ｂｙ－ｈｏｐ ＲＬＣＡＲＱの場合のＵＬデータのロスレス配信のメカニズムの比較を示す図である。 図３７は、「Ｃ）ＵＬステータス配信の導入」のオプションを示す図である。 図３８は、ドナー間のＩＡＢノード移動で発生する可能性のあるＲＡＮ２シグナリングの問題を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

さらに、以下において、ドナーｇＮＢ２００を、ＩＡＢドナー２００と称する場合がある。

（第１実施形態）
セルラ通信システム１では、フロー制御が行われる場合がある。フロー制御により、ＩＡＢノード３００とＩＡＢドナー２００においてパケットドロップに関連した輻輳（ｃｏｎｇｅｓｔｉｏｎ）（又は混雑。以下、「混雑」という場合がある。）を回避することができる。

３ＧＰＰにおけるダウンストリーム方向のフロー制御は、ＢＡＰサブレイヤでサポートされる。ＩＡＢノード３００は、バッファサイズが一定量を超えた場合、又は、フロー制御ポーリングを受信した場合、各ｉｎｇｒｅｓｓ（流入）ＢＨ ＲＬＣチャネルにおいて利用可能なバッファサイズに関するフィードバック情報を、親ノードへ送信する。フィードバック情報は、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを用いて送信される。

アップストリーム方向のフロー制御は、３ＧＰＰでは、とくに規定されておらず、実装依存により、ＭＡＣレイヤ上のＵＬスケジューリングによって（又はＵＬ ｇｒａｎｔによって）行われる、とされる。

他方、セルラ通信システム１では、ローカルリルーティングが行われる場合がある。３ＧＰＰにおいては、ローカルリルーティングは、バックホールリンクでの回線障害（ＢＨ ＲＬＦ（Ｂａｃｋｈａｕｌ Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ））が発生した場合に、代替パス（ａｌｔｅｒｎａｔｉｖｅ ｐａｔｈ）を介してデータパケットが転送される、とされている。一般には、ＩＡＢドナー２００が、各ＩＡＢノード３００に対して、ルーティング設定を行う。そして、各ＩＡＢノード３００は、ルーティング設定に従って、複数の中継ノードからデータパケットを転送する中継ノードを選択する。ローカルリルーティングは、このようなルーティング設定を無視して、上記のように、代替パスを選択することにより行われてもよい。

上記で説明したフロー制御とローカルリルーティングとを組み合わせて、以下のような制御が行われる場合がある。すなわち、ＩＡＢノード３００は、親ノードから、アップリンクフロー制御フィードバック（ＵＬ Ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）メッセージを受信すると、ローカルリルーティング（ｌｏｃａｌ ｒｅｒｏｕｔｉｎｇ）を行う。言い換えると、ＩＡＢノード３００は、当該メッセージを親ノードから受信すると、代替パスを選択し、代替パス上の他の親ノードへ、データパケットを転送する。

しかし、ＩＡＢノード３００は、アップリンクフロー制御フィードバックメッセージを受信して、すぐに、ローカルリルーティングを行うと、当該メッセージを送信した親ノードの混雑状況が改善したにも関わらず、代替パスへのデータパケットが転送される場合がある。

そこで、本第１の実施の形態では、第１に、親ノードと子ノードとの間に介在する中継ノード（例えば、ＩＡＢノード３００）が、親ノード又は子ノードから、フロー制御フィードバックメッセージを受信する。第２に、中継ノードが、フロー制御フィードバックメッセージを受信後、一定期間経過したことに応じて、フロー制御フィードバックメッセージを送信した親ノード又は子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行する。

これにより、例えば、ＩＡＢノード３００は、フロー制御フィードバックメッセージを受信しても、一定期間、親ノード又は子ノードの混雑状況を見ることが可能となる。そのため、ＩＡＢノード３００は、混雑状況が改善すれば、一定期間経過前に、親ノードに対するパスを維持することも可能となる。

図９は、ＩＡＢノード３００－Ｔが、親ノードであるＩＡＢノード３００－Ｐ１からフロー制御フィードバックメッセージを受信した場合のローカルリルーティングの例を表す図である。図９に示すように、ＩＡＢノード３００－Ｔは、ＩＡＢノード３００－Ｐ１から当該メッセージを受信し、一定期間経過後、代替パス上の他の親ノードであるＩＡＢノード３００－Ｐ２へ、データパケットを転送する。なお、この場合のフロー制御フィードバックメッセージは、アップリンクフロー制御フィードバックメッセージとなる。

図１０は、ＩＡＢノード３００－Ｔが、子ノードであるＩＡＢノード３００－Ｃ１からフロー制御フィードバックメッセージを受信した場合のローカルリルーティングの例を表す図である。図１０に示すように、ＩＡＢノード３００－Ｔは、ＩＡＢノード３００－Ｃ１から当該メッセージを受信し、一定期間経過後、代替パス上の他の子ノードであるＩＡＢノード３００－Ｃ２へ、データパケットを転送する。なお、この場合のフロー制御フィードバックメッセージは、ダウンリンクフロー制御フィードバック（ＤＬ Ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）メッセージとなる。

なお、フロー制御フィードバックメッセージは、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵなど、ＢＡＰレイヤのメッセージとして伝送されてもよい。もしくは、フロー制御フィードバックメッセージには、ＭＡＣ ＣＥ及び／又はＲＲＣメッセージが用いられてもよい。

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

ＩＡＢノード３００－Ｔは、ステップＳ１０において、処理を開始すると、ステップＳ１１において、親ノード３００－Ｐ１又は子ノード３００－Ｃ１から、フロー制御フィードバックメッセージを受信する。

ステップＳ１２において、ＩＡＢノード３００－Ｔは、一定期間を測定する。一定期間は、ＩＡＢノード３００－Ｔが、フロー制御フィードバックメッセージを受信してからの期間である。ＩＡＢノード３００－Ｔは、例えば、当該メッセージを受信すると、タイマを起動させて、一定期間を測定する。また、当該一定期間は、ＩＡＢドナー２００又は親ノード３００－Ｐ１により事前に設定されてもよいし、フロー制御フィードバックメッセージに含まれてもよい。ＩＡＢノード３００－Ｔは、例えば、タイマをカウントさせて、そのカウント値が一定期間となったとき、一定期間が満了し、一定期間が経過したと判断する。もしくは、ＩＡＢノード３００－Ｔは、一定期間の計測のために、フロー制御フィードバックメッセージを受信した回数を用いてもよい。すなわち、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１もしくは子ノード３００－Ｃ１からフロー制御フィードバックメッセージを受信すると、カウンタをインクリメントする。ＩＡＢノード３００－Ｔは、当該カウンタ値が閾値に達した場合に一定期間が経過したと判断する。当該閾値は、ＩＡＢドナー２００又は親ノード３００－Ｐ１により事前に設定されてもよいし、フロー制御フィードバックメッセージに含まれてもよい。又は、ＩＡＢノード３００－Ｔは、一定期間の計測のために、これらタイマによる判断とカウンタによる判断とを組み合わせてもよい。つまり、ＩＡＢノード３００－Ｔは、フロー制御フィードバックメッセージを最初に受信した場合にタイマを起動し、カウンタをインクリメントする。当該タイマが満了する前に、当該カウンタ値が閾値に達した場合に、ＩＡＢノード３００－Ｔは、一定期間が経過したと判断する。当該タイマが満了した場合、ＩＡＢノード３００－Ｔは、当該カウンタ値をリセット（つまり、ゼロに設定）する。

ステップＳ１３において、ＩＡＢノード３００－Ｔは、一定期間経過したことに応じて、ローカルリルーティングを実行する。

すなわち、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１からフロー制御フィードバックメッセージを受信して、一定期間経過すると、親ノード３００－Ｐ１に対するパスとは別の代替パスに、データパケットを転送する。当該代替パスは、データパケットの宛先が親ノード３００－Ｐ１に対するパスの場合と同一の代替パスである。また、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃ１からフロー制御フィードバックメッセージを受信して、一定期間経過すると、子ノード３００－Ｃ１に対するパスとは別の代替パスに、データパケットを転送する。当該代替パスは、データパケットの宛先が子ノード３００－Ｃ１に対するパスの場合と同一の代替パスである。当該ローカルリルーティングは、代替パスの選択、及び／又は代替パスへのパケット送信、の処理を含んでもよい。

ステップＳ１４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。

なお、第１実施形態において、ＩＡＢノード３００－Ｔは、ダウンリンクフロー制御フィードバックメッセージを、子ノード３００－Ｃ１から受信すると、一定期間経過することなく、ローカルリルーティングを実行するようにしてもよい。

また、第１実施形態において、フロー制御フィードバックメッセージに代えて、ＢＨ ＲＬＦのＴｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎが用いられてもよい。

Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦを検知したこと（ＲＬＦ ｄｅｔｅｃｔｅｄ）を示す障害発生通知の一例である。また、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦからの回復を試行中であること（Ｔｒｙｉｎｇ ｔｏ ｒｅｃｏｖｅｒ）を示す障害発生通知の一例である。さらに、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎも、障害発生通知の一例であって、Ｔｙｐｅ１ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎとを区別しないときに用いられる通知である。

なお、通知の種類として、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ（ＲＬＦ ｒｅｃｏｖｅｒｅｄ）とＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎ（Ｒｅｃｏｖｅｒｙ ｆａｉｌｕｒｅ）とがある。Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎは、ＩＡＢノード３００－ＴがＢＨ ＲＬＦから回復したことを示す回復通知である。また、Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎは、ＩＡＢノード３００－ＴがＢＨ ＲＬＦからの回復に失敗したことを示す回復失敗通知の一例である。

さらに、第１実施形態において、一定期間が測定されることに代えて、親ノード３００－Ｐ１もしくは子ノード３００－Ｃ１からの希望に応じてローカルリルーティングの実行判断が行われてもよい。例えば、親ノード３００－Ｐ１又は子ノード３００－Ｃ１は、フロー制御フィードバックメッセージに、ローカルリルーティングを実施すべきか否かを示す識別子を含める。ＩＡＢノード３００－Ｔは、当該識別子により、ローカルリルーティングを実施するか否かを決定する。これにより、親ノード３００－Ｐ１もしくは子ノード３００－Ｃ１は、混雑状況に応じて、ＩＡＢノード３００－Ｔのローカルリルーティングを制御することができる。

（第２実施形態）
第２実施形態では、ＩＡＢノード３００が、親ノード又は子ノードへ、例えば、一定期間、データパケットを転送することができなかった場合、ローカルリルーティングを実行する例である。

すなわち、第１に、親ノードと子ノードとの間に介在する中継ノード（例えば、ＩＡＢノード３００）が、親ノード又は子ノードへ、データパケットの転送を試みる。第２に、中継ノードが、一定期間、データパケットの転送ができなかった場合、親ノード又は子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行する。

これにより、例えば、ＩＡＢノード３００は、現在の親ノード又は子ノードに対して見切りをつけて、代替パスにデータパケットを送信することができるため、データパケット転送によるレイテンシを削減させることが可能となる。

図１２は、ＩＡＢノード３００－Ｔに対してアップストリーム方向におけるローカルリルーティングの例を表す図である。ＩＡＢノード３００－Ｔは、一定期間、親ノードであるＩＡＢノード３００－Ｐ１へ、データパケットを転送することができなかった場合、ローカルリルーティングを実行する。すなわち、ＩＡＢノード３００－Ｔは、ＩＡＢノード３００－Ｐ１に対するパスとは異なる代替パス上のＩＡＢノード３００－Ｐ２へ、当該データパケットを転送する。

図１３は、ＩＡＢノード３００－Ｔに対してダウンストリーム方向におけるローカルリルーティングの例を表す図である。ＩＡＢノード３００－Ｔは、一定期間、子ノードであるＩＡＢノード３００－Ｃ１へ、データパケットを転送することができなかった場合、ローカルリルーティングを実行する。すなわち、ＩＡＢノード３００－Ｔは、ＩＡＢノード３００－Ｃ１に対するパスとは異なる代替パス上のＩＡＢノード３００－Ｃ２へ、当該データパケットを転送する。

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

ＩＡＢノード３００－Ｔは、ステップＳ２０において、処理を開始すると、ステップＳ２１において、親ノード３００－Ｐ１又は子ノード３００－Ｃ１へ、データパケットを転送する。

ステップＳ２２において、ＩＡＢノード３００－Ｔは、一定期間、データパケットの転送ができなかった場合、ローカルリルーティングを実行する。

ここで、「一定期間、データパケットの転送ができなかった場合」とは、ＵＬ方向については、例えば、以下がある。

すなわち、

（Ａ１）「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１へ、スケジューリング要求（ＳＲ（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ））を一定回数送信しても、親ノード３００－Ｐ１から、ＵＬ ｇｒａｎｔを受信しなかった場合である。

（Ａ２）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１へ、ＳＲ又はバッファステータスレポート（ＢＳＲ）を送信後、一定時間、ＵＬ ｇｒａｎｔを受信しなかった場合である。

（Ａ３）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔの親ノード３００－Ｐ１に対するＨＡＲＱ／ＲＬＣの再送回数が一定回数に達した場合である。ただし、この場合、ＨＡＲＱ／ＲＬＣの再送回数が一定回数に達した場合であっても、ＲＬＦとなる前が望ましい。

（Ａ４）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔと親ノード３００－Ｐ１との間の無線状態（ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）／ＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ））が一定値を下回った場合である。ただし、当該無線状態が一定値を下回った場合でも、ＲＬＦとなる前が望ましい。

（Ａ５）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、子ノード３００－Ｃ１からデータパケットを受信後、一定期間、当該データパケットを、親ノード３００－Ｐ１へ転送できなかった（又は滞留した）場合である。

また、「一定期間、データパケットの転送ができなかった場合」とは、ＤＬ方向については、例えば、以下がある。

すなわち、

（Ｂ１）「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔの子ノード３００－Ｃ１に対するＨＡＲＱ／ＲＬＣの再送回数が一定回数に達した場合である。

（Ｂ２）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔと子ノード３００－Ｃ１との間の無線状態が一定値を下回った場合である。この場合の無線状態は、子ノード３００－Ｃ１からのｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔによりＩＡＢノード３００－Ｔへ通知される。

（Ｂ３）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１から受信したデータパケットを、一定時間、子ノード３００－Ｃ１へ転送できない（滞留した）場合である。

なお、上記（Ａ１）から（Ｂ３）における「一定回数」、「一定時間」、及び「一定値」は、親ノード３００－Ｐ１又はＩＡＢドナー２００により、設定されてもよい。また、ＩＡＢノード３００－Ｔは、「一定時間」を、内部のタイマを用いて計測してもよい。さらに、「一定回数」、「一定時間」、「一定値」、及びタイマは、ＢＨ ＲＬＣチャネル毎、ＬＣＧ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ）毎、送信元（ｓｏｕｒｃｅ）及び／又は宛先（ｄｅｓｔｉｎａｔｉｏｎ）毎、ルーティングＩＤ毎に、別々に存在又は計測されてもよい。タイマ値とＢＨ ＲＬＣチャネル等が紐づけられていてもよい。

（第３実施形態）
第１実施形態では、ＩＡＢノード３００がフロー制御フィードバックメッセージを受信して一定期間経過後にローカルリルーティングを行う例について説明した。この場合、ＩＡＢノード３００は、フロー制御離脱（ｆｌｏｗ ｃｏｎｔｒｏｌ ｌｅａｖｉｎｇ）フィードバックメッセージを受信した場合、ローカルリルーティングの実行を停止することができる。フロー制御離脱フィードバックメッセージは、当該メッセージを送信したＩＡＢノード３００が混雑状態から、混雑していない通常の状態に戻ったことを通知するためのメッセージである。

他方、第２実施形態では、ＩＡＢノードが自ら判断して、ローカルリルーティングを実行するようにした。

第３実施形態では、第２実施形態において、ローカルリルーティングがＩＡＢノード３００で実行された場合、どのようにローカルリルーティングを停止させるか、についての実施形態である。

すなわち、中継ノード（例えばＩＡＢノード３００）が、ローカルリルーティングを実行後、一定期間経過したことに応じて、ローカルリルーティングを停止する。これにより、例えば、ＩＡＢノード３００が自らの判断で実行を開始したローカルリルーティングを停止させることが可能となる。

図１５は、アップストリーム方向でローカルリルーティングが実行されている場合の例を表す図である。図１５に示すように、ＩＡＢノード３００－Ｔは、代替パス上のＩＡＢノード３００－Ｐ２へ、データパケットを転送して、ローカルリルーティングを行っている。ＩＡＢノード３００－Ｔは、一定期間、ローカルリルーティングを実行すると、ローカルリルーティングを停止する。

図１６は、ダウンストリーム方向でローカルリルーティングが実行されている場合の例を表す図である。この場合も、ＩＡＢノード３００－Ｔは、ＩＡＢノード３００－Ｃ２に対して、一定期間、ローカルリルーティングを実行すると、当該ローカルリルーティングを停止する。

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

ＩＡＢノード３００－Ｔは、ステップＳ３０において、処理を開始すると、ステップＳ３１において、ローカルリルーティングの実行を判断した時からタイマによるカウントを開始する。言い換えると、タイマが作動している間は、ローカルリルーティングが実行されている。そして、ＩＡＢノード３００－Ｔのタイマは、カウント値が所定のタイマ値になるまで、カウント値をカウントする。所定のタイマ値は、例えば、親ノード３００－Ｐ１（又は親ノード３００－Ｐ２）、又はＩＡＢドナー２００により、ＩＡＢノード３００－Ｔに対して設定されてもよい。また、所定のタイマ値は、代替パス毎に設定されてもよい。

ステップＳ３２において、ＩＡＢノード３００－Ｔは、カウント値が所定のタイマ値になった時、すなわち、タイマが満了した時、ローカルリルーティングを停止する。具体的には、ＩＡＢノード３００－Ｔは、ルーティング設定に従ったパスへ、図１５と図１６の例では、親ノード３００－Ｐ１又は子ノード３００－Ｃ１へのパスへ、データパケットを転送することを試みる。

（第４実施形態）
ＩＡＢドナー２００は、配下のＩＡＢノード３００によって構築されたＩＡＢトポロジを管理する。また、ＩＡＢドナー２００は、各ＩＡＢノード３００における混雑状態などを把握することが可能である。

また、上述したように、ＩＡＢドナー２００のＩＡＢ－ＣＵは、各ＩＡＢノード３００のＩＡＢ－ＤＵに対して、ルーティング設定を提供する。提供するルーティング設定には、ルーティングＩＤと次ホップのＢＡＰアドレスとが含まれる。各ＩＡＢノード３００は、データパケットのＢＡＰヘッダに格納されたルーティングＩＤに基づいて、ルーティングを行う。ルーティングＩＤは、（宛先）ＢＡＰアドレスとＢＡＰパスＩＤとから構成される。各ＩＡＢノード３００は、（宛先）ＢＡＰアドレスが自ＢＡＰアドレスと一致するときは、データパケットが目的地に到達したと判定する。他方、各ＩＡＢノード３００は、（宛先）ＢＡＰアドレスが自ＢＡＰアドレスと一致しないときは、ルーティング設定に従って、次ホップのＢＡＰアドレスのＩＡＢノード３００へ、受信したデータパケットを転送する。なお、ＩＡＢドナー２００による、ルーティング設定は、例えば、Ｆ１－ＡＰのＢＡＰ ＭＡＰＰＩＮＧ ＣＯＮＦＩＧＵＲＡＴＩＯＮメッセージにより行われる。

このように、ルーティング設定は、ＩＡＢドナー２００によって、集中管理されている。そして、このようなルーティング設定に従って、ＩＡＢノード３００において、データパケットの転送が可能な状態になった場合、ＩＡＢドナー２００が主導して、ローカルリルーティングを停止させる。これにより、ＩＡＢドナー２００による集中管理にも対応させることが可能となる。第４実施形態は、このように、ＩＡＢドナー２００が、ＩＡＢノード３００において実行中のローカルリルーティングを停止させる例である。

すなわち、第４実施形態は、第１に、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノード（例えば、ＩＡＢノード３００）へ、ローカルリルーティングの停止指示を示す第１のメッセージを送信する。第２に、第１の中継ノードが、第１のメッセージを受信したことに応じて、ローカルリルーティングを停止する。

図１８は、ＩＡＢノード３００－Ｔがアップストリーム方向で、ＩＡＢノード３００－Ｐ２に対して、ローカルリルーティングを実行している例を表している。この場合、ＩＡＢドナー２００のＩＡＢ－ＣＵが、停止指示を示すメッセージを、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵへ送信する。ＩＡＢノード３００－Ｔは、当該メッセージを受信すると、ＩＡＢノード３００－Ｐ２へのローカルリルーティングを停止する。

図１９は、ＩＡＢノード３００－Ｔがダウンストリーム方向で、ＩＡＢノード３００－Ｃ２に対して、ローカルリルーティングを実行している例を表している。この場合も、ＩＡＢノード３００－Ｔは、ＩＡＢドナー２００から停止指示を示すメッセージを受信すると、ＩＡＢノード３００－Ｃ２に対するローカルリルーティングを停止する。

図２０は、第４実施形態における動作例を表す図である。

ＩＡＢノード３００は、ステップＳ４０において、処理を開始すると、ステップＳ４１において、ローカルリルーティングを実行する。

ステップＳ４２において、ＩＡＢドナー２００が、所定状態になったことを契機として、ローカルリルーティングの停止指示を示すメッセージを、ＩＡＢノード３００－Ｔへ送信する。「所定状態」は、ＩＡＢドナー２００がルート毎に負荷（又は混雑）状況をモニタし、負荷が一定値よりも低いパスを検出した場合である。例えば、各ＩＡＢノード３００は、負荷状況を、Ｆ１－ＡＰメッセージ又はＲＲＣメッセージを利用して、ＩＡＢドナー２００に送信する。これにより、ＩＡＢドナー２００は、ルート毎の負荷状況をモニタすることが可能である。ＩＡＢドナー２００は、この負荷状況に基づいて、停止指示を示すメッセージを送信する。停止指示を示すメッセージは、Ｆ１－ＡＰメッセージ又はＲＲＣメッセージにより、送信される。

当該停止指示を示すメッセージには、例えば、以下の情報を含んでもよい。すなわち、ＢＨ ＲＬＣ Ｃｈａｎｎｅｌ ＩＤが当該メッセージに含まれてもよい。この場合、当該ＩＤを有するＢＨ ＲＬＣ Ｃｈａｎｎｅｌが停止指示の対象となる。又は、ＢＨ ＬＣＧ ＩＤが当該メッセージに含まれてもよい。この場合も、当該ＩＤを有するＢＨ ＬＣＧが停止指示の対象となる。又は、宛先ＩＤとパスＩＤとから構成されるルーティングＩＤが当該メッセージに含まれてもよい。この場合、当該ルーティングＩＤのルートが停止指示の対象となる。又は、代替パスＩＤが当該メッセージに含まれてもよい。この場合、代替パスＩＤの代替パスが停止指示の対象となる。当該停止指示を示すメッセージには、上記のようなＩＤ以外にも、停止指示の有効期間が含まれてもよい。この場合、有効期間は、タイマ値などで表されてもよい。

ステップＳ４３において、ＩＡＢノード３００は、ローカルリルーティングの停止指示を示すメッセージを受信したことに応じて、ローカルリルーティングを停止する。ローカルリルーティングの停止は、代替パスへのデータ送信の停止、ルーティング設定に基づいたパス（つまりローカルリルーティング実施以前に使用していたメインパス）の（再）選択、及び当該（再）選択したパスへのデータ送信、のいずれかを含んでもよい。

ステップＳ４４において、ＩＡＢノード３００は、一連の処理を終了する。

なお、第４実施形態における他の例として、ＩＡＢドナー２００は、停止中のローカルリルーティングの開始指示を示すメッセージを、ＩＡＢノード３００へ送信してもよい。この場合、当該メッセージには、開始指示の対象となるルーティングＩＤと代替パスのＩＤとが含まれてもよい。ＩＡＢノード３００は、当該情報によって、どのルーティングＩＤのどの代替パスでローカルリルーティングを開始するかを把握することが可能となる。

また、第４実施形態における他の例として、ＩＡＢドナー２００は、ローカルリルーティングの変更（又は更新）指示を示すメッセージを、ＩＡＢノード３００へ送信してもよい。当該メッセージには、変更対象となるルーティングＩＤと代替パスのＩＤとが含まれてもよい。又は、当該メッセージには、次の優先度（例えば、現在、第１優先度のパスが選択されている場合、第２優先度など）を示すパスへのローカルリルーティングを指示する情報、或いは、ＩＡＢノード３００で現在選択しているパスとは別のパスへのローカルリルーティングを指示する情報が含まれてもよい。

さらに、第４実施形態における他の例として、ＩＡＢドナー２００は、実行中又は停止中のローカルリルーティングの維持又は維持解除の指示を示すメッセージを、ＩＡＢノード３００へ送信してもよい。ＩＡＢノード３００は、実行中又は停止中のローカルリルーティングの維持を示すメッセージを受信した場合、ローカルリルーティングの実行の決定又は停止の決定をそのまま維持する。他方、ＩＡＢノード３００は、実行中又は停止中のローカルリルーティングの維持解除を示すメッセージを受信した場合、ローカルリルーティングの実行の決定又は停止の決定を解除する。さらに、当該維持の有効期間が設定されてもよい。つまり、ＩＡＢノード３００は、当該維持を示すメッセージを受信した場合にタイマを起動する。タイマが作動中は、ＩＡＢノード３００は、ローカルリルーティングの実行又は停止の決定（状態）を維持する。ＩＡＢノード３００は、タイマが満了した場合、ローカルリルーティングの実行又は停止の決定（状態）を維持しなくてもよい。言い換えると、ＩＡＢノード３００は、ローカルリルーティングの実施又は停止の決定を行うことができる。当該タイマ値は、ＩＡＢドナー２００又は親ノードにより事前に設定されていてもよく、当該維持を示すメッセージによって設定されてもよい。

以上、他の例として説明したメッセージは、例えば、Ｆ１－ＡＰメッセージ又はＲＲＣメッセージとして送信される。

（第５実施形態）
第４実施形態では、ＩＡＢドナー２００が、ＩＡＢノード３００に対して、ローカルリルーティングの開始を明示的に指示する例について説明した。第５実施形態では、ローカルリルーティングを各ＩＡＢノード３００で行うことを決定する際のアシスト情報として、ＩＡＢドナー２００が、各ＩＡＢノード３００へ、各ＩＡＢノード３００のダウンストリーム方向でのＢＨ ＲＬＦを通知する例である。

一般には、ＩＡＢノード３００のＩＡＢ－ＭＴは、ＩＡＢノードのアップストリーム方向におけるＢＨの無線リンク障害（ＢＨ ＲＬＦ）を検出する。そのため、ＩＡＢノード３００では、ダウンストリーム方向のＢＨ ＲＬＦを検出する手段が基本的にはない。

第５実施形態では、ＩＡＢノード３００は、ＩＡＢドナー２００から、自ノード３００のダウンストリーム方向のＢＨ ＲＬＦの発生の通知を受けることで、ローカルリルーティングを実行することが可能となる。このような通知が、ＩＡＢノード３００において、ダウンストリーム方向に対するローカルリルーティングの決定のアシストとなり得る。

すなわち、第５実施形態では、第１に、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノードへ、第１のメッセージを送信する。第１のメッセージは、第１の中継ノードから第１の中継ノード配下の第２の中継ノードへのダウンストリーム方向におけるバックホールリンクにおいて無線リンク障害が発生していることを示す。第２に、第１の中継ノードが、第１のメッセージを受信したことに応じて、ローカルリルーティングを実行する。

図２１は、第５実施形態におけるローカルリルーティングの例を図である。ＩＡＢドナー２００は、ＩＡＢノード３００－Ｔのダウンストリーム方向におけるＢＨ ＲＬＦを検出すると、当該ＩＡＢノード３００－Ｔに対して、ＤＬ ＢＨ ＲＬＦの発生を通知する。ＩＡＢドナー２００は、例えば、ＩＡＢノード３００－Ｔの子ノードであるＩＡＢノード３００－Ｃからｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔを受信した場合に、ＩＡＢノード３００－ＴにおけるＤＬ ＢＨ ＲＬＦを検出した、と判断してもよい。そして、ＩＡＢドナー２００は、ＩＡＢノード３００－Ｔへ、ＩＡＢノード３００－ＴにおけるＤＬ ＢＨ ＲＬＦ発生を通知する。ＩＡＢノード３００－Ｔは、ＤＬ ＢＨ ＲＬＦの発生の通知を受信すると、ローカルリルーティングを行い、代替パス上の他の子ノードへ、データパケットを転送する。

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

ＩＡＢドナー２００は、ステップＳ５０において、処理を開始すると、ステップＳ５１において、ＩＡＢノード３００－ＴにおけるＤＬ方向のＲＬＦを検知する。例えば、ＩＡＢドナー２００のＩＡＢ－ＣＵは、ＩＡＢノード３００－Ｔの子ノード３００－ＣのＩＡＢ－ＭＴから、ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔを受信することで、ＩＡＢドナー２００は、ＩＡＢノード３００－ＴにおけるＤＬ ＢＨ ＲＬＦを検知してもよい。又は、例えば、子ノード３００－Ｃにおいて、ＩＡＢノード３００－Ｔと他のＩＡＢノードとでＤＣ（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）が行われている場合、ＩＡＢドナー２００は、子ノード３００－Ｃから、ＭＣＧ（Ｍａｓｔｅｒ Ｃｅｌｌ Ｇｒｏｕｐ） Ｆａｉｌｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎ及び／又はＳＣＧ（Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ Ｇｒｏｕｐ） Ｆａｉｌｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎを受信する。これにより、ＩＡＢドナー２００は、ＩＡＢノード３００－ＴにおけるＤＬ ＢＨ ＲＬＦを検知してもよい。

ステップＳ５２において、ＩＡＢドナー２００は、当該ＩＡＢノード３００－Ｔへ、ＤＬ ＢＨ ＲＬＣが発生していることを通知する。例えば、ＩＡＢドナー２００のＩＡＢ－ＣＵが、ＩＡＢノード３００のＩＡＢ－ＤＵへ、ＲＲＣメッセージ又はＦ１－ＡＰメッセージを用いて、当該通知を送信してもよい。

ステップＳ５３において、当該ＩＡＢノード３００－Ｔは、当該通知の受信に応じて、所定の動作を行う。所定の動作として、ローカルリルーティングがある。すなわち、ＩＡＢノード３００－Ｔは、当該ＤＬ ＢＨ ＲＬＦが発生しているリンク（又は子ノード３００－Ｃ）に対して、ローカルリルーティングによって、代替パス上の他の子ノードへ、データパケットを転送する。また、所定の動作として、ＤＬ送信の停止がある。すなわち、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃに対するデータパケットの送信を停止する。

ステップＳ５４において、ＩＡＢノード３００（とＩＡＢドナー２００）は一連の動作を終了する。

なお、第５実施形態の他の例として、ＩＡＢドナー２００は、ＩＡＢノード３００－ＴにおけるＤＬ ＢＨ ＲＬＦが回復したことを検知した場合、当該ＩＡＢノード３００－Ｔへ、ＤＬ ＢＨ ＲＬＦが回復した旨を通知してもよい。例えば、ＩＡＢドナー２００のＩＡＢ－ＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵへ、ＲＲＣメッセージ又はＦ１－ＡＰメッセージを利用して、ＤＬ ＢＨ ＲＬＦが回復した旨を通知するようにしてもよい。

（第６実施形態）
第６実施形態は、ＩＡＢノード３００がローカルリルーティングの実行開始又は実行停止を判断した場合、ＩＡＢドナー２００へ通知する例である。すなわち、第１に、第１の中継ノード（例えば、ＩＡＢノード３００）が、ローカルリルーティングの実行開始又は実行停止を判断したことを示す第２のメッセージをドナー基地局（例えば、ＩＡＢドナー２００）へ送信する。

これにより、例えば、ＩＡＢドナー２００は、ＩＡＢノード３００において、ローカルリルーティングが行われているのか否かを把握することができる。そして、ＩＡＢドナー２００は、第４実施形態で説明した、実行中のローカルリルーティングの停止又は開始を、ＩＡＢノード３００へ指示することが可能となる。

図２３は、ＩＡＢノード３００－Ｔによる通知の例を表す図である。図２３は、ＩＡＢノード３００－Ｔのダウンストリーム方向におけるローカルリルーティングの実行を判断した場合の例である。

図２３に示すように、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃ１から子ノード３００－Ｃ２へのローカルリルーティングの実行開始又は実行停止を判断すると、ＩＡＢドナー２００へ、その旨を示すメッセージを送信する。

この場合、ＩＡＢドナー２００は、必要に応じて、当該メッセージの受信に応じて、ＩＡＢノード３００－Ｔにおけるローカルリルーティングの実行開始又は実行停止の許可又は禁止を指示するメッセージを、当該ＩＡＢノード３００－Ｔへ送信してもよい。

当該ＩＡＢノード３００－Ｔは、許可又は禁止を指示するメッセージの受信に応じて、ローカルリルーティングの実行を開始又は停止する。具体的には、例えば、以下となる。

すなわち、当該ＩＡＢノード３００－Ｔは、実行開始を判断したことに対して、ＩＡＢドナー２００から実行開始の許可を示すメッセージを受信すると、当該メッセージの受信に応じて、ローカルリルーティングの実行を開始する。また、当該ＩＡＢノード３００－Ｔは、実行開始を判断したことに対して、ＩＡＢドナー２００から実行開始の禁止を示すメッセージを受信すると、当該メッセージの受信に応じて、ローカルリルーティングを実行しない。さらに、当該ＩＡＢノード３００－Ｔは、実行停止を判断したことに対して、ＩＡＢドナー２００から実行停止の許可を示すメッセージを受信すると、当該メッセージの受信に応じて、実行中のローカルリルーティングを停止する。さらに、当該ＩＡＢノード３００－Ｔは、実行停止を判断したことに対して、ＩＡＢドナー２００から実行停止の禁止を示すメッセージを受信すると、当該メッセージの受信に応じて、実行中のローカルリルーティングを停止することなく、実行を継続する。

なお、図２３の例では、ＩＡＢノード３００－Ｔにおけるダウンストリーム方向のローカルリルーティングの実行開始の例を表しているが、ＩＡＢノード３００－Ｔにおけるアップストリーム方向のローカルリルーティングの実行開始の場合であってもよい。

図２４は、第６実施形態の動作例を表す図である。

ＩＡＢノード３００－Ｔは、ステップＳ６０において、処理を開始すると、ステップＳ６１において、ローカルリルーティングの実行開始又は実行停止を判断した場合、ＩＡＢドナー２００へ、メッセージを送信する。

当該メッセージには、第１に、どのルートがローカルリルーティングの対象になったのかを示す情報が含まれてもよい。具体的には、当該情報は、ＢＨ ＲＬＣ Ｃｈａｎｎｅｌ ＩＤであってもよい。又は、当該情報は、ＢＨ ＬＣＧ ＩＤであってもよい。又は、当該情報は、宛先ＩＤとパスＩＤとからなるルーティングＩＤであってもよい。

また、当該メッセージには、第２に、どのルートへのローカルリルーティングが行われたのかを示す情報が含まれてもよい。具体的には、当該情報は、代替パスＩＤであってもよい。この場合、代替パスＩＤは、ルーティングＩＤ又はパスＩＤにより表されてもよい。

さらに、当該メッセージには、第３に、なぜ、ローカルリルーティングの実行を開始又は停止したのかを示す情報（理由情報）が含まれてもよい。具体的には、当該情報は、ＢＨ ＲＬＦのＴｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎの受信によるものであってもよい。又は、当該情報は、フロー制御フィードバックメッセージ又はフロー制御離脱フィードバックメッセージの受信によるものであってもよい。又は、当該情報は、フロー制御フィードバックメッセージ又はフロー制御離脱フィードバックメッセージを受信して一定期間経過したことであってもよい。又は、当該情報は、データパケットの転送不能によるもの（又は第２実施形態における、一定期間、データパケットの転送ができなかった場合のよるもの）であってもよい。又は、当該情報は、親ノードからの指示によるものであってもよい。

当該メッセージは、ＲＲＣメッセージ又はＦ１－ＡＰメッセージとして送信されてもよい。

ステップＳ６２において、ＩＡＢドナー２００は、当該ＩＡＢノード３００－Ｔに対して、許可又は禁止を示すメッセージを送信してもよい。この場合、ＩＡＢドナー２００は、ローカルリルーティングの実行開始の許可を示すメッセージを送信する場合、当該メッセージに、ローカルリルーティング先のルーティングＩＤ又はパスＩＤを指示してもよい。当該メッセージも、ＲＲＣメッセージ又はＦ１－ＡＰメッセージとして送信されてもよい。

当該ＩＡＢノード３００－Ｔは、上述したように、許可又は禁止を示すメッセージの受信に応じて、ローカルリルーティングの実行を開始したり、実行しなかったりすることができる。

なお、ステップＳ６１においては、ＩＡＢノード３００は、ローカルリルーティングの実行を判断した場合、ＩＡＢドナー２００に対するメッセージの送信により、ＩＡＢドナー２００に対して、ローカルリルーティング実行のお伺いを立てることとしてもよい。ＩＡＢドナー２００は、ステップＳ６２において、そのお伺いに対して、ＩＡＢノード３００に対して、許可又は禁止を指示することになる。

（第７実施形態）
第７実施形態は、ＩＡＢノード３００において、複数の実行条件を組み合わせて、ローカルリルーティングの実行又は停止の判断が行われる例である。

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、フロー制御フィードバックメッセージを受信したこと、中継ノードと他の中継ノードとの間のバックホールリンク間の障害発生通知を受信したこと、及び一定期間、データパケットの転送ができなかったこと、の少なくとも１つの実行条件が満たされたことに応じて、他の中継ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行する。第２に、中継ノードが、ローカルリルーティングを実行後、停止条件が満たされたことに応じて、ローカルリルーティングを停止する。

複数の実行条件を組み合わせて、ローカルリルーティングの実行又は停止が判断されることで、ネットワーク毎の実装（インプリメンテーション）や展開（デプロイメント）の柔軟性を高めることが可能となる。

図２５は、第７実施形態の動作例を表す図である。

ＩＡＢノード３００は、ステップＳ７０において、処理を開始すると、ステップＳ７１において、１つ以上の実行条件に合致した場合、ローカルリルーティングを実行する。

実行条件としては、例えば、以下の３つがある。

（Ｃ１）フロー制御フィードバックメッセージを受信したこと、又は、フロー制御フィードバックメッセージを受信して一定期間経過したこと（第１実施形態）。

（Ｃ２）ＢＨ ＲＬＦのＴｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信したこと。

（Ｃ３）一定期間、データパケットの転送ができなかったこと（第２実施形態）。

ＩＡＢノード３００は、３つの実行条件のうち、少なくとも１つの実行条件に合致する状況となった場合に、ローカルリルーティングを実行する。

ステップＳ７２において、ＩＡＢノード３００は、停止条件に合致した場合、ローカルリルーティングを停止する。

停止条件としては、例えば、ＢＨ ＲＬＦのＴｙｅｐ３ Ｉｎｄｉｃａｔｉｏｎの受信である。ＩＡＢノード３００は、ステップＳ７１でローカルリルーティングを開始しても、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信したことに応じて、ローカルリルーティングを停止する。

ステップＳ７３において、ＩＡＢノード３００は、一連の処理を終了する。

図２６は、第７実施形態の他の動作例を表す図である。

ＩＡＢノード３００は、ステップＳ８０において、処理を開始すると、ステップＳ８１において、ある実行条件に合致した場合、ローカルリルーティングを実行する。実行条件は、上記の（Ｃ１）から（Ｃ３）の３つの実行条件のすくなくともいずれか１つである。

ステップＳ８２において、ＩＡＢノード３００は、実行条件に対応する停止条件に合致した場合、ローカルリルーティングを停止する。実行条件に対応する停止条件とは、例えば、「フロー制御フィードバックメッセージを受信したこと」という実行条件に対して、「フロー制御離脱フィードバックメッセージを受信したこと」である。例えば、ＩＡＢノード３００は、ステップＳ８１において、「フロー制御フィードバックメッセージを受信したこと」という実行条件により、ローカルリルーティングを開始したとする。このような場合、ＩＡＢノード３００は、「フロー制御離脱フィードバックメッセージを受信したこと」という停止条件に合致すればローカルリルーティングを停止する。この場合、実行条件に対応する停止条件は、実行条件とは反対の内容の条件であると言うこともできる。他方、ＩＡＢノード３００は、「フロー制御フィードバックメッセージを受信したこと」という実行条件により、ローカルリルーティングを開始したとする。このような場合、ＩＡＢノード３００は、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信しても、実行条件に対応する停止条件に合致しないため、ローカルリルーティングを停止することなく、実行を継続する。これは、「Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信したこと」は、「フロー制御フィードバックメッセージを受信したこと」という実行条件に対応しない停止条件だからである。

ステップＳ８３において、ＩＡＢノード３００は、一連の処理を終了する。

（第８実施形態）
第７実施形態では、ローカルリルーティングに関する複数の実行条件について説明した。第８実施形態は、ＩＡＢドナー２００が、ＩＡＢノード３００に対して、複数の実行条件の中から当該ＩＡＢノード３００が用いる実行条件を設定する例である。具体的には、中継ノード（例えば、ＩＡＢノード３００）を配下に有するドナー基地局（例えば、ＩＡＢドナー２００）が、複数の実行条件を中継ノードに設定する。

図２７は、第８実施形態の動作例を表す図である。

ＩＡＢドナー２００は、ステップＳ９０において、処理を開始すると、ステップＳ９１において、ＩＡＢノード３００に対して、ローカルリルーティングの複数の実行条件の中から当該ＩＡＢノード３００が用いる実行条件を設定する。設定される実行条件は、

（Ｄ１）ＢＨ ＲＬＦのＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎを受信したこと。

（Ｄ２）ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信したこと。

（Ｄ３）ダウンリンクフロー制御フィードバックメッセージ、又はアップリンクフロー制御フィードバックメッセージを受信したこと。

（Ｄ４）一定期間、データパケットを転送することができなかったこと（第２実施形態）。

（Ｄ５）上記（Ｄ１）から（Ｄ４）に関連する閾値、タイマ値、及び回数上限値、のうちの１つ又は複数である。また、ＩＡＢドナー２００は、第７実施形態で説明した停止条件を、ＩＡＢノード３００に設定してもよい。

設定は、例えば、ＩＡＢドナー２００が、１つ又は複数の実行条件（と停止条件）を含むＲＲＣメッセージ又はＦ１－ＡＰメッセージをＩＡＢノード３００へ送信することにより行われる。

ステップＳ９２において、ＩＡＢノード３００は、設定された実行条件（又は停止条件）に合致する状況となった場合、ローカルリルーティングを開始（又は停止）する。ＩＡＢノード３００は、複数の実行条件（又は停止条件）が設定された場合、そのうちの１以上の実行条件に合致する状況になると、ローカルリルーティングを開始（又は停止）する。

ステップＳ９３において、ＩＡＢノード３００は、一連の処理を終了する。

（第９実施形態）
第９実施形態は、ＩＡＢドナー２００において、ローカルリルーティングにおける代替パスの設定が行われる例である。

ローカルリルーティングについて、ＩＡＢノード３００による分散制御ではなく、ＩＡＢドナー２００による中央集権的な制御により行われるべきという議論がある。ＩＡＢトポロジ全体を把握するのはＩＡＢドナー２００であり、ＩＡＢドナー２００によりルーティング設定が最適化されている、という理由からである。そのため、ローカルリルーティングにおける代替パスについても、ＩＡＢドナー２００が、設定できるようにすべきという議論がある。具体的には、ＩＡＢドナー２００が、同一のルーティングＩＤ（宛先アドレス＋パスＩＤ）に対して、別のパスをＩＡＢノード３００に割り振る、という議論である。

第９実施形態は、ＩＡＢドナー２００による代替パスの設定、具体的は、ＩＡＢドナー２００がルーティング設定により設定したルーティングＩＤと、代替パスのルーティングＩＤとを紐づけて設定する例である。

すなわち、第１に、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノード（例えば、ＩＡＢノード３００）に対して、メインパスに関する情報と対応付けられた代替パスに関する情報を含む代替パスの設定を行う。第２に、第１の中継ノードが、代替パスの設定に基づいて、代替パスを選択する。

図２８は、第９実施形態の動作例を表す図である。

ＩＡＢドナー２００は、ステップＳ１００において、処理を開始すると、ステップＳ１０１において、ＩＡＢノード３００に対して、メインパスに加え、代替パス（ａｌｔｅｒｎａｔｉｖｅ ｐａｔｈ（ｓ））を設定する。

メインパスは、例えば、第４実施形態で説明した、ＩＡＢドナー２００によるルーティング設定により、ＩＡＢノード３００に設定されたパスである。ＩＡＢドナー２００は、予め、ルーティング設定により、各ＩＡＢノード３００に対するメインパスが設定されている。また、代替パスは、例えば、ＩＡＢノード３００においてローカルリルーティングが行われる際に選択されるパスである。図１８及び図１９の例では、メインパスは、ＩＡＢノード３００－ＴからＩＡＢノード３００－Ｐ１又は３００－Ｃ１へのパスとなり、代替パスは、ＩＡＢノード３００－ＴからＩＡＢノード３００－Ｐ２又は３００－Ｃ２へのパスとなる。

図２８に戻り、ステップＳ１０１において、ＩＡＢドナー２００は、Ｆ１－ＡＰのＢＡＰ ＭＡＰＰＩＮＧ ＣＯＮＦＩＧＵＲＡＴＩＯＮ（ＢＡＰマッピング設定）メッセージ、又はＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ（ＲＲＣ設定）メッセージに、代替パスに関する情報を含ませて、ＩＡＢノード３００へ送信する。これにより、ＩＡＢドナー２００は、ＩＡＢノード３００に対して代替パス設定を行う。

代替パスに関する情報は、複数の代替パスに対応して、複数の情報を含んでもよい。

代替パスに関する情報は、第１に、メインパスのルーティングＩＤと、代替パスのルーティングＩＤとの紐づけ情報を含む。例えば、代替パスに関する情報に、代替パスのルーティングＩＤがあり、そのルーティングＩＤに対応させてメインパスのルーティングＩＤが指定されることで、紐付け（又は対応付け）が行われてもよい。又は、紐づけ情報として、例えば、グルーピングＩＤが用いられてもよい。グルーピングＩＤは、メインパスのパスＩＤと代替パスのパスＩＤとをグルーピング化するために定義されたＩＤである。グルーピングＩＤにより、メインパスのルーティングＩＤと、代替パスのルーティングＩＤとが紐づけられる。

代替パスに関する情報は、第２に、代替パスの宛先ＩＤを含む。代替パスの宛先ＩＤは、メインパスの宛先ＩＤと同じである。ただし、ドナーＤＵ間リルーティング（ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ ｒｅｒｏｕｔｉｎｇ）が行われる場合（第１２実施形態）は、２つの宛先ＩＤは異なってもよい。

代替パスに関する情報は、第３に、代替パスのパスＩＤを含む。代替パスのパスＩＤは、メインパスのパスＩＤと異なってもよいし、同じであってもよい。代替パスのパスＩＤとメインパスのパスＩＤとが同じ場合、ルーティングＩＤ毎に、次ホップＢＡＰアドレス（Ｎｅｘｔ Ｈｏｐ ＢＡＰ Ａｄｄｒｅｓｓ）のリストが設定されてもよい。この場合、当該リストの先頭エントリが、メインパスの次ホップＢＡＰアドレス、２番目以降が、代替パスの次ホップＢＡＰアドレスと識別されてもよい。又は、当該リストのエントリの順番が、次ホップＢＡＰアドレスの優先順位を表してもよい。

代替パスに関する情報は、第４に、代替パスのルーティングＩＤを含む。

代替パスに関する情報は、さらに、以下の情報を含んでもよい。すなわち、代替パスに対応して（又は紐づいて）、

（Ｅ１）次ホップＢＡＰアドレス（Ｎｅｘｔ Ｈｏｐ ＢＡＰ Ａｄｄｒｅｓｓ）

（Ｅ２）ＩＡＢドナーＤＵ ＢＡＰアドレス（ＩＡＢ－ｄｏｎｏｒ－ＤＵ ＢＡＰ ａｄｄｒｅｓｓ）

（Ｅ３）セルＩＤ

（Ｅ４）流出ＢＨ ＲＬＣチャンネルＩＤ（Ｅｇｒｅｓｓ ＢＨ ＲＬＣ ＣＨ ＩＤ）

（Ｅ５）流入ＢＨ ＲＬＣチャンネルＩＤ（Ｉｎｇｒｅｓｓ ＢＨ ＲＬＣ ＣＨ ＩＤ）
の全部又は一部が含まれてもよい。

また、代替パスに関する情報は、さらに、以下の情報を含んでもよい。すなわち、代替パスに対応して（又は紐づいて）、

（Ｆ１）優先度設定

（Ｆ２）選択確率設定

（Ｆ３）有効期間を示すタイマ値と禁止期間を示すタイマ値
の全部又は一部が含まれてもよい。

上記（Ｆ１）の優先度設定は、優先度が高い順に代替パスが選択されるようにする設定情報である。例えば、複数の代替パスの優先度「１」、「２」、…が設定情報に含まれる場合、ＩＡＢノード３００は、ローカルリルーティングを行う際は、優先度「１」の代替パスを選択し、パケット転送を試みる。その結果、パケットを転送できなかった場合、ＩＡＢノード３００は、優先度「２」の代替パスを選択する。又は、設定情報に以下の情報が含まれる場合、優先度設定がなくてもよい。
（Ｇ１）Ｉｎｔｒａ－ｄｏｎｏｒ－ＤＵ（ドナーＤＵ内）の代替パス（メインパスと代替パスとが同一のドナーＤＵ内に存在する）
（Ｇ２）Ｉｎｔｒａ－ｄｏｎｏｒ（ドナー内）の代替パス（メインパスと代替パスとが同一のドナー内に存在する）
（Ｇ３）Ｉｎｔｅｒ－ｄｏｎｏｒ（ドナー間）の代替パス（メインパスと代替パスとが異なるドナーに存在する）
この場合、ＩＡＢノード３００は、ドナーＤＵ内の代替パス、ドナー内の代替パス、ドナー間の代替パスの順番で、代替パスを選択してもよい。

上記（Ｆ２）の選択確率設定は、代替パス毎にパーセント又は真数（０から１）で表示された選択確率である。例えば、ＩＡＢノード３００は、乱数を用いて、乱数値と選択確率とに基づいて、代替パスを選択する。例えば、代替パスが３つあり、各選択確率が｛０．５，０．３，０．２｝であるとする。この場合、ＩＡＢノード３００は、乱数値が０．４の場合、１つ目の選択確率を有する代替パスを選択し、乱数値が０．７の場合、２つ目の選択確率を有する代替パスを選択し、乱数値が０．９の場合、３つ目の選択確率を有する代替パスを選択する。なお、選択確率の合計値は、１００％（又は１）となることが望ましい。

上記（Ｆ３）は、代替パス毎に設定された有効期間を示すタイマ値と、禁止期間を示すタイマ値とである。例えば、以下のようにタイマ値が用いられる。

すなわち、ＩＡＢノード３００は、ローカルリルーティングにより代替パスを選択した時、又は当該代替パスにパケット転送を開始した時、タイマによるカウントを開始する。そして、ＩＡＢノード３００は、当該タイマによるカウント値が、有効期間を示すタイマ値に達していないとき（ランニングの間）、選択した代替パスを使用することができる。他方、ＩＡＢノード３００は、当該タイマによるカウント値が、有効期間を示すタイマ値に達した時（タイマが満了した時）、当該代替パスの使用を停止（又は禁止）する。そして、ＩＡＢノード３００は、実行したローカルリルーティングの終了（又は停止或いは禁止）後、タイマによるカウントを開始する。そして、ＩＡＢノード３００は、当該カウント値が、禁止期間を示すタイマ値に達していないとき（ランニングの間）、終了した代替パスの使用を禁止する。当該代替パスは選択候補から外され、ローカルリルーティングが継続している間、他の代替パスが選択される。他方、当該カウント値が、禁止期間を示すタイマ値に達した時（タイマが満了した時）、ＩＡＢノード３００において、終了した代替パスの使用が可能となる。当該代替パスは、代替パスの選択候補となり得る。

ステップＳ１０２において、ＩＡＢノード３００は、ローカルリルーティングを行う際、ＩＡＢドナー２００により設定された代替パス設定に基づいて、代替パスを選択し、パケット転送を試みる。

ステップＳ１０３において、ＩＡＢノード３００は、一連の処理を終了する。

（第１０実施形態）
ＩＡＢノード３００において、ローカルリルーティングが行われている場合、ＩＡＢドナー２００は、トポロジ全体のパフォーマンスが落ちている等の理由で、ルーティング設定を変更する場合がある。第１０実施形態は、ルーティング設定が変更された場合、ローカルリルーティングの動作を停止（又はキャンセル）する例である。

具体的には、第１に、第１の中継ノード（例えば、ＩＡＢノード３００）が、ローカルリルーティングを開始する。第２に、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノードへ、第１の中継ノードに設定されたルーティング設定を更新することを示す第１のメッセージを送信する。第３に、第１の中継ノードが、第１のメッセージを受信したことに応じて、ローカルリルーティングを停止する。

図２９は、第１０実施形態における動作例を表す図である。

ＩＡＢノード３００は、ステップＳ１１０において、処理を開始すると、ステップＳ１１１において、ローカルリルーティングを開始する。

ステップＳ１１２において、ＩＡＢドナー２００は、トポロジ全体のパフォーマンス低下を検出した等の理由で、ＩＡＢノードのルーティング設定を更新する。例えば、ＩＡＢドナー２００は、ＩＡＢノード３００から、ＩＡＢノード３００における負荷が上昇しているなどの負荷状況を示すメッセージを受信したことにより、トポロジ全体のパフォーマンス低下を検出してもよい。そして、ＩＡＢドナー２００は、設定更新を示すメッセージを、配下の全ＩＡＢノード３００へ送信する。当該メッセージは、Ｆ１－ＡＰメッセージ又はＲＲＣメッセージであってもよい。

ステップＳ１１３において、ＩＡＢノード３００は、設定更新を示すメッセージの受信に応じて、ローカルリルーティングを停止する。例えば、ＢＦ ＲＬＦのＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの受信によりローカルリルーティングが開始されたとする。このような場合、「停止」は、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを待つことなく、「停止」するとともに、ＩＡＢノード３００におけるＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎの受信を予期しなくてもよい、という意味である。

ステップＳ１１４において、ＩＡＢノード３００は、一連の処理を終了する。

（第１１実施形態）
ＩＡＢノード３００が、ローカルリルーティングにより代替パスを選択しても、選択した代替パスが、選択する前のパスよりも、混雑している場合もあり得る。これでは、データパケット転送の遅延が増加し、トポロジ全体のパフォーマンスが低下する場合がある。

第１１実施形態は、ＩＡＢドナー２００が、ＩＡＢノード３００へ、各パスの負荷情報を送信する例である。具体的には、第１に、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノード（例えば、ＩＡＢノード３００）へ、第１の中継ノードと第２の中継ノードとの間のパスの負荷情報を含む第１のメッセージを送信する。第２に、第１の中継ノードが、負荷情報に基づいて、ローカルリルーティングを実行又は停止する。

ＩＡＢドナー２００が、ＩＡＢノード３００へ、各パスの負荷情報を送信することで、ＩＡＢノード３００では、ローカルリルーティングが行われる際に、負荷状況が良好な代替パスを選択することができる。これにより、データパケット転送遅延を防止し、トポロジ全体のパフォーマンス低下を防止させることが可能となる。

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

ＩＡＢドナー２００は、ステップＳ１２０において、処理を開始すると、ステップＳ１２１において、各パスの負荷情報を含むメッセージを、ＩＡＢノード３００へ送信する。

ＩＡＢドナー２００が当該メッセージを送信する契機は、例えば、以下がある。すなわち、ＩＡＢドナー２００は、周期的（ｐｅｒｉｏｄｉｃ）に当該メッセージを送信してもよい。又は、ＩＡＢドナー２００は、ＩＡＢノード３００から要求があったときに、当該メッセージを送信してもよい。この場合の「要求」は、例えば、ＩＡＢノード３００でローカルリルーティングに関する判断を行ったときに、当該判断に応じて、ＩＡＢノード３００から送信された要求のことである。又は、ＩＡＢドナー２００は、自身が必要と判断したときに、当該メッセージを送信する。「必要と判断したとき」とは、例えば、あるパスの負荷が顕著に上がったときである。ＩＡＢドナー２００は、パス上のＩＡＢノード３００から負荷情報を取得できるため、この負荷情報に基づいて、あるパスの負荷が短時間で閾値以上に上がったときに、負荷が顕著に上がったと判断してもよい。

また、ＩＡＢドナー２００が送信する、「各パスの負荷情報」を含むメッセージに含まれる、「各パスの負荷情報」は、例えば、ルーティングＩＤ毎の負荷レベル、又は、パスＩＤ毎の負荷レベルである。この場合、負荷レベルは、例えば、０～１００％の百分率で表示される。

なお、「負荷情報」に代えて、パスに対する優先度情報が通知されてもよい。ＩＡＢドナー２００は、負荷が低いパスの優先度を上げることが可能である。これにより、ＩＡＢノード３００では、負荷の低いパスを代替パスとして選択する可能性を高くすることが可能となる。なお、優先度情報を含むメッセージの送信により、例えば、ＩＡＢノード３００において設定された優先度情報を更新させることが可能となる。したがって、例えば、ＩＡＢドナー２００は、あるパスの負荷が高くなったことを検出すると、優先度情報の更新によって、ＩＡＢノード３００に設定された、当該パスの優先度を低く設定することも可能となる。これにより、ＩＡＢドナー２００によるルーティング設定により設定された各パスの優先度情報に対して、ステップＳ１２１によるメッセージの送信によって、その優先度情報を更新させることが可能となる。ステップＳ１２１におけるメッセージを用いた優先度情報の更新は、ルーティング設定による設定と比較して、高頻度に行うことが可能となる。

ステップＳ１２２において、ＩＡＢノード３００は、負荷情報を用いて、所定の動作を行う。

所定の動作として、第１に、ローカルリルーティングの実行又は停止の判断がある。例えば、ＩＡＢノード３００は、現在使用しているパスがメインパスであって、負荷情報により示されたメインパスの負荷が一定値を超えた場合、ローカルリルーティングを実行すると判断する。また、例えば、ＩＡＢノード３００は、現在使用しているパスが代替パスであって、負荷情報により示された代替パスの負荷が一定値を超えた場合、ローカルリルーティングを停止すると判断する。負荷情報に代えて優先度情報が用いられる場合は、ＩＡＢノード３００は、現在使用しているメインパスの優先度情報が、優先度閾値より低い場合、ローカルリルーティングを実行すると判断する。他方、ＩＡＢノード３００は、現在使用している代替パスの優先度情報が、優先度閾値より低い場合、ローカルリルーティングを停止する。当該一定値又は優先度閾値は、ＩＡＢドナー２００により設定されてもよい。

また、所定の動作として、第２に、代替パスの選択がある。例えば、ＩＡＢノード３００は、ローカルリルーティングを実行する際に、負荷情報を用いて、以下の基準で代替パスを選択する。すなわち、ＩＡＢノード３００は、負荷情報に示された負荷の中で、最も負荷が低いパスを、代替パスとして選択する。或いは、ＩＡＢノード３００は、負荷が一定以下のパスから任意に選択してもよい。負荷情報に代えて、優先度情報が用いられる場合は、ＩＡＢノード３００は、優先度情報に示された優先度の中で、最も優先度が高いパスを、代替パスとして選択する。或いは、ＩＡＢノード３００は、優先度が一定以上のパスから任意のパスを代替パスとして選択してもよい。

（第１２実施形態）
第１２実施形態は、ＩＡＢドナー２００により、ＩＡＢ－ｄｏｎｏｒ－ＤＵ ＢＡＰアドレス（ＩＡＢ－ｄｏｎｏｒ－ＤＵ ＢＡＰ Ａａｄｒｅｓｓ）をＩＡＢノード３００に設定する例である。ＩＡＢノード３００は、代替パスとして、ＩＡＢドナー２００とは異なる他のＩＡＢドナーにおけるＩＡＢ－ｄｏｎｏｒ－ＤＵ ＢＡＰアドレスを選択することができる。これにより、ドナーＤＵ間（Ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ）リルーティングが可能となる。

具体的には、第１に、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノード（例えば、ＩＡＢノード３００）へ、ドナー基地局のＢＡＰアドレスを設定する。第２に、ドナー基地局が、第１の中継ノードへ、ドナー基地局とは異なる他のドナー基地局のＢＡＰアドレスを設定する。第３に、第１の中継ノードがローカルリルーティングの実行を決定する。第４に、第１の中継ノードが、ドナー基地局のＢＡＰアドレス又は他のドナー基地局のＢＡＰアドレスのいずれかのＢＡＰアドレスへのパスを代替パスとして選択する。

なお、ＩＡＢ－ｄｏｎｏｒ－ＤＵ ＢＡＰアドレスは、例えば、ＩＡＢドナーにおけるＩＡＢ－ＤＵのＢＡＰアドレスである。

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

ＩＡＢドナー２００は、ステップＳ１３０において、処理を開始すると、ステップＳ１３１において、ＩＡＢノード３００に対して、代替パスとして選択可能な別ＩＡＢドナーのＩＡＢ－ｄｏｎｏｒ－ＤＵ ＢＡＰアドレスを設定する。別ＩＡＢドナーとは、ＩＡＢドナー２００とは異なるＩＡＢドナーのことである。ここでは、ＩＡＢドナー２００とは異なる別ドナーに属するＩＡＢ－ＤＵのＢＡＰアドレスを設定している。なお、ＩＡＢドナー２００は、例えば、Ｆ１－ＡＰメッセージを利用して、別ＩＡＢドナーのＩＡＢ－ＤＵのＢＡＰアドレスを設定する。また、ＩＡＢドナー２００自身のＩＡＢ－ＤＵのＢＡＰアドレスは、第４実施形態で説明したようにルーティング設定により、本処理が行われる前に、ＩＡＢドナー２００により設定される。なお、ＩＡＢドナー２００は、事前に当該別ＩＡＢドナーとフォーワーディングパスが確立されてもよい。

ステップＳ１３２において、ＩＡＢノード３００は、ローカルリルーティングの実行を決定する。例えば、ＩＡＢノード３００は、ＢＨ ＲＬＦを検知したときに、ローカルリルーティングの実行を決定してもよい。又は、上述した（第１実施形態）、（第２実施形態）、（第４実施形態）、（第７実施形態）、又は（第８実施形態）で説明した契機により、ローカルリルーティングの実行が決定されてもよい。

ステップＳ１３４において、ＩＡＢノード３００は、代替パスを選択する。ＩＡＢノード３００は、ルーティング設定（ルーティングＩＤ＝宛先ＢＡＰアドレス＋パスＩＤ）の中から、宛先ＢＡＰアドレスと一致する、ＩＡＢドナー２００（自ドナー）のＩＡＢ－ＤＵのＢＡＰアドレス、又は、代替パスとして選択可能な別ＩＡＢドナーのＩＡＢ－ＤＵのＢＡＰアドレスのパス（ルーティングＩＤ）を選択する。

ステップＳ１３４において、ＩＡＢノード３００は、選択した代替パスに対して、パケットを転送する。

ステップＳ１３５において、ＩＡＢノード３００は、一連の処理を終了する。

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

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

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

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

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

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

トポロジ適応の拡張に関して、次の合意に達した。

・（例えば、急速なシャドウイングのための）堅牢性、異なるＩＡＢノード間、ＩＡＢドナーＤＵとＩＡＢドナーＣＵとの間のロードバランシング、及びシグナリング負荷の削減を改善させるトポロジ適応の拡張を検討。
・ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する。
・ＣＨＯ及びＣＨＯの潜在的なＩＡＢ固有の拡張機能は検討中である。
・ＤＡＰＳ及びＤＡＰＳの潜在的なＩＡＢ固有の拡張機能は、現時点では除外されていない（ただし、ＰＤＣＰがないため、ＤＡＰＳをサポートする方法が明確ではない）。
・メッセージのバンドリングについては、ＲＡＮ２は、少なくとも、トポロジ適応手順についてＲＡＮ３でさらに進展が見られるのを待つ。
・ＲＡＮ２は、セントラルルート決定に対する利点を含むローカルリルーティング、及びトポロジ全体の目標に対処する方法について議論する。

この付記では、Ｒｅｌ－１７ ｅＩＡＢのトポロジ適応拡張のさまざまなトピックについて議論する。

（議論）
（ＢＨ ＲＬＦインジケーションの拡張）
Ｒｅｌ－１６のＥメールディスカッションでは、図３２に示すような４種類のＢＨ ＲＬＦ通知が議論された。最後に、タイプ４の「回復失敗」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして規定され、これにより、子ＩＡＢ－ＭＴは親のＢＨリンク上のＲＬＦを認識し、ＲＬＦ回復手順を開始できる。

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

ＲＡＮ２は、「（例えば、急速なシャドウイングのための）堅牢性を改善させるトポロジ適応の拡張を検討」に合意した。これは、無線状態がより動的に変化すると想定されるため、ＢＨ ＲＬＦは、Ｒｅｌ－１６の場合と比較してＲｅｌ－１７でより頻繁に発生することを意味する。

所見２：Ｒｅｌ－１７では、急速なシャドウイングなど、無線状態がより動的に変更されるため、Ｒｅｌ－１６の展開と比較して、ＢＨ ＲＬＦがより頻繁に発生する。

Ｒｅｌ－１６における課題は、子ＩＡＢノードが親のＲＬＦ回復中にアップストリームデータを転送できないこと、又はデータが転送されたとしても、親がＢＨ ＲＬＦのためにデータを転送できないことである。そのため、どのような場合でもデータがＩＡＢドナーに到達できず、サービスが中断される。

所見３：Ｒｅｌ－１６のＢＨ ＲＬＦインジケーション（タイプ４）を使用すると、親のＲＬＦ回復の進行中に、ＩＡＢノードでデータ転送が中断される。

したがって、遅延を削減するための適切なアクションを実行するために、子ＩＡＢノードに親のＢＨ ＲＬＦをできるだけ早く通知すべきである。これは、「ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する」というＲＡＮ２の合意に沿ったものある。したがって、ＲＡＮ２は、タイプ２の「回復を試みている」というＢＨ ＲＬＦインジケーションを導入すべきである。なお、タイプ１及びタイプ２は同じ意味である。

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

提案１のようにタイプ２のインジケーションを導入する場合、親のＢＨ ＲＬＦが回復した場合に子ＩＡＢ－ＭＴにも通知すべきであるから、タイプ３の「ＢＨリンクが回復」を導入することは非常に明快である。但し、ＲＡＮ２は、「シグナリング負荷の削減を改善させるトポロジ適応の拡張を検討」に合意しているから、そのような明示的なインジケーションが本当に必要かどうかを検討すべきである。タイプ３のインジケーションがすべての子ＩＡＢノードに（例えば、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを介して）専用の方法で送信される場合、大きなオーバーヘッドが発生する可能性がある。

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

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

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

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

「ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する」という合意を考慮すると、むしろ、ＩＡＢ－ＭＴがサービスの中断を削減するためにどのように動作するかについて議論すべきである。ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）の機能拡張は、ＢＨ ＲＬＦインジケーションと組み合わせると解決策の候補と見なされ得るが、これらはまだ検討中である。私たちの見解では、ローカルリルーティング及びＣＨＯの共通の側面は、ある種のトリガ条件を必要とすることである。そのため、タイプ２インジケーションがそのような目的で機能する可能性がある。したがって、ＲＡＮ２は、提案３に加えて、親がＢＨ ＲＬＦから回復しようとしているときの他のＩＡＢ－ＭＴの動作について議論すべきである。

提案４：ＲＡＮ２は、タイプ２のＢＨ ＲＬＦインジケーションを受信した場合の他のＩＡＢ－ＭＴの動作について議論すべきである。更なる検討が必要であるが、例えば、ローカルリルーティング及び／条件付きハンドオーバをトリガするなど。

（条件付きハンドオーバの拡張）
条件付きハンドオーバ（ＣＨＯ）は、モビリティの堅牢性を改善させるためにＲｅｌ－１６で導入される。私たちの理解では、ＣＨＯは指定されたＲｅｌ－１６ ＩＡＢに使用できる。ＲＡＮ２は、「ＣＨＯ及びＣＨＯの潜在的なＩＡＢ固有の拡張機能は検討中である」に合意した。したがって、Ｒｅｌ－１６ ＣＨＯベースラインに加えて、ｅＩＡＢのＣＨＯ拡張機能を検討する価値がある。Ｒｅｌ－１６ ＣＨＯでは、図３４に示すように、対応するＣＨＯイベント（Ａ３／Ａ５）が満たされたとき、又は選択されたセルがＲＲＣ再確立のためのセル選択の結果としてＣＨＯ候補であるときに実行される。

ＣＨＯイベントＡ３／Ａ５は、ＩＡＢノードがＢＨリンクでＢＨ ＲＬＦを経験したときに満たすことができる。一方、これらのトリガ条件は、ＩＡＢ固有のＲＬＦ、つまりＢＨ ＲＬＦインジケーション（タイプ４）の受信によるＲＬＦでは、ＩＡＢノード自体のＢＨリンクの無線状態は良好であるため、満たすことができない。この場合、望ましい動作の１つは、ＩＡＢノードがＢＨ ＲＬＦインジケーションを受信したときにＣＨＯを実行することである。

所見４：Ｒｅｌ－１６ ＣＨＯは、親のＢＨ ＲＬＦ回復が進行中であり、失敗したとしても、ＩＡＢ－ＭＴと親との間のＢＨリンクがまだ良好であるため、ＩＡＢ－ＭＴでＣＨＯイベントＡ３／Ａ５によって自動的にトリガ／実行されない。

したがって、Ｒｅｌ－１７ ｅＩＡＢのトポロジ適応を改善するために、ＣＨＯの追加のトリガ条件について議論する価値がある。少なくとも既存のＢＨ ＲＬＦインジケーション（つまり、タイプ４）は、新しいトリガの有望な候補であると考えるが、導入された場合、タイプ２インジケーションの受信時にＣＨＯも実行すべきかについてさらに議論され得る。

提案５：ＲＡＮ２は、少なくともＩＡＢノードがＢＨ ＲＬＦインジケーション（タイプ４）を受信した場合に、ＣＨＯの追加のトリガ条件が規定されているかどうかを議論すべきである。追加のトリガ条件が導入された場合、タイプ２に適用できるかどうかは更なる検討が必要である。

提案５が合意される場合、ＣＨＯイベントＡ３／Ａ５に依存しないが、ＢＨ ＲＬＦインジケーションによる一種の「強制」トリガであるため、すべてのＣＨＯ候補（つまり、候補セル）が同時にＣＨＯをトリガされ得るという問題が発生する可能性がある。

現在の仕様では、「条件付き再設定の実行で複数のＮＲセルがトリガされる場合、どれを選択するかはＵＥの実装次第である。例えば、ＵＥは、ビーム及びビーム品質を考慮して、実行のためにトリガされたセルの１つを選択する。」とされている。これは主にＵＥを対象としている。

所見５：Ｒｅｌ－１６ ＣＨＯでは、複数の候補セルがＣＨＯ実行をトリガする場合、どのセルを選択するかはＵＥの実装次第である。

トポロジ全体の目的がＩＡＢドナーによって適切に処理されるため、ＩＡＢ－ＭＴに関しては、ＩＡＢ－ＭＴがローカル無線品質などに応じて実装によってトリガされたセルの１つを選択する場合、常に最良とは限らない。したがって、ＲＡＮ２は、提案５のような追加のトリガ条件のためにＩＡＢドナー制御のＣＨＯの実行を確認する方法について議論すべきである。例えば、ＩＡＢドナーは、ＣＨＯ設定におけるＣＨＯ候補に関連付けられた優先度情報を設定してもよい。ＩＡＢ－ＭＴは、特定の無線品質（Ｓ－ｃｒｉｔｅｒｉｏｎなど）を満たすすべてのトリガされたＣＨＯ候補から最も優先度の高いセルを選択すべきである。

提案６：ＲＡＮ２は、ＢＨ ＲＬＦインジケーションの受信により、すべての候補セルがＣＨＯをトリガする場合に、追加の拡張機能としてＩＡＢドナー制御のＣＨＯ実行が必要かどうかを検討すべきである。

（ローカルリルーティングの拡張）
Ｒｅｌ－１６では、以下の記載のように、ローカルリルーティングはＢＨ ＲＬＦが発生した場合にのみ許可される。
ＮＯＴＥ：例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングは実装次第である。ＢＨ ＲＬＦの場合、ＢＡＰエンティティの送信部分は、ＢＨ ＲＬＦの前に下位レイヤによって受け入れられていないＢＡＰデータＰＤＵを代替パスにリルーティングしてもよい。

これは、ＢＨ ＲＬＦによる堅牢性及びサービスの中断を改善するためにローカルリルーティングが有益であることを示している。したがって、Ｒｅｌ－１７は、ＲＡＮ２が合意した、負荷分散、シグナリングの削減、堅牢性及び／又はサービスの中断を改善する他のケースにローカルリルーティングを適用することを目的とすべきである。（堅牢性／サービスの中断を改善するために）提案４のようにＢＨ ＲＬＦインジケーションを受信することによって、及び／又は（負荷分散／輻輳緩和のために）フロー制御フィードバックを受信することによってなど、ＢＨ ＲＬＦ以外のローカルリルーティングを開始／停止するための追加条件を検討する価値がある。つまり、一般的に、親及び／又は子は、条件によってはＩＡＢノードのローカルリルーティングをトリガできるべきである。

所見６：Ｒｅｌ－１６では、ローカルリルーティングはＢＨ ＲＬＦの場合にのみ許可される。これにより、堅牢性とサービスの中断が改善される。

提案７：ＲＡＮ２は、ローカルリルーティングを開始／停止する追加の条件が導入されるかを議論すべきである。これにより、提案４のようにＢＨ ＲＬＦインジケーションを受信することによって、及び／又はフロー制御フィードバックを受信することによってなど、他のＩＡＢノードがトリガできるようになる。

合意される場合、Ｒｅｌ－１７における他の場合、すなわち、ＢＨ ＲＬＦに限らず、「ＲＡＮ２は、セントラルルート決定に対する利点を含むローカルリルーティング、及びトポロジ全体の目標に対処する方法について議論する。」したがって、Ｒｅｌ－１６の課題は、トポロジ全体の客観的な観点から検討すべきである。言うまでもなく、ＩＡＢドナーは、ＩＡＢトポロジ全般について完全な知識及び完全な制御を持っているため、トポロジ全体の目的を処理する。

Ｒｅｌ－１６のローカルリルーティングでは、宛先が同じである限り、代替パスとしてパスが選択されるのはＩＡＢノードの実装次第である。これは、ローカルリルーティングがローカルの決定に基づいており、ＩＡＢドナーの観点からは制御できないことを意味する。これは、特に、多くのローカルの決定が発生してＩＡＢトポロジに蓄積される場合、トポロジ全体の目的と一致しない可能性がある。

所見７：Ｒｅｌ－１６のローカルリルーティングでは、代替パスとしてどのパスが選択されるかはＩＡＢ－ＭＴの実装次第である。

したがって、ローカルリルーティングがＢＨ ＲＬＦの場合を超えて拡張される場合、ＩＡＢドナーの可制御性はより重要になるはずである。ＩＡＢノードはローカルリルーティングを実行するときに代替パスを選択する必要があるから、ＩＡＢドナーが代替パスを設定できることは明快である。代替パスのモデリングは、代替パスが同じルーティングＩＤを持っているかどうかなど、更なる検討が必要である。

提案８：ＲＡＮ２は、ＩＡＢドナーがＲｅｌ－１６のルーティング設定に加えて代替パスをＩＡＢノードに設定できるかどうかを検討すべきである。

ＩＡＢドナーの可制御性の他の側面として、ＩＡＢドナーはローカルリルーティングを認識すべきであって、ローカルリルーティングとトポロジ全体の目的の共存のために、ＩＡＢノードでローカルリルーティングを開始／停止してもよいことを考慮すべきである。例えば、ＩＡＢドナーは、どのＩＡＢノードが現在ローカルリルーティングを実行しているかの認識に基づいて、トポロジ全体の目的がまだ達成されているかどうかを検討してもよい。ＩＡＢドナーがトポロジ全体の目的を達成できないことに気付いた場合、ＩＡＢドナーはＩＡＢノードにローカルリルーティングを開始／停止するように指示するか、ＩＡＢドナーがＩＡＢトポロジ全体のルーティング設定を変更してもよい。

ローカルリルーティングにより、トポロジ全体の目的をどのように処理するかは、完全にＩＡＢドナーの実装次第であるが、ＩＡＢドナーは、ＩＡＢノードのローカル決定の情報及び制御性を必要とするかもしれない。

提案９：ＲＡＮ２は、ローカルリルーティングの開始／停止時にＩＡＢノードがＩＡＢドナーに通知する必要があるかどうかを議論すべきである。

提案１０：ＲＡＮ２は、ＩＡＢドナーがＩＡＢノードにローカルリルーティングを開始／停止するように指示できるかどうかについて議論すべきである。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（ドナー間のＩＡＢノードの移動）
ＩＡＢノード統合手順はＲｅｌ－１６に導入されており、これは、ＩＡＢノードの初期統合に使用される。つまり、まだサービス外の段階にある。

Ｒｅｌ－１７は、インタードナーＩＡＢノードの移動を指定することを目的としており、これは、堅牢な操作を提供し、モバイルＩＡＢノードに適用される予定である。Ｒｅｌ－１６とは対照的に、Ｒｅｌ－１７のインタードナーＩＡＢノードの移動は稼働中のフェーズで実行されるため、１つのＩＡＢノードのインタードナーＩＡＢノードの移動により、トポロジ全体に影響が生じ、サービスの中断を引き起こす。言い換えると、Ｒｅｌ－１７のインタードナーＩＡＢノードの移動では、ＩＡＢトポロジ内のすべてのＩＡＢノードが他のＩＡＢドナーに移動する方法、具体的には、同期を伴うＲＲＣ再設定（つまり、ハンドオーバコマンド）がこれらの影響を受けるＩＡＢノードにどのように提供されるか、を検討する必要がある。

図３８に示すように、子ノード（ＩＡＢノード♯２）が親ノード（ＩＡＢノード♯１）を介してソースＩＡＢドナーに接続されていると仮定すると、一組のシグナリングの問題が考えられる。

・ケース１：親が最初に移動された場合、子とソースドナー間のＲＲＣシグナリングパスが解放される。そのため、子ノードをどのように移動できるかは不明である。
・ケース２：子が最初に移動された場合、親ノードを介したターゲットドナーへのＲＲＣシグナリングパスはまだ確立されていない。そのため、子ノードがターゲットドナーにどのようにアクセスするか（つまり、ＲＲＣ再設定を完了してターゲットドナーに送信する方法）は不明である。

ケース１の場合、ＣＨＯは、子ノードのいくつかの拡張機能を使用して再利用されてもよい。つまり、親ノードが移動されるときに、子ノードでＣＨＯが実行される。
ケース２の場合、子ノードのＲＲＣ再設定のターゲットドナーへの送信は、例えば、その親ノードによって遅延されてもよい。

どちらの場合も、子ノードが最初に解放され、Ｒｅｌ－１６手順を使用して再統合されることが１つのオプションである可能性がある。ただし、重大なサービスの中断を考慮すると、Ｒｅｌ－１７のために望ましい解決策ではない可能性がある。

インタードナーＩＡＢノードの移動の全体的な手順はＲＡＮ３で検討されているが、ＲＡＮ２は、マルチホップネットワークで複数のＩＡＢノードを再設定する方法に対するＲＡＮ２の影響について検討する必要がある。

提案１６：ＲＡＮ２は、インタードナーＩＡＢノード移動のためにマルチホップＩＡＢノードを再設定する方法について検討する必要がある。

Claims (3)

1. 制御方法であって、
   中継ノードが、バックホールリンクの障害を検知したことを示す通知を他の中継ノードから受信したことに応じて、前記他の中継ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行することと、
   前記中継ノードが、前記ローカルリルーティングを実行後、前記他の中継ノードから、前記バックホールリンクの障害が回復したことを示す通知を受信することに応じて、前記他の中継ノードに対する前記パスにデータパケットを送信することと、
   前記中継ノードが、前記中継ノードの子ノードから、フロー制御フィードバックメッセージを受信することと、
   前記中継ノードが、前記フロー制御フィードバックメッセージに含まれる所定情報に基づいて、前記子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行するか否かを判断することと、
   を有する通信制御方法。
2. 中継ノードであって、
   バックホールリンクの障害を検知したことを示す通知を他の中継ノードから受信したことに応じて、前記他の中継ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行する制御部を備え、
   前記制御部は、前記ローカルリルーティングを実行後、前記他の中継ノードから、前記バックホールリンクの障害が回復したことを示す通知を受信することに応じて、前記他の中継ノードに対する前記パスにデータパケットを送信し、
   前記制御部は、
   前記中継ノードの子ノードから、フロー制御フィードバックメッセージを受信し、
   前記フロー制御フィードバックメッセージに含まれる所定情報に基づいて、前記子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行するか否かを判断する
   中継ノード。
3. 中継ノードを制御するプロセッサであって、
   バックホールリンクの障害を検知したことを示す通知を他の中継ノードから受信したことに応じて、前記他の中継ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行する処理と、
   前記ローカルリルーティングを実行後、前記他の中継ノードから、前記バックホールリンクの障害が回復したことを示す通知を受信することに応じて、前記他の中継ノードに対する前記パスにデータパケットを送信する処理と、
   前記中継ノードの子ノードから、フロー制御フィードバックメッセージを受信する処理と、
   前記フロー制御フィードバックメッセージに含まれる所定情報に基づいて、前記子ノードに対するパスとは異なる代替パスにデータパケットを転送するローカルリルーティングを実行するか否かを判断する処理と、を実行する
   プロセッサ。

Images