JP2018517368A - 統合スモールセルネットワークおよびｗｉｆｉネットワークのための統一認証 - Google Patents

Abstract

マルチＲＡＴ ＵＥは、現在、ＨＳＳと認証を行うための２つの独立経路を有し（ＭＭＥ又は３ＧＰＰ ＡＡＡサーバのいずれかを介し）、反復認証メッセージをＨＳＳに生じさせる。スモールセル及びＷｉ−Ｆｉ認証のためのＵＥとＨＳＳとの間の１つの統一認証経路の使用が説明される。第１に、新しい３ＧＰＰ ＥＰＣ−ＴＷＡＮインタワーキングアーキテクチャは、ＭＭＥにマルチＲＡＴ ＵＥからの全認証要求を管理させる。第２に、新しい統一認証プロシージャが追加され、ＩＳＷＮベースのマルチＲＡＴ ＵＥが、その現在のアクセスネットワーク（ＴＷＡＮ又はＨｅＮＢ）に関係なく、ＨＳＳと直接認証されることを可能にする。第３に、ＲＡＴ間ハンドオーバシナリオのための新しい高速再認証プロシージャが行われる。最後に、認証プロシージャを実行するための種々の標準的プロトコルメッセージに対して必要とされる拡張が説明される。

Description

（関連出願の相互参照）
本願は、２０１５年６月５日に出願された米国仮特許出願第６２／１７１，４９７号の利益を主張するものであり、該米国仮特許出願の開示は、その全体が開示されているのと同然に参照により本明細書中に援用される。

最近、モバイルネットワークオペレータ（ＭＮＯ）は、統合スモールセルおよびＷｉ−Ｆｉ（ＩＳＷ）ネットワークを展開し、無線データ使用量の広範な増加に適応することに大きな関心を示している。より具体的には、ＩＳＷネットワークは、ライセンススペクトル内のロング・ターム・エボリューション（ＬＴＥ）スモールセルの展開とともに、アンライセンススペクトル内の無線ローカルエリアネットワーク（ＷＬＡＮ）アクセスポイント（ＡＰ）を活用する。ＩＳＷトピックは、第三世代パートナーシッププロジェクト（３ＧＰＰ）、スモールセルフォーラム（ＳＣＦ）、および無線ブロードバンドアライアンス（ＷＢＡ）等の規格化、研究者、および産業団体によって取り組まれている。そのような膨大な関心は、ＩＳＷネットワークに対する種々のネットワークアーキテクチャ、加入者サービスオプション、およびポリシ管理機構の開発を促すであろう。

３ＧＰＰ ＴＳ２３．４０２では、進化型パケットコア（ＥＰＣ）と非３ＧＰＰネットワーク（例えば、ＷＬＡＮ）との間のコアネットワーク（ＣＮ）ベースのインタワーキングのための３ＧＰＰ技術仕様が、導入されている。３ＧＰＰ ＴＳ２３．４０２文書は、信頼広域ネットワーク（ＴＷＡＮ）と３ＧＰＰ進化型パケットコア（ＥＰＣ）との間のインタワーキングのための完全なアーキテクチャ、インターフェース、アクセス、およびハンドオーバプロシージャを提供する。図１は、ＴＷＡＮが３ＧＰＰ ＥＰＣネットワークとインタワーキングするためのネットワークアーキテクチャを示す。示されるように、ＴＷＡＮは、Ｓ２ａインターフェースを介して、パケットデータネットワーク（ＰＤＮ）ＧＷにアクセスする。したがって、開発された３ＧＰＰ ＥＰＣ−ＷＬＡＮインタワーキングアーキテクチャは、システム間ハンドオーバ（ロング・ターム・エボリューション（ＬＴＥ）からＷｉ−Ｆｉおよびその逆）をパケットデータネットワークゲートウェイ（Ｐ−ＧＷ）において発生させ、これは、特に、予期される多数のスモールセル展開を伴って、大きな負担をモバイルコアネットワーク（ＭＣＮ）に生じさせ得る。

ＥＰＣの基本的アーキテクチャ原理は、データプレーンおよび制御プレーンを別個にハンドリングすることであるため（すなわち、ＭＭＥ／Ｓ−ＧＷ）、ＴＷＡＮ拡張を伴う、モビリティ管理エンティティ（ＭＭＥ）拡張は、システム間モビリティ管理信号伝達のための論理選択肢を提供し得る一方、対応するＳ−ＧＷ拡張は、システム間ユーザプレーン機能性をサポートし得る。モビリティ管理エンティティ（ＭＭＥ）は、Ｓ−ＧＷがＬＴＥおよびＷｉ−Ｆｉアクセスの両方のための共通ユーザプレーンゲートウェイとして機能することを可能にしながら、ＬＴＥおよびＷｉ−Ｆｉアクセスの両方のための共通制御プレーンエンティティに拡張され得る。図２に示される参照点Ｓ１ａ−ＭＭＥおよびＳ１ａ−Ｕは、３ＧＰＰ ＥＰＣ−ＷＬＡＮ統合アーキテクチャにおいて上記に導入されている。ＭＭＥ２０２は、制御プレーン信号伝達のために、Ｓ１ａ−ＭＭＥ参照点を介してＷＬＡＮ ＡＮ２０４に接続され、Ｓ１ａ−Ｕ参照点は、ユーザプレーンのために、ＷＬＡＮ ＡＮ２０４とサービングゲートウェイＳ−ＧＷ２０６との間に定義される。そのようなＭＭＥ／Ｓ−ＧＷ統合アンカポイントを有することは、より効率的ハンドオーバプロシージャにつながるであろう。

これらの拡張は、ネットワークのエッジにより近づけてシステム間モビリティプロシージャの実行をイネーブルにすることによって、性能を改良することができる。待ち時間は、コアネットワークの深部、すなわち、ＰＤＮゲートウェイ（Ｐ−ＧＷ）２０８に向けての信号伝達プロシージャの必要性を最小限にすることによって低減され得る。これは、特に、モバイルネットワークオペレータ（ＭＮＯ）がスモールセルおよびＷｉ−Ｆｉアクセスの両方を共通の地理的エリアにおいて展開するときに有益であり得る。スケーラビリティもまた、Ｐ−ＧＷ２０８処理負担を低減させることによって、例えば、いくつかのシステム間モビリティ機能をＭＭＥ２０２およびＳ−ＧＷ２０６に分散させることによって改良される。

ＡＫＡアルゴリズムに関する総合的背景が、鍵生成階層を伴う、ユーザ機器（ＵＥ）２１４とネットワークとの間の相互認証を含め、以下に与えられる。次いで、そのような一般的認証および鍵共有（ＡＫＡ）アルゴリズムが、３ＧＰＰ（ＥＰＳ ＡＫＡ）およびＷＬＡＮ（ＥＡＰ−ＡＫＡ’）ネットワークに関して説明される。

図３は、ＵＥ２１４と、ＭＭＥ２０２およびホーム加入者サーバ（ＨＳＳ）２１０（ホーム環境（ＨＥ）または認証センタ（ＡｕＣ）３０４）を含む、ネットワークとの間の相互認証のために使用される、ＡＫＡプロシージャ（３ＧＰＰ ＴＳ３３．１０２の第６．３節）を描写する。示されるように、ＭＭＥは、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ ｒｅｑｕｅｓｔ」をＨＳＳ／ＡｕＣに送信する。それに応答して、ＨＳＳ／ＡｕＣは、複数の認証ベクトル（ＡＶ）を生成し、シーケンス番号（ＳＱＮ）に基づいて、それらを順序付ける。認証ベクトルは、乱数（ＲＡＮＤ）、予期される応答（ＸＲＥＳ）、暗号鍵（ＣＫ）、保全性鍵（ＩＫ）、および認証トークン（ＡＵＴＮ）から成る。

ＡＶを生成するプロセスは、図４に説明される。最初に、ＡｕＣ３０４は、新たなシーケンス番号、ＳＱＮ、および予測不能なチャレンジＲＡＮＤを生成することから開始する。Ｋは、ユニバーサル加入者識別モジュール（ＵＳＩＭ）上およびＡｕＣ３０４内に記憶される永続鍵である。認証および鍵管理フィールド（ＡＭＦ）が、各認証ベクトルの認証トークン内に含まれる。機能ｆ１およびｆ２は、それぞれ、メッセージ認証コード（ＭＡＣ）およびＸＲＥＳを生成する、メッセージ認証機能である。機能ｆ３、ｆ４、およびｆ５は、ＣＫ、ＩＫ、および匿名鍵（ＡＫ）を生成するために使用される、鍵生成機能である。ＡＫは、後者がユーザの識別および場所を暴露し得るため、シーケンス番号を隠蔽するために使用される匿名鍵である。最後に、認証トークンＡＵＴＮが、ＳＱＮ、ＡＫ、ＡＭＦ、およびＭＡＣに基づいて形成される。各認証ベクトルは、ＭＭＥ２０２とＵＥ２１４との間の１つのみのＡＫＡプロセスに対して有効である。

図３に戻ると、いったんＡｕＣ／ＨＳＳは、ＡＶを生成すると、それらをＭＭＥ２０２に送信する。その結果、ＭＭＥ２０２は、相互認証プロセスをＵＥ２１４と開始する。最初に、ＭＭＥ２０２は、次の未使用認証ベクトルを認証ベクトルＡＶの順序付けられたアレイから選択し、「ｕｓｅｒ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｅｓｔ」（ＲＡＮＤ、ＡＵＴＮ）メッセージをＵＥに送信する。

ＲＡＮＤおよびＡＵＴＮの受信に応じて、ＵＳＩＭ／ＵＥは、図５に示されるユーザ認証プロシージャを適用する。最初に、ＵＳＩＭは、ＡＫを算出し、シーケンス番号ＳＱＮを読み出す。次に、予期されるＭＡＣ（ＸＭＡＣ）を計算する。ＵＳＩＭは、受信されたＡＵＴＮが生成されたものと同一であることを検証することによって、より具体的には、生成されたＸＭＡＣが受信されたＭＡＣと同一であって、受信されたＳＱＮが正しい範囲内にあることを検証することによって、ネットワークを認証する。

最後に、図３に戻ると、いったんＵＥ３０２は、ネットワークを認証すると、その生成された応答（ＲＥＳ）をＭＭＥ２０２に送信する。次いで、ＭＭＥ２０２は、受信されたＲＥＳとそのＸＲＥＳ（ＨＳＳによって生成され、そこから受信される）を比較する。ＲＥＳおよびＸＲＥＳが合致する場合、ＭＭＥ２０２は、ＵＥ３０２を認証する。このように、ＵＥとネットワークとの間の相互認証およびＡＫＡプロセスは、正常に完了される。最後に、ＵＥ２１４およびＭＭＥ２０２における残りの鍵、すなわち、ＣＫおよびＩＫが、暗号ならびに保全性機能のためのより多くの鍵を導出するために利用される。

ＬＴＥに関して、「Ｕｓｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」は、「ＮＡＳ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」内に実装される。同様に、「Ｕｓｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ」も、「ＮＡＳ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ」内に実装される。ＷＬＡＮの場合、「Ｕｓｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」は、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」および「ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ」メッセージを介して実装される。「Ｕｓｅｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ」は、「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ」および「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」を使用して実装される。

ＵＥ２１４とＥＰＣネットワーク２１６との間のセキュリティプロシージャは、３ＧＰＰ ＴＳ３３．４０１の第６節に詳細に説明されている。セキュリティプロシージャは、初期アタッチメントプロシージャの基本的ステップである（３ＧＰＰ ＴＳ２３．４０１の第５．３．２節）。本項は、３ＧＰＰ ＥＰＣにおける正確な認証関連メッセージに焦点を当てる。特に、本項は、Ｓ６ａ参照点を経由してＭＭＥ２０２とＨＳＳ２１０との間で交換されるダイアメータベースのメッセージに焦点を当てる。提示されるメッセージは、図３に示される一般的「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ ｒｅｑｕｅｓｔ」および「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ ｒｅｓｐｏｎｓｅ」に対応する。

ＭＭＥは、ＨＳＳのための認証ベクトルを要求するために、３ＧＰＰ ＴＳ２９．２７２の第５．２．３節に示されるように、ダイアメータベースの「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ（ＡＩＲ）」コマンドをＳ６ａ参照点を経由して送信する。ＡＩＲコマンドの関連属性−値対（ＡＶＰ）のうちのいくつかが、表１に示される。ＵＥ３０２は、その「Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ（ＩＭＳＩ）」を使用して識別されるであろう。「Ｒｅｑｕｅｓｔｅｄ−ＥＵＴＲＡＮ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏ」ＡＶＰ（３ＧＰＰ ＴＳ２９．２７２の第７．３．１１節）は、Ｅ−ＵＴＲＡＮのための認証要求に関連する情報、すなわち、「Ｎｕｍｂｅｒ−Ｏｆ−Ｒｅｑｕｅｓｔｅｄ−Ｖｅｃｔｏｒｓ」、「Ｉｍｍｅｄｉａｔｅ−Ｒｅｓｐｏｎｓｅ−Ｐｒｅｆｅｒｒｅｄ」、および「Ｒｅ−ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ−Ｉｎｆｏ」ＡＶＰを含有するものとする。サービングネットワーク識別（ＳＮ ＩＤ）とも称される、「Ｖｉｓｉｔｅｄ−ＰＬＭＮ−Ｉｄ」ＡＶＰ（３ＧＰＰ ＴＳ２９．２７２の第７．３．９節）は、モバイル国コード（ＭＣＣ）およびモバイルネットワークコード（ＭＮＣ）の連結を含有するものとする。

ＡＩＲコマンドに応答して、ＨＳＳは、３ＧＰＰ ＴＳ２９．２７２の第５．２．３節に示されるように、Ｓ６ａ参照点を経由して、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ（ＡＩＡ）」コマンド内で認証ベクトルをＭＭＥに提供する。表２は、ＡＩＡコマンドの関連ＡＶＰのうちのいくつかを提供する。「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏ」ＡＶＰ（３ＧＰＰ ＴＳ２９．２７２の第７．３．１７節）は、複数の３ＧＰＰ ＲＡＴのための要求される認証ベクトル、すなわち、「Ｅ−ＵＴＲＡＮ−Ｖｅｃｔｏｒ」、「ＵＴＲＡＮ−Ｖｅｃｔｏｒ」、および「ＧＥＲＡＮ−Ｖｅｃｔｏｒ」を含有する。特に着目すべきものは、以下の認証情報、すなわち、「Ｉｔｅｍ−Ｎｕｍｂｅｒ」、「ＲＡＮＤ」、「ＸＲＥＳ」、「ＡＵＴＮ」、および「Ｋ_ＡＳＭＥ」を含む、Ｅ−ＵＴＲＡＮベクトルである、「Ｅ−ＵＴＲＡＮ−Ｖｅｃｔｏｒ」ＡＶＰ（３ＧＰＰ ＴＳ２９．２７２の第７．３．１８節）である。Ｋ_ＡＳＭＥは、アクセスセキュリティ管理エンティティ鍵（ＡＳＭＥ）である。

非３ＧＰＰアクセス認証信号伝達が、ＳＴａ参照点（ＴＷＡＮ−ＡＡＡサーバ）およびＳＷｘ（ＡＡＡサーバ−ＨＳＳ）を横断して、３ＧＰＰ ＡＡＡ２１２サーバ２１２を通してＵＥ２１４とＨＳＳ２１０との間で実行される。最初に、ＵＥは、拡張認証プロトコル（ＥＡＰ）認証プロセスをＴＷＡＮ２１８に向けて開始し、これは、ＥＡＰメッセージを３ＧＰＰ ＡＡＡサーバ２１２に転送する。３ＧＰＰ ＡＡＡサーバ２１２およびＨＳＳ２１０は、上記の図３で示される標準的ＡＫＡプロシージャに従って相互作用する。ＥＰＣネットワークへのＴＷＡＮのアクセスのためのＥＡＰ−ＡＫＡ’セキュリティプロシージャは、ＴＳ３３．４０２の第６．２節に詳細に説明されている。以下は、上記の図３で示される一般的「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ ｒｅｑｕｅｓｔ」および「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｄａｔａ ｒｅｓｐｏｎｓｅ」にマップする、ＡＡＡサーバ２１２とＨＳＳ２１０との間のダイアメータベースのメッセージの詳細を説明する。

３ＧＰＰ ＡＡＡサーバ２１２は、ＴＷＡＮ接続ＵＥ２１４を認証するために、ＳＷｘ参照点を経由してダイアメータベースの「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＨＳＳ２１０に送信する。表３は、我々が着目する「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージのいくつかのＡＶＰを示す。示されるように、３ＧＰＰ ＡＡＡサーバ２１２は、「ＩＭＳＩ」、「Ｎｕｍｂｅｒ ｏｆ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｉｔｅｍｓ」、「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ（＝ＷＬＡＮ）」、および「Ａｃｃｅｓｓ Ｔｙｐｅ（＝ＷＬＡＮ）」ＡＶＰを含む。

