特許第5694296号(P5694296)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社東芝の特許一覧 ▶ テルコーディア・テクノロジーズ・インコーポレーテッドの特許一覧

<>
  • 特許5694296-プロアクティブ認証 図000017
  • 特許5694296-プロアクティブ認証 図000018
  • 特許5694296-プロアクティブ認証 図000019
  • 特許5694296-プロアクティブ認証 図000020
  • 特許5694296-プロアクティブ認証 図000021
  • 特許5694296-プロアクティブ認証 図000022
  • 特許5694296-プロアクティブ認証 図000023
  • 特許5694296-プロアクティブ認証 図000024
  • 特許5694296-プロアクティブ認証 図000025
  • 特許5694296-プロアクティブ認証 図000026
  • 特許5694296-プロアクティブ認証 図000027
  • 特許5694296-プロアクティブ認証 図000028
  • 特許5694296-プロアクティブ認証 図000029
  • 特許5694296-プロアクティブ認証 図000030
  • 特許5694296-プロアクティブ認証 図000031
  • 特許5694296-プロアクティブ認証 図000032
  • 特許5694296-プロアクティブ認証 図000033
  • 特許5694296-プロアクティブ認証 図000034
  • 特許5694296-プロアクティブ認証 図000035
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5694296
(24)【登録日】2015年2月13日
(45)【発行日】2015年4月1日
(54)【発明の名称】プロアクティブ認証
(51)【国際特許分類】
   H04W 12/06 20090101AFI20150312BHJP
   H04W 36/14 20090101ALI20150312BHJP
   H04W 88/06 20090101ALI20150312BHJP
   H04W 12/04 20090101ALI20150312BHJP
   H04L 9/32 20060101ALI20150312BHJP
   G09C 1/00 20060101ALI20150312BHJP
   H04L 9/08 20060101ALI20150312BHJP
【FI】
   H04W12/06
   H04W36/14
   H04W88/06
   H04W12/04
   H04L9/00 675A
   G09C1/00 640E
   H04L9/00 601B
   H04L9/00 601E
