JP4317215B2 - 移動端末管理装置及び移動端末並びに通信システム - Google Patents

Description

本発明は、移動端末（モバイル端末、モバイルノード）が移動を行った場合でも、所定の通信ネットワークへの接続を維持することを可能とする通信技術に関する。

無線技術の出現と発展によって、モバイル（異なるドメイン間を移動し、トランスポートセッションの進行中に、異なる場所のパケット交換データ通信ネットワークに異なる接続ポイントで接続するという意味）である端末が、ますます増加してきている。このようなローミングの機能は、インターネットプロトコルバージョン４（ＩＰｖ４）（下記の非特許文献２）のモバイルＩＰｖ４（下記の非特許文献１）や、インターネットプロトコルバージョン６（ＩＰｖ６）（下記の非特許文献４）のモバイルＩＰｖ６（下記の非特許文献３）などの解決策によって提供されている。

モバイルＩＰでは、各モバイルノードは、永続的なホームドメインを有しており、モバイルノードが、自身のホームネットワークに接続している場合には、ホームアドレスとして知られる永続的に使用可能なグローバルアドレスが割り当てられている。一方、モバイルノードがホームネットワークから離れており、すなわち、他のフォーリンネットワークに接続している場合には、通常、気付アドレス（Care-of-address）として知られる一時的なグローバルアドレスが割り当てられる。モビリティサポートの考え方は、モバイルノードが他のフォーリンネットワークに接続した状態でさえ、ホームアドレスによって、その位置を特定可能とするものである。上記の事柄は、下記の非特許文献１や非特許文献３において、ホームエージェントとして知られるホームネットワークのエンティティの導入によって実現されている。

モバイルノードは、バインディングアップデートとして知られるメッセージを利用して、ホームエージェントに気付アドレスの登録を行う。また、ホームエージェントは、モバイルノードのホームアドレスを送信先とするメッセージを受信（intercept）し、IP-in-IPトンネリング（下記の非特許文献５及び下記の非特許文献６）を利用して、そのパケットをモバイルノードの気付アドレスあてに転送するよう要請されている。IP-in-IPトンネリングでは、オリジナルのＩＰパケットを別のＩＰパケットによってカプセル化することが行われる。オリジナルのパケットは、インナパケットと呼ばれることがあり、インナパケットをカプセル化するための新しいパケットはアウタパケットと呼ばれることがある。

しかしながら、双方向トンネルによる単純なアプローチでは、ＩＰｖ４やＩＰｖ６における他の効果的な特徴（例えばマルチ・ホーミングなど）における要求を十分に満たすことはできない。グローバルネットワークへの独立したルートを提供する外部ネットワーク側インタフェース（イグレスインタフェース：egress interface）が複数存在する場合には、ノードはマルチホームとなり得る。これらのインタフェースがすべて、同一のルータに属する場合には、そのルータのみがマルチホームとなる。一方、これらのインタフェースがそれぞれ独立したルータに属する場合には、これらのルータが集合して存在するサイトやネットワークもマルチホームとなる。

現在、マルチホーミングの利点が、完全に活用されているわけではない。トランスポートレイヤでマルチホーミングをサポートする１つの解決策が提供されている（下記の特許文献１）。独立したフロントエンドプロセッサで構成されたホストシステムにトランスポートプロバイダを設けることによって、各トランスポートプロバイダがネットワークプロトコルスタックを有し、異なるネットワークや、同一ネットワークの異なる部分に接続して、ホストシステム上で実行される異なるタイプのアプリケーションからの様々な要求に応える完全なマルチホーミングのサポートが提供される。しかしながら、この解決策は、モバイルＩＰよりも高次のネットワークレイヤでなされるものであり、無線接続の切り換えが散発的にしか起こらない状況では、十分な応答を行わないこともあり得る。さらに、ＩＰ又はネットワークレイヤにおける変化と比較した場合、トランスポートレイヤにおける変化に伴うオーバヘッドの非効率性はかなり高い。

また、ホームエージェント間の通信に関して、別の解決策が提案されている（下記の非特許文献７）。関連するホームエージェントは、まず、それぞれ識別され、ホームエージェントのデータベースに手入力される必要がある。さらに、モバイルノードが移動する場合、この解決策では、利用可能なあらゆるホームエージェントに対して、すべてのアップデートのマルチキャストを求め、この影響によるオーバヘッドの非効率性によって、この解決策のスケーラビリティが制限される可能性もある。

また、マルチホーミングプロキシ装置に関して、別の解決策が提供されている（下記の特許文献２）。この解決策では、他のタイプのネットワークにパケットのトラフィックを転送するためのメディアゲートウェイを制御するエンティティの調整を行うセントラルエンティティの使用が提案されている。しかしながら、主な焦点は、セントラルエンティティによる負荷バランスの管理であり、２つ以上の管理エンティティ間の通信に関する提案はなされていない。

マルチホームサイト又はマルチホームホストは、同一又は異なるネットワーク上に存在し得る複数のデータリンクに物理的に接続される。これは、ある法人サイトが２つの異なるインターネットサービスプロバイダ（ＩＳＰ：Internet Service Provider）を経由してグローバル通信ネットワークにリンクを有している場合に見られる。また、無線ＬＡＮ（Local Area Network）（IEEE802.11）及びセルラネットワーク（ＧＰＲＳ：General Packet Radio Service）を介して接続を行うノードも、ホストの場合におけるマルチホーミングを表している。マルチホーミングを行う利点の１つは、ネットワークサイト又はノードが、その上り回線（アップリンク）の１つに障害や輻輳が起こった場合に、グローバルネットワークとの間で相互に到達可能とする代替経路を使用できるという点である。

サービスレベルアグリーメント（ＳＬＡ：Service Level Agreement）はネットワークサービスのレベルを保証するプロバイダとクライアントとの契約である。モバイルクライアントのホームエージェントとして機能している際に、特定のリンクにおいてネットワークトラフィックの急上昇が起こった場合、ＩＳＰは、ＳＬＡに規定されている条件を満たすことができない可能性がある。このようにネットワークの速度が低下した場合には、モバイルクライアントは、輻輳したリンクを利用し続けてしまうことになる。したがって、リンクの障害や過剰の輻輳が生じた場合には、モバイルクライアントによる動的なホームエージェントのアドレス探索が、クライアント側で開始されなければならない。

