JP2016213880A - マスタ基地局、セカンダリ基地局、及びプロセッサ - Google Patents

Abstract

【課題】ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおいて、効率的なハンドオーバを提供する。【解決手段】ターゲットマスタ基地局として動作するマスタ基地局２００Ｍ２は、セカンダリ基地局２００Ｓを変更することなく、ソースマスタ基地局２００Ｍ１からターゲットマスタ基地局に対してユーザ端末１００のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う。【選択図】図２３

Description

本発明は、移動通信システムにおいて用いられるマスタ基地局、セカンダリ基地局、及びプロセッサに関する。

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

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

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

３ＧＰＰ技術報告書 「ＴＲ ３６．８４２ Ｖ１２．０．０」 ２０１４年１月７日

ＲＲＣコネクティッド状態のユーザ端末は、移動に伴ってハンドオーバを行う。

しかしながら、ＲＲＣコネクティッド状態のユーザ端末が二重接続方式の通信を行う場合には、当該ユーザ端末のハンドオーバに係る処理が複雑になるという問題がある。

そこで、本発明は、二重接続方式において効率的なハンドオーバを実現するマスタ基地局、セカンダリ基地局、及びプロセッサを提供することを目的とする。

第１の特徴に係るマスタ基地局は、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおいて、ターゲットマスタ基地局として動作する。前記マスタ基地局は、前記セカンダリ基地局を変更することなく、前記ソースマスタ基地局から前記ターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備える。前記制御部は、前記セカンダリ基地局に関する情報を含むハンドオーバ要求を前記ソースマスタ基地局から受信する処理と、前記ハンドオーバ要求の受信に応じて、マスタ基地局変更に関する第１のメッセージを前記セカンダリ基地局に送信する処理と、前記第１のメッセージに対する肯定応答である第２のメッセージを前記セカンダリ基地局から受信する処理と、を行う。前記第２のメッセージは、前記セカンダリ基地局が前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む。

第２の特徴に係るセカンダリ基地局は、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける前記セカンダリ基地局である。前記セカンダリ基地局は、前記セカンダリ基地局を変更することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備える。前記制御部は、前記セカンダリ基地局に関する情報を含むハンドオーバ要求を受信した前記ターゲットマスタ基地局から、マスタ基地局変更に関する第１のメッセージを受信する処理と、前記第１のメッセージに対する肯定応答である第２のメッセージを前記ターゲットマスタ基地局に送信する処理と、を行う。前記第２のメッセージは、前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む。

第３の特徴に係るプロセッサは、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおいて、ターゲットマスタ基地局として動作するマスタ基地局のためのプロセッサである。前記プロセッサは、前記セカンダリ基地局を変更することなく、前記ソースマスタ基地局から前記ターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う。前記プロセッサは、前記セカンダリ基地局に関する情報を含むハンドオーバ要求を前記ソースマスタ基地局から受信する処理と、前記ハンドオーバ要求の受信に応じて、マスタ基地局変更に関する第１のメッセージを前記セカンダリ基地局に送信する処理と、前記第１のメッセージに対する肯定応答である第２のメッセージを前記セカンダリ基地局から受信する処理と、を行う。前記第２のメッセージは、前記セカンダリ基地局が前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む。

第４の特徴に係るプロセッサは、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける前記セカンダリ基地局のためのプロセッサである。前記プロセッサは、前記プロセッサは、前記セカンダリ基地局を変更することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う。前記プロセッサは、前記セカンダリ基地局に関する情報を含むハンドオーバ要求を受信した前記ターゲットマスタ基地局から、マスタ基地局変更に関する第１のメッセージを受信する処理と、前記第１のメッセージに対する肯定応答である第２のメッセージを前記ターゲットマスタ基地局に送信する処理と、を行う。前記第２のメッセージは、前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む。

第１実施形態乃至第６実施形態に係るＬＴＥシステムの構成図である。 第１実施形態乃至第６実施形態に係るＵＥのブロック図である。 第１実施形態乃至第６実施形態に係るｅＮＢのブロック図である。 第１実施形態乃至第６実施形態に係る無線インターフェイスのプロトコルスタック図である。 二重接続方式の概要を説明するための図である。 第１のＵＰアーキテクチャ（ＵＰアーキテクチャ「１Ａ」）を示す図である。図６Ａはデータパス構成を示し、図６Ｂはプロトコルスタック構成を示す。 第２のＵＰアーキテクチャ（ＵＰアーキテクチャ「３Ｃ」）を示す図である。図７Ａはデータパス構成を示し、図７Ｂはプロトコルスタック構成を示す。 第１実施形態に係る動作環境を示す図である。 基本シーケンスを示すシーケンス図である。 第１実施形態に係る動作パターン１を示すシーケンス図である。 第１実施形態に係る動作パターン２を示すシーケンス図である。 第２実施形態に係る動作シナリオを示す図である。 第２実施形態に係るＳ−ＧＷ識別情報をｅＮＢ間で送受信するための第１の動作を示す図である。 第２実施形態に係るＳ−ＧＷ識別情報をｅＮＢ間で送受信するための第２の動作を示す図である。 第２実施形態に係る動作を示すフロー図である。 第３実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。 第３実施形態の変更例１に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。 ＳＣＧベアラ・オプションの場合のＴＥＩＤについて説明するための図である。 スプリットベアラ・オプションの場合のＴＥＩＤについて説明するための図である。 第３実施形態の変更例２に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。 第４実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。 第５実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。 第６実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。 実施形態の付記１に係る図である。 実施形態の付記１に係る図である。 実施形態の付記１に係る図である。 実施形態の付記１に係る図である。 実施形態の付記１に係る図である。 実施形態の付記１に係る図である。 実施形態の付記２に係る図である。 実施形態の付記２に係る図である。 実施形態の付記２に係る図である。 実施形態の付記２に係る図である。 実施形態の付記３に係る図である。 実施形態の付記３に係る図である。 実施形態の付記３に係る図である。

［実施形態の概要］
第１実施形態乃至第６実施形態に係る通信制御方法は、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける方法である。前記通信制御方法は、前記ユーザ端末と前記セカンダリ基地局との間の接続を解放することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順を備える。

第１実施形態乃至第６実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記ソースマスタ基地局が、前記ユーザ端末のハンドオーバを要求するハンドオーバ要求を前記ターゲットマスタ基地局に送信するステップを有する。前記ハンドオーバ要求は、前記マスタ基地局間ハンドオーバ手順を示す情報を含む。

第３実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記ターゲットマスタ基地局が、前記ハンドオーバ要求の受信に応じて、前記セカンダリ基地局における設定の修正を要求する修正要求を前記セカンダリ基地局に送信するステップと、前記セカンダリ基地局が、前記修正要求の受信に応じて、前記修正要求に対する修正要求肯定応答を前記ターゲットマスタ基地局に送信するステップと、を有する。前記修正要求は、前記マスタ基地局間ハンドオーバ手順を示す情報を含む。

第３実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記ターゲットマスタ基地局が、前記修正要求肯定応答の受信に応じて、前記ハンドオーバ要求に対するハンドオーバ肯定応答を前記ソースマスタ基地局に送信するステップを有する。

第３実施形態の変更例２において、前記マスタ基地局間ハンドオーバ手順は、前記ターゲットマスタ基地局が、前記修正要求肯定応答を前記セカンダリ基地局に送信するよりも前において、前記ハンドオーバ要求に対するハンドオーバ肯定応答を前記ソースマスタ基地局に送信するステップを有する。

第４実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記ソースマスタ基地局が、前記セカンダリ基地局における設定の修正を要求する修正要求を前記セカンダリ基地局に送信するステップを有する。前記修正要求は、前記マスタ基地局間ハンドオーバ手順を示す情報を含む。

第５実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記セカンダリ基地局が、前記修正要求の受信に応じて、前記ユーザ端末のハンドオーバを要求するハンドオーバ要求を前記ターゲットマスタ基地局に送信するステップを有する。

第６実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記ターゲットマスタ基地局が、前記ハンドオーバ要求の受信に応じて、前記セカンダリ基地局を前記ユーザ端末のための新たなセカンダリ基地局として設定するための追加要求を前記セカンダリ基地局に送信するステップを有する。

第３実施形態乃至第６実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記セカンダリ基地局における設定に失敗した場合、前記ソースマスタ基地局が、前記マスタ基地局間ハンドオーバ手順の失敗を示す情報を前記ターゲットマスタ基地局又は前記セカンダリ基地局から受信するステップを有する。

第３実施形態乃至第６実施形態において、前記マスタ基地局間ハンドオーバ手順は、前記セカンダリ基地局とサービングゲートウェイとの間のトンネリングについて、前記サービングゲートウェイにおけるＴＥＩＤを変更することなく維持するステップを有する。

第１実施形態乃至第６実施形態に係るマスタ基地局は、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおいて、ソースマスタ基地局又はターゲットマスタ基地局として動作する。前記マスタ基地局は、前記ユーザ端末と前記セカンダリ基地局との間の接続を解放することなく、前記ソースマスタ基地局から前記ターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備える。

第１実施形態乃至第６実施形態に係るセカンダリ基地局は、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける前記セカンダリ基地局である。前記セカンダリ基地局は、前記ユーザ端末と前記セカンダリ基地局との間の接続を解放することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備える。

第１実施形態乃至第６実施形態に係るユーザ端末は、ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける前記ユーザ端末である。前記ユーザ端末は、前記ユーザ端末と前記セカンダリ基地局との間の接続を解放することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（第１実施形態に係る動作）
（１）動作シナリオ
第１実施形態では、マスタセルがマクロセルであり、セカンダリセルがマクロセルよりもカバレッジの狭いセル（小セル）であるシナリオを主として想定する。ここで、小セルは、例えばピコセル又はフェムトセル等であり、マクロセルのカバレッジと少なくとも一部が重複するカバレッジを有する。カバレッジの広いセルをマスタセルとして設定することにより、ＲＲＣコネクティッド状態のＵＥ１００の移動に対応する、すなわち、モビリティを強化することができる。

図８は、第１実施形態に係る動作環境を示す図である。

図８に示すように、ＵＥ１００は、マクロセル１のカバレッジ及び小セルのカバレッジの重複領域に位置しており、マクロセル１（ＭｅＮＢ２００Ｍ１）及び小セル（ＳｅＮＢ２００Ｓ）の組み合わせにより二重接続方式の通信を行っている。小セルは、２つのマクロセル１，２の境界付近に位置する。ＵＥ１００は、マクロセル２（ＭｅＮＢ２００Ｍ２）に向けて移動している。よって、ＭｅＮＢ２００Ｍ１（ソース）からＭｅＮＢ２００Ｍ２（ターゲット）へのＵＥ１００のハンドオーバが必要になる。以下において、ＭｅＮＢ２００Ｍ１をソースＭｅＮＢ（Ｓ−ＭｅＮＢ）と称し、ＭｅＮＢ２００Ｍ２をターゲットＭｅＮＢ（Ｔ−ＭｅＮＢ）と称する。

図９は、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを行う場合の基本シーケンスを示すシーケンス図である。図９の初期状態において、ＵＥ１００は、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓと二重接続方式の通信を行っている（Ｓ１０１）。

図９に示すように、基本シーケンスでは、Ｓ−ＭｅＮＢ２００Ｍ１がＵＥ１００から受信（Ｓ１０２）する測定報告などに基づいてＴ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを決定（Ｓ１０３）した後、次の３つの手順を行う。第１に、ＳｅＮＢ２００Ｓの解放手順（Ｓ１０４乃至Ｓ１１３）を行う。第２に、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバ手順（Ｓ１１４乃至Ｓ１２４）を行う。第３に、ＳｅＮＢ２００Ｓの追加手順（Ｓ１２５乃至Ｓ１３７）を行う。

詳細には、ステップＳ１０３において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを決定する。ステップＳ１０４において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００に対応するＳｅＮＢリソースの解放を決定する。ステップＳ１０５において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００に対応するＳｅＮＢリソースの解放要求（ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓに送信する。ステップＳ１０６において、ＳｅＮＢ２００Ｓは、解放要求に応じて、ＳｅＮＢリソースを解放する。ステップＳ１０７において、ＳｅＮＢ２００Ｓは、解放要求に対する応答（ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｓｐｏｎｓｅ）をＴ−ＭｅＮＢ２００Ｍ２に送信する。

第１のＵＰアーキテクチャの場合、ステップＳ１０８において、ＳｅＮＢ２００Ｓは、ベアラをＳｅＮＢ２００ＳからＳ−ＭｅＮＢ２００Ｍ１へ移すための切り替え要求（Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ）をＭＭＥ３００Ｃに送信する。ステップＳ１０９において、ＭＭＥ３００Ｃは、切り替え要求に対する肯定応答をＳｅＮＢ２００Ｓに送信する。ステップＳ１１０及びＳ１１１において、ＳｅＮＢ２００Ｓは、ＵＥ１００のデータの転送処理をＳ−ＭｅＮＢ２００Ｍ１に対して行う。

ステップＳ１１２において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓの解放のためのＲＲＣ再設定メッセージ（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）をＵＥ１００に送信する。ＵＥ１００は、ＳｅＮＢ２００Ｓに係る設定を解放する。ステップＳ１１３において、ＵＥ１００は、ＲＲＣ再設定の完了通知（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）をＳ−ＭｅＮＢ２００Ｍ１に送信する。

ステップＳ１１４において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求をＴ−ＭｅＮＢ２００Ｍ２に送信する。ステップＳ１１５において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求の承認判断を行う。ステップＳ１１６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ肯定応答（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）をＳ−ＭｅＮＢ２００Ｍ１に送信する。

ステップＳ１１７において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバのためのＲＲＣ再設定メッセージをＵＥ１００に送信する。ステップＳ１１８及びＳ１１９において、ＳｅＮＢ２００Ｓは、ＵＥ１００のデータの転送処理をＴ−ＭｅＮＢ２００Ｍ２に対して行う。

ステップＳ１２０において、ＵＥ１００は、ＲＲＣ再設定メッセージに基づいてＴ−ＭｅＮＢ２００Ｍ２へのランダムアクセスを行い、Ｔ−ＭｅＮＢ２００Ｍ２との同期をとる。ステップＳ１２１において、ＵＥ１００は、ＲＲＣ再設定の完了通知をＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ１２２において、Ｔ−ＭｅＮＢ２００Ｍ２は、データパスをＳ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へ移すための切り替え要求をＭＭＥ３００Ｃに送信する。ステップＳ１２３において、ＭＭＥ３００Ｃは、切り替え要求に対する肯定応答をＳｅＮＢ２００Ｓに送信する。ステップＳ１２４において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＵＥコンテキストの解放要求をＳ−ＭｅＮＢ２００Ｍ１に送信する。

ステップＳ１２５において、ＵＥ１００は、測定報告をＴ−ＭｅＮＢ２００Ｍ２に送信する。ステップＳ１２６において、Ｔ−ＭｅＮＢ２００Ｍ２は、測定報告などに基づいて、ＳｅＮＢリソースの追加を決定する。

ステップＳ１２７において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢリソースの割り当て要求（ＳｅＮＢ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓに送信する。ステップＳ１２８において、ＳｅＮＢ２００Ｓは、要求を承認する場合に、無線リソース設定を行う。ステップＳ１２９において、ＳｅＮＢ２００Ｓは、無線リソース設定の通知（ＳｅＮＢ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎ Ｃｏｍｍａｎｄ）をＴ−ＭｅＮＢ２００Ｍ２に送信する。

第１のＵＰアーキテクチャの場合、ステップＳ１３０及びＳ１３１において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＵＥ１００のデータの転送処理をＳｅＮＢ２００Ｓに対して行う。

ステップＳ１３２において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓの追加のためのＲＲＣ再設定メッセージをＵＥ１００に送信する。ＵＥ１００は、ＳｅＮＢ２００Ｓの無線リソース設定の適用を開始する。ステップＳ１３３において、ＵＥ１００は、ＲＲＣ再設定の完了通知（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）をＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ１３４において、ＵＥ１００は、ＲＲＣ再設定メッセージに基づいてＳｅＮＢ２００Ｓへのランダムアクセスを行い、ＳｅＮＢ２００Ｓとの同期をとる。ステップＳ１３５において、ＵＥ１００との同期を検出したＳｅＮＢ２００Ｓは、無線リソース設定の使用が可能になった旨の通知（ＳｅＮＢ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎ Ｃｏｍｐｌｅｔｅ）をＴ−ＭｅＮＢ２００Ｍ２に送信する。

第１のＵＰアーキテクチャの場合、ステップＳ１３６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ベアラをＳ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓへ移すための切り替え要求をＭＭＥ３００Ｃに送信する。ステップＳ１３７において、ＭＭＥ３００Ｃは、切り替え要求に対する肯定応答をＳｅＮＢ２００Ｓに送信する。

このように基本シーケンスでは、ＳｅＮＢ２００Ｓの解放手順、ハンドオーバ手順、ＳｅＮＢ２００Ｓの追加手順のそれぞれにおいて、ＵＥ１００に対するＲＲＣ再設定（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）が行われる。第１に、ＳｅＮＢ２００Ｓの解放手順では、ＳｅＮＢ２００Ｓの解放のためのＲＲＣ再設定（Ｓ１１２）が行われる。第２に、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバ手順では、ハンドオーバのためのＲＲＣ再設定（Ｓ１１７）が行われる。第３に、ＳｅＮＢ２００Ｓの追加手順では、ＳｅＮＢ２００Ｓの追加のためのＲＲＣ再設定（Ｓ１３２）が行われる。このように、二重接続方式におけるＭｅＮＢ２００Ｍ間のハンドオーバでは、合計で３回のＲＲＣ再設定が行われると考えられる。よって、無線区間のシグナリングが増大するとともに、ハンドオーバに係る処理時間の増大により、ＲＬＦ・ＨＯＦ（ｈａｎｄ ｏｖｅｒ ｆａｉｌｕｒｅ）が増える。

また、ＳｅＮＢ２００Ｓの解放手順、ハンドオーバ手順、ＳｅＮＢ２００Ｓの追加手順のそれぞれにおいて、コアネットワークとのシグナリングが発生し得る。第１に、ＳｅＮＢ２００Ｓの解放手順では、上述した第１のＵＰアーキテクチャの場合に、ベアラをＳｅＮＢ２００ＳからＳ−ＭｅＮＢ２００Ｍ１へ移すためのシグナリング（Ｓ１０８、Ｓ１０９）が発生する。第２に、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバ手順では、データパスをＳ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へ切り替えるためのシグナリング（Ｓ１２２、Ｓ１２３）が発生する。第３に、ＳｅＮＢ２００Ｓの追加手順では、第１のＵＰアーキテクチャの場合に、ベアラをＳ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓへ移すためのシグナリング（Ｓ１３６、Ｓ１３７）が発生する。このように、二重接続方式におけるＭｅＮＢ２００Ｍ間のハンドオーバでは、最大で３回のコアネットワークとのシグナリングが発生すると考えられる。よって、ネットワーク区間のシグナリングの増大が問題となる。

第１実施形態では、二重接続方式におけるＭｅＮＢ２００Ｍ間のハンドオーバのシーケンスを改良することにより、上述したシグナリングの増大を抑制可能とする。以下において、改良されたハンドオーバシーケンスについて説明する。

（２）動作パターン１
図１０は、第１実施形態に係る動作パターン１を示すシーケンス図である。以下においては、基本シーケンスとの相違点を主として説明する。図１０の初期状態において、ＵＥ１００は、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓと二重接続方式の通信を行っている（Ｓ２０１）。

図１０に示すように、ステップＳ２０３において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００から受信（Ｓ２０２）する測定報告などに基づいて、Ｔ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを決定する。動作パターン１では、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバの判断時に、ＳｅＮＢ２００ＳとＵＥ１００との間の接続を解放するか否かを判断してもよい。

ステップＳ２０４において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求をＴ−ＭｅＮＢ２００Ｍ２に送信する。ステップＳ２０５において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求の承認判断を行う。ステップＳ２０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ肯定応答（Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ）をＳ−ＭｅＮＢ２００Ｍ１に送信する。Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ設定がされていないＲＲＣコンテナをハンドオーバ肯定応答に含める。Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２からのハンドオーバ肯定応答の受信時に、ＳｅＮＢ２００ＳとＵＥ１００との間の接続を解放するか否かを判断してもよい。

次に、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓは、ＳｅＮＢ２００Ｓの解放手順（ステップＳ２０７乃至Ｓ２１２）を行う。当該解放手順は、基本シーケンスと同様である。

ステップＳ２１３において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバを指示するためのハンドオーバ指令を含むＲＲＣ再設定メッセージをＵＥ１００に送信する。

動作パターン１では、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００ＳとＵＥ１００との間の接続の解放を設定する情報（ＳｅＮＢ ｒｅｍｏｖｅ）をハンドオーバ指令と共にＵＥ１００に送信する。ＳｅＮＢ ｒｅｍｏｖｅは、ＳｅＮＢ２００Ｓの設定に関するセカンダリ基地局情報に相当する。Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ指令とＳｅＮＢ ｒｅｍｏｖｅとを含む１つのＲＲＣ再設定メッセージをＵＥ１００に送信することが好ましい。これにより、ＳｅＮＢ２００Ｓの解放だけのためのＲＲＣ再設定メッセージが不要となるため、基本シーケンスに比べてＲＲＣ再設定を１回分削減することができる。ハンドオーバ指令と共にＳｅＮＢ情報を受信したＵＥ１００は、ＳｅＮＢ ｒｅｍｏｖｅに応じてＳｅＮＢ２００Ｓとの接続を解放しつつ、ハンドオーバ指令に応じてＴ−ＭｅＮＢ２００Ｍ２との同期をとり（Ｓ２１６）、新たなＲＲＣ接続を確立（Ｓ２１７）する。

また、動作パターン１では、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１とＳ−ＧＷ３００Ｕとの間のデータパス、及びＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のデータパス（ベアラ）を一括してＴ−ＭｅＮＢ２００Ｍ２に切り替えるためのパス切り替え要求をＭＭＥ３００Ｃに送信（Ｓ２１８）する。なお、上述したハンドオーバ要求（Ｓ２０４）又は他のメッセージに、Ｓ−ＭｅＮＢ２００Ｍ１のベアラの情報が含まれていることが好ましい。これにより、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求に含まれるベアラ情報により、切り替えるベアラを特定できる。

ＭＭＥ３００Ｃは、パス切り替え要求に応じて、Ｓ−ＭｅＮＢ２００Ｍ１とＳ−ＧＷ３００Ｕとの間のデータパス、及びＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のデータパス（ベアラ）を一括してＴ−ＭｅＮＢ２００Ｍ２に切り替えるためのパス切り替えを行う。これにより、第１のＵＰアーキテクチャの場合に、ベアラをＳｅＮＢ２００ＳからＳ−ＭｅＮＢ２００Ｍ１へ移すためのシグナリングが不要になる。

ＳｅＮＢ２００Ｓの追加手順（ステップＳ２１１乃至Ｓ２３３）については基本シーケンスと同様である。

（３）動作パターン２
図１１は、第１実施形態に係る動作パターン２を示すシーケンス図である。図１１の初期状態において、ＵＥ１００は、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓと二重接続方式の通信を行っている（Ｓ３０１）。

図１１に示すように、ステップＳ３０３において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００から受信（Ｓ３０２）する測定報告などに基づいて、Ｔ−ＭｅＮＢ２００Ｍ２へのＵＥ１００のハンドオーバを決定する。また、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバの判断時に、ＳｅＮＢ２００ＳとＵＥ１００との間の接続を解放するか否かを判断する。動作パターン２では、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓを維持したハンドオーバ（ＤＣ ＨＯ： Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ ＨａｎｄＯｖｅｒ）を決定可能である。ＳｅＮＢ２００Ｓを維持したハンドオーバを決定した後、次の動作を行う。

ステップＳ３０４において、Ｓ−ＭｅＮＢ２００Ｍ１は、ハンドオーバ要求をＴ−ＭｅＮＢ２００Ｍ２に送信する。その際、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００ＳとＵＥ１００との間の接続を維持したままハンドオーバを行うことを示す情報（ＳｅＮＢ Ｉｎｆｏｒｍａｔｉｏｎ）をハンドオーバ要求に含める。ＳｅＮＢ Ｉｎｆｏｒｍａｔｉｏｎは、ＳｅＮＢ２００Ｓに関する情報（ｅＮＢ ＩＤ、セルＩＤなど）を含む。また、ＳｅＮＢ Ｉｎｆｏｒｍａｔｉｏｎには、ＳｅＮＢ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎに含まれる要素（ｅ．ｇ． ＵＥ ｃａｐａｂｉｌｉｔｉｅｓ ａｎｄ ｔｈｅ ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｆｉｇｕｒａｔｉｏｎ ｏｆ ｔｈｅ ＵＥ）を入れてもよい。さらに、Ｓ−ＭｅＮＢ２００Ｍ１は、本シーケンス前のＳｅＮＢ Ａｄｄｉｔｉｏｎ時にＳｅＮＢ２００Ｓから受け取ったＲＲＣコンテナを保持しておき、当該ＲＲＣコンテナをハンドオーバ要求に含めてもよい。当該ＲＲＣコンテナは、例えば、後述するステップＳ３１１などで利用できる。

ステップＳ３０５において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ要求の承認の判断を行う。ここで、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ Ａｄｄｉｔｉｏｎに係る情報がハンドオーバ要求に含まれている場合（つまり、ＤＣ ＨＯを示す）は、当該ＳｅＮＢ Ａｄｄｉｔｉｏｎの受け入れも含めて判断してもよい。

承認（受け入れ）可の場合、ステップＳ３０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、ハンドオーバ肯定応答をＳ−ＭｅＮＢ２００Ｍ１に送信する。なお、ステップＳ３０６におけるハンドオーバ肯定応答は、通常のハンドオーバ肯定応答でもよく、後述するステップＳ３１２で改めて送信される場合には省略してもよい。或いは、ステップＳ３０６におけるハンドオーバ肯定応答は、通常のハンドオーバ肯定応答を簡略化したもの（例えば、暫定的にＨＯのみ受け入れたというフラグ）であってもよい。或いは、「リソースが足りないので、当該ＨＯにはＳｅＮＢのリソース追加を要する」という意味の情報（後述するステップＳ３０７で利用可）が含まれていてもよい。

ステップＳ３０７において、ハンドオーバ肯定応答を受信したＳ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢリソースの維持を決定する。ステップＳ３０８において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＭｅＮＢを変更・交替するための要求（ＳｅＮＢ Ｒｅｌｅａｓｅ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）をＳｅＮＢ２００Ｓに送信する。Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢがＴ−ＭｅＮＢ２００Ｍ２に切り替えることを示す情報（ＭｅＮＢ ｃｈａｎｇｅ）を当該要求に含める。ＭｅＮＢ ｃｈａｎｇｅは、Ｔ−ＭｅＮＢ２００Ｍ２に関する情報（ｅＮＢ ＩＤ、セルＩＤなど）を含む。なお、ステップＳ３０４でハンドオーバ要求にＳｅＮＢ関連設定情報が入っていた場合（つまり、既にＴ−ＭｅＮＢがＳｅＮＢを設定可能な状態）、ステップＳ３０８は単なるＲｅｌｅａｓｅで良い（但し、ＭｅＮＢ ｃｈａｎｇｅに係る情報は伝達される）。

ステップＳ３０９において、ＳｅＮＢ２００Ｓは、Ｓ−ＭｅＮＢ２００Ｍ１からの要求を承認する場合に、無線リソース解放・変更を行う。ステップＳ３１０において、ＳｅＮＢ２００Ｓは、解放・変更要求に対する応答（ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｓｐｏｎｓｅ）をＳ−ＭｅＮＢ２００Ｍ１に送信する。

ステップＳ３１１において、ＳｅＮＢ２００Ｓは、Ｓ−ＭｅＮＢ２００Ｍ１から受信したＭｅＮＢ ｃｈａｎｇｅに基づいて、無線リソース設定の通知（ＳｅＮＢ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ／Ｃｏｍｍａｎｄ）をＴ−ＭｅＮＢ２００Ｍ２に送信する。なお、ステップＳ３０４でハンドオーバ要求にＳｅＮＢ関連設定情報が入っていた場合（つまり、既にＴ−ＭｅＮＢがＳｅＮＢを設定可能な状態）、ステップＳ３１１は逆方向の通知でもよいし、省略してもよい。

ステップＳ３１２において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢの無線リソース（ＳｅＮＢリソース）設定を含んだハンドオーバ肯定応答をＳ−ＭｅＮＢ２００Ｍ１に送信する。或いは、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢリソース設定を他のメッセージに含めてＳ−ＭｅＮＢ２００Ｍ１に送信してもよい。

ステップＳ３１３において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２からのＳｅＮＢリソース設定とハンドオーバ指令とを含むＲＲＣ再設定メッセージをＵＥ１００に送信する。ＳｅＮＢリソース設定は、ＳｅＮＢ２００ＳとＵＥ１００との間の接続の維持を設定する情報に相当する。

ＵＥ１００は、当該ＳｅＮＢリソース設定の適用を開始する。ここで、ＵＥ１００は、ＳｅＮＢ２００Ｓと同期がとれているため、ＳｅＮＢ２００Ｓに対するランダムアクセス（同期）を省略可能である。また、ランダムアクセス（同期）の省略を示す情報がＲＲＣ再設定メッセージに含まれていてもよい。

ステップＳ３１４及びＳ３１５において、ＳｅＮＢ２００Ｓは、ＵＥ１００のデータの転送処理をＴ−ＭｅＮＢ２００Ｍ２に対して行う。

ステップＳ３１６において、ＵＥ１００は、ＲＲＣ再設定メッセージに基づいてＴ−ＭｅＮＢ２００Ｍ２へのランダムアクセスを行い、Ｔ−ＭｅＮＢ２００Ｍ２との同期をとる。ステップＳ３１７において、ＵＥ１００は、ＲＲＣ再設定の完了通知をＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ３１８において、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１とＳ−ＧＷ３００Ｕとの間のデータパスをＴ−ＭｅＮＢ２００Ｍ２に切り替えるためのパス切り替え要求をＭＭＥ３００Ｃに送信する。動作パターン２では、ＳｅＮＢ２００Ｓは維持されるため、第１のＵＰアーキテクチャの場合でも、ＳｅＮＢ２００Ｓのベアラ切り替えは発生しない。

このように、動作パターン２では、ＳｅＮＢ２００Ｓを維持したままＭｅＮＢ２００Ｍ間でハンドオーバを行うことにより、基本シーケンスに比べてシグナリングを大幅に削減することができる。

なお、動作パターン２では、Ｔ−ＭｅＮＢ２００Ｍ２からＳ−ＭｅＮＢ２００Ｍ１へのハンドオーバ肯定応答の送信が２回（Ｓ３０６、Ｓ３１２）行われているが、１回（Ｓ３１２）のみとしてもよい。

［第２実施形態］
以下において、第２実施形態について、第１実施形態との相違点を主として説明する。

（１）動作シナリオ
図１２は、第２実施形態に係る動作シナリオを示す図である。

図１２に示すように、第２実施形態に係る動作シナリオでは、第１実施形態に係る動作シナリオにおいてＥＰＣ２０の構成も考慮する。図１２の例では、ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓは同一のＳ−ＧＷ３００Ｕ１に収容されており、ＭｅＮＢ２００Ｍ１は別のＳ−ＧＷ３００Ｕ２に収容されている。すなわち、ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓのそれぞれは、Ｓ−ＧＷ３００Ｕ１との間にＳ１インターフェイスを持つ。ＭｅＮＢ２００Ｍ２は、Ｓ−ＧＷ３００Ｕ２との間にＳ１インターフェイスを持つ。

このようなシナリオでは、ＳｅＮＢ２００Ｓ及びＭｅＮＢ２００Ｍ２には、第１のＵＰアーキテクチャを適用することができないが、第２のＵＰアーキテクチャを適用することはできる。また、このようなシナリオでは、第１のＵＰアーキテクチャを前提とする場合に、例えば第１実施形態に係る動作パターン２のようなＳｅＮＢ２００Ｓを維持したままＭｅＮＢ２００Ｍ間のハンドオーバを行う高度なハンドオーバ制御を行うことはできない。

（２）第２実施形態に係る動作
第２実施形態では、第１実施形態に係るハンドオーバ制御において、ハンドオーバ判断（ＨＯ ｄｅｃｉｓｉｏｎ）又はハンドオーバ承認制御（Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ）などを行うノードは、ＭｅＮＢ２００Ｍを収容するＳ−ＧＷ３００ＵとＳｅＮＢ２００Ｓを収容するＳ−ＧＷ３００Ｕとが一致するか否かに基づいて、二重接続方式に係る判断を行う。当該ノードは、ＭｅＮＢ２００Ｍ又はＳｅＮＢ２００Ｓなどの通信制御装置である。例えば、当該ノードは、ＭｅＮＢ２００Ｍを収容するＳ−ＧＷ３００ＵとＳｅＮＢ２００Ｓを収容するＳ−ＧＷ３００Ｕとが一致しない場合に、第１のＵＰアーキテクチャを適用しないと判断する。

また、図１２に示すように、第１実施形態を例に挙げると、第２のＵＰアーキテクチャが可能であるか否かに基づいて、ＳｅＮＢ２００ＳとＵＥ１００との間の接続を解放してハンドオーバ（基本シーケンス）を行うか、又はＳｅＮＢ２００ＳとＵＥ１００との間の接続を維持したままハンドオーバ（高度なハンドオーバ）を行うかを判断する。或いは、当該ノードは、ＭｅＮＢ２００Ｍ２を収容するＳ−ＧＷ３００ＵとＳｅＮＢ２００Ｓを収容するＳ−ＧＷ３００Ｕとが一致するか否かに基づいて、ＳｅＮＢ２００ＳとＵＥ１００との間の接続を解放してハンドオーバ（基本シーケンス）を行うか、又はＳｅＮＢ２００ＳとＵＥ１００との間の接続を維持したままハンドオーバ（高度なハンドオーバ）を行うかを判断する。

このような判断をＭｅＮＢ２００Ｍ又はＳｅＮＢ２００Ｓが行うためには、各ｅＮＢ２００が他のｅＮＢ２００を収容するＳ−ＧＷ３００Ｕを把握している必要がある。

よって、第２実施形態では、ＭｅＮＢ２００Ｍ又はＳｅＮＢ２００Ｓは、自ｅＮＢを収容するＳ−ＧＷ３００Ｕの識別情報を近隣のｅＮＢに送信する。ここで、自ｅＮＢを収容するＳ−ＧＷ３００Ｕとは、自ｅＮＢとの間にＳ１インターフェイスを持つＳ−ＧＷ３００Ｕである。Ｓ−ＧＷ３００Ｕの識別情報とは、例えばＳ−ＴＥＩＤ（Ｓ−ＧＷ ＩＤ）又はＳ−ＧＷ ＩＰ ａｄｄｒｅｓｓである。

図１３は、Ｓ−ＧＷ３００Ｕの識別情報をｅＮＢ２００間で送受信するための第１の動作を示す図である。図１３に示すように、ｅＮＢ２００ａは、ｅＮＢ２００ａを収容するＳ−ＧＷ３００Ｕの識別情報をｅＮＢ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージに含めてｅＮＢ２００ｂに送信する。ｅＮＢ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージは、ｅＮＢ２００の設定更新を通知するためのメッセージである。なお、ｅＮＢ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージに代えて、Ｘ２ Ｓｅｔｕｐメッセージを使用してもよい。Ｘ２ Ｓｅｔｕｐメッセージは、Ｘ２インターフェイスを確立するためのメッセージである。例えば、表１に示すように、ｅＮＢ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｕｐｄａｔｅメッセージの「Ｓｅｒｖｅｄ Ｃｅｌｌ Ｉｎｆｏｒｍａｔｉｏｎ」にＳ−ＧＷ３００Ｕの識別情報含める。

図１４は、Ｓ−ＧＷ３００Ｕの識別情報をｅＮＢ２００間で送受信するための第２の動作を示す図である。図１４及び表２に示すように、ｅＮＢ２００ａは、ｅＮＢ２００ａを収容するＳ−ＧＷ３００Ｕの識別情報を、上述したＳｅＮＢ Ａｄｄｉｔｉｏｎ／Ｍｏｄｉｆｉｃａｔｉｏｎメッセージに含めてｅＮＢ２００ｂに送信する。

図１５は、第２実施形態に係る動作を示すフロー図である。

図１５に示すように、ステップＳ４０１において、ノード（ＭｅＮＢ２００Ｍ又はＳｅＮＢ２００Ｓ）は、ＵＥ１００が二重接続方式で通信しているか否かを判断する。通常の通信を行っている場合（ステップＳ４０１；ＮＯ）、ステップＳ４０５において、通常のハンドオーバを行うと判断する。

二重接続方式で通信している場合（ステップＳ４０１；ＹＥＳ）、ステップＳ４０２において、当該ノードは、ＵＥ１００が第２のＵＰアーキテクチャ（ＵＰアーキテクチャ「３Ｃ」）で通信を行っているか否かを判断する。第２のＵＰアーキテクチャで通信を行っている場合（ステップＳ４０２；ＹＥＳ）、ステップＳ４０３において、当該ノードは、第１実施形態に係る高度なハンドオーバを行うと判断する。

これに対し、ＵＥ１００が第２のＵＰアーキテクチャで通信を行っていない、すなわち、ＵＥ１００が第１のＵＰアーキテクチャ（ＵＰアーキテクチャ「１Ａ」）で通信を行っている場合（ステップＳ４０２；ＮＯ）、ステップＳ４０４において、当該ノードは、上述したようなＳ−ＧＷ３００Ｕの一致／不一致を判断する。Ｓ−ＧＷ３００Ｕが一致すると判断した場合（ステップＳ４０４；ＹＥＳ）、ステップＳ４０３において、当該ノードは、第１実施形態に係る高度なハンドオーバを行うと判断する。一方、Ｓ−ＧＷ３００Ｕが一致しないと判断した場合（ステップＳ４０４；ＮＯ）、ステップＳ４０５において、当該ノードは、通常のハンドオーバを行うと判断する。

［第３実施形態］
第３実施形態乃至第７実施形態は、第１実施形態の動作パターン２を一部変更した実施形態である。

以下において、第３実施形態について、第１実施形態及び第２実施形態との相違点を主として説明する。第３実施形態乃至第７実施形態における基本的なハンドオーバ手順は、第１実施形態の動作パターン２と同様である。

具体的には、第３実施形態に係る通信制御方法は、ＵＥ１００とＲＲＣ接続を確立するＭｅＮＢ２００Ｍ（マスタ基地局）と、ＵＥ１００に追加的な無線リソースを提供するＳｅＮＢ２００Ｓ（セカンダリ基地局）と、を用いる二重接続方式の通信をサポートするＬＴＥシステムにおける方法である。通信制御方法は、ＵＥ１００とＳｅＮＢ２００Ｓとの間の接続を解放することなく、Ｓ−ＭｅＮＢ２００Ｍ１（ソースマスタ基地局）からＴ−ＭｅＮＢ２００Ｍ２（ターゲットマスタ基地局）に対してＵＥ１００のハンドオーバを行うＭｅＮＢ間ハンドオーバ手順を備える。

図１６は、第３実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。図１６の初期状態において、ＵＥ１００は、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓと二重接続方式の通信を行っている。なお、図１６の破線で示す動作については、必須の動作ではないことを示している。

