JP5211155B2 - Ｍｉｈ事前認証 - Google Patents

Description

本発明は無線ネットワーク間モバイルノードの認証及びハンドオーバに関する。

ネットワーク及びインターネット（登録商標）プロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、ＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれる１組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業及び個人へのアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御される。

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。

ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれるエンティティに分割される。各パケットは、独立のデータ単位として扱われる。

インターネットなどのネットワークを介した各点間の伝送を標準化するために、ＯＳＩ（開放型システム間相互接続）モデルが確立された。ＯＳＩモデルは、ネットワーク中の２点間の通信プロセスを７つの階層に分け、各層（レイヤ）は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。７つの機能層を提供するプログラミング及び／又はハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、ＴＣＰ／ＩＰ及び／又は他のトランスポート及びネットワークプロトコル、ならびに他のソフトウェア及びハードウェアの組み合わせである。

通常、上位４層は、メッセージがユーザから、又はユーザへ渡されるときに使用され、下位３層は、メッセージが装置（ＩＰホスト装置など）を通過するときに使用される。ＩＰホストは、サーバ、ルータ、ワークステーションなど、ＩＰパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。ＯＳＩモデルの各層を以下に列記する。第７層（すなわち、アプリケーション層）は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証及びプライバシが考慮され、データ構文に対する制約条件が識別される層である。第６層（すなわち、プレゼンテーション層）は、例えば、着信及び発信データをあるプレゼンテーション形式から別の形式に変換する層である。第５層（すなわち、セッション層）は、例えば、アプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了させる層である。第４層（すなわち、トランスポート層）は、例えば、エンドツーエンド制御及び誤りチェックなどを管理する層である。第３層（すなわち、ネットワーク層）は、例えば、経路指定や転送などを処理する層である。第２層（すなわち、データリンク層）は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識及び管理などを提供する層である。米国電気電子技術者協会（ＩＥＥＥ）では、データリンク層を、物理層との間のデータ転送を制御するＭＡＣ（媒体アクセス制御）層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うＬＬＣ（論理リンク制御）層という、２つのさらなる副層（サブレイヤ）に細分する。第１層（すなわち、物理層）は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。ＩＥＥＥでは、物理層を、ＰＬＣＰ（物理層収束手順）副層とＰＭＤ（物理媒体依存）副層とに細分する。

無線ネットワーク：
無線ネットワークは、例えば、セルラ及び無線電話機、ＰＣ（パーソナルコンピュータ）、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、ＰＤＡなど、多種多様なモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び／又はデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイル機器は、次のエンティティの一部又は全部、即ち送受信機（すなわち、例えば、送信機、受信機及び、必要に応じて、他の機能が統合されたシングルチップ送受信機などを含む、送信機及び受信機）、アンテナ、プロセッサ、１つ又は複数の音声変換器（例えば、音声通信用機器でのスピーカやマイクロホンなど）、電磁データ記憶（データ処理が提供される機器の場合などでの、ＲＯＭ、ＲＡＭ、デジタルデータ記憶など）、メモリ、フラッシュメモリ、フルチップセット又は集積回路、インターフェース（ＵＳＢ、ＣＯＤＥＣ、ＵＡＲＴ、ＰＣＭなど）及び／又は同種のものを含む。

モバイルユーザが無線接続を介してローカルエリアネットワーク（ＬＡＮ）に接続することのできる無線ＬＡＮ（ＷＬＡＮ）が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース（登録商標）、ＩＥＥＥ８０２．１１、ＨｏｍｅＲＦなど、様々なＷＬＡＮ標準が存在する。

一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末（ＰＤＡ）、及び他のモバイル機器の間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイル機器が、短距離無線接続を使って、相互に、また非モバイル機器と、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータ及び電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイル機器の普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名（ＢＤＮ）又は一意のブルートゥース機器アドレス（ＢＤＡ）に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル（ＩＰ）ネットワークに参加することもできる。ブルートゥース機器がＩＰネットワーク上で機能する場合、この機器は、ＩＰアドレス及びＩＰ（ネットワーク）名を備え得る。よって、ＩＰネットワークに参加するように構成されたブルートゥース機器は、ＢＤＮ、ＢＤＡ、ＩＰアドレス及びＩＰ名などを含むことができる。「ＩＰ名」という用語は、インターフェースのＩＰアドレスに対応する名前を指す。

ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及び機器の技術の仕様を定める。８０２．１１を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、８０２．１１で使用される機器は、通常、機器がアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、それとも別の機器であるか否かを問わず、無線送受信機、アンテナ、及びネットワークにおける各点間のパケットの流れを制御するＭＡＣ（媒体アクセス制御）層という３つの注目すべきエンティティを含む。

更に、いくつかの無線ネットワークでは、複数インターフェース機器（ＭＩＤ）が利用できる。ＭＩＤは、ブルートゥースインターフェースと８０２．１１インターフェースなど、２つの独立のネットワークインターフェースを含むことができ、よって、ＭＩＤが２つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。ＭＩＤは、ＩＰアドレス、及びＩＰアドレスに関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。

無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器（ＭＩＤ）、８０２．１１ｘ機器（８０２．１１ａ、８０２．１１ｂ、８０２．１１ｇ機器などを含む、ＩＥＥＥ８０２．１１機器）、ＨｏｍｅＲＦ（家庭内無線周波数）機器、Ｗｉ−Ｆｉ（Wireless Fidelity）機器、ＧＰＲＳ（General Packet Radio Service）機器、３Ｇセルラ機器、２．５Ｇセルラ機器、ＧＳＭ（Global System for Mobile Communications）機器、ＥＤＧＥ（Enhanced Data for GSM Evolution）機器、ＴＤＭＡ型（Time Division Multiple Access）機器、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多重接続）機器が含めることができる。各ネットワーク機器は、それだけに限らないが、ＩＰアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、ＩＥＥＥ ＭＡＣアドレスを含む、様々な種類のアドレスを含むことができる。

また、無線ネットワークは、例えば、モバイルＩＰ（インターネットプロトコル）システム、ＰＣＳシステム、及び他のモバイルネットワークシステムにおいて見られる方法及びプロトコルも関与できる。モバイルＩＰでは、これに、インターネット技術標準化委員会（ＩＥＴＦ）によって作成された標準通信プロトコルが関与する。モバイルＩＰでは、モバイル機器ユーザは、これらの一旦割り当てられたＩＰアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求（ＲＦＣ）３３４４を参照されたい。（注：ＲＦＣはインターネット技術標準化委員会（ＩＥＴＦ）の公式文書である。）モバイルＩＰは、インターネットプロトコル（ＩＰ）を拡張し、モバイル機器のホームネットワーク外部に接続するときに、モバイル機器にインターネットトラフィックを転送する手段を付加する。モバイルＩＰは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワーク及びこれのサブネット内の機器の現在位置を識別する気付アドレス（ＣｏＡ）を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、インターネット制御メッセージプロトコル（ＩＣＭＰ）などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。

（例えば、モバイルＩＰ外部などの）基本的なＩＰ経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのＩＰアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、及び／又は転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別するＩＰアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別するビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別するビットセットを調べることができる。典型的なモバイルＩＰ通信の場合、ユーザが、例えば、インターネットなどからモバイル機器を切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいＩＰアドレス、適正なネットマスク及びデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。

一般的な背景文献については、以下に記載された文献の各々は参照することにより全体として本明細書に援用される。

Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. ここでは [RFC3344]として参照する． Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. ここでは [RFC3775]として参照する． Malki, K., "Low latency Handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in progress), June 2004. ここでは[I-D.ietf-mobileip-lowlatency-handoffs-v4]として参照する． Koodli, R., "Fast Handovers for Mobile IPv6",draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. ここでは[I-D.ietf-mipshop-fast-mipv6]として参照する． Liebsch, M., "Candidate Access Router Discovery", draft-ietf-seamoby-card-protocol-08 (work in progress), September 2004. ここでは[I-D.ietf-seamoby-card-protocol]として参照する． Loughney, J., "Context Transfer Protocol", draft-ietf-seamoby-ctp-11 (work in progress), August 2004. ここでは[I-D.ietf-seamoby-ctp]として参照する． Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-04 (work in progress), November 2004. ここでは[I-D.ietf-eap-keying]として参照する． Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-07 (work in progress), December 2004. ここでは[I-D.ietf-pana-pana]として参照する． Kim, P., Volz, B. and S. Park, "Rapid Commit Option for DHCPv4", draft-ietf-dhc-rapid-commit-opt-05 (work in progress), June 2004. ここでは[I-D.ietf-dhc-rapid-commit-opt]として参照する． ITU-T, "General Characteristics of International Telephone Connections and International Telephone Cirsuits: One-Way Transmission Time." ここでは[RG98]として参照する． ITU-T, "The E-Model, a computational model for use in transmission planning." ここでは[ITU98]として参照する． ETSI, "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON) Release 3: End-to-end Quality of Service in TIPHON systems; Part 1: General Aspects of Quality of Service." ここでは[ETSI]として参照する． Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol," draft-ietf-mobike-design-01 (work in progress), January 2005. ここでは[I-D.ietf-mobike-design]として参照する． Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-01 (work in progress), October 2004. ここでは[I-D.ietf-hip-base]として参照する． Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. ここでは[RFC2679]として参照する． Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. ここでは[RFC2680] として参照する． Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. ここでは[RFC2681] として参照する． Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. ここでは[RFC1853] として参照する． Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. ここでは[RFC3046] として参照する． Schulzrine, H., "Application Layer Mobility Using SIP." ここでは[SIPMM] として参照する． Yegin, A., "Supporting Optimized Handover for IP Mobility -Requirements for Underlying Systems", draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002. ここでは[I-D.manyfolks-l2-mobilereq]として参照する． Cambell, A., Gomez, J., Kim, S., Valko, A. and C. Wan, "Design, Implementation, and Evaluation of Cellular IP." ここでは[CELLIP] として参照する． Ramjee, R., Porta, T., Thuel, S., Varadhan, K. and S. Wang, "HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless networks." ここでは[HAWAII] として参照する． Das, S., Dutta, A., Misra, A. and S. Das, "IDMP: An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks." ここでは[IDMP] として参照する． Calhoun, P., Montenegro, G., Perkins, C. and E. Gustafsson, "Mobile IPv4 Regional Registration", draft-ietf-mobileip-reg-tunnel-09 (work in progress), July 2004. ここでは[I-D.ietf-mobileip-reg-tunnel] として参照する． Yokota, H., Idoue, A. and T. Hasegawa, "Link Layer Assisted Mobile IP Fast Handoff Method over Wireless LAN Networks." ここでは[YOKOTA] として参照する． Shin, S., "Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs." ここでは[MACD] として参照する． Dutta, A., "Secured Universal Mobility." ここでは[SUM]として参照する． Dutta, A., "Fast handoff Schemes for Application Layer Mobility Management." ここでは[SIPFAST]として参照する． Gwon, Y., Fu, G. and R. Jain, "Fast Handoffs in Wireless LAN Networks using Mobile initiated Tunneling Handoff Protocol for IPv4 (MITHv4)", January 2005. ここでは[MITH] として参照する． Anjum, F., Das, S., Dutta, A., Fajardo, V., Madhani, S., Ohba, Y., Taniuchi, K., Yaqub, R. and T. Zhang, "A proposal for MIH function and Information Service", January 2005. ここでは[NETDISC] として参照する． Dutta, A., "GPS-IP based fast-handoff for Mobiles." ここでは[GPSIP] として参照する． [MAGUIRE] Vatn, "The effect of using co-located care-of-address on macro handover latency."。

［メディア独立事前認証のフレームワークに関する背景］
次の米国出願の全体の開示はそれらのエンティティにおいて参照することによってここに援用される。メディア独立認証のフレームワークに関してＡ．Ｄｕｔｔａによる米国特許出願番号１１／３０７，３６２、メディア独立認証のフレームワーク（ＰＡＮＡ支援）に関してＹ．Ｏｈｂａによる米国特許出願番号１１／３０８，１７５。このセクションはまた参照として以下の米国特許出願番号１１／３０７，３６２のあらゆる内容を含む。

１．序論
セルラ及び無線ＬＡＮを含む無線技術が普及するにつれて、無線ＬＡＮからＣＤＭＡへ、又はＧＰＲＳへなど、異なる種類のアクセスネットワークにまたがる端末ハンドオーバをサポートすることが明確な課題であると考えられている。他方、同種のアクセスネットワーク間の端末ハンドオーバのサポートも、特に、ハンドオーバがＩＰサブネット又は管理ドメインにまたがるときには、依然として難しい。これらの課題に対処するには、不合理な複雑さを招くことなく、最適化された、安全なやり方で、リンク層技術にとれわれない端末モビリティを提供することが重要である。本明細書では、低待ち時間低損失の、シームレスなハンドオーバを提供する端末モビリティについて論じる。シームレスなハンドオーバは、第１．１項に記述する性能要件の観点から特徴付けられる。

端末モビリティの基本部分は、モバイル端末のロケータと識別子の間のバインディングを維持するモビリティ管理プロトコルによって達成され、このバインディングを、モビリティバインディングと呼ぶ。モバイルノードのロケータは、モバイル端末の移動が生じるときに、動的に変化できる。ロケータの変化を生じる移動は、物理的にのみならず、論理的にも発生できる。モビリティ管理プロトコルは、任意の層で定義できる。本明細書の以下の部分において、「モビリティ管理プロトコル」という用語は、ネットワーク層以上で動作するモビリティ管理プロトコルを指す。

いくつかのモビリティ管理プロトコルが異なる層にある。モバイルＩＰ［ＲＦＣ３３４４］及びモバイルＩＰｖ６［ＲＦＣ３７７５］は、ネットワーク層で動作するモビリティ管理プロトコルである。ＩＥＴＦにおいては、ネットワーク層より上位の各層におけるモビリティ管理プロトコルを定義するためのいくつかの活動が現在行われている。例えば、ＭＯＢＩＫＥ（ＩＫＥｖ２モビリティ及びマルチホーミング）［I-D.ietf-mobike-design］は、ＩＫＥｖ２端点のＩＰアドレスの変更を扱うことを可能にするＩＫＥｖ２の拡張である。ＨＩＰ（ホスト識別情報プロトコル）［I-D.ietf-hip-base］は、ネットワーク層とトランスポート層の両方にとって透過的なやり方で端末モビリティを提供するように、ネットワーク層とトランスポート層の間に新しいプロトコル層を定義する。また、ＳＩＰモビリティは、ＳＩＰユーザエージェントのモビリティバインディングを維持するためのＳＩＰの拡張である［ＳＩＰＭＭ］。

モビリティ管理プロトコルはモビリティバインディングを維持するが、これらを単にこれらの現在の形で使用するだけでは、シームレスなハンドオーバを提供するのに十分ではない。シームレスなハンドオーバを実現するには、モビリティバインディングを更新する間の送信未完了パケットの喪失を防ぐためにモバイル端末の訪問先ネットワークにおいて機能する、さらなる最適化機構が必要である。かかる機構を、モビリティ最適化機構と呼ぶ。例えば、隣接するアクセスルータに、モバイル端末に関する情報を搬送するために通信を行わせることによる、モビリティ最適化機構［I-D.ietf-mobileip-lowlatency-handoffs-v4］及び［I-D.ietf-mipshop-fast-mipv6］が、それぞれ、モバイルＩＰｖ４とモバイルＩＰｖ６とに定義されている。モビリティ最適化機構の「援助機能」とみなされるプロトコルがある。ＣＡＲＤ（候補アクセスルータ発見機構）プロトコル［I-D.ietf-seamoby-card-protocol］は、隣接するアクセスルータを発見するように設計されている。ＣＴＰ（コンテキスト転送プロトコル）［I-D.ietf-seamoby-ctp］は、アクセスルータの間で、モバイル端末に提供されるサービスに関連付けられた状態、又はコンテキストを保持するように設計されている。

既存のモビリティ最適化機構にはいくつかの問題がある。第１に、既存のモビリティ最適化機構は、特定のモビリティ管理プロトコルと緊密に結びついている。例えば、モバイルＩＰｖ４又はモバイルＩＰｖ６用に設計されたモビリティ最適化機構をＭＯＢＩＫＥに使用することは不可能である。強く望まれているのは、どんなモビリティ管理プロトコルとも一緒に機能する、単一の、統一されたモビリティ最適化機構である。第２に、管理ドメイン間に事前に確立されたセキュリティアソシエーションを想定せずに管理ドメインにまたがるハンドオーバを容易にサポートする既存のモビリティ最適化機構がない。モビリティ最適化機構は、モバイルノードと各管理ドメインの間の信頼関係だけに基づいて、安全なやり方で管理ドメインにまたがって機能する必要がある。第３に、モビリティ最適化機構は、複数のインターフェースを介した複数の同時接続が期待できる多重インターフェース端末のみならず、単一インターフェース端末もサポートする必要がある。

