知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-16
(45)【発行日】2024-08-26
(54)【発明の名称】通信制御方法、中継ノード及びプロセッサ
(51)【国際特許分類】
H04W 76/19 20180101AFI20240819BHJP
H04W 48/16 20090101ALI20240819BHJP
H04W 16/26 20090101ALI20240819BHJP
H04W 92/20 20090101ALI20240819BHJP
【ＦＩ】
H04W76/19
H04W48/16 130
H04W16/26
H04W92/20 110
【請求項の数】
3
(21)【出願番号】P 2022541723
(86)(22)【出願日】2021-08-05
(86)【国際出願番号】 JP2021029098
(87)【国際公開番号】W WO2022030575
(87)【国際公開日】2022-02-10
【審査請求日】2023-02-03
(31)【優先権主張番号】63/061,883
(32)【優先日】2020-08-06
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】チャン ヘンリー
【審査官】松野 吉宏
(56)【参考文献】
【文献】国際公開第２０２０／０５９４７０（ＷＯ，Ａ１）
【文献】ZTE, Sanechips，Discussion on IAB RLF and IAB reestablishment，3GPP TSG RAN WG3#105bis R3-195685，フランス，3GPP，2019年10月04日
【文献】ZTE, Sanechips，Discussion on IAB BH RLF handling，3GPP TSG RAN WG2#109_e R2-2000509，フランス，3GPP，2020年02月14日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４ － ７／２６
Ｈ０４Ｗ ４／００ － ９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
上位ノードとの無線バックホールリンクを有する中継ノードを用いる通信制御方法であって、前記中継ノードが、前記無線バックホールリンクの障害を検知した後、前記無線バックホールリンクを再確立するためのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）再確立処理を開始するか否かを判断することと、
前記中継ノードが、前記ＲＲＣ再確立処理を開始すると判断した場合、前記ＲＲＣ再確立処理を開始することと、
前記中継ノードが、前記ＲＲＣ再確立処理の開始に応じて、前記無線バックホールリンクの障害の検知を示す障害情報を、前記中継ノードの下位ノードに送信することと、
前記中継ノードが、前記中継ノードからの要求に応じて前記上位ノードから取得した許可セル情報に基づいて、前記中継ノードのサービングセルとして適切なセルを選択する処理を行うことと、を有し、
前記許可セル情報は、前記中継ノードが前記サービングセルとして選択することが許可されるセルを識別する
通信制御方法。
【請求項2】
上位ノードとの無線バックホールリンクを有する中継ノードであって、前記無線バックホールリンクの障害を検知した後、前記無線バックホールリンクを再確立するためのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）再確立処理を開始するか否かを判断する制御部と、
送信部と、を備え、
前記制御部は、前記ＲＲＣ再確立処理を開始すると判断した場合、前記ＲＲＣ再確立処理を開始し、
前記送信部は、前記ＲＲＣ再確立処理の開始に応じて、前記無線バックホールリンクの障害の検知を示す障害情報を、前記中継ノードの下位ノードに送信し、
前記制御部は、前記中継ノードからの要求に応じて前記上位ノードから取得した許可セル情報に基づいて、前記中継ノードのサービングセルとして適切なセルを選択する処理を行い、
前記許可セル情報は、前記中継ノードが前記サービングセルとして選択することが許可されるセルを識別する
中継ノード。
【請求項3】
上位ノードとの無線バックホールリンクを有する中継ノードを制御するプロセッサであって、前記無線バックホールリンクの障害を検知した後、前記無線バックホールリンクを再確立するためのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）再確立処理を開始するか否かを判断する処理と、
前記ＲＲＣ再確立処理を開始すると判断した場合、前記ＲＲＣ再確立処理を開始する処理と、
前記ＲＲＣ再確立処理の開始に応じて、前記無線バックホールリンクの障害の検知を示す障害情報を、前記中継ノードの下位ノードに送信する処理と、
前記中継ノードからの要求に応じて前記上位ノードから取得した許可セル情報に基づいて、前記中継ノードのサービングセルとして適切なセルを選択する処理と、を実行し、
前記許可セル情報は、前記中継ノードが前記サービングセルとして選択することが許可されるセルを識別する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、移動通信システムで用いる通信制御方法に関する。
【背景技術】
【0002】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードが規定されている（例えば、「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．２．０ （２０２０－０７）」参照）。１又は複数の中継ノードが基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
【発明の概要】
【0003】
第１の態様に係る通信制御方法は、無線バックホールリンクを有する中継ノードが、前記無線バックホールリンクの障害に関するイベントの発生に応じて、前記無線バックホールリンクを復旧するための復旧処理を行うことを有する。前記復旧処理を行うことは、前記復旧処理の一部として、前記無線バックホールリンクを再確立するためのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）再確立処理を開始する際に、前記イベントの発生を示す障害情報を、前記中継ノードの下位ノードに送信することを有する。
【0004】
第２の態様に係る通信制御方法は、無線バックホールリンクを有する第１中継ノードが、前記無線バックホールリンクの再確立の対象セルを決定するためのセル選択手順を行う際に使用するセル情報を、ドナー基地局から受信することを有する。前記セル情報は、前記対象セルとして選択することが許可されるセルを識別する許可セル情報と、前記対象セルとして選択することが許可されないセルを識別する非許可セル情報と、のいずれか１つを含む。
【0005】
第３の態様に係る通信制御方法は、無線バックホールリンクを有する第１中継ノードが、前記第１中継ノードの配下の第２中継ノードに、前記第２中継ノードをＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）インアクティブ状態に遷移させるためのメッセージを送信することを有する。
【図面の簡単な説明】
【0006】
【図1】実施形態に係る移動通信システム１の構成を示す図である。
【図2】実施形態に係るｇＮＢ２００の構成を示す図である。
【図3】実施形態に係るＩＡＢノード３００の構成を示す図である。
【図4】実施形態に係るＵＥ１００の構成を示す図である。
【図5】実施形態に係るユーザプレーンのプロトコルスタックの一例を示す図である。
【図6】実施形態に係る制御プレーン（Ｆ１－Ｃ）のプロトコルスタックの一例を示す図である。
【図7】実施形態に係る制御プレーン（ＲＲＣ及びＮＡＳ）のプロトコルスタックの一例を示す図である。
【図8】実施形態に係るＩＡＢトポロジを示す図である。
【図9】第１実施形態の動作例１を示す図である。
【図10】第１実施形態の動作例２を示す図である。
【図11】第２実施形態の動作例を示す図である。
【図12】第３実施形態の動作例を示す図である。
【図13】ＢＨ ＲＬＦ通知のタイプを示す図である。
【図14】子孫ノードへの再確立を回避するための特定された解決策を示す図である。
【図15】ｈｏｐ－ｂｙ－ｈｏｐ ＲＬＣ ＡＲＱの場合のＵＬデータのロスレス配信のメカニズムの比較を示す図である。
【図16】ＵＬステータス配信の導入のオプションを示す図である。
【発明を実施するための形態】
【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】
Ｒｅｌ－１７の拡張では、意図されたユースケースの1つは「モバイルＩＡＢノード」であり、ＷＩＤに明示的に記載されていなくても、「インタードナーＩＡＢノード移動」の一部である可能性がある。さらに、「ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能」及び「トポロジの冗長性に対する拡張」のようなＷＩＤにおけるサブ目的は、ＢＨリンクが安定していないことを明確に意図しており、移動及びＢＨ ＲＬＦはＲｅｌ－１７展開のシナリオで頻繁に発生する。従って、Ｒｅｌ－１７の議論によれば、ＲＡＮ２は最初にＢＨリンクの想定について共通の理解を有するべきである。
【0208】
提案１：ＲＡＮ２は、バックホールリンクの品質が動的に変化することを想定すべきである。従って、バックホールＲＬＦは、Ｒｅｌ－１７ ｅＩＡＢのようにまれなケースではない。
【0209】
（ＢＨ ＲＬＦインジケーションの拡張）
Ｒｅｌ－１６のＥメールディスカッションでは、図１３に示すような４種類のＢＨ ＲＬＦ通知が議論された。
Ｒｅｌ－１６のＥメールディスカッションでは、図１３に示すような４種類のＢＨ ＲＬＦ通知が議論された。
【0210】
最後に、タイプ４の「回復失敗」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして規定され、これにより、子ＩＡＢ－ＭＴはＢＨリンク上のＲＬＦを考慮し、ＲＬＦ回復手順を開始する。
【0211】
所見３：Ｒｅｌ－１６では、タイプ４の「回復障害」のみがＢＨ ＲＬＦインジケーションとして規定された。
【0212】
一方で、多くの企業は依然として他の種類のインジケーションが有益であると考えていたので、それはＥメールでさらに議論された。１３社中８社がタイプ２の「回復を試みている」を導入することを好み、他の２社はＲｅｌ－１７で議論されると考えた。従って、大多数の企業は、Ｒｅｌ－１７にタイプ２のインジケーションを導入する準備ができていると考えていると見なされ得る。ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ、ＳＩＢ１、又はその両方を使用することなどによって、タイプ２のインジケーションを送信する方法は、更なる検討が必要である。なお、タイプ１及びタイプ２は全く同じ意味である。
【0213】
提案２：ＲＡＮ２は、ＢＨ ＲＬＦインジケーションのタイプ２の「回復を試みている」が導入されていることに合意すべきである。ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ、ＳＩＢ１、又はその両方を介して送信されるかは更なる検討が必要である。
【0214】
さらに、１３社のうち９社が、Ｒｅｌ－１７でもタイプ３の「ＢＨリンク回復」について議論することに合意した。詳細には、そのような明示的なインジケーションは本当に必要かが検討され得る。例えば、タイプ２のインジケーションがＳＩＢ１を介して送信される場合、ＢＨリンクがＲＬＦの下にない（即ち、「回復される」）と、インジケーションはブロードキャストされなくなる。従って、ダウンストリームＩＡＢノード及びＵＥは、ＳＩＢ１にタイプ２のインジケーションがないことに基づいてＢＨリンクが回復したかどうかを認識するであろう。もちろん、タイプ３のインジケーションがＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを介して送信される場合、ダウンストリームＩＡＢノードがＢＨリンク回復をすばやく知ることができるという利点がある。但し、この場合、ＵＥはＢＡＰレイヤを持たないため、事実を知ることができない。従って、ＲＡＮ２は、タイプ３のインジケーションが必要かを議論すべきである。
【0215】
提案３：提案３に合意できる場合、ＲＡＮ２は、ＢＨ ＲＬＦがなくなったときの明示的なＢＨ ＲＬＦインジケーション、即ち、タイプ３の「ＢＨリンク回復」が導入されるかについて議論すべきである。
【0216】
提案２及び／又は提案３に合意できる場合、インジケーションを受信したＩＡＢ－ＭＴのＢＨリンクの回復下における動作を検討すべきである。ＩＡＢ－ＭＴは、タイプ２を受信するとＳＲを削減/停止し、タイプ３を受信する（即ち、親ＩＡＢノードでＢＨ ＲＬＦがなくなる）と動作を再開することが提案された。これは、親ノードがＢＨリンクを回復しようとするときに望ましいＩＡＢ－ＭＴの動作の1つである。全てのＲＢを中断するなど、他のＩＡＢ－ＭＴの動作も可能であると想定される。
【0217】
提案４：ＲＡＮ２は、ＩＡＢ－ＭＴがタイプ２のインジケーションを受信した後、スケジューリング要求を削減/停止し、親ノードでＢＨ ＲＬＦがなくなった場合に、スケジューリング要求を再開することに合意すべきである。
【0218】
提案５：ＲＡＮ２は、親ノードがＢＨリンクを回復しようとしている間、他のＩＡＢ－ＭＴの動作がある場合について、議論すべきである。
【0219】
インジケーションを送信するＩＡＢ－ＤＵに関して、ＩＡＢノードのBHリンクがRLF下にある場合、タイプ２のＢＨ ＲＬＦインジケーションを送信することが想定される。このＢＨリンクでＲＬＦが発生するとインジケーションが送信されるため、単一接続のＢＨの場合は簡単である。しかしながら、二重接続のＢＨの場合は少し複雑になる。例えば、ＩＡＢノードがＭＣＧでＲＬＦを検出すると、ＭＣＧ障害情報手順を開始するが、ＳＣＧは引き続きＢＨリンクとして機能するため、この時点でタイプ２のインジケーションを送信する必要がない可能性がある。Ｔ３１６の満了などで、ＭＣＧ障害情報手順が失敗した場合、ＩＡＢ－ＭＴはＲＲＣ再確立を開始するため、この時点でタイプ２のインジケーションが送信される。従って、タイプ２のインジケーションは、ＭＣＧ／ＳＣＧ障害情報がトリガされたときではなく、ＲＲＣ再確立が開始されたときに送信される。いずれにせよ、これはＩＡＢ－ＤＵの動作を対象としているため、仕様にキャプチャするかどうか／どのようにキャプチャするかを慎重に検討すべきである。即ち、ステージ２、ステージ３で、ｎｏｔｅを追加するか或いは何もキャプチャする必要がないかを検討すべきである。
【0220】
提案６：ＲＡＮ２は、ＩＡＢ－ＤＵがＲＬＦ回復手順のいずれかを開始するときではなく、ＲＲＣ再確立を開始するときに、タイプ２のＢＨ ＲＬＦインジケーションを送信する可能性があることに合意すべきである。
【0221】
提案７：ＲＡＮ２は、仕様でＩＡＢ-ＤＵの動作（即ち、提案６）をキャプチャするかどうか/どのようにキャプチャするかについて議論すべきである。
【0222】
（ＢＨ ＲＬＦ回復及びセル（再）選択の拡張）
ＲＲＣ再確立手順では、ＩＡＢ－ＭＴは、適切なセルを見つけるために、最初にセル選択手順を実行する。このセル選択手順では、ＩＡＢ－ＭＴが子孫ノードを選択する可能性があるなど、潜在的な課題がＲｅｌ－１６で指摘された。従って、それはＥメールディスカッションで議論された。
ＲＲＣ再確立手順では、ＩＡＢ－ＭＴは、適切なセルを見つけるために、最初にセル選択手順を実行する。このセル選択手順では、ＩＡＢ－ＭＴが子孫ノードを選択する可能性があるなど、潜在的な課題がＲｅｌ－１６で指摘された。従って、それはＥメールディスカッションで議論された。
【0223】
図１４に示すように、考えられる５つの解決策について、ラポーターの見解とともに議論及び要約した。
【0224】
結論は、「Ｒｅｌ－１６ではこのトピックに関してこれ以上のアクションは取らない」であった。これは、ＲＡＮ２が「オプション４：ＢＨ接続がない場合、ＲＲＣ再確立は失敗するため、何も必要ない」に合意したことを意味する。オプション４は、失敗（Ｔ３０１の満了）を待ち、最終的にアイドルに移動する必要があるため、ＢＨ ＲＬＦ回復にさらに時間が必要である場合でも、Ｒｅｌ－１６の展開シナリオでは受け入れ可能であった。
【0225】
所見４：Ｒｅｌ－１６では、ＩＡＢノードが子孫ノードに対してＲＲＣ再確立要求を試行した場合、ＩＡＢノードはその失敗を待ち、最終的にアイドルに移動する必要がある。
【0226】
Ｒｅｌ－１７では、提案１の観点から、セル（再）選択及びＲＲＣ再確立が頻繁に発生する可能性がある。従って、準最適な動作、即ち、所見４に従う動作は、ＩＡＢトポロジの安定性及びサービス継続性の観点からパフォーマンスが大幅に低下を引き起こすであろう。従って、ＢＨ ＲＬＦ回復中のＩＡＢ－ＭＴの動作を最適化するために、上記のメールディスカッションのラポーターが述べているように、「このトピックについては、Ｒｅｌ－１７で再度議論され得る」。
【0227】
提案８：ＲＡＮ２は、不適切なノード（例えば、子孫ノード）への再確立を回避するために、セル（再）選択の最適化が検討されることに合意すべきである。
【0228】
上記のオプション４を除いて特定された解決策の中で、共通概念は、セル選択の目的で、ＩＡＢ－ＭＴはホワイトリストまたはブラックリストのいずれかの種類で提供されることであると見なされ得る。例えば、「インタードナーＩＡＢノードの移動」によって、トポロジ変更がＲｅｌ－１７で頻繁に発生する可能性があることを考えると、ホワイトリストとブラックリストには、トポロジ及びＩＡＢノードの位置に応じて長所と短所とがある。
【0229】
例えば、ＩＡＢドナーの近くのＩＡＢノード、即ち、ＤＡＧトポロジの最上位の観点からは、候補ノードの数が少なく、場合によってはＩＡＢドナーＤＵのみであるため、ホワイトリストを提供する方が合理的である。
【0230】
しかしながら、ＩＡＢドナーから遠く離れたＩＡＢノード、即ち、ＤＡＧトポロジの最下位からの観点である別の例では、ホワイトリストに膨大な数の候補ノードを含める必要がある可能性がある。代わりに、ブラックリストは、例えば、懸念されるＩＡＢノードのダウンストリームＩＡＢノードのみを含み、場合によっては少数の子ＩＡＢノードのみを含むため、この場合はオーバーヘッドが少ないという利点がある。
【0231】
ホワイトリストの懸念事項の１つは、Ｒｅｌ－１７の「インタードナーＩＡＢノードの移動」の性質上、異なる／隣接するＩＡＢトポロジに属する候補ＩＡＢノードを含める必要がある場合があり、リストのサイズが大きくなる可能性があることである。一方で、ダウンストリームＩＡＢノードは同じＩＡＢトポロジに属していることは言うまでもないため、ブラックリストはそれを気にする必要がない。
【0232】
所見５：ホワイトリスト及びブラックリストには、ＩＡＢノードのトポロジ及び位置に応じて長所と短所とがある。
【0233】
従って、セル選択の目的で子ＩＡＢノードに情報を提供する場合、ＩＡＢドナー（又は親ＩＡＢノード）がホワイトリスト又はブラックリストのどちらかを選択できることが望ましい。なお、当該情報は、セル再選択の目的で再利用することが有益であると考えられる。
【0234】
提案９：ＲＡＮ２は、子孫ノードへの再確立を回避するために、セル選択の目的でＩＡＢ－ＭＴにホワイトリスト又はブラックリスト（即ち、選択構造）が提供されることに合意すべきである。これらのリストをセル再選択手順にも使用できるかは更なる検討が必要である。
【0235】
提案９に合意できる場合、情報、即ち、ホワイトリスト又はブラックリストの提供方法をさらに検討すべきである。オプション１は、ＣＨＯ設定を想定しており、いくつかの拡張が必要になる可能性がある。オプション２は、追加のインジケーションを想定しており、例えば、タイプ２のＢＨ ＲＬＦインジケーションなどである。オプション３は、既存設定にはないトポロジ全体の情報を提供することを想定している。オプション５は、ＯＡＭによる設定を想定しているが、ラポーターが指摘したように、これは疑わしい。
【0236】
Ｒｅｌ－１７の想定（即ち、提案１）、即ち、トポロジ変更が発生したら、親ＩＡＢノード又はＩＡＢドナーが子ＩＡＢノードにリストを提供すべきであることを再度考慮すると、ホワイトリスト／ブラックリストの提供方法は動的な方法であるべきである。従って、オプション５、即ち、ＯＡＭは除外すべきである。どの方法、即ち、オプション１、２、又は３のうちのどの方法を拡張のベースラインにするかは、更なる検討が必要である。
【0237】
提案１０：ＲＡＮ２は、トポロジが変更されるたびに、ホワイトリスト／ブラックリストが親ＩＡＢノード又はＩＡＢドナーによって動的に提供されることに合意すべきである。詳細は更なる検討が必要である。
【0238】
（ロスレス配信の拡張）
Ｒｅｌ－１５の研究段階では、マルチホップＲＬＣ ＡＲＱの課題が、ＴＲのセクション８．２．３で議論され、キャプチャされた。Ｒｅｌ－１６では、プロトコルスタックは分離されていないＲＬＣ層を有するＩＡＢに対して定義された。つまり、Ｒｅｌ－１６では、ｅｎｄ－ｔｏ－ｅｎｄ ＡＲＱは除外され、ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱが採用された。
Ｒｅｌ－１５の研究段階では、マルチホップＲＬＣ ＡＲＱの課題が、ＴＲのセクション８．２．３で議論され、キャプチャされた。Ｒｅｌ－１６では、プロトコルスタックは分離されていないＲＬＣ層を有するＩＡＢに対して定義された。つまり、Ｒｅｌ－１６では、ｅｎｄ－ｔｏ－ｅｎｄ ＡＲＱは除外され、ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱが採用された。
【0239】
ｈｏｐ－ｂｙ－ｈｏｐ ＡＲＱに関しては、ｅｎｄ－ｔｏ－ｅｎｄの信頼性、即ち、ＵＬパケットのロスレス配信における課題が特定された。図１５に示すように、３つの解決策が特定され、評価された。
【0240】
Ｒｅｌ－１６では、第１の解決策である「ＰＤＣＰプロトコル／手順の変更」はＲｅｌ－１５ UEに影響を与えるため、採用されなかった。
【0241】
第２の解決策である「中間ＩＡＢノードでバッファリングされたＰＤＣＰ ＰＤＵの再ルーティング」は、ＢＡＰレイヤでの実装選択としてサポートされた。さらに、ＢＡＰレイヤは、「例えば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングすることは、実装依存」で実行してもよい。これらのＢＡＰ実装は、Ｒｅｌ－１６展開シナリオの「ほとんど」の場合、即ち、固定ＩＡＢノードを使用した場合、パケット損失を回避するために考慮されたが、例えば、図１５のように完全ではなかった。
【0242】
第３の解決策である「ＵＬステータス配信の導入」は、図１５に引用されている評価結果を考慮して、ＵＬデータのロスレス配信を保証するための約束された解決策であった。アイデアは、ＵＥへのＲＬＣ ＡＲＱを遅延させ、ＵＥでのＰＤＣＰデータ回復が必要なときに開始されるようにすることであった。しかしながら、固定ＩＡＢノードが想定されていたため、トポロジ変更によりＵＬパケットがドロップされることはまれであると見なされていたため、Ｒｅｌ－１６では規定されなかった。
【0243】
Ｒｅｌ－１７の想定を考えると、即ち、提案１の観点から、Ｒｅｌ－１７で頻繁に発生するトポロジ変更中にULパケットを損失することがもはやまれではないため、第３の解決策をさらに検討すべきである。従って、ＲＡＮ２は、ＴＲでキャプチャされた結果に加えて、Ｌ２マルチホップネットワーク内でロスレス配信を保証するための拡張メカニズムについて議論すべきである。
【0244】
提案１１：ＲＡＮ２は、ＴＲ３８．８７４で特定される解決策、即ち、何らかの形式の「ＵＬステータス配信」に基づいてトポロジ変更が頻繁に発生する可能性がある条件下で、ロスレス配信を保証するメカニズムを導入することに合意すべきである。
【0245】
第３の解決策、即ち、「ＵＬステータス配信の導入」の詳細については、図１６に示すように、ＥメールディスカッションでＣ－１及びＣ－２の２つのオプションについて議論した。
【0246】
上記のＣ－１に関して、マルチホップＬ２ネットワークを介したｅｎｄ－ｔｏ－ｅｎｄのシグナリング転送のために、ＩＡＢドナーからの「確認」をＢＡＰ又はＲＲＣで規定する必要があると想定される。従って、このオプションを規定するためには、比較的高い標準的な取り組みが必要になるであろう。
【0247】
上記のＣ－２に関して、ＩＡＢトポロジで十分に機能する場合、ＯＡＭがこのオプションを使用して全てのＩＡＢノードを設定すると想定される必要があっても、ＲＬＣ ＡＣＫをＵＥ（又はダウンストリームＩＡＢノード）に送信する場合、最終的にＩＡＢ－ＤＵ実装に依存するため、Ｒｅｌ－１６ ＩＡＢノードに対しても実際に実装可能である。さらに、ｈｏｐ－ｂｙ－ｈｏｐフィードバックを想定し、追加のＣｏｎｔｒｏｌ ＰＤＵを想定しないため、Ｃ－１よりも簡単である。従って、Ｃ－２は、ＵＬパケットのロスレス配信のためのＲｅｌ－１７の拡張ベースラインであるべきである。
【0248】
所見６：「ＵＬステータス配信の導入」の解決策であるＣ－２は、Ｒｅｌ－１７の拡張ベースラインとなる可能性があり、これは、Ｒｅｌ－１６に対しても実装可能である。
【0249】
但し、Ｒｅｌ－１７は、ＵＬパケット損失を引き起こす動的なトポロジ変更を想定すべきであるため、Ｒｅｌ－１７の拡張はＣ－２を標準のサポート機能としてサポートするであろう。少なくともステージ２の仕様では、Ｃ－２に基づく全体的なメカニズムを説明すべきである。それ以外の場合、３ＧＰＰ標準では、ＩＡＢノードのハンドオーバ中にロスレス配信が保証されない。さらに、ステージ３ではＲＬＣ及び／又はＢＡＰなどの小さな変更が予想されますが、ＩＡＢノードの内部動作と見なされるため、詳細を規定しない可能性もある。
【0250】
提案１２：ＲＡＮ２は、ステージ２でＵＬパケットをロスレス配信するためのＲＬＣ ＡＲＱメカニズムを規定することに合意すべきである。これは、親ＩＡＢノードからＡＣＫを受信する前に、子ノード／ＵＥへのＡＣＫの送信を遅らせる（即ち、Ｃ－２）。ステージ３で規定するかどうか／どのように規定するかは更なる検討が必要である。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】