(57)【要約】【課題】関連技術の問題の少なくとも１つを解決するソリューションを提供する。【解決手段】ＵＥ１０は潜在的なＳ’ｅＮＢの情報を提供する。その情報は、ＭｅＮＢ２０＿１からＭ’ｅＮＢ２０＿２に転送され、Ｍ’ｅＮＢ２０＿２は、ハンドオーバが起こる前に、Ｍ’ｅＮＢ２０＿２が新たなＳｅＮＢ（Ｓ’ｅＮＢ）を構成できるか、及びどのＳ’ｅＮＢをＭ’ｅＮＢ２０＿２が構成できるかを決定できる。１つのオプションにおいて、ＭｅＮＢ２０＿１は、ＵＥ１０とＳ’ｅＮＢ３０＿１との間の通信保護のための鍵Ｓ’−ＫｅＮＢを導出し、Ｓ’−ＫｅＮＢをＭ’ｅＮＢ２０＿２に送信する。他のオプションにおいて、Ｍ’ｅＮＢ２０＿２は、Ｓ’−ＫｅＮＢを、ＭｅＮＢ２０＿１から受信した鍵ＫｅＮＢ＊から導出する。Ｍ’ｅＮＢ２０＿２は、Ｓ’−ＫｅＮＢをＳ’ｅＮＢ３０＿１に送信する。【選択図】図１
2017085668.tif 000002
【特許請求の範囲】
【請求項１】
ＤＣ（Dual Connectivity）のためのモバイル通信システムであって、
ＵＥ（端末）と、
ＭｅＮＢ（Master eNodeB）と、
ＳｅＮＢ（Secondary eNodeB）と、
ＭＭＥ（Mobility Management Entity）と、
Ｓ−ＧＷ（Serving Gateway）とを備え、
前記ＵＥは前記ＭｅＮＢ及び前記ＳｅＮＢに接続され、
Ｃ−Ｐｌａｎｅ（Control Plane）信号伝送は、前記ＭｅＮＢと前記ＳｅＮＢとの間、及び前記ＭｅＮＢと前記ＭＭＥとの間のインタフェースにより実施され、Ｕ−Ｐｌａｎｅ（User Plane）データは前記Ｓ−ＧＷから前記ＭｅＮＢ及び前記ＳｅＮＢへ送信され、
ソースＭｅＮＢからターゲットＭｅＮＢへのハンドオーバにおいて、
前記ソースＭｅＮＢは、前記ターゲットＭｅＮＢへハンドオーバ要求メッセージ（Handover Request message）を送信し、ハンドオーバ要求確認応答メッセージ（Hanover Request Acknowledge message）を前記ターゲットＭｅＮＢから受信し、ソースＳｅＮＢを解放し、かつ、ＲＲＣコネクションリコンフィギュレーションメッセージ（RRCConnectionReconfiguration message）を前記ＵＥに送信し、かつ、
前記ＵＥはＲＲＣコネクションリコンフィギュレーション完了メッセージ（RRCConnectionReconfigurationComplete message）を前記ターゲットＭｅＮＢへ送信し、かつ、
前記ターゲットＭｅＮＢは、新しいＳｅＮＢのリソースが利用可能な場合に前記ハンドオーバ要求メッセージの受信後に前記新しいＳｅＮＢを追加し、
前記ソースＳｅＮＢの解放後、前記ＵＥ及び前記ソースＳｅＮＢにおいてセキュリティコンテキストが削除されるモバイル通信システム。
【請求項２】
前記ターゲットＭｅＮＢは、前記ＳｅＮＢの追加の際に新たなセキュリティコンテキストを生成する請求項１に記載のモバイル通信システム。
【請求項３】
前記ターゲットＭｅＮＢはパススイッチ要求メッセージ（Path Switch Request message）を前記ＭＭＥに送信し、
前記ＭＭＥはベアラ修正要求メッセージ（Modify Bearer Request message）を前記Ｓ−ＧＷへ送信し、
前記Ｓ−ＧＷはベアラ修正応答メッセージ（Modify Bearer Response message）を前記ＭＭＥへ送信し、かつ、
前記ＭＭＥはパススイッチ要求確認応答メッセージ（Path Switch Request Acknowledge message）を前記ターゲットＭｅＮＢに送信する請求項１に記載のモバイル通信システム。
【請求項４】
少なくともＵＥ（terminal）、ＭｅＮＢ（Master eNodeB）、ＳｅＮＢ（Secondary eNodeB）、ＭＭＥ（Mobility Management Entity）、及びＳ−ＧＷ（Serving Gateway）を含み、前記ＵＥは前記ＭｅＮＢ及び前記ＳｅＮＢに接続され、Ｃ−Ｐｌａｎｅ（Control Plane）信号伝送は前記ＭｅＮＢと前記ＳｅＮＢとの間、及び前記ＭｅＮＢと前記ＭＭＥとの間のインタフェースにより実施され、Ｕ−Ｐｌａｎｅ（User Plane）データは前記Ｓ−ＧＷから前記ＭｅＮＢ及び前記ＳｅＮＢへ送信される、ＤＣ（Dual Connectivity）のためのモバイル通信システムにおける、ソースＭｅＮＢからターゲットＭｅＮＢへハンドオーバする基地局（eNodeB）であって、
前記ソースＭｅＮＢとして機能する前記基地局は、
前記ターゲットＭｅＮＢへハンドオーバ要求メッセージ（Handover Request message）を送信する送信手段と、
ハンドオーバ要求確認応答メッセージ（Hanover Request Acknowledge message）を前記ターゲットＭｅＮＢから受信する受信手段と、
前記ハンドオーバ要求確認応答メッセージ（Hanover Request Acknowledge message）を受信し、ソースＳｅＮＢを解放する制御手段とを有し、
前記ターゲットＭｅＮＢとして機能する前記基地局は、新しいＳｅＮＢのリソースが利用可能な場合に前記ハンドオーバ要求メッセージの受信後に前記新しいＳｅＮＢを追加し、
前記ＵＥは、ＲＲＣコネクションリコンフィギュレーションメッセージ（RRCConnectionReconfiguration message）を前記ソースＭｅＮＢから受信し、ＲＲＣコネクションリコンフィギュレーション完了メッセージ（RRCConnectionReconfigurationComplete message）を前記ターゲットＭｅＮＢへ送信し、
前記ソースＳｅＮＢの解放後、前記ＵＥ及び前記ソースＳｅＮＢにおいてセキュリティコンテキストが削除される基地局。
【請求項５】
前記ターゲットＭｅＮＢは、前記ＳｅＮＢの追加の際に、新たなセキュリティコンテキストを生成する請求項４に記載の基地局。
【請求項６】
前記ターゲットＭｅＮＢはパススイッチ要求メッセージ（Path Switch Request message）を前記ＭＭＥに送信し、
前記ＭＭＥはベアラ修正要求メッセージ（Modify Bearer Request message）を前記Ｓ−ＧＷへ送信し、
前記Ｓ−ＧＷはベアラ修正応答メッセージ（Modify Bearer Response message）を前記ＭＭＥへ送信し、かつ、
前記ＭＭＥはパススイッチ要求確認応答メッセージ（Path Switch Request Acknowledge message）を前記ターゲットＭｅＮＢに送信する請求項４に記載の基地局。
【請求項７】
ＵＥ（端末）、ＭｅＮＢ（Master eNodeB）、ＳｅＮＢ（Secondary eNodeB）、ＭＭＥ（Mobility Management Entity）、及びＳ−ＧＷ（Serving Gateway）を含み、前記ＵＥは前記ＭｅＮＢ及び前記ＳｅＮＢに接続され、Ｃ−Ｐｌａｎｅ（Control Plane）信号伝送は前記ＭｅＮＢと前記ＳｅＮＢとの間、及び前記ＭｅＮＢと前記ＭＭＥとの間のインタフェースにより実施され、Ｕ−Ｐｌａｎｅ（User Plane）データは前記Ｓ−ＧＷから前記ＭｅＮＢ及び前記ＳｅＮＢへ送信される、ＤＣ（Dual Connectivity）のためのモバイル通信システムの方法であって、
ソースＭｅＮＢからターゲットＭｅＮＢへのハンドオーバにおいて、
前記ソースＭｅＮＢは、
前記ターゲットＭｅＮＢへハンドオーバ要求メッセージ（Handover Request message）を送信し、ハンドオーバ要求確認応答メッセージ（Hanover Request Acknowledge message）を前記ターゲットＭｅＮＢから受信し、ソースＳｅＮＢを解放し、かつＲＲＣコネクションリコンフィギュレーションメッセージ（RRCConnectionReconfiguration message）を前記ＵＥに送信し、かつ、
前記ＵＥが、ＲＲＣコネクションリコンフィギュレーション完了メッセージ（RRCConnectionReconfigurationComplete message）を前記ターゲットＭｅＮＢへ送信し、かつ、
前記ターゲットＭｅＮＢは、新しいＳｅＮＢのリソースが利用可能な場合に前記ハンドオーバ要求メッセージの受信後に前記新しいＳｅＮＢを追加し、
前記ソースＳｅＮＢの解放後、前記ＵＥ及びソースＳｅＮＢにおいてセキュリティコンテキストが削除される方法。
【請求項８】
前記ターゲットＭｅＮＢは、前記ＳｅＮＢの追加の際に、新たなセキュリティコンテキストを生成する請求項７に記載の方法。
【請求項９】
さらに、
前記ターゲットＭｅＮＢはパススイッチ要求メッセージ（Path Switch Request message）を前記ＭＭＥに送信し、
前記ＭＭＥはモディファイベアラ要求メッセージ（Modify Bearer Request message）を前記Ｓ−ＧＷへ送信し、
前記Ｓ−ＧＷはモディファイベアラ応答メッセージ（Modify Bearer Response message）を前記ＭＭＥへ送信し、かつ、
前記ＭＭＥはパススイッチ要求確認応答メッセージ（Path Switch Request Acknowledge message）を前記ターゲットＭｅＮＢに送信する請求項７に記載の方法。
【請求項１０】
少なくともＵＥ（terminal）、ＭｅＮＢ（Master eNodeB）とＳｅＮＢ（Secondary eNodeB）ととして機能する基地局、ＭＭＥ（Mobility Management Entity）、及びＳ−ＧＷ（Serving Gateway）を含み、前記ＵＥは前記ＭｅＮＢ及び前記ＳｅＮＢに接続され、Ｃ−Ｐｌａｎｅ（Control Plane）信号伝送は前記ＭｅＮＢと前記ＳｅＮＢとの間、及び前記ＭｅＮＢと前記ＭＭＥとの間のインタフェースにより実施され、Ｕ−Ｐｌａｎｅ（User Plane）データは前記Ｓ−ＧＷから前記ＭｅＮＢ及び前記ＳｅＮＢへ送信される、ＤＣ（Dual Connectivity）のためのモバイル通信システムにおける、ソースＭｅＮＢからターゲットＭｅＮＢへハンドオーバする基地局（eNodeB）の方法であって、
前記ソースＭｅＮＢとして機能する前記基地局は、
前記ターゲットＭｅＮＢへハンドオーバ要求メッセージ（Handover Request message）を送信し、
ハンドオーバ要求確認応答メッセージ（Hanover Request Acknowledge message）を前記ターゲットＭｅＮＢから受信し、
ソースＳｅＮＢを解放し、
前記ターゲットＭｅＮＢとして機能する前記基地局は、新しいＳｅＮＢのリソースが利用可能に前記ハンドオーバ要求メッセージの受信後に前記新しいＳｅＮＢを追加し、
前記ＵＥは、ＲＲＣコネクションリコンフィギュレーションメッセージ（RRCConnectionReconfiguration message）を前記ソースＭｅＮＢから受信し、かつＲＲＣコネクションリコンフィギュレーション完了メッセージ（RRCConnectionReconfigurationComplete message）を前記ターゲットＭｅＮＢへ送信し、
前記ソースＳｅＮＢの解放後、前記ＵＥ及びソースＳｅＮＢにおいてセキュリティコンテキストが削除される方法。
【請求項１１】
前記ターゲットＭｅＮＢは、前記ＳｅＮＢの追加の際に、新たなセキュリティコンテキストを生成する請求項１０に記載の方法。
【請求項１２】
前記ターゲットＭｅＮＢはパススイッチ要求メッセージ（Path Switch Request message）を前記ＭＭＥに送信し、
前記ＭＭＥはモディファイベアラ要求メッセージ（Modify Bearer Request message）を前記Ｓ−ＧＷへ送信し、
前記Ｓ−ＧＷはモディファイベアラ応答メッセージ（Modify Bearer Response message）を前記ＭＭＥへ送信し、かつ、
前記ＭＭＥはパススイッチ要求確認応答メッセージ（Path Switch Request Acknowledge message）を前記ターゲットＭｅＮＢに送信する請求項１０に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＣＥ（Small Cell Enhancement）又はＤＣ（Dual Connectivity）のための装置、システム、及び方法に関し、特に、ＤＣにおけるセキュアなハンドオーバ方法に関する。
【背景技術】
【０００２】
ＳＣＥ又はＤＣは、３ＧＰＰ（3rd Generation Partnership Project）ＲＡＮ（Radio Access Network）ワーキンググループにおいて定義されており、非特許文献１に定義されるアーキテクチャ１Ａに対するセキュリティ局面及び影響の検討が始められた。
【０００３】
ＤＣにおけるＵＥ（User Equipment）は、ＭｅＮＢ（Master eNB (evolved Node B)）及びＳｅＮＢ（Secondary eNB)の双方に接続される。ＤＣアーキテクチャにおいてＭｅＮＢとＭＭＥ（Mobility Management Entity）との間のＳ１−ＭＭＥコネクションは１つのみ存在するため、ハンドオーバはＭｅＮＢのハンドオーバを意味する。非特許文献２−４に記載されるように、ハンドオーバが起こると、ＳｅＮＢは最初に解体されるべきであることが合意される。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TR 36.842, "Study on Small Cell enhancements for E-UTRA and E-UTRAN; Higher layer aspects (Release 12)", V12.0.0, 2013-12
【非特許文献２】S3-140211, 3GPP TSG SA WG3 (Security) Meeting #74
【非特許文献３】S3-140209, 3GPP TSG SA WG3 (Security) Meeting #74
【非特許文献４】S3-140210, 3GPP TSG SA WG3 (Security) Meeting #74
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、本発明者らは、現在のソリューションにおいて、下記１）から３）の問題が存在することを発見した。
【０００６】
１）ハンドオーバにおけるＳｅＮＢ解放
ハンドオーバの間に、ＮｅＮＢがＳｅＮＢ解放プロシージャ（SeNB Release procedure）をどのように実行すべきかのソリューションは存在しない。それを実行するのが早すぎても、遅すぎても、下記に与えられるいくつかの問題が生じる。
ａ．ＳｅＮＢ解放（SeNB Release）が早くすぎる、例えば（ソース）ＭｅＮＢがターゲットＭｅＮＢ（以下では、Ｍ’ｅＮＢとも呼ぶ）にハンドオーバ要求メッセージ（Handover Request message）を送信した直後にＳｅＮＢ解放が起こる場合、Ｍ’ｅＮＢから失敗メッセージが受信されると、ＳｅＮＢ追加プロシージャ（SeNB Addition procedure）を実施することによりＳｅＮＢ（新たな又は同じＳｅＮＢのどちらか。以下、Ｓ’ｅＮＢとも呼ぶ）を構成する必要がある。これは、ＭｅＮＢ、制御プレーン信号伝送、及びカウンタ値増加問題に負担である。
ｂ．ＳｅＮＢ解放が遅すぎ、例えばハンドオーバプロシージャが完了し、ＭｅＮＢとＵＥとの間のベアラが解放された後にＳｅＮＢ解放が起こる場合、ＳｅＮＢを介したパケットデータ送信が続き、Ｍ’ｅＮＢはＳｅＮＢについての知識を持たない。ベアラは継続され、これは資源を消耗し、潜在的なセキュリティ脆弱性に通じる。
【０００７】
２）ハンドオーバにおけるＳｅＮＢ追加
Ｍ’ｅＮＢによってどのようにＳ’ｅＮＢを構成するかのソリューションが存在しない。第１に、Ｓ’ｅＮＢを構成するために、Ｍ’ｅＮＢはどのＳ’ｅＮＢが潜在的に利用可能であるかの知識を持つべきである。そのような情報は、ハンドオーバのためのＵＥ測定報告から取得することが可能である。このようにすることで、ＵＥとの潜在的な相互作用を削減できる。第２に、Ｓ’ｅＮＢ追加がハンドオーバプロシージャにおいて遅すぎるか、又はハンドオーバからかなり遅れて起こると、Ｍ’ｅＮＢは過負荷になり、ＲＲＣ（Radio Resource Control）信号伝送を増加させ得る。
【０００８】
３）ＳｅＮＢに対するセキュリティコンテキスト、及びＳ’ｅＮＢに対する新たなセキュリティコンテキストを含む、ＳｅＮＢ及びＳ’ｅＮＢに対するセキュリティ鍵管理が定義されていない。
【０００９】
従って、本発明の例示的な目的は、上記問題の少なくとも１つを解決するソリューションを提供することである。
【課題を解決するための手段】
【００１０】
本発明は、上記問題に対するソリューションを提案する。本発明の例示的な態様に従う装置、システム、及び方法のそれぞれは、Ｘ２ハンドオーバプロシージャ、及びデュアルコネクティビティを支援するためのセキュリティに対してより詳細を与える。
【００１１】
本発明の第１の例示的な態様によれば、デュアルコネクティビティをサポートするモバイル通信システムが提供される。このシステムは、ソースＭｅＮＢ（Master evolved Node B）と、ソースＳｅＮＢ（Secondary evolved Node B）と、ソースＭｅＮＢ及びソースＳｅＮＢに接続するＵＥ（User Equipment）とを含む。ソースＭｅＮＢは、ソースＭｅＮＢについての情報及びソースＳｅＮＢについての情報を、ハンドオーバ要求においてターゲットＭｅＮＢに送信する。ターゲットＭｅＮＢは、ハンドオーバ要求確認応答（Handover Request Acknowledge）をソースＭｅＮＢに送信する。
【００１２】
本発明の第２の例示的な態様によれば、ソースＭｅＮＢ（Master evolved Node B）及びソースＳｅＮＢ（Secondary evolved Node B）を有するデュアルコネクティビティのための通信方法が提供される。この方法は、ソースＭｅＮＢから、ソースＭｅＮＢについての情報及びソースＳｅＮＢについての情報をハンドオーバ要求においてターゲットＭｅＮＢに送信することと、ハンドオーバ要求確認応答をターゲットＭｅＮＢからソースＭｅＮＢに送信することとを含む。
【００１３】
本発明の第３の例示的な態様によれば、デュアルコネクティビティにおいて使用される基地局が提供される。この基地局は、基地局についての情報、及びデュアルコネクティビティのための第２の基地局についての情報を、ハンドオーバ要求においてターゲット基地局に送信する送信手段と、ハンドオーバ要求確認応答をターゲット基地局から受信する受信手段とを含む。
【００１４】
本発明の第４の例示的な態様によれば、デュアルコネクティビティにおいて使用される基地局が提供される。この基地局は、パススイッチ要求（Path Switch Request）を、ソース第２の基地局についての情報、又はデュアルコネクティビティについての情報をＭＭＥ（Mobility Management Entity）に送信する送信手段を含む。
【発明の効果】
【００１５】
本発明によれば、上記した問題の少なくとも１つを解決することが可能である。
【図面の簡単な説明】
【００１６】
【図１】図１は、本発明の一実施形態に係るシステムの構成例を示すブロック図である。
【図２】図２は、実施形態に係るハンドオーバフローにおけるＳｅＮＢ変化の第１の例を示すフローチャート図である。
【図３】図３は、実施形態に係るハンドオーバフローにおけるＳｅＮＢ変化の第２の例を示すフローチャート図である。
【図４】図４は、実施形態に係るハンドオーバフローにおけるＳｅＮＢ変化の第３の例を示すフローチャート図である。
【図５】図５は、実施形態に係るシステムにおけるＳ’−ＫｅＮＢ導出の一例を示すシーケンス図である。
【図６】図６は、実施形態に係るシステムにおけるＳ’−ＫｅＮＢ導出の他の例を示すシーケンス図である。
【図７】図７は、実施形態に係るハンドオーバプロシージャの一例の一部を示すシーケンス図。
【図８】図８は、実施形態に係るハンドオーバプロシージャの一例の残りの部分を示すシーケンス図。
【図９】図９は、本発明に係るソースＭｅＮＢの構成例を示すブロック図である。
【図１０】図１０は、本発明に係るターゲットＭｅＮＢの構成例を示すブロック図である。
【発明を実施するための形態】
【００１７】
以下、本発明に係る装置、システム、及び方法の実施形態が、図面を伴って記述される。
【００１８】
この実施形態は、以下の仮定に基づく：
１）各ＵＥは、現行のアーキテクチャ（非特許文献１を参照）と同様に、１つのＭｅＮＢと、最大で１つのＳｅＮＢに接続でき、かつ、
２）新たなＳｅＮＢが追加される前にＳｅＮＢ接続が切り離されるＳＡ３同意。
【００１９】
アーキテクチャが図１に図示される。図１に示されるように、この実施形態に係るシステムは、ＵＥ１０と、ＭｅＮＢ２０＿１及び２０＿２と、ＳｅＮＢ３０＿１及び３０＿２と。ＭＭＥ４０と、Ｓ−ＧＷ（Serving Gateway）５０とを含む。
【００２０】
Ｃ−Ｐｌａｎｅ（Control-Plane）信号伝送のためのインタフェースが、ＭＭＥとＭｅＮＢとの間、ＭｅＮＢとＳｅＮＢとの間、及びＭｅＮＢとＵＥとの間に設けられる。なお、Ｃ−Ｐｌａｎｅインタフェースは、ＳｅＮＢとＭＭＥとの間、及びＳｅＮＢとＵＥとの間には存在しない。さらに、Ｕ−Ｐｌａｎｅ（User-Plane）通信のためのインタフェースも、Ｓ−ＧＷと各ｅＮＢとの間、ＭｅＮＢとＳｅＮＢとの間、ＵＥと各ｅＮＢとの間に設けられる。このアーキテクチャにおいて、ＵＥとＳ−ＧＷと間のＵ−Ｐｌａｎｅトラヒックは、ＭｅＮＢをオフロードする目的で（換言すれば、ＭｅＮＢとＳ−ＧＷとの間のバックホールインタフェースをオフロードする目的で）、ＭｅＮＢ及びＳｅＮＢを通じて並列に送信される。
【００２１】
図１において矢印で示されるように、ＵＥ１０はソースＭｅＮＢ２０＿１からターゲットＭｅＮＢ（以下、Ｍ’ｅＮＢと呼ぶ）２０＿２へハンドオーバされ、ハンドオーバの間にＳｅＮＢ３０＿１は新たなＳｅＮＢ（以下、Ｓ’ｅＮＢと呼ぶ）３０＿２に変更される。ＳｅＮＢ３０＿１とＳ’ｅＮＢ３０＿２とが同じノードであり得ても、ＳｅＮＢ３０＿１はＭｅＮＢ２０＿１からまず解放され、次いでＭ’ｅＮＢ２０＿２により構成される必要がある。
【００２２】
下記セクション１から３において、この実施形態の動作例が図２から図８を参照して説明される。
【００２３】
１．ハイレベルハンドオーバフロー（High Level Handover Flow）
この実施形態はＸ２ハンドオーバ（3GPP TS 36.300, Clause 10.1.2.1におけるプロシージャに基づく）を考える。上記したように、この実施形態において、ターゲットｅＮＢはＭ’ｅＮＢで示され、新たに構成されたＳｅＮＢはＳ’ｅＮＢで示される。シナリオは、図２を参照して下記で与えられる。
【００２４】
ソースＭｅＮＢでハンドオーバ決定がなされると、ＭｅＮＢは、ＲＲＣコネクションリコンフィギュレーション（RRC Connection Reconfiguration）及びベアラ修正を含むＳｅＮＢ解放を実施し（3GPP TR 36.842, Annex G.2に記述されるものと同様）、１）ＵＥにＵＬパケットをそれ以上ＳｅＮＢに送信しないことを通知し、２）Ｓ−ＧＷにＤＬパケットをそれ以上ＳｅＮＢに送信しないことを通知する。Ｍ’ｅＮＢは、Ｓ’ｅＮＢのリソースが利用可能であれば、3GPP TR 36.842, Annex G.1におけるＳ’ｅＮＢ追加プロシージャを開始し、新たなＳ’ｅＮＢを構成する。ＳｅＮＢが保持するいかなるパケットについて、ＳｅＮＢはそれらをＭｅＮＢに転送すべきである。ハンドオーバ要求とハンドオーバ要求Ａｃｋは異なるタイミングであり得るため、それらは破線のボックスで示される。
【００２５】
図３及び図４に示されるように、ＳｅＮＢ解放、ＳｅＮＢ追加、及びベアラ修正（Bearer Modification）を実施する他のバリエーションが存在する。
【００２６】
図３に示されるバリエーションにおいて、ＭｅＮＢはＳ−ＧＷへのベアラ修正を先に実施し、次いでＳｅＮＢ解放プロシージャを実施する。
【００２７】
図４に示されるバリエーションにおいて、ＭｅＮＢはベアラ修正、ＳｅＮＢ解放プロシージャ、及びＲＲＣコネクションリコンフィギュレーション（フローチャートに示されず）を同時に実施する。
【００２８】
バリエーションの詳細はセクション３に与えられる。
【００２９】
２．ハンドオーバプロシージャにおける鍵導出
ソースＭｅＮＢにより構成されたＳｅＮＢはソースＭｅＮＢにより解放されるべきであり、新たなＳｅＮＢ（Ｓ’ｅＮＢ）は利用可能であればターゲットＭｅＮＢ（Ｍ’ｅＮＢ）により構成されるべきである。新たな鍵Ｓ−ＫｅＮＢ（Ｓ’−ＫｅＮＢ）はＵＥとＳｅＮＢとの間の通信保護のために導出されるべきである。
【００３０】
Ｓ’ＫｅＮＢ及びカウンタをどのように導出するかについては２つのオプション、すなわちソースにおいて又はターゲットＭｅＮＢにおいて、がある。２つのオプションは、図５及び６に図示される。
【００３１】
なお、ハンドオーバ要求／ハンドオーバ要求Ａｃｋ、ＳｅＮＢ解放及びＳｅＮＢ追加、並びにＲＲＣコネクションリコンフィギュレーションプロシージャは、異なる順序で発生することがあり得、それは次のセクション３で示される。
【００３２】
＜Ｓ’−ＫｅＮＢ導出オプション１＞
図５に示されるように、ＭｅＮＢ２０＿１は、ハンドオーバのためのＫｅＮＢ＊からＳ’−ＫｅＮＢを導出し、ＫｅＮＢ＊に関連するカウンタを生成する（ステップＳ１２）。ＭｅＮＢ２０＿１は、Ｍ’ｅＮＢ２０＿２に鍵及びカウンタを送信し、Ｍ’ｅＮＢ２０＿２はカウンタをキープし、Ｓ’−ＫｅＮＢをＳ’ｅＮＢ３０＿２に送信する（ステップＳ１３、Ｓ１４、及びＳ１７）。ＭｅＮＢ２０＿１は、カウンタ、及びＫＳＩ（Key Set Identifier）を、ＲＲＣコネクションリコンフィギュレーションメッセージにおいてＵＥ１０に送信することができる（ステップＳ１５）。
【００３３】
＜Ｓ’−ＫｅＮＢ導出オプション２＞
図６に示されるように、Ｍ’ｅＮＢ２０＿２は、Ｓ’−ＫｅＮＢを、ＭｅＮＢ２０＿１からハンドオーバ要求メッセージにおいて受信したＫｅＮＢ＊から導出し、ＫｅＮＢ＊に関連するカウンタを生成する（ステップＳ２４）。Ｍ’ｅＮＢ２０＿２は、Ｓ’−ＫｅＮＢをＳ’ｅＮＢ３０＿２に送信する（ステップＳ２７）。Ｍ’ｅＮＢ２０＿２は、カウンタ及びＫＳＩを、ＲＲＣコネクションリコンフィギュレーションメッセージにおいてＵＥ１０に送信する（ステップＳ２５）。
【００３４】
３．ハンドオーバプロシージャ
ＳｅＮＢ解放、ＳｅＮＢ追加、及びベアラ修正は、ハンドオーバプロシージャの間に異なる順序で発生することがあり、この実施形態において、バリエーション及び各ケースのアドバンテージが与えられる。
【００３５】
第１のバリエーションが図７及び図８に示される。ここで、なお、バリエーションはテキストで与えられる。
【００３６】
新たなステップは下記に与えられる。
図７に示されるステップＳ３２において、ＵＥ１０がＭｅＮＢ２０＿１に送信する測定報告（Measurement Reportsの中に、潜在的なＳ’ｅＮＢの測定報告を同様に含める。
【００３７】
ステップＳ３４において、Ｓ’−ＫｅＮＢ導出オプション１と同様に、ＭｅＮＢ２０＿１はＫｅＮＢ＊からＳ’−ＫｅＮＢを導出し、Ｋ＊ｅＮＢに関連するカウンタを生成する。
【００３８】
ステップＳ３５において、ＭｅＮＢ２０は、ハンドオーバ要求に測定報告（オプション１。Ｓ’−ＫｅＮＢ、カウンタ）を含める。なお、ＫｅＮＢ＊もこのメッセージにおいて送信される。カウンタは、Ｍ’ｅＮＢ２０＿２において生成されることもできる。
【００３９】
ステップＳ３６において、Ｍ’ｅＮＢ２０＿２は、アドミッションコントロール（Admission Control）においてＳ’ｅＮＢを構成するかどうか、及びどのＳ’ｅＮＢを構成するかを決定する。
【００４０】
ステップＳ３９において、ＭｅＮＢ２０＿１はＳｅＮＢ解放プロシージャを実施する。ＭｅＮＢ２０＿１及びＳｅＮＢ３０＿１は、所与のＵＥ１０に対するセキュリティコンテキストを削除すべきである。
【００４１】
ステップＳ４０において、ＳｅＮＢ３０＿１は、バッファしたパケットをＭｅＮＢ２０＿１に転送する。
【００４２】
ステップＳ４１において、ＲＲＣコネクションリコンフィギュレーションのメッセージの中で、ＭｅＮＢ２０＿１は、ＵＥ１０が関連するＳｅＮＢセキュリティコンテキストを削除するために、ＵＥ１０にＳｅＮＢ解放について知らせるべきである。Ｓ’−ＫｅＮＢ導出オプション１の場合は、ＭｅＮＢ２０＿１はカウンタ及びＫＳＩも含める。
【００４３】
ステップＳ４２において、ＵＥ１０はＲＲＣコネクションリコンフィギュレーション完了（RRCConnectionReconfiguration Complete）をＭｅＮＢ２０＿１に送信する。
【００４４】
ステップＳ４３において、ＭｅＮＢ２０＿１は、ベアラ修正プロシージャを開始する。ＭｅＮＢ２０＿１は、ＤＲＢ(Data Radio Bearer)情報、ＳｅＮＢＩＤ，及びＳｅＮＢＩＰアドレスを含む、解放されるＳｅＮＢ３０＿１についての詳細を含めるべきである。
【００４５】
ステップＳ４４において、Ｍ’ｅＮＢ２０＿２はＳｅＮＢ追加を開始し、新たなＳｅＮＢ（Ｓ’ｅＮＢ３０＿２）を構成する。これは、図８に示されるステップＳ５１のあとに起こることもでき、前者は既にＳ’ｅＮＢにＭ’ｅＮＢのオフロードを実施させ、後者はＨＯが失敗した場合にリソースを保全することができる。
【００４６】
ステップＳ４５において、Ｓ’−ＫｅＮＢ導出オプション２と同様に、Ｍ’ｅＮＢ２０＿２はＳ’−ＫｅＮＢを導出し、カウンタを生成し、Ｓ’−ＫｅＮＢをＳ’ｅＮＢ３０＿２に送信する。そして、Ｍ’ｅＮＢ２０＿２はＲＲＣコネクションリコンフィギュレーションをＵＥ１０に送信する。
【００４７】
ステップＳ４６において、Ｍ’ｅＮＢ２０＿２は、Ｓ’−ＫｅＮＢ及びＫＳＩを、ＳｅＮＢ追加プロシージャにおけるものと同様は方法でＳ’ｅＮＢ３０＿２に送信する。
【００４８】
ステップＳ４７において、Ｍ’ｅＮＢ２０＿２はＲＲＣコネクションリコンフィギュレーションをＭｅＮＢ２０＿１を介してＵＥ１０に送信する。これは、Ｓ’ｅＮＢ３０＿２が構成されたことをＵＥ１０に通知するためである。Ｓ’−ＫｅＮＢ導出オプション２については、それはカウンタ及びＫＳＩを含む。
【００４９】
図８に示されるステップＳ５２において、Ｍ’ｅＮＢ２０＿２はパススイッチ要求をＭＭＥ４０に送信する。ハンドオーバのパラメータに加えて、メッセージは新たに追加されたＳ’ｅＮＢ情報、すなわちＤＣ構成情報（構成されたＤＲＢ情報、ＳｅＮＢＩＤ，及びＳｅＮＢＩＰアドレスを含む）をも含むべきである。
【００５０】
ステップＳ５３において、ＭＭＥ４０は、ＤＣ構成情報を、ベアラ修正要求においてＳ−ＧＷ５０に転送する。
【００５１】
ＭＭＥ４０（ステップＳ５２のあと）、又はＳ−ＧＷ５０（ステップＳ５４において）は、ｅＮＢ検証を実施し、１）ＭｅＮＢが、所与のＵＥのためにＳｅＮＢを構成することが許可されているかを検証し、２）ＳｅＮＢが有効なネットワーク要素であるかを検証し、３）ＳｅＮＢがデュアルコネクティビティを提供することを許可されているかを検証し、及び、４）これがＤｏＳ（(Denial of Service）アタックであるかを確認する。検証がＭＭＥ４０でなされるとき、それは、ＭＭＥ４０がステップＳ５２のパススイッチ要求メッセージを受信した後でなされるべきである。検証がＳ−ＧＷ５０でなされるとき、それは、ステップＳ５３のベアラ修正要求メッセージがＭＭＥ４０から受信された後に起こるべきである。
【００５２】
＜他のバリエーション＞
上記したように、ハンドオーバの間のＳｅＮＢ解放、ＳｅＮＢ追加の順序は異なる可能性がある。ここで他のバリエーションが記述される。
【００５３】
（バリエーション１）
現行ステップＳ３９のＳｅＮＢ解放は、ステップＳ４３のベアラ修正の後に実施されることができる。
【００５４】
このバリエーションによれば、ＵＥ１０及びＳ−ＧＷ５０は、ＭｅＮＢ２０＿１がＳｅＮＢ解放を実施すると決定したとき、できるだけ通知されることができる。
【００５５】
（バリエーション２）
ステップＳ３９の後、ステップＳ４１とステップＳ４３は、同時に実施可能である。
このバリエーションによれば、更なるパケットが送信されないように、ＵＥ１０及びＳ−ＧＷ５０の双方に間に合うように通知する。
【００５６】
（バリエーション３）
ステップＳ４７のＭ’ｅＮＢ２０＿２からＵＥ１０へのＲＲＣコネクションリコンフィギュレーションは、“古いセルからの切り離し、及び新たなセルとの同期”の後、ＵＥ１０に直接に送信されてもよい。
【００５７】
次いで、図９及び図１０をそれぞれ参照して、ＭｅＮＢ（ソースＭｅＮＢ）２０＿１とＭ’ｅＮＢ（ターゲットＭｅＮＢ）２０＿２の構成例が説明される。
【００５８】
図９に示されるように、ＭｅＮＢ（ソースＭｅＮＢ）２０＿１は、少なくとも送信ユニット１０１と受信ユニット１０２とを含む。送信ユニット１０１は、Ｍ’ｅＮＢ（ターゲットＭｅＮＢ）２０＿２に、ＭｅＮＢ２０＿１についての情報、及びデュアルコネクティビティのためのＳｅＮＢ３０についての情報を、ハンドオーバ要求において送信する。受信ユニット１０２は、Ｍ’ｅＮＢ２０＿２から、ハンドオーバ要求確認応答を受信する。ここで、これらユニット１０２及び１０２は、ＭｅＮＢ２０＿１の他の要素と同様に、少なくとも、Ｍ’ｅＮＢ２０＿２、ＳｅＮＢ３０、ＭＭＥ４０、及びＳ−ＧＷ５０との通信を実施するトランシーバ、ＵＥ１０と無線通信を実施するトランシーバ、及び、それらトランシーバを制御し、図２から図８のそれぞれに示される処理又はそれと等価な処理を実行するＣＰＵ（Central Processing Unit）のようなコントローラなどのハードウェアにより実現されることができる。ＭｅＮＢ２０＿１は、そのようなハードウェアとソフトウェア（例えばメモリに格納されＣＰＵにより実行されるプログラム）の組み合わせにより実現されることができる。さらに、上記したように、ＭｅＮＢ２０＿１は、ＵＥ１０に、ＳｅＮＢ３０の解放についてＲＲＣコネクションリコンフィギュレーションを送信してもよい。
【００５９】
図１０に示されるように、Ｍ’ｅＮＢ（ターゲットＭｅＮＢ）２０＿２は、少なくとも送信ユニット２０１を含む。送信ユニット２０１は、ＭＭＥ４０に、パススイッチ要求を、ＳｅＮＢ３０についての情報又はデュアルコネクティビティについての情報と共に送信する。Ｍ’ｅＮＢ２０＿２は、受信ユニット２０２も含み得る。受信ユニット２０２は、ＭｅＮＢ（ソースＭｅＮＢ）２０＿１から、ＭｅＮＢ２０＿１についての情報及びデュアルコネクティビティのためのＳｅＮＢ３０についての情報を、ハンドオーバ要求において受信する。ここで、これらユニット２０１及び２０１は、Ｍ’ｅＮＢ２０＿２の他の要素も同様に、少なくとも、ＭｅＮＢ２０＿１、ＳｅＮＢ３０、ＭＭＥ４０、及びＳ−ＧＷ５０との通信を実施するトランシーバ、ＵＥ１０と無線通信を実施するトランシーバ、及び、それらトランシーバを制御し、図２から図８のそれぞれに示される処理又はそれと等価な処理を実行するＣＰＵのようなコントローラなどのハードウェアにより実現されることができる。Ｍ’ｅＮＢ２０＿２は、そのようなハードウェアとソフトウェア（例えばメモリに格納されＣＰＵにより実行されるプログラム）の組み合わせにより実現されることができる。
【００６０】
なお、本発明は上記した実施形態には限定されず、特許請求の範囲の規定に基づいて当業者によって種々の変更がなされ得ることは自明である。
【００６１】
上記で説明された実施形態の全部又は一部は、下記の付記のように記述され得るが、これには限定されない。
【００６２】
（付記１）
測定報告に含まれる潜在的なＳ’ｅＮＢ情報を提供するＵＥであって、
その情報は、ハンドオーバが起こる前にＭ’ｅＮＢが新たなＳｅＮＢ（Ｓ’ｅＮＢ）を構成するか否か、及びどのＳ’ｅＮＢをＭ’ｅＮＢが構成するかを決定可能とするために、ＭｅＮＢからＭ’ｅＮＢへ転送され得る。
【００６３】
（付記２）
鍵Ｓ’−ＫｅＮＢが、
ａ）オプション１として、ＨＯ決定の後、ＭｅＮＢはＳ’−ＫｅＮＢを導出し、ハンドオーバ要求メッセージにおいてＳ’−ＫｅＮＢをＭ’ｅＮＢに送信する。これは、鍵ＫｅＮＢ＊は既に導出され、そのメッセージにおいて送信されているからであり、ＭｅＮＢは、ＫｅＮＢ＊からＳ’−ＫｅＮＢを導出でき、Ｓ’−ＫｅＮＢを同じメッセージで送信できる。または、
ｂ）オプション２として、ＭｅＮＢはＭ’ｅＮＢにＳ’ｅＮＢについての測定報告をハンドオーバ要求メッセージにおいて通知し、それによってＭ’ｅＮＢはどのＳ’ｅＮＢが構成できるかを知ることができ、Ｍ’ｅＮＢはＳ’ｅＮＢ追加プロシージャを実施し、Ｓ’−ＫｅＮＢをＭｅＮＢから受信したＫｅＮＢ＊から導出し、カウンタを生成してＳ’−ＫｅＮＢをＳ’ｅＮＢに送信する。
ことによって導出されるシステム
【００６４】
（付記３）
システムであって、そのシステムにおいてＳｅＮＢ解放及びベアラ修正が、
ａ）ＳｅＮＢ解放は、ＳｅＮＢ及びＵＥが通信を継続することができず、従ってＭ’ｅＮＢにおいてＳｅＮＢが構成されないためにパケットロスが抑制できるように、ＭｅＮＢがＭ’ｅＮＢからハンドオーバ要求Ａｃｋを受信したとき実施することができ、又は、
ｂ）ＳｅＮＢ解放は、Ｓ−ＧＷ及びＵＥが、パケットを送信することを抑制しかつパケットロスをも抑制するために、ＳｅＮＢについてちょうどよいときに通知されることが可能となるように、ベアラ修正の後又はそれと同時に実施することができる。
として実施されるシステム。
【００６５】
（付記４）
ハンドオーバが完了しＳｅＮＢが切り離されたことを確実にするために、ハンドオーバ要求Ａｃｋの後、Ｓ’ｅＮＢ追加プロシージャを実施するＭ’ｅＮＢ。
【００６６】
（付記５）
ＭＭＥ又はＳ−ＧＷが、ＳｅＮＢ追加に対してＭ’ｅＮＢ及びＳ’ｅＮＢ検証を実施するシステム。
【００６７】
（付記６）
ＲＲＣコネクションリコンフィギュレーションプロシージャが、現行のプロシージャから新たなプロシージャに変更されるシステムであって、
現行のプロシージャは、ソースｅＮＢからＵＥへ及びＵＥからターゲットｅＮＢへのラウンドトリップを有し、
新たなプロシージャは、ＵＥがＳｅＮＢ解放とＳ’ｅＮＢ追加について通知される必要があるため、ソースＭｅＮＢとＵＥとの間のラウンドトリップ、及びＭ’ｅＮＢとＵＥとの間のラウンドトリップを有する。
【００６８】
（付記７）
アップデートパススイッチ要求メッセージ（Update Path Switch Request message）が、新たに構成されたＳ’ｅＮＢの情報、すなわちＤＣ構成情報（構成されたＤＢＲ情報、ＳｅＮＢＩＤ，及びＳｅＮＢＩＰアドレスを含む）を運ぶシステム。
【００６９】
本願は、２０１４年３月１０日に提出された日本特許出願２０１４−０４６１５８に基づき、かつ優先権の利益を主張するものであり、その日本特許出願の開示は、参照として組み込まれる。
【符号の説明】
【００７０】
１０    ＵＥ
２０    ＭｅＮＢ
３０    ＳｅＮＢ
４０    ＭＭＥ
５０    Ｓ−ＧＷ
１０１、２０１    送信ユニット
１０２、２０２    受信ユニット
【図１】
2017085668.tif 000003
【図２】
2017085668.tif 000004
【図３】
2017085668.tif 000005
【図４】
2017085668.tif 000006
【図５】
2017085668.tif 000007
【図６】
2017085668.tif 000008
【図７】
2017085668.tif 000009
【図８】
2017085668.tif 000010
【図９】
2017085668.tif 000011
【図１０】
2017085668.tif 000012