JP6262917B2 - ハンドオーバ手順を制御するための方法及び基地局 - Google Patents

Description

本発明は、ハンドオーバ手順を制御するための方法及び基地局に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）では、一般基地局（例えば、マクロセル基地局）よりもカバレッジの狭い特定基地局（例えば、小セル基地局）を効率的に利用するための検討が進められている。

また、３ＧＰＰでは、リリース１２以降において二重接続方式（Ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ）の導入が予定されている（非特許文献１参照）。二重接続方式では、ユーザ端末は、複数の基地局（一般基地局及び特定基地局）との接続を同時に確立する。ユーザ端末には、各基地局から無線リソースが割り当てられるため、スループットの向上が見込まれる。なお、二重接続方式は、基地局間キャリアアグリゲーション（ｉｎｔｅｒ−ｅＮＢ ＣＡ）と称されることがある。

二重接続方式では、ユーザ端末との接続を確立する複数の基地局のうち、１つの基地局（以下、「マスタ基地局」という）のみが当該ユーザ端末とのＲＲＣ接続を確立する。これに対し、当該複数の基地局のうち他の基地局（以下、「セカンダリ基地局」という）は、ＲＲＣ接続をユーザ端末と確立せずに、追加的な無線リソースをユーザ端末に提供する。

一の実施形態に係る方法は、二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法である。方法は、前記ソースマスタ基地局は、前記ターゲットマスタ基地局に対してハンドオーバ要求を送信し、前記ターゲットマスタ基地局から、前記セカンダリ基地局の変更の必要性に関する情報を受信することを含む。

一の実施形態に係る方法は、二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法である。方法は、前記ターゲットマスタ基地局は、前記ソースマスタ基地局からハンドオーバ要求を受信すると、所定の情報に基づいて、前記セカンダリ基地局を変更する必要があるか否かを判断し、当該判断の結果に基づいて、前記セカンダリ基地局の変更の必要性に関する情報を前記ソースマスタ基地局に対して送信することを含む。

一の実施形態に係る方法は、二重接続方式によってソースマスタ基地局及びソースセカンダリ基地局に接続しているユーザ端末の前記ソースマスタ基地局からターゲットマスタ基地局へのハンドオーバ手順を制御するための方法である。方法は、前記ターゲットマスタ基地局は、前記ソースマスタ基地局からハンドオーバ要求を受信すると、前記ソースセカンダリ基地局とは異なる、前記ユーザ端末に新たに接続するターゲットセカンダリ基地局を選択し、当該選択したターゲットセカンダリ基地局に対して、セカンダリ基地局追加要求を送信することを含む。

一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第１のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第２のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ソース基地局に送信する制御部を備える。前記メッセージにおいて、前記第１のトンネリング識別子及び前記第２のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。

一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第１のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第２のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ターゲット基地局から受信する制御部を備える。前記メッセージにおいて、前記第１のトンネリング識別子及び前記第２のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。

一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ソース基地局に送信する制御部を備える。

一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ターゲット基地局から受信する制御部を備える。前記制御部は、前記情報要素の受信に応じて、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。

一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ターゲット基地局に送信する制御部を備える。

一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ソース基地局から受信する制御部を備える。前記制御部は、前記通知情報の受信に応じて、前記ダイレクトフォワーディング、及び、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。

一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記メッセージを前記ソース基地局に送信した際に、前記インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させる。

一の実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する制御部を備える。前記制御部は、前記ダイレクトフォワーディングを決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ターゲット基地局に送信する。

一の実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である、前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記データを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングを前記ソース基地局が決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ソース基地局から受信する。

実施形態に係るＬＴＥシステムである。 実施形態に係るＵＥのブロック図である。 実施形態に係るｅＮＢのブロック図である。 実施形態に係る無線インターフェイスのプロトコルスタック図である。 二重接続方式の概要を説明するための図である。 第１のＵＰアーキテクチャ（ＵＰアーキテクチャ「１Ａ」）を示す図である。図６Ａはデータパス構成を示し、図６Ｂはプロトコルスタック構成を示す。 第２のＵＰアーキテクチャ（ＵＰアーキテクチャ「３Ｃ」）を示す図である。図７Ａはデータパス構成を示し、図７Ｂはプロトコルスタック構成を示す。 第１実施形態に係る動作環境を示す図である。 第１のハンドオーバ手順に係るシーケンス図である。 第２のハンドオーバ手順に係るシーケンス図である。 第３のハンドオーバ手順に係るシーケンス図である。 第４のハンドオーバ手順に係るシーケンス図である。 第５のハンドオーバ手順に係るシーケンス図である。 第６のハンドオーバ手順に係るシーケンス図である。 二重接続方式の概要を示す図である。 二重接続方式におけるベアラ構成例１を示す図である。 二重接続方式におけるベアラ構成例２を示す図である。 第２実施形態乃至第６実施形態に係る想定シナリオを示す図である。 第２実施形態乃至第６実施形態に係るフォワーディング方式を示す図である。 第２実施形態に係る概略シーケンスを示す図である。 第２実施形態に係る詳細シーケンスの一例を示す図である。 第５実施形態に係るターゲットＭｅＮＢ２００Ｍ２の動作を示すフロー図である。 第６実施形態に係る動作シーケンスの一例を示す図である。 付記に係るベアラタイプの変更（ＳＣＧからＭＣＧへ）を伴う直接データ転送を示す図である。 付記に係るベアラタイプの変更（ＭＣＧからＳＣＧへ）を伴う直接データ転送を示す図である。 付記に係るハンドオーバ準備が成功する動作を示す図である。 付記に係るＭｅＮＢ始動のＳｅＮＢ解放が成功する動作を示す図である。

［第１実施形態］
以下において、本発明をＬＴＥシステムに適用する場合の第１実施形態を説明する。

（システム構成）
図１は、第１実施形態に係るＬＴＥシステムの構成図である。

図１に示すように、第１実施形態に係るＬＴＥシステムは、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。

ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、セル（サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。

Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。

ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータのルーティング機能、モビリティ制御・スケジューリングのための測定制御機能などを有する。「セル」は、無線通信エリアの最小単位を示す用語として使用される他に、ＵＥ１００との無線通信を行う機能を示す用語としても使用される。

ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御などを行う。Ｓ−ＧＷは、ユーザデータの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。

図２は、ＵＥ１００のブロック図である。図２に示すように、ＵＥ１００は、複数のアンテナ１０１、無線送受信機１１０、ユーザインターフェイス１２０、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ Ｓｙｓｔｅｍ）受信機１３０、バッテリ１４０、メモリ１５０、及びプロセッサ１６０を備える。メモリ１５０及びプロセッサ１６０は、制御部を構成する。ＵＥ１００は、ＧＮＳＳ受信機１３０を有していなくてもよい。また、メモリ１５０をプロセッサ１６０と一体化し、このセット（すなわち、チップセット）をプロセッサ１６０’としてもよい。

アンテナ１０１及び無線送受信機１１０は、無線信号の送受信に用いられる。無線送受信機１１０は、プロセッサ１６０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ１０１から送信する。また、無線送受信機１１０は、アンテナ１０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ１６０に出力する。

ユーザインターフェイス１２０は、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタンなどを含む。ユーザインターフェイス１２０は、ユーザからの操作を受け付けて、該操作の内容を示す信号をプロセッサ１６０に出力する。ＧＮＳＳ受信機１３０は、ＵＥ１００の地理的な位置を示す位置情報を得るために、ＧＮＳＳ信号を受信して、受信した信号をプロセッサ１６０に出力する。バッテリ１４０は、ＵＥ１００の各ブロックに供給すべき電力を蓄える。

メモリ１５０は、プロセッサ１６０により実行されるプログラム、及びプロセッサ１６０による処理に使用される情報を記憶する。プロセッサ１６０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ１５０に記憶されるプログラムを実行して各種の処理を行うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含む。プロセッサ１６０は、さらに、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサ１６０は、後述する各種の処理及び各種の通信プロトコルを実行する。

図３は、ｅＮＢ２００のブロック図である。図３に示すように、ｅＮＢ２００は、複数のアンテナ２０１、無線送受信機２１０、ネットワークインターフェイス２２０、メモリ２３０、及びプロセッサ２４０を備える。メモリ２３０及びプロセッサ２４０は、制御部を構成する。また、メモリ２３０をプロセッサ２４０と一体化し、このセット（すなわち、チップセット）をプロセッサとしてもよい。

アンテナ２０１及び無線送受信機２１０は、無線信号の送受信に用いられる。無線送受信機２１０は、プロセッサ２４０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナ２０１から送信する。また、無線送受信機２１０は、アンテナ２０１が受信する無線信号をベースバンド信号（受信信号）に変換してプロセッサ２４０に出力する。

ネットワークインターフェイス２２０は、Ｘ２インターフェイスを介して隣接ｅＮＢ２００と接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。ネットワークインターフェイス２２０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信に用いられる。

メモリ２３０は、プロセッサ２４０により実行されるプログラム、及びプロセッサ２４０による処理に使用される情報を記憶する。プロセッサ２４０は、ベースバンド信号の変調・復調及び符号化・復号などを行うベースバンドプロセッサと、メモリ２３０に記憶されるプログラムを実行して各種の処理を行うＣＰＵと、を含む。プロセッサ２４０は、後述する各種の処理及び各種の通信プロトコルを実行する。

図４は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタック図である。図４に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１層乃至第３層に区分されており、第１層は物理（ＰＨＹ）層である。第２層は、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）層、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）層を含む。第３層は、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）層を含む。

物理層は、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理層とｅＮＢ２００の物理層との間では、物理チャネルを介してユーザデータ及び制御信号が伝送される。

ＭＡＣ層は、データの優先制御、ハイブリッドＡＲＱ（ＨＡＲＱ）による再送処理、及びＲＲＣ接続確立時のランダムアクセス手順などを行う。ＵＥ１００のＭＡＣ層とｅＮＢ２００のＭＡＣ層との間では、トランスポートチャネルを介してユーザデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式）及びＵＥ１００への割当リソースブロックを決定するスケジューラを含む。

ＲＬＣ層は、ＭＡＣ層及び物理層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ１００のＲＬＣ層とｅＮＢ２００のＲＬＣ層との間では、論理チャネルを介してユーザデータ及び制御信号が伝送される。

ＰＤＣＰ層は、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

ＲＲＣ層は、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣ層とｅＮＢ２００のＲＲＣ層との間では、各種設定のための制御信号（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態であり、そうでない場合、ＵＥ１００はＲＲＣアイドル状態である。

ＲＲＣ層の上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）層は、セッション管理及びモビリティ管理などを行う。

（二重接続方式）
第１実施形態に係るＬＴＥシステムは、二重接続方式をサポートする。二重接続方式は、リリース１２以降において導入が予定されている。二重接続方式では、ＵＥ１００は、複数のｅＮＢ２００との接続を同時に確立する。ＵＥ１００には、各ｅＮＢ２００から無線リソースが割り当てられるため、スループットの向上が見込まれる。なお、二重接続方式は、ｅＮＢ２００間キャリアアグリゲーション（ｉｎｔｅｒ−ｅＮＢ ＣＡ）と称されることもある。

図５は、二重接続方式の概要を説明するための図である。

図５に示すように、二重接続方式では、ＵＥ１００との接続を確立する複数のｅＮＢ２００のうち、ＭｅＮＢ（ＭｅＮＢ）２００Ｍのみが当該ＵＥ１００とのＲＲＣ接続を確立する。これに対し、当該複数のｅＮＢ２００のうちセカンダリｅＮＢ（ＳｅＮＢ）２００Ｓは、ＲＲＣ接続をＵＥ１００と確立せずに、追加的な無線リソースをＵＥ１００に提供する。言い換えると、ＭｅＮＢ２００Ｍは、ユーザプレーン接続だけでなく制御プレーン接続をＵＥ１００と確立する。これに対し、ＳｅＮＢ２００Ｓは、制御プレーン接続をＵＥ１００と確立せずに、ユーザプレーン接続をＵＥ１００と確立する。ＭｅＮＢ２００ＭとＳｅＮＢ２００Ｓとの間にはＸｎインターフェイスが設定される。Ｘｎインターフェイスは、Ｘ２インターフェイス又は新たなインターフェイスである。

二重接続方式では、ＵＥ１００は、ＭｅＮＢ２００Ｍが管理するＮ個のセル及びＳｅＮＢ２００Ｓが管理するＭ個のセルを同時に利用したキャリアアグリゲーションが可能である。二重接続方式においてＵＥ１００のサービングセルの最大数、すなわち、（Ｎ＋Ｍ）の最大数は、例えば５である。ここで、ＭｅＮＢ２００Ｍが管理するＮ個のセルからなるグループは、マスタセルグループ（ＭＣＧ）と称される。また、ＳｅＮＢ２００Ｓが管理するＭ個のセルからなるグループは、セカンダリセルグループ（ＳＣＧ）と称される。ＳＣＧには、ＵＥ１００のＰＵＣＣＨを設ける特別なセルが設定される。特別なセルは、キャリアアグリゲーションにおけるプライマリセル（ＰＣｅｌｌ）の機能の一部を遂行する。

図６及び図７は、二重接続方式におけるユーザデータの転送経路（データパス）の構成方式を説明するための図である。二重接続方式におけるユーザデータの転送経路（データパス）を構成するユーザプレーンアーキテクチャ（ＵＰアーキテクチャ）は主に２通り存在する。

図６は、第１のＵＰアーキテクチャ（ＵＰアーキテクチャ「１Ａ」とも称される）を示す。図６Ａに示すように、第１のＵＰアーキテクチャでは、ＭｅＮＢ２００ＭとＳ−ＧＷ３００Ｕとの間のＳ１−Ｕインターフェイスと、ＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のＳ１−Ｕインターフェイスと、が利用される。ＵＥ１００とＰ−ＧＷとの間のＥＰＳベアラ＃１は、ＭｅＮＢ２００ＭとＳ−ＧＷ３００Ｕとの間のＳ１−Ｕインターフェイスを経由する。ＵＥ１００とＰ−ＧＷとの間のＥＰＳベアラ＃２は、ＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のＳ１−Ｕインターフェイスを経由する。このように、第１のＵＰアーキテクチャでは、ＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のデータパスはＭｅＮＢ２００Ｍを経由しない。図６Ｂに示すように、ＭｅＮＢ２００Ｍ及びＳｅＮＢ２００Ｓのそれぞれは、ＰＤＣＰ、ＲＬＣ、ＭＡＣの各層の処理を行う。なお、図６Ａに示すＥＰＳベアラ＃１は「ＭＣＧベアラ」と称され、ＥＰＳベアラ＃２は「ＳＣＧベアラ」と称されてもよい。また、第１のＵＰアーキテクチャは、ＳＣＧベアラ・オプションと称されてもよい。

図７は、第２のＵＰアーキテクチャ（ＵＰアーキテクチャ「３Ｃ」とも称される）を示す。図７Ａに示すように、第２のＵＰアーキテクチャでは、ＵＥ１００とＰ−ＧＷとの間のＥＰＳベアラ＃２は、ＭｅＮＢ２００Ｍにおいて分割されており、分割された一方（ｓｐｌｉｔ ｂｅａｒｅｒ）はＳｅＮＢ２００Ｓを経由してＵＥ１００で終端し、分割された他方（ｓｐｌｉｔ ｂｅａｒｅｒ）はＳｅＮＢ２００Ｓを経由せずにＵＥ１００で終端する。このように、第２のＵＰアーキテクチャでは、ＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のデータパスはＭｅＮＢ２００Ｍを経由する。図７Ｂに示すように、ＥＰＳベアラ＃２における分割された一方（ｓｐｌｉｔ ｂｅａｒｅｒ）については、ＭｅＮＢ２００ＭのＰＤＣＰ、ＳｅＮＢ２００ＳのＲＬＣ及びＭＡＣ、により各層の処理を行う。なお、ｓｐｌｉｔ ｂｅａｒｅｒについては、ＲＬＣ（又はＲＬＣの一部機能）までの処理をＭｅＮＢ２００Ｍが担当してもよい。なお、図７Ａに示すＥＰＳベアラ＃１は「ＭＣＧベアラ」と称され、ＥＰＳベアラ＃２は「スプリットベアラ」と称されてもよい。第２のＵＰアーキテクチャは、スプリットベアラ・オプションと称されてもよい。

ところで、二重接続方式によってＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓ１と同時に接続しているＵＥ１００が、移動等によって信号の受信状況等の環境が変化すると、ＭｅＮＢ２００Ｍ１（ソースＭｅＮB、以下Ｓ−ＭｅＮＢ２００Ｍ１と称する）から他のＭｅＮＢ２００Ｍ２（ターゲットＭｅＮＢ又はターゲットｅＮＢ，以下、Ｔ−ＭｅＮＢ２００Ｍ２又はＴ−ｅＮＢ２００Ｍ２と称する）へのハンドオーバを実行する。さらに、ＵＥ１００が接続するＳｅＮＢ２００Ｓも変更する場合には、以下の２つのシナリオが想定される。

第１のシナリオは、一旦、ＵＥ１００と接続するＳｅＮＢ２００Ｓを変更せず（ＳｅＮＢ２００ＳとＵＥ１００との接続を維持しつつ）、ＵＥ１００のＳ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバ（Inter ＭｅＮＢ Handover without ＳｅＮＢ Change）を実行し、その後に、ＵＥ１００と接続するＳｅＮＢ２００Ｓを変更する（ＳｅＮＢ changeを実行する）。

なお、第１のシナリオにおけるハンドオーバは、ＳｅＮＢ２００ＳとＵＥ１００との接続を維持するための手順を含む。なお、ＳｅＮＢ２００ＳとＵＥ１００との接続を維持するとは、ハンドオーバ手順の中で、一旦ＳｅＮＢ２００ＳとＵＥ１００との接続を解放し、再度接続する場合も含む。

一方で、第２のシナリオは、ＳｅＮＢ２００ＳとＵＥ１００との接続を維持せずに解放し、ＵＥ１００のＳ−ＭｅＮＢ２００ＭからＴ−ＭｅＮＢ２００Ｍへのハンドオーバ（ＭｅＮＢ to ｅＮＢ change）を実行し、その後に、Ｔ−ＭｅＮＢ２００Ｍが他のＳｅＮＢ２００Ｓを追加する（ＳｅＮＢ Additionを実行する）。

ここで、ＵＥ１００の位置環境及び／又はＴ−ＭｅＮＢ２００Ｍの設定状況に応じては、ＭｅＮＢ２００Ｍのハンドオーバに併せてＳｅＮＢ２００Ｓを変更することが望ましい場合もある。

そのような場合に、仮に、第１のシナリオに沿ってハンドオーバ（Inter ＭｅＮＢ Handover without ＳｅＮＢ Change）を実行すると、即座にＵＥ１００と接続するＳｅＮＢ２００Ｓを変更する（ＳｅＮＢ changeを実行する）こととなるため、ＳｅＮＢとＵＥ１００との接続を維持するための手順が無駄となる可能性がある。

そこで、第１実施形態は、ＵＥ１００の環境及び／又はＴ−ＭｅＮＢ２００Ｍ２の設定状況等を踏まえた最適なハンドオーバ手順の実行を実現する。

図８は、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバを実行する際のＵＥ１００の環境の一例を示す図である。

ＵＥ１００は、ａ地点において、Ｓ−ＭｅＮＢ２００Ｍ１が管理するセルＭ１及びＳｅＮＢ２００Ｓ１が管理するセルＳ１の範囲内に位置し、二重接続方式によって、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓ１と接続している。

次に、ＵＥ１００は、矢印に沿って移動後、ｂ地点において、Ｓ−ＭｅＮＢ２００Ｍ１が管理するセルＭ１及びＳｅＮＢ２００Ｓ１が管理するセルＳ１の範囲内に位置すると共に、ｅＮＢ２００Ｍ２が管理するセルＭ２及びｅＮＢ２００Ｓ２が管理するセルＳ２の範囲内に位置する。

この場合、ＵＥ１００は、各ｅＮＢが管理するセルからの参照信号の測定結果が所定の条件を満たすと、Ｓ−ＭｅＮＢ２００Ｍ１に対して測定報告（Ｍｅａｓｕｒｅｍｅｎｔ Ｒｅｐｏｒｔ）を行い、Ｓ−ＭｅＮＢ２００Ｍ１が、Ｓ−ＭｅＮＢ２００Ｍ１からｅＮＢ２００Ｍ２（Ｔ−ＭｅＮＢ２００Ｍ２）へＵＥ１００のハンドオーバを実行する。なお、ＵＥ１００のハンドオーバとは、例えば、ＵＥ１００の接続先をＳ−ＭｅＮＢ２００Ｍ１（又はＳ−ＭｅＮＢ２００Ｍ１が管理するセル）から他のＴ−ＭｅＮＢ２００Ｍ２（又はＴ−ＭｅＮＢ２００Ｍ２が管理するセル）へ切り替えることであってもよい。

なお、Ｓ−ＭｅＮＢ２００Ｍ１及びＴ−ＭｅＮＢ２００Ｍ２は、マクロセルを管理するｅＮＢであって、Ｓ−ＳｅＮＢ２００Ｓ１及びｅＮＢ２００Ｓ２は、マクロセルよりエリアの狭いセル（スモールセル）であって、例えばナノセル又はピコセルを管理するｅＮＢであってもよい。また、マクロセルとスモールセルは、異なる周波数で運用されていてもよい。

図８に示すような環境において、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へＵＥ１００のハンドオーバを実行する際の各ハンドオーバ手順（第１のハンドオーバ手順〜第６のハンドオーバ手順）を、図９〜図１４を用いて以下に説明する。

まず、第１のハンドオーバ手順について、図９を用いて以下に説明する。

第１のハンドオーバ手順は、ＵＥ１００と接続するＳｅＮＢ２００Ｓ１を変更せずに（接続を維持したままで）、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へＵＥ１００のハンドオーバを実行する手順である。

