JP6977187B2 - 通信制御方法 - Google Patents

Description

本開示は、移動通信システムに用いられる通信制御方法に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと称される新たな中継装置が検討されている。１又は複数の中継装置が基地局とユーザ機器との間の通信に介在し、この通信に対する中継を行う。かかる中継装置は、ユーザ機器機能及び基地局機能を有しており、ユーザ機器機能を用いて上位ノード（基地局又は上位の中継装置）との無線通信を行うとともに、基地局機能を用いて下位ノード（ユーザ機器又は下位の中継装置）との無線通信を行う。

ユーザ機器と、中継装置又は基地局との間の無線区間は、アクセスリンクと称されることがある。中継装置と、基地局又は他の中継装置との間の無線区間は、バックホールリンクと称されることがある。３ＧＰＰ寄書「ＲＰ−１７０２１７」には、アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクに動的に無線リソースを割り当てることにより、データ転送経路を動的に切り替える方法が記載されている。

一実施形態に係る通信制御方法は、移動通信システムにおいてユーザ装置からドナー基地局へ送信される上りリンクデータを中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置のＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）エンティティが、前記中継装置と前記ドナー基地局との間に介在する他の中継装置に対して前記上りリンクデータを送信することと、前記中継装置のエンティティであって前記ＲＬＣエンティティよりも上位の上位エンティティが、前記他の中継装置を介して、前記上りリンクデータに対応する送達情報を前記ドナー基地局から受信することと、前記上位エンティティが、前記ドナー基地局から受信した前記送達情報に関する情報を前記ＲＬＣエンティティに通知することと、を含む。

実施形態に係る移動通信システムの構成を示す図である。 実施形態に係る基地局（ｇＮＢ）の構成を示す図である。 実施形態に係る中継装置（ＩＡＢノード）の構成を示す図である。 実施形態に係るユーザ機器（ＵＥ）の構成を示す図である。 実施形態に係る移動通信システムにおけるユーザプレーンのプロトコルスタック構成の一例を示す図である。 第１実施形態に係る通常動作シーケンスの一例を示す図である。 第１実施形態に係るコンテキスト転送先を決定するためのテーブルの一例を示す図である。 第１実施形態に係る例外動作シーケンスの一例を示す図である。 第１実施形態に係るマルチホップ接続シーケンスの一例を示す図である。 第２実施形態に係る「ｅｎｄ−ｔｏ−ｅｎｄ」の一例を示す図である。 第２実施形態に係る「ｈｏｐ−ｂｙ−ｈｏｐ」の一例を示す図である。 第２実施形態に係る動作例を示すシーケンス図である。 第２実施形態に係る他の動作例を示すシーケンス図である。 第２実施形態の変更例１を示す図である。 第２実施形態の変更例２の想定シナリオを示す図である。 第２実施形態の変更例２に係る動作を示す図である。 第２実施形態の変更例３の想定シナリオを示す図である。 第２実施形態の変更例３に係る動作を示す図である。 第２実施形態の変更例４に係る動作を示す図である。 第３実施形態に係るＩＡＢノードの動作を示す図である。 第４実施形態に係る動作を示す図である。 付記に係る図である。 付記に係る図である。

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

［第１実施形態］
（移動通信システムの構成）
本実施形態に係る移動通信システムの構成について説明する。図１は、本実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）移動通信システムである。具体的には、移動通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、移動通信システム１には、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。

図１に示すように、移動通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ機器（ＵＥ）１００と、基地局（ｇＮＢと称される）２００と、ＩＡＢノード３００とを備える。本実施形態において、基地局がＮＲ基地局である一例について主として説明するが、基地局がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。

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

ｇＮＢ２００は、ＮＧインターフェイスと称されるインターフェイスを介して、５ＧＣ１０に接続される。図１において、５ＧＣ１０に接続された３つのｇＮＢ２００−１〜ｇＮＢ２００−３を例示している。ｇＮＢ２００は、ＵＥ１００との無線通信を行う固定の無線通信装置である。ｇＮＢ２００がドナー機能を有する場合、ｇＮＢ２００は、自身に無線で接続するＩＡＢノードとの無線通信を行ってもよい。

ｇＮＢ２００は、Ｘｎインターフェイスと称される基地局間インターフェイスを介して、隣接関係にある他のｇＮＢ２００と接続される。図１において、ｇＮＢ２００−１がｇＮＢ２００−２及びｇＮＢ２００−３に接続される一例を示している。

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

ＵＥ１００は、ｇＮＢ２００との無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ＩＡＢノード３００との無線通信を行ってもよい。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末、タブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、又は車両若しくは車両に設けられる装置である。

図１において、ＵＥ１００−１がｇＮＢ２００−１に無線で接続され、ＵＥ１００−２がＩＡＢノード３００−１に無線で接続され、ＵＥ１００−３がＩＡＢノード３００−２に無線で接続される一例を示している。ＵＥ１００−１は、ｇＮＢ２００−１との通信を直接的に行う。ＵＥ１００−２は、ＩＡＢノード３００−１を介してｇＮＢ２００−１との通信を間接的に行う。ＵＥ１００−３は、ＩＡＢノード３００−１及びＩＡＢノード３００−２を介してｇＮＢ２００−１との通信を間接的に行う。

ＩＡＢノード３００は、ｅＮＢ２００とＵＥ１００との間の通信に介在し、この通信に対する中継を行う装置（中継装置）である。図１において、ＩＡＢノード３００−１がドナーであるｇＮＢ２００−１に無線で接続され、ＩＡＢノード３００−２がＩＡＢノード３００−１に無線で接続される一例を示している。各ＩＡＢノード３００は、セルを管理する。ＩＡＢノード３００が管理するセルのセルＩＤは、ドナーｇＮＢ２００−１のセルのセルＩＤと同じであってもよいし、異なっていてもよい。

ＩＡＢノード３００は、ＵＥ機能（ユーザ機器機能）及びｇＮＢ機能（基地局機能）を有する。ＩＡＢノード３００は、ＵＥ機能を用いて上位ノード（ｇＮＢ２００又は上位のＩＡＢノード３００）との無線通信を行うとともに、ｇＮＢ機能を用いて下位ノード（ＵＥ１００又は下位のＩＡＢノード３００）との無線通信を行う。なお、ＵＥ機能とは、ＵＥ１００が有する機能のうち少なくとも一部の機能を意味し、必ずしもＵＥ１００の全ての機能をＩＡＢノード３００が有していなくてもよい。ｇＮＢ機能とは、ｇＮＢ２００の機能のうち少なくとも一部の機能を意味し、必ずしもｇＮＢ２００の全ての機能をＩＡＢノード３００が有していなくてもよい。

ＵＥ１００と、ＩＡＢノード３００又はｇＮＢ２００との間の無線区間は、アクセスリンク（或いは、Ｕｕ）と称されることがある。ＩＡＢノード３００と、ｇＮＢ２００又は他のＩＡＢノード３００との間の無線区間は、バックホールリンク（或いは、Ｕｎ）と称されることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。

アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び／又は周波数分割により多重化されてもよい。

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

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

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

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

（ＩＡＢノードの構成）
本実施形態に係るＩＡＢノード３００の構成について説明する。図３は、ＩＡＢノード３００の構成を示す図である。図３に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを備える。

無線通信部３１０は、ｇＮＢ２００との無線通信（バックホールリンク）及びＵＥ１００との無線通信（アクセスリンク）に用いられる。無線通信部３１０は、受信部３１１及び送信部３１２を備える。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

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

（ＵＥの構成）
本実施形態に係るＵＥ１００の構成について説明する。図４は、ＵＥ１００の構成を示す図である。図４に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを備える。

無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信に用いられる。無線通信部１１０は、受信部１１１及び送信部１１２を備える。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

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

（プロトコルスタック構成の一例）
本実施形態に係る移動通信システム１におけるプロトコルスタック構成の一例について説明する。図５は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図１に示したＵＥ１００−３と５ＧＣ１０のＵＰＦ１２との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。

図５に示すように、ＵＰＦ１２は、ＧＴＰ−Ｕ（ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｕｓｅｒ Ｐｌａｎｅ）と、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）と、レイヤ１／レイヤ２（Ｌ１／Ｌ２）とを備える。ｇＮＢ２００−１（ドナーｇＮＢ）には、これらに対応するプロトコルスタックが設けられる。

また、ｇＮＢ２００−１は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とを備える。無線インターフェイスのプロトコルスタックのうちＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）以上の各レイヤをＣＵが有し、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）以下の各レイヤをＤＵが有し、Ｆ１インターフェイスと称されるインターフェイスを介してＣＵ及びＤＵが接続される。

具体的には、ＣＵは、ＳＤＡＰ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）と、ＰＤＣＰと、ＩＰと、Ｌ１／Ｌ２とを備える。ＣＵのＳＤＡＰ及びＰＤＣＰは、ＤＵと、ＩＡＢノード３００−１と、ＩＡＢノード３００−２とを介して、ＵＥ１００のＳＤＡＰ及びＰＤＣＰとの通信を行う。

また、ＤＵは、無線インターフェイスのプロトコルスタックのうち、ＲＬＣと、アダプテーションレイヤ（Ａｄａｐｔ）と、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）と、ＰＨＹ（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ）とを有する。これらのプロトコルスタックは、ｇＮＢ向けのプロトコルスタックである。なお、アダプテーションレイヤ及びＲＬＣ（Ｓ−ＲＬＣ）は上下関係が逆であってもよい。

ＩＡＢノード３００−１には、これらに対応するＵＥ向けのプロトコルスタックＳＴ１が設けられる。さらに、ＩＡＢノード３００−１には、ｇＮＢ向けのプロトコルスタックＳＴ２が設けられる。プロトコルスタックＳＴ１及びプロトコルスタックＳＴ２は、何れもレイヤ２以下の各レイヤ（各サブレイヤ）からなる。すなわち、ＩＡＢノード３００−１は、レイヤ２以下の各レイヤを用いてユーザデータの中継を行うレイヤ２中継装置である。ＩＡＢノード３００−１は、レイヤ３以上のレイヤ（具体的には、ＰＤＣＰ以上のレイヤ）を用いることなくデータ中継を行う。なお、ＩＡＢノード３００−２は、ＩＡＢノード３００−１と同様なプロトコルスタック構成を有する。

ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、ｇＮＢ２００−１、ＩＡＢノード３００−１、ＩＡＢノード３００−２、及びＵＥ１００−３のそれぞれは、レイヤ３に相当するＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）を備える。

ｇＮＢ２００−１（ドナーｇＮＢ）のＲＲＣとＩＡＢノード３００−１のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。また、ｇＮＢ２００−１のＲＲＣとＩＡＢノード３００−２のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。さらに、ｇＮＢ２００−１のＲＲＣとＵＥ１００−３のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。

（移動通信システムにおける動作）
本実施形態に係る移動通信システム１における動作について説明する。具体的には、ＩＡＢノード３００−１がｇＮＢ２００−１（ドナーｇＮＢ）に無線で接続する場合の動作について説明する。

かかる場合、最初に、ＩＡＢノード３００−１は、ＵＥ機能を用いてｇＮＢ２００−１とのアクセスリンク接続（第１の無線接続）を確立する。言い換えると、ＩＡＢノード３００−１は、ＵＥ１００として振る舞ってｇＮＢ２００−１とのアクセスリンク接続を確立する。アクセスリンク接続の確立は、ＲＲＣ接続の確立を含む。

次に、ｇＮＢ２００−１は、アクセスリンク接続を維持しつつ、ＩＡＢノード３００−１のｇＮＢ機能のためのバックホールリンク接続（第２の無線接続）をＩＡＢノード３００−１とｇＮＢ２００−１との間に確立させるメッセージをＩＡＢノード３００−１に送信する。本実施形態において、かかるメッセージは、ＲＲＣ接続を用いて送受信されるＲＲＣ再設定（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージである。

その結果、バックホールリンク接続がＩＡＢノード３００−１とｇＮＢ２００−１との間に確立されるため、ＩＡＢノード３００−１とｇＮＢ２００−１との間でバックホールリンクの通信を適切に開始可能とすることができる。

バックホールリンク接続を確立させるＲＲＣ再設定メッセージは、バックホールリンク接続を構成するベアラ（又はＬ２リンク）の設定情報、及びＩＡＢノード３００−１が送信するべきセルＩＤ（具体的には、セルＩＤに関連付けられた参照信号及び同期信号の送信設定）を含んでもよい。以下において、かかるＲＲＣ再設定メッセージをＩＡＢノード設定メッセージと称する。

ＩＡＢノード設定メッセージは、デフォルトベアラ（又はデフォルトリンク）の設定情報を含んでもよい。デフォルトベアラ（又はデフォルトリンク）は、例えば、ＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）の中継やＵＥからのＭｓｇ３中継などを行うためのベアラ（又はリンク）である。

ＩＡＢノード設定メッセージは、ドナーｇＮＢ２００−１側のスタックの設定情報と、オプションでＩＡＢノード３００−２（又はＵＥ１００）側のスタックの設定情報とを含んでもよい。ＩＡＢノード３００−２（又はＵＥ１００）側のスタックの設定情報は、暗示的にドナーｇＮＢ２００−１のＳＩＢで報知されている設定群を再利用してもよいし、オペレータ（ＯＡＭ）から（事前に）設定されてもよい。

ＩＡＢノード設定メッセージにおける設定内容としては、基本的にＲＲＣ再設定メッセージに含まれる設定全てが対象になり得るが、ＲＬＣ設定（ＡＭ：Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ／ＵＭ：Ｕｎａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ／ＴＭ：Ｔｒａｎｓｐａｒｅｎｔ Ｍｏｄｅ等の動作モード、ＬＣＰ（Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ Ｐｒｉｏｒｉｔｉｚａｔｉｏｎ）パラメータ等）、ＭＡＣ設定（ＢＳＲ：Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ／ＴＡＧ：Ｔｉｍｉｎｇ Ａｄｖａｎｃｅ Ｇｒｏｕｐ／ＰＨＲ：Ｐｏｗｅｒ Ｈｅａｄｒｏｏｍパラメータ、ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｅｓ Ｒｅｃｅｐｔｉｏｎ設定等）、ＰＨＹ設定が含まれてもよい。

また、ＩＡＢノード設定メッセージにおける設定内容には、アダプテーションレイヤの設定（下位側又は上位側の論理チャネルのマッピング（ルーティング）設定、優先度設定等）が含まれてもよい。

さらに、ＩＡＢノード設定メッセージにおける設定内容には、必要に応じて、ＩＡＢノード３００−１の（仮想的な）ＩＰアドレス（すなわち、Ｌ３アドレス）を含めてもよい。これは、例えばＦ１インターフェイスをＬ２リンク上に確立するために、Ｆ１のプロトコルスタックがＳＣＴＰ ｏｖｅｒ ＩＰを想定しているためである。

なお、ＩＡＢノード設定メッセージにおける設定内容は、ＮＲプロトコルの設定情報に限らず、ＬＴＥプロトコル（ＲＬＣ、ＭＡＣ、ＰＨＹ）の設定情報であってもよい。

本実施形態において、ＩＡＢノード３００−１は、バックホールリンク接続を確立するよりも前に、ＩＡＢノードの機能（すなわち、レイヤ２中継機能）を有すること又はバックホールリンク接続の確立を要求することを示すインディケーションをｇＮＢ２００−１に送信してもよい。これにより、ｇＮＢ２００−１は、バックホールリンク接続を確立するためのプロシージャを適切に開始できる。以下において、かかるインディケーションをＩＡＢインディケーションと称する。ＩＡＢインディケーションは、ＩＡＢノード３００−１におけるＵＥ機能向けリンクプロトコルスタックをＬＴＥで準備するのか、ＮＲで準備するのか、もしくはその両方か、という意図又は能力を示す情報を含んでもよい。

なお、ＩＡＢノード３００−１は、ｇＮＢ２００−１とのアクセスリンク接続の確立後にＩＡＢインディケーションを送信してもよいし、ｇＮＢ２００−１とのアクセスリンク接続を確立するプロシージャ中にＩＡＢインディケーションを送信してもよい。

また、ＩＡＢインディケーションをｇＮＢに送信可能とする条件として、このｇＮＢから、ドナー機能を有することを示すドナー機能識別子を含むＳＩＢを受信しているという条件があってもよい。かかる場合、ＩＡＢノード３００−１は、ｇＮＢ２００−１からＳＩＢによりドナー機能識別子を受信している場合に限り、ｇＮＢ２００−１に対してＩＡＢインディケーションを送信する。

本実施形態において、ＩＡＢノード３００−１とのバックホールリンク接続を確立するドナー機能をｇＮＢ２００−１が有する場合がある。この場合、ｇＮＢ２００−１は、ＩＡＢノード３００−１からＩＡＢインディケーションを受信した後、ＩＡＢノード設定メッセージをＩＡＢノード３００−１に送信する。一方、ドナー機能をｇＮＢ２００−１が有しない場合、ｇＮＢ２００−１は、ＩＡＢノード３００−１からＩＡＢインディケーションを受信した後、ＩＡＢノード設定メッセージをＩＡＢノード３００−１に送信することに代えて、ＩＡＢノード３００−１のハンドオーバを要求するハンドオーバ要求を他のｇＮＢに送信してもよい。ここで、ｇＮＢ２００−１は、ドナー機能を有する他のｇＮＢの情報を予め記憶していることが好ましい。ｇＮＢ２００−１は、ドナー機能を有する他のｇＮＢの情報をＩＡＢノード３００−１から取得してもよい。ＩＡＢノード３００−１は、５ＧＣ１０（コアネットワーク）から情報を入手、もしくは隣接セルのＳＩＢ（ドナー機能識別子）を確認する。これにより、ドナー機能を有する他のｇＮＢ（隣接セル）の情報を取得し、取得した情報をｇＮＢ２００−１に通知する。ｇＮＢ２００−１は、記憶している情報又はＩＡＢノード３００−１から取得した情報に基づいて、ドナー機能を有する他のｇＮＢに対してハンドオーバ要求を送信する。これにより、ＩＡＢノード３００−１を他のｇＮＢにハンドオーバさせた後に、ＩＡＢノード３００−１が当該他のｇＮＢとのバックホールリンク接続を確立できる。或いは、ドナー機能をｇＮＢ２００−１が有しない場合、ＩＡＢノード３００−１は、５ＧＣ１０に対して、ドナー機能を有するセル（ｇＮＢ）へハンドオーバさせることを要求し、５ＧＣ１０がハンドオーバに係る処理を行ってもよい。

