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

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

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

(11)【特許番号】

(24)【登録日】2025-05-26

(45)【発行日】2025-06-03

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

(51)【国際特許分類】

   H04W 40/02 20090101AFI20250527BHJP

   H04W 24/04 20090101ALI20250527BHJP

   H04W 80/04 20090101ALI20250527BHJP

   H04W 88/04 20090101ALI20250527BHJP

【ＦＩ】

H04W40/02

H04W24/04

H04W80/04

H04W88/04

【請求項の数】 17

(21)【出願番号】P 2023554696

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

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

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

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

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

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

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

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

【早期審査対象出願】

(73)【特許権者】

【識別番号】000006633

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

(74)【代理人】

【識別番号】110001106

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

(72)【発明者】

【氏名】藤代 真人

(72)【発明者】

【氏名】チャン ヘンリー

【審査官】玉田 恭子

(56)【参考文献】

【文献】Fujitsu，Open issues on (re-)routing [online]，3GPP TSG-RAN WG2 Meeting #115-e R2-2107648，Internet<https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_115-e/Docs/R2-2107648.zip>，2021年08月06日，pages 1-9，[検索日 2024-06-10]

【文献】vivo，On Inter-CU routing, Inter-donor-DU rerouting and local re-routing [online]，3GPP TSG-RAN WG2 Meeting #115-e R2-2107861，Internet<https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_115-e/Docs/R2-2107861.zip>，2021年08月06日，pages 1-11，[検索日 2024-06-10]

【文献】3GPP TS 38.340 V16.4.0 (2021-03)[online]，Internet<https://www.3gpp.org/ftp/Specs/archive/38_series/38.340/38340-g40.zip>，2021年03月30日，pages 1-22，[検索日 2024-06-10]

【文献】FUTUREWEI，Solutions for Inter-Donor Routing and Bearer Mapping [online]，3GPP TSG-RAN WG2 Meeting #115-e R2-2108482，Internet<https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_115-e/Docs/R2-2108482.zip>，2021年08月06日，pages 1-7，[検索日 2024-06-10]

【文献】Kyocera，BH RLF Indications and local rerouting for eIAB[online]，3GPP TSG RAN WG2 #115-e R2-2107997，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_115-e/Docs/R2-2107997.zip>，2021年08月06日，[検索日 2025-04-09]

【文献】Nokia, Nokia Shanghai Bell，discussion on Inter-CU topology redundancy[online]，3GPP TSG RAN WG3 #113-e R3-213532，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_113-e/Docs/R3-213532.zip>，2021年08月06日，[検索日 2025-04-09]

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

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

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

【請求項1】

セルラ通信システムで用いる通信制御方法であって、
中継ノードが、アップストリーム方向のパケットを受信することと、
前記中継ノードが、前記パケットに対して、複数のルーティングＩＤを有するルーティング設定情報に基づいてルーティング処理を行うことと、を有し、
前記ルーティング処理を行うことは、
前記パケットのＢＡＰヘッダに含まれる宛先情報と一致するルーティングＩＤに対応する流出バックホールリンクが利用不能であり、且つ、ドナーＤＵ間リルーティングが可能である旨がドナーノードにより前記中継ノードに指示されている場合、前記パケットに対して前記ドナーＤＵ間リルーティングを行うことと、を含む、
通信制御方法。

【請求項2】

更に、前記中継ノードが、前記ドナーＤＵ間リルーティングを行うパケットに対して、当該パケットの宛先を書き替えるＢＡＰヘッダ書き替え処理を実行することを有する
請求項１記載の通信制御方法。

【請求項3】

前記ＢＡＰヘッダ書き替え処理を実行することは、
前記ルーティング設定情報に含まれる所定ルーティングＩＤに対応する流出バックホールリンクが利用可能である場合、前記所定ルーティングＩＤを前記パケットのヘッダに書き込むことを含む
請求項２に記載の通信制御方法。

【請求項4】

前記中継ノードが、トポロジ内ルーティング及びトポロジ間ルーティングの両方に適用可能な前記ルーティング設定情報をドナーノードから受信することをさらに有し、
前記ルーティング設定情報において、前記トポロジ間ルーティングに適用するエントリは、前記トポロジ間ルーティングであることを示す情報を含む
請求項１に記載の通信制御方法。

【請求項5】

前記中継ノードは、異なるドナーＣＵに属するトポロジ間で前記ドナーＤＵ間リルーティングを行う
請求項１に記載の通信制御方法。

【請求項6】

前記中継ノードが、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定されることと、
前記中継ノードのＢＡＰレイヤが、前記パケットを受信することと、
前記ＢＡＰレイヤが、前記パケットの流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードのＢＡＰアドレスが、前記パケットのヘッダに含まれる宛先ＢＡＰアドレスと一致する場合、前記パケットを上位レイヤへ出力することと、を、有する
請求項１に記載の通信制御方法。

【請求項7】

前記中継ノードは、第１ドナーノードの第１トポロジとの接続と、第２ドナーノードの第２トポロジとの接続との２つの接続を有する境界中継ノードである
請求項６に記載の通信制御方法。

【請求項8】

前記中継ノードは、前記第１ドナーノード及び前記第２ドナーノードのうち一方のドナーノードとのＲＲＣ接続を有し、前記第１ドナーノード及び前記第２ドナーノードのうち他方のドナーノードとのＦ１接続を有する
請求項７に記載の通信制御方法。

【請求項9】

前記中継ノードは、
前記第１ドナーノードが管理する前記第１トポロジにおける第１ＢＡＰアドレスが設定され、
前記第２ドナーノードが管理する前記第２トポロジにおける第２ＢＡＰアドレスが設定される
請求項７に記載の通信制御方法。

【請求項10】

前記第１ＢＡＰアドレス及び前記第２ＢＡＰアドレスのそれぞれは、Ｆ１ＡＰメッセージ又はＲＲＣメッセージにより前記中継ノードに設定される
請求項９に記載の通信制御方法。

【請求項11】

前記パケットを前記上位レイヤへ出力することは、
前記パケットのＢＡＰヘッダを取り除くことと、
前記ＢＡＰヘッダが取り除かれた前記パケットを前記上位レイヤに出力することと、を含む
請求項６に記載の通信制御方法。

【請求項12】

前記パケットを前記上位レイヤへ出力することは、
前記ＢＡＰレイヤの受信部分が前記パケットを前記上位レイヤへ出力することを含む
請求項６に記載の通信制御方法。

【請求項13】

前記ＢＡＰレイヤの受信部分が、前記パケットの前記流入バックホールＲＬＣチャネルと対応付けられる前記トポロジにおける前記中継ノードの前記ＢＡＰアドレスが、前記パケットの前記ヘッダに含まれる前記宛先ＢＡＰアドレスと一致しない場合、前記パケットを前記ＢＡＰレイヤの送信部分へ出力することをさらに有する
請求項６に記載の通信制御方法。

【請求項14】

セルラ通信システムで用いる中継ノードであって、
アップストリーム方向のパケットを受信する受信部と、
前記パケットに対して、複数のルーティングＩＤを有するルーティング設定情報に基づいてルーティング処理を行う制御部と、を備え、
前記制御部は、前記ルーティング処理において、前記パケットのＢＡＰヘッダに含まれる宛先情報と一致するルーティングＩＤに対応する流出バックホールリンクが利用不能であり、且つ、ドナーＤＵ間リルーティングが可能である旨がドナーノードにより前記中継ノードに指示されている場合、前記パケットに対して前記ドナーＤＵ間リルーティングを行う
中継ノード。

【請求項15】

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

【請求項16】

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

【請求項17】

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

【発明の詳細な説明】

【技術分野】

【0001】

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

【背景技術】

【0002】

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

【発明の概要】

【0003】

第１の態様に係る通信制御方法は、中継ノードが、アップストリーム方向のパケットを受信することと、前記中継ノードが、前記パケットに対して、複数のルーティングＩＤを有するルーティング設定情報に基づいてルーティング処理を行うことと、を有する。前記ルーティング処理を行うことは、前記パケットのＢＡＰヘッダに含まれる宛先情報と一致するルーティングＩＤに対応する流出バックホールリンクが利用不能である場合、前記パケットに対してドナーＤＵ間リルーティングを行うこととを含む。

【0004】

第２の態様に係る中継ノードは、セルラ通信システムで用いる中継ノードである。前記中継ノードは、アップストリーム方向のパケットを受信する受信部と、前記パケットに対して、複数のルーティングＩＤを有するルーティング設定情報に基づいてルーティング処理を行う制御部と、を備える。前記制御部は、前記ルーティング処理において、前記パケットのＢＡＰヘッダに含まれる宛先情報と一致するルーティングＩＤに対応する流出バックホールリンクが利用不能である場合、前記パケットに対してドナーＤＵ間リルーティングを行う。

【0005】

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ドナーノードが、中継ノードに対して、第１ドナーノードの第１宛先アドレスと、第２ドナーノードの第２宛先アドレスとを設定するステップを有する。また、前記通信制御方法は、中継ノードが、アップストリーム方向のパケットを受信するステップを有する。更に、前記通信制御方法は、中継ノードが、ルーティング処理を行い、パケットを次ホップ中継ノードへ送信できないことを判別するステップを有する。更に、前記通信制御方法は、中継ノードが、判別したパケットに対して、当該パケットの第１宛先アドレスと一致するＢＡＰアドレスを含む第１ルーティングＩＤがルーティングテーブルに存在しない場合、第２宛先アドレスと一致するＢＡＰアドレスを含む第２ルーティングＩＤをルーティングテーブルから選択するステップを有する。更に、前記通信制御方法は、中継ノードが、第２ルーティングＩＤをパケットのヘッダに書き込むステップを有する。ここで、第２宛先アドレスは第１宛先アドレスに紐づけられている。

【図面の簡単な説明】

【0006】

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

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

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

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

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

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

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

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

【図9】図９（Ａ）は「ＣＵ内／ドナーＤＵ内」シナリオ、図９（Ｂ）は「ＣＵ内／ドナーＤＵ間」シナリオ、図９（Ｃ）は「ＣＵ間」シナリオにおけるトポロジの構成例を示す図である。

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

【図11】図１１は、第１実施形態に係る第１動作例をまとめた図面である。

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

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

【図14】図１４は、第１実施形態に係るＢＡＰ Ｄａｔａ ＰＤＵパケットの構成例を表す図である。

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

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

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

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

【図19】図１９（Ａ）と図１９（Ｂ）は、第２実施形態に係るトポロジの構成例を表す図である。

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

【図21】図２１は、第２実施形態に係る変形例を表す図である。

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

【図23】図２３は、第３実施形態に係る第１動作例をまとめた図である。

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

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

【図26】図２６は、第３実施形態に係る第３動作例をまとめたものである。

【図27】図２７は、第４実施形態に係るＩＡＢノードの構成例を表している。

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

【0007】

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

【0008】

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

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

（ルーティング及びリルーティングのシナリオ）
ＢＡＰレイヤの機能の１つに、ルーティング（ｒｏｕｔｉｎｇ）とリルーティング（ｒｅ－ｒｏｕｔｉｎｇ）がある。ルーティングは、例えば、受信したパケットをどのＩＡＢノード３００へ転送するかを制御することである。また、リルーティングは、例えば、受信したパケットを、代替パス（alternative path）を介して宛先ノード（アクセスＩＡＢノード又はドナーノード）へ転送するように制御することである。

【0051】

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

【0052】

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

【0053】

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

【0054】

ここで、各シナリオについて説明する。

【0055】

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

【0056】

図９（Ａ）に示すように、当該シナリオにおいては、同一のドナーＤＵ（２００Ｄ）と同一のドナーＣＵ（２００Ｃ）において、ルーティングとリルーティングが行われる。

【0057】

図９（Ａ）に示すように、ＩＡＢノード３００－１とドナーＤＵ（２００Ｄ）との間には、ＩＡＢノード３００－２を介した経路と、ＩＡＢノード３００－３を介した経路の２つの経路が存在する。ＩＡＢノード３００－１は、アップリンク方向のパケットについては、いずれかの経路に転送させることが可能である。ＩＡＢノード３００－１は、ダウンリンク方向のパケットについても、前記いずれかの経路で転送されてきたパケットを、ＩＡＢノード３００－４又はＩＡＢノード３００－５へ転送させることも可能である。ルーティング（Ｓ１－１）に際しては、このような２つの経路が存在することで、経路について冗長性を確保することができる。

【0058】

また、リルーティング（Ｓ１－２）は、所謂、ローカルリルーティングである。例えば、ＩＡＢノード３００－１が、ＩＡＢノード３００－２に対するバックホールリンクにおける無線リンク障害（ＢＨ ＲＬＦ（Radio Link Failure））（以下、「ＢＨ ＲＬＦ」と称する場合がある。）を検出したとき、アップリンク方向のパケットについて、代替パスであるＩＡＢノード３００－３を介した経路に切り替えて、リルーティングを行うことも可能である。

【0059】

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

【0060】

図９（Ｂ）に示すように、当該シナリオでは、１つのドナーノードのＣＵ（２００Ｃ）に、ドナーＤＵ＃１（２００Ｄ１）とドナーＤＵ＃２（２００Ｄ２）の２つの異なるＤＵが接続される。当該シナリオでは、ドナーノードのＣＵ（２００Ｃ）は同一であるものの、異なるドナーＤＵを介して、ルーティングとリルーティングが行われるシナリオとなっている。

【0061】

図９（Ｂ）に示すように、ＩＡＢノード３００－１とドナーノードのＣＵ（２００Ｃ）との間には、ＩＡＢノード３００－２とドナーＤＵ＃１（２００Ｄ１）とを介した経路と、ＩＡＢノード３００－３とドナーＤＵ＃２（２００－Ｄ２）とを介した経路の２つの経路がある。

【0062】

ＩＡＢノード３００－１におけるアップリンク方向のルーティングでは、ＩＡＢノード３００－１は、ＩＡＢノード３００－２又はＩＡＢノード３００－３へ、パケットを転送できる。ダウンリンク方向についても、前記いずれかの経路で転送されてきたパケットを、ＩＡＢノード３００－１は、ＩＡＢノード３００－４又はＩＡＢノード３００－５へパケットを転送できる。