なお、第１のハンドオーバ手順は、例えば、Inter ＭｅＮＢ Handover without ＳｅＮＢ Change ｐｒｏｃｅｄｕｒｅを一部改変したものであってもよい。

ステップＳ１０１において、ＵＥ１００は、ｅＮＢ２００（Ｓ−ＭｅＮＢ２００Ｍ１及び／又はＴ−ＭｅＮＢ２００Ｍ２を含む）からの信号の測定結果が一定の条件を満たすと、複数のｅＮＢ２００（Ｓ−ＭｅＮＢ２００Ｍ１、Ｔ−ＭｅＮＢ２００Ｍ２、ＳｅＮＢ２００Ｓ１及び／又はｅＮＢ２００Ｓ２を含む）からの信号の測定結果を含む測定報告（Measurement Report）をＳ−ＭｅＮＢ２００Ｍ１へ送信する。

ステップＳ１０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００から測定報告を受信すると、第１のハンドオーバ手順を開始する。なお、第１のハンドオーバ手順の開始は、ＵＥ１００からの測定報告の受信以外を契機としてもよい。Ｓ−ＭｅＮＢ２００Ｍ１は、第１のハンドオーバ手順を開始すると、ハンドオーバ要求（Handover Request）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。ハンドオーバ要求には、ステップＳ１０１においてＵＥ１００から受信した測定結果を含んでもよい。なお、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００から受信した複数のｅＮＢが管理するセルからの信号の測定結果のうち、一部のｅＮＢが管理するセルからの信号の測定結果のみをハンドオーバ要求に含めて送信してもよい。ハンドオーバ要求には、ＳｅＮＢ変更要否判断の指示を含んでもよい。

ステップＳ１０３において、Ｔ−ＭｅＮＢ２００Ｍ２は、所定の情報に基づいて、ＳｅＮＢ２００Ｓ１を変更する必要があるか否か判断する。ここで、ＳｅＮＢ２００Ｓ１を変更するとは、ＵＥ１００が、ＳｅＮＢ２００Ｓ１との接続を解放する及び／又はＳｅＮＢ２００Ｓ１とは異なるＳｅＮＢ２００（例えば、ＳｅＮＢ２００Ｓ２）と新たに接続することを含んでもよい。所定の情報とは、複数のｅＮＢが管理するセルからの信号のＵＥ１００による測定結果、過去にＴ−ＭｅＮＢ２００Ｍ２がＵＥ１００との二重接続の際に設定したＳｅＮＢ２００に関する情報、当該ＳｅＮＢ２００における無線リンク失敗（Ｓ−ＲＬＦ：S-Radio Link Failure）、ＯＡＭ（Operations、 Administration and Maintenance）によって予め設定されたＳｅＮＢ２００に関する情報、Ｔ−ＭｅＮＢ２００Ｍ２の負荷状況（無線リソース消費状況、プロセッシング負荷状況等）、ＳｅＮB２００Ｓ１とＳ−ＧＷ３００Ｕとの接続情報、Ｔ−ＭｅＮＢ２００Ｍ２とＳｅＮB２００Ｓ１とのＸ２接続情報、ＵＥ１００の移動速度情報のうちの一つ若しくは複数の組合せであってもよい。

ここで、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ１０３において、ＳｅＮＢ２００Ｓ１を変更する必要がないと判断する（ステップＳ１０３ ＮＯ）。一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、ＵＥ１００から受信した測定結果において、ＳｅＮＢ２００Ｓ１からの信号の品質（ＳＩＮＲ及びＲＳＲＰ等）が一定値以上及び／又はＳｅＮＢ２００Ｓ１からの信号の品質が他のｅＮＢ（例えば、ｅＮＢ２００Ｓ２）からの信号の品質より高い場合に、ＳｅＮＢ２００Ｓ１を変更する必要が無いと判断してもよい。

また、一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、過去にＳｅＮＢ２００Ｓ１をＳｅＮＢとして設定したことがある、ＳｅＮＢ２００Ｓ１の無線リンク失敗が一定値未満及び／又はＳｅＮＢ２００Ｓ１がＯＡＭによって予めＳｅＮＢとして設定されている場合に、ＳｅＮＢ２００Ｓ１を変更する必要が無いと判断してもよい。

ステップＳ１０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１を変更する必要がないと判断する（ステップＳ１０３ ＮＯ）と、ＳｅＮＢ２００Ｓ１へＳｅＮＢ追加要求（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ）を送信する。

ステップＳ１０５において、ＳｅＮＢ２００Ｓ１は、Ｔ−ＭｅＮＢ２００Ｍ２へＳｅＮＢ追加要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Request Acknowledgement）を送信する。

ステップＳ１０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求応答（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Acknowledgement）をＳ−ＭｅＮＢ２００Ｍ１へ送信する。このハンドオーバ要求応答には、ＳｅＮＢ２００Ｓ１の変更の必要性に関する情報（ＳｅＮＢ２００Ｓ１の変更が必要で有る旨）を含む。このＳｅＮＢの変更の必要性に関する情報は、Ｔ−ＭｅＮＢ２００Ｍ２がＳｅＮＢ２００Ｓ１を変更する必要があるか否かを判断した結果及び／又はＳｅＮＢ追加手順（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔの送信等）を実行した旨を示す情報を含んでもよい。この判断した結果は、Ｓ１０３における判断結果（ステップＳ１０３ ＮＯ）であって、ＳｅＮＢ２００Ｓ１の変更不要である。また、ＳｅＮＢの変更の必要性に関する情報は、ＵＥ１００の測定結果に含まれる複数のｅＮＢをＳｅＮＢとして選択すべき優先順位を含んでもよい。

また、このハンドオーバ要求応答には、ＳｅＮＢ２００Ｓ１の解放に用いられる設定情報（ＳｅＮＢ Release configuration）を含んでもよい。

なお、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求応答を送信することに代えて又はハンドオーバ要求応答を送信すると共に、ＳｅＮＢ変更要求（ＳｅＮB ｃｈａｎｇｅ Ｒｅｑｕｅｓｔ）を送信してもよい。Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求応答を送信すると共にＳｅＮＢ変更要求を送信する場合には、ＳｅＮＢの変更の必要性に関する情報をハンドオーバ要求応答には含めずにＳｅＮＢ変更要求に含めてもよい。

ステップＳ１０７において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２から受信したハンドオーバ要求応答に含まれる情報に基づいて、以降の手順を決定する。一例として、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答にＳｅＮＢ２００Ｓ１の変更不要との判断結果が含まれる場合には、以降の手順（ハンドオーバ手順）を、ＳｅＮＢ２００Ｓ１を変更しない（又は維持する）手順に決定する。ＳｅＮＢ２００Ｓ１を変更しない（又は維持する）手順は、以下に説明するステップＳ１０８〜Ｓ１２１を含む手順であるが、少なくとも、ステップＳ１１２及び／又はステップＳ１１３を含むものであればよい。なお、以降の手順を、ＳｅＮＢ２００Ｓ１を変更しない（又は維持する）手順に決定するとは、ステップＳ１０２から開始した、ＳｅＮＢ２００Ｓ１を変更しないハンドオーバ手順を継続するとの決定であってもよい。

ステップＳ１０８において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓ１へＳｅＮＢ解放要求（ＳｅＮＢ Release Request）を送信する。

ステップＳ１０９において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＲＲＣ接続再設定（RRC Connection Reconfiguration）をＵＥ１００へ送信する。

ステップＳ１１０において、ＵＥ１００は、ランダム接続手順（Random Access Procedure）をＴ−ＭｅＮＢ２００Ｍ２に対して実行する。

ステップＳ１１１において、ＵＥ１００は、ＲＲＣ接続再設定完了（RRC Connection Reconfiguration Complete）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。

ステップＳ１１２において、ＵＥ１００は、ランダム接続手順（Random Access Procedure）をＳｅＮＢ２００Ｓ１に対して実行する。

ステップＳ１１３において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１へＳｅＮＢ再設定完了（ＳｅＮＢ Reconfiguration Complete）を送信する。

ステップＳ１１４において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒメッセージをＴ−ＭｅＮＢ２００Ｍ２へ通知する。なお、ＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージは、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２への上り又は下りデータの転送状況に関する通知である。

ステップＳ１１５において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｓ−ＧＷ３００ＵからＳ−ＭｅＮＢ２００Ｍ１を介してＴ−ＭｅＮＢ２００Ｍ２へＵＥ１００向けのデータを転送するデータフォワーディングを実行する。

ステップＳ１１６において、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＧＷ３００ＵとＳ−ＭｅＮＢ２００Ｍ１との間のデータパスをＴ−ＭｅＮＢ２００Ｍ２へ切換えるために、パス切替要求（Path Switch Request）をＭＭＥ３００Ｃへ送信する。

ステップＳ１１７及びステップＳ１１８において、Ｓ−ＧＷ３００Ｕは、ＭＭＥ３００Ｃとの間でベアラ修正（Ｂｅａrer Ｍｏｄｉｆｉｃａｔｉｏｎ）をし、新規のデータパスを、Ｔ−ＭｅＮＢ２００Ｍ２との間に設定する（Ｓ１１８ａ）と共にＳｅＮＢ２００Ｓ１との間にＳＣＧベアラで設定する（Ｓ１１８ｂ）。なお、ステップＳ１１８ｂにおいて、ＳＣＧベアラを新たに設定してもよい。また、ＳＣＧベアラを新たに設定する代わりに、ＳｅＮＢ２００Ｓ１がＳ−ＭeNB２００Ｍ１によってＳＣＧベアラが設定されている状態で、ハンドオーバ前後において、Ｓ−ＧＷ３００Ｕが変更されないのであれば、当該ＳＣＧベアラを維持してもよい。

ステップＳ１１９において、ＭＭＥ３００Ｃは、パス切替要求応答（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。

ステップＳ１２０において、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１へＵＥコンテキスト解放（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）を送信する。

ステップＳ１２１において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥコンテキスト解放（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）をＳｅＮＢ２００Ｓ１へ送信する。

なお、ステップＳ１０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求を送信することに代えて、ＳｅＮＢ修正要求（ＳｅＮＢ Modification Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓ１へ送信してもよい。その場合には、ステップＳ１０５において、ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求応答の送信に代えて、ＳｅＮＢ修正要求応答（ＳｅＮＢ Modification Request Acknowledgment）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。その場合には、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ１０８及び／又はステップＳ１２１を省略してもよい。

第１のハンドオーバ手順によって、Ｔ−ＭｅＮＢ２００Ｍ２におけるＳｅＮＢ２００Ｓ１の変更の必要性に応じて、適切なハンドオーバ手順を実行することができる。つまり、Ｔ−ＭｅＮＢ２００Ｍ２において、ＳｅＮＢ２００Ｓ１の変更が不要（又は維持が必要）と判断された場合には、ハンドオーバ手順後においても、ＵＥ１００とＳｅＮＢ２００Ｓ１との接続が解放されずに維持することができる。

次に、第２のハンドオーバ手順について、図１０を用いて以下に説明する。

第２のハンドオーバ手順は、ＵＥ１００とＳｅＮB２００Ｓ１との接続を維持せずに解放し、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ｅＮＢ２００Ｍ２へＵＥ１００のハンドオーバを実行する手順である。

なお、第２のハンドオーバ手順は、ＭｅＮＢ to ｅＮＢ change ｐｒｏｃｅｄｕｒｅを一部改変したものであってもよい。

ＵＥ１００、Ｓ−ＭｅＮＢ２００Ｍ１及びＴ−ｅＮＢ２００Ｍ２は、ステップＳ２０１〜ステップＳ２０３を実行する。なお、ステップＳ２０１〜ステップＳ２０３は、第１のハンドオーバ手順におけるステップＳ１０１〜ステップＳ１０３と同じ動作である。

ステップＳ２０３において、Ｔ−ｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１を変更する必要がある（又は維持する必要が無い）と判断する（ステップＳ２０３ ＹＥＳ）。一例として、Ｔ−ｅＮＢ２００Ｍ２は、ＵＥ１００から受信した測定結果において、ＳｅＮＢ２００Ｓ１が管理するセルからの信号の品質（ＳＩＮＲ及びＲＳＲＰ等）が一定値未満及び／又はＳｅＮＢ２００Ｓ１が管理するセルからの信号の品質が他のｅＮＢ２００（例えば、ＳｅＮＢ２００Ｓ２）が管理するセルからの信号の品質より低い場合に、ＳｅＮＢ２００Ｓ１を変更する必要があると判断してもよい。

また、一例として、Ｔ−ｅＮＢ２００Ｍ２は、過去にＳｅＮＢ２００Ｓ１をＳｅＮＢとして設定したことがない、ＳｅＮＢ２００Ｓ１の無線リンク失敗が一定値以上及び／又はＳｅＮＢ２００Ｓ１がＯＡＭによって予めＳｅＮＢとして設定されていない場合に、ＳｅＮＢ２００Ｓ１を変更する必要が有ると判断してもよい。

ステップＳ２０４において、Ｔ−ｅＮＢ２００Ｍ２は、Ｔ−ＳｅＮＢ２００（例えば、ｅＮB２００Ｓ２）を選択できるか否かを判断する。ここで、Ｔ−ｅＮＢ２００Ｍ２は、所定の情報に基づいて、Ｔ−ＳｅＮＢ２００として選択できるｅＮＢを判断してもよい。一例として、Ｔ−ｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１から受信したＵＥ１００における測定結果に含まれる複数のｅＮＢのうち、所定の条件を満たすｅＮＢの有無に応じて、Ｔ−ＳｅＮＢとして選択できるｅＮＢを判断してもよい。所定の条件を満たすｅＮＢは、信号の品質（ＳＩＮＲ及びＲＳＲＰ等）が一定値以上、過去にＴ−ｅＮＢ２００Ｍ２がＳｅＮＢとして設定したことがある、無線リンク失敗が一定値未満及び／又はＯＡＭによって予めＳｅＮＢとして設定されているｅＮＢであってもよい。

なお、Ｔ−ｅＮＢ２００Ｍ２は、ステップＳ２０４は省略してもよく、ステップＳ２０３において、ＳｅＮＢ２００Ｓ１を変更する必要があると判断した場合（ステップＳ２０３ ＹＥＳ）に、ステップＳ２０５に移ってもよい。

Ｔ−ｅＮＢ２００Ｍ２は、ステップＳ２０４を省略した場合若しくはステップＳ２０４において、所定の条件を満たすｅＮＢが存在しなかったためＴ−ＳｅＮＢを選択できなかった場合（ステップＳ２０４ ＮＯ）、ステップＳ２０５において、ハンドオーバ要求応答（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Acknowledgement）をＳ−ＭｅＮＢ２００Ｍ１へ送信する。ここで、ハンドオーバ要求応答は、ＳｅＮＢの変更の必要性に関する情報を含む。このＳｅＮＢの変更の必要性に関する情報は、Ｔ−ｅＮＢ２００Ｍ２がＳｅＮＢ２００Ｓ１を変更する必要があるか否かを判断した結果及び／又はＳｅＮＢ追加手順（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔの送信等）を実行していない旨を示す情報を含んでもよい。この判断した結果は、Ｓ２０３における判断結果（ステップＳ２０３ ＮＯ）であって、ＳｅＮＢ２００Ｓ１の変更が必要であることである。

また、Ｔ−ｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１を変更する必要があると判断すると、ＳｅＮＢ２００Ｓ１に対して、ＳｅＮＢ追加要求を送信しない（又は送信を禁止する）。

ステップＳ２０６において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ｅＮＢ２００Ｍ２から受信したハンドオーバ要求応答に含まれる情報に基づいて、以降の手順（ハンドオーバ手順）を決定する。一例として、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答にＳｅＮＢ２００Ｓ１を変更する必要があるとの判断結果及び／又はＳｅＮＢ追加手順（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔの送信等）を実行していない旨を示す情報が含まれている場合、以降の手順を、ＳｅＮＢ２００Ｓ１を維持しない（ＳｅＮＢ２００Ｓ１との接続を解放する）手順に決定する。ＳｅＮＢを維持しない手順は、以下に説明するステップＳ２０６〜２１８を含む手順であるが、少なくとも、第１のハンドオーバ手順におけるステップＳ１１２及び／又はステップＳ１１３を含まない（又はステップＳ１１２及び／又はステップＳ１１３に相当する動作の実行を禁止する）ものであればよい。つまり、ＳｅＮＢ２００Ｓ１を維持しない手順は、ＳｅＮＢ２００Ｓ１に対してＵＥ１００及び／又はＴ−ｅＮＢ２００Ｍ２が接続を確立しない手順であればよい。

Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ２０７〜Ｓ２１０を実行するが、これは、第１のハンドオーバ手順におけるステップＳ１０８〜Ｓ１１１と同じ動作である。

ステップＳ２１１及びステップＳ２１２において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｓ−ＧＷ３００ＵからＳｅＮＢ２００Ｓ１及びＳ−ＭｅＮＢ２００Ｍ１を介して、Ｔ−ｅＮＢ２００Ｍ２へＵＥ１００向けのデータを転送するデータフォワーディングを実行する。

ステップＳ２１３において、Ｔ−ｅＮＢ２００Ｍ２は、Ｓ−ＧＷ３００ＵとＳ−ＭｅＮＢ２００Ｍ１との間のデータパスをＴ−ｅＮＢ２００Ｍ２へ切換えるために、パス切替要求（Path Switch Request）をＭＭＥ３００Ｃへ送信する。

ステップＳ２１４において、Ｓ−ＧＷ３００Ｕは、ＭＭＥ３００Ｃとの間でベアラ修正（Ｂｅａrer Ｍｏｄｉｆｉｃａｔｉｏｎ）を実行する。

ステップＳ２１５において、Ｓ−ＧＷ３００Ｕは、ＳｅＮＢ２００Ｓ１及びＳ−ＭｅＮＢ２００Ｍ１を介して、Ｔ−ＭｅＮＢ２００Ｍ２へEnd Marker Packetを送信する。

ステップＳ２１６において、Ｓ−ＧＷ３００Ｕは、新規のデータパスをＴ−ｅＮＢ２００Ｍ２との間に設定する。

ステップＳ２１７において、ＭＭＥ３００Ｃは、パス切替要求応答（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）をＴ−ｅＮＢ２００Ｍ２へ送信する。

ステップＳ２１８において、Ｔ−ｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１へＵＥコンテキスト解放（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）を送信する。

ステップＳ２１９において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥコンテキスト解放（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）をＳｅＮＢ２００Ｓ１へ送信する。

第２のハンドオーバ手順によって、Ｔ−ｅＮＢ２００Ｍ２におけるＳｅＮＢ２００Ｓ１の変更の必要性に応じて、適切なハンドオーバ手順を実行することができる。つまり、Ｔ−ＭｅＮＢ２００Ｍ２において、ＳｅＮＢ２００Ｓ１の変更が必要（又は維持が不要）と判断された場合には、ＳｅＮＢ２００Ｓ１を維持する処理（当該ＳｅＮＢに対するランダム接続処理等）の実行を省くことができる。

なお、第２のハンドオーバ手順が完了した後に、Ｔ−ｅＮＢ２００Ｍ２がＵＥ１００と接続するＳｅＮＢ２００Ｓ（例えば、ＳｅＮB２００Ｓ２）を新たに設定する場合には、既存のＳｅＮＢ追加手順（ＳｅＮＢAddition）（3GPP TS36.300 v12.5.0）等を用いてもよい。

次に、第３のハンドオーバ手順について、図１１を用いて説明する。

第３のハンドオーバ手順は、ＵＥ１００とＳｅＮＢ２００Ｓ１（Ｓ−ＳｅＮＢ２００Ｓ１）との接続を維持せずに解放すると共にＴ−ＳｅＮＢ２００Ｓ２との接続を確立し、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを実行する手順である。

ＵＥ１００は、ステップＳ３０１を実行する。なお、ステップＳ３０１は、第１のハンドオーバ手順におけるステップＳ１０１及び第２のハンドオーバ手順におけるステップＳ２０１と同じ動作である。

ステップＳ３０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求（Handover Request）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。一例として、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２へ送信するハンドオーバ要求に、ステップＳ３０１においてＵＥ１００から受信した測定結果を含めてもよく、特に、ＵＥ１００から受信した複数のｅＮＢ２００が管理するセルからの参照信号の測定結果のうち、一部のｅＮＢ２００が管理するセルからの参照信号の測定結果のみを含めてもよい。一部のｅＮＢ２００は、例えば、Ｓ−ＭｅＮＢ２００Ｍ１とのＸ２接続が確立されているｅＮＢ２００であってもよく、その場合、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求に、Ｘ２接続が確立されているｅＮＢ２００及びＳ−ＳｅＮＢ２００Ｓ１の識別子（ＩＤ）を含めてもよい。

Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ３０３及びＳ３０４を実行する。なお、ステップＳ３０３及びＳ３０４は、第２のハンドオーバ手順におけるステップＳ２０３及びＳ２０４と同じ動作である。なお、ステップＳ３０３は省略してもよく、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ３０２においてハンドオーバ要求を受信すると、ステップＳ３０４においてＴ−ＳｅＮＢ２００Ｓ２を選択してもよい。

ステップＳ３０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、新たにＵＥ１００が接続するＴ−ＳｅＮＢ２００Ｓ２を選択する（ステップＳ３０４ ＹＥＳ）。一例として、Ｔ−ｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１から受信したＵＥ１００における測定結果に含まれる複数のｅＮＢ２００のうち、所定の条件を満たすｅＮＢ２００のうち最も条件の良いｅＮＢ２００をＴ−ＳｅＮＢ２００Ｓとして選択してもよい。所定の条件を満たすｅＮＢ２００は、信号の品質（ＳＩＮＲ及びＲＳＲＰ等）が一定値以上、過去にＴ−ｅＮＢ２００Ｍ２がＳｅＮＢとして設定したことがある、無線リンク失敗が一定値未満及び／又はＯＡＭによって予めＳｅＮＢとして設定されているｅＮＢであってもよい。最も条件の良いｅＮＢ２００は、複数の条件（信号の品質（ＳＩＮＲ及びＲＳＲＰ等）が一定値以上、過去にＴ−ｅＮＢ２００Ｍ２がＳｅＮＢとして設定したことがある、無線リンク失敗が一定値未満及びＯＡＭによって予めＳｅＮＢとして設定されている）を最も多く満たすｅＮＢ２００であってもよい。

ステップＳ３０５において、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ３０４において選択したＴ−ＳｅＮＢ２００Ｓ２に対して、ＳｅＮＢ追加要求（ＳｅＮＢ Addition Request）を送信する。なお、ＳｅＮＢ追加要求には、ステップＳ３０２においてＳ−ＭｅＮＢ２００Ｍ１から受信したＳ−ＳｅＮＢ２００Ｓ１の識別子（ＩＤ）を含んでもよい。

ステップＳ３０６において、Ｔ−ＳｅＮＢ２００Ｓ２は、ＳｅＮＢ要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇ）を送信する。なお、Ｔ−ＳｅＮＢ２００Ｓ２は、ＳｅＮＢ追加要求に含まれるＳ−ＳｅＮＢ２００Ｓ１の識別子から、自局とＳ−ＳｅＮＢ２００Ｓ１とのＸ２接続が確立されているか否かを判断する。ここで、Ｔ−ＳｅＮＢ２００Ｓ２は、自局とＳ−ＳｅＮＢ２００Ｓ１とのＸ２接続が確立されており、ダイレクトデータフォワーディングが可能であれば、自局のＸ２ ＴＥＩＤ（Tunnel endpoint identifier）を含めて、ＳｅＮＢ要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Request Acknowledgement）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。なお、Ｘ２ ＴＥＩＤは、Ｘ２−Ｕ ユーザプレーン用のデータを流すために用いられてもよい。ダイレクトデータフォワーディングは、一例として、Ｓ−ＳｅＮＢ２００Ｓ１からＴ−ＳｅＮＢ２００Ｓ２への直接的なＵＥ１００向けのデータの転送を意味する。一方で、Ｔ−ＳｅＮＢ２００Ｓ２は、自局とＳ−ＳｅＮＢ２００Ｓ１とのＸ２接続が確立されておらず、ダイレクトデータフォワーディングが不可能であれば、自局のＸ２ ＴＥＩＤを含めずに、ＳｅＮＢ要求応答をＴ−ＭｅＮＢ２００Ｍ２へ送信する。

ステップＳ３０７において、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１に対してハンドオーバ要求応答（Handover Request Acknowledgement）を送信する。なお、ハンドオーバ要求応答は、ＳｅＮＢ２００Ｓ１の変更の必要性に関する情報を含んでもよい。また、ハンドオーバ要求応答は、ＵＥ１００のＲＲＣ接続再設定（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏn）用のＴ−ＳｅＮＢ２００Ｓ２の設定情報（RRC Configuration information）を含んでもよい。このＴ−ＳｅＮＢ２００Ｓ２の設定情報は、ステップＳ３０６において、Ｔ−ＳｅＮＢ２００Ｓ２から送信されてもよい。また、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ３０６においてＴ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤを受信した場合には、ハンドオーバ要求応答に、Ｔ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤを含めて送信してもよい。また、ハンドオーバ要求応答には、ステップＳ１０６において送信された情報と同様の情報を含んでもよい。

ステップＳ３０８において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答に含まれるＳｅＮＢ２００Ｓ１の変更の必要性に関する情報、ＵＥ１００のＲＲＣ再設定（ＲＲＣ ｒｅｃｏｎｆｉｇｕｒａｔｉｏn）用のＴ−ＳｅＮＢ２００Ｓ２の設定情報（RRC Configuration information）及び／又はＴ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤに基づいて、以降の手順（ハンドオーバ手順）を決定する。一例として、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００のＲＲＣ再設定（ＲＲＣ ｒｅｃｏｎｆｉｇｕｒａｔｉｏn）用のＴ−ＳｅＮＢ２００Ｓ２の設定情報（RRC Configuration information）及び／又はＴ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤが含まれる場合には、以降の手順を、Ｓ−Ｔ−ＳｅＮＢ２００Ｓ２との接続を行う手順に決定してもよい。

ステップＳ３０９において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｓ−ＳｅＮＢ２００Ｓ１に対して、ＳｅＮＢ解放要求（ＳｅＮＢ Release Request）を送信する。なお、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ３０7においてＴ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤを受信した場合には、ＳｅＮＢ解放要求に、Ｔ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤを含めて送信してもよい。

ステップＳ３１０において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００に対して、Ｔ−ＳｅＮＢ２００Ｍ２から受信したハンドオーバ要求応答に含まれるＴ−ＳｅＮＢ２００Ｓ２の設定情報を含めて、ＲＲＣ Ｃｏｎnection Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎを送信する。

ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２に対してステップＳ３１１〜Ｓ３１２を実行する。なお、ステップＳ３１１〜Ｓ３１２は、第１のハンドオーバ手順におけるステップＳ１１０〜Ｓ１１１に対応する。

ステップＳ３１３において、ＵＥ１００は、Ｔ−ＳｅＮＢ２００Ｓ２に対してランダム接続処理（Random Access Procedure）を実行する。なお、ＵＥ１００は、ステップＳ３０９において受信したＴ−ＳｅＮＢ２００Ｓ２の設定情報を用いてランダム接続処理（Random Access Procedure）を実行してもよい。なお、ＵＥ１００は、ステップＳ３１１の途中からステップＳ３１３の処理を開始してもよい。

ステップＳ３１４において、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｔ−ＳｅＮＢ２００Ｓ２に対してＳｅＮＢ再設定完了（ＳｅＮＢ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）を通知する。

ステップＳ３１５において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２に対して、ハンドオーバに際して発生するデータフォワーディングのためにＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージを通知する。

Ｓ−ＳｅＮＢ２００Ｓ１は、ステップＳ３０９においてＳ−ＭｅＮＢ２００Ｍ１から受信したソースｅＮＢ解放要求にＴ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤが含まれない場合には、ステップ３１６ａにおいて、Ｔ−ＳｅＮＢ２００Ｓ２に対して、Ｓ−ＭｅＮＢ２００Ｍ１を介して、インダイレクトフォワーディング（インダイレクトデータフォワーディング）のためにＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージを送信する。その後に、Ｓ−ＳｅＮＢ２００Ｓ１は、ＵＥ１００向けのデータをＳ−ＭｅＮＢ２００Ｍ１を介してＴ−ＳｅＮＢ２００Ｓ２へ間接的に転送するインダイレクトフォワーディングを実行する。

一方で、Ｓ−ＳｅＮＢ２００Ｓ１は、ステップＳ３０９において受信したソースｅＮＢ解放要求にＴ−ＳｅＮＢ２００Ｓ２のＸ２ ＴＥＩＤが含まれる場合には、ステップ３１６ｂにおいて、Ｔ−ＳｅＮＢ２００Ｓ２に対して、ダイレクトフォワーディング（ダイレクトデータフォワーディング）のために、ＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージを送信する。その後に、Ｓ−ＳｅＮＢ２００Ｓ１は、ＵＥ１００向けのデータを直接的にＴ−ＳｅＮＢ２００Ｓ２へ転送するダイレクトフォワーディングを実行する。

つまり、Ｓ−ＳｅＮＢ２００Ｓ１は、ステップＳ３１６ａ及びステップＳ３１６ｂのいずれか一方を実行する。

また、ステップＳ３１７〜ステップＳ３２１は、第１のハンドオーバ手順におけるステップＳ１１６〜Ｓ１２１が対応し、ステップＳ１１８ｂにおけるＳ−ＧＷ３００ＵとＳｅＮＢ２００Ｓ１との間の新たなパスの設定に代えて、Ｓ−ＧＷ３００ＵとＴ−ＳｅＮＢ２００Ｓ２との新たなパスの設定が実行される。

第３のハンドオーバ手順によって、Ｔ−ＭｅＮＢ２００Ｍ２におけるＳ−ＳｅＮＢ２００Ｓ１の変更の必要性に応じて、適切なハンドオーバ手順を実行することができる。つまり、Ｔ−ＭｅＮＢ２００Ｍ２において、Ｓ−ＳｅＮＢ２００Ｓ１の変更が必要と判断された場合には、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へハンドオーバすると共に、Ｓ−ＳｅＮＢ２００Ｓ１からＴ−ＳｅＮＢ２００Ｓ２へ変更することができ、ＭｅＮＢ２００Ｍのハンドオーバ後にＳｅＮB２００Ｓを変更する必要が無くなり、効率的にＳｅＮＢ２００Ｓの変更をすることができる。

次に、第４のハンドオーバ手順を、図１２を用いて以下に説明する。

第４のハンドオーバ手順は、ＵＥ１００と接続するＳｅＮＢ２００Ｓ１を変更せずに（ＳｅＮＢ２００Ｓ１との接続を維持したままで）Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを実行する手順であって、Ｓ−ＭｅＮＢ２００Ｍ１で確立（又は設定）しているＭＣＧベアラをＳｅＮＢ２００Ｓ１が用いる（又は管理する）ＳＣＧベアラに変更する手順を含むものである。

ＵＥ１００は、ステップＳ４０１を実行する。なお、ステップＳ４０１は、第１のハンドオーバ手順におけるステップＳ１０１と同じ動作である。

ステップＳ４０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２へハンドオーバ要求を送信する。一例として、ハンドオーバ要求は、ベアラタイプの変更を要求する旨（例えば、ＭＣＧベアラからＳＣＧベアラへの変更を要求する旨）を含んでもよい。また、一例として、ハンドオーバ要求は、Ｓ−ＭｅＮＢ２００Ｍ１が管理するＭＣＧベアラの情報（例えば、ベアラＩＤ）及び／又はＳＣＧベアラの情報を含んでもよい。または、ハンドオーバ要求は、ＵＥ合計最大ビットレート（ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔｒａｔｅ）及び／又はＳｅＮＢ２００Ｓ１におけるＵＥ合計最大ビットレート（ＳｅＮＢ ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔｒａｔｅ）を含んでもよい。なお、ベアラＩＤは、Ｅ−ＲＡＢ（Ｅ−ＵＴＲＡＮ Ａｃｃｅｓｓ Ｂｅａｒｅｒ） ＩＤであってもよい。また、ハンドオーバ要求には、ベアラの種類に関する情報（ＭＣＧベアラ、ＳＣＧベアラ又はスプリットベアラ）を含めてもよい。また、ハンドオーバ要求に含まれるベアラの種類に関する情報は、同じくハンドオーバ要求に含まれるＳ−ＭｅＮＢ２００Ｍ１が管理するベアラのベアラＩＤに対応付けられてもよい。これによって、ハンドオーバ要求を受信したＴ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１が管理するベアラＩＤに対応するベアラの種類（ＭＣＧベアラ、ＳＣＧベアラ又はスプリットベアラなのか）を特定することが可能となる。

ステップＳ４０３において、Ｔ−ＭｅＮＢ２００Ｍ２は、ベアラタイプを変更するか否かを判断する。つまり、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１で確立しているＭＣＧベアラをＳｅＮＢ２００Ｓ１のＳＣＧベアラに変更するか否かを判断する。一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求にベアラタイプの変更を要求する旨が含まれている場合に、ベアラタイプを変更すると判断してもよい。または、一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、自局のＲＲＭ（無線リソース管理）に基づいてベアラタイプを変更すると判断してもよい。具体的には、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１のリソース状況及びロード状況、ＵＥ１００におけるＴ−ＭｅＮＢ２００Ｍ２及び／若しくはＳｅＮＢ２００Ｓ１からの信号の測定結果、ＵＥ合計最大ビットレート（UE Aggregate Maximum Bit Rate）並びに／又はＳｅＮＢ２００Ｓ１におけるＵＥ合計最大ビットレート（SeNB UE Aggregate Maximum Bit Rate）等に基づいて、Ｓ−ＭｅＮB２００Ｍ１におけるＵＥ１００向けのデータをＳｅＮB２００Ｓ１から送信すべきと判断することにより、ベアラタイプを変更すると判断してもよい。

Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ４０３において、ベアラタイプを変更すると判断すると（Ｓ４０３ ＹＥＳ）、変更するＭＣＧベアラの識別子（ベアラ ＩＤ）を記憶する。一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、変更する対象のＭＣＧベアラの情報をInter-node RRC information elementの１つであるＨａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎにより取得してもよい。

ステップＳ４０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求に、ＳｅＮＢ２００Ｓ１に対して確立（又は設定）を要求するＳＣＧベアラの情報を含めて送信する。一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求内のＥ−ＲＡＢ Ｔｏ Ｂｅ Ａｄｄｅｄ Ｉｔｅｍ ＩＥ内のＳＣＧ Ｂｅａｒｅｒ ＩＥに上記ＳＣＧベアラの情報を含める。ここで、ＳＣＧベアラの情報とは、Ｅ−ＲＡＢ ＩＤ、Ｅ−ＲＡＢ Ｌｅｖｅｌ ＱｏＳ Ｐａｒａｍｅｔｅｒｓ、ＤＬ Ｆｏｒｗａｒｄｉｎｇ及びＳ１ ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ等である。また、ＳｅＮＢ２００Ｓ１は、受信したＳｅＮＢ追加要求に、既に確立しているＳＣＧベアラのベアラＩＤとは異なるベアラＩＤが含まれている場合には、当該異なるベアラＩＤに対応するＳＣＧベアラの追加（当該ベアラＩＤに対応するＭＣＧベアラからＳＣＧベアラへの変更）が要求されていると判断してもよい。

ステップＳ４０５において、ＳｅＮＢ２００Ｓ１は、Ｓ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へのデータフォワーディングのための自局のＸ２ ＴＥＩＤを含めてＳｅＮＢ追加要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。

ステップＳ４０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求応答（Ｈａｎdover Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）に、ＳｅＮＢ２００Ｓ１から受信したＳｅＮＢ２００Ｓ１のＸ２ ＴＥＩＤ及びステップＳ４０３において記憶した、ベアラタイプをＭＣＧベアラからＳＣＧベアラへ変更するＳ−ＭｅＮＢ２００Ｍ１が管理するＭＣＧベアラの識別子（ベアラＩＤ）を含めて送信する。

ステップＳ４０７〜Ｓ４１４を実行する。ステップＳ４０７〜Ｓ４１４は、第１のハンドオーバ手順におけるステップＳ１０８〜Ｓ１１５に対応する。

ステップＳ４１５において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓ１のＸ２ ＴＥＩＤに対して、ステップＳ４０６において受信したＭＣＧベアラの識別子で示されるＭＣＧベアラにバッファ（記憶）又はＭＣＧベアラに対応した記憶領域にバッファしているＵＥ１００向けのデータを、ＳｅＮB２００Ｓ１へダイレクト（データ）フォワーディング（直接的に転送）する。なお、ダイレクト（データ）フォワーディングは、ＵＥ１００向けのアップリンクデータ又はダウンリンクデータをＳ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へ直接的に（他のｅＮＢ２００を介さずに）転送することである。

ステップＳ４１６〜Ｓ４２１を実行する。ステップＳ４１６〜Ｓ４２１は、第１のハンドオーバ手順におけるステップＳ１１６〜１２１に対応する。

なお、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ４１３の後であってステップＳ４１５の前に、ステップＳ４１５のダイレクトフォワーディングに用いるベアラ（ベアラタイプをＭＣＧベアラからＳＣＧベアラに変更するベアラ）に関するＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒメッセージをＳｅＮＢ２００Ｓ１へ通知してもよい（ステップＳ４１４ａ）。

また、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓ１への上記ＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージの通知に代えて、ステップＳ４１３においてＴ−ＭｅＮＢ２００Ｍ２へ送信するＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージとして、（ベアラタイプを変更しない）ＭＣＧベアラのＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒとベアラタイプをＭＣＧベアラからＳＣＧベアラへ変更するベアラのＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒを送信してもよい。その後に、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１から受信したＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒのうち、ベアラのタイプをＭＣＧベアラからＳＣＧベアラへ変更するベアラのＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒのみをＳｅＮＢ２００Ｓ１へ転送してもよい（ステップＳ４１４ｂ）。この際に、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ４０３におけるベアラタイプの変更に基づいて、Ｓ−ＭｅＮＢ２００Ｍ１から受信したＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒのうち、ベアラのタイプをＭＣＧベアラからＳＣＧベアラへ変更するベアラのＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒのみを抽出できることとしてもよい。

また、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へのダイレクトフォワーディングを指示する場合に、ステップＳ４０６において送信するハンドオーバ要求応答にダイレクトフォワーディングの指示（Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｉｎｄｉｃａｔｏｒ）を含めてもよい。これによって、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｓ―ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へのダイレクトフォワーディングが要求されているのか否かを判断することができる。なお、ダイレクトフォワーディングの指示は、ハンドオーバ要求応答に含まれているベアラＩＤ及び／又はＳｅＮＢ２００Ｓ１のＸ２ ＴＥＩＤに対応付けられてもよい。これによって、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答に複数のベアラＩＤ及び又はＸ２ ＴＥＩＤが含まれている場合に、どのベアラＩＤ及び／又はＸ２ ＴＥＩＤがダイレクトフォワーディング用のベアラＩＤ及び／又はＸ２ ＴＥＩＤであるかを判別することができる。

第４のハンドオーバ手順によって、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバの際に、ベアラタイプを変更し、Ｓ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へのダイレクトフォワーディングが可能となる。

次に、第５のハンドオーバ手順を、図１３を用いて以下に説明する。

第５のハンドオーバ手順は、ＵＥ１００と接続するＳｅＮＢ２００Ｓ１を変更せずに（ＳｅＮＢ２００Ｓ１との接続を維持したままで）Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へＵＥ１００のハンドオーバを実行する手順であって、ＳｅＮＢ２００Ｓ１で確立（設定）しているＳＣＧベアラをＴ−ＭｅＮＢ２００Ｍ２が用いる（又は管理する）ＭＣＧベアラに変更する手順を含むものである。

ＵＥ１００は、ステップＳ５０１を実行する。ステップＳ５０１は、第１のハンドオーバ手順におけるステップＳ１０１と同じ動作である。

ステップＳ５０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２へハンドオーバ要求を送信する。ハンドオーバ要求は、ＳｅＮＢ２００Ｓ１で確立（設定）されているＳＣＧベアラの識別子を含む。また、ハンドオーバ要求は、Ｓ−ＭｅＮＢ２００Ｍ１で確立（設定）しているＭＣＧベアラの識別子を含んでもよい。また、一例として、ハンドオーバ要求は、ベアラタイプの変更を要求する旨（例えば、ＳＣＧベアラからＭＣＧベアラへの変更を要求する旨）を含んでもよい。

ステップＳ５０３において、Ｔ−ＭｅＮＢ２００Ｍ２は、ベアラタイプを変更するか否かを判断する。つまり、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１で確立（設定）されているＳＣＧベアラをＴ−ＭｅＮＢ２００Ｍ２で用いるＭＣＧベアラに変更するか否かを判断する。

Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ５０３において、ＲＲＭ又はハンドオーバ要求にベアラタイプの変更を要求する旨の有無に基づいて、ベアラタイプを変更すると判断すると（Ｓ５０３ ＹＥＳ）、変更するＳＣＧベアラの識別子及びＴ−ＭｅＮＢ２００Ｍ２で新たに設定するＭＣＧベアラの識別子を記憶する。

ステップＳ５０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ）を送信する。ここで、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求内のＥ−ＲＡＢ Ｔｏ Ｂｅ Ａｄｄｅｄ Ｉｔｅｍ ＩＥのSCG bearer IEにＳｅＮＢ２００１で設定されているＳＣＧベアラの設定を含めてもよい。また、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求に、自局のＸ２ TEIDを含めてもよい。この自局のＸ２ TEIDは、ＳｅＮＢ２００Ｓ１からＴ−ＭｅＮＢ２００Ｍ２へのダイレクトフォワーディングのためのものである。なお、ダイレクトデータフォワーディングは、ＵＥ１００向けのアップリンクデータ又はダウンリンクデータをＳｅＮＢ２００Ｓ１からＴ−ＭｅＮＢ２００Ｍ２へ直接的に（他のｅＮＢ２００を介さずに）転送することである。

ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求を受信すると、自局が確立しているＳＣＧベアラをＴ−ＭｅＮＢ２００Ｍ２で用いるためのＭＣＧベアラに変更することを要求していると判断する。一例として、ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求に、自局が確立しているＳＣＧベアラの設定若しくはＴ−ＭｅＮＢ２００Ｍ２のＸ２ ＴＥＩＤが含まれていることにより、ベアラの変更を要求していると判断してもよい。また、ＳｅＮＢ２００Ｓ１は、受信したＳｅＮＢ追加要求に、既に確立しているＳＣＧベアラのＩＤ（又は既に確立している複数のＳＣＧベアラのＩＤのうちの一部のＳＣＧベアラのＩＤ）が含まれていない場合には、当該ベアラのＩＤに対応するＳＣＧベアラの削除（又は当該ベアラのＩＤに対応するＳＣＧベアラからＭＣＧベアラへの変更）が要求されていると判断してもよい。

ステップＳ５０５において、ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を、Ｔ−ＭｅＮＢ２００Ｍ２へ送信する。

ステップＳ５０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求応答（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Acknowledgement）をＳ−ＭｅＮＢ２００Ｍ１へ送信する。

ステップＳ５０７〜Ｓ５１４を実行する。ステップＳ５０７〜Ｓ５１４は、第１のハンドオーバ手順におけるステップＳ１０８〜Ｓ１１５に対応する。

ステップＳ５１５において、ＳｅＮＢ２００Ｓ１は、ステップＳ５０４において受信したＴ−ＭeＮＢ２００Ｍ２のＸ２ ＴＥＩＤに対して、自局で確立していたＳＣＧベアラにバッファ（記憶）又はＳＣＧベアラに対応した記憶領域にバッファしているＵＥ１００向けのデータ（アップリンクデータ若しくはダウンリンクデータ）をＴ−ＭｅＮB２００Ｍ２へダイレクトフォワーディング（直接的に送信）する。なお、ＳＣＧベアラは、ＳｅＮＢ追加要求に、その設定に関する情報が含まれるものであってもよい。

なお、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ５０４においてＳｅＮＢ２００Ｍ１へ送信するＳｅＮＢ追加要求に自局のＸ２ TEIDを含めることに代えて、ステップＳ５０６において送信するハンドオーバ要求応答に、自局のＸ２ ＴＥＩDを含めてもよい。自局のＸ２ ＴＥＩDは、ステップＳ５１５におけるダイレクトフォワーディング（ＳｅＮＢ２００Ｓ１→Ｔ−ＭｅＮＢ２００Ｍ２）に用いるＸ２ ＴＥＩDとＭＣＧベアラ用のＸ２ ＴＥＩＤを含む。また、ステップＳ５０７において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答に含まれているＴ−ＭｅＮＢ２００Ｍ２のＸ２ ＴＥＩDのうちのダイレクトフォワーディングに用いるＸ２ ＴＥＩDのみを、ＳｅＮＢ解放要求に含めてＳｅＮＢ２００Ｓ１へ送信してもよい。その後、ステップＳ５１３において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＭＣＧベアラ（ハンドオーバ要求応答に含まれているＭＣＧベアラ用のＴＥＩＤに対応するＭＣＧベアラ）のみに関連するＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒメッセージをＴ−ＭｅＮＢ２００Ｍ２へ送信してもよい。その後、ＳｅＮＢ２００Ｓ１は、ベアラタイプを変更するベアラ（ダイレクトフォワーディングに用いるＴＥＩDに対応するベアラ）のみに関連するＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒメッセージをＴ−ＭｅＮＢ２００Ｍ２へ送信してもよい（Ｓ５１４ａ）。なお、ステップＳ５１３の前に、ＳｅＮＢ２００Ｓ１は、ベアラタイプをＳＣＧベアラからＭＣＧベアラに変更するベアラに関する情報をＳ−ＭｅＮＢ２００Ｍ１へ送信してもよい。この場合、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ５１３において、ＳｅＮＢ２００から受信した変更するベアラに関する情報をＴ−ＭｅＮＢ２００Ｍ２へ送信するＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒメッセージに含めてもよい。

また、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１へＳｅＮＢ２００Ｓ１からＴ−ＭｅＮＢ２００Ｍ２へのダイレクトフォワーディングを指示する場合に、ステップＳ５０６において送信するハンドオーバ要求応答にダイレクトフォワーディングの指示（Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｉｎｄｉｃａｔｏｒ）を含めてもよい。これによって、Ｓ−ＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディング（ＳｅＮＢ２００Ｓ１→Ｔ−ＭｅＮＢ２００Ｍ２）が要求されているのか否かを判断することができる。なお、ダイレクトフォワーディングの指示は、ハンドオーバ要求応答に含まれているベアラ（複数のベアラのうちのいずれかのベアラ）のベアラＩＤ及び／又はＸ２ ＴＥＩＤに対応付けられてもよい。これによって、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答に含まれている複数のベアラＩＤ及び／又はＸ２ ＴＥＩＤのうちのどのベアラＩＤ及び／又はＸ２ ＴＥＩＤがダイレクトフォワーディング用のベアラＩＤ及び／又はＸ２ ＴＥＩＤであるかを判別することができる。

さらに、Ｓ−ＭｅＮＢ２００Ｍ１は、受信したハンドオーバ要求応答にダイレクトフォワーディングの指示が含まれている場合には、ステップＳ５０７においてＳｅＮＢ２００Ｓ１へ送信するＳｅＮＢ解放要求にダイレクトフォワーディングの指示を含めてもよい。これによって、ＳｅＮＢ２００Ｓ１は、ダイレクトフォワーディング（ＳｅＮＢ２００Ｓ１→Ｔ−ＭｅＮＢ２００Ｍ２）が要求されているのか否かを判断することができる。これによって、ＳｅＮＢ２００Ｓ１は、ダイレクトフォワーディングが要求されている場合には、ＳＮ Ｓｔａｔｕｓ ＴｒａｎｓｆｅｒメッセージをＴ−ＭｅＮＢ２００Ｍ２へ送信すればよいと判断できる。また、ダイレクトフォワーディングの指示は、ＳｅＮＢ解放要求に含まれているベアラＩＤ及び／又はＸ２ ＴＥＩＤに対応付けられてもよい。これによって、ＳｅＮＢ２００Ｓ１は、ダイレクトフォワーディングの指示に対応付けられているベアラＩＤ及び／又はＸ２ ＴＥＩＤに対して、ダイレクトフォワーディングすることが要求されていると判断することができる。

第５のハンドオーバ手順によって、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバの際に、ベアラタイプを変更し、ＳｅＮＢ２００Ｓ１からＴ−ＭｅＮＢ２００Ｍ２へのダイレクトフォワーディングが可能となる。

次に、第６のハンドオーバ手順を、図１４を用いて以下に説明する。

第６のハンドオーバ手順は、ＵＥ１００と接続するＳｅＮＢ２００Ｓ１を変更せずに（ＳｅＮＢ２００Ｓ１との接続を維持したままで）Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へＵＥ１００のハンドオーバを実行する手順であって、ＳｅＮＢ２００Ｓ１経由のスプリットベアラをＴ−ＭｅＮＢ２００Ｍ２が用いるＭＣＧベアラに変更する手順を含むものである。

ＵＥ１００は、ステップＳ６０１を実行する。なお、ステップＳ６０１は、第１のハンドオーバ手順におけるステップＳ１０１と同じ動作である。

ステップＳ６０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２へハンドオーバ要求を送信する。一例として、ハンドオーバ要求には、ベアラタイプの変更を要求する旨（例えば、スプリットベアラからＭＣＧベアラへの変更を要求する旨）を含めてもよい。また、一例として、ハンドオーバ要求には、Ｓ−ＭｅＮＢ２００Ｍ１が管理するスプリットベアラの情報を含んでもよい。

ステップＳ６０３において、Ｔ−ＭｅＮＢ２００Ｍ２は、ベアラタイプを変更するか否かを判断する。つまり、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１経由のスプリットベアラをＴ−ＭｅＮＢ２００Ｍ２が用いるＭＣＧベアラに変更するか否かを判断する。一例として、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求にベアラタイプの変更を要求する旨が含まれている場合に、ベアラタイプを変更すると判断する。

Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１経由のスプリットベアラをＭＣＧベアラに変更すると判断した場合（ステップＳ６０３ ＹＥＳ）、当該スプリットベアラのベアラ識別子（Ｂｅａｒｅｒ ＩＤ）を記憶する。

ステップＳ６０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ６０４において、ＳｅＮＢ追加要求（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓ１へ送信する。ここで、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求内のＥ−ＲＡＢ Ｔｏ Ｂｅ Ａｄｄｅｄ Ｉｔｅｍ ＩＥのＳｐｌｉｔ bearer IEに、ＳｅＮＢ２００Ｓ１経由のスプリットベアラの設定を含めてもよい。

ＳｅＮＢ２００Ｓ１は、Ｔ−ＭｅＮＢ２００Ｍ２からＳｅＮＢ追加要求を受信すると、ＳｅＮＢ２００Ｓ１経由のスプリットベアラをＴ−ＭｅＮＢ２００Ｍ２で用いるためのＭＣＧベアラに変更することを要求していると判断する。具体的には、ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求に、現在設定されているＳｅＮＢ２００Ｓ１経由のスプリットベアラの設定が含まれていることにより、ベアラタイプの変更を要求していると判断してもよい。

ステップＳ６０５において、ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。

ステップＳ６０７〜Ｓ６１４を実行する。ステップＳ６０７〜Ｓ６１４は、第１のハンドオーバ手順におけるステップＳ１０８〜Ｓ１１５に対応する。

ステップＳ６１５において、Ｔ−ＭｅＮＢ２００Ｍ２がベアラタイプの変更を要求していると判断したＳｅＮＢ２００Ｓ１は、スプリットベアラにバッファ（記憶）しているＵＥ１００向けのデータ（アップリンクデータ若しくはダウンリンクデータ）をＳ−ＭｅＮＢ２００Ｍ１を介してＴ−ＭｅＮB２００Ｍ２へインダイレクトフォワーディング（転送）する。なお、このスプリットベアラは、ＳｅＮＢ追加要求に設定が含まれているスプリットベアラであってもよい。

ステップＳ６１６〜Ｓ６２１を実行する。ステップＳ６１６〜Ｓ６２１は、第１のハンドオーバ手順におけるステップＳ１１６〜１２１に対応する。

第６のハンドオーバ手順によって、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバの際にベアラタイプを変更し、ＳｅＮＢ２００Ｓ１からＴ−ＭｅＮＢ２００Ｍ２へのインダイレクトフォワーディングが可能となる。

なお、ステップＳ４０４、Ｓ５０４及びＳ６０４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求の送信に代えて、ＳｅＮＢ修正要求（ＳｅＮＢ Modification Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓ１へ送信してもよい。その場合には、ステップＳ４０５、Ｓ５０５及びＳ６０５において、ＳｅＮＢ２００Ｓ１は、ＳｅＮＢ追加要求応答の送信に代えて、ＳｅＮＢ修正要求応答（ＳｅＮＢ Modification Request Acknowledgment）をＴ−ＭｅＮＢ２００Ｍ２へ送信する。その場合には、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ４０７、Ｓ５０７及びＳ６０７及び／又はステップＳ４２１、Ｓ５２１及びＳ６２１を省略してもよい。

なお、第４〜６のハンドオーバ手順におけるステップＳ４０２、５０２及び６０２において、Ｓ−ＭｅＮＢ２００Ｍ１から送信されるハンドオーバ要求には、ＭＣＧベアラの情報及び／又はＳＣＧベアラの情報を含んでもよい。ここで、ＭＣＧベアラの情報及びＳＣＧベアラの情報は、所定のベアラＩＤがＭＣＧベアラ若しくはＳＣＧベアラであるということを示す情報を含んでもよい。このＭＣＧベアラ若しくはＳＣＧベアラであるということを示す情報は、Ｔ−ＭｅＮＢ２００Ｍ２が、変更の対象となるベアラ（ＭＣＧベアラ及び／又はＳＣＧベアラ）を選択する時に用いられてもよい。

なお、第４〜６のハンドオーバ手順は、例えば、Inter ＭｅＮＢ Handover without ＳｅＮＢ Changeを改良したものであってもよい。

なお、第１〜６のハンドオーバ手順は、上述したものに限られず、例えば、上述のステップのうち一部のステップを除くものであってもよい。

なお、第１〜６のハンドオーバ手順は、それぞれ異なる手順として説明したが、例えば、一のハンドオーバ手順における一部のステップを他のハンドオーバ手順において用いてもよい。

上述した第１実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。

［第２実施形態乃至第６実施形態の概要］
第２実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第１のトンネリング識別子と、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第２のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ソース基地局に送信する制御部を備える。前記メッセージにおいて、前記第１のトンネリング識別子及び前記第２のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。

第２実施形態に係るターゲット基地局において、前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答であってもよい。

第２実施形態に係るターゲット基地局において、前記制御部は、前記ベアラのタイプを、前記ソース基地局を介して前記ベアラを確立する第１のタイプから、前記セカンダリ基地局を介して前記ベアラを確立する第２のタイプに変更すると決定してもよい。

第２実施形態に係るソース基地局は、二重接続方式によりソース基地局及びセカンダリ基地局に接続するユーザ端末の基地局間ハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングに用いる第１のトンネリング識別子と、ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いる第２のトンネリング識別子と、前記ベアラを識別するベアラ識別子と、を含むメッセージを前記ターゲット基地局から受信する制御部を備える。前記メッセージにおいて、前記第１のトンネリング識別子及び前記第２のトンネリング識別子は、同一の前記ベアラ識別子に対応付けられている。

第２実施形態に係るソース基地局において、前記制御部は、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定し、前記決定したフォワーディング方式に応じて、前記第１のトンネリング識別子及び前記第２のトンネリング識別子の何れかを用いて前記ベアラに対するフォワーディング制御を行ってもよい。

第３実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ソース基地局に送信する制御部を備える。

第３実施形態に係るターゲット基地局において、前記制御部は、前記ダイレクトフォワーディングに用いる第１のトンネリング識別子と、前記ベアラを識別する第１のベアラ識別子と、前記インダイレクトフォワーディングに用いる第２のトンネリング識別子と、前記ベアラを識別する第２のベアラ識別子と、前記情報要素と、を含むメッセージを前記ソース基地局に送信し、前記メッセージにおいて、前記第１のトンネリング識別子が前記第１のベアラ識別子に対応付けられ、かつ、前記第２のトンネリング識別子が前記第２のベアラ識別子に対応付けられていてもよい。

第３実施形態に係るターゲット基地局において、前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答であってもよい。

第３実施形態に係るターゲット基地局において、前記制御部は、前記ベアラのタイプを、前記ソース基地局を介して前記ベアラを確立する第１のタイプから、前記セカンダリ基地局を介して前記ベアラを確立する第２のタイプに変更すると決定してもよい。

第３実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を前記ソース基地局が決定可能であることを示す情報要素を前記ターゲット基地局から受信する制御部を備える。前記制御部は、前記情報要素の受信に応じて、前記ダイレクトフォワーディング及び前記インダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。

第３実施形態に係るソース基地局において、前記制御部は、前記ダイレクトフォワーディングに用いる第１のトンネリング識別子と、前記ベアラを識別する第１のベアラ識別子と、前記インダイレクトフォワーディングに用いる第２のトンネリング識別子と、前記ベアラを識別する第２のベアラ識別子と、前記情報要素と、を含むメッセージを前記ターゲット基地局から受信し、前記決定したフォワーディング方式に応じて、前記第１のトンネリング識別子及び前記第２のトンネリング識別子の何れかを用いて前記ベアラに対するフォワーディング制御を行ってもよい。

第４実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ターゲット基地局に送信する制御部を備える。

第４実施形態に係るソース基地局において、前記制御部は、前記ソース基地局から前記ターゲット基地局に送信するハンドオーバ要求に前記通知情報を含めてもよい。

第４実施形態に係るソース基地局において、前記通知情報は、前記ソース基地局が前記ダイレクトフォワーディングを提案することを示す情報、又は、前記ソース基地局と前記セカンダリ基地局との間のＸ２インターフェイスが利用可能であることを示す情報であってもよい。

第４実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングが可能であることを示す通知情報を前記ソース基地局から受信する制御部を備える。前記制御部は、前記通知情報の受信に応じて、前記ダイレクトフォワーディング、及び、前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。

第５実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である。前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記メッセージを前記ソース基地局に送信した際に、前記インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させる。

第５実施形態に係るターゲット基地局において、前記制御部は、前記タイマの時間内で前記インダイレクトフォワーディングが開始された場合、前記タイマを停止させ、前記タイマが満了した場合、前記トンネリング識別子を解放してもよい。

第５実施形態に係るターゲット基地局において、前記メッセージは、前記ソース基地局から送信されたハンドオーバ要求に対するハンドオーバ要求応答であってもよい。

第６実施形態に係るソース基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ソース基地局である。前記ソース基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局からセカンダリ基地局に直接的に転送するダイレクトフォワーディング、及び前記ターゲット基地局を介して前記データを前記セカンダリ基地局に間接的に転送するインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する制御部を備える。前記制御部は、前記ダイレクトフォワーディングを決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ターゲット基地局に送信する。

第６実施形態に係るソース基地局において、前記制御部は、前記ダイレクトフォワーディングが完了した場合、前記通知情報としてのエンドマーカを前記ターゲット基地局に送信する。

第６実施形態に係るターゲット基地局は、二重接続方式をサポートする移動通信システムにおいて、ソース基地局からターゲット基地局に対してユーザ端末のハンドオーバを行う場合における前記ターゲット基地局である、前記ターゲット基地局は、前記ユーザ端末のベアラのデータを前記ソース基地局から前記ターゲット基地局を介してセカンダリ基地局に間接的に転送するインダイレクトフォワーディングに用いるトンネリング識別子を設定した後、前記トンネリング識別子を含むメッセージを前記ソース基地局に送信する制御部を備える。前記制御部は、前記データを前記ソース基地局から前記セカンダリ基地局に直接的に転送するダイレクトフォワーディングを前記ソース基地局が決定した場合、前記ダイレクトフォワーディングに関する通知情報を前記ソース基地局から受信する。

第６実施形態に係るターゲット基地局において、前記制御部は、前記通知情報の受信に応じて、前記第２のトンネリング識別子を解放する。

［二重接続方式］
以下において、二重接続方式について説明する。実施形態に係るＬＴＥシステムは、二重接続方式をサポートする。図１５は、二重接続方式の概要を示す図である。図１５に示すように、二重接続方式において、ＵＥ１００は、ＭｅＮＢ２００Ｍ（マスタ基地局）との接続及びＳｅＮＢ２００Ｓ（セカンダリ基地局）との接続を確立する。ＵＥ１００には、各ｅＮＢ２００のスケジューラから無線リソースが割り当てられる。

二重接続方式において、ＵＥ１００との接続を確立する複数のｅＮＢ２００のうち、ＭｅＮＢ２００Ｍのみが当該ＵＥ１００とのＲＲＣ接続を確立する。これに対し、ＳｅＮＢ２００Ｓは、ＲＲＣ接続をＵＥ１００と確立せずに、追加的な無線リソースをＵＥ１００に提供する。言い換えると、ＭｅＮＢ２００Ｍは、ユーザプレーン接続だけでなく制御プレーン接続をＵＥ１００と確立する。これに対し、ＳｅＮＢ２００Ｓは、制御プレーン接続をＵＥ１００と確立せずに、ユーザプレーン接続をＵＥ１００と確立する。ＭｅＮＢ２００ＭとＳｅＮＢ２００Ｓとの間にはＸ２インターフェイスが設定されている。

二重接続方式において、ＵＥ１００は、ＭｅＮＢ２００Ｍが管理するＮ個のサービングセル及びＳｅＮＢ２００Ｓが管理するＭ個のサービングセルを同時に利用したキャリアアグリゲーションが可能である。二重接続方式においてＵＥ１００のサービングセルの最大数、すなわち、（Ｎ＋Ｍ）の最大数は、例えば５である。ＭｅＮＢ２００Ｍが管理するＮ個のサービングセルからなるグループは、マスタセルグループ（ＭＣＧ）と称される。ＳｅＮＢ２００Ｓが管理するＭ個のサービングセルからなるグループは、セカンダリセルグループ（ＳＣＧ）と称される。ＳＣＧは、ＵＥ１００のＰＵＣＣＨを設けるプライマリ・セカンダリセル（ＰＳＣｅｌｌ）を含む。

図１６及び図１７は、二重接続方式におけるベアラ構成例を示す図である。ベアラは、ユーザデータの転送経路（データパス）に相当する。なお、ＵＥ１００とＰ−ＧＷ（ＰＤＮ Ｇａｔｅｗａｙ）との間にＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｓｙｓｔｅｍ）ベアラが確立される。ＥＰＳベアラは、ＵＥ１００とＳ-ＧＷとの間のＥ−ＲＡＢ（Ｅ−ＵＴＲＡＮ Ｒａｄｉｏ Access Ｂｅａｒｅｒ）と、Ｓ-ＧＷとＰ−ＧＷとの間のＳ５／Ｓ８ベアラと、により構成される。Ｅ−ＲＡＢは、ＵＥ１００とｅＮＢ２００との間の無線ベアラと、ｅＮＢ２００とＳ-ＧＷとの間のＳ１ベアラと、により構成される。以下において「ベアラ」とは、主としてＥ−ＲＡＢ又はＥＰＳベアラを意味する。

図１６は、二重接続方式におけるベアラ構成例１を示す。図１６Ａに示すように、ＵＥ１００は、ＭｅＮＢ２００Ｍを介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃１）と、ＳｅＮＢ２００Ｓを介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）と、を有する。但し、ＵＥ１００は、３つ以上のベアラを有していてもよい。また、図１６Ａにおいて下りリンクのベアラを例示しているが、ＵＥ１００は、上りリンクのベアラも有していてもよい。

ＭｅＮＢ２００Ｍを介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃１）は、対応する無線プロトコルがＭｅＮＢ２００Ｍにのみ存在するベアラである。このようなベアラのタイプは、「ＭＣＧベアラ」と称される。ＭＣＧベアラは、ＭｅＮＢ２００Ｍを介してベアラを確立する第１のタイプに相当する。一方、ＳｅＮＢ２００Ｓを介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）は、対応する無線プロトコルがＳｅＮＢ２００Ｓにのみ存在するベアラである。このようなベアラのタイプは、「ＳＣＧベアラ」と称される。ＳＣＧベアラは、ＳｅＮＢ２００Ｓを介してベアラを確立する第２のタイプに相当する。

図１６Ｂに示すように、ＭｅＮＢ２００Ｍは、ＭＣＧベアラ（ＥＰＳ ｂｅａｒｅｒ＃１）について、ＰＤＣＰ、ＲＬＣ、ＭＡＣの各層の処理を行う。ＳｅＮＢ２００Ｓは、ＳＣＧベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）について、ＰＤＣＰ、ＲＬＣ、ＭＡＣの各層の処理を行う。

