JP5404791B2 - モバイルノードをホームエージェントに登録するための方法及びフォーリンエージェントグループ - Google Patents

Description

本発明はＩＰｖ４の分野に関し、特にＩＰｖ４におけるシームレスなネットワーク層ハンドオーバーを達成することに関する。

インターネットの普及と移動体通信の開発により、ユーザはますます、いつでもどこでもインターネットにアクセスできなければならず、そのため、移動体インターネットアクセスの提供がインターネット技術の研究のホットスポットの１つとなっている。モバイルＩＰは、元のＩＰプロトコル毎に与えられたノードの移動をサポートする解決手段であり、人々がノートブックコンピュータ、ＰＤＡ（パーソナル・デジタル・アシスタント）等の端末を介して、彼／彼女が、例えば、家、電車又は飛行機等、どこにいようとも、いつでもインターネットに接続できることを可能とする。ユーザ端末の位置の移動について、どこに移動体デバイスが実際に位置しているかにかかわらず、ユーザ端末のＩＰアドレスは不変であることが重要である。従って、他のデバイスがこのＩＰアドレスによってユーザ端末にアクセスできることが可能となり、結果として移動中の通信の連続性を維持する。従って、モバイルＩＰはユーザによるインターネットへの自由なアクセスを実現する。

図１に示すように、ＩＰｖ４ベースのモバイルＩＰは３つの機能的エンティティ：モバイルノードＭＮ、ホームエージェントＨＡ及びフォーリンエージェント（Foreign Agent）ＦＡを規定する。モバイルノードＭＮは、ノートブックコンピュータ、ＰＤＡ、携帯電話等のような移動によってそのネットワーク接続点を変更し得る移動体端末である。ＭＮはホームアドレスＨｏＡをそのホームネットワークに有し、他の固定されたホストのアドレスとして固定されたホームアドレスＨｏＡはホームネットワークＨＮによって与えられる。移動したモバイルノードについて、その現在の接続点がどこにあるかにかかわらず、ネットワーク内の他のデバイスの視点からはモバイルノードは未だにホームネットワークに接続されているように見える。ホームエージェントはモバイルノードのホームネットワーク内に位置するノードであり、通常はルータである。モバイルノードがホームネットワークから離れ、外部ネットワークに入ると、それは自身の取得したケア・オブ・アドレス（care-of address）をホームエージェントに登録する。ホームエージェントはモバイルノードの現在位置情報を保持し、モバイルノードのホームアドレスに宛てられたデータパケットを抜き取ると、そのデータパケットをモバイルノードにトンネリングする。モバイルノードが外部ネットワークＦＮに移動すると、外部ネットワークにおいてフォーリンエージェントＦＡはホストとなり、通常、それは、モバイルノードにルーティングサービスを提供し、ＭＮのＨＡからのトンネリングされたパケットに対してトンネルカプセル化を解放して脱カプセル化データパケットをＭＮに送信し得るルータである。ＨＡ及びＦＡ双方は、それらがホームネットワークＨＮに位置するのか外部ネットワークＦＮに位置するのかをＭＮが判断できるようなエージェント広告メッセージを周期的に送信することができる。モバイルノードがＦＮにあるときは、ケア・オブ・アドレスＣｏＡは受信されたフォーリンエージェント広告メッセージから取得できる。また、同位置（Co-located）ケア・オブ・アドレスＣｏＣｏＡのようなケア・オブ・アドレスは外部ネットワークによって割り当てられ得る。ここで、ＣｏＣｏＡはＦＮによってＭＮに割り当てられた個別のＩＰアドレスであり、モバイルノードは、カプセル化されてトンネリングされたパケットを受信することができる。ＦＡＣｏＡを用いるモバイルノードはその後、ＦＡによって転送される脱カプセル化パケットを受信する。

ＩＰｖ４環境では、ＭＮはフォーリンエージェントから他のフォーリンエージェントに移動する度にケア・オブ・アドレスをそのホームエージェントに登録する。従って、セッションの連続性を維持するために、ネットワーク層ハンドオーバーのハンドオーバー遅延及びパケットロスが最小限まで減らされる必要がある。現存の技術は主に２つの態様によってシームレスなネットワーク層ハンドオーバーを得ている。その第１のものは、ハンドオーバーに必要な手順の潜在的な遅延を直接減らすものであり、例えば、ハンドオーバーにおける幾つかの手順の遅延を減らすこと、ハンドオーバー中の幾つかの手順を重複させてハンドオーバー遅延全体を減らすこと（即ち、事前の登録）等である。しかし、この第１の態様によるだけではシームレスなネットワーク層ハンドオーバーを得ることは難しい。例えば、フォーリンエージェントとモバイルノードのホームネットワークとの間の距離が非常に大きい場合、登録のためのシグナリング遅延が非常に長くなることになる。

図２に示すように、第２の態様は地域登録的解決手段である。この解決手段では、登録を減らすために、ゲートウェイ・フォーリンエージェントＧＦＡといわれる新たなネットワーク要素がＦＮに追加される。中央ノードとしてのゲートウェイ・フォーリンエージェントはビジターのリストを保持及び分散し、データを転送する責任を担う。制御プレーンでは、ＭＮからホームエージェントＨＡに送信される全ての登録リクエストは現在のＦＡによってＧＦＡに転送され、さらにＧＦＡは登録リクエストをＨＡに転送する必要があるかを判断する。さらに、ゲートウェイ・フォーリンエージェントは全てのビジターの情報を収集及び保持し、それを訪問ドメインにおける他のフォーリンエージェントに分散する。米国特許第７０６９３３８Ｂ２号は地域登録的解決手段を詳述しており、この解決手段についての詳細はこれ以上ここには記載しない。従って、ゲートウェイ・フォーリンエージェントと、同じ訪問ドメイン内に位置する地域登録の関連する全てのフォーリンエージェントとの間のトポロジーは固定され、配備の柔軟性に欠ける。さらに、この解決手段は、ネットワークに追加のゲートウェイ・フォーリンエージェントを設定するだけでなく、地域登録関連機能がモバイルノードＭＮと同様にホームエージェントＨＡ、フォーリンエージェントＦＡにおいてサポートされることを要するので、実装コストが大幅に増加し、多くのベンダ及びオペレータに拒否される傾向にある。また、この解決手段によって克服するのが難しい欠点は：既存のＭＮについては、それらは対応する地域登録機能をサポートできないのでこの解決手段から利益を受けることができないこと、既存のＨＡ及びＦＡについては、それらも対応する機能をサポートできないのでこの解決手段に組み込まれることができないこと、である。

このように、ホームネットワークに到達するシグナリングメッセージ数の最小化を達成し、ＭＮがＦＮで移動しているときに生成されるシグナリング遅延を減らすために、改善された解決手段が依然として必要とされている。

従来技術の上記欠点に対処するために、本発明は、ＩＰｖ４において、ローミングＭＮをＨＡに登録し、ホームネットワークへのシグナリングメッセージ数を大幅に減らすための改善された方法を提供する。

本発明は、ＩＰｖ４においてモバイルノードＭＮをホームエージェントＨＡに登録するための方法を提供し、ＩＰｖ４は少なくとも１つのモバイルノードＭＮ及びホームエージェントＨＡを備え、さらに少なくとも２つのフォーリンエージェントＦＡを備え、本方法は、
Ａ．フォーリンエージェントグループＦＡＧを構成するフォーリンエージェントＦＡから少なくとも２つのＦＡを選択するステップ、
Ｂ．ＦＡＧ内のＦＡメンバーが、ＦＡＧのカバレッジエリアにローミングしていくＭＮの情報を共有するステップ、
Ｃ．ＦＡＧのいずれか１つのＦＡが、ＭＮによって送信されたケア・オブ・アドレスをＨＡに登録するための登録リクエストを受信すると、共有されたＭＮ情報によって、ＭＮがＦＡＧカバレッジエリアに初めて入るのかどうかを判断するステップ、
Ｄ．ＭＮがＦＡＧカバレッジエリアに初めて入る場合は、ＦＡが受信登録リクエストをＨＡに転送し、そうでない場合は、登録レスポンスをＭＮに直接送信するステップ
を備える。

好ましくは、ＦＡＧのＦＡは、リンクで隣接し、サブネットで隣接し、又はネットワークカバレッジエリアで隣接するＦＡとなり得る。好ましくは、ＦＡＧのＦＡは、ＭＮの情報を保持するために、ビジター情報テーブルＶＩＴ及び／又はグループ全域ビジター情報テーブルＯＶＩＴを保持する。

上記ステップＣにおいて、ＭＮがケア・オブ・アドレスとしてフォーリンエージェント・ケア・オブ・アドレスＦＡＣｏＡを用いるときは、ＦＡＣｏＡは、ＭＮを現在サービングしているＦＡのアドレス、又はＦＡＧに対して構成されたエニーキャストアドレスＡＡであり、ＭＮがケア・オブ・アドレスとして同位置ケア・オブ・アドレスＣｏＣｏＡを用いるときは、ＦＡＧカバレッジエリア内のＣｏＣｏＡがそれに対して構成される。好ましくは、ＦＡが、ＭＮのホームアドレスＨｏＡ又は同位置ケア・オブ・アドレスＣｏＣｏＡによって、ＦＡＧカバレッジエリアに初めて入るのかどうかを判断する。

上記ステップＤにおいて、ＦＡはＭＮ情報を更新し、自身をＭＮを現在サービングしているＦＡとして示す。

上記ステップＡにおいて、ＦＡＧのＦＡメンバーの一部が、共有されたＭＮ情報を分散及び保持する責任を担う転送用協働的ＦＡとして選択され、又は共有されたＭＮ情報を分散及び保持するための専用の転送用協働的ＦＡがＦＡＧ内に設定される。

好ましくは、専用転送用協働的ＦＡは、データパケット通過量が多いＦＡＧカバレッジエリアのノードにおいて、又はＨＡからＦＡＧのＦＡメンバーへの主経路において設定される。

本発明はまた、ＩＰｖ４においてモバイルノードＭＮをホームエージェントＨＡに登録するためのフォーリンエージェントグループＦＡＧを提供し、ＩＰｖ４は少なくとも１つのモバイルノードＭＮ及びホームエージェントＨＡを備え、さらに少なくとも２つのフォーリンエージェントＦＡを備え、
ＦＡの少なくとも２つがＦＡＧとして形成され、ＦＡＧのＦＡメンバーはＦＡＧカバレッジエリアにローミングしていくＭＮの情報を共有し、
ＦＡＧを構成するＦＡが、
ＦＡＧを構成する他のＦＡから共有情報を取得するための共有情報取得手段、
ケア・オブ・アドレスをＨＡに登録するＭＮの登録リクエストが受信されると、共有されたＭＮ情報によって、ＭＮがＦＡＧカバレッジエリアに初めて入るのかどうかを判断する管理手段、及び
ＭＮがＦＡＧカバレッジエリアに初めて入るものと管理手段が判断した場合は、登録リクエストをＨＡに転送し、そうでない場合は、登録レスポンスをＭＮに直接送信するための登録処理手段
を備える。

好ましくは、ＦＡの管理手段は、ＭＮの情報を保持するためにビジター情報テーブルＶＩＴ及び／又はグループ全域ビジター情報テーブルＯＶＩＴを保持する。好ましくは、前記管理手段は、ＭＮがＦＡＧカバレッジエリアに入るのが初めてではないものと判断したときは、自身をＭＮを現在サービングしているＦＡとして示す。

ＦＡの管理手段は、エニーキャストアドレスＡＡ又はＦＡのアドレスとしてエージェント広告における移動エージェント広告拡張にケア・オブ・アドレスを設定し、又はＭＮに対してＦＡＧカバレッジエリア内のＣｏＣｏＡをケア・オブ・アドレスとして構成する。

好ましくは、ＦＡＧのＦＡの一部が、管理手段が共有ＭＮ情報を分散及び保持する責任を担う転送用協働的ＦＡとして設定され、共有ＭＮ情報を分散及び保持するとともにデータパケットを転送するための専用の転送用協働的ＦＡがＦＡＧに設定される。

本発明はまた、ＩＰｖ４においてモバイルノードＭＮをホームエージェントＨＡに登録するためのフォーリンエージェントＦＡを提供し、ＩＰｖ４は少なくとも１つのモバイルノードＭＮ及びホームエージェントＨＡを備え、さらに少なくとも２つのフォーリンエージェントＦＡを備え、ＦＡは、そのカバレッジエリアにローミングしていくＭＮの情報を共有するために； ケア・オブ・アドレスをＨＡに登録するＭＮの登録リクエストが受信されると、ＭＮがＦＡＧカバレッジエリアに初めて入るのかどうかを共有されたＭＮ情報によって判断するために； 及びＭＮがＦＡＧカバレッジエリアに初めて入る場合には登録リクエストをＨＡに転送し、そうでない場合には登録レスポンスをＭＮに直接送信するために使用される。

本発明はまた、ＩＰｖ４においてモバイルノードＭＮのホームエージェントＨＡへの登録を扱うためのコンピュータプログラムを提供し、ＩＰｖ４は少なくとも１つのモバイルノードＭＮ及びホームエージェントＨＡを備え、さらに少なくとも２つのフォーリンエージェントＦＡを備え、そのコンピュータプログラムは、
少なくとも２つのＦＡをグルーピングしてフォーリンエージェントグループＦＡＧを形成し、
ＦＡＧのＦＡメンバーがＦＡＧカバレッジエリアにローミングしていくＭＮの情報を共有し、
ＦＡＧのいずれか１つのＦＡが、ＭＮによって送信されたケア・オブ・アドレスをＨＡに登録するための登録リクエストを受信すると、共有されたＭＮ情報によって、ＭＮがＦＡＧカバレッジエリアに初めて入るのかどうかを判断し、
ＭＮがＦＡＧカバレッジエリアに初めて入る場合は、ＦＡが受信された登録リクエストをＨＡに転送し、そうでない場合は、登録レスポンスをＭＮに直接送信する
ためのインストラクションを備える。

本発明はまた、本発明による方法、フォーリンエージェントグループＦＡＧ及びフォーリンエージェントＦＡを実行するためのコンピュータ可読インストラクションがそこに記憶される記憶媒体を提供する。

本発明はまた、本発明による方法、フォーリンエージェントグループＦＡＧ及びフォーリンエージェントＦＡを実行するためのコンピュータ可読インストラクションを有するプロセッサを含むコンピュータシステムを提供する。

本発明によって提供される改善された解決手段は、ローミングＭＮからＨＡへの登録メッセージを大幅に減らし、それによりＭＮがＦＮで移動するときに生成されるシグナリング遅延を低減する。地域登録的解決手段に比べて、本発明はより簡素かつ柔軟な解決手段を提供して、新たな要素をネットワークに設定すること及びＭＮ、ＨＡにおいてサポートされる追加の機能を付加することを回避し、配備コストを大幅に削減する。さらに、ＦＡＧを構成するＦＡについて、共有ＭＮ情報（例えば、ＯＶＩＴ）の分散は、中央化されるように（即ち、選択されたＦＡメンバーの１つ又は幾つかが共有情報を保持、収集及び分散し、他のＦＡメンバーへの情報を更新するように）、あるいは拡散されるように（即ち、各ＦＡが共有情報を保持し、情報が更新されると、いずれかのＦＡメンバーがそれを他のＦＡメンバーに分散するように）設計できる。結果として、この解決手段はより柔軟な配備を提供するので、それ自体をより多くのネットワークに適用させることができる。発明の「ＦＡＧ」による解決手段によると、ＭＮ及びＨＡに関して、それらはＦＡＧを構成するＦＡメンバー間の変更はもちろんのこと、ＦＡＧの存在を感じることはない。即ち、ＦＡＧを構成するＦＡのみが本解決手段と従来技術との差を知ることになる。従って、従来技術におけるＭＮ及びＨＡの双方が本解決手段に参加して本解決手段から利益を受けることが可能となり、既存のＩＰｖ４、特にモバイルＩＰｖ４、とのシームレスな統合を達成することができる。