【0063】

当該シナリオにおいては、ドナーノードのＤＵは異なるが、ドナーノードのＣＵは同じであるため、同一トポロジ内でのルーティングとなる。このようなルーティングを、トポロジ内ルーティングと称する場合がある。

【0064】

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

【0065】

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

【0066】

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

【0067】

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

【0068】

当該シナリオのルーティング（Ｓ３－１）に関しては、境界ＩＡＢノード３００－１では、ドナーＤＵ＃１（２００Ｄ１）宛てのパケットを、異なるトポロジのドナーＤＵ＃２（２００Ｄ１）へ転送することが可能である。また、ＩＡＢノード３００－４宛のパケットを、異なるトポロジを介して転送することができる。例えばドナーＣＵ＃１（２００Ｃ１）から送信されたパケットが、ドナーＣＵ＃２（２００Ｃ２）、ドナーＤＵ＃２（２００Ｄ２）、ＩＡＢノード３００－３及び３００－１を介して、ＩＡＢノード３００－４に転送できる。これら場合も宛先となるドナーノードのＤＵが変更されるため、３ＧＰＰにおいては、ＢＡＰヘッダの書き替えを行うことが合意された。

【0069】

このように異なるトポロジ間でルーティングが行われることを、トポロジ間ルーティングと称する場合がある。

【0070】

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

【0071】

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

【0072】

以上、３つのシナリオについて説明した。これら３つのシナリオについては、できるだけ、各シナリオ固有の手続を少なくして、全てのシナリオに共通な手順又は処理を特定することが望ましい。共通の手順又は処理とすることにより、シナリオ毎に個別の処理を行う場合よりも、処理を簡略化できるからである。

【0073】

実施形態では、以下の順番で各シナリオについて説明する。
［第１実施形態］ＣＵ間ルーティング
（第１動作例）
（第２動作例）
（第３動作例）
（第４動作例）
（第５動作例）
（第６動作例）
［第２実施形態］ＣＵ間リルーティング
［第３実施形態］ＣＵ内／ドナーＤＵ間リルーティング
（第１動作例）
（第２動作例）
（第３動作例）
なお、以下の説明において、「ＢＨ Ｒｏｕｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を「ルーティングテーブル」と称する場合がある。また、「ＢＨ ＲＬＣ Ｃｈａｎｎｅｌ Ｍａｐｐｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を「マッピングテーブル」と称する場合がある。更に、「Ｈｅａｄｅｒ Ｒｅｗｒｉｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を「ヘッダ書き替えテーブル」と称する場合がある。

【0074】

更に、「ＣＵ間ルーティング」を「トポロジ間ルーティング」、「ＣＵ間リルーティング」を「トポロジ間リルーティング」とそれぞれ称する場合がある。

【0075】

更に、「ＣＵ内／ドナーＤＵ間リルーティング」を「ドナーＤＵ間リルーティング」と称する場合がある。

【0076】

更に、レイヤとエンティティとを区別しないで用いる場合がある。

【0077】

［第１実施形態］
第１実施形態では、トポロジ間ルーティングについての実施形態である。

【0078】

トポロジ間ルーティングに関して、３ＧＰＰでは、以下の４つのＯｐｅｎ Ｉｓｓｕｅ（課題）が議論されている。

【0079】

（課題１）「What’s the BAP address added in BAP header in the first topology (i.e. the BAP address of ingress data at the boundary node).」

【0080】

（課題２）「How to differentiate the concatenated traffic and non-concatenated traffic.」

【0081】

（課題３）「How to determine whether a data should be delivered to upper layer (for downstream).」

【0082】

（課題４）「How to determine whether the BAP header of a data should be rewritten (i.e. whether being routed to another topology or its own topology).」

【0083】

（課題１）は、例えば、アクセスＩＡＢノード又はドナーノードのＤＵが、トポロジ間ルーティング対象のＢＡＰパケット（ＢＡＰ ＰＤＵ）のヘッダに、どのようなＢＡＰアドレスをセットすればよいかについての課題である。例えば、境界ＩＡＢノード３００－１は、セットされたＢＡＰアドレスに基づいて、トポロジ間ルーティング対象のＢＡＰパケットとそうでないパケットとを判別できれば、トポロジ間ルーティングを行ったり、通常のルーティング処理を行ったり、適切に処理することができる。

【0084】

（課題２）は、例えば、境界ＩＡＢノード３００－１が、トポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）とトポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）とをどのように判別するかについての課題である。境界ＩＡＢノードが係る判別を適切に行うことができれば、トポロジ間ルーティングとトポロジ内ルーティングとを適切に行うことが可能となる。

【0085】

（課題３）は、例えば、境界ＩＡＢノードが、自身の上位レイヤに渡すべきパケットをどのように判別するかについての課題である。例えば、境界ＩＡＢノードでは、アップストリーム方向からのパケットとダウンストリーム方向からのパケットの２つのパケットを受信できる。境界ＩＡＢノードは、ダウンストリーム方向における自身宛てのパケットであれば、自身がアクセスＩＡＢノードであると判別して、上位レイヤへ渡すことが可能である。

【0086】

（課題４）は、例えば、ＢＡＰヘッダをどのように書き替えるのかについての課題である。上述したように、トポロジ間ルーティング（例えば、図９（Ｃ））では、アップリンク方向のパケットの場合、宛先ドナーＤＵは、トポロジが異なるドナーＤＵへと変更される。そのため、ＢＡＰヘッダを適切に書き替えることができれば、トポロジが異なるドナーＤＵへの転送が可能となり、適切にトポロジ間ルーティングを行うことが可能となる。

【0087】

以上の４つの課題に対して、３ＧＰＰでは、以下の２つのＥｘａｍｐｌｅ（案）が提案されている。

【0088】

（案１）：Add the boundary node’s BAP address, in the BAP PDU header in the first topology;

【0089】

（案２）：Add some proxy/pseudo BAP address of the real destination；

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

上記（案２）で示されるように、トポロジ間ルーティング対象のパケットを識別する方法として、偽ＢＡＰアドレス（ｐｒｏｘｙ／pseudo ＢＡＰ Ａｄｄｒｅｓｓ）を境界ＩＡＢノード３００－１に割り当てる案が提案されている。この場合、境界ＩＡＢノード３００－１には、ドナーＣＵ＃１（２００Ｃ１）によって割り当てられる偽ＢＡＰアドレスと、ドナーＣＵ＃２（２００Ｃ２）によって割り当てられる偽ＢＡＰアドレスの２つの偽ＢＡＰアドレスが割り当てられる場合がある。更に、上述したように、境界ＩＡＢノード３００－１は、自ＢＡＰアドレスとして、これら２つのドナーによって、２つの自ＢＡＰアドレスが割り当てられる。

【0161】

従って、境界ＩＡＢノード３００－１には、４つのＢＡＰアドレスが割り当てられる場合がある。この４つのＢＡＰアドレスを用いて、トポロジ間ルーティング対象のパケットを識別するには、複雑な処理となる場合がある。

【0162】

また、ＢＡＰレイヤは、ＢＡＰアドレスを選択するために、どのトポロジから当該パケットが流入してきたのかを判定する可能性もある。

【0163】

そこで、第２動作例では、ＩＡＢノード３００－１は、流入したパケットのトポロジを特定し、当該トポロジと紐づけられたＢＡＰアドレスを自身のＢＡＰアドレスとして特定し、特定したＢＡＰアドレスを用いて、第１動作例と同様に、ＢＡＰ受信処理とＢＡＰ送信処理を行う。

【0164】

すなわち、第１に、中継ノード（例えば、ＩＡＢノード３００－１）が、ドナーノード（例えば、ドナーノード２００）から、各トポロジにおける当該中継ノードのＢＡＰアドレスが設定される。第２に、中継ノードが、ドナーノードから、トポロジと流入バックホールリンクとを紐づける紐付け情報、及び／又は、トポロジと流入バックホールＲＬＣチャネルとを紐付ける紐付け情報、が設定される。第３に、中継ノードのＢＡＰレイヤが、パケットを受信する。第４に、ＢＡＰレイヤが、パケットの流入バックホールリンク及び／又は流入バックホールＲＬＣチャネルに基づいて、パケットが属するトポロジを特定し、特定したトポロジに紐づいたＢＡＰアドレスを中継ノードのＢＡＰアドレスとして特定する。ここで、中継ノードは、トポロジ間の境界に位置する境界中継ノード（例えば、境界ＩＡＢノード３００－１）である。

【0165】

これにより、例えば、４つのＢＡＰアドレスを用いることなく、各トポロジに紐づけられた２つのＢＡＰアドレスを用いるだけでよいため、４つのＢＡＰアドレスを用いる場合と比較して、処理を簡略化することが可能である。

【0166】

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

【0167】

ここで、ＩＡＢノード（ここでは、境界ＩＡＢノード）３００－１は、２つのトポロジとの接続を有していると仮定する。例えば、図９（Ｃ）に示すように、境界ＩＡＢノード３００－１は、ドナーＣＵ＃１（２００Ｃ１）とドナーＣＵ＃２（２００Ｃ２）との接続を有する。この場合、境界ＩＡＢノード３００－１と２つのドナーノードとの関係は、境界ＩＡＢノード３００－１とＦ１ＡＰ接続を有するドナーノードと、境界ＩＡＢノード３００－１とＦ１ＡＰ接続を有しないドナーノードとの関係であってもよい。また、当該関係は、境界ＩＡＢノード３００－１と第１（メイン又はマスタ）Ｆ１ＡＰ接続を有するドナーノードと、境界ＩＡＢノード３００－１と第２（セカンダリ）Ｆ１ＡＰ接続を有するドナーノードとの関係でもよい。更に、当該関係は、境界ＩＡＢノード３００－１とＲＲＣ接続を有するドナーノードと、境界ＩＡＢノード３００－１とＲＲＣ接続を有しないドナーノードとの関係であってもよい。更に、当該関係は、境界ＩＡＢノード３００－１とＭＣＧ（Master Cell Group）接続を有するドナーノードと、境界ＩＡＢノード３００－１とＳＣＧ（Secondary Cell Group）接続を有するドナーノードとの関係であってもよい。

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

Ｄ１：宛先ＩＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ ＩＰ Ａｄｄｒｅｓｓ）
Ｄ２：ＩＰｖ６フローレベル（ＩＰｖ６ ｆｌｏｗ ｌａｂｅｌ）
Ｄ３：ＤＳＣＰ（Differentiated Services Code Point）
Ｄ４：ルーティングＩＤ
Ｄ５：トポロジ間ルーティングを示す識別子を書き込みか否かの情報
当該マッピング設定においても、アクセスＩＡＢノードへの設定と同様に、Ｄ５が含まれる。Ｄ５は、Ｕ３と同様に、当該ＩＥが当該マッピング設定に含まれる場合に、当該識別子をＢＡＰヘッダに書き込むとし（又は書き込みが指定されているとし）、当該ＩＥが当該マッピング設定に含まれない場合に、当該識別子をＢＡＰヘッダに書き込まない（又は書き込みが指定されていない）、としてもよい。当該情報が“１”の場合に当該識別子をＢＡＰヘッダに書き込むとし、当該情報が“０”の場合に当該識別子をＢＡＰヘッダに書き込まない、としてもよい。“１”と“０”は逆でもよい。当該情報が“Ｔｒｕｅ”又は“Ｆａｌｓｅ”により示されてもよい。また、当該情報が、“Ｙｅｓ”又は“Ｎｏ”で示されてもよい。

【0254】

なお、以下では、アクセスＩＡＢノードにおける動作例について説明する。

【0255】

ステップＳ８２において、アクセスＩＡＢノードのＢＡＰレイヤは、上位レイヤから、ＢＡＰパケット（ＢＡＰ ＳＤＵ）を受信する。

【0256】

第１に、ＢＡＰレイヤは、当該パケットに対応するトラフィック指定子を含むエントリを、当該マッピング設定（「Ｕｐｌｉｎｋ Ｔｒａｆｆｉｃ ｔｏ Ｒｏｕｔｉｎｇ ＩＤ Ｍａｐｐｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」）から選択する。

【0257】

第２に、ＢＡＰレイヤは、選択したエントリ内のルーティングＩＤを、ＢＡＰヘッダへ書き込むルーティングＩＤとする。

【0258】

そして、第３に、ＢＡＰレイヤは、選択したエントリ内において、トポロジ間ルーティングを示す識別子への書き込みが指定されていた場合、ＢＡＰヘッダにおける当該識別子を“１”とする。他方、選択したエントリ内において、当該識別子への書き込みが指定されていなかった場合、ＢＡＰレイヤは、当該識別子を“０”とする。

【0259】

第４に、ＢＡＰレイヤは、ルーティングＩＤと当該識別子とを含むＢＡＰヘッダを、当該パケット（ＢＡＰ ＳＤＵ）に付加して、ＢＡＰ ＰＤＵを生成する。

【0260】

ステップＳ８３において、アクセスＩＡＢノードのＢＡＰレイヤは、当該ＢＡＰ ＰＤＵに対して、ルーティング処理とマッピング処理とを行い、次ホップのノードへ送信する。

【0261】

そして、ステップＳ８４において、アクセスＩＡＢノードのＢＡＰレイヤは、一連の処理を終了する。

【0262】

ここで、ステップＳ８２とステップＳ８３について、ドナーノード２００のＤＵが処理を行う場合、ステップＳ８２とステップＳ８３における「アクセスＩＡＢノード」を「ドナーノード２００のＤＵ」と置き換え、マッピング設定を「Ｄｏｗｎｌｉｎｋ Ｔｒａｆｆｉｃ ｔｏ Ｒｏｕｔｉｎｇ ＩＤ Ｍａｐｐｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」とすればよい。

【0263】

以上、トポロジ間ルーティングのシナリオ（Ｓ３－１）に関する第１実施形態について説明した。次に、トポロジ間リルーティングのシナリオ（Ｓ３－２）について説明する。

【0264】

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

【0265】

第２実施形態では、トポロジ間リルーティングについて説明する。

【0266】

３ＧＰＰにおいては、トポロジ間リルーティングをサポートすることが合意されている。トポロジ間リルーティングは、ＩＡＢノードが、ターゲットドナーノードのＣＵのトポロジ上の代替パスを介して、オリジナルドナーノード（又はソースドナーノード）のＣＵへパケットをリルーティングすることである。

【0267】

トポロジ間リルーティングに関し、３ＧＰＰでは、ＩＡＢノードが、新たなドナーＣＵでのＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）を介して、ＢＨ ＲＬＦからの回復を実行する場合、元のドナーノードとの進行中のＦ１接続を維持し、回復されたパスを介してリルーティングが行われてもよい、ことが合意されている。

【0268】

つまり、ＩＡＢノードにおけるトポロジ間リルーティングは、ソースドナーノードとのＦ１接続を残したまま、ターゲットドナーノードに対してはＲＲＣ再確立の状態で適用される可能性がある。言い換えると、ＩＡＢノードでは、２つのドナーノードとの二重接続（ＤＣ：Dual Connectivity）の状態ではなく、ターゲットドナーノードとのＦ１接続が未確立である過渡状態で、トポロジ間リルーティングが適用される可能性がある。

【0269】

このような過渡状態において、ＩＡＢノードがＲｅｌ－１６のローカルリルーティングの手順を用いてトポロジ間リルーティングを実行しても、実行できない場合がある。

【0270】

すなわち、Ｒｅｌ－１６のローカルリルーティングの手順では、ＢＡＰパケットのＢＡＰヘッダに含まれる宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するルーティングＩＤをルーティングテーブルから選択して、当該パケットを転送する。

【0271】

しかし、ソースドナーノードのルーティングテーブルには、ターゲットドナーノードへのルーティングＩＤ（或いは、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）がターゲットドナーノードのＤＵのＢＡＰアドレス）は存在しない。２つのドナーノードは、トポロジが異なり、各ドナーノードのＣＵで各トポロジのＢＡＰアドレスなどを管理するからである。

【0272】

そのため、ソースドナーノードのＣＵが、ＩＡＢノードへ当該ルーティングテーブルを設定しても、ＩＡＢノードは、ターゲットドナーノードへ当該パケットを転送できない。

【0273】

仮に、ＩＡＢノードがターゲットドナーノードへ当該パケットを転送できても、ターゲットドナーノードは、当該パケットが自身宛てなのか、ソースドナーノード宛てなのか、把握できない場合がある。

【0274】

そこで、第２実施形態では、ターゲットドナーノードがトポロジ間リルーティング用の通信路をＩＡＢノードに設定し、ＩＡＢノード３００は、当該通信路を介して、パケットを転送する。

【0275】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、第１ドナーノード（例えば、ソースドナーノード）との接続又は第１上位ノードとの接続において、バックホールの無線リンク障害を検出する。第２に、中継ノードが、第２ドナーノード（例えば、ターゲットドナーノード）又は第２上位ノードに対して、ＲＲＣ再確立を実施した際に、第１ドナーノードとの通信を継続することを示す情報を通知する。ここで、第１上位ノードは、第１ドナーノードが管理するノードであって、中継ノードの上位ノードである。また、第２上位ノードは、第２ドナーノードが管理するノードであって、中継ノードの上位ノードである。

【0276】

これにより、例えば、ターゲットドナーノードでは、ＩＡＢノードとソースドナーノードとの間で通信が継続されることを把握でき、この通知をトリガにして、トポロジ間リルーティング用の通信路の設定を、ＩＡＢノードに対して行うことが可能となる。そして、上述した過渡状態においても、ＩＡＢノードは、当該通信路を利用して、受信したパケットを適切に転送することが可能となる。

【0277】

図１９（Ａ）と図１９（Ｂ）は、第２実施形態に係るトポロジの構成例を表す図である。

【0278】

図１９（Ａ）では、ＩＡＢノード３００とドナーノードＡ（２００－Ａ）との間のバックホールリンクでＢＨ ＲＬＦが発生している例を表している。また、図１９（Ｂ）では、ＩＡＢノード３００と上位ノード３００－Ｐ１との間のバックホールリンクでＢＨ ＲＬＦが発生している例を表している。図１９（Ｂ）において、ＩＡＢノード３００－Ｐ１は、ドナーノードＡ（２００－Ａ）が管理するノードである。また、ＩＡＢノード３００－Ｐ２は、ドナーノードＢ（２００－Ｂ）が管理するノードである。

【0279】

図２０は、第２実施形態に係る動作例を表す図である。図２０に示す動作例は、図１９（Ａ）と図１９（Ｂ）に示す構成例を適宜参照しながら説明する。

【0280】

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

【0281】

ステップＳ９１において、バックホールリンクにおいてＢＨ ＲＬＦが発生する。例えば、図１９（Ａ）の例では、ＩＡＢノード３００のＩＡＢ－ＭＴが、ドナーノードＡ（２００－Ａ）との間のバックホールリンクでのＢＨ ＲＬＦを検出する。また、図１９（Ｂ）の例では、ＩＡＢノード３００のＩＡＢ－ＭＴが、ＩＡＢノード３００－Ｐ１との間のＢＨ ＲＬＦを検出する。

【0282】

図２０に戻り、ステップＳ９２において、ＩＡＢノード３００は、セル選択により、ドナーノードＢ（２００－Ｂ）を選択する。ＩＡＢノード３００は、セル選択により、ドナーノードＢ（２００－Ｂ）が管理するＩＡＢノード３００－Ｐ２を選択してもよい。

【0283】

ステップＳ９３において、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）に対して、ＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）手順を実行する。例えば、以下の手順が実行される。

【0284】

第１に、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）に対して、ＲＲＣ再確立要求（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｒｅｑｕｅｓｔ）メッセージを送信する。ＩＡＢノード３００は、ＩＡＢノード３００－Ｐ２を介してドナーノードＢ（２００－Ｂ）に対して、当該メッセージを送信してもよい。

【0285】

この際、ＩＡＢノード３００は、当該メッセージにおいて、ドナーノードＡ（２００－Ａ）との通信を継続することを示す情報（又は要求）をドナーノードＢ（２００－Ｂ）へ通知してもよい。若しくは、ＩＡＢノード３００は、当該メッセージにおいて、自ＩＡＢノード３００がトポロジ間リルーティングの能力を有していることを示す情報をドナーノードＢ（２００－Ｂ）へ通知してもよい。若しくは、ＩＡＢノード３００は、当該メッセージにおいて、ドナーノードＡ（２００－Ａ）とのＦ１接続が残っていることを示す情報をドナーノードＢ（２００－Ｂ）へ通知してもよい。或いは、ＩＡＢノード３００は、当該メッセージにおいてドナーノードＡ（２００－Ａ）との通信路の確立要求をドナーノードＢ（２００－Ｂ）へ通知してもよい。

【0286】

なお、当該通知は、後のＲＲＣ再確立完了（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃｏｍｐｌｅｔｅ）、又は、更に後のＵＥアシスタンス情報（ＵＥ Ａｓｓｉｓｔａｎｖｅ Ｉｎｆｏｒｍａｔｉｏｎ）の各メッセージにおいて行われてもよい。

【0287】

第２に、ドナーノードＢ（２００－Ｂ）は、ＲＲＣ再確立要求を受け入れ、ＩＡＢノード３００へ、ＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）メッセージを送信する。

【0288】

第３に、ＩＡＢノード３００は、当該ＲＲＣ再確立メッセージの受信に応じて、ＲＲＣ再確立完了（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ Ｃｏｍｐｌｅｔｅ）メッセージを、ドナーノードＢ（２００－Ｂ）へ送信する。

【0289】

以上により、ＩＡＢノード３００とドナーノードＢ（２００－Ｂ）との間でＲＲＣ接続が確立される。

【0290】

ステップＳ９４において、ドナーノードＢ（２００－Ｂ）は、ドナーノードＡ（２００－Ａ）との間で通信路（ＧＴＰ（GPRS(General Packet Radio System) Tunnelling Protocol））を確立する。ドナーノードＢ（２００－Ｂ）が当該通信路を利用して、ＩＡＢノード３００においてトポロジ間ルーティングされたアップストリーム方向のパケットをドナーノードＡ（２００－Ａ）へ送信するためである。加えて、ドナーノードＡ（２００－Ａ）も、ドナーノードＢ（２００－Ｂ）との間で通信路（ＧＴＰ）を確立する。ドナーノードＡ（２００－Ａ）が、ドナーノードＢ（２００－Ｂ）へ、ダウンストリーム方向のパケットを送信するためである。

【0291】

例えば、ドナーノードＢ（２００－Ｂ）が、通信路確立要求メッセージをドナーノードＡ（２００－Ａ）へ送信する。そして、ドナーノードＡ（２００－Ａ）が、当該メッセージの受信に応じて、肯定応答メッセージをドナーノードＢ（２００－Ｂ）へ送信する。これにより、当該通信路が確立されてもよい。当該要求メッセージには、ＩＡＢノード３００の識別子、ダウンストリームパケット受信用のＧＴＰ ＴＥＩＤ（Tunnel Endpoint Identifier）、及びＩＰアドレスが含まれてもよい。当該肯定応答メッセージには、アップストリームパケット受信用のＧＴＰ ＴＥＩＤ、及びＩＰアドレスが含まれてもよい。

【0292】

なお、ＧＴＰ通信路の確立は、ドナーノードＢ（２００－Ｂ）がＩＡＢノード３００へ、ＲＲＣ再確立（ＲＲＣ Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）メッセージを送信する前に行われてもよい。

【0293】

ステップＳ９５において、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００に対して、トポロジ間リルーティング用の通信路を設定する。すなわち、第２ドナーノード（例えば、ドナーノードＢ（２００－Ｂ））が、中継ノード（例えば、ＩＡＢノード３００）に対して、トポロジ間リルーティング用の通信路を設定する。

【0294】

ドナーノードＢ（２００－Ｂ）は、ステップＳ９３で確立したＲＲＣ接続を利用して、ＩＡＢノード３００に対して通信路の設定を行う。具体的には、ドナーノードＢ（２００－Ｂ）のＣＵは、ＩＡＢノード３００のＩＡＢ－ＭＴへ、ＲＲＣ再設定（ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージを送信することで、通信路の設定を行う。当該メッセージには、トポロジ間リルーティング用の（テンポラリな）バックホールＲＬＣチャネル（ＢＨ ＲＬＣ ｃｈａｎｎｅｌ）を確立するための設定を含む。

【0295】

第１に、当該設定には、トポロジ間リルーティング用の（テンポラリな）ルーティングテーブルが含まれてもよい。当該ルーティングテーブルには、ルーティングＩＤ、次ホップＢＡＰアドレス（Ｎｅｘｔ Ｈｏｐ ＢＡＰ Ａｄｄｒｅｓｓ）が含まれてもよい。

【0296】

第２に、当該設定には、トポロジ間リルーティング用の（テンポラリな）マッピングテーブルが含まれてもよい。当該マッピングテーブルには、流入バックホールＲＬＣチャネル（ｉｎｇｒｅｓｓ ＢＨ ＲＬＣ ｃｈａｎｎｅｌ）、流出バックホールＲＬＣチャネル（ｅｇｒｅｓｓ ＢＨ ＲＬＣ ｃｈａｎｎｅｌ）、流入バックホールリンク（ｉｎｇｒｅｓｓ ＢＨ ｌｉｎｋ）、及び流出バックホールリンク（ｅｇｒｅｓｓ ＢＨ ｌｉｎｋ）が含まれてもよい。

【0297】

第３に、当該設定には、ＩＡＢノード３００のＢＡＰアドレスが含まれてもよい。当該ＢＡＰアドレスは、ドナーノードＢ（２００－Ｂ）が管理するＩＡＢノード３００に対するＢＡＰアドレスである。

【0298】

第４に、当該設定には、ドナーノードＢ（２００－Ｂ）のＤＵのＢＡＰアドレスが含まれてもよい。

【0299】

第５に、当該設定には、ＢＡＰヘッダ書き替えテーブルが含まれてもよい。

【0300】

ＩＡＢノード３００のＲＲＣレイヤは、当該設定を受信すると、当該設定を、ＩＡＢノード３００のＢＡＰレイヤへ出力する。ＢＡＰレイヤは、当該設定を、ルーティングテーブル及び／又はマッピングテーブルとして取り扱ってもよい。

【0301】

ステップＳ９６において、ＩＡＢノード３００のＢＡＰレイヤは、当該設定に従い、トポロジ間リルーティング処理を行う。例えば、ＩＡＢノードのＢＡＰレイヤは、以下の処理を行う。

【0302】

第１に、ＢＡＰレイヤは、滞留しているドナーノードＡ（２００－Ａ）宛てのパケットのＢＡＰヘッダを、当該設定に従い、ドナーノードＢ（２００－Ｂ）のＤＵ向けのルーティングＩＤに書き替える。

【0303】

第２に、ＢＡＰレイヤは、当該設定に従い、当該ルーティングＩＤから次ホップＢＡＰアドレス（又は次ホップＢＡＰアドレスに対応する流出バックホールリンク）を特定する。この場合、ＢＡＰレイヤは、当該設定によるトポロジ間リルーティング用のルーティングテーブルを利用してもよい。例えば、ＢＡＰレイヤは、当該ルーティングＩＤと一致するエントリを、トポロジ間リルーティング用のルーティングテーブルから読み出し、当該エントリの次ホップＢＡＰアドレスに対応する流出バックホールリンクを特定してもよい。

【0304】

第３に、ＢＡＰレイヤは、当該設定から流出バックホールＲＬＣチャネルを特定する。この場合、ＢＡＰレイヤは、当該設定によるトポロジ間リルーティング用のマッピングテーブルを利用してもよい。例えば、ＢＡＰレイヤは、当該パケットの流入バックホールＲＬＣチャネル、流入バックホール、特定した流出バックホールリンクと一致するエントリを読み出し、当該エントリに含まれる流出バックホールＲＬＣチャネルを特定してもよい。

【0305】

第４に、ＢＡＰレイヤは、特定した流出バックホールリンクの特定した流出バックホールＲＬＣチャネルへ、滞留している当該パケットを出力する。

【0306】

なお、上記流出バックホールリンクの特定と、上記流出バックホールＲＬＣチャネルの特定とに関し、例えば、以下のように処理が行われてもよい。すなわち、ＢＡＰレイヤは、ＩＡＢノード３００に滞留する送信待ちのパケットについて、当該パケットのヘッダに含まれるルーティングＩＤと一致するエントリがルーティングテーブルに無く、かつ、当該パケットのヘッダに含まれる宛先と一致するエントリがルーティングテーブルに無い場合、当該設定で設定されたバックホールＲＬＣチャネルを送信先として選択し、選択したバックホールＲＬＣチャネルを介して、滞留パケットを送信する。つまり、ＢＡＰレイヤは、このような場合に、トポロジ間リルーティング用の通信路へ滞留パケットを送信する。

【0307】

また、ＩＡＢノード３００のＢＡＰレイヤは、当該設定に従い、流入バックホールリンクと流入バックホールＲＬＣチャネルから、ドナーノードＡ（２００－Ａ）が送信したダウンリンク方向のパケットを、ドナーノードＢ（２００－Ｂ）を介して受信してもよい。

【0308】

ステップＳ９７において、ドナーノードＡ（２００－Ａ）又はＩＡＢノード３００は、ドナーノードＡ（２００－Ａ）とＩＡＢノード３００との間のＦ１接続が解放された場合、Ｆ１通信が完了したことを示す情報（例えば、前記通信路の破棄要求）を、ドナーノードＢ（２００－Ｂ）へ通知する。

【0309】

例えば、ドナーノードＡ（２００－Ａ）が、ドナーノードＢ（２００－Ｂ）とＩＡＢノード３００間のトポロジ間リルーティング用の通信の破棄要求を、ドナーノードＢ（２００－Ｂ）へ送信する。そして、ドナーノードＢ（２００－Ｂ）は、当該破棄要求に対する肯定応答をドナーノードＡ（２００－Ａ）へ返送することで、当該通知と当該通信の破棄とを同時に実行することも可能である。若しくは、ＩＡＢノードのＦ１レイヤが、Ｆ１セットアップ要求をドナーノードＢ（２００－Ｂ）へ送信することで、暗示的に、当該Ｆ１接続が解放されたことを通知してもよい。

【0310】

ステップＳ９８において、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００から、ステップＳ９５で設定した、トポロジ間リルーティング用のバックホールＲＬＣチャネル設定（又はトポロジ間リルーティング用の通信路の設定）を取り除く。すなわち、中継ノード（例えば、ＩＡＢノード３００）は、第１ドナーノード（例えば、ドナーノードＡ（２００－Ａ））とのＦ１接続又は第１上位ノード（例えば、ＩＡＢノード３００－Ｐ１）とのＦ１接続が解放された場合、トポロジ間リルーティング用の通信路の設定を破棄する。

【0311】

例えば、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００に対して、当該設定を取り除くよう指示を行ってもよい。また、ＩＡＢノード３００が自動的に当該設定を取り除いてもよい。後者の場合、ＩＡＢノード３００は、ステップＳ９７におけるＦ１通信完了の通知をトリガにして、当該設定を取り除いてもよい。

【0312】

ステップＳ９９において、ドナーノードＢ（２００－Ｂ）は、一連の処理を終了する。

【0313】

（第２実施形態の変形例）
第２実施形態では、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）に対してＲＲＣ接続を再確立し、ドナーノードＢ（２００－Ｂ）は、ＲＲＣメッセージを利用して、ＩＡＢノード３００に対して、トポロジ間リルーティング用の通信路の設定を行った。

【0314】

第２実施形態の変形例では、ＲＲＣに代えて、Ｆ１を利用して、当該通信路の設定を行う例である。具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、第１ドナーノード（例えば、ドナーノードＡ（２００－Ａ））との接続又は第１上位ノード（例えば、ＩＡＢノード３００－Ｐ１）との接続において、ＢＨ ＲＬＦを検出する。第２に、中継ノードが、第２ドナーノード（例えば、ドナーノードＢ（２００－Ｂ））又は第２上位ノード（例えば、ＩＡＢノード３００－Ｐ２）に対して、Ｆ１セットアップを実施した際に、第１ドナーノードとの通信を継続することを示す情報を通知する。ここで、第１上位ノードは、第１ドナーノードが管理するノードであって、中継ノードの上位ノードである。また、第２上位ノードは、第２ドナーノードが管理するノードであって、中継ノードの上位ノードである。

【0315】

これにより、例えば、ターゲットドナーノードでは、ＩＡＢノードとソースドナーノードとの間で通信が継続されることを把握でき、この通知をトリガにして、トポロジ間リルーティング用の通信路の設定を、Ｆ１ＡＰメッセージを利用して、ＩＡＢノードに対して行うことが可能となる。そして、当該通信路の設定により、ＩＡＢノードは、トポロジ間リルーティングを適切に行うことが可能となる。

【0316】

図２１は、第２実施形態に係る変形例を表す図である。

【0317】

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

【0318】

ステップＳ１０１とステップＳ１０２は、第２実施形態のステップＳ９１とステップＳ９２とそれぞれ同じである。

【0319】

ステップＳ１０３において、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）との間で、ＲＲＣ再確立手順を実行して、ドナーノードＢ（２００－Ｂ）との間でＲＲＣ接続を再確立する。その後、ＩＡＢノード３００は、Ｆ１セットアップ手順を実行して、ドナーノードＢ（２００－Ｂ）との間でＦ１接続を確立する。

【0320】

なお、Ｆ１セットアップ手順は、ＩＡＢノード３００のＩＡＢ－ＤＵとドナーノードＢ（２００－Ｂ）のＣＵとの間で行われる。Ｆ１セットアップ手順は、例えば、以下のようして行われる。

【0321】

第１に、ＩＡＢノード３００は、ドナーノードＢ（２００－Ｂ）へ、Ｆ１セットアップ要求（Ｆ１ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ）メッセージを送信する。この際に、ＩＡＢノード３００は、第２実施形態と同様に、当該メッセージにおいて、ドナーノードＡ（２００－Ａ）との通信を継続することを示す情報を通知する。又は、ＩＡＢノード３００は、第２実施形態と同様に、トポロジ間リルーティングの能力を有していることを示す情報を通知してもよい。また、ＩＡＢノード３００は、ドナーノードＡ（２００－Ａ）とのＦ１接続が残っていることを示す情報を通知してもよい。なお、当該通知は、後のＦ１セットアップ応答（Ｆ１ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅ）メッセージ、又は、更に後のＵＥアシスタンス情報メッセージにおいて行われてもよい。

【0322】

第２に、ドナーノードＢ（２００－Ｂ）は、当該要求を受け入れて、ＩＡＢノード３００へ、Ｆ１セットアップ応答メッセージを送信する。

【0323】

これにより、ＩＡＢノード３００とドナーノードＢ（２００－Ｂ）との間でＦ１接続が確立する。

【0324】

ステップＳ１０４は、第２実施形態のステップＳ９４と同じである。

【0325】

ステップＳ１０５において、ドナーノードＢ（２００－Ｂ）は、ＩＡＢノード３００に対して、トポロジ間リルーティング用の（テンポラリな）通信路を設定する。当該設定は、Ｆ１再設定更新（Ｆ１ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅ）メッセージを用いて行われる。設定内容は、第２実施形態と同じである。当該設定には、第２実施形態と同様に、トポロジ間リルーティング用の（テンポラリな）バックホールＲＬＣチャネルを確立するための設定が含まれる。ＩＡＢノード３００のＦ１ＡＰレイヤは、当該設定を受信すると、当該設定をＩＡＢノード３００のＢＡＰレイヤへ出力する。ＢＡＰレイヤは、第２実施形態と同様に、当該設定を、ルーティングテーブル及び／又はマッピングテーブルとして扱ってもよい。

【0326】

なお、当該設定は、Ｆ１セットアップ応答メッセージを用いて行われてもよい。

【0327】

ステップＳ１０６において、ＩＡＢノード３００のＢＡＰレイヤは、当該設定に従い、トポロジ間リルーティング処理を行う。トポロジ間リルーティング処理自体は、第２実施形態と同様である。

【0328】

ステップＳ１０７とステップＳ１０８は、第２実施形態のステップＳ９７とステップＳ９８とそれぞれ同じである。

【0329】

そして、ステップＳ１０９において、ドナーノードＢ（２００－Ｂ）は、一連の処理を終了する。

【0330】

以上、トポロジ間リルーティングのシナリオ（Ｓ３－２）に関する第２実施形態について説明した。次に、ドナーＤＵ間リルーティングのシナリオ（Ｓ２－２）について説明する。

【0331】

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

【0332】

第３実施形態は、ドナーＤＵ間リルーティングについて説明する。

【0333】

例えば、図９（Ｂ）に示すトポロジ構成例の場合、ドナーノードのＤＵが複数存在する。そのため、ドナーノードのＤＵのＢＡＰアドレスも複数存在する。図９（Ｂ）の例では、ドナーノードＤＵ＃１（２００Ｄ１）のＢＡＰアドレスと、ドナーノードＤＵ＃２（２００Ｄ２）のＢＡＰアドレスの２つが存在する。

【0334】

ここで、ダウンストリーム方向のパケットに関し、発信元（ドナーノードのＤＵ）は、ＩＡＢノード３００－１におけるルーティング処理に関与しない。また、ダウンストリーム方向のパケットに関し、宛先（アクセスＩＡＢノード）は、ルーティング処理を行っても変わらない。そのため、ダウンストリーム方向のドナーＤＵ間リルーティングは、とくに問題は生じないことが予想される。

【0335】

一方、アップストリーム方向に関し、ドナーＤＵ間リルーティングを行うと、宛先（ドナーノードのＤＵ）が変わる。つまり、各パケットについて、宛先ＢＡＰアドレスが変更となる。このため、ＩＡＢノード３００－１では、ＢＡＰヘッダ書き替え処理が行われる場合がある。３ＧＰＰでは、ＢＡＰヘッダ書き替え処理として、「“ｐｒｅｖｉｏｕｓ ｒｏｕｔｉｎｇ ＩＤ ｔｏ ｎｅｗ ｒｏｕｔｉｎｇ ＩＤ” ＢＡＰ ｒｅｗｒｉｔｉｎｇ」が合意された。

【0336】

ここで、本シナリオでは、２つの課題がある。

【0337】

第１に、リルーティングは、ルーティングとは異なり、一旦、ルーティング処理を行い、行先のないパケットに対して、再度ルーティング処理を行うことが原則である。そのため、ＢＡＰヘッダ書き替え処理を行うタイミングを考慮する必要がある。

【0338】

第２に、ＩＡＢノード３００－１が受信したパケットの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するルートを適当に選択するのか、或いは、ドナーノードによって、代替パスが明示的に設定されるのかが明確ではない。そのため、設定が複雑になる場合も考えられる。

【0339】

（第１動作例）
次に、第３実施形態に係る第１動作例について説明する。

【0340】

第１動作例では、一旦、ルーティング処理を行い、送信できなかったパケットに対してＢＡＰヘッダ書き替え処理を行い、その後、再度ルーティング処理を行う動作例である。

【0341】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－１）が、パケットを受信する。第２に、中継ノードが、当該パケットに対して、ルーティング処理を行い、次ホップＢＡＰアドレスを選択できないこと、又は流出バックホールリンクを選択できないこと、を確認する。第３に、中継ノードが、確認を行った当該パケットをドナーＤＵ間リルーティングの対象のパケットと判定する。第４に、中継ノードが、ドナーＤＵ間リルーティングの対象のパケットと判定した当該パケットに対して、再度ルーティング処理を行う。

【0342】

これにより、例えば、ルーティング処理を行い、行先のないパケットに対して、再度ルーティング処理を行うという、リルーティングの原則に則った処理を行うことができる。

【0343】

そして、中継ノードが、ドナーＤＵ間リルーティング対象のパケットと判定した当該パケットに対して、当該パケットの宛先を書き替えるＢＡＰヘッダ書き替え処理を実行する。この場合、中継ノードは、パケットの宛先を書き替えたパケットに対して、再度ルーティング処理を行う。

【0344】

これにより、例えば、ＩＡＢノード３００－１では、ＢＡＰヘッダ書き替え処理、ルーティング処理、及び再度のルーティング処理を適切に行うことができる。

【0345】

図２２は、第３実施形態に係る第１動作例を表す図である。例えば、図９（Ｂ）に示す構成例を適宜参照しながら、図２２を説明する。

【0346】

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

【0347】

ステップＳ１１１において、ＩＡＢノード３００－１は、ドナーノード２００から、所定の設定を受ける。所定の設定は、例えば、以下である。

【0348】

第１に、ヘッダ書き替えテーブルの設定が行われる。この場合、ヘッダ書き替えテーブルには、第１実施形態で説明したトポロジ間ルーティング用のヘッダ書き替えテーブルと、第３実施形態に係るドナーＤＵ間リルーティング用のヘッダ書き替えテーブルとが設定される。２つのテーブルには、各テーブルを識別する識別子が含まれてもよい。

【0349】

第２に、２つのドナーＤＵのＢＡＰアドレスが設定される。図９（Ｂ）の例では、ドナーＤＵ＃１（２００Ｄ１）とドナーＤＵ＃２（２００Ｄ２）の２つのＢＡＰアドレスが設定される。なお、設定されるＢＡＰアドレスは、３つ以上あってもよい。

【0350】

ステップＳ１１２において、ＩＡＢノード３００－１のＢＡＰレイヤの送信部は、ＩＡＢノード３００－１のＢＡＰレイヤの受信部から、パケットを受信する。ここで、ＢＡＰレイヤの受信部は、第１実施形態と同様に、ダウンストリーム方向における自身宛てのパケットを、上位レイヤへ出力してもよい。例えば、自身がアクセスＩＡＢノードのため、ルーティング処理などを行わなくてもよいからである。従って、送信部は、受信部から、自身宛のパケット以外のパケットを受信する。

【0351】

ステップＳ１１３において、送信部は、当該パケットに対して、ルーティング処理を行う。ルーティング処理では、例えば、以下の処理が行われる。

【0352】

第１に、送信部は、当該パケットのＢＡＰヘッダを確認し、宛先（Ｄｅｓｔｉｎａｔｉｏｎ）とパスＩＤ（Ｐａｔｈ ＩＤ）が一致するエントリがルーティングテーブルに存在しない、又は、当該エントリが存在しても、当該エントリに対応する次ホップＢＡＰアドレスが使用可能（ａｖａｉｌａｂｌｅ）ではないことを確認する（Ｒｅｌ－１６のルーティング処理）。

【0353】

第２に、送信部は、当該パケットのＢＡＰヘッダを確認し、宛先が一致するエントリがルーティングテーブルに存在しない、又は、当該エントリが存在しても、当該エントリに対応する次ホップＢＡＰアドレスが使用可能（ａｖａｉｌａｂｌｅ）ではないことを確認する（Ｒｅｌ－１６のリルーティング処理）。

【0354】

つまり、送信部は、上記２つを確認し、次ホップＢＡＰアドレスが選択できない状態になっていることを確認する。

【0355】

送信部は、次ホップＢＡＰアドレスが使用可能である場合、対応する流出バックホールリンクが使用可能（ａｖａｉｌａｂｌｅ）ではないことを確認する。つまり、送信部は、流出バックホールリンクが選択できない状態であることを確認する。

【0356】

第３に、送信部は、マッピング処理において、流出バックホールＲＬＣチャネルが選択できないことを確認してもよい。すなわち、送信部は、当該パケットの流入バックホールＲＬＣチャネルと流入バックホールリンク、及びルーティング処理で選択した流出バックホールリンクと一致するエントリが、マッピングテーブルに存在しないことを確認してもよい。

【0357】

第４に、送信部は、当該パケットのＢＡＰヘッダを確認し、宛先がドナーノード２００のＤＵ（例えば、ドナーノードＤＵ＃１（２００Ｄ１））のＢＡＰアドレスであることを確認する。ドナーノードのＤＵのＢＡＰアドレスは、例えば、ステップＳ１１１においてドナーノード２００によってＩＡＢノード３００－１に対して設定されている。そのため、送信部は、このＢＡＰアドレスと当該パケットの宛先とを比較することで確認可能である。なお、当該確認によって、ダウンストリーム方向に対するＢＡＰヘッダの書き替えを防止し、アップストリーム方向のパケットに対してヘッダ書き替えを行うようにすることが可能となる。

【0358】

第５に、送信部は、当該パケットがドナーノード２００のＤＵ宛てであることを確認すると、ドナーＤＵ間リルーティング対象（又はアップストリーム方向）のパケットであるとして、マーキングをしてもよい。送信部は、マーキングの代わりに、特別な送信バッファ（すなわち、ドナーＤＵ間リルーティング用バッファ）に当該パケットを格納してもよい。

【0359】

送信部は、当該パケットが、ドナーＤＵ間リルーティング対象（又はアップストリーム方向）のパケットであり、かつ、ヘッダ書き替えテーブルが設定されている場合、次のヘッダ書き替え処理へ移行する。

【0360】

ステップＳ１１４において、送信部は、当該パケットに対して、ヘッダ書き替え処理を行う。ヘッダ書き替え処理は、第１実施形態における第１動作例のステップＳ１６（図１０）と同様である。

【0361】

ステップＳ１１５において、送信部は、ヘッダ書き替え処理が完了したパケットに対して、再度ルーティング処理と再度マッピング処理を行う。送信部は、２つの処理により、流出バックホールリンクと流出バックホールＲＬＣチャネルとを選択する。

【0362】

ステップＳ１１６において、送信部は、選択した流出バックホールリンクの選択した流出バックホールＲＬＣチャネルへ、当該パケットを出力する。そして、ＩＡＢノード３００－１は、当該パケットを、選択した次ホップのノードへ送信する。

【0363】

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

【0364】

（第１動作例のまとめ）
図２３は、第３実施形態に係る第１動作例をまとめた図である。

【0365】

図２３において、ステップＳ１２０は、図２２のステップＳ１１２に対応する。図２３のステップＳ１２２は、図２２のステップＳ１１３に対応する。図２３のステップＳ１２３は、図２２のステップＳ１１４に対応する。

【0366】

図２３に示すように、送信部は、ルーティング処理とマッピング処理（ステップＳ１２２）を行って、ルーティング処理においてルーティングできなかったパケット、又はマッピング処理においてマッピングできなかったパケットに対して、ＢＡＰヘッダ書き替え処理を行う（ステップＳ１２３）。

【0367】

そして、送信部は、再度、ルーティング処理とマッピング処理を行って、処理済のパケットをドナーＤＵ間リルーティング済のパケットとして、次ホップノードへ送信する。

【0368】

（第１動作例の変形例）
第３実施形態に係る第１動作例の少なくとも一部は、ドナーＤＵ間リルーティング以外のシナリオにも適用可能である。

【0369】

（第２動作例）
次に、第３実施形態に係る第２動作例について説明する。

【0370】

３ＧＰＰ ＴＳ３８．３４０ Ｖ１６．５．０（２０１６－０６）の５．２．１．１「Ｇｅｎｅｒａｌ」には、以下の記載がある。
「NOTE: Data buffering on the transmitting part of the BAP entity, e.g., until RLC-AM entity has received an acknowledgement, is up to implementation. In case of BH RLF, the transmitting part of the BAP entity may reroute the BAP Data PDUs, which has not been acknowledged by lower layer before the BH RLF, to an alternative path in accordance with clause 5.2.1.3.」
下線部に示すように、３ＧＰＰにおけるリルーティングは、送信済のパケットのうち、下位レイヤにおいてＡｃｋが確認されなかったパケットに対して行われる。

【0371】

そこで、第２動作例では、送信済のパケットに対して、ドナーＤＵ間リルーティングを行う動作例について説明する。

【0372】

具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００－１）が、パケット送信後、当該パケットの複製（又はコピー）をバッファに記憶する。第２に、中継ノードが、バッファに記憶したパケットから、ドナーＤＵ間リルーティング対象のパケットを選択する。第３に、中継ノードが、選択したパケットに対して、当該パケットの宛先を書き替えるＢＡＰヘッダ書き替え処理を行う。第４に、中継ノードが、ＢＡＰパケット書き替え処理を行ったパケットに対して、再度ルーティング処理を行う。

【0373】

これにより、例えば、ＩＡＢノード３００－１では、バッファに滞留しているパケットの中から、ドナーＤＵ間リルーティング対象のパケットを選択することができ、適切にドナーＤＵ間リルーティングを行うことが可能となる。

【0374】

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

【0375】

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

【0376】

ステップＳ１３１において、ＩＡＢノード３００－１のＢＡＰレイヤは、パケットを送信後、当該パケットのコピーをバッファに格納する。ＢＡＰレイヤは、当該パケットの送信に用いた、ルーティングＩＤ、次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルの少なくも１つを、バッファに格納した当該パケットと紐づけて格納してもよい。若しくは、ルーティングＩＤ、次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルのいずれかに紐づいた複数のバッファを有してもよい。この場合、ＢＡＰレイヤは、当該パケットの送信先に応じて、該当するバッファに当該パケットのコピーを格納してもよい。なお、ＢＡＰレイヤは、下位レイヤ（ＲＬＣ）より、当該パケットの送達確認の通知を受けた場合、バッファに格納した当該パケット（のコピー）をバッファから削除する。

【0377】

ステップＳ１３２において、ＢＡＰレイヤは、ドナーＤＵ間リルーティングの実行を判断したとき、ドナーＤＵ間リルーティングの対象となるパケットを、バッファに格納したパケットの中から選択する。当該ドナーＤＵ間リルーティングの実行判断と当該ドナーＤＵ間リルーティング対象パケットの選択は、例えば、以下のようにして行われる。

【0378】

第１に、ＩＡＢノード３００－１は、ＢＨ ＲＬＦを検出した場合に当該リルーティングを実行すると判断する。ＩＡＢノード３００－１は、当該ＢＨ ＲＬＦを検出した流出バックホールリンクを特定してもよい。若しくは、ＩＡＢノード３００－１は、当該流出バックホールリンクから影響を受ける、ルーティングＩＤ、次ホップＢＡＰアドレス、及び流出バックホールＲＬＣチャネルの少なくとも１つを特定してもよい。ＩＡＢノード３００－１は、特定した流出バックホールリンク（又は、ルーティングＩＤ、次ホップＢＡＰアドレス、及び流出バックホールＲＬＣチャネルの少なくとも１つ）と紐づいたパケットをバッファから選択する。当該パケットが当該リルーティング対象パケットとなり得る。

【0379】

第２に、ＩＡＢノード３００－１は、Ｔｙｐｅ２ ＢＨ ＲＬＣ Ｉｎｄｉｃａｔｉｏｎを受信した場合に当該リルーティングを実行すると判断する。Ｔｙｐｅ２ ＢＨ ＲＬＣ Ｉｎｄｉｃａｔｉｏｎは、ＢＨ ＲＬＦからの回復を施行中であることを示すＩｎｄｉｃａｔｉｏｎである。ＩＡＢノード３００－１の上位ノードであるＩＡＢノード３００－Ｐ１のＩＡＢ－ＤＵが、ＩＡＢノード３００－１のＩＡＢ－ＭＴへ当該Ｉｎｄｉｃａｔｉｏｎを送信する。ＩＡＢノード３００－１は、当該Ｉｎｄｉｃａｔｉｏｎを受信した流出バックホールリンクを特定してもよい。若しくは、ＩＡＢノード３００－１は、当該Ｉｎｄｉｃａｔｉｏｎにルーティングできない（又は影響を受ける、若しくはリルーティングすべき）、ルーティングＩＤとバックホールＲＬＣチャネルＩＤとが通知されている場合、これらのＩＤを特定してもよい。若しくは、ＩＡＢノード３００－１は、特定したこれらの情報から、影響を受ける次ホップＢＡＰアドレスを特定してもよい。ＩＡＢノード３００－１は、特定した流出バックホールリンク（又は、ルーティングＩＤ、流出バックホールＲＬＣチャネル、及び次ホップＢＡＰアドレスの少なくとも１つ）に紐づいたパケットをバッファから選択する。当該パケットが当該リルーティング対象パケットとなり得る。

【0380】

第３に、ＩＡＢノード３００－１は、アップリンク方向のフロー制御フィードバック（Ｆｌｏｗ ｃｏｎｔｒｏｌ ｆｅｅｄｂａｃｋ）を、ＩＡＢノード３００－１の上位ノードから受信した場合に当該リルーティングを実行すると判断する。当該フロー制御フィードバックを上位ノードから受信したＩＡＢノード３００－１は、上位ノードへのデータ送信量などを少なくするなどの制御を行うことで、ＩＡＢノード間の混雑を回避すること等が可能となる。ＩＡＢノード３００－１のＩＡＢ－ＭＴ（のＢＡＰレイヤ）が、上位ノードのＩＡＢ－ＤＵから送信された当該フィードバックを受信できる。ＩＡＢノード３００－１は、当該フィードバックを受信した流出バックホールリンクを特定してもよい。若しくは、ＩＡＢノード３００－１は、当該フィードバックにより、影響を受ける使用可能バッファサイズ（ａｖａｉｌａｂｌｅ ｂｕｆｆｅｒ ｓｉｚｅ）と紐づいたルーティングＩＤ又はバックホールＲＬＣチャネルを特定してもよい。使用可能なバッファサイズが閾値（ドナーノード２００により設定）を下回った場合に、当該バッファサイズと紐づいたルーティングＩＤ又はバックホールＲＬＣチャネルを、当該リルーティング対象としてもよい。若しくは、ＩＡＢノード３００－１は、特定したこれらの情報から次ホップＢＡＰアドレスを特定してもよい。ＩＡＢノード３００－１は、特定したルーティングＩＤ、流出バックホールリンク、流出バックホールＲＬＣチャネル、及び次ホップＢＡＰアドレスのうち少なくとも１つに紐づいたパケットをバッファから選択する。当該パケットが当該リルーティング対象パケットとなり得る。

【0381】

ＩＡＢノード３００－１は、他の何等かの基準で当該リルーティングを実行する場合も、同様にして、当該リルーティング対象のパケットを選択してもよい。

【0382】

ステップＳ１３３において、ＩＡＢノード３００－１は、選択したパケットに対して、ＢＡＰヘッダ書き替え処理を行う。ＢＡＰヘッダ書き替え処理は、第１実施形態の第１動作例（図１０のステップＳ１６）と同様である。

【0383】

ステップＳ１３４において、ＩＡＢノード３００－１は、ＢＡＰヘッダ書き替え処理を行ったパケットに対して、パケット送信前に行ったルーティング処理とマッピング処理とを再度行う。ＩＡＢノード３００－１は、処理済の当該パケットを次ホップノードへ送信する。

【0384】

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

【0385】

（第２動作例の変形例）
第２動作例の少なくとも一部は、ドナーＤＵ間リルーティング以外のシナリオにも適用可能である。

【0386】

（第３動作例）
次に、第３実施形態に係る第３動作例について説明する。

【0387】

第１実施形態と第２実施形態では、ＩＡＢノード３００のＢＡＰレイヤが、ドナーノード２００から設定されたＢＡＰヘッダ書き替えテーブルを参照して、ＢＡＰヘッダ書き替えを行う例を説明した。

【0388】

一方、Ｒｅｌ－１６では、ＢＡＰレイヤが、通常のルーティングテーブルを参照して、ＢＡＰヘッダの宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するルーティングＩＤの中から、リルーティング先のルーティングＩＤを適当に選択していた。これは、Ｒｅｌ－１６では、ＣＵ内／ドナーＤＵ内リルーティング（Ｓ１－２）が想定されていたため、同一トポロジ内にリルーティング先のルートがあることが前提であったため、問題は生じ得なかった。

【0389】

ここで、同様のコンセプト（つまり、ＢＡＰヘッダ書き替えテーブルが存在しない場合のコンセプト）がドナーＤＵ間リルーティングに適用される場合の課題について検討する。

【0390】

第１に、ダウンストリーム方向については、宛先はアクセスＩＡＢノードであり、これは、Ｒｅｌ－１６と変わらない。そのためダウンストリーム方向については、課題については検討しないことにする。

【0391】

第２に、アップストリーム方向については、ドナーノードのＤＵが複数存在する（＝宛先ＢＡＰアドレスが複数存在する）。ただし、ドナーノードの複数のＤＵは、同一のドナーノードのＣＵに管理される。そのため、当該ドナーノードのＣＵが管理するルーティングテーブルには、例えば、ドナーＤＵ＃１（２００Ｄ１）のＢＡＰアドレスと、ドナーＵ＃２（２００Ｄ２）のＢＡＰアドレスの２つのＢＡＰアドレス（宛先）が存在するはずである。

【0392】

しかし、ＢＡＰヘッダに含まれる宛先（例えば、ドナーＤＵ＃１（２００Ｄ１））だけを手掛かりにルーティングテーブルを参照しても、別のドナーノードのＤＵ（例えば、ドナーＤＵ＃２（２００Ｄ２））とはＢＡＰアドレス自体が異なるため、当該別のドナーのＤＵへのルーティングＩＤを候補として選択できない場合がある。

【0393】

また、３ＧＰＰでは、ドナーＤＵ間リルーティングについて、直前のルーティングＩＤから新たなルーティングＩＤへのＢＡＰヘッダ書き替えを行うことが既に合意済である。

【0394】

そこで、第３動作例は、ドナーノード２００が、宛先（例えば、ドナーＤＵ＃１（２００Ｄ１））と紐づけられたａｌｔｅｒｎａｔｉｖｅ ｄｅｓｔｉｎａｔｉｏｎ（代替宛先（例えば、ドナーＤＵ＃２（２００Ｄ２）））をＩＡＢノード３００－１に設定する。そして、ＩＡＢノード３００－１は、代替宛先を含むルーティングＩＤをルーティングテーブルから選択し、選択したルーティングＩＤをＢＡＰヘッダに書き込むことで、ＢＡＰヘッダ書き替えを行う。

【0395】

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、中継ノード（例えば、ＩＡＢノード３００－１）に対して、第１ドナーノード（例えば、ドナーＤＵ＃１（２００Ｄ１））の第１宛先アドレスと、第２ドナーノード（例えば、ドナーＤＵ＃２（２００Ｄ２））の第２宛先アドレスとを設定する。第２に、中継ノードが、アップストリーム方向のパケットを受信する。第３に、中継ノードが、ルーティング処理を行い、パケットを次ホップ中継ノードへ送信できないことを判別する。第４に、中継ノードが、判別したパケットに対して、当該パケットの第１宛先アドレスと一致するＢＡＰアドレスを含む第１ルーティングＩＤがルーティングテーブルに存在しない場合、第２宛先アドレスと一致するＢＡＰアドレスを含む第２ルーティングＩＤをルーティングテーブルから選択する。第５に、中継ノードが、第２ルーティングＩＤを当該パケットのヘッダに書き込む。ここで、第２宛先アドレスは第１宛先アドレスに紐づけられている。

【0396】

これにより、ＩＡＢノード３００－１は、ドナーＤＵ間リルーティングに際して、ＢＡＰヘッダ書き替えテーブルを使用することなく、ＢＡＰヘッダ書き替えを行うことが可能となる。

【0397】

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

【0398】

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

【0399】

ステップＳ１４１において、ＩＡＢノード３００－１は、ドナーノード２００から所定の設定を受ける。所定の設定は、例えば、以下である。

【0400】

すなわち、所定の設定は、ドナーノード２００の複数のＤＵについてのＢＡＰアドレスである。若しくは、所定の設定は、ドナーＤＵ間リルーティングに用いる代替宛先（ａｌｔｅｒｎａｔｉｖｅ ｄｅｓｔｉｎａｔｉｏｎ）である。例えば、ある宛先（例えば、ドナーＤＵ＃１（２００Ｄ１））のＢＡＰアドレスと、代替宛先（例えば、ドナーＤＵ＃２（２００Ｄ２））のＢＡＰアドレスと、が紐づけられて設定される。若しくは、ある宛先（例えば、ドナーＤＵ＃１（２００Ｄ１）とドナーＤＵ＃２（２００Ｄ２））が（アップストリーム方向の）代替宛先として使用可能であることを示す識別子が設定されてもよい。

【0401】

ステップＳ１４２において、ＩＡＢノード３００－１は、パケットを下位ノードから受信する。

【0402】

ステップＳ１４３において、ＩＡＢノード３００－１は、通常のルーティング処理を行い、次ホップノードが選択できない（又は送信できない）ことを確認する。ステップＳ１４３における処理は、例えば、第３実施形態に係る第１動作例（図２２のステップＳ１１３）と同様でもよい。

【0403】

ステップＳ１４４において、ＩＡＢノード３００－１は、当該パケットのヘッダに含まれる宛先（Ｄｅｓｔｉｎａｔｉｏｎ）と一致するＢＡＰアドレスを有するルーティングＩＤをルーティングテーブルにおいて検索する。

【0404】

第１に、ＩＡＢノード３００－１は、当該ルーティングＩＤを含むエントリがルーティングテーブルに存在し、対応する次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルが使用可能（ａｖａｉｌａｂｌｅ）である場合、当該設定に従って、再度ルーティング処理を行う。

【0405】

第２に、当該エントリがルーティングテーブルに存在しない場合、対応する次ホップＢＡＰアドレスが使用不可能（ｕｎａｖｉｌａｂｌｅ、又はｃｏｎｇｅｓｔｅｄ）である場合、又は対応する流出バックホールリンク及び／又は流出バックホールＲＬＣチャネルが使用不可能（ｕｎａｖｉｌａｂｌｅ、又はｃｏｎｇｅｓｔｅｄ）である場合、以下の処理へ進む。

【0406】

すなわち、ＩＡＢノード３００－１は、当該パケットがアップストリーム方向であると判定したとき、当該パケットの宛先と紐づけられた代替宛先（当該宛先とは異なる別ドナーノードのＤＵのＢＡＰアドレス）と一致するＢＡＰアドレスを含むルーティングＩＤをルーティングテーブルにおいて検索する。

【0407】

ここで、アップストリーム方向であることの判定方法は、当該パケットのヘッダに含まれる宛先が、ステップＳ１４１で設定されたドナーノード２００のＤＵのＢＡＰアドレスと一致した場合、ＩＡＢノードは当該パケットがアップストリーム方向であると判定できる。また、当該パケットのヘッダに含まれる宛先と一致する代替宛先がステップＳ１４１による設定で存在する場合に、ＩＡＢノード３００－１は、アップストリーム方向であると判定できる。

【0408】

ＩＡＢノード３００－１は、当該検索の結果、ルーティングテーブルに、別ドナーノード（又は代替宛先）のＤＵのＢＡＰアドレスを含むルーティングＩＤが存在する場合、当該ルーティングＩＤを選択する。その後、ＩＡＢノード３００－１は、当該ルーティングＩＤと対応する次ホップＢＡＰアドレスを選択し、対応する流出バックホールリンクと、流出バックホールＲＬＣチャネルとを選択する。この際、ＩＡＢノード３００－１は、選択した次ホップＢＡＰアドレス、流出バックホールリンク、及び流出バックホールＲＬＣチャネルが送信可能（ａｖａｉｌａｂｌｅ）であることを確認する。

【0409】

ステップＳ１４５において、ＩＡＢノード３００－１は、当該選択したルーティングＩＤを当該パケットのヘッダに書き込む。つまり、ＩＡＢノード３００－１は、代替宛先を含むルーティングＩＤを選択した場合に、当該ルーティングＩＤをヘッダに書き込む。これにより、ＢＡＰヘッダ書き替えが行われる。ここで、ＩＡＢノード３００－１は、ＢＡＰヘッダ書き替えに関する情報をドナーへ報告してもよい。当該情報は、リルーティング処理に伴ってＢＡＰヘッダ書き替えを行った場合の、書き替え前のルーティングＩＤ（すなわち、旧ルーティングＩＤ又はPrevious Routing ID）及び／又は書き替え後のルーティングＩＤ（すなわち、新たなルーティングＩＤ又はNew Routing ID）であってもよい。当該情報は更にリルーティングが実行された時間（時刻）情報、リルーティングが実行されたパケット数を含んでもよい。当該情報は、リルーティング処理が発生するたびにＩＡＢノード３００－１の内部メモリに記録（ログ）されてもよい。当該報告は、リルーティング処理が行われる毎に（すなわち即座に）行われてもよく、ドナーからの要求に伴って（すなわち後で）行われてもよい。

【0410】

ステップＳ１４６において、ＩＡＢノード３００－１のＢＡＰレイヤは、選択した流出バックホールリンクの選択した流出バックホールＲＬＣチャネルへ、当該パケットを出力する。ＩＡＢノード３００－１は、当該パケットを次ホップのＩＡＢノードへ（又はドナーＤＵ＃２（２００Ｄ２）へ向けて）送信する。

【0411】

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

【0412】

（第３動作例のまとめ）
図２６は、第３実施形態に係る第３動作例をまとめたものである。

【0413】

図２６において、ステップＳ１５０は、図２５のステップＳ１４２に対応する。図２６のステップＳ１５２は、図２５のステップＳ１４３とステップＳ１４４に対応する。図２６のステップＳ１５３は、図２５のステップＳ１４５に対応する。

【0414】

ステップＳ１５０において、ＩＡＢノード３００－１はＢＡＰ受信処理を行う。この場合、ＩＡＢノード３００－１は、第１実施形態と同様に、アップストリーム方向だけではなく、ダウンストリーム方向のパケットも受信し、当該パケットが自身宛て（当該パケットがダウンストリーム方向で、ＩＡＢノード３００－１がアクセスＩＡＢノードとなり得る）の場合、上位ノードへ出力するようにしてもよい。この場合、ＩＡＢノード３００－１は、受信パケットのうち、自身宛てのパケット以外のパケットに対して、ＢＡＰ送信処理（ステップＳ１５１）を行う。

【0415】

ステップＳ１５２において、ＩＡＢノード３００－１のＢＡＰレイヤは、ルーティング処理とマッピング処理を行う。この場合、ＢＡＰレイヤは、受信パケットのヘッダに含まれる宛先と異なる宛先へルーティングするアップストリーム方向のパケットをＢＡＰヘッダ書き替え対象のパケットと判定する（図２５のステップＳ１４３とステップＳ１４４）。また、ＢＡＰレイヤは、当該ヘッダの宛先と紐づいた別のドナーノードのＣＵのＢＡＰアドレスを含むルーティングＩＤをルーティングテーブルから検索する。

【0416】

そして、ステップＳ１５３において、ＢＡＰレイヤは、ＢＡＰヘッダ書き替え対象のパケットに対して、当該ルーティングＩＤを用いてＢＡＰヘッダ書き替え処理を行う（図２５のステップＳ１４４）。

【0417】

他方、ステップＳ１５２において、ＢＡＰレイヤは、当該ヘッダに含まれる宛先と同一の宛先へルーティング可能なアップストリーム方向のパケットを、次ホップのノードへ送信する。また、ＩＡＢノード３００－１は、ＢＡＰ送信処理対象のダウンストリーム方向のパケットも、ルーティング処理とマッピング処理により、次ホップのノードへ送信する。

【0418】

（第３動作例の変形例）
第３実施形態に係る第３動作例の少なくとも一部は、ドナーＤＵ間リルーティング以外のシナリオにも適用可能である。

【0419】

［第４実施形態］
第１実施形態から第３実施形態では、トポロジ間ルーティング（Ｓ３－１）、トポロジ間リルーティング（Ｓ３－１）、ドナーＤＵ間リルーティング（Ｓ２－２）の各シナリオについてそれぞれ説明した。

【0420】

では、全てのシナリオにおいて、できるだけ共通の手順又は処理とするにはどのようにすればよいかが問題となる場合がある。

【0421】

図２７は、手順又は処理を全てのシナリオで共通化した場合の一例を表す。図２７は、第４実施形態に係るＩＡＢノード３００の構成例を表している。

【0422】

図２７に示すように、ＩＡＢノード３００は、送信部３３０－Ｔと、受信部３３０－Ｒとを有する。

【0423】

送信部３３０－Ｔは、ＢＡＰヘッダ書き替え決定部３３１、ＢＡＰヘッダ書き替え部３３２、ルーティング／マッピングテーブル選択部３３３、ルーティング／リルーティング処理部３３４、及びマッピング処理部３３５を有する。

【0424】

受信部３３０－Ｒは、上位レイヤ出力決定部３３６を有する。

【0425】

上位レイヤ出力決定部３３６は、受信パケットを上位レイヤへ出力するか、当該パケットを送信部３３０－Ｔへ出力するかを決定する。例えば、第１実施形態で説明したように、当該パケットのヘッダに含まれる、トポロジ間ルーティング対象であるか否かを示す識別子に基づいて決定してもよい。

【0426】

ＢＡＰヘッダ書き替え決定部３３１は、受信部３３０－Ｒから受け取った当該パケットについて、ＢＡＰヘッダ書き替えを行うか否かを決定する。ＢＡＰヘッダ書き替え決定部３３１は、例えば、第１実施形態で説明したように、当該パケットのヘッダが特定のルーティングＩＤにマッチするか否かにより、ＢＡＰヘッダ書き替え対象のパケット（＝トポロジ間ルーティング対象のパケット）を決定してもよい。ＢＡＰヘッダ書き替え決定部３３１は、ＢＡＢヘッダ書き替え対象のパケットをＢＡＰヘッダ書き替え部３３２へ出力し、ＢＡＰヘッダ書き替え対象ではないパケットをルーティング／リルーティング処理部３３４へ出力する。

【0427】

ＢＡＰヘッダ書き替え部３３２は、当該パケットのＢＡＰヘッダを書き替える。ＢＡＰヘッダ書き替え部３３２は、第１実施形態で説明したように、ＢＡＰヘッダ書き替えテーブルを用いて書き替えを行ってもよい。また、ＢＡＰヘッダ書き替え部３３２は、一度もルーティング処理を行っていないパケットに対してはＢＡＰヘッダ書き替えを行わないようにし、ルーティング／リルーティング処理部３３４から出力されたパケットに対して、ＢＡＰヘッダ書き替えを行うようにしてもよい。
ルーティング／マッピングテーブル選択部３３３は、ルーティングテーブルとマッピングテーブルとを選択する。ルーティング／マッピングテーブル選択部３３３は、例えば、第１実施形態で説明したように、第２ルーティングテーブルと第２マッピングテーブルとを選択してもよい。

【0428】

ルーティング／リルーティング処理部３３４は、ＢＡＰヘッダ書き替えを行ったパケットに対してルーティング処理及び／又はリルーティング処理を行い、ＢＡＰヘッダ書き替えを行っていないパケットに対してルーティング処理及び／又はリルーティング処理を行ってもよい。ルーティング／リルーティング処理部３３４は、第３実施形態で説明したように、一旦、ルーティング処理（及び／又はリルーティング処理）を行い、行先の無いのパケットを、ＢＡＰヘッダ書き替え部３３２へ出力してもよい。

【0429】

マッピング処理部３３５は、ルーティング処理後のパケット、又はリルーティング処理後のパケットに対して、マッピングテーブルを用いてマッピング処理を行う。マッピング処理部３３５は、処理済のパケットを、流出バックホールＲＬＣチャネルを介して、次ホップノードへ送信する。

【0430】

上述したように、図２７に示すＩＡＢノード３００の構成例は一例である。

【0431】

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

【0432】

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

【0433】

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

【0434】

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

【0435】

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

【0436】

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

【0437】

（付記）
導入
ＲＡＮ２＃１１５Ｅにおいて、ＮＲ向け統合アクセス及びバックホールの強化（ＥＩＡＢ）の作業項目は、トポロジ適応の強化について以下の合意に達した。

【0438】

フロー制御フィードバックに基づく利用可能なバッファサイズの設定された閾値は、ローカルリルーティングの目的のために、輻輳を決定するために使用される。

【0439】

ＣＵ内の場合、少なくともドナーＤＵ間のＮＲ－ＤＣ、ドナーＤＵ間回復、ドナーＤＵ間移動のシナリオでは、ドナーＤＵ間リルーティングをサポートすること。

【0440】

ＣＵ間リルーティングをサポートする。すなわち、ＩＡＢノードはターゲットＣＵのトポロジ上の代替ＢＡＰパスを介して、元のドナーＣＵにデータをリルーティングする。

【0441】

ドナーDU間のリルーティングにおいて、「直前のルーティングＩＤから新たなルーティングＩＤへ」のBAPヘッダの書き替えをサポートする。

【0442】

ＲＡＮ２でＣＵ間ルーティングのＯｐｅｎ Ｉｓｓｕｅをさらに議論する。
最初のトポロジのＢＡＰヘッダに追加されるＢＡＰアドレス（すなわち、境界ノードにおける流入データのＢＡＰアドレス）とは何か。
トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）とトポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）とをどのように判別するか。
上位レイヤ（ダウンストリーム用）にデータを配信すべきかどうかの決定方法。
データのＢＡＰヘッダを書き替えるべきかどうか（他のトポロジにルーティングされるか、自トポロジにルーティングされるか）の決定方法。

【0443】

ベースラインとして、ＣＵ間ルーティングにおいて、境界ノードでのＢＡＰヘッダの書き替えのための「直前のルーティングＩＤ」から「新たなルーティングＩＤへ」の１：１及びＮ：１マッピングをサポートすること。

【0444】

ベースラインとして、ＣＵ間ルーティングにおいて、境界ノードでのベアラマッピングの「流入ＢＨリンク＋流入ＢＨ ＲＬＣ ＩＤ」から「流出ＢＨリンク＋流出ＢＨ ＲＬＣ ＩＤ」への１：１及びＮ：１マッピングをサポートすること。

【0445】

この付記では、様々なシナリオのためのルーティングとリルーティングの拡張について議論している。

【0446】

議論
ＲＥＬ－１７では、図９に示すように、ルーティング及びリルーティングは、ＣＵ内／ドナーＤＵ内（ＲＥＬ－１６と同様）、ＣＵ内／ドナーＤＵ間及びＣＵ間などのさまざまなシナリオをカバーする必要がある。これらの機能強化は、ＩＡＢトポロジにおけるパケット転送の信頼性、柔軟性、又は低遅延化に貢献すると期待されるが、ＢＡＰルーティング／リルーティング動作にさらなる複雑さをもたらす可能性がある。したがって、すべてのシナリオに共通の手順を規定し、シナリオ固有の手順を可能な限り少なくすることが望ましい。この意味で、最も複雑なシナリオであるＣＰＵ間ルーティングを最初に検討し、その後、ＣＰＵ間ルーティングの手順が他のシナリオに適用（再利用）可能かどうかについて検討する必要がある。

【0447】

ＣＵ間ルーティング
ＣＵ間ルーティングについては、４つのＯｐｅｎ Ｉｓｓｕｅに合意している。Ｏｐｅｎ Ｉｓｓｕｅをどのように解決するかについて検討する良い出発点となる。

【0448】

Ｏｐｅｎ Ｉｓｓｕｅ１：最初のトポロジのＢＡＰヘッダに付加されるＢＡＰアドレス（すなわち、境界ノードでの流入データのＢＡＰアドレス）は何か。

【0449】

以下のようにいくつかの解決例が示されている。
例１：最初のトポロジのＢＡＰ ＰＤＵヘッダに、境界ノードのＢＡＰアドレスを追加する。
例2：実際の宛先の代理／偽BAPアドレスを追加する。

【0450】

一方、ＲＡＮ３では、トポロジの冗長性について以下のように合意している。
１Ａ：ＲＡＮ３は、境界ノードが各トポロジで１つのＢＡＰアドレスのみを有すると仮定する。
１Ｂ：ＲＡＮ３は、各トポロジにおいて、そのトポロジの境界ノードのＢＡＰアドレスは、上位レイヤに渡されなければならないパケットを識別するためにのみ使用されると仮定している。

【0451】

両方の例が機能可能であるが、例１はＲＡＮ３の仮定（特に１Ａ）とより一致すると考えられる。さらに、例１は、境界ノードがＩＡＢ－ドナーＤＵやアクセスＩＡＢノードのように、最初のトポロジのエンドポイントとして考えられるため、ＲＥＬ－１６ルーティングメカニズムの観点から非常に単純であると言える。また、例１は、中間ＩＡＢノードがローカルリルーティングを実行する場合、「誤ルーティング」のリスクが低くなる。この意味で、ＲＡＮ２はさらなる議論のために例１に合意すべきである。

【0452】

提案１：ＲＡＮ２は、最初のトポロジにおいて、境界ノードのＢＡＰアドレスがＢＡＰデータＰＤＵヘッダ（すなわち、宛先フィールド）に追加されることに合意すべきである。

【0453】

Ｏｐｅｎ Ｉｓｓｕｅ２：トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）とトポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）とを判別する方法

【0454】

提案１に合意する場合、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ（異なるＩＡＢドナーＣＵに属する２つのトポロジ間のルーティング））は、ＢＡＰデータＰＤＵヘッダの宛先フィールドに境界ＩＡＢノードのＢＡＰアドレスを持つ。一方、トポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ（１つのＩＡＢドナーＣＵに属するトポロジ内のルーティング））は、他のＢＡＰアドレス、すなわち、ＩＡＢドナーＤＵ又はアクセスＩＡＢノードのＢＡＰアドレスを持つ。つまり、宛先が境界ＩＡＢノードのＢＡＰアドレスと一致しない場合、ＢＡＰデータＰＤＵは受信部からコロケーションＢＡＰエンティティの送信部へ配送される。そのため、受信部では特別な処理は必要ない。ただし、以下のＯｐｅｎ Ｉｓｓｕｅ３がまだ存在することに留意する必要がある。

【0455】

提案２：ＲＡＮ２は、ＢＡＰエンティティの受信部において、トポロジ間ルーティング（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）を決定するために特別な処理を必要としないこと、つまりＲＥＬ－１６の動作が適用されることに合意すべきである。

【0456】

Ｏｐｅｎ Ｉｓｓｕｅ３：上位レイヤー（ダウンストリーム）へのデータ配信の可否の決定方法

【0457】

提案１に合意する場合、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）と境界ＩＡＢノード宛のトラフィックは、各ＢＡＰデータＰＤＵヘッダにおいて同じ宛先、すなわち、境界ＩＡＢノードのＢＡＰアドレスを持つことになる。そこで、境界ＩＡＢノードのＢＡＰエンティティの受信部は、各ＢＡＰデータＰＤＵヘッダのパスフィールド又は新しいフラグ（３つの「Ｒ」ビットのいずれかを使用）によりそれらを判別することができる。

【0458】

パスフィールドを使用する場合、境界ＩＡＢノードとＩＡＢドナーＤＵ／アクセスＩＡＢノード間に設定されるパスの数に応じて、ルーティングＩＤスペースが消費される。ＢＡＰヘッダの既存フィールドを再利用するため、データストリームに追加のオーバーヘッドはない。

【0459】

新しいフラグが使用される場合、それは「Ｒ」ビットを消費し、それによって、３つの予約ビットがあるだけである。ＢＡＰヘッダの「Ｒ」ビットを使用するため、追加のオーバーヘッドはない。また、このフラグは、ＢＡＰエンティティの送信部において、ＢＡＰヘッダを書き替えるか否かを決定する際にも有用であると想定される。

【0460】

上記の利点と欠点を考慮すると、ルーティングされるデータを判別するために、１つの「Ｒ」ビットを使用した新しいフラグを定義することが望ましい。言うまでもなく、この新しいフラグを「０」に設定すれば、ＲＥＬ－１６のＢＡＰヘッダ形式と完全に同じになるため、ＢＡＰエンティティの受信部はＲＥＬ－１６の動作に従ってデータを上位レイヤに送出することになる。

【0461】

提案３：ＣＵ間ルーティングのために、ＲＡＮ２はＢＡＰデータＰＤＵヘッダの１つの「Ｒ」ビットを使用して、ルーティングされるデータと上位レイヤに配信されるデータを判別するための新しいフラグを定義することに合意すべきである。

【0462】

Ｏｐｅｎ Ｉｓｓｕe４：データのＢＡＰヘッダを書き替えるべきかどうか（別のトポロジにルーティングされるか、自トポロジにルーティングされるか）を決定する方法

【0463】

提案２及び提案３が合意される場合、ＢＡＰエンティティの送信部は、まず各ＢＡＰデータＰＤＵヘッダの新しいフラグを確認することができる。新フラグが「０」であれば（すなわち、ＲＥＬ－１６ ＢＡＰデータＰＤＵを含むトポロジ間ルーティング（（ｎｏｎ－ｃｏｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）又は「自身のトポロジにルーティングされる」）、ＲＥＬ－１６ルーティング手順が実行される。（すなわち、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）又は「別のトポロジにルーティングされる」））の場合、ルーティング手順の前にＢＡＰヘッダの書き替え動作が実行される。これは「リルーティング」ではないため、ＢＡＰヘッダの書き替え動作が事前に行われるのは当然である。

【0464】

提案４：提案３のＢＡＰデータＰＤＵヘッダの新フラグを使用して、ＣＵ間ルーティングのために、ＢＡＰヘッダの書き替えを行うかどうかを決定することにＲＡＮ２は合意すること。

【0465】

提案５：ＣＵ間ルーティングについて、ＲＡＮ２は、ルーティング手順の前にＢＡＰヘッダの書き替えが実行されることに合意すること。

【0466】

提案３及び提案５が合意された場合、境界ＩＡＢノードで新しいフラグが使用される。そのため、ＢＡＰヘッダの書き替え動作後は無意味になるか、むしろ第２トポロジで不要なエラーを引き起こす可能性がある。そのため、境界ＩＡＢノードでフラグを「０」に書き替えることが安全である。これは、ＢＡＰヘッダの書き替え動作の中で行うのが簡単であると考えられる。

【0467】

提案６：ＣＵ間ルーティングについて、提案３の新フラグもＢＡＰヘッダの書き替え動作で書き替える、すなわち「０」にリセットするかどうかをＲＡＮ２で議論すべきである。

【0468】

その他考えられる問題
ルーティングテーブルの選択
提案５が合意される場合、ヘッダの書き替え設定に従ってヘッダが書き替えられたデータは、ルーティング手順に進むことになる。この場合、ＲＡＮ２が「RAN2の優先順位は、BAPルーティングID選択肢4に基づくBAPヘッダの書き替えによるトポロジ間ルーティングをサポートすること」に合意した通り、既にデータのヘッダは新しいルーティングＩＤに書き替えられているため、最初のトポロジで設定したルーティングテーブル、すなわちＢＨルーティング設定は有効ではない。そうでなければ、各ＩＡＢノードのＢＡＰアドレスはトポロジ内で一意であり、ＣＵ間ルーティングシナリオでも２つのトポロジ（すなわち２つのＣＵ）間では一意ではないため、混乱や「誤ルーティング」のリスクが生じる場合がある。そのため、ルーティングテーブルは２番目のトポロジによって構成されたものを使用する必要がある。

【0469】

提案７：ＣＵ間シナリオでは、ＲＡＮ２は、境界ノードが最初のトポロジと２番目のトポロジにそれぞれルーティングするために使用される２つのルーティングテーブルで設定されることに合意すべきである。

【0470】

提案７が合意される場合、ルーティング手順の前に、各データのルーティングテーブル選択手順が必要となる場合がある。その仕組みは非常にシンプルに考えられており、あるデータについて、ヘッダが書き替えられた場合（又は新しいフラグが「１」に設定された場合）、２番目のルーティングテーブルが適用される。そうでなければ、最初のルーティングテーブル（すなわち、ＲＥＬ－１６と同じもの）が適用される。

【0471】

提案８：ＣＵ間シナリオでは、ＲＡＮ２は、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）に対して、第２のトポロジのルーティングテーブルを選択する手順が必要であるかどうかを議論すべきである。

【0472】

ＢＨ ＲＬＣチャネルマッピングテーブル選択
ルーティング手順でネクストホップＢＡＰアドレスが決定されると、マッピングテーブル（＝ＢＨ ＲＬＣチャネルマッピング設定）に用意されている、決定した流入ＢＨリンク、流入ＢＨ ＲＬＣチャネル、流出ＢＨリンクに基づいて、流出ＢＨ ＲＬＣチャネルへのマッピングが行われる。ＴＳ３８．３４０の現在の実行ＣＲでは、以下の注釈が収録されている。

【0473】

注：境界ＩＡＢノードでのベアラマッピングをどのように収録するかについては更なる検討が必要である（現在の仕様が既にＣＵ間ルーティングのための境界ＩＡＢノードでのベアラマッピングをサポートしているかどうかについても更なる必要が検討である）。

【0474】

ＣＵ間シナリオの場合、流入ＢＨリンクとＲＬＣチャネルは第１トポロジに属し、流出ＢＨリンクは第２トポロジに関連付けられる。ＢＡＰアドレスとＲＬＣチャネルがＣＵによって（つまりトポロジごとに）管理されるため、２つのトポロジに接続するためには新しいマッピングテーブルが必要になる。具体的には、ＲＥＬ－１６のマッピングテーブルの構造を再利用することができるが、ＲＥＬ－１６とは異なるマッピングテーブルで構成される必要がある。そうでなければ、両方のトポロジで同じＢＡＰアドレス（すなわち、流入／流出リンクＩＤ）及び／又は同じＢＨ ＲＬＣチャネルＩＤが使用されている場合、「誤マッピング」のリスクがある。この場合、提案８と同様のマッピングテーブルの選択が必要となる場合がある。

【0475】

提案９：ＣＵ間シナリオでは、ＲＡＮ２は、境界ＩＡＢノードが（ＲＥＬ－１６マッピングテーブルに加えて）別のマッピングテーブルで構成され、そのマッピングテーブルはトポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）に適用されることに合意するものとする。

【0476】

提案１０：ＣＵ間シナリオにおいて、提案９の２つのトポロジを接続するための個別のマッピングテーブルを選択する手順が、トポロジ内ルーティング（ｃｏｎｃａｔｅｎａｔｅｄ ｔｒａｆｆｉｃ）に必要かどうかをＲＡＮ２で議論する。

【0477】

ＣＵ間リルート
ＢＡＰヘッダの書き替え動作の適用性

【0478】

ＲＡＮ２は、「ＩＣＵ間リルーティングのサポート、すなわちＩＡＢノードがターゲットＣＵのトポロジ上の代替ＢＡＰパスを介して元のドナーＣＵにデータをリルーティングする」ことに合意した。一般に、この合意はＣＵ間ルーティングと同様と見なすことができる。しかし、詳細には、ＩＡＢノードがターゲットドナーＣＵとのＲＲＣ接続を再確立し、ソースドナーＣＵとのＦ１接続がまだ保持されている場合（つまり、部分移行）、ＣＵ間リルーティングが適用される。ＲＡＮ３は、このシナリオに適用される可能性が高い以下の記載に合意した。

【0479】

部分的なドナー間移行では、特定のトポロジのトラフィックのために境界ノードが使用するＩＰアドレス、ＢＡＰアドレス、ＢＨ ＲＬＣ ＣＨ及びデフォルトマッピングは、そのトポロジのＣＵによって割り当てられ、それらはＲＲＣを介して設定される。

【0480】

上記の構成に加えて、（ターゲットドナーＣＵの）ＲＲＣは、境界ＩＡＢノードが使用する（単純な）ルーティングテーブル及び／又はヘッダの書き替え設定も提供する。なぜなら、元の第２のトポロジにリルートされたデータのＢＡＰヘッダの元のルーティングＩＤはもはや有効ではなく、すなわち境界ＩＡＢノードはターゲットドナーＣＵが管理する、新しい第２のトポロジで有効なルーティングＩＤを知る必要があるからである。この意味で、ＢＡＰヘッダの書き替え動作は、ＣＵ間リルーティングにも必要である。ＣＵ間ルーティングとは対照的に、ＢＡＰヘッダの書き替え動作は、ＢＡＰ ＲＵＮＮＩＮＧ ＣＲで既に収録されているように、ルーティング手順が失敗した時点で、「リルーティング」であるため、実行される。また、提案７及び提案８が合意されれば、ルーティングテーブルの選択は、ＣＵ間リルーティングにも適用される可能性がある。また、提案９及び提案１０が合意されれば、ＢＨ ＲＬＣチャネルマッピングテーブルの選択も適用される場合がある。

【0481】

その後、境界ＩＡＢノードは、新しい第２トポロジのＲＲＣによって設定されたＢＨ ＲＬＣチャネル、つまりターゲットドナーＣＵによって、ネクストホップＢＡＰアドレスにデータを送信することができる。

【0482】

提案１１：ＣＵ間リルーティングのために、ＲＡＮ２は、ターゲットドナーからのＲＲＣ信号を介して、境界ＩＡＢノードがＩＰアドレス、ＢＡＰアドレス、ＢＨ ＲＬＣチャネル及びデフォルトマッピング（ＲＡＮ３が合意したように）、及びデフォルトルーティングＩＤ（又は簡略化したヘッダの書き替えテーブル）などにより構成されることに合意すべきである。

【0483】

提案１２：ＣＵ間リルーティングについては、ルーティング（ＲＥＬ－１６ルーティング）が失敗した時点でＢＡＰヘッダの書き替え動作を行うことにＲＡＮ２が合意すべきである。

【0484】

提案１３：ＣＵ間リルーティングについて、ルーティングテーブル選択（提案８の導入された場合）、マッピングテーブル選択（提案１０の導入された場合）が適用できるかどうかをＲＡＮ２は議論すべきである。

【0485】

ＣＵ内／ＤＵ内リルーティング

【0486】

ＲＡＮ２は「ドナーＤＵ間リルーティングでは、『直前のルーティングＩＤから新たなルーティングＩＤ』ＢＡＰヘッダの書き替えをサポートする」ことに合意した。一方、ＲＡＮ３は、以下のように合意している。

【0487】

ＲＡＮ３は、あるトポロジのＢＨリンクから隣接トポロジのＢＨリンクにＢＡＰレイヤでルーティングされるトラフィックに対してのみ、ＵＬ及びＤＬトラフィックの両方について、境界ノードがＢＡＰヘッダの書き替えを実行することを望む。

【0488】

トポロジはドナーＣＵによって管理され、ドナーＣＵ内の２つのドナーＤＵはＣＵ内トポロジ還元とみなされるため、ドナーＤＵ間のリルーティングは依然として一つのトポロジ内で実行されていると考えられる。この場合、ＲＡＮ２の合意はＲＡＮ３の優先順位と衝突する可能性がある。しかし、ドナーＤＵ間リルーティングにより、アップストリームトラフィックの宛先が変更される、すなわち、ドナーＤＵのＢＡＰアドレスから他のドナーＤＵのＢＡＰアドレスに変更されるため、ＢＡＰヘッダの書き替え動作は当然に必要である。ダウンストリームトラフィックについては、宛先（アクセスＩＡＢノードのＢＡＰアドレス）が変更されないため、ＢＡＰヘッダの書き替え動作は必要ない場合がある。実際、下りのトラフィックは、ドナーＤＵ間リルーティングの対象にはならない（つまり、ローカルリルーティングに過ぎない）と想定される。したがって、ＲＡＮ２は、ＲＡＮ３の優先順位と異なっていても、その合意を確認すべきである。

【0489】

提案１４：ＣＵ内／ＤＵ間リルーティングについて、少なくともアップストリームトラフィックについては、「『直前のルーティングＩＤから新たなルーティングＩＤ』のＢＡＰヘッダの書き替えをサポートする」というＲＡＮ２のこれまでの合意を確認する。

【0490】

提案１４において、これは「リルーティング」であるため、提案１２のＣＵ間リルーティングと同様に、ＲＥＬ－１６ルーティングが失敗した時点で、ＢＡＰヘッダの書き替え動作を行う。これは、現在のＴＳ ３８．３４０のＲＵＮＮＩＮＧ ＣＲに既に収録されており、単純に確認することが可能である。

【0491】

提案１５：ＣＵ内／ドナー間ＤＵリルーティングについて、ＲＡＮ２は、ＴＳ３８．３４０の現在の実行ＣＲで収録されているように、ルーティング（すなわちＲＥＬ－１６ルーティング）が失敗した時点でＢＡＰヘッダの書き替え動作が行われることを確認すべきである。

【0492】

ＣＵ内／ドナーＤＵ内リルーティング（＝ローカルリルーティング）
ＢＡＰヘッダの書き替え動作の適用可否

【0493】

ＣＵ内／ドナーＤＵ内のリルーティングはローカルリルーティングと呼ばれ、以下のようにＲＥＬ－１６から既にサポートされている。

【0494】

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

【0495】

ＢＡＰアドレスが宛先フィールドと一致し、ネクストホップＢＡＰアドレスに対応する流出リンクが利用可能なエントリがＢＨルーティング設定に少なくとも一つ存在する場合、
ＢＨルーティング設定から、ＢＡＰアドレスが宛先フィールドと同じで、ネクストホップＢＡＰアドレスに対応する流出リンクが利用できるエントリを選択する。
上記で選択したエントリのネクストホップＢＡＰアドレスに対応する流出リンクを選択する。

【0496】

上記現行の仕様によれば、ＩＡＢノードは、ローカルリルーティングの結果、宛先にはマッチするがデータのパスにはマッチしないルーティングＩＤを介してＢＡＰデータＰＤＵを送信することができる。

【0497】

一方、ＲＡＮ２＃１１２－Ｅでは、ＲＥＬ－１７のローカルリルーティングは、以下のようにトポロジ全体の目標を考慮すべきであると合意した。
ＲＡＮ２は、中央経路決定に対する利点を含むローカルリルーティングと、トポロジ全体の目標にどのように対処できるかを議論する。

【0498】

上記の合意を考えると、ＲＥＬ－１６のローカルリルートでは、代替パスの選択がＩＡＢノードの実装に任されており、ドナーの観点からは管理しにくい場合があるという問題がある。ＲＥＬ－１６ ＩＡＢトポロジでは、ＩＡＢノードがＢＨ ＲＬＦを検出した場合のみ、つまり特定の異常状態でのみローカルリルートが許可されるため、大きな問題にはならない。しかし、ＲＥＬ－１７では、他の条件（例えば、輻輳状態）でもローカルリルートが許可されるため、その限りではないが、上記の合意を満たす方法についてはまだ問題が残されている。トポロジ全体の目標を達成するためには、トポロジ全体を管理するドナーが最も適していることは、非常に理解しやすい。この意味で、ドナーはＲＥＬ－１６メカニズムと比較して、代替パス設定という点でローカルリルーティングの制御性をより高める必要がある。

【0499】

所見１：ＲＥＬ－１６のローカルリルーティングでは、どの代替パスを選択するかはＩＡＢノードの実装次第であり、ドナーが管理することはできない。

【0500】

所見２：ＩＡＢドナーは、ローカルリルーティングにより、トポロジ全体の目標に取り組むのに最も適したノードである。

【0501】

この問題を解決するために、ＢＡＰヘッダの書き替え動作が一つの解決策になると考えられる。ＲＡＮ２は以下に合意している。
ＩＡＢドナーが、ローカルリルーティング（少なくとも同じ宛先、同じルーティングＩＤの更なる検討が必要である）で使用できる（代替）流出リンクを設定すると仮定する。

【0502】

流出リンクはＮネクストホップＢＡＰアドレスに関連付けられ、ネクストホップＢＡＰアドレスはルーティングＩＤで決定される。したがって、ドナー側がＩＡＢノードに新たなルーティングＩＤを設定してローカルリルーティングを行うことは当然であり、これは他の（リ）ルーティングシナリオのヘッダの書き替え設定と非常に似ている。

【0503】

ＲＡＮ３は、ＢＡＰヘッダの書き込み動作をトポロジ間シナリオでのみ実行することを望んでいるが、ＲＡＮ２は、前述したように、トポロジ内シナリオ、すなわちドナー間ＤＵリルーティングでも実行することに既に合意している。

【0504】

そこで、ＢＡＰヘッダの書き替え動作が、ＣＵ内／ＤＵ内リルーティングにも適用され、それによって、ヘッダの書き替え設定が設定されている場合のみ実行されるかどうかを議論する価値があると思われる（選択肢）。

【0505】

提案１６：ＲＡＮ２は、ＢＡＰヘッダの書き替えがローカルリルーティング（すなわち、ＣＵ内／ＤＵ間リルーティング）にも適用され、ＩＡＢノードが古いルーティングＩＤと新しいルーティングＩＤの間のマッピングで構成される場合（すなわち、現在のＴＳ３８．３４０の実行ＣＲにおけるヘッダの書き替え設定に類似している場合）の選択肢について議論すべきである。

【0506】

ドナーによるローカルリルートコマンド
ＩＡＢドナーの制御性のもう一つの側面として、ＩＡＢドナーがローカルリルーティングを認識し、ＩＡＢノードでローカルリルーティングを開始／停止することで、ローカルリルーティングとトポロジ全体の目標が共存可能であることを考慮する必要がある。例えば、ＩＡＢドナーがトポロジ全体の目的を達成できないことに気付いた場合、ＩＡＢドナーはＩＡＢノードにローカルリルーティングを開始／停止するように指示することができる。

【0507】

ローカルリルーティングによるトポロジ全体の目的をどのように扱うかは、完全にＩＡＢドナーの実装次第だが、ＩＡＢドナーはＩＡＢノードのローカルな決定の情報と制御性を必要とする場合がある。

【0508】

提案１７：ＲＡＮ２は、ローカルリルーティングの開始／停止時にＩＡＢノードがＩＡＢドナーに通知する必要があるかどうかを議論すべきである。

【0509】

提案１８：ＲＡＮ２は、ＩＡＢドナーがＩＡＢノードに対して、ルート間の負荷分散のためなどにローカルリルーティングの開始／停止を指示できるかどうかを議論するべきである。

【0510】

機能強化のまとめ
上記の提案が合意される場合、全てのシナリオを統一したソリューションの例を図２７に示す。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】