本実施形態において、ｇＮＢ２００−１は、ＩＡＢノード３００−１からＩＡＢインディケーションを受信したことに応じて、無線測定を設定する測定設定をＩＡＢノード３００−１に送信してもよい。ＩＡＢノード３００−１は、ｇＮＢ２００−１から測定設定を受信した後、無線測定の結果を含む測定報告をｇＮＢ２００−１に送信する。ｇＮＢ２００−１は、ＩＡＢノード３００−１からの測定報告に基づいて、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。例えば、ｇＮＢ２００−１は、測定報告に基づいて、自身（ｇＮＢ２００−１）に対する測定結果よりも他のｇＮＢに対する測定結果が良好であり、かつ、これらの測定報告の差が閾値よりも大きい場合に、他のｇＮＢが適切なドナーｇＮＢであると判断する。そうでなければ、ｇＮＢ２００−１は、自身が適切なドナーｇＮＢであると判断する。

そして、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢ２００−１であると判断した場合、ｇＮＢ２００−１は、ＩＡＢノード設定メッセージをＩＡＢノード３００−１に送信する。一方、他のｇＮＢが適切なドナーｇＮＢであると判断した場合、ｇＮＢ２００−１は、ＩＡＢノード設定メッセージをＩＡＢノード３００−１に送信することに代えて、ＩＡＢノード３００−１のハンドオーバを要求するハンドオーバ要求を当該他のｇＮＢに送信する。これにより、ＩＡＢノード３００−１をより無線状態の良好な他のｇＮＢにハンドオーバさせて、ＩＡＢノード３００−１が当該他のｇＮＢとのバックホールリンク接続を確立できる。

本実施形態において、ｇＮＢ２００−１は、バックホールリンク接続の確立後、ＩＡＢノード３００−１に関するコンテキスト情報を他のｇＮＢに送信してもよい。このコンテキスト情報は、無線側のＡＳレイヤの接続設定（ＲＲＣ再設定の内容）、ネットワーク側のＰＤＵセッションリソース設定（ＡＭＦ又はＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）のＵＥ ＩＤ、セッションＩＤ、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）／スライス設定等）、その他関連情報（ＩＡＢノードの挙動や通信などの履歴情報、及び／又はプリファレンス情報）などを含む。

具体的には、ｇＮＢ２００−１は、ＩＡＢノード３００−１を他のｇＮＢにハンドオーバさせるという判断を行っていなくても、ＩＡＢノード３００−１に関するコンテキスト情報を予め他のｇＮＢに送信する。これにより、ｇＮＢ２００−１とＩＡＢノード３００−１との間の無線状態が悪化し、ＩＡＢノード３００−１が他のｇＮＢとの無線接続を再確立する場合に、予め共有したコンテキスト情報を用いて速やかな再確立を行うことができる。

ここで、ｇＮＢ２００−１は、ＩＡＢノード３００−１とＩＡＢノード３００−１のドナーｇＮＢの候補とを対応付けるテーブルを保持していることが好ましい。ｇＮＢ２００−１は、テーブル中の候補である他のｇＮＢに対してコンテキスト情報を送信する。これにより、ｇＮＢ２００−１は、コンテキスト情報を適切な他のｇＮＢと共有できる。

（１）通常動作シーケンスの一例
図６は、本実施形態に係る移動通信システム１における通常動作シーケンスの一例を示す図である。

図６に示すように、ステップＳ１０１において、ＩＡＢノード３００−１は、例えばｇＮＢ２００−１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００−１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００−１は、ランダムアクセスプロシージャ中にｇＮＢ２００−１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００−１は、ステップＳ１０１において、ＩＡＢノード３００−１に関するコンテキスト情報を取得する。

ステップＳ１０２において、ＩＡＢノード３００−１は、ｇＮＢ２００−１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。ここで、ＩＡＢノード３００−１は、ＩＡＢインディケーションのような通知（つまり、ＩＡＢノードとして動作したいことを示す通知）をＡＭＦ１１に通知してもよい。これにより、ＩＡＢノード３００−１は、ＡＭＦ１１から、ドナーｇＮＢ（セル）の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、ＡＭＦ１１からドナーｇＮＢの各候補に対して、ＩＡＢノード３００−１のアタッチがあった旨や、ＩＡＢノード３００−１のルーティング情報などのコンテキスト情報を通知してもよい。なお、ＩＡＢノード３００−１が既にアタッチしている場合は、ステップＳ１０２におけるアタッチ処理を省略可能である。具体的には、ＩＡＢノード３００−１は、ステップＳ１０１において、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）などのように、何らかのエラー発生によってドナーｇＮＢとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。

ステップＳ１０３において、ＩＡＢノード３００−１は、ＩＡＢインディケーションをｇＮＢ２００−１に送信する。ＩＡＢノード３００−１は、次のイベントのうち１又は複数が満たされたことをトリガとしてＩＡＢインディケーションを送信してもよい。

・Ｍｓｇ５（ＲＲＣ Ｃｏｍｐｌｅｔｅ）を送信する際。

・ｇＮＢとの接続が確立した際（Ｍｓｇ５以降でもよい。例えば最初のＲＲＣ再設定が行われた際）。

・ＡＭＦからＩＡＢ設定情報（上記参照）を入手した際（既にＩＡＢ設定情報を持っている場合も含む）。

・単純にＩＡＢノードとして動作したくなった際（上位レイヤからＩＡＢノードとして動作する指示を受信したことを含む）。

・下位のＩＡＢノード３００−２又はＵＥ１００−３からＩＡＢノードとなるように要求された場合（その旨の要求を示す信号を下位のＩＡＢノード３００−２又はＵＥ１００−３から受信した場合）。

・下位のＩＡＢノード３００−２又はＵＥ１００−３が既に接続している場合。

ＩＡＢノード３００−１は、例えばｇＮＢ２００−１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥとしての能力を示す「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ１０１においてＩＡＢインディケーションを送信している場合、ステップＳ１０３は省略可能である。

或いは、ＩＡＢインディケーションは、ＡＭＦ１１からＰＤＵセッションリソースの変更という形でｇＮＢ２００−１に通知されてもよい。なお、ＡＭＦは、ＩＡＢ管理用（専用）のＡＭＦであってもよい。

本通常動作シーケンスにおいては、ｇＮＢ２００−１がドナー能力を有すると仮定して説明を進める。ｇＮＢ２００−１は、ＩＡＢインディケーションに基づいて、バックホールリンク接続をＩＡＢノード３００−１に確立させる必要があると判断する。

ステップＳ１０４において、ｇＮＢ２００−１は、無線測定を設定する測定設定をＩＡＢノード３００−１に送信する。ＩＡＢノード３００−１は、測定設定に基づいて無線測定を行う。例えば、ＩＡＢノード３００−１は、現在のサービングセルであるｇＮＢ２００−１のセルと、隣接セルであるｇＮＢ２００−２のセルとに対して受信電力（セル固有参照信号の受信電力）の測定を行う。

ステップＳ１０５において、ＩＡＢノード３００−１は、無線測定の結果を含む測定報告をｇＮＢ２００−１に送信する。ｇＮＢ２００−１は、測定報告に基づいて、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。ここでは、ｇＮＢ２００−１が、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであると判断したと仮定して説明を進める。なお、ステップＳ１０４及びステップＳ１０５の処理は必須ではなく、省略してもよい。

ステップＳ１０６において、ｇＮＢ２００−１は、ＩＡＢノード設定メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００−１に送信する。ＩＡＢノード設定メッセージは、ｇＮＢ２００−１のセル（すなわち、ＩＡＢノード３００−１の現在のサービングセル）をハンドオーバ先として指定するハンドオーバ指示を含んでもよい。ＩＡＢノード３００−１は、ＩＡＢノード設定メッセージに基づいて、バックホールリンク接続をｇＮＢ２００−１と確立する処理を行う。かかる確立処理は、ＩＡＢノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック（アダプテーション／ＲＬＣ／ＭＡＣ／ＰＨＹエンティティ）を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、ＵＥ側（のアクセスリンク用）のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理（もしくは、開始する準備をする処理）を含んでもよい。

ステップＳ１０７において、ＩＡＢノード３００−１は、バックホールリンク接続の確立を含むＩＡＢノード設定が完了したことを示す完了通知メッセージをｇＮＢ２００−１に送信する。ステップＳ１０７以降は、ＩＡＢノード３００−１はｇＮＢ２００−１に対してＵＥとして振る舞うのではなく、ＩＡＢノードとして振る舞う。

ステップＳ１０８において、ｇＮＢ２００−１は、ステップＳ１０１において取得したコンテキスト情報を、Ｘｎインターフェイス上でｇＮＢ２００−２に転送する。ｇＮＢ２００−１は、ＩＡＢノード３００−１とＩＡＢノード３００−１のドナーｇＮＢの候補とを対応付けるテーブルを保持しており、このテーブルを参照してコンテキスト転送先を決定する。このようにして、ｇＮＢ２００−１が、他のｇＮＢに対してコンテキストを事前に転送しておけば、ＩＡＢノード３００−１と接続しているｇＮＢとの無線接続状態が悪化した場合に、直ぐに、当該他のｇＮＢとの再接続を確立することができる。図７は、コンテキスト転送先を決定するためのテーブルの一例を示す図である。かかるテーブルは、例えばオペレータにより各ｇＮＢに対して予め設定される。図７に示すように、テーブルにおいて、ＩＡＢノードごとに、そのドナーｇＮＢの候補が対応けられている。具体的には、ＩＡＢノードに関する識別子ごとに、そのドナーｇＮＢの候補の識別子が対応けられている。例えば、ＩＡＢノードに地理的に近いｇＮＢがそのＩＡＢノードのドナーｇＮＢの候補として設定される。なお、図７のテーブルは、ｇＮＢとの対応付けの例を示したが、セルＩＤとの対応付けであってもよい。セルＩＤは、物理レイヤセルＩＤでもよく、グローバルセルＩＤでもよい。なお、ｇＮＢ２００−１は、ＩＡＢノード３００−１から受信した測定報告に基づいて、ＩＡＢノード３００−１に地理的に近いｇＮＢ２００−１をドナー候補として決定してもよい。ｇＮＢ２００−１は、当該決定したドナー候補に基づいて、ＩＡＢノード３００−１と当該ＩＡＢノード３００−１のドナーｇＮＢの候補とを対応付けるテーブルを作成又は既存のテーブルを更新してもよい。

ステップＳ１０９において、ｇＮＢ２００−１は、ＩＡＢノード３００−１とのバックホールリンク接続を確立したことを示す通知を５ＧＣ１０に送信する。もしくは、ｇＮＢ２００−１は、ＩＡＢノード用のＰＤＵセッションの確立要求を５ＧＣ１０に送信してもよい。なお、上述したように、ＰＤＵセッションの確立要求は、ステップＳ１０９よりも先に又はステップＳ１０９においてＡＭＦ１１からｇＮＢ２００−１に送信されてもよい。

（２）例外動作シーケンスの一例
図８は、本実施形態に係る移動通信システム１における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、ｇＮＢ２００−１は、ＩＡＢノード３００−１をｇＮＢ２００−２にハンドオーバさせる。

図８に示すように、ステップＳ２０１において、ＩＡＢノード３００−１は、例えばｇＮＢ２００−１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００−１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００−１は、ランダムアクセスプロシージャ中にｇＮＢ２００−１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００−１は、ステップＳ２０１において、ＩＡＢノード３００−１に関するコンテキスト情報を取得する。

ステップＳ２０２において、ＩＡＢノード３００−１は、ｇＮＢ２００−１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。

ステップＳ２０３において、ＩＡＢノード３００−１は、ＩＡＢインディケーションをｇＮＢ２００−１に送信する。ＩＡＢノード３００−１は、例えばｇＮＢ２００−１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥの能力を示す「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ２０１においてＩＡＢインディケーションを送信している場合、ステップＳ２０３は省略可能である。

ステップＳ２０４において、ｇＮＢ２００−１は、自身がドナー能力を有するか否かを判断する。ｇＮＢ２００−１がドナー能力を有しない場合（ステップＳ２０４：ＮＯ）、ｇＮＢ２００−１は、処理をステップＳ２０８に進める。

ｇＮＢ２００−１がドナー能力を有する場合（ステップＳ２０４：ＹＥＳ）、ステップＳ２０５において、ｇＮＢ２００−１は、無線測定を設定する測定設定をＩＡＢノード３００−１に送信する。ＩＡＢノード３００−１は、測定設定に基づいて無線測定を行う。例えば、ＩＡＢノード３００−１は、現在のサービングセルであるｇＮＢ２００−１のセルと、隣接セルであるｇＮＢ２００−２のセルとに対して受信電力（セル固有参照信号の受信電力）の測定を行う。

ステップＳ２０６において、ＩＡＢノード３００−１は、無線測定の結果を含む測定報告をｇＮＢ２００−１に送信する。

ステップＳ２０７において、ｇＮＢ２００−１は、測定報告に基づいて、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであると判断した場合（ステップＳ２０７：ＹＥＳ）、ｇＮＢ２００−１は、上述した通常動作シーケンス（図６参照）のステップＳ１０６に処理を進める。

一方、他のｇＮＢが適切なドナーｇＮＢであると判断した場合（ステップＳ２０７：ＮＯ）、ｇＮＢ２００−１は、ステップＳ２０８に処理を進める。

ステップＳ２０８において、ｇＮＢ２００−１は、ＩＡＢノード３００−１から受信したＩＡＢインディケーションを含むハンドオーバ要求メッセージをＸｎインターフェイス上でｇＮＢ２００−２に転送する。ｇＮＢ２００−１は、ステップＳ２０１において取得したコンテキスト情報をハンドオーバ要求メッセージに含めてもよい。又は、ｇＮＢ２００−１は、ハンドオーバ要求メッセージに、ＩＡＢインディケーションを含める代わりに、ＩＡＢノード３００−１がｇＮＢに対してドナーｇＮＢとして機能することを要求する旨を示す情報を含めて送信してもよい。なお、ステップＳ２０８において、ｇＮＢ２００−１は、ｇＮＢ２００−２がドナー能力を有すると判断した上で、ハンドオーバ要求メッセージをＸｎインターフェイス上でｇＮＢ２００−２に転送してもよい。具体的には、例えば、ｇＮＢ２００−１は、図７に示すテーブルにおいて、ＩＡＢノード３００−１にドナー候補としてｇＮＢ２００−２が対応付けられていると判断した場合に、ハンドオーバ要求メッセージをｇＮＢ２００−２に対して転送してもよい。この場合、ｇＮＢ２００−２がハンドオーバ要求を拒否する可能性が低減されるため、ＩＡＢノード３００−１のハンドオーバをより早急に実行することができる。又は、互いに隣接する複数のｇＮＢ２００間でＸｎインターフェイスを介して、自身のドナー能力に関する情報を事前に共有してもよい。これによって、ｇＮＢ２００−１は、ドナー能力を有する隣接のｇＮＢ２００を特定することができ、当該特定した隣接のｇＮＢ２００に対してハンドオーバ要求メッセージを転送することができる。

ｇＮＢ２００−２は、ハンドオーバ要求メッセージに含まれるＩＡＢインディケーションも考慮して、ＩＡＢノード３００−１のハンドオーバを受け入れるか否かを判断する。ｇＮＢ２００−２は、自身がドナー能力を有しない場合には、ハンドオーバ要求を拒否してもよい。ここではｇＮＢ２００−２がＩＡＢノード３００−１のハンドオーバを受け入れると判断したと仮定して説明を進める。

ステップＳ２０９において、ｇＮＢ２００−２は、ハンドオーバ肯定応答メッセージをＸｎインターフェイス上でｇＮＢ２００−１に送信する。

ステップＳ２１０において、ｇＮＢ２００−１は、ｇＮＢ２００−２からのハンドオーバ肯定応答メッセージに基づいて、ハンドオーバ指示メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００−１に送信する。ハンドオーバ指示メッセージは、ハンドオーバ先のｇＮＢ２００−２（のセル）を指定する情報を含む。

ステップＳ２１１において、ＩＡＢノード３００−１は、ｇＮＢ２００からのハンドオーバ指示メッセージに基づいて、ｇＮＢ２００−２へのハンドオーバを行う。

（３）マルチホップ接続シーケンスの一例
図９は、本実施形態に係る移動通信システム１におけるマルチホップ接続シーケンスの一例を示す図である。マルチホップ接続シーケンスは、ＩＡＢノード３００−１とｇＮＢ２００−１との間にバックホールリンク接続が確立された後において、ＩＡＢノード３００−１にＩＡＢノード３００−２又はＵＥ１００−２が接続する場合のシーケンスである。ここではＩＡＢノード３００−１にＩＡＢノード３００−２が接続する場合について主として説明するが、ＩＡＢノード３００−２をＵＥ１００−２と適宜読み替えてもよい。また、上述した「（１）通常動作シーケンス」と重複する説明を省略する。

図９に示すように、ステップＳ３０１において、ＩＡＢノード３００−２は、ＩＡＢノード３００−１を介してｇＮＢ２００−１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００−１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００−２は、ランダムアクセスプロシージャ中にｇＮＢ２００−１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００−１は、ステップＳ３０１において、ＩＡＢノード３００−２に関するコンテキスト情報を取得する。

ステップＳ３０２において、ＩＡＢノード３００−２は、ＩＡＢノード３００−２及びｇＮＢ２００−１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。ここで、ＩＡＢノード３００−２は、ＩＡＢインディケーションのような通知（つまり、ＩＡＢノードとして動作したいことを示す通知）をＡＭＦ１１に通知してもよい。これにより、ＩＡＢノード３００−２は、ＡＭＦ１１から、ドナーｇＮＢ（セル）の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、ＡＭＦ１１からドナーｇＮＢの各候補に対して、ＩＡＢノード３００−２のアタッチがあった旨や、ＩＡＢノード３００−２のルーティング情報などのコンテキスト情報を通知してもよい。なお、ＩＡＢノード３００−２が既にアタッチしている場合は、ステップＳ３０２におけるアタッチ処理を省略可能である。具体的には、ＩＡＢノード３００−２は、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）などのように、何らかのエラー発生によってドナーｇＮＢとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。

ステップＳ３０３において、ＩＡＢノード３００−２は、ＩＡＢノード３００−１を介してＩＡＢインディケーションをｇＮＢ２００−１に送信する。ＩＡＢノード３００−２は、上述した「（１）通常動作シーケンス」のステップＳ１０３において説明したトリガと同様なトリガに応じてＩＡＢインディケーションを送信してもよい。