図１はＩＰｖ４環境においてモバイルノードが外部ネットワークにわたって移動するときのネットワークトポロジー構造の一例を示す。 図２は地域登録的解決手段のネットワークトポロジー構造の一例を示す。 図３は本発明による、ＦＡＧで構成されたＩＰｖ４環境においてモバイルノードが外部ネットワークにわたって移動するときのネットワークトポロジー構造の一例を示す。 図４はＦＡＧのＦＡの一構造例を示す。 図５は本発明による、ＭＮがＦＡＣｏＡをケア・オブ・アドレスとして用いてＨＡに登録する際のフローチャートを示す。 図６は本発明による、ＦＡＣｏＡをケア・オブ・アドレスとして用いるＭＮに関してＭＮのＨｏＡに宛てられた受信データパケットをＨＡが転送する際のフローチャートを示す。 図７は本発明による、ＦＡＣｏＡをケア・オブ・アドレスとして用いるＭＮがデータパケットを通信ノードＣＮに送信する際のフローチャートを示す。 図８は本発明による、ＦＡＧで構成されるＩＰｖ４環境においてモバイルノードが外部ネットワークにわたって移動するときのネットワークトポロジー構造の他の例を示す。

本発明の基本的発想は、幾つかのＦＡを選択して、好ましくは、幾つかの隣接ＦＡ（リンクで隣接するもの、サブネットで隣接するもの、ネットワークカバレッジエリアで隣接するもの又は他の態様での隣接するＦＡ）を選択してフォーリンエージェントグループといわれる協働的グループを形成することである。ＦＡＧによってサービングされるネットワークは訪問ドメインＶＤといわれる。ＩＰｖ４環境にあるＦＡのように、そのエリアに移動していくＭＮの情報を保持するのに加えて、このグループに属する全てのＦＡメンバーに関して、ＦＡメンバーの各々は、それらの間でそれぞれのサービングエリアにローミングしていくＭＮの情報、特に登録情報、を共有することができ、それにより、ＶＤに移動していくいずれのＭＮの情報も共有することができる。ＭＮ情報の共有によって、ＭＮがＶＤエリアに初めて移動していくときのみ、ＦＡＧのＦＡはＭＮのケア・オブ・アドレスをＭＮのＨＡに登録し、その後、ＭＮがＶＤ内のＦＮを横断して／その中で移動するときは、ＨＡへの登録はもはや実行される必要はない。即ち、ＶＤにローミングしていくＭＮに関して、ＨＡへの登録は、それが初めてＶＤに入る時のみ必要となり、ＨＡへの複数の登録は、ＭＮがその後依然としてＶＤ内を移動している限り、もはや不要である。従って、本発明のＦＡＧはＨＡ及びＭＮに対して１つのＦＡとして挙動する。従って、本発明の改善された解決手段はローミングＭＮとＨＡの間の登録手順を大幅に減らし、それによってＨＡへのシグナリングメッセージを減らし、さらにＭＮがＶＤに移動していくときのシグナリング遅延を減らす。

図３はＩＰｖ４環境においてＦＡＧにサービングされるＶＤ内で移動するＭＮの一例を示す。通常、ＩＰｖ４環境は、モバイルノードＭＮ、フォーリンエージェントＦＡ及びホームエージェントＨＡの３つのタイプの機能エンティティを備え、ここで、ＭＮ及びＨＡの意味及び機能は従来技術におけるものと同様である。図３に示す例では、ＭＮはＨＮにホームアドレスＨｏＡを有し、ルータ１はＭＮのＨＡである。ＦＡ１、ＦＡ２、ＦＡ３は、ネットワークカバレッジエリアが隣接する外部ネットワークＦＮ１、ＦＮ２、ＦＮ３におけるそれぞれのＦＡである。この例では、ＦＡ１、ＦＡ２及びＦＡ３はＦＡＧとして構成されるので、この３個のＦＡは協働的なＦＡとなり、ＦＮ１、ＦＮ２及びＦＮ３によってサービングされるエリアはＶＤを形成する。ＦＡＧを構成する一ＦＡメンバーに関して、それはグループ内の他のＦＡメンバーのアドレスを知っているべきであり、それが属するＦＡＧのＩＤも知得することによって異なるＦＡＧを識別すべきであり、これは手動又は自動構成によって達成できる。好ましくは、ＦＡＣｏＡをケア・オブ・アドレスとして用いるＭＮに関して、エニーキャストアドレス（Anycast Address）ＡＡがＭＮのケアオブアドレスとしてＦＡＧに対して構成され、この時のＡＡもＦＡＧのＩＤとなる。さらに、１つのＦＡは複数の異なるＦＡＧにおいて同時に設定及び追加されることができ、ＦＡはこの時、識別子によってそれが属するＦＡＧを認識する。なお、異なるＩＤが異なるグループを識別し、それは手動又は自動構成によって達成され得る。好ましくは、異なるＦＡＧは、アプリケーション環境におけるＦＡ間の隣接状況やＭＮの移動頻度等のような要因に基づいて柔軟に設定できる。

図４は上述のＦＡ１−３の構造の一例を示す。ここで、従来技術における移動エージェント広告等のような機能に加えて、ＦＡはさらに、ＦＡＧの他のＦＡメンバーからＭＮについての共有可能な情報を取得するための共有情報取得手段を備える。管理手段はグループ全域ビジター情報テーブル（Over-group Visitor Information Table）ＯＶＩＴ及びビジター情報テーブル（Visitor Information Table）ＶＩＴを保持するのに使用される。ＶＩＴはＦＡＧの各ＦＡメンバーでＩＰｖ４プロトコルの登録プロセスによって作成される。そのようなリストは「ビジター情報エントリ」のセットである。ビジター情報エントリに含まれる必要な欄は、ＭＮのホームアドレスＨｏＡ、ＨＡアドレス、現在のＦＡ即ちＣＦＡ（現在のフォーリンエージェント）のアドレス、及び現在の登録の存続時間であり、ここで、「ＣＦＡ」は現在どのＦＡがＭＮにサービスを提供しているのかを示す。ＭＮがＣｏＣｏＡをそのケア・オブ・アドレスとして使用する状況では、「ＭＮのＣｏＣｏＡ」の欄もテーブルに含まれるべきである。ＦＡＧの全てのＦＡメンバーのＶＩＴは、全てのＦＡメンバーで共有される（ここではＦＡ１−３で共有される）ＯＶＩＴに組み込まれ得る。ビジター情報の共有を実現するために、ＦＡメンバーにおける管理手段は、規則的に（例えば、周期的に）若しくは特定のＦＡメンバーからのリクエストによってトリガされて、又はそのＶＩＴにおける変化によってトリガされて、そのＶＩＴにおける更新情報の、ＦＡＧの他のＦＡメンバーへの分散を管理する。その分散はＩＰユニキャストＵＤＰによって配信されることができ、又はＴＣＰの配信態様、マルチキャスト等のような、更新情報を他のＦＡメンバーに配信することができる他の態様も使用され得る。広告を受信する他のＦＡメンバーの各々はそのＶＩＴ及びＯＶＩＴを更新する（追加、削除、変更等の動作を含む）。ＦＡが登録リクエストをＭＮから受信すると、管理手段は、ＭＮがＶＤに入るのが初めてなのかどうかを判断する責任を担う。さらに、ＦＡにおける登録処理手段が、登録リクエストをＭＮのＨＡに送信すること、登録レスポンスをＭＮに送信すること等といった登録関連のトランザクションに使用される。

図４に示すＦＡの構造は一例に過ぎない。当業者であれば、上記例の管理手段は、その機能に応じて、（ＯＶＩＴのような共有情報を保持するための）保持手段、（ＭＮがＶＤに入るのが初めてなのかどうかを判断するための）判断手段等に分割することもできることが分かるはずである。同様に、上記例における管理手段及び登録処理手段は一体化されてもよい。要するに、ＦＡの特定の構造は固有のものではなく、上記例に限定されるものではない。ＶＤに入っていくＭＮの情報を共有でき、ＭＮがＶＤに初めて入っていくのかどうかを判断できるという前提の下、その特定の構造は柔軟に設定でき、そこにおける手段及びモジュールは統合又は分割でき、又は他の機能を実施するための手段及びモジュールが追加され得る。

選択的に、ＦＡＧを構成する複数のＦＡメンバーは隣接していなくてもよい。例えば、或るＭＮが或る特定のＦＮエリアに移動することが分かっている場合、関係するＦＡは直接的にＦＡＧとして構成されることができ、それらのＦＡが隣接していなくてもよいことは明らかである。

