(57)【特許請求の範囲】
【請求項１】
メディア独立アクセス機能を実装したコンピュータを有する装置であって、
異種メディア間でアタッチされたモバイルデバイスを認証する独立オーセンティケータと；
各々が固有のサービングメディアに対応する固有のオーセンティケータをサポートする複数の異種アクセスネットワークに前記独立オーセンティケータを接続するインターフェースと；
前記コンピュータのメディア独立機能に基づいた所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーとを具備し、
前記独立オーセンティケータは、サービングアクセスネットワークから、それぞれ固有のサービングメディアを持つ複数の異種アクセスネットワークに属する候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークを認証し、
前記ハンドオーバに先立って前記候補アクセスネットワークを認証することが、前記独立オーセンティケータによって正常に行われた後に、前記独立オーセンティケータが、前記モバイルデバイスに関するメディアキーを生成し、メディア固有鍵を固有オーセンティケータに利用可能にし、
全体の認証プロセスを実行するために前記複数のモバイルデバイスを必要とすることなく、かつ、前記固有オーセンティケータでメディア固有セキュリティアソシエーションを成功して確立した後に、前記独立オーセンティケータに登録するために前記独立オーセンティケータとＩＰ接続を確立する前記複数のモバイルデバイスを必要とすることなく、前記複数の固有のアクセスネットワークのうちのいずれかへ切り替える際に、前記モバイルデバイスは、利用可能な前記メディア固有鍵を使用して、前記固有のオーセンティケータで前記メディア固有セキュリティアソシエーションを実行する、装置。
【請求項２】
前記独立オーセンティケータと前記固有のオーセンティケータの間に提供された固有インターフェースによって前記メディア固有鍵が候補アクセスネットワークのサービングアクセスネットワークおよび固有のオーセンティケータからプルまたはプッシュされ、
前記独立オーセンティケータは、前記ハンドオーバのためのペアワイズメディア独立マスター認証鍵を得るためにマスター認証鍵を保持する、請求項１の装置。
【請求項３】
前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために、最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項２の装置。
【請求項４】
前記複数の異種アクセスネットワークの各々は、前記インターフェースを介して専用の独立オーセンティケータに接続され；
前記専用の独立オーセンティケータと前記複数の異種アクセスネットワークの各々との間に相互の通信接続を形成する個別のインターフェースを具備し、
前記専用の独立オーセンティケータとともに前記複数の異種アクセスネットワークの各々は２つの個別サービスポイントを有する、請求項１の装置。
【請求項５】
前記独立オーセンティケータは、前記インターフェースを介した前記複数の異種アクセスネットワークの各々との間の相互通信を管理するための単一のサービスポイントである、請求項１の装置。
【請求項６】
対応する候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って、該モバイルデバイスがアタッチされるサービングアクセスネットワークを経ることにより、前記モバイルデバイスは、前記対応する候補アクセスネットワークの前記独立オーセンティケータとの認証を行なう、請求項１の装置。
【請求項７】
前記ハンドオーバのトリガーは、前記候補アクセスネットワーク、または前記モバイルデバイスによって生成することが可能である、請求項４の装置。
【請求項８】
前記モバイルデバイスは、対応する候補アクセスネットワークへの該モバイルデバイスのハンドオーバに先立って、前記対応する候補アクセスネットワークの独立オーセンティケータとの認証を直接行なう、請求項１の装置。
【請求項９】
前記ハンドオーバのトリガーは、前記モバイルデバイスからの応答が続く候補アクセスネットワークによって、または前記候補アクセスネットワークからの応答が続くモバイルデバイスによって生成することができる、請求項８の装置。
【請求項１０】
前記サービングメディアはケーブル、ファイバー、無線周波数および衛星を含む請求項１の装置。
【請求項１１】
プロセッサが、異種メディア間でアタッチされたモバイルデバイスをメディア独立オーセンティケータによってプロアクティブに認証する動作を実行可能にするための命令がコード化されたマシンアクセス可能な記憶媒体に記憶されるプログラムであって、
前記命令は、
複数の異種アクセスネットワーク内のサービングアクセスネットワークにアタッチされたモバイルデバイスにメディア固有認証手続きを割り当てること；
前記メディア独立オーセンティケータを介して候補アクセスネットワークに関する情報をハンドオーバ準備段階でモバイルデバイスに提供すること；
インターフェースを用いて、プロアクティブ認証を行なうこと；
前記メディア独立オーセンティケータによって前記プロアクティブ認証が正常に行なわれると、それぞれの前記モバイルデバイスに関するメディア固有鍵を生成し、前記メディア固有認証手続きを有する前記異種アクセスネットワークに前記メディア固有鍵を利用可能にすること；
全体の認証プロセスを実行するために前記複数のモバイルデバイスを必要とすることなく、前記複数の異種アクセスネットワークのうちのいずれかへ切り替える際に、メディア固有セキュリティアソシエーションを実行するために、利用可能な前記メディア固有鍵を使用すること；
それぞれの前記異種アクセスネットワークで前記メディア固有セキュリティアソシエーションを成功して確立した後に、サーバに登録するために前記メディア独立オーセンティケータとＩＰ接続を確立すること；
前記複数の異種アクセスネットワークに属する候補アクセスネットワークへのハンドオーバを実行すること、を具備するプログラム。
【請求項１２】
前記メディア独立オーセンティケータおよびメディア固有オーセンティケータの間で提供される固有インターフェースによって、前記サービングアクセスネットワークおよび前記候補アクセスネットワークから前記メディア固有鍵をプルまたはプッシュし、
前記メディア独立オーセンティケータは、ハンドオーバのためのペアワイズのメディア独立マスター認証鍵を得るためのマスター認証鍵を保持する、請求項１１のプログラム。
【請求項１３】
前記モバイルデバイスは、候補アクセスネットワークへの該モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークのメディア独立オーセンティケータとのプロアクティブ認証を直接行なう、請求項１２のプログラム。
【請求項１４】
前記モバイルデバイスからの応答が、前記候補アクセスネットワークによるハンドオーバのトリガーの生成に続いて起こる、請求項１３のプログラム。
【請求項１５】
前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために、最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項１４のプログラム。
【請求項１６】
前記候補アクセスネットワークからの応答が、前記モバイルデバイスによる前記ハンドオーバのトリガーの生成に続いて起こる、請求項１３のプログラム。
【請求項１７】
前記候補アクセスネットワークおよび前記モバイルデバイスは、メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために、最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項１６のプログラム。
【請求項１８】
前記モバイルデバイスは、前記候補アクセスネットワークへのモバイルデバイスのハンドオーバに先立って、前記モバイルデバイスはアタッチされる前記サービングアクセスネットワークを経ることにより、前記候補アクセスネットワークのメディア独立オーセンティケータとのプロアクティブ認証を行なう、請求項１１のプログラム。
【請求項１９】
前記メディア独立オーセンティケータおよびメディア固有オーセンティケータの間に提供される固有インターフェースを介して前記サービングアクセスネットワークおよび前記候補アクセスネットワークからメディア固有鍵をプルまたはプッシュし、
前記モバイルデバイスからの応答が、前記候補アクセスネットワークによる前記ハンドオーバのトリガーの生成に続いて起こり、
前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成し；
前記候補アクセスネットワークからの前記応答が、前記モバイルデバイスによる前記ハンドオーバのトリガーの生成に続いて起こり、前記候補アクセスネットワークおよび前記モバイルデバイスは、前記メディア固有鍵にリンクレイヤー・アイデンティティーを安全に設定するために最終のリクエストおよび応答において気付リンクアドレスリストおよびモバイルノードリンクアドレスリストをそれぞれ生成する、請求項１８のプログラム。
【請求項２０】
メディアに固有のリンクの終端にインターフェースを介してアタッチされた他のエンティティを認証するメディア独立認証機能を含むメディア独立アクセス機能を有するサーバと；
前記メディアに固有の前記リンクの前記終端に前記インターフェースを介してアタッチされた前記他のエンティティに対応する認証機能を含むメディア固有アクセス機能を各々が含んでいる複数の異種アクセスネットワークと；
前記複数の異種アクセスネットワークに接続されるモバイルデバイスとを具備し、
前記サーバは、ハンドオーバに関するメディア独立機能に基づく所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーを有し、
前記サーバは、サービングアクセスネットワークから、候補アクセスネットワークへの前記モバイルデバイスの前記ハンドオーバに先立って前記候補アクセスネットワークを認証し、前記候補アクセスネットワークの各々は前記メディアに固有の前記リンクを有する前記複数の異種アクセスネットワークに属し、
ハンドオーバ認証に先立って前記候補アクセスネットワークを認証することが前記サーバによって正常に行われた後に、前記サーバが、それぞれの前記モバイルデバイスに関するメディア固有鍵を生成し、前記メディア固有アクセス機能および認証機能を提供する前記異種アクセスネットワークに前記メディア固有鍵を利用可能にし、
全体の認証プロセスを実行するために前記モバイルデバイスを必要とすることなく、かつ、それぞれの前記異種アクセスネットワークでメディア固有セキュリティアソシエーションを成功して確立した後に、前記サーバに登録するために前記サーバとＩＰ接続を確立する前記モバイルデバイスを必要とすることなく、前記複数の異種アクセスネットワークのうちのいずれかへ切り替える際に、前記モバイルデバイスは、利用可能な前記メディア固有鍵を使用して、前記メディア固有セキュリティアソシエーションを実行する、プロアクティブな認証のためのシステム。
【発明の詳細な説明】
【関連出願】
【０００１】
本出願は、２００９年５月３日提出の米国仮出願第６０／９１７，５４９号および２００９年６月２９日提出の米国仮出願第６１／２２１，５５１号の優先権を主張するものであって、これらの開示内容の全体が参照により本明細書に組み込まれる。
【背景技術】
【０００２】
１．技術分野
本発明は、異種ネットワーク間のセキュリティシグナリングに関し、特に、モバイルノート（ＭＮ）とターゲットネットワークの間のセキュアなハンドオーバを行うためのオーセンティケーションおよびオーサリゼーションの概念に関する。
【０００３】
２．背景論議
ネットワークおよびインターネット（登録商標）プロトコル：
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザーが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業および個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。
【０００４】
ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザーがデータまたはメッセージを送信し、または受信するとき、データまたはメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００５】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤー）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミングおよび／またはハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰおよび／または他のトランスポートおよびネットワークプロトコル、ならびに他のソフトウェアおよびハードウェアの組み合わせである。
【０００６】
通常、上位４層は、メッセージがユーザーから、またはユーザーへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザー認証およびプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信および発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換およびダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御および誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、ルーティングや転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識および管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤー）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。
【０００７】
無線ネットワーク：
無線ネットワークは、例えば、セルラおよび無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声および／またはデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次の構成要素の一部または全部、即ち送受信機（すなわち、例えば、送信機、受信機および、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機および受信機）、アンテナ、プロセッサ、１つまたは複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセットまたは集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）および／または同種のものを含む。
【０００８】
モバイルユーザーが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。
【０００９】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、および他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータおよび電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザー問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）または一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレスおよびＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレスおよびＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。
【００１０】
ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮおよび機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザーが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、およびネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべき要素を含む。
【００１１】
更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、およびＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。
【００１２】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）機器、ＧＰＲＳ（汎用パケット無線システム）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（登録商標）（移動通信用グローバルシステム）機器、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｆｏｒ  ＧＳＭ  Ｅｖｏｌｕｔｉｏｎ）機器、ＴＤＭＡ型（時分割多重接続）機器、またはＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ  ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。
【００１３】
また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、および他のモバイルネットワークシステムにおいて見られる方法およびプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザーは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワークおよびこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１４】
（例えば、モバイルＩＰ外部などの）基本的なＩＰルーティングにおいて、ルーティング機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、および／または転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザーが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスクおよびデフォルトのルータを用いて再構成する必要がある。そうでなければ、ルーティングプロトコルは、パケットを適正に配信することができないはずである。
【００１５】
メディア独立ハンドオーバサービス：
Ｄｒａｆｔ  ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ：Ｍｅｄｉａ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｈａｎｄｏｖｅｒ  Ｓｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフトＩＥＥＥ規格：メディア独立ハンドオーバサービス）と題する２００６年９月のＩＥＥＥ．Ｐ８０２．２１／Ｄ．０１．０９において、特にこの文書は８０２システムとセルラーシステムとの間のハンドオーバを最適化する８０２メディアアクセス独立機構を明記している。ＩＥＥＥ８０２．２１規格は、異種８０２システム間のハンドオーバの最適化を可能にし、また８０２システムとセルラーシステムとの間のハンドオーバを容易にし得る、拡張可能なメディアアクセス独立機構を定義している。
【００１６】
ＩＥＥＥ８０２．２１（メディア独立ハンドオーバ）規格の範囲は、異種メディア間のハンドオーバを最適化するためにリンク層情報および他の関連ネットワーク情報を上位層に供給する仕様を開発することである。これは、３ＧＰＰと、３ＧＰＰ２と、ＩＥＥＥ８０２ファミリーの規格における有線および無線メディア両者と、によって指定されるリンクを含む。この文書では「メディア」は、他に注記されていなければ、通信の感覚的態様（例えばオーディオ、ビデオなど）とは対照的に、電気通信システムにアクセスする方法／モード（例えばケーブル、無線通信、衛星など）を指す。文書の全内容がこの特許出願書にその一部として組み込まれているＤｒａｆｔ  ＩＥＥＥ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ：Ｍｅｄｉａ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｈａｎｄｏｖｅｒ  Ｓｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフトＩＥＥＥ規格：メディア独立ハンドオーバサービス）と題する２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９の１．１を参照されたい。更に、ここで優先権が主張されている仮出願はまた、上記の規格のドラフト０５（ここではＤ０５と呼ばれる）および２００９年１月２１日公開のＩ．Ｅ．Ｅ．Ｅ．８０２．２１規格を組み込んでおり、これらの全内容は参照により本明細書に組み込まれている−すなわち、例えばＩ．Ｅ．Ｅ．Ｅ．コンピュータ学会のＬＡＮ  ＭＡＮ規格委員会によって後援されているＤｒａｆｔ  Ｓｔａｎｄａｒｄ  ｆｏｒ  Ｌｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ：Ｍｅｄｉａ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｈａｎｄｏｖｅｒ  Ｓｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフト規格：メディア独立ハンドオーバサービス）と題する２００７年４月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ０５．００およびＩ．Ｅ．Ｅ．Ｅ．コンピュータ学会のＬＡＮ  ＭＡＮ規格委員会によって後援されているＬｏｃａｌ  ａｎｄ  Ｍｅｔｒｏｐｏｌｉｔａｎ  Ａｒｅａ  Ｎｅｔｗｏｒｋｓ−−Ｐａｒｔ２１：Ｍｅｄｉａ  Ｉｎｄｅｐｅｎｄｅｎｔ  Ｈａｎｄｏｖｅｒ  Ｓｅｒｖｉｃｅｓ（地元地域および大都市圏のネットワークのためのドラフト規格：メディア独立ハンドオーバサービス）と題する２００９年１月２１日公開のＩ．Ｅ．Ｅ．Ｅ．規格をそれぞれ参照されたい。
【００１７】
一般的アーキテクチャ：
序論：
ＩＥＥＥ８０２．２１規格は、種々のハンドオーバ方法を容易にするように意図されている。このような方法は一般に、モバイルノードとネットワークとの間のデータパケットの交換をサポートするデータトランスポート（データ搬送）ファシリティーに関して、ハンドオーバ手順が「メーク前ブレーク(break before make）」または「ブレーク前メーク（make before break）」であるかどうかによって「ハード」または「ソフト」として分類される。
【００１８】
一般にハンドオーバは、ネットワークオペレータとエンドユーザーのニーズを満足させるためにモバイルノードとネットワークインフラストラクチャの両者の協力的使用にかかわる。ハンドオーバ意思決定に関連するハンドオーバ制御、ハンドオーバ方策および他のアルゴリズムは一般に、ＩＥＥＥ８０２．２１規格の範囲に入らない通信システム要素によって取り扱われる。しかしながら、全ハンドオーバプロセスにおけるＭＩＨイベントサービス、ＭＩＨコマンドサービス、ＭＩＨ情報サービスおよびＭＩＨＦの役割と目的が明らかになるように全ハンドオーバ手順の幾つかの態様を説明することは有益である。
【００１９】
一般的設計原理：
ＩＥＥＥ８０２．２１規格は、下記の一般的設計原理に基づいている。
【００２０】
ａ）ＭＩＨ機能は、ハンドオーバ意思決定を助けて容易にする論理的エンティティである。上位層は、ＭＩＨからの入力と前後関係とに基づいてハンドオーバ意思決定とリンク選択とを行う。ハンドオーバが行われるべきであるという認識を容易にすることは、ＭＩＨＦの主要な目標の１つである。効果的なハンドオーバ意思決定を行う方法に関する情報の発見もまた主要構成要素である。
【００２１】
ｂ）ＭＩＨＦは、より上位の層に抽象サービスを提供する。この観点からＭＩＨＦは、上位層に統一的インターフェースを提供する。この統一インターフェースによってあらわになるサービスプリミティブは、異なるアクセスネットワークの技術固有プロトコルエンティティに基づいている。ＭＩＨＦは、技術固有インターフェースを介してモビリティ管理プロトコルスタックの下位層と通信する。
【００２２】
下位層とのＭＩＨＦインターフェースの仕様は、一般にこの規格の範囲内に入らない。このようなインターフェースは既に、ＩＥＥＥ８０２．１、ＩＥＥＥ８０２．３、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６、３ＧＰＰおよび３ＧＰＰ２といったそれぞれのアクセス技術に関連する規格内のサービスアクセスポイント（ＳＡＰ）として明記され得る。この規格は、下位層インターフェースの修正がＭＩＨＦ機能を利用可能にし得る、または改善し得るときに既存のアクセス技術固有規格を修正するための勧告を含み得る。
【００２３】
ｃ）ハンドオーバシグナリング（ハンドオーバ実行および後続の更新の一部としての）は、この規格の一部でない可能性がある。異なるアクセスネットワークは、（移動体起動、ネットワーク起動などの）水平ハンドオーバ機構をサポートする。ハンドオーバ起動トリガーは、同種方式のように行われないときに異種ハンドオーバにおいて有用であり得る。
【００２４】
ｄ）ＭＩＨＦは、ＭＡＣ／ＰＨＹトリガーおよび他の関連ローカルイベントについて更なる処理を行い得る。この処理の定義は、この規格の範囲外である。この規格は、リモートイベントに関してもサポートを与えるであろう。イベントは実際はアドバイザリである。これらのイベントに基づいてハンドオーバを引き起こすべきか否かの決定は、この規格の範囲外である。
【００２５】
ｅ）この規格は、ＭＮ起動、ＭＮ制御、ネットワーク起動およびネットワーク制御のハンドオーバをサポートするための機構を指定するであろう。
【００２６】
ｆ）本規格は、レガシー装置とのトランスペアレントな相互作用をサポートし得る。したがってＩＥＥＥ８０２．２１準拠の装置は、レガシー非ＩＥＥＥ８０２．２１準拠装置と共存し得るであろう。
【００２７】
メディア独立ハンドオーバ基準フレームワーク：
下記のセクションは、クライアントデバイス（ＭＮ）とネットワークとに置ける異なるＭＩＨＦエンティティ間の通信に関する態様を説明する。
【００２８】
ＭＩＨＦ機能は、種々の目的のために互いに通信する。クライアントデバイス（モバイルノード）は、そのＭＩＨサービスポイントとの間でＭＩＨ情報を交換する。いかなるネットワークエンティティにおけるＭＩＨＦでもＭＮベースのＭＩＨＦと直接通信するときにはＭＩＨ  ＰｏＳになる。ＭＩＨネットワークエンティティは、ＭＮとの直接接続を有しない可能性があり、したがってこの特定のＭＮのためのＭＩＨ  ＰｏＳを構成しない。同じＭＩＨネットワークエンティティが異なるＭＮのためのＭＩＨ  ＰｏＳとして、なお動作する可能性がある。ＭＩＨＦ通信は、ＭＩＨ可能ＭＮのすべてのＬ２インターフェース上で起こり得るわけではない。一例として、３つのＬ２インターフェースすなわち８０２．１１、８０２．１６および８０２．３を有するＭＩＨ可能ＭＮ上で、８０２．３インターフェースはシステム管理および保守作業のためだけに使用され得るが、８０２．１１および８０２．１６インターフェースはＭＩＨＦサービスの提供に携わり得る。ＭＮは、そのネットワークＰｏＡと同じネットワークエンティティ内に常駐するＭＩＨ  ＰｏＳとＭＩＨ情報を交換するためにＬ２トランスポートを使用し得る。ＭＮは、そのネットワークＰｏＡと同じネットワークエンティティ内に常駐しない可能性のあるＭＩＨ  ＰｏＳとＭＩＨ情報を交換するためにＬ３トランスポートを使用し得る。このフレームワークは、ＭＩＨネットワークエンティティ間の通信のためにＬ２またはＬ３いずれかの機構の使用をサポートする。図３は、８０２．２１規格のＭＩＨ通信モデルを示す。このモデルは、異なる独自の役割を有するＭＩＨＦとそれらの間の通信関係とを示す。図３に示された通信関係は、ＭＩＨＦにだけ適用される。この通信モデルにおける通信関係の各々が特定のトランスポート機構を意味しないことは注目に値する。むしろ通信関係は、２つの独自ＭＩＨＦ間でＭＩＨＦ関連情報交換が可能であることを示すように意図されているだけである。更には１）ＭＮ上のＭＩＨＦ、２）ＭＮのサービングＰｏＡを含むネットワークエンティティ上のＭＩＨ  ＰｏＳ、３）ＭＮのための候補ＰｏＡ（候補ＰｏＡはＭＮがそれに気づいてはいるが現在それに所属していないＰｏＡであって、この候補ＰｏＡはハンドオーバが最終的に起こった場合にターゲットＰｏＡになる）を含むネットワークエンティティ上のＭＩＨ  ＰｏＳ、４）ＭＮのためのＰｏＡを含まないネットワークエンティティ上のＭＩＨ  ＰｏＳ、５）ＭＮのためのＰｏＡを含まないネットワークエンティティ上のＭＩＨ  非ＰｏＳである。
【００２９】
この通信モデルはまた、ＭＩＨＦの異なる事例間の下記の通信基準点を識別する。
【００３０】
１）通信基準点Ｒ１：基準点Ｒ１は、ＭＮ上のＭＩＨＦとサービングＰｏＡのネットワークエンティティ上のＭＩＨ  ＰｏＳとの間のＭＩＨＦ手順を指す。Ｒ１はＬ２、Ｌ３両者とそれ以上との上の通信インターフェースを包含し得る。Ｒ１上を通ったＭＩＨＦ内容はＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。
【００３１】
２）通信基準点Ｒ２：基準点Ｒ２は、ＭＮ上のＭＩＨＦと候補ＰｏＡのネットワークエンティティ上のＭＩＨ  ＰｏＳとの間のＭＩＨＦ手順を指す。Ｒ２はＬ２、Ｌ３両者とそれ以上との上の通信インターフェースを包含し得る。Ｒ２上を通ったＭＩＨＦ内容はＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。
【００３２】
３）通信基準点Ｒ３：基準点Ｒ３は、ＭＮ上のＭＩＨＦと非ＰｏＡネットワークエンティティ上のＭＩＨ  ＰｏＳとの間のＭＩＨＦ手順を指す。Ｒ３はＬ３とそれ以上と、またおそらくはイーサネット（登録商標）ブリッジ、ＭＰＬＳなどのようなＬ２トランスポートプロトコルとの上の通信インターフェースを包含し得る。Ｒ３上を通ったＭＩＨＦ内容はＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。
【００３３】
４）通信基準点Ｒ４：基準点Ｒ４は、ネットワークエンティティ内のＭＩＨ  ＰｏＳともう１つのネットワークエンティティ内のＭＩＨ  非ＰｏＳ事例との間のＭＩＨＦ手順を指す。Ｒ４はＬ３とそれ以上との上の通信インターフェースを包含し得る。Ｒ４上を通ったＭＩＨＦ内容はＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。
【００３４】
５）通信基準点Ｒ５：基準点Ｒ５は、異なるネットワークエンティティ内の２つのＭＩＨ  ＰｏＳ事例間のＭＩＨＦ手順を指す。Ｒ５はＬ３とそれ以上との上の通信インターフェースを包含し得る。Ｒ５上を通ったＭＩＨＦ内容はＭＩＩＳ、ＭＩＥＳまたはＭＩＣＳに関連している可能性がある。
【００３５】
ＭＩＨ通信モデルの説明図：
ＭＩＨ通信基準点のより大きな説明図のために、ＭＩＨサービスを含むネットワークモデルが図４に示されている。右から左へ移って行くと、このモデルは、多数の有線および無線アクセス技術オプションをサポートするＭＩＨ可能モバイルノード（ＭＮ、一番右）を含む。このモデルは、プロビジョニングサービスプロバイダが多数のアクセス技術を運用している、あるいは相互作用をサポートするＳＬＡが確立されているときにこのサービスプロバイダのユーザーが他のネットワークにローミングすることを可能にすることを想定している。ＭＮは、特定のＭＩＨクエリーを送信することを可能にするＭＩＨＦを実現している。ＭＮはある程度内部的に実現された情報サービスを有し得る。
【００３６】
このモデルは、ある緩やかな連続した仕方でコアネットワーク（オペレータ１―３コア）に接続されたアクセスネットワークを示す。また、よりタイトに相互接続または連結されたアクセスネットワーク（アクセスネットワーク・３）も描かれている。オペレータ１―３コアは各々、サービスプロバイダ、企業イントラネットプロバイダあるいはビジテッドアクセス（visited access）またはホームアクセスの単なる他の一部、あるいはコアネットワークを表す可能性がある。このモデルではサービス提供するプロバイダは、Ｒ１を介して１つのコア（ビジテッド／ホームコア・ネットワークとラベル付けされた）に連結されたアクセスネットワーク・３を運用している。用語ビジテッド（Visited）およびホーム（Home）はサービス提供するサービスプロバイダまたは企業を示すために使用される。図示のネットワークのいかなるものも、ＭＮのサービス提供業者とのオペレータの関係に依存してビジテッドまたはホームネットワークの両方になり得る。ネットワークプロバイダは、自身のネットワークへのハンドオーバを容易にするために自身のアクセスネットワーク（アクセスネットワーク・１―４）においてＭＩＨサービスを提供する。各アクセス技術は、そのＭＩＨ能力を宣伝するか、あるいはＭＩＨサービス発見に応答する。アクセスネットワークに関する各サービスプロバイダは、１つ以上のＭＩＨサービスポイント（ＰｏＳ、通信モデルと比較すること）へのアクセスを可能にする。これらのＰｏＳは、ＭＩＨ能力発見時に決定されたＭＩＨサービスの一部または全部を提供し得る。ＭＩＨ  ＰｏＳの位置またはノードは、規格によって固定されない。ＰｏＳ位置は、オペレータの配置シナリオと技術固有ＭＩＨアーキテクチャとに基づいて変化し得る。
【００３７】
ＭＩＨ  ＰｏＳは、アクセスネットワーク（アクセスネットワーク１、２、４が典型的である）内の所属ポイント（point of attachment）（ＰｏＡ）の隣に常駐し得るか、あるいはＰｏＡと同一場所配置（co-located）され得る。代替としてＰｏＳは、アクセスまたはコアネットワーク（アクセスネットワーク３が典型的である）の内部深く常駐し得る。図３に示されたようにＭＮ内のＭＩＨエンティティは、任意のアクセスネットワーク上のＲ１、Ｒ２またはＲ３のいずれかによってＭＩＨネットワークエンティティと通信する。サービングアクセスネットワーク内のＰｏＡが同一場所配置されたＭＩＨ機能を有すると、Ｒ１基準接続はＰｏＳでもあるＰｏＡで終了する（このモデルのアクセスネットワーク１、２、４へのＭＮはすべてＲ１であり得る）。この場合、Ｒ３基準接続は、任意の非ＰｏＡ（アクセスネットワーク１、２、４へのＭＮによって示された）で終端されるであろう。ＭＩＨイベントはアクティブなＲ１リンクの両側から発生し得る。ＭＮは典型的にはこれらのイベントに反応する第１のノードである。
【００３８】
ビジテッドネットワークとホームネットワークとの相互作用は、制御および管理目的またはデータトランスポート目的のいずれかのためであり得る。ローミング契約またはＳＬＡ契約によって、ＭＮがビジテッドネットワークを介して公衆のインターネットに直接アクセスすることをホームネットワークが可能にし得ることも可能である。図示のように２つのＭＩＨネットワークエンティティは、Ｒ４またはＲ５基準接続を介して互いに通信し得る。ＭＩＨ可能ＰｏＡはまた、Ｒ３およびＲ４基準点を介して他のＭＩＨネットワークエンティティと通信できる。ＭＩＨ可能ＭＮは、候補ネットワークについての情報サービスを取得するためにＲ２基準点を介しての候補アクセスネットワーク内の他のＰｏＡとのＭＩＨ通信を有し得るであろう。
【００３９】
ＭＩＨ情報サービス（ＭＩＩＳ）に関してプロバイダは、ＭＩＨ  ＰｏＳノード（上部左端）に位置する自身の情報サーバへのアクセスを提供する。オペレータは、新しいローミングリスト、コスト、プロバイダ識別情報、プロバイダサービス、優先順位、およびサービスを選択して利用することを可能にする他の任意の情報を含むが、これらに限定されない関連情報を取得できるように、モバイルノードにＭＩＩＳを提供する。図示のようにモバイルノードがプロバイダによってＭＩＩＳデータを事前提供されることは可能である。
【００４０】
またモバイルノードが、情報サービスのプロバイダの任意のアクセスネットワークからＭＩＨ情報サービスを取得することも可能である。ＭＩＩＳはまた、このネットワークのＭＩＩＳサービスポイントを使用してもう１つのオーバーラップしているネットワーク、または近隣のネットワークから利用可能であり得る。サービス提供業者のネットワーク（ここではアクセスネットワーク３と連結されているように描かれている）は、サービス提供業者の、あるいはビジテッドネットワークのＭＩＨ情報サーバのような他のＭＩＨエンティティにアクセスするためにＲ３およびＲ４インターフェースを利用し得る。
【００４１】
ＭＩＨコマンドサービス（ＭＩＣＳ）に関して情報データベースのいかなるものも、コマンドサービスＰｏＳとして使用され得る。ＭＮ  ＭＩＨＦは典型的には、レイヤー３トランスポートを使用してこのサーバと通信する。
【００４２】
ＭＩＨＦサービス：
ＭＩＨＦは、リンク層およびＭＩＨユーザーのために明確なＳＡＰを介して非同期および同期サービスを提供する。任意の型の多数のネットワークインターフェースを有するシステムの場合に上位層は、基礎に在るインターフェースの状態を管理、決定および制御するためにＭＩＨによって提供されるイベントサービス、コマンドサービスおよび情報サービスを使用し得る。
【００４３】
ＭＩＨによって提供されるこれらのサービスは、サービスの連続性の維持と、変化するサービス品質へのサービス適応と、バッテリ寿命保全と、ネットワーク発見およびリンク選択と、において上位層を援助する。８０２型およびセルラー３ＧＰＰ、３ＧＰＰ２型の異種ネットワークインターフェースを含むシステムでは、メディア独立ハンドオーバ機能は、異種ネットワークインターフェースに亘ってサービスを連結するために上位層が効率的な手順を実現するのを助け得る。上位層は、異種ネットワーク間のハンドオーバ動作のために必要とされるリソースの問合せ（クエリー）を行うために異なるエンティティに亘ってＭＩＨＦによって提供されるサービスを利用し得る。
【００４４】
モバイルデバイスにおけるＭＩＨサービスは、異種ネットワーク間でのシームレスハンドオーバを容易にする。モビリティ管理プロトコル（例示的モバイルＩＰ）といったＭＩＨユーザーは、ハンドオーバおよびシームレスセッション連続性のためにサポートされ得る。これは、ハンドオーバを最適化するためにＭＩＨサービスを利用することから、モバイルＩＰおよび他の上位層に加えて他のプロトコルを除外しないであろう。
【００４５】
ＭＩＨサービスを使用するモバイルノードは、イベントサービスのような非同期動作のためにリンク層からの指示を受信するであろう。コマンドサービスおよび情報サービスとの相互作用は、機構の同期クエリーおよび応答型を介して行われるであろう。ＭＩＨＦはまた、同じメディア型のネットワークエンティティとホストエンティティとの間の情報交換のための機能を提供するであろう。もしこのような情報交換のための機構が所定のメディア型をもって（例えばある幾つかのセルラーメディア型をもって）既に存在するならば、ＭＩＨＦはいつでも可能なときに既存の機構を利用するであろうことに留意されたい。
【００４６】
ＭＩＨプロトコル：
ＩＥＥＥ８０２．２１規格は、メディア独立イベントサービス、メディア独立コマンドサービスおよびメディア独立情報サービスをサポートする。ＭＩＨプロトコルは、リモートＭＩＨＦエンティティとメッセージの送達をサポートするトランスポート機構との間で交換されるメッセージのフォーマット（すなわち、ヘッダとペイロードとを有するＭＩＨＦパケット）を定義する。トランスポート機構の選択は、ＭＮをネットワークとＭＩＨ  ＰｏＳの位置とに接続するアクセス技術に依存する。
【００４７】
これらのサービスのためのパケットペイロードは、Ｌ２管理フレーム、Ｌ２データフレームまたは他の上位層プロトコル上で搬送され得る。８０２．１１および８０２．１６といった無線ネットワークは、管理プレーンを有しており、上記のペイロードを搬送するために適当に改善され得る管理フレームをサポートする。しかしながら有線イーサネットネットワークは管理プレーンを有さず、またデータフレームだけで上記ペイロードを搬送し得る。
【００４８】
ＩＥＥＥ８０２．２１規格は、標準ＴＬＶフォーマットにおいてメディア独立方式でパケットフォーマットおよびペイロードを定義する。この後にこれらのパケットは、ペイロードがイーサネットの場合のように正常なデータフレーム上で送られる必要があるときにＭＩＨＦイーサ型を使用してＬ２ＭＩＨプロトコル内にカプセル化され得る。他の場合にはＴＬＶベースのメッセージおよびペイロードは、メディア固有管理フレームに直接カプセル化され得る。代替としてＭＩＨプロトコルメッセージは、下位層（Ｌ２）または上位層（Ｌ３以上）トランスポートを使用してカプセル化され得る。
【００４９】
ＩＥＥＥ８０２．２１規格は、ＭＩＨプロトコルデータユニット（ＰＤＵ）ヘッダおよびペイロードのフォーマットを定義する。標準ＴＬＶフォーマットは、ＰＤＵペイロード内容のためにメディア独立表現を提供する。ＭＩＨＦ  ＰＤＵは、８０２リンク上でＭＩＨＦイーサ型を有するデータフレーム内にカプセル化される。８０２．１１および８０２．１６リンクに関して、ＭＩＨメッセージを搬送するためにメディア固有管理フレームの拡張が推奨される。この規格ではＬ２における３ＧＰＰおよび３ＧＰＰ２アクセスリンク上でのＭＩＨメッセージのトランスポートに関して、何らの仮定も行われていない。
【００５０】
メディア独立情報サービス：
序論：
メディア独立情報サービス（ＭＩＩＳ）は、モバイルノードおよびネットワーク両者におけるＭＩＨＦがハンドオーバを容易にするためにある地理的領域内のネットワーク情報を発見して取得し得るフレームワークを提供する。その目的は、これらのネットワークに亘ってローミングするときにシームレスハンドオーバを容易にするためにこの領域内のＭＮに関連するすべての異種ネットワークのグローバルなビューを取得することである。
【００５１】
メディア独立情報サービスは、種々の情報要素（ＩＥ）のサポートを含む。情報要素は、ネットワークセレクタが知的ハンドオーバ意思決定を行うために本質的である情報を提供する。
【００５２】
ハンドオーバを実行するためには、モビリティの型に依存して種々の型の情報要素のサポートが必要となり得る。例えば同じアクセスネットワークの異なるＰｏＡに亘る水平ハンドオーバの場合には、アクセスネットワークの下位リンク層からの利用可能な情報で十分である可能性がある。このような場合、イントラテクノロジ近隣レポートのような情報要素およびハンドオーバ時に必要とされる他のリンク層情報は、アクセスネットワークから直接利用可能である。このような場合、ネットワークによって提供される上位層サービスの利用可能性は、異なるネットワーク所属ポイントに亘って目立つほどには変化しない可能性がある。
【００５３】
他方、垂直ハンドオーバ時には、アクティブなユーザープリケーションに関してサービスおよびセッションの連続性を可能にするために最適なリンク層接続性ならびに適切な上位層サービスの利用可能性の両者に基づいて新しいネットワーク内で適当なＰｏＡを選択する必要がある。
【００５４】
メディア独立情報サービス（ＭＩＩＳ）は、ハンドオーバのために必要な情報を取得するための能力を提供する。これは、近隣マップおよび他のリンク層パラメーターといった下位層に関する情報ならびにインターネット接続性、ＶＰＮサービスの利用可能性などといった利用可能な上位層サービスに関する情報を含む。ＭＩＩＳによって提供される異なる上位層サービスのセットは、絶え間なく進化することができる。同時に、ＭＩＩＳによってサポートされるアクセスネットワークのリストも進化し得る。そのようなものとして、ＭＩＩＳが異なる情報要素のサポートを提供する仕方には、柔軟性および拡張可能性の必要性が存在する。この目的のためにＭＩＩＳは、あるスキーマを定義する。このスキーマは、ＭＩＩＳのクライアントがＭＩＩＳの能力を発見し、また特定の実現形態によってサポートされる異なるアクセスネットワークとＩＥとのセット全体を発見するのを助ける。スキーマ表現はまた、モバイルノードがより柔軟で効率的な仕方で情報を問い合わせることを可能にする。このスキーマを定義することの一部としてＭＩＩＳはまた、ＭＩＩＳの異なる実現形態のコア機能を定義し得る１セットの基本的情報要素を識別し得る。他の情報要素は、それらが追加されると、ＭＩＩＳ能力の拡張されたセットの一部になり得る。
【００５５】
ＭＩＩＳは、８０２ネットワーク、３ＧＰＰネットワークおよび３ＧＰＰ２ネットワークといった異なるアクセスネットワークに関する情報を提供する。ＭＩＩＳはまた、この収集された情報がいかなる単一のネットワークからでもアクセスされることを可能にする。
【００５６】
したがって例えば８０２．１１アクセスネットワークを使用して、特定の地域内の他のすべての８０２ネットワークに関する情報ばかりでなく３ＧＰＰおよび３ＧＰＰ２ネットワークの情報も取得することが可能であり得る。同様に３ＧＰＰ２インターフェースを使用して、所定の地域内のすべての８０２および３ＧＰＰネットワークに関する情報を利用することが可能であり得る。この能力は、モバイルノードがその現在アクティブなアクセスネットワークを使用し、またある地理的地域内の他の利用可能なアクセスネットワークに関してスキャンすることを可能にする。このようにしてモバイルノードは、それの個別の無線通信の各々に電力供給し、そして異種ネットワーク情報にアクセスするという目的のためにネットワーク接続性を確立するという負担から解放される。ＭＩＩＳは、いかなる地理的領域においても異種ネットワーク情報を検索するための均一な仕方を提供することによって、すべての利用可能なアクセスネットワークに亘ってこの機能を使用可能にする。
【００５７】
情報サービス要素：
情報サービスの背後にある主要目標は、モバイルノードとネットワークエンティティとがハンドオーバ時の適当なネットワークの選択に影響を及ぼし得る情報を発見することを可能にすることである。この情報は、この情報に基づいて効果的なハンドオーバ意思決定を行い得る方策エンジンエンティティによって主に使用されるように意図されている。この情報サービスは、ネットワーク構成の変更が明らかにされなくてはならないにもかかわらず、大抵の静止型の情報を提供するように期待されている。現在利用可能なリソースレベル、状態パラメーター、動態統計などといった異なるアクセスネットワークに関する他の動的情報は、それぞれのアクセスネットワークから直接取得されるべきである。この情報サービスの背後にある主要な動機の幾つかは次の通りである：
１）ある地理的領域におけるアクセスネットワークの利用可能性に関する情報を提供する。更にこの情報は、任意の無線ネットワークを使用して検索され得るであろう、例えば近隣のＷｉＦｉホットスポットに関する情報は、要求／応答シグナリングによるか、あるいはこれらのセルラーネットワーク上で明確にまたは暗示的にブロードキャストされる情報によるかによって、ＧＳＭ、ＣＤＭＡ、または他の何らかのセルラーネットワークを使用して取得され得るであろう。代替としてこの情報は、ＭＮによって内部データベースに維持され得るであろう。
【００５８】
２）適当なアクセスネットワークを選択する際にモバイルデバイスを援助し得る静的リンク層情報パラメーターを提供する。例えば、セキュリティおよびＱｏＳがある特定のアクセスネットワーク上でサポートされているかどうかの知識は、ハンドオーバ時にこのようなアクセスネットワークを選択するための意思決定に影響を与え得る。
【００５９】
３）近隣レポートからなるリンク層情報および異なるＰｏＡの能力に関する情報もまた、利用可能な／選択されたアクセスネットワークに接続するために無線通信を最適に構成する際に助けとなり得るであろう。例えば異なるＰｏＡによってサポートされたチャネルに関する知識は、スキャン、ビーコンなどとは対照的に最適にチャネルを構成する際に、またこの情報を発見する際に助けとなり得る。しかしながらほとんどの部分に関して、アクセスネットワークとの直接的相互作用に基づいて動的リンク層パラメーターが取得または選択されなければならず、またこれに関してこの情報サービスはあまり助けとなり得ない可能性がある。
【００６０】
４）異なるアクセスネットワークによってサポートされる上位層サービスの指示とハンドオーバ意思決定時に助けとなり得る他の関連情報とを提供する。このような情報は、特定のアクセスネットワークのＭＡＣ／ＰＨＹ層から直接利用可能でない可能性がある（あるいは利用可能にされ得ない）が、情報サービスの一部として提供され得るであろう。例えばある幾つかの場合には、公共、企業、家庭、その他などといったカテゴリへの異なるネットワークの分類は、ハンドオーバ意思決定に影響を与え得る。ここでの他の情報は事実上、より販売業者／ネットワーク固有である可能性があり、またこの形式で指定され得るであろう。
【００６１】
情報サービス要素は、３つのグループに分類される：
１）一般的アクセスネットワーク情報：これらの情報要素は、利用可能なネットワークおよびそれらの関連オペレータのリストといったある領域内のカバレッジを与える異なるネットワークと、異なるオペレータ間のローミング契約と、ネットワークへの接続のコストと、ネットワークセキュリティおよびサービス品質の能力と、の一般的概要を与える。
【００６２】
２）所属ポイントに関する情報：これらの情報要素は、利用可能なアクセスネットワークの各々のための異なるＰｏＡに関する情報を提供する。これらのＩＥは、ＰｏＡアドレス指定情報、ＰｏＡ位置、サポートされるデータ転送速度、ＰＨＹおよびＭＡＣ層の型、およびリンク層接続性を最適化するための任意のチャネルパラメーターを含む。これはまた、上位層サービスと異なるＰｏＡの個別能力とを含む。
【００６３】
３）他の情報は、販売業者／ネットワーク固有である可能性があり、また適切に指定され得る。
【００６４】
メディア独立ハンドオーバプロトコル：
序論：
ＭＩＨは、下位層および上位層に関して明確なＳＡＰを介して非同期および同期サービスを提供する。提供されるサービスは、イベントサービス（ＥＳ）、コマンドサービス（ＣＳ）および情報サービス（ＩＳ）を含む。ＭＩＨサービスに関する詳細説明は、８０２．２１ドラフト文書に見出される。ＭＩＨ  ＳＡＰは、種々のＭＩＨＦサービスへのアクセスを取得するためにＭＩＨのユーザーによって使用されるＭＩＨ上位層ＳＡＰと、種々のメディア依存下位層リソースのアクセスと制御とを取得するためにＭＩＨＦによって使用されるＭＩＨ下位層ＳＡＰとを含む。
【００６５】
ＭＩＨプロトコルは、ピアＭＩＨＦエンティティ間でメッセージを交換するためのフレームフォーマットを定義する。これらのメッセージは、メディア独立イベントサービス、メディア独立コマンドサービスおよびメディア独立情報サービスの一部であるプリミティブに基づいている。ＩＥＥＥ８０２．２１は、モバイルノードおよびネットワークにおけるメディア独立ハンドオーバ機能をサポートする。ＭＩＨプロトコルは、ピアＭＩＨＦエンティティが互いに相互作用することを可能にする。
【００６６】
モバイルノードのＭＩＨＦエンティティがＭＩＨプロトコル手順を開始するためにモバイルノードのＭＩＨＦエンティティは、それのピアリモートＭＩＨＦエンティティを発見できる。ピアリモートＭＩＨＦエンティティは、モバイルノードのＭＩＨＦがＭＩＨプロトコルメッセージを交換する対応するＭＩＨＦエンティティである。ピアリモートＭＩＨＦエンティティはネットワークのどこかに常駐しているので、モバイルノードのＭＩＨＦエンティティはＭＩＨプロトコル手順を開始する前にネットワーク内のＭＩＨＦエンティティを発見できる。これは、ＭＩＨ機能発見手順を介して行われる。
【００６７】
ＭＩＨ機能発見は、レイヤー２またはレイヤー３のいずれかにおいて行われ得る。しかしながらこの文書は、両方のＭＩＨ機能が同じブロードキャストドメイン内に位置しているときにＭＩＨＦ機能発見がどのようにしてレイヤー２において実行されるかを指定しているだけである。ＭＩＨ機能発見は、ＭＩＨプロトコルを介して（すなわちＬＬＣといったＬ２カプセル化を使用して）またはメディア固有レイヤー２ブロードキャストメッセージ（すなわち８０２．１１ビーコン、８０２．１６ＤＣＤ）を介して実行され得る。レイヤー３におけるＭＩＨ機能発見は、８０２．２１の範囲外である。
【００６８】
ひとたびピアＭＩＨＦが発見されるとＭＮは、ピアＭＩＨＦの能力を発見できる。これは、ＭＩＨ能力発見手順を介して行われる。ＭＩＨ能力発見は、ＭＩＨプロトコルを介して、またはメディア固有レイヤー２ブロードキャストメッセージ（すなわち８０２．１１ビーコン、８０２．１６ＤＣＤ）を介して実行され得る。
【００６９】
ピアＭＩＨＦがＭＮと同じブロードキャストドメイン内に常駐しているとき、ＭＩＨ機能発見はＭＩＨ能力発見だけを使用して実行され得る。
【００７０】
例示的アーキテクチャ：
図１は、クライアントデバイスが通信する無線アクセスポイントを含むある幾つかの例示的かつ非限定的な実装に使用され得る、ある幾つかの例示的アーキテクチャ構成要素を示す。これに関して図１は、一般に２１で示された無線ローカルエリアネットワーク（ＷＬＡＮ）に接続された例示的有線ネットワーク２０を示す。ＷＬＡＮ２１は、アクセスポイント（ＡＰ）２２と多数のユーザー局２３、２４とを含む。例えば有線ネットワーク２０は、インターネットまたは企業内データ処理ネットワークを含み得る。例えばアクセスポイント２２は無線ルータであることが可能であり、ユーザー局２３、２４は例えば携帯型コンピュータ、卓上型パソコン、ＰＤＡ、ＶｏＩＰ携帯電話および／または他のデバイスであり得る。アクセスポイント２２は、有線ネットワーク２１にリンクされたネットワークインターフェース２５と、ユーザー局２３、２４と通信する無線トランシーバと、を有する。例えば無線トランシーバ２６は、ユーザー局２３、２５との通信のための無線周波数用またはマイクロ波周波数用のアンテナ２７を含み得る。アクセスポイント２２はまた、プロセッサ２８とプログラムメモリ２９とランダムアクセスメモリ３１とを有する。ユーザー局２３は、アクセスポイント局２２との通信のためのアンテナ３６を含む無線トランシーバ３５を有する。同様にユーザー局２４は、アクセスポイント２２との通信のための無線トランシーバ３８とアンテナ３９とを有する。例としてある幾つかの実施形態では、このようなアクセスポイント（ＡＰ）内ではオーセンティケータが使用され得る、および／またはモバイルノードあるいはユーザー局内ではサプリカントまたはピアが使用され得るであろう。
【００７１】
図２は、ある幾つかの実施形態において例えばアクセスポイント、ユーザー局、送信元ノードまたは宛て先ノードといったデバイスによって実行されるコンピュータ化されたプロセスステップを実行するために使用され得る、例示的コンピュータまたは制御ユニットを示す。ある幾つかの実施形態ではコンピュータあるいは制御ユニットは、バス３２６上で１セットの入力／出力（Ｉ／Ｏ）デバイス３２４と通信し得る中央演算処理装置（ＣＰＵ）３２２を含む。Ｉ／Ｏデバイス３２４は、例えばキーボード、モニターおよび／または他のデバイスを含み得る。ＣＰＵ３２２は、バス３２６上でコンピュータ可読媒体（例えば従来の揮発性または不揮発性データ記憶デバイス）３２８（以下、「メモリ３２８」）と通信できる。ＣＰＵ３２２、Ｉ／Ｏデバイス３２４、バス３２６およびメモリ３２８間の相互作用は、当技術において周知のものと同様である。メモリ３２８は、例えばデータ３３０を含み得る。メモリ３２８は、ソフトウェア３３８も記憶できる。ソフトウェア３３８は、プロセスのステップを実行するための多数のモジュール３４０を含み得る。これらのモジュールを実現するために従来のプログラミング技法が使用され得る。メモリ３２８はまた、上記および／または他のデータファイルを記憶し得る。ある幾つかの実施形態ではここで説明された種々の方法は、コンピュータシステムによる使用のためにコンピュータプログラム製品を介して実現され得る。この実現形態は、例えばコンピュータ可読媒体（例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭなど）に記憶された、あるいはモデムなどといったインターフェースデバイスを介してコンピュータシステムに伝送可能な一連のコンピュータ命令を含み得る。通信媒体は、実質的に有形（例えば通信ライン）および／または実質的に無形（例えばマイクロ波、光、赤外線などを使用する無線媒体）であり得る。コンピュータ命令は、種々のプログラミング言語で書かれ得る、および／または半導体デバイス（例えばチップまたは回路）、磁気デバイス、光デバイスおよび／または他のメモリデバイスといったメモリデバイスに記憶され得る。種々の実施形態において伝送手段は、適当ないかなる通信技術でも使用できる。
【００７２】
一般的な背景文献：  
以下の一般的な背景出願を参照する（そのような出願はさらにここで参照することによって背景参照に関する全ての以下の特許出願の全開示を組み込む）。
【００７３】
１）K. Taniuchiらの２００７年２月２３日提出の米国仮出願第６０／８９１，３４９号；  
２）Y. A. Chengらの２００６年９月１３日提出の米国仮出願第６０／８２５，５６７号；  
３）Y. Obaらの２００６年１２月５日提出の米国出願第１１／５６７，１３４号；  
４）Y. Obaらの２００６年１１月２３日提出の米国出願第１１／５６３，０００号；  
５）Y. Obaらの２００６年１１月１２日提出の米国出願第１１／５５８，９２２号；  
６）Y. Obaらの２００６年７月２７日提出の米国出願第１１／４６０，６１６号；  
７）A. Duttaらのメディア独立事前認証の改善フレームワークと題された２００６年４月１４日提出の米国出願第１１／２７９，８５６号；  
８）スイッチングの失敗とスイッチバックに関する考慮（Considerations For Failed Switching And Switchback）を含んでいること；  
９）Y. ObaらのPANAに関するメディア独立事前認証サポートのフレームワークと題された２００６年３月９日提出の米国出願第１１／３０８，１７５号；  
１０）A. Duttaらのメディア独立事前認証のフレームワークと題された２００６年２月提出の米国出願第１１／３０７，３６２号；  
１１）Y. Oba, et al.らの２００８年５月１２日提出の米国出願第１２／１１９，０４８号；  
上記のとおり、ハンドオーバのためのメディア独立のソリューションは、異種ネットワーク間のセキュリティシグナリング要件の問題に対処していない。異種メディアをサポートするネットワーク間にアタッチするモバイルノード（ＭＮ）がハンドオーバを安全に行うために、モバイルノードと候補ネットワーク（ターゲットネットワーク）との間の認証(authentication)、許可(authorization)、および秘密性(confidentiality)が必要とされる。しかしながら、セキュリティ関連のシグナリングの追加は、ハンドオーバ動作の際の大幅な遅延をもたらす可能性がある。これは、インターネットや他のパケット交換方式のネットワークのようなＩＰネットワークによる音声情報配信のためのVoice over Internet Protocol (VoIP)といった時間的制約のあるアプリケーションに影響を及ぼし得る。その多くの場合、サービス品質（ＱｏＳ）への影響からサービスの継続性はもはや満たされず、最終的にはユーザエクスペリエンスに多大な影響を及ぼす。
【発明の概要】
【００７４】
ある例示的実施形態において、メディア独立ハンドオーバプロトコルへのセキュリティ関連のシグナリングの追加に起因するサービス品質およびユーザエクスペリエンスへの悪影響の問題は、プロアクティブ認証技術およびＭＩＨプロトコル・レベル・セキュリティ機構によって、特にハンドオーバ中のセキュリティ関連シグナリングを最適化することにより解決される。
【００７５】
この出願の一態様において、システムは、メディアに固有のリンクの終端にインターフェースを介してアタッチされた他のエンティティを認証するメディア独立認証機能を含むメディア独立アクセス機能を有しているサーバを含む。複数の異機種ネットワークの各々は、前記メディアに固有の前記リンクの前記終端に前記インターフェースを介してアタッチされた他のエンティティに対応する認証機能メディア固有アクセス機能を含んでおり、モバイルデバイスは、前記複数の異種ネットワークに接続され、前記サーバは、ハンドオーバに関するメディア独立機能に基づく所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーを有し、前記サーバは、サービングアクセスネットワークから、候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークを認証し、前記候補アクセスネットワークの各々は、前記メディアに固有の前記リンクを有する前記複数の異種アクセスネットワークに属する。
【００７６】
この出願の別の態様において、製品は、プロセッサが、異種メディア間でアタッチされたモバイルデバイスをメディア独立オーセンティケータによってプロアクティブに認証する動作を実行可能にするための命令がコード化されたマシンアクセス可能な媒体を具備し、複数の異種アクセスネットワーク内のサービングアクセスネットワークにアタッチされたモバイルデバイスにメディア固有認証手続きを割り当てること；前記メディア独立オーセンティケータを介して候補アクセスネットワークに関する情報をハンドオーバ準備段階でモバイルデバイスに提供すること；インターフェースを用いて、プロアクティブ認証を行なうこと；前記メディア独立オーセンティケータを介して前記プロアクティブ認証が正常に行なわれると、前記メディア固有認証手続きを有する候補アクセスネットワークへのハンドオーバを実行すること、を具備する。
【００７７】
この出願のさらに別の態様において、メディア独立アクセス機能を実装したコンピュータを有する装置は、異種メディア間でアタッチされたモバイルデバイスを認証する独立オーセンティケータと；各々が固有のサービングメディアに対応する固有のオーセンティケータをサポートする複数の異種アクセスネットワークに前記独立オーセンティケータを接続するインターフェースと；前記コンピュータの前記メディア独立機能に基づいた所定のメディア独立ハンドオーバプロトコルおよびメディア独立ハンドオーバ・アイデンティティーとを具備し、前記独立オーセンティケータは、サービングアクセスネットワークから、固有のサービングメディアを持つ複数の異種アクセスネットワークに属する候補アクセスネットワークへの前記モバイルデバイスのハンドオーバに先立って前記候補アクセスネットワークを認証する。
【００７８】
種々の実施形態の上記および／または他の態様、特徴および／または利点は、添付の図に関連して下記の説明を考慮することによって更に理解されるであろう。種々の実施形態は、適用可能の場合に、異なる態様、特徴および／または利点を含み得る、および／または除外し得る。更に種々の実施形態は、適用可能の場合に他の実施形態の１つ以上の態様または特徴を組み合わせることができる。特定の実施形態の態様、特徴および／または利点の説明は、他の実施形態または特許請求の範囲を限定するものと解釈されるべきではない。
【図面の簡単な説明】
【００７９】
本発明の実施形態の上記および他の特徴および利点は、以下の添付の図面に関しての典型的な実施形態について詳細に記述することによってより明白になるだろう：
【図１】図１は、クライアント装置が通信する無線アクセスポイントを含むいくつかの実例となり制限しない実装で使用することができるいくつかの実例となるアーキテクチャ上のコンポーネントを示す；
【図２】図２は、装置（例えば、いくつかの実施形態でのソースノード、デスティネーションノード、アクセスポイント、あるいはユーザー局）によって実行されるために、コンピュータ化されたプロセスステップを実装するために用いることができる実例となるコンピュータまたは制御ユニットを示す；
【図３】図３は、認証関連セキュリティシグナリングがいくつかの実施形態で実現されうるＩ．Ｅ．Ｅ．Ｅ８０２．２１の規格で開示されるような実例となるメディア独立ハンドオーバ機能通信モデルである；
【図４】図４は、認証関連セキュリティシグナリングがいくつかの実施形態で実現されうるメディア独立ハンドオーバサービス通信モデルを持ったネットワークモデルの例である；
【図５】図５は、ダイレクトプロアクティブ認証シグナリングの間に、異なる機能エンティティとそれらの関与との間の関係を示す；
【図６】図６は、非ダイレクトプロアクティブ認証シグナリングの間に、異なる機能エンティティとそれらの関与との間の関係を示す；
【図７】図７は、２つのアクセスネットワークが１つのメディア独立したオーセンティケータおよびキーホルダーによって管理される場合、プロアクティブ認証用の実例となる論理的なアーキテクチャを示す；
【図８】図８は、２つのアクセスネットワークが２つの個別のメディア独立オーセンティケータおよびキーホルダーによって管理される場合、プロアクティブ認証用の実例となる論理的なアーキテクチャを示す；
【図９】図９は、ＭＮと、ネットワーク主導のダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間での複数のメッセージフローを示す；
【図１０】図１０は、ＭＮと、モバイル主導のダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１１】図１１は、ＭＮと、ネットワーク主導の非ダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１２】図１２は、ＭＮと、モバイル主導の非ダイレクトプロアクティブ認証（ＥＡＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１３】図１３は、ＭＮと、ネットワーク主導のダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１４】図１４は、ＭＮと、モバイル主導のダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１５】図１５は、ＭＮと、ネットワーク主導の非ダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１６】図１６は、ＭＮと、モバイル主導の非ダイレクトプロアクティブ認証（ＥＲＰ）に関するメディア独立したオーセンティケータ（Media independent authenticator）との間でのメッセージフローを示す；
【図１７】図１７は、ＭＮと、ターゲットＭＳＡ−ＫＨと、ターゲットＭＩＡ−ＫＨとの間でのコールフローを示す；
【図１８】図１８は、ネットワーク主導およびモバイル主導両方のダイレクト終了手続に関するコールフローを示す；
【図１９】図１９は、ネットワーク主導およびモバイル主導両方の非ダイレクト終了手続に関するコールフローを示す。
【発明を実施するための形態】
【００８０】
本発明は多くの異なる形で具現され得るが、本開示が本発明の原理の例を提供するものと考えられるべきであることと、このような例が本発明を本明細書に説明された、および／または本明細書に図解された好適な実施形態に限定するようには意図されていないということとの理解の下で、多数の例示的実施形態が本明細書において説明される。
【００８１】
用語（Terminologies）：  
ＥＡＰ：Extensible Authentication Protocol 拡張認証プロトコル
ＥＲＰ：EAP Re-Authentication Protocol ＥＡＰ再認証プロトコル
ＳＡ：Serving Authenticator サービングオーセンティケータ
ＣＡ：Candidate Authenticator 候補オーセンティケータ
定義（Definitions）：  
認証プロセス（Authentication Process）：暗号処理および認証を行うデータフレームのサポート。
【００８２】
メディア固有オーセンティケータおよび鍵ホルダ（Media Specific Authenticator and Key Holder）（ＭＳＡ−ＫＨ）：メディア固有オーセンティケータおよび鍵ホルダは、メディアに特有のリンクの他端にアタッチされた他のエンティティの認証を促進するエンティティである。
【００８３】
メディア独立オーセンティケータおよび鍵ホルダ（Media Independent Authenticator and Key Holder）（ＭＩＡ−ＫＨ）：メディア独立したオーセンティケータおよび鍵ホルダは、ＭＳＡ−ＫＨと相互作用し、かつＭＳＡ−ＫＨのリンクの他端にアタッチされた他のエンティティのプロアクティブ認証を促進するエンティティである。
【００８４】
プロアクティブ認証（Proactive Authentication）：ＭＳＡ−ＫＨのリンクの他端にアタッチされる他の複数のエンティティと、ＭＩＡ−ＫＨとの間で行なわれる認証プロセス。他の複数のエンティティが別のリンクへのハンドオーバを行なおうとする場合、このプロセスが発生する。
【００８５】
サービングＭＩＡ−ＫＨ（Serving MIA-KH）：アクセスネットワークにアタッチされるモバイルノードに現在サービスしているＭＩＡ＿ＫＨ。
【００８６】
候補ＭＩＡ−ＫＨ（Candidate MIA-KH）：モバイルノードの、潜在的な複数の候補アクセスネットワークのリストに載っているアクセスネットワークにサービスするＭＩＡ−ＫＨ。
【００８７】
ＭＩＨセキュリティアソシエーション（MIH Security Association）（ＳＡ）：ＭＩＨ ＳＡは複数のピアＭＩＨエンティティ間でのセキュリティアソシエーションである。
【００８８】
参考文献（References）  
次の参考文献のそれぞれ全ては、背景参照に関するそれらの全体におけるこの開示において参照によってここに組み込まれる：
［ＲＦＣ４７４８］H. Levkowetz, Ed. and et al, Extensible Authentication Protocol (EAP), RFC 3748；
［ＲＦＣ５２９６］V. Narayan and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)" RFC 5296； 
［ＲＦＣ４３０６］C. Kaufman, Ed, "Internet Key Exchange (IKEv2) Protocol:", RFC 4306；
［ＲＦＣ５２４６］T. Dierks and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246；
［ＲＦＣ４３４７］E. Rescorla and N. Modadugu, "Datagram Transport Layer Security", RFC 4347；
［ＲＦＣ５２９５］J. Saloway, et al, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)" RFC 5295；および
［ＩＥＥＥ８０２．２１］IEEE P802.21 Std-2008, IEEE Standard for Local and Metropolitan Area Networks- Part 21: Media Independent Handover Services. 
プロアクティブ認証（Proactive Authentication）  
プロアクティブ認証は、メディア独立のオーセンティケータおよび候補ネットワークをサービスしている鍵ホルダ（ＭＩＡ−ＫＨ）により、アプリオリなネットワークアクセス認証をエンティティが行なうことができるプロセスである。エンティティは近隣のネットワークへのハンドオーバを予期してそのような認証を行なう。プロアクティブ認証は２つの方法で行なうことができる：ｉ）認証シグナリングがサービングＭＩＡ−ＫＨにトランスペアレントであるダイレクトプロアクティブ認証（図５）と、ｉｉ）サービングＭＩＡ−ＫＨが認証シグナリングを承知している非ダイレクトプロアクティブ認証（図６）。それぞれの場合において、ＥＡＰ（Extensible Authentication Protocol、拡張認証プロトコル）［ＲＦＣ４７９８］あるいはＥＲＰ（EAP Re-Authentication Protocol、ＥＡＰ再認証プロトコル）［ＲＦＣ５２９６］のいずれかを、認証プロトコルとして用いることができる。
【００８９】
図５および図６は、プロアクティブ認証シグナリング中に異なる機能エンティティの間の関係と、プロアクティブ認証シグナリング中のそれらの関与とを示す。ダイレクトプロアクティブ認証については、モバイルノードは、候補ＭＩＡ−ＫＨと直接通信する（図５）。また、非ダイレクトプロアクティブ認証については、モバイルノードは最初にサービングＭＩＡ−ＫＨと通信する。その後、サービングＭＩＡ−ＫＨはモバイルノードの代わりに、候補ＭＩＡ＿ＫＨと通信する。
【００９０】
プロアクティブ認証アーキテクチャ（Proactive Authentication Architecture）
図７および図８での典型的な実施形態は、プロアクティブ認証用の２つの例の論理的なアーキテクチャを描いている。メディア独立したオーセンティケータおよび鍵ホルダ（ＭＩＡ−ＫＨ、Media Independent Authenticator and Key Holder）は、複数の候補ネットワークへのハンドオーバに先立って、認証を円滑にするエンティティである。このアーキテクチャでは、複数の認証機能はメディア独立ハンドオーバ機能（ＭＩＨＦ、Media Independent Handover Function）内に加えられる。また、新しいエンティティは向上されたＰＯＳ（例えばＰｏＳ＋）として呼ばれる。
【００９１】
メディア固有オーセンティケータおよび鍵ホルダ（ＭＳＡ−ＫＨ、Media Specific Authenticator and key holder）は、特定のアクセスネットワークへのアクセス用の認証装置に関与している。また、提案されたアーキテクチャは、そのような既存の機構を変更しないと仮定する。図７と図８との間の差は、図７では、２つのアクセスネットワークが１つのＭＩＡ−ＫＨによって管理され、したがって１つのＰｏＳが存在するが、一方図８では、それぞれのアクセスネットワークがそれら自身のＭＩＡ−ＫＨを有していてしたがって２つの別個のＰｏＳが必要である。図８にはさらにＭＩＨ通信モデルについてＲＰ５と呼ばれる１つの追加のインターフェースがある［ＩＥＥＥ Ｓｔｄ ８０２．２１．２００８］。
【００９２】
この開示は、ネットワーク主導およびモバイル主導の手続を含む、ダイレクトおよび非ダイレクトのプロアクティブ認証の両方をサポートする。動作のシーケンスは次のものを含んでいる：
−ＭＮはアクセス固有認証手続でアクセスネットワークにアタッチする；
−ハンドオーバ準備段階の間に、ＭＮは候補オーセンティケータを発見する；
−メディア独立したオーセンティケータの到達可能性に依存して、ＭＮは、ＲＰｌインターフェースを用いて、ダイレクトまたは非ダイレクトのいずれかのプロアクティブ認証を行なう；
−一旦メディア独立した認証が成功して行なわれれば、複数のメディア固有鍵はＭＳＡ−ＫＨへプッシュされるか、あるいはＭＳＡ−ＫＨからプルされる。Ｉｎｔｅｒｆａｃｅ＿ＭＩＡ−ＫＨ−ＭＳＡ−ＫＨはこの動作を行なうために用いられる；
−ＭＮは、メディア固有セキュアアソシエーション（例えば８０２．１１に関する４方向のハンドシェイク）を行なうことにより、ハンドオーバを実行し、さらにターゲットとして知られている候補ネットワークのうちの１つへアタッチする；そして
−接続確立の後、ＭＮはＰｏＳで再登録する。
【００９３】
次の仮定は、このセクションの残りにわたってなされる：
仮定（Assumptions）  
−オーセンティケータはＭＩＨ ＰｏＳである；
−ＭＩＨプロトコルはＥＡＰとＥＲＰを運ぶために用いられる；
−ＭＮのＭＩＨＦ−ＩＤはＭＮのメディア独立アイデンティティーとして用いられる；
−オーセンティケータのＭＩＨＦ−ＩＤはオーセンティケータのメディア独立アイデンティティーとして用いられる；
−メディア独立したオーセンティケータ（Media Independent Authenticator）は、ＥＡＰによって生成されたｒＭＳＫ（再認証ＭＳＫ）あるいはＭＳＫ(Master Session Key)（マスターセッション鍵）を保持する；
−ＭＳＫまたはｒＭＳＫはメディア独立した対のマスター鍵（ＭＩ−ＰＭＫ）を導き出すために用いられる；および
−ＭＮがターゲットＭＳＡ−ＫＨにハンドオーバし、かつそれがターゲットＭＳＡ−ＫＨに関するＭＩ−ＰＭＫから導き出されたメディア固有ＰＭＫ（ＭＳ−ＰＭＫ）を有する場合、それはＭＳ−ＰＭＫを用いて、メディア固有のセキュアアソシエーションを実施する。
【００９４】
ＥＡＰを用いたプロアクティブ認証（Proactive Authentication using EAP）  
このセクションはプロアクティブ認証プロトコルとしてＥＡＰを用いる手続きについて説明する。
【００９５】
ダイレクトプロアクティブ認証（Direct Proactive Authentication）  
このシナリオでは、ＭＮは、メディア独立候補オーセンティケータで、認証を直接的に行なう。ここでの仮定はＭＮが、候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかである。候補オーセンティケータは、ＩＰリンクを介してＭＮから直接到達可能でなければならない。
【００９６】
コールフロー（Call Flows）  
図９は、ネットワーク主導のダイレクトプロアクティブ認証に関して、ＭＮとメディア独立オーセンティケータとの間の複数のメッセージフローを説明する。それは例Ａおよび例Ｂのアーキテクチャの両方をカバーする。例Ｂアーキテクチャでは、サービングＭＩＡ−ＫＨ（Serving MIA-KH）および複数の候補ＭＩＡ−ＫＨオーセンティケータは、２つの別個のエンティティであり、またそれらは、互いに通信するためにインターフェースＲＰ５を用いる。２つの新しいＭＩＨメッセージタイプ：ｉ）ＭＩＨ Ｐｒｏ＿Ａｕｔｈリクエスト（ＥＡＰ）メッセージおよびｉｉ）ＭＩＨ Ｐｒｏ＿Ａｕｔｈ応答メッセージは、ＭＩＨ上の複数のＥＡＰメッセージを伝えるために提案されている。最初のＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージは、ＭＮからのＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージが続くＥＡＰ＿Ｉｄｅｎｔｉｔｙ＿Ｒｅｑｕｅｓｔメッセージを伝えるネットワークによって開始される。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤーアイデンティティーで複数の鍵を安全に結びつけるために、最終リクエスト／応答メッセージにおいて必要である。
【００９７】
図１０は、モバイル主導のプロアクティブ認証に関して、ＭＮと、メディア独立したオーセンティケータとの間の複数のメッセージフローを説明する。以前のものとの重要な差は、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔを生成し、かつそれを候補オーセンティケータに直接送るＭＮからトリガーが来るということである。残りのコールフローは、図９に説明されるようなネットワーク主導のダイレクトプロアクティブ認証に似ている。
【００９８】
非ダイレクトプロアクティブ認証（Indirect Proactive Authentication）  
このシナリオではＭＮは、メディア独立候補オーセンティケータで、認証を直接行なうことができない。サービングオーセンティケータは、ＭＮ（ネットワーク主導認証の場合）、または候補ＭＩＡ−ＫＨ（モバイル主導認証の場合）のどちらかへ向けて、複数のメッセージを転送することに参加する。ここでの仮定は、ＭＮが候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかであるが、ＭＮは候補オーセンティケータにＩＰリンクを介して直接到達することはできない。
【００９９】
コールフロー（Call Flows）  
図１１は、ネットワーク主導の非ダイレクトプロアクティブ認証に関して、ＭＮと、複数のメディア独立オーセンティケータとの間での複数のメッセージフローを説明する。以前に説明されているように、それは例Ａおよび例Ｂのアーキテクチャの両方をカバーする。また、例Ｂのアーキテクチャでは、サービングＭＩＡ−ＫＨおよび候補ＭＩＡ−ＫＨのエンティティは、２つの別個のエンティティである。またそれらは、互いに通信するためにインターフェースＲＰ５を用いる。最初のＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージは、候補ＭＩＡ−ＫＨによって始められ、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにそれを送った。
【０１００】
ＭＮはＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを生成し、続く複数のＥＡＰメッセージはリクエストおよび応答のメッセージに関して運ばれる。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤーアイデンティティーを鍵に安全に設定するために用いられる。
【０１０１】
図１２は、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージを生成し、サービングＭＩＡ−ＫＨにそれを送るＭＮからトリガーが来る、モバイル主導の非ダイレクトプロアクティブ認証を描いている。候補ＭＩＡ−ＫＨは、サービングＭＩＡ−ＫＨからこのメッセージを受信し、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを送る。
【０１０２】
残りのコールフローは、図１１で説明されるようなネットワーク主導の非ダイレクトプロアクティブ認証に似ている。
【０１０３】
ＥＲＰを使用するプロアクティブ認証（Proactive Authentication using ERP）  
このセクションはプロアクティブ認証プロトコルとしてＥＲＰを用いる手続きについて説明する。
【０１０４】
ダイレクトプロアクティブ認証（Direct Proactive Authentication）  
このシナリオではＭＮは、メディア独立候補オーセンティケータで、認証を直接行なう。ここでの仮定はＭＮが、候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかである。候補オーセンティケータは、ＩＰリンクを介してＭＮから直接到達可能でなければならない。
【０１０５】
コールフロー（Call Flows）  
図１３は、ネットワーク主導のダイレクトプロアクティブ認証に関して、ＭＮとメディア独立オーセンティケータとの間の複数のメッセージフローを示す。それは例Ａおよび例Ｂのアーキテクチャの両方をカバーし、例Ｂのアーキテクチャでは、サービングＭＩＡ−ＫＨ（Serving MIA-KH）および複数の候補ＭＩＡ−ＫＨオーセンティケータは、２つの別個のエンティティであり、またそれらは、互いに通信するためにインターフェースＲＰ５を用いる。ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｉｎｄｉｃａｔｉｏｎと呼ばれる新しいＭＩＨメッセージタイプが、ＭＩＨ上での複数のＥＲＰメッセージ交換を開始するために提案されている。これは、ＭＮを始動させ、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔ（ＥＲＰ）メッセージを生成する。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤーアイデンティティーを複数の鍵に安全に設定するために、リクエスト／応答メッセージにおいて必要である。
【０１０６】
図１４は、モバイル主導のプロアクティブ認証に関して、ＭＮと、メディア独立したオーセンティケータとの間の複数のメッセージフローを示す。以前のものとの主な差は、ＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔを生成し、かつそれを候補オーセンティケータに直接送るＭＮからトリガーが来るということである。最後に、候補ＭＩＡ−ＫＨは、認証成功または失敗を有するＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅを送る。
【０１０７】
非ダイレクトプロアクティブ認証（Indirect Proactive Authentication）  
このシナリオではＭＮは、メディア独立候補オーセンティケータで、認証を直接行なうことができない。サービングオーセンティケータは、ＭＮ（ネットワーク主導認証の場合）、または候補ＭＩＡ−ＫＨ（モバイル主導認証の場合）のどちらかへ向けて、複数のメッセージを転送することに参加する。ここでの仮定は、ＭＮが候補オーセンティケータを知るかまたはＭＩＨ情報サービス（MIH Information Service）を介して発見するかのいずれかであるが、ＭＮは候補オーセンティケータにＩＰリンクを介して直接到達することはできない。
【０１０８】
コールフロー（Call Flows）  
図１５は、ネットワーク主導の非ダイレクトプロアクティブ認証に関して、ＭＮと、複数のメディア独立オーセンティケータとの間での複数のメッセージフローを示す。最初のＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージは、候補ＭＩＡ−ＫＨによって始められ、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにそれを送った。ＭＮはＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを生成し、続く複数のＥＡＰメッセージはリクエストおよび応答のメッセージに関して運ばれる。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤーアイデンティティーを鍵に安全に設定するために用いられる。
【０１０９】
図１６は、ＥＲＰを有するＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージを生成し、サービングＭＩＡ−ＫＨにそれを送るＭＮからトリガーが来る、モバイル主導の非ダイレクトプロアクティブ認証を示す。候補ＭＩＡ−ＫＨは、サービングＭＩＡ−ＫＨからこのメッセージを受信し、その後、ＭＮへ転送されるサービングＭＩＡ−ＫＨにＥＲＰを有するＭＩＨ Ｐｒｏ＿Ａｕｔｈ Ｒｅｓｐｏｎｓｅメッセージを送る。ＰｏＡ−Ｌｉｎｋ−Ａｄｄｒ−ＬｉｓｔおよびＭＮ−Ｌｉｎｋ−Ａｄｄｒ−Ｌｉｓｔは、リンクレイヤーアイデンティティーを複数の鍵に安全に設定するために、リクエスト／応答メッセージにおいて必要である。
【０１１０】
ターゲットオーセンティケータへのアタッチメント（Attachment to Target Authenticator）  
認証が行なわれ、かつモバイルノードがハンドオーバを実行することを決定した後に、それは複数の候補ネットワークのうちの１つを選択し、そのアクセスネットワークに切り替える。この候補ネットワークはターゲットネットワークになり、このアクセスネットワークにサービスするオーセンティケータは、ターゲットメディア固有オーセンティケータおよび鍵ホルダ（ＭＳＡ−ＫＨ）と呼ばれる。その後、ターゲットＭＳＡがモバイルノードに関してターゲットメディア独立オーセンティケータおよび鍵ホルダ(MIA-KH)から鍵の正しいセットを得たと仮定して、モバイルノードはメディア固有セキュアアソシエーション（ＳＡ）を行う。
【０１１１】
コールフロー（Call Flows）  
図１７は、ＭＮとターゲットＭＳＡ−ＫＨとターゲットＭＩＡ−ＫＨとの間のコールフローを描く。一旦プロアクティブ認証が成功して行なわれれば、ＭＩＡ−ＫＨは、ＭＳＡ−ＫＨへプッシュされるか、ＭＳＡ−ＫＨによってプルされることができる複数のモバイルノードメディア固有鍵につき生成する。一旦複数の鍵がＭＳＡ−ＫＨで利用可能ならば、モバイルノードは、十分な認証を行う必要がなしにネットワークへそれが切り替えるとすぐに、メディア固有セキュリティアソシエーションを行うことができる。一旦セキュアアソシエーションが成功し、かつＩＰ接続が確立されれば、ＭＮは、ＭＩＡ−ＫＨが正確にモバイルノードをそのサービングノードとして登録するために、ＭＩＡ−ＫＨを登録する。
【０１１２】
プロアクティブ認証終了（Proactive Authentication Termination）  
プロアクティブ認証終了の目的は、モバイルノードおよび候補／ターゲット／サービングのオーセンティケータがセッションを終了し、対応の複数の状態マシンが同期されることを保証することである。この時点で、ＭＩ−ＰＭＫおよびＭＳ−ＰＭＫはキャッシュされるかまたは削除されるかのいずれかである。
【０１１３】
ダイレクトプロアクティブ認証終了（Direct Proactive Authentication Termination）  
ダイレクトプロアクティブ認証終了は、ネットワークおよびモバイルのノードの両方が認証状態を直接終了することを可能にする。
【０１１４】
コールフロー（Call Flows）  
図１８は、ネットワーク主導およびモバイル主導の終了手続の両方に関するコールフローを示す。保全性チェック（インテグリティチェック、integrity check）を含む目的は、終了のリクエストおよび応答の信頼性を確認することである。
【０１１５】
非ダイレクトプロアクティブ認証終了（Indirect Proactive Authentication Termination）  
非ダイレクトプロアクティブ認証終了は、ネットワークとモバイルノードの両方がサービングＭＩＡ−ＫＨを介して認証状態を終了することを可能にする。
【０１１６】
コールフロー（Call Flows）  
図１９は、ネットワーク主導およびモバイル主導の終了手続の両方に関するコールフローを示す。保全性チェックを含むことの目的は、終了のリクエストおよび応答の信頼性を確認することである。両方の場合では、サービングＭＩＡ−ＫＨは、終了リクエストを、ＭＮまたは候補ＭＩＡ−ＫＨのいずれかへ転送する。
【０１１７】
プリミティブ（Primitives）  
このセクションは、プロアクティブ認証を可能にするために要求されるプリミティブおよび対応するパラメーターを概説する。
【０１１８】
イベントプリミティブ（Event Primitives）  
テーブル１は、複数のリンクイベントのリストを示す。
【０１１９】
テーブル１：イベントプリミティブのリスト（List of Event Primitives）
【表１】
0005694296.tif 000002
【０１２０】
Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿ｋｅｙ＿Ｉｎｓｔａｌｌ．ｉｎｄｉｃａｔｉｏｎ  
機能：レイヤー２接続の確立が、サービスプリミティブの指定されたリンクインターフェースセマンティックス（Semantics）上で試みられる場合、この通知が配信される。
【０１２１】
Link_Pro_Auth_key_Install.indication  （
Linkldentifler
）
パラメーター（Parameters）:
【表２】
0005694296.tif 000003
【０１２２】
生成された場合（When generated）  
指定されたリンクインターフェースに関してあるいは成功したプロアクティブ認証の完成の後に、レイヤー２接続が確立される場合、この通知が生成される。
【０１２３】
受信の影響（Effect of Receipt）  
ＭＩＨＦは、この通知をサブスクライブしている（複数の）ＭＩＨユーザーにこのリンク通知を渡すものとする。（複数の）ＭＩＨユーザーは複数のメディア固有鍵をプッシュまたはプルする。
【０１２４】
ＭＩＨイベント（MIH Events）  
テーブル２はＭＩＨイベントのリストを説明する。
【０１２５】
テーブル２：ＭＩＨイベントのリスト（List of MIH Events）
【表３】
0005694296.tif 000004
【０１２６】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｓｕｌｔ．ｉｎｄｉｃａｔｉｏｎ  
機能：ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｓｕｌｔは、ローカルイベントを彼らに通知するために、複数のローカルＭＩＨＦユーザーに送られるか、またはこの遠隔イベントにサブスクライブしている複数の遠隔ＭＩＨＦユーザーに示すためにＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｑｕｅｓｔメッセージの受信の結果である。
【０１２７】
サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Result.indication (
Sourceldentifier
Mobilenodeldentifier
Candidateldentifier(Optional)
MobileLinkldentifiers
PoALinkldentifiers
Status
)
パラメーター（Parameters）:
【表４】
0005694296.tif 000005
【０１２８】
生成された場合（When Generated）  
このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｒｅｑｕｅｓｔメッセージが受信された場合に、ローカルまたは遠隔のＭＩＨＦによって生成される。
【０１２９】
受信への影響（Effect on Receipt）  
ＭＩＨＦは、この通知をサブスクライブした（複数の）ＭＩＨユーザーへこのリンク通知を渡すものとする。
【０１３０】
コマンドプリミティブ（Command Primitives）  
テーブル３はＭＩＨコマンドについて説明する。
【０１３１】
テーブル３：ＭＩＨコマンドのリスト（List of MIH Commands）
【表５】
0005694296.tif 000006
【０１３２】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｑｕｅｓｔ  
機能：プリミティブは、プロアクティブ認証のその意図についてローカルＭＩＨＦあるいはピアＭＩＨユーザーに示すために、ＭＩＨユーザー（MIH User）によって呼び出される。
【０１３３】
サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Start.request ( 
Destinationldentifier,
MobileNodeldentifier(Optional)
Candidateldentifier(Optional)
)
パラメーター（Parameters）：
【表６】
0005694296.tif 000007
【０１３４】
生成される場合（When Generated）  
このプリミティブは、プロアクティブ認証のその意図についてのローカルＭＩＨＦまたは遠隔のＭＩＨユーザーと通信するために、ＭＩＨユーザーによって呼び出される。
【０１３５】
受信への影響（Effect on Receipt）  
このプリミティブの受信に際して、ローカルＭＩＨＦは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージを生成し、かつデスティネーション識別子（Destination Identifier）によって識別される遠隔のＭＩＨＦへ送信する。遠隔のＭＩＨＦはＭＩＨユーザー（MIH User）へ指示としてリクエストを転送する。
【０１３６】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｉｎｄｉｃａｔｉｏｎ  
機能：このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ Ｒｅｑｕｅｓｔメッセージが遠隔ＭＩＨＦから受信されたＭＩＨユーザー（MIH User）に示すために、ＭＩＨＦによって用いられる。
【０１３７】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
MIH_Pro_Auth_Start.indication ( 
Sourceldentifier,
MobileNodeldentifier 
Candidateldentifier 
)
パラメーター（Parameters）:
【表７】
0005694296.tif 000008
【０１３８】
生成される場合（When Generated）  
このプリミティブは、ピアＭＩＨＦからＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｑｕｅｓｔメッセージを受信することについてＭＩＨＦによって生成される。
【０１３９】
受信への影響（Effect on Receipt）  
この指示を受信するＭＩＨユーザー（MIH User）は、リクエストメッセージでのソース識別子（Source Identifier）によって示される遠隔ＭＩＨＦへのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｓｐｏｎｓｅプリミティブを呼び出すものとする。
【０１４０】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｓｐｏｎｓｅ  
機能：このプリミティブは、ネットワークでの遠隔ＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｑｕｅｓｔメッセージへ応答するために、ＭＮでのＭＩＨＦによって使用される。
【０１４１】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
MIH_Pro_Auth_start.response ( 
Destinationldentifier, 
MobileNodeldentifier (Optional), 
Candidateldentifier (optional), 
Status, 
)
パラメーター（Parameters）:
【表８】
0005694296.tif 000009
【０１４２】
生成される場合（When Generated）  
遠隔のＭＩＨユーザー（MIH User）は、そのＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｒｅｓｐｏｎｓｅメッセージに応答してこのプリミティブを呼び出す。
【０１４３】
受信への影響（Effect on Receipt）  
ＭＩＨＦは、デスティネーション識別子に示されるピアＭＩＨＦへＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｓｐｏｎｓｅメッセージを送信する。
【０１４４】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｓｔａｒｔ．ｃｏｎｆｉｒｍ  
機能：このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｓｐｏｎｓｅメッセージがピアＭＩＨＦから受信されたことを確認するためにＭＩＨＦによって用いられる。
【０１４５】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
MIH_Pro_Auth_Start.confirm( 
Sourceldentifier, 
MobileNodeldentifier(Optional), 
Candidateldentifier(Optional), 
Status, 
)
パラメーター（Parameters）:
【表９】
0005694296.tif 000010
【０１４６】
生成される場合（When Generated）  
このプリミティブは、ピアＭＩＨＦからＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｓｐｏｎｓｅメッセージを受信するＭＩＨＦによって生成される。
【０１４７】
受信への影響（Effect on Receipt）  
プリミティブを受信する際に、プロアクティブ認証リクエストを最初に開始するエンティティは、プロアクティブ認証を実行するか、またはプリミティブに基づいてそれを中止することを決定する。しかしながら、ステータス（Status）が「成功あるいは失敗（Success or Failure）」を示さない場合、受信者は任意の他の戻り値を無視し、代わりに、適切なエラー処理を行なう。
【０１４８】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｒｅｑｕｅｓｔ  
機能：プリミティブは、プロアクティブ認証の終了についてピアＭＩＨユーザー（MIH User）に示すために、ＭＩＨユーザーによって呼び出される。
【０１４９】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
MIH_Pro_Auth_Termination.request (
Destinationldentifier,
MobileNodeldentifier(Optional)
Candidateldnetifier(Optional) 
KeyCache 
)
パラメーター（Parameters）:
【表１０】
0005694296.tif 000011
【０１５０】
生成される場合（When Generated）  
このプリミティブは、プロアクティブ認証の終了について遠隔のＭＩＨユーザーと通信するために、このプリミティブはＭＩＨユーザーによって呼び出される。
【０１５１】
受信への影響（Effect on Receipt）  
このプリミティブの受信に際して、ローカルＭＩＨＦは、デスティネーション識別子（Destination Identifier）によって識別された遠隔のＭＩＨＦへのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを生成し送る。遠隔のＭＩＨＦは、ＭＩＨユーザーへの指示としてリクエストを転送する。
【０１５２】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｉｎｄｉｃａｔｉｏｎ  
機能：このプリミティブは、MIH_Pro_Auth_Termination requestメッセージが遠隔ＭＩＨＦから受信されたことをＭＩＨユーザーに示すために、ＭＩＨＦによって用いられる。
【０１５３】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
MIH_Pro_Auth_Termination.indication (
Sourceldentifier, 
MobileNodeldentifier(Optional) 
Candidateldnetifier(Optional) 
KeyCache 
) 
パラメーター（Parameters）:
【表１１】
0005694296.tif 000012
【０１５４】
生成される場合（When Generated）  
このプリミティブは、ピアＭＩＨＦからＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ ｒｅｑｕｅｓｔメッセージを受信することについてのＭＩＨＦによって生成される。
【０１５５】
受信への影響（Effect on Receipt）  
この指示を受信するＭＩＨユーザーは、ソース識別子（Source Identifier）によって示されている遠隔ＭＩＨＦへのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｒｅｓｐｏｎｓｅを生成するものとする。
【０１５６】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｒｅｓｐｏｎｓｅ  
機能：このプリミティブは、ネットワークでの遠隔ＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ ｒｅｑｕｅｓｔメッセージに応答するために、ＭＮ上でのＭＩＨＦによって使用される。
【０１５７】
サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Termination.response ( 
Destinationldentifier, 
MobileNodeldentifler(optional), 
Candidateldentifler(Optional), 
Status,
)
パラメーター（Parameters）:
【表１２】
0005694296.tif 000013
【０１５８】
生成される場合（When Generated）  
遠隔のＭＩＨユーザーは、そのＭＩＨＦからのＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｉｎｄｉｃａｔｉｏｎに応じてこのプリミティブを呼び出す。
【０１５９】
受信への影響（Effect on Receipt）  
ＭＩＨＦは、デスティネーション識別子に示されるピアＭＩＨＦへ、MIH_Pro_Auth responseメッセージを送る。
【０１６０】
ＭＩＨ＿Ｐｒｏ＿Ａｕｔｈ＿Ｔｅｒｍｉｎａｔｉｏｎ．ｃｏｎｆｉｒｍ  
機能：このプリミティブは、ＭＩＨ＿Ｐｒｏ＿Ｔｅｒｍｉｎａｔｉｏｎ ｒｅｓｐｏｎｓｅメッセージがピアＭＩＨＦから受信されたことを確認するために、使用される。
【０１６１】
サービスプリミティブのセマンティックス（Semantics of service primitive）
MIH_Pro_Auth_Termination.confirm (
Sourceldentifier, 
MobileNodeldentifier(Optional), 
Candidateldentifier(Optional),
Status,
)
パラメーター（Parameters）:
【表１３】
0005694296.tif 000014
【０１６２】
生成された場合（When Generated）  
このプリミティブは、ピアＭＩＨＦからMIH_Pro_Auth responseメッセージを受信するＭＩＨＦによって生成される。
【０１６３】
受信への影響（Effect on Receipt）  
プリミティブを受信する際に、プロアクティブ認証リクエストを最初に開始するエンティティは、プロアクティブ認証を終了するか、またはプリミティブに基づいてそれを中止することを決定する。しかしながら、ステータスが「成功あるいは失敗（Success or Failure）」を示さない場合、受信者は任意の他の戻り値を無視し、代わりに、適切なエラー処理を行なう。
【０１６４】
ＬＩｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｒｅｑｕｅｓｔ  
機能：プリミティブは、メディア固有オーセンティケータへ複数のメディア固有鍵をインストールするローカルＭＩＨＦを示すために、ＭＩＨユーザーによって呼び出される。
【０１６５】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
Link_Pro_Auth_Key_Install.request (
DestinationLinkldentifierwithKeys 
)
パラメーター（Parameters）:
【表１４】
0005694296.tif 000015
【０１６６】
生成された場合（When Generated）  
このプリミティブは、メディア固有オーセンティケータへ複数の鍵をインストールするローカルの複数のレイヤーを示すために、ＭＩＨＦによって呼び出される。
【０１６７】
受信への影響（Effect on Receipt）  
このプリミティブの受信の際に、下位レイヤーはＬｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｃｏｍｆｉｒｍプリミティブをＭＩＨＦへ生成する。
【０１６８】
Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｃｏｍｆｉｒｍ  
機能：このプリミティブは、Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｒｅｑｕｅｓｔが受信されたことを確認するために、ＭＩＨＦによって使用される。
【０１６９】
サービスプリミティブのセマンティックス（Semantics of service primitive）  
Link_Pro_Auth_Key_Install.confirm ( 
Status, 
)
パラメーター（Parameters）:
【表１５】
0005694296.tif 000016
【０１７０】
生成された場合（When Generated）  
このプリミティブは、Ｌｉｎｋ＿Ｐｒｏ＿Ａｕｔｈ＿Ｋｅｙ＿Ｉｎｓｔａｌｌ．ｒｅｑｕｅｓｔをＭＩＨＦから受信する際に下位レイヤーによって生成される。
【０１７１】
受信への影響（Effect on Receipt）  
プリミティブを受信する際に、ＭＩＨＦは、ステータスに基づいて、複数のプロアクティブ認証状態を維持するか、またはそれを中止するかを決定する。
【０１７２】
鍵生成アルゴリズム（Key Generation Algorithm）  
・ＫＤＦ：ＲＦＣ５２４６で指定される鍵導出関数（Key derivation function）  
−デフォルトＫＤＦ（すなわち、ＨＭＡＣ−ＳＨＡ−２５６に基づいたＩＫＥｖ２ ＰＲＦ＋）は、ピアＭＩＨＦ間で明示的に交渉されることなく、使用される。
【０１７３】
・MI-PMK = KDF(MK, "MI-PMK" | RAND_P | RAND_A | length)
−ＭＩ−ＰＭＫの長さ（Length）は６４オクテットである
−ＭＫ（マスター鍵、Master Key）：ＭＳＫまたはｒＭＳＫ
−ＲＡＮＤ＿Ｐ：ピアによって生成される乱数
−ＲＡＮＤ＿Ａ：オーセンティケータによって生成される乱数
・MS-PMK =KDF(MI-PMK, "MS-PMK" | MN_LINK_ID | POA_LINK_ID | length)
−ＭＳ＿ＰＭＫの長さは各メディアに依存する。８０２．１１の場合には、長さ（Length）＝３２。
【０１７４】
−ＭＮ＿ＬＩＮＫ＿ＩＤ：ＬＩＮＫ＿ＩＤデータタイプとしてエンコードされる、ＭＮのリンク識別子
−ＰＯＡ＿ＬＩＮＫ＿ＩＤ：ＬＩＮＫ＿ＩＤデータタイプとしてエンコードされる、メディア固有のオーセンティケータのリンク識別子
・ＰＲＦ＋：ＩＫＥｖ２［ＲＦＣ４３０６］で指定される鍵展開
・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)
・...
・鍵マテリアルの要求される長さを計算する必要があるとして継続する。デフォルトＰＲＦは、ＨＭＡＣ−ＳＨＡ−２５６［ＳＨＡ２５６］として受け取られる。ＰＲＦ＋が単に２５５回のイテレーションに関して定義されるので、それは８１６０オクテット以内の鍵マテリアルを生成してもよい。
【０１７５】
鍵配布機構（Key Distribution Mechanism）  
いくつかの実施形態では、鍵配布機構は、技術でのものによって確立することができる。例えば、これは規格を要求することができるか、あるいは配置仕様または実装選択として残すことができる。
【０１７６】
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合および／または変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、または本出願の出願中において説明される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能またはステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」または「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、およびｃ）構造、材料またはこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」または「発明」という用語は、本開示内の１つまたは複数の態様を指すものとして使用され得る。本発明または発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様または実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様および実施形態を有すると理解されるべきであり）、また、誤って本出願または特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセスまたはステップ、これらの任意の組合せ、および／またはこれらの任意の部分などを説明するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。
【図１】
0005694296.tif 000017
【図２】
0005694296.tif 000018
【図３】
0005694296.tif 000019
【図４】
0005694296.tif 000020
【図５】
0005694296.tif 000021
【図６】
0005694296.tif 000022
【図７】
0005694296.tif 000023
【図８】
0005694296.tif 000024
【図９】
0005694296.tif 000025
【図１０】
0005694296.tif 000026
【図１１】
0005694296.tif 000027
【図１２】
0005694296.tif 000028
【図１３】
0005694296.tif 000029
【図１４】
0005694296.tif 000030
【図１５】
0005694296.tif 000031
【図１６】
0005694296.tif 000032
【図１７】
0005694296.tif 000033
【図１８】
0005694296.tif 000034
【図１９】
0005694296.tif 000035