ＩＡＢノード３００−２は、例えばｇＮＢ２００−１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥとしての能力を示す「ＵＥ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ３０１においてＩＡＢインディケーションを送信している場合、ステップＳ３０３は省略可能である。

或いは、ＩＡＢインディケーションは、ＡＭＦ１１からＰＤＵセッションリソースの変更という形でｇＮＢ２００−１に通知されてもよい。なお、ＡＭＦは、ＩＡＢ管理用（専用）のＡＭＦであってもよい。

本動作シーケンスにおいては、ｇＮＢ２００−１がドナー能力を有すると仮定している。そのため、ｇＮＢ２００−１は、ＩＡＢインディケーションに基づいて、バックホールリンク接続をＩＡＢノード３００−１とＩＡＢノード３００−２との間に確立させる必要があると判断する。

ステップＳ３０４において、ｇＮＢ２００−１は、無線測定を設定する測定設定をＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２は、測定設定に基づいて無線測定を行う。

ステップＳ３０５において、ＩＡＢノード３００−２は、無線測定の結果を含む測定報告を、ＩＡＢノード３００−１を介してｇＮＢ２００−１に送信する。ｇＮＢ２００−１は、測定報告に基づいて、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。ここでは、ｇＮＢ２００−１が、自身（ｇＮＢ２００−１）が適切なドナーｇＮＢであると判断したと仮定して説明を進める。なお、ステップＳ３０４及びステップＳ３０５の処理は必須ではなく、省略してもよい。

ステップＳ３０６において、ｇＮＢ２００−１は、ＩＡＢノード設定メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２は、ＩＡＢノード設定メッセージに基づいて、バックホールリンク接続をＩＡＢノード３００−１と確立する処理を行う。かかる確立処理は、ＩＡＢノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック（アダプテーション／ＲＬＣ／ＭＡＣ／ＰＨＹエンティティ）を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、ＵＥ側（のアクセスリンク用）のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理（もしくは、開始する準備をする処理）を含んでもよい。

ステップＳ３０７において、ｇＮＢ２００−１は、ＲＲＣ再設定メッセージをＩＡＢノード３００−１に送信する。かかるＲＲＣ再設定メッセージは、ＩＡＢノード３００−２の追加に伴ってＩＡＢノード３００−１における設定を変更するためのメッセージである。かかるＲＲＣ再設定メッセージは、例えば、ＩＡＢノード３００−２の論理チャネルとＩＡＢノード３００−１のバックホールリンクの論理チャネルとの対応付けを示すマッピング情報を含む。なお、ステップＳ３０７は、ステップＳ３０６の前であってもよいし、ステップＳ３０６と同時であってもよい。

ステップＳ３０８において、ＩＡＢノード３００−２は、ＩＡＢノード３００−１とのバックホールリンク接続の確立を含むＩＡＢノード設定が完了したことを示す完了通知メッセージをｇＮＢ２００−１に送信する。ステップＳ３０８以降は、ＩＡＢノード３００−２はｇＮＢ２００−１に対してＵＥとして振る舞うのではなく、ＩＡＢノードとして振る舞う。

ステップＳ３０９において、ＩＡＢノード３００−１は、ＩＡＢノード３００−２とのバックホールリンク接続の確立に伴う設定変更が完了したことを示す完了通知メッセージをｇＮＢ２００−１に送信する。なお、ステップＳ３０９は、ステップＳ３０８の前であってもよいし、ステップＳ３０８と同時であってもよい。

ステップＳ３１０において、ｇＮＢ２００−１は、ステップＳ３０１において取得したＩＡＢノード３００−２のコンテキスト情報を、Ｘｎインターフェイス上でｇＮＢ２００−２に転送する。

ステップＳ３１１において、ｇＮＢ２００−１は、ＩＡＢノード３００−２のバックホールリンク接続を確立したことを示す通知を５ＧＣ１０に送信する。もしくは、ｇＮＢ２００−１は、ＩＡＢノード３００−２用のＰＤＵセッションの確立要求を５ＧＣ１０に送信してもよい。なお、上述したように、ＰＤＵセッションの確立要求は、ステップＳ３１１よりも先に又はステップＳ３１１においてＡＭＦ１１からｇＮＢ２００−１に送信されてもよい。

［第１実施形態の変更例］
上述した第１実施形態において、ＩＡＢノード３００−１がｇＮＢ２００−１に無線で接続した後に、ｇＮＢ２００−１がドナー能力を有しないことに応じてＩＡＢノード３００−１をハンドオーバさせる一例について説明した。しかしながら、各ｇＮＢ２００は、自身がドナー能力を有するか否かに関する情報をＩＡＢノード３００−１に提供してもよい。これにより、ＩＡＢノード３００−１は、ドナー能力を有するｇＮＢ２００を選択したうえで接続することが可能になる。例えば、ドナー能力を有するｇＮＢ２００は、ドナー能力を有することを示す情報をシステム情報ブロック（ＳＩＢ）に含めてブロードキャストする。ＩＡＢノード３００−１は、かかるＳＩＢに基づいて、接続先とするｇＮＢ２００を選択する。ＩＡＢノード３００−１は、ドナー能力を有するｇＮＢ２００であって、且つ、このｇＮＢ２００からの受信電力が閾値以上である場合に、このｇＮＢ２００を接続先として選択してもよい。又は、ｇＮＢ２００がドナー能力を有しない場合には、ＩＡＢノード３００−１は、ｇＮＢ２００から送信されたＳＩＢを受信したことに応じて、他のｇＮＢ２００を再選択してもよい。その後、他のｇＮＢ２００から送信されたＳＩＢにより当該他のｇＮＢ２００がドナー能力を有することが示される場合には、ＩＡＢノード３００−１は、当該他のｇＮＢ２００を接続先として、ランダムアクセスプロシージャを行うと共にＩＡＢインディケーションを送信してもよい。

或いは、各ｇＮＢ２００は、自身がドナー能力を有することをＳＩＢにより通知することに加えて、又は自身がドナー能力を有することをＳＩＢにより通知することに代えて、自身がＩＡＢノード３００を取り扱う能力を有することをＳＩＢにより通知してもよい。例えば、各ｇＮＢ２００は、自身がＩＡＢノード３００を他のｇＮＢ（ドナーｇＮＢ）にハンドオーバする機能を有することをＳＩＢにより通知してもよい。

上述した第１実施形態において、ＩＡＢノード３００がランダムアクセスプロシージャ中にｇＮＢ２００に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含める一例について説明した。ここで、Ｍｓｇ３は、例えばＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージである。また、ＩＡＢノード３００は、Ｍｓｇ３中のフィールド（情報要素）であるＥｓｔａｂｌｉｓｈｍｅｎｔ ＣａｕｓｅにＩＡＢインディケーションを含めてもよい。

或いは、ＩＡＢノード３００は、ランダムアクセスプロシージャ中にｇＮＢ２００に送信するランダムアクセスプリアンブル（Ｍｓｇ１）を利用して、ＩＡＢインディケーションを通知してもよい。例えば、ＩＡＢインディケーション用のＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）リソースがＳＩＢにより通知される場合、ＩＡＢノード３００は、通知されたＩＡＢインディケーション用のＰＲＡＣＨリソースの中から選択したＰＲＡＣＨリソースを用いてランダムアクセスプリアンブルを送信することにより、ＩＡＢインディケーションを通知してもよい。ここで、ＰＲＡＣＨリソースとは、時間・周波数リソースであってもよいし、信号系列（プリアンブル系列）であってもよい。

或いは、ＩＡＢノード３００は、ランダムアクセスプロシージャ以外のタイミングでＩＡＢインディケーションを通知してもよい。例えば、ＩＡＢノード３００は、ＵＥ Ａｓｓｉｓｔａｎｃｅ Ｉｎｆｏｒｍａｔｉｏｎメッセージ等のＲＲＣメッセージにＩＡＢインディケーションを含めてもよい。

上述した第１実施形態において、ｇＮＢ２００が、無線測定を設定する測定設定をＩＡＢノード３００又はＵＥ１００に送信し、無線測定の結果を含む測定報告を受信する。これにより、自身（ｇＮＢ２００）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを当該測定報告に基づいて判断する一例について説明した。しかしながら、ｇＮＢ２００は、このような初期接続時に測定結果を利用する場合に限らず、ネットワークトポロジの変更やデータ転送経路の変更に測定報告を利用してもよい。

［第２実施形態］
第２実施形態について、上述した第１実施形態との相違点を主として説明する。第２実施形態は、ＡＭ（Ａｃｋｎｏｗｌｅｄｇｅｄ Ｍｏｄｅ）のＲＬＣレイヤにおける自動再送制御（ＡＲＱ：ＡｕｔｏｍａｔｉｃＲｅｐｅａｔ ｒｅＱｕｅｓｔ）に着目した実施形態である。

ＵＥ１００とｇＮＢ（ドナーｇＮＢ）２００との間の通信にＩＡＢノード３００が介在する場合、ＡＲＱを「ｅｎｄ−ｔｏ−ｅｎｄ」で行う方法とＡＲＱを「ｈｏｐ−ｂｙ−ｈｏｐ」で行う方法とがある。なお、本実施形態において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。

図１０は、「ｅｎｄ−ｔｏ−ｅｎｄ」の一例を示す図である。

図１０に示すように、ＡＲＱを「ｅｎｄ−ｔｏ−ｅｎｄ」で行う場合、ＵＥ１００の送信側ＲＬＣエンティティ１２は、ＩＡＢノード３００を介して上りリンクデータをｇＮＢ２００の受信側ＲＬＣエンティティ３２に送信するとともに、当該上りリンクデータを保持する。この上りリンクデータが伝送中に消失すると、当該上りリンクデータを受信失敗したことを示すＮａｃｋ（ｎｅｇａｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をｇＮＢ２００の受信側ＲＬＣエンティティ３２がＩＡＢノード３００を介してＵＥ１００の送信側ＲＬＣエンティティ１２に送信する。ＵＥ１００の送信側ＲＬＣエンティティ１２は、Ｎａｃｋの受信に応じて、保持している上りリンクデータを再送する。

一方、ｇＮＢ２００の受信側ＲＬＣエンティティ３２が上りリンクデータの受信に成功すると、当該上りリンクデータを受信成功したことを示すＡｃｋ（ｐｏｓｉｔｉｖｅ ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をｇＮＢ２００の受信側ＲＬＣエンティティ３２がＩＡＢノード３００を介してＵＥ１００の送信側ＲＬＣエンティティ１２に送信する。但し、ｇＮＢ２００の受信側ＲＬＣエンティティ３２は、ＵＥ１００の送信側ＲＬＣエンティティ１２からの要求（Ｓｔａｔｕｓ ＰＤＵ）に応じてＡｃｋを送信してもよい。具体的には、Ａｃｋは、複数ＰＤＵ分をまとめて送ることができるため、受信成功したら直ぐにＡｃｋを返す訳ではない。ＵＥ１００の送信側ＲＬＣエンティティ１２は、Ａｃｋの受信に応じて、保持している上りリンクデータを破棄するとともに、ＵＥ１００のＰＤＣＰエンティティ１３にデータ送信成功を通知する。なお、Ａｃｋは、１つのＰＤＵの受信に成功するごとに返してもよい。

なお、ＲＬＣエンティティが送信するデータは「ＲＬＣ ｄａｔａ ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）」と称され、特にＡＭのＲＬＣエンティティが送信するデータは「ＡＭＤ（ＡＭ Ｄａｔａ） ＰＤＵ」と称される。また、ＡＭＤ ＰＤＵの送信側は「ｔｒａｎｓｍｉｔｔｉｎｇ ＡＭ ＲＬＣ ｅｎｔｉｔｙ」と称され、ＡＭＤ ＰＤＵの受信側は「ｒｅｃｅｉｖｉｎｇ ＡＭ ＲＬＣ ｅｎｔｉｔｙ」と称される。Ａｃｋ及びＮａｃｋは、「ＳＴＡＴＵＳ ＰＤＵ」と称されるＰＤＵに含まれる。「ＳＴＡＴＵＳ ＰＤＵ」は、「ＲＬＣ ｃｏｎｔｒｏｌ ＰＤＵ」の一種である。

このように、ＵＥ１００とｇＮＢ２００との間の通信にＩＡＢノード３００が介在する場合であっても、ＡＲＱを「ｅｎｄ−ｔｏ−ｅｎｄ」で行うことにより、データ転送経路上において消失したデータが再送により受信側に伝達されることを保証できる。

一方で、ＡＲＱを、「ｅｎｄ−ｔｏ−ｅｎｄ」ではなく、「ｈｏｐ−ｂｙ−ｈｏｐ」で行う場合、データ転送経路上でデータが消失すると、消失したデータを再送できないことがある。

図１１は、「ｈｏｐ−ｂｙ−ｈｏｐ」の一例を示す図である。

図１１に示すように、ＵＥ１００とＩＡＢノード３００との間のＡＲＱ＃１と、ＩＡＢノード３００とｇＮＢ２００との間のＡＲＱ＃２とが個別に行われる。先ず、ＵＥ１００の送信側ＲＬＣエンティティ１２がＩＡＢノード３００の受信側ＲＬＣエンティティ２２Ｒに上りリンクデータを送信し、且つ、ＩＡＢノード３００の受信側ＲＬＣエンティティ２２ＲがＵＥ１００の送信側ＲＬＣエンティティ１２にＡｃｋを送信する。この場合、ＵＥ１００の送信側ＲＬＣエンティティ１２は当該上りリンクデータについて送信成功と判断する。ＵＥ１００のＰＤＣＰエンティティ１３は、送信側ＲＬＣエンティティ１２が送信成功と判断した上りリンクデータについては、ＰＤＣＰ Ｄａｔａ Ｒｅｃｏｖｅｒｙ処理における再送対象から外す（破棄してもよい）。

次に、ＩＡＢノード３００の送信側ＲＬＣエンティティ２２ＴがｇＮＢ２００の受信側ＲＬＣエンティティ３２に当該上りリンクデータを送信する際に当該上りリンクデータが消失する。この場合、ｇＮＢ２００の受信側ＲＬＣエンティティ３２はＮａｃｋをＩＡＢノード３００の送信側ＲＬＣエンティティ２２Ｔに送信し、ＩＡＢノード３００の送信側ＲＬＣエンティティ２２Ｔは当該上りリンクデータを再送する。ＩＡＢノード３００とｇＮＢ２００との間のＡＲＱ＃２においてデータを回復できない場合、ｇＮＢ２００のＰＤＣＰエンティティ３４は、ＰＤＣＰレイヤの再送の仕組みであるＰＤＣＰ Ｄａｔａ Ｒｅｃｏｖｅｒｙを利用して、ＵＥ１００のＰＤＣＰエンティティ１３に再送を要求する。しかしながら、ＵＥ１００のＰＤＣＰエンティティ１３は、ＩＡＢノード３００へのデータ送信成功と判断しているため、ＰＤＣＰレイヤにおける再送が行われない虞がある。

このような「ｈｏｐ−ｂｙ−ｈｏｐ」における問題を解決するために、本実施形態に係るＩＡＢノード３００は次のような動作を行う。図１１に示すように、ＩＡＢノード３００は、第１の通信装置から上りリンクデータを受信する受信側ＲＬＣエンティティ２２Ｒと、受信側ＲＬＣエンティティ２２Ｒが受信した上りリンクデータを第２の通信装置に送信する送信側ＲＬＣエンティティ２２Ｔとを有する。図１１の例において第１の通信装置がＵＥ１００であるが、第１の通信装置は、ＵＥ１００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。また、図１１の例において第２の通信装置がｇＮＢ２００であるが、第２の通信装置は、ｇＮＢ２００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。

送信側ＲＬＣエンティティ２２Ｔは、送信された上りリンクデータを第２の通信装置が受信成功したことを示す第１の肯定応答（Ａｃｋ）を第２の通信装置から受信する。受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信したことに応じて、当該上りリンクデータを受信側ＲＬＣエンティティ２２Ｒが受信成功したことを示す第２の肯定応答（Ａｃｋ）を第１の通信装置に送信する。すなわち、受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信するまでは、第２の肯定応答（Ａｃｋ）を第１の通信装置に送信しない。

このように、ＩＡＢノード３００において、受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ２２Ｔが上りリンクデータの送信成功を確認するまで、当該上りリンクデータに対応するＡｃｋを第１の通信装置に送信しない。これにより、第１の通信装置は、受信側ＲＬＣエンティティ２２Ｒから当該上りリンクデータに対応するＡｃｋを受信するまで、当該上りリンクデータを保持するため、上述したような「ｈｏｐ−ｂｙ−ｈｏｐ」における問題を解決できる。

ＩＡＢノード３００は、受信側ＲＬＣエンティティ２２Ｒ及び送信側ＲＬＣエンティティ２２Ｔよりも上位のレイヤに位置付けられるアダプテーションレイヤ（Ａｄａｐｔ．）のエンティティ２３を有してもよい。以下において、アダプテーションレイヤのエンティティを「アダプテーションエンティティ」と称する。アダプテーションエンティティ２３は、複数の受信側ＲＬＣエンティティ２２Ｒと複数の送信側ＲＬＣエンティティ２２Ｔとが存在する場合に、受信側ＲＬＣエンティティ２２Ｒと送信側ＲＬＣエンティティ２２Ｔとの対応付けを示すマッピング情報を管理する。アダプテーションエンティティ２３は、論理チャネル（ＬＣＨ）ごとにマッピング情報を管理してもよいし、ＵＥ１００の識別子（例えば、Ｃ−ＲＮＴＩ（Ｃｅｌｌ−Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）等）ごとにマッピング情報を管理してもよい。

アダプテーションエンティティ２３は、第１の肯定応答（Ａｃｋ）に関する情報を送信側ＲＬＣエンティティ２２Ｔから取得し、該取得された情報を受信側ＲＬＣエンティティ２２Ｒに提供する。受信側ＲＬＣエンティティ２２Ｒは、アダプテーションエンティティ２３から提供される情報に基づいて、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信したことを確認する。