モバイルネットワークの使用がますます普及していくに従って、あるモバイルルータが、そのモバイルネットワーク内のノードのホームエージェントとして機能するようになるという仮定は、決して途方もないことではない。これは、例えば、航空機内のモバイルルータが、長距離フライトの間に、乗客に対してホームエージェントとして機能したり、定期クルーズ船のモバイルルータが、１週間の航海の間に、乗客のノードに対してホームエージェントとして動作したりする場合に当てはまる。通常、モバイルネットワークは、グローバルネットワークと無線接続を行っている。近年、無線技術は非常に進歩しているが、有線ネットワークと比べると、依然として、チャンネルが不安定であり雑音が生じる傾向がある。

しかしながら、モバイルルータとホームエージェントとの間で双方向トンネルメカニズムが採用されている場合には、ホームエージェントが有する複数のインタフェースの１つをデフォルトルータとして選ぶことができるのは接続しているノードである。このインタフェースがグローバルネットワークへの接続に失敗した場合、もはやホームエージェントとモバイルルータとの間のトンネルは維持され得ない。したがって、同一のホームエージェントのルータにおける別のインタフェースが、グローバルネットワークへのアクティブなリンクを持っていたとしても、そのモバイルルータを利用するすべてのノードも、同様にグローバルネットワークへの接続性を失うことになる。そして、モバイルルータ及びモバイルネットワークのノードは、最終的に、それら自身のデフォルトのホームエージェントのインタフェースがもはやグローバルネットワークへのルートを持っていないことに気付いて、代理ホームエージェントを選択することになる。

このような案では、モバイルルータ及びモバイルネットワークのノードが、それら自身のルート探索を実行することに依存している。結局、モバイルルータは、ホームエージェントを切り換えなければならず（例えば、動的なホームエージェントのアドレス探索）、復旧の遅れが生じることになる。復旧において重大な遅れが生じた場合、モバイルネットワークのノードは、現在のデフォルトのルートが落ちている（down）と決定してしまうかもしれない。また、非常に限られた処理能力（例えば、組み込みデバイス）しか持たないモバイルネットワークのノードでは、処理負荷が増大して更なる遅れが生じてしまう。さらに、異なるモバイルルータは、異なるサブネットプリフィックスの通知を行うので、結局、モバイルノードがデフォルトルータを切り換える際に、異なる気付アドレスの使用が必須となってしまう。これにより、モバイルノードは、ホームエージェントへのバインディングアップデートの送信が必要になり、復旧の遅れがさらに増大してしまう。
Perkins, C. E. et. al., "IP Mobility Support", IETF RFC 2002, Oct 1996. DARPA, "Internet Protocol", IETF RFC 791, Sep 1981. Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Draft: draft-ietf-mobileip-ipv6-24.txt, Work In Progress, June 2003. Deering, S., and Hinden, R., "Internet Protocol Version 6 (IPv6) Specification", IETF RFC 2460, Dec 1998. Simpson, W., "IP in IP Tunneling", IETF RFC 1853, Oct 1995. Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6", IETF RFC 2473, Dec 1998. Ryuji Wakikawa, Vijay Devarapalli and Pascal Thubert, "Inter Home Agents Protocol (HAHA)", Internet Draft: draft-wakikawa-mip6-nemo-haha-00.txt, Oct 2003. 米国特許第６１１９１７０号 米国特許公開２００２−１１８６８６号

しかしながら、上述の各文献（特に、非特許文献７）に記載されている技術によれば、モバイルノード／モバイルルータのホームエージェントは、異なる各リンク上に配置された複数のホームエージェントとの間で、バインディングキャッシュ情報やホームエージェントのリスト情報の同期付け（共有）を行う必要がある。この同期付けを行うためには、ホームエージェント間で相互に情報の交換を行う必要があり、すべてのホームエージェントがあらかじめ相互に情報を持つことは大変であるという問題がある。また、何らかのトリガに応じて、オンデマンドにすべてのホームエージェントに対してアップデートの送信を行うようにした場合でも、送信されるアップデートによるトラフィックの増加によって、逆に輻輳を招くことになるという問題がある。さらに、ホームエージェントの切り換えを行うタイミングがモバイルノード／モバイルルータ側の主導で決定されるため、ネットワークの状態を考慮したホームエージェントの切り換えが行われにくくなるとともに、ネットワーク側に障害が起こった場合には、障害発生後にモバイルノード／モバイルルータ側によってホームエージェントの切り換えが行われることになり、障害発生に係る対応が遅くなってしまうという問題がある。

本発明では、ホームエージェントに対して新たな機能が付加され、また、モバイルルータやモバイルノードにも若干の新たな機能が付加される。ホームエージェントは、転送するデータパケットを常に監視する。そして、別のホームエージェントを送信先とするパケットが検出された場合には、そのパケットの送信元及び送信先に関する情報が記録されるとともに、指定されたホームエージェントに対して、メッセージデータパケットが送られ、現在のホームエージェントの利用可能性が通知される。指定されたホームエージェントのイグレスリンクに障害が生じるか、所定のレベルを超える輻輳が発生した場合には、指定されたホームエージェントは、ホームエージェントとして機能するように選択されたモバイルルータやモバイルノードに対して、メッセージデータパケットを送信する。メッセージデータパケットには、例えば、指定されたホームエージェントのアドレスや、別のホームエージェントのアドレスが含まれ、実際の位置情報が、選択されたモバイルルータやモバイルノードに明らかとなる。メッセージデータパケットを受信すると、選択されたモバイルルータやモバイルノードは、本来のホームエージェント登録エントリを終了して、新たなホームエージェントの登録を行う。

本発明によれば、モバイルノードのホームエージェントの変更が可能となり、モバイルノードとそのホームエージェントとの接続性が常に維持されるようにすることが可能になる。また、ネットワーク側の主導でホームエージェントの切り換えが行われるようになり、ネットワークにおける障害発生などのネットワークの状態を考慮して、ホームエージェントの切り換えを、適切、かつ迅速に行うことが可能となる。また、例えば、ＤｏＳ（Denial of Service）攻撃などによって、ホームエージェント又はホームエージェントとのリンクに障害が生じた場合でも、モバイルノードが、別のノードにそのホームエージェントを変更することによって、障害が生じたホームエージェントの管理下にあったモバイルノードの通信に係る接続性が維持されるようになる。

＜第１の実施の形態＞
本発明では、グローバルネットワークを移動するモバイルルータ又はモバイルノードに対して、ホームエージェントとして機能するノードが含まれている。この場合、ホームエージェント自身がモバイルルータの場合もある。本発明では、ホームエージェントが、代理ホームエージェントとしての機能を果たすことが可能な他のノードに関する通知を受けるだけではなく、グローバルネットワークへのルートを受動的に監視することが必要とされる。また、状況に応じて、ホームエージェントは、登録されるモバイルルータ又はモバイルノードを別のインタフェースや代理ホームエージェントに積極的に切り換えることも可能である。