本明細書では、これらの問題すべてに対処する可能性を有する新しいハンドオーバ最適化機構である、メディア独立型事前認証（ＭＰＡ）のフレームワークについて説明する。ＭＰＡは、任意のリンク層より上位で、モバイルＩＰｖ４、モバイルＩＰｖ６、ＭＯＢＩＫＥ、ＨＩＰ、ＳＩＰモビリティなどを含む任意のモビリティ管理プロトコルを用いて機能する、モバイル主導型の安全なハンドオーバ最適化方式である。ＭＰＡでは、ＩＥＥＥ８０２．１１ｉ事前認証の概念が、モバイル端末が移動先とし得るネットワークからのＩＰアドレスの早期獲得、ならびにモバイル端末がまだ現在のネットワークに接続されている間のネットワークへの事前対応ハンドオーバを実行する追加機構を用いて、上位層において機能するように拡張される。

ここでは、異なるメディアの上位層及び下位層コンテキストを先回りして確立するシステム及び方法が記述されている。これに関して、メディアは、例えば、（有線、無線認可、無線無認可の）モバイル機器にアクセスできる利用可能なネットワークを含む。例えば、ＩＥＥＥ８０２．２１を含むＩＥＥＥ８０２で論じられているメディアなどを参照されたい。メディアには、例えば、セルラ、無線ＬＡＮ（ＩＥＥＥ８０２．１１など）、ＩＥＥＥ８０２．１６、ＩＥＥＥ８０２．２０、ブルートゥースなどが含まれ得る。説明例の中には、１）セルラネットワークから無線又はＷｉ−Ｆｉネットワークに切り換わるモバイル機器、例えば、セルラインターフェース及び無線インターフェースを備える携帯電話機などのモバイル機器が、同時に無線インターフェースを確立するのではなく、最初に、セルラネットワークを介して情報（鍵など）を獲得することによってＷｉ−Ｆｉアクセスを取得しようとするなどの場合、２）モバイル機器が現在無線又はＷｉ−Ｆｉ接続を有し、無線ＬＡＮが、ことによっては、急にシャットダウンできる場合において、例えば、モバイル機器が、セルラネットワークを介して先回りして（すなわち、必要に応じて迅速な切り換えを可能にするように）事前認証を行い得る場合が含まれる。いくつかの説明的事例では、単一のＩＥＥＥ８０２．ｘｘインターフェースを有するモバイルノードが、複数のサブネット及び複数の管理ドメインの間でローミングを行うこともできる。複数のインターフェースを常にオンに保つことも１つの選択肢であるが、場合によっては、モバイルノードは、（例えば、節電などのために）不使用のインターフェースを非活動化しようとすることもある。加えて、ＭＰＡは、中でも特に、サブネット間ハンドオフ、ドメイン間ハンドオフ、技術間ハンドオフなど、及び複数インターフェースの使用のために機能する、安全でシームレスなモビリティ最適化を提供することができる。

２．用語
モビリティバインディング：
モバイル端末のロケータと識別子の間のバインディング。

モビリティ管理プロトコル（ＭＭＰ）：
モバイル端末のロケータと識別子の間のバインディングを維持するためにネットワーク層以上で動作するプロトコル。

バインディング更新：
モビリティバインディングを更新する手順。

メディア独立型事前認証モバイルノード（ＭＮ）：
任意のリンク層より上位で、任意のモビリティ管理プロトコルを用いて機能するモバイル主導型の安全なハンドオーバ最適化方式である、メディア独立型事前認証（ＭＰＡ）のモバイル端末。ＭＰＡモバイルノードはＩＰノードである。本明細書において、修飾句の付かない「モバイルノード」又は「ＭＮ」という用語は、「ＭＰＡモバイルノード」を指す。ＭＰＡモバイルノードは、普通、モビリティ管理プロトコルのモバイルノードの機能も有する。

候補ターゲットネットワーク（ＣＴＮ）：
近い将来においてモバイルの移動先となり得るネットワーク。

ターゲットネットワーク（ＴＮ）：
モバイルが移動先に決定しているネットワーク。ターゲットネットワークは、１つ又は複数の候補ターゲットネットワークから選択される。

事前対応ハンドオーバトンネル（ＰＨＴ）：
ＭＰＡモバイルノードと候補ターゲットネットワークのアクセスルータの間で確立される双方向ＩＰトンネル。本明細書において、修飾句の付かない「トンネル」という用語は、「事前対応ハンドオーバトンネル」を指す。

接続点（ＰｏＡ）：
ＭＰＡモバイルノードのネットワークへのリンク層接続点として機能するリンク層装置（スイッチ、アクセスポイント又は基地局など）。

気付アドレス（ＣｏＡ）
モビリティ管理プロトコルによってＭＰＡモバイルノードのロケータとして使用されるＩＰアドレス。

３．ＭＰＡフレームワーク
３．１ 概要
メディア独立型事前認証（ＭＰＡ）は、任意のリンク層より上位で、任意のモビリティ管理プロトコルを用いて機能するモバイル主導型の安全なハンドオーバ最適化方式である。ＭＰＡを用いれば、モバイルノードは、候補ターゲットネットワークからＩＰアドレス及び他の構成パラメータを安全に獲得することができるだけでなく、候補ターゲットネットワークがターゲットネットワークになるときにモバイルノードが候補ターゲットネットワークに接続する前に、獲得したＩＰアドレス及び他の構成パラメータを使ってＩＰパケットを送受信することもできる。これは、モバイルノードが、リンク層においてハンドオーバを実行する前に、任意のモビリティ管理プロトコルのバインディング更新を完了し、新しい気付アドレスを使用することを可能にする。

この機能は、現在のネットワークへの接続を有するが、まだ候補ターゲットネットワークに接続されていないモバイルノードに、（i）後続のプロトコル実行を確保するために、候補ターゲットネットワークとのセキュリティアソシエーションを確立させ、次いで、（ii）候補ターゲットネットワークからＩＰアドレス及び他の構成パラメータを獲得するための構成プロトコル、ならびにモバイルノードと候補ターゲットネットワークのアクセスルータの間の双方向トンネルを確立するためのトンネル管理プロトコルを安全に実行させ、次いで、（iii）獲得したＩＰアドレスをトンネル内アドレスとして使用し、トンネルを介して、モビリティ管理プロトコルのバインディング更新用シグナリングメッセージ、及びバインディング更新の完了後に送信されるデータパケットを含むＩＰパケットを送受信させ、最後に、（iv）候補ターゲットネットワークがターゲットネットワークになるときに候補ターゲットネットワークに接続する直前に、トンネルを削除し、又は使用不可にし、次いで、モバイルノードがこれの物理インターフェースを介してターゲットネットワークに接続された直後に、削除され、又は使用不可にされたトンネルの内部アドレスをこのインターフェースに割り当てることによって提供される。ターゲットネットワークに接続する前にトンネルを削除し、又は使用不可にする代わりに、ターゲットネットワークに接続された直後にトンネルを削除し、使用不可にすることもできる。

特に、第３の手順は、モバイルが、リンク層ハンドオーバを開始する前に、上位層のハンドオーバを完了することを可能にする。これは、モバイルが、トンネルを介してバインディング更新の完了後に送信されるデータパケットを送受信することができると同時に、トンネル外部のバインディング更新の完了前に送信されるデータパケットも送受信することができることを意味する。

上記のＭＰＡの４つの基本手順において、第１の手順を「事前認証」といい、第２の手順を「事前構成」といい、第３と第４の手順の組み合わせを「安全な事前対応ハンドオーバ」という。事前認証によって確立されるセキュリティアソシエーションを「ＭＰＡ−ＳＡ」という。事前構成によって確立されるトンネルを「事前対応ハンドオーバトンネル」という。

３．２ 機能要素
ＭＰＡフレームワークでは、モバイルノードと通信を行うために、各候補ターゲットネットワークに、認証エージェント（ＡＡ）、構成エージェント（ＣＡ）及びアクセスルータ（ＡＲ）という機能要素があることが期待される。これらの要素の一部又は全部は、単一のネットワーク装置、又は別々のネットワーク装置に配置できる。

認証エージェントは事前認証の役割を果たす。モバイルノードと認証エージェントの間でＭＰＡ−ＳＡを確立するために認証プロトコルが実行される。認証プロトコルは、モバイルノードと認証エージェントの間で鍵を導出することができなければならず、相互認証を提供できる必要がある。認証プロトコルは、ＡＡＡインフラストラクチャの適切な認証サーバに認証証明書を搬送するために、ＲＡＤＩＵＳやＤｉａｍｅｔｅｒなどのＡＡＡプロトコルと対話することができる必要がある。導出された鍵は、事前構成及び安全な事前対応ハンドオーバに使用されるメッセージ交換を保護するのに使用される鍵をさらに導出するために使用される。また、リンク層及び／又はネットワーク層暗号をブートストラップするのに使用される他の鍵もＭＰＡ−ＳＡから導出され得る。

構成エージェントは、事前構成の一部、すなわち、構成プロトコルを安全に実行して、ＩＰアドレス及び他の構成パラメータをモバイルノードに安全に配信する役割を果たす。構成プロトコルのシグナリングメッセージは、ＭＰＡ−ＳＡに対応する鍵から導出される鍵を使って保護されなければならない。

アクセスルータは、事前構成の他の部分、すなわち、トンネル管理プロトコルを安全に実行して、モバイルノードへの事前対応ハンドオーバトンネルを確立し、事前対応ハンドオーバトンネルを使って事前対応ハンドオーバを確保する役割を果たすルータである。構成プロトコルのシグナリングメッセージは、ＭＰＡ−ＳＡに対応する鍵から導出される鍵を使って保護されなければならない。事前対応ハンドオーバトンネルを介して送信されるＩＰパケットは、ＭＰＡ−ＳＡに対応する鍵から導出される鍵を使って保護される必要がある。

３．３ 基本的通信フロー
モバイルノードは、ｏＰｏＡ（旧い接続点）などの接続点にすでに接続されており、ｏＣｏＡ（旧い気付アドレス）などの気付アドレスが割り当てられているものと仮定する。ＭＰＡの通信の流れは以下のように説明される。この通信の流れ全体を通して、データパケット喪失は、ステップ５の切り換え手順時の期間以外には発生しないはずであり、この期間におけるパケット喪失を最小限に抑えるのはリンク層ハンドオーバの役割である。

ステップ１（事前認証段階）：モバイルノードは、何らかの発見プロセスを介して候補ターゲットネットワークを探し出し、何らかの手段によって、候補ターゲットネットワークのＩＰアドレス、認証エージェント、構成エージェント及びアクセスルータを獲得する。モバイルノードは、認証エージェントを用いて事前認証を行う。事前認証に成功した場合、モバイルノードと認証エージェントの間でＭＰＡ−ＳＡが作成される。ＭＰＡ−ＳＡから、２つの鍵、すなわち、ＭＮ−ＣＡ鍵とＭＮ−ＡＲ鍵が導出され、それぞれ、後続の構成プロトコル及びトンネル管理プロトコルのシグナリングメッセージを保護するのに使用される。次いで、ＭＮ−ＣＡ鍵とＭＮ−ＡＲ鍵は、それぞれ、構成エージェントとアクセスルータとに安全に配信される。

ステップ２（事前構成段階）：モバイルノードは、これの接続点が、ｏＰｏＡからｎＰｏＡ（新しい接続点）などの新しいものに変わる可能性のあることに気付く。次いで、モバイルノードは事前構成を実行し、構成エージェントで構成プロトコルを使って、候補ターゲットネットワークから、ｎＣｏＡ（新しい気付アドレス）などのＩＰアドレス、及び他の構成パラメータを獲得し、アクセスルータでトンネル管理プロトコルを使って事前対応ハンドオーバトンネルを確立する。トンネル管理プロトコルにおいて、モバイルノードは、ｏＣｏＡ及びｎＣｏＡを、それぞれ、トンネル外部アドレス及びトンネル内部アドレスとして登録する。事前構成プロトコルのシグナリングメッセージは、ＭＮ−ＣＡ鍵及びＭＮ−ＡＲ鍵を使って保護される。構成及びアクセスルータが同じ装置に位置しているときには、これら２つのプロトコルは、ＩＫＥｖ２などの単一プロトコルに統合できる。トンネル確立の完了後、モバイルノードは、ステップ４の終わりまでに、ｏＣｏＡとｎＣｏＡの両方を使って通信を行うことができる。

ステップ３（安全な事前対応ハンドオーバの主段階）：モバイルノードは、何らかの手段によって新しい接続点に切り換わることを決定する。モバイルノードは、新しい接続点に切り換わる前に、モビリティ管理プロトコルのバインディング更新を実行し、トンネルを介して後続のデータトラフィックを送信することによって安全な事前対応ハンドオーバを開始する。

ステップ４（安全な事前対応ハンドオーバ切り換え前段階）：モバイルノードはバインディング更新を完了し、新しい接続点に切り換わることのできる状態になる。モバイルは、トンネル管理プロトコルを実行して事前対応ハンドオーバトンネルを削除する。モバイルノードは、トンネルの削除後でさえも、ｎＣｏＡをキャッシュする。モバイルノードがいつ新しい接続点に切り換わることのできる状態になるかの決定は、ハンドオーバポリシによって決まる。

ステップ５（切り換え）：このステップではリンク層ハンドオーバが行われることが期待される。

ステップ６（安全な事前対応ハンドオーバ切り換え後段階）：モバイルノードは、切り換え手順を実行する。切り換え手順が正常に完了すると、モバイルノードは、直ちに、キャッシュしたｎＣｏＡを復元し、これを、新しい接続点に接続された物理インターフェースに割り当てる。この後は、事前対応ハンドオーバトンネルを使用せずに、ｎＣｏＡを使ったデータパケットの直接送信が可能である。

４．詳細
高速なサブネット及びドメインのハンドオーバが行われるモバイルに最適化ハンドオーバ提供するためには、いくつかの問題を検討する必要がある。これらの問題には、隣接するネットワーク要素の発見、ある一定のポリシに基づいた適切な接続先ネットワークの選択、第２層接続点の変更、ＤＨＣＰ又はＰＰＰサーバからのＩＰアドレスの獲得、ＩＰアドレスの一意性の確認、特定のドメインにおけるＡＡＡサーバなどの認証エージェントとの事前認証、対応するホストへのバインディング更新の送信及び新しい接続点への宛先変更ストリーミングトラフィックの獲得が含まれる。以下の段落では、これらの問題を詳細に説明し、ＭＰＡベースの安全な事前対応ハンドオーバの場合にこれらをどのようにして最適化しているか説明する。

５．１ ディスカバリ
アクセスポイント、アクセスルータ、認証サーバなどの隣接するネットワーク要素の発見は、モバイルの高速なネットワーク間移動時のハンドオーバプロセスを円滑するのに役立つ。所望の座標、機能及びパラメータのセットを有する近隣ネットワークを発見することにより、モバイルは、事前認証、事前対応ＩＰアドレス獲得、事前対応アドレス解決、前のネットワークにある間のバインディング更新といった動作の多くを実行することができる。

モバイルが隣接するネットワークを発見するいくつかの方法がある。候補アクセスルータ発見プロトコル［I-D.ietf-seamoby-card-protocol］は、隣接するネットワーク中の候補アクセスルータを発見するのに役立つ。あるネットワークドメインが与えられた場合、ＳＬＰ及びＤＮＳは、この特定のドメインにおける所与のサービスセットでのネットワーク構成要素のアドレスを提供するのに役立つ。場合によっては、ネットワーク層及び上位層のパラメータの多くが、モバイルが隣接するネットワークの近傍に接近するときに、ビーコンなどのリンク層管理フレームを介して送信され得る。ＩＥＥＥ８０２．１１ｕは、リンク層に含まれる情報を使った隣接局の発見などの問題を考察する。しかしながら、リンク層管理フレームが何らかのリンク層セキュリティ機構によって暗号化されている場合、モバイルノードは、アクセスポイントへのリンク層接続を確立する前に必要な情報を獲得することができないこともある。また、これは、帯域幅が制約された無線媒体に負担をかけることもある。かかる場合、隣接する要素に関する情報を獲得するには、上位層プロトコルの方が好ましい。モビリティサーバから隣接するネットワークに関するこれらの情報を獲得するのに役立つ、［ＮＥＴＤＩＳＣ］など、若干の提案がある。モバイルは、モバイルの移動が差し迫っているときに、特定のサーバに問い合わせを行うことによって発見プロセスを開始し、アクセスポイントのＩＰアドレス、これの特性、ルータ、隣接するネットワークのＳＩＰサーバ又は認証サーバなど、必要なパラメータを獲得する。複数のネットワークがある場合には、複数の隣接するネットワークから必要なパラメータを獲得し、これらをキャッシュに保持することができる。ある時点において、モバイルは、多くの有望なネットワークの中からいくつかの候補ターゲットネットワークを探し出し、候補ターゲットネットワーク中の必要なエンティティと通信を行うことによって事前認証プロセスを開始する。