例えば、送信側ＲＬＣエンティティ２２Ｔは、第２の通信装置の受信側ＲＬＣエンティティ３２からの送達情報としてＳＴＡＴＵＳ ＰＤＵ（Ａｃｋ／Ｎａｃｋ）をアダプテーションエンティティ２３に通知する。或いは、送信側ＲＬＣエンティティ２２Ｔは、当該ＳＴＡＴＵＳ ＰＤＵに基づくＡｃｋ／Ｎａｃｋ情報を送達情報としてアダプテーションエンティティ２３に通知してもよい。Ａｃｋ／Ｎａｃｋ情報は、送達に成功したシーケンス番号（ＳＮ）を含んでもよいし、送達に失敗したシーケンス番号（ＳＮ）を含んでもよい。アダプテーションエンティティ２３は、送信側ＲＬＣエンティティ２２Ｔからの送達情報を、対応する受信側ＲＬＣエンティティ２２Ｒに転送する。受信側ＲＬＣエンティティ２２Ｒは、アダプテーションエンティティ２３から転送された送達情報を取得し、ＲＬＣ ＰＤＵ（ＡＭＤ ＰＤＵ）の送信成功が確認できた場合に、当該ＲＬＣ ＰＤＵ（ＡＭＤ ＰＤＵ）についてＡｃｋを送信可能な状態になったと判断する。

本実施形態では、ＩＡＢノード３００が、独立したアダプテーションエンティティ２３を有する一例を想定しているが、ＩＡＢノード３００が、独立したアダプテーションエンティティ２３を有していなくてもよい。アダプテーションエンティティ２３の機能は、他のレイヤ（例えば、ＲＬＣ、ＭＡＣ）のエンティティに統合されてもよい。このような場合、受信側ＲＬＣエンティティ２２Ｒと送信側ＲＬＣエンティティ２２Ｔとの間で直接的に送達情報の受け渡しを行ってもよいし、ＲＲＣエンティティ経由で送達情報の受け渡しを行ってもよい。

本実施形態において、受信側ＲＬＣエンティティ２２Ｒは、第１の通信装置からの上りリンクデータを受信してから、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信するまで（又は受信側ＲＬＣエンティティ２２Ｒが、送信側ＲＬＣエンティティ２２Ｔから送達情報を取得するまで若しくはＲＬＣ ＰＤＵ（ＡＭＤ ＰＤＵ）についてＡｃｋを送信可能な状態になったと判断するまで）の待ち時間を計時してもよい。受信側ＲＬＣエンティティ２２Ｒは、当該待ち時間が一定時間を超える場合に、受信側ＲＬＣエンティティ２２Ｒが上りリンクデータの受信に失敗したことを示す否定応答（Ｎａｃｋ）を第１の通信装置に送信してもよい。かかる否定応答（Ｎａｃｋ）に応じて第１の通信装置から再送された上りリンクデータを受信側ＲＬＣエンティティ２２Ｒが受信した場合、送信側ＲＬＣエンティティ２２Ｔは、受信された上りリンクデータによって第２の通信装置に対する再送を試みてもよい。或いは、受信側ＲＬＣエンティティ２２Ｒは、当該待ち時間が一定時間を超える場合に、ＰＤＣＰ Ｄａｔａ ＲｅｃｏｖｅｒｙをトリガすることをＵＥ１００のＰＤＣＰエンティティ１３に要求するためのメッセージを送信してもよい。かかるメッセージは、受信側ＲＬＣエンティティ２２Ｒから上位レイヤ（例えば、アダプテーションエンティティ２３又はＲＲＣエンティティ）に通知され、当該上位レイヤからＵＥ１００に対して送信されてもよい。

例えば、受信側ＲＬＣエンティティ２２Ｒは、第１の通信装置から上りリンクデータ（ＲＬＣ ＰＤＵ）を受信した時に、タイマを起動する。タイマには一定時間が設定され、この一定時間が経過（すなわち、タイマが満了）すると、受信側ＲＬＣエンティティ２２Ｒは、否定応答（Ｎａｃｋ）を第１の通信装置に送信する。受信側ＲＬＣエンティティ２２Ｒは、タイマが動作中（すなわち、タイマが満了する前）に、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を第２の通信装置から受信すると（又は受信側ＲＬＣエンティティ２２Ｒが、送信側ＲＬＣエンティティ２２Ｔから送達情報を取得する若しくはＲＬＣ ＰＤＵ（ＡＭＤ ＰＤＵ）についてＡｃｋを送信可能な状態になったと判断すると）、タイマを停止させる。なお、タイマに設定される一定時間は、ｇＮＢ２００から例えばＲＲＣシグナリングにより指定されてもよいし、予めＩＡＢノード３００に記憶されたものでもよい。また、タイマに設定される一定時間は、他のＩＡＢノード３００から転送されてもよい。受信側ＲＬＣエンティティ２２Ｒは、ｇＮＢ２００からの設定に応じて、タイマ満了時の動作を変更してもよい。例えば、受信側ＲＬＣエンティティ２２Ｒは、タイマ満了時に第２の肯定応答（Ａｃｋ）を第１の通信装置に送信するよう設定されてもよい。

本実施形態において、ＵＥ１００（第１の通信装置）の送信側ＲＬＣエンティティ１２は、Ａｃｋの待ち時間が長くなっても送信失敗と判断しないように、Ａｃｋの最大待ち時間（又はＳＴＡＴＵＳ ＰＤＵの最大待ち時間）を規定するタイマを通常よりも長く設定することが好ましい。例えば、ｇＮＢ２００は、ＲＲＣシグナリングにより、通常よりも長いタイマ値をＵＥ１００（第１の通信装置）の送信側ＲＬＣエンティティ１２に設定してもよい。ＵＥ１００の送信側ＲＬＣエンティティ１２は、当該タイマが動作中は、ＳＴＡＴＵＳ ＰＤＵの送信をＩＡＢノード３００の受信側ＲＬＣエンティティ２２Ｒに要求しないようにする。

図１２は、本実施形態に係る動作例を示すシーケンス図である。

ここでは、図１に示すＵＥ１００−３とｇＮＢ２００−１との間で上りリンクのデータ転送を行う場合を想定する。本動作例において、第２の通信装置は、ＩＡＢノード３００−２とｇＮＢ２００−１（ドナーｇＮＢ）との間の通信に介在するＩＡＢノード３００−１である。

図１２に示すように、ステップＳ１１において、ＵＥ１００−３の送信側ＲＬＣエンティティ１２は、ＰＤＣＰエンティティ１３からのＰＤＣＰ ＰＤＵをＲＬＣ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）として受け取り、ＲＬＣ ＳＤＵからＲＬＣ ＰＤＵを生成し、生成したＲＬＣ ＰＤＵを、ＭＡＣエンティティ１１を介してＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒを介してＲＬＣ ＰＤＵを受信する。

ステップＳ１２において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＲＬＣ ＰＤＵの受信に応じてタイマを起動することにより、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２ＴがＡｃｋを受信するまでの待ち時間を計時する。なお、タイマは、ＲＬＣ ＰＤＵごとに設けられてもよいし、複数のＲＬＣ ＰＤＵからなるグループごとに設けられてもよい。つまり、タイマが複数のＲＬＣ ＰＤＵからなるグループごとに設けられている場合、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、当該複数のＲＬＣ ＰＤＵを受信した場合に、タイマを起動してもよい。その場合、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、後述するステップＳ２１において、当該複数のＲＬＣ ＰＤＵに対応するＡｃｋを送信側ＲＬＣエンティティ２２Ｔが受信した場合に応じて、後述するステップＳ２４において、ＵＥ１００−３に対してＡｃｋを送信してもよい。

ステップＳ１３において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＩＡＢノード３００−２のアダプテーションエンティティ２３を介してＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２ＴにＲＬＣ ＳＤＵを提供する。

ステップＳ１４において、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔは、アダプテーションエンティティ２３から受け取ったＲＬＣ ＳＤＵからＲＬＣ ＰＤＵを生成し、生成したＲＬＣ ＰＤＵを、ＭＡＣエンティティ２１を介してＩＡＢノード３００−１に送信する。ＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒを介してＲＬＣ ＰＤＵを受信する。

ステップＳ１５において、ＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒは、ＲＬＣ ＰＤＵの受信に応じてタイマを起動することにより、ＩＡＢノード３００−１の送信側ＲＬＣエンティティ２２ＴがＡｃｋを受信するまでの待ち時間を計時する。

ステップＳ１６において、ＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒは、ＩＡＢノード３００−１のアダプテーションエンティティ２３を介してＩＡＢノード３００−１の送信側ＲＬＣエンティティ２２ＴにＲＬＣ ＳＤＵを提供する。

ステップＳ１７において、ＩＡＢノード３００−１の送信側ＲＬＣエンティティ２２Ｔは、アダプテーションエンティティ２３から受け取ったＲＬＣ ＳＤＵからＲＬＣ ＰＤＵを生成し、生成したＲＬＣ ＰＤＵを、ＭＡＣエンティティ２１を介してｇＮＢ２００−１に送信する。ｇＮＢ２００−１の受信側ＲＬＣエンティティ３２は、ＭＡＣエンティティ３１を介してＲＬＣ ＰＤＵを受信する。ｇＮＢ２００−１の受信側ＲＬＣエンティティ３２は、受信したＲＬＣ ＰＤＵに対応するＲＬＣ ＳＤＵを、アダプテーションエンティティ３３を介してＰＤＣＰエンティティ３４に提供する。

ステップＳ１８において、ｇＮＢ２００−１の受信側ＲＬＣエンティティ３２は、ステップＳ１７で受信したＲＬＣ ＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳ ＰＤＵを、ＭＡＣエンティティ３１を介してＩＡＢノード３００−１に送信する。このＳＴＡＴＵＳ ＰＤＵには、他のＲＬＣ ＰＤＵに対応するＡｃｋ／Ｎａｃｋも含まれていてもよい。ＩＡＢノード３００−１の送信側ＲＬＣエンティティ２２Ｔは、ＭＡＣエンティティ２１Ｔを介してＳＴＡＴＵＳ ＰＤＵを受信する。

ステップＳ１９において、ＩＡＢノード３００−１の送信側ＲＬＣエンティティ２２Ｔは、受信したＳＴＡＴＵＳ ＰＤＵ又はそれに基づく送達情報を、ＩＡＢノード３００−１のアダプテーションエンティティ２３を介してＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒに提供する。

ステップＳ２０において、ＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒは、送達情報に基づいて、ステップＳ１４で受信したＲＬＣ ＰＤＵに対応するＡｃｋをＩＡＢノード３００−１の送信側ＲＬＣエンティティ２２Ｔが受信したことを確認する。

ステップＳ２１において、ＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒは、ステップＳ１４で受信したＲＬＣ ＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳ ＰＤＵを、ＭＡＣエンティティ２１Ｒを介してＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔは、ＭＡＣエンティティ２１Ｔを介してＳＴＡＴＵＳ ＰＤＵを受信する。

ステップＳ２２において、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔは、受信したＳＴＡＴＵＳ ＰＤＵに基づく送達情報を、ＩＡＢノード３００−２のアダプテーションエンティティ２３を介してＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒに提供する。

ステップＳ２３において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、送達情報に基づいて、ステップＳ１１で受信したＲＬＣ ＰＤＵに対応するＡｃｋをＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔが受信したことを確認する。

ステップＳ２４において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ステップＳ１１で受信したＲＬＣ ＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳ ＰＤＵを、ＭＡＣエンティティ２１Ｒを介してＵＥ１００−３に送信する。ＵＥ１００−３の送信側ＲＬＣエンティティ１２は、ＭＡＣエンティティ１１を介してＳＴＡＴＵＳ ＰＤＵを受信し、ステップＳ１１で送信したＲＬＣ ＰＤＵの送信成功を確認し、その旨をＰＤＣＰエンティティ１３に通知する。

また、上述の実施形態では、ｇＮＢ２００−１や各ＩＡＢノードがＲＬＣ ＰＤＵを正常に受信し、Ａｃｋを含むＳＴＡＴＵＳ ＰＤＵを送信する事例を主に説明したが、ＲＬＣ ＰＤＵを正常に受信しなかった場合を以下に説明する。

ｇＮＢ２００−１又は各ＩＡＢノード３００−１の受信側ＲＬＣエンティティは、Ｎａｃｋを含むＳＴＡＴＵＳ ＰＤＵを各ＩＡＢノード３００−１（３００−２）の送信側ＲＬＣエンティティに送信する。その場合、各ＩＡＢノード３００−１（３００−２）の送信側ＲＬＣエンティティ２２Ｔは、当該ＳＴＡＴＵＳ ＰＤＵを受信したことに応じて、ＲＬＣ ＰＤＵを再送する。その後、各ＩＡＢノード３００−１（３００−２）の送信側ＲＬＣエンティティ２２Ｔは、Ａｃｋを含むＳＴＡＴＵＳ ＰＤＵを受信した場合、上述の実施形態と同様に、受信したＳＴＡＴＵＳ ＰＤＵに基づく送達情報を、各ＩＡＢノード３００−１（３００−２）のアダプテーションエンティティ２３を介してＩＡＢノード３００−１（３００−２）の受信側ＲＬＣエンティティ２２Ｒに提供する。

また、ＩＡＢノード３００−１（３００−２）の送信側ＲＬＣエンティティ２２Ｔは、ＲＬＣ ＰＤＵの再送ができない場合、Ｎａｃｋを含むＳＴＡＴＵＳ ＰＤＵを所定回数受信した場合又はタイマが満了した場合、Ｎａｃｋを含むＳＴＡＴＵＳ ＰＤＵをＩＡＢノード３００−２又はＵＥ１００−３に送信してもよい。

なお、ＩＡＢノード３００−１（３００−２）は、Ｎａｃｋを含むＳＴＡＴＵＳ ＰＤＵをＩＡＢノード３００−２又はＵＥ１００−３に送信することに併せて、タイマを停止してもよい。 図１３は、本実施形態に係る他の動作例を示すシーケンス図である。ここでは、図１２の動作例との相違点について説明する。

図１３に示すように、本動作例において、アダプテーションエンティティ２３はＲＬＣエンティティ２２よりも下位のレイヤに位置付けられている。かかる構成において、アダプテーションエンティティ２３は、例えば、ＱｏＳ制御を行ったり、ＵＥ１００からのＵＬ受信とＩＡＢノードからのＵＬ受信とを区別してひも付けを行ったり、ＭＡＣへの指示を行ったりする。また、ＩＡＢノード３００−１及び３００−２、並びにｇＮＢ２００−１において、ＲＬＣエンティティ２２がＡＲＱ機能（ＲＬＣ ＡＲＱ）とデータ分割・結合機能（ＲＬＣ Ｓｅｇ．）とに分けられている。

図１３に示すように、ステップＳ３１において、ＵＥ１００−３の送信側ＲＬＣエンティティ１２は、ＰＤＣＰエンティティ１３からのＰＤＣＰ ＰＤＵをＲＬＣ ＳＤＵとして受け取り、ＲＬＣ ＳＤＵからＲＬＣ ＰＤＵを生成し、生成したＲＬＣ ＰＤＵを、ＭＡＣエンティティ１１を介してＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒ及びアダプテーションエンティティ２３Ｒを介してＲＬＣ ＰＤＵを受信する。

ステップＳ３２において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＲＬＣ ＰＤＵの受信に応じてタイマを起動することにより、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）２２ＴｂがＡｃｋを受信するまでの待ち時間を計時する。

ステップＳ３３において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）２２ＴｂにステップＳ３２において受信した当該ＲＬＣ ＰＤＵに対応するＲＬＣ ＳＤＵを中継（ｒｅｌａｙ）する。

ステップＳ３４において、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）２２Ｔｂは、受信側ＲＬＣエンティティ２２Ｒから受け取ったＲＬＣ ＳＤＵを、送信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）２２Ｔａ、アダプテーションエンティティ２３Ｔ、及びＭＡＣエンティティ２１Ｔを介してＩＡＢノード３００−１に送信する。ここで、送信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）２２Ｔａは、ＲＬＣ ＳＤＵに対してシーケンス番号の付与及び分割（セグメンテーション）を行う。ＩＡＢノード３００−１の受信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）２２Ｒａは、ＭＡＣエンティティ２１Ｒ及びアダプテーションエンティティ２３Ｒを介してＲＬＣ ＰＤＵを受信し、ＲＬＣ ＰＤＵを送信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）２２Ｔａに中継する。ＩＡＢノード３００−１の送信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）２２Ｔａは、中継されたＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を分割して、アダプテーションエンティティ２３Ｔ及びＭＡＣエンティティ２１Ｔを介してｇＮＢ２００−１に送信する。なお、ＡＲＱの視点では、ＩＡＢノード３００−１は透過的である。ｇＮＢ２００−１の受信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）３２ｂは、ＭＡＣエンティティ３１、アダプテーションエンティティ３３、及び受信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）３２ａを介してＲＬＣ ＰＤＵを受信する。ｇＮＢ２００−１の受信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）３２ｂは、受信したＲＬＣ ＰＤＵに対応するＲＬＣ ＳＤＵをＰＤＣＰエンティティ３４に提供する。

ステップＳ３５において、ｇＮＢ２００−１の受信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）３２ｂは、ステップＳ３４で受信したＲＬＣ ＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳ ＰＤＵを、受信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）３２ａ、アダプテーションエンティティ３３、及びＭＡＣエンティティ３１を介してＩＡＢノード３００−１に送信する。このＳＴＡＴＵＳ ＰＤＵには、他のＲＬＣ ＰＤＵに対応するＮａｃｋも含まれていてもよい。ＳＴＡＴＵＳ ＰＤＵはＩＡＢノード３００−１を介してＩＡＢノード３００−２に伝達される。ＩＡＢノード３００−２の送信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）２２Ｔｂは、ＭＡＣエンティティ２１Ｔ、アダプテーションエンティティ２３Ｔ、及び送信側ＲＬＣエンティティ（ＲＬＣ Ｓｅｇ．）２２Ｔａを介してＳＴＡＴＵＳ ＰＤＵを受信する。

ステップＳ３６において、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）２２Ｔｂは、受信したＳＴＡＴＵＳ ＰＤＵ又はそれに基づく送達情報を、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒに提供する。

ステップＳ３７において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、送達情報に基づいて、ステップＳ３１で受信したＲＬＣ ＰＤＵに対応するＡｃｋをＩＡＢノード３００−２の送信側ＲＬＣエンティティ（ＲＬＣ ＡＲＱ）２２Ｔｂが受信したことを確認する。

ステップＳ３８において、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ステップＳ３１で受信したＲＬＣ ＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳ ＰＤＵを、アダプテーションエンティティ２３Ｒ及びＭＡＣエンティティ２１Ｒを介してＵＥ１００−３に送信する。ＵＥ１００−３の送信側ＲＬＣエンティティ１２は、ＭＡＣエンティティ１１を介してＳＴＡＴＵＳ ＰＤＵを受信し、ステップＳ３１で送信したＲＬＣ ＰＤＵの送信成功を確認し、その旨をＰＤＣＰエンティティ１３に通知する。

