JP7575604B2 - 通信制御方法 - Google Patents

Description

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

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

第１の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ドナーノードが、第１ユーザ装置と第２ユーザ装置との間でデータ無線ベアラ（ＤＲＢ）を確立するための設定を、第１ユーザ装置と第２ユーザ装置に対してそれぞれ行うことを有する。また、前記通信制御方法は、第１ユーザ装置と第２ユーザ装置が、設定を受けて、第１ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）エンティティと第２ＰＤＣＰエンティティをそれぞれ確立することを有する。更に、前記通信制御方法は、第１ＰＤＣＰエンティティが、ＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）を介することなく、第２ＰＤＣＰエンティティへ、データを送信することと、中継ノードが、前記データをＰＤＣＰレイヤよりも下位のレイヤにおけるレイヤ２中継により中継することと、を有する。

第２の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、ドナーノードが、ローカルルーティングを行う中継ノードに対して、ルーティング設定を行うことを有する。また、前記通信制御方法は、中継ノードが、ルーティング設定に従って、第１ユーザ装置から送信されたデータを、ＵＰＦを介することなく、第２ユーザ装置へ送信することを有する。

第３の態様に係る通信制御方法は、セルラ通信システムで用いる通信制御方法である。前記通信制御方法は、中継ノードが、ルーティング設定に従って、第１ユーザ装置から送信されたデータを、ＵＰＦを介することなく、第２ユーザ装置へ送信することを有する。また、前記通信制御方法は、中継ノードが、データのデータ量をドナーノードへ送信することを有する。

図１は、一実施形態に係るセルラ通信システムの構成例を表す図である。 図２は、一実施形態に係るＩＡＢノードと親ノード（Ｐａｒｅｎｔ ｎｏｄｅｓ）と子ノード（Ｃｈｉｌｄ ｎｏｄｅｓ）との関係を表す図である。 図３は、一実施形態に係るｇＮＢ（ドナーノード）の構成例を表す図である。 図４は、一実施形態に係るＩＡＢノード（中継ノード）の構成例を表す図である。 図５は、一実施形態に係るＵＥ（ユーザ装置）の構成例を表す図である。 図６は、一実施形態に係るＩＡＢ－ＭＴのＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）接続及びＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）接続に関するプロトコルスタックの例を表す図である。 図７は、一実施形態に係るＦ１－Ｕプロトコルに関するプロトコルスタックの例を表す図である。 図８は、一実施形態に係るＦ１－Ｃプロトコルに関するプロトコルスタックの例を表す図である。 図９（Ａ）と図９（Ｂ）は、第１実施形態に係るＰＤＣＰリンクの例を表す図である。 図１０は、第１実施形態に係る動作例を表す図である。 図１１は、第２実施形態に係る動作例を表す図である。 図１２（Ａ）と図１２（Ｂ）は、第２実施形態のＩＡＢノードの関係例を表す図である。 図１３（Ａ）と図１３（Ｂ）は、第２実施形態に係るＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）チャネル情報の例を表す図である。 図１４は、第３実施形態に係る動作例を表す図である。

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

（セルラ通信システムの構成）
まず、一実施形態に係るセルラ通信システムの構成例について説明する。一実施形態に係るセルラ通信システムは３ＧＰＰの５Ｇシステムである。具体的には、セルラ通信システムにおける無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（Ｎｅｗ Ｒａｄｉｏ）である。但し、セルラ通信システムには、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。また、セルラ通信システムは、６Ｇなど、将来のセルラ通信システムも適用されてよい。

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

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

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

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

５ＧＣ１０は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１１、ＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）１２、及びＳＭＦ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）１３を有する。ＡＭＦ１１は、ＵＥ１００に対する各種モビリティ制御等を行う装置である。ＡＭＦ１１は、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）シグナリングを用いてＵＥ１００と通信することにより、ＵＥ１００が在圏するエリアの情報を管理する。ＵＰＦ１２は、ユーザデータの転送制御等を行う装置である。ＳＭＦ１３は、ＵＥ１００のセッション管理、及びＵＰＦ１２の制御等を行う装置である。

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

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

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

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

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

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

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

図２に示すように、各ＩＡＢノード３００は、基地局機能部に相当するＩＡＢ－ＤＵとユーザ装置機能部に相当するＩＡＢ－ＭＴ（Ｍｏｂｉｌｅ Ｔｅｒｍｉｎａｔｉｏｎ）とを有する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図６に示すように、ＩＡＢノード３００－２のＩＡＢ－ＭＴは、物理（ＰＨＹ）レイヤと、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤと、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤと、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤと、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤと、ＮＡＳ（Ｎｏｎ－Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤとを有する。

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

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

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

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

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

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

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

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

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

なお、ドナーノード２００のＣＵは、ＩＡＢノード３００とドナーノード２００のＤＵへのＦ１インターフェイスを終端する、ドナーノード２００のｇＮＢ－ＣＵ機能である。また、ドナーノード２００のＤＵは、ＩＡＢ ＢＡＰサブレイヤをホストし、ＩＡＢノード３００へワイヤレスバックホールを提供する、ドナーノード２００のｇＮＢ－ＤＵ機能である。

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

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

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

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

（ルーティングとローカルルーティング）
最初にルーティングについて説明する。

ＢＡＰレイヤの機能の１つに、次ホップへのパケットのルーティング機能がある。複数のＩＡＢノード３００によって形成されたネットワークにおいて、各ＩＡＢノード３００は、受信したパケットを次ホップへ転送することで、最終的には、宛先ＩＡＢノード３００（又ドナーノード２００）へパケットを送信させるようにしている。ルーティングは、例えば、受信したパケットをどのＩＡＢノード３００へ転送するかを制御することである。このようなルーティングの設定は、ドナーノード２００によって行われる。

しかし、複数のＩＡＢノード３００から構成されたネットワークにおいて、ＩＡＢノード３００間のバックホールリンクで回線障害が発生する場合がある。

複数のＩＡＢノード３００によってパケットを次々と転送させるマルチホップネットワークでは、データパケットを、代替パス（ａｌｔｅｒｎａｔｉｖｅ ｐａｔｈ）を介して宛先ＩＡＢノード３００（又はドナーノード２００）へ転送させることができる。このように代替パスを利用して、データパケットを転送することを、ローカルルーティングと称する場合がある。ローカルルーティングは、ドナーノード２００によって設定された代替パス候補の中から代替パスを選択することで行われてもよい。

また、３ＧＰＰシステム内の通信は、通常、コアネットワーク（具体的にはＵＰＦ１２）でルーティングが行われる。２台のＵＥ（例えば、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２））が通信する場合、これらＵＥがローカルエリア（例えば、同一ＩＡＢノード３００のカバレッジ内）に存在する場合でも、一旦、ＵＰＦ１２までデータを到達させ、同じ経路で折り返し通信を行う必要がある。このような場合、コアネットワークを介さずに（例えば、ＩＡＢノード３００において）データのルーティングを行うことで、コアネットワークのトラフィック量を低減したり、コアネットワーク内の通信で発生する遅延を少なくしたりすることができる。このようにコアネットワークを介さないルーティングを、ローカルルーティングと称する場合がある。

（ＤＲＢ確立とＰＤＣＰエンティティ確立）
次に、ＤＲＢ確立（Ｄａｔａ Ｒａｄｉｏ Ｂｅａｒｅｒ ｅｓｔａｂｌｉｓｈｍｅｎｔ）とＰＤＣＰエンティティ確立について説明する。

ＤＲＢとＰＤＣＰエンティティは、ＰＤＵセッションを確立する際に確立される場合がある。

ＰＤＵセッションは、ＵＥ１００とＵＰＦ１２との間でユーザデータを転送するための論理的な経路である。ＵＥ１００がＰＤＵセッション確立をネットワークへ要求した後、ＵＥ１００は、ｇＮＢ２００からＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信する。ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、ＤＲＢを設定する無線ベアラ設定情報（ｒａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ）が含まれる。ＵＥ１００は、当該無線ベアラ設定情報に基づいて、新たなＰＤＵセッションのためにＤＲＢを確立し、ＱＦＩ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｆｌｏｗ ＩＤ）をＤＲＢにマッピングするマッピング規則を生成する。

無線ベアラ設定情報には、ＤＲＢの識別情報（ＤＲＢ ＩＤ）とＰＤＣＰ設定情報（ＰＤＣＰ Ｃｏｎｆｉｇ）とが含まれる。ＵＥ１００は、当該ＤＲＢ ＩＤが現在のＵＥ１００における設定の一部ではないことを確認すると、受信したＰＤＣＰ設定情報に従って、ＰＤＣＰを確立する。

ＤＲＢとＰＤＣＰとが確立された後、ユーザデータは、ＵＥ１００とｇＮＢ２００間において、マッピング規則に従ってＤＲＢ上で交換される。また、ユーザデータは、ｇＮＢ２００とＵＰＦ１２間において、ＰＤＵセッションのトンネルプロトコル上で交換される。

このように、ＵＥ１００は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる無線ベアラ設定情報に基づいて、ＤＲＢを確立し、ＰＤＣＰエンティティを確立することができる。

以下では、ＤＲＢの確立とＰＤＣＰエンティティの確立とを区別しないで用いる場合がある。

（ＰＤＣＰリンク）
ＩＡＢノード３００は、レイヤ２中継を行う。具体的には、ＲＬＣ以下のレイヤ（サブレイヤ）とＢＡＰレイヤとを用いてユーザデータの中継を行い、これらのレイヤ以上のレイヤ（具体的には、ＰＤＣＰレイヤ及びＳＤＡＰレイヤ）を用いることはない。そのため、ＩＡＢノード３００間では、ＰＤＣＰリンクは存在しない。

図９（Ａ）は、第１実施形態に係るＰＤＣＰリンクの例を表す図である。図９（Ａ）に示すように、ＵＥ１００とドナーノード２００のＣＵとはＰＤＣＰリンクが存在する。しかし、上記した理由で、ＵＥ１００とＩＡＢノード３００との間では、ＰＤＣＰリンクは存在しない。

従って、ＩＡＢノード３００は、ＵＥ＃１（１００－１）から送信されたデータ（ＰＤＣＰ ＰＤＵ）を、ローカルルーティングによって、ＵＥ＃２（１００－２）へ送信しても、ＰＤＣＰリンクが確立されていないため、ＵＥ＃２（１００－２）では、データをデコードできない場合がある。具体的には、ＵＥ＃１（１００－１）で暗号化されたＰＤＣＰ ＰＤＵは、ＵＥ＃２（１００－２）において復号することができない虞がある。

そこで、第１実施形態は、ＵＥ１００間において、ＰＤＣＰリンクを確立し、ＰＤＣＰリンクを用いてデータを交換する。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、第１ユーザ装置（例えば、ＵＥ＃１（１００－１））と第２ユーザ装置（例えば、ＵＥ＃２（１００－２））との間でデータ無線ベアラ（ＤＲＢ）を確立するための設定を、第１ユーザ装置と第２ユーザ装置に対して行う。第２に、第１ユーザ装置と第２ユーザ装置が、設定を受けて、第１ＰＤＣＰエンティティと第２ＰＤＣＰエンティティをそれぞれ確立する。第３に、第１ＰＤＣＰエンティティが、ＵＰＦ（例えば、ＵＰＦ１２）を介することなく、第２ＰＤＣＰエンティティへ、データを送信する。

これにより、ＵＥ１００間でＰＤＣＰリンクが確立されるため、ＩＡＢノード３００において、ＵＥ＃１（１００－１）から送信されたデータに対してローカルルーティングを行ってＵＥ＃２（１００－２）へ転送しても、ＵＥ＃２（１００－２）においてデータを効率的に取得できる。また、ＩＡＢノード３００におけるローカルルーティングによって、ＵＥ＃１（１００－１）から送信されたデータは、コアネットワーク（例えばＵＰＦ１２）を介することなく、ＵＥ＃２（１００－２）へ転送できる。このため、コアネットワークのトラフィック量を低減したり、コアネットワーク内の通信で発生する遅延を少なくしたりすることも可能となる。

（第１実施形態の動作例）
図１０は、第１実施形態に係る動作例を表す図である。なお、図１０に示す動作例は、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）との間でＰＤＣＰリンクを確立する例を含む。

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

ステップＳ１１において、ドナーノード２００は、ＣＮ（Ｃｏｒｅ Ｎｅｔｗｏｒｋ）から、ローカルルーティングが可能なＰＤＵセッションに関する情報を取得してもよい。ＣＮは、５ＧＣ１０に含まれるＡＭＦ１１、ＵＰＦ１２、及びＳＭＦ１３のうち少なくとも一つであってもよい。

第１に、例えば、ＵＥ＃１（１００－１）から送信されたデータがＵＰＦ１２で折り返して、ＵＥ＃２（１００－２）へ送信される場合、ドナーノード２００がＰＤＵセッションに関する情報を取得してもよい。具体的には、ドナーノード２００からＧＴＰ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ Ｔｕｎｎｅｌｉｎｇ Ｐｒｏｔｏｃｏｌ）トンネルを介して送信されたデータがＵＰＦ１２で折り返して、同一ドナーノード２００の異なるＧＴＰトンネルに向けて送信される場合である。

又は、例えば、ＵＥ＃２（１００－２）のＩＰアドレスが同一ネットワーク内に存在することをＵＰＦ１２が確認した場合に、ドナーノード２００がＰＤＵセッションに関する情報を取得してもよい。

第２に、ＰＤＵセッションに関する情報は、例えば、以下のいずれかを含む。

（Ａ１）ＰＤＵセッションＩＤ：ＵＥ１００とＵＰＦ１２との間のＰＤＵセッションＩＤ。上記したＵＰＦ１２での折り返しがある場合、ＵＥ＃１（１００－１）とＵＰＦ１２との間のＰＤＵセッションＩＤと、ＵＰＦ１２とＵＥ＃２（１００－２）との間のＰＤＵセッションＩＤとのペアがＰＤＵセッションに関する情報であってもよい。