図１６に示すように、ステップＳ５０１において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００のハンドオーバを要求するハンドオーバ要求（「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」）メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージは、ＭｅＮＢ間ハンドオーバ手順を示す情報（「ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ」）を含む。「ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ」は、ＭｅＮＢ間ハンドオーバであることを示し、ＳｅＮＢ２００Ｓに関連する動作の要求をＴ−ＭｅＮＢ２００Ｍ２に示す。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージは、「Ｓ−ＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ」を含んでもよい。「Ｓ−ＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ」は、Ｓ−ＭｅＮＢ２００Ｍ１のＸ２ＡＰ ＩＤである。「Ｓ−ＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ」は、「ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ」の役割を暗示的に担ってもよい。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージは、Ｓ−ＭｅＮＢ２００Ｍ１がＳｅＮＢ２００Ｓと対応付けて保持していた設定情報（ＳＣＧ設定情報）を含む。具体的には、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージは、「ＳＣＧ−Ｃｏｎｆｉｇｉｎｆｏ」及び「ＳＣＧ−Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を含む。「ＳＣＧ−Ｃｏｎｆｉｇｉｎｆｏ」は、ＭｅＮＢの現状の設定に関する設定情報（ＭｅＮＢ関連設定情報）である。ここでは、「ＳＣＧ−Ｃｏｎｆｉｇｉｎｆｏ」は、Ｓ−ＭｅＮＢ２００Ｍ１についての設定情報である。「ＳＣＧ−Ｃｏｎｆｉｇｕｒａｔｉｏｎ」は、ＳｅＮＢの現状の設定に関する設定情報（ＳｅＮＢ関連設定情報）である。

ステップＳ５０２において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、ＳｅＮＢ２００Ｓにおける設定の修正を要求する修正要求（「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」）メッセージをＳｅＮＢ２００Ｓに送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージは、「ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ」、「Ｓ−ＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ」を含む。また、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージは、「ＳＣＧ−Ｃｏｎｆｉｇｉｎｆｏ」を含む。ここでは、「ＳＣＧ−Ｃｏｎｆｉｇｉｎｆｏ」は、Ｔ−ＭｅＮＢ２００Ｍ２についての設定情報であり、ＳｅＮＢ２００Ｓが「ＳＣＧ−Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を決定するために使用される。

ステップＳ５０３において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージに含まれる「Ｓ−ＭｅＮＢ ＵＥ Ｘ２ＡＰ ＩＤ」とＴ−ＭｅＮＢ２００Ｍ２側の「ＵＥ Ｘ２ＡＰ ＩＤ」とを照合し、対応付ける。

ステップＳ５０４において、ＳｅＮＢ２００Ｓは、ＳｅＮＢ解放要請（「ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｑｕｉｒｅｄ」）メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。スプリットベアラ・オプションの場合、ステップＳ５０５において、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓは、スプリットベアラのＧＴＰ−Ｕトンネルを破棄する。ステップＳ５０６において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ解放通知（「ＳｅＮＢ Ｒｅｌｅａｓｅ Ｃｏｎｆｉｒｍ」）メッセージをＳｅＮＢ２００Ｓに送信する。

ステップＳ５０７において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージに対する修正要求承諾（「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」）メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」メッセージは、ＳｅＮＢ２００Ｓにおける設定情報（ＳＣＧ設定情報）を含む。スプリットベアラ・オプションの場合、ステップＳ５０８において、ＳｅＮＢ２００Ｓ及びＴ−ＭｅＮＢ２００Ｍ２は、スプリットベアラのＧＴＰ−Ｕトンネルを確立する。

ステップＳ５０８において、Ｔ−ＭｅＮＢ２００Ｍ２は、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」メッセージの受信に応じて、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージに対するハンドオーバ肯定応答（「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」）をＳ−ＭｅＮＢ２００Ｍ１に送信する。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージは、後述するＲＲＣ再設定（ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）をＳ−ＭｅＮＢ２００Ｍ１が行うために必要な情報（ＳＣＧの設定情報及びＭＣＧの設定情報）を含む。

ステップＳ５１０において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージの受信に応じて、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージをＵＥ１００に送信する。「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージは、Ｔ−ＭｅＮＢ２００Ｍ２へのハンドオーバを指示するハンドオーバ指令に相当し、ＳＣＧの設定情報及びＭＣＧの設定情報を含む。ここで、ＳｅＮＢ２００Ｓが解放されないことに留意すべきである。

ステップＳ５１１において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２とのＲＲＣ接続確立処理を行う。このようにして、ＵＥ１００は、ＳｅＮＢ２００Ｓを維持しつつ、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２へのハンドオーバを行う。

次に、Ｔ−ＭｅＮＢ２００Ｍ２は、ＭＭＥ３００Ｃに対してパス切り替え要求を行う。ここでは、ＳＣＧベアラ・オプションの場合に、ＳｅＮＢ２００ＳとＳ−ＧＷ３００Ｕとの間のトンネリングについて、Ｓ−ＧＷ３００Ｕ側のエンドポイントＩＤ（すなわち、ＵＬ−ＴＥ ＩＤ）を維持したままパス切り替えを行うための第１の方法（ｏｐｔｉｏｎ １）及び第２の方法（ｏｐｔｉｏｎ ２）について説明する。

第１の方法では、ステップＳ５１２において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」をＭＭＥ３００Ｃに送信する。「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」は、Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙ中のハンドオーバである旨を示す情報（インディケータ）、又は、前記エンドポイントＩＤを維持するＥ−ＲＡＢ ＩＤ、及び／又は維持しなくてもよいＥ−ＲＡＢ ＩＤ等を含む。ＭＭＥ３００Ｃは、当該Ｅ−ＲＡＢ ＩＤについてパス更新が行われるまでデータ転送を行わないようＳ−ＧＷ３００Ｕを制御してもよい。ステップＳ５１３において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｅ−ＲＡＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ｉｎｄｉｃａｔｉｏｎ」をＭＭＥ３００Ｃに送信する。ステップＳ５１４において、ＭＭＥ３００Ｃは、前記Ｅ−ＲＡＢ ＩＤと合致する事を確認し、「Ｅ−ＲＡＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍａｔｉｏｎ」をＳ−ＭｅＮＢ２００Ｍ１に送信する。ステップＳ５１５において、ＭＭＥ３００Ｃは、「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ ＡＣＫ」をＴ−ＭｅＮＢ２００Ｍ２に送信する。

第２の方法では、ステップＳ５１６において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」をＭＭＥ３００Ｃに送信する。「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」は、ＵＬ−ＴＥＩＤが変更されたくないＥ−ＲＡＢ ＩＤのリストを含む。ＭＭＥ３００Ｃは、当該リスト中のＥ−ＲＡＢ ＩＤに対応するＵＬ−ＴＥＩＤを維持する。ステップＳ５１７において、ＭＭＥ３００Ｃは、「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ ＡＣＫ」をＴ−ＭｅＮＢ２００Ｍ２に送信する。

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

本シーケンスにおいて、ＳｅＮＢ２００Ｓにおける設定に失敗した場合（Ｓ５０７でＮＡＣＫの場合）を想定する。この場合、ＳｅＮＢ２００Ｓを維持しない従来のハンドオーバ手順が可能である場合、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｔ−ＭｅＮＢ２００Ｍ２の設定情報（ＲＲＣコンテナ）を含む「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。但し、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージに、ＭｅＮＢ間ハンドオーバ手順の失敗を示す情報（ＤＣ ｕｎｓｕｃｃｅｓｓｆｕｌ ｉｎｉｔｉａｔｅｄ）を含める。これにより、ＳｅＮＢ２００Ｓにおける設定に失敗した場合でも、従来のハンドオーバ手順を行うことができる。或いは、Ｓ−ＭｅＮＢ２００Ｍ１は、ＳｅＮＢ２００Ｓを解放する手順（ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｑｕｅｓｔ）を実施してもよい。

また、ＭｅＮＢ間ハンドオーバ手順の失敗を示す情報は、失敗の理由（Ｃａｕｓｅ）を含んでもよい。失敗の理由とは、例えば「Ｘ２ ｃｏｎｎｅｃｔｉｏｎ ｕｎａｖａｉｌａｂｌｅ」、「Ｓ−ＧＷ ｒｅｌｏｃａｔｉｏｎ」等である。このような情報は、ＳＯＮ（Ｓｅｌｆ Ｏｒｇａｎｉｚｉｎｇ Ｎｅｔｗｏｒｋ）の用途に使用することができる。

或いは、ＳｅＮＢ２００Ｓにおける設定に失敗した場合で、例えば「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージが負荷分散目的のものである場合、ハンドオーバ否定応答をＳ−ＭｅＮＢ２００Ｍ１に送信してもよい。

［第３実施形態の変更例１］
ＳＣＧベアラ・オプション及びスプリットベアラ・オプションのそれぞれについてＭｅＮＢ間ハンドオーバ手順を説明する。本変更例では、各メッセージのＩＥの具体例についても説明する。

（１）ＳＣＧベアラ・オプションの場合
図１７は、第３実施形態の変更例１に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。先ず、ＳＣＧベアラ・オプションの場合の動作を説明する。

ステップＳ５３１において、ＵＥ１００は、Ｓ−ＭｅＮＢ２００Ｍ１に「Ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔ」を送信する。

ステップＳ５３２において、Ｓ−ＭｅＮＢ２００Ｍ１は、Ｔ−ＭｅＮＢ２００Ｍ２に「Ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ」メッセージを送信する。「Ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ」メッセージは以下のＩＥを含む。但し、必ずしも全てのＩＥを要しない。

・「Ｉｎｔｅｒ ＭｅＮＢ ＨＯ ＩＤ」 ＭｅＮＢ間ハンドオーバを示す。

・「ＳＣＧ−Ｃｏｎｆｉｇｉｎｆｏ（Ｓｏｕｒｃｅ ＭＣＧ ｃｏｎｆｉｇ）」 Ｓ−ＭｅＮＢ２００Ｍ１のＭＣＧ ｃｏｎｆｉｇである。

・「Ｘ２ＡＰ ｅｎｄｐｏｉｎｔ ｏｆ ＳｅＮＢ ｆｏｒ Ｘ２ Ｉｎｔｅｒｆａｃｅ」 Ｘ２インターフェイスがＳｅＮＢ２００ＳとＴ−ＭｅＮＢ２００Ｍ２との間にない場合、Ｘ２の確立に用いる。或いは、Ｇｌｏｂａｌ ｅＮＢ ＩＤで確立してもよい。

・「ＤＲＢ−ｉｎｆｏ」 ＤＲＢ ＩＤ, ＤＲＢ ｔｙｐｅ（Ｓｐｌｉｔ／ＳＣＧ）を含む。ＳＣＧであるか、スプリットベアラであるかの判定に用いる。

・「ｓｅｃｕｒｉｔｙ ｐａｒａｍｅｔｅｒ １」 ＫｅＮＢ＊やＴｏｋｅｎ等のセキュリティパラメータを含む。KeNB*s, tokens, NCC, UE EPS security capabilities, security algorithms 等の情報を含む。これらの情報はＵＥ１００のHO Failure時のReestablishment やTokenの計算に使用されるパラメータである。KeNB*はTarget cellのtarget cell’s physical cell ID and frequency EARFCN-DLから生成される。

・「Ｘ２ ＤＬ／ＵＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ ＴＥＩＤ ｏｆ ＳｅＮＢ」 ベアラ解放時等に必要になるデータフォワーディングに利用するベアラのＳｅＮＢ２００Ｓ側のエンドポイント

ステップＳ５３３において、Ｔ−ＭｅＮＢ２００Ｍ２は、ＳｅＮＢ２００Ｓに「ＭｅＮＢ Ｃｈａｎｇｅ（修正要求）」を送信する。「ＭｅＮＢ Ｃｈａｎｇｅ」は以下のＩＥを含む。但し、必ずしも全てのＩＥを要しない。

・「Ｉｎｔｅｒ ＭｅＮＢ ＨＯ ＩＤ」

・「Ｓｅｃｕｒｉｔｙ ｐａｒａｍｅｔｅｒ ２」 Ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔに含まれていた「ｓｅｃｕｒｉｔｙ ｐａｒａｍｅｔｅｒ １」とは異なるセキュリティパラメータ（Ｓ−ＫｅＮＢ、ＳＣＧカウンタ、ＭＣＧセキュリティアルゴリズム等）である。

・「ＳｅＮＢ ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ」 ＳｅＮＢ２００Ｓ側で保証すべきＵＥ１００のビットレートである。この値は、Ｔ−ＭｅＮＢ２００Ｍ２が、「Ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ」メッセージ内に含まれる「ＵＥ Ａｇｇｒｅｇａｔｅ Ｍａｘｉｍｕｍ Ｂｉｔ Ｒａｔｅ」から算出する。

・「Ｓｏｕｒｃｅ ＭｅＮＢ ＵＥ X２ＡＰ ＩＤ」 どのＵＥ１００についてのハンドオーバかを示す。

・「ＤＲＢ Ｉｎｆｏ」 ＤＲＢ ＩＤ，ＤＲＢ typeを示す。この情報を基に、どのベアラの設定を維持するかを決定できる。

・「Ｘ２ ＤＬ／ＵＬ Ｆｏｒｗａｒｄｉｎｇ ＧＴＰ ＴＥＩＤ ｏｆ ＭｅＮＢ」 ベアラ解放時等に必要になるデータフォワーディングに利用するベアラのＳ−ＭｅＮＢ２００Ｍ１側のエンドポイントである。

・「ＭＣＧ Ｃｏｎｆｉｇｕｒａｔｉｏｎ（ＳＣＧ Ｃｏｎｆｉｇｉｎｆｏ ｉｎ ＭｅＮＢ ｔｏ ＳｅＮＢ ｃｏｎｔａｉｎｅｒ）」 Ｔ−ＭｅＮＢ２００Ｍ２のMCGの設定情報。この値は、「ＳｅＮＢ Ａｄｄｉｔｉｏｎ」メッセージの「ＭｅＮＢ ｔｏ ＳｅＮＢ ｃｏｎｔａｉｎｅｒ」の中身と同じ。