図１７は、二重接続方式におけるベアラ構成例２を示す。図１７Ａに示すように、ＵＥ１００は、ＭｅＮＢ２００Ｍを介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃１）と、ＭｅＮＢ２００Ｍ及びＳｅＮＢ２００Ｓの両方を介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）と、を有する。但し、ＵＥ１００は、３つ以上のベアラを有していてもよい。また、図１７Ａにおいて下りリンクのベアラを例示しているが、ＵＥ１００は、上りリンクのベアラも有していてもよい。

ＭｅＮＢ２００Ｍを介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃１）は、図１６と同様なＭＣＧベアラである。一方、ＭｅＮＢ２００Ｍ及びＳｅＮＢ２００Ｓの両方を介して確立するベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）は、対応する無線プロトコルがＭｅＮＢ２００Ｍ及びＳｅＮＢ２００Ｓの両方に存在するベアラである。このようなベアラのタイプは、「スプリットベアラ」と称される。

図１７Ｂに示すように、ＭｅＮＢ２００Ｍは、ＭＣＧベアラ（ＥＰＳ ｂｅａｒｅｒ＃１）について、ＰＤＣＰ、ＲＬＣ、ＭＡＣの各層の処理を行う。また、ＭｅＮＢ２００Ｍは、スプリットベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）について、ＰＤＣＰ、ＲＬＣ、ＭＡＣの各層の処理を行う。ＭｅＮＢ２００ＭのＰＤＣＰ層は、スプリットベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）の少なくとも一部のデータをＳｅＮＢ２００Ｓに割り振る。ＳｅＮＢ２００Ｓは、スプリットベアラ（ＥＰＳ ｂｅａｒｅｒ＃２）について、ＲＬＣ及びＭＡＣの各層の処理を行う。

［想定シナリオ］
以下において、第２実施形態乃至第６実施形態に係る想定シナリオについて説明する。図１８は、第２実施形態乃至第６実施形態に係る想定シナリオを示す図である。図１８に示すように、二重接続方式によりＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓに接続するＵＥ１００は、ＳｅＮＢ２００Ｓを変更せず（ＳｅＮＢ２００ＳとＵＥ１００との間の接続を維持しつつ）、ＭｅＮＢ２００Ｍ１からＭｅＮＢ２００Ｍ２へのハンドオーバを行う。

このようなハンドオーバは、ＳｅＮＢ２００Ｓを変更しないＭｅＮＢ間ハンドオーバ（ｉｎｔｅｒ ＭｅＮＢ Ｈａｎｏｖｅｒ ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ）と称される。以下において、ハンドオーバ元であるｅＮＢ２００Ｍ１をソースＭｅＮＢ（ソースマスタ基地局）２００Ｍ１と称し、ハンドオーバ先であるｅＮＢ２００Ｍ２をターゲットＭｅＮＢ（ターゲットマスタ基地局）２００Ｍ２と称する。

図１８（Ａ）に示すように、ソースＭｅＮＢ２００Ｍ１はマクロセルＭＣ１を管理し、ターゲットＭｅＮＢ２００Ｍ２はマクロセルＭＣ２を管理し、ＳｅＮＢ２００Ｓは小セルＳＣを管理している。マクロセルＭＣ１の一部とマクロセルＭＣ２の一部とは重複しており、当該重複する領域に小セルＳＣが位置する。小セルＳＣ内に位置するＵＥ１００は、二重接続方式によりソースＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓに接続する。具体的には、ＵＥ１００は、ソースＭｅＮＢ２００Ｍ１を介してＭＣＧベアラを確立し、ＳｅＮＢ２００Ｓを介してＳＣＧベアラを確立する。ＵＥ１００は、ＳＣＧベアラに代えてスプリットベアラを確立してもよいし、又はＳＣＧベアラに加えてスプリットベアラを確立してもよい。

このような状況下で、図１８（Ｂ）に示すように、ＵＥ１００がターゲットＭｅＮＢ２００Ｍ２の方向に向けて移動すると仮定する。この場合、ＵＥ１００とソースＭｅＮＢ２００Ｍ１との間の無線状況が悪化するため、ＵＥ１００のハンドオーバの必要性が生じる。ＵＥ１００は、ＳｅＮＢ２００Ｓを変更せずに、ソースＭｅＮＢ２００Ｍ１からターゲットＭｅＮＢ２００Ｍ２へのＭｅＮＢ間ハンドオーバを行う。

実施形態において、ソースＭｅＮＢ２００Ｍ１を介して確立された少なくとも１つのＭＣＧベアラは、ＭｅＮＢ間ハンドオーバの際に、ＳＣＧベアラに変更され、ＳｅＮＢ２００Ｓに引き継がれる。このようなベアラタイプの変更は、ターゲットＭｅＮＢ２００Ｍ２により決定される。ＭＣＧベアラをＳＣＧベアラに変更する場合、ＭＣＧベアラのデータ（すなわち、ソースＭｅＮＢ２００Ｍ１のバッファに残存するデータ）をソースＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓに転送する必要がある。このようなデータ転送は、「フォワーディング」と称される。

図１９は、実施形態に係るフォワーディング方式を示す図である。フォワーディング方式には、ダイレクトフォワーディング及びインダイレクトフォワーディングの２つの方式がある。

図１９（Ａ）に示すように、ダイレクトフォワーディングにおいて、ソースＭｅＮＢ２００Ｍ１は、Ｘ２インターフェイスを介して、ＵＥ１００のベアラ（ＭＣＧベアラ）のデータをＳｅＮＢ２００Ｓに直接的に転送する。具体的には、ソースＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間には、Ｘ２インターフェイス上にトンネリング接続が確立され、トンネリング接続によりソースＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓにデータが転送される。

トンネリング接続は、フォワーディング対象のベアラごとに確立される。また、トンネリングには、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）が適用される。ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングを行うために、ＳｅＮＢ２００Ｓに設定されたＧＴＰトンネリング識別子（ＴＥ ＩＤ：Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ）を把握している必要がある。ＳｅＮＢ２００Ｓに設定されたＧＴＰ ＴＥ ＩＤは、第１のトンネリング識別子に相当する。

図１９（Ｂ）に示すように、インダイレクトフォワーディングにおいて、ソースＭｅＮＢ２００Ｍ１は、ターゲットＭｅＮＢ２００Ｍ２を介して、ＵＥ１００のベアラ（ＭＣＧベアラ）のデータをＳｅＮＢ２００Ｓに間接的に転送する。具体的には、ソースＭｅＮＢ２００Ｍ１とターゲットＭｅＮＢ２００Ｍ２との間には、Ｘ２インターフェイス上にトンネリング接続が設定され、かつ、ターゲットＭｅＮＢ２００Ｍ２とＳｅＮＢ２００Ｓとの間には、Ｘ２インターフェイス上にトンネリング接続が確立される。

これらのトンネリング接続により、まずソースＭｅＮＢ２００Ｍ１からターゲットＭｅＮＢ２００Ｍ２にデータが転送され、次にターゲットＭｅＮＢ２００Ｍ２からＳｅＮＢ２００Ｓにデータが転送される。ソースＭｅＮＢ２００Ｍ１は、インダイレクトフォワーディングを行うために、ターゲットＭｅＮＢ２００Ｍ２に設定されたＧＴＰトンネリング識別子（ＴＥ ＩＤ）を把握している必要がある。ターゲットＭｅＮＢ２００Ｍ２に設定されたＧＴＰ ＴＥ ＩＤは、第２のトンネリング識別子に相当する。

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

（１）第２実施形態に係る動作シーケンス
第２実施形態において、ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングを行うか又はインダイレクトフォワーディングを行うかの決定を行う。このようなフォワーディング方式の決定をソースＭｅＮＢ２００Ｍ１が行う場合、ターゲットＭｅＮＢ２００Ｍ２は、ダイレクトフォワーディング用の第１のトンネリング識別子及びインダイレクトフォワーディング用の第２のトンネリング識別子を、フォワーディング対象のベアラと対応付けてソースＭｅＮＢ２００Ｍ１に通知する必要がある。

図２０は、第２実施形態に係る概略シーケンスを示す図である。

図２０に示すように、ステップＳ１１において、ソースＭｅＮＢ（Ｓ−ＭｅＮＢ）２００Ｍ１は、ハンドオーバ要求（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ）をターゲット（Ｔ−ＭｅＮＢ）ＭｅＮＢ２００Ｍ２に送信する。ハンドオーバ要求は、ＵＥ１００のベアラの情報を含む。

ターゲットＭｅＮＢ２００Ｍ２は、ハンドオーバ要求を受信する。ターゲットＭｅＮＢ２００Ｍ２は、ソースＭｅＮＢ２００Ｍ１を介して確立された少なくとも１つのＭＣＧベアラを、ＳＣＧベアラに変更して、ＳｅＮＢ２００Ｓに引き継ぐことを決定する。言い換えると、ターゲットＭｅＮＢ２００Ｍ２は、ベアラのタイプを、ソースＭｅＮＢ２００Ｍ１を介してベアラを確立する第１のタイプから、ＳｅＮＢ２００Ｓを介してベアラを確立する第２のタイプに変更すると決定する。以下において、ＭＣＧベアラからＳＣＧベアラに変更されるベアラを「タイプ変更ベアラ」と称する。

ステップＳ１２において、ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求（ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）をＳｅＮＢ２００Ｓに送信する。ＳｅＮＢ追加要求は、タイプ変更ベアラのベアラ識別子を含む。

ＳｅＮＢ２００Ｓは、ＳｅＮＢ追加要求を受信する。ＳｅＮＢ２００Ｓは、タイプ変更ベアラについて、ダイレクトフォワーディング用の第１のトンネリング識別子（ＧＴＰ ＴＥ ＩＤ）を設定する。

ステップＳ１３において、ＳｅＮＢ２００Ｓは、ＳｅＮＢ追加要求に対する肯定応答メッセージであるＳｅＮＢ追加要求応答（ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）をターゲットＭｅＮＢ２００Ｍ２に送信する。ＳｅＮＢ追加要求応答は、タイプ変更ベアラのベアラ識別子と、ダイレクトフォワーディング用の第１のトンネリング識別子と、を含む。ＳｅＮＢ追加要求応答において、第１のトンネリング識別子は、タイプ変更ベアラのベアラ識別子と対応付けられている。

ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求応答を受信する。ターゲットＭｅＮＢ２００Ｍ２は、タイプ変更ベアラについて、インダイレクトフォワーディング用の第２のトンネリング識別子（ＧＴＰ ＴＥ ＩＤ）を設定する。

ステップＳ１４において、ターゲットＭｅＮＢ２００Ｍ２は、ハンドオーバ要求に対する肯定応答メッセージであるハンドオーバ要求応答（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）をソースＭｅＮＢ２００Ｍ１に送信する。ハンドオーバ要求応答は、ダイレクトフォワーディング用の第１のトンネリング識別子と、インダイレクトフォワーディング用の第２のトンネリング識別子と、タイプ変更ベアラのベアラ識別子と、を含む。

ハンドオーバ要求応答において、第１のトンネリング識別子及び第２のトンネリング識別子は、同一のベアラ識別子に対応付けられている。ここで、第１のトンネリング識別子及び第２のトンネリング識別子は、同一のベアラ識別子に対応付けているのは、以下の理由による。

第１のトンネリング識別子にタイプ変更ベアラのベアラ識別子（Ａ）を対応付け、かつ、第２のトンネリング識別子にタイプ変更ベアラのベアラ識別子（Ｂ）を対応付ける場合、同一の値を有する複数のベアラ識別子がハンドオーバ要求応答に含まれることになる。つまり、第１のトンネリング識別子に対応付けられるベアラ識別子のフィールドと第２のトンネリング識別子に対応付けられるベアラ識別子のフィールドとが異なる場合、同一のベアラ（タイプ変更ベアラ）について複数のベアラ識別子が存在し、ベアラ識別子の重複が生じる。これは既存のＬＴＥ仕様において、エラー（Ｃａｕｓｅ ＩＥ： Ｍｕｌｔｉｐｌｅ Ｅ−ＲＡＢ ＩＤ ｉｎｓｔａｎｃｅｓ）とみなされてハンドオーバが失敗する又は特定のベアラに関してのみハンドオーバが失敗する虞がある。

一方、ハンドオーバ要求応答において、第１のトンネリング識別子及び第２のトンネリング識別子は、同一のベアラ識別子に対応付けることにより、同一のベアラ（タイプ変更ベアラ）について複数のベアラ識別子が存在しなくなるため、上記のようなエラーを防止することができる。

表１に、第２実施形態に係るハンドオーバ要求応答の構成例を示す。

表１に示すように、ハンドオーバ要求応答は、ターゲットＭｅＮＢ２００Ｍ２がリソースを準備したベアラ（Ｅ−ＲＡＢ）のリストである「Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ」を含む。「Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ」は、ベアラごとの項目（Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｉｔｅｍ）を含む。各項目は、「Ｅ−ＲＡＢ ＩＤ」、「ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」、「ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」、「ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ｆｏｒ ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ」、「ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ｆｏｒ ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ」を含む。その他の情報要素（ＩＥ）については、３ＧＰＰ技術仕様書「ＴＳ３６．４２３」を参照されたい。

ここで、「Ｅ−ＲＡＢ ＩＤ」は、ベアラ識別子に相当する。「ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」及び「ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」は、インダイレクトフォワーディング用の第２のトンネリング識別子に相当する。「ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ｆｏｒ ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ」及び「ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ｆｏｒ ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ」は、ダイレクトフォワーディング用の第１のトンネリング識別子に相当する。このように、第１のトンネリング識別子及び第２のトンネリング識別子は、同一のベアラ識別子に対応付けられている。具体的には、１つの項目（Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｉｔｅｍ）内に、１つのベアラ識別子と、第１のトンネリング識別子及び第２のトンネリング識別子と、が含まれる。

ソースＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答を受信する。

ステップＳ１５において、ソースＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答の受信に応じて、ＳｅＮＢ解放要求（ＳＥＮＢ ＲＥＬＥＡＳＥ ＲＥＱＵＥＳＴ）をＳｅＮＢ２００Ｓに送信する。また、ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。

なお、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する際の判断基準としては、次に示す情報を用いることができる。１）ユーザ（アプリケーション）が要求するＱｏＳや課金情報。２）オペレータの好み。例えば、ＭｅＮＢとＳｅＮＢが同一ベンダの製品であれば、ダイレクトを選択する。このような情報は、ＯＡＭによってｅＮＢに事前設定（ｐｒｅ ｃｏｎｆｉｇ）される。３）Ｔ−ＭｅＮＢの負荷情報。既存仕様に従って事前に負荷情報が「Ｒｅｓｏｕｒｃｅ Ｓｔａｔｕｓ Ｒｅｐｏｒｔｉｎｇ ｐｒｏｃｅｄｕｒｅ」で交換されているため、Ｔ−ＭｅＮＢの負荷が高い場合にはダイレクトフォワーディングを選択することにより、転送負荷をなくすことが可能である。

ソースＭｅＮＢ２００Ｍ１は、決定したフォワーディング方式に応じて、第１のトンネリング識別子及び第２のトンネリング識別子の何れかを用いてタイプ変更ベアラに対するフォワーディング制御を行う。具体的には、ダイレクトフォワーディングを決定した場合、ソースＭｅＮＢ２００Ｍ１は、第１のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う（ステップＳ１６ｂ、ステップＳ１７ｂ）。一方、インダイレクトフォワーディングを決定した場合、ソースＭｅＮＢ２００Ｍ１は、第２のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う（ステップＳ１６ａ、ステップＳ１７ａ）。

（２）詳細シーケンスの一例
図２１は、第２実施形態に係る詳細シーケンスの一例を示す図である。上述したように、本シーケンスは、ＵＥ１００と接続するＳｅＮＢ２００Ｓ１を変更せずにＭｅＮＢ間ハンドオーバを行うシーケンスであって、ソースＭｅＮＢ２００Ｍ１で確立しているＭＣＧベアラをＳｅＮＢ２００Ｓ１が管理するＳＣＧベアラに変更するものである。

図２１に示すように、ステップＳ４０１において、ＵＥ１００は、ｅＮＢ２００（ソースＭｅＮＢ２００Ｍ１及び／又はターゲットＭｅＮＢ２００Ｍ２を含む）からの信号の測定結果が一定の条件を満たすと、信号の測定結果を含む測定報告（Ｍｅａｓｕｒｅｍｅｎｔ Ｒｅｐｏｒｔ）をソースＭｅＮＢ２００Ｍ１に送信する。ソースＭｅＮＢ２００Ｍ１は、ＵＥ１００から測定報告を受信すると、ハンドオーバ手順を開始する。なお、ハンドオーバ手順の開始は、ＵＥ１００からの測定報告の受信以外を契機としてもよい。

ステップＳ４０２において、ソースＭｅＮＢ２００Ｍ１は、ターゲットＭｅＮＢ２００Ｍ２にハンドオーバ要求（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ）を送信する。ハンドオーバ要求は、ベアラタイプの変更を要求する旨（例えば、ＭＣＧベアラからＳＣＧベアラへの変更を要求する旨）を含んでもよい。また、ハンドオーバ要求は、ソースＭｅＮＢ２００Ｍ１が管理するＭＣＧベアラの情報（例えば、ベアラ識別子）及び／又はＳＣＧベアラの情報を含んでもよい。ハンドオーバ要求は、ＵＥ合計最大ビットレート（ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔｒａｔｅ）及び／又はＳｅＮＢ２００Ｓ１におけるＵＥ合計最大ビットレート（ＳｅＮＢ ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔｒａｔｅ）を含んでもよい。なお、ベアラ識別子は、Ｅ−ＲＡＢ ＩＤであってもよい。また、ハンドオーバ要求は、ベアラの種類に関する情報（ＭＣＧベアラ、ＳＣＧベアラ又はスプリットベアラ）を含んでもよい。また、ベアラの種類に関する情報は、ベアラ識別子に対応付けられてもよい。これにより、ハンドオーバ要求を受信したターゲットＭｅＮＢ２００Ｍ２は、ソースＭｅＮＢ２００Ｍ１が管理するベアラ識別子に対応するベアラの種類（ＭＣＧベアラ、ＳＣＧベアラ又はスプリットベアラなのか）を特定することが可能となる。

ステップＳ４０３において、ターゲットＭｅＮＢ２００Ｍ２は、ベアラタイプを変更するか否かを判断する。つまり、ターゲットＭｅＮＢ２００Ｍ２は、ソースＭｅＮＢ２００Ｍ１で確立しているＭＣＧベアラをＳｅＮＢ２００Ｓ１のＳＣＧベアラに変更するか否かを判断する。ターゲットＭｅＮＢ２００Ｍ２は、ハンドオーバ要求にベアラタイプの変更を要求する旨が含まれている場合に、ベアラタイプを変更すると判断してもよい。或いは、ターゲットＭｅＮＢ２００Ｍ２は、自局のＲＲＭ（無線リソース管理）に基づいてベアラタイプを変更すると判断してもよい。具体的には、ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓ１のリソース状況及び負荷状況、ＵＥ１００におけるターゲットＭｅＮＢ２００Ｍ２及び／若しくはＳｅＮＢ２００Ｓ１からの信号の測定結果、ＵＥ合計最大ビットレート（ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ）並びに／又はＳｅＮＢ２００Ｓ１におけるＵＥ合計最大ビットレート（ＳｅＮＢ ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ）等に基づいて、ソースＭｅＮＢ２００Ｍ１におけるＵＥ１００向けのデータをＳｅＮB２００Ｓ１から送信すべきと判断することにより、ベアラタイプを変更すると判断してもよい。

ターゲットＭｅＮＢ２００Ｍ２は、ベアラタイプを変更すると判断すると（Ｓ４０３：ＹＥＳ）、変更するＭＣＧベアラの識別子（ベアラ識別子）を記憶する。ターゲットＭｅＮＢ２００Ｍ２は、変更する対象のＭＣＧベアラの情報を「Ｉｎｔｅｒ−ｎｏｄｅ ＲＲＣ ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ」の１つである「Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ」により取得してもよい。

ステップＳ４０４において、ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求に、ＳｅＮＢ２００Ｓ１に対して確立（又は設定）を要求するＳＣＧベアラの情報を含めて送信する。ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求内の「Ｅ−ＲＡＢ Ｔｏ Ｂｅ Ａｄｄｅｄ Ｉｔｅｍ ＩＥ」内の「ＳＣＧ Ｂｅａｒｅｒ ＩＥ」に上記ＳＣＧベアラの情報を含める。ここで、ＳＣＧベアラの情報とは、Ｅ−ＲＡＢ ＩＤ、Ｅ−ＲＡＢ Ｌｅｖｅｌ ＱｏＳ Ｐａｒａｍｅｔｅｒｓ、ＤＬ Ｆｏｒｗａｒｄｉｎｇ及びＳ１ ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ等である。ＳｅＮＢ２００Ｓ１は、受信したＳｅＮＢ追加要求に、既に確立しているＳＣＧベアラのベアラ識別子とは異なるベアラ識別子が含まれている場合には、当該異なるベアラ識別子に対応するＳＣＧベアラの追加（当該ベアラ識別子に対応するＭＣＧベアラからＳＣＧベアラへの変更）が要求されていると判断してもよい。

ステップＳ４０５において、ＳｅＮＢ２００Ｓ１は、ソースＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へのダイレクトデータフォワーディングのための自局のＧＴＰ ＴＥ ＩＤを含めてＳｅＮＢ追加要求応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をターゲットＭｅＮＢ２００Ｍ２に送信する。

ステップＳ４０６において、ターゲットＭｅＮＢ２００Ｍ２は、ハンドオーバ要求応答（Ｈａｎdover Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）に、ＳｅＮＢ２００Ｓ１から受信したＳｅＮＢ２００Ｓ１のＧＴＰ ＴＥ ＩＤ及びステップＳ４０３において記憶したタイプ変更ベアラの識別子（ベアラ識別子）を含めて送信する。

