JP5044855B2

JP5044855B2 - 支援されたプロアクティブなｉｐアドレス取得

Info

Publication number: JP5044855B2
Application number: JP2009524033A
Authority: JP
Inventors: 義洋大場; ロペツ、ラファエル・マリン
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2006-12-05
Filing date: 2007-12-04
Publication date: 2012-10-10
Anticipated expiration: 2027-12-04
Also published as: US8223716B2; EP2109987A2; KR100958905B1; JP2010512034A; CN104270477A; US20080130647A1; WO2008069340A3; CA2672010A1; CN101536471A; KR20080096533A; CA2672010C; WO2008069340A2

Description

本願は、無線ネットワーキングに関し、また、幾つかの好ましい実施形態においては、ＩＰアドレスの事前取得を通じて近隣のネットワーク及び又は類似するものの間でのモバイル機器のハンドオフを向上する方法に関する。

１．ネットワーク及びインターネットプロトコル
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットはコンピュータネットワークの世界的なネットワークである。今日、インターネットは何百万ものユーザが使用できる公衆の自立したネットワークである。インターネットはＴＣＰ／ＩＰ（すなわち、伝送制御プロトコル／インターネットプロトコル）と呼ばれている一組の通信プロトコルを使用して、ホストを接続する。インターネットはインターネットバックボーンとして知られている通信インフラストラクチャを有する。インターネットバックボーンに対するアクセスは、主として企業及び個人のアクセスを再販するインターネットサービスプロバイダ（ＩＳＰ）によって制御されている。

ＩＰ（インターネットプロトコル）は、ネットワーク上においてあるデバイス（例えば、電話、ＰＤＡ［パーソナルデジタルアシスタント］、コンピュータなど）から別のデバイスにデータを送信できるプロトコルである。ＩＰはコネクションレス型プロトコルである。今日では、ＩＰｖ４、ＩＰｖ６などを含む種々のＩＰのバージョンがある。ネットワーク上の各ホストデバイスは、そのホストデバイスのＩＰネットワークへの接続点を識別する少なくとも１つのＩＰアドレスを有する。通信中のエンドポイント間の接続は連続的ではない。ユーザがデータ又はメッセージを送信又は受信するとき、このデータ又はメッセージはパケットとして知られている構成要素に分割される。各パケットは独立したデータの単位として取り扱われる。

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

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

典型的には、第２層より上位の層（例えば、ＯＳＩ及び類似するものにおけるネットワーク層又は第３層を含む層など）が、上位レイヤと呼ばれる。

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

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

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

ＩＥＥＥ標準であるＩＥＥＥ８０２．１１は、無線ＬＡＮ及びデバイスのための技術を規定する。８０２．１１を使用すれば、各単一基地局がいくつかのデバイスをサポートする無線ネットワーキングが実現できる。いくつかの例では、デバイスに無線ハードウェアを事前装備しても良いし、又は、ユーザが、例えばアンテナを含み得るカードなどの別個のハードウェアをインストールしても良い。一例として、８０２．１１で使用されるデバイスは、通常、デバイスがアクセスポイント（ＡＰ）であるか、移動局（ＳＴＡ）であるか、ブリッジであるか、ＰＣＭＣＩＡカードであるか、又は別のデバイスであるか否かに関係なく、３つの注目すべき要素、すなわち無線トランシーバ、アンテナ及びネットワークにおけるポイント間のパケットフローを制御するＭＡＣ（媒体アクセス制御）層を含む。

更に、いくつかの無線ネットワークでは、マルチプル・インタフェース・デバイス（ＭＩＤ）が利用できる。ＭＩＤは、例えばブルートゥースインタフェース及び８０２．１１インタフェースなど、２つ以上の独立したネットワークインタフェースを含むことができ、よって、ＭＩＤは、複数のブルートゥースデバイスと接続できるだけでなく、２つの別個のネットワークに参加できるようになる。ＭＩＤは、ＩＰアドレスと、このＩＰアドレスと関連付けられた共通ＩＰ（ネットワーク）名を持つことができる。

無線ネットワークデバイスには、ブルートゥースデバイス、マルチプル・インタフェース・デバイス（ＭＩＤ）、８０２．１１ｘデバイス（例えば８０２．１１ａ、８０２．１１ｂ及び８０２．１１ｇのデバイスを含むＩＥＥＥ８０２．１１デバイス）、ＨｏｍｅＲＦ（ホーム無線周波数）デバイス、Ｗｉ−Ｆｉ（ワイヤレス・フィディリティー）デバイス、ＧＰＲＳ（汎用パケット無線サービス）デバイス、３Ｇセルラーデバイス、２．５Ｇセルラーデバイス、ＧＳＭ（移動通信用グローバルシステム）デバイス、ＥＤＧＥ（ＧＳＭ進化型高速データレート）デバイス、ＴＤＭＡ型（時分割多元接続）デバイス、又はＣＤＭＡ２０００を含むＣＤＭＡ型（符号分割多元接続）デバイスが含まれ得るが、これらに限定されない。各ネットワークデバイスは、ＩＰアドレス、ブルートゥースデバイスアドレス、ブルートゥース共通名、ブルートゥースＩＰアドレス、ブルートゥースＩＰ共通名、８０２．１１ＩＰアドレス、８０２．１１ＩＰ共通名、又はＩＥＥＥＭＡＣアドレスを含む様々なタイプのアドレスを含むことができるが、これらに限定されない。

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

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