４．２ 事前ＩＰアドレス獲得
一般に、モビリティ管理プロトコルは、外部エージェントと連動して、又はコロケーテッドアドレスモードで機能する。好ましい実施形態では、本ＭＰＡ手法は、コロケーテッドアドレスモードと外部エージェントアドレスモードの両方を使用することができる。ここでは、コロケートテッドアドレスモードで使用されるアドレス割り当て構成要素について論じる。モバイルノードがＩＰアドレスを獲得し、モバイルノード自体の構成を行うことのできるいくつかの方法がある。最も一般的には、モバイルは、ネットワークにサーバやルータなどの構成要素がない場合には、モバイル自体を静的に構成することができる。ＩＥＴＦゼロコンフ（Zeroconf、設定不要）作業グループは、モバイルが、随意に構成され、１６９．２５４．ｘ．ｘ．などの指定範囲から一意のアドレスを選択する自動ＩＰ機構を定義している。ＬＡＮ環境において、モバイルは、ＤＨＣＰサーバからＩＰアドレスを獲得することができる。ＩＰｖ６ネットワークの場合、モバイルには、ステートレス自動構成を使ってＩＰアドレスを獲得する選択肢もある。広帯域ネットワーク環境において、モバイルは、ＰＰＰを使い、ＮＡＳと通信を行うことによってＩＰアドレスを獲得する。

これらのプロセスのそれぞれは、クライアントとサーバのＩＰアドレス獲得プロセス及びオペレーティングシステムの種類に応じて、およそ数百ミリ秒から数秒程度の時間を要する。ＩＰアドレス獲得はハンドオーバプロセスの一部であるため、これはハンドオーバ遅延を増大させ、よって、この時間をできるだけ短縮することが望ましい。ＩＰアドレス獲得時間に起因するハンドオーバ時間を短縮しようとする、ＤＨＣＰ高速コミット［I-D.ietf-dhc-rapid-commit-opt］やＧＰＳ座標ベースのＩＰアドレス［ＧＰＳＩＰ］など、利用可能ないくつかの最適化された技法がある。しかしながら、これらすべての場合において、モバイルは、やはり、新しいサブネットに移動し、モバイルノードとＤＨＣＰサーバの間のシグナリングハンドシェークによる多少の遅延を生じた後で、ＩＰアドレスを獲得する。

以下の各パラグラフでは、モバイルノードが候補ターゲットネットワークから先回りしてＩＰアドレスを獲得できるいくつかの方法、及び関連するトンネルセットアップ手順を説明する。これらは、大きく、ＰＡＮＡ支援事前ＩＰアドレス獲得、ＩＫＥ支援事前ＩＰアドレス獲得及びＤＨＣＰのみを使った事前ＩＰアドレス獲得などの、３つのカテゴリに定義できる。

４．２．１ ＰＡＮＡ支援事前ＩＰアドレス獲得
ＰＡＮＡ支援事前ＩＰアドレス獲得の場合、モバイルノードは、候補ターゲットネットワークから先回りしてＩＰアドレスを獲得する。モバイルノードは、ＰＡＮＡメッセージを利用して、候補ターゲットネットワーク中のアクセスルータのＰＡＮＡ認証エージェントと同じ場所にあるＤＨＣＰリレーエージェント上でアドレス獲得プロセスをトリガする。モバイルノードからＰＡＮＡメッセージを受け取ると、ＤＨＣＰリレーエージェントは、候補ターゲットネットワーク中のＤＨＣＰサーバからＩＰアドレスを獲得するために、通常のＤＨＣＰメッセージ交換を実行する。このアドレスは、ＰＡＮＡメッセージに載せて運ばれ、クライアントに配信される。

４．２．２ ＩＫＥｖ２支援事前ＩＰアドレス獲得
ＩＫＥｖ２支援事前対応ＩＰアドレス獲得は、ＩＰｓｅｃゲートウェイ及びＤＨＣＰリレーエージェントが候補ターゲットネットワーク中の各アクセスルータ内にあるときに機能する。この場合、候補ターゲットネットワークのＩＰｓｅｃゲートウェイ及びＤＨＣＰリレーエージェントは、モバイルノードが、候補ターゲットネットワーク中のＤＨＣＰサーバからＩＰアドレスを獲得するのを補助する。事前認証段階において設定されたＭＮ−ＡＲキーが、モバイルノードとアクセスルータの間でＩＫＥｖ２を実行するのに必要とされるＩＫＥｖ２事前共用秘密キーとして使用される。候補ターゲットネットワークからのＩＰアドレスは、標準ＩＫＥｖ２手順の一部として、標準のＤＨＣＰを使用してターゲットネットワーク中のＤＨＣＰサーバからＩＰアドレスを獲得するために同じ場所にあるＤＨＣＰリレーエージェントを使用して獲得される。獲得したＩＰアドレスは、ＩＫＥｖ２構成ペイロード交換においてクライアントに返送される。この場合、ＩＫＥｖ２は、事前対応ハンドオーバトンネルのトンネル管理プロトコルとしても使用される（第５．４項参照）。

４．２．３ ＤＨＣＰのみを使った事前ＩＰアドレス獲得
別の代替方法として、ＤＨＣＰを使って、モバイルノードと候補ターゲットネットワークのＤＨＣＰリレー又はＤＨＣＰサーバの間の直接ＤＨＣＰ通信を可能にすることにより、ＰＡＮＡ又はＩＫＥｖ２ベースの手法を利用せずに、候補ターゲットネットワークからＩＰアドレスを先回りして獲得することもできる。この場合、モバイルノードは、現在の物理インターフェースに関連付けられたアドレスを要求のソースアドレスとして使用して、候補ターゲットネットワーク中のＤＨＣＰリレーエージェント又はＤＨＣＰサーバに、アドレスを要求するユニキャストＤＨＣＰメッセージを送る。

メッセージがＤＨＣＰリレーエージェントに送られると、ＤＨＣＰリレーエージェントは、このＤＨＣＰメッセージを中継して、モバイルノードとＤＨＣＰサーバの間を往復させる。ＤＨＣＰリレーエージェントがない場合、モバイルは、ターゲットネットワークのＤＨＣＰサーバと直接通信することもできる。クライアントのユニキャストＤＩＳＣＯＶＥＲメッセージのブロードキャストオプションは、リレーエージェント又はＤＨＣＰサーバが、モバイルノードのソースアドレスを使ってモバイルに直接応答を返信することができるように、０に設定される必要がある。

悪意のあるノードがＤＨＣＰサーバからＩＰアドレスを獲得することを防ぐために、ＤＨＣＰ認証を使用する必要があり、又はアクセスルータは、事前認証されていないモバイルノードからリモートのＤＨＣＰサーバに送られるユニキャストＤＨＣＰメッセージをブロックするフィルタをインストールする必要がある。ＤＨＣＰ認証が使用されるとき、ＤＨＣＰ認証鍵は、モバイルノードと候補ターゲットネットワークの認証エージェントの間で確立されたＭＰＡ−ＳＡから導出できる。

事前獲得ＩＰアドレスは、モバイルが新しいネットワークに移動するまでモバイルノードの物理インターフェースに割り当てられない。よって、ターゲットネットワークから先回りして獲得されたＩＰアドレスは、物理インターフェースに割り当てられるのではなく、クライアントの仮想インターフェースに割り当てられる必要がある。よって、モバイルノードと候補ターゲットネットワークのＤＨＣＰリレー又はＤＨＣＰサーバとの間の直接ＤＨＣＰ通信を介して先回りして獲得されたかかるＩＰアドレスは、これを、物理インターフェースに割り当てられた他のアドレスと区別するのに使用される付加情報と共に搬送できる。

モバイルが新しいネットワークに入ると、モバイルノードは、ＤＨＣＰ ＩＮＦＯＲＭなどを使って、ＳＩＰサーバ、ＤＮＳサーバなどの他の構成パラメータを取得するために、物理インターフェースを介して新しいネットワークにＤＨＣＰを実行することができる。これは、モバイルと対応するホストの間の進行中の通信に影響を及ぼすべきではない。また、モバイルノードは、新しいネットワークに入る前に先回りして獲得されたアドレスのリースを延長するために、物理インターフェースを介して新しいネットワークにＤＨＣＰを実行することもできる。

モバイルノードのＤＨＣＰバインディングを維持し、安全な事前対応ハンドオーバ前後に与えられたＩＰアドレスを追跡するために、事前対応ＩＰアドレス獲得でのＤＨＣＰと、モバイルノードがターゲットネットワークに入った後で実行されるＤＨＣＰの両方のモバイルノードに同じＤＨＣＰクライアント識別子を使用する必要がある。ＤＨＣＰクライアント識別子は、モバイルノードのＭＡＣアドレス又は他の何らかの識別子とすることができる。

４．３ アドレス解決問題
５．３．１ 事前対応重複アドレス検出
ＤＨＣＰサーバは、ＩＰアドレスを与えるときに、これのリース表を更新して、この同じアドレスがこの特定の期間にわたって別のクライアントに与えられないようにする。同時に、クライアントも、必要に応じて更新できるように、リース表をローカルで保持する。ネットワークがＤＨＣＰと非ＤＨＣＰの両方に対応するクライアントを含む場合には、ＬＡＮを備える別のクライアントが、ＤＨＣＰアドレスプールからのＩＰアドレスを用いて構成されている可能性がある。かかるシナリオにおいて、サーバは、ＩＰアドレスを割り当てる前に、ＡＲＰ（アドレス解決プロトコル）又はＩＰｖ６隣接局探索に基づいて重複アドレス検出を行う。この検出手順には最大４秒から１５秒を要することがあり［ＭＡＧＵＩＲＥ］、よって、より大きなハンドオーバ遅延の一因となる。事前対応ＩＰアドレス獲得プロセスの場合には、この検出が前もって実行され、よって、ハンドオーバ遅延には全く影響を及ぼさない。前もって重複アドレス検出を実行することにより、ハンドオーバ遅延要因が低減される。

４．３．２ 事前対応アドレス解決更新
事前構成のプロセスの間には、モバイルノードが、ターゲットネットワークへの接続後にターゲットネットワーク中の各ノードと通信するのに必要なアドレス解決マッピングを知ることもでき、これらの各ノードは、アクセスルータ、認証エージェント、構成エージェント及び対応ノードとすることができる。このような事前対応アドレス解決を実行するいくつかの可能な方法がある。

・各ノードのＭＡＣアドレスを解決するため情報サービス機構［ＮＥＴＤＩＳＣ］を使用する。これは、情報サービスのサーバが事前対応アドレス解決のデータベースを構築できるように、情報サービスに含めるためにターゲットネットワークに各ノードが必要となるかもしれない。

・事前認証に使用される認証プロトコル又は事前構成に使用される構成プロトコルを拡張して、事前対応アドレス解決をサポートする。例えば、事前認証用認証プロトコルとしてＰＡＮＡが使用される場合、ＰＡＮＡメッセージは、事前対応アドレス解決に使用されるＡＶＰを搬送できる。この場合、ターゲットネットワークのＰＡＮＡ認証エージェントは、モバイルノードに代わってアドレス解決を実行することができる。

・ターゲットネットワーク中の各ノードのＭＡＣアドレスを先回りして解決するために新しいＤＮＳリソースリコードを定義する。これは、ドメイン名とＭＡＣアドレスの間のマッピングが一般に安定的でない、あまり望ましくない。

モバイルノードは、ターゲットネットワークに接続するときに、ターゲットネットワーク中の各ノードのためのアドレス解決問い合わせを必ずしも実行せずに、先回りして獲得したアドレス解決マッピングをインストールする。

他方、ターゲットネットワークにあり、モバイルノードと通信を行っている各ノードもまた、モバイルノードがターゲットネットワークに接続し次第、モバイルノードのためのこれらのアドレス解決マッピングを更新する必要がある。また、上記の事前対応アドレス解決方法は、これらのノードが、モバイルノードがターゲットネットワークに接続する前に、モバイルノードのＭＡＣアドレスを先回りして解決するのにも使用できる。しかしながら、これはあまり望ましくない。というのは、これらのノードが、先回りして解決されたアドレス解決マッピングを用いる前に、モバイルノードのターゲットネットワークへの接続を検出する必要があるからである。より適切な手法は、接続検出とアドレス解決マッピング更新の統合にあると考えられる。これは、ターゲットネットワーク中の各ノードがモバイルノードのためのアドレス解決マッピングを迅速に更新できるように、モバイルノードが新しいネットワークに接続した直後に、モバイルノードが、ＩＰｖ４の場合のＡＲＰ要求又はＡＲＰ応答、又はＩＰｖ６の場合の隣接局告知を送信するアドレス解決［ＲＦＣ３３４４］、［ＲＦＣ３７７５］を余分に実行することに基づくものである。

４．４ トンネル管理
候補ターゲットネットワーク中のＤＨＣＰサーバから先回りしてＩＰアドレスが獲得された後、モバイルノードと候補ターゲットネットワークのアクセスルータの間に事前ハンドオーバトンネルが確立される。モバイルノードは獲得したＩＰアドレスをトンネル内アドレスとして使用し、十中八九、このアドレスを仮想インターフェースに割り当てる。

事前対応ハンドオーバトンネルは、トンネル管理プロトコルを使って確立される。事前対応ＩＰアドレス獲得にＩＫＥｖ２が使用されるときには、ＩＫＥｖ２は、トンネル管理プロトコルとしても使用される。代替として、事前対応ＩＰアドレス獲得にＰＡＮＡが使用されるときには、安全なトンネル管理プロトコルとしてＰＡＮＡが使用され得る。

モバイルノードと候補ターゲットネットワークのアクセスルータの間に事前対応ハンドオーバトンネルが確立されると、アクセスルータは、モバイルノードの新しいアドレスに向けられた任意のパケットを捕捉できるように、モバイルノードに代わってプロキシアドレス解決を実行する必要もある。

モバイルは、前のネットワークにある間、対応ノードと通信可能とする必要があるため、バインディング更新及び対応ノードからモバイルノードへのデータの一部又は全部を、事前対応ハンドオーバトンネルを介してモバイルノードに送り返す必要がある。ＳＩＰモビリティがモビリティ管理プロトコルに使用されるときには、連絡先アドレスとしての新しいアドレスが、ＳＩＰ Ｒｅ−ＩＮＶＩＴＥを使って対応ノードに報告される。対応ノードのＳＩＰユーザエージェントは、新しい連絡先アドレスを獲得すると、実際にはターゲットネットワークに属する新しい連絡先アドレスにＯＫを送る。ターゲットネットワーク中のアクセスルータは、これが新しい連絡先アドレスに向けられたためにこのＯＫ信号を取得し、これを以前のネットワークにあるモバイルにトンネルする。モバイルから対応ノードに最後のＡＣＫメッセージが受け取られる。モバイルから対応ノードへのデータは、イングレスフィルタリングがない場合には、トンネルされる必要がないこともある。ＳＩＰ Ｒｅ−ＩＮＶＩＴＥシグナリングハンドシェークの完了後、対応ノードからのデータは、事前対応ハンドオーバトンネルを介してモバイルに送られる。

モバイルノードがターゲットネットワークに接続した後でトラフィックがモバイルノードに向けられるように、事前対応ハンドオーバトンネルを、削除し、又は使用不可にする必要がある。このために、トンネルを確立するのに使用されたトンネル管理プロトコルが使用される。代替として、認証プロトコルとしてＰＡＮＡが使用されるときには、アクセスルータにおけるトンネル削除又は使用不可化は、モバイルがターゲットネットワークに移動し次第、ＰＡＮＡ更新機構によってトリガできる。リンク層トリガは、モバイルノードが、実際にターゲットネットワークに接続され、トンネルを削除し、又は使用不可にするトリガとしても使用できるようにする。