開示される発明の理解を容易とするために、以下の定義が使用される。

「パケット」は、データネットワーク上で伝送可能な、任意のフォーマットのデータの独立した（self-contained）ユニットである。通常、「パケット」は「ヘッダ」部分と「ペイロード」部分の２つの部分により構成される。「ペイロード」部分には、伝送されるデータが含まれており、「ヘッダ」部分には、パケットの伝送を支援するための情報が含まれている。なお、「ヘッダ」部分には、「パケット」の送信者及び受信者のそれぞれを識別するために、送信元アドレス及び送信先アドレスが含まれる必要がある。

「パケットトンネリング」は、別のパケットをカプセルに入れた独立したパケットに関連するものである。「パケットトンネリング」の動作は、パケットの「カプセル化」とも呼ばれる。また、カプセル化されたパケットは、「トンネル化されたパケット」又は「インナパケット」と呼ばれ、「インナパケット」をカプセル化するパケットは「トンネリングパケット」又は「アウタパケット」と呼ばれる。なお、カプセル化されたパケットでは、「インナパケット」全体が、「アウタパケット」のペイロード部分を形成する。

「モバイルノード」は、グローバルデータ通信ネットワークへの接続ポイントを変更するネットワークエレメントである。この「モバイルノード」は、エンドユーザ端末や、グローバルデータ通信ネットワークへの接続ポイントを変更することが可能なゲートウェイ、ルータ、インテリジェントネットワークハブなどの中間的なネットワークエレメントを示すために使用される場合もある。また、「モバイルノード」がエンドユーザ端末の場合には、より明確に「モバイルホスト」と呼ばれ、「モバイルノード」が、ゲートウェイ、ルータ、インテリジェントネットワークハブなどとして機能する中間的なネットワークエレメントの場合には、より明確に「モバイルルータ」と呼ばれる。なお、説明のため、この用語を、「登録されたノード」という用語に置き換えて使用する場合もある。

「登録されたノード（registered node）」は、その登録されたノードのネットワーク上の位置情報を通知して、別のネットワークへの登録を行うネットワークエレメントである。ネットワークエレメント自体は、そのグローバルデータ通信ネットワークへの接続ポイントに対して、静的（static）でも移動可能（mobile）でもよい。なお、説明のため、この用語を、「モバイルノード」という用語に置き換えて使用する場合もある。

「ホームエージェント」は、モバイルノードのホームドメインに存在するネットワークエンティティである。「ホームエージェント」は、モバイルノードがホームネットワークから離れている場合の気付アドレスの登録サービスを行うものであり、モバイルノードのホームアドレスが送信先に設定されているパケットを、モバイルノードの気付アドレスに転送する。

「バインディングアップデート」は、モバイルノードから、そのホームエージェントやコレスポンデントノード（correspondent node）に対して送られるメッセージであり、受信者に対して送信者の現在の気付アドレスの通知を行うメッセージである。これによって、受信者は、モバイルノードのホームアドレスと気付アドレスとの間の関係の「バインディング」を行う。

「バインディングリフレッシュリクエスト」は、ホームエージェントやコレスポンデントノードからモバイルノードに送られるメッセージであり、その受信者に対して、その送信者へのバインディングアップデートメッセージを送るように通知するメッセージである。

なお、以下の記述では、説明のために、特定の数、時間、構造、その他のパラメータなどが、本発明を完全に理解してもらうために詳しく説明されるが、こうした詳細な設定は一例であり、こうした特定の詳細な設定を行わなくても、本発明を実行できることは、当業者にとって自明である。

図１には、本発明の適切な動作を行うためのホームエージェント（１０００）に存在する必要な機能に係る要素が図示されている。なお、ルートマネージャ（１００６）は分離可能であるが、これに関しては、後述の第２の実施の形態で説明する。上位レイヤプロトコル（１００１）は、上位に存在するすべてのプロトコルやアプリケーションレイヤをまとめたものである。ＩＰレイヤもこの上位レイヤプロトコル（１００１）に含まれる。例えば、ＩＣＭＰｖ６（Internet Control Message Protocol version 6）などの通常のＩＰｖ６プロトコルは、パケットフローパス（１０６１）を通じて、ネットワークインタフェース（１００２）にメッセージパケットを直接送出することも可能である。

ネットワークインタフェース（１００２）は、イーサネット（登録商標）カードや、ブルートゥースカードのような無線インタフェースカードなど、複数の利用可能なインタフェースカードを表している。ネットワークインタフェース（１００２）には、ハードウェアを動作させるために必要なソフトウェアドライバやプロトコルが含まれている。パケットフローパス（１０５７）は、イーサネット（登録商標）やＧＰＲＳなどの下層プロトコルによって処理され、インタフェースマネージャ（１００５）に渡されるＩＰレイヤプロトコルデータパケットによって利用される。また、シグナルフローパス（１０５８）は、ハードウェアの障害やその他の故障を上位レイヤのアプリケーションに通知するために、インタフェースによって使用される通知信号を表している。このシグナルフローパス（１０５８）は、電気的な信号やその他の何らかの信号の形式が採用され、インタフェースマネージャ（１００５）への通知に使用される。

また、モバイルＩＰプロトコルなどのような任意のプロトコルスタックは、双方向トンネリングユニット（１００３）を利用することが可能である。双方向トンネリングユニット（１００３）は、送受信パケット用の双方向トンネリングを実行する。双方向トンネリングユニット（１００３）では、適切なネットワークインタフェース（１００２）を経由する送信を行うために、上位レイヤプロトコル（１００１）からパケットフローパス（１０５２）への、パケットフローパス（１０５１）におけるすべての送信パケットがカプセル化される。また、受信した入力パケットの脱カプセル化（カプセル化されたパケットを復元する処理）を行い、脱カプセル化されたパケットが、パケットフローパス（１０５１）を通じて上位レイヤプロトコル（１００１）に渡される。

インタフェースマネージャ（１００５）は、２つの主要な機能を有している。第１の機能は、ネットワークインタフェース（１００２）で受信されたパケットをスキャンすることである。システムマネージャ（１００４）は、インタフェースマネージャ（１００５）がチェックを行うための何らかの選定基準を送る。なお、例えば、選定基準には、ネットワークプリフィックス、又は特定のホームエージェントのアドレスなどを含ませることが可能である。

