JP5072864B2 - 通信システム及びドメイン管理装置 - Google Patents

Description

本発明は、ＩＰ（Internet Protocol：インターネットプロトコル）ネットワークなどのパケット交換型データ通信ネットワークにおける通信システム、ドメイン管理装置、エッジ装置並びに移動端末に関する。

ＩＰモビリティを利用した場合には、モバイル装置はホームアドレス（ＨｏＡ：Home Address）を使用してインターネットにおける到達可能性を維持しながら、あるネットワークから別のネットワークに移動することが可能である。このＩＰモビリティを実現するプロトコルとして、現在、ＩＥＴＦ（Internet Engineering task Force）において、モバイルＩＰと呼ばれる標準化プロトコルが構築されている。なお、モバイルＩＰは、インターネットにおけるノードのモビリティに関して、処理能力に優れ、かつ拡張性のある通信プロトコルである。

モバイルＩＰを使用することで、ノードは、ＩＰアドレス（ホームアドレス）を変更することなく、インターネットへの接続ポイントを変更することが可能であり、ノードは、移動しながらトランスポート層又はより高次のレイヤの接続を維持することが可能となる。なお、ノードのモビリティを実現する際には、インターネットのルーティング構造全体にわたって、そのホスト特有のルートを構築する必要はない。モバイルＩＰを使用する場合の典型的なシナリオとしては、例えば無線ＷＡＮ（Wide Area network：広域ネットワーク）環境が挙げられる。無線ＷＡＮ環境では、モバイル装置は、異なるＩＰアドレスを有する複数のＬＡＮ（Local Area Network：ローカルエリアネットワーク）を通過することがある。また、モバイルＩＰは、第３世代（３Ｇ）ネットワークにおいて、インターネットへの通信を行っているユーザの通信装置がセルラ基地局間を移動する場合に透過性を提供するために用いられてもよい。なお、現在のところ、モバイルＩＰは、ＩＰバージョン４（ＩＰｖ４）又はＩＰバージョン６（ＩＰｖ６）で使用され得る。

また、最近では、ローカルＩＰモビリティのサポートが提供されるようになってきている。ローカルＩＰモビリティは、ネットワークトポロジ（ネットワークの接続形態）が限定されたエリアにおけるＩＰモビリティである。なお、モバイルノードが移動するネットワークトポロジのエリアが限定されている場合であっても、実際の地理的な地域はかなり広大である可能性がある。これは、ネットワークトポロジと無線通信エリアとのマッピングに依存する。ローカルモビリティに関して実行可能なシナリオとしては、例えば、大規模なキャンパス（例えば、大学のキャンパス）における無線ＬＡＮ環境の配置が挙げられる。キャンパスのエリア内に存在するユーザは、大学構内を移動しながら、例えばｅメール、検索、ウェブサーフィンなどのサービスを受けることができる。しかしながら、キャンパスエリア内のすべてのＷＬＡＮアクセスポイントを単一のブロードキャストドメインに収容することは、あまり良い拡張とは言えない。

また、何らかの理由（例えば、リンクがＩＥＥＥ８０２．３ではない）で、キャンパスの一部を１つのＶＬＡＮ（Virtual Local Area Network）でカバーできない場合もある。この場合、キャンパスを、それぞれが１つ以上のアクセスルータによって提供されている最終ホップ（last-hop）のリンクに分割することが望ましい。したがって、大学キャンパスのそれぞれのエリア（アクセスルータによって提供されている各エリア）内で使用可能な不変のＩＰアドレスを有するためには、何らかの局所モビリティ管理技術が用いられる必要がある。ＩＥＴＦでは、ネットワークベースの局所モビリティ管理のワーキンググループ（ＮｅｔＬＭＭ（Network-based Localized Mobility Management）ワーキンググループ）が、局所化されたモビリティ管理のプロトコルを設計している。下記の非特許文献１では、アクセスネットワーク（あるいは、ＮｅｔＬＭＭドメインと呼ばれる）内に限定してＩＰモビリティ管理を行う局所モビリティ管理プロトコルが導入されている。このプロトコルは、移動に伴うアクセスネットワークの変更を収容することによって、移動を局所化する。

モバイルノードがＮｅｔＬＭＭインフラストラクチャに接続する際、モバイルノードは、まず、ステートフルアドレス構成処理又はステートレスアドレス構成処理を使用して、サービスを提供しているＬＭＡ（Local Mobility Anchor：ローカルモビリティアンカ）に関するアドレスを構成する必要がある。したがって、モバイルノードがＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）に接続すると、ＭＡＧは、自身の識別情報（ＩＤ）とモバイルノードのＩＤとを含む位置登録メッセージをＬＭＡに送信する。ＬＭＡは、このメッセージに対して、ＭＡＧからモバイルノードへのルータ通知に使用可能なＮｅｔＬＭＭプレフィクスを含む位置登録確認メッセージで応答を行う。そして、ＭＡＧは、接続されているモバイルノードに対してルータ通知（ＮｅｔＬＭＭプレフィックスを含む）を送信する。アドレス構成が完了すると、ＭＡＧは、ＭＡＧのＩＤ、ＭＮのＩＤ、ＮｅｔＬＭＭのアドレス、トンネルのＩＤを含むＭＮアドレスセットアップメッセージをＬＭＡに送信することによって、モバイルノードのアドレスをＬＭＡに登録する。ＬＭＡは、このメッセージに対して、パケットの転送ステートを作成して、パケットセットアップを承認するＭＮアドレスリプライメッセージをＭＡＧに送信する。ＭＡＧは、承認を示すＭＮアドレスセットアップリプライメッセージを受信すると、モバイルノードあてのパケットに関する転送ステートを作成する。

さらに、最近の動向では、ラップトップやその他のハンドヘルド電子周辺機器が、複数のネットワークインタフェースを搭載することが可能である。一方、下記の非特許文献２に記載されているモバイルＩＰｖ６（ＭＩＰｖ６）に関して、モバイルノードは、ホームネットワークから離れていても到達可能性を実現することができるように、ホームエージェントにおいて、自身の気付アドレス（ＣｏＡ）をホームアドレス（ＨｏＡ）と関連付けることが可能である。したがって、いくつかのネットワークインタフェースが搭載されているハンドヘルド電子周辺機器が導入されることで、モバイルノードが、複数の気付アドレスを所定のホームエージェントアドレスに登録できるようになる。

このような複数の気付アドレスの登録方法は、現在、Mobile Nodes and Multiple Interfaces in IPv6（Ｍｏｎａｍｉ６）のＩＥＴＦワーキンググループで定義されている。下記の非特許文献３では、１つのＨｏＡに対する複数のバインディングを区別するため、バインディングユニーク識別番号（ＢＩＤ：Binding Unique Identification）と呼ばれる識別番号が導入されている。ＢＩＤは、モバイルノードの１つのホームアドレス（ＨｏＡ）に関連付けられたインタフェース又はＣｏＡに対して割り当てられる。したがって、ＨｏＡはモバイルノードに関連付けられており、一方、ＢＩＤは、モバイルノードによって登録された各バインディングを特定する。モバイルノードは、バインディングアップデート（ＢＵ：Binding Update）によって、そのホームエージェントにＢＩＤを通知し、ホームエージェントは、自身のバインディングキャッシュにＢＩＤを記録する。

ここで、複数のインタフェースを有するモバイルノードが、ＮｅｔＬＭＭドメイン内の単一のＬＭＡに同時接続（simultaneous association）を行おうとしているとする。なお、同時接続とは、複数のインタフェースを有するノード（マルチモードノード）が、複数のインタフェースのそれぞれにおける接続を同時に行うことを意味する。複数のインタフェースを有するモバイルノードが、ＭＮのＩＤを使用して、異なるＭＡＧを通じて同一のＬＭＡに接続する場合には、ＭＡＧからＬＭＡに送信される位置登録メッセージは相互に無効化される（すなわち、上書きされる）。これによって、実際にはＬＭＡは、いかなる場合であってもモバイルノードの１つのインタフェースのみを使用する。

また、下記の特許文献１には、複数のインタフェースを有するモバイルノード（モバイルステーション）が、その複数のインタフェースのいずれにおいても同一のグローバルアドレスを使用できるようにする方法が開示されている。モバイルステーションは、複数のインタフェースのいずれかにおいて、ローカルの通信に使用可能なリンクローカルＩＰアドレスを生成する。そして、モバイルステーションは、リンクローカルＩＰアドレスを使用して、グローバルアドレス取得部から複数のインタフェースのすべてを通じてグローバル通信に使用可能な１つのグローバルアドレスを取得する。したがって、モバイルステーションは、複数のインタフェースのそれぞれに関してグローバルアドレスを生成する必要はない。

また、下記の特許文献２には、無線通信ネットワークにおいて、複数のリンクレイヤアドレスをＩＰアドレスに関連付ける方法が開示されている。この方法を実行することによって、クライアントデバイスは、ＩＰアドレスに関連付けられているデータリンクを集約して、データのダウンロード量を増加させることができる。また、この方法によれば、無線通信デバイスの複数のリンクレイヤアドレスに関連付けられているＩＰアドレスから、クライアントデバイスへのバイキャストが可能になる。さらに、この方法によれば、第１のリンクレイヤアドレスへの通信リンクが悪化した場合に、第２のリンクレイヤアドレスへのダウンロードが行われるようにすることによって障害復旧（failure recovery）が可能となる。

また、最近、ＮｅｔＬＭＭワーキンググループでは、別のタイプのローカルモビリティ管理プロトコルの採用に関する議論が行われている。このプロトコルは、プロキシモバイルＩＰ（ＰＭＩＰ：Proxy MIP）と呼ばれるものであり、例えば下記の非特許文献４に記載されている。

ＰＭＩＰでは、ＭＡＧとＬＭＡとの間のシグナリングメッセージは、モバイルＩＰｖ６シグナリングを拡張したものが利用される。モバイルノードは、ＮｅｔＬＭＭドメイン内に移動すると、アクセス認証処理においてモバイルノードの識別子（ＭＮのＩＤ）を提示することによって、ＭＡＧに接続する。ＭＮのＩＤは、通常、ローカルサーバから取得可能なモバイルノードのポリシプロファイル（policy profile）を関連付けるために使用される。

ポリシプロファイルには、提供されるネットワークベースのモビリティサービスの特徴、関連するパラメータ（例えば、モバイルノードに割り当てられるプレフィックス、許可されるアドレス構成モード、ローミングポリシ）や、その他のネットワークベースのモビリティサービスを提供するために必要なパラメータなどが含まれている。

アクセス認証に成功すると、ＭＡＧは、ローカルサーバからモバイルノードのポリシプロファイルを取得する。これによって、ＭＡＧは、モバイルノードに関するモビリティシグナリングを実行するために必要な情報をすべて有することになる。そして、ＭＡＧは、モバイルノードに割り当てられるプレフィックスを通知するルータ通知（ＲＡ：router advertisement）メッセージを周期的にモバイルノードに送信する。

モバイルノードは、受信したＲＡメッセージからプレフィックスを見つけると、ＮｅｔＬＭＭドメインに接続されているインタフェースで通信を行うために、ＩＰアドレス（例えば、ホームドメインではホームアドレス、外部ドメインでは気付アドレス）を構成する。モバイルノードがＮｅｔＬＭＭドメイン内を移動している限り、ＮｅｔＬＭＭドメインに接続されるインタフェースは常に同一のプレフィックスを見つけることが可能となる。これは、モバイルノードによって接続される各ＭＡＧが、常にローカルサーバからモバイルノードのプロファイルを取得することによって実現される。したがって、ＮｅｔＬＭＭドメイン内の位置によらず、モバイルノードは、通信を行うために最初に構成されたＩＰアドレスを常に使用することが可能となる。また、アドレスを構成する別の方法として、ＤＨＣＰなどのステートフルなアドレス構成方法を用いて、モバイルノードにアドレス若しくはプレフィックスを割り当てることもできる。

上述のように、ＬＭＡは、ＮｅｔＬＭＭドメイン内の各モバイルノードに関して、論理的（トポロジカル）なアンカポイントとして機能する。各モバイルノードのアンカポイントとして機能するため、ＬＭＡは各モバイルノードの現在位置をアップデートする必要がある。このため、モバイルノードがＭＡＧに接続する場合には常に、ＭＡＧがプロキシバインディングアップデート（ＰＢＵ：Proxy binding update）メッセージをＬＭＡに送信する。このＰＢＵメッセージは、モバイルノードの固有識別子をＭＡＧの気付アドレス（固有の識別子）にバインドする。このバインディングによって、ＬＭＡは、パケットを適切なＭＡＧを経由してモバイルノードに発送することが可能となる。

なお、複数のインタフェースを有するモバイルノードは、ＮｅｔＬＭＭドメイン内に位置しているからといって、必ずしもすべてのインタフェースがＮｅｔＬＭＭドメインに接続される必要はない。例えば、モバイルノードは、セルラインタフェースとＷＬＡＮインタフェースを有しており、モバイルノードのユーザは、セルラサービスのサービスプロバイダと契約（使用契約）を交わしているとする。一方、サービスプロバイダは、ＮｅｔＬＭＭドメインにおいてＷＬＡＮアクセスポイントを有しており、ＷＬＡＮサービスの提供も行っているとする。このとき、使用契約の内容によっては、モバイルノードのＷＬＡＮインタフェースは、たとえＮｅｔＬＭＭドメイン内で移動している場合であっても、サービスプロバイダのＷＬＡＮアクセスポイントへのアクセスは許可されないかもしれない。

また、例えば、下記の非特許文献３には、複数のインタフェースを有するモバイルノードのアクセス制御方法の典型的な例が開示されている。非特許文献３に開示されている従来の技術では、モバイルノードのインタフェースは、一意の識別子（例えば、メディアアクセス制御（ＭＡＣ：media access control）アドレス）を使用して特定される。また、接続に使用されているインタフェースの一意の識別子などの情報は、ネットワーク内に存在するアクセスコントロールリストに格納される。

モバイルノードのインタフェースが、スイッチを経由してネットワークへの接続を試みる場合、スイッチがアクセスコントロールリストを用いて、モバイルノードが既に別のインタフェースを経由してネットワークに接続されているか否かを判断する。モバイルノードが既に別のインタフェースを経由してネットワーク接続されている場合には、スイッチは、モバイルノードに関連したポリシを使用して、モバイルノードがネットワークへの同時接続を行うことが可能か否かを確認する。ポリシに基づいて、モバイルノードがネットワークへの同時接続を行うことが不可能であると判断した場合には、スイッチは、モバイルノードの第２のインタフェースに対してアクセスを拒否する。
米国特許公開２００５／０２７１０３２号 米国特許公開２００４／０１００９２２号 米国特許７２３６４７０号 G. Giaretta, K. Leung, M. Liebsch, P. Roberts, K. Nishida, H. Yokota, M. Parthasarathy and H. Levkowetz, "The NetLMM Protocol", NetLMM Working Group Internet-Draft, Internet-Draft, draft-giaretta-netlmm-dt-protocol-02.txt, October 5, 2006. D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Monami6 Working Group Internet-Draft, draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-00.txt, April 08, 2007.

しかしながら、特許文献１に開示されている技術によれば、モバイルステーションの他のインタフェース（リンクローカルＩＰアドレスを生成したインタフェースとは異なるインタフェース）はリンクローカルＩＰアドレスを生成する必要がなく、グローバル通信のグローバルアドレスをすぐに使用することができる一方、モバイルステーションは、一度に複数のインタフェースのうちの１つしか使用できないように制限されてしまうという問題がある。また、特許文献２に開示されている技術では、複数のリンクレイヤアドレスをＩＰアドレスに関連付ける方法に関しては、詳細な説明はなされていない。

上記の問題を解決するため、本発明は、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようにするための通信システム及びドメイン管理装置を提供することを目的とする。

上記の目的を達成するため、本発明の通信システムは、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記移動端末が現在接続している前記エッジ装置とを関連付ける関連情報を保持するドメイン管理装置とを、
有し、
前記ドメイン管理装置が、前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記ドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べ、前記移動端末の関連情報を保持している場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置に対して、前記移動端末との間の接続が有効か否かの問い合わせを行って、前記移動端末との間の接続が有効な場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を保持する一方、前記移動端末との間の接続が有効でない場合には、前記移動端末と第２のエッジ装置を関連付ける関連情報を消去するとともに、前記移動端末と前記第１のエッジ装置とを関連付ける関連情報を保持するように構成されている。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第１の実施の形態における構成及び動作が実現可能となる。

上記の目的を達成するため、本発明の通信システムは、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記インタフェースが現在接続している前記エッジ装置とを関連付ける関連情報を保持するドメイン管理装置とを、
有し、
前記ドメイン管理装置が、前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記ドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べ、前記第１のインタフェースと、前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している場合には、前記第１のインタフェースと前記第２のエッジ装置とを関連付ける関連情報を消去するとともに、前記第１のインタフェースと前記第１のエッジ装置との関連情報を保持し、前記第１のインタフェースとは異なる第２のインタフェースと、前記第２のエッジ装置とを関連付ける関連情報を保持している場合には、前記第２のインタフェースと前記第２のエッジ装置とを関連付ける関連情報に加えて、前記第１のインタフェースと前記第１のエッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として保持するように構成されている。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第１の実施の形態においてインタフェース単位で接続の識別を行う場合の構成及び動作が実現可能となる。

上記の目的を達成するため、本発明の通信システムは、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記移動端末が現在接続している前記エッジ装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
有し、
前記複数のドメイン管理装置のうちの１つが、前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信し、前記ドメイン管理装置自身が前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持していない場合、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かの問い合わせを行い、他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記移動端末と前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を保持するように構成されている。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第２の実施の形態における構成及び動作が実現可能となる。

上記の目的を達成するため、本発明の通信システムは、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記インタフェースが現在接続している前記エッジ装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
有し、
前記複数のドメイン管理装置のうちの１つが、前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信し、前記ドメイン管理装置自身が前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する前記関連情報を保持していない場合、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する関連情報を保持しているか否かの問い合わせを行い、他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記第１のインタフェースとは異なる第２のインタフェースと前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記第１のインタフェースと前記第１エッジ装置とを関連付ける関連情報に加えて、前記第２のインタフェースと前記第２エッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として保持するように構成されている。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第２の実施の形態においてインタフェース単位で接続の識別を行う場合の構成及び動作が実現可能となる。

上記の目的を達成するため、本発明の通信システムは、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記移動端末が現在接続している前記エッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
有し、
前記複数のドメイン管理装置のうちの１つである第１のドメイン管理装置が、前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記第１のドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べ、前記移動端末の関連情報を保持していない場合には、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記移動端末の関連情報を保持している場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して前記移動端末との間の接続が有効か否かの問い合わせを行い、前記問い合わせの結果において前記移動端末との間の接続が有効な場合には、前記第１のドメイン管理装置は、前記移動端末と前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報と、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置を関連付ける関連情報とを保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記問い合わせの結果において前記移動端末との間の接続が有効ではない場合には、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を消去するとともに、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持し、さらに、他の前記ドメイン管理装置においても同様の更新処理を行わせるように構成されている。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第３の実施の形態における構成及び動作が実現可能となる。

上記の目的を達成するため、本発明の通信システムは、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記インタフェースが現在接続している前記エッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
有し、
前記複数のドメイン管理装置のうちの１つである第１のドメイン管理装置が、前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記第１のドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する前記関連情報を保持しているか否かを調べ、前記第１のインタフェースに関する関連情報を保持していない場合には、前記第１インタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記第１のインタフェースに関する関連情報を保持している場合には、前記第１のインタフェースに関する関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して、前記移動端末の第１のインタフェースとの間の接続が有効か否かの問い合わせを行い、前記問い合わせの結果において前記第１インタフェースとの間の接続が有効な場合には、前記第１のドメイン管理装置は、前記第１のインタフェースと前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報に加えて、前記第２のインタフェースと第２エッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を同一の前記移動端末の関連情報として保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記問い合わせの結果において前記第１のインタフェースとの間の接続が有効ではない場合には、前記第２のインタフェースと第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を消去するとともに、前記第１のインタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持し、さらに、他の前記ドメイン管理装置においても同様の更新処理を行わせるように構成されている。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第３の実施の形態においてインタフェース単位で接続の識別を行う場合の構成及び動作が実現可能となる。

さらに、本発明の通信システムは、上記の通信システムにおいて、前記アクセスネットワーク内を伝送する前記移動端末のフローフィルタリングに係るフィルタの管理を行う１つ又は複数のポリシサーバを有することが可能である。
この構成により、集中型ポリシサーバ又は分散型ポリシサーバによって、移動端末のフローフィルタリングに係るフィルタの管理が行われるようになる。

さらに、本発明の通信システムは、上記の通信システムにおいて、前記ドメイン管理装置は、前記移動端末のポリシを参照して、前記関連情報の管理を行うように構成されている。
この構成により、各移動端末に対応するポリシに応じたバインディング情報の登録やアクセスコントロールを行うことが可能となる。

さらに、本発明の通信システムは、上記の通信システムにおいて、前記移動端末が単一のインタフェースを使用している場合には、前記ドメイン管理装置は、前記移動端末が複数のインタフェースの同時接続を行おうとしているか否かの問い合わせを行わないように構成されている。
この構成により、ドメイン管理装置は、無駄な問い合わせ（あるいは冗長な問い合わせ）を省くことが可能な場合を即座に判断することが可能となる。

さらに、本発明の通信システムは、上記の通信システムにおいて、前記ドメイン管理装置は、前記移動端末のポリシとして、前記移動端末が複数のインタフェースを同時に接続しない旨、前記移動端末が単一のインタフェースのみを有している旨、複数のインタフェースのうちの１つしか使用しない旨のいずれかが規定されている場合に、前記移動端末が単一のインタフェースを使用していると判断するように構成されている。
この構成により、ドメイン管理装置は、無駄な問い合わせ（あるいは冗長な問い合わせ）を省くことが可能な場合を即座に判断することが可能となる。

さらに、本発明の通信システムは、上記の通信システムにおいて、前記移動端末のポリシを管理するポリシサーバを有する。
この構成により、ネットワーク側において、移動端末のポリシを管理することが可能となる。

さらに、本発明の通信システムは、上記の通信システムにおいて、前記移動端末のローカルモビリティをネットワーク側で実現する前記プロトコルとして、ＰＭＩＰを用いるように構成されている。
この構成により、ＰＭＩＰが導入されているネットワークに本発明を適用することが可能となる。

上記の目的を達成するため、本発明のドメイン管理装置は、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
前記関連情報を保持する関連情報保持手段と、
前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
前記チェック手段で前記移動端末の関連情報を保持していることが把握された場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置に対して、前記移動端末との間の接続が有効か否かの問い合わせを行う問い合わせ手段と、
前記問い合わせ手段による問い合わせ結果において、前記移動端末との間の接続が有効であると判断された場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を前記関連情報保持手段に保持させる一方、前記移動端末との間の接続が有効でないと判断された場合には、前記移動端末と第２のエッジ装置を関連付ける関連情報を前記関連情報保持手段から消去するとともに、前記移動端末と前記第１のエッジ装置とを関連付ける関連情報を前記関連情報保持手段に保持させる情報保持制御手段とを、
有する。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第１の実施の形態における構成及び動作が実現可能となる。

上記の目的を達成するため、本発明のドメイン管理装置は、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
前記関連情報を保持する関連情報保持手段と、
前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
前記チェック手段で前記第１のインタフェースと、前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持していることが把握された場合には、前記第１のインタフェースと前記第２のエッジ装置とを関連付ける関連情報を前記関連情報保持手段から消去するとともに、前記第１のインタフェースと前記第１のエッジ装置との関連情報を前記関連情報保持手段に保持させ、前記第１のインタフェースとは異なる第２のインタフェースと、前記第２のエッジ装置とを関連付ける関連情報を保持していることが把握された場合には、前記第２のインタフェースと前記第２のエッジ装置とを関連付ける関連情報に加えて、前記第１のインタフェースと前記第１のエッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として前記関連情報保持手段に保持させる情報保持制御手段とを、
有する。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第１の実施の形態においてインタフェース単位で接続の識別を行う場合の構成及び動作が実現可能となる。

上記の目的を達成するため、本発明のドメイン管理装置は、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
前記関連情報を保持する関連情報保持手段と、
前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
前記チェック手段で前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持していないことが把握された場合には、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かの問い合わせを行う問い合わせ手段と、
他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記移動端末と前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を前記関連情報保持手段に保持させる情報保持制御手段とを、
有する。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第２の実施の形態における構成及び動作が実現可能となる。

上記の目的を達成するため、本発明のドメイン管理装置は、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
前記関連情報を保持する関連情報保持手段と、
前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のインタフェースに関する前記関連情報を保持しているか否かを調べるチェック手段と、
前記チェック手段で、前記ドメイン管理装置自身が前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する前記関連情報を保持していないことが把握された場合には、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する関連情報を保持しているか否かの問い合わせを行う問い合わせ手段と、
他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記第１のインタフェースとは異なる第２のインタフェースと前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記第１のインタフェースと前記第１エッジ装置とを関連付ける関連情報に加えて、前記第２のインタフェースと前記第２エッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として前記関連情報保持手段に保持させる情報保持制御手段とを、
有する。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第２の実施の形態においてインタフェース単位で接続の識別を行う場合の構成及び動作が実現可能となる。

上記の目的を達成するため、本発明のドメイン管理装置は、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持するドメイン管理装置であって、
前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
前記関連情報を保持する関連情報保持手段と、
前記関連情報保持手段に保持している前記関連情報が更新された場合、他のドメイン管理装置に対して同様の情報更新を行うように指示する更新指示手段と、
前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
前記チェック手段で前記移動端末の関連情報を保持していないことが把握された場合には、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第１の情報保持制御手段と、
前記チェック手段で前記移動端末の関連情報を保持していることが把握された場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して前記移動端末との間の接続が有効か否かの問い合わせを行う問い合わせ手段と、
前記問い合わせ手段による問い合わせ結果において前記移動端末との間の接続が有効であると判断された場合には、前記移動端末と前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報と、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置を関連付ける関連情報とを前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる一方、前記問い合わせ手段による問い合わせ結果において前記移動端末との間の接続が有効ではないと判断された場合には、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を消去するとともに、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させ、さらに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第２の情報保持制御手段とを、
有する。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第３の実施の形態における構成及び動作が実現可能となる。

上記の目的を達成するため、本発明のドメイン管理装置は、複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持するドメイン管理装置であって、
前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
前記関連情報を保持する関連情報保持手段と、
前記関連情報保持手段に保持している前記関連情報が更新された場合、他のドメイン管理装置に対して同様の情報更新を行うように指示する更新指示手段と、
前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のインタフェースに関する前記関連情報を保持しているか否かを調べるチェック手段と、
前記チェック手段で、前記第１のインタフェースに関する前記関連情報を保持していないことが把握された場合には、前記第１インタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第１の情報保持制御手段と、
前記チェック手段で前記第１のインタフェースに関する関連情報を保持していることが把握された場合には、前記第１のインタフェースに関する関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して、前記移動端末の第１のインタフェースとの間の接続が有効か否かの問い合わせを行う問い合わせ手段と、
前記問い合わせ手段による問い合わせ結果において前記第１インタフェースとの間の接続が有効であると判断された場合には、
前記第１のインタフェースと前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報に加えて、前記第２のインタフェースと第２エッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を同一の前記移動端末の関連情報として前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる一方、前記問い合わせ手段による問い合わせ結果において前記第１のインタフェースとの間の接続が有効ではないと判断された場合には、前記第２のインタフェースと第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段から消去するとともに、前記第１のインタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させ、さらに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第２の情報保持制御手段とを、
有する。
この構成により、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようになる。また、この構成により、後述の本発明の第３の実施の形態においてインタフェース単位で接続の識別を行う場合の構成及び動作が実現可能となる。

さらに、本発明のドメイン管理装置は、上記のドメイン管理装置において、前記移動端末のポリシを参照して、前記関連情報の管理を行うように構成されている。
この構成により、各移動端末に対応するポリシに応じたバインディング情報の登録やアクセスコントロールを行うことが可能となる。

さらに、本発明のドメイン管理装置は、上記のドメイン管理装置において、前記移動端末のポリシとして、前記移動端末が複数のインタフェースを同時に接続しない旨、前記移動端末が単一のインタフェースのみを有している旨、複数のインタフェースのうちの１つしか使用しない旨のいずれかが規定されている場合には、前記移動端末が複数のインタフェースの同時接続を行おうとしているか否かの問い合わせを行わないように構成されている。
この構成により、ドメイン管理装置は、無駄な問い合わせ（あるいは冗長な問い合わせ）を省くことが可能な場合を即座に判断することが可能となる。

本発明は上記の構成を有しており、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようにするという効果を有している。

以下、図面を参照しながら、本発明の実施の形態について説明する。

本発明によれば、モバイルノードが通信ネットワークドメイン内でその複数のインタフェースを接続することが可能となる方法が提供される。これにより、通信ネットワークドメイン内において、モバイルノードによる同時接続が実現される。

なお、本明細書では、“ＮｅｔＬＭＭドメイン”という用語は、１つ又は複数のモバイルアクセスゲートウェイ（ＭＡＧ：Mobile Access Gateway）や１つ又は複数のローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）がアクセスネットワークに接続されており、何らかの局所的なモビリティ管理プロトコル（Localized Mobility Management Protocol）を実行することによって、接続されたモバイルノードに対してモビリティ動作を提供する通信ネットワークドメインを表すものとする。

さらに、本明細書では、“マルチモードノード”という用語は、選択可能な複数のアドレス（又はプレフィックス）を有するノード（ホスト又はルータ）を表すものとする。これらのアドレスは、メディアアクセスコントロール（ＭＡＣ：Media Access Control）アドレスであってもよく、ＩＰｖ４又はＩＰｖ６アドレスであってもよい。複数のアドレスの選択が可能なことは、マルチモードノードが、リンク上で通知される１つ又は複数のプレフィックスを受信でき、同一リンクあるいは異なるリンク上で使用可能な複数のインタフェースを有していることを意味する。なお、複数のインタフェースとは、論理的なインタフェースであればよく、例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合とのと同等に動作できるよう構成されていてもよいことはよく知られている。

＜第１の実施の形態＞
まず、本発明の第１の実施の形態について説明する。図１には、本発明の第１の実施の形態におけるネットワークトポロジ（ネットワークの接続形態）の一例が図示されている。図１に図示されているネットワークはＮｅｔＬＭＭドメイン１８であり、ＮｅｔＬＭＭドメイン１８は、モバイルノード(ＭＮ：Mobile Node）１０、２つのモバイルアクセスゲートウェイ（ＭＡＧ：Mobile Access Gateway）１１ａ、１１ｂ、２つのアクセスシステム１２ａ、１２ｂ、ローカルモビリティアンカ（ＬＭＡ）１３を有している。

なお、図１に図示されているネットワークにおいて、ＭＮ１０は、ＮｅｔＬＭＭドメイン１８内で同時接続を実現するために、複数のＭＡＧ１１ａ、１１ｂに接続することができるマルチモードノードである。ＭＮ１０は、ＮｅｔＬＭＭドメイン１８に参加する際にはＭＡＧに接続して、ＮｅｔＬＭＭドメイン１８に接続する権利を獲得する。なお、ＭＮ１０がＭＡＧに接続する方法として、例えばＩＥＥＥ８０２．１ｘの技術を用いる方法が挙げられるが、これに限定されるものではない。

また、図１に図示されているＭＡＧ１１ａ及びＭＡＧ１１ｂは、ＭＮ１０が接続可能なルータであり、ＭＮ１０にとって、ＮｅｔＬＭＭドメイン１８における最初のホップのルータとして機能する。ＭＡＧは、リンクレイヤによって提供されるある特定のリンクを通じて、モバイルノードに接続される。図１に図示されているネットワークにおいては、ＭＮ１０はリンク１４を通じてＭＡＧ１１ａと接続するとともに、リンク１５を通じてＭＡＧ１１ｂと接続する。

なお、このネットワークで使用されるリンクレイヤ技術としては、例えばＩＥＥＥ８０２．１１の技術やブルートゥースなどが挙げられるが、これらに限定されるものではない。つまり、ＭＡＧとモバイルノードとの間に実際には別のルータが存在しているような場合でも、ＩＰトンネリング技術などを用いて、特定の接続（セッション）については、ＭＡＧが最初のホップのルータとして（ＩＰトンネルが仮想的なリンクとして）機能するような方法でもよい。各ＭＡＧは、ＮｅｔＬＭＭドメイン１８内のＬＭＡとの間におけるメッセージ交換で使用する識別子を有している。なお、ＭＡＧとＬＭＡとの間におけるメッセージ交換は、例えばシグナリングメッセージによって行われてもよいが、これに限定されるものではない。

図１に図示されているネットワークでは、ＮｅｔＬＭＭドメイン１８は、２つのＭＡＧ１１ａ、１１ｂ及びアクセスシステム１２ａ、１２ｂを有している。なお、ＮｅｔＬＭＭドメイン１８は、多数（３つ以上）のＭＡＧ及びアクセスシステムを有していてもよい。また、図１には、ＮｅｔＬＭＭドメイン１８にはモバイルノード１０が１つのみ接続されている状態が図示されているが、当業者であれば、ＮｅｔＬＭＭドメイン１８には複数のモバイルノード１０が接続可能なことは明らかである。

各アクセスシステムには、モバイルノード１０が接続可能なＭＡＧが少なくとも１つ存在しており、これによって、アクセスシステムへのアクセスが可能となる。図１に図示されているネットワークでは、ＭＡＧ１１ａはアクセスシステム１２ａに存在し、ＭＡＧ１１ｂはアクセスシステム１２ｂに存在している。なお、アクセスシステム１２ａ、１２ｂで用いられるネットワーク技術としては、例えばＷｉ−Ｆｉ、ブルートゥース、セルラなどの技術が挙げられるが、これらに限定されるものではない。

各ＭＡＧは、ＭＡＧの識別情報（ＩＤ）とそのＭＡＧがサポートしているデータ転送モード（例えばＩＰｖ６−ｉｎ−ＩＰｖ６）とを含むアソシエーションリクエストメッセージ（Association Request message）を送信することによって、ＬＭＡに接続する。なお、図１には、ＭＡＧ１１ａはリンク１６を使用してＬＭＡ１３と通信を行い、ＭＡＧ１１ｂはリンク１７を使用してＬＭＡ１３と通信を行う状態が図示されている。

また、図１に図示されているネットワークにおいて、ＬＭＡ１３は、モバイルノード１０がＮｅｔＬＭＭドメイン１８内を移動している間は、そのモバイルノード１０のアドレスへの到達可能性（reachability）を維持することができるルータである。ＬＭＡ１３はＮｅｔＬＭＭドメイン１８に存在する各モバイルノードに関する転送情報を保持する機能を有している。なお、転送情報としては、例えば識別子によってモバイルノードとアドレス情報とを関連付ける（モバイルノードと、モバイルノードに接続しているＭＡＧとを関連付ける）マッピングのセットや、ＬＭＡ１３とＮｅｔＬＭＭドメイン１８内のＭＡＧとの対応関係などが挙げられるが、これらに限定されるものではない。

ＬＭＡ１３は、ＮｅｔＬＭＭドメイン１８内の任意のＭＡＧからアソシエーションリクエストメッセージを受信した場合には、そのＭＡＧとの接続を確立して、ＭＡＧに対してアソシエーションリクエスト確認（アクノレッジメント）メッセージを応答する。なお、アソシエーションリクエスト確認メッセージに、ＬＭＡ１３のＩＤや、上述のＭＡＧへのデータ転送モードに対する同意などの情報が含まれてもよいが、これらに限定されるものではない。

モバイルノードは、ＮｅｔＬＭＭドメインに接続する際に、まず、例えばステートフルアドレス構成又はステートレスアドレス構成を用いて、アドレスを構成する必要がある。以降、このアドレス構成処理をＭＮアドレス割り当て処理と呼ぶ。このＭＮアドレス割り当て処理は、ＮｅｔＬＭＭドメイン１８への接続を提供している１つ又は複数のＬＭＡによって行われる。

以下、より明確にＭＮアドレス割り当て処理について説明を行うため、図１に図示されているネットワークを参照しながら説明を行う。ここでは、ＭＮ１０がＮｅｔＬＭＭドメイン１８内を移動し、そのルータ要請段階（router solicitation phase）でＭＡＧ１１ａを検出したと仮定する。ＭＮ１０はＭＡＧ１１ａとの接続処理を行い、ＭＮアドレス割り当て処理が開始される。そして、ＭＡＧ１１ａは、ＮｅｔＬＭＭドメイン１８におけるＭＮ１０の存在を登録するために、ＬＭＡ１３に対して位置登録メッセージを送信する。なお、この位置登録メッセージには、ＭＡＧ１１ａのＩＤやＭＮ１０のＩＤが含まれてもよいが、これらに限定されるものではない。

続いて、ＭＮアドレス割り当て処理において、ＭＡＧ１１ａから位置登録メッセージを受信したＬＭＡ１３は、ＭＡＧ１１ａがＭＮ１０へのルータ通知に使用可能なＮｅｔＬＭＭドメイン１８のプレフィックス（以下、ＮｅｔＬＭＭプレフィックスと記載することもある）を含む位置登録確認メッセージによって応答を行う。なお、この位置登録確認メッセージにはＮｅｔＬＭＭプレフィックスが１つのみではなく、複数含まれていてもよい。

ＮｅｔＬＭＭプレフィックスを取得すると、続いてＭＡＧ１１ａは、取得したＮｅｔＬＭＭプレフィックスをルータ通知によってＭＮ１０に送信する。なお、ＭＮ１０は、ＮｅｔＬＭＭプレフィックスを使用してＮｅｔＬＭＭドメイン１８で使用可能なアドレスを構成することが望ましい。以下、本明細書では、ネットワークプレフィックスにＮｅｔＬＭＭプレフィックスを用いて構成されたアドレスを“ＮｅｔＬＭＭアドレス”と呼ぶことにする。

ＭＮ１０がステートフルアドレス構成又はステートレスアドレス構成によってＮｅｔＬＭＭアドレスの構成を完了すると、ＭＡＧ１１ａは、ＭＮアドレスセットアップメッセージをＬＭＡ１３に送信して、ＭＮ１０のＮｅｔＬＭＭアドレスをＬＭＡ１３に登録する。なお、このＭＮアドレスセットアップメッセージには、ＭＡＧ１１ａのＩＤ、ＭＮ１０のＩＤ、ＭＮ１０のＮｅｔＬＭＭアドレスが含まれてもよいが、これらに限定されるものではない。ＬＭＡ１３は、例えば重複アドレス検出（ＤＡＤ）やその他の同様の技術を利用して、ＮｅｔＬＭＭドメイン１８内におけるＭＮ１０のＮｅｔＬＭＭアドレスのユニーク性をチェックする。

ＭＮ１０のＮｅｔＬＭＭアドレスがユニークであることが分かると、ＬＭＡ１３は、ＭＮ１０のパケットに関する転送ステートを作成し、ＭＮ１０に関するパケットのセットアップを承認するＭＮアドレスセットアップリプライメッセージを送信する。また、ＭＡＧ１１ａも、承認を通知するＭＮアドレスセットアップリプライメッセージを受信すると、さらに、ＭＮ１０あてのパケットに関する転送ステート作成する。この処理によって、ＭＮアドレス割り当て処理は完了となり、ＭＮ１０はＮｅｔＬＭＭドメイン１８においてパケットの送受信を行えるようになる。

ＭＮ１０はマルチモードノードであり、図１に図示されているネットワークにおいて、上述のようにＭＮ１０のプライマリインタフェースを使用してＭＡＧ１１ａに接続している状態で、ＭＮ１０のセカンダリインタフェースを使用してＭＡＧ１１ｂに接続を試みることが可能である。ＭＮ１０は、ＮｅｔＬＭＭドメイン１８で複数の接続を持つことにより、例えば負荷バランス（load balancing）や特定のルートを通るフローのフィルタリングなどの機能を実行することが可能となる。実際の適用例としては、ＭＮ１０が２つのアクティブなフロー（ビデオフロー及びデータフロー）を持っている場合が挙げられる。ＭＮ１０がＮｅｔＬＭＭドメイン１８内のＭＡＧ１１ａ、１１ｂの両方に接続できるようにすることによって、ＭＮ１０は、例えばビデオフローをＭＡＧ１１ａ経由で伝送し、データフローをＭＡＧ１１ｂ経由で伝送するように選択できるようになる。これにより、ＭＮ１０は、フロータイプやＭＮ１０が接続されている現在のネットワークのアクセス特性などに基づいて、どのようにフローの経路を定めるかを自由に指定できるようになる。

本発明は、上述のようなＮｅｔＬＭＭドメイン１８に存在するモバイルノードからの複数の接続をサポートすることを目的とする。この目的を達成するため、本発明の実施の形態では、ＬＭＡは、自身のルーティングキャッシュに既に存在しているＭＮのＩＤを含む位置登録メッセージを別の新たなＭＡＧ（現在の転送ステートによって設定されているＭＡＧとは異なるＭＡＧ）から受信した場合に、先に接続しているＭＡＧ（現在の転送ステートによって設定されているＭＡＧ）に対して問い合わせを行うことが可能である。ＬＭＡは問い合わせを行うことによって、先に接続しているＭＡＧに対して、モバイルノードの接続が依然としてアクティブか否かを確認することが可能となる。

ＮｅｔＬＭＭドメイン内でのＭＮ１０による同時接続が受け入れられて、ＬＭＡが、自身のルーティングキャッシュに既に存在しているＭＮ１０のＩＤが記載された位置登録メッセージをＭＡＧから受信した場合には、下記の２つの状況が起こっている可能性がある。第１のケースは、モバイルノードが、ＮｅｔＬＭＭドメイン１８でＬＭＡに対して複数の接続を同時に行おうとしている場合である。一方、第２のケースは、モバイルノードがあるＭＡＧから別のＭＡＧに実際に移動しており、ＮｅｔＬＭＭドメイン１８で順次的（シーケンシャル）な接続（すなわち、ハンドオーバ）を行おうとしている場合である。

ＬＭＡが上述の２つのケースを区別するためには、モバイルノードが同時接続又は順次的な接続のどちらをリクエストしているかを判断する必要がある。本発明では、ＬＭＡは、先に接続しているＭＡＧへの問い合わせ（クエリメッセージ）に対する応答（クエリリプライメッセージ）に基づいて、上述の２つのケースの判別を行う。

モバイルノードがＬＭＡへの同時接続を実行している場合（第１のケース）には、モバイルノードと問い合わせを受けたＭＡＧとの間の接続はまだアクティブな状態にある。したがって、問い合わせを受けたＭＡＧは、モバイルノードの接続がまだアクティブであることを示すクエリリプライメッセージをＬＭＡに送信する。しかしながら、モバイルノードがＬＭＡに対して順次的な接続を実行している場合には、モバイルノードはＮｅｔＬＭＭドメイン１８内で、問い合わせを受けたＭＡＧから別のＭＡＧに移動しているので、モバイルノードと問い合わせを受けたＭＡＧとの間の接続は既に切断されている。したがって、問い合わせを受けたＭＡＧは、モバイルノードの接続がアクティブではない旨を示すクエリリプライメッセージをＬＭＡに送信する。

以下、モバイルノードがＮｅｔＬＭＭドメインで同時接続を実現するための好適な方法について詳細に説明する。この好適な方法では、ＬＭＡ１３が、ＭＮ１０とＭＡＧ１１ａとの間の接続が有効か否かを問い合わせるメッセージ（以下、ハートビート（Heartbeat）メッセージと記載）を使用してＭＡＧ１１ａに問い合わせを行い、ＭＮ１０とＭＡＧ１１ａとの接続状態をチェックする。

例えば、ＬＭＡ１３は、ＭＮ１０に関する有効なエントリがＬＭＡ１３のルーティングキャッシュに登録されており、かつ、そのＭＮ１０に関する位置登録リクエストをＭＡＧ１１ｂから受信した場合に、ハートビートメッセージの送信を行う。そして、ＬＭＡ１３は、ハートビートメッセージに対する応答メッセージ（以下、ハートビートレスポンスメッセージと記載）をＭＡＧから受信し、このハートビートレスポンスメッセージに含まれている情報を参照することによって、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続又は順次的な接続（すなわち、ハンドオーバ）のどちらを実行したいかを判断する。

なお、この好適な方法において、本発明におけるハートビートメッセージ（ＭＮ１０とＭＡＧ１１ａとの間の接続が有効か否かを問い合わせるメッセージ）は、非特許文献１に定義されているＮｅｔＬＭＭに係るハートビートメッセージ（ＬＭＡとＭＡＧとの間で、相手の接続状態を取得するために送信されるメッセージ）を拡張することによって実現可能である。

以下、図２を参照しながら、モバイルノードがＮｅｔＬＭＭドメイン内で同時接続を行うための好適な方法について説明する。図２には、本発明の第１の実施の形態におけるメッセージ交換の一例が図示されている。ここでは、ＭＮ１０がＭＡＧ１１ａに接続することによって、ステップＳ２０において、ＭＡＧ１１ａが、ＬＭＡ１３に対して、ＭＮ１０に関するＭＮアドレス割り当て処理の実行を開始する。そして、ＭＡＧ１１ａがＬＭＡ１３に対してＭＮ１０の登録を行い、その結果、ＬＭＡ１３のルーティングキャッシュには、ＭＮ１０の情報が格納される。なお、ＭＮ１０の情報としては、例えばＭＮ１０のＩＤ及びＭＡＧ１１ａのＩＤを用いることが可能であるが、これらに限定されるものではない。

ここで、ＭＮ１０はマルチモードノードであり、ＬＭＡ１３への複数の接続を同時に行うために、セカンダリインタフェースによってＭＡＧ１１ｂに接続を行うとする。ＭＡＧ１１ｂへのＭＮ１０の接続を登録するため、ＭＡＧ１１ｂは、ステップＳ２１において、位置登録メッセージ（ＬｏｃＲｅｇ）をＬＭＡ１３に送信する。なお、位置登録メッセージには、例えばＭＮ１０のＩＤ、ＭＡＧ１１ｂのＩＤ、ＬＭＡ１３のＩＤなどが含まれてもよいが、これらに限定されるものではない。

ＬＭＡ１３は、ステップＳ２２において、ＭＡＧ１１ｂからの位置登録メッセージを受信して処理を行う際に、受信した位置登録メッセージに含まれるＭＮ１０のＩＤが自身のルーティングキャッシュに存在しているか否かを調べることによって、ＭＮ１０がＮｅｔＬＭＭドメイン１８において同時接続あるいは順次的な接続（すなわちハンドオーバ）を実行しようとしているか否かを判断する。そして、ＬＭＡ１３は、自身のルーティングキャッシュにＭＮ１０のＩＤが既に存在していることを特定すると、ＭＮ１０がＮｅｔＬＭＭドメイン１８において同時接続を実行しようとしているのか、あるいは順次的な接続（すなわちハンドオーバ）を実行しようとしているのかをチェックする処理を開始する。ＬＭＡ１３は、ステップＳ２３において、ＭＮ１０によるＭＡＧ１１ａへの接続がまだアクティブか否かを特定するために、ハートビートメッセージ（ＨｅａｒｔＢｅａｔ）を送信してＭＡＧ１１ａに問い合わせを行う。なお、この本発明におけるハートビートメッセージには、ＭＮ１０のＩＤ、ＭＡＧ１１ａのＩＤ、ＬＭＡ１３のＩＤが含まれてもよいが、これらに限定されるものではない。

ＭＮ１０は、ＭＡＧ１１ｂを通じてＮｅｔＬＭＭドメイン１８における同時接続を実現しようとしているので、ＭＮ１０とＭＡＧ１１ａとの間の現在の接続は、依然としてアクティブである。ＭＡＧ１１ａは、ＬＭＡ１３からハートビートメッセージを受信した場合に、ステップＳ２４において、ＬＭＡ１３に対して、ＭＮ１０の接続がまだアクティブであることを示すクエリリプライメッセージであるハートビート確認（アクノレッジメント）メッセージ（ＨｅａｒｔＢｅａｔＡｃｋ）を送信する。なお、このハートビート確認メッセージには、例えばＭＮ１０のＩＤ、ＭＡＧ１１ａのＩＤ、ＬＭＡ１３のＩＤが含まれてもよいが、これらに限定されるものではない。

ＭＡＧ１１ａからハートビート確認メッセージを受信すると、ＬＭＡ１３は、ＭＮ１０がＮｅｔＬＭＭドメイン１８に同時接続しようとしている旨を把握する。したがって、ＬＭＡ１３は、ステップＳ２５において、位置登録が正常に行われた旨を示す位置登録確認メッセージ（ＬｏｃＲｅｇＲｅｓ）をＭＡＧ１１ｂに返信する処理を行う。なお、この位置登録確認メッセージには、例えば１つ又は複数のＮｅｔＬＭＭプレフィックス（ＭＡＧ１１ｂからＭＮ１０に送信されるルータ通知（ルータアドバタイズメント）に使用されるＮｅｔＬＭＭプレフィックス）が含まれてもよいが、これに限定されるものではない。

ＭＮ１０は、ルータ通知内のＮｅｔＬＭＭプレフィックスを使用して、ＮｅｔＬＭＭドメイン１８で使用可能なアドレス（ＮｅｔＬＭＭアドレス）を構成する。ＭＡＧ１１ｂは、例えば重複アドレス検出（ＤＡＤ：Duplicate Address Detection）を使用して、ＭＮ１０のＮｅｔＬＭＭアドレスが有効であることを把握する。そして、ＭＡＧ１１ｂは、ＭＮ１０のＮｅｔＬＭＭアドレスがユニークであることを検証すると、ステップＳ２６において、ＭＮアドレスセットアップメッセージ（ＡｄｄｒＳｅｔｕｐ）をＬＭＡ１３に送信して、ＬＭＡ１３のルーティングキャッシュ内のＭＮ１０に関するエントリのアップデートを行う。なお、このＭＮアドレスセットアップメッセージには、ＭＡＧ１１ｂのＩＤ、ＭＮ１０のＩＤ、ＭＮ１０のＮｅｔＬＭＭアドレスが含まれてもよいが、これらに限定されるものではない。

ＭＮアドレスセットアップメッセージを受信したＬＭＡ１３は、ステップＳ２７において、このＭＮアドレスセットアップメッセージの処理を行い、ＭＮ１０とＭＡＧ１１ａとの接続、ＭＮ１０とＭＡＧ１１ｂとの接続の両方が含まれるように、自身のルーティングキャッシュのＭＮ１０に関するエントリのアップデートを行う。ＭＮ１０に関するエントリにおいて、ＭＮ１０とＭＡＧ１１ａとの接続に対してＭＮ１０とＭＡＧ１１ｂとの接続が追加されたことにより、ＬＭＡ１３は、ＭＮ１０の複数のインタフェースを経由してＭＮ１０と通信を行うことが可能となり、これによって、例えばＭＮ１０のフローフィルタリングが実行される。

そして最後に、ＬＭＡ１３は、ステップＳ２８において、ＭＡＧ１１ｂに対して、ＭＮ１０のＮｅｔＬＭＭアドレスがＬＭＡ１３に登録された旨を通知するＭＮアドレスセットアップ確認メッセージ（ＡｄｄｒＳｅｔｕｐＲｅｓ）を送信する。なお、このＭＮアドレスセットアップ確認メッセージには、ＬＭＡ１３のＩＤやＭＮ１０のＩＤが含まれてもよいが、これらに限定されるものではない。

また、上述の動作において、ＬＭＡが、モバイルノードのインタフェースＩＤ（ＩＦ−ＩＤ）を使用して、モバイルノードがＮｅｔＬＭＭドメイン１８内で同時接続を行おうとしているのか、あるいは順次的な接続（すなわち、ハンドオーバ）を行おうとしているのかを判断することも可能である。図２において、ＭＡＧ１１ａは、ステップＳ２０におけるＭＮアドレス割り当て処理の間に、ＭＮ１０の第１ＩＦ−ＩＤ（ＭＡＧ１１ａに接続されているインタフェースＩＤ）を更に含む第１位置登録メッセージをＬＭＡ１３に送信する。ＬＭＡ１３は、ＭＮ１０に関するエントリにＭＮ１０の第１ＩＦ−ＩＤが更に含まれるように、ルーティングキャッシュのアップデートを行う。一方、ＭＮ１０がＭＡＧ１１ｂに接続する際には、ＭＮ１０は別のインタフェースＩＤ（第２ＩＦ−ＩＤ）で識別されるインタフェースを使用する。したがって、ＭＡＧ１１ｂは、ステップＳ２１において、ＭＮ１０の第２ＩＦ−ＩＤを更に含む第２位置登録メッセージをＬＭＡ１３に送信する。

ＬＭＡ１３は、ＭＡＧ１１ｂから第２位置登録メッセージを受信すると、ステップＳ２２でその処理を行い、ＭＮ１０の第１及び第２ＩＦ−ＩＤが異なっていることに気付く。したがって、ＬＭＡ１３は、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続を行おうとしていることを把握する。そして、ＬＭＡ１３は、自身のルーティングキャッシュ内に、ＭＮ１０用の追加エントリを作成して、２つの異なるインタフェースＩＤに係る接続が同時に維持される。なお、ステップＳ２２でＭＮ１０の第１及び第２ＩＦ−ＩＤが同一の場合には、ＬＭＡ１３は、そのインタフェースでハンドオーバが行われたことを把握して処理を行うことが可能である。

上述のように、さらにＩＦ−ＩＤを使用した場合には、ＩＦ−ＩＤを使用しない上述の動作と同様の効果を実現しながら、ＬＭＡとＭＡＧとの間のシグナリングメッセージ交換をより少なくすることが可能となる。なお、ＩＦ−ＩＤを使用し、さらにハートビートメッセージ及びハートビート確認メッセージによるクエリ及びレスポンスが行われるようにすることも可能である。

＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。上述の本発明の第１の実施の形態では、ＮｅｔＬＭＭドメインにＬＭＡが１つのみ存在するネットワークに対して、本発明を適用した場合について説明を行った。しかしながら、ＮｅｔＬＭＭドメインには複数のＬＭＡが存在する可能性があり、さらに、モバイルノードはＮｅｔＬＭＭドメイン内の異なるＬＭＡに接続する可能性もある。

図３には、本発明の第２の実施の形態におけるネットワークトポロジ（ネットワークの接続形態）の一例が図示されている。図３に図示されているネットワークはＮｅｔＬＭＭドメイン１８であり、ＮｅｔＬＭＭドメイン１８は、モバイルノード(ＭＮ：Mobile Node）１０、２つのモバイルアクセスゲートウェイ（ＭＡＧ：Mobile Access Gateway）１１ａ、１１ｂ、２つのアクセスシステム１２ａ、１２ｂ、２つのローカルモビリティアンカ（ＬＭＡ）１３ａ、１３ｂを有している。

なお、図３に図示されているネットワークにおいて、ＮｅｔＬＭＭドメイン１８の様々な構成要素は、図１で説明されているものと同様である。一方、図３に図示されているネットワークと大きく異なる点は、ＮｅｔＬＭＭドメイン１８に複数のＬＭＡが導入されていることである。ここでは、ＭＡＧ１１ａはリンク３０を通じてＬＭＡ１３ａに接続されており、ＭＡＧ１１ｂはリンク３１を通じてＬＭＡ１３ｂに接続されている。さらに、図３に図示されているネットワークでは、ＮｅｔＬＭＭドメイン１８には２つのＬＭＡ１３ａ、１３ｂが存在している。なお、ＮｅｔＬＭＭドメイン１８には、より多くのＬＭＡが存在していてもよい。

本発明の第２の実施の形態では、モバイルノードが、図３に図示されているように複数のＬＭＡが存在するＮｅｔＬＭＭドメインで同時接続を行おうとする場合がサポートされる。本発明の第２の実施の形態では、ＬＭＡに登録を行おうとしているモバイルノードに関する情報を取得するために、複数のＬＭＡが互いに問い合わせを行うことが可能である。この結果、上述の本発明の第１の実施の形態と同一の目的が達成される。

図４には、本発明の第２の実施の形態におけるメッセージ交換の一例が図示されている。なお、図４には、モバイルノードが、ＮｅｔＬＭＭドメイン内の複数のＬＭＡに同時接続を実行する際の方法が図示されている。この好適な方法では、ＭＮ１０に関する既存のエントリがＮｅｔＬＭＭドメイン１８の他のＬＭＡに存在しているか否かをチェックするために、ＬＭＡ１３ｂが、ルーティングキャッシュクエリメッセージを使用して、ＮｅｔＬＭＭドメイン１８内の他のＬＭＡ（ＬＭＡ１３ａ）に対して問い合わせを行う。ＬＭＡ１３ｂは、ＭＡＧ１１ｂからのＭＮ１０の登録リクエスト（位置登録メッセージ）を受信することによって、ルーティングキャッシュクエリメッセージの送信を開始する。ＬＭＡ１３ｂは、ルーティングキャッシュクエリメッセージを使用して、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続あるいは順次的な接続（すなわち、ハンドオーバ）を実行しようとしているのか否かを判断する。この好適な方法を使用することによって、モバイルノードの接続は、ＮｅｔＬＭＭドメイン１８内のＬＭＡ間の単純なクエリ・レスポンスメッセージの交換に還元されることになる。

図４に図示されているシーケンスチャートでは、ステップＳ４０において、ＭＡＧ１１ａがＬＭＡ１３ａに対してＭＮ１０の情報を登録し、これによって、ＬＭＡ１３ａは、ＭＮ１０に関するエントリを有することになる。ここで、ＭＮ１０が、ＮｅｔＬＭＭドメイン１８で同時接続を実現するために、ＭＡＧ１１ａと接続しているインタフェースとは異なるセカンダリインタフェースによってＭＡＧ１１ｂとの接続を行う。ＭＮ１０によるＭＡＧ１１ｂへの接続を登録するため、ＭＡＧ１１ｂは、ステップＳ４１において、ＬＭＡ１３ｂに対して位置登録メッセージ（ＬｏｃＲｅｇ）を送信する。なお、この位置登録メッセージには、例えばＭＮ１０のＩＤ、ＭＡＧ１１ｂのＩＤ、ＬＭＡ１３ｂのＩＤが含まれてもよいが、これらに限定されるものではない。

ＬＭＡ１３ａは、ステップＳ４２において、ＭＡＧ１１ｂからの位置登録メッセージを受信して処理を行う際に、ＭＮ１０がＮｅｔＬＭＭドメイン１８において同時接続あるいは順次的な接続（すなわちハンドオーバ）を実行しようとしているか否かのチェックを試みる。そして、ＬＭＡ１３ｂは、ステップＳ４３において、ＮｅｔＬＭＭドメイン１８内の他のＬＭＡ（ＬＭＡ１３ａ）に対してルーティングキャッシュクエリメッセージ（ＲｔｇＣａｃｈｅＱｕｅｒｙ）を送信し、ＬＭＡ１３ａのルーティングキャッシュ内にＭＮ１０に関する既存エントリが存在しているか否かの問い合わせを行う。なお、このルーティングキャッシュクエリメッセージには、例えばＭＮ１０のＩＤやＬＭＡ１３ｂのＩＤが含まれてもよいが、これらに限定されるものではない。

ＬＭＡ１３ａは、ステップＳ４２で送信されたルーティングキャッシュクエリメッセージを受信すると、自身のルーティングキャッシュにＭＮ１０に関するエントリが存在しているか否かを調べ、ＭＮ１０に関するエントリが既に含まれていることを特定する。そして、ＬＭＡ１３ａは、上述の本発明の第１の実施の形態で説明したハートビートメッセージの送信を行って、ＭＮ１０とＬＭＡ１３ａとの間の接続状態を確認した後、ＬＭＡ１３ｂのクエリに対して応答を行う。ＭＮ１０がＮｅｔＬＭＭドメイン１８において複数の接続を行おうとしている場合には、ＬＭＡ１３ａは、ＭＮ１０との接続がアクティブであることを把握し、ステップＳ４４において、ＭＮ１０に関する有効な既存エントリを有していることをＬＭＡ１３ｂに通知するためのルーティングキャッシュクエリレスポンスメッセージ（ＲｔｇＣａｃｈｅＱｕｅｒｙＲｅｓ）を送信する。なお、このルーティングキャッシュクエリレスポンスメッセージには、ＬＭＡ１３ａのＩＤ、ＭＮ１０のＩＤ、ＭＮ１０がＬＭＡ１３ａとの接続に使用しているＮｅｔＬＭＭアドレス（第１ＮｅｔＬＭＭアドレス）が含まれてもよいが、これらに限定されるものではない。

また、ＭＮ１０に関するエントリを有していないＬＭＡが、ルーティングキャッシュクエリメッセージを受信した場合には、ＭＮ１０に関するエントリが存在していない旨を示すルーティングキャッシュクエリレスポンスメッセージによって返信することが望ましい。また、ＬＭＡ１３ａがハートビートメッセージによる問い合わせの結果、ＭＮ１０との接続がアクティブではないことを把握した場合には、その旨を示すルーティングキャッシュクエリレスポンスメッセージによって返信することが望ましい。なお、ここでは、主として、ＬＭＡ１３ａからＬＭＡ１３ｂに対して、ＭＮ１０に関する有効な既存エントリを有していることを通知するルーティングキャッシュクエリレスポンスメッセージ（ＲｔｇＣａｃｈｅＱｕｅｒｙＲｅｓ）が返信される場合について説明する。

ＬＭＡ１３ｂは、ＬＭＡ１３ａからのルーティングキャッシュクエリレスポンスメッセージを受信すると、ＭＮ１０が現在ＬＭＡ１３ａに接続されている旨の通知を受けることになる。したがって、ＬＭＡ１３ｂは、ＭＮ１０がＮｅｔＬＭＭドメイン１８で同時接続を実現しようとしている旨を把握する。これにより、ＬＭＡ１３ｂは、受信したＭＮ１０に関する情報をルーティングキャッシュに格納し、ステップＳ４５において、登録の成功を通知するためにＭＡＧ１１ｂに対して位置登録確認メッセージ（ＬｏｃＲｅｇＲｅｓ）による応答処理を行う。なお、この位置登録確認メッセージには、１つ又は複数のＮｅｔＬＭＭプレフィックスが含まれてもよいが、これに限定されるものではない。１つ又は複数のＮｅｔＬＭＭプレフィックスは、ＭＡＧ１１ｂから送信されるルータ通知によってＭＮ１０に通知される。

ＭＮ１０は、ＮｅｔＬＭＭドメイン１８で使用可能なアドレスを構成するためのＮｅｔＬＭＭプレフィックスをルータ通知に使用する。ＭＡＧ１１ｂは、例えば重複アドレス検出（ＤＡＤ）技術を使用して、ＭＮ１０のＮｅｔＬＭＭアドレスが有効か否かを判定する。なお、ＭＡＧ１１ｂは、ＭＮ１０のＮｅｔＬＭＭアドレスがユニークであることを確認した後、ステップＳ４６においてＬＭＡ１３ｂに対してＭＮアドレスセットアップメッセージ（ＡｄｄｒＳｅｔｕｐ）を送信して、ＬＭＡ１３ｂのルーティングキャッシュ内のＭＮ１０に関するエントリのアップデートを行う。このＭＮアドレスセットアップメッセージには、ＭＡＧ１１ｂのＩＤ、ＭＮ１０のＩＤ、ＭＮ１０の第２ＮｅｔＬＭＭアドレスが含まれてもよいが、これらに限定されるものではない。なお、ＭＮ１０の第１及び第２ＮｅｔＬＭＭアドレスは同一であってもよく、あるいは異なっていてもよい。

ＭＮアドレスセットアップメッセージを受信すると、ＬＭＡ１３ｂは、ステップＳ４７において、ＭＡＧ１１ａとＬＭＡ１３ａとの間における接続、ＭＡＧ１１ｂとＬＭＡ１３ｂとの間における接続の両方が含まれるように、自身のルーティングキャッシュに関するＭＮ１０に関するエントリのアップデートを行う。そして最終的に、ＬＭＡ１３ｂは、ステップ４８において、ＭＮ１０の第２ＮｅｔＬＭＭアドレスがＬＭＡ１３ｂに登録された旨をＭＡＧ１１ｂに通知するＭＮアドレスセットアップ確認メッセージ（ＡｄｄｒＳｅｔｕｐＲｅｓ）をＭＡＧ１１ｂに送信する。なお、このＭＮアドレスセットアップ確認メッセージには、ＬＭＡ１３ｂのＩＤやＭＮ１０のＩＤが含まれてもよいが、これらに限定されるものではない。

また、ＬＭＡ１３ｂが、ＭＮ１０に関するエントリが存在していない旨を示すルーティングキャッシュクエリレスポンスメッセージや、ＭＮ１０との接続がアクティブではない旨を示すルーティングキャッシュクエリレスポンスメッセージを受信した場合には、ＭＮ１０がＮｅｔＬＭＭドメイン１８に対して初めて接続を行おうとしているか、あるいは、順次的な接続（ハンドオーバ）を行っているとみなして、ＭＡＧ１１ｂとＬＭＡ１３ｂとの間における接続のみが含まれるように、自身のルーティングキャッシュに関するＭＮ１０に関するエントリのアップデートを行い、通常どおりの処理を行う。

また、上述の動作において、ＬＭＡがモバイルノードのインタフェースＩＤ（ＩＦ−ＩＤ）を使用して、モバイルノードがＮｅｔＬＭＭドメイン１８内で同時接続を行おうとしているのか、あるいは順次的な接続（すなわち、ハンドオーバ）を行おうとしているのかを判断することも可能である。図４において、ＭＮ１０は、ステップＳ４０におけるＭＮアドレス割り当て処理の間に、ＭＮ１０の第１ＩＦ−ＩＤ（ＭＡＧ１１ａに接続されているインタフェースＩＤ）を更に含む第１位置登録メッセージをＬＭＡ１３ａに送信し、ＬＭＡ１３ａは、ＭＮ１０に関するエントリにＭＮ１０の第１ＩＦ−ＩＤが更に含まれるように、ルーティングキャッシュのアップデートを行う。一方、ＭＮ１０がＭＡＧ１１ｂに接続する際には、ＭＮ１０は別のインタフェースＩＤ（第２ＩＦ−ＩＤ）で識別されるインタフェースを使用する。したがって、ＭＡＧ１１ｂは、ステップＳ４１において、ＭＮ１０の第２ＩＦ−ＩＤを更に含む第２位置登録メッセージをＬＭＡ１３ｂに送信する。

なお、ここでは、ステップＳ４４において、ＬＭＡ１３ａからＬＭＡ１３ｂに対してルーティングキャッシュクエリレスポンスメッセージで返答を行う際に、ＭＮ１０の第１ＩＦ−ＩＤがさらに含まれるようにする。この結果、ＬＭＡ１３ｂは、ＭＮ１０の第１及び第２ＩＦ−ＩＤは異なっていることを把握し、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続を実現しようとしていることを把握する。そして、ＬＭＡ１３ｂは、ＬＭＡ１３ｂのルーティングキャッシュ内に、ＭＮ１０に関する追加エントリの作成処理を行う。本発明の第２の実施の形態においてＩＦ−ＩＤを使用した場合には、上述の本発明の第１の実施の形態においてＩＦ−ＩＤを使用した場合と同様の効果が生じる。

＜第３の実施の形態＞
次に、本発明の第３の実施の形態について説明する。また、図３に図示されているＬＭＡが複数存在するネットワーク構成において、ＬＭＡが、ＮｅｔＬＭＭドメイン内の他のＬＭＡのキャッシュ内のエントリをアップデートできるようにすることも可能である。ここでは、ＬＭＡのキャッシュが変更された場合には、そのＬＭＡが、ＮｅｔＬＭＭドメイン内の他のＬＭＡに対してキャッシュアップデートメッセージの送信が行われる。なお、ＬＭＡのキャッシュが変更される条件としては、例えばモバイルノードによるＬＭＡへの接続又は切断などが挙げられるが、これらに限定されるものではない。また、以下では、このキャッシュアップデートメッセージを、ルーティングキャッシュアップデートメッセージと呼ぶことにする。

本発明の第３の実施の形態では、問い合わせを行うＬＭＡは、ルーティングキャッシュを参照することによって、ＬＭＡがモバイルノードに関する情報を保持しているか否かを特定することができるようになり（すなわち、モバイルノードに関する情報を保持しているＬＭＡを特定できるようになり）、モバイルノードに関する情報を保持している特定のＬＭＡに対して問い合わせを行うことができるようになる。これによって、ＬＭＡがＮｅｔＬＭＭドメイン内でモバイルノードに関する情報の問い合わせを行う際のシグナリング量が少なくなる。

以下、本発明の第３の実施の形態の動作について説明する。ＭＮ１０がＬＭＡ１３ａへの登録に成功した場合（図４のステップＳ４０に対応する処理）、ＬＭＡ１３ａは、ＬＭＡ１３ｂに対して、ＬＭＡ１３ａにおけるＭＮ１０の新たなエントリを通知するルーティングキャッシュアップデートメッセージを送信する。このルーティングキャッシュアップデートメッセージには、ＭＮ１０のＩＤ、ＭＮ１０の第１ＩＦ−ＩＤ、ＬＭＡ１３ａのＩＤ、ＭＮ１０のＮｅｔＬＭＭアドレスなどが含まれてもよいが、これらに限定されるものではない。

ＬＭＡ１３ｂは、ＬＭＡ１３ａから受信したルーティングキャッシュアップデートメッセージ内のＭＮ１０に関する情報によって、自身のルーティングキャッシュのアップデートを行う。さらに、ＬＭＡ１３ｂは、ＬＭＡ１３ａに対して送信された情報が正しく受信（及びアップデート）できた旨を通知する確認メッセージをＬＭＡ１３ａに送信するように選択してもよい。例えば、ＬＭＡ１３ｂは、ＭＮ１０に関する情報の受信に成功した旨を示すルーティングキャッシュアップデート確認メッセージをＬＭＡ１３ａに送信する。なお、ＬＭＡ１３ｂが、ＭＮ１０に関する情報の受信に成功したか否かをＬＭＡ１３ａに対して応答しないことも可能である。

ＭＮ１０がＭＡＧ１１ｂを通じてＬＭＡ１３ｂに第２ＮｅｔＬＭＭアドレスの登録を行おうとしている場合、ＬＭＡ１３ｂは、自身のルーティングキャッシュを参照して、ＭＮ１０のＩＤが既にＮｅｔＬＭＭドメイン１８に存在していることを特定する。そして、ＬＭＡ１３ｂは、特定のＬＭＡ（すなわち、ＬＭＡ１３ａ）に対して問い合わせを行って、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続を実行しようとしているのか、あるいは順次的な接続（すなわち、ハンドオーバ）を実行しようとしているのかを判断する。例えば、ＭＮ１０がＮｅｔＬＭＭドメイン１８における同時接続を実現しようとしている場合には、ＬＭＡ１３ａは、ＬＭＡ１３ｂに対して、ＭＮ１０とＬＭＡ１３ａとの間の接続がまだアクティブである旨を返答する。したがって、ＬＭＡ１３ｂは、ＭＮ１０の追加エントリが登録されるように、自身のルーティングキャッシュエントリのアップデート処理を行う。そして最終的に、ＬＭＡ１３ｂは、アップデートされたＭＮ１０のエントリに関する通知を行って、ＮｅｔＬＭＭドメイン１８内の他のＬＭＡのルーティングキャッシュをアップデートする。

また、上述の動作において、ＬＭＡ１３ａは、ＬＭＡ１３ｂに対して、ルーティングキャッシュアップデートメッセージによってＭＮ１０の第１ＩＦ−ＩＤを更に送信することも可能である。ＭＮ１０が第２ＩＦ−ＩＤを使用してＬＭＡ１３ｂへの登録を行うと、ＬＭＡ１３ｂは、ＭＮ１０の第１ＩＦ−ＩＤと第２ＩＦ−ＩＤとが異なっており、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続を実行しようとしていることを把握する。ＩＦ−ＩＤの使用によって、ＭＮ１０が同時接続又は順次的な接続のどちらを行おうとしているかを問い合わせるクエリメッセージを使用することなく、同様の効果が実現され、さらに、ＬＭＡ間のシグナリングが低減される。

以上、上述の様々な実施の形態において、モバイルノードがＮｅｔＬＭＭドメインで同時接続を実現できるようにするための方法について説明を行った。同時接続によって、ＮｅｔＬＭＭドメイン内にはモバイルノードへの複数のルートが存在することになり、これによって、モバイルノードはポリシ又はルールを使用して、自身あてのフローのルーティングの方向を定めることができるようになる。なお、本明細書では、このフローの方向を定める方法（リダイレクション方法）をフローフィルタリングと呼び、この方法を定めるポリシ又はルールをフィルタと呼ぶことにする。

モバイルノードは、ＮｅｔＬＭＭドメインのＬＭＡにこれらのフィルタを設定することが可能である。各ＬＭＡ内のルーティングキャッシュに基づいて、ＬＭＡは、モバイルノードの複数のエントリをそれぞれ定義済みのフィルタにマッピングする。モバイルノードのフローがＬＭＡに到着すると、ＬＭＡは、モバイルノードに対する特定のフローの転送方法を決定するために、フィルタのチェックを行う。以下、ＮｅｔＬＭＭドメインで、モバイルノードに関するフローフィルタリングが実現される方法について詳細に説明する。

図１に図示されているＮｅｔＬＭＭドメイン１８内にＬＭＡ１３が１つ存在するネットワークにおいて、ＭＮ１０に関するフィルタが存在する。このとき、ＮｅｔＬＭＭドメイン１８にはポリシサーバ（不図示）が存在しており、ＬＭＡ１３は、ＭＮ１０の様々なフィルタに関して、ポリシサーバに問い合わせを行うことが可能である。例えば、ＭＮ１０に向かうフロー（到来フロー）がＬＭＡ１３に到着した場合、ＬＭＡ１３は、そのルーティングキャッシュ内にＭＮ１０に関する複数のエントリを有していることを検出する。この場合、ＬＭＡ１３は、ポリシサーバにクエリを送信して、ＭＮ１０に関する到来フローのフィルタセットを有しているか否かのチェックが行われる。

このとき、ＭＮ１０は、この特定の到来フローに関するフィルタセットをＮｅｔＬＭＭドメイン１８に有しており、これによって、フローは例えばＭＡＧ１１ａを通過して伝送されるようになる。以上のように、ＬＭＡ１３はＭＮ１０の到来するフローをＭＡＧ１１ａに転送し、ＬＭＡ１３は、到来するフローを順次ＭＮ１０に転送する。さらに、ＬＭＡ１３は、ＭＮ１０の将来のフローのフローフィルタリングに使用可能なＭＮ１０のフィルタを検索して、ＬＭＡ１３のルーティングキャッシュに格納することも可能である。さらに、ポリシサーバ及びＬＭＡが同一のエンティティで構成されてもよい。

一方、ＮｅｔＬＭＭドメインが複数のＬＭＡを有している場合には、ＮｅｔＬＭＭドメインにおいて、モバイルノードに関するフローフィルタリングが行われてもよい。複数のＬＭＡが存在するネットワークにおいては、ＬＭＡはＮｅｔＬＭＭドメイン内の他のＬＭＡの存在を把握し、ＮｅｔＬＭＭドメイン内に位置するモバイルノードに関する情報を相互にアップデートし合うことが可能となる。これにより、ＮｅｔＬＭＭドメイン内のＬＭＡは、モバイルノードが複数の接続を有しているか否かを把握することができるようになる。

図３には、各ＭＡＧ１１ａ，１１ｂが、それぞれＮｅｔＬＭＭドメイン１８内のＬＭＡ１３ａ，１３ｂに接続されている状態が図示されている。このとき、ＮｅｔＬＭＭドメイン１８にはポリシサーバが存在しており、ＬＭＡ１３ａ、１３ｂはポリシサーバに対してＭＮ１０に関する様々なフィルタについて問い合わせを行うことが可能である。例えば、ＭＮ１０の到来フローがＬＭＡ１３ａに到達した場合には、ＬＭＡ１３ａは自身のルーティングキャッシュから、ＭＮ１０がＬＭＡ１３ｂとの間に別のアクティブな接続を有していることを検出する。したがって、ＬＭＡ１３ａは、ＭＮ１０が到来フローに関するフィルタセットを有しているか否かをチェックするため、ポリシサーバにクエリを送信する。ここでは、ＭＮ１０が、この特定の到来フローに関するフィルタセットをＮｅｔＬＭＭドメイン１８に有しており、ＬＭＡ１３ａはＭＮ１０の到来フローをＬＭＡ１３ｂにトンネルすることによって、フローはＭＡＧ１１ｂを通過して伝送される。

また、ＬＭＡ１３ｂも、ＬＭＡ１３ａからトンネルを通じてフローを受信すると、ＭＮ１０が到来フローに関するフィルタを有しているか否かをチェックするため、ポリシサーバにクエリを送信する。ここでは、ＬＭＡ１３ｂは、ＭＮ１０のフィルタの中から、フローがＭＡＧ１１ｂを通過して伝送されるようなフィルタを決定する。この結果、ＬＭＡ１３ｂはＭＡＧ１１ｂにフローを転送し、ＭＡＧ１１ｂはＭＮ１０にフローを転送する。さらに、ＬＭＡ１３ａ、１３ｂは、ＭＮ１０の将来のフローのフローフィルタリングに使用可能なＭＮ１０のフィルタを検索して、各ＬＭＡ１３ａ、１３ｂのルーティングキャッシュに格納することも可能である。

また、図３に図示されているネットワークにおいて、各ＭＡＧが、ＮｅｔＬＭＭドメイン１８内の複数のＬＭＡに接続されている場合もあり得る。この場合、ポリシサーバはＮｅｔＬＭＭドメイン１８内に存在しており，ＬＭＡ１３ａ、１３ｂは、ＭＮ１０の様々なフィルタに関してポリシサーバに問い合わせを行うことが可能である。また、ＭＡＧ１１ａがさらにＬＭＡ１３ｂと接続されており、ＭＡＧ１１ｂがさらにＬＭＡ１３ａと接続されているので、ＬＭＡ１３ａ、１３ｂはフローフィルタリングを実現するためにＬＭＡ間にトンネルを確立することなく、ＭＮ１０に関するフローをＭＡＧ１１ａ、１１ｂのどちらかを経由して直接転送できるようになる。これにより、モバイルノードに関するフローをＮｅｔＬＭＭドメイン内で転送する場合のオーバレイネットワークを、ＮｅｔＬＭＭドメインに設けることができるようになる。

上述の実施の形態には、ＬＭＡが、モバイルノードの到来フローを受信した場合にモバイルノードのフィルタを検索するように構成されているものが存在する。このようなＬＭＡに対し、ポリシサーバが、ＮｅｔＬＭＭドメイン１８に存在するモバイルノードのフィルタに関して定期的にアップデートを行うことも可能である。なお、実際に実施する際には、ポリシサーバがＬＭＡに対して、ある一定の間隔でＮｅｔＬＭＭドメインに関する様々なフィルタをマルチキャストしてもよい。これにより、ポリシサーバは、各ＬＭＡに格納されているフィルタを同期させることが可能となる。

ＮｅｔＬＭＭドメイン内において、ＬＭＡがフローフィルタリングを実行する際に使用されるフィルタは、２つのエンティティによって定義可能である。第１のエンティティは、ＮｅｔＬＭＭドメインを管理するＮｅｔＬＭＭサービスプロバイダである。第２のエンティティは、モバイルノードのユーザである。

例えば上述の本発明の第１の実施の形態において、フローフィルタリングに用いられるフィルタがＮｅｔＬＭＭサービスプロバイダによって定義されてもよい。ＮｅｔＬＭＭサービスプロバイダは、フィルタを用いてＮｅｔＬＭＭドメイン内におけるリソースの使用方法を制御する。例えば図１において、ＭＡＧ１１ａが現在過負荷状態にあることをＮｅｔＬＭＭサービスプロバイダが検出した場合、ＮｅｔＬＭＭサービスプロバイダは、ＬＭＡ１３がＭＮ１０の任意のフローをＭＡＧ１１ｂ経由で転送するように指示するフィルタをセットする。これにより、ＮｅｔＬＭＭサービスプロバイダは、ＮｅｔＬＭＭドメイン１８内で負荷バランスを実行することができるようになる。

また、フローフィルタリングに使用されるフィルタは、モバイルノードのユーザによって定義されてもよい。これにより、ユーザは、特定のフローをモバイルノードに転送する方法を自由に選択することが可能となる。例えば、図３に図示されているネットワークにおいて、ＭＮ１０のユーザが、ＭＡＧ１１ａを通じて巨大なビデオファイルをダウンロードし、かつビデオ通話を行っているとする。ＭＮ１０のユーザは、ビデオ通話に遅延を感じた場合、ビデオ通話がＭＡＧ１１ｂを経由して提供されるようにＬＭＡ１３ａ、１３ｂに指示するフィルタをセットする旨を決定する。これにより、ＬＭＡ１３ａ又はＬＭＡ１３ｂは、ＭＮ１０のビデオ通話のフローを受信すると、セットされた各フィルタによって、フローはＭＡＧ１１ｂに転送される。これにより、ユーザは、ＭＮ１０に送信されるフローの転送方法に関して、ＬＭＡに指示することが可能となる。

上述のように、ＮｅｔＬＭＭドメイン１８において、ＮｅｔＬＭＭサービスプロバイダ又はモバイルノードのユーザがフィルタをセットすることが可能である。なお、ＮｅｔＬＭＭドメイン１８において、ＮｅｔＬＭＭサービスプロバイダ及びモバイルノードのユーザの両方によってフィルタがセットされてもよい。

また、本発明で使用されるポリシサーバの導入によって、ＮｅｔＬＭＭドメインにおけるフィルタの格納や適用が可能となる。上述の実施の形態の中には、ＮｅｔＬＭＭドメイン１８にポリシサーバが存在している場合について説明を行ったものもある。上述の例では、このポリシサーバは集中型ポリシサーバと呼べるものであり、このポリシサーバに、ＮｅｔＬＭＭドメイン１８のすべてのフィルタが記録可能である。集中型ポリシサーバを導入することによって、ＮｅｔＬＭＭサービスプロバイダ又はＭＮ１０のユーザは、集中型ポリシサーバにおけるフィルタの作成又は格納のみを行えばよく、これによって、ＮｅｔＬＭＭドメインに位置する複数のＬＭＡをアップデートする場合に比べて、シグナリングが少なくなるという利点が生まれる。さらに、集中型ポリシサーバを導入した場合、複数のＬＭＡ間において同期が取れないという問題はほとんど発生しなくなるという利点がある。

また、ＮｅｔＬＭＭドメインに複数のポリシサーバが存在していてもよい。これによって、ＮｅｔＬＭＭドメインにおいて、フィルタの処理を行う手段を分散させることが可能となる。ここでは、ＮｅｔＬＭＭサービスプロバイダ又はＭＮ１０のユーザにより、ＮｅｔＬＭＭドメイン１８内の各ポリシサーバにおいてフィルタが作成され、アップデートされる。これにより、ポリシサーバに障害が生じた場合であっても、ＮｅｔＬＭＭドメイン１８におけるフローフィルタリングなどのサービスを継続して提供することが可能となる。また、ＮｅｔＬＭＭドメイン１８内の他のポリシサーバが、障害が生じたポリシサーバのバックアップとして機能することも可能である。

また、上述した様々な実施の形態に係る動作を実現するため、ＮｅｔＬＭＭドメインでマルチモードノードが同時接続を実現するための機能（装置）が導入される必要がある。ここでは、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）が、ＮｅｔＬＭＭドメインでマルチモードノードが同時接続を実現するための装置として機能する場合について説明する。

図５には、本発明に係る動作を実現するためのＬＭＡの構成の一例が図示されている。図５に図示されているＬＭＡ１３は、１つ又は複数のネットワークインタフェース５０、キャッシュチェック部５１、ルーティングキャッシュ５２を有している。ネットワークインタフェース５０は、ＬＭＡ１３が任意の通信媒体を通じて別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。当業者に周知の用語を使用すると、ネットワークインタフェース５０は、レイヤ１（物理層）及びレイヤ２（データリンクレイヤ）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルを表している。なお、ＬＭＡ１３は、１つ以上のネットワークインタフェース５０を有することが可能である。

また、ルーティングキャッシュ５２には、ＬＭＡ１３に接続されている任意のマルチモードノードに関するエントリが含まれている。なお、可能であれば、ルーティングキャッシュ５２にマルチモードノードエントリのリストが含まれ、各エントリにはＮｅｔＬＭＭドメインのマルチモードノードにユニークな識別子が含まれていることが望ましい（さらには、マルチモードノードが有する各インタフェースを識別する識別子が含まれていてもよい）。さらに、各エントリには、マルチモードノードと、ＮｅｔＬＭＭドメイン内の１つ又は複数のＭＡＧ又はＬＭＡとの関係が記載されていることが望ましい。シグナル／データパス５４を通じて、ルーティングキャッシュ５２内のエントリがアップデート又は抽出されることで、キャッシュチェック部５１による動作が補助される。

また、本発明ではキャッシュチェック部５１が導入される。このキャッシュチェック部５１は、ＬＭＡ１３が使用するアルゴリズムの機能を表す機能ブロックであり、このアルゴリズムによって、マルチモードノードはＬＭＡ１３との同時接続を実現することが可能となる。なお、キャッシュチェック部５１は、例えばＬＭＡ１３がＮｅｔＬＭＭドメイン１８内のマルチモードノードに関連した登録リクエスト（位置登録メッセージ）を受信した場合をトリガとして、その動作を開始することが可能であるが、このトリガに限定されるものではない。

キャッシュチェック部５１は、位置登録メッセージの処理を行い、マルチモードノードのエントリが既にＮｅｔＬＭＭドメイン１８に存在しているか否か（マルチモードノードが、ＮｅｔＬＭＭドメイン１８で同時接続あるいは順次的な接続（すなわち、ハンドオーバ）を行おうとしているか否か）を判断する処理を実行することが可能である。さらに、キャッシュチェック部５１は、マルチモードノードが、ＮｅｔＬＭＭドメイン１８で同時接続を行おうとしているのか、あるいは順次的な接続（すなわち、ハンドオーバ）を行おうとしているのかをチェックする処理を実行することが可能である。マルチモードノードのエントリがルーティングキャッシュ５２に既に存在している場合には、キャッシュチェック部５１は、例えば上述したような、マルチモードノードがＬＭＡ１３への同時接続を実現するため方法を実行する。なお、キャッシュチェック部５１は、上述した様々な実施の形態における方法のいずれか１つ又は複数を選択的に実行することが可能である。キャッシュチェック部５１は、シグナル／データパス５３を通じて、適切なネットワークインタフェース５０でパケットを受信したり、適切なネットワークインタフェース５０からパケットを送信したりすることが可能である。

また、図６には、本発明に係る動作を実現するためのＭＡＧが有する機能が、機能ブロックによって模式的に表されている。図６に図示されているＭＡＧ１１は、ＮｅｔＬＭＭドメイン１８に接続するマルチモードノードへのパケット転送経路を管理するＬＭＡから、特定のマルチモードノードとの間の接続が有効か否かの問い合わせを受ける問い合わせ受信部１１１、特定のマルチモードノードとの間の接続が有効か否かをチェックする接続チェック部１１２、接続チェック部により判別した、特定のマルチモードノードとの間の接続が有効か否かを示すチェック結果を、問い合わせを行ったＬＭＡに通知する問い合わせ結果通知部１１３を有する。なお、特定のマルチモードノードが有する特定のインタフェースに関して、接続が有効か否かの問い合わせを受けて接続をチェックし、そのチェック結果を返答するように構成されていてもよい。

＜第４の実施の形態＞
次に、本発明の第４の実施の形態について説明する。

上述の本発明の第３の実施の形態に記載されているポリシサーバは、非特許文献４に記載されているようなローカルサーバ（ＬＳ：Local Server）の機能を有していてもよい。この場合、ポリシサーバは、非特許文献４に説明されているように、例えばＭＡＧへのモバイルノードのプロファイルの送信などのような必要なシグナリングを実行することが可能となる。

また、ＮｅｔＬＭＭドメイン１８にＰＭＩＰ（プロキシモバイルＩＰ）が実装されている場合には、ＬＭＡが、モバイルノードとの接続が有効か否かを問い合わせるメッセージを送信することで、モバイルノードの接続がまだアクティブか否かを判断する方法（以下、クエリ方法と呼ぶ）を用いることが可能となる。

図７には、本発明の第４の実施の形態において、ＮｅｔＬＭＭにＰＭＩＰが実装されている場合のクエリ方法の使用を説明するためのシーケンスチャートが図示されている。なお、ここでは、基本的に図１に図示されているネットワークトポロジを前提とし、さらにＮｅｔＬＭＭドメイン１８にＰＭＩＰが実装されており、ローカルサーバ（ＬＳ）が存在しているとする。

図７において、ステップＳ６００において、ＭＮ１０の第１インタフェース（ＩＦ１）がＭＡＧ１１ａとアクティブな状態で接続しており、ＬＭＡ１３は、ＭＡＧ１１ａを経由するＭＮ１０へのルーティングエントリを既に有しているとする。ここで、ステップＳ６０１において、ＭＮ１０の第２インタフェース（ＩＦ２）が、ＭＡＧ１１ｂにＭＮの識別子（ＭＮのＩＤ）を含む接続メッセージ（Ａｓｓｏｃ−ＩＦ２）を送信することで、ＭＡＧ１１ｂと接続しようとしている。

ＭＡＧ１１ｂはＭＮのＩＤを受信すると、ステップＳ６０２において、ＭＮ１０のポリシプロファイルを検索するためにクエリプロファイルメッセージ（Ｑｕｅｒｙ−Ｐｒｏｆｉｌｅ）を送信し、ＬＳ６０に問い合わせを行う（ステップＳ６０２）。ＬＳ６０は、ＭＮのＩＤに基づいてポリシ情報を検索し、関連するＭＮ１０のポリシプロファイルを探す。そして、ＭＮ１０のポリシプロファイルが発見されると、ステップＳ６０３において、ＬＳ６０はＭＡＧ１１ｂに対して、ＭＮ１０のプロファイル（ポリシプロファイル）を含むクエリプロファイルレスポンスメッセージ（Ｑｕｅｒｙ−Ｐｒｏｆｉｌｅ−Ｒｅｓ）を返信する。なお、ＭＮ１０のポリシプロファイルには、例えばＭＮ１０に割り当てられるプレフィックス（ＭＮのプレフィックス）が含まれるが、これに限定されるものではない。

ＭＡＧ１１ｂがＭＮ１０のポリシプロファイルを受信すると、ＭＡＧ１１ｂはＭＮ１０のモビリティ管理を行うことが可能となる。そして、ＭＡＧ１１ｂは、ＭＮ１０においてモビリティ管理プロトコルが作動しないようにするため、ステップＳ６０４において、ＭＮ１０のプレフィックスを含むルータアドバタイズメントメッセージ（ＲＡ）を送信する。この処理によって、ＭＮ１０は、ＭＮ１０が依然として同一ネットワークドメイン内に存在していると判断し、ＭＮ１０においてモビリティ管理プロトコルが実行されないようになる。

同時に、ＭＡＧ１１ｂは、ステップＳ６０５において、プロキシバインディングアップデートメッセージ（ＰＢＵ）をＬＭＡ１３に送信することによって、ＭＮ１０が現在ＭＡＧ１１ｂに接続されている旨をＬＭＡ１３に通知する。なお、このＰＢＵメッセージには、例えばＭＮのＩＤ及びＭＡＧ１１ｂの気付アドレス（ＭＡＧ．ＣｏＡ）などが含まれるが、これらに限定されるものではない。

ＬＭＡ１３がＭＡＧ１１ｂからＰＢＵメッセージを受信すると、ステップＳ６０６において、ＬＭＡ１３はルーティングキャッシュ５２をチェックして、ＭＮ１０がＮｅｔＬＭＭドメイン内にアクティブな接続を有しているか否かの確認を行う。ここで、ＬＭＡ１３は、ＭＮ１０がＭＡＧ１１ａを経由するルーティングエントリを有していることに気付く。

この場合、ＬＭＡ１３は、ステップＳ２３において、ＭＮ１０がまだＭＡＧ１１ａに接続されているか否かを問い合わせるハートビートメッセージ（ＨｅａｒｔＢｅａｔ）をＭＡＧ１１ａに送信する。なお、このハートビートメッセージには、例えばＭＮ１０のＭＮのＩＤが含まれるが、これに限定されるものではない。

ＭＡＧ１１ａは、ＭＮ１０が依然としてＭＡＧ１１ａ自身に接続されていることを確認すると、ステップＳ２４において、ＬＭＡ１３にハートビートレスポンスメッセージ（ＨｅａｒｔＢｅａｔＲｅｓ）を返信する。なお、このハートビートレスポンスメッセージにおいても、例えばＭＮ１０のＭＮのＩＤが含まれるが、これに限定されるものではない。

ハートビートレスポンスメッセージを受信すると、ＬＭＡ１３は、ＭＮ１０がＮｅｔＬＭＭドメインに同時接続を行おうとしていることを把握する。したがって、ＬＭＡ１３は、ＭＮ１０に関して第２のルーティングエントリ（ＭＡＧ１１ｂ経由）をルーティングキャッシュ５２内に作成する。そして、ＬＭＡ１３は、ステップＳ６０７において、ＭＮ１０のバインディングが成功した旨を通知するプロキシバインディングアクノレッジメント（ＰＢＡ：Proxy Binding Acknowledgement）メッセージをＭＡＧ１１ｂに送信する。

なお、図７に図示されている動作において、非特許文献２に開示されているバインディングリフレッシュ方法を利用して、ハートビートメッセージの交換（問い合わせ／応答）が行われてもよい。

例えば、ステップＳ６０６において、ＬＭＡ１３は、ＭＮ１０がＭＡＧ１１ａ経由のルーティングエントリを既に持っていることを見つけると、プロキシバインディングリフレッシュリクエスト（プロキシＢＲＲ：Proxy Binding Refresh Request）メッセージをＭＡＧ１１ａに送信する。プロキシＢＲＲメッセージにはＭＮ１０のＭＮのＩＤが含まれており、このプロキシＢＲＲメッセージによって、ＬＭＡ１３がＭＮ１０のルーティングステートのアップデートを望んでいる旨がＭＡＧ１１ａに通知される。

ＭＡＧ１１ａは、ＭＮ１０がまだＭＡＧ１１ａに接続されていることを確認すると、ＰＢＵメッセージによって応答を行い、ＬＭＡ１３におけるＭＮ１０のルーティングステートのアップデートを行う。ＰＭＩＰプロトコルはモビリティ管理にＭＩＰｖ６シグナリングを再利用するので、ＮｅｔＬＭＭドメイン内のＭＡＧは、ほとんど変更されることなくバインディングリフレッシュ方法を利用できるという利点がある。

また、図７のステップＳ６０１において、ＭＮ１０は、ＭＡＧ１１ｂへの接続メッセージにインタフェース識別子（ＩＦのＩＤ）を挿入してもよい。ＭＮ１０が使用するＩＦのＩＤを用いることで、ＭＮ１０の様々なインタフェースの識別が可能となる。この場合、ステップＳ６０５でＭＡＧ１１ｂからＬＭＡ１３に送信されるＰＢＵメッセージには、さらにＭＮ１０のＩＦのＩＤが挿入されることになる。これにより、ＬＭＡ１３は、ルーティングキャッシュ５２をチェックする際に（ステップＳ６０６）、ＭＮ１０がＮｅｔＬＭＭドメイン１８において同時接続を実現しようとしているか否かを判断するための付加情報として、ＩＦのＩＤを用いることが可能となる。

なお、この方法を用いた場合、ＩＦのＩＤのチェックによって事実上ハートビートメッセージの交換と同様の効果が実現されるので、ハートビートメッセージの交換をオプションの動作としてもよい。すなわち、ＩＦのＩＤを使用することで、ＬＮＡ１３とＭＡＧ１１ａとの間のシグナリングメッセージの交換による処理負荷やネットワーク負荷を低減させることが可能となる。

また、ＩＦのＩＤがＭＡＧ経由でＬＳに送信されてもよい。例えば、図７のステップＳ６０２において、ＭＡＧ１１ｂからＬＳ６０に送信されるクエリプロファイルメッセージに、ＭＮ１０のＩＦのＩＤが挿入されてもよい。ＬＳ６０がＮｅｔＬＭＭドメイン１８内のポリシサーバと同様の機能を有することが可能であれば、ＬＳ６０は、ＭＮ１０のＩＦのＩＤを用いてＭＮ１０の課金処理を行うことができるようになる。このような課金処理においては、例えば、ＭＮ１０の所有者（サービス加入者）に対する請求金額の計算が行われる。

また、ＮｅｔＬＭＭドメイン１８に複数のＬＭＡが存在する場合には、ＬＳ６０は、モバイルノードのバインディングステートに係るバインディングを行うために、どのＬＭＡと通信を行うべきかについてＭＡＧに応答を行うことも可能である。例えば、図７のステップＳ６０３において、ＬＳ６０からＭＡＧ１１ｂに送信されるクエリプロファイルレスポンスメッセージに、バインディングを行う対象となるＬＭＡ１３の識別情報が更に含まれるようにしてもよい。これによって、ＭＡＧ１１ｂは、ＭＮ１０のモビリティを取り扱う際に、特定のＬＭＡ１３を探す必要がある旨を把握することが可能となる。

また、ＬＳ６０は、ＮｅｔＬＭＭドメイン１８におけるＭＮ１０のトラフィックフローのフィルタリングを補助するフィルタポリシを格納してもよい。このようなフィルタポリシはモバイルノードによって構成され、情報交換によってＬＳ６０に格納される。モバイルノードは、例えばＭＡＧを経由してＬＳ６０にフィルタポリシを送信することが可能であり、また、フィルタポリシを直接ＬＳ６０に送信することも可能である。

フィルタポリシによって規定されるフィルタリングルールを把握すると、ＬＳ６０は、ＭＡＧに対して、ＮｅｔＬＭＭドメイン１８内におけるＭＮ１０のルーティング設定に関する通知を行うことが可能となる。例えば、図７のステップＳ６０３において、ＬＳ６０からＭＡＧ１１ｂに送信されるクエリプロファイルレスポンスメッセージに、さらに、ＭＮ１０のフィルタポリシが含まれてもよい。これによって、ＭＡＧ１１ｂは、例えばステップＳ６０５において送信されるＰＢＵメッセージにＭＮ１０のフィルタルールを含ませることで、ＭＮ１０のフィルタルールをＬＭＡ１３にセットすることが可能となる。なお、この場合にＭＡＧ１１ｂで行われるフィルタルール転送方法として、ＩＥＴＦのＭｏｎａｍｉ６ワーキンググループで説明されている方法を本発明の通知方法を用いて拡張して用いることが可能である。

また、ＬＳ６０は、ＮｅｔＬＭＭドメイン１８内のモバイルノードの接続設定（以下、接続ポリシと呼ぶ）を保持することも可能である。モバイルノードの接続ポリシを用いることで、ＮｅｔＬＭＭドメイン１８のネットワークエンティティは、モバイルノードがＮｅｔＬＭＭドメイン１８内に存在している間に実現可能な接続のタイプを把握することが可能となる。

例えば、モバイルノードの接続ポリシによって、ＭＮ１０がインタフェースを１つのみ有するモバイルノードである旨が示されているとする。このＭＮ１０の接続ポリシによれば、どのような場合であってもＮｅｔＬＭＭドメイン１８においてＭＮ１０が単一のアクティブな接続しか実現できないことが示されている。ＬＳ６０は、このようなＭＮ１０の接続ポリシをＬＭＡ１３に通知することが可能である。例えば、ＭＮ１０が単一のインタフェースしか有さない場合には、ＬＭＡ１３は、ＭＮ１０のルーティングステートの処理を行う際に、ＭＮ１０に対しては上述の各実施の形態で説明されているようなクエリ方法を行う必要がないことを把握できる。この場合には、ＬＭＡ１３は、ＭＮ１０がＮｅｔＬＭＭドメイン１８内を移動していること（ハンドオーバを行っていること）を把握し、受信した各アップデートに関して、ＭＮ１０の既存のルーティングエントリを上書きする処理を行う。

また、ＭＮ１０の接続ポリシによって、ＭＮ１０がＮｅｔＬＭＭドメイン１８内で同時接続可能である旨が示されているとする。このような場合でも、ＭＮ１０が、ＮｅｔＬＭＭドメイン１８内では複数のインタフェースを接続しないことを決定する可能性がある。こうした動作を行う理由の１つとして、ＭＮ１０のＷＬＡＮインタフェースが近隣に無料のＷＬＡＮサービスを検出した場合が挙げられる。このとき、加入者は、ＮｅｔＬＭＭドメイン１８におけるＷＬＡＮサービスに接続して対価を支払うより、無料で使用可能なＷＬＡＮホットスポットのアクセスポイントにＭＮ１０のＷＬＡＮインタフェースを接続させたいと思う可能性がある。したがって、この場合には、ＭＮ１０が現在同時接続を行う必要がない旨をＮｅｔＬＭＭドメイン１８のネットワークエンティティが把握できるように、ＭＮ１０の接続ポリシがアップデートされる必要がある。このような接続ポリシのアップデートは、モバイルノードによって実行可能である。例えば、ＭＮ１０が同時接続を行わない場合には、ＬＭＡ１３は、ＭＮ１０のルーティングステートの処理を行う際に、ＭＮ１０に対しては上述の各実施の形態で説明されているようなクエリ方法を行う必要がないことを把握できる。このような接続ポリシのアップデートは、ＭＮ１０の接続ポリシの変化に応じて任意のタイミングで（若しくは登録情報の更新時に）行われることが望ましい。例えば、初期接続時であれば図７のステップＳ６００の処理中に接続ポリシのアップデートを行い、接続中であれば同様のメッセージを任意のタイミングで送信し、以降の同時接続の要／不要（ＮｅｔＬＭＭドメイン１８側からすればハートビートメッセージの交換の要／不要）を通知する。

また、ＭＮ１０がＮｅｔＬＭＭドメイン１８において複数のインタフェースの同時接続を行わないようにする別の理由として、ＭＮ１０がコレスポンデントノードとの間で経路最適化セッションを有することを所望する場合が挙げられる。例えば、ＭＮ１０が２つのインタフェースを有しており、一方のインタフェースが、ＮｅｔＬＭＭドメイン１８に接続されているセルラインタフェースであり、他方のインタフェースが、その近隣に存在するＮｅｔＬＭＭドメイン１８内のアクセスポイントを検出するＷＬＡＮインタフェースであるとする。

このとき、ＭＮ１０は、コレスポンデントノードとの間に最適化経路セッションを確立するため、ＷＬＡＮインタフェースの使用を選択することが可能である。これは、例えば、ＭＮ１０がコレスポンデントノードからのパケット又はコレスポンデントノードへのパケットをＮｅｔＬＭＭドメイン１８内で伝送させたくない場合に有効であり、ＭＮ１０は、コレスポンデントノードとの間で、非特許文献２に記載されている経路最適化を行う可能性がある。

このような場合には、例えば図７のステップＳ６０１において（若しくは経路最適化セッションを確立するに先立ち任意のタイミングで）、ＭＮ１０からＭＡＧ１１ｂに送信される接続メッセージに、さらにフラグ（ノマディックフラグ）が含まれるようにすればよい。このノマディックフラグによって、ＷＬＡＮインタフェース上においてＰＭＩＰサービスは不要である旨がＭＮ１０からＭＡＧ１１ｂに通知可能となる。

ＭＡＧ１１ｂは、接続メッセージにノマディックフラグが含まれていることを見つけると、ＭＮのプレフィックスではなく、ＭＡＧ１１ｂのローカルプレフィックスをＭＮ１０に通知する（ステップＳ６０４）。これによって、ＭＮ１０はそのＷＬＡＮインタフェース上に、ＮｅｔＬＭＭドメイン１８に属さない気付アドレスを構成できるようになり、この気付アドレスを用いて、ＭＮ１０は、コレスポンデントノードとの間で経路最適化セッションをセットアップできるようになる。なお、このような経路最適化セッションは通常のセッションと必ずしも排他的ではなく、混在させて使用することも可能である。

また、ＭＡＧ１１ｂは、ＭＮ１０のＷＬＡＮインタフェースがＭＡＧ１１ｂに接続されているがノマディックモードである旨をＬＳ６０に通知してもよい。これにより、ＬＳ６０は、ＭＮ１０の接続ポリシをアップデートし、ＭＮ１０のＮｅｔＬＭＭドメイン１８における接続状態（接続ポリシ）をＬＭＡ１３に通知することが可能となる。このアップデートによって、ＬＭＡ１３は、上述の各実施の形態で説明されているようなクエリ方法がＭＮ１０には不要である旨を把握することが可能となる。

また、ＭＡＧ１１ｂは、ＭＮ１０の接続状態（接続ポリシ）に関してＬＭＡ１３にアップデートを行うことが可能である。このアップデートは、ＭＮ１０のＷＬＡＮインタフェースがＭＡＧ１１ｂに接続されているがノマディックモードである旨を示すものである。これにより、ＬＭＡ１３は、ＭＮ１０のルーティングエントリにノマディックフラグを追加し、ルーティングエントリに存在するノマディックフラグによって、ＬＭＡ１３は、上述の各実施の形態で説明されているようなクエリ方法がＭＮ１０には不要である旨を把握することが可能となる。

なお、本発明におけるモバイルノードが接続状態をアップデートする方法は、例えば、特許文献３で説明されている方法とは異なっていることは明らかである。特許文献３で説明されている従来の技術では、ネットワーク内におけるモバイルノードの接続状態が、ネットワークオペレータによって定義、管理されている。すなわち、ネットワーク内のエンティティによって処理が行われるので、モバイルノードは接続ポリシをアップデートする必要がないことを意味している。一方、本発明における接続状態のアップデートでは、モバイルノードがその設定情報（preference）に基づいて接続ポリシを修正することが可能である。

また、さらに、図１において、ＬＭＡ１３がＭＮ１０のホームエージェントとしての機能も有するシステムが考えられる。このようなシステムでは、ＭＮ１０がＮｅｔＬＭＭドメイン１８の外部に移動すると、ＬＭＡ１３によってＭＮ１０のモビリティバインディング処理（移動管理）が行われる。

ここで、ＭＮ１０は、パス１４を経由してＭＡＧ１１ａと第１のインタフェースを接続し、通信にホームアドレス（ＨｏＡ）を使用し、同時に、ＭＮ１０はパス１５を経由してＭＡＧ１１ｂと第２のインタフェースを接続し、通信にホーム気付アドレス（ＨＣｏＡ：Home Care-of address）を使用しているとする。ＭＮ１０の第２のインタフェースがＮｅｔＬＭＭドメイン１８から外部ネットワーク（foreign network）に移動すると、第２のインタフェースは気付アドレス（ＣｏＡ）を取得する。したがって、ＭＮ１０は、ＣｏＡをＨｏＡにバインドさせるバインディングアップデート（ＢＵ）メッセージをＬＭＡ１３に送信する。

ＬＭＡ１３は、ＭＮ１０からＢＵメッセージを受信すると、そのルーティングキャッシュ５２をチェックして、ＭＮ１０がＮｅｔＬＭＭドメイン１８にアクティブな接続（接続エントリ）を有しているか否かを確認する。この場合、ＬＭＡ１３は、ＭＮ１０がＭＡＧ１１ａを経由するルーティングエントリを有していることに気付く。そして、ＭＮ１０が依然としてＭＡＧ１１ａに接続されているかどうかの確認のために、ＬＭＡ１３はハートビートメッセージの交換を利用してＭＡＧ１１ａにクエリを行う。このハートビートメッセージの交換によって、ＬＭＡ１３は、ＮｅｔＬＭＭドメイン１８におけるＭＮ１０の第１のインタフェースに関するルーティングステートを上書きしないようにすることが可能となる。したがって、ＭＮ１０は、ＮｅｔＬＭＭドメイン１８及び外部ネットワークの両方への同時接続を実現できるようになる。

また、ＬＭＡ１３がＭＮ１０のホームエージェントとしての機能も有するシステムにおいて、ＭＮ１０のインタフェースの１つがＮｅｔＬＭＭドメイン１８に戻った場合には、ハートビートメッセージ交換を利用してＬＭＡ１３がＭＮ１０のルーティングエントリを消去しないようにすることも可能である。例えば、ＭＮ１０が、第１のインタフェースを通じてＮｅｔＬＭＭドメイン１８に接続されており、第１のインタフェースによる通信にＨｏＡが使用されているとする。同時に、ＭＮ１０は、第２のインタフェースを通じて外部ネットワークに接続されており、第２のインタフェースもよる通信にＣｏＡが使用されているといる。また、ＬＭＡ１３では、パケット転送のためにＣｏＡがＨｏＡにバインドされている。

ここで、ＭＮ１０の第２のインタフェースがＮｅｔＬＭＭドメイン１８に戻ってＭＡＧ１１ｂと接続しようとする場合、ＭＮ１０はＢＵメッセージを送信して、ＬＭＡ１３におけるＣｏＡのバインディングの登録を削除する。ＢＵメッセージは、ＭＡＧ１１ｂを経由してＬＭＡ１３に発送される。

ＬＭＡ１３は、ＢＵメッセージを受信すると、非特許文献４に開示されている方法によって、ＭＮ１０のルーティングエントリすべてを消去して、ＭＡＧ１１ｂを経由するＭＮ１０の一時的なルーティングエントリを生成する。これによって、ＭＮ１０はＭＡＧ１１ａを経由するＮｅｔＬＭＭドメイン１８へのアクティブな接続を失うことになる。しかしながら、ＬＭＡ１３は、本発明に記載されているハートビートメッセージの交換によるクエリ方法を使用してＭＡＧ１１ａに問い合わせを行うことで、ＭＮ１０の第１のインタフェースが依然としてアクティブであることを把握できる。

その結果、ＬＭＡ１３では、単にＭＮ１０のＣｏＡバインディングが削除され、ＭＡＧ１１ａを経由するＭＮ１０のルーティングステートは維持される。これにより、ＭＮ１０のインタフェースの１つがＮｅｔＬＭＭドメイン１８に戻った場合に、ＭＮ１０がＮｅｔＬＭＭドメイン１８とのアクティブな接続（同時接続）を失ってしまうという問題が解決される。

また、さらに、図１において、ＭＮ１０のホームエージェントが存在するシステムが考えられる。ホームエージェントは、ＭＮ１０がＮｅｔＬＭＭドメイン１８の外部に移動した場合に、ＭＮ１０のモビリティバインディング処理）を扱う機能（移動管理機能）を有している。

ここで、ＭＮ１０は、パス１４を経由してＭＡＧ１１ａと第１のインタフェースを接続し、通信にホームアドレス（ＨｏＡ）を使用し、同時に、ＭＮ１０はパス１５を経由してＭＡＧ１１ｂと第２のインタフェースを接続し、通信に気付アドレス（ＣｏＡ：Home Care-of address）を使用しているとする。また、ホームエージェントでは、パケット転送のためにＣｏＡがＨｏＡにバインドされている。

このシステムにおいて、ＬＭＡ１３は、ＮｅｔＬＭＭドメイン１８内のホームエージェントの上位階層に存在する。すなわち、これは、グローバルなインターネットからのパケットは、ＮｅｔＬＭＭドメイン１８に届くと、まずＬＭＡ１３に到達して処理されることを意味する。

パケットがＮｅｔＬＭＭドメイン１８外部のモバイルノードの気付アドレスをあて先とする場合には、ＬＭＡ１３は、パケットをホームエージェントに転送して、モバイルノードへのパケットのルーティングを行わせる。なお、これは、ＬＭＡ１３とＭＮ１０のホームエージェントとの間にバインディングが存在していることを意味する。

例えば、ＭＮ１０がホームエージェントにモビリティバインディングを生成した場合には、ホームエージェントは、ＭＮ１０がホームエージェントへの接続を有している旨（すなわち、ホームエージェントを経由するパケット転送に係るバインディングが登録された旨）をＬＭＡ１３に通知する。このような動作によって、ホームエージェントは、ＮｅｔＬＭＭドメイン１８のＭＡＧに似た機能を有するようになる。ＬＭＡ１３はホームエージェントから送信されてきた情報を確認し、ホームエージェント経由で到達可能なＭＮ１０のルーティングエントリを構成する。そして、フィルタルールを使用することで、ＬＭＡ１３は、どのパケットがホームエージェント経由でＭＮ１０に転送されるべきかを把握する。

また、ＭＮ１０の第２のインタフェースがＮｅｔＬＭＭドメイン１８に戻ってＭＡＧ１１ｂと接続しようとする場合には、ＭＮ１０はＢＵを送信して、ホームエージェントにおけるＣｏＡのバインディングの登録を削除する。ＭＡＧ１１ｂを経由するＮｅｔＬＭＭドメイン１８内のバインディング処理を迅速に行うため、ＭＮ１０は、ＢＵメッセージにＭＡＧ１１ｂの識別情報を追加することも可能である。これによって、ホームエージェントは、ＭＮ１０がＭＡＧ１１ｂ経由でＮｅｔＬＭＭドメイン１８に接続しようとしている旨を把握することが可能となり、ＭＮ１０が接続しようとしている旨をＬＭＡ１３に通知することが可能となる。

ＬＭＡ１３は、ハートビートメッセージ交換を用いて、ＭＮ１０がアクティブか否かをＭＡＧ１１ｂに問い合わせる。モバイルノードのルーティングエントリを確立するためにＬＭＡ１３がＭＡＧに問い合わせを行う動作は、ＭＡＧが過負荷状態のときに有効である。このような場合、ＭＡＧは、ＰＢＵメッセージの送信を遅らせることで、モバイルノードがＮｅｔＬＭＭドメインに接続する際に要する時間を長引かせることが可能となる。

また、本発明に係るシステムにおいて、モバイルＩＰｖ４（ＭＩＰｖ４）プロトコルが実装されていてもよい。ＭＩＰｖ４プロトコルに記載されているフォーリンエージェント（ＦＡ：Foreign Agent）は、基本的に、本発明に記載されているＭＡＧと同様の機能を有している。したがって、ＭＡＧによって行われる動作をＦＡによって行われる動作として読み換えることで、本発明に係る同時接続の実現方法が、ＭＩＰｖ４が実装されているシステムにおいても適用可能であることが分かる。例えば、ＭＩＰｖ４のモバイルノードは、２つのフォーリンエージェント（ＦＡ１及びＦＡ２）に接続されていてもよい。各フォーリンエージェントは、それぞれ独立したバインディングアップデートメッセージをモバイルノードのホームエージェントに送信する。ホームエージェントは、本発明の各実施の形態に記載されている方法を用いることで、モバイルノードが接続ポイントの変更を行っている状況と、モバイルノードが同時に２つの接続ポイントに接続されている状況とを区別できるようになる。

また、本明細書では、ハートビートメッセージの交換は各モバイルノードの確認のために個別に行っているが、同時期に確認が必要なモバイルノードのハートビートメッセージの送信を一括に行うことや、ＬＭＡが必要と判断する任意のタイミングにおいて一部又は全部のルーティングエントリに対してハートビートメッセージの交換を行うことができる。これにより、例えば、アクティブでない接続エントリに関してはあらかじめそのエントリを削除（無効化）しておくことができる。

次に、本発明に係る動作を実現するためのＭＮの機能について説明する。図８には、本発明に係る動作を実現するためのＭＮが有する機能の一例を表す機能ブロック図が図示されている。図８に図示されているＭＮ１０は、複数の無線通信インタフェース１２０、ＮｅｔＬＭＭドメイン１８に複数の無線通信インタフェース１２０を同時に接続する必要があるか否かを判断する同時接続判断部１２１、同時接続判断部１２１による判断結果（複数のインタフェースの同時接続の必要性）を接続ポリシとしてＮｅｔＬＭＭドメイン１８に通知する接続ポリシ通知部１２２、ＭＮ１０の通信相手であるコレスポンデントノードとの間の通信に最適化経路を利用するか否かを判断し、その判断結果を同時接続の必要性を判断する条件として同時接続判断部１２１に提供する経路最適化判断部１２３、複数の無線通信インタフェース１２０のいずれかによって、ＮｅｔＬＭＭドメイン１８のＭＡＧと接続する際に、ＭＮ１０自身のホームエージェントに対して、そのＭＡＧの識別情報を含む位置情報更新メッセージ（例えば、ＢＵメッセージなどを利用してもよい）を送信することによって、ホームエージェントからＮｅｔＬＭＭドメイン１８のＬＭＡに対して、ＭＮ１０がＮｅｔＬＭＭドメイン１８に接続する旨が通知できるようにする接続通知部１２４を有している。

なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、本発明に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明白である。

例えば、複数のＬＭＡが、それぞれ異なるＮｅｔＬＭＭドメインに存在しているネットワークに対して本発明を適用することが可能である。なお、この場合、複数のＬＭＡが相互に協働して動作することが望ましい。

さらに、本発明では、ＬＭＡが複数のＮｅｔＬＭＭプレフィックスを管理し、マルチモードノードが異なるＮｅｔＬＭＭプレフィックスを使用して、自身の各インタフェース用のＮｅｔＬＭＭアドレスを構成してもよい。なお、この場合、ＬＭＡは、マルチモードノードがＮｅｔＬＭＭドメインで同時接続を行っているか否かを把握するため、ＭＡＧのＩＤに加えて、マルチモードノードによって使用されるプレフィックスをチェックする必要がある。

また、モバイルノードがＮｅｔＬＭＭドメイン内でモバイルルータとして機能する場合においても、本発明を適用することが可能である。

なお、本明細書では、局所化されたモビリティ管理プロトコルの一例として、ＮｅｔＬＭＭのうちのＬＭＡをドメイン管理装置、ＭＡＧをエッジ装置としてＮｅｔＬＭＭドメイン（モビリティ管理ドメイン）を構成する場合について説明を行っているが、ローカルホームエージェントをドメイン管理装置、ＰＭＡ（Proxy Mobile Agent）をエッジ装置としてＮｅｔＬＭＭドメインを構成する（ProxyMIPとしても知られている）場合についても、それぞれの詳細なメッセージ交換手順、パラメータを変更するのみで本発明を適用することが可能であり、また、モバイルＩＰｖ４のフォーリンエージェントをエッジ装置として構成し本発明を適用することも可能であることは明らかである。

なお、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。

さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、通信ネットワークドメイン（特に、ＮｅｔＬＭＭドメイン）において、複数のインタフェースを有するノードが、その複数のインタフェースの接続を同時に行えるようにするという効果を有しており、ＩＰネットワークなどのパケット交換型データ通信ネットワークにおける技術、複数のインタフェースを有するノードによる通信技術、ＮｅｔＬＭＭプロトコルなどの局所モビリティ管理プロトコルを使用した通信技術などに適用可能である。

本発明の第１の実施の形態におけるネットワークトポロジ（ネットワークの接続形態）の一例を示す図 本発明の第１の実施の形態におけるメッセージ交換の一例を示すシーケンスチャート 本発明の第２の実施の形態におけるネットワークトポロジ（ネットワークの接続形態）の一例を示す図 本発明の第２の実施の形態におけるメッセージ交換の一例を示すシーケンスチャート 本発明に係る動作を実現するためのＬＭＡの構成の一例を示す図 本発明に係る動作を実現するためのＭＡＧが有する機能の一例を表す機能ブロック図 本発明の第４の実施の形態において、ＮｅｔＬＭＭにＰＭＩＰが実装されている場合のクエリ方法の使用を説明するためのシーケンスチャート 本発明に係る動作を実現するためのＭＮが有する機能の一例を表す機能ブロック図

Claims (20)

1. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
   前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
   前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記移動端末が現在接続している前記エッジ装置とを関連付ける関連情報を保持するドメイン管理装置とを、
   有し、
   前記ドメイン管理装置が、前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記ドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べ、前記移動端末の関連情報を保持している場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置に対して、前記移動端末との間の接続が有効か否かの問い合わせを行って、前記移動端末との間の接続が有効な場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を保持する一方、前記移動端末との間の接続が有効でない場合には、前記移動端末と第２のエッジ装置を関連付ける関連情報を消去するとともに、前記移動端末と前記第１のエッジ装置とを関連付ける関連情報を保持するように構成されている通信システム。
2. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
   前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
   前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記インタフェースが現在接続している前記エッジ装置とを関連付ける関連情報を保持するドメイン管理装置とを、
   有し、
   前記ドメイン管理装置が、前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記ドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べ、前記第１のインタフェースと、前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している場合には、前記第１のインタフェースと前記第２のエッジ装置とを関連付ける関連情報を消去するとともに、前記第１のインタフェースと前記第１のエッジ装置との関連情報を保持し、前記第１のインタフェースとは異なる第２のインタフェースと、前記第２のエッジ装置とを関連付ける関連情報を保持している場合には、前記第２のインタフェースと前記第２のエッジ装置とを関連付ける関連情報に加えて、前記第１のインタフェースと前記第１のエッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として保持するように構成されている通信システム。
3. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
   前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
   前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記移動端末が現在接続している前記エッジ装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
   有し、
   前記複数のドメイン管理装置のうちの１つが、前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信し、前記ドメイン管理装置自身が前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持していない場合、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かの問い合わせを行い、他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記移動端末と前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を保持するように構成されている通信システム。
4. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
   前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
   前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記インタフェースが現在接続している前記エッジ装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
   有し、
   前記複数のドメイン管理装置のうちの１つが、前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信し、前記ドメイン管理装置自身が前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する前記関連情報を保持していない場合、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する関連情報を保持しているか否かの問い合わせを行い、他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記第１のインタフェースとは異なる第２のインタフェースと前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記第１のインタフェースと前記第１エッジ装置とを関連付ける関連情報に加えて、前記第２のインタフェースと前記第２エッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として保持するように構成されている通信システム。
5. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
   前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
   前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記移動端末が現在接続している前記エッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
   有し、
   前記複数のドメイン管理装置のうちの１つである第１のドメイン管理装置が、前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記第１のドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べ、前記移動端末の関連情報を保持していない場合には、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記移動端末の関連情報を保持している場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して前記移動端末との間の接続が有効か否かの問い合わせを行い、前記問い合わせの結果において前記移動端末との間の接続が有効な場合には、前記第１のドメイン管理装置は、前記移動端末と前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報と、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置を関連付ける関連情報とを保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記問い合わせの結果において前記移動端末との間の接続が有効ではない場合には、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を消去するとともに、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持し、さらに、他の前記ドメイン管理装置においても同様の更新処理を行わせるように構成されている通信システム。
6. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システムであって、
   前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が接続可能な複数のエッジ装置と、
   前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記インタフェースが現在接続している前記エッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持する複数のドメイン管理装置とを、
   有し、
   前記複数のドメイン管理装置のうちの１つである第１のドメイン管理装置が、前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信した場合、前記第１のドメイン管理装置自身が保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する前記関連情報を保持しているか否かを調べ、前記第１のインタフェースに関する関連情報を保持していない場合には、前記第１インタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記第１のインタフェースに関する関連情報を保持している場合には、前記第１のインタフェースに関する関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して、前記移動端末の第１のインタフェースとの間の接続が有効か否かの問い合わせを行い、前記問い合わせの結果において前記第１インタフェースとの間の接続が有効な場合には、前記第１のドメイン管理装置は、前記第１のインタフェースと前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報に加えて、前記第２のインタフェースと第２エッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を同一の前記移動端末の関連情報として保持するとともに、他の前記ドメイン管理装置においても同様の更新処理を行わせる一方、前記問い合わせの結果において前記第１のインタフェースとの間の接続が有効ではない場合には、前記第２のインタフェースと第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を消去するとともに、前記第１のインタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を保持し、さらに、他の前記ドメイン管理装置においても同様の更新処理を行わせるように構成されている通信システム。
7. 前記アクセスネットワーク内を伝送する前記移動端末のフローフィルタリングに係るフィルタの管理を行う１つ又は複数のポリシサーバを有する請求項１に記載の通信システム。
8. 前記ドメイン管理装置は、前記移動端末のポリシを参照して、前記関連情報の管理を行うように構成されている請求項１に記載の通信システム。
9. 前記移動端末が単一のインタフェースを使用している場合には、前記ドメイン管理装置は、前記移動端末が複数のインタフェースの同時接続を行おうとしているか否かの問い合わせを行わないように構成されている請求項７に記載の通信システム。
10. 前記ドメイン管理装置は、前記移動端末のポリシとして、前記移動端末が複数のインタフェースを同時に接続しない旨、前記移動端末が単一のインタフェースのみを有している旨、複数のインタフェースのうちの１つしか使用しない旨のいずれかが規定されている場合に、前記移動端末が単一のインタフェースを使用していると判断するように構成されている請求項８に記載の通信システム。
11. 前記移動端末のポリシを管理するポリシサーバを有する請求項７に記載の通信システム。
12. 前記移動端末のローカルモビリティをネットワーク側で実現する前記プロトコルとして、ＰＭＩＰを用いるように構成されている請求項１に記載の通信システム。
13. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末と、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記移動端末が現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
    前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
    前記関連情報を保持する関連情報保持手段と、
    前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
    前記チェック手段で前記移動端末の関連情報を保持していることが把握された場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置に対して、前記移動端末との間の接続が有効か否かの問い合わせを行う問い合わせ手段と、
    前記問い合わせ手段による問い合わせ結果において、前記移動端末との間の接続が有効であると判断された場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を前記関連情報保持手段に保持させる一方、前記移動端末との間の接続が有効でないと判断された場合には、前記移動端末と第２のエッジ装置を関連付ける関連情報を前記関連情報保持手段から消去するとともに、前記移動端末と前記第１のエッジ装置とを関連付ける関連情報を前記関連情報保持手段に保持させる情報保持制御手段とを、
    有するドメイン管理装置。
14. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
    前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
    前記関連情報を保持する関連情報保持手段と、
    前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
    前記チェック手段で前記第１のインタフェースと、前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持していることが把握された場合には、前記第１のインタフェースと前記第２のエッジ装置とを関連付ける関連情報を前記関連情報保持手段から消去するとともに、前記第１のインタフェースと前記第１のエッジ装置との関連情報を前記関連情報保持手段に保持させ、前記第１のインタフェースとは異なる第２のインタフェースと、前記第２のエッジ装置とを関連付ける関連情報を保持していることが把握された場合には、前記第２のインタフェースと前記第２のエッジ装置とを関連付ける関連情報に加えて、前記第１のインタフェースと前記第１のエッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として前記関連情報保持手段に保持させる情報保持制御手段とを、
    有するドメイン管理装置。
15. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
    前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
    前記関連情報を保持する関連情報保持手段と、
    前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
    前記チェック手段で前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持していないことが把握された場合には、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かの問い合わせを行う問い合わせ手段と、
    他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記移動端末と前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記移動端末と前記第１及び第２のエッジ装置の両方とを関連付ける関連情報を前記関連情報保持手段に保持させる情報保持制御手段とを、
    有するドメイン管理装置。
16. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置とを関連付ける関連情報を保持するドメイン管理装置であって、
    前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
    前記関連情報を保持する関連情報保持手段と、
    前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のインタフェースに関する前記関連情報を保持しているか否かを調べるチェック手段と、
    前記チェック手段で、前記ドメイン管理装置自身が前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する前記関連情報を保持していないことが把握された場合には、他の前記ドメイン管理装置に対して、前記第１のエッジ装置に接続しようとしている前記移動端末の第１のインタフェースに関する関連情報を保持しているか否かの問い合わせを行う問い合わせ手段と、
    他の任意の前記ドメイン管理装置から、前記問い合わせの結果として、前記第１のインタフェースとは異なる第２のインタフェースと前記第１のエッジ装置とは異なる第２のエッジ装置とを関連付ける関連情報を保持している旨の通知を受けた場合には、前記第１のインタフェースと前記第１エッジ装置とを関連付ける関連情報に加えて、前記第２のインタフェースと前記第２エッジ装置とを関連付ける関連情報を同一の前記移動端末の関連情報として前記関連情報保持手段に保持させる情報保持制御手段とを、
    有するドメイン管理装置。
17. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持するドメイン管理装置であって、
    前記移動端末が第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
    前記関連情報を保持する関連情報保持手段と、
    前記関連情報保持手段に保持している前記関連情報が更新された場合、他のドメイン管理装置に対して同様の情報更新を行うように指示する更新指示手段と、
    前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のエッジ装置に接続しようとしている前記移動端末の関連情報を保持しているか否かを調べるチェック手段と、
    前記チェック手段で前記移動端末の関連情報を保持していないことが把握された場合には、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第１の情報保持制御手段と、
    前記チェック手段で前記移動端末の関連情報を保持していることが把握された場合には、前記移動端末の関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して前記移動端末との間の接続が有効か否かの問い合わせを行う問い合わせ手段と、
    前記問い合わせ手段による問い合わせ結果において前記移動端末との間の接続が有効であると判断された場合には、前記移動端末と前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報と、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置を関連付ける関連情報とを前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる一方、前記問い合わせ手段による問い合わせ結果において前記移動端末との間の接続が有効ではないと判断された場合には、前記移動端末と前記第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を消去するとともに、前記移動端末と前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させ、さらに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第２の情報保持制御手段とを、
    有するドメイン管理装置。
18. 複数のインタフェースを有する移動端末のローカルモビリティをネットワーク側で実現するプロトコルの動作が行われるように構成されており、モビリティ管理ドメインが形成されている通信システム内に配置可能であり、前記モビリティ管理ドメインに接続する前記移動端末へのパケット転送経路を管理し、前記移動端末が有するインタフェースと、前記モビリティ管理ドメインのアクセスネットワークの端末側のエッジに配置され、前記インタフェースが現在接続しているエッジ装置及びそのエッジ装置を管理するドメイン管理装置とを関連付ける関連情報を保持するドメイン管理装置であって、
    前記移動端末の第１のインタフェースが第１のエッジ装置に接続しようとしている旨を通知するメッセージを前記第１のエッジ装置から受信する受信手段と、
    前記関連情報を保持する関連情報保持手段と、
    前記関連情報保持手段に保持している前記関連情報が更新された場合、他のドメイン管理装置に対して同様の情報更新を行うように指示する更新指示手段と、
    前記受信手段で前記メッセージを受信した場合、前記関連情報保持手段に保持している前記関連情報を参照して、前記第１のインタフェースに関する前記関連情報を保持しているか否かを調べるチェック手段と、
    前記チェック手段で、前記第１のインタフェースに関する前記関連情報を保持していないことが把握された場合には、前記第１インタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第１の情報保持制御手段と、
    前記チェック手段で前記第１のインタフェースに関する関連情報を保持していることが把握された場合には、前記第１のインタフェースに関する関連情報によって関連付けられている第２のエッジ装置を管理する第２のドメイン管理装置に対して、前記移動端末の第１のインタフェースとの間の接続が有効か否かの問い合わせを行う問い合わせ手段と、
    前記問い合わせ手段による問い合わせ結果において前記第１インタフェースとの間の接続が有効であると判断された場合には、
    前記第１のインタフェースと前記第１エッジ装置及び第１のドメイン管理装置とを関連付ける関連情報に加えて、前記第２のインタフェースと第２エッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を同一の前記移動端末の関連情報として前記関連情報保持手段に保持させるとともに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる一方、前記問い合わせ手段による問い合わせ結果において前記第１のインタフェースとの間の接続が有効ではないと判断された場合には、前記第２のインタフェースと第２のエッジ装置及び第２のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段から消去するとともに、前記第１のインタフェースと前記第１のエッジ装置及び第１のドメイン管理装置とを関連付ける関連情報を前記関連情報保持手段に保持させ、さらに、前記更新指示手段によって前記他のドメイン管理装置に対して同様の情報更新を行わせる第２の情報保持制御手段とを、
    有するドメイン管理装置。
19. 前記移動端末のポリシを参照して、前記関連情報の管理を行うように構成されている請求項１３に記載のドメイン管理装置。
20. 前記移動端末のポリシとして、前記移動端末が複数のインタフェースを同時に接続しない旨、前記移動端末が単一のインタフェースのみを有している旨、複数のインタフェースのうちの１つしか使用しない旨のいずれかが規定されている場合には、前記移動端末が複数のインタフェースの同時接続を行おうとしているか否かの問い合わせを行わないように構成されている請求項１９に記載のドメイン管理装置。