JP7547656B2 - 通信制御方法 - Google Patents

Description

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

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

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、境界中継ノードが、流入リンクに関する設定情報を、ネットワークから受信することを有する。また、前記通信制御方法は、前記境界中継ノード、前記設定情報に基づいて、前記流入リンクが対応するトポロジを特定することを有する。また、前記通信制御方法は、前記境界中継ノードが、前記流入リンクが対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行うことを有する。

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、境界中継ノードが、トポロジとルーティングＩＤとの対応付けを示す設定情報をネットワークから受信することを有する。また、前記通信制御方法は、前記境界中継ノードが、ネットワークから受信した設定情報に基づいて、パケット送信先のトポロジに紐づいたルーティングＩＤを決定することを有する。また、前記通信制御方法は、前記境界中継ノードが、前記ルーティングＩＤをヘッダに含む前記パケットを送信することを有する。

第３の態様に係る境界中継ノードは、流入リンクに関する設定情報をネットワークから受信する受信部を有する。また、前記境界中継ノードは、前記設定情報に基づいて、前記流入リンクが対応するトポロジを特定する制御部を有する。ここで、前記制御部は、前記流入リンクが対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行う。

第４の態様に係るプロセッサは、境界中継ノードを制御するプロセッサである。前記プロセッサは、流入リンクに関する設定情報をネットワークから受信する処理を実行する。また、前記プロセッサは、前記設定情報に基づいて、前記流入リンクが対応するトポロジを特定する処理を実行する。また、前記プロセッサは、前記流入リンクが対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行う処理と、を実行する。

第５の態様に係る境界中継ノードは、トポロジとルーティングＩＤとの対応付けを示す設定情報をネットワークから受信する受信部を備える。また、前記境界中継ノードは、ネットワークから受信した設定情報に基づいて、パケット送信先のトポロジに紐づいたルーティングＩＤを決定する制御部を有する。また、前記境界中継ノードは、前記ルーティングＩＤをヘッダに含む前記パケットを送信する送信部を備える。

第６の態様に係るプロセッサは、境界中継ノードを制御するプロセッサである。前記プロセッサは、トポロジとルーティングＩＤとの対応付けを示す設定情報をネットワークから受信する処理を実行する。また、前記プロセッサは、ネットワークから受信した設定情報に基づいて、パケット送信先のトポロジに紐づいたルーティングＩＤを決定する処理を実行する。また、前記プロセッサは、前記ルーティングＩＤをヘッダに含む前記パケットを送信する処理を実行する。

図１は、一実施形態に係るセルラ通信システムの構成例を示す図である。 図２は、ＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を示す図である。 図３は、一実施形態に係るｇＮＢ（基地局）の構成例を示す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を示す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を示す図である。 図６は、ＩＡＢ－ＭＴのＲＲＣ接続及びＮＡＳ接続に関するプロトコルスタックの例を示す図である。 図７は、Ｆ１－Ｕプロトコルに関するプロトコルスタックの例を示す図である。 図８は、Ｆ１－Ｃプロトコルに関するプロトコルスタックの例を示す図である。 図９は、第１実施形態に係るノード間の構成例を表す図である。 図１０は、第１実施形態に係るオプションＤ１の動作例を表す図である。 図１１は、第１実施形態に係るオプションＤ２の動作例を表す図である。 図１２は、第１実施形態に係るオプションＵ１の動作例を表す図である。 図１３は、第１実施形態に係るオプションＵ２の動作例を表す図である。 図１４は、第１実施形態に係るオプションＣ２の動作例を表す図である。 図１５は、第２実施形態に係る境界ＩＡＢノードの例を表す図である。 図１６は、第２実施形態に係る動作例を表す図である。 図１７は、第３実施形態に係る境界ＩＡＢノードの構成例を表す図である。 図１８は、第３実施形態に係る第１動作例を表す図である。 図１９は、第３実施形態に係る第２動作例を表す図である。 図２０は、第４実施形態に係る動作例を表す図である。 図２１は、第５実施形態に係る境界ＩＡＢノードの例を表す図である。 図２２は、第５実施形態に係る動作例を表す図である。 図２３は、ルーティング及びリルーティングに関するシナリオを表す図である。 図２４は、ＣＵ間シナリオで適用可能なルーティングテーブルを表す図である。 図２５は、全シナリオのルーティング/リルート機能強化の概要を表す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最初に、第１実施形態に係るルーティング処理について説明する。
（ルーティング処理）
ＩＡＢノード３００のＢＡＰレイヤでは、ルーティング処理が行われる。具体的には、例えば、以下のような処理が行われる。

すなわち、ＢＡＰレイヤは、ＢＡＰヘッダに含まれるＢＡＰルーティングＩＤに基づいて、ＢＡＰパケットをルーティングする。ＢＡＰヘッダは、パケットが上位レイヤから到達したときに追加され、宛先ノードに到達したときに除去される。ＢＡＰルーティングＩＤの設定又はルーティングテーブルは、ドナーノード２００のＣＵによって設定される。ＢＡＰルーティングＩＤは、ＢＡＰアドレス（又はＤｅｓｔｉｎａｔｉｏｎ、或いは宛先ＢＡＰアドレス）とＢＡＰパスＩＤ（又は経路識別子）から構成される。ＢＡＰアドレスは、宛先ノードを示す。また、ＢＡＰパスＩＤは、宛先までにパケットが辿るルーティングパスを示す。

パケットの経路上の各ＩＡＢノード３００では、パケットが目的地に到達したか否か、すなわち、ＩＡＢノード３００のＢＡＰアドレスと一致しているかどうかを判断する。具体的には、ＢＡＰヘッダに含まれるＢＡＰルーティングＩＤのＢＡＰアドレスに基づいて行われる。ＩＡＢノード３００は、パケットが目的地（宛先ＢＡＰアドレス）に到達していない（すなわち、ＢＡＰヘッダに含まれるＢＡＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ）が自ＩＡＢノードのＢＡＰアドレスと一致していない）場合、ＢＡＰヘッダに含まれるＢＡＰルーティングＩＤと、ルーティング設定（ｒｏｕｔｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）とに基づいて、次ホップのＢＡＰアドレス（又はバックホールリンク、或いは流出リンク）を決定する。

このように、パケットの送信先を制御する処理のことを、例えば、ルーティング処理と称する場合がある。

なお、以下では、ＢＡＰルーティングＩＤをルーティングＩＤ、ＢＡＰパスＩＤをパスＩＤとそれぞれ称する場合がある。また、ＩＡＢドナーＤＵをドナーノード２００のＤＵ、ＩＡＢドナーＣＵをドナーノード２００のＣＵとそれぞれと称する場合がある。更に、ルーティングＩＤに含まれるＢＡＰパスＩＤをパスＩＤ、ルーティングＩＤに含まれるＢＡＰアドレスをＤｅｓｔｉｎａｔｉｏｎとそれぞれ称する場合がある。

（第１実施形態に係る通信制御方法）
ドナーノード２００が、トポロジ内の全ＩＡＢノードに対して、ルーティング設定（ｒｏｕｔｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を変更するには、トポロジの規模が大きければ大きいほど、時間がかかることが予想される。

あるルーティングＩＤが付与されたパケットが、アクセスＩＡＢノード（ＵＥ１００から受信したパケットを最初に処理するノード及びＵＥ１００へ送信するパケットを最後に処理するノード）又はドナーノード２００のＤＵから送信された後、中間のＩＡＢノード３００においてルーティング設定が変更された場合、当該パケットはどのように処理されるかが問題となる場合がある。

例えば、中間のＩＡＢノード３００では、ルーティング設定が変更されると、本来、到達すべきＤｅｓｔｉｎａｔｉｏｎ（当該パケットのＢＡＰヘッダに含まれるルーティングＩＤのＤｅｓｔｉｎａｔｉｏｎ）とは異なるＤｅｓｔｉｎａｔｉｏｎ（つまり、異なるルート）へ、当該パケットをルーティングする場合がある。このようなルーティングミスはパケットロスが生じる原因ともなる。

そこで、第１実施形態では、ドナーノード２００は、ルーティング設定変更開始メッセージと、ルーティング設定変更完了メッセージとを、アクセスＩＡＢノード３００－Ａへ送信する。アクセスＩＡＢノード３００－Ａでは、２つのメッセージに基づいて、ドナーノード２００に到達済のパケットを推測し、推測結果に基づいて、過去に送信したパケットを再送信する。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、トポロジ内の中継ノード（例えば、ＩＡＢノード３００）に対して、ルーティング設定に関するメッセージを送信する。第２に、中継ノードが、メッセージを受信したことに応じて第１の処理を行う。

ここで、メッセージを送信する処理には、ドナーノードが、トポロジ内の中継ノードに対してルーティング設定の変更を開始したことに応じて、ルーティング設定変更開始メッセージをアクセス中継ノード（例えば、アクセスＩＡＢノード３００－Ａ）へ送信する処理を含む。また、メッセージを送信する処理には、ドナーノードが、トポロジ内の中継ノードに対してルーティング設定の変更を完了したことに応じて、ルーティング設定変更完了メッセージをアクセス中継ノードへ送信する処理を含む。そして、第１の処理には、アクセス中継ノードが、ルーティング設定変更開始メッセージとルーティング設定変更完了メッセージとに基づいて、アップストリーム方向において一定期間過去に送信したパケットを再送信する処理を含む。

図９は、第１実施形態に係るノード間の構成例を表す図である。図９に示すように、ドナーノード２００が、ルーティング設定変更開始メッセージと、ルーティング設定変更完了メッセージとを、アクセスＩＡＢノード３００－Ａへ送信している。

これにより、アクセスＩＡＢノード３００－Ａでは、例えば、ルーティング設定変更開始のタイミングとルーティング設定変更完了のタイミングとを把握することができ、ドナーノード２００に到達済のパケット（又はドナーノード２００に到達していないパケット）を精度良く推測することができる。従って、アクセスＩＡＢノード３００－Ａでは、パケットロスが生じたと予想されるパケットを再送信することで、パケットロスを補償する（又は抑制させる）ことが可能となる。

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

第１動作例は、ダウンストリーム方向とアップストリーム方向とを別々に説明する。また、第１動作例では、ダウンストリーム方向には２つのオプション（オプションＤ１とオプションＤ２）がある。また、第１動作例では、アップストリーム方向についても２つのオプション（オプションＵ１とオプションＵ２）がある。

（ダウンストリーム方向のオプションＤ１）
図１０は、第１実施形態に係るダウンストリーム方向のオプションＤ１の動作例を表す図である。

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

ステップＳ１１において、ドナーノード２００は、ダウンストリーム方向において送信済のパケットをメモリなどに保持する。

ステップＳ１２において、ドナーノード２００は、トポロジ内の（全ての）ＩＡＢノード３００のルーティング設定を変更した後、変更前のルーティング設定に従ったヘッダを有するパケット（すなわち、送信済パケット）がアクセスＩＡＢノードに到達済かを推測する。例えば、ドナーノード２００は、過去の送信履歴から単位時間あたり、アクセスＩＡＢノードに到達するパケット数を計算し、ルーティング設定変更後から現在時刻までの時間に基づいて、アクセスＩＡＢノード３００－Ａに到達済パケットの数を推測する。なお、ドナーノード２００のＣＵは、アクセスＩＡＢノード３００－ＡのＩＡＢ－ＤＵに対して、Ｆ１ＡＰプロトコルによるメッセージを利用して、ルーティング設定の変更を行ってもよい。

ステップＳ１３において、ドナーノード２００は、一定期間過去に送信したパケットについて、変更後のルーティング設定に従ったヘッダを付与した上で、当該パケットを再送信（ブラインド再送信）する。例えば、ドナーノード２００は、推測した到達済パケットの数と、ルーティング設定変更後から現在時刻までに送信した送信済パケット数とに基づいて、どれくらい過去に遡ればよいかを計算することで、一定期間過去に送信したパケットを特定してもよい。

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

（ダウンストリーム方向のオプションＤ２）
図１１は、第１実施形態に係るダウンストリーム方向のオプションＤ２の動作例を表す図である。

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

ステップＳ２１において、ドナーノード２００は、ダウンストリーム方向において送信済パケットをメモリなどに保持する。

ステップＳ２２において、ドナーノード２００は、トポロジ内の（全ての）ＩＡＢノード３００に対してルーティング設定を変更した後、影響を受けそうなＵＥ１００を特定する。例えば、ドナーノード２００は、当該ドナーノード２００とＲＲＣコネクティッド状態のＵＥ１００を、影響を受けそうなＵＥ１００として特定してもよい。

ステップＳ２３において、ドナーノード２００は、当該ＵＥ１００に対して、ＰＤＣＰステータスレポート（ＰＤＣＰ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）を送信させるよう指示する。例えば、ドナーノード２００のＣＵが、ＲＲＣメッセージを利用して、当該ＵＥ１００に対して当該指示を送信する。

ステップＳ２４において、ドナーノード２００は、ＵＥ１００から、ＰＤＣＰステータスレポートを受信し、当該レポートに含まれるＦＭＣ（Ｆｉｒｓｔ Ｍｉｓｓｉｎｇ Ｃｏｕｎｔ）に基づいて、ＵＥ１００に未到達のパケットを特定する。そして、ドナーノード２００は、当該パケットに対して、変更後のルーティング設定に従ったヘッダを付与した上で、再送信を行う。なお、ドナーノード２００のＣＵは、ＲＲＣメッセージを利用して、ＵＥ１００からＰＤＣＰステータスレポートを受信してもよい。

そして、ドナーノード２００は、一連の処理を終了する。

（アップストリーム方向のオプションＵ１）
図１２は、第１実施形態に係るアップストリーム方向のオプションＵ１の動作例を表す図である。

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

ステップＳ３１において、アクセスＩＡＢノード３００－Ａは、アップストリーム方向における送信済のパケットをメモリなどに保持する。

ステップＳ３２において、ドナーノード２００は、トポロジ内における、当該アクセスＩＡＢノード３００－Ａに関連するＩＡＢノード３００に対してルーティング設定の変更を開始した時、ルーティング設定変更開始メッセージを、当該アクセスＩＡＢノード３００－Ａへ送信する。ルーティング設定変更開始メッセージは、ルーティング設定の変更が開始されたことを示すメッセージである。例えば、ドナーノード２００のＣＵが、アクセスＩＡＢノード３００－ＡのＩＡＢ－ＤＵへ、Ｆ１ＡＰメッセージとして当該メッセージを送信してもよい。又は、例えば、ドナーノード２００のＣＵが、アクセスＩＡＢノード３００－ＡのＩＡＢ－ＭＴへ、ＲＲＣメッセージとして、当該メッセージを送信してもよい。

ステップＳ３３において、ドナーノード２００は、トポロジ内における、当該アクセスＩＡＢノード３００－Ａに関連するＩＡＢノード３００に対してルーティング設定の変更を完了した時、ルーティング設定変更完了メッセージを、当該アクセスＩＡＢノード３００－Ａへ送信する。ルーティング設定変更完了メッセージは、ルーティング設定の変更が完了されたことを示すメッセージである。例えば、当該メッセージは、Ｆ１ＡＰメッセージ又はＲＲＣメッセージとして送信されてもよい。なお、ルーティング設定変更完了メッセージには、ルーティング設定の変更に要した時間が含まれてもよい。当該時間は、ルーティング設定開始時刻からルーティング設定終了時刻までの時間で表されてもよい。

ステップＳ３４において、アクセスＩＡＢノード３００－Ａは、ルーティング設定変更開始メッセージとルーティング設定変更完了メッセージとに基づいて、送信済パケットのうち、ドナーノード２００へ到達した到達済パケットを推測する。例えば、アクセスＩＡＢノード３００－Ａは、以下のようにして到達済パケットを推測してもよい。すなわち、アクセスＩＡＢノード３００－Ａは、ルーティング設定変更開始メッセージを受信した受信時刻とルーティング設定変更完了メッセージを受信した受信時刻とからルーティング設定の変更に要した変更時間を計算する。また、アクセスＩＡＢノード３００－Ａは、過去の履歴から、単位時間あたりにドナーノード２００へ到達したパケット数を計算する。そして、アクセスＩＡＢノード３００－Ａは、当該変更時間と当該パケット数とに基づいて、到達済パケットを推測する。

ステップＳ３５において、アクセスＩＡＢノード３００－Ａは、一定期間過去に送信したパケットに対して、変更後のルーティング設定に従ったヘッダを付与した上で、再送信（又はブラインド再送信）する。例えば、アクセスＩＡＢノード３００－Ａは、メモリに保持した送信済のパケットから、推測した到達済パケットを除いたパケットを、一定期間過去に送信したパケットとして、再送信してもよい。或いは、例えば、アクセスＩＡＢノード３００－Ａは、ルーティング設定の変更に要した変更時間を、一定期間として、その時間分の送信済パケットを、一定期間過去に送信したパケットとして再送信してもよい。アクセスＩＡＢノード３００－Ａでは、ルーティング設定変更開始メッセージとルーティング設定変更完了メッセージとに基づいて、アップストリーム方向において一定期間過去に送信したパケットを再送信することになる。

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

（アップストリーム方向のオプションＵ２）
図１３は、第１実施形態に係るアップストリーム方向のオプションＵ２の動作例を表す図である。

図１３に示すように、ステップＳ４０において、ＵＥ１００は、処理を開始する。

ステップＳ４１において、ＵＥ１００は、送信済のＰＤＣＰ Ｄａｔａ ＳＤＵ（Service Data Unit）をメモリなどに保持する。この際、ＵＥ１００は、通常よりも長いＤｉｓｃａｒｄ Ｔｉｍｅｒ値を設定しておくようにする。ＵＥ１００からドナーノード２００へのマルチホップ転送の到達遅延を考慮して、タイマ満了によるＰＤＣＰ ＳＤＵが破棄されるのを防止するためである。

ステップＳ４２において、ドナーノード２００は、トポロジ内の（全ての）ＩＡＢノード３００に対してルーティング設定を変更し、その後、影響を受けそうなＵＥ１００を特定する。ドナーノード２００は、当該ドナーノード２００に対してＲＲＣコネクティッド状態となっているＵＥ１００を、影響を受けそうなＵＥ１００として特定してもよい。

ステップＳ４３において、ドナーノード２００は、当該ＵＥ１００に対して、ＰＤＣＰステータスレポートを送信する。なお、ＵＥ１００は、当該ＰＤＣＰステータスレポートに従って、到達済のパケット（ＰＤＣＰ Ｄａｔａ ＳＤＵ）を破棄する。

ステップＳ４４において、ドナーノード２００は、ＰＤＣＰデータ回復（ＰＤＣＰ Ｄａｔａ Ｒｅｃｏｖｅｒｙ）をトリガする。ＵＥ１００は、保持しているＰＤＣＰ Ｄａｔａ ＳＤＵをアクセスＩＡＢノード３００－Ａへ再送する。アクセスＩＡＢノード３００－Ａでは、当該パケットに対して、変更後のルーティング設定に従ったヘッダを付与して、次ホップノードへ送信する。

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

（第１実施形態に係る第２動作例）
上述した第１実施形態に係る第１動作例では、一定期間過去の送信済のパケットを再送信するなどにより、パケットロスを補償することについて説明した。

しかし、ルーティングミスそのものに対する対処方法については、第１動作例では議論されていない。そのため、ルーティングミスによる無駄なパケットがトポロジ内で転送され、無駄なリソースが消費される場合がある。

そこで、第２動作例では、各ＩＡＢノード３００では、ルーティング設定変更前からルーティング設定変更完了までの間、ルーティング処理が停止され、ルーティング処理再開後、それまでメモリに保持したパケットのヘッダを書き替えて送信する例について説明する。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、トポロジ内の中継ノード（例えば、ＩＡＢノード３００）に対して、ルーティング停止指示メッセージを送信する。第２に、中継ノードが、ルーティング停止指示メッセージに従って、ルーティング処理を停止するとともに、受信したパケットをメモリに保持する。第３に、ドナーノードが、中継ノードに対して、ルーティング設定を変更し、ルーティング設定変更前のルーティングＩＤとルーティング設定変更後のルーティングＩＤとのマッピング情報を送信する。第４に、中継ノードが、ルーティング処理を再開し、マッピング情報に従って、メモリに保持したパケットのヘッダを書き替えて送信する。

このように、各ＩＡＢノード３００では、ルーティング設定変更前後で、ルーティング処理が停止され、パケットをメモリに保持している。これにより、ルーティングミスによるパケットがトポロジ内で転送されることを防止している。そして、各ＩＡＢノード３００では、ルーティング処理再開後、それまでメモリに保持したパケットのヘッダに含まれるルーティングＩＤについて、ルーティング設定変更前後のマッピング情報を用いて書き替えている。これにより、ルーティング設定変更後の正しいルーティングＩＤに書き替えられたパケットがトポロジ内に転送されることになる。従って、ルーティングミスを防止させることが可能となる。

第１実施形態に係る第２動作例は、２つのオプション（オプションＣ１とオプションＣ２）がある。最初にオプションＣ１について説明する。２つのオプションともに、パケットの送信について、ダウンストリーム方向とアップストリーム方向の双方において実施可能である。

（オプションＣ１）
ドナーノード２００は、ルーティング設定変更時において、各ルーティングＩＤのパスＩＤを変更し、Ｄｅｓｔｉｎａｔｉｏｎをルーティング設定変更前後で変更しないようにする。

次に、ＩＡＢノード３００は、ルーティング設定変更前のルーティング設定に従ったパケットを受信する。

次に、ＩＡＢノード３００は、変更後のルーティング設定において、当該パケットのルーティングＩＤに含まれるパスＩＤが変更後のルーティング設定に存在しない場合、Ｄｅｓｔｉｎａｔｉｏｎへのローカルリルーティング（ｌｏｃａｌ ｒｅ－ｒｏｕｔｉｎｇ）を行う。変更後のルーティング設定には、当該パケットに含まれるパスＩＤが存在しなくても、当該パケットに含まれるＤｅｓｔｉｎａｔｉｏｎがエントリとして存在する。そのため、ＩＡＢノード３００は、正しいＤｅｓｔｉｎａｔｉｏｎへのローカルリルーティングを実行できる。ローカルリルーティングとは、ルーティング設定を考慮しないで代替パス（ａｌｔｅｒｎａｔｉｖｅ ｐａｔｈ）へパケットをルーティングすることである。

ただし、Ｄｅｓｔｉｎａｔｉｏｎは１０２４個（１０ビット）設定可能であるが、トポロジ内のＩＡＢノード３００とドナーノード２００のＤＵの個数が１０２４に近づくと、同一のＤｅｓｔｉｎａｔｉｏｎが重複使用される場合がある。この場合、オプションＣ１ではルーティングミスの可能性が存在する。

（オプションＣ２）
図１４は、第１実施形態に係るオプションＣ２の動作例を表す図である。

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

ステップＳ５１において、ドナーノード２００は、トポロジ内のＩＡＢノード３００に対してルーティング設定変更を行う前に、トポロジ内の（全部又は一部の）ＩＡＢノード３００に対して、ルーティング処理停止を指示するルーティング停止指示メッセージを送信する。ルーティング停止指示メッセージは、Ｆ１ＡＰメッセージ又はＲＲＣメッセージとして送信されてもよい。

ステップＳ５２において、ＩＡＢノード３００は、ルーティング停止指示メッセージの受信に応じて、ルーティング処理を停止するとともに、受信したパケット（ＢＡＰ Ｄａｔａ ＰＤＵ）をメモリなどに保持する。

ステップＳ５３において、ドナーノード２００は、トポロジ内の（全部又は一部の）ＩＡＢノード３００に対して、ルーティング設定を変更する。例えば、ドナーノード２００のＣＵが、ＩＡＢノード３００のＩＡＢ－ＤＵに対して、Ｆ１ＡＰメッセージを利用して変更後のルーティング設定を送信することで、ルーティング設定の変更が行われてもよい。

ステップＳ５４において、ドナーノード２００は、ルーティング設定変更前のルーティングＩＤと、ルーティング設定変更後のルーティングＩＤと対応関係を表すマッピング情報を、トポロジ内の（全部又は一部の）ＩＡＢノード３００へ送信する。マッピング情報は、Ｆ１ＡＰメッセージ又はＲＲＣメッセージにより送信されてもよい。なお、ＩＡＢノード３００では、このマッピング情報の受信がルーティング処理再開のトリガとなってもよい。或いは、ドナーノード２００は、マッピング情報を送信後、トポロジ内の（全部又は一部の）ＩＡＢノード３００に対して、ルーティング再開指示メッセージを送信してもよい。ルーティング再開指示メッセージも、Ｆ１ＡＰメッセージ又はＲＲＣメッセージとして送信されてもよい。ＩＡＢノード３００では、ルーティング再開指示メッセージの受信に応じて、ルーティング処理を再開する。

ステップＳ５５において、ＩＡＢノード３００は、ルーティング処理を再開し、マッピング情報に従って、メモリに保持したパケット（ＢＡＰ Ｄａｔａ ＰＤＵ）の（ＢＡＰ）ヘッダを書き換える。具体的には、ＩＡＢノード３００のＢＡＰレイヤ（又はＢＡＰエンティティ。以下では、ＢＡＰレイヤとＢＡＰエンティティとを区別しないで用いる場合がある。）は、マッピング情報に従って、ヘッダに含まれるルーティングＩＤ（ルーティング設定変更前のルーティングＩＤ）を、ルーティング設定変更後のルーティングＩＤへ書き換える。なお、ＩＡＢノード３００は、マッピング情報受信後（又はルーティング処理再開後）、新たに受信したパケットについては、マッピング情報によるヘッダ書き替えを行わない。ＩＡＢノード３００は、メモリに保持した全パケットについて、マッピング情報によるヘッダ書き替えが終了すると、マッピング情報を破棄してもよい。

ステップＳ５６において、ＩＡＢノード３００は、当該パケットに対して、変更後のルーティング設定によりルーティング処理を行い、次ホップノードへ送信する。

そして、ステップＳ５７において、一連の処理が終了する。
[第２実施形態]
次に、第２実施形態について説明する。

第２実施形態では、ダウンストリーム方向におけるパケットのヘッダ書き替えについて説明する。

ＩＡＢノード３００には、複数のトポロジに属するＩＡＢノードがある。このようなＩＡＢノードを、境界ＩＡＢノード（ｂｏｕｎｄａｒｙ ＩＡＢ－ｎｏｄｅ）と呼ぶ。

図１５は、第２実施形態に係る境界ＩＡＢノード３００－Ｂの例を表す図である。図１５に示す例では、境界ＩＡＢノード３００－Ｂは、ドナーノード２００のＣＵ＃１（２００－Ｃ１）によって構成されたトポロジと、別のドナーノードのＣＵ＃２（２００－Ｃ２）によって構成されたトポロジの２つのトポロジに属している。

なお、第２実施形態では、ＣＵ＃１（２００－Ｃ１）によって構成されたトポロジをメイントポロジ、ＣＵ＃２（２００－Ｃ２）によって構成されたトポロジをサブトポロジとそれぞれ称する場合がある。

境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティング（Ｉｎｔｅｒ－ＣＵ ｒｏｕｔｉｎｇ）において、ヘッダ書き替え処理が行われる。ＣＵ間ルーティングとは、例えば、第１ＣＵが管理する第１トポロジから第２ＣＵが管理する第２トポロジへパケットをルーティングすることである。

アップストリーム方向のＣＵ間ルーティングに関しては、境界ＩＡＢノード３００－Ｂでは、メイントポロジから流入したパケットを、サブトポロジへ流出させる処理を行う。具体的には、境界ＩＡＢノード３００－ＢのＢＡＰレイヤが、ヘッダ書き替えテーブル（Ｈｅａｄｅｒ Ｒｅｗｒｉｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を利用して、当該パケットに対してヘッダを書き替え（例えば、ルーティングＩＤを書き替えることで、ＤｅｓｔｉｎａｔｉｏｎをＣＵ＃１（２００－Ｃ１）からＣＵ＃２（２００－Ｃ２）へ書き替え）を行って、パケットを転送させている。アップストリーム方向のヘッダ書き替えテーブルは、メイントポロジ側のＣＵ＃１（２００－Ｃ）が管理している。

一方、ダウンストリーム方向のＣＵ間ルーティングに関しては、境界ＩＡＢノード３００－Ｂでは、サブトポロジから流入したパケットを、メイントポロジに流出させる処理を行う。具体的には、境界ＩＡＢノード３００－ＢのＢＡＰレイヤが、ヘッダ書き替えテーブルを利用して、当該パケットに対してヘッダを書き替え（例えば、ルーティングＩＤを書き替えることで、ＤｅｓｔｉｎａｔｉｏｎをサブトポロジのアクセスＩＡＢノードから、メイントポロジのアクセスＩＡＢノードへ書き替え）を行って、パケットを転送させている。ダウンストリーム方向のヘッダ書き替えテーブルは、サブトポロジ側のＣＵ＃２（２００－Ｃ２）が管理している。

ここで、境界ＩＡＢノード３００－Ｂでは、ルーティング設定と、アップストリーム方向のヘッダ書き替えテーブルとについて、同一のドナーノード２００（又はＣＵ＃１（２００－Ｃ））により管理されている。そのため、境界ＩＡＢノード３００－Ｂでは、アップストリーム方向のヘッダ書き替えについては、ヘッダ書き替えテーブルを参照して、エントリが存在するか否かにより、ヘッダ書き替えを行うか否かを判断できる。

一方、境界ＩＡＢノード３００－Ｂにおいて、ダウンストリーム方向のヘッダ書き替えテーブルは、上述したように、サブトポロジ（ＣＵ＃２（２００－Ｃ２））により管理されている。また、サブトポロジのルーティングＩＤはＣＵ＃２（２００－Ｃ２）により管理され、メイントポロジのルーティングＩＤはＣＵ＃１（２００－Ｃ１）により管理されている。そのため、メイントポロジにあるルーティングＩＤと、サブトポロジにあるルーティングＩＤとが一致する場合がある。境界ＩＡＢノード３００－Ｂでは、ダウンストリーム方向におけるヘッダ書き替えの際に、メイントポロジ側のルーティングＩＤと、サブトポロジ側のルーティングＩＤとを区別することなく、ヘッダを書き替える。そのため、境界ＩＡＢノード３００－Ｂでは、ダウンストリーム方向へのＣＵ間ルーティングの際に、パケットを、誤ってサブトポロジ側へ流出させてしまう場合がある。

そこで、３ＧＰＰでは、ダウンストリーム方向のヘッダ書き替え処理については、境界ＩＡＢノード３００－ＢのＳＣＧ（Secondary Cell Group）側から流入したパケットをヘッダ書き替え対象とすることについて議論している。

しかし、ＳＣＧ側は、必ずしも、サブトポロジに属しているとは限らない。ＭＣＧ（Master Cell Group）側がサブトポロジとなっている場合、サブトポロジから流入したダウンストリーム方向のパケットは、ヘッダ書き替え対象とはならないことになる。逆に、メイントポロジ側のＳＣＧから流入したパケットがヘッダ書き替え対象となってしまう。

そこで、第２実施形態では、ドナーノード２００が、境界ＩＡＢノード３００－Ｂに対して、ダウンストリーム方向においてヘッダ書き替えの対象となるリンク（又は境界ＩＡＢノード３００－Ｂに対する親ノード）を指定する例について説明する。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、ダウンストリームリンクを指定した指定情報を、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）へ送信する。第２に、境界中継ノードが、指定情報に従って、ダウンストリームリンクから流入したパケットに対してヘッダ書替え処理を行う。

これにより、例えば、境界ＩＡＢノード３００－Ｂでは、ヘッダ書き替え対象のパケットを特定することができるため、ダウンストリーム方向のヘッダ書き替え処理を適切に行うことが可能となる。

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

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

ステップＳ６１において、ドナーノード２００は、境界ＩＡＢノード３００－Ｂに対して、ヘッダ書き替え対象となるダウンストリームリンク(又は流入リンク（ｉｎｇｒｅｓｓ ｌｉｎｋ）)を指定した指定情報を送信する。指定情報には、ヘッダ書き替えが必要な（又はヘッダ書き替えの対象となる）流入リンクが含まれる。具体的には、指定情報には、ヘッダ書き替えが必要なＭＣＧ又はＳＣＧが含まれてもよい。また、指定情報には、ヘッダ書き替えが必要な親ノードのＢＡＰアドレス又は親ノードのセルＩＤが含まれてもよい。更に、指定情報には、トポロジに対応するリンクが含まれてもよい。例えば、メイントポロジはＭＣＧでサブトポロジはＳＣＧ、又は、メイントポロジはＳＣＧでサブトポロジはＭＣＧであることを示す情報が指定情報に含まれてもよい。この場合、サブトポロジとして指定された側が、ヘッダ書き替えが必要なリンクとなる。なお、指定情報は、Ｆ１ＡＰメッセージ又はＲＲＣメッセージに含まれて送信されてもよい。

ステップＳ６２において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、当該指定情報に従って、指定情報として指定されたダウンストリームリンクから流入したパケットを、書き替え対象のパケットとして特定し、当該パケットに対してヘッダ書き替え処理を行う。

そして、ステップＳ６３において、一連の処理が終了する。
[第３実施形態]
次に第３実施形態について説明する。

第３実施形態では、様々な種類のヘッダ書き替えテーブルを分類する例について説明する。

３ＧＰＰでは、ＣＵ間ルーティングを行う際に、境界ＩＡＢノード３００－Ｂに設定されるヘッダ書き替えテーブルを、ＵＬ方向(又はアップストリーム方向)とＤＬ方向（又はダウンストリーム方向）とでどのように異ならせるかについて議論されている。

ヘッダ書き替えテーブルについては、ＵＬ方向とＤＬ方向とで異なるテーブルが用いられる場合、ＢＡＰレイヤでは、パケット毎の流入方向を特定する処理が行われる場合がある。すなわち、ＢＡＰレイヤでは、パケット毎に、流入方向を特定後、ＵＬ用のヘッダ書き替えテーブル及びＤＬ用のヘッダ書き替えテーブルのいずれかのテーブルを用いて、ヘッダ書き替え処理を行うことになる。

しかし、境界ＩＡＢノード３００－Ｂにおいて、このような処理を行うことは、ＣＵ間ルーティングの処理を増大させてしまう。また、ＢＡＰレイヤでは、パケットの流入方向を特定するために、他のレイヤとの間で情報交換を行うことになり、他のレイヤとの依存性を高めてしまう。

そこで、第３実施形態では、ＣＵ間ルーティングで使用されるヘッダ書き替えテーブルを、境界ＩＡＢノード３００－ＢのＩＡＢ－ＭＴ側で使用するテーブルと、ＩＡＢ－ＤＵ側で使用するテーブルとで分類するようにする。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）に対して、第１分類情報を有する第１ヘッダ書き替えテーブルと、第２分類情報を有する第２ヘッダ書き替えテーブルとを設定する。第２に、境界中継ノードが、第１ヘッダ書き替えテーブルと第２ヘッダ書き替えテーブルの少なくともいずれかを用いて、パケットに対してヘッダ書き替え処理を行う。

ここで、第１ヘッダ書き替えテーブルは、境界中継ノードのユーザ装置機能部（ＩＡＢ－ＭＴ）で使用する第１ＣＵ間ルーティング用ヘッダ書き替えテーブルであり、第２ヘッダ書き替えテーブルは、境界中継ノードの基地局機能部（ＩＡＢ－ＤＵ）で使用する第２ＣＵ間ルーティング用ヘッダ書き替えテーブルである。

また、ヘッダ書き替え処理は、ユーザ装置機能部が、第１ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照してパケットに対してヘッダ書き替えを行い、基地局機能部が、第２ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照してパケットに対してヘッダ書き替えを行うことを含む。

このように、第３実施形態では、ヘッダ書き替えテーブルが、ＩＡＢ－ＭＴ側で使用するテーブルと、ＩＡＢ－ＤＵ側で使用するテーブルとで分類されており、ＵＬ方向とＤＬ方向とで分類されていない。そのため、ＤＬ方向又はＵＬ方向をパケット毎に特定することによる処理増大を抑制させることができる。また、ＢＡＰレイヤも他レイヤとの依存性を高めてしまう事態を抑制させることが可能となる。更に、ＩＡＢ－ＭＴとＩＡＢ－ＤＵは、各々、設定されたヘッダ書き替えテーブルを用いてヘッダ書き替え処理を行えばよいだけであるため、適切にヘッダ書き替え処理を行うことも可能となる。

なお、「ＵＬ」と「ＤＬ」は、例えば、以下を意味で用いる場合がある。すなわち、第１トポロジから第２トポロジへパケットが転送される場合に「ＵＬ」となり得る。また、第２トポロジから第１トポロジにパケットが転送される場合に「ＤＬ」となり得る。なお、第１トポロジから第１トポロジに転送される（すなわち、同一トポロジ内）パケットはヘッダ書き替えの対象外となる。

（第３実施形態に係る第１動作例）
図１７は、第３実施形態に係る境界ＩＡＢノード３００－Ｂの構成例を表す図である。

図１７に示すように、ＩＡＢ－ＭＴ（３００－ＭＴ）にはＣＵ間ルーティング用のヘッダ書き替えテーブル３５０－ＭＴを有する。ヘッダ書き替えテーブル３５０－ＭＴは、ＵＬ方向におけるパケットに対するヘッダ書き替えを行うテーブルとなっている。

また、ＩＡＢ－ＤＵ（３００－ＤＵ）は、ＣＵ間ルーティング用のヘッダ書き替えテーブル３５０－ＤＵを有する。ヘッダ書き替えテーブル３５０－ＤＵは、ＤＬ方向におけるパケットに対するヘッダ書き替えテーブルとなっている。

なお、第３実施形態に係る第１動作例では、ＩＡＢ－ＭＴ（３００－ＭＴ）側のヘッダ書き替えテーブル３５０－ＭＴを、ＭＴ用書き替えテーブル３５０－ＭＴと称し、ＩＡＢ－ＤＵ（３００－ＤＵ）側のヘッダ書き替えテーブル３５０－ＤＵを、ＤＵ用書き替えテーブル３５０－ＤＵと称する場合がある。

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

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

ステップＳ７１において、ドナーノード２００は、境界ＩＡＢノード３００－Ｂに対して、ＤＵとＭＴとで異なる分類情報を有するＣＵ間ルーティング用の書き替えテーブルを設定する。例えば、ドナーノード２００は、第１分類情報を有するＭＴ用書き替えテーブル３５０－ＭＴと、第２分類情報を有するＤＵ用書き替えテーブル３５０－ＤＵとを境界ＩＡＢノード３００－Ｂに設定する。

分類情報は、２つの書き替えテーブルに対して、ＤＵ用とＭＴ用という情報であってもよい。分類情報が各書き替えテーブルに紐づけられる。また、分類情報は、２つの書き替えテーブルを区別する名称であってもよい。例えば、「ＢＡＰ Ｈｅａｄｅｒ Ｒｅｗｒｉｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ ＩＡＢ－ＤＵ」と「ＢＡＰ Ｈｅａｄｅｒ Ｒｅｗｒｉｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ ＩＡＢ－ＭＴ」である。更に、書き替えテーブル自体は１つのテーブルとし、各エントリ（例えば、旧ルーティングＩＤと新ルーティングＩＤとからなるエントリ）に対して、ＤＵ用とＭＴ用という分類情報を紐づけてもよい。

なお、分類情報を有する各書き替えテーブルは、例えば、Ｆ１ＡＰメッセージ又はＲＲＣメッセージを用いて送信されてもよい。

ステップＳ７２において、境界ＩＡＢノード３００－Ｂは、当該設定を適用する。書き替えテーブルには分類情報が存在するため、境界ＩＡＢノード３００－Ｂは、設定された書き替えテーブルをどの位置（ＩＡＢ－ＭＴ（３００－ＭＴ）又はＩＡＢ－ＤＵ（３００－ＤＵ））に設定すればよいか容易に判断できる。

ステップＳ７３において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、パケット（ＢＡＰ Ｄａｔａ ＰＤＵ）を、上位レイヤ又は前ホップノードから受信し、受信したパケットがヘッダ書き替え対象か否かを特定する。ＩＡＢ－ＭＴのＢＡＰ送信部（ＢＡＰ Ｔｘ部）は、ＩＡＢ－ＭＴ（３００－ＭＴ）に設定されたヘッダ書き替えテーブル３５０－ＭＴを参照し、受信したパケットのＢＡＰヘッダに含まれるルーティングＩＤが、当該ヘッダ書き替えテーブル３５０－ＭＴの旧ルーティングＩＤと一致すれば、ヘッダ書き替え対象と特定してもよい。一方、当該ＢＡＰ送信部は、受信したパケットのＢＡＰヘッダに含まれるルーティングＩＤと一致するルーティングＩＤが、当該ヘッダ書き替えテーブル３５０－ＭＴの旧ルーティングＩＤになければ、当該パケットはヘッダ書き替え対象ではないと特定してもよい。ＩＡＢ－ＤＵ（３００－ＤＵ）のＢＡＰ送信部も、同様に、ＩＡＢ－ＤＵ（３００－ＤＵ）に設定されたヘッダ書き替えテーブル３５０－ＤＵを参照し、受信したパケットのＢＡＰヘッダに含まれるルーティングＩＤが、当該ヘッダ書き替えテーブル３５０－ＤＵの旧ルーティングＩＤと一致すれば、当該パケットをヘッダ書き替え対象と特定し、一致するものがなければ、当該パケットをヘッダ書き替え対象ではないと特定してもよい。

ステップＳ７４において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、ヘッダ書き替え対象のパケットに対して、ヘッダ書き替え処理を行う。ＩＡＢ－ＭＴ（３００－ＭＴ）のＢＡＰ送信部は、ＩＡＢ－ＭＴ（３００－ＭＴ）に設定されたＭＴ用書き替えテーブル３５０－ＭＴ（例えば、第１ＣＵ間ルーティング用ヘッダ書き替えテーブル）を参照して、当該パケットのＢＡＰヘッダを、旧ルーティングＩＤから新ルーティングＩＤに書き替える。また、ＩＡＢ－ＤＵ（３００－ＤＵ）のＢＡＰ送信部は、ＩＡＢ－ＤＵ（３００－ＤＵ）に設定されたＤＵ用書き替えテーブル３５０－ＤＵ（例えば、第２ＣＵ間ルーティング用ヘッダ書き替えテーブル）を参照して、当該パケットのＢＡＰヘッダを、旧ルーティングＩＤから新ルーティングＩＤに書き替える。

ステップＳ７５において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、ルーティング設定に従って、ルーティング処理を行う。

ステップＳ７６において、境界ＩＡＢノード３００－Ｂは、当該パケットを次ホップノードへ送信する。

そして、ステップＳ７７において、一連の処理が終了する。

（第３実施形態に係る第２動作例）
第３実施形態に係る第１動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルを分類する例について説明した。第３実施形態に係る第２動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルと、ＣＵ間リルーティング（又はＤＵ間リルーティング）用のヘッダ書き替えテーブルとを分類する例について説明する。

ＩＡＢノード３００において、リルーティングが行われる場合がある。リルーティングは、例えば、受信したパケットに対してルーティング設定を用いてルーティング処理を行ったものの、何らかの原因で当該パケットを送信できなかった場合に行われる。リルーティングは、ルーティング処理の後に行われる。

このようなリルーティングが、トポロジを跨いで行われる場合がある。例えば、境界ＩＡＢノード３００－Ｂにおいて、ＵＬ方向について、第１トポロジから流入したパケットを第１トポロジへルーティング処理を行ったものの、送信できなかったため、当該パケットを第２トポロジへリルーティングするなどである。この場合も、境界ＩＡＢノード３００－Ｂは、ヘッダ書き替え処理を行うことによって、第２トポロジへのリルーティングが可能となる。

例えば、図１５の場合、境界ＩＡＢノード３００－Ｂは、ヘッダ書き替え処理により、ルーティングＩＤを変更することで、ＤｅｓｔｉｎａｔｉｏｎがＣＵ＃１（２００－Ｃ１）からＣＵ＃２（２００－Ｃ２）に変更される。このようにＣＵ間を跨いだリルーティングのことを、ＣＵ間リルーティング（ｉｎｔｅｒ－ＣＵ ｒｅ－ｒｏｕｔｉｎｇ）と呼ぶ。

例えば、図１５において、ＣＵ＃１がＤＵ＃１、ＣＵ＃２がＤＵ＃２であった場合、ヘッダ書き替え処理により、ルーティングＩＤが変更されることで、ＤｅｓｔｉｎａｔｉｏｎがＤＵ＃１からＤＵ＃２へ変更される場合もある。このように、ＤＵ間を跨いだリルーティングのことを、ＤＵ間リルーティング（ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ ｒｅ－ｒｏｕｔｉｎｇ）と呼ぶ。

ＣＵ間リルーティング（ｉｎｔｅｒ－ＣＵ ｒｅ－ｒｏｕｔｉｎｇ）とＤＵ間リルーティング（ｉｎｔｅｒ－ｄｏｎｏｒ－ＤＵ ｒｅ－ｒｏｕｔｉｎｇ）とをまとめて、「ヘッダ書き替えベースリルーティング」と称する場合がある。ヘッダ書き替えベースリルーティングは、ＣＵ間リルーティングとＤＵ間リルーティングのうち少なくとも一方が含まれもよい。

なお、同一トポロジ内でのリルーティングは、ローカルリルーティングと呼ばれる。

ヘッダ書き替えベースリルーティングは、ルーティング処理を行ったものの、パケットを送信することができなかった場合に行われる。そのため、ヘッダ書き替えベースリルーティングは、ルーティング処理の後に行われる。

他方、ＣＵ間ルーティングでは、ヘッダ書き替え処理を行った後で、ルーティング処理を行うことで、受信したパケットを異なるトポロジへ送信する。そのため、ＣＵ間ルーティングは、ルーティング処理の前に行われる。

ここで、ＣＵ間ルーティング用のヘッダ書き替えテーブルと、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルとが、１つのテーブルにまとめられた場合を考える。この場合、境界ＩＡＢノード３００－Ｂでは、当該テーブル内にあるルーティングＩＤ（旧ルーティングＩＤ）について、ルーティング処理の前に処理すべきか、ルーティング処理の後に処理すべきかわからなくなる場合がある。そのため、境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティングとヘッダ書き替えベースリルーティングとを適切行うことができない場合がある。

そこで、第３実施形態に係る第２動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルと、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルとを別分類とする例について説明する。

具体的には、第１ヘッダ書き替えテーブルは、ＣＵ間ルーティング用ヘッダ書き替えテーブルであり、第２ヘッダ書き替えテーブルは、ヘッダ書き替えベースリルーティング用ヘッダ書き替えテーブルである。

これにより、例えば、境界ＩＡＢノード３００－ＢのＢＡＰレイヤでは、２つのテーブルを区別してヘッダ書き替え処理を行うことができる。具体的には、ＢＡＰレイヤでは、ルーティング処理前のＣＵ間ルーティング処理を行うときにはＣＵ間ルーティング用のヘッダ書き替えテーブルを用い、ルーティング処理後のヘッダ書き替えベースリルーティング処理を行うときには、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルを用いることが可能となる。従って、境界ＩＡＢノード３００－Ｂは、ＣＵ間ルーティングとヘッダ書き替えベースリルーティングとを適切に行うことができる。

なお、第３実施形態に係る第２動作例では、ＣＵ間ルーティング用のヘッダ書き替えテーブルを「ルーティング用ヘッダ書き替えテーブル」と称する場合がある。また、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルを「リルーティング用ヘッダ書き替えテーブル」と称する場合がある。

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

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

ステップＳ８１において、ドナーノード２００は、境界ＩＡＢノード３００－Ｂに対して、ルーティング用ヘッダ書き替えテーブルと、リルーティング用ヘッダ書き替えテーブルとで、異なる分類情報を有するように各テーブルを設定する。例えば、ドナーノード２００は、第１分類情報を有するルーティング用ヘッダ書き替えテーブルと、第２分類情報を有するリルーティング用ヘッダ書き替えテーブルとを、境界ＩＡＢノード３００－Ｂに設定する。

分類情報は、２つの書き替えテーブルに対して、ｒｏｕｔｉｎｇ用（又はＣＵ間ルーティング用）とｒｅ－ｒｏｕｔｉｎｇ用（又はヘッダ書き替えベースリルーティング用）という情報であってもよい。この場合、分類情報が各書き替えテーブルに紐づけられる。また、分類情報は、２つの書き替えテーブルを区別する名称であてもよい。例えば、「ＢＡＰ Ｈｅａｄｅｒ Ｒｅｗｒｉｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ ｒｏｕｔｉｎｇ」と「ＢＡＰ Ｈｅａｄｅｒ Ｒｅｗｒｉｔｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ｆｏｒ ｒｅ－ｒｏｕｔｉｎｇ」とであってもよい。更に、書き替えテーブル自体は１つのテーブルとし、各エントリ（例えば、旧ルーティングＩＤと新ルーティングＩＤとからなるエントリ）に対して、ｒｏｕｔｉｎｇ用とｒｅ－ｒｏｕｔｉｎｇ用という分類情報を紐づけてもよい。

なお、分類情報を有する各書き替えテーブルは、例えば、Ｆ１ＡＰメッセージ又はＲＲＣメッセージを用いて送信されてもよい。

ステップＳ８２において、境界ＩＡＢノード３００－Ｂは、当該設定を適用する。

ステップＳ８３において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、上位レイヤ又は前ホップノードから、パケット（ＢＡＰ Ｄａｔａ ＰＤＵ）を受信する。

ステップＳ８４において、ＢＡＰレイヤは、当該パケットに対して、ＣＵ間ルーティング用のヘッダ書き替え処理を行ってもよい。ＢＡＰレイヤは、ルーティング用ヘッダ書き替えテーブルを参照して、当該パケットのルーティングＩＤと同一の旧ルーティングＩＤがあれば、ＣＵ間ルーティング用のヘッダ書き替え処理を行う。ＢＡＰレイヤは、ルーティング用ヘッダ書き替えテーブルに分類情報が含まれるため、当該テーブルを容易に判別できる。ただし、ＢＡＰレイヤは、このタイミングにおいては、リルーティング用ヘッダ書き替えテーブルを参照することはなく、ヘッダ書き替えベースリルーティングを行わない。

ステップＳ８５において、ＢＡＰレイヤは、ルーティング処理及び／又はリルーティング処理を行う。このタイミングでのリルーティング処理は、ローカルリルーティング処理である。すなわち、ＢＡＰレイヤは、ルーティング処理を行ったものの、再び、ステップＳ８５に移行して、ローカルリルーティング処理を行う場合である。

ステップＳ８６において、ＢＡＰレイヤは、ルーティング及び／又はリルーティングに失敗する。

ここで、「ルーティングに失敗した」とは、ある評価条件において、次ホップアドレス（Ｎｅｘｔ Ｈｏｐ ＢＡＰアドレス）が選択できなかった場合を意味してもよい。評価条件は、パケットのヘッダとルーティングテーブル（ｒｏｕｔｉｎｇ ｃｏｎｆｉｇｕｒａｔｉｏｎ）とにおいて、Ｄｅｓｔｉｎａｔｉｏｎ及びパスＩＤが一致するか否かであってもよい。又は、評価条件は、パケットのヘッダとルーティングテーブルとにおいて、Ｄｅｓｔｉｎａｔｉｏｎのみ一致するか否かであってもよい。

ステップＳ８７において、ＢＡＰレイヤは、当該パケットがヘッダ書き替えベースリルーティング対象の場合、当該パケットに対して、リルーティング用ヘッダ書き替えテーブルを用いて、ヘッダ書き替え処理を行う。ＢＡＰレイヤは、当該パケットが、ヘッダ書き替えベースリルーティング対象か否かを特定してもよい。すなわち、ＢＡＰレイヤは、当該パケットのＢＡＰヘッダに含まれるルーティングＩＤと一致する旧ルーティングＩＤが、リルーティング用ヘッダ書き替えテーブルにあれば、ヘッダ書き替えベースリルーティング対象であると特定してもよい。一方、ＢＡＰレイヤは、当該パケットのＢＡＰヘッダに含まれるルーティングＩＤと一致する旧ルーティングＩＤが、リルーティング用ヘッダ書き替えテーブルになければ、ヘッダ書き替えベースリルーティング対象ではないと特定してもよい。ＢＡＰレイヤは、リルーティング用ヘッダ書き替えテーブルを参照して、当該パケットのＢＡＰヘッダを、旧ルーティングＩＤから新ルーティングＩＤに書き替える。

ステップＳ８８において、ＢＡＰレイヤは、当該パケットに対して、ルーティング処理又はヘッダ書き替えベースリルーティング処理を行う。

ステップＳ８９において、境界ＩＡＢノード３００－Ｂは、当該パケットを、ルーティング処理又はヘッダ書き替えベースリルーティング処理に従って、次ホップノードへ送信する。

そして、ステップＳ９０において、一連の処理が終了する。

なお、第３実施形態では、ＣＵ間リルーティングとＤＵ間リルーティングについては、共通のヘッダ書き替えテーブルを用いるものとする。そのため、第３実施形態では、ＣＵ間リルーティングとＤＵ間リルーティングとを分類するための分類情報は用いない。
[第４実施形態]
次に、第４実施形態について説明する。

１つのパケットに対して、何回もヘッダ書き替えが行われるケースがある。例えば、次のようなケースである。すなわち、境界ＩＡＢノード３００－Ｂは、当該パケットに対してＣＵ間ルーティングによりヘッダを書き替えたものの、ルーティングに失敗する。次に、境界ＩＡＢノード３００－Ｂは、当該パケットに対して、ＤＵ間リルーティングによりヘッダを書き替えたものの、再び、ルーティングに失敗する。

ＣＵ間ルーティングに用いられるヘッダ書き替えテーブルも、ヘッダ書き替えベースリルーティングに用いられるヘッダ書き替えテーブルも、エントリに含まれる旧ルーティングＩＤは、ヘッダ書き替え前のルーティングＩＤであることが前提である。

しかし、ヘッダ書き替えテーブルによりヘッダ書き替えが行われると、当該パケットのヘッダには書き替え後のルーティングＩＤが含まれることになる。このような場合に、書き替え後のルーティングＩＤに基づいて、ヘッダ書き替え処理を行うと、境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティング又はヘッダ書き替えベースリルーティングを適切に行うことができない場合がある。

そこで、第４実施形態では、ヘッダが書き替えられた後、ルーティング（又はリルーティング）に失敗した場合、当該パケットのヘッダを元のルーティングＩＤに戻す例について説明する。

具体的には、第１に、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）が、ＣＵ間ルーティング用ヘッダ書き替えテーブルを用いてパケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻す。第２に、境界中継ノードが、リルーティング用ヘッダ書き替えテーブルを用いてパケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻す。

これにより、ヘッダ書き替えによってヘッダが書き替えられても、ルーティングに失敗したときはルーティングＩＤが元のルーティングＩＤに戻されるため、境界ＩＡＢノード３００－Ｂでは、ＣＵ間ルーティング又はヘッダ書き替えベースリルーティングを適切に行うことができる。

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

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

ステップＳ１０１において、ＢＡＰレイヤは、パケットを受信する。

ステップＳ１０２において、ＢＡＰレイヤは、当該パケットに対して、ＣＵ間ルーティングのヘッダ書き替え処理を行ってもよい。ルーティング用ヘッダ書き替えテーブルに、当該パケットのルーティングＩＤと一致する旧ルーティングＩＤが存在すれば、当該ヘッダ書き替え処理を行う。ＢＡＰレイヤは、ヘッダ書き替え処理を行った場合、ＣＵ間ルーティング用にヘッダ書き替え処理済であることを示す情報をメモリなどに記録(又は記憶)してもよい。もしくは、ＢＡＰレイヤは、ヘッダ書き替え処理済であることを示す情報をメモリなどに記録してもよい。

ステップＳ１０３において、ＢＡＰレイヤは、当該パケットのルーティングに失敗する。ＢＡＰレイヤは、ＣＵ間ルーティングのヘッダ書き替え処理を行って、ルーティングに失敗した場合、ルーティングＩＤを元の旧ルーティングＩＤに戻す。また、この場合、ＢＡＰレイヤは、メモリなどに記録した書き替え処理済の情報を破棄（又は未処理と）してもよい。

ステップＳ１０４において、ＢＡＰレイヤは、当該パケットに対して、ヘッダ書き替えベースリルーティングのヘッダ書き替え処理を行う。この際、ＢＡＰレイヤは、ＣＵ間リルーティング用、ＤＵ間リルーティング用、及びヘッダ書き替えベースリルーティング用のいずれかのヘッダ書き替え処理が処理済であることを示す情報をメモリなどに記録してもよい。もしくは、ＢＡＰレイヤは、ヘッダ書き替え処理済であることを示す情報を記録してもよい。

ステップＳ１０５において、ＢＡＰレイヤは、ヘッダ書き替えベースリルーティング処理に失敗する。

ステップＳ１０６において、ＢＡＰレイヤは、ステップＳ１０４で書き替えた当該パケットのヘッダを、元のルーティングＩＤ（旧ルーティングＩＤ）に戻す（書き替える）。また、この場合、ＢＡＰレイヤは、メモリなどに記録した書き替え処理済の情報を破棄（又は未処理と）してもよい。

ステップＳ１０７において、ＢＡＰレイヤは、当該パケットを、ルーティング処理などの所定のプロシージャに戻す。

そして、ステップＳ１０８において、一連の処理が終了する。
（第４実施形態に係る他の動作例）
次に、第４実施形態に係る他の動作例について説明する。上述した動作例では、ヘッダ書き替え後のルーティング失敗又はリルーティング失敗により、ヘッダを元のルーティングＩＤに戻す例を示したが、パケットを復元することで元のルーティングＩＤを復元してもよい。具体的には、ステップＳ１０１で、ＢＡＰレイヤがパケットを受信した時に、当該パケットのコピーをメモリに保存する。次に、ステップＳ１０３において、ＢＡＰレイヤは、ルーティングに失敗した場合、当該パケット（ヘッダ書き替え済）を破棄し、メモリから当該パケットのコピーを取得する。また、ステップＳ１０５において、ＢＡＰレイヤは、ヘッダ書き替えベースリルーティング処理に失敗した場合、当該パケット（ヘッダ書き替え済）を破棄し、メモリから当該パケットのコピーを取得する。これにより、境界ＩＡＢノード３００－Ｂでは、ヘッダを再度書き替えることなく、元のルーティングＩＤを復元することができる。
[第５実施形態]
次に、第５実施形態について説明する。

３ＧＰＰでは、ＣＵ間ルーティングについて、主に、ユーザデータを対象として検討されている。他方、Ｆ１－Ｃ（制御信号）トラフィックについても、ＣＵ間ルーティングは可能である。例えば、境界ＩＡＢノード３００－Ｂは、ＣＰ／ＵＰ分離（ＣＰ／ＵＰ ｓｅｐａｒａｔｉｏｎ）機能を用いて、Ｆ１－ＣパケットをＲＲＣメッセージの中にカプセル化し、当該ＲＲＣメッセージをＳｐｌｉｔ ＳＲＢ１で送信することで、Ｆ１－Ｃパケットを第１トポロジへ又は第２トポロジへ送信することは可能である。

他方、境界ＩＡＢノード３００－Ｂは、自ノードで発生したユーザデータ（つまり、境界ＩＡＢノード３００－ＢがアクセスＩＡＢノードとして、ＵＥ１００から直接受信したデータ）についても、ＣＵ間ルーティングを行うケースが考えられる。

図２１は、第５実施形態に係る境界ＩＡＢノード３００－Ｂの例を表す図である。

一般に、アクセスＩＡＢノードでは、ＢＡＰヘッダを作成して、ドナーノード２００へ向けて、パケットを送信する。例えば、アクセスＩＡＢノードは、以下のようにして、ＢＡＰヘッダを作成する。

すなわち、アクセスＩＡＢノードは、上りトラフィックマッピング設定(Ｕｐｌｉｎｋ Ｔｒａｆｆｉｃ ｔｏ Ｒｏｕｔｉｎｇ ＩＤ Ｍａｐｐｉｎｇ Ｃｏｎｆｉｇｕｒａｔｉｏｎ)が、ドナーノード２００から設定される。上りトラフィックマッピング設定には、トラフィックタイプ識別子（ｔｒａｆｆｉｃ ｔｙｐｅ ｓｐｅｃｉｆｉｅｒ）とＢＡＰルーティングＩＤとが含まれる。なお、上りトラフィックマッピング設定は、Ｆ１ＡＰメッセージによりドナーノード２００から送信される。

アクセスＩＡＢノードのＢＡＰレイヤは、上位レイヤから受信したＢＡＰ ＳＤＵがＦＩ－Ｕトラフィックの場合、ＢＡＰ ＳＤＵのＤｅｓｔｉｎａｔｉｏｎ ＩＰアドレスとＴＥＩＤ（Tunnel Endpoint Identifier）とに対応するトラフィックタイプ識別子を含むエントリを、上りトラフィックマッピング設定から選択する。一方、ＢＡＰレイヤは、ＢＡＰ ＳＤＵがＦ１－Ｕトラフィックではない場合、ＢＡＰ ＳＤＵのトラフィックタイプ識別子を含むエントリを、上りトラフィックマッピング設定から選択する。

次に、ＢＡＰレイヤは、当該エントリのルーティングＩＤ（ＤｅｓｔｉｎａｔｉｏｎとパスＩＤ）を選択する。そして、ＢＡＰレイヤは、選択したルーティングＩＤを用いて、ＢＡＰヘッダを生成し、当該ＢＡＰ ＳＤＵにＢＡＰヘッダを付与して、ＢＡＰ ＰＤＵを生成する。

ここで、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂにおいて、ＣＵ間ルーティングを行う場合、以下のような課題がある。すなわち、現状の上りトラフィックマッピング設定は、基本的には、トラフィックタイプ識別子とＢＡＰルーティングＩＤの組が１組含まれる。この１つのＢＡＰルーティングＩＤを、２つのトポロジに割り当ててしまうと、２つのトポロジで当該ＢＡＰルーティングＩＤが存在すれば、境界ＩＡＢノード３００－Ｂは、当該ＢＡＰ ＰＤＵをどちらのトポロジへ送信すればよいかわからなくなる。そのため、アクセスＩＡＢノードでは、適切にＣＵ間ルーティングを行うことができない場合がある。

そこで、第５実施形態では、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂが、ルーティングＩＤが適用されるトポロジの情報を含む上りトラフィックマッピング設定に基づいて、トポロジに紐づいたルーティングＩＤを選択する例について説明する。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、境界中継ノード（例えば、境界ＩＡＢノード３００－Ｂ）に対して、パケット送信先のトポロジを含む上りトラフィックマッピング設定を設定する。第２に、境界中継ノードは、上りトラフィックマッピング設定に基づいて、トポロジに紐づいたルーティングＩＤを選択する。第３に、境界中継ノードは、ルーティングＩＤをヘッダに含むパケットを送信する。

これにより、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂは、ルーティングＩＤがどちらのトポロジ向けのルーティングＩＤかを把握できるため、そのトポロジに向けたパケットを適切に生成することができる。従って、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂでは、適切にＣＵ間ルーティングを行うことができる。

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

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

ステップＳ１１１において、ドナーノード２００は、アクセスＩＡＢノードでもある境界ＩＡＢノード３００－Ｂに対して、上りトラフィックマッピング設定を設定する。当該上りトラフィックマッピング設定には、既存のトラフィックタイプ識別子とＢＡＰルーティングＩＤとに加え、適用するトポロジ（又は送信先のトポロジ）の情報が含まれる。当該情報を、以下では、トポロジ情報と称する場合がある。

すなわち、トポロジ情報は、ＭＣＧ又はＳＣＧであってもよい。例えば、パケット送信先がＭＣＧ又はＳＣＧであることを表す。また、トポロジ情報は、境界ＩＡＢノード３００－ＢのＢＡＰアドレスであってもよい。すなわち、境界ＩＡＢノード３００－ＢのＢＡＰアドレスには、第１トポロジから設定されたＢＡＰアドレスと第２トポロジから設定されたＢＡＰアドレスがある。トポロジ情報を、当該ＢＡＰアドレスとすることで、パケット送信先のトポロジが第１トポロジか第２トポロジかを識別することができる。更に、トポロジ情報は、Ｆ１－ＡＰを終端しているトポロジか、Ｆ１－ＡＰを終端していないトポロジかにより表されてもよい。

なお、オプションとして、上りトラフィックマッピング設定に、ベアラＩＤが含まれてもよい。ベアラＩＤがパケット送信先を表している。例えば、トラフィックタイプ識別子がユーザデータの場合、ＢＡＰレイヤは、ベアラＩＤ毎に紐づいた送信先を選択してもよい。このように、ベアラＩＤ毎に異なる送信先となっていてもよい。

トポロジ情報とベアラＩＤは、上りトラフィックマッピング設定内の各エントリに存在してもよい。また、当該トポロジ情報とベアラＩＤは、別設定であってもよい。例えば、トポロジ毎に異なる（２つの）上りトラフィックマッピング設定が境界ＩＡＢノード３００－Ｂに通知されてもよい。

ステップＳ１１２において、境界ＩＡＢノード３００－ＢのＢＡＰレイヤは、上位レイヤからＢＡＰ ＳＤＵを受信する。

ステップＳ１１３において、ＢＡＰレイヤは、当該ＢＡＰ ＳＤＵに対応するエントリを、上りトラフィックマッピング設定から選択する。

ステップＳ１１４において、ＢＡＰレイヤは、上りトラフィックマッピング設定から、当該エントリに紐づいたトポロジ（又はパケット送信先）を特定する。

ステップＳ１１５において、ＢＡＰレイヤは、当該エントリ及び／又はトポロジに紐づいたルーティングＩＤを選択する。

ステップＳ１１６において、ＢＡＰレイヤは、当該ルーティングＩＤを用いてＢＡＰヘッダを生成し、生成したＢＡＰヘッダを、ＢＡＰ ＳＤＵに付与して、ＢＡＰ ＰＤＵを生成する。

ステップＳ１１７において、ＢＡＰレイヤは、特定したトポロジに紐づいたルーティング設定を選択し、ルーティング処理を行う。

ステップＳ１１８において、境界ＩＡＢノード３００－Ｂは、次ホップノードへ、当該パケットを送信する。

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

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

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

以上、図面を参照して一実施形態について詳しく説明したが、具体的な構成は上述のものに限られることはなく、要旨を逸脱しない範囲内において様々な設計変更等をすることが可能である。上述した各実施形態、各動作例、各処理、又は各ステップは、矛盾しない範囲で組み合わせることも可能である。

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

本願は、米国仮出願第６３／２９６２３２号（２０２２年１月４日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
（付記１）
導入
ＲＡＮ２＃１１６ｅでは、ＮＲ向け統合アクセス（Ｉｎｔｅｇｒａｔｅｄ Ａｃｃｅｓｓ）とバックホールの強化（ｅＩＡＢ）のワークアイテムにおいて、ルーティングとリルーティングの強化が大きく進展し、その合意内容はＴＳ３８．３４０の実行中のＣＲとして支持された。

この付記では、ルーティング及びリルーティングの詳細について、合意事項と実行中のＣＲの上に、現時点で基本的と思われる事項を中心に議論している。

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

ＣＵ間ルーティング
ヘッダ書き替えの判定
ＲＸまたはＴｘ動作でのモデリングに関する更なる検討が必要な事項
現在実行中のＣＲでは、ヘッダ書き替えの判断は受信動作に置かれ、以下の更なる検討が必要な事項が取り込まれている。

なお、ヘッダ書き替えの判定をＲＸ動作とＴＸ動作のどちらでモデル化するかは、議論することができる。

技術的な観点からは、ヘッダ書き替えの判定は、受信動作、送信動作のいずれでモデル化されても動作可能である。しかし、仕様の観点からは、ＩＡＢ－ＭＴとＩＡＢ－ＤＵに２つのＢＡＰエンティティが存在する、すなわち、「ＩＡＢノードでは、ＢＡＰサブレイヤはＭＴ機能に１つのＢＡＰエンティティとＤＵ機能に別のコロケーションＢＡＰエンティティを含む」とされている。したがって、エンティティ間の機能依存は可能な限り最小にする必要がある。

ヘッダ書き替えの判定は、送信動作への依存度が高いことが確認されている。実際、ヘッダ書き替えの判定結果は、以下のように受信動作に影響を与えない。すなわち、ヘッダ書き替えと判定されたかどうかに関わらず、パケットは送信部に配送される。

その他
境界ＩＡＢノードのＩＡＢ－ＤＵにおけるＢＡＰエンティティの受信部において、ヘッダ書き替え設定に、前ルーティングＩＤのＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドに一致し、前ルーティングＩＤのＢＡＰパスアイデンティティがパスフィールドに一致するエントリがある場合（サブクラス５．２．Ｘで規定）、又は
境界ＩＡＢノードのＩＡＢ－ＭＴにおけるＢＡＰエンティティの受信部分について、流入リンクがＳＣＧの場合は、
ＢＡＰデータパケットをＢＡＰヘッダ書き替えのために考慮し、
ＢＡＰデータパケットを、配置されたＢＡＰエンティティの送信部へ配送する。

そして、その結果を以下のように送信動作に利用する。すなわち、ヘッダ書き替えの対象と判断されたパケットに対してのみ、ヘッダ書き替えを行う。

ＢＡＰエンティティの送信部は、送信するＢＡＰ Ｄａｔａ ＰＤＵがある場合、以下の処理を行う。

ＢＡＰ Ｄａｔａ ＰＤＵを受信するＢＡＰエンティティがＢＡＰヘッダを書き替える場合、ＢＡＰヘッダを書き替える。

流出リンクを決定するためのルーティングを行う。

流出ＢＨ ＲＬＣチャネルを決定する。

このＢＡＰ Ｄａｔａ ＰＤＵを、選択された流出リンクの選択された流出ＢＨ ＲＬＣチャネルに送信する。

所見１：ヘッダ書き替えの判定結果は、受信動作には依存しないが、送信動作には影響を与える。

この意味で、ヘッダ書き替えの判断は、Ｔｘ操作でモデル化されることが好ましい。ＢＡＰヘッダ書き替え操作の中で取り込むか、新しいセクションを設けるかについては更なる検討が必要である。

提案１：ＣＵ間ルーティングについて、ＲＡＮ２は、ヘッダ書き替えの決定を送信動作でモデル化することに合意すべきである。

ダウンストリームのトラフィックに関する更なる検討が必要な事項
ヘッダ書き替えの必要性の判断方法の詳細については、ダウンストリームトラフィック、すなわち「境界ＩＡＢノードのＩＡＢ－ＭＴにおけるＢＡＰエンティティの受信部について、流入リンクがＳＣＧの場合はＢＡＰヘッダ書き替え用のＢＡＰデータパケットを考慮する」という別の更なる検討事項が取り込まれている。

なお、ＳＮがＦ１終端ノードである場合の考慮を含め、トポロジ間移行／トポロジ冗長化／ＲＬＦ回復のための流入リンクを特定するためにＳＣＧが十分かどうかについて更なる検討が必要である。

上述のように、ＳＣＧは、例えばＣＰ／ＵＰ分離のようなすべてのケースに適用できない可能性がある。そのため、ドナー側がどちらの流入リンク、すなわちＭＣＧ又はＳＣＧがヘッダ書き替え操作を必要とするかを明示的に示すことは、単純なことだと考えられる。

提案２：ＣＵ間ルーティングについて、ドナー側がＩＡＢ－ＭＴにどの流入リンク、すなわちＭＣＧまたはＳＣＧのＢＡＰヘッダの書き替えが必要であるかを設定することにＲＡＮ２は合意すべきである。

ヘッダ書き替え操作
ヘッダ書き替えの設定に関する更なる検討が必要な事項
ＲＡＮ２＃１１６ｅでは、設定の問題について議論し、更なる検討が必要な事項と以下の合意に達した。

古いルーティングＩＤから新しいルーティングＩＤへのマッピング設定を書き替え、（すべての書き替えの場合）可能な書き替えを制限することについて、詳細は更なる検討が必要である。

また、現在実行中のＣＲにおいて、以下の更なる検討事項が取り込まれている。

Ｒ３合意に基づき、ＵＬとＤＬでヘッダ書き替え設定が異なるのか、どのように異なるのかについて更なる検討を行う。ＵＬトラフィックの場合、それらは参照する流出トポロジを示す必要がある。その表示は暗黙的であってもよい。

現在の実行中のＣＲでは、「ＢＡＰデータＰＤＵがＢＡＰヘッダ書き替えの対象となる場合、ＢＡＰエンティティの送信部はＢＡＰヘッダ書き替え動作を行う」、すなわちヘッダ書き替えを決定した後にＴｘ部でヘッダ書き替えを行うこととされている。この場合、ＩＡＢ－ＤＵでは常にダウンストリーム用のヘッダ書き替え設定が使用され、ＩＡＢ－ＭＴではアップストリーム用のものが使用されるだけである。そこで、２つのヘッダ書き替えテーブルを定義し、それぞれＩＡＢ－ＤＵとＩＡＢ－ＭＴに関連付ける方が簡単であり、ヘッダ書き替えの判定動作と同様である。

提案３：ＣＵ間ルーティングのために、ドナー側は、ＩＡＢ－ＤＵ（すなわちダウンストリーム）のＢＡＰエンティティのＴｘ部分に使用される２つのヘッダ書き替えテーブルとＩＡＢ－ＭＴ（すなわちアップストリーム）のそれぞれで境界ＩＡＢノードを構成することに合意すべきである。

ヘッダ書き替え動作における更なる検討が必要な事項
現在実行中のＣＲでは、ヘッダ書き替え動作は、送信動作、受信動作と同じレベルで取り込まれ、以下の記載が付されている。

ＢＡＰヘッダ書き替えの方法を取り込むために使用され、ＣＵ間ルーティング、ＣＵ間リルーティング、ドナーＤＵ間リルーティングのケースで使用することが可能である。本節の必要性／位置／詳細については、ＲＡＮ２がヘッダ書き替えの全ケースについて明確な合意を得た後に確認／改訂される。

ヘッダ書き替え動作は、送信動作で参照されるため、送信動作の下に取り込む必要がある。

提案４：ＲＡＮ２は、ヘッダ書き替え操作を送信操作の下で定義すること、すなわち、ＢＡＰ仕様書で合意すべきである。

ルーティングテーブルの選択
原則として、ドナーＣＵは自身のトポロジのルーティングテーブルを管理する。ＣＵ間シナリオでは、２つのドナーＣＵが境界ＩＡＢノードでのルーティングに関与し、これらのドナーＣＵは独立してルーティングテーブルを管理することが想定される。この意味で、境界ＩＡＢノードが、これらのドナーＣＵによって別々に管理される２つのルーティングテーブルで構成されることは単純なことである。

提案５：ＲＡＮ２は、境界ＩＡＢノードが２つのルーティングテーブルで構成され、それぞれドナーＣＵと別のドナーＣＵによって管理されることに合意すべきである。

提案５に合意する場合、境界ＩＡＢノードがルーティング処理中のトラフィックに適用するルーティングテーブルを選択する方法について議論する価値がある。ＣＵ間シナリオでは、図２に示すように、トポロジ内でルーティングされるトラフィック（レガシールーティングと同様、別名、非連結トラフィック）と、２つのトポロジにまたがってルーティングされるトラフィック（別名、連結トラフィック）の２つのトラフィックカテゴリがある。

ＢＡＰエンティティのＴｘ部でルーティングを行うことを考えると、図２４に示すように、受信ソース（流入リンク）に関わらず、３つの送信方向（流出リンク）が存在することになる。

図２４のトポロジ＃１の場合、トラフィックが連結されているかどうかに関わらず、ダウンストリームのトラフィックは常にレガシールーティングテーブルに従うことがわかる。このため、境界ＩＡＢノードはダウンストリームトラフィックのルーティングにレガシールーティングテーブルを適用する必要がある。

提案６：ダウンストリームパケットについて、ＲＡＮ２は境界ＩＡＢノードが常にレガシールーティングテーブルを選択することに合意すべきである。

アップストリームのトラフィックについては、パケットがどのトポロジで送信されるかによって、適用できるルーティングテーブルが異なる。現在実行中のＣＲにあるように、結合されたトラフィックはルーティング処理の前にヘッダが書き替えられていると考えると、境界ＩＡＢノードは次のように適切なルーティングテーブルを選択することができる。

ヘッダを書き替えないパケットには、レガシールーティングテーブル（図２４のトポロジ＃１の場合）が選択される。

ヘッダを書き替えたパケットに対して、新しいルーティングテーブル（図２４のトポロジ＃２の場合）が選択される。

適切なルーティングテーブルが選択されると、パケットは既存のルーティング手順によって処理される。

提案７：アップストリームパケットについて、ＲＡＮ２は、ルーティング処理中のパケットがヘッダを書き替えたかどうかに応じて、境界ＩＡＢノードがレガシールーティングテーブルまたは新しいルーティングテーブルのいずれかを選択することに合意すべきである。

ＣＵ間リルーティングとドナーＤＵ間リルーティング
ヘッダ書き替えによるリルート動作の条件
現在実行中のＣＲでは、ヘッダ書き替えによるリルーティングの条件として、以下の更なる検討が必要な事項が取り込まれている。

「ヘッダ書き替えテーブル（リルーティング用）が設定されている場合」は、「ヘッダ書き替えテーブルに、前回のルーティングＩＤのＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、前回のルーティングＩＤのＢＡＰパスＩＤがパスフィールドと一致するエントリがある場合」と修正する必要がある。

この問題は、リルーティング（＝ＣＵ間リルーティング、ドナーＤＵ間リルーティング）用のヘッダ書き替えテーブルが、ルーティング（＝ＣＵ間ルーティング）用のものと分離されているかどうかに関係するものである。ルーティング用のヘッダ書き替えはルーティング手順の前に行われ、リルート用のヘッダ書き替えはルーティング手順の後に行われる。つまり、ルーティング用ヘッダ書き替えはルーティング用ヘッダ書き替えテーブルに基づいて行い、リルート用ヘッダ書き替えはリルート用ヘッダ書き替えテーブルに基づいて行う必要がある。同じヘッダ書き替えテーブルを想定すると、古いルーティングＩＤをルーティング手順の前と後、すなわちルーティング用とリルーティング用のどちらのヘッダ書き替えを行うかで、境界ＩＡＢノードが混乱する可能性があるからである。そのため、リルーティング用のヘッダ書き替えテーブルとルーティング用のヘッダ書き替えテーブルを分離することが望ましい。

所見２：ルーティング用ヘッダ書き替え動作は、ルーティング用ヘッダ書き替え設定に基づくルーティング手順の前に行われ、リルーティング用ヘッダ書き替え動作は、リルーティング用ヘッダ書き替え設定に基づくルーティング手順の後に行われる。

また、ＣＵ間リルーティングとドナーＤＵ間リルーティングのヘッダ書き替えテーブルを分離する必要があるかどうかについても問題である。ＣＵ間リルーティングとドナーＤＵ間リルーティングは、どちらもリルーティングのためのシナリオであるため、同じヘッダ書き替えテーブルを使用することができると考えることができる。また、ＣＵ間リルーティング、ドナーＤＵ間リルーティングともに、アップストリームトラフィックのみを対象とすることを想定している。そのため、リルーティングのためのヘッダ書き替えテーブルは、アップストリームとダウンストリームを区別する必要はない。

しかし、ＣＵ間リルーティングは、この時点で異なるＩＡＢドナー、すなわち異なるトポロジに向けてＲＲＣ復元を行うため（すなわち、過渡的状態）、一方、ドナーＤＵ間リルーティングは、同じトポロジ内の異なるＩＡＢドナーＤＵに宛先ＢＡＰアドレスを変更するため（すなわち、静的状態）、経路関連の設定の観点からいくつかの違いがある可能性がある。したがって、さらなる合意が得られるまで、現時点では更なる検討が必要な事項としておくべきだろう。

以上の所見から、少なくともルーティング用のヘッダ書き替えテーブルとは別に、リルーティング用のヘッダ書き替えテーブルを定義することが望ましい。

提案８：ＲＡＮ２は、ＣＵ間リルーティングとドナーＤＵ間リルーティングのヘッダ書き替えテーブルが、ＣＵ間ルーティングのテーブルとは別物であることに合意すべきである。共通のヘッダ書き替えテーブルが両方のリルーティングシナリオに適用されるかどうかについては更なる検討が必要である。

流出リンク選択前後のヘッダ書き替え
現在実行中のＣＲにおいて、以下の更なる検討が必要な事項が取り込まれている。

ＲＡＮ２がヘッダ書き替えに基づくＵＬリルーティングの場合、流出リンク選択後にヘッダ書き替えを行うことに合意すれば、上記を修正することができる。

流出リンクの選択はルーティング手順の中で行われ、ヘッダの書き替え操作はルーティング手順の前に行われることが前提であり、つまり、流出リンクの選択とヘッダの書き替え操作は現在分離されているのである。そのため、これらの処理が混在すると複雑になる。

また、ＲＡＮ２＃１１６ｅでは、トポロジ内（ドナーＤＵ間リルーティング）において、リルーティングのためのＢＡＰヘッダ書き替えの事前条件はＲｅｌ－１６と同様、すなわち、流出リンク選択との条件なし、として以下のように合意された。

トポロジ内
アップストリームの場合、「ＢＡＰヘッダ書き替えによるリルーティング」の前提条件／基準は、Ｒ１６と同様に、ＢＡＰルーティングＩＤに基づき、かつルーティングテーブルのＢＡＰアドレスに基づく利用可能な次ホップが見つからないこと（ＢＨ ＲＬＦや輻輳、Ｔｙｐｅ－２ Ｉｎｄｉｃａｔｉｏｎなどによる）である。

ＣＵ間リルーティングにおけるヘッダ書き替えについて、異なる前提条件を考慮することは合理的でない。そこで、ドナーＤＵ間リルーティングとＣＵ間リルーティングの両方に上記の合意を適用すべきである。

提案９：ＲＡＮ２は、Ｒｅｌ－１６と同様にルーティング手順内で流出リンクの選択が行われること、すなわち流出リンク選択の前にヘッダの書き替えが行われることに合意すべきである。

ヘッダ書き替え前の流出リンク選択の利点は、ヘッダ書き替え後にパケットのリルーティングに失敗した場合を回避することである。つまり、ＣＵ間リルーティングやドナーＤＵ間リルーティングに失敗した場合、ヘッダ書き替えを行ったパケットはヘッダ書き替えを行うのかどうか、つまり、１つのパケットに対して何回ヘッダ書き替えを行うのかどうかは不明である。ヘッダ書き替えを複数回行うと、誤操作のリスクや複雑さが生じる可能性がある。

このシナリオでは、すなわち、ＣＵ間またはドナーＤＵ間のリルーティングが失敗した場合、フロー制御フィードバックの受信によって、ＩＡＢノードが輻輳のために利用可能なリンクを持っていないと仮定される。この場合、パケットは先に輻輳から回復した流出リンクを経由して送信されることになる。したがって、パケットは、回復した流出リンクに応じて、古いルーティングＩＤまたは新しいルーティングＩＤのいずれかを持つことが望ましい。

以上の議論から、ヘッダ書き替えに基づくリルーティングに失敗した場合、ヘッダを新しいルーティングＩＤから古いルーティングＩＤに戻すという方法が考えられる。このようにすれば、パケットは元の状態、すなわちヘッダに古いルーティングＩＤを持つ状態に戻り、ＢＡＰエンティティの送信動作の最初から処理されることができる。このパケットに対して再度ルーティングを行うことを意味し、ルーティングに失敗した場合にはリルーティングを行うことができる。

提案１０：ＲＡＮ２は、ヘッダ書き替えに基づくリルーティング（すなわち、ＣＵ間リルーティングまたはドナーＤＵ間リルーティング）が失敗した場合に、ヘッダを戻すかどうかを議論すべきである。

ヘッダ書き替えに基づくリルーティングのモデル化
Ｒｅｌ－１６では、ルーティングとリルートはルーティングプロセス内でモデル化される。つまり、リルートはルーティングに従う。

ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、ＢＡＰパスＩＤがパスフィールドと一致し、次ホップアドレスに対応する流出リンクが利用可能なエントリがＢＨルーティング設定に存在する場合、
そのエントリの次ホップアドレスに対応する流出リンクを選択する。

ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、次ホップアドレスに対応する流出リンクが利用可能なエントリがＢＨルーティング設定に少なくとも１つ存在する場合、
ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと同じで、次ホップアドレスに対応する流出リンクが利用可能なエントリをＢＨルーティング設定から選択する。

上記で選択したエントリの次ホップアドレスに対応する流出リンクを選択する。

現在実行中のＣＲでは、ヘッダ書き替えに基づくリルーティングは、同じモデリング、すなわち、Ｒｅｌ－１６リルーティングに従うものを適用している。

それ以外の場合は、ヘッダ書き替え設定（リルーティング用）が設定され、少なくとも１つの流出リンクが利用可能である場合、
ＢＡＰヘッダ書き替え操作を行う。

ＢＨルーティング設定に、ＢＡＰアドレスがＤｅｓｔｉｎａｔｉｏｎフィールドと一致し、ＢＡＰパスＩＤがパスフィールドと一致し、次ホップアドレスに対応する流出リンクが存在する場合、
そのエントリの次ホップアドレスに対応する流出リンクを選択する。

上記のように、Ｒｅｌ－１６ルーティングとＲｅｌ－１７ヘッダ書き替えベースのリルーティングは同じ文章、つまりルーティング手順を再度実行するように見受けられる。そのため、簡略化する候補として考えてもよい。

また、Ｒｅｌ－１６のローカルリルートは、ルーティング手順の中でリルートが行われるため、明確ではなかった。そこで、ルーティングからリルーティングのセクションを分離することも可能なオプションかもしれない。

提案１１：ＲＡＮ２は、仕様をより明確にするために、リルーティングのモデリングを簡略化する方法を議論すべきである。

機能強化の概要
上記の提案に合意できる場合、すべてのシナリオに対する統合解決策の例を図２５に、またヘッダ書き替えテーブルとルーティングテーブルの概要を表１に示す。

全シナリオの構成強化の概要
（付記２）
上述の実施形態に関する特徴について記載する。

（１）
セルラ通信システムで用いる通信制御方法であって、
ドナーノードが、トポロジ内の中継ノードに対して、ルーティング設定に関するメッセージを送信するステップと、
前記中継ノードが、前記メッセージを受信したことに応じて第１の処理を行うステップと、を有する
通信制御方法。

（２）
前記送信するステップは、
前記ドナーノードが、前記トポロジ内の前記中継ノードに対してルーティング設定の変更を開始したことに応じて、ルーティング設定変更開始メッセージをアクセス中継ノードへ送信するステップと、
前記ドナーノードが、前記トポロジ内の前記中継ノードに対してルーティング設定の変更を完了したことに応じて、ルーティング設定変更完了メッセージを前記アクセス中継ノードへ送信するステップと、を含み、
前記第１の処理を行うステップは、
アクセス中継ノードが、前記ルーティング設定変更開始メッセージと前記ルーティング設定変更完了メッセージとに基づいて、アップストリーム方向において一定期間過去に送信したパケットを再送信するステップを含む、
上記（１）に記載の通信制御方法。

（３）
前記送信するステップは、
前記ドナーノードが、前記トポロジ内の前記中継ノードに対して、ルーティング停止指示メッセージを送信するステップを含み、
前記第１の処理を行うステップは、
前記中継ノードが、前記ルーティング停止指示メッセージに従って、ルーティング処理を停止するとともに、受信したパケットをメモリに保持するステップを含み、
更に、前記ドナーノードが、前記中継ノードに対して、ルーティング設定を変更し、ルーティング設定変更前のルーティングＩＤとルーティング設定変更後のルーティングＩＤとのマッピング情報を送信するステップと、
前記中継ノードが、ルーティング処理を再開し、前記マッピング情報に従って、前記メモリに保持した前記パケットのヘッダを書き替えて送信するステップと、を有する
上記（１）に記載の通信制御方法。

（４）
セルラ通信システムで用いる通信制御方法であって、
ドナーノードが、ダウンストリームリンクを指定した指定情報を、境界中継ノードへ送信するステップと、
前記境界中継ノードが、前記指定情報に従って、前記ダウンストリームリンクから流入したパケットに対してヘッダ書替え処理を行うステップと、を有する、
通信制御方法。

（５）
セルラ通信システムで用いる通信制御方法であって、
ドナーノードが、境界中継ノードに対して、第１分類情報を有する第１ヘッダ書き替えテーブルと、第２分類情報を有する第２ヘッダ書き替えテーブルを設定するステップと、
前記境界中継ノードが、前記第１ヘッダ書き替えテーブルと前記第２ヘッダ書き替えテーブルの少なくともいずれかを用いて、パケットに対してヘッダ書き替え処理を行うステップと、を有する、
通信制御方法。

（６）
前記第１ヘッダ書き替えテーブルは、前記境界中継ノードのユーザ装置機能部（ＩＡＢ－ＭＴ）で使用する第１ＣＵ間ルーティング用ヘッダ書き替えテーブルであり、前記第２ヘッダ書き替えテーブルは、前記境界中継ノードの基地局機能部（ＩＡＢ－ＤＵ）で使用する第２ＣＵ間ルーティング用ヘッダ書き替えテーブルであって
前記ヘッダ書き替え処理を行うステップは、前記ユーザ装置機能部が、前記第１ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照して前記パケットに対してヘッダ書き替えを行い、前記基地局機能部が、前記第２ＣＵ間ルーティング用ヘッダ書き替えテーブルを参照して前記パケットに対してヘッダ書き替えを行うステップを含む、
上記（５）に記載の通信制御方法。

（７）
前記第１ヘッダ書き替えテーブルは、ＣＵ間ルーティング用のヘッダ書き替えテーブルであり、前記第２ヘッダ書き替えテーブルは、ヘッダ書き替えベースリルーティング用のヘッダ書き替えテーブルである、
上記（５）に記載の通信制御方法。

（８）
前記ヘッダ書き替え処理を行うステップは、
前記境界中継ノードが、前記ＣＵ間ルーティング用ヘッダ書き替えテーブルを用いて前記パケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻すステップと、
前記境界中継ノードが、前記リルーティング用ヘッダ書き替えテーブルを用いて前記パケットに対してヘッダ書き替えを行った後、ルーティングに失敗したとき、書き替えたルーティングＩＤを書き替え前のルーティングＩＤに戻すステップと、を含む、
上記（７）に記載の通信制御方法。

（９）
セルラ通信システムで用いる通信制御方法であって、
ドナーノードが、境界中継ノードに対して、パケット送信先のトポロジを含む上りトラフィックマッピング設定を設定するステップと、
前記境界中継ノードが、前記上りトラフィックマッピング設定に基づいて、前記トポロジに紐づいたルーティングＩＤを選択するステップと、
前記境界中継ノードが、前記ルーティングＩＤをヘッダに含む前記パケットを送信するステップと、を有する、
通信制御方法。

Claims (5)

1. セルラ通信システムで用いる通信制御方法であって、
   境界中継ノードが、流入リンクに関する設定情報を、ネットワークから受信することと、
   前記境界中継ノードが、前記設定情報に基づいて、前記流入リンクに対応するトポロジを特定することと、
   前記境界中継ノードが、前記流入リンクに対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行うことと、を有し、
   前記境界中継ノードは、第１トポロジを管理する第１ドナーノードとのＦ１接続を有するとともに、第２トポロジを管理する第２ドナーノードとのＲＲＣ接続を有し、
   前記所定のトポロジは、前記第２トポロジである
   通信制御方法。
2. 境界中継ノードであって、
   流入リンクに関する設定情報をネットワークから受信する受信部と、
   前記設定情報に基づいて、前記流入リンクに対応するトポロジを特定する制御部と、
   前記制御部は、前記流入リンクに対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケット に対してヘッダ書替え処理を行い、
   前記境界中継ノードは、第１トポロジを管理する第１ドナーノードとのＦ１接続を有するとともに、第２トポロジを管理する第２ドナーノードとのＲＲＣ接続を有し、
   前記所定のトポロジは、前記第２トポロジである
   境界中継ノード。
3. 境界中継ノードのチップセットであって、
   流入リンクに関する設定情報をネットワークから受信することと、
   前記設定情報に基づいて、前記流入リンクに対応するトポロジを特定することと、
   前記流入リンクに対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行うことと、を含み、
   前記境界中継ノードは、第１トポロジを管理する第１ドナーノードとのＦ１接続を有するとともに、第２トポロジを管理する第２ドナーノードとのＲＲＣ接続を有し、
   前記所定のトポロジは、前記第２トポロジである
   チップセット。
4. 第１ドナーノードと第２ドナーノードと境界中継ノードとを有するセルラ通信システムであって、
   前記境界中継ノードは、流入リンクに関する設定情報を、ネットワークから受信し、
   前記境界中継ノードは、前記設定情報に基づいて、前記流入リンクに対応するトポロジを特定し、
   前記境界中継ノードは、前記流入リンクに対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行い、
   前記境界中継ノードは、第１トポロジを管理する前記第１ドナーノードとのＦ１接続を有するとともに、第２トポロジを管理する前記第２ドナーノードとのＲＲＣ接続を有し、
   前記所定のトポロジは、前記第２トポロジである
   セルラ通信システム。
5. セルラ通信システムの境界中継ノードに、
   流入リンクに関する設定情報を、ネットワークから受信する処理と、
   前記設定情報に基づいて、前記流入リンクに対応するトポロジを特定する処理と、
   前記流入リンクに対応するトポロジが所定のトポロジである場合、前記ネットワークから受信したヘッダ書き替え設定情報に基づいて、前記流入リンクから流入したパケットに対してヘッダ書替え処理を行う処理と、を実行させ、
   前記境界中継ノードは、第１トポロジを管理する第１ドナーノードとのＦ１接続を有するとともに、第２トポロジを管理する第２ドナーノードとのＲＲＣ接続を有し、
   前記所定のトポロジは、前記第２トポロジである
   プログラム。
   

Images