特許 7606009 通信制御方法、中継ノード、セルラ通信システム、チップセット、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-16

(45)【発行日】2024-12-24

(54)【発明の名称】通信制御方法、中継ノード、セルラ通信システム、チップセット、及びプログラム

(51)【国際特許分類】

   H04W 16/26 20090101AFI20241217BHJP

   H04W 76/19 20180101ALI20241217BHJP

   H04W 92/20 20090101ALI20241217BHJP

   H04W 72/0457 20230101ALI20241217BHJP

   H04B 7/15 20060101ALI20241217BHJP

【ＦＩ】

H04W16/26

H04W76/19

H04W92/20 110

H04W72/0457 110

H04B7/15

【請求項の数】 6

(21)【出願番号】P 2023554697

(86)(22)【出願日】2022-10-18

(86)【国際出願番号】 JP2022038728

(87)【国際公開番号】W WO2023068258

(87)【国際公開日】2023-04-27

【審査請求日】2024-04-18

(31)【優先権主張番号】63/257,246

(32)【優先日】2021-10-19

(33)【優先権主張国・地域又は機関】US

【早期審査対象出願】

(73)【特許権者】

【識別番号】000006633

【氏名又は名称】京セラ株式会社

(74)【代理人】

【識別番号】110001106

【氏名又は名称】弁理士法人キュリーズ

(72)【発明者】

【氏名】藤代 真人

(72)【発明者】

【氏名】チャン ヘンリー

【審査官】桑江 晃

(56)【参考文献】

【文献】国際公開第２０２０／０９０９８７（ＷＯ，Ａ１）

【文献】国際公開第２０２０／１１９６３７（ＷＯ，Ａ１）

【文献】Qualcomm Incorporated，Status on RAN WI NR_IAB[online]，3GPP TSG SA WG3 #95 S3-191516，Internet<URL:https://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_95_Reno/Docs/S3-191516.zip>，2019年05月10日，１－１１頁

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４ － ７／２６

Ｈ０４Ｂ ７／１５

Ｈ０４Ｗ ４／００ － ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

セルラ通信システムで用いる通信制御方法であって、
中継ノードがＬＴＥの第１ノードをマスターノードとし、ＮＲの第２ノードをセカンダリノードとして、ＥＮ－ＤＣによる二重接続方式が設定されることと、
前記中継ノードが、前記第１ノードとの間の第１無線リンクと、前記第２ノードとの間の第２無線リンクとのうち、前記第２無線リンクに無線リンク障害を検知したことに応じて、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信することと、
前記中継ノードが、前記第１通知を送信した後、前記無線リンク障害から回復したことに応じて、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信することと、を有する。
通信制御方法。

【請求項2】

前記中継ノードが、前記第１無線リンクと前記第２無線リンクとのうち、前記第１無線リンクに無線リンク障害を検知しても、前記第１通知を前記子ノードへ送信しないよう制御することをさらに有する
請求項１に記載の通信制御方法。

【請求項3】

セルラ通信システムで用いる中継ノードであって、ＬＴＥの第１ノードをマスターノードとし、ＮＲの第２ノードをセカンダリノードとして、ＥＮ－ＤＣによる二重接続方式が設定される処理と、
前記第１ノードとの間の第１無線リンクと、前記第２ノードとの間の第２無線リンクとのうち、前記第２無線リンクに無線リンク障害を検知したことに応じて、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信する処理と、
前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信する処理と、を実行するプロセッサを備える、
中継ノード。

【請求項4】

請求項３に記載の中継ノードを備えるセルラ通信システム。

【請求項5】

請求項１に記載の通信制御方法を実行するチップセット。

【請求項6】

請求項１に記載の通信制御方法を中継ノードに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、セルラ通信システムに用いる通信制御方法に関する。

【背景技術】

【0002】

セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Third Generation Partnership Project）において、ＩＡＢ（Integrated Access and Backhaul）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．７．０（２０２１－０９）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。

【発明の概要】

【0003】

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定されることと、前記中継ノードが、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信することと、前記中継ノードが、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信することと、を有する。

【0004】

第２の態様に係る中継ノードは、セルラ通信システムで用いる中継ノードである。前記中継ノードは、プロセッサを備える。前記プロセッサは、マスターセルグループを管理する第１親ノードをマスターノードとし、セカンダリセルグループを管理する第２親ノードをセカンダリノードとして、二重接続方式が設定される処理と、前記第１親ノードとの間の第１バックホールリンクと、前記第２親ノードとの間の第２バックホールリンクのうちの一方のリンク上に無線リンク障害を検知した場合、前記無線リンク障害の検知を示す第１通知を、子ノードへ送信する処理と、前記第１通知を送信した後、前記無線リンク障害から回復した場合、前記無線リンク障害から回復したことを示す第２通知を、前記子ノードへ送信する処理と、を実行する。

【図面の簡単な説明】

【0005】

【図1】図１は、一実施形態に係るセルラ通信システムの構成例を示す図である。

【図2】図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を示す図である。

【図3】図３は、一実施形態に係るｇＮＢ（基地局）の構成例を示す図である。

【図4】図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を示す図である。

【図5】図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を示す図である。

【図6】図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。

【図7】図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を示す図である。

【図8】図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を示す図である。

【図9】図９は、第１実施形態に係るノード間の構成例を表す図である。

【図10】図１０は、第１実施形態に係るノード間の構成例を表す図である。

【図11】図１１は、第１実施形態に係る動作例を表す図である。

【図12】図１２は、第１実施形態に係るノード間の構成例を表す図である。

【図13】図１３は、第２実施形態に係るノード間の構成例を表す図である。

【図14】図１４は、第２実施形態に係る動作例を表す図である。

【図15】図１５は、第３実施形態に係る動作例を表す図である。

【図16】図１６は、第４実施形態に係る動作例を表す図である。

【図17】図１７（Ａ）と図１７（Ｂ）は第５実施形態に係るノード間の構成例を表す図である。

【図18】図１８は、第５実施形態に係る動作例を表す図である。

【図19】図１９は、第６実施形態に係るノード間の構成例を表す図である。

【図20】図２０は、第６実施形態に係る動作例を表す図である。

【図21】図２１（Ａ）から図２１（Ｃ）は、第７実施形態に係るトポロジの構成例を表す図である。

【図22】図２２は、付記にかかる動作例を表す図である。

【図23】図２３は、付記にかかる動作例を表す図である。

【発明を実施するための形態】

【0006】

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

【0007】

（セルラ通信システムの構成）
一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システム１は３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（New Radio）である。但し、セルラ通信システム１には、ＬＴＥ（Long Term Evolution）が少なくとも部分的に適用されてもよい。また、セルラ通信システム１は、６Ｇなど、将来のセルラ通信システムも適用されてよい。

【0008】

図１は、一実施形態に係るセルラ通信システム１の構成例を示す図である。

【0009】

図１に示すように、セルラ通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ装置（ＵＥ：User Equipment）１００、基地局装置（以下、「基地局」と称する場合がある。）２００－１，２００－２、及びＩＡＢノード３００－１，３００－２を有する。基地局２００は、ｇＮＢと呼ばれる場合がある。

【0010】

以下において、基地局２００がＮＲ基地局である一例について主として説明するが、基地局２００がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。

【0011】

なお、以下において、基地局２００－１，２００－２をｇＮＢ２００（又は基地局２００）、ＩＡＢノード３００－１，３００－２をＩＡＢノード３００とそれぞれ称する場合がある。

【0012】

５ＧＣ１０は、ＡＭＦ（Access and Mobility Management Function）１１及びＵＰＦ（User Plane Function）１２を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Non-Access Stratum）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。

【0013】

各ｇＮＢ２００は、固定の無線通信ノードであって、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。以下では、セルと基地局とを区別しないで用いる場合がある。

【0014】

各ｇＮＢ２００は、ＮＧインターフェイスと呼ばれるインターフェイスを介して５ＧＣ１０と相互に接続される。図１において、５ＧＣ１０に接続された２つのｇＮＢ２００－１及びｇＮＢ２００－２を例示している。

【0015】

各ｇＮＢ２００は、集約ユニット（ＣＵ：Central Unit）と分散ユニット（ＤＵ：Distributed Unit）とに分割されていてもよい。ＣＵ及びＤＵは、Ｆ１インターフェイスと呼ばれるインターフェイスを介して相互に接続される。Ｆ１プロトコルは、ＣＵとＤＵとの間の通信プロトコルであって、制御プレーンのプロトコルであるＦ１－ＣプロトコルとユーザプレーンのプロトコルであるＦ１－Ｕプロトコルとがある。

【0016】

セルラ通信システム１は、バックホールにＮＲを用いてＮＲアクセスの無線中継を可能とするＩＡＢをサポートする。ドナーｇＮＢ２００－１（又はドナーノード。以下、「ドナーノード」と称する場合がある。）は、ネットワーク側のＮＲバックホールの終端ノードであり、ＩＡＢをサポートする追加機能を備えたドナー基地局である。バックホールは、複数のホップ（すなわち、複数のＩＡＢノード３００）を介するマルチホップが可能である。

【0017】

図１において、ＩＡＢノード３００－１がドナーノード２００－１と無線で接続し、ＩＡＢノード３００－２がＩＡＢノード３００－１と無線で接続し、Ｆ１プロトコルが２つのバックホールホップで伝送される一例を示している。

【0018】

ＵＥ１００は、セルとの無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であってもよい。例えば、ＵＥ１００は、携帯電話端末やタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置、飛行体若しくは飛行体に設けられる装置である。ＵＥ１００は、アクセスリンクを介してＩＡＢノード３００又はｇＮＢ２００に無線で接続する。図１において、ＵＥ１００がＩＡＢノード３００－２と無線で接続される一例を示している。ＵＥ１００は、ＩＡＢノード３００－２及びＩＡＢノード３００－１を介してドナーノード２００－１と間接的に通信する。

【0019】

図２は、ＩＡＢノード３００と親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係例を示す図である。

【0020】

図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Mobile Termination）とを有する。

【0021】

ＩＡＢ－ＭＴのＮＲ Ｕｕ無線インターフェイス上の隣接ノード（すなわち、上位ノード）は、親ノードと呼ばれる。親ノードは、親ＩＡＢノード又はドナーノード２００のＤＵである。ＩＡＢ－ＭＴと親ノードとの間の無線リンクは、バックホールリンク（ＢＨリンク）と呼ばれる。図２において、ＩＡＢノード３００の親ノードがＩＡＢノード３００－Ｐ１及び３００－Ｐ２である一例を示している。なお、親ノードへ向かう方向は、アップストリーム（ｕｐｓｔｒｅａｍ）と呼ばれる。ＵＥ１００から見て、ＵＥ１００の上位ノードは親ノードに該当し得る。

【0022】

ＩＡＢ－ＤＵのＮＲアクセスインターフェイス上の隣接ノード（すなわち、下位ノード）は、子ノードと呼ばれる。ＩＡＢ－ＤＵは、ｇＮＢ２００と同様に、セルを管理する。ＩＡＢ－ＤＵは、ＵＥ１００及び下位のＩＡＢノードへのＮＲ Ｕｕ無線インターフェイスを終端する。ＩＡＢ－ＤＵは、ドナーノード２００－１のＣＵへのＦ１プロトコルをサポートする。図２において、ＩＡＢノード３００の子ノードがＩＡＢノード３００－Ｃ１～３００－Ｃ３である一例を示しているが、ＩＡＢノード３００の子ノードにＵＥ１００が含まれてもよい。なお、子ノードへ向かう方向は、ダウンストリーム（ｄｏｗｎｓｔｒｅａｍ）と呼ばれる。

【0023】

また、１つ又は複数のホップを介して、ドナーノード２００に接続されている全てのＩＡＢノード３００は、ドナーノード２００をルートとする有向非巡回グラフ（ＤＡＧ：Directed Acyclic Graph）トポロジ（以下、「トポロジ」と称する場合がある。）を形成する。このトポロジにおいて、図２に示すように、ＩＡＢ－ＤＵのインターフェイス上の隣り合うノードが子ノード、ＩＡＢ－ＭＴのインターフェイス上の隣り合うノードが親ノードとなる。ドナーノード２００は、例えば、ＩＡＢトポロジのリソース、トポロジ、ルート管理などを集中的に行う。ドナーノード２００は、バックホールリンクとアクセスリンクのネットワークを介して、ＵＥ１００に対して、ネットワークアクセスを提供するｇＮＢである。

【0024】

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

【0025】

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

【0026】

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

【0027】