ステップＳ５３４において、ＳｅＮＢ２００Ｓは、Ｔ−ＭｅＮＢ２００Ｍ２に「ＭｅＮＢ Ｃｈａｎｇｅ ＡＣＫ」を送信する。「ＭｅＮＢ Ｃｈａｎｇｅ ＡＣＫ」は以下のＩＥを含む。但し、必ずしも全てのＩＥを要しない。

・「ＳＣＧ Ｃｏｎｆｉｇ」 ＳｅＮＢ２００ＳのＳＣＧの設定情報。

・「Ｓｅｌｅｃｔｅｄ ａｌｇｏｒｉｔｈｍ」 ＳｅＮＢ２００Ｓが選定したセキュリティ用のアルゴリズム。

ステップＳ５３５において、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１に「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージを送信する。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージは以下のＩＥを含む。但し、必ずしも全てのＩＥを要しない。

・「ＳＣＧ−Ｃｏｎｆｉｇ， ＳＣＧ−ＣｏｎｆｉｇＩｎｆｏ （ＭＣＧ Ｃｏｎｆｉｇ）」 Ｔ−ＭｅＮＢ２００Ｍ２とＳｅＮＢ２００ＳのＭＣＧ／ＳＣＧの設定情報を含む。

・「ｓｅｃｕｒｉｔｙ ｐａｒａｍｅｔｅｒ３」 SCG Counter, selected algorithmを含む。SCG counterはＴ−ＭｅＮＢ２００Ｍ２で使用する値である。Selected algorithmは、ステップＳ５３４でＳｅＮＢ２００Ｓが決定したものである。

ＳＣＧベアラ・オプションの場合、ステップＳ５３６乃至Ｓ５３８は省略される。

ステップＳ５３９において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＵＥ１００に「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージを送信する。「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージは、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージに含まれていたＩＥを含む。

ステップＳ５４０において、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２に対してデータフォワーディングを行う。

ステップＳ５４１において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２との同期を確立する。

ステップＳ５４２において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２とのＲＲＣ接続確立処理を行う。

ステップＳ５４３において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」をＭＭＥ３００Ｃに送信する。「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」は、Ｔ−ＭｅＮＢ２００Ｍ２のＭＣＧベアラ用のＤＬ ＴＥＩＤを含む。

図１８は、ＳＣＧベアラ・オプションの場合のＴＥＩＤについて説明するための図である。

図１８Ａに示すように、ＭｅＮＢ間ハンドオーバ手順において、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２に下りリンクのＭＣＧベアラが切り替わるため、図１８Ａの「１」で示すＴ−ＭｅＮＢ２００Ｍ２のＤＬ ＴＥＩＤをＭＭＥ３００Ｃに通知する。ＳＣＧベアラ用のＤＬ ＴＥＩＤは変更しない。

図１８Ｂに示すように、ＭｅＮＢ間ハンドオーバ手順において、Ｓ−ＭｅＮＢ２００Ｍ１からＴ−ＭｅＮＢ２００Ｍ２にＭＣＧベアラのＵＬ−ＴＥＩＤが「Ｈａｎｄｏｖｅｒ ｒｅｑｕｅｓｔ」メッセージで引き継がれる。上述したように、ＳＣＧベアラのＵＬ−ＴＥＩＤは変更されるべきではない。

（２）スプリットベアラ・オプションの場合
図１７及び図１９を参照して、スプリットベアラ・オプションの場合の動作を説明する。図１９は、スプリットベアラ・オプションの場合のＴＥＩＤについて説明するための図である。ここでは、ＳＣＧベアラ・オプションの場合と異なる動作について説明する。

図１９Ａの「１」に示すように、ＭｅＮＢ間ハンドオーバ手順において、ＳｅＮＢ２００ＳにおけるＤＬ−ＴＥＩＤは変更されない。このＤＬ−ＴＥＩＤは、図１７のステップＳ５３２（「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」）又はステップＳ５３４（「ＭｅＮＢ Ｃｈａｎｇｅ ＡＣＫ」）において、「ＳｅＮＢ ＧＴＰ ＴＥＩＤ ｆｏｒ ＤＬ」のＩＥによりＴ−ＭｅＮＢ２００Ｍ２に通知される。

図１９Ｂの「２」に示すように、ＭｅＮＢ間ハンドオーバ手順において、Ｓ−ＭｅＮＢ２００Ｍ１におけるＵＬ−ＴＥＩＤからＴ−ＭｅＮＢ２００Ｍ２におけるＵＬ−ＴＥＩＤに切り替わる。このＵＥ−ＴＥＩＤは、図１７のステップＳ５３５（「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」）及びＳ５３６（「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」）において、「Ｔ−ＭｅＮＢ ＧＴＰ ＴＥＩＤ ｆｏｒ ＵＬ」のＩＥにより、Ｓ−ＭｅＮＢ２００Ｍ１を介してＳｅＮＢ２００に通知され、ステップＳ５３７においてＳｅＮＢ２００ＳがＵＬ−ＴＥＩＤを変更する。

また、図１９Ａの「３」、「４」に示すように、ＭｅＮＢ間ハンドオーバ手順において、ＭＣＧベアラ及びＳＣＧベアラのそれぞれについて、Ｓ−ＭｅＮＢ２００Ｍ１におけるＤＬ−ＴＥＩＤからＴ−ＭｅＮＢ２００Ｍ２におけるＤＬ−ＴＥＩＤに切り替わる。これらのＤＬ−ＴＥＩＤは、図１７のステップＳ５４３（「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」）において、「ＭＣＧ ｐａｒｔ ｏｆ ｓｐｌｉｔ ｂｅａｒｅｒ」のＩＥによりＭＭＥ３００Ｃに通知される。

［第３実施形態の変更例２］
第３実施形態の変更例２において、Ｔ−ＭｅＮＢ２００Ｍ２は、修正要求承諾（「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」）メッセージをＳｅＮＢ２００Ｓに送信するよりも前において、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。

図２０は、第３実施形態の変更例２に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。

図２０に示すように、ステップＳ５６１において、ＵＥ１００は、「Ｍｅａｓｕｒｅｍｅｎｔ ｒｅｐｏｒｔ」をＳ−ＭｅＮＢ２００Ｍ１に送信する。

ステップＳ５６２において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ５６３において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。

ステップＳ５６４において、Ｔ−ＭｅＮＢ２００Ｍ２は、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＳｅＮＢ２００Ｓに送信する。

ステップＳ５６５において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ５６５と同時に、ステップＳ５６６において、ＳｅＮＢ２００Ｓは、ＳＣＧ設定情報を含むメッセージ（メッセージＸ）をＳ−ＭｅＮＢ２００Ｍ１に送信する。当該メッセージＸは、既存のメッセージを拡張したものであってもよいし、新たに規定されたメッセージであってもよい。

ステップＳ５６７において、Ｔ−ＭｅＮＢ２００Ｍ２は、ステップＳ５６２で得られたＭＣＧ設定情報（Ｓ−ＭｅＮＢ２００Ｍ１における設定情報）とステップＳ５６５で得られたＳＣＧ設定情報とをマージする。

ステップＳ５６８において、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ５６３で得られたＭＣＧ設定情報（Ｔ−ＭｅＮＢ２００Ｍ２における設定情報）とステップＳ５６６で得られたＳＣＧ設定情報とをマージする。なお、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ５６３で「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージを受信した際にタイマを起動し、タイマ満了前にメッセージＸ（Ｓ５６６）を得られない場合に、ＭｅＮＢ間ハンドオーバ手順に失敗したと判断してもよい。この場合、通常のハンドオーバ手順に切り替えてもよいし、ハンドオーバ手順を中止してもよい。タイマの値はＯＡＭが設定してもよいし、ｅＮＢ間でネゴシエーションして得られたものでもよい。

ステップＳ５６９において、Ｓ−ＭｅＮＢ２００Ｍ１は、ＭＣＧ設定情報及びＳＣＧ設定情報を含む「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージをＵＥ１００に送信する。

ステップＳ５７０において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２との同期を確立する。

ステップＳ５７１において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２とのＲＲＣ接続確立処理を行う。

ステップＳ５７２において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｐａｔｈ Ｓｗｉｔｃｈ Ｒｅｑｕｅｓｔ」をＭＭＥ３００Ｃに送信する。

［第４実施形態］
以下において、第４実施形態について、第１実施形態乃至第３実施形態との相違点を主として説明する。

第４実施形態は、Ｓ−ＭｅＮＢ２００Ｍ１からＳｅＮＢ２００Ｓに対して、ＳｅＮＢ２００Ｓにおける設定の修正を要求する修正要求（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージを送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージは、ＭｅＮＢ間ハンドオーバ手順を示す情報（ｉｎｔｅｒ−ＭｅＮＢ ＨＯ ｉｎｄｉｃａｔｏｒ）を含む。

図２１は、第４実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。

図２１に示すように、ステップＳ６０１において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ６０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＳｅＮＢ２００Ｓに送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージは、ＭｅＮＢ間ハンドオーバ手順を示す情報（ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ）と、Ｔ−ＭｅＮＢ２００Ｍ２の識別情報（Ｔ−ＭｅＮＢ ＩＤ）を含む。

ステップＳ６０３において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、ＳｅＮＢ２００Ｓの設定の修正を要請する修正要請（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ）メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ」メッセージは、Ｓ−ＭｅＮＢ２００Ｍ１のＸ２インターフェイス上のＩＤ（Ｓ−ＭｅＮＢ Ｘ２ＡＰ ＩＤ）と、ＳＣＧの設定情報（ＳＣＧ ｃｏｎｆｉｇｕｒａｔｉｏｎ）と、を含む。

Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１から受信した「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージにおけるＸ２ＡＰ ＩＤと、ＳｅＮＢ２００Ｓから受信した「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ」メッセージにおける「Ｓ−ＭｅＮＢ Ｘ２ＡＰ ＩＤ」と、を照合して対応付ける。

照合された場合、ステップＳ６０４及びＳ６０５において、Ｔ−ＭｅＮＢ２００Ｍ２とＳｅＮＢ２００Ｓとの間でＳｅＮＢ２００Ｓの設定修正処理を行う。但し、ステップＳ６０４及びＳ６０５は必須の処理ではない。

ステップＳ６０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージは、ＳＣＧ及びＭＣＧそれぞれの設定情報を含む。なお、Ｓ−ＭｅＮＢ２００Ｍ１は、ステップＳ６０２で「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージを送信した際にタイマを起動し、タイマ満了前に「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージを得られない場合に、ＭｅＮＢ間ハンドオーバ手順に失敗したと判断し、上述した対処を行ってもよい。

ステップＳ６０７において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージの受信に応じて、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージをＵＥ１００に送信する。

ステップＳ６０８において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２とのＲＲＣ接続確立処理を行う。

ステップＳ６０９において、ステップＳ６０３での「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｉｒｅｄ」メッセージに対する承認（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍ）メッセージをＳｅＮＢ２００Ｓに送信する。

ステップＳ６１０において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｃｏｎｆｉｒｍ」メッセージの受信に応じて、ステップＳ６０２での「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージに対する肯定応答（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ）メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」メッセージは、「ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ」を含む。

ステップＳ６１１において、Ｓ−ＭｅＮＢ２００Ｍ１は、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」メッセージの受信に応じて、ＳｅＮＢ２００Ｓを解放する。

ステップＳ６１２において、上述したような「Ｐａｔｈ Ｓｗｉｔｃｈｔ」（及び「Ｐａｔｈ Ｕｐｄａｔｅ」）を行う。

ステップＳ６１３において、Ｔ−ＭｅＮＢ２００Ｍ２は、「ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ」をＳ−ＭｅＮＢ２００Ｍ１に送信する。

なお、本シーケンスを次のように一部変更してもよい。具体的には、ＳｅＮＢ２００Ｓは、ステップＳ６０５で「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」をＴ−ＭｅＮＢ２００Ｍ２に送信することに代えて、「ＳＣＧ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を含む「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ」をＳ−ＭｅＮＢ２００Ｍ１に送信する。その場合、ステップＳ６０６の「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ ＡＣＫ」は「ＳＣＧ Ｃｏｎｆｉｇｕｒａｔｉｏｎ」を含まなくてもよい。

［第５実施形態］
以下において、第５実施形態について、第１実施形態乃至第４実施形態との相違点を主として説明する。

第５実施形態において、ＳｅＮＢ２００Ｓは、Ｓ−ＭｅＮＢ２００Ｍ１からの「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、ＵＥ１００のハンドオーバを要求する「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。すなわち、ＳｅＮＢ２００ＳがＳ−ＭｅＮＢ２００Ｍ１の代わりに「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

図２２は、第５実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。

図２２に示すように、ステップＳ７０１において、Ｓ−ＭｅＮＢ２００Ｍ１は、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＳｅＮＢ２００Ｓに送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージは、ＭｅＮＢ間ハンドオーバ手順を示す情報（ＭｅＮＢ Ｃｈａｎｇｅ Ｉｎｄｉｃａｔｏｒ）と、Ｔ−ＭｅＮＢ２００Ｍ２の識別情報（Ｔ−ＭｅＮＢ ＩＤ）を含む。