図２には、パケットが取り得るフォーマットが与えられている。条件が妥当な場合には、このパケットが、システムマネージャ（１００４）からインタフェースマネージャ（１００５）に送られる。妥当な条件に係る例としては、ホストユニットが初めて起動した場合や、管理者が構成を変更した場合などが挙げられる。パケットを受信すると、インタフェースマネージャ（１００５）は、“Ａ”フィールドに基づいて、その情報が選定基準のデータベースに加えられるべきであるか、あるいは、削除されるべきであるかに注意し、適切な動作を行う。インタフェースマネージャ（１００５）は、複数のネットワークインタフェース（１００２）のいずれか１つを通るすべてのパケットのチェックを行う。これらのパケットは、パケットフローパス（１０５７）を通じて受信される。このチェックの目的は、これらのパケットがシステムマネージャ（１００４）によって与えられた選定基準に指定されているホームエージェントへのモバイルＩＰパケットであるかどうかを決定することである。例えば、システムマネージャ（１００４）によって与えられた選定基準のプリフィックスやアドレスと、あて先アドレスフィールドとの比較を行う方法が可能である。また、これがモバイルＩＰパケットであるかどうかを決定するために、ＩＰｖ６拡張ヘッダを検査して、モバイルＩＰ拡張ヘッダ、あるいは、モビリティヘッダ（ＭＨ：Mobility Header）として知られているヘッダを探索することも可能である。具体例としては、ペイロードプロトフィールド（Payload Proto field）内のIPPROTO_NONEの値を探索する。また、ＭＨタイプフィールド（非特許文献３参照）内の値“５”の探索を行う。これは、パケットが、選択されたホームエージェントへのバインディングアップデートメッセージであることを示すものである。

また、そのイベントをシステムマネージャ（１００４）に通知するために、パケットが送られる。図３には、このパケットが取り得るフォーマットが与えられている。このパケットは、インタフェースマネージャ（１００５）の選定基準データベース内で発見される選定基準のいずれか１つと一致するあて先アドレスのバインディングアップデートメッセージが受信（intercept）された場合に送信されるものである。なお、受信者（システムマネージャ（１００４））の動作は、後述のシステムマネージャ（１００４）に関する記述で与えられる。

受信（intercept）されたパケットは、通常のルーティングルールに従って転送されるため、適切なネットワークインタフェース（１００２）へのパケットフローパス（１０５７）を通じて送出される。すべての受信パケットは、通常の処理と同様に、パケットフローパス（１０５７）を通じて、引き続き伝送が許容されるか、あるいは、パケットフローパス（１０５５）を通じて、双方向トンネリングユニット（１００３）に渡される。

また、インタフェースマネージャ（１００５）は、ネットワークインタフェースにおいて生じたあらゆる問題や、これから起こり得る潜在的な問題を、システムマネージャ（１００４）に通知するという別の機能を有している。インタフェースマネージャ（１００５）は、様々なネットワークインタフェース（１００２）における負荷を決定するために、ある種のメトリックを監視するように構成されることが望ましい。これは、例えば、利用状態、利用される帯域幅、インタフェースの障害などである。何らかの可能なアルゴリズムに基づくある閾値に達した場合（例えば、ネットワークカードの８０％の利用率）には、パケットフローパス（１０５６）を通じてシステムマネージャ（１００４）にパケットが送られて、その問題の通知が行われる。図４には、このパケットが取り得るフォーマットが与えられている。なお、受信者（システムマネージャ（１００４））の動作は、後述のシステムマネージャ（１００４）に関する記述で説明する。

ルートマネージャ（１００６）は情報を格納するとともに、パケットフローパス（１０５９）を通じてシステムマネージャ（１００４）からリクエストされた関連情報を抽出するためのツール及び機能を保持する必要がある。この情報は、利用可能な代理ホームエージェントと、パケットフローパス（１０５９）を通じてシステムマネージャ（１００４）から供給される関連情報とを詳細に記載するテーブルの形式で格納される。例えば、この情報には、指示されたモバイルノード、代理ホームエージェントのアドレス、代理ホームエージェントのインタフェースのホップカウント距離、代理ホームエージェントのインタフェースの優先度やその他のメトリックが含まれている。

情報抽出の機能やツールは、リクエストを行ったシステムマネージャ（１００４）から選定基準が与えられた場合に、上述のシステムマネージャ（１００４）に対して関連エントリを供給するように構成されている。例えば、システムマネージャ（１００４）は、最も高い優先度やその他のメトリックを有する任意のモバイルノードのための代理ホームエージェントに対してリクエストを行う。

モバイルノードの検出に関連して、インタフェースマネージャ（１００５）からパケットフローパス（１０５６）を通じて図４に記載されているパケットで伝えられる情報を受信した場合には、システムマネージャ（１００４）は、検出されたホームエージェントに対して、検出されたモバイルノードの利用可能性（availability）に関する情報を、パケットフローパス（１０６０）を通じて送信する処理を行う必要がある。図５には、このとき送信されるデータパケットの一例が与えられている。

また、システムマネージャ（１００４）は、ホームエージェントとして機能しているインタフェースに関する情報を用いて、ルートマネージャ（１００６）をアップデートする必要がある。図６には、アップデートメッセージのフォーマットの一例が与えられている。このアップデートは、起動又は構成変更時に行われる。システムマネージャ（１００４）が、他のホームエージェントから、特定のモバイルノードの利用可能性を通知する何らかのパケットを受信した場合には、モバイルノードのホームアドレスが気付アドレスを用いて解析された後に、その情報が、図６のメッセージフォーマットを使用するルートマネージャ（１００６）に送られる。

パケットフローパス（１０５６）を通じてインタフェースマネージャ（１００５）から伝搬されるパケット（図４に図示）によって伝えられるインタフェースの障害や過負荷（overload）が検出された場合には、システムマネージャ（１００４）は、利用可能な代替経路やインタフェースを探索するために、さらにアップデートを行い、パケットフローパス（１０５９）を通じてルートマネージャ（１００６）に問い合わせを行う必要がある。障害を通知するアップデートパケットとして可能なフォーマットは、図６に図示されるパケットのライフタイムフィールド（１５０３）の値がゼロに設定されたものであり、これによって、エントリの効力がなくなる。

一方、クエリパケットの一例は図７に図示されている。クエリパケットは、どのホームエージェントが各モバイルノードに対する代理を務めるかを問い合わせるために送られる。そして、代理ホームエージェントのアドレスを有するリプライパケットが、ルートマネージャ（１００６）からシステムマネージャ（１００４）へのパケットフローパス（１０５９）を経由して送られることになる。なお、この代理ホームエージェントは、現在のホームエージェントの別のインタフェースであってもよい。また、このリプライパケットのメッセージフォーマットは、図７に図示されているクエリパケットのフォーマットと同様のものが利用可能である。そして、システムマネージャ（１００４）は、パケットフローパス（１０５３）を通じてパケットを送り、影響を受けるモバイルノードに対して、ホームエージェントを変えるように要求する通知を行う。なお、ここで送信されるパケットの一例は、図８に図示されている。

