JP4538009B2 - メディア独立型事前認証のフレームワーク - Google Patents

Description

本発明は、特に、安全高速ハンドオフなどのためのネットワーク発見機構の方法などを含む、ネットワーク発見機構の方法に関する。

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

ＩＰ（インターネットプロトコル）に関して、これは、ネットワーク上である装置（電話機、ＰＤＡ［携帯情報端末］、コンピュータなど）から別の装置にデータを送るためのプロトコルである。今日、ＩＰｖ４、ＩＰｖ６などを含めて、様々なＩＰのバージョンがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも１つのＩＰアドレスを有する。ＩＰはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータ又はメッセージを送信し、又は受信するとき、データ又はメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。

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

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

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

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

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

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

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

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

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

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

好ましい実施形態は、例えば、以下の参照文献などに記載されている技術を改善するものである。以下に列記する各参照文献全体は、参照してここに組み込まれる。

１．Perkins,C.,「IP Mobility Support for IPv4」,RFC 3344,August 2002．以下、［ＲＦＣ３３４４］とする。

２．Johnson,D.,Perkins,C.and J.Arkko,「Mobility Support in IPv6」,RFC 3775,June 2004．以下、［ＲＦＣ３７７５］とする。

３．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］とする。

７．Aboda,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」．以下、［ＲＧ９８］とする。

１１．ITU-T,「The E-Model,a computational model for use in transmission planning」．以下、［ＩＴＵ９８］とする。

１２．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」．以下、［ＥＴＳＩ］とする。

１３．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．以下、［ＲＦＣ２６７９］とする。

１６．Almes,G.,Kalidindi,S.and M.Zekauskas,「A One-Way Packet Loss Metric for IPPM」,RFC 2680,September 1999．以下、［ＲＦＣ２６８０］とする。

１７．Almes,G.,Kalidindi,S.and M.Zekauskas,「A Round-trip Delay Metric for IPPM」,RFC 2681,September 1999．以下、［ＲＦＣ２６８１］とする。

１８．Simpson,W.,「IP in IP Tunneling」,RFC 1853,October 1995．以下、［ＲＦＣ１８５３］とする。

１９．Patrick,M.,「DHCP Relay Agent Information Option」,RFC 3046,January 2001．以下、［ＲＦＣ３０４６］とする。

２０．Schulzrine,H.,「Application Layer Mobility Using SIP」．以下、［ＳＩＰＭＭ］とする。

２１．Yegin,A.,「Supporting Optimized Handover for IP Mobility-Requirements for Underlying Systems」,draft-manyfolks-I2-mobilereq-02 (work in progress),July 2002．以下、［I-D.manyfolks-I2-mobilereq］とする。

２２．Cambell,A.,Gomez,J.,Kim,S.,Valko,A.and C.Wan,「Design,Implementation,and Evaluation of Cellular IP」．以下、［ＣＥＬＬＩＰ］とする。

２３．Ramjee,R.,Porta,T.,Thuel,S.,Varadhan,K.and S.Wang,「HAWAII: A Domain-based Approach for Supporting Mobility in Wide-area Wireless networks」．以下、［ＨＡＷＡＩＩ］とする。

２４．Das,S.,Dutta,A.,Misra,A.and S.Das,「IDMP: An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks」．以下、［ＩＤＭＰ］とする。

２５．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」．以下、［ＹＯＫＯＴＡ］とする。

２７．Shin,S.,「Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs」．以下、［ＭＡＣＤ］とする。

２８．Dutta,A.,「Secured Universal Mobility」．以下、［ＳＵＭ］とする。

２９．Dutta,A.,「Fast handoff Schemes for Application Layer Mobility Management」．以下、［ＳＩＰＦＡＳＴ］とする。

３０．Gwon,Y.,Fu,G.and R.Jain,「Fast Handoffs in Wireless LAN Networks using Mobile initiated Tunneling Handoff Protocol for IPv4 (MITHv4)」,January 2005．以下［ＭＩＴＨ］とする。

３１．Anjum,F.,Das,S.,Dutta,A.,Fajardo,V.,Madhani,S.,Ohba,Y.,Taniuchi,K.,Yaqub,R.and T.Zhang,「A Protocol for MIH function and Information Service」,January 2005．以下、［ＮＥＴＤＩＳＣ］とする。

３２．Dutta,A.,「GPS-IP based fast-handoff for Mobiles」．以下、［ＧＰＳＩＰ］とする。

３３．[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-D.ietf-mobileip-reg-tunnel］などのドメイン間モビリティ管理方式がある。ＩＰｖ４及びＩＰｖ６ネットワークのための高速モバイルＩＰプロトコル［I-D.ietf-mobileip-lowlatency-handoffs-v4］、［I-D.ietf-mipshop-fast-mipv6］は、リンク層トリガによって利用可能にされるモビリティ情報を利用する高速ハンドオーバ技法を提供する。Ｙｏｋｏｔａら［ＹＯＫＯＴＡ］は、アクセスポイントと専用ＭＡＣブリッジの共用による、ＭＩＰｖ４仕様を変更しない高速ハンドオーバを提案している。［ＭＡＣＤ］方式は、キャッシュベースのアルゴリズムを提供することによりＭＡＣ層ハンドオフに起因する遅延を低減する。

モビリティ管理方式のいくつかは、デュアルインターフェースを使って、メークビフォアブレーク（make-before-break）シナリオを提供する［ＳＵＭ］。メークビフォアブレーク状況では、普通、他方のインターフェースが接続されようとしているときに、一方のインターフェースを用いて通信が続行される。ＩＥＥＥ８０２．２１作業グループは、これらのシナリオを詳細に論じている。単一のインターフェースを使って高速ハンドオーバを提供するには、複数のインターフェースを有するクライアントの場合よりも慎重な設計技術が必要である。［ＳＩＰＦＡＳＴ］は、一時的トラフィックが、アプリケーション層転送方式を使って旧いサブネットから新しいサブネットへ転送される、ＳＩＰベースのモビリティ管理のための最適化ハンドオーバ方式を提供する。［ＭＩＴＨ］は、旧い外部エージェントと新しい外部エージェントの間のモバイル主導のトンネリングを使用する、単一インターフェースの場合での高速ハンドオーバ方式を提供する。［ＭＩＴＨ］は、Ｐｒｅ−ＭＩＴとＰｏｓｔ−ＭＩＴなど、２種類のハンドオーバ方式を定義する。本発明のＭＰＡ方式は、一般に、モバイルが、実際に新しいネットワークに移動する前に外部エージェントと通信を行うＭＩＴＨの予測方式に相当するものである。しかしながら、本明細書で説明するＭＰＡ方式案は、ＭＩＰ型のモビリティプロトコルだけに限定されるものではなく、この方式は、ドメイン間の移動にも配慮し、事前対応ハンドオーバに加えて事前認証も行う。よって、この方式案は、全体の遅延を、リンク層ハンドオーバ遅延近くまで低減する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

モバイルは、前のネットワークにある間、対応ノードと通信可能とする必要があるため、バインディング更新及び対応ノードからモバイルノードへのデータの一部又は全部を、事前対応ハンドオーバトンネルを介してモバイルノードに送り返す必要がある。

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

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

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

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

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

（１）候補ターゲットネットワークの認証エージェント及びモバイルノードは、正常な事前認証の結果として確立されるＭＰＡ−ＳＡを使ってＰＭＫ（対状マスタキー）［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）を使用している。

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

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

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

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

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

６．３ 非ＭＰＡシナリオ
比較のために、非ＭＰＡシナリオも実験し、本明細書で説明する。非ＭＰＡシナリオは、このようなどんな事前対応ハンドオーバ機構も提供せず、標準のハンドオーバ手順に従う。

以下は、あり得る類似の状況における非ＭＰＡシナリオの各ステップである。この場合、事前対応ハンドオーバは関与しない。モバイルがネットワーク１にある間の初期通信セットアップの一部として関与するステップは、ＭＰＡの部分と同じままである。信号対雑音比などの何らかのポリシ決定に基づいて、モバイルは、新しいネットワークに切り換わることを決定する。

第１のステップで、ＭＮは、ＡＰ２と連携し、ＤＨＣＰサーバ２から新しいＩＰアドレスを獲得し、次いで、このＩＰアドレスをネットワークインターフェースに割り当てる。

第２のステップで、ＭＮはＰＡＡに認証を行う。モバイルがＰＡＡに対して正常に認証を行うまで、データはルータＲ２を通って流れることができない。これは、事後認証の遅延を付加する。

第３のステップで、ＭＮは、新しいネットワークにおいてＤＨＣＰサーバから獲得した新しいＩＰアドレスを用いてＳＩＰ Ｒｅ−ＩＮＶＩＴＥを送り、次いで、音声トラフィックが新しいＩＰアドレスに向けられる。このバインディング更新は、モバイルのターゲットネットワーク及び対応ノードが遠く離れている場合、ともすれば、多大な時間を取ることがある。

６．４ 評価及び結果
ＭＰＡシナリオの場合、事前認証時のパケット喪失はなく、モバイルが新しいネットワークに移動するときに、リンク層ハンドオーバの前の安全な事前対応ハンドオーバが行われる。リンク層ハンドオーバ遅延及びハンドオーバ時のトンネル削除機構による遅延及び関連するパケット喪失が観測される。このハンドオーバ遅延は、リンク層遅延を含めて２８０ミリ秒に制限される。これは、結局、これらのプロセスのために合計１４パケットが失われることになる。［ＭＡＣＤ］などの方式を使ってリンク層遅延を最適化すれば、合計パケット喪失が、約４パケットまで低減される。［ＭＡＣＤ］に記載されている方式がＨＯＳＴＡＰドライバのみを用いて実験されていることに留意することは重要である。

非ＭＰＡシナリオの場合、移動中のＬ２ハンドオーバ、ＩＰアドレス割り当て、事後認証、及びモビリティバインディング更新のために、ハンドオーバ遅延及び結果としてのパケット喪失が発生する。特に、ＤＨＣＰは、ネットワークにおけるＩＰアドレス重複の検出を完了するのに長時間を要し、バインディング更新は、対応ノードがモバイルノードから遠すぎる場合には、長時間掛ることがある。発明者らの試験台において、非ＭＰＡベースのハンドオーバは、上記の要因すべてのために、最大４秒の遅延を要した。ＲＡＴを使って２０ミリ秒ごとに１回送られたストリーミングトラフィックの種類に基づくと、約２００パケットが失われた。

６．５ 注釈
このネットワーク例では、事前認証プロセスなど一部の機能が省略されているが、これをこのネットワークに対して実施することもでき、ハンドオーバにとって決定的に重要な部分ではない。

このネットワーク例では、候補プロトコルは、常に、他のプロトコルで置き換えることができ、例えば、モビリティ管理プロトコルは、モバイルＩＰｖ４又はモバイルＩＰｖ６で置き換えることができる。このような場合、ホームエージェントをネットワーク３に配置することができ、同様に、トンネル管理プロトコルを、ＩＫＥｖ２及びＩＰｓｅｃトンネルモードで置き換えることもできる。性能値は、使用される候補プロトコルの種類によって異なる可能性がある。Ｌ２遅延は、使用されるドライバ及びオペレーティングシステムによって変わることがあることが分った。

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

いくつかの例示的実施形態による基本的な通信の流れを示す、図２へと続く流れ図である。 図１に示す流れ図の続きを示す図である。 いくつかの例示的実施形態によるリンク層セキュリティのブートストラッピングを示す図である。 いくつかの例示的実施形態による例示的ネットワーク構造を示すアーキテクチャ図である。 例示的実装環境によるメディア独立型事前認証（ＭＰＡ）通信の流れ図を示す流れ図である。 例示的実装環境による非ＭＰＡ通信の流れ図を示すフローチャートである。

Claims (24)

1. 任意のリンク層より上位で、任意のモビリティ管理プロトコルによって動作するように構成されるモビリティ最適化方式を用いてメディア独立型事前認証（ＭＰＡ）を実行する方法であって、
   ａ）第１のメディアのネットワークへの接続を有するモバイルノードを設け、
   ｂ）前記第１のメディアのネットワークを介して、上位層で事前認証を実行し、前記モバイルノードが移動できる別のメディア候補ターゲットネットワークの上位層及び下位層のコンテキストを先回りして確立し、
   c)前記モバイルノードは、前記候補ターゲットネットワークからＩＰアドレス及び他の構成パラメータを取得し、前記モバイルノードが前記候補ターゲットネットワークに接続する前に、獲得ＩＰアドレス及び獲得構成パラメータを使ってＩＰパッケージを送受信することを含む、方法。
2. 前記第１のメディアはセルラであり、前記別のメディアは無線ＬＡＮである、又は前記第１のメディアは無線ＬＡＮであり、前記別のメディアはセルラである、請求項１に記載の方法。
3. 前記第１のメディアのネットワークに接続されているが、前記候補ターゲットネットワークにまだ接続されていない前記モバイルノードに、（ｉ）後続のプロトコル実行を確保するために、前記候補ターゲットネットワークとのセキュリティアソシエーションを確立させ、次いで、（ｉｉ）前記候補ターゲットネットワークからＩＰアドレス及び他の構成パラメータを獲得するための構成プロトコル、ならびに前記モバイルノードと前記候補ターゲットネットワークのアクセスルータとの間に双方向トンネルを確立するためのトンネル管理プロトコルをセキュアに実行させ、次いで、（ｉｉｉ）前記獲得ＩＰアドレスをトンネル内アドレスとして使用し、前記トンネルを介して、モビリティ管理プロトコルのバインディング更新のためのシグナリングメッセージ及びバインディング更新の完了後に送信されるデータパケットを含むＩＰパケットを送受信させることをさらに含む、請求項１に記載の方法。
4. 前記候補ターゲットネットワーク内において、それぞれが単一のネットワーク装置又は別個のネットワーク装置に位置する、認証エージェント、構成エージェント、及びアクセス装置という機能要素を設けることをさらに含む、請求項１に記載の方法。
5. メディア独立型事前認証（ＭＰＡ）を実行する方法であって、
   ａ）モバイルノードが、発見プロセスを介して候補ターゲットネットワークを探し出し、ＩＰアドレス及び認証エージェント、構成エージェント及び前記候補ターゲットネットワークのアクセス装置を獲得する事前認証段階を、前記モバイルノードが前記認証エージェントで事前認証を実行している状態で実行すること、
   ｂ）アクセス装置が事前対応ハンドオーバトンネルを確立するためトンネル管理プロトコルを使用している状態で前記候補ターゲットネットワークからＩＰアドレス又は新気付アドレス及び他の構成パラメータを獲得するため事前構成段階を実行すること、
   ｃ）前記候補ターゲットネットワークへのハンドオーバの前に、前記モバイルノードのためのアドレス解決手順を実行すること、
   d）前記モバイルノードが前記候補ターゲットネットワークに接続する前に、獲得ＩＰアドレス及び獲得構成パラメータを使ってＩＰパッケージを送受信すること、
   を有する、方法。