４．５ バインディング更新
異なるモビリティ管理方式のための数種類のバインディング更新機構がある。ＲＯ無しのモバイルＩＰｖ４などいくつかの場合には、バインディング更新は、ホームエージェントだけに送られ、モバイルＩＰｖ６の場合には、バインディング更新は、ホームエージェントと対応するホストの両方に送られる。ＳＩＰベースの端末モビリティの場合にも、モバイルは、Ｒｅ−ＩＮＶＩＴＥを使って、登録器と対応するホストの両方にバインディング更新を送る。モバイルと対応ノードの間の距離に基づいて、バインディング更新は、ハンドオーバ遅延の原因となる可能性がある。ＳＩＰ高速ハンドオーバ［ＳＩＰＦＡＳＴ］は、バインディング更新によるハンドオーバ遅延を低減するいくつかの方法を提供する。ＳＩＰベースのモビリティ管理を使用する安全な事前対応ハンドオーバの場合には、バインディング更新による遅延は、これが前のネットワークにおいて発生するために、完全に除外される。よって、この方式は、対応ノードが通信を行うモバイルノードから離れすぎているときには、より魅力的に思われる。

４．６ パケット喪失の防止
例示のＭＰＡの場合には、ＩＰアドレス獲得、セキュリティ保護された認証及びバインディング更新に起因するどんなパケット喪失も観測されなかった。しかしながら、リンク層ハンドオーバの間、ターゲットネットワークへの接続後にトラフィックがモバイルノードに向けられるまで、多少の一時パケットを発生できる。これらの一時パケットは失われることがある。アクセスルータにおける一時パケットのバイキャスト又はバッファリングを使って、パケット喪失を最小限に抑え、又は無くすことができる。しかしながら、双報は、リンク層ハンドオーバがシームレスに行われない場合には、パケット喪失を解決しない。他方、バッファリングは、パケット遅延を低減しない。パケット遅延はストリーミング用途では受信側においてプレイヤウトバッファによって補償できるが、プレイヤウトバッファは、大きな遅延ジッタを許容しない対話型ＶｏＩＰ用途にはあまり役に立たない。よって、いずれにせよ、リンク層ハンドオーバを最適化することが依然として重要である。

４．７ リンク層セキュリティ及びモビリティ
事前認証段階にモバイルノードと候補ターゲットネットワークの認証エージェントの間で確立されたＭＰＡ−ＳＡを使って、モバイルノードが現在のネットワークにある間に、候補ターゲットネットワークでのリンク層セキュリティを以下のようにブートストラップすることが可能である。リンク層セキュリティを詳細に説明するが、実施形態の中には、モバイルノードが現在のネットワークにある間に、候補ターゲットネットワークのＩＰ層及び／又は上位層のセキュリティのブートストラップを同様に提供できるものもある。

（１）候補ターゲットネットワークの認証エージェント及びモバイルノードは、正常な事前認証の結果として確立されるＭＰＡ−ＳＡを使ってＰＭＫ（対状マスタキー）［I-D.ietf-eap-keying］を導出する。ＭＰＡ−ＳＡを確立する事前認証の間には、ＥＡＰ及びＡＡＡプロトコルの実行が関与できる。ＰＭＫから、モバイルノードの互いに異なるＴＳＫ（一時セッション鍵）［I-D.ietf-eap-keying］が、候補ターゲットネットワークの各接続点ごとに直接的又は間接的に導出される。

（２）認証エージェントは、ＰＭＫから導出され、接続点への安全なアソシエーションに使用される鍵をインストールできる。導出される鍵は、ＴＳＫとすることも、ＴＳＫを導出するための中間鍵とすることもできる。

（３）モバイルノードは、候補ターゲットネットワークをターゲットネットワークとして選択し、（これからモバイルノードの新しいネットワークになる）ターゲットネットワークの接続点に切り換えた後で、モバイルノードと接続点の間のリンク層パケットを保護するのに使用されるＰＴＫ（対状一時鍵）及びＧＴＫ（グループ一時鍵）［I-D.ietf-eap-keying］を設定するために、ＰＭＫを使って、ＩＥＥＥ８０２．１１ｉ４方向ハンドシェーク［８０２．１１ｉ］などの安全なアソシエーションプロトコルを実行する。ここでは、さらなるＥＡＰ認証の実行は必要とされない。

（４）モバイルノードは、新しいネットワークでローミングしている間、これの接続点と安全なアソシエーションプロトコルを実行しさえすればよく、さらなるＥＡＰ認証は必要とされない。このようにしてＭＰＡの、８０２．１１ｒなどのリンク層ハンドオーバ最適化機構との統合がアーカイブできる。

モバイルノードは、ＴＳＫを導出するために候補ターゲットネットワークの接続点のリンク層識別情報を知る必要があることもある。事前認証用の認証プロトコルとしてＰＡＮＡが使用される場合、これは、ＰＡＡ［I-D.ietf-pana-pana］から送られるＰＡＮＡバインドリクエストメッセージで、各ＡＶＰが互いに異なるアクセスポイントのＢＳＳＩＤを含む、機器ＩＤ ＡＶＰを搬送することによって可能である。

リンクレイヤセキュリティに加えて、ＩＰレイヤ及び／又は上位のレイヤのためのセキュリティはモバイルノードが現在のネットワークになお存在している間、候補ネットワークに対して同様にブートストラップできる。

４．８ 初期ネットワーク接続における認証
モバイルノードがネットワークに最初に接続するときには、ＭＰＡの使用に関わらず、ネットワークアクセス認証が行われるはずである。ＭＰＡがハンドオーバ最適化に使用されるときのネットワークアクセス認証に使用されるプロトコルは、ＩＥＥＥ８０２．１Ｘなどのリンク層ネットワークアクセス認証プロトコル又はＰＡＮＡなどより上位層のネットワークアクセス認証プロトコルとすることができる。

５．初期実装及び結果
ＭＰＡと非ＭＰＡベース両方の手法を評価する具体的シナリオを説明する。この項では、ＭＰＡ及び非ＭＰＡの具体的実装の１つの詳細を説明する。実装詳細に加えて、この項では、ＭＰＡを用いた最適化ハンドオフの評価結果を示すと共に、これを非ＭＰＡベースのハンドオーバと比較する。

５．１ ネットワーク構造
図１に実験ネットワーク構造を示す。

この実装環境においては３つのネットワークが定義されている。ネットワーク１は旧い接続点（ｏＰｏＡ）であり、ネットワーク２は新しい接続点（ｎＰｏＡ）であり、ネットワーク３は対応ノード（ＣＮ）のあるネットワークである。モバイルは、最初はネットワーク１にあり、対応ノードとの通信を開始する。ネットワーク１、ネットワーク２、及びネットワーク３は、隣接し合う必要はない。しかしながら、例示の実装シナリオにおいては、ネットワーク１、ネットワーク２、及びネットワーク３は１ホップ離れている。モバイルの移動の場合には、特定のモビリティ管理プロトコル（ＭＭＰ）が、ピアツーピアアプリケーションによってセットアップされたストリーミングトラフィックの連続性を処理できる。

ネットワーク１は、ＤＨＣＰサーバ１、アクセスポイント（ＡＰ）１及びアクセスルータ１を含む。ネットワーク２は、ＤＨＣＰサーバ２、ＡＰ２及びアクセスルータ２を含む。ＡＰ１及びＡＰ２は８０２．１１無線ＬＡＮアクセスポイントである。また、ルータ２は、ネットワーク２のＰＡＮＡ認証エージェント（ＰＡＡ）［I-D.ietf-pana-pana］及びＤＨＣＰリレーエージェント［ＲＦＣ３０４６］としても機能するが、これらは別個のものとすることもできる。また、ＤＨＣＰリレーエージェントは、隣接するターゲットネットワークから先回りしてモバイルのＩＰアドレスを獲得するのに役立つ構成エージェント（ＣＡ）のようにも機能する。ネットワーク３は、ネットワーク１のモバイルノードと通信を行う対応ノード（ＣＮ）を含む。対応ノードもモバイルノードも、モビリティ対応ＳＩＰクライアントを備える。また、モバイルＳＩＰクライアントも、ＰＡＮＡクライアント（ＰａＣ）を備える。この具体例においては、対応ノードとモバイルノードの間の初期通信のセットアップにＳＩＰプロキシは関与しない。モバイルノード（ＭＮ）は、アクセス方法として８０２．１１無線ＬＡＮを使用し、モバイルノードがＡＰ２を介して通信を行うネットワーク２に移動する前に、ＡＰ１を介して通信を行うことができる。この具体例では、モビリティ管理プロトコル（ＭＭＰ）はＳＩＰモビリティ（ＳＩＰ−Ｍ）であり、構成プロトコルはＤＨＣＰであり、認証エージェント（ＡＡ）はＰＡＡであり、構成エージェント（ＣＡ）はＤＨＣＰリレーエージェントであり、アクセスルータ（ＡＲ）は、ＩＰ−ｉｎ−ＩＰトンネリング［ＲＦＣ１８５３］管理機能を提供することのできるルータ２である。また、ＭＮも、ＩＰ−ｉｎ−ＩＰトンネリング管理機能を備える。よって、モバイルは、トンネルインターフェースをセットアップし、ルータ２とモバイルの間のトンネルを介して送られるパケットをデトンネルすることができる。この具体例では、ＩＰｖ４を使用しているが、ＭＩＰｖ６やＩＰｖ６を介したＳＩＰモビリティなど、ＩＰｖ６用のモビリティ管理を使用することもできる。

５．２ ＭＰＡシナリオ
この実装環境におけるＭＰＡでの通信の流れを以下で説明し、図５に示す。

ステップ０：ＭＮは、ブートストラップする際に、ＡＰ１と連携し、ネットワーク１のＤＨＣＰサーバからＩＰアドレス旧気付アドレス（ｏＣｏＡ）を獲得する。ＭＮのＳＩＰユーザエージェントは、ＣＮのＳＩＰユーザエージェントと通信を行う。モバイルと対応ノードの間の正常な接続セットアップの後、音声トラフィックがＭＮとＣＮの間を流れる。この音声トラフィックは、ＲＴＰ／ＵＤＰを介して搬送される。メディアエージェントとして、ＲＡＴ（Robust Audio Tool）を使用している。

ステップ１（事前認証段階）では、ＭＮの移動によりＡＰ１のリンクレベルが低下するなど、ステップ１への何らかのトリガがある。ＭＮは、ハンドオーバプロセスを開始する用意をし、情報サーバから必要なターゲットネットワークの要素に関する情報を獲得する。次いで、ＭＮは、ＰＡＡと事前認証を行い、事前認証に成功した場合には、ＭＰＡ−ＳＡからＭＮ−ＣＡ鍵及びＭＮ−ＡＲ鍵を導出する。

ステップ２（事前構成段階）で、ＭＮは、ＤＨＣＰプロキシと通信を行ってＩＰアドレスなどを獲得することによって事前構成を行う。この場合、ＤＨＣＰプロキシと認証エージェント（ＡＡ）は同じ場所に位置する。このＩＰアドレスは、モバイルが新しいネットワークに移動した後で獲得しているはずの新しい気付アドレス（ｎＣｏＡ）である。ＤＨＣＰプロキシはＤＨＣＰサーバ２からＩＰアドレスを取得する。モバイルの新しいＩＰアドレスは、これの事前認証プロセスの一部としてモバイルに戻される。ＭＮが新しいＩＰアドレス（ｎＣｏＡ）を取得した後で、ルータ２とモバイルの間にＩＰ−ｉｎ−ＩＰトンネルが作成される。

この時点において、ＭＮ及びルータ２の挙動は、基本的に［ＲＦＣ１８５３］に従い、信号はＭＮ−ＣＡを使用し、暗号によって保護される。

ステップ３（安全な事前対応ハンドオーバの主段階）で、モバイルが、これの仮想インターフェース上で新しいＩＰアドレス（ｎＣｏＡ）を用いて構成され、モバイルとＲ２の間にトンネルがセットアップされると、ＭＮは、これの連絡先アドレスとしてのｎＣｏＡと共にＳＩＰ Ｒｅ−ＩＮＶＩＴＥをＣＮに送る。ＳＩＰ Ｒｅ−ＩＮＶＩＴＥシグナリングすべてがトンネルを介して搬送され、新しいＲＴＰストリームも搬送される。よって、モバイルは、ＣＮがトラフィックをｎＣｏＡに送った場合でも、旧いネットワークにおいてトラフィックを受け取る。

ステップ４（安全な事前対応ハンドオーバスイッチング前段階）：モバイルは、新しい接続点を検出し、新しいネットワークに切り換わる決定を行う際に、ＡＰ２と連携する。この時点において、モバイルは、ｎＣｏＡをこれの物理インターフェースに割り当てることによってモバイル自体を構成し、ネットワーク１において事前構成段階の間に格納されるローカルキャッシュからデフォルトルータを更新する。ＭＮは、アクセスルータＲ２にＰＡＮＡ更新リクエストメッセージを送る。この更新メッセージは、ルータＲ２上のトンネルを削除し、トンネルをモバイル上でローカルに削除する。また、モバイルのｎＣｏＡを用いたＡＲＰエントリも安全な事前対応ハンドオーバの間にルータＲ２において更新され、よって、普通は新しいノードがネットワークに入るときに発生するＡＲＰプロセスによる遅延が低減される。

ＥＡＰ事前認証
アクティブ通信セッション中のモバイルは１つのアクセスネットワークから他のアクセスネットワークに移動し、その接続点を変更するとき、それは関連するハンドオーバ動作によりサービスの連続性に乱れを生じる。ハンドオーバ処理中に、モバイルがネットワークの接続点を変えると、それはそのサブネット又はそれが接続される管理ドメインを変更できる。

ハンドオーバはモバイルに割り当てられる資源の取得又は修正のために認証を要求することがあり、認証はドメイン内の中央権限との対話を必要とする。多くの場合、ハンドオーバ手順中の認証手順はドメインの中央権限と対話も必要とする認証手順に従う。そのような認証及び承認に由来する遅延はハンドオーバ遅れに加算し、必然的に進行中のマルチメディアセッションに影響を与える。

認証及び承認手順はＡＡＡサーバがハンドオーバ中のＥＡＰメッセージングに含まれる可能性がある場合にＥＡＰ認証を含むことができる。アーチテクチャのタイプに依存して、場合によっては、ネットワークサービスが新たなネットワークにおけるモバイルに対して許可される前にＡＡＡ信号はモバイルのホームドメインにおけるＡＡＡサーバに対しても最後までトラバーズする。

ＶｏｌＰのようなリアルタイム通信／双方向トラフィックは遅延に非常に敏感である。故に、モバイルとＡＡＡサーバ間の相互作用はハンドオーバ中には回避又は減少されなければならない。

このセクションで検討したＥＡＰ事前認証はモバイル装置及び候補オーセンティケータが同じサブネットになく又は同じリンクレイヤのものでない環境で主に扱われる。ＥＡＰ事前認証のそのような使用はモバイル装置が候補オーセンティケータの１つに接続する前にキーを認証及びセットアップすることを可能にすることになる。

このフレームワークは事前信号伝達が効果を発揮する種々の展開シナリオに対する一般的適応性を有する。即ちＥＡＰ事前認証の適応性は候補オーセンティケータが容易に発見し得る場合のシナリオに限定され、移動の正確な予測が容易になし得る。また、ＥＡＰ事前認証の有効性は多数の技術の同時使用が主要な関心事でない、又は異なる技術間の十分な無線サービスエリアの重なりがある場合に特定の技術間ハンドオーバシナリオにとって重要でないかもしれない。

ＥＡＰ事前認証においては、候補オーセンティケータに対するＡＡＡ認証及び承諾はアプリケーションセッションがサービスネットワークを介して進行中である。ＥＡＰ事前認証の目的は装置が移動したとき又は直後にＥＡＰに対するＡＡＡ信号伝達を回避することにある。

図３はＥＡＰ事前認証に関連する機能素子を示す。図３を参照すると、モバイルノードはサービスアクセスネットワークに接続される。モバイルノードはサーバアクセスネットワークから候補アクセスネットワークまでハンドオーバを行う前に、それは候補オーセンティケータ、候補アクセスネットワークのオーセンティケータによって、サービスアクセスネットワークを介してＥＡＰ事前認証を行う。モバイルノードは１以上の候補オーセンティケータによってＥＡＰ事前認証を行うことができる。各オーセンティケータはオーセンティケータが異なるＩＰリンクに存在するときにＩＰアドレスを有すると仮定する。サービスアクセスネットワークがサービングオーセンティケータを持つかどうかが分からない間では各候補アクセスネットワークに少なくとも１つの候補オーセンティケータが存在すると仮定する。サービス及び候補アクセスネットワークが異なるリンクレイヤ技術を用いることができる。

各オーセンティケータは独立ＥＡＰオーセンティケータ又はパススルーＥＡＰオーセンティケータのいずれかであるＥＡＰオーセンティケータの機能性を持つオーセンティケータが独立ＥＡＰオーセンティケータとして作用するとき、それはＥＡＰサーバの機能性も持つ。他方、オーセンティケータがパススルーＥＡＰオーセンティケータとして作用するとき、それはＲＡＤＩＵＳ及びＤｉａｍｅｔｅｒのようなＡＡＡプロトコルを用いてＡＡＡサーバで一般的に実施されるＥＡＰサーバと通信する。

候補オーセンティケータは下位層暗号化キーを生成するためにＭＳＫ（マスタセッションキー）を使用する既存のリンクレイヤ技術のものであれば、ＥＡＰ事前認証は候補オーセンティケータに対するＭＳＫを事前に生成するために使用される。

サービングオーセンティケータがＥＡＰ事前信号伝達にどのように含まれるかに依存して、モバイルノード、サービングオーセンティケータ、候補オーセンティケータの間でＥＡＰ事前認証信号伝達がどのように起こすことができるかに関する２つのシナリオがある。サービングオーセンティケータ及び候補オーセンティケータとの間のセキュリティ関連性は両事前認証シナリオに対して必要としない。

第１シナリオ、直接事前認証信号伝達、が図４に示される。このタイプの事前認証では、サービングオーセンティケータはそれが任意の他のデータトラフィックであり又はサービスアクセスネットワークに全くサービングオーセンティケータが存在しないかもしれないのでＥＡＰ事前認証トラフィックを転送する。そして、ＭＮはＭＮ−ＣＡ信号伝達（Ｌ２又はＬ３）を介して通信する。

第２シナリオ、間接事前認証信号伝達、が図５に示される。間接事前認証によって、サービングオーセンティケータはＥＡＰ事前信号伝達に含まれる。例えば、ＭＮがＣＡ７ｓＩＰアドレスを発見できなければ又はセキュリティの理由のためＩＰ通信は候補オーセンティケータと不承認ノードとの間で許可されなければ、間接事前認証は必要としない。間接事前認証信号伝達はモバイルノード−サービングオーセンティケータ信号伝達（ＭＮ−ＳＡ信号伝達）及びサービングオーセンティケータ候補オーセンティケータ信号伝達（ＳＡ−ＣＡ信号伝達）に継ぎ合わせる。ＳＡ−ＣＡ信号伝達はＬ３を介して行われる。ＭＮ−ＳＡ信号伝達はＬ２又はＬ３を介して行われる。間接事前認証におけるサービングオーセンティケータの役割はモバイルノードと候補オーセンティケータとの間でＥＰＡ事前認証信号伝達を転送すること及びそれが通常認証信号伝達に対するＥＡＰオーセンティケータとして作用している間はＥＡＰオーセンティケータとして作用しないことである。これは図６に示されている。

故に、次の機能素子が幾つかの実施例：（１）８０２．２１仕様で定義されている機能性に加えて、ＭＮは次の機能性、即ちＥＡＰピアを持つモバイルノード（ＭＮ），及び（２）８０２．２１仕様で定義されている機能性に加えて、ＰｏＡは次の機能性、即ち、ＥＡＰオーセンティケータ、間接事前認証のための事前認証転送を有し、ＰｏＡはＭＩＨＰｏＳとして作用する接続点（ＰｏＡ）に採用し得る。

メディア独立ハンドオーバサービス：
Draft IEEE Standard for Local and Metropolitan Area Networksと名称付けられた、2006年9月の I.E.E.E. P802.21/D.01.09、即ち、メディア独立ハンドオーバサービス（その全開示は参照によりここに援用される）において、特に、文献は８０２方式とセルラー方式との間のハンドオーバを最適化する８０２メディアアクセス独立機構を特定している。Ｉ．Ｅ．Ｅ．Ｅ． ８０２．２１規格は異種８０２方式間のハンドオーバの最適化を可能にし、８０２方式とセルラー方式との間のハンドオーバを容易にできる拡張メディアアクセス独立機構を定義している。

ＩＥＥＥ ８０２．２１（メディア独立ハンドオーバ）規格の範囲は異種メディア間のハンドオーバを最適化するためリンクレイヤ情報及び上位レイヤに関連する他のネットワーク情報を提供する仕様を展開することである。これは３ＧＰＰ， ３ＧＰＰ２及びＩＥＥＥ ８０２ファミリの規格の有線及び無線メディアの両方によって特定される。この文献では、特に断りない限り、「メディア」は感覚態様の通信（例えば、オーディオ、ビデオ、など）とは対照的に、電話通信方式（例えば、ケーブル、無線、サテライト、など）をアクセスする方法／モードを参照している。Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Servicesと名称付けられた、２００６年９月のI.E.E.E. P802.21/D.01.09の１．１を参照。その文献の全内容は上記参照の仮出願のＰＡＲＴ Ｃ内に完全に援用されることによってこの特許出願に及びその一部に援用される。

ＩＥＥＥ ８０２．２１規格は多種のハンドオーバ方法を容易にすることを意図している。そのような方法は一般的にハンドオーバ手順がモバイルノードとネットワークとの間でデータパケットの交換をサポートするデータ転送設備に関して「作る前に壊す」又は「壊す前に作る」かどうかに依存して「ハード」又は「ソフト」として分類される。

一般的に、ハンドオーバはネットワークオペレータ及びエンドユーザニーズを満足するためにモバイルノードとネットワークインフラストラクチャの両方の共同使用を含む。ハンドオーバ政策決定に含まれるハンドオーバ制御、ハンドオーバ政策及び他のアルゴリズムは一般的にＩＥＥＥ ８０２．２１規格の範囲に入らない通信方式素子によって処理される。しかしながら、それは全体のハンドオーバにおけるＭＩＨイベントサービス，ＭＩＨコマンドサービス，ＭＩＨ情報サービス及びＭＩＨＦの役割及び目的が明らかになるように全体のハンドオーバ手順のある態様を記述することに役立つ。

一般設計原理
ＩＥＥＥ ８０２．２１規格は次の一般設計原理に基づく。

ａ）ＭＩＨ機能はハンドオーバ政策決定を援助し、容易にするロジカルエンティティである。上位レイヤはＭＩＨＦからの入力及びコンテクストに基づいてハンドオーバ決定及びリンク選択を行う。有効なハンドオーバ決定をする方法に関する情報の発見は主要な要素ともなる。

ｂ）ＭＩＨＦは上位レイヤに抽象化サービスを提供する。その見込みＭＩＨＦから統一インターフェースを上位レイヤに提供する。この統一インターフェースによって明らかにされるサービスプリミティブは異なるアクセスネットワークの技術的特定プロトコルエンティティに基づく。ＭＩＨＦは技術特定インターフェースを介してモバイル管理プロトコルスタックの下位レイヤと通信する。

下位レイヤとのＭＩＨＦインターフェースの仕様は一般的にはこの規格の範囲内にはない。そのようなインターフェースはＩＥＥＥ ８０２．１，ＩＥＥＥ ８０２．３，ＩＥＥＥ ８０２．１１，ＩＥＥＥ ８０２．１６，３ＧＰＰ及び３ＧＰＰ２のような個別のアクセス技術に関連する規格内のサービスアクセスポイント（ＳＡＰｓ）としてすでに特定されているかもしれない。この規格は下位レイヤインターフェースの変形がＭＩＨＦ機能性を可能にする又は高めるかもしれないときに既存のアクセス技術特定規格を改定する推奨を含めることを可能にする。

ｃ）（ハンドオーバ実行及び後続の更新の一部としての）ハンドオーバ信号伝達は規格の一部とはならないかもしれない。異なるアクセスネットワークは水平ハンドオーバ機構（モバイル主導型、ネットワーク主導型、など）をサポートする。ハンドオーバ開始トリガは均一方式のように行われないときに不均一ハンドオーバにおいて使用できる。

ｄ）ＭＩＨＦはＭＡＣ／ＰＨＹトリガ及び他の関連した局所的事象に関する処理を更に行うことができる。この処理の定義は規格の範囲外である。規格は遠隔的事象に対しても当然サポートを提供する。事象は本来助言的である。ハンドオーバを生じさせるかこれら事象に基づかないかの決定は規格の範囲外である。

ｅ）規格はＭＮ開始、ＭＮ制御、ネットワーク主導型及びネットワーク制御ハンドオーバをサポートする機構を規定するものとする。

ｆ）規格はレガシ機器との透明性の相互動作をサポートできる。故に、ＩＥＥＥ ８０２．２１互換性機器はレガシ非ＩＥＥＥ ８０２．２１対応機器と共存できるべきである。

メディア独立ハンドオーバ参照フレームワーク
次の記述はクライアント装置（ＭＮ）とネットワークにおける異なるＭＩＨＦ要素間の通信に関して重要な及び顕著な特徴を記載している。

ＭＩＨＦ機能は種々の目的のために互いに通信する。クライアント装置（モバイルノード）はＭＩＨをそのＭＩＨサービス点と交換する。任意のネットワーク要素のＭＩＨＦはそれがＭＩＮに基づくＭＩＨＦと直接に通信するときにＭＩＨＰｏＳとなる。ＭＩＨネットワーク要素ＭＮへの直接接続をしないかもしれなく、それ故にその測定のＭＮに対するＭＩＨＰｏＳを構成しない。同じＭＩＨネットワーク要素が異なるＭＮに対するＭＩＨ ＰｏＳとしても作用できる。ＭＩＨＦ通信はＭＩＨケーブルＭＮケーブルＭＩＨの全てのＬ２インターフェースで行われないかもしれない。例として、３つのＬ２インターフェース、即ち８０２．１１， ８０２．１６，及び８０２．３を持つＭＩＨケーブルＭＮに関しては、８０２．３インターフェースがシステム管理及び保守業務に対してだけ使用でき、これに対して８０２．１１及び８０２．１６インターフェースはＭＩＨＦサービスを提供する。ＭＮはＭＩＨ ＰｏＳのネットワークＰｏＳと同じネットワーク要素にあるＭＩＨ ＰｏＳとＭＩＨ情報を交換するためのＬ２移送を使用できる。ＭＮはＭＩＨ ＰｏＳのネットワークＰｏＡと同じネットワーク要素にないかもしれないＭＩＨ ＰｏＳとＭＩＨ情報を交換するためのＬ３移送を使用できる。フレームワークはＭＩＨネットワーク要素間の通信に向けてＬ２又はＬ３機構のいずれかの仕様をサポートする。

図７はＭＩＨ通信モデルを示す。モデルは異なる特殊な役割のＭＩＨＦｓ及びそれらの間の通信関係を示す。通信モデルの通信関係の各々は特定の搬送機構を暗示していないことに留意することが重要である。むしろ、通信関係はＭＩＨＦ関連情報通過が２つの特殊なＭＩＨＦｓの間で可能であることを示すことを意図しているだけである。更に、１）ＭＮに関するＭＩＨＦ、２）ＭＮのサービスＰｏＡを含むネットワーク要素に関するＭＩＨ ＰｏＳ、３）ＭＮに対する候補ＰｏＳを含むネットワーク要素に関するＭＩＨ ＰｏＳ（候補ＰｏＳはＭＮが現在接続されていないことを認識しているＰｏＡであり、それはハンドオーバが最終的に生じれば目標ＰｏＡになる）、４）ＭＮに対するＰｏＡを含まないネットワーク要素に関するＭＩＨ ＰｏＳ、５）ＭＮに対するＰｏＡを含まないネットワーク要素に関するＭＩＨ ｎｏｎ−ＰｏＳ。

通信モデルはＭＩＨＦｓの異なる事例間の次の通信基準点を認識もする。

１）通信基準点Ｒ１：基準点Ｒ１はＭＮに関するＭＩＨＦとそのサービスＰｏＡのネットワーク要素に関するＭＩＨ ＰｏＳとの間のＭＩＨＦを参照している。Ｒ１はＬ２及びＬ３の両方以上を介した通信インターフェースを包み込むことができる。Ｒ１を通過したＭＩＨＦ内容はＭＩＩＳ，ＭＩＥＳ又はＭＩＣＳに関連できる。

２）通信基準点Ｒ２：基準点Ｒ２はＭＮに関するＭＩＨＦと候補ＰｏＡのネットワーク要素に関するＭＩＨ ＰｏＳとの間のＭＩＨＦ手順を参照する。Ｒ２はＬ２とＬ３の両方以上を介する通信インターフェースを包み込むことができる。Ｒ２を通過したＭＩＨＦ内容はＭＩＩＳ，ＭＩＥＳ，又はＭＩＣＳに関連できる。

３）通信基準点Ｒ３：基準点Ｒ３はＭＮに関するＭＩＨＦとｎｏｎ−ＰｏＡネットワーク要素に関するＭＩＨ ＰｏＳとの間のＭＩＨＦ手順を参照している。Ｒ３はＬ３以上を介する通信インターフェース及び場合によってはイーサネット（登録商標）ブリッジ、ＭＰＬＳなどのようなＬ２トランスポートプロトコルを含むことができる。Ｒ３を通過したＭＩＨＦ内容はＭＩＩＳ，ＭＩＥＳ，又はＭＩＣＳに関するかもしれない。

４）通信基準点Ｒ４：基準点Ｒ４はネットワーク要素のＭＩＨ ＰｏＳと他のネットワーク要素のＭＩＨ ｎｏｎ−ＰｏＳ事例との間のＭＩＨＦ手順を参照する。Ｒ４はＬ３以上を介する通信インターフェースを含むことができる。Ｒ４を通過したＭＩＨＦＭＩＨＦはＭＩＩＳ，ＭＩＥＳ又はＭＩＣＳに関するかもしれない。

５）通信基準点Ｒ５：基準点Ｒ５は異なるネットワーク要素の２つのＭＩＨ ＰｏＳ事例の間のＭＩＨＦ手順を参照する。Ｒ５はＬ３以上を介する通信インターフェースを含むことができる。Ｒ５を通過したＭＩＨＦ内容はＭＩＩＳ，ＭＩＥＳ又はＭＩＣＳに関するかもしれない。

ＭＩＨ通信モデルの具体例
ＭＩＨサービスを含むネットワークモデルはＭＩＨ通信基準点の重要な説明のために図８に示される。右から左へ移動すると、モデルはＭＩＨ可能モバイルノード（一番右よりのＭＮ）を含む。これは複数の有線及び無線アクセス技術オプションをサポートする。モデルはプロビジョニングサービスプロバイダが複数のアクセス技術を活用するか、又はインターワーキングをサポートしてＳＬＡが確立されたときそのユーザが他のネットワークにロームすることを可能にするかのいずれかであると仮定する。ＭＮはそれが特定のＭＩＨ質問を送ることを可能にする実行されたＭＩＨＦを有する。ＭＮは内部的に部分的に実行される情報サービスを受けることができる。

モデルは幾分ゆるい連続方法でコアネットワーク（オペレータ１−３コア）に接続されるアクセスネットワークを示している。また、より堅く相互作用し又は結合されるアクセスネットワーク（アクセスネットワーク−３）が示されている。オペレータ１−３コアは各々サービスプロバイダ、企業イントラネットプロバイダー又はビジタ若しくはホームアクセスの普通の部分、又はイーブンコアネットワークを表す可能性がある。このモデルでは、プロビジョニングネットワークがＲ１を介してコア（ラベル付きビジタ／ホームコアネットワーク）に結合されるアクセスネットワーク−３を動作している。用語ビジタ及びホームはプロビジョニングサービスプロバイダ又は企業を示すために使用される。図示のネットワークのいずれもＭＮの提供者（provisioner）に対するオペレータの関係に依存してビジタ又はモームネットワークの両方である可能性がある。

ネットワークプロバイダはそれらのネットワークへのハンドオーバを容易にするためにそれらのアクセスネットワーク（アクセスネットワーク−１乃至４）においてＭＩＨサービスを提供する。各アクセス技術はそのＭＩＨキャパビリティを宣伝するかＭＩＨサービスディスカバリに応答するかのいずれかである。アクセスネットワークに対する各サービスプロバイダはサービス上の１以上のＭＩＨ点（通信モデルと比較するＰｏＳ）へのアクセスを可能にする。これらＰｏＳはＭＩＨ能力発見（capabilities discovery）中に決定されるようにＭＩＨサービスの幾らか又は全てを提供できる。ＭＩＨＰｏＳの位置又はノードは規格によって固定されない。ＰｏＳ位置はオペレータ展開シナリオ及び技術特定ＭＩＨアーチテクチャに基づいて変わる可能性がある。

