JP4330034B2 - 改良型マイクロ移動性管理 - Google Patents

Description

３５ Ｕ．Ｓ．Ｃ．Ｓ．１１９（ｅ）及び３７ Ｃ．Ｆ．Ｒ．Ｓ．１．７８に基づく優先権ステートメント。
この特許出願は、ワシム ハダド（Ｗａｓｓｉｍ Ｈａｄｄａｄ）の名の下に、２００５年３月７日に出願された出願番号６０／６５８，５６７号「最適化されたマイクロ移動性管理（ＯＭＭ）」の先の米国仮特許出願に基づく優先権を主張するものである。

本発明は、モバイルインターネットプロトコルバージョン６（モバイルＩＰｖ６）に関し、特に、モバイルＩＰｖ６におけるハンドオーバー性能を高めることによって移動性の管理を最適化することに関する。

モバイルＩＰバージョン４（モバイルＩＰｖ４、モバイルＩＰ、ＭＩＰｖ４またはＭＩＰ）とモバイルＩＰｖ６の最新版（ＭＩＰｖ６）は、ホストまたはモバイルノード（ＭＮ；Ｍｏｂｉｌｅ
Ｎｏｄｅ）に移動性を提供するために構築される。通常（ＣＮ）として対応ノード（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ Ｎｏｄｅ）と呼ばれる他のノードは、通常固定されたホストとして考えられる。ここで、図１を参照して、図１は、インターネットエンジニアリングタスクフォース（ＩＥＴＦ；Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）Ｎｏ．３７７５（参考文献によってここに含まれる）にみられる現在のＭＩＰｖ６の仕様で示されるような、ＭＩＰｖ６ネットワークアーキテクチャを示している。図１に見られるように、ＩＰネットワーク１００は、リンク１２２上でＣＮ１２０と通信するＭＮ１１０を備える。リンク１２２は、１つの直接的な物理接続だけで構成される可能性は低いが、むしろ、その間での通信を透過的に可能にするルーティング機器の間の一連のリンクを表している。その間のＩＰコミュニケーションが確立できる限り、一連のリンクがＭＮ１１０とＣＮ１２０との間のトラフィックを伝送するために用いられる方法は重要ではない。

ＭＮ１１０は、ホームネットワーク１２７で有効なホームアドレスを永久に割り当てられる。ホームアドレスは、ホームネットワーク１２７においてＭＮ１１０を初期化するときに割り当てられる。ＭＮ１１０は、さらに、ホームネットワーク１２７内に位置するホームエージェント（ＨＡ；Ｈｏｍｅ Ａｇｅｎｔ）１３０と通信を行う。その他の機能の中で、ＨＡ１３０は、ホームネットワーク１２７の外部で有効なＭＮ１１０の外部アドレスを記録している。外部アドレスは、ＭＩＰｖ６のコンテクストにおいて気付アドレス（ＣｏＡ；Ｃａｒｅ−ｏｆ−Ａｄｄｒｅｓｓ）と呼ばれる。ＭＮ１１０に割り当てられたＣｏＡは、ＭＮ１１０が１つのネットワークから別のネットワークに移動するにつれて時間内に変化する。ＨＡ１３０によって保持されている記録は、ＭＩＰｖ６のコンテクストにおいてバインディング（ｂｉｎｄｉｎｇ）と呼ばれ、ＣｏＡをホームアドレスに結びつける。また、ホームアドレスとＣｏＡとの間のバインディングは、ＭＮ１１０に到達するためにＣＮ１２０に保持される。ＨＡ１３０もまた、ＭＮ１１０へのホームアドレスで受信されたトラフィックのルーティングに対する責任を負う。受信されたトラフィックは、リンク１２５上のＨＡ１３０によってＭＮ１１０に向けて転送される。

ＨＡ１３０、及びＨＡ１３０とＭＮ１１０との間のリンク１２５上の圧力を減少させるために、階層的なモバイルＩＰｖ６の移動性管理（ＨＭＩＰｖ６；Ｈｉｅｒａｒｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６）が開発された。ＨＭＩＰｖ６プロトコルの最新の公的に利用可能なバージョンは、ＩＥＴＦのインターネットドラフト<draft-ietf-mipshop-hmipv6-04.txt>（参考文献によってここに含まれる）によって定められ、また、以下ではＨＭＩＰｖ６仕様と呼ばれる。

図２は、ＨＭＩＰｖ６仕様により定められたＨＭＩＰｖ６ネットワークアーキテクチャを示している。最も単純な表現では、ＨＭＩＰｖ６の基本方針は、ＨＭＩＰｖ６ドメイン１１０’によって図１のＭＮ１１０を置き換えることである。その結果、ＨＡ１３０で維持されるバインディングを更新する必要性が減少する。そのために、ＨＭＰｖ６ドメイン１１０’は、モバイルアンカーポイント（ＭＡＰ；Ｍｏｂｉｌｅ Ａｎｃｈｏｒ Ｐｏｉｎｔ）２１０を備える。ＭＡＰ２１０は、ＭＩＰｖ６ドメイン１１０’内のローカルホームエージェントと考えることができる。図２の例示のために、ＭＡＰ２１０は、中間ルータＩＲ１ ２２０に接続され、中間ルータＩＲ１ ２２０は中間ルータＩＲ２ ２２２及び中間ルータＩＲ３ ２２４に順番に接続する。アクセスルータＡＲ１ ２３０は、ＩＲ２ ２２２に接続される。アクセスルータＡＲ２ ２３２とアクセスルータＡＲ３ ２３４は、ともにＩＲ３ ２２４に接続される。様々なリンク２４０は、ＨＭＰｖ６ドメイン１１０’のノード間に情報を送信するために用いられる。いくつかのさらなるリンク２４２も存在することができるが、（リンク２４２の破線矢印によって示されるように）ＨＭＩＰｖ６の仕様では定められておらず、使用されてもいない。リンク２４０及び２４２は、通常有線のリンクである。また、ＭＡＰ２１０は、破線矢印２４４によって示されるように、さらなる中間ルータ及びアクセスルータに接続されることができる。ＭＡＰ２１０は、ＨＭＩＰｖ６ドメイン１１０’のエントリーポイントであり、そういうものとしてＭＮ１１０の代わりに図１のリンク１２５に接続されるであろう。また、図２は、第１の位置ＡでＨＭＩＰｖ６ドメイン１１０’に入り、位置Ｂ及びＣに沿って移動するＭＮ１１２を示す。ＭＮ１１２は、位置Ａの近くにある間はリンク２５０を経由してＡＲ１ ２３０に接続され、位置Ｂの近くにある間はリンク２５２を経由してＡＲ２ ２３２に接続され、位置Ｃの近くにある間はリンク２５４を経由してＡＲ３ ２３４に接続される。例示のため、ＭＮ１１２は位置Ｂの近くにあるが、全てのリンクを図示している。リンク２５０〜２５４は、通常有線のリンクである。

図３は、ＭＮ１１２がＨＭＩＰｖ６ドメイン１１０’に入るとき（ステップ３１０）のＭＮ１１２とＨＭＩＰｖ６ドメイン１１０’の他のノードとの間で行われる動作及び作用についてのノードの動作及びフローチャートを示す。３１０の後すぐに、ＭＮ１１２は、ＭＡＰ２１０とＲｔＡｄｖの送付者の情報を含むルータ通知（ＲｔＡｄｖ）３１４を受信する。ＲｔＡｄｖメッセージは、定期的にＨＭＩＰｖ６ドメイン１１０’の各アクセスルータによって送信される。また、ＲｔＡｄｖメッセージが受信されないか、あるいは、ＭＮ１１２の構成からみた予定時刻にそれが受信されない場合、ＭＮ１１２は、任意のルータ要請（ＲｔＳｏｌ）３１２を通じて能動的にＲｔＡｄｖ３１４を要求することもできる。ＲｔＳｏｌ３１２は、マルチキャストアドレスと、適切なＲｔＡｄｖに応答して受信するアクセスルータ（例えば、ＡＲ１ ２３０及びＡＲ２ ２３２）に送信されるメッセージである。ＡＲ１ ２３０からＲｔＡｄｖ３１４を受信すると、ＭＮ１１２は、局所気付アドレス（ＬＣｏＡ；Ｌｏｃａｌ Ｃａｒｅ−ｏｆ−Ａｄｄｒｅｓｓ）、地域気付アドレス（ＲＣｏＡ；Ｒｅｇｉｏｎａｌ Ｃａｒｅ−ｏｆ
Ａｄｄｒｅｓｓ）を構成し（ステップ３１６）、アドレスがＨＭＩＰｖ６ドメイン１１０’で既に使用されていないことを確認するために、そのＬＣｏＡで二重アドレス検出（ＤＡＤ；Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）を実行する。一般的なＨＭＩＰｖ６の実装において、ＬＣｏＡのための一般的なＤＡＤ３１６の手続きが２０００ｍｓ以上かかることは、既に実験を通して確定されている。ＬＣｏＡは、ＡＲ１ ２３０の下で有効である。ＨＭＩＰｖ６の仕様によると、ＬＣｏＡは、ＡＲ１ ２３０のサブネットプリフィックス（ｓｕｂｎｅｔ ｐｒｅｆｉｘ）（ＲｔＡｄｖ３１４内で取得される）の最初の６４ビットと、ＭＮ１１２によって提供される別の６４ビットの値とを連結したものである。ＲＣｏＡは、ＭＡＰ２１０の下で有効である。ＨＭＩＰｖ６の仕様によると、ＲＣｏＡは、ＭＡＰ２１０のサブネットプリフィックス（ＲｔＡｄｖ内で取得される）の最初の６４ビットと、ＭＮ１１２によって提供される別の６４ビットの値とを連結したものである。

ステップ３１６の後、ＭＮ１１２は、ＭＡＰ２１０宛の局所バインディング更新（ＬＢＵ；Ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）３１８を送信することによって、ＭＡＰ２１０の新たに構成されたＬＣｏＡ及びＲＣｏＡをＭＡＰ２１０に通知する。ＬＢＵ３１８は、途中のルータによってＨＭＩＰｖ６トポロジーに沿って転送され、ＭＡＰ２１０まで適切なリンク２４０を辿る。ＨＭＩＰｖ６の仕様で定められたように、ＭＡＰ２１０は、その後、その責任において他のいかなるものもＭＮ１１２によって提示されたＲＣｏＡを現在使用していないことを確認するために、ＤＡＤを実行する（ステップ３２０）。一般的なＨＭＩＰｖ６の実装において、一つのＲＣｏＡのための一般的なＤＡＤ３２０の手続きが２０〜３０ｍｓ以上かかることは、既に実験を通して確定されている。ＤＡＤ３２０が肯定的（ｐｏｓｉｔｉｖｅ）である場合（即ち、ＲＣｏＡ及びＬＣｏＡが既に使用中である場合）、ＭＡＰ２１０は、局所バインディングにＲＣｏＡ及びＬＣｏＡを登録し、ＨＡ１３０とともにＲＣｏＡを登録するために適切な段階を(即ち、ＨＡ１３０に対するＢＵ、図３には図示せず）とる。局所バインディングを確認するために、ＭＡＰ２１０は、さらにＭＮのＬＣｏＡ宛の局所バインディング受信確認（ＬＢＡ；Ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を送信する。その後、ＭＡＰ２１０は、局所ＨＡとして動作し、ＭＮ１１２の代わりにＲＣｏＡ宛の全てのパケットを受信し、要約し、直接ＭＮ１１２のＬＣｏＡに転送する。これは、図３上で「トラフィック」３２４として太線の矢印で示されている。

ＨＭＩＰｖ６仕様によると、ＭＮ１１２がＢに向かって移動するとき（ステップ３３０）、ＭＮ１１２は、ＡＲ１ ２３０からＡＲ２ ２３２にハンドオーバーする必要がある。例えば、リンク２５０〜２５４が無線であるところでは、ＨＭＩＰｖ６の仕様は、ＭＮ１１２がハンドオーバー手続きが開始されたネットワークを初期化またはネットワークに応答すべき時期を決定するための閾値を厳密には提供しない。しかしながら、ＭＮ１１２とＡＲ１ ２３０との間の無線通信品質の測定値を判断基準として用いることができる。ＭＮ１１２によってハンドオーバーが開始されたら、ＲｔＡｄｖ３３４を受信したものに対してＲｔＳｏｌ３３２が送信される。ＲｔＡｄｖ３３４は、それがＲｔＳｏｌ３３２に応答して送信されない場合、ハンドオーバー手続きが開始されたネットワークの最初のメッセージであるかもしれないが、ＭＮ１１２は、いつ新たに構成されたＬＣｏＡ２（ステップ３３６）を選択して実際のＬＣｏＡを取り下げるかについての最終決定権を常に有する。その時に、ＨＭＩＰｖ６仕様で定められたＭＮ１１２は、ＬＣｏＡ２が既に使用されていないことを確認するためにＤＡＤを実行する（再び、＋２０００ｍｓ）。ＬＣｏＡ２は、ＡＲ２ ２３２の下で有効である。ＨＭＩＰｖ６仕様によると、ＬＣｏＡ２は、ＡＲ２ ２３２のサブネットプリフィックス（ＲｔＡｄｖ３３４内で取得される）の最初の６４ビットとＭＮ１１２によって提供された別の６４ビットの値とを連結したものである。

ステップ３３６の後、ＭＮ１１２は、ＭＡＰ２１０宛の局所バインディング更新（ＬＢＵ；Ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）３３８を送信することによって、新たに構成されたＬＣｏＡ２をＭＡＰ２１０に通知する。ＬＢＵ３３８は、適切なリンク２４０を辿り、途中にあるルータによってＨＭＩＰｖ６トポロジーに沿ってＭＡＰ２１０まで転送される。その後、ＭＡＰ２１０は、ＬＣｏＡに置き換えて局所バインディングにＬＣｏＡ２を登録する。ＲＣｏＡは変化していないので、この時点でのＨＡ１３０の更新は全く必要ない。局所バインディングを確認するために、ＭＡＰ２１０はさらに、ＭＮ１１２のＬＣｏＡ２宛に局所バインディング受信確認（ＬＢＡ；Ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）３４２を送信する。その後、ＭＡＰ２１０は、局所ＨＡとして動作し、ＭＮ１１２の代わりにＲＣｏＡ宛の全てのパケットを受信し、カプセル化し、ＭＮ１１２のＬＣｏＡ２に直接それらを転送する。これは、図３上に「トラフィック」３４４として太線の矢印で示されている。

ＡＲ１ ２２０との接続が切断された時点で、トラフィックはＭＮ１１２に到達するのを中断するため、ハンドオーバーがＭＮ１１２によっていつ開始され、またはいつ受理されるべきであるかの決定は重要である。ハンドオーバー手続き（ＭＡＰ２１０とＭＮ１１２との間の転送時間に加えられるステップ３３６のＤＡＤ手続きのためだけの２０００ｍｓ）により生じる遅延を考慮すると、予想された一般的なＨＭＩＰｖ６の実装において、提示された解決策が実行可能でないことがと容易に予測できる。会話の音声アプリケーションの場合、２５０ｍｓより長い遅延によりアプリケーションが実行不可能になるため、特に問題がある。

この問題を考慮した場合、高速ハンドオーバー手続きは、ＨＭＩＰｖ６のコンテクストで適用される場合、潜在的な解決策であると考えられた。高速ハンドオーバー手続きは、また参考文献によってここに含まれるＩＥＴＦのインターネットドラフト<draft-ietf-mipshop-fast-mipv6-02.txt>において、以下で高速ハンドオーバー仕様と呼ばれ、仕様が定められている。高速ハンドオーバー仕様の基本的特徴は、現在ＭＮ１１２に役立つＡＲ１ ２２０が、隣接しているアクセスルータの情報を送るのを可能にすることである。その結果、ＬＣｏＡ２をより高速に構成することが可能となる。ＨＭＩＰｖ６仕様は、その付録１において提案された高速ハンドオーバー仕様の適応を提供する。図３Ｂは、図３の既に開発された実施例のコンテキストにおける適応を提示する。

図３Ｂにおいて、Ｂに向かって移動するステップ３３０は、ＨＭＩＰｖ６仕様で変更された高速ハンドオーバーの出発点である。その後、ＭＮ１１２は、プロキシＲｔＳｏｌ（ＰｒＲｔＳｏｌ）３５２をＡＲ１に送る。ＡＲ１はそれに対して、プロキシＲｔＡｄｖ（ＰｒＲｔＡｄｖ）３５４と共にＡＲ２ ２３２の代わりに応答する。また、ＰｒＲｔＡｄｖ３５４は、ＡＲ１ ２３０から自発的に送信されることができたが、そのような事象のための閾値を指定しない。ＰｒＲｔＡｄｖ３５４が送信されるのとほぼ同時に、ＭＡＰ２１０は、ＡＲ１ ２３０からＡＲ２ ２３２に対してＭＮ１１２のためにハンドオーバーが行われる必要があると決定する（ステップ３５８）。残念ながら、ＭＡＰ２１０がどのようにしてそのような決定３５８を行うことができるかについての案内は、高速ハンドオーバー仕様、またはより適切には、ＨＭＩＰｖ６仕様において全く認識されていなかった。指定されたメカニズムがある場合、それはＭＡＰ２１０が決定３５８を行うのを可能にすることを認識できず、ＡＲ１ ２３０とＭＮ１１２との間の通信品質に関する情報を効率的に取得するために、ＭＡＰ２１０はＨＭＩＰｖ６トポロジーに配置されない。適切な瞬間に（即ち、ＰｒＲｔＡｄｖ３５４が送信されるのとほぼ同時に）どうにか決定３５８を行うことができたと仮定して、ＭＡＰは入って来るＭＮ１１２のノードを通知するためにＡＲ２に宛てられたハンドオーバー開始（ｈｉ；ｈａｎｄｏｖｅｒ ｉｎｉｔｉａｔｅ）を送信する。ハンドオーバーが実行されることができる場合、ＡＲ２は、さらに指定されたハンドオーバー受信確認（ｈａｃｋ；ｈａｎｄｏｖｅｒ ａｃｋｎｏｗｌｅｄｇｅ）３６２で応答する。もしｈａｃｋ３６２が肯定的（ｐｏｓｉｔｉｖｅ）である場合（即ち、ハンドオーバーが実行できる場合）、ＭＡＰ２１０は、それを受信した上で、ＬＣｏＡで受信されたトラフィックをＬＣｏＡ２に対して通過させる（ｔｕｎｎｅｌｉｎｇ）ことを開始する。これは、図３Ｂにおいて「トラフィック」３６４として太線の矢印で示されている。

ＰｒＲｔＡｄｖ３５４の受信後のあるポイントでは、ＭＮ１１２は、ＡＲ１ ２３０からＡＲ２ ２３２までのハンドオーバーを続けることを決定するはずである。しかしながら、この場合も同様に、閾値は全く指定されない。決定を行うときはいつも、ＭＮ１１２は、既に提示されたものに対し同様の方法で、ＡＲ２ ２３２のサブネットプリフィックス（今回は、ＲｔＡｄｖ３３４の代わりにＰｒＲｔＡｄｖ３５４から取得される）の最初の６４ビットとＭＮ１１２によって提供される他の６４ビットの値とを連結して、ＬＣｏＡ２を構成する（ステップ３５６）。ステップ３５６では、ＨＭＩＰｖ６仕様で指定されるＭＮ１１２は、ＬＣｏＡ２が既に使用中ではないことを確認するためにＤＡＤを実行する（ここでも＋２０００ｍｓ）。その後、ＭＮ１１２は、ＨＭＩＰｖ６トポロジーの中で高速局所バインディング更新（ＦＢＵ；Ｆａｓｔ ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）３６８をＭＡＰ２１０まで送信する。その後、ＭＡＰ２１０は、高速局所バインディング受信確認（ＦＢＡ；Ｆａｓｔ ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）３７２を送る前に、ＬＣｏＡとＬＣｏＡ２とを交換するために局所バインディングを更新する。

ＨＭＩＰｖ６の代替手段のコンテキストにおけるこの高速ハンドオーバーは、ＦＢＵ３６８とＦＢＡ３７２とを交換する前にトラフィック３６４を許容するという利点を有しているが、依然としてステップ３５６においてＬＣｏＡ２を有効にするためにＤＡＤを用いている（＋２０００ｍｓ）。ＬＣｏＡ２が有効でない場合、ハンドオーバーは適切に実行されず、状況は図３に示される不十分な手続きに戻ってしまう。しかしながら、図３Ｂに示された手続きには、ＭＮ１１２のハンドオーバーの決定（ステップ３５６）とハンドオーバーを開始するというＭＡＰ２１０の決定（ステップ３５８）との間の同期において別の問題がある。上述したように、ＡＲ１ ２３０からＡＲ２ ２３２へのＭＮ１１２のハンドオーバーの関連性をＭＡＰ２１０に知らせるのに必要なメカニズムは、ＨＭＩＰｖ６または高速ハンドオーバー仕様のいずれかで指定される場合、認識されなかった。さらに、ＭＡＰ２１０は、ＡＲ１ ２３０とＭＮ１１２との間の通信品質に関する情報を効率的に取得するためにＨＭＩＰｖ６トポロジーの中には配置されない。また、ＭＮ１１２に近づくようにＭＡＰ２１０を移動することは、そのようなＭＡＰ機能の利点を大幅に減少させる（即ち、ＨＡ１３０に向けての信号を発することを減少させる）であろう。

このように、ＨＭＩＰｖ６トポロジーとの互換性があり、会話音声アプリケーションやその他の時間に依存するアプリケーション等の様々なアプリケーションの要件をサポートするのに十分効果的なハンドオーバーの解決方法が必要である。

本発明の第１の側面は、モバイルインターネットプロトコルバージョン６（ＭＩＰｖ６）ネットワークにおいて、第１のアクセスルータ（ＡＲ１）から第２のアクセスルータ（ＡＲ２）へのモバイルノード（ＭＮ）のハンドオーバーの効率を向上させるための、仮想モバイルアンカーポイント（ＶＭＡＰ）を目的とするものであり、ＶＭＡＰは、階層的にモバイルアンカーポイント（ＭＡＰ）の下かつＡＲ１の上にあり、ＭＮは、ＭＡＰの下で有効な地域｛きょくち てき｝気付アドレス（ＲＣｏＡ；Ｒｅｇｉｏｎａｌ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ）と、ＡＲ１の下で有効な第１の局所気付アドレス（ＬＣｏＡ；Ｌｏｃａｌ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ）とを有し、ＶＭＡＰは、改良型マイクロ移動性管理（ＯＭＭ；ｉｍｐｒＯｖｅｄ Ｍｉｃｒｏ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）機能を備える。ＯＭＭ機能は、ＭＮ４１２がＡＲ２にハンドオーパーしていることをＶＭＡＰに通知するパス更新メッセージ（ＰａｔｈＵＭ；Ｐａｔｈ Ｕｐｄａｔｅ Ｍｅｓｓａｇｅ）を受信し、ＡＲ２の下で有効な第２の局所気付アドレス（ＬＣｏＡ２）を計算し、ＬＣｏＡで受信されたトラフィックをＬＣｏＡ２に転送することができる。

任意に、ＶＭＡＰは、少なくともＭＮのＲＣｏＡを備えるＭＮのためのＶＭＡＰバインディングキャッシュエントリ（ＶＢＣＥ；ＶＭＡＰ Ｂｉｎｄｉｎｇ Ｃａｃｈｅ Ｅｎｔｒｙ）と、ＭＮに関連付けられた固有値とを含むことができる。この場合、ＬＣｏＡ２の計算は、以下の関数を用いることによって実行される。

ＬＣｏＡ２＝ＭＮのＲＣｏＡ、ＭＮのＬＣｏＡ及びＭＮに関連付けられた固有値をハッシュ化することによって得られる６４ビットと連結された、ＡＲ２のサブネットプリフィックスに対応する最初の６４ビット

また、ＶＭＡＰのＯＭＭ機能はさらに、ＰａｔｈＵＭを受信する前に、ＬＣｏＡ宛のＭＡＰから発行される拡張局所バインディング受信確認（Ｅ−ＬＢＡ；Ｅｘｔｅｎｄｅｄ−Ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を受信し、Ｅ−ＬＢＡは、少なくともＭＮのＲＣｏＡ、ＭＮのＬＣｏＡ及びＭＮに関連付けられた固有値とを含み、ＭＮのためのＶＢＣＥが既に存在する場合、Ｅ−ＬＢＡに含まれる情報を用いてＭＮのためのＶＢＣＥを更新し、ＭＮのためのＶＢＣＥが存在しない場合、Ｅ−ＬＢＡに含まれる情報を用いてＭＮのためのＶＢＣＥを生成することもできる。

さらに、ＶＭＡＰのＯＭＭ機能は、さらにＡＲ２及びＭＮから成るグループの１つによって発行されたＰａｔｈＵＭを受信し、ＰａｔｈＵＭがＭＮから発行される場合、ＶＭＡＰに直接送信されたＰａｔｈＵＭからＡＲ２のサブネットプリフィックスに対応する最初の６４ビットを抽出し、ＰａｔｈＵＭがＡＲ２から発行される場合、ＬＣｏＡ宛のＰａｔｈＵＭのソースアドレス領域からＡＲ２のサブネットプリフィックスに対応する最初の６４ビットを抽出することもできる。

他の任意の実装では、ＶＭＡＰのＯＭＭ機能は、さらに、Ｅ−ＬＢＡの中のバインディング存続期間の値（Ｂｉｎｄｉｎｇ Ｌｉｆｅｔｉｍｅ ｖａｌｕｅ）を受信し、ＭＮのためのＶＢＣＥにバインディング存続期間の値を加え、バインディング存続期間の満了のときにＭＮのためのＶＢＣＥを除去することもできることを示唆している。

ＶＭＡＰのＯＭＭ機能は、さらに、第２のモバイルノード（ＭＮ２）からＭＮ２がＶＭＡＰにハンドオーバーを要求するための拡張ルータ要請（Ｅ−ＲｔＳｏｌ）を受信し、前のＬＣｏＡ（ＬＣｏＡ−ＭＮ２）宛のＰａｔｈＵＭを送信し、ルータ通知（ＲｔＡｄｖ）をＭＮ２に送信することもでき、Ｅ−ＲｔＳｏｌは、前のＬＣｏＡ（ＬＣｏＡ−ＭＮ２）を含む。

本発明の第２の側面は、モバイルインターネットプロトコルバージョン６（ＭＩＰｖ６）のネットワークにおいて、モバイルノード（ＭＮ）が第１のアクセスルータ（ＡＲ１）から第２のアクセスルータ（ＡＲ２）にハンドオーバーするための方法を目的とするものであって、仮想モバイルアンカーポイント（ＶＭＡＰ）は、階層的にモバイルアンカーポイント(ＭＡＰ)の下、かつＡＲ１の上にあり、ＭＮは、ＭＡＰの下で有効な地域｛きょくち てき｝気付アドレス（ＲＣｏＡ；Ｒｅｇｉｏｎａｌ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ）と、ＡＲ１の下で有効な第１の局所気付アドレス（ＬＣｏＡ；Ｌｏｃａｌ Ｃａｒｅ−ｏｆ Ａｄｄｒｅｓｓ）とを有する。上記方法は、ＶＭＡＰにおいて、ＭＮのための固有値と、ＬＣｏＡ宛の拡張局所バインディング受信確認（Ｅ−ＬＢＡ；Ｅｘｔｅｎｄｅｄ−Ｌｏｃａｌ Ｂｉｎｄｉｎｇ Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）の中のＭＮのＲＣｏＡとをＭＡＰから受信するステップと、ＭＮのためのＶＭＡＰバインディングキャッシュエントリを生成し、ＭＮのための固有値はＬＣｏＡ及びＲＣｏＡとともにＶＭＡＰにおいて保持されるステップと、ＭＮから拡張ルータ要請（Ｅ−ＲｔＳｏｌ）をＡＲ２に送信し、それによってＭＮのハンドオーバーをＡＲ２に要求し、Ｅ−ＲｔＳｏｌはＭＮのＬＣｏＡを含むステップと、ＡＲ２からルータ通知メッセージ（ＲｔＡｄｖ）をＭＮに送信するステップと、ＡＲ２からＭＮの第１のＬＣｏＡ宛にパス更新メッセージ（ＰａｔｈＵＭ）を送信するステップと、ＶＭＡＰにおいてＰａｔｈＵＭを受信するステップと、ＶＭＡＰにおいてＭＮの第２のＬＣｏＡ（ＬＣｏＡ２）を計算するステップと、ＶＭＡＰにおいてＬＣｏＡで受信されたトラフィックをＬＣｏＡ２に転送するステップと、を含む。

本発明の第３の側面は、モバイルインターネットプロトコルバージョン６（ＭＩＰｖ６）のネットワークにおいて、ＶＭＡＰが使用可能なＭＩＰｖ６のドメインにおいて有効な第１の局所気付アドレス（ＬＣｏＡ）を用いて第１のアクセスルータ（ＡＲ１）に接続されるモバイルノード（ＭＮ）を目的とするものであって、ＭＮは、ＭＮに関連付けられ、ＶＭＡＰが使用可能なドメインのモバイルアンカーポイント（ＭＡＰ）と共有される固有値を有し、ＭＮは、ＭＡＰの下で有効な地域｛きょくち てき｝気付アドレス（ＲＣｏＡ）を有する。ＭＮは、ＡＲ１から第２のアクセスルータ（ＡＲ２）へのハンドオーバーが必要であることを検知することが可能で、ＬＣｏＡを含むＡＲ２に拡張ルータ要請（Ｅ−ＲｔＳｏｌ）を送信し、ルータ通知（ＲｔＡｄｖ）をＡＲ２から受信し、ＡＲ２のサブネットプリフィックスに対応する６４ビットをＲｔＡｄｖから抽出し、ＡＲ２の下で有効な第２のＬＣｏＡ（ＬＣｏＡ２）を以下の関数を用いて計算する、改良型マイクロ移動性管理（ＯＭＭ）機能を備える。

ＬＣｏＡ２＝ＭＮのＲＣｏＡ、ＭＮのＬＣｏＡ及びＭＮに関連付けられた固有値を共にハッシュ化することによって得られる６４ビットと連結された、ＡＲ２のサブネットプリフィックスに対応する６４ビット

任意に、ＭＮのＯＭＭ機能はさらに、ＬＣｏＡ２を計算する前に、ＡＲ１宛のパス更新メッセージ（ＰａｔｈＵＭ）を送信することも可能であり、ＰａｔｈＵＭは、ＡＲ２のサブネットプリフィックスに対応する６４ビットを少なくとも含む。

さらに別のオプションは、ＭＮのＯＭＭ機能がさらに、ＬＣｏＡ２を計算した後、ＬＣｏＡ宛のパス更新メッセージ（ＰａｔｈＵＭ）を送信することが可能であり、ＰａｔｈＵＭがＡＲ２のサブネットプリフィックスに対応する６４ビットを少なくとも含むようにするためのものである。

本発明は、ＨＭＩＰｖ６との互換性のある、改良型マイクロ移動性管理のメカニズムを提供する。改良されたメカニズムは、新しいアクセスルータへの最初のアクセスルータとの間の通信のハンドオーバーを容易にするために既存のアドレス管理の手続きを利用する。そのため、仮想モバイルアンカーポイントの新しい機能は、ＭＡＰと比較してモバイルノード（ＭＮ）により近い状態で導入される。例えば、ＭＮは、最初のアドレスが有効な状態でそれに従って最初のアクセスルータに接続されることができる。ＶＭＡＰは、階層的に、最初のアクセスルータがＭＡＰとＭＮとの間で交換されたメッセージの軌跡を保つことに対し責任をもつ。ＶＭＡＰはさらに、新しいアクセスルータの下で有効なＭＮの新しいアドレスを計算し、ＭＮの新しいアドレスに対しＭＮの最初のアドレスで受信されたトラフィックを通過させる（ｔｕｎｎｅｌｉｎｇ）ことによって、新しいアクセスルータへのＭＮのハンドオーバーが確認されるとすぐに反応する。ＶＭＡＰにおけるハンドオーバーは、新しいアクセスルータまたは新しいアクセスルータの近くの第２のＶＭＡＰからのこの趣旨のメッセージの受信によって確認される。局所バインディング更新及び受信確認の手続きがＭＮとＭＡＰとの間で完了しているとき、新しいアドレスの利益のためにそれがＭＡＰレベルで廃棄されるので、ＶＭＡＰはＭＮの最初のアドレスにおけるトラフィックを受信するのを停止する。本発明はまた、それらのリンクの存在に縛られないが、場合によっては階層的な木のトポロジー（即ち、メッシュネットワーク）の外のルータとの間に存在するリンクを利用する。

図４は、本発明の教示にかかる改良型マイクロ移動性管理（ＯＭＭ）ドメイン４００と呼ばれるＨＭＩＰｖ６互換のドメインのネットワーク形態を示している。ＯＭＭドメイン４００のノードには異なる機能があるが、ＯＭＭドメイン４００の階層構造は、先に提示したＨＭＩＰｖ６ドメイン１１０’の階層構造と同様である。ＯＭＭドメイン４００は、モバイルアンカーポイント（ＭＡＰ）４１０を備える。ＭＡＰ４１０は、ＯＭＭドメイン４００におけるローカルホームエージェントとみなすことができる。図４に示す実施例の目的のために、ＭＡＰ４１０はＶＭＡＰ１ ４２０に接続され、そしてＶＭＡＰ１は、ＶＭＡＰ２ ４２２及びＶＭＡＰ３ ４２４に接続する。ＶＭＡＰアクセスルータＶＡＭＰ ＡＲ１ ４３０は、ＶＭＡＰ１ ４２０に接続される。ＶＭＡＰアクセスルータＶＭＡＰ ＡＲ２ ４３２及びアクセスルータＡＲ３ ４３４は、ともにＶＭＡＰ３ ４２４に接続される。様々なリンク２４０は、ＯＭＭドメイン４００のノード間に情報を送るのに用いられる。また、いくつかのさらなるリンク４４０が、ＯＭＭドメイン４００内の少なくともＶＭＡＰの同一階層レベル（ＡＲの視点からみて）の間に存在する。本発明は、後に示すように、いくつかのさらなるリンク４４２が存在する可能性を考慮に入れるが、それらが要因となって複雑度が増加するという観点から奨励されない。リンク２４０、４４０及び４４２は、通常有線のリンクである。また、ＭＡＰ４１０は、点線の矢印２４４によって示されるように、さらにルータに接続されることができる。ＭＡＰ４１０は、ＯＭＭ４００のエントリーポイントであり、ＭＮ１１０の代わりになるものとして図１のリンク１２５に接続される。また、図４は、第１の位置ＡにおいてＯＭＭドメインに入り、位置Ｂ及びＣに沿って移動するＭＮ４１２を示す。ＭＮ４１２は、位置Ａの付近にあるリンク２５０を経由してＶＭＡＰ ＡＲ１ ４３０に接続され、位置Ｂの付近にあるリンク２５２を経由してＶＭＡＰ ＡＲ２ ４３２に、位置Ｃの付近にあるリンク２５４を経由してＡＲ３ ４３４に接続される。説明のために、ＭＮ４１２は位置Ｂの近くにあるが、全てのリンクを表示している。リンク２５０〜２５４は、通常無線リンクである。

本発明では、後に明らかにされるように、ＯＭＭドメイン４００内の全てのＶＭＡＰが使用可能なルータは、それらの間で交換されたメッセージを認証できることが望ましい。これは、あらかじめ設定されたキーを用いることで実行できると思われるが、認証機能を提供する他のいかなるメカニズムでも使用することができる。さらに、ＭＮ４１２及びＭＡＰ４１０は、ともにＭＮ４１２に関連する同一の固有の値を提供することができると仮定する。これは、例えばＣＧＡ（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓ）メカニズム等の認証機関または他の手段を用いてあらかじめ確立された既存の秘密鍵（ＳｅｃｒｅｔＫｅｙ）のハッシュ値であることができる。秘密鍵は、ＯＭＭドメイン４００の他のノードでは利用できず、また利用可能にしてはいけないが、秘密鍵のハッシュ値を提供することにおいてはリスクは全くない（ハッシュ関数を経由して元の値は数学的に失われている）。以下の議論では、明確さのためだけに、ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）は、ＭＮ４１２に関連する固有値を代表するものとして用いられる。

図５は、ＭＮ４１２が位置ＡにおいてＯＭＭドメイン４００に入る（ステップ５１０）ときの、ＯＭＭドメイン４００のＭＮ４１２と他のノードとの間の動作及び作用についてのノードの動作及びフローチャートを示している。ステップ５１０の後すぐに、ＭＮ４１２は、ＭＡＰ４１０及びＥ−ＲｔＡｄｖの送信者に関する情報を含む拡張されたルータ通知（Ｅ−ＲｔＡｄｖ）を受信する。Ｅ−ＲｔＡｄｖ５１４には、さらに、ＯＭＭドメイン４００はＶＭＡＰが使用可能である（即ち、少なくとも１つのＶＭＡＰがＯＭＭドメイン４００内に存在する）ことを示す印を含む。その印は、標準のＲｔＡｄｖメッセージの中にフラグのビットを追加することによって実装されてもよい。

Ｅ−ＲｔＡｄｖメッセージは、ＯＭＭドメイン４００の各アクセスルータによって定期的に送信される。それが受信されないか、またはＭＮ１１２の構成から見た期限時間内に受信されない場合、ＭＮ４１２は、任意のルータ要請（ＲｔＳｏｌ）５１２を通じて能動的に要求することもできる。ＲｔＳｏｌ５１２は、マルチキャストアドレスに送信されたメッセージであり、受信するアクセスルータ（例えば、ＶＭＡＰ ＡＲ１ ４３０及びＶＭＡＰ ＡＲ２ ４３２）は適切なＥ−ＲｔＡｄｖに応答する。ＶＭＡＰ ＡＲ１ ４３０からＥ−ＲｔＡｄｖを受信すると（リンク２５０〜２５４が無線である場合に、ＡＲ１ ４３０のＥ−ＲｔＡｄｖ３１４が、１以上のＥ−ＲｔＡｄｖが受信された場合の最良のＥ−ＲｔＡｄｖメッセージであると仮定する。最良のＥ−ＲｔＡｄｖとは、Ｅ−ＲｔＡｄｖの伝播信号の品質がＭＮ４１２による評価において最も良い特性を有することを意味する。）、ＭＮ４１２は、局所気付アドレス（ＬＣｏＡ）、地域気付アドレス（ＲＣｏＡ）を構成する（ステップ５１６）。ＭＮ５１２は、ＬＣｏＡを構築するのに用いられる仕組みに応じて、そのアドレスがＯＭＭドメイン４００内で既に使用中でないことを確認するために、そのＬＣｏＡにおいて二重アドレス検出（ＤＡＤ；Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）を実行（ステップ５１７）しなければならないこともある。一般的なＨＭＩＰｖ６の実装におけるＬＣｏＡのための一般的なＤＡＤ５１７の手続きは２０００ｍｓ以上かかることが経験を通じて既に確定されているので、固有のサフィックス（ｓｕｆｆｉｘ）を用いるＬＣｏＡを構築することは有益である。ＬＣｏＡは、ＶＭＡＰ ＡＲ１ ４３０の下で有効である。ＨＭＩＰｖ６の仕様によると、ＬＣｏＡは、ＶＭＡＰ ＡＲ１ ４３０のサブネットプリフィックス（Ｅ−ＲｔＡｄｖ５１４内で取得される）の最初の６４ビットと、ＭＮ４１２によって提供される別の６４ビットの値との連結である。ＲＣｏＡは、ＭＡＰ４１０の下で有効である。上述したように、それは異なって好適に構築されることができるが、このことは本発明の範囲外に該当するものである。同様に、ＲＣｏＡを構築するために様々なメカニズムを用いることができる。ＲＣｏＡのためのメカニズムの１つは、ＭＡＰ４１０のサブネットプリフィックス（Ｅ−ＲｔＡｄｖ５１４内で取得される）最初の６４ビットとＭＮ４１２によって提供される別の６４ビットの値との連結である。

ステップ５１６の後、ＭＮ４１２は、ＭＡＰ４１０宛のローカルバインディングアップデート（ＬＢＵ）５１８を送信することによって、新たに構成されたＬＣｏＡ及びＲＣｏＡをＭＡＰ４１０に通知する。ＬＢＵ５１８は、途中のルータによってＨＭＩＰｖ６トポロジーに沿って転送され、ＭＡＰ４１０まで適切なリンク２４０を辿る。ＨＭＩＰｖ６の仕様によると、その後ＭＡＰ４１０は、その責任において他のいかなるものもＭＮ４１２によって提示されたＲＣｏＡを現在使用していないことを確認するために、ＤＡＤを実行（ステップ５２０）しなければならない。ＲＣｏＡを構築するために用いられたメカニズムによって、それは必要でないかもしれないので、ステップ５２０は、本発明のコンテキストにおいては任意であるとしてみなされる。ＭＡＰ４１０はその後、ローカルバインディングにＲＣｏＡ及びＬＣｏＡを登録し、ＨＡ１３０とともにＲＣｏＡを登録するための適切なステップ（即ち、ＨＡ１３０に対するＢＵ、図５には図示していない）をとる。ローカルバインディングを確認するために、ＭＡＰ５１０はさらに、ＭＮ４１２のＬＣｏＡ宛に拡張ローカルバインディング受信確認（Ｅ−ＬＢＡ）５２２を送信する。Ｅ−ＬＢＡ５２２は、合意されたハッシュ関数（例えば、ＭＤ５等）を用いて実行される秘密鍵のハッシュ値に対応する値を含む情報を通常の一番上に含む。Ｅ−ＬＢＡ５２２は、最良の実施例においては、バインディング存続期間及びＭＮ４１２のＲＣｏＡをさらに含む。これらの３つの値は、例えば、Ｅ−ＬＢＡ５２２の１つの付加的な領域に含むことができる。Ｅ−ＬＢＡ５２２にこの情報を含む理由は、本発明のハンドオーバー機能の説明を通して後に明らかにされる。Ｅ−ＬＢＡ５２２を受信する各ＶＭＡＰ（即ち、ＶＭＡＰ１ ４２０、ＶＭＡＰ２ ４２２及びＶＭＡＰ ＡＲ１ ４３０）は、以下の構造を有する仮想バインディングキャッシュエントリ（ＶＢＣＥ）を生成する。

・ＬＣｏＡ−ＲＣｏＡ−バインディング存続期間（提供された場合）−Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）

ＬＣｏＡは、Ｅ−ＬＢＡ５２２の目的地領域から特定される。その後、ＭＡＰ４１０は、ローカルＨＡとして動作し、ＭＮ４１２に代えてＲＣｏＡに宛てられた全てのパケットを受信し、カプセル化してＭＮ４１２のＬＣｏＡに直接それらを転送する。これは、図５において、「トラフィック」５２４として太線の矢印で示されている。

図６は、ＭＮ４１２がポイントＢに向かって移動するとき（ステップ５３０）の、ＯＭＭドメイン４００のＭＮ４１２と他のノードとの間の動作及び作用についてのノードの動作及びフローチャートを示している。この位置で、ＭＮ４１２は、ＶＭＡＰ ＡＲ１ ４３０からＶＭＡＰ ＡＲ２ ４３２にハンドオーバーする必要があることを検知する。リンク２５０〜２５４が無線の場合、ＭＮ４１２がハンドオーバー手続きを開始すべき時期を決定するための、本発明によって提供される厳密な閾値はない。しかしながら、ＭＮ４１２とＶＭＡＰ ＡＲ１ ４３０との間の無線通信品質の測定結果は、判断基準として用いられることができる。本発明では、ハンドオーバー手続きは、ＶＭＡＰ ＡＲ２ ４３２（即ち、新たなアクセスルータ）にＥ−ＲｔＳｏｌ５３２を送信することによってＭＮ４１２により開始される必要がある。Ｅ−ＲｔＳｏｌは、以下の値が追加されたＲｔＳｏｌメッセージの全ての情報を含む：ＬＣｏＡ（即ち、ＶＭＡＰ ＡＲ１ ４３０の下で有効なアドレス）、及び潜在的には、以下の関数に対応する値：Ｈａｓｈ［Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ］（即ち、ＬＣｏＡとハッシュ化された秘密鍵とのハッシュ値）。

Ｅ−ＲｔＳｏｌ５３２の受信後、ＶＭＡＰ ＡＲ２ ４３２は、ＲｔＡｄｖ５３４（または、Ｅ−ＲｔＡｄｖの可能性もある）を送信する。ＶＭＡＰ ＡＲ２ ４３２は、ＭＮ４１２がＥ−ＲｔＳｏｌ５３２の実際の送信源であることを証明しなければならない。さもなければ、メカニズムが危険にさらされる可能性がある。しかしながら、証明に関する仕様の詳細は、本発明の範囲外に該当する。ＲｔＡｄｖ５３４の受信後、ＭＮ４１２は、ＶＭＡＰ ＡＲ２ ４３２の下で有効なＬＣｏＡ２を以下の数式を用いて構成する（ステップ５３６）。

ＬＣｏＡ２＝Ｈａｓｈ［ＲＣｏＡ｜Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ］からの６４ビットに連結されたＲｔＡｄｖ５３４のソースアドレスの最初の６４ビット（即ち、ＶＭＡＰ ＡＲ２ ４３２のプリフィックス）

そのようなシナリオでは、ＬＣｏＡ２はＭＡＰ４１０によって既に検証されまたは提供された固有の情報のみを用いて取得されるという事実によって陳腐化されているので、ＬＣｏＡ２においてＤＡＤを実行する必要は全くない。ハッシュが一意の入力に対し一意の出力を提供することは、数学的に証明されている。

最良の実施例においては、Ｅ−ＲｔＳｏｌ５３２の受信後、ＶＭＡＰ ＡＲ２ ４３２は、ＬＣｏＡ宛のパス更新メッセージ（ＰａｔｈＵＭ）５３５を送信する。ＰａｔｈＵＭ５３５は、好ましくは、ＯＭＭドメイン４００のルータ間で利用可能な認証メカニズム（例えば、予め設定された鍵）を用いて署名される。ＰａｔｈＵＭ５３５は、階層化構造の外で送信され、可能であればリンク４４０を利用する。言い換えると、ＰａｔｈＵＭ５３５が宛てられたＬＣｏＡは、ＶＭＡＰ ＡＲ１ ４３０の責任下にあるので、ＰａｔｈＵＭ５３５は、ＶＭＡＰ ＡＲ２ ４３２からＶＭＡＰ ＡＲ１ ４３０に対し、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）のようなルーティングプロトコルを用いて最適化されたパス上に送信される。他の変形例は、ＬＣｏＡは依然としてＭＮ４１２によって使用されることができ、ＭＮ４１２からＶＭＡＰ ＡＲ１ ４３０にＰａｔｈＵＭ５３５’を送信するようにするものである。これは、潜在的により高価なエアインタフェースを使用するため、それほど効果的でない選択肢と考えられるが、ＰａｔｈＵＭ５３５’がＶＭＡＰ ＡＲ２ ４３２のサブネットプリフィックスをさらに含む限り、本発明の目的に対しては適切に動作する。

ＰａｔｈＵＭ５３５の受信後（または、付随的は５３５’）ＶＭＡＰ ＡＲ１ ４３０は、そのＶＢＣＥうちの一つにＬＣｏＡがあるかどうかをチェックする。既に導入されたものを呼び戻して、ＶＢＣＥは、対応するＬＣｏＡ、対応するＲＣｏＡ及び対応するハッシュ値（秘密鍵）、及び場合によってはバインディング存続期間をリストにし、ＰａｔｈＵＭ５３５または５３５’はＬＣｏＡを提供する。ＬＣｏＡがＶＢＣＥに存在する場合、ＶＭＡＰ ＡＲ１ ４３０は、もし使用されていればＰａｔｈＵＭ５３５の署名をチェックし、もし有効であればＭＮ４１２と同様の数式を用いてＬＣｏＡ２を計算する（ステップ５３７）。

ＬＣｏＡ２＝Ｈａｓｈ［ＲＣｏＡ｜Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ］からの６４ビットと連結されたＰａｔｈＵＭ５３５のソースアドレスまたはＰａｔｈＵＭ５３５’のコンテンツ（即ち、ＶＭＡＰ ＡＲ２ ４３２のプリフィックス）の最初の６４ビット

また、ＶＭＡＰ ＡＲ１ ４３０は、ＶＢＣＥからＲＣｏＡ及びハッシュ値（秘密鍵）を取得し、ＶＢＣＥのＬＣｏＡを用いて相互に関連付けられたＰａｔｈＵＭ５３５または５３５’からＬＣｏＡを取得する。その後、ＶＭＡＰ ＡＲ１ ４３０は、ＬＣｏＡ２を用いてＶＢＣＥを更新し、すぐにＬＣｏＡで受信されたパケットをＬＣｏＡ２に対して別のルートで送信し始める（ステップ５３７）。従って、ＶＭＡＰ ＡＲ１ ４３０は、ＬＣｏＡで受信したパケットをカプセル化し、利用可能であればリンク４４０（例えばＯＳＰＦを経由して）を用いてＭＮ１１２のＬＣｏＡ２に対し直接転送する。これは、図６において、「トラフィック」５４４として太線の矢印で示されている。

この時点で、ＭＮ４１２は、事実上ＶＭＡＰ ＡＲ２ ４３２の責任範囲下にある。ＬＣｏＡで受信されたトラフィックは、新たに構成されたＬＣｏＡ２に対して事実上転送される。唯一なくなったステップは、その結果としてＬＣｏＡ２の利益のために用いられるのを止めるためにＬＣｏＡがＭＡＰ４１０に通知することである。これは、以前と同様にＬＢＵ及びＥ−ＬＢＡを用いて行われる。２つのアクセスルータの間のピンポンが頻繁であるアクセスネットワークにおいて、この更新を遅延させることにおける利点がある可能性がある。いかなるトラフィックの損失も経験せず、本発明で提案されるハンドオーバーが非常に効率的であるので、本発明は、ＭＡＰ４１０のローカルバインディングの正式な更新を開始する前に、所定の遅延を導入することによって２つのアクセスルータ間でハンドオーバーを行うための真の必要性があることを保証するのに用いることができる。

ステップ５３６の後、ＭＮ４１２は、ＭＡＰ４１０宛てのＬＢＵ５３８を送ることによって、新たに構成されたＬＣｏＡ２のＭＡＰ４１０を通知することができる。ＬＢＵ５３８は、適切なリンク２４０を辿り、途中にあるルータによってＨＭＩＰｖ６トポロジーに沿ってＭＡＰ４１０まで転送される。その後、ＭＡＰ４１０は、ＬＣｏＡに置き換えてローカルバインディングにＬＣｏＡ２を登録する。ＲＣｏＡは変化していないので、この時点ではＨＡ１３０の更新は必要ない。ローカルバインディングを確認するために、ＭＡＰ２１０はさらに、ＭＮ４１２のＬＣｏＡ２宛てにＥ−ＬＢＡ５４２を送信する。その後、ＭＡＰ４１０がローカルＨＡとして動作し、ＭＮ４１２に代えてＲＣｏＡ宛の全てのパケットを受信し、カプセル化し、ＭＮ４１２のＬＣｏＡ２にそれらを直接転送する。この時点で、ＬＣｏＡはＭＡＰ４１０のレベルで使用を中止されるので、ＶＭＡＰ ＡＲ１ ４３０で構築された転送は使用を中止される。Ｅ−ＬＢＡ５４２は、前に提示されたＥ−ＬＢＡ５２２と同様に用いられ、従って、最良の実施例においては、バインディング存続期間及びＭＮ４１２のＲＣｏＡを含んでいる。Ｅ−ＬＢＡ５４２を受信する各ＶＭＡＰ（即ち、ＶＭＡＰ１ ４２０、ＶＭＡＰ３ ４２４及びＶＭＡＰ ＡＲ２ ４３２）は、仮想バインディングキャッシュエントリ（ＶＢＣＥ）を生成するか、または更新する（ステップ５４３）。

図７は、ＭＮ４１２がポイントＣに向かって移動するとき（ステップ７３０）のＯＭＭドメイン４００のＭＮ４１２と他のノードとの間の動作及び作用についてのノードの動作及びフローチャートを示している。この位置で、ＭＮ４１２は、ＶＭＡＰ ＡＲ２ ４３２からＡＲ３ ４３４へのハンドオーバーが必要であることを検知する。リンク２５０〜２５４が無線である場合、ＭＮ４１２がハンドオーバー手続きを開始すべき時期を決定するための、本発明で提供される厳密な閾値はない。しかしながら、ＭＮ４１２とＶＭＡＰ ＡＲ２ ４３２の間の無線通信品質の測定結果は、判断基準として用いられることができる。上述したように、ハンドオーバー手続きは、ＡＲ３ ４３４（即ち、新しいアクセスルータ）にＥ−ＲｔＳｏｌ７３２を送信することによって、ＭＮ４１２により開始される必要がある。Ｅ−ＲｔＳｏｌは、以下の値が追加されたＲｔＳｏｌメッセージの全ての情報を含んでいる：ＬＣｏＡ２（即ち、ＶＭＡＰ ＡＲ２ ４３２の下で有効なアドレス）、及び潜在的には、以下の関数に対応する値：Ｈａｓｈ［Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ２］（即ち、ＬＣｏＡ２とハッシュ化された秘密鍵とのハッシュ値）。Ｅ−ＲｔＳｏｌ７３２はさらに、Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）の値を用いて署名される（悪意を持つユーザからの誤ったハンドオーバーの開始を避けるため）。

Ｅ−ＲｔＳｏｌ７３２の受信後、ＡＲ３ ４３４は、ＲｔＡｄｖ７３４（または、潜在的にＥ−ＲｔＡｄｖ）を送信する。ＲｔＡｄｖ７３４の受信後、ＭＮ４１２は、以下の式を用いてＡＲ３ ４３４の下で有効なＬＣｏＡ３を構成する（ステップ７３６）。

ＬＣｏＡ３＝Ｈａｓｈ［ＲＣｏＡ｜Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ２］からの６４ビットに連結されたＲｔＡｄｖ４３４のソースアドレスの最初の６４ビット（即ち、ＡＲ３ ４３４のプリフィックス）

また、そのようなシナリオでは、ＬＣｏＡ３はＭＡＰ４１０によって既に検証されまたは提供された固有の情報のみを用いて取得されるという事実によって陳腐化されているので、ＬＣｏＡ３においてＤＡＤを実行する必要は全くない（ＤＡＤは、ここでは任意であり、推奨されない）。

最良の実施例においては、ＡＲ３ ４５４は、ＶＭＡＰの機能を有していないので、ＡＲ３ ４３４とＶＭＡＰ ＡＲ２ ３４２との間のリンク４４２は、存在しない（リンク４４２は、この時点では全く影響がないが、その効果は、図８を参照してさらによく理解される）。Ｅ−ＲｔＳｏｌ７３２の受信後、ＡＲ３ ４３４は、ＬＣｏＡ２宛のパス更新メッセージ（ＰａｔｈＵＭ）７３５を送信する。ＰａｔｈＵＭ７３５は、好ましくは、ＯＭＭドメイン４００のルータ間で利用可能な認証メカニズム（例えば、あらかじめ設定された鍵）を用いて署名される。最良の実施例では、ＰａｔｈＵＭ７３５は、階層構造の内側で送信され、従って、ＶＭＡＰ３ ４２４の近くを通る。リンク４４２が存在する場合、ＰａｔｈＵＭ７３５に一致するＰａｔｈＵＭ７３５’が直接リンク４４２の上に送信される。他の変形例は、ＬＣｏＡ２がまだＭＮ４１２によって使用できる間に、ＭＮ４１２からＶＭＡＰ ＡＲ２ ４３２にＰａｔｈＵＭ７３５”を送信することである。これは、潜在的により高価なエアインタフェースを使用するため、あまり効果的でない選択肢であると考えられるが、ＰａｔｈＵＭ７３５”がＡＲ３ ４３４のサブネットプリフィックスをさらに含む限り、本発明の目的のためには適切に動作する。さらなる他の変形例は、ＬＣｏＡ３を構成した後、ＭＮ４１２からＶＭＡＰ ＡＲ２ ４３２にＰａｔｈＵＭ７３５'''を送信することである。この場合、リンク４４２が存在するか存在しないかについて考慮する必要がある。これは、潜在的により高価なエアインタフェースを使用するため、あまり効果的でない選択肢であると考えられるが、ＰａｔｈＵＭ７３５'''がＡＲ３ ４３４のサブネットプリフィックスをさらに含む限り、本発明の目的のためには適切に動作する。

ＰａｔｈＵＭ７３５（７３５’、７３５”または７３５'''）の受信後、ＶＭＡＰ ＡＲ２ ４３２は、ＬＣｏＡ２がＶＢＣＥの１つにあるかどうかをチェックする。ＬＣｏＡ２がＶＢＣＥに存在する場合、ＶＭＡＰ ＡＲ２ ４３２は、もし使用されていれば、ＰａｔｈＵＭ７３５または７３５’の署名をチェックし、有効であれば、ＭＮ４１２と同じ式でＬＣｏＡ３を計算する（ステップ７３７）。

ＬＣｏＡ３＝Ｈａｓｈ［ＲＣｏＡ｜Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ２］からの６４ビットに連結された、ＰａｔｈＵＭ７３５または７３５’のソースアドレスまたはＰａｔｈＵＭ７３５”または７３５'''のコンテンツからの最初の６４ビット（即ち、ＡＲ３ ４３４のプリフィックス）

また、ＶＭＡＰ ＡＲ２ ４３２は、ＶＢＣＥのＬＣｏＡ２を用いることに関連して、ＶＢＣＥからＲＣｏＡ及びＨａｓｈ（ＳｅｃｒｅｔＫｅｙ）を、ＰａｔｈＵＭ７３５（７３５’、７３５”または７３５'''）からＬＣｏＡ２を取得する。その後、ＶＭＡＰ ＡＲ２ ４３２は、ＬＣｏＡ３を用いてＶＢＣＥを更新し、すぐに、ＬＣｏＡ２で受信されたパケットを別ルートでＬＣｏＡ３に送信し始める（ステップ７３７）。その結果、ＶＭＡＰ ＡＲ２ ４３２は、ＬＣｏＡ２で受信されたパケットをカプセル化し、リンク４４０（利用可能であるなら）及び潜在的に４４２（例えばＯＳＰＦを経由して）を用いてＭＮ１１２のＬＣｏＡ３に直接転送する。これは、図７上で「トラフィック」７４４として太線の矢印で示されている。

この時点で、ＭＮ４１２は、事実上ＡＲ３ ４３４の責任範囲下にある。ＬＣｏＡ２で受信されたトラフィックは、新たに構成されたＬＣｏＡ３に対して事実上転送される。唯一なくなったステップは、その結果としてＬＣｏＡ３の利益のために用いられるのを止めるためにＬＣｏＡ２がＭＡＰ４１０に通知することである。これは、以前と同様にＬＢＵ及びＥ−ＬＢＡを用いて行われる。

ステップ７３６の後、ＭＮ４１２は、ＭＡＰ４１０宛のＬＢＵ７３８を送ることによって、ＭＡＰ４１０の新たに構成されたＬＣｏＡ３をＭＡＰ４１０に通知することができる。ＬＢＵ７３８は、適切なリンク２４０を辿り、途中にあるルータによってＨＭＩＰｖ６トポロジーに沿ってＭＡＰ４１０まで転送される。その後、ＭＡＰ４１０は、ＬＣｏＡ２に置き換えてローカルバインディングにＬＣｏＡ３を登録する。ＲＣｏＡは変化していないので、この時点ではＨＡ１３０の更新は必要ない。ローカルバインディングを確認するために、ＭＡＰ２１０はさらに、ＭＮ４１２のＬＣｏＡ３宛にＥ−ＬＢＡ７４２を送信する。その後、ＭＡＰ４１０は、ローカルＨＡとして動作し、ＭＮ４１２に代えてＲＣｏＡ宛の全てのパケットを受信し、カプセル化し、ＭＮ４１２のＬＣｏＡ３に直接それらを転送する。この時点で、ＬＣｏＡ２は、ＭＡＰ４１０のレベルで使用を中止されるので、ＶＭＡＰ ＡＲ２ ４３２で構築された転送は使用を中止される。Ｅ−ＬＢＡ７４２は、前に提示されたＥ−ＬＢＡ５４２及び５２２と同様に用いられ、従って、最良の実施例においては、バインディング存続期間及びＭＮ４１２のＲＣｏＡを含んでいる。Ｅ−ＬＢＡ７４２を受信する各ＶＭＡＰ（即ち、ＶＭＡＰ１ ４２０及びＶＭＡＰ３ ４２４）は、仮想バインディングキャッシュエントリ（ＶＢＣＥ）を生成するか、または更新する（ステップ７４３）。

図８は、ＭＮ４１２がポイントＣからポイントＢに向かって戻るときのＯＭＭドメイン４００のＭＮ４１２と他のノードとの間の動作及び作用についてのノードの動作及びフローチャートを示している。この位置で、ＭＮ４１２は、ＡＲ３ ４３４からＶＭＡＰ ＡＲ２ ４３２へのハンドオーバーが必要であることを検知する。リンク２５０〜２５４が無線である場合、ＭＮ４１２がハンドオーバー手続きを開始すべき時期を決定するための、本発明で提供される厳密な閾値はない。しかしながら、ＭＮ４１２とＡＲ３ ４３４の間の無線通信品質の測定結果は、判断基準として用いられることができる。上述したように、ハンドオーバー手続きは、ＶＭＡＰ ＡＲ２ ４３２（即ち、新しいアクセスルータ）にＥ−ＲｔＳｏｌ８３２を送信することによって、ＭＮ４１２により開始される必要がある。Ｅ−ＲｔＳｏｌは、以下の値が追加されたＲｔＳｏｌメッセージの全ての情報を含んでいる：ＬＣｏＡ３（即ち、ＡＲ３ ４３４の下で有効なアドレス）、及び潜在的には、以下の関数に対応する値：Ｈａｓｈ［Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ３］（即ち、ＬＣｏＡ３とハッシュ化された秘密鍵とのハッシュ値）。Ｅ−ＲｔＳｏｌ８７２はさらに、Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）の値を用いて署名される（悪意を持つユーザからの誤ったハンドオーバーの開始を避けるため）。

Ｅ−ＲｔＳｏｌ８３２の受信後、ＶＭＡＰ ＡＲ２ ４３２は、図６及び７の他の実施例に示すような標準のＲｔＡｄｖ、または、本実施例のために、ＭＮ−ＲｔＡｄｖ８３４（潜在的には、Ｅ−ＲｔＡｄｖのＶＭＡＰフラグと共に）を送信する。ＭＮ−ＲｔＡｄｖは、階層的にＶＭＡＰ ＡＲ２ ４３２の上のＶＭＡＰであるものとして、ＶＭＡＰ３ ４２４のアドレスをさらに含む。ＭＮ−ＲｔＡｄｖ８３４の受信後、ＭＮ４１２は、以下の式を用いてＶＭＡＰ ＡＲ２ ４３２の下で有効なＬＣｏＡ４を構成する（ステップ８３６）。

ＬＣｏＡ４＝Ｈａｓｈ［ＲＣｏＡ｜Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ３］からの６４ビットに連結されたＲｔＡｄｖ８３４のソースアドレスの最初の６４ビット（即ち、ＶＭＡＰ ＡＲ２ ４３２のプリフィックス）

また、そのようなシナリオでは、ＬＣｏＡ４は、ＭＡＰ４１０によって既に検証されまたは提供された固有の情報のみを用いて取得されるという事実によって陳腐化されているので、ＬＣｏＡ４においてＤＡＤを実行する必要は全くない（ＤＡＤは、ここでは任意であり、推奨されない）。

最良の実施例においては、ＡＲ３ ４３４は、ＶＭＡＰの機能を有していないので、ＡＲ３ ４３４とＶＭＡＰ ＡＲ２ ３４２との間のリンク４４２は存在せず、Ｅ−ＲｔＳｏｌ８３２の受信後、ＶＭＡＰ４３２は、ＬＣｏＡ３宛のパス更新メッセージ（ＰａｔｈＵＭ）８３５を送信する。ＰａｔｈＵＭ８３５は、好ましくは、ＯＭＭドメイン４００のルータ間で利用可能な認証メカニズム（例えば、あらかじめ設定された鍵）を用いて署名される。最良の実施例では、ＰａｔｈＵＭ８３５は、階層構造の内側で送信され、ＶＭＡＰ３ ４２４に直接到達する。リンク４４２が存在する場合、ＰａｔｈＵＭ８３５に一致するＰａｔｈＵＭ８３５’が、ＡＲ３ ４３４に送信される。ＡＲ３ ４３４は、ＶＭＡＰ３ ４２４へさらにそれを転送する必要がある（ＡＲ３ ４３４はＶＭＡＰの機能を有していないので）。他の変形例は、ＬＣｏＡ３がまだＭＮ４１２によって使用できる間に、ＭＮ４１２からＶＭＡＰ３ ４２４にＰａｔｈＵＭ８３５”を送信することである。これは、潜在的により高価なエアインタフェースを使用するため、あまり効果的でない選択肢であると考えられるが、ＰａｔｈＵＭ８３５”がＶＭＡＰ ＡＲ２ ４３２のサブネットプリフィックスをさらに含む限り、本発明の目的のためには適切に動作する。さらなる他の変形例は、ＬＣｏＡ４を構成した後、ＭＮ４１２からＶＭＡＰ３ ４２４（ＭＮ−ＲｔＡｄｖ８３４に含まれるアドレス）にＰａｔｈＵＭ８３５'''を送信することである。メッセージはそれによってＶＭＡＰ３ ４２４に送信されるので、この場合、ＶＭＡＰ ＡＲ２ ４３２のプリフィックスは、除外することができる。これは、潜在的により高価なエアインタフェースを使用するため、あまり効果的でない選択肢であると考えられるが、本発明の目的のためには適切に動作する。

ＰａｔｈＵＭ８３５（８３５’、８３５”または８３５'''）の受信後、ＶＭＡＰ３ ４２４は、ＬＣｏＡ３がＶＢＣＥの１つにあるかどうかをチェックする。ＬＣｏＡ３がＶＢＣＥに存在する場合、ＶＭＡＰ３ ４２４は、もし使用されていれば、ＰａｔｈＵＭ８３５または８３５’の署名をチェックし、有効であれば、ＭＮ４１２と同じ式でＬＣｏＡ４を計算する（ステップ８３７）。

ＬＣｏＡ４＝Ｈａｓｈ［ＲＣｏＡ｜Ｈａｓｈ（ＳｅｃｒｅｔＫｅｙ）｜ＬＣｏＡ３］からの６４ビットに連結された、ＰａｔｈＵＭ８３５または８３５’または８３５'''のソースアドレスまたはＰａｔｈＵＭ８３５”のコンテンツからの最初の６４ビット（即ち、ＶＭＡＰ ＡＲ２ ４２４のプリフィックス）

また、ＶＭＡＰ３ ４２４は、ＶＢＣＥのＬＣｏＡ３を用いることに関連して、ＶＢＣＥからＲＣｏＡ及びＨａｓｈ（ＳｅｃｒｅｔＫｅｙ）を、ＰａｔｈＵＭ８３５（８３５’、８３５”または８３５'''）からＬＣｏＡ３を取得する。その後、ＶＭＡＰ３ ４２４は、ＬＣｏＡ４を用いてＶＢＣＥを更新し、すぐに、ＬＣｏＡ３で受信されたパケットを別ルートでＬＣｏＡ４に送信し始める（ステップ８３７）。その結果、ＶＭＡＰ３ ４２４は、ＬＣｏＡ３で受信されたパケットをカプセル化し、この場合は（例えばＯＳＰＦを経由して）リンク２４０を用いてＭＮ１１２のＬＣｏＡ４に直接転送する。これは、図８上で「トラフィック」８４４として太線の矢印で示されている。

この時点で、ＭＮ４１２は、事実上ＶＭＡＰ ＡＲ２ ４３２の責任範囲下にある。ＬＣｏＡ３で受信されたトラフィックは、新たに構成されたＬＣｏＡ４に対して事実上転送される。唯一なくなったステップは、その結果としてＬＣｏＡ４の利益のために用いられるのを止めるためにＬＣｏＡ３がＭＡＰ４１０に通知することである。この場合には、ＬＢＵ及びＥ−ＬＢＡを用いて最終的な更新を行うことにおいて効率が向上することはないことに留意されたい。

ステップ８３６の後、ＭＮ４１２は、ＭＡＰ４１０宛のＬＢＵ８３８を送ることによって、ＭＡＰ４１０の新たに構成されたＬＣｏＡ４をＭＡＰ４１０に通知することができる。ＬＢＵ８３８は、適切なリンク２４０を辿り、途中にあるルータによってＨＭＩＰｖ６トポロジーに沿ってＭＡＰ４１０まで転送される。その後、ＭＡＰ４１０は、ＬＣｏＡ３に置き換えてローカルバインディングにＬＣｏＡ４を登録する。ＲＣｏＡは変化していないので、この時点ではＨＡ１３０の更新は必要ない。ローカルバインディングを確認するために、ＭＡＰ２１０はさらに、ＭＮ４１２のＬＣｏＡ４宛にＥ−ＬＢＡ８４２を送信する。その後、ＭＡＰ４１０は、ローカルＨＡとして動作し、ＭＮ４１２に代えてＲＣｏＡ宛の全てのパケットを受信し、カプセル化し、ＭＮ４１２のＬＣｏＡ４に直接それらを転送する。この時点で、ＬＣｏＡ３は、ＭＡＰ４１０のレベルで使用を中止されるので、ＶＭＡＰ３ ４２４で構築された転送は使用を中止される。Ｅ−ＬＢＡ８４２は、前に提示されたＥ−ＬＢＡ７４２及、５４２及び５２２と同様に用いられ、従って、最良の実施例においては、バインディング存続期間及びＭＮ４１２のＲＣｏＡを含んでいる。Ｅ−ＬＢＡ８４２を受信する各ＶＭＡＰ（即ち、ＶＭＡＰ１ ４２０、ＶＭＡＰ３ ４２４及びＶＭＡＰ ＡＲ２ ４３２）は、仮想バインディングキャッシュエントリ（ＶＢＣＥ）を生成するか、または更新する（ステップ８４３）。

図９は、本発明の教示にかかるＶＭＡＰ９００のモジュラの説明を示している。ＶＭＡＰは、ＶＢＣＥ９１０を含み、認証モジュール９２０、中間ルータ機能９３０、及びアクセスルータ機能９４０を備えることができ、改良型マイクロ移動性管理（ＯＭＭ）機能９５０及び階層モバイルＩＰｖ６機能９６０を備える。認証モジュール９２０は、隣接するノードとＭＮとで交換されたメッセージを認証するのに用いられる場合、上で示したように処理を行う。中間ルータ機能９３０は、この役割で適切に動作するように、上述したＶＭＡＰ３ ４２４などのＶＭＡＰに存在している。階層モバイルＩＰｖ６機能９６０は、上述したような既存のＨＭＩＰｖ６の特徴を受け持つ。アクセスルータ機能９４０は、この役割で適切に動作するように、上述したＶＭＡＰ ＡＲ２ ４３２などのＶＭＡＰに存在している。中間ルータ機能９３０及びアクセスルータ機能９４０は、必ずしも相互排他的ではない。

ＯＭＭ機能９５０は、ＭＮ４１２が新しいＡＲにハンドオーバーしていることをＶＭＡＰ９５０に通知する、上述したＰａｔｈＵＭのうちの１つを受信し、新しいＡＲの下で有効な新しい局所気付アドレス（ｎＬＣｏＡ）を計算し、ＭＮの前のＬＣｏＡで受信されたトラフィックをｎＬＣｏＡに転送することができる。

ＭＮのためのＶＢＣＥ９１０は、少なくともＭＮのＲＣｏＡ、ＭＮのＬＣｏＡ、及びＭＮに関連づけられた固有値を含み、ＬＣｏＡ２を計算するステップは、上述した関数を用いて実行される。

ＬＣｏＡ２＝ＭＮのＲＣｏＡ、ＭＮのＬＣｏＡ、及びＭＮに関連づけられた固有値を共にハッシュ化することによって得られる６４ビットと連結された、新しいＡＲのサブネットプリフィックスに対応する最初の６４ビット

任意に、ＰａｔｈＵＭを受信する前に、ＯＭＭ機能９５０はさらに、ＬＣｏＡ宛のＭＡＰから発行された拡張局所バインディング受信確認（Ｅ−ＬＢＡ）を受信することができる。上で示したように、Ｅ−ＬＢＡは、少なくともＭＮのＲＣｏＡ及びＭＮに関連付けられた固有値を含む。その後、ＯＭＭ機能９５０は、さらに以下のステップのうち１つを実行することができる。
ＭＮのためのＶＢＣＥが既に存在する場合、Ｅ−ＬＢＡに含まれる情報を用いてＭＮのためのＶＢＣＥを更新するステップ、及び
ＭＮのためのＶＢＣＥが存在しない場合、Ｅ−ＬＢＡに含まれる情報を用いてＭＮのためのＶＢＣＥを生成するステップ

さらに、ＯＭＭ機能９５０は、さらに、ＡＲ２及びＭＮからなるグループのうちの１つによって発行されたＰａｔｈＵＭを受信し、ＰａｔｈＵＭがＭＮから発行される場合、ＶＭＡＰに直接送信されたＰａｔｈＵＭからＡＲ２のサブネットプリフィックスに対応する最初の６４ビットを抽出し、またはＰａｔｈＵＭがＡＲ２から発行される場合、ＬＣｏＡ宛のＰａｔｈＵＭのソースアドレス領域からＡＲ２のサブネットプリフィックスに対応する最初の６４ビットを抽出することができる。

また、ＯＭＭ機能は、さらにＥ−ＬＢＡの中のバインディング存続期間の値を受信し、ＭＮのためのＶＢＣＥにバインディング存続期間の値を加え、バインディング存続期間の満了のときにＭＮのためのＶＢＣＥを除去することができる。

上で示したように、ＶＭＡＰ９００は、ＶＭＡＰ９００のＯＭＭ機能９５０を通じて、さらに、第２のモバイルノード（ＭＮ２）がVMAPにハンドオーバーを要求するための拡張ルータ要求（Ｅ−ＲｔＳｏｌ）を第２のモバイルノード（ＭＮ２）から受信し、Ｅ−ＲｔＳｏｌは、前のＬＣｏＡ（ＬＣｏＡ−ＭＮ２）を含む。その後、ＶＭＡＰは、ＬＣｏＡ−ＭＮ２宛のＰａｔｈＵＭを送信し、ＭＮ２にルータ通知（ＲｔＡｄｖ）を送信する。

図１０は、本発明の教示にかかるＭＮ１０００のモジュラの説明を示している。ＭＮ１０００は、認証モジュール１０２０、ＯＭＭ機能１０５０、及びＨＭＩＰｖ６機能１０６０を備える。認証モジュール１０２０は、他のノードと交換されたメッセージの認証に用いられる場合、上で示したような処理を行う。階層モバイルＩＰｖ６機能１０６０は、上述したような既存のＨＭＩＰｖ６の特徴を受け持つ。ＯＭＭ機能は、第１のＡＲ１から第２のアクセスルータ（ＡＲ２）へのハンドオーバーを行う必要があることを検知し、ＡＲ１の下で有効なＬＣｏＡを含むＡＲ２に拡張ルータ要請（Ｅ−ＲｔＳｏｌ）を送信し、ＡＲ２からルータ通知（ＲｔＡｄｖ）を受信し、ＲｔＡｄｖからＡＲ２のサブネットプリフィックスに対応する６４ビットを抽出し、以下の関数を用いてＡＲ２の下で有効な第２のＬＣｏＡ（ＬＣｏＡ２）を計算することができる。

ＬＣｏＡ２＝ＭＮのＲＣｏＡ、ＭＮのＬＣｏＡ、及びＭＮに関連づけられた固有値を共にハッシュ化することによって得られる６４ビットと連結された、ＡＲ２のサブネットプリフィックスに対応する最初の６４ビット

任意に、ＬＣｏＡ２を計算する前に、ＯＭＭ機能はさらに、ＡＲ１宛のパス更新メッセージ（ＰａｔｈＵＭ）を送信することができ、ＰａｔｈＵＭは、ＡＲ２のサブネットプリフィックス対応する６４ビットを少なくとも含む。

同様に、ＬＣｏＡ２を計算した後に、ＯＭＭ機能はさらに、ＬＣｏＡ宛のパス更新メッセージ（ＰａｔｈＵＭ）送信することができ、ＰａｔｈＵＭは、ＡＲ２のサブネットプリフィックスに対応する６４ビットを少なくとも含む。

直接のリンクが存在している限り、最終的にＰａｔｈＵＭが交換される２つのＶＭＡＰは、単一のＭＡＰの下にある必要は全くないことに注意されたい。

本発明のいくつかの実施例は、添付図面で示され、上記記載で説明されるが、本発明は、開示された実施形態に限定されるものではなく、本発明の教示から逸脱しない範囲で多数の再配置、変更、及び置換が可能であるものと理解されたい。さらに、ノード間の通信は、多くの中間ノードの間の情報の経路選択と転送を伴うと思われる。このことは、本発明に影響せず、従って説明では明確に言及しない。一般に、本発明の説明でなされた記述は、必ずしも本発明の様々な請求された側面のいずれかを制限するというわけではない。さらに、いくつかの記述は、いくつかの発明の特徴に適用するが、他のものには適用されなくてもよい。図面では、同様のまたは同一の要素は、複数の図中で同じ参照番号で指定され、表現された様々な要素は、必ずしも原寸｛げんすん｝に比例｛ひれい｝して描かれるというわけではない。

従来技術のモバイルインターネットプロトコルバージョン６の構造を表したものである。 従来技術によるＨＭＩＰｖ６の仕様によって定められたＨＭＩＰｖ６のネットワークアーキテクチャである。 従来技術によるＭＮがＨＭＩＰｖ６ドメインに入るときの、モバイルノードとＨＭＩＰｖ６ドメインの他のノードとの間の動作及び作用についてのノードの動作とフローチャートである。 従来技術によるＭＮがＨＭＩＰｖ６ドメインに入るときの、モバイルノードとＨＭＩＰｖ６ドメインの他のノードとの間の動作及び作用についてのノードの動作とフローチャートである。 本発明の教示にかかる、改良型マイクロ移動性管理（ＯＭＭ）の特徴を実装するＨＭＩＰｖ６互換のドメインのネットワーク形態（トポロジー）である。 本発明にかかる、ＭＮがＯＭＭドメインに入るときのＯＭＭドメインのモバイルノード（ＭＮ）と他のノードとの間の動作及び作用についてのノードの動作及びフローチャートである。 本発明にかかる、ＭＮがポイントＢに向かって移動するときのＯＭＭドメインのＭＮと他のノードとの間の動作及び作用についてのノードの動作及びフローチャートである。 本発明にかかる、ＭＮがポイントＣに向かって移動するときのＯＭＭドメインのＭＮと他のノードとの間の動作及び作用についてのノードの動作及びフローチャートである。 本発明にかかる、ＭＮがポイントＢに向かって戻るときのＯＭＭドメインのＭＮと他のノードとの間の動作及び作用についてのノードの動作及びフローチャートである。 本発明の教示にかかるＶＭＡＰのモジュールを表したものである。 本発明の教示にかかるモバイルノードのモジュールを表したものである。

Claims (9)

1. モバイルインターネットプロトコルバージョン６（ＭＩＰｖ６）ネットワークにおいて、第１のアクセスルータ（ＡＲ１）から第２のアクセスルータ（ＡＲ２）へのモバイルノード（ＭＮ）のハンドオーバーの効率性を向上させるための仮想モバイルアンカーポイント（ＶＭＡＰ）であって、前記仮想モバイルアンカーポイントは、階層的にモバイルアンカーポイント（ＭＡＰ）の下かつ前記第１のアクセスルータの上にあり、前記モバイルノードは、前記モバイルアンカーポイントの下で有効な地域気付アドレス（ＲＣｏＡ）と、前記第１のアクセスルータの下で有効な第１の局所気付アドレス（ＬＣｏＡ）とを有し、
   前記モバイルノード４１２が前記第２のアクセスルータにハンドオーバーすることを前記仮想モバイルアンカーポイントに通知するパス更新メッセージ（ＰａｔｈＵＭ）を受信することと、
   前記第２のアクセスルータの下で有効な第２の局所気付アドレス（ＬＣｏＡ２）を計算することと、
   前記第１の局所気付アドレスにおいて受信されたトラフィックを前記第２の局所気付アドレスに転送することと、
   を可能とする、改善型マイクロ移動性管理（ＯＭＭ）機能を備え、更に
   前記モバイルノードの地域気付アドレスと、
   前記モバイルノードの第１の局所気付アドレスと、
   前記モバイルノードに関連付けられた固有値と、
   を少なくとも含む、前記モバイルノードのためのＶＭＡＰバインディングキャッシュエントリ（ＶＢＣＥ）をさらに含み、
   前記第２のアクセスルータのサブネットプリフィックスに対応する最初の６４ビットと、前記モバイルノードの地域気付アドレス、前記モバイルノードの第１の局所気付アドレス及び前記モバイルノードに関連付けられた固有値を共にハッシュ化することによって得られる６４ビットとを連結する関数を用いて、前記第２の局所気付アドレスの計算を実行することを特徴とする、仮想モバイルアンカーポイント。
2. 前記改良型マイクロ移動性管理機能は、さらに、
   前記パス更新メッセージを受信する前に、前記モバイルアンカーポイントから発行された前記第１の局所気付アドレス宛の拡張ローカルバインディング受信確認（Ｅ−ＬＢＡ）を受信し、前記拡張ローカルバインディング受信確認は、前記モバイルノードの地域気付アドレス及び前記モバイルノードに関連付けられた固有値を少なくとも含むことと、
   前記モバイルノードのための前記ＶＭＡＰバインディングキャッシュエントリが既に存在する場合、前記拡張ローカルバインディング受信確認に含まれる情報を用いて前記モバイルノードのための前記ＶＭＡＰバインディングキャッシュエントリを更新するステップ、及び前記モバイルノードのための前記ＶＭＡＰバインディングキャッシュエントリが存在しない場合、前記拡張ローカルバインディング受信確認に含まれる情報を用いて前記モバイルノードのための前記ＶＭＡＰバインディングキャッシュエントリを生成するステップのうち１つを実行することと、
   を可能とすることを特徴とする、請求項１に記載の仮想モバイルアンカーポイント。
3. 前記改良型マイクロ移動性管理機能は、さらに、
   前記第２のアクセスルータ及び前記モバイルノードから成るグループのうちの１つによって発行された前記パス更新メッセージを受信することと、
   前記パス更新メッセージが前記モバイルノードから発行される場合に、前記仮想モバイルアンカーポイントに直接送信された前記パス更新メッセージから前記ＡＲ２のサブネットプリフィックスに対応する最初の６４ビットを抽出することと、
   前記パス更新メッセージが前記第２のアクセスルータから発行される場合に、前記第１の局所気付アドレス宛の前記パス更新メッセージのソースアドレス領域から前記第２のアクセスルータのサブネットプリフィックスに対応する最初の６４ビットを抽出することと、
   を可能とすることを特徴とする、請求項１に記載の仮想モバイルアンカーポイント。
4. 前記改良型マイクロ移動性管理機能は、さらに、
   前記拡張ローカルバインディング受信確認の中のバインディング存続期間の値を受信することと、
   前記モバイルノードのための前記ＶＭＡＰバインディングキャッシュエントリに前記バインディング存続期間の値を加えることと、
   前記バインディング存続期間の満了のときに前記モバイルノードのための前記ＶＭＡＰバインディングキャッシュエントリを除去することと、
   を可能とすることを特徴とする、請求項２に記載の仮想モバイルアンカーポイント。
5. 前記改良型マイクロ移動性管理機能は、さらに、
   第２のモバイルノード（ＭＮ２）が前記仮想モバイルアンカーポインにハンドオーバーを要求する拡張ルータ要請（Ｅ−ＲｔＳｏｌ）を前記第２のモバイルノード（ＭＮ２）から受信し、前記拡張ルータ要請は、前の局所気付アドレス（ＬＣｏＡ−ＭＮ２）を含むことと、
   前記前の局所気付アドレス（ＬＣｏＡ−ＭＮ２）宛のパス更新メッセージを送信することと、
   ルータ通知（ＲｔＡｄｖ）を前記第２のモバイルノードに送信することと、
   を可能とすることを特徴とする、請求項１に記載の仮想モバイルアンカーポイント。
6. モバイルインターネットプロトコルバージョン６（ＭＩＰｖ６）ネットワークにおいて、第１のアクセスルータ（ＡＲ１）から第２のアクセスルータ（ＡＲ２）へのモバイルノード（ＭＮ）のハンドオーバーを行う方法であって、仮想モバイルアンカーポイント（ＶＭＡＰ）は、階層的にモバイルアンカーポイント（ＭＡＰ）の下かつ前記第１のアクセスルータの上にあり、前記モバイルノードは、前記モバイルアンカーポイントの下で有効な地域気付アドレス（ＲＣｏＡ）と、前記第１のアクセスルータの下で有効な第１の局所気付アドレス（ＬＣｏＡ）とを有し、
   前記仮想モバイルアンカーポイントにおいて、前記第１の局所気付アドレス宛の拡張局所バインディング受信確認（Ｅ−ＬＢＡ）内の前記モバイルノード及び前記モバイルノードの地域気付アドレスのための固有値を前記モバイルアンカーポイントから受信するステップと、
   前記仮想モバイルアンカーポイントにおいて、前記モバイルノードのためのＶＭＡＰバインディングキャッシュエントリを生成し、前記モバイルノードのための固有値は、前記第１の局所気付アドレス及び前記地域気付アドレスとともに保持されるステップと、
   前記モバイルノードから拡張ルータ要請メッセージ（Ｅ−ＲｔＳｏｌ）を前記第２のアクセスルータに送信し、それによって前記モバイルノードのハンドオーバーを前記第２のアクセスルータに要求し、前記拡張ルータ要請メッセージは前記モバイルノードの第１の局所気付アドレスを含むステップと、
   前記第２のアクセスルータのサブネットプリフィックスを前記モバイルノードへ提供するために、ルータ通知メッセージ（ＲｔＡｄｖ）を前記第２のアクセスルータから前記モバイルノードに送信するステップと、
   前記モバイルノードの第１の局所気付アドレス宛のパス更新メッセージ（ＰａｔｈＵＭ）を前記第２のアクセスルータから送信するステップと、
   前記モバイルノードが前記第２のアクセスルータにハンドオーバーすることを前記仮想モバイルアンカーポイントに通知する前記パス更新メッセージを、前記仮想モバイルアンカーポイントにおいて受信するステップであって、前記パス更新メッセージは前記第２のアクセスルータのサブネットプリフィックスを含む、前記受信するステップと、
   前記仮想モバイルアンカーポイントにおいて、前記モバイルノードの第２の局所気付アドレス（ＬＣｏＡ２）を計算するステップであって、前記第２のアクセスルータのサブネットプリフィックスに対応する最初の６４ビットと、前記モバイルノードの地域気付アドレス、前記モバイルノードの第１の局所気付アドレス及び前記モバイルノードに関連付けられた固有値を共にハッシュ化することによって得られる６４ビットとを連結する関数を用いて、前記第２の局所気付アドレスを計算するステップと、
   前記仮想モバイルアンカーポイントにおいて、前記第１の局所気付アドレスにおいて受信されたトラフィックを前記第２の局所気付アドレスに転送するステップと、
   を含むことを特徴とする方法。
7. モバイルインターネットプロトコルバージョン６（ＭＩＰｖ６）ネットワークにおける前記ＭＩＰｖ６ネットワークのＶＭＡＰが使用可能なドメイン内で、その下にあって有効な第１の局所気付アドレス（ＬＣｏＡ）を用いる第１のアクセスルータ（ＡＲ１）に接続されたモバイルノード（ＭＮ）であって、前記モバイルノードは、前記ＶＭＡＰが使用可能なドメインのモバイルアンカーポイント（ＭＡＰ）と共有され、前記モバイルノードに関連付けられた固有値を有し、前記モバイルノードは、前記モバイルアンカーポイントの下で有効な地域気付アドレス（ＲＣｏＡ）を有し、
   前記第１のアクセスルータから第２のアクセスルータ（ＡＲ２）へのハンドオーバーを行う必要があることを検知することと、
   前記第１の局所気付アドレスを含む前記第２のアクセスルータに拡張ルータ要請（Ｅ−ＲｔＳｏｌ）を送信することと、
   前記第２のアクセスルータからルータ通知（ＲｔＡｄｖ）を受信することと、
   前記ルータ通知から前記第２のアクセスルータのサブネットプリフィックスに対応する６４ビットを抽出することと、
   前記第２のアクセスルータのサブネットプリフィックスに対応する６４ビットと、前記モバイルノードの地域気付アドレス、前記モバイルノードの第１の局所気付アドレス及び前記モバイルノードに関連付けられた固有値を共にハッシュ化することによって得られる６４ビットとを連結する関数を用いて、前記第２のアクセスルータの下で有効な第２の局所気付アドレス（ＬＣｏＡ２）を計算することと、
   を可能とする、改良型マイクロ移動性管理（ＯＭＭ）機能を備えることを特徴とする、モバイルノード。
8. 前記改良型マイクロ移動性管理機能は、さらに、
   前記第２の局所気付アドレスを計算する前に、前記第２のアクセスルータのサブネットプリフィックスに対応する６４ビットを少なくとも含む、前記第１のアクセスルータ宛のパス更新メッセージ（ＰａｔｈＵＭ）を送信することを可能とすることを特徴とする、請求項７に記載のモバイルノード。
9. 前記改良型マイクロ移動性管理機能は、さらに、
   前記第２の局所気付アドレスを計算した後に、前記第２のアクセスルータのサブネットプリフィックスに対応する６４ビットを少なくとも含む、前記第１の局所気付アドレス宛のパス更新メッセージ（ＰａｔｈＵＭ）を送信することを可能とすることを特徴とする、請求項７に記載のモバイルノード。

Images