なお、図１３の動作例において、ｇＮＢ２００−１は、例えばルーティングテーブルを参照し、ＵＥ１００−３に対してアクセスリンクを提供しているＩＡＢノード３００−２を特定し、ＩＡＢノード３００−２に対して、通常のＡＣＫ／ＮＡＣＫ（ＳＴＡＴＵＳ ＰＤＵ）とは別のＡＣＫ／ＮＡＣＫを送信してもよい。ここで、別のＡＣＫ／ＮＡＣＫとは、複数の（バックホール）ベアラのＡＣＫ／ＮＡＣＫをまとめて１つのメッセージで送信するものであってもよい。その場合、ｇＮＢ２００−１は、ベアラ（又はＲＬＣチャネル）を特定するためのＩＤとＡＣＫ／ＮＡＣＫ情報とを紐づけて（リスト化して）送信してもよい。ｇＮＢ２００−１は、このような別のＡＣＫ／ＮＡＣＫを、ＩＡＢノード３００−２からの要求に応じて送信してもよい。

このように、本実施形態によれば、ＡＲＱを「ｈｏｐ−ｂｙ−ｈｏｐ」で行う場合において、データ転送経路上でデータが消失しても、ＰＤＣＰレイヤにおける再送を行うことが可能である。現状のＰＤＣＰ動作と整合が取れているため、現状のＰＤＣＰ動作に変更を加える必要がない。具体的には、ＵＥ１００の動作変更を最小限にすることで、後方互換性を保つことができる。さらに、各ＩＡＢノード３００が中継先のＡＣＫ受信状況を加味するだけでよいため、複雑性及び処理の増加を防ぐことができる。

［第２実施形態の変更例１］
第２実施形態の変更例１について、上述した第２実施形態との相違点を主として説明する。本変更例は、上述した第２実施形態と併用して実施してもよいし、上述した第２実施形態とは別に実施してもよい。

本変更例において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。

本変更例に係るＩＡＢノード３００は、第１の通信装置から第２の通信装置へデータを中継する場合に、当該データを保持する。第１の通信装置は、ＵＥ１００であってもよいし、ＵＥ１００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。第２の通信装置は、ｇＮＢ２００であってもよいし、ｇＮＢ２００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。ＩＡＢノード３００は、第２の通信装置との無線リンクにおける無線状態の悪化又はデータ転送経路の切り替えに応じて、保持しているデータを第３の通信装置に送信する。

図１４は、本変更例に係る構成例を示す図である。

図１４に示すように、ＩＡＢノード３００−２は、第１の通信装置からデータを受信する受信側ＲＬＣエンティティ２２Ｒと、第２の通信装置と対応付けられた第１の送信側ＲＬＣエンティティ２２Ｔ_１と、第３の通信装置と対応付けられた第２の送信側ＲＬＣエンティティ２２Ｔ_２とを有する。図１４の例において、第１の通信装置はＵＥ１００−３であり、第２の通信装置はＩＡＢノード３００−１であり、第３の通信装置はＩＡＢノード３００−４である。

ＩＡＢノード３００−２は、受信側ＲＬＣエンティティ２２Ｒが受信したデータを第１の送信側ＲＬＣエンティティ２２Ｔ_１に提供するとともに当該データを保持（バッファリング）するアダプテーションエンティティ２３を有する。アダプテーションエンティティ２３は、ＲＬＣエンティティ２２よりも上位のレイヤに位置付けられている。

ＩＡＢノード３００−２のアダプテーションエンティティ２３は、当該ＩＡＢノード３００−２と第２の通信装置（ＩＡＢノード３００−１）との間の無線状態の悪化、又は第２の通信装置（ＩＡＢノード３００−１）から第３の通信装置（ＩＡＢノード３００−４）へのデータ転送経路の切り替えに応じて、保持しているデータを第２の送信側ＲＬＣエンティティ２２Ｔ_２に提供する。ここで、無線状態の悪化とは、第２の通信装置との間で無線リンク障害が発生したこと、第２の通信装置からの無線信号が途絶したこと、又は第２の通信装置からの無線信号の受信レベルが閾値を下回ったことであってもよい。また、データ転送経路の切り替えとは、ハンドオーバによるネットワークトポロジの変更であってもよい。

例えば、アダプテーションエンティティ２３は、１つの送信側ＲＬＣエンティティ２２Ｔ_１に受け渡し済みのＰＤＣＰ ＰＤＵ（ＲＬＣ ＳＤＵ）をバッファリングし、この送信側ＲＬＣエンティティ２２Ｔ_１に紐づいた無線リンクに障害が発生した場合に、当該バッファリングしているＰＤＣＰ ＰＤＵを別の無線リンクに紐づいた送信側ＲＬＣエンティティ２２Ｔ_２に受け渡す。これにより、無線リンク障害が発生した場合でもデータが消失することを防止できる。

具体的には、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、受信側ＲＬＣエンティティ２２ＲからＲＬＣ ＳＤＵを取得し、当該ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）のコピーを作成し、一方のＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を自身のバッファに保存した後、他方のＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を第１の送信側ＲＬＣエンティティ２２Ｔ_１に受け渡す。そして、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、無線リンク異常が発生した場合に、当該保存してあるＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）をバッファから取り出し、無線リンク異常が発生していない第２の送信側ＲＬＣエンティティ２２Ｔ_２に受け渡す。ここで、無線リンク異常は、ＩＡＢノード３００−２のＲＲＣから通知されてもよいし、ｇＮＢ（ドナーｇＮＢ）２００のＲＲＣから通知されてもよい。若しくは、ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２ＲからＲＬＣ ＳＤＵからそのコピーを第２の送信側ＲＬＣエンティティ２２Ｔ_２に受け渡してもよい。また、切替先の送信側ＲＬＣエンティティは、ＩＡＢノード３００−２のＲＲＣから指定されてもよいし、ｇＮＢ（ドナーｇＮＢ）２００のＲＲＣから指定されてもよい。

ＩＡＢノード３００−２のアダプテーションエンティティ２３は、ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を保存する際にタイマを起動し、タイマが満了した際に当該ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を破棄する。或いは、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、ｇＮＢ（ドナーｇＮＢ）２００のアダプテーションエンティティ又は他のＩＡＢノードのアダプテーションエンティティから送達確認情報（Ａｃｋ／Ｎａｃｋ）を取得し、保持しているＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）の送信が成功したと判断した場合に当該ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を破棄してもよい。また、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、当該ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を破棄する際に、当該タイマを停止してもよい。また、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、当該ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を破棄する代わりに、ＰＤＣＰ Ｄａｔａ Ｒｅｃｏｖｅｒｙを利用した再送対象から除外してもよい。

また、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、第２の送信側ＲＬＣエンティティ２２Ｔ_２が、ＳＴＡＴＵＳ ＰＤＵ（Ａｃｋ／Ｎａｃｋ）又は送達確認情報（Ａｃｋ／Ｎａｃｋ）を他のＩＡＢノード３００−４の受信側ＲＬＣエンティティ２２Ｒから受信し、それらの情報を第２の送信側ＲＬＣエンティティ２２Ｔ_２から取得したことに応じて、当該ＲＬＣ ＳＤＵ（ＰＤＣＰ ＰＤＵ）を破棄又はＰＤＣＰ Ｄａｔａ Ｒｅｃｏｖｅｒｙを利用した再送対象から除外してもよい。

なお、図１２〜１４において、各装置（ＵＥ、ＩＡＢノード、ｇＮＢ）のＰＨＹエンティティを省略しているが、実際、各装置は、それぞれＰＨＹエンティティを有し、各ＰＨＹエンティティを介して互いに通信していてもよい。

［第２実施形態の変更例２］
第２実施形態の変更例２について、上述した第２実施形態及びその変更例１との相違点を主として説明する。本変更例は、上述した第２実施形態及びその変更例１と併用して実施してもよいし、上述した第２実施形態及びその変更例１とは別に実施してもよい。

図１５は、第２実施形態の変更例２の想定シナリオを示す図である。

図１５に示すように、ドナーｇＮＢ（ＩＡＢ ｄｏｎｏｒ）２００−１とＵＥ１００−３との間に、ＩＡＢノード３００−１（ＩＡＢ ｎｏｄｅ＃１）及びＩＡＢノード３００−２（ＩＡＢ ｎｏｄｅ＃２）が介在している。ＩＡＢノード３００−１（ＩＡＢ ｎｏｄｅ＃１）及びＩＡＢノード３００−２（ＩＡＢ ｎｏｄｅ＃２）のそれぞれは、ＵＥ１００からドナーｇＮＢ２００−１へ送信される上りリンクデータ（ＵＬ ｄａｔａ）を中継する。

ドナーｇＮＢ２００−１は、上りリンクデータの送達状況を示す送達情報（ＵＬ ｄｅｌｉｖｅｒｙ ｓｔａｔｕｓ）を、ＩＡＢノード３００−１を介して、ＵＥ１００が接続するＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２は、送達確認に基づいて、上りリンクデータをドナーｇＮＢ２００−１が正しく受信したことを確認すると、上りリンクデータに対応するＡＣＫ（ＲＬＣ ＡＣＫ）をＵＥ１００に送信する。

ここで、ＩＡＢノード３００−２は、ＩＡＢノード３００−１に対して上りリンクデータを送信する送信側ＲＬＣエンティティを有しており、この送信側ＲＬＣエンティティは順序制御及び重複制御を行うためにウィンドウ制御を行っている。

ＩＡＢノード３００−２の送信側ＲＬＣエンティティは、新規のＲＬＣ ＰＤＵの送信の度にシーケンス番号（ＳＮ）を付与し、ＳＮを含むＲＬＣ ＰＤＵをＩＡＢノード３００−１の受信側ＲＬＣエンティティに送信する。ＩＡＢノード３００−２の送信側ＲＬＣエンティティは、送信済みのＲＬＣ ＰＤＵをバッファに蓄積しており、受信側からのＳｔａｔｕｓ ｒｅｐｏｒｔ（ＡＣＫ）により送達を確認した後に破棄する。

ここで、ＩＡＢノード３００−２の送信側ＲＬＣエンティティは、ＲＬＣ送信ウィンドウを管理する。ＩＡＢノード３００−２の送信側ＲＬＣエンティティは、ＡＣＫが確認されていないＲＬＣ ＰＤＵを再送しつつ、順次ＲＬＣ送信ウィンドウをスライドさせる。

ＩＡＢノード３００−２の送信側ＲＬＣエンティティは、ＡＣＫを確認できず、ＲＬＣ送信ウィンドウを更新できない場合、新規のＰＤＵを送信することができなくなり、スループットが低下する。このような現象は、Ｔｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇと呼ばれることがある。Ｔｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇを回避するためには、受信側からのＳｔａｔｕｓ ｒｅｐｏｒｔを適切な頻度で受信側からフィードバックする必要がある。

本変更例では、ドナーｇＮＢ２００−１からＩＡＢノード３００−２へ送達情報（ＵＬ ｄｅｌｉｖｅｒｙ ｓｔａｔｕｓ）を送信するために、この送達情報のやり取りを上位エンティティが行うこととする。上位エンティティとは、ＲＬＣエンティティよりも上位のレイヤのエンティティをいう。例えば、上位のレイヤは、アダプテーションレイヤ（Ａｄａｐｔ）であってもよいし、Ｆ１インターフェイスのためのエンティティであるＦ１−ＡＰであってもよい。ＩＡＢノード３００−２とドナーｇＮＢ２００−１とが直接的なやり取りを行うためには、マルチホップのルーティング機能が必要であるところ、ＲＬＣは対面（一対）でのやり取りしかできないため、上位レイヤを利用することとしている。

ここで、ＩＡＢノード３００−２の上位レイヤが送達情報（ＵＬ ｄｅｌｉｖｅｒｙ ｓｔａｔｕｓ）をやり取りし、且つ、ＩＡＢノード３００−２の送信側ＲＬＣエンティティがＲＬＣ送信ウィンドウを管理する場合、ＩＡＢノード３００−２において上位レイヤと送信側ＲＬＣエンティティとの間の適切な協調が必要である。

図１６は、本変更例に係る動作を示す図である。図１６に示すプロトコルスタックの構成は、図１２に示すプロトコルスタックの構成と同様である。なお、図１６において上位レイヤがアダプテーションレイヤ（アダプテーションエンティティ）である一例を示しているが、上位レイヤはＦ１−ＡＰ（Ｆ１−ＡＰエンティティ）であってもよい。

図１６に示すように、ステップＳ５１において、ＵＥ１００−３の送信側ＲＬＣエンティティ１２は、ＰＤＣＰエンティティ１３からの上りリンクデータ（ＰＤＣＰ ＰＤＵ）をＲＬＣ ＳＤＵとして受け取り、ＲＬＣ ＳＤＵからＲＬＣ ＰＤＵを生成し、生成したＲＬＣ ＰＤＵを、ＭＡＣエンティティ１１を介してＩＡＢノード３００−２に送信する。ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒを介してＲＬＣ ＰＤＵを受信する。

ＩＡＢノード３００−２の受信側ＲＬＣエンティティ２２Ｒは、ＩＡＢノード３００−２のアダプテーションエンティティ２３を介して、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２ＴにＲＬＣ ＳＤＵを提供する。ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔは、アダプテーションエンティティ２３から受け取ったＲＬＣ ＳＤＵからＲＬＣ ＰＤＵを生成し、生成したＲＬＣ ＰＤＵを、ＭＡＣエンティティ２１を介してＩＡＢノード３００−１に送信する。ＩＡＢノード３００−１の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒを介してＲＬＣ ＰＤＵを受信する。

ＩＡＢノード３００−１は、ＩＡＢノード３００−２が行う動作と同様の動作を行い、ＲＬＣ ＰＤＵをドナーｇＮＢ２００−１に送信する。

ドナーｇＮＢ２００−１は、ＭＡＣエンティティ３１、ＲＬＣエンティティ３２、アダプテーションエンティティ３３、及びＰＤＣＰエンティティの順に上りリンクデータを処理する。

ステップＳ５２において、ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔは、自身のＲＬＣ送信ウィンドウのｓｔａｌｌｉｎｇが発生しないように、アダプテーションエンティティ２３に対して上りリンクデータの送達確認要求を行う。

具体的には、送信側ＲＬＣエンティティ２２Ｔは、ＡＣＫが確認できていない最も古いシーケンス番号が、ＲＬＣ送信ウィンドウに対応するシーケンス番号の範囲（下限値）に達する前に、アダプテーションエンティティ２３に対して上りリンクデータの送達確認要求を行う。送信側ＲＬＣエンティティ２２Ｔは、送達確認の対象となるシーケンス番号を送達確認要求に含めてもよい。このシーケンス番号は、送信側ＲＬＣエンティティ２２Ｔが付与するＲＬＣシーケンス番号であってもよいし、アダプテーションエンティティ２３が付与するシーケンス番号（パケット識別番号）であってもよい。

ステップＳ５３において、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、送信側ＲＬＣエンティティ２２Ｔからの要求（ステップＳ５２）に応じて、ドナーｇＮＢ２００のアダプテーションエンティティ３３に対して、上りリンクデータに対応する送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）の送信を要求する送信要求（ＵＬ ｓｔａｔｕｓ ｒｅｑｕｅｓｔ）を送信する。

ＩＡＢノード３００−２のアダプテーションエンティティ２３は、送信要求（ＵＬ ｓｔａｔｕｓ ｒｅｑｕｅｓｔ）に、送達確認の対象となるシーケンス番号を含めてもよい。このシーケンス番号は、送信側ＲＬＣエンティティ２２Ｔが付与するＲＬＣシーケンス番号であってもよいし、アダプテーションエンティティ２３が付与するシーケンス番号（パケット識別番号）であってもよい。

ステップＳ５４において、ドナーｇＮＢ２００−１のアダプテーションエンティティ３３は、送信要求（ＵＬ ｓｔａｔｕｓ ｒｅｑｕｅｓｔ）の受信に応じて、送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）をＩＡＢノード３００−２のアダプテーションエンティティ２３に送信する。

ステップＳ５５において、ＩＡＢノード３００−２のアダプテーションエンティティ２３は、送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）の受信に応じて、送信側ＲＬＣエンティティ２２Ｔに対して上りリンクデータの送達確認応答を行う。当該応答には、送達確認したパケットのＲＬＣ ＳＮ、もしくはアダプテーションエンティティ２３のＳＮ（パケット識別番号）を含めてもよい。

ＩＡＢノード３００−２の送信側ＲＬＣエンティティ２２Ｔは、アダプテーションエンティティ２３からの応答に応じて、ＲＬＣ送信ウィンドウをスライドさせる。

なお、ＵＥ１００側へＡＣＫを伝達する方法としては、上述した第２実施形態と同様な方法を利用してもよい。

本変更例によれば、ＩＡＢノード３００−２の上位レイヤ（アダプテーションエンティティ２３）が送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）をドナーｇＮＢ２００−１から受信し、この送達情報に関する情報をアダプテーションエンティティ２３から送信側ＲＬＣエンティティ２２Ｔに通知することにより、送信側ＲＬＣエンティティ２２ＴにおけるＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇの発生を抑制できる。

図１６に示す動作例では、ドナーｇＮＢ２００−１の送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）をＩＡＢノード３００−２が受信し、ＲＬＣ送信ウィンドウをスライドさせる例を示したが、これに限らない。前記送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）は、ＩＡＢノード３００−１のアダプテーションエンティティ２３のルーティング機能を介して伝送される為、ＩＡＢノード３００−１においても解読が可能である。前記ＩＡＢノード３００−２の動作と同様に、ＩＡＢノード３００−１においてもＲＬＣ送信ウィンドウをスライドさせることが可能である。つまり、ＩＡＢノード３００−１のアダプテーションエンティティ２３は、前記送達情報（ＵＬ ｓｔａｔｕｓ ｄｅｌｉｖｅｒｙ）の送信先が自分自身でない場合においても情報を解読し、自身（ＩＡＢノード３００−１）のＲＬＣエンティティ２２Ｔに対して送達確認情報を提供する。これにより、ＲＬＣエンティティ２２ＴはＲＬＣ送信ウィンドウをスライドすることが可能である。このような方法により、ＩＡＢノード毎に別々の送達確認要求及び送達情報をやり取りする必要がなくなり、ネットワーク上のシグナリング負荷を低減することが可能である。

［第２実施形態の変更例３］
第２実施形態の変更例３について、上述した第２実施形態及びその変更例１、２との相違点を主として説明する。本変更例は、上述した第２実施形態及びその変更例１、２と併用して実施してもよいし、上述した第２実施形態及びその変更例１、２とは別に実施してもよい。