３ＧＰＰ ＡＡＡサーバ２１２からの「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージへの応答として、ＨＳＳ２１０は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｎｓｗｅｒ」メッセージをＡＡＡサーバ２１２に送信することによって応答する。「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｎｓｗｅｒ」コマンドは、ＳＷｘ参照点を経由して送信される。ダイアメータベースの「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｎｓｗｅｒ」コマンドの最も関連するＡＶＰは、表４に示される。示されるように、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ」ＡＶＰを含み、そのコンテンツは、表５に示される。示されるように、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ」ＡＶＰは、全ての必要とされる認証／認可パラメータ（ＲＡＮＤ、ＡＵＴＮ、ＸＲＥＳ）および鍵（ＣＫ、ＩＫ）を含有する。

ＥＰＳ／Ｅ−ＵＴＲＡＮアクセスのための鍵階層は、図６に示される（３ＧＰＰ ＴＳ３３．４０１）。示されるように、永続鍵Ｋは、ＵＥ（ＵＳＩＭ）およびネットワーク（ＨＳＳ／ＡｕＣ３０４）の両方に記憶される。最初に、ＵＥ２１４およびＨＳＳ２１０の両方は、中間鍵対ＣＫおよびＩＫを導出する。次いで、それらは、３ＧＰＰ ＴＳ３３．４０１の付属Ａ．２に説明されるように、ＣＫ、ＩＫ、およびサービングネットワーク識別（ＳＮ ＩＤ）を使用して、Ｋ_ＡＳＭＥを導出する。Ｋ_ＡＳＭＥは、その後、上記の表２で説明された「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」メッセージを使用して、ＭＭＥ２０２に送信される。

次いで、ＵＥ２１４およびＭＭＥ２０２は、３ＧＰＰ ＴＳ３３．４０１の付属Ａ．７に説明される鍵導出関数（ＫＤＦ）を使用して、ＮＡＳ鍵、すなわち、Ｋ_{ＮＡＳｅｎｃ}（ＮＡＳ暗号化鍵）およびＫ_{ＮＡＳｉｎｔ}（ＮＡＳ保全性保護鍵）を導出する。さらに、ＭＭＥ２０２およびＵＥ２１４は、３ＧＰＰ ＴＳ３３．４０１の付属Ａ．３に定義されるように、Ｋ_ＡＳＭＥおよびアップリンクＮＡＳ ＣＯＵＮＴを使用して、ｅＮＢセキュリティ鍵（Ｋ_ｅＮＢ）を導出する。その後、ｅＮＢは、「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ」メッセージ内に含有されるＫ_ｅＮＢをＭＭＥ２０２から受信する。最後に、ＵＥ２１４およびｅＮＢは、３ＧＰＰ ＴＳ３３．４０１の付属Ａ．７に説明されるＫＤＦを使用して、ユーザプレーン（Ｋ_{ＵＰｉｎｔ}、Ｋ_{ＵＰｅｎｃ}）およびＲＲＣ（Ｋ_{ＲＲＣｉｎｔ}、Ｋ_{ＲＲＣｅｎｃ}）伝送のための必要とされる鍵を導出する。

ＭＭＥ２０２は、「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ」メッセージを使用して、（Ｋ_ｅＮＢ）をｅＮＢに送信する。一般に、「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ」メッセージは、ＵＥコンテキストの設定を要求するために送信される（ＴＳ３６．４１３の第９．１．４節）。「Ｓｅｃｕｒｉｔｙ Ｋｅｙ」情報要素（ＩＥ）（Ｋ_ｅＮＢ）は、セキュリティをｅＮＢ内に適用するために使用される（ＴＳ３６．４１３の第９．２．１．４１節）。

本項では、図７に示される、ＴＷＡＮのためのＡＫＡ’鍵階層が、議論される。図６におけるＥＰＳシナリオと同様に、鍵対ＣＫおよびＩＫが、ＵＥ２１４およびＨＳＳにおいて導出される。次いで、新しい対の鍵、すなわち、ＣＫ’およびＩＫ’が、「ａｃｃｅｓｓ ｎｅｔｗｏｒｋ ｉｄｅｎｔｉｔｙ」を利用して導出される。３ＧＰＰ ＴＳ３３．４０２の付属Ａ．２は、ＣＫ’、ＩＫ’をＣＫ、ＩＫ、および「ａｃｃｅｓｓ ｎｅｔｗｏｒｋ ｉｄｅｎｔｉｔｙ」から導出する方法を示す。鍵ＣＫ’、ＩＫ’は、上記の表４で説明された「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ａｎｓｗｅｒ」メッセージを使用して、３ＧＰＰ ＡＡＡサーバに送信される。次いで、マスタ鍵（ＭＫ）が、以下のように、ＵＥおよび３ＧＰＰ ＡＡＡサーバにおいて導出される（ＩＥＴＦ ＲＦＣ５４４８の第３．３節）：
ＭＫ＝ＰＲＦ’（ＩＫ’｜ＣＫ’，”ＥＡＰ−ＡＫＡ’”｜Ｉｄｅｎｔｉｔｙ）
Ｋ＿ｅｎｃｒ＝ＭＫ［０．．１２７］；Ｋ＿ａｕｔ＝ＭＫ［１２８．．３８３］；Ｋ＿ｒｅ＝ＭＫ［３８４．．６３９］；
ＭＳＫ＝ＭＫ［６４０．．１１５１］；ＥＭＳＫ＝ＭＫ［１１５２．．１６６３］

式中、ＰＲＦ’は、擬似乱数関数であって、Ｋ＿ｅｎｃｒは、１２８ビット暗号化鍵（データ暗号化のため）であって、Ｋ＿ａｕｔは、２５６ビット認証鍵（ＭＡＣのため）であって、Ｋ＿ｒｅは、２５６ビット再認証鍵（高速再認証のため）であって、ＭＳＫは、５１２ビットマスタセッション鍵であって、ＥＭＳＫは、５１２ビット拡張マスタセッション鍵である。

ＭＳＫは、ＥＡＰ方法ＩＥＴＦ ＲＦＣ３７４８によってＴＷＡＮにエクスポートされる。より具体的には、３ＧＰＰ ＡＡＡサーバは、ＩＥＴＦ ＲＦＣ４０７２に議論されるように、ダイアメータベースの「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」（ＥＡＰ−ペイロード、ＥＡＰ−Ｍａｓｔｅｒ−Ｓｅｓｓｉｏｎ−Ｋｅｙ）メッセージを送信することによって、ＭＳＫをＴＷＡＮにトランスポートする。「ＥＡＰ−Ｍａｓｔｅｒ−Ｓｅｓｓｉｏｎ−Ｋｅｙ」ＡＶＰは、ＷＬＡＮリンクを経由して使用されるべきＭＳＫを表す。

ＵＥ２１４が１つのｅＮＢから別のｅＮＢへのハンドオーバを被る、ＬＴＥ間ハンドオーバでは、ＵＥ２１４は、ネットワークに対して再び認証される必要はない。代わりに、新しいＫ_ｅＮＢのみ、ＵＥおよび標的ｅＮＢにおいて生成される。Ｋ_ｅＮＢを更新するためのプロシージャは、図８に示され、以下のように要約される（３ＧＰＰ ＴＳ３３．４０１の第７．２．８節）。最初に、ＵＥ２１４およびＭＭＥ２０２は、Ｋ_ＡＳＭＥ鍵を使用して、Ｋ_ｅＮＢおよび次のＨｏｐパラメータ（ＮＨ）を導出するであろう。ＮＨ連鎖カウンタ（ＮＣＣ）が、各Ｋ_ｅＮＢおよびＮＨパラメータと関連付けられる。ＭＭＥ２０２は、Ｋ_ｅＮＢ鍵または｛ＮＨ、ＮＣＣ｝対をｅＮＢに送信することができる。ハンドオーバ時、基礎Ｋ_ｅＮＢ＊が、最初に、Ｋ_ｅＮＢ（水平鍵導出）またはＮＨ（垂直鍵導出）のいずれかを使用して導出される。最後に、ＮＨまたはＫ_ｅＮＢはさらに、標的物理セルＩＤ（ＰＣＩ）およびそのダウンリンク進化型絶対無線周波数チャネル番号（ＥＡＲＦＣＮ−ＤＬ）に結び付けられる。

高速再認証は、ＥＰＣ２１６へのＴＷＡＮ２１８アクセスのために行われることができる。この場合、ＨＳＳ２１０は、完全認証の場合と同じように関わらないであろう。高速再認証プロシージャは、ＵＥとＴＷＡＮとの間で使用されるべき新しいＭＳＫを生成することを目的とする。３ＧＰＰ ＴＳ３３．４０２の第６．３節は、これについて詳細に説明している。

「ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ」メッセージ（ＩＥＴＦ ＲＦＣ４１８７の第９．７節）メッセージが、いったん３ＧＰＰ ＡＡＡサーバが再認証ＩＤを受信すると、３ＧＰＰ ＡＡＡサーバからＵＥに送信される。これは、以下の属性、すなわち、ＣＯＵＮＴＥＲ、ＮＯＮＣＥ、ＭＡＣ、および新しい再認証ＩＤを含む。第１に、ＣＯＵＮＴＥＲは、１６ビット符号なし整数カウンタ値（ＩＥＴＦ ＲＦＣ４１８７の第１０．１６節）である。ＣＯＵＮＴＥＲは、完全認証プロシージャにおけるものに初期化される。第２に、ＮＯＮＣＥは、本ＥＡＰ−ＡＫＡ’高速再認証のためにＡＡＡサーバによって新たに生成された乱数（１６バイト）である（ＩＥＴＦ ＲＦＣ４１８７の第１０．１８節）。乱数は、ＵＥのためのチャレンジとして、また、新しい鍵化材料のためのシード値として使用される。第３に、ＭＡＣ属性は、ＥＡＰパケットを全体として網羅するメッセージ認証コード（ＭＡＣ）を含有する。ＭＡＣは、全体的ＥＡＰパケットにわたって計算され（この場合、ＮＯＮＣＥ）、随意のメッセージ特有のデータと連結される（ＩＥＴＦ ＲＦＣ４１８７の第１０．１５節）。最後に、新しい再認証ＩＤが、次の高速再認証において使用されるであろう。

高速再認証では、以下の鍵が、計算される（ＩＥＴＦ ＲＦＣ５４４８）。
ＭＫ＝ＰＲＦ’（Ｋ＿ｒｅ，”ＥＡＰ−ＡＫＡ’ｒｅ−ａｕｔｈ”｜Ｉｄｅｎｔｉｔｙ｜ＣＯＵＮＴＥＲ｜ＮＯＮＣＥ）
ＭＳＫ＝ＭＫ［０．．５１１］
式中、ＭＫは、マスタ鍵であって、ＰＲＦは、擬似乱数関数である。高速再認証時、同一擬似乱数生成器が、使用され、新しいＭＳＫを生成することができる（ＩＥＴＦ ＲＦＣ４１８７）。Ｋ＿ｒｅは、先行完全認証からの再認証鍵であって、それに基づいて発生し得る任意の高速再認証にわたって不変のままである。最後に、ＣＯＵＮＴＥＲおよびＮＯＮＣＥが、サーバにおいて生成される。

現在の３ＧＰＰインタワーキングアーキテクチャでは、ＲＡＴ間ハンドオーバを行うことを決定する、マルチＲＡＴ（ＬＴＥ／ＷＬＡＮ）ＵＥは、ハンドオーバを行う前に、完全認証プロシージャを起動する必要があるであろう（ＴＳ２３．４０２）。スモールセルがＷｉ−Ｆｉネットワークと共存するとき、ＵＥがＬＴＥとＷＬＡＮとの間の各ハンドオーバにおいて完全な再認証を起動することを要求することは、非効率的である。

マルチＲＡＴ ＵＥは、現在、ＨＳＳと認証を行うための２つの独立経路を有し（ＭＭＥまたは３ＧＰＰ ＡＡＡサーバのいずれかを介して）、反復認証メッセージをＨＳＳに生じさせる。以下に説明される実施形態は、スモールセルおよびＷｉ−Ｆｉ認証のためのＵＥとＨＳＳとの間の１つの統一認証経路を使用する。

第１に、新しい３ＧＰＰ ＥＰＣ−ＴＷＡＮインタワーキングアーキテクチャは、ＭＭＥにマルチＲＡＴ ＵＥからの認証要求を管理させる。言い換えると、３ＧＰＰ ＡＡＡサーバは、ＩＳＷＮベースのＵＥからのいかなる認証プロシージャもハンドリングしないであろう。そのために、新しい参照点、すなわち、ＳＴｂが、ＴＷＡＮとＭＭＥとの間に追加される。

第２に、新しい統一認証プロシージャが、追加され、ＩＳＷＮベースのマルチＲＡＴ ＵＥが、その現在のアクセスネットワーク（ＴＷＡＮまたはＨｅＮＢ）にかかわらず、ＨＳＳと直接認証されることを可能にする。統一認証プロシージャは、ＵＥとＭＭＥとの間の相互認証をイネーブルにし、ＷＬＡＮおよびＬＴＥアクセスネットワークの両方のための鍵を提供する。ＴＷＡＮ開始およびＨｅＮＢ開始認証は両方とも、それぞれ、ＴＷＡＮまたはＨｅＮＢのいずれかを介して、ＵＥによって行われることができる。

第３に、ＲＡＴ間ハンドオーバシナリオのための新しい高速再認証プロシージャが、行われる。再認証プロシージャは、要求される鍵を生成することのみに集中することによって、相互認証ステップを簡略化する。言い換えると、高速再認証プロシージャは、再認証プロセスにおいてＨＳＳを伴わず、これは、コアネットワーク上の負担を低減させる。ＩＳＷＮ内（ＴＷＡＮ／ＨｅＮＢおよびＨｅＮＢ−ＴＷＡＮ）およびＴＷＡＮ／ｅＮＢハンドオーバシナリオの両方が、説明される。

最後に、認証プロシージャを実行するための種々の標準的プロトコルメッセージに対する拡張が、説明される。拡張されたメッセージは、Ｓ６ａ参照点（ＭＭＥ−ＨＳＳ）を経由して、後続層、プロトコル、および参照点：ＲＲＣ、Ｓ１−ＡＰ、ＮＡＳ、ＥＡＰ、およびダイアメータに及ぶ。

これらの変更は、既存の３ＧＰＰインタワーキングアーキテクチャに取って代わる必要はない。むしろ、それらは、スモールセルおよびＷｉ−Ｆｉネットワークが緊密に統合されるときに使用され得る、より効率的代替を提供することができる。

本書における実施例は、ＬＴＥ等のライセンススペクトルで動作する無線アクセス技術とＷｉ−Ｆｉ等のアンライセンスで動作する無線アクセス技術との間のハンドオーバに対処するが、本概念は、任意の２つの無線アクセス技術間のハンドオーバに適用されることができることを理解されたい。

本概要は、発明を実施するための形態において以下でさらに説明される、一連の概念を簡略化形態において導入するために提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図しておらず、また、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分に記載される一部または全ての不利点を解決するという限界にも限定されない。

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。

図１は、ＥＰＣへの信頼ＷＬＡＮアクセスのための非ローミングアーキテクチャを図示する、略図である。 図２は、太字の付加的参照点で３ＧＰＰ ＥＰＣ−ＷＬＡＮ ＭＭＥ／Ｓ−ＧＷアンカされたＩＳＷＮアーキテクチャを図示する、略図である。 図３は、認証および鍵共有（ＡＫＡ）を図示する、略図である。 図４は、認証ベクトルの生成を図示する、略図である。 図５は、ＵＳＩＭにおけるユーザ認証機能を図示する、略図である。 図６は、Ｅ−ＵＴＲＡＮのための鍵階層を図示する、略図である。 図７は、ＴＷＡＮのための鍵階層を図示する、略図である。 図８は、ハンドオーバ鍵連鎖のためのモデルを図示する、略図である。 図９は、ＩＳＷＮ ＵＥのための２つのパラレル認証経路を図示する、略図である。 図１０は、ＩＳＷＮにおける頻繁なＴＷＡＮ−ＨｅＮＢハンドオーバのコールフローを図示する、略図である。 図１１は、統一認証統合ＥＰＣ−ＴＷＡＮアーキテクチャを図示する、略図である。 図１２は、ＨｅＮＢベースの統一認証／アタッチメントプロシージャのコールフローを図示する、略図である。 図１３は、ＴＷＡＮベースの統一認証／アタッチメントプロシージャのコールフローを図示する、略図である。 図１４は、高速再認証プロシージャを用いたＨｅＮＢ／ＴＷＡＮハンドオーバのコールフローを図示する、略図である。 図１５は、ＥＡＰ−ＲＰに基づく再認証のコールフローを図示する、略図である。 図１６は、高速再認証プロシージャを用いたＴＷＡＮ／ＨｅＮＢハンドオーバのコールフローを図示する、略図である。 図１７は、高速再認証プロシージャを用いたＴＷＡＮ／ｅＮＢハンドオーバのコールフローを図示する、略図である。 図１８は、統合ＥＰＣおよび非信頼ＷＬＡＮネットワークアーキテクチャを図示する、略図である。 図１９は、非信頼ＷＬＡＮ（下側）および信頼ＷＬＡＮ（上側）シナリオにおけるＵＥ−ＨＳＳ経路を図示する、略図である。 図２０は、本発明の実施形態と併用するための例示的グラフィカルユーザインターフェースを図示する、略図である。 図２１Ａは、ＩｏＴイベント管理システムおよび方法の１つまたはそれを上回る開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）またはモノのインターネット（ＩｏＴ）通信システムの略図である。 図２１Ｂは、図２１Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２１Ｃは、図２１Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２１Ｄは、図２１Ａの通信システムの側面が具現化され得る、例示的コンピューティングシステムのブロック図である。

図９は、ＩＳＷＮを介してＥＰＣ２１６にアクセスするマルチＲＡＴ ＵＥ２１４のための２つの異なる認証経路を描写する。ＵＥ２１４は、上側経路上でのＬＴＥ接続のために、ＨｅＮＢ２２０およびＭＭＥ２０２を通して、ＨＳＳ２１０とＡＫＡアルゴリズムを行う、または下側経路上でのＷＬＡＮ接続のために、ＴＷＡＮおよびＡＡＡサーバを通して、ＨＳＳ２１０とＡＫＡアルゴリズムを執行する。ＵＥ２１４がＲＡＴ間ハンドオーバを行うとき、ＭＭＥ２０２またはＡＡＡサーバ２１２のいずれかを介して、ＨＳＳ２１０との認証プロシージャを再実行する必要がある。ＭＭＥ２０２および３ＧＰＰ ＡＡＡサーバ２１２の役割は、類似する。

統合スモールセル／Ｗｉ−Ｆｉネットワークでは、ＭＭＥ２０２およびＡＡＡサーバ２１２の両方によって提供される類似機能性を用いて、各ハンドオーバイベントにおいて完全認証プロシージャを再実行することは非効率的である。

図９に図示される機能性は、以下に説明される図２１Ｃまたは２１Ｄに図示されるものの１つ等、無線デバイスまたは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよいことを理解されたい。また、図９に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。また、図９に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。

図１０は、本プロシージャを詳細に説明する。最初に、ＵＥ２１４が、電源が投入され、ＬＴＥを使用することを所望すると仮定されたい。図１０のステップ１では、ＵＥ２１４は、ＨｅＮＢを介して、「Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ」プロシージャをＭＭＥ２０２に向けて開始する。それに応答して、図１０のステップ２では、ＭＭＥ２０２は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＨＳＳ２１０に送信する。図１０のステップ３では、ＨＳＳ２１０は、ＡＫＡアルゴリズムを起動し、認証ベクトルおよび中間鍵を生成する。

図１０のステップ４では、ＨＳＳは、認証ベクトルおよび鍵をＭＭＥに送信する。次いで、ＭＭＥは、必要とされる鍵を導出する。図１０のステップ６では、ＵＥ２１４とＭＭＥ２０２との間の相互認証プロシージャが、実行され、その間、ＵＥは、ＡＫＡアルゴリズムを起動し、必要とされる鍵および検証を生成する。図１０のステップ７では、いったん認証が完了すると、ＭＭＥは、セッション作成プロシージャをＳ−ＧＷ／Ｐ−ＧＷに向けて開始する。その結果、ＧＴＰトンネルが、ＨｅＮＢ２２０とＳ−ＧＷ／Ｐ−ＧＷ１００２との間に確立される。さらに、図１０のステップ８では、無線およびアクセスベアラ確立のためのＬＴＥプロシージャが、ＵＥ２１４、ＨｅＮＢ２２０、およびＭＭＥ２０２間で行われる。

しばらくして、図１０のステップ９では、ＵＥ２１４は、ＷＬＡＮを発見し、ＴＷＡＮ２１８にハンドオーバを行うことを所望する。故に、図１０のステップ１０では、ＵＥ２１４は、ＴＷＡＮ２１８との接続を開始するであろう。図１０のステップ１１では、ＴＷＡＮ２１８およびＵＥ２１４は、初期ＥＡＰ認証プロシージャを有するであろう。いったん完了すると、図１０のステップ１４および１５では、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」が、ＡＡＡサーバ２１２およびＨＳＳ２１０に向けて送信される。ＭＭＥ２０２および３ＧＰＰ ＡＡＡサーバ２１２の役割は、図１０のステップ２および１３におけるものと類似する。図１０のステップ１４では、ＨＳＳ２１０は、ＡＫＡアルゴリズムを起動し（ステップ３に類似する）、認証ベクトルおよび中間鍵を生成する。これらの認証ベクトルは、ＵＥ２１４を認証するために必要とされ、これは、上記の図１０のステップ６においてすでに認証されている。

図１０のステップ１５では、ＨＳＳ２１０は、認証ベクトルおよび鍵をＡＡＡサーバに送信する。故に、ステップ１６では、ＡＡＡサーバ２１２は、必要とされる鍵を導出する。再び、ＭＭＥ２０２および３ＧＰＰ ＡＡＡサーバ２１２の役割は、図１０のステップ５および１６におけるものと類似する。次いで、図１０のステップ１７では、図１０のステップ６におけるものに類似する相互認証が、３ＧＰＰ ＡＡＡサーバ２１２とＵＥ２１４との間で行われるであろう。本プロシージャは、図１０のステップ６と同様に、ＵＥ２１４側における鍵生成を含む。その結果、図１０のステップ１８では、ＴＷＡＮ２１８は、３ＧＰＰ ＡＡＡサーバ２１２を介して（Ｓ２ａ参照点を経由して）、「セッション作成」プロシージャをＳ−ＧＷ／Ｐ−ＧＷ１００２に向けて開始し、これは、ＴＷＡＮ２１８とＳ−ＧＷ／Ｐ−ＧＷ１００２との間のＧＴＰトンネルを有することによって完結される。代替として、ＴＷＡＮ２１８は、Ｓ１ａ−ＭＭＥ参照点（図２に示される）を経由して、ＭＭＥ２０２を介してセッション作成を開始することができる。最後に、図１０のステップ１９では、認証プロシージャが、完了され、ＷＬＡＮ接続が、確立される。

図１０から、ＬＴＥアクセスを使用しているＵＥ２１４が、ＴＷＡＮ２１８にハンドオーバすることを所望する場合、現在の規格では、認可のために、３ＧＰＰ ＡＡＡサーバ２１２を介して、ＨＳＳ２１０に再びコンタクトするであろう。言い換えると、図１０は、ＩＳＷＮ内ＲＡＴ間ハンドオーバにおける冗長認証プロシージャを明確にする。より正確には、図１０におけるハンドオーバプロシージャの短所は、以下である。
１． ＨＳＳ２１０は、図１０のステップ３および１４におけるように、２回、ＡＫＡアルゴリズムを起動し、認証ベクトルを生成する。
２． ＵＥ２１４は、図１０のステップ６および１７におけるように、２回、ＡＫＡアルゴリズムを起動し、認証ベクトルを生成する。
３． ＵＥ２１４およびＥＰＣ２１６は、図１０のステップ１７および６におけるように、２回、メッセージの相互認証セットを交換する。

本問題の観察において、ＩＳＷＮのＨｅＮＢ側にアタッチされているＵＥ２１４が、ＩＳＷＮのＴＷＡＮ側にハンドオーバすることを所望する場合、ＡＡＡサーバ２１２を介して、再び、ＨＳＳ２１０と完全認証プロシージャを行う必要はない。前述の使用例に基づいて、本開示において検討される問題は、以下のように述べられ得る。
・どのようにして、ＬＴＥおよびＷＬＡＮの両方のために、ＩＳＷＮにアタッチされたＵＥ２１４をＥＰＣ２１６と一度に認証を行い、ＥＰＣ２１６内のＨＳＳ２１０向け反復メッセージングを低減させるか？
この場合、ＩＳＷＮ内ＲＡＴ間ハンドオーバにおいて完全認証プロシージャを起動する必要はなくなるであろう。代わりに、高速再認証プロシージャを有することになるであろう。
・どのようにして、ＲＡＴ間ハンドオーバシナリオにおいて高速再認証を実施するか？
例えば、ＨＳＳ２１０は、再認証プロセスに関わることが必要とされなくなり得る。

図１０に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置または図２１Ｃまたは図２１Ｄに図示されるもの等、コンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る、論理エンティティであり得ることを理解されたい。すなわち、図１０に図示される方法は、図２１Ｃまたは図２１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶される、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよく、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１０に図示されるステップを行う。また、図１０に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。また、図１０に図示される任意の伝送および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で装置の通信回路によって行われ得ることを理解されたい。また、図１０に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。

図１１は、ＥＰＣ−ＴＷＡＮ統合のためのインタワーキングアーキテクチャを示す。修正されたメッセージを伴う既存の参照点は、Ｕｕ、ＳＷｕ、Ｓ１−ＭＭＥ、およびＳＧａである。図２に前述された付加的参照点は、Ｓ１ａ−ＭＭＥおよびＳ１ａ−Ｕである。新しい参照点ＳＴｂが、ＴＷＡＰ２２４とＭＭＥ２０２との間に追加される。図１１は、ＩＳＷＮ２３０内に統合されたＨｅＮＢ２２０およびＴＷＡＮ２１８を示す。本開示に提示される概念はまた、ＨｅＮＢスモールセル２２０およびＴＷＡＮ２１８が同一物理ボックス内に統合される場合にも適用可能である。

本実施例では、３ＧＰＰ ＡＡＡサーバ２１２は、利用されないであろう。代わりに、認証プロシージャのために、ＴＷＡＰ２２４が、新しいＳＴｂ参照点を介して、ＭＭＥ２０２に接続されるであろう。セッション管理（ＳＭ）プロシージャに関して、図２と同様に、ＴＷＡＮ２１８（この場合、ＴＷＡＧ２３２）が、それぞれ、Ｓ１ａ−ＭＭＥおよびＳ１ａ−Ｕ参照点を介して、ＭＭＥ２０２およびＳ−ＧＷ２０６に接続されるであろう。

統一認証プロシージャは、３ＧＰＰ ＡＡＡサーバ２１２をバイパスし、ＩＳＷＮ２３０の認証のために、ＨＳＳ２１０およびＭＭＥ２０２のみを使用することができる。しかしながら、３ＧＰＰ ＡＡＡサーバ２１２は、依然として、統一認証のために許可されない他のネットワークの認証のために同一ネットワーク内に共存する、または統一認証がサポートされないときに使用されることができる。最後に、我々は、そのようなインタワーキングアーキテクチャが、ＣＤＭＡ２０００等の３ＧＰＰ ＡＡＡサーバ２１２を利用する他の非３ＧＰＰシステムに一般化されることができると指摘する。

図１１に示されたように、ＩＳＷＮ２３０は、ＴＷＡＮ２１８およびＨｅＮＢ２２０から成る。我々は、各アクセスノード（ＨｅＮＢ２２０またはＴＷＡＮ２１８）がＩＳＷＮ２３０についてのいくつかのパラメータを用いて構成されると仮定する。これらの構成パラメータは、Ｅ−ＵＴＲＡＮネットワークタイプ（３ＧＰＰ ＴＳ３３．４０１におけるように）およびＷＬＡＮアクセスネットワーク識別（３ＧＰＰ ＴＳ２４．３０２におけるように）を含めることを目的とする。表６は、追加された構成パラメータを描写する。示されるように、第１に、「Ａｃｃｅｓｓ Ｔｙｐｅ」が、「ＩＳＷＮ」としての統合性質を示すために追加される。第２に、我々は、ＩＳＷＮ２３０のＨｅＮＢ側の「Ｎｅｔｗｏｒｋ Ｔｙｐｅ」が「Ｅ−ＵＴＲＡＮ」であるように含める。最後に、我々は、ＴＷＡＮ２１８側の「Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｔｙ」がＷＬＡＮであるように示す。これらのＩＳＷＮ構成パラメータは、ＨｅＮＢ２２０およびＴＷＡＮ２１８の両方に記憶され、それらのいずれかによって、認証／アタッチメントプロシージャ内でＭＭＥ２０２に送信されるであろう。

図１１に図示される機能性は、以下に説明される図２１Ｃまたは２１Ｄに図示されるものの１つ等、無線デバイスまたは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよいことを理解されたい。また、図１１に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。また、図１１に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。
統一認証プロシージャ

本項では、我々は、ＵＥ２１４およびネットワークがＩＳＷＮ２３０のＲＡＴの両方のための完全ＡＫＡアルゴリズムを行うことを可能にする、統一認証プロシージャを導入する。認証ステップは、初期アタッチメントプロシージャにおける最初の重要なステップである。故に、我々は、初期アタッチメントプロセスの一部として、認証プロシージャを説明するであろう。我々は、ＵＥ２１４がＩＳＷＮ２３０のＴＷＡＮ２１８またはＨｅＮＢ２２０に向けてアタッチメントを開始するかどうかに応じて、２つの場合を網羅するであろう。
ＨｅＮＢベースの統一認証／アタッチメントプロシージャ

本項では、我々は、ＵＥ２１４がＨｅＮＢ２２０を介してＩＳＷＮ２３０へのアタッチメントを開始するであろうと仮定する。故に、我々は、ＵＥ２１４に、ＭＭＥ２０２を介して相互にＨＳＳ２１０と認証させることを目的とする。さらに、Ｅ−ＵＴＲＡＮおよびＷＬＡＮ２１８の両方のための鍵材料が、導出されるはずである。統一プロシージャは、表６におけるＩＳＷＮ構成パラメータを考慮して、一度のみ、ＡＫＡアルゴリズムを起動することに依存する。

図１２は、ＨｅＮＢベースの統一認証／アタッチメントプロシージャのコールフローを描写し、以下のように説明されることができる。

図１２のステップ１では、ＵＥ２１４は、３ＧＰＰ ＴＳ３６．３３１の第５．３．３節に説明されるように、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｅｓｔａｂｌｉｓｈｍｅｎｔ」プロシージャを実施することによって、ＨｅＮＢ２２０と接続を確立することを開始する。より正確には、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＨｅＮＢ２２０に送信する。それに応答して、ＨｅＮＢ２２０は、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ」メッセージをＵＥ２１４に送信する。

図１２のステップ２では、その結果、ＵＥ２１４は、ＮＡＳ「Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ」（古いＧＵＴＩ、古いＧＵＴＩ Ｔｙｐｅ、ＵＥ Ｃｏｒｅ Ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ、Ａｔｔａｃｈ Ｔｙｐｅ等）コンテンツを搬送する、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」（ＮＡＳ：Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ、ＧＵＭＭＥＩ、Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）メッセージをＨｅＮＢに送信する。「Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ」メッセージ内に含まれる情報要素のリストは、３ＧＰＰ ＴＳ２３．４０１の第５．３．２節に述べられており、また、３ＧＰＰ ＴＳ２４．３０１の表８．２．４．１に列挙されている。グローバル一意一時識別（ＧＵＴＩ）は、３ＧＰＰ ＴＳ２３．００３に定義されるように、ＭＭＥ２０２によってＵＥ２１４に配分される。ＵＥ２１４が有効な古いＧＵＴＩを有していない場合、ＩＭＳＩが、代わりに含まれるものとする。「ＵＥ Ｃｏｒｅ Ｎｅｔｗｏｒｋ Ｃａｐａｂｉｌｉｔｙ」情報要素は、サポートされるＡＳおよびＮＡＳセキュリティプロシージャのインジケーションを含む。「Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ」ＮＡＳコンテンツに加え、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」メッセージもまた、３ＧＰＰ ＴＳ３６．３３１の第６．２．２節に示されるように、選択されたネットワークおよび古いグローバル一意ＭＭＥ識別子（ＧＵＭＭＥＩ）を示す、ＲＲＣパラメータを搬送する。

新しい「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素が、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」メッセージに追加される。本新しい情報要素は、ＵＥ１４によって使用され、ＨｅＮＢ２２０に対してＩＳＷＮのＴＷＡＮ側も含む統一認証を行うことのその所望を示す。我々は、そのようなＩＥを追加することによって、典型的認証プロシージャを行い得るため、ＵＥ２１４が後方互換性となるであろうと指摘する。同様に、図１２のステップ１では、新しい情報要素、すなわち「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」が、ＨｅＮＢ２２０からＵＥ２１４への「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ」メッセージ内に追加される。そのような情報要素は、ＨｅＮＢ２２０によって使用され、統一認証プロシージャのためのそのサポートをＵＥ２１４に示す。