【請求項の数】20
【全頁数】43
(21)【出願番号】特願2012-509878(P2012-509878)
(86)(22)【出願日】2010年5月3日
(65)【公表番号】特表2012-526455(P2012-526455A)
(43)【公表日】2012年10月25日
(86)【国際出願番号】US2010033415
(87)【国際公開番号】WO2010129479
(87)【国際公開日】20101111
【審査請求日】2013年2月8日
(31)【優先権主張番号】61/221,551
(32)【優先日】2009年6月29日
(33)【優先権主張国】US
(31)【優先権主張番号】61/175,016
(32)【優先日】2009年5月3日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】000003078
【氏名又は名称】株式会社東芝
(73)【特許権者】
【識別番号】504473670
【氏名又は名称】テルコーディア・テクノロジーズ・インコーポレーテッド
(74)【代理人】
【識別番号】100108855
【弁理士】
【氏名又は名称】蔵田 昌俊
(74)【代理人】
【識別番号】100091351
【弁理士】
【氏名又は名称】河野 哲
(74)【代理人】
【識別番号】100088683
【弁理士】
【氏名又は名称】中村 誠
(74)【代理人】
【識別番号】100109830
【弁理士】
【氏名又は名称】福原 淑弘
(74)【代理人】
【識別番号】100075672
【弁理士】
【氏名又は名称】峰 隆司
(74)【代理人】
【識別番号】100095441
【弁理士】
【氏名又は名称】白根 俊郎
(74)【代理人】
【識別番号】100084618
【弁理士】
【氏名又は名称】村松 貞男
(74)【代理人】
【識別番号】100103034
【弁理士】
【氏名又は名称】野河 信久
(74)【代理人】
【識別番号】100140176
【弁理士】
【氏名又は名称】砂川 克
(72)【発明者】
【氏名】ダス、スビア
(72)【発明者】
【氏名】大場 義洋
(72)【発明者】
【氏名】ドゥッタ、アシュトシュ
【審査官】 望月 章俊
(56)【参考文献】
【文献】 米国特許出願公開第2009/0067623(US,A1)
【文献】 米国特許出願公開第2007/0091846(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04W4/00−H04W99/00
H04B7/24−H04B7/26
G09C1/00
H04L9/08
H04L9/32
(57)【特許請求の範囲】
【請求項1】
メディア独立アクセス機能を実装したコンピュータを有する装置であって、
異種メディア間でアタッチされたモバイルデバイスを認証する独立オーセンティケータと;
各々が固有のサービングメディアに対応する固有のオーセンティケータをサポートする複数の異種アクセスネットワークに前記独立オーセンティケータを接続するインターフェースと;
前記コンピュータのメディア独立機能に基づいた所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーとを具備し、
前記独立オーセンティケータは、サービングアクセスネットワークから、それぞれ固有のサービングメディアを持つ複数の異種アクセスネットワークに属する候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークを認証し、
前記ハンドオーバに先立って前記候補アクセスネットワークを認証することが、前記独立オーセンティケータによって正常に行われた後に、前記独立オーセンティケータが、前記モバイルデバイスに関するメディアキーを生成し、メディア固有鍵を固有オーセンティケータに利用可能にし、
全体の認証プロセスを実行するために前記複数のモバイルデバイスを必要とすることなく、かつ、前記固有オーセンティケータでメディア固有セキュリティアソシエーションを成功して確立した後に、前記独立オーセンティケータに登録するために前記独立オーセンティケータとIP接続を確立する前記複数のモバイルデバイスを必要とすることなく、前記複数の固有のアクセスネットワークのうちのいずれかへ切り替える際に、前記モバイルデバイスは、利用可能な前記メディア固有鍵を使用して、前記固有のオーセンティケータで前記メディア固有セキュリティアソシエーションを実行する、装置。
【請求項2】
前記独立オーセンティケータと前記固有のオーセンティケータの間に提供された固有インターフェースによって前記メディア固有鍵が候補アクセスネットワークのサービングアクセスネットワークおよび固有のオーセンティケータからプルまたはプッシュされ、
前記独立オーセンティケータは、前記ハンドオーバのためのペアワイズメディア独立マスター認証鍵を得るためにマスター認証鍵を保持する、請求項1の装置。
【請求項3】
前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために、最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項2の装置。
【請求項4】
前記複数の異種アクセスネットワークの各々は、前記インターフェースを介して専用の独立オーセンティケータに接続され;
前記専用の独立オーセンティケータと前記複数の異種アクセスネットワークの各々との間に相互の通信接続を形成する個別のインターフェースを具備し、
前記専用の独立オーセンティケータとともに前記複数の異種アクセスネットワークの各々は2つの個別サービスポイントを有する、請求項1の装置。
【請求項5】
前記独立オーセンティケータは、前記インターフェースを介した前記複数の異種アクセスネットワークの各々との間の相互通信を管理するための単一のサービスポイントである、請求項1の装置。
【請求項6】
対応する候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って、該モバイルデバイスがアタッチされるサービングアクセスネットワークを経ることにより、前記モバイルデバイスは、前記対応する候補アクセスネットワークの前記独立オーセンティケータとの認証を行なう、請求項1の装置。
【請求項7】
前記ハンドオーバのトリガーは、前記候補アクセスネットワーク、または前記モバイルデバイスによって生成することが可能である、請求項4の装置。
【請求項8】
前記モバイルデバイスは、対応する候補アクセスネットワークへの該モバイルデバイスのハンドオーバに先立って、前記対応する候補アクセスネットワークの独立オーセンティケータとの認証を直接行なう、請求項1の装置。
【請求項9】
前記ハンドオーバのトリガーは、前記モバイルデバイスからの応答が続く候補アクセスネットワークによって、または前記候補アクセスネットワークからの応答が続くモバイルデバイスによって生成することができる、請求項8の装置。
【請求項10】
前記サービングメディアはケーブル、ファイバー、無線周波数および衛星を含む請求項1の装置。
【請求項11】
プロセッサが、異種メディア間でアタッチされたモバイルデバイスをメディア独立オーセンティケータによってプロアクティブに認証する動作を実行可能にするための命令がコード化されたマシンアクセス可能な記憶媒体に記憶されるプログラムであって、
前記命令は、
複数の異種アクセスネットワーク内のサービングアクセスネットワークにアタッチされたモバイルデバイスにメディア固有認証手続きを割り当てること;
前記メディア独立オーセンティケータを介して候補アクセスネットワークに関する情報をハンドオーバ準備段階でモバイルデバイスに提供すること;
インターフェースを用いて、プロアクティブ認証を行なうこと;
前記メディア独立オーセンティケータによって前記プロアクティブ認証が正常に行なわれると、それぞれの前記モバイルデバイスに関するメディア固有鍵を生成し、前記メディア固有認証手続きを有する前記異種アクセスネットワークに前記メディア固有鍵を利用可能にすること;
全体の認証プロセスを実行するために前記複数のモバイルデバイスを必要とすることなく、前記複数の異種アクセスネットワークのうちのいずれかへ切り替える際に、メディア固有セキュリティアソシエーションを実行するために、利用可能な前記メディア固有鍵を使用すること;
それぞれの前記異種アクセスネットワークで前記メディア固有セキュリティアソシエーションを成功して確立した後に、サーバに登録するために前記メディア独立オーセンティケータとIP接続を確立すること;
前記複数の異種アクセスネットワークに属する候補アクセスネットワークへのハンドオーバを実行すること、を具備するプログラム
【請求項12】
前記メディア独立オーセンティケータおよびメディア固有オーセンティケータの間で提供される固有インターフェースによって、前記サービングアクセスネットワークおよび前記候補アクセスネットワークから前記メディア固有鍵をプルまたはプッシュし、
前記メディア独立オーセンティケータは、ハンドオーバのためのペアワイズのメディア独立マスター認証鍵を得るためのマスター認証鍵を保持する、請求項11のプログラム
【請求項13】
前記モバイルデバイスは、候補アクセスネットワークへの該モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークのメディア独立オーセンティケータとのプロアクティブ認証を直接行なう、請求項12のプログラム
【請求項14】
前記モバイルデバイスからの応答が、前記候補アクセスネットワークによるハンドオーバのトリガーの生成に続いて起こる、請求項13のプログラム
【請求項15】
前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために、最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項14のプログラム
【請求項16】
前記候補アクセスネットワークからの応答が、前記モバイルデバイスによる前記ハンドオーバのトリガーの生成に続いて起こる、請求項13のプログラム
【請求項17】
前記候補アクセスネットワークおよび前記モバイルデバイスは、メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために、最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項16のプログラム
【請求項18】
前記モバイルデバイスは、前記候補アクセスネットワークへのモバイルデバイスのハンドオーバに先立って、前記モバイルデバイスはアタッチされる前記サービングアクセスネットワークを経ることにより、前記候補アクセスネットワークのメディア独立オーセンティケータとのプロアクティブ認証を行なう、請求項11のプログラム
【請求項19】
前記メディア独立オーセンティケータおよびメディア固有オーセンティケータの間に提供される固有インターフェースを介して前記サービングアクセスネットワークおよび前記候補アクセスネットワークからメディア固有鍵をプルまたはプッシュし、
前記モバイルデバイスからの応答が、前記候補アクセスネットワークによる前記ハンドオーバのトリガーの生成に続いて起こり、
前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成し;
前記候補アクセスネットワークからの前記応答が、前記モバイルデバイスによる前記ハンドオーバのトリガーの生成に続いて起こり、前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項18のプログラム
【請求項20】
メディアに固有のリンクの終端にインターフェースを介してアタッチされた他のエンティティを認証するメディア独立認証機能を含むメディア独立アクセス機能を有するサーバと;
前記メディアに固有の前記リンクの前記終端に前記インターフェースを介してアタッチされた前記他のエンティティに対応する認証機能を含むメディア固有アクセス機能を各々が含んでいる複数の異種アクセスネットワークと;
前記複数の異種アクセスネットワークに接続されるモバイルデバイスとを具備し、
前記サーバは、ハンドオーバに関するメディア独立機能に基づく所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーを有し、
前記サーバは、サービングアクセスネットワークから、候補アクセスネットワークへの前記モバイルデバイスの前記ハンドオーバに先立って前記候補アクセスネットワークを認証し、前記候補アクセスネットワークの各々は前記メディアに固有の前記リンクを有する前記複数の異種アクセスネットワークに属し、
ハンドオーバ認証に先立って前記候補アクセスネットワークを認証することが前記サーバによって正常に行われた後に、前記サーバが、それぞれの前記モバイルデバイスに関するメディア固有鍵を生成し、前記メディア固有アクセス機能および認証機能を提供する前記異種アクセスネットワークに前記メディア固有鍵を利用可能にし、
全体の認証プロセスを実行するために前記モバイルデバイスを必要とすることなく、かつ、それぞれの前記異種アクセスネットワークでメディア固有セキュリティアソシエーションを成功して確立した後に、前記サーバに登録するために前記サーバとIP接続を確立する前記モバイルデバイスを必要とすることなく、前記複数の異種アクセスネットワークのうちのいずれかへ切り替える際に、前記モバイルデバイスは、利用可能な前記メディア固有鍵を使用して、前記メディア固有セキュリティアソシエーションを実行する、プロアクティブな認証のためのシステム。
【発明の詳細な説明】
【関連出願】
【0001】
本出願は、2009年5月3日提出の米国仮出願第60/917,549号および2009年6月29日提出の米国仮出願第61/221,551号の優先権を主張するものであって、これらの開示内容の全体が参照により本明細書に組み込まれる。
【背景技術】
【0002】
1.技術分野
本発明は、異種ネットワーク間のセキュリティシグナリングに関し、特に、モバイルノート(MN)とターゲットネットワークの間のセキュアなハンドオーバを行うためのオーセンティケーションおよびオーサリゼーションの概念に関する。
【0003】
2.背景論議
ネットワークおよびインターネット(登録商標)プロトコル:
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザーが利用可能な、公衆の自律的ネットワークである。インターネットは、TCP/IP(すなわち、伝送制御プロトコル/インターネットプロトコル)と呼ばれる1組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業および個人へのアクセスを再販するインターネットサービスプロバイダ(ISP)によって制御される。
【0004】
IP(インターネットプロトコル)に関して、これは、ネットワーク上である装置(電話機、PDA[携帯情報端末]、コンピュータなど)から別の装置にデータを送るためのプロトコルである。今日、IPv4、IPv6などを含めて、様々なIPのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも1つのIPアドレスを有する。IPはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザーがデータまたはメッセージを送信し、または受信するとき、データまたはメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【0005】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、OSI(開放型システム間相互接続)モデルが確立された。OSIモデルは、ネットワーク中の2点間の通信プロセスを7つの階層に分け、各層(レイヤー)は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。7つの機能層を提供するプログラミングおよび/またはハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、TCP/IPおよび/または他のトランスポートおよびネットワークプロトコル、ならびに他のソフトウェアおよびハードウェアの組み合わせである。
【0006】
通常、上位4層は、メッセージがユーザーから、またはユーザーへ渡されるときに使用され、下位3層は、メッセージが装置(IPホスト装置など)を通過するときに使用される。IPホストは、サーバ、ルータ、ワークステーションなど、IPパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。OSIモデルの各層を以下に列記する。第7層(すなわち、アプリケーション層)は、例えば、通信相手が識別され、サービス品質が識別され、ユーザー認証およびプライバシが考慮され、データ構文に対する制約条件が識別される層である。第6層(すなわち、プレゼンテーション層)は、例えば、着信および発信データをあるプレゼンテーション形式から別の形式に変換する層である。第5層(すなわち、セッション層)は、例えば、アプリケーション間の会話、交換およびダイアログをセットアップし、調整し、終了させる層である。第4層(すなわち、トランスポート層)は、例えば、エンドツーエンド制御および誤りチェックなどを管理する層である。第3層(すなわち、ネットワーク層)は、例えば、ルーティングや転送などを処理する層である。第2層(すなわち、データリンク層)は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識および管理などを提供する層である。米国電気電子技術者協会(IEEE)では、データリンク層を、物理層との間のデータ転送を制御するMAC(媒体アクセス制御)層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うLLC(論理リンク制御)層という、2つのさらなる副層(サブレイヤー)に細分する。第1層(すなわち、物理層)は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。IEEEでは、物理層を、PLCP(物理層収束手順)副層とPMD(物理媒体依存)副層とに細分する。
【0007】
無線ネットワーク:
無線ネットワークは、例えば、セルラおよび無線電話機、PC(パーソナルコンピュータ)、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、PDAなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声および/またはデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次の構成要素の一部または全部、即ち送受信機(すなわち、例えば、送信機、受信機および、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機および受信機)、アンテナ、プロセッサ、1つまたは複数の音声変換器(例えば、音声通信用機器でのスピーカやマイクロホンなど)、電磁データ記憶(データ処理が提供される機器の場合などでの、ROM、RAM、デジタルデータ記憶など)、メモリ、フラッシュメモリ、フルチップセットまたは集積回路、インターフェース(USB、CODEC、UART、PCMなど)および/または同種のものを含む。
【0008】
モバイルユーザーが無線接続を介してローカルエリアネットワーク(LAN)に接続することのできる無線LAN(WLAN)が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース(登録商標)、IEEE802.11、HomeRFなど、様々なWLAN標準が存在する。
【0009】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末(PDA)、および他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータおよび電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザー問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名(BDN)または一意のブルートゥース機器アドレス(BDA)に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル(IP)ネットワークに参加することもできる。ブルートゥース機器がIPネットワーク上で機能する場合、この機器は、IPアドレスおよびIP(ネットワーク)名を備え得る。よって、IPネットワークに参加するように構成されたブルートゥース機器は、BDN、BDA、IPアドレスおよびIP名などを含むことができる。「IP名」という用語は、インターフェースのIPアドレスに対応する名前を指す。
【0010】
IEEE標準であるIEEE802.11は、無線LANおよび機器の技術の仕様を定める。802.11を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザーが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、802.11で使用される機器は、通常、機器がアクセスポイント(AP)であるか、移動局(STA)であるか、ブリッジであるか、PCMCIAカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、およびネットワークにおける各点間のパケットの流れを制御するMAC(媒体アクセス制御)層という3つの注目すべき要素を含む。
【0011】
更に、いくつかの無線ネットワークでは、複数インターフェース機器(MID)が利用できる。MIDは、ブルートゥースインターフェースと802.11インターフェースなど、2つの独立のネットワークインターフェースを含むことができ、よって、MIDが2つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。MIDは、IPアドレス、およびIPアドレスに関連付けられた共通IP(ネットワーク)名を持つことができる。
【0012】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器(MID)、802.11x機器(802.11a、802.11b、802.11g機器などを含む、IEEE802.11機器)、HomeRF(家庭内無線周波数)機器、Wi−Fi(Wireless Fidelity)機器、GPRS(汎用パケット無線システム)機器、3Gセルラ機器、2.5Gセルラ機器、GSM(登録商標)(移動通信用グローバルシステム)機器、EDGE(Enhanced Data for GSM Evolution)機器、TDMA型(時分割多重接続)機器、またはCDMA2000を含むCDMA型(符号分割多重接続)機器が含めることができる。各ネットワーク機器は、それだけに限らないが、IPアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースIPアドレス、ブルートゥースIP共通名、802.11IPアドレス、802.11IP共通名、IEEE MACアドレスを含む、様々な種類のアドレスを含むことができる。
【0013】
また、無線ネットワークは、例えば、モバイルIP(インターネットプロトコル)システム、PCSシステム、および他のモバイルネットワークシステムにおいて見られる方法およびプロトコルも関与できる。モバイルIPでは、これに、インターネット技術標準化委員会(IETF)によって作成された標準通信プロトコルが関与する。モバイルIPでは、モバイル機器ユーザーは、これらの一旦割り当てられたIPアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求(RFC)3344を参照されたい。(注:RFCはインターネット技術標準化委員会(IETF)の公式文書である。)モバイルIPは、インターネットプロトコル(IP)を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルIPは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワークおよびこれのサブネット内の機器の現在位置を識別する気付アドレス(CoA)を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル(ICMP)などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【0014】
(例えば、モバイルIP外部などの)基本的なIPルーティングにおいて、ルーティング機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのIPアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、および/または転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するIPアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルIP通信の場合、ユーザーが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいIPアドレス、適正なネットマスクおよびデフォルトのルータを用いて再構成する必要がある。そうでなければ、ルーティングプロトコルは、パケットを適正に配信することができないはずである。
【0015】
メディア独立ハンドオーバサービス:
Draft IEEE Standard for Local and Metropolitan Area Networks:Media Independent Handover Services(地元地域および大都市圏のネットワークのためのドラフトIEEE規格:メディア独立ハンドオーバサービス)と題する2006年9月のIEEE.P802.21/D.01.09において、特にこの文書は802システムとセルラーシステムとの間のハンドオーバを最適化する802メディアアクセス独立機構を明記している。IEEE802.21規格は、異種802システム間のハンドオーバの最適化を可能にし、また802システムとセルラーシステムとの間のハンドオーバを容易にし得る、拡張可能なメディアアクセス独立機構を定義している。
【0016】
IEEE802.21(メディア独立ハンドオーバ)規格の範囲は、異種メディア間のハンドオーバを最適化するためにリンク層情報および他の関連ネットワーク情報を上位層に供給する仕様を開発することである。これは、3GPPと、3GPP2と、IEEE802ファミリーの規格における有線および無線メディア両者と、によって指定されるリンクを含む。この文書では「メディア」は、他に注記されていなければ、通信の感覚的態様(例えばオーディオ、ビデオなど)とは対照的に、電気通信システムにアクセスする方法/モード(例えばケーブル、無線通信、衛星など)を指す。文書の全内容がこの特許出願書にその一部として組み込まれているDraft IEEE Standard for Local and Metropolitan Area Networks:Media Independent Handover Services(地元地域および大都市圏のネットワークのためのドラフトIEEE規格:メディア独立ハンドオーバサービス)と題する2006年9月のI.E.E.E.P802.21/D.01.09の1.1を参照されたい。更に、ここで優先権が主張されている仮出願はまた、上記の規格のドラフト05(ここではD05と呼ばれる)および2009年1月21日公開のI.E.E.E.802.21規格を組み込んでおり、これらの全内容は参照により本明細書に組み込まれている−すなわち、例えばI.E.E.E.コンピュータ学会のLAN MAN規格委員会によって後援されているDraft Standard for Local and Metropolitan Area Networks:Media Independent Handover Services(地元地域および大都市圏のネットワークのためのドラフト規格:メディア独立ハンドオーバサービス)と題する2007年4月のI.E.E.E.P802.21/D05.00およびI.E.E.E.コンピュータ学会のLAN MAN規格委員会によって後援されているLocal and Metropolitan Area Networks−−Part21:Media Independent Handover Services(地元地域および大都市圏のネットワークのためのドラフト規格:メディア独立ハンドオーバサービス)と題する2009年1月21日公開のI.E.E.E.規格をそれぞれ参照されたい。
【0017】
一般的アーキテクチャ:
序論:
IEEE802.21規格は、種々のハンドオーバ方法を容易にするように意図されている。このような方法は一般に、モバイルノードとネットワークとの間のデータパケットの交換をサポートするデータトランスポート(データ搬送)ファシリティーに関して、ハンドオーバ手順が「メーク前ブレーク(break before make)」または「ブレーク前メーク(make before break)」であるかどうかによって「ハード」または「ソフト」として分類される。
【0018】
一般にハンドオーバは、ネットワークオペレータとエンドユーザーのニーズを満足させるためにモバイルノードとネットワークインフラストラクチャの両者の協力的使用にかかわる。ハンドオーバ意思決定に関連するハンドオーバ制御、ハンドオーバ方策および他のアルゴリズムは一般に、IEEE802.21規格の範囲に入らない通信システム要素によって取り扱われる。しかしながら、全ハンドオーバプロセスにおけるMIHイベントサービス、MIHコマンドサービス、MIH情報サービスおよびMIHFの役割と目的が明らかになるように全ハンドオーバ手順の幾つかの態様を説明することは有益である。
【0019】
一般的設計原理:
IEEE802.21規格は、下記の一般的設計原理に基づいている。
【0020】
a)MIH機能は、ハンドオーバ意思決定を助けて容易にする論理的エンティティである。上位層は、MIHからの入力と前後関係とに基づいてハンドオーバ意思決定とリンク選択とを行う。ハンドオーバが行われるべきであるという認識を容易にすることは、MIHFの主要な目標の1つである。効果的なハンドオーバ意思決定を行う方法に関する情報の発見もまた主要構成要素である。
【0021】
b)MIHFは、より上位の層に抽象サービスを提供する。この観点からMIHFは、上位層に統一的インターフェースを提供する。この統一インターフェースによってあらわになるサービスプリミティブは、異なるアクセスネットワークの技術固有プロトコルエンティティに基づいている。MIHFは、技術固有インターフェースを介してモビリティ管理プロトコルスタックの下位層と通信する。
【0022】
下位層とのMIHFインターフェースの仕様は、一般にこの規格の範囲内に入らない。このようなインターフェースは既に、IEEE802.1、IEEE802.3、IEEE802.11、IEEE802.16、3GPPおよび3GPP2といったそれぞれのアクセス技術に関連する規格内のサービスアクセスポイント(SAP)として明記され得る。この規格は、下位層インターフェースの修正がMIHF機能を利用可能にし得る、または改善し得るときに既存のアクセス技術固有規格を修正するための勧告を含み得る。
【0023】
c)ハンドオーバシグナリング(ハンドオーバ実行および後続の更新の一部としての)は、この規格の一部でない可能性がある。異なるアクセスネットワークは、(移動体起動、ネットワーク起動などの)水平ハンドオーバ機構をサポートする。ハンドオーバ起動トリガーは、同種方式のように行われないときに異種ハンドオーバにおいて有用であり得る。
【0024】
d)MIHFは、MAC/PHYトリガーおよび他の関連ローカルイベントについて更なる処理を行い得る。この処理の定義は、この規格の範囲外である。この規格は、リモートイベントに関してもサポートを与えるであろう。イベントは実際はアドバイザリである。これらのイベントに基づいてハンドオーバを引き起こすべきか否かの決定は、この規格の範囲外である。
【0025】
e)この規格は、MN起動、MN制御、ネットワーク起動およびネットワーク制御のハンドオーバをサポートするための機構を指定するであろう。
【0026】
f)本規格は、レガシー装置とのトランスペアレントな相互作用をサポートし得る。したがってIEEE802.21準拠の装置は、レガシー非IEEE802.21準拠装置と共存し得るであろう。
【0027】
メディア独立ハンドオーバ基準フレームワーク:
下記のセクションは、クライアントデバイス(MN)とネットワークとに置ける異なるMIHFエンティティ間の通信に関する態様を説明する。
【0028】
MIHF機能は、種々の目的のために互いに通信する。クライアントデバイス(モバイルノード)は、そのMIHサービスポイントとの間でMIH情報を交換する。いかなるネットワークエンティティにおけるMIHFでもMNベースのMIHFと直接通信するときにはMIH PoSになる。MIHネットワークエンティティは、MNとの直接接続を有しない可能性があり、したがってこの特定のMNのためのMIH PoSを構成しない。同じMIHネットワークエンティティが異なるMNのためのMIH PoSとして、なお動作する可能性がある。MIHF通信は、MIH可能MNのすべてのL2インターフェース上で起こり得るわけではない。一例として、3つのL2インターフェースすなわち802.11、802.16および802.3を有するMIH可能MN上で、802.3インターフェースはシステム管理および保守作業のためだけに使用され得るが、802.11および802.16インターフェースはMIHFサービスの提供に携わり得る。MNは、そのネットワークPoAと同じネットワークエンティティ内に常駐するMIH PoSとMIH情報を交換するためにL2トランスポートを使用し得る。MNは、そのネットワークPoAと同じネットワークエンティティ内に常駐しない可能性のあるMIH PoSとMIH情報を交換するためにL3トランスポートを使用し得る。このフレームワークは、MIHネットワークエンティティ間の通信のためにL2またはL3いずれかの機構の使用をサポートする。図3は、802.21規格のMIH通信モデルを示す。このモデルは、異なる独自の役割を有するMIHFとそれらの間の通信関係とを示す。図3に示された通信関係は、MIHFにだけ適用される。この通信モデルにおける通信関係の各々が特定のトランスポート機構を意味しないことは注目に値する。むしろ通信関係は、2つの独自MIHF間でMIHF関連情報交換が可能であることを示すように意図されているだけである。更には1)MN上のMIHF、2)MNのサービングPoAを含むネットワークエンティティ上のMIH PoS、3)MNのための候補PoA(候補PoAはMNがそれに気づいてはいるが現在それに所属していないPoAであって、この候補PoAはハンドオーバが最終的に起こった場合にターゲットPoAになる)を含むネットワークエンティティ上のMIH PoS、4)MNのためのPoAを含まないネットワークエンティティ上のMIH PoS、5)MNのためのPoAを含まないネットワークエンティティ上のMIH 非PoSである。
【0029】
この通信モデルはまた、MIHFの異なる事例間の下記の通信基準点を識別する。
【0030】
1)通信基準点R1:基準点R1は、MN上のMIHFとサービングPoAのネットワークエンティティ上のMIH PoSとの間のMIHF手順を指す。R1はL2、L3両者とそれ以上との上の通信インターフェースを包含し得る。R1上を通ったMIHF内容はMIIS、MIESまたはMICSに関連している可能性がある。
【0031】
2)通信基準点R2:基準点R2は、MN上のMIHFと候補PoAのネットワークエンティティ上のMIH PoSとの間のMIHF手順を指す。R2はL2、L3両者とそれ以上との上の通信インターフェースを包含し得る。R2上を通ったMIHF内容はMIIS、MIESまたはMICSに関連している可能性がある。
【0032】
3)通信基準点R3:基準点R3は、MN上のMIHFと非PoAネットワークエンティティ上のMIH PoSとの間のMIHF手順を指す。R3はL3とそれ以上と、またおそらくはイーサネット(登録商標)ブリッジ、MPLSなどのようなL2トランスポートプロトコルとの上の通信インターフェースを包含し得る。R3上を通ったMIHF内容はMIIS、MIESまたはMICSに関連している可能性がある。
【0033】
4)通信基準点R4:基準点R4は、ネットワークエンティティ内のMIH PoSともう1つのネットワークエンティティ内のMIH 非PoS事例との間のMIHF手順を指す。R4はL3とそれ以上との上の通信インターフェースを包含し得る。R4上を通ったMIHF内容はMIIS、MIESまたはMICSに関連している可能性がある。
【0034】
5)通信基準点R5:基準点R5は、異なるネットワークエンティティ内の2つのMIH PoS事例間のMIHF手順を指す。R5はL3とそれ以上との上の通信インターフェースを包含し得る。R5上を通ったMIHF内容はMIIS、MIESまたはMICSに関連している可能性がある。
【0035】
MIH通信モデルの説明図:
MIH通信基準点のより大きな説明図のために、MIHサービスを含むネットワークモデルが図4に示されている。右から左へ移って行くと、このモデルは、多数の有線および無線アクセス技術オプションをサポートするMIH可能モバイルノード(MN、一番右)を含む。このモデルは、プロビジョニングサービスプロバイダが多数のアクセス技術を運用している、あるいは相互作用をサポートするSLAが確立されているときにこのサービスプロバイダのユーザーが他のネットワークにローミングすることを可能にすることを想定している。MNは、特定のMIHクエリーを送信することを可能にするMIHFを実現している。MNはある程度内部的に実現された情報サービスを有し得る。
【0036】
このモデルは、ある緩やかな連続した仕方でコアネットワーク(オペレータ1―3コア)に接続されたアクセスネットワークを示す。また、よりタイトに相互接続または連結されたアクセスネットワーク(アクセスネットワーク・3)も描かれている。オペレータ1―3コアは各々、サービスプロバイダ、企業イントラネットプロバイダあるいはビジテッドアクセス(visited access)またはホームアクセスの単なる他の一部、あるいはコアネットワークを表す可能性がある。このモデルではサービス提供するプロバイダは、R1を介して1つのコア(ビジテッド/ホームコア・ネットワークとラベル付けされた)に連結されたアクセスネットワーク・3を運用している。用語ビジテッド(Visited)およびホーム(Home)はサービス提供するサービスプロバイダまたは企業を示すために使用される。図示のネットワークのいかなるものも、MNのサービス提供業者とのオペレータの関係に依存してビジテッドまたはホームネットワークの両方になり得る。ネットワークプロバイダは、自身のネットワークへのハンドオーバを容易にするために自身のアクセスネットワーク(アクセスネットワーク・1―4)においてMIHサービスを提供する。各アクセス技術は、そのMIH能力を宣伝するか、あるいはMIHサービス発見に応答する。アクセスネットワークに関する各サービスプロバイダは、1つ以上のMIHサービスポイント(PoS、通信モデルと比較すること)へのアクセスを可能にする。これらのPoSは、MIH能力発見時に決定されたMIHサービスの一部または全部を提供し得る。MIH PoSの位置またはノードは、規格によって固定されない。PoS位置は、オペレータの配置シナリオと技術固有MIHアーキテクチャとに基づいて変化し得る。
【0037】
MIH PoSは、アクセスネットワーク(アクセスネットワーク1、2、4が典型的である)内の所属ポイント(point of attachment)(PoA)の隣に常駐し得るか、あるいはPoAと同一場所配置(co-located)され得る。代替としてPoSは、アクセスまたはコアネットワーク(アクセスネットワーク3が典型的である)の内部深く常駐し得る。図3に示されたようにMN内のMIHエンティティは、任意のアクセスネットワーク上のR1、R2またはR3のいずれかによってMIHネットワークエンティティと通信する。サービングアクセスネットワーク内のPoAが同一場所配置されたMIH機能を有すると、R1基準接続はPoSでもあるPoAで終了する(このモデルのアクセスネットワーク1、2、4へのMNはすべてR1であり得る)。この場合、R3基準接続は、任意の非PoA(アクセスネットワーク1、2、4へのMNによって示された)で終端されるであろう。MIHイベントはアクティブなR1リンクの両側から発生し得る。MNは典型的にはこれらのイベントに反応する第1のノードである。
【0038】
ビジテッドネットワークとホームネットワークとの相互作用は、制御および管理目的またはデータトランスポート目的のいずれかのためであり得る。ローミング契約またはSLA契約によって、MNがビジテッドネットワークを介して公衆のインターネットに直接アクセスすることをホームネットワークが可能にし得ることも可能である。図示のように2つのMIHネットワークエンティティは、R4またはR5基準接続を介して互いに通信し得る。MIH可能PoAはまた、R3およびR4基準点を介して他のMIHネットワークエンティティと通信できる。MIH可能MNは、候補ネットワークについての情報サービスを取得するためにR2基準点を介しての候補アクセスネットワーク内の他のPoAとのMIH通信を有し得るであろう。
【0039】
MIH情報サービス(MIIS)に関してプロバイダは、MIH PoSノード(上部左端)に位置する自身の情報サーバへのアクセスを提供する。オペレータは、新しいローミングリスト、コスト、プロバイダ識別情報、プロバイダサービス、優先順位、およびサービスを選択して利用することを可能にする他の任意の情報を含むが、これらに限定されない関連情報を取得できるように、モバイルノードにMIISを提供する。図示のようにモバイルノードがプロバイダによってMIISデータを事前提供されることは可能である。
【0040】
またモバイルノードが、情報サービスのプロバイダの任意のアクセスネットワークからMIH情報サービスを取得することも可能である。MIISはまた、このネットワークのMIISサービスポイントを使用してもう1つのオーバーラップしているネットワーク、または近隣のネットワークから利用可能であり得る。サービス提供業者のネットワーク(ここではアクセスネットワーク3と連結されているように描かれている)は、サービス提供業者の、あるいはビジテッドネットワークのMIH情報サーバのような他のMIHエンティティにアクセスするためにR3およびR4インターフェースを利用し得る。
【0041】
MIHコマンドサービス(MICS)に関して情報データベースのいかなるものも、コマンドサービスPoSとして使用され得る。MN MIHFは典型的には、レイヤー3トランスポートを使用してこのサーバと通信する。
【0042】
MIHFサービス:
MIHFは、リンク層およびMIHユーザーのために明確なSAPを介して非同期および同期サービスを提供する。任意の型の多数のネットワークインターフェースを有するシステムの場合に上位層は、基礎に在るインターフェースの状態を管理、決定および制御するためにMIHによって提供されるイベントサービス、コマンドサービスおよび情報サービスを使用し得る。
【0043】
MIHによって提供されるこれらのサービスは、サービスの連続性の維持と、変化するサービス品質へのサービス適応と、バッテリ寿命保全と、ネットワーク発見およびリンク選択と、において上位層を援助する。802型およびセルラー3GPP、3GPP2型の異種ネットワークインターフェースを含むシステムでは、メディア独立ハンドオーバ機能は、異種ネットワークインターフェースに亘ってサービスを連結するために上位層が効率的な手順を実現するのを助け得る。上位層は、異種ネットワーク間のハンドオーバ動作のために必要とされるリソースの問合せ(クエリー)を行うために異なるエンティティに亘ってMIHFによって提供されるサービスを利用し得る。
【0044】
モバイルデバイスにおけるMIHサービスは、異種ネットワーク間でのシームレスハンドオーバを容易にする。モビリティ管理プロトコル(例示的モバイルIP)といったMIHユーザーは、ハンドオーバおよびシームレスセッション連続性のためにサポートされ得る。これは、ハンドオーバを最適化するためにMIHサービスを利用することから、モバイルIPおよび他の上位層に加えて他のプロトコルを除外しないであろう。
【0045】
MIHサービスを使用するモバイルノードは、イベントサービスのような非同期動作のためにリンク層からの指示を受信するであろう。コマンドサービスおよび情報サービスとの相互作用は、機構の同期クエリーおよび応答型を介して行われるであろう。MIHFはまた、同じメディア型のネットワークエンティティとホストエンティティとの間の情報交換のための機能を提供するであろう。もしこのような情報交換のための機構が所定のメディア型をもって(例えばある幾つかのセルラーメディア型をもって)既に存在するならば、MIHFはいつでも可能なときに既存の機構を利用するであろうことに留意されたい。
【0046】
MIHプロトコル:
IEEE802.21規格は、メディア独立イベントサービス、メディア独立コマンドサービスおよびメディア独立情報サービスをサポートする。MIHプロトコルは、リモートMIHFエンティティとメッセージの送達をサポートするトランスポート機構との間で交換されるメッセージのフォーマット(すなわち、ヘッダとペイロードとを有するMIHFパケット)を定義する。トランスポート機構の選択は、MNをネットワークとMIH PoSの位置とに接続するアクセス技術に依存する。
【0047】
これらのサービスのためのパケットペイロードは、L2管理フレーム、L2データフレームまたは他の上位層プロトコル上で搬送され得る。802.11および802.16といった無線ネットワークは、管理プレーンを有しており、上記のペイロードを搬送するために適当に改善され得る管理フレームをサポートする。しかしながら有線イーサネットネットワークは管理プレーンを有さず、またデータフレームだけで上記ペイロードを搬送し得る。
【0048】
IEEE802.21規格は、標準TLVフォーマットにおいてメディア独立方式でパケットフォーマットおよびペイロードを定義する。この後にこれらのパケットは、ペイロードがイーサネットの場合のように正常なデータフレーム上で送られる必要があるときにMIHFイーサ型を使用してL2MIHプロトコル内にカプセル化され得る。他の場合にはTLVベースのメッセージおよびペイロードは、メディア固有管理フレームに直接カプセル化され得る。代替としてMIHプロトコルメッセージは、下位層(L2)または上位層(L3以上)トランスポートを使用してカプセル化され得る。
【0049】
IEEE802.21規格は、MIHプロトコルデータユニット(PDU)ヘッダおよびペイロードのフォーマットを定義する。標準TLVフォーマットは、PDUペイロード内容のためにメディア独立表現を提供する。MIHF PDUは、802リンク上でMIHFイーサ型を有するデータフレーム内にカプセル化される。802.11および802.16リンクに関して、MIHメッセージを搬送するためにメディア固有管理フレームの拡張が推奨される。この規格ではL2における3GPPおよび3GPP2アクセスリンク上でのMIHメッセージのトランスポートに関して、何らの仮定も行われていない。
【0050】
メディア独立情報サービス:
序論:
メディア独立情報サービス(MIIS)は、モバイルノードおよびネットワーク両者におけるMIHFがハンドオーバを容易にするためにある地理的領域内のネットワーク情報を発見して取得し得るフレームワークを提供する。その目的は、これらのネットワークに亘ってローミングするときにシームレスハンドオーバを容易にするためにこの領域内のMNに関連するすべての異種ネットワークのグローバルなビューを取得することである。
【0051】
メディア独立情報サービスは、種々の情報要素(IE)のサポートを含む。情報要素は、ネットワークセレクタが知的ハンドオーバ意思決定を行うために本質的である情報を提供する。
【0052】
ハンドオーバを実行するためには、モビリティの型に依存して種々の型の情報要素のサポートが必要となり得る。例えば同じアクセスネットワークの異なるPoAに亘る水平ハンドオーバの場合には、アクセスネットワークの下位リンク層からの利用可能な情報で十分である可能性がある。このような場合、イントラテクノロジ近隣レポートのような情報要素およびハンドオーバ時に必要とされる他のリンク層情報は、アクセスネットワークから直接利用可能である。このような場合、ネットワークによって提供される上位層サービスの利用可能性は、異なるネットワーク所属ポイントに亘って目立つほどには変化しない可能性がある。
【0053】
他方、垂直ハンドオーバ時には、アクティブなユーザープリケーションに関してサービスおよびセッションの連続性を可能にするために最適なリンク層接続性ならびに適切な上位層サービスの利用可能性の両者に基づいて新しいネットワーク内で適当なPoAを選択する必要がある。
【0054】
メディア独立情報サービス(MIIS)は、ハンドオーバのために必要な情報を取得するための能力を提供する。これは、近隣マップおよび他のリンク層パラメーターといった下位層に関する情報ならびにインターネット接続性、VPNサービスの利用可能性などといった利用可能な上位層サービスに関する情報を含む。MIISによって提供される異なる上位層サービスのセットは、絶え間なく進化することができる。同時に、MIISによってサポートされるアクセスネットワークのリストも進化し得る。そのようなものとして、MIISが異なる情報要素のサポートを提供する仕方には、柔軟性および拡張可能性の必要性が存在する。この目的のためにMIISは、あるスキーマを定義する。このスキーマは、MIISのクライアントがMIISの能力を発見し、また特定の実現形態によってサポートされる異なるアクセスネットワークとIEとのセット全体を発見するのを助ける。スキーマ表現はまた、モバイルノードがより柔軟で効率的な仕方で情報を問い合わせることを可能にする。このスキーマを定義することの一部としてMIISはまた、MIISの異なる実現形態のコア機能を定義し得る1セットの基本的情報要素を識別し得る。他の情報要素は、それらが追加されると、MIIS能力の拡張されたセットの一部になり得る。
【0055】
MIISは、802ネットワーク、3GPPネットワークおよび3GPP2ネットワークといった異なるアクセスネットワークに関する情報を提供する。MIISはまた、この収集された情報がいかなる単一のネットワークからでもアクセスされることを可能にする。
【0056】
したがって例えば802.11アクセスネットワークを使用して、特定の地域内の他のすべての802ネットワークに関する情報ばかりでなく3GPPおよび3GPP2ネットワークの情報も取得することが可能であり得る。同様に3GPP2インターフェースを使用して、所定の地域内のすべての802および3GPPネットワークに関する情報を利用することが可能であり得る。この能力は、モバイルノードがその現在アクティブなアクセスネットワークを使用し、またある地理的地域内の他の利用可能なアクセスネットワークに関してスキャンすることを可能にする。このようにしてモバイルノードは、それの個別の無線通信の各々に電力供給し、そして異種ネットワーク情報にアクセスするという目的のためにネットワーク接続性を確立するという負担から解放される。MIISは、いかなる地理的領域においても異種ネットワーク情報を検索するための均一な仕方を提供することによって、すべての利用可能なアクセスネットワークに亘ってこの機能を使用可能にする。
【0057】
情報サービス要素:
情報サービスの背後にある主要目標は、モバイルノードとネットワークエンティティとがハンドオーバ時の適当なネットワークの選択に影響を及ぼし得る情報を発見することを可能にすることである。この情報は、この情報に基づいて効果的なハンドオーバ意思決定を行い得る方策エンジンエンティティによって主に使用されるように意図されている。この情報サービスは、ネットワーク構成の変更が明らかにされなくてはならないにもかかわらず、大抵の静止型の情報を提供するように期待されている。現在利用可能なリソースレベル、状態パラメーター、動態統計などといった異なるアクセスネットワークに関する他の動的情報は、それぞれのアクセスネットワークから直接取得されるべきである。この情報サービスの背後にある主要な動機の幾つかは次の通りである:
1)ある地理的領域におけるアクセスネットワークの利用可能性に関する情報を提供する。更にこの情報は、任意の無線ネットワークを使用して検索され得るであろう、例えば近隣のWiFiホットスポットに関する情報は、要求/応答シグナリングによるか、あるいはこれらのセルラーネットワーク上で明確にまたは暗示的にブロードキャストされる情報によるかによって、GSM、CDMA、または他の何らかのセルラーネットワークを使用して取得され得るであろう。代替としてこの情報は、MNによって内部データベースに維持され得るであろう。
【0058】
2)適当なアクセスネットワークを選択する際にモバイルデバイスを援助し得る静的リンク層情報パラメーターを提供する。例えば、セキュリティおよびQoSがある特定のアクセスネットワーク上でサポートされているかどうかの知識は、ハンドオーバ時にこのようなアクセスネットワークを選択するための意思決定に影響を与え得る。
【0059】
3)近隣レポートからなるリンク層情報および異なるPoAの能力に関する情報もまた、利用可能な/選択されたアクセスネットワークに接続するために無線通信を最適に構成する際に助けとなり得るであろう。例えば異なるPoAによってサポートされたチャネルに関する知識は、スキャン、ビーコンなどとは対照的に最適にチャネルを構成する際に、またこの情報を発見する際に助けとなり得る。しかしながらほとんどの部分に関して、アクセスネットワークとの直接的相互作用に基づいて動的リンク層パラメーターが取得または選択されなければならず、またこれに関してこの情報サービスはあまり助けとなり得ない可能性がある。
【0060】
4)異なるアクセスネットワークによってサポートされる上位層サービスの指示とハンドオーバ意思決定時に助けとなり得る他の関連情報とを提供する。このような情報は、特定のアクセスネットワークのMAC/PHY層から直接利用可能でない可能性がある(あるいは利用可能にされ得ない)が、情報サービスの一部として提供され得るであろう。例えばある幾つかの場合には、公共、企業、家庭、その他などといったカテゴリへの異なるネットワークの分類は、ハンドオーバ意思決定に影響を与え得る。ここでの他の情報は事実上、より販売業者/ネットワーク固有である可能性があり、またこの形式で指定され得るであろう。
【0061】
情報サービス要素は、3つのグループに分類される:
1)一般的アクセスネットワーク情報:これらの情報要素は、利用可能なネットワークおよびそれらの関連オペレータのリストといったある領域内のカバレッジを与える異なるネットワークと、異なるオペレータ間のローミング契約と、ネットワークへの接続のコストと、ネットワークセキュリティおよびサービス品質の能力と、の一般的概要を与える。
【0062】
2)所属ポイントに関する情報:これらの情報要素は、利用可能なアクセスネットワークの各々のための異なるPoAに関する情報を提供する。これらのIEは、PoAアドレス指定情報、PoA位置、サポートされるデータ転送速度、PHYおよびMAC層の型、およびリンク層接続性を最適化するための任意のチャネルパラメーターを含む。これはまた、上位層サービスと異なるPoAの個別能力とを含む。
【0063】
3)他の情報は、販売業者/ネットワーク固有である可能性があり、また適切に指定され得る。
【0064】
メディア独立ハンドオーバプロトコル:
序論:
MIHは、下位層および上位層に関して明確なSAPを介して非同期および同期サービスを提供する。提供されるサービスは、イベントサービス(ES)、コマンドサービス(CS)および情報サービス(IS)を含む。MIHサービスに関する詳細説明は、802.21ドラフト文書に見出される。MIH SAPは、種々のMIHFサービスへのアクセスを取得するためにMIHのユーザーによって使用されるMIH上位層SAPと、種々のメディア依存下位層リソースのアクセスと制御とを取得するためにMIHFによって使用されるMIH下位層SAPとを含む。
【0065】
MIHプロトコルは、ピアMIHFエンティティ間でメッセージを交換するためのフレームフォーマットを定義する。これらのメッセージは、メディア独立イベントサービス、メディア独立コマンドサービスおよびメディア独立情報サービスの一部であるプリミティブに基づいている。IEEE802.21は、モバイルノードおよびネットワークにおけるメディア独立ハンドオーバ機能をサポートする。MIHプロトコルは、ピアMIHFエンティティが互いに相互作用することを可能にする。
【0066】
モバイルノードのMIHFエンティティがMIHプロトコル手順を開始するためにモバイルノードのMIHFエンティティは、それのピアリモートMIHFエンティティを発見できる。ピアリモートMIHFエンティティは、モバイルノードのMIHFがMIHプロトコルメッセージを交換する対応するMIHFエンティティである。ピアリモートMIHFエンティティはネットワークのどこかに常駐しているので、モバイルノードのMIHFエンティティはMIHプロトコル手順を開始する前にネットワーク内のMIHFエンティティを発見できる。これは、MIH機能発見手順を介して行われる。
【0067】
MIH機能発見は、レイヤー2またはレイヤー3のいずれかにおいて行われ得る。しかしながらこの文書は、両方のMIH機能が同じブロードキャストドメイン内に位置しているときにMIHF機能発見がどのようにしてレイヤー2において実行されるかを指定しているだけである。MIH機能発見は、MIHプロトコルを介して(すなわちLLCといったL2カプセル化を使用して)またはメディア固有レイヤー2ブロードキャストメッセージ(すなわち802.11ビーコン、802.16DCD)を介して実行され得る。レイヤー3におけるMIH機能発見は、802.21の範囲外である。
【0068】
ひとたびピアMIHFが発見されるとMNは、ピアMIHFの能力を発見できる。これは、MIH能力発見手順を介して行われる。MIH能力発見は、MIHプロトコルを介して、またはメディア固有レイヤー2ブロードキャストメッセージ(すなわち802.11ビーコン、802.16DCD)を介して実行され得る。
【0069】
ピアMIHFがMNと同じブロードキャストドメイン内に常駐しているとき、MIH機能発見はMIH能力発見だけを使用して実行され得る。
【0070】
例示的アーキテクチャ:
図1は、クライアントデバイスが通信する無線アクセスポイントを含むある幾つかの例示的かつ非限定的な実装に使用され得る、ある幾つかの例示的アーキテクチャ構成要素を示す。これに関して図1は、一般に21で示された無線ローカルエリアネットワーク(WLAN)に接続された例示的有線ネットワーク20を示す。WLAN21は、アクセスポイント(AP)22と多数のユーザー局23、24とを含む。例えば有線ネットワーク20は、インターネットまたは企業内データ処理ネットワークを含み得る。例えばアクセスポイント22は無線ルータであることが可能であり、ユーザー局23、24は例えば携帯型コンピュータ、卓上型パソコン、PDA、VoIP携帯電話および/または他のデバイスであり得る。アクセスポイント22は、有線ネットワーク21にリンクされたネットワークインターフェース25と、ユーザー局23、24と通信する無線トランシーバと、を有する。例えば無線トランシーバ26は、ユーザー局23、25との通信のための無線周波数用またはマイクロ波周波数用のアンテナ27を含み得る。アクセスポイント22はまた、プロセッサ28とプログラムメモリ29とランダムアクセスメモリ31とを有する。ユーザー局23は、アクセスポイント局22との通信のためのアンテナ36を含む無線トランシーバ35を有する。同様にユーザー局24は、アクセスポイント22との通信のための無線トランシーバ38とアンテナ39とを有する。例としてある幾つかの実施形態では、このようなアクセスポイント(AP)内ではオーセンティケータが使用され得る、および/またはモバイルノードあるいはユーザー局内ではサプリカントまたはピアが使用され得るであろう。
【0071】
図2は、ある幾つかの実施形態において例えばアクセスポイント、ユーザー局、送信元ノードまたは宛て先ノードといったデバイスによって実行されるコンピュータ化されたプロセスステップを実行するために使用され得る、例示的コンピュータまたは制御ユニットを示す。ある幾つかの実施形態ではコンピュータあるいは制御ユニットは、バス326上で1セットの入力/出力(I/O)デバイス324と通信し得る中央演算処理装置(CPU)322を含む。I/Oデバイス324は、例えばキーボード、モニターおよび/または他のデバイスを含み得る。CPU322は、バス326上でコンピュータ可読媒体(例えば従来の揮発性または不揮発性データ記憶デバイス)328(以下、「メモリ328」)と通信できる。CPU322、I/Oデバイス324、バス326およびメモリ328間の相互作用は、当技術において周知のものと同様である。メモリ328は、例えばデータ330を含み得る。メモリ328は、ソフトウェア338も記憶できる。ソフトウェア338は、プロセスのステップを実行するための多数のモジュール340を含み得る。これらのモジュールを実現するために従来のプログラミング技法が使用され得る。メモリ328はまた、上記および/または他のデータファイルを記憶し得る。ある幾つかの実施形態ではここで説明された種々の方法は、コンピュータシステムによる使用のためにコンピュータプログラム製品を介して実現され得る。この実現形態は、例えばコンピュータ可読媒体(例えばディスケット、CD−ROM、ROMなど)に記憶された、あるいはモデムなどといったインターフェースデバイスを介してコンピュータシステムに伝送可能な一連のコンピュータ命令を含み得る。通信媒体は、実質的に有形(例えば通信ライン)および/または実質的に無形(例えばマイクロ波、光、赤外線などを使用する無線媒体)であり得る。コンピュータ命令は、種々のプログラミング言語で書かれ得る、および/または半導体デバイス(例えばチップまたは回路)、磁気デバイス、光デバイスおよび/または他のメモリデバイスといったメモリデバイスに記憶され得る。種々の実施形態において伝送手段は、適当ないかなる通信技術でも使用できる。
【0072】
一般的な背景文献:
以下の一般的な背景出願を参照する(そのような出願はさらにここで参照することによって背景参照に関する全ての以下の特許出願の全開示を組み込む)。
【0073】
1)K. Taniuchiらの2007年2月23日提出の米国仮出願第60/891,349号;
2)Y. A. Chengらの2006年9月13日提出の米国仮出願第60/825,567号;
3)Y. Obaらの2006年12月5日提出の米国出願第11/567,134号;
4)Y. Obaらの2006年11月23日提出の米国出願第11/563,000号;
5)Y. Obaらの2006年11月12日提出の米国出願第11/558,922号;
6)Y. Obaらの2006年7月27日提出の米国出願第11/460,616号;
7)A. Duttaらのメディア独立事前認証の改善フレームワークと題された2006年4月14日提出の米国出願第11/279,856号;
8)スイッチングの失敗とスイッチバックに関する考慮(Considerations For Failed Switching And Switchback)を含んでいること;
9)Y. ObaらのPANAに関するメディア独立事前認証サポートのフレームワークと題された2006年3月9日提出の米国出願第11/308,175号;
10)A. Duttaらのメディア独立事前認証のフレームワークと題された2006年2月提出の米国出願第11/307,362号;
11)Y. Oba, et al.らの2008年5月12日提出の米国出願第12/119,048号;
上記のとおり、ハンドオーバのためのメディア独立のソリューションは、異種ネットワーク間のセキュリティシグナリング要件の問題に対処していない。異種メディアをサポートするネットワーク間にアタッチするモバイルノード(MN)がハンドオーバを安全に行うために、モバイルノードと候補ネットワーク(ターゲットネットワーク)との間の認証(authentication)、許可(authorization)、および秘密性(confidentiality)が必要とされる。しかしながら、セキュリティ関連のシグナリングの追加は、ハンドオーバ動作の際の大幅な遅延をもたらす可能性がある。これは、インターネットや他のパケット交換方式のネットワークのようなIPネットワークによる音声情報配信のためのVoice over Internet Protocol (VoIP)といった時間的制約のあるアプリケーションに影響を及ぼし得る。その多くの場合、サービス品質(QoS)への影響からサービスの継続性はもはや満たされず、最終的にはユーザエクスペリエンスに多大な影響を及ぼす。
【発明の概要】
【0074】
ある例示的実施形態において、メディア独立ハンドオーバプロトコルへのセキュリティ関連のシグナリングの追加に起因するサービス品質およびユーザエクスペリエンスへの悪影響の問題は、プロアクティブ認証技術およびMIHプロトコル・レベル・セキュリティ機構によって、特にハンドオーバ中のセキュリティ関連シグナリングを最適化することにより解決される。
【0075】
この出願の一態様において、システムは、メディアに固有のリンクの終端にインターフェースを介してアタッチされた他のエンティティを認証するメディア独立認証機能を含むメディア独立アクセス機能を有しているサーバを含む。複数の異機種ネットワークの各々は、前記メディアに固有の前記リンクの前記終端に前記インターフェースを介してアタッチされた他のエンティティに対応する認証機能メディア固有アクセス機能を含んでおり、モバイルデバイスは、前記複数の異種ネットワークに接続され、前記サーバは、ハンドオーバに関するメディア独立機能に基づく所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーを有し、前記サーバは、サービングアクセスネットワークから、候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークを認証し、前記候補アクセスネットワークの各々は、前記メディアに固有の前記リンクを有する前記複数の異種アクセスネットワークに属する。
【0076】
この出願の別の態様において、製品は、プロセッサが、異種メディア間でアタッチされたモバイルデバイスをメディア独立オーセンティケータによってプロアクティブに認証する動作を実行可能にするための命令がコード化されたマシンアクセス可能な媒体を具備し、複数の異種アクセスネットワーク内のサービングアクセスネットワークにアタッチされたモバイルデバイスにメディア固有認証手続きを割り当てること;前記メディア独立オーセンティケータを介して候補アクセスネットワークに関する情報をハンドオーバ準備段階でモバイルデバイスに提供すること;インターフェースを用いて、プロアクティブ認証を行なうこと;前記メディア独立オーセンティケータを介して前記プロアクティブ認証が正常に行なわれると、前記メディア固有認証手続きを有する候補アクセスネットワークへのハンドオーバを実行すること、を具備する。
【0077】
この出願のさらに別の態様において、メディア独立アクセス機能を実装したコンピュータを有する装置は、異種メディア間でアタッチされたモバイルデバイスを認証する独立オーセンティケータと;各々が固有のサービングメディアに対応する固有のオーセンティケータをサポートする複数の異種アクセスネットワークに前記独立オーセンティケータを接続するインターフェースと;前記コンピュータの前記メディア独立機能に基づいた所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーとを具備し、前記独立オーセンティケータは、サービングアクセスネットワークから、固有のサービングメディアを持つ複数の異種アクセスネットワークに属する候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークを認証する。
【0078】
種々の実施形態の上記および/または他の態様、特徴および/または利点は、添付の図に関連して下記の説明を考慮することによって更に理解されるであろう。種々の実施形態は、適用可能の場合に、異なる態様、特徴および/または利点を含み得る、および/または除外し得る。更に種々の実施形態は、適用可能の場合に他の実施形態の1つ以上の態様または特徴を組み合わせることができる。特定の実施形態の態様、特徴および/または利点の説明は、他の実施形態または特許請求の範囲を限定するものと解釈されるべきではない。
【図面の簡単な説明】
【0079】
本発明の実施形態の上記および他の特徴および利点は、以下の添付の図面に関しての典型的な実施形態について詳細に記述することによってより明白になるだろう:
図1図1は、クライアント装置が通信する無線アクセスポイントを含むいくつかの実例となり制限しない実装で使用することができるいくつかの実例となるアーキテクチャ上のコンポーネントを示す;
図2図2は、装置(例えば、いくつかの実施形態でのソースノード、デスティネーションノード、アクセスポイント、あるいはユーザー局)によって実行されるために、コンピュータ化されたプロセスステップを実装するために用いることができる実例となるコンピュータまたは制御ユニットを示す;
図3図3は、認証関連セキュリティシグナリングがいくつかの実施形態で実現されうるI.E.E.E802.21の規格で開示されるような実例となるメディア独立ハンドオーバ機能通信モデルである;
図4図4は、認証関連セキュリティシグナリングがいくつかの実施形態で実現されうるメディア独立ハンドオーバサービス通信モデルを持ったネットワークモデルの例である;
図5図5は、ダイレクトプロアクティブ認証シグナリングの間に、異なる機能エンティティとそれらの関与との間の関係を示す;
図6図6は、非ダイレクトプロアクティブ認証シグナリングの間に、異なる機能エンティティとそれらの関与との間の関係を示す;
図7図7は、2つのアクセスネットワークが1つのメディア独立したオーセンティケータおよびキーホルダーによって管理される場合、プロアクティブ認証用の実例となる論理的なアーキテクチャを示す;
図8図8は、2つのアクセスネットワークが2つの個別のメディア独立オーセンティケータおよびキーホルダーによって管理される場合、プロアクティブ認証用の実例となる論理的なアーキテクチャを示す;
図9図9は、MNと、ネットワーク主導のダイレクトプロアクティブ認証(EAP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間での複数のメッセージフローを示す;
図10図10は、MNと、モバイル主導のダイレクトプロアクティブ認証(EAP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図11図11は、MNと、ネットワーク主導の非ダイレクトプロアクティブ認証(EAP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図12図12は、MNと、モバイル主導の非ダイレクトプロアクティブ認証(EAP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図13図13は、MNと、ネットワーク主導のダイレクトプロアクティブ認証(ERP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図14図14は、MNと、モバイル主導のダイレクトプロアクティブ認証(ERP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図15図15は、MNと、ネットワーク主導の非ダイレクトプロアクティブ認証(ERP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図16図16は、MNと、モバイル主導の非ダイレクトプロアクティブ認証(ERP)に関するメディア独立したオーセンティケータ(Media independent authenticator)との間でのメッセージフローを示す;
図17図17は、MNと、ターゲットMSA−KHと、ターゲットMIA−KHとの間でのコールフローを示す;
図18図18は、ネットワーク主導およびモバイル主導両方のダイレクト終了手続に関するコールフローを示す;
図19図19は、ネットワーク主導およびモバイル主導両方の非ダイレクト終了手続に関するコールフローを示す。
【発明を実施するための形態】
【0080】
本発明は多くの異なる形で具現され得るが、本開示が本発明の原理の例を提供するものと考えられるべきであることと、このような例が本発明を本明細書に説明された、および/または本明細書に図解された好適な実施形態に限定するようには意図されていないということとの理解の下で、多数の例示的実施形態が本明細書において説明される。
【0081】
用語(Terminologies):
EAP:Extensible Authentication Protocol 拡張認証プロトコル
ERP:EAP Re-Authentication Protocol EAP再認証プロトコル
SA:Serving Authenticator サービングオーセンティケータ
CA:Candidate Authenticator 候補オーセンティケータ
定義(Definitions):
認証プロセス(Authentication Process):暗号処理および認証を行うデータフレームのサポート。
【0082】
メディア固有オーセンティケータおよび鍵ホルダ(Media Specific Authenticator and Key Holder)(MSA−KH):メディア固有オーセンティケータおよび鍵ホルダは、メディアに特有のリンクの他端にアタッチされた他のエンティティの認証を促進するエンティティである。
【0083】
メディア独立オーセンティケータおよび鍵ホルダ(Media Independent Authenticator and Key Holder)(MIA−KH):メディア独立したオーセンティケータおよび鍵ホルダは、MSA−KHと相互作用し、かつMSA−KHのリンクの他端にアタッチされた他のエンティティのプロアクティブ認証を促進するエンティティである。
【0084】
プロアクティブ認証(Proactive Authentication):MSA−KHのリンクの他端にアタッチされる他の複数のエンティティと、MIA−KHとの間で行なわれる認証プロセス。他の複数のエンティティが別のリンクへのハンドオーバを行なおうとする場合、このプロセスが発生する。
【0085】
サービングMIA−KH(Serving MIA-KH):アクセスネットワークにアタッチされるモバイルノードに現在サービスしているMIA_KH。
【0086】
候補MIA−KH(Candidate MIA-KH):モバイルノードの、潜在的な複数の候補アクセスネットワークのリストに載っているアクセスネットワークにサービスするMIA−KH。
【0087】
MIHセキュリティアソシエーション(MIH Security Association)(SA):MIH SAは複数のピアMIHエンティティ間でのセキュリティアソシエーションである。
【0088】
参考文献(References)
次の参考文献のそれぞれ全ては、背景参照に関するそれらの全体におけるこの開示において参照によってここに組み込まれる:
[RFC4748]H. Levkowetz, Ed. and et al, Extensible Authentication Protocol (EAP), RFC 3748;
[RFC5296]V. Narayan and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)" RFC 5296;
[RFC4306]C. Kaufman, Ed, "Internet Key Exchange (IKEv2) Protocol:", RFC 4306;
[RFC5246]T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246;
[RFC4347]E. Rescorla and N. Modadugu, "Datagram Transport Layer Security", RFC 4347;
[RFC5295]J. Saloway, et al, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)" RFC 5295;および
[IEEE802.21]IEEE P802.21 Std-2008, IEEE Standard for Local and Metropolitan Area Networks- Part 21: Media Independent Handover Services.
プロアクティブ認証(Proactive Authentication)
プロアクティブ認証は、メディア独立のオーセンティケータおよび候補ネットワークをサービスしている鍵ホルダ(MIA−KH)により、アプリオリなネットワークアクセス認証をエンティティが行なうことができるプロセスである。エンティティは近隣のネットワークへのハンドオーバを予期してそのような認証を行なう。プロアクティブ認証は2つの方法で行なうことができる:i)認証シグナリングがサービングMIA−KHにトランスペアレントであるダイレクトプロアクティブ認証(図5)と、ii)サービングMIA−KHが認証シグナリングを承知している非ダイレクトプロアクティブ認証(図6)。それぞれの場合において、EAP(Extensible Authentication Protocol、拡張認証プロトコル)[RFC4798]あるいはERP(EAP Re-Authentication Protocol、EAP再認証プロトコル)[RFC5296]のいずれかを、認証プロトコルとして用いることができる。
【0089】
図5および図6は、プロアクティブ認証シグナリング中に異なる機能エンティティの間の関係と、プロアクティブ認証シグナリング中のそれらの関与とを示す。ダイレクトプロアクティブ認証については、モバイルノードは、候補MIA−KHと直接通信する(図5)。また、非ダイレクトプロアクティブ認証については、モバイルノードは最初にサービングMIA−KHと通信する。その後、サービングMIA−KHはモバイルノードの代わりに、候補MIA_KHと通信する。
【0090】
プロアクティブ認証アーキテクチャ(Proactive Authentication Architecture)
図7および図8での典型的な実施形態は、プロアクティブ認証用の2つの例の論理的なアーキテクチャを描いている。メディア独立したオーセンティケータおよび鍵ホルダ(MIA−KH、Media Independent Authenticator and Key Holder)は、複数の候補ネットワークへのハンドオーバに先立って、認証を円滑にするエンティティである。このアーキテクチャでは、複数の認証機能はメディア独立ハンドオーバ機能(MIHF、Media Independent Handover Function)内に加えられる。また、新しいエンティティは向上されたPOS(例えばPoS+)として呼ばれる。
【0091】
メディア固有オーセンティケータおよび鍵ホルダ(MSA−KH、Media Specific Authenticator and key holder)は、特定のアクセスネットワークへのアクセス用の認証装置に関与している。また、提案されたアーキテクチャは、そのような既存の機構を変更しないと仮定する。図7図8との間の差は、図7では、2つのアクセスネットワークが1つのMIA−KHによって管理され、したがって1つのPoSが存在するが、一方図8では、それぞれのアクセスネットワークがそれら自身のMIA−KHを有していてしたがって2つの別個のPoSが必要である。図8にはさらにMIH通信モデルについてRP5と呼ばれる1つの追加のインターフェースがある[IEEE Std 802.21.2008]。
【0092】
この開示は、ネットワーク主導およびモバイル主導の手続を含む、ダイレクトおよび非ダイレクトのプロアクティブ認証の両方をサポートする。動作のシーケンスは次のものを含んでいる:
−MNはアクセス固有認証手続でアクセスネットワークにアタッチする;
−ハンドオーバ準備段階の間に、MNは候補オーセンティケータを発見する;
−メディア独立したオーセンティケータの到達可能性に依存して、MNは、RPlインターフェースを用いて、ダイレクトまたは非ダイレクトのいずれかのプロアクティブ認証を行なう;
−一旦メディア独立した認証が成功して行なわれれば、複数のメディア固有鍵はMSA−KHへプッシュされるか、あるいはMSA−KHからプルされる。Interface_MIA−KH−MSA−KHはこの動作を行なうために用いられる;
−MNは、メディア固有セキュアアソシエーション(例えば802.11に関する4方向のハンドシェイク)を行なうことにより、ハンドオーバを実行し、さらにターゲットとして知られている候補ネットワークのうちの1つへアタッチする;そして
−接続確立の後、MNはPoSで再登録する。
【0093】
次の仮定は、このセクションの残りにわたってなされる:
仮定(Assumptions)
−オーセンティケータはMIH PoSである;
−MIHプロトコルはEAPとERPを運ぶために用いられる;
−MNのMIHF−IDはMNのメディア独立アイデンティティーとして用いられる;
−オーセンティケータのMIHF−IDはオーセンティケータのメディア独立アイデンティティーとして用いられる;
−メディア独立したオーセンティケータ(Media Independent Authenticator)は、EAPによって生成されたrMSK(再認証MSK)あるいはMSK(Master Session Key)(マスターセッション鍵)を保持する;
−MSKまたはrMSKはメディア独立した対のマスター鍵(MI−PMK)を導き出すために用いられる;および
−MNがターゲットMSA−KHにハンドオーバし、かつそれがターゲットMSA−KHに関するMI−PMKから導き出されたメディア固有PMK(MS−PMK)を有する場合、それはMS−PMKを用いて、メディア固有のセキュアアソシエーションを実施する。
【0094】
EAPを用いたプロアクティブ認証(Proactive Authentication using EAP)
このセクションはプロアクティブ認証プロトコルとしてEAPを用いる手続きについて説明する。
【0095】
ダイレクトプロアクティブ認証(Direct Proactive Authentication)
このシナリオでは、MNは、メディア独立候補オーセンティケータで、認証を直接的に行なう。ここでの仮定はMNが、候補オーセンティケータを知るかまたはMIH情報サービス(MIH Information Service)を介して発見するかのいずれかである。候補オーセンティケータは、IPリンクを介してMNから直接到達可能でなければならない。
【0096】
コールフロー(Call Flows)
図9は、ネットワーク主導のダイレクトプロアクティブ認証に関して、MNとメディア独立オーセンティケータとの間の複数のメッセージフローを説明する。それは例Aおよび例Bのアーキテクチャの両方をカバーする。例Bアーキテクチャでは、サービングMIA−KH(Serving MIA-KH)および複数の候補MIA−KHオーセンティケータは、2つの別個のエンティティであり、またそれらは、互いに通信するためにインターフェースRP5を用いる。2つの新しいMIHメッセージタイプ:i)MIH Pro_Authリクエスト(EAP)メッセージおよびii)MIH Pro_Auth応答メッセージは、MIH上の複数のEAPメッセージを伝えるために提案されている。最初のMIH Pro_Auth Requestメッセージは、MNからのMIH Pro_Auth Responseメッセージが続くEAP_Identity_Requestメッセージを伝えるネットワークによって開始される。PoA−Link−Addr−ListおよびMN−Link−Addr−Listは、リンクレイヤーアイデンティティーで複数の鍵を安全に結びつけるために、最終リクエスト/応答メッセージにおいて必要である。
【0097】
図10は、モバイル主導のプロアクティブ認証に関して、MNと、メディア独立したオーセンティケータとの間の複数のメッセージフローを説明する。以前のものとの重要な差は、MIH Pro_Auth Requestを生成し、かつそれを候補オーセンティケータに直接送るMNからトリガーが来るということである。残りのコールフローは、図9に説明されるようなネットワーク主導のダイレクトプロアクティブ認証に似ている。
【0098】
非ダイレクトプロアクティブ認証(Indirect Proactive Authentication)
このシナリオではMNは、メディア独立候補オーセンティケータで、認証を直接行なうことができない。サービングオーセンティケータは、MN(ネットワーク主導認証の場合)、または候補MIA−KH(モバイル主導認証の場合)のどちらかへ向けて、複数のメッセージを転送することに参加する。ここでの仮定は、MNが候補オーセンティケータを知るかまたはMIH情報サービス(MIH Information Service)を介して発見するかのいずれかであるが、MNは候補オーセンティケータにIPリンクを介して直接到達することはできない。
【0099】
コールフロー(Call Flows)
図11は、ネットワーク主導の非ダイレクトプロアクティブ認証に関して、MNと、複数のメディア独立オーセンティケータとの間での複数のメッセージフローを説明する。以前に説明されているように、それは例Aおよび例Bのアーキテクチャの両方をカバーする。また、例Bのアーキテクチャでは、サービングMIA−KHおよび候補MIA−KHのエンティティは、2つの別個のエンティティである。またそれらは、互いに通信するためにインターフェースRP5を用いる。最初のMIH Pro_Auth Requestメッセージは、候補MIA−KHによって始められ、その後、MNへ転送されるサービングMIA−KHにそれを送った。
【0100】
MNはMIH Pro_Auth Responseメッセージを生成し、続く複数のEAPメッセージはリクエストおよび応答のメッセージに関して運ばれる。PoA−Link−Addr−ListおよびMN−Link−Addr−Listは、リンクレイヤーアイデンティティーを鍵に安全に設定するために用いられる。
【0101】
図12は、MIH Pro_Auth Requestメッセージを生成し、サービングMIA−KHにそれを送るMNからトリガーが来る、モバイル主導の非ダイレクトプロアクティブ認証を描いている。候補MIA−KHは、サービングMIA−KHからこのメッセージを受信し、その後、MNへ転送されるサービングMIA−KHにMIH Pro_Auth Responseメッセージを送る。
【0102】
残りのコールフローは、図11で説明されるようなネットワーク主導の非ダイレクトプロアクティブ認証に似ている。
【0103】
ERPを使用するプロアクティブ認証(Proactive Authentication using ERP)
このセクションはプロアクティブ認証プロトコルとしてERPを用いる手続きについて説明する。
【0104】
ダイレクトプロアクティブ認証(Direct Proactive Authentication)
このシナリオではMNは、メディア独立候補オーセンティケータで、認証を直接行なう。ここでの仮定はMNが、候補オーセンティケータを知るかまたはMIH情報サービス(MIH Information Service)を介して発見するかのいずれかである。候補オーセンティケータは、IPリンクを介してMNから直接到達可能でなければならない。
【0105】
コールフロー(Call Flows)
図13は、ネットワーク主導のダイレクトプロアクティブ認証に関して、MNとメディア独立オーセンティケータとの間の複数のメッセージフローを示す。それは例Aおよび例Bのアーキテクチャの両方をカバーし、例Bのアーキテクチャでは、サービングMIA−KH(Serving MIA-KH)および複数の候補MIA−KHオーセンティケータは、2つの別個のエンティティであり、またそれらは、互いに通信するためにインターフェースRP5を用いる。MIH Pro_Auth Indicationと呼ばれる新しいMIHメッセージタイプが、MIH上での複数のERPメッセージ交換を開始するために提案されている。これは、MNを始動させ、MIH Pro_Auth Request(ERP)メッセージを生成する。PoA−Link−Addr−ListおよびMN−Link−Addr−Listは、リンクレイヤーアイデンティティーを複数の鍵に安全に設定するために、リクエスト/応答メッセージにおいて必要である。
【0106】
図14は、モバイル主導のプロアクティブ認証に関して、MNと、メディア独立したオーセンティケータとの間の複数のメッセージフローを示す。以前のものとの主な差は、MIH Pro_Auth Requestを生成し、かつそれを候補オーセンティケータに直接送るMNからトリガーが来るということである。最後に、候補MIA−KHは、認証成功または失敗を有するMIH Pro_Auth Responseを送る。
【0107】
非ダイレクトプロアクティブ認証(Indirect Proactive Authentication)
このシナリオではMNは、メディア独立候補オーセンティケータで、認証を直接行なうことができない。サービングオーセンティケータは、MN(ネットワーク主導認証の場合)、または候補MIA−KH(モバイル主導認証の場合)のどちらかへ向けて、複数のメッセージを転送することに参加する。ここでの仮定は、MNが候補オーセンティケータを知るかまたはMIH情報サービス(MIH Information Service)を介して発見するかのいずれかであるが、MNは候補オーセンティケータにIPリンクを介して直接到達することはできない。
【0108】
コールフロー(Call Flows)
図15は、ネットワーク主導の非ダイレクトプロアクティブ認証に関して、MNと、複数のメディア独立オーセンティケータとの間での複数のメッセージフローを示す。最初のMIH Pro_Auth Requestメッセージは、候補MIA−KHによって始められ、その後、MNへ転送されるサービングMIA−KHにそれを送った。MNはMIH Pro_Auth Responseメッセージを生成し、続く複数のEAPメッセージはリクエストおよび応答のメッセージに関して運ばれる。PoA−Link−Addr−ListおよびMN−Link−Addr−Listは、リンクレイヤーアイデンティティーを鍵に安全に設定するために用いられる。
【0109】
図16は、ERPを有するMIH Pro_Auth Requestメッセージを生成し、サービングMIA−KHにそれを送るMNからトリガーが来る、モバイル主導の非ダイレクトプロアクティブ認証を示す。候補MIA−KHは、サービングMIA−KHからこのメッセージを受信し、その後、MNへ転送されるサービングMIA−KHにERPを有するMIH Pro_Auth Responseメッセージを送る。PoA−Link−Addr−ListおよびMN−Link−Addr−Listは、リンクレイヤーアイデンティティーを複数の鍵に安全に設定するために、リクエスト/応答メッセージにおいて必要である。
【0110】
ターゲットオーセンティケータへのアタッチメント(Attachment to Target Authenticator)
認証が行なわれ、かつモバイルノードがハンドオーバを実行することを決定した後に、それは複数の候補ネットワークのうちの1つを選択し、そのアクセスネットワークに切り替える。この候補ネットワークはターゲットネットワークになり、このアクセスネットワークにサービスするオーセンティケータは、ターゲットメディア固有オーセンティケータおよび鍵ホルダ(MSA−KH)と呼ばれる。その後、ターゲットMSAがモバイルノードに関してターゲットメディア独立オーセンティケータおよび鍵ホルダ(MIA-KH)から鍵の正しいセットを得たと仮定して、モバイルノードはメディア固有セキュアアソシエーション(SA)を行う。
【0111】
コールフロー(Call Flows)
図17は、MNとターゲットMSA−KHとターゲットMIA−KHとの間のコールフローを描く。一旦プロアクティブ認証が成功して行なわれれば、MIA−KHは、MSA−KHへプッシュされるか、MSA−KHによってプルされることができる複数のモバイルノードメディア固有鍵につき生成する。一旦複数の鍵がMSA−KHで利用可能ならば、モバイルノードは、十分な認証を行う必要がなしにネットワークへそれが切り替えるとすぐに、メディア固有セキュリティアソシエーションを行うことができる。一旦セキュアアソシエーションが成功し、かつIP接続が確立されれば、MNは、MIA−KHが正確にモバイルノードをそのサービングノードとして登録するために、MIA−KHを登録する。
【0112】
プロアクティブ認証終了(Proactive Authentication Termination)
プロアクティブ認証終了の目的は、モバイルノードおよび候補/ターゲット/サービングのオーセンティケータがセッションを終了し、対応の複数の状態マシンが同期されることを保証することである。この時点で、MI−PMKおよびMS−PMKはキャッシュされるかまたは削除されるかのいずれかである。
【0113】
ダイレクトプロアクティブ認証終了(Direct Proactive Authentication Termination)
ダイレクトプロアクティブ認証終了は、ネットワークおよびモバイルのノードの両方が認証状態を直接終了することを可能にする。
【0114】
コールフロー(Call Flows)
図18は、ネットワーク主導およびモバイル主導の終了手続の両方に関するコールフローを示す。保全性チェック(インテグリティチェック、integrity check)を含む目的は、終了のリクエストおよび応答の信頼性を確認することである。
【0115】
非ダイレクトプロアクティブ認証終了(Indirect Proactive Authentication Termination)
非ダイレクトプロアクティブ認証終了は、ネットワークとモバイルノードの両方がサービングMIA−KHを介して認証状態を終了することを可能にする。
【0116】
コールフロー(Call Flows)
図19は、ネットワーク主導およびモバイル主導の終了手続の両方に関するコールフローを示す。保全性チェックを含むことの目的は、終了のリクエストおよび応答の信頼性を確認することである。両方の場合では、サービングMIA−KHは、終了リクエストを、MNまたは候補MIA−KHのいずれかへ転送する。
【0117】
プリミティブ(Primitives)
このセクションは、プロアクティブ認証を可能にするために要求されるプリミティブおよび対応するパラメーターを概説する。
【0118】
イベントプリミティブ(Event Primitives)
テーブル1は、複数のリンクイベントのリストを示す。
【0119】
テーブル1:イベントプリミティブのリスト(List of Event Primitives)
【表1】
【0120】
Link_Pro_Auth_key_Install.indication
機能:レイヤー2接続の確立が、サービスプリミティブの指定されたリンクインターフェースセマンティックス(Semantics)上で試みられる場合、この通知が配信される。
【0121】
Link_Pro_Auth_key_Install.indication (
Linkldentifler

パラメーター(Parameters):
【表2】
【0122】
生成された場合(When generated)
指定されたリンクインターフェースに関してあるいは成功したプロアクティブ認証の完成の後に、レイヤー2接続が確立される場合、この通知が生成される。
【0123】
受信の影響(Effect of Receipt)
MIHFは、この通知をサブスクライブしている(複数の)MIHユーザーにこのリンク通知を渡すものとする。(複数の)MIHユーザーは複数のメディア固有鍵をプッシュまたはプルする。
【0124】
MIHイベント(MIH Events)
テーブル2はMIHイベントのリストを説明する。
【0125】
テーブル2:MIHイベントのリスト(List of MIH Events)
【表3】
【0126】
MIH_Pro_Auth_Result.indication
機能:MIH_Pro_Auth_Resultは、ローカルイベントを彼らに通知するために、複数のローカルMIHFユーザーに送られるか、またはこの遠隔イベントにサブスクライブしている複数の遠隔MIHFユーザーに示すためにMIH_Pro_Auth_Requestメッセージの受信の結果である。
【0127】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Result.indication (
Sourceldentifier
Mobilenodeldentifier
Candidateldentifier(Optional)
MobileLinkldentifiers
PoALinkldentifiers
Status
)
パラメーター(Parameters):
【表4】
【0128】
生成された場合(When Generated)
このプリミティブは、MIH_Pro_Auth_Requestメッセージが受信された場合に、ローカルまたは遠隔のMIHFによって生成される。
【0129】
受信への影響(Effect on Receipt)
MIHFは、この通知をサブスクライブした(複数の)MIHユーザーへこのリンク通知を渡すものとする。
【0130】
コマンドプリミティブ(Command Primitives)
テーブル3はMIHコマンドについて説明する。
【0131】
テーブル3:MIHコマンドのリスト(List of MIH Commands)
【表5】
【0132】
MIH_Pro_Auth_Start.request
機能:プリミティブは、プロアクティブ認証のその意図についてローカルMIHFあるいはピアMIHユーザーに示すために、MIHユーザー(MIH User)によって呼び出される。
【0133】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Start.request (
Destinationldentifier,
MobileNodeldentifier(Optional)
Candidateldentifier(Optional)
)
パラメーター(Parameters):
【表6】
【0134】
生成される場合(When Generated)
このプリミティブは、プロアクティブ認証のその意図についてのローカルMIHFまたは遠隔のMIHユーザーと通信するために、MIHユーザーによって呼び出される。
【0135】
受信への影響(Effect on Receipt)
このプリミティブの受信に際して、ローカルMIHFは、MIH_Pro_Auth Requestメッセージを生成し、かつデスティネーション識別子(Destination Identifier)によって識別される遠隔のMIHFへ送信する。遠隔のMIHFはMIHユーザー(MIH User)へ指示としてリクエストを転送する。
【0136】
MIH_Pro_Auth_Start.indication
機能:このプリミティブは、MIH_Pro_Auth Requestメッセージが遠隔MIHFから受信されたMIHユーザー(MIH User)に示すために、MIHFによって用いられる。
【0137】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Start.indication (
Sourceldentifier,
MobileNodeldentifier
Candidateldentifier
)
パラメーター(Parameters):
【表7】
【0138】
生成される場合(When Generated)
このプリミティブは、ピアMIHFからMIH_Pro_Auth requestメッセージを受信することについてMIHFによって生成される。
【0139】
受信への影響(Effect on Receipt)
この指示を受信するMIHユーザー(MIH User)は、リクエストメッセージでのソース識別子(Source Identifier)によって示される遠隔MIHFへのMIH_Pro_Auth_Start.responseプリミティブを呼び出すものとする。
【0140】
MIH_Pro_Auth_Start.response
機能:このプリミティブは、ネットワークでの遠隔MIHFからのMIH_Pro_Auth requestメッセージへ応答するために、MNでのMIHFによって使用される。
【0141】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_start.response (
Destinationldentifier,
MobileNodeldentifier (Optional),
Candidateldentifier (optional),
Status,
)
パラメーター(Parameters):
【表8】
【0142】
生成される場合(When Generated)
遠隔のMIHユーザー(MIH User)は、そのMIHFからのMIH_Pro_Auth_Start.responseメッセージに応答してこのプリミティブを呼び出す。
【0143】
受信への影響(Effect on Receipt)
MIHFは、デスティネーション識別子に示されるピアMIHFへMIH_Pro_Auth responseメッセージを送信する。
【0144】
MIH_Pro_Auth_Start.confirm
機能:このプリミティブは、MIH_Pro_Auth responseメッセージがピアMIHFから受信されたことを確認するためにMIHFによって用いられる。
【0145】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Start.confirm(
Sourceldentifier,
MobileNodeldentifier(Optional),
Candidateldentifier(Optional),
Status,
)
パラメーター(Parameters):
【表9】
【0146】
生成される場合(When Generated)
このプリミティブは、ピアMIHFからMIH_Pro_Auth responseメッセージを受信するMIHFによって生成される。
【0147】
受信への影響(Effect on Receipt)
プリミティブを受信する際に、プロアクティブ認証リクエストを最初に開始するエンティティは、プロアクティブ認証を実行するか、またはプリミティブに基づいてそれを中止することを決定する。しかしながら、ステータス(Status)が「成功あるいは失敗(Success or Failure)」を示さない場合、受信者は任意の他の戻り値を無視し、代わりに、適切なエラー処理を行なう。
【0148】
MIH_Pro_Auth_Termination.request
機能:プリミティブは、プロアクティブ認証の終了についてピアMIHユーザー(MIH User)に示すために、MIHユーザーによって呼び出される。
【0149】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Termination.request (
Destinationldentifier,
MobileNodeldentifier(Optional)
Candidateldnetifier(Optional)
KeyCache
)
パラメーター(Parameters):
【表10】
【0150】
生成される場合(When Generated)
このプリミティブは、プロアクティブ認証の終了について遠隔のMIHユーザーと通信するために、このプリミティブはMIHユーザーによって呼び出される。
【0151】
受信への影響(Effect on Receipt)
このプリミティブの受信に際して、ローカルMIHFは、デスティネーション識別子(Destination Identifier)によって識別された遠隔のMIHFへのMIH_Pro_Auth_Termination requestメッセージを生成し送る。遠隔のMIHFは、MIHユーザーへの指示としてリクエストを転送する。
【0152】
MIH_Pro_Auth_Termination.indication
機能:このプリミティブは、MIH_Pro_Auth_Termination requestメッセージが遠隔MIHFから受信されたことをMIHユーザーに示すために、MIHFによって用いられる。
【0153】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Termination.indication (
Sourceldentifier,
MobileNodeldentifier(Optional)
Candidateldnetifier(Optional)
KeyCache
)
パラメーター(Parameters):
【表11】
【0154】
生成される場合(When Generated)
このプリミティブは、ピアMIHFからMIH_Pro_Auth_Termination requestメッセージを受信することについてのMIHFによって生成される。
【0155】
受信への影響(Effect on Receipt)
この指示を受信するMIHユーザーは、ソース識別子(Source Identifier)によって示されている遠隔MIHFへのMIH_Pro_Auth_Termination.responseを生成するものとする。
【0156】
MIH_Pro_Auth_Termination.response
機能:このプリミティブは、ネットワークでの遠隔MIHFからのMIH_Pro_Auth requestメッセージに応答するために、MN上でのMIHFによって使用される。
【0157】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Termination.response (
Destinationldentifier,
MobileNodeldentifler(optional),
Candidateldentifler(Optional),
Status,
)
パラメーター(Parameters):
【表12】
【0158】
生成される場合(When Generated)
遠隔のMIHユーザーは、そのMIHFからのMIH_Pro_Auth_Termination.indicationに応じてこのプリミティブを呼び出す。
【0159】
受信への影響(Effect on Receipt)
MIHFは、デスティネーション識別子に示されるピアMIHFへ、MIH_Pro_Auth responseメッセージを送る。
【0160】
MIH_Pro_Auth_Termination.confirm
機能:このプリミティブは、MIH_Pro_Termination responseメッセージがピアMIHFから受信されたことを確認するために、使用される。
【0161】
サービスプリミティブのセマンティックス(Semantics of service primitive)
MIH_Pro_Auth_Termination.confirm (
Sourceldentifier,
MobileNodeldentifier(Optional),
Candidateldentifier(Optional),
Status,
)
パラメーター(Parameters):
【表13】
【0162】
生成された場合(When Generated)
このプリミティブは、ピアMIHFからMIH_Pro_Auth responseメッセージを受信するMIHFによって生成される。
【0163】
受信への影響(Effect on Receipt)
プリミティブを受信する際に、プロアクティブ認証リクエストを最初に開始するエンティティは、プロアクティブ認証を終了するか、またはプリミティブに基づいてそれを中止することを決定する。しかしながら、ステータスが「成功あるいは失敗(Success or Failure)」を示さない場合、受信者は任意の他の戻り値を無視し、代わりに、適切なエラー処理を行なう。
【0164】
LInk_Pro_Auth_Key_Install.request
機能:プリミティブは、メディア固有オーセンティケータへ複数のメディア固有鍵をインストールするローカルMIHFを示すために、MIHユーザーによって呼び出される。
【0165】
サービスプリミティブのセマンティックス(Semantics of service primitive)
Link_Pro_Auth_Key_Install.request (
DestinationLinkldentifierwithKeys
)
パラメーター(Parameters):
【表14】
【0166】
生成された場合(When Generated)
このプリミティブは、メディア固有オーセンティケータへ複数の鍵をインストールするローカルの複数のレイヤーを示すために、MIHFによって呼び出される。
【0167】
受信への影響(Effect on Receipt)
このプリミティブの受信の際に、下位レイヤーはLink_Pro_Auth_Key_Install.comfirmプリミティブをMIHFへ生成する。
【0168】
Link_Pro_Auth_Key_Install.comfirm
機能:このプリミティブは、Link_Pro_Auth_Key_Install.requestが受信されたことを確認するために、MIHFによって使用される。
【0169】
サービスプリミティブのセマンティックス(Semantics of service primitive)
Link_Pro_Auth_Key_Install.confirm (
Status,
)
パラメーター(Parameters):
【表15】
【0170】
生成された場合(When Generated)
このプリミティブは、Link_Pro_Auth_Key_Install.requestをMIHFから受信する際に下位レイヤーによって生成される。
【0171】
受信への影響(Effect on Receipt)
プリミティブを受信する際に、MIHFは、ステータスに基づいて、複数のプロアクティブ認証状態を維持するか、またはそれを中止するかを決定する。
【0172】
鍵生成アルゴリズム(Key Generation Algorithm)
・KDF:RFC5246で指定される鍵導出関数(Key derivation function)
−デフォルトKDF(すなわち、HMAC−SHA−256に基づいたIKEv2 PRF+)は、ピアMIHF間で明示的に交渉されることなく、使用される。
【0173】
・MI-PMK = KDF(MK, "MI-PMK" | RAND_P | RAND_A | length)
−MI−PMKの長さ(Length)は64オクテットである
−MK(マスター鍵、Master Key):MSKまたはrMSK
−RAND_P:ピアによって生成される乱数
−RAND_A:オーセンティケータによって生成される乱数
・MS-PMK =KDF(MI-PMK, "MS-PMK" | MN_LINK_ID | POA_LINK_ID | length)
−MS_PMKの長さは各メディアに依存する。802.11の場合には、長さ(Length)=32。
【0174】
−MN_LINK_ID:LINK_IDデータタイプとしてエンコードされる、MNのリンク識別子
−POA_LINK_ID:LINK_IDデータタイプとしてエンコードされる、メディア固有のオーセンティケータのリンク識別子
・PRF+:IKEv2[RFC4306]で指定される鍵展開
・PRF+ (K,S) = Tl | T2 | T3 | T4 | ...
・ここで:
・‘ | ’は連結(concatenation)を意味する
・T1 = PRF (K, S | 0x01)
・T2 = PRF (K, T1 | S | 0x02)
・T3 = PRF (K, T2 | S | 0x03)
・T4 = PRF (K, T3 | S | 0x04)
・...
・鍵マテリアルの要求される長さを計算する必要があるとして継続する。デフォルトPRFは、HMAC−SHA−256[SHA256]として受け取られる。PRF+が単に255回のイテレーションに関して定義されるので、それは8160オクテット以内の鍵マテリアルを生成してもよい。
【0175】
鍵配布機構(Key Distribution Mechanism)
いくつかの実施形態では、鍵配布機構は、技術でのものによって確立することができる。例えば、これは規格を要求することができるか、あるいは配置仕様または実装選択として残すことができる。
【0176】
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、(様々な実施形態にまたがる態様などの)組合せ、適合および/または変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、または本出願の出願中において説明される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能またはステッププラス機能限定は、特定のクレーム限定について、この限定において、a)「〜の手段」または「〜のステップ」が明記されている、b)対応する機能が明記されている、およびc)構造、材料またはこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」または「発明」という用語は、本開示内の1つまたは複数の態様を指すものとして使用され得る。本発明または発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様または実施形態にわたって適用されるものと解釈されるべきではなく(すなわち、本発明はいくつかの態様および実施形態を有すると理解されるべきであり)、また、誤って本出願または特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセスまたはステップ、これらの任意の組合せ、および/またはこれらの任意の部分などを説明するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「e.g.」という省略用語が用いられ得る。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19