(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-11
(45)【発行日】2024-11-19
(54)【発明の名称】通信制御方法
(51)【国際特許分類】
H04W 16/26 20090101AFI20241112BHJP
H04W 72/27 20230101ALI20241112BHJP
H04W 72/52 20230101ALI20241112BHJP
H04W 92/20 20090101ALI20241112BHJP
【ＦＩ】
H04W16/26
H04W72/27
H04W72/52
H04W92/20 110
【請求項の数】
22
(21)【出願番号】P 2023518695
(86)(22)【出願日】2022-05-02
(86)【国際出願番号】 JP2022019528
(87)【国際公開番号】W WO2022234846
(87)【国際公開日】2022-11-10
【審査請求日】2023-11-02
(31)【優先権主張番号】63/185,648
(32)【優先日】2021-05-07
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】チャン ヘンリー
【審査官】久松 和之
(56)【参考文献】
【文献】国際公開第２０２１／０６５７６３（ＷＯ，Ａ１）
【文献】国際公開第２０２０／１９６２０１（ＷＯ，Ａ１）
【文献】Samsung，IAB MAC - miscellaneous corrections and clarifications，3GPP TSG RAN WG2 #111-e R2-2008502，2020年09月01日
【文献】Kyocera，Possible solutions for topology-wide fairness, multi-hop latency and congestion mitigation in eIAB，3GPP TSG RAN WG2 #113bis-e R2-2103370，2021年04月02日
【文献】LG Electronics Inc.，Further consideration on identified issues for fairness, latency and congestion，3GPP TSG RAN WG2 #113bis-e R2-2103418，2021年04月02日
【文献】ZTE, Sanechips，Discussion on IAB BH RLF handling，3GPP TSG RAN WG2 #108 R2-1915119，2019年11月08日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４ － ７／２６
Ｈ０４Ｗ ４／００ － ９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４、６
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
セルラ通信システムで用いる通信制御方法であって、第１の中継ノードの上位ノードが、前記第１の中継ノードへ、論理チャネルグループに関する設定値を設定することと、
前記第１の中継ノードが、前記設定値に対応するＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）コントロールエレメント（ＣＥ）フォーマットを決定することと、
前記第１の中継ノードが、前記第１の中継ノードの親ノードである第２の中継ノードへ、前記ＭＡＣコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信することと
を有する通信制御方法。
【請求項2】
前記設定値は、前記論理チャネルグループの上限値の設定である請求項１記載の通信制御方法。
【請求項3】
前記ＭＡＣコントロールエレメントは、ロングバッファステータスレポート又はプリエンプティブバッファステータスレポートについては、拡張された論理チャネルグループｉ（ＬＣＧｉ）領域を含む請求項２記載の通信制御方法。
【請求項4】
前記ＭＡＣコントロールエレメントは、ショートバッファステータスレポート（Ｓｈｏｒｔ ＢＳＲ）について、拡張された論理チャネルグループＩＤ（ＬＣＧ ＩＤ）領域を含む、請求項３記載の通信制御方法。
【請求項5】
前記拡張された論理チャネルグループＩＤ領域は４ビット以上、前記拡張された論理チャネルグループｉ領域は１６ビット以上である請求項３又は４に記載の通信制御方法。
【請求項6】
前記ＭＡＣコントロールエレメントは、更に、前記上限値が格納されるＬＣＧレンジ（ＬＣＧ ｒａｎｇｅ）領域を含む請求項３又は４に記載の通信制御方法。
【請求項7】
前記上限値を設定することは、前記上位ノードが、前記第１の中継ノードへ、レガシーバッファステータスレポートとプリエンプティブバッファステータスレポートとで異なる上限値を設定することを含む請求項２記載の通信制御方法。
【請求項8】
セルラ通信システムで用いる通信制御方法であって、配下に第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを有するドナーノードが、前記第１の中継ノードへ、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を設定することと、
前記第１の中継ノードが、前記第２の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信することと、
前記第２の中継ノードが、前記第１の中継ノードへ、前記対応情報と前記バッファステータスレポートとに基づいて、アップリンクグラント（ＵＬ ｇｒａｎｔ）を送信することと、を有する
通信制御方法。
【請求項9】
更に、前記ドナーノードが、前記第２の中継ノードへ、前記対応情報を送信することを有する請求項８記載の通信制御方法。
【請求項10】
前記バッファステータスレポートを送信することは、前記第１の中継ノードが、前記対応情報に基づいて、前記論理チャネルを介して受信したパケットのホップ数に対応する前記論理チャネルグループを特定して、当該論理チャネルグループのバッファサイズを含む前記バッファステータスレポートを前記第２の中継ノードへ送信することを含む請求項８記載の通信制御方法。
【請求項11】
セルラ通信システムで用いる通信制御方法であって、第１の中継ノードの上位ノードが、前記第１の中継ノードへ、統合バッファステータスレポートの設定を行うことと、
前記第１の中継ノードが、前記設定に従って、前記統合バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、前記第１の中継ノードの親ノードである第２の中継ノードへ送信することと
を有する通信制御方法。
【請求項12】
セルラ通信システムで用いる通信制御方法であって、第１の中継ノード及び当該第１の中継ノードの親ノードである第２の中継ノードを配下に有するドナーノードが、前記第１の中継ノードへ、ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）の設定を行うことと、
前記第１の中継ノードが、前記第２の中継ノードから、当該第２の中継ノードと当該第２の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信することと、
前記第１の中継ノードが、前記障害回復通知の受信に応じて、前記ローカルリルーティング又は前記条件付きハンドオーバを実行することと
を有する通信制御方法。
【請求項13】
更に、前記ドナーノードが、前記障害回復通知の受信に応じて、前記ローカルリルーティングを実行するのか、又は前記条件付きハンドオーバを実行するのか、を前記第１の中継ノードへ設定することを有する請求項１２記載の通信制御方法。
【請求項14】
前記ローカルリルーティング又は前記条件付きハンドオーバを実行することは、前記第１の中継ノードが、予め設定されたルールに従って、前記ローカルリルーティング又は前記条件付きハンドオーバをトリガすることを含む請求項１２記載の通信制御方法。
【請求項15】
第１の中継ノードであって、
第１の中継ノードの上位ノードから、論理チャネルグループに関する設定値を受信する受信部と、
前記設定値に対応するＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）コントロールエレメント（ＣＥ）フォーマットを決定する制御部と、
前記第１の中継ノードの親ノードである第２の中継ノードへ、前記ＭＡＣコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信する送信部と、を有する
第１の中継ノード。
【請求項16】
第１の中継ノードであって、
配下に前記第１の中継ノード及び前記第１の中継ノードの親ノードである第２の中継ノードを有するドナーノードから、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を受信する受信部と、
前記第２の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信する送信部と、
前記第２の中継ノードから、前記対応情報と前記バッファステータスレポートとに基づくアップリンクグラント（ＵＬ ｇｒａｎｔ）を受信する受信部と、を有する
第１の中継ノード。
【請求項17】
第１の中継ノードであって、
第１の中継ノードの上位ノードから、統合バッファステータスレポートを設定する情報を受信する受信部と、
前記設定情報に従って、前記統合バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、前記第１の中継ノードの親ノードである第２の中継ノードへ送信する送信部と、を有する
第１の中継ノード。
【請求項18】
第１の中継ノードであって、
第１の中継ノード及び前記第１の中継ノードの親ノードである第２の中継ノードを配下に有するドナーノードから、ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）を設定する情報を受信し、
前記第２の中継ノードから、前記第２の中継ノードと前記第２の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信する受信部と、
前記障害回復通知の受信に応じて、前記ローカルリルーティング又は前記条件付きハンドオーバを実行する制御部と、を有する
第１の中継ノード。
【請求項19】
第１の中継ノードを制御するプロセッサであって、
第１の中継ノードの上位ノードから、論理チャネルグループに関する設定値を受信する処理と、
前記設定値に対応するＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）コントロールエレメント（ＣＥ）フォーマットを決定する処理と、
前記第１の中継ノードの親ノードである第２の中継ノードへ、前記ＭＡＣコントロールエレメントフォーマットを用いて、バッファステータスレポートを送信する処理と、を実行する
プロセッサ。
【請求項20】
第１の中継ノードを制御するプロセッサであって、
配下に前記第１の中継ノード及び前記第１の中継ノードの親ノードである第２の中継ノードを有するドナーノードから、論理チャネル（ＬＣＨ）のホップ数と論理チャネルグループ（ＬＣＧ）との対応関係を表す対応情報を受信する処理と、
前記第２の中継ノードへ、前記対応情報に基づいて、バッファステータスレポート（ＢＳＲ）を送信する処理と、
前記第２の中継ノードから、前記対応情報と前記バッファステータスレポートとに基づくアップリンクグラント（ＵＬ ｇｒａｎｔ）を受信する処理と、を実行する
プロセッサ。
【請求項21】
第１の中継ノードを制御するプロセッサであって、
第１の中継ノードの上位ノードから、統合バッファステータスレポートを設定する情報を受信する処理と、
前記設定情報に従って、前記統合バッファステータスレポートの種別毎に分類された論理チャネルグループに対応するバッファサイズが格納された前記統合バッファステータスレポートを、前記第１の中継ノードの親ノードである第２の中継ノードへ送信する処理と、を実行する
プロセッサ。
【請求項22】
第１の中継ノードを制御するプロセッサであって、
第１の中継ノード及び前記第１の中継ノードの親ノードである第２の中継ノードを配下に有するドナーノードから、ローカルリルーティング及び条件付きハンドオーバ（ＣＨＯ）を設定する情報を受信する処理と、
前記第２の中継ノードから、前記第２の中継ノードと前記第２の中継ノードの親ノードとの間のバックホールリンクで発生した障害に対して当該障害からの回復を試行中であることを示す障害回復通知を受信する処理と、
前記障害回復通知の受信に応じて、前記ローカルリルーティング又は前記条件付きハンドオーバを実行する処理と、を実行する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【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】
ＩＬ－５の可能な解決策は次の通りである。
・Ｌ３：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｌ３－１：ＩＡＢノードのバッファ／リンクステータスはＣＵと共有される。
・Ｌ３－２：ＢＨ ＲＬＣチャネルごとの個々のホップの遅延測定値はＣＵと共有される。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－２：ローカルリルーティングはＲＬＦ以外の目的で許可される（たとえば、発信リンクの遅延に基づく）。
・Ｆ４：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｆ４－１：ＢＨ ＲＬＣチャネルごとの負荷情報に関連する。
・Ｆ４－２：個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・Ｌ３：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｌ３－１：ＩＡＢノードのバッファ／リンクステータスはＣＵと共有される。
・Ｌ３－２：ＢＨ ＲＬＣチャネルごとの個々のホップの遅延測定値はＣＵと共有される。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－２：ローカルリルーティングはＲＬＦ以外の目的で許可される（たとえば、発信リンクの遅延に基づく）。
・Ｆ４：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｆ４－１：ＢＨ ＲＬＣチャネルごとの負荷情報に関連する。
・Ｆ４－２：個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
【0235】
ＩＬ－６は次のように指定された：
・ＩＬ－６：ＣＵは、ＢＨ ＲＬＣチャネルごとの実際の（リアルタイム）遅延に基づいてルーティングを設定できない。
・ＩＬ－６：ＣＵは、ＢＨ ＲＬＣチャネルごとの実際の（リアルタイム）遅延に基づいてルーティングを設定できない。
【0236】
ＩＬ－６の可能な解決策は次の通りである。
・Ｌ３：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｌ３－２：ＢＨ ＲＬＣチャネルごとの個々のホップの遅延測定値はＣＵと共有される。
・Ｆ４：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｆ４－２：個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－２：ローカルリルーティングはＲＬＦ以外の目的で許可される（たとえば、発信リンクの遅延に基づく）。
・Ｌ３：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｌ３－２：ＢＨ ＲＬＣチャネルごとの個々のホップの遅延測定値はＣＵと共有される。
・Ｆ４：追加のシグナリングがＩＡＢノードからＣＵに導入される。
・Ｆ４－２：個々のリンクでのホップごとの遅延及びホップごとのパケット損失に関連する。
・Ｌ４：ＩＡＢノードに新しい動作又は機能が指定されている。
・Ｌ４－２：ローカルリルーティングはＲＬＦ以外の目的で許可される（たとえば、発信リンクの遅延に基づく）。
【0237】
ＩＬ－５及びＩＬ－６の可能な解決策は、ＩＡＢノードからＩＡＢドナーへの追加のシグナル伝達、つまりＬ３及びＬ４に関して共通性を持っている可能性があり、これは、一元化された最適化を可能にするため、ＭＤＴ及び／又はＳＯＮ手順の一種と見なすことができる。
【0238】
Ｌ３－１に関しては、現在の仕様では、ＩＡＢノードがある程度のバッファ／リンクステータスをＩＡＢドナーと共有できるようになっていると見なすことができる。例えば、Ｆ１－ＡＰのＲＥＳＯＵＲＣＥ ＳＴＡＴＵＳ ＵＰＤＡＴＥやＲＲＣの測定報告フレームワークを共有できるようになっていると見なすことができる。そのため、ＣＵに報告する必要のある追加情報は不明である。
【0239】
Ｌ３－２及びＦ４－２に関しては、これらのソリューションはＩＬ－５及びＩＬ－６の両方に一般的に使用でき、遅延測定の観点からは同じと見なすことができる。既存のＬ２測定では、「ＵＥごとのＤＲＢごとのＵＬ ＰＤＣＰパケット平均遅延」が指定されているが、ＰＤＣＰパケット平均遅延をＩＡＢノードに適用できないことは明らかである。そのため、ＢＡＰレイヤには新しいＬ２測定が必要になると予想される。
【0240】
提案５：ＲＡＮ２は、ＩＡＢノードがホップごとの遅延測定結果をＩＡＢドナーに報告することに同意する必要がある。つまり、Ｌ３－２を使用してＩＬ－５及びＩＬ－６を解決する。
【0241】
Ｌ４－２に関して、ＲＡＮ２は、「タイプ２ ＲＬＦインジケーションを使用してローカルリルーティングをトリガできる」及び「ローカルリルーティングは、ホップごとのフロー制御のインジケーションによってトリガできる」ことにすでに同意している。従って、このアジェンダ項目でこの問題について更に議論する必要はない。つまり、ローカルリルーティングの詳細については、トポロジ適応の強化に関する他のアジェンダ項目で議論できる。
【0242】
所見３：他の目的、つまりＬ４－２のためのローカルリルーティングについては、トポロジ適応の強化の下で議論する。
【0243】
―輻輳の緩和―
ＩＣ－１及びＩＣ－７
ＩＣ－１及びＩＣ－７は、次のように注釈を付けて指定された。
Ｒ２は、次の２つの問題に対処するために企業間に十分な関心があると結論付けた。
・ＩＣ－１：パケットのドロップに依存せずに、既存のＲｅｌ－１６ ＤＬ ＨｂＨフロー制御メカニズムを使用して、単一リンクでの長期的なダウンストリーム輻輳を軽減することはできない。
・ＩＣ－７：ＣＵ（ローカルの輻輳状態を認識していない）は、輻輳が発生しているルーティングパスを更新できない。
ＩＣ－１及びＣＩ－７はどちらもＲＡＮ３に関連している。ＲＡＮ３もこれに取り組んでいるようであるため、ＲＡＮ２がこれにどの程度取り組むかは現在のところ明確ではない。
ＩＣ－１及びＩＣ－７
ＩＣ－１及びＩＣ－７は、次のように注釈を付けて指定された。
Ｒ２は、次の２つの問題に対処するために企業間に十分な関心があると結論付けた。
・ＩＣ－１：パケットのドロップに依存せずに、既存のＲｅｌ－１６ ＤＬ ＨｂＨフロー制御メカニズムを使用して、単一リンクでの長期的なダウンストリーム輻輳を軽減することはできない。
・ＩＣ－７：ＣＵ（ローカルの輻輳状態を認識していない）は、輻輳が発生しているルーティングパスを更新できない。
ＩＣ－１及びＣＩ－７はどちらもＲＡＮ３に関連している。ＲＡＮ３もこれに取り組んでいるようであるため、ＲＡＮ２がこれにどの程度取り組むかは現在のところ明確ではない。
【0244】
ＲＡＮ３は輻輳の兆候について議論しており、次のことに同意した。
ＣＰベースの輻輳インジケーションには、次のレポートが含まれる場合がある：
・ＢＡＰルーティングＩＤごと及び／又は
・子ノードごとのリンク及び／又は
・ＢＨ ＲＬＣ ＣＨ ＩＤ
（ダウンセレクションは更なる検討が必要である）。
ＣＰベースの輻輳インジケーションは、Ｆ１ＡＰＧＮＢ－ＤＵステータスインジケーション手順を再利用する。
ＣＰベースの輻輳インジケーションは、ＤＬ輻輳に関連している。
ＩＡＢ輻輳緩和へのＵＰベースのアプローチについては、次の２つのオプションを検討する。
・機能強化はない。
・パケットマーキングベースのアプローチ。
ＣＰベースの輻輳インジケーションには、次のレポートが含まれる場合がある：
・ＢＡＰルーティングＩＤごと及び／又は
・子ノードごとのリンク及び／又は
・ＢＨ ＲＬＣ ＣＨ ＩＤ
（ダウンセレクションは更なる検討が必要である）。
ＣＰベースの輻輳インジケーションは、Ｆ１ＡＰＧＮＢ－ＤＵステータスインジケーション手順を再利用する。
ＣＰベースの輻輳インジケーションは、ＤＬ輻輳に関連している。
ＩＡＢ輻輳緩和へのＵＰベースのアプローチについては、次の２つのオプションを検討する。
・機能強化はない。
・パケットマーキングベースのアプローチ。
【0245】
ＩＡＢドナーがＩＡＢノードから輻輳インジケーションを受信すると、ＩＡＢドナーは上記のＲＡＮ２の合意で暗示されているように輻輳が発生するパスを回避できると想定できる。この問題に対処するには、いくつかの方法がある。つまり、ＩＡＢドナーは、ルーティング設定を更新するか、ローカルリルーティングを指示する。後者の場合、輻輳インジケーションの使用方法にＲＡＮ２が関与している可能性がある。いずれの場合も、ＲＡＮ２はＲＡＮ３の進行を待ってから決定する必要がある。
【0246】
所見４：ＲＡＮ２は、ＲＡＮ３が詳細を把握した後、輻輳の兆候が原因でＩＡＢドナーがどのように行動するかに関与している可能性がある。
【0247】
（付記２）
（導入）
ＮＲの統合アクセスとバックホールの拡張（ｅＩＡＢ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８ｅで承認された。いくつかの目的は次の通りである。
トポロジ適応の強化：
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間ＩＡＢノード移行の手順の仕様。
・ＩＡＢノードの移行及びＢＨＲＬＦの回復によるサービスの中断を減らすための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化：
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
（導入）
ＮＲの統合アクセスとバックホールの拡張（ｅＩＡＢ）に関する改訂されたワークアイテムは、ＲＡＮ＃８８ｅで承認された。いくつかの目的は次の通りである。
トポロジ適応の強化：
・シグナリング負荷を軽減するための機能強化を含む、堅牢性と負荷分散を強化するためのドナー間ＩＡＢノード移行の手順の仕様。
・ＩＡＢノードの移行及びＢＨＲＬＦの回復によるサービスの中断を減らすための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性の強化の仕様。
トポロジ、ルーティング、及びトランスポートの機能強化：
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
【0248】
付記２では、現在の合意に加えて、Ｒｅｌ－１７ｅＩＡＢのトポロジ適応強化のさまざまなトピックについて議論する。具体的には、ＢＨ ＲＬＦインジケーションの機能強化、条件付きハンドオーバの機能強化、及びローカルリルーティングの機能強化である。
【0249】
【0250】
最後に、タイプ４の「リカバリ障害」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして指定された。これにより、子ＩＡＢ－ＭＴは親ノードのＢＨリンク上のＲＬＦを認識し、ＲＬＦ回復手順を開始できる。
【0251】
所見１：タイプ４の「回復障害」のみがＲｅｌ－１６のＢＨ ＲＬＦインジケーションとして指定された。
【0252】
Ｒｅｌ－１７の機能強化について、ＲＡＮ２は、タイプ２の「回復の試行」及びタイプ３の「ＢＨリンクの回復」を導入することに同意したが、詳細なＩＡＢノードの動作は引き続き更なる検討が必要である。
【0253】
ＲＡＮ２＃１１３－ｅ：
タイプ２／３ＲＬＦインジケーションをサポートするＲＡＮ２（詳細は更なる検討が必要である）。タイプ２ＲＬＦインジケーションを使用して、ローカルリルーティングをトリガできる。タイプ２ＲＬＦインジケーションは、ＳＩＢでサポートされているＩＡＢの非アクティブ化をトリガするために使用できる。タイプ２ＲＬＦインジケーションは、ＳＲ及び／又はＢＳＲ送信の非アクティブ化、又は削減をトリガするために使用できる。
タイプ２／３ＲＬＦインジケーションをサポートするＲＡＮ２（詳細は更なる検討が必要である）。タイプ２ＲＬＦインジケーションを使用して、ローカルリルーティングをトリガできる。タイプ２ＲＬＦインジケーションは、ＳＩＢでサポートされているＩＡＢの非アクティブ化をトリガするために使用できる。タイプ２ＲＬＦインジケーションは、ＳＲ及び／又はＢＳＲ送信の非アクティブ化、又は削減をトリガするために使用できる。
【0254】
ＲＡＮ２＃１１３ｂｉｓ－ｅ：
他のＣＨＯ実行条件が必要な場合は更なる検討が必要である（例：タイプ２ ＲＬＦインジケーションをトリガとして使用できるかどうか）。
他のＣＨＯ実行条件が必要な場合は更なる検討が必要である（例：タイプ２ ＲＬＦインジケーションをトリガとして使用できるかどうか）。
【0255】
更なる検討がなされているものの１つは、ＲＡＮ２がすでに合意している新しいＢＨＲ ＬＦインジケーションの３つの可能なユースケースに関連する動作を指定するかどうか／どのように指定するかである。
【0256】
ローカルリルーティングのトリガに関しては、タイプ２ ＢＨ ＲＬＦインジケーションを受信するＩＡＢノードの観点からＢＨ ＲＬＦがＵＬで発生するため、トリガはアップストリームローカルリルーティング、つまりＵＬパスの切り替えを可能にする必要がある。言い換えると、タイプ２ ＢＨ ＲＬＦインジケーションを受信するＩＡＢノードはダウンストリームノードとの良好なＢＨリンクを維持できるため、ダウンストリームローカルリルーティングはタイプ２ＢＨ ＲＬＦインジケーションから独立している。従って、明確に指定する必要があるＩＡＢ－ＭＴの動作と見なすことができる。
【0257】
提案１：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ２ ＢＨ ＲＬＦインジケーションを受信したときに、アップストリームパスでローカルリルーティングをトリガすることを指定することに同意する必要がある。
【0258】
提案２：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ３ ＢＨ ＲＬＦインジケーションを受信すると、アップストリームパスでのローカルリルーティングを停止する、つまり、設定された「通常の」ルーティングに戻ることを指定することに同意する必要がある。
【0259】
ＳＩＢ１でのＩＡＢサポートＩＥの非アクティブ化に関しては、Ｒｅｌ－１６での実装まで広く考えられていたＩＡＢ－ＤＵの動作と見なすことができる。従って、ステージ２でのみ指定するだけで、おそらく十分である。特に、ＩＡＢ－ＤＵは、ドナーへの代替ルートがまだある場合、ＳＩＢ１からＩＡＢ－Ｓｕｐｐｏｒｔ ＩＥを削除しないと想定できる。これは、動作が指定されている場合に明確にする必要がある。
【0260】
提案３：ＲＡＮ２は、ステージ２でのみＩＡＢ－ＤＵがタイプ２ ＢＨ ＲＬＦインジケーションを受信し、ＩＡＢドナーへの代替ルートがない場合にＳＩＢ１からＩＡＢ－Ｓｕｐｐｏｒｔ ＩＥを削除するかどうかを検討する必要がある。
【0261】
上記のＲＡＮ２の合意によれば、提案３が同意できるかどうかに関係なく、ＩＡＢ－Ｓｕｐｐｏｒｔ ＩＥがＳＩＢ１にない場合、ＩＡＢ－ＭＴは親ノードへの接続確立を開始しない。１つの質問は、親ノードがＢＨ ＲＬＦの下にある場合でも、ＵＥがセル（つまり親ノード）へのアクセスを許可されているかどうかである。ＲＲＣセットアップリクエストはＣＵ、つまりドナーに到達できないため、最終的にはユーザに悪影響を与える。これを回避するために、セルには、ＵＥのアクセスを禁止し、ＳＳＢ送信を停止し、又はＳＩＢ１を介してタイプ２ＢＨ ＲＬＦインジケーションをブロードキャストするオプションがある。提案３と同様に、ＩＡＢノードにドナーへの代替ルートがある場合、ＩＡＢサポートＩＥをＳＩＢ１から削除する必要はない。
【0262】
提案４：ＲＡＮ２は、ＩＡＢ－ＤＵがタイプ２ ＢＨ ＲＬＦインジケーションを受信し、ＩＡＢドナーへの代替ルートがない場合に、ＩＡＢ－ＭＴアクセスに加えてＵＥアクセスを禁止するかどうかを検討する必要がある。
【0263】
ＳＲ及び／又はＢＳＲ送信の非アクティブ化、又は削減に関しては、ＩＡＢ－ＭＴの動作と見なされる可能性があるため、明確に指定する必要がある。非アクティブ化又は削減に関しては、仕様の観点から「非アクティブ化」の方が簡単な場合がある。ただし、ＳＲ及び／又はＢＳＲは、タイプ３の受信後にのみ送信できるため、スケジューリングの遅延が発生する可能性がある。一方、「削減」は、不要な干渉を引き起こす可能性はあるが、ＢＨリンクが回復した直後にスケジューリングを再開できる場合がある。従って、ＲＡＮ２は、ＳＲ及び／又はＢＳＲの「非アクティブ化」、「削減」、又はその両方をサポートするかどうかについて議論する必要がある。両方がサポートされている場合は、ＩＡＢドナーによって設定可能である必要がある。更に、「削減」がサポートされている場合、ＳＲ及び／又はＢＳＲの削減をどのように処理する必要があるかが不明確である。禁止タイマーの概念を再利用することも考えられるが、この時点では更なる検討が必要である。
【0264】
提案５：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ２ ＢＨ ＲＬＦインジケーションを受信したときに、ＳＲ及び／又はＢＳＲ送信を非アクティブ化、又は削減することを指定することに同意する必要がある。
【0265】
提案６：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ３ ＢＨ ＲＬＦインジケーションを受信したときに、ＳＲ及び／又はＢＳＲ送信の通常の手順を再開できることを指定することに同意する必要がある。
【0266】
提案７：ＲＡＮ２は、タイプ２ ＢＨ ＲＬＦインジケーションが親ノードから受信されたときに、ＳＲ及び／又はＢＳＲの「非アクティブ化」、「削減」、又はその両方（つまり、設定可能）をサポートするかどうかを検討する必要がある。
【0267】
更なる検討がなされているもののもう１つは、ＣＨＯがタイプ２ＢＨ ＲＬＦインジケーションの受信によってトリガされるかどうかである。タイプ２ＢＨ ＲＬＦインジケーションが送信された状態で、親ノードはＢＨ ＲＬＦを経験し、ＢＨリンクを回復しようとしている。これは、言うまでもなく、ＩＡＢノードがドナーと通信できないことを意味する。ＩＡＢノードがデュアルコネクティビティで設定されている場合、提案１のように、ＭＣＧとＳＣＧとの間でローカルリルーティングを実行することを選択できる。
【0268】
ただし、接続が１つしかないＩＡＢノードは何も実行できず、親ノードのＢＨ回復又はタイプ４ＢＨ ＲＬＦインジケーションの受信のいずれかを待機する必要がある。明らかに、それは長期間のサービス中断及びユーザへの悪影響を引き起こす。従って、ＩＡＢノードには、タイプ２ＢＨ ＲＬＦインジケーションを受信したときにＣＨＯをトリガするオプションが必要である。更に、さらなる最適化として、ＩＡＢノードが実際にＣＨＯを実行する前にタイプ３ ＢＨ ＲＬＦインジケーションを受信した場合に、ＩＡＢノードがＣＨＯ実行をキャンセルする必要があるかどうかを検討する価値がある。
【0269】
提案８：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ２ＢＨ ＲＬＦインジケーションを受信したときにＣＨＯをトリガすることを指定することに同意する必要がある。
【0270】
提案９：ＲＡＮ２は、ＩＡＢ－ＭＴが親ノードからタイプ３ ＢＨ ＲＬＦインジケーションを受け取ったときに、（可能であれば）ＣＨＯ実行をキャンセルするかどうかを検討する必要がある。
【0271】
提案１及び提案８の両方に合意できる場合、つまり、デュアルコネクティビティ、ローカルリルーティング、及びＣＨＯで同時に設定されたＩＡＢノードの場合、タイプ２ ＢＨインジケーションを受信したときに、ローカルリルーティング又はＣＨＯのどちらをトリガするかを選択できる。たとえば、タイプ２の受信によるローカルリルーティングは、サービスの中断を回避するのに役立ちますが、タイプ２の受信によるＣＨＯは、長期的／トポロジ全体のパフォーマンスに適している。ローカルリルーティング及びＣＨＯは、タイプ２受信以外の条件によってトリガされるため、これらは主に、イベントＡ３によるハンドオーバの堅牢性などのさまざまな目的で設定されていると想定される。
【0272】
この場合、いくつかのオプションがある。ＩＡＢノードの実装又はＩＡＢドナーの設定のいずれかである。ドナーがトポロジ全体の目標を管理するノードであることを考えると、トポロジのパフォーマンスを制御できる必要があるため、タイプ２の受信によるローカルリルーティング又はＣＨＯの選択は、ＩＡＢノードの実装に任せるのではなく、ドナーが設定できる必要がある。
【0273】
提案１０：提案１及び提案８の両方に合意できる場合、ＲＡＮ２は、タイプ２ ＢＨ ＲＬＦインジケーションを受信したため、ＩＡＢノードがローカルリルーティング又はＣＨＯをトリガするようにＩＡＢドナーが設定できることに更に同意する必要がある。
【0274】
仕様に新しいＢＨ ＲＬＦインジケーションを実装する方法について説明する必要がある。タイプ２及びタイプ３のＢＨ ＲＬＦインジケーションは、Ｒｅｌ－１６のタイプ４ ＢＨ ＲＬＦインジケーションの場合と同様に、ＢＡＰ制御ＰＤＵを介して送信されることは簡単であると考えられる。上記の提案３と同様に、ＵＥはＢＡＰ制御ＰＤＵを受信できないため、ＢＡＰ層がない。従って、これらのＢＨ ＲＬＦインジケーションがＳＩＢ１を介してブロードキャストされ、ＳＩＢ１がＤＵによってエンコードされる可能性がある。従って、ＲＡＮ２は、これらがＢＡＰ制御ＰＤＵ又はＳＩＢ１のどちらを介して送信されるかを検討する必要がある。
【0275】
提案１１：ＲＡＮ２は、タイプ２及びタイプ３のＢＨ ＲＬＦインジケーションがＢＡＰ制御ＰＤＵ又はＳＩＢ１のどちらを介して送信されるかについて議論する必要がある。
【0276】
（条件付きハンドオーバの機能強化）
条件付きハンドオーバ（ＣＨＯ）は、モビリティの堅牢性を向上させるためにＲｅｌ－１６に導入された。ＣＨＯは指定されたＲｅｌ－１６ＩＡＢに使用できる。ＲＡＮ２＃１１３－ｅ及びＲＡＮ２＃１１３－ｅは次の合意に達した。従って、Ｒｅｌ－１６ＣＨＯに加えてｅＩＡＢのＣＨＯ拡張機能を検討する価値がある。
条件付きハンドオーバ（ＣＨＯ）は、モビリティの堅牢性を向上させるためにＲｅｌ－１６に導入された。ＣＨＯは指定されたＲｅｌ－１６ＩＡＢに使用できる。ＲＡＮ２＃１１３－ｅ及びＲＡＮ２＃１１３－ｅは次の合意に達した。従って、Ｒｅｌ－１６ＣＨＯに加えてｅＩＡＢのＣＨＯ拡張機能を検討する価値がある。
【0277】
ＲＡＮ２＃１１３－ｅ：
ＲＡＮ２では、ＣＨＯについて議論し、ＲＡＮ３がドナー間のＩＡＢノードの移行についての議論を進めるまで、ドナー内のＣＨＯの議論から始める。
ＲＡＮ２は、Ｒｅｌ－１６のＣＨＯがＩＡＢ－ＭＴに使用される／使用できるという意図を確認する（変更が必要かどうかは更なる検討が必要である）。
ＲＡＮ２は、Ｒｅｌ－１６仕様が、デフォルトルート、ＩＰアドレス、及びドナー内ＣＨＯのターゲットパスの設定のベースラインであると想定している。
ＲＡＮ２では、ＣＨＯについて議論し、ＲＡＮ３がドナー間のＩＡＢノードの移行についての議論を進めるまで、ドナー内のＣＨＯの議論から始める。
ＲＡＮ２は、Ｒｅｌ－１６のＣＨＯがＩＡＢ－ＭＴに使用される／使用できるという意図を確認する（変更が必要かどうかは更なる検討が必要である）。
ＲＡＮ２は、Ｒｅｌ－１６仕様が、デフォルトルート、ＩＰアドレス、及びドナー内ＣＨＯのターゲットパスの設定のベースラインであると想定している。
【0278】
ＲＡＮ２＃１１３ｂｉｓ－ｅ：
ＩＡＢ－ＭＴのＣＨＯの使用例は、移行とＲＬＦリカバリである必要がある。
ＲＡＮ２には、ＣＵ内／ＤＵ内ＣＨＯ、及びＣＵ内／ＤＵ間ＣＨＯに共通のソリューションが必要である。
ＣＨＯイベントＡ３及びＣＨＯイベントＡ５はＩＡＢ－ＭＴに適用可能である。
他のＣＨＯ実行条件が必要な場合は更なる検討が必要である（例：タイプ２ ＲＬＦインジケーションをトリガとして使用できるかどうか）。
ＩＡＢ－ＭＴのＣＨＯの使用例は、移行とＲＬＦリカバリである必要がある。
ＲＡＮ２には、ＣＵ内／ＤＵ内ＣＨＯ、及びＣＵ内／ＤＵ間ＣＨＯに共通のソリューションが必要である。
ＣＨＯイベントＡ３及びＣＨＯイベントＡ５はＩＡＢ－ＭＴに適用可能である。
他のＣＨＯ実行条件が必要な場合は更なる検討が必要である（例：タイプ２ ＲＬＦインジケーションをトリガとして使用できるかどうか）。
【0279】
前セクションの提案８が合意できる場合、ＣＨＯイベントＡ３／Ａ５に依存しないが、タイプ２ＢＨ ＲＬＦインジケーションによる一種の強制的なトリガであるため、すべてのＣＨＯ候補（つまり、候補セル）が同時にＣＨＯをトリガできる可能性がある。
【0280】
現在の仕様によると、「条件付き再設定の実行で複数のＮＲセルがトリガされる場合、どれを選択するかはＵＥの実装次第である。ＵＥは、ビームとビーム品質を考慮して、実行のためにトリガされたセルの１つを選択する。」これは主にＵＥを対象としている。
【0281】
所見２：Ｒｅｌ－１６のＣＨＯでは、複数の候補セルがＣＨＯ実行をトリガする場合、どのセルを選択するかはＵＥの実装次第である。
【0282】
ＩＡＢ－ＭＴに関しては、ＩＡＢ－ＭＴがローカルの無線品質に応じて実装することにより、トリガされたセルの１つを選択することが常に最良のアプローチであるとは限らない。これは、トポロジ全体の目標は、ＲＡＮ２＃１１２－ｅで議論されているように、ＩＡＢドナーによって効果的に処理される可能性があるためである。従って、ＲＡＮ２は、追加のトリガ条件を使用したＩＡＢドナー制御のＣＨＯ実行が、提案８のようにどのように機能するかを検討する必要がある。例えば、ＩＡＢドナーは、ＣＨＯ設定でＣＨＯ候補に関連付けられた優先度情報を設定できる。ＩＡＢ－ＭＴは、特定の無線品質（Ｓ基準など）を満たすすべてのトリガされたＣＨＯ候補から最も優先度の高いセルを選択する必要がある。
【0283】
提案１２：ＲＡＮ２は、タイプ２ ＢＨ ＲＬＦインジケーションの受信により、すべての候補セルがＣＨＯをトリガする場合に、追加の拡張機能としてＩＡＢドナー制御のＣＨＯ実行が必要かどうかを検討する必要がある。
【0284】
（ローカルリルーティングの機能強化）
Ｒｅｌ－１６では、ローカルリルーティングはＢＨ ＲＬＦが発生した場合にのみ許可される。
たとえば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングは実装次第である。ＢＨ ＲＬＦの場合、ＢＡＰエンティティの送信部分は、ＢＨ ＲＬＦの前に下位層によって確認されていないＢＡＰデータＰＤＵを代替パスにリルーティングすることができる。
Ｒｅｌ－１６では、ローカルリルーティングはＢＨ ＲＬＦが発生した場合にのみ許可される。
たとえば、ＲＬＣ－ＡＭエンティティが確認応答を受信するまで、ＢＡＰエンティティの送信部分でのデータバッファリングは実装次第である。ＢＨ ＲＬＦの場合、ＢＡＰエンティティの送信部分は、ＢＨ ＲＬＦの前に下位層によって確認されていないＢＡＰデータＰＤＵを代替パスにリルーティングすることができる。
【0285】
ＲＡＮ２＃１１３－ｅは、ローカルリルーティングの機能強化に関連する次の合意を達成した。
タイプ２ＲＬＦインジケーションを使用して、ローカルリルーティングをトリガできる。
ローカルリルーティングは、ホップごとのフロー制御を示すことでトリガできる。トリガ情報、トリガ条件、ＣＵ設定の役割などの詳細は、更なる検討が必要である。
ＲＡＮ２は、ドナー間ＤＵローカルリルーティングが範囲内にあると見なす。
タイプ２ＲＬＦインジケーションを使用して、ローカルリルーティングをトリガできる。
ローカルリルーティングは、ホップごとのフロー制御を示すことでトリガできる。トリガ情報、トリガ条件、ＣＵ設定の役割などの詳細は、更なる検討が必要である。
ＲＡＮ２は、ドナー間ＤＵローカルリルーティングが範囲内にあると見なす。
【0286】
ただし、ローカルリルーティングの詳細は、少なくとも設定の観点からはまだ不明である。ＲＡＮ２＃１１２－ｅで合意されているように、Ｒｅｌ－１７では、他の場合（すなわち、ＢＨ ＲＬＦに限定されない場合）について、中央ルート決定に対する利益を含むローカルリルーティング、およびトポロジ全体の目標にどのように対処できるかについて、ＲＡＮ２で議論する。従って、Ｒｅｌ－１６の問題は、トポロジ全体の客観的な観点から検討する必要がある。言うまでもなく、ＩＡＢドナーは、ＩＡＢトポロジの完全な知識と完全な制御を備えているため、トポロジ全体の目的を処理するエンティティである。
【0287】
所見３：ＩＡＢドナーは、トポロジ全体の目的を確実にするために最も適切なエンティティである。
【0288】
Ｒｅｌ－１６ローカルリルーティングでは、宛先が同じである限り、代替パスとしてパスが選択されることはＩＡＢノードの実装次第である。これは、ローカルリルーティングがローカルの決定に基づいており、ＩＡＢドナーの観点からは制御できないことを意味する。これは、特に多くのローカルの決定が発生してＩＡＢトポロジに蓄積される場合、トポロジ全体の目的と一致しない可能性がある。
【0289】
所見４：Ｒｅｌ－１６ローカルリルーティングでは、代替パスとしてどのパスが選択されるかはＩＡＢ－ＭＴの実装次第である。
【0290】
従って、ローカルリルーティングがＢＨ ＲＬＦの場合を超えて拡張される場合、ＩＡＢドナーの可制御性はより重要になるはずである。ＩＡＢドナーが代替パスを設定することは簡単である。これにより、ＩＡＢノードはローカルリルーティングを実行するときに代替パスを選択する必要がある。代替パスのモデリングは更なる検討が必要である。例えば、代替パスが同じルーティングＩＤを持っているかどうかなどである。
【0291】
提案１３：ＲＡＮ２は、ＩＡＢドナーがＲｅｌ－１６のルーティング設定に加えて代替パスを使用してＩＡＢノードを設定できるかどうかを検討する必要がある。
【0292】
ＩＡＢドナーの可制御性のもう１つの側面として、ＩＡＢドナーはローカルリルーティングを認識し、ローカルリルーティング及びトポロジ全体の目的を共存させるためにＩＡＢノードでローカルリルーティングを開始／停止できることを考慮する必要がある。例えば、ＩＡＢドナーは、どのＩＡＢノードが現在ローカルリルーティングを実行しているかの知識に基づいて、トポロジ全体の目標がまだ達成されているかどうかを検討できる。ＩＡＢドナーがトポロジ全体の目的を達成できないことに気付いた場合、ＩＡＢドナーはＩＡＢノードにローカルリルーティングを開始／停止するように指示するか、ＩＡＢドナーがＩＡＢトポロジ全体のルーティング設定を変更する可能性がある。
【0293】
ローカルリルーティングにより、トポロジ全体の目標をどのように処理するかは、ＩＡＢドナーの実装次第であるが、ＩＡＢドナーは、ＩＡＢノードのローカル決定の情報と制御性を必要とする場合がある。
【0294】
提案１４：ＲＡＮ２は、ローカルリルーティングの開始／停止時にＩＡＢノードがＩＡＢドナーに通知する必要があるかどうかを検討する必要がある。
【0295】
提案１５：ＲＡＮ２は、ＩＡＢドナーがＩＡＢノードにローカルリルーティングを開始／停止するように指示できるかどうかについて議論する必要がある。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】