JP4248556B2 - モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法 - Google Patents

モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法 Download PDF

Info

Publication number
JP4248556B2
JP4248556B2 JP2006055885A JP2006055885A JP4248556B2 JP 4248556 B2 JP4248556 B2 JP 4248556B2 JP 2006055885 A JP2006055885 A JP 2006055885A JP 2006055885 A JP2006055885 A JP 2006055885A JP 4248556 B2 JP4248556 B2 JP 4248556B2
Authority
JP
Japan
Prior art keywords
router
address
dynamic address
mobile host
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006055885A
Other languages
English (en)
Other versions
JP2006246481A (ja
Inventor
宰 薫 李
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2006246481A publication Critical patent/JP2006246481A/ja
Application granted granted Critical
Publication of JP4248556B2 publication Critical patent/JP4248556B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H02—GENERATION; CONVERSION OR DISTRIBUTION OF ELECTRIC POWER
    • H02J—CIRCUIT ARRANGEMENTS OR SYSTEMS FOR SUPPLYING OR DISTRIBUTING ELECTRIC POWER; SYSTEMS FOR STORING ELECTRIC ENERGY
    • H02J7/00—Circuit arrangements for charging or depolarising batteries or for supplying loads from batteries
    • H02J7/0029—Circuit arrangements for charging or depolarising batteries or for supplying loads from batteries with safety or protection devices or circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
    • H04W36/0019—Control or signalling for completing the hand-off for data sessions of end-to-end connection adapted for mobile IP [MIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/085—Mobility data transfer involving hierarchical organized mobility servers, e.g. hierarchical mobile IP [HMIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

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

Claims (12)

  1. モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法であって、
    第１の動的アドレスを用いて第１のルータに接続された状態で第２のルータに接続された接続装置からリンク階層信号を受信した移動ホストの要求に応答して、前記第１のルータが前記移動ホストに前記第２のルータの網情報を提供するステップと、
    前記移動ホストが前記第１のルータ及び第２のルータとイントラネットで接続されたローカルホームエージェントと第１のルータに前記第２のルータの網情報を用いた前記移動ホストの第２の動的アドレスが含まれた高速バインディングアップデート（Fast Binding Update）メッセージを送信するステップと、
    前記第１のルータが前記移動ホストから前記高速バインディングアップデートメッセージを受信して第１の動的アドレスを目的地とするパケットをバッファリングする第１のバッファリングステップと、
    前記第２のルータが前記高速バインディングアップデートメッセージを受信したローカルホームエージェントの要求によって前記第２の動的アドレスの使用可能性を確認するステップと、
    前記ローカルホームエージェントは前記第２の動的アドレスが使用可能な場合、前記高速バインディングアップデートの完了（Fast Binding Ａｃｋ）メッセージを前記第１のルータに送信し、前記移動ホストの高速バインディングアップデートを実行するステップと、
    前記第１のルータが、前記ローカルホームエージェントから受信した前記高速バインディングアップデートの完了メッセージに応答して、第１のバッファリングステップでバッファリングされたパケットを前記第２のルータに転送し、前記第１のバッファリングステップでバッファリングされた全てのパケットを前記第２のルータに転送した場合には、これを知らせる転送完了メッセージを送信するステップと、
    前記第２のルータが前記第１のルータから転送されたパケットをバッファリングする第２のバッファリングステップと、
    前記第２のルータが第２の動的アドレスを目的地とするパケットを受信し、バッファリングする第３のバッファリングステップと、
    前記移動ホストが、前記第１のルータから前記第２のルータに移動したことを知らせる移動完了メッセージを第２のルータに送信すれば、該移動完了メッセージに応答して、前記第２のルータが第２のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、
    前記第２のルータが前記転送完了メッセージを受信すれば、前記第２のバッファリングステップでバッファリングされたパケットの送信ステップ終了後に、前記第３のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、
    を備えることを特徴とするトラフィック交換方法。
  2. 前記ローカルホームエージェントの網情報を用いた前記移動ホストの地域動的アドレスを生成するステップと、
    前記移動ホストの第１の動的アドレスと前記地域動的アドレスを前記ローカルホームエージェントに格納するローカルバインディングアップデートステップと、
    前記移動ホストのホームアドレスと前記地域動的アドレスをホームエージェントに格納するバインディングアップデートステップと、をさらに備えることを特徴とする請求項１に記載のトラフィック交換方法。
  3. 前記転送完了メッセージは、
    前記第１のルータのアドレスを格納する出発地アドレスフィールドと、
    前記第２の動的アドレスを格納する目的地アドレスフィールドと、
    前記転送が完了したことを知らせるフラグ情報を格納するフィールドと、を含むことを特徴とする請求項１又は２に記載のトラフィック交換方法。
  4. 前記第２の動的アドレスを使用可能な場合には、前記第２の動的アドレスを用いて前記ローカルホームエージェントに格納されたローカルバインディングアップデート情報を変更するステップをさらに備えることを特徴とする請求項２に記載のトラフィック交換方法。
  5. 前記変更ステップは、前記第２の動的アドレスと前記地域動的アドレスとをマッピングさせることを特徴とする請求項４に記載のトラフィック交換方法。
  6. 前記移動ホストのホームアドレスを目的地とするパケットが受信されると、前記ローカルホームエージェントは、該パケットの目的地を前記第２の動的アドレスに変更し、前記第２のルータに送信することを特徴とする請求項５に記載のトラフィック交換方法。
  7. モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法であって、
    第１の動的アドレスを用いて第１のルータに接続された状態で第２のルータに接続された接続装置からリンク階層信号を受信した移動ホストの要求に応答して、前記第１のルータが前記移動ホストに前記第２のルータの網情報を提供するステップと、
    前記第２のルータが前記第２のルータの網情報を用いた前記移動ホストの第２の動的アドレスが含まれた高速バインディングアップデート（Fast Binding Update）メッセージを含む前記移動ホストの移動完了（Fast Neighbor Advertisement）メッセージを受信するステップと、
    前記第２のルータが前記移動ホストの第２の動的アドレスを前記高速バインディングアップデートメッセージを介して前記第１のルータに送信するステップと、
    前記第１のルータが前記高速バインディングアップデートメッセージに含まれた第２の動的アドレスを前記第１のルータ及び第２のルータとイントラネットで接続されたローカルホームエージェントに送信した後、第１の動的アドレスを目的地とするパケットをバッファリングする第１のバッファリングステップと、
    前記ローカルホームエージェントが、前記高速バインディングアップデートの完了（Fast Binding Ａｃｋ）メッセージを前記第１のルータに送信し、前記移動ホストの高速バインディングアップデートを実行するステップと、
    前記第１のルータが、前記ローカルホームエージェントから受信した前記高速バインディングアップデートの完了メッセージに応答して、前記第１のルータが第１のバッファリングステップでバッファリングされたパケットを前記第２のルータに転送し、前記第１のバッファリングステップでバッファリングされた全てのパケットを前記第２のルータに転送した場合には、これを知らせる転送完了メッセージを前記第２のルータに送信するステップと、
    前記第２のルータが前記第１のルータから転送されたパケットをバッファリングする第２のバッファリングステップと、
    前記第２のルータが第２の動的アドレスを目的地とするパケットを受信し、バッファリングする第３のバッファリングステップと、
    前記第２のルータが第２のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、
    前記第２のルータが前記転送完了メッセージを受信すれば、前記第２のバッファリングステップでバッファリングされたパケットの送信ステップ終了後に、前記第３のバッファリングステップでバッファリングされたパケットを前記移動ホストに送信するステップと、
    を備えることを特徴とするトラフィック交換方法。
  8. 前記ローカルホームエージェントの網情報を用いた前記移動ホストの地域動的アドレスを生成するステップと、
    前記移動ホストの第１の動的アドレスと前記地域動的アドレスを前記ローカルホームエージェントに格納するローカルバインディングアップデートステップと、
    前記移動ホストのホームアドレスと前記地域動的アドレスをホームエージェントに格納するバインディングアップデートステップと、をさらに備えることを特徴とする請求項７に記載のトラフィック交換方法。
  9. 前記転送完了メッセージは、
    前記第１のルータのアドレスを格納する出発地アドレスフィールドと、
    前記第２の動的アドレスを格納する目的地アドレスフィールドと、
    前記転送が完了したことを知らせるフラグ情報を格納するフィールドと、を含むことを特徴とする請求項７又は８に記載のトラフィック交換方法。
  10. 前記第２の動的アドレスを使用可能な場合には、前記第２の動的アドレスを用いて前記ローカルホームエージェントに格納されたローカルバインディングアップデート情報を変更するステップをさらに備えることを特徴とする請求項８に記載のトラフィック交換方法。
  11. 前記変更ステップは、前記第２の動的アドレスと前記地域動的アドレスとをマッピングさせることを特徴とする請求項１０に記載のトラフィック交換方法。
  12. 前記移動ホストのホームアドレスを目的地とするパケットが受信されると、前記ローカルホームエージェントは、該パケットの目的地を前記第２の動的アドレスに変更し、前記第２のルータに送信することを特徴とする請求項１１に記載のトラフィック交換方法。
JP2006055885A 2005-03-03 2006-03-02 モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法 Expired - Fee Related JP4248556B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR20050017732A KR100582731B1 (ko) 2005-03-03 2005-03-03 모바일 ＩＰｖ6 망에서 이동 호스트를 이용한 트래픽 교환방법

Publications (2)

Publication Number Publication Date
JP2006246481A JP2006246481A (ja) 2006-09-14
JP4248556B2 true JP4248556B2 (ja) 2009-04-02

Family

ID=36121427

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006055885A Expired - Fee Related JP4248556B2 (ja) 2005-03-03 2006-03-02 モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法

Country Status (5)

Country Link
US (1) US7720059B2 (ja)
EP (1) EP1699254B1 (ja)
JP (1) JP4248556B2 (ja)
KR (1) KR100582731B1 (ja)
DE (1) DE602006018082D1 (ja)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7917152B2 (en) * 2003-06-27 2011-03-29 Nokia Corporation Enhanced fast handover procedures
KR100893213B1 (ko) * 2005-07-08 2009-04-16 삼성전자주식회사 모바일 네트워크에 있어서 데이터 처리 장치 및 그 방법
KR100813987B1 (ko) * 2005-12-30 2008-03-14 삼성전자주식회사 더 신속한 Ｌ２ 핸드오버를 트리거하기 위해ＦＭＩＰｖ６를 이용하는 방법 및 장치
CN100596095C (zh) * 2006-02-23 2010-03-24 华为技术有限公司 层次化移动IPv6快速切换方法和系统
JP4905061B2 (ja) 2006-11-08 2012-03-28 日本電気株式会社 移動通信システム、基地局装置およびそのハンドオーバ方法ならびにプログラム
US8768357B2 (en) * 2007-04-25 2014-07-01 Qualcomm Incorporated Changes of forward-link and reverse-link serving access points
JP4924501B2 (ja) * 2008-03-21 2012-04-25 富士通株式会社 ゲートウェイ装置、及びハンドオーバ方法
US20120063428A1 (en) * 2008-10-08 2012-03-15 Panasonic Corporation Interface Switching System, Mobile Node, Proxy Node, and Mobile Management Node
WO2010052918A1 (ja) * 2008-11-07 2010-05-14 パナソニック株式会社 ハンドオーバ制御システム、ユーザ端末、シグナリング中継装置並びにセッション制御装置
JP2010157908A (ja) 2008-12-26 2010-07-15 Ntt Docomo Inc 移動通信方法、無線アクセス装置及びゲートウェイ装置
US9148373B2 (en) * 2010-07-30 2015-09-29 Intellectual Discovery Co., Ltd. Network system
US8498414B2 (en) * 2010-10-29 2013-07-30 Telefonaktiebolaget L M Ericsson (Publ) Secure route optimization in mobile internet protocol using trusted domain name servers
CN103339988B (zh) * 2011-01-31 2017-05-31 英迪股份有限公司 网络系统
CN102158845B (zh) * 2011-05-23 2013-07-10 山东大学 一种HMIPv6切换性能优化方法
CN108347723B (zh) * 2017-01-25 2021-01-29 华为技术有限公司 一种切换方法和装置

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3442257B2 (ja) 1997-05-06 2003-09-02 日本電信電話株式会社 パケット通信方法
JP4491980B2 (ja) 2001-03-05 2010-06-30 ソニー株式会社 通信処理システム、通信処理方法、および通信端末装置、並びにプログラム
US6826154B2 (en) * 2001-05-24 2004-11-30 3Com Corporation Method and apparatus for seamless mobility between different access technologies
US6832087B2 (en) 2001-11-30 2004-12-14 Ntt Docomo Inc. Low latency mobile initiated tunneling handoff
KR100438443B1 (ko) * 2001-12-12 2004-07-03 삼성전자주식회사 이동통신시스템에서 핸드오프 수행방법
JP3822120B2 (ja) 2002-03-06 2006-09-13 松下電器産業株式会社 パケット通信方法
JP3997826B2 (ja) 2002-04-23 2007-10-24 松下電器産業株式会社 Ｉｐアドレス生成方法及び無線基地局装置
JP2004015143A (ja) 2002-06-04 2004-01-15 Fujitsu Ltd 移動通信システムにおけるハンドオーバ方法、および移動通信システムにおいて使用されるルータ装置
KR100474451B1 (ko) * 2002-08-16 2005-03-10 삼성전자주식회사 지역화 이동성 관리를 지원하는 이동 ＩＰｖ６에서최적화된 패킷 라우팅 방법
JP3946153B2 (ja) 2003-02-26 2007-07-18 株式会社エヌ・ティ・ティ・ドコモ 通信システム、移動端末、転送装置
US7035640B2 (en) * 2003-05-15 2006-04-25 Motorola, Inc. Method for improving the reliability of low latency handoffs
KR20050003566A (ko) * 2003-06-27 2005-01-12 주식회사 케이티 무선통신 시스템에서 바인딩 캐쉬를 이용한 연속적 로밍방법
WO2005053187A1 (en) * 2003-11-26 2005-06-09 Electronics And Telecommunications Research Institute Access router based mobile ipv6 fast handover method

Also Published As

Publication number Publication date
US7720059B2 (en) 2010-05-18
EP1699254A1 (en) 2006-09-06
DE602006018082D1 (de) 2010-12-23
JP2006246481A (ja) 2006-09-14
KR100582731B1 (ko) 2006-05-22
US20060198372A1 (en) 2006-09-07
EP1699254B1 (en) 2010-11-10

Similar Documents

Publication Publication Date Title
JP4248556B2 (ja) モバイルＩＰｖ６網における移動ホストのためのトラフィック交換方法
Yokota et al. Fast handovers for proxy mobile IPv6
US7342903B2 (en) Methods and apparatus for the utilization of multiple uplinks in reverse tunneling
KR100763534B1 (ko) ＩＰｖ６ 기반 모바일 시스템에서 빠른 리액티브핸드오버를 수행하는 장치
US8144660B2 (en) Multimode terminal for supporting fast handover between heterogeneous networks
US7330449B2 (en) Mobile node, mobility control apparatus, communication control method, communication system, and data format
US8254929B2 (en) Mobile communication method and mobile communication apparatus
US20060240825A1 (en) Mobile communication method, mobile communication apparatus, home agent apparatus, access router information server apparatus, and mobile communication system
US20090097453A1 (en) Method and system for fast handovers using dynamic router advertisements
KR101400415B1 (ko) 네트워크 기반 서비스 플로우 바인딩 방법
US20090147751A1 (en) Method of applying fast mobile ipv6 for mobile nodes in mobile networks, mobile router therefor, and mobile network therefor
JP2009529267A (ja) 移動通信システムでの移動ノード用のデフォルト・ルータの高速構成
JPWO2009057296A1 (ja) 移動端末及びネットワークノード並びにパケット転送管理ノード
US8400980B2 (en) Fast handover system and method thereof
EP2208380B1 (en) Method for controlling proxy binding of a mobile node
WO2010073620A1 (ja) ハンドオーバ方法、その方法で用いられる移動端末及びホームエージェント
JP4175855B2 (ja) 移動ネットワークおよびその通信管理方法
EP1494405B1 (en) Mobile node, mobile communication system, communication control method and access router
JP2007281721A (ja) 移動通信制御方法、移動通信システム及びルータ
KR101018856B1 (ko) 무선 접속 망에서의 핸드오프에 따른 패킷 포워딩 장치 및방법
KR102230823B1 (ko) 상황인지 기반 트래픽 경로최적화 관리 방법
KR20070115823A (ko) 프록시 모바일 아이피에서 고속 경로 최적화 기법
JP2003274436A (ja) 移動ノード、移動通信システム及び通信制御プログラム
KR20070007994A (ko) 무선 네트워크에서의 핸드오버 방법
Zohra et al. Overview of ipv6 mobility management protocols and their handover performances

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080612

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080729

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081028

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20081224

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090113

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120123

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4248556

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130123

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees