特開 2024-79777 通信制御方法

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024079777

(43)【公開日】2024-06-11

(54)【発明の名称】通信制御方法

(51)【国際特許分類】

   H04W 24/04 20090101AFI20240604BHJP

   H04W 92/20 20090101ALI20240604BHJP

【ＦＩ】

H04W24/04

H04W92/20 110

【審査請求】有

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2024048615

(22)【出願日】2024-03-25

(62)【分割の表示】P 2022557567の分割

【原出願日】2021-10-19

(31)【優先権主張番号】63/094,428

(32)【優先日】2020-10-21

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

(71)【出願人】

【識別番号】000006633

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

(74)【代理人】

【識別番号】110001106

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

(72)【発明者】

【氏名】藤代 真人

(72)【発明者】

【氏名】チャン ヘンリー

(57)【要約】      （修正有）

【課題】トポロジ内の全ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードが、Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎを転送することで、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）再確立等を実行する必要がないＩＡＢノードまでも、ＲＲＣ再確立等を行うことを避けるための通信制御方法及び中継ノードを提供する。
【解決手段】セルラ通信システムにおいて、ＩＡＢノード３００－Ｔは、ＩＡＢノード３００－Ｔとその親ノード５００との間のバックホールリンク＃１における無線リンク障害の発生を検知し、ＩＡＢノード３００－Ｃへ障害発生通知（Ｔｙｐｅ１，Ｔｙｐｅ２，ｏｒ Ｔｙｐｅ１／２ Ｉｎｄｉｃａｔｉｏｎ）を送信する。ＩＡＢノード３００－Ｃは、ＩＡＢノード３００－Ｔから設定された値に基づいて、障害発生通知をＩＡＢノード３００－Ｃの下位ノードに送信するか否かを判定する。
【選択図】図９

【特許請求の範囲】

【請求項1】

セルラ通信システムで用いる通信制御方法であって、
第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードが、第２の中継ノードへ障害発生通知を送信することと、
前記第２の中継ノードが、ネットワークノードから設定された値に基づいて、前記障害発生通知を前記第２の中継ノードの下位ノードに送信するか否かを判定することと、
を有する通信制御方法。

【請求項2】

前記障害発生通知は、前記障害発生通知が転送される毎にインクリメントされる転送ホップ数を含み、
前記ネットワークノードから設定された値は、前記転送ホップ数の上限値であり、
前記判定することは、前記転送ホップ数が前記上限値よりも小さいことに応じて、前記第１の中継ノードから受信した前記障害発生通知を前記下位ノードに転送すると判定することを含む
請求項１に記載の通信制御方法。

【請求項3】

前記障害発生通知は、当該障害発生通知を転送するか否かを示す転送可否情報を含み、
前記判定することは、前記第２の中継ノードが、前記転送可否情報に従って、前記障害発生通知を前記下位ノードに転送するか否かを判定することを含む
請求項２に記載の通信制御方法。

【請求項4】

第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードから、障害発生通知を受信する受信部と、
ネットワークノードから設定された値に基づいて、前記障害発生通知を下位ノードに送信するか否かを判定する制御部と、を備える
中継ノード。

【請求項5】

中継ノードのためのチップセットであって、
第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードから、障害発生通知を受信する処理と、
ネットワークノードから設定された値に基づいて、前記障害発生通知を下位ノードに送信するか否かを判定する処理と、を実行する
チップセット。

【請求項6】

中継ノードに、
第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードから、障害発生通知を受信する処理と、
ネットワークノードから設定された値に基づいて、前記障害発生通知を下位ノードに送信するか否かを判定する処理と、を実行させる
プログラム。

【請求項7】

セルラ通信システムであって、
第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードは、第２の中継ノードへ障害発生通知を送信し、
前記第２の中継ノードは、ネットワークノードから設定された値に基づいて、前記障害発生通知を前記第２の中継ノードの下位ノードに送信するか否かを判定する、
セルラ通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

セルラ通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）（登録商標。以下同じ）において、ＩＡＢ（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ ａｎｄ Ｂａｃｋｈａｕｌ）ノードと呼ばれる新たな中継ノードの導入が検討されている（例えば、「３ＧＰＰ ＴＳ ３８．３００ Ｖ１６．２．０（２０２０－０７）」参照）。１又は複数の中継ノードが、基地局とユーザ装置との間の通信に介在し、この通信に対する中継を行う。

【発明の概要】

【0003】

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードと前記中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記中継ノードが、条件付きハンドオーバの実行を指示する通知を送信することと、通信装置が、前記通知を受信することとを有する。

【0004】

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第１の中継ノードと前記第１の中継ノードの親ノードとの間のバックホールリンクにおける障害の発生を検知した前記第１の中継ノードが、前記障害の発生を示す障害発生通知に、当該障害発生通知を転送するか否かを示す転送可否情報を含めて、第２の中継ノードへ送信することを有する。また、前記通信制御方法は、前記第２の中継ノードが、前記転送可否情報に従って、前記第１の中継ノードから受信した前記障害発生通知を転送する、又は前記第２の中継ノードから受信した前記障害発生通知を転送しないことを有する。

【0005】

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第１の中継ノードが、バックホールリンクにおいて障害が発生したことを示す障害発生通知、又は前記バックホールリンクにおいて前記障害からの回復に失敗したことを示す回復失敗通知を送信する際に、経路優先度の変更を要求する第１の要求を第２の中継ノードへ送信することを有する。また、前記通信制御方法は、前記第２の中継ノードが、前記第１の要求の受信に応じて、前記第２の中継ノードから第３の中継ノードを介して第４の中継ノードへ至る第１の経路の優先度、及び／又は前記第２の中継ノードから第５の中継ノードを介して前記第４の中継ノードへ至る第２の経路の優先度を変更することを有する。さらに、前記通信制御方法は、前記第２の中継ノードが、変更した前記第１の経路の優先度及び／又は変更した前記第２の経路の優先度に従って、パケットを送信することを有する。

【0006】

第４の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、第２の中継ノードが、バックホールリンクにおいて障害が発生したことを示す障害発生通知を第１の中継ノードから受信することと、前記第２の中継ノードが、前記障害発生通知の受信に応じて、メインパスの設定をディアクティベートし、前記メインパスに対する代替パスの設定をアクティベートすることとを有する。

【図面の簡単な説明】

【0007】

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

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

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

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

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

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

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

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

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

【図10】図１０は、第１実施形態の動作例を示す図である。

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

【図12】図１２は、第３実施形態の動作例を示す図である。

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

【図14】図１４は、第４実施形態の動作例を示す図である。

【図15】図１５は、第５実施形態の動作例を示す図である。

【図16】図１６は、ＢＨ ＲＬＦ通知のタイプを示す図である。

【図17】図１７は、拡張されたＢＨ ＲＬＦインジケーションの送信オプションを示す図である。

【図18】図１８は、子孫ノードへの再確立を回避するための特定されたソリューションを示す図である。

【図19】図１９は、ｈｏｐ－ｂｙ－ｈｏｐ ＲＬＣＡＲＱの場合のＵＬデータのロスレス配信のメカニズムの比較を示す図である。

【図20】図２０は、「Ｃ）ＵＬステータス配信の導入」のオプションを示す図である。

【図21】図２１は、ドナー間のＩＡＢノード移動で発生する可能性のあるＲＡＮ２シグナリングの問題を示す図である。

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

【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】

提案１４：ＲＡＮ２は、インタードナーＩＡＢノード移動のためにマルチホップＩＡＢノードを再設定する方法について検討する必要がある。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】