図１２のステップ３では、ＨｅＮＢ２２０は、「古いＧＵＭＭＥＩ」情報要素を使用して、ＭＭＥ２０２を受信された「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」メッセージから抽出する。次いで、ＨｅＮＢ２２０は、「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」（ＮＡＳ−ＰＤＵ、Ｓｅｌｅｃｔｅｄ Ｎｅｔｗｏｒｋ、ＣＳＧ ＩＤ、Ａｃｃｅｓｓ Ｔｙｐｅ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ）メッセージをＭＭＥ２０２に送信する。オリジナルＳ１−ＭＭＥ「Ｉｎｉｔｉａｌ ＵＥ ｍｅｓｓａｇｅ」制御メッセージは、３ＧＰＰ ＴＳ３６．４１３の第８．６．２．１節に提示されている。ＣＳＧ ＩＤは、限定加入者グループ（ＣＳＧ）の識別子を示す。

我々は、ＨｅＮＢ２２０がその統合ＴＷＡＮ２１８についてのいくつかの情報を送信すると仮定する。そのような情報は、いったんＩＳＷＮが確立されると、ＨｅＮＢ２２０およびＴＷＡＮ２１８の両方において構成されることができる。より具体的には、ＨｅＮＢ２２０は、「Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」を搬送する、「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」メッセージをＭＭＥ２０２に送信するであろう。「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」は、ＴＷＡＮ側を表す（３ＧＰＰ ＴＳ２４．３０２の表８．１．１．２）。さらに、我々は、ＵＥ２１４がＩＳＷＮ２３０（ＴＷＡＮ２１８およびＨｅＮＢ２２０）に接続されていることをＭＭＥ２０２に知らせるためのＩＳＷＮの新しい「Ａｃｃｅｓｓ ｔｙｐｅ」を定義する。

図１２のステップ４では、ＥＰＳセキュリティパラメータ（ａｕｔｈｅｎｔｉｃａｔｉｏｎ、ＮＡＳ ｓｅｃｕｒｉｔｙ ｓｅｔｕｐ）を確立するために、ＭＭＥ２０２は、ＡＫＡプロシージャを開始する。特に、ＭＭＥ２０２は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」（ＩＭＳＩ、ＰＬＭＮ−ＩＤ、Ｒｅｑｕｅｓｔｅｄ−ＥＵＴＲＡＮ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏ、Ａｃｃｅｓｓ Ｔｙｐｅ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ）メッセージをＨＳＳ２１０に送信する。ＰＬＭＮ−ＩＤまたはＳｅｒｖｉｎｇ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ（ＳＮＩＤ）識別は、ＭＣＣ＋ＭＮＣと等しい。「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」メッセージの標準的ＡＶＰは、上記の表１に示される。

「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」メッセージは、ＴＷＡＮ２１８側の「Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」を含むように拡張される。

図１２のステップ５では、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」メッセージの受信に応じて、ＨＳＳ２１０は、ＡＫＡプロシージャを起動する。その結果、ＨＳＳ２１０は、ＲＡＮＤ、ＸＲＥＳ、ＣＫ、ＩＫ、およびＡＵＴＮから成る、認証ベクトル（ＡＶ）を生成する。

図１２のステップ６では、加えて、Ｅ−ＵＴＲＡＮのために、ＣＫ、ＩＫ、およびＳＮ ＩＤのセットが、暗号鍵導出関数（ＫＤＦ）にフィードされ、上記の図６に示されたように、新しい鍵、すなわち、Ｋ_ＡＳＭＥを生成する。

図１２のステップ７ではさらに、ＷＬＡＮ２１８のために、ＣＫ、ＩＫ、ａｃｃｅｓｓ ｎｅｔｗｏｒｋ ｉｄｅｎｔｉｔｙ、およびｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ（ＳＱＮ）のセットが、暗号ＫＤＦにフィードされ、上記の図７に示されたように、新しい対の鍵、すなわち、ＣＫ’およびＩＫ’を生成する。

図１２のステップ８では、いったんＨＳＳ２１０がＡＶおよび鍵を生成すると、それらを「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」（ＲＡＮＤ、ＡＵＴＮ、ＸＲＥＳ、Ｋ_ＡＳＭＥ、ＣＫ’、ＩＫ’、ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ）メッセージ内でＭＭＥ２０２に転送する。「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」メッセージの標準的ＡＶＰは、上記の表２に示されている。

３つの情報要素が、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」メッセージに追加され、それらは、ＣＫ’およびＩＫ’である。

図１２のステップ９では、ＭＭＥ２０２は、ＮＡＳ暗号化（Ｋ_{ＮＡＳｅｎｃ}）、ＮＡＳ保全性（Ｋ_{ＮＡＳｉｎｔ}）、およびまた、ＨｅＮＢセキュリティ鍵（Ｋ_ｅＮＢ）のために必要とされる鍵を生成する。上記の図６に示されたように、これらの鍵は、図１２のステップ８においてＨＳＳ２１０から前もって受信された中間鍵Ｋ_ＡＳＭＥに基づいて生成される。

図１２のステップ１０では、同様に、ＷＬＡＮのために、ＭＭＥ２０２は、図７に提示されるＷＬＡＮ２１８のための全ての必要とされる鍵、すなわち、Ｋ＿ｅｎｃｒ、Ｋ＿ａｕｔ、Ｋ＿ｒｅ、ＭＳＫ、およびＥＭＳＫを生成する。これらの鍵は、図１２のステップ８においてＨＳＳから前もって受信された中間鍵ＣＫ’およびＩＫ’に基づいて導出される。

ＭＭＥ２０２は、全ＷＬＡＮ鍵（Ｋ＿ｅｎｃｒ、Ｋ＿ａｕｔ、Ｋ＿ｒｅ、ＭＳＫ、およびＥＭＳＫ）を生成することができる。そのような鍵生成機能は、３ＧＰＰ ＡＡＡサーバ２１２からＭＭＥ２０２に移動される。

図１２のステップ１１では、いったんＡＶがＨＳＳ２１０から受信され、Ｅ−ＵＴＲＡＮおよびＷＬＡＮ鍵が生成されると、ＭＭＥ２０２は、ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージを送信することによって、ＵＥ２１４と相互認証プロセスを開始する。したがって、最初に、ＭＭＥ２０２は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」（ＲＡＮＤ、ＡＵＴＮ、ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ）メッセージをＨｅＮＢ２２０に送信する。ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの情報要素の完全なリストは、３ＧＰＰ ＴＳ２４．３０１の表８．２．７．１に示されている。再認証ＩＤは、後に、ＩＳＷＮ２３０のＴＷＡＮ２１８側に接続するであろう場合、ＵＥ２１４によって使用されるべきＭＭＥ２０２によって生成されるであろう。

「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ」および「ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ」の２つの新しい情報要素が、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージ内に追加される。「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ」情報要素は、ＷＬＡＮアクセスネットワーク識別をＵＥに伝達する（ＨｅＮＢを介して）。そのような情報要素は、ＵＥにおいて図１２の７と類似方式でＷＬＡＮ鍵生成のために使用されるために必要とされる。

図１２のステップ１２では、ＨｅＮＢ２２０は、ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＵＥ２１４に転送する。「ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ」は、ＵＥ２１４がＩＳＷＮ２３０のＴＷＡＮ２１８への接続を試みる度に、ＵＥ２１４において後に使用されるために記憶されるであろう。

図１２のステップ１３では、それに応答して、ＵＥ２１４は、上記の図５で説明されたＡＫＡアルゴリズムを起動する。ＵＥ２１４は、予期されるＡＵＴＮ（より具体的には、ＸＭＡＣ）、ＲＥＳ、ＣＫ、およびＩＫを生成する。最初に、ＵＥ２１４は、生成された予期されるＡＵＴＮがＭＭＥ２０２から受信されたＡＵＴＮに合致することを検証する。該当する場合、ＵＥ２１４は、ネットワークを認証する。

図１２のステップ１４では、ＨＳＳ２１０側で行われる図１２のステップ５および６と同様に、ＵＥ２１４は、生成された鍵ＣＫおよびＩＫとともに、「ＳＮＩＤ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ」（ＭＭＥから受信された）等の他のパラメータを使用して、中間鍵Ｋ_ＡＳＭＥ、ＣＫ’、ＩＫ’を確立する。我々は、Ｋ_ＡＳＭＥが、Ｅ−ＵＴＲＡＮ鍵を導出するために使用されるであろう（図６に示されるように）一方、ＣＫ’、ＩＫ’が、ＷＬＡＮ鍵を導出するために使用されるであろう（図７に示されるように）ことに着目する。

図１２のステップ１５では、これらの中間鍵に基づいて、ＵＥ２１４は、Ｅ−ＵＴＲＡＮおよびＷＬＡＮ伝送のための全ての必要とされる鍵を導出する。第１に、Ｅ−ＵＴＲＡＮのために（図７に従って）、ＵＥ２１４は、ＮＡＳ暗号化（Ｋ_{ＮＡＳｅｎｃ}）、ＮＡＳ保全性（Ｋ_{ＮＡＳｉｎｔ}）、ＲＲＣ暗号化鍵（Ｋ_{ＲＲＣｅｎｃ}）、ＲＲＣ保全性鍵（Ｋ_{ＲＲＣｉｎｔ}）、ユーザプレーン暗号化鍵（Ｋ_{ＵＰｅｎｃ}）、およびユーザプレーン保全性鍵（Ｋ_{ＵＰｉｎｔ}）を導出する。第２に、ＷＬＡＮのために（図７に従って）、ＵＥ２１４は、データ暗号化鍵（Ｋ＿ｅｎｃｒ）、ＭＡＣ認証鍵（Ｋ＿ａｕｔ）、再認証鍵（Ｋ＿ｒｅ）、マスタセッション鍵（ＭＳＫ）、および拡張マスタセッション鍵（ＥＭＳＫ）を導出する。

図１２のステップ１６では、ＵＥ２１４がネットワークを認証したため、ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ」（ＲＥＳ）メッセージをＭＭＥ２０２に返信する。「ＲＥＳ」情報要素は、上記の図１２のステップ１３において生成されている。ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ」メッセージの情報要素の完全なリストは、３ＧＰＰ ＴＳ２４．３０１の表８．２．８．１に表化されている。

図１２のステップ１７では、ＨｅＮＢ２２０は、ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｓｐｏｎｓｅ」（ＲＥＳ）メッセージをＭＭＥ２０２に転送する。

図１２のステップ１８では、いったんＭＭＥ２０２が「ＲＥＳ」を受信すると、それを「ＸＲＥＳ」（図１２のステップ８においてＨＳＳ２１０から受信された）と比較する。検証が成功する場合、ＭＭＥ２０２は、ＵＥ２１４を認証する。故に、ＵＥ２１４とネットワークとの間の相互認証は、正常に完了される。

図１２のステップ１９では、ＭＭＥ２０２は、標準的「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＳ−ＧＷに送信することによって、サービングＧＷ（Ｓ−ＧＷ）２０６およびＰＤＮゲートウェイ（Ｐ−ＧＷ）２０８に向けてセッションの作成を開始する。それに応答して、Ｐ−ＧＷ２０８およびＳ−ＧＷ２０６は、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ」（Ｓ−ＧＷ ＴＥＩＤ、Ｐ−ＧＷ ＴＥＩＤ）メッセージをＭＭＥ２０２に送信し、ＨｅＮＢ２２０からのアップリンク伝送において使用されるべきＴｕｎｎｅｌｉｎｇ Ｅｎｄｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ（ＴＥＩＤ）を識別する。

図１２のステップ２０では、いったんＳ−ＧＷ／Ｐ−ＧＷ１００２向けセッションが確立されると、ＭＭＥ２０２は、ＨｅＮＢ２２０セキュリティ鍵（Ｋ_ｅＮＢ）を「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ Ａｃｃｅｐｔ」（Ｋ_ｅＮＢ）メッセージ内でＨｅＮＢ２２０に送信する。本メッセージはまた、アップリンク伝送において使用されるべきＳ−ＧＷのＴＥＩＤおよびアドレスを含む。また、ＥＰＳ Ｂｅａｒｅｒ Ｉｄｅｎｔｉｔｙ、ＮＡＳ ＳＱＮ、およびＮＡＳ−ＭＡＣを含む。ＮＡＳ ＳＱＮは、ＮＡＳメッセージのｓｅｑｕｅｎｔｉａｌ ｎｕｍｂｅｒを示し、ＮＡＳ−ＭＡＣは、保全性のためのＮＡＳのＭｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ（ＭＡＣ）である。例えば、ＴＡＵ要求メッセージは、３ＧＰＰ ＴＳ３３．４０１に説明されるように、ＮＡＳ−ＭＡＣによって保全性が保護されるものとする。

図１２のステップ２１では、ＭＭＥ２０２からのセキュリティ鍵（Ｋ_ｅＮＢ）を含む「Ａｔｔａｃｈ Ａｃｃｅｐｔ」メッセージの受信に応じて、ＨｅＮＢ２２０は、図６に従って、Ｅ−ＵＴＲＡＮ ＲＲＣならびにユーザプレーン鍵、すなわち、Ｋ_{ＲＲＣｅｎｃ}、Ｋ_{ＲＲＣｉｎｔ}、Ｋ_{ＵＰｅｎｃ}、およびＫ_{ＵＰｉｎｔ}を導出する。

図１２のステップ２２では、ＨｅＮＢ２２０は、標準的「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕａｒａｔｉｏｎ」メッセージを送信し、標準的「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕａｒａｔｉｏｎ Ｃｏｍｐｌｅｔｅ」メッセージをその代わりに得ることによって、ＵＥ２１４に向けてＲＲＣ接続再構成プロシージャを開始する。３ＧＰＰ ＴＳ２３．４０１の図５．３．２．１−１（ステップ１８、１９）は、これらのメッセージを詳細に説明している。

図１２のステップ２３では、いったんＲＲＣ接続が再構成されると、ＨｅＮＢ２２０は、「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅ」（ＨｅＮＢ ＴＥＩＤ、ＨｅＮＢ ａｄｄｒｅｓｓ）メッセージを送信することによって、ＭＭＥ２０２に返信する。本メッセージは、ダウンリンクトラフィックのために使用されるべきＨｅＮＢ２２０のＴＥＩＤおよびａｄｄｒｅｓｓを伝達する。

図１２のステップ２４では、Ｅ−ＵＴＲＡＮアタッチメントを完了するために、ＵＥ２１４は、ＮＡＳ「Ａｔｔａｃｈ Ｃｏｍｐｌｅｔｅ」メッセージをＭＭＥ２０２に送信する。より具体的には、ＵＥ２１４は、「Ａｔｔａｃｈ Ｃｏｍｐｌｅｔｅ」（ＥＰＳ Ｂｅａｒｅｒ Ｉｄｅｎｔｉｔｙ、ＮＡＳ ＳＱＮ、ＮＡＳ−ＭＡＣ）メッセージをＨｅＮＢ２２０に送信する。次いで、ＨｅＮＢ２２０は、ＮＡＳ「Ａｔｔａｃｈ Ｃｏｍｐｌｅｔｅ」メッセージを「Ｕｐｌｉｎｋ ＮＡＳ Ｔｒａｎｓｐｏｒｔ」メッセージ内でＭＭＥ２０２に転送する。ＵＥ２１４とＨｅＮＢ２２０との間のＬＴＥ伝送が、ここで開始することができる。

図１２のステップ２５では、最後に、ダウンリンクのためのユーザプレーントンネルを確立するために、ＭＭＥ２０２は、ＨｅＮＢ ＴＥＩＤを「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ」（ＨｅＮＢ ＴＥＩＤ）メッセージ内でＳ−ＧＷ２０６に伝達する。Ｓ−ＧＷ２０６は、「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｓｐｏｎｓｅ」メッセージによって返信することによって確認する。ここで、ＧＴＰトンネルが、ＨｅＮＢ２２０とＳ−ＧＷ／Ｐ−ＧＷとの間に確立される。
ＴＷＡＮベースの統一認証／アタッチメントプロシージャ

本項では、我々は、ＵＥ２１４がそのＴＷＡＮ２１８側を介してＩＳＷＮ２３０への接続を試みると仮定する。図１２に提示される、統一認証概念と同様に、ＵＥ２１４は、ＴＷＡＮ２１８およびＨｅＮＢ２２０の両方と統一認証を行うことを目的とする。より正確には、最初に、ＵＥ２１４は、ＴＷＡＮ２１８とＥＡＰ認証を確立するであろう。しかしながら、３ＧＰＰサーバ向けの標準的ＴＷＡＮの伝送とは対照的に、ＴＷＡＮ２１８は、新しいＳＴｂ参照点を経由して、ＭＭＥ２０２と通信し、認証要求を伝達するであろう。ダイアメータプロトコルが、２つのダイアメータベースのメッセージ、すなわち、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」および「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」メッセージを使用して、ＳＴｂ参照点を経由して利用されるであろう。

ＨＳＳ２１０、ＭＭＥ２０２、ＴＷＡＮ２１８、およびＵＥ２１４を伴う、標準的ＡＫＡアルゴリズムが、適用されるであろう。ＵＥ２１４およびＭＭＥ２０２は両方とも、ＴＷＡＮ伝送において使用されるために必要とされる鍵を生成するであろう。我々は、３ＧＰＰ ＡＡＡサーバ２１２がもはや必要とされないことに着目する。図１３は、ＴＷＡＮベースの統一認証およびアタッチメントプロシージャのコールフローを描写する。

図１３におけるコールフローは、以下のように説明されることができる。

図１３のステップ１では、接続が、ＩＥＥＥ８０２．１１規格に従って、ＵＥ２１４とＴＷＡＮ２１８との間で開始される。

図１３のステップ２では、認証のための最初のステップとして、ＴＷＡＮ２１８（具体的には、ＴＷＡＰ）が、ＩＥＴＦ ＲＦＣ５４４８に定義されたＥＡＰ−ＡＫＡ’プロトコルに従って「ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙ」メッセージをＵＥ２１４に送信する。

図１３のステップ３では、識別要求に応答して、ＵＥ２１４は、「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ」（ＮＡＩ、Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）メッセージをＴＷＡＮに送信し、そのＮｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ（ＮＡＩ）を示す（ＩＥＴＦ ＲＦＣ４２８２、３ＧＰＰ ＴＳ２３．００３）。ＮＡＩは、ＵＥ２１４が前に認証されている場合、スードニムが配分される。そうでなければ、ＮＡＩは、最初の認証の場合、ＩＭＳＥである。

ＥＡＰ「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ」メッセージは、「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素を追加することによって拡張されることができる。「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素は、ＩＳＷＮ２２０のＴＷＡＮ２１８およびＨｅＮＢ２２０側の両方を含む、ＩＳＷＮベースの統一認証を行う必要があることのＵＥ２１４からのインジケータである。我々は、ＥＡＰメッセージが、上記で行われたように、例えば、「ｈａｎｄｏｖｅｒ ｉｎｄｉｃａｔｏｒ」を含むように拡張されることができると指摘する（３ＧＰＰ ＴＳ２３．４０２における第１６．１．４Ａ．２節）。

図１３のステップ４では、本ＴＷＡＮ２１８は、ＩＳＷＮ２３０の一部であるため、ＴＷＡＮ２１８は、それ自体およびそのＩＳＷＮ２３０の識別情報も同様にＭＭＥ２０２に搬送することができる。より具体的には、ＴＷＡＮ２１８は、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ＝ＮＡＩ、Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ）メッセージをＭＭＥ２０２に送信する。ＩＳＷＮ Ａｃｃｅｓｓ Ｔｙｐｅを含むことによって、ＭＭＥ２０２は、ＴＷＡＮ２１８にアタッチされているマルチＲＡＴ ＵＥ２１４がＩＳＷＮ２３０のＴＷＡＮ２１８およびＨｅＮＢ２２０の両方に認証されるように試みていることを認識する。

新しいメッセージ、すなわち、ＩＥＴＦ ＲＦＣ４０７２においてＳＴａ（ＡＡＡサーバとＴＷＡＰとの間）上に定義されたものに類似する、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」メッセージが、ＳＴｂ参照点上に追加される。さらに、「Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」が、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」メッセージに追加されることができる。

図１３のステップ５−１１は、図１２のステップ４−１０に類似する。これらのステップは、認証ベクトルの要求に関するＭＭＥ２０２とＨＳＳ２１０との間の通信を含む。加えて、これらのステップはまた、ＨＳＳ２１０およびＭＭＥ２０２におけるＥ−ＵＴＲＡＮならびにＴＷＡＮ２１８の鍵生成を含む。

図１３のステップ１２では、認証ベクトルがＭＭＥ２０２において利用可能であるため、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」（ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ）メッセージをＴＷＡＮ２１８に送信する。「ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ」ペイロードは、ＵＥ２１４における認証および鍵生成のために必要とされる（ＲＡＮＤ、ＡＵＴＮ、ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ、Ａｃｃｅｓｓ ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ）を含む。再認証ＩＤは、任意の今後の高速再認証要求におけるＵＥの識別において使用されるであろう。

ＩＥＴＦ ＲＦＣ４０７２におけるＳＴａ（ＡＡＡサーバ２１２とＴＷＡＰ２２４との間）上に定義されたものに類似する、新しいメッセージ、すなわち、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」メッセージが、ＳＴｂ参照点上に追加される。新しいＡＶＰは「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」メッセージに追加されない。

図１３のステップ１３では、ＴＷＡＮ２１８（特に、ＴＷＡＰ２２４）は、ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ（ＲＡＮＤ、ＡＵＴＮ、ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ）をＵＥ２１４に転送する。

図１３のステップ１４−１６では、図１２におけるステップ１３−１５と同様に、ＵＥ２１４は、ＡＫＡアルゴリズムを起動し、ＡＵＴＮならびにステップ１４−１６におけるＷＬＡＮおよびＥ−ＵＴＲＡＮのために必要とされる鍵も生成する。ＵＥ２１４は、受信されたＡＵＴＮをその独自の生成されたものと比較することによって、ネットワークを認証する。最後に、ＵＥ２１４は、ＭＭＥ２０２に送信されるべきＲＥＳを生成する。

図１３のステップ１７では、ネットワークは、ＵＥ２１４によって認証されるため、ＵＥ２１４は、「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ」（ＲＥＳ）メッセージをＴＷＡＮ２１８（具体的には、ＴＷＡＰ２２４）に送信することによって応答する。

図１３のステップ１８では、ＴＷＡＮは、新しいＳＴｂ参照点を経由して、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」内に含有されるＥＡＰ「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＡＫＡ’−Ｃｈａｌｌｅｎｇｅ」（ＲＥＳ）メッセージをＭＭＥ２０２に転送する。

図１３のステップ１９では、ＭＭＥ２０２は、図１２のステップ１８と類似方式でＵＥ２１４を認証する。

図１３のステップ２０では、いったんＵＥ２１４が認証されると、ＭＭＥ２０２は、ＥＰＳペイロード（ＥＡＰ−Ｓｕｃｃｅｓｓ）を搬送する「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」（ＥＡＰ−Ｓｕｃｃｅｓｓ、ＥＡＰ−Ｍａｓｔｅｒ−Ｓｅｓｓｉｏｎ−Ｋｅｙ）メッセージをＴＷＡＮに送信し、ＥＡＰ認証の成功を示す。さらに、本メッセージは、そのさらなる通信においてＵＥ２１４とＴＷＡＮ２１８との間で使用されるべき「ＥＡＰ−Ｍａｓｔｅｒ−Ｓｅｓｓｉｏｎ−Ｋｅｙ」（ＭＳＫ）ＡＶＰをＴＷＡＮ２１８に伝達する。

図１３のステップ２１では、認証プロシージャを完了するために、ＴＷＡＮ２１８は、「ＥＡＰ−Ｓｕｃｃｅｓｓ」メッセージをＵＥ２１４に転送する。

図１３のステップ２２では、セッションを作成するために、ＴＷＡＮ２１８は、Ｓ１−ＭＭＥ参照点を経由して、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ」（ＴＷＡＮ ＴＥＩＤ）メッセージをＭＭＥ２０２に送信し、これは、Ｓ−ＧＷ２０６およびＰ−ＧＷ２０８に転送される。

図１３のステップ２３では、それに応答して、Ｐ−ＧＷ／Ｓ−ＧＷは、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ」（Ｓ−ＧＷ ＴＥＩＤ）メッセージをＭＭＥ２０２に送信し、これは、ＴＷＡＮ２１８に転送される（Ｓ１−ＭＭＥ参照点を経由して）。ＧＴＰトンネルが、ここで、ＴＷＡＮ２１８、Ｓ−ＧＷ２０６、およびＰ−ＧＷ２０８間に確立される。

図１３のステップ２４では、ＵＥ２１４は、標準的層３アタッチ要求（例えば、ＤＨＣＰｖ４要求）を送信してもよい。それに応答して、ＤＨＣＰｖ４メッセージが、配分されたＩＰｖ４アドレスとともに、ＵＥに送信される。ＩＥＥＥ８０２．１１規格を使用するＷＬＡＮ通信が、ここで、ＵＥ２１４とＴＷＡＮ２１８との間に確立される。
ＲＡＴ間ハンドオーバプロシージャにおける高速再認証
ＩＳＷＮ内ＨｅＮＢ／ＴＷＡＮハンドオーバプロシージャにおける高速再認証

本項では、我々は、ＵＥ２１４が、最初に、ＨｅＮＢ２２０にアタッチすることによって、統一認証を行っているシナリオを検討する。次いで、ＵＥ２１４は、ＷＬＡＮ２１８に切り替えることを決定する。ＵＥ２１４は、ＨＳＳ２１０とすでに認証されているため、完全認証プロシージャを再び起動する必要はない。代わりに、ＵＥ２１４およびＭＭＥ２０２は、高速再認証のみを起動する必要があり、ＷＬＡＮアクセスネットワークのための新しい鍵（例えば、ＭＳＫ）のみが、生成される。図１４は、同一ＩＳＷＮ２３０内のＨｅＮＢ／ＷＬＡＮハンドオーバシナリオにおける高速再認証プロシージャのためのコールフローを描写する。示されるであろうように、新しい認証ベクトルを生成する必要はない。

ＴＷＡＮ２１８ではなく、ＭＭＥ２０２が、新しいＷＬＡＮ鍵（例えば、ＭＳＫ）を生成するための責任ネットワークエンティティとなるであろう。これは、３ＧＰＰガイドラインに合致し、典型的には、ＡＡＡサーバ（ＴＷＡＮ２１８ではなく）が高速再認証（３ＧＰＰ ＴＳ３３．４０２の第６．３節）を行う、またはＭＭＥ２０２（ＨｅＮＢ２２０ではなく）がＬＴＥ内Ｅ−ＵＴＲＡＮハンドオーバ鍵を生成することを可能にする（第２１２項）。

図１４におけるコールフローは、以下のように説明されることができる。

図１４のステップ０では、ＬＴＥ接続がすでに、ＵＥ２１４、ＨｅＮＢ２２０、およびＳ−ＧＷ／Ｐ−ＧＷ間に存在する。ＨｅＮＢ２２０は、ＩＳＷＮの一部と仮定される。さらに、ＨｅＮＢ２２０およびＷＬＡＮ２１８の両方を含む、ＩＳＷＮ２３０との統一認証プロシージャが、前述の新しいプロシージャに従って、最初に行われている。

図１４のステップ１では、ＵＥ２１４は、同一ＩＳＷＮ内においてＲＡＴ間ハンドオーバをＴＷＡＮ２１８に行うことを決定する。故に、ＵＥ２１４は、ＴＷＡＮ２１８との接続を開始する。

図１４のステップ２では、ＴＷＡＮ２１８側からの最初のステップとして、「ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙ」メッセージをＵＥ２１４に送信し、ＵＥの識別を問い合わせる。

図１４のステップ３では、それに応答して、ＵＥ２１４は、「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ」（ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ、ｈａｎｄｏｖｅｒ）メッセージをＴＷＡＮ２１８に送信することによって返信する。本メッセージでは、ＵＥ２１４は、先行初期統一認証プロシージャ（図１２におけるステップ１２）においてそこに送信された再認証ＩＤを使用して、その識別を示す。さらに、ＴＷＡＮ２１８に向けてハンドオーバを行っていることを示す。我々は、ＥＡＰ−ＡＫＡ’が「ｈａｎｄｏｖｅｒ ｉｎｄｉｃａｔｏｒ」および「ｒｅｑｕｅｓｔｅｄ ＡＰＮ」情報要素を搬送するように以前に拡張されていることに着目する（３ＧＰＰ ＴＳ２３．４０２における第１６．１．４Ａ．２節）。したがって、我々は、「ｈａｎｄｏｖｅｒ ｉｎｄｉｃａｔｏｒ」を含むことによって、本ＥＡＰ拡張を本ステップにおいて利用する。

図１４のステップ４では、ＴＷＡＮ２１８は、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ：ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ、Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ、Ｈａｎｄｏｖｅｒ）を送信することによって、受信されたメッセージをＭＭＥにさらに搬送する（新しいＳＴｂ参照点を経由して）。本メッセージは、ＭＭＥ２０２に、既存のＵＥ２１４（その再認証ＩＤによって認識される）がそのＩＳＷＮ２３０のＷＬＡＮ２１８側にハンドオーバを行うことを目的としていることを示す。

図１４のステップ５では、ＭＭＥ２０２は、「ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ」情報要素を受信し、高速再認証プロシージャを使用することを決定する。したがって、図１３におけるステップ５−１０をスキップするであろう。次いで、ＭＭＥ２０２は、新しいＳＴｂ参照点を経由して、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」（ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ：ＣＯＵＮＴＥＲ、ＮＯＮＣＥ、ＭＡＣ、ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ）メッセージをＴＷＡＮ２１８に送信する。本メッセージでは、ＭＭＥ２０２は、新たなＣＯＵＮＴＥＲ値（完全認証プロシージャにおけるものに初期化された）、ＮＯＮＣＥ、ＭＡＣ、および新しい再認証ＩＤを含む。ＭＡＣが、ＮＯＮＣＥを通じて計算され、新しい再認証ＩＤが、次の高速再認証において使用されるであろう。これらの属性は、標準的「ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ」ＥＡＰメッセージに従う。

図１４のステップ６では、いったんＴＷＡＮ２１８が上記のメッセージを受信すると、そのペイロード（ＣＯＵＮＴＥＲ、ＮＯＮＣＥ、ＭＡＣ、ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ）を含む、「ＥＡＰ−Ｒｅｑｕｅｓｔ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ」メッセージをＵＥ２１４に転送する。

図１４のステップ７では、メッセージの受信に応じて、ＵＥ２１４は、カウンタが新たな値を有し、ＭＡＣが正しく計算されていることを検証する。次いで、ＵＥ２１４は、「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ」（ＣＯＵＮＴＥＲ、ＭＡＣ）メッセージをＴＷＡＮ２１８に送信することによって応答する。ＣＯＵＮＴＥＲは、ＭＭＥ２０２から受信されたものと同一であって、ＭＡＣが、ＥＡＰパケットおよびＮＯＮＣＥ（ＭＭＥ２０２から受信されたように）を通じて計算される。これらの属性は、ＩＥＴＦＲＦＣ４１８７の第９．８節に定義された標準的「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ」ＥＡＰメッセージに従う。

図１４のステップ８では、ＴＷＡＮ２１８は、ＵＥ２１４から受信されたＥＡＰペイロードを「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」（ＥＡＰ−Ｒｅｓｐｏｎｓｅ／ＡＫＡ’−Ｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎ）メッセージの中に埋め込み、新しいＳＴｂ参照点を経由して、それをＭＭＥ２０２に送信する。

図１４のステップ９では、再認証応答が受信されて、ＭＭＥ２０２は、ＷＬＡＮマスタセッション鍵（ＭＳＫ）を再生成する。新しいＭＳＫは、再認証鍵（Ｋ＿ｒｅ）、再認証ＩＤ、ＣＯＵＮＴＥＲ、およびＮＯＮＣＥに基づいて生成される。

図１４のステップ１０では、ＭＭＥ２０２は、新しいＳＴｂ参照点を経由して、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」（ＥＡＰ−Ｓｕｃｃｅｓｓ、ＭＳＫ）メッセージをＴＷＡＮ２１８に送信する。故に、ＴＷＡＮ２１８は、ＵＥ２１４とのその伝送において使用されるべきＭＳＫを記憶するであろう。

図１４のステップ１１では、高速再認証プロシージャを完了するために、ＴＷＡＮ２１８は、「ＥＡＰ−Ｓｕｃｃｅｓｓ」メッセージをＵＥ２１４に転送する。

図１４のステップ１２では、さらに、ＴＷＡＮ２１８は、Ｓ１−ＭＭＥ参照点を経由して、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ」（ＴＷＡＮ ＴＥＩＤ）をＭＭＥ２０２に送信し、これは、Ｓ−ＧＷ２０６およびＰ−ＧＷ２０８に転送される。

図１４のステップ１３では、応答として、「Ｈａｎｄｏｖｅｒ」インジケーションを前提として、Ｐ−ＧＷ２０８は、同一ＩＰアドレスをＵＥ２１４に再配分する。次いで、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ」をＳ−ＧＷ２０６に送信し、これは、ＭＭＥ２０２に、最後に、ＴＷＡＮ２１８に転送される（Ｓ１−ＭＭＥ参照点を経由して、）。その結果、ＧＴＰトンネルが、ＴＷＡＮ２１８、Ｓ−ＧＷ２０６、およびＰ−ＧＷ２０８間に確立される。

図１４のステップ１４では、いったんＵＥ２１４が「ＥＡＰ−Ｓｕｃｃｅｓｓ：メッセージをＴＷＡＮから受信すると、図１４のステップ９と同様に、新しいＷＬＡＮ ＭＳＫを生成する。さらに、ＵＥ２１４は、標準的層３アタッチ要求（例えば、ＤＨＣＰｖ４要求）を送信してもよい。それに応答して、ＤＨＣＰｖ４メッセージが、配分されたＩＰｖ４アドレスとともに、ＵＥに送信される。その結果、ハンドオーバは、ここで完了し、ＵＥ２１４は、ＴＷＡＮ２１８とのＷＬＡＮ接続を有する。

