JP2010519829A

JP2010519829A - プロキシＭＩＰｖ６環境における高速ハンドオフをサポートするメディア独立事前認証

Info

Publication number: JP2010519829A
Application number: JP2009550606A
Authority: JP
Inventors: 謙一谷内; ダッタ、アシュトシュ; ファジャード、ビクター; 義洋大場
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2007-02-23
Filing date: 2008-02-25
Publication date: 2010-06-03
Anticipated expiration: 2028-02-25
Also published as: JP5122588B2; US8446875B2; CA2679202A1; EP2116070B1; CA2679202C; EP2116070A4; EP2116070A2; US20080207206A1; WO2008103488A3; WO2008103488A2

Abstract

本明細書では、ＰＭＩＰｖ６を対象とする高速ハンドオーバを提供するためのプロアクティブ機構について記載される。特に、メディア独立事前認証（ＭＰＡ）技術を用いてＰＭＩＰｖ６のための高速ハンドオフをどのように実現することができるかについて記載される。ＰＭＩＰｖ６環境のための高速ハンドオフの必要性を検討している。そしてＰＭＩＰｖ６のためのドメイン内及びドメイン間ハンドオフの両方を含む異なるステップ中でＭＰＡ技術をどのように用いることができるかを説明している。前のローカルモビリティ（ＰＭＡ）ドメインにいる間、モバイルがアクセス認証を行うことができ、以前として前のネットワークにいる間にハンドオフ関連動作の多くを終えることができるように、ＭＰＡベースの高速ハンドオーバは事前認証機構を利用する。

Description

関連出願

本願は、全開示内容が参照により本明細書に導入される２００７年２月２３日提出の米国暫定出願第６０／８９１，３４９号の非暫定出願であり、３５Ｕ．Ｓ．Ｃ．１１９条に基づく優先権を主張する。

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

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

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

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

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

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

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

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

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

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

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

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

ＭＰＡの概観：
メディア独立事前認証（ＭＰＡ）に関する詳細が、下記の参考文献［ｌ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｆｒａｍｅｗｏｒｋ］及び［ｌ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｉｍｐｌｅｍｅｎｔａｔｉｏｎ］、ならびに以下の特許出願（１）ＡＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎと題して２００６年２月２日に提出された米国特許出願第１１／３０７，３６２号、（２）ＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＳｕｐｐｏｒｔｆｏｒＰＡＮＡ）と題して２００６年３月９日に提出された米国特許出願第１１／３０８，１７５号、（３）ＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−ＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｍｐｒｏｖｅｍｅｎｔｓ：ＩｎｃｌｕｄｉｎｇＣｏｎｓｉｄｅｒａｔｉｏｎｓｆｏｒＦａｉｌｅｄＳｗｉｔｃｈｉｎｇａｎｄＳｗｉｔｃｈｂａｃｋと題して２００６年４月１４日に提出された米国特許出願第１１／２７９，８５６号、及び（４）ＭＰＡＩｍｐｒｏｖｅｍｅｎｔｓＲｅｌａｔｅｔｏＰｒｅ−ＦｅｔｃｈｉｎｇｏｆＩＰＡｄｄｒｅｓｓｅｓと題して２００６年１２月５日に提出された米国特許出願第１１／５６７，１３４号において述べられており、参照することにより全開示がそれぞれ本明細書に導入される。

ＭＰＡは、（モバイルが近い将来に移動するかもしれない）ネットワークへのレイヤ２アソシエーションを確立する前に行われるモバイル支援の高次レイヤ認証、承認、及びハンドオーバのスキームである。これは、安全でシームレスなモビリティ最適化を提供し、ドメイン間ハンドオーバ、ならびに単一インタフェース及び複数インタフェースの両方が関与するヘテロジニアスなハンドオーバに有効である。ＭＰＡは、ハンドオーバが実際に起こる前に、ターゲットネットワークに対する事前構成及び事前認証を行うことによって、ターゲットネットワークへのシームレスなハンドオーバ及び接続性を保証するために実行される一連の技術／アルゴリズムである。これは、実際のハンドオーバが現実に起こる前にプロアクティブなレイヤ３及びレイヤ４アソシエーション及びバインディングを行い、通常はレイヤ２アソシエーションの後に発生するこれら動作のための時間を省くことにより、既存のモビリティプロトコルの性能を向上させるため用いることができる。さらに、レイヤ２ハンドオーバは、８０２．１１ＡＰのチャネルスキャンの抑制、及び選択ターゲットネットワークＳＳＩＤのチャネル番号の事前情報を所有（コンセプトの証明のために行われる）することによるインタフェースドライバでの最良ＡＰの選択によって向上される。したがって、ターゲットネットワークへのアソシエーションでは、チャネルスキャニング、ＰｏＡＭＡＣアドレスの検出、及び適合チャネル選択を回避する。

ＭＰＡフレームワーク
参考として、図１８は、メディア独立事前認証の一部であってプロアクティブな事前認証、事前構成、及びプロアクティブなハンドオーバトンネリング技術を提供する機能コンポーネントのうちのいくつかを示している。

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

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

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

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

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

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

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

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

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

メディア独立ハンドオーバサービス：
ＤｒａｆｔＩＥＥＥＳｔａｎｄａｒｄｆｏｒＬｏｃａｌａｎｄＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋｓと名称付けられた、２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９、即ち、メディア独立ハンドオーバサービスにおいて、特に、該文献は８０２方式とセルラー方式との間のハンドオーバを最適化する８０２メディアアクセス独立機構の仕様を定めている。Ｉ．Ｅ．Ｅ．Ｅ．８０２．２１規格は異種８０２方式間のハンドオーバの最適化を可能にし、８０２方式とセルラー方式との間のハンドオーバを容易化する拡張メディアアクセス独立機構を定義している。ＩＥＥＥ８０２．２１（メディア独立ハンドオーバ）規格の範囲は異種メディア間のハンドオーバを最適化するためリンクレイヤ情報及び上位レイヤに関連する他のネットワーク情報を提供する仕様を作り上げることである。これは３ＧＰＰ，３ＧＰＰ２により規定されるリンク及びＩＥＥＥ８０２規格ファミリにおける有線及び無線メディアの両方を含む。特に断りない限り、本明細書で「メディア」とは、知覚イメージの伝達（例えば、オーディオ、ビデオなど）ではなく、電気通信システム（例えば、ケーブル、無線、衛星など）をアクセスする方法／モードのことを指す。例えば、ＤｒａｆｔＩＥＥＥＳｔａｎｄａｒｄｆｏｒＬｏｃａｌａｎｄＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋｓ：ＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＨａｎｄｏｖｅｒＳｅｒｖｉｃｅｓと題された２００６年９月のＩ．Ｅ．Ｅ．Ｅ．Ｐ８０２．２１／Ｄ．０１．０９の１．１を参照されたい。Ｉｄを参照されたい。

ネットワークベース局所モビリティ管理：
以下に述べるように、ローカルモビリティ管理の目的はＪ．ＫｅｍｐｆによるＩ．Ｅ．Ｔ．Ｆ．インターネットドラフト「ＧｏａｌｓｆｏｒＮｅｔｗｏｒｋ−ｂａｓｅｄＬｏｃａｌｉｚｅｄＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ（ＮＥＴＬＭＭ），Ｄｏｃｕｍｅｎｔ：ｄｒａｆｔ−ｉｅｔｆ−ｎｅｔｌｍｍ−ｎｏｈｏｓｔ−ｒｅｑ−０２．ｔｘｔ，Ｊｕｎｅ，２００６」に説明されている。

上記参考文献では、ローカルモビリティの管理にグローバルモビリティプロトコルが用いられる場合に生じる基本的問題が説明されており、局所モビリティ管理に現在のところ用いられている２つのアプローチ−ほとんどのＩＥＴＦプロトコルによって用いられるホストベースのアプローチ、及び異なるサブネットでＷＬＡＮスイッチ間に用いられる独自仕様（ｐｒｏｐｒｉｅｔａｒｙ）の無線ＬＡＮ（ＷＬＡＮ）スイッチのアプローチ−について検討されている。該問題を記述する文献からの結論は、アプローチのいずれも、その問題に対する完全解を持っていないことである。ＷＬＡＮスイッチアプローチは、モバイルノード上にＷｉＦｉ用の標準ドライバー以外のソフトウェアを必要としないことから、ネットワーク・オペレーター及びユーザーにはとても便利であるが、プロプラエタリであるという性質により相互運用性が制限され、単一ラストホップリンク型及び帰路リンク型への制約によりスケーラビリティが制限される。ＩＥＴＦホストベースプロトコルは、すべてのグローバルモビリティプロトコルとの互換性をもち得ないホストソフトウェアスタックの変更を要する。デプロイアビリティを制限し得る特殊で複雑なネットワークとのセキュリティ処理も必要である。局所モビリティ管理に関してホスト上に何らソフトウェアを必要としないネットワークベースの局所モビリティ管理プロトコルが望ましい、というのが結論である。

この参考文献は、簡略な機能アーキテクチャ及びネットワークベース局所モビリティ管理プロトコル（ＮＥＴＬＭＭ）に関して詳細な目的を示している。更に、該文献は以下の用語を示している。

局所モビリティ管理ドメイン：
モビリティがＮＥＴＬＭＭプロトコルによって処理されるという意味での［１］に定義されたアクセスネットワーク
モバイルアクセスゲートウェイ：
モバイルアクセスゲートウェイ（ＭＡＧ）は、ローカルモビリティアンカーとのＮＥＴＬＭＭシグナリングを通じて特定のエッジリンクを終結し、エッジリンク間のモバイルノードＩＰレベルモビリティを監視する機能的なネットワークエレメントである。またＭＡＧは、ＭＡＧ管理下でエッジリンク内に現在位置するモバイルノードに関してローカルモビリティアンカーからのホストルーティングされたデータトラフィックを終結し、管理下のエッジリンク上のモバイルノードからのデータトラフィックをローカルモビリティアンカーにフォワードする。

ローカルモビリティアンカー：
ローカルモビリティアンカー（ＬＭＡ）は、その管理下の局所モビリティ管理ドメイン内のモバイルノードについて、ホスト経路及び関連するフォワーディング情報のコレクションを維持するルータである。関連するＭＡＧと共に、ＬＭＡは、局所モビリティ管理ドメイン内のＩＰノードモビリティを管理するためにＮＥＴＬＭＭプロトコルを用いる。モバイルノードが局所モビリティ管理ドメイン内を動き回っても、モバイルノードデータトラフィックのルーティングはＬＭＡに固定である。

参考文献は、以下のコンポーネントを持つ以下のＮＥＴＬＭＭ機能アーキテクチャを説明している。バックボーンネットワーク内のローカルモビリティアンカー（ＬＭＡ）は、局所モビリティ管理ドメイン内の個々のモバイルノードについて経路のコレクションを維持する。経路は、モバイルノードが現在位置するリンクを管理しているモバイルアクセスゲートウェイ（ＭＡＧ）を示す。モバイルノードに対するパケットはＬＭＡとＭＡＧの間のトンネルを介してモバイルノード間でルーティングされる。モバイルノードがあるリンクから別のリンクに移動する場合、ＭＡＧはＬＭＡに経路更新を送信する。モバイルノード移動についてＭＡＧに通知するための移動検出のような総括的なモビリティ機能に関して、何らかのモバイルノードの関与が必要であり求められるが、局所モビリティ管理それ自体についてはモバイルノード対ネットワークプロトコルは特に必要ではない。モビリティ管理におけるホストスタック関与は、それによりＩＰレイヤにおける総括的なモビリティ機能に限定され、特殊な局所モビリティ管理ソフトウェアは必要ではない。

プロキシモバイルＩＰｖ６：
プロキシモバイルＩＰｖ６（ＰＭＩＰｖ６）の例示の概要は、ＰｒｏｂｌｅｍＳｔａｔｅｍｅｎｔｆｏｒＣｏｍｍｏｎＩｎｔｅｒｆａｃｅＳｕｐｐｏｒｔｉｎＬｏｃａｌｉｚｅｄＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ，Ｉ．Ｅ．Ｔ．Ｆ．，ｄｒａｆｔ−ｃｏｒｕｊｏ−ｐｓ−ｃｏｍｍｏｎ−ｉｎｔｅｒｆａｃｅｓ−ｌｍｍ−０１，Ｊｕｌｙ，２００７，Ｄ．Ｃｏｒｕｊｏ，ｅｔａｌにおいて説明される。可能であるならばモバイルＩＰｖ６（ＭＩＰｖ６）［ＲＦＣ３７７５］実体及び概念を再利用するが、この文献では、ＰＭＩＰｖ６がローカルモビリティサポートを目的とした、ネットワークベースのモビリティ管理プロトコルであることを示す。このプロトコルにおいてモバイルノード（ＭＮ）は、ホームプレフィックスを含むプロファイルのようなネットワーク上に記憶される情報関連セットを有する識別子（例えばＮＡＩ）によって区別される。この情報は、典型的にはポリシーストア（例えばＡＡＡ）において維持され、ＬＭＤにおけるすべてのＰＭＩＰｖ６実体によってアクセス可能である。ＰＭＩＰｖ６は、Ｌ２ネットワーク接続時にノードが認証されることを想定している。この接続は、ネットワークがホームネットワークプレフィックスを取り出すことができることを保証するために必要な情報（例えばノードＮＡＩ）を提供する。その後、プレフィックスはノードへのルータ広告において用いられ、該ノードがホームドメイン上にいることを通知する。このシナリオでは、ＭＮは、フォーリンネットワークを横切るローミングの際、ノードの視点から見て訪問先のＬＭＤを単一のリンクに変換するときでさえ、ネットワークインターフェースに関してホームアドレスを構成する。

アクセスルータ内に位置するプロキシモバイルエージェント（ＰＭＡ）は、ノードに代ってシグナリングを行い、ＭＮ情報を取り込み、ホームネットワーク挙動をエミュレートして、カスタマイズされたルータ広告を送信する実体である。ＰＭＡモビリティシグナリングは、ＭＮのホームエージェントへのバインディングを更新すること、登録済みＭＮの現在の気付けアドレスがＰＭＡのアドレスであることをＨＡに通知することからなる。これらの手順は、ＨＡとＰＭＡの間のトンネルの確立をもたらす。

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

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

背景文献：
以下の背景文献は、参照することにより、本明細書に完全に記載されているかのように、その全体が本明細書に組み込まれる。