なお、上記例では、各ＦＡメンバーが２つのテーブル、ＶＩＴ及びＯＶＩＴを保持し、或るＦＡによって保持されるＶＩＴが更新されると、更新された情報だけが他のＦＡメンバーに送られるので、ＦＡ自身のサービスはＦＡＧの情報から分離されることができ、それはネットワークリソースの完全利用をも実現し、好ましい解決手段である。しかし、当業者であれば、特定のアプリケーションにおいて、各ＦＡメンバーの異なる搬送能力及びリソースの異なる使用に基づいて、各ＦＡメンバーは２つのテーブルのうちの１つのみを保持することも可能であり、それでも、ＦＡＧ内のＭＮ情報を共有することが達成される限り発明の解決手段が実現されることが分かるはずである。もちろん必要であれば、ＦＡメンバーは、更新された情報だけでなく、その保持するＶＩＴ又はＯＶＩＴにおける他の情報を他のＦＡメンバーに送信することもできる。

選択的に、特定のアプリケーションによっては、ＦＡＧのＦＡメンバーの一部がＶＩＴ又はＯＶＩＴを保持するように構成され、一方、他のＦＡメンバーは共有ＭＮ情報を必要な時に一時的に取得する。そのような状況は、例えば、ＦＡＧのＦＡメンバーがより少ないか若しくはＦＡにカバーされるエリア内のサービスが少ないような状況、又はより多くのメンバーを有するＦＡＧのＦＡメンバーに対して共有エリアが論理的に分割され、共有エリアの各々内で１つのＦＡが共有情報を保持するように選択される一方で、共有情報を保持するＦＡからそのエリア内の他のＦＡが所望の情報を一時的に取得するような状況である。要するに、当業者であれば、ＦＡＧのＦＡメンバー間でＭＮの情報を共有する態様は多様であり、特定のアプリケーション環境に基づいて柔軟に選択され得ることが分かるはずである。

さらに、ＦＡＣｏＡをケア・オブ・アドレスとして用いるＭＮに関して、ＦＡＧの各ＦＡメンバーはエニーキャストアドレスＡＡを、エージェント広告における移動エージェント広告拡張に好ましいケア・オブ・アドレスとして設定し、それによりＭＮはＡＡを取得し、それを登録リクエストＲＲＱに追加する。ＦＡＧのＦＡメンバーはＦＡＧのＡＡのルーティング情報をＮＳＰ（ネットワーク・サービス・プロバイダ）ネットワークに公表し、又はＩＰコアネットワークに公表し、それによってエニーキャストアドレスＡＡを宛先として持つデータパケットがグループのＦＡメンバーに到達することができる。

ＨＮの外部をローミングしてＶＤに亘って移動するＭＮに関して、ＦＡＣｏＡ及びＣｏＣｏＡ双方がケア・オブ・アドレスとして使用され得る。上記２つの場合に関して、ＭＮがＨＡに登録するプロセス及びデータパケット転送のプロセスを以下にそれぞれ説明する。

１．ケア・オブ・アドレスとしてフォーリンエージェント・ケア・オブ・アドレスを用いる場合
１．１ 登録プロセス
図５はＭＮがＦＡＣｏＡをそのケア・オブ・アドレスとして用いるときの登録プロセスを示す。この例では、上述のように、ＦＡＧの全ＦＡメンバーはＡＡをＦＡＣｏＡとして公表するので、登録リクエストにおける「ＣｏＡ」フィールドがＡＡとして設定される。具体的には、ＭＮは、ＶＤにおいて外部ネットワークＦＮに亘って移動すると、移動エージェント広告を受信し、移動検出を行ってケア・オブ・アドレスを取得する（ステップ５０１）。移動検出は通常、ネットワークプレフィクスの変化の検出、又はＭＮによって受信された「ルータ広告」の存続時間に基づくので、ＦＡＣｏＡの設定はＭＮの移動検出に影響を与えない。ＭＮに関して、ＡＡは、汎用ＩＰｖ４において受信された移動エージェント広告におけるＦＡＣｏＡと変わらない。ＭＮは、それがＨＮの外部でＦＮへ移動したと分かると、例えば図３において、ＭＮがＨＮにおける位置１からＶＤにおけるＦＮ１内の位置２へ移動すると、取得されたケア・オブ・アドレスを登録するために登録リクエストＲＲＱをＨＡに送信する（ステップ５０２）。前述したように、ＭＮは、ＦＡＧのエニーキャストＡＡをケア・オブ・アドレスとして使用して、ＩＰｖ４、好ましくはモバイルＩＰｖ４において規定された登録プロセスを開始する。ＶＤにおけるＣＦＡ（ここではＦＡ１）がＭＮのＲＲＱを受信すると、それはＭＮのホームアドレスＨｏＡをキーワードとして用いてＯＶＩＴを検索し、一致するビジターリストのエントリが存在するかを判断する（ステップ５０３）。一致するエントリがない場合、それはＭＮがＶＤに（訪問ドメインに含まれないネットワークから現在のネットワークに）初めて入ったことを意味する。この場合、ＦＡ１はＲＲＱをＭＮからＭＮのＨＡに転送するとともにＭＮのケアオブアドレスＡＡを登録する必要がある（ステップ５０４）。ＦＡ１は自身の保持するＶＩＴ及びＯＶＩＴにおいてＭＮに対するビジターリストのエントリを作成し、そのエントリを自身のグループ内の他のＦＡメンバーに分散する。ＲＲＱを受信した後、ＨＡはＭＮのＨｏＡを受信したＡＡにバインディングし、登録レスポンスＲＲＰをＦＡ１に送信する（ステップ５０５）。ＦＡ１はＲＲＰをＨＡからＭＮに転送して、ＩＰｖ４で規定される登録プロセスを完了する（ステップ５０６）。上記の動作によって、ＭＮのビジターリストのエントリはＣＦＡのＶＩＴ及びＯＶＩＴに追加され、ＣＦＡはＯＶＩＴの更新をＦＡＧの他のメンバーに分散し、他のメンバーはそれらのＯＶＩＴをそれに従って更新する。一致するエントリが１つある場合、それはＭＮが訪問ドメインに含まれる或るネットワークから現在のネットワークに移動すること、例えば、ＭＮが図３の位置２から位置３に移動することを意味する。この場合、ＣＦＡ（ここではＦＡ２）のみがエントリを更新する必要があり、ＲＲＱをＭＮからＨＡに転送する（ケア・オブ・アドレスの登録の更なる起動が続く）必要はないが、ＲＲＰをＭＮに直接送信する（ステップ５０７）。ここで、更新手段ＦＡ２は古いＣＦＡアドレス（ＦＡ１）を自身のアドレスに置き換え、古い存続時間を更新し、更新情報をＦＡグループの他のメンバーに分散する。

１．２ 転送プロセス
図６及び７はそれぞれ、ＭＮがＶＤにおいてＨＮから出ていくとき及びネットワークを通過するときのＩＰパケットの送信プロセスを示す。ここで、説明は、図３に示すネットワーク環境において、ＭＮがＶＤにおいてＨＮからＦＮ２エリアに移動する例示によって与えられる。

図６に示すように、ＨＮから離れたＭＮのＨｏＡに通信ノードＣＮから宛てられたパケットに関して、ＭＮのＨＡはパケットを抜き取る（ステップ６０１）。ＨＡはパケットをＩＰｖ４、好ましくはモバイルＩＰｖ４において規定されたように転送する：パケットはＨＡによって保持されるバインディング情報で示されるＡＡにトンネリングされる（ステップ６０２）。ＦＡＧのＦＡメンバーはＡＡをＮＳＰに公表したので、ＨＡによって送られるトンネリングされるパケットはＨＡに最も近いＦＡにルーティングされる（最も近いとは、通常、ポリシーベース、ルーティングホップ数ベース、遅延ベース、帯域幅ベース等によるものをいう）。この例における最も近いＦＡはＦＮ１におけるＦＡ１である。パケットを受信した後、ＦＡ１はトンネリングされたパケットの有効性をＩＰｖ４で規定されるようにチェックし、トンネリングされたパケットの内部ＩＰ宛先アドレス、即ち、ＭＮのＨｏＡをキーワードとして用いてＯＶＩＴを検索し、ＭＮを現在サービングしているＭＮのＣＦＡを知る（ステップ６０３）。一致するエントリがＯＶＩＴにある場合、パケットはＩＰトンネリングによって又はＩＰルーティングオプションを挿入することよってＣＦＡ（この例ではＦＡ２）に転送される（ステップ６０４）。ＣＦＡはパケットを受信した後に、パケットの有効性をチェックし、パケットの内部ＩＰ宛先アドレス、即ち、ＭＮのＨｏＡをキーワードとして用いてＯＶＩＴを検索する（ステップ６０５）。一致するエントリがある場合、内部パケットはＭＮに転送される（ステップ６０６）。一致するエントリがＣＦＡのＯＶＩＴにない場合、パケットは静かに廃棄される（ステップ６０７）。

図７に示すように、ＨＮから離れたＭＮから通信ノードへのパケットについて、パケットはその最初のホップルータＣＦＡ（この例ではＦＡ２）に直接転送される（ステップ７０１）。ＣＦＡはＭＮが登録済みビジターかどうかをチェックする：データパケットの送信元ＩＰアドレス、即ち、ＭＮのＨｏＡをキーワードとして用いてＯＶＩＴを検索する（ステップ７０２）。一致するエントリがＣＦＡ（ここではＦＡ２）のＯＶＩＴにある場合、それはパケット送信元が登録済みビジターであり、ＣＦＡはパケットを通常の転送メカニズムによって通信ノードに転送する（ステップ７０３）。一方、一致するエントリがＣＦＡのＯＶＩＴに存在しない場合、パケットは登録済みビジターからのものではなく、パケットは静かに廃棄される（ステップ７０４）。

ローミングＭＮがＦＡＣｏＡをそのケア・オブ・アドレスとして使用するときのケア・オブ・アドレスのＨＡへの登録プロセス及びＭＮとＣＮの間のデータ転送プロセスは上述した。好ましい解決手段として、本例でのＦＡＧはエニーキャストＡＡによって構成され、それをＭＮのケア・オブ・アドレスとして捉える。しかし、当業者であれば、本発明の発想によると、ＶＤにローミングしていくＭＮの情報をＦＡＧのＦＡメンバーが共有できる限り、本発明の解決手段は実現でき、必ずしもＦＡＧに対するエニーキャストＡＡを構成する必要はないことが分かるはずである。

例えば、本発明の原理によると、既存のＩＰｖ４ネットワーク環境におけるＦＡに関して、リンク隣接、サブネット隣接、ネットワークカバレッジエリア隣接又は他の形態での隣接する２以上のＦＡがＦＡＧを形成するように選択される。ここで、はやり図３を一例として挙げると、ＦＡ１、ＦＡ２、ＦＡ３がグループ化されてＦＡＧを形成し、サービングエリアにローミングするＭＮの情報をＦＡＧの全ＦＡ間で共有することは、各ＦＡがそれが保持するテーブルを更新するときにユニキャスト又はマルチキャスト等の態様で更新情報を他のＦＡメンバーに適宜転送することによって、又は周期的転送によって等、何らかのメカニズムによって達成される。ＭＮがＨＮを出てＶＤを通ってＦＮ１に移動するとき、ＭＮは、移動エージェント広告を受信して移動検出を行うことによって、それがＨＮの外に移動してＦＮに位置したことを把握し、登録リクエストＲＲＱをＨＡに送信して取得したケア・オブ・アドレスを登録する。ここで、ＦＡＧはＡＡでは構成されず、従って、ＭＮはＦＡ１のアドレスをそのケア・オブ・アドレスとして使用する。同様に、ＶＤにおけるＣＦＡ、即ち、ＦＡ１はＭＮのＲＲＱを受信すると、ＭＮのＨｏＡをキーワードとして用いてＯＶＩＴを検索し、一致するビジターリストのエントリがあるかどうかを判断する。この場合、上記例との唯一の差は、ＭＮがＡＡではなくＦＡ１のアドレスをケア・オブ・アドレスとして使用する点であるが、ここにこれ以上記載されていない登録プロセスは上記例のものと実質的に同じである。ＭＮのＨＡは、ＨＮから離れたＭＮのＨｏＡに通信ノードＣＮから宛てられたパケットを抜き取り、本例のＦＡＧはＡＡで構成されていないのでＨＡはＩＰｖ４で規定されるように完全にパケットを転送する：パケットはＨＡ、即ち、ＦＡ１によって保持されるバインディング情報に示されるケア・オブ・アドレスにトンネリングされる。ＦＡ１はパケットを受信すると、トンネリングされたパケットの有効性のチェック及びＭＮのＨｏＡをキーワードとして用いることによるＯＶＩＴの検索といった上記動作を実行し、ＭＮを現在サービングしているＣＦＡがＦＡ２であることを、ＦＡＧのそれぞれのＦＡメンバー間の共有ＭＮ情報によって、例えば、ＯＶＩＴによって知得する。そして、上述の転送プロセスと同様に、ＦＡ１は受信パケットをＭＮのＣＦＡ、即ち、ＦＡ２に転送し、それはさらにパケットを処理する（一致するエントリが存在する場合にはそれをＭＮに転送し、それ以外の場合にはそれを廃棄する）。ローミングＭＮが情報をＣＮに送信すると、上述の対応の処理プロセスと同様に、ＣＦＡ、即ち、ＦＡ２は、データパケットの受信時にＭＮが登録済みビジターかどうかを判断する。ＣＦＡは、例えば、ＯＶＩＴを検索することによって、それ自身によって保持される情報又はＦＡＧのＦＡメンバー間で共有されるＭＮ情報に従って、ＦＮ１への移動時にＭＮが既に登録されていることを把握した場合にはパケットはＣＮに転送され、それ以外の場合には静かに廃棄される。

上記の例から分かるように、ＦＡＧがＡＡで構成されていない場合であっても、それは本発明を実現できる。即ち、ＡＡのないＦＡＧに関して、ＭＮがそれを現在サービングしているＦＡのアドレスをＦＡＣｏＡとして用いるとき、ＦＡからＭＮに宛てられたパケットを受信するＦＡは、もはやＨＡに最も近いＦＡＧ内のＦＡではなく、ＭＮが初めてＶＤに移動したときに登録を提供するＦＡ（上記の例ではＦＡ１）である。

２．同位置ケア・オブ・アドレスＣｏＣｏＡをケア・オブ・アドレスとして用いる場合
ＭＮがＣｏＣｏＡをそのケア・オブ・アドレスとして用いる場合も、基本的発想は「ＦＡＣｏＡ」の場合のものと同様である。この実施例では、ＭＮはＲＲＱ及びＲＲＰを中継するのにＦＡをはやり必要とし、ＦＡメンバー間でＭＮでの情報共有を達成するために、ＦＡが登録済みＭＮに対するビジターリストのエントリを保持することを要する。ここで、ＭＮの登録プロセスはＦＡＣｏＡの場合における処理プロセスと類似する。その差は：ＭＮがＣｏＣｏＡをその現在のケア・オブ・アドレスとして維持できる範囲でＶＤが最大であること（訪問ドメインは未だに、ＦＡＧによってサービングされるネットワークをカバーするエリアである）；ＣｏＣｏＡを記憶するために、ＦＡＧのＦＡメンバーによって保持されるＯＶＩＴに「ＭＮのＣｏＣｏＡ」（ここで「Ｒ」ビットが設定される）も含まれ、ＯＶＩＴを検索するためのキーワードはトンネリングされたデータパケットの外部ＩＰ宛先アドレス、即ち、ＭＮのＣｏＣｏＡである。詳細な説明は以下の通りである。

登録プロセスにおいて、ＭＮは、ＶＤにおけるネットワークに亘って移動するとき、移動検出を行い、例えばＤＨＣＰ等によってＣｏＣｏＡを取得する。従来技術はどのようにしてＭＮがＣｏＣｏＡを取得するかを詳細に規定する規格を有しているので、本発明では説明しない。そして、ＭＮは登録プロセスを開始して、その新たに取得されたＣｏＣｏＡをそのケア・オブ・アドレスとしてＨＡに登録する。ＶＤにおけるＦＡは、ＲＲＱを受信すると、ＭＮのＣｏＣｏＡをキーワードとして用いてＯＶＩＴを検索して、ＭＮに対して一致するビジターリストのエントリがあるかどうかを判断する。ＭＮがＦＡＣｏＡをそのケア・オブ・アドレスとして使用する処理手順と同様に、一致するエントリがない場合、それはＭＮがＶＤに初めて入ることを意味する。そして、ＦＡはＶＤにおけるＭＮのＣｏＣｏＡをＭＮのＨＡに登録して登録プロセスを完了し、ＦＡによって保持されるＶＩＴ及びＯＶＩＴ双方においてビジターリストのエントリを作成して、更新情報をグループ内の他のＦＡメンバーに分散する必要がある。一致するエントリがある場合、それはＭＮは初めてＶＤに移動していくのではないことを意味し、ＦＡは、ＭＮのＣｏＣｏＡをＭＮのＨＡに登録するのではなく、エントリを更新して更新情報をＦＡグループの他のメンバーに分散するだけである。