以下、本発明に係る解決方法で使用される様々なメッセージフォーマットの一例について説明する。

システムマネージャ（１００４）がパケット選定基準をインタフェースマネージャ（１００５）に渡すために使用されるメッセージ用のフォーマットが、図２に図示されている。

タイプ（Type）（１１０１）は、パケットを特定するために使用される任意の数を示している。また、Ａ（１１０２）は、後続のエントリが選定基準のリストに付加されるか否か、又は削除されるか否かを示すフラグである。また、プリフィックスレングス（Prefix Length）（１１０３）は、選定基準として使用されるプリフィックス／アドレス（Prefix/Address）（１１０４）フィールドにおけるビット数を決定するために使用される。また、プリフィックス／アドレス（１１０４）は、選定に使用されるプリフィックス又はアドレスである。

また、インタフェースマネージャ（１００５）がモバイルノードの検出をシステムマネージャ（１００４）に通知するために使用されるメッセージ用のフォーマットが、図３に図示されている。

タイプ（Type）（１２０１）は、パケットを特定するために使用される任意の数を示している。また、ホームエージェントアドレス（Home Agent Address）（１２０２）は、検査されたパケットの送信先フィールドから把握される特定のホームエージェントのアドレスを示している。また、モバイルノードの気付アドレス（Mobile Node's Care-of-Address）（１２０３）は、検査されたパケットの送信元フィールドから把握されるモバイルノードの現在の気付アドレスである。

また、インタフェースマネージャ（１００５）がインタフェースの障害をシステムマネージャ（１００４）に通知するために使用されるメッセージ用のフォーマットが、図４に図示されている。

タイプ（Type）（１３０１）は、パケットを特定するために使用される任意の数を示している。また、エラーコード（Error Code）（１３０２）は、インタフェースで起こっているエラーや障害のタイプを示す。なお、様々な輻輳レベルやハードウェアの障害など、様々な状態を示すために異なる数値が割り当てられる。また、インタフェースアドレス（Interface Address）（１３０３）は、当該問題に直面しているインタフェースのアドレスである。

また、ホストのホームエージェントの利用可能性を、他のホームエージェントに通知するために使用されるメッセージのフォーマットが、図５に示されている。

タイプ（Type）（１４０１）は、パケットを特定するために使用される任意の数を示している。また、レングス（Length）（１４０２）は、パケットの長さである。また、ホップリミットカウント（Hop Limit Count）（１４０３）はＩＰｖ６ヘッダのホップカウントフィールドの初期値である。これは、特定のホームエージェントから現在のホストのホームエージェントがどれくらい離れているかを判断するためのメトリックの一例として使用される。基本的には、移動しているモバイルノードに最も近いホームエージェントが、特定のホームエージェントから最も遠いとみなされる。なお、ここでは、所定の初期値から、受信したＩＰｖ６ヘッダ内のホップカウントフィールドの値を減算することによって、ホップカウント距離を取得してもよい。また、ライフタイム（Lifetime）（１４０４）は、この情報が有効な時間である。また、検出されたモバイルノードの気付アドレス（Detected Mobile Node's Care-of-Address）（１４０５）は、ホストのホームエージェントが検出したモバイルノードの気付アドレスである。ホームエージェントとして機能することができるインタフェースのアドレスは、ＩＰｖ６ヘッダの送信元フィールドに与えられている。

また、システムマネージャ（１００４）が、利用可能なインタフェースを有するルートマネージャ（１００６）又は代理ホームエージェントをアップデートするために使用されるメッセージのフォーマットが、図６に図示されている。

タイプ（Type）（１５０１）は、パケットを特定するために使用される任意の数字を示している。また、メトリック（Metric）（１５０２）は、このエントリを使用する望ましさを計算する際に使用される数値である。メトリックの値は、ホームエージェントがどのくらい近くに存在するかに関する関数であり、概して、代理ホームエージェントを選択する際に使用される。また、ライフタイム（Lifetime）（１５０３）は、期間満了又は削除の後のこのエントリの有効なライフタイムである。ローカルインタフェースは、最大の可能な値（ビットをすべて１に設定）を持つことによって示される場合もある。また、入力パケットのこのフィールドが０に設定されている場合には、ルートマネージャ（１００６）内のすべての対応エントリは、満了となり削除される。また、ホームエージェントアドレス（Home Agent Address）（１５０４）は、ローカルインタフェース又は代理ホームエージェントのアドレスである。また、モバイルノードアドレス（Mobile Node Address）（１５０５）は、代理ホームエージェントとして機能するモバイルノードのアドレスである。通常、ローカルインタフェースの場合には、このフィールドは空（empty）に設定される。

また、システムマネージャ（１００４）からルートマネージャ（１００６）への問い合わせ（クエリ）として使用されるメッセージのフォーマットが、図７に図示されている。なお、同一のフォーマットが、ルートマネージャ（１００６）からシステムマネージャ（１００４）へのリプライメッセージで使用される。

タイプ（Type）（１６０１）は、パケットを特定するために使用される任意の数を示している。リクエスト及びリプライパケットは、異なる値を有することになる。また、マジック（Magic）（１６０２）は、リクエスト及びリプライのペアを対応させるために使用されるランダムに選択された数である。送信されるリクエストには、ランダムに生成された値を有しており、リプライパケットには、リクエストと同一の値が保持される。また、ホームエージェント／モバイルノードアドレス（Home Agent/Mobile Node Address）（１６０３）フィールドには、リクエストメッセージではチェック用のモバイルノードのアドレスが、リプライメッセージでは選択されたホームエージェントのアドレスが与えられる。

また、モバイルノードは、図８に図示されている新しいモビリティオプションを理解する必要がある。

タイプ（Type）（１７０１）は、オプションを特定するために使用される任意の数を示している。また、レングス（Length）（１７０２）は、タイプ及びレングスフィールドを除くオプションの長さであり、オクテットで示される。また、代理ホームエージェントアドレス（Alternate Home Agent Address）（１７０３）は、代理ホームエージェントの１２８ビットのアドレスである。これは、同一のホームエージェント、又は、別の異なるホームエージェント上の代理インタフェースであってもよい。

この新しいオプションを受信したモバイルノードは、送信元アドレスがバインディングアップデートのリスト内の対応するエントリに含まれていることを、まずチェックしなければならず、対応するエントリがない場合には、オプションは無視されるべきである。また、このオプションを検証して、モバイルノードが、そのバインディングキャッシュエントリを維持することを選択した場合には、このオプションを含むパケットの送信元アドレスに対して、ライフタイムがゼロに設定されたバインディングアップデート（Binding Update：ＢＵ）を送信しなければならない。このとき、新しいバインディングアップデートは、代理ホームエージェントアドレスのフィールドで与えられたアドレスに送られるべきである。