１．Ｇｕｎｄａｖｅｌｌｉ，Ｓ．，"ＰｒｏｘｙＭｏｂｉｌｅＩＰｖ６"，ｄｒａｆｔ−ｓｇｕｎｄａｖｅ−ｍｉｐｙ６−ｐｒｏｘｙｍｉｐｙ６−００（ｗｏｒｋｉｎｐｒｏｇｒｅｓｓ），Ｏｃｔｏｂｅｒ２００６．本明細書では［ｌ−Ｄ．ｓｇｕｎｄａｖｅ−ｍｉｐｖ６−ｐｒｏｘｙｍｉｐｖ６］と称する。２．Ｏｈｂａ，Ｙ．，"ＡＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａ−ＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＭＰＡ）"，ｄｒａｆｔ−ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｆｒａｍｅｗｏｒｋ−０３（ｗｏｒｋｉｎｐｒｏｇｒｅｓｓ），Ｏｃｔｏｂｅｒ２００６．本明細書では［Ｉ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｆｒａｍｅｗｏｒｋ］と称する。３．Ｏｈｂａ，Ｙ．，"Ｍｅｄｉａ−ＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＭＰＡ）ＩｍｐｌｅｍｅｎｔａｔｉｏｎＲｅｓｕｌｔｓ"，ｄｒａｆｔ−ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｉｍｐｌｅｍｅｎｔａｔｉｏｎ−０３（ｗｏｒｋｉｎｐｒｏｇｒｅｓｓ），Ｏｃｔｏｂｅｒ２００６．本明細書では［ｌ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｉｍｐｌｅｍｅｎｔａｔｉｏｎ］と称する。４．Ｋｅｍｐｆ，Ｊ．，"ＰｒｏｂｌｅｍＳｔａｔｅｍｅｎｔｆｏｒＩＰＬｏｃａｌＭｏｂｉｌｉｔｙ"，ｄｒａｆｔ−ｋｅｍｐｆ−ｎｅｔｌｍｍ−ｎｏｈｏｓｔ−ｐｓ−０１（ｗｏｒｋｉｎｐｒｏｇｒｅｓｓ），Ｊａｎｕａｒｙ２００６．本明細書では［ｌ−Ｄ．ｋｅｍｐｆ−ｎｅｔｌｍｍ−ｎｏｈｏｓｔ−ｐｓ］と称する。５．Ｋｅｍｐｆ，Ｊ．，"ＲｅｑｕｉｒｅｍｅｎｔｓａｎｄＧａｐＡｎａｌｙｓｉｓｆｏｒＩＰＬｏｃａｌＭｏｂｉｌｉｔｙ"，ｄｒａｆｔ−ｋｅｍｐｆ−ｎｅｔｌｍｍ−ｎｏｈｏｓｔ−ｒｅ［ａｌｐｈａ］−００（ｗｏｒｋｉｎｐｒｏｇｒｅｓｓ），Ｊｕｌｙ２００５．本明細書では［ｌ−Ｄ．ｋｅｍｐｆ−ｎｅｔｌｍｍ−ｎｏｈｏｓｔ−ｒｅｑ］と称する。６．Ｆｏｒｓｂｅｒｇ，Ｄ．，"ＰｒｏｔｏｃｏｌｆｏｒＣａｒｒｙｉｎｇＡｕｔｈｅｎｔｉｃａｔｉｏｎｆｏｒＮｅｔｗｏｒｋＡｃｃｅｓｓ（ＰＡＮＡ）"，ｄｒａｆｔ−ｉｅｔｆ−ｐａｎａ−ｐａｎａ−１３（ｗｏｒｋｉｎｐｒｏｇｒｅｓｓ），Ｄｅｃｅｍｂｅｒ２００６．本明細書では［Ｉ−Ｄ．ｉｅｔｆ−ｐａｎａ−ｐａｎａ］と称する。７． "ＤｒａｆｔＩＥＥＥＳｔａｎｄａｒｄｆｏｒＬｏｃａｌａｎｄＭｅｔｒｏｐｏｌｉｔａｎＡｒｅａＮｅｔｗｏｒｋｓ：ＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＨａｎｄｏｖｅｒＳｅｒｖｉｃｅｓ，ＩＥＥＥＰ８０２．２１／Ｄ０００．０４，" Ｆｅｂ２００７．本明細書では［８０２．２１］と称する。

本発明の好ましい実施形態は、前述及び他の背景技術を改良するものである。

本発明のこの好ましい実施形態では、ＰＭＩＰｖ６を対象とする高速ハンドオーバを提供するためのプロアクティブ機構について記載される。特に、該好ましい実施形態は、メディア独立事前認証（ＭＰＡ）技術を用いてＰＭＩＰｖ６のための高速ハンドオフをどのように実現することができるかについて記載される。ある実施形態では、ＰＭＩＰｖ６のためのドメイン内及びドメイン間ハンドオフの両方を含む異なるステップ中でＭＰＡ技術を用いることができる。前のローカルモビリティ（ＰＭＡ）ドメインにいる間、モバイルがアクセス認証を行うことができ、以前として前のネットワークにいる間にハンドオフ関連動作の多くを終えることができるように、ＭＰＡベースの高速ハンドオーバは事前認証機構を利用する。いくつかの実施形態によると、対応するローカルモビリティアンカー（ＬＭＡ／ＨＡ）を持つ少なくとも１つの局所モビリティ管理ドメイン内に位置し、プロキシモバイルエージェント（ＰＭＡ）を持つアクセスルータ間でのモバイルノードのＰＭＩＰｖ６環境におけるハンドオーバを最適化する方法は、第１のアクセスルータの第１のプロキシモバイルエージェント（ＰＭＡ）と第２のアクセスルータの第２のプロキシモバイルエージェント（ＰＭＡ）との間のモバイルノードの高速ハンドオフをサポートするメディア独立事前認証（ＭＰＡ）を用いることを含む。いくつかの実施例において、該方法はドメイン内ハンドオーバに関して、前記第１のプロキシモバイルエージェント及び前記第２のプロキシエージェントを同じドメインに配置させる。またいくつかの実施例において、該方法はドメイン間ハンドオーバに関して、前記第１のプロキシモバイルエージェント及び前記第２のプロキシエージェントを異なるドメインに配置させる。

いくつかの好ましい実施形態によると、対応するローカルモビリティアンカー（ＬＭＡ／ＨＡ）を持つ少なくとも１つの局所モビリティ管理ドメイン内に位置し、プロキシモバイルエージェント（ＰＭＡ）を持つアクセスルータ間でのモバイルノードのＰＭＩＰｖ６環境におけるハンドオーバを最適化するシステムは、クライアントＭＩＰｖ６を備え、第１のアクセスルータの第１のプロキシモバイルエージェント（ＰＭＡ）と第２のアクセスルータの第２のプロキシモバイルエージェント（ＰＭＡ）との間のモバイルノードの高速ハンドオフをサポートするメディア独立事前認証（ＭＰＡ）を行うように構成されたモバイルノードを具備する。

様々な実施形態の、上記の、及び／又は他の態様、特徴、及び／又は利点は、以下の説明を添付の図と併せて考察すれば、さらに理解される。様々な実施形態は、適用可能な場合には、異なる態様、特徴及び／又は利点を含めることも、除外することもできる。加えて、様々な実施形態は、適用可能な場合には、他の実施形態の１つ又は複数の態様又は特徴を組み合わせることもできる。特定の実施形態の態様、特徴及び／又は利点の説明は、他の実施形態又は特許請求の範囲を限定するものと解釈されるべきではない。

本発明の好ましい実施形態は、添付の図面において、限定ではない実施例によって示される。

図１は、ある具体的な実施例によりモバイル（ＭＮ）がｐＰＭＡ下のセルにおいてブートする初期ブートストラップのシナリオを示す図である。図２は、ある具体的な実施例によりモバイルが現在の接続ポイント（ｐＰｏＡ）から移動し始めるシナリオを示す図である。図３ａは、ある具体的な実施例により直接事前認証フェーズを示す図である。図３ｂは、ある具体的な実施例により間接事前認証フェーズを示す図である。図４（ａ）は、ある具体的な実施例によりｐＰＭＡとｎＰＭＡの間にプロアクティブで一時的なトンネルがどのように生成されるかの詳細手順を示す図である。図４（ｂ）は、ある具体的な実施例によりｐＰＭＡとｎＰＭＡの間にプロアクティブで一時的なトンネルがどのように生成されるかの詳細手順を示す図である。図５は、ある具体的な実施例によりｎＰＭＡがｎＰＭＡのソースアドレスでＨＡを更新し、ルータ広告において送信することができるホームプレフィックスを得る、プロキシバインディング更新に関連した機構を示す図である。図６は、ある具体的な実施例によるＨＡとｎＰＭＡの間のトンネル生成を示す図である。図７は、ある具体的な実施例によるトンネル削除手順を示す図である。図８は、ある具体的な実施例による初期のブートストラッピング状態を示す図である。図９は、ある具体的な実施例による、ｐＰｏＡから移動するモバイルノードを表す図である。図１０は、ある具体的な実施例による直接事前認証を示す図である。図１１は、ある具体的な実施例による間接事前認証を示す図である。図１２（ａ）は、ある具体的な実施例によるトンネルの片側の生成を示す図である。図１２（ｂ）は、ある具体的な実施例によるトンネルの両側の生成を示す図である。図１３（ａ）は、ある具体的な実施例によるｎＨＡへのプロキシバインディング更新を示す図である。図１３（ｂ）は、ある具体的な実施例によるｐＨＡへのプロキシバインディング更新を示す図である。図１４は、ある具体的な実施例による、ｎＨｏＡについてのｐＨＡへのバインディング更新を送信するモバイルノードを示す図である。図１５は、ある具体的な実施例により、対応ノードからモバイルノードまでのトンネルを用いるデータの流れを示す図である。図１６は、ある具体的な実施例によるｐＰＭＡとｎＰＭＡの間のトンネル削除を示す図である。図１７は、ある具体的な実施例による、新規ドメインにおけるデータの流れを示す図である。図１８は、ある具体的な実施例による、実例となるＭＰＡシナリオを示す図である。図１９は、ある具体的な実施例におけるデバイスコンポーネントを示す、実例となるアーキテクチャの図である。図２０は、ある具体的な実施例におけるデバイスコンポーネントを示す、実例となるアーキテクチャの図である。

本発明は、多くの異なる形態で実施できるが、本明細書では、本開示が、本発明の原理の例を提供するものとみなされるべきであり、かかる例は、本発明を、本明細書で説明し、及び／又は本明細書で図示する好ましい実施形態だけに限定するためのものではないという了解の下で、いくつかの例示的実施形態について説明する。

イントロダクション：
ローカルモビリティ管理の目的は、ｎｏ−ｈｏｓｔ−ｒｅｑｕｉｒｅｍｅｎｔｄｒａｆｔにおいて十分に文書化されている。例えばＪ．ＫｅｍｐｆによるＩ．Ｅ．Ｔ．Ｆ．インターネットドラフト「ＧｏａｌｓｆｏｒＮｅｔｗｏｒｋ−ｂａｓｅｄＬｏｃａｌｉｚｅｄＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔ（ＮＥＴＬＭＭ），Ｄｏｃｕｍｅｎｔ：ｄｒａｆｔ−ｉｅｔｆ−ｎｅｔｌｍｍ−ｎｏｈｏｓｔ−ｒｅｑ−０２．ｔｘｔ，Ｊｕｎｅ，２００６」を参照されたい。これは、優先の暫定出願の一部として、本明細書に組込まれる。背景を補足するために、次の参考文献（１）ＡＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅａｕｔｈｅｎｔｉｃａｔｉｏｎと題して２００６年２月２日に提出された米国特許出願第１１／３０７，３６２号、（２）ＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−Ａｕｔｈｅｎｔｉｃａｔｉｏｎ（ＳｕｐｐｏｒｔｆｏｒＰＡＮＡ）と題して２００６年３月９日に提出された米国特許出願第１１／３０８，１７５号、（３）ＦｒａｍｅｗｏｒｋｏｆＭｅｄｉａＩｎｄｅｐｅｎｄｅｎｔＰｒｅ−ＡｕｔｈｅｎｔｉｃａｔｉｏｎＩｍｐｒｏｖｅｍｅｎｔｓ：ＩｎｃｌｕｄｉｎｇＣｏｎｓｉｄｅｒａｔｉｏｎｓｆｏｒＦａｉｌｅｄＳｗｉｔｃｈｉｎｇａｎｄＳｗｉｔｃｈｂａｃｋと題して２００６年４月１４日に提出された米国特許出願第１１／２７９，８５６号の全開示が、参照することにより本明細書に組み込まれる。

ローカルモビリティ管理の１つの利点は、モビリティに関する機能の多くを最適化し、エア上のシグナリングメッセージの数を減らすことである。ネットワーク局所モビリティ管理のパラダイムにおいて、あるＭＡＧから別のＭＡＧまでモバイルが移動し、その移動が１つのＬＭＡ内において限定的である場合、以下の動作が行われなければならない。それは、大まかには、レイヤ２移動、新規リンクの検出（ＤＮＡ）、ルータ懇請（ＲＳ）、アクセス認証、プロファイル照合、プロキシバインディング更新及びアドレス再構成のような幾つかのステップに分類することができる。これは、ドメイン間の場合についてモバイルが２つのＬＭＡ間を移動することができるようにパラダイムを拡張するものである。この文献において、ＬＭＡという用語は、ＨＡに置き換えられ、ＭＡＧはＰＭＡに置き換えられる。

ここで、ネットワークローカル移動時に関与するステップのうちのいくつかを詳細に説明する。

１）ハンドオーバ及び再認証に必要なリンクレイヤシグナリング。例えば８０２．１１では、これは、ＥＡＰを用いる８０２．１ｘ再認証を伴うＲｅＡｓｓｏｃｉａｔｅメッセージである。

２）ルータ到達可能性を含むアクティブなＩＰレベル移動検出：ＤＮＡ（ネットワーク接続検出）プロトコルは、この目的でルータ懇請／ルータ広告を用いる。更に、ＳＥＮＤが用いられるとともにモバイルノードがルータに関してキャッシュされた証明書を持たない場合、モバイルノードは、認可経路を得るために、認可経路懇請／認可経路広告を用いなければならない。

３）移動検出が完了すると、モバイルはＭＡＧからのプレフィックス広告に基いてＩＰアドレスを構成する必要がある。しかし、プレフィックスが古いプレフィックスと同じである場合、同ＩＰアドレスで構成されることになる。

４）しかし、該モバイルは、新規の接続ポイントにおいて再認証のプロセスを受ける。再認証の完了の後、ＭＡＧ（ＰＭＡ）とＬＭＡ（ＨＡ）の間のトンネルの確立が始動される。したがって、モバイルノードを宛先とするあらゆるトラフィックは、トンネル上で送信され、モバイルに送達される。

この移動がドメイン間移動まで延びると、ＰＭＡ（ＭＡＧ）は２つの異なるＬＭＡに属するであろう。それぞれのＬＭＡもまたｐＰＭＡ及びｎＰＭＡと称することができる。

高速ハンドオフの動機：
少なくともＰＭＩＰｄｒａｆｔ［ｌ−Ｄ．ｓｇｕｎｄａｖｅ−ｍｉｐｖ６−ｐｒｏｘｙｍｉｐｖ６］の現行バージョンから、ＰＭＩＰドメイン内を移動中のモバイル（あるＰＭＡリンクから別のＰＭＡリンクまで移動する場合）は、たとえ該新規のリンクにおいてＩＰアドレスを変更しない場合であってもＩＰアドレス構成プロセスを経験すると思われる。したがって、例えばステートレスな自動構成モードに関しては、たとえ生成された新たなアドレスが古いＰＭＡリンクで持っていたアドレスと同じであっても、ネットワーク接続検出（ＤＮＡ）時にルータ懇請（ＲＳ）を送信すること（リンク変更の場合）、ルータ（ＰＭＡ）からホームプレフィックスを得ること、（リンクレイヤアドレスにプレフィックスをアペンドすることにより）アドレスを構成するといったことが必須である。したがって、それは、アドレス構成プロセスを再開始することとほぼ同様である。更に、ＬＭＡがプロキシバインディング更新を完了し、かつＰＭＡとＨＡの間のトンネルをセットアップするためには、ある程度の時間がかかる。したがって、たとえグローバルモビリティプロトコルと比較してハンドオフ遅延が減らされ、無線リンク上のシグナリング交換がより少ないとしても、プロセスに関与する他のコンポーネントによるかなりの量の遅延が依然としてある。これらのコンポーネントは、アクセス認証、プロファイル照合、ホームアドレス再構成及びバインディング更新を含む。ドメイン間の場合、各ドメインに２つのホームエージェントが必要であり、ホームプレフィックス広告は各ドメインにおいて異なることから、事態はより複雑であり、より多くの時間が必要であると思われる。

本明細書の好ましい実施形態は、ドメイン内及びドメイン間の場合の両方についてメディア独立事前認証技術を適用することによって、アクセス認証、トンネルセットアップ、バインディング更新及びメディア転送に起因する遅延を減らすものである。

本明細書で説明したように、メディア独立事前認証技術（上記参考文献［Ｉ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｆｒａｍｅｗｏｒｋ］を参照）は、ＰＭＩＰｖ６のためのプロアクティブな高速ハンドオフ技術を提供することもできる。ＭＰＡフレームワークを用いた結果のいくつかは上記言及した参考文献［Ｉ−Ｄ．ｏｈｂａ−ｍｏｂｏｐｔｓ−ｍｐａ−ｉｍｐｌｅｍｅｎｔａｔｉｏｎ］中に見出すことができる。

Ｐｍｉｐｖ６（プロキシモバイルＩｐｖ６）のためのＭＰＡ支援高速ハンドオフの詳細：
本願は、モバイルがＰｒｏｘｙＭｌｐハンドオフをしなければならない場合に、ドメイン内及びドメイン間ハンドオフ遅延の両方を減らす機構を提供し、これによりパケット損失も同様に減らすものである。両方のハンドオフの場合に使われる機構をカバーする。ドメイン内の場合、モバイルは、同じＬＭＡ下のＰＭＡ間を移動する。したがって、両方のＰＭＡは、それらのルータ広告の一部と同じホームプレフィックスを送信する。

ドメイン間の場合ではＬＭＡが異なる。したがって、各ＬＭＡに属するＰＭＡの各々はルータ広告の一部とは異なるプレフィックスを送信する。両方の場合についてハンドオフの高速化をＭＰＡがどのようにして支援することができるかについて詳細に説明する。

Ｉ．ドメイン内移動：
本項では、移動がドメイン内に限定される場合について、高速ハンドオフをサポートし、これによりパケット損失を減らすために必要なＭＰＡ手順を説明する。

初期状態（例えばブートストラッピング状態）：
図１は、ｐＰＭＡ下のセルにおいてモバイル（ＭＮ）がブートする初期ブートストラッピングシナリオを示す。この場合、ｐＰＭＡとｎＰＭＡの両方は、ＨＡ（ホームエージェント）である同じＬＭＡ下にいる。モバイルは、ｐＰｏＡに接続される場合、該モバイルに関係する他のプロファイル及びＮＡＩをｐＰＭＡに送信することにより、アクセス認証手順を完了する。この場合、ｐＰＭＡは、実際にアクセスルータＰＡＲと共存する。また、第一ホップのアクセスルータは、ＰＡＡ（ＰＡＮＡ認証エージェント）（例えば上記参考文献［ｌ−Ｄ．ｉｅｔｆ−ｐａｎａ−ｐａｎａ］参照）のようなレイヤ３認証エージェントを備えているものとする。

初期アクセス認証の一部として、モバイルは、ローカルネットワーク内のＰＡＡ及びＡＡＡサーバと通信することによってＥＡＰを行うことができる。初期認証が終った後、ＰＭＡは該モバイル用のホームプレフィックスを得て、それをルータ広告の一部として送信する。モバイルは、ホームプレフィックスを得た後、ホームアドレスＨｏＡによってそれ自体を構成し、デフォルトルータがＰＭＡであるとして構成する。この時点でＰＭＡはＨＡへのプロキシバインディング更新をモバイルに代って送信する。バインディング更新手順が完了した後、ｐＰＭＡとＨＡの間にトンネルが生成される。該モバイルを宛先とする任意のホストからのデータは、ＨＡによってインターセプトされ、該ＨＡはｐＰＭＡにこのデータを送信する。このデータはカレントのＩＰアドレッシングスキームを持つ。外側トンネルはソースアドレスＨＡ及びデスティネーションアドレスｐＰＭＡを持つであろう。内側のデータはソースアドレスＡＮＹ及び内部アドレスＨｏＡを持つであろう。ｐＰＭＡは、ひとたびこのデータを得ると、外部ヘッダーを取り除き、内部データをモバイルに送達する。

ここで、データ配送経路を以下のように示すことができる。

データパケット，ＡＮＹ−＞ＨｏＡ；
ＰＭＩＰトンネル，外側ＨＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ＨｏＡ
モバイル移動開始（モバイルは移動しようとしている）：
図２は、モバイルが現在の接続ポイント（ｐＰｏＡ）から移動し始めるシナリオを示す。モバイルは、ｐＰｏＡから移動しようとする場合、事前認証プロセスを準備する。モバイルは、現在の接続ポイントから移動することを判定するためにどのような技術を用いてもよい。例えば、モバイルは、移動しようとしていることの判定にＩＥＥＥ８０２．２１ベースのイベントサービスコマンドを用いることができる（例えば上記参考文献［８０２．２１］参照）。

ステップ１（事前認証段階）：
事前認証フェーズ中に、モバイルは、依然として前のネットワークにいる場合であっても、レイヤ３及びレイヤ２認証を完了することができ、これにより事前認証による時間を削減することができる。基本的には、直接認証及び間接認証のような２つの型の認証がある。直接認証の場合、モバイルはｎＰＭＡと直接通信することができ、間接認証の場合、ｐＰＭＡはプロキシのように振る舞う。直接事前認証及び間接事前認証の両方の場合について説明する。

オプション１：直接事前認証：図３ａは直接事前認証フェーズを示す。この事前認証はレイヤ３事前認証である。レイヤ３事前認証であるがレイヤ２事前認証を始めることもできる。ＩＥＥＥ８０２．２１ベースの情報サービス（例えば上記参考文献［８０２．２１］参照）のような何らかの発見プロセスを通じて、モバイルは、次アクセスネットワークにおけるネットワーク要素の詳細を発見する。特に、アクセスルータのＭＡＣアドレス、ＩＰアドレスのような関連情報を得る。ｎＰＭＡ及びｎＰＡＡはＮＡＲと共存するので、モバイルはＰＭＡ及びＰＡＡのアドレスも同様に得る。モバイルがｎＰＡＡとの事前認証プロセスを始めると、ｎＰＭＡはモバイルのプロファイルをチェックし終え、前もってＨＡからモバイルのホームプレフィックスを得る。ｎＰＭＡはＭＮのプロファイルを得て事前認証（ｐｒｅ−ａｕｔｈ）状態を了解する。ｎＰＭＡは、任意に、バックエンドサーバとしてＡＡＡサーバと通信し得る。事前認証のプロセス中に、ｐＰＭＡとｎＰＭＡの間にトンネルが生成される。望ましいトンネルを生成することができるように、ｐＰＭＡとｎＰＭＡの両方は互いのエンドポイントを知る必要がある。事前認証（ｐｒｅ−ａｕｔｈ）パケットはＰＭＡ間のトンネルを生成するために用いられるｐＰＭＡアドレスを有する。

オプション２：間接事前認証：図３ｂは間接事前認証を示す。間接事前認証の場合、ｐＰＭＡは通り道として関与し、事前認証プロキシのように振舞う。この場合、ｎＰＡＡはｎＰＭＡと共同配置される。事前認証フェーズ中に、ｎＰＭＡはモバイルのプロファイルを得て、次にＨＡから広告するために使用することができるプレフィックスを受信する。事前認証（ｐｒｅ−ａｕｔｈ）シグナリングはトンネルを生成するために用いることができる。

データパケットＡＮＹ−＞ＨｏＡ；
ＰＭＩＰトンネル−外側ＨＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ＨｏＡ
ｐＰＭＡとｎＰＭＡの間のプロアクティブなトンネル生成の詳細：
参考のために、図４（ａ）及び４（ｂ）はトンネル生成メッセージングを示す。特に、ＦＩＧＳ．４（ａ）及び４（ｂ）は、ｐＰＭＡとｎＰＭＡの間にプロアクティブで一時的なトンネルがどのように生成されるかについて詳細な手順を示す。事前認証フェーズ中に、ｐＰＭＡとｎＰＭＡは互いのＩＰアドレスを知るようになり、これによりトンネルをセットアップすることができる。

ここで、プロアクティブなハンドオーバトンネルの詳細は以下を含む。

プロアクティブなＨＯトンネル：外側ｎＰＭＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ＨｏＡ
プロキシバインディング更新：
トンネルが認証フェーズ中にｐＰＭＡとｎＰＭＡの間に生成された後、ｎＰＭＡはモバイルに代ってプロキシバインディング更新を送信する。図５は、ｎＰＭＡがｎＰＭＡのソースアドレスでＨＡを更新し、ルータ広告で送信することができるホームプレフィックスを得る、プロキシバインディング更新に関連する機構を示す。プロキシバインディング更新中に、データは常にｐＰＭＡを介して流れる。

データパケット：ＡＮＹ−＞ＨｏＡ；
プロアクティブなＨＯトンネル：外側ｎＰＭＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ＨｏＡ
ｎＰＭＡとＨＡの間のトンネル生成：
モバイルに代ってプロキシバインディング更新がｎＰＭＡからＨＡに送信された後、別のトンネルがＨＡとｐＰＭＡの間に生成される。図６はこの手順を示す。しかし、このトンネルが生成されている間、データは常にｐＰＭＡを介して流れる。したがって、このトンネル生成中のデータ損失は回避される。しかし、トンネルが生成された後は、新規のデータは、ＨＡとｎＰＭＡの間、ｎＰＭＡとｐＰＭＡの間に生成された２本のトンネルによってｐＰｏＡにフォワードされることになる。

ここで、データ配送を以下のように示すことができる。

データパケット：ＡＮＹ−＞ＨｏＡ；
ＰＭＩＰトンネル：外側ＨＡ−＞ｎＰＭＡ，内側ＡＮＹ−＞ＨｏＡ；
プロアクティブなＨＯトンネル：外側ｎＰＭＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ＨｏＡ
移動前のプロアクティブトンネルの削除：
モバイルがｎＰｏＡである場合、ｐＰＭＡとｎＰＭＡの間のトンネルがそこにあってはならないので、ｎＰｏＡに移動する直前に、このトンネルは該モバイルによって削除されるべきである。図７はちょうどモバイルが新規のＰｏＡに移動する前に、トンネルがどのように削除されるかを示す。場合によっては、ピンポン効果を回避するためにトンネルを維持することが望ましい。データの軌道は以下のように見える。ここで、データ配送経路を以下のように示すことができる。

データパケット：ＡＮＹ−＞ＨｏＡ；
ＰＭＩＰトンネル：外側（ＨＡ−＞ｎＰＭＡ），内側（ＡＮＹ−＞ＨｏＡ）；
プロアクティブなＨＯトンネル：外側（ｎＰＭＡ−＞ｐＰＭＡ），内側（ＡＮＹ−＞ＨｏＡ）
ＭＮがＮｐｏａに移動（新しいネットワークに移動）：
ある境界では、モバイルは、最終的にｎＰｏＡに移動する。ＮＡＲからのＲＡに基いて、モバイルは、新しいネットワークにいることを認識し、そのデフォルトルータを変更する。しかし、事前認証とバインディング更新が既に前もって処理されているので、モバイルは、アクセス認証（レイヤ２及びレイヤ３）のプロセスを再度受ける必要はない。これは、実効ハンドオフ時間ひいてはパケット損失を減らす。一旦モバイルがすでにｎＰＭＡ内にいることをＨＡが検知すれば、ｐＰＭＡとＨＡの間のトンネルをいつも削除することができる。

データパケット，（ＡＮＹ−＞ＨｏＡ）；
ＰＭＩＰトンネル，外側（ＨＡ−＞ｎＰＭＡ），内側（ＡＮＹ−＞ＨｏＡ）
ＩＩ．ドメイン間移動（ドメイン間ハンドオフ）：
本項では、２つの異なるドメインにｐＰＭＡとｎＰＭＡがいる場合の、モバイルのドメイン間移動を定義する。ＰＭＡ（ＭＡＧ）の各々について設計された異なるＬＭＡ（ＨＡ）が存在する。したがって、ｐＰＭＡとｎＰＭＡはそれらのルータ広告の一部として異なるホームプレフィックスを送信する。この状況においてモバイルが２つのＰＭＡ間を移動するときに、該モバイルは新規のＨｏＡに対して構成しようとする。これをどのように処理するかについては２つのケースがあり得る。ある状況では、ＭＮがＣＭＩＰを備えており、別のケースではＭＮがＣＭＩＰを備えない。ＭＮがＣＭＩＰを備えていない場合、ｎＰＭＡはＭＮに代ってバインド更新を送信する。しかし、この場合、ｎＰＭＡとｐＨＡの間にトンネルは存在しない。

