JP7303290B2 - 通信制御方法 - Google Patents

Description

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

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

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

第１の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記上位装置と無線で接続するユーザ装置機能部が、前記下位装置と無線で接続する基地局機能部に対して状態情報を通知することを含む。前記状態情報は、前記ユーザ装置機能部のＲＲＣ状態、及び前記上位装置と前記ユーザ装置機能部との間の無線リンク状態のうち、少なくとも一方の状態を示す情報である。

第２の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置において、前記下位装置と無線で接続する基地局機能部が、前記上位装置と無線で接続するユーザ装置機能部又は前記上位装置を介してドナー装置と通信する通信機能部に対して、状態情報を通知することを含む。前記状態情報は、前記基地局機能部と前記下位装置の間の無線リンク状態を示す情報である。

第３の態様に係る通信制御方法は、上位装置と下位装置との間の通信を無線で中継する中継装置を用いる方法である。前記通信制御方法は、前記中継装置が、前記中継装置に接続する下位装置から、他の中継装置との無線リンク障害の発生を示す通知を受信することと、前記中継装置が、ドナー装置に対して、前記無線リンク障害に関するメッセージを送信することとを含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ここで、ＲＬＦに関連する下位装置の一般的な動作について説明する。図１０に示すように、下位装置は、Ｎ３１０回連続して同期外れ状態（ｏｕｔ－ｏｆ－ｓｙｎｃ）を検知した場合、無線問題（ｒａｄｉｏ ｐｒｏｂｌｅｍ）を検知する。下位装置は、無線問題を検知すると、所定のタイマＴ３１０を開始させる。下位装置は、タイマＴ３１０を開始させた後、Ｎ３１１回連続して同期状態（ｉｎ－ｓｙｎｃ）を検知した場合、タイマＴ３１０を停止させる。下位装置は、タイマＴ３１０が満了すると、ＲＬＦを検知するとともに、タイマＴ３１１を開始し、且つセル再選択動作（接続再確立処理）を開始する。そして、下位装置は、接続再確立に成功せずにタイマＴ３１１が満了すると、ＲＲＣアイドルモードに遷移する。

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

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

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

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

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

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

図１２は、第２実施形態に係る動作シーケンスの一例を示す図である。図１２に示す例において、ＩＡＢノード３００－２は、下位装置としてのＵＥ１００－３と、上位装置としてのＩＡＢノード３００－１とに無線で接続しており、ＵＥ１００－３とＩＡＢノード３００－１との間の通信を無線で中継する。ＩＡＢノード３００－２において、基地局機能部（ＤＵ）はＵＥ１００－３と無線で接続し、ユーザ装置機能部（ＭＴ）はＩＡＢノード３００－１と無線で接続する。

但し、下位装置は、ＩＡＢノードであってもよい。また、ＩＡＢノード３００－２は、ＩＡＢノード３００－１を介さずにドナー装置（ｇＮＢ２００－１）に無線で接続していてもよい。この場合、上位装置とドナー装置とが同じ装置になる。

図１２に示すように、ステップＳ６１１において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＵＥ１００－３との無線リンク障害（ＲＬＦ）を検知する。このようなＲＬＦはＩＡＢノード３００－２の観点で、フロントホール（Ｆｒｏｎｔｈａｕｌ）ＲＬＦと呼ばれてもよい。

ＲＬＦの検知方法は、上述した方法以外に、ＵＥ１００－３からのＡＣＫ／ＮＡＣＫに基づく方法を用いることができる。具体的には、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、例えば下りリンクのＨＡＲＱ再送を行っても、ＡＣＫやＮＡＣＫがＵＥ１００－３から返ってこない場合、ＵＥ１００－３とのＲＬＦを検知する。

ステップＳ６１２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＵＥ１００－３とのＲＬＦを検知したことを示す状態情報（ＲＬＦ通知）をＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）に通知する。この状態情報（ＲＬＦ通知）は、ＵＥ１００－３に関する識別子、例えばＵＥ識別子及び／又はベアラ識別子を含んでもよい。

ステップＳ６１３において、ＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）は、状態情報（ＲＬＦ通知）を含むＲＲＣメッセージを、ＩＡＢノード３００－１を介してドナーｇＮＢ２００－１に送信する。ドナーｇＮＢ２００－１は、このＲＲＣメッセージに含まれる状態情報（ＲＬＦ通知）に基づいて、ＵＥ１００－３に対応するベアラを解放してもよい。

図１２に示すシーケンスを次のように変更してもよい。

具体的には、ステップＳ６１２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＵＥ１００－３とのＲＬＦを検知したことを示す状態情報（ＲＬＦ通知）をＩＡＢノード３００－２のＦ１－ＡＰエンティティに通知する。この状態情報（ＲＬＦ通知）は、ＵＥ１００－３に関する識別子、例えばＵＥ識別子及び／又はベアラ識別子を含んでもよい。Ｆ１－ＡＰエンティティとは、フロントホールのインターフェイスであるＦ１インターフェイス上でドナーｇＮＢ２００－１との通信を行う通信機能部をいう。

ステップＳ６１３において、ＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）は、状態情報（ＲＬＦ通知）を含むＦ１－ＡＰメッセージを、ＩＡＢノード３００－１を介してドナーｇＮＢ２００－１に送信する。ドナーｇＮＢ２００－１は、このＦ１－ＡＰメッセージに含まれる状態情報（ＲＬＦ通知）に基づいて、ＵＥ１００－３に対応するベアラを解放してもよい。

図１２に示すシーケンスを次のように変更してもよい。

具体的には、ステップＳ６１１において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、自身の配下の全ての下位装置がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したことを検知する。

ステップＳ６１２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、自身の配下の全ての下位装置がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移したことを示す状態情報をＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）又はＦ１－ＡＰエンティティに通知する。

ステップＳ６１３において、ＩＡＢノード３００－２のユーザ装置機能部（ＭＴ）又はＦ１－ＡＰエンティティは、基地局機能部（ＤＵ）からの状態情報に基づいて、自身のＲＲＣ接続を解放可能であることを示すＲＡＩ（Ｒｅｌｅａｓｅ Ａｓｓｉｓｔａｎｃｅ Ｉｎｄｉｃａｔｉｏｎ）を、ＩＡＢノード３００－１を介してドナーｇＮＢ２００－１に送信する。ドナーｇＮＢ２００－１は、このＲＡＩに基づいて、ＵＥ１００－３のＲＲＣ接続を解放してもよい。

［第２実施形態の変更例］
第２実施形態において、ＩＡＢノード３００－２は、自身と下位装置との間のＲＬＦをドナーｇＮＢ２００－１に通知していた。しかしながら、下位装置が他のＩＡＢノードとの間で検知したＲＬＦをドナーｇＮＢ２００－１に通知してもよい。

図１３は、第２実施形態の変更例に係る動作シーケンスを示す図である。図１３において、ＩＡＢノード３００－２とドナーｇＮＢ２００－１との間に他のＩＡＢノードが介在してもよい。

図１３に示すように、ステップＳ６２１において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ＩＡＢノード３００－２に接続する下位装置（ＵＥ１００－３）から、ＩＡＢノード３００－３とのＲＬＦの発生を示す通知を受信する。この通知は、ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージ又はＲＬＦ Ｉｎｄｉｃａｔｉｏｎであってもよい。

例えば、ＵＥ１００－３は、ＩＡＢノード３００－３とのＲＬＦを検知し、ＩＡＢノード３００－２との接続再確立を行う。ここで、ＵＥ１００－３は、ＲＲＣ ＲｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージをＩＡＢノード３００－２に送信する。このＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージは、ＵＥ１００－３の識別子だけではなく、ＵＥ１００－３がＩＡＢノード３００－３に接続していたことを示す情報（ＩＡＢノード３００－３の識別子であってもよい）、及び／又は、ＵＥ１００－３がＩＡＢノード３００－３を介して接続していたドナー装置の識別子等を含んでもよい。

或いは、ＵＥ１００－３は、ＩＡＢノード３００－３及び３００－２と同時に接続するデュアルコネクティビティ（ＤＣ）通信中に、ＩＡＢノード３００－３とのＲＬＦを検知し、このＲＬＦに関するＲＬＦ ＩｎｄｉｃａｔｉｏｎをＩＡＢノード３００－２に送信する。ＩＡＢノード３００－３がマスタノード（ＭＮ）として設定されていた場合、このＲＬＦ Ｉｎｄｉｃａｔｉｏｎは、ＭＣＧ（Ｍａｓｔｅｒ Ｃｅｌｌ Ｇｒｏｕｐ） ＲＬＦ Ｉｎｄｉｃａｔｉｏｎと呼ばれてもよい。ＲＬＦ Ｉｎｄｉｃａｔｉｏｎは、ＵＥ１００－３の識別子、ＩＡＢノード３００－３の識別子、ＵＥ１００－３がＩＡＢノード３００－３を介して接続していたドナー装置の識別子等を含んでもよい。

ステップＳ６２２において、ＩＡＢノード３００－２の基地局機能部（ＤＵ）は、ステップＳ６２１でＵＥ１００－３から受信した通知に含まれる情報を、ＩＡＢノード３００－２の端末機能部（ＭＴ）又はＦ１－ＡＰエンティティに通知する。

ステップＳ６２３において、ＩＡＢノード３００－２の端末機能部（ＭＴ）又はＦ１－ＡＰエンティティは、基地局機能部（ＤＵ）から通知された情報を含むメッセージをドナーｇＮＢ２００－１に送信する。このメッセージは、ＲＲＣメッセージ又はＦ１－ＡＰメッセージである。

ドナーｇＮＢ２００－１は、受信したメッセージに含まれる情報に基づいて、ＵＥ１００－３が他のドナー装置の配下にあった、すなわち、他のドナー装置のトポロジに属していたと判定した場合、当該他のドナー装置に対して通知を行ってもよい。この通知は、ＵＥ１００－３の識別子及びＩＡＢノード３００－３の識別子のうち少なくとも一方を含んでもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１５に示すように、ＩＡＢノード３００は、バックホールリンクを介して上位装置Ａと無線で接続している。上位装置Ａは、上位ＩＡＢノード又はドナーｇＮＢ（ドナー装置）である。

ＩＡＢノード３００には下位装置Ｂ１及びＢ２が接続しており、下位装置Ｂ２には下位装置Ｂ３が接続している。下位装置Ｂ４は、ＩＡＢノード３００の配下にない装置である。下位装置Ｂ１乃至Ｂ４は、下位ＩＡＢノード又はＵＥである。以下において、下位装置Ｂ１乃至Ｂ４を特に区別しないときは単に下位装置Ｂと呼ぶ。

第４実施形態において、上位装置Ａと下位装置Ｂとの間の通信を無線で中継するＩＡＢノード３００において、上位装置Ａと無線で接続するユーザ装置機能部（ＭＴ）は、下位装置Ｂと無線で接続する基地局機能部（ＤＵ）に対して状態情報を通知する。

この状態情報は、ユーザ装置機能部（ＭＴ）のＲＲＣ状態、及び上位装置Ａとユーザ装置機能部（ＭＴ）との間の無線リンク状態（以下、バックホールリンク状態と呼ぶ）のうち、少なくとも一方の状態を示す情報である。これにより、基地局機能部（ＤＵ）は、バックホールリンク側の状態を考慮して下位装置Ｂに対するサービス提供を制御できる。

ここで、ユーザ装置機能部（ＭＴ）のＲＲＣ状態は、コネクティッド、インアクティブ、及びアイドルのいずれかである。

バックホールリンク状態は、下記の１）乃至６）のうち少なくとも１つの指標、又はこれらの指標の組み合わせに基づく状態である。

１）ＲＬＦを検知した及びＲＬＦから復帰したなどのＲＬＦ状態
２）ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）などの無線品質
３）ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）再送回数やＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）再送回数などのリンク状態
４）ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）、ＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）、ＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）状況などの混雑度
５）設定されている又は活性化されているセカンダリセル数、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）レイヤ数、割り当て無線リソース状況（例えば、準静的割り当てにおけるＣｏｎｆｉｇｕｒｅｄ ｇｒａｎｔの増減、動的割り当てにおけるＤｙｎａｍｉｃ ｇｒａｎｔの増減）、スループット測定値などの通信容量
６）上りリンクスケジューリング遅延時間の測定値、上りリンクバッファ中のデータ量などの遅延状態。

バックホールリンク状態は、上記１）乃至６）の指標に基づくバックホールリンク状態の良好度合い、例えば、閾値よりも良好又は閾値よりも劣悪といった状態であってもよい。

ユーザ装置機能部（ＭＴ）は、ＲＲＣ状態の変化又はバックホールリンク状態の変化をトリガとして、状態情報を基地局機能部（ＤＵ）に通知してもよい。例えば、ユーザ装置機能部（ＭＴ）は、バックホールリンク状態が閾値条件を満たしたというイベントが発生した際に、状態情報を基地局機能部（ＤＵ）に通知する。

或いは、ユーザ装置機能部（ＭＴ）は、状態情報を基地局機能部（ＤＵ）に周期的に通知してもよい。

基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、下位装置Ｂに対するサービス提供を停止してもよい。下位装置Ｂに対するサービス提供を停止するとは、少なくとも１つの下りリンク無線信号の送信を停止することをいう。基地局機能部（ＤＵ）は、ＰＳＳ（Ｐｒｉｍａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）、ＰＳＳ（Ｓｅｃｏｎｄａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）、ＭＩＢ（Ｍａｓｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）の送信を停止してもよい。

例えば、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合、下位装置Ｂに対するサービス提供を停止してもよい。基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣコネクティッド状態に遷移した場合、下位装置Ｂに対するサービス提供を再開してもよい。

基地局機能部（ＤＵ）は、バックホールリンクが劣化している場合、例えば、バックホールでＲＬＦが検知された場合、下位装置Ｂに対するサービス提供を停止してもよい。基地局機能部（ＤＵ）は、バックホールリンクが良化した場合、下位装置Ｂに対するサービス提供を再開してもよい。

或いは、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、下位装置Ｂに対する無線リソース割り当て（スケジューリング）を制御してもよい。

基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合、下位装置Ｂに対するリソース割当を中止してもよい。なお、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した際に、下位装置Ｂに上りリンクリソースを割り当てている場合がある。この場合、基地局機能部（ＤＵ）は、ＲＲＣコネクティッド状態に遷移するようにユーザ装置機能部（ＭＴ）に要求してもよい。

基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣコネクティッド状態に遷移した場合、下位装置Ｂに対するリソース割当を再開してもよい。

基地局機能部（ＤＵ）は、バックホールリンクが劣化している場合、例えば、バックホールでＲＬＦが検知された場合、下位装置Ｂに対するリソース割当を中止してもよい。基地局機能部（ＤＵ）は、バックホールリンクが良化した場合、例えば、バックホールでＲＬＦから復旧した場合、下位装置Ｂに対するリソース割当を再開してもよい。

或いは、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、バックホールリンクの劣化を示す通知、例えば、バックホールリンクのＲＬＦ発生を示す通知（以下、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎと呼ぶ）を下位装置Ｂに送信してもよい。ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎは、ＩＡＢノード３００の識別子を含んでもよい。以下において、バックホールリンクの劣化を示す通知がＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎである一例について説明する。

基地局機能部（ＤＵ）は、ＲＲＣレイヤよりも下位のレイヤの制御信号によりＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを送信してもよい。基地局機能部（ＤＵ）は下位装置ＢとのＲＲＣ接続を有していないためである。ＲＲＣレイヤよりも下位のレイヤの制御信号は、ＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、ＲＬＣ Ｃｏｎｔｒｏｌ ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）、又はＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）であるが、以下においてはＭＡＣ ＣＥを用いる一例について説明する。

基地局機能部（ＤＵ）は、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎをユニキャストで下位装置Ｂに送信してもよい。或いは、基地局機能部（ＤＵ）は、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎのシグナリング負荷を減らすために、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎをブロードキャスト又はマルチキャストで送信してもよい。ブロードキャスト又はマルチキャストを用いる場合、下位装置Ｂ３及びＢ４は、接続中のセル（上位ＩＡＢノード）からのＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎだけではなく、その他のセルのＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎもモニタすることで、ＩＡＢノード３００からのＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信できる。

基地局機能部（ＤＵ）は、例えば、予め仕様で定められた固定のＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いてＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎをブロードキャストで送信してもよい。基地局機能部（ＤＵ）は、下位装置のグループに割り当てた共通のＲＮＴＩを用いてＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎをマルチキャストで送信してもよい。

なお、ブロードキャスト／マルチキャストと、ユニキャストとを使い分けてもよい。この場合、基地局機能部（ＤＵ）は、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎがブロードキャスト／マルチキャストで送信されるか、ユニキャストで送信されるかをＳＩＢで通知（ブロードキャスト）してもよい。下位装置Ｂは、このＳＩＢに基づいて、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの待ち受けモード、例えば、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎのモニタに用いるＲＮＴＩを変更してもよい。

基地局機能部（ＤＵ）は、バックホールリンクの無線リンク状態が劣化している期間、例えば、バックホールリンクのＲＬＦが発生している期間内において、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを周期的に送信してもよい。この場合、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎが周期的に送信される期間内では、ＲＬＦが発生していることになる。或いは、基地局機能部（ＤＵ）は、バックホールリンクのＲＬＦが発生した際にＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを送信し、バックホールリンクのＲＬＦから復旧した際に復旧を示す通知を送信してもよい。以下においては、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信により、バックホールリンクのＲＬＦの発生及びＲＬＦからの復旧を下位装置に示す一例について主として説明する。

下位装置Ｂは、ＩＡＢノード３００からＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信する期間内では、バックホールリンクのＲＬＦが発生していると判定する。ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの送信周期は、ドナー装置からＩＡＢノード３００のユーザ装置機能部（ＭＴ）を介して基地局機能部（ＤＵ）に設定されてもよい。

ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎがマルチキャストで送信される場合、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００に対するＡＣＫ／ＮＡＣＫフィードバックの送信を開始してもよい。ＩＡＢノード３００は、配下の全ての下位装置Ｂ１乃至Ｂ３からＡＣＫを受信した場合、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信を停止してもよい。

ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を行ってもよい。このような処理としては、例えば、接続再確立処理、条件付きハンドオーバのトリガ処理、通信経路切替処理、ハンドオーバ用の測定報告処理が挙げられる。なお、下位装置Ｂ１乃至Ｂ３は、このような切り替え処理を開始した後、切り替え処理を完了するまでの間において、ＩＡＢノード３００からのＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信しなくなった場合（又はバックホールＲＬＦの復旧を示す通知を受信した場合）、ＩＡＢノード３００のバックホールリンクが復旧したと判定し、切り替え処理を中止してもよい。

例えば、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、ＩＡＢノード３００のセル以外のセルを探索するセルサーチを行い、適切なセルに対して接続再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）を行う。ここで、下位装置Ｂ１乃至Ｂ３とＩＡＢノード３００との間でＲＬＦが発生していなくても、このような接続再確立処理を早期に行う。

接続再確立処理は、時間的に分散して実行するように制御されていてもよい。例えば、下位装置Ｂ１乃至Ｂ３は、ランダム値やＵＥ－ＩＤを用いて接続再確立処理の実行開始時間を決定することにより、下位装置Ｂ１乃至Ｂ３の接続再確立処理の実行開始時間を分散させ、負荷の集中を防ぐことができる。なお、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎがユニキャストで送信される場合、基地局機能部（ＤＵ）がＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの送信タイミングを分散させることにより、下位装置Ｂ１乃至Ｂ３の接続再確立処理の実行開始時間を分散させてもよい。

ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、自身がＩＡＢノード３００と、ＩＡＢノード３００以外の上位装置とに接続してＤＣ通信を行っている場合、ＩＡＢノード３００を経由する通信経路を他の上位装置に切り替えてもよいし、他の通信装置にＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを送信してもよい。例えば、下位装置Ｂは、ＩＡＢノード３００をマスタノード（ＭＮ）として設定し、他の上位装置をバックアップ用のセカンダリノード（ＳＮ）として設定している場合、ＭＮを経由する通信経路をＳＮに切り替える。

ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、自身に条件付きハンドオーバが設定されている場合、条件が満たされたとみなして、ハンドオーバを行ってもよい。ハンドオーバ条件がサービングセルの無線品質劣化を示すイベントである場合、サービングセルの無線品質測定結果を低く修正する（例えば、－２００ｄＢｍとみなす）ことにより、強制的にハンドオーバをトリガしてもよい。

ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、測定報告の送信をトリガしてもよい。ここで、一般的な測定報告はＲＲＣメッセージで送信されるが、基地局機能部（ＤＵ）はＲＲＣレイヤを有していない。このため、ＩＡＢノード３００は、バックホールリンクのＲＬＦから復旧するまでは下位装置Ｂからの測定報告を保持し、バックホールリンクのＲＬＦから（一時的に）復旧した際にドナー装置に転送し、ドナー装置が下位装置Ｂをハンドオーバさせてもよい。

ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ４は、接続先の候補としてＩＡＢノード３００を除外するための処理を行ってもよい。例えば、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ４は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態におけるセル再選択動作において、ＩＡＢノード３００のセルの優先度を下げる、もしくは再選択対象から除外する、もしくはＩＡＢノード３００についての受信電力測定値を低く調整する。これにより、接続先の候補としてＩＡＢノード３００が除外されるようにしてもよい。ここで、受信電力測定値を低く調整するために、実際の受信電力測定値に対してオフセット値を適用してもよい。当該オフセット値は予め決められた固定値であってもよい。もしくは当該オフセット値はネットワークから通知された値であってもよく、当該通知は下位装置Ｂ４が現在キャンプしているセルの報知情報（ＳＩＢ）によって通知されてもよい。

下位装置Ｂ４は、接続先の候補としてＩＡＢノード３００を除外するための処理を、ＲＲＣコネクティッド状態に遷移する際のＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ処理又はＲＲＣ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ処理を開始する前のタイミングで行ってもよい。

具体的には、下位装置Ｂ４は、ＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを送信する前に、送信先候補のセルがＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを通知しているか否かの確認を行う。下位装置Ｂ４は、送信先候補のセルがＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを通知していない場合はＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを送信する。送信先候補のセルがＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを通知している場合はＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔの送信を停止（もしくは中止）し、前記セル再選択動作を行うことにより、適切なＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ送信先を選択する。

下位装置Ｂ４は、ＩＡＢノード３００からのＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信しなくなった場合（又はバックホールＲＬＦの復旧を示す通知を受信した場合）、ＩＡＢノード３００のバックホールリンクが復旧したと判定し、接続先の候補としてＩＡＢノード３００を除外するための処理を中止してもよい。

図１６は、第４実施形態に係る動作の一例を示す図である。図１６において、ＩＡＢノード（Ｐａｒｅｎｔ ＩＡＢ ｎｏｄｅ）３００とドナーｇＮＢ（ＩＡＢ ｄｏｎｏｒ）２００との間に他のＩＡＢノードが介在してもよい。

図１６に示すように、ステップＳ８０１において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、無線問題（ｒａｄｉｏ ｐｒｏｂｌｅｍ）を検知する。

ステップＳ８０２において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＬＦを検知する（ＲＬＦ ｄｅｃｌａｒａｔｉｏｎ）。

ステップＳ８０３において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＬＦの発生を示す状態情報をＩＡＢノード３００の基地局機能部（ＤＵ）に通知する。

ステップＳ８０４において、ＩＡＢノード３００の基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの通知に応じて、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信を開始する。

ステップＳ８０５において、ＲＬＦ ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を開始する。このような処理としては、例えば、接続再確立処理（Ｅａｒｌｙ ＲＲＣ Ｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）、条件付きハンドオーバのトリガ処理（Ｔｒｉｇｇｅｒｉｎｇ Ｃｏｎｄｉｔｉｏｎａｌ ＨＯ）、通信経路切替処理（Ｓｗｉｔｃｈｉｎｇ ｔｏ ｒｅｄｕｎｄａｎｔ ｒｏｕｔｅ）が挙げられる。

ステップＳ８０６において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、例えばＴ３１０動作中に接続再確立を行うことができず、Ｔ３１０の満了に応じてＲＲＣアイドル状態に遷移する（Ｇｏ ｔｏ ＩＤＬＥ）。

ステップＳ８０７において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＲＣアイドル状態への遷移を示す状態情報をＩＡＢノード３００の基地局機能部（ＤＵ）に通知する。

ステップＳ８０８において、ＩＡＢノード３００の基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの通知に応じて、下位装置Ｂへのサービス提供を停止する（Ｓｅｒｖｉｃｅ ｓｔｏｐｐｅｄ）。

ステップＳ８０９において、下位装置Ｂは、ＩＡＢノード３００からのサービス提供が停止されたことにより、ＲＬＦを検知する。

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

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

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

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

以下を含むアーキテクチャ1aに続くＩＡＢノードの仕様
・[…]
・低遅延スケジューリング、ＢＨ ＲＬＦ処理、及びマルチホップトポロジ全体のリソース調整をサポートするためのシグナリングのホップバイホップ伝搬。
・[…]
Ｌ２トランスポート及びリソース管理のシグナリングの仕様
・[…]
・ＢＨ ＲＬＦ処理の仕様（例：ダウンストリームＢＨ ＲＬＦ通知）
この付記では、研究項目からの結果に加えてＢＨ ＲＬＦ処理の最初の考慮が議論される。

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

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

９．７．１４アーキテクチャ１ａにおけるＢＨ ＲＬＦのダウンストリーム通知
「選択肢１：ＩＡＢノードＤＵはサービスを中止する。その結果、子ノードもＢＨ ＲＬＦを決定し、上記の手順に従って回復する。」
「選択肢２：ＩＡＢノードＤＵは、アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する。この警告を受信した子ＩＡＢノードは、警告をさらに下流に転送し得る。このような警告を受信した各ＩＡＢノードは、上記のＢＨ－ＲＬＦ回復を開始する。」
「選択肢３：全てのＩＡＢノードは、ＢＨ品質などに関する情報を子又は親のＩＡＢノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームＲＬＦを検知し得る。」
９．７．１５効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームＩＡＢノードに提供され得る。」（選択肢４）
「事前（つまり、ＲＬＦの発生前）における代替バックホールリンクとルートの準備」（選択肢５）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

したがって、重要な問題の１つは、通常のＢＳＲのトリガを高速化する方法である。通常のＢＳＲは、次のように、データが送信可能になるとトリガされる。

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

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

－ＬＣＧに属する論理チャネルのＵＬデータは、ＭＡＣエンティティで利用可能になる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

９．７．１４アーキテクチャ１ａにおけるＢＨ ＲＬＦのダウンストリーム通知
「選択肢１：ＩＡＢノードＤＵはサービスを中止する。その結果、子ノードもＢＨ ＲＬＦを決定し、上記の手順に従って回復する。」
「選択肢２：ＩＡＢノードＤＵは、アップストリームＲＬＦについて子ＩＡＢノードに明示的に警告する。この警告を受信した子ＩＡＢノードは、警告をさらに下流に転送し得る。このような警告を受信した各ＩＡＢノードは、上記のＢＨ－ＲＬＦ回復を開始する。」
「選択肢３：全てのＩＡＢノードは、ＢＨ品質などに関する情報を子又は親のＩＡＢノードと定期的に共有し得る。このようにして、明示的な動作を実行しなくても、ダウンストリーム又はアップストリームＲＬＦを検知し得る。」
９．７．１５効率的なバックホールリンク障害の復旧
「バックホール障害のために親ノードとして機能できないノードのリストを含む、バックホール障害に関する情報は、ダウンストリームＩＡＢノードに提供され得る。」（選択肢４）
「事前（つまり、ＲＬＦの発生前）における代替バックホールリンクとルートの準備」（選択肢５）

Ｒ２は、少なくともダウンストリームノードへのＢＨ Ｌｉｎｋ ＲＬＦでＲＬＦ通知があると想定する。

代替リンク及び／又はデュアルコネクティビティ（合意されている場合）は、ＢＨ Ｌｉｎｋの障害時の復旧時に利用され得る。

現在のＵＥ ＲＬＦ検出及び回復は、ベースラインとして再利用される。

例えば、リンクが回復したとき、または回復が進行中のとき、他の表示が必要かどうかは更なる検討が必要である。

これらの合意は、上記の選択肢２，４，５に基づいており、追加の側面も含まれる。

２．２．ＩＡＢノードがサービスを中止する（選択肢１）
選択肢１は、ＢＨ ＲＬＦ情報が子ＩＡＢノード及びＵＥに暗示的に伝搬されるため、セクション９．７．１４と９．７．１５との間の共通の問題のための一般的な解決策と見なし得る。合意された「ＲＬＦ通知」はＲｅｌ－１６の機能だが、Ｒｅｌ－１５ ＵＥは、ＩＡＢノードとの接続をまだ許可される。Ｒｅｌ－１５ ＵＥの場合でもサービスの中断を最小限に抑えるには、ＢＨ ＲＬＦの問題のためのベースラインの解決策として選択肢１を指定すべきである。

所見１：合意された「ＲＬＦ通知」は、Ｒｅｌ－１５ ＵＥの観点からＢＨ ＲＬＦの問題を解決できない。

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

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

提案１に同意できる場合、ＲＡＮ２はすでに「ＢＨ Ｌｉｎｋ ＲＬＦでのＲＬＦ通知」を想定しており、また、現在のＵＥの動作はＲＬＦを宣言した後でも、つまりＲＲＣ再確立を開始するためにＲＲＣ接続を維持するため、ＲＬＦでサービスを実際に停止する必要があるかどうかは疑問である。ＵＥがＲＲＣ接続を正常に再確立すると、最小の中断時間でサービスが回復する。そのため、ＩＡＢノードは、ＭＴがＲＲＣ ＩＤＬＥに入った場合、つまりＲＲＣ再確立が失敗した場合にのみ、「サービス」を停止すべきであることが分かる。この意味では、ＭＴが（同じＩＡＢノードの）ＤＵにＲＲＣ ＩＤＬＥに入ること（セットアップ段階でＲＲＣ Ｃｏｎｎｅｃｔｅｄに移行する可能性もあること）を通知するのは自然である。

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

提案３：提案２に同意できる場合、ＲＡＮ２は、ＭＴがＲＲＣ ＩＤＬＥに入った場合、ＭＴが（同じＩＡＢノードの）ＤＵに通知する必要があるかどうかについてさらに議論する。

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

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

物理的な無線リンクがＢＨ ＲＬＦで切断されることを考慮すると、ダウンストリームノードへの情報はＲＲＣメッセージで伝達できない。つまり、ＣＵによって生成されたＲＲＣメッセージはＢＨ ＲＬＦのためにＤＵに到達できない。（選択肢２の）「警告」は、ＭＡＣ ＣＥで送信されてもよいが、ＭＡＣ ＣＥは「ノードのリスト」（選択肢４）を伝えるのに適切ではない。したがって、ＲＡＮ２は選択肢２をＭＡＣ ＣＥで想定し、選択肢４を考慮すべきではない。

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

提案４：ＲＡＮ２は、ダウンストリームノードへのＲＬＦ通知がＭＡＣ ＣＥを介して送信されるかどうかを議論すべきである。

ＲＬＦ通知がいつ/どのようにトリガされるかについても議論されるだろう。情報の名前を考慮すると、ＢＨ ＲＬＦがＭＴで宣言された時にＲＬＦ通知が送信されるのが素直である。この場合、ＤＵはＢＨ ＲＬＦに従ってＲＬＦ通知を生成／送信する必要があるため、ＭＴはＲＬＦ宣言を（同じＩＡＢノードの）ＤＵに通知すべきである。前のセクションの提案２に同意できる場合、ＢＨ ＲＬＦ、つまりＩＡＢノードがＲＬＦ通知を送信するだけの場合、「サービス」が継続し、ＭＴがＲＲＣ ＩＤＬＥに入ると「サービス」が停止する。

提案５：ＲＡＮ２は、ＤＵがＭＴによってＲＬＦを通知されるとＲＬＦ通知が送信されることに同意すべきである。

もう１つの疑問は、ＲＬＦ通知の受信時の（子ＩＡＢノードの）ＭＴ動作である。ＭＴが何らかの回復手順を開始することは想定し得るが、それはＭＴがＲＬＦを宣言する「前の」プロセスであるべきである。つまり、ＲＬＦ通知は、子ノードのＲＬＦをすぐにトリガすべきではない。なぜなら、ＲＬＦの宣言により、さらにダウンストリームノードへのＲＬＦ通知がトリガされ、ＲＬＦ通知は間もなくＩＡＢトポロジ間で伝搬されるからである。不要なトポロジ適応のストリームが発生し、最悪の場合はＩＡＢトポロジが破損する可能性がある。

提案６：ＲＡＮ２は、ＭＴ/ＵＥがＲＬＦ通知の受信時にＲＬＦを宣言せず、何らかのバックホールリンクの回復を開始するだけであることに同意すべきである。

ＲＡＮ２は、「Ｒ２は、少なくともダウンリンクノードへのＢＨ Ｌｉｎｋ ＲＬＦでＲＬＦ通知があると想定する」ことに同意した。これにより、「ダウンストリームノード」とは、親ノードに直接接続されている子ノード/ＵＥを意味することが自然である。ただし、「ダウンストリームノード」に、親と直接接続していない孫ノード／ＵＥ（つまり、親は孫の観点から祖父母である）も含まれているかどうかは明確ではない。

孫がＲＬＦ通知を受信できる場合、ＲＬＦ通知の伝播遅延がなくなるため、トポロジの回復が速くなるという利点がある。さらに、副産物として、任意のＩＤＬＥノード／ＵＥがＲＬＦ通知を受信できる場合、再選択の際に考慮される可能性がある。これにより、ノード／ＵＥは、ドナーノードに接続できないため、セルのランクが最高であっても、ＢＨ ＲＬＦが発生するセルの再選択または接続を回避するよう試みることができる。欠点は、トポロジの適応と管理が複雑になることである。例えば、極端な場合、ＩＡＢトポロジ内の全てのノード／ＵＥが１つのノードからＲＬＦ通知を受信して回復手順を開始すると、多くの不必要なトポロジ変更が行われる可能性があり、最悪の場合、ＩＡＢトポロジが破損する。したがって、上記の長所と短所を考慮して、ＲＬＦ通知を子ノードのみが受信するかどうかを検討すべきである。

提案７：ＲＡＮ２は、ＲＬＦ通知を子ノードのみが受信するか、孫ノードも受信するかを明確にすべきである。

