知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-01-07
(45)【発行日】2025-01-16
(54)【発明の名称】通信制御方法
(51)【国際特許分類】
H04W 28/10 20090101AFI20250108BHJP
H04W 16/26 20090101ALI20250108BHJP
H04W 48/16 20090101ALI20250108BHJP
H04W 92/20 20090101ALI20250108BHJP
【ＦＩ】
H04W28/10
H04W16/26
H04W48/16 131
H04W92/20 110
【請求項の数】
3
(21)【出願番号】P 2022575590
(86)(22)【出願日】2022-01-12
(86)【国際出願番号】 JP2022000640
(87)【国際公開番号】W WO2022153989
(87)【国際公開日】2022-07-21
【審査請求日】2023-07-11
(31)【優先権主張番号】63/136,472
(32)【優先日】2021-01-12
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】チャン ヘンリー
【審査官】青木 健
(56)【参考文献】
【文献】LG Electronics Inc.，Discussion on topology-wide fairness, multi-hop latency and congestion mitigation，3GPP TSG RAN WG2 #112-e R2-2009667，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_112-e/Docs/R2-2009667.zip>，2020年11月02日
【文献】Samsung (rapporteur)，Discussion summary - [AT112-e][030][eIAB]，3GPP TSG RAN WG2 #112-e R2-2011060，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_112-e/Docs/R2-2011060.zip>，2020年11月02日
【文献】ZTE, Sanechips，Discussion on topology-wide fairness, multi-hop latency and congestion mitigation，3GPP TSG RAN WG2 #112-e R2-2009388，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_112-e/Docs/R2-2009388.zip>，2020年11月02日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｗ ４／００ － ９９／００
Ｈ０４Ｂ ７／２４ － ７／２６
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１，４
(57)【特許請求の範囲】
【請求項1】
セルラ通信システムで用いる通信制御方法であって、配下に中継ノードを有するドナー基地局が、前中継ノードに対して、前記中継ノードの親ノード又は子ノードのスケジューラにおいてデータパケットの転送における優先制御が行われるためのアシスト情報を当該親ノード又は子ノードへ通知させるか否かを設定することと、
前記中継ノードが、前記設定に従って、前記親ノード又は子ノードへ、前記アシスト情報を通知することと、
を有する通信制御方法。
【請求項2】
前記アシスト情報は、前記中継ノードを含む複数の中継ノードを経由するごとに変更される情報及び前記中継ノードが混雑していることを示す混雑情報の少なくともいずれか一方を含む、請求項１記載の通信制御方法。
【請求項3】
ドナー基地局の配下にいる中継ノードあって、
前記ドナー基地局から、前記中継ノードの親ノード又は子ノードのスケジューラにおいてデータパケットの転送における優先制御が行われるためのアシスト情報を当該親ノード又は子ノードへ通知させるか否かを設定する設定情報を受信する受信部と、
前記親ノード又は子ノードへ、前記設定情報に従って、前記アシスト情報を通知する送信部と、を備える
中継ノード。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、セルラ通信システムに用いる通信制御方法に関する。
【背景技術】
【0002】
セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．３．０（２０２０－０９）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。
【発明の概要】
【0003】
第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、配下に中継ノードを有するドナー基地局が、前記中継ノードに対して、前記中継ノードのスケジューラにデータパケットの転送における優先制御を行わせるか否かを設定することを有する。また、前記通信制御方法は、前記中継ノードが、前記設定に従って、前記スケジューラを動作させることを有する。
【0004】
第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、当該中継ノードを配下に有するドナー基地局へ、ルート毎のスループットを表す第１情報、データパケット破棄数を表す第２情報、又は障害発生通知を受信したことを表す第３情報を送信することを含む。また、前記通信制御方法は、前記ドナー基地局が、前記第１情報、前記第２情報、又は前記第３情報に基づいて、所定の動作を行うことを含む。
【0005】
第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、親ノードと子ノードとの間に介在する中継ノードが、前記親ノードへ、プリエンプティブバッファステータスレポートを送信することを有する。また、前記通信制御方法は、前記親ノードが、前記プリエンプティブバッファステータスレポートを受信することを有する。さらに、前記通信制御方法は、前記送信することにおいて、前記中継ノードが、前記子ノードに滞留する第１データの第１データ量と前記中継ノードに滞留する第２データの第２データ量とを前記プリエンプティブバッファステータスレポートの異なる領域に格納することを含む。
【図面の簡単な説明】
【0006】
【発明を実施するための形態】
【0007】
図面を参照しながら、実施形態に係るセルラ通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【0008】
（セルラ通信システムの構成）
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。
【0009】
図１は、一実施形態に係るセルラ通信システム１の構成例を表す図である。
【0010】
図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。
【0011】
以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
【0012】
なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。
【0013】
５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
【0014】
各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。また、セルは、ｇＮＢ２００など、基地局と区別しないで用いられる場合がある。１つのセルは１つのキャリア周波数に属する。
【0015】
各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。
【0016】
各ｇＮＢ２００は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。
【0017】
セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ（又はＩＡＢドナー。以下、「ＩＡＢドナー」と称する場合がある。）２００－１は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。
【0018】
図１において、ＩＡＢノード３００－１がＩＡＢドナー２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。
【0019】
ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末、タブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、及び／又は車両若しくは車両に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１は、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してＩＡＢドナー２００－１と間接的に通信する。
【0020】
図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を表す図である。
【0021】
図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｉｏｎ）とを有する。
【0022】
ＩＡＢ－ＭＴのＮＲ Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はＩＡＢドナー２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。
【0023】
ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ＩＡＢドナー２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。
【0024】
また、１つ又は複数のホップを介して、ＩＡＢドナー２００に接続されている全てのＩＡＢノード３００は、ＩＡＢドナー２００をルートとする有向非巡回グラフ（ＤＡＧ：Ｄｉｒｅｃｔｅｄ Ａｃｙｃｌｉｃ Ｇｒａｐｈ）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ＩＡＢドナー２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。
【0025】
（基地局の構成）
次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を表す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
次に、実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図３は、ｇＮＢ２００の構成例を表す図である。図３に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
【0026】
無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信を行う。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
【0027】
ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）を行う。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
【0028】
制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）とを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部２３０は、以下に示す各実施例において、ｇＮＢ２００おける各処理を行うようにしてもよい。
【0029】
（中継ノードの構成）
次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を表す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を表す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
【0030】
無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
【0031】
無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
【0032】
制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部３２０は、以下に示す各実施例において、ＩＡＢノード３００における各処理を行うようにしてもよい。
【0033】
（ユーザ装置の構成）
次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を表す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を表す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
【0034】
無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。
【0035】
制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部１３０は、以下に示す各実施例において、ＵＥ１００における各処理を行うようにしてもよい。
【0036】
（プロトコルスタックの構成）
次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。
次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を表す図である。
【0037】
図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤと、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤとを有する。
【0038】
ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。
【0039】
ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ：Ｈｙｂｒｉｄ Ａｕｔｏｍａｔｉｃ Ｒｒｅｐｅａｔ ｒｅＱｕｅｓｔ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及び割当リソースブロックを決定する。
【0040】
ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。
【0041】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとＩＡＢドナー２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。
【0042】
ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとＩＡＢドナー２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ＩＡＢドナー２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ＩＡＢドナー２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。
【0043】
ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。
【0044】
図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを表す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを表す図である。ここでは、ＩＡＢドナー２００がＣＵ及びＤＵに分割されている一例を示す。
【0045】
図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びＩＡＢドナー２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Ｂａｃｋｈａｕｌ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。
【0046】
各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）は、バックホールＲＬＣチャネル（ＢＨ ＮＲ ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成する。これにより、トラフィックの優先順位付け及びＱｏＳ制御が可能である。ＢＡＰ ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びＩＡＢドナー２００のＢＡＰレイヤによって実行される。
【0047】
なお、ＩＡＢドナー２００のＣＵは、ＩＡＢノード３００とＩＡＢドナー２００のＤＵへのＦ１インターフェイスを終端し、ＩＡＢドナー２００のｇＮＢ－ＣＵ機能である。また、ＩＡＢドナー２００のＤＵは、ＩＡＢ ＢＡＰサブレイヤをホストし、ＩＡＢノード３００へワイヤレスバックホールを提供し、ＩＡＢドナー２００のｇＮＢ－ＤＵ機能である。
【0048】
図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰ（Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ）レイヤを有する。
【0049】
なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ＩＡＢドナー２００のＤＵ又はＣＵの処理又は動作についても、単に「ＩＡＢドナー」の処理又は動作として説明する場合がある。
【0050】
また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。さらに、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。
【0051】
（第１実施形態）
ＩＡＢにおいては、トポロジ全体の公平性（ｔｏｐｏｌｏｇｙ－ｗｉｄｅ ｆａｉｒｎｅｓｓ。以下、「公平性」と称する場合がある。）という考え方がある。公平性は、例えば、ＵＥ１００がＩＡＢネットワークのどこに接続しても、トポロジ全体で要求されるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）が満たされるようにＱｏＳを管理するためのメカニズムを提供する。例えば、図１において、ＵＥ１００が、ＩＡＢノード３００－２に接続しても、ＩＡＢドナー２００－１に接続しても、同一のＱｏＳを得るように、トポロジ全体を管理することが、公平性である、ということができる。
ＩＡＢにおいては、トポロジ全体の公平性（ｔｏｐｏｌｏｇｙ－ｗｉｄｅ ｆａｉｒｎｅｓｓ。以下、「公平性」と称する場合がある。）という考え方がある。公平性は、例えば、ＵＥ１００がＩＡＢネットワークのどこに接続しても、トポロジ全体で要求されるＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）が満たされるようにＱｏＳを管理するためのメカニズムを提供する。例えば、図１において、ＵＥ１００が、ＩＡＢノード３００－２に接続しても、ＩＡＢドナー２００－１に接続しても、同一のＱｏＳを得るように、トポロジ全体を管理することが、公平性である、ということができる。
【0052】
このような公平性に対するアプローチは、例えば、以下の２つに分類される。
【0053】
（Ａ１）局所／分散型公平性最適化（Ｌｏｃａｌ／ｄｉｓｔｒｉｂｕｔｅｄ ｆａｉｒｎｅｓｓ ｏｐｔｉｍｉｚａｔｉｏｎ）
【0054】
（Ａ２）中央集権型公平性最適化（Ｃｅｎｔｒａｌｉｚｅｄ ｆａｉｒｎｅｓｓ ｏｐｔｉｍｉｚａｔｉｏｎ）
【0055】
例えば、（Ａ１）は、各ＩＡＢノード３００のスケジューラによって行われる。ＩＡＢノード３００は、残りホップ数などの情報をスケジューラに提供することによって、（Ａ１）のような最適化を図ることが可能になる。
【0056】
他方、（Ａ２）は、例えば、ＩＡＢドナー２００によるルーティング設定の更新などにより行われる。ＩＡＢノード３００が、ＩＡＢドナー２００へ、混雑状況及び／又は遅延情報などの情報を報告することで、ルーティング設定の更新が可能となる。
【0057】
（Ａ１）は、より高速化を図ることが可能であるというメリットはあるものの、そのメリットはローカル接続内に限定され、スケジューラの実装に依存して変化する可能性がある。また、（Ａ２）は、トポロジ全体の最適化を解決することは可能であるが、パケット単位での公平性を解決できない可能性がある。
【0058】
そこで、公平性に対するアプローチとして、（Ａ１）と（Ａ２）とを混在させるアプローチもある。上記２つを混在させることで、（Ａ１）と（Ａ２）のメリットを享受し、（Ａ１）と（Ａ２）のデメリットを最小限にすることが可能となる。
【0059】
第１実施形態では、このように混在する場合において、ＩＡＢドナー２００がＩＡＢノード３００に対して、（Ａ１）を行うか否かを指定する例である。具体的には、第１に、配下に中継ノード（例えば、ＩＡＢノード３００）を有するドナー基地局（例えば、ＩＡＢドナー２００）が、中継ノードに対して、中継ノードのスケジューラにデータパケットの転送における優先制御を行わせるか否かを設定する。第２に、中継ノードが、設定に従って、スケジューラを動作させる。以下では、データパケットの転送における優先制御を、単に、データパケットの転送制御と称する場合がある。
【0060】
図９は、ＩＡＢドナー２００が、ＩＡＢノード３００－Ｔに対して、ＩＡＢノード３００－Ｔのスケジューラにデータパケットの転送制御を行わせるか否かを設定する例を表す図である。データパケットの転送制御は、例えば、公平性に関する制御の一例である。このような設定により、例えば、ＩＡＢドナー２００がＩＡＢノード３００－Ｔに対して、公平性に関する制御（以下、「公平性制御」と称する場合がある。）を行わせるか否かを指定することができる。これにより、上記（Ａ１）を指定することが可能となる。
【0061】
図１１は、第１実施形態に係る動作例を表す図である。
【0062】
ＩＡＢドナー２００は、ステップＳ１０において、処理を開始すると、ステップＳ１１において、ＩＡＢノード３００－Ｔへ、ＩＡＢ用の公平性制御を行わせるか否かを設定する。公平性制御の具体例としては、例えば、以下がある。
【0063】
（Ｂ１）（過去の）経由ホップ数が大きいデータパケットの転送を優先する。これにより、例えば、遅延の大きいデータパケットが優先して転送されるため、上述した公平性の実現を図ることが可能となる。
【0064】
（Ｂ２）（未来の）残りホップ数が大きいデータパケットの転送を優先する。この場合も（Ｂ１）と同様に、遅延の大きいデータパケットが優先して転送されるため、公平性の実現を図ることが可能となる。
【0065】
（Ｂ３）ＢＨ ＲＬＣチャネルあたりのＵＥベアラ多重数（１：Ｎマッピングの“Ｎ”）が大きいデータパケットの転送を優先する。これにより、例えば、データ量が多いデータパケットが優先して転送されるため、データ量が多いことによる転送遅延を少なくして、上述した公平性の実現を図ることが可能となる。
【0066】
（Ｂ４）タイムスタンプを基準として経過時間が長いデータパケットの転送を優先する。これにより、例えば、ある時刻を基準にした経過時間が長いデータパケットが優先して転送されるため、転送遅延を少なくして、公平性の実現を図ることが可能となる。
【0067】
なお、ＩＡＢドナー２００は、上記（Ｂ１）から（Ｂ４）を組み合わせて、公平性制御の設定を行うようにしてもよい。また、ＩＡＢドナー２００は、このような公平性制御から除外するＵＥベアラＩＤ、又はＢＨ ＲＬＣチャネルＩＤを、ＩＡＢノード３００－Ｔに設定するようにしてもよい。さらに、ＩＡＢドナー２００は、ＩＡＢノード３００－Ｔへ、ＲＲＣメッセージ、Ｆ１－ＡＰメッセージ、又はＭＡＣ ＣＥなどを送信することで、ＩＡＢノード３００に対して公平性制御の設定を行うようにしてもよい。
【0068】
ステップＳ１２において、ＩＡＢノード３００－Ｔは、設定に従って、スケジューラを動作させる。すなわち、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵ（スケジューラ）は、上記（Ｂ１）から（Ｂ４）による設定に従って、データパケットの転送制御を行う。具体的には、以下となる。
【0069】
例えば、ＩＡＢノード３００を経由する毎にインクリメントされるホップ数がＢＡＰ Ｄａｔａ ＰＤＵのヘッダに含まれる。上記（Ｂ１）が設定された場合、スケジューラは、当該ホップ数に基づいて、経由ホップ数の大きいデータパケットを優先して転送させる。
【0070】
例えば、ＢＡＰ Ｄａｔａ ＰＤＵのヘッダには、ターゲットまでのホップ数が含まれ、当該ホップ数はＩＡＢノード３００を経由する毎にデクリメントされる。上記（Ｂ２）が設定された場合、スケジューラは、当該ホップ数に基づいて、残りホップ数が大きいデータパケットの転送を優先する。
【0071】
上記（Ｂ３）が設定された場合、スケジューラは、ＢＨ ＲＬＣチャネルあたりのＵＥ１００毎のベアラ多重数を確認して、当該ベアラ多重数の大きいデータパケットを優先して転送する。
【0072】
上記（Ｂ４）が設定された場合、スケジューラは、ＢＡＰ Ｄａｔａ ＰＤＵのヘッダに含まれるタイムスタンプ値を基準にして、経過時間が長いデータパケットを優先して転送する。
【0073】
ステップＳ１３において、ＩＡＢノード３００は、一連の処理を終了する。
【0074】
上述した実施形態では、スケジューラによる公平性制御（優先制御）の例を示したが、これに限らない。公平性制御は、ルーティング処理においても実施されてもよい。具体的には、ＢＡＰレイヤにおいて、優先すべきパケット（例えば、残りホップ数が多いパケット）のルーティング処理を優先する。換言すると、ＢＡＰレイヤは、優先するパケットを、他のパケットよりも先に（もしくは早く）下位レイヤ（例えば、ＲＬＣレイヤ）に渡す（もしくは転送する）。この場合、上述した実施形態と同様に、ＩＡＢドナー２００は、ＩＡＢノード３００に対して、公平性制御に関する設定を行い、ＩＡＢノード３００は、当該設定に従って、ルーティング処理を実施することが可能であることに留意すべきである。
【0075】
第１実施形態における他の例を説明する。
【0076】
第１実施形態における他の例は、第１に、ドナー基地局（例えば、ＩＡＢドナー２００）が、中継ノード（例えば、ＩＡＢノード３００）に対して、アシスト情報を当該親ノード又は子ノードへ通知させるか否かを設定する。当該アシスト情報は、中継ノードの親ノード又は子ノードのスケジューラにおいてデータパケットの転送制御が行われるための情報である。第２に、中継ノードが、設定に従って、親ノード又は子ノードへ、アシスト情報を通知する。
【0077】
図１０は、ＩＡＢドナー２００が、ＩＡＢノード３００－Ｔへ、アシスト情報を通知するか否かを設定する例を表す図である。このような設定により、ＩＡＢノード３００－Ｔの親ノード３００－Ｐ又は子ノード３００－Ｃは、アシスト情報に基づいて、公平性制御を実行することが可能となる。したがって、このような設定により、ＩＡＢドナー２００が、ＩＡＢノード３００－Ｔの親ノード３００－Ｐ又は子ノード３００－Ｃ（のスケジューラ）に対して、上記（Ａ１）を（間接的に）指定することが可能となる。
【0078】
図１２は、第１実施形態における他の例に係る動作例を表す図である。
【0079】
ＩＡＢドナー２００は、ステップＳ２０において、処理を開始すると、ステップＳ２１において、ＩＡＢノード３００－Ｔへ、スケジューリングのアシスト情報を当該ＩＡＢノード３００－Ｔの親ノード３００－Ｐ又は子ノード３００－Ｃへ通知するか否かの設定を行う。当該設定は、ＲＲＣメッセージ、又はＦ１－ＡＰメッセージなどを利用して行われる。
【0080】
なお、アシスト情報は、ＢＡＰ Ｄａｔａ ＰＤＵのヘッダに含まれる情報であって、ＩＡＢノード３００を経由するごとに変更される情報であってもよい。このような情報としては、例えば、ホップ数のカウント値、又は転送レイテンシ計測用のタイムスタンプ値がある。また、アシスト情報は、フロー制御フィードバック（ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）メッセージなどの混雑情報であってもよい。フロー制御フィードバックメッセージは、例えば、ＩＡＢノード３００－Ｔが混雑（ｃｏｎｇｅｓｔｉｏｎ）しているときに、親ノード３００－Ｐ又は子ノード３００－Ｃへ、混雑していることを通知するために用いられるメッセージである。
【0081】
ステップＳ２２において、ＩＡＢノード３００－Ｔは、設定に従って、アシスト情報を、親ノード３００－Ｐ又は子ノード３００－Ｃへ通知する。親ノード３００－Ｐ又は子ノード３００－Ｃのスケジューラは、アシスト情報に基づいて、公平性制御（例えば、（Ｂ１）から（Ｂ４）の全部又は一部）を行う。
【0082】
ステップＳ２３において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0083】
第１実施形態における他の例において、アシスト情報が、ＩＡＢノード３００－Ｔから親ノード３００－Ｐ又は子ノード３００－Ｃへ提供される例を示したが、これに限らない。アシスト情報がＩＡＢドナー２００からＩＡＢノード３００－Ｔへ提供され、提供を受けたＩＡＢノード３００－Ｔが公平性制御を行ってもよい。この場合、当該アシスト情報は、ＢＨ ＲＬＦチャネル毎もしくはルーティングＩＤ毎の、残りホップ数、ＵＥベアラ数、優先度情報（例えば、ＱｏＳ設定情報）、転送遅延情報（例えば、ある一定期間の実測平均レイテンシ）、及び／又は混雑度情報（例えば、負荷や無線リソースの使用率もしくは余裕度）などであってもよい。当該アシスト情報は、第２実施形態で、ＩＡＢドナー２００が集約した情報を用いてもよい。
【0084】
（第２実施形態）
公平性について、第１実施形態で説明した（Ａ２）によるアプローチが採用される場合、できるだけ、ＩＡＢノード３００の情報を、ＩＡＢドナー２００へ、集約させた方が良い。トポロジ全体の公平性を把握しているのはＩＡＢドナー２００であって、ＩＡＢドナー２００が中心となって公平性の実現を図ることができるからである。
公平性について、第１実施形態で説明した（Ａ２）によるアプローチが採用される場合、できるだけ、ＩＡＢノード３００の情報を、ＩＡＢドナー２００へ、集約させた方が良い。トポロジ全体の公平性を把握しているのはＩＡＢドナー２００であって、ＩＡＢドナー２００が中心となって公平性の実現を図ることができるからである。
【0085】
第２実施形態は、第１に、中継ノード（例えば、ＩＡＢノード３００）が、当該中継ノードを配下に有するドナー基地局（例えば、ＩＡＢドナー２００）へ、ルート毎のスループットを表す第１情報を送信する。第２に、ドナー基地局が、第１情報に基づいて、所定の動作を行う。ＩＡＢドナー２００は、所定の動作として、ルーティング設定を更新する。これにより、例えば、ＩＡＢドナー２００は、ルーティング設定の更新を行うことで、上記（Ａ２）のアプローチによる公平性の実現を図ることが可能となる。
【0086】
図１３は、第２実施形態に係る動作例を表す図である。
【0087】
ＩＡＢノード３００は、ステップＳ３０において、処理を開始すると、ステップＳ３１において、ＩＡＢドナー２００へ、ルート毎のスループット情報を通知する。
【0088】
ＤＬ方向の場合、ＩＡＢノード３００とその子ノードとの間のＢＨリンク又はＩＡＢノード３００とＵＥ１００との間のアクセスリンクのリンク状態がスループットとして表される。この場合、当該ＩＡＢノード３００が、スループットを報告してもよい。一方、ＵＬ方向の場合、ＩＡＢノード３００とその親ノードとの間のＢＨリンクのリンク状態がスループットとして表される。この場合、当該親ノードが、スループットを報告してもよい。
【0089】
スループット情報は、当該ＢＨリンク又はアクセスリンクの最大スループット及び最小スループットのうち少なくとも一方で表されてもよい。スループット情報は、理論値、及び／又は実効値であってもよい。また、スループット情報は、ある一定期間における平均スループットでもよい。一定期間（例えば、過去１０秒など）は、ＩＡＢドナー２００によって設定されてもよい。なお、スループット情報は、ルート毎のスループット情報に代えて、パス毎のスループットでもよい。
【0090】
なお、ステップＳ３１のように、ＩＡＢノード３００がスループット情報を報告することで、ＩＡＢノード３００は、ＩＡＢノード３００のスケジューラの実装性又は当該スケジューラの負荷状況に応じた正確なスループットを、ＩＡＢドナー２００へ報告できる。
【0091】
ステップＳ３２において、ＩＡＢドナー２００は、スループット情報に基づいて、ルーティング設定の更新などを行う。
【0092】
ステップＳ３３において、ＩＡＢドナー２００は、一連の処理を終了する。
【0093】
（第３実施形態）
５ＧのＱｏＳ特性の一つとして、ＰＤＢ（Ｐａｃｋｅｔ Ｄｅｌａｙ Ｂｕｄｇｅｔ：パケット遅延バジェット）がある。ＰＤＢは、ＵＥ１００とＵＰＦ１２との間でパケットが遅延する時間の上限を表す。ＰＤＢを超えて遅延したパケットは、ローカルの判断に応じて破棄される場合がある。ＰＤＢが設定されることで、スケジューラでは、予期せぬ値を処理しなければならいことを回避することが可能となる。
５ＧのＱｏＳ特性の一つとして、ＰＤＢ（Ｐａｃｋｅｔ Ｄｅｌａｙ Ｂｕｄｇｅｔ：パケット遅延バジェット）がある。ＰＤＢは、ＵＥ１００とＵＰＦ１２との間でパケットが遅延する時間の上限を表す。ＰＤＢを超えて遅延したパケットは、ローカルの判断に応じて破棄される場合がある。ＰＤＢが設定されることで、スケジューラでは、予期せぬ値を処理しなければならいことを回避することが可能となる。
【0094】
このようにＰＤＢによるパケット破棄は、ローカルで実施されるため、ＩＡＢドナー２００はパケット破棄を検知することができない。
【0095】
そこで、第３実施形態では、ＩＡＢノード３００は、パケットを破棄した場合、破棄したパケット数をＩＡＢドナー２００へ報告する。具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、配下に当該中継ノードを有するドナー基地局（例えば、ＩＡＢドナー２００）へ、データパケット破棄数を表す第２情報を送信する。第２に、ドナー基地局が、第２情報に基づいて、所定の動作を行う。これにより、例えば、ＩＡＢドナー２００は、ＩＡＢノード３００におけるパケット破棄を検知して、ルーティング設定の更新などを行うことで、上記（Ａ２）のアプローチによる公平性の実現を図ることが可能となる。
【0096】
図１４は、第３実施形態に係る動作例を表す図である。
【0097】
ＩＡＢノード３００は、ステップＳ４０において、処理を開始すると、ステップＳ４１において、ＩＡＢドナー２００から、パケット転送の有効期間が設定される。設定は、例えば、ＲＲＣメッセージ、及び／又はＦ１－ＡＰメッセージなどを用いて行われる。
【0098】
ステップＳ４２において、ＩＡＢノード３００は、データパケット受信時に、当該データパケットが有効期間内であるか否かを判定する。例えば、ＩＡＢノード３００は、ＢＡＰ Ｄａｔａ ＰＤＵのヘッダに含まれるタイムスタンプ情報に基づいて、当該データパケットの遅延時間を計算し、設定された有効期間と比較する。これにより、ＩＡＢノード３００は、遅延時間が有効期間内であるか否かにより判定する。タイムスタンプ情報が、ソースにおける当該データパケット送信時の時間情報として表されている場合は、ＩＡＢノード３００は、現在時間と、タイムスタンプ情報とを比較して、遅延時間を計算してもよい。
【0099】
ステップＳ４３において、当該データパケットが有効期間内でなければ（ステップＳ４３においてＮＯ）、ステップＳ４４において、ＩＡＢノード３００は、当該データパケットを破棄する。このとき、ＩＡＢノード３００は、破棄したデータパケットの数をカウントし、そのカウント値と付随情報とを記録情報として、メモリなどに記憶する。付随情報は、例えば、流入（ｉｎｇｒｅｓｓ）ＢＨ ＲＬＣチャネルＩＤ、ルーティングＩＤ（又は宛先（Ｄｅｓｔｉｎａｔｉｏｎ）ＩＤ、或いはパスＩＤ）、及び／又は遅延時間（当該データパケットを受信した時点での遅延）を含む。
【0100】
ステップＳ４５において、ＩＡＢノード３００は、ＩＡＢドナー２００へ、記録情報を報告する。例えば、ＩＡＢノード３００は、破棄したパケット数が（一定期間内に）一定以上となった場合に報告する。又は、ＩＡＢノード３００は、一定周期で、報告してもよい。又は、ＩＡＢノード３００は、ＩＡＢドナー２００から要求（リクエスト）があった場合に報告してもよい。ＩＡＢノード３００は、ＢＡＰメッセージなどを利用して、ＩＡＢドナー２００へ、記録情報を報告してもよい。
【0101】
ステップＳ４６において、ＩＡＢノード３００は、一連の処理を終了する。なお、ＩＡＢドナー２００では、記録情報に基づいて、所定の動作として、ルーティング設定の更新などを行う。
【0102】
一方、ステップＳ４３において、当該データパケットが有効期間内であれば（ステップＳ４３でＹＥＳ）、ＩＡＢノード３００は、受信したデータパケットを次ホップへ転送する。
【0103】
そして、ステップＳ４６において、ＩＡＢノード３００は、一連の処理を終了する。
【0104】
（第４実施形態）
図１５は、ＩＡＢノード３００が、ＩＡＢドナー２００へ、障害発生通知メッセージを送信する例を表す図である。
図１５は、ＩＡＢノード３００が、ＩＡＢドナー２００へ、障害発生通知メッセージを送信する例を表す図である。
【0105】
図１５に示すように、ＩＡＢノード３００の親ノード３００－Ｐとその親ノードである上位ノード３００－Ｕとの間のＢＨリンクでＢＨ ＲＬＦ（Ｂａｃｋ Ｈａｕｌ Ｒａｄｉｏ Ｌｉｎｋ Ｆａｉｌｕｒｅ：ＢＨリンクの無線リンク障害）が発生したと仮定する。この場合、親ノード３００－Ｐは、ＢＨ ＲＬＦが発生したことを表す障害発生通知を、ＩＡＢノード３００－Ｔへ通知する。
【0106】
しかし、障害発生通知は、親ノード３００－ＰからＩＡＢノード３００－Ｔへ通知され、ＩＡＢドナー２００には通知されない。したがって、ＩＡＢドナー２００は、親ノード３００－ＰでＢＨ ＲＬＦが発生したことを検知できない。ＩＡＢドナー２００が親ノード３００－ＰでのＢＨ ＲＬＦを検知できない場合、トポロジ全体のパフォーマンスが低下（混雑又は遅延など）する恐れがある。
【0107】
そこで、第４実施形態は、ＩＡＢノード３００が障害発生通知を受信したときに、ＩＡＢドナー２００へ、受信したことを報告する。具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、当該中継ノードを配下に有するドナー基地局（例えば、ＩＡＢドナー２００）へ、障害発生通知を受信したことを表す第３情報を送信する。第２に、ドナー基地局が第３情報に基づいて、所定の動作を行う。所定の動作として、例えば、ＩＡＢドナー２００は、ルーティング設定の更新などを行う。これにより、例えば、トポロジ全体のパフォーマンス低下を防止することが可能となる。また、例えば、ＩＡＢドナー２００に情報を集約させて、上記（Ａ２）のアプローチによる公平性の実現を図ることが可能となる。
【0108】
なお、障害発生通知には、ＢＨ ＲＬＦのＴｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ（ＲＬＦ ｄｅｔｅｃｔｅｄ）がある。Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎは、親ノード３００－ＰのＩＡＢ－ＤＵが、ＢＨ ＲＬＦを検出すると、ＩＡＢノード３００－Ｔ（又はＵＥ１００）へ、通知するＩｎｄｉｃａｔｉｏｎである。また、障害発生通知には、ＢＨ ＲＬＦのＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ（Ｔｒｙｉｎｇ ｔｏ ｒｅｃｏｖｅｒ）がある。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎは、親ノード３００－ＰのＩＡＢ－ＤＵが、ＢＨ ＲＬＦからの回復動作を検知すると、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴ（又はＵＥ１００）へ、通知するＩｎｄｉｃａｔｉｏｎである。Ｔｙｐｅ１ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎとを区別しないときは、親ノード３００－ＰのＩＡＢ－ＤＵがＩＡＢノード３００－ＴのＩＡＢ－ＭＴ（又はＵＥ１００）へ、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを通知できる。Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎも、障害発生通知の一例である。
【0109】
図１６は、第４実施形態に係る動作例を表す図である。なお、以下では、障害発生通知として、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを例にして説明するが、Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎでもよいし、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎでもよい。
【0110】
ＩＡＢノード３００－Ｔは、ステップＳ５０において、処理を開始すると、ステップＳ５１において、親ノード３００－Ｐから、ＢＨ ＲＬＦのＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信する。
【0111】
ステップＳ５２において、ＩＡＢノード３００－Ｔは、ＩＡＢドナー２００へ、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信したことを通知する。当該通知には、親ノード３００－ＰのセルＩＤ、親ノード３００－ＰのｇＮＢ ＩＤ、及び／又は親ノード３００－ＰのＢＡＰアドレスが含まれてもよい。
【0112】
なお、この通知の送信経路としては、ＩＡＢノード３００－ＴがＤＣ（Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）により、親ノード３００－Ｐと他の親ノードと接続されている場合、例えば、以下がある。すなわち、ＩＡＢノード３００－Ｔは、ＭＣＧ（Ｍａｓｔｅｒ Ｃｅｌｌ Ｇｒｏｕｐ）経由でＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信すると、ＳＣＧ（Ｓｅｃｏｎｄａｒｙ Ｃｅｌｌ Ｇｒｏｕｐ）（ＳＲＢ（Ｓｉｇｎａｌｉｎｇ Ｒａｄｉｏ Ｂｅａｒｅｒ）３）経由で当該通知を送信してもよい。又は、ＩＡＢノード３００－Ｔは、ＳＣＧ経由でＴｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信すると、ＭＣＧ（ＳＲＢ１）経由で当該通知を送信してもよい。又は、ＩＡＢノード３００－Ｔは、Ｓｐｌｉｔ ＳＲＢ１経由で当該通知を送信してもよい。
【0113】
ステップＳ５３において、ＩＡＢドナー２００は、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを受信したことに応じて、親ノード３００－ＰにおいてＢＨ ＲＬＦが発生していることを認識し、所定の動作を行う。所定の動作としては、ルーティング設定の更新、ＩＡＢノード３００－Ｔに対するローカルリルーティングの指示、又はＩＡＢノード３００－Ｔに対するハンドオーバなどがある。
【0114】
ステップＳ５４において、ＩＡＢノード３００は、一連の処理を終了する。
【0115】
なお、上記動作例において、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎに代えて、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ、Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎ、又はフロー制御フィードバック（ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）メッセージでもよい。
【0116】
Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ（ＲＬＦ ｒｅｃｏｖｅｒｅｄ）は、親ノード３００－ＰがＢＨ ＲＬＦから回復したときに、ＩＡＢノード３００－Ｔへ通知される障害回復通知である。Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎ（Ｒｅｃｏｖｅｒｙ ｆａｉｌｕｒｅ）は、親ノード３００－ＰがＢＨ ＲＬＦからの回復に失敗したときに、ＩＡＢノード３００－Ｔへ通知される回復失敗通知の一例である。障害回復通知及び回復失敗通知は、例えば、ＢＨリンクにおける無線リンクの障害に関する通知である。
【0117】
また、フロー制御フィードバックメッセージは、例えば、親ノード３００－Ｐにおいてデータパケットの混雑が発生しているときに、親ノード３００－Ｐから通知されるメッセージである。
【0118】
（第５実施形態）
ＵＬ方向のスケジューリングに関して、プリエンプティブバッファステータスレポート（ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）。以下、「ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ」と称する場合がある。）が行われる場合がある。ここで、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲについて説明する。
ＵＬ方向のスケジューリングに関して、プリエンプティブバッファステータスレポート（ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）。以下、「ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ」と称する場合がある。）が行われる場合がある。ここで、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲについて説明する。
【0119】
【0120】
図１７（Ａ）に示すように、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃからデータを受信した後、親ノード３００－Ｐへ、通常のＢＳＲを送信する。親ノード３００－Ｐは、ＢＳＲに基づいて、ＩＡＢノード３００－Ｔに対してスケジューリングを行い、ＵＬ ｇｒａｎｔをＩＡＢノード３００－Ｔへ送信する。
【0121】
一方、図１７（Ｂ）に示すように、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃに対してＵＬ ｇｒａｎｔを送信後、子ノード３００－Ｃからデータを受信する前に、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを親ノード３００－Ｐへ送信する。
【0122】
また、図１７（Ｃ）に示すように、ＩＡＢノード３００－Ｔは、子ノード３００－ＣからＢＳＲを受信した後、ＵＬ ｇｒａｎｔを子ノード３００－Ｃへ送信する前に、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを親ノード３００－Ｐへ送信する。
【0123】
このように、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲは、通常のＢＳＲよりも早いタイミングで、親ノード３００－Ｐへ送信されるため、ＩＡＢノード３００－ＴにおけるＵＬスケジューリングの遅延を低減させることが可能となる。
【0124】
ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲは、通常のＢＳＲと同様に、ＭＡＣ ＣＥを用いて送信される。図１８は、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥ（以下、「ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ」と称する場合がある。）の構成例を表す図である。図１８に示すように、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥは、ＬＣＧｉとバッファサイズの各領域を含む。
【0125】
ＬＣＧｉは、論理チャネルグループ（ＬＣＧ：Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ）ｉのバッファサイズが存在することを示す領域である。すなわち、ＬＣＧｉに「１」が設定されると、論理チャネルグループ（ＬＣＧ：Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｇｒｏｕｐ）ｉのバッファサイズが報告されることを示す。一方、ＬＣＧｉに「０」が設定されると、論理チャネルグループｉのバッファサイズが報告されないことを示す。
【0126】
バッファサイズは、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲがトリガされたＩＡＢノード３００のＩＡＢ－ＭＴに到着することが期待されるデータの総量を識別し、ＩＡＢ－ＭＴにおいて現在利用可能なデータの総量は含まない。バッファサイズの詳細について、以下、説明する。
【0127】
図１９は、ＩＡＢノード３００と親ノード３００－Ｐ、及び子ノード３００－Ｃとの関係例を表す図である。図１９は、ＩＡＢノード３００－Ｔが、親ノード３００－Ｐへ、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを送信する例を表している。バッファサイズ領域には、図１９の例では、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲがトリガされた親ノード３００－ＰのＩＡＢ－ＭＴに到着すると予想されるデータの総量が格納される。親ノード３００－ＰのＩＡＢ－ＭＴに到着すると予想されるデータは、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータと、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータとの総量である。言い換えると、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲのバッファサイズ領域に格納されるバッファサイズは、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータと、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータとが混在したデータのデータ量となる。
【0128】
しかし、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータのスケジューリングタイミングと、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのスケジューリングタイミングとは異なる。そのため、親ノード３００－Ｐは、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを受信しても、異なるスケジューリングタイミングの２つのデータに対して、どのタイミングでスケジューリングを行えば良いのかわからない場合がある。
【0129】
そこで、第５実施形態では、ＩＡＢノード３００－Ｔは、自身のＩＡＢ－ＤＵに滞留したデータのデータ量と、子ノード３００－ＣのＩＡＢ－ＭＴに滞留したデータのデータ量とを、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲの異なるバッファサイズ領域に格納する。そして、ＩＡＢノード３００－Ｔは、当該ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを親ノード３００－Ｐへ送信する。
【0130】
具体的には、第１に、親ノード（例えば親ノード３００－Ｐ）と子ノード（例えば子ノード３００－Ｃ）との間に介在する中継ノード（例えばＩＡＢノード３００）が、親ノードへ、プリエンプティブバッファステータスレポート（ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ）を送信する。この際、中継ノードが、子ノードに滞留する第１データの第１データ量をｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲの第１バッファサイズ領域に格納する。また、中継ノードは、中継ノードに滞留する第２データの第２データ量を、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲの第２バッファサイズ領域に格納する。第２に、親ノードが、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを受信する。これにより、例えば、親ノード３００－Ｐは、第１データ量と第２データ量とが異なる領域に格納されたｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを受信できるため、第１データと第２データに対するスケジューリングを異なるタイミングで行うことが可能となる。
【0131】
図２０は第５実施形態の動作例を表す図である。
【0132】
ＩＡＢノード３００－Ｔは、ステップＳ６０において、処理を開始すると、ステップＳ６１において、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲをトリガする。
【0133】
ステップＳ６２において、ＩＡＢノード３００－Ｔは、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量を、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥのＢＳ（Ｂｕｆｆｅｒ Ｓｉｚｅ）＃１の領域に格納し、自身（のＩＡＢ－ＤＵ）に滞留するデータのデータ量を、ＢＳ＃２の領域に格納する。この際、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃに滞留するデータのデータ量を特定する。特定は、子ノード３００－Ｃから受信したＢＳＲに含まれるバッファサイズから特定してもよいし、ＩＡＢノード３００－Ｔが子ノード３００－Ｃに対してスケジューリングしたＵＬ ｇｒａｎｔ値から特定してもよい。また、ＩＡＢノード３００－Ｔは、自身のＩＡＢ－ＤＵに滞留するデータのデータ量を特定する。特定は、例えば、ＩＡＢノード３００－Ｔに滞留する受信側ＭＡＣ ＳＤＵ、受信側ＲＬＣ ＰＤＵ、及び／又は受信側ＢＡＰ ＰＤＵ（送信側ＢＡＰ ＰＤＵを含めてもよい）のデータ量から特定する。なお、ＢＳ＃１及びＢＳ＃２は、当該ＭＡＣ ＣＥにおいて、別々のバッファサイズ領域である。
【0134】
ステップＳ６３において、ＩＡＢノード３００－Ｔは、ＢＳ＃１とＢＳ＃２を含む、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥを、親ノード３００－Ｐへ送信する。
【0135】
ステップＳ６４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0136】
なお、ステップＳ６３では、１つのｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥに、ＢＳ＃１とＢＳ＃２を含む例について説明したが、ＢＳ＃１とＢＳ＃２がそれぞれ異なるｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥに含まれてもよい。この場合、ＩＡＢノード３００－Ｔは、ＢＳ＃１を含むｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥと、ＢＳ＃２を含むｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥと、を送信することになる。
【0137】
また、図１８に示すｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥは一例である。例えば、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥは、バッファサイズ領域が含まれるＭＡＣ ＣＥであればどのような構成のｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥでもよい。
【0138】
（第６実施形態）
第６実施形態は、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータのデータ量と、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量とを、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲのＬＣＧｉを利用して区別する例である。
第６実施形態は、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータのデータ量と、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量とを、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲのＬＣＧｉを利用して区別する例である。
【0139】
具体的には、第１に、配下に中継ノード（例えば、ＩＡＢノード３００－Ｔ）を有するドナー基地局（例えば、ＩＡＢドナー２００）が、中継ノードに対して、第１論理チャネルグループを設定する。第２に、中継ノードが、第１論理チャネルグループに対応するバッファサイズ領域であって、プリエンプティブバッファステータスレポートの第３バッファサイズ領域に、中継ノードの子ノードに滞留する第１データの第１データ量を格納する。
【0140】
図２１は第６実施形態に係る動作例を表す図である。
【0141】
ステップＳ７０において、ＩＡＢドナー２００は、処理を開始する。
【0142】
ステップＳ７１において、ＩＡＢドナー２００は、ＩＡＢノード３００－Ｔに対して、子ノード３００－ＣのＢＳＲ値（又はバッファサイズ値）を格納するＬＣＧを設定する。設定は、ＲＲＣメッセージ又はＦ１－ＡＰメッセージなどを用いて行われる。例えば、ＩＡＢドナー２００は、ＬＣＧ０（図１８）を、子ノード３００－ＣのＢＳＲ値を格納するＬＣＧとして設定する。
【0143】
ステップＳ７２において、ＩＡＢノード３００－Ｔは、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲをトリガする。
【0144】
ステップＳ７３において、ＩＡＢノード３００－Ｔは、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量を、設定されたＬＣＧ（例えば、ＬＣＧ０）に対応するＢＳ（例えば、ＢＳ＃１）に格納する。子ノード３００－Ｃに滞留するデータは、第５実施形態と同様に、子ノード３００－ＣからのＢＳＲ又は子ノード３００－ＣへのＵＬ ｇｒａｎｔ値に基づいて、ＩＡＢノード３００－Ｔにおいて特定してもよい。
【0145】
ステップＳ７４において、ＩＡＢノード３００－Ｔは、当該ＢＳを含む、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥを親ノード３００－Ｐへ送信する。
【0146】
ステップＳ７５において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0147】
なお、上述した動作例は、子ノード３００－Ｃに滞留するデータのデータ量を送信する例である。ＩＡＢノード３００－Ｔ自身のＩＡＢ－ＤＵに滞留するデータのデータ量の送信は、例えば、以下のようにして行う。
【0148】
すなわち、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータは、ＩＡＢノード３００－Ｔにおいて、子ノード３００－Ｃから既に受信したデータである。ＩＡＢノード３００－Ｔは、当該データに対して、設定されたルーティング情報と比較することによって、どの論理チャネルを利用して当該データを送信するかを把握できる。そして、ＩＡＢノード３００－Ｔは、当該論理チャネルに対応するＬＣＧ（例えば、ＬＣＧ１）を特定し、当該ＬＣＧに対応するＢＳ（例えば、ＢＳ＃２）に、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータを格納できる。
【0149】
このような処理は、例えば、図２１に示す動作例のステップＳ７３において行われる。すなわち、ＩＡＢノード３００－Ｔは、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量を、ＩＡＢドナー２００により設定されたＬＣＧに対応するＢＳ（例えば、ＢＳ＃１）に格納する。ＩＡＢノード３００－Ｔは、自身のＩＡＢ－ＤＵに滞留するデータのデータ量を、ルーティング情報から特定したＬＣＧに対応するＢＳ（例えば、ＢＳ＃２）に格納する。
【0150】
なお、子ノード３００－Ｃに滞留するデータのデータ量に関し、ＩＡＢドナー２００によるＬＣＧの設定に代えて、ルーティング情報から特定したＬＣＧ以外のＬＣＧに対応するＢＳ（例えば、ＢＳ＃３）に格納するようにしてもよい。すなわち、ＩＡＢノード３００は、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータのデータ量をルーティング情報から特定したＬＣＧ（例えば、ＬＣＧ１）に対応するＢＳ（例えば、ＢＳ＃２）に格納する。一方、ＩＡＢノード３００は、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量を当該ＬＣＧ以外のＬＣＧ（例えば、ＬＣＧ２）に対応するＢＳ（例えば、ＢＳ＃３）に格納する。したがって、ＩＡＢノード３００－Ｔは、２つのデータのデータ量をｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥにおける異なるバッファサイズ領域に確実に格納して送信することが可能となる。
【0151】
（第７実施形態）
第７実施形態は、ＩＡＢノード３００－Ｔが、子ノード３００－Ｃに滞留するデータのデータ量をｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲで報告し、ＩＡＢノード３００－Ｔに滞留するデータのデータ量を通常のＢＳＲで報告する例である。
第７実施形態は、ＩＡＢノード３００－Ｔが、子ノード３００－Ｃに滞留するデータのデータ量をｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲで報告し、ＩＡＢノード３００－Ｔに滞留するデータのデータ量を通常のＢＳＲで報告する例である。
【0152】
図２２は、ＩＡＢノード３００が、親ノード３００－Ｐへ、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲと通常のＢＳＲとを送信する例を表す図である。
【0153】
通常のＢＳＲは、現状では、ＩＡＢ－ＭＴに滞留するデータのデータ量のみを報告する。しかし、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵに滞留するデータも、すぐに送信可能となるため、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲではなく、通常のＢＳＲを用いて送信した方がよい。
【0154】
そこで、本第７実施形態では、ＩＡＢノード３００－Ｔは、自身のＩＡＢ－ＭＴとＩＡＢ－ＤＵに滞留するデータのデータ量を、ＢＳＲを用いて報告する。また、ＩＡＢノード３００－Ｔは、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量を、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを用いて報告する。
【0155】
具体的には、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、親ノード（例えば、親ノード３００－Ｐ）へ、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲを利用して子ノード（例えば、子ノード３００－Ｃ）に滞留する第１データの第１データ量を送信する。中継ノードが、バッファステータスレポートを利用して中継ノードに滞留する第２データの第２データ量を送信する。
【0156】
図２３は第７実施形態に係る動作例を表す図である。
【0157】
図２３に示すように、ステップＳ８０において、ＩＡＢノード３００－Ｔは、処理を開始する。
【0158】
ステップＳ８１において、ＩＡＢノード３００－Ｔは、通常のＢＳＲとｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲとをトリガする。
【0159】
ステップＳ８２において、ＩＡＢノード３００－Ｔは、自身のＩＡＢ－ＤＵとＩＡＢ－ＭＴに滞留するデータを特定し、通常のＢＳＲ ＭＡＣ ＣＥのＢＳに格納する。ＩＡＢノード３００－Ｔは、例えば、送信側及び受信側ＢＡＰ ＰＤＵ、受信側ＲＬＣ ＰＤＵ、及び／又は受信側ＭＡＣ ＳＤＵに基づいて、自身のＩＡＢ－ＤＵに滞留するデータのデータ量を特定する。また、ＩＡＢノード３００－Ｔは、例えば、送信側ＭＡＣ ＳＤＵ、及び／又は送信側ＲＬＣ ＰＤＵに基づいて、自身のＩＡＢ－ＭＴに滞留するデータのデータ量を特定する。
【0160】
また、ステップＳ８２において、ＩＡＢノード３００－Ｔは、子ノード３００－ＣのＩＡＢ－ＭＴに滞留するデータのデータ量をｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥのＢＳに格納する。子ノード３００－Ｃに滞留するデータのデータ量の特定は、例えば、第５実施形態と同様である。
【0161】
ステップＳ８３において、ＩＡＢノード３００－Ｔは、通常のＢＳＲ ＭＡＣ ＣＥと、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥとを、親ノード３００－Ｐへ送信する。
【0162】
ステップＳ８４において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。
【0163】
この動作例に伴い、３ＧＰＰ ＴＳ３８．３２１で規定された、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥのバッファサイズは、「ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲがトリガされたノードのＩＡＢ－ＭＴに到着することが期待されるデータの総量」から、「ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲがトリガされたノードのＩＡＢ－ＤＵに到着することが期待されるデータの総量」へと変更されることになる。
【0164】
なお、図２３における動作例において、ＩＡＢノード３００－Ｔは、ｐｒｅ－ｅｍｐｔｉｖｅ ＢＳＲ ＭＡＣ ＣＥとＢＳＲ ＭＡＣ ＣＥとを異なるタイミングで送信してもよい。
【0165】
（その他の実施形態）
ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。
【0166】
また、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行する回路を集積化し、ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。
【0167】
以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。また、矛盾しない範囲で、各実施例の全部又は一部を組み合わせることも可能である。
【0168】
本願は、米国仮出願第６３／１３６，４７２号（２０２１年１月１２日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【0169】
（付記）
（導入）
ＮＲのためのｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）に関する改訂されたワークアイテムが承認された。いくつかの目的は次の通りである。
（導入）
ＮＲのためのｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）に関する改訂されたワークアイテムが承認された。いくつかの目的は次の通りである。
【0170】
トポロジ適応の拡張
・シグナリング負荷を軽減するための機能拡張を含む、堅牢性及び負荷分散を強化するためのインタードナーＩＡＢノード移動のための手順の仕様。
・ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性に対する拡張の仕様。
トポロジ、ルーティング、及びトランスポートの機能拡張
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
・シグナリング負荷を軽減するための機能拡張を含む、堅牢性及び負荷分散を強化するためのインタードナーＩＡＢノード移動のための手順の仕様。
・ＩＡＢノード移動及びＢＨ ＲＬＦ回復によるサービス中断削減のための拡張機能の仕様。
・ＣＰ／ＵＰ分離のサポートを含む、トポロジの冗長性に対する拡張の仕様。
トポロジ、ルーティング、及びトランスポートの機能拡張
・トポロジ全体の公平性、マルチホップ遅延、及び輻輳緩和を改善するための拡張機能の仕様。
【0171】
トポロジ、ルーティング、及びトランスポートの機能拡張に関して、次の合意に達した。
【0172】
・Ｒ２は、Ｒｅｌ－１７ ＩＡＢのワークは、既存の５ＧＱｏＳフレームワークに加えて新しいエンドユーザＱｏＳメトリックを定義されないことを前提とする。
・Ｒｅｌ－１７ ＩＡＢのワークには、トポロジ全体の公平性の定義について合意することが含まれる。
・トポロジ全体の公平性は、ＵＥがＩＡＢネットワークのどこにアタッチされるかに関わらず、トポロジ全体で必要なＱｏＳが満たされるように、ＱｏＳを管理するためのメカニズムを提供する。この定義の変形は排除されない。そのようなメカニズムの成功がどのように評価されるかは、更なる検討が必要である。
・ＲＡＮ２は、ＲＡＮ３からのインプットなしで、ＤＬＥ ２Ｅフロー制御の拡張について議論しない。
・ＲＡＮ２が無線ベアラのデータを２つ以上のパスにスプリットする優先順位を下げるか否かは更なる検討が必要である。（ＲＡＮ３は、ＩＡＢでのデータスプリットでのマルチルートサポートの優先順位を下げることに合意）
・Ｒｅｌ－１７ ＩＡＢのワークには、トポロジ全体の公平性の定義について合意することが含まれる。
・トポロジ全体の公平性は、ＵＥがＩＡＢネットワークのどこにアタッチされるかに関わらず、トポロジ全体で必要なＱｏＳが満たされるように、ＱｏＳを管理するためのメカニズムを提供する。この定義の変形は排除されない。そのようなメカニズムの成功がどのように評価されるかは、更なる検討が必要である。
・ＲＡＮ２は、ＲＡＮ３からのインプットなしで、ＤＬＥ ２Ｅフロー制御の拡張について議論しない。
・ＲＡＮ２が無線ベアラのデータを２つ以上のパスにスプリットする優先順位を下げるか否かは更なる検討が必要である。（ＲＡＮ３は、ＩＡＢでのデータスプリットでのマルチルートサポートの優先順位を下げることに合意）
【0173】
この付記では、Ｒｅｌ－１７ ＩＡＢのトポロジ、ルーティング、及びトランスポートの拡張について議論し、ＢＳＲ及びプリエンプティブＢＳＲの拡張、及びトポロジ全体の公平性のための一般的なフレームワークに焦点を当てる。
【0174】
（議論）
（ＢＳＲ及びプリエンプティブＢＳＲの拡張）
（ＬＣＧ領域の拡張）
Ｒｅｌ－１６では、ＵＥのＬＣＧの数、つまり、最大８つのＬＣＧが、ＩＡＢ－ＭＴに再利用されました。多くの企業がＬＣＧの数を増やすことを提案した。ＬＣＧ領域を拡張すると、ＬＣＧあたりのＬＣＨの数が減り、スケジューリングの粒度が細かくなり、トポロジ全体の公平性に貢献するようである。したがって、ＲＡＮ２はＬＣＧの数を増やすべきである。これは、レガシーＢＳＲ及びプリエンプティブＢＳＲの両方に適用できる。
（ＢＳＲ及びプリエンプティブＢＳＲの拡張）
（ＬＣＧ領域の拡張）
Ｒｅｌ－１６では、ＵＥのＬＣＧの数、つまり、最大８つのＬＣＧが、ＩＡＢ－ＭＴに再利用されました。多くの企業がＬＣＧの数を増やすことを提案した。ＬＣＧ領域を拡張すると、ＬＣＧあたりのＬＣＨの数が減り、スケジューリングの粒度が細かくなり、トポロジ全体の公平性に貢献するようである。したがって、ＲＡＮ２はＬＣＧの数を増やすべきである。これは、レガシーＢＳＲ及びプリエンプティブＢＳＲの両方に適用できる。
【0175】
提案１：ＲＡＮ２は、ＢＳＲ及びプリエンプティブＢＳＲのＬＣＧの数を増やすことに合意すべきである。
【0176】
（バッファサイズの計算）
レガシーＢＳＲの場合、バッファサイズの計算は明確に規定される。これは、ＭＡＣ、ＲＬＣ、及びＰＤＣＰで利用可能なデータに基づく。ＲＬＣ及びＰＤＣＰの場合、データ量の計算手順は各仕様で規定される。Ｒｅｌ－１６では、これらのメカニズムはＩＡＢ－ＭＴで再利用される。しかし、ＩＡＢノードにはＰＤＣＰの代わりにＢＡＰレイヤがあり、ＢＡＰにはデータ量の計算はない。そのため、現在の仕様では送信に利用可能なデータが不足している。トポロジ全体の公平性のためにより適切にスケジューリングするには、レガシーＢＳＲで報告されるバッファサイズをより正確にすべきである。
レガシーＢＳＲの場合、バッファサイズの計算は明確に規定される。これは、ＭＡＣ、ＲＬＣ、及びＰＤＣＰで利用可能なデータに基づく。ＲＬＣ及びＰＤＣＰの場合、データ量の計算手順は各仕様で規定される。Ｒｅｌ－１６では、これらのメカニズムはＩＡＢ－ＭＴで再利用される。しかし、ＩＡＢノードにはＰＤＣＰの代わりにＢＡＰレイヤがあり、ＢＡＰにはデータ量の計算はない。そのため、現在の仕様では送信に利用可能なデータが不足している。トポロジ全体の公平性のためにより適切にスケジューリングするには、レガシーＢＳＲで報告されるバッファサイズをより正確にすべきである。
【0177】
提案２：ＲＡＮ２は、データ量の計算手順をＢＡＰのために規定すべきかを議論すべきである。
【0178】
Ｒｅｌ－１６では、プリエンプティブＢＳＲのバッファサイズの計算は、ＩＡＢ－ＤＵの実装に大きく依存するが、仕様は、「バッファサイズフィールドは、プリエンプティブＢＳＲがトリガされるノードのＩＡＢ－ＭＴに到着すると予想されるデータの合計量を識別し、ＩＡＢ－ＭＴで現在利用可能なデータの量は含まれない。」という大まかなガイドラインを提供する。一部のＩＡＢノードは、プリエンプティブＢＳＲで、実際に到着すると予想されるよりも大きなバッファサイズを報告する可能性がある。マルチベンダー展開の場合などでは、子ノードと親ノードとの間に同じ原則を設定することが難しい可能性がある。これは、非効率な無線リソースの割り当て、親でのスケジューリング遅延、及びＩＡＢ－ＭＴ間のリソース要求の不公平を引き起こす。ＩＡＢノードがデュアルコネクティビティで設定されている場合、よりあいまいになる可能性がある。したがって、プリエンプティブＢＳＲのバッファサイズの計算は、より正確に規定されるべきである。
【0179】
提案３：ＲＡＮ２は、プリエンプティブＢＳＲのバッファサイズの計算を規定すべきである。
【0180】
（トポロジ全体の公平性）
トポロジ全体の公平性の強化は、次の２つのアプローチによって分類される。
・スケジューラなどによる局所／分散型の公平性の最適化
・ルーティング設定の更新などによる中央集権型の公平性の最適化
トポロジ全体の公平性の強化は、次の２つのアプローチによって分類される。
・スケジューラなどによる局所／分散型の公平性の最適化
・ルーティング設定の更新などによる中央集権型の公平性の最適化
【0181】
局所／分散型の公平性の最適化に関して、例えば、スケジューラアルゴリズムを最適化するために、ＩＡＢノードには、利益メトリック、残りのホップ数などの情報が提供される。一部の解決策は各スケジューラの実装に強く依存していることに気づく。存在するならば、すべての実装に役立つ可能性のある共通／一般的な情報を規定することだけが望ましい。
【0182】
一方、中央集権型の公平性の最適化では、ＩＡＢドナーには、輻輳状態、遅延／レイテンシなどの情報又は測定値とともに報告され、例えば、ルーティング設定の更新を決定する。したがって、このアプローチは一種のＭＤＴ及びＳＯＮと見なすことができる。
【0183】
私たちの見解では、これらのアプローチには長所と短所とがある。局所／分散型のアプローチはより高速なメカニズムであり得るが、メリットはローカル接続内に制限され、スケジューラの実装によって変わり得る。中央集権型のアプローチは、トポロジ全体／大幅な最適化を解決し得るが、パケットごとの公平性には機能しない可能性がある。したがって、ＲＡＮ２は、トポロジ全体の公平性を強化するために、どちら（又は双方）のアプローチがより望ましいか議論すべきである。
【0184】
提案４：ＲＡＮ２は、トポロジ全体の公平性の強化は、（例えば、各スケジューラによる）局所／分散型のアプローチ、又は（例えば、ルーティング設定の更新を伴うＩＡＢ－ｄｏｎｏｒ－ＣＵによる）中央集権型のアプローチ、又はその双方によって実現すべきかを議論すべきである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】