初期状態（ブートストラッピング状態）：
ドメイン間の場合の初期状態はドメイン内の場合の初期状態と同じである。ｐＨＡとｎＨＡの間にトンネルが前もって作られてもよい。図に示されるように、ｐＰＭＡはｐＨＡ下にいる。またｎＰＭＡはｎＨＡ下にいる。前もって、又はオンデマンドで、ｐＨＡとｎＨＡの間にトンネルが形成されてもよい。トンネルを生成することができるために、２つのネットワークプロバイダー間にサービス同意があるものと仮定する。参考のために、図８は、初期ブートストラッピングの状態を示す。ここで、データ配送経路を以下のように示すことができる。

データパケット：ＡＮＹ−＞ｐＨｏＡ；
ＰＭＩＰトンネル：外側ＨＡ−＞ｎＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ
ＭＮがネットワークを出ることを検知する：（ＭＮは移動しようとしている）：
図９は、ある境界に基いてモバイルがネットワークを出ようとしている場合を示す。しかしこの時点で、データは常にｐＨＡを介して流れる。

モバイルがある境界に基づいてネットワークを出ようとするとき、事前認証フェーズを始める。しかし、データは、この時点で常にｐＨＡを介して流れる。

ここで、データ経路を以下のように示すことができる。

データパケット：ＡＮＹ−＞ｐＨｏＡ；
ＰＭＩＰトンネル：外側ＨＡ−＞ｎＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ
事前認証状態（事前認証フェーズ）：
この状態において、ＭＮは事前認証段階を始める。ドメイン内の場合と同様、２つの型の可能な認証、すなわち直接認証及び間接認証がある。この認証はレイヤ３認証であるが、レイヤ３認証はレイヤ２認証をブートストラップすることもできる。ＰＡＡは各ドメインにおけるＰＭＡにコロケートされる。この段階におけるデータフローの経路は以下のとおりである。

データパケット，ＡＮＹ−＞ｐＨｏＡ；
ＰＭＩＰトンネル，外側（ＨＡ−＞ｎＰＭＡ），内側（ＡＮＹ−＞ｐＨｏＡ）；
Ｈａ間のトンネルにおけるデータ経路：外側（ｐＨＡ−＞ｎＨＡ），内側（ＡＮＹ−＞ｐＨｏＡ）
事前認証の一部として、ｎＰＭＡはＭＮのプロファイルを得て、事前認証（ｐｒｅ−ａｕｔｈ）状態であることが分かり、新しいネットワークに対するものであることを意味するプレフィックスを得る。

直接事前認証：
図１０は、直接事前認証による呼び出しフローを示す。

このセクションは、ドメイン間の場合についての直接事前認証を説明する。ドメイン間の場合の直接事前認証は、ドメイン内の場合に極めて似ており、ｐＰＭＡがパススルーのように振る舞う。

間接事前認証：
図１１は間接事前認証を示す。

本項は、ドメイン間の場合の間接認証を説明する。ドメイン間の場合の間接認証は、ドメイン内の場合の間接事前認証に極めて似ている。この場合、ｐＰＭＡが認証プロセスに関与する。

ｐＰＭＡとｎＰＭＡの間のトンネル生成（プロアクティブなトンネル生成）：
この項は、ｐＰＭＡとｎＰＭＡの間のトンネル生成について説明する。このシナリオでは、事前認証の一部としてｎＰＭＡはｐＰＭＡとのトンネルを生成する。ＣＮ−＞ＭＮのデータの流れは常に同じままである。

参考のために、図１２は、ｎＰＭＡとｐＰＭＡの間のトンネル生成を示す図であって、図１２（ａ）はトンネルの片側の生成を示し、図１２（ｂ）はトンネルの両側の生成を示す。

データパケット：ＡＮＹ−＞ｐＨｏＡ；
ＰＭＩＰトンネル：外側ｐＨＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ
プロキシバインディング更新（プロアクティブなプロキシバインディング更新）：
モバイルが常に前のネットワークにいる場合、プロキシバインディング更新が行われる。図１３はプロキシバインディング更新段階（例えばｐＨＡ及びｎＨＡの両方へのプロキシバインディング更新）を示す。ｎＰＭＡはｎＨＡへのプロキシバインディング更新を送信する。また、ｎＨＡはプロキシバインディング応答を送信する。ｎＰＭＡは、そのアドレスをプロキシバインディング更新の一部としてｎＨＡに送信する（ｎＨｏＡ：ｎＰＭＡ）。ｎＰＭＡは、ｐＨｏＡへのｎＨＡバインディングのアドレスとともにｐＨＡへのバインディング更新を送信する（ｐＨｏＡ：ｎＨｏＡ）。このフェーズの一部として、ｎＨＡとｎＰＭＡの間にトンネルが生成される。ｐＨｏＡを宛先とする、あらゆるトラフィックは、ｐＨＡによってまずインターセプトされ、ｎＨＡにフォワードされ、ｎＨＡ−ｎＰＭＡトンネルを用いて最終的にｎＰＭＡに達する。ＰＭＡの場合には、このトラフィックはｐＰＭＡｎＰＭＡトンネルを用いてもとのモバイルにトンネリングされる。

図のように、図１３（ａ）及び１３（ｂ）はｐＨＡ及びｎＨＡの両方へのプロキシバインディング更新を示す。

特に、図１３（ａ）はｎＨＡへのプロキシバインディング更新を示し、図１３（ｂ）はｐＨＡへのプロキシバインディング更新を示す。これらは同時に又は順々に行われ得る。ｎＨＡへのプロキシバインディング更新が完了すると、ｎＰＭＡとｎＨＡの間のトンネルがすみやかにセットアップされる。ｐＨＡへのプロキシバインディング更新は、ｐＨＡにおけるｎＨＡへのフォワーディングテーブルをセットアップする。ｎＰＭＡがｐＨＡを更新することができるように、ｎＰＭＡとｐＨＡの間には、ある種のセキュリティアソシエーションがあるものとする。

あるいは、モバイルは、新規のＨＡのプレフィックスを既に持っていることから、ｎＨｏＡについて更新信号をｐＨＡに直接送信することができる。図１４はＭＮがｎＨｏＡについてｐＨＡにバインディング更新を送信するシナリオを示す。しかしこの場合、モバイルはクライアントＭＩＰｖ６を備えている必要がある。このクライアントは、ドメイン間ローミングを支援する目的でｃＭＩＰｖ６を備えているであろうことを想定する。ＣＭＩＰの場合、モバイルはｐＰＭＡ又はｎＰＭＡのいずれかを介してバインディング更新を送信することができる。

モバイルがｐＰｏＡにいる場合のデータの流れ：
ひとたびｐＨＡとｎＨＡが適切に更新され、ｎＨＡとｎＭＰＡの間及びｐＰＭＡとｎＰＭＡの間にトンネルがセットアップされると、モバイルが前のネットワークにいる場合、以下のようにしてデータがＣＮからＭＮに流れ始める。データは、ｎＨＡとｎＰＭＡ上を送られるのではなく、ｎＨＡとｎＰＭＡを介して送られるので、回り道をする。ｐＨＡは、ＣＮからｐＨＡへのパケットをトンネルを用いてフォワードするので、ｐＨＡは、ｐＨｏＡを宛先とするパケットをｎＰＭＡにフォワードする。データトラフィックは、プロアクティブなハンドオーバトンネルを用いてｐＰＭＡにフォワードされる。