ＭＩＨＰｏＳはアクセスネットワーク（アクセスネットワーク１，２，３が代表的である）における接着点（ＰｏＡ）に次いで存在でき又は同位置となり得る。或いは、ＰｏＳはアクセス又はコアネットワーク（アクセスネットワーク３が代表的である）の内側に深く存在できる。図３に示されるように、ＭＮのＭＩＨエンティティは任意のアクセスネットワークを介してＲ１，Ｒ２又はＲ３のいずれかによってＭＩＨネットワークエンティティと通信する。サービスアクセスネットワークのＰｏＡが同位置のＭＩＨ関数を有するとき、Ｒ１基準接続はＰｏＳでもあるＰｏＡで終端する（モデルのアクセスネットワーク１，２，４に対するＭＮは全てＲ１である可能性がある）。その場合、Ｒ３基準接続は（アクセスネットワーク１，２，４に対するＭＮによっても示される）任意の非ＰｏＡで終端することになる。ＭＩＨ事象はアクティブＲ１リンクの両側に起こる可能性がある。ＭＮは代表的にはこれら事象に対処する第１ノードである。

ビジタ及びホームネットワークの相互作用は制御及び管理目的のため又はデータ転送目的のためのいずれかになる。ローミング又はＳＬＡ合意によりホームネットワークはＭＮがビジタネットワークを直接介して公共インターネットをアクセスすることを可能にする。図示するように、２つのＭＮネットワークエンティティはＲ４又はＲ５基準接続を介して互いに通信できる。ＭＩＨ可能ＰｏＡもＲ３及びＲ４基準点を介して他のＭＩＨネットワークエンティティと通信できる。ＭＩＨ可能ＭＮは候補ネットワークに関する情報サービスを得るためにＲ２基準点を介して候補アクセスネットワークにおいて他のＰｏＡとのＭＩＨ通信を可能にする。

ＭＩＨ情報サービス（ＭＩＳ）に関してプロバイダはＭＩＨＰｏＳノード（上方左端）に廃止されるそれらの情報サーバに対してアクセスする。オペレータは複数のモバイルノードが新たなロームリストに限定されないが、コスト、プロバイダ認識情報、プロバイダサービス、優先度及びサービスを選択及び利用できる任意の他の情報を含む関連情報を得ることができるようにＭＩＳを前記モバイルノードに提供する。図示するように、モバイルノードがそのプロバイダによってＭＩＳデータを事前に提供し得る。

また、モバイルノードがそのプロバイダの任意のアクセスネットワークからＭＩＨ情報サービスを得ることができる。ＭＩＳはそのネットワークのＭＩＳサービス点を用いて、他の重複又は隣接ネットワークからも利用できる。（ここではアクセスネットワーク３と結合されるように示されている）供給者のネットワークは供給者の又はビジタネットワークのＭＩＨ情報サーバと同様に他のＭＩＨエンティティをアクセスするためＲ３及びＲ４インターフェースを利用できる。

ＭＩＨコマンドサービス（ＭＩＣＳ）に関して、情報データベースのどれかはコマンドサービスＰｏＳとして使用もできる。ＭＮ ＭＩＨＦは一般にレイヤ３トランスポートを用いてこのサーバと通信する。

ＭＩＨＦサービス
ＭＩＨＦはリンクレイヤ及びＭＩＨユーザのために明確なＳＡＰｓを介して非同期及び同期サービスを提供する。任意のタイプの複数のネットワークインターフェースを有するシステムの場合、下位インターフェースの状態を管理し、決定し、制御するため上位レイヤはイベントサービス、コマンドサービス及びＭＩＨによって提供される情報サービスを用いることができる。

ＭＩＨによって提供されるこれらサービスはサービスの連続性、サービスの可変品質に対するサービス適用、バッテリ寿命維持、及びネットワークディスカバリ・リンク選択を維持するときに上位レイヤを支援する。８０２タイプ及びセルラ３ＧＰＰ，３ＧＰＰ２タイプの異種ネットワークインターフェースを含むシステムにおいては、メディア独立ハンドオーバ機能は異種ネットワークインターフェースを介してサービスを結合する有効手順を実行するため上位レイヤを支援できる。上位レイヤは異種ネットワーク間のハンドオーバ動作に必要な資源を問い合わせるために異なるエンティティを介してＭＩＨＦによって提供されるサービスを利用できる。

モバイル装置におけるＭＩＨサービスは異種ネットワーク間でシームレスハンドオーバを容易にする。モビリティ管理プロトコル（事例モバイルＩＰ）のようなＭＩＨユーザはハンドオーバ及びシームレスセッション連続性に対してサポートし得る。これはハンドオーバを最適化するためにＭＩＨサービスを使用することからモバイルＩＰ及び同等の他の上位レイヤに加えて他のプロトコルを除外することになる。

ＭＩＨサービスを採用するモバイルノードはイベントサービスと同様に非同期動作のためにリンクレイヤからの指示を受けることになる。コマンドサービスと情報サービスの相互作用は非同期質問及びメカニズムの応答タイプを介すことになる。ＭＩＨＦはネットワークと同じメデイアタイプのホストエンティティとの間での情報交換のための機能も提供することになる。そのような情報交換のためのメカニズムがすでに（幾つかのセルラメディアタイプを持つような）所定タイプのメディアと共に存在すれば、ＭＩＨＦは可能ならいつでも既存のメカニズムを使用することになる。

ＭＩＨプロトコル
ＩＥＥＥ８０２．２１規格はメディア独立イベントサービス、メディア独立コマンドサービス及びメデイア独立情報サービスをサポートする。ＭＩＨプロトコルは遠隔ＭＩＨＦエンティティ間で交換されるメッセージ（即ち、ヘッダ及びペイロードを持つＭＩＨＦパケット）のフォーマット及びメッセージの搬送をサポートするトランスポートメカニズムを定義する。トランスポートメカニズムの選択はＭＮをネットワークに接続するアクセス技術及びＭＩＨＰｏＳの位置に依存する。

これらサービスのためのパケットペイロードはＬ２管理フレーム、Ｌ２データフレーム又は他の上位レイヤプロトコルを介して搬送し得る。８０２．１１及び８０２．１６のような無線ネットワークは管理計画を有し、上記ペイロードを搬送するために適宜に改良し得る管理フレームをサポートする。しかしながら、有線イーサーネットネットワークは管理計画を持たなく、データフレームにおいてだけ上記ペイロードを搬送できる。

ＩＥＥＥ ８０２．２１規格は標準ＩＬＶフォーマットにメディア独立方法でパケットフォーマット及びペイロードを定義する。その後、これらパケットはペイロードがイーサネットの場合のように通常データフレームを介して送信する必要があるときにＭＩＨＦイーサタイプ（ethertype）を用いてＬ２ＭＩＨプロトコルにカプセル化し得る。他の場合には、ＴＬＶ使用メッセージ及びペイロードがメディア固有管理フレームに直接的にカプセル化し得る。或いは、ＭＩＨプロトコルメッセージは下位レイヤ（Ｌ２）又は上位レイヤ（Ｌ３及び上記）トランスポートを用いてカプセル化し得る。そのような情報交換のメカニズムが（幾つかのセルラメディアタイプのような）所定タイプのメディアと共にすでに存在していれば、ＭＩＨＦは可能ならいつでも既存のメカニズムを使用する。

ＩＥＥＥ ８０２．２１規格はＭＩＨプロトコルデータユニット（ＰＤＵ）ヘッダ及びペイロードのフォーマットを規定する。標準ＴＬＶフォーマットはＰＤＵペイロードコンテンツのためのメディア独立表現を提供する。ＭＩＨＦ ＰＤＵｓは８０２リンクを介してＭＩＨＦイーサタイプでデータフレームにカプセル化される。８０２．１１及び８０２．１６リンクに対してメディア固有管理フレームの拡張はＭＩＨメッセージを搬送するために推奨される。Ｌ２での３ＧＰＰ及び３ＧＰＰ２アクセスを介してＭＩＨメッセージのトランスポートに関するこの企画では前提としていない。

具体的アーチテクチャ
図１３はクライアント装置が通信する無線アクセスポイントを含む幾つかの具体的及び限定されない実施に採用できる具体的アーチテクチャコンポーネントを示す。これに関して、図５は一般的に２１で示される無線ローカルエリアネットワーク（ＷＬＡＮ）に接続される具体的有線ネットワーク２０を示す。ＷＬＡＮ２１はアクセスポイント（ＡＰ）２２及び複数のユーザ局２３，２４を含む。例えば、有線ネットワーク２０はインターネット又は企業データ処理ネットワークを含めることができる。例えば、アクセスポイント２２は有線ネットワーク２１にリンクされたネットワークインターフェース２５及びユーザ局２３，２５と通信する無線トランシーバを有する。例えば、無線トランシーバ２６はユーザ局２３，２５と無線又はマイクロ波周波数通信のためのアンテナ２７を含むことができる。アクセスポイント２２はプロセッサ２８、プログラムメモリ２９及びランダムアクセスメモリ３１も有する。ユーザ局２３はアクセスポイント局２２と通信するためのアンテナ３６を含む無線トランシーバ３５を有する。同様に、ユーザ局２４は無線トランシーバ３８とアクセスポイント２２に対して通信するためのアンテナ３９を有する。一例として、幾つかの実施形態では、オーセンティケータはそのようなアクセスポイント（ＡＰ）及び／又はサプリカント（ｓｕｐｐｌｉｃａｎｔ）内で採用でき、ピアはモバイルノード又はユーザ局内で採用し得る。

図１４は、幾つかの実施形態において、例えば、アクセスポイント、オーセンティケータ、ユーザ局、モバイルノード又は他のノードのような装置によって実行される、コンピュータ化処理ステップを実施するために使用し得る具体的コンピュータ又は制御ユニットを示す。幾つかの実施形態では、コンピュータまた葉制御ユニットはバス３２６を介して一組の入出力（Ｉ／Ｏ）装置３２４と通信できる中央処理装置（ＣＰＵ）３２２を含む。Ｉ／Ｏ装置３２４は、例えば、キーボード、モニタ、及び／又は他の装置を含むことができる。ＣＰＵ３２２はバス３２６を介してコンピュータ読み取り可能媒体（例えば、一般的な揮発性又は不揮発性データ記憶装置）３２８（以後、「メモリ３２８」）と通信できる。ＣＰＵ３２２、Ｉ／Ｏ装置３２４、バス３２６及びメモリ３２８の相互関係は従来知られているものと同様にできる。メモリ３２８は例えば、データ３３０を含むことができる。メモリ３２８はソフトウェア３３８も記憶できる。ソフトウェア３３８はプロセスのステップを実行するための複数のモジュール３４０を含むことができる。一般的プログラミング技術がこれらのモジュールを実施するために使用できる。メモリ３２８は上記及び／又は他のデータファイルも記憶できる。幾つかの実施形態では、ここに記載されている種々の方法はコンピュータシステムを用いてコンピュータプログラム製品を介して実施し得る。この実施は、コンピュータ読み取り可能媒体（例えば、ディスケット、ＣＤ−ＲＯＭ， ＲＯＭ又は同種のもの）に固定され、モデム又は同様なもののようなインターフェース装置を介してコンピュータシステムに送信できる一連のコンピュータインストラクションを含むことができる。通信媒体は実質的に有形（例えば、通信ライン）及び／又は実質的に無形（例えば、マイクロ波、光、赤外線などを用いた無線媒体）であってもよい。コンピュータインストラクションは種々のプログラム言語で書くことができ及び／又は半導体装置（例えば、チップ又は回路）、磁気装置、光学装置及び／又は他の記憶装置のような記憶装置に記憶できる。種々の実施形態では、送信は任意の適当な通信技術を使用できる。

本発明は、上記及び／又は他の背景技術及び／又は問題を改善する。

本発明の好適実施形態はメディア独立ハンドオーバ信号伝達（例えば、イベントサービス、コマンドサービス及び情報サービス信号伝達）及び単一プロトコル（即ち、８０２．２１ＭＩＨプロトコル）でのネットワークアクセス認証信号伝達を統合する。特に、好適実施形態は単一リンクレイヤ技術内に限らないが、異種網間ハンドオーバに関してそのような統合を可能にする。

更に、本発明の好適実施形態はペアワイズマスタキー（ＰＭＫ）を２つのキー（即ち、メディア独立ＰＭＫ（ＭＩ−ＰＭＫ）及びメディア固有ＰＭＫ（ＭＳ−ＰＭＫ））に分ける。従って、好適実施形態では、１）１つは複数のアクセス技術をサポートするために単一認証を採用でき、２）１つは事前認証のためのオーセンティケータと通常認証のためのオーセンティケータとを分けるために更に柔軟性を追加できる。

更に、本発明の好適実施形態は間接及び直接事前認証の両方をサポートできる。これに対して、既存の事前認証解決（例えば、８０２．１１ｉ事前認証及びＰＡＮＡ事前認証）は直接事前認証をサポートするだけである。

好適実施形態の幾つかに従うと、次の新規な特徴、即ち、直接及び／又は間接事前認証の両方のサポート、及び／又はネットワーク主導型及びモバイル主導型事前認証が採用される。

幾つかの実施形態によると、サービングオーセンティケータからターゲットオーセンティケータまでのハンドオーバ中にモバイルノードのメディア独立ハンドオーバ（ＭＩＨ）事前認証のための方法は、単一プログラムでメディア独立ハンドオーバ信号伝達及びネットワークアクセスオーセンティケータ信号伝達を統合することを含む。幾つかの実施形態では、単一プロトコルは８０２．２１ ＭＩＨプロトコルを含む。幾つかの実施形態では、本方法はネットワーク主導型直接事前認証を実行することを含む。幾つかの実施形態では、本方法はモバイル主導型間接事前認証を実行することを含む。幾つかの実施形態では、本方法は異種網間ハンドオーバのためのメディア独立ハンドオーバ（ＭＩＨ）事前認証を実行することを含む。幾つかの実施形態では、本方法はオーセンティケータにＥＡＰによって生成されるマスタセッションキー（ＭＳＫ）を保持させること、メディア独立ペアワイズマスタキー（ＭＩ−ＰＭＫ）を取得するためにＭＳＫを使用すること、モバイルノードが事前認証したターゲットオーセンティケータにハンドオーバしたとき、メディア独立ＰＭＫ（ＭＩ−ＰＭＫ）から得られたメディア固有ＰＭＫ（ＭＳ−ＰＭＫ）を用いてメディア固有安全関連プロトコルを実行することを含む。幾つかの実施形態では、本方法は複数のアクセス技術をサポートするために単一オーセンティケータを採用することを含む。

幾つかの実施形態によると、サービングオーセンティケータからターゲットオーセンティケータまでのハンドオーバ中にモバイルノードのメディア独立ハンドオーバ（ＭＩＨ）事前認証のためのシステムが提供される。このシステムはａ）モバイルノードのネットワークアクセス認証及び単一プロトコルを用いてモバイルノードのメディア独立ハンドオーバを行い、複数のアクセス技術をサポートするような構成を含み、（ｂ）オーセンティケータはメディア固有認証又はメディア独立ハンドオーバ事前認証中に生成されるマスタセッションキーを保持するように構成される。そのマスタセッションキーがメディア独立ペアワイズマスタキー及びメディア固有安全関連を実行するためのメディア固有ペアワイズマスタキーを得るために使用される。幾つかの実施形態では、単一プロトコルは８０２．２１ ＭＩＨプロトコルを含む。

上記及び／又は他の発明者、態様、特徴及び／又は各種実施形態の利点が添付図を参照して次の説明を考慮して更に理解されるであろう。各種実施形態は適用可能な場合、異なる態様、特徴及び／又は利点を含む及び／又は除外できる。更に、各種実施形態は適用可能な場合、他の実施形態の１以上の態様又は特徴を組み合わせることができる。特定の実施形態の態様、特徴及び／又は利点の説明は他の実施形態又は請求項を限定するように解釈されるべきでない。

幾つかの具体的背景実施形態に従った具体的ネットワーク構造を示すアーチテクチャ図である。 具体的背景実施環境に従ったメディア独立事前認証（ＭＰＡ）通信フロー図を示すフロー図である。 具体的ＥＡＰ事前認証シナリオを示すアーチテクチャ図である。 直接事前認証に関する具体的ＥＡＰ事前認証信号フローを示すアーチテクチャ図である。 間接事前認証に関する具体的ＥＡＰ事前認証信号フローを示すアーチテクチャ図である。 間接事前認証におけるサービングオーセンティケータの役目を示す図である。 メディア独立ハンドオーバ（ＭＩＨ）に関するネットワーク基準モデルを示す。 ＭＩＨＦ通信モデルを示す。 アーチテクチャ特徴、メッセージ呼出フロー、及び本発明の好適実施形態の幾らかに従った特徴に関する同様なものを示す。 アーチテクチャ特徴、メッセージ呼出フロー、及び本発明の好適実施形態の幾らかに従った特徴に関する同様なものを示す。 アーチテクチャ特徴、メッセージ呼出フロー、及び本発明の好適実施形態の幾らかに従った特徴に関する同様なものを示す。 アーチテクチャ特徴、メッセージ呼出フロー、及び本発明の好適実施形態の幾らかに従った特徴に関する同様なものを示す。 アーチテクチャ特徴、メッセージ呼出フロー、及び本発明の好適実施形態の幾らかに従った特徴に関する同様なものを示す。 アーチテクチャ特徴、メッセージ呼出フロー、及び本発明の好適実施形態の幾らかに従った特徴に関する同様なものを示す。 幾つかの実例に従ったシステムアーチテクチャの具体的コンポーネントを示す具体的アーチテクチャ図である。 幾つかの実施形態における、例えば、アクセスポイント、ユーザ局、ソースノード又はあて先ノードのような装置によって遂行されるコンピュータ化された処理ステップを実施するために使用される具体的コンピュータ又は制御ユニットに従った特徴を示す。

本発明の好適実施形態は添付図に、限定されないが、一例として示されている。

本発明は多くの異なる形態で実施できるが、本開示は本発明の原理の例を提供していると考えられ、そのような例はここに説明され及び／又はここに図説されている好適実施形態に本発明を限定する意図がないことを考慮してここに複数の具体的実施形態が説明されている。

本発明の好適実施形態は単一のプロトコル（即ち、８０２．２１ ＭＩＨプロトコル）でメディア独立ハンドオーバ信号伝達（例えば、イベントサービス、コマンドサービス及び情報サービス信号伝達）及びネットワークアクセス認証信号伝達を統合する。特に、好適実施形態は単一のリンク層技術内ばかりでなく異種網間ハンドオーバに関してそのような統合を可能にする。

本発明の好適実施形態では、ペアワイズマスタキー（ＰＭＫ）は２つのキー（即ち、メディア独立ＰＭＫ（ＭＩ−ＰＭＫ）及びメディア固有ＰＭＫ（ＭＳ−ＰＭＫ））に分ける。従って、好適実施形態では、１）複数のアクセス技術に寄与する単一のオーセンティケータを採用でき、２）事前認証のためのオーセンティケータと通常認証のためのオーセンティケータとを分けるためにより柔軟性を追加できる。

更に、本発明の実施形態は間接及び直接認証の両方をサポートできる。これに対して、既存の事前認証解決法（例えば、８０２．１１ｉ事前認証及びＰＡＮＡ事前認証）は直接事前認証をサポートするだけである。

好適実施形態の幾つかによると、直接及び間接事前認証の両方をサポートし、ネットワーク主導型及びモバイル主導型事前認証の両方をサポートするシステム及び方法が提供される。

幾つかの好適実施形態によると、次の態様が採用される。

・オーセンティケータはポイントオブサービス（ＰｏＳ）である。

・ＭＮ のＭＩＨＦ−ＩＤはＭＮのメディア独立識別として使用される。

・オーセンティケータのＭＩＨＦ−ＩＤはオーセンティケータのメディア独立識別として使用される。

・オーセンティケータはメディア固有認証又はＭＩＨ事前認証中にＥＡＰによって生成されるＭＳＫ（マスタセッションキー）を保持する。

・ＭＳＫはメディア独立ペアワイズマスタキー（ＭＩ−ＰＭＫ）を得るために使用される。

・ＭＮが事前認証されているターゲットオーセンティケータにハンドオーバすると、それはＭＩ−ＰＭＫから得られるメディア固有ＰＭＫ（ＭＳ−ＰＭＫ）を用いてメディア固有メディア固有セキュアアソシエーションプロトコルを実行する。

・ＭＩＨ送達確認(Acknowledge)機構はＭＩＨトランスポートがＥＡＰメッセージの配送に信頼性がなければ使用されることになる。

・ＭＩＨ事前認証コマンドのために、セッションＩｄが通信ＭＩＨピア間で異なる事前認証セッションを識別するために使用される。

−ここでは、セッションＩＤはオーセンティケータによって割り当てられる整数であり、オーセンティケータ内で独特である。

・ＭＮ又はサービングオーセンティケータ（ＳＡ）は候補オーセンティケータ（ＣＡ）のＩＰアドレスを知る必要がある。

・モバイル主導型事前認証のために、サービングオーセンティケータは“pre-auth initiate”イベントのためのＭＮに同意する。

ネットワーク主導型直接事前認証
幾つかの実施形態では、図９に示されるような特徴を含むネットワーク主導型直接事前認証が採用できる。

これに関して、図示するように、ネットワーク主導型直接事前認証が次の機能エンティティ、即ち、モバイルノード（ＭＮ）又はピア、サービングオーセンティケータ、及び候補オーセンティケータ（ＣＡ）を含むことができる。図示のように、ネットワーク主導型直接事前認証状況においては、サービングオーセンティケータは候補オーセンティケータに送信されるMIH Pre-auth開始指示（ＭＮ−ＭＩＨＦ−ＩＤ）によって開始できる。それに応じて、候補オーセンティケータはMIH Pre-authリクエスト（ＥＡＰ）をモバイルノード（ＭＮ）に送信できる。それに応じて、モバイルノードはMIH Pre-authレスポンス（ＥＡＰ）を候補オーセンティケータに送信できる。これに応じて、候補オーセンティケータはMIH Pre-authリクエスト（Result, EAP, Lifetime, IC）をモバイルノードに送信できる。これに応じて、モバイルノードはMIH Pre-authレスポンス（ＩＣ）を候補オーセンティケータに送信できる。図９に示される呼出フローに関して、送信元識別子、送信先及びＳＩＤが図に示されていなく、ＳＩＤは候補オーセンティケータによって割り当てられる。

特に、上記メッセージ交換の実行において、次のステップは（例えば、メッセージの特定ノード及びメッセージの送信に関するプリミティブの発行を鑑みて）実行される。

ステップＡ１．サービングオーセンティケータ上のＭＩＨユーザがサービングオーセンティケータ上のＭＩＨ関数（ＭＩＨＦ）にMIH_Pre-authentication_initiation.Requestプリミティブを発行し、これにより同ＭＩＨＦは候補オーセンティケータに対してMIH_Pre-authentication_Initiation indicationメッセージを送信する。

ステップＡ２．候補オーセンティケータ上のＭＩＨＦがMIH_Pre-authentication_Initiationindicationメッセージを受けると、候補オーセンティケータ上のＭＩＨユーザに対しMIH_Pre-authentication_initiationプリミティブを戻す。

ステップＡ３．候補オーセンティケータ上のＭＩＨユーザは、候補オーセンティケータ上のＭＩＨＦに対し、MIH_Pre-authentication.Requestプリミティブを発行し、これにより、同ＭＩＨＦはピアに対してMIH_Pre-authenticationリクエストメッセージを送信する。

ステップＡ４．ピア上のＭＩＨＦがMIH_Pre-authenticationリクエストメッセージを受信すると、ピア上のＭＩＨユーザに対してMIH_Pre-authentication.Indicationプリミティブを戻す。

ステップ５．ピア上のＭＩＨユーザは、ピア上のＭＩＨＦに対し、MIH_Pre-authentication.Responseプリミティブを発行し、これにより同ＭＩＨＦは候補オーセンティケータに対してMIH_Pre-authenticationレスポンスメッセージを送信する。

ステップ６．候補オーセンティケータ上のＭＩＨＦがMIH_Pre-authenticationレスポンスメッセージを受信すると、候補オーセンティケータに関するＭＩＨユーザに対してMIH_Pre-authentication.Confirmプリミティブを戻す。

その後、ステップＡ３乃至Ａ６がＥＡＰ認証の完了まで繰り返す。

モバイル処理直接事前認証
幾つかの実施形態では、図１０に示すような特徴を含むモバイル処理直接事前認証が採用し得る。

これに関して、図示するように、モバイル主導型直接事前認証は同様に次の機能エンティティ、即ち、モバイルノード（ＭＮ），サービングオーセンティケータ（ＳＡ），及び候補オーセンティケータ（ＣＡ）を含むことができる。図示するように、モバイル主導型直接事前認証状況では、モバイルノードはサービングオーセンティケータに送信されたMIH Pre-auth開始指示メッセージ（ＣＡ−ＭＩＨＦ−ＩＤ）で開始する。次に、サービングオーセンティケータはMIH Pre-auth開始指示メッセージ（ＣＡ−ＭＩＨＦ−ＩＤ）を候補オーセンティケータに送信する。その後、図８に示されるように、手順はネットワーク主導型直接事前認証に関する図７に示される（即ち、ＭＮ−ＭＩＨＦ−ＩＤの送信に続く）手順と同じ方法で続けられる。図１０に示される呼出フローに関して、送信元識別子、送信先識別子及びＳＩＤは図に示されていないことに留意する。

特に、上記メッセージ効果の実行において、次のステップが（例えば、特定のノードに関するプリミティブの発行及びメッセージの送信に関して）行われる。

ステップＢ１．ピアに関するＭＩＨユーザはMIH_Pre-authentication_Initiationを発行する。ＭＩＨＦにメッセージをサービングオーセンティケータに送らせる、ピアに関するＭＩＨＦに対するプリミティブリクエスト。

ステップＢ２．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Initiation指示メッセージを受けると、それはMIH_Pre-authentication_Initiationを戻す。サービングオーセンティケータに関するＭＩＨユーザに対してプリミティブである指示。

ステップＢ３．サービングオーセンティケータに関するＭＩＨユーザは、ＭＩＨＦにMIH_Pre-authentication_Initiation指示メッセージを候補オーセンティケータに送らせる、サービングオーセンティケータに関するＭＩＨＦに対してプリミティブであるMIH_Pre-authentication_Initiation指示を発行する。

その後、ステップＡ２及び図９の後続のステップが取られることになる。

ネットワーク主導型間接事前認証
幾つかの実施形態では、図１１に示されるような特徴を含むネットワーク主導型間接事前認証が採用し得る。

これに関して、図示するように、ネットワーク主導型事前認証は次の機能エンティティ、即ち、モバイルノード（ＭＮ），サービングオーセンティケータ（ＳＡ）、及び候補オーセンティケータ（ＣＡ）を含めることができる。図示のように、ネットワーク主導型間接事前認証状態では、候補オーセンティケータはMIH Pre-authリクエスト（MN-MIF-ID, EAP）をサービングオーセンティケータに送信できる。このとき、サービングオーセンティケータはMIH Pre-authリクエスト（ＣＡ−ＭＩＨＦ−ＩＤ， ＥＡＰ）をモバイルノード（ＭＮ）に送信できる。このとき、モバイルノードはMIH Pre-authレスポンス（CA-MIHF-ID, EAP）をサービングオーセンティケータに送信できる。このとき、サービングオーセンティケータはMIH Pre-authレスポンス（ＭＮ−ＭＩＨＦ−ＩＤ， ＥＡＰ）を候補オーセンティケータに送信できる。このとき、候補オーセンティケータはMIH Pre-authリクエスト（Result, EAP, Lifetime, IC）をサービングオーセンティケータに送信できる。このとき、サービングオーセンティケータはMIH Pre-authリクエスト（Result, EAP, Lifetime, IC）をモバイルノードに送信できる。このとき、モバイルノードはMIH Pre-authレスポンス（ＩＣ）をサービングオーセンティケータに送信できる。そして、サービングオーセンティケータはMIH Pre-authレスポンス（ＩＣ）を候補オーセンティケータに送信できる。図１１に示される呼出フローに関して、送信元識別子、送信先識別子及びＳＩＤは図に示されていないことに留意する。ＳＩＤはモバイルノードとサービングオーセンティケータとの間のメッセージのためのサービングオーセンティケータによって及びサービングオーセンティケータと候補オーセンティケータとの間のメッセージに対する候補オーセンティケータによって割り当てられる。

特に、上記メッセージ交換の実行においては、次のステップは（例えば、特定のノードに関するプリミティブの発行及びメッセージの送信について）実行される。

ステップＣ１．候補オーセンティケータに関するＭＩＨユーザはMIH_Pre-authenticationを発行する。ＭＩＨＦにMIH_Pre-authenticationリクエストメッセージをサービングオーセンティケータに送らせる、候補オーセンティケータに関するＭＩＨＦに対してプリミティブであるリクエスト。

ステップＣ２．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authenticationリクエストメッセージを受けると、それはMIH_Pre-authenticationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな指示。

ステップＣ３．サービングオーセンティケータに関するＭＩＨユーザはMIH_Pre-authenticationを発行する。ＭＩＨＦにMIH_Pre-authenticationリクエストメッセージをピアに送らせる、サービングオーセンティケータに関するＭＩＨＦにプリミティブなリクエスト。

ステップＣ４．ピアに関するＭＩＨＦがMIH_Pre-authenticationリクエストメッセージを受けると、それはMIH_Pre-authenticationを戻す。ピアに関するＭＩＨユーザにプリミティブな指示。

ステップＣ５．ピアに関するＭＩＨユーザはMIH_Pre-authenticationを発行する。ＭＩＨＦにMIH_Pre-authenticationレスポンスメッセージをサービングオーセンティケータに送らせる、ピアに関するＭＩＨＦにプリミティブなレスポンス。

ステップＣ６．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authenticationレスポンスメッセージを受けると、それはMIH_Pre-authenticationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな確認。

ステップＣ７．サービングオーセンティケータに関するＭＩＨユーザはMIH_Pre-authenticationを発行する。ＭＩＨＦにMIH_Pre-authenticationレスポンスメッセージを候補オーセンティケータに送る、サービングオーセンティケータに関するＭＩＨＦにプリミティブなレスポンス。

ステップＣ８．候補オーセンティケータに関するＭＩＨＦがMIH_Pre-authenticationレスポンスメッセージを受けると、それはMIH_Pre-authenticationを戻す。候補オーセンティケータに関するＭＩＨユーザにプリミティブな確認。

その後、ステップＣ１乃至Ｃ８はＭＡＰ認証の完了まで繰り返される。

モバイル主導型間接事前認証
幾つかの実施形態では、図１２に示すような特徴を含むモバイル主導型間接認証が採用し得る。

これに関して、図示するように、モバイル主導型間接事前認証は次の機能エンティティ、即ち、モバイルノード（ＭＮ）又はピア、サービングオーセンティケータ（ＳＡ）、及び候補オーセンティケータ（ＣＡ）を含めることができる。図示するように、モバイル主導型間接認証では、モバイルノードはMIH Pre-auth開始指示（ＣＡ−ＭＩＨＦ−ＩＤ）を候補オーセンティケータに送信できる。このとき、サービングオーセンティケータはMIH Pre-auth開始指示 （ＭＮ−ＭＩＨＦ−ＩＤ）を候補オーセンティケータに送信できる。その後、図１２に示すように、手順はネットワーク主導型間接事前認証に関する（即ち、モバイルノードとサービングオーセンティケータとの間及びサービングオーセンティケータと候補オーセンティケータとの間の通信に関して）図１１に示される手順と同じ方法で継続される。図１２に示される呼出フローに関して、送信元識別子、送信先識別子及びＳＩＤが図に示されていないことに留意する。

特に、上記メッセージ交換の実行において、次のステップが（例えば、特定ノードに関するプリミティブの発行及び目セージの送信に関して）実行される。

ステップＤ１．ピアに関するＭＩＨユーザはMIH_Pre-authentication_initiationを発行する。ＭＩＨＦにMIH_Pre-authentication_Initiation指示メッセージをサービングオーセンティケータに送らせる、ピアに関するＭＩＨＦにプリミティブなリクエスト。

ステップＤ２．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Initiation指示メッセージを受けると、それはMIH_Pre-authentication_Initiationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな指示。

ステップＤ３．サービングオーセンティケータに関するＭＩＨユーザはMIHFにMIH_Pre-authentication_Initiation指示メッセージを候補オーセンティケータに送らせる、サービングオーセンティケータに関するＭＩＨＦにプリミティブなMIH_Pre-authentication_Initiation指示を発行する。