（Ａ２）ＧＴＰトンネルＩＤ：ドナーノード２００とＵＰＦ１２との間のＧＴＰトンネルＩＤ。上記したＵＰＦ１２での折り返しがある場合、ドナーノード２００とＵＰＦ１２との間のＧＴＰトンネルＩＤと、ＵＰＦ１２とドナーノード２００との間のＧＴＰトンネルＩＤと、のペアが、ＰＤＵセッションに関する情報であってもよい。

（Ａ３）ＱｏＳフローＩＤ（ＱＦＩ）

（Ａ４）ＵＥ１００のＩＰアドレス：例えば、ＵＥ＃１（１００－１）のＩＰアドレスとＵＥ＃２（１００－２）のＩＰアドレスのペアがＰＤＵセッションに関する情報であってもよい。

（Ａ５）ＵＥ－ＩＤ（例えば、ＮＧ－ＡＰ ＵＥ ＩＤ又は５Ｇ－Ｓ－ＴＭＳＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ））：例えば、ＵＥ＃１（１００－１）に対するＵＥ－ＩＤと、ＵＥ＃２（１００－２）に対するＵＥ－ＩＤのペアがＰＤＵセッションに関する情報であってもよい。

ドナーノード２００が、ＰＤＵセッションに関する情報を取得するのは、ＤＲＢ確立において、あるいはＤＲＢ確立後のデータ転送において、これらの情報が用いられる場合があるからである。

ステップＳ１２において、ドナーノード２００は、ローカルルーティングを行うことを決定する。

ステップＳ１３において、ドナーノード２００は、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）に対して、ＤＲＢ確立のための設定を行う。例えば、ドナーノード２００は、上述した無線ベアラ設定情報を含むＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを、ＵＥ＃１（１００－１）とＵＥ＃２（２００－２）へ送信することで、ＤＲＢ確立のための設定を行う。

この場合、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、ＵＥ間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）用ＤＲＢであることを示す情報が含まれてもよい。すなわち、当該情報は、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）との間のＰＤＣＰ確立（ＤＲＢ確立）（例えば、図９（Ｂ））であって、ドナーノード２００とＵＥ１００との間のＰＤＣＰ確立（ＤＲＢ確立）（例えば、図９（Ａ））ではないことを示す情報である。ＵＥ間のＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）用ＤＲＢであることを示す情報は、ローカルルーティング対象であることを示すものであってもよい。

また、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、相手方のＵＥ１００に関する情報が含まれてもよい。当該情報として、例えば、ＵＥ＃２（１００－２）のＩＰアドレス、又はＵＥ＃２（１００－２）のＵＥ－ＩＤがある。

更に、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、対象となるＱｏＳフローＩＤが含まれてもよい。

更に、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージには、ステップＳ１１において、ドナーノード２００が取得したＰＤＵセッションに関する情報が含まれてもよい。

ステップＳ１４において、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）は、設定を受けて、ＰＤＣＰエンティティを確立する。

例えば、ＵＥ＃１（１００－１）とＵＥ＃２（２００－２）は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれる無線ベアラ設定情報（ｒａｄｉｏＢｅａｒｅｒＣｏｎｆｉｇ）に基づいて、ＰＤＣＰエンティティを確立する。ＵＥ＃１（１００－１）とＵＥ＃２（２００－２）は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれるＰ２Ｐ用ＤＲＢであることを示す情報と無線ベアラ設定情報とに基づいて、ＰＤＣＰエンティティを確立してもよい。これにより、図９（Ｂ）に示すように、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）とでＰＤＣＰエンティティが確立される。

図１０に戻り、ステップＳ１５において、ＵＥ＃１（１００－１）は、所定データを、ＰＤＣＰエンティティ（又はＤＲＢ）へ出力する。所定データは、ＵＥ＃２のＩＰアドレスに合致するデータである。又は、所定データは、対象ＱｏＳフローＩＤに合致するデータである。又は、所定データは、対象ＰＤＵセッションＩＤに合致するデータである。例えば、ＵＥ＃１（１００－１）のＲＬＣエンティティは、所定データをＵＥ＃２（１００－２）宛てのデータとして、ＰＤＣＰエンティティへ出力する。ＵＥ＃１（１００－１）のＰＤＣＰエンティティは、所定データを、ＵＥ＃２（１００－２）のＰＤＣＰエンティティへ送信する。他方、ＵＥ＃１（１００－１）のＲＬＣエンティティは、所定データではないデータを、ドナーノード２００宛てのデータとして、ＩＡＢノード３００のＲＬＣエンティティへ送信する。

ステップＳ１６において、ＵＥ＃２（１００－２）は、所定データを、ＩＡＢノード３００経由で（又はドナーノード２００経由で）受信する。すなわち、ＵＥ＃２（１００－２）のＰＤＣＰエンティティは、ＵＥ＃１（１００－１）のＰＤＣＰエンティティから送信された所定データ（ＰＤＣＰ ＰＤＵ）を受信する。なお、ＰＤＣＰセキュリティキーは、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）双方とも、ＮＲ Ｕｕ無線インターフェイスで用いたセキュリティキーを使用してもよい。

