(57)【特許請求の範囲】
【請求項１】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するための方法であって、前記方法は前記ＵＥ（１）によって実行され、前記方法は、
前記ターゲットｅＮＢ（３）からＲＲＣ接続再確立メッセージを受信すること（Ｓ１００）であって、前記ＲＲＣ接続再確立メッセージは、モビリティ管理エンティティ（４）によって生成され、入力として非アクセス層保全性鍵を有するダウンリンク（ＤＬ）認証トークンを含む、ことと、
前記受信したＤＬ認証トークンを認証すること（Ｓ１１０）を含む、方法。
【請求項２】
請求項１に記載の方法であって、入力として前記非アクセス層保全性鍵を用いてアップリンク（ＵＬ）認証トークンを計算することと、前記ＵＬ認証トークンを含むＲＲＣ接続再確立要求を前記ターゲットｅＮＢ（３）に送信することを含む、方法。
【請求項３】
請求項２に記載の方法であって、前記ＵＬ認証トークンは、入力としてターゲットセルの識別子を用いて計算される、方法。
【請求項４】
請求項３に記載の方法であって、前記ＲＲＣ接続再確立要求に前記ターゲットセルの識別子を含める、方法。
【請求項５】
請求項１に記載の方法であって、前記ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いて前記モビリティ管理エンティティ（４）により計算されている、方法。
【請求項６】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するための方法であって、前記方法は前記ターゲットｅＮＢ（３）によって実行され、前記方法は、
モビリティ管理エンティティ（ＭＭＥ）（４）から、前記ＭＭＥによって生成されたダウンリンク（ＤＬ）認証トークンを含むメッセージを受信すること（Ｓ３００）であって、前記ＤＬ認証トークンは入力として非アクセス層保全性鍵を用いて生成されている、ことと、
ＲＲＣ接続再確立メッセージを前記ＵＥ（１）に送信すること（Ｓ３１０）であって、前記ＲＲＣ接続再確立メッセージは前記ＤＬ認証トークンを含むこと、を含む方法。
【請求項７】
請求項６に記載の方法であって、前記ＵＥ（１）からアップリンク（ＵＬ）認証トークンを含むＲＲＣ接続再確立要求を受信することであって、前記ＵＬ認証トークンは入力として前記非アクセス層保全性鍵を用いて前記ＵＥによって計算されていること、を含む方法。
【請求項８】
請求項７に記載の方法であって、前記ＵＬ認証トークンは、入力としてターゲットセルの識別子を用いて前記ＵＥ（１）により計算されている、方法。
【請求項９】
請求項６に記載の方法であって、前記ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いて前記ＭＭＥ（４）により計算されている、方法。
【請求項１０】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するための方法であって、前記方法はモビリティ管理エンティティ（ＭＭＥ）（４）によって実行され、前記方法は、
入力としてターゲットセルの識別子を用いてダウンリンク（ＤＬ）認証トークンを生成すること（Ｓ４００）と、
前記生成したＤＬ認証トークンを含むメッセージを前記ターゲットｅＮＢ（３）へ送信すること（Ｓ４１０）を含む、方法。
【請求項１１】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するための方法であって、前記方法はモビリティ管理エンティティ（ＭＭＥ）（４）によって実行され、前記方法は、
入力として非アクセス層保全性鍵を用いてダウンリンク（ＤＬ）認証トークンを生成すること（Ｓ４００）と、
前記生成したＤＬ認証トークンを含むメッセージを前記ターゲットｅＮＢ（３）へ送信すること（Ｓ４１０）と、
アップリンク（ＵＬ）認証トークンを前記ターゲットｅＮＢから受信することであって、前記ＵＬ認証トークンは、入力として前記非アクセス層保全性鍵を用いて前記ＵＥ（１）により生成されている、ことと、
前記認証トークンを検証することを含む、方法。
【請求項１２】
請求項１１に記載の方法であって、前記ＵＬ認証トークンは、入力としてターゲットセルの識別子を用いて前記ＵＥ（１）により生成されている、方法。
【請求項１３】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するための前記ＵＥ（１）あって、前記ＵＥ（１）は、
プロセッサ（１０）と、
命令を格納するコンピュータプログラム製品（１２、１３）を有し、前記命令は前記プロセッサにより実行された場合に、前記ＵＥに、
前記ターゲットｅＮＢ（３）からＲＲＣ接続再確立メッセージを受信させ、ここで前記ＲＲＣ接続再確立メッセージは、モビリティ管理エンティティ（ＭＭＥ）（４）によって生成され、入力として非アクセス層保全性鍵を有するダウンリンク（ＤＬ）認証トークンを含み、
受信したＤＬ認証トークンを認証させる、ＵＥ。
【請求項１４】
請求項１３に記載のＵＥであって、前記ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いて前記モビリティ管理エンティティ（４）により計算されている、ＵＥ。
【請求項１５】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するための前記ターゲットｅＮＢであって、前記ターゲットｅＮＢ（３）は、
プロセッサ（３０）と、
命令を格納するコンピュータプログラム製品（３２、３３）を有し、前記命令は前記プロセッサにより実行された場合に、前記ターゲットｅＮＢに、
モビリティ管理エンティティ（ＭＭＥ）（４）から、前記ＭＭＥによって生成されたダウンリンク（ＤＬ）認証トークンを含むメッセージを受信させ、ここで、前記ＤＬ認証トークンは入力として非アクセス層保全性鍵を用いて生成されており、
ＲＲＣ接続再確立メッセージを前記ＵＥ（１）に送信させ、ここで、前記ＲＲＣ接続再確立メッセージは前記ＤＬ認証トークンを含む、ターゲットｅＮＢ。
【請求項１６】
請求項１５に記載のターゲットｅＮＢ（３）であって、前ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いて前記ＭＭＥ（４）により計算されている、ターゲットｅＮＢ。
【請求項１７】
ユーザ装置（ＵＥ）（１）とターゲットｅＮＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するためのソース進化型ノードＢ（ソースｅＮＢ）（２）であって、前記ソースｅＮＢ（２）は、
プロセッサ（２０）と、
命令を格納するコンピュータプログラム製品（２２、２３）を有し、前記命令は前記プロセッサにより実行された場合に、前記ソースｅＮＢに、
入力として非アクセス層保全性鍵を用いて生成されているダウンリンク（ＤＬ）認証トークンを取得させ、
応答メッセージを前記ターゲットｅＮＢ（３）へ送信させ、前記応答メッセージは前記取得したＤＬ認証トークンを含む、ソースｅＮＢ。
【請求項１８】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するためのコンピュータプログラム（１４、１５）であって、前記コンピュータプログラムは、前記ＵＥ（１）上で実行されると、前記ＵＥに、
前記ターゲットｅＮＢ（３）からＲＲＣ接続再確立メッセージを受信させ（Ｓ１００）、ここで前記ＲＲＣ接続再確立メッセージは、移動管理エンティティ（ＭＭＥ）（４）によって生成され、入力として非アクセス層保全性鍵を有するダウンリンク（ＤＬ）認証トークンを含み、
受信したＤＬ認証トークンを認証させる（Ｓ１１０）、コンピュータプログラムコードを含む、コンピュータプログラム。
【請求項１９】
ユーザ装置（ＵＥ）（１）とターゲット進化型ノードＢ（ターゲットｅＮＢ）（３）との間の無線リソース制御（ＲＲＣ）接続を再確立するためのコンピュータプログラム（３４、３５）であって、前記コンピュータプログラムは、前記ターゲットｅＮＢ（３）上で実行されると、前記ターゲットｅＮＢに、
モビリティ管理エンティティ（ＭＭＥ）（４）から、前記ＭＭＥによって生成されたダウンリンク（ＤＬ）認証トークンを含むメッセージを受信させ、ここで、前記ＤＬ認証トークンは入力として非アクセス層保全性鍵を用いて生成されており、
ＲＲＣ接続再確立メッセージを前記ＵＥ（１）に送信させ、ここで、前記ＲＲＣ接続再確立メッセージは前記ＤＬ認証トークンを含む、コンピュータプログラムコードを含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線リソース制御接続を再確立するための方法、ユーザ装置、ソースノードＢ、ターゲットノードＢ、モビリティ管理エンティティ、コンピュータプログラム、およびコンピュータプログラム製品に関する。
【背景技術】
【０００２】
制御プレーン（ＣＰ）セルラーインターネットオブシングス（ＣＩｏＴ）の最適化（非アクセス層（ＮＡＳ）を介したデータ（ＤｏＮＡＳ）とも呼ばれる）は、第３世代パートナーシッププロジェクト（３ＧＰＰ）の技術仕様であるTS 23.401 V14.2.0, 5.3.4B節（および他の仕様、例えばTS 23.301, V14.2.0）で規定されているＮＡＳを介したデータを転送するためのソリューションである。セキュリティ機能はTS 33.401 V14.1.0, 8.2節に規定されている。基本ソリューションのセキュリティへの影響は非常に限られている。ＤｏＮＡＳ機能の目的は、データ無線ベアラ（ＤＲＢ）を確立せずに、またアクセス層（ＡＳ）セキュリティを確立せずに、ＮＡＳシグナリングを介してデータを送信することである。その意図はシグナリングを節約することである。TS23.401の図5.3.4B.2-1に対応する図１は、ＤｏＮＡＳの原理を示している。
【０００３】
３ＧＰＰ文書R3-161324の作業項目は、CP CIoTのためのモビリティ強化について考察している。ハンドオーバはCP CIoTではサポートされていないが、ユーザ装置（ＵＥ）は常に移動し、ＵＥが接続モードにあるとき（すなわち、進化型ノードＢ（ｅＮＢ）に対して無線リソース制御（ＲＲＣ）接続しているとき）無線リンク障害（ＲＬＦ）を引き起こす可能性がある。これはそのような場合に何をすべきかの問題を提起した。ＡＳセキュリティはCP CIoT機能ではサポートされていないため、ＲＬＦの既存のメカニズムをそのままでは安全に使用できない。言い換えれば、CP CIoTで既存のＲＬＦ処理メカニズムを使用することは、セキュリティ面で容認できない。
【０００４】
ＲＲＣレイヤは現在のＬＴＥ（ロングタームエボリューション）システムにある。 例えば、3GPP TS36.331 V14.1.0は、例えばＲＲＣ接続再確立手順の間にＵＥの識別に使用されるShortMAC-Iと呼ばれる情報要素（ＩＥ）を含むように規定されている。ShortMAC-Iの計算には、入力として次のものが含まれる。
・ＲＲＣ保全性鍵（integrity key）：ビット文字列（サイズ（128））
・ターゲットセルの識別子（identity）：ビット文字列（サイズ（28））
・ソースセルの物理セル識別子：整数（0…503）
・ソースセルにおけるＵＥのＣ−ＲＮＴＩ（セル無線ネットワーク一時識別子）：ビット文字列（サイズ（16））
【０００５】
使用される機能はTS 33.401 V14.1.0に規定されている。
【０００６】
ＲＲＣレイヤは、ＬＴＥシステムでは、例えばＲＲＣ接続再開手順中にＵＥの識別に使用されるShortResumeMAC-Iと呼ばれる情報要素（ＩＥ）を含むように指定されている。ShortResumeMAC-Iの計算には、入力として次のものが含まれる。
・ＲＲＣ保全性鍵：ビット文字列（サイズ（128））
・ターゲットセルの識別子：ビット文字列（サイズ（28））
・ソースセルの物理セル識別子：整数（0…503）
・ソースセルにおけるＵＥのＣ−ＲＮＴＩ：ビット文字列（サイズ（16））
・再開定数（Resume constant）
【０００７】
ShortResumeMAC-Iの計算には、ResumeShortMAC-IからShortMAC-Iを区別できるようにする再開定数が追加で含まれている。 使用される機能=は、TS 33.401 V 14.1.0に規定されている。
【発明の概要】
【０００８】
本発明の目的は、無線リソース制御接続の再確立中にシグナリングの削減を可能にする  ことである。
【０００９】
本発明の別の目的は、ＲＲＣ接続再確立中にＵＥによるターゲットｅＮＢの認証を可能にすることである。
【００１０】
本発明の第１の態様によれば、ユーザ装置（ＵＥ）とターゲット進化型（evolved）ノードＢ（ターゲットｅＮＢ）との間の無線リソース制御（ＲＲＣ）接続を再確立するための方法が提示される。方法はＵＥにより実行され、当該方法は、
ターゲットｅＮＢからＲＲＣ接続再確立メッセージを受信することであって、当該ＲＲＣ接続再確立メッセージは、モビリティ管理エンティティ（ＭＭＥ）によって生成され、入力として非アクセス層（ＮＡＳ）保全性鍵を有するダウンリンク（ＤＬ）認証トークンを含む、ことと、
受信したＤＬ認証トークンを認証することを含む。
【００１１】
これによって、とりわけ、ＥＰＳ ＣＰ ＩｏＴ最適化のためのＲＲＣ接続再確立などのＲＲＣ接続再確立中に、ＵＥがＮＡＳ保全性鍵を用いてｅＮＢを認証することが可能になることが達成される。したがって、アクセス層（ＡＳ）鍵を作成する必要はなく、これは、例えばＮＡＳ鍵はいずれにせよ生成されなければならないが、ＡＳ鍵はＲＲＣ接続再確立で使用されるためだけに生成されなければならないという点で非常に有益である。
【００１２】
方法はまた、入力としてＮＡＳ保全性鍵を用いてアップリンク（ＵＬ）認証トークンを計算するステップと、ＵＬ認証トークンを含むＲＲＣ接続再確立要求をターゲットｅＮＢに送信することとを含み得る。その場合、ＵＬ認証トークンは、ターゲットセルの識別子を入力として計算され得る。後者の場合、ターゲットセルの識別子は、ＲＲＣ接続再確立要求に含まれてもよい。
【００１３】
本方法の一実施形態では、ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いてＭＭＥによって計算されてもよい。
【００１４】
ＲＲＣ接続再確立メッセージは、Input-MAC CIoT DLを含み得る。受信されたＤＬ認証トークンを認証することは、Input-MAC CIoT DLおよび非アクセス層保全性鍵を使用することによって行われ得る。Input-MAC CIoT DLは、ターゲットセルの識別子を含み得る。
【００１５】
第２の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法に関し、ターゲットｅＮＢによって実行される。方法は、 
ＭＭＥから、ＭＭＥによって生成されたＤＬ認証トークンを含むメッセージを受信ことであって、当該ＤＬ認証トークンは、入力としてＮＡＳ保全性鍵を用いて生成されている、ことと、
ＲＲＣ接続再確立メッセージを前記ＵＥへ送信することであって、当該ＲＲＣ接続再確立メッセージは当該ＤＬ認証トークンを含むことを含む。
【００１６】
第２の態様の実施形態では、方法は、ＵＥから、アップリンク（ＵＬ）認証トークンを含むＲＲＣ接続再確立要求を受信することであって、当該ＵＬ認証トークンは入力として非アクセス層保全性鍵を用いてＵＥによって計算されていること、を含む。当該ＵＬ認証トークンは、入力としてターゲットセルの識別子を用いてＵＥによって計算されてもよい。
【００１７】
第２の態様の実施形態では、ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いてＭＭＥにより計算されている。
【００１８】
第２の態様の実施形態では、ＲＲＣ接続再確立メッセージは、Input MAC CIoT DLを含む。
【００１９】
受信したメッセージは、Patch Switch Request Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。受信したメッセージは、代替的に、Check MAC Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。
【００２０】
第３の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法に関し、当該方法はソースｅＮＢによって実行される。方法は、
入力としてＮＡＳ保全性鍵を用いて生成されているＤＬ認証トークンを取得することと、
応答メッセージを前記ターゲットｅＮＢへ送信することであって、当該応答メッセージは取得したＤＬ認証トークンを含む、ことを含む。
【００２１】
当該取得することは、第３の態様の実施形態では、認証トークンを生成すること、または、ＭＭＥから S1 Check responseメッセージ（Ｓ１チェック応答メッセージ）を受信することを含み、当該受信したS1 Check responseメッセージは、ＤＬ認証トークンおよび／またはInput-MAC CIoT DLを含む。
【００２２】
応答メッセージは、第３の態様の実施形態では、 X2 UE Context responseメッセージ （Ｘ２  ＵＥ  コンテキスト応答メッセージ）である。
【００２３】
第４の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法に関し、当該方法はＭＭＥによって実行される。方法は、
入力としてＮＡＳ保全性鍵を用いてＤＬ認証トークンを生成することと、
生成したＤＬ認証トークンを含むメッセージをターゲットｅＮＢへ送信することを含む。
【００２４】
第４の態様の実施形態では、ＤＬ認証トークンの生成は、（ＮＡＳ保全性鍵に追加して）入力としてターゲットセルの識別子を用いてなされる。
【００２５】
第４の態様による方法は、
ＵＬ認証トークンをターゲットｅＮＢから受信することであって、当該ＵＬ認証トークンは、入力として非アクセス層保全性鍵を用いてＵＥより生成されている、ことと、
認証トークンを検証することを含む。
【００２６】
ＵＬ認証トークンは、入力としてターゲットセルの識別子を用いてＵＥによって計算されていても良い。
【００２７】
メッセージは、Path Switch Request Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。方法は、別の実施形態では、Check MAC Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。
【００２８】
本発明の第５の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのＵＥに関する。ＵＥは、
プロセッサと、当該プロセッサにより実行された場合に、当該ＵＥに、
ターゲットｅＮＢからＲＲＣ接続再確立メッセージを受信させ、ここで、当該ＲＲＣ接続再確立メッセージは、ＭＭＥによって生成され、入力としてＮＡＳ保全性鍵を有するダウンリンクＤＬ認証トークンを含み、
受信したＤＬ認証トークンを認証させる、ための命令を格納するコンピュータプログラム製品とを有する。
【００２９】
ＵＥの実施形態では、ＲＲＣ接続再確立メッセージは、Input-MAC CIoT DLを含み、受信したＤＬ認証トークンは、Input-MAC CIoT DLと非アクセス層保全性鍵とを使用することにより認証される。
【００３０】
ＵＥの実施形態では、ＤＬ認証トークンは、入力としてターゲットセルの識別子を用いてＭＭＥにより計算されている。
【００３１】
第６の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのターゲットｅＮＢに関する。当該ターゲットｅＮＢは、
プロセッサと、
当該プロセッサにより実行された場合に、当該ターゲットｅＮＢに、
ＭＭＥから、ＭＭＥによって生成されたＤＬ認証トークンを含むメッセージを受信させ、ここで、当該ＤＬ認証トークンは、入力としてＮＡＳ保全性鍵を用いて生成されており、
ＲＲＣ接続再確立メッセージをＵＥに送信させ、ここで、当該ＲＲＣ接続再確立メッセージはＤＬ認証トークンを含む、ための命令を格納するコンピュータプログラム製品とを有する。
【００３２】
ＤＬ認証トークンは、ターゲットｅＮＢの実施形態では、入力としてターゲットセルの識別子を用いてＭＭＥによって計算されてもよい。
【００３３】
ターゲットｅＮＢの実施形態では、ＲＲＣ接続再確立メッセージは、Input MAC CIoT DL、すなわち、ＤＬ認証トークンの生成に対する入力を含む。
【００３４】
ターゲットｅＮＢの実施形態では、受信したメッセージは、Patch Switch Request Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。
【００３５】
受信したメッセージは、別の実施形態では、Check MAC Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。
【００３６】
第７の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのソースｅＮＢに関する。ソースｅＮＢは、
プロセッサと、
当該プロセッサにより実行された場合に、当該ソースｅＮＢに、
入力として非アクセス層保全性鍵を用いて生成されているＤＬ認証トークンを取得させ、
応答メッセージをターゲットｅＮＢへ送信させ、ここで、当該応答メッセージは取得されたＤＬ認証トークンを含む、ための命令を格納するコンピュータプログラム製品とを有する。
【００３７】
応答メッセージは、ソースｅＮＢの実施形態では、 X2 UE Context responseメッセージ（Ｘ２  ＵＥ  コンテキスト応答メッセージ）である。
【００３８】
第８の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのＭＭＥに関する。当該ＭＭＥは、
プロセッサと、
当該プロセッサにより実行された場合に、当該ＭＭＥに、
入力としてＮＡＳ保全性鍵を用いてＤＬ認証トークンを生成させ、
生成したＤＬ認証トークンを含むメッセージをターゲットｅＮＢへ送信する、ための命令を格納するコンピュータプログラム製品とを有する。
【００３９】
メッセージは、ＭＭＥの実施形態ではPath Switch Request Acknowledgeメッセージであっても良く、当該メッセージは、本実施形態ではInput-MAC CIoT DLを含んでも良い。
【００４０】
ＭＭＥの別の実施形態では、メッセージは、Check MAC Acknowledgeメッセージである。当該メッセージは、その場合、Input-MAC CIoT DLを含む。
【００４１】
第９の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのＵＥに関する。当該ＵＥは、
ターゲットｅＮＢからＲＲＣ接続再確立メッセージを受信するための通信マネージャーであって、当該ＲＲＣ接続再確立メッセージは、ＭＭＥによって生成され、入力としてＮＡＳ保全性鍵を有するＤＬ認証トークンを含む、通信マネージャーと、
当該受信したＤＬ認証トークンを認証するための判定マネージャーとを有する。
【００４２】
第１０の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのターゲットｅＮＢに関する。当該ターゲットｅＮＢは、
ＭＭＥから、当該ＭＭＥによって生成されたＤＬ認証トークンを含むメッセージを受信し、ＲＲＣ接続再確立メッセージをＵＥへ送信するための通信マネージャーであって、当該ＤＬ認証トークンは入力としてＮＡＳ保全性鍵を用いて生成されており、当該ＲＲＣ接続再確立メッセージはＤＬ認証トークンを含む、通信マネージャーを有する。
【００４３】
第１１の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのソースｅＮＢに関する。当該ソースｅＮＢは、
入力としてＮＡＳ保全性鍵を用いて生成されているＤＬ認証トークンを取得するための判定マネージャーと、
応答メッセージを当該ターゲットｅＮＢへ送信するための通信マネージャーであって、当該応答メッセージは当該取得したＤＬ認証トークンを含む、通信マネージャーとを有する。
【００４４】
第１２の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのＭＭＥに関する。当該ＭＭＥは、
入力としてＮＡＳ保全性鍵を用いてＤＬ認証トークンを生成するための判定マネージャーと、
当該生成したＤＬ認証トークンを含むメッセージを当該ターゲットｅＮＢへ送信するための通信マネージャーとを有する。
【００４５】
第１３の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのコンピュータプログラムに関する。当該コンピュータプログラムは、ＵＥ上で実行された場合に、ＵＥに、
ターゲットｅＮＢからＲＲＣ接続再確立メッセージを受信させ、ここで、当該ＲＲＣ接続再確立メッセージは、ＭＭＥによって生成され、入力としてＮＡＳ層保全性鍵を有するＤＬ認証トークンを含み、
受信したＤＬ認証トークンを認証させる、コンピュータプログラムコードを含む。
【００４６】
第１４の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのコンピュータプログラムに関する。コンピュータプログラムは、ターゲットｅＮＢ上で実行された場合に、当該ターゲットｅＮＢに、
ＭＭＥから、ＭＭＥによって生成されたＤＬ認証トークンを含むメッセージを受信させ、ここで、当該ＤＬ認証トークンは、入力としてＮＡＳ保全性鍵を用いて生成されており、
ＲＲＣ接続再確立メッセージをＵＥに送信させ、ここで、当該ＲＲＣ接続再確立メッセージはＤＬ認証トークンを含む、コンピュータプログラムコードを含む。
【００４７】
第１５の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのコンピュータプログラムに関する。当該コンピュータプログラムは、ソースｅＮＢ上で実行された場合に、ソースｅＮＢに、
入力としてＮＡＳ保全性鍵を用いて生成されているＤＬ認証トークンを取得させ、
応答メッセージをターゲットｅＮＢへ送信させ、ここで、当該応答メッセージは取得したＤＬ認証トークンを含む、コンピュータプログラムコードを含む。
【００４８】
第１６の態様は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのコンピュータプログラムに関する。コンピュータプログラムは、ＭＭＥ上で実行された場合に、当該ＭＭＥに、
入力としてＮＡＳ保全性鍵を用いてＤＬ認証トークンを生成させ、
生成したＤＬ認証トークンを含むメッセージをターゲットｅＮＢへ送信させる、コンピュータプログラムコードを含む。
【００４９】
第１７の態様は、第１３から１６の態様によるコンピュータプログラムの少なくとも１つを含むコンピュータプログラム製品、および、当該少なくとも１つのコンピュータプログラムが格納されているコンピュータ可読記憶手段に関する。
【００５０】
全ての第１７の態様では、ＲＲＣ接続に対する再確立は、制御プレーンインターネットオブシングスの最適化に対するものであり得る。
【００５１】
一般に、実施形態の箇条書きリストで使用されるすべての用語は、本明細書で他に明示的に定義されない限り、技術分野におけるそれらの通常の意味に従って解釈されるべきである。「要素、装置、構成要素、手段、ステップなど」に対するすべての参照は、他に明示的に述べられていない限り、要素、装置、構成要素、手段、ステップなどの少なくとも１つの例を指すものとして公然と解釈されるべきである。本明細書に開示された任意の方法のステップは、明示的に述べられていない限り、開示された正確な順序で実行される必要はない。
【図面の簡単な説明】
【００５２】
添付の図面を参照しながら、例として本発明を説明する。
【図１】図１は、ＤｏＮＡＳ原理シグナリングを概略的に示す。
【図２】図２は、本明細書に提示された実施形態を適用することができる環境を概略的に示す。
【図３ａ】図３ａは、本明細書に提示される実施形態の一部によるシグナリングを概略的に示す。
【図３ｂ】図３ｂは、本明細書に提示され図３ａから開始される一実施形態の一部によるシグナリングを概略的に示す。
【図４ａ】図４ａは、本明細書に提示される実施形態の一部によるシグナリングを概略的に示す。
【図４ｂ】図４ｂは、本明細書に提示され図４ａで開始された実施形態の一部によるシグナリングを概略的に示す。
【図５】図５は、本明細書に提示された実施形態によるシグナリングを概略的に示す。
【図６】図６は、本明細書に提示された実施形態によるシグナリングを概略的に示す。
【図７Ａ】図７Ａは、本明細書に提示された実施形態による方法を示すフローチャートである。
【図７Ｂ】図７Ｂは、本明細書に提示された実施形態による方法を示すフローチャートである。
【図７Ｃ】図７Ｃは、本明細書に提示された実施形態による方法を示すフローチャートである。
【図７Ｄ】図７Ｄは、本明細書に提示された実施形態による方法を示すフローチャートである。
【図８】図８は、本明細書に提示されるエンティティのいくつかの構成要素を示す概略図である。
【図９】図９は、本明細書に提示されるエンティティのいくつかの構成要素を示す概略図である。
【図１０】図１０は、本明細書に提示されるエンティティのいくつかの構成要素を示す概略図である。
【図１１】図１１は、本明細書に提示されるエンティティのいくつかの構成要素を示す概略図である。
【図１２】図１２は、本明細書に提示される実施形態の機能モジュールを示す概略図である。
【図１３】図１３は、本明細書に提示される実施形態の機能モジュールを示す概略図である。
【図１４】図１４は、本明細書に提示される実施形態の機能モジュールを示す概略図である。
【図１５】図１５は、本明細書に提示される実施形態の機能モジュールを示す概略図である。
【発明を実施するための形態】
【００５３】
本発明の特定の実施形態が示されている添付の図面を参照しながら、本発明を以下でより十分に説明する。しかしながら、本発明は、多くの異なる形態で具体化することができ、そして本明細書に記載の実施形態に限定されると解釈されるべきではない。むしろ、これらの実施形態は、この開示が徹底的かつ完全であり、そして本発明の範囲を当業者に十分に伝えるように、例として提供される。説明全体を通して、同じ番号は同じ要素を指す。
【００５４】
無線リソース制御（ＲＲＣ）接続再確立およびＲＲＣ接続中断／再開手順は既存のソリューションであり、これは、制御プレーン（ＣＰ）セルラーインターネットオブシングス（ＣＩｏＴ）最適化の場合に無線リンク障害を処理するための候補となり得る。これらの既存のソリューションは両方とも、背景で説明したように、ユーザ装置（ＵＥ）認証トークンを使用して、本物のＵＥ１がＲＲＣ接続を再確立または再開したいことを進化型ノードＢ（ｅＮＢ）に示す。更に、ダウンリンク（ＤＬ）方向の保全性保護ＲＲＣメッセージは、それが本物のｅＮＢに接続されていることをＵＥ１に示すために使用される。しかしながら、これらのソリューションは、アクセス層（ＡＳ）セキュリティ（特にＲＲＣセキュリティ）の存在に依存しているが、ＡＳセキュリティおよびＲＲＣセキュリティは存在しないか、またはCP CIoT最適化には使用されていない。したがって、ＲＲＣ接続再確立およびＲＲＣ接続中断／再開手順は、そのままでは、CP CIoT内のモビリティを処理するために使用されるのにセキュリティ上許容されるものではない。
【００５５】
３ＧＰＰの寄書S3-16717に記載されたソリューションは、認証トークンが、ＡＳセキュリティモードコマンド（ＳＭＣ）手順を介してＵＥ１とソースｅＮＢ２との間にＡＳセキュリティ（ＲＲＣセキュリティを含む）を設定することなく、ＵＥ１とモビリティ管理エンティティ（ＭＭＥ）４の両方によって導出することができる新しいＲＲＣ保全性鍵（KeNB-RRCと呼ばれる）に基づくこと、および、および当該トークンがＵＥ１とターゲットｅＮＢ３との間で使用されることを提案する。しかしながら、３ＧＰＰの寄書S3-16717に記載されたソリューションは、本物のＵＥ１がＲＲＣ接続を再確立したいことをｅＮＢに示す方法の問題を解決しようとしている。本物のｅＮＢに接続されていることをＵＥ１にどのように示すかという問題は考慮されていない。
【００５６】
ＡＳセキュリティがなく、その結果、ｅＮＢからＵＥへのＤＬ ＲＲＣメッセージの保全性保護がない場合、CP CIoTモビリティのコンテキストにおいて、それが本物のｅＮＢに接続されていることをＵＥに示す方法は現在ない。その問題を軽減するために、ネットワークからＵＥへのＤＬ方向での認証トークンの使用が提示されている。認証トークンは、ＭＭＥ、ソースｅＮＢ、またはターゲットｅＮＢによって生成および送信され得る。ＤＬ認証トークンは、それを送信しているエンティティに応じて、ＮＡＳまたはＡＳ鍵を使用して計算することができる（後者は本願の特許請求の範囲の範囲内ではない）。  以下のケースが識別される。
【００５７】
ＤＬ認証トークンは常にターゲットｅＮＢを介してＵＥに送信される。
【００５８】
次の４つの異なる解決策は、これがどのように達成されるかを示している。
１ａ．ＤＬ認証トークンは、ソースｅＮＢからターゲットｅＮＢを介してＵＥに送信され、ＡＳ鍵を用いてＵＥによってチェックされる。あるいは、ターゲットｅＮＢは、ソースｅＮＢから受信したKrrC_int鍵を用いてトークンを計算する。この変形は、本願の特許請求の範囲の範囲内ではない。
１ｂ．ＤＬ認証トークンは、ＭＭＥからソースｅＮＢおよびターゲットｅＮＢを介してＵＥに送信され、ＵＥによってＮＡＳ鍵を用いてチェックされる。
２ａ．ＤＬ認証トークンは、 Path Switch Acknowledge（パススイッチ（切替）確認）メッセージ  でターゲットＥｅＮＢを介してＭＭＥからＵＥに送信され、ＵＥはＤＬ認証トークンを、ＮＡＳ鍵を用いてチェックする。
２ｂ．ＤＬ認証トークンは、ターゲットｅＮＢを介して新しいメッセージでＭＭＥからＵＥに送信され、ＵＥはトークンを、ＮＡＳ鍵を用いてチェックする。
【００５９】
本物のｅＮＢに接続されているというＵＥによる確認がＤＬ認証トークンに基づいている場合、ＡＳ鍵を確立する必要は全くない。したがって、ＡＳ鍵の生成を回避することができ、これは有益である。なぜならば、そうでなければＡＳ鍵がＲＲＣ接続の再確立の目的のためにのみ生成されればよく、それ以上使用されないからである。しかしながら、ＮＡＳ鍵は、ｅＮＢを認証するだけではなく、他のセキュリティ問題にも使用可能であろう。より正確には、ＮＡＳを介してデータを送信するＵＥに対してＮＡＳセキュリティコンテキストが存在するので、ＮＡＳ鍵はいずれにても作成されている。
【００６０】
ＵＥがCP CIoT（DoNAS）接続中に無線リンク障害（ＲＬＦ）を経験すると、ＵＥは他のｅＮＢへのＲＲＣ接続を再確立しようと試みる（図２参照）。
【００６１】
CP CIoTで使用するためのネットワークの認証トークン（MAC CIoT DLと示す）は、ネットワークの認証に使用される、すなわち、本物のターゲットｅＮＢ３に接続されていることをＵＥ１に示すために使用されるトークンである。
【００６２】
請求項に係る発明の態様によれば、MAC CIoT DLは、入力として以下を用いて計算することができる。
・ＮＡＳ保全性鍵（NAS-int、例えばKNASint）。他の変形例では、本出願では主張していないが、それはまた、ＡＳ保全性鍵、またはNAS-intもしくはＡＳ保全性鍵（Krrc_int）から派生する鍵、またはそれらの鍵のいずれかから派生する鍵であり得る。NAS-intは、Key-MAC CIoT DLと表記される以下の文章を通して多くの場合に用いられている。ＮＡＳまたはＡＳ鍵の使用は、MAC CIoT DLがＭＭＥ４またはｅＮＢのいずれによって計算されるかに依存する。本出願の特許請求の範囲の範囲外の他の代替鍵は、NAS-int、例えば、ＬＴＥにおけるKASMEおよびＮｅｗ  ＲａｄｉｏシステムにおけるKAUSF、KAUSF、KSEAF、およびKAMFのルート鍵である。
・ターゲットセルの識別子（セルＩＤ） 
・ソースセルの物理セル識別子
・ソースセルにおけるＵＥのＣ−ＲＮＴＩ
・定数（定数は、ShortResumeMAC-IおよびShortMAC-Iまたは他の方法で定義されたMACからのMAC CIoTの区別を可能にする）
・MAC CIoT DL計算への可能性のある入力は、アップリンク（ＵＬ）認証トークンであり、ここではMAC IoT UL（アップリンク）と呼ばれる。
・鮮度パラメータ
【００６３】
MAC CIoT DLの計算に使用される入力は、Input-MAC CIoT DLと示される。したがって、ターゲットセルの識別子は、Input-MAC CIoT DLの一部であり得るが、それは、通常、既にＮＡＳ保全性鍵を有してMAC CIoT ULの計算のためにそれを使用するため、ＮＡＳ保全性鍵はＵＥによって受信されたInput-MAC-CIoT DLとは別個であり得る。
【００６４】
MAC CIoT DL（Fun-MAC CIoT DLと示す）の計算に使用される関数は、ＲＲＣ再確立およびＲＲＣ再開のためのTS 33.401のAnnex B.2で使用されるもの、すなわち、128-EIA1、128-EIA2、128-EIA3であり得るNAS 128ビット保全性アルゴリズムの形式の保全性アルゴリズム、と同じである場合がある。
【００６５】
変形例１ａは、図３ａおよび図３ｂに示されている。ここで、 MAC CIoT DLはソースｅＮＢから送信され、ＡＳ鍵（アプリケーションのクレームの範囲内ではない）またはＮＡＳ鍵でＵＥによってチェックされる。
【００６６】
この変形例は、ＮＡＳプロトコルを介したＡＳアルゴリズムのネゴシエーションと、ソースｅＮＢでのMAC CIoT ULと呼ばれるアップリンクトークンのその後のチェックに基づく。変形例は、MAC CIoT ULをチェックした後にソースｅＮＢがMAC CIoT DLと呼ばれるダウンリンクトークンを生成するメカニズムを有する。ソースｅＮＢは、X2 UE Context responseメッセージ（Ｘ２  ＵＥコンテキスト応答メッセージ）でMAC CIoT DLをターゲットｅＮＢに送信する。ターゲットｅＮＢは、認証チェックのためにＲＲＣメッセージでMAC CIoT DLを更にＵＥに送信する。MAC CIoT DLのチェックが成功した場合、ＵＥは、それが偽のｅＮＢではなく本物のｅＮＢに接続されていることを知る。
【００６７】
ステップ１から１５は、現在の３ＧＰＰ仕様で定義されているとおりである。ＵＥはＲＲＣ接続を設定し、ＭＭＥからサービングゲートウェイ（Ｓ−ＧＷ）／パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）に転送されるＮＡＳを介してデータを送信する。ＲＬＦはステップ１５において発生する。ＲＬＦはまた、ＵＥがＤＬデータを受信する前に起こり得る。
【００６８】
ステップ１６。ＵＥは、ランダムアクセスメッセージをターゲットｅＮＢに送信することによってＲＲＣ接続を開始する。
【００６９】
ステップ１７。ターゲットｅＮＢは、ＵＥへのランダムアクセス応答で応答する。
【００７０】
ステップ１８。ＵＥは認証トークン、MAC CIoT ULを生成する。トークンは次のように計算することができる。トークン＝ ｆ（ソースＰＣＩ、ソースＣ−ＲＮＴＩ、ターゲットセルＩＤ、ＮＡＳ鍵、再生入力）、ここでＮＡＳ鍵は現在のＮＡＳ保全性鍵、例えば KNASint、またはその派生物である。 なお、ｆは関数である。しかしながら、この特定の変形例１ａに関しては、トークンはＮＡＳ鍵の代わりにＡＳ鍵によって代わりに導出され得る。ＡＳ鍵は、KRRCintのようなＡＳ保全性鍵であり得る。
【００７１】
ステップ１９。ＵＥは、ＲＲＣ接続再確立メッセージを、例えばCP IoT EPS（Evolved Packet System）最適化のために、ターゲットｅＮＢに送信する。メッセージにはMAC CIoT ULが含まれる。
【００７２】
ステップ２０。ターゲットｅＮＢは、X2 UE Context requestメッセージ（Ｘ２  ＵＥコンテキスト要求メッセージ）をソースｅＮＢに送信する。メッセージにはMAC CIoT ULが含まれる。
【００７３】
ステップ２１。ソースｅＮＢは、MAC CIoT ULが本物かどうかをチェックする。
【００７４】
ステップ２２。認証が成功した場合、ソースｅＮＢは、Input-MAC CIoT DLとKey-MAC CIoT DLを使用して上記のようにMAC CIoT DLを生成し、処理はステップ２３に続く。認証に失敗した場合、ソースｅＮＢは、失敗を示すX2 UEコンテキスト応答を送信する。この失敗により、ターゲットＥｅＮＢがＲＲＣ接続を解放するようにトリガされる（図示せず）。
【００７５】
ステップ２３。ソースｅＮＢは、X2 UEコンテキスト応答をターゲットｅＮＢに送信する。メッセージにはMAC CIoT ＤＬが含まれる。メッセージには更にInput-MAC CIoT DLが含まれる。
【００７６】
ステップ２４。ターゲットｅＮＢはＲＲＣ接続再確立メッセージをＵＥに送信する。メッセージにはMAC CIoT ＤＬが含まれる。メッセージには更にInput-MAC CIoT DLが含まれる。
【００７７】
ステップ２５。ＲＲＣ接続再確立メッセージを受信すると、ＵＥは、前述のように、Input-MAC CIoT DLおよびKey-MAC CIoT DLを使用してMAC CIoT DLを認証する。
【００７８】
ステップ２６Ａ。MAC CIoT DL認証が成功した場合。
２６Ａ．１。 ＵＥは、オプションでＮＡＳデータＰＤＵ（NAS Data PDU）を含むＲＲＣ接続再確立完了メッセージをターゲットｅＮＢに送信する。
２６Ａ．２〜２６Ａ．５。これらの手順は、通常のパス切り替えおよびベアラ変更手順である。
２６Ａ．６。ターゲットｅＮＢは、UE Context Releaseと呼ばれるX2メッセージを送信することで、ソースｅＮＢにＵＥコンテキストを解放するように指示する。
【００７９】
ステップ２５でMAC CIoT DLの認証が失敗した場合、ＵＥは、更にメッセージを送信しない、または、RRC_CONNECTEDモードに移行してネットワークを認証するといったアクションを実行し得る。
【００８０】
変形例１ｂは、図４ａ〜４ｂに示されている。 ここで、MAC CIoT DLは、ＭＭＥからソースｅＮＢへ、ソースｅＮＢからターゲットｅＮＢへ、ターゲットｅＮＢからＵＥへ送信され、次いで、ＮＡＳ鍵でＵＥによりチェックされる。
【００８１】
これは、ＲＬＦが発生する状況、例えば、CP CIoT最適化のためのＮＡＳデータの送信中に適用できる例である。
【００８２】
ステップ１から１８は、現在の３ＧＰＰ仕様で定義されているとおりである。
【００８３】
ステップ１９。ＵＥは、MAC CIoT ULを含むＲＲＣメッセージをターゲットｅＮＢに送信する。ＲＲＣメッセージは、ＲＲＣ接続再確立要求、ＲＲＣ再開要求、または他の何らかのＲＲＣメッセージであり得る。
【００８４】
ステップ２０。ターゲットｅＮＢは、MAC CIoT ULを含むＸ２メッセージをソースｅＮＢに送信する。Ｘ２メッセージは、X2 context fetchメッセージ（Ｘ２コンテキストフェッチメッセージ）であり得る。 
【００８５】
ステップ２１。ソースｅＮＢは、MAC CIoT ULおよびInput-MAC CIoT ULを含むＳ１メッセージをＭＭＥに送信する。
【００８６】
ステップ２２。MAC CIoT ULおよびInput-MAC CIoT ULを受信すると、ＭＭＥはＵＥが実行したのと同じ計算を実行し、受信したMAC CIoT ULと比較することでMAC CIoT ULを検証する。検証が成功した場合、ＭＭＥはInput-MAC CIoT DLとKey-MAC CIoT DLを使用して上記のようにMAC CIoT DLを生成し、処理はステップ２３に続く。ここで、ＭＭＥは、成功を示すＳ１メッセージをソースｅＮＢに送信し、 MAC CIoT DLを含める。検証が失敗した場合、ＭＭＥはエラーを示すＳ１メッセージをソースｅＮＢへ送信する。ソースｅＮＢはその後、失敗を示すX2 UE context応答を送信する。この失敗により、ターゲットｅＮＢがＲＲＣ接続を解放するようにトリガされる（図示せず）。
【００８７】
ステップ２３。ＭＭＥは、成功を示すS1 Check responseメッセージ（Ｓ１チェック応答メッセージ）をソースｅＮＢへ送信する。メッセージにはMAC CIoT DLが含まれる。メッセージには更にInput-MAC CIoT DLが含まれる。
【００８８】
ステップ２４。ソースｅＮＢは、UE Context response（ＵＥコンテキスト応答）をターゲットｅＮＢに送信する。メッセージにはMAC CIoT ＤＬが含まれる。メッセージには更にInput-MAC CIoT DLが含まれる。
【００８９】
ステップ２５。ターゲットｅＮＢはＲＲＣ接続再確立メッセージをＵＥに送信する。メッセージにはMAC CIoT DLが含まれる。メッセージには更にInput-MAC CIoT DLが含まれる。
【００９０】
ステップ２６。ＲＲＣ接続再確立メッセージを受信すると、ＵＥは、前述のように、Input-MAC CIoT DLおよびKey-MAC CIoT DLを使用してMAC CIoT DLを認証する。
【００９１】
ステップ２７Ａ。MAC CIoT DL認証が成功した場合。
２７Ａ．１。ＵＥは、オプションでNAS Data PDUを含むＲＲＣ接続再確立完了メッセージをターゲットｅＮＢに送信する。
２７Ａ．２〜２７Ａ．５。これらの手順は、通常のパス切り替えおよびベアラ変更手順である。
２７Ａ．６。ターゲットｅＮＢは、UE Context Releaseと呼ばれるＸ２メッセージを送信することで、ソースｅＮＢにＵＥコンテキストを解放するように指示する。
【００９２】
ステップ２５でMAC CIoT DLの認証が失敗した場合、ＵＥは、更にメッセージを送信しない、または、RRC_CONNECTEDモードに移行してネットワークを認証するといったアクションを実行し得る。
【００９３】
変形例２ａが図５に示される。ここで、MAC CIoT DLは、ＭＭＥからターゲットｅＮＢに、S1 AP Path Switch Request Acknowledgmentメッセージで送信される。MAC CIoT DL はターゲットｅＮＢからＵＥに送信される。
【００９４】
この変形例は、ＭＭＥからターゲットｅＮＢに送信されるPath Switch Request Acknowledgmentと呼ばれる既存のS1APメッセージに基づいている。Path Switch Request Acknowledgementは、MAC CIoT DLおよびInput-MAC CIoT DLを伝送できるように変更されている。同じ効果を達成するために、ステップの順序、メッセージ、およびフィールドを変更できること、メッセージの結合、異なるメッセージなどに入れられるフィールドは、当業者には明らかであるべきである。
【００９５】
ステップ１〜１７は、図３ａに関連して前述したものと同じである。
【００９６】
ステップ１８〜１９も、図３ａに関連して前述したものと同じであるが、ＲＲＣ接続再確立手順の完全性のために図５にも示されている。
【００９７】
ステップ２０。ターゲットｅＮＢは、ソースｅＮＢにＵＥのコンテキストを送信するように要求する。Retrieve UE Context Request（リトリーブＵＥコンテキスト要求）と呼ばれる既存のＸ２メッセージは、必要に応じて適合させることができる（例えば、ResumeIdentityの代わりにReestabUE-Identityを使用する）。
【００９８】
ステップ２１。ソースｅＮＢは、ＵＥのコンテキストをターゲットｅＮＢに送信する。Retrieve UE Context Response（リトリーブＵＥコンテキスト応答）と呼ばれる既存のＸ２メッセージは、必要に応じて適合させることができる。
【００９９】
ステップ２２。ターゲットｅＮＢはＲＲＣ接続再確立メッセージをＵＥに送信する。
【０１００】
ステップ２３。ＵＥは、オプションでNAS Data PDU（プロトコルデータユニット）を含むＲＲＣ接続再確立完了メッセージをターゲットｅＮＢに送信する。
【０１０１】
ステップ２４。ターゲットｅＮＢはPath Switch RequestをＭＭＥへ送信する。Path Switch Requestにおいて、ターゲットｅＮＢはMAC CIoT ULおよびInput-MAC CIoT ULを含める。前述のように、Input-MAC CIoT ULにはターゲットセルのＩＤが含まれ得る。ターゲットｅＮＢは、ステップ１９でMAC CIoT ULを受信する。Input-MAC CIoT ULは、ターゲットｅＮＢがステップ１９および／またはステップ２１で受信した情報、および／またはターゲットｅＮＢ自身の情報を含み得る。Path Switch Requestは、ＭＭＥがＭＭＥにおけるＵＥのコンテキストを識別できるようにするＵＥの情報を含み得る。そのＵＥの情報は、現在「Source MME US S1AP ID」と呼ばれ、ターゲットｅＮＢはステップ２３で受信した情報から提供することができる。
【０１０２】
ステップ２５．ＭＭＥは、例えば、Fun-MAC CIoT DLへの入力としてInput-MAC CIoT ULおよびKey-MAC CIoT ULを使用することによって、MAC CIoT ULを認証する。Key-MAC CIoT ULは、一実施形態では、Key-MAC CIoT DL、すなわち、KASMEに基づいてＭＭＥおよびＵＥによってそれぞれ別個に導出され得るＮＡＳ保全性鍵と同じであり、当業者には既知である。
【０１０３】
以下では、簡単化のために、現在の解決策に関連するステップのみを更に説明する。それは、ステップ２５における認証が成功した場合である。
【０１０４】
ステップ２６。ＭＭＥは、Input-MAC CIoT DLとKey-MAC CIoT DLを使用して上記のようにMAC CIoT DLを生成する。ターゲットセルのＩＤ（セルＩＤ）等、Input-MAC CIoT DLのいくつかの要素は、Input-MAC CIoT ULから取得され得る。
【０１０５】
ステップ２７。ＭＭＥは、ターゲットｅＮＢに成功を示すＳ１メッセージ、Path Switch Request Acknowledgeメッセージを送信し、Path Switch Request Acknowledgeメッセージは、MAC CIoT DLおよびInput-MAC CIoT DLを含むように適合される。
【０１０６】
ステップ２８。ターゲットｅＮＢは、ＵＥによって送信され、前の手順で説明したMAC CIoT ULが本物であることを認識する。ターゲットｅＮＢは、ＲＲＣメッセージにおいてＵＥにMAC CIoT DLとInput-MAC CIoT DLを、例えばＲＲＣ ＤＬ情報転送手順のDLInformationTransferメッセージのDedicatedInfoNASフィールドにそれらを入れることにより、送信する。MAC CIoT DLをＵＥに伝えるというこの特定の目的のために、新しい種類のＲＲＣ手順、例えばＲＲＣ再確立の確認、が導入され得る。
【０１０７】
ステップ２９。ＵＥは、例えば、Fun-MAC CIoT DLへの入力としてInput-MAC CIoT DLおよびKey-MAC CIoT DLを使用して、MAC CIoT DLを認証する。 
【０１０８】
ステップ２７でMAC CIoT DLの認証が失敗した場合、ＵＥは、更にメッセージを送信しない、または、RRC_CONNECTEDモードに移行してネットワークを認証するといったアクションを実行し得る。
【０１０９】
変形例２ａが図６に示される。ここで、MAC CIoT DLは、新しいＳ１ＡＰメッセージでＭＭＥからターゲットｅＮＢに送信され、ターゲットｅＮＢからＵＥに送信される。
【０１１０】
この変形例は、ターゲットｅＮＢからＭＭＥに送信される新しいＳ１ＡＰメッセージ（Check MAC Requestと示す）に基づく。Check MAC Requestメッセージは、MAC CIoT ULおよびInput-MAC CIoT ULを伝送できる。同様に、ＭＭＥからターゲットｅＮＢに送信されるCheck MAC AcknowledgeおよびCheck MAC Failureと表示される新しいＳ１ＡＰメッセージは、それぞれMAC CIoT ULが本物であるか本物ではないことを示すために使用される。新しいＳ１ＡＰメッセージCheck MAC Acknowledgeは、MAC CIoT DLおよびInput-MAC CIoT DLをＭＭＥからターゲットｅＮＢに送信する。ターゲットｅＮＢは、ＲＲＣ接続再確立メッセージに、ＵＥへのMAC CIoT DLおよびInput-MAC CIoT DLを含める。同じ効果を達成するために、ステップの順序、メッセージ、およびフィールドを変更できること、メッセージの結合、異なるメッセージなどに入れられるフィールド、に気づくことは、当業者には明らかであるべきである。
【０１１１】
ステップ１〜１７は、図３に関連して前述したものと同じである。
【０１１２】
ステップ１８〜１９も前述したものと同じであるが、ＲＲＣ接続再確立手順の完全性のために示されている。
【０１１３】
ステップ２０。ターゲットｅＮＢは、ソースｅＮＢにＵＥのコンテキストを送信するように要求する。リトリーブＵＥコンテキスト要求と呼ばれる既存のＸ２メッセージは、例えば、ResumeIdentityの代わりにReestabUE-Identityを使用して、必要に応じて適合させることができる。
【０１１４】
ステップ２１。ソースｅＮＢは、ＵＥのコンテキストをターゲットｅＮＢに送信する。Retrieve UE Context Responseと呼ばれる既存のＸ２メッセージは、必要に応じて適合させることができる。ＵＥのコンテキストは、ＵＥが登録されている対応するＭＭＥをターゲットｅＮＢに通知する。
【０１１５】
ステップ２２。ターゲットｅＮＢは、ステップ２１で識別されたＭＭＥにCheck MAC Requestの形式でメッセージを送信する。Check MAC Requestにおいて、ターゲットｅＮＢはMAC CIoT ULおよびInput-MAC CIoT ULを含める。ターゲットｅＮＢは、ステップ１９でMAC CIoT ULを受信する。Input-MAC CIoT ULは、ステップ１９および／またはステップ２１でターゲットｅＮＢが受信した情報、および／またはターゲットｅＮＢ自身の情報を含み得る。Input-MAC CIoT ULに含まれるこのような情報は、ターゲットセルのＩＤであり得る。したがって、ＵＥ認証トークンMAC CIoT ULを生成するために、少なくともＮＡＳ保全性鍵とともに入力として使用される。Check MAC Requestはまた、ＭＭＥがＭＭＥにおけるＵＥのコンテキストを識別できるようにするＵＥの情報を含み得る。そのＵＥの情報は、例えば、ステップ２１でターゲットｅＮＢがソースｅＮＢから受信したMME UE S1AP IDであり得る。
【０１１６】
ステップ２３。ＭＭＥは、Fun-MAC CIoT ULへの入力として、Input-MAC CIoT ULおよびKey-MAC CIoT UL（例えば、Key-MAC CIoT DLとして使用される同じNAS保全性鍵）を使用して、MAC CIoT ULを認証する。言い換えれば、Fun-MAC CIoT ULの結果は、受信したMAC CIoT ULの検証のために、受信したMAC CIoT ULと比較される。
【０１１７】
以下では、簡単にするために、この変形例に関連するステップのみを更に説明する。ステップ２３における認証が成功した場合：
ステップ２４。ＭＭＥは、Input-MAC CIoT DLとKey-MAC CIoT DLを使用して上記のようにMAC CIoT DLを生成する。ターゲットセルのＩＤ等、Input-MAC CIoT DLのいくつかの要素は、Input-MAC CIoT ULから取得され得る。ＭＭＥは、成功を示すＳ１メッセージ（Check MAC Acknowledgeメッセージ）をターゲットｅＮＢに送信し、MAC CIoT DLおよびInput-MAC CIoT DLを含める。
【０１１８】
ステップ２５。ＭＭＥは、Check MAC Request AcknowledgeメッセージをターゲットｅＮＢに送信する。当該メッセージは、MAC CIoT DLを含み、オプションでInput-MAC CIoT DLも含む。これで、ターゲットeNBは、前の手順で言及したMAC CIoT ULが本物であることを認識する。
【０１１９】
ステップ２６。ターゲットｅＮＢはＲＲＣ接続再確立メッセージをＵＥに送信する。このメッセージは、MAC CIoT DLを含み、Input-MAC CIoT DLを含み得る。
【０１２０】
ステップ２７。ＵＥは、例えば、Fun-MAC CIoT DLへの入力としてInput-MAC CIoT DLおよびKey-MAC CIoT DLを使用して、MAC CIoT DLを認証する。
【０１２１】
ステップ２８。ステップ２７でMAC CIoT DLの認証が成功した場合、ＵＥはオプションでNAS Data PDUを含むＲＲＣ接続再確立完了メッセージをターゲットｅＮＢに送信する。 
【０１２２】
ステップ２７でMAC CIoT DLの認証が失敗した場合、ＵＥは、更にメッセージを送信しない、または、RRC_CONNECTEDモードに移行してネットワークを認証するといったいくつかのアクションを実行し得る。
【０１２３】
一実施形態によれば、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法が、図７Ａを参照して提示される。この方法は、ＵＥ１によって実行され、Ｓ１００において、CP IoT最適化のために、ターゲットｅＮＢ３からＲＲＣ接続再確立メッセージを受信することを含む。ＲＲＣ接続再確立メッセージは、ＭＭＥ４によって生成され、入力としてＮＡＳ保全性鍵を持つＤＬ認証トークンを含み、受信したＤＬ認証トークンをＳ１１０で認証する。
【０１２４】
ＤＬ認証トークンを含むＲＲＣ接続再確立メッセージには、オプションでInput-MAC CIoT DLを含めることもでき、受信したInput-MAC CIoT DLとNAS保全性鍵を使用して、受信したＤＬ認証トークンが認証され得る。
【０１２５】
ＲＲＣメッセージは、MAC CIoT DLおよびオプションでInput-MAC CIoT DLを含むRRC DL情報転送メッセージであり、受信したMAC CIoT DLは、Input-MAC CIoT DLおよびキーMAC CIoT DLを使用して認証され得る。
【０１２６】
Ｓ１００の前のオプションのステップＳ８０では、ＵＥは、ＮＡＳ保全性鍵を入力としてＵＥ認証トークン（図７ＡでUL ATと呼ばれる）を計算し、オプションのステップＳ９０では、ＵＥ認証トークンを含むＲＲＣ接続再確立要求をターゲットｅＮＢ３に送信する。入力としてターゲットセルのＩＤを使用してＵＬ認証トークンを計算でき、ターゲットセルのＩＤを、例えばInput-MAC ULの一部として、ＲＲＣ接続再確立要求に含めることができる。
【０１２７】
一実施形態によれば、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法は、例えば、CP IoT最適化に対して、図７Ｂを参照して示される。当該方法は、ターゲットｅＮＢ３によって実行され、ＭＭＥ４から、ＭＭＥによって生成されたＤＬ認証トークンを含むメッセージを受信すること（Ｓ３００）であって、ＤＬ認証トークンは、入力としての非アクセス層保全性鍵とともに生成される、ことと、ＤＬ認証トークンを含むＲＲＣ接続再確立メッセージをＵＥ１に送信すること（Ｓ３１０）を含む。
【０１２８】
Ｓ３００の前のオプションのステップＳ２８０において、ターゲットｅＮＢは、ＵＥ１から、ＵＬ認証トークンを含むＲＲＣ接続再確立要求を受信する。ここで、ＵＬ認証トークンは、ＮＡＳ保全性鍵を入力としてＵＥ１によって計算されている。一実施形態では、ＵＬ認証トークンは、ターゲットセルの識別子を含むInput-MAC CIoT ULとともに送信される。Ｓ３００の前のオプションのステップＳ２９０で、ターゲットｅＮＢは、オプションでターゲットセルのＩＤを含むInput-MAC CIoT ULとともに、ＵＬ認証トークンをＭＭＥ４に送信／転送する。
【０１２９】
送信されたＲＲＣ接続再確立メッセージは、Input-MAC CIoT DLを含み得る。
【０１３０】
受信したメッセージは、Input-MAC CIoT DLを含むPatch Switch Request Acknowledgeメッセージであり得る。 
【０１３１】
受信したメッセージは、Check MAC Acknowledgeメッセージであっても良く、Input-MAC CIoT DLを含んでも良い。
【０１３２】
一実施形態によれば、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法は、例えば、CP IoT最適化に対して、図７Ｃを参照して示される。当該方法は、ソースｅＮＢ２で実行され、ＮＡＳ保全性鍵を入力として生成されたＤＬ認証トークンを取得すること（Ｓ２００）と、取得したＤＬ認証トークンを含む応答メッセージをターゲットｅＮＢ３に送信すること（Ｓ２１０）とを含む。
【０１３３】
取得すること（Ｓ２００）は、ＤＬ認証トークンを生成すること、またはＭＭＥ４からS1 Check responseメッセージ（Ｓ１チェック応答メッセージ）を受信することを含むことができ、受信したS1 Check response（Ｓ１チェック応答）はＤＬ認証トークンおよびオプションとして Input-MAC CIoT DLを含む。
【０１３４】
応答メッセージは、X2 UE Context responseメッセージ（Ｘ２  ＵＥ  コンテキスト応答メッセージ）であり得る。
【０１３５】
一実施形態によれば、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するための方法は、例えば、CP IoT最適化に対して、図７Ｄを参照して示される。この方法は、ＭＭＥ４によって実行され、ＮＡＳ保全性鍵を入力としてＤＬ認証トークンを生成すること（Ｓ４００）、および生成されたＤＬ認証トークンを含むメッセージをターゲットｅＮＢ３に送信することを含む。ＤＬ認証トークンは、入力としてターゲットセルの識別子をも用いて計算され得る。
【０１３６】
Ｓ４００の前のオプションのステップＳ３８０において、ＭＭＥは、ターゲットｅＮＢ３からＵＬ認証トークンを受信する。ここで、ＵＬ認証トークンは、ＮＡＳ保全性鍵を入力としてＵＥ１により生成される。また、オプションのステップＳ３９０において、ＭＭＥは、ＵＬ認証トークンを、例えば ＵＥと同じ方法で（たとえば、ＮＡＳ保全性鍵とターゲットセルのＩＤを入力として用いて）２番目のＵＬ認証トークンを計算し、２番目のＵＬ認証トークンをターゲットｅＮＢから受信したトークンと比較することによって、検証する。
【０１３７】
当該メッセージは、Path Switch Request Acknowledgeメッセージであっても良く、Input-MAC CIoT DL.を含む。
【０１３８】
当該メッセージは、Input-MAC CIoT DLを含むCheck MAC Acknowledgeメッセージであり得る。
【０１３９】
一実施形態によれば、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続を再確立するためのＵＥ１が、図８を参照して提示される。ＵＥ１は、プロセッサ１０とコンピュータプログラム製品を有する。コンピュータプログラムは、プロセッサにより実行された場合に、ＵＥに、ターゲットｅＮＢ３からＲＲＣ接続再確立メッセージを受信させ、ここでＲＲＣ接続再確立メッセージは、ＭＭＥ４によって生成され入力としてＮＡＳ保全性鍵を持つＤＬ認証トークンを含み、受信したDL認証トークンを認証させる命令を格納する。
【０１４０】
ＲＲＣ接続再確立メッセージには、オプションでInput-MAC CIoT DLを含めることもでき、Input-MAC CIoT DLとＮＡＳ保全性鍵を使用して、受信したＤＬ認証トークンが認証され得る。
【０１４１】
一実施形態によれば、ＵＥ１とターゲットｅＮＢ３との間のＲＲＣ接続を再確立するためのソースｅＮＢが、図９を参照して提示される。ソースｅＮＢ２は、プロセッサ２０とコンピュータプログラム製品を有する。コンピュータプログラム製品は、プロセッサにより実行された場合に、ソースｅＮＢに、ＮＡＳ保全性鍵を入力として生成されたＤＬ認証トークンを取得させ、取得されたＤＬ認証トークンを含む応答メッセージをターゲットｅＮＢ３に送信させるための命令を格納する。
【０１４２】
応答メッセージは、X2 UE Context responseメッセージであり得る。
【０１４３】
一実施形態によれば、ＵＥ１とターゲットｅＮＢ３との間のＲＲＣ接続を再確立するためのターゲットｅＮＢが、図１０を参照して提示される。ターゲットｅＮＢ３は、プロセッサ３０とコンピュータプログラム製品を有する。コンピュータプログラム（製品）は、プロセッサにより実行された場合に、ターゲットｅＮＢに、ＭＭＥ４から、ＭＭＥ４によって生成されたＤＬ認証トークンを含むメッセージを受信させ、ここでＤＬ認証トークンは、入力としてのＮＡＳ保全性鍵とともに生成され、ＤＬ認証トークンを含むＲＲＣ接続再確立メッセージをＵＥ１に送信させる、ための命令を格納する。ＤＬ認証トークンは、一実施形態では、入力としてターゲットセルの識別子を用いてＭＭＥ４によって計算されてもよい。
【０１４４】
送信されたＲＲＣ接続再確立メッセージは、オプションでターゲットセルの識別子を含み得るInput-MAC CIoT DLを含んでいる。
【０１４５】
受信したメッセージは、Input-MAC CIoT DLを含むPatch Switch Request Acknowledgeメッセージであり得る。 
【０１４６】
受信したメッセージは、Input-MAC CIoT DLを含むCheck MAC Acknowledgeメッセージであり得る。 
【０１４７】
一実施形態によれば、ＵＥ１とターゲットｅＮＢ３との間のＲＲＣ接続を再確立するためのＭＭＥが、図１１を参照して提示される。ＭＭＥ４は、プロセッサ４０とコンピュータプログラム製品を有する。コンピュータプログラム製品は、プロセッサにより実行された場合に、ＭＭＥに、ＮＡＳ保全性鍵を入力としてＤＬ認証トークンを生成させ、生成されたＤＬ認証トークンを含むメッセージをターゲットｅＮＢ３に送信させる、ための命令を格納する。
【０１４８】
当該メッセージは、Input-MAC CIoT DLを含むPath Switch Request Acknowledgeメッセージであり得る。
【０１４９】
当該メッセージは、Input-MAC CIoT DLを含むCheck MAC Acknowledgeメッセージであり得る。
【０１５０】
図８は、ＵＥ１のいくつかのコンポーネントを示す概略図である。プロセッサ１０は、メモリに格納されたコンピュータプログラム１４のソフトウェア命令を実行することが可能な、ＣＰＵ（central processing unit）、マルチプロセッサ、マイクロコントローラ、ＤＳＰ（デジタル信号プロセッサ）、特定用途向け集積回路などのうちの１つ以上の任意の組み合わせを使用して提供され得る。したがって、メモリは、コンピュータプログラム製品１２であるか、その一部を形成するとみなすことができる。プロセッサ１０は、図７Ａを参照して本明細書で説明される方法を実行するように構成され得る。
【０１５１】
メモリは、読み取りおよび書き込みメモリ（ＲＡＭ）と読み取り専用メモリ（ＲＯＭ）の任意の組み合わせである。メモリはまた、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。
【０１５２】
例えば、プロセッサ１０におけるソフトウェア命令の実行中のデータの読み取りおよび／または保存のために、データメモリの形態の第２のコンピュータプログラム製品１３も提供され得る。データメモリは、読み取りおよび書き込みメモリ（ＲＡＭ）、および読み取り専用メモリ（ＲＯＭ）の組み合わせである可能性があり、また、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。データメモリは、ＵＥ１に対する機能性を改善するために、例えば 他のソフトウェア命令１５を保持し得る。
【０１５３】
ＵＥ１は更に、例えばユーザインタフェースを含む入力／出力（Ｉ／Ｏ）インタフェース１１を備え得る。ＵＥ１は、他のノードからシグナリングを受信するように構成された受信器と、他のノード（図示せず）にシグナリングを送信するように構成された送信器とを更に備えてもよい。ＵＥ１の他の構成要素は、本明細書に提示される概念を不明瞭にしないために省略されている。
【０１５４】
図１２は、ＵＥ１の機能ブロックを示す概略図である。モジュールは、キャッシュサーバーで実行されるコンピュータプログラムなどのソフトウェア命令のみ、または特定用途向け集積回路、フィールドプログラマブルゲートアレイ、個別論理コンポーネント、トランシーバーといった、ハードウェアのみ、またはそれらの組み合わせとして実装され得る。代替実施形態では、機能ブロックのいくつかはソフトウェアによって実装され、他はハードウェアによって実装されてもよい。これらのモジュールは、図７Ａに示されている方法のステップに対応しており、判定マネージャー部６０と通信マネージャー部６１を備えている。モジュールの1つまたは複数がコンピュータプログラムによって実装される実施形態では、これらのモジュールは必ずしもプロセスモジュールに対応するわけではないが、実装されるプログラミング言語に従って命令として記述できることを理解されたい。それは、一部のプログラミング言語には通常、プロセスモジュールが含まれていないためである。
【０１５５】
判定マネージャー６０は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ａのチェックステップ（Ｓ１１０）、すなわち受信したＤＬ認証トークンの認証に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図８のプロセッサ１０によって実行される。
【０１５６】
通信マネージャー６１は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ａの受信ステップ（Ｓ１００）に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図１２のプロセッサ１０によって実行される。
【０１５７】
図９は、ソースｅＮＢ２いくつかのコンポーネントを示す概略図である。プロセッサ２０は、メモリに格納されたコンピュータプログラム２４のソフトウェア命令を実行することが可能な、ＣＰＵ（central processing unit）、マルチプロセッサ、マイクロコントローラ、ＤＳＰ（デジタル信号プロセッサ）、特定用途向け集積回路などのうちの１つ以上の任意の組み合わせを使用して提供され得る。したがって、メモリは、コンピュータプログラム製品２２であるか、その一部を形成するとみなすことができる。プロセッサ２０は、図７Ｂを参照して本明細書で説明される方法を実行するように構成され得る。
【０１５８】
メモリは、読み取りおよび書き込みメモリ（ＲＡＭ）と読み取り専用メモリ（ＲＯＭ）の任意の組み合わせである。メモリはまた、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。
【０１５９】
例えば、プロセッサ２０におけるソフトウェア命令の実行中のデータの読み取りおよび／または保存のために、データメモリの形態の第２のコンピュータプログラム製品２３も提供され得る。データメモリは、読み取りおよび書き込みメモリ（ＲＡＭ）、および読み取り専用メモリ（ＲＯＭ）の組み合わせである可能性があり、また、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。データメモリは、ｅＮＢ２に対する機能性を改善するために、例えば 他のソフトウェア命令２５を保持し得る。
【０１６０】
ｅＮＢ２は更に、例えばユーザインタフェースを含む入力／出力（Ｉ／Ｏ）インタフェース２１を備え得る。ソースｅＮＢ２は、他のノードからシグナリングを受信するように構成された受信器と、他のノード（図示せず）にシグナリングを送信するように構成された送信器とを更に備えてもよい。ソースｅＮＢ２の他の構成要素は、本明細書に提示される概念を不明瞭にしないために省略されている。
【０１６１】
図１３は、ソースｅＮＢ２の機能ブロックを示す概略図である。モジュールは、キャッシュサーバーで実行されるコンピュータプログラムなどのソフトウェア命令のみ、または特定用途向け集積回路、フィールドプログラマブルゲートアレイ、個別論理コンポーネント、トランシーバーといった、ハードウェアのみ、またはそれらの組み合わせとして実装され得る。代替実施形態では、機能ブロックのいくつかはソフトウェアによって実装され、他はハードウェアによって実装されてもよい。これらのモジュールは、図７Ｃに示されている方法のステップに対応しており、判定マネージャー部７０と通信マネージャー部７１を備えている。モジュールの１つまたは複数がコンピュータプログラムによって実装される実施形態では、これらのモジュールは必ずしもプロセスモジュールに対応するわけではないが、実装されるプログラミング言語に従って命令として記述できることを理解されたい。それは、一部のプログラミング言語には通常、プロセスモジュールが含まれていないためである。
【０１６２】
判定マネージャー７０は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ｃの取得ステップ（Ｓ２００）に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図９のプロセッサ２０によって実行される。
【０１６３】
通信マネージャー７１は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ｃの送信ステップ（Ｓ２１０）に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図１３のプロセッサ２０によって実行される。
【０１６４】
図１０は、ターゲットｅＮＢ３のいくつかのコンポーネントを示す概略図である。プロセッサ３０は、メモリに格納されたコンピュータプログラム３４のソフトウェア命令を実行することが可能な、ＣＰＵ（central processing unit）、マルチプロセッサ、マイクロコントローラ、ＤＳＰ（デジタル信号プロセッサ）、特定用途向け集積回路などのうちの１つ以上の任意の組み合わせを使用して提供され得る。したがって、メモリは、コンピュータプログラム製品３２であるか、その一部を形成するとみなすことができる。プロセッサ３０は、図７Ｃを参照して本明細書で説明される方法を実行するように構成され得る。 
【０１６５】
メモリは、読み取りおよび書き込みメモリ（ＲＡＭ）と読み取り専用メモリ（ＲＯＭ）の任意の組み合わせである。メモリはまた、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。
【０１６６】
例えば、プロセッサ３０におけるソフトウェア命令の実行中のデータの読み取りおよび／または保存のために、データメモリの形態の第２のコンピュータプログラム製品３３も提供され得る。データメモリは、読み取りおよび書き込みメモリ（ＲＡＭ）、および読み取り専用メモリ（ＲＯＭ）の組み合わせである可能性があり、また、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。データメモリは、ターゲットｅＮＢ３に対する機能性を改善するために、例えば 他のソフトウェア命令３５を保持し得る。
【０１６７】
ターゲットｅＮＢ３は更に、例えばユーザインタフェースを含む入力／出力（Ｉ／Ｏ）インタフェース３１を備え得る。ターゲットｅＮＢ３は、他のノードからシグナリングを受信するように構成された受信器と、他のノード（図示せず）にシグナリングを送信するように構成された送信器とを更に備えてもよい。ターゲットｅＮＢ３の他の構成要素は、本明細書に提示される概念を不明瞭にしないために省略されている。
【０１６８】
図１４は、ターゲットｅＮＢ３いくつかの機能ブロックを示す概略図である。モジュールは、キャッシュサーバーで実行されるコンピュータプログラムなどのソフトウェア命令のみ、または特定用途向け集積回路、フィールドプログラマブルゲートアレイ、個別論理コンポーネント、トランシーバーといった、ハードウェアのみ、またはそれらの組み合わせとして実装され得る。代替実施形態では、機能ブロックのいくつかはソフトウェアによって実装され、他はハードウェアによって実装されてもよい。これらのモジュールは、図７Ｂに示されている方法のステップに対応しており、判定マネージャー部８０と通信マネージャー部８１を備えている。モジュールの１つまたは複数がコンピュータプログラムによって実装される実施形態では、これらのモジュールは必ずしもプロセスモジュールに対応するわけではないが、実装されるプログラミング言語に従って命令として記述できることを理解されたい。それは、一部のプログラミング言語には通常、プロセスモジュールが含まれていないためである。
【０１６９】
通信マネージャー８１は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ｂの受信ステップ（Ｓ３００）および送信ステップ（３１０）に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図１０のプロセッサ３０によって実行される。
【０１７０】
図１１は、ＭＭＥ４のいくつかのコンポーネントを示す概略図である。プロセッサ４０は、メモリに格納されたコンピュータプログラム４４のソフトウェア命令を実行することが可能な、ＣＰＵ（central processing unit）、マルチプロセッサ、マイクロコントローラ、ＤＳＰ（デジタル信号プロセッサ）、特定用途向け集積回路などのうちの１つ以上の任意の組み合わせを使用して提供され得る。したがって、メモリは、コンピュータプログラム製品４２であるか、その一部を形成するとみなすことができる。プロセッサ４０は、図７Ｄを参照して本明細書で説明される方法を実行するように構成され得る。
【０１７１】
メモリは、読み取りおよび書き込みメモリ（ＲＡＭ）と読み取り専用メモリ（ＲＯＭ）の任意の組み合わせである。メモリはまた、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。
【０１７２】
例えば、プロセッサ４０におけるソフトウェア命令の実行中のデータの読み取りおよび／または保存のために、データメモリの形態の第２のコンピュータプログラム製品４３も提供され得る。データメモリは、読み取りおよび書き込みメモリ（ＲＡＭ）、および読み取り専用メモリ（ＲＯＭ）の組み合わせである可能性があり、また、例えば、磁気メモリ、光学メモリ、固体メモリ、またはリモートでマウントされたメモリでさえ、任意の単一のものまたは組み合わせであり得る永続的ストレージを備え得る。データメモリは、ＭＭＥ４に対する機能性を改善するために、例えば 他のソフトウェア命令４５を保持し得る。
【０１７３】
ＭＭＥ４は更に、例えばユーザインタフェースを含む入力／出力（Ｉ／Ｏ）インタフェース４１を備え得る。ＭＭＥ４は、他のノードからシグナリングを受信するように構成された受信器と、他のノード（図示せず）にシグナリングを送信するように構成された送信器とを更に備えてもよい。ＭＭＥ４の他の構成要素は、本明細書に提示される概念を不明瞭にしないために省略されている。
【０１７４】
図１５は、ＭＭＥ４の機能ブロックを示す概略図である。モジュールは、キャッシュサーバーで実行されるコンピュータプログラムなどのソフトウェア命令のみ、または特定用途向け集積回路、フィールドプログラマブルゲートアレイ、個別論理コンポーネント、トランシーバーといった、ハードウェアのみ、またはそれらの組み合わせとして実装され得る。代替実施形態では、機能ブロックのいくつかはソフトウェアによって実装され、他はハードウェアによって実装されてもよい。これらのモジュールは、図７Ｄに示されている方法のステップに対応しており、判定マネージャー部９０と通信マネージャー部９１を備えている。モジュールの１または複数がコンピュータプログラムによって実装される実施形態では、これらのモジュールは必ずしもプロセスモジュールに対応するわけではないが、実装されるプログラミング言語に従って命令として記述できることを理解されたい。それは、一部のプログラミング言語には通常、プロセスモジュールが含まれていないためである。
【０１７５】
判定マネージャー９０は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ｄの生成ステップ（４００）に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図１１のプロセッサ４０によって実行される。
【０１７６】
通信マネージャー９１は、ＵＥとターゲットｅＮＢとの間のＲＲＣ接続の再確立を可能にするためのものである。このモジュールは、図７Ｄの送信ステップＳ４１０に対応する。このモジュールは、例えば コンピュータプログラムを実行するとき、図１１のプロセッサ４０によって実行される。
【０１７７】
本発明は、いくつかの実施形態を参照して主に説明された。しかしながら、当業者には容易に理解されるように、上に開示されたもの以外の他の実施形態も、添付の項目別の実施形態のリストによって定義されるように、本発明の範囲内で等しく可能である。
【図１】
0006725764.tif 000002
【図２】
0006725764.tif 000003
【図３ａ】
0006725764.tif 000004
【図３ｂ】
0006725764.tif 000005
【図４ａ】
0006725764.tif 000006
【図４ｂ】
0006725764.tif 000007
【図５】
0006725764.tif 000008
【図６】
0006725764.tif 000009
【図７Ａ】
0006725764.tif 000010
【図７Ｂ】
0006725764.tif 000011
【図７Ｃ】
0006725764.tif 000012
【図７Ｄ】
0006725764.tif 000013
【図８】
0006725764.tif 000014
【図９】
0006725764.tif 000015
【図１０】
0006725764.tif 000016
【図１１】
0006725764.tif 000017
【図１２】
0006725764.tif 000018
【図１３】
0006725764.tif 000019
【図１４】
0006725764.tif 000020
【図１５】
0006725764.tif 000021