(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-11
(45)【発行日】2024-11-19
(54)【発明の名称】通信制御方法
(51)【国際特許分類】
H04W 24/04 20090101AFI20241112BHJP
H04W 16/26 20090101ALI20241112BHJP
H04W 36/16 20090101ALI20241112BHJP
H04W 92/20 20090101ALI20241112BHJP
【ＦＩ】
H04W24/04
H04W16/26
H04W36/16
H04W92/20 110
【請求項の数】
3
(21)【出願番号】P 2022573993
(86)(22)【出願日】2021-12-22
(86)【国際出願番号】 JP2021047568
(87)【国際公開番号】W WO2022149470
(87)【国際公開日】2022-07-14
【審査請求日】2023-07-03
(31)【優先権主張番号】63/134,275
(32)【優先日】2021-01-06
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】チャン ヘンリー
【審査官】青木 健
(56)【参考文献】
【文献】米国特許出願公開第２０２０／０２６７７９５（ＵＳ，Ａ１）
【文献】国際公開第２０２０／１９６２０１（ＷＯ，Ａ１）
【文献】国際公開第２０２０／２０２４４７（ＷＯ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｗ ４／００ － ９９／００
Ｈ０４Ｂ ７／２４ － ７／２６
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１，４
(57)【特許請求の範囲】
【請求項1】
セルラ通信システムで用いる通信制御方法であって、中継ノードが、前記中継ノードの親ノードからフロー制御フィードバックメッセージ又は障害発生通知メッセージを受信することと、
前記中継ノードが、前記フロー制御フィードバックメッセージ又は前記障害発生通知メッセージを受信後、一定期間経過したことに応じて、条件付きハンドオーバを実行することと、を有し、
前記実行することは、前記中継ノードが、前記親ノードから前記フロー制御フィードバックメッセージを受信し、さらに、前記親ノードから前記障害発生通知メッセージを受信したことに応じて、一定期間経過することなく、前記条件付きハンドオーバを実行することを含む、通信制御方法。
【請求項2】
前記障害発生通知メッセージは、前記中継ノードと前記親ノードとの間のバックホールリンクの無線リンク障害を検知したことを示すメッセージ、及び前記バックホールリンクの無線リンク障害からの回復を試行中であることを示すメッセージのうち少なくとも一方を含む、請求項１記載の通信制御方法。
【請求項3】
中継ノードであって、
前記中継ノードの親ノードからフロー制御フィードバックメッセージ又は障害発生通知メッセージを受信する受信部と、
前記フロー制御フィードバックメッセージ又は前記障害発生通知メッセージを受信後、一定期間経過したことに応じて、条件付きハンドオーバを実行する制御部と、を備え、
前記制御部は、前記親ノードから前記フロー制御フィードバックメッセージを受信し、さらに、前記親ノードから前記障害発生通知メッセージを受信したことに応じて、一定期間経過することなく、前記条件付きハンドオーバを実行する
中継ノード。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、セルラ通信システムに用いる通信制御方法に関する。
【背景技術】
【0002】
セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．３．０（２０２０－０９）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
【発明の概要】
【0003】
第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、前記中継ノードの親ノードからフロー制御フィードバックメッセージ又は障害発生通知メッセージを受信することを有する。また、前記通信制御方法は、前記中継ノードが、前記フロー制御フィードバックメッセージ又は前記障害発生通知メッセージを受信後、一定期間経過したことに応じて、条件付きハンドオーバを実行することを有する。
【0004】
第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、当該中継ノードの親ノードへ、データパケットの転送を試みることと、前記中継ノードが、一定期間、前記データパケットの転送ができなかった場合、条件付きハンドオーバを実行することとを有する。
【0005】
第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に第１の中継ノードを有するドナー基地局が、前記第１の中継ノードに対して、条件付きハンドオーバに関する設定を行うことと、前記第１の中継ノードが、前記設定に基づいて、条件付きハンドオーバを実行することとを有する。
【図面の簡単な説明】
【0006】
【発明を実施するための形態】
【0007】
図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【0008】
（セルラ通信システムの構成）
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
【0009】
図１は、一実施形態に係るセルラ通信システム１の構成例を表す図である。
【0010】
図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。
【0011】
以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
【0012】
なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。
【0013】
５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
【0014】
各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。また、セルは、ｇＮＢ２００など、基地局と区別しないで用いられる場合がある。１つのセルは１つのキャリア周波数に属する。
【0015】
各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
【0016】
各ｇＮＢ２００は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
【0017】
セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ（又はＩＡＢノード。以下、「ＩＡＢノード」と称する場合がある。）２００－１は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
【0018】
図１において、ＩＡＢノード３００－１がＩＡＢドナー２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
【0019】
ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末、タブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、及び／又は車両若しくは車両に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１は、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してＩＡＢドナー２００－１と間接的に通信する。
【0020】
図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を表す図である。
【0021】
図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｉｏｎ）とを有する。
【0022】
ＩＡＢ－ＭＴのＮＲ Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はＩＡＢドナー２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
【0023】
ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ＩＡＢドナー２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
【0024】
また、１つ又は複数のホップを介して、ＩＡＢドナー２００に接続されている全てのＩＡＢノード３００は、ＩＡＢドナー２００をルートとする有向非巡回グラフ（ＤＡＧ：Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ＩＡＢドナー２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。
【0025】
（基地局の構成）
次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を表す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を表す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
【0026】
無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
【0027】
ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
【0028】
制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部２３０は、以下に示す各実施例において、ｇＮＢ２００おける各処理を行うようにしてもよい。
【0029】
（中継ノードの構成）
次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を表す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を表す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
【0030】
無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
【0031】
無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
【0032】
制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部３２０は、以下に示す各実施例において、ＩＡＢノード３００における各処理を行うようにしてもよい。
【0033】
（ユーザ装置の構成）
次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を表す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を表す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
【0034】
無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
【0035】
制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部１３０は、以下に示す各実施例において、ＵＥ１００における各処理を行うようにしてもよい。
【0036】
（プロトコルスタックの構成）
次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。
次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。
【0037】
図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤと、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤとを有する。
【0038】
ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
【0039】
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｅｐｅａｔ ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及び割当リソースブロックを決定する。
【0040】
ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
【0041】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとＩＡＢドナー２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
【0042】
ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとＩＡＢドナー２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＩＡＢドナー２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ＩＡＢドナー２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
【0043】
ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。
【0044】
図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを表す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを表す図である。ここでは、ＩＡＢドナー２００がＣＵ及びＤＵに分割されている一例を示す。
【0045】
図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びＩＡＢドナー２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
【0046】
各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）は、バックホールＲＬＣチャネル（ＢＨ ＮＲ ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成する。これにより、トラフィックの優先順位付け及びＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御が可能である。ＢＡＰ ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びＩＡＢドナー２００のＢＡＰレイヤによって実行される。
【0047】
なお、ＩＡＢドナー２００のＣＵは、ＩＡＢノード３００とＩＡＢドナー２００のＤＵへのＦ１インターフェイスを終端する、ＩＡＢドナー２００のｇＮＢ－ＣＵ機能である。また、ＩＡＢドナー２００のＤＵは、ＩＡＢ ＢＡＰサブレイヤをホストし、ＩＡＢノード３００へワイヤレスバックホールを提供する、ＩＡＢドナー２００のｇＮＢ－ＤＵ機能である。
【0048】
図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤを有する。
【0049】
なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ＩＡＢドナー２００のＤＵ又はＣＵの処理又は動作についても、単に「ＩＡＢドナー」の処理又は動作として説明する場合がある。
【0050】
また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。さらに、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
【0051】
（第１実施形態）
セルラ通信システム１において、条件付きハンドオーバが行われる場合がある。条件付きハンドオーバ（ＣＨＯ：Ｃｏｎｄｉｔｉｏｎａｌ Ｈａｎｄｏｖｅｒ）は、１つ以上の実行条件（又はトリガ条件）が満たされたときに実行されるハンドオーバである。ここで、条件付きハンドオーバについて説明する。
セルラ通信システム１において、条件付きハンドオーバが行われる場合がある。条件付きハンドオーバ（ＣＨＯ：Ｃｏｎｄｉｔｉｏｎａｌ Ｈａｎｄｏｖｅｒ）は、１つ以上の実行条件（又はトリガ条件）が満たされたときに実行されるハンドオーバである。ここで、条件付きハンドオーバについて説明する。
【0052】
（条件付きハンドオーバ）
一般的なハンドオーバにおいては、ＵＥ１００がサービングセル及び／又は隣接セルの無線状態の測定値をｇＮＢ２００に報告し、この報告に基づいてｇＮＢ２００が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をＵＥ１００に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。
一般的なハンドオーバにおいては、ＵＥ１００がサービングセル及び／又は隣接セルの無線状態の測定値をｇＮＢ２００に報告し、この報告に基づいてｇＮＢ２００が隣接セルへのハンドオーバを決定し、ハンドオーバ指示をＵＥ１００に送信する。このため、サービングセルの無線状態が急激に劣化したような場合、一般的なハンドオーバは、ハンドオーバが実行される前に通信が途絶する場合がある。
【0053】
これに対し、条件付きハンドオーバは、予め設定されたトリガ条件が満たされると、当該トリガ条件に対応する候補セルへのハンドオーバを自律的に実行可能である。このため、一般的なハンドオーバにおける通信途絶などの問題を解決できる。
【0054】
条件付きハンドオーバの実行条件には、１つ以上のトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件を含む。条件付きハンドオーバの設定は、候補セル及びトリガ条件の複数の組み合わせを複数含んでもよい。条件付きハンドオーバの設定は、例えば、ＩＡＢドナー２００のＣＵからＩＡＢノード３００のＩＡＢ－ＤＵとＵＥ１００へのユニキャストのシグナリング（例えば、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージなど）により行われる。
【0055】
図９は、条件付きハンドオーバが行われる例を表す図である。図９に示すように、ＩＡＢノード３００－Ｔは、その親ノードであるＩＡＢノード３００－Ｐ１に対して、ＲＲＣコネクティッド状態にある。そして、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、トリガ条件を満たすと判断した場合、サービングセル（又はサービングセルを管理するＩＡＢノード３００－Ｐ１）から、ターゲットセル（又はターゲットセルを管理するＩＡＢノード３００－Ｐ２）へ、条件付きハンドオーバを実行する。
【0056】
なお、図１０に示すように、ＩＡＢノード３００－Ｔのダウンストリーム方向においては、子ノード３００－Ｃ１からフロー制御フィードバックメッセージを受信すると、ローカルリルーティングが行われ、パスの切り替えが行われる。なお、フロー制御フィードバックメッセージの詳細は後述する。
【0057】
なお、以下では、セルと当該セルを管理するＩＡＢノード３００とを区別しないで用いる場合がある。したがって、サービングセルからターゲットセルへのハンドオーバと、サービングセルを管理するＩＡＢノード３００－Ｐ１から、ターゲットセルを管理するＩＡＢノード３００－Ｐ２へのハンドオーバは、同じ意味で用いられる場合がある。
【0058】
ＩＡＢノード３００－Ｔにおいて、トリガ条件が満たされる場合、すぐに条件付きハンドオーバを実行すると、状況が改善したにも関わらず、当該ハンドオーバを実行してしまう場合がある。このような条件付きハンドオーバは無駄なハンドオーバとなってしまう。このような無駄なハンドオーバにより、トポロジ全体が最適でない状態となる場合がある。
【0059】
そこで、第１実施形態では、トリガ条件を満たす場合にすぐに条件付きハンドオーバを実行するのではなく、所定メッセージを受信後、一定期間経過後に、条件付きハンドオーバを実行する。すなわち、第１実施形態におけるトリガ条件は、「所定メッセージを受信後、一定期間経過したこと」である。
【0060】
具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、中継ノードの親ノードからフロー制御フィードバック（ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）メッセージ又は障害発生通知メッセージを受信する。第２に、中継ノードが、前記フロー制御フィードバックメッセージ又は前記障害発生通知メッセージを受信後、一定期間経過したことに応じて、条件付きハンドオーバを実行する。
【0061】
すなわち、「所定メッセージ」は、「フロー制御フィードバック（ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）メッセージ又は障害発生通知メッセージ」のことである。
【0062】
第１実施形態では、ＩＡＢノード３００－Ｔにおいて、所定メッセージを受信した後、一定期間経過後に行われるため、状況が改善した場合に条件付きハンドオーバを行わないようにすることも可能である。従って、第１実施形態では、無駄な条件付きハンドオーバの実行が抑制され、トポロジ全体も最適な状態を維持させることが可能となる。
【0063】
ここで、「フロー制御フィードバックメッセージ」は、フロー制御の際に用いられるメッセージである。また、「障害発生通知メッセージ」は、ＢＨリンクで障害が発生した際に用いられる通知メッセージである。ここで、２つのメッセージについて説明する。
【0064】
（フロー制御フィードバックメッセージ）
セルラ通信システム１では、フロー制御が行われる場合がある。フロー制御により、ＩＡＢノード３００とＩＡＢドナー２００においてパケットドロップに関連した輻輳（ｃｏｎｇｅｓｔｉｏｎ）（又は混雑。以下、「混雑」という場合がある。）を回避することができる。
セルラ通信システム１では、フロー制御が行われる場合がある。フロー制御により、ＩＡＢノード３００とＩＡＢドナー２００においてパケットドロップに関連した輻輳（ｃｏｎｇｅｓｔｉｏｎ）（又は混雑。以下、「混雑」という場合がある。）を回避することができる。
【0065】
３ＧＰＰにおけるダウンストリーム方向のフロー制御は、ＢＡＰサブレイヤでサポートされる。ＩＡＢノード３００のＩＡＢ－ＭＴは、バッファサイズが一定量を超えた場合、又は、フロー制御ポーリングを受信した場合、各ｉｎｇｒｅｓｓ（流入）ＢＨ ＲＬＣチャネルにおいて利用可能なバッファサイズに関するフィードバック情報を、親ノードへ送信する。このフィードバック情報を含むメッセージが、フロー制御フィードバックメッセージである。
【0066】
アップストリーム方向のフロー制御は、３ＧＰＰでは、とくに規定されていない。この場合３ＧＰＰでは、実装依存により、ＭＡＣレイヤ上のＵＬスケジューリングによって（又はＵＬ ｇｒａｎｔによって）行われる、とされる。第１実施形態では、図９に示すように、親ノード３００－Ｐ１のＩＡＢ－ＤＵが、その子ノードであるＩＡＢノード３００－ＴのＩＡＢ－ＭＴへ、フロー制御フィードバックメッセージを送信することが可能である。
【0067】
フロー制御フィードバックメッセージは、ＢＡＰレイヤメッセージ、例えば、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵに含まれてもよい。又は、フロー制御フィードバックメッセージは、ＭＡＣ ＣＥ又はＲＲＣメッセージを用いて送信されてもよい。
【0068】
ただし、図９において、ＩＡＢノード３００－Ｔに代えてＵＥ１００である場合を仮定する。ＵＥ１００は、ＢＡＰレイヤをサポートしていない。そこで、ＩＡＢノード３００－Ｐ１は、フロー制御フィードバックメッセージを、システム情報ブロックタイプ１（ＳＩＢ１：Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ Ｔｙｐｅ１）に含めてＵＥ１００へ送信したり、ＭＡＣ ＣＥを用いてＵＥ１００へ送信したりする。これにより、ＩＡＢノード３００－Ｐ１は、ＵＥ１００へ、フロー制御フィードバックメッセージを送信することが可能となる。
【0069】
（障害発生通知メッセージ）
図９に示すように、ＩＡＢノード３００－Ｐ１は、その上位ＩＡＢノードとの間でバックホール（ＢＨ＃１）リンクを確立している。ＩＡＢノード３００－Ｐ１のＩＡＢ－ＭＴは、ＲＲＣコネクティッド状態である。
図９に示すように、ＩＡＢノード３００－Ｐ１は、その上位ＩＡＢノードとの間でバックホール（ＢＨ＃１）リンクを確立している。ＩＡＢノード３００－Ｐ１のＩＡＢ－ＭＴは、ＲＲＣコネクティッド状態である。
【0070】
そして、ＩＡＢノード３００－Ｐ１のＩＡＢ－ＭＴが、ＢＨ＃１リンクの無線リンク障害（ＢＨ ＲＬＦ：Ｂａｃｋｈａｕｌ Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ）を検出したと仮定する。例えば、ＩＡＢノード３００－Ｐ１のＩＡＢ－ＭＴは、一定条件で同期外れ状態（ｏｕｔ－ｏｆ－ｓｙｎｃ）を検出した場合などにより、ＢＨ ＲＬＦを検出する。ＩＡＢノード３００－Ｐ１のＩＡＢ－ＤＵは、ＢＨ ＲＬＦを検出すると、ＩＡＢノード３００－Ｔ（又はＵＥ１００）へ、Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ（ＲＬＦ ｄｅｔｅｃｔｅｄ）を通知できる。Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦを検知したことを示す障害発生通知の一例である。また、ＩＡＢノード３００－Ｐ１のＩＡＢ－ＤＵは、ＢＨ ＲＬＦからの回復動作を検知すると、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴ（又はＵＥ１００）へ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ（Ｔｒｙｉｎｇ ｔｏ ｒｅｃｏｖｅｒ）を通知できる。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦからの回復を試行中であることを示す障害発生通知の一例である。さらに、ＩＡＢノード３００－Ｐ１のＩＡＢ－ＤＵは、Ｔｙｐｅ１ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎとを区別しないときは、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴ（又はＵＥ１００）へ、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信できる。Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎも、障害発生通知の一例である。
【0071】
このような障害発生通知を含むメッセージが、障害発生通知メッセージとなる。障害発生通知メッセージも、ＢＡＰレイヤメッセージ、例えば、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵに含まれてもよい。ただし、図９において、ＩＡＢノード３００－Ｔに代えてＵＥ１００である場合を仮定する。この場合も、ＩＡＢノード３００－Ｐ１は、障害発生通知メッセージを、ＳＩＢ１に含めてＵＥ１００へ送信したり、ＭＡＣ ＣＥを用いてＵＥ１００へ送信したりすることで、ＵＥ１００へ送信することが可能となる。
【0072】
なお、通知の種類として、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ（ＲＬＦ ｒｅｃｏｖｅｒｅｄ）とＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎ（Ｒｅｃｏｖｅｒｙ ｆａｉｌｕｒｅ）とがある。Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎは、ＩＡＢノード３００－ＴがＢＨ ＲＬＦから回復したことを示す回復通知である。また、Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎは、ＩＡＢノード３００－ＴがＢＨ ＲＬＦからの回復に失敗したことを示す回復失敗通知の一例である。
【0073】
（動作例）
次に、第１実施形態に係る動作例について説明する。
次に、第１実施形態に係る動作例について説明する。
【0074】
図１１は、第１実施形態に係る動作例を表す図である。
【0075】
ＩＡＢノード３００－Ｔは、ステップＳ１０において処理を開始すると、ステップＳ１１において、ＩＡＢドナー２００によって、条件付きハンドオーバの設定が行われる。
【0076】
ステップＳ１２において、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１からフロー制御フィードバックメッセージ又は障害発生通知メッセージを受信後、一定期間を測定する。障害発生通知メッセージは、ＢＨ ＲＬＦのＴｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎである。一定期間は、フロー制御フィードバックメッセージ又は障害発生通知メッセージの受信時から開始される。この場合、ＩＡＢノード３００－Ｔは、タイマを起動して、そのカウント値がタイマ値になったとき、一定期間が満了したと判断する。タイマ値は、事前に、ＩＡＢドナー２００又は親ノード３００－Ｐ１からＩＡＢノード３００－Ｔに設定されてもよい。もしくは、タイマ値は、フロー制御フィードバックメッセージ又は障害発生通知メッセージに含まれてもよい。この一定期間については、フロー制御フィードバックメッセージを受信した回数を用いてもよい。すなわち、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１又は子ノード３００－Ｃ１からフロー制御フィードバックメッセージを受信すると、カウンタをインクリメントする。ＩＡＢノード３００－Ｔは、当該カウンタ値が閾値に達した場合に一定期間が経過したと判断する。当該閾値は、ＩＡＢドナー２００又は親ノード３００－Ｐ１により事前に設定されてもよいし、フロー制御フィードバックメッセージに含まれてもよい。又は、これらタイマによる判断とカウンタによる判断とを組み合わせてもよい。つまり、ＩＡＢノード３００－Ｔは、フロー制御フィードバックメッセージを最初に受信した場合にタイマを起動し、カウンタをインクリメントする。当該タイマが満了する前に、当該カウンタ値が閾値に達した場合に、ＩＡＢノード３００－Ｔは、一定期間が経過したと判断する。当該タイマが満了した場合、ＩＡＢノード３００－Ｔは、当該カウンタ値をリセット（つまり、ゼロに設定）する。
【0077】
ステップＳ１３において、ＩＡＢノード３００－Ｔは、一定期間経過したことに応じて、条件付きハンドオーバを実行する。図９の例では、ＩＡＢノード３００－Ｔは、ターゲットセルを管理するＩＡＢノード３００－Ｐ２へ条件付きハンドオーバを実行する。
【0078】
ステップＳ１４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0079】
なお、第１実施形態において、一定期間が測定されることに代えて、親ノード３００－Ｐ１又は子ノード３００－Ｃ１からの希望に応じて、条件付きハンドオーバの実行判断が行われてもよい。例えば、親ノード３００－Ｐ１又は子ノード３００－Ｃ１は、フロー制御フィードバックメッセージに、条件付きハンドオーバを実施すべきか否かを示す識別子を含める。ＩＡＢノード３００－Ｔは、当該識別子により、条件付きハンドオーバを実施するか否かを決定する。これにより、親ノード３００－Ｐ１もしくは子ノード３００－Ｃ１は、混雑状況に応じて、ＩＡＢノード３００－Ｔの条件付きハンドオーバを制御することができる。
【0080】
また、ステップＳ１３において、一定期間が経過するよりも前に、所定のメッセージを受信した場合、ＩＡＢノード３００－Ｔは、条件付きハンドオーバを実行しないようにすることも可能である。所定のメッセージとしては、フロー制御離脱（ｆｌｏｗ ｃｏｎｔｒｏｌ ｌｅａｖｉｎｇ ｆｅｅｄｂａｃｋ）メッセージがある。フロー制御離脱メッセージは、例えば、混雑状況となってフロー制御フィードバックメッセージを送信した親ノード３００－Ｐ１が、混雑状況から改善して通常の状態に戻ったことを通知するために用いられるメッセージである。また、所定のメッセージとしては、ＢＨ ＲＬＦのＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎがある。このような所定のメッセージを受信したＩＡＢノード３００－Ｔは、タイマを停止してもよい。
【0081】
（第２実施形態）
第２実施形態は、ＩＡＢノード３００が一定期間データパケットを転送することができない場合、条件付きハンドオーバを実行する例である。
第２実施形態は、ＩＡＢノード３００が一定期間データパケットを転送することができない場合、条件付きハンドオーバを実行する例である。
【0082】
具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、当該中継ノードの親ノードへ、データパケットの転送を試みる。第２に、中継ノードが、一定期間、データパケットの転送ができなかった場合、条件付きハンドオーバを実行する。
【0083】
第２実施形態では、条件付きハンドオーバのトリガ条件は、「一定期間、親ノードへデータパケットの転送ができなかったこと」となる。
【0084】
図９の例では、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが親ノード３００－Ｐ１のＩＡＢ－ＤＵへデータパケットの転送を試みる。そして、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、一定期間、その転送ができなかった場合、ターゲットセルを管理するＩＡＢノード３００－Ｐ２へ、条件付きハンドオーバを実行する。
【0085】
このように、ＩＡＢノード３００において、一定期間、データパケットの転送ができなかった場合に条件付きハンドオーバを実行する。例えば、ＩＡＢノード３００は、サービングセルを管理するＩＡＢノードに見切りを付けて、他のＩＡＢノードへ条件付きハンドオーバを実行することができる。そのため、第２実施形態では、データパケット転送の遅延を削減させることが可能となる。
【0086】
次に、第２実施形態に係る動作例について説明する。
【0087】
図１２は、第２実施形態に係る動作例を表す図である。
【0088】
ＩＡＢノード３００－Ｔは、ステップＳ２０において、処理を開始すると、ステップＳ２１において、ＩＡＢドナー２００によって、条件つきハンドオーバの設定が行われる。
【0089】
ステップＳ２２において、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１へ、データパケットの転送を試みる。
【0090】
ステップＳ２３において、ＩＡＢノード３００－Ｔは、一定期間、データパケットの転送ができなかった場合、条件付きハンドオーバを実行する。ここで、「一定期間、データパケットの転送ができなかった場合」として、例えば、以下がある。
【0091】
（Ａ１）「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１へ、スケジューリング要求（ＳＲ：Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）を一定回数送信しても、親ノード３００－Ｐ１から、ＵＬ ｇｒａｎｔを受信しなかった場合である。
【0092】
（Ａ２）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１へ、ＳＲ又はバッファステータスレポート（ＢＳＲ：Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）を送信後、一定時間、ＵＬ ｇｒａｎｔを受信しなかった場合である。
【0093】
（Ａ３）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１に対するＨＡＲＱ又はＲＬＣの再送回数が一定回数に達した場合である。ただし、この場合、ＨＡＲＱ又はＲＬＣの再送回数が一定回数に達した時に、ＢＨ ＲＬＦとなる前であることが望ましい。特に、ＲＬＣの再送の場合、当該一定回数の閾値は、ＲＬＣの再送失敗によるＢＨ ＲＬＦを判定するための閾値よりも小さいことが望ましい。
【0094】
（Ａ４）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、子ノード３００－Ｃ１からデータパケットを受信後、一定時間、当該データパケットを、親ノード３００－Ｐ１へ転送できなかった（つまり滞留した）場合である。
【0095】
（Ａ５）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１に対する無線異常（ｒａｄｉｏ ｐｒｏｂｌｅｍ）を検知後（当該無線異常が回復することなく）、一定時間が経過した場合である。ただし、この場合、当該一定時間の閾値は、無線異常によるＢＨ ＲＬＦを判定するための閾値よりも小さい（短い）ことが望ましい。
【0096】
（Ａ６）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１に対する無線測定報告（ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔ）をトリガした後に（当該無線測定報告を送信することなく）、一定時間が経過した場合である。ただし、この場合、当該一定時間の閾値は、無線測定報告によるＢＨ ＲＬＦを判定するための閾値よりも小さい（短い）ことが望ましい。
【0097】
（Ａ７）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔによる、親ノード３００－Ｐ１へのランダムアクセスプリアンブルの送信（再送）が（当該ランダムアクセスプリアンブル送信が成功することなく）、一定回数に達した場合である。ただし、この場合、当該一定回数の閾値は、ランダムアクセスプロシージャ失敗によるＢＨ ＲＬＦを判定するための閾値よりも小さいことが望ましい。
【0098】
（Ａ８）又は、「一定期間、データパケットの転送ができなかった場合」とは、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐ１に対するＬｉｓｔｅｎ－Ｂｅｆｏｒｅ－Ｔａｌｋ（ＬＢＴ）が一定時間内に一定回数に達した場合である。ただし、この場合、当該一定回数の閾値は、連続ＬＢＴ失敗（ｃｏｎｓｉｓｔｅｎｔ ＬＢＴ ｆａｉｌｕｒｅ）によるＢＨ ＲＬＦを判定するための閾値よりも小さいことが望ましい。また、当該一定時間は連続ＬＢＴ失敗（ｃｏｎｓｉｓｔｅｎｔ ＬＢＴ ｆａｉｌｕｒｅ）によるＢＨ ＲＬＦを判定するための閾値より大きく（長く）てもよい。
【0099】
なお、上記（Ａ１）から（Ａ８）における「一定回数」と「一定時間」は、親ノード３００－Ｐ１又はＩＡＢドナー２００により、設定されてもよい。また、ＩＡＢノード３００－Ｔは、内部のタイマを用いて、「一定時間」を計測してもよい。さらに、「一定回数」、「一定時間」、及びタイマは、ＢＨ ＲＬＣチャネル毎、ＬＣＧ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ）毎、送信元（ｓｏｕｒｃｅ）及び／又は宛先（ｄｅｓｔｉｎａｔｉｏｎ）毎、又はルーティングＩＤ毎に、別々に存在又は計測されてもよい。
【0100】
ステップＳ２４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0101】
（第３実施形態）
第３実施形態は、ＩＡＢノード３００が、その親ノードからフロー制御フィードバックメッセージを受信し、さらに、障害発生通知メッセージを受信した場合に、条件付きハンドオーバを実行する例である。
第３実施形態は、ＩＡＢノード３００が、その親ノードからフロー制御フィードバックメッセージを受信し、さらに、障害発生通知メッセージを受信した場合に、条件付きハンドオーバを実行する例である。
【0102】
具体的には、中継ノード（例えば、ＩＡＢノード３００）が、親ノードからフロー制御フィードバックメッセージを受信し、さらに、親ノードから障害発生通知メッセージを受信したことに応じて、一定期間経過することなく、条件付きハンドオーバを実行する。
【0103】
第３実施形態では、条件付きハンドオーバのトリガ条件は、「親ノードからフロー制御フィードバックメッセージを受信し、さらに、親ノードから障害発生通知メッセージを受信したこと」となる。
【0104】
これにより、例えば、ＩＡＢノード３００は、フロー制御メッセージを送信した親ノードとは別の親ノードへハンドオーバすることになるため、親ノードにおける「混雑」状況を改善させることができる。また、例えば、ＩＡＢノード３００は、「混雑」状況となっている親ノードであって、ＢＨ ＲＬＦが発生する親ノードとは別の親ノードへハンドオーバするため、アップストリーム方向におけるデータパケット転送の遅延を少なくさせることも可能となる。
【0105】
次に、第３実施形態に係る動作例について説明する。
【0106】
図１３は第３実施形態に係る動作例を表す図である。
【0107】
ＩＡＢノード３００は、ステップＳ３０において、処理を開始すると、ステップＳ３１において、ＩＡＢドナー２００から条件付きハンドオーバの設定を受ける。
【0108】
ステップＳ３２において、ＩＡＢノード３００は、親ノードからフロー制御フィードバックメッセージを受信する。ＩＡＢノード３００は、フロー制御フィードバックメッセージを受信すると、ローカルリルーティング（ｌｏｃａｌ ｒｅｒｏｕｔｉｎｇ）を実行する。ここで、「ローカルリルーティング」について説明する。
【0109】
（ローカルリルーティング）
３ＧＰＰにおいてはバックホールリンクでのＢＨ ＲＬＦが発生した場合に、ローカルリルーティングが行われ、代替パス（ａｌｔｅｒｎａｔｉｖｅ ｐａｔｈ）を介してデータパケットが転送される、とされている。一般には、ＩＡＢドナー２００が、各ＩＡＢノード３００に対して、ルーティング設定を行う。各ＩＡＢノード３００は、ルーティング設定に従って、複数の中継ノードからデータパケットを転送する中継ノードを選択する。ローカルリルーティングは、例えば、このようなルーティング設定を無視して、代替パスを選択して、当該代替パスへデータパケットを転送することである。ローカルリルーティングによって、第１のＩＡＢノードから、代替パス上の第２のＩＡＢノードへデータパケットが転送されるため、例えば、データパケット転送の遅延を少なくさせることが可能となる。
３ＧＰＰにおいてはバックホールリンクでのＢＨ ＲＬＦが発生した場合に、ローカルリルーティングが行われ、代替パス（ａｌｔｅｒｎａｔｉｖｅ ｐａｔｈ）を介してデータパケットが転送される、とされている。一般には、ＩＡＢドナー２００が、各ＩＡＢノード３００に対して、ルーティング設定を行う。各ＩＡＢノード３００は、ルーティング設定に従って、複数の中継ノードからデータパケットを転送する中継ノードを選択する。ローカルリルーティングは、例えば、このようなルーティング設定を無視して、代替パスを選択して、当該代替パスへデータパケットを転送することである。ローカルリルーティングによって、第１のＩＡＢノードから、代替パス上の第２のＩＡＢノードへデータパケットが転送されるため、例えば、データパケット転送の遅延を少なくさせることが可能となる。
【0110】
第３実施形態では、図９の例では、親ノード３００－Ｐ１が、そのバッファサイズが一定量を超えた場合、フロー制御フィードバックメッセージをＩＡＢノード３００－Ｔへ送信することが可能である。ＩＡＢノード３００－Ｔは、当該メッセージの受信により、親ノード３００－Ｐ１において、「混雑」の発生を把握することができる。そして、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１において「混雑」している状況を確認すると、ローカルリルーティングを実行する。図９の例では、ＩＡＢノード３００－Ｔは、ローカルリルーティングにより、親ノード３００－Ｐ２へのパスを代替パスとして選択する。ＩＡＢノード３００－Ｔは、代替パスへデータパケットを転送する。これにより、例えば、親ノード３００－Ｐ１における「混雑」を解消させることが可能である。図１３のステップＳ３２は、「ＩＡＢノード３００がローカルリルーティングを実施する状況にあると判断する」、としてもよい。
ステップＳ３３において、ＩＡＢノード３００は、親ノードから、Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信する。ＩＡＢノード３００は、ステップＳ３２を合わせて、親ノードからフロー制御フィードバックメッセージを受信し、さらに、障害発生通知メッセージを受信したことを、ステップＳ３３において確認している。
ステップＳ３３において、ＩＡＢノード３００は、親ノードから、Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信する。ＩＡＢノード３００は、ステップＳ３２を合わせて、親ノードからフロー制御フィードバックメッセージを受信し、さらに、障害発生通知メッセージを受信したことを、ステップＳ３３において確認している。
【0111】
なお、ステップＳ３３は、「ＩＡＢノード３００がローカルリルーティングを行っている状況で、同一の親ノードから障害発生通知メッセージを受信する」、としてもよい。「同一の親ノード」は、例えば、ＩＡＢノード３００が代替パスを選択する直前のパス（又はメインパス）上にある親ノードのことである。図９の例では、親ノード３００－Ｐ１がフロー制御フィードバックメッセージを送信するため、親ノード３００－Ｐ１が「同一の親ノード」となる。
【0112】
ステップＳ３４において、ＩＡＢノード３００は、条件付きハンドオーバを実行（又はトリガ）する。図９の例では、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ２へ、条件付きハンドオーバを実行することになる。
【0113】
図１３に戻り、ステップＳ３５において、ＩＡＢノード３００は、一連の処理を終了する。
【0114】
（第４実施形態）
第４実施形態は、条件付きハンドオーバにおける複数のトリガ条件のうち、ＩＡＢノード３００においてどのトリガ条件を用いるのかを、ＩＡＢドナー２００が設定する例である。具体的には、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノード（例えば、ＩＡＢノード３００）に対して、条件付きハンドオーバに関する複数のトリガ条件のうち、第１の中継ノードが用いるべき１以上のトリガ条件を設定する。これにより、例えば、中継ノードに応じたトリガ条件を設定することが可能となる。
第４実施形態は、条件付きハンドオーバにおける複数のトリガ条件のうち、ＩＡＢノード３００においてどのトリガ条件を用いるのかを、ＩＡＢドナー２００が設定する例である。具体的には、ドナー基地局（例えば、ＩＡＢドナー２００）が、第１の中継ノード（例えば、ＩＡＢノード３００）に対して、条件付きハンドオーバに関する複数のトリガ条件のうち、第１の中継ノードが用いるべき１以上のトリガ条件を設定する。これにより、例えば、中継ノードに応じたトリガ条件を設定することが可能となる。
【0115】
図１４は第４実施形態に係る動作例を表す図である。
【0116】
ＩＡＢドナー２００は、ステップＳ４０において、処理を開始すると、ステップＳ４１において、ＩＡＢノード３００に対して、条件付きハンドオーバにおける複数のトリガ条件の中から、当該ＩＡＢノード３００が用いるべき１以上のトリガ条件を設定する。例えば、ＩＡＢドナー２００のＣＵが、ＩＡＢノード３００のＩＡＢ－ＭＴ又はＩＡＢ－ＤＵへ、ＲＲＣメッセージ又はＦ１－ＡＰメッセージなどを利用して、トリガ条件を設定する。トリガ条件としては、例えば、以下がある。
【0117】
（Ｂ１）ＢＨ ＲＬＦのＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎを受信したこと。
【0118】
（Ｂ２）ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信したこと。
【0119】
（Ｂ３）親ノードからフロー制御フィードバックメッセージを受信したこと。
【0120】
（Ｂ４）一定期間、データパケットを転送することができなかったこと（第２実施形態）。
【0121】
（Ｂ５）上記（Ｂ１）から（Ｂ４）に関連する閾値、タイマ値、回数上限値。
【0122】
トリガ条件は、上記（Ｂ１）から（Ｂ５）の１つ又は複数である。トリガ条件としては、複数の場合も許容されるため、トリガ条件として、「ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信したこと」（Ｂ２）＋「親ノードからフロー制御フィードバックメッセージを受信したこと」（Ｂ３）が設定されてもよい。また、（Ｂ２）については、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎに代えて、Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ又はＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎであってもよい。
【0123】
ステップＳ４２において、ＩＡＢノード３００は、設定されたトリガ条件を満たす場合に、条件付きハンドオーバを実行（又はトリガ）する。
【0124】
ステップＳ４３において、ＩＡＢノード３００は、一連の処理を終了する。
【0125】
（第５実施形態）
例えば、図１５に示すように、ＩＡＢノード３００－Ｔの親ノード３００－Ｐ１が、ＩＡＢノード３００－Ｔへ、ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信し、ＩＡＢノード３００－Ｔが条件付きハンドオーバをトリガしたと仮定する。そして、条件付きハンドオーバの候補セルとして、候補セル＃１と候補セル＃２があると仮定する。
例えば、図１５に示すように、ＩＡＢノード３００－Ｔの親ノード３００－Ｐ１が、ＩＡＢノード３００－Ｔへ、ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信し、ＩＡＢノード３００－Ｔが条件付きハンドオーバをトリガしたと仮定する。そして、条件付きハンドオーバの候補セルとして、候補セル＃１と候補セル＃２があると仮定する。
【0126】
このように、複数の候補セル＃１，＃２がある場合、ＩＡＢノード３００－Ｔが、どの候補セルを選択するのかが問題となるケースがある。例えば、ＩＡＢノード３００－Ｔが、各候補セル＃１，＃２における無線状況が最も良いセル、例えば、候補セル＃１を選択すると仮定する。
【0127】
しかし、ＩＡＢノード３００－Ｔから親ノード３００－Ｐ２を介してターゲット（図１５の例ではＩＡＢドナー２００）までに至るホップ数は、候補セル＃２を管理する親ノード３００－Ｐ３を介してターゲットまでに至るホップ数よりも多くなる場合がある。この場合、前者の方が、後者よりも、ホップ数が多くなることによって、データパケット転送の遅延が大きくなる。
【0128】
従って、候補セル＃１，＃２が複数ある場合に、無線状況が最も良い候補セルを選択することが、必ずしも、最適なルートを選択したことにはならない場合がある。
【0129】
そこで、第５実施形態では、ＩＡＢドナー２００が条件付きハンドオーバの候補セルに優先順位を設定する。具体的には、第１に、ドナー基地局（例えばＩＡＢドナー２００）が、第１の中継ノード（例えばＩＡＢノード３００－Ｔ）に対して、候補セル毎の優先順位を設定する。第２に、第１の中継ノードが、最も優先順位の高い候補セルをターゲットセルとして選択し、当該ターゲットセルに対して条件付きハンドオーバを実行する。これにより、例えば、データパケット転送の遅延を少なくした最適なルートの選択が可能となる。
【0130】
図１６は第５実施形態に係る動作例を表す図である。
【0131】
ＩＡＢドナー２００は、ステップＳ５０において、処理を開始すると、ステップＳ５１において、ＩＡＢノード３００－Ｔへ条件付きハンドオーバの設定を行う。ＩＡＢドナー２００のＣＵは、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵ（又はＵＥ１００）へ、候補セルとトリガ条件に加え、候補セル毎の優先順位を含むＲＲＣ再設定（Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信することで、設定が行われてもよい。例えば、図１５の例では、候補セル＃１の優先順位は「１」、候補セル＃２の優先順位は「２」などである。なお、ＲＲＣ再設定メッセージに代えて、Ｆ１－ＡＰメッセージ及び／又はＭＡＣ ＣＥを利用して、優先順位を含む設定が行われてもよい。
【0132】
なお、条件付きハンドオーバのトリガ条件は、ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信すること以外にも、第１実施形態で説明したトリガ条件でもよいし、第２実施形態又は第３実施形態で説明したトリガ条件でもよい。あるいは、トリガ条件は、イベントＡ３又はイベントＡ５であってもよい。イベントＡ３は、隣接セルの無線状態がサービングセルの無線状態よりも所定量（所定オフセット）以上良好であるというイベントである。また、イベントＡ５は、サービングセルの無線状態が第１閾値よりも劣化し、且つ、隣接セルの無線状態が第２閾値よりも良好であるというイベントである。
【0133】
図１６に戻り、ステップＳ５２において、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信する等、トリガ条件を満たすと、条件付きハンドオーバの設定に従って、条件付きハンドオーバを実行（又はトリガ）する。ＩＡＢノード３００－Ｔは、複数の候補セル＃１，＃２がトリガされた場合、設定された優先順位に基づいて、最も優先順位の高いセルをターゲットセルとして選択する。最も優先順位の高いセルが複数存在する場合、どのセルを選択するかは、ＩＡＢノード３００－Ｔの実装依存でもよい。例えば、最も優先順位の高いセルが複数存在する場合、ＩＡＢノード３００－Ｔは、最も無線品質の良いセルをターゲットセルとして選択してもよい。ＩＡＢノード３００－Ｔは、選択したターゲットセルに対して、条件付きハンドオーバの設定を適用する。
【0134】
ステップＳ５３において、ＩＡＢノード３００－Ｔは、適用した条件付きハンドオーバの設定に従って、ターゲットセルへのアクセスを開始する。
【0135】
ステップＳ５４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0136】
第５実施形態において、ＩＡＢドナー２００は、条件付きハンドオーバの設定として、さらに、最低無線品質閾値を、ＩＡＢノード３００－Ｔに設定してもよい。最低無線品質閾値は、例えば、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）、ＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ）、及び／又はＳＩＮＲ（Ｓｉｇｎａｌ ｔｏ Ｉｎｔｅｒｆｅｒｅｎｃｅ ｐｌｕｓ Ｎｏｉｓｅ Ｒａｔｉｏ）などにより表された無線品質に対する閾値である。この場合、ステップＳ５２において、ＩＡＢノード３００－Ｔは、複数の候補セルがトリガされた場合、最低無線品質閾値を上回る候補セルを抽出し、抽出した候補セルのうち最も優先順位の高いセルを選択する。このように、最低無線品質閾値が設定されることで、最低無線品質を満たすターゲットセルが選択されることになる。そのため、ＩＡＢノード３００－Ｔからターゲットセル（例えば、親ノード３００－Ｐ２）に対するデータパケット転送の確実性が確保される。
【0137】
（第６実施形態）
第５実施形態では、複数の候補セルからターゲットセルを選択する例について説明した。例えば、ＩＡＢノード３００が選択したターゲットセルにおいて、ＢＨ ＲＬＦが発生していると、ＩＡＢノード３００からＩＡＢドナー２００へ、ＲＲＣメッセージなどが届かない等により、条件付きハンドオーバ自体が失敗する場合がある。
第５実施形態では、複数の候補セルからターゲットセルを選択する例について説明した。例えば、ＩＡＢノード３００が選択したターゲットセルにおいて、ＢＨ ＲＬＦが発生していると、ＩＡＢノード３００からＩＡＢドナー２００へ、ＲＲＣメッセージなどが届かない等により、条件付きハンドオーバ自体が失敗する場合がある。
【0138】
そこで、第６実施形態は、条件付きハンドオーバの候補セルにおいてＢＨ ＲＬＦが発生している場合、ＩＡＢノード３００は、当該候補セルを、候補セルから外して、ターゲットセルとして選択しないようにする。
【0139】
具体的には、第１の中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、候補セル（例えば、候補セル＃１）を管理する第２の中継ノード（例えば、ＩＡＢノード３００－Ｐ１）と当該第２の中継ノードの親ノードとの間のバックホールリンクが正常な場合、候補セルをターゲットセルとして選択してターゲットセルに対して条件付きハンドオーバを実行する。正常でない場合、第１の中継ノードが、他の候補セルを選択する。これにより、例えば、条件付きハンドオーバが失敗する可能性を低くすることが可能となる。
【0140】
図１７は第６実施形態における動作例を表す図である。
【0141】
ＩＡＢドナー２００は、ステップＳ６０において、処理を開始すると、ステップＳ６１において、ＩＡＢノードに対して条件付きハンドオーバの設定を行う。条件付きハンドオーバの設定については、ターゲットセルのＢＨ ＲＬＦを確認するか否かを指定する指定情報が含まれてもよい。当該指定情報は、第５実施形態と同様に、ＲＲＣ再設定メッセージ又はＦ１－ＡＰメッセージなどに、候補セル及びトリガ条件とともに含まれてもよい。
【0142】
ステップＳ６２において、ＩＡＢノード３００は、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信する等、トリガ条件を満たすと、条件付きハンドオーバを実行（又はトリガ）する。第６実施形態においても、複数の候補セルがトリガされると仮定する。そして、ＩＡＢノード３００のＩＡＢ－ＭＴは、例えば、以下のようにしてターゲットセルを選択する。
【0143】
すなわち、ＩＡＢノード３００は、最初に、ターゲットセルを仮選択する。例えば、図１５の例では、ＩＡＢノード３００－Ｔは、候補セル＃１（又は親ノード３００－Ｐ２）をターゲットセルとして仮選択する。ターゲットセルの仮選択は、第５実施形態と同様に、優先順位に基づいて選択されてもよい。ターゲットセルの仮選択は、最低無線品質閾値を上回る候補セルの中から優先順位に基づいて選択されてもよい。
【0144】
そして、ＩＡＢノード３００－Ｔは、仮選択したターゲットセルのＢＨリンクが正常か否か（又はＢＨ ＲＬＦが発生していないか否か）を確認する。具体的には、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ２がＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信したか否かにより確認を行う。つまり、親ノード３００－Ｐ２と、当該親ノード３００－Ｐ２のさらに親ノードとの間のＢＨリンクでＢＨ ＲＬＦが発生しているか否かを確認する。
【0145】
例えば、ＩＡＢノード３００－Ｔは、受信したＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを確認することで、親ノード３００－Ｐ２においてＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信したか否かを確認してもよい。また、例えば、ＩＡＢノード３００－Ｔが親ノード３００－Ｐ２に問い合わせることで、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信したか否かを確認してもよい。ＩＡＢノード３００－Ｔに代えて、ＵＥ１００である場合は、ＵＥ１００は、報知されたＳＩＢ１に含まれるＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを確認することで、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを送信したか否かを確認する。これらは、いずれも、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎに代えて、Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ又はＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎでもよい。なお、仮選択したターゲットセルのＢＨ ＲＬＦが正常か否かは、親ノード３００－Ｐ２がＩＡＢ Ｓｕｐｐｏｒｔ ＩＥを送信したか否かを、ＩＡＢノード３００－Ｔが確認することで判断してもよい。
【0146】
そして、ＩＡＢノード３００－Ｔは、仮選択したターゲットセルのＢＨリンクが正常であると判断した場合、当該セルをターゲットセルとして選択する。例えば、図１５の例において、ＩＡＢノード３００－Ｔは、仮選択した親ノード３００－Ｐ２のＢＨリンクが正常である場合、親ノード３００－Ｐ２（又は親ノード３００－Ｐ２が管理する候補セル＃１）をターゲットセルとして選択する。
【0147】
他方、ＩＡＢノード３００－Ｔは、仮選択したターゲットセルのＢＨリンクが正常でないと判断した場合、別の候補セルを、ターゲットセルとして仮選択する。例えば、図１５の例において、ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ２のＢＨリンクが正常でない場合、候補セル＃２（又は親ノード３００－Ｐ３）を仮選択し、仮選択したターゲットセルにおいて、ＢＨ ＲＬＦが発生しているか否かを確認する。確認方法は、上述した例と同一である。また、仮選択するターゲットセルが複数ある場合は、候補セル毎の優先順位に従って選択されてもよい。
【0148】
図１７に戻り、ステップＳ６３において、ＩＡＢノード３００は、条件付きハンドオーバの設定に従って、ターゲットセルへのアクセスを開始する。
【0149】
ステップＳ６４において、ＩＡＢノード３００は、一連の処理を終了する。
【0150】
（その他の実施形態）
上述した第１実施形態から第６実施形態において、ＩＡＢノード３００－Ｔに代えて、ＵＥ１００であってもよい。例えば、第１実施形態でも説明したように、ＵＥ１００は、親ノード３００－Ｐ１からＳＩＢ１などを利用して、フロー制御フィードバックメッセージ又は障害発生メッセージを受信できる。したがって、ＵＥ１００では、第１実施形態から第６実施形態で説明したトリガ条件を満たす場合に、条件付きハンドオーバを実行することが可能となる。また、第３実施形態で説明した、ＵＥ１００において設定されるべきトリガ条件も、ＲＲＣメッセージ又はＦ１－ＡＰメッセージを利用することで、設定することが可能である。
上述した第１実施形態から第６実施形態において、ＩＡＢノード３００－Ｔに代えて、ＵＥ１００であってもよい。例えば、第１実施形態でも説明したように、ＵＥ１００は、親ノード３００－Ｐ１からＳＩＢ１などを利用して、フロー制御フィードバックメッセージ又は障害発生メッセージを受信できる。したがって、ＵＥ１００では、第１実施形態から第６実施形態で説明したトリガ条件を満たす場合に、条件付きハンドオーバを実行することが可能となる。また、第３実施形態で説明した、ＵＥ１００において設定されるべきトリガ条件も、ＲＲＣメッセージ又はＦ１－ＡＰメッセージを利用することで、設定することが可能である。
【0151】
ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
【0152】
また、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行する回路を集積化し、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。
【0153】
以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施例の全部又は一部を組み合わせることも可能である。
【0154】
本願は、米国仮出願第６３／１３４２７５号（２０２１年１月６日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【0155】
（付記）
（導入）
ＮＲ ｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ＡＮＤ Ｂａｃｋｈａｕｌ）に関する改訂されたワークアイテムが承認された。いくつかの目的は次の通りである。
（導入）
ＮＲ ｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ＡＮＤ Ｂａｃｋｈａｕｌ）に関する改訂されたワークアイテムが承認された。いくつかの目的は次の通りである。
【0156】
トポロジ適応の拡張
・シグナリング負荷を軽減するための機能拡張を含む、堅牢性及び負荷分散を強化するためのインタードナーＩＡＢノード移動のための手順の仕様。
・ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性に対する拡張の仕様。
トポロジ、ルーティング、及びトランスポートの機能拡張
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
・シグナリング負荷を軽減するための機能拡張を含む、堅牢性及び負荷分散を強化するためのインタードナーＩＡＢノード移動のための手順の仕様。
・ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性に対する拡張の仕様。
トポロジ、ルーティング、及びトランスポートの機能拡張
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
【0157】
トポロジ適応の拡張に関して、次の合意に達した。
【0158】
・（例えば、急速なシャドウイングのための）堅牢性、異なるＩＡＢノード間、ＩＡＢドナーＤＵとＩＡＢドナーＣＵとの間のロードバランシング、及びシグナリング負荷の削減を改善させるトポロジ適応の拡張を検討。
・ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する。
・ＣＨＯ及びＣＨＯの潜在的なＩＡＢ固有の拡張機能は検討中である。
・ＤＡＰＳ及びＤＡＰＳの潜在的なＩＡＢ固有の拡張機能は、現時点では除外されていない（ただし、ＰＤＣＰがないため、ＤＡＰＳをサポートする方法が明確ではない）。
・メッセージのバンドリングについては、ＲＡＮ２は、少なくとも、トポロジ適応手順についてＲＡＮ３でさらに進展が見られるのを待つ。
・ＲＡＮ２は、セントラルルート決定に対する利点を含むローカルリルーティング、及びトポロジ全体の目標に対処する方法について議論する。
・ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する。
・ＣＨＯ及びＣＨＯの潜在的なＩＡＢ固有の拡張機能は検討中である。
・ＤＡＰＳ及びＤＡＰＳの潜在的なＩＡＢ固有の拡張機能は、現時点では除外されていない（ただし、ＰＤＣＰがないため、ＤＡＰＳをサポートする方法が明確ではない）。
・メッセージのバンドリングについては、ＲＡＮ２は、少なくとも、トポロジ適応手順についてＲＡＮ３でさらに進展が見られるのを待つ。
・ＲＡＮ２は、セントラルルート決定に対する利点を含むローカルリルーティング、及びトポロジ全体の目標に対処する方法について議論する。
【0159】
この付記では、Ｒｅｌ－１７ ｅＩＡＢのトポロジ適応拡張のさまざまなトピックについて議論する。
【0160】
（議論）
（ＢＨ ＲＬＦインジケーションの拡張）
Ｒｅｌ－１６のＥメールディスカッションでは、図１８に示すような４種類のＢＨ ＲＬＦ通知が議論された。最後に、タイプ４の「回復失敗」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして規定され、これにより、子ＩＡＢ－ＭＴは親のＢＨリンク上のＲＬＦを認識し、ＲＬＦ回復手順を開始できる。
（ＢＨ ＲＬＦインジケーションの拡張）
Ｒｅｌ－１６のＥメールディスカッションでは、図１８に示すような４種類のＢＨ ＲＬＦ通知が議論された。最後に、タイプ４の「回復失敗」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして規定され、これにより、子ＩＡＢ－ＭＴは親のＢＨリンク上のＲＬＦを認識し、ＲＬＦ回復手順を開始できる。
【0161】
所見１：Ｒｅｌ－１６では、タイプ４の「回復障害」のみがＢＨ ＲＬＦインジケーションとして規定された。
【0162】
ＲＡＮ２は、「（例えば、急速なシャドウイングのための）堅牢性を改善させるトポロジ適応の拡張を検討」に合意した。これは、無線状態がより動的に変化すると想定されるため、ＢＨ ＲＬＦは、Ｒｅｌ－１６の場合と比較してＲｅｌ－１７でより頻繁に発生することを意味する。
【0163】
所見２：Ｒｅｌ－１７では、急速なシャドウイングなど、無線状態がより動的に変更されるため、Ｒｅｌ－１６の展開と比較して、ＢＨ ＲＬＦがより頻繁に発生する。
【0164】
Ｒｅｌ－１６における課題は、子ＩＡＢノードが親のＲＬＦ回復中にアップストリームデータを転送できないこと、又はデータが転送されたとしても、親がＢＨ ＲＬＦのためにデータを転送できないことである。そのため、どのような場合でもデータがＩＡＢドナーに到達できず、サービスが中断される。
【0165】
所見３：Ｒｅｌ－１６のＢＨ ＲＬＦインジケーション（タイプ４）を使用すると、親のＲＬＦ回復の進行中に、ＩＡＢノードでデータ転送が中断される。
【0166】
したがって、遅延を削減するための適切なアクションを実行するために、子ＩＡＢノードに親のＢＨ ＲＬＦをできるだけ早く通知すべきである。これは、「ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する」というＲＡＮ２の合意に沿ったものある。したがって、ＲＡＮ２は、タイプ２の「回復を試みている」というＢＨ ＲＬＦインジケーションを導入すべきである。なお、タイプ１及びタイプ２は同じ意味である。
【0167】
提案１：ＲＡＮ２は、ＢＨ ＲＬＦインジケーションのタイプ２の「回復を試みている」が導入されていることに合意すべきである。ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ、ＳＩＢ１、又はその両方を介して送信されるかは更なる検討が必要である。
【0168】
提案１のようにタイプ２のインジケーションを導入する場合、親のＢＨ ＲＬＦが回復した場合に子ＩＡＢ－ＭＴにも通知すべきであるから、タイプ３の「ＢＨリンクが回復」を導入することは非常に明快である。但し、ＲＡＮ２は、「シグナリング負荷の削減を改善させるトポロジ適応の拡張を検討」に合意しているから、そのような明示的なインジケーションが本当に必要かどうかを検討すべきである。タイプ３のインジケーションがすべての子ＩＡＢノードに（例えば、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを介して）専用の方法で送信される場合、大きなオーバーヘッドが発生する可能性がある。
【0169】
例えば、タイプ２のインジケーションがＳＩＢ１を介して送信される場合、図１９のオプション２に示されているように、ＢＨリンクがＲＬＦの下にない（即ち、「回復される」）と、インジケーションはブロードキャストされなくなる。従って、ダウンストリームＩＡＢノード及びＵＥは、ＳＩＢ１にタイプ２のインジケーションがないことに基づいてＢＨリンクが回復したかどうかを認識する。もちろん、タイプ３のインジケーションがＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを介して送信される場合、ダウンストリームＩＡＢノードがＢＨリンク回復をすばやく知ることができるという利点がある。しかしながら、ＵＥはＢＡＰレイヤを持たないため、その回復を知れないということが不利な点である。従って、ＲＡＮ２は、タイプ３のインジケーションが本当に必要かを検討すべきである。
【0170】
提案２：提案１に合意できる場合、ＲＡＮ２は、ＢＨ ＲＬＦがなくなったときの明示的なＢＨ ＲＬＦインジケーション、即ち、タイプ３の「ＢＨリンク回復」が導入されるべきかについて検討すべきである。
【0171】
提案１及び／又は提案２に合意できる場合、インジケーションを受信したＩＡＢ－ＭＴの動作をＢＨリンクが回復している間について検討すべきである。ＩＡＢ－ＭＴは、タイプ２のインジケーションを受信するとＳＲを削減／停止し、タイプ３のインジケーションを受信する（即ち、親ＩＡＢノードでＢＨ ＲＬＦがなくなる）と動作を再開することが提案された。これは、親ノードがＢＨリンクを回復しようとするときに望ましいＩＡＢ－ＭＴの動作の１つである。全てのＲＢを中断するなど、他のＩＡＢ－ＭＴの動作も可能であると想定される。
【0172】
提案３：ＲＡＮ２は、ＩＡＢ－ＭＴがタイプ２のインジケーションを受信した後、スケジューリング要求を削減／停止し、親ノードでＢＨ ＲＬＦがなくなった場合に、スケジューリング要求を再開することに合意すべきである。
【0173】
「ＲＡＮ２は、ＢＨ ＲＬＦ後のサービス中断の削減に焦点を当てて、ＲＬＦインジケーション／ハンドリングの拡張について議論する」という合意を考慮すると、むしろ、ＩＡＢ－ＭＴがサービスの中断を削減するためにどのように動作するかについて議論すべきである。ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）の機能拡張は、ＢＨ ＲＬＦインジケーションと組み合わせると解決策の候補と見なされ得るが、これらはまだ検討中である。私たちの見解では、ローカルリルーティング及びＣＨＯの共通の側面は、ある種のトリガ条件を必要とすることである。そのため、タイプ２インジケーションがそのような目的で機能する可能性がある。したがって、ＲＡＮ２は、提案３に加えて、親がＢＨ ＲＬＦから回復しようとしているときの他のＩＡＢ－ＭＴの動作について議論すべきである。
【0174】
提案４：ＲＡＮ２は、タイプ２のＢＨ ＲＬＦインジケーションを受信した場合の他のＩＡＢ－ＭＴの動作について議論すべきである。更なる検討が必要であるが、例えば、ローカルリルーティング及び／条件付きハンドオーバをトリガするなど。
【0175】
（条件付きハンドオーバの拡張）
条件付きハンドオーバ（ＣＨＯ）は、モビリティの堅牢性を改善させるためにＲｅｌ－１６で導入される。私たちの理解では、ＣＨＯは指定されたＲｅｌ－１６ ＩＡＢに使用できる。ＲＡＮ２は、「ＣＨＯ及びＣＨＯの潜在的なＩＡＢ固有の拡張機能は検討中である」に合意した。したがって、Ｒｅｌ－１６ ＣＨＯベースラインに加えて、ｅＩＡＢのＣＨＯ拡張機能を検討する価値がある。Ｒｅｌ－１６ ＣＨＯでは、図２０に示すように、対応するＣＨＯイベント（Ａ３／Ａ５）が満たされたとき、又は選択されたセルがＲＲＣ再確立のためのセル選択の結果としてＣＨＯ候補であるときに実行される。
条件付きハンドオーバ（ＣＨＯ）は、モビリティの堅牢性を改善させるためにＲｅｌ－１６で導入される。私たちの理解では、ＣＨＯは指定されたＲｅｌ－１６ ＩＡＢに使用できる。ＲＡＮ２は、「ＣＨＯ及びＣＨＯの潜在的なＩＡＢ固有の拡張機能は検討中である」に合意した。したがって、Ｒｅｌ－１６ ＣＨＯベースラインに加えて、ｅＩＡＢのＣＨＯ拡張機能を検討する価値がある。Ｒｅｌ－１６ ＣＨＯでは、図２０に示すように、対応するＣＨＯイベント（Ａ３／Ａ５）が満たされたとき、又は選択されたセルがＲＲＣ再確立のためのセル選択の結果としてＣＨＯ候補であるときに実行される。
【0176】
ＣＨＯイベントＡ３／Ａ５は、ＩＡＢノードがＢＨリンクでＢＨ ＲＬＦを経験したときに満たすことができる。一方、これらのトリガ条件は、ＩＡＢ固有のＲＬＦ、つまりＢＨ ＲＬＦインジケーション（タイプ４）の受信によるＲＬＦでは、ＩＡＢノード自体のＢＨリンクの無線状態は良好であるため、満たすことができない。この場合、望ましい動作の１つは、ＩＡＢノードがＢＨ ＲＬＦインジケーションを受信したときにＣＨＯを実行することである。
【0177】
所見４：Ｒｅｌ－１６ ＣＨＯは、親のＢＨ ＲＬＦ回復が進行中であり、失敗したとしても、ＩＡＢ－ＭＴと親との間のＢＨリンクがまだ良好であるため、ＩＡＢ－ＭＴでＣＨＯイベントＡ３／Ａ５によって自動的にトリガ／実行されない。
【0178】
したがって、Ｒｅｌ－１７ ｅＩＡＢのトポロジ適応を改善するために、ＣＨＯの追加のトリガ条件について議論する価値がある。少なくとも既存のＢＨ ＲＬＦインジケーション（つまり、タイプ４）は、新しいトリガの有望な候補であると考えるが、導入された場合、タイプ２インジケーションの受信時にＣＨＯも実行すべきかについてさらに議論され得る。
【0179】
提案５：ＲＡＮ２は、少なくともＩＡＢノードがＢＨ ＲＬＦインジケーション（タイプ４）を受信した場合に、ＣＨＯの追加のトリガ条件が規定されているかどうかを議論すべきである。追加のトリガ条件が導入された場合、タイプ２に適用できるかどうかは更なる検討が必要である。
【0180】
提案５が合意される場合、ＣＨＯイベントＡ３／Ａ５に依存しないが、ＢＨ ＲＬＦインジケーションによる一種の「強制」トリガであるため、すべてのＣＨＯ候補（つまり、候補セル）が同時にＣＨＯをトリガされ得るという問題が発生する可能性がある。
【0181】
現在の仕様では、「条件付き再設定の実行で複数のＮＲセルがトリガされる場合、どれを選択するかはＵＥの実装次第である。例えば、ＵＥは、ビーム及びビーム品質を考慮して、実行のためにトリガされたセルの１つを選択する。」とされている。これは主にＵＥを対象としている。
【0182】
所見５：Ｒｅｌ－１６ ＣＨＯでは、複数の候補セルがＣＨＯ実行をトリガする場合、どのセルを選択するかはＵＥの実装次第である。
【0183】
トポロジ全体の目的がＩＡＢドナーによって適切に処理されるため、ＩＡＢ－ＭＴに関しては、ＩＡＢ－ＭＴがローカル無線品質などに応じて実装によってトリガされたセルの１つを選択する場合、常に最良とは限らない。したがって、ＲＡＮ２は、提案５のような追加のトリガ条件のためにＩＡＢドナー制御のＣＨＯの実行を確認する方法について議論すべきである。例えば、ＩＡＢドナーは、ＣＨＯ設定におけるＣＨＯ候補に関連付けられた優先度情報を設定してもよい。ＩＡＢ－ＭＴは、特定の無線品質（Ｓ－ｃｒｉｔｅｒｉｏｎなど）を満たすすべてのトリガされたＣＨＯ候補から最も優先度の高いセルを選択すべきである。
【0184】
提案６：ＲＡＮ２は、ＢＨ ＲＬＦインジケーションの受信により、すべての候補セルがＣＨＯをトリガする場合に、追加の拡張機能としてＩＡＢドナー制御のＣＨＯ実行が必要かどうかを検討すべきである。
【0185】
（ローカルリルーティングの拡張）
Ｒｅｌ－１６では、以下の記載のように、ローカルリルーティングはＢＨ ＲＬＦが発生した場合にのみ許可される。
ＮＯＴＥ：例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングは実装次第である。ＢＨ ＲＬＦの場合、ＢＡＰエンティティの送信部分は、ＢＨ ＲＬＦの前に下位レイヤによって受け入れられていないＢＡＰデータＰＤＵを代替パスにリルーティングしてもよい。
Ｒｅｌ－１６では、以下の記載のように、ローカルリルーティングはＢＨ ＲＬＦが発生した場合にのみ許可される。
ＮＯＴＥ：例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングは実装次第である。ＢＨ ＲＬＦの場合、ＢＡＰエンティティの送信部分は、ＢＨ ＲＬＦの前に下位レイヤによって受け入れられていないＢＡＰデータＰＤＵを代替パスにリルーティングしてもよい。
【0186】
これは、ＢＨ ＲＬＦによる堅牢性及びサービスの中断を改善するためにローカルリルーティングが有益であることを示している。したがって、Ｒｅｌ－１７は、ＲＡＮ２が合意した、負荷分散、シグナリングの削減、堅牢性及び／又はサービスの中断を改善する他のケースにローカルリルーティングを適用することを目的とすべきである。（堅牢性／サービスの中断を改善するために）提案４のようにＢＨ ＲＬＦインジケーションを受信することによって、及び／又は（負荷分散／輻輳緩和のために）フロー制御フィードバックを受信することによってなど、ＢＨ ＲＬＦ以外のローカルリルーティングを開始／停止するための追加条件を検討する価値がある。つまり、一般的に、親及び／又は子は、条件によってはＩＡＢノードのローカルリルーティングをトリガできるべきである。
【0187】
所見６：Ｒｅｌ－１６では、ローカルリルーティングはＢＨ ＲＬＦの場合にのみ許可される。これにより、堅牢性とサービスの中断が改善される。
【0188】
提案７：ＲＡＮ２は、ローカルリルーティングを開始／停止する追加の条件が導入されるかを議論すべきである。これにより、提案１のようにＢＨ ＲＬＦインジケーションを受信することによって、及び／又はフロー制御フィードバックを受信することによってなど、他のＩＡＢノードがトリガできるようになる。
【0189】
合意される場合、Ｒｅｌ－１７における他の場合、すなわち、ＢＨ ＲＬＦに限らず、「ＲＡＮ２は、セントラルルート決定に対する利点を含むローカルリルーティング、及びトポロジ全体の目標に対処する方法について議論する。」したがって、Ｒｅｌ－１６の課題は、トポロジ全体の客観的な観点から検討すべきである。言うまでもなく、ＩＡＢドナーは、ＩＡＢトポロジ全般について完全な知識及び完全な制御を持っているため、トポロジ全体の目的を処理する。
【0190】
Ｒｅｌ－１６のローカルリルーティングでは、宛先が同じである限り、代替パスとしてパスが選択されるのはＩＡＢノードの実装次第である。これは、ローカルリルーティングがローカルの決定に基づいており、ＩＡＢドナーの観点からは制御できないことを意味する。これは、特に、多くのローカルの決定が発生してＩＡＢトポロジに蓄積される場合、トポロジ全体の目的と一致しない可能性がある。
【0191】
所見７：Ｒｅｌ－１６のローカルリルーティングでは、代替パスとしてどのパスが選択されるかはＩＡＢ－ＭＴの実装次第である。
【0192】
したがって、ローカルリルーティングがＢＨ ＲＬＦの場合を超えて拡張される場合、ＩＡＢドナーの可制御性はより重要になるはずである。ＩＡＢノードはローカルリルーティングを実行するときに代替パスを選択する必要があるから、ＩＡＢドナーが代替パスを設定できることは明快である。代替パスのモデリングは、代替パスが同じルーティングＩＤを持っているかどうかなど、更なる検討が必要である。
【0193】
提案８：ＲＡＮ２は、ＩＡＢドナーがＲｅｌ－１６のルーティング設定に加えて代替パスをＩＡＢノードに設定できるかどうかを検討すべきである。
【0194】
ＩＡＢドナーの可制御性の他の側面として、ＩＡＢドナーはローカルリルーティングを認識すべきであって、ローカルリルーティングとトポロジ全体の目的の共存のために、ＩＡＢノードでローカルリルーティングを開始／停止してもよいことを考慮すべきである。例えば、ＩＡＢドナーは、どのＩＡＢノードが現在ローカルリルーティングを実行しているかの認識に基づいて、トポロジ全体の目的がまだ達成されているかどうかを検討してもよい。ＩＡＢドナーがトポロジ全体の目的を達成できないことに気付いた場合、ＩＡＢドナーはＩＡＢノードにローカルリルーティングを開始／停止するように指示するか、ＩＡＢドナーがＩＡＢトポロジ全体のルーティング設定を変更してもよい。
【0195】
ローカルリルーティングにより、トポロジ全体の目的をどのように処理するかは、完全にＩＡＢドナーの実装次第であるが、ＩＡＢドナーは、ＩＡＢノードのローカル決定の情報及び制御性を必要とするかもしれない。
【0196】
提案９：ＲＡＮ２は、ローカルリルーティングの開始／停止時にＩＡＢノードがＩＡＢドナーに通知する必要があるかどうかを議論すべきである。
【0197】
提案１０：ＲＡＮ２は、ＩＡＢドナーがＩＡＢノードにローカルリルーティングを開始／停止するように指示できるかどうかについて議論すべきである。
【0198】
（ＢＨ ＲＬＦ回復及びセル（再）選択の拡張）
ＲＲＣ再確立手順では、ＩＡＢ－ＭＴは、適切なセルを見つけるために、最初にセル選択手順を実行する。このセル選択手順では、ＩＡＢ－ＭＴが子孫ノードを選択する可能性があるなど、潜在的な課題がＲｅｌ－１６で指摘された。従って、それはＥメールディスカッションで議論された。
ＲＲＣ再確立手順では、ＩＡＢ－ＭＴは、適切なセルを見つけるために、最初にセル選択手順を実行する。このセル選択手順では、ＩＡＢ－ＭＴが子孫ノードを選択する可能性があるなど、潜在的な課題がＲｅｌ－１６で指摘された。従って、それはＥメールディスカッションで議論された。
【0199】
図２１に示すように、考えられる５つの解決策について、ラポーターの見解とともに議論及び要約した。
【0200】
結論は、「Ｒｅｌ－１６ではこのトピックに関してこれ以上のアクションは取らない」であった。これは、ＲＡＮ２が「オプション４：ＢＨ接続がない場合、ＲＲＣ再確立は失敗するため、何も必要ない」に合意したことを意味する。オプション４は、失敗（Ｔ３０１の満了）を待ち、最終的にアイドルに移動する必要があるため、ＢＨ ＲＬＦ回復にさらに時間が必要である場合でも、Ｒｅｌ－１６の展開シナリオでは受け入れ可能であった。
【0201】
所見８：Ｒｅｌ－１６では、ＩＡＢノードが子孫ノードに対してＲＲＣ再確立要求を試行した場合、ＩＡＢノードはその失敗を待ち、最終的にアイドルに移動する必要がある。
【0202】
Ｒｅｌ－１７では、所見２の観点から、セル（再）選択及びＲＲＣ再確立がさらに頻繁に発生する可能性がある。従って、準最適な動作、即ち、所見８に従う動作は、ＩＡＢトポロジの安定性及びサービス継続性の観点からパフォーマンスが大幅に低下を引き起こすであろう。従って、ＢＨ ＲＬＦ回復中のＩＡＢ－ＭＴの動作を最適化するために、上記のメールディスカッションのラポーターが述べているように、「このトピックについては、Ｒｅｌ－１７で再度議論され得る」。
【0203】
提案１１：ＲＡＮ２は、不適切なノード（例えば、子孫ノード）への再確立を回避するために、セル（再）選択の最適化が検討されることに合意すべきである。
【0204】
上記のオプション４を除いて特定された解決策の中で、共通概念は、セル選択の目的で、ＩＡＢ－ＭＴは許可リストまたはブロックリストのいずれかの種類で提供されることであると見なされ得る。例えば、「インタードナーＩＡＢノードの移動」によって、トポロジ変更がＲｅｌ－１７で頻繁に発生する可能性があることを考えると、許可リストとブロックリストには、トポロジ及びＩＡＢノードの位置に応じて長所と短所とがある。
【0205】
例えば、ＩＡＢドナーの近くのＩＡＢノード、即ち、ＤＡＧトポロジの最上位の観点からは、候補ノードの数が少なく、場合によってはＩＡＢドナーＤＵのみであるため、許可リストを提供する方が合理的である。
【0206】
しかしながら、ＩＡＢドナーから遠く離れたＩＡＢノード、即ち、ＤＡＧトポロジの最下位からの観点である別の例では、許可リストに膨大な数の候補ノードを含める必要があるかもしれない。代わりに、ブロックリストは、例えば、懸念されるＩＡＢノードのダウンストリームＩＡＢノードのみを含み、場合によっては少数の子ＩＡＢノードのみを含むため、オーバーヘッドを削減するため、より適切な場合がある。
【0207】
許可リストの懸念事項の１つは、Ｒｅｌ－１７の「インタードナーＩＡＢノードの移動」の性質上、異なる／隣接するＩＡＢトポロジに属する候補のＩＡＢノードを含める必要がある場合があり、リストのサイズが大きくなる可能性があることである。一方で、ダウンストリームＩＡＢノードは同じＩＡＢトポロジに属していることは言うまでもないため、ブロックリストにはそのような懸念はない。
【0208】
所見９：許可リスト及びブロックリストには、ＩＡＢノードのトポロジ及び位置に応じて長所と短所とがある。
【0209】
従って、セル選択の目的で子ＩＡＢノードに情報を提供する場合、ＩＡＢドナー（又は親ＩＡＢノード）が許可リスト又はブロックリストのどちらかを使用するかを選択できることが望ましい場合がある。なお、当該情報がセル再選択の目的で再利用することが有益であるかどうかも検討されるべきである。
【0210】
提案１２：ＲＡＮ２は、子孫ノードへの再確立を回避するために、セル選択の目的でＩＡＢ－ＭＴに許可リスト又はブロックリスト（即ち、選択構造）が提供されることに合意すべきである。これらのリストをセル再選択手順にも使用できるかは更なる検討が必要である。
【0211】
提案１２に合意できる場合、情報（即ち、許可リスト又はブロックリスト）がどのように提供されるかをさらに検討すべきである。オプション１は、ＣＨＯ設定を想定しており、いくつかの拡張が必要になる可能性がある。オプション２は、追加のインジケーションを想定しており、例えば、タイプ２のＢＨ ＲＬＦインジケーションなどである。オプション３は、既存設定にはないトポロジ全体の情報を提供することを想定している。オプション５は、ＯＡＭによる設定を想定しているが、ラポーターが指摘したように、これは疑わしい。
【0212】
Ｒｅｌ－１７の想定（即ち、所見２）、即ち、トポロジ変更が生じたら、親ＩＡＢノード又はＩＡＢドナーが子ＩＡＢノードにリストを提供すべきであることを再度考慮すると、許可リスト／ブロックリストは動的に提供される必要がある。従って、オプション５、即ち、ＯＡＭは除外すべきである。どの方法、即ち、オプション１、２、又は３のうちのどの方法を拡張のベースラインにするかは、更なる検討が必要である。
【0213】
提案１３：ＲＡＮ２は、トポロジが変更されるたびに、許可リスト／ブロックリストが親ＩＡＢノード又はＩＡＢドナーによって動的に提供されることに合意すべきである。詳細は更なる検討が必要である。
【0214】
（ロスレス配信の拡張）
Ｒｅｌ－１５の研究段階では、マルチホップＲＬＣ ＡＲＱの課題が、ＴＲのセクション８．２．３で議論され、キャプチャされた。Ｒｅｌ－１６では、プロトコルスタックは分離されていないＲＬＣ層を有するＩＡＢに対して定義された。つまり、Ｒｅｌ－１６では、ｅｎｄ－ｔｏ－ｅｎｄ ＡＲＱは除外され、ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱが採用された。
Ｒｅｌ－１５の研究段階では、マルチホップＲＬＣ ＡＲＱの課題が、ＴＲのセクション８．２．３で議論され、キャプチャされた。Ｒｅｌ－１６では、プロトコルスタックは分離されていないＲＬＣ層を有するＩＡＢに対して定義された。つまり、Ｒｅｌ－１６では、ｅｎｄ－ｔｏ－ｅｎｄ ＡＲＱは除外され、ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱが採用された。
【0215】
ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱに関しては、ｅｎｄ－ｔｏ－ｅｎｄの信頼性、即ち、ＵＬパケットでのロスレス配信における課題が特定された。図２２に示すように、３つの解決策が特定され、評価された。
【0216】
Ｒｅｌ－１６では、第１の解決策である「ＰＤＣＰプロトコル／手順の変更」はＲｅｌ－１５ ＵＥに影響を与えるため、採用されなかった。
【0217】
第２の解決策である「中間ＩＡＢノードでバッファリングされたＰＤＣＰ ＰＤＵのリルーティング」は、ＢＡＰレイヤでの実装選択としてサポートされた。さらに、ＢＡＰレイヤは、「例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングすることは、実装依存」で実行してもよい。これらのＢＡＰ実装は、Ｒｅｌ－１６展開シナリオの「ほとんど」の場合、即ち、固定ＩＡＢノードを使用した場合、パケット損失を回避するために考慮されたが、例えば、図３６のように完全ではなかった。
【0218】
第３の解決策である「ＵＬステータス配信の導入」は、図３６に引用されている評価結果を考慮して、ＵＬデータのロスレス配信を保証するための有望な解決策であった。アイデアは、ＵＥへのＲＬＣ ＡＲＱを遅延させ、ＵＥでのＰＤＣＰデータ回復が必要なときに開始されるようにすることであった。しかしながら、固定ＩＡＢノードが想定されていたため、トポロジ変更によりＵＬパケットがドロップされることはまれであると見なされていたため、Ｒｅｌ－１６では規定されなかった。
【0219】
Ｒｅｌ－１７の想定を考えると、即ち、提案１の観点から、Ｒｅｌ－１７で頻繁に発生するトポロジ変更中にＵＬパケットを損失することがもはやまれではないため、第３の解決策をさらに検討すべきである。従って、ＲＡＮ２は、ＴＲでキャプチャされた結果に加えて、Ｌ２マルチホップネットワーク内でロスレス配信を保証するための拡張メカニズムについて議論すべきである。
【0220】
提案１４：ＲＡＮ２は、ＴＲ３８．８７４で特定される解決策、即ち、何らかの形式の「ＵＬステータス配信」に基づいてトポロジ変更が頻繁に発生する可能性がある条件下で、ロスレス配信を保証するメカニズムを導入することに合意すべきである。
【0221】
第３の解決策、即ち、「ＵＬステータス配信の導入」の詳細については、図２３に示すように、ＥメールディスカッションでＣ－１及びＣ－２の２つのオプションについて議論した。
【0222】
上記のＣ－１に関して、マルチホップＬ２ネットワークを介したｅｎｄ－ｔｏ－ｅｎｄのシグナリング転送のために、ＩＡＢドナーからの「確認」をＢＡＰ又はＲＲＣで規定する必要があると想定される。従って、このオプションを規定するためには、比較的高い標準的な取り組みが必要になるであろう。
【0223】
上記のＣ－２に関して、ＩＡＢトポロジで十分に機能する場合、ＯＡＭがこのオプションを使用して全てのＩＡＢノードを設定すると想定される必要があっても、ＲＬＣ ＡＣＫをＵＥ（又はダウンストリームＩＡＢノード）に送信する場合、最終的にＩＡＢ－ＤＵ実装に依存するため、Ｒｅｌ－１６ ＩＡＢノードに対しても実際に実装可能である。さらに、ｈｏｐ－ｂｙ－ｈｏｐフィードバックを想定し、追加のＣｏｎｔｒｏｌ ＰＤＵを想定しないため、Ｃ－１よりも簡単である。従って、Ｃ－２は、ＵＬパケットのロスレス配信のためのＲｅｌ－１７の拡張ベースラインであるべきである。
【0224】
所見１０：「ＵＬステータス配信の導入」の解決策であるＣ－２は、Ｒｅｌ－１７の拡張ベースラインとなる可能性があり、これは、Ｒｅｌ－１６に対しても実装可能である。
【0225】
但し、Ｒｅｌ－１７は、ＵＬパケット損失を引き起こす動的なトポロジ変更を想定すべきであるため、Ｒｅｌ－１７の拡張はＣ－２を標準のサポート機能としてサポートするであろう。少なくともステージ２の仕様では、Ｃ－２に基づく全体的なメカニズムを説明すべきである。それ以外の場合、３ＧＰＰ標準では、ＩＡＢノードのハンドオーバ中にロスレス配信が保証されない。さらに、ステージ３ではＲＬＣ及び／又はＢＡＰなどの小さな変更が予想されるが、ＩＡＢノードの内部動作と見なされるため、詳細を規定しない可能性もある。
【0226】
提案１５：ＲＡＮ２は、ステージ２でＵＬパケットをロスレス配信するためのＲＬＣ ＡＲＱメカニズムを規定することに合意すべきである。これは、親ＩＡＢノードからＡＣＫを受信する前に、子ノード／ＵＥへのＡＣＫの送信を遅らせる（即ち、Ｃ－２）。ステージ３で規定するかどうか／どのように規定するかは更なる検討が必要である。
【0227】
（ドナー間のＩＡＢノードの移動）
ＩＡＢノード統合手順はＲｅｌ－１６に導入されており、これは、ＩＡＢノードの初期統合に使用される。つまり、まだサービス外の段階にある。
ＩＡＢノード統合手順はＲｅｌ－１６に導入されており、これは、ＩＡＢノードの初期統合に使用される。つまり、まだサービス外の段階にある。
【0228】
Ｒｅｌ－１７は、インタードナーＩＡＢノードの移動を指定することを目的としており、これは、堅牢な操作を提供し、モバイルＩＡＢノードに適用される予定である。Ｒｅｌ－１６とは対照的に、Ｒｅｌ－１７のインタードナーＩＡＢノードの移動は稼働中のフェーズで実行されるため、１つのＩＡＢノードのインタードナーＩＡＢノードの移動により、トポロジ全体に影響が生じ、サービスの中断を引き起こす。言い換えると、Ｒｅｌ－１７のインタードナーＩＡＢノードの移動では、ＩＡＢトポロジ内のすべてのＩＡＢノードが他のＩＡＢドナーに移動する方法、具体的には、同期を伴うＲＲＣ再設定（つまり、ハンドオーバコマンド）がこれらの影響を受けるＩＡＢノードにどのように提供されるか、を検討する必要がある。
【0229】
図２４に示すように、子ノード（ＩＡＢノード♯２）が親ノード（ＩＡＢノード♯１）を介してソースＩＡＢドナーに接続されていると仮定すると、一組のシグナリングの問題が考えられる。
【0230】
・ケース１：親が最初に移動された場合、子とソースドナー間のＲＲＣシグナリングパスが解放される。そのため、子ノードをどのように移動できるかは不明である。
・ケース２：子が最初に移動された場合、親ノードを介したターゲットドナーへのＲＲＣシグナリングパスはまだ確立されていない。そのため、子ノードがターゲットドナーにどのようにアクセスするか（つまり、ＲＲＣ再設定を完了してターゲットドナーに送信する方法）は不明である。
・ケース２：子が最初に移動された場合、親ノードを介したターゲットドナーへのＲＲＣシグナリングパスはまだ確立されていない。そのため、子ノードがターゲットドナーにどのようにアクセスするか（つまり、ＲＲＣ再設定を完了してターゲットドナーに送信する方法）は不明である。
【0231】
ケース１の場合、ＣＨＯは、子ノードのいくつかの拡張機能を使用して再利用されてもよい。つまり、親ノードが移動されるときに、子ノードでＣＨＯが実行される。
ケース２の場合、子ノードのＲＲＣ再設定のターゲットドナーへの送信は、例えば、その親ノードによって遅延されてもよい。
ケース２の場合、子ノードのＲＲＣ再設定のターゲットドナーへの送信は、例えば、その親ノードによって遅延されてもよい。
【0232】
どちらの場合も、子ノードが最初に解放され、Ｒｅｌ－１６手順を使用して再統合されることが１つのオプションである可能性がある。ただし、重大なサービスの中断を考慮すると、Ｒｅｌ－１７のために望ましい解決策ではない可能性がある。
【0233】
インタードナーＩＡＢノードの移動の全体的な手順はＲＡＮ３で検討されているが、ＲＡＮ２は、マルチホップネットワークで複数のＩＡＢノードを再設定する方法に対するＲＡＮ２の影響について検討する必要がある。
【0234】
提案１６：ＲＡＮ２は、インタードナーＩＡＢノード移動のためにマルチホップＩＡＢノードを再設定する方法について検討する必要がある。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】