このモビリティオプションの送信を可能とする方法の具体的な例としては、ホームエージェントからモバイルノードへのバインディングリフレッシュリクエストを使用することが可能である。仮定として、このオプションは、新たに定義されるＩＰｖ６拡張ヘッダとして伝送されることが想定される。このオプションの最も重要な機能は、メッセージの送信元が、登録されているホームエージェントであり、使用可能な新たなホームエージェントであることを、モバイルノードが見極められるようにすることにある。

第１の実施の形態では、ホームエージェントがマルチホームであり、代理ホームエージェントが存在する場合について説明する。図９は、ネットワークの概要図である。ホームエージェント（１８０２）は、アクセスルータ（１８０５）に向かうイグレスインタフェース（１８１０）と、アクセスルータ（１８０６）に向かうイグレスインタフェース（１８１１）とを介して、グローバルネットワーク（１８０７）に接続されており、登録されたノード（１８０１）に対するホームエージェントとして機能している。

また、代理ホームエージェントが存在している。ホームエージェント（１８０３）は、グローバルネットワーク（１８０７）とグローバルネットワーク（１８０８）との間に存在している。また、同様に、ホームエージェント（１８０４）が、グローバルネットワーク（１８０８）とグローバルネットワーク（１８０９）との間に存在している。

登録されたノード（１８０１）は、モバイルＩＰプロトコルスタックを利用する任意のモバイルターミナルを示している。また、この登録されたノード（１８０１）は、他のモバイルノードが存在可能なモバイルネットワークを提供するモバイルルータも表すものとする。登録されたノード（１８０１）は、本来はグローバルネットワーク（１８０７）内を移動するものであり、ホームエージェント（１８０２）のイグレスインタフェース（１８１０）が、ホームエージェントインタフェースとして機能している。しかしながら、仮にイグレスインタフェース（１８１０）が輻輳などによって落ちた（down）場合には、インタフェースマネージャ（１００５）からシステムマネージャ（１００４）への通知が行われる。システムマネージャ（１００４）は、代替経路を取得するために、ルートマネージャ（１００６）に対して問い合わせを行う。ルートマネージャ（１００６）は、他方のイグレスインタフェース（１８１１）のアドレスによって返答を行い、システムマネージャ（１００４）は、登録されたノード（１８０１）に対して、ホームエージェントをイグレスインタフェース（１８１１）に切り換えるように通知するメッセージの送信処理を行う。

登録されたノード（１８０１）がグローバルネットワーク（１８０９）に移動すると仮定する。登録されたノード（１８０１）は、その本来のホームエージェント（イグレスインタフェース（１８１０））に対して、バインディングアップデート（ＢＵ）メッセージを送信する処理を行う。ＢＵがホームエージェント（１８０２）に向かう途中、そのパケットは代理ホームエージェント（ホームエージェント（１８０３）とホームエージェント（１８０４））を通り抜ける。そして、ホームエージェント（１８０３）及びホームエージェント（１８０４）の両方がパケットを検出し、それぞれ選択されたインタフェースのアドレスによって、ホームエージェント（１８０２）をアップデートする処理を行う。イグレスインタフェース（１８１１）が輻輳状態にある場合には、インタフェースマネージャ（１００５）は、システムマネージャ（１００４）に対して再度通知を行う。登録されたノード（１８０１）に関する問い合わせをシステムマネージャ（１００４）から受けた際に、ルートマネージャ（１００６）は、２つの代理ホームエージェント（ホームエージェント（１８０３）とホームエージェント（１８０４））が利用可能であることを把握し、メトリックに基づく選択を行って、ホップ距離がより遠い好適なホームエージェント（したがって、登録されたノード（１８０１）により近いと思われるホームエージェント）としてホームエージェント（１８０４）を選定することになる。

そして、システムマネージャ（１００４）は、登録されたノードに対して、図８に図示されているモビリティオプションを有するメッセージの送信を行う。モビリティオプションを受信すると、登録されたノード（１８０１）は、まず、メッセージの検証を行うべきであり、例えば、ＩＰｖ６パケットの送信元フィールドに、その登録されたホームエージェント（１８０２）のアドレスが含まれていることを確認する。そして、このアドレスが含まれていれば、メッセージに含まれるインタフェースアドレスを有するホームエージェント（１８０４）に、ホームエージェントの切り換えを行うべきである。

この状況では、図１０に図示されるアルゴリズムが使用されることになる。インタフェースマネージャ（１００５）は、インタフェースの障害を検出した後に、システムマネージャ（１００４）に対して、アップデートを行って、モバイルノード用の代替経路をルートマネージャ（１００６）に対してリクエストするように通知を行う（ステップ１９０１）。ルートマネージャ（１００６）は、まず、利用可能なローカルインタフェース（代替インタフェースとなり得るローカルインタフェース）が存在するか否かのチェックを行う（ステップ１９０２）。ここで、ローカルの代替経路が存在しない場合（パス１９５４）には、代理ホームエージェントに関するチェックが行われる（ステップ１９０６）。

一方、代替インタフェースが見つかった場合（パス１９５１）には、代替インタフェースのアドレスを有するメッセージ（図８）が送信される。なお、この場合、本来のイグレスインタフェースが落ちている（down）のであれば、双方向トンネリングユニット（１００３）によって新たなトンネルのセットアップが必要となる場合もある。そして、ホームエージェントは、代替インタフェースに関するモバイルルータからのＢＵを待機する（ステップ１９０３）。なお、このメッセージ（図８）は、タイムアウトの後も任意の回数、再送されてもよい。

ステップ１９０３でＢＵを受信しない場合（タイムアウトの場合、又はリトライが最大となった場合）には、ホームエージェントは、新しい代替インタフェースを求める一連の処理を繰り返し行ってもよい（パス１９５２）。このとき、現在のイグレスインタフェースをリストから削除する（ステップ１９０４）ことによって、前に試されたインタフェースは、このモバイルルータの検討対象から除外される。

また、ステップ１９０３でＢＵが代替インタフェース上で受信された場合（パス１９５３）には、古いバインディングキャッシュエントリは直ちに効力がなくなり、新しいインタフェースアドレスと関連付けられたモバイルノード用の新たなエントリが加えられることによって、代替インタフェースの使用に移行する（ステップ１９０５）。