図１７は、第２実施形態の変更例３の想定シナリオを示す図である。なお、第２実施形態の変更例３の想定シナリオは、上述した第２実施形態の図１１及び図１２と同様である。

図１７に示すように、ドナーｇＮＢ（ＩＡＢ ｄｏｎｏｒ）２００−１とＵＥ１００−３との間に、ＩＡＢノード３００−１（ＩＡＢ ｎｏｄｅ＃１）及びＩＡＢノード３００−２（ＩＡＢ ｎｏｄｅ＃２）が介在している。ＩＡＢノード３００−１（ＩＡＢ ｎｏｄｅ＃１）及びＩＡＢノード３００−２（ＩＡＢ ｎｏｄｅ＃２）のそれぞれは、ＵＥ１００からドナーｇＮＢ２００−１へ送信される上りリンクデータ（ＵＬ ｄａｔａ）を中継する。

ドナーｇＮＢ２００−１がＲＬＣ ＡＣＫをＩＡＢノード３００−１に送信し、ＩＡＢノード３００−１がＲＬＣ ＡＣＫをＩＡＢノード３００−２に送信し、ＩＡＢノード３００−２がＲＬＣ ＡＣＫをＵＥ１００に送信する。このように、ＲＬＣ ＡＣＫが上位から下位へ向けて順次伝送される場合、ＲＬＣ ＡＣＫの遅延が大きくなる。その結果、下位装置（ＵＥ１００及びＩＡＢノード３００−２）の送信側ＲＬＣエンティティにおいてＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇが発生する可能性がある。

そこで、本変更例では、このような遅延を考慮して、ドナーｇＮＢ２００−１がＲＬＣ送信ウィンドウに関する設定を行う。

図１８は、第２実施形態の変更例３に係る動作を示す図である。

図１８に示すように、ステップＳ４０１において、ドナーｇＮＢ２００は、ＵＥ１００とドナーｇＮＢ２００との間に介在するＩＡＢノード３００の数を示すホップ数に基づいて、ＲＬＣウィンドウに関する設定パラメータを決定する。ここで、ドナーｇＮＢ２００は、自身の配下の各ＩＡＢノード３００を管理しており、ホップ数を把握している。

ＲＬＣウィンドウに関する設定パラメータは、例えば、送信側ＲＬＣエンティティが管理するＲＬＣ送信ウィンドウの長さ、受信側ＲＬＣエンティティから送信側ＲＬＣエンティティへのＲＬＣ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ（ＳＴＡＴＵＳ ＰＤＵ）の送信を禁止する時間を定めるタイマ（ｔ−ＳｔａｔｕｓＰｒｏｈｉｂｉｔ）、送信側ＲＬＣエンティティから受信側ＲＬＣエンティティへＲＬＣ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ（ＳＴＡＴＵＳ ＰＤＵ）の送信を要求するトリガとするデータ量又はＰＤＵ数の閾値（ｐｏｌｌＰＤＵ、ｐｏｌｌＢｙｔｅ）のうち、少なくとも１つを含む。

ドナーｇＮＢ２００は、ホップ数が多いほど、ＲＬＣ送信ウィンドウを大きくするように決定してもよい。ドナーｇＮＢ２００は、ホップ数が多いほど、ｔ−ＳｔａｔｕｓＰｒｏｈｉｂｉｔの値を小さくするように決定してもよい。ドナーｇＮＢ２００は、ホップ数が多いほど、データ量又はＰＤＵ数の閾値を小さくするように決定してもよい。

ステップＳ４０２において、ドナーｇＮＢ２００は、ステップＳ４０１で決定された設定パラメータをＵＥ１００及びＩＡＢノード３００の少なくとも一方に設定する。具体的には、ドナーｇＮＢ２００は、ステップＳ４０１で決定された設定パラメータを含む設定メッセージをＵＥ１００及びＩＡＢノード３００の少なくとも一方に送信する。

本変更例によれば、ドナーｇＮＢ２００は、ホップ数を考慮してＲＬＣウィンドウに関する設定パラメータを決定することにより、送信側ＲＬＣエンティティにおけるＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇの発生を抑制できる。

［第２実施形態の変更例４］
第２実施形態の変更例４について、上述した第２実施形態及びその変更例１乃至３との相違点を主として説明する。本変更例は、上述した第２実施形態及びその変更例１乃至３と併用して実施してもよいし、上述した第２実施形態及びその変更例１乃至３とは別に実施してもよい。

第２実施形態の変更例４の想定シナリオは、第２実施形態の変更例３と同様である（図１７参照）。

本変更例は、ＩＡＢノード３００の送信側ＲＬＣエンティティが、ＡＣＫ／ＮＡＣＫを示すＲＬＣ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ（ＳＴＡＴＵＳ ＰＤＵ）の送信を要求するポーリングを上位装置に対して送信する動作に関する。なお、上位装置は、ドナーｇＮＢ２００、又はドナーｇＮＢ２００とＩＡＢノード３００との間に介在する他のＩＡＢノードである。

図１９は、第２実施形態の変更例４に係る動作を示す図である。ここでは、図１７に示すＩＡＢノード３００−２を例に挙げて説明する。

図１９に示すように、ステップＳ５０１において、ＩＡＢノード３００−２は、自身の下位装置であるＵＥ１００のＲＬＣ送信ウィンドウの状態を推定する。例えば、ＩＡＢノード３００−２は、ＵＥ１００のＲＬＣ送信ウィンドウ設定、ＵＥ１００からのバッファ状態報告（ＢＳＲ）、ＵＥ１００に割り当てた上りリンクリソースの情報（ＵＬ ｇｒａｎｔ）などに基づいて、ＵＥ１００のＲＬＣ送信ウィンドウの状態を推定する。ここで、ＩＡＢノード３００−２は、自身の下位装置であるＵＥ１００のＲＬＣ設定をＩＡＢドナー（ドナーｇＮＢ２００−１）から受信していてもよい。

特に、ＩＡＢノード３００−２は、ＵＥ１００においてＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇが発生したか否かを推定する。ＩＡＢノード３００−２は、ＵＥ１００においてＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇが発生する将来のタイミングを予測してもよい。

ステップＳ５０２において、ＩＡＢノード３００−２は、ステップＳ５０１で推定したＲＬＣ送信ウィンドウの状態に基づいて、ポーリングをＩＡＢノード３００−１に送信する。例えば、ＩＡＢノード３００−２は、ＵＥ１００においてＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇが発生した又はＴｘ Ｗｉｎｄｏｗ Ｓｔａｌｌｉｎｇが近いうちに発生すると推定した場合、ポーリングをＩＡＢノード３００−１に送信する。

これにより、ＩＡＢノード３００−２は、ＩＡＢノード３００−１からＲＬＣ ＡＣＫ／ＮＡＣＫを適切なタイミングで取得できるため、ＵＥ１００からポーリングを受けた際に即座にＲＬＣ ＡＣＫ／ＮＡＣＫをＵＥ１００に送信できる。

［第３実施形態］
第３実施形態について、上述した第１実施形態及び第２実施形態との相違点を主として説明する。本実施形態は、上述した第１実施形態及び第２実施形態と併用して実施してもよいし、上述した第１実施形態及び第２実施形態とは別に実施してもよい。

ＩＡＢノード３００の直下の下位装置は、ＩＡＢノード３００との無線リンク障害（ＲＬＦ）を検知した場合、他のセルを再選択し、再選択したセルに対して接続の再確立を試みる。しかしながら、ＲＬＦは、基本的には下りリンクの受信状態に基づいて検知されるため、ＩＡＢノード３００は、下位装置がＲＬＦを検知したことを把握できない可能性がある。

図２０は、第３実施形態に係るＩＡＢノード３００の動作を示す図である。

図２０に示すように、ステップＳ６０１において、ＩＡＢノード３００は、自身の直下の下位装置から定期的に送信される上りリンク信号を受信する。下位装置とは、ＵＥ１００、又はＵＥ１００とＩＡＢノード３００との間に介在する他のＩＡＢノードをいう。上りリンク信号とは、定期的に送信可能な信号であればどのようなものであってもよいが、例えば、ＭＡＣ ＣＥ（例えば、バッファ状態報告）、ＲＲＣメッセージ（例えば、測定報告メッセージ）、上りリンク参照信号を利用できる。

ステップＳ６０２において、ＩＡＢノード３００は、下位装置からの上りリンク信号の受信に応じて、タイマを開始させる。このタイマに設定されるタイマ値は、ドナーｇＮＢ２００−１から設定された値であってもよい。タイマ値は、下位装置が上りリンク信号を送信する周期よりも長い時間であってもよい。

タイマを開始させた後、ＩＡＢノード３００は、下位装置から上りリンク信号を受信した場合（ステップＳ６０３：ＹＥＳ）、ステップＳ６０４において、タイマを停止させる。この場合、処理がステップＳ６０２に戻り、タイマを再開させる。

一方、下位装置から上りリンク信号を受信することなく（ステップＳ６０３：ＮＯ）、タイマが満了した場合（ステップＳ６０５：ＹＥＳ）、ステップＳ６０６において、ＩＡＢノード３００は、下位装置がＲＬＦを検知したと判断する。ＩＡＢノード３００は、自身の下位装置がＲＬＦを検知したと判断した場合、自身の上位装置に対して、この下位装置に対応する無線ベアラ（バックホールリンク）の解放を要求してもよい。

第３実施形態によれば、下位装置においてＲＬＦが検知されたことをＩＡＢノード３００が把握できる。

［第４実施形態］
第４実施形態について、上述した第１実施形態乃至第３実施形態との相違点を主として説明する。本実施形態は、上述した第１実施形態乃至第３実施形態と併用して実施してもよいし、上述した第１実施形態乃至第３実施形態とは別に実施してもよい。

図２１は、第４実施形態に係る動作を示す図である。図２１において、「ＤＵ」は基地局機能に相当し、「ＭＴ」はユーザ装置機能に相当する。

図２１に示すように、ＵＥ１００−３は、ステップＳ７０１乃至Ｓ７０５の手順により上りリンクデータ（ＰＤＵ）をＩＡＢノード３００−２に送信する。具体的には、ＵＥ１００−３は、スケジューリング要求（ＳＲ）をＩＡＢノード３００−２に送信し（ステップＳ７０１）、ＢＳＲ送信用の上りリンク無線リソースの割り当てを受け（ステップＳ７０２）、ＢＳＲを送信し（ステップＳ７０３）、上りリンクデータ送信用の上りリンク無線リソースの割り当てを受け（ステップＳ７０４）、上りリンクデータをＩＡＢノード３００−２に送信する（ステップＳ７０５）。

同様にして、ＩＡＢノード３００−２は、ステップＳ７０６乃至Ｓ７１０の手順により上りリンクデータ（ＰＤＵ）をＩＡＢノード３００−１に送信する。

また、ＩＡＢノード３００−１は、ステップＳ７１１乃至Ｓ７１５の手順により上りリンクデータ（ＰＤＵ）をドナーｇＮＢ２００−１に送信する。

本シーケンスにおいて、各ＩＡＢノード３００は、上りリンク無線リソースの割り当てを要求する第１スケジューリング要求を下位装置から受信する。そして、各ＩＡＢノード３００は、上りリンクデータ（ＰＤＵ）を下位装置から受信するよりも前において、第２スケジューリング要求を上位装置に送信する。

一般的に、スケジューリング要求は、送信するべき上りリンクデータを有する場合にトリガされるが、本実施形態では、送信するべき上りリンクデータを未だ有していない段階でスケジューリング要求をトリガしている。これにより、円滑な上りリンク無線リソースの割り当てを実現できる。

例えば、ステップＳ７０６において、ＩＡＢノード３００−２は、ＵＥ１００−３からＢＳＲを受信（ステップＳ７０３）した際に、スケジューリング要求をＩＡＢノード３００−１に送信する。

ＩＡＢノード３００−２は、ＵＥ１００−３からスケジューリング要求を受信（ステップＳ７０１）した後、ＵＥ１００−３からＢＳＲを受信（ステップＳ７０３）する前に、スケジューリング要求をＩＡＢノード３００−１に送信してもよい。

ＩＡＢノード３００−２は、ＵＥ１００−３からスケジューリング要求を受信（ステップＳ７０１）した後、ＵＥ１００−３に上りリンク無線リソースを割り当てた際（ステップＳ７０２）に、スケジューリング要求をＩＡＢノード３００−１に送信（トリガ）してもよい。

ＩＡＢノード３００−２は、ＵＥ１００−３からスケジューリング要求を受信した際（ステップＳ７０１）に、スケジューリング要求をＩＡＢノード３００−１に送信（トリガ）してもよい。

本実施形態において、各ＩＡＢノード３００は、当該ＩＡＢノード３００が上りリンク送信に利用可能なデータの量を少なくとも示す第１のバッファ状態報告を上位装置に送信する。ここで、上位装置とは、ドナーｇＮＢ２００の配下の他のＩＡＢノード（上位ＩＡＢノード）又はドナーｇＮＢ２００である。上位装置は、第１のバッファ状態報告に基づいて、上りリンク送信用の無線リソースをＩＡＢノード３００に割り当てる。

ＩＡＢノード３００は、上りリンク送信待ちのデータを一時的に記憶する上りリンクバッファを有する。例えば、ＩＡＢノード３００のＭＡＣレイヤは、当該上りリンクバッファ内のデータ量を示す情報を含む第１のバッファ状態を上位装置のＭＡＣレイヤに通知する。上位装置のＭＡＣレイヤはスケジューラを有しており、第１のバッファ状態に基づいて上りリンク無線リソースをＩＡＢノード３００に割り当て、制御チャネルを介して割当リソースをＩＡＢノード３００に通知する。

ここで、ＩＡＢノード３００は、複数のＵＥ分の上りリンクデータをバッファリングするため、ＵＥ１００に比べて大容量の上りリンクバッファを有すると考えられる。よって、ＩＡＢノード向けのバッファ状態報告は、ＵＥ向けのバッファ状態報告とは異なるフォーマットを有していてもよい。また、ＩＡＢノード向けのバッファ状態報告が表現可能なデータ量（最大データ量）は、ＵＥ向けのバッファ状態報告が表現可能なデータ量（最大データ量）よりも大きくてもよい。

ＩＡＢノード向けのバッファ状態報告は、ＩＡＢノード３００の配下のＵＥ１００の数に関する情報を含んでもよい。ＩＡＢノード３００は、自身の配下のＵＥ１００の数をＵＥコンテキストやＣ−ＲＮＴＩ等に基づいて判断してもよいし、自身の配下のＵＥ１００の数をドナーｇＮＢ２００から通知されてもよい。ＩＡＢノード３００は、自身の配下のＵＥ１００のうち、自身の上りリンクバッファ内にデータがあるＵＥ１００の数をバッファ状態報告に含めてもよい。言い換えると、ＩＡＢノード３００は、自身がいくつのＵＥ分の上りリンクデータを持っているかをバッファ状態報告により上位装置に通知してもよい。或いは、ＩＡＢノード３００は、自身の配下のＵＥ１００のうち、ＲＲＣコネクティッド状態にあるＵＥ１００の数をバッファ状態報告に含めてもよい。

ＩＡＢノード向けのバッファ状態報告は、ＩＡＢノード３００の上りリンクバッファ内に実際に存在するデータの量だけではなく、下位装置からのバッファ状態報告（すなわち、潜在的な上りリンクデータ量）が加味されてもよい。これにより、上位装置は、潜在的な上りリンクデータ量を考慮して、上りリンク無線リソースを予めＩＡＢノード３００に割り当てておくことができるため、マルチホップに起因する上りリンクの伝送遅延を抑制できる。

ＩＡＢノード３００は、下位装置から、下位装置が上りリンク送信に利用可能なデータの量を示す第２のバッファ状態報告を受信する。ＩＡＢノード３００は、第２のバッファ状態報告に基づいて、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量とに基づく第１のバッファ状態報告を上位装置に送信する。例えば、ＩＡＢノード３００は、自身が上りリンク送信に利用可能なデータの量と下位装置が上りリンク送信に利用可能なデータの量との合計値を第１のバッファ状態報告に含めてもよい。或いは、ＩＡＢノード３００は、自身が上りリンク送信に利用可能なデータの量を示す第１のＢＳＲ値と、下位装置が上りリンク送信に利用可能なデータの量を示す第２のＢＳＲ値とを別々に第１のバッファ状態報告に含めてもよい。

なお、ＩＡＢノード３００が上りリンク送信に利用可能なデータ量とは、自身の送信バッファ（ＭＴのバッファ）のデータ量、自身の受信バッファ（ＤＵ）のデータ量、アダプテーションエンティティのバッファ量を含んでもよい。

［その他の実施形態］
上述した実施形態において、移動通信システム１が５Ｇ移動通信システムである一例について主として説明した。しかしながら、移動通信システム１における基地局はｅＮＢであってもよい。また、移動通信システム１におけるコアネットワークはＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されることもできる。

なお、上述した実施形態に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ等の記録媒体であってもよい。ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。

なお、各図において示されるフローは、適宜組み合わされても良い。

［付記１］
１． 序論
ＲＡＮ２ ＡＨ１８０７は、ｅｎｄ−ｔｏ−ｅｎｄの信頼性、即ち、「ｅｎｄ−ｔｏ−ｅｎｄ」及び「ｈｏｐ−ｂｙ−ｈｏｐ」のＲＬＣ ＡＲＱメカニズムを比較することを広く議論し、ＴＲに追加のテキストを取り込むことに合意した。

「ｅｎｄ−ｔｏ−ｅｎｄ」及び「ｈｏｐ−ｂｙ−ｈｏｐ」のＡＲＱに対する所見

ｈｏｐ−ｂｙ−ｈｏｐのＲＬＣ ＡＲＱの場合におけるｅｎｄ−ｔｏ−ｅｎｄの信頼性の課題は、例えば、以下のメカニズムを特定することによって対処することができる。

−ＰＤＣＰプロトコル／プロシージャの変更。この解決策は、Ｒｅｌ−１５ ＵＥには適用できないであろう、それはＲｅｌ−１５ ＵＥの性能が損なわれる可能性があることを意味する。

−経路更新（ＦＦＳ ＩＡＢノード間で交換される必要のある情報）に応じて中間ＩＡＢノードにバッファされたＰＤＣＰ ＰＤＵの再ルーティング。

−ＵＬステータス配信（ドナーｇＮＢからＩＡＢノードに）を導入することにより、ＩＡＢノードは、ドナーｇＮＢでの受信の確認までＵＥへのＲＬＣ ＡＣＫの送信を遅らせることができる。