転送プロセスにおいて、ＣＮによって送信され、ＨＮから離れたＭＮのＨｏＡに宛てられたパケットに関して、ＭＮのＨＡはパケットを抜き取る。ＨＡはＩＰｖ４、好ましくはモバイルＩＰｖ４で規定されたようにパケットを転送する：パケットはＨＡによって保持されるバインディング情報において示されるＣｏＣｏＡにトンネリングされる。トンネリングされたパケットは、最長一致プレフィクス検索アルゴリズム等のようなアルゴリズムに従ってＭＮに直接転送される。

ローミングＭＮから通信ノードに宛てられたパケットに関して、パケットはデフォルトのルータ、通常はＣＦＡ、に直接転送される。同様に、ＣＦＡはＭＮが登録済みビジターかどうかをチェックし、データパケットの送信元ＩＰアドレスをキーワードとして用いてＯＶＩＴにおけるＨｏＡと比較して、一致するものがあるかどうかを判断する。一致するエントリがある場合、パケット送信元は登録済みビジターであり、ＣＦＡはパケットを通常の転送メカニズムによってＣＮに転送する。あるいは、一致するエントリがＣＦＡのＯＶＩＴにない場合、パケットは登録済みビジターからのものではなく、静かに廃棄される。

上記から分かるように、ＯＶＩＴの内容及び検索キーワードが異なることを除いて、ＭＮがそのケア・オブ・アドレスとしてＦＡＣｏＡを用いるときの登録処理フローとＣｏＣｏＡを用いるときの登録処理フロー、併せてＭＮからＣＮにパケットを転送するフローは、類似する。ＭＮからＣＮへのデータパケットに関して：ＭＮは、はやりデータパケットをデフォルトのルータ（通常はＣＦＡ）に送信し、デフォルトのルータはパケットの有効性をチェックしてそれを対応のノードに向けて次のホップＩＰノードに転送する。

ＭＮがそのケア・オブ・アドレスとしてＦＡＣｏＡを使用する場合及びＣｏＣｏＡを使用する場合をそれぞれ上述した。上記例では、ＦＡメンバーは１つのタイプのリスト、即ちＶＩＴ又はＯＶＩＴを保持するだけであり、上記の検索動作は、ＦＡ自身によって保持されるテーブルを検索するのに対応して変更される。

上述した解決手段では、ＶＩＴ／ＯＶＩＴを検索するのにそれぞれＭＮのＨｏＡ、ＣｏＣｏＡをそのケア・オブ・アドレスとして使用するＦＡを例として記載した。当業者であれば、キーワードの選択はＭＮのＨｏＡ及びＣｏＣｏＡに限定されず、互いからローミングするＭＮを区別できるあらゆる情報がキーワードとして使用できることが分かるはずである。一例として、ＭＮが初めてＶＤに入っていくのかどうかをＦＡが判断するときのＭＮ情報を更新する動作も上述した。当業者であれば、ＦＡのサービスに依存して、上記の更新動作及びＭＮの種々のリクエストを処理する動作は同時に実行されなくてもよい。

好ましくは、上述の廃棄動作が実行されるときは、廃棄の動作のみが静かに実行され、他の廃棄に関する動作を実行しない。例えば、廃棄されるメッセージの送信元アドレスに宛てられるメッセージは生成されず、ログ上の記録はない。

本発明の解決手段によると、ＦＡＧを形成すること及びＯＶＩＴを分散することには、そのＦＡメンバーによって所有されるコンピューティングリソースに依存して多数のやり方がある。図３に示すＦＡＧの構成の例は、各ＦＡメンバーはほぼ同じコンピューティングリソース及び負荷能力を有するという前提に基づいている。この場合、いずれか１つのＦＡメンバーは、ＯＶＩＴ更新等の、そのＭＮの更新情報をＦＡＧの他のＦＡメンバーに直接分散することができる。しかし、コンピューティングリソース及び処理負荷がＦＡＧのＦＡメンバー間で不均衡な場合、余剰なコンピューティングリソースを持つＦＡメンバーをＦＡＧの転送用協働的（Forwarding Cooperative）ＦＡとして選ぶことができる。選択的に、転送用協働的ＦＡは、グループ間の他のＦＡメンバーによるものと同じ動作を実行することに加えて、ＦＡＧ内で共有されるＭＮ情報を分散する責任をさらに担う。具体的には、いずれかのＦＡメンバーが情報を更新してＦＡＧの他のＦＡメンバーに送信したときは常に、そのＦＡは情報を他のＦＡメンバーに直接送信せずに、それをまず転送用協働的ＦＡに送信し、それが更新情報をどのＦＡメンバーに送信するかを決定し、好ましくは、更新情報を必要とするＦＡに送信することを決定する。例えば、ＦＡＧに多数のＦＡメンバーがある場合、更新された情報が新たに追加されたエントリかどうかによって、即ち、エントリがＶＤに初めて入っていくＭＮによって作成されたものかどうかが転送用協働的ＦＡによって判断され、その場合には、転送用協働的ＦＡはそれをＦＡＧの全てのＦＡメンバーに送信することを決定することができ；そうでない場合には、転送用協働的ＦＡは、次の期間中に更新情報を必要とし得るＦＡを、ＦＡメンバーからＭＮのＣＦＡ及びＭＮのＨＡへの距離に基づいて選択する。

選択的に、ＦＡＧで共有されるＭＮ情報の保守を主に達成する独立したＦＡを転送用協働的ＦＡとして設定することもできる。図８に示すように、ＶＤは４個のＦＡを含み、ＦＡ１−３は図３及び４で示したＦＡと異ならず、この種のＦＡを「大規模協働的（Big Cooperative）ＦＡ」という。当該グループ内のＦＡ４の機能はＦＡ１−３の機能のサブセットであり、データ転送負荷を共にするために使用されるように設定される。図８のＦＡ４のみが以下の：ＯＶＩＴ保持、データパケット転送、の２つの役割を持ち、この種のＦＡを「転送用協働的（Forwarding Cooperative）ＦＡ」という。本例におけるＦＡＧの他の全てのＦＡメンバーであるＦＡ１−３はそのＯＶＩＴ更新を送信し、それはＦＡＧのＯＶＩＴ更新の全てを保持し、更新済み情報を必要とする他のＦＡメンバーへのＯＶＩＴ更新の分散を管理する責任を担う。さらに、図８に示すように、ＨＡからのデータパケットに関して、ＦＡ４はＨＡに（ポリシーベースで）最も近いＦＡメンバーであるから、ＦＡからのデータパケットは最初にＦＡ４に到着し、ＦＡ４はそのＯＶＩＴを検索してさらにＭＮのＣＦＡを特定してからデータパケットをＣＦＡに転送し、それがデータパケットをローミングＭＮに送信する。ローミングＭＮからのＣＮに宛てられたパケットに関して、転送プロセスは上記実施例のものと同じである。

ここで、なぜ転送用協働的ＦＡがデータ転送負荷を共にできるのかを説明しておく。図３に示す例において、異なるＨＡからＡＡへのデータパケットはＦＡＧのいずれのメンバーにも到達することができ、それがいずれ到達するＦＡＧのメンバーはネットワークトポロジー及びルーティングポリシーにおけるＨＡの位置に依存する。従って、転送用協働的ＦＡを適当なネットワーク位置に（例えば、ルーティングトポロジーに基づいて）配備する場合、ＦＡＧにおける大規模協働的ＦＡの一部又は全部の転送負荷を低減するように、ＡＡに宛てられた所定数のデータパケットが廃棄される。好ましくは、統計により、転送用協働的ＦＡを配備する位置はＶＤの最大データパケットスループットを持つ入力地点の１つとなり得、ＡＡに宛てられたほとんどのデータパケットは最初に転送用協働的ＦＡに到来してからＣＦＡに転送されることになる。転送用協働的ＦＡの位置の配備例は、ＦＡＧのＦＡメンバーの転送負荷を可能な限り大きく低減するように、ＦＡＧメンバーへの多数の異なるＨＡからのメイン／ハブ経路にそれを配備することである。従って、この例では、大規模協働的ＦＡが共有され得る又はされる必要がある転送負荷を決定することは、転送用協働的ＦＡの位置選択において非常に重要である。