ステップＳ７０２において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージは、ＳＣＧの設定情報（ＳＣＧ ｃｏｎｆｉｇｕｒａｔｉｏｎ）を含む。

ステップＳ７０３において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージをＳｅＮＢ２００Ｓに送信する。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージは、ＳＣＧ及びＭＣＧそれぞれの設定情報を含む。

ステップＳ７０４において、ＳｅＮＢ２００Ｓは、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージの受信に応じて、ステップＳ７０１での「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージに対する肯定応答（ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ＡＣＫ）メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ＡＣＫ」メッセージは、ＳＣＧ及びＭＣＧそれぞれの設定情報を含む。

ステップＳ７０５において、Ｓ−ＭｅＮＢ２００Ｍ１は、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ＡＣＫ」メッセージの受信に応じて、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージをＵＥ１００に送信する。

ステップＳ７０６において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２とのＲＲＣ接続確立処理を行う。

ステップＳ７０７において、上述したような「Ｐａｔｈ Ｓｗｉｔｃｈｔ」（及び「Ｐａｔｈ Ｕｐｄａｔｅ」）を行う。

ステップＳ７０８において、Ｔ−ＭｅＮＢ２００Ｍ２は、「ＳｅＮＢ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ Ｃｏｎｆｉｒｍ」メッセージをＳｅＮＢ２００Ｓに送信する。但し、ステップＳ７０８は必須の処理ではない。

ステップＳ７０９において、ＳｅＮＢ２００Ｓは、「ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ」をＳ−ＭｅＮＢ２００Ｍ１に送信する。

［第６実施形態］
以下において、第６実施形態について、第１実施形態乃至第５実施形態との相違点を主として説明する。

第６実施形態は、ＭｅＮＢ間ハンドオーバ手順の過程で、「ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ」を使用するのではなく、「ＳｅＮＢ Ａｄｄｉｔｉｏｎ」を使用する。具体的には、Ｔ−ＭｅＮＢ２００Ｍ２は、Ｓ−ＭｅＮＢ２００Ｍ１からの「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、ＳｅＮＢ２００ＳをＵＥ１００のための新たなＳｅＮＢとして設定するための追加要求（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ）メッセージをＳｅＮＢ２００Ｓに送信する。これにより、ＭｅＮＢ間ハンドオーバ手順の過程で、ＳｅＮＢ２００ＳにおいてＵＥ１００に対応する設定が一時的に二重に存在することになる。

図２３は、第６実施形態に係るＭｅＮＢ間ハンドオーバ手順を示すシーケンス図である。

図２３に示すように、ステップＳ８０１において、Ｓ−ＭｅＮＢ２００Ｍ１及びＳｅＮＢ２００Ｓは、ＵＥ１００と二重接続方式の通信を行う。

ステップＳ８０２において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

ステップＳ８０３において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、「ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＳｅＮＢ２００Ｓに送信する。

ステップＳ８０４において、ＳｅＮＢ２００Ｓは、「ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、肯定応答（ＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｒｅｑｕｅｓｔ ＡＣＫ）メッセージをＴ−ＭｅＮＢ２００Ｍ２に送信する。

その結果、ステップＳ８０５において、ＳｅＮＢ２００Ｓ及びＴ−ＭｅＮＢ２００Ｍ２は、二重接続方式が可能な状態になる。一方で、ＳｅＮＢ２００Ｓには、元々の設定情報（Ｓ−ＭｅＮＢ２００Ｍ１との設定情報）が維持されている。

ステップＳ８０６において、Ｔ−ＭｅＮＢ２００Ｍ２は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージをＳ−ＭｅＮＢ２００Ｍ１に送信する。「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージは、ＳＣＧ及びＭＣＧそれぞれの設定情報を含む。

ステップＳ８０７において、Ｓ−ＭｅＮＢ２００Ｍ１は、「Ｈａｎｄｏｖｅｒ Ｒｅｑｕｅｓｔ Ａｃｋｎｏｗｌｅｄｇｅ」メッセージの受信に応じて、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」メッセージをＵＥ１００に送信する。

ステップＳ８０８において、ＵＥ１００は、Ｔ−ＭｅＮＢ２００Ｍ２とのＲＲＣ接続確立処理を行う。

ステップＳ８０９において、Ｓ−ＭｅＮＢ２００Ｍ１は、「ＳｅＮＢ Ｒｅｌｅａｓｅ Ｒｅｑｕｅｓｔ」メッセージをＳｅＮＢ２００Ｓに送信する。その結果、ＳｅＮＢ２００Ｓにおける元々の設定情報（Ｓ−ＭｅＮＢ２００Ｍ１との設定情報）が解放される。

ステップＳ８１０において、Ｓ−ＭｅＮＢ２００Ｍ１とＳｅＮＢ２００Ｓとの間でデータフォワーディング処理を行う。但し、ステップＳ８１０は必須の処理ではない。

ステップＳ８１１において、上述したような「Ｐａｔｈ Ｓｗｉｔｃｈｔ」（及び「Ｐａｔｈ Ｕｐｄａｔｅ」）を行う。

ステップＳ８１２において、Ｓ−ＭｅＮＢ２００Ｍ１は、「ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ」をＳｅＮＢ２００Ｓに送信する。

ステップＳ８１３において、Ｔ−ＭｅＮＢ２００Ｍ２は、「ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅ」をＳ−ＭｅＮＢ２００Ｍ１に送信する。

［その他の実施形態］
上述した各実施形態を別個独立に実施する場合に限らず、２以上の実施形態を組み合わせてもよい。

上述した実施形態では、マクロセルと小セルとの組み合わせにより二重接続方式の通信を行うケースを例示した。しかしながら、そのような組み合わせに限らず、マクロセルとピコセルとの組み合わせにより二重接続方式の通信を行ってもよく、ピコセルとフェムトセルとの組み合わせにより二重接続方式の通信を行ってもよい。

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

［付記］
１．はじめに
本付記では、様々なハンドオーバのシナリオを考慮して、ＭＣＧハンドオーバ及びＳＣＧハンドオーバのために必要なメカニズムについて説明する。

２．用語
用語「ＭＣＧハンドオーバ」及び「ＳＣＧハンドオーバ」が採用される前に、まずこれらの用語を使用した場合の影響を考慮する必要がある。ＭＣＧは、ｅＮＢ内キャリアアグリゲーション（ｅＮＢ内ＣＡ）によりＰＣｅｌｌ及びＳＣｅｌｌの両方がＵＥに設定されている可能性を示唆しており、既存のｅＮＢ内ＣＡ手順はＰＣｅｌｌハンドオーバのみを許容するので、用語「ＭＣＧハンドオーバ」の使用は誤解を招く可能性があり、既存のｅＮＢ内ＣＡハンドオーバ手順と矛盾し得る。しかしながら、既存のｅＮＢ内ＣＡ手順は、ＤＣ機能とＰＣｅｌｌハンドオーバを組み合わせる可能性を意味し得る。そのような機能はリリース１２前では想定されていないが、この機能の説明を容易にするために、用語「ＤＣを伴うＰＣｅｌｌハンドオーバ」は、このような機能を称するために使用されることが提案される。この機能の有用性についての詳細については後述する。

考察１：ＰＣｅｌｌ及びＳＣｅｌｌの両方からなるＭＣＧハンドオーバは、既存のｅＮＢ内ＣＡハンドオーバ手順では許可されていない。

提案１：ＤＣを伴うＰＣｅｌｌハンドオーバは、二重接続が有効化されている間に、２つのＭｅＮＢ間のハンドオーバを称するために使用されるべきである。そのような機能が実際に必要かどうかは検討が必要である。

同様に、２つのＳｅＮＢ間のハンドオーバを記載するために、「ＳＣＧハンドオーバ」の代わりに、「特別セルのハンドオーバ」を使用することが提案される。これは、２つのＭｅＮＢ間のハンドオーバと一貫性のある手順を提供するであろう。

提案２：特別セルのハンドオーバは、二重接続性の間における２つのＳｅＮＢ間のハンドオーバを称するために使用されるべきである。それは、そのような機能が必要かどうかは検討が必要である。

３．ハンドオーバのシナリオ
対象とする展開シナリオを図２４に示す。図２４に示す高密度の小セル展開は、いくつかのシナリオ（例えば、密集した都市や大型ショッピングモール）において巨大なトラフィックをサポートするために必要とされる。特に、高密度の小セル展開では、マクロセルの境界に多くの小セルが配置されることを予測することが妥当である（例えば、図２４における右上マクロセルを参照）。

考察２：多くの小セルは、マクロセルの境界付近に展開され得る。

考察２の結果として、二重接続を伴うハンドオーバ手順は、考慮から除外されるべきではない。具体的には、ＤＣを伴うＰＣｅｌｌハンドオーバが次のシナリオ下で有用であり得る：
・シナリオＭ１：ＳｅＮＢがソースＭｅＮＢ（Ｓ−ＭｅＮＢ）とターゲットＭｅＮＢ（Ｔ−ＭｅＮＢ）との間のセル端に配置される。

また、特別セルのハンドオーバは、次のシナリオ下で有用であり得る：
・シナリオＳ２：ソースＳｅＮＢ（Ｓ−ＳｅＮＢ）及びターゲットＳｅＮＢ（Ｔ−ＳｅＮＢ）がＭｅＮＢのカバレッジ内に配置される。

最後に、ＤＣを伴うＰＣｅｌｌハンドオーバと特別セルのハンドオーバとの組み合わせは、次のような状況の下で有用であり得る：
・シナリオＭ３：ＳｅＮＢ（ＳｅＮＢ１）がＳ−ＭｅＮＢのカバレッジ内に配置され、隣接ＳｅＮＢ（ＳｅＮＢ２）がＴ−ＭｅＮＢのカバレッジ内に配置される。なお、ＭｅＮＢ間のセル端とＳｅＮＢ間のセル端とが同じ領域である(図２５)。

提案３：二重接続を伴う３つのハンドオーバシナリオを考慮に入れるべきである。

４．可能なハンドオーバ手順
４．１．ＤＣを伴うＰＣｅｌｌハンドオーバ
４．１．１．シナリオＭ１
４．１．１．１．現在のハンドオーバ手順に関する問題
シナリオＭ１のための二重接続を伴う現在のハンドオーバ手順の単純な応用を図２６に示す。このハンドオーバ手順は、二重接続のためのハンドオーバを完了するために３つのＲＲＣ接続再構成メッセージが必要とされていると仮定する。１つはＳｅＮＢの解放であり、１つはＭｅＮＢハンドオーバであり、１つは同一ＳｅＮＢの追加である。このハンドオーバ手順のためのＲＲＣ接続再構成メッセージ数の増加は、ＲＬＦ／ＨＯＦの発生及びスループット劣化をもたらし得る。

考察３：シナリオＭ１では、ＰＣｅｌｌハンドオーバ中に同一ＳｅＮＢを解放・追加するする現在の手順は、複数のＲＲＣ接続再構成を必要とし、ＲＬＦ／ＨＯＦの増加につながる可能性がある。

４．１．１．２．ＤＣを伴うＰＣｅｌｌハンドオーバの詳細
不要なＲＲＣ接続再構成の数を減らすために、強化されたハンドオーバ手順が図２７で検討される。この手順は、１つのみのＲＲＣ接続再構成が必要とされるように、ＵＥがＤＣを伴うＰＣｅｌｌハンドオーバの間に少なくとも特別セルを維持することを可能とする。ＤＣを伴うＰＣｅｌｌハンドオーバが以下の選択肢の１つを使用して実現することができる。

選択肢１：Ｔ−ＭｅＮＢがＳｅＮＢに対してＳｅＮＢ追加手順を開始することができるように、ハンドオーバ要求が、既存ＳｅＮＢの設定（configurations）に関連するパラメータを含む。

選択肢２：ハンドオーバ要求が、ハンドオーバ手順が二重接続を含むことの簡単な通知を含む。Ｔ−ＭｅＮＢ（又はＳｅＮＢであり得る）がハンドオーバ完了前にＳｅＮＢに対して追加手順を開始する。

いずれかの選択肢でも、Ｔ−ＭｅＮＢにおけるアドミッション制御の後に、ＳｅＮＢが、Ｓ−ＭｅＮＢから解放され、ＵＥの再構成の前にＴ−ＭｅＮＢに追加されているものとする。その後、Ｔ−ＭｅＮＢは、ハンドオーバ及びＳｅＮＢ追加の両方の構成を伴うＲＲＣコンテナをＳ−ＭｅＮＢに送信し、最終的なＲＲＣ接続再構成がＵＥに送信される。

考察４：強化されたＤＣ手順を伴うＰＣｅｌｌハンドオーバは、ＲＲＣ接続再構成メッセージの数を減らし、ＵＥはＳＣＧ設定を維持することを可能にする。

提案４：ＤＣを伴うＰＣｅｌｌハンドオーバを実現するために２つの選択肢のどちらを使用すべきかを決定する必要がある。

提案５：１つのみのＲＲＣ接続再構成で二重接続を伴うＭｅＮＢハンドオーバ手順を強化するためのオプションを検討する必要がある。

４．２．特別セルのハンドオーバ
４．２．１．シナリオＳ２
特別セルのハンドオーバの概念は新しいが、図２８に示すように、現在のハンドオーバ手順とＳｅＮＢ追加／変更／解放手順を使用して実現することができる。

ＤＣを伴うＰＣｅｌｌハンドオーバとは対照的に、ＭｅＮＢとのＲＲＣエンティティはＵＥのために変わらないので、ＳｅＮＢ追加／変更要求メッセージにおけるＳｅＮＢ追加／変更及びＳｅＮＢ解放の機能を用いて特別セルのハンドオーバを実現することができる。図２８に基づき、２つのＲＲＣ接続再構成メッセージが必要とされている。しかしながら、ＳｅＮＢ解放応答メッセージがＲＲＣコンテナを含まない場合はそれを容易に削減することができ、それは、ＭｅＮＢがＳ−ＳｅＮＢの解放のためにだけにＵＥにＲＲＣ再構成メッセージを送信する必要がないことを意味する。そして、これは下記の合意と調和する。

５）ＭｅＮＢは、ＳｅＮＢが提供するＲＲＣ構成の内容を変更しない。−ＦＦＳ ＭｅＮＢがＵＥのいずれかのサービングセルを解放することをＳｅＮＢに要求し、ＳｅＮＢがコンテナを作成し、それがサービングセルの解放につながるか。又は、ＭｅＮＢは、自身で、ＳｅＮＢに維持されているサービングセルを解放することができるかどうか。−ＦＦＳ ＭｅＮＢがＳｅＮＢから受信したＲＲＣコンテナを理解又は拒否する必要があるかどうか。−ＦＦＳ ＭｅＮＢとＳｅＮＢとでどのように「共有」（例えばＬ１処理能力）するか。

考察５：ＳｅＮＢ解放応答メッセージ内にＲＲＣコンテナが含まれていない場合、特別セルのハンドオーバに使用されるＲＲＣ接続再構成メッセージの数を削減することができる。

他の選択肢は、ＲＲＣコンテナの無い「ＳｅＮＢ交換要求」として新しいメッセージを定義することである。図２９を参照すると、ＭｅＮＢ又はＳ−ｅＮＢの何れかが、特別セルのハンドオーバを他のｅＮＢに知らせるためのＳｅＮＢ交換手順を開始する。ｅＮＢ間の調整が完了した後、Ｔ−ＳｅＮＢは、ＲＲＣコンテナを含む追加／変更コマンドをＭｅＮＢに送信し、その後、ＭｅＮＢは、ＲＲＣコンテナをＲＲＣ接続再構成内でＵＥに転送し得る。

提案６：ＳｅＮＢ解放応答が特別セルのハンドオーバのためのＲＲＣコンテナを含むべきかどうかを決定する必要がある。

４．３．シナリオＭ３
このシナリオでは、ＭｅＮＢ及びＳｅＮＢの両方のセル端が同じ領域にある。考慮すべき３つの選択肢がある。

選択肢１：ＳｅＮＢ１の解放後にＰＣｅｌｌハンドオーバが開始される。これは、現在のｅＮＢ内ＰＣｅｌｌハンドオーバ手順と同じである。ＳｅＮＢ２はハンドオーバの完了後に追加することができる。

選択肢２：ＳｅＮＢ１構成を維持しつつＤＣを伴うＰＣｅｌｌハンドオーバが開始される。そして、特別セルのハンドオーバは別途ＳｅＮＢ１からＳｅＮＢ２に開始される。この選択肢は、基本的には、Ｍ１とＳ２のためのハンドオーバ手順を別々に開始すると想定している。

選択肢３：ＤＣを伴うＰＣｅｌｌハンドオーバ及び特別セルのハンドオーバを同時に開始する。これは、シナリオＭ１及びＳ２を組み合わせたパラレルハンドオーバ手順を必要とする。

選択肢２及び選択肢３では、別個のハンドオーバ強化の手順が必要とされない。その代わりに、シナリオＭ１及びシナリオＳ２について検討されるハンドオーバ手順を再利用することで十分である。

考察６：シナリオＭ１及びＳ２のための強化されたハンドオーバ手順がシナリオＭ３のために適用可能であり得る。シナリオＭ３のために別個に強化された手順は必要とされない。

５．ハンドオーバシナリオのその他の制約
二重接続用Ｘｎの機能は、既存のＸ２インターフェイス上で実現される。したがって、強化された二重接続の手順は、Ｓ１インターフェイス上で適用されない。二重接続を伴うハンドオーバについては、Ｓ１ハンドオーバ手順が完了する前にＳｅＮＢがＵＥから解放されるべきである。

考察７：二重接続のための強化されたハンドオーバ手順は、Ｘ２インターフェイス上で適用可能であるべきである。

［付記２］
１.はじめに
リリース１２では、ＭｅＮＢ間のハンドオーバはサポートしない事が決まった。つまり、ｅＮＢ間ハンドオーバ時に、ＳｅＮＢは解放されるということである。一方、リリース１２のＤｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙでは、ｅＮＢ間ハンドオーバ時に使用する“ＭｅＮＢ ｔｏ ｅＮＢ ｃｈａｎｇｅ”プロシージャと、ＭｅＮＢとしての役割を維持する時に使用する“Ｉｎｔｒａ−ＭｅＮＢ ｃｈａｎｇｅ ｉｎｖｏｌｖｉｎｇ ＳＣＧ ｃｈａｎｇｅ”プロシージャが既に仕様化されている。よって、これらのプロシージャをベースラインとして、リリース１３の検討を行う事ができる。

この付記では、これらリリース１２のプロシージャを基に、“ｉｎｔｅｒ−ＭｅＮＢ ｈａｎｄｏｖｅｒ ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”（ＳｅＮＢ ｃｈａｎｇｅを伴わないＭｅＮＢ間ハンドオーバを行う方法）を実現するための、４つの方法について議論する。

２.１.検討の前提となる仮定
まず始めに、“ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”の意味について明らかにすべきである。”ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”は異なる要求事項を異なる側面から暗示していると仮定している。

（ＵＥ設定の観点）
リリース１２における“Ｉｎｔｒａ−ＭｅＮＢ ｃｈａｎｇｅ ｉｎｖｏｌｖｉｎｇ ＳＣＧ ｃｈａｎｇｅ”プロシージャによると、ＵＥは、ＳＣＧの設定情報の解放を伴わずに、単一のＲＲＣ接続再設定メッセージによって、再設定されることが可能である。つまり、ＵＥの視点から考えると、既に”ｈａｎｄｏｖｅｒ ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”はサポートされているということである。リリース１３におけるＭｅＮＢ間ハンドオーバについて、“ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”は、ＭｅＮＢ間ハンドオーバプロシージャの間に、ＳＣＧの設定情報を解放することなく、ＳｅＮＢの設定を行うことを指示できる、単一のＲＲＣ接続再設定メッセージである、と解釈できる。

考察１：単一のＲＲＣ接続再設定が、ＭｅＮＢ間ハンドオーバプロシージャに含まれる可能性がある。

リリース１２における“ＭｅＮＢ ｔｏ ｅＮＢ ｃｈａｎｇｅ”プロシージャに関して、ＳｅＮＢの設定は、“ＭｅＮＢ ｔｏ ｅＮＢ ｃｈａｎｇｅ”プロシージャの実行後、ターゲットＭｅＮＢからのＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎプロシージャによって、実行される。よって、リリース１３における“ｉｎｔｅｒ−ＭｅＮＢ ｈａｎｄｏｖｅｒ ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”の方法のひとつとして、Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ中にＳｅＮＢ Ａｄｄｉｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎプロシージャが含まれる可能性がある。（図３０参照）

一方、“Ｉｎｔｒａ−ＭｅＮＢ ｃｈａｎｇｅ ｉｎｖｏｌｖｉｎｇ ＳＣＧ ｃｈａｎｇｅ”プロシージャをリリース１３のベースラインとした場合、ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ＰｒｅｐａｒａｔｉｏｎプロシージャがＨａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎプロシージャ中に含まれる可能性がある（図３１参照）。しかしながら、リリース１２のプロシージャは同一ｅＮＢ内におけるハンドオーバを想定しているため、ソースＭｅＮＢとターゲットＭｅＮＢのどちらのＭｅＮＢがＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎプロシージャを開始するのかが明確ではない。加えて、リリース１２のプロシージャはＨａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎプロシージャとの協調動作を考慮していないため、いつＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ プロシージャが開始されるのかについての議論も必要である。

考察２：ＳｅＮＢ Ａｄｄｉｔｉｏｎ ＰｒｅｐａｒａｔｉｏｎとＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎのどちらかが、ＭｅＮＢ間ハンドオーバ中のＳｅＮＢ設定に用いられる可能性がある。

考察３：もしＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ＰｒｅｐａｒａｔｉｏｎがＭｅＮＢ間ハンドオーバに用いられる場合、どのＭｅＮＢがいつ当該プロシージャを開始するのかが明確ではない。

２.２. 概略設計の選択肢
（Ａｌｔ １：”ＭｅＮＢ ｔｏ ｅＮＢ ｃｈａｎｇｅ”の拡張）
ターゲットＭｅＮＢは、ＲＲＣ接続再設定の為の最終的なＲＲＣ設定を生成する責務を負う。現状の”ＭｅＮＢ ｔｏ ｅＮＢ ｃｈａｎｇｅ”プロシージャにおいて、ターゲットＭｅＮＢは”Ｔａｒｇｅｔ ｅＮＢ Ｔｏ Ｓｏｕｒｃｅ ｅＮＢ Ｔｒａｎｓｐａｒｅｎｔ Ｃｏｎｔａｉｎｅｒ”の中の”ＳＣＧ Ｃｏｎｆｉｇｕｒａｔｉｏｎ”を”Ｒｅｌｅａｓｅ”に設定する。これは、”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ"メッセージに含まれる（図３０のｓｔｅｐ ３参照）。

リリース１３におけるＳｅＮＢ変更を伴わないＭｅＮＢ間ハンドオーバプロシージャにおいて、ターゲットＭｅＮＢは”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ”メッセージとして、ソースＭｅＮＢに対して”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ”が送信されるよりも以前に、”ＳＣＧ Ｃｏｎｆｉｇｕｒａｔｉｏｎ”を”ｓｅｔｕｐ”に設定し、適切な設定情報を入力する可能性がある。当該理由から、ＳｅＮＢ Ａｄｄｉｔｉｏｎプロシージャ（ｓｔｅｐ ２参照）が実行される事は、簡単な拡張のひとつであると思われる。

ターゲットＭｅＮＢが”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ”を送信するまで、ソースＭｅＮＢは”ＳｅＮＢ Ｒｅｌｅａｓｅ”プロシージャ（ｓｔｅｐ ４参照）を開始すべきではない。なぜならば、ターゲットＭｅＮＢが当該ハンドオーバ要求を拒否する可能性がある為である。ハンドオーバ受入許可を受信した後、ソースＭｅＮＢはＳｅＮＢ ＲｅｌｅａｓｅプロシージャをＳｅＮＢに対して開始する。

（Ａｌｔ ２：”Ｉｎｔｒａ−ＭｅＮＢ ｃｈａｎｇｅ ｉｎｖｏｌｖｉｎｇ ＳＣＧ ｃｈａｎｇｅ”の拡張）
“Ｉｎｔｒａ−ＭｅＮＢ ｃｈａｎｇｅ ｉｎｖｏｌｖｉｎｇ ＳＣＧ ｃｈａｎｇｅ”プロシージャもまた、”ｉｎｔｅｒ−ＭｅＮＢ ｈａｎｄｏｖｅｒ ｗｉｔｈｏｕｔ ＳｅＮＢ ｃｈａｎｇｅ”を実現する為に改良される候補のひとつである。現在のプロシージャでは、ＭｅＮＢが”ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャを開始する。

ＭｅＮＢ間ハンドオーバの場合を考えると、どちらのＭｅＮＢが当該プロシージャを開始するのかが不明確である。加えて、”ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャは”Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャとのインタラクションを仮定していないので、当該プロシージャをいつ実行するのかについても、検討が必要である。これら検討事項を基に、３つの選択肢が考えられる。３つのそれぞれの選択肢は下記に示されるＡｌｔ２−１，Ａｌｔ２−２，Ａｌｔ２−３となる。

加えて、単一のＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージで、ｉｎｔｅｒ ＭｅＮＢ ハンドオーバを実現するためには、それぞれの選択肢のＳｔｅｐ４の前に、どのようにして、ソースＭｅＮＢがＲＲＣの設定情報を保持するのかという共通の問題が存在する。そのため、例えば、どのようにしてＳＣＧ−ｃｏｎｆｉｇＩｎｆｏや、ＳＣＧ―ｃｏｎｆｉｇのような必要な情報を交換するのか、ということや、設定情報のための交渉をどのように行うかは議論されるべきだろう。

（Ａｌｔ ２-１：ソースＭｅＮＢが開始するＳｅＮＢ ｍｏｄｉｆｉｃａｔｉｏｎとＨａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎの並列実行の場合）
この場合、ソースＭｅＮＢは、”Ｈａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャの途中で“ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャを開始する。当該プロシージャは並列実行される可能性がある（図３１のｓｔｅｐ １およびｓｔｅｐ ２参照）。

Ｓｔｅｐ４においてＵＥへ最後のＲＲＣメッセージを送信するために、ソースＭｅＮＢは必要な情報をｓｔｅｐ２もしくはｓｔｅｐ３で手に入れる必要があるだろう。

（Ａｌｔ ２-２:ソースＭｅＮＢが開始するＳｅＮＢ ＭｏｄｉｆｉｃａｔｉｏｎがＨａｎｄｏｖｅｒ Ｐｒｅｐａｒａｔｉｏｎの後に実行される場合）
この場合、ソースＭｅＮＢは、”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ”を受信した後に、”ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャを開始する（図３２のｓｔｅｐ ３参照）。

（Ａｌｔ ２-３:ターゲットＭｅＮＢが開始するＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎを用いる場合）
この場合、ターゲットＭｅＮＢは、ＭｅＮＢ間ハンドオーバを示唆する”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ”を受信した後に（ｓｔｅｐ １参照）、”ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャを開始する（図３３のｓｔｅｐ ２参照）。”ＳｅＮＢ Ｍｏｄｉｆｉｃａｔｉｏｎ Ｐｒｅｐａｒａｔｉｏｎ”プロシージャの完了後に、ターゲットＭｅＮＢはハンドオーバ受入許可メッセージを、ソースＭｅＮＢに対して送信する。このメッセージには当該ＵＥに対するＲＲＣ再設定情報を含む（ｓｔｅｐ ３）。

ここで、Ａｌｔ １と同様の理由により、ターゲットＭｅＮＢが当該プロシージャを開始する場合は、”ＨＡＮＤＯＶＥＲ ＲＥＱＵＥＳＴ ＡＣＫＮＯＷＬＥＤＧＥ”を送信するよりも以前に開始されるべきである（図３３のｓｔｅｐ ２参照)。

２.３. 初期評価
各選択肢に対する初期評価結果を表３に示す。

もっとも簡単な拡張はＡｌｔ １であると思われる。一方、他の選択肢は潜在的にＭｅＮＢ間ハンドオーバプロシージャを最適化できる可能性がある。しかしながら、無線アクセスネットワーク観点だけで見ても、全ての選択肢に長所と短所がある。

［付記３］
１. はじめに
この付記ではＳ１とＸ２インターフェイスの接続性の観点から、ＳｅＮＢの変更無しのｉｎｔｅｒ−ＭｅＮＢハンドオーバをサポートするための要求事項について、考えられる基地局等の配置のシナリオを基に議論する。

２.１. 配置シナリオ１（基本シナリオ）
図３４は基本的な配置シナリオを示している、このシナリオにおいて、ソース ＭｅＮＢとターゲットＭｅＮＢ間と、各ＭｅＮＢと各ＭｅＮＢ間でハンドオーバが行われる領域に位置しているＳｅＮＢ間のＸ２は利用可能である。加えて、各ｅＮＢは同一のＳ−ＧＷにＳ１で接続されている。

このシナリオの場合、ハンドオーバＰｒｅｐａｒａｔｉｏｎとＰａｔｈ ｓｗｉｔｃｈ ｒｅｑｕｅｓｔ を含む全体のハンドオーバプロシージャは、下記の側面から、再考される必要がある。

ベアラの情報について
Ｅ−ＲＡＢを管理するために、ターゲットＭｅＮＢはＳ１/Ｘ２上で既に確立されており、ＳＣＧ／Ｓｐｌｉｔベアラに対応する、それぞれのベアラの情報が必要かもしれない。例えば、ＳＣＧベアラに対応したＳ−ＧＷのＵＬ ＧＴＰ ＴＥＩＤや、ＳｅＮＢのＤＬ ＧＴＰ ＴＥＩＤ、また、Ｓｐｌｉｔベアラに対応したターゲットＭｅＮＢのＵＬ ＧＴＰ ＴＥＩＤなどである。

考察１: ＭｅＮＢ間のハンドオーバの間、既に確立されたＳＣＧ／Ｓｐｌｉｔベアラに対応するＥ−ＲＡＢの情報の交換がＭｅＮＢ間で必要かもしれない。

Ｐａｔｈ ｓｗｉｔｃｈについて
Ｒｅｌ−１２もしくは、それ以前、ハンドオーバプロシージャはＳ１のユーザプレーンベアラをソースｅＮＢからターゲットｅＮＢへ変更するために、Ｐａｔｈ ｓｗｉｔｃｈ ｒｅｑｕｅｓｔ プロシージャを使用している。Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙの場合、Ｓ１ベアラの更新に必要なＥ−ＲＡＢ Ｍｏｄｉｆｉｃａｔｉｏｎ ＩｎｄｉｃａｔｉｏｎプロシージャがＳＣＧ ベアラに関連した操作に使用されている。これはつまり、ＭＣＧベアラに対応するＥ−ＲＡＢをＭｅＮＢが維持する一方、ＳＣＧベアラとなるＥ−ＲＡＢをＳ−ＧＷのＵＬ ＧＴＰ ＴＥＩＤの変更なしに、ＭｅＮＢからＳｅＮＢへ更新するために使用されるということである。

ＳＣＧベアラを維持しつつＭｅＮＢ間のハンドオーバを行うＲｅｌ−１３プロシージャを検討する場合、Ｓ−ＧＷとＳｅＮＢ間のＵＬ ＧＴＰ ＴＥＩＤは変更されてはならないという要求があるだろう。理由は、これらの既に確立されたベアラはＭｅＮＢハンドオーバには関係ないからである。仮に、ＭｅＮＢ間のハンドオーバにおいてＰａｔｈ ｓｗｉｔｃｈ ｒｅｑｕｅｓｔプロシージャを再利用すれば、ＥＰＣはＳ−ＧＷのＵＬ ＧＴＰ ＴＥＩＤを変更することを許容してしまい、これは、ＳｅＮＢに対して問題となる可能性がある。

考察２: ＭｅＮＢ間のハンドオーバ 間はＳ−ＧＷのＧＴＰ ＴＥＩＤが変更されることは許されないだろう。

上記の考えられる要求を考慮すると、ＭｅＮＢ間のハンドオーバ のための、Ｘ２もしくはＳ１で必要とされるプロシージャ、もしくは、現状のプロシージャの拡張案を検討すべきである。

提案１: 上記を考慮して、ＭｅＮＢ間のハンドオーバ間のＧＴＰ ＴＥＩＤの扱いについて議論すべきである。

２．２．配置シナリオ２（ターゲットＭｅＮＢとＳｅＮＢ間にＸ２が無い）
以前のＲＡＮ２＃８５会合の際、ターゲットＭｅＮＢとＳｅＮＢ間のＸ２の接続性に関する小さな議論があった。そのため、我々はそのような議論をこの配置シナリオへ反映させた。

図３５はターゲットＭｅＮＢとＳｅＮＢ間のＸ２が利用不可である場合の配置シナリオである。Ｘ２の利用不可に関しては２つの理由が想定される。１つはネットワークの混雑等で、一時的に利用出来ない動的な理由、もう一つは、接続性がないために利用出来ない静的な理由である。現状、ソースＭｅＮＢはＭｅＮＢ間のハンドオーバ後のＸ２利用が不可であることを知る術を持っていない。

考察３: ソースＭｅＮＢは動的、もしくは静的な理由でもたらされる、Ｘ２の利用不可という事実を知らない。

この配置シナリオの場合、ＭｅＮＢ間のハンドオーバを成功させるための責任をソースＭｅＮＢ もしくはターゲットＭｅＮＢのどちらが負うべきかを明確化する必要がある。単純な仮定として、ターゲット ＭｅＮＢが責任を負う場合、ターゲットＭｅＮＢはＳｅＮＢとのＸ２が利用不可な場合はＨＡＮＤＯＶＥＲ ＰＲＥＰＡＲＡＴＩＯＮ ＦＡＩＬＵＲＥメッセージ返信するように作成するだろう。ソースＭｅＮＢは他のｅＮＢ間のＸ２の利用可否について、考慮しなくて良い。この場合、Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙは拒絶し、通常のハンドオーバは実行するのかということについては更なる議論が必要である。

ソースＭｅＮＢが責任を負う場合、他のｅＮＢ間のＸ２の利用可否を知るための情報が必要だろう、これはソースＭｅＮＢにおいて更なる複雑な機能を要することになるかもしれない。しかし、ＭｅＮＢの変更を含むハンドオーバ 準備失敗メッセージの数を減らすことが可能である。また、この情報は、拡張されるSON機能のためにも使用可能である。ソースＭｅＮＢがどのノード、例えばＳｅＮＢやターゲットＭｅＮＢからＸ２の利用可否に関する情報を貰うのかといったことや、どのタイミング、例えば、ＭｅＮＢ間のハンドオーバ時もしくは、定期的な状況報告よって情報を受けとるかについては、更なる議論が必要である。

ＭｅＮＢ間のハンドオーバが実行可能かどうかについての判断は、どのｅＮＢが責任を負うべきかについて議論すべきである。

提案２: ターゲットＭｅＮＢとＳｅＮＢ間のＸ２の接続性を保証する責任を、どのｅＮＢが負うべきか、議論すべきである。

２．３．配置シナリオ３（Ｓ−ＧＷの置きかえを伴うＸ２ハンドオーバ）
図３６は異なるＳ−ＧＷがソースＭｅＮＢとターゲット ＭｅＮＢに接続している、また、ＳｅＮＢが両方のＳ−ＧＷとの接続を持っていることを示す、配置シナリオである。

現在の合意事項に従えば、Ｄｕａｌ Ｃｏｎｎｅｃｔｉｖｉｔｙの際のＳｅＮＢ Ａｄｄｉｔｉｏｎ時のＳ−ＧＷの置き換えを禁止している、一方、Ｓ−ＧＷの置き換えが発生するＸ２ハンドオーバはサポートしている。Ｒｅｌ−１２の合意事項の範囲外となる、Ｓ−ＧＷが置き変えられるＭｅＮＢ間のハンドオーバで、ターゲットＭｅＮＢとＳｅＮＢは同じＳ−ＧＷに接続を持つ、という場合、シグナリング負荷の低減と、ユーザの体感するサービス品質の改良のために、このＳ−ＧＷの置き換えを伴う、ＭｅＮＢ間のハンドオーバを受け入れるべきである。

提案３: ターゲットＭｅＮＢとＳｅＮＢが同一Ｓ−ＧＷへＳ１の接続性を持っている限り、ＭｅＮＢ間のハンドオーバ時のＳ−ＧＷの置き換えを許容することが出来る。

[相互参照]
米国仮出願第６１／９３４３５０号（２０１４年１月３１日出願）の全内容が、参照により本願明細書に組み込まれている。

本発明は、移動通信分野において有用である。

Claims (5)

1. ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおいて、ターゲットマスタ基地局として動作するマスタ基地局であって、
   前記セカンダリ基地局を変更することなく、前記ソースマスタ基地局から前記ターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備え、
   前記制御部は、
   前記セカンダリ基地局に関する情報を含むハンドオーバ要求を前記ソースマスタ基地局から受信する処理と、
   前記ハンドオーバ要求の受信に応じて、マスタ基地局変更に関する第１のメッセージを前記セカンダリ基地局に送信する処理と、
   前記第１のメッセージに対する肯定応答である第２のメッセージを前記セカンダリ基地局から受信する処理と、を行い、
   前記第２のメッセージは、前記セカンダリ基地局が前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む
   マスタ基地局。
2. 前記制御部は、前記第２のメッセージの受信に応じて、前記アルゴリズム情報を含むハンドオーバ肯定応答を前記ソースマスタ基地局に送信する処理をさらに行う
   請求項１に記載のマスタ基地局。
3. ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける前記セカンダリ基地局であって、
   前記セカンダリ基地局を変更することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行う制御部を備え、
   前記制御部は、
   前記セカンダリ基地局に関する情報を含むハンドオーバ要求を受信した前記ターゲットマスタ基地局から、マスタ基地局変更に関する第１のメッセージを受信する処理と、
   前記第１のメッセージに対する肯定応答である第２のメッセージを前記ターゲットマスタ基地局に送信する処理と、を行い、
   前記第２のメッセージは、前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む
   セカンダリ基地局。
4. ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおいて、ターゲットマスタ基地局として動作するマスタ基地局のためのプロセッサであって、
   前記プロセッサは、前記セカンダリ基地局を変更することなく、前記ソースマスタ基地局から前記ターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行い、
   前記プロセッサは、
   前記セカンダリ基地局に関する情報を含むハンドオーバ要求を前記ソースマスタ基地局から受信する処理と、
   前記ハンドオーバ要求の受信に応じて、マスタ基地局変更に関する第１のメッセージを前記セカンダリ基地局に送信する処理と、
   前記第１のメッセージに対する肯定応答である第２のメッセージを前記セカンダリ基地局から受信する処理と、を行い、
   前記第２のメッセージは、前記セカンダリ基地局が前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む
   プロセッサ。
5. ユーザ端末とＲＲＣ接続を確立するマスタ基地局と、前記ユーザ端末に追加的な無線リソースを提供するセカンダリ基地局と、を用いる二重接続方式の通信をサポートする移動通信システムにおける前記セカンダリ基地局のためのプロセッサであって、
   前記プロセッサは、前記セカンダリ基地局を変更することなく、ソースマスタ基地局からターゲットマスタ基地局に対して前記ユーザ端末のハンドオーバを行うマスタ基地局間ハンドオーバ手順のための制御を行い、
   前記プロセッサは、
   前記セカンダリ基地局に関する情報を含むハンドオーバ要求を受信した前記ターゲットマスタ基地局から、マスタ基地局変更に関する第１のメッセージを受信する処理と、
   前記第１のメッセージに対する肯定応答である第２のメッセージを前記ターゲットマスタ基地局に送信する処理と、を行い、
   前記第２のメッセージは、前記ユーザ端末との通信のために用いるセキュリティアルゴリズムを示すアルゴリズム情報を含む
   プロセッサ。

Images