(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023120360
(43)【公開日】2023-08-29
(54)【発明の名称】通信制御方法
(51)【国際特許分類】
H04W 36/30 20090101AFI20230822BHJP
H04W 16/26 20090101ALI20230822BHJP
【ＦＩ】
H04W36/30
H04W16/26
【審査請求】有
【請求項の数】4
【出願形態】ＯＬ
(21)【出願番号】P 2023101502
(22)【出願日】2023-06-21
(62)【分割の表示】P 2021537700の分割
【原出願日】2020-07-22
(31)【優先権主張番号】62/884,268
(32)【優先日】2019-08-08
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．３ＧＰＰ
(71)【出願人】
【識別番号】000006633
【氏名又は名称】京セラ株式会社
(74)【代理人】
【識別番号】110001106
【氏名又は名称】弁理士法人キュリーズ
(72)【発明者】
【氏名】藤代 真人
(72)【発明者】
【氏名】チャン ヘンリー
(57)【要約】 （修正有）
【課題】第１の態様に係る通信制御方法は、ユーザ装置とドナー装置との間に複数の中継装置を用いた少なくとも１つの通信経路を形成可能な移動通信システムにおいて用いる通信制御方法を提供する。
【解決手段】通信制御方法は、複数の中継装置に含まれる中継装置（ＩＡＢノード３００）が、上位の上位装置と中継装置との間のバックホールリンクの障害を検知することと、バックホールリンクの障害の検知に応じて、中継装置が、バックホールリンクの障害に関する障害通知を中継装置の下位の下位装置に送信することと、下位装置が、中継装置からの障害通知の受信に応じて、中継装置に対する上りリンク送信を停止することと、を有する。
【選択図】図６
【解決手段】通信制御方法は、複数の中継装置に含まれる中継装置（ＩＡＢノード３００）が、上位の上位装置と中継装置との間のバックホールリンクの障害を検知することと、バックホールリンクの障害の検知に応じて、中継装置が、バックホールリンクの障害に関する障害通知を中継装置の下位の下位装置に送信することと、下位装置が、中継装置からの障害通知の受信に応じて、中継装置に対する上りリンク送信を停止することと、を有する。
【選択図】図６
【特許請求の範囲】
【請求項1】
ユーザ装置とドナー装置との間に複数の中継装置を用いた少なくとも１つの通信経路を形成可能な移動通信システムにおいて用いる通信制御方法であって、
前記複数の中継装置に含まれる第１中継装置が、バックホールリンクにおける障害の発生を示す第１障害通知を第１上位装置から受信することと、
前記第１中継装置が、前記第１障害通知を受信したことに応じて、前記第１上位装置を経由する第１通信経路から、前記第１上位装置とは異なる第２上位装置を経由する第２通信経路に切り替えることと、を有する
通信制御方法。
前記複数の中継装置に含まれる第１中継装置が、バックホールリンクにおける障害の発生を示す第１障害通知を第１上位装置から受信することと、
前記第１中継装置が、前記第１障害通知を受信したことに応じて、前記第１上位装置を経由する第１通信経路から、前記第１上位装置とは異なる第２上位装置を経由する第２通信経路に切り替えることと、を有する
通信制御方法。
【請求項2】
前記第１中継装置が、前記第１上位装置から、前記障害から復旧したことを示す復旧通知を受信することと、
前記第１中継装置が、前記復旧通知の受信に応じて、前記第２通信経路から前記第１通信経路に切り替えることと、
を有する請求項１記載の通信制御方法。
前記第１中継装置が、前記復旧通知の受信に応じて、前記第２通信経路から前記第１通信経路に切り替えることと、
を有する請求項１記載の通信制御方法。
【請求項3】
ユーザ装置とドナー装置との間に複数の中継装置を用いた少なくとも１つの通信経路を形成可能な移動通信システムにおける、前記複数の中継装置に含まれる第１中継装置であって、
バックホールリンクにおける障害の発生を示す第１障害通知を第１上位装置から受信する受信部と、
前記第１障害通知を受信したことに応じて、前記第１上位装置を経由する第１通信経路から、前記第１上位装置とは異なる第２上位装置を経由する第２通信経路に切り替える制御部と、を備える
第１中継装置。
バックホールリンクにおける障害の発生を示す第１障害通知を第１上位装置から受信する受信部と、
前記第１障害通知を受信したことに応じて、前記第１上位装置を経由する第１通信経路から、前記第１上位装置とは異なる第２上位装置を経由する第２通信経路に切り替える制御部と、を備える
第１中継装置。
【請求項4】
ユーザ装置とドナー装置との間に複数の中継装置を用いた少なくとも１つの通信経路を形成可能な移動通信システムにおける、前記複数の中継装置に含まれる第１中継装置を制御するプロセッサであって、
バックホールリンクにおける障害の発生を示す第１障害通知を第１上位装置から受信する処理と、
前記第１障害通知を受信したことに応じて、前記第１上位装置を経由する第１通信経路から、前記第１上位装置とは異なる第２上位装置を経由する第２通信経路に切り替える処理と、を実行する
プロセッサ。
バックホールリンクにおける障害の発生を示す第１障害通知を第１上位装置から受信する処理と、
前記第１障害通知を受信したことに応じて、前記第１上位装置を経由する第１通信経路から、前記第１上位装置とは異なる第２上位装置を経由する第２通信経路に切り替える処理と、を実行する
プロセッサ。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、移動通信システムに用いられる通信制御方法に関する。
【背景技術】
【0002】
移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと称される新たな中継装置が検討されている。１又は複数の中継装置が基地局とユーザ機器との間の通信に介在し、この通信に対する中継を行う。
【0003】
このような中継装置は、ユーザ機器機能及び基地局機能を有しており、ユーザ機器機能を用いて上位ノード（基地局又は上位の中継装置）との無線通信を行うとともに、基地局機能を用いて下位ノード（ユーザ機器又は下位の中継装置）との無線通信を行う。
【0004】
ユーザ機器と、中継装置又は基地局との間の無線区間は、アクセスリンクと称されることがある。中継装置と、基地局又は他の中継装置との間の無線区間は、バックホールリンクと称されることがある。３ＧＰＰ寄書「ＲＰ－１７０２１７」には、アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクに動的に無線リソースを割り当てることにより、通信経路を動的に切り替える方法が記載されている。
【発明の概要】
【0005】
第１の態様に係る通信制御方法は、ユーザ装置とドナー装置との間に複数の中継装置を用いた少なくとも１つの通信経路を形成可能な移動通信システムにおいて用いる方法である。前記通信制御方法は、前記複数の中継装置に含まれる中継装置が、前記中継装置の上位の上位装置と前記中継装置との間のバックホールリンクの障害を検知することと、前記バックホールリンクの障害の検知に応じて、前記中継装置のＢＡＰレイヤが、前記バックホールリンクの障害に関する障害通知を前記中継装置の下位の下位装置に送信することと、前記下位装置のＢＡＰレイヤが、前記中継装置からの前記障害通知の受信に応じて、前記障害通知を受信した旨を前記下位装置の上位レイヤに通知することとを有する。
【図面の簡単な説明】
【0006】
【図1】一実施形態に係る移動通信システムの構成を示す図である。
【図2】一実施形態に係る基地局の構成を示す図である。
【図3】一実施形態に係る中継装置の構成を示す図である。
【図4】一実施形態に係るユーザ装置の構成を示す図である。
【図5】一実施形態に係るユーザプレーンのプロトコルスタック構成の一例を示す図である。
【図6】第１実施形態に係る中継装置の動作を示す図である。
【図7】第１実施形態に係る移動通信システムの動作の一例を示す図である。
【図8】第１実施形態の変更例１において二重接続が適用される場合の構成を示す図である。
【図9】第１実施形態の変更例２に係る動作を示す図である。
【図10】第２実施形態の動作例１を示す図である。
【図11】第２実施形態の動作例２を示す図である。
【図12】第２実施形態の動作例３を示す図である。
【図13】第２実施形態の動作例３における中継装置の動作フロー図である。
【図14】第２実施形態の動作例４を示す図である。
【図15】第２実施形態の動作例５を示す図である。
【図16】付記に係る図である。
【図17】付記に係る図である。
【発明を実施するための形態】
【0007】
図面を参照しながら、実施形態に係る移動通信システムについて説明する。図面の記載において、同一又は類似の部分には同一又は類似の符号を付している。
【0008】
［第１実施形態］
【0009】
（移動通信システムの構成）
まず、一実施形態に係る移動通信システムの構成について説明する。図１は、一実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）移動通信システムである。具体的には、移動通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、移動通信システム１には、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。
まず、一実施形態に係る移動通信システムの構成について説明する。図１は、一実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）移動通信システムである。具体的には、移動通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、移動通信システム１には、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。
【0010】
図１に示すように、移動通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００と、基地局（ｇＮＢと呼ばれる）２００と、ＩＡＢノード３００とを有する。ＩＡＢノード３００は、中継装置の一例である。
【0011】
一実施形態において、基地局がＮＲ基地局である一例について主として説明するが、基地局がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。
【0012】
５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１及びＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。
【0013】
ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して、５ＧＣ１０に接続される。図１において、５ＧＣ１０に接続された３つのｇＮＢ２００－１～ｇＮＢ２００－３を例示している。ｇＮＢ２００は、ＵＥ１００との無線通信を行う固定の無線通信装置である。ｇＮＢ２００がドナー機能を有する場合、ｇＮＢ２００は、自身に無線で接続するＩＡＢノードとの無線通信を行ってもよい。
【0014】
ｇＮＢ２００は、Ｘｎインターフェイスと呼ばれる基地局間インターフェイスを介して、隣接関係にある他のｇＮＢ２００と接続される。図１において、ｇＮＢ２００－１がｇＮＢ２００－２及びｇＮＢ２００－３に接続される一例を示している。
【0015】
各ｇＮＢ２００は、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。
【0016】
ＵＥ１００は、ｇＮＢ２００との無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ＩＡＢノード３００との無線通信を行ってもよい。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればよい。例えば、ＵＥ１００は、携帯電話端末、タブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、又は車両若しくは車両に設けられる装置である。
【0017】
図１において、ＵＥ１００－１がｇＮＢ２００－１に無線で接続され、ＵＥ１００－２がＩＡＢノード３００－１に無線で接続され、ＵＥ１００－３がＩＡＢノード３００－２に無線で接続される一例を示している。ＵＥ１００－１は、ｇＮＢ２００－１との通信を直接的に行う。ＵＥ１００－２は、ＩＡＢノード３００－１を介してｇＮＢ２００－１との通信を間接的に行う。ＵＥ１００－３は、ＩＡＢノード３００－１及びＩＡＢノード３００－２を介してｇＮＢ２００－１との通信を間接的に行う。
【0018】
ＩＡＢノード３００は、ｅＮＢ２００とＵＥ１００との間の通信に介在し、この通信に対する中継を行う装置（中継装置）である。図１において、ＩＡＢノード３００－１がドナー装置であるｇＮＢ２００－１に無線で接続され、ＩＡＢノード３００－２がＩＡＢノード３００－１に無線で接続される一例を示している。各ＩＡＢノード３００は、セルを管理する。ＩＡＢノード３００が管理するセルのセルＩＤは、ドナーｇＮＢ２００－１のセルのセルＩＤと同じであってもよいし、異なっていてもよい。
【0019】
ＩＡＢノード３００は、ＵＥ機能（ユーザ装置機能）及びｇＮＢ機能（基地局機能）を有する。このようなＵＥ機能はＭＴと呼ばれることがあり、ｇＮＢ機能はＤＵと呼ばれることがある。
【0020】
ＩＡＢノード３００は、自身のＵＥ機能（ＭＴ）により上位装置（ｇＮＢ２００又は上位のＩＡＢノード３００）との無線通信を行うとともに、自身のｇＮＢ機能（ＤＵ）により下位装置（ＵＥ１００又は下位のＩＡＢノード３００）との無線通信を行う。上位とは、ＩＡＢノード３００を基準としてドナー装置（ｇＮＢ２００）側をいい、下位とは、ＩＡＢノード３００を基準としてＵＥ１００側をいう。
【0021】
ＵＥ機能（ＭＴ）とは、ＵＥ１００が有する機能のうち少なくとも一部の機能を意味し、必ずしもＵＥ１００の全ての機能をＩＡＢノード３００が有していなくてもよい。ｇＮＢ機能（ＤＵ）とは、ｇＮＢ２００の機能のうち少なくとも一部の機能を意味し、必ずしもｇＮＢ２００の全ての機能をＩＡＢノード３００が有していなくてもよい。例えば、ｇＮＢ機能（ＤＵ）とは、ＲＲＣレイヤ及びＰＤＣＰレイヤ等を有していなくてもよい。
【0022】
ＵＥ１００と、ＩＡＢノード３００又はｇＮＢ２００との間の無線区間は、アクセスリンク（或いは、Ｕｕ）と呼ばれることがある。ＩＡＢノード３００と、ｇＮＢ２００又は他のＩＡＢノード３００との間の無線区間は、バックホールリンク（或いは、Ｕｎ）と呼ばれることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。
【0023】
アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び／又は周波数分割により多重化されてもよい。
【0024】
（基地局の構成）
次に、一実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図２は、ｇＮＢ２００の構成を示す図である。図２に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
次に、一実施形態に係る基地局であるｇＮＢ２００の構成について説明する。図２は、ｇＮＢ２００の構成を示す図である。図２に示すように、ｇＮＢ２００は、無線通信部２１０と、ネットワーク通信部２２０と、制御部２３０とを有する。
【0025】
無線通信部２１０は、ＵＥ１００との無線通信及びＩＡＢノード３００との無線通信に用いられる。無線通信部２１０は、受信部２１１及び送信部２１２を有する。受信部２１１は、制御部２３０の制御下で各種の受信を行う。受信部２１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。送信部２１２は、制御部２３０の制御下で各種の送信を行う。送信部２１２はアンテナを含み、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【0026】
ネットワーク通信部２２０は、５ＧＣ１０との有線通信（又は無線通信）及び隣接する他のｇＮＢ２００との有線通信（又は無線通信）に用いられる。ネットワーク通信部２２０は、受信部２２１及び送信部２２２を有する。受信部２２１は、制御部２３０の制御下で各種の受信を行う。受信部２２１は、外部から信号を受信して受信信号を制御部２３０に出力する。送信部２２２は、制御部２３０の制御下で各種の送信を行う。送信部２２２は、制御部２３０が出力する送信信号を外部に送信する。
【0027】
制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
【0028】
（中継装置の構成）
次に、一実施形態に係る中継装置であるＩＡＢノード３００の構成について説明する。図３は、ＩＡＢノード３００の構成を示す図である。図３に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
次に、一実施形態に係る中継装置であるＩＡＢノード３００の構成について説明する。図３は、ＩＡＢノード３００の構成を示す図である。図３に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。
【0029】
無線通信部３１０は、ｇＮＢ２００との無線通信（バックホールリンク）及びＵＥ１００との無線通信（アクセスリンク）に用いられる。バックホールリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。
【0030】
無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【0031】
制御部３２０は、ＩＡＢノード３００における各種の制御を行う。制御部３２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
【0032】
（ユーザ装置の構成）
次に、一実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図４は、ＵＥ１００の構成を示す図である。図４に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
次に、一実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図４は、ＵＥ１００の構成を示す図である。図４に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。
【0033】
無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信に用いられる。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【0034】
制御部１２０は、ＵＥ１００における各種の制御を行う。制御部１２０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサ及びＣＰＵを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する処理を実行する。
【0035】
（プロトコルスタック構成の一例）
次に、一実施形態に係る移動通信システム１におけるプロトコルスタック構成の一例について説明する。図５は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。図５において、図１に示したＵＥ１００－３と５ＧＣ１０のＵＰＦ１２との間のユーザデータ伝送に関するプロトコルスタック構成の一例を示している。
次に、一実施形態に係る移動通信システム１におけるプロトコルスタック構成の一例について説明する。図５は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。図５において、図１に示したＵＥ１００－３と５ＧＣ１０のＵＰＦ１２との間のユーザデータ伝送に関するプロトコルスタック構成の一例を示している。
【0036】
図５に示すように、ＵＰＦ１２は、ＧＴＰ－Ｕ（ＧＰＲＳ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｕｓｅｒ Ｐｌａｎｅ）と、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）と、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）と、レイヤ１／レイヤ２（Ｌ１／Ｌ２）とを有する。ｇＮＢ２００－１（ドナーｇＮＢ）には、これらに対応するプロトコルスタックが設けられる。
【0037】
また、ｇＮＢ２００－１は、集約ユニット（ＣＵ：Ｃｅｎｔｒａｌ Ｕｎｉｔ）と分散ユニット（ＤＵ：Ｄｉｓｔｒｉｂｕｔｅｄ Ｕｎｉｔ）とを有する。無線インターフェイスのプロトコルスタックのうちＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）以上の各レイヤをＣＵが有し、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）以下の各レイヤをＤＵが有し、Ｆ１インターフェイスと呼ばれるインターフェイスを介してＣＵ及びＤＵが接続される。
【0038】
具体的には、ＣＵは、ＳＤＡＰ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）と、ＰＤＣＰと、ＩＰと、Ｌ１／Ｌ２とを有する。ＣＵのＳＤＡＰ及びＰＤＣＰは、ＤＵと、ＩＡＢノード３００－１と、ＩＡＢノード３００－２とを介して、ＵＥ１００のＳＤＡＰ及びＰＤＣＰとの通信を行う。
【0039】
また、ＤＵは、無線インターフェイスのプロトコルスタックのうち、ＲＬＣと、アダプテーションレイヤ（Ａｄａｐｔ）と、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）と、ＰＨＹ（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ）とを有する。これらのプロトコルスタックは、ｇＮＢ向けのプロトコルスタックである。なお、アダプテーションレイヤ及びＲＬＣ（Ｓ－ＲＬＣ）は上下関係が逆であってもよい。アダプテーションレイヤは、バックホールアダプテーションプロトコル（ＢＡＰ）レイヤと呼ばれてもよい。
【0040】
ＩＡＢノード３００－１には、これらに対応するＵＥ向けのプロトコルスタックＳＴ１が設けられる。さらに、ＩＡＢノード３００－１には、ｇＮＢ向けのプロトコルスタックＳＴ２が設けられる。プロトコルスタックＳＴ１及びプロトコルスタックＳＴ２は、何れもレイヤ２以下の各レイヤ（各サブレイヤ）からなる。すなわち、ＩＡＢノード３００－１は、レイヤ２以下の各レイヤを用いてユーザデータの中継を行うレイヤ２中継装置である。ＩＡＢノード３００－１は、レイヤ３以上のレイヤ（具体的には、ＰＤＣＰ以上のレイヤ）を用いることなくデータ中継を行う。なお、ＩＡＢノード３００－２は、ＩＡＢノード３００－１と同様なプロトコルスタック構成を有する。
【0041】
ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、ｇＮＢ２００－１、ＩＡＢノード３００－１、ＩＡＢノード３００－２、及びＵＥ１００－３のそれぞれは、レイヤ３に相当するＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）を有する。
【0042】
ｇＮＢ２００－１（ドナーｇＮＢ）のＲＲＣとＩＡＢノード３００－１のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。また、ｇＮＢ２００－１のＲＲＣとＩＡＢノード３００－２のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。さらに、ｇＮＢ２００－１のＲＲＣとＵＥ１００－３のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。
【0043】
（第１実施形態に係る動作）
次に、第１実施形態に係る動作について説明する。図６は、第１実施形態に係るＩＡＢノード３００の動作を示す図である。
次に、第１実施形態に係る動作について説明する。図６は、第１実施形態に係るＩＡＢノード３００の動作を示す図である。
【0044】
図６に示すように、ＩＡＢノード３００は、バックホールリンクを介して上位装置Ａと無線で接続している。上位装置Ａは、上位ＩＡＢノード又はドナーｇＮＢ（ドナー装置）である。
【0045】
ＩＡＢノード３００には下位装置Ｂ１及びＢ２が接続しており、下位装置Ｂ２には下位装置Ｂ３が接続している。下位装置Ｂ４は、ＩＡＢノード３００の配下にない装置である。下位装置Ｂ１乃至Ｂ４は、下位ＩＡＢノード又はＵＥである。以下において、下位装置Ｂ１乃至Ｂ４を特に区別しないときは単に下位装置Ｂと呼ぶ。
【0046】
第１実施形態では、上位装置Ａと下位装置Ｂとの間の通信を無線で中継するＩＡＢノード３００において、上位装置Ａと無線で接続するユーザ装置機能部（ＭＴ）は、下位装置Ｂと無線で接続する基地局機能部（ＤＵ）に対して状態情報を通知する。
【0047】
この状態情報は、ユーザ装置機能部（ＭＴ）のＲＲＣ状態、及び上位装置Ａとユーザ装置機能部（ＭＴ）との間の無線リンク状態（以下、バックホールリンク状態と呼ぶ）のうち、少なくとも一方の状態を示す情報である。これにより、基地局機能部（ＤＵ）は、バックホールリンク側の状態を考慮して下位装置Ｂに対するサービス提供を制御できる。
【0048】
ここで、ユーザ装置機能部（ＭＴ）のＲＲＣ状態は、コネクティッド、インアクティブ、及びアイドルのいずれかである。
【0049】
バックホールリンク状態は、下記の１）乃至６）のうち少なくとも１つの指標、又はこれらの指標の組み合わせに基づく状態である。
【0050】
１）バックホールのＲＬＦ（以下、ＢＨ ＲＬＦと呼ぶ）を検知した及びＢＨ ＲＬＦから復帰したなどのＲＬＦ状態
【0051】
２）ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）などの無線品質
【0052】
３）ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）再送回数やＲＡＣＨ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）再送回数などのリンク状態
【0053】
４）ＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｏｒ）、ＣＢＲ（Ｃｈａｎｎｅｌ Ｂｕｓｙ Ｒａｔｉｏ）、ＬＢＴ（Ｌｉｓｔｅｎ Ｂｅｆｏｒｅ Ｔａｌｋ）状況などの混雑度
【0054】
５）設定されている又は活性化されているセカンダリセル数、ＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）レイヤ数、割り当て無線リソース状況（例えば、準静的割り当てにおけるＣｏｎｆｉｇｕｒｅｄ ｇｒａｎｔの増減、動的割り当てにおけるＤｙｎａｍｉｃ ｇｒａｎｔの増減）、スループット測定値などの通信容量
【0055】
６）上りリンクスケジューリング遅延時間の測定値、上りリンクバッファ中のデータ量などの遅延状態
【0056】
バックホールリンク状態は、上記１）乃至６）の指標に基づくバックホールリンク状態の良好度合い、例えば、閾値よりも良好又は閾値よりも劣悪といった状態であってもよい。
【0057】
ユーザ装置機能部（ＭＴ）は、ＲＲＣ状態の変化又はバックホールリンク状態の変化をトリガとして、状態情報を基地局機能部（ＤＵ）に通知してもよい。例えば、ユーザ装置機能部（ＭＴ）は、バックホールリンク状態が閾値条件を満たしたというイベントが発生した際に、状態情報を基地局機能部（ＤＵ）に通知する。
【0058】
或いは、ユーザ装置機能部（ＭＴ）は、状態情報を基地局機能部（ＤＵ）に周期的に通知してもよい。
【0059】
基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、下位装置Ｂに対するサービス提供を停止してもよい。下位装置Ｂに対するサービス提供を停止するとは、少なくとも１つの下りリンク無線信号の送信を停止することをいう。基地局機能部（ＤＵ）は、ＰＳＳ（Ｐｒｉｍａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）、ＳＳＳ（Ｓｅｃｏｎｄａｒｙ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｓｉｇｎａｌ）、ＭＩＢ（Ｍａｓｔｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）の送信を停止してもよい。
【0060】
例えば、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合、下位装置Ｂに対するサービス提供を停止してもよい。基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣコネクティッド状態に遷移した場合、下位装置Ｂに対するサービス提供を再開してもよい。
【0061】
基地局機能部（ＤＵ）は、バックホールリンクが劣化している場合、例えば、ＢＨ ＲＬＦが検知された場合、下位装置Ｂに対するサービス提供を停止してもよい。基地局機能部（ＤＵ）は、バックホールリンクが良化した場合、下位装置Ｂに対するサービス提供を再開してもよい。
【0062】
或いは、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、下位装置Ｂに対する無線リソース割り当て（スケジューリング）を制御してもよい。
【0063】
基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した場合、下位装置Ｂに対するリソース割当を中止してもよい。なお、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣアイドル状態又はＲＲＣインアクティブ状態に遷移した際に、下位装置Ｂに上りリンクリソースを割り当てている場合、ＲＲＣコネクティッド状態に遷移するようにユーザ装置機能部（ＭＴ）に要求してもよい。
【0064】
基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）がＲＲＣコネクティッド状態に遷移した場合、下位装置Ｂに対するリソース割当を再開してもよい。
【0065】
基地局機能部（ＤＵ）は、バックホールリンクが劣化している場合、例えば、ＢＨ ＲＬＦが検知された場合、下位装置Ｂに対するリソース割当を中止してもよい。基地局機能部（ＤＵ）は、バックホールリンクが良化した場合、例えば、ＢＨ ＲＬＦから復旧した場合、下位装置Ｂに対するリソース割当を再開してもよい。
【0066】
或いは、基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの状態情報に基づいて、バックホールリンクの劣化を示す通知、例えば、ＢＨ ＲＬＦの発生を示す通知（以下、ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ又はＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎと呼ぶ）を下位装置Ｂに送信してもよい。ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎは、ＩＡＢノード３００の識別子を含んでもよい。以下において、バックホールリンクの劣化を示す通知がＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎである一例について説明する。
【0067】
基地局機能部（ＤＵ）は、ＲＲＣレイヤよりも下位のレイヤの制御信号によりＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信してもよい。基地局機能部（ＤＵ）は下位装置ＢとのＲＲＣ接続を有していないためである。ＲＲＣレイヤよりも下位のレイヤの制御信号は、ＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）、ＲＬＣ Ｃｏｎｔｒｏｌ ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）、又はＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）であるが、以下においてはＭＡＣ ＣＥを用いる一例について説明する。
【0068】
基地局機能部（ＤＵ）は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎをユニキャストで下位装置Ｂに送信してもよい。或いは、基地局機能部（ＤＵ）は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎのシグナリング負荷を減らすために、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎをブロードキャスト又はマルチキャストで送信してもよい。ブロードキャスト又はマルチキャストを用いる場合、下位装置Ｂ３及びＢ４は、接続中のセル（上位ＩＡＢノード）からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎだけではなく、その他のセルのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎもモニタすることで、ＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信できる。
【0069】
基地局機能部（ＤＵ）は、例えば、予め仕様で定められた固定のＲＮＴＩ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いてＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎをブロードキャストで送信してもよい。基地局機能部（ＤＵ）は、下位装置のグループに割り当てた共通のＲＮＴＩを用いてＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎをマルチキャストで送信してもよい。
【0070】
なお、ブロードキャスト／マルチキャストと、ユニキャストとを使い分けてもよい。この場合、基地局機能部（ＤＵ）は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎがブロードキャスト／マルチキャストで送信されるか、ユニキャストで送信されるかをＳＩＢで通知（ブロードキャスト）してもよい。下位装置Ｂは、このＳＩＢに基づいて、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの待ち受けモード、例えば、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎのモニタに用いるＲＮＴＩを変更してもよい。
【0071】
基地局機能部（ＤＵ）は、バックホールリンクの無線リンク状態が劣化している期間、例えば、ＢＨ ＲＬＦが発生している期間内において、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを周期的に送信してもよい。この場合、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎが周期的に送信される期間内では、ＢＨ ＲＬＦが発生していることになる。或いは、基地局機能部（ＤＵ）は、ＢＨ ＲＬＦが発生した際にＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信し、ＢＨ ＲＬＦから復旧した際に復旧を示す通知（ＢＨ Ｒｅｃｏｖｅｒｅｄ）を送信してもよい。以下においては、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信により、ＢＨ ＲＬＦの発生及びＢＨ ＲＬＦからの復旧を下位装置に示す一例について主として説明する。
【0072】
下位装置Ｂは、ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信する期間内では、ＢＨ ＲＬＦが発生していると判定する。ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信周期は、ドナー装置からＩＡＢノード３００のユーザ装置機能部（ＭＴ）を介して基地局機能部（ＤＵ）に設定されてもよい。
【0073】
ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎがマルチキャストで送信される場合、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００に対するＡＣＫ／ＮＡＣＫフィードバックの送信を開始してもよい。ＩＡＢノード３００は、配下の全ての下位装置Ｂ１乃至Ｂ３からＡＣＫを受信した場合、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信を停止してもよい。
【0074】
ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を行ってもよい。このような処理としては、例えば、接続再確立処理、条件付きハンドオーバのトリガ処理、通信経路切替処理、ハンドオーバ用の測定報告処理が挙げられる。なお、下位装置Ｂ１乃至Ｂ３は、このような切り替え処理を開始した後、切り替え処理を完了するまでの間において、ＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信しなくなった場合（又はＢＨ ＲＬＦの復旧を示す通知を受信した場合）、ＩＡＢノード３００のバックホールリンクが復旧したと判定し、切り替え処理を中止してもよい。
【0075】
例えば、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、ＩＡＢノード３００のセル以外のセルを探索するセルサーチを行い、適切なセルに対して接続再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）を行う。ここで、下位装置Ｂ１乃至Ｂ３とＩＡＢノード３００との間でＲＬＦが発生していなくても、このような接続再確立処理を早期に行う。
【0076】
接続再確立処理は、時間的に分散して実行するように制御されていてもよい。例えば、下位装置Ｂ１乃至Ｂ３は、ランダム値やＵＥ－ＩＤを用いて接続再確立処理の実行開始時間を決定することにより、下位装置Ｂ１乃至Ｂ３の接続再確立処理の実行開始時間を分散させ、負荷の集中を防ぐことができる。なお、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎがユニキャストで送信される場合、基地局機能部（ＤＵ）がＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信タイミングを分散させることにより、下位装置Ｂ１乃至Ｂ３の接続再確立処理の実行開始時間を分散させてもよい。
【0077】
ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、自身がＩＡＢノード３００と、ＩＡＢノード３００以外の上位装置とに接続してＤＣ通信を行っている場合、ＩＡＢノード３００を経由する通信経路を他の上位装置に切り替えてもよいし、他の通信装置にＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信してもよい。例えば、下位装置Ｂは、ＩＡＢノード３００をマスタノード（ＭＮ）として設定し、他の上位装置をバックアップ用のセカンダリノード（ＳＮ）として設定している場合、ＭＮを経由する通信経路をＳＮに切り替える。
【0078】
ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、自身に条件付きハンドオーバが設定されている場合、条件が満たされたとみなして、ハンドオーバを行ってもよい。ハンドオーバ条件がサービングセルの無線品質劣化を示すイベントである場合、サービングセルの無線品質測定結果を低く修正する（例えば、－２００ｄＢｍとみなす）ことにより、強制的にハンドオーバをトリガしてもよい。
【0079】
ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ１乃至Ｂ３は、測定報告の送信をトリガしてもよい。ここで、一般的な測定報告はＲＲＣメッセージで送信されるが、基地局機能部（ＤＵ）はＲＲＣレイヤを有していない。このため、ＩＡＢノード３００は、バックホールリンクのＲＬＦから復旧するまでは下位装置Ｂからの測定報告を保持し、ＢＨ ＲＬＦから（一時的に）復旧した際にドナー装置に転送し、ドナー装置が下位装置Ｂをハンドオーバさせてもよい。
【0080】
ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ４は、接続先の候補としてＩＡＢノード３００を除外するための処理を行ってもよい。例えば、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂ４は、ＲＲＣアイドル状態又はＲＲＣインアクティブ状態におけるセル再選択動作において、ＩＡＢノード３００のセルの優先度を下げる、もしくは再選択対象から除外する、もしくはＩＡＢノード３００についての受信電力測定値を低く調整することにより、接続先の候補としてＩＡＢノード３００が除外されるようにしてもよい。ここで、受信電力測定値を低く調整するために、実際の受信電力測定値に対してオフセット値を適用してもよい。当該オフセット値は予め決められた固定値であってもよい。もしくは当該オフセット値はネットワークから通知された値であってもよく、当該通知は下位装置Ｂ４が現在キャンプしているセルの報知情報（ＳＩＢ）によって通知されてもよい。
【0081】
下位装置Ｂ４は、接続先の候補としてＩＡＢノード３００を除外するための処理を、ＲＲＣコネクティッド状態に遷移する際のＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ処理又はＲＲＣ Ｒｅｓｕｍｅ Ｒｅｑｕｅｓｔ処理を開始する前のタイミングで行ってもよい。
【0082】
具体的には、下位装置Ｂ４は、ＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを送信する前に、送信先候補のセルがＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを通知しているか否かの確認を行う。下位装置Ｂ４は、送信先候補のセルがＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを通知していない場合はＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔを送信する。送信先候補のセルがＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを通知している場合はＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔの送信を停止（もしくは中止）し、前記セル再選択動作を行うことにより、適切なＲＲＣ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ送信先を選択する。
【0083】
下位装置Ｂ４は、ＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信しなくなった場合（又はＢＨ ＲＬＦの復旧を示す通知を受信した場合）、ＩＡＢノード３００のバックホールリンクが復旧したと判定し、接続先の候補としてＩＡＢノード３００を除外するための処理を中止してもよい。
【0084】
図７は、第１実施形態に係る動作の一例を示す図である。図７において、ＩＡＢノード（Ｐａｒｅｎｔ ＩＡＢ ｎｏｄｅ）３００とドナーｇＮＢ（ＩＡＢ ｄｏｎｅｒ）２００との間に他のＩＡＢノードが介在してもよい。
【0085】
図７に示すように、ステップＳ１０１において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、無線問題（ｒａｄｉｏ ｐｒｏｂｌｅｍ）を検知する。
【0086】
ステップＳ１０２において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＢＨ ＲＬＦを検知する（ＲＬＦ ｄｅｃｌａｒａｔｉｏｎ）。
【0087】
ステップＳ１０３において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＢＨ ＲＬＦの発生を示す状態情報をＩＡＢノード３００の基地局機能部（ＤＵ）に通知する。
【0088】
ステップＳ１０４において、ＩＡＢノード３００の基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの通知に応じて、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの周期的な送信を開始する。
【0089】
ステップＳ１０５において、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を開始する。このような処理としては、例えば、接続再確立処理（Ｅａｒｌｙ ＲＲＣ Ｒｅ－ｅｓｔａｂｌｉｓｈｍｅｎｔ）、条件付きハンドオーバのトリガ処理（Ｔｒｉｇｇｅｒｉｎｇ Ｃｏｎｄｉｔｉｏｎａｌ ＨＯ）、通信経路切替処理（Ｓｗｉｔｃｈｉｎｇ ｔｏ ｒｅｄｕｎｄａｎｔ ｒｏｕｔｅ）が挙げられる。
【0090】
ステップＳ１０６において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、例えばＴ３１０動作中に接続再確立を行うことができず、Ｔ３１０の満了に応じてＲＲＣアイドル状態に遷移する（Ｇｏ ｔｏ ＩＤＬＥ）。
【0091】
ステップＳ１０７において、ＩＡＢノード３００のユーザ装置機能部（ＭＴ）は、ＲＲＣアイドル状態への遷移を示す状態情報をＩＡＢノード３００の基地局機能部（ＤＵ）に通知する。
【0092】
ステップＳ１０８において、ＩＡＢノード３００の基地局機能部（ＤＵ）は、ユーザ装置機能部（ＭＴ）からの通知に応じて、下位装置Ｂへのサービス提供を停止する（Ｓｅｒｖｉｃｅ ｓｔｏｐｐｅｄ）。
【0093】
ステップＳ１０９において、下位装置Ｂは、ＩＡＢノード３００からのサービス提供が停止されたことにより、ＲＬＦを検知する。
【0094】
［第１実施形態の変更例１］
次に、第１実施形態の変更例１について説明する。
次に、第１実施形態の変更例１について説明する。
【0095】
上述した第１実施形態において、図７のステップＳ１０４及びＳ１０５に示すように、ＢＨ ＲＬＦを検知したＩＡＢノード３００がＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに送信し、下位装置Ｂが、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を開始する一例について説明した。
【0096】
本変更例では、下位装置Ｂは、ＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００に対する上りリンク送信を停止する。具体的には、ＩＡＢノード３００においてＢＨ ＲＬＦが発生している場合、ＩＡＢノード３００と下位装置Ｂとの間の無線状態が正常であっても、下位装置Ｂの上りリンク信号はドナー装置２００に到達しない。このため、下位装置ＢがＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて上りリンク送信を停止することにより、消費電力及び干渉の増大を抑制できる。
【0097】
すなわち、本変更例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、このＩＡＢノード３００の上位の上位装置ＡとＩＡＢノード３００との間のＢＨ ＲＬＦ（ＢＨ ＲＬＦ）を検知することと、
２）ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００が、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに送信することと、
３）下位装置Ｂが、ＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００に対する上りリンク送信を停止することと、を有する。
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、このＩＡＢノード３００の上位の上位装置ＡとＩＡＢノード３００との間のＢＨ ＲＬＦ（ＢＨ ＲＬＦ）を検知することと、
２）ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００が、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに送信することと、
３）下位装置Ｂが、ＩＡＢノード３００からのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００に対する上りリンク送信を停止することと、を有する。
【0098】
下位装置Ｂは、ＩＡＢノード３００に対する上りリンク送信を停止するとともに、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を開始してもよい。或いは、下位装置Ｂは、ＩＡＢノード３００に対する上りリンク送信を停止した状態でＢＨ ＲＬＦの復旧を待ち、一定時間待ってもＢＨ ＲＬＦが復旧しない場合、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を開始してもよい。
【0099】
下位装置Ｂにおける上りリンク送信の停止とは、次のａ）乃至ｅ）のうち少なくとも１つを含む。
【0100】
ａ）下位装置ＢからＩＡＢノード３００に対するスケジューリング要求（ＳＲ：Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）の送信を停止する：
スケジューリング要求とは、上りリンク無線リソースの割当を要求する信号をいう。ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、このＩＡＢノード３００に対するスケジューリング送信の送信を停止（禁止）する。
スケジューリング要求とは、上りリンク無線リソースの割当を要求する信号をいう。ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、このＩＡＢノード３００に対するスケジューリング送信の送信を停止（禁止）する。
【0101】
ｂ）下位装置ＢからＩＡＢノード３００に対するＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）送信を停止する：
ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、このＩＡＢノード３００から上りリンク無線リソース（ＰＵＳＣＨリソース）が割り当てられた場合、すなわち、上りリンクグラントを受信した場合であっても、この割当を適用せずに、ＰＵＳＣＨ送信を停止（禁止）する。すなわち、ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、上りリンクデータ及び上りリンクＲＲＣシグナリングの送信を停止（禁止）する。
ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、このＩＡＢノード３００から上りリンク無線リソース（ＰＵＳＣＨリソース）が割り当てられた場合、すなわち、上りリンクグラントを受信した場合であっても、この割当を適用せずに、ＰＵＳＣＨ送信を停止（禁止）する。すなわち、ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、上りリンクデータ及び上りリンクＲＲＣシグナリングの送信を停止（禁止）する。
【0102】
ｃ）下位装置Ｂの無線ベアラをサスペンドする：
無線ベアラをサスペンドするとは、無線ベアラの設定を保持しつつ、無線ベアラの使用を停止（禁止）することをいう。ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、このＩＡＢノード３００に対応する全ての無線ベアラをサスペンドしてもよいし、これらの無線ベアラのうちシグナリング無線ベアラの使用を継続しつつデータ無線ベアラをサスペンドしてもよい。
無線ベアラをサスペンドするとは、無線ベアラの設定を保持しつつ、無線ベアラの使用を停止（禁止）することをいう。ＩＡＢノード３００からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、このＩＡＢノード３００に対応する全ての無線ベアラをサスペンドしてもよいし、これらの無線ベアラのうちシグナリング無線ベアラの使用を継続しつつデータ無線ベアラをサスペンドしてもよい。
【0103】
ｄ）下位装置ＢからＩＡＢノード３００に対するＰＵＣＣＨ送信を停止する：
これはａ）で述べたＭＡＣレイヤによるＳＲ送信の停止、及び、ＰＨＹレイヤによるＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）のフィードバックなどの停止を包含し得る。
これはａ）で述べたＭＡＣレイヤによるＳＲ送信の停止、及び、ＰＨＹレイヤによるＣＳＩ（Ｃｈａｎｎｅｌ Ｓｔａｔｅ Ｉｎｆｏｒｍａｔｉｏｎ）のフィードバックなどの停止を包含し得る。
【0104】
ｅ）下位装置ＢからＩＡＢノード３００に対するＰＲＡＣＨ送信を停止する、もしくはランダムアクセスプロシージャの開始を規制する（行わない）。
【0105】
本変更例において、下位装置Ｂは、ＩＡＢノード３００がＢＨ ＲＬＦから復旧したと判定し、この判定に応じて上りリンク送信を再開してもよい。
【0106】
例えば、ＢＨ ＲＬＦから復旧したことを示す通知（ＲＬＦ Ｒｅｃｏｖｅｒｅｄ）をＩＡＢノード３００が下位装置Ｂに送信する前提下において、下位装置Ｂは、このＲＬＦ Ｒｅｃｏｖｅｒｅｄの受信に応じて、ＩＡＢノード３００がＢＨ ＲＬＦから復旧したと判定し、上りリンク送信を再開する。
【0107】
一方、ＢＨ ＲＬＦの継続中はＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＩＡＢノード３００が下位装置Ｂに周期的に（連続的に）送信する前提下において、下位装置Ｂは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信が停止したことに応じて、ＩＡＢノード３００がＢＨ ＲＬＦから復旧したと判定し、上りリンク送信を再開する。ここで、下位装置Ｂは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信していない場合に、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信が停止したと判断してもよい。例えば、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを所定のタイミングで受信しなかった場合に、当該判断を実施する。ここで所定のタイミングとは、前記周期的に送信される場合における送信周期であってもよい。
【0108】
なお、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信停止とは、例えば、下位装置Ｂがスケジューリング要求の送信を希望した時点で既に停止していた場合や、スケジューリング要求の送信を希望した時点から次のＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎタイミングでＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎが停止していた場合が含まれる。
【0109】
詳細については第２実施形態において説明するが、移動通信システム１において二重接続（ＤＣ：Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）が適用されてもよい。図８は、本変更例において二重接続が適用される場合の構成を示す図である。
【0110】
図８に示す構成において、下位装置Ｂは、ＩＡＢノード３００Ｍをマスタノード（ＭＮ）とし、且つＩＡＢノード３００Ｓをセカンダリノード（ＳＮ）とする二重接続の通信を行っている。ＭＮが下位装置Ｂに割り当てる１つ又は複数のセルはマスタセルグループ（ＭＣＧ）と呼ばれる。ＳＮが下位装置Ｂに割り当てる１つ又は複数のセルはセカンダリセルグループ（ＳＣＧ）と呼ばれる。
【0111】
図８において、ＩＡＢノード３００Ｍの上位装置Ａ１及びＩＡＢノード３００Ｓの上位装置Ａ２は、ＩＡＢノード３００又はｇＮＢ２００である。下位装置Ｂは、ＩＡＢノード３００又はＵＥ１００である。
【0112】
このような二重接続の状況下において、ＭＮであるＩＡＢノード３００Ｍは、上位装置Ａ１とのＢＨ ＲＬＦを検知すると、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに送信する。下位装置Ｂは、ＭＮであるＩＡＢノード３００ＭからのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＩＡＢノード３００Ｍに対する上りリンク送信を停止するとともに、ＳＮであるＩＡＢノード３００Ｓに対する上りリンク送信を停止する。言い換えると、下位装置Ｂは、ＭＮがＢＨ ＲＬＦを検知した場合、全ての上りリンク送信（ＭＣＧ及びＳＣＧへの上りリンク送信）を停止する。
【0113】
一方、ＳＮであるＩＡＢノード３００Ｓは、上位装置Ａ２とのＢＨ ＲＬＦを検知すると、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに送信する。下位装置Ｂは、ＳＮであるＩＡＢノード３００ＳからのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信に応じて、ＭＮであるＩＡＢノード３００Ｍに対する上りリンク送信を停止せずに、ＳＮであるＩＡＢノード３００Ｓに対する上りリンク送信を停止する。言い換えると、下位装置Ｂは、ＳＮがＢＨ ＲＬＦを検知した場合、ＳＮに対する上りリンク送信（ＳＣＧへの上りリンク送信）のみを停止する。
【0114】
［第１実施形態の変更例２］
次に、第１実施形態の変更例２について説明する。
次に、第１実施形態の変更例２について説明する。
【0115】
上述した実施形態において、ＩＡＢノード３００が、ＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＭＡＣレイヤにおいて送信する一例について説明した。本変更例においては、このようなＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した下位装置Ｂは、ＭＡＣレイヤにおいて受信したＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎに関して上位レイヤに通知する。
【0116】
すなわち、本変更例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、このＩＡＢノード３００の上位の上位装置ＡとＩＡＢノード３００との間のＢＨ ＲＬＦを検知することと、
２）ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００のＭＡＣレイヤが、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに送信することと、
３）下位装置ＢのＭＡＣレイヤが、ＩＡＢノード３００からの障害通知の受信に応じて、障害通知を受信した旨を下位装置Ｂの上位レイヤに通知することと、を有する。
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、このＩＡＢノード３００の上位の上位装置ＡとＩＡＢノード３００との間のＢＨ ＲＬＦを検知することと、
２）ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００のＭＡＣレイヤが、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに送信することと、
３）下位装置ＢのＭＡＣレイヤが、ＩＡＢノード３００からの障害通知の受信に応じて、障害通知を受信した旨を下位装置Ｂの上位レイヤに通知することと、を有する。
【0117】
図９は、本変更例に係る動作を示す図である。図９の（１）は、下位装置ＢがＩＡＢノード３００である一例を示している。図９の（２）は、下位装置ＢがＵＥ１００である一例を示している。上位装置Ａは、ＩＡＢノード３００であってもよいし、ｇＮＢ２００（ドナー装置）であってもよい。
【0118】
図９の（１）に示すように、ＩＡＢノード３００は、ＭＴと、ＢＡＰレイヤと、ＤＵとを有する。ＢＡＰレイヤの少なくとも一部は、ＭＴに含まれていてもよいし、ＤＵに含まれていてもよい。ＩＡＢノード３００のＤＵは、ＭＡＣレイヤを有する。また、ＤＵは、図示を省略するＰＨＹレイヤ及びＲＬＣレイヤも有する。下位装置Ｂ（下位のＩＡＢノード）のＭＴは、ＭＡＣレイヤと、ＲＲＣレイヤとを有する。また、ＤＵは、図示を省略するＰＨＹレイヤ及びＲＬＣレイヤも有する。
【0119】
図９の（２）に示すように、ＩＡＢノード３００は、図９の（１）と同様に構成されている。下位装置Ｂ（ＵＥ１００）は、ＭＡＣレイヤと、ＰＤＣＰレイヤと、ＲＲＣレイヤとを有する。また、ＵＥ１００は、図示を省略するＰＨＹレイヤ及びＲＬＣレイヤも有する。
【0120】
図９に示すような構成において、ＩＡＢノード３００のＭＴがＢＨ ＲＬＦを検知すると、ＩＡＢノード３００のＤＵのＭＡＣレイヤは、このＢＨ ＲＬＦの検知に応じて、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに送信する。ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎは、ＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）に含まれていてもよい。下位装置ＢのＭＡＣレイヤは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信すると、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した旨を下位装置Ｂの上位レイヤに通知する。上位レイヤへの通知は、ＩＡＢノード３００においてＢＨ ＲＬＦが検知されたことを示す通知であってもよいし、対応する通信経路（或いはＩＡＢノード３００と下位装置Ｂとの間の無線リンク）が使用不能である旨の通知であってもよい。
【0121】
下位装置ＢにおいてＭＡＣレイヤからの通知先となる上位レイヤは、ＲＲＣレイヤ、ＢＡＰレイヤ、及びＰＤＣＰレイヤのうち少なくとも１つを含む。上位レイヤは、第１実施形態で説明したような処理、すなわち、接続先又は通信経路をＩＡＢノード３００から切り替えるための処理を行ってもよいし、第１実施形態の変更例１で説明したような処理、すなわち、上りリンク送信を停止してもよい。
【0122】
下位装置Ｂにおいて、ＭＡＣレイヤからの通知を受けたＲＲＣレイヤは、例えば次の処理のうち少なくとも１つを実行する。
【0123】
・上りリンク送信を停止する（第１実施形態の変更例１参照）。
【0124】
・リダンダンシリンクの確立を試みる。例えば、下位装置Ｂが下位ＩＡＢノードであり、下位ＩＡＢノードが複数のＭＴを有する場合、ＲＲＣレイヤは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信したＭＴ以外のＭＴによりリンクを確立する。
【0125】
・ＲＲＣレイヤは、別のセル（別の上位装置）へＲＲＣ再確立処理（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）を行う。
【0126】
・下位装置Ｂが二重接続を有しており、下位装置ＢがＳＮ（ＳＣＧ）からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合、ＲＲＣレイヤは、ＭＮ（ＭＣＧ）へ通知（ＳＣＧ Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）を送信する。
【0127】
・下位装置Ｂが二重接続を有しており、下位装置ＢがＭＮ（ＭＣＧ）からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合、ＲＲＣレイヤは、ＳＮ（ＳＣＧ）へ通知（ＭＣＧ Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）を送信する。
【0128】
また、下位装置Ｂにおいて、ＭＡＣレイヤからの通知を受けたＢＡＰレイヤ又はＰＤＣＰレイヤは、下位装置Ｂが二重接続を有している場合、バッファしたアップストリームデータを別リンクへ転送（再ルーティング）する。例えば、下位装置ＢがＳＮ（ＳＣＧ）からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合、ＢＡＰレイヤ又はＰＤＣＰレイヤは、ＭＮ（ＭＣＧ）にアップストリームデータを転送する。一方、下位装置ＢがＭＮ（ＭＣＧ）からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合、ＢＡＰレイヤ又はＰＤＣＰレイヤは、ＳＮ（ＳＣＧ）にアップストリームデータを転送する。もしくは、ＢＡＰレイヤ又はＰＤＣＰレイヤは、ＢＨ ＲＬＦが発生しているルート（上位ノード）とリンクを確立しているＲＬＣチャネル（すなわちＲＬＣエンティティ）へのアップストリームデータの送信を停止する。
【0129】
なお、本変更例において、ＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎがＭＡＣレイヤにおいて送受信される一例について説明したが、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎは、例えばＲＲＣレイヤにおいて送受信されてもよい。このような前提下において、下位装置ＢのＲＲＣレイヤは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信すると、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した旨を他のレイヤ（例えば、ＢＡＰレイヤ及び／又はＭＡＣレイヤ）に通知する。
【0130】
或いは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎは、ＢＡＰレイヤにおいて送受信されてもよい。このような前提下において、下位装置ＢのＢＡＰレイヤは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信すると、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した旨を他のレイヤ（例えば、ＲＲＣレイヤ及び／又はＭＡＣレイヤ）に通知する。
【0131】
［第１実施形態の変更例３］
次に、第１実施形態の変更例３について説明する。
次に、第１実施形態の変更例３について説明する。
【0132】
上述した第１実施形態において、図７のステップＳ１０４に示すように、ＩＡＢノード３００が、ＢＨ ＲＬＦが発生している期間内においてＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを周期的に（連続的に）送信する一例について説明した。この送信周期は、移動通信システム１の仕様で規定された一定周期としてもよいが、本変更例では、この送信周期を可変とする。
【0133】
すなわち、本変更例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、このＩＡＢノード３００の上位の上位装置ＡとＩＡＢノード３００との間のＢＨ ＲＬＦを検知することと、
２）ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００が、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに繰り返し送信することと、
３）ＩＡＢノード３００が、障害通知の繰り返し送信のタイミングに関するタイミング情報を下位装置Ｂに送信することと、を有する。
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、このＩＡＢノード３００の上位の上位装置ＡとＩＡＢノード３００との間のＢＨ ＲＬＦを検知することと、
２）ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００が、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに繰り返し送信することと、
３）ＩＡＢノード３００が、障害通知の繰り返し送信のタイミングに関するタイミング情報を下位装置Ｂに送信することと、を有する。
【0134】
これにより、障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）の送信周期を可変とすることができる。周期を短くすると、頻繁に送信することになるので、上位ノードがＢＨ ＲＬＦから復旧した際に、下位ノードは当該復旧を迅速に知ることができ、ＵＬ送信再開などのリカバリ動作を素早く行うことができるメリットがある。一方で、送信／受信に要する消費電力が増えてしまったり、干渉が増えたりするデメリットがある。周期を長くした場合は、上記メリット／デメリットが逆転する。よって、障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）の送信周期は、ネットワーク設計ポリシーに応じて最適値に調整され得る。
【0135】
なお、繰り返し送信とは、周期的な送信であってもよいし、非周期的な送信であってもよい。ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを周期的に送信する場合において、ＩＡＢノード３００が送信するタイミング情報は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信周期を示す情報を含む。ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを非周期的に送信する場合において、ＩＡＢノード３００が送信するタイミング情報は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信タイミングに対応するサブフレーム番号を示す情報を含んでもよい。
【0136】
ＩＡＢノード３００は、タイミング情報を含むＳＩＢをブロードキャストにより送信してもよい。或いは、ドナー装置は、タイミング情報を含むＲＲＣメッセージ（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）を、ＩＡＢノード３００を介して下位装置Ｂに送信してもよい。
【0137】
或いは、ＩＡＢノード３００は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎと共にタイミング情報を下位装置Ｂに送信してもよい。具体的には、ＩＡＢノード３００は、タイミング情報を含むＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信する。例えば、１つのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎに含まれるタイミング情報は、次回のＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信タイミングに対応するサブフレーム番号を示す情報を含んでもよい。なお、上述したように、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎは、ＭＡＣレイヤにおいて送受信されてもよい。
【0138】
また、ＢＨ ＲＬＦを検知したＩＡＢノード３００は、バックホールリンクの再確立を試行する期間において、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに繰り返し送信してもよい。具体的には、ＢＨ ＲＬＦを検知したＩＡＢノード３００は、バックホールリンクのＲＲＣ再確立に失敗しても、バックホールリンクのＲＲＣ再確立の試行を継続する期間内において、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信を継続する。そして、この期間内でＲＲＣ再確立に成功しない場合、ＩＡＢノード３００のＤＵは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信を停止するとともに、下位装置Ｂに対するサービス提供を停止する（すなわち、ＰＳＳ／ＳＳＳ／ＭＩＢ／ＳＩＢ１を停止する）。また、ＩＡＢノード３００のＭＴは、ＲＲＣアイドル状態に遷移する。
【0139】
［第２実施形態］
次に、第１実施形態及びその変更例に係る動作を前提として第２実施形態について説明する。但し、第１実施形態とは異なる点を主として説明し、第１実施形態と重複する説明を省略する。
次に、第１実施形態及びその変更例に係る動作を前提として第２実施形態について説明する。但し、第１実施形態とは異なる点を主として説明し、第１実施形態と重複する説明を省略する。
【0140】
第２実施形態は、二重接続（ＤＣ）を想定した実施形態であって、第１実施形態及びその変更例に係る動作と併用することが可能である。
【0141】
（動作例１）
図１０は、第２実施形態の動作例１を示す図である。
図１０は、第２実施形態の動作例１を示す図である。
【0142】
図１０に示すように、ＩＡＢノード３００は、上位装置Ａ１をＭＮとし、且つ上位装置Ａ２をセカンダリノード（ＳＮ）とする二重接続の通信を行っている。ＩＡＢノード３００には、下位装置Ｂが無線で接続されている。下位装置Ｂは、下位ＩＡＢノード又はＵＥである。
【0143】
ＩＡＢノード３００は、ＭＮである上位装置Ａ１との間に通信経路のためのバックホールリンクを設定せずに、上位装置Ａ１がＩＡＢノード３００を制御するための制御用リンクを設定している。ＩＡＢノード３００は、ＳＮである上位装置Ａ２との間に通信経路のためのバックホールリンクを設定している。
【0144】
二重接続を有するＩＡＢノード３００がＭＮとのバックホールリンク及びＳＮとのバックホールリンクの両方を設定している場合、ＳＮとのバックホールリンクにＢＨ ＲＬＦが発生しても、ＭＮとのバックホールリンクにＢＨ ＲＬＦが維持される限りは、ＩＡＢノード３００が下位装置ＢにＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信する必要は無いと考えられる。ＳＮとのバックホールリンクにＢＨ ＲＬＦが発生しても、ＭＮとのバックホールリンクが維持される限りは、下位装置ＢがＩＡＢノード３００に対する接続を維持してよいためである。
【0145】
一方、二重接続を有するＩＡＢノード３００がＭＮとのバックホールリンクを設定していない場合、ＩＡＢノード３００は、下位装置ＢのデータをＭＮと送受信できない。このため、ＳＮとのバックホールリンクにＢＨ ＲＬＦが発生した場合、下位装置ＢがＩＡＢノード３００を介したデータ送受信が不可になってしまうため、ＩＡＢノード３００が下位装置ＢにＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信するべきである。
【0146】
すなわち、本動作例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、ＩＡＢノード３００の上位の上位装置Ａ２をＳＮとし、且つ、他の装置（上位装置Ａ１）をＭＮとした二重接続の通信を行うことと、
２）ＩＡＢノード３００とＭＮとの間に通信経路のためのバックホールリンクを設定せずに、ＩＡＢノード３００とＳＮとの間にバックホールリンクを設定することと、
３）ＩＡＢノード３００が、ＩＡＢノード３００とＳＮとの間のＢＨ ＲＬＦを検知することと、ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００が、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに送信することと、を有する。
１）複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、ＩＡＢノード３００の上位の上位装置Ａ２をＳＮとし、且つ、他の装置（上位装置Ａ１）をＭＮとした二重接続の通信を行うことと、
２）ＩＡＢノード３００とＭＮとの間に通信経路のためのバックホールリンクを設定せずに、ＩＡＢノード３００とＳＮとの間にバックホールリンクを設定することと、
３）ＩＡＢノード３００が、ＩＡＢノード３００とＳＮとの間のＢＨ ＲＬＦを検知することと、ＢＨ ＲＬＦの検知に応じて、ＩＡＢノード３００が、ＢＨ ＲＬＦに関する障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００の下位の下位装置Ｂに送信することと、を有する。
【0147】
具体的には、本動作例において、二重接続の通信を行うＩＡＢノード３００は、ＭＮとの間にバックホールリンクが設定されているか否かに応じて、障害通知を下位装置Ｂに送信するか否かを決定する。具体的には、ＩＡＢノード３００は、ＭＮとの間にバックホールリンクが設定されていない場合、ＩＡＢノード３００とＳＮとの間のＢＨ ＲＬＦの検知に応じて、障害通知を下位装置Ｂに送信すると決定する。一方、ＭＮとの間にバックホールリンクが設定されている場合、ＩＡＢノード３００は、ＩＡＢノード３００とＳＮとの間のＢＨ ＲＬＦを検知しても、障害通知を下位装置Ｂに送信しないと決定する。
【0148】
本動作例において、ＬＴＥ及びＮＲによる二重接続（ＤＣ）、すなわち、ＥＮ－ＤＣ（Ｅ－ＵＴＲＡ（Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）－ＮＲ Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）を想定してもよい。このような想定下において、ＭＮ（上位装置Ａ１）はＬＴＥの装置であって、ＳＮ（上位装置Ａ２）はＮＲの装置である。例えば、ＭＮ（上位装置Ａ１）は、ＬＴＥ基地局であるｅＮＢであって、ＳＮ（上位装置Ａ２）は、ＮＲ基地局であるｇＮＢ（ドナー装置２００）又は上位ＩＡＢノードである。
【0149】
本動作例において、ＮＲのみによる二重接続（ＤＣ）、すなわち、ＮＲ－ＤＣ（ＮＲ Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ）を想定してもよい。このような想定下において、ＭＮ（上位装置Ａ１）はＮＲの装置であって、ＳＮ（上位装置Ａ２）もＮＲの装置である。例えば、ＭＮ（上位装置Ａ１）は、ＮＲ基地局であるｇＮＢ又は上位ＩＡＢノードであって、ＳＮ（上位装置Ａ２）は、ＮＲ基地局であるｇＮＢ又は上位ＩＡＢノードである。
【0150】
本動作例において、ＩＡＢノード３００は、バックホールリンクとして用いられるか否かを示す設定情報をドナー装置２００から受信し、この設定情報に基づいてバックホールリンクを設定及び識別してもよい。設定情報は、ＣＧ（Ｃｅｌｌ Ｇｒｏｕｐ）毎もしくはベアラ毎にバックホールリンクに用いられているか否かを示す情報であってもよい。
【0151】
（動作例２）
図１１は、第２実施形態の動作例２を示す図である。
図１１は、第２実施形態の動作例２を示す図である。
【0152】
図１１に示すように、下位装置Ｂは、上位装置Ａ１をＭＮとし、且つＩＡＢノード３００をセカンダリノード（ＳＮ）とする二重接続の通信を行っている。下位装置Ｂは、下位ＩＡＢノード又はＵＥである。このような前提下において、ＩＡＢノード３００は、ＩＡＢノード３００の上位装置Ａ２とのＢＨ ＲＬＦを検知した場合、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに送信する。この場合、ＳＮであるＩＡＢノード３００においてＢＨ ＲＬＦが発生したことをＭＮ（上位装置Ａ１）が把握できることが好ましい。なお、上位装置Ａ１はＩＡＢノード又は基地局であって、上位装置Ａ２はＩＡＢノード又は基地局（ドナー装置２００）である。
【0153】
すなわち、本動作例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）ＩＡＢノード３００の下位の下位装置Ｂが、ＩＡＢノード３００をＳＮとし、且つ、他の装置（上位装置Ａ１）をＭＮとした二重接続の通信を行うことと、
２）ＩＡＢノード３００が、ＩＡＢノード３００の上位の装置（上位装置Ａ２）とＩＡＢノード３００との間のＢＨ ＲＬＦを検知すると、第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を下位装置Ｂに送信することと、
３）下位装置Ｂが、ＳＮであるＩＡＢノード３００からの第１障害通知の受信に応じて、ＳＮにおけるＢＨ ＲＬＦを示す第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）をＭＮに送信することと、を有する。
１）ＩＡＢノード３００の下位の下位装置Ｂが、ＩＡＢノード３００をＳＮとし、且つ、他の装置（上位装置Ａ１）をＭＮとした二重接続の通信を行うことと、
２）ＩＡＢノード３００が、ＩＡＢノード３００の上位の装置（上位装置Ａ２）とＩＡＢノード３００との間のＢＨ ＲＬＦを検知すると、第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を下位装置Ｂに送信することと、
３）下位装置Ｂが、ＳＮであるＩＡＢノード３００からの第１障害通知の受信に応じて、ＳＮにおけるＢＨ ＲＬＦを示す第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）をＭＮに送信することと、を有する。
【0154】
なお、下位装置Ｂは、下位装置ＢとＩＡＢノード３００との間のＲＬＦを検知した場合、ＳＣＧ Ｆａｉｌｕｒｅ ＩｎｄｉｃａｔｉｏｎをＭＮに送信してもよい。一方、第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）は、下位装置ＢとＩＡＢノード３００との間でＲＬＦが検知されていなくても、ＩＡＢノード３００と上位装置Ａ２との間でＢＨ ＲＬＦが発生した場合には、下位装置ＢからＭＮに送信されるものである。なお、第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）は、ＳＣＧ Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎメッセージ中の情報要素としてもよいし、ＳＣＧ Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎメッセージとは異なるメッセージとしてもよい。
【0155】
下位装置Ｂは、ＳＣＧ障害の原因（Ｃａｕｓｅ）を示す情報として、“ＢＨ ＲＬＦ”を第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）に含めてもよい。第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）は、ＩＡＢノード３００又はそのセルを示す識別子を含んでもよい。
【0156】
下位装置Ｂから第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）を受信した上位装置Ａ１（ＭＮ）は、ＳＮであるＩＡＢノード３００側のリンクを他の上位装置に繋ぎ変えるために、ＳＮ変更（Ｓｅｃｏｎｄａｒｙ Ｎｏｄｅ Ｃｈａｎｇｅ）等の処理を行う。また、上位装置Ａ１（ＭＮ）は、第２障害通知（Ｆａｉｌｕｒｅ Ｉｎｄｉｃａｔｉｏｎ）に基づいて、ＤＣ設定が切断した（ｆａｉｌした）と判断し、ＳＮであるＩＡＢノード３００におけるＵＥコンテキストを解放する処理を実行してもよい。例えば、上位装置Ａ１（ＭＮ）とＩＡＢノード３００（ＳＮ）との間のインターフェイスを介して、ＵＥコンテキスト解放メッセージを上位装置Ａ１（ＭＮ）からＩＡＢノード３００（ＳＮ）に送信する。
【0157】
（動作例３）
図１２は、第２実施形態の動作例３を示す図である。
図１２は、第２実施形態の動作例３を示す図である。
【0158】
図１２に示すように、ＩＡＢノード３００は、ＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を行っている。ＭＮ３００Ｍ及びＳＮ３００Ｓのそれぞれは上位ＩＡＢノードである。ＭＮ３００Ｍは、自身の上位装置Ａ１とのＢＨ ＲＬＦを検知すると、ＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＩＡＢノード３００に送信する。ＳＮ３００Ｓは、自身の上位装置Ａ２とのＢＨ ＲＬＦを検知すると、ＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＩＡＢノード３００に送信する。上位装置Ａ１及びＡ２のそれぞれは上位ＩＡＢノード又は基地局である。なお、ＩＡＢノード３００とＭＮ３００Ｍとの間のリンクであるＭＣＧリンクにＲＬＦが発生しておらず、且つＩＡＢノード３００とＳＮ３００Ｓとの間のリンクであるＳＣＧリンクにＲＬＦが発生していないものとする。
【0159】
このような前提下において、ＩＡＢノード３００は、ＭＮ３００Ｍ及びＳＮ３００Ｓの両方からＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合に限り、下位装置Ｂに対してＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信する。言い換えると、ＩＡＢノード３００は、ＭＮ３００Ｍ及びＳＮ３００Ｓのうち一方のみからＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合には、下位装置Ｂに対してＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを送信しない。
【0160】
すなわち、本動作例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、ＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を行うことと、
２）ＭＮ３００Ｍが、ＭＮ３００Ｍの上位装置Ａ１とＭＮ３００Ｍとの間のＢＨ ＲＬＦを検知すると、第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００に送信することと、
３）ＳＮ３００Ｓが、ＳＮ３００Ｓの上位装置Ａ２とＳＮ３００Ｓとの間のＢＨ ＲＬＦを検知すると、第２障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００に送信することと、
４）ＩＡＢノード３００が、第１障害通知及び第２障害通知の両方を受信した場合、ＩＡＢノード３００の下位の下位装置Ｂに対して第３障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を送信することと、を有する。
１）当該複数のＩＡＢノード３００に含まれるＩＡＢノード３００が、ＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を行うことと、
２）ＭＮ３００Ｍが、ＭＮ３００Ｍの上位装置Ａ１とＭＮ３００Ｍとの間のＢＨ ＲＬＦを検知すると、第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００に送信することと、
３）ＳＮ３００Ｓが、ＳＮ３００Ｓの上位装置Ａ２とＳＮ３００Ｓとの間のＢＨ ＲＬＦを検知すると、第２障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）をＩＡＢノード３００に送信することと、
４）ＩＡＢノード３００が、第１障害通知及び第２障害通知の両方を受信した場合、ＩＡＢノード３００の下位の下位装置Ｂに対して第３障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を送信することと、を有する。
【0161】
ここで、ＩＡＢノード３００は、ＩＡＢノード３００とＭＮ３００Ｍとの間及びＩＡＢノード３００とＳＮ３００Ｓとの間においてＲＬＦが発生していなくても、第１障害通知及び第２障害通知の両方を受信した場合には、下位装置Ｂに対して第３障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を送信する。言い換えると、ＩＡＢノード３００は、自身の無線状態が良好であっても、ＭＮ３００Ｍ及びＳＮ３００Ｓの両方でＢＨ ＲＬＦが検知された場合には、下位装置Ｂに対して第３障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を送信する。
【0162】
ＩＡＢノード３００は、第１障害通知及び第２障害通知の両方を受信した場合、ＩＡＢノード３００におけるＢＨ ＲＬＦが発生したと見なしてもよい。ＩＡＢノード３００は、ＢＨ ＲＬＦが発生したと見なすことにより、結果的にＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂへ送信することになる。また、ＩＡＢノード３００は、ＢＨ ＲＬＦが発生したと見なすことにより、別の上位装置に対するＲＲＣ再確立を実施するなどの動作を行ってもよい。
【0163】
本動作例において、ＩＡＢノード３００は、第１障害通知及び第２障害通知の両方を受信し、且つ、ＩＡＢノード３００のバックホール通信が復旧しない状態が一定時間継続したと判定した場合、下位装置Ｂに対して第３障害通知を送信してもよい。すなわち、ＩＡＢノード３００は、第１障害通知及び第２障害通知の両方を受信して直ちに下位装置Ｂに第３障害通知を送信するのではなく、第１障害通知及び第２障害通知の両方を受信した後の一定時間内において自身のバックホール通信が復旧しないことを確認したうえで下位装置Ｂに対して第３障害通知を送信する。一方、ＩＡＢノード３００は、第１障害通知及び第２障害通知の両方を受信した後の一定時間内において自身のバックホール通信が復旧したと判定した場合、下位装置Ｂに対して第３障害通知を送信しない。
【0164】
図１３は、本動作例におけるＩＡＢノード３００の動作フロー図である。ここでは、ＭＮ３００Ｍ及びＳＮ３００Ｓのそれぞれが、ＢＨ ＲＬＦを検知している期間内においてＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを周期的に（連続的に）送信するものとする。
【0165】
図１３に示すように、ステップＳ２０１において、ＩＡＢノード３００は、ＭＮ３００Ｍ（ＭＣＧ）及びＳＮ３００Ｓ（ＳＣＧ）の両方、すなわち、全てのＣＧからＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信したか否かを判定する。
【0166】
全てのＣＧからＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した場合（ステップＳ２０１：Ｙｅｓ）、ステップＳ２０２において、ＩＡＢノード３００は、一定時間に対応するタイマを起動する。このタイマの値は、ＭＮ３００Ｍ又は上位装置Ａ１（例えばドナー装置）がＩＡＢノード３００に設定してもよい。
【0167】
ステップＳ２０３において、ＩＡＢノード３００は、ＭＮ３００Ｍ（ＭＣＧ）及びＳＮ３００Ｓ（ＳＣＧ）の両方、すなわち、全てのＣＧからのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの受信が継続しているか否かを判定する。ステップＳ２０３において「Ｎｏ」である場合、処理がステップＳ２０１に戻る。
【0168】
ステップＳ２０３において「Ｙｅｓ」である場合、ステップＳ２０４において、ＩＡＢノード３００は、ステップＳ２０２で起動したタイマが満了したか否かを判定する。ステップＳ２０４において「Ｎｏ」である場合、処理がステップＳ２０３に戻る。
【0169】
ステップＳ２０４において「Ｙｅｓ」である場合、ステップＳ２０５において、ＩＡＢノード３００は、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを下位装置Ｂに送信する。或いは、ステップＳ２０４において「Ｙｅｓ」である場合、ステップＳ２０５において、ＩＡＢノード３００は、自身のＢＨ ＲＬＦが発生したと見なしてもよい。
【0170】
図１３において、ＭＮ３００Ｍ及びＳＮ３００Ｓのそれぞれが、ＢＨ ＲＬＦを検知している期間内においてＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを周期的に（連続的に）送信することを想定している。しかしながら、第１実施形態において説明したように、ＭＮ３００Ｍ及びＳＮ３００Ｓのそれぞれは、ＢＨ ＲＬＦから復旧した際に復旧を示す通知（ＢＨ Ｒｅｃｏｖｅｒｅｄ）を送信してもよい。
【0171】
このような通知（ＢＨ Ｒｅｃｏｖｅｒｅｄ）を用いる前提下においては、ＩＡＢノード３００は、ステップＳ２０３において、少なくとも一方のＣＧからＢＨ Ｒｅｃｏｖｅｒｅｄを受信したか否かを判定してもよい。そして、ＩＡＢノード３００は、少なくとも一方のＣＧからＢＨ Ｒｅｃｏｖｅｒｅｄを受信した場合、ステップＳ２０１に処理を戻す。一方、ＩＡＢノード３００は、いずれのＣＧからもＢＨ Ｒｅｃｏｖｅｒｅｄを受信していない場合、ステップＳ２０４に処理を進める。
【0172】
また、図１３のステップＳ２０３において「Ｎｏ」と判定するケースとしては、ＩＡＢノード３００が、両方のＣＧからＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎを受信した後、別の上位装置に対するＲＲＣ再確立に成功したケースが含まれる。
【0173】
（動作例４）
図１４は、第２実施形態の動作例４を示す図である。
図１４は、第２実施形態の動作例４を示す図である。
【0174】
図１４に示すように、下位装置Ｂは、ＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続（ＮＲ－ＤＣ）の通信を行っている。下位装置Ｂは、ＩＡＢノード又はＵＥである。ＭＮ３００Ｍ及びＳＮ３００Ｓのそれぞれは、ＩＡＢノードである。ＭＮ３００Ｍと上位装置Ａ１との間にはバックホールリンクが設定されており、ＳＮ３００Ｓと上位装置Ａ２との間にはバックホールリンクが設定されている。
【0175】
本動作例においては、ＭＮ（ＭＣＧ）及びＳＮ（ＳＣＧ）の両方がバックホールリンクに設定されている場合、ＭＮ（ＭＣＧ）からのみＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信が許可される。
【0176】
すなわち、本動作例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）当該複数のＩＡＢノード３００に含まれるＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を下位装置Ｂが行うことと、
２）ＭＮ３００Ｍが上位装置Ａ１とＭＮ３００Ｍとの間のＢＨ ＲＬＦを検知すると、ＭＮ３００Ｍが第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を下位装置Ｂに送信することと、
３）ＳＮ３００ＳがＳＮ３００Ｓの上位装置Ａ２とＳＮ３００Ｓとの間のＢＨ ＲＬＦを検知すると、ＭＮ３００Ｍが第２障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を下位装置Ｂに送信することとを有する。
１）当該複数のＩＡＢノード３００に含まれるＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を下位装置Ｂが行うことと、
２）ＭＮ３００Ｍが上位装置Ａ１とＭＮ３００Ｍとの間のＢＨ ＲＬＦを検知すると、ＭＮ３００Ｍが第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を下位装置Ｂに送信することと、
３）ＳＮ３００ＳがＳＮ３００Ｓの上位装置Ａ２とＳＮ３００Ｓとの間のＢＨ ＲＬＦを検知すると、ＭＮ３００Ｍが第２障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）を下位装置Ｂに送信することとを有する。
【0177】
本動作例において、ＳＮ３００ＳのＢＨ ＲＬＦが発生した場合、ＳＮ３００Ｓは、ＭＮ３００ＭとＳＮ３００Ｓとの間のインターフェイスを用いて、ＳＮ３００ＳのＢＨ ＲＬＦに関する情報をＳＮ３００ＳからＭＮ３００Ｍに送信する。ＳＮ３００Ｓの上位装置Ａ２がＳＮ３００ＳのＢＨ ＲＬＦを検知可能である場合、上位装置Ａ２からドナー装置２００を介してＳＮ３００ＳのＢＨ ＲＬＦに関する情報をＭＮ３００Ｍに送信してもよい。
【0178】
ここで、第１障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）は、ＭＮ３００ＭのＢＨ ＲＬＦの発生を示す情報を含み、第２障害通知（ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎ）は、ＳＮ３００ＳのＢＨ ＲＬＦの発生を示す情報を含む。これにより、下位装置Ｂは、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信をＭＮ３００Ｍのみが行う場合であっても、ＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎに含まれる情報に基づいてＢＨ ＲＬＦがＭＮ３００Ｍ及びＳＮ３００Ｓのいずれで発生したかを把握できる。
【0179】
本動作例において、ＳＮ３００Ｓは、ドナー装置２００（ＣＵ）からの通知又はＭＮ３００Ｍからの通知に基づいて、ＭＮ３００Ｍがバックホールリンクを有するか否かを特定する。ＳＮ３００Ｓは、ＭＮ３００Ｍがバックホールリンクを有する場合、ＳＮ３００Ｓから下位装置ＢへのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信を禁止する。一方、ＳＮ３００Ｓは、ＭＮ３００Ｍがバックホールリンクを有しない場合、ＳＮ３００Ｓから下位装置ＢへのＢＨ ＲＬＦ Ｎｏｔｉｆｉｃａｔｉｏｎの送信を可能とする。
【0180】
（動作例５）
図１５は、第２実施形態の動作例５を示す図である。
図１５は、第２実施形態の動作例５を示す図である。
【0181】
図１５に示すように、下位装置Ｂは、ＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を行っている。ＭＮ３００Ｍ及びＳＮ３００Ｓのそれぞれは、ＩＡＢノードである。ＭＮ３００Ｍと上位装置Ａ１との間にはバックホールリンクが設定されており、ＳＮ３００Ｓと上位装置Ａ２との間にはバックホールリンクが設定されている。本動作例においては、ＭＮ３００ＭとＳＮ３００Ｓとの間にインターフェイスが存在しないものとする。
【0182】
本動作例において、下位装置Ｂは、ＳＮ３００ＳのＢＨ ＲＬＦが発生している場合、ＳＮ３００Ｓ宛てのメッセージをＭＮ３００Ｍから受信し、受信したメッセージをＳＮ３００Ｓに転送する。ＳＮ３００Ｓ宛てのメッセージとは、例えば基地局間インターフェイス（Ｘｎインターフェイス）用のメッセージ、又はＣＵ・ＤＵ間インターフェイス（Ｆ１インターフェイス）用のメッセージであって、ＳＮ３００Ｓを解放するための解放メッセージである。
【0183】
すなわち、本動作例に係る通信制御方法は、ＵＥ１００とドナー装置２００との間に複数のＩＡＢノード３００を用いた少なくとも１つの通信経路を形成可能な移動通信システム１において用いる通信制御方法であって、
１）当該複数のＩＡＢノード３００に含まれるＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を下位装置Ｂが行うことと、
２）ＳＮ３００Ｓが上位装置Ａ２とＳＮ３００Ｓとの間のＢＨ ＲＬＦを検知した後、下位装置Ｂが、ＳＮ３００Ｓ宛てのメッセージをＭＮ３００Ｍから受信することと、
３）下位装置Ｂが、ＭＮ３００Ｍから受信したメッセージをＳＮ３００Ｓに転送することと、を有する。
１）当該複数のＩＡＢノード３００に含まれるＭＮ３００Ｍ及びＳＮ３００Ｓとの二重接続の通信を下位装置Ｂが行うことと、
２）ＳＮ３００Ｓが上位装置Ａ２とＳＮ３００Ｓとの間のＢＨ ＲＬＦを検知した後、下位装置Ｂが、ＳＮ３００Ｓ宛てのメッセージをＭＮ３００Ｍから受信することと、
３）下位装置Ｂが、ＭＮ３００Ｍから受信したメッセージをＳＮ３００Ｓに転送することと、を有する。
【0184】
これにより、ＳＮ３００ＳのＢＨ ＲＬＦが検知され、ＭＮ３００ＭとＳＮ３００Ｓとの間にインターフェイスが存在しない場合であっても、ＳＮ３００Ｓは、ＭＮ３００Ｍからのメッセージを受信できる。
【0185】
本動作例は、次の手順を含む。
【0186】
第１に、下位装置Ｂは、ＳＮ３００ＳのＢＨ ＲＬＦを示すＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＳＮ３００Ｓから受信する。下位装置Ｂは、ＳＮ３００ＳのＢＨ ＲＬＦを示すＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＭＮ３００Ｍから受信してもよい（動作例４参照）。下位装置Ｂは、ＳＮ３００ＳのＢＨ ＲＬＦを示すＢＨ ＲＬＦ ＮｏｔｉｆｉｃａｔｉｏｎをＳＮ３００Ｓから受信すると、Ｆａｉｌｕｒｅ ＩｎｄｉｃａｔｉｏｎをＭＮ３００Ｍに送信してもよい（動作例２参照）。
【0187】
第２に、ＭＮ３００Ｍ又はドナー装置２００は、ネットワークインターフェース（Ｘｎ／Ｆ１等）の中継を下位装置Ｂに指示する。ＭＮ３００Ｍ又はドナー装置２００は、下位装置Ｂのルーティングテーブル情報に例外ルーティングの設定を行ってもよい。この設定は、ＳＮ３００Ｓ又はそのセルのＩＤ、及びＳＮ３００ＳのＢＡＰレイヤのエンティティのＩＤのいずれかを含む。下位装置Ｂは、ＳＮ３００Ｓに対して、下位装置Ｂを経由する例外ルーティングが設定されたことの通知、又は下位装置Ｂを経由する例外ルーティングの要求を行ってもよい。下位装置Ｂは、下位装置Ｂを経由する中継ルートが確立できたか否かをＭＮ３００Ｍ又はドナー装置２００に通知（応答）してもよい。中継ルートが確立不可（ＮＧ）の通知の場合、その原因を示す情報として、ＳＮ３００Ｓの拒否、下位装置Ｂの拒否などの情報を通知に含めてもよい。
【0188】
第３に、ＭＮ３００Ｍ又はドナー装置２００は、中継ルートへネットワークインターフェースのメッセージ（例えば、Ｓｅｃｏｎｄａｒｙ Ｎｏｄｅ Ｒｅｌｅａｓｅメッセージ）を送信する。当該メッセージはカプセル化され、例えばＲＲＣメッセージ又はＢＡＰ制御メッセージにより運ばれる。
【0189】
第４に、下位装置Ｂは、カプセル化されたメッセージを、上述した例外ルーティング情報に従ってＳＮ３００Ｓへ転送する。
【0190】
第５に、ＳＮ３００Ｓは、カプセル化されたメッセージを受信し、受信したメッセージに準じる動作を行う。例えば、ＳＮ３００Ｓは、Ｓｅｃｏｎｄａｒｙ Ｎｏｄｅ Ｒｅｌｅａｓｅ受信時に、無線リソースの使用停止などの処理を行う。ＳＮ３００Ｓは、Ｓｅｃｏｎｄａｒｙ Ｎｏｄｅ Ｒｅｌｅａｓｅ Ａｃｋｎｏｗｌｅｄｇｅを、例外ルーティングを用いて、下位装置Ｂ経由でＭＮ３００Ｍ又はドナー装置２００に対して返してもよい。
【0191】
［その他の実施形態］
上述した各実施形態及びその変更例において、移動通信システム１が５Ｇ移動通信システムである一例について主として説明した。しかしながら、移動通信システム１における基地局はＬＴＥ基地局であるｅＮＢであってもよい。また、移動通信システム１におけるコアネットワークはＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されてもよい。
上述した各実施形態及びその変更例において、移動通信システム１が５Ｇ移動通信システムである一例について主として説明した。しかしながら、移動通信システム１における基地局はＬＴＥ基地局であるｅＮＢであってもよい。また、移動通信システム１におけるコアネットワークはＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されてもよい。
【0192】
上述した各実施形態及びその変更例に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。ＵＥ１００、ｇＮＢ２００、又はＩＡＢノード３００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。
【0193】
なお、各図において示されるフローは、適宜組み合わされても良い。
【0194】
［付記］
（導入）
バックホールリンクの無線リンク障害（ＢＨ ＲＬＦ）について、ＲＡＮ２は次の合意に達した。
（導入）
バックホールリンクの無線リンク障害（ＢＨ ＲＬＦ）について、ＲＡＮ２は次の合意に達した。
【0195】
・Ｒ２は、少なくともダウンストリームノードへのＢＨリンクＲＬＦにおけるＲＬＦ通知があると想定する。
【0196】
・ＢＨリンクの障害における回復時に、（合意されている場合）代替ルート及び／又はデュアルコネクティビティを利用され得る。
【0197】
・現在のＵＥ ＲＬＦの検出及び回復はベースラインとして再利用される。
【0198】
・例えば、リンクが回復したとき、または回復が進行中のとき、他のインディケーションが必要かどうかは更なる検討が必要である。
【0199】
合意に加えて、ＲＡＮ２は、ダウンストリームノード向けのＲＬＦ通知及びアップストリームノード向けのＲＬＦ通知を含むＲＬＦ通知の詳細を議論した。
【0200】
この付記では、ＢＨ ＲＬＦハンドリングの残りの問題、特にダウンストリームノードへのＲＬＦ通知に焦点を当てて議論する。
【0201】
なお、この付記では、「親」ノードが「子」ノードにＲＬＦ通知を送信するという関係を想定する。
【0202】
（議論）
（ＲＬＦ通知およびその他のインディケーション）
Ｒｅｌ－１５ ＵＥは、引き続きＩＡＢノードとの接続を許可されるが、合意された「ＲＬＦ通知」はＲｅｌ－１６機能であることに注意すべきである。Ｒｅｌ－１５ ＵＥでもサービスの停止を最小限に抑えるためには、バックホールリンクを回復することに失敗した場合、ＩＡＢノードはＳＳＢ（ＰＳＳ、ＳＳＳ、及びＰＢＣＨ）の送信を停止すべきである。なぜならば、ＩＡＢノードがバックホールリンクなしではサービスを継続できないことは明らかであり、またＲｅｌ－１５ ＵＥに対して意図的に無線問題を生み出すからである。
（ＲＬＦ通知およびその他のインディケーション）
Ｒｅｌ－１５ ＵＥは、引き続きＩＡＢノードとの接続を許可されるが、合意された「ＲＬＦ通知」はＲｅｌ－１６機能であることに注意すべきである。Ｒｅｌ－１５ ＵＥでもサービスの停止を最小限に抑えるためには、バックホールリンクを回復することに失敗した場合、ＩＡＢノードはＳＳＢ（ＰＳＳ、ＳＳＳ、及びＰＢＣＨ）の送信を停止すべきである。なぜならば、ＩＡＢノードがバックホールリンクなしではサービスを継続できないことは明らかであり、またＲｅｌ－１５ ＵＥに対して意図的に無線問題を生み出すからである。
【0203】
所見１：合意された「ＲＬＦ通知」はＲｅｌ－１５ ＵＥでは機能できない。
【0204】
提案１：ＲＡＮ２は、バックホールリンクを回復することに失敗した場合、ＩＡＢノードがＳＳＢの送信を停止することに合意すべきである。
【0205】
また、提案１は、バックホールリンクが回復することに失敗するまで、ＩＡＢノードはサービスを提供し続けてもよいことを暗示する。次に、「例えば、リンクが回復したとき、または回復が進行中のとき、他のインディケーションが必要かどうかは更なる検討が必要である」ように、バックホールリンク状態についてダウンストリームのＭＴ／ＵＥに通知する価値があるかどうかを更に検討する必要がある。ただし、ＢＨ ＲＬＦ中にＲＬＦ通知が繰り返し送信される場合は、「その他のインディケーション」を指定する必要はない。言い換えれば、ＲＬＦ通知が送信されない場合、ＢＨ ＲＬＦは発生していない、又はすでに回復されており、そうでない場合は、バックホールリンクの回復が進行中である。したがって、論点は、ＢＨ ＲＬＦ中にＲＬＦ通知を繰り返し送信するかどうかである。
【0206】
提案２：ＲＡＮ２は、ＲＬＦ通知がＢＨ ＲＬＦ中に繰り返し送信されることに合意すべきである。
【0207】
（ＲＲＣコネクティッド）
ＢＨ ＲＬＦが親ＩＡＢノードで発生している間、アップリンクデータが子ＩＡＢノード／ＵＥからＩＡＢドナーに到達できないことは明らかである。アップリンク送信が続く場合、子ＩＡＢノード／ＵＥでの電力消費、親ＩＡＢノードでのバッファのオーバーフローのリスク、及びネットワークでの干渉などの不要な問題を発生させる可能性がある。したがって、子ノード／ＵＥは、少なくとも新しいデータ送信においてＳＲ送信を控えるべきである。
ＢＨ ＲＬＦが親ＩＡＢノードで発生している間、アップリンクデータが子ＩＡＢノード／ＵＥからＩＡＢドナーに到達できないことは明らかである。アップリンク送信が続く場合、子ＩＡＢノード／ＵＥでの電力消費、親ＩＡＢノードでのバッファのオーバーフローのリスク、及びネットワークでの干渉などの不要な問題を発生させる可能性がある。したがって、子ノード／ＵＥは、少なくとも新しいデータ送信においてＳＲ送信を控えるべきである。
【0208】
提案３：ＲＡＮ２は、ＲＬＦ通知を受信時に、ＭＴ／ＵＥがアップリンク信号、つまりデータ送信用のＳＲを停止することに合意すべきである。
【0209】
親ＩＡＢノードがそのバックホールリンクでＲＬＦを受けるとＲＬＦ通知が送信されるが、そのアクセスリンクはまだ良好である可能性がある。言い換えると、ＲＬＦは、親ＩＡＢノードと子ＩＡＢノードとの間のリンクでは発生していない。ＲＡＮ２は「現在のＵＥ ＲＬＦ検出及び回復はベースラインとして再利用される」ことに合意しているため、子ノード／ＵＥはＲＬＦを宣言せず、この場合はＲＬＦ通知をトリガしない。
【0210】
追加ルールとしてＲＬＦ通知の受信が既存のＲＬＦをトリガする場合、さらにそれはダウンストリームノードへのＲＬＦ通知の送信をトリガし、それはＩＡＢトポロジ間ですぐに伝搬される。これは、全てのＩＡＢノードに同時にＲＲＣ再確立を開始させ、ＩＡＢトポロジを壊す可能性がある。したがって、ＲＬＦ通知の受信はＲＲＣ再確立をトリガしない。
【0211】
提案４：ＲＡＮ２は、ＭＴ／ＵＥがＲＬＦ通知の受信時にＲＲＣ再確立の開始を含むＲＬＦを宣言せず、ＲＬＦ通知の送信もトリガしないことに合意すべきである。
【0212】
（ＲＲＣアイドル）
別の態様は、ＲＲＣアイドルでのＭＴ／ＵＥのふるまいである。提案３が同意できる場合、アイドルモードのＭＴ／ＵＥがＢＨ ＲＬＦを受ける親ＩＡＢノードへのＲＲＣセットアップ要求を開始することを控えることは、非常に簡単である。これにより、一種のアクセス制限と見なすことができる。たとえＲＲＣセットアップ要求メッセージが送信された場合でも、ＢＨ ＲＬＦのためにＩＡＢドナー（つまり、ピアＲＲＣエンティティを有するＣＵ）に転送できず、手順は結局失敗する。
別の態様は、ＲＲＣアイドルでのＭＴ／ＵＥのふるまいである。提案３が同意できる場合、アイドルモードのＭＴ／ＵＥがＢＨ ＲＬＦを受ける親ＩＡＢノードへのＲＲＣセットアップ要求を開始することを控えることは、非常に簡単である。これにより、一種のアクセス制限と見なすことができる。たとえＲＲＣセットアップ要求メッセージが送信された場合でも、ＢＨ ＲＬＦのためにＩＡＢドナー（つまり、ピアＲＲＣエンティティを有するＣＵ）に転送できず、手順は結局失敗する。
【0213】
提案５：ＲＡＮ２は、ＲＲＣアイドルであるＭＴ／ＵＥが、ＲＬＦ通知を送信している親ＩＡＢノードへのＲＲＣセットアップ要求を開始することを控えるべきであることに合意すべきである。
【0214】
論点は、セル再選択プロセスがＢＨ ＲＬＦをどのようにハンドリングするか、つまり、ＢＨ ＲＬＦを送信する親ＩＡＢノードが再選択の候補セルであるかどうかである。ＢＨ ＲＬＦが短時間で回復され得る場合、そのような最適化は必要ない。そうではない場合、ＭＴ／ＵＥが結局ＢＨリンクなしにセルでＲＲＣ接続を確立できないため、悪いユーザーエクスペリエンスを引き起こす可能性がある。
【0215】
提案６：ＲＡＮ２は、ＲＲＣアイドルのＭＴ／ＵＥが、ＲＬＦ通知を送信する親ＩＡＢノードを再選択できるかどうかについて議論すべきである。
【0216】
（デュアルコネクティビティの場合の検討）
デュアルコネクティビティは複雑なシナリオの１つですが、ＲＡＮ２は「ＢＨリンクの障害における回復時に、（合意されている場合）代替ルート及び／又はデュアルコネクティビティを利用され得る」ことに合意した。これは、親がデュアルコネクティビティを有するケース（つまり、図１７のケース１）、及び子がデュアルコネクティビティを有するケース（つまり、図１７のケース２）の２つのケースに分類できる。
デュアルコネクティビティは複雑なシナリオの１つですが、ＲＡＮ２は「ＢＨリンクの障害における回復時に、（合意されている場合）代替ルート及び／又はデュアルコネクティビティを利用され得る」ことに合意した。これは、親がデュアルコネクティビティを有するケース（つまり、図１７のケース１）、及び子がデュアルコネクティビティを有するケース（つまり、図１７のケース２）の２つのケースに分類できる。
【0217】
（ケース１(親がＤＣで設定される)
ケース1では、ＲＬＦ通知はＭＣＧ ＲＬＦ又はＳＣＧ ＲＬＦのいずれかによってトリガされてもよい。ＥＮ－ＤＣ（つまり、ＣプレーンがＬＴＥ Ｕｕ上にある）の場合、ＲＮ２が「ＥＮ－ＤＣを使用するＩＡＢノードの場合、ＢＡＰおよびバックホールＲＬＣチャネルの観点から、これは単一リンクの展開（ＮＲリンクによるＢＡＰルートのみ）である」ことに合意したように、バックホールリンクにＭＣＧを使用することは想定されていない。したがって、ＲＬＦがＳＣＧリンクでのみ発生する場合でも、ＩＡＢトポロジの観点からは、ＢＨ ＲＬＦと見なすべきである。これは、ＲＬＦ通知がＳＣＧ ＲＬＦで親ＩＡＢノードによって送信されるべきであることも意味する。
ケース1では、ＲＬＦ通知はＭＣＧ ＲＬＦ又はＳＣＧ ＲＬＦのいずれかによってトリガされてもよい。ＥＮ－ＤＣ（つまり、ＣプレーンがＬＴＥ Ｕｕ上にある）の場合、ＲＮ２が「ＥＮ－ＤＣを使用するＩＡＢノードの場合、ＢＡＰおよびバックホールＲＬＣチャネルの観点から、これは単一リンクの展開（ＮＲリンクによるＢＡＰルートのみ）である」ことに合意したように、バックホールリンクにＭＣＧを使用することは想定されていない。したがって、ＲＬＦがＳＣＧリンクでのみ発生する場合でも、ＩＡＢトポロジの観点からは、ＢＨ ＲＬＦと見なすべきである。これは、ＲＬＦ通知がＳＣＧ ＲＬＦで親ＩＡＢノードによって送信されるべきであることも意味する。
【0218】
所見２：ＥＮ－ＤＣで設定されたＩＡＢノードの場合、ＳＣＧ ＲＬＦはＲＬＦ通知をトリガすべきである。
【0219】
一方、ＮＲ－ＤＣの場合、バックホールリンクはＳＣＧのみ、又はＳＣＧ及びＭＣＧの両方に設定されてもよい。言うまでもなく、前者のケース（ＳＣＧのみのＢＨ）はＥＮ－ＤＣのケースと同様である。後者の場合（ＭＣＧ及びＳＣＧの両方でＢＨ）、ＳＣＧ ＲＬＦがＲＬＦ通知をトリガしないことは明らかですが、ＭＣＧ ＲＬＦが常にＲＬＦ通知をトリガするかどうかは疑わしい。
【0220】
現在の仕様では、ＵＥは、ＭＣＧ ＲＬＦでＳＣＧへのＵＬ送信を停止（ＲＲＣ再確立で「ＳＲＢ０を除く全てのＲＢをサスペンド」）する。これにより、ＢＨ ＲＬＦと見なすことができる。一方、ＭＣＧ ＲＬＦが発生してもＳＣＧリンクの品質は良好であり、堅牢なバックホールのために使用され続ける可能性がある。したがって、ＵＬ送信の停止に関する現在の原則は、ＭＣＧリンクに障害が発生した場合にＳＣＧリンクを使用すべきかどうかに応じて、再検討される必要がある可能性がある。例えば、ＤＣＣＡ ＷＩで議論されている高速ＭＣＧリンク回復メカニズムである。
【0221】
所見３：ＮＲ－ＤＣで設定されＳＣＧにのみＢＨがあるＩＡＢノードの場合、ＳＣＧ ＲＬＦはＲＬＦ通知をトリガする（所見２と同様）。
【0222】
提案７：ＲＡＮ２は、バックホールリンクがＳＣＧのみで構成されている場合（つまり、ＥＮ－ＤＣ及びＳＣＧのみバックホールを備えたＮＲ－ＤＣ）、ＳＣＧ ＲＬＦがＲＬＦ通知をトリガすることに合意すべきである。
【0223】
提案８：ＲＡＮ２は、ＭＣＧ ＲＬＦが常にＲＬＦ通知をトリガすることに合意すべきである。
【0224】
所見４：ＭＣＧ ＲＬＦのときにＳＣＧリンクが使用されている場合、ＵＬ送信の停止に関する現在の原則を再検討する必要がある可能性がある。ＤＣＣＡ ＷＩにおけるＭＣＧリンクの高速復旧について議論することが期待される。
【0225】
（ケース２（子がＤＣで設定される））
ケース２では、子ＩＡＢノードの観点からのデュアルコネクティビティにより、２つの親ＩＡＢノードがバックホールリンクのために利用できる。したがって、論点は、どの親ＩＡＢノードがそのＢＨ ＲＬＦでＲＬＦ通知を送信するかである。1つのアプローチは、ＢＨ ＲＬＦがＭＣＧ（つまり、ＭＮ）又はＳＣＧ（つまり、ＳＮ）に関連付けられたバックホールリンクで発生するかどうかに関係なく、ＭＣＧが常にＲＬＦ通知を送信することである。ＭＣＧは子ＩＡＢノードとのＣプレーン接続を有するため、これは理にかなっているであろう。但し、これは、ＳＣＧ（ＳＮ）がそのＢＨ ＲＬＦをＭＣＧ（ＭＮ）に通知しなければならないことを意味する。ＢＨ ＲＬＦ下において、ノード間接続が必ずしも利用できるとは限らない（図１７参照）。
ケース２では、子ＩＡＢノードの観点からのデュアルコネクティビティにより、２つの親ＩＡＢノードがバックホールリンクのために利用できる。したがって、論点は、どの親ＩＡＢノードがそのＢＨ ＲＬＦでＲＬＦ通知を送信するかである。1つのアプローチは、ＢＨ ＲＬＦがＭＣＧ（つまり、ＭＮ）又はＳＣＧ（つまり、ＳＮ）に関連付けられたバックホールリンクで発生するかどうかに関係なく、ＭＣＧが常にＲＬＦ通知を送信することである。ＭＣＧは子ＩＡＢノードとのＣプレーン接続を有するため、これは理にかなっているであろう。但し、これは、ＳＣＧ（ＳＮ）がそのＢＨ ＲＬＦをＭＣＧ（ＭＮ）に通知しなければならないことを意味する。ＢＨ ＲＬＦ下において、ノード間接続が必ずしも利用できるとは限らない（図１７参照）。
【0226】
したがって、ＭＣＧでのＲＬＦ通知及びＳＣＧでのＲＬＦ通知は分離されている方が簡単である。つまり、ＭＣＧはそのＢＨ ＲＬＦでのみＲＬＦ通知を送信し、ＳＣＧはそのＢＨ ＲＬＦでのみＲＬＦ通知を送信する。デュアルコネクティビティ下で各ＣＧに２つの個別のＭＡＣが設定されているため、ＲＬＦ通知にＭＡＣ ＣＥが使用されている場合、これは容易である。
【0227】
提案９：ＲＡＮ２は、ＲＬＦ通知がＭＡＣ ＣＥを介してＭＣＧ又はＳＣＧのいずれかによって送信される可能性があることに合意すべきである。
【0228】
一方、子ＩＡＢノードは、ＳＣＧからＲＬＦ通知を受信すると、提案３が受け入れられる場合、ＳＣＧへのＵＬ送信を停止する。これは実際には一種のＳＣＧ障害と見なされる可能性があり、子ＩＡＢノードはＭＣＧがトポロジの適合（例えば、セカンダリノードの変更）を行うことを期待する場合がある。ただし、IABトポロジによっては、ＳＣＧのＢＨリンクに障害が発生した場合、ＭＣＧはＳＣＧのＢＨリンクが（少なくとも一時的に）切断されていることを認識しない可能性があり、適切なアクションをとることはできない可能性がある。したがって、子ノードが、例えば、障害情報又はＳＣＧ障害情報を介して、ＳＣＧからＲＬＦ通知を受信した場合に、ＭＣＧに通知できるかどうかを検討すべきである。
【0229】
提案１０：ＲＡＮ２は、ＳＣＧからＲＬＦ通知を受信した場合に、ＭＴ/ＵＥがＭＣＧに通知することを許可されるかどうかについて議論すべきである。
【0230】
本願は、米国仮出願第６２/８８４２６８号（２０１９年８月８日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】