ステップＤ４．候補オーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Initiation指示メッセージを受けると、それはMIH_Pre-authentication_Initiationを戻す。候補オーセンティケータに関するＭＩＨユーザにプリミティブな指示。

その後、図１１におけるステップＣ１及び後続のステップが行われる。

直接事前認証終了
幾つかの実施形態では、図１３に示されるような特徴を含む直接事前認証終了が採用し得る。これに関して、図１３はネットワーク主導型方法及びモバイル主導型方法の両方を示す。

図示するように、ネットワーク主導型方法に関して、候補オーセンティケータはMIH Pre-auth終了リクエスト（ＩＣ）をモバイルノードに送信できる。そして、モバイルノードはMIH Pre-auth終了レスポンス（ＩＣ）を候補オーセンティケータに送信できる。

図１３に示される呼出フローに関して、送信元識別子、送信先識別子及びＳＩＤが図に示されていないことに留意する。

特に、上記メッセージ交換の実行においては、次のステップが（例えば、特定ノードに関するプリミティブの発行及びメッセージの送信に関して）実行される。

１．ネットワーク主導型Direct-Preauth終了
ステップＥ１．候補オーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationリクエストメッセージをピアに送らせる、候補オーセンティケータに関するＭＩＨＦにプリミティブであるリクエスト。

ステップＥ２．ピアに関するＭＩＨＦがMIH_Pre-authentication_Terminationリクエストメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。ピアに関するＭＩＨユーザにプリミティブな指示。

ステップＥ３．ピアに関するＭＩＨユーザはMIH_Pre-authenticationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationを候補オーセンティケータに送らせる、ピアに関するＭＩＨＦにプリミティブなレスポンス。

ステップＣ４．候補オーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationレスポンスメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。候補オーセンティケータに関するＭＩＨユーザにプリミティブである確認。

モバイル主導型Direct-Preauth終了
これに関して、ネットワーク主導型Direct-Preauth終了に対する各ステップにおける候補オーセンティケータ及びピア機能は次のようにモバイル主導型Direct-Preauth終了において交換される。

ステップＥ１．ピアに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationリクエストメッセージを候補オーセンティケータに送らせる、ピアに関するＭＩＨＦにプリミティブなリクエスト。

ステップＥ２．候補オーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationリクエストメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。候補オーセンティケータに関するＭＩＨユーザにプリミティブな指示。

ステップＥ３．候補オーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationをピアに送らせる、候補オーセンティケータに関するＭＩＨＦにプリミティブなレスポンス。

ステップＥ４．ピアに関するＭＩＨＦがMIH_Pre-authentication_Terminationレスポンスメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。ピアに関するＭＩＨユーザにプリミティブな確認。

間接事前認証終了
幾らかの実施形態では、図１４に示されるような特徴を含む間接事前認証終了が採用し得る。これに関して図１４はネットワーク主導型方法及びモバイル主導型方法の両方を示している
ネットワーク主導型方法に関して、図示するように、候補オーセンティケータはMIH Pre-auth終了リクエスト（ＩＣ）をサービングオーセンティケータに送信でき、サービングオーセンティケータはMIH Pre-auth送信リクエスト（ＩＣ）モバイルノードに送信する。このとき、モバイルはMIH Pre-auth終了レスポンス（ＩＣ）をサービングオーセンティケータに送信でき、サービングオーセンティケータはMIH Pre-auth終了レスポンス（ＩＣ）を候補オーセンティケータに送信できる。

モバイル主導型方法に関して、図示するように、モバイルノードはMIH Pre-auth終了リクエスト（ＩＣ）をサービングオーセンティケータに送信でき、サービングオーセンティケータはMIH Pre-auth終了リクエストを候補オーセンティケータに送信できる。このとき、候補オーセンティケータはMIH Pre-auth終了レスポンス（ＩＣ）をサービングオーセンティケータに送信でき、サービングオーセンティケータはMIH Pre-auth終了レスポンスをモバイルノードに送信できる。

図１４に示される呼出フローに関しては、送信元識別子、送信先識別子及びＳＩＤは図に示されていないことに留意する。

特に、上記メッセージ交換の実行においては、次のステップが（例えば、特定のノードに関するプリミティブの発行及びメッセージの送信に関して）実行される。

１．ネットワーク主導型Indirect-Preauth終了
ステップＦ１．候補オーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationリクエストメッセージをサービングオーセンティケータに送らせる、候補オーセンティケータに関するＭＩＨＦに対してプリミティブであるリクエスト。

ステップＦ２．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationリクエストメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな指示。

ステップＦ３．サービングオーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationリクエストメッセージをピアに送らせる、サービングオーセンティケータに関するＭＩＨＦにプリミティブなリクエスト。

ステップＦ４．ピアに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationレスポンスメッセージをサービングオーセンティケータに送らせる、ピアに関するＭＩＨＦにプリミティブなレスポンス。

ステップＦ５．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationレスポンスメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな確認。

ステップＦ６．サービングオーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationレスポンスメッセージを候補オーセンティケータに送らせる、サービングオーセンティケータに関するＭＩＨＦにプリミティブなレスポンス。

ステップＦ７．候補オーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationレスポンスメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。候補オーセンティケータに関するＭＩＨユーザにプリミティブな確認。

２．モバイル主導型Indirect-Preauth終了
これに関して、ネットワークIndirect-Preauth終了に対して各ステップにおいて候補オーセンティケータ及びピア機能はモバイル主導型Indirect-Preauth終了において交換される。

ステップＦ１．ピアに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationリクエストメッセージをサービングオーセンティケータに送らせる、ピアに関するＭＩＨＦにプリミティブであるリクエスト。

ステップＦ２．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationリクエストメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな指示。

ステップＦ３．サービングオーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationリクエストメッセージを候補オーセンティケータに送らせる、サービングオーセンティケータに関するＭＩＨＦにプリミティブなリクエスト。

ステップＦ４．候補オーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationレスポンスメッセージをサービングオーセンティケータに送らせる、候補オーセンティケータに関するＭＩＨＦにプリミティブなレスポンス。

ステップＦ５．サービングオーセンティケータに関するＭＩＨＦがMIH_Pre-authentication_Terminationレスポンスメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。サービングオーセンティケータに関するＭＩＨユーザにプリミティブな確認。

ステップＦ６．サービングオーセンティケータに関するＭＩＨユーザはMIH_Pre-authentication_Terminationを発行する。ＭＩＨＦにMIH_Pre-authentication_Terminationレスポンスメッセージをピアに送らせる、サービングオーセンティケータに関するＭＩＨＦにプリミティブなレスポンス。

ステップＦ７．ピアに関するＭＩＨＦがMIH_Pre-authentication_Terminationレスポンスメッセージを受けると、それはMIH_Pre-authentication_Terminationを戻す。ピアに関するＭＩＨユーザにプリミティブな確認。

事前認証リモードプリミティブ（Pre-Authentication Remote Primitives）
幾つかの好適実施形態において、上記の図９−１４に示される機能性に対応するプリミティブは次のパラグラフに説明されているような特徴を含めることができる。これに関して、プリミティブは、例えば、メッセージ交換を引き起こす上位層から呼び出されるような同じ通信ノード内でプロトコル層を介して呼び出し得る機能の概念表現を含む。

１．事前認証遠隔イベントプリミティブ
MIH_Pre-authentication_initiation.{Request,Indication}
好適実施形態では、下記パラメータが使用されるそのようなプリミティブが採用し得る。

− 送信元識別子：ＭＮ又はＣＡ のＭＩＨＦ−ＩＤ
− 送信先識別子：ＳＡ又はＣＡ のＭＩＨＦ−ＩＤ
− ＳＩＤ：セッションＩＤ
− ＭＮ−ＭＩＨＦ−ＩＤ：ＭＮ のＭＩＨＦ−ＩＤ（送信元識別子と異なれば）
− ＣＡ−ＭＩＨＦ−ＩＤ：ＣＡ のＭＩＨＦ−ＩＤ（送信先識別子と異なれば）
２．事前認証リモードコマンドプリミティブ
MIH_Pre-Authentication.{Request,Indication}
幾つかの実施形態では、下記パラメータが使用されるそのようなプリミティブが採用し得る。

− 送信元識別子：ＭＮ又はＳＡのＭＩＨＦ−ＩＤ
− 送信先識別子：ＳＡ又はＣＡのＭＩＨＦ−ＩＤ
− ＳＩＤ：セッションＩＤ
− 結果：｛成功，失敗｝：リクエストプリミティブがＣＡによって発行され、ＥＡＰ認証が完了されているときだけ含まれる。

− ＥＡＰ：ＥＡＰメッセージ
− ＭＮ−ＭＩＨＦ−ＩＤ：ＭＮのＭＩＨＦ−ＩＤ（送信元識別子と異なれば又はSession-Idが割当てられる前であれば）
− ＣＡ−ＭＩＨＦ−ＩＤ：ＣＡのＭＩＨＦ−ＩＤ（送信先識別子と異なれば）
− 寿命：事前認証セッションの寿命
− ＩＣ（Integrity Checksum）．
３．事前認証リモートコマンド
MIH_Pre-authentication_{Response,Confirm}
幾つかの実施形態では、これに関して、下記パラメータが採用される。

− 送信元識別子：ＣＡ又はＳＡのＭＩＨＦ−ＩＤ
− 送信先識別子：ＭＮ又はＳＡのＭＩＨＦ−ＩＤ
− ＳＩＤ：セッションＩＤ
− ＥＡＰ： ＥＡＰメッセージ
− ＩＣ （Integrity Checksum）．
４．事前認証遠隔コマンド
MIH_Pre-authentication_Termination_{Request,Indication}
幾つかの実施形態では、これに関して、下記パラメータが採用される。

− 送信元識別子：ＭＮ、ＣＡ又はＳＡのＭＩＨＦ−ＩＤ
− 送信先識別子：ＭＮ、ＣＡ又はＳＡのＭＩＨＦ−ＩＤ
− ＳＩＤ：セッションＩＤ
− ＩＣ（Integrity Checksum）．
本発明の広い範囲
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合及び／又は変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、又は本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能又はステッププラス機能限定は、特定のクレーム限定について、この限定において、ａ）「〜の手段」又は「〜のステップ」が明記されている、ｂ）対応する機能が明記されている、及びｃ）構造、材料又はこの構造をサポートする動作が記載されていないという条件すべてが存在する場合に限り用いられる。本開示において、かつ本出願の出願中において、「本発明」又は「発明」という用語は、本開示内の１つ又は複数の態様を指すものとして使用され得る。本発明又は発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様又は実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様及び実施形態を有すると理解されるべきであり）、また、誤って本出願又は特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセス又はステップ、これらの任意の組合せ、及び／又はこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、「例えば」を意味する「ｅ．ｇ．」という省略用語が用いられ得る。

Claims (21)

1. サービングオーセンティケータからターゲットオーセンティケータへのハンドオーバ中にモバイルノードのメディア独立ハンドオーバ（ＭＩＨ）事前認証のための方法であって、
   単一プロトコルにおいてメディア独立ハンドオーバ信号伝達及びネットワークアクセス認証信号伝達を統合すること、
   メディア独立ＰＭＫ（ＭＩ−ＰＭＫ）及びメディア固有ＰＭＫ（ＭＳ−ＰＭＫ）を取得すること、
   ＥＡＰによって生成されたマスタセッションキー（ＭＳＫ）をオーセンティケータに保持させること、
   前記メディア独立ペアワイズマスタキー（ＭＩ−ＰＭＫ）を取得するために前記ＭＳＫを用いること、
   前記モバイルノードが事前認証された前記ターゲットオーセンティケータにハンドオーバするとき、前記メディア独立ＰＭＫ（ＭＩ−ＰＭＫ）から得られるメディア固有ＰＭＫ（ＭＳ−ＰＭＫ）を用いてメディア固有セキュアアソシエーションプロトコルを実行することを含む、方法。
2. 前記単一プロトコルは８０２．２１ ＭＩＨプロトコルを含む、請求項１の方法。
3. ネットワーク主導型直接事前認証を実行することを更に含む、請求項１の方法。
4. 前記ネットワーク主導型直接事前認証を実行することはサービングオーセンティケータから候補オーセンティケータにMIH Pre-auth開始指示メッセージを送信すること、前記候補オーセンティケータからモバイルノードにＭＩＨＰｒｅ−ａｕｔｈリクエストメッセージを送信すること、前記モバイルノードから前記候補オーセンティケータにＭＩＨPre-authレスポンスメッセージを送信することを含む、請求項３の方法。
5. モバイル主導型直接事前認証を実行することを更に含む、請求項１の方法。
6. 前記モバイル主導型直接事前認証を実行することは、モバイルノードにMIH Pre-auth開始指示メッセージをサービングオーセンティケータに送信させること、サービングオーセンティケータにMIH Pre-auth開始指示メッセージを前記候補オーセンティケータに送信させることを含む、請求項５の方法。
7. ネットワーク主導型間接事前認証を実行することを更に含む、請求項１の方法。
8. 前記ネットワーク主導型直接事前認証を実行することは候補オーセンティケータにMIH Pre-authリクエストメッセージを前記サービングオーセンティケータに送信させること、前記サービングオーセンティケータにＭＩＨPre-authリクエストメッセージをモバイルノードに送信させることを含む、請求項７の方法。
9. モバイル主導型モバイル主導型事前認証を実行することを更に含む、請求項１の方法。
10. 前記モバイル主導型モバイル主導型事前認証を実行することはモバイルノードにMIH Pre-auth開始指示メッセージをサービングオーセンティケータに送信させること、前記サービングオーセンティケータにMIH Pre-auth開始指示メッセージを候補オーセンティケータに送信させることを含む、請求項９の方法。
11. 異種網間ハンドオーバのために前記メディア独立ハンドオーバ（ＭＩＨ）事前認証を実行することを更に含む、請求項１の方法。
12. 複数のアクセス技術を提供するために単一オーセンティケータを採用することを更に含む、請求項１の方法。
13. 事前認証を実行する前にサービングオーセンティケータによって前記モバイルノードのＭＩＨ登録を実行することを更に含む、請求項１の方法。
14. モバイル主導型事前認証を実行すること、サービングオーセンティケータをpre-auth開始イベントに対して前記モバイルノードに同意させることを更に含む、請求項１の方法。
15. サービングオーセンティケータからターゲットオーセンティケータにハンドオーバ中にモバイルノードのメディア独立ハンドオーバ（ＭＩＨ）事前認証のための方法であって、オーセンティケータにＥＡＰによって生成されるマスタセッションキー（ＭＳＫ）を保持させること、メディア独立ペアワイズマスタキー（ＭＩ−ＰＭＫ）を取得するための前記ＭＳＫを使用すること、前記モバイルノードが事前認証したターゲットオーセンティケータにハンドオーバすると、メディア独立ＰＭＫ（ＭＩ−ＰＭＫ）から取得されるメディア固有ＰＭＫ（ＫＳ−ＰＭＫ）を用いてメディア固有セキュアアソシエーションプロトコルを実行することを含む、方法。
16. 単一プロトコルにおいてメディア独立ハンドオーバ信号伝達及びネットワークアクセス認証信号伝達を統合することを更に含む、請求項１５の方法。
17. 前記単一プロトコルが８０２．２１ ＭＩＨプロトコルを含む、請求項１６の方法。
18. 異種網間ハンドオーバのため前記メディア独立ハンドオーバ（ＭＩＨ）事前認証を実行することを更に含む、請求項１５の方法。
19. 複数のアクセス技術を提供するため単一オーセンティケータを採用することを更に含む、請求項１８の方法。
20. サービングオーセンティケータからターゲットオーセンティケータへのハンドオーバ中にモバイルノードのメディア独立ハンドオーバ（ＭＩＨ）事前認証のためのシステムであって、
    ａ）単一プロトコルを用いて前記モバイルノードのネットワークアクセス認証及び前記モバイルノードのメディア独立ハンドオーバを実行し、複数のアクセス技術を提供するように構成されるオーセンティケータを含み、
    ｂ）前記オーセンティケータはメディア固有認証又はメディア独立ハンドオーバ事前認証中に生成されるマスタセッションを保持するように構成され、前記マスタセッションキーはメディア固有セキュアアソシエーションを実行するためにメディア独立ペアワイズマスタキー及びメディア固有ペアワイズマスタキーを取得するために使用される、システム。
21. 前記単一プロトコルは８０２．２１ ＭＩＨプロトコルを含む、請求項２０のシステム。

Images