制御部２３０は、ｇＮＢ２００における各種の制御を行う。制御部２３０は、少なくとも１つのメモリと、メモリと電気的に接続された少なくとも１つのプロセッサとを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサとＣＰＵとを含んでもよい。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各レイヤの処理を行う。また、制御部２３０は、以下に示す各実施形態において、ｇＮＢ２００における各処理又は各動作を行ってもよい。

【0028】

（中継ノードの構成）
次に、実施形態に係る中継ノード（又は中継ノード装置。以下、「中継ノード」と称する場合がある。）であるＩＡＢノード３００の構成について説明する。図４は、ＩＡＢノード３００の構成例を示す図である。図４に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを有する。ＩＡＢノード３００は、無線通信部３１０を複数有していてもよい。

【0029】

無線通信部３１０は、ｇＮＢ２００との無線通信（ＢＨリンク）及びＵＥ１００との無線通信（アクセスリンク）を行う。ＢＨリンク通信用の無線通信部３１０とアクセスリンク通信用の無線通信部３１０とが別々に設けられていてもよい。

【0030】

無線通信部３１０は、受信部３１１及び送信部３１２を有する。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。

【0031】

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

【0032】

（ユーザ装置の構成）
次に、実施形態に係るユーザ装置であるＵＥ１００の構成について説明する。図５は、ＵＥ１００の構成例を示す図である。図５に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを有する。

【0033】

無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信を行う。また、無線通信部１１０は、サイドリンクにおける無線通信、すなわち、他のＵＥ１００との無線通信を行ってもよい。無線通信部１１０は、受信部１１１及び送信部１１２を有する。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換（ダウンコンバート）して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換（アップコンバート）してアンテナから送信する。

【0034】

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

【0035】

（プロトコルスタックの構成）
次に、実施形態に係るプロトコルスタックの構成について説明する。図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。

【0036】

図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Medium Access Control）レイヤと、ＲＬＣ（Radio Link Control）レイヤと、ＰＤＣＰ（Packet Data Convergence Protocol）レイヤと、ＲＲＣ（Radio Resource Control）レイヤと、ＮＡＳ（Non-Access Stratum）レイヤとを有する。

【0037】

ＰＨＹレイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＨＹレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＰＨＹレイヤとの間では、物理チャネルを介してデータ及び制御情報が伝送される。

【0038】

ＭＡＣレイヤは、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びランダムアクセスプロシージャ等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＭＡＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御情報が伝送される。ＩＡＢ－ＤＵのＭＡＣレイヤはスケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及び割当リソースブロックを決定する。

【0039】

ＲＬＣレイヤは、ＭＡＣレイヤ及びＰＨＹレイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＬＣレイヤとＩＡＢノード３００－１のＩＡＢ－ＤＵのＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御情報が伝送される。

【0040】

ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＰＤＣＰレイヤとドナーノード２００のＰＤＣＰレイヤとの間では、無線ベアラを介してデータ及び制御情報が伝送される。

【0041】

ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＲＲＣレイヤとドナーノード２００のＲＲＣレイヤとの間では、各種設定のためのＲＲＣシグナリングが伝送される。ドナーノード２００とのＲＲＣ接続がある場合、ＩＡＢ－ＭＴはＲＲＣコネクティッド状態である。ドナーノード２００とのＲＲＣ接続がない場合、ＩＡＢ－ＭＴはＲＲＣアイドル状態である。

【0042】

ＲＲＣレイヤの上位に位置するＮＡＳレイヤは、セッション管理及びモビリティ管理等を行う。ＩＡＢノード３００－２のＩＡＢ－ＭＴのＮＡＳレイヤとＡＭＦ１１との間では、ＮＡＳシグナリングが伝送される。

【0043】

図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックを示す図である。図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックを示す図である。ここでは、ドナーノード２００がＣＵ及びＤＵに分割されている一例を示す。

【0044】

図７に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴ、ＩＡＢノード３００－１のＩＡＢ－ＤＵ、ＩＡＢノード３００－１のＩＡＢ－ＭＴ、及びドナーノード２００のＤＵの各々は、ＲＬＣレイヤの上位レイヤとしてＢＡＰ（Backhaul Adaptation Protocol）レイヤを有する。ＢＡＰレイヤは、ルーティング処理及びベアラマッピング・デマッピング処理を行うレイヤである。バックホールでは、ＩＰレイヤがＢＡＰレイヤを介して伝送されることにより、複数のホップでのルーティングが可能になる。

【0045】

各バックホールリンクにおいて、ＢＡＰレイヤのＰＤＵ（Protocol Data Unit）は、バックホールＲＬＣチャネル（ＢＨ ＮＲ ＲＬＣチャネル）によって伝送される。各ＢＨリンクで複数のバックホールＲＬＣチャネルを構成することにより、トラフィックの優先順位付け及びＱｏＳ制御が可能である。ＢＡＰ ＰＤＵとバックホールＲＬＣチャネルとの対応付けは、各ＩＡＢノード３００のＢＡＰレイヤ及びドナーノード２００のＢＡＰレイヤによって実行される。

【0046】

図８に示すように、Ｆ１－Ｃプロトコルのプロトコルスタックは、図７に示すＧＴＰ－Ｕレイヤ及びＵＤＰレイヤに代えて、Ｆ１ＡＰレイヤ及びＳＣＴＰレイヤを有する。

【0047】

なお、以下においては、ＩＡＢのＩＡＢ－ＤＵとＩＡＢ－ＭＴで行われる処理又は動作について、単に「ＩＡＢ」の処理又は動作として説明する場合がある。例えば、ＩＡＢノード３００－１のＩＡＢ－ＤＵが、ＩＡＢノード３００－２のＩＡＢ－ＭＴへＢＡＰレイヤのメッセージを送信することを、ＩＡＢノード３００－１がＩＡＢノード３００－２へ、当該メッセージを送信するものとして説明する。また、ドナーノード２００のＤＵ又はＣＵの処理又は動作についても、単に「ドナーノード」の処理又は動作として説明する場合がある。

【0048】

また、アップストリーム方向とアップリンク（ＵＬ）方向とを区別しないで用いる場合がある。更に、ダウンストリーム方向とダウンリンク（ＤＬ）方向とを区別しないで用いる場合がある。

【0049】

［第１実施形態］
次に、第１実施形態について説明する。

【0050】

最初に、第１実施形態に係るＴｙｐｅ２ ＢＨ ＲＬＦ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ３ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎについて説明する。

【0051】

（Ｔｙｐｅ２ ＢＨ ＲＬＦ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ３ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ）
図９は、第１実施形態に係るノード間の構成例を示す図である。

【0052】

図９に示すセルラ通信システム１は、ＩＡＢノード３００－Ｔ、親ノード（ＩＡＢノード）３００－Ｐ１と親ノード３００－Ｐ２、及び子ノード（ＩＡＢノード）３００－Ｃを含む。

【0053】

ＩＡＢノード３００－Ｐ１は、ＩＡＢノード３００－Ｔの親ノードである。以下、ＩＡＢノード３００－Ｐ１を親ノード３００－Ｐ１と称する場合がある。親ノード３００－Ｐ１のＩＡＢ－ＤＵとＩＡＢノード３００－ＴのＩＡＢ－ＭＴとの間でバックホールリンク（ＢＨリンク）＃１が確立されている。なお、親ノード３００－Ｐ１は、ドナーノード２００（のＤＵ＃１）であってもよい。

【0054】

ＩＡＢノード３００－Ｐ２も、ＩＡＢノード３００－Ｔの親ノードである。以下、ＩＡＢノード３００－Ｐ２を親ノード３００－Ｐ２と称する場合がある。親ノード３００－Ｐ２のＩＡＢ－ＤＵとＩＡＢノード３００－ＴのＩＡＢ－ＭＴとの間でもＢＨリンク＃２が確立されている。なお、親ノード３００－Ｐ２は、ドナーノード２００（のＤＵ＃２）であってもよい。

【0055】

ＩＡＢノード３００－Ｃは、ＩＡＢノード３００－Ｔの子ノードである。以下、ＩＡＢノード３００－Ｃを子ノード３００－Ｃと称する場合がある。子ノード３００－ＣのＩＡＢ－ＭＴとＩＡＢノード３００－ＴのＩＡＢ－ＤＵとの間でもＢＨリンク＃３が確立されている。

【0056】

このような構成において、ＢＨリンク＃１で無線リンク障害（ＢＨ ＲＬＦ（Radio Link Failure））が発生し、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴがこのＢＨ ＲＬＦを検知した仮定する。

【0057】

ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、ダウンストリーム側の子ノード３００－Ｃへ、Ｔｙｐｅ１ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ１ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦを検知したことを示す障害発生通知の一例である。

【0058】

また、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、当該ＢＨ ＲＬＦに対する回復動作を検知した場合、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、子ノード３００－Ｃへ、Ｔｙｐｅ２ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦからの回復を試行中であることを示す回復試行通知（又は障害発生通知）の一例である。

【0059】

なお、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、Ｔｙｐｅ１ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎとを区別しないときは、子ノードへ、Ｔｙｐｅ１／２ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎも、障害発生通知の一例である。

【0060】

ここで、Ｔｙｐｅ１ ＩｎｄｉｃａｔｉｏｎをＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎと読み替えてもよい。Ｔｙｐｅ１ ＩｎｄｉｃａｔｉｏｎはＢＨ ＲＬＦ検出時、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎは回復試行時に、それぞれ送信される。しかし、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＢＨ ＲＬＦ検出後、直ちに、ＢＨ ＲＬＦの回復試行処理を行う。そのため、２つのＩｎｄｉｃａｔｉｏｎを実質的に同じＩｎｄｉｃａｔｉｏｎと見ることができる。

【0061】

更に、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、当該ＢＨ ＲＬＦからの回復を検知した場合、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、子ノード３００－Ｃへ、Ｔｙｐｅ３ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎは、ＢＨリンクがＢＨ ＲＬＦからリカバリしたことを示す回復通知でもよい。

【0062】

更に、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴが、当該ＢＨ ＲＬＦからの回復に失敗したことを検知した場合、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵは、子ノードへ、Ｔｙｐｅ４ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎ（以下、「Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎ」と称する場合がある。）を送信できる。Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎは、ＢＨリンクがＢＨ ＲＬＦからリカバリに失敗したことを示す失敗通知でもある。

【0063】

図９では、ＩＡＢノード３００－Ｔが、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを、子ノード３００－Ｃへ送信する例を表している。

【0064】

なお、これらのＴｙｐｅ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎは、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵ又はＭＡＣ ＣＥに含まれて送信されてもよい。

【0065】

（二重接続方式（ＤＣ：Dual Connectivity））
ＩＡＢノード３００－Ｔは、２つの異なる親ノード３００－Ｐ１及び３００－Ｐ２から提供されるリソースを利用することが可能である。一方の親ノードが、マスターセルグループ（以下、「ＭＣＧ」と称する場合がある。）を管理するマスターノード（ＭＮ）となり得る。他方の親ノードが、セカンダリセルグループ（以下、「ＳＣＧ」と称する場合がある。）を管理するセカンダリノード（ＳＮ）となり得る。

【0066】

ＭＣＧは、マスターノードに関連付けられているサービングセルのセルグループである。ＭＣＧは、プライマリセル（Ｓｐセル又はＰセル）と、オプションで１以上のセカンダリセル（Ｓセル）とを有する。

【0067】

ＳＣＧは、セカンダリノードに関連付けられているサービングセルのグループである。ＳＣＧは、プライマリセル（Ｓｐセル又はＰＳセル）と、オプションで１以上のセカンダリセル（Ｓセル）とを有する。Ｓｐセルは、ＭＣＧにおけるプライマリセルであり、ＳＣＧにおけるプライマリセルでもある。

【0068】

ここで、マスターノードとセカンダリノードは、論理的なエンティティ（ｅｎｔｉｔｙ）である。第１実施形態では、マスターノードは親ノード３００－Ｐ１に対応し、セカンダリノードは親ノード３００－Ｐ２に対応するものとして、以下説明する。

【0069】

ＩＡＢノード３００－Ｔは、ＭＣＧを管理するマスターノードと接続しつつ、ＳＣＧを管理するセカンダリノードと接続することができる。この場合、ＩＡＢノード３００－Ｔは、各親ノード３００－Ｐ１及び３００－Ｐ２に同時に接続して、無線通信を行う。これにより、ＩＡＢノード３００－Ｔでは、スループット向上を図ることができる。

【0070】