この付記において、ｈｏｐ−ｂｙ−ｈｏｐのＲＬＣ ＡＲＱメカニズムの更なる考察が議論される。

２． 議論
合意されたＴＰは、ｅｎｄ−ｔｏ−ｅｎｄの信頼性、即ち、「トポロジ変更中のＵＬデータの損失のない配信」に関して、「ｈｏｐ−ｂｙ−ｈｏｐ」のＲＬＣ ＡＲＱメカニズムにおける課題を特定し、それはまた３つの可能なアプローチを取り入れる。参考として、アプローチを以下に引用する。

第１のアプローチ：「ＰＤＣＰプロトコル／プロシージャの変更。この解決策は、Ｒｅｌ−１５ ＵＥには適用できないであろう、それはＲｅｌ−１５ ＵＥの性能が損なわれる可能性があることを意味する。」
第２のアプローチ：「経路更新に応じて中間ＩＡＢノードにバッファされたＰＤＣＰ ＰＤＵの再ルーティング。（ＦＦＳ ＩＡＢノード間で交換される必要のある情報）」
第３のアプローチ：「ＵＬステータス配信（ドナーｇＮＢからＩＡＢノードに）を導入することにより、ＩＡＢノードは、ドナーｇＮＢでの受信の確認までＵＥへのＲＬＣ ＡＣＫの送信を遅らせることができる。」

２．１． 信頼性のあるｈｏｐ−ｂｙ−ｈｏｐのＡＲＱのための第１のアプローチ
第１のアプローチは、例えば、既に送信されたＰＤＣＰ ＰＤＵを一定期間維持しながらＤＣＰデータ回復を行うために、いくつかの「ＰＤＣＰプロトコル／プロシージャの変更」を必要とする。しかしながら、それはＴＲで取り込まれているように、Ｒｅｌ−１５ ＵＥの性能を損なう。さらに、Ｒｅｌ−１６ ＰＤＣＰプロトコルを実装するＵＥを有する必要がある可能性がある、これは、ＴＲに取り込まれている以下の要件を満たすことができないことを意味する。

ＩＡＢ設計は、ＩＡＢノードに接続する以下のＵＥを少なくともサポートする。

−Ｒｅｌ．１５ ＮＲ ＵＥ
−ＩＡＢがＬＴＥアクセスのバックホールをサポートしている場合、レガシＬＴＥ ＵＥ
この意味では、それはｅｎｄ−ｔｏ−ｅｎｄの信頼性を保証するための解決策候補にはなり得ない。

提案１：ＲＡＮ２は、「Ｒｅｌ−１５ ＵＥの性能が損なわれる可能性がある」ことに加えて、「ＰＤＣＰの変更」がＲｅｌ−１５ ＵＥのための解決策ではないことに同意すべきである。

２．２． 信頼性のあるｈｏｐ−ｂｙ−ｈｏｐのＡＲＱのための第２のアプローチ
第２のアプローチは、「経路更新に応じて中間ＩＡＢノードにバッファされたＰＤＣＰ ＰＤＵの再ルーティング」のための新しい機能を導入することになり、それはＲＬＣ又はアダプテーションレイヤのいずれかの中に実装されると仮定され得る。経路更新は、例えば、以下のような複数のシナリオを意味する可能性がある。

−親への接続は失敗し、異なる親への別の接続として回復する（即ち、ＲＲＣ再確立）。又は、
−親への接続は、異なる親に変更されるように再設定される（即ち、ハンドオーバ）。又は、
−異なる親への２つの接続のうちの１次接続が他方に切り替えられる（即ち、例えばデュアルコネクティビティによる冗長ルーティング）。

上記のいくつかの場合において（例えば、ハンドオーバ時に）、ＲＬＣエンティティは再確立される必要があるかもしれず、更に全てのＲＬＣ ＳＤＵは破棄される。そのため、Ｒｅｌ−１５ ＲＬＣの動作が変更されない限り、ＰＤＣＰ ＰＤＵをバッファリング／再ルーティングすることはできない。一方、「ＲＬＣより上の」タイプのアダプテーションレイヤは、ＲＬＣ再確立中にＰＤＣＰ ＰＤＵをバッファリングするのに適し、そしてアクティブＭＡＣリンクに関連する（他の）ＲＬＣエンティティにそれらを再ルーティングするのに適すると考えられる。

提案２：ＲＡＮ２は、ＰＤＣＰ ＰＤＵをバッファリング／再ルーティングする機能が、中間ＩＡＢノードにおいて「ＲＬＣより上」に位置するアダプテーションレイヤによって処理されることに同意すべきである。

これらの場合を考慮すると、「情報が交換される必要がある」ことは、それはＲＲＣの再設定を含むことになるので、例えば、アーキテクチャグループ２に対して既に取り入れられた「ＩＡＢノード間」に加えて、例えば、アーキテクチャグループ１のために、ＩＡＢドナー及びＩＡＢノードの間にあると考えられる。加えて、経路更新のために、例えば、ＲＬＦのために、経路更新のためにＩＡＢノード間で情報を交換することは既に不可能であるかもしれない。従って、ＴＲはＩＡＢノード内の情報交換のエンティティを制限すべきではないと考えられる。

提案３：ＲＡＮ２は、「ＰＤＣＰ ＰＤＵの再ルーティング」を契機とした情報交換のために「又はＩＡＢドナーとＩＡＢノード間の」というテキストを追加することに同意すべきである。

第２のアプローチの利点は、たとえＲＬＣチャネルのうちの１つが例えばＲＬＦのために失敗したとしても、ＩＡＢネットワークがそれ自体でパケット損失を回復することであろう。一方、結局のところ、それはｅｎｄ−ｔｏ−ｅｎｄの信頼性のための完璧な解決策ではないかもしれない。例えば、適切なＩＡＢドナー／ノードが周囲にないために、再ルーティングのための中間ＩＡＢノードが他の接続を得ることができず、最終的にＰＤＣＰ ＰＤＵを失う場合、データの損失のない配信は保証されない。

提案４：ＲＡＮ２は、「ＰＤＣＰ ＰＤＵの再ルーティング」が最終的に損失のない配信を保証するのではなく、別の経路が見つかる限り中間ＲＬＣチャネルのパケット損失を改善／回復することに同意すべきである。

２．３． 信頼性のあるｈｏｐ−ｂｙ−ｈｏｐのＡＲＱのための第３のアプローチ
第３のアプローチ、即ち、「ＵＬステータス配信（ドナーｇＮＢからＩＡＢノードに）を導入すること」は興味深いが、これまでの寄書では何らかの関連される／可能な解決策が明らかにされているかどうか明白ではない。従って、研究段階でも、もう少し詳しく議論する価値がある。

現時点で「ＵＬステータス配信」が何であるかは明確にされていないが、これの目的は、例えば、ＵＥのＰＤＣＰレイヤにおけるＰＤＣＰ ＰＤＵをバッファリングし、ＰＤＣＰデータを回復することを可能にするために、「ＩＡＢノードが、ドナーｇＮＢでの受信の確認まで、ＲＬＣ ＡＣＫのＵＥへの送信を遅らせることができる」ことを許可することである。そのため、ＩＡＢノードのＲＬＣレイヤに導入される可能性がある新しいメカニズムによるＲｅｌ−１５ ＰＤＣＰへの影響は何ら予期されない。

提案５：ＲＡＮ２は、第３のアプローチの影響がＩＡＢネットワーク内で（即ち、ＩＡＢドナー及びＩＡＢノードにおいて）制限されるかどうかを議論するべきである。

提案３に同意する場合、エッジのＩＡＢノードの観点から、ＩＡＢドナーへのステータスＵＬ配信を確認するために以下のような２つの選択肢がある。

−選択肢１：ＵＬ配信ステータス報告は、ＩＡＢドナーからエッジのＩＡＢノードに直接送られることにより、ＲＬＣ ＡＣＫは、それ自身の受信ステータス及びＵＬ配信ステータス報告の両方を考慮に入れる。

−選択肢２：ＳＴＡＴＵＳ ＰＤＵ（即ち、ＡＣＫ）は、今日のようにピアＰＬＣエンティティの間で送られることにより、ＲＬＣ ＡＣＫは、それ自身だけでなく親ノードのＲＬＣエンティティにおいて成功した受信を考慮に入れる。

選択肢１は、ＴＲで取り入れられた文の直接的な解釈であるが、各エッジのＩＡＢノードに各ＵＬ配信ステータス報告を送ることに関して、いくらかの複雑さが所見される。新しい報告は通常のＲＬＣ ＰＤＵ（即ち、ＳＴＡＴＵＳ ＰＤＵ）とは異なるので、バックホールリンクを介した追加のシグナリングオーバヘッドをもたらす可能性がある。

選択肢２は、ＲＬＣ ＡＣＫのバケツリレーゲームのような単純な代替であることにより、ＩＡＢノードは、親ノードから関連付けられたＲＬＣ ＡＣＫを受信した後、既存のＲＬＣ ＡＣＫを送るだけである。利点は、追加のシグナリングを必要とせず、スケーラビリティを提供することである（即ち、ホップ数に制限がない）。欠点は、ＵＥがＩＡＢノードからＳＴＡＴＵＳ ＰＤＵを受信するためにより長い時間待つ可能性があることだが、選択肢１よりも悪くない。

まだ研究段階にあるので、両方の選択肢が有益であると認識される場合、両方の選択肢はＴＲに取り込まれるべきである。

提案６：ＲＡＮ２は、「ＵＬステータス配信」の詳細をＴＲに取り込むことに同意すべきである。特に、ＩＡＢノードはＩＡＢドナーからのＵＬ配信ステータス報告（選択肢１）及びその親ノードからのＲＬＣ ＡＣＫ（選択肢２）を考慮する。

［付記２］
１．序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。このＷＩの目的の１つは、ロスレス配信でマルチホップＲＬＣ ＡＲＱメカニズムを指定することである。

Ｌ２無線トランスポートの拡張の仕様：
・ｈｏｐ−ｂｙ−ｈｏｐのＡＲＱにおけるロスレス配信を可能にするメカニズムの仕様。

この付記では、ｈｏｐ−ｂｙ−ｈｏｐのＡＲＱの規範的なワークのための最初の考慮事項について議論する。

２．議論
調査段階では、マルチホップＲＬＣ ＡＲＱが広く議論され、最終的にＴＲは、「ＲＡＮ２は、ｈｏｐ−ｂｙ−ｈｏｐ及びｅｎｄ−ｔｏ−ｅｎｄのＲＬＣ ＡＲＱを研究した。Ｒｅｌ−１６では、ｈｏｐ−ｂｙ−ｈｏｐのＡＲＱのみをサポートすることが推奨される。」と結論付けた。ｈｏｐ−ｂｙ−ｈｏｐのＲＬＣ ＡＲＱに関して、ＵＬデータのロスレス配信の問題が特定され、候補の解決策とこれらの所見がＴＲでキャプチャされた。ｈｏｐ−ｂｙ−ｈｏｐのＲＬＣ ＡＲＱにおけるｅｎｄ−ｔｏ−ｅｎｄの信頼性の問題は、例えば、次のメカニズムを指定することで対処できる。

−ＰＤＣＰプロトコル/手順の変更。このメカニズムは、Ｒｅｌ−１５ ＵＥのパフォーマンスが低下する可能性があるため、Ｒｅｌ−１５のＵＥには適用されないだろう
−ＰＤＣＰデータ回復／ＰＤＣＰ再確立がＲＲＣによってトリガされるか、ＰＤＣＰステータスレポートが受信される場合、ＵＥは、ＲＬＣによって配信の成功が確認されたかどうかに関係なく、ＵＬデータを再送信する
−ＲＬＣによる配信成功の確認に関係なくＵＥがＵＬデータ再送信を実行するかどうかを示すために、ＲＲＣメッセージ又はＰＤＣＰステータスレポートに新しいフィールドを含め得る
−経路更新に応じて、中間ＩＡＢノードでバッファされたＰＤＣＰ ＰＤＵの再ルーティング
−ＵＬデータは、ＩＡＢノードが親ノードからＩＡＢドナーに正常に配信されたＵＬデータに関する情報、又はＲＬＣ肯定ＡＣＫのいずれかを受信するまで、ＩＡＢノードでバッファされる
−転送パスが（再）設定されると、バッファされたデータは、新しいパスの最新の変更がされていないノードであるＩＡＢノード、又はバックホールリンク障害が発生したＩＡＢノードによって再送信される
−ＵＬステータス配信の導入（ドナーｇＮＢからＩＡＢノードへ）
−１つの方法は、ＵＥのアクセスＩＡＢノードが、ＩＡＢドナーからデータ受信の確認を受信するまで、ＵＥへのＲＬＣ肯定ＡＣＫの送信を遅らせることである。別の方法は、ＩＡＢノードが、親ノードからＲＬＣ肯定ＡＣＫを受信するまで、子ノード又はＵＥへのＲＬＣ肯定ＡＣＫの送信を遅らせることである。
−ＲＲＣによってＰＤＣＰデータ回復／ＰＤＣＰ再確立がトリガされる場合、ＵＥは現在の仕様のようにＵＬデータを再送信する

明らかに、「ＵＬステータス配信の導入」の３番目の候補は、研究段階で議論されたメトリックスに利点がある。したがって、Ｒｅｌ−１６の規範的なワークでは、３番目の解決策を優先する必要がある。他の解決策も検討することができ、除外することは意図されていない。

提案１：ＲＡＮ２は、ｈｏｐ−ｂｙ−ｈｏｐのＲＬＣ ＡＲＱにおけるＵＬのロスレス配信で特定された「ＵＬステータス配信の導入」に基づく解決策を最初に検討すべきである。

提案１が受け入れられる場合、「ＵＬステータス配信」が何であるかを明確にすべきである。ＴＲは、次の２つの可能性をキャプチャする。

「１つの方法は、ＩＡＢノードからのデータ受信の確認を受信するまで、ＵＥのアクセスＩＡＢノードがＲＬＣ肯定ＡＣＫのＵＥへの送信を遅らせることである。」（選択肢１）
・「別の方法は、ＩＡＢノードが、親ノードからＲＬＣ肯定ＡＣＫを受信するまで、子ノード又はＵＥへのＲＬＣ肯定ＡＣＫの送信を遅らせることである。」（選択肢２）

所見１：「ＵＬステータス配信」の２つの選択肢が研究段階で特定された。

選択肢１では、ＩＡＢノードはＩＡＢドナーから直接ＵＬステータス配信を受信する。ＲＬＣ ＳＴＡＴＵＳ ＰＤＵがピアＲＬＣエンティティ間で転送されることを考慮すると、マルチホップ機能により、ＵＬステータス配信が中間ＲＬＣエンティティを超えて（つまり、中間ＩＡＢノードで）必要になることが課題となるだろう。中間ＩＡＢノードのＲＬＣエンティティをバイパスするには、（アクセス）ＩＡＢノードとＩＡＢドナー間の直接メッセージ（つまり、ＵＬステータス配信）は、ＲＬＣレイヤの上に配置され、無線バックホール全体のルーティングを提供するアダプテーションレイヤに（或いは、他の可能性として、Ｆ１−ＡＰに）実装する必要がある。アダプテーションレイヤ／Ｆ１−ＡＰとＲＬＣレイヤとの間のレイヤ間相互作用（例えば、ＲＬＣ層からのポーリング要求、ＲＬＣデータＰＤＵのシーケンス番号のマッピングを伴うアダプテーションレイヤからの配信指示など）が必要になる可能性がある。

所見２：直接の「ＵＬステータス配信」（選択肢１）は、アダプテーションレイヤ又はＦ１−ＡＰに実装されてもよく、いくつかのレイヤ間の相互作用が必要である。

選択肢２では、ＩＡＢノードは、親ノードから対応するＲＬＣ ＡＣＫを受信するまで、子ノードにＲＬＣ ＡＣＫを送信するのを遅らせる。そのため、ＵＬステータス配信はＲＬＣレイヤで既存のＳＴＡＴＵＳ ＰＤＵを再利用でき、メッセージは「暗示的」と見なされます。ただし、エッジデバイス（例えば、ＵＥ及び（アクセス）ＩＡＢノード）でＲＬＣ ＡＣＫの遅延が長くなると、ウィンドウの長さが長くなったり、ｔ−ＳｔａｔｕｓＰｒｏｈｉｂｉｔタイマが短くなったり、注意深い操作が行われたりしない限り、ＲＬＣウィンドウが停止するため、レイテンシ／スループットが低下する可能性がある。

所見３：暗示的な「ＵＬステータス配信」（選択肢２）は、既存のＲＬＣ ＳＴＡＴＵＳ ＰＤＵを再利用できますが、頻繁なＲＬＣウィンドウ停止を回避するために、慎重に実装する必要がある。

「ＵＬステータス配信」の２つの選択肢には長所と短所がありますが、選択肢２の方が簡単であるため、標準化の労力は少なくなる。

提案２：ＲＡＮ２は、既存のＲＬＣ ＳＴＡＴＵＳ ＰＤＵを再利用する暗示的な「ＵＬステータス配信」、すなわち、「ＩＡＢノードは、その親ノードからＲＬＣ肯定ＡＣＫを受信するまで、その子ノード又はＵＥへのＲＬＣ肯定ＡＣＫの送信を遅らせる」（上記選択肢２）を採用（又は優先）することに同意すべきである。

選択肢間の共通の側面は、ＲＬＣがＵＥ及び／又は子ノードへのＲＬＣ ＡＣＫのための追加条件、つまりＳＴＡＴＵＳ ＰＤＵでＡＣＫ＿ＳＮを設定する方法を持つ必要があることだろう。ＩＡＢノードのＲＬＣエンティティは、実際にＵＥ／子ノードから関連データＰＤＵを正常に受信したが、ＩＡＢドナー／親ノードからの「ＵＬステータス配信」の受信を待つ必要があるためである。単純な解決策は、ＲＬＣエンティティが「ＵＬステータス配信」を受信するまで、関連するデータＰＤＵがまだ受信されていないと見なすことである。

提案３：ＲＡＮ２は、選択肢（つまり、直接的又は暗示的）に関係なく、ＳＴＡＴＵＳ ＰＤＵを構築する場合、「ＵＬステータス配信」が受信されるまで、関連するＵＬデータＰＤＵがまだ受信されていないとＲＬＣエンティティが見なすことに同意すべきである。

［付記３］
１．序論
統合されたアクセスとバックホールに関する新しいワークアイテムが承認された。ＷＩＤは、目的の１つとしてバックホール無線リンク障害（ＢＨ ＲＬＦ）処理を指定することを定める。