ステップＳ４０７において、ソースＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓ１へＳｅＮＢ解放要求（ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｑｕｅｓｔ）を送信する。

ステップＳ４０８において、ソースＭｅＮＢ２００Ｍ１は、ＲＲＣ接続再設定（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）をＵＥ１００に送信する。

ステップＳ４０９において、ＵＥ１００は、ランダム接続手順（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｒｏｃｅｄｕｒｅ）をターゲットＭｅＮＢ２００Ｍ２に対して実行する。

ステップＳ４１０において、ＵＥ１００は、ＲＲＣ接続再設定完了（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）をターゲットＭｅＮＢ２００Ｍ２に送信する。

ステップＳ４１１において、ＵＥ１００は、ランダム接続手順（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｒｏｃｅｄｕｒｅ）をＳｅＮＢ２００Ｓ１に対して実行する。

ステップＳ４１２において、ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ再設定完了（ＳｅＮＢ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）をＳｅＮＢ２００Ｓ１に送信する。

ステップＳ４１３において、ソースＭｅＮＢ２００Ｍ１は、「ＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒ」メッセージをターゲットＭｅＮＢ２００Ｍ２に通知する。「ＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒ」メッセージは、ソースＭｅＮＢ２００Ｍ１における上り又は下りデータの転送状況に関する通知である。

ステップＳ４１４において、ソースＭｅＮＢ２００Ｍ１は、Ｓ−ＧＷ３００ＵからソースＭｅＮＢ２００Ｍ１を介してＵＥ１００向けのデータをターゲットＭｅＮＢ２００Ｍ２に転送するデータフォワーディングを行う。

ステップＳ４１５において、ソースＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓ１の「ＧＴＰ ＴＥ ＩＤ」に対して、タイプ変更ベアラについてバッファしているＵＥ１００向けのデータを、ＳｅＮB２００Ｓ１に直接的に転送する（ダイレクトフォワーディング）。

ステップＳ４１６において、ターゲットＭｅＮＢ２００Ｍ２は、Ｓ−ＧＷ３００ＵとソースＭｅＮＢ２００Ｍ１との間のデータパスをターゲットＭｅＮＢ２００Ｍ２へ切換えるために、パス切替要求（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）をＭＭＥ３００Ｃに送信する。

ステップＳ４１７及びステップＳ４１８において、Ｓ−ＧＷ３００Ｕは、ＭＭＥ３００Ｃとのベアラ修正（Ｂｅａｒｅｒ Ｍｏｄｉｆｉｃａｔｉｏｎ）をし、新規のデータパスをターゲットＭｅＮＢ２００Ｍ２と設定する（Ｓ４１８ａ）とともに、ＳｅＮＢ２００Ｓ１とのＳＣＧベアラを設定する（Ｓ４１８ｂ）。なお、ステップＳ４１８ｂにおいて、ＳＣＧベアラを新たに設定してもよい。また、ＳＣＧベアラを新たに設定する代わりに、ＳｅＮＢ２００Ｓ１がソースＭｅＮＢ２００Ｍ１によってＳＣＧベアラが設定されている状態で、ハンドオーバ前後において、Ｓ−ＧＷ３００Ｕが変更されないのであれば、当該ＳＣＧベアラを維持してもよい。

ステップＳ４１９において、ＭＭＥ３００Ｃは、パス切替要求応答（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）をターゲットＭｅＮＢ２００Ｍ２に送信する。

ステップＳ４２０において、ターゲットＭｅＮＢ２００Ｍ２は、ソースＭｅＮＢ２００Ｍ１へＵＥコンテキスト解放（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）を送信する。

ステップＳ４２１において、ソースＭｅＮＢ２００Ｍ１は、ＵＥコンテキスト解放（ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ）をＳｅＮＢ２００Ｓ１に送信する。

なお、ソースＭｅＮＢ２００Ｍ１は、ステップＳ４１３の後であってステップＳ４１５の前に、ステップＳ４１５のダイレクトフォワーディングに用いるベアラ（ベアラタイプをＭＣＧベアラからＳＣＧベアラに変更するベアラ）に関する「ＳＮ Ｓｔａｔｕｓ Ｔｒａｎｓｆｅｒ」メッセージをＳｅＮＢ２００Ｓ１へ通知してもよい（ステップＳ４１４ａ）。

［第３実施形態］
以下において、第３実施形態について説明する。第３実施形態は第２実施形態の一部を変更した実施形態であるため、第２実施形態との相違点について説明する。

第３実施形態に係る動作シーケンスは、図２０と同様である。但し、第３実施形態は、ハンドオーバ要求応答（図２０のステップＳ１４のメッセージ）の構成が第２実施形態とは異なる。

第３実施形態に係るハンドオーバ要求応答において、第１のトンネリング識別子に対応付けられるベアラ識別子のフィールドと第２のトンネリング識別子に対応付けられるベアラ識別子のフィールドとが異なる。つまり、同一のベアラ（タイプ変更ベアラ）について複数のベアラ識別子が存在する。上述したように、このようなベアラ識別子の重複がある場合、エラー（Ｃａｕｓｅ： Ｍｕｌｔｉｐｌｅ Ｅ−ＲＡＢ ＩＤ ｉｎｓｔａｎｃｅｓ）とみなされる虞がある。

そこで、第３実施形態に係るターゲットＭｅＮＢ２００Ｍ２は、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式をソースＭｅＮＢ２００Ｍ１が決定可能であることを示す情報要素をハンドオーバ要求応答に含める。このような情報要素をハンドオーバ要求応答に含める。言い換えると、ターゲットＭｅＮＢ２００Ｍ２は、ベアラ識別子の重複が意図的に行われており、エラーと判断するべきではないことを示すインジケータをハンドオーバ要求応答に含める。これにより、ソースＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答中に、同一の値を有する複数のベアラ識別子が存在する場合でも、エラーと判断しないようにすることができる。

表２に、第３実施形態に係るハンドオーバ要求応答の構成例を示す。なお、説明の便宜上、既存のＩＥの一部を省略して示している。

表２に示すように、第３実施形態に係るハンドオーバ要求応答において、「Ｅ−ＲＡＢＳ ＡＤＭＩＴＴＥＤ ＬＩＳＴ」とは別に、ダイレクトフォワーディング用の「Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｅ−ＲＡＢｓ Ｌｉｓｔ」が設けられる。

「Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｅ−ＲＡＢｓ Ｌｉｓｔ」は、「Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｅ−ＲＡＢｓ Ｉｔｅｍ」を含む。「Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｅ−ＲＡＢｓ Ｉｔｅｍ」は、ダイレクトフォワーディングに用いる第１のトンネリング識別子（「ＵＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」）と、ベアラを識別する第１のベアラ識別子（Ｅ−ＲＡＢ ＩＤ）と、を含む。このように、第１のトンネリング識別子が第１のベアラ識別子に対応付けられている。

一方、「Ｅ−ＲＡＢＳ ＡＤＭＩＴＴＥＤ ＬＩＳＴ」は、「Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｉｔｅｍ」を含む。「Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｉｔｅｍ」は、インダイレクトフォワーディングに用いる第２のトンネリング識別子（「ＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」、「ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ」）と、ベアラを識別する第２のベアラ識別子（Ｅ−ＲＡＢ ＩＤ）と、を含む。このように、第２のトンネリング識別子が第２のベアラ識別子に対応付けられている。

さらに、第３実施形態に係るハンドオーバ要求応答は、フォワーディング方式をソースＭｅＮＢ２００Ｍ１が決定可能であることを示す情報要素（Ｆｏｒｗａｒｄｉｎｇ Ｓｅｌｅｃｔａｂｌｅ）を含む。

ソースＭｅＮＢ２００Ｍ１は、フォワーディング方式をソースＭｅＮＢ２００Ｍ１が決定可能であることを示す情報要素（Ｆｏｒｗａｒｄｉｎｇ Ｓｅｌｅｃｔａｂｌｅ）を含むハンドオーバ要求応答を受信する。ソースＭｅＮＢ２００Ｍ１は、情報要素（Ｆｏｒｗａｒｄｉｎｇ Ｓｅｌｅｃｔａｂｌｅ）の受信に応じて、エラーと判断することなく、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。

ソースＭｅＮＢ２００Ｍ１は、決定したフォワーディング方式に応じて、第１のトンネリング識別子及び第２のトンネリング識別子の何れかを用いてタイプ変更ベアラに対するフォワーディング制御を行う。具体的には、ダイレクトフォワーディングを決定した場合、ソースＭｅＮＢ２００Ｍ１は、第１のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う（図２０のステップＳ１６ｂ、ステップＳ１７ｂ参照）。一方、インダイレクトフォワーディングを決定した場合、ソースＭｅＮＢ２００Ｍ１は、第２のトンネリング識別子を用いてタイプ変更ベアラに対するフォワーディング制御を行う（図２０のステップＳ１６ａ、ステップＳ１７ａ参照）。

［第４実施形態］
以下において、第４実施形態について説明する。第４実施形態に係る動作シーケンスは、図２０と同様である。但し、第４実施形態は、ハンドオーバ要求（図２０のステップＳ１１のメッセージ）及びハンドオーバ要求応答（図２０のステップＳ１４のメッセージ）の構成が第２実施形態及び第３実施形態とは異なる。

第４実施形態に係るソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングが可能であることを示す通知情報をターゲットＭｅＮＢ２００Ｍ２に送信する。具体的には、ソースＭｅＮＢ２００Ｍ１は、ソースＭｅＮＢ２００Ｍ１からターゲットＭｅＮＢ２００Ｍ２に送信するハンドオーバ要求に通知情報を含める。通知情報は、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを提案することを示す情報、又は、ソースＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間のＸ２インターフェイスが利用可能であることを示す情報である。なお、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを提案するか否かを決定する際の判断基準としては、第２実施形態において例示した１）乃至３）に示す情報を用いることができる。

ターゲットＭｅＮＢ２００Ｍ２は、通知情報の受信に応じて、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。そして、ターゲットＭｅＮＢ２００Ｍ２は、決定したフォワーディング方式をソースＭｅＮＢ２００Ｍ１に通知（又は指示）する。具体的には、ターゲットＭｅＮＢ２００Ｍ２は、決定したフォワーディング方式を示す情報をハンドオーバ要求応答に含める。

このように、第４実施形態においては、フォワーディング方式の決定権をターゲットＭｅＮＢ２００Ｍ２が持ち、ソースＭｅＮＢ２００Ｍ１は、そのような決定を補助するための通知を行う。フォワーディング方式の決定をターゲットＭｅＮＢ２００Ｍ２が行うことにより、ターゲットＭｅＮＢ２００Ｍ２は、ダイレクトフォワーディング用の第１のトンネリング識別子及びインダイレクトフォワーディング用の第２のトンネリング識別子のうち一方のみをソースＭｅＮＢ２００Ｍ１に通知すればよい。よって、上述したエラーの発生を防止することができる。

ターゲットＭｅＮＢ２００Ｍ２は、ダイレクトフォワーディングを指示する場合に、ステップＳ４０６において送信するハンドオーバ要求応答にダイレクトフォワーディングの指示（Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｉｎｄｉｃａｔｏｒ）を含めてもよい。これにより、ソースＭｅＮＢ２００Ｍ１は、ソースＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓ１へのダイレクトフォワーディングが要求されているのか否かを判断することができる。なお、ダイレクトフォワーディングの指示は、ハンドオーバ要求応答に含まれているベアラ識別子及び／又はＳｅＮＢ２００Ｓ１のＧＴＰ ＴＥ ＩＤに対応付けられてもよい。これにより、ソースＭｅＮＢ２００Ｍ１は、ハンドオーバ要求応答に複数のベアラ識別子及び又はＧＴＰ ＴＥ ＩＤが含まれている場合に、どのベアラ識別子及び／又はＧＴＰ ＴＥ ＩＤがダイレクトフォワーディング用のベアラ識別子及び／又はＧＴＰ ＴＥ ＩＤであるかを判別することができる。

（１）ハンドオーバ要求の構成例１
表３に、第４実施形態に係るハンドオーバ要求の構成例１を示す。なお、説明の便宜上、既存のＩＥの一部を省略して示している。

表３に示すように、ハンドオーバ要求は、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」を含む。「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」は、ハンドオーバすべきベアラ（Ｅ−ＲＡＢｓ Ｔｏ Ｂｅ Ｓｅｔｕｐ Ｉｔｅｍ）ごとに設けられる。なお、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」自体は、既存のＩＥである。その他のＩＥについては、３ＧＰＰ技術仕様書「ＴＳ３６．４２３」を参照されたい。

第４実施形態に係るハンドオーバ要求の構成例１においては、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを提案することを示す情報を「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」に含めることができるように、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」の内容（ＥＮＵＭＥＲＡＴＥＤ）を拡張する。

表４に、第４実施形態に係る「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」の構成例を示す。

表４に示すように、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」は、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを提案することを示す情報（ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ ｐｒｏｐｏｓｅｄ）を含めることが可能に構成される。

ソースＭｅＮＢ２００Ｍ１は、ターゲットＭｅＮＢ２００Ｍ２にダイレクトフォワーディングを提案する場合、「ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ ｐｒｏｐｏｓｅｄ」を「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」に含める。一方、ターゲットＭｅＮＢ２００Ｍ２にダイレクトフォワーディングを提案しない場合、ソースＭｅＮＢ２００Ｍ１は、既存のＩＥ（ＤＬ ｆｏｒｗａｒｄｉｎｇ ｐｒｏｐｏｓｅｄ）を「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」に含める。そして、ソースＭｅＮＢ２００Ｍ１は、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」を含むハンドオーバ要求をターゲットＭｅＮＢ２００Ｍ２に送信する。

ターゲットＭｅＮＢ２００Ｍ２は、「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」を含むハンドオーバ要求を受信する。ターゲットＭｅＮＢ２００Ｍ２は、「ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ ｐｒｏｐｏｓｅｄ」が「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」に含まれている場合、対応するベアラについて、ダイレクトフォワーディング及びインダイレクトフォワーディングの何れかのフォワーディング方式を決定する。一方、既存のＩＥ（ＤＬ ｆｏｒｗａｒｄｉｎｇ ｐｒｏｐｏｓｅｄ）が「ＤＬ Ｆｏｒｗａｒｄｉｎｇ」に含まれている場合、ターゲットＭｅＮＢ２００Ｍ２は、対応するベアラについて、ダイレクトフォワーディングを決定することはできず、インダイレクトフォワーディングを決定する。

（２）ハンドオーバ要求の構成例２
表５に、第４実施形態に係るハンドオーバ要求の構成例２を示す。なお、説明の便宜上、既存のＩＥの一部を省略して示している。

表５に示すように、ハンドオーバ要求の構成例２において、ハンドオーバ要求は、「Ｅ−ＲＡＢｓ Ｔｏ Ｂｅ Ｓｅｔｕｐ Ｌｉｓｔ」とは別のＩＥとして、ダイレクトフォワーディングを提案することを示す「Ｄｉｒｅｃｔ ｆｏｒｗａｒｄｉｎｇ ｉｎｄｉｃａｔｏｒ」を含む。つまり、ダイレクトフォワーディングの提案をベアラごとに行うのではなく、「Ｅ−ＲＡＢｓ Ｔｏ Ｂｅ Ｓｅｔｕｐ Ｌｉｓｔ」中の全ベアラについてダイレクトフォワーディングの提案を纏めて行う。

（３）ハンドオーバ要求の構成例３
ハンドオーバ要求の構成例３において、ソースＭｅＮＢ２００Ｍ１は、ソースＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間のＸ２インターフェイスが利用可能である場合、ソースＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間のＸ２インターフェイスが利用可能であることを示す情報（Ｘ２ ａｖａｉｌａｂｌｅ）をハンドオーバ要求に含める。

ソースＭｅＮＢ２００Ｍ１は、ソースＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間のＸ２インターフェイスが利用不能である場合、ソースＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間のＸ２インターフェイスが利用不能であることを示す情報（Ｘ２ ｕｎａｖａｉｌａｂｌｅ）をハンドオーバ要求に含めてもよい。

ターゲットＭｅＮＢ２００Ｍ２は、情報（Ｘ２ ａｖａｉｌａｂｌｅ）がハンドオーバ要求に含まれている場合、ダイレクトフォワーディング及びインダイレクトフォワーディングの何れかのフォワーディング方式を決定する。一方、情報（Ｘ２ ａｖａｉｌａｂｌｅ）がハンドオーバ要求に含まれていない、又は、情報（Ｘ２ ｕｎａｖａｉｌａｂｌｅ）がハンドオーバ要求に含まれている場合、ターゲットＭｅＮＢ２００Ｍ２は、ダイレクトフォワーディングを決定することはできず、インダイレクトフォワーディングを決定する。

［第４実施形態の変更例］
上述した第４実施形態において、ＵＥ１００と接続するＳｅＮＢ２００Ｓ１を変更せずにＭｅＮＢ間ハンドオーバを行うシナリオである「ｉｎｔｅｒ ＭｅＮＢ Ｈａｎｏｖｅｒ ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ」を想定していた。

しかしながら、第４実施形態は、二重接続方式を適用していないＵＥ１００がハンドオーバに伴って二重接続方式を開始するシナリオである「ｉｎｔｅｒ ｅＮＢ Ｈａｎｏｖｅｒ ｗｉｔｈ ＳｅＮＢ Ａｄｄｉｔｉｏｎ」に応用することができる。このシナリオにおいて、ソースｅＮＢにおいて二重接続方式が適用されていない。このため、ターゲットｅＮＢは、ダイレクトフォワーディングを利用可能か否か（すなわち、ソースｅＮＢとＳｅＮＢとの間にＸ２インターフェイスが存在するか否か）を知ることができない。そこで、第４実施形態に係る通知情報をソースｅＮＢからターゲットｅＮＢに送信することにより、ターゲットｅＮＢは、ダイレクトフォワーディングを利用可能か否か判断することができる。

「ｉｎｔｅｒ ｅＮＢ Ｈａｎｏｖｅｒ ｗｉｔｈ ＳｅＮＢ Ａｄｄｉｔｉｏｎ」のシナリオにおいて、まず、ソースｅＮＢは、ＵＥ１００に測定を設定し、ＵＥ１００から測定報告を受信する。なお、ソースｅＮＢがどのセルを対象として測定を設定するかは実装依存である。

異なるｅＮＢに属する複数のセルの測定結果が測定報告に含まれている場合、ソースｅＮＢは、この情報をハンドオーバ要求（ＨＯ Ｒｅｑ）に含めてターゲットｅＮＢ（ｔａｒｇｅｔ ＭｅＮＢ）に送信する。具体的には、ハンドオーバ要求内の「ＲＲＭ Ｃｏｎｆｉｇ ＩＥ in Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ （ＲＲＣ ｃｏｎｔａｉｎｅｒ）」に測定報告を含める。

ここで、ソースｅＮＢは、測定報告に含まれるセルが属するｅＮＢすべてに対してＸ２インターフェイスがあれば、ダイレクトフォワーディング可と判断することができる。或いは、測定報告に含まれるセルが属するｅＮＢのうち一部のｅＮＢに対してのみＸ２インターフェイスがある場合、ソースｅＮＢは、当該一部のｅＮＢに対してのみダイレクトフォワーディング可と判断してもよい。この場合、ソースｅＮＢは、当該一部のｅＮＢをダイレクトフォワーディング可能なｅＮＢとしてハンドオーバ要求（ＨＯ Ｒｅｑ）中でターゲットｅＮＢに通知してもよい。或いは、測定報告に対応する複数のｅＮＢ（複数のＳｅＮＢ候補）のそれぞれについてダイレクトフォワーディング可能か否かをハンドオーバ要求（ＨＯ Ｒｅｑ）中でターゲットｅＮＢに通知してもよい。

ターゲットｅＮＢ（ｔａｒｇｅｔ ＭｅＮＢ）は、転送された測定報告内の複数のセルの中から適したセルを選択し、対応するｅＮＢに「ＳｅＮＢ Ａｄｄｉｔｉｏｎ」を送信する。このようにしてＳｅＮＢが決定される。

［第５実施形態］
以下において、第５実施形態について説明する。第５実施形態において、第２実施形態及び第３実施形態と同様に、ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングを行うか又はインダイレクトフォワーディングを行うかの決定を行う。

第２実施形態及び第３実施形態において説明したように、ターゲットＭｅＮＢ２００Ｍ２は、インダイレクトフォワーディングに用いる第２のトンネリング識別子を設定した後、第１のトンネリング識別子及び第２のトンネリング識別子を含むハンドオーバ要求応答をソースＭｅＮＢ２００Ｍ１に送信する（図２０のステップＳ１４参照）。

ここで、ハンドオーバ要求応答を受信したソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを決定した場合を想定する。この場合、ソースＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓに対してダイレクトフォワーディングを行う（図１９（Ａ）参照）。具体的には、ソースＭｅＮＢ２００Ｍ１は、「ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲ」をＳｅＮＢ２００Ｓに送信し（図２０のステップＳ１６ｂ参照）、その後、ダイレクトフォワーディングを行う（図２０のステップＳ１７ｂ参照）。そして、ソースＭｅＮＢ２００Ｍ１は、自身宛のデータ転送が完了したことを示すエンドマーカをＳ−ＧＷから受信すると、ダイレクトフォワーディングの完了を示すエンドマーカをＳｅＮＢ２００Ｓに送信する。

このように、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを決定した場合、ターゲットＭｅＮＢ２００Ｍ２は、その旨を知ることができず、インダイレクトフォワーディングに用いる第２のトンネリング識別子を保持しなければならない。よって、ターゲットＭｅＮＢ２００Ｍ２が第２のトンネリング識別子を保持する間において、Ｘ２インターフェイスのリソースが無駄になるという問題がある。

図２２は、第５実施形態に係るターゲットＭｅＮＢ２００Ｍ２の動作を示すフロー図である。

図２２に示すように、ターゲットＭｅＮＢ２００Ｍ２は、第１のトンネリング識別子及び第２のトンネリング識別子を含むハンドオーバ要求応答をソースＭｅＮＢ２００Ｍ１に送信した際に、インダイレクトフォワーディングが開始されるまでの最大待ち時間を規定するタイマを開始させる（ステップＳ４１）。具体的には、タイマは、タイプ変更ベアラのベアラ識別子に対応する「ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲ」又は転送データの受信待ちを行うことが許容される時間を表す。

ターゲットＭｅＮＢ２００Ｍ２は、タイマの時間内でインダイレクトフォワーディングが開始された場合（ステップＳ４２：ＹＥＳ）には、タイマを停止させる（ステップＳ４３）。具体的には、ターゲットＭｅＮＢ２００Ｍ２は、タイプ変更ベアラのベアラ識別子に対応する「ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲ」又は転送データの受信を検知した場合、すなわち、自身が設定した第２のトンネリング識別子宛てのメッセージ又はデータの受信を検知した場合、タイマを停止させる。

一方、タイマが満了した場合、すなわち、タイマの時間内でインダイレクトフォワーディングが開始されなかった場合（ステップＳ４４：ＹＥＳ）、ターゲットＭｅＮＢ２００Ｍ２は、第２のトンネリング識別子を解放する。具体的には、ターゲットＭｅＮＢ２００Ｍ２は、タイプ変更ベアラのベアラ識別子に対応する第２のトンネリング識別子（ＧＴＰ ＴＥ ＩＤ）を解放する。ターゲットＭｅＮＢ２００Ｍ２は、第２のトンネリング識別子を解放するとともに、トランスポートレイヤアドレスを解放してもよい。

よって、ソースＭｅＮＢ２００Ｍ１がダイレクトフォワーディングを決定した場合でも、ターゲットＭｅＮＢ２００Ｍ２が適切なタイミングで第２のトンネリング識別子を解放することができるため、Ｘ２インターフェイスのリソースが無駄になることを防止することができる。

［第６実施形態］
以下において、第６実施形態について説明する。第６実施形態は、第５実施形態において説明した問題を解決しようとする実施形態であるが、解決方法が第５実施形態とは異なる。

第６実施形態に係るソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディング及びインダイレクトフォワーディングのうちの一のフォワーディング方式を決定する。ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングを決定した場合、ダイレクトフォワーディングに関する通知情報をターゲットＭｅＮＢ２００Ｍ２に送信する。ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングが完了した場合、エンドマーカをＳｅＮＢ２００Ｓに送信することに加えて、通知情報としてのエンドマーカをターゲットＭｅＮＢ２００Ｍ２に送信してもよい。この場合、ソースＭｅＮＢ２００Ｍ１は、転送データが存在しない場合でも、通知情報としてのエンドマーカをターゲットＭｅＮＢ２００Ｍ２に送信する。或いは、通知情報は、ダイレクトフォワーディングが決定されたことを示すシグナリング、又は第２のトンネリング識別子の解放を要求するシグナリングであってもよい。

第６実施形態に係るターゲットＭｅＮＢ２００Ｍ２は、第１のトンネリング識別子及び第２のトンネリング識別子を含むハンドオーバ要求応答をソースＭｅＮＢ２００Ｍ１に送信する。ターゲットＭｅＮＢ２００Ｍ２は、ダイレクトフォワーディングをソースＭｅＮＢ２００Ｍ１が決定した場合、ダイレクトフォワーディングに関する通知情報をソースＭｅＮＢ２００Ｍ１から受信する。ターゲットＭｅＮＢ２００Ｍ２は、通知情報の受信に応じて、第２のトンネリング識別子を解放する。

図２３は、第６実施形態に係る動作シーケンスの一例を示す図である。

図２３に示すように、ステップＳ５１乃至Ｓ５５は、図２０のステップＳ１１乃至Ｓ１５と同様である。

ステップＳ５６において、ソースＭｅＮＢ２００Ｍ１は、「ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲ」をＳｅＮＢ２００Ｓに送信する。

ステップＳ５７において、ソースＭｅＮＢ２００Ｍ１は、ダイレクトフォワーディングを行う。

ステップＳ５８において、ソースＭｅＮＢ２００Ｍ１は、エンドマーカをＳ−ＧＷから受信すると、ダイレクトフォワーディングの完了を示すエンドマーカをＳｅＮＢ２００Ｓに送信する。

ステップＳ５９において、ソースＭｅＮＢ２００Ｍ１は、通知情報としてのエンドマーカをターゲットＭｅＮＢ２００Ｍ２に送信する。ターゲットＭｅＮＢ２００Ｍ２は、通知情報としてのエンドマーカの受信に応じて、第２のトンネリング識別子を解放する。ターゲットＭｅＮＢ２００Ｍ２は、第２のトンネリング識別子を解放するとともに、トランスポートレイヤアドレスを解放してもよい。

[その他の実施形態]
第４実施形態の変更例において、「ｉｎｔｅｒ ｅＮＢ Ｈａｎｏｖｅｒ ｗｉｔｈ ＳｅＮＢ Ａｄｄｉｔｉｏｎ」のシナリオについて説明した。しかしながら、第４実施形態以外の実施形態についても、「ｉｎｔｅｒ ｅＮＢ Ｈａｎｏｖｅｒ ｗｉｔｈ ＳｅＮＢ Ａｄｄｉｔｉｏｎ」のシナリオに応用可能である。

上述した各実施形態において、ターゲットＭｅＮＢ２００Ｍ２は、ＳｅＮＢ追加要求の送信に代えて、ＳｅＮＢ修正要求（ＳｅＮＢ Modification Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓに送信してもよい。その場合、ＳｅＮＢ２００Ｓは、ＳｅＮＢ追加要求応答の送信に代えて、ＳｅＮＢ修正要求応答（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）をターゲットＭｅＮＢ２００Ｍ２に送信する。その場合には、ソースＭｅＮＢ２００Ｍ１は、ＳｅＮＢ解放要求の送信を省略してもよい。

上述した実施形態において、ｅＮＢ２００は、自身のタイマを停止させた後、当該タイマをリセット（クリア）する又は初期値にする。また、ｅＮＢ２００は、自身のタイマが満了した後、当該タイマをリセット（クリア）する又は初期値にする。

上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外のシステムに本発明を適用してもよい。

［付記１］
ＭｅＮＢ間ハンドオーバの承認されたシーケンスは、まだ検討事項（ＦＦＳ）を有している。

ＦＦＳ１：ＳｅＮＢにおけるＵＥコンテキストの参照は、ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ又はＣ−ＲＮＴＩ。

ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバ中にＳｅＮＢとＵＥとの間の関係を維持するために、ＳｅＮＢは、該当するＵＥコンテキストを知るために、ＭｅＮＢから識別子を通知される必要がある。ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ及びＣ−ＲＮＴＩの２つの候補がある。両方のＩＤがＵＥコンテキストを識別するために機能するが、次のような違いがある。

−ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ
このＩＤはＳｅＮＢのＸ２ＡＰでＵＥに一意に割り当てられる。よって、ＳｅＮＢ Ｘ２ＡＰ ＩＤは、該当するＵＥのためのＸ２ＡＰセッションに関連している。ＵＥコンテキストを参照するためにＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤを使用することは素直な方法であると思われる。この場合、ソースＭｅＮＢからのハンドオーバ要求は、現在の二重接続（ｄｕａｌ ｃｏｎｎｅｃｔｉｖｉｔｙ）に設定されているＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤをターゲットＭｅＮＢに通知すべきである。

−Ｃ−ＲＮＴＩ
Ｃ−ＲＮＴＩは、該当するＵＥをＡＳレイヤにおいて識別するためにＭｅＮＢ及びＳｅＮＢの両方でＭＡＣによってセルグループごとにＵＥに割り当てられる。ＳｅＮＢにおけるＣ−ＲＮＴＩがＵＥコンテキストの参照のために使用されていると仮定すると、ターゲットＭｅＮＢは、ＳｅＮＢコンテナＩＥに、ＭｅＮＢにおけるＩＤをＳｅＮＢに通知する必要があり得る。また、ソースＭｅＮＢもハンドオーバ要求の前にＳｅＮＢで割り当てられたＣ−ＲＮＴＩを知っている必要があり得る。これらは、ＲＡＮ２の努力を引き起こす可能性がある。

したがって、ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤは、ＳｅＮＢにおいてＵＥコンテキストを参照するために適している。

提案１：ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤは、ＳｅＮＢでＵＥコンテキストを参照するために使用され、ＦＦＳ１を削除すべきである。

ＦＦＳ２：ＳｅＮＢ修正要求（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）又は別のＸ２ＡＰメッセージは、ＳｅＮＢ追加要求（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ）に代えてステップ３で使用することができる。

ＦＦＳ３：ＳｅＮＢが保たれる場合、ｅＮＢ１は、ステップ６のＳｅＮＢ解放プロシージャ及びステップ１５のＵＥコンテキスト解放をスキップすることができるか。

それはＳｅＮＢ修正準備（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）又はＳｅＮＢ追加準備（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ）のいずれかを使用することが考えられる。

−ＳｅＮＢ修正準備
ＳｅＮＢ修正準備では、ＵＥコンテキストが保持され、ハンドオーバ中に修正されるため、ソースＭｅＮＢからのＳｅＮＢ解放プロシージャ及びＵＥコンテキスト解放プロシージャは必要ない。ＳｅＮＢの観点から、ＳｅＮＢにおいて該当するＵＥのＵＥコンテキストはハンドオーバ時に再利用され、ターゲットＭｅＮＢの新しい設定を適用するように修正される（例えば、ＳｅＮＢセキュリティキー）。この挙動は、現在の仕様と整合される。

ターゲットＭｅＮＢからのＳＥＮＢ ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ｍｅｓｓａｇｅに含まれるＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤに関しては、ハンドオーバプロシージャの前に、既にＳｅＮＢによって割り当てられたものと同じでなければならない。したがって、ＳｅＮＢは、ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤがソースのＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤに関連付けられていることに気づき、修正するべき該当するＵＥコンテキストを識別する必要がある。

−ＳｅＮＢ追加準備
現在のＴＲは、ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバのためのＳｅＮＢ追加準備を記述している。ＳｅＮＢは、ターゲットＭｅＮＢによって開始されたＳｅＮＢ追加要求の受信時に、該当するＵＥのための新たなＵＥコンテキストを作成することができる。ＳｅＮＢはこの時点で古いＵＥコンテキストを解放していないので、ＳｅＮＢで同じＵＥのためのＵＥコンテキストの複製（duplication）を引き起こす。よって、ソースＭｅＮＢからのＵＥコンテキスト解放プロシージャは、古いＵＥコンテキストを解放する必要があるべきである。

現在のＳｅＮＢ追加要求メッセージは、ＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤのみが含まれていることに留意すべきである。ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤがメッセージに含まれているのであれば、ＳｅＮＢは、ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバの発生を暗黙的に理解することができる。

考察１：ＳｅＮＢ追加準備及びＳｅＮＢ修正準備の両方を、ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバのために使用することができ、それぞれのプロシージャは長所と短所を持っている。

−異常な状態（Abnormal condition）
ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバのプロシージャでは３つの異常な状態があることを考慮すべきである。これらの全ての条件は、以下の表６のように記述することができる。

条件１：ＳｅＮＢ追加／修正要求拒絶を有するハンドオーバ要求肯定応答（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ ｗｉｔｈ ＳＥＮＢ ＡＤＤＩＴＩＯＮ／ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）
ＳｅＮＢ修正準備では、拒絶により、二重接続用のＸ２セッションがソースＭｅＮＢとＳｅＮＢとの間にまだ保持されているので、ソースＭｅＮＢは、ＳｅＮＢを解放すべきである。ソースＭｅＮＢは、最終のＲＲＣメッセージを把握又は拒絶を通知されない限り、ＳｅＮＢ解放を開始すべきかどうかを決定する方法がない。

一方、ＳｅＮＢ追加要求により、拒絶が発生したか否かにかかわらず、ソースＭｅＮＢは、ＳｅＮＢ解放プロシージャを開始する。この場合は、リリース１２で定義された「ＭｅＮＢからｅＮＢに変更」と同じように考えることができる。

条件２：ＳｅＮＢ追加／修正要求肯定応答を有するハンドオーバ準備失敗（ＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮ ＦＡＩＬＵＲＥ ｗｉｔｈ ＳＥＮＢ ＡＤＤＩＴＩＯＮ／ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）
ＳｅＮＢ修正準備では、ターゲットＭｅＮＢは、ソースＭｅＮＢへ二重接続のためのマスタの役割を返すためにＳｅＮＢ修正準備を再始動する必要がある。また、ソースＭｅＮＢは役割が返されたか否かをＳｅＮＢ又はターゲットＭｅＮＢのいずれかから通知される必要がある。ＳｅＮＢ追加準備では、ハンドオーバ拒絶に拘らず、二重接続のためのソースＭｅＮＢとＳｅＮＢとの間のＸ２セッションは保持されるので、ターゲットＭｅＮＢはＳｅＮＢ解放を開始すべきである。

条件３：ＳｅＮＢ追加／修正要求を有するハンドオーバ準備失敗（ＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮ ＦＡＩＬＵＲＥ ｗｉｔｈ ＳＥＮＢ ＡＤＤＩＴＩＯＮ／ＭＯＤＩＦＩＣＡＴＩＯＮ ＲＥＱＵＥＳＴ ＲＥＪＥＣＴ）
ＳｅＮＢ追加／修正準備に拘らず、追加／修正要求が既に拒絶されたので、ＳｅＮＢ解放要求を開始する必要はない。よって、何も問題はない。

異常な状態の両方のプロシージャに比べて、ＳｅＮＢ修正準備は、ＳｅＮＢ追加準備よりも複雑であるかもしれない。すなわち、ＳｅＮＢ解放要求を開始するか否かはケース・バイ・ケースである。したがって、ＳｅＮＢ追加準備をＭｅＮＢ間ハンドオーバプロシージャのために使用することが若干好ましい。

提案２：ＳｅＮＢ追加準備プロシージャは、ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバに適しており、ＦＦＳ２を削除すべきである。

提案３：ＳｅＮＢ解放プロシージャ及びＵＥコンテキスト解放プロシージャが必要であり、ＦＦＳ３を削除すべきである。

ＦＦＳ４：データ転送（Ｄａｔａ ｆｏｒｗａｒｄｉｎｇ）はさらに一般的に考慮される必要があるか；省略するか又は直接データ転送であるか？
データ転送は、スプリットベアラ及びＳＣＧベアラのオプションについて個別に分析すべきである。

−スプリットベアラオプション
ＵＬについては、ＵＥがソースＭｅＮＢにより設定された、ＰＤＣＰでＵＬ ＰＤＣＰ ＰＤＵを暗号化（ｃｉｐｈｅｒ）する限りは、ＳｅＮＢは、Ｘ２−Ｕの上でソースＭｅＮＢにＵＬ ＰＤＣＰ ＰＤＵを転送すべきである。ＭｅＮＢ間ハンドオーバ時には、ソースＭｅＮＢで復号（ｄｅｃｉｐｈｅｒ）されたＰＤＣＰ ＳＤＵは、ターゲットＭｅＮＢに転送すべきである。ＵＥの再設定の後、ＳｅＮＢは、Ｘ２−Ｕ上でターゲットＭｅＮＢにＰＤＣＰ ＰＤＵの転送を開始し、それはターゲットＭｅＮＢのものと同じ暗号化キーで暗号化される。よって、ＳｅＮＢは、ＵＥに設定された暗号化キーに応じて、適切なＭｅＮＢにＵＬ ＰＤＣＰ ＰＤＵを転送すべきである。そのため、ＳｅＮＢからターゲットＭｅＮＢへの直接データ転送は、ＵＬには適用されない。

ＵＬと同じように、ＤＬは、ＰＤＣＰ ＰＤＵの暗号化キーを考慮すべきである。すなわち、ソース／ターゲットＭｅＮＢは、ＵＥの再設定の前／後に、ＰＤＣＰ ＰＤＵを提供すべきである。よって、ソースＭｅＮＢは、ＭｅＮＢ間ハンドオーバ時にターゲットＭｅＮＢへのＰＤＣＰ ＳＤＵを転送すべきである。そのため、ＳｅＮＢからターゲットＭｅＮＢへの直接データ転送は、ＤＬには適用されない。

結論として、スプリットベアラは、直接データ転送及びデータ転送の省略を適用することができない。

考察２：スプリットベアラは、直接データ転送及びデータ転送の省略のどちらも適用することができない。

−ＳＣＧベアラオプション
スプリットベアラ場合とは異なり、Ｘ２−ＵはＳＣＧベアラオプションで想定されていない。すなわち、ＰＤＣＰ ＰＤＵ転送がないため、データ転送おける暗号化キーの問題はない。ＳＣＧベアラは、ＭｅＮＢ間ハンドオーバの間、ＳｅＮＢとＳ−ＧＷとの間のＧＴＰトンネルを保持することができるので、ＤＬ ＰＤＣＰ ＳＤＵは、ＭｅＮＢハンドオーバ後に適用することができ、ＵＬ ＰＤＣＰ ＳＤＵも同様にすることができる。したがって、ＭｅＮＢ間ハンドオーバに応じて、ＳＣＧベアラは、ＳｅＮＢからソースＭｅＮＢへのデータ転送、及びターゲットＭｅＮＢからＳｅＮＢへのデータ転送を省略することができる。

また、ベアラタイプの変更のサポートを想定すると、ベアラタイプ情報がｅＮＢ間で交換される限りは、直接データ転送が可能である。ＭＣＧベアラからＳＣＧベアラへのケースでは、ソースＭｅＮＢは、ＳｅＮＢにＰＤＣＰ ＳＤＵの直接データ転送を行うことができる。ＭＣＧベアラからＳＣＧベアラのケースでは、ＳｅＮＢは、ターゲットＭｅＮＢに直接データ転送を実行することができる。

結論として、ＳＣＧベアラはデータ転送を省略することができる。また、ＭＣＧベアラとＳＣＧベアラとの間のベアラタイプ変更時に、対応するベアラ情報がｅＮＢ間で交換される限りは、直接データ転送を適用することが可能である。情報交換の詳細はＷＩ段階に任される。

考察３：ベアラタイプ変更が発生していない場合、ＳＣＧベアラは、データ転送を省略することができる。

提案４：ＳＣＧベアラは、ベアラタイプ変更時に直接データ転送を行うことができる。詳細はＷＩフェーズに委ね、ＦＦＳ４を削除すべきである。

ＦＦＳ５：ベアラタイプの変更
ベアラタイプの変更が、ベアラ関連のＩＥの取り扱いに影響を与えるかどうかを検討すべきであり、それらは、ハンドオーバ要求中のＥ−ＲＡＢｓ Ｔｏ Ｂｅ Ｓｅｔｕｐ Ｌｉｓｔ及びＲＲＣ Ｃｏｎｔｅｘｔと、ハンドオーバ肯定応答中のＥ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ、Ｅ−ＲＡＢｓ Ｎｏｔ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ、及びＴａｒｇｅｔ ｅＮＢ Ｔｏ Ｓｏｕｒｃｅ ｅＮＢ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒにマッピングされる。また、また、パス切り替え要求（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）も考慮されるべきである。一方、非ベアラ関連のＩＥ、例えばＵＥ−ＡＭＢＲに影響があってはならない。

−Ｘ２ ＡＰ中のＲＲＣコンテナ
ハンドオーバ中のベアラタイプ変更を伴うＲＲＣ再設定については、ＲＲＣコンテキストに比べて、ターゲットｅＮＢからソースｅＮＢへの透過的なコンテナ（Ｔａｒｇｅｔ ｅＮＢ ｔｏ Ｓｏｕｒｃｅ ｅＮＢ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ）に、変更されたベアラ設定を含むことが必要である。最終的なＲＲＣメッセージを作成するために、ＭｅＮＢは、制限なしにこれらのＩＥを使用することができる。現在の仕様によれば、ハンドオーバ中にベアラのタイプを変更するのには制限はない。よって、問題はＲＲＣコンテナにはない。

−Ｘ２ ＡＰにおけるＥ−ＲＡＢ関連リスト
ベアラタイプの変更にかかわらず、ハンドオーバ要求中のＥ−ＲＡＢｓ Ｔｏ Ｂｅ Ｓｅｔｕｐ Ｌｉｓｔは、ベアラタイプ（すなわち、ＳＣＧ又はスプリット）を含む必要がある。ベアラタイプの変更がハンドオーバ準備プロシージャ中に発生した場合でも、ＭＣＧベアラに対応する少なくとも１つの非ＧＢＲ Ｅ−ＲＡＢがターゲットＭｅＮＢに認められる限りは、ハンドオーバ肯定応答が各ベアラタイプ変更をソースＭｅＮＢに通知する必要がないかもしれない。

考察４：ＲＲＣコンテナ及びＥ−ＲＡＢ関連リストを考慮すると、ベアラタイプの変更についてリリース１２のハンドオーバ準備プロシージャには問題はない。

−Ｘ２ ＡＰでのＧＴＰ ＴＥＩＤの取り扱い
ベアラタイプの変更を想定した場合、データ転送アドレスの取り扱いが各シナリオについて考慮されるべきである。ＭｅＮＢ間ハンドオーバ中にＳｅＮＢ追加準備を使用することをこの分析で想定する。なお、すでにリリース１２においてハンドオーバ中にＳＣＧ／スプリットからＭＣＧに全てのベアラのベアラタイプの変更が許可されている（すなわち、ＭｅＮＢからｅＮＢへの変更プロシージャ）。

ＳＣＧベアラからＭＣＧベアラへ
ＭｅＮＢ間ハンドオーバ中にＳＣＧからＭＣＧベアラへのベアラタイプ変更の一部を実行するには、ターゲットＭｅＮＢは、変更されるベアラをＳｅＮＢ追加要求中に追加する必要はないかもしれない（すなわち、ターゲットＭｅＮＢは、保持するベアラをＳｅＮＢ追加要求のＥ−ＲＡＢ Ｔｏ Ｂｅ Ａｄｄｅｄ ＩＥに含めるだけである）。ＭＣＧベアラに変更されるＳＣＧベアラはソースＭｅＮＢで自律的に解放されるかである。そして、ターゲットは、エンドポイントを所有するために、パス切り替え要求によって、ＳＣＧベアラのＧＴＰ−ＴＥＩＤの変更をＭＭＥに要求すべきである。

スプリットベアラからＭＣＧベアラへ
スプリットベアラからＭＣＧベアラへのベアラタイプ変更の場合は、スプリットベアラを含むＳ１−Ｕのための全てのＧＴＰ−ＴＥＩＤはＭｅＮＢで終端されている。よって、ターゲットＭｅＮＢは従来のＸ２ハンドオーバプロシージャに従う、すなわち、ＦＦＳ４で説明したように直接データ転送の懸念がなく、ＭＭＥへのパス切り替え要求を行う。

ＭＣＧベアラからＳＣＧベアラ又はスプリットベアラへ
ＭＣＧベアラからＳＣＧ／スプリットベアラへのベアラタイプの変更に関しては、このＳＩで議論されているＳｅＮＢ追加を伴うハンドオーバと同じプロシージャとして考えられる。

データ転送（すなわち、直接データ転送）の最適化として、ＧＴＰ ＴＥＩＤの取り扱いを最適化する余地がある。例えば、ＳｅＮＢからＭＣＧベアラへのケースでは、ＳｅＮＢからターゲットＭｅＮＢへのデータ転送は、ＳｅＮＢが、直接データ転送のためにＭｅＮＢのＧＴＰ ＴＥＩＤを知っている必要がある。もしあれば（例えば、ＳｅＮＢ追加要求又はＳｅＮＢ解放要求が直接データ転送アドレスを含む）、ＷＩ段階でいくつかの最適化が必要となり得る。

考察５：ＧＴＰ ＴＥＩＤの取り扱いの観点からは、直接データ転送のないベアラタイプの変更はＳＩ段階で実現可能である。

−Ｓ１ ＡＰでのパス切り替え要求
ベアラタイプの変更を想定した場合、パス切り替え要求プロシージャが考慮されるべきである。

ＭＣＧベアラからＳＣＧベアラへ
ベアラタイプの変更の場合には、パス切り替え要求メッセージは、ＳｅＮＢ及びターゲットＭｅＮＢの各トランスポート層アドレス（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ ａｄｄｒｅｓｓ）ＩＥを含み得る。このような現象は、通常のハンドオーバで想定されておらず、リリース１２では、パス切り替え要求メッセージは、ターゲットＭｅＮＢのみのトランスポート層アドレスを常に含むことを意味する。ＭＭＥは、このようなケースを想定していない可能性があるため、ＭＭＥは、このような現象を、メッセージ内の暗黙的又は明示的な指示によって、ベアラタイプの変更を有するＭｅＮＢ間ハンドオーバを示すと理解する必要があり得る。しかし、それはＷＩ段階で議論されるべきである。

ＳＣＧベアラからＭＣＧベアラへ
一方、ＳＣＧベアラからＭＣＧベアラへのケースでは、パス切り替え要求メッセージは、ターゲットＭｅＮＢのみのトランスポート層アドレスＩＥが含まれる。これは、通常のハンドオーバの場合と同様である。よって、何も問題はありません。

スプリット／ＭＣＧからＭＣＧ／スプリットベアラへ
この場合、スプリットベアラ又はＭＣＧベアラに拘らず、Ｓ１−ＵベアラはＭｅＮＢで終端されているので、ターゲットＭｅＮＢは通常のハンドオーバのようなパス切り替え要求プロシージャを実行する。

考察６：ＭＣＧベアラからＳＣＧベアラへのケースについて不明確な点があるが、それはＳＩ段階に任せて、ベアラタイプの変更はＳＩ段階で実現可能である。

なお、直接ベアラタイプ変更、すなわち、スプリット／ＳＣＧベアラからＳＣＧ／スプリットベアラへは、ＲＡＮ２仕様でサポートされていない。

ほとんど全てのリリース１２のプロシージャ及び情報要素は、基本的にベアラタイプの変更で良好に機能するが、リリース１３のためのいくつかのアップデートがＷＩ段階で考慮されるべきである。さらに、ベアラタイプの変更は、例えばＲＲＭに基づいて、ターゲットＭｅＮＢに二重接続設定のいくつかの柔軟性を可能にすることが期待される。したがって、ＲＡＮ３は、ＭｅＮＢ間ハンドオーバ中のベアラタイプの変更が可能であると結論づけるである。

提案５：考察４から６を考慮して、ベアラタイプの変更はＭｅＮＢ間ハンドオーバ中に実現可能であり、ＦＦＳ５を削除すべきである。

［付記２］
（はじめに）
この付記では、ＳｅＮＢを変更しないＭｅＮＢ間ハンドオーバのための直接データ転送について説明する。

（直接データ転送）
直接データ転送は２つのベアラタイプ変更時に考慮される。

１．ＳＣＧからＭＣＧへの変更（すなわち、ＳｅＮＢからターゲットＭｅＮＢへの直接データ転送）
２．ＭＣＧからＳＣＧへの変更（すなわち、ソースＭｅＮＢからＳｅＮＢへの直接データ転送）
以下では、両方のベアラタイプの変更のための直接データ転送を導入するための潜在的な仕様への影響を分析する。

（ＳＣＧからＭＣＧへの変更）
図２４は、ベアラタイプの変更（ＳＣＧからＭＣＧへ）を伴う直接データ転送を示す。

ＳＣＧからＭＣＧへのベアラタイプの変更については、ターゲットＭｅＮＢのデータ転送アドレス（すなわち、ＧＴＰトンネルエンドポイントＩＥ）がＳｅＮＢに提供されるべきである。ターゲットＭｅＮＢは、対応するＳＣＧベアラのデータ転送アドレスをＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ（ステップ４）に含めるべきである。そして、ソースＭｅＮＢは、受信したアドレスをＳｅＮＢ解放要求（ステップ５）に含めるべきである。仕様への影響の観点から、ＧＴＰトンネルエンドポイントＩＥが既にメッセージに含まれているので、これらのメッセージは、アドレスを転送するために適用されるであろう。

図２４において、ステップ１〜３はＴＲと同様である。

ステップ４．ターゲットＭｅＮＢは、変更するＳＣＧベアラのための自身のＧＴＰトンネルエンドポイントをＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥに含める。

ステップ５．ソースＭｅＮＢは、ターゲットＭｅＮＢのＧＴＰトンネルエンドポイントを含むＳｅＮＢ解放要求を送信する。

提案１：ＳｅＮＢからターゲットＭｅＮＢへの直接データ転送については、ターゲットＭｅＮＢのＧＴＰトンネルエンドポイントは、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ及びＳＥＮＢ ＲＥＬＥＡＳＥ ＲＥＱＵＥＳＴで、ソースＭｅＮＢを介してＳｅＮＢに伝達されるべきである。

ＳＣＧからＭＣＧへのベアラタイプの変更の問題
−ソースＭｅＮＢの観点
ベアラタイプの変更及び直接データ転送が行われるかどうかはターゲットＭｅＮＢによって決定されるべきである。しかし、ソースＭｅＮＢは決定を知ることはできない。言い換えれば、ソースＭｅＮＢは、ＳｅＮＢ解放要求に自身のＧＴＰトンネルエンドポイント又はターゲットＭｅＮＢのＧＴＰトンネルエンドポイントを含めるべきかどうかを理解することはできない。それを理解するには、２つの可能な選択肢がある。

ＡＬＴ１．ソースＭｅＮＢはＲＲＣコンテナを把握し、ベアラタイプ変更を行うかどうかを理解する。

ＡＬＴ２．ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥは、直接データ転送が行われるかどうかを示すために明示的なＩＥを含む。

ＡＬＴ１は、ＲＡＮ３仕様に与える影響が小さいが、レイヤの独立性を壊し、ソースＭｅＮＢの負担が大きい。したがって、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥに明示的インジケータを追加することが望ましい。

提案２：ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥは、直接データ転送が行われるかどうかを示すために追加のＩＥを含めるべきである。

−ＳｅＮＢの観点
現在の仕様によると、ＳＮステータス転送（ＳＮ ＳＴＡＴＵＳ ＴＲＡＮＳＦＥＲ）及びデータ転送の方向を揃える必要がある。言い換えると、ＳｅＮＢは、直接データ転送が適用されるかどうかを理解する必要がある。したがって、直接データ転送をＳｅＮＢに知らせるためには、ＳｅＮＢ解放要求に明示的なインジケータを追加することが望ましい。

提案３：ＳｅＮＢ解放要求は、直接データ転送が行われるかどうかを示すために追加のＩＥを含むべきである。

（ＭＣＧからＳＣＧへの変更）
図２５は、ベアラタイプの変更（ＭＣＧからＳＣＧへ）を伴う直接データ転送を示す。

ＭＣＧからＳＣＧへのベアラタイプ変更の準備として、ＳｅＮＢは、新しいＳＣＧベアラの確立のための追加のＥ−ＲＡＢが要求されるべきである。ターゲットＭｅＮＢは、ＳｅＮＢ追加要求（ステップ２）において追加のＥ−ＲＡＢを要求すると想定することができる。したがって、ＳｅＮＢは、ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ（ステップ３）に自身のデータ転送アドレスを含める。

ＭＣＧからＳＣＧへの変更の場合における間接データ転送と直接データ転送との違いは、ソースＭｅＮＢが、ＳｅＮＢのデータ転送アドレスを通知しなければならないということである。これはＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ（ステップ４）にＳｅＮＢのＧＴＰトンネルエンドポイントを含めることによって容易に達成される。

図２５において、ステップ１はＴＲと同様である。

ステップ２．ターゲットＭｅＮＢは、ＳｅＮＢ追加要求（ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ）において追加ＳＣＧベアラを要求する。

ステップ３．ＳｅＮＢは、ＳｅＮＢ追加要求肯定応答（ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）に、追加ベアラのためのＧＴＰトンネルエンドポイントを含める。

ステップ４．ターゲットＭｅＮＢは、ハンドオーバ要求肯定応答（ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ）に、ＳｅＮＢのＧＴＰトンネルエンドポイントを含める。

提案４：ソースＭｅＮＢからＳｅＮＢへの直接データ転送については、ＳｅＮＢのＧＴＰトンネルエンドポイントは、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥで、ターゲットＭｅＮＢを介してソースＭｅＮＢに伝達されるべきである。

［付記３］
成功する動作（Ｓｕｃｃｅｓｓｆｕｌ Ｏｐｅｒａｔｉｏｎ）
図２６は、ハンドオーバ準備が成功する動作を示す。

ソースｅＮＢは、ターゲットｅＮＢにＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴメッセージを送信することによりプロシージャを開始する。ソースｅＮＢは、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴメッセージを送信すると、タイマＴ_{ＲＥＬＯＣｐｒｅｐ}を開始しなければならない。

Ｅ−ＲＡＢ Ｌｅｖｅｌ ＱｏＳ Ｐａｒａｍｅｔｅｒｓ ＩＥに含まれるＡｌｌｏｃａｔｉｏｎ ａｎｄ Ｒｅｔｅｎｔｉｏｎ Ｐｒｉｏｒｉｔｙ ＩＥの値に応じたリソースの割り当ては、ＴＳ３６．４１３におけるＥ−ＲＡＢのセットアッププロシージャに記載された原則に従わなければならない。

ソースｅＮＢはＧＵＭＭＥＩ ＩＥにソースＭＭＥノードに対応する任意のＧＵＭＭＥＩを含めることができる。

要求された非ＧＢＲ Ｅ−ＲＡＢの少なくとも１つが、ターゲットセルＩＤ ＩＥで示されるセルに入ることを許可された場合、ターゲットｅＮＢは、必要なリソースを確保し、ソースｅＮＢにＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージを送信しなければならない。ターゲットｅＮＢは、Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ ＩＥに、ターゲットセルでリソースが準備されたＥ−ＲＡＢを含めなければならない。ターゲットｅＮＢは、Ｅ−ＲＡＢｓ Ｎｏｔ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ ＩＥに、承認しなかったＥ−ＲＡＢを適切な原因値（ｃａｕｓｅ ｖａｌｕｅ）と共に含めなければならない。

ターゲットｅＮＢは、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴメッセージの受信時に：
−ＵＥコンテキスト情報ＩＥ中のＵＥ Ｓｅｃｕｒｉｔｙ Ｃａｐａｂｉｌｉｔｉｅｓ ＩＥ及びＡＳ Ｓｅｃｕｒｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ ＩＥ中の情報を用いて、ＵＥとターゲットｅＮＢとの間のＡＳセキュリティの関係の設定を準備する。

ソースｅＮＢは、下りリンクデータの転送を行うことを提案する各Ｅ−ＲＡＢのために、ハンドオーバ要求メッセージのＥ−ＲＡＢｓ Ｔｏ ｂｅ Ｓｅｔｕｐ Ｉｔｅｍ ＩＥ内に、ＤＬ Ｆｏｒｗａｒｄｉｎｇ ＩＥを含めなければならない。承認することを決定した各Ｅ−ＲＡＢのために、ターゲットｅＮＢは、下りリンクデータの提案された転送を受け入れることを示すために、ハンドオーバ要求肯定応答メッセージのＥ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｉｔｅｍ ＩＥ内に、ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥを含める。このＧＴＰトンネルエンドポイントは、実装の選択に応じて、パス切り替え要求メッセージ（ＴＳ３６．４１３を参照）のＥ−ＲＡＢ Ｔｏ Ｂｅ Ｓｗｉｔｃｈｅｄ ｉｎ Ｄｏｗｎｌｉｎｋ Ｌｉｓｔ ＩＥ中のＧＴＰ ＴＥＩＤ ＩＥと異なる場合がある。

Ｅ−ＲＡＢｓ Ａｄｍｉｔｔｅｄ Ｌｉｓｔ ＩＥ中の各ベアラについて、ターゲットｅＮＢは、そのベアラのために実行される上りリンクパケットのデータ転送を要求することを示すために、ＵＬ ＧＴＰトンネルエンドポイントＩＥを含めることができる。

ソースｅＮＢは、ハンドオーバ要求肯定応答を受信すると、タイマＴ_{ＲＥＬＯＣｐｒｅｐ}を停止し、タイマＴＸ２_{ＲＥＬＯＣｏｖｅｒａｌｌ}を開始し、ハンドオーバ準備プロシージャを終了しなければならない。ソースｅＮＢは、そのＸ２のＵＥに関連するシグナリングのための準備されたハンドオーバを持つように定義される。

ハンドオーバ制限リストＩＥがある場合、ハンドオーバ要求メッセージに含まれる場合、ターゲットｅＮＢは、
−ＵＥコンテキストにおけるハンドオーバ制限リストＩＥにおいて受信された情報を格納する。

−二重接続動作中に適切なＳＣＧを選択するためにこの情報を使用する。

二重接続
ＭｅＮＢ間ハンドオーバ中に、ベアラオプションがＳＣＧベアラに変更される各Ｅ−ＲＡＢについて、ターゲットＭｅＮＢは、ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージから受信したＳｅＮＢのＤＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ／ ＵＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥを、ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージ中のＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ／ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥに設定し、Ｄｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｉｎｄｉｃａｔｏｒ ＩＥを「ｄｉｒｅｃｔ ｄａｔａ ｆｏｒｗａｒｄｉｎｇ」に設定する。

成功する動作（Ｓｕｃｃｅｓｓｆｕｌ Ｏｐｅｒａｔｉｏｎ）
図２７は、ＭｅＮＢ始動のＳｅＮＢ解放が成功する動作を示す。

ＭｅＮＢは、ＳｅＮＢ解放要求（ＳＥＮＢ ＲＥＬＥＡＳＥ ＲＥＱＵＥＳＴ）メッセージを送信することにより、プロシージャを開始する。ＳｅＮＢ解放要求メッセージを受信すると、ＳｅＮＢは、ＵＥにユーザデータの提供を停止しなければならない。ＳｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ ＩＥがＳｅＮＢから取得された場合、それが含まれなければならない。ＭｅＮＢは、原因（Ｃａｕｓｅ）ＩＥ内で適切な情報を提供することができる。

ＳｅＮＢでベアラコンテキストがＳＣＧベアラオプションで設定されていた場合、ＭｅＮＢが上りリンク／下りリンクデータの転送を要求した各ＳＣＧベアラについて、ＭｅＮＢは、そのＳＣＧベアラのための上りリンク／下りリンクパケットのデータ転送をＳｅＮＢが実行する必要があることを示すために、ＳｅＮＢ解放要求メッセージのＥ−ＲＡＢｓ Ｔｏ Ｂｅ Ｒｅｌｅａｓｅｄ Ｉｔｅｍ ＩＥ内に、ＵＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ／ ＤＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥを含める。

ＳｅＮＢでベアラコンテキストがスプリットベアラオプションで設定されていた場合、ＭｅＮＢが下りリンクデータの転送を要求した各ＳＣＧベアラについて、ＭｅＮＢは、そのスプリットベアラのための下りリンクパケットのデータ転送をＳｅＮＢが実行する必要があることを示すために、ＳｅＮＢ解放要求メッセージのＥ−ＲＡＢｓ Ｔｏ Ｂｅ Ｒｅｌｅａｓｅｄ Ｉｔｅｍ ＩＥ内に、ＤＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥを含める。

ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥのＥ−ＲＡＢ Ａｄｍｉｔｔｅｄ Ｉｔｅｍ ＩＥ中のＤｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｉｎｄｉｃａｔｏｒ ＩＥが「ｄｉｒｅｃｔ ｄａｔａ ｆｏｒｗａｒｄｉｎｇ」に設定された各Ｅ−ＲＡＢについて、ソースＭｅＮＢは、ＳＥＮＢ ＡＤＤＩＴＩＯＮ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥメッセージから受信したＭｅＮＢのＵＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ／ ＤＬ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥを、ＳＥＮＢ ＲＥＬＥＡＳＥ ＲＥＱＵＥＳＴメッセージのＵＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ／ ＤＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ Ｔｕｎｎｅｌ Ｅｎｄｐｏｉｎｔ ＩＥに設定し、Ｅ−ＲＡＢ Ｔｏ Ｂｅ Ｒｅｌｅａｓｅｄ Ｉｔｅｍ ＩＥ中のＤｉｒｅｃｔ Ｄａｔａ Ｆｏｒｗａｒｄｉｎｇ Ｉｎｄｉｃａｔｏｒ ＩＥを「ｄｉｒｅｃｔ ｄａｔａ ｆｏｒｗａｒｄｉｎｇ」に設定する。

（ハンドオーバ要求肯定応答）
このメッセージは、ターゲットで準備されたリソースに関してソースｅＮＢに通知するために、ターゲットｅＮＢによって送信される。

方向：ターゲットｅＮＢからソースｅＮＢへ。

（ＳｅＮＢ解放要求）
このメッセージは、リソースの解放を要求するためにＭｅＮＢによってＳｅＮＢに送信される。

方向：ＭｅＮＢからＳｅＮＢへ。

（直接データ転送インジケータ）
直接データ転送インジケータＩＥは、Ｅ−ＲＡＢに対応する直接データ転送が要求されることを示す。

［相互参照］
米国仮出願６２／１４５７５５号（２０１５年４月１０日出願）、米国仮出願６２／２２２８７７号（２０１５年９月２４日出願）、米国仮出願６２／２５１８９０号（２０１５年１１月６日出願）、及び米国仮出願６２／２５１９０７号（２０１５年１１月６日出願）の全内容が参照により本発明に組み込まれている。

Claims (3)

1. 二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末を、前記ソースマスタ基地局からターゲットマスタ基地局へハンドオーバするハンドオーバ手順を制御するための方法であって、
   前記ソースマスタ基地局から前記ターゲットマスタ基地局に対してハンドオーバ要求を送信し、
   前記ターゲットマスタ基地局から、前記セカンダリ基地局が維持されることを示す情報を含むハンドオーバ要求応答を前記ソースマスタ基地局が受信し、
   前記ハンドオーバ要求応答の受信後、前記ユーザ端末のベアラを、前記ソースマスタ基地局を介して確立するＭＣＧベアラから前記セカンダリ基地局を介して確立するＳＣＧベアラに変更する場合に、前記ソースマスタ基地局から前記セカンダリ基地局に対してダイレクトデータフォワーディングを行う、
   方法。
2. 前記セカンダリ基地局が維持されることを示す情報を含む前記ハンドオーバ要求応答を受信した場合でも、前記ソースマスタ基地局から前記セカンダリ基地局にセカンダリ基地局解放要求を送信する、
   請求項１に記載の方法。
3. 二重接続方式によってソースマスタ基地局及びセカンダリ基地局に接続しているユーザ端末を、前記ソースマスタ基地局からターゲットマスタ基地局へハンドオーバするハンドオーバ手順において、前記ソースマスタ基地局として動作する基地局であって、
   前記ターゲットマスタ基地局に対してハンドオーバ要求を送信する送信部と、
   前記ターゲットマスタ基地局から、前記セカンダリ基地局が維持されることを示す情報を含むハンドオーバ要求応答を受信する受信部と、
   前記ハンドオーバ要求応答の受信後、前記ユーザ端末のベアラを、前記ソースマスタ基地局を介して確立するＭＣＧベアラから前記セカンダリ基地局を介して確立するＳＣＧベアラに変更する場合に、前記ソースマスタ基地局から前記セカンダリ基地局に対してダイレクトデータフォワーディングを行う制御部とを備える、
   基地局。

Images