本発明によって提供されるＦＡＧによると、ＦＡＧのＦＡメンバー間でＭＮ情報を共有することによって、ＶＤに亘るＭＮの移動中に、ＣＦＡは、ＭＮがＶＤ内のある外部ネットワークＦＮからＶＤ内の他のＦＮに移動する毎に登録プロセスを実行するのではなく、ＭＮがＶＤに初めて入っていくときにＭＮのケア・オブ・アドレスをＨＡに登録することだけを要することが可能となる。従って、ＦＡＧはＨＡ及びＭＮに対する単一のＦＡとして挙動し、それによってＩＰｖ４ベースのＨＡ及びＭＮが変更を伴わずにＦＡＧと協働できることを実現する。即ち、本発明の解決手段によると、ローミングＭＮによってそのホームＨＡに登録されるシグナリングが大幅に減り、それによりネットワーク層ハンドオーバー遅延が大幅に低減されるだけでなく、従来技術のＭＮ及びＨＡが本発明の解決手段から利益を得ることもできる。

本発明の方法及び手段は、コンピュータインストラクション、本発明の方法を実施する手段及びモジュール、本発明の方法を実行するためのコンピュータインストラクションを記憶する可読記憶媒体、発明の方法を実行するのに使用できるプロセッサを含むコンピュータ、又は当業者によって容易に想到可能な同様の実装態様等、ソフトウェア、ハードウェア又はそれらの組合せによって実施できる。

Claims (13)

1. ＩＰｖ４においてモバイルノード（ＭＮ）をホームエージェント（ＨＡ）に登録するための方法において、該ＩＰｖ４が少なくとも１つのモバイルノード（ＭＮ）及びホームエージェント（ＨＡ）を備え、さらに少なくとも２つのフォーリンエージェント（ＦＡ）を備え、該方法が、
   Ａ．フォーリンエージェントグループ（ＦＡＧ）を構成する前記フォーリンエージェント（ＦＡ）から少なくとも２つのフォーリンエージェント（ＦＡ）を選択するステップ、
   Ｂ．前記フォーリンエージェントグループ（ＦＡＧ）内のフォーリンエージェント（ＦＡ）メンバーが、前記フォーリンエージェントグループ（ＦＡＧ）のカバレッジエリアにローミングしていくモバイルノード（ＭＮ）の情報を共有するステップとを含み、前記フォーリンエージェントグループ（ＦＡＧ）の前記フォーリンエージェント（ＦＡ）は、前記モバイルノード（ＭＮ）の情報を維持するためにビジター情報テーブル（ＶＩＴ）を維持し、前記ビジター情報テーブル（ＶＩＴ）が、前記フォーリンエージェントグループ（ＦＡＧ）の各フォーリンエージェント（ＦＡ）メンバーにおいてＩＰｖ４プロトコルの登録処理によって生成され、ビジター情報テーブル（ＶＩＴ）は、モバイルノード（ＭＮ）のホームアドレス（ＨｏＡ）、ホームエージェント（ＨＡ）アドレス、現在のフォーリンエージェント（ＦＡ）、即ち、カレントフォーリンエージェント（ＣＦＡ）のアドレス、及び現在の登録の存続時間に関する情報を含み、前記カレントフォーリンエージェント（ＣＦＡ）は、どのフォーリンエージェント（ＦＡ）がモバイルノード（ＭＮ）へサービスを現在提供しているかを示すものであり、さらに、
   Ｃ．前記フォーリンエージェントグループ（ＦＡＧ）のいずれか１つのフォーリンエージェント（ＦＡ）が、モバイルノード（ＭＮ）によって送信されたケア・オブ・アドレスを前記ホームエージェント（ＨＡ）に登録するための登録リクエストを受信すると、前記共有されたモバイルノード（ＭＮ）情報によって、該モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るのかどうかを決定するステップと、
   Ｄ．前記モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入る場合は、前記フォーリンエージェント（ＦＡ）が前記受信された登録リクエストを前記ホームエージェント（ＨＡ）に転送し、そうでない場合は、登録レスポンスを該モバイルノード（ＭＮ）に直接送信するステップとを含む、方法。
2. 請求項１の方法において、前記フォーリンエージェントグループ（ＦＡＧ）のフォーリンエージェント（ＦＡ）が、リンクで隣接し、サブネットで隣接し、又はネットワークカバレッジエリアで隣接するフォーリンエージェント（ＦＡ）となることを特徴とする方法。
3. 請求項１の方法において、前記ステップＣにおいて、前記モバイルノード（ＭＮ）が前記ケア・オブ・アドレスとしてフォーリンエージェント・ケア・オブ・アドレス（ＦＡＣｏＡ）を用いるときは、該フォーリンエージェント・ケア・オブ・アドレス（ＦＡＣｏＡ）は、該モバイルノード（ＭＮ）を現在サービングしているフォーリンエージェント（ＦＡ）のアドレス、又は前記フォーリンエージェントグループ（ＦＡＧ）に対して構成されたエニーキャストアドレス（ＡＡ）であり、前記モバイルノード（ＭＮ）が前記ケア・オブ・アドレスとして同位置ケア・オブ・アドレス（ＣｏＣｏＡ）を用いるときは、前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリア内の該同位置ケア・オブ・アドレス（ＣｏＣｏＡ）がそれに対して構成されることを特徴とする方法。
4. 請求項１の方法において、前記ステップＣにおいて、前記フォーリンエージェント（ＦＡ）が、前記モバイルノード（ＭＮ）のホームアドレス（ＨｏＡ）又は同位置ケア・オブ・アドレス（ＣｏＣｏＡ）によって、前記モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るのかどうかを決定することを特徴とする方法。
5. 請求項１の方法において、前記ステップＤにおいて、前記フォーリンエージェント（ＦＡ）が前記モバイルノード（ＭＮ）情報を更新し、自身を該モバイルノード（ＭＮ）を現在サービングしているフォーリンエージェント（ＦＡ）として示すことを特徴とする方法。
6. 請求項１の方法において、前記ステップＡにおいて、前記フォーリンエージェントグループ（ＦＡＧ）のフォーリンエージェント（ＦＡ）メンバーの一部が、前記共有されたモバイルノード（ＭＮ）情報を分散及び保持する責任を担う転送用協働的フォーリンエージェント（ＦＡ）として選択され、又は前記共有されたモバイルノード（ＭＮ）情報を分散及び保持するとともにデータパケットを転送するために専用の転送用協働的フォーリンエージェント（ＦＡ）が前記フォーリンエージェントグループ（ＦＡＧ）内に設定されることを特徴とする方法。
7. 請求項６の方法において、前記ステップＡにおいて、前記専用の転送用協働的フォーリネージェント（ＦＡ）が、前記ホームエージェント（ＨＡ）から前記フォーリンエージェントグループ（ＦＡＧ）のフォーリンエージェント（ＦＡ）メンバーへの主経路において設定されることを特徴とする方法。
8. ＩＰｖ４においてモバイルノード（ＭＮ）をホームエージェント（ＨＡ）に登録するためのフォーリンエージェントグループ（ＦＡＧ）であって、該ＩＰｖ４が少なくとも１つのモバイルノード（ＭＮ）及びホームエージェント（ＨＡ）を備え、さらに少なくとも２つのフォーリンエージェント（ＦＡ）を備え、
   前記フォーリンエージェント（ＦＡ）の少なくとも２つがフォーリンエージェントグループ（ＦＡＧ）を形成するよう適合され、該フォーリンエージェントグループ（ＦＡＧ）のフォーリンエージェント（ＦＡ）メンバーがフォーリンエージェントグループ（ＦＡＧ）カバレッジエリアにローミングしていくモバイルノード（ＭＮ）の情報を共有するよう適合され、
   前記フォーリンエージェントグループ（ＦＡＧ）の前記フォーリンエージェント（ＦＡ）が、
   前記フォーリンエージェントグループ（ＦＡＧ）の他のフォーリンエージェント（ＦＡ）から共有情報を取得するよう適合された共有情報取得手段を備え、前記フォーリンエージェントグループ（ＦＡＧ）の前記フォーリンエージェント（ＦＡ）は、前記モバイルノード（ＭＮ）の情報を維持するためにビジター情報テーブル（ＶＩＴ）を維持し、前記ビジター情報テーブル（ＶＩＴ）が、前記フォーリンエージェントグループ（ＦＡＧ）の各フォーリンエージェント（ＦＡ）メンバーにおいてＩＰｖ４プロトコルの登録処理によって生成され、前記ビジター情報テーブル（ＶＩＴ）は、モバイルノード（ＭＮ）のホームアドレス（ＨｏＡ）、ホームエージェント（ＨＡ）アドレス、現在のフォーリンエージェント（ＦＡ）、即ち、カレントフォーリンエージェント（ＣＦＡ）のアドレス、及び現在の登録の存続時間に関する情報を含み、前記カレントフォーリンエージェント（ＣＦＡ）は、どのフォーリンエージェント（ＦＡ）が前記モバイルノード（ＭＮ）へサービスを現在提供しているかを示すものであり、
   ケア・オブ・アドレスを前記ホームエージェント（ＨＡ）に登録する前記モバイルノード（ＭＮ）の登録リクエストが受信されると、前記共有された情報によって、該モバイルノード（ＭＮ）が該フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るのかどうかを決定するよう適合された決定管理手段、及び
   前記モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るものと前記決定管理手段が決定した場合は、前記登録リクエストを前記ホームエージェント（ＨＡ）に転送し、そうでない場合は、登録レスポンスを該モバイルノード（ＭＮ）に直接送信するよう適合された登録処理手段を備える、フォーリンエージェントグループ（ＦＡＧ）。