図１４のステップ１５では、最後に、３ＧＰＰ ＥＰＳベアラ解放プロシージャが、ＰＧＷ２０８によって開始される。より具体的には、３ＧＰＰ ＴＳ２３．４０２の第５．６．２．２節に説明されるＰ−ＧＷ２０８開始ＰＤＮ切断プロシージャが、行われる。

代替機構が、以下に説明され、これは、ＥＡＰ−再認証プロトコル（ＥＡＰ−ＲＰ）（ＲＦＣ６６９６）に基づく最適化された再認証機構を説明する。ＥＡＰ−ＲＰプロトコルは、完全ＥＡＰ認証もしくはＡＫＡ認証プロトコル、さらに言うなら、任意の完全認証プロトコル後に実施されてもよい。ＥＡＰ−ＲＰは、単一ラウンドトリップを使用して、再認証を達成する。類似機構が、再認証を行うために使用されてもよく、例えば、ワンラウンドトリップ認証（ＯＲＴＡ）が、採用されてもよい。ＥＡＰ−ＦＡＳＴ機構もまた、採用されてもよい。

ＯＲＴＡ等の機構は、認証／ＩＰアドレス割当に関わる待ち時間をさらに短縮するために採用されてもよい。ＯＲＴＡは、完全認証プロシージャが回避され、ＵＥが、随意に、ＥＡＰ認証がシリアル様式で実施された後、ＤＨＣＰメッセージを明示的に開始する必要なく、ＯＲＴＡメッセージを使用して、ＩＰアドレス割当を要求可能となり得るように、ＯＲＴＡ ＩＤを利用する。ＯＲＴＡを使用して、ＤＨＣＰプロセスは、パラレル様式でＯＲＴＡメッセージングを使用して、暗示的または明示的のいずれかで実施される。

図１５におけるコールフローは、以下のように説明されることができる。

図１５のステップ０では、我々は、ＬＴＥ接続がすでに、ＵＥ２１４、ＨｅＮＢ２１５、およびＳ−ＧＷ／Ｐ−ＧＷ１００２間に存在すると仮定する。ＨｅＮＢ２２０は、ＩＳＷＮ２３０の一部であると仮定される。さらに、ＨｅＮＢ２２０およびＷＬＡＮ２１８の両方を含む、ＩＳＷＮ２３０との統一認証プロシージャが、最初に、図１２に関して議論される新しいプロシージャに従って行われている。認証プロセスの結果、再認証のためのコンテキストが、ＥＡＰ−ＲＰプロトコルに基づいて作成される。ＥＡＰ認証の一部として生成された拡張マスタセッション鍵（ＥＭＳＫ）が、ＥＭＳＫＮａｍｅ／ｋｅｙＮａｍｅＮＡＩによって識別される再認証コンテキスト情報と関連付けられ得る、再認証ルート鍵（ｒＲＫ）を生成するために使用されてもよい。再認証保全性鍵（ｒＩＫ）および他の関連付けられた鍵等のｒＲＫに基づく派生鍵は、ＵＥおよびＭＭＥ２０２の両方において生成されてもよい。ドメイン特有の（例えば、ＤＳ−ｒＲＫ）および関連付けられた鍵（例えば、ＤＳ−ｒＩＫ。ＤＳ−ｒＣＫ）もまた、生成されてもよい。

図１５のステップ１では、我々は、ＵＥ２１４が同一ＩＳＷＮ２３０内でＴＷＡＮ２１８へのＲＡＴ間ハンドオーバを行うことを決定すると仮定する。故に、ＵＥ２１４は、ＴＷＡＮ２１８との接続を開始する。

図１５のステップ２では、ＴＷＡＮ側からの最初のステップとして、「ＥＡＰ−Ｒｅｑｕｅｓｔ／Ｉｄｅｎｔｉｔｙ」メッセージをＵＥ２１４に送信し、ＵＥの識別を問い合わせる。これは、随意である、または特定のＥＡＰ再認証要求識別メッセージと置換されてもよい。

図１５のステップ３では、ＵＥは、「ＥＡＰ−Ｉｎｉｔｉａｔｅ／Ｒｅ−ａｕｔｈ／ｂｏｏｔｓｔｒａｐ」（ｋｅｙＮａｍｅＮＡＩ、ＳＥＱ、ＭＡＣ）メッセージをＴＷＡＮ２１８に送信する。本メッセージでは、ＵＥ２１４は、先行初期統一認証プロシージャ（図１２におけるステップ１２）の一部として生成された再認証コンテキストｋｅｙＮａｍｅＮＡＩを示す。さらに、ハンドオーバをＴＷＡＮ２１８に向けて行っていることを示す。「ｈａｎｄｏｖｅｒ」インジケーションは、明示的または暗示的であってもよい。特定のＴＷＡＮ２１８と関連付けられた新たなかつ有効な鍵が、存在しない場合、ＵＥ２１４は、ハンドオーバが生じていない場合でも、本プロセスを開始してもよい。メッセージ認証コードまたは認証タグが、ＥＡＰ−ＲＰプロトコルに説明される機構を使用して作成される。ＳＥＱ値ならびにｒＩＫは、ＭＡＣ／認証タグを作成するために、メッセージとともに使用される。

図１５のステップ４では、ＴＷＡＮ２１８は、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」（ＥＡＰ−Ｉｎｉｔｉａｔｅ／Ｒｅ−ａｕｔｈ／ｂｏｏｔｓｔｒａｐ：ｋｅｙＮａｍｅＮＡＩ、Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ、Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ、ＳＥＱ、ＭＡＣ）を送信することによって、受信されたメッセージをＭＭＥ２０２にさらに搬送する（新しいＳＴｂ参照点を経由して）。本メッセージは、ＭＭＥ２０２に、既存のＵＥ（そのｋｅｙＮａｍｅＮＡＩによって認識される）がそのＩＳＷＮ２３０のＷＬＡＮ側へのハンドオーバを行うことを目的としていることを示す。

図１５のステップ５では、ＭＭＥ２０２によって受信されたｋｅｙＮａｍｅＮＡＩに基づいて、ＭＭＥ２０２は、再認証コンテキスト情報をチェックし、ＥＭＳＫＮａｍｅと関連付けられたｒＩＫを得る。ＭＭＥ２０２は、ＥＡＰ−ＲＰプロトコルによって説明される機構を使用して、ＭＡＣ／認証タグを検証する。ＭＭＥ２０２は、ＳＥＱおよびｒＲＫを使用して、ｒＭＳＫを生成する。

図１５のステップ６では、ＭＭＥ２０２は、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」（ＥＡＰ−Ｓｕｃｃｅｓｓ（ｒＭＳＫ、ＭＡＣ））を作成し、それをＴＷＡＮ２１８に送信する。

図１５のステップ７では、いったんＴＷＡＮ２１８がメッセージを受信すると、ｒＭＳＫを記憶し、次いで、ＭＡＣ／認証タグを含有するそのペイロードを含む、「ＥＡＰ−Ｓｕｃｃｅｓｓ」（ＭＡＣ）メッセージをＵＥ２１４に転送する。

図１５のステップ８では、メッセージの受信に応じて、ＵＥ２１４は、ＳＥＱが順序正しく、ＭＡＣが正しく計算されていることを検証する。ＵＥ２１４は、次いで、ＭＭＥ２０２と類似機構を使用して、ｒＭＳＫを導出する。他の関連ＴＷＡＮ特有の鍵も、８０２．１１メッセージを保護するために導出される。

図１５のステップ９では、さらに、ＴＷＡＮ２１８は、Ｓ１−ＭＭＥ参照点を経由して、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ」（ＴＷＡＮ ＴＥＩＤ）をＭＭＥ２０２に送信し、これは、Ｓ−ＧＷ２０６およびＰ−ＧＷ２０８に転送される。

図１５のステップ１０では、応答として、「Ｈａｎｄｏｖｅｒ」インジケーションを前提として、Ｐ−ＧＷ２０８は、同一ＩＰアドレスをＵＥ２１４に再配分する。次いで、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ」をＳ−ＧＷ２０６に送信し、これは、ＭＭＥ２０２に、最後に、ＴＷＡＮ２１８に転送される（Ｓ１−ＭＭＥ参照点を経由して）。その結果、ＧＴＰトンネルが、ＴＷＡＮ２１８、Ｓ−ＧＷ２０６、およびＰ−ＧＷ２０８間に確立される。

図１５のステップ１１−１２は、上記のメッセージフローから導かれる。
ＩＳＷＮ内ＴＷＡＮ／ＨｅＮＢハンドオーバプロシージャにおける高速再認証

本項では、我々は、ＩＳＷＮ２３０内におけるＴＷＡＮ２１８からＨｅＮＢ２２０へのハンドオーバシナリオを検討する。最初に、我々は、統一認証プロシージャがＵＥ２１４をＩＳＷＮ２３０のＴＷＡＮ２１８と認証するために行われていると仮定する。次いで、ＵＥ２１４が、ＩＳＷＮのＨｅＮＢ２２０側に向けてハンドオーバを行うことを決定する。この場合、完全認証プロシージャを起動する必要はない。代わりに、鍵再生成のみに集中する、ＵＥ２１４とＭＭＥ２０２との間の高速再認証プロシージャが、行われることができる。ＨＳＳ２１０は、高速再認証プロシージャに関わらないであろう。図１６は、ＩＳＷＮ内ＴＷＡＮ／ＨｅＮＢハンドオーバシナリオにおける高速再認証およびハンドオーバプロシージャのためのコールフローを描写する。

図１６におけるコールフローは、以下のように説明されることができる。

図１６のステップ０では、我々は、ＵＥ２１４がＴＷＡＮ２１８およびＳ−ＧＷ／Ｐ−ＧＷ１００２との既存の接続を有すると仮定する。ＴＷＡＮ２１８は、ＩＳＷＮ２３０の一部である。本接続は、最初に、ＴＷＡＮベースの統一認証／認可プロシージャを使用して認証されている。

図１６のステップ１では、我々は、ＵＥ２１４が、以前に認証されたＩＳＷＮ２３０の一部である、ＨｅＮＢ２２０へのハンドオーバを行うことを決定すると仮定する。最初に、ＵＥ２１４は、「ｈａｎｄｏｖｅｒ」インジケーションを含む、ＮＡＳ「Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ」（Ｈａｎｄｏｖｅｒ）メッセージをＨｅＮＢ２２０に送信する。

図１６のステップ２では、それに応答して、ＨｅＮＢ２２０は、「Ａｔｔａｃｈ Ｒｅｑｕｅｓｔ」（Ｈａｎｄｏｖｅｒ）メッセージをＭＭＥ２０２に転送する。

図１６のステップ３では、いったんＭＭＥ２０２がＩＳＷＮ内ＲＡＴ間ハンドオーバインジケーションを受信すると、再認証プロシージャを高速で起動することができる。言い換えると、図１２のステップ４−１８をスキップする。次いで、標準的セッション作成プロシージャが、図１２におけるステップ１９と同様に、ＭＭＥ２０２、Ｓ−ＧＷ２０６、およびＰ−ＧＷ２０８間で実施される。「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｑｕｅｓｔ」メッセージは、ＩＭＳＩ、Ｈａｎｄｏｖｅｒ Ｉｎｄｉｃａｔｉｏｎ、およびＡＰＮを含むであろう。応答として、「Ｈａｎｄｏｖｅｒ」インジケーションを前提として、Ｐ−ＧＷ２０８は、同一ＩＰアドレスをＵＥ２１４に再配分する。次いで、Ｐ−ＧＷ／Ｓ−ＧＷ１００２は、「Ｃｒｅａｔｅ Ｓｅｓｓｉｏｎ Ｒｅｓｐｏｎｓｅ」（ＩＰ ａｄｄｒｅｓｓ、Ｓ−ＧＷ ＴＥＤＩ、Ｐ−ＧＷ ＴＥＩＤ）メッセージをＭＭＥ２０２に返信するであろう。

図１６のステップ４では、いったんハンドオーバセッションが作成されると、ＭＭＥ２０２は、ローカルに維持されるＮＣＣ値を１だけ増加させ、その記憶されたＫ_ＡＳＭＥおよびローカルに維持されるＮＨ値を使用して、新たなＮＨ値を算出する（３ＧＰＰ ＴＳ３３．４０１の付属Ａ．４）。ＮＡＳセキュリティ鍵に関して、我々は、ＭＭＥ２０２が、初期統一認証プロシージャ（図１３のステップ１０）において導出されたＫ_{ＮＡＳｅｎｃ}およびＫ_{ＮＡＳｉｎｔ}のすでに記憶されたバージョンを有することに着目する。

図１６のステップ５では、ＭＭＥ２０２は、「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔ／Ａｔｔａｃｈ Ａｃｃｅｐｔ」（ＮＨ、ＮＣＣ）メッセージをＨｅＮＢ２２０に送信することによって、アタッチ要求を承認する。

図１６のステップ６では、ＨｅＮＢ２２０は、標的ＨｅＮＢ物理セルＩＤ（ＰＣＩ）およびその周波数ＥＡＲＦＣＮ−ＤＬ（標的物理セルダウンリンク周波数）に加え、受信された（ＮＨ、ＮＣＣ）を使用して、新しいセキュリティ鍵（Ｋ_ｅＮＢ）を生成する。１つの生成機能が、３ＧＰＰ ＴＳ３３．４０１の付属Ａ．５に説明されている。

図１６のステップ７では、いったん新しいＫｅＮＢが生成されると、ＨｅＮＢは、Ｋ_ｅＮＢに基づいて、全ての付加的な必要とされるＥ−ＵＴＲＡＮ鍵、すなわち、（Ｋ_{ＲＲＣｅｎｃ}、Ｋ_{ＲＲＣｉｎｔ}、Ｋ_{ＵＰｅｎｃ}、Ｋ_{ＵＰｉｎｔ}）を導出するであろう。

図１６のステップ８では、いったん鍵生成プロセスがＨｅＮＢ２２０において完了されると、新しいＮＣＣ値を搬送する「Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄ」（ＮＣＣ）メッセージをＵＥ２１４に送信する。「Ｈａｎｄｏｖｅｒ Ｃｏｍｍａｎｄ」メッセージ内への「ＮＣＣ」情報要素の含有は、３ＧＰＰ ＴＳ３３．４０１の第７．２．８．４．３節に述べられている。

図１６のステップ９では、いったんＵＥ２１４がＮＣＣ値を受信すると、第１に、その記憶されたＫ_ＡＳＭＥおよびローカルに維持されるＮＨを使用して、ＭＭＥ２０２が図１６のステップ４において行ったものと類似方式で新たなＮＨを生成する。第２に、ＵＥ２１４は、（ＮＨ、ＮＣＣ、ｔａｒｇｅｔ ＰＣＩ、ｆｒｅｑｕｅｎｃｙ ＥＡＲＦＣＮ−ＤＬ）を使用して、ＨｅＮＢ２２０が図１６のステップ６において行ったものと類似方式でＫ_ｅＮＢを生成する。ＮＡＳセキュリティ鍵に関して、我々は、ＵＥ２１４が初期統一認証プロシージャ（図１３のステップ１６）において導出されたすでに記憶されたバージョンのＫ_{ＮＡＳｅｎｃ}およびＫ_{ＮＡＳｉｎｔ}を有することに着目する。

図１６のステップ１０では、最後に、ＵＥ２１４は、ＨｅＮＢ２２０が図１６のステップ［０１７５］において行ったものと同様に、Ｋ_ｅＮＢに基づいて、全ての必要とされるＥ−ＵＴＲＡＮ鍵（Ｋ_{ＲＲＣｅｎｃ}、Ｋ_{ＲＲＣｉｎｔ}、Ｋ_{ＵＰｅｎｃ}、Ｋ_{ＵＰｉｎｔ}）を導出する。

図１６のステップ１１−１４では、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｃｏｎｆｉｇｕａｒａｔｉｏｎ」、「Ｉｎｉｔｉａｌ Ｃｏｎｔｅｘｔ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅ」、「Ａｔｔａｃｈ Ｃｏｍｐｌｅｔｅ」、および「Ｍｏｄｉｆｙ Ｂｅａｒｅｒ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ」メッセージが図１２のステップ２２−２５と同様に交換される。最後に、ハンドオーバプロシージャが、完了され、新しいＬＴＥ接続および関連付けられたＧＴＰトンネルが、確立される。

図１６のステップ１５では、ＰＤＮ ＧＷ２０８は、３ＧＰＰ ＴＳ２３．４０２の第６．１２節に定義されるように、リソース配分非アクティブ化プロシージャをＴＷＡＮ２１８において開始する。
ＴＷＡＮ／ｅＮＢハンドオーバプロシージャにおける高速再認証