以下を含むアーキテクチャ1aに続くIABノードの仕様
・[…]
・低遅延スケジューリング、ＢＨ ＲＬＦ処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。

・[…]
Ｌ２トランスポート及びリソース管理のシグナリングの仕様
・[…]
・ＢＨ ＲＬＦ処理の仕様（例：ダウンストリームＢＨ ＲＬＦ通知）
この付記では、研究項目からの結果に加えてＢＨ ＲＬＦ処理の最初の考慮が議論される。

２．議論
ＴＲは、セクション９．７．１４及び９．７．１５において、マルチホップの無線バックホールのＢＨ ＲＬＦに起因する問題を特定する。セクション間の共通の問題は、子ＩＡＢノード／ＵＥが親ＩＡＢノードにおけるＢＨ ＲＬＦを認識していないことである。結果として、ユーザの観点から、サービスの回復が遅れることを含むサービスが大幅に中断される。これにより、ＢＨ ＲＬＦは、ＦＲ２やマルチホッピングなどの高周波数の無線バックホールにおいて頻繁に発生する可能性がある。

このような悪いユーザーエクスペリエンスを回避するために、ＴＲは次のように潜在的な解決策も特定する。

９．７．１４アーキテクチャ１ａにおけるＢＨ ＲＬＦのダウンストリーム通知
「選択肢１：ＩＡＢノードＤＵはサービスを中止する。その結果、子ノードもＢＨ ＲＬＦを決定し、上記の手順に従って回復する。」
「選択肢２：ＩＡＢノードＤＵは、アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する。この警告を受信した子ＩＡＢノードは、警告をさらに下流に転送し得る。このような警告を受信した各ＩＡＢノードは、上記のＢＨ−ＲＬＦ回復を開始する。」
「選択肢３：全てのＩＡＢノードは、ＢＨ品質などに関する情報を子又は親のＩＡＢノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームＲＬＦを検知し得る。」

９．７．１５効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームＩＡＢノードに提供され得る。」（選択肢４）
「事前（つまり、ＲＬＦの発生前）における代替バックホールリンクとルートの準備」（選択肢５）

２．１．ＩＡＢノードがサービスを中止する（選択肢１）
選択肢１は、ＢＨ ＲＬＦ情報が子ＩＡＢノード及びＵＥに暗示的に伝搬されるため、セクション９．７．１４と９．７．１５との間の共通の問題のための一般的な解決策と見なし得る。ＢＨ ＲＬＦが子ＩＡＢノードだけでなく、（ＢＨ ＲＬＦに直面する親ＩＡＢノードに接続される）ＵＥにも影響することを考慮すると、選択肢１は既存のＲＬＦと回復メカニズムに依存することが予想されるため、選択肢１がＲｅｌ−１５ ＵＥでサポートされることは重要な側面である。一方、他の選択肢にはＲｅｌ−１６の機能が必要であろう。Ｒｅｌ−１５ ＵＥの場合でもサービスの中断を最小限に抑えるには、ＢＨ ＲＬＦの問題のためのベースラインの解決策として選択肢１を指定すべきである。

提案１：ＲＡＮ２は、選択肢１、つまりＩＡＢノードがＢＨ ＲＬＦでサービスを停止すること、及び選択肢１はＲｅｌ−１５ ＵＥにも有効であるため、ベースラインの解決策であることに同意すべきである。

選択肢１の説明によれば、解決策は「子ノードもＢＨ ＲＬＦを判定する」ことを容易にすべきである。技術的には、子ＩＡＢノードのＭＴ及びＵＥは、「サービス」が中断された場合にＲＬＦを宣言すべきである。簡単な解決策は、ＢＨ ＲＬＦ下にある親ＩＡＢノードが、ＰＳＳ、ＳＳＳ、ＭＩＢ、及びＳＩＢ１の送信を停止することである。これにより、子ＩＡＢノード及びＵＥの無線問題を意図的に作成する。

提案２：ＲＡＮ２は、「サービス」を中止することを決定した場合に、ＩＡＢノードがＰＳＳ、ＳＳＳ、ＭＩＢ、及びＳＩＢ１の送信を停止することに同意すべきである。

提案２に同意できる場合は、いつ信号が停止するかを厳密に定義すべきである。ＢＨ ＲＬＦにあることはＴＲから大まかに理解できるが、ＢＨ ＲＬＦが何であるか、及び「サービス」がいつ停止するかは不明確である。明らかに、ＢＨ ＲＬＦは、ＩＡＢノードのＭＴとＩＡＢドナーのＤＵ（例えば、親ＩＡＢノードのＤＵ）の間のＲＬＦと見なし得る。ＵＥとｇＮＢ間の既存のＲＬＦを使用した場合とまったく同じように理解し得る。したがって、ＢＨ ＲＬＦは、無線バックホールリンクにおけるＲＬＦとしてモデル化される。

提案３：ＲＡＮ２は、ＢＨ ＲＬＦに既存のＲＬＦメカニズムの再利用に同意すべきである。

提案３に同意できる場合、現在のＵＥの動作はＲＬＦを宣言した後でも、つまりＲＲＣ再確立を開始するためにＲＲＣ接続を維持するため、ＲＬＦでサービスを実際に停止する必要があるかどうかは疑問である。ＵＥがＲＲＣ接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、ＩＡＢノードは、ＭＴがＲＲＣ ＩＤＬＥに入った場合、つまりＲＲＣ再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。

提案４：ＲＡＮ２は、ＭＴがＲＬＦを宣言した場合ではなく、ＭＴがＲＲＣ ＩＤＬＥに入った場合、ＩＡＢノードのＤＵが「サービス」を停止することに同意すべきである。

上記のように、選択肢１は、Ｒｅｌ−１５のＵＥを含むあらゆる種類のケースとデバイスをカバーするための基盤であり、サービスの迅速な回復などの点で最良の解決策を意味するものではない。そのため、他の選択肢は選択肢１に加えて有益であり、このＷＩで指定される他の多くの機能がある。

所見１：選択肢１の上にある他の選択肢は、サービス品質をさらに向上させるという点で依然として有益である。

２．２．ＩＡＢノードはダウンストリームノードに通知する（選択肢２、選択肢４）
子ＩＡＢノードが回復手順を迅速及び／又は効率的に開始することを容易にするため、親ＩＡＢノードがそのＢＨ ＲＬＦに関連する情報を子ＩＡＢノードに通知することは役立つ。ＴＲは、「アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する」（選択肢２）のような可能な情報要素、又は「親ノードとして機能できないノードのリストを含むバックホール障害に関する」（選択肢４）情報をキャプチャする。

ただし、親ＩＡＢノードでＢＨ ＲＬＦが発生した場合に、子ＩＡＢノードにそのような情報を提供する方法は不明確である。研究項目は、「ＲＡＮ−３は将来の規範的段階にアーキテクチャ１ａを推奨する」と結論付けた。これは、ＩＡＢノードがＤＵとＭＴで構成され、ＩＡＢドナーが（ＤＵと）ＣＵで構成されることを意味する。ＣＵはＤＵとＣＵとの間のＲＲＣを担当し、ＢＨ ＲＬＦはＭＴのＲＲＣで検出される。そのため、考慮すべき２つの異なるＲＲＣがある。親ＩＡＢノードのＭＴ上におけるＲＲＣは、ＢＨ ＲＬＦを検出し、ＩＡＢドナーの異なるＲＲＣは子ＩＡＢノードに送信されるＲＲＣメッセージを生成する。

物理的な無線リンクがＢＨ ＲＬＦで切断されることを考慮すると、ダウンストリームノードへの情報はＲＲＣメッセージで伝達でない。つまり、ＣＵによって生成されたＲＲＣメッセージはＢＨ ＲＬＦのためにＤＵに到達できない。（選択肢２の）「警告」は、ＭＡＣ ＣＥなどで送信してもよいが、ＲＲＣメッセージを使用しなければ、（選択肢４の）「ノードのリスト」は大きすぎ、フレキシブルすぎる。そのため、選択肢２及び／又は選択肢４が導入された場合、ＲＡＮ２は最初にどのシグナリングが使用されるかを検討すべきである。

所見２：ＣＵへの物理的な無線リンクが切断されているため、ＩＡＢノードのＤＵはＲＲＣメッセージを使用しなくてもよい。

この情報はＲｅｌ−１６の機能として提供されることは明らかである。つまり、ＩＡＢノード間でのみサポートされ得る。つまり、Ｒｅｌ−１５のＵＥではサポートされない。

所見３：選択肢２及び選択肢４は、Ｒｅｌ−１６のＩＡＢノードの復旧手順でのみ機能する。

２．３．全てのＩＡＢノードは定期的に情報を共有する（選択肢３）
選択肢３では、ＩＡＢノードは共有される情報に基づいてＢＨ ＲＬＦを検知できる。ＴＲでキャプチャされる情報は、例えば、「ＢＨ品質」である。これは、Ｆ１の既存のＧＮＢ−ＤＵステータス表示である場合とＤＵ間の新しいシグナリングである場合があってもよい。

所見４：選択肢３はＲＡＮ２の範囲外である可能性がある。

２．４．代替リンクの事前準備（選択肢５）
選択肢５は、例えば、マルチコネクティビティ（ＭＮ／ＳＮロール変更あり）、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。ＴＲで「他のＲｅｌ−１６のＷＩの一部として定義された追加の機能／拡張機能を活用してもよい」と述べられているように、選択肢５は、このＷＩ又は他のＷＩの他のトピックで議論される結果を再利用してもよい。

所見５：選択肢５は、このＷＩ又は他のＷＩでの他のトピックで議論される解決策を再利用してもよい。

［付記４］
１．序論
統合されたアクセス及びバックホールの新しいワークアイテムはＲＡＮ#８２で承認され、マルチホップ無線バックホールの低レイテンシスケジューリングは特定されると見なされる。

アーキテクチャ１ａに続くＩＡＢノードの仕様
・[…]
・マルチホップトポロジ全体での低レイテンシスケジューリング、ＢＨ ＲＬＦ処理、及びリソース調整をサポートするためのシグナリングのｈｏｐ−ｂｙ−ｈｏｐ伝搬。

この寄書では、低レイテンシスケジューリングの解決策について議論する。

２．議論
この研究項目は、ＴＲ ３８．８７のセクション８．６でキャプチャされた図２２に示すようなマルチホップバックホールのシーケンス手順によるＵＬスケジューリングのレイテンシの問題を特定した。

ＴＲはまた、「このような遅延を緩和する１つのアプローチは、到着が予想されるデータに基づいてＩＡＢノードでアップリンクリソース要求を開始することで構成される。これにより、ＩＡＢノードは、子ＩＡＢノード又はそれがサービスを提供するＵＥから実際のデータを受信する前に、アップリンクリソースを取得できるようになる。」、及び「ＳＲ／ＢＳＲ及びＵＬスケジューリングの内容及びトリガの詳細は、ＷＩ段階に残される。」という考えられるメカニズムを特定する。

詳細に飛ぶ前に、前提条件に応じて解決策が多少異なるため、拡張が動的割り当てに必要か、設定されたグラントに必要か、又はその両方に必要かを明確にすべきである。上記のＴＲの論述は、動的リソース割り当ての使用を意図している可能性がありますが、レイテンシの問題は、設定されるグラントには問題でない場合がありますが、場合によってはスペクトル効率において問題がある場合がある。したがって、ＲＡＮ２は、動的リソース割り当てのためにＳＲ、ＢＳＲ、及び／又はＵＬスケジューリングを拡張すべきである。

提案１：ＲＡＮ２は、マルチホップ無線バックホールでの動的なリソース割り当てのためにＳＲ、ＢＳＲ、及び／又はＵＬスケジューリングを拡張すべきである。

現在の仕様では、次のように通常のＢＳＲ送信用のリソースがない場合にＳＲがトリガされる。

ＭＡＣエンティティ
１＞バッファステータスレポート手順で、少なくとも1つのＢＳＲがトリガされ、キャンセルされていないと判断された場合
[…]
２＞通常のＢＳＲがトリガされ、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−ＤｅｌａｙＴｉｍｅｒが実行されていない場合
３＞新しい送信に利用可能なＵＬ−ＳＣＨリソースがない場合、又は
３＞ＭＡＣエンティティが設定されるアップリンクグラントで設定し、ｌｏｇｉｃａｌＣｈａｎｎｅｌＳＲ−Ｍａｓｋがｆａｌｓｅに設定される論理チャネルに対して通常のＢＳＲがトリガされた場合、又は
３＞新しい伝送に使用可能なＵＬ−ＳＣＨリソースが、ＢＳＲをトリガした論理チャネルに設定されたＬＣＰマッピングの制限（５．４.３．１を参照）を満たさない場合、
４＞スケジューリング要求をトリガする
したがって、重要な問題の１つは、通常のＢＳＲのトリガを高速化する方法である。通常のＢＳＲは、次のように、データが送信可能になるとトリガされる。

ＭＡＣエンティティは、ＴＳ３８．３２２及び３８．３２３のデータ量計算手順に従って、論理チャネルで使用可能なＵＬデータの量を決定する。

次のいずれかのイベントが発生した場合、ＢＳＲがトリガされる。

−ＬＣＧに属する論理チャネルのＵＬデータは、ＭＡＣエンティティで利用可能になる。
−このＵＬデータは、任意のＬＣＧに属する利用可能なＵＬデータを含む論理チャネルの優先度よりも高い優先度を持つ論理チャネルに属する。又は、
−ＬＣＧに属する論理チャネルには、利用可能なＵＬデータが含まれていない。

この場合、ＢＳＲは「通常ＢＳＲ」と呼ばれる。

「アーリー通常ＢＳＲトリガ」を有効にするには、送信可能なデータに追加のルールを設定することが簡単である。現在、このようなデータ量の計算手順はＲＬＣ及びＰＤＣＰレイヤでのみ行われているが、バックホールリンクのＭＴのＭＡＣエンティティは、ＤＵに表示されるＵＬデータ量を何らかの形で考慮すべきである。

提案２：ＲＡＮ２は、ＭＴのＭＡＣエンティティが、同じＩＡＢノードのＤＵで見えるＵＬデータ量を考慮する必要があることに同意すべきである。

提案２に同意できる場合、ＤＵに見えるデータ量のどれがデータ利用可能な送信とみなされるかを検討すべきである。以下の選択肢が考慮される。

選択肢１：ＤＵプロトコルスタックのＭＡＣ、ＲＬＣ、ＰＤＣＰ（及び場合によってはアダプテーションレイヤ）におけるバッファの実際のデータ量。

選択肢２：選択肢１に加えて、子ノード／ＵＥに既にグラントされているデータ量（図２３）。

選択肢３：選択肢２に加えて、子ノード／ＵＥでの送信に利用可能なデータ、つまり子ノード／ＵＥからのＢＳＲのバッファサイズ（図２１）。

レイテンシ削減の観点から、選択肢３は、ＩＡＢノードのＤＵが子ノード／ＵＥからＵＬデータを受信したときにそのＩＡＢノードのＭＴがバックホールリンクのリソースをグラントしたことが予想されるため、最適な解決策である。一方、ＭＴでのＵＬグラントの受信とＤＵでのＵＬデータの受信とが十分に同期されていない限り、リソースの浪費が発生する可能性がある。つまり、オーバースケジューリングが発生する可能性がある。選択肢１はリスクが低いが利益も低くなる。選択肢２は、他の選択肢間のバランスの取れた解決策と見なされる。

提案３：ＲＡＮ２は、送信に利用可能な追加データがＵＥへのＵＬグラント又はＵＥからのＢＳＲに関連するデータ量であるかどうかを議論すべきである。

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

Claims (4)

1. 移動通信システムにおいてユーザ装置からドナー基地局へ送信される上りリンクデータを中継する中継装置を用いる通信制御方法であって、
   前記中継装置が、下位装置から、前記下位装置への上りリンク無線リソースの割り当てを要求する第１スケジューリング要求を受信することと、
   前記中継装置が、前記下位装置から前記第１スケジューリング要求を受信した後、前記下位装置から前記上りリンクデータを受信するよりも前において、前記中継装置への上りリンク無線リソースの割り当てを要求する第２スケジューリング要求を上位装置に送信することと、を含み、
   前記下位装置は、前記ユーザ装置、又は前記ユーザ装置と前記中継装置との間に介在する下位中継装置であり、
   前記上位装置は、前記ドナー基地局、又は前記ドナー基地局と前記中継装置との間に介在する上位中継装置である
   通信制御方法。
2. 前記中継装置が、前記第１スケジューリング要求の受信に応じて、バッファ状態報告の送信に用いる前記上りリンク無線リソースを前記下位装置に割り当てることをさらに含み、
   前記第２スケジューリング要求を送信することは、前記中継装置が前記上りリンク無線リソースを前記下位装置に割り当てた後において行われる
   請求項１に記載の通信制御方法。
3. 移動通信システムにおいてユーザ装置からドナー基地局へ送信される上りリンクデータを中継する中継装置を制御するプロセッサであって、
   下位装置から、前記下位装置への上りリンク無線リソースの割り当てを要求する第１スケジューリング要求を受信する処理と、
   前記下位装置から前記第１スケジューリング要求を受信した後、前記下位装置から前記上りリンクデータを受信するよりも前において、前記中継装置への上りリンク無線リソースの割り当てを要求する第２スケジューリング要求を上位装置に送信する処理と、を実行し、
   前記下位装置は、前記ユーザ装置、又は前記ユーザ装置と前記中継装置との間に介在する下位中継装置であり、
   前記上位装置は、前記ドナー基地局、又は前記ドナー基地局と前記中継装置との間に介在する上位中継装置である
   プロセッサ。
4. 移動通信システムにおいてユーザ装置からドナー基地局へ送信される上りリンクデータを中継する中継装置であって、
   下位装置から、前記下位装置への上りリンク無線リソースの割り当てを要求する第１スケジューリング要求を受信する受信部と
   前記下位装置から前記第１スケジューリング要求を受信した後、前記下位装置から前記上りリンクデータを受信するよりも前において、前記中継装置への上りリンク無線リソースの割り当てを要求する第２スケジューリング要求を上位装置に送信する送信部と、を備え、
   前記下位装置は、前記ユーザ装置、又は前記ユーザ装置と前記中継装置との間に介在する下位中継装置であり、
   前記上位装置は、前記ドナー基地局、又は前記ドナー基地局と前記中継装置との間に介在する上位中継装置である
   中継装置。
   
   

Images