9. 請求項８のフォーリンエージェントグループ（ＦＡＧ）において、前記決定管理手段は、前記モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに入るのが初めてではないものと決定したときは、自身を、モバイルノード（ＭＮ）を現在サービングしているフォーリンエージェント（ＦＡ）として示すよう適合されることを特徴とするフォーリンエージェントグループＦＡＧ。
10. 請求項８のフォーリンエージェントグループ（ＦＡＧ）において、前記フォーリンエージェント（ＦＡ）の前記決定管理手段が、エニーキャストアドレス（ＡＡ）又は前記フォーリンエージェント（ＦＡ）のアドレスとしてエージェント広告における移動エージェント広告拡張にケア・オブ・アドレスを設定するよう適合され、又は前記モバイルノード（ＭＮ）に対して前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリア内の同位置ケア・オブ・アドレス（ＣｏＣｏＡ）を該ケア・オブ・アドレスとして構成するよう適合されることを特徴とするフォーリンエージェントグループＦＡＧ。
11. 請求項８のフォーリンエージェントグループ（ＦＡＧ）において、前記フォーリンエージェントグループ（ＦＡＧ）のフォーリンエージェント（ＦＡ）の一部が、前記決定管理手段が前記共有モバイルノード（ＭＮ）情報を分散及び保持する責任を担うよう適合された転送用協働的フォーリンエージェント（ＦＡ）として設定されるよう適合され、前記共有モバイルノード（ＭＮ）情報を分散及び保持するとともにデータパケットを転送するよう適合するために専用の転送用協働的フォーリンエージェント（ＦＡ）が前記フォーリンエージェントグループ（ＦＡＧ）に設定されることを特徴とするフォーリンエージェントグループ（ＦＡＧ）。
12. ＩＰｖ４においてモバイルノード（ＭＮ）をホームエージェント（ＨＡ）に登録するためのフォーリンエージェント（ＦＡ）であって、該ＩＰｖ４が少なくとも１つのモバイルノード（ＭＮ）及びホームエージェント（ＨＡ）を備え、さらに少なくとも２つのフォーリンエージェント（ＦＡ）を備え、該フォーリンエージェント（ＦＡ）が、
    前記フォーリンエージェントグループ（ＦＡＧ）の他のフォーリンエージェント（ＦＡ）から共有情報を取得する共有情報取得手段を備え、前記フォーリンエージェントグループ（ＦＡＧ）の前記フォーリンエージェント（ＦＡ）は、前記モバイルノード（ＭＮ）の情報を維持するためにビジター情報テーブル（ＶＩＴ）を維持し、前記ビジター情報テーブル（ＶＩＴ）が、前記フォーリンエージェントグループ（ＦＡＧ）の各フォーリンエージェント（ＦＡ）メンバーにおいてＩＰｖ４プロトコルの登録処理によって生成され、ビジター情報テーブル（ＶＩＴ）は、モバイルノード（ＭＮ）のホームアドレス（ＨｏＡ）、ホームエージェント（ＨＡ）アドレス、現在のフォーリンエージェント（ＦＡ）、即ち、カレントフォーリンエージェント（ＣＦＡ）のアドレス、及び現在の登録の存続時間に関する情報を含み、前記カレントフォーリンエージェント（ＣＦＡ）は、どのフォーリンエージェント（ＦＡ）がモバイルノードへサービスを現在提供しているかを示すものであり、さらに、
    ケア・オブ・アドレスを前記ホームエージェント（ＨＡ）に登録する前記モバイルノード（ＭＮ）の登録リクエストが受信されると、前記共有された情報によって、該モバイルノード（ＭＮ）がフォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るのかどうかを決定する決定管理手段、および、
    前記モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るものと前記決定管理手段が決定した場合は、前記登録リクエストを前記ホームエージェント（ＨＡ）に転送し、そうでない場合には登録レスポンスを該モバイルノード（ＭＮ）に直接送信する登録処理手段を備える、フォーリンエージェント（ＦＡ）。
13. ＩＰｖ４においてモバイルノード（ＭＮ）のホームエージェント（ＨＡ）への登録を扱うためのコンピュータプログラムであって、該ＩＰｖ４が少なくとも１つのモバイルノード（ＭＮ）及びホームエージェント（ＨＡ）を備え、さらに少なくとも２つのフォーリンエージェント（ＦＡ）を備え、
    少なくとも２つのフォーリンエージェント（ＦＡ）をグルーピングしてフォーリンエージェントグループ（ＦＡＧ）を形成するための命令、
    前記フォーリンエージェントグループ（ＦＡＧ）のフォーリンエージェント（ＦＡ）メンバーがフォーリンエージェントグループ（ＦＡＧ）カバレッジエリアにローミングしていく前記モバイルノード（ＭＮ）の情報を共有するための命令を備え、前記フォーリンエージェントグループ（ＦＡＧ）の前記フォーリンエージェント（ＦＡ）は、前記モバイルノード（ＭＮ）の情報を維持するためにビジター情報テーブル（ＶＩＴ）を維持し、前記ビジター情報テーブル（ＶＩＴ）が、前記フォーリンエージェントグループ（ＦＡＧ）の各フォーリンエージェント（ＦＡ）メンバーにおいてＩＰｖ４プロトコルの登録処理によって生成され、前記ビジター情報テーブル（ＶＩＴ）は、モバイルノード（ＭＮ）のホームアドレス（ＨｏＡ）、ホームエージェント（ＨＡ）アドレス、現在のフォーリンエージェント（ＦＡ）、即ち、カレントフォーリンエージェント（ＣＦＡ）のアドレス、及び現在の登録の存続時間に関する情報を含み、前記カレントフォーリンエージェント（ＣＦＡ）は、どのフォーリンエージェント（ＦＡ）がモバイルノードへサービスを現在提供しているかを示すものであり、さらに、
    前記フォーリンエージェントグループ（ＦＡＧ）のいずれか１つのフォーリンエージェント（ＦＡ）が、モバイルノード（ＭＮ）によって送信されたケア・オブ・アドレスを前記ホームエージェント（ＨＡ）に登録するための登録リクエストを受信すると、前記共有されたモバイルノード（ＭＮ）情報によって、該モバイルノード（ＭＮ）が該フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入るのかどうかを決定する命令、および、
    前記モバイルノード（ＭＮ）が前記フォーリンエージェントグループ（ＦＡＧ）カバレッジエリアに初めて入る場合は、前記フォーリンエージェント（ＦＡ）が前記受信された登録リクエストを前記ホームエージェント（ＨＡ）に転送し、そうでない場合は、登録レスポンスを該モバイルノード（ＭＮ）に直接送信するための命令を備える、コンピュータプログラム。