二重接続方式（以下、「ＤＣ」と称する場合がある。）の種類の１つとして、ＥＮ－ＤＣ（（E-UTRA(Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity））がある。ＥＮ－ＤＣでは、ＩＡＢノード３００－Ｔは、マスターノードとして機能する１つのｅＮＢ（evolved Node B）と接続されるとともに、セカンダリノードとして機能する１つのｅｎ－ｇＮＢと接続される。ｅＮＢは、Ｅ－ＵＴＲＡサービスを提供するＬＴＥ基地局である。また、ｅｎ－ｇＮＢは、ＮＲサービスを提供するＮＲ基地局である。例えば、図９の例では、マスターノードである親ノード３００－Ｐ１がｅＮＢ、セカンダリノードである親ノード３００－Ｐ２がｅｎ－ｇＮＢとなり得る。ＥＮ－ＤＣでは、ＭＣＧが制御（Ｃ－Ｐｌａｎｅ）に関する処理を行う。一方、ＳＣＧはデータ（Ｕ－Ｐｌａｎｅ）に関する処理を行う。

【0071】

ＤＣの種類には、他にもＮＲ－ＤＣ（NR-NR Dual Connectivity）がある。ＮＲ－ＤＣは、マスターノードもセカンダリノードもｇＮＢである。ＮＲ－ＤＣでは、ＭＣＧもＳＣＧも、ともに、制御とデータに関する処理を行うことができる。そのため、例えば、ＩＡＢノード３００－Ｔは、ともにｇＮＢである親ノード３００－Ｐ１及び３００－Ｐ２との間で同時にデータを送受信できる。

【0072】

（第１実施形態に係る通信制御方法）
３ＧＰＰでは、シングル接続の場合、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの生成（又は送信）は、ＢＨ ＲＬＦ（以下、「ＲＬＦ」と称する場合がある。）検出時であることが合意されている。

【0073】

一方、ＤＣの場合、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎがどのような場合に送信されるのかについては、３ＧＰＰではまだ決定されていない。

【0074】

ＤＣの場合についても、シングル接続の場合と同様に、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの生成（又は送信）は、ＲＬＦ検出時とすることも可能である。

【0075】

この場合、２つのケースが考えられる。すなわち、ＭＣＧ側で発生したＲＬＦが検知されて、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎが送信されるケースと、ＳＣＧ側で発生したＲＬＦが検知されて、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎが送信されるケースである。図９は、前者のケースの例を示し、図１０は、後者のケースの例を示している。

【0076】

このような場合において、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した子ノード３００－Ｃは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信しただけでは、ＭＣＧ側でＲＬＦが発生しているのか、ＳＣＧ側でＲＬＦが発生しているのか、分からない場合がある。

【0077】

そこで、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏに付加情報を付加して送信することができる。付加情報を受信した子ノード３００－Ｃは、付加情報に基づいて、ルーティング処理又はリルーティング処理などを行うことが可能となる。

【0078】

更に、ＭＣＧ側とＳＣＧ側の双方でＲＬＦが（同時に）発生する場合もある。この場合、子ノード３００－Ｃは、ＭＣＧ側で発生したＲＬＦに対応するＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎと、ＳＣＧ側で発生したＲＬＦに対応するＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの２つを受信する。

【0079】

その後、ＭＣＧ側で発生したＲＬＦが回復したと仮定する。この場合、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを、子ノード３００－Ｃへ送信する。

【0080】

子ノード３００－Ｃは、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信しても、ＭＣＧ側で発生したＲＬＦが回復したのか、ＳＣＧ側で発生したＲＬＦが回復したのか、わからない場合がある。

【0081】

そこで、第１実施形態では、ＩＡＢノード３００－ＴがＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎに付加情報を付加して、子ノード３００－Ｃへ送信する。

【0082】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、マスターセルグループを管理する第１親ノード（例えば、親ノード３００－Ｐ１）をマスターノードとし、セカンダリセルグループを管理する第２親ノード（例えば、親ノード３００－Ｐ２）をセカンダリノードとして、二重接続方式が設定される。第２に、中継ノードが、第１親ノードとの間の第１バックホールリンク（例えば、ＢＨリンク＃１）と、第２親ノードとの間の第２バックホールリンク（例えば、ＢＨリンク＃２）のうち、少なくともいずれかで発生した無線リンク障害から回復したことを示す第２通知（例えば、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ）を、子ノード（例えば、子ノード３００－Ｃ）へ送信する。ここで、第２通知は、第２付加情報を含み、第２付加情報は、少なくとも、使用可能となった第２ルーティングＩＤを示す。

【0083】

これにより、例えば、子ノード３００－Ｃは、使用可能になったルーティングＩＤに基づいて、ローカルリルーティングを実行していた場合に通常のルーティング動作に戻すなど、適切な処理を行うことが可能となる。

【0084】

なお、ルーティングＩＤは、宛先ＢＡＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ）と経路識別子（Ｐａｔｈ ＩＤ）とにより構成される。

【0085】

（第１実施形態に係る動作例）
図１１は、第１実施形態に係る動作例を表す図である。

【0086】

図１１に示すように、ステップＳ１０において、ＩＡＢノード３００－Ｔは、処理を開始する。

【0087】

なお、ＩＡＢノード３００－Ｔは、ステップＳ１０の後、ステップＳ１１の前において、ＤＣが設定されるものとする。すなわち、ＩＡＢノード３００－Ｔは、ＭＣＧを管理する親ノード３００－Ｐ１をマスターノードとし、ＳＣＧを管理する親ノード３００－Ｐ２をセカンダリノードとして、ＤＣが設定されるものとする。

【0088】

ステップＳ１１において、ＩＡＢノード３００－Ｔは、ＲＬＦを検知する（又はＲＬＦから復旧中であることを検知する）。ＲＬＦは、ＭＣＧ側のＢＨリンク＃１でもよいし、ＳＣＧ側のＢＨリンク＃２でもよい。また、ＲＬＦは、ＭＣＧ側のＢＨリンク＃１とＳＣＧ側のＢＨリンク＃２とで同時に発生してもよい。ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＲＬＦが各ＢＨリンクで同時に発生した場合でも個別に発生した場合でも、ＲＬＦ毎に当該ＲＬＦを検知してもよい。

【0089】

ステップＳ１２において、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃへ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する。ＩＡＢノード３００－Ｔは、検知したＲＬＦ毎に独立してＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する。例えば、ＩＡＢノード３００－Ｔは、ＭＣＧ側のＢＨリンク＃１で発生したＲＬＦを検知すると、当該ＲＬＦに対応するＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信し、ＳＣＧ側のＢＨリンク＃２で発生したＲＬＦを検知すると、当該ＲＬＦに対応するＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する。

【0090】

ここで、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎに付加情報を付加して送信する。付加情報は、当該ＲＬＦによって影響を受けるルートの情報であってもよい。

【0091】

具体的には、付加情報は、使用不可能なＣＧ（例えば、ＭＣＧが使用不可能か、ＳＣＧが使用不可能かを示す情報）、使用不可能なルーティングＩＤ、及び使用不可能なリンク品質の少なくともいずれかを含んでもよい。更に、付加情報は、使用不可能なＢＨ ＲＬＣ チャネルＩＤ（ＢＨ ＲＬＣ ｃｈａｎｎｅｌ ＩＤ）を含んでもよい。子ノード３００－Ｃは、使用不可能なＢＨ ＲＬＣチャネルＩＤを受信することで、当該ＢＨ ＲＬＣチャネルへの送信を停止したり、他のＢＨ ＲＬＣチャネルへのルーティングを行ったりすることが可能となる。

【0092】

なお、子ノード３００－Ｃは、付加情報を含むＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信したことにより、他の親ノードへのローカルリルーティングを実行するものとして、以下説明する。ローカルリルーティングとは、例えば、ある親ノードから、代替パス上の他の親ノードへ送信を切り替えることである。図９の例では、子ノード３００－Ｃは、ＩＡＢノード３００－Ｔ（子ノード３００－Ｃにとって親ノード）から、代替パス上の他のＩＡＢノード（子ノード３００－Ｃにとって別の親ノード）へ送信を切り替える。

【0093】

図１１に戻り、ステップＳ１３において、ＩＡＢノード３００－Ｔは、ＢＨリンクで発生したＲＬＦの復旧を検知する。ＩＡＢノード３００－Ｔは、ＭＣＧ側におけるＲＬＦからの復旧と、ＳＣＧ側におけるＲＬＦからの復旧について、それぞれ独立して検知する。

【0094】

ステップＳ１４において、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃへ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信する。ＩＡＢノード３００－Ｔは、ＭＣＧ側におけるＲＬＦからの復旧を検知すると、当該復旧に対応するＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信し、ＳＣＧ側におけるＲＬＦからの復旧を検知すると、当該復旧に対応するＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信する。

【0095】

図１２は、第１実施形態に係るノード間の構成例を表す図である。図１２に示すように、ＩＡＢノード３００－Ｔは、子ノード３００－Ｃへ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信する。

【0096】

ここで、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎに付加情報を付加して送信する。付加情報は、当該復旧により影響を受けるルートの情報であってもよい。

【0097】

具体的には、付加情報は、使用可能となったＣＧ（例えば、使用可能となったのはＭＣＧであるのかＳＣＧであるのかを示す情報）、使用可能となったルーティングＩＤ、使用可能なリンク品質（例えば、使用可能なスループットの更新）、及び使用可能となったＢＨ ＲＬＣチャネルＩＤの少なくともいずれかを含む。

【0098】

ステップＳ１５において、子ノード３００－Ｃは、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信したことに応じて、付加情報に従って、ローカルリルーティング動作を停止し、通常のルーティング動作を行う。例えば、子ノード３００－Ｃは、使用可能となったルーティングＩＤについて、ローカルリルーティングを停止する。また、例えば、子ノード３００－Ｃは、使用可能となったルーティングＩＤ＃１を付加情報として受信し、ルーティングＩＤ＃２についてローカルリルーティングを実行していたと仮定する。この場合、ルーティングＩＤ＃２は依然として、使用不可能なルーティングＩＤである。子ノード３００－Ｃは、ルーティングＩＤ＃２については、ローカルリルーティングを継続することになる。

【0099】

このように、付加情報を受信した子ノード３００－Ｃは、復旧により影響を受けるルートの情報を把握することができ、付加情報に従って、通信を制御することが可能となる。

【0100】

そして、ステップＳ１６において、子ノード３００－Ｃは、一連の処理を終了する。

【0101】

（第１実施形態の変形例）
第１実施形態では、ＩＡＢノード３００－Ｔは、付加情報を含むＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信する例について説明した。例えば、ＩＡＢノード３００－Ｔは、付加情報を含まないＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信してもよい。この場合、子ノード３００－Ｃは、当該Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎに関連するＢＨリンクの全てのルーティングＩＤが使用可能になったと判断してもよい。

【0102】

［第２実施形態］
次に、第２実施形態について説明する。

【0103】

ローカルリルーティングに関して、ドナーＤＵ間リルーティングが行われる場合がある。ドナー間リルーティングとは、例えば、ドナーノード２００の第１ＤＵから当該ドナーノード２００の第２ＤＵへ経路が切り替わるリルーティングのことである。

【0104】

図１３は、第２実施形態に係るノード間の構成例を表す図である。図１３は、ドナー間リルーティングの例を表している。

【0105】

図１３の例では、ドナー間リルーティングにより、ドナーノード２００のＤＵ＃１（以下、「ドナーＤＵ＃１」）（２００Ｄ１）から、ドナーノード２００のＤＵ＃２（以下、「ドナーＤＵ＃２」）（２００Ｄ２）へ切り替えられる。この場合、アップストリーム方向のパケットの宛先が、ドナーＤＵ＃１のＢＡＰアドレスから、ドナーＤＵ＃２のＢＡＰアドレスへと変更されることになる。

【0106】

なお、図１３では、第１実施形態と同様に、ＩＡＢノード３００－Ｔと、親ノード３００－Ｐ１及び３００－Ｐ２とにおいて、ＤＣ設定が行われた例を表している。

【0107】

そして、ＩＡＢノード３００－Ｔは、ＭＣＧ側のＢＨリンク又はＳＣＧ側のＢＨリンクでＲＬＦを検知した場合、付加情報を含むＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信できる。

【0108】

ここで、ＩＡＢノード３００－Ｔは、ＭＣＧ側のＢＨリンクでのＲＬＦを検知した場合、当該付加情報として、ＭＣＧ側に紐づいた宛先（Ｄｅｓｔｉｎａｔｉｏｎ：ドナーＤＵ＃１のＢＡＰアドレス）を有する全てのルーティングＩＤを、送信する場合もある。

【0109】

また、ＩＡＢノード３００－Ｔは、ＳＣＧ側のＢＨリンクでのＲＬＦを検知した場合、当該付加情報として、ＳＣＧ側に紐づいた宛先（Ｄｅｓｔｉｎａｔｉｏｎ：ドナーＤＵ＃２（２００Ｄ２）のＢＡＰアドレス）を有する全てのルーティングＩＤを、送信する場合もある。

【0110】

しかし、ＩＡＢノード３００－Ｔが、付加情報として、宛先に紐づいた全てのルーティングＩＤを送信するには、付加情報のオーバーヘッドが大きい。

【0111】

そこで、第２実施形態では、ＩＡＢノード３００－Ｔは、使用不可能になった宛先ＢＡＰアドレスをＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの付加情報として、子ノード３００－Ｃへ送信する例について説明する。

【0112】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、親ノード（例えば、親ノード３００－Ｐ１）との間のバックホールリンクで発生した無線リンク障害により、使用不可能となったルーティングＩＤに含まれる宛先ＢＡＰアドレスを確認する。第２に、中継ノードが、無線リンク障害に対して回復試行中であることを示す第１通知を、子ノード（例えば、子ノード３００－Ｃ）へ送信する。ここで、第１通知は、付加情報を含み、付加情報は、宛先ＢＡＰアドレスを含む。

【0113】

これにより、ＩＡＢノード３００－Ｔは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎに付加される付加情報のサイズをコンパクトにして、付加情報のオーバーヘッドを抑制することができる。

【0114】

（第２実施形態に係る動作例）
図１４は、第２実施形態に係る動作例を表す図である。

【0115】

図１４に示すように、ステップＳ２０において、ＩＡＢノード３００－Ｔは、処理を開始する。

【0116】

ステップＳ２１において、ＩＡＢノード３００－Ｔは、ＲＬＦを検知する（又はＲＬＦから復旧中であることを検知する）。

【0117】

ステップＳ２２において、ＩＡＢノード３００－Ｔは、ルーティング可能なルーティングＩＤと、ルーティングが不可能なルーティングＩＤとを特定する。具体的には、例えば、以下となる。

【0118】

第１に、シングル接続の場合である。シングル接続とは、ＩＡＢノード３００－Ｔに代替パスが存在せず、１つの親ノード３００－Ｐとのみ接続された形態である。シングル接続の場合、代替パスが存在しないため、全てのルーティングＩＤがルーティング不可能なルーティングＩＤとなる。この場合、ルーティング可能なルーティングＩＤは存在しない。そのため、シングル接続の場合、全てのルーティングＩＤがルーティング不可能なルーティングＩＤとなり得る。

【0119】

第２に、ＤＣ接続の場合である。例えば、ＩＡＢノード３００－Ｔが、２つの親ノード３００－Ｐ１及び３００－Ｐ２に同時に接続された場合である。なお、ＤＣ接続が行われる場合、ステップＳ２０とステップＳ２１の間で、ＩＡＢノード３００－Ｔに対してＤＣ設定が行われるものとする。

【0120】

ＤＣ接続の場合、イントラドナーＤＵ（「Ｉｎｔｒａ－ｄｏｎｏｒ－ＤＵ」）によってルーティング又はリルーティングが行われる場合がある。イントラドナーＤＵは、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）は同じであって、複数の経路が存在する形態である。イントラドナーＤＵの場合、ＲＬＦを検知するものの、代替パスが存在するため、一部のルーティングＩＤは使用不可能であるものの、それ以外のルーティングＩＤは使用可能である。

【0121】

ＤＣ接続の場合、ドナーＤＵ間（「Ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ」）によってルーティング又はリルーティングが行われる場合がある。ドナー間ＤＵは、例えば、図１３に示すように、ドナーノードの異なるＤＵ間で、ルーティング又はリルーティングが行われる形態である。ドナー間ＤＵの場合、当該ＲＬＦが発生しているＢＨリンクの上流のＤｅｓｔｉｎａｔｉｏｎ（例えば、ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）がルーティング不可能となる。そのため、当該Ｄｅｓｔｉｎａｔｉｏｎを有する全てのルーティングＩＤが使用不可能となる。他方、別のＢＨリンクの上流のＤｅｓｔｉｎａｔｉｏｎ（ドナーＤＵ＃２（２００Ｄ２）のＢＡＰアドレス）については、経路上ではＲＬＦを検知していないため、当該Ｄｅｓｔｉｎａｔｉｏｎを有する全てのルーティングＩＤは使用可能となる。

【0122】

ステップＳ２３において、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）を確認する。

【0123】

具体的には、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先が、ルーティング可能なルーティングＩＤの宛先に存在するか否かを確認する。

【0124】

そして、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先が、ルーティングが可能なルーティングＩＤの宛先に存在しない場合、当該ルーティングが不可能なルーティングＩＤの宛先を、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの付加情報に含める。

【0125】

例えば、上述したシングル接続の場合、ルーティング可能なルーティングＩＤの宛先が存在しないため、ルーティングが不可能なルーティングＩＤの宛先がルーティング可能なルーティングＩＤの宛先に存在しない場合に該当する。この場合、ルーティングが不可能なルーティングＩＤの宛先が当該付加情報に含まれることになる。

【0126】

また、例えば、上述したドナーＤＵ間による場合、ルーティング不可能なルーティングＩＤの宛先（ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）と、ルーティング可能なルーティングＩＤの宛先（ドナーＤＵ＃２（２００Ｄ２））とは、異なる宛先となっている。従って、ルーティングが不可能なルーティングＩＤの宛先（ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）が、ルーティング可能なルーティングＩＤの宛先（ドナーＤＵ＃２（２００Ｄ２）のＢＡＰアドレス）に存在しない場合に該当する。従って、この場合、ルーティングが不可能なルーティングＩＤの宛先（ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレス）が、当該付加情報に含まれることになる。

【0127】

一方、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤの宛先が、ルーティングが可能なルーティングＩＤの宛先に存在する場合、ルーティングが不可能なルーティングＩＤのリストを、当該付加情報に含めるようにする。

【0128】

例えば、上述したように、イントラドナーＤＵによる場合、ある宛先へのルーティングが不可能となったとしても、代替パスが存在するため、同一の宛先において、ルーティングが可能な場合も存在する。従って、この場合、ＩＡＢノード３００－Ｔは、ルーティングが不可能なルーティングＩＤのリストを、当該付加情報に含めるようにする。

【0129】

ステップＳ２４において、ＩＡＢノード３００－Ｔは、当該付加情報を含むＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信する。

【0130】

ステップＳ２５において、子ノード３００－Ｃは、当該Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信したことに応じて、当該宛先（Ｄｅｓｔｉｎａｔｉｏｎ）を有する全てのルーティングＩＤが使用不可能であると判定する。当該付加情報には、ルーティングが不可能な宛先（Ｄｅｓｔｉｎａｔｉｏｎ）が含まれるため、子ノード３００－Ｔは、当該宛先を含むルーティングＩＤは使用不可能なルーティングＩＤと判定する。

【0131】

そして、ステップＳ２６において、子ノード３００－Ｔは、一連の処理を終了する。

【0132】

［第３実施形態］
第１実施形態において、ＤＣの種別として、ＥＮ－ＤＣがあることを述べた。ＥＮ－ＤＣでは、上述したように、ＭＣＧが制御（Ｃ－Ｐｌａｎｅ）に関する処理を行い、ＳＣＧがデータ（Ｕ－Ｐｌａｎｅ）に関する処理を行う。そのため、ＭＣＧ側にＲＬＦが発生しても、少なくともデータの送信を維持することが可能である。ＮＲ－ＤＣについても、例えば、ＳＣＧがデータに関する処理し、ＭＣＧが制御に関する処理を行う場合、ＥＮ－ＤＣと同じ状況となり得る。

【0133】

このような場合、ＩＡＢノード３００－Ｔは、ＭＣＧ側でＲＬＦが発生しても、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信しないようにすることも可能である。ＩＡＢノード３００－Ｔは、ＳＣＧを利用して、親ノード３００－Ｐ２へデータを転送できるからである。

【0134】

しかし、ＩＡＢノード３００－Ｔにおいて、ＤＣの種別を判定したり、ＳＣＧとＭＣＧのどちらの側でデータに関する処理を行っているかを判定したりすることは、処理が複雑になる場合もある。ＩＡＢノード３００－Ｔは、ＤＣの種別を判定する等をすることなく、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信したり、送信しなかったりすることができれば、簡易に処理を行うことが可能となる。

【0135】

そこで、第３実施形態では、ＲＬＦによる使用不可能なルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しない例について説明する。また、第３実施形態では、使用不可能なルートがルーティングテーブル及び／又はマッピングテーブル存在すれば、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する例について説明する。

【0136】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、マスターセルグループを管理する第１親ノード（例えば、親ノード３００－Ｐ１）をマスターノード、セカンダリセルグループを管理する第２親ノード（例えば、親ノード３００－Ｐ２）をセカンダリノードとして、二重接続方式が設定される。第２に、中継ノードが、第１親ノードとの間の第１バックホールリンクと、第２親ノードとの間の第２バックホールリンクのうち、少なくともいずれかで発生した無線リンク障害を検知する。第３に、中継ノードが、無線リンク障害により使用不可能なルートを示す第１ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在する場合、無線リンク障害に対して回復試行中であることを示す第１通知（例えば、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ）を子ノード（例えば、子ノード３００－Ｃ）へ送信し、第１ルート情報がルーティングテーブル及び／又はマッピングテーブル存在しない場合、前記第１通知を前記子ノードへ送信しないようにする。

【0137】

これにより、例えば、ＩＡＢノード３００－Ｔは、ＭＣＧ側でＲＬＦを検知した場合でも、ＭＣＧ側のルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しなければ、当該ＲＬＦを無視して、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しないようにすることができる。そのため、ＩＡＢノード３００－Ｔでは、ＥＮ－ＤＣが設定されて、ＭＣＧ側でＲＬＦが発生しても、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しないようにすることができる。従って、ＩＡＢノード３００－Ｔでは、複雑な処理を抑制したＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの送信を行うことが可能となる。

【0138】

（第３実施形態に係る動作例）
図１５は、第３実施形態に係る動作例を表す図である。

【0139】

図１５に示すように、ステップＳ３０において、ＩＡＢノード３００－Ｔは、処理を開始する。

【0140】

なお、ＩＡＢノード３００－Ｔは、第１実施形態と同様に、ステップＳ３０とステップＳ３１の間で、ＤＣ設定が行われる。ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１及び３００－Ｐ２と同時に無線通信が可能となる。

【0141】

ステップＳ３１において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＲＬＦを検知する。ＩＡＢノード３００－Ｔは、引き続き、ＲＲＣ再確立（ＲＲＣ ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）手順、ＭＣＧ失敗情報（ＭＣＧ Ｆａｉｌｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎ）手順、ＳＣＧ失敗情報（ＳＣＧ Ｆａｉｌｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎ）手順を実行してもよい。

【0142】

ステップＳ３２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴのＲＲＣレイヤは、ＲＬＦを検知したこと（又は当該ＢＨリンクが復旧中であることを）を示す第１情報を、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。

【0143】

例えば、当該ＲＲＣレイヤは、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＦ１ＡＰレイヤを経由して、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ、第１情報を出力してもよい。

【0144】

第１情報は、どのリンクでＲＬＦが発生したのかを示す情報が含まれてもよい。具体的には、第１情報は、ＭＣＧでＲＬＦが発生したのか、ＳＣＧでＲＬＦ発生したのかを示す情報が含まれてもよい。また、第１情報は、ＲＬＦが発生したＢＨリンクを流出ＢＨリンクとする流出ＢＨリンクＩＤ（ｅｇｒｅｓｓ ＢＨ ｌｉｎｋ ＩＤ）が含まれてもよい。更に、第１情報は、ＲＬＦが発生したＢＨリンク上のＩＡＢノード３００－Ｔの次ホップＢＡＰアドレス（Ｎｅｘｔ ｈｏｐ ＢＡＰ ａｄｄｒｅｓｓ）が含まれてもよい。第１情報は、ＭＣＧかＳＣＧかを示す情報、流出ＢＨリンクＩＤ、及び次ホップＢＡＰアドレスの少なくともいずれかが含まれてもよい。

【0145】

ステップＳ３３において、ＢＡＰレイヤは、第１情報の入力に応じて、使用不可能なルートが存在するか否かを確認する。具体的には、ＢＡＰレイヤは、第１情報に対応する（又は第１情報を含む）ルート情報が、ルーティング設定（又はルーティングテーブル）及び／又はマッピング設定（又はマッピングテーブル）に存在するか否かを確認する。

【0146】

第１に、ルーティングテーブルに対する確認は、例えば、以下となる。

【0147】

すなわち、ＢＡＰレイヤは、第１情報に対応する、ルート情報（ここでは、ルーティングＩＤ及び／又は流出ＢＨリンク）が、ルーティングテーブルに存在するか否かを確認する。

【0148】

第２に、マッピングテーブルに対する確認は、例えば、以下となる。

【0149】

すなわち、ＢＡＰレイヤは、第１情報に対応する、ルート情報（ここでは、流出ＢＨ ＲＬＣチャネル（ｅｇｒｅｓｓ ＢＨ ＲＬＣ ｃｈａｎｎｅｌ））が、マッピングテーブルに存在するか否かを確認する。

【0150】

ステップＳ３４において、ＢＡＰレイヤは、使用不可能なルートが、ルーティングテーブル及び／又はマッピングテーブルに存在すれば（ステップＳ３４でＹＥＳ）、ステップＳ３５の処理を行う。一方、ステップＳ３４において、ＢＡＰレイヤは、使用可能なルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ（ステップＳ３４でＮＯ）、ステップＳ３８の処理を行う。

【0151】

使用不可能なルートが存在する場合（ステップＳ３４でＹＥＳ）とは、第１情報に対応する、ルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。例えば、ＲＬＦがＭＣＧ側で発生した場合、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。このような場合、ＢＡＰレイヤは、ステップＳ３５とステップＳ３６を行う。

【0152】

使用不可能なルートが存在しない場合（ステップＳ３４でＮＯ）とは、第１情報に対応するルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。例えば、ＲＬＦがＭＣＧ側で発生した場合であっても、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。このような場合、ＢＡＰレイヤは、ＲＲＣレイヤから第１情報を受け取っても、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しない。つまり、ＭＣＧ側でＲＬＦが発生しても、ルーティングテーブル及び／又はマッピングテーブルに対応するエントリ（又は対応するルート情報）がなければ、ＢＡＰレイヤは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しないようにすることが可能となる。そのため、ＢＡＰレイヤは、ステップＳ３８の処理を行う。

【0153】

ステップＳ３５において、ＢＡＰレイヤは、使用不可能なルートを特定する。

【0154】

ここで、ＢＡＰレイヤは、下位ノード（例えば、子ノード３００－Ｃ）が把握できるように、使用不可能なルートを特定する。すなわち、ＢＡＰレイヤは、ルート情報として、ルーティングＩＤを用いて、ステップＳ３３とステップＳ３４を判定した場合（当該ルーティングＩＤが使用不可能なルートに対応する場合）、ルーティングＩＤをそのまま用いて、使用不可能なルートとして特定してもよい。また、ＢＡＰレイヤは、ルート情報として、流出ＢＨリンクを用いて、ステップＳ３３とステップＳ３４を判定した場合（当該流出ＢＨリンクが使用不可能なルートに対応する場合）、流出ＢＨリンクに対応する流入ＢＨリンク（ｉｎｇｒｅｓｓ ＢＨ ｌｉｎｋ）を、使用不可能なルートとして特定してもよい。更に、ＢＡＰレイヤは、ルート情報として、流出ＢＨ ＲＬＣチャネルを用いて、ステップＳ３３とステップＳ３４を判定した場合（当該流出ＢＨ ＲＬＣチャネルが使用不可能なルートに対応する場合）、流出ＢＨ ＲＬＣチャネルに対応する流入ＢＨ ＲＬＣチャネル（ｉｎｇｒｅｓｓ ＢＨ ＲＬＣ ｃｈａｎｎｅｌ）を、使用不可能なルートとして特定してもよい。

【0155】

ステップＳ３６において、ＢＡＰレイヤは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する。ＢＡＰレイヤは、ステップＳ３５で特定したルートと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信してもよい。例えば、ＢＡＰレイヤは、使用不可能なルートとして特定した流入ＢＨリンクと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信してもよい。この場合、ＢＡＰレイヤは、特定した流入ＢＨリンクと繋がっていない子ノードへ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しなくてもよい。

【0156】

なお、当該Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎには、使用不可能なルートが付加情報として含まれてもよい。使用不可能なルートは、使用不可能なルーティングＩＤなどであってもよい。

【0157】

そして、ステップＳ３７において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。

【0158】

一方、ステップＳ３８において、ＢＡＰレイヤは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信しない。

【0159】

そして、ステップＳ３８において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。

【0160】

（第３実施形態の変形例）
第３実施形態では、ＢＡＰレイヤがステップＳ３３からステップＳ３５の処理を行う例について説明した。例えば、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＦ１ＡＰレイヤがステップＳ３３からステップＳ３５の処理を行ってもよい。この場合の動作は、例えば、以下となる。

【0161】

すなわち、ステップＳ３２において、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＲＲＣレイヤは、当該Ｆ１ＡＰレイヤへ第１情報を出力する。

【0162】

ステップＳ３３からステップＳ３５は、ＢＡＰレイヤに代えて、当該Ｆ１ＡＰレイヤが、同様の処理を行えばよい。この場合、当該Ｆ１ＡＰレイヤは、ステップＳ３５で特定した使用不可能なルートを、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。そして、ＢＡＰレイヤは、ステップＳ３６以降の処理を行えばよい。

【0163】

［第４実施形態］
第３実施形態では、ＲＬＦによる使用不可能なルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信せず、使用不可能なルートが存在すれば、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する例を説明した。

【0164】

第４実施形態では、ＲＬＦから回復したルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信せず、回復したルートがルーティングテーブル及び／又はマッピングテーブルに存在すれば、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信する例を説明する。

【0165】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、無線リンク障害から回復したことを検知する。第２に、中継ノードが、無線リンク障害からの回復により使用することが可能となったルートを示す第２ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在する場合、無線リンク障害から回復したことを示す第２通知（例えば、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ）を子ノード（例えば、子ノード３００－Ｃ）へ送信し、第２ルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しない場合、第２通知を子ノードへ送信しない。

【0166】

これにより、例えば、第４実施形態でも、第３実施形態と同様に、複雑な処理を抑制したＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎの送信を行うことが可能となる。

【0167】

（第４実施形態に係る動作例）
図１６は、第４実施形態に係る動作例を表す図である。

【0168】

図１６に示すように、ステップＳ４０において、ＩＡＢノード３００－Ｔは、処理を開始する。

【0169】

なお、ＩＡＢノード３００－Ｔは、第３実施形態と同様に、ステップＳ４０とステップＳ４１の間で、ＤＣ設定が行われる。ＩＡＢノード３００－Ｔは、親ノード３００－Ｐ１及び３００－Ｐ２と同時に無線通信が可能となる。

【0170】

ステップＳ４１において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴは、ＲＬＦを検知する。

【0171】

ステップＳ４２において、ＩＡＢノード３００－ＴのＩＡＢ－ＭＴのＲＲＣレイヤは、ＲＬＦから回復したことを示す第２情報を、当該ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。

【0172】

第２情報は、どのリンクのＲＬＦが回復したのかを示す情報が含まれてもよい。具体的には、第２情報は、ＭＣＧで回復したのか、ＳＣＧで回復したのかを示す情報が含まれてもよい。また、第２情報は、回復したＢＨリンクを流出ＢＨリンクとする流出ＢＨリンクＩＤ（ｅｇｒｅｓｓ ＢＨ ｌｉｎｋ ＩＤ）が含まれてもよい。更に、第２情報は、回復したＢＨリンク上のＩＡＢノード３００－Ｔの次ホップＢＡＰアドレス（Ｎｅｘｔ ｈｏｐ ＢＡＰ ａｄｄｒｅｓｓ）が含まれてもよい。第２情報には、ＭＣＧかＳＣＧかを示す情報、流出ＢＨリンクＩＤ、及び次ホップＢＡＰアドレスの少なくともいずれかが含まれてもよい。

【0173】

ステップＳ４３において、ＢＡＰレイヤは、第２情報の入力に応じて、使用可能となったルートが存在するか否かを確認する。具体的には、ＢＡＰレイヤは、第２情報に対応する（又は第２情報を含む）ルート情報が、ルーティング設定（又はルーティングテーブル）及び／又はマッピング設定（又はマッピングテーブル）に存在するか否かを確認する。

【0174】

第１に、ルーティングテーブルに対する確認は、例えば、以下となる。

【0175】

すなわち、ＢＡＰレイヤは、第２情報に対応する（又は第２情報を含む）、ルート情報（ここでは、ルーティングＩＤ及び／又は流出ＢＨリンク）が、ルーティングテーブルに存在するか否かを確認する。

【0176】

第２に、マッピングテーブルに対する確認は、例えば、以下となる。

【0177】

すなわち、ＢＡＰレイヤは、第２情報に対応する（又は第２情報を含む）、ルート情報（ここでは、流出ＢＨ ＲＬＣチャネル（ｅｇｒｅｓｓ ＢＨ ＲＬＣ ｃｈａｎｎｅｌ））が、マッピングテーブルに存在するか否かを確認する。

【0178】

ステップＳ４４において、ＢＡＰレイヤは、使用可能となったルートがルーティングテーブル及び／又はマッピングテーブルに存在すれば（ステップＳ４４でＹＥＳ）、ステップＳ４５の処理を行う。一方、ステップＳ４４において、ＢＡＰレイヤは、使用可能になったルートがルーティングテーブル及び／又はマッピングテーブルに存在しなければ（ステップＳ４４でＮＯ）、ステップＳ４８の処理を行う。

【0179】

使用可能になったルートが存在する場合（ステップＳ４４でＹＥＳ）とは、第２情報に対応する、ルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。例えば、ＲＬＦからの回復がＭＣＧ側で発生した場合、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在する場合である。このような場合、ＢＡＰレイヤは、ステップＳ４５とステップＳ４６を行う。

【0180】

一方、使用可能となったルートが存在しない場合（ステップＳ４４でＮＯ）とは、第２情報に対応するルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。例えば、ＲＬＦからの回復がＭＣＧ側で発生した場合であっても、ＭＣＧ側のルート情報が、ルーティングテーブル及び／又はマッピングテーブルに存在しない場合である。このような場合、ＢＡＰレイヤは、ＲＲＣレイヤから第２情報を受け取っても、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信しない。そのため、ＢＡＰレイヤは、ステップＳ４８の処理を行う。

【0181】

ステップＳ４５において、ＢＡＰレイヤは、使用不可能なルートを特定する。ＢＡＰレイヤは、下位ノード（例えば、子ノード３００－Ｃ）が把握できるように、使用可能となったルートを特定する。すなわち、ＢＡＰレイヤは、第３実施形態と同様に、ルーティングＩＤ、流入ＢＨリンク（ｉｎｇｒｅｓｓ ＢＨ ｌｉｎｋ）、又は流入ＢＨ ＲＬＣチャネル（ｉｎｇｒｅｓｓ ＢＨ ＲＬＣ ｃｈａｎｎｅｌ）を、使用可能となったルートとして特定してもよい。

【0182】

ステップＳ４６において、ＢＡＰレイヤは、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信する。ＢＡＰレイヤは、ステップＳ４５で特定したルートと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信してもよい。例えば、ＢＡＰレイヤは、特定した流入ＢＨリンクと繋がっている子ノード３００－Ｃのみへ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信してもよい。この場合、ＢＡＰレイヤは、特定した流入ＢＨリンクと繋がっていない子ノードへ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信しなくてもよい。

【0183】

なお、当該Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎには、使用可能となったルートが付加情報として含まれてもよい。使用可能となったルートとしては、使用可能になったルーティングＩＤなどが含まれる。

【0184】

そして、ステップＳ４７において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。

【0185】

一方、ステップＳ４８において、ＢＡＰレイヤは、使用可能なルートが存在しない場合（ステップＳ４４でＮＯ）、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信しない。

【0186】

そして、ステップＳ４８において、ＩＡＢノード３００－Ｔは、一連の処理を終了する。

【0187】

（第４実施形態の変形例）
第３実施形態の変形例と同様に、ステップＳ４３からステップＳ４５の処理を、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＦ１ＡＰレイヤが行ってもよい。すなわち、ステップＳ４３からステップＳ４５は、ＢＡＰレイヤに代えて、当該Ｆ１ＡＰレイヤが、同様の処理を行えばよい。この場合、当該Ｆ１ＡＰレイヤは、ステップＳ４５で特定したルート情報を、ＩＡＢノード３００－ＴのＩＡＢ－ＤＵのＢＡＰレイヤへ出力する。そして、ＢＡＰレイヤは、ステップＳ４６以降の処理を行えばよい。

【0188】

［第５実施形態］
第３実施形態では、ＩＡＢノード３００－Ｔが、使用不可能なルーティングＩＤを含むＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信してもよいことについて説明した。また、第４実施形態では、ＩＡＢノード３００－Ｔが、使用可能なルーティングＩＤを含むＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを子ノード３００－Ｃへ送信してもよいことについて説明した。

【0189】

第５実施形態では、子ノード３００－Ｃが、使用不可能なルーティングＩＤが含むＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した場合と、使用可能なルーティングＩＤを含むＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信した場合のＢＡＰレイヤにおける具体的な動作例について説明する。

【0190】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－Ｔ）が、無線リンク障害に対して回復試行中であることを示す第１通知（例えば、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ）を、子ノード（例えば、子ノード３００－Ｃ）へ送信する。第２に、子ノードが、使用不可能な第１ルーティングＩＤを含む第１通知を受信したことに応じて、第１ルーティングＩＤはルーティングテーブルに存在しないものとして第１ルーティング処理を行う。第３に、子ノードが、使用可能な第２ルーティングＩＤを含む第２通知（例えば、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ）を受信したことに応じて、第２ルーティングＩＤを含むルーティングテーブル内のエントリを用いて第２ルーティング処理を行う。

【0191】

これにより、子ノード３００－Ｃは、ＲＬＦにより使用不可能となったルーティングＩＤを含むＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信し、ＲＬＦからの回復により使用可能となったルーティングＩＤを含むＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信した場合でも、適切に処理を行うことができる。

【0192】

（第５実施形態に係る動作例）
図１７（Ａ）と図１７（Ｂ）は第５実施形態に係るノード間の構成例を表す図である。また、図１８は、第５実施形態に係る動作例を表す図である。図１７（Ａ）と図１７（Ｂ）に示す構成例を適宜参照しながら、図１８に示す動作例を説明する。

【0193】

図１８に示すように、ステップＳ５０において、子ノード３００－Ｃは、処理を開始する。

【0194】

ステップＳ５１において、子ノード３００－ＣのＢＡＰレイヤは、親ノード３００－Ｐ１から、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信する。図１７（Ａ）は、子ノード３００－Ｃが当該Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信する例を表している。当該Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎには、ＲＬＦにより、ルーティング不可能となったルーティングＩＤが付加情報として含まれている。

【0195】

図１８に戻り、ステップＳ５２において、子ノード３００－ＣのＢＡＰレイヤは、ルーティングテーブルにおいて、当該エントリが存在しないものとして、ルーティング処理を行う。すなわち、ＢＡＰレイヤは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎに含まれるルーティングＩＤを含むエントリが、ルーティングテーブルに存在しないもの（又は、使用不可能なエントリ）とみなして、ルーティング処理を行う。この場合、ＢＡＰレイヤは、ルーティングテーブルに当該エントリが存在しないため、当該ルーティングＩＤの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致する、ルーティングテーブルのエントリを検索し、当該エントリのルーティングＩＤへ、ローカルリルーティングを行う。第１ルーティング処理は、例えば、このようなローカルリルーティング処理に対応する。図１７（Ａ）は、当該ローカルリルーティング処理により、子ノード３００－Ｃが、親ノード３００－Ｐ２へ、経路を切り替えた例を表している。

【0196】

図１８に戻り、ステップＳ５３において、子ノード３００－Ｃは、親ノード３００－Ｐ１から、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信する。図１７（Ｂ）は、子ノード３００－Ｃが当該Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信する例を表している。当該Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎには、ＲＬＦからの回復により、ルーティング可能となったルーティングＩＤが付加情報として含まれている。

【0197】

図１８に戻り、ステップＳ５４において、子ノード３００－Ｃは、当該ルーティングＩＤに該当するエントリをルーティングテーブルから検索し、当該エントリが存在すれば、当該エントリの使用を再開し、通常のルーティング処理を行う。すなわち、子ノード３００－Ｃは、ルーティングテーブルに当該エントリが存在するため、ローカルリルーティング処理を停止し、通常のルーティング処理を行う。図１７（Ｂ）では、子ノード３００－Ｃが、親ノード３００－Ｐ２から親ノード３００－Ｐ１へ経路を切り替える例を表している。

【0198】

そして、ステップＳ５５において、子ノード３００－Ｃは、一連の処理を終了する。

【0199】

［第６実施形態］
図１９は、第６実施形態に係るノード間の構成例を表す図である。

【0200】

図１９に示すように、子ノード３００－Ｃが、親ノード３００－Ｐから、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した場合を仮定する。この場合、その後、子ノード３００－Ｃが、親ノード３００－Ｐから、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ又はＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎを受信できなかった場合、子ノード３００－Ｃは、どのような処理を行えばよいのか、わからない場合もある。

【0201】

これは、親ノード３００－Ｐが、何らかの原因により、Ｔｙｐｅ３ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎとを送信できなかったのかもしれない。また、親ノード３００－Ｐが、Ｔｙｐｅ３ ＩｎｄｉｃａｔｉｏｎとＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎとを送信しても、子ノード３００－Ｃが何らかの原因により受信できなかったのかもしれない。

【0202】

このような場合、親ノード３００－Ｐの意図と、子ノード３００－Ｃの動作とにミスマッチが生じ、トポロジ全体として意図した動作にならず、効率が悪くなる場合がある。特に、図１９に示すようなシングル接続の場合、子ノード３００－Ｃは、親ノード３００－Ｐへのアップストリーム方向の送信ができなくなってしまう。

【0203】

そこで、第６実施形態では、子ノード３００－Ｃは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した時にタイマのカウントを開始し、カウント値が所定値に達すると、ＢＨリンクの復旧処理を開始する例について説明する。

【0204】

具体的には、第１に、中継ノード（例えば、子ノード３００－Ｃ）が、ドナーノード（例えば、ドナーノード２００）からタイマ値の設定を受ける。第２に、中継ノードが、親ノード（例えば、親ノード３００－Ｐ）から、親ノードのバックホールリンクで発生した無線リンク障害に対して回復試行中であることを示す第１通知（例えば、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ）を受信する。第３に、中継ノードが、第１通知の受信に応じて、タイマによるカウントを開始する。第４に、中継ノードが、無線リンク障害から回復したことを示す第２通知（例えば、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ）と、無線リンク障害からの回復に失敗したことを示す第３通知（例えば、Ｔｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎ）のいずれも受信することなく、タイマによるカウント値がタイマ値に達した場合、復旧処理を行う。

【0205】

これにより、例えば、親ノード３００－Ｐと子ノード３００－Ｃとの間のミスマッチを抑制し、トポロジ全体として意図した動作に近づけるようにすることが可能となる。

【0206】

（第６実施形態に係る動作例）
図２０は、第６実施形態に係る動作例を表す図である。

【0207】

図２０に示すように、ステップＳ６０において、子ノード３００－Ｃは、処理を開始する。

【0208】

ステップＳ６１において、子ノード３００－Ｃは、ドナーノード２００又は親ノード３００－Ｐから、タイマ値の設定を受信する。子ノード３００－Ｃは、ドナーノード２００から、ＲＲＣメッセージ又はＦ１ＡＰメッセージを利用して当該タイマ値の設定を受信してもよい。また、子ノード３００－Ｃは、親ノード３００－Ｐから、ＢＡＰ Ｃｏｎｔｒｏｌ ＰＤＵを利用して当該タイマ値の設定を受信してもよい。

【0209】

ステップＳ６２において、子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信する。子ノード３００－Ｃは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの受信に応じて、タイマのカウントを開始する。

【0210】

ステップＳ６３において、子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎを受信したか否かを判定する。子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎを受信した場合（ステップＳ６３でＹＥＳ）、ステップＳ６４の処理を行う。一方、子ノード３００－Ｃは、親ノード３００－Ｐから、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ、又はＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎを受信しなかった場合（ステップＳ６３でＮＯ）、ステップＳ６６の処理を行う。

【0211】

ステップＳ６４において、子ノード３００－Ｃは、タイマのカウントを停止する。

【0212】

そして、ステップＳ６５において、子ノード３００－Ｃは、一連の処理を終了する。

【0213】

一方、ステップＳ６６において、子ノード３００－Ｃは、タイマのカウント値がタイマ値に達したか（タイマが満了したか）否かを判定する。子ノード３００－Ｃは、タイマのカウント値がタイマ値に達した場合（ステップＳ６６でＹＥＳ）、ステップＳ６７の処理を行う。一方、子ノード３００－Ｃは、タイマのカウント値がタイマ値に達していない場合（ステップＳ６６でＮＯ）、ステップＳ６３へ移行し、上述した処理を繰り返す。

【0214】

ステップＳ６７において、子ノード３００－Ｃは、復旧処理を行う。

【0215】

復旧処理は、ＲＬＦの宣言（ｄｅｃｌａｒｅ）であってもよい。例えば、子ノード３００－Ｃは、親ノード３００－ＰのＢＨリンクで発生したＲＬＦについて、当該ＲＬＦの宣言を行ってもよい。

【0216】

また、復旧処理は、ＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）手順の実行であってもよい。例えば、子ノード３００－Ｃは、親ノード３００－Ｐに対して、ＲＲＣ再確立手順を開始してもよい。

【0217】

更に、復旧処理は、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎに含まれる付加情報に応じたＭＣＧ失敗情報（ＭＣＧ Ｆａｉｌｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎ）手順又はＳＣＧ失敗情報（ＳＣＧ Ｆａｉｌｕｒｅ Ｉｎｆｏｒｍａｔｉｏｎ）手順の実行であってもよい。例えば、子ノード３００－Ｃは、当該付加情報としてＭＣＧ側でのＲＬＦを示す情報が含まれる場合、ＭＣＧ失敗情報手順を実行し、当該付加情報としてＳＣＧ側でのＲＬＦを示す情報が含まれる場合、ＳＣＧ失敗情報手順を実行してもよい。

【0218】

そして、ステップＳ６５において、子ノード３００－Ｃは、一連の処理を終了する。

【0219】

［第７実施形態］
３ＧＰＰでは、複数のＩＡＢノード３００によって形成されたネットワーク（又はトポロジ）において、どのようにリルーティングを行うのかについての検討が行われている。

【0220】

現在、ルーティングとリルーティングに関して、以下のシナリオがある。

【0221】

（Ｓ１）ＣＵ内／ドナーＤＵ内（Ｉｎｔｒａ－ＣＵ／Ｉｎｔｒａ－ｄｏｎｏｒ－ＤＵ）
（Ｓ１－１）ルーティング
（Ｓ１－２）リルーティング
（Ｓ２）ＣＵ内／ドナーＤＵ間（Ｉｎｔｒａ－ＣＵ／Ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ）
（Ｓ２－１）ルーティング
（Ｓ２－２）リルーティング
（Ｓ３）ＣＵ間（Ｉｎｔｅｒ－ＣＵ）
（Ｓ３－１）ルーティング
（Ｓ３－２）リルーティング
このようなシナリオを考慮した上で、各シナリオに共通の手順又は処理を検討したり、各シナリオ個別の手順又は処理を検討したりすることで、トポロジにおける、パケット転送の信頼性、柔軟性、及び低遅延性を向上させることが期待される。

【0222】

なお、ルーティングとは、例えば、受信したパケットをどのＩＡＢノード３００へ転送するかを制御することである。

【0223】

ここでは、リルーティングに着目して、各シナリオについて説明する。

【0224】

（Ｓ１）「ＣＵ内／ドナーＤＵ内」シナリオについて
図２１（Ａ）は、「ＣＵ内／ドナーＤＵ内」シナリオにおけるトポロジの構成例を表している。

【0225】

当該シナリオにおけるリルーティング（Ｓ１－２）は、所謂、ローカルリルーティングである。例えば、ＩＡＢノード３００－１が、ＩＡＢノード３００－２に対するＢＨ ＲＬＦを検出したとき、アップリンク方向のパケットについて、代替パスであるＩＡＢノード３００－３を介した経路に切り替えて、リルーティングを行う。

【0226】

（Ｓ２）「ＣＵ内／ドナーＤＵ間」シナリオについて
図２１（Ｂ）は、「ＣＵ内／ドナーＤＵ間」シナリオにおけるトポロジの構成例を表す図である。

【0227】

ＩＡＢノード３００－１におけるリルーティングに関しては、例えば、ＩＡＢノード３００－２経由の経路から、ＩＡＢノード３００－３経由の経路（代替パス）に切り替えたと仮定する。この場合、当該パケットの宛先となるドナーＤＵが、ドナーＤＵ＃１（２００Ｄ１）からドナーＤＵ＃２（２００Ｄ２）へ変更される。すなわち、パケットの宛先ＢＡＰアドレスが変更される。そのため、３ＧＰＰでは、当該シナリオで、ＢＡＰヘッダの書き替えを行うことが合意された。ＢＡＰヘッダの書き替えは、直前のルーティングＩＤ（ｐｒｅｖｉｏｕｓ ｒｏｕｔｉｎｇ ＩＤ）から新たなルーティングＩＤ（ｎｅｗ ｒｏｕｔｉｎｇ ＩＤ）へのＢＡＰヘッダを書き替えることである。

【0228】

（Ｓ３）「ＣＵ間」シナリオについて
図２１（Ｃ）は「ＣＵ間」シナリオにおけるトポロジの構成例を表す図である。

【0229】

図２１（Ｃ）に示すように、当該シナリオでは、ドナーＣＵ＃１（２００Ｃ１）とドナーＣＵ＃２（２００Ｃ２）の２つの異なるＣＵが設けられる。そして、ドナーＣＵ＃１（２００Ｃ１）にはドナーＤＵ＃１（２００Ｄ１）が接続され、ドナーＣＵ＃２（２００Ｃ２）にはドナーＤＵ＃２（２００Ｄ２）が接続される構成となっている。

【0230】

一般的に、異なるドナーＣＵにより、異なるトポロジが形成される。すなわち、ドナーＣＵ＃１（２００Ｃ１）からＩＡＢノード３００－１へ至る経路で形成されたトポロジ（第１トポロジ）と、ドナーＣＵ＃２（２００Ｃ２）からＩＡＢノード３００－１へ至る経路で形成されたトポロジ（第２トポロジ）とは異なるトポロジとなり得る。ＩＡＢノード３００－１は、２つの異なるトポロジの境界に位置する。このようなＩＡＢノード３００－１を境界ＩＡＢノード（ｂｏｕｎｄａｒｙ ｎｏｄｅ）と称する場合がある。

【0231】

当該シナリオのリルーティングに関しては、例えば、境界ＩＡＢノード３００－１は、ドナーＣＵ＃２（２００Ｃ２）におけるトポロジ上の代替パスを介して、ドナーＤＵ＃１（２００Ｄ１）宛てのパケットを転送することができる。

【0232】

ただし、当該シナリオのリルーティングに関して、３ＧＰＰでは、境界ＩＡＢノード３００－１において、ソースドナーノードであるドナーＣＵ＃１（２００Ｃ１）とはＦ１接続を残したまま、ターゲットのドナーノードであるドナーＣＵ＃２（２００Ｃ２）に対してＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）状態で適用されてもよい、ことが合意された。

【0233】

（第７実施形態に係る通信制御方法）
第１実施形態で説明した動作例、処理などは、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。

【0234】

第１実施形態をシナリオ（Ｓ２－２）に適用した場合は、例えば、以下となる。すなわち、図２１（Ｂ）に示すように、ＩＡＢノード３００－４及びＩＡＢノード３００－５は、ＩＡＢノード３００－１から、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。また、ＩＡＢノード３００－４及びＩＡＢノード３００－５は、ＩＡＢノード３００－１から、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。

【0235】

また、第１実施形態をシナリオ（Ｓ２－３）に適用した場合は、例えば、以下となる。すなわち、図２１（Ｃ）に示すように、ＩＡＢノード３００－４では、ＩＡＢノード３００－１から、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。また、ＩＡＢノード３００－４は、ＩＡＢノード３００－１から、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信する。Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎには、第１実施形態で説明した付加情報が含まれる。

【0236】

第２実施形態で説明した動作例、処理なども、シナリオ（Ｓ３－２）に適用可能である。なお、シナリオ（Ｓ２－２）は、第２実施形態で説明したため説明を割愛する。

【0237】

第２実施形態をシナリオ（Ｓ３－２）に適用した場合は、例えば、以下となる。すなわち、図２１（Ｃ）に示すように、ＩＡＢノード３００－１は、ＩＡＢノード３００－２との間のＢＨリンクにおけるＲＬＦを検知する。ＩＡＢノード３００－１は、ルーティングが不可能なルーティングＩＤの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）として、ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレスを確認する。そして、ＩＡＢノード３００－１は、当該ＢＡＰアドレスを含むＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを、ＩＡＢノード３００－４へ送信する。

【0238】

第３実施形態で説明した動作例、処理などは、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－１は、例えば、ＩＡＢノード３００－２との間のＢＨリンクでのＲＬＦを検知した場合、ＲＬＦによって使用不可能なルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信しない。ＩＡＢノード３００－１は、ＲＬＦによって使用不可能なルート情報がルーティングテーブル及び／又はマッピングテーブルに存在すれば、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信する。

【0239】

第４実施形態で説明した動作例、処理などは、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－１は、例えば、ＩＡＢノード３００－２との間のＢＨリンクでのＲＬＦからの回復を検知した場合、回復によって使用可能となったルート情報がルーティングテーブル及び／又はマッピングテーブルに存在しなければ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信しない。ＩＡＢノード３００－１は、当該回復によって使用可能となったルート情報がルーティングテーブル及び／又はマッピングテーブルに存在すれば、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを、下位ノードへ送信する。

【0240】

第５実施形態で説明した動作例、処理なども、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－４は、ＩＡＢノード３００－１からＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信する。付加情報として、ＲＬＦにより使用不可能となったルーティングＩＤが含まれる場合、ＩＡＢノード３００－４は、当該ルーティングＩＤを含むエントリがルーティングテーブルに存在しないものとして、第１ルーティング処理を行う。また、ＩＡＢノード３００－４は、ＩＡＢノード３００－１からＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを受信する。付加情報として、ＲＬＦからの回復により使用可能となったルーティングＩＤが含まれる場合、ＩＡＢノード３００－４は、ルーティングテーブルに含まれる当該エントリを利用して、第２ルーティング処理を行う。

【0241】

第６実施形態で説明した動作例、処理なども、シナリオ（Ｓ１－２）、シナリオ（Ｓ２－２）、及びシナリオ（Ｓ３－２）に適用可能である。すなわち、ＩＡＢノード３００－４は、ＩＡＢノード３００－１からＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信したときにタイマのカウントを開始し、カウント値がタイマ値に達した場合、復旧処理を行う。

【0242】

［第８実施形態］
上述した実施形態では、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの受信により、ローカルリルーティングを開始（又はトリガ）したり、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎの受信により、ローカルリルーティングの動作を停止したりする例について説明した。

【0243】

ＩＡＢノード３００は、ローカルリルーティングのトリガ及び停止をドナーノード２００へ報告してもよい。

【0244】

当該報告には、トリガ又は停止の原因を示す原因情報を含んでもよい。当該原因情報は、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎに含まれる付加情報（第１実施形態、第２実施形態、及び第５実施形態）であってもよいし、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎに含まれる付加情報（第１実施形態）であってもよい。

【0245】

当該報告は、ローカルリルーティングのトリガ又は停止を行ったルートの情報を含んでもよい。当該ルート情報は、ルーティングＩＤ又はＢＨ ＲＬＣチャネルＩＤであってもよい。

【0246】

ＩＡＢノード３００は、当該報告をローカルリルーティングのトリガ又は停止に伴い、即座にドナーノード２００へ送信してもよい。又は、ＩＡＢノード３００は、当該報告を事後に送信してもよい。事後に送信する場合、ＩＡＢノード３００は、ローカルリルーティングのトリガ及び停止に伴い、当該トリガ又は停止、前記原因情報、前記ルート情報を記録（ログ）してもよい。ＩＡＢノード３００は、ドナーノード２００からの要求に伴い、当該記録（ログ）を、当該報告としてドナーノード２００へ送信してもよい。

【0247】

［その他の実施形態］
第１実施形態から第８実施形態で説明した各実施形態、各動作例、各処理、又は各ステップは、相互に組み合わせることが可能である。第１実施形態から第８実施形態の各実施形態の全部又は一部は矛盾しない範囲で組み合わせることが可能である。このような組み合わせにより、全てのシナリオにおいて手順又は処理の共通化を図ることができる場合もある。

【0248】

ＵＥ１００又はｇＮＢ２００が行う各処理をコンピュータに実行させるプログラムが提供されてもよい。プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。

【0249】

また、ＵＥ１００又はｇＮＢ２００が行う各処理を実行する回路を集積化し、ＵＥ１００又はｇＮＢ２００の少なくとも一部を半導体集積回路（チップセット、ＳｏＣ）として構成してもよい。

【0250】

以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。

【0251】

本開示で使用されている「に基づいて（ｂａｓｅｄ ｏｎ）」、「に応じて（ｄｅｐｅｎｄｉｎｇ ｏｎ）」という記載は、別段に明記されていない限り、「のみに基づいて」、「のみに応じて」を意味しない。「に基づいて」という記載は、「のみに基づいて」及び「に少なくとも部分的に基づいて」の両方を意味する。同様に、「に応じて」という記載は、「のみに応じて」及び「に少なくとも部分的に応じて」の両方を意味する。また、「取得する（ｏｂｔａｉｎ／ａｃｑｕｉｒｅ）」は、記憶されている情報の中から情報を取得することを意味してもよく、他のノードから受信した情報の中から情報を取得することを意味してもよく、又は、情報を生成することにより当該情報を取得することを意味してもよい。「含む（ｉｎｃｌｕｄｅ）」、「備える（ｃｏｍｐｒｉｓｅ）」、及びそれらの変形の用語は、列挙する項目のみを含むことを意味せず、列挙する項目のみを含んでもよいし、列挙する項目に加えてさらなる項目を含んでもよいことを意味する。また、本開示において使用されている用語「又は（ｏｒ）」は、排他的論理和ではないことが意図される。さらに、本開示で使用されている「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量又は順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、又は何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。本開示において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含むものとする。

【0252】

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

【0253】

（付記）
導入
ｅＩＡＢ（Ｅｎｈａｎｃｅｍｅｎｔｓ ｔｏ Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ ｆｏｒ ＮＲ）は、ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎとローカルリルーティングのサポートを含むトポロジ適応の強化を目的としている。

【0254】

本付記では、Ｔｙｐｅ２／３ＢＨ ＲＬＦの詳細について説明する。

【0255】

議論
二重接続方式の場合のＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの送信
ＲＡＮ２＃１１４－ｅにおいて、ＲＡＮ２はＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎのトリガ条件について以下のように合意した。

【0256】

Ｔｙｐｅ２のＲＬＦ Ｉｎｄｉｃａｔｉｏｎを生成するトリガは、ＲＬＦ検出時である。更なる検討は、シングル接続と二重接続の両方のケースに必要である。

【0257】

親ノードとのシングル接続の場合、合意は非常に簡単である。一方、２つの親ノードとの二重接続の場合、どのようにＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信するか、さらに議論すべきである。

【0258】

ＲＡＮ２＃１１３－ｅにおいて、子ノードの観点からのＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎのユースケースが以下のように合意された。
ＲＡＮ２はＴｙｐｅ２／３のＲＬＦ Ｉｎｄｉｃａｔｉｏｎをサポートする（規定されたる動作、ＴＳの影響、詳細については更なる検討が必要である）。
Ｔｙｐｅ２のＲＬＦ Ｉｎｄｉｃａｔｉｏｎは、ローカルリルーティングをトリガすることができる。
Ｔｙｐｅ２のＲＬＦ Ｉｎｄｉｃａｔｉｏｎは、ＳＩＢでサポートされるＩＡＢの無効化のトリガすることができる。
Ｔｙｐｅ２のＲＬＦ Ｉｎｄｉｃａｔｉｏｎは、ＳＲやＢＳＲの送信の停止や削減のトリガとして使用することができる。

【0259】

上記の合意事項の文脈では、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した子ノードが、当該ＩＡＢノードでのＢＨ ＲＬＦにより、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信した当該ＩＡＢノードにアップストリームパケットを転送しないことは、予想される動作と考えることができる。これは、「親ノードが２つあるＩＡＢノードが（ＤＣを介して）一方の親ノードからＴｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを受信した場合、ＩＡＢノードはもう一方の親ノードへのローカルリルーティングをトリガしてもよい」という合意とも一致するものである。

【0260】

所見１：親ノードがシングルＢＨ接続の場合、子ノードはＴｙｐｅ２ ＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを送信したＩＡＢノードへアップストリームパケットを転送することは期待できない場合がある。

【0261】

図２２の（ｂ）に示すように、当該ＩＡＢノードが二重接続方式を持つ場合、Ｒｅｌ－１６の動作としてローカルリルーティングを実行することがあるため、所見１は常に正しいわけではない。

【0262】

注：ＲＬＣ－ＡＭエンティティが確認応答を受信するまでのＢＡＰエンティティ送信部でのデータバッファリングは、実装次第である。ＢＨ ＲＬＦの場合、ＢＡＰエンティティの送信部は、ＢＨ ＲＬＦの前に下位レイヤで確認されなかったＢＡＰデータＰＤＵを代替パスにリルーティングさせてもよい。

【0263】

したがって、ＭＣＧのＢＨ ＲＬＦの後でも代替パスがある場合、当該ＩＡＢノードがＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信すべきかどうかについては疑問が残る。ＭＣＧ障害情報手順の間、当該ＩＡＢノードはローカルリルーティングを継続する可能性があることに注意するべきである。

【0264】

所見２：子ノードは、親ノード（当該ＩＡＢノード）がローカルリルーティングを実行できる場合、つまり二重接続のために、アップストリームパケットを転送することがある。

【0265】

ＥＮ－ＤＣのもう１つのシナリオも検討に値する。ＥＮ－ＤＣでは、ＭＣＧリンク（つまりＭｅＮＢ）は制御プレーンのシグナリングのためにのみ使用され、データは常にＳＣＧリンク（つまりＳｇＮＢ）を介して転送される。この場合、ＳＣＧ ＲＬＦは子ノードのパケット転送に直接影響を与えるため、当該ＩＡＢノードは子ノードに対してＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信する必要がある。一方、ＭＣＧ ＲＬＦ（ＬＴＥリンク）の場合は、その後のＲＲＣ接続再確立手順の間、ＳＣＧリンクはまだ使用可能であり、再確立に失敗した場合はＲｅｌ－１６と同様にＴｙｐｅ４ Ｉｎｄｉｃａｔｉｏｎが送信されるため、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎが必要ない場合がある。

【0266】

所見３：ＥＮ－ＤＣでは、ＭＣＧ（つまりＬＴＥリンク）を介してローカルリルーティングを行うことができないため、ＳＣＧ ＲＬＦ（つまりＮＲリンク）の際にＴｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを送信する必要がある。

【0267】

所見４：ＥＮ－ＤＣでは、パケット転送は常にＳＣＧ（すなわちＮＲリンク）を介して行われるため、ＭＣＧ ＲＬＦ（すなわちＬＴＥリンク）の際にＴｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを送信する必要はない。

【0268】

上記の所見を考慮すると、ＢＨ ＲＬＦによって少なくとも１つのルートが利用できない場合、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎが送信されるというのがシンプルな解決策であると考えられる。この解決策は、シングル接続と二重接続の両方の場合、またＮＲ－ＤＣとＥＮ－ＤＣの両方をカバーすることができる。例えば、シングルコネクションのＢＨ ＲＬＦでは、すべてのルートが使用できなくなる。ＥＮ－ＤＣでは、ＭＣＧ ＲＬＦはどのルートにも影響を与えず、ＳＣＧ ＲＬＦはすべてのルートを使用不可にする。ＮＲ－ＤＣでは、ＢＨ ＲＬＦは、ＢＨリンクとルートのマッピングによって、いくつかのルートに影響を与える場合と与えない場合がある。そのため、ＲＡＮ２はＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎのトリガ条件について、この統一された動作に合意すべきである。。

【0269】

提案１：ＲＡＮ２は、ＩＡＢノードがシングル接続か二重接続（ＥＮ－ＤＣを含む）かを問わず、ＢＨ ＲＬＦ時に少なくとも１つのルートが利用できない場合にＴｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎが送信されることに合意すべきである。。

【0270】

Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎ受信時の部分的なローカルリルーティング
二重接続方式を持つ子ノードがＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信したときにどのように動作するかを検討する必要がある。親ノード（当該ＩＡＢノード）がＢＨ ＲＬＦを検出したが、まだローカルリルーティングを実行できる場合、二重接続の子ノードには、以下のいくつかの動作の選択肢がある（図２３参照）。
選択肢Ａ：すべてのアップストリームトラフィックがこの親ノードに残り、子ノードでのローカルリルーティングはない。
選択肢Ｂ：アップストリームトラフィックの一部が別の親ノードにリルートされる、つまり、「部分的」なローカルリルーティングである。

【0271】

選択肢Ａは単純な動作だが、ＢＨ ＲＬＦによって親ノードがＭＣＧ又はＳＣＧのどちらかのリンクを失うため、親ノードに過負荷が発生する可能性がある。一方、選択肢Ｂは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎが追加情報を伝える必要があるが、子ノードの２つの親ノードに負荷を分散することができる。そのため、選択肢Ｂはトポロジー全体のパフォーマンスを向上させるために有効であると予想される。

【0272】

所見５：Ｔｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを受信すると、子ノードはより良い負荷分散のために「部分的な」ローカルリルーティングを実行するかどうかの選択肢を持つことができる（すなわち、選択肢Ｂ）。

【0273】

提案２：ＲＡＮ２は、二重接続の親ノードがＢＨ ＲＬＦを経験した場合、子ノード（すなわち選択肢Ｂ）で「部分的な」ローカルリルーティングを実行するかどうかを議論すべきである。

【0274】

提案２のように部分的なリルーティング（つまり選択肢Ｂ）が好ましい動作である場合、子ノードはどのトラフィックが元のルートに残れるか、どのトラフィックをローカルリルーティングの対象とすべきかを判断しなければならないため、どのルートが利用できないかを知る必要がある。Ｔｙｐｅ２ ＩｎｄｉｃａｔｉｏｎにＢＨ ＲＬＦのために利用できないルーティングＩＤが含まれている場合は、容易に知ることができる。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した子ノードは、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎで通知されたルーティングＩＤを使用不可とみなし、子ノードのＢＡＰレイヤがローカルリルーティングを実行する。そのため、ＲＡＮ２は関係するノードと子ノードでこれらの動作に合意すべきである。

【0275】

提案３：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ ＲＬＦ ＩｎｄｉｃａｔｉｏｎがＢＨ ＲＬＦのために利用できないルーティングＩＤを示すことに合意すべきである。

【0276】

提案４：ＲＡＮ２は、受信したＴｙｐｅ２のＢＨ ＲＬＦ ＩｎｄｉｃａｔｉｏｎでルーティングＩＤが示された場合、子ノードがルーティングＩＤを利用できないものとみなすことに合意すべきである。

【0277】

Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎのためのドナーの制御性
Ｔｙｐｅ２の表示で最も有望なユースケースは、ＲＡＮ２が合意したように、子ノードがローカルリルーティングを実行することである。ＲＡＮ２＃１１４－ｅでは、Ｒｅｌ－１６と同様に、Ｔｙｐｅ４の指示によって子ノードがＢＨ ＲＬＦを宣言し、最終的にローカルリルーティングを行うため、Ｔｙｐｅ２とＴｙｐｅ４がどのように連動するかが議論された。Ｔｙｐｅ２受信時のローカルリルーティングは提供者が設定可能であると指摘されている。提供者はトポロジ全体の目的を管理し、トポロジ全体の最新のパフォーマンスを知っているため、これは理にかなっている。

【0278】

提案５：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎの受信時にローカルリルーティングを実行するかどうか、ドナーがＩＡＢノードを設定することに合意すべきである。

【0279】

さらに、ＢＨ ＲＬＦが検出されたときにＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを送信するかどうかを、提供者が当該ＩＡＢノードに対して設定できるようにする必要がある。例えば、当該ＩＡＢノードがＲｅｌ－１７の機能を実装し、その子ノードがＲｅｌ－１６のみをサポートする場合（「混合」配置）、提供者はこれをオフにすることができる。

【0280】

提案６：ＲＡＮ２は、ドナー側がＩＡＢノードに対して、そのＢＨ ＲＬＦの検出時にＴｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを送信するかどうかを設定することに合意すべきである。。

【0281】

シングル接続及び二重接続の場合におけるＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎ
ＲＡＮ２＃１１４－ｅにおいて、ＲＡＮ２はＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎのトリガ条件について以下のように合意した。

【0282】

Ｔｙｐｅ３のＲＬＦ Ｉｎｄｉｃａｔｉｏｎの送信のトリガは、ＢＨ ＲＬＦ後の正常な回復である。シングル接続、二重接続のいずれでも更なる検討が必要である。

【0283】

Ｔｙｐｅ３はＴｙｐｅ２の受信によって開始された子ノードの動作を元に戻すというのが共通の認識であると考えられる。そのため、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎは子ノードがＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信した場合のみ有効である。Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎのみがこれらのケースに依存するため、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎに関するこのような条件は、例えば上記の提案１のように、シングル接続と二重接続の両方に共通して適用可能である。

【0284】

提案７：ＲＡＮ２は、合意された動作、すなわちＢＨ ＲＬＦの回復に成功した場合に加え、Ｔｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを送信した場合にのみ、Ｔｙｐｅ３のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを送信することをシングル接続及び二重接続ケースに共通するものとして合意すべきである。

【0285】

提案１が合意できるのであれば、少なくとも１つのルートがＢＨ ＲＬＦ回復の成功により再利用可能になったとき、つまり状態が「利用不可」から「利用可能」に変化したときにのみ、Ｔｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎを送信するのが妥当であろう。この動作は、提案と同様に、ＮＲ－ＤＣとＥＮ－ＤＣを含むシングル接続と二重接続のケースに適用することができる。

【0286】

提案８：ＲＡＮ２は、ＢＨ ＲＬＦの回復に成功し少なくとも１つのルートが再利用可能になると、Ｔｙｐｅ３のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎが送信されることに合意するべきである。

【0287】

また、提案３に合意できる場合は、再利用可能になったルーティングＩＤを子ノードにも通知する必要がある。子ノードはこれらのルーティングＩＤをルーティング可能であるとみなし、該当するトラフィックのローカルリルーティングを停止させる。

【0288】

提案９：ＲＡＮ２は、Ｔｙｐｅ３のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎが、ＢＨ ＲＬＦ回復の成功により再利用可能となったルーティングＩＤを示すことに合意すべきである。

【0289】

提案１０：ＲＡＮ２は、受信したＴｙｐｅ３のＢＨ ＲＬＦ ＩｎｄｉｃａｔｉｏｎでルーティングＩＤが示された場合、子ノードがルーティングＩＤを利用できるとみなすことに合意すべきである。

【0290】

Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの伝播
Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎのプロパゲーションは、負荷分散やサービス中断の低減など、より良いトポロジ管理を提供することを目的としている。

【0291】

具体的には、様々な提案がされている。そのうちの１つは、ＩＡＢノードがＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを受信し、代替パスがない場合、Ｔｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎを転送するものであり、これは主に提案１の選択肢１によるＩＡＢノードの動作と一致するものである。言い換えれば、この条件は、提案２の部分的なローカルリルーティングを含め、ＩＡＢノードがローカルリルーティングを行わない条件と解釈することも可能である。もう一つの選択肢は、安定したトポロジ管理のために期待されるＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの伝搬を１ホップのみに制限することである。二重接続の場合、つまり提案１ではＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎがどのように送信されるか、また子ノードでの「部分的」なローカルリルーティングを考慮するか、つまり提案２に依存することに変わりはない。そのため、詳細は現時点では更なる検討が必要としておくべきである。

【0292】

提案１１：ＲＡＮ２は、子孫ノードへのＴｙｐｅ２ Ｉｎｄｉｃａｔｉｏｎの伝搬がサポートされることに合意すべきである。ＩＡＢノードがローカルリルーティングを行わない場合のみ転送するなど、詳細な条件について更なる検討を行う。

【0293】

Ｔｙｐｅ２ ＩｎｄｉｃａｔｉｏｎによるＳＲやＢＳＲの無効化又は削減
ＲＡＮ２は「Ｔｙｐｅ２ＲＬＦ ＩｎｄｉｃａｔｉｏｎはＳＲやＢＳＲの送信を停止又は削減するために使用できる」と合意したが、この合意をどのように扱うかについては議論されていない。これはＩＡＢ－ＭＴの動作と考えられるため、明確に規定されるべきである。非活性化・削減については、「非活性化」の方が仕様的にはシンプルかもしれない。しかし、それはＳＲやＢＳＲがＴｙｐｅ３ Ｉｎｄｉｃａｔｉｏｎの受信後にのみ送信できることを意味し、スケジューリングの遅延を引き起こす可能性がある。一方、「低減」は、不必要な干渉を引き起こす可能性はあるが、ＢＨリンクが回復した直後にスケジューリングを再開することができる場合がある。そこで、ＲＡＮ２は、ＳＲ及び／又はＢＳＲの「非活性化」、「低減」、又はその両方をサポートするかどうかを議論すべきである。両方がサポートされる場合、ＩＡＢドナーによって設定可能であるべきである。さらに、「縮小」がサポートされる場合、ＳＲ及び／又はＢＳＲの縮小がどのように処理されるべきかについては不明確である。禁止タイマの概念を再利用することも考えられるが、現時点では更なる検討が必要であるとして残すべきである。

【0294】

提案１２：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを受信した場合、ＩＡＢ－ＭＴがＳＲ及び／又はＢＳＲ送信を停止又は削減することを規定することに合意すべきである。

【0295】

提案１３：ＲＡＮ２は、Ｔｙｐｅ２のＢＨ ＲＬＦ Ｉｎｄｉｃａｔｉｏｎを受信したときに、ＳＲ及び／又はＢＳＲの「非活性化」、「低減」、又はその両方をサポートするかどうか（つまり、設定可能かどうか）を議論すべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】