(57)【要約】  基地局装置（１）は、第１の情報要素を基地局間ゲートウェイ（３）に送信するよう構成されている。当該第１の情報要素は、無線端末宛て又は無線端末からのデータパケットを基地局間ゲートウェイ（３）が基地局装置（１）と他の基地局（２）の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。これにより、例えば、基地局又は基地局間ゲートウェイが基地局間ハンドオーバの際に基地局間ゲートウェイによるリレー処理を行うか否かを選択できるようにすることに寄与できる。
2016151653.tif 000002
【特許請求の範囲】
【請求項１】
基地局装置であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、第１の情報要素を基地局間ゲートウェイに送信するよう構成され、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
基地局装置。
【請求項２】
前記第１の情報要素は、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を明示的に示す、
請求項１に記載の基地局装置。
【請求項３】
前記少なくとも１つのプロセッサは、前記基地局装置から前記他の基地局または前記他の基地局から前記基地局装置への前記無線端末のハンドオーバの際に、前記第１の情報要素を送信するよう構成されている、
請求項１又は２に記載の基地局装置。
【請求項４】
前記少なくとも１つのプロセッサは、前記他の基地局へのハンドオーバ要求メッセージ又はハンドオーバ要求承認メッセージを運ぶために前記基地局間ゲートウェイに送信される転送メッセージに前記第１の情報要素を含めるよう構成されている、
請求項３に記載の基地局装置。
【請求項５】
前記第１の情報要素は、前記リレー処理が必要とされることを暗示的に示すために、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容を示す、
請求項４に記載の基地局装置。
【請求項６】
前記少なくとも１つのプロセッサは、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容の第３の情報要素を前記転送メッセージに含めるよう構成されている、
請求項４に記載の基地局装置。
【請求項７】
前記第２の情報要素は、前記データパケットのフォワーディングの要否を示す情報要素、前記無線端末のために設定されたベアラの識別子を示す情報要素、および前記ベアラのQuality of Service（QoS）パラメータを示す情報要素のうち少なくとも１つを含む、
請求項５又は６に記載の基地局装置。
【請求項８】
前記少なくとも１つのプロセッサは、前記転送メッセージによって運ばれる基地局間シグナリングメッセージの種別を示す情報要素を前記転送メッセージに含めるよう構成されている、
請求項４〜７のいずれか１項に記載の基地局装置。
【請求項９】
前記少なくとも１つのプロセッサは、前記データパケットの送信又は受信のために、前記基地局間ゲートウェイによる前記リレー処理を利用するか否かを決定するよう構成され、
前記リレー処理が利用されない場合、前記データパケットは、前記基地局装置と前記他の基地局の間のダイレクトパスを用いてフォワーディングされる、
請求項１〜８のいずれか１項に記載の基地局装置。
【請求項１０】
前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記基地局間ゲートウェイが前記リレー処理の能力を有するか否かを考慮するよう構成されている、
請求項１〜９のいずれか１項に記載の基地局装置。
【請求項１１】
前記少なくとも１つのプロセッサは、前記リレー処理の能力を示す第４の情報要素を前記基地局間ゲートウェイから受信するよう構成されている、
請求項１〜１０のいずれか１項に記載の基地局装置。
【請求項１２】
前記少なくとも１つのプロセッサは、前記基地局装置を前記基地局間ゲートウェイに登録する手順において、前記第４の情報要素を受信するよう構成されている、
請求項１１に記載の基地局装置。
【請求項１３】
前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記基地局装置と前記他の基地局の間のダイレクトパスの状態を考慮するよう構成されている、
請求項１〜１２のいずれか１項に記載の基地局装置。
【請求項１４】
前記ダイレクトパスの前記状態は、前記ダイレクトパスの利用可否、前記ダイレクトパスのスループット、及び前記ダイレクトパスの負荷のうち少なくとも１つを含む、
請求項１３に記載の基地局装置。
【請求項１５】
前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記基地局装置のトランスポートレイヤ・アドレスを前記他の基地局から隠す必要があるか否かを考慮するよう構成されている、
請求項１〜１４のいずれか１項に記載の基地局装置。
【請求項１６】
前記少なくとも１つのプロセッサは、前記第１の情報要素を生成する際に、前記他の基地局の種別を考慮するよう構成されている、
請求項１〜１５のいずれか１項に記載の基地局装置。
【請求項１７】
基地局間ゲートウェイ装置であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信するよう構成され、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
基地局間ゲートウェイ装置。
【請求項１８】
基地局装置により行われる方法であって、
第１の情報要素を基地局間ゲートウェイに送信することを備え、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
【請求項１９】
基地局間ゲートウェイ装置によって行われる方法であって、
第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを備え、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
【請求項２０】
基地局装置により行われる方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
前記方法は、第１の情報要素を基地局間ゲートウェイに送信することを備え、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
非一時的なコンピュータ可読媒体。
【請求項２１】
基地局間ゲートウェイ装置によって行われる方法をコンピュータに行わせるためのプログラムを格納した非一時的なコンピュータ可読媒体であって、
前記方法は、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを備え、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
非一時的なコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、無線通信に関し、特に、基地局間でのユーザデータパケットのフォワーディングに関する。
【背景技術】
【０００２】
3rd Generation Partnership Project（3GPP）Release 12は、X2 Gateway（X2 GW）について規定している（例えば、非特許文献１を参照）。非特許文献１に記載されているように、X2 GWは複数の(H)eNBの各々とシグナリング（i.e., Stream Control Transmission Protocol（SCTP））コネクションを確立し、これら複数の(H)eNBは当該X2 GWを介してシグナリングメッセージ（i.e., X2APメッセージ）を交換する。(H)eNB は、eNodeB又はHome eNodeBを意味する。X2 GWは、X2AP Message Transfer procedureを除いて、X2AP proceduresを終端しない。つまり、X2APコンテキスト（X2AP contexts）は、２つのピア(H)eNB内にのみ存在する（X2 GWが無い場合と同様）。X2APコンテキストは、２つのSCTPコネクションにまたがる（spans over）２つのピア(H)eNBの間の“X2APアソシエーション”を定義する。【０００３】
X2GWによるX2APメッセージの転送手順（X2AP Message Transfer procedure）は以下のように行われる。すなわち、ソース(H)eNBがX2APメッセージ（X2AP MESSAGE TRANSFERメッセージを除く）をX2 GWを介してターゲット(H)eNBに送信する場合、当該ソース(H)eNBは、当該X2APメッセージをX2AP MESSAGE TRANSFERメッセージ内にカプセル化（encapsulate）し、ルーティング情報（i.e., RNL Header）を追加し、そして当該X2AP MESSAGE TRANSFERメッセージを当該X2 GWに送信する。ルーティング情報（i.e., RNL Header）は、ターゲット(H)eNB ID及びソース(H)eNB IDの両方を含む。X2 GWは、ターゲット(H)eNB IDに基づいて当該X2AP MESSAGE TRANSFERメッセージをルーティングする。【０００４】
なお、X2インタフェースは、3GPP Release 8以降の基地局間インタフェースである。X2インタフェースは、コントロールプレーン（シグナリング）インタフェース（i.e., X2-Cインタフェース）及びユーザプレーン（データプレーン）インタフェース（i.e., X2-Uインタフェース）を含む。X2-Cインタフェースは、例えば、基地局間ハンドオーバ（i.e., X2ハンドオーバ）の準備、Dual connectivityの制御（e.g., UEコンテキストの確立、修正及び開放、並びにX2ユーザプレーントンネルの管理）、及び隣接するeNBに関する様々な設定及びメンテナンスのために使用される。X2-Cインタフェースは、X2APプロトコルを使用するとともに、X2APシグナリングメッセージを転送するためにSCTP及びInternet Protocol（IP）を使用する。X2APプロトコルは、Radio Network Layer（RNL）プロトコルと呼ばれ、X2APプロトコルを転送するためのSCTP/IPは、Transport Network Layer（TNL）プロトコルと呼ばれる。【０００５】
一方、X2-Uインタフェースは、例えば、ハンドオーバ中にソース(H)eNBからターゲット(H)eNBにユーザデータパケットをフォワーディングするため、及びDual connectivityでのMaster eNB（MeNB）とSecondary eNB（SeNB）の間でユーザデータパケット（i.e., Packet Data Convergence Protocol（PDCP） PDUs）を転送するため、に使用される。X2-Uインタフェースは、GPRS Tunnelling Protocol User Plane（GTP-U）プロトコルを使用し、GTP Protocol Data Unit（GTP-PDU）を転送するためにUser Datagram Protocol（UDP）及びIPを使用する。GTP-Uプロトコルは、ユーザプレーン（U-plane）のRNLプロトコルであり、GTP-U PDUを転送するためのUDP/IPは、U-planeのためのTNLプロトコルである。GTP-UおよびTNL UDP/IPは、トンネルメカニズムを提供する。すなわち、GTP-Uは、ユーザデータパケット（e.g., IPパケット）をGTP-Uヘッダによってカプセル化し、カプセル化されたユーザデータパケット（i.e., GTP-PDU）は、TNL UDP/IPレイヤにおいて転送される。なお、ユーザデータパケットは、T-PDUと呼ばれることもある。また、GTP-Uヘッダによりカプセル化されたユーザデータパケット（T-PDU）は、GTP-PDUの１つであるが、GTPノード間のシグナリングメッセージを包含するGTP-PDUと区別するためにG-PDUと呼ばれることもある。また、G-PDU又はシグナリングメッセージとしてのGTP-U PDUは、GTP-Uメッセージと呼ばれることもある。【０００６】
非特許文献１に記載されているように、3GPP Release 12は、２つのピア(H)eNB 間でのX2 GWを介したX2APシグナリングメッセージ（X2-C）の転送を規定しているが、ユーザデータパケット（X2-U）の転送を規定していない。これに対して、特許文献１及び２は、２つのピア(H)eNB 間でのX2 GWを介したユーザデータパケットの転送を開示している。【０００７】
特許文献１は、コアネットワーク（i.e., Evolved Packet Core（EPC））と(H)eNBの間でS1-MMEシグナリングメッセージ及びユーザデータパケットを中継するHeNB-GWが、X2-Cインタフェース及びX2-Uインタフェースもサポートすることを記載している。特許文献１に記載されたHeNB-GWは、ユーザデータパケットをカプセル化しているGTP-PDU（i.e., G-PDU）を２つのピア(H)eNBの間で中継するよう動作する。しかしながら、特許文献１は、HeNB-GWによるG-PDUの中継動作の詳細について記載していない。【０００８】
特許文献２は、G-PDUが２つの(H)eNB間でX2-GWを介して転送されることを記載している。特許文献２のX2-GWは、ハンドオーバ準備時に２つの(H)eNBにTunnel Endpoint Identifier（TEID）を割り当てるとともに、一方の(H)eNBから受信したGTP-U PDUのGTP-Uヘッダ内のTEIDを変更し、TEIDを変更されたGTP-U PDUを他方の(H)eNBに送信するよう動作する。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１２−２２７９７４号公報
【特許文献２】特開２０１３−１５０２０４号公報
【非特許文献】
【００１０】
【非特許文献１】3GPP TS 36.300 V12.4.0 (2014-12), “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 12)”, 2014年12月
【発明の概要】
【発明が解決しようとする課題】
【００１１】
基地局間ゲートウェイ（e.g., X2-GW）が利用される場合に、基地局間でのユーザデータパケット（e.g., PDCP PDUs）の転送（e.g., 基地局間ハンドオーバ（e.g., X2ハンドオーバ）時のDLデータフォワーディング、及びDual connectivityでのMeNBとSeNB間での転送）が常にX2-GWを介して行われることは適切ではないかもしれない。例えば、基地局間ダイレクトパス（e.g., X2インタフェース）の最大または実効的なスループット（伝送速度）が十分に大きければ、常に基地局間ゲートウェイによるリレーを利用することは遅延の増大の観点から適切ではないかもしれない。一方で、基地局間ダイレクトパスの負荷が高い場合、又は基地局間ダイレクトパスが何らかの事情で利用不能である場合には、基地局間ゲートウェイによるリレーを選択できることが好ましいかもしれない。また、２つの基地局（e.g., (H)eNBs）間のハンドオーバの際に、一方の基地局のTNLアドレス（e.g., IPアドレス）を他方の基地局から隠蔽できることが好ましいかもしれない。このTNLアドレスの隠蔽は、特定の基地局または特定の種別の基地局に対してのみ要求されるかもしれない。【００１２】
したがって、基地局（e.g., (H)eNB）又は基地局間ゲートウェイ（e.g., X2-GW）は、基地局間でのユーザデータパケットの転送の際に基地局間ゲートウェイ（e.g., X2-GW）によるリレー処理を行うか否かを選択できることが好ましいかもしれない。しかしながら、特許文献１及び２は、X2 GWによるリレー処理を行うか否かを制御することについて記載していない。ここで、基地局間ゲートウェイ（e.g., X2-GW）によるユーザデータパケットのリレー処理は、X2 GWを介した基地局（e.g., (H)eNBs）間でのユーザデータパケットの転送を意味する。【００１３】
本明細書に開示される実施形態が達成しようとする目的の１つは、基地局（e.g., (H)eNB）又は基地局間ゲートウェイ（e.g., X2-GW）が基地局間ゲートウェイ（e.g., X2-GW）によるリレー処理を行うか否かを選択できるようにすることに寄与する装置、方法、及びプログラムを提供することである。この目的は、本明細書に開示される実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
【課題を解決するための手段】
【００１４】
第１の態様では、基地局装置は、メモリ、及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、第１の情報要素を基地局間ゲートウェイに送信するよう構成されている。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。【００１５】
第２の態様では、基地局間ゲートウェイ装置は、メモリ、及び前記メモリに結合された少なくとも１つのプロセッサを含む。前記少なくとも１つのプロセッサは、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信するよう構成されている。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。【００１６】
第３の態様では、基地局装置により行われる方法は、第１の情報要素を基地局間ゲートウェイに送信することを含む。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。【００１７】
第４の態様では、基地局間ゲートウェイ装置により行われる方法は、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを含む。前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す。【００１８】
第５の態様では、プログラムは、コンピュータに読み込まれた場合に、上述の第３又は第４の態様に係る方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
【発明の効果】
【００１９】
上述の態様によれば、基地局又は基地局間ゲートウェイが基地局間ゲートウェイによるリレー処理を行うか否かを選択できるようにすることに寄与する装置、方法、及びプログラムを提供できる。
【図面の簡単な説明】
【００２０】
【図１】いくつかの実施形態に係る無線通信システムの構成例を示す図である。
【図２】第１の実施形態に係るリレー処理の必要性を通知する手順の一例を示すシーケンス図である。
【図３】第１の実施形態に係るソース基地局の動作の一例を示すフローチャートである。
【図４】第１の実施形態に係る基地局間ゲートウェイの動作の一例を示すフローチャートである。
【図５】第１の実施形態に係るターゲット基地局の動作の一例を示すフローチャートである。
【図６】第１の実施形態に係るターゲット基地局の動作の一例を示すフローチャートである。
【図７】第１の実施形態に係るソース基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。
【図８】第１の実施形態に係るソース基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。
【図９】第１の実施形態に係るターゲット基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。
【図１０】第１の実施形態に係るターゲット基地局および基地局間ゲートウェイの動作とその起動条件の組み合せの一例を示すテーブルである。
【図１１】第１の実施形態に係るリレー能力の通知手順の一例を示すシーケンス図である。
【図１２】第１の実施形態に係るリレー能力の通知手順の一例を示すシーケンス図である。
【図１３Ａ】第１の実施形態に係る基地局間ハンドオーバ手順の一例を示すシーケンス図である。
【図１３Ｂ】第１の実施形態に係る基地局間ハンドオーバ手順の一例を示すシーケンス図である。
【図１４】X2AP Message Transferメッセージの変更（modification）の一例を示す図である。
【図１５Ａ】X2AP Message Transferメッセージの変更の他の例を示す図である。
【図１５Ｂ】X2AP Message Transferメッセージの変更の他の例を示す図である。
【図１６】第３の実施形態に係る基地局間ゲートウェイのアドレスをターゲット基地局に通知する手順の一例を示すシーケンス図である。
【図１７Ａ】X2 TNL Configuration Infoメッセージの変更の一例を示す図である。
【図１７Ｂ】X2 TNL Configuration Infoメッセージの変更の一例を示す図である。
【図１８】いくつかの実施形態に係る基地局の構成例を示すブロック図である。
【図１９】いくつかの実施形態に係る基地局間ゲートウェイの構成例を示すブロック図である。
【発明を実施するための形態】
【００２１】
以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【００２２】
以下に示される複数の実施形態は、Long Term Evolution (LTE)/LTE-Advancedシステムを主な対象として説明される。しかしながら、これらの実施形態は、LTE/ LTE-Advancedシステムに限定されるものではなく、他の無線通信ネットワーク又はシステム、例えば3GPP Universal Mobile Telecommunications System（UMTS）、3GPP2 CDMA2000システム、Global System for Mobile communications（GSM（登録商標））/ General packet radio service（GPRS）システム、及びWiMAXシステム等に適用されてもよい。
【００２３】
＜第１の実施形態＞
図１は、本実施形態を含むいくつかの実施形態に係る無線通信システムの構成例を示している。図１の例では、無線通信システムは、(H)eNB１、(H)eNB２、X2 GW３、及びEPC４を含む。X2 GW３は、(H)eNBs１及び２の間でシグナリングメッセージ（X2APメッセージ）を中継するために、(H)eNBs１及び２の各々とSCTPコネクションを確立するよう構成されている。X2 GW３は、さらに、(H)eNBs１及び２の間でユーザデータパケットを中継するために、(H)eNBs１及び２の各々とGTP-Uトンネルを確立できるよう構成されている。(H)eNBs１及び２の各々は、X2 GW３との間にX2-Cインタフェースを有し、EPC４との間にS1インタフェースを有する。なお、 (H)eNB１及び２の少なくとも一方とEPC４の間にHeNB-GWが使用されてもよい。当該HeNB-GWは、(H)eNB１及び２の少なくとも一方とEPC４の間でS1-MMEシグナリング及びユーザデータパケット（S1-U）を中継する。本実施形態では、主に、(H)eNB１から(H)eNB２へのUEのハンドオーバについて説明する。したがって、 (H)eNB１をソース(H)eNBと呼び、(H)eNB２をターゲット(H)eNBと呼ぶこともある。
【００２４】
本実施形態では、(H)eNBs１及び２の少なくとも一方は、第１の情報要素（Information Element（IE））をX2 GW３に送信するよう構成されている。当該第１の情報要素は、無線端末（User Equipment（UE））のユーザデータパケットのフォワーディングのためにX2 GW３によるリレー処理が必要とされるか否かを明示的又は暗示的に示す。いくつかの実装において、(H)eNB１から(H)eNB２への当該UEのハンドオーバの際に、ソース(H)eNBs１及びターゲット(H)eNB２の少なくとも一方が当該第１の情報要素を送信してもよい。いくつかの実装において、(H)eNB１、(H)eNB２、及びUEがDual Connectivityをサポートする場合に、当該UEのベアラ確立の際に、(H)eNBs１及び (H)eNB２の少なくとも一方が当該第１の情報要素を送信してもよい。
【００２５】
X2 GW３によるリレー処理は、(H)eNB１とX2 GW３の間のX2-Uインタフェース（GTP-Uトンネル）１０１、及び(H)eNB２とX2 GW３の間のX2-Uインタフェース（GTP-Uトンネル）１０２を介してユーザデータパケット（T-PDU）を転送することを含む。X2 GW３によるユーザデータパケットのリレーは、当該リレー処理は、GTP-Uヘッダによりカプセル化されたユーザデータパケット、つまりG-PDUを転送することにより行われてもよい。X2 GW３によるリレー処理は、X2-Uリレー、U-planeリレー、GTP-Uリレー、又はユーザプレーン集約（user plane concentration）と呼ぶこともできる。
【００２６】
すなわち、当該第１の情報要素は、X2 GW３によるU-planeリレーの必要性を示す明示的（explicit）又は暗示的（implicit）な表示（indication）である。いくつかの実装において、当該表示は、X2 GW３によるリレー処理が必要とされるか否かに応じて異なる値がセットされるフラグ情報であってもよい。これに代えて、いくつかの実装において、当該表示は、X2 GW３によるリレー処理が必要とされる場合に送信され且つリレー処理が不要な場合に送信されない明示的又は暗示的なリレー要求であってもよい。これに代えて、いくつかの実装において、当該表示は、複数の情報要素の組み合せであってもよい。
【００２７】
例えば、以下に示される具体例のように、当該表示は、(H)eNBs１及び２の間のダイレクトパス１００の利用可否を示す情報要素（e.g., Direct Path Availability IE又は Direct Path Unavailability IE）を含んでもよい。ダイレクトパス１００の利用可否は、例えば、オペレータによって、つまりoperations, administration and maintenance（OAM）によって、(H)eNBs１及び２に予め設定されてもよい。これに代えて、ダイレクトパス１００の利用可否は、(H)eNBs１及び２によって動的に判定されてもよい。例えば、(H)eNBs１及び２は、ダイレクトパス１００を利用できるがそのスループットが低い場合、又はダイレクトパス１００の負荷が高い場合に、ダイレクトパス１００を利用できないと判定してもよい。当該表示は、例えば、ダイレクトパス１００の利用可否を示す情報要素とデータフォワーディングの要否を示す情報要素（e.g., DL Forwarding IE又はUplink (UL) GTP Tunnel Endpoint IE）の組合せであってもよい。
【００２８】
図２は、リレー処理の必要性をX2 GW３に通知する手順の一例（処理２００）を示すシーケンス図である。ブロック２０１では、(H)eNB１又は２は、X2AP Message TransferメッセージをX2 GW３に送信する。当該X2AP Message Transferメッセージは、ソース(H)eNB１からターゲット(H)eNB２へのX2AP Handover Requestメッセージ又はターゲット(H)eNB２からソース(H)eNB１へのX2AP Handover Request Acknowledgeメッセージを運ぶ。当該X2AP Message Transferメッセージは、さらに、X2 GW３によるX2-Uリレー処理の必要性を明示的又は暗示的に示す表示を含む。X2 GW３は、当該表示に基づいて、X2-Uリレーの準備を行うべきか否かを認識することができる。
【００２９】
また、図２の例では、X2 GW３は、Handover Requestメッセージ又はHandover Request Acknowledgeメッセージを運ぶX2AP Message Transferメッセージと共に、X2-Uリレー処理の必要性を示す表示を受信する。したがって、X2 GW３は、当該X2AP Message Transferメッセージを参照することによって、X2-Uリレーに必要なGTP-Uトンネルの準備を容易に行うことができる。
【００３０】
以上の説明から理解されるように、本実施形態では、(H)eNBs１及び２の少なくとも一方は、X2 GW３によるU-plane（X2-U）リレーが必要とされるか否かを明示的又は暗示的に示す表示をX2 GW３に送信するよう構成されている。したがって、X2 GW３は、当該表示に基づいて、U-plane（X2-U）リレーを行うべきか否かを認識することができる。
【００３１】
さらに、本実施形態では、(H)eNBs１及び２の少なくとも一方は、(H)eNB１から(H)eNB２への無線端末（UE）のユーザデータパケットの転送が必要とされる場合に、当該UEのユーザデータパケットのフォワーディングのためにX2 GW３によるリレー処理を利用するか否かを決定するよう構成されてもよい。言い換えると、(H)eNBs１及び２は、(H)eNB１から(H)eNB２へのユーザデータパケットのフォワーディングのためにX2 GW３を介したリレーパス（１０１及び１０２）とダイレクトパス（１００）のどちらを利用するかを選択するよう構成されてもよい。X2 GW３によるリレー処理を利用しない場合、ソース(H)eNB１は、(H)eNBs１及び２の間のダイレクトパス、つまりX2-Uインタフェース（GTP-Uトンネル）１００を用いてユーザデータパケットをターゲット(H)eNB２にフォワーディングしてもよい。
【００３２】
いくつかの実装において、ソース(H)eNB１は、(H)eNB２へのUEのハンドオーバの開始を決定した場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。いくつかの実装において、ターゲット(H)eNB２は、ソース(H)eNB１からのハンドオーバ要求を受信した場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。いくつかの実装において、(H)eNB１は、Dual connectivityをサポートするUEに関するベアラ確立の要求（e.g., S1AP: Initial Context Setup Request）をEPC４から受信した場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。これらに代えて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かは、(H)eNBのペア毎に予め決定されてもよい。
【００３３】
いくつかの実装において、(H)eNB１若しくは２又はこれら両方は、ダイレクトパス１００の状態（e.g., ダイレクトパス１００の利用可否、ダイレクトパス１００のスループット、又はダイレクトパス１００の負荷）に応じて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB１若しくは２又はこれら両方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否か（又は要求するか否か）を決定する際に、ダイレクトパス１００の状態を考慮してもよい。
【００３４】
例えば、基地局間ダイレクトパス１００の最大または実効的なスループット（伝送速度）が (H)eNB１（又は２）とX2 GW３の間のパス１０１（又は１０２）のスループットよりも大きければ、基地局間ゲートウェイによるリレーを利用することは遅延の増大の観点から適切ではないかもしれない。したがって、(H)eNB１又は２は、基地局間ダイレクトパス１００のスループットが(H)eNB１とX2 GW３の間のパス１０１又は１０２のスループットよりも十分に大きい場合に、X2 GW３によるU-plane（X2-U）リレー処理を利用しないことを決定してもよい。これにより、不必要なU-planeリレーに起因する遅延の増大を抑制できる。
【００３５】
いくつかの実装において、(H)eNB１は、(H)eNB１のTNLアドレス（e.g., IPアドレス）を(H)eNB２から隠蔽する必要がある場合にX2 GW３によるU-plane（X2-U）リレー処理を利用し、TNLアドレスの隠蔽が必要でない場合にダイレクトパス１００を介したフォワーディングを実施してもよい。同様に、(H)eNB２は、(H)eNB２のTNLアドレス（e.g., IPアドレス）を(H)eNB１からの隠蔽の必要性に基づいて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB１若しくは２又はこれら両方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否か（又は要求するか否か）を決定する際に、TNLアドレスの隠蔽の必要性を考慮してもよい。
【００３６】
例えば、ソース(H)eNB１は、ハンドオーバの際に、自身のTNLアドレス（e.g., IPアドレス）をターゲット(H)eNB２から隠蔽することを必要とするかもしれない。これとは反対に、ターゲット(H)eNB２がそのTNLアドレス（e.g., IPアドレス）をソース(H)eNB１から隠蔽することを必要とするかもしれない。このTNLアドレスの隠蔽は、特定の基地局または特定の種別の基地局に対してのみ要求されるかもしれない。
【００３７】
HeNBは通信事業者によって管理される局舎（サイト）内ではなく、エンドユーザの家やビル内に設置されうる。そのため、HeNBは悪意のユーザによって改造されるおそれがあり、必ずしもセキュリティが十分に保証された装置とはいえない。したがって、ハンドオーバの際に、このようなHeNBに対してマクロeNBのX2-U TNLアドレスを知らせることは、マクロeNBがDenial of Service（DoS）攻撃を受ける等のセキュリティリスクを招くおそれがある。例えば、ソース(H)eNB１がマクロeNBであってターゲット(H)eNB２がHeNBである場合、ソース(H)eNB１は、X2 GW３によるU-plane（X2-U）リレー処理を利用することを決定してもよい。一方、ソース(H)eNB１がマクロeNBであってターゲット(H)eNB２もマクロeNBである場合、ソース(H)eNB１は、X2 GW３によるU-plane（X2-U）リレー処理を利用しないことを決定してもよい。これにより、マクロeNBのX2-U TNLアドレスをHeNBに知らせることに起因するセキュリティリスクを抑制できる。
【００３８】
いくつかの実装において、(H)eNB１若しくは２又はこれら両方は、X2 GW３のU-planeリレー能力（U-plane Relay Capability）に基づいて、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択してもよい。言い換えると、(H)eNB１若しくは２又はこれら両方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否か（又は要求するか否か）を決定する際に、X2 GW３のU-planeリレー能力の有無を考慮してもよい。
【００３９】
以上の説明から理解されるように、本実施形態では、(H)eNBs１及び２の少なくとも一方は、(H)eNB１から(H)eNB２へのUEのハンドオーバの際に、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを決定するよう構成されてもよい。これにより、(H)eNBs１及び２の少なくとも一方は、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを選択できる。
【００４０】
続いて以下では、ソース(H)eNB１、X2 GW３、及びターゲット(H)eNB２の動作の具体例について説明する。図３は、ソース(H)eNB１の動作の一例（処理３００）を示すフローチャートである。ブロック３０１では、(H)eNB１は、ターゲット(H)eNB２へのUEのハンドオーバの開始を判定する。ブロック３０２では、当該ハンドオーバの際に、X2 GW３によるU-plane（X2-U）リレー処理が必要とされるか否かを判定する。U-plane（X2-U）リレー処理が必要とされる場合（ブロック３０２でYES）、ソース(H)eNB１は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）に明示的又は暗示的なリレー要求を含める（ブロック３０３）。ブロック３０４では、ソース(H)eNB１は、ハンドオーバ要求を運ぶ転送メッセージ（リレー要求を含む）をX2 GW３に送信する。これに対して、U-plane（X2-U）リレー処理が必要とされない場合、（ブロック３０２でNO）、ソース(H)eNB１は、ハンドオーバ要求を運ぶ転送メッセージ（リレー要求を含まない）をX2 GW３に送信する（ブロック３０５）。
【００４１】
図４は、X2 GW３の動作の一例（処理４００）を示すフローチャートである。ブロック４０１では、X2 GW３は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）をソース(H)eNB１から受信する。ブロック４０２では、X2 GW３は、受信した転送メッセージ内にリレー要求が含まれているか否かを確認する。転送メッセージがリレー要求を含む場合（ブロック４０２でYES）、X2 GW３は、X2 GW３によるU-plane（X2-U）リレーが行われることを示す表示を転送メッセージ（ハンドオーバ要求を運ぶ）に追加し、これをターゲット(H)eNB２に送信する。
【００４２】
いくつかの実装において、X2 GW３によるU-plane（X2-U）リレーが行われることを示す当該表示は、U-plane（X2-U）リレーが行われるか否かを示す単純なフラグ情報であってもよい。さらに又はこれに代えて、図４のブロック４０３に示されているように、X2 GW３によるU-plane（X2-U）リレーが行われることを示す当該表示は、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定を含んでもよい。エンドポイント設定は、TNLアドレス（e.g., IPアドレス）及びTEIDを含む。当該エンドポイント設定は、ダウンリンク（DL）ユーザデータパケットのフォワーディングに使用されるX2トランスポートベアラに関するDL GTPトンネル・エンドポイント設定のみでもよいし、アップリンク（UL）ユーザデータパケットのフォワーディングに使用されるX2トランスポートベアラに関するUL GTPトンネル・エンドポイント設定をさらに含んでもよい。
【００４３】
X2 GW３が、ハンドオーバ要求を運ぶ転送メッセージと共に、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定をターゲット(H)eNB２に送信することによって、例えば以下に述べる効果が得られる。いくつかの実装において、ターゲット(H)eNB２は、Access Control List （ACL）機能（functionality）を有するかもしれない。ACL機能がターゲット(H)eNB２に適用された場合、ターゲット(H)eNB２は、送信ノードのソースアドレスをターゲット(H)eNB２において既に知っている場合に限り、送信ノードからのコネクションを受け入れる。このため、仮にターゲット(H)eNB２がX2 GW３のX2-U TNLアドレスを知らなければ、ターゲット(H)eNB２は、X2 GW３から送信されるG-PDUを運ぶTNL UDP/IPパケットをACL機能により破棄するおそれがある。これを回避するために、X2 GW３は、データフォワーディングの上流側であるが、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定をターゲット(H)eNB２に先に通知するとよい。これにより、ターゲット(H)eNB２は、X2 GW３のX2-U TNLアドレスからのコネクションを受け入れるようにACLを更新することができる。ACLは、パケットフィルタ又はファイヤウォール設定と言うこともできる。
【００４４】
図４に戻り説明を続ける。転送メッセージがリレー要求を含まない場合（ブロック４０２でNO）、X2 GW３は、ソース(H)eNB１から受信した転送メッセージをそのままターゲット(H)eNB２に送信する（ブロック４０４）。つまり、ブロック４０４で送信される転送メッセージは、X2 GW３によるU-plane（X2-U）リレーが行われることを示す表示を含まない。
【００４５】
図５は、ターゲット(H)eNB２の動作の一例（処理５００）を示すフローチャートである。ブロック５０１では、ターゲット(H)eNB２は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）をX2 GW３から受信する。ブロック５０２では、受信した転送メッセージが、X2トランスポートベアラ（i.e., GTP-Uベアラ）に関するX2 GW３側のエンドポイント設定を含むか否かを判定する。X2 GW３側のエンドポイント設定が含まれている場合（ブロック５０３でYES）、ターゲット(H)eNB２は、X2 GW３のX2-U TNLアドレスからのコネクションを受け入れるように自身のACLを更新する。
【００４６】
ブロック５０４では、ターゲット(H)eNB２は、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）を X2 GW ３に送信する。ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）は、ターゲット(H)eNB２のDL GTPトンネル・エンドポイント設定を含む。さらに、DLデータフォワーディングに加えてULデータフォワーディングが行われる場合、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）は、ターゲット(H)eNB２のUL GTPトンネル・エンドポイント設定を含む。ターゲット(H)eNB２のDL GTPトンネル・エンドポイント設定は、ソース(H)eNB１からフォワーディングされるDLユーザデータパケットを受信するためのGTP-Uトンネルに関するTNLアドレス及びTEIDを含む。ターゲット(H)eNB２のUL GTPトンネル・エンドポイント設定は、ソース(H)eNB１からフォワーディングされるULユーザデータパケットを受信するためのGTP-Uトンネルに関するTNLアドレス及びTEIDを含む。
【００４７】
なお、ブロック５０４において送信されるハンドオーバ要求承認メッセージを運ぶ転送メッセージは、ハンドオーバ要求承認メッセージ内に記述されているのと同じターゲット(H)eNB２のGTPトンネル・エンドポイント設定を示す追加の情報要素を含んでもよい。このようなメッセージ構成は冗長であるものの、X2 GW３がハンドオーバ要求承認メッセージをデコード又は参照しなくてもよいという利点がある。
【００４８】
図３〜図５に示されたソース(H)eNB１、X2 GW３、及びターゲット(H)eNB２の動作は一例であって適宜変更されてもよい。例えば、図３においてリレー要求の送信に使用されるメッセージは、X2AP Message Transferメッセージとは異なるX2APメッセージであってもよい。例えば、リレー要求は、X2AP Message Transferメッセージによって運ばれるHandover Requestメッセージ内にセットされてもよい。図４において、X2 GW３のエンドポイント設定の送信に使用されるメッセージは、X2AP Message Transferメッセージとは異なるX2APメッセージであってもよい。例えば、X2 GW３のエンドポイント設定は、X2AP Message Transferメッセージによって運ばれるHandover Requestメッセージ内にセットされてもよい。
【００４９】
図３〜図５は、ハンドオーバ要求の際に、ソース(H)eNB１がX2 GW３によるU-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定する例について示した。これと同様に、ハンドオーバ要求をソース(H)eNB１からX2 GW３を介して受信した場合に、ターゲット(H)eNB２は、ソース(H)eNB１がX2 GW３によるU-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定してもよい。すなわち、ソース(H)eNB１によるX2 GW３によるU-plane（X2-U）リレーの要否判定とは独立に、ターゲット(H)eNB２は、X2 GW３によるU-plane（X2-U）リレーの要否を判定してもよい。
【００５０】
図６は、ターゲット(H)eNB２によって行われるU-plane（X2-U）リレーの要否判定を含む動作の一例（処理６００）を示すフローチャートである。ブロック６０１では、ターゲット(H)eNB２は、ハンドオーバ要求（i.e., Handover Requestメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）をX2 GW３から受信する。ブロック６０２では、ターゲット(H)eNB２は、X2 GW３によるU-plane（X2-U）リレー処理が必要とされるか否かを判定する。U-plane（X2-U）リレー処理が必要とされる場合（ブロック６０２でYES）、ターゲット(H)eNB２は、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）を運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）に明示的又は暗示的なリレー要求を含める（ブロック６０３）。ブロック６０４では、ターゲット(H)eNB２は、ハンドオーバ要求承認を運ぶ転送メッセージ（リレー要求を含む）をX2 GW３に送信する。これに対して、U-plane（X2-U）リレー処理が必要とされない場合、（ブロック６０２でNO）、ターゲット(H)eNB２は、ハンドオーバ要求承認を運ぶ転送メッセージ（リレー要求を含まない）をX2 GW３に送信する（ブロック６０５）。
【００５１】
ハンドオーバ要求承認を運ぶ転送メッセージ（リレー要求を含む）をターゲット(H)eNB２から受信したときのX2 GW３の動作は、図４と同様であってもよい。ただし、図５に関して説明したように、ハンドオーバ要求承認（i.e., Handover Request Acknowledgeメッセージ）は、ターゲット(H)eNB２のGTPトンネル・エンドポイント設定を含む。いくつかの実装において、ブロック４０３に相当する処理において、X2 GW３は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定を、X2 GW３のGTPトンネル・エンドポイント設定によって書き換えてもよい。
【００５２】
これに代えて、ブロック４０３に相当する処理において、X2 GW３は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定に修正を加えずに、X2 GW３のエンドポイント設定を示す追加の情報要素をX2AP Message Transferメッセージに含めてもよい。この場合、ソース(H)eNB１は、追加の情報要素に従ってX2トランスポートベアラコンテキストを更新し、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定を無視すればよい。
【００５３】
ただし、ターゲット(H)eNB２のTNLアドレスをソース(H)eNB１から隠蔽するためにX2 GW３によるU-plane（X2-U）リレーが行われる場合、X2 GW３は、Handover Request Acknowledgeメッセージ内に記述されているターゲット(H)eNB２のGTPトンネル・エンドポイント設定を修正することが好ましい。これにより、ターゲット(H)eNB２のTNLアドレスのソース(H)eNB１からの隠蔽を確実に行うことができる。
【００５４】
図３〜図６は、ハンドオーバにおける (H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例を示した。しかしながら、既に説明したことから理解されるように、図３〜図６を用いて説明された(H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例は、Dual connectivityをサポートするUEに関するベアラ確立を行う際に適用されてもよい。例えば、(H)eNB１は、Dual connectivityをサポートするUEに関するベアラ確立の要求をEPC４から受信したことに応答して、X2 GW３によるU-plane（X2-U）リレー処理を利用するか否かを判定してもよい。そして、(H)eNB１は、Dual connectivityのためのUEコンテキストの確立のためのX2APメッセージを運ぶ転送メッセージ（i.e., X2AP Message Transferメッセージ）に明示的又は暗示的なリレー要求を含めてもよい。
【００５５】
続いて以下では、ソース(H)eNB１およびX2 GW３の動作とその起動条件の具体例について図７及び図８を用いて説明する。図７は、ソース(H)eNB１およびX2 GW３の動作とその起動条件の組み合せの一例を示すテーブルである。図７の例では、ソース(H)eNB１は、U-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定するために、ダイレクトパス１００の利用可否（Direct Path Availability）及びX2 GW３のリレー能力（U-plane Relay Capability）を参酌する。
【００５６】
図７に示されたケース１は、ダイレクトパス１００が利用可能であり、X2 GW３がリレー能力を有する場合である。図７に示されたケース２は、ダイレクトパス１００が利用でき、X2 GW３がリレー能力を有していない場合である。ケース１及びケース２では、ダイレクトパス１００が利用可能であるため、ソース(H)eNB１は、X2 GW３に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ（Handover Requestメッセージを運ぶ）に設定しない。したがって、X2 GW３は、DLデータフォワーディングに関するU-plane（X2-U）リレーを実施しない。
【００５７】
図７に示されたケース３は、ダイレクトパス１００が利用不可であり、X2 GW３がリレー能力を有する場合である。ケース３では、ダイレクトパス１００が利用不可であるが、X2 GW３がリレー能力を有するため、ソース(H)eNB１は、X2 GW３に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ（Handover Requestメッセージを運ぶ）に設定する。したがって、X2 GW３は、DLデータフォワーディングに関するU-plane（X2-U）リレーを実施する。
【００５８】
図７に示されたケース４は、ダイレクトパス１００が利用不可であり、且つX2 GW３がリレー能力を有していない場合である。ケース４では、X2-Uデータフォワーディングが不可能であるから、ソース(H)eNB１は、X2 GW３に対する明示的又は暗示的なリレー要求をX2AP Message Transferメッセージ（Handover Requestメッセージを運ぶ）に設定しない。したがって、X2 GW３は、DLデータフォワーディングに関するU-plane（X2-U）リレーを実施しない。
【００５９】
なお、既に説明したように、いくつかの実装において、X2 GW３に対する暗示的なリレー要求（又はリレー表示）は、複数の情報要素の組み合せを含んでもよい。例えば、図８に示されているように、X2 GW３に対する暗示的なリレー要求（又はリレー表示）は、Direct Path Unavailability IEおよびDL Forwarding IEの組み合せであってもよい。図８に示されたDirect Path Unavailability IEは、ダイレクトパス１００が利用不可能であるときに設定される。Direct Path Unavailability IEは、１ビットのフラグ情報であってもよい。図８に示されたDL Forwarding IEは、現在の3GPP仕様においてX2AP: Handover Requestメッセージに含まれているDL Forwarding IEであってもよいし、X2AP Message Transferメッセージに新たに追加される情報要素であってもよい。
【００６０】
図８に示されたケース１〜４は、図７に示されたケース１〜４にそれぞれ対応する。すなわち、図８に示されたケース１は、ダイレクトパス１００が利用可能であり、X2 GW３がリレー能力を有する場合である。図８に示されたケース２は、ダイレクトパス１００が利用でき、X2 GW３がリレー能力を有していない場合である。ケース１及びケース２では、ダイレクトパス１００が利用可能であるため、ソース(H)eNB１は、Direct Path Unavailability IEを設定しない。一方、（ダイレクトパス１００を介して）DLフォワーディングを行うことをターゲット(H)eNB２に知らせるために、DL Forwarding IEを設定する。
【００６１】
図８に示されたケース３は、ダイレクトパス１００が利用不可であり、X2 GW３がリレー能力を有する場合である。ケース３では、ダイレクトパス１００が利用不可であるため、Direct Path Unavailability IEを設定する。さらに、ダイレクトパス１００を利用できないもののX2 GW３がリレー能力を有することから、ソース(H)eNB１は、X2 GW３を介したDLフォワーディングが可能であると判断し、したがって（X2 GW３を介して）DLフォワーディングを行うことをターゲット(H)eNB２に知らせるために、DL Forwarding IEを設定する。
【００６２】
図８に示されたケース４は、ダイレクトパス１００が利用不可であり、且つX2 GW３がリレー能力を有していない場合である。したがって、ケース４では、ソース(H)eNB１は、Direct Path Unavailability IEを設定し、DL Forwarding IEを設定しない。
【００６３】
図８の例では、X2 GW３は、Direct Path Unavailability IEおよびDL Forwarding IEを参照し、これらが共に設定されている場合にDLデータフォワーディングに関するU-Plane（X2-U）リレーを実施すればよい。したがって、図７の例と同様に、図８のケース３のみDLデータフォワーディングに関するU-Plane（X2-U）リレーが実施され、図８のケース１、２及び４ではDLデータフォワーディングに関するU-Plane（X2-U）リレーが実施されない。
【００６４】
続いて以下では、ターゲット(H)eNB２およびX2 GW３の動作とその起動条件の具体例について図９及び図１０を用いて説明する。図９は、ターゲット(H)eNB２およびX2 GW３の動作とその起動条件の組み合せの一例を示すテーブルである。ターゲット(H)eNB２に関する図９の例は、ソース(H)eNB１に関する図７の例と対応する。したがって、図９のケース３のみULデータフォワーディングに関するU-Plane（X2-U）リレーが実施され、図９のケース１、２及び４ではULデータフォワーディングに関するU-Plane（X2-U）リレーが実施されない。
【００６５】
図１０の例では、ターゲット(H)eNB２からX2 GW３に対する暗示的なリレー要求（又はリレー表示）が、Direct Path Unavailability IEおよびUL GTP Tunnel Endpoint IEの組み合せとされている。図１０に示されたUL GTP Tunnel Endpoint IEは、現在の3GPP仕様においてX2AP: Handover Request Acknowledgeメッセージに含まれているUL GTP Tunnel Endpoint IEであってもよいし、X2AP Message Transferメッセージに新たに追加される情報要素であってもよい。
【００６６】
ターゲット(H)eNB２に関する図１０の例は、DL Forwarding IEとUL GTP Tunnel Endpoint IEの違いを除いて、ソース(H)eNB１に関する図８の例に対応する。すなわち、図１０の例では、X2 GW３は、Direct Path Unavailability IEおよびUL GTP Tunnel Endpoint IEを参照し、これらが共に設定されている場合にULデータフォワーディングに関するU-Plane（X2-U）リレーを実施すればよい。したがって、図１０のケース３のみULデータフォワーディングに関するU-Plane（X2-U）リレーが実施され、図１０のケース１、２及び４ではULデータフォワーディングに関するU-Plane（X2-U）リレーが実施されない。
【００６７】
図７〜図１０は、ハンドオーバにおける (H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例を示した。しかしながら、既に説明したことから理解されるように、図７〜図１０を用いて説明された(H)eNB１、(H)eNB２、及びX2 GW３の動作の具体例は、Dual connectivityをサポートするUEに関するベアラ確立を行う際に適用されてもよい。
【００６８】
図７〜図１０を用いて説明された例では、(H)eNB１及び(H)eNB２は、U-plane（X2-U）リレーを利用するか否か（又は要求するか否か）を判定する際に、X2 GW３のリレー能力の有無を考慮する。X2 GW３のリレー能力の有無は、オペレータによって、つまりoperations, administration and maintenance（OAM）によって、(H)eNBs１及び２に予め設定されてもよい。これに代えて、X2 GW３は、自身のリレー能力の有無を(H)eNBs１及び２に知らせてもよい。すなわち、X2 GW３は、自身のリレー能力の有無を示す情報要素（IE）を含むシグナリングメッセージを(H)eNBs１及び２に送信してもよい。いくつかの実装において、図１１及び図１２に示されるように、X2 GW３は、(H)eNBs１及び２をX2 GW３に登録する手順において、自身のリレー能力を(H)eNBs１及び２に知らせてもよい。
【００６９】
図１１は、リレー能力の有無をX2 GW３から(H)eNBs１及び２に通知する手順の一例（処理１１００）を示すシーケンス図である。ブロック１１０１では、(H)eNBs１（２）は、登録要求をX2 GW３に送信する（(H)eNB registration）。当該登録要求は、登録要求に含まれる送信元(H)eNBの識別子（i.e., Global eNB ID）と登録要求の送信に使用された送信元(H)eNBのTNLアドレス（e.g., IPアドレス）のマッピングを保存する。そして、ブロック１１０２では、X2 GW３は、登録要求に対する応答を送信する（(H)eNB registration response）。当該応答は、X2 GW３のリレー能力の有無を示す情報要素（U-plane Relay Capability）を含む。(H)eNBs１（２）は、ブロック１１０２での応答を受信することにより、X2 GW３のU-plane（X2-U）リレー能力の有無を認識する。
【００７０】
図１２は、リレー能力の有無をX2 GW３から(H)eNBs１及び２に通知する手順の他の例（処理１２００）を示すシーケンス図である。3GPP Release 12では、(H)eNBのX2 GWへの登録のために、X2AP Message Transferメッセージが使用される。図１２は、3GPP Release 12と同様にX2AP Message Transferメッセージを利用する例を示している。すなわち、ブロック１２０１では、登録を要求する(H)eNB１（２）は、RNL Header IE内にSource (H)eNB IDを含むが、RNL Header IE内にTarget (H)eNB IDを含まず、かつX2AP Messageを含まないX2AP Message Transferメッセージを送信する。ブロック１２０２では、X2 GW３は、変更されたX2AP Message Transferメッセージを送信する。当該変更されたX2AP Message Transferメッセージは、RNL Header IE内にTarget (H)eNB IDを含み、新たに定義されたU-plane Relay Capability IEを含むが、RNL Header IE内にSource (H)eNB IDを含まず、かつX2AP Messageを含まないX2AP Message Transferメッセージを送信する。(H)eNBs１（２）は、ブロック１２０２でのX2AP Message Transferメッセージを受信することにより、X2 GW３のU-plane（X2-U）リレー能力の有無を認識する。
【００７１】
図１３Ａ及び図１３Ｂは、本実施形態に係るX2ハンドオーバ手順の一例（処理１３００）を示すシーケンス図である。図１３Ａ及び図１３Ｂに示された手順は、ソース(H)eNB１からターゲット(H)eNB２へのユーザデータパケットのフォワーディングがX2 GW３を介して行われること（ブロック１３０７及び１３０８）を除いて、通常のX2 GWを介するX2ハンドオーバ手順と同様である。すなわち、ブロック１３０１では、ソース(H)eNB１は、Handover Requestメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。既に説明したように、当該X2AP Message Transferメッセージは、U-plane（X2-U）リレーの要否を明示的又は暗示的に示す情報要素を含んでもよい。ブロック１３０２では、X2 GW３は、Handover Requestメッセージを運ぶX2AP Message Transferメッセージをターゲット(H)eNB２に転送する。既に説明したように、X2 GW３は、U-plane（X2-U）リレーを行うか否かに応じて、ブロック１３０２でのX2AP Message Transferメッセージ内の情報要素を更新してもよいし、情報要素を追加してもよい。
【００７２】
ブロック１３０３では、ターゲット(H)eNB２は、Handover Request Acknowledgeメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。既に説明したように、当該X2AP Message Transferメッセージは、U-plane（X2-U）リレーの要否を明示的又は暗示的に示す情報要素を含んでもよい。ブロック１３０４では、X2 GW３は、Handover Request Acknowledgeメッセージを運ぶX2AP Message Transferメッセージをソース(H)eNB１に転送する。既に説明したように、X2 GW３は、U-plane（X2-U）リレーを行うか否かに応じて、ブロック１３０４でのX2AP Message Transferメッセージ内の情報要素を更新してもよいし、情報要素を追加してもよい。
【００７３】
ソース(H)eNB１は、Handover Request Acknowledgeメッセージの受信に応答して、図示されていないUEにハンドオーバ指示（Handover Command）を送信する。ブロック１３０５では、ソース(H)eNB１は、SN Status Transferメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。SN Status Transferメッセージは、UEへの送達が完了してないuplink/downlink Packet Data Convergence Protocol（PDCP） PDUのSequence Number（SN）を示す。ブロック１３０６では、X2 GW３は、SN Status Transferメッセージを運ぶX2AP Message Transferメッセージをターゲット(H)eNB２に転送する。
【００７４】
ブロック１３０７及び１３０８では、ソース(H)eNB１は、UEへの送達が完了していないuplink/downlink ユーザデータパケットを、X2 GW３を介してターゲット(H)eNB２にフォワーディングする。すなわち、ブロック１３０７では、ソース(H)eNB１は、ソース(H)eNB１とX2 GW３の間のGTP-Uトンネルを介して、uplink/downlink ユーザデータパケットをカプセル化しているG-PDUをX2 GW３に送信する。ブロック１３０８では、X2 GW３は、ターゲット(H)eNB２とX2 GW３の間のGTP-Uトンネルを介して、ソース(H)eNB１から受信したG-PDUをターゲット(H)eNB２に転送する。
【００７５】
ブロック１３０７及び１３０８のデータフォワーディングでは、X2GW３は、ソース(H)eNB１から受信したG-PDUに付与されているソースTNLアドレス（i.e., ソース(H)eNB１のTNLアドレス）をX2GW３のTNLアドレスによって更新し、ソースTEID（i.e., ソース(H)eNB１のTEID）をX2GW３のTEIDによって更新する。さらに、X2GW３は、ソース(H)eNB１から受信したG-PDUに付与されているターゲットTNLアドレス（i.e., X2GW３のTNLアドレス）をターゲット(H)eNB２のTNLアドレスによって更新し、ターゲットTEID（i.e., X2GW３のTEID）をターゲット(H)eNB２のTEIDによって更新する。
【００７６】
ブロック１３０９では、ターゲット(H)eNB２は、UEからハンドオーバ確認（Handover Confirm）メッセージを受信する。これにより、UEは、ターゲット(H)eNB２にULユーザデータパケットを送信することができ、DLユーザデータパケットをターゲット(H)eNB２から受信できる。
【００７７】
ブロック１３１０では、ターゲット(H)eNB２は、UEのサービングセルの変更をEPC４に知らせるとともにEvolved Packet System （EPS）ベアラの経路変更を要求するために、S1AP: Path Switch RequestメッセージをEPC４（つまり、Mobility Management Entity（MME）５）に送信する。MME５は、図示していないServing Gateway（S−GW）とシグナルし、EPSベアラの経路（つまり、S1ベアラの経路）を修正する。ブロック１３１１では、MME５は、S1AP: Path Switch Request Acknowledgeメッセージをターゲット(H)eNB２に送信する。ブロック１３１２では、Path Switch Request Acknowledgeメッセージの受信に応答して、ターゲット(H)eNB２は、UE Context Releaseメッセージを運ぶX2AP Message TransferメッセージをX2 GW３に送信する。ブロック１３１３では、X2 GW３は、UE Context Releaseメッセージを運ぶX2AP Message Transferメッセージをソース(H)eNB１に転送する。ソース(H)eNB１は、UE Context Releaseメッセージの受信に応答して、UEに割り当てた無線リソースを解放する。
【００７８】
なお、ターゲット(H)eNB２は、UE Context Releaseメッセージの送信（ブロック１３１２）に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。X2 GW３は、UE Context Releaseメッセージを運ぶX2AP Message Transferメッセージの受信（ブロック１３１２）に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。ソース(H)eNB１は、UE Context Releaseメッセージの受信（ブロック１３１３）に応答して、データフォワーディングのためのGTP-Uトンネル設定を開放してもよい。
【００７９】
続いて以下では、X2AP Message Transferメッセージの変更（modification）の具体例について、図１４並びに図１５Ａ及び図１５Ｂを用いて説明する。図１４は、X2AP Message Transferメッセージの変更の一例を示している。“U-Plane Relay Capability” IEは、U-plane（X2-U）リレー能力の有無を(H)eNBs１及び２に知らせるためにX2 GW３によって使用される。“Direct Path Unavailability” IEは、ダイレクトパス１００の利用可否をX2 GW３に知らせるために(H)eNBs１及び２によって使用される。“E-RABs To Be Setup List” IEは、X2 GW３のEndpoint設定を(H)eNBs１及び２に知らせるためにX2 GW３によって使用される。
【００８０】
“E-RABs To Be Setup List” IEは、“E-RABs To Be Setup Item” IEを含む。“E-RABs To Be Setup Item” IEは、“E-RAB ID” IE、“UL GTP Tunnel Endpoint” IE、及び“DL GTP Tunnel Endpoint” IEを含む。“UL GTP Tunnel Endpoint” IEは、ULデータ（UL PDUs）フォワーディングのためのX2トランスポートベアラに関するX2 GW３のEndpoint設定（つまり、TNLアドレス及びTEID）を示す。“DL GTP Tunnel Endpoint” IEは、DLデータ（DL PDUs）フォワーディングのためのX2トランスポートベアラに関するX2 GW３のEndpoint設定（つまり、TNLアドレス及びTEID）を示す。
【００８１】
図１５Ａ及び図１５Ｂは、X2AP Message Transferメッセージの変更の他の例を示している。図１５Ａに示されているように、X2AP Message Transferメッセージは、“Message Type of X2AP Message” IEを含むように拡張されてもよい。“Message Type of X2AP Message” IEは、X2AP Message Transferメッセージによって運ばれるX2APメッセージの種別を示す。これにより、X2 GW３は、必要なX2APメッセージのみ参照又はデコードするように動作することができる。すなわち、“Message Type of X2AP Message” IE がHandover Requestメッセージ又はHandover Request Acknowledgeメッセージを示す場合にのみ、X2AP Message Transferメッセージ内の“X2AP message” IEを参照又はデコードしてもよい。
【００８２】
さらに又はこれに代えて、図１５Ｂに示されるように、X2AP Message Transferメッセージは、“DL Forwarding” IEを含むように拡張されてもよい。“DL Forwarding” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB１によって使用される。“DL Forwarding” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“DL Forwarding” IEと同じ内容を示す。これにより、X2 GW３は、“DL Forwarding” IE を確認するために“X2AP message” IE内のHandover Requestメッセージをデコード又は参照する必要がなくなる。
【００８３】
これと同じ思想に従って、X2AP Message Transferメッセージは、図１５Ｂに示された“E-RAB Level QoS Parameters” IEを含むように拡張されてもよい。“E-RAB Level QoS Parameters” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB１によって使用される。“E-RAB Level QoS Parameters” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“E-RAB Level QoS Parameters” IEと同じ内容を示す。
【００８４】
これと同じ思想に従って、図１５Ｂに示された“E-RAB ID” IEは、“X2AP message” IEがHandover Requestメッセージを運ぶ場合に、ソース(H)eNB１によって使用されてもよい。この場合、“E-RAB ID” IEは、“X2AP message” IE内のHandover Requestメッセージに含まれる“E-RAB ID” IEと同じ内容を示す。さらに、図１５Ｂに示された“E-RAB ID” IEは、“X2AP message” IEがHandover Request Acknowledgeメッセージを運ぶ場合に、ターゲット(H)eNB２によって使用されてもよい。この場合、“E-RAB ID” IEは、“X2AP message” IE内のHandover Request Acknowledgeメッセージに含まれる“E-RAB ID” IEと同じ内容を示す。
【００８５】
これと同じ思想に従って、図１５Ｂに示された“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEは、“X2AP message” IEがHandover Request Acknowledgeメッセージを運ぶ場合に、ターゲット(H)eNB２によって使用されてもよい。この場合、“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEは、“X2AP message” IE内のHandover Request Acknowledgeメッセージに含まれる“DL GTP Tunnel Endpoint” IE及び“UL GTP Tunnel Endpoint” IEと同じ内容を示す。
【００８６】
このように、Handover Request メッセージ及びHandover Request Acknowledgeメッセージ内の複数の情報要素のうち、U-plane（X2-U）リレーのためにX2 GW３が参照しなければならない一部の情報要素をX2AP Message Transferメッセージに含めることによって以下の利点がある。すなわち、X2 GW３は、X2AP Message IEを透過的に転送すればよく、X2AP Message IEの参照又はデコードを行う必要がない。もしX2 GW３が常にX2AP Message IE の参照又はデコードすると、X2 GW３の処理能力を大きく消費するかもしれないし、X2 GW３のプロトコルバージョンと(H)eNB間のX2APプロトコルバージョンが異なることでプロトコルエラーが発生するかもしれない。X2 GW３は、X2AP Message IEを透過的に転送することで、これらの問題の発生を回避することができる。
【００８７】
なお、図１５Ａ及び図１５Ｂに示すように、Handover Requestメッセージ又はHandover Request Acknowledgeメッセージ内の情報要素と同一内容を持つ情報要素がX2AP Message Transferメッセージに追加される場合、これらの追加された情報要素（例えば、“DL Forwarding” IE、“E-RAB Level QoS Parameters” IE、“E-RAB ID” IE、“DL GTP Tunnel Endpoint” IE、及び“UL GTP Tunnel Endpoint” IEのうち少なくとも１つ）は、暗示的なリレー要求（又はリレー表示）として利用されてもよい。すなわち、X2 GW３は、X2AP Message Transferメッセージが追加された情報要素を含むか否かに応じて、(H)eNB１又は２からのリレー要求の有無を検出してもよい。この場合、X2AP Message Transferメッセージは、“Direct Path Unavailability” IE（又はその他の明示的又は暗示的なリレー要求）を含まなくてもよい。
【００８８】
＜第２の実施形態＞
本実施形態では、X2 GW３のX2-U TNLアドレス（e.g., IPアドレス）をターゲット(H)eNB２に知らせる手順の具体例を説明する。第１の実施形態では、X2 GW３のX2-U TNLアドレスがOAMによってターゲット(H)eNB２に設定される例、及びX2AP Message Transferメッセージを用いてX2 GW３からターゲット(H)eNB２にX2 GW３のX2-U TNLアドレスが通知される例を示した。これらに代えて、改良されたEnhanced TNL Address Discovery手順が使用されてもよい。
【００８９】
Enhanced TNL Address Discovery手順は、非特許文献１のセクション4.6.6.1に規定されている。Enhanced TNL Address Discovery手順では、(H)eNBは、当該(H)eNBが接続されているX2 GWのTNLアドレスをS1AP: eNB CONFIGURATION TRANSFERメッセージに含め、X2 GWのTNLアドレスを含むeNB CONFIGURATION TRANSFERメッセージをMMEに送信する。MMEは、eNB CONFIGURATION TRANSFERメッセージに含まれるtarget eNB ID及びX2 GWのTNLアドレスを取得し、S1AP: MME CONFIGURATION TRANSFERメッセージを用いてtarget eNB IDにX2 GWのTNLアドレスを転送する。これにより、２つの(H)eNBは、X2 GWのTNLアドレスを認識でき、当該X2 GWを介したインダイレクトX2を利用できる。
【００９０】
しかしながら、既存のEnhanced TNL Address Discovery手順によって転送されるX2 GWのTNLアドレスは、SCTPコネクションにおいてX2APシグナリングメッセージを転送するためのTNLアドレス（つまり、X2-C TNLアドレス）であることに留意するべきである。本実施形態では、G-PDUを運ぶTNL UDP/IPパケットを転送するためのX2 GWのTNLアドレス（つまり、X2-U TNLアドレス）を転送するように、Enhanced TNL Address Discovery手順が変更される。
【００９１】
図１６は、本実施形態に係るEnhanced TNL Address Discovery手順の一例（処理１６００）を示すシーケンス図である。図１６の手順は、X2 GW U-plane アドレス（X2-U TNLアドレス）が送られる点を除いて、既存のEnhanced TNL Address Discovery手順と同様である。すなわち、ブロック１６０１では、ソース(H)eNB１は、S1AP: eNB CONFIGURATION TRANSFERメッセージをMME５に送信する。当該eNB CONFIGURATION TRANSFERメッセージは、X2 GW３のU-plane アドレス（X2-U TNLアドレス）を含む。ブロック１６０２では、MME５は、S1AP: MME CONFIGURATION TRANSFERメッセージをターゲット(H)eNB２に送信する。当該MME CONFIGURATION TRANSFERメッセージは、ソース(H)eNB１から受信したX2 GW３のU-plane アドレス（X2-U TNLアドレス）を含む。
【００９２】
ブロック１６０３では、ターゲット(H)eNB２は、受信したX2 GW３のU-plane アドレス（X2-U TNLアドレス）をACLに追加する。ブロック１６０４では、ターゲット(H)eNB２は、S1AP: eNB CONFIGURATION TRANSFERメッセージをMME５に送信する。当該eNB CONFIGURATION TRANSFERメッセージは、ソース(H)eNB１に対する応答である。ブロック１６０５では、MME５は、S1AP: MME CONFIGURATION TRANSFERメッセージをソース(H)eNB１に送信する。MME CONFIGURATION TRANSFERメッセージは、ターゲット(H)eNB２からeNB CONFIGURATION TRANSFERメッセージにより受信した情報要素（e.g., ターゲット(H)eNB２がソース(H)eNB１から受信したX2 GW３のU-plane アドレス）を含む。
【００９３】
図１７Ａ及び図１７Ｂは、3GPP TS 36.413 V12.4.0のセクション9.2.3.29 に規定されている“X2 TNL Configuration Info” IEの変更の具体例を示している。“X2 TNL Configuration Info” IEは、S1AP: eNB CONFIGURATION TRANSFERメッセージ及びS1AP: MME CONFIGURATION TRANSFERメッセージに含まれる。図１７Ｂに示されているように、“X2 TNL Configuration Info” IEは、インダイレクトX2 U-plane エンドポイントに関するTNLアドレス（つまり、X2 GW３のX2-U TNLアドレス）を示す“Transport Layer Address” IEを含むように拡張されてもよい。
【００９４】
最後に、上述の複数の実施形態に係る(H)eNB１、(H)eNB２、及びX2 GW３の構成例について説明する。図１８は、(H)eNB１の構成例を示すブロック図である。(H)eNB２も、図１８の構成と同様の構成を有してもよい。図１８を参照すると、(H)eNB１は、RFトランシーバ１８０１、ネットワークインターフェース１８０３、プロセッサ１８０４、及びメモリ１８０５を含む。RFトランシーバ１８０１は、UEsと通信するためにアナログRF信号処理を行う。RFトランシーバ１８０１は、複数のトランシーバを含んでもよい。RFトランシーバ１８０１は、アンテナ１８０２及びプロセッサ１８０４と結合される。RFトランシーバ１８０１は、変調シンボルデータ（又はOFDMシンボルデータ）をプロセッサ１８０４から受信し、送信RF信号を生成し、送信RF信号をアンテナ１８０２に供給する。また、RFトランシーバ１８０１は、アンテナ１８０２によって受信された受信ＲＦ信号に基づいてベースバンド受信信号を生成し、これをプロセッサ１８０４に供給する。
【００９５】
ネットワークインターフェース１８０３は、ネットワークノード（e.g., MMEおよびS/P-GW）と通信するために使用される。ネットワークインターフェース１８０３は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。
【００９６】
プロセッサ１８０４は、無線通信のためのデジタルベースバンド信号処理を含むデータプレーン処理とコントロールプレーン処理を行う。例えば、LTEおよびLTE-Advancedの場合、プロセッサ１８０４によるデジタルベースバンド信号処理は、PDCPレイヤ、RLCレイヤ、MACレイヤ、およびPHYレイヤの信号処理を含んでもよい。さらに、プロセッサ１８０４による信号処理は、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を含んでもよい。また、プロセッサ１８０４によるコントロールプレーン処理は、X2APプロトコル、S1-MMEプロトコルおよびRRCプロトコルの処理を含んでもよい。
【００９７】
プロセッサ１８０４は、複数のプロセッサを含んでもよい。例えば、プロセッサ１８０４は、プロセッサ１８０４は、デジタルベースバンド信号処理を行うモデム・プロセッサ（e.g., DSP）、X2-Uインタフェース及びS1-UインタフェースでのGTP-U・UDP/IPレイヤの信号処理を行うプロセッサ（e.g., DSP）、及びコントロールプレーン処理を行うプロトコルスタック・プロセッサ（e.g., CPU又はMPU）を含んでもよい。
【００９８】
メモリ１８０５は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１８０５は、物理的に独立した複数のメモリデバイスを含んでもよい。揮発性メモリは、例えば、Static Random Access Memory（SRAM）若しくはDynamic RAM（DRAM）又はこれらの組み合わせである。不揮発性メモリは、マスクRead Only Memory（MROM）、Electrically Erasable Programmable ROM（EEPROM）、フラッシュメモリ、若しくはハードディスクドライブ、又はこれらの任意の組合せである。メモリ１８０５は、プロセッサ１８０４から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１８０４は、ネットワークインターフェース１８０３又は図示されていないI/Oインタフェースを介してメモリ１８０５にアクセスしてもよい。
【００９９】
メモリ１８０５は、上述の複数の実施形態で説明された(H)eNB１による処理を行うための命令群およびデータを含むソフトウェアモジュール（コンピュータプログラム）を格納してもよい。いくつかの実装において、プロセッサ１８０４は、当該ソフトウェアモジュールをメモリ１８０５から読み出して実行することで、上述の実施形態で説明された(H)eNB１の処理を行うよう構成されてもよい。
【０１００】
図１９は、X2 GW３の構成例を示すブロック図である。図１６を参照すると、X2 GW３は、ネットワークインターフェース１９０１、プロセッサ１９０２、及びメモリ１９０３を含む。ネットワークインターフェース１９６０１は、ネットワークノード（e.g., (H)eNB１及び(H)eNB２）と通信するために使用される。ネットワークインターフェース１９０１は、例えば、IEEE 802.3 seriesに準拠したネットワークインターフェースカード（NIC）を含んでもよい。
【０１０１】
プロセッサ１９０２は、メモリ１９０３からソフトウェア（コンピュータプログラム）を読み出して実行することで、上述の実施形態において説明されたX2 GW３の処理を行う。プロセッサ１９０２は、例えば、マイクロプロセッサ、MPU、又はCPUであってもよい。プロセッサ１９０２は、複数のプロセッサを含んでもよい。
【０１０２】
メモリ１９０３は、揮発性メモリ及び不揮発性メモリの組み合わせによって構成される。メモリ１９０３は、プロセッサ１９０２から離れて配置されたストレージを含んでもよい。この場合、プロセッサ１９０２は、図示されていないI/Oインタフェースを介してメモリ１９０３にアクセスしてもよい。
【０１０３】
図１８及び図１９を用いて説明したように、上述の実施形態に係る(H)eNB１、(H)eNB２、及びX2 GW３が有するプロセッサの各々は、図面を用いて説明されたアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムを実行する。このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１０４】
＜その他の実施形態＞
上述の実施形態は、各々独立に実施されてもよいし、適宜組み合わせて実施されてもよい。
【０１０５】
上述の実施形態では、X2 GWのX2-UインタフェースにおいてGTP-Uプロトコルが使用される例を示した。しかしながら、GTP-Uプロトコルとは異なるプロトコル、例えばProxy Mobile. IPv6（PMIPv6）が使用されてもよい。
【０１０６】
上述の実施形態は、例えば、UMTS及びGSMシステム等の他の無線通信システムに適用されてもよい。上述の実施形態で説明された基地局（(H)eNB）は、無線リソース管理機能を持つ制御ノード（e.g., UMTSにおけるRadio Network Controller（RNC）、又はGSMシステムにおけるBase Station Controller（BSC））及び無線送信ノード（e.g., UMTSにおけるNodeB、又はGSMシステムにおけるBase transceiver station （BTS））を含んでもよい。
【０１０７】
例えば、3GPP TS25.467に示されるように、Home NodeB（HNB）がHome NodeB Gateway（HNB-GW）を経由してRNCにIur接続する場合に、HNBとRNC間においてHNB-GW経由でrelocationを実施することができる。この場合に、HNBは、RNSAP: Enhanced Relocation RequestメッセージをIurhインタフェース上でHNB-GW経由で送る。そして、HNB-GWは、Iurインタフェース上でRNSAP: Enhanced Relocation RequestメッセージをSignalling Connection Control Part（SCCP）を用いて転送する。この場合、HNB-GWは、HNBとRNCの間でU-Planeリレーをさらに行ってもよい。
【０１０８】
上述の実施形態は、UMTSシステムとLTE/LTE-Advancedシステムの間でゲートウェイが用いられる場合に適用されてもよい。例えば、LTEのHeNBとUMTSのRNC間においてハンドオーバを実施する場合に、当該ゲートウェイは、HeNBとRNCの間でU-Planeリレーを行ってもよい。
【０１０９】
上述の実施形態は、CDMA2000システムとLTE/LTE-Advancedシステムの間でゲートウェイが用いられる場合に適用されてもよい。例えば、LTEのHeNBとCDMA2000システムの基地局間においてハンドオーバを実施する場合に、当該ゲートウェイは、U-Planeリレーを行ってもよい。
【０１１０】
上述の実施形態は、Wireless Local Area Network（WLAN）システムとLTE/LTE-Advancedシステムの間でゲートウェイが用いられる場合に適用されてもよい。例えば、LTEのHeNBとWLANのアクセスポイント間においてハンドオーバを実施する場合に、当該ゲートウェイは、HeNBとアクセスポイントの間でU-Planeリレーを行ってもよい。
【０１１１】
さらに、上述の実施形態は、任意のRadio Access Technology（RAT）内の基地局間ハンドオーバのために基地局間ゲートウェイを使用する場合に適用されることができる。さらに、上述の実施形態は、任意のRAT間の基地局間ハンドオーバのために基地局間ゲートウェイを使用する場合に適用されることができる。
【０１１２】
さらに、上述の実施形態は、Relay Node（RN）およびDonor eNB（DeNB）の間のハンドオーバのためにX2ゲートウェイを使用する場合に適用されることができる。RN及びDeNBは、3GPP TS36.300（非特許文献１）に記載されている。
【０１１３】
さらに、上述の実施形態は、既に説明したように、Dual ConnectivityのケースにおいてMaster eNB（MeNB）とSecondary eNB（SeNB）の間のユーザデータパケットの転送のためにX2ゲートウェイを使用する場合に適用されることができる。Dual Connectivityは、3GPP TS36.300（非特許文献１）に記載されている。
【０１１４】
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
【０１１５】
例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
【０１１６】
（付記１）
基地局装置により行われる方法であって、
無線端末宛て又は前記無線端末からのデータパケットを基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを決定する際に、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を考慮することを備える、
方法。
【０１１７】
（付記２）
基地局装置により行われる方法であって、
無線端末宛て又は前記無線端末からのデータパケットを基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを決定する際に、前記基地局間ゲートウェイの前記リレー処理の能力を考慮することを備える、
方法。
【０１１８】
（付記３）
基地局装置により行われる方法であって、
第１の情報要素を基地局間ゲートウェイに送信することを備え、
前記第１の情報要素は、前記基地局装置と他の基地局の間のダイレクトパスの利用可否を示す、
方法。
【０１１９】
（付記４）
基地局間ゲートウェイ装置によって行われる方法であって、
リレー処理の能力を基地局に通知することを備え、
前記リレー処理は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって第１の基地局と第２の基地局の間で中継することを含む、
方法。
【０１２０】
（付記５）
基地局間ゲートウェイ装置であって、
メモリと、
前記メモリに結合された少なくとも１つのプロセッサと、
を備え、
前記少なくとも１つのプロセッサは、第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信するよう構成され、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
基地局間ゲートウェイ装置。
【０１２１】
（付記６）
前記第１の情報要素は、前記第１の基地局と前記第２の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記５に記載の基地局間ゲートウェイ装置。
【０１２２】
（付記７）
前記少なくとも１つのプロセッサは、前記第１の基地局から前記第２の基地局への前記無線端末のハンドオーバの際に、前記第１の情報要素を受信するよう構成されている、
付記５又は６に記載の基地局間ゲートウェイ装置。
【０１２３】
（付記８）
前記少なくとも１つのプロセッサは、前記リレー処理の能力を示す第２の情報要素を前記第１の基地局及び前記第２の基地局の少なくとも一方に送信するよう構成されている、
付記５〜７のいずれか１項に記載の基地局間ゲートウェイ装置。
【０１２４】
（付記９）
前記少なくとも１つのプロセッサは、前記第１の基地局及び前記第２の基地局の少なくとも一方を前記基地局間ゲートウェイ装置に登録する手順において、前記第２の情報要素を送信するよう構成されている、
付記８に記載の基地局間ゲートウェイ装置。
【０１２５】
（付記１０）
前記少なくとも１つのプロセッサは、前記第１の情報要素に基づいて、前記リレー処理を行うか否かを決定するよう構成されている、
付記５〜９のいずれか１項に記載の基地局間ゲートウェイ装置。
【０１２６】
（付記１１）
前記少なくとも１つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第１の基地局から前記第２の基地局へのハンドオーバ要求メッセージを運ぶ第１の転送メッセージに、前記基地局間ゲートウェイ装置と前記第２の基地局の間で前記データパケットを転送するための第１のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めるよう構成されている、
付記５〜１０のいずれか１項に記載の基地局間ゲートウェイ装置。
【０１２７】
（付記１２）
前記エンドポイント設定は、前記第２の基地局においてパケットフィルタを更新するために使用される、
付記１１に記載の基地局間ゲートウェイ装置。
【０１２８】
（付記１３）
前記エンドポイント設定は、前記基地局間ゲートウェイ装置のトランスポートレイヤ・アドレスを含む、
付記１１又は１２に記載の基地局間ゲートウェイ装置。
【０１２９】
（付記１４）
前記エンドポイント設定は、ダンリンクフォワーディングのためのエンドポイント設定及びアップリンクフォワーディングのためのエンドポイント設定を含む、
付記１１〜１３のいずれか１項に記載の基地局間ゲートウェイ装置。
【０１３０】
（付記１５）
前記少なくとも１つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第２の基地局から前記第１の基地局へのハンドオーバ要求承認メッセージを運ぶ第２の転送メッセージに、前記基地局間ゲートウェイ装置と前記第１の基地局の間で前記データパケットを転送するための第２のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めるよう構成されている、
付記５〜１４のいずれか１項に記載の基地局間ゲートウェイ装置。
【０１３１】
（付記１６）
基地局装置により行われる方法であって、
第１の情報要素を基地局間ゲートウェイに送信することを備え、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイが前記基地局装置と他の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
【０１３２】
（付記１７）
前記第１の情報要素は、前記基地局装置と前記他の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記１６に記載の方法。
【０１３３】
（付記１８）
前記送信することは、前記基地局装置から前記他の基地局または前記他の基地局から前記基地局装置への前記無線端末のハンドオーバの際に、前記第１の情報要素を送信することを含む、
付記１６又は１７に記載の方法。
【０１３４】
（付記１９）
前記送信することは、前記他の基地局へのハンドオーバ要求メッセージ又はハンドオーバ要求承認メッセージを運ぶために前記基地局間ゲートウェイに送信される転送メッセージに前記第１の情報要素を含めることを含む、
付記１８に記載の方法。
【０１３５】
（付記２０）
前記第１の情報要素は、前記リレー処理が必要とされることを暗示的に示すために、前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容を示す、
付記１９に記載の方法。
【０１３６】
（付記２１）
前記転送メッセージによって運ばれる前記ハンドオーバ要求メッセージ又は前記ハンドオーバ要求承認メッセージに包含されている第２の情報要素と同じ内容の第３の情報要素を前記転送メッセージに含めることをさらに備える、
付記１９に記載の方法。
【０１３７】
（付記２２）
前記第２の情報要素は、前記データパケットのフォワーディングの要否を示す情報要素、前記無線端末のために設定されたベアラの識別子を示す情報要素、および前記ベアラのQuality of Service（QoS）パラメータを示す情報要素のうち少なくとも１つを含む、
付記２０又は２１に記載の方法。
【０１３８】
（付記２３）
前記転送メッセージによって運ばれる基地局間シグナリングメッセージの種別を示す情報要素を前記転送メッセージに含めることをさらに備える、
付記１９〜２２のいずれか１項に記載の方法。
【０１３９】
（付記２４）
前記データパケットの送信又は受信のために、前記基地局間ゲートウェイによる前記リレー処理を利用するか否かを決定すること、及び
前記リレー処理が利用されない場合に、前記基地局装置と前記他の基地局の間のダイレクトパスを用いて前記データパケットをフォワーディングすること、
をさらに備える、
付記１６〜２３のいずれか１項に記載の方法。
【０１４０】
（付記２５）
基地局間ゲートウェイ装置によって行われる方法であって、
第１の情報要素を第１の基地局及び第２の基地局の少なくとも一方から受信することを備え、
前記第１の情報要素は、無線端末宛て又は前記無線端末からのデータパケットを前記基地局間ゲートウェイ装置によって前記第１の基地局と前記第２の基地局の間で中継するリレー処理が必要とされる否かを明示的または暗示的に示す、
方法。
【０１４１】
（付記２６）
前記第１の情報要素は、前記第１の基地局と前記第２の基地局の間のダイレクトパスの利用可否を明示的に示す、
付記２５に記載の方法。
【０１４２】
（付記２７）
前記受信することは、前記第１の基地局から前記第２の基地局への前記無線端末のハンドオーバの際に、前記第１の情報要素を受信することを含む、
付記２５又は２６に記載の方法。
【０１４３】
（付記２８）
前記リレー処理の能力を示す第２の情報要素を前記第１の基地局及び前記第２の基地局の少なくとも一方に送信することをさらに備える、
付記２５〜２７のいずれか１項に記載の方法。
【０１４４】
（付記２９）
前記送信することは、前記第１の基地局及び前記第２の基地局の少なくとも一方を前記基地局間ゲートウェイ装置に登録する手順において、前記第２の情報要素を送信することを含む、
付記２８に記載の方法。
【０１４５】
（付記３０）
前記第１の情報要素に基づいて、前記リレー処理を行うか否かを決定することをさらに備える、
付記２５〜２９のいずれか１項に記載の方法。
【０１４６】
（付記３１）
前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第１の基地局から前記第２の基地局へのハンドオーバ要求メッセージを運ぶ第１の転送メッセージに、前記基地局間ゲートウェイ装置と前記第２の基地局の間で前記データパケットを転送するための第１のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めることをさらに備える、
付記２５〜３０のいずれか１項に記載の方法。
【０１４７】
（付記３２）
前記エンドポイント設定は、前記第２の基地局においてパケットフィルタを更新するために使用される、
付記３１に記載の方法。
【０１４８】
（付記３３）
前記エンドポイント設定は、前記基地局間ゲートウェイ装置のトランスポートレイヤ・アドレスを含む、
付記３１又は３２に記載の方法。
【０１４９】
（付記３４）
前記エンドポイント設定は、ダンリンクフォワーディングのためのエンドポイント設定及びアップリンクフォワーディングのためのエンドポイント設定を含む、
付記３１〜３３のいずれか１項に記載の方法。
【０１５０】
（付記３５）
前記少なくとも１つのプロセッサは、前記基地局間ゲートウェイ装置によって前記リレー処理が行われる場合に、前記第２の基地局から前記第１の基地局へのハンドオーバ要求承認メッセージを運ぶ第２の転送メッセージに、前記基地局間ゲートウェイ装置と前記第１の基地局の間で前記データパケットを転送するための第２のトランスポートベアラに関する前記基地局間ゲートウェイ装置のエンドポイント設定を含めることをさらに備える、
付記２５〜３４のいずれか１項に記載の方法。
【０１５１】
この出願は、２０１５年３月２０日に出願された日本出願特願２０１５−０５８１５５を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０１５２】
１  (H)eNB
２  (H)eNB
３  X2 Gateway（X2 GW）
４  Evolved Packet Core（EPC）
５  Mobility Management Entity（MME）
１８０４  プロセッサ
１８０５  メモリ
１９０２  プロセッサ
１９０３  メモリ
【図１】
2016151653.tif 000003
【図２】
2016151653.tif 000004
【図３】
2016151653.tif 000005
【図４】
2016151653.tif 000006
【図５】
2016151653.tif 000007
【図６】
2016151653.tif 000008
【図７】
2016151653.tif 000009
【図８】
2016151653.tif 000010
【図９】
2016151653.tif 000011
【図１０】
2016151653.tif 000012
【図１１】
2016151653.tif 000013
【図１２】
2016151653.tif 000014
【図１３Ａ】
2016151653.tif 000015
【図１３Ｂ】
2016151653.tif 000016
【図１４】
2016151653.tif 000017
【図１５Ａ】
2016151653.tif 000018
【図１５Ｂ】
2016151653.tif 000019
【図１６】
2016151653.tif 000020
【図１７Ａ】
2016151653.tif 000021
【図１７Ｂ】
2016151653.tif 000022
【図１８】
2016151653.tif 000023
【図１９】
2016151653.tif 000024
【国際調査報告】
2016151653.tif 000025
2016151653.tif 000026
2016151653.tif 000027
2016151653.tif 000028