ステップＳ１７において、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）は一連の処理を終了する。

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

第１実施形態では、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）がＰＤＣＰエンティティを確立後、ＩＡＢノード３００がローカルルーティングを行って、データを転送する例について説明した。

第２実施形態は、ＩＡＢノード３００において、どのようにローカルルーティングを行って、データを転送するかについての実施形態である。

具体的には、第１に、ドナーノード（例えば、ドナーノード２００）が、ローカルルーティングを行う中継ノード（例えば、ＩＡＢノード３００）に対して、ルーティング設定を行う。第２に、中継ノードが、ルーティング設定に従って、第１ユーザ装置（例えば、ＵＥ＃１（１００－１））から送信されたデータを、ＵＰＦ（例えば、ＵＰＦ１２）を介することなく、第２ユーザ装置（例えば、ＵＥ＃２（１００－２））へ送信する。

これにより、ＩＡＢノード３００は、ＵＥ＃１（１００－１）から送信されたデータを、ローカルルーティングを行って、ＵＰＦ１２を介することなく、ＵＥ＃２（１００－２）へ、適切に転送できる。

ここで、ルーティング設定によるルーティングの一般的な具体例について説明する。

（ルーティング具体例）
ＩＡＢノード３００において、パケットのルーティングは、例えば、以下のようにして行われる。すなわち、ドナーノード２００のＩＡＢ－ＣＵは、各ＩＡＢノード３００のＩＡＢ－ＤＵに対して、ルーティング設定を提供する。提供するルーティング設定は、ルーティングＩＤと次ホップのＢＡＰアドレスとを含む。ルーティングＩＤは、（宛先）ＢＡＰアドレスとパスＩＤとから構成される。各ＩＡＢノード３００は、パケット（ＢＡＰパケット）を受信すると、当該パケットのヘッダに含まれる宛先ＢＡＰアドレスを読み出す。各ＩＡＢノード３００は、宛先ＢＡＰアドレスと、自ＩＡＢノード３００のＢＡＰアドレスとが一致するか否かを判定する。各ＩＡＢノード３００は、宛先ＢＡＰアドレスが自ＢＡＰアドレスと一致するときは、データパケットが目的地に到達したと判定する。他方、各ＩＡＢノード３００は、宛先ＢＡＰアドレスが自ＢＡＰアドレスと一致しないときは、ルーティング設定に従って、次ホップのＢＡＰアドレスのＩＡＢノード３００へ、パケットを転送する。ルーティング設定は、例えば、Ｆ１ＡＰメッセージを利用して行われる。

このように、各ＩＡＢノード３００は、ドナーノード２００によって設定されたルーティング設定に従って、受信したＢＡＰパケットを次ホップへ転送するようにしている。

第２実施形態では、ドナーノード２００が、ローカルルーティングを行うＩＡＢノード３００に対して、新たにルーティングＩＤを設定するとともに、当該ルーティングＩＤに紐づいたＲＬＣチャネル情報を設定することで、ローカルルーティングの設定を行うようにしている。以下、具体的に説明する。

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

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

ステップＳ２１において、ドナーノード２００は、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）に対してＤＲＢを確立するための設定を行う。ステップＳ２１は、第１実施形態のステップＳ１３（図１０）と同一である。ステップＳ２１は、後述するステップＳ２３の後で行われてもよい。

ステップＳ２２において、ドナーノード２００は、ローカルルーティングを行うＩＡＢノード３００に対してルーティング設定を行う。

第１に、ドナーノード２００は、新たなルーティングＩＤを、ローカルルーティングを行うＩＡＢノード３００に設定する。上述したように、ルーティングＩＤには、宛先ＢＡＰアドレスが含まれる。ドナーノード２００は、新たなルーティングＩＤに含まれる宛先ＢＡＰアドレスとして、ＵＥ＃１がアクセスするＩＡＢノード３００のＢＡＰアドレスを指定してもよい。

図１２（Ａ）は、第２実施形態に係るＩＡＢノード３００の関係例を表す図である。図１２（Ａ）の例では、ＵＥ＃１（１００－１）がアクセスするＩＡＢノード３００に対して、ＵＥ＃２（１００－２）もアクセスしている例である。このような場合、ＩＡＢノード３００でローカルルーティングが行われる。ドナーノード２００は、ＩＡＢノード３００のＢＡＰアドレスを宛先ＢＡＰアドレスとしてもよい。

図１２（Ｂ）は、第２実施形態に係るＩＡＢノード３００の関係例を表す図である。図１２（Ｂ）では、ＵＥ＃１（１００－１）がアクセスするのはＩＡＢノード３００－１であり、ＵＥ＃２（１００－２）がアクセスするのはＩＡＢノード３００－３である。更に、２つのＩＡＢノード３００－１，３００－３の親ノードとしてＩＡＢノード３００－２がある。