前回の会議では、ＲＡＮ２は「例えば、リンクが回復したとき、または回復が進行中のとき、他の指示が必要かどうかはさらに検討する必要がある」とした。

子ＩＡＢノード又はＵＥの観点から、ＲＬＦ通知が受信されると、何らかのトポロジ適応手順、例えば、他のＩＡＢノードへのＲＲＣ再確立、又は冗長ルートへのプライマリパスの切り替えが開始される。この意味では、バックホールの「リンクが回復した」という情報は、トポロジ適応手順が完了していない場合、例えばＲＲＣ再確立手順で適切なセルが見つからない場合、手順を停止できるため有益である。ただし、ＲＬＦ通知がＢＨ ＲＬＦ中に繰り返し送信される場合、任意の「他の指示」を規定する必要はない。ＲＬＦ通知が送信されない場合、ＢＨ ＲＬＦは発生していないことになるからだ。そうでない場合、「サービス」が停止する。したがって、問題は、ＢＨ ＲＬＦ中にＲＬＦ通知を繰り返し送信するかどうかである。

提案８：ＲＡＮ２は、ＢＨ ＲＬＦ中にＲＬＦ通知が繰り返し送信されるかどうかを議論すべきである。

他の例、つまり「回復が進行中」については、子ノード／ＵＥの動作は不明確である。子ノード／ＵＥをしばらく待機させることだけを意味する場合、ダウンストリームノードへの何らの指示も（ＲＬＦ通知さえ）必要としない可能性がある。したがって、この時点で導入する動機はない。

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

２．５．代替リンクの事前準備（選択肢５）
選択肢５は、例えば、マルチコネクティビティ（ＭＮ／ＳＮロール変更あり）、条件付きハンドオーバ、又は通常のトポロジ適応又はモビリティ拡張に関連するその他の技術を利用することを目的とする場合がある。ＴＲで「他のＲｅｌ－１６のＷＩの一部として定義された追加の機能／拡張機能を活用してもよい」と述べられているように、選択肢５は、このＷＩ又は他のＷＩの他のトピックで議論される結果を再利用してもよい。ＲＬＦ通知が「ＭＣＧ Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ」などの特定の動作をトリガするかどうかなど、ＩＡＢ固有の影響のみが（ある場合）後で議論されるだろう。

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

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

Claims (3)

1. 上位装置と下位装置との間の通信を無線で中継する第１中継装置に用いられる通信制御方法であって、
   前記第１中継装置が、前記第１中継装置の上位装置である第２中継装置から、前記第２中継装置と前記第２中継装置の上位装置との間の無線リンク状態の劣化を示す通知を受信することと、
   前記第１中継装置が、前記第１中継装置に条件付きハンドオーバが設定されている場合、前記通知の受信に応じて、ハンドオーバを行うことと、
   前記第１中継装置が、前記第２中継装置とは異なる第３中継装置とに接続してデュアルコネクティビティ通信を行っている場合、前記通知の受信に応じて、アップストリームの通信経路を前記第２中継装置から前記第３中継装置に切り替える切り替え処理を行うことと、
   前記第１中継装置が、前記通知を受信した後、前記第２中継装置から、前記無線リンク状態の復旧を示す通知を受信した場合、前記切り替え処理を中止することと、を含む
   通信制御方法。
2. 上位装置と下位装置との間の通信を無線で中継する第１中継装置であって、
   前記第１中継装置の上位装置である第２中継装置から、前記第２中継装置と前記第２中継装置の上位装置との間の無線リンク状態の劣化を示す通知を受信する受信部と、
   前記第１中継装置に条件付きハンドオーバが設定されている場合、前記通知の受信に応じて、ハンドオーバを行う制御部と、を備え、
   前記制御部は、前記第２中継装置とは異なる第３中継装置とに接続してデュアルコネクティビティ通信を行っている場合、前記通知の受信に応じて、アップストリームの通信経路を前記第２中継装置から前記第３中継装置に切り替える切り替え処理を行い、
   前記制御部は、前記通知を受信した後、前記第２中継装置から、前記無線リンク状態の復旧を示す通知を受信した場合、前記切り替え処理を中止する
   第１中継装置。
3. 上位装置と下位装置との間の通信を無線で中継する第１中継装置を制御するプロセッサであって、
   前記第１中継装置の上位装置である第２中継装置から、前記第２中継装置と前記第２中継装置の上位装置との間の無線リンク状態の劣化を示す通知を受信する処理と、
   前記第１中継装置に条件付きハンドオーバが設定されている場合、前記通知の受信に応じて、ハンドオーバを行う処理と、
   前記第２中継装置とは異なる第３中継装置とに接続してデュアルコネクティビティ通信を行っている場合、前記通知の受信に応じて、アップストリームの通信経路を前記第２中継装置から前記第３中継装置に切り替える処理と、
   前記第１中継装置が、前記通知を受信した後、前記第２中継装置から、前記無線リンク状態の復旧を示す通知を受信した場合、前記切り替える処理を中止する処理と、を実行する
   プロセッサ。

Images