ステップ１９０６において、ルートマネージャ（１００６）がチェックを行って、代理ホームエージェントを発見しなかった場合（パス１９５５）には、動作は変更なく継続されることとなる（ステップ１９０７）。なお、本来のインタフェースが落ちている（down）場合には、ホームエージェントは切断状態となる。

しかしながら、ステップ１９０６において、ルートマネージャ（１００６）が代理ホームエージェントの利用可能性に関する情報を有している場合（利用可能な代理ホームエージェントを発見した場合）には（パス１９５６）、代理ホームエージェントのアドレスを示すメッセージ（図８）が送信される（ステップ１９０８）。本来のイグレスインタフェースが落ちている（down）と、ルートマネージャ（１００６）は、代替ルートを求めて、再度問い合わせを行うことになる。ここでは、例えば、何らかの他の方法を用いて検出された代理ホームエージェントを経由する内部ネットワーク側（イングレス：ingress）ルートを利用することも可能である。そして、新しいトンネルが、双方向トンネリングユニット（１００３）によってセットアップされる。ホームエージェント（１０００）は、バインディングキャッシュエントリを失効させることが可能なＢＵ以外のパケットをモバイルルータから受信するか否かを確認する待機状態となる（ステップ１９０９）。

ステップ１９０９において、依然としてパケットを受信している場合（パス１９５７）には、ホームエージェントは、利用可能な新しい代理ホームエージェントを求める一連の処理を繰り返し行う。このとき、現在の代理ホームエージェントをリストから削除する（ステップ１９１１）ことによって、前に試されたホームエージェントは、このモバイルルータの検索対象から除外される。

また、もはやモバイルルータからパケットを受信しない場合（パス１９５８）には、ライフタイムの値がゼロに達して、バインディングキャッシュエントリが放置され、その効力が自然に満了となる（ステップ１９１０）。

＜第２の実施の形態＞
第２の実施の形態では、セントラルルートマネージャ（２００１）が存在するホームネットワークに関する場合について説明する。セントラルルートマネージャ（２００１）のみが必要とされる場合には、ホームエージェント（２０００）に必要な機能コンポーネントは、図１１に図示されるように、より簡単な構成となる。そのレイアウトは、ルートマネージャ（１００６）のブロック、及び、関連するパケットフローパス（１０５９）が存在しないことを除いて、図１に示す構成と類似している。また、その代わり、各ホストのホームエージェント内のシステムマネージャ（１００４）が、パケットフローパス（１０６２）を経由して、セントラルルートマネージャ（２００１）内のルートマネージャに、すべてのアップデートを送信することになる。なお、セントラルルートマネージャ（２００１）は、図１に示す機能コンポーネントを有しており、セントラルルートマネージャ（２００１）の位置情報は、クライアントのホームエージェントのそれぞれにおいて、静的に構成された状態とすることが可能である。

図１２には、ネットワーク（２００５）を通じて、アップデート及びリクエストをセントラルルートマネージャ（２００１）に送信するクライアントのホームエージェント（ホームエージェント（２００２）、ホームエージェント（２００３）、ホームエージェント（２００４））において可能な配置構成が図示されている。セントラルルートマネージャ（２００１）は、すべてのアップデート情報を収集して、それぞれに対するリプライメッセージを送信する。

第１の実施の形態における説明からの変更箇所は、ホームエージェントのインタフェースとして機能するローカルインタフェースのアップデートが含まれている点である。セントラルルートマネージャ（２００１）の場合には、セントラルルートマネージャ（２００１）上のローカルインタフェースが、ホームエージェントの機能を有している場合も、また、有していない場合も考えられる。クライアントのホームエージェント用のローカルインタフェースが、何らかのモバイルノードのホームエージェントのインタフェースとして機能しているときのみ、ローカルインタフェースはルートマネージャで更新されるべきである。また、図５に図示されているメッセージのフォーマットの所定の検出モバイルノード気付アドレス（１４０５）フィールドによって、モバイルノードの気付アドレスではなくホームアドレスが提供されることを示すために、クライアントのホームエージェントがセントラルルートマネージャ（２００１）をアップデートする場合には、図５に図示されているメッセージのフォーマットのタイプ（１４０１）フィールドに、異なる値を入れることも可能である。

このとき、図６及び図７に図示されるメッセージは、ＩＰｖ６を使用して伝搬されることになる。実施可能な例としては、ＩＰｖ６パケットのペイロードとして運ばれる。なお、第１の実施の形態で説明されているその他のメッセージは、変更される必要はない。

セントラルルートマネージャ（２００１）を有する主要な利点としては、他のホームエージェントにおける格納スペースの節約や処理能力の補完が挙げられる。したがって、他のホームエージェントは、データ格納の点において比較的安いコストで製造できるようになり、また、様々なエントリの検索や処理に必要な処理の負荷が、セントラルルートマネージャ（２００１）にオフロードされるようになる。このような集中化のアプローチによれば、あらゆる関連情報を１箇所に集めるという利益が付加的にもたらされ、より効果的、かつ効率的なルート選定用のアルゴリズムの利用が可能となる。

本発明は、モバイルノードのホームエージェントの変更を可能とするものであり、移動端末に係る通信技術（特に、無線通信技術）に係る分野に適用可能である。

複数のインタフェースを有するホームエージェント内に存在する機能ブロックのフレームワークを示す図 システムマネージャが、インタフェースマネージャに対して、パケット選定基準を渡すために使用されるメッセージのフォーマットを示す図 インタフェースマネージャが、システムマネージャに対して、モバイルノードの検出を通知するために使用されるメッセージのフォーマットを示す図 インタフェースマネージャが、システムマネージャに対して、インタフェースの障害を通知するために使用されるメッセージのフォーマットを示す図 他のホームエージェントに対して、ホストのホームエージェントの利用可能性を通知するために使用されるメッセージのフォーマットを示す図 システムマネージャが、ルートマネージャに対して、利用可能なインタフェースを有するルートマネージャや、代理ホームエージェントのアップデートを行うために使用されるメッセージのフォーマットを示す図 システムマネージャからルートマネージャに対するクエリとして使用されるメッセージのフォーマットを示す図 新しいモビリティオプションのフォーマットを示す図 複数のインタフェースを有する複数のホームエージェントが存在するホームネットワーク（マルチホームサイト又はマルチホームホスト）を特徴とするネットワーク図 図９に図示される場合において行われる動作のフロー図 セントラルルートマネージャを利用するクライアントのホームエージェント内に存在する機能ブロックのフレームワークを示す図 セントラルルートマネージャを有するクライアントのホームエージェントを特徴とするネットワーク図

Claims (7)

1. 通信ネットワークに接続する移動端末の位置情報の管理を行うホームエージェントとして機能し得る移動端末管理装置であって、
   前記通信ネットワークに接続可能な１つ又は複数のネットワークインタフェースと、
   前記１つ又は複数のネットワークインタフェースを監視して、ホームエージェントとして機能するために管理下に置くことができる移動端末の存在を検出するインタフェースマネージャと、
   管理下に置くことができる前記移動端末が前記インタフェースマネージャによって検出された場合に、前記移動端末の現在のホームエージェントに対して、前記移動端末を管理下に置くことができる旨を通知する通知メッセージを生成及び送信するシステムマネージャとを、
   有し、
   前記インタフェースマネージャが、
   すべての前記ネットワークインタフェースを通るＩＰｖ６パケットの検査を行うパケット検査手段と、
   所定の選定基準を参照して、前記所定の選定基準によって定められたアドレスを送信先アドレスとする前記移動端末からのバインディングアップデートメッセージを検出するバインディングアップデートメッセージ検出手段と、
   前記バインディングアップデートメッセージ検出手段による前記バインディングアップデートメッセージの検出に基づいて、前記移動端末の現在のホームエージェントのアドレスを取得するアドレス取得手段とを、
   有する移動端末管理装置。
2. 前記システムマネージャによって生成される通知メッセージが、前記ホームエージェントから前記移動端末の現在のホームエージェントまでのホップ数が記載されるフォーマットを有している請求項１に記載の移動端末管理装置。
3. 通信ネットワークに接続する移動端末の位置情報の管理を行うホームエージェントとして機能し得る移動端末管理装置であって、
   少なくとも１つに前記移動端末の前記ホームエージェントを特定するアドレスが設定されており、前記通信ネットワークに接続可能な１つ又は複数のネットワークインタフェースと、
   前記ホームエージェントとしての前記アドレスが設定されている前記ネットワークインタフェースによって、前記移動端末からバインディングアップデートメッセージを受信した場合に、前記移動端末のホームエージェントとして機能し得る通信装置においてすべてのネットワークインタフェースを通るＩＰｖ６パケットの検査を行って所定の選定基準によって定められたアドレスを送信先アドレスとする前記移動端末からの前記バインディングアップデートメッセージを検出し、前記移動端末の現在のホームエージェントのアドレスを取得して送信する、前記通信装置が前記移動端末を管理下に置くことができる旨を通知する通知メッセージを監視する通知メッセージ監視手段と、
   前記通信装置から前記通知メッセージを受信した場合、前記通信装置を前記移動端末のホームエージェントとして設定するための処理を開始するシステムマネージャとを、
   有する移動端末管理装置。
4. 複数の前記通信装置のそれぞれから前記通知メッセージを受信した場合、前記通知メッセージ内のホップ数を参照して、前記移動端末に最も近い通信装置を検出するルートマネージャを有し、
   前記システムマネージャが、前記ルートマネージャによって検出された前記移動端末に最も近い前記通信装置を、前記移動端末のホームエージェントとして設定するための処理を開始するように構成されている請求項３に記載の移動端末管理装置。
5. 前記移動端末に対して、前記ルートマネージャによって検出された前記移動端末に最も近い前記通信装置のアドレスを通知するように構成されている請求項４に記載の移動端末管理装置。
6. 通信ネットワークに接続する移動端末の位置情報の管理を行うホームエージェントとして機能し得る複数の移動端末管理装置を有する通信システムにおいて、前記通信ネットワークに接続し、その位置情報をホームエージェントに管理してもらうことにより移動しながら通信を行うことが可能な移動端末であって、
   前記移動端末のホームエージェントとして機能し得る第１の移動端末管理装置が、
   前記通信ネットワークに接続可能なすべてのネットワークインタフェースを通るＩＰｖ６パケットの検査を行い、所定の選定基準を参照して、前記所定の選定基準によって定められたアドレスを送信先アドレスとする前記移動端末からのバインディングアップデートメッセージを検出し、前記バインディングアップデートメッセージの検出に基づいて、前記移動端末の現在のホームエージェントのアドレスを取得することで、ホームエージェントとして機能するために管理下に置くことができる前記移動端末の存在を検出し、前記移動端末の現在のホームエージェントに対して、前記移動端末を管理下に置くことができる旨を通知する通知メッセージを生成及び送信するよう構成されており、
   前記移動端末の現在のホームエージェントとして機能している第２の移動端末管理装置が、
   前記ホームエージェントとしての前記アドレスが設定されているネットワークインタフェースによって前記移動端末から前記バインディングアップデートメッセージを受信した場合に前記通知メッセージを監視し、前記第１の移動端末管理装置から前記通知メッセージを受信した場合、前記第１の移動端末管理装置を前記移動端末のホームエージェントとして設定するための処理を開始するよう構成されている前記通信システムにおいて、
   前記移動端末の現在のホームエージェントとして機能している前記第２の移動端末管理装置に対して前記バインディングアップデートメッセージを送信する手段と、
   前記第１の移動端末管理装置を前記移動端末のホームエージェントとして設定するための処理を行う前記第２の移動端末管理装置から、前記第１の移動端末管理装置にホームエージェントを切り換えるように指示するとともに、前記切り換え後のホームエージェントのアドレスを含む通知メッセージを受信した場合に、前記ホームエージェントの切り換えを行う手段とを、
   有する移動端末。
7. 通信ネットワークに接続する移動端末の位置情報の管理を行うホームエージェントとして機能し得る複数の移動端末管理装置を有する通信システムであって、
   前記移動端末のホームエージェントとして機能し得る第１の移動端末管理装置が、
   前記通信ネットワークに接続可能なすべてのネットワークインタフェースを通るＩＰｖ６パケットの検査を行い、所定の選定基準を参照して、前記所定の選定基準によって定められたアドレスを送信先アドレスとする前記移動端末からのバインディングアップデートメッセージを検出し、前記バインディングアップデートメッセージの検出に基づいて、前記移動端末の現在のホームエージェントのアドレスを取得することで、ホームエージェントとして機能するために管理下に置くことができる前記移動端末の存在を検出し、前記移動端末の現在のホームエージェントに対して、前記移動端末を管理下に置くことができる旨を通知する通知メッセージを生成及び送信するよう構成されており、
   前記移動端末の現在のホームエージェントとして機能している第２の移動端末管理装置が、
   前記ホームエージェントとしての前記アドレスが設定されているネットワークインタフェースによって前記移動端末から前記バインディングアップデートメッセージを受信した場合に前記通知メッセージを監視し、前記第１の移動端末管理装置から前記通知メッセージを受信した場合、前記第１の移動端末管理装置を前記移動端末のホームエージェントとして設定するための処理を開始するよう構成されている通信システム。

Images