好ましい実施形態は、例えば以下の参考文献に説明される技術を改良するものであり、また、各参考文献の全体が参照してここに組み込まれる。
１．Perkins, C., “IP Mobility Support for IPv4”, RFC 3344, August 2002（Referred to herein as [RFC3344]）.
２．Johnson, D., Perkins, C. and J. Arkko, “Mobility Support in IPv6”, RFC 3775, June 2004（Referred to herein as[RFC3775]）.
３．Malki, K., “Low latency Handoffs in Mobile IPv4”, draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in progress), June 2004（Referred to herein as [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（Referred to herein as [I-D.ietf-mipshopfast-mipv6]）.
５．Liebsch, M., “Candidate Access Router Discovery”, draft-ietf-seamoby-cardprotocol-08 (work in progress), September 2004（Referred to herein as [I-D.ietf-seamoby-card-protocol]）.
６．Loughney, J., “Context Transfer Protocol”, draft-ietf-seamoby-ctp-11 (work in progress), August 2004（Referred to herein as [I-D.ietf-seamoby-ctp]）.
７．Aboba, B., “Extensible Authentication Protocol (EAP) Key Management Framework”, draft-ietf-eap-keying-04 (work in progress), November 2004（Referred to herein as [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（Referred to herein as [I-D.ietf-panapana]）.
９．Kim, P., Volz, B. and S. Park, “Rapid Commit Option for DHCPv4”, draft-ietf-dhc-rapid-commit-opt-05 (work in progress), June 2004（Referred to herein as [I-D.ietf-dhc-rapid-commit-opt]）.
１０．ITU-T, “General Characteristics of International Telephone Connections and International Telephone Cirsuits: One-Way Transmission Time”（Referred to herein as [RG98]）.
１１．ITU-T, “The E-Model, a computational model for use in transmission planning”（Referred to herein as [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”（Referred to herein as [ETSI]）.
１３．Kivinen, T. and H. Tschofenig, “Design of the MOBIKE protocol, ” draft-ietf-mobike-design-01 (work in progress), January 2005（Referred to herein as [I-D.ietf-mobike-design]）.
１４．Moskowitz, R., “Host Identity Protocol”, draft-ietf-hip-base-01 (work in progress), October 2004（Referred to herein as [I-D.ietf-hip-base]）.
１５．Almes, G., Kalidindi, S. and M. Zekauskas, “A One-way Delay Metric for IPPM”, RFC 2679, September 1999（Referred to herein as [RFC2679]）.
１６．Almes, G., Kalidindi, S. and M. Zekauskas, “A One-way Packet Loss Metric for IPPM”, RFC 2680, September 1999（Referred to herein as [RFC2680]）.
１７．Almes, G., Kalidindi, S. and M. Zekauskas, “A Round-trip Delay Metric for IPPM”, RFC 2681, September 1999（Referred to herein as [RFC2681]）.
１８．Simpson, W., “IP in IP Tunneling”, RFC 1853, October 1995（Referred to herein as [RFC1853]）.
１９．Patrick, M., “DHCP Relay Agent Information Option”, RFC 3046, January 2001（Referred to herein as [RFC3046]）.
２０．Schulzrine, H., “Application Layer Mobility Using SIP”（Referred to herein as [SIPMM]）.
２１．Yegin, A., “Supporting Optimized Handover for IP Mobility-Requirements for Underlying Systems”, draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002（Referred to herein as [I-D.manyfolks-l2-mobilereq]）.
２２．Cambell, A., Gomez, J., Kim, S., Valko, A. and C. Wan, “Design, Implementation, and Evaluation of Cellular IP”（Referred to herein as [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”（Referred to herein as [HAWAII]）.
２４．Das, S., Dutta, A., Misra, A. and S. Das, “IDMP: An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks”（Referred to herein as [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（Referred to herein as [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”（Referred to herein as [YOKOTA]）.
２７．Shin, S., “Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs”（Referred to herein as [MACD]）.
２８．Dutta, A., “Secured Universal Mobility”（Referred to herein as [SUM]）.
２９．Dutta, A., “Fast handoff Schemes for Application Layer Mobility Management”（Referred to herein as [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（Referred to herein as [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（Referred to herein as [NETDISC]）.
３２．Dutta, A., “GPS-IP based fast-handoff for Mobiles”（Referred to herein as [GPSIP]）.
３３．[MAGUIRE] Vatn, “The effect of using co-located care-of-address on macro handover latency. ”
３．モバイル機器のハンドオフ
例えば、ＩＰベースの無線ネットワークインターフェース（例えば、ＩＥＥＥ８０２．１１又は８０２．１６のインターフェースなど）を備えたモバイル機器と関連して、該モバイル機器は、それが一つのネットワークから他のネットワークへ移動する場合に、ローミング又はハンドオフを実行する必要がある。既存のハンドオフ方法では、ハンドオフは、典型的には、以下のプロトコル層の特定のハンドオフのシーケンスを実行することにより遂行される。

第１に、ハンドオフは物理層で行われる。その際、モバイル機器は、その無線チャネルを、例えば、ターゲットネットワークにおける無線基地局又は無線アクセスポイントに切り替える。

第２に、ハンドオフは第２層で行われる。その際、モバイル機器は、その第２層（すなわち、リンク層）の接続を、ターゲットネットワークに切り替える。上に説明されるように、リンク層又は第２層は、直ちに、ユーザトラフィックを運ぶＩＰ層の直下のプロトコルを照会する。ターゲットネットワークがそのような認証を必要とする場合、モバイル機器は、ターゲットネットワークとの第２層認証を実行する。

第３に、ハンドオフはＩＰ層で行われる。その際、モバイル機器は、ターゲットネットワークからローカルＩＰアドレスを取得し、ターゲットネットワークにより要求されればＩＰ層認証を行ない、次いで、該モバイル機器に向けられるＩＰパケットを、ターゲットネットワークを介して該モバイル機器へ、ＩＰネットワークによりルーティングすることができるように、ＩＰ層位置の更新を実行する。場合によっては、ＩＰ層位置更新をサポートする一つの方法は、インターネット技術標準化委員会（ＩＥＴＦ）により定義されたモバイルＩＰを用いることである。

第４に、ハンドオフはアプリケーション層で行われる。モバイル機器は、そのアプリケーショントラフィックがターゲットネットワークを介して該モバイル機器上のアプリケーションに正確に流れることを保証するために、アプリケーション層での必要なステップを実行する。例えば、モバイル機器が、そのアプリケーション層シグナリングを管理するために、ＩＥＴＦにより定義されたセッション確立プロトコル（ＳＩＰ）を用いる場合、アプリケーション層ハンドオフは、そのモバイル機器がそのホームＳＩＰサーバとともにその現在位置を更新することにより達成することができる。モバイル機器はまた、ターゲットネットワークにより要求されれば、ターゲットネットワークとのアプリケーション層認証を実行する必要がある場合がある。これは、例えば、モバイル機器が、移動先の（visited）３ＧＰＰ（第３世代パートナーシッププロジェクト）無線ネットワークにおけるＩＰマルチメディアサブシステム（ＩＭＳ）を利用しており、ＩＭＳが、アプリケーション層シグナリング及び３ＧＰＰネットワーク上のマルチメディアアプリケーションの管理をサポートする、ＳＩＰベースシステムである場合である。

ＩＰ層ハンドオフ又はアプリケーション層ハンドオフのいずれかで十分であることがしばしばある。すなわち、ＩＰ層及びアプリケーション層ハンドオフの両方を実行する必要がないことがある。これらの既存の方法は、それがＩＰベース無線ネットワークにおいて用いられる場合に、重大なハンドオフ遅延をもたらすことがあり得る。例えば都市のように多数の無線ローカルエリアネットワーク（ＷＬＡＮ）が存在する地理的領域における複合ビル若しくは居住施設の内部で、又は複数の無線ＬＡＮが存在する他の公共の場において、モバイル機器は、複数の無線ネットワークから強い無線信号を同時に受信する場合がある。しかしながら、モバイル機器は、これらの無線ネットワークのうちのいくつかを用いることを認められない場合がある。

上に説明された既存のハンドオフ方法の下では、モバイル機器は、例えば無線信号の強度に基づいて、ターゲットネットワークを選択し、上述したステップを経て該ターゲットネットワークに接続し、次いで、例えば、そのネットワークを用いることが認められるかどうか、又は該モバイル機器が必要とする能力（例えば十分利用可能な帯域幅）若しくはサービスをそのネットワークが提供しないかどうかを、発見する。その結果、モバイル機器は、別のネットワークへの接続を試みる必要があることがあり、また、最終的にそれが必要とする能力及びサービスを提供し且つそれが利用することを許されるネットワークに接続するまで（又は、それがすべての可能なネットワークを使い尽くすまで）、このプロセスを繰り返すことがある。それにより、既存のシステムでは、ハンドオフは、耐えられないくらい長い時間を取ることがあり、また、例えばいくつかの実例としてライブ音声及び又はビデオアプリケーションのようなセンシティブなアプリケーションを、遅延させることがある。

様々なシステム及び方法が知られている一方、依然として、無線ネットワークにおいてハンドオフを実行する改善されたシステム及び方法の必要性が残っている。

本発明の好ましい実施形態の広い態様は、ＭＮがＩＰアドレスを要求する前でさえＩＰアドレスを取得する方法である。

本発明の好ましい実施形態の他の態様は、ちょうど必要なときにＭＮに供給されるＩＰアドレスのプールの保持を可能にすることである。

本発明の好ましい実施形態の他の態様は、ＭＰＡフレームワークにおけるＩＰアドレスを事前設定（pre-configure）するためにＤＨＣＰが用いられるときに、ＭＮにＩＰアドレスを提供するのに要求される時間の削減である。

本発明の好ましい実施形態の他の態様は、ＰＡＮＡ支援されたプロアクティブなＩＰアドレス取得、ＩＫＥｖ２支援されたプロアクティブなＩＰアドレス取得及びＤＨＣＰのみを用いるプロアクティブなＩＰアドレス取得がちょうど必要なときにＭＮに供給されるＩＰアドレスのプールを保持するシステムのアプリケーションである。

本発明の好ましい実施形態の他の態様は、特定のＰａＣについてＰＡＮＡセッションが作成されていないときでも、ＰＡＡがＰＡＮＡセッションＩＤのセットを事前に作成するシステムである。ＰＡＮＡセッションＩｄのセットは、ＰＡＡが、新しいＰａＣにセッションＩｄを要求する最初のＰＡＮＡメッセージを送信する場合に消費される、セッションＩｄのプールを形成する、すなわち、ＰＡＡが、ＰＡＮＡスタートリクエスト（PANA-Start-Request）を送信する場合に、セッションＩｄはプールから送信される。

本発明の好ましい実施形態の他の態様は、セッションＩｄのプールの生成中に、また、ＰＡＡが予約されたリソースに対するインデックスとしてそのセッションＩｄを用いることにより、いくつかのリソースを予約するシステムである。本発明の好ましい実施形態の他の態様は、事前生成（pre-generated）されたＰＡＮＡセッションＩｄのセットに基づいたＤＨＣＰを介してＩＰアドレスをプリフェッチするためのインデックスを使用することであり、それによって、ＭＮ（ＰａＣ）にＩＰアドレスをより速く提供し、事前認証（pre-authentication）時間全体を大幅に削減する。

本発明の好ましい実施形態の他の態様は、ＰＡＡが、一連の固有のセッションＩｄを、それらがクライアントにより必要とされる前に作成し蓄えるシステムである。ＰａＣが、管理フレームの形式におけるセッションＩｄリクエストを送信する場合に、ＰＡＡは、その作成済みのセッションＩｄのプールからセッションＩｄを返す。次いで、ＰＡＡは、未使用のプールからセッションＩｄを削除し、それが送信されるＰａＣに対応付けられる新しいテーブルに、それを移動させる。ＰａＣは、複数のセッションＩｄが受信された場合に、それがどのＰＡＡに属するかＰａＣ自身に分かるように、受信したセッションＩｄを、該セッションＩｄを送信したＰＡＡに関する情報とともに蓄える。

様々な実施形態の上述の及び又は他の態様、特徴及び又は利点は、以下の説明を添付の図と併せて考慮すればさらに理解されるであろう。様々な実施形態は、当てはまる場合には、種々の態様、特徴及び又は利点を含み、及び又は除外することができる。加えて、様々な実施形態は、当てはまる場合には、他の実施形態の１つ若しくは複数の態様又は特徴を組み合わせることができる。個々の実施形態の態様、特徴及び又は利点の記述は、他の実施形態又は特許請求の範囲を限定するものと解釈すべきではない。

ＰＡＮＡ支援されたプロアクティブなＩＰアドレス取得を説明する図ＩＫＥｖ２支援されたプロアクティブなＩＰアドレス取得を説明する図

本発明の好ましい実施形態は、添付図において制限ではなく一例として示される。

本発明は多くの異なる形式で実施されてよいが、多くの例示的な実施形態は、本開示が本発明の原理の例を提供すると考えられるべきである旨、及びこのような例が、本発明を、本明細書に説明されている及び／又は本明細書に図示されている好ましい実施形態に制限することを目的としていない旨の理解の下、本明細書に説明されている。

好ましい実施形態の概要
以下の略語がここに使用される。
認証エージェント（Authentication Agent）（ＡＡ）、
バッファリング制御プロトコル（Buffering Control Protocol）（ＢＣＰ）、
バッファリングノード（Buffering Node）（ＢＮ）、
バッファサイズ（Buffer Size）（ｂｓｚ）、
分類されたトラフィック（Classified Traffic）（ｔｃ）、
コンフィギュレーションエージェント（Configuration agent）（ＣＡ）、
相手ノード（Correspondent Node）（ＣＮ）、
動的ホスト構成プロトコル（Dynamic Host Configuration Protocol）（ＤＨＣＰ）、
サービス終了（End of Service）（ＥＯＳ）、
フラッシングポリシー（Flushing Policy）（ＦＰ）、
インターネット鍵交換セカンドバージョン（Internet Key Exchange second version）（ＩＫＥｖ２）、
ＩＰセキュリティ（IP security）（ＩＰｓｅｃ）、
モバイルノード（Mobile node）（ＭＮ）、
認証プロトコル（Authentication protocol）（ＰＡＮＡ）、
ＰＡＮＡ認証エージェント（PANA authentication agent）（ＰＡＡ）、
ＰＡＮＡクライアント（PANA client）（ＰａＣ）、
結果コード（Result Code）（ｒｃｏｄｅ）、及び
タイムリミット・タイムアウト（Time-limited Timeout）（ｈｐ）。

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

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

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

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

メディア独立事前認証モバイルノード（ＭＮ）：任意のリンク層上で任意のモビリティ管理プロトコルとともに動作する、移動支援された、安全なハンドオーバ最適化スキームであるメディア独立事前認証（media-independent pre-authentication）（ＭＰＡ）のモバイル端末。ＭＰＡモバイルノードは、ＩＰノードである。この文書において、用語“モバイルノード”又は修飾語のない“ＭＮ”は、“ＭＰＡモバイルノード”を意味する。同様に、ＭＰＡモバイルノードは、通常、モビリティ管理プロトコルのモバイルノードの機能を有する。

候補ターゲットネットワーク（Candidate Target Network）（ＣＴＮ）：モバイルが近いうちに移動し得るネットワーク。

ターゲットネットワーク（Target Network）（ＴＮ）：モバイルが移動することを決定したネットワーク。ターゲットネットワークは、１つ以上の候補ターゲットネットワークから選択される。

プロアクティブなハンドオーバトンネル（Proactive Handover Tunnel）（ＰＨＴ）：ＭＰＡモバイルノードと候補ターゲットネットワークのアクセスルータとの間で確立される双方向ＩＰトンネル。この文書において、修飾語なしの用語“トンネル”は、“プロアクティブなハンドオーバトンネル”を意味する。

接続点（Point of Attachment）（ＰｏＡ）：ＭＰＡモバイルノードについてネットワークへのリンク層接続点として機能するリンク層デバイス（例えば、スイッチ、アクセスポイント、基地局など）。

気付けアドレス（Care-of Address）（ＣｏＡ）：ＭＰＡモバイルノードのロケータとしてモビリティ管理プロトコルにより用いられるＩＰアドレス。

メディア独立事前認証（ＭＰＡ）は、任意のリンク層上で任意のモビリティ管理プロトコルとともに動作する、移動支援された、安全なハンドオーバ最適化スキームである。ＭＰＡでは、モバイルノードは、ＣＴＮについてのＩＰアドレス及び他のコンフィギュレーション・パラメータを安全に取得できるだけでなく、取得されたＩＰアドレスを用いて、それがＣＴＮに実際に接続する前に、ＩＰパケットを送信及び受信することができる。これは、モバイルノードが、リンク層でのハンドオーバの実行前に、任意のモビリティ管理プロトコルのバインディング更新を完了し、新しいＣｏＡを用いることを可能にする。

ＭＰＡは、任意のリンク層上で、モバイルＩＰｖ４、モバイルＩＰｖ６、ＭＯＢＩＫＥ、ＨＩＰ、ＳＩＰモビリティなどを含む任意のモビリティ管理プロトコルとともに動作する。ＭＰＡにおいて、ＩＥＥＥ８０２．１１ｉの事前認証の概念は、モバイル端末が未だ現在のネットワークに接続されている間でのネットワークに対するプロアクティブなハンドオーバだけでなく、モバイル端末がそこから移動し得るネットワークからのＩＰアドレスの早期取得を実行するための付加機構を組み込むことによって、より高い層で動作するように拡張される。

ＭＰＡをサポートするＭＮは、ＡＡとの事前認証プロセスを開始する。成功した認証は、ＰＡＡがＡＡとのセキュリティ関連付け（security associations）を確立することを可能にする。これは、ＩＰアドレス及び他のコンフィギュレーション・パラメータをモバイルノードに安全に供給するためのコンフィギュレーション・プロトコルを安全に実行するために用いられるＣＡと、モバイルノードに対するプロアクティブなハンドオーバトンネルを確立するためのトンネル管理プロトコルを安全に実行するＡＲを追加することである。ＭＮが現在の接続点に接続される場合に、この全プロセスが実行される。それは、“draft-ohba-mobopts-mpa-framework-02.txt”、2006年3月、及び“draft-ohba-mobopts-mpa-framework-03.txt”、2006年10月22日に詳細に説明され、それらの開示は参照してここに組込まれる。

前に指摘された文書が述べるように、ＩＰアドレス構成は、数ミリ秒から数秒の間を必要とすることもあり得る。実際、重複アドレス検出は、４秒から１５秒を必要とすることもあり得る。ハンドオーバ時間に影響を与える構成時間を避けるために、本発明のＭＰＡは、現在のネットワークへのＭＮの接続に関して、ハンドオーバ前に確認を開始する。

構成時間は事前認証時間全体に影響を与え、また、事前認証時間はハンドオーバ時間に影響を与えないとは言え、それはＭＮが事前認証を開始するときに影響を与えるかも知れない。事前認証時間が、例えば、数秒を超える場合、ＭＮは、ハンドオーバの開始に十分に先立って、事前認証を開始する必要がある。しかしながら、事前認証時間が低減されるならば、それが実際に前もって必要とされる時に、ＭＮが事前認証を開始することが可能である。さらに、ＭＮ速度は、低減された事前認証時間によって、増加されることがある。

背景
１．アーキテクチャ
好ましい実施形態において、ＰＡＮＡ支援されたプロアクティブなＩＰアドレス取得、ＩＫＥｖ２支援されたプロアクティブなＩＰアドレス取得、ＤＨＣＰのみを用いるプロアクティブなＩＰアドレス取得を利用して、プロアクティブにＩＰアドレスを取得する３つの方法がある。

ＭＰＡフレームワークにおいて、次の機能要素、すなわち、認証エージェント（ＡＡ）、コンフィギュレーション・エージェント（ＣＡ）及びアクセスルータ（ＡＲ）が、モバイルノードと通信する各々のＣＴＮに常駐することが期待される。それらの要素のうちの一部又は全部は、単一のネットワークデバイス又は個別のネットワークデバイスに配置することが可能である。

１．１．ＰＡＮＡ支援されたプロアクティブなＩＰアドレス取得
図１の図表のフローチャート１００は、ＰＡＮＡ支援されたＩＰアドレスの取得のプロセスを示す。この場合、ＰＡＡ１０２は、１からｎまで及ぶプールにおいてセッションＩｄ値の数を使って、セッションＩｄ値のプール１０６を生成する。それらＩＰアドレスは、各々の事前生成されたセッションＩｄについて同一のシーケンスに従って個別に処理される。

セッションＩｄのプールを作成するために、ＰＰＡ１０２は、ＤＨＣＰサーバ１１０の可用性（availability）及び受入れ可能性（acceptability）を判定するためのクライアント識別子及びセッションＩｄリクエストを含む“ディスカバリー”メッセージ１１４を送信して、ＤＨＣＰサーバ１１０を探し特定する。ＤＨＣＰサーバ１１０は、ＰＰＡ１０２に要求された情報を提供する“オファー”１１８で応答する。ＤＨＣＰサーバ１１０が肯定的に応答すれば、ＰＰＡ１０２は続行する。ＰＰＡ１０２は、ＤＨＣＰリレー又はＤＨＣＰクライアントのいずれかとして動作し、セッションＩｄ−１のためのＤＨＣＰリクエスト１２２をＩＰアドレスのためのＤＨＣＰサーバ１１０へ送信する。これは、事前生成されたＰＡＮＡセッションＩｄを含むＤＨＣＰクライアント識別子オプション（オプション番号６１）を用いることによって行われる。ＤＨＣＰサーバ１１０は、肯定応答と事前生成されたセッションＩｄに割り当てられたＩＰアドレス１２６で応答する。次いで、ＰＡＡ１０２は、受信したＩＰアドレスをキャッシュし、該プロセスを繰り返す。

ＰＡＡ１０２がセッションＩｄ−２のリクエストを送信する場合、能力（capability）及び可用性を要求中のＤＨＣＰサーバ１１０をＰＰＡ１０２が探す同一の手順１３２が続く。ＤＨＣＰサーバ１１０は“オファー”１３６で応答し、その時点においてＰＰＡ１０２はセッションＩｄ−２についてＩＰアドレスのリクエストを送信する。ＤＨＣＰサーバ１１０は、事前生成されたセッションＩｄに割り当てられたＩＰアドレスを含むリクエスト１４２で肯定応答する。次いで、ＰＡＡ１０２は、ＩＰアドレスをキャッシュして、次のリクエストに進む。

ディスカバリー１５０、オファー１５２、リクエスト１５２及び肯定応答１５４でのプロセスに見られるように、このプロセスが、ＰＡＡ１０２により生成された各々のセッションＩｄについて、繰り返される。

前述のプロセスの開始状態で、ＰＡＡ１０２は、キャッシュに保持される多くの蓄えられたＩＰアドレスを有する。そのように、ＰａＣ１８０がＰＡＡ１０２からのＩＰアドレスを必要とする場合、それはディスカバリーリクエストを送信することにより事前認証を開始する。

ＰＡＡ１０２は、次の事前取得（pre-acquired）されたセッションＩｄを、プールからＰａＣに送信する１８４。セッションＩｄの肯定応答１８６に際して、認証情報はＰａＣとＰＡＡとの間で交換され１８８，１８９、また、認証が成功する場合、ＰＡＡ１０２は、そのセッションＩｄに関連付けられた、プリフェッチされたＩＰアドレスを、直接ＰａＣに送信する１９２。ＩＰアドレスの受領は、肯定応答され１９４、また、プロセスは必要に応じて繰り返される。ＩＰアドレスをキャッシュに入れることにより、ＰａＣは、ＤＨＣＰサーバ１１０が初期のリクエストのときにアドレスを転送する場合に経験されるであろう遅延を受けることなく、アドレスを取得することが可能である。

ハンドオーバ後に、ＰａＣは、ハンドオーバ前にＩＰアドレスをプリフェッチするために用いられたＰＡＮＡセッションＩｄを伝えるためのＤＨＣＰクライアント識別子オプションを、該プロアクティブに取得されたＩＰアドレスをハンドオーバ後に再取得するために、用いることが可能である。

３．ＩＫＥｖ２支援されたプロアクティブなＩＰアドレス取得
図２のダイアグラム２００において見られるように、ＩＫＥｖ２支援されたプロアクティブなＩＰアドレス取得もまた、ＩＰアドレスをプリフェッチするために用いることが可能である。この実施形態において、ＣＴＮからのＩＰアドレスは、標準的なＤＨＣＰを用いてターゲットネットワーク上のＤＨＣＰサーバ２０４からＩＰアドレスを取得するためのアクセスルータ上に設置された共有（co-located）ＤＨＣＰリレーエージェント又はＤＨＣＰクライアントを用いて、標準的なＩＫＥｖ２手順の一部として、得られる。

ＰＡＡ２０２は、セッションＩｄのプールを事前生成し、セッションＩｄのプールを、直接ＩＰｓｅｃ−ＧＷ２０６に転送する。そのとき、ＩＰｓｅｃ−ＧＷ２０６上のＤＨＣＰリレー／クライアントは、最初にＰＡＡ２０２により作成され、ＰＡＡ２０２から受信された、事前生成されたセッションＩｄのセットとともに構成される。ＩＰｓｅｃ−ＧＷ２０６上のＤＨＣＰリレー／クライアントは、ＩＰアドレスのプールを構築するために、各々の構成されたセッションＩｄにつき１つずつのＩＰアドレスを要求するためのｎ個のＰＡＮＡセッションＩｄを用いる。

これは、ＩＰｓｅｃ−ＧＷ２０６が、通信受容性データ（communication acceptability data）を取得するためのディスカバリーモード２２０においてＤＨＣＰサーバ２０４と連絡を取ることを開始することによって、遂行される。次いで、ＤＨＣＰサーバ２０４は、通信のための能力及び可用性を提供するオファー２２４を返す。オファー２２４が肯定の場合、ＩＰｓｅｃ−ＧＷ２０６は、セッションＩｄ−１に関連付けられるべきＩＰアドレスのためのリクエスト２２８を送信する。ＤＨＣＰ２０４は、そのリクエストを承認して、セッションＩｄ−１に関連付けられたＩＰアドレス２２８、ＩＰａｄｄｒ−１を返す。

続いて起こるディスカバー送信２３０、オファー送信２３２、リクエスト送信２３４、及び肯定応答送信２３６の複数の送信により示されるように、このプロセスは継続され、すべてのＩＰアドレスが取得されるまで、繰り返される。

ＰａＣ２１０がＡＲと連絡を取り、ＩＫＥｖ２セキュリティアソシエーションを約束する場合、ＰａＣは、ＰＡＮＡ認証ステップの間、ＰＡＡにより提供されるセッションＩｄを明示する必要がある。最初にＰＡＮＡによりプールされるセッションＩｄは、この認証処理プロセス中に、ＰａＣ２１０に送信される。

ＩＰアドレスを取得するために、ＰａＣ２１０は、ＩＤ＿ＫＥＹ＿ＩＤペイロードの内部で提供できる、ＰＡＮＡの事前生成されたセッションＩｄを、ＩＰｓｅｃ−ＧＷに送信する。ＩＰｓｅｃ−ＧＷは、ＤＨＣＰサーバからプリフェッチされたプールから、セッションＩｄに対応するＩＰアドレスを返し、遅延を除去する。

ＩＰｓｅｃ−ＧＷ２０６は、コンフィギュレーション・ペイロード内のＩＮＴＥＲＮＡＬ＿ＩＰ４＿ＡＤＤＲＥＳＳ又はＩＮＴＥＲＮＡＬ＿ＩＰ６＿ａｔｔｒｉｂｕｔｅを介して、各々のセッションＩｄリクエストに関連付けられたＩＰアドレスを提供する。ＩＰｓｅｃ−ＧＷ２０６は、ＤＨＣＰクライアントとして動作することによって、ＩＰアドレスのリースをアクティブに保持する。そのために、ＩＰｓｅｃ−ＧＷ２０６は、ＤＨＣＰサーバに送信されるＤＨＣＰリクエスト中に、ＰＡＮＡセッションＩｄを含むＤＨＣＰクライアント識別子オプションを含める。

４．ＤＨＣＰのみを用いたプロアクティブなＩＰアドレス取得
ＤＨＣＰのみを用いることによるプロアクティブなＩＰアドレスの場合には、モバイルノード（ＭＮ）とＣＴＮにおけるＤＨＣＰリレー又はＤＨＣＰサーバとの間のダイレクトＤＨＣＰ通信が可能になる。具体的には、モバイルノードは、リクエストのソースアドレスとして現在の物理インタフェースに関連付けられたアドレスを用いている間、ＣＴＮにおけるＤＨＣＰリレーエージェント又はＤＨＣＰサーバにユニキャストＤＨＣＰメッセージを送信して、アドレスを要求する。この場合、ＰＡＮＡセッションＩｄのセットを事前生成した後に、ＰＡＡは、２つの可能な選択肢を有する。

Ｉ．ＰＡＡは、事前生成されたセッションＩｄのセットを、何らかのプロトコル又はＡＰＩを通してＤＨＣＰサーバの中へインストールする。該ＤＨＣＰサーバにインストールされた各々のＰＡＮＡセッションＩｄについては、関連付けられたＩＰアドレスが存在する。

ＩＩ．ＰＡＡは、前述のように、ＰＡＮＡ支援されたプロアクティブなＩＰアドレス取得の場合について実行された同一のメカニズムに従う。すなわち、ＤＨＣＰリレー又はＤＨＣＰクライアントのいずれかとして動作するＰＡＡは、事前生成されたＰＡＮＡセッションＩｄを含むＤＨＣＰクライアント識別子オプションを用いることによって、ＤＨＣＰサーバにＩＰアドレスを要求する。すなわち、それは、ＤＨＣＰサーバにおけるセッションＩｄｉとＩＰアドレスｉとの間の関連付けを作成する。しかしながら、この場合、ＰＡＡは、ＤＨＣＰサーバにより返されたＩＰアドレスを格納しない。

両方の場合において、ＭＮは、ＰＡＮＡ認証中にＰＡＡにより送信された、ＰＡＮＡセッションＩｄを含むＤＨＣＰクライアント識別子オプションを含むユニキャストＤＨＣＰメッセージを、ＤＨＣＰリレー又は直接ＤＨＣＰサーバに送信する。

ＰＡＮＡ支援されたプロアクティブなＩＰアドレス取得の場合について説明されたように、前述のように、ハンドオーバの後、ＰａＣは、ハンドオーバ前にＩＰアドレスをプリフェッチするために用いられたＰＡＮＡセッションＩｄを伝えるためのＤＨＣＰクライアント識別子オプションを、該プロアクティブに取得されたＩＰアドレスをハンドオーバ後に再取得するために、用いることができる。

本発明の幅広い範囲：
本発明の例示的な実施形態を本明細書に説明してきたが、本開示に基づいて当業者により理解されるように、本発明は本明細書に説明されている多様な好ましい実施形態に限定されるのではなく、同等な要素、変型、省略、（例えば、多様な実施形態全体での態様の）組み合わせ、適応、及び／又は改変を有するあらゆるすべての実施形態を含む。請求項における制限は請求項で利用される言語に基づいて幅広く解釈されるべきであり、本明細書に、あるいは出願の手続き追行の間に説明される例に限定されず、その例は包括的と解釈されるべきである。例えば、本開示では、用語“好ましくは”は包括的であり、“好ましいが、限定されない”を意味する。本開示では、及び本開示の手続き追行中、手段プラス機能（means-plus-function）又はステッププラス機能（step-plus-function）の制限は、特定の請求項の制限について、以下の条件のすべてがその制限内に存在する場合にだけ利用される。つまり、ａ）“のための手段（means for）”又は“のためのステップ（step for）”は、明示的に列挙され、ｂ）対応する機能は明示的に列挙され、及びｃ）その構造をサポートする構造、材料又は行為が列挙される。本開示において、及び本出願の手続き追行中、用語“本発明”又は“発明”は、本開示の中で１つ又は複数の態様に対する参照として使用されてよい。言語本発明又は発明は、臨界の識別として理解されてはならず、すべての態様又は実施形態全体で当てはまると不適切に解釈されてはならず（つまり、本発明は多数の態様と実施形態を有することが理解されるべきである）、出願つまり請求項の範囲を制限すると不適切に解釈されてはならない。本開示では、及び本願の手続き追行の間、用語“実施形態（embodiment）”は任意の態様、特徴、プロセス又はステップ、その組み合わせ、及び／又はその任意の部分等を説明するために使用できる。いくつかの例では、多様な実施形態は重複する特長を含むことがある。本開示では、以下の省略された用語、つまり“例えば”を意味する“ｅ．ｇ．”が利用されてよい。

Claims

ＭＰＡフレームワークにおけるＩＰアドレスを事前設定するためにＤＨＣＰを用いる場合にＭＮにＩＰアドレスを提供するのに要求される時間を低減する方法において、
ａ）複数のセッションＩＤをＰＡＡが生成することと、
ｂ）前記複数のセッションＩＤをセッションＩＤのプールとして保持することと、
ｃ）前記ＰＡＡがセッションＩＤを要求する最初のＰＡＮＡメッセージを送信するときに、前記プールからセッションＩＤを取得することを含み、
前記ＰＡＡは、事前生成されたセッションＩＤを含むＤＨＣＰクライアント識別子オプションを用いてＤＨＣＰサーバにＤＨＣＰリクエストを送信する場合に、ＤＨＣＰリレー又はＤＨＣＰクライアントのいずれかとして働き、前記ＤＨＣＰサーバは、前記識別子に基づいてＰＡＡにＩＰアドレスを提供し、
ＭＮに事前取得されたＩＰアドレスを提供することにより、事前認証の時間を削減する方法。
前記ＰＡＡは、前記事前生成されたセッションＩＤに関連付けて前記ＩＰアドレスをキャッシュする請求項１に記載の方法。
前記ＰａＣは、ハンドオーバ前に前記ＩＰアドレスをプリフェッチするために用いられた前記セッションＩＤを伝えるための前記ＤＨＣＰクライアント識別子オプションを、前記プロアクティブに取得されたＩＰアドレスをハンドオーバ後に再取得するために用いる請求項２に記載の方法。
前記ＰＡＡは、事前取得されたＩＰアドレスをＰａＣに提供する請求項１に記載の方法。
特定のＰａＣとのＰＡＮＡセッションが作成されるのに先立って、前記ＰＡＡが、セッションＩＤのセットを作成するステップを更に含む請求項１に記載の方法。
新しいＰａＣが、前記ＰＡＡとの新しいＰＡＮＡセッションの確立を試行するステップを更に含み、前記ＰＡＡは、ＰＡＮＡ認証リクエスト（PANA-Auth-Request）を送信し、
セッションＩＤは、前記セッションＩＤのセットから送信される請求項５に記載の方法。
ＩＰアドレスは、各々の事前生成されたセッションＩＤについて同一のシーケンスに従って、個別に処理され、セッションＩＤのセットは、ＰＡＡが、前記ＤＨＣＰサーバの可用性及び受容性を判定するためのクライアント識別子及びセッションＩＤリクエストを含むＤＨＣＰディスカバリーメッセージを送信して、ＤＨＣＰサーバを探し特定することによって、生成されることを要求する請求項１に記載の方法。
前記ＤＨＣＰサーバは、要求された情報をＰＡＡに提供するオファーで応答し、前記ＤＨＣＰサーバが肯定的に応答する場合、前記ＰＡＡは、ＤＨＣＰリレー又はＤＨＣＰクライアントのいずれかとして開始及び動作し、ＩＰアドレスのためのＤＨＣＰサーバに対してセッションＩｄ−１のためのＤＨＣＰリクエストを送信する請求項７に記載の方法。
事前生成されたセッションＩｄを含むＤＨＣＰクライアント識別子オプションを用いることを更に含み、前記ＤＨＣＰサーバは、肯定応答で応答し、ＩＰアドレスは、前記事前生成されたセッションＩｄに割り当てられ、前記ＰＡＡは、前記受信ＩＰアドレスをキャッシュし、該処理は、更なるセッションＩｄを取得するために、繰り返される請求項８に記載の方法。
ＰａＣがＰＡＡからのＩＰアドレスを要求する場合、セッションＩｄを含むＰＡＡによりＰＡＮＡスタートリクエストメッセージ（PANA-Start-Request message）で応答されるＰＡＮＡクライアント開始メッセージ（PANA-Client-Initiation message）を送信することによって、事前認証が開始され、ＩＰアドレスは、ＰＡＮＡバインドリクエストメッセージ（PANA-Bind-Request message）に入れて運ばれ、また、前記ＩＰアドレスの受領は、ＰＡＮＡバインド応答メッセージ（PANA-Bind-Answer）で肯定応答され、該処理は、必要に応じて繰り返され、これによって、ＰａＣは、ＤＨＣＰサーバが初期のリクエストのときにアドレスを転送する場合にそうでなければ経験されるであろう遅延を受けることなく、アドレスを取得することが可能である請求項１に記載の方法。
ハンドオーバ後に、ＰａＣは、ハンドオーバ前にＩＰアドレスをプリフェッチするために用いられたセッションＩｄを伝えるためのＤＨＣＰクライアント識別子オプションを、該プロアクティブに取得されたＩＰアドレスをハンドオーバ後に再取得するために用いる請求項１０に記載の方法。
ＩＰアドレスをプリフェッチするためにＩＫＥｖ２支援されたプロアクティブなＩＰアドレス取得を用いて、ＭＮにＩＰアドレスを提供するのに要求される時間を低減する方法において、
ａ）標準的なＩＫＥｖ２手順の一部としてＣＴＮからＩＰアドレスを取得することと、
ｂ）標準的なＤＨＣＰを用いてターゲットネットワーク上のＤＨＣＰサーバからＩＰアドレスを取得するために、ＩＰｓｅｃゲートウェイ上に配置された、共有ＤＨＣＰリレーエージェント又はＤＨＣＰクライアントを提供することと、
ｃ）ＰＡＡが、セッションＩｄのプールを事前生成することと、
ｄ）前記セッションＩｄのプールをＩＰｓｅｃゲートウェイに直接転送することと、
ｅ）前記ＰＡＡにより最初に作成され、前記ＰＡＡから受信された、事前生成された前記セッションＩｄのプールとともに、前記ＩＰｓｅｃゲートウェイ上にＤＨＣＰリレー／クライアントを構成することを含み、
前記ＩＰｓｅｃゲートウェイ上のＤＨＣＰリレー／クライアントは、ＩＰアドレスのプールを構築するために、各々の構成されたセッションＩｄにつき１つずつのＩＰアドレスを要求するための前記セッションＩｄのプールを用いる方法。
前記ＩＰｓｅｃゲートウェイが、通信受容性データを取得するためのディスカバリーモードにおいて前記ＤＨＣＰサーバと連絡を取り、次いで、前記ＤＨＣＰサーバが、通信のための能力及び可用性を提供するオファーを返し、オファーが肯定の場合、前記ＩＰｓｅｃゲートウェイが、第１のセッションＩｄに関連付けられるべきＩＰアドレスのためのリクエストを送信し、前記ＤＨＣＰが、前記リクエストを承認して、前記第１のセッションＩｄに関連付けられたＩＰアドレスを返すステップを更に含み、前記ステップは、すべてのＩＰアドレスが取得されるまで、繰り返される請求項１２に記載の方法。
前記ＰａＣが、ＩＰｓｅｃゲートウェイと連絡を取り、ＩＫＥｖ２セキュリティを約束するステップを更に含み、
前記ＰａＣは、前記ＰＡＮＡ認証ステップの間、ＰＡＡにより提供される前記セッションＩｄを明示する請求項１３に記載の方法。
前記ＰａＣが、ＩＰアドレスを取得するために、ＩＤ＿ＫＥＹ＿ＩＤペイロードの内部で提供できる、ＰＡＮＡの事前生成されたセッションＩｄを、前記ＩＰｓｅｃゲートウェイに送信し、前記ＩＰｓｅｃゲートウェイが、前記ＤＨＣＰサーバからプリフェッチされたプールから、前記セッションＩｄに対応するＩＰアドレスを返すステップを更に含み、これによって、遅延が除去される請求項１２に記載の方法。
ＤＨＣＰのみを用いて、ＭＮにＩＰアドレスを提供するのに要求される時間を低減する方法において、
前記モバイルノードと前記ＣＴＮにおけるＤＨＣＰリレー又はＤＨＣＰサーバとの間のダイレクトＤＨＣＰ通信を可能にすることと、
前記モバイルノードが、リクエストのソースアドレスとして現在の物理インタフェースに関連付けられたアドレスを用いている間、前記ＣＴＮにおける前記ＤＨＣＰリレーエージェント又は前記ＤＨＣＰサーバにユニキャストＤＨＣＰメッセージを送信して、アドレスを要求することと、セッションＩｄのセットは事前生成されたものである、
前記ＰＡＡが、ＤＨＣＰリレー又はＤＨＣＰクライアントのいずれかとして動作し、前記事前生成されたセッションＩｄを含むＤＨＣＰクライアント識別子オプションを用いることによって、ＤＨＣＰサーバにＩＰアドレスを要求することを含み、これによって、前記ＤＨＣＰサーバにおけるセッションＩｄｉとＩＰアドレスｉとの間の関連付けを作成し、ＰＡＡは、ＤＨＣＰサーバにより返されたＩＰアドレスを格納しない、方法。
前記ＰＡＡが、前記事前生成されたセッションＩｄのセットを、何らかのプロトコル又はＡＰＩを通してＤＨＣＰサーバへインストールすることを更に含み、前記ＤＨＣＰサーバにインストールされた各々のセッションＩｄについては、関連付けられたＩＰアドレスが存在する請求項１６に記載の方法。
前記モバイルノードは、ＰＡＮＡ認証中にＰＡＡにより送信された、セッションＩｄを持ったＤＨＣＰクライアント識別子オプションを含むユニキャストＤＨＣＰメッセージを、ＤＨＣＰリレー又は直接ＤＨＣＰサーバに送信し、ハンドオーバの後、前記ＰａＣは、ハンドオーバ前にＩＰアドレスをプリフェッチするために用いられた前記セッションＩｄを伝えるための前記ＤＨＣＰクライアント識別子オプションを、前記プロアクティブに取得されたＩＰアドレスをハンドオーバ後に再取得するために、用いる請求項１６に記載の方法。