6. 前記アドレス解決手順は、前記候補ターゲットネットワーク中の装置によって実行される、請求項５に記載の方法。
7. 前記アドレス解決手順は、前記候補ターゲットネットワーク中のアクセスルータによって実行される、請求項６に記載の方法。
8. 前記アドレス解決手順は、重複アドレス検出を実行することを含む、請求項５に記載の方法。
9. 前記重複アドレス検出は、前記モバイルノードにＩＰアドレスを割り当てる前に、アドレス解決プロトコル又はＩＰｖ６隣接局発見に基づいて実行される、請求項８に記載の方法。
10. 前記アドレス解決手順は事前対応アドレス解決を実行することを含む、請求項５に記載の方法。
11. 前記事前対応アドレス解決は、前記事前構成プロセスの間に、前記モバイルノードが、前記候補ターゲットネットワーク中のアクセス装置、認証エージェント、及び構成エージェントと通信を行うのに必要とされるアドレス解決マッピングを先回りして確立することを含む、請求項１０に記載の方法。
12. 前記モバイルノードと通信を行う前記候補ターゲットネットワーク中の各ノードが、前記モバイルノードが前記候補ターゲットネットワークに接続した後で、前記モバイルノードの解決マッピングを更新する、請求項１１に記載の方法。
13. 前記モバイルノードの接続検出とアドレス解決マッピング更新の統合を実行することをさらに含む、請求項１２に記載の方法。
14. メディア独立型事前認証（ＭＰＡ）を実行する方法であって、
    ａ）モバイルノードが、発見プロセスを介して候補ターゲットネットワークを探し出し、ＩＰアドレス及び認証エージェント、構成エージェント及び前記候補ターゲットネットワークのアクセス装置を獲得する事前認証段階を、前記モバイルノードが前記認証エージェントで事前認証を実行している状態で実行すること、
    ｂ）アクセス装置が事前対応ハンドオーバトンネルを確立するためトンネル管理プロトコルを使用している状態で前記候補ターゲットネットワークからＩＰアドレス又は新気付アドレス及び他の構成パラメータを獲得するため事前構成段階を実行すること、
    ｃ）パケット喪失を最小限に抑え、又は除去するために一時パケットを同報し、双報し、又は一時記憶すること、
    d)前記モバイルノードが前記候補ターゲットネットワークに接続する前に、獲得ＩＰアドレス及び獲得構成パラメータを使ってＩＰパッケージを送受信すること、
    を含む、方法。