ここで、データ経路を以下のように示すことができる。

データパケット：ＡＮＹ−＞ｐＨｏＡ；
Ｈａ間のトンネル：外側ｐＨＡ−＞ｎＨＡ，内側ＡＮＹ−＞ｐＨｏＡ；
ｎＰＭＩＰトンネル：外側ｎＨＡ−＞ｎＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ，ｎＨｏＡ；
プロアクティブなＨＯトンネル：外側ｎＰＭＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ，ｎＨｏＡ
ｐＰＭＡとｎＰＭＡの間のトンネル削除：
ある境界では、モバイルは、そのレイヤ２接続ポイントを変更して新しいネットワークに移動することを決定する。該モバイルは、移動する直前に、ドメイン内の場合と全く同様にｎＰＭＡとｐＰＭＡの間のトンネルを削除して新しいネットワークに到着(lands up)する。トンネル削除中の一時的なトラフィックについては、アクセスルータでバッファリングエージェントを展開することにより、これまでどおり対処することができる。図１６は、モバイルが新規のＰｏＡに移動する直前のｐＰＭＡとｎＰＭＡの間のトンネル削除を示す。

データパケット：ＡＮＹ−＞ｐＨｏＡ；
ＨＡの間のトンネル：外側ｐＨＡ−＞ｎＨＡ，内側ＡＮＹ−＞ｐＨｏＡ；
ｎＰＭＩＰトンネル：外側ｎＨＡ−＞ｎＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ，ｎＨｏＡ；
プロアクティブなＨＯトンネル：外側ｎＰＭＡ−＞ｐＰＭＡ，内側ＡＮＹ−＞ｐＨｏＡ，ｎＨｏＡ
新しいネットワークにおけるデータの流れ（新しいネットワークへの移動）：
モバイルが新しいネットワークに移動すると、該モバイルは、ＭＡＣアドレス及びデフォルトルータＮＡＲを学習するための（ルータ懇請）を送信するＤＮＡプロセスを経る必要はない。ＭＡＣアドレス及びＮＡＲのＩＰアドレスを既に持っていることから、該モバイルはｎＰＭＡからのトラフィックをすぐに受信し始めることができる。トンネルは削除されているので、このトラフィックはｐＰＭＡにはフォワードされない。トンネル削除中の一時的なトラフィックは、エッジルータでバッファすることができる。図１７は、モバイルが新しいネットワークに移動した後のデータ経路を示す。

ここで、データ経路を以下のように示すことができる。

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

Claims

対応するローカルモビリティアンカー（ＬＭＡ／ＨＡ）を持つ少なくとも１つの局所モビリティ管理ドメイン内に位置し、プロキシモバイルエージェント（ＰＭＡ）を持つアクセスルータ間でのモバイルノードのＰＭＩＰｖ６環境におけるハンドオーバを最適化する方法であって、
第１のアクセスルータの第１のプロキシモバイルエージェント（ＰＭＡ）と第２のアクセスルータの第２のプロキシモバイルエージェント（ＰＭＡ）との間のモバイルノードの高速ハンドオフをサポートするメディア独立事前認証（ＭＰＡ）を用いることを含む方法。
ドメイン内ハンドオーバに関して、前記第１のプロキシモバイルエージェント及び前記第２のプロキシエージェントを同じドメインに配置させることをさらに含む請求項１の方法。
ドメイン間ハンドオーバに関して、前記第１のプロキシモバイルエージェント及び前記第２のプロキシエージェントを異なるドメインに配置させることをさらに含む請求項１の方法。
初期アクセス認証の一部として、前記モバイルノードは、ローカルネットワーク内のレイヤ３認証エージェント及びＡＡＡサーバと通信することによりＥＡＰを行う請求項１の方法。
前記モバイルノードが前記第１のＰＭＡとの現在の接続ポイントから移動し始める場合、前記モバイルノードが依然として前記第１のＰＭＡの第１のネットワークにいる間に該モバイルノードが認証を完了し、これによりハンドオーバ時間を削減する事前認証フェーズを行う請求項１の方法。
前記モバイルノードは、前記第２のＰＭＡと直接通信する直接認証を行う請求項５の方法。
前記モバイルノードがパススルーとして前記第１のＰＭＡを介して通信し、プロキシとして振る舞う間接認証を行う請求項５の方法。
前記モバイルノードは、前記第１のＰＭＡのネットワークのネットワーク要素を先ず発見し、該ネットワーク要素は前記第２のＰＭＡのアクセスルータのＩＰアドレスを含む請求項５の方法。
事前認証中に、前記第１及び第２のＰＭＡが互いのＩＰアドレスを学習し、前記第１のＰＭＡと前記第２のＰＭＡの間にトンネルが生成される請求項５の方法。
前記認証フェーズ中に前記第１のＰＭＡと前記第２のＰＭＡの間に前記トンネルが生成された後、前記第２のＰＭＡは前記モバイルに代ってＬＭＡ／ＨＡへのプロキシバインディング更新を送信する請求項９の方法。
前記第２のＰＭＡが前記ＬＭＡ／ＨＡへのプロキシバインディング更新を送信した後、前記ＬＭＡ／ＨＡと前記第２のＰＭＡの間に別のトンネルが生成される請求項１０の方法。
前記モバイルは、前記第２のＰＭＡに移動する場合に、前記第１のＰＭＡと前記第２のＰＭＡの間のトンネルを削除する請求項１１の方法。
前記モバイルノードが前記第２のＰＭＡに移動する場合に、前記モバイルノードはそのデフォルトルータを変更するが、事前認証及びバインディング更新が行われていることを理由に、該モバイルはアクセス認証を経ない請求項１２の方法。
前記第１のＰＭＡは第１のＬＭＡ／ＨＡを持ち、前記第２のＰＭＡは異なる第２のＬＭＡ／ＨＡを持ち、それらのルータ広告の一部として異なるホームプレフィックスを送信する請求項３の方法。
前記第２のＰＭＡが前記第２のＬＭＡ／ＨＡへのプロキシバインディング更新を送信した後、前記第２のＬＭＡ／ＨＡと前記第２のＰＭＡの間にトンネルが生成される請求項１４の方法。
プロキシバインディング更新が前記第１のＬＭＡ／ＨＡに送信され、前記第１のＬＭＡ／ＨＡと前記第１のＰＭＡの間にトンネルが生成される請求項１４の方法。
前記モバイルノードは前記第１のＬＭＡ／ＨＡにバインディング更新を送信する請求項１４の方法。
前記モバイルノードはクライアントＭｌＰｖ６を備える請求項１７の方法。
対応するローカルモビリティアンカー（ＬＭＡ／ＨＡ）を持つ少なくとも１つの局所モビリティ管理ドメイン内に位置し、プロキシモバイルエージェント（ＰＭＡ）を持つアクセスルータ間でのモバイルノードのＰＭＩＰｖ６環境におけるハンドオーバを最適化するシステムであって、
クライアントＭＩＰｖ６を備え、第１のアクセスルータの第１のプロキシモバイルエージェント（ＰＭＡ）と第２のアクセスルータの第２のプロキシモバイルエージェント（ＰＭＡ）との間のモバイルノードの高速ハンドオフをサポートするメディア独立事前認証（ＭＰＡ）を行うように構成されたモバイルノードを具備するシステム。