ドナーノード２００は、ローカルルーティングを行うＩＡＢノード３００として、ＩＡＢノード３００－１、ＩＡＢノード３００－２、及び／又はＩＡＢノード３００－３としてもよい。ただし、ドナーノード２００は、新たなルーティングＩＤの宛先ＢＡＰアドレスとして、ＩＡＢノード３００－３のＢＡＰアドレスを指定してもよい。

なお、図１２（Ｂ）の場合、ＩＡＢノード３００－１とＩＡＢノード３００－２とにおいて、ローカルルーティング対象のデータ（ＢＡＰ ＰＤＵ）の宛先を、ＩＡＢノード３００－３のＢＡＰアドレスにセットする。そのため、ドナーノード２００は、ローカルルーティング対象のＢＡＰ ＰＤＵのヘッダに含まれる宛先を、ＩＡＢノード３００－３のＢＡＰアドレスにセットすることを示す情報を、ＩＡＢノード３００－１とＩＡＢノード３００－２とに対して送信してもよい。

なお、ドナーノード２００のＣＵが、当該ルーティングＩＤを含むＦ１ＡＰメッセージを、ＩＡＢノード３００のＩＡＢ－ＤＵへ送信することで、新たなルーティングＩＤの設定が行われてもよい。また、ドナーノード２００のＣＵが、当該ルーティングＩＤを含むＲＲＣメッセージを、ＩＡＢノード３００のＩＡＢ－ＭＴへ送信することで、新たなルーティングＩＤの設定が行われてもよい。

また、ローカルルーティング対象のＢＡＰ ＰＤＵのヘッダに含まれる宛先を、ＩＡＢノード３００－３のＢＡＰアドレスにセットすることを示す情報も、Ｆ１ＡＰメッセージ又はＲＲＣメッセージにより送信されてもよい。

第２に、ドナーノード２００は、新たなルーティングＩＤに紐づいたＲＬＣ Ｃｈａｎｎｅｌ（ＲＬＣチャネル）情報を、ローカルルーティングを行うＩＡＢノード３００に設定する。

図１３（Ａ）は、第２実施形態に係るＲＬＣチャネル情報の例を表す図である。図１３（Ａ）の例では、前ホップＢＡＰアドレス（Ｐｒｉｏｒ－ＨＯＰ ＢＡＰ Ａｄｄｒｅｓｓ）と次ホップＢＡＰアドレス（Ｎｅｘｔ－ＨＯＰ ＢＡＰ Ａｄｄｒｅｓｓ）とが含まれる。そのため、図１３（Ａ）に示すＲＬＣチャネル情報は、例えば、図１２（Ｂ）のＩＡＢノード３００－２に設定されてもよい。

図１３（Ｂ）も、第２実施形態に係るＲＬＣチャネル情報の例を表す図である。図１３（Ｂ）に示すＲＬＣチャネル情報は、ルーティングＩＤが含まれる。そのため、ＩＡＢノード３００は、ルーティングＩＤから、次ホップＢＡＰアドレスと流出（ｅｇｒｅｓｓ）ＲＬＣ ＣＨ ＩＤとを特定することが可能となる。

ただし、図１３（Ａ）と図１３（Ｂ）は、ＲＬＣチャネル情報にＢＡＰアドレスが含まれる例である。例えば、図１２（Ａ）のＩＡＢノード３００では、入力側も出力側もＢＡＰヘッダが付与されない。また、図１２（Ｂ）のＩＡＢノード３００－１では入力側、ＩＡＢノード３００－３では出力側にＢＡＰヘッダが付与されない。そのため、例えば、ＢＡＰアドレス（Ｐｒｉｏｒ－ＨＯＰ ＢＡＰ ＡｄｄｒｅｓｓとＮｅｘｔ－ＨＯＰ ＢＡＰ Ａｄｄｒｅｓｓ）ではなく、流入（Ｉｎｇｒｅｓｓ）ＲＬＣ ＣＨ ＩＤ及び／又は流出（ｅｇｒｅｓｓ）ＲＬＣ ＣＨ ＩＤを利用して、パケットに対するローカルルーティングが行われてもよい。ＢＡＰアドレスが含まれず、流入（Ｉｎｇｒｅｓｓ）ＲＬＣ ＣＨ ＩＤ及び／又は流出（ｅｇｒｅｓｓ）ＲＬＣ ＣＨ ＩＤを含むＲＬＣチャネル情報が用いられてもよい。

また、ドナーノード２００は、新たなルーティングＩＤと、ＲＬＣチャネル情報とを紐づける紐づけ情報も、ＩＡＢノード３００へ送信してもよい。

なお、ドナーノード２００のＣＵが、ＲＬＣチャネル情報を含むＦ１ＡＰメッセージを、ＩＡＢノード３００のＩＡＢ－ＤＵへ送信することで、ＲＬＣチャネルの設定が行われてもよい。また、ドナーノード２００のＣＵが、紐づけ情報を含むＦ１ＡＰメッセージを、ＩＡＢノード３００のＩＡＢ－ＤＵへ送信してもよい。Ｆ１ＡＰメッセージに代えて、ＲＲＣメッセージにより、ＲＬＣチャネルの設定と紐づけ情報の送信が行われてもよい。

図１１に戻り、ステップＳ２３において、ＩＡＢノード３００は、ルーティング設定に従って、ローカルルーティングを行う。ＩＡＢノード３００（図１２（Ｂ）のＩＡＢノード３００－２）は、ＢＡＰ ＰＤＵヘッダの宛先を、ＵＥ＃２（１００－２）がアクセスするＩＡＢノード３００－３のＢＡＰアドレスに書き換えてもよい。また、ＩＡＢノード３００は、ルーティングＩＤに含まれるパスＩＤを書き換えてもよい。ドナーノード２００は、新たなルーティングＩＤ毎に、ローカルルーティング後（又は書き換え後）の宛先ＢＡＰアドレス（又はルーティングＩＤ全体）を、ローカルルーティングを行うＩＡＢノード３００へ送信してもよい。

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

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

第１実施形態と第２実施形態において、ＩＡＢノード３００がローカルルーティングを行い、ＵＥ＃１（１００－１）からのデータを、ＵＰＦ１２を介することなく、ＵＥ＃２（１００－２）へ転送する例について説明した。

しかし、ＵＰＦ１２を含むＣＮには、データが転送されない。そのため、ＣＮは、ＵＥ＃１（１００－１）とＵＥ＃２（１００－２）間で転送されるデータのデータ量を把握することができない。

そこで、第３実施形態では、ＩＡＢノード３００は、ローカルルーティングによりデータを転送した場合、当該データのデータ量をドナーノード２００へ送信する例について説明する。具体的には、第１に、中継ノード（例えば、ＩＡＢノード３００）が、ルーティング設定に従って、第１ユーザ装置（例えば、ＵＥ＃１（１００－１））から送信されたデータを、ＵＰＦ（例えば、ＵＰＦ１２）を介することなく、第２ユーザ装置（例えば、ＵＥ＃２（１００－２））へ送信する。第２に、中継ノードが、データのデータ量をドナーノード（例えば、ドナーノード２００）へ送信する。

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

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

ステップＳ３１において、ＩＡＢノード３００は、ローカルルーティングを行う。第１実施形態又は第２実施形態と同様に、例えば、ＩＡＢノード３００は、ＵＥ＃１（１００－１）から送信されたデータに対して、ローカルルーティングを行って、ＵＰＦ１２を介することなく、ＵＥ＃２（１００－２）へ送信する。

ステップＳ３２において、ＩＡＢノード３００は、データ量をカウントして、メモリに記憶（又は記録。以下では、「記憶」と称する場合がある。）する。ＩＡＢノード３００は、ローカルルーティングを行ったＢＡＰ ＰＤＵのペイロード部分のデータ量をカウントして、メモリに記憶してもよい。また、ＩＡＢノード３００は、ＢＡＰヘッダを含むＢＡＰ ＰＤＵ全体のデータ量をカウントしてメモリに記憶してもよい。

当該記憶は、ＢＡＰレイヤで行われてもよい。この場合、例えば、ＢＡＰレイヤは、ＢＡＰ ＰＤＵのデータ量をカウントしてメモリに記憶し、ＲＲＣレイヤからの要求に応じて、記憶したデータ量（の累計）をＲＲＣレイヤへ出力する。

また、当該記憶は、ＲＲＣレイヤで行われてもよい。この場合、例えば、ＲＲＣレイヤは、ＢＡＰレイヤにおいて、ＢＡＰパケット転送毎にカウントしたデータ量をＢＡＰレイヤから入力し、当該データ量の累計をメモリに記憶する。

ステップＳ３３において、ＩＡＢノード３００は、ドナーノード２００へ、データ量を送信する。例えば、ＩＡＢノード３００は、メモリに記憶したデータ量を読み出して、ドナーノード２００へ送信する。

第１に、ＩＡＢノード３００は、ＵＥ１００のＰＤＵセッションＩＤ、ＵＥ１００のＤＲＢＩＤ、ルーティングＩＤ、及びＲＬＣ Ｃｈａｎｎｅｌ ＩＤのうち少なくとも１つを、データ量に紐づけて送信してもよい。

第２に、ＩＡＢノード３００は、時間情報をデータ量とともにドナーノード２００へ送信してもよい。時間情報は、測定時間、開始時刻、終了時刻、又はこれらの組み合わせでもよい。

第３に、ＩＡＢノード３００は、以下をトリガにして、ドナーノード２００へデータ量を送信してもよい。すなわち、ＩＡＢノード３００は、ドナーノード２００からの要求に応じて、データ量を送信してもよい。また、ＩＡＢノード３００は、ローカルルーティングを行うための設定（例えば、第２実施形態のステップＳ２２（図１１））が取り除かれた場合に、データ量を送信してもよい。更に、ＩＡＢノード３００は、データ量が閾値に達した場合に、データ量を送信してもよい。閾値は、ドナーノード２００によって設定されてもよい。更に、ＩＡＢノード３００は、周期的（ｐｅｒｉｏｄｉｃ）にデータ量を送信してもよい。周期（又は時間間隔）は、ドナーノード２００によって設定されてもよい。

なお、ＩＡＢノード３００のＩＡＢ－ＭＴが、データ量を含むＲＲＣメッセージを、ドナーノード２００のＣＵへ送信してもよい。また、ＩＡＢノード３００のＩＡＢ－ＤＵが、データ量を含むＦ１ＡＰメッセージを、ドナーノード２００のＣＵへ送信してもよい。

ステップＳ３４において、ドナーノード２００は、ＩＡＢノード３００から受信したデータ量を、ＡＭＦ１１を含むＣＮへ、送信してもよい。ＣＮでは、データ量を当該ユーザのデータ量としてメモリに記憶してもよい。ＣＮは、データ量に基づいて、チャージング又は課金処理などを行う。

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

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

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

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

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

１ ：移動通信システム
１０ ：５ＧＣ
１１ ：ＡＭＦ
１２ ：ＵＰＦ
１３ ：ＳＭＦ
１００ ：ＵＥ
１１０ ：無線通信部
１２０ ：制御部
２００（２００－１，２００－２） ：ｇＮＢ（ドナーノード）
２１０ ：無線通信部
２２０ ：ネットワーク通信部
２３０ ：制御部
３００ ：ＩＡＢノード
３１０ ：無線通信部
３２０ ：制御部

Claims (10)

1. セルラ通信システムで用いる通信制御方法であって、
   中継ノードが、第１ユーザ装置と第２ユーザ装置との間でデータを中継すること、を有し、
   前記中継することは、前記中継ノードが、前記第１ユーザ装置と前記第２ユーザ装置との間の通信に関する識別情報に基づいて流出ＲＬＣチャネルを決定し、当該流出ＲＬＣチャネルを利用してレイヤ２中継による前記中継を行うことを含む
   通信制御方法。
2. 前記中継ノードは、ユーザ装置の機能を有する、
   請求項１記載の通信制御方法。
3. 中継ノードと、
   第１ユーザ装置と、
   第２ユーザ装置と、を有するセルラ通信システムであって、
   前記中継ノードは、前記第１ユーザ装置と前記第２ユーザ装置との間でデータを中継し、
   前記中継ノードは、前記第１ユーザ装置と前記第２ユーザ装置との間の通信に関する識別情報に基づいて流出ＲＬＣチャネルを決定し、当該流出ＲＬＣチャネルを利用してレイヤ２中継による前記中継を行う
   セルラ通信システム。
4. 前記中継ノードは、ユーザ装置の機能を有する
   請求項３記載のセルラ通信システム。
5. セルラ通信システムにおける中継ノードであって、
   第１ユーザ装置と第２ユーザ装置との間でデータを中継する制御部を有し、
   前記制御部は、前記第１ユーザ装置と前記第２ユーザ装置との間の通信に関する識別情報に基づいて流出ＲＬＣチャネルを決定し、当該流出ＲＬＣチャネルを利用してレイヤ２中継による前記中継を行う
   中継ノード。
6. 前記中継ノードは、ユーザ装置の機能を有する
   請求項５記載の中継ノード。
7. セルラ通信システムにおける中継ノードに、
   第１ユーザ装置と第２ユーザ装置との間でデータを中継する処理を実行させ、
   前記中継する処理は、前記第１ユーザ装置と前記第２ユーザ装置との間の通信に関する識別情報に基づいて流出ＲＬＣチャネルを決定し、当該流出ＲＬＣチャネルを利用してレイヤ２中継による前記中継を行う処理を含む
   プログラム。
8. 前記中継ノードは、ユーザ装置の機能を有する
   請求項７記載のプログラム。
9. セルラ通信システムにおける中継ノードのチップセットであって、
   第１ユーザ装置と第２ユーザ装置との間でデータを中継し、
   前記中継することは、前記第１ユーザ装置と前記第２ユーザ装置との間の通信に関する識別情報に基づいて流出ＲＬＣチャネルを決定し、当該流出ＲＬＣチャネルを利用してレイヤ２中継による前記中継を行うことを含む
   チップセット。
10. 前記中継ノードは、ユーザ装置の機能を有する
    請求項９記載のチップセット。

Images