本項では、我々は、ＵＥ２１４がＩＳＷＮ２３０の一部であるＴＷＡＮ２１８からマクロｅＮＢ１７０２に移行するシナリオを検討する。本シナリオは、加入者が、その自宅またはオフィス（ＩＳＷＮ／ＴＷＡＮ）から出て、道路（マクロｅＮＢ１７０２）に進むときの場合に類似する。図１７は、この場合のコールフローを描写する。示されるように、ＴＷＡＮ／ＨｅＮＢにおける高速再認証例に非常に類似する。コールフローの詳細は、図１６のものに類似し、故に、再びここでステップを繰り返す必要はないであろう。
メッセージ拡張

本項では、我々は、必要とされるメッセージおよびプロトコル拡張を導入し、上記に提示されるプロシージャをイネーブルにする。
ＲＲＣ：「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」メッセージ

図１２のステップ１２では、我々は、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」メッセージを修正し、新しい「ＵｎｉｆｉｅｄＡｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素を含める。「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素が設定される場合、ＵＥ２１４が統一認証プロシージャを行うことを所望することを意味する。表７は、太字で示される新しい「ＵｎｉｆｉｅｄＡｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素に加え、「ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｓｅｔｕｐ Ｃｏｍｐｌｅｔｅ」メッセージの標準的情報要素を描写する。
Ｓ１−ＡＰ：「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」メッセージ

図１２のステップ１２では、我々は、「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」メッセージ内にＩＳＷＮ構成パラメータのうちのいくつかを含める。表８は、新しい情報要素、すなわち、「ＡｃｃｅｓｓＴｙｐｅ＝ＩＳＷＮ」および「ＡｃｃｅｓｓＮｅｔｗｏｒｋＩｄｅｎｔｉｔｙ＝ＷＬＡＮ」に加え、「Ｉｎｉｔｉａｌ ＵＥ Ｍｅｓｓａｇｅ」メッセージの標準的情報要素（３ＧＰＰ ＴＳ３６．４１３の第９．１．７．１節）を示す。
ＮＡＳ：「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージ

図１２のステップ１１および１２では、ＭＭＥ２０２は、ＮＡＳ「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージをＩＳＷＮ２３０に送信する。認証ベクトル（ＲＡＮＤ、ＡＵＴＮ）に加え、ＭＭＥ２０２は、２つの新しい情報要素「Ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」を送信する。再認証ＩＤは、ハンドオーバのために今後の高速再認証プロシージャにおいてＵＥ２１４を識別するために使用されるであろう（例えば、図５−４のステップ３）。アクセスネットワーク識別が、ＣＫ’およびＩＫ’鍵を導出する際に利用するために、ＵＥにフィードされる（図１２のステップ１４）。表９は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ」メッセージの標準的情報要素（３ＧＰＰ ＴＳ ２４．３０１の第８．２．７節）とともに、新しい「Ｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ ＩＤ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ」情報要素を描写する。
ＥＡＰ：「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ」メッセージ

ＩＥＴＦ ＦＲＣ４１８７の第９．２節は、ＵＥによって送信され、その識別（Ｎｅｔｗｏｒｋ Ａｃｃｅｓｓ Ｉｄｅｎｔｉｆｉｅｒ）を示す、「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ」を説明する。図１３のステップ３では、我々は、新しい情報要素、すなわち、「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」を「ＥＡＰ−Ｒｅｓｐｏｎｓｅ／Ｉｄｅｎｔｉｔｙ」メッセージに追加する。「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素は、バイナリ値（０または１）をとる。「Ｕｎｉｆｉｅｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ」情報要素が設定される場合、ＵＥが統一認証プロシージャを行うことを所望していることを意味する。
Ｓ６ａ参照点を経由したダイアメータベースのメッセージ
「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」メッセージ

複数のインスタンス（例えば、図１２のステップ４）において、ＭＭＥ２０２は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」メッセージをＨＳＳ２１０に送信し、認証ベクトルを要求する。「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」情報要素が、ＨＳＳ２１０がＷＬＡＮのためにも鍵（ＣＫ’およびＩＫ’）を生成することができるように、本メッセージ内に追加される。表１０は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ｒｅｑｕｅｓｔ」メッセージの標準的情報要素（３ＧＰＰ ＴＳ２９．２７２の表５．２．３．１．１／１）ならびに新しい「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ」情報要素を示す。
「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」メッセージ

複数のインスタンス（例えば、図１２のステップ８）において、ＨＳＳ２１０は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」メッセージをＭＭＥ２０２に送信し、認証ベクトルおよび鍵を伝達する。「ＣＫ’」、「ＩＫ’」、および「再認証ＩＤ」情報要素が、本メッセージ内に追加される。表１１は、「Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｉｎｆｏｒｍａｔｉｏｎ−Ａｎｓｗｅｒ」メッセージの標準的情報要素（３ＧＰＰ ＴＳ２９．２７２の表５．２．３．１．１／２）ならびに新しい情報要素を示す。
新しいＳＴｂ参照点を経由したダイアメータベースのメッセージ
「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」メッセージ

図１３および図１４のステップ４では、メッセージ「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」が、ＴＷＡＮ２１８（特に、ＴＷＡＰ２２４）とＭＭＥ２０２との間の新しいＳＴｂ参照点を経由して使用される。さらに、「Ａｃｃｅｓｓ Ｔｙｐｅ＝ＩＳＷＮ」および「Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ｉｄｅｎｔｉｔｙ＝ＷＬＡＮ」ＡＶＰが、追加され、ＴＷＡＮ２１８からＭＭＥ２０２に搬送される。標準的ＡＶＰ（ＩＥＴＦ ＲＦＣ４０７２の第３．１節）とともに、新しいもの（太字）が、以下に示される。
「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」メッセージ

複数のインスタンス（例えば、図１３のステップ１２）では、ＭＭＥ２０２は、新しいＳＴｂ参照点を経由して、「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」メッセージをＴＷＡＮ２１８に送信する。ＩＥＴＦ ＲＦＣ４０７２の第３．２節からの以下にコピーされる標準的なもの以外、任意の付加的ＡＶＰは必要とされない。

図１２−１７に図示されるステップを行うエンティティは、無線および／またはネットワーク通信のために構成される装置または図２１Ｃもしくは図２１Ｄに図示されるもの等、コンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る、論理エンティティであり得ることを理解されたい。すなわち、図１２−１７に図示される方法は、図２１Ｃまたは図２１Ｄに図示される装置もしくはコンピュータシステム等の装置のメモリ内に記憶される、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよく、そのコンピュータ実行可能命令は、装置のプロセッサによって実行されると、図１２−１７に図示されるステップを行う。また、図１２−１７に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。また、図１２−１７に図示される任意の伝送および受信ステップは、装置のプロセッサおよびそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で装置の通信回路によって行われ得ることを理解されたい。また、図１２−１７に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。

図１８は、３ＧＰＰ ＴＳ２３．４０２に提示される３ＧＰＰと非信頼ＷＬＡＮとの間のインタワーキングアーキテクチャを描写する。示されるように、拡張パケットデータゲートウェイ（ｅＰＤＧ）１８０４が、ＵＥ２１４とＰＤＮ−ＧＷ２０８との間の中間エンティティとして導入される。一方で、ｅＰＤＧ１８０４は、ＳＷｕ参照点を経由して、ＩＰＳｅｃトンネルを通してＵＥ２１４と通信する。他方で、ｅＰＤＧ１８０４は、ＧＴＰ−Ｕトンネルプロトコルを使用して、Ｓ２ｂインターフェースを経由してＰＤＮ−ＧＷ２０８と通信する。

非信頼ＷＬＡＮ例におけるＵＥ２１４とＨＳＳ２１０との間の標準的相互認証プロシージャは、３ＧＰＰ ＴＳ３３．４０２に説明されており、以下のプロトコルから成る。
１． ＳＷｕ参照点を経由したＵＥ２１４とｅＰＤＧ１８０４との間のインターネット鍵交換バージョン２（ＩＫＥｖ２）（ＲＦＣ５９９６）プロトコルを通じたＥＡＰ。対照的に、我々は、ＥＡＰプロトコルのみがＵＥ２１４と信頼ＷＬＡＮ２１８（ＴＷＡＰ）２２４との間で使用されることを考え出している。非信頼ＷＬＡＮ１８０２例では、最初に、ＵＥ２１４が、ＥＡＰメッセージをＩＫＥｖ２を経由してｅＰＤＧ１８０４に送信し、標準的ＩＰＳｅｃトンネルが、標準的ＩＫＥｖ２プロトコルを使用して、ｅＰＤＧ１８０４とＵＥ２１４との間に確立される。
２． ＳＷｍ参照点を経由したｅＰＤＧ１８０４と３ＧＰＰ ＡＡＡサーバ２１２との間のダイアメータプロトコル。より正確には、ｅＰＤＧが、ＵＥ２１４によって送信されるＩＫＥｖ２メッセージからＥＡＰメッセージを抽出し、それらを３ＧＰＰ ＡＡＡサーバ２１２に転送する。
３． ＳＷｘを経由した３ＧＰＰ ＡＡＡサーバ２１２とＨＳＳ２１０との間のダイアメータプロトコル。そのようなステップは、前述の信頼ＷＬＡＮ例に発生するものと正に類似する。

非信頼と信頼ＷＬＡＮ例との間の主な認証関連差異は、非信頼例に関するＥＡＰメッセージを搬送するためのＩＫＥｖ２プロトコル（ＵＥ−ｅＰＤＧ）の使用である。等しく重要なこととして、我々は、図９および図１０に詳細に説明されたように、上記のステップ２（非信頼ＷＬＡＮ例に関するｅＰＤＧ−３ＧＰＰ ＡＡＡサーバ２１２）と信頼ＷＬＡＮ例に関するＳＴａを経由した（ＴＷＡＰ−３ＧＰＰ ＡＡＡサーバ２１２）通信との間の役割の類似性に着目する。特に、同一ＥＡＰメッセージが、２つの参照点（ＳＷｍ、ＳＴａ）を経由して伝達される。

したがって、非信頼ＷＬＡＮ例に関するインタワーキングアーキテクチャは、新しい参照点（すなわち、図１８におけるＳＴｍ）をｅＰＤＧ１８０４とＭＭＥ２０２との間に追加することによって向上されることができる。新しい参照点ＳＴｍは、ＳＴｂ参照点（ＴＷＡＰ２２４とＭＭＥ２０２との間でＥＡＰメッセージを搬送する）と同様に、ＥＡＰメッセージをｅＰＤＧ１８０４とＭＭＥ２０２との間で搬送するであろう。

図１８に図示される機能性は、以下に説明される図２１Ｃまたは２１Ｄに図示されるものの１つ等、無線デバイスまたは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよいことを理解されたい。また、図１８に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。また、図１８に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。

図１９は、信頼および非信頼ＷＬＡＮシナリオにおけるＵＥ２１４とＨＳＳ２１０との間の経路を示す。示されるように、ＳＴｂおよびＳＴｍ参照点は相互に類似する。故に、以下のように、統一認証および高速再認証プロシージャを非信頼ＷＬＡＮシナリオに拡張することが簡単となるであろう。
１． 図１３および図１４においてＵＥ２１４とＴＷＡＰ２２４との間の上記で定義された修正されたＥＡＰメッセージをＵＥ２１４とｅＰＤＧ１８０４との間の標準的ＩＫＥｖ２プロトコルを通じて搬送する。標準的ＩＫＥｖ２プロトコルの使用は、変更されず、３ＧＰＰ ＴＳ３３．４０２において使用されるものと同一となるであろう。
２． ＳＴｂ参照点（ＴＷＡＰ−ＭＭＥ）を経由して導入される「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ｒｅｑｕｅｓｔ」および「Ｄｉａｍｅｔｅｒ−ＥＡＰ−Ａｎｓｗｅｒ」メッセージは、ＳＴｍ参照点（ｅＰＤＧ−ＭＭＥ）を経由して正に使用されるであろう。それらは、ｅＰＤＧまたはＨＳＳから抽出される同一ＥＡＰメッセージを搬送するであろう。

図１９に図示される機能性は、以下に説明される図２１Ｃまたは２１Ｄに図示されるものの１つ等、無線デバイスまたは他の装置（例えば、サーバ、ゲートウェイ、デバイス、または他のコンピュータシステム）のメモリ内に記憶され、そのプロセッサ上で実行する、ソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装されてもよいことを理解されたい。また、図１９に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。また、図１８に図示される機能性は、仮想ネットワーク機能のセットとして実装されてもよいことを理解されたい。ネットワーク機能は、必ずしも、直接通信しなくてもよく、むしろ、それらは、転送またはルーティング機能を介して通信してもよい。
ユーザインターフェース

グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、ユーザが統一認証に関連する機能性を制御および／または構成することを補助するために使用されることができる。グラフィカルユーザインターフェース（ＧＵＩ）は、ＵＥ２１４が、どのアクセスネットワーク（ＬＴＥまたはＷｉ−Ｆｉ）を利用する（初期アタッチメントおよびハンドオーバの際）と、統一認証プロシージャを使用するかどうかとを決定することを可能にすることができる。

図２０は、最初に、マルチＲＡＴ（ＬＴＥ／Ｗｉ−Ｆｉ）ＵＥ２０４を伴うユーザが、ＬＴＥ（ボタン２００２）またはＷｉ−Ｆｉ（ボタン２００４）のいずれかに接続する（初期アタッチメントまたはハンドオーバにおいて）ことを選定することをイネーブルにする、グラフィカルユーザインターフェース（ＧＵＩ）２０００を描写する。１つのアクセスネットワークが利用不可能である場合、そのボタンは、ディスエーブルにされることができる。「統一認証」フラグが、ＵＥが、ＨｅＮＢ２２０またはＴＷＡＮ２１８に、統一認証プロシージャを行うことのその所望を示し得るように追加されている（図１２におけるステップ２および図１３におけるステップ３）。そのようなＵＥの２１４決定は、図２０に示されるＧＵＩ２０００を使用して判定されることができる。したがって、例えば、ＨｅＮＢ開始統一認証／アタッチメントプロシージャは、いったんＵＥ２１４が初期アタッチメントにおいて「ＬＴＥ」ボタン２００２および「統一認証」ボタン２００６を選定すると実行されるであろう。同様に、ＴＷＡＮ開始統一認証／アタッチメントプロシージャは、いったんＵＥ２１４が初期アタッチメントにおいてＧＵＩ２０００の「Ｗｉ−Ｆｉ」ボタン２００４および「統一認証」ボタン２００６をクリックすると実装されるであろう。代替として、通常認証ボタン２００８が、選択されることもできる。
インターフェース２０００は、以下で説明される図２１Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができることを理解されたい。
例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装されてもよい。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐してもよい。本装置は、本明細書に説明される方法をもたらすように、単独で、または相互と組み合わせて動作してもよい。本明細書で使用されるように、用語「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」は、同義的に使用されてもよい。

用語「サービス層」は、ネットワークサービスアーキテクチャ内の機能層を指す。サービス層は、典型的には、ＨＴＴＰ、ＣｏＡＰ、またはＭＱＴＴ等のアプリケーションプロトコル層の上方に位置し、付加価値サービスをクライアントアプリケーションに提供する。サービス層はまた、インターフェースを、例えば、制御層およびトランスポート／アクセス層等の下位リソース層におけるコアネットワークに提供する。サービス層は、サービス定義、サービスランタイム有効化、ポリシ管理、アクセス制御、およびサービスクラスタリングを含む、（サービス）能力または機能性の複数のカテゴリをサポートする。最近、いくつかの産業規格団体、例えば、ｏｎｅＭ２Ｍが、インターネット／ウェブ、セルラー、企業、およびホームネットワーク等の展開へのＭ２Ｍタイプのデバイスならびにアプリケーションの統合と関連付けられたチャレンジに対処するためのＭ２Ｍサービス層を開発している。Ｍ２Ｍサービス層は、アプリケーションおよび／または種々のデバイスに、ＣＳＥもしくはＳＣＬと称され得る、サービス層によってサポートされる前述の能力または機能性の集合もしくはセットへのアクセスを提供することができる。いくつかの実施例として、限定ではないが、種々のアプリケーションによって一般に使用され得る、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、およびコネクティビティ管理が挙げられる。これらの能力または機能性は、Ｍ２Ｍサービス層によって定義されたメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、そのような種々のアプリケーションに利用可能となる。ＣＳＥまたはＳＣＬは、それらにそのような能力もしくは機能性を使用するために、ハードウェアおよび／もしくはソフトウェアによって実装され得、種々のアプリケーションならびに／もしくはデバイスにエクスポーズされる（サービス）能力または機能性を提供する、機能エンティティ（すなわち、そのような機能エンティティ間の機能インターフェース）である。

図２１Ａは、１つまたはそれを上回る開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、またはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための構築ブロックを提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノードならびにＩｏＴ／ＷｏＴサービス層等であってもよい。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の機能性および論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティを含むことができる。

図２１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、イーサネット（登録商標）、ファイバ、ＩＳＤＮ、ＰＬＣ、または同等物）もしくは無線ネットワーク（例えば、ＷＬＡＮ、セルラー、または同等物）もしくは異種ネットワークのネットワークであってもよい。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト、または同等物等のコンテンツを複数のユーザに提供する、多重アクセスネットワークから成ってもよい。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、および同等物等の１つまたはそれを上回るチャネルアクセス方法を採用してもよい。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備えてもよい。

図２１Ａに示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインおよびフィールドドメインを含んでもよい。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、種々の異なるネットワークノード（例えば、サーバ、ゲートウェイ、デバイス、および同等物）を備えてもよい。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、端末デバイス１８とを含んでもよい。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８はそれぞれ、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送および受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍ端末デバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０または他のＭ２Ｍ端末デバイス１８に送信してもよい。Ｍ２Ｍ端末デバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍ端末デバイス１８からデータを受信してもよい。さらに、データおよび信号は、以下で説明されたように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信されてもよい。Ｍ２Ｍ端末デバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信してもよい。

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図２１Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の機能性および論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティを含むことができる。

Ｍ２Ｍサービス層２２は、例えば、以下で説明された図２１Ｃおよび２１Ｄで図示されるデバイスを含む、１つまたはそれを上回るサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）、または同等物によって実装されてもよい。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス、または同等物を備え得る、ネットワークの１つもしくはそれを上回るノードによって実装されてもよい。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装されてもよい。

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’が、存在する。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍ端末デバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによるサービス層と相互作用してもよい。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）、または同等物を備え得る、ネットワークの１つもしくはそれを上回るノードによって実装されてもよい。

また、図２１Ｂも参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができる、サービス送達能力のコアセットを提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、課金、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、ネットワーク１２を通して通信することも可能にする。

本願の方法は、サービス層２２および２２’の一部として実装されてもよい。サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含有し得る、サービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装されてもよい。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０’は、開示されるシステムおよび方法と併せて使用されてもよい。Ｍ２Ｍアプリケーション２０および２０’は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含んでもよく、また、他の開示されるシステムおよび方法と併せて使用されてもよい。

一実施形態では、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティは、図２１Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされてもよい。例えば、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の機能性エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備えてもよい。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界でのアプリケーションを含んでもよい。前述のように、本システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって作動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、課金、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、サービス層２２および２２’は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースのセットを通して付加価値サービス能力をサポートする、ソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャの両方は、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装されてもよい。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装されてもよい。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）のセットをサポートする。１つまたはそれを上回る特定のタイプのＣＳＦのセットのインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る、共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、またはＮＳＣＬで具現化されようと、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で具現化されようと、ｏｎｅＭ２ＭアーキテクチャのＣＳＦまたはＣＳＥで具現化されようと、もしくはネットワークのある他のノードとして具現化されようと、サービス層のインスタンスは、サーバ、コンピュータ、および他のコンピュータデバイスまたはノードを含む、ネットワーク内の１つもしくはそれを上回る独立型ノード上で実行される論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令、および同等物）として、もしくは１つまたはそれを上回る既存のノードの一部としてのいずれかで実装されてもよい。実施例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明された図２１Ｃまたは図２１Ｄで図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス、または同等物）上で作動するソフトウェアの形態において実装されてもよい。

さらに、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図２１Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ、または同等物等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティを実行する、または含むことができる。

デバイス３０は、図２１Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部または非Ｍ２Ｍネットワークの一部であり得る。図２１Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非リムーバブルメモリ４４と、リムーバブルメモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含んでもよい。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含んでもよい。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。本ノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであってもよい。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたはそれを上回るマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン、および同等物であってもよい。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されるコンピュータ実行可能命令を実行してもよい。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはＭ２Ｍノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を行ってもよい。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動させてもよい。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号動作等のセキュリティ動作を行ってもよい。

図２１Ｃに示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に連結される。プロセッサ３２は、ノード３０に、それが接続されるネットワークを介して他のノードと通信させるために、コンピュータ実行可能命令の実行を通して、通信回路を制御してもよい。特に、プロセッサ３２は、本明細書および請求項に説明される伝送および受信ステップを行うために、通信回路を制御してもよい。図２１Ｃは、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップ内にともに統合され得ることが理解されるであろう。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、および同等物を含む、他のＭ２Ｍノードに信号を伝送する、またはそこから信号を受信するように構成されてもよい。例えば、ある実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであってもよい。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー、および同等物等の種々のネットワークならびにエアインターフェースをサポートしてもよい。ある実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、または可視光信号を伝送ならびに／もしくは受信するように構成されるエミッタ／検出器であってもよい。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成されてもよい。伝送／受信要素３６は、無線または有線信号の任意の組み合わせを伝送ならびに／もしくは受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図２１Ｃに描写されているが、Ｍ２Ｍノード３０は、任意の数の伝送／受信要素３６を含んでもよい。より具体的には、Ｍ２Ｍノード３０は、ＭＩＭＯ技術を採用してもよい。したがって、ある実施形態では、Ｍ２Ｍノード３０は、無線信号を伝送および受信するための２つまたはそれを上回る伝送／受信要素３６（例えば、複数のアンテナ）を含んでもよい。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成されてもよい。上記のように、Ｍ２Ｍノード３０は、マルチモード能力を有してもよい。したがって、送受信機３４は、Ｍ２Ｍノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含んでもよい。

プロセッサ３２は、非リムーバブルメモリ４４および／またはリムーバブルメモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶してもよい。例えば、プロセッサ３２は、前述のように、セッションコンテキストをそのメモリ内に記憶してもよい。非リムーバブルメモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。リムーバブルメモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード、および同等物を含んでもよい。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等、Ｍ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶してもよい。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、または色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させる、またはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得る、または情報をユーザに表示するように構成されてもよい。別の実施例では、ディスプレイは、セッション状態に関する情報を示してもよい。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッションまたはその移行もしくは共有を双方向に確立および管理することを可能にしてもよい。

プロセッサ３２は、電源４８から電力を受容してもよく、Ｍ２Ｍノード３０内の他のコンポーネントへの電力を配信および／または制御するように構成されてもよい。電源４８は、Ｍ２Ｍノード３０に給電するための任意の好適なデバイスであってもよい。例えば、電源４８は、１つまたはそれを上回る乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池、および同等物を含んでもよい。

プロセッサ３２はまた、Ｍ２Ｍノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成され得る、ＧＰＳチップセット５０に連結されてもよい。Ｍ２Ｍノード３０は、実施形態と一致したままで、任意の好適な場所判定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、付加的な特徴、機能性、および／または有線もしくは無線接続を提供する、１つまたはそれを上回るソフトウェアならびに／もしくはハードウェアモジュールを含み得る、他の周辺機器５２に連結されてもよい。例えば、周辺機器５２は、種々のセンサ、例えば、加速度計、バイオメトリック（例えば、指紋）センサ、ｅ−コンパス、衛星送受信機、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポートまたは他の相互接続インターフェース、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および同等物を含んでもよい。

ノード３０は、センサ、消費者電子機器、装着式デバイス、例えば、スマートウォッチまたはスマート衣類、医療またはｅヘルスデバイス、ロボット、産業機器、ドローン、車両、例えば、車、トラック、電車、または飛行機等の他の装置またはデバイス内に具現化されてもよい。ノード３０は、周辺機器５２のうちの１つを備え得る相互接続インターフェース等の１つまたはそれを上回る相互接続インターフェースを介して、そのような装置またはデバイスの他のコンポーネント、モジュール、またはシステムに接続してもよい。代替として、ノード３０は、センサ、消費者電子機器、装着式デバイス、例えば、スマートウォッチまたはスマート衣類、医療またはｅヘルスデバイス、ロボット、産業機器、ドローン、車両、例えば、車、トラック、電車、または飛行機等の装置もしくはデバイスを備えてもよい。

図２１Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または他のノード等、Ｍ２Ｍネットワークの１つまたはそれを上回るノードを実装するためにも使用され得る、例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備えてもよく、主に、ソフトウェアの形態であり得るコンピュータ可読命令によって制御されてもよく、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピューティングシステム９０は、ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティを実行する、または含むことができる。

コンピューティングシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む、任意の他のノードであり得る。そのようなコンピュータ可読命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行されてもよい。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備えてもよい。コプロセッサ８１は、付加的な機能を果たすか、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは明確に異なる、随意的なプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等、Ｅ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理してもよい。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、およびそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、割り込みを送信するため、およびシステムバスを動作するための制御ラインとを含む。そのようなシステムバス８０の実施例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に連結されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２と、読取専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶され、読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正され得ない、記憶されたデータを含有する。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られる、もしくは変更されてもよい。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御されてもよい。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換する、アドレス変換機能を提供してもよい。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離する、メモリ保護機能を提供してもよい。したがって、第１のモードで作動するプログラムは、その独自のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることはできない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を伝達する責任がある、周辺機器コントローラ８３を含有してもよい。

ディスプレイコントローラ９６によって制御される、ディスプレイ８６は、コンピューティングシステム９０によって生成される視覚的出力を表示するために使用される。そのような視覚的出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含んでもよい。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装されてもよい。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される、電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、例えば、図２１Ａおよび図２１Ｂのネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、ネットワークアダプタ９７等の通信回路を含有し、コンピューティングシステム９０が、ネットワークの他のノードと通信することを可能にしてもよい。

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであることができる。これは、携帯電話、モバイルブロードバンドアダプタを装備するラップトップコンピュータ、または任意の他のデバイスであることができる。例えば、ＵＥは、図２１Ａ−ＢのＭ２Ｍ端末デバイス１８または図２１Ｃのデバイス３０として実装されることができる。

本明細書で説明されたシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ可読記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、または同等物を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを行うならびに／もしくは実装することが理解される。具体的には、ゲートウェイ、ＵＥ、ＵＥ／ＧＷ、またはモバイルコアネットワーク、サービス層、もしくはネットワークアプリケーションプロバイダのノードのうちのいずれかの動作を含む、前述のステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態において実装されてもよい。ＭＭＥ２０２、ＷＬＡＮ ＡＮ２０４、Ｓ−ＧＷ２０６、Ｐ−ＧＷ２０８、ＨＳＳ２１０、３ＧＰＰ ＡＡＡサーバ２１２、ＵＥ２１４、ＥＰＣ２１６、ＴＷＡＮ２１８、ＨｅＮＢ２２０、ＴＷＡＰ２２４、ＩＳＷＮ２３０、ＴＷＡＧ２３２、Ｓ−ＧｗＩＰ−ＧＷ１００２、マクロｅＮＢ１７０２、非信頼ＷＬＡＮ１８０２、およびｅＰＤＧ１８０４等の論理エンティティならびに図２０に示されるユーザインターフェース２０００を生成するための論理エンティティは、コンピュータ可読記憶媒体上に記憶されるコンピュータ実行可能命令の形態において具現化されてもよい。コンピュータ可読記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理）方法もしくは技術で実装される、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体の両方を含むが、そのようなコンピュータ可読記憶媒体は、信号を含まない。コンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の有形または物理媒体を含むが、それらに限定されない。

図に図示されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、具体的用語が採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図しておらず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、実施例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の実施例を含んでもよい。そのような他の実施例は、請求項の文字通りの言葉とは異ならない要素を有する場合に、または請求項の文字通りの言葉とのごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (19)

1. プロセッサおよびメモリを備える装置であって、前記装置は、前記装置のメモリ内に記憶されるコンピュータ実行可能命令をさらに含み、前記命令は、前記装置のプロセッサによって実行されると、前記装置に、
   第１の無線アクセス技術を使用する第１のアクセスポイントを通して、ネットワークに接続することであって、前記第１のアクセスポイントを通した前記ネットワークへの接続に応じて、前記装置は、完全認可を行う、ことと、
   その後、第２の無線アクセス技術を使用する第２のアクセスポイントを通した前記ネットワークへの接続に切り替えることであって、前記第２のアクセスポイントを通した前記ネットワークへの接続に応じて、前記装置は、高速認可を行い、前記高速認可は、前記完全認可において行われた少なくとも１つの認証ステップを行わない、ことと
   を行わせる、装置。
2. 前記第１および第２のアクセスポイントのうちの一方は、ＷｉＦｉアクセスポイントであって、前記第１および第２のアクセスポイントのうちの他方は、セルラーアクセスポイントである、請求項１に記載の装置。
3. 前記ＷｉＦｉアクセスポイントは、信頼または非信頼ＷＬＡＮのためのものである、請求項２に記載の装置。
4. 前記セルラーアクセスポイントは、ｅＮｏｄｅＢのためのものである、請求項２に記載の装置。
5. 前記第１のアクセスポイントに接続するための前記装置からの要求は、前記第１および第２のアクセスポイントの両方との認証が所望されることのインジケーションを含む、請求項１に記載の装置。
6. 前記第１のアクセスポイントは、再認証ＩＤを前記装置に提供し、前記再認証ＩＤは、高速再認証の間、前記第２のアクセスポイントに提供される、請求項１に記載の装置。
7. 前記第１および第２のアクセスポイントは、単一ボックス内において統合サービス無線ネットワーク（ＩＳＷＮ）として組み合わせられる、請求項１に記載の装置。
8. 高速認証および前記完全認証の両方において、前記装置は、ホーム加入者サーバ（ＨＳＳ）ではなく、モビリティ管理エンティティ（ＭＭＥ）と相互作用する、請求項１に記載の装置。
9. 前記第１および第２のアクセスポイントのうちの一方は、ＷｉＦｉアクセスポイントであって、前記装置は、前記ＷｉＦｉアクセスポイントと前記ＭＭＥとの間を接続する、インターフェースを使用する、請求項８に記載の装置。
10. 前記装置は、ユーザ機器である、請求項１に記載の装置。
11. プロセッサおよびメモリを備える装置であって、前記装置は、前記装置のメモリ内に記憶されるコンピュータ実行可能命令をさらに含み、前記命令は、前記装置のプロセッサによって実行されると、前記装置に、
    第１の無線アクセス技術を使用する第１のアクセスポイントおよび第２の無線アクセス技術を使用する第２のアクセスポイントのうちの１つを通したユーザ機器との接続に応じて、前記ユーザ機器との完全認可を実行することと、
    その後、前記第１および第２のアクセスポイントのうちの他方を通した接続への切替に応じて、高速認可を実行することであって、高速認証は、前記装置とユーザ機器との間の相互認証ステップを要求しない、ことと
    を行わせる、装置。
12. 前記完全認証では、前記装置は、前記ユーザ機器に再認証ＩＤおよびアクセスネットワーク識別のうちの少なくとも１つを提供する、請求項１１に記載の装置。
13. 前記高速認証では、前記装置は、認証および鍵共有（ＡＫＡ）を起動しない、請求項１１に記載の装置。
14. 前記装置は、ネットワーク機能である、請求項１１に記載の装置。
15. 前記高速認証の両方は、前記ユーザ機器がホーム加入者サーバ（ＨＳＳ）と相互作用することを要求しない、請求項１４に記載の装置。
16. 前記第１および第２のアクセスポイントのうちの一方は、ＷｉＦｉアクセスポイントであって、前記ネットワーク機能は、前記ＷｉＦｉアクセスポイントと前記ネットワーク機能との間を接続する、インターフェースを使用する、請求項１１に記載の装置。
17. 装置による使用のための方法であって、前記装置は、プロセッサおよびメモリを備え、前記装置はさらに、前記メモリ内に記憶されるコンピュータ実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
    第１の無線アクセス技術を使用する第１のアクセスポイントを通してネットワークに接続するステップであって、前記第１のアクセスポイントを通した前記ネットワークへの接続に応じて、前記装置は、完全認可を行う、ステップと、
    その後、第２の無線アクセス技術を使用する第２のアクセスポイントを通した前記ネットワークへの接続に切り替えるステップであって、前記第２のアクセスポイントを通した前記ネットワークへの接続に応じて、前記装置は、高速認可を行い、前記高速認可は、前記完全認可において行われた少なくとも１つの認証ステップを行わない、ステップと、
    を含む方法の機能を実行する、方法。
18. 前記装置は、ユーザ機器である、請求項１７に記載の方法。
19. 装置による使用のための方法であって、前記装置は、プロセッサおよびメモリを備え、前記装置はさらに、前記メモリ内に記憶されるコンピュータ実行可能命令を含み、前記命令は、前記プロセッサによって実行されると、
    第１の無線アクセス技術を使用する第１のアクセスポイントおよび第２の無線アクセス技術を使用する第２のアクセスポイントのうちの１つを通したユーザ機器との接続に応じて、前記ユーザ機器との完全認可を行うステップと、
    その後、前記第１および第２のアクセスポイントのうちの他方を通した接続への切替に応じて、高速認可を行うステップであって、高速認証は、前記装置とユーザ機器との間の相互認証ステップを要求しない、ステップと、
    を含む方法の機能を実行する、方法。