(57)【要約】【課題】  ＭＩＰｖ６網においてパケットの損失を低減し、且つパケットの順序がずれないようにするトラフィック交換方法を提供する。【解決手段】  ハンドオーバー遅延の間にパケットの損失を低減するためにＨＭＩＰｖ６とＦＭＩＰｖ６を効率的に統合し、ＦＭＩＰｖ６の適用にあたってパケット順序のずれを防止するために新しいメッセージを定義した。すなわち、先に受信されたパケットが全て送信されたことを知らせるためのメッセージ（Ｆｌｕｓｈメッセージ）を定義することによって、パケット順序のずれを防止した。したがって、モバイルＩＰｖ６網において移動ホストのトラフィック交換時に、パケットの損失を低減し、且つパケット順序のずれを防止する効果がある。【選択図】  図１０
2006246481.tif 000002
【特許請求の範囲】
【請求項１】
モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法であって、
第１の動的アドレスを用いて第１のルータに接続された状態で第２のルータに接続された接続装置からリンク階層信号を受信した移動ホストの要求に応答して、前記第１のルータが前記移動ホストに前記第２のルータの網情報を提供するステップと、
前記第１のルータ及び前記第２のルータが、前記第２のルータの網情報を用いた前記移動ホストの第２の動的アドレスを受信するステップと、
前記第１のルータが第１の動的アドレスを目的地とするパケットをバッファリングする第１のバッファリングステップと、
前記第２のルータによって前記第２の動的アドレスが使用できるか否かを判別するステップと、
前記第２の動的アドレスを使用可能な場合には、該第２の動的アドレスを用いて前記移動ホストによる高速バインディングアップデートを行い、前記高速バインディングアップデートの完了メッセージを前記第１のルータに送信するステップと、
前記高速バインディングアップデートの完了メッセージに応答して、前記第１のルータが第１のバッファリングステップでバッファリングされたパケットを前記第２のルータに転送し、前記第１のバッファリングステップでバッファリングされた全てのパケットを前記第２のルータに転送した場合には、これを知らせる転送完了メッセージを送信するステップと、
前記第２のルータが前記第１のルータから転送されたパケットをバッファリングする第２のバッファリングステップと、
前記第２のルータが第２の動的アドレスを目的地とするパケットを受信し、バッファリングする第３のバッファリングステップと、
前記移動ホストが、前記第１のルータから前記第２のルータに移動したことを知らせる移動完了メッセージを送信すれば、該移動完了メッセージに応答して、前記第２のルータが第２のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、
前記第２のルータが前記転送完了メッセージを受信すれば、前記第３のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、を備えることを特徴とするトラフィック交換方法。
【請求項２】
前記第１のルータ及び前記第２のルータをイントラネットで接続するローカルホームエージェントを備えており、
前記ローカルホームエージェントの網情報を用いた前記移動ホストの地域動的アドレスを生成するステップと、
前記移動ホストの第１の動的アドレスと前記地域動的アドレスを前記ローカルホームエージェントに格納するローカルバインディングアップデートステップと、
前記移動ホストのホームアドレスと前記地域動的アドレスをホームエージェントに格納するバインディングアップデートステップと、をさらに備えることを特徴とする請求項１に記載のトラフィック交換方法。
【請求項３】
前記転送完了メッセージは、
前記第１のルータのアドレスを格納する出発地アドレスフィールドと、
前記第２の動的アドレスを格納する目的地アドレスフィールドと、
前記転送が完了したことを知らせるフラグ情報を格納するフィールドと、を含むことを特徴とする請求項１又は２に記載のトラフィック交換方法。
【請求項４】
前記第２の動的アドレスを使用可能な場合には、前記第２の動的アドレスを用いて前記ローカルホームエージェントに格納されたローカルバインディングアップデート情報を変更するステップをさらに備えることを特徴とする請求項２に記載のトラフィック交換方法。
【請求項５】
前記変更ステップは、前記第２の動的アドレスと前記地域動的アドレスとをマッピングさせることを特徴とする請求項４に記載のトラフィック交換方法。
【請求項６】
前記移動ホストのホームアドレスを目的地とするパケットが受信されると、前記ローカルホームエージェントは、該パケットの目的地を前記第２の動的アドレスに変更し、前記第２のルータに送信することを特徴とする請求項５に記載のトラフィック交換方法。
【請求項７】
モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法であって、
第１の動的アドレスを用いて第１のルータに接続された状態で第２のルータに接続された接続装置からリンク階層信号を受信した移動ホストの要求に応答して、前記第１のルータが前記移動ホストに前記第２のルータの網情報を提供するステップと、
前記第２のルータが前記第２のルータの網情報を用いた前記移動ホストの第２の動的アドレス及び前記移動ホストの移動完了メッセージを受信するステップと、
前記第２のルータが前記移動ホストの第２の動的アドレスを前記第１のルータに送信するステップと、
前記第１のルータが第１の動的アドレスを目的地とするパケットをバッファリングする第１のバッファリングステップと、
前記第２の動的アドレスを用いて前記移動ホストの高速バインディングアップデートを行い、前記高速バインディングアップデートの完了メッセージを前記第１のルータに送信するステップと、
前記高速バインディングアップデートの完了メッセージに応答して、前記第１のルータが第１のバッファリングステップでバッファリングされたパケットを前記第２のルータに転送し、前記第１のバッファリングステップでバッファリングされた全てのパケットを前記第２のルータに転送した場合には、これを知らせる転送完了メッセージを送信するステップと、
前記第２のルータが前記第１のルータから転送されたパケットをバッファリングする第２のバッファリングステップと、
前記第２のルータが第２の動的アドレスを目的地とするパケットを受信し、バッファリングする第３のバッファリングステップと、
前記第２のルータが第２のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、
前記第２のルータが前記第１のルータから前記転送完了メッセージを受信すれば、前記第３のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、を備えることを特徴とするトラフィック交換方法。
【請求項８】
前記第１のルータ及び前記第２のルータをイントラネットで接続するローカルホームエージェントを備えており、
前記ローカルホームエージェントの網情報を用いた前記移動ホストの地域動的アドレスを生成するステップと、
前記移動ホストの第１の動的アドレスと前記地域動的アドレスを前記ローカルホームエージェントに格納するローカルバインディングアップデートステップと、
前記移動ホストのホームアドレスと前記地域動的アドレスをホームエージェントに格納するバインディングアップデートステップと、をさらに備えることを特徴とする請求項７に記載のトラフィック交換方法。
【請求項９】
前記転送完了メッセージは、
前記第１のルータのアドレスを格納する出発地アドレスフィールドと、
前記第２の動的アドレスを格納する目的地アドレスフィールドと、
前記転送が完了したことを知らせるフラグ情報を格納するフィールドと、を含むことを特徴とする請求項７又は８に記載のトラフィック交換方法。
【請求項１０】
前記第２の動的アドレスを使用可能な場合には、前記第２の動的アドレスを用いて前記ローカルホームエージェントに格納されたローカルバインディングアップデート情報を変更するステップをさらに備えることを特徴とする請求項８に記載のトラフィック交換方法。
【請求項１１】
前記変更ステップは、前記第２の動的アドレスと前記地域動的アドレスとをマッピングさせることを特徴とする請求項１０に記載のトラフィック交換方法。
【請求項１２】
前記移動ホストのホームアドレスを目的地とするパケットが受信されると、前記ローカルホームエージェントは、該パケットの目的地を前記第２の動的アドレスに変更し、前記第２のルータに送信することを特徴とする請求項１１に記載のトラフィック交換方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モバイルＩＰｖ６網に関し、特に、モバイルＩＰｖ６網における移動ホストのトラフィック交換方法に関する。
【背景技術】
【０００２】
現在のインターネットは、ＩＰｖ４を基盤としている。ＩＰｖ４において、ソースは、トラフィックを目的地に転送するために、パケットにソースアドレス及び目的地アドレスを書き込み、インターネットを介して送る。ＩＰｖ４に使われるＩＰアドレスは、３２ビットよりなり、最大約４０億個程度のホストをインターネットに接続することができる。しかしながら、特殊なアドレスの使用とサブネッティング、そしてネットワークアドレス割り当てなどに起因してインターネットに接続できるホストの数は、非常に少ない。また、インターネットの普遍化とマルチメディアトラフィックの増加に伴って、過去とは異なって、コンピュータだけでなく、移動通信端末、情報家電なども現在のインターネットに接続されるようになっている。このような移動通信端末とテレビ、そして冷蔵庫のような情報家電の数は、大変多いし、このような装置をインターネットに接続するためには、ＩＰｖ４アドレスが非常に足りない実情である。したがって、このようにＩＰアドレスの不足現象を解決し、ＩＰｖ４の非効率性を補完して、インターネットの性能を向上させることができるようにするためのＩＰｖ６技術が提案された。
【０００３】
ＩＰｖ６は、１２８ビットのアドレス体系を有している。したがって、アドレス体系が３２ビットであるＩＰｖ４に比べてＩＰアドレスが多い。また、アドレス体系が１２８ビットに増加すれば、ルータで経路を決定するための必須事項であるルーティングテーブルの内容が増加することによって、適切な経路を探すのに必要とする時間を短縮することができる。すなわち、ＩＰｖ６のアドレス体系は、ＩＰｖ４の場合よりも多い階層構造からなるため、ルーティングテーブルから適切な経路を探すのに要する時間が短いという特徴がある。
【０００４】
このようなＩＰｖ６は、ＩＰｖ４に比べて優れた機能を有するため、インターネットトラフィックの急激な増加とマルチメディアトラフィックの普遍的使用によるインターネットの性能問題を解決することができる。
【０００５】
一方、ホストに割り当てられるＩＰアドレスは、網識別子とホスト識別子とで構成される。網識別子は、ホストが接続されている網を表すための唯一の情報であり、ホスト識別子は、該当網においてホストを識別するための唯一の情報である。ＩＰアドレスを割り当てられたホストは、ＩＰアドレスと転送階層のポート番号を用いてソケットアドレスを作り、このようなソケットアドレスを用いて他のホストとの接続を設定する。
【０００６】
したがって、一つのホスト（ホスト１）が他のホスト（ホスト２）との接続を設定すれば、その接続が設定されている間は、該当ホストに同じＩＰアドレスが固定的に維持されていなければならない。
【０００７】
一方、他のホストとの接続が設定されている一つのホストが他の網に移動する場合には、網識別子が変更されなければならないため、移動するホストに割り当てられたＩＰアドレスを変更しなければならない。ＩＰアドレスの変更は、ソケットアドレスの変更を意味するため、既に設定されている接続は、全てキャンセルされ、さらに接続を試みなければならないという短所がある。
【０００８】
このようにホストが網を変更してインターネットに接続する場合に発生する接続キャンセルの問題を解決するために、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）では、モバイルＩＰｖ６（以下、“ＭＩＰｖ６”という。）プロトコルを提案している。ＭＩＰｖ６プロトコルでは、移動ホスト（Ｍｏｂｉｌｅ  Ｎｏｄｅ、以下、“ＭＮ”という。）が自機の位置を変更しても、既に設定されている接続を続いて維持できるようにするための方法が提案されている。すなわち、ＭＩＰｖ６プロトコルでは、インターネットに接続されているＭＮがインターネット上の任意のホスト（Ｃｏｒｒｅｓｐｏｎｄｅｎｔ  Ｎｏｄｅ、以下、“ＣＮ”という。）との接続を設定した状態で、自機の接続地点を変更しても、ＣＮとの接続が続いて維持され得るようにするためのメカニズムを定義している。
【０００９】
図１は、このようなＭＩＰｖ６プロトコルが適用されたＭＩＰｖ６網に関するシステム構成の例を示す。図１を参照すれば、ＭＩＰｖ６網に関するシステムは、ＭＮ２０にインターネット接続をサービスするアクセスルータ（Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ、以下、“ＡＲ”という。）３０、４０と、ＭＮ２０のホームアドレスと同じ網アドレスを有し、ＭＮ２０のホームアドレスを管理するホームエージェント（Ｈｏｍｅ  Ａｇｅｎｔ、以下、“ＨＡＧＴ”という。）５０とを備える。ここで、ＭＮ２０が移動する前に、ＭＮ２０のインターネット接続サービスを提供するＡＲ３０を、前ルータ（Ｐｒｅｖｉｏｕｓ  ＡＲ、以下、“ＰＡＲ”という。）と称し、ＭＮ２０が移動した後に、ＭＮ２０のインターネット接続サービスを提供するＡＲ４０を、新しいルータ（Ｎｅｗ  ＡＲ、以下、“ＮＡＲ”という。）と称する。一方、ＣＮ６０は、インターネット１０を介してＭＮ２０と接続されたホストである。
【００１０】
このような構成を有するＭＩＰｖ６網システムは、ＭＮ２０にホームアドレス（Ｈｏｍｅ  Ａｄｄｒｅｓｓ、以下、“ＨＡ”という。）として固定ＩＰアドレスを割り当て、該ホームアドレスをＭＮ２０のホームアドレスと同じ網アドレスを有するＨＡＧＴ５０に登録する。
【００１１】
一方、ＭＮ２０は、網の接続地点を変更する毎に、新しい網に存在するＡＲ（ＮＡＲ）から新しい動的ＩＰアドレスであるＣｏＡ（Ｃａｒｅ−ｏｆ  Ａｄｄｒｅｓｓ）を割り当てられ、自機のＨＡとＣｏＡをＨＡＧＴ５０に登録する。
【００１２】
次に、ＭＮ２０の移動前アドレス（例えば、ＨＡ）を認識しているＣＮ６０は、そのアドレス情報を用いてＭＮ２０に転送するデータをカプセル化する。次に、カプセル化されたデータは、ＭＮ２０のホームネットワークに送信され、ＭＮ２０の移動前アドレス（例えば、ＨＡ）及び移動後アドレス（ＣｏＡ）を共に認識しているＨＡＧＴ５０は、移動後アドレス（ＣｏＡ）を用いてデータをさらにカプセル化した後、ＭＮ２０に送信する。
【００１３】
このような一連の処理を図２に示す。図２は、ＭＩＰｖ６のトラフィック交換処理のうち、「双方向トンネリング方式」によるトラフィック交換処理の例を示している。
【００１４】
図１及び図２を参照すれば、ＭＮ２０がＰＡＲ３０からＮＡＲ４０に移動した場合には、ＭＮ２０は、ＮＡＲ４０に網情報を要求し（ステップＳ１０１）、それに対する応答を受け取り（ステップＳ１０３）、動的アドレス（ＣｏＡ）を生成し、自機のホームアドレス（ＨＡ）と動的アドレス（ＣｏＡ）をＨＡＧＴ５０に送信する（ステップＳ１０５）。ここで、ＭＮ２０は、ＨＡとＣｏＡを送信するために、バインディングアップデートメッセージ（ｂｉｎｄｉｎｇ  ｕｐｄａｔｅ  ｍｅｓｓａｇｅ）を用いる。
【００１５】
次に、ＨＡＧＴ５０は、ＭＮ２０のＨＡ及びＣｏＡをバインディングキャッシュに格納した後（ステップＳ１０７）、ＭＮ２０に応答メッセージ（Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  ｍｅｓｓａｇｅ）を送信する（ステップＳ１０９）。このようにＭＮ２０が自機のＨＡとＣｏＡをＨＡＧＴ５０に登録する処理を、「アドレス登録」処理という。
【００１６】
一方、ＣＮ６０からＭＮ２０に転送するデータがある場合には、ＣＮ６０は、ＭＮ２０のＨＡを用いてＭＮ２０に送るパケットＰＫＴＭＮを生成し（ステップＳ１１１）、ＭＮ２０のＨＡＧＴ５０に送信する（ステップＳ１１３）。次に、ＨＡＧＴ５０は、ステップＳ１０７でバインディングキャッシュに格納された情報に基づいてＭＮ２０のＣｏＡを検出し、ＣｏＡを用いてＰＫＴＭＮをカプセル化し（ステップＳ１１５）、カプセル化したＰＫＴＭＮをＭＮ２０に送信する。
【００１７】
このような双方向トンネリング方式では、ＣＮ６０がＭＩＰｖ６を提供できる機能を必要としない。すなわち、この方式において、ＣＮ６０からＭＮ２０に転送されるパケットの目的地アドレスは、ＭＮ２０のホームアドレスである。したがって、このパケットは、ＭＮ２０のホームネットワークに転送され、ＨＡＧＴ５０は、このパケットを受信し、ＭＮ２０のＣｏＡを用いてトンネリングした後、ＭＮ２０に転送する。また、ＭＮ２０からＣＮ５０に転送されるパケットは、まずトンネリングを用いてＨＡＧＴ５０に転送され（これは、ｒｅｖｅｒｓｅ  ｔｕｎｎｅｌｉｎｇという。）、正常な経路に沿ってＨＡＧＴ５０からＣＮ６０に送信される。
【００１８】
一方、図３は、ＭＩＰｖ６のトラフィック交換処理のうち「最適化方式」によるトラフィック交換処理の例を示す。
【００１９】
図１及び図３を参照すれば、ＭＮ２０がＰＡＲ３０からＮＡＲ４０に移動した場合には、ＭＮ２０は、ＮＡＲ４０に動的アドレスＣｏＡを要求し（ステップＳ１２１）、それに対する応答として、ＮＡＲ４０からＣｏＡを送信する（ステップＳ１２３）。
【００２０】
このように新しく移動したＮＡＲ４０からＣｏＡが送信されたＭＮ２０は、自機のホームアドレス（ＨＡ）と動的アドレス（ＣｏＡ）をＣＮ６０に送信する（ステップＳ１２５）。次に、ＣＮ６０は、ＭＮ２０のＨＡ及びＣｏＡを格納した後（ステップＳ１２７）、ＭＮ２０に応答メッセージ（Ｂｉｎｄｉｎｇ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  ｍｅｓｓａｇｅ、“Ａｃｋ”）を送信する（ステップＳ１２９）。
【００２１】
一方、ＣＮ６０からＭＮ２０に転送するデータがある場合には、ＣＮ６０は、格納されたＭＮ２０のＣｏＡを用いてＭＮ２０に送るパケットＰＫＴＭＮを生成した後（ステップＳ１３１）、パケットＰＫＴＭＮをＭＮ２０に直接転送する（ステップＳ１３３）。
【００２２】
このような最適化方式で、ＭＮ２０は、ＨＡとＣｏＡアドレスをＣＮ６０に登録する。したがって、ＣＮ６０がＭＮ２０にパケットを転送しようとする場合には、ＣＮ６０は、まず自機のバインディング情報に、ＭＮ２０に関するＣｏＡが存在するか否かを判別する。そして、ＭＮ２０に関するＣｏＡが存在すれば、そのアドレス情報（ＣｏＡ）を用いて、ＭＮ２０に転送するパケットを生成してから転送する。また、ＭＮ２０からＣＮ６０に転送されるパケットは、ＨＡＧＴ５０を経由せずに、ＣＮ６０に直接パケットを転送することが可能である。
【００２３】
しかし、ＭＩＰｖ６プロトコルを用いたＭＩＰｖ６網において、ＭＮ２０が新しい網に移動すれば、ＭＮ２０が新しい網からインターネット接続サービスを提供されるまでに所定時間がかかる。このような時間をハンドオーバー遅延（ｈａｎｄ−ｏｖｅｒ  ｌａｔｅｎｃｙ）といい、ハンドオーバー遅延には、ＭＮ２０が新しい網に移動したか否かを認識するのに要する時間と、新しい網から一つのＣｏＡを構成するのに要する時間と、構成されたＣｏＡをＨＡまたはＣＮに登録するのに要する時間が含まれる。
【００２４】
したがって、図１に示すＭＩＰｖ６網において、ＭＮ２０が移動した場合には、ハンドオーバー遅延の時間の間にＨＡＧＴ５０またはＣＮ６０から転送されるパケットは、ＭＮ２０がハンドオーバーする前に接続された前−ＡＲ（ＰＡＲ）３０に転送され、このようなパケットは、全て破棄される。すなわち、ハンドオーバー遅延の時間が長ければ長いほど、パケット損失が増加してしまう。
【００２５】
このような問題を解決し、ハンドオーバー遅延を低減（短縮）するために、従来、階層的ＭＩＰｖ６（Ｈｉｅｒａｒｃｈｉｃａｌ  ＭＩＰｖ６、以下、“ＨＭＩＰｖ６”という。）と、ＭＩＰｖ６のための高速ハンドオーバー（Ｆａｓｔ  ｈａｎｄ−ｏｖｅｒ、以下、“ＦＭＩＰｖ６”という。）が提案されている。
【００２６】
ＨＭＩＰｖ６では、ＭＡＰ（Ｍｏｂｉｌｉｔｙ  Ａｎｃｈｏｒ  Ｐｏｉｎｔ）という新しい機能を有しているルータを定義している。ここで、同じＭＡＰ情報を有するＡＲの集合をＭＡＰドメインという。そして、ＭＮがＭＡＰドメイン内で移動する場合には、そのアドレスの変更をＭＡＰにだけ報告することによって、バインディングアップデートの時間を短縮して、ハンドオーバー遅延を低減している。このようなＨＭＩＰｖ６網に関するシステム構成の例を、図４に示す。
【００２７】
図４を参照すれば、ＨＭＩＰｖ６網に関するシステムでは、ＭＮ２０のインターネット接続を管理するルータ３０、４０とインターネット１０との間にＭＡＰ７０を設けることによって、ＭＡＰ７０に基づいてルータ３０、４０間にイントラネット８０を形成する。ここで、ＭＡＰ７０は、ＭＡＰ７０ドメイン内で一種の「ローカルホームエージェント」として動作する。
【００２８】
このような構成を有するＨＭＩＰｖ６システムにおいて、ＭＮ２０は、複数の動的アドレスを割り当てられる。例えば、ＭＮ２０が他のＭＡＰドメインからＭＡＰ７０のドメイン領域に移動した場合には、ＭＮ２０は、ＰＡＲ３０からローカル動的アドレス（Ｌｏｃａｌ  ＣｏＡ、以下、“ＬＣｏＡ”という。）を割り当てられ、また、ＭＡＰ７０から地域動的アドレス（Ｒｅｇｉｏｎａｌ  ＣｏＡ、以下、“ＲＣｏＡ”という。）を割り当てられる。そして、ＭＡＰ７０には、ＭＮ２０のＬＣｏＡと、ＲＣｏＡが格納され、ＨＡＧＴ５０には、ＲＣｏＡとＨＡを登録し、バインディングアップデートを行う。一方、ＭＮ２０がＭＡＰ７０の領域内で移動する場合には、ＭＮ２０のＬＣｏＡが変更されるだけで、ＭＮ２０のＲＣｏＡは、変更されない。したがって、ＭＮ２０がＭＡＰ７０領域内で移動する場合には、これをＨＡＧＴ５０に知らせなくてもよい。
【００２９】
図４に示すようなＨＭＩＰｖ６網システムにおける、移動ホストのトラフィック交換処理を図５及び図６に示す。ここで、図５は、ＭＡＰ間の移動が発生した場合を示し、図６は、同一ＭＡＰ内での移動が発生した場合を示す。
【００３０】
図４及び図５を参照すれば、ＭＮ２０が他のＭＡＰドメインからＭＡＰ７０ドメインに移動した場合には、ＭＮ２０は、ＰＡＲ３０に網情報を要求する（ステップＳ２０１）。次に、ＰＡＲ３０は、それに対する応答として自機の網情報だけでなく、ＭＡＰ７０情報と共にＭＮ２０に送信する（ステップＳ２０３）。
【００３１】
ＭＮ２０は、ＰＡＲ３０の網情報を用いてＬＣｏＡ１を生成し、ＭＡＰ７０の情報を用いてＲＣｏＡを生成した後、ＬＣｏＡ１とＲＣｏＡをＭＡＰ７０に登録する（ステップＳ２０５、ステップＳ２０７、ステップＳ２０９）。すなわち、ローカルバインディングアップデート（ｌｏｃａｌ  ｂｉｎｄｉｎｇ  ｕｐｄａｔｅ）を行う。これにより、ＭＡＰ７０とＭＮ２０との間には、双方向トンネリングが設定される。すなわち、ＲＣｏＡの目的地アドレスを有するパケットを受信したＭＡＰ７０は、ＭＡＰ７０に格納されたＬＣｏＡ１を用いてパケットをＭＮ２０にトンネリングし、ＭＮ２０が転送しようとするラフィックは、ＭＡＰ７０にトンネリングされた後、ＭＡＰ７０からさらに該当目的地アドレスに再転送される。
【００３２】
また、ＭＮ２０は、自機のＲＣｏＡとホームアドレスを自機のＨＡとＣＮに登録する（ステップＳ２１１、ステップＳ２１３、ステップＳ２１５）。すなわち、バインディングアップデートを行う。このようにバインディングアップデートを行うと、ＨＡＧＴ５０またはＣＮ６０からＭＮ２０に転送されるパケットの目的地アドレスは、ＲＣｏＡを有し、このパケットをＭＡＰ７０が受信し、ＭＮ２０にトンネリングされる。
【００３３】
例えば、ＣＮ６０からＭＮ２０に転送するデータが存在する場合には、ＣＮ６０は、ＭＮ２０のＨＡを用いてＭＮ２０に送るパケットＰＫＴＭＮを生成し（ステップＳ２１７）、ＭＮ２０のＨＡＧＴ５０に送信する（ステップＳ２１９）。次に、ＨＡＧＴ５０は、ＭＮ２０のバインディングアップデート情報に基づいてＭＮ２０のＲＣｏＡを検出し、ＲＣｏＡを用いてＰＫＴＭＮをカプセル化し（ステップＳ２２１）、カプセル化したＰＫＴＭＮをＭＡＰ７０に送信する（ステップＳ２２３）。
【００３４】
カプセル化したＰＫＴＭＮを受信したＭＡＰ７０は、このカプセル化したＰＫＴＭＮの目的地アドレスからＲＣｏＡを検出した後、このＲＣｏＡに対応するＬＣｏＡ１を検出する（ステップＳ２２５）。そして、ＬＣｏＡ１を用いてＰＫＴＭＮをさらにカプセル化し（ステップＳ２２７）、カプセル化したＰＫＴＭＮをＭＮ２０に送信する（ステップＳ２２９）。
【００３５】
一方、ＭＮ２０がＭＡＰ７０ドメイン内の他のＡＲ（すなわち、ＮＡＲ）４０に移動する場合には、ＭＮ２０は、ＮＡＲ４０から受信したＮＡＲ４０の網情報及びＭＡＰ７０の情報を用いて自機のＬＣｏＡ２を構成し、このＬＣｏＡ２をＭＡＰ７０に登録することによって、ローカルバインディングアップデートを行う。
【００３６】
図６は、このような一連の処理及び移動したＭＮ２０へのパケット転送処理を示す。
【００３７】
図４及び図６を参照すれば、ＮＡＲ４０に移動したＭＮ２０は、ＮＡＲ３０に網情報を要求する（ステップＳ２５１）。次に、ＮＡＲ４０は、それに対する応答として自機の網情報だけでなく、ＭＡＰ７０情報と共にＭＮ２０に送信する（ステップＳ２５３）。
【００３８】
ＭＮ２０は、ＮＡＲ４０の網情報を用いてＬＣｏＡ２を生成する。また、ＭＡＰ７０情報を用いて自機の属するＭＡＰドメインが同一ドメインなのか異なるドメインなのかを把握する。図６は、同一ＭＡＰドメイン内での移動に関する例を示すもので、ＭＮ２０は、予め構成したＲＣｏＡをそのまま使用する。したがって、ＭＮ２０は、新しく生成したＬＣｏＡ２と予め構成したＲＣｏＡをＭＡＰ７０に登録する（ステップＳ２５５、ステップＳ２５７、ステップＳ２５９）。すなわち、ローカルバインディングアップデートを行う。これにより、ＭＮ（２０）のアドレス登録手続は終了し、追加的なＨＡＧＴ５０またはＣＮ６０への登録処理は不要になる。
【００３９】
一方、上記のようにアドレス登録が終了すれば、図５で説明したように、ＭＡＰ７０とＭＮ２０との間に双方向トンネリングが設定される。すなわち、ＲＣｏＡの目的地アドレスを有するパケットを受信したＭＡＰ７０は、ＭＡＰ７０に格納されたＬＣｏＡ２を用いてパケットをＭＮ２０にトンネリングし、ＭＮ２０が転送しようとするトラフィックは、ＭＡＰ７０にトンネリングされた後、ＭＡＰ７０からさらに該当目的地アドレスに再転送される。
【００４０】
この場合には、ＣＮ６０からＭＮ２０にデータを転送する処理は、図５で説明した処理と同様である。すなわち、ステップＳ２６１乃至ステップＳ２７３での処理は、図５に示すステップＳ２１７乃至ステップＳ２２９での処理に各々対応する。したがって、ステップＳ２６１乃至ステップＳ２７３での処理に関する具体的な説明は省略する。
【００４１】
このようにＨＭＩＰｖ６を用いる場合には、同一ＭＡＰドメイン内でのハンドオーバー時において、追加的なＨＡＧＴ５０またはＣＮ６０への登録処理を省略してもよい。したがって、同一ＭＡＰドメイン内でのハンドオーバー実行時において、ハンドオーバー遅延を低減することができる。しかしながら、この方法でも、ハンドオーバー遅延を十分に低減することはできない。すなわち、ＭＮ２０がＰＡＲ３０からＮＡＲ４０に移動する場合には、ハンドオーバー遅延が発生する。したがって、この遅延の間に、ＭＡＰ７０からＰＡＲ３０に転送されるパケットは、ＰＡＲ（３０）によって破棄される。すなわち、ＨＭＩＰｖ６網の場合にも、パケット損失が発生する問題点を依然として有している。
【００４２】
一方、ハンドオーバー遅延を低減するための他の解決方法として、ＦＭＩＰｖ６が挙げられる。ＦＭＩＰｖ６では、ＭＩＰｖ６網のシステム構成をそのまま用い、ＭＮが新しい網に移動する前に、ＮＡＲに関する情報及びＮＣｏＡ構成などを予め行うことによって、ハンドオーバー遅延を低減するとともに、パケットの損失を低減するようにしている。
【００４３】
図７及び図８は、このようなＦＭＩＰｖ６処理の例を示す。図７は、ＭＮ２０が移動する領域のルータから受信した情報により生成した動的アドレスにＭＮ２０の動的アドレスを変更した後に、実際移動がなされた場合に関する例を示し、図８は、ＭＮ２０が移動すると予想された領域に移動した後に、アドレスが変更された場合に関する例を示す。
【００４４】
図７を用いて、ＭＮ２０がｐｒｅｄｉｃｔｉｖｅである場合に関するＦＭＩＰｖ６処理を説明する。
【００４５】
ＭＮ２０がＰＡＲ３０を用いてインターネット接続を行い、ＰＡＲ３０の網情報を用いて生成された動的アドレス（Ｐｒｅｖｉｏｕｓ  ＣｏＡ、以下、“ＰＣｏＡ”という。）を用いてトラフィック交換を行い、新しい網に関する情報（すなわち、無線ＬＡＮの場合には、ＳＳＩＤなど）を受信すれば、ＭＮ２０は、新しい網の第２の階層アドレスを含むメッセージ（すなわち、ＲｔＳｏｌＰｒ（Ｒｏｕｔｅｒ  Ｓｏｌｉｃｉｔａｔｉｏｎ  Ｐｒｏｘｙ）メッセージ）をＰＡＲ３０に転送する（ステップＳ３０１）。このメッセージを受信したＰＡＲ３０は、ＮＡＲ４０のＩＰｖ６アドレスと第２の階層アドレスとを含むメッセージ（すなわち、ＰｒＲｔＡｄｖ（Ｐｒｏｘｙ  Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔ）メッセージ）をＭＮ２０に転送する（ステップＳ３０３）。このメッセージを受信したＭＮ２０は、ＮＡＲ４０のＩＰｖ６アドレスにある網アドレス情報と自機のインタフェース識別子情報を用いて新しい網に使われる動的アドレス（ＮＣｏＡ）を構成し（ステップＳ３０５）、このアドレス情報（ＮＣｏＡ）を含むメッセージ（すなわち、ＦＢＵメッセージ）をＰＡＲ３０に転送する（ステップＳ３０７）。
【００４６】
ＦＢＵメッセージを受信したＰＡＲ３０は、ＮＣｏＡアドレスの使用可能性を判別するために、ＮＡＲ４０にＮＣｏＡアドレス情報を含むメッセージ（ＨＩ（Ｈａｎｄ−ｏｖｅｒ  Ｉｎｉｔｉａｔｅ））メッセージを転送する（ステップＳ３０９）。そして、ＮＡＲ４０からそれに対する応答メッセージ（ＨＡｃｋ（Ｈａｎｄ−ｏｖｅｒ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）メッセージ）を受信する（ステップＳ３１１）。そして、ＭＮ２０とＮＡＲ４０にＦＢ＿Ａｃｋメッセージを転送する（ステップＳ３１３、ステップＳ３１５）。
【００４７】
ＦＢ＿Ａｃｋメッセージを受信したＭＮ２０は、自機の動的アドレスを変更する（ＰＣｏＡ→ＮＣｏＡ）（ステップＳ３１７）。
【００４８】
一方、ＰＡＲ３０は、ＨＡＧＴ５０またはＣＮ６０からＰＣｏＡの目的地アドレスを有するパケットをＮＣｏＡにトンネリングする。すなわち、ＨＡＧＴ５０またはＣＮ６０からＰＣｏＡの目的地アドレスを有するパケットＰＫＴＭＮが送信されると（ステップＳ３１９）、ＮＣｏＡを用いて該パケットＰＫＴＭＮをカプセル化し（ステップＳ３２１）、該パケットＰＫＴＭＮをＮＡＲ４０に送信する（ステップＳ３２３）。
【００４９】
ＮＡＲ４０は、ＭＮ２０が自機の網に接続する前まで、該パケットＰＫＴＭＮ（すなわち、ＮＣｏＡにカプセル化したパケット）をバッファリングする（ステップＳ３２５）。
【００５０】
ステップＳ３１７で動的アドレスを変更したＭＮ２０がＮＡＲ領域に移動すれば（ステップＳ３２７）、ＭＮ２０は、自機の移動をＮＡＲ（４０）に知らせるために、ＦＮＡメッセージをＮＡＲ４０に転送する（ステップＳ３２９）。
【００５１】
ＭＮ２０からＦＮＡメッセージを受信したＮＡＲ４０は、今までバッファリングされたパケットをＭＮ２０に転送する（ステップＳ３３１）。このように、高速のハンドオーバーが完了した後、ＭＮ２０は、ＮＡＲ４０で使用する動的アドレス（ＮＣｏＡ）とホームアドレス（ＨＡ）をＨＡＧＴ５０に送信し、登録する（ステップＳ３３３、ステップＳ３３５）。バインディングアップデートを行う。
【００５２】
バインディングアップデート後、ＨＡＧＴ５０は、ＣＮ６０からパケットＰＫＴＭＮが送信されると（ステップＳ３３７）、該パケットＰＫＴＭＮをＮＣｏＡにカプセル化し（ステップＳ３３９）、ＭＮ２０に送信する（ステップＳ３４１）。
【００５３】
一方、ＭＮ２０は、自機の変更されたＣｏＡ（すなわち、ＮＣｏＡ）をＨＡＧＴ５０またはＣＮ６０に登録（例えば、バインディングアップデート）する前まで、送信しようとするパケットのソースアドレスをＰＣｏＡにした後、該当パケットをＰＡＲにトンネリング（不図示）することで、ハンドオーバーによるパケット損失を低減している。
【００５４】
次に、図８を用いて、ＭＮ２０がｒｅａｃｔｉｖｅである場合に関するＦＭＩＰｖ６処理を説明する。
【００５５】
図８を参照すれば、所定のステップＳ３５１、ステップＳ３５３、ステップＳ３５５を経てＮＣｏＡを構成したＭＮ２０がＮＡＲ領域に移動すれば（ステップＳ３５７）、ＭＮ２０は、自機の移動をＮＡＲ４０に知らせるために、ＦＮＡメッセージをＮＡＲ４０に転送する（ステップＳ３５９）。
【００５６】
ここで、ステップＳ３５１、ステップＳ３５３、ステップＳ３５５での各処理は、図７に示すステップＳ３０１、ステップＳ３０３、ステップＳ３０５での各処理と同様なので、これらの処理の具体的な説明は省略する。ここで、ステップＳ３５９で送信されるＦＮＡメッセージには、アドレス情報（ＮＣｏＡ）を含むメッセージ（ＦＢＵメッセージ）が含まれる。
【００５７】
次に、ＮＡＲ４０は、ＦＢＵメッセージを通じてＮＣｏＡをＰＡＲ３０に送信する（ステップＳ３６１）。このようにＮＣｏＡアドレスを受信したＰＡＲ３０は、ＭＮ２０とＮＡＲ４０の各々にＦＢ＿Ａｃｋメッセージを送信する（ステップＳ３６３、ステップＳ３６５）。
【００５８】
ＦＢ＿Ａｃｋメッセージを受信したＭＮ２０は、自機の動的アドレスを変更する（ＰＣｏＡ→ＮＣｏＡ）（ステップＳ３６７）。
【００５９】
そして、ＣＮ６０からパケットＰＫＴＭＮが受信されると、図８に示すステップＳ３６９乃至ステップＳ３８７の処理に基づいてパケットＰＫＴＭＮを処理する。ここで、ステップＳ３６９乃至ステップＳ３８７での各処理は、図７に示すパケットＰＫＴＭＮ処理（ステップＳ３１９乃至ステップＳ３４１）と同様である。したがって、ステップＳ３６９乃至ステップＳ３８７に関する具体的な説明は省略する。但し、図８に示す処理では、図７において、ＭＮ２０がＮＡＲに移動した後（ステップＳ３２７）、その事実をＮＡＲ４０に知らせる処理（ステップＳ３２９）が、パケット処理前に実行されるという点だけが異なる。
【００６０】
図７及び図８に示すＦＭＩＰｖ６処理は、いずれも２種類の経路を介してＭＮ２０へのパケットＰＫＴＭＮを送信する。すなわち、バインディングアップデートを起点としてバインディングアップデートの前後においてパケット送信経路が互いに異なる。すなわち、ＭＮ２０がバインディングアップデートを行う前には、ＣＮ６０から送信されるパケットを、ＰＡＲ３０を経て受信し、ＭＮ２０がバインディングアップデートを行った後には、ＣＮ６０から送信されるパケットを、ＰＡＲ３０を経由せずに受信する。言い換えれば、ＭＮ２０がバインディングアップデートを行う前には、ＭＮ２０に送信されるパケットＰＫＴＭＮがＰＡＲ３０を経てＮＡＲ４０にバッファリングされてから、実際の移動後のＭＮ２０に送信されるが、ＭＮ２０がバインディングアップデートを行った後には、ＭＮ２０に送信されるパケットが、直ちにＮＡＲ４０でのＮＣｏＡアドレスを用いてＭＮ２０に送信される。
【００６１】
上述した処理では、ＭＮ２０の移動時間が長くかかったり、バインディングアップデート時間が遅延されたりする。そして、ＮＡＲ４０にバッファリングされたパケットＰＫＴＭＮが多い場合には、バッファリングされたパケットＰＫＴＭＮが全てＭＮ２０に送信される前に、ＮＡＲ４０を介してＭＮ２０に送信されるパケットＰＫＴＭＮが存在し得る。
【００６２】
この場合には、ＭＮ２０に送信されたパケットＰＫＴＭＮの順序がずれる問題が発生するようになる。このようにパケットの受信順序がずれる場合には、応用プログラムの性能が非常に低下してしまう。すなわち、パケットの受信順序がずれる場合には、パケットの受信側では、正しい順序のパケットを要求する応答を発生するが、これにより、ＴＣＰでは、重複応答が発生するようになり、送信側ＴＣＰに３つ以上の重複応答が入れば、送信側ＴＣＰは、早い再転送及び早い復旧状態に入る。この状態で、送信側ＴＣＰは、自機のトラフィックを再転送し、また、混雑ウィンドウのサイズを減少させる。このような混雑ウィンドウサイズの減少は、送信側ＴＣＰの性能を低下させてしまう。
【００６３】
また、ＵＤＰ基盤のマルチメディアトラフィックの場合にも、パケット損失が生じ、順序がずれてパケットが受信される場合には、品質が非常に低下する問題がある。
【００６４】
したがって、ＭＮが新しい網に移動する場合には、パケットの損失だけでなく、パケットの順序がずれて受信されることを防止するためのメカニズムが求められている。
【発明の開示】
【発明が解決しようとする課題】
【００６５】
本発明の目的は、前述のような問題点を解決するためになされたもので、本発明は、ＭＩＰｖ６網においてパケットの損失を低減し、且つパケットの受信順序がずれないようにするトラフィック交換方法を提供することにある。
【００６６】
また、本発明の目的はは、ＭＩＰｖ６網において応用階層プロトコルの性能を向上させるためのトラフィック交換方法を提供することにある。
【課題を解決するための手段】
【００６７】
上述した目的を達成するために、本願第１の発明に係るモバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法は、第１の動的アドレスを用いて第１のルータに接続された状態で第２のルータに接続された接続装置からリンク階層信号を受信した移動ホストの要求に応答して、第１のルータが移動ホストに第２のルータの網情報を提供するステップと、第１のルータ及び第２のルータが第２のルータの網情報を用いた移動ホストの第２の動的アドレスを受信するステップと、第１のルータが第１の動的アドレスを目的地とするパケットをバッファリングする第１のバッファリングステップと、第２のルータが第２の動的アドレスの使用可能性を確認するステップと、第２の動的アドレスを使用可能な場合には、該第２の動的アドレスを用いて移動ホストの高速バインディングアップデートを行い、高速バインディングアップデート完了メッセージを第１のルータに送信するステップと、高速バインディングアップデート完了メッセージに応答して、第１のルータが第１のバッファリングステップでバッファリングされたパケットを第２のルータに転送し、第１のバッファリングステップでバッファリングされた全てのパケットを第２のルータに転送した場合には、これを知らせる転送完了メッセージを送信するステップと、第２のルータが第１のルータから転送されたパケットをバッファリングする第２のバッファリングステップと、第２のルータが第２の動的アドレスを目的地とするパケットを受信し、バッファリングする第３のバッファリングステップと、移動ホストが第１のルータから第２のルータに移動したことを知らせる移動完了メッセージを送信すれば、該移動完了メッセージに応答して、第２のルータが第２のバッファリングステップでバッファリングされたパケットを移動ホストに送信するステップと、第２のルータが転送完了メッセージを受信すれば、第３のバッファリングステップでバッファリングされたパケットを移動ホストに送信するステップと、を備えることを特徴とする。
【００６８】
ここで、第１のルータ及び第２のルータをイントラネットで接続するローカルホームエージェントを備え、ローカルホームエージェントの網情報を用いた移動ホストの地域動的アドレスを生成するステップと、移動ホストの第１の動的アドレスと地域動的アドレスをローカルホームエージェントに格納するローカルバインディングアップデートステップと、移動ホストのホームアドレスと地域動的アドレスをホームエージェントに格納するバインディングアップデートステップと、をさらに備えることができる。
【００６９】
また、転送完了メッセージに、第１のルータのアドレスを格納する出発地アドレスフィールドと、第２の動的アドレスを格納する目的地アドレスフィールドと、転送が完了したことを知らせるフラグ情報を格納するフィールドと、を含めることができる。
【００７０】
本願第２の発明に係るモバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法は、第１の動的アドレスを用いて第１のルータに接続された状態で第２のルータに接続された接続装置からリンク階層信号を受信した移動ホストの要求に応答して、第１のルータが移動ホストに第２のルータの網情報を提供するステップと、第２のルータが第２のルータの網情報を用いた移動ホストの第２の動的アドレス及び移動ホストの移動完了メッセージを受信するステップと、第２のルータが移動ホストの第２の動的アドレスを第１のルータに送信するステップと、第１のルータが第１の動的アドレスを目的地とするパケットをバッファリングする第１のバッファリングステップと、第２の動的アドレスを用いて移動ホストの高速バインディングアップデートを行い、高速バインディングアップデート完了メッセージを第１のルータに送信するステップと、高速バインディングアップデート完了メッセージに応答して、第１のルータが第１のバッファリングステップでバッファリングされたパケットを第２のルータに転送し、第１のバッファリングステップでバッファリングされた全てのパケットを第２のルータに転送した場合には、これを知らせる転送完了メッセージを送信するステップと、第２のルータが第１のルータから転送されたパケットをバッファリングする第２のバッファリングステップと、第２のルータが第２の動的アドレスを目的地とするパケットを受信し、バッファリングする第３のバッファリングステップと、第２のルータが第２のバッファリングステップでバッファリングされたパケットを移動ホストに送信するステップと、第２のルータが第１のルータから転送完了メッセージを受信すれば、第３のバッファリングステップでバッファリングされたパケットを移動ホストに送信するステップと、を備えることを特徴とする。
【００７１】
ここで、第１のルータ及び第２のルータをイントラネットで接続するローカルホームエージェントを備え、ローカルホームエージェントの網情報を用いた移動ホストの地域動的アドレスを生成するステップと、移動ホストの第１の動的アドレスと地域動的アドレスをローカルホームエージェントに格納するローカルバインディングアップデートステップと、移動ホストのホームアドレスと地域動的アドレスをホームエージェントに格納するバインディングアップデートステップと、をさらに備えることができる。
【００７２】
転送完了メッセージに、第１のルータのアドレスを格納する出発地アドレスフィールドと、第２の動的アドレスを格納する目的地アドレスフィールドと、転送が完了したことを知らせるフラグ情報を格納するフィールドと、を含めることができる。
【発明の効果】
【００７３】
本発明では、ハンドオーバー遅延の間にパケットの損失を低減するために、ＨＭＩＰｖ６とＦＭＩＰｖ６を効率的に統合し、ＦＭＩＰｖ６の適用において、パケット順序のずれを防止するために、新しいメッセージを定義している。すなわち、先に受信されたパケットが全て送信されたことを知らせるためのメッセージ（Ｆｌｕｓｈメッセージ）を定義することによって、パケット順序のずれを防止している。したがって、モバイルＩＰｖ６網において移動ホストのトラフィック交換時において、パケットの損失を低減し、且つパケット順序のずれを防止することができる。そして、パケット順序のずれに起因して発生する応用階層プロトコルの性能低下の問題を解決することができる。
【発明を実施するための最良の形態】
【００７４】
以下、添付の図面を参照して、本発明の好適な実施形態に係る構成及び作用を詳細に説明する。なお、本発明の要旨を不明確にする公知の機能及び構成についての詳細な説明は省略する。本明細書において、同一の参照番号は、同一の構成要素を示す。
【００７５】
図９は、本発明の実施形態に係るモバイルＩＰｖ６網に関する構成図である。図９を参照すれば、本発明の実施形態に係るモバイルＩＰｖ６網は、移動ホストＭＮ２００のインターネット接続を管理するルータ(Ａｃｃｅｓｓ  Ｒｏｕｔｅｒ、以下、“ＡＲ”という。)３００、４００と、ＭＮ２００のホームアドレスを管理するホームエージェント（Ｈｏｍｅ  Ａｇｅｎｔ、以下、“ＨＡＧＴ”という。）５００と、ルータ３００、４００とインターネット１００との間でルータ３００、４００間にイントラネット８００を形成するＭＡＰ７００と、を備える。
【００７６】
ここで、ＭＮ２００が移動する前にＭＮ２００のインターネット接続サービスを提供するＡＲ３００を前ルータ（Ｐｒｅｖｉｏｕｓ  ＡＲ、以下、“ＰＡＲ”という。）と称し、ＭＮ２００が移動した後、ＭＮ２００のインターネット接続サービスを提供するＡＲ４００を新しいルータ（Ｎｅｗ  ＡＲ、以下、“ＮＡＲ”という。）と称する。
【００７７】
また、ルータ３００、４００間にイントラネット８００を形成するＭＡＰ７０は、ドメイン内で一種の「ローカルホームエージェント」として動作する。
【００７８】
一方、ＣＮ６００は、インターネット１００を介してＭＮ２００と接続されたホストである。
【００７９】
このような構成を有する本発明の実施形態に係るＭＩＰｖ６網は、階層的ＭＩＰｖ６（Ｈｉｅｒａｒｃｈｉｃａｌ  ＭＩＰｖ６、以下、“ＨＭＩＰｖ６”という。）とＭＩＰｖ６のための高速ハンドオーバー（Ｆａｓｔｈａｎｄ−ｏｖｅｒ、以下、“ＦＭＩＰｖ６”という。）の特徴を全て含む。
【００８０】
このような本発明のＭＩＰｖ６網において移動ホストのトラフィックを交換するための処理を、図１０及び図１５に示す。図１０は、ＭＮ２００が移動する領域のルータＮＡＲ４００から受信した情報により生成した動的アドレスにＭＮ２００の動的アドレスを変更した後、実際移動がなされた場合（ｐｒｅｄｉｃｔｉｖｅ）に関する例を示し、図１５は、ＭＮ２００が移動すると予想された領域に移動した後、アドレスが変更された場合（ｒｅａｃｔｉｖｅ）に関する例を示す。
【００８１】
図１０は、本発明の一実施形態に係るＭＩＰｖ６網において移動ホストのトラフィック交換手続を示す図であって、図１０を参照すれば、本発明の一実施形態に係るＭＩＰｖ６網においてトラフィック交換手続は、次の通りである。すなわち、動的アドレスが変更された後に、ＭＮ２００の実際の移動が行われる場合（ｐｒｅｄｉｃｔｉｖｅ）に関する本発明のトラフィック交換手続は、次の通りである。
【００８２】
ＭＮ２００が他のＭＡＰドメインからＭＡＰ７００ドメインに移動した場合には、ＭＮ２００は、ＰＡＲ３００に網情報を要求（Ｒｏｕｔｅｒ  Ｓｏｌｉｃｉｔａｔｉｏｎ）する（ステップＳ４０１）。次に、ＰＡＲ３００は、それに対する応答として自機の網情報だけでなく、ＭＡＰ７００情報と共にＭＮ２００に送信する（ステップＳ４０３）。この場合には、ステップＳ４０１での要求及びステップＳ４０３での応答のためのメッセージは、ＨＭＩＰｖ６プロトコルに定義された形態のメッセージを用いることが好ましい。
【００８３】
ＭＮ２００は、ＰＡＲ３００の網情報を用いてＰＬＣｏＡ（Ｐｒｅｖｉｏｕｓ  Ｌｏｃａｌ  ＣｏＡ）を生成し、ＭＡＰ７００の情報を用いてＲＣｏＡを生成した後、ＰＬＣｏＡとＲＣｏＡをＭＡＰ７００に登録する。すなわち、ＭＮ２００は、ＰＬＣｏＡとＲＣｏＡをＭＡＰ７００に送信し、ローカルバインディングアップデートを要求し（ステップＳ４０５）、ＭＡＰ７００はＰＬＣｏＡとＲＣｏＡをバインディングキャッシュ（ｂｉｎｄｉｎｇ  ｃａｃｈｅ）に格納した後（ステップＳ４０７）、ＭＮ２００にローカルバインディングアップデートに対する応答（ｌｏｃａｌ  ｂｉｎｄｉｎｇ  ａｃｋｎｏｗｌｅｄｇｅ）を転送する（ステップＳ４０９）。ステップＳ４０５乃至ステップＳ４０９の処理における、ローカルバインディングアップデートのためのローカルバインディング要求ローカルバインディング通知のためのメッセージ形式は、ＨＭＩＰｖ６プロトコルに定義されたものを用いることが好ましい。
【００８４】
上述したローカルバインディングアップデートにより、ＭＡＰ７００とＭＮ２００との間には、双方向（ｂｉ−ｄｉｒｅｃｔｉｏｎａｌ）トンネリングが設定される。すなわち、ＲＣｏＡの目的地アドレスを有するパケットを受信したＭＡＰ７００は、ＭＡＰ７００に格納されたＰＬＣｏＡを用いてパケットをＭＮ２００にトンネリングし、ＭＮ２００が転送しようとするトラフィックは、ＭＡＰ７００にトンネリングされた後、ＭＡＰ７００からさらに該当目的地アドレスに再転送される。
【００８５】
また、ＭＮ２００は、自機のＲＣｏＡとホームアドレスをＨＡＧＴ５００とＣＮ６００に登録する（ステップＳ４１１、ステップＳ４１３）。すなわちバインディングアップデートを行う。
【００８６】
一方、ＭＮ２００がＰＡＲ３００を用いてインターネットに接続し、ＰＡＲ３００の網情報を用いて生成された第１の動的アドレスＰＬＣｏＡ及びＭＡＰ７００を用いて生成された第２の動的アドレスＲＣｏＡを用いてトラフィック交換を行った場合には、新しいアクセスルータＡＲ（すなわち、ＮＡＲ４００）に接続されているＡＰからリンク階層信号を受信し、ＮＡＲ４００に移動しようとする場合、ＭＮ２００は、ＰＡＲ３００にＲｔＳｏｌＰｒ（Ｒｏｕｔｅｒ  Ｓｏｌｉｃｉｔａｔｉｏｎ  Ｐｒｏｘｙ）メッセージを転送する（ステップＳ４１５）。
【００８７】
ＲｔＳｏｌＰｒメッセージには、新しく感知されたＡＰの第２の階層アドレスと現在ＭＮが接続されているＭＡＰアドレスが含まれる。ＲｔＳｏｌＰｒメッセージの構成例を図１１に示す。図１１に示すように、ＲｔＳｏｌＰｒメッセージ４１０は、ＭＮ２００のアドレス情報（ＭＮ  Ａｄｄｒ.）４１１と、新しいＡＰのアドレス情報（Ｎｅｗ−ＡＰ  Ａｄｄｒ.）４１３と、ＭＡＰアドレス情報（ＭＡＰ  Ａｄｄｒ.）４１５とを含む。ここで、新しいＡＰのアドレス情報４１３は、ＡＰの第２の階層アドレスである。
【００８８】
一方、ステップＳ４１５で、ＭＮ２００からＲｔＳｏｌＰｒメッセージを受信したＰＡＲ３００は、該メッセージに含まれたＡＰの第２の階層（例えば、リンク階層）情報を用いてどのＮＡＲがＡＰと接続されているかを確認する。また、ＰＡＲ３００は、ＭＮ２００から転送されたＭＡＰアドレス情報のうち、ＮＡＲ４００が提供し得るＭＡＰが存在するか否かを確認する。その後、ＰＡＲ３００は、ＭＮ２００にＰｒＲｔＡｄｖ（Ｐｒｏｘｙ  Ｒｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔ）メッセージを転送する（ステップＳ４１７）。
【００８９】
ＰｒＲｔＡｄｖメッセージは、ＰＡＲ、ＡＰ、そしてＮＡＲのリンク階層アドレス情報とＮＡＲのＩＰアドレス情報及びプレフィクス情報、そしてＭＡＰのアドレス情報を含む。このメッセージの構成例を図１２に示す。図１２に示すように、ＰｒＲｔＡｄｖメッセージ４２０は、ＰＡＲ３００アドレス情報（ＰＡＲ  Ａｄｄｒ.）４２１、ＡＰアドレス情報（ＡＰ  Ａｄｄｒ.）４２２、ＮＡＲ４００アドレス情報（ＮＡＲ  Ａｄｄｒ.）４２３、ＮＡＲ４００のＩＰアドレス（ＮＡＲ  ＩＰ）４２４、ＮＡＲプレフィクス（ＮＡＲ  ｐｒｅｆｉｘ）４２５及びＭＡＰアドレス情報（ＭＡＰ  Ａｄｄｒ.）４２６を含む。ここで、ＰＡＲ３００とＮＡＲ４００のアドレス情報４２１及び４２３には、ＰＡＲ３００及びＮＡＲ４００の第２の階層アドレスが格納される。
【００９０】
ＰｒＲｔＡｄｖメッセージを受信したＭＮ２００は、該メッセージ内にＭＡＰアドレス情報（例えば、ＭＡＰアドレスオプション）が存在するか否かを確認する。そして、ＭＡＰアドレス情報が存在すれば、同一ＭＡＰドメイン内での移動として見なし、ＮＡＲ４００のプレフィクス（ｐｒｅｆｉｘ）情報を用いてＮＬＣｏＡ（Ｎｅｗ  Ｌｏｃａｌ  ＣｏＡ）を構成する（ステップＳ４１９）。そして、このＮＬＣｏＡを含むＦＢＵメッセージをＰＡＲ３００に転送する（ステップＳ４２１）。また、ＰＡＲ３００は、ＦＢＵメッセージ内のＭＡＰアドレスを用いて該ＦＢＵメッセージをＭＡＰ７００にリレイする（ステップＳ４２３）。
【００９１】
ここで、生成されたＦＢＵメッセージの形式と内容を、図１３に示す。
【００９２】
図１３に示すように、本発明の一実施形態に係るＦＢＵメッセージ４３０は、ＭＮ２００のＰＬＣｏＡアドレス４３１、ＰＡＲ３００のアドレス４３２、ルーティングヘッダー４３３、移動性ヘッダー４３４、ＭＡＰ７００のアドレス４３５、ＭＮ２００のＮＬＣｏＡアドレス４３６、ＮＡＲ４００のＩＰアドレス４３７及びＭＮ２００のリンク階層アドレス４３８を含む。
【００９３】
ここで、ＭＮ２００のＰＬＣｏＡアドレス４３１、ＰＡＲ３００のアドレス４３２、ルーティングヘッダー４３３は、ＩＰヘッダー領域（ＩＰ  ＨＤＲ）に相当するものであって、ＭＮ２００のＰＬＣｏＡアドレス４３１は、該当メッセージの出発地アドレスであり、ＰＡＲ３００のアドレス４３２は、該当メッセージの目的地アドレスである。そして、ルーティングヘッダー４３３は、次のヘッダー情報を示す。
【００９４】
一方、移動性ヘッダー４３４、ＭＡＰ７００のアドレス４３５は、ルーティングヘッダー（ｒｏｕｔｉｎｇ  ＨＤＲ）に相当するものであって、移動性ヘッダー４３４は、次のヘッダー情報であり、ＭＡＰ７００のアドレス４３５は、ＩＰアドレスである。
【００９５】
また、ＭＮ２００のＮＬＣｏＡアドレス４３６、ＮＡＲ４００のＩＰアドレス４３７、ＭＮ２００のリンク階層アドレス４３８は、移動性ヘッダー（ｍｏｂｉｌｉｔｙ  ｈｅａｄｅｒ）であって、バインディングアップデート情報である。ここで、ＮＬＣｏＡアドレス４３６は、ＭＮ２００が移動した位置で使用する動的アドレスであり、ＮＡＲ４００のＩＰアドレス４３７は、ＭＮ２００の移動先の新しいＮＡＲのＩＰアドレスである。
【００９６】
さらに図１０を参照すれば、ＦＢＵメッセージを受信したＰＡＲ３００が目的地アドレスとしてＰＬＣｏＡを有するパケットＰＫＴ（ＰＬＣｏＡ）を受信すれば（ステップＳ４２５）、ＰＡＲ３００は、そのパケットＰＫＴ（ＰＬＣｏＡ）をバッファリングする（ステップＳ４２７）。
【００９７】
一方、ＰＡＲ３００からＦＢＵメッセージを受信したＭＡＰ７００は、ＭＮ２００の移動を支援するために、ＮＡＲ４００にハンド−オーバー初期化（Ｈａｎｄ−ｏｖｅｒ  Ｉｎｉｔｉａｔｅ、以下、“ＨＩ”という。）メッセージを転送する（ステップＳ４２９)。このメッセージには、ＦＭＩＰｖ６プロトコルで定義されたＭＮ２００のリンク階層アドレスとＰＬＣｏＡ及びＮＬＣｏＡアドレス、そしてＰＡＲ３００のアドレス（例えば、ＰＡＲアドレスオプション）が含まれる。このＰＡＲアドレスオプションは、ＰＬＣｏＡアドレスオプションと同じ形式を有する。
【００９８】
ＨＩメッセージを受信したＮＡＲ４００は、重複アドレスを確認することによって、ＭＮ２００が使用しようとするＮＬＣｏＡを使用可能か否かを確認する。すなわち、ＭＮのＮＣｏＡが既に使われているか否かを確認する。そして、ＨＩメッセージに対する応答メッセージ（Ｈａｎｄ−ｏｖｅｒ  ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ  ｍｅｓｓａｇｅ、以下、“Ｈａｃｋメッセージ”という。）メッセージをＭＡＰ７００に転送する（ステップＳ４３１）。
【００９９】
ＮＡＲ４００からＨＩメッセージに対する応答メッセージ（Ｈａｃｋメッセージ）が送信されれば、ＭＡＰ７００は、高速のハンドオーバー手続が完了したと判断し、ＦＢ＿ａｃｋメッセージ（Ｆａｓｔ  Ｂｉｎｄｉｎｇ  Ａｃｋ  ｍｅｓｓｇａｅ）をＰＡＲ３００に送信した後（ステップＳ４３３）、ＮＬＣｏＡを用いてバインディングキャッシュの内容を変更する（“ＰＬＣｏＡ、ＲＣｏＡ”→“ＮＬＣｏＡ、ＲＣｏＡ”）（ステップＳ４４７）。
【０１００】
これにより、ＭＡＰ７００は、ＭＮ２００に関する全てのパケットをＮＬＣｏＡにトンネリングする。
【０１０１】
一方、ＦＢ＿ａｃｋメッセージを受信したＰＡＲ３００は、ＭＮ２００及びＮＡＲ４００にＦＢ＿ａｃｋメッセージを送信する(ステップＳ４３５、ステップＳ４３７)。すなわち目的地アドレスとしてＰＬＣｏＡを有するＦＢ＿ａｃｋメッセージを作成し、直接ＭＮ２００に転送し（ステップＳ４３５）、目的地アドレスとしてＮＬＣｏＡを有するＦＢ＿ａｃｋメッセージを作成し、ＮＡＲ４００に転送する（ステップＳ４３７）。
【０１０２】
また、ＰＡＲ３００は、今までバッファリングされたパケット、すなわち、目的地アドレスとしてＰＬＣｏＡを有するパケットＰＫＴ（ＰＬＣｏＡ）をＮＡＲ４００にトンネリングする。すなわち、ＮＡＲ４００に送信され（ステップＳ４３９)、ＮＡＲ４００にバッファリングされる（ステップＳ４４３）。そして、バッファリングされたパケットの転送が完了すれば（すなわち、ＰＡＲ３００内のバッファがエンプティー（空）の場合には）（ステップＳ４４１）、ＰＡＲ３００は、送信するパケットがこれ以上ないことをＮＡＲ４００に知らせるための所定のメッセージ（例えば、Ｆｌｕｓｈメッセージ）をＮＡＲ４００に転送する（ステップＳ４４５）。Ｆｌｕｓｈメッセージの形式と内容を図１４に示す。
【０１０３】
図１４に示すように、Ｆｌｕｓｈメッセージ４４０は、出発地アドレスと、目的地アドレス及び次のヘッダー情報を含むＩＰ  ＨＤＲ領域と、Ｆｌｕｓｈ状態情報(すなわち、送信するパケットが存在するか否かを識別するための情報)と、移動前の動的アドレス情報(ＭＮのＰＬＣｏＡ)を含む移動性ＨＤＲを含む。図１４の例で、ＰＡＲ３００のアドレス４４１は、出発地アドレスであり、ＭＮ２００のＮＬＣｏＡは、目的地アドレスであり、移動性ＨＤＲ４４３は、次のヘッダー情報であり、Ｆｌｕｓｈ４４４は、Ｆｌｕｓｈ状態情報であり、ＭＮ２００のＰＬＣｏＡは、移動前の動的アドレスである。
【０１０４】
一方、ＨＡＧＴ５００またはＣＮ６００からＭＡＰ７００にパケットＰＫＴＭＮが送信されると（ステップＳ４４９）、ＭＡＰ７００は、該パケットＰＫＴＭＮをＮＬＣｏＡにカプセル化し（ステップＳ４５１）、ＮＡＲ４００に転送する（ステップＳ４５３）。以下の説明では、ＮＬＣｏＡにカプセル化したパケットをＰＫＴ（ＮＬＣｏＡ）で表記する。
【０１０５】
ＰＫＴ（ＮＬＣｏＡ）を受信したＮＡＲ４００は、ＰＫＴ（ＮＬＣｏＡ）をバッファリングする（ステップＳ４５５）。すなわち、ＮＡＲ４００は、ＭＮ２００からＭＮ２００の移動を知らせるためのＦＮＡメッセージを受信するときまで、ＰＡＲ３００から送信されるＰＫＴ（ＰＬＣｏＡ）と、ＭＡＰ７００から送信されるＰＫＴ（ＮＬＣｏＡ）を全てバッファリングする。
【０１０６】
ここで、ＰＫＴ（ＰＬＣｏＡ）は、ＰＫＴ（ＮＬＣｏＡ）より先に受信されたものである。したがって、ＮＡＲ４００は、ＰＫＴ（ＰＬＣｏＡ）をＰＫＴ（ＮＬＣｏＡ）よりも先にＭＮ２００に転送しなければならない。このために、ＮＡＲ４００は、ＰＫＴ（ＰＬＣｏＡ）をバッファリングするための第１のバッファと、ＰＫＴ（ＮＬＣｏＡ）をバッファリングするための第２のバッファとを含むことが好ましい。
【０１０７】
一方、ＰＡＲ３００からＦＢ＿ａｃｋメッセージを受信したＭＮ２００は、自機の動的アドレスを変更する（ＰＬＣｏＡ→ＮＬＣｏＡ）（ステップＳ４５７）。そして、ＭＮ２００がＮＡＲ領域に移動すれば（ステップＳ４５９）、ＭＮ２００は、自機の移動をＮＡＲ４００に知らせるために、ＦＮＡメッセージをＮＡＲ４００に転送する（ステップＳ４６１）。
【０１０８】
次に、ＮＡＲ４００は、まずＰＫＴ（ＰＬＣｏＡ）をＭＮ２００に転送し（ステップＳ４６３）、ＰＫＴ（ＮＬＣｏＡ）をＭＮ２００に転送する（ステップＳ４６５）。すなわち、第１のバッファの内容を全て転送した後、第２のバッファの内容を転送する。
【０１０９】
ここで、ＮＡＲ４００がＦＮＡメッセージを受信するときまでに、ＰＡＲ３００からＦｌｕｓｈメッセージを受信しない場合には、ＮＡＲ４００は、Ｆｌｕｓｈメッセージを受信するときまで第１のバッファの内容をＭＮ２００に転送し、Ｆｌｕｓｈメッセージを受信すれば、ＰＡＲ３００から送信されるパケットがこれ以上存在しないと判断し、ＰＡＲ３００と設定されたトンネルを終了する。そして、第２のバッファの内容をＭＮ２００に転送する。
【０１１０】
図１５は、本発明の他の実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換手続を示す図であって、図１５を参照すれば、本発明の他の実施形態に係るＭＩＰｖ６網においてトラフィック交換手続は、次の通りである。すなわち、ＭＮ２００が移動した後に、アドレスが変更された場合（ｒｅａｃｔｉｖｅ）に関する本発明のトラフィック交換手続は、次の通りである。
【０１１１】
ＭＮ２００が他のＭＡＰドメインからＭＡＰ７００ドメインに移動した場合には、ＭＮ２００に関するバインディングアップデート処理（ローカルバインディングアップデートを含む）は、ｐｒｅｄｉｃｔｉｖｅである場合やｒｅａｃｔｉｖｅである場合がいずれも同一である。したがって、ＭＮ２００のバインディングアップデートステップＳ５０１乃至ステップＳ５１３は、図１０に示すステップＳ４０１乃至ステップＳ４１３と同様である。すなわち、図１５のステップＳ５０１乃至ステップＳ５１３の各々は、図１０のステップＳ４０１乃至ステップＳ４１３に対応する。したがって、バインディングアップデート処理に関する具体的な説明は省略する。
【０１１２】
そして、上記のように、バインディングアップデートを行ったＭＮ２００が所定のステップＳ５１５、ステップＳ５１７、ステップＳ５１９を経てＮＬＣｏＡを構成した後、ＮＡＲ領域に移動すれば（ステップＳ５２１）、ＭＮ２００は、自機の移動をＮＡＲ４００に知らせるためにＦＮＡメッセージをＮＡＲ４００に転送する（ステップＳ５２３）。
【０１１３】
ここで、ステップＳ５１５、ステップＳ５１７、ステップＳ５１９は、図１０のステップＳ４１５、ステップＳ４１７、ステップＳ４１９の各々と同様なので、その具体的な説明は省略する。一方、ステップＳ５２３で送信されるＦＮＡメッセージには、アドレス情報ＮＬＣｏＡを含むメッセージ（ＦＢＵメッセージ）を含む。
【０１１４】
次に、ＮＡＲ４００は、ＦＢＵメッセージに基づいてＮＬＣｏＡをＰＡＲ３００に送信する（ステップＳ５２５）。
【０１１５】
一方、ＮＬＣｏＡを含むＦＢＵメッセージを受信したＰＡＲ３００は、そのアドレス情報をＭＡＰ７００に送信した後（ステップＳ５２７）、ＰＬＣｏＡを目的地アドレスとするパケットＰＫＴ（ＰＬＣｏＡ）の受信に応答し（ステップＳ５２９）、該パケットＰＫＴ（ＰＬＣｏＡ）をバッファリングする（ステップＳ５３１）。
【０１１６】
そして、その後のステップＳ５３３乃至ステップＳ５６１での処理は、図１０に示すステップＳ４３３乃至ステップＳ４６５での処理と同様である。但し、図１０で、ＭＮ２００がＮＡＲに移動した後（ステップＳ４５９）、その事実をＮＡＲ４００に知らせるステップＳ４６１が図１５ではパケット受信前に、ＭＮ２００がＮＡＲ４００に移動するという点だけが異なる。したがって、ステップＳ５３３乃至ステップＳ５６１に関する具体的な説明は省略する。
【０１１７】
図１０及び図１５を参照すれば、本発明は、ＦＭＩＰｖ６を適用するにあたって、ＮＡＲ４００がＰＡＲ３００から転送されたパケットＰＫＴ（ＰＬＣｏＡ）を全てＭＮ２００に転送した後、ＭＡＰ７００から転送されたパケットＰＫＴ（ＮＬＣｏＡ）を転送することによって、ＭＮ２００に転送されるパケットの順序がずれないようにすることができる。すなわち、ＰＡＲ３００から、パケットＰＫＴ（ＰＬＣｏＡ）が全て転送されたことを知らせる所定メッセージ（Ｆｌｕｓｈメッセージ）をＰＡＲ３００がＮＡＲ４００に送信し、ＮＡＲ４００は、該メッセージを受信するときまでＭＡＰ７００から転送されたパケットＰＫＴ（ＮＬＣｏＡ）の転送を保留することによって、パケット順序のずれを防止することができるようになる。
【０１１８】
以上において説明した本発明は、本発明が属する技術の分野における通常の知識を有する者であれば、本発明の技術的思想を逸脱しない範囲内で、様々な置換、変形及び変更が可能であるので、上述した実施形態及び添付された図面に限定されるものではない。
【図面の簡単な説明】
【０１１９】
【図１】ＭＩＰｖ６プロトコルが適用されたＭＩＰｖ６網に関するシステム構成図である。
【図２】通常のモバイルＩＰｖ６網において移動ホストのトラフィック交換手続の例を示す図である。
【図３】通常のモバイルＩＰｖ６網において移動ホストのトラフィック交換手続の例を示す図である。
【図４】階層的モバイルＩＰｖ６網に関する構成図である。
【図５】階層的モバイルＩＰｖ６網において移動ホストのトラフィック交換手続の例を示す図である。
【図６】階層的モバイルＩＰｖ６網において移動ホストのトラフィック交換手続の例を示す図である。
【図７】モバイルＩＰｖ６網において移動ホストのトラフィック交換のための高速ハンドオーバー処理の例を示す図である。
【図８】モバイルＩＰｖ６網において移動ホストのトラフィック交換のための高速ハンドオーバー処理の例を示す図である。
【図９】本発明の実施形態に係るモバイルＩＰｖ６網に関する構成図である。
【図１０】本発明の一実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換手続を示す図である。
【図１１】本発明の一実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換時に転送されるメッセージの構成例を示す図である。
【図１２】本発明の一実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換時に転送されるメッセージの構成例を示す図である。
【図１３】本発明の一実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換時に転送されるメッセージの構成例を示す図である。
【図１４】本発明の一実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換時に転送されるメッセージの構成例を示す図である。
【図１５】本発明の他の実施形態に係るモバイルＩＰｖ６網において移動ホストのトラフィック交換手続を示す図である。
【符号の説明】
【０１２０】
１００  インターネット
２００  ＭＮ
３００  ルータ
４００  ルータ
５００  ホームエージェント
６００  ＣＮ
７００  ＭＡＰ
８００  イントラネット
【図１】
2006246481.tif 000003
【図２】
2006246481.tif 000004
【図３】
2006246481.tif 000005
【図４】
2006246481.tif 000006
【図５】
2006246481.tif 000007
【図６】
2006246481.tif 000008
【図７】
2006246481.tif 000009
【図８】
2006246481.tif 000010
【図９】
2006246481.tif 000011
【図１０】
2006246481.tif 000012
【図１１】
2006246481.tif 000013
【図１２】
2006246481.tif 000014
【図１３】
2006246481.tif 000015
【図１４】
2006246481.tif 000016
【図１５】
2006246481.tif 000017