15. アクセスルータにおいて前記モバイルノードに向かうパケットを一時記憶する、請求項１４に記載の方法。
16. アクセスルータにおいて複数のアクセスネットワークにパケットを報することをさらに含む、請求項１４に記載の方法。
17. メディア独立型事前認証（ＭＰＡ）を実行する方法であって、
    ａ）モバイルノードが発見プロセスを介して候補ターゲットネットワークを探し出し、ＩＰアドレス及び認証エージェント、構成エージェント及び前記候補ターゲットネットワークのアクセス装置を獲得する事前認証段階を、モバイルノードが認証エージェントで事前認証を行っている状態で、実行すること、
    ｂ）前記アクセス装置が事前対応ハンドオーバトンネルを確立するためトンネル管理プロトコルを使用している状態で前記候補ターゲットネットワークからＩＰアドレス又は新
    気付アドレス及び他の構成パラメータを獲得する事前構成段階を実行すること、
    ｃ）前記事前認証又は事前構成段階の間に、前記モバイルノードと候補ターゲットネットワークの前記認証エージェントとの間に確立されるＭＰＡ−ＳＡを使って、前記モバイルノードが現在のネットワークにある間に、前記候補ターゲットネットワークおいてリンク層、ＩＰ層又は上位層のセキュリティをブートストラップすること、
    d)前記モバイルノードが前記候補ターゲットネットワークに接続する前に、獲得ＩＰアドレス及び獲得構成パラメータを使ってＩＰパッケージを送受信すること、
    を含む、方法。
18. 前記候補ターゲットネットワークの前記認証エージェント及び前記モバイルノードは、前記ＭＰＡ−ＳＡを使って鍵を導出する、請求項１７に記載の方法。
19. メディア独立型事前認証（ＭＰＡ）を用いるシステムにおいて初期ネットワーク接続を実行する方法であって、
    ａ）モバイルノードが、発見プロセスを介して候補ターゲットネットワークを探し出し、ＩＰアドレス及び認証エージェント、構成エージェント及び前記候補ターゲットネットワークのアクセス装置を獲得する事前認証段階を、前記モバイルノードが前記認証エージェントで事前認証を実行している状態で実行し、
    b)前記アクセス装置が事前対応ハンドオーバトンネルを確立するためトンネル管理プロトコルを使用している状態で前記候補ターゲットネットワークからＩＰアドレス又は新気付アドレス及び他の構成パラメータを獲得する事前構成段階を実行するように構成されるシステムを設けること、
    ｃ）前記モバイルノードがネットワークに最初に接続するときに、リンク層ネットワークアクセス認証プロトコル又は上位層ネットワークアクセス認証プロトコルを用いて前記初期ネットワーク接続における認証を行うことを含むこと、
    d)前記モバイルノードが前記候補ターゲットネットワークに接続する前に、獲得ＩＰアドレス及び獲得構成パラメータを使ってＩＰパッケージを送受信すること、
    を有する、方法。
20. ＩＥＥＥ８０２．Ｘリンク層ネットワークアクセス認証プロトコルを使用することを含む、請求項１９に記載の方法。
21. ＰＡＮＡネットワーク層ネットワークアクセス認証プロトコルを使用することを含む、請求項１９に記載の方法。
22. メディア独立型事前認証（ＭＰＡ）を実行する方法であって、
    ａ）モバイルノードが、発見プロセスを介して候補ターゲットネットワークを探し出し、ＩＰアドレス及び認証エージェント、構成エージェント及び前記候補ターゲットネットワークのアクセス装置を獲得する事前認証段階を、前記モバイルノードが前記認証エージェントで事前認証を実行している状態で実行すること、
    ｂ）アクセス装置が事前対応ハンドオーバトンネルを確立するためトンネル管理プロトコルを使用している状態で前記候補ターゲットネットワークからＩＰアドレス又は新気付アドレス及び他の構成パラメータを獲得するため事前構成段階を実行すること、
    ｃ）前記モバイルノードが、前記候補ターゲットネットワークのＤＨＣＰサーバ又はＤＨＣＰリレーエージェントに直接通信を行うＤＨＣＰを使って事前対応ＩＰアドレス獲得を実行すること、
    d)前記モバイルノードが前記候補ターゲットネットワークに接続する前に、獲得ＩＰアドレス及び獲得構成パラメータを使ってＩＰパッケージを送受信すること、
    を含む、方法。
23. 前記候補ターゲットネットワークに、前記モバイルノードとＤＨＣＰサーバの間でＤＨＣＰメッセージを中継するＤＨＣＰリレーエージェントを設けることをさらに含む、請求項２２に記載の方法。
24. 事前認証されていないモバイルノードから送られるＤＨＣＰメッセージをブロックするフィルタを設けることをさらに含む、請求項２２に記載の方法。

Images