JP7189219B2

JP7189219B2 - 中継装置

Info

Publication number: JP7189219B2
Application number: JP2020535848A
Authority: JP
Inventors: 真人藤代; ヘンリーチャン
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2018-08-08
Filing date: 2019-08-07
Publication date: 2022-12-13
Anticipated expiration: 2039-08-07
Also published as: US20210159968A1; WO2020032129A1; US11949490B2; JPWO2020032129A1

Description

本開示は、移動通信システムに用いられる中継装置に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）において、ＩＡＢ（ＩｎｔｅｇｒａｔｅｄＡｃｃｅｓｓａｎｄＢａｃｋｈａｕｌ）ノードと称される新たな中継装置が検討されている。１又は複数の中継装置が基地局とユーザ機器との間の通信に介在し、この通信に対する中継を行う。かかる中継装置は、ユーザ機器機能及び基地局機能を有しており、ユーザ機器機能を用いて上位ノード（基地局又は上位の中継装置）との無線通信を行うとともに、基地局機能を用いて下位ノード（ユーザ機器又は下位の中継装置）との無線通信を行う。

ユーザ機器と、中継装置又は基地局との間の無線区間は、アクセスリンクと称されることがある。中継装置と、基地局又は他の中継装置との間の無線区間は、バックホールリンクと称されることがある。３ＧＰＰ寄書「ＲＰ－１７０２１７」には、アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクに動的に無線リソースを割り当てることにより、データ転送経路を動的に切り替える方法が記載されている。

一実施形態に係る中継装置は、移動通信システムに用いられる。前記中継装置は、第１の通信装置からデータを受信する受信側ＲＬＣエンティティと、前記受信側ＲＬＣエンティティが受信した前記データを第２の通信装置に送信する送信側ＲＬＣエンティティとを備える。前記送信側ＲＬＣエンティティは、前記送信されたデータを前記第２の通信装置が受信成功したことを示す第１の肯定応答を前記第２の通信装置から受信する。前記受信側ＲＬＣエンティティは、前記送信側ＲＬＣエンティティが前記第１の肯定応答を受信するまで待った後、前記データを前記受信側ＲＬＣエンティティが受信成功したことを示す第２の肯定応答を前記第１の通信装置に送信する。

一実施形態に係る中継装置は、移動通信システムに用いられる。前記中継装置は、第１の通信装置からデータを受信する受信側ＲＬＣエンティティと、第２の通信装置と対応付けられた第１の送信側ＲＬＣエンティティと、第３の通信装置と対応付けられた第２の送信側ＲＬＣエンティティと、前記受信側ＲＬＣエンティティが受信した前記データを前記第１の送信側ＲＬＣエンティティに提供するとともに前記データを保持する上位エンティティとを備える。前記上位エンティティは、当該中継装置と前記第２の通信装置との間の無線状態の悪化、又は前記第２の通信装置から前記第３の通信装置へのデータ転送経路の切り替えに応じて、前記保持しているデータを前記第２の送信側ＲＬＣエンティティに提供する。

実施形態に係る移動通信システムの構成を示す図である。実施形態に係る基地局（ｇＮＢ）の構成を示す図である。実施形態に係る中継装置（ＩＡＢノード）の構成を示す図である。実施形態に係るユーザ機器（ＵＥ）の構成を示す図である。実施形態に係る移動通信システムにおけるユーザプレーンのプロトコルスタック構成の一例を示す図である。第１実施形態に係る通常動作シーケンスの一例を示す図である。第１実施形態に係るコンテキスト転送先を決定するためのテーブルの一例を示す図である。第１実施形態に係る例外動作シーケンスの一例を示す図である。第１実施形態に係るマルチホップ接続シーケンスの一例を示す図である。第２実施形態に係る「ｅｎｄ－ｔｏ－ｅｎｄ」の一例を示す図である。第２実施形態に係る「ｈｏｐ－ｂｙ－ｈｏｐ」の一例を示す図である。第２実施形態に係る動作例を示すシーケンス図である。第２実施形態に係る他の動作例を示すシーケンス図である。第２実施形態の変更例を示す図である。ＵＥへのＲＬＣＡＣＫの送信を遅らせる選択肢１を示す図である。ＵＥへのＲＬＣＡＣＫの送信を遅らせる選択肢２を示す図である。

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

［第１実施形態］
（移動通信システムの構成）
本実施形態に係る移動通信システムの構成について説明する。図１は、本実施形態に係る移動通信システム１の構成を示す図である。移動通信システム１は、３ＧＰＰ規格に基づく第５世代（５Ｇ）移動通信システムである。具体的には、移動通信システム１における無線アクセス方式は、５Ｇの無線アクセス方式であるＮＲ（ＮｅｗＲａｄｉｏ）である。但し、移動通信システム１には、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）が少なくとも部分的に適用されてもよい。

図１に示すように、移動通信システム１は、５Ｇコアネットワーク（５ＧＣ）１０と、ユーザ機器（ＵＥ）１００と、基地局（ｇＮＢと称される）２００と、ＩＡＢノード３００とを備える。本実施形態において、基地局がＮＲ基地局である一例について主として説明するが、基地局がＬＴＥ基地局（すなわち、ｅＮＢ）であってもよい。

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

ｇＮＢ２００は、ＮＧインターフェイスと称されるインターフェイスを介して、５ＧＣ１０に接続される。図１において、５ＧＣ１０に接続された３つのｇＮＢ２００－１～ｇＮＢ２００－３を例示している。ｇＮＢ２００は、ＵＥ１００との無線通信を行う固定の無線通信装置である。ｇＮＢ２００がドナー機能を有する場合、ｇＮＢ２００は、自身に無線で接続するＩＡＢノードとの無線通信を行ってもよい。

ｇＮＢ２００は、Ｘｎインターフェイスと称される基地局間インターフェイスを介して、隣接関係にある他のｇＮＢ２００と接続される。図１において、ｇＮＢ２００－１がｇＮＢ２００－２及びｇＮＢ２００－２に接続される一例を示している。

各ｇＮＢ２００は、１又は複数のセルを管理する。セルは、無線通信エリアの最小単位を示す用語として用いられる。セルは、ＵＥ１００との無線通信を行う機能又はリソースを示す用語として用いられることがある。１つのセルは１つのキャリア周波数に属する。

ＵＥ１００は、ｇＮＢ２００との無線通信を行う移動可能な無線通信装置である。ＵＥ１００は、ＩＡＢノード３００との無線通信を行ってもよい。ＵＥ１００は、ｇＮＢ２００又はＩＡＢノード３００との無線通信を行う装置であればどのような装置であっても構わないが、例えば、ＵＥ１００は、携帯電話端末やタブレット端末、ノートＰＣ、センサ若しくはセンサに設けられる装置、車両若しくは車両に設けられる装置である。

図１において、ＵＥ１００－１がｇＮＢ２００－１に無線で接続され、ＵＥ１００－２がＩＡＢノード３００－１に無線で接続され、ＵＥ１００－３がＩＡＢノード３００－２に無線で接続される一例を示している。ＵＥ１００－１は、ｇＮＢ２００－１との通信を直接的に行う。ＵＥ１００－２は、ＩＡＢノード３００－１を介してｇＮＢ２００－１との通信を間接的に行う。ＵＥ１００－３は、ＩＡＢノード３００－１及びＩＡＢノード３００－２を介してｇＮＢ２００－１との通信を間接的に行う。

ＩＡＢノード３００は、ｅＮＢ２００とＵＥ１００との間の通信に介在し、この通信に対する中継を行う装置（中継装置）である。図１において、ＩＡＢノード３００－１がドナーであるｇＮＢ２００－１に無線で接続され、ＩＡＢノード３００－２がＩＡＢノード３００－１に無線で接続される一例を示している。各ＩＡＢノード３００は、セルを管理する。ＩＡＢノード３００が管理するセルのセルＩＤは、ドナーｇＮＢ２００－１のセルのセルＩＤと同じであってもよいし、異なっていてもよい。

ＩＡＢノード３００は、ＵＥ機能（ユーザ機器機能）及びｇＮＢ機能（基地局機能）を有する。ＩＡＢノード３００は、ＵＥ機能を用いて上位ノード（ｇＮＢ２００又は上位のＩＡＢノード３００）との無線通信を行うとともに、ｇＮＢ機能を用いて下位ノード（ＵＥ１００又は下位のＩＡＢノード３００）との無線通信を行う。なお、ＵＥ機能とは、ＵＥ１００が有する機能のうち少なくとも一部の機能を意味し、必ずしもＵＥ１００の全ての機能をＩＡＢノード３００が有していなくてもよい。ｇＮＢ機能とは、ｇＮＢ２００の機能のうち少なくとも一部の機能を意味し、必ずしもｇＮＢ２００の全ての機能をＩＡＢノード３００が有していなくてもよい。

ＵＥ１００と、ＩＡＢノード３００又はｇＮＢ２００との間の無線区間は、アクセスリンク（或いは、Ｕｕ）と称されることがある。ＩＡＢノード３００と、ｇＮＢ２００又は他のＩＡＢノード３００との間の無線区間は、バックホールリンク（或いは、Ｕｎ）と称されることがある。かかるバックホールリンクは、フロントホールリンクと称されてもよい。

アクセスリンクのデータ通信及びバックホールリンクのデータ通信をレイヤ２において統合及び多重化し、バックホールリンクのデータ通信に動的に無線リソースを割り当て、中継の経路を動的に切り替えることが可能である。なお、アクセスリンク及びバックホールリンクには、ミリ波帯が用いられてもよい。また、アクセスリンク及びバックホールリンクは、時分割及び／又は周波数分割により多重化されてもよい。

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

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

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

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

（ＩＡＢノードの構成）
本実施形態に係るＩＡＢノード３００の構成について説明する。図３は、ＩＡＢノード３００の構成を示す図である。図３に示すように、ＩＡＢノード３００は、無線通信部３１０と、制御部３２０とを備える。

無線通信部３１０は、ｇＮＢ２００との無線通信（バックホールリンク）及びＵＥ１００との無線通信（アクセスリンク）に用いられる。無線通信部３１０は、受信部３１１及び送信部３１２を備える。受信部３１１は、制御部３２０の制御下で各種の受信を行う。受信部３１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部３２０に出力する。送信部３１２は、制御部３２０の制御下で各種の送信を行う。送信部３１２はアンテナを含み、制御部３２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

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

（ＵＥの構成）
本実施形態に係るＵＥ１００の構成について説明する。図４は、ＵＥ１００の構成を示す図である。図４に示すように、ＵＥ１００は、無線通信部１１０と、制御部１２０とを備える。

無線通信部１１０は、アクセスリンクにおける無線通信、すなわち、ｇＮＢ２００との無線通信及びＩＡＢノード３００との無線通信に用いられる。無線通信部１１０は、受信部１１１及び送信部１１２を備える。受信部１１１は、制御部１２０の制御下で各種の受信を行う。受信部１１１はアンテナを含み、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１２０に出力する。送信部１１２は、制御部１２０の制御下で各種の送信を行う。送信部１１２はアンテナを含み、制御部１２０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。

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

（プロトコルスタック構成の一例）
本実施形態に係る移動通信システム１におけるプロトコルスタック構成の一例について説明する。図５は、ユーザプレーンのプロトコルスタック構成の一例を示す図である。ここでは、図１に示したＵＥ１００－３と５ＧＣ１０のＵＰＦ１２との間のユーザデータ伝送に関するプロトコルスタック構成の一例について説明する。

図５に示すように、ＵＰＦ１２は、ＧＴＰ－Ｕ（ＧＰＲＳＴｕｎｎｅｌｉｎｇＰｒｏｔｏｃｏｌｆｏｒＵｓｅｒＰｌａｎｅ）と、ＵＤＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ）と、ＩＰ（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）と、レイヤ１／レイヤ２（Ｌ１／Ｌ２）とを備える。ｇＮＢ２００－１（ドナーｇＮＢ）には、これらに対応するプロトコルスタックが設けられる。

また、ｇＮＢ２００－１は、集約ユニット（ＣＵ：ＣｅｎｔｒａｌＵｎｉｔ）と分散ユニット（ＤＵ：ＤｉｓｔｒｉｂｕｔｅｄＵｎｉｔ）とを備える。無線インターフェイスのプロトコルスタックのうちＰＤＣＰ（ＰａｃｋｅｔＤａｔａＣｏｎｖｅｒｇｅｎｃｅＰｒｏｔｏｃｏｌ）以上の各レイヤをＣＵが有し、ＲＬＣ（ＲａｄｉｏＬｉｎｋＣｏｎｔｒｏｌ）以下の各レイヤをＤＵが有し、Ｆ１インターフェイスと称されるインターフェイスを介してＣＵ及びＤＵが接続される。

具体的には、ＣＵは、ＳＤＡＰ（ＳｅｒｖｉｃｅＤａｔａＡｄａｐｔａｔｉｏｎＰｒｏｔｏｃｏｌ）と、ＰＤＣＰと、ＩＰと、Ｌ１／Ｌ２とを備える。ＣＵのＳＤＡＰ及びＰＤＣＰは、ＤＵと、ＩＡＢノード３００－１と、ＩＡＢノード３００－２とを介して、ＵＥ１００のＳＤＡＰ及びＰＤＣＰとの通信を行う。

また、ＤＵは、無線インターフェイスのプロトコルスタックのうち、ＲＬＣと、アダプテーションレイヤ（Ａｄａｐｔ）と、ＭＡＣ（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ）と、ＰＨＹ（Ｐｈｙｓｉｃａｌｌａｙｅｒ）とを有する。これらのプロトコルスタックは、ｇＮＢ向けのプロトコルスタックである。なお、アダプテーションレイヤ及びＲＬＣ（Ｓ－ＲＬＣ）は上下関係が逆であってもよい。

ＩＡＢノード３００－１には、これらに対応するＵＥ向けのプロトコルスタックＳＴ１が設けられる。さらに、ＩＡＢノード３００－１には、ｇＮＢ向けのプロトコルスタックＳＴ２が設けられる。プロトコルスタックＳＴ１及びプロトコルスタックＳＴ２は、何れもレイヤ２以下の各レイヤ（各サブレイヤ）からなる。すなわち、ＩＡＢノード３００－１は、レイヤ２以下の各レイヤを用いてユーザデータの中継を行うレイヤ２中継装置である。ＩＡＢノード３００－１は、レイヤ３以上のレイヤ（具体的には、ＰＤＣＰ以上のレイヤ）を用いることなくデータ中継を行う。なお、ＩＡＢノード３００－２は、ＩＡＢノード３００－１と同様なプロトコルスタック構成を有する。

ここではユーザプレーンにおけるプロトコルスタック構成について説明した。しかしながら、制御プレーンにおいて、ｇＮＢ２００－１、ＩＡＢノード３００－１、ＩＡＢノード３００－２、及びＵＥ１００－３のそれぞれは、レイヤ３に相当するＲＲＣ（ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｔｒｏｌ）を備える。

ｇＮＢ２００－１（ドナーｇＮＢ）のＲＲＣとＩＡＢノード３００－１のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。また、ｇＮＢ２００－１のＲＲＣとＩＡＢノード３００－２のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。さらに、ｇＮＢ２００－１のＲＲＣとＵＥ１００－３のＲＲＣとの間にＲＲＣ接続が確立され、このＲＲＣ接続を用いてＲＲＣメッセージが送受信される。

（移動通信システムにおける動作）
本実施形態に係る移動通信システム１における動作について説明する。具体的には、ＩＡＢノード３００－１がｇＮＢ２００－１（ドナーｇＮＢ）に無線で接続する場合の動作について説明する。

かかる場合、最初に、ＩＡＢノード３００－１は、ＵＥ機能を用いてｇＮＢ２００－１とのアクセスリンク接続（第１の無線接続）を確立する。言い換えると、ＩＡＢノード３００－１は、ＵＥ１００として振る舞ってｇＮＢ２００－１とのアクセスリンク接続を確立する。アクセスリンク接続の確立は、ＲＲＣ接続の確立を含む。

次に、ｇＮＢ２００－１は、アクセスリンク接続を維持しつつ、ＩＡＢノード３００－１のｇＮＢ機能のためのバックホールリンク接続（第２の無線接続）をＩＡＢノード３００－１とｇＮＢ２００－１との間に確立させるメッセージをＩＡＢノード３００－１に送信する。本実施形態において、かかるメッセージは、ＲＲＣ接続を用いて送受信されるＲＲＣ再設定（ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージである。

その結果、バックホールリンク接続がＩＡＢノード３００－１とｇＮＢ２００－１との間に確立されるため、ＩＡＢノード３００－１とｇＮＢ２００－１との間でバックホールリンクの通信を適切に開始可能とすることができる。

バックホールリンク接続を確立させるＲＲＣ再設定メッセージは、バックホールリンク接続を構成するベアラ（又はＬ２リンク）の設定情報、及びＩＡＢノード３００－１が送信するべきセルＩＤ（具体的には、セルＩＤに関連付けられた参照信号及び同期信号の送信設定）を含んでもよい。以下において、かかるＲＲＣ再設定メッセージをＩＡＢノード設定メッセージと称する。

ＩＡＢノード設定メッセージは、デフォルトベアラ（又はデフォルトリンク）の設定情報を含んでもよい。デフォルトベアラ（又はデフォルトリンク）は、例えば、ＳＩＢ（ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ）の中継やＵＥからのＭｓｇ３中継などを行うためのベアラ（又はリンク）である。

ＩＡＢノード設定メッセージは、ドナーｇＮＢ２００－１側のスタックの設定情報と、オプションでＩＡＢノード３００－２（又はＵＥ１００）側のスタックの設定情報とを含んでもよい。ＩＡＢノード３００－２（又はＵＥ１００）側のスタックの設定情報は、暗示的にドナーｇＮＢ２００－１のＳＩＢで報知されている設定群を再利用してもよいし、オペレータ（ＯＡＭ）から（事前に）設定されてもよい。

ＩＡＢノード設定メッセージにおける設定内容としては、基本的にＲＲＣ再設定メッセージに含まれる設定全てが対象になり得るが、ＲＬＣ設定（ＡＭ：ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ／ＵＭ：ＵｎａｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ／ＴＭ：ＴｒａｎｓｐａｒｅｎｔＭｏｄｅ等の動作モード、ＬＣＰ（ＬｏｇｉｃａｌＣｈａｎｎｅｌＰｒｉｏｒｉｔｉｚａｔｉｏｎ）パラメータ等）、ＭＡＣ設定（ＢＳＲ：ＢｕｆｆｅｒＳｔａｔｕｓＲｅｐｏｒｔ／ＴＡＧ：ＴｉｍｉｎｇＡｄｖａｎｃｅＧｒｏｕｐ／ＰＨＲ：ＰｏｗｅｒＨｅａｄｒｏｏｍパラメータ、ＤＲＸ：ＤｉｓｃｏｎｔｉｎｕｅｓＲｅｃｅｐｔｉｏｎ設定等）、ＰＨＹ設定が含まれてもよい。

また、ＩＡＢノード設定メッセージにおける設定内容には、アダプテーションレイヤの設定（下位側又は上位側の論理チャネルのマッピング（ルーティング）設定、優先度設定等）が含まれてもよい。

さらに、ＩＡＢノード設定メッセージにおける設定内容には、必要に応じて、ＩＡＢノード３００－１の（仮想的な）ＩＰアドレス（すなわち、Ｌ３アドレス）を含めてもよい。これは、例えばＦ１インターフェイスをＬ２リンク上に確立するために、Ｆ１のプロトコルスタックがＳＣＴＰｏｖｅｒＩＰを想定しているためである。

なお、ＩＡＢノード設定メッセージにおける設定内容は、ＮＲプロトコルの設定情報に限らず、ＬＴＥプロトコル（ＲＬＣ、ＭＡＣ、ＰＨＹ）の設定情報であってもよい。

本実施形態において、ＩＡＢノード３００－１は、バックホールリンク接続を確立するよりも前に、ＩＡＢノードの機能（すなわち、レイヤ２中継機能）を有すること又はバックホールリンク接続の確立を要求することを示すインディケーションをｇＮＢ２００－１に送信してもよい。これにより、ｇＮＢ２００－１は、バックホールリンク接続を確立するためのプロシージャを適切に開始できる。以下において、かかるインディケーションをＩＡＢインディケーションと称する。ＩＡＢインディケーションは、ＩＡＢノード３００－１におけるＵＥ機能向けリンクプロトコルスタックをＬＴＥで準備するのか、ＮＲで準備するのか、もしくはその両方か、という意図又は能力を示す情報を含んでもよい。

なお、ＩＡＢノード３００－１は、ｇＮＢ２００－１とのアクセスリンク接続の確立後にＩＡＢインディケーションを送信してもよいし、ｇＮＢ２００－１とのアクセスリンク接続を確立するプロシージャ中にＩＡＢインディケーションを送信してもよい。

また、ＩＡＢインディケーションをｇＮＢに送信可能とする条件として、このｇＮＢから、ドナー機能を有することを示すドナー機能識別子を含むＳＩＢを受信しているという条件があってもよい。かかる場合、ＩＡＢノード３００－１は、ｇＮＢ２００－１からＳＩＢによりドナー機能識別子を受信している場合に限り、ｇＮＢ２００－１に対してＩＡＢインディケーションを送信する。

本実施形態において、ＩＡＢノード３００－１とのバックホールリンク接続を確立するドナー機能をｇＮＢ２００－１が有する場合、ｇＮＢ２００－１は、ＩＡＢノード３００－１からＩＡＢインディケーションを受信した後、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信する。一方、ドナー機能をｇＮＢ２００－１が有しない場合、ｇＮＢ２００－１は、ＩＡＢノード３００－１からＩＡＢインディケーションを受信した後、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信することに代えて、ＩＡＢノード３００－１のハンドオーバを要求するハンドオーバ要求を他のｇＮＢに送信してもよい。ここで、ｇＮＢ２００－１は、ドナー機能を有する他のｇＮＢの情報を予め記憶していることが好ましい。ｇＮＢ２００－１は、ドナー機能を有する他のｇＮＢの情報をＩＡＢノード３００－１から取得してもよい。ＩＡＢノード３００－１は、５ＧＣ１０（コアネットワーク）から情報を入手、もしくは隣接セルのＳＩＢ（ドナー機能識別子）を確認することにより、ドナー機能を有する他のｇＮＢ（隣接セル）の情報を取得し、取得した情報をｇＮＢ２００－１に通知する。ｇＮＢ２００－１は、記憶している情報又はＩＡＢノード３００－１から取得した情報に基づいて、ドナー機能を有する他のｇＮＢに対してハンドオーバ要求を送信する。これにより、ＩＡＢノード３００－１を他のｇＮＢにハンドオーバさせた後に、ＩＡＢノード３００－１が当該他のｇＮＢとのバックホールリンク接続を確立できる。或いは、ドナー機能をｇＮＢ２００－１が有しない場合、ＩＡＢノード３００－１は、５ＧＣ１０に対して、ドナー機能を有するセル（ｇＮＢ）へハンドオーバさせることを要求し、５ＧＣ１０がハンドオーバに係る処理を行ってもよい。

本実施形態において、ｇＮＢ２００－１は、ＩＡＢノード３００－１からＩＡＢインディケーションを受信したことに応じて、無線測定を設定する測定設定をＩＡＢノード３００－１に送信してもよい。ＩＡＢノード３００－１は、ｇＮＢ２００－１から測定設定を受信した後、無線測定の結果を含む測定報告をｇＮＢ２００－１に送信する。ｇＮＢ２００－１は、ＩＡＢノード３００－１からの測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。例えば、ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）に対する測定結果よりも他のｇＮＢに対する測定結果が良好であり、かつ、これらの測定報告の差が閾値よりも大きい場合に、他のｇＮＢが適切なドナーｇＮＢであると判断する。そうでなければ、ｇＮＢ２００－１は、自身が適切なドナーｇＮＢであると判断する。

そして、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢ２００－１であると判断した場合、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信する。一方、他のｇＮＢが適切なドナーｇＮＢであると判断した場合、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージをＩＡＢノード３００－１に送信することに代えて、ＩＡＢノード３００－１のハンドオーバを要求するハンドオーバ要求を当該他のｇＮＢに送信する。これにより、ＩＡＢノード３００－１をより無線状態の良好な他のｇＮＢにハンドオーバさせて、ＩＡＢノード３００－１が当該他のｇＮＢとのバックホールリンク接続を確立できる。

本実施形態において、ｇＮＢ２００－１は、バックホールリンク接続の確立後、ＩＡＢノード３００－１に関するコンテキスト情報を他のｇＮＢに送信してもよい。このコンテキスト情報は、無線側のＡＳレイヤの接続設定（ＲＲＣ再設定の内容）、ネットワーク側のＰＤＵセッションリソース設定（ＡＭＦ又はＲＡＮ（ＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）のＵＥＩＤ、セッションＩＤ、ＱｏＳ（ＱｕａｌｉｔｙｏｆＳｅｒｖｉｃｅ）／スライス設定等）、その他関連情報（ＩＡＢノードの挙動や通信などの履歴情報、プリファレンス情報などを含む。

具体的には、ｇＮＢ２００－１は、ＩＡＢノード３００－１を他のｇＮＢにハンドオーバさせるという判断を行っていなくても、ＩＡＢノード３００－１に関するコンテキスト情報を予め他のｇＮＢに送信する。これにより、ｇＮＢ２００－１とＩＡＢノード３００－１との間の無線状態が悪化し、ＩＡＢノード３００－１が他のｇＮＢとの無線接続を再確立する場合に、予め共有したコンテキスト情報を用いて速やかな再確立を行うことができる。

ここで、ｇＮＢ２００－１は、ＩＡＢノード３００－１とＩＡＢノード３００－１のドナーｇＮＢの候補とを対応付けるテーブルを保持していることが好ましい。ｇＮＢ２００－１は、テーブル中の候補である他のｇＮＢに対してコンテキスト情報を送信する。これにより、ｇＮＢ２００－１は、コンテキスト情報を適切な他のｇＮＢと共有できる。

（１）通常動作シーケンスの一例
図６は、本実施形態に係る移動通信システム１における通常動作シーケンスの一例を示す図である。

図６に示すように、ステップＳ１０１において、ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００－１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００－１は、ランダムアクセスプロシージャ中にｇＮＢ２００－１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００－１は、ステップＳ１０１において、ＩＡＢノード３００－１に関するコンテキスト情報を取得する。

ステップＳ１０２において、ＩＡＢノード３００－１は、ｇＮＢ２００－１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。ここで、ＩＡＢノード３００－１は、ＩＡＢインディケーションのような通知（つまり、ＩＡＢノードとして動作したいことを示す通知）をＡＭＦ１１に通知してもよい。これにより、ＩＡＢノード３００－１は、ＡＭＦ１１から、ドナーｇＮＢ（セル）の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、ＡＭＦ１１からドナーｇＮＢの各候補に対して、ＩＡＢノード３００－１のアタッチがあった旨や、ＩＡＢノード３００－１のルーティング情報などのコンテキスト情報を通知してもよい。なお、ＩＡＢノード３００－１が既にアタッチしている場合は、ステップＳ１０２におけるアタッチ処理を省略可能である。具体的には、ＩＡＢノード３００－１は、ステップＳ１０１において、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）などのように、何らかのエラー発生によってドナーｇＮＢとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。

ステップＳ１０３において、ＩＡＢノード３００－１は、ＩＡＢインディケーションをｇＮＢ２００－１に送信する。ＩＡＢノード３００－１は、次のイベントのうち１又は複数が満たされたことをトリガとしてＩＡＢインディケーションを送信してもよい。

・Ｍｓｇ５（ＲＲＣＣｏｍｐｌｅｔｅ）を送信する際。

・ｇＮＢとの接続が確立した際（Ｍｓｇ５以降でもよい。例えば最初のＲＲＣ再設定が行われた際）。

・ＡＭＦからＩＡＢ設定情報（上記参照）を入手した際（既にＩＡＢ設定情報を持っている場合も含む）。

・単純にＩＡＢノードとして動作したくなった際（上位レイヤからＩＡＢノードとして動作する指示を受信したことを含む）。

・下位のＩＡＢノード３００－２又はＵＥ１００－３からＩＡＢノードとなるように要求された場合（その旨の要求を示す信号を下位のＩＡＢノード３００－２又はＵＥ１００－３から受信した場合）。

・下位のＩＡＢノード３００－２又はＵＥ１００－３が既に接続している場合。

ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥとしての能力を示す「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ１０１においてＩＡＢインディケーションを送信している場合、ステップＳ１０３は省略可能である。

或いは、ＩＡＢインディケーションは、ＡＭＦ１１からＰＤＵセッションリソースの変更という形でｇＮＢ２００－１に通知されてもよい。なお、ＡＭＦは、ＩＡＢ管理用（専用）のＡＭＦであってもよい。

本通常動作シーケンスにおいては、ｇＮＢ２００－１がドナー能力を有すると仮定して説明を進める。ｇＮＢ２００－１は、ＩＡＢインディケーションに基づいて、バックホールリンク接続をＩＡＢノード３００－１に確立させる必要があると判断する。

ステップＳ１０４において、ｇＮＢ２００－１は、無線測定を設定する測定設定をＩＡＢノード３００－１に送信する。ＩＡＢノード３００－１は、測定設定に基づいて無線測定を行う。例えば、ＩＡＢノード３００－１は、現在のサービングセルであるｇＮＢ２００－１のセルと、隣接セルであるｇＮＢ２００－２のセルとに対して受信電力（セル固有参照信号の受信電力）の測定を行う。

ステップＳ１０５において、ＩＡＢノード３００－１は、無線測定の結果を含む測定報告をｇＮＢ２００－１に送信する。ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。ここでは、ｇＮＢ２００－１が、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであると判断したと仮定して説明を進める。なお、ステップＳ１０４及びステップＳ１０５の処理は必須ではなく、省略してもよい。

ステップＳ１０６において、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００－１に送信する。ＩＡＢノード設定メッセージは、ｇＮＢ２００－１のセル（すなわち、ＩＡＢノード３００－１の現在のサービングセル）をハンドオーバ先として指定するハンドオーバ指示を含んでもよい。ＩＡＢノード３００－１は、ＩＡＢノード設定メッセージに基づいて、バックホールリンク接続をｇＮＢ２００－１と確立する処理を行う。かかる確立処理は、ＩＡＢノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック（アダプテーション／ＲＬＣ／ＭＡＣ／ＰＨＹエンティティ）を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、ＵＥ側（のアクセスリンク用）のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理（もしくは、開始する準備をする処理）を含んでもよい。

ステップＳ１０７において、ＩＡＢノード３００－１は、バックホールリンク接続の確立を含むＩＡＢノード設定が完了したことを示す完了通知メッセージをｇＮＢ２００－１に送信する。ステップＳ１０７以降は、ＩＡＢノード３００－１はｇＮＢ２００－１に対してＵＥとして振る舞うのではなく、ＩＡＢノードとして振る舞う。

ステップＳ１０８において、ｇＮＢ２００－１は、ステップＳ１０１において取得したコンテキスト情報を、Ｘｎインターフェイス上でｇＮＢ２００－２に転送する。ｇＮＢ２００－１は、ＩＡＢノード３００－１とＩＡＢノード３００－１のドナーｇＮＢの候補とを対応付けるテーブルを保持しており、このテーブルを参照してコンテキスト転送先を決定する。このようにして、ｇＮＢ２００－１が、他のｇＮＢに対してコンテキストを事前に転送しておけば、ＩＡＢノード３００－１と接続しているｇＮＢとの無線接続状態が悪化した場合に、直ぐに、当該他のｇＮＢとの再接続を確立することができる。図７は、コンテキスト転送先を決定するためのテーブルの一例を示す図である。かかるテーブルは、例えばオペレータにより各ｇＮＢに対して予め設定される。図７に示すように、テーブルにおいて、ＩＡＢノードごとに、そのドナーｇＮＢの候補が対応けられている。具体的には、ＩＡＢノードに関する識別子ごとに、そのドナーｇＮＢの候補の識別子が対応けられている。例えば、ＩＡＢノードに地理的に近いｇＮＢがそのＩＡＢノードのドナーｇＮＢの候補として設定される。なお、ｇＮＢとの対応付けの例を示したが、セルＩＤとの対応付けであってもよい。セルＩＤは、物理レイヤセルＩＤでもよく、グローバルセルＩＤでもよい。なお、ｇＮＢ２００－１は、ＩＡＢノード３００－１から受信した測定報告に基づいて、ＩＡＢノード３００－１に地理的に近いｇＮＢ２００－１をドナー候補として決定してもよい。ｇＮＢ２００－１は、当該決定したドナー候補に基づいて、ＩＡＢノード３００－１と当該ＩＡＢノード３００－１のドナーｇＮＢの候補とを対応付けるテーブルを作成又は既存のテーブルを更新してもよい。

ステップＳ１０９において、ｇＮＢ２００－１は、ＩＡＢノード３００－１とのバックホールリンク接続を確立したことを示す通知を５ＧＣ１０に送信する。もしくは、ｇＮＢ２００－１は、ＩＡＢノード用のＰＤＵセッションの確立要求を５ＧＣ１０に送信してもよい。なお、上述したように、ＰＤＵセッションの確立要求は、ステップＳ１０９よりも先に又はステップＳ１０９においてＡＭＦ１１からｇＮＢ２００－１に送信されてもよい。

（２）例外動作シーケンスの一例
図８は、本実施形態に係る移動通信システム１における例外動作シーケンスの一例を示す図である。例外動作シーケンスにおいて、ｇＮＢ２００－１は、ＩＡＢノード３００－１をｇＮＢ２００－２にハンドオーバさせる。

図８に示すように、ステップＳ２０１において、ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００－１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００－１は、ランダムアクセスプロシージャ中にｇＮＢ２００－１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００－１は、ステップＳ２０１において、ＩＡＢノード３００－１に関するコンテキスト情報を取得する。

ステップＳ２０２において、ＩＡＢノード３００－１は、ｇＮＢ２００－１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。

ステップＳ２０３において、ＩＡＢノード３００－１は、ＩＡＢインディケーションをｇＮＢ２００－１に送信する。ＩＡＢノード３００－１は、例えばｇＮＢ２００－１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥの能力を示す「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ２０１においてＩＡＢインディケーションを送信している場合、ステップＳ２０３は省略可能である。

ステップＳ２０４において、ｇＮＢ２００－１は、自身がドナー能力を有するか否かを判断する。ｇＮＢ２００－１がドナー能力を有しない場合（ステップＳ２０４：ＮＯ）、ｇＮＢ２００－１は、処理をステップＳ２０８に進める。

ｇＮＢ２００－１がドナー能力を有する場合（ステップＳ２０４：ＹＥＳ）、ステップＳ２０５において、ｇＮＢ２００－１は、無線測定を設定する測定設定をＩＡＢノード３００－１に送信する。ＩＡＢノード３００－１は、測定設定に基づいて無線測定を行う。例えば、ＩＡＢノード３００－１は、現在のサービングセルであるｇＮＢ２００－１のセルと、隣接セルであるｇＮＢ２００－２のセルとに対して受信電力（セル固有参照信号の受信電力）の測定を行う。

ステップＳ２０６において、ＩＡＢノード３００－１は、無線測定の結果を含む測定報告をｇＮＢ２００－１に送信する。

ステップＳ２０７において、ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであると判断した場合（ステップＳ２０７：ＹＥＳ）、ｇＮＢ２００－１は、上述した通常動作シーケンス（図６参照）のステップＳ１０６に処理を進める。

一方、他のｇＮＢが適切なドナーｇＮＢであると判断した場合（ステップＳ２０７：ＮＯ）、ｇＮＢ２００－１は、ステップＳ２０８に処理を進める。

ステップＳ２０８において、ｇＮＢ２００－１は、ＩＡＢノード３００－１から受信したＩＡＢインディケーションを含むハンドオーバ要求メッセージをＸｎインターフェイス上でｇＮＢ２００－２に転送する。ｇＮＢ２００－１は、ステップＳ２０１において取得したコンテキスト情報をハンドオーバ要求メッセージに含めてもよい。または、ｇＮＢ２００－１は、ハンドオーバ要求メッセージに、ＩＡＢインディケーションを含める代わりに、ＩＡＢノード３００－１がｇＮＢに対してドナーｇＮＢとして機能することを要求する旨を示す情報を含めて送信してもよい。なお、ステップＳ２０８において、ｇＮＢ２００－１は、ｇＮＢ２００－２がドナー能力を有すると判断した上で、ハンドオーバ要求メッセージをＸｎインターフェイス上でｇＮＢ２００－２に転送してもよい。具体的には、例えば、ｇＮＢ２００－１は、図７に示すテーブルにおいて、ＩＡＢノード３００－１にドナー候補としてｇＮＢ２００－２が対応付けられていると判断した場合に、ハンドオーバ要求メッセージをｇＮＢ２００－２に対して転送してもよい。この場合、ｇＮＢ２００－２がハンドオーバ要求を拒否する可能性が低減されるため、ＩＡＢノード３００－１のハンドオーバをより早急に実行することができる。または、互いに隣接する複数のｇＮＢ２００間でＸｎインターフェイスを介して、自身のドナー能力に関する情報を事前に共有してもよい。これによって、ｇＮＢ２００－１は、ドナー能力を有する隣接のｇＮＢ２００を特定することができ、当該特定した隣接のｇＮＢ２００に対してハンドオーバ要求メッセージを転送することができる。

ｇＮＢ２００－２は、ハンドオーバ要求メッセージに含まれるＩＡＢインディケーションも考慮して、ＩＡＢノード３００－１のハンドオーバを受け入れるか否かを判断する。ｇＮＢ２００－２は、自身がドナー能力を有しない場合には、ハンドオーバ要求を拒否してもよい。ここではｇＮＢ２００－２がＩＡＢノード３００－１のハンドオーバを受け入れると判断したと仮定して説明を進める。

ステップＳ２０９において、ｇＮＢ２００－２は、ハンドオーバ肯定応答メッセージをＸｎインターフェイス上でｇＮＢ２００－１に送信する。

ステップＳ２１０において、ｇＮＢ２００－１は、ｇＮＢ２００－２からのハンドオーバ肯定応答メッセージに基づいて、ハンドオーバ指示メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００－１に送信する。ハンドオーバ指示メッセージは、ハンドオーバ先のｇＮＢ２００－２（のセル）を指定する情報を含む。

ステップＳ２１１において、ＩＡＢノード３００－１は、ｇＮＢ２００からのハンドオーバ指示メッセージに基づいて、ｇＮＢ２００－２へのハンドオーバを行う。

（３）マルチホップ接続シーケンスの一例
図９は、本実施形態に係る移動通信システム１におけるマルチホップ接続シーケンスの一例を示す図である。マルチホップ接続シーケンスは、ＩＡＢノード３００－１とｇＮＢ２００－１との間にバックホールリンク接続が接続された後において、ＩＡＢノード３００－１にＩＡＢノード３００－２又はＵＥ１００－２が接続する場合のシーケンスである。ここではＩＡＢノード３００－１にＩＡＢノード３００－２が接続する場合について主として説明するが、ＩＡＢノード３００－２をＵＥ１００－２と適宜読み替えてもよい。また、上述した「（１）通常動作シーケンス」と重複する説明を省略する。

図９に示すように、ステップＳ３０１において、ＩＡＢノード３００－２は、ＩＡＢノード３００－１を介してｇＮＢ２００－１に対してランダムアクセスプロシージャを行うことにより、ｇＮＢ２００－１とのアクセスリンク接続（ＲＲＣ接続）を確立する。ＩＡＢノード３００－２は、ランダムアクセスプロシージャ中にｇＮＢ２００－１に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含めてもよい。また、ｇＮＢ２００－１は、ステップＳ３０１において、ＩＡＢノード３００－２に関するコンテキスト情報を取得する。

ステップＳ３０２において、ＩＡＢノード３００－２は、ＩＡＢノード３００－２及びｇＮＢ２００－１を介して、５ＧＣ１０（具体的には、ＡＭＦ１１）に対するアタッチプロシージャを行う。ここで、ＩＡＢノード３００－２は、ＩＡＢインディケーションのような通知（つまり、ＩＡＢノードとして動作したいことを示す通知）をＡＭＦ１１に通知してもよい。これにより、ＩＡＢノード３００－２は、ＡＭＦ１１から、ドナーｇＮＢ（セル）の候補リストや下位ノードの有無などのルーティング情報、その他管理情報などを入手してもよい。もしくは、ＡＭＦ１１からドナーｇＮＢの各候補に対して、ＩＡＢノード３００－２のアタッチがあった旨や、ＩＡＢノード３００－２のルーティング情報などのコンテキスト情報を通知してもよい。なお、ＩＡＢノード３００－２が既にアタッチしている場合は、ステップＳ３０２におけるアタッチ処理を省略可能である。具体的には、ＩＡＢノード３００－２は、ＲＲＣ再確立（Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ）などのように、何らかのエラー発生によってドナーｇＮＢとの接続を再確立しなければならない場合などにおいて、アタッチ処理を省略する。

ステップＳ３０３において、ＩＡＢノード３００－２は、ＩＡＢノード３００－１を介してＩＡＢインディケーションをｇＮＢ２００－１に送信する。ＩＡＢノード３００－２は、上述した「（１）通常動作シーケンス」のステップＳ１０３において説明したトリガと同様なトリガに応じてＩＡＢインディケーションを送信してもよい。

ＩＡＢノード３００－２は、例えばｇＮＢ２００－１に送信するＲＲＣメッセージにＩＡＢインディケーションを含める。かかるＲＲＣメッセージは、ＵＥとしての能力を示す「ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ」メッセージであってもよい。但し、ステップＳ３０１においてＩＡＢインディケーションを送信している場合、ステップＳ３０３は省略可能である。

本動作シーケンスにおいては、ｇＮＢ２００－１がドナー能力を有すると仮定しているため、ｇＮＢ２００－１は、ＩＡＢインディケーションに基づいて、バックホールリンク接続をＩＡＢノード３００－１とＩＡＢノード３００－２との間に確立させる必要があると判断する。

ステップＳ３０４において、ｇＮＢ２００－１は、無線測定を設定する測定設定をＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２は、測定設定に基づいて無線測定を行う。

ステップＳ３０５において、ＩＡＢノード３００－２は、無線測定の結果を含む測定報告を、ＩＡＢノード３００－１を介してｇＮＢ２００－１に送信する。ｇＮＢ２００－１は、測定報告に基づいて、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを判断する。ここでは、ｇＮＢ２００－１が、自身（ｇＮＢ２００－１）が適切なドナーｇＮＢであると判断したと仮定して説明を進める。なお、ステップＳ３０４及びステップＳ３０５の処理は必須ではなく、省略してもよい。

ステップＳ３０６において、ｇＮＢ２００－１は、ＩＡＢノード設定メッセージ（ＲＲＣ再設定メッセージ）をＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２は、ＩＡＢノード設定メッセージに基づいて、バックホールリンク接続をＩＡＢノード３００－１と確立する処理を行う。かかる確立処理は、ＩＡＢノード設定メッセージ中の設定情報に基づいて、バックホールリンク用のプロトコルスタック（アダプテーション／ＲＬＣ／ＭＡＣ／ＰＨＹエンティティ）を生成したり、パラメータ設定したりする処理を含む。かかる確立処理は、ＵＥ側（のアクセスリンク用）のプロトコルスタックを準備して、同期信号やセル固有参照信号の送信を開始する処理（もしくは、開始する準備をする処理）を含んでもよい。

ステップＳ３０７において、ｇＮＢ２００－１は、ＲＲＣ再設定メッセージをＩＡＢノード３００－１に送信する。かかるＲＲＣ再設定メッセージは、ＩＡＢノード３００－２の追加に伴ってＩＡＢノード３００－１における設定を変更するためのメッセージである。かかるＲＲＣ再設定メッセージは、例えば、ＩＡＢノード３００－２の論理チャネルとＩＡＢノード３００－１のバックホールリンクの論理チャネルとの対応付けを示すマッピング情報を含む。なお、ステップＳ３０７は、ステップＳ３０６の前であってもよいし、ステップＳ３０６と同時であってもよい。

ステップＳ３０８において、ＩＡＢノード３００－２は、ＩＡＢノード３００－１とのバックホールリンク接続の確立を含むＩＡＢノード設定が完了したことを示す完了通知メッセージをｇＮＢ２００－１に送信する。ステップＳ３０８以降は、ＩＡＢノード３００－２はｇＮＢ２００－１に対してＵＥとして振る舞うのではなく、ＩＡＢノードとして振る舞う。

ステップＳ３０９において、ＩＡＢノード３００－１は、ＩＡＢノード３００－２とのバックホールリンク接続の確立に伴う設定変更が完了したことを示す完了通知メッセージをｇＮＢ２００－１に送信する。なお、ステップＳ３０９は、ステップＳ３０８の前であってもよいし、ステップＳ３０８と同時であってもよい。

ステップＳ３１０において、ｇＮＢ２００－１は、ステップＳ３０１において取得したＩＡＢノード３００－２のコンテキスト情報を、Ｘｎインターフェイス上でｇＮＢ２００－２に転送する。

ステップＳ３１１において、ｇＮＢ２００－１は、ＩＡＢノード３００－２のバックホールリンク接続を確立したことを示す通知を５ＧＣ１０に送信する。もしくは、ｇＮＢ２００－１は、ＩＡＢノード３００－２用のＰＤＵセッションの確立要求を５ＧＣ１０に送信してもよい。なお、上述したように、ＰＤＵセッションの確立要求は、ステップＳ３１１よりも先に又はステップＳ３１１においてＡＭＦ１１からｇＮＢ２００－１に送信されてもよい。

［第１実施形態の変更例］
上述した第１実施形態において、ＩＡＢノード３００－１がｇＮＢ２００－１に無線で接続した後に、ｇＮＢ２００－１がドナー能力を有しないことに応じてＩＡＢノード３００－１をハンドオーバさせる一例について説明した。しかしながら、各ｇＮＢ２００は、自身がドナー能力を有するか否かに関する情報をＩＡＢノード３００－１に提供してもよい。これにより、ＩＡＢノード３００－１は、ドナー能力を有するｇＮＢ２００を選択したうえで接続することが可能になる。例えば、ドナー能力を有するｇＮＢ２００は、ドナー能力を有することを示す情報をシステム情報ブロック（ＳＩＢ）に含めてブロードキャストする。ＩＡＢノード３００－１は、かかるＳＩＢに基づいて、接続先とするｇＮＢ２００を選択する。ＩＡＢノード３００－１は、ドナー能力を有するｇＮＢ２００であって、且つ、このｇＮＢ２００からの受信電力が閾値以上である場合に、このｇＮＢ２００を接続先として選択してもよい。または、ｇＮＢ２００がドナー能力を有しない場合には、ＩＡＢノード３００－１は、ｇＮＢ２００から送信されたＳＩＢを受信したことに応じて、他のｇＮＢ２００を再選択してもよい。その後、他のｇＮＢ２００から送信されたＳＩＢにより当該他のｇＮＢ２００がドナー能力を有することが示される場合には、ＩＡＢノード３００－１は、当該他のｇＮＢ２００を接続先として、ランダムアクセスプロシージャを行うと共にＩＡＢインディケーションを送信してもよい。

或いは、各ｇＮＢ２００は、自身がドナー能力を有することをＳＩＢにより通知することに加えて、又は自身がドナー能力を有することをＳＩＢにより通知することに代えて、自身がＩＡＢノード３００を取り扱う能力を有することをＳＩＢにより通知してもよい。例えば、各ｇＮＢ２００は、自身がＩＡＢノード３００を他のｇＮＢ（ドナーｇＮＢ）にハンドオーバする機能を有することをＳＩＢにより通知してもよい。

上述した第１実施形態において、ＩＡＢノード３００がランダムアクセスプロシージャ中にｇＮＢ２００に送信するメッセージ（例えば、Ｍｓｇ３）にＩＡＢインディケーションを含める一例について説明した。ここで、Ｍｓｇ３は、例えばＲＲＣＳｅｔｕｐＲｅｑｕｅｓｔメッセージである。また、ＩＡＢノード３００は、Ｍｓｇ３中のフィールド（情報要素）であるＥｓｔａｂｌｉｓｈｍｅｎｔＣａｕｓｅにＩＡＢインディケーションを含めてもよい。

或いは、ＩＡＢノード３００は、ランダムアクセスプロシージャ中にｇＮＢ２００に送信するランダムアクセスプリアンブル（Ｍｓｇ１）を利用して、ＩＡＢインディケーションを通知してもよい。例えば、ＩＡＢインディケーション用のＰＲＡＣＨ（ＰｈｙｓｉｃａｌＲａｎｄｏｍＡｃｃｅｓｓＣｈａｎｎｅｌ）リソースがＳＩＢにより通知される場合、ＩＡＢノード３００は、通知されたＩＡＢインディケーション用のＰＲＡＣＨリソースの中から選択したＰＲＡＣＨリソースを用いてランダムアクセスプリアンブルを送信することにより、ＩＡＢインディケーションを通知してもよい。ここで、ＰＲＡＣＨリソースとは、時間・周波数リソースであってもよいし、信号系列（プリアンブル系列）であってもよい。

或いは、ＩＡＢノード３００は、ランダムアクセスプロシージャ以外のタイミングでＩＡＢインディケーションを通知してもよい。例えば、ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎメッセージ等のＲＲＣメッセージにＩＡＢインディケーションを含めてもよい。

上述した第１実施形態において、ｇＮＢ２００が、無線測定を設定する測定設定をＩＡＢノード３００又はＵＥ１００に送信し、無線測定の結果を含む測定報告を受信することにより、自身（ｇＮＢ２００）が適切なドナーｇＮＢであるか又は他のｇＮＢが適切なドナーｇＮＢであるかを当該測定報告に基づいて判断する一例について説明した。しかしながら、このような初期接続時に測定結果を利用する場合に限らず、ネットワークトポロジの変更やデータ転送経路の変更に測定報告を利用してもよい。

［第２実施形態］
第２実施形態について、上述した第１実施形態との相違点を主として説明する。第２実施形態は、ＡＭ（ＡｃｋｎｏｗｌｅｄｇｅｄＭｏｄｅ）のＲＬＣレイヤにおける自動再送制御（ＡＲＱ：ＡｕｔｏｍａｔｉｃＲｅｐｅａｔｒｅＱｕｅｓｔ）に着目した実施形態である。

ＵＥ１００とｇＮＢ（ドナーｇＮＢ）２００との間の通信にＩＡＢノード３００が介在する場合、ＡＲＱを「ｅｎｄ－ｔｏ－ｅｎｄ」で行う方法とＡＲＱを「ｈｏｐ－ｂｙ－ｈｏｐ」で行う方法とがある。なお、本実施形態において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。

図１０は、「ｅｎｄ－ｔｏ－ｅｎｄ」の一例を示す図である。

図１０に示すように、ＡＲＱを「ｅｎｄ－ｔｏ－ｅｎｄ」で行う場合、ＵＥ１００の送信側ＲＬＣエンティティ１２は、ＩＡＢノード３００を介して上りリンクデータをｇＮＢ２００の受信側ＲＬＣエンティティ３２に送信するとともに、当該上りリンクデータを保持する。この上りリンクデータが伝送中に消失すると、当該上りリンクデータを受信失敗したことを示すＮａｃｋ（ｎｅｇａｔｉｖｅａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をｇＮＢ２００の受信側ＲＬＣエンティティ３２がＩＡＢノード３００を介してＵＥ１００の送信側ＲＬＣエンティティ１２に送信する。ＵＥ１００の送信側ＲＬＣエンティティ１２は、Ｎａｃｋの受信に応じて、保持している上りリンクデータを再送する。

一方、ｇＮＢ２００の受信側ＲＬＣエンティティ３２が上りリンクデータの受信に成功すると、当該上りリンクデータを受信成功したことを示すＡｃｋ（ｐｏｓｉｔｉｖｅａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をｇＮＢ２００の受信側ＲＬＣエンティティ３２がＩＡＢノード３００を介してＵＥ１００の送信側ＲＬＣエンティティ１２に送信する。但し、ｇＮＢ２００の受信側ＲＬＣエンティティ３２は、ＵＥ１００の送信側ＲＬＣエンティティ１２からの要求（ＳｔａｔｕｓＰＤＵ）に応じてＡｃｋを送信してもよい。具体的には、Ａｃｋは、複数ＰＤＵ分をまとめて送ることができるようになっているため、受信成功したら直ぐにＡｃｋを返す訳ではない。ＵＥ１００の送信側ＲＬＣエンティティ１２は、Ａｃｋの受信に応じて、保持している上りリンクデータを破棄するとともに、ＵＥ１００のＰＤＣＰエンティティ１３にデータ送信成功を通知する。なお、Ａｃｋは、１つのＰＤＵの受信に成功するごとに返してもよい。

なお、ＲＬＣエンティティが送信するデータは「ＲＬＣｄａｔａＰＤＵ（ＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）」と称され、特にＡＭのＲＬＣエンティティが送信するデータは「ＡＭＤ（ＡＭＤａｔａ）ＰＤＵ」と称される。また、ＡＭＤＰＤＵの送信側は「ｔｒａｎｓｍｉｔｔｉｎｇＡＭＲＬＣｅｎｔｉｔｙ」と称され、ＡＭＤＰＤＵの受信側は「ｒｅｃｅｉｖｉｎｇＡＭＲＬＣｅｎｔｉｔｙ」と称される。Ａｃｋ及びＮａｃｋは、「ＳＴＡＴＵＳＰＤＵ」と称されるＰＤＵに含まれる。「ＳＴＡＴＵＳＰＤＵ」は、「ＲＬＣｃｏｎｔｒｏｌＰＤＵ」の一種である。

このように、ＵＥ１００とｇＮＢ２００との間の通信にＩＡＢノード３００が介在する場合であっても、ＡＲＱを「ｅｎｄ－ｔｏ－ｅｎｄ」で行うことにより、データ転送経路上において消失したデータが再送により受信側に伝達されることを保証できる。

一方で、ＡＲＱを、「ｅｎｄ－ｔｏ－ｅｎｄ」ではなく、「ｈｏｐ－ｂｙ－ｈｏｐ」で行う場合、データ転送経路上でデータが消失すると、消失したデータを再送できないことがある。

図１１は、「ｈｏｐ－ｂｙ－ｈｏｐ」の一例を示す図である。

図１１に示すように、ＵＥ１００とＩＡＢノード３００との間のＡＲＱ＃１と、ＩＡＢノード３００とｇＮＢ２００との間のＡＲＱ＃２とが個別に行われる。先ず、ＵＥ１００の送信側ＲＬＣエンティティ１２がＩＡＢノード３００の受信側ＲＬＣエンティティ２２Ｒに上りリンクデータを送信し、且つ、ＩＡＢノード３００の受信側ＲＬＣエンティティ２２ＲがＵＥ１００の送信側ＲＬＣエンティティ１２にＡｃｋを送信すると、ＵＥ１００の送信側ＲＬＣエンティティ１２は当該上りリンクデータについて送信成功と判断する。ＵＥ１００のＰＤＣＰエンティティ１３は、送信側ＲＬＣエンティティ１２が送信成功と判断した上りリンクデータについては、ＰＤＣＰＤａｔａＲｅｃｏｖｅｒｙ処理における再送対象から外す（破棄してもよい）。

次に、ＩＡＢノード３００の送信側ＲＬＣエンティティ２２ＴがｇＮＢ２００の受信側ＲＬＣエンティティ３２に当該上りリンクデータを送信する際に当該上りリンクデータが消失すると、ｇＮＢ２００の受信側ＲＬＣエンティティ３２はＮａｃｋをＩＡＢノード３００の送信側ＲＬＣエンティティ２２Ｔに送信し、ＩＡＢノード３００の送信側ＲＬＣエンティティ２２Ｔは当該上りリンクデータを再送する。ＩＡＢノード３００とｇＮＢ２００との間のＡＲＱ＃２においてデータを回復できない場合、ｇＮＢ２００のＰＤＣＰエンティティ３４は、ＰＤＣＰレイヤの再送の仕組みであるＰＤＣＰＤａｔａＲｅｃｏｖｅｒｙを利用して、ＵＥ１００のＰＤＣＰエンティティ１３に再送を要求する。しかしながら、ＵＥ１００のＰＤＣＰエンティティ１３は、ＩＡＢノード３００へのデータ送信成功と判断しているため、ＰＤＣＰレイヤにおける再送が行われない虞がある。

このような「ｈｏｐ－ｂｙ－ｈｏｐ」における問題を解決するために、本実施形態に係るＩＡＢノード３００は次のような動作を行う。図１１に示すように、ＩＡＢノード３００は、第１の通信装置から上りリンクデータを受信する受信側ＲＬＣエンティティ２２Ｒと、受信側ＲＬＣエンティティ２２Ｒが受信した上りリンクデータを第２の通信装置に送信する送信側ＲＬＣエンティティ２２Ｔとを有する。図１１の例において第１の通信装置がＵＥ１００であるが、第１の通信装置は、ＵＥ１００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。また、図１１の例において第２の通信装置がｇＮＢ２００であるが、第２の通信装置は、ｇＮＢ２００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。

送信側ＲＬＣエンティティ２２Ｔは、送信された上りリンクデータを第２の通信装置が受信成功したことを示す第１の肯定応答（Ａｃｋ）を第２の通信装置から受信する。受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信したことに応じて、当該上りリンクデータを受信側ＲＬＣエンティティ２２Ｒが受信成功したことを示す第２の肯定応答（Ａｃｋ）を第１の通信装置に送信する。すなわち、受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信するまでは、第２の肯定応答（Ａｃｋ）を第１の通信装置に送信しない。

このように、ＩＡＢノード３００において、受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ２２Ｔが上りリンクデータの送信成功を確認するまで、当該上りリンクデータに対応するＡｃｋを第１の通信装置に送信しない。これにより、第１の通信装置は、受信側ＲＬＣエンティティ２２Ｒから当該上りリンクデータに対応するＡｃｋを受信するまで、当該上りリンクデータを保持するため、上述したような「ｈｏｐ－ｂｙ－ｈｏｐ」における問題を解決できる。

ＩＡＢノード３００は、受信側ＲＬＣエンティティ２２Ｒ及び送信側ＲＬＣエンティティ２２Ｔよりも上位のレイヤに位置付けられるアダプテーションレイヤ（Ａｄａｐｔ．）のエンティティ２３を有してもよい。以下において、アダプテーションレイヤのエンティティを「アダプテーションエンティティ」と称する。アダプテーションエンティティ２３は、複数の受信側ＲＬＣエンティティ２２Ｒと複数の送信側ＲＬＣエンティティ２２Ｔとが存在する場合に、受信側ＲＬＣエンティティ２２Ｒと送信側ＲＬＣエンティティ２２Ｔとの対応付けを示すマッピング情報を管理する。アダプテーションエンティティ２３は、論理チャネル（ＬＣＨ）ごとにマッピング情報を管理してもよいし、ＵＥ１００の識別子（例えば、Ｃ－ＲＮＴＩ（Ｃｅｌｌ－ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）等）ごとにマッピング情報を管理してもよい。

アダプテーションエンティティ２３は、第１の肯定応答（Ａｃｋ）に関する情報を送信側ＲＬＣエンティティ２２Ｔから取得し、該取得された情報を受信側ＲＬＣエンティティ２２Ｒに提供する。受信側ＲＬＣエンティティ２２Ｒは、アダプテーションエンティティ２３から提供される情報に基づいて、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信したことを確認する。

例えば、送信側ＲＬＣエンティティ２２Ｔは、第２の通信装置の受信側ＲＬＣエンティティ３２からの送達情報としてＳＴＡＴＵＳＰＤＵ（Ａｃｋ／Ｎａｃｋ）をアダプテーションエンティティ２３に通知する。或いは、送信側ＲＬＣエンティティ２２Ｔは、当該ＳＴＡＴＵＳＰＤＵに基づくＡｃｋ／Ｎａｃｋ情報を送達情報としてアダプテーションエンティティ２３に通知してもよい。Ａｃｋ／Ｎａｃｋ情報は、送達に成功したシーケンス番号（ＳＮ）を含んでもよいし、送達に失敗したシーケンス番号（ＳＮ）を含んでもよい。アダプテーションエンティティ２３は、送信側ＲＬＣエンティティ２２Ｔからの送達情報を、対応する受信側ＲＬＣエンティティ２２Ｒに転送する。受信側ＲＬＣエンティティ２２Ｒは、アダプテーションエンティティ２３から転送された送達情報を取得し、ＲＬＣＰＤＵ（ＡＭＤＰＤＵ）の送信成功が確認できた場合に、当該ＲＬＣＰＤＵ（ＡＭＤＰＤＵ）についてＡｃｋを送信可能な状態になったと判断する。本実施形態では、ＩＡＢノード３００が、独立したアダプテーションエンティティ２３を有する一例を想定しているが、ＩＡＢノード３００が、独立したアダプテーションエンティティ２３を有していなくてもよい。アダプテーションエンティティ２３の機能は、他のレイヤ（例えば、ＲＬＣ、ＭＡＣ）のエンティティに統合されてもよい。このような場合、受信側ＲＬＣエンティティ２２Ｒと送信側ＲＬＣエンティティ２２Ｔとの間で直接的に送達情報の受け渡しを行ってもよいし、ＲＲＣエンティティ経由で送達情報の受け渡しを行ってもよい。

本実施形態において、受信側ＲＬＣエンティティ２２Ｒは、第１の通信装置からの上りリンクデータを受信してから、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を受信するまで（又は受信側ＲＬＣエンティティ２２Ｒが、送信側ＲＬＣエンティティ２２Ｔから送達情報を取得するまで若しくはＲＬＣＰＤＵ（ＡＭＤＰＤＵ）についてＡｃｋを送信可能な状態になったと判断するまで）の待ち時間を計時してもよい。受信側ＲＬＣエンティティ２２Ｒは、当該待ち時間が一定時間を超える場合に、受信側ＲＬＣエンティティ２２Ｒが上りリンクデータの受信に失敗したことを示す否定応答（Ｎａｃｋ）を第１の通信装置に送信してもよい。かかる否定応答（Ｎａｃｋ）に応じて第１の通信装置から再送された上りリンクデータを受信側ＲＬＣエンティティ２２Ｒが受信した場合、送信側ＲＬＣエンティティ２２Ｔは、受信された上りリンクデータによって第２の通信装置に対する再送を試みてもよい。或いは、受信側ＲＬＣエンティティ２２Ｒは、当該待ち時間が一定時間を超える場合に、ＰＤＣＰＤａｔａＲｅｃｏｖｅｒｙをトリガすることをＵＥ１００のＰＤＣＰエンティティ１３に要求するためのメッセージを送信してもよい。かかるメッセージは、受信側ＲＬＣエンティティ２２Ｒから上位レイヤ（例えば、アダプテーションエンティティ２３又はＲＲＣエンティティ）に通知され、当該上位レイヤからＵＥ１００に対して送信されてもよい。

例えば、受信側ＲＬＣエンティティ２２Ｒは、第１の通信装置から上りリンクデータ（ＲＬＣＰＤＵ）を受信した時に、タイマを起動する。タイマには一定時間が設定され、この一定時間が経過（すなわち、タイマが満了）すると、受信側ＲＬＣエンティティ２２Ｒは、否定応答（Ｎａｃｋ）を第１の通信装置に送信する。受信側ＲＬＣエンティティ２２Ｒは、タイマが動作中（すなわち、タイマが満了する前）に、送信側ＲＬＣエンティティ２２Ｔが第１の肯定応答（Ａｃｋ）を第２の通信装置から受信すると（又は受信側ＲＬＣエンティティ２２Ｒが、送信側ＲＬＣエンティティ２２Ｔから送達情報を取得する若しくはＲＬＣＰＤＵ（ＡＭＤＰＤＵ）についてＡｃｋを送信可能な状態になったと判断すると）、タイマを停止させる。なお、タイマに設定される一定時間は、ｇＮＢ２００から例えばＲＲＣシグナリングにより指定されてもよいし、予めＩＡＢノード３００に記憶されたものでもよい。また、タイマに設定される一定時間は、他のＩＡＢノード３００から転送されたものであってもよい。受信側ＲＬＣエンティティ２２Ｒは、ｇＮＢ２００からの設定に応じて、タイマ満了時の動作を変更してもよい。例えば、受信側ＲＬＣエンティティ２２Ｒは、タイマ満了時に第２の肯定応答（Ａｃｋ）を第１の通信装置に送信するよう設定されてもよい。本実施形態において、ＵＥ１００（第１の通信装置）の送信側ＲＬＣエンティティ１２は、Ａｃｋの待ち時間が長くなっても送信失敗と判断しないように、Ａｃｋの最大待ち時間（又はＳＴＡＴＵＳＰＤＵの最大待ち時間）を規定するタイマを通常よりも長く設定することが好ましい。例えば、ｇＮＢ２００は、ＲＲＣシグナリングにより、通常よりも長いタイマ値をＵＥ１００（第１の通信装置）の送信側ＲＬＣエンティティ１２に設定してもよい。ＵＥ１００の送信側ＲＬＣエンティティ１２は、当該タイマが動作中は、ＳＴＡＴＵＳＰＤＵの送信をＩＡＢノード３００の受信側ＲＬＣエンティティ２２Ｒに要求しないようにする。

図１２は、本実施形態に係る動作例を示すシーケンス図である。

ここでは、図１に示すＵＥ１００－３とｇＮＢ２００－１との間で上りリンクのデータ転送を行う場合を想定する。本動作例において、第２の通信装置は、ＩＡＢノード３００－２とｇＮＢ２００－１（ドナーｇＮＢ）との間の通信に介在するＩＡＢノード３００－１である。

図１２に示すように、ステップＳ１１において、ＵＥ１００－３の送信側ＲＬＣエンティティ１２は、ＰＤＣＰエンティティ１３からのＰＤＣＰＰＤＵをＲＬＣＳＤＵ（ＳｅｒｖｉｃｅＤａｔａＵｎｉｔ）として受け取り、ＲＬＣＳＤＵからＲＬＣＰＤＵを生成し、生成したＲＬＣＰＤＵを、ＭＡＣエンティティ１１を介してＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒを介してＲＬＣＰＤＵを受信する。

ステップＳ１２において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ＲＬＣＰＤＵの受信に応じてタイマを起動することにより、ＩＡＢノード３００－２の送信側ＲＬＣエンティティ２２ＴがＡｃｋを受信するまでの待ち時間を計時する。なお、タイマは、ＲＬＣＰＤＵごとに設けられてもよいし、複数のＲＬＣＰＤＵからなるグループごとに設けられてもよい。つまり、タイマが複数のＲＬＣＰＤＵからなるグループごとに設けられている場合、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、当該複数のＲＬＣＰＤＵを受信した場合に、タイマを起動してもよい。その場合、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、後述するステップＳ２１において、当該複数のＲＬＣＰＤＵに対応するＡｃｋを送信側ＲＬＣエンティティ２２Ｔが受信した場合に応じて、後述するステップＳ２４において、ＵＥ１００－３に対してＡｃｋを送信してもよい。

ステップＳ１３において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ＩＡＢノード３００－２のアダプテーションエンティティ２３を介してＩＡＢノード３００－２の送信側ＲＬＣエンティティ２２ＴにＲＬＣＳＤＵを提供する。

ステップＳ１４において、ＩＡＢノード３００－２の送信側ＲＬＣエンティティ２２Ｔは、アダプテーションエンティティ２３から受け取ったＲＬＣＳＤＵからＲＬＣＰＤＵを生成し、生成したＲＬＣＰＤＵを、ＭＡＣエンティティ２１を介してＩＡＢノード３００－１に送信する。ＩＡＢノード３００－１の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒを介してＲＬＣＰＤＵを受信する。

ステップＳ１５において、ＩＡＢノード３００－１の受信側ＲＬＣエンティティ２２Ｒは、ＲＬＣＰＤＵの受信に応じてタイマを起動することにより、ＩＡＢノード３００－１の送信側ＲＬＣエンティティ２２ＴがＡｃｋを受信するまでの待ち時間を計時する。

ステップＳ１６において、ＩＡＢノード３００－１の受信側ＲＬＣエンティティ２２Ｒは、ＩＡＢノード３００－１のアダプテーションエンティティ２３を介してＩＡＢノード３００－１の送信側ＲＬＣエンティティ２２ＴにＲＬＣＳＤＵを提供する。

ステップＳ１７において、ＩＡＢノード３００－１の送信側ＲＬＣエンティティ２２Ｔは、アダプテーションエンティティ２３から受け取ったＲＬＣＳＤＵからＲＬＣＰＤＵを生成し、生成したＲＬＣＰＤＵを、ＭＡＣエンティティ２１を介してｇＮＢ２００－１に送信する。ｇＮＢ２００－１の受信側ＲＬＣエンティティ３２は、ＭＡＣエンティティ３１を介してＲＬＣＰＤＵを受信する。ｇＮＢ２００－１の受信側ＲＬＣエンティティ３２は、受信したＲＬＣＰＤＵに対応するＲＬＣＳＤＵを、アダプテーションエンティティ３３を介してＰＤＣＰエンティティ３４に提供する。

ステップＳ１８において、ｇＮＢ２００－１の受信側ＲＬＣエンティティ３２は、ステップＳ１７で受信したＲＬＣＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳＰＤＵを、ＭＡＣエンティティ３１を介してＩＡＢノード３００－１に送信する。このＳＴＡＴＵＳＰＤＵには、他のＲＬＣＰＤＵに対応するＡｃｋ／Ｎａｃｋも含まれていてもよい。ＩＡＢノード３００－１の送信側ＲＬＣエンティティ２２Ｔは、ＭＡＣエンティティ２１Ｔを介してＳＴＡＴＵＳＰＤＵを受信する。

ステップＳ１９において、ＩＡＢノード３００－１の送信側ＲＬＣエンティティ２２Ｔは、受信したＳＴＡＴＵＳＰＤＵ又はそれに基づく送達情報を、ＩＡＢノード３００－１のアダプテーションエンティティ２３を介してＩＡＢノード３００－１の受信側ＲＬＣエンティティ２２Ｒに提供する。

ステップＳ２０において、ＩＡＢノード３００－１の受信側ＲＬＣエンティティ２２Ｒは、送達情報に基づいて、ステップＳ１４で受信したＲＬＣＰＤＵに対応するＡｃｋをＩＡＢノード３００－１の送信側ＲＬＣエンティティ２２Ｔが受信したことを確認する。

ステップＳ２１において、ＩＡＢノード３００－１の受信側ＲＬＣエンティティ２２Ｒは、ステップＳ１４で受信したＲＬＣＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳＰＤＵを、ＭＡＣエンティティ２１Ｒを介してＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２の送信側ＲＬＣエンティティ２２Ｔは、ＭＡＣエンティティ２１Ｔを介してＳＴＡＴＵＳＰＤＵを受信する。

ステップＳ２２において、ＩＡＢノード３００－２の送信側ＲＬＣエンティティ２２Ｔは、受信したＳＴＡＴＵＳＰＤＵに基づく送達情報を、ＩＡＢノード３００－２のアダプテーションエンティティ２３を介してＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒに提供する。

ステップＳ２３において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、送達情報に基づいて、ステップＳ１１で受信したＲＬＣＰＤＵに対応するＡｃｋをＩＡＢノード３００－２の送信側ＲＬＣエンティティ２２Ｔが受信したことを確認する。

ステップＳ２４において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ステップＳ１１で受信したＲＬＣＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳＰＤＵを、ＭＡＣエンティティ２１Ｒを介してＵＥ１００－３に送信する。ＵＥ１００－３の送信側ＲＬＣエンティティ１２は、ＭＡＣエンティティ１１を介してＳＴＡＴＵＳＰＤＵを受信し、ステップＳ１１で送信したＲＬＣＰＤＵの送信成功を確認し、その旨をＰＤＣＰエンティティ１３に通知する。

また、上述の実施形態では、ｇＮＢ２００－１や各ＩＡＢノードがＲＬＣＰＤＵを正常に受信し、Ａｃｋを含むＳＴＡＴＵＳＰＤＵを送信する事例を主に説明したが、ＲＬＣＰＤＵを正常に受信しなかった場合を以下に説明する。

ｇＮＢ２００－１又は各ＩＡＢノード３００－１の受信側ＲＬＣエンティティは、Ｎａｃｋを含むＳＴＡＴＵＳＰＤＵを各ＩＡＢノード３００－１（３００－２）の送信側ＲＬＣエンティティに送信する。その場合、各ＩＡＢノード３００－１（３００－２）の送信側ＲＬＣエンティティ２２Ｔは、当該ＳＴＡＴＵＳＰＤＵを受信したことに応じて、ＲＬＣＰＤＵを再送する。その後、各ＩＡＢノード３００－１（３００－２）の送信側ＲＬＣエンティティ２２Ｔは、Ａｃｋを含むＳＴＡＴＵＳＰＤＵを受信した場合、上述の実施形態と同様に、受信したＳＴＡＴＵＳＰＤＵに基づく送達情報を、各ＩＡＢノード３００－１（３００－２）のアダプテーションエンティティ２３を介してＩＡＢノード３００－１（３００－２）の受信側ＲＬＣエンティティ２２Ｒに提供する。

また、ＩＡＢノード３００－１（３００－２）の送信側ＲＬＣエンティティ２２Ｔは、ＲＬＣＰＤＵの再送ができない場合、Ｎａｃｋを含むＳＴＡＴＵＳＰＤＵを所定回数受信した場合又はタイマが満了した場合、Ｎａｃｋを含むＳＴＡＴＵＳＰＤＵをＩＡＢノード３００－２又はＵＥ１００－３に送信してもよい。

なお、ＩＡＢノード３００－１（３００－２）は、Ｎａｃｋを含むＳＴＡＴＵＳＰＤＵをＩＡＢノード３００－２又はＵＥ１００－３に送信することに併せて、タイマを停止してもよい。

図１３は、本実施形態に係る他の動作例を示すシーケンス図である。ここでは、図１２の動作例との相違点について説明する。

図１３に示すように、本動作例において、アダプテーションエンティティ２３はＲＬＣエンティティ２２よりも下位のレイヤに位置付けられている。かかる構成において、アダプテーションエンティティ２３は、例えば、ＱｏＳ制御を行ったり、ＵＥ１００からのＵＬ受信とＩＡＢノードからのＵＬ受信とを区別してひも付けを行ったり、ＭＡＣへの指示を行ったりする。また、ＩＡＢノード３００－１及び３００－２、並びにｇＮＢ２００－１において、ＲＬＣエンティティ２２がＡＲＱ機能（ＲＬＣＡＲＱ）とデータ分割・結合機能（ＲＬＣＳｅｇ．）とに分けられている。

図１３に示すように、ステップＳ３１において、ＵＥ１００－３の送信側ＲＬＣエンティティ１２は、ＰＤＣＰエンティティ１３からのＰＤＣＰＰＤＵをＲＬＣＳＤＵとして受け取り、ＲＬＣＳＤＵからＲＬＣＰＤＵを生成し、生成したＲＬＣＰＤＵを、ＭＡＣエンティティ１１を介してＩＡＢノード３００－２に送信する。ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ＭＡＣエンティティ２１Ｒ及びアダプテーションエンティティ２３Ｒを介してＲＬＣＰＤＵを受信する。

ステップＳ３２において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ＲＬＣＰＤＵの受信に応じてタイマを起動することにより、ＩＡＢノード３００－２の送信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）２２ＴｂがＡｃｋを受信するまでの待ち時間を計時する。

ステップＳ３３において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、送信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）２２ＴｂにステップＳ３２において受信した当該ＲＬＣＰＤＵに対応するＲＬＣＳＤＵを中継（ｒｅｌａｙ）する。

ステップＳ３４において、ＩＡＢノード３００－２の送信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）２２Ｔｂは、受信側ＲＬＣエンティティ２２Ｒから受け取ったＲＬＣＳＤＵを、送信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）２２Ｔａ、アダプテーションエンティティ２３Ｔ、及びＭＡＣエンティティ２１Ｔを介してＩＡＢノード３００－１に送信する。ここで、送信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）２２Ｔａは、ＲＬＣＳＤＵに対してシーケンス番号の付与及び分割（セグメンテーション）を行う。ＩＡＢノード３００－１の受信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）２２Ｒａは、ＭＡＣエンティティ２１Ｒ及びアダプテーションエンティティ２３Ｒを介してＲＬＣＰＤＵを受信し、ＲＬＣＰＤＵを送信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）２２Ｔａに中継する。ＩＡＢノード３００－１の送信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）２２Ｔａは、中継されたＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を分割して、アダプテーションエンティティ２３Ｔ及びＭＡＣエンティティ２１Ｔを介してｇＮＢ２００－１に送信する。なお、ＡＲＱの視点では、ＩＡＢノード３００－１は透過的である。ｇＮＢ２００－１の受信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）３２ｂは、ＭＡＣエンティティ３１、アダプテーションエンティティ３３、及び受信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）３２ａを介してＲＬＣＰＤＵを受信する。ｇＮＢ２００－１の受信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）３２ｂは、受信したＲＬＣＰＤＵに対応するＲＬＣＳＤＵをＰＤＣＰエンティティ３４に提供する。

ステップＳ３５において、ｇＮＢ２００－１の受信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）３２ｂは、ステップＳ３４で受信したＲＬＣＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳＰＤＵを、受信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）３２ａ、アダプテーションエンティティ３３、及びＭＡＣエンティティ３１を介してＩＡＢノード３００－１に送信する。このＳＴＡＴＵＳＰＤＵには、他のＲＬＣＰＤＵに対応するＮａｃｋも含まれていてもよい。ＳＴＡＴＵＳＰＤＵはＩＡＢノード３００－１を介してＩＡＢノード３００－２に伝達される。ＩＡＢノード３００－２の送信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）２２Ｔｂは、ＭＡＣエンティティ２１Ｔ、アダプテーションエンティティ２３Ｔ、及び送信側ＲＬＣエンティティ（ＲＬＣＳｅｇ．）２２Ｔａを介してＳＴＡＴＵＳＰＤＵを受信する。

ステップＳ３６において、ＩＡＢノード３００－２の送信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）２２Ｔｂは、受信したＳＴＡＴＵＳＰＤＵ又はそれに基づく送達情報を、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒに提供する。

ステップＳ３７において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、送達情報に基づいて、ステップＳ３１で受信したＲＬＣＰＤＵに対応するＡｃｋをＩＡＢノード３００－２の送信側ＲＬＣエンティティ（ＲＬＣＡＲＱ）２２Ｔｂが受信したことを確認する。

ステップＳ３８において、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２Ｒは、ステップＳ３１で受信したＲＬＣＰＤＵに対応するＡｃｋを含むＳＴＡＴＵＳＰＤＵを、アダプテーションエンティティ２３Ｒ及びＭＡＣエンティティ２１Ｒを介してＵＥ１００－３に送信する。ＵＥ１００－３の送信側ＲＬＣエンティティ１２は、ＭＡＣエンティティ１１を介してＳＴＡＴＵＳＰＤＵを受信し、ステップＳ３１で送信したＲＬＣＰＤＵの送信成功を確認し、その旨をＰＤＣＰエンティティ１３に通知する。

なお、図１３の動作例において、ｇＮＢ２００－１は、例えばルーティングテーブルを参照し、ＵＥ１００－３に対してアクセスリンクを提供しているＩＡＢノード３００－２を特定し、ＩＡＢノード３００－２に対して、通常のＡＣＫ／ＮＡＣＫ（ＳＴＡＴＵＳＰＤＵ）とは別のＡＣＫ／ＮＡＣＫを送信してもよい。ここで、別のＡＣＫ／ＮＡＣＫとは、複数の（バックホール）ベアラのＡＣＫ／ＮＡＣＫをまとめて１つのメッセージで送信するものであってもよい。その場合、ベアラ（又はＲＬＣチャネル）を特定するためのＩＤとＡＣＫ／ＮＡＣＫ情報とを紐づけて（リスト化して）送信してもよい。ｇＮＢ２００－１は、このような別のＡＣＫ／ＮＡＣＫを、ＩＡＢノード３００－２からの要求に応じて送信してもよい。

このように、本実施形態によれば、ＡＲＱを「ｈｏｐ－ｂｙ－ｈｏｐ」で行う場合において、データ転送経路上でデータが消失しても、ＰＤＣＰレイヤにおける再送を行うことが可能である。現状のＰＤＣＰ動作と整合が取れているため、現状のＰＤＣＰ動作に変更を加える必要がない。具体的には、ＵＥ１００の動作変更を最小限にすることで、後方互換性を保つことができる。さらに、各ＩＡＢノード３００が中継先のＡＣＫ受信状況を加味するだけでよいため、複雑性及び処理の増加を防ぐことができる。

［第２実施形態の変更例］
第２実施形態の変更例について、上述した第２実施形態との相違点を主として説明する。本変更例は、上述した第２実施形態と併用して実施してもよいし、上述した第２実施形態とは別に実施してもよい。

本変更例において上りリンクにおけるデータ転送について主として説明する。但し、上りリンクにおけるデータ転送に限定されるものではなく、下りリンクにおけるデータ転送であってもよい。

本変更例に係るＩＡＢノード３００は、第１の通信装置から第２の通信装置へデータを中継する場合に、当該データを保持する。第１の通信装置は、ＵＥ１００であってもよいし、ＵＥ１００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。第２の通信装置は、ｇＮＢ２００であってもよいし、ｇＮＢ２００と当該ＩＡＢノード３００との間に介在する他のＩＡＢノードであってもよい。ＩＡＢノード３００は、第２の通信装置との無線リンクにおける無線状態の悪化又はデータ転送経路の切り替えに応じて、保持しているデータを第３の通信装置に送信する。

図１４は、本変更例に係る構成例を示す図である。

図１４に示すように、ＩＡＢノード３００－２は、第１の通信装置からデータを受信する受信側ＲＬＣエンティティ２２Ｒと、第２の通信装置と対応付けられた第１の送信側ＲＬＣエンティティ２２Ｔ_１と、第３の通信装置と対応付けられた第２の送信側ＲＬＣエンティティ２２Ｔ_２とを有する。図１４の例において、第１の通信装置はＵＥ１００－３であり、第２の通信装置はＩＡＢノード３００－１であり、第３の通信装置はＩＡＢノード３００－４である。

ＩＡＢノード３００－２は、受信側ＲＬＣエンティティ２２Ｒが受信したデータを第１の送信側ＲＬＣエンティティ２２Ｔ_１に提供するとともに当該データを保持（バッファリング）するアダプテーションエンティティ２３を有する。アダプテーションエンティティ２３は、ＲＬＣエンティティ２２よりも上位のレイヤに位置付けられている。

ＩＡＢノード３００－２のアダプテーションエンティティ２３は、当該ＩＡＢノード３００－２と第２の通信装置（ＩＡＢノード３００－１）との間の無線状態の悪化、又は第２の通信装置（ＩＡＢノード３００－１）から第３の通信装置（ＩＡＢノード３００－４）へのデータ転送経路の切り替えに応じて、保持しているデータを第２の送信側ＲＬＣエンティティ２２Ｔ_２に提供する。ここで、無線状態の悪化とは、第２の通信装置との間で無線リンク障害が発生したこと、第２の通信装置からの無線信号が途絶したこと、又は第２の通信装置からの無線信号の受信レベルが閾値を下回ったことであってもよい。また、データ転送経路の切り替えとは、ハンドオーバによるネットワークトポロジの変更であってもよい。

例えば、アダプテーションエンティティ２３は、１つの送信側ＲＬＣエンティティ２２Ｔ_１に受け渡し済みのＰＤＣＰＰＤＵ（ＲＬＣＳＤＵ）をバッファリングし、この送信側ＲＬＣエンティティ２２Ｔ_１に紐づいた無線リンクに障害が発生した場合に、当該バッファリングしているＰＤＣＰＰＤＵを別の無線リンクに紐づいた送信側ＲＬＣエンティティ２２Ｔ_２に受け渡す。これにより、無線リンク障害が発生した場合でもデータが消失することを防止できる。

具体的には、ＩＡＢノード３００－２のアダプテーションエンティティ２３は、受信側ＲＬＣエンティティ２２ＲからＲＬＣＳＤＵを取得し、当該ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）のコピーを作成し、一方のＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を自身のバッファに保存した後、他方のＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を第１の送信側ＲＬＣエンティティ２２Ｔ_１に受け渡す。そして、ＩＡＢノード３００－２のアダプテーションエンティティ２３は、無線リンク異常が発生した場合に、当該保存してあるＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）をバッファから取り出し、無線リンク異常が発生していない第２の送信側ＲＬＣエンティティ２２Ｔ_２に受け渡す。ここで、無線リンク異常は、ＩＡＢノード３００－２のＲＲＣから通知されてもよいし、ｇＮＢ（ドナーｇＮＢ）２００のＲＲＣから通知されてもよい。若しくは、ＩＡＢノード３００－２の受信側ＲＬＣエンティティ２２ＲからＲＬＣＳＤＵからそのコピーを第２の送信側ＲＬＣエンティティ２２Ｔ_２に受け渡してもよい。また、切替先の送信側ＲＬＣエンティティは、ＩＡＢノード３００－２のＲＲＣから指定されてもよいし、ｇＮＢ（ドナーｇＮＢ）２００のＲＲＣから指定されてもよい。

ＩＡＢノード３００－２のアダプテーションエンティティ２３は、ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を保存する際にタイマを起動し、タイマが満了した際に当該ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を破棄する。或いは、ＩＡＢノード３００－２のアダプテーションエンティティ２３は、ｇＮＢ（ドナーｇＮＢ）２００のアダプテーションエンティティ又は他のＩＡＢノードのアダプテーションエンティティから送達確認情報（Ａｃｋ／Ｎａｃｋ）を取得し、保持しているＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）の送信が成功したと判断した場合に当該ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を破棄してもよい。また、ＩＡＢノード３００－２のアダプテーションエンティティ２３は、当該ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を破棄する際に、当該タイマを停止してもよい。また、ＩＡＢノード３００－２のアダプテーションエンティティ２３は、当該ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を破棄する代わりに、ＰＤＣＰＤａｔａＲｅｃｏｖｅｒｙを利用した再送対象から除外してもよい。

また、ＩＡＢノード３００－２のアダプテーションエンティティ２３は、第２の送信側ＲＬＣエンティティ２２Ｔ_２が、ＳＴＡＴＵＳＰＤＵ（Ａｃｋ／Ｎａｃｋ）又は送達確認情報（Ａｃｋ／Ｎａｃｋ）を他のＩＡＢノード３００－４の受信側ＲＬＣエンティティ２２Ｒから受信し、それらの情報を第２の送信側ＲＬＣエンティティ２２Ｔ_２から取得したことに応じて、当該ＲＬＣＳＤＵ（ＰＤＣＰＰＤＵ）を破棄又はＰＤＣＰＤａｔａＲｅｃｏｖｅｒｙを利用した再送対象から除外してもよい。

なお、図１２～１４において、各装置（ＵＥ、ＩＡＢノード、ｇＮＢ）のＰＨＹエンティティを省略しているが、実際、各装置は、それぞれＰＨＹエンティティを有し、各ＰＨＹエンティティを介して互いに通信していてもよい。

［その他の実施形態］
上述した実施形態において、移動通信システム１が５Ｇ移動通信システムである一例について主として説明した。しかしながら、移動通信システム１における基地局はｅＮＢであってもよい。また、移動通信システム１におけるコアネットワークはＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）であってもよい。さらに、ｇＮＢがＥＰＣに接続することもでき、ｅＮＢが５ＧＣに接続することもでき、ｇＮＢとｅＮＢとが基地局間インターフェイス（Ｘｎインターフェイス、Ｘ２インターフェイス）を介して接続されることもできる。

なお、上述した実施形態に係る各処理をコンピュータに実行させるプログラムが提供されてもよい。また、プログラムは、コンピュータ読取り可能媒体に記録されていてもよい。コンピュータ読取り可能媒体を用いれば、コンピュータにプログラムをインストールすることが可能である。ここで、プログラムが記録されたコンピュータ読取り可能媒体は、非一過性の記録媒体であってもよい。非一過性の記録媒体は、特に限定されるものではないが、例えば、ＣＤ－ＲＯＭやＤＶＤ－ＲＯＭ等の記録媒体であってもよい。ＵＥ１００及びｅＮＢ２００が行う各処理を実行するためのプログラムを記憶するメモリ及びメモリに記憶されたプログラムを実行するプロセッサによって構成されるチップセットが提供されてもよい。

なお、各図において示されるフローは、適宜組み合わされても良い。

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

［付記］
１．序論
ＲＡＮ２ＡＨ１８０７は、ｅｎｄ－ｔｏ－ｅｎｄの信頼性、即ち、「ｅｎｄ－ｔｏ－ｅｎｄ」及び「ｈｏｐ－ｂｙ－ｈｏｐ」のＲＬＣＡＲＱメカニズムを比較することを広く議論し、ＴＲに追加のテキストを取り込むことに合意した。

「ｅｎｄ－ｔｏ－ｅｎｄ」及び「ｈｏｐ－ｂｙ－ｈｏｐ」のＡＲＱに対する所見

（例：ＩＡＢノード間の無線リンク障害）
現在の仕様では、ＩＡＢトポロジの変更を追加の機能強化なしで実行した場合（下記の例）に、データの損失のない配信を保証できない。

ｅｎｄ－ｔｏ－ｅｎｄのＲＬＣフィードバックにより、データの損失のない配信が保証される。

ｈｏｐ－ｂｙ－ｈｏｐのＲＬＣＡＲＱの場合におけるｅｎｄ－ｔｏ－ｅｎｄの信頼性の課題は、例えば、以下のメカニズムを特定することによって対処することができる。

－ＰＤＣＰプロトコル／プロシージャの変更。この解決策は、Ｒｅｌ－１５ＵＥには適用できないであろう、それはＲｅｌ－１５ＵＥの性能が損なわれる可能性があることを意味する。

－経路更新（ＦＦＳＩＡＢノード間で交換される必要のある情報）に応じて中間ＩＡＢノードにバッファされたＰＤＣＰＰＤＵの再ルーティング。

－ＵＬステータス配信（ドナーｇＮＢからＩＡＢノードに）を導入することにより、ＩＡＢノードは、ドナーｇＮＢでの受信の確認までＵＥへのＲＬＣＡＣＫの送信を遅らせることができる。

この付記において、ｈｏｐ－ｂｙ－ｈｏｐのＲＬＣＡＲＱメカニズムの更なる考察が議論される。

２．議論
合意されたＴＰは、ｅｎｄ－ｔｏ－ｅｎｄの信頼性、即ち、「トポロジ変更中のＵＬデータの損失のない配信」に関して、「ｈｏｐ－ｂｙ－ｈｏｐ」のＲＬＣＡＲＱメカニズムにおける課題を特定し、それはまた３つの可能なアプローチを取り入れる。参考として、アプローチを以下に引用する。

第１のアプローチ：「ＰＤＣＰプロトコル／プロシージャの変更。この解決策は、Ｒｅｌ－１５ＵＥには適用できないであろう、それはＲｅｌ－１５ＵＥの性能が損なわれる可能性があることを意味する。」

第２のアプローチ：「経路更新に応じて中間ＩＡＢノードにバッファされたＰＤＣＰＰＤＵの再ルーティング（ＦＦＳＩＡＢノード間で交換される必要のある情報）。」

第３のアプローチ：「ＵＬステータス配信（ドナーｇＮＢからＩＡＢノードに）を導入することにより、ＩＡＢノードは、ドナーｇＮＢでの受信の確認までＵＥへのＲＬＣＡＣＫの送信を遅らせることができる。」

２．１．信頼性のあるｈｏｐ－ｂｙ－ｈｏｐのＡＲＱのための第１のアプローチ
第１のアプローチは、例えば、既に送信されたＰＤＣＰＰＤＵを一定期間維持しながらＤＣＰデータ回復を行うために、いくつかの「ＰＤＣＰプロトコル／プロシージャの変更」を必要とする。しかしながら、それはＴＲで取り込まれているように、Ｒｅｌ－１５ＵＥの性能を損なう。さらに、Ｒｅｌ－１６ＰＤＣＰプロトコルを実装するＵＥを有する必要がある可能性がある、これは、ＴＲに取り込まれている以下の要件を満たすことができないことを意味する。

ＩＡＢ設計は、ＩＡＢノードに接続する以下のＵＥを少なくともサポートする。

－Ｒｅｌ．１５ＮＲＵＥ
－ＩＡＢがＬＴＥアクセスのバックホールをサポートしている場合、レガシＬＴＥＵＥ

この意味では、それはｅｎｄ－ｔｏ－ｅｎｄの信頼性を保証するための解決策候補にはなり得ない。

提案１：ＲＡＮ２は、「Ｒｅｌ－１５ＵＥの性能が損なわれる可能性がある」ことに加えて、「ＰＤＣＰの変更」がＲｅｌ?１５ＵＥのための解決策ではないことに同意すべきである。

２．２．信頼性のあるｈｏｐ－ｂｙ－ｈｏｐのＡＲＱのための第２のアプローチ
第２のアプローチは、「経路更新に応じて中間ＩＡＢノードにバッファされたＰＤＣＰＰＤＵの再ルーティング」のための新しい機能を導入することになり、それはＲＬＣまたはアダプテーションレイヤのいずれかの中に実装されると仮定され得る。経路更新は、例えば、以下のような複数のシナリオを意味する可能性がある。

－親への接続は失敗し、異なる親への別の接続として回復する（即ち、ＲＲＣ再確立）。または、
－親への接続は、異なる親に変更されるように再設定される（即ち、ハンドオーバ）。または、
－異なる親への２つの接続のうちの１次接続が他方に切り替えられる（即ち、例えばデュアルコネクティビティによる冗長ルーティング）。

上記のいくつかの場合において（例えば、ハンドオーバ時に）、ＲＬＣエンティティは再確立される必要があるかもしれず、更に全てのＲＬＣＳＤＵは破棄される。そのため、Ｒｅｌ－１５ＲＬＣの動作が変更されない限り、ＰＤＣＰＰＤＵをバッファリング／再ルーティングすることはできない。一方、「ＲＬＣより上の」タイプのアダプテーションレイヤは、ＲＬＣ再確立中にＰＤＣＰＰＤＵをバッファリングするのに適し、そしてアクティブＭＡＣリンクに関連する（他の）ＲＬＣエンティティにそれらを再ルーティングするのに適すると考えられる。

提案２：ＲＡＮ２は、ＰＤＣＰＰＤＵをバッファリング／再ルーティングする機能が、中間ＩＡＢノードにおいて「ＲＬＣより上」に位置するアダプテーションレイヤによって処理されることに同意すべきである。

これらの場合を考慮すると、「情報が交換される必要がある」ことは、それはＲＲＣの再設定を含むことになるので、例えば、アーキテクチャグループ２に対して既に取り入れられた「ＩＡＢノード間」に加えて、例えば、アーキテクチャグループ１のために、ＩＡＢドナー及びＩＡＢノードの間にあると考えられる。加えて、経路更新のために、例えば、ＲＬＦのために、経路更新のためにＩＡＢノード間で情報を交換することは既に不可能であるかもしれない。従って、ＴＲはＩＡＢノード内の情報交換のエンティティを制限すべきではないと考えられる。

提案３：ＲＡＮ２は、「ＰＤＣＰＰＤＵの再ルーティング」を契機とした情報交換のために「またはＩＡＢドナーとＩＡＢノード間の」というテキストを追加することに同意すべきである。

第２のアプローチの利点は、たとえＲＬＣチャネルのうちの１つが例えばＲＬＦのために失敗したとしても、ＩＡＢネットワークがそれ自体でパケット損失を回復することであろう。一方、結局のところ、それはｅｎｄ－ｔｏ－ｅｎｄの信頼性のための完璧な解決策ではないかもしれない。例えば、適切なＩＡＢドナー／ノードが周囲にないために、再ルーティングのための中間ＩＡＢノードが他の接続を得ることができず、最終的にＰＤＣＰＰＤＵを失う場合、データの損失のない配信は保証されない。

提案４：ＲＡＮ２は、「ＰＤＣＰＰＤＵの再ルーティング」が最終的に損失のない配信を保証するのではなく、別の経路が見つかる限り中間ＲＬＣチャネルのパケット損失を改善／回復することに同意すべきである。

２．３．信頼性のあるｈｏｐ－ｂｙ－ｈｏｐのＡＲＱのための第３のアプローチ
第３のアプローチ、即ち、「ＵＬステータス配信（ドナーｇＮＢからＩＡＢノードに）を導入すること」は興味深いが、これまでの寄書では何らかの関連される／可能な解決策が明らかにされているかどうか明白ではない。従って、研究段階でも、もう少し詳しく議論する価値がある。

現時点で「ＵＬステータス配信」が何であるかは明確にされていませんが、これの目的は、例えば、ＵＥのＰＤＣＰレイヤにおけるＰＤＣＰＰＤＵをバッファリングし、ＰＤＣＰデータを回復することを可能にするために、「ＩＡＢノードが、ドナーｇＮＢでの受信の確認まで、ＲＬＣＡＣＫのＵＥへの送信を遅らせることができる」ことを許可することである。そのため、ＩＡＢノードのＲＬＣレイヤに導入される可能性がある新しいメカニズムによるＲｅｌ－１５ＰＤＣＰへの影響は何ら予期されない。

提案５：ＲＡＮ２は、第３のアプローチの影響がＩＡＢネットワーク内で（即ち、ＩＡＢドナーおよびＩＡＢノードにおいて）制限されるかどうかを議論するべきである。

提案３に同意する場合、エッジのＩＡＢノードの観点から、ＩＡＢドナーへのステータスＵＬ配信を確認するために以下のような２つの選択肢がある。

－選択肢１：ＵＬ配信ステータス報告は、ＩＡＢドナーからエッジのＩＡＢノードに直接送られることにより、ＲＬＣＡＣＫは、それ自身の受信ステータス及びＵＬ配信ステータス報告の両方を考慮に入れる。

－選択肢２：ＳＴＡＴＵＳＰＤＵ（即ち、ＡＣＫ）は、今日のようにピアＰＬＣエンティティの間で送られることにより、ＲＬＣＡＣＫは、それ自身だけでなく親ノードのＲＬＣエンティティにおいて成功した受信を考慮に入れる。

選択肢１は、ＴＲで取り入れられた文の直接的な解釈であるが、各エッジのＩＡＢノードに各ＵＬ配信ステータス報告を送ることに関して、いくらかの複雑さが所見される。新しい報告は通常のＲＬＣＰＤＵ（即ち、ＳＴＡＴＵＳＰＤＵ）とは異なるので、バックホールリンクを介した追加のシグナリングオーバヘッドをもたらす可能性がある。

選択肢２は、ＲＬＣＡＣＫのバケツリレーゲームのような単純な代替であることにより、ＩＡＢノードは、親ノードから関連付けられたＲＬＣＡＣＫを受信した後、既存のＲＬＣＡＣＫを送るだけである。利点は、追加のシグナリングを必要とせず、スケーラビリティを提供することである（即ち、ホップ数に制限がない）。欠点は、ＵＥがＩＡＢノードからＳＴＡＴＵＳＰＤＵを受信するためにより長い時間待つ可能性があることだが、選択肢１よりも悪くない。

まだ研究段階にあるので、両方の選択肢が有益であると認識される場合、両方の選択肢はＴＲに取り込まれるべきである。

提案６：ＲＡＮ２は、「ＵＬステータス配信」の詳細をＴＲに取り込むことに同意すべきである。特に、ＩＡＢノードはＩＡＢドナーからのＵＬ配信ステータス報告（選択肢１）及びその親ノードからのＲＬＣＡＣＫ（選択肢２）を考慮する。

Claims

移動通信システムに用いられる中継装置であって、
第１の通信装置からデータを受信する受信側ＲＬＣエンティティと、
前記受信側ＲＬＣエンティティが受信した前記データを第２の通信装置に送信する送信側ＲＬＣエンティティと、を備え、
前記送信側ＲＬＣエンティティは、前記送信されたデータを前記第２の通信装置が受信成功したことを示す第１の肯定応答を前記第２の通信装置から受信し、
前記受信側ＲＬＣエンティティは、前記送信側ＲＬＣエンティティが前記第１の肯定応答を受信するまで待った後、前記データを前記受信側ＲＬＣエンティティが受信成功したことを示す第２の肯定応答を前記第１の通信装置に送信し、
前記受信側ＲＬＣエンティティ及び前記送信側ＲＬＣエンティティよりも上位のレイヤに位置付けられる上位エンティティをさらに備え、
前記上位エンティティは、前記第１の肯定応答に関する情報を前記送信側ＲＬＣエンティティから取得し、該取得された情報を前記受信側ＲＬＣエンティティに提供し、
前記受信側ＲＬＣエンティティは、前記上位エンティティから提供される情報に基づいて、前記送信側ＲＬＣエンティティが前記第１の肯定応答を受信したことを確認する
中継装置。
前記受信側ＲＬＣエンティティは、前記第１の通信装置からの前記データを受信してから、前記送信側ＲＬＣエンティティが前記第１の肯定応答を受信するまでの待ち時間を計時し、
前記受信側ＲＬＣエンティティは、前記待ち時間が一定時間を超える場合に、前記受信側ＲＬＣエンティティが前記データを受信失敗したことを示す否定応答を前記第１の通信装置に送信する
請求項１に記載の中継装置。
前記第２の通信装置は、当該中継装置とドナー基地局との間の通信に介在する他の中継装置であり、
前記送信側ＲＬＣエンティティは、前記受信側ＲＬＣエンティティにより受信された前記データを、前記他の中継装置に設けられるＲＬＣエンティティに送信し、
前記送信側ＲＬＣエンティティは、前記他の中継装置に設けられる前記ＲＬＣエンティティから前記第１の肯定応答を受信する
請求項１又は２に記載の中継装置。
前記送信側ＲＬＣエンティティは、
前記送信されたデータを前記第２の通信装置が受信失敗したことを示す第１の否定応答を前記第２の通信装置から受信したことに応じて、前記データを再送し、
前記再送した後に前記第１の肯定応答を前記第２の通信装置から受信した場合であっても、前記上位エンティティに前記第１の肯定応答に関する情報を提供する、
請求項１乃至３のいずれか１項に記載の中継装置。