JPWO2010010695A1 - 移動端末及びネットワークノード - Google Patents

Abstract

ローカルモビリティドメイン内で移動する移動端末（モバイルノード）のマルチホーミングを確実にサポートする技術が開示される。ＭＮ（モバイルノード）１１が、マルチホーミング機能をサポートしているＭＡＧ（モバイルアクセスゲートウェイ）１０２にＩＦ１１０によって接続しており、さらに、マルチホーミング機能をサポートしていないＭＡＧ（モバイルアクセスゲートウェイ）１０３にＩＦ１１１によって接続を行おうとする。このとき、その技術によればＭＮは、ＭＡＧ１０３がマルチホーミング機能をサポートしていないことを把握すると、ＭＡＧ１０３との接続がまだ確立していない場合にはＭＡＧ１０３がマルチホーミング機能をサポートしていない旨を、ＭＡＧ１０３との接続が既に確立している場合にはＭＡＧ１０３以外のローカルモビリティドメインへの接続（ＭＡＧ１０２との接続）に関する情報を、ローカルモビリティドメインへ通知する。

Description

本発明は、パケット交換型データ通信ネットワークシステムにおける通信技術に関する。本発明は、特に、マルチホーミング機能を有するモバイルノードがローカルモビリティドメインに接続している場合に、マルチホーミングのサービスを受けることができるようにするための移動端末及びネットワークノードに関する。

下記の非特許文献１に記載のモバイルＩＰｖ６（ＭＩＰｖ６）によれば、移動端末（ＭＮ：Mobile Node、モバイルノード）は、インターネットへの接続ポイントを変更する場合にインターネットプロトコル（ＩＰ）アドレスを変更せずに維持することが可能である。

このＭＩＰｖ６において変更されることのないＩＰアドレスは、モバイルノードのホームネットワークドメインにおけるアドレスであり、ホームアドレス（home address）と呼ばれている。モバイルノードが外部（foreign）ネットワークドメインに接続されている間は、モバイルノードは、外部ネットワークドメインによって通知されるサブネットプレフィックスから、使用すべきＩＰアドレスを構成することが可能である。このように構成されたＩＰアドレスは、気付アドレス（care-of address）と呼ばれ、モバイルノードはこのアドレス経由でも到達可能となる。

モバイルノードは、その接続位置によらずに到達可能性を維持するため、気付アドレスとホームアドレスとを関連付けてホームエージェントに登録する。ＭＩＰｖ６では、ホームエージェントは、モバイルノードのホームネットワークドメイン内のルータであり、モバイルノードの現在の気付アドレスとそのホームアドレスのバインディングを登録する。これは、モバイルノードがバインディングアップデート（ＢＵ：Binding Update）メッセージをホームエージェントへ送信することによって実現される。モバイルノードがホームネットワークドメインから離れている場合には、ホームエージェントは、モバイルノードのホームアドレスあてのパケットを受信（intercept）し、関連付けられた気付アドレス経由で受信したパケットをモバイルノードへ向けトンネルする。上述のＭＩＰｖ６の説明から分かるように、ＭＩＰｖ６では、ホスト（モバイルノード）がモビリティ管理を行う。したがって、ＭＩＰｖ６は、ホストベースのモビリティ管理プロトコルとしても知られている。

一方、モバイルノードがローカルモビリティドメインを移動している際に、モビリティ関連シグナリングを行わないですむ別のモビリティ管理方式が存在する。このモビリティ管理方式では、ローカルモビリティドメイン内に存在するプロキシエンティティが、モバイルノードのモビリティ管理を行う。こうしたモビリティ管理方式は、ネットワークベースのモビリティ管理と呼ばれ、例えば、下記の非特許文献２に記載されている。

ローカルモビリティドメイン内を移動するモバイルノードは、アクセス認証処理の過程で、モバイルノードの識別情報（ＭＮ−ＩＤ）を提示することによって、プロキシエンティティ）に接続する。このプロキシエンティティは、例えば、非特許文献２に記載されているＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）である。ＭＮ−ＩＤは、ローカルサーバから取得可能なモバイルノードのポリシプロファイルを関連付けるために用いられる。ポリシプロファイルには、提供されるネットワークベースのモビリティサービスの特性やその他の関連するパラメータ（例えば、モバイルノードに割り当てられるネットワークプレフィックス（例えばMN.Prefix）、許可されているアドレス構成モード、移動ポリシ、ネットワークベースのモビリティサービスを提供するために不可欠なその他のパラメータなど）が含まれている。

モバイルアクセスゲートウェイは、アクセス認証に成功した後、ローカルサーバからモバイルノードのポリシプロファイルを取得する。これは、モバイルアクセスゲートウェイが、モバイルノードに関するモビリティシグナリングを実行するために必要なすべての情報を把握できることを意味する。したがって、モバイルアクセスゲートウェイは、モバイルノードのネットワークプレフィックス（MN.Prefix）を通知するルータ通知を周期的にモバイルノードへ送信する。モバイルノードは、MN.Prefixを参照すると、ローカルモビリティドメインに接続されているインタフェースに対して、通信を行うためのＩＰアドレス（例えば、ホームアドレス）を構成する。モバイルノードがローカルモビリティドメイン内のどの場所を移動しても、接続インタフェースは、常にMN.Prefixを参照することが可能である。これは、モバイルノードが接続する各モバイルアクセスゲートウェイが常にローカルサーバに問い合わせを行って、モバイルノードのプロファイルを取得することによる。その結果、モバイルノードは、ローカルモビリティドメインのどの位置に接続している場合であっても、通信を行うために、常に最初に構成されたＩＰアドレスを使用することが可能となる。

このネットワークベースのモビリティ管理を実現するため、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）と呼ばれるエンティティが、ローカルモビリティドメイン内の各モバイルノードに対して論理的なアンカポイントとして機能する。さらに、ローカルモビリティアンカは、各モバイルノードに関する到達可能状態の管理を行う。したがって、ローカルモビリティアンカは、非特許文献１に記載のホームエージェントと類似していると言える。各モバイルノードに関するアンカポイントとして機能するために、ローカルモビリティアンカには、各モバイルノードの現在位置がアップデートされる必要がある。したがって、モバイルノードがモバイルアクセスゲートウェイに接続する際は常に、モバイルアクセスゲートウェイは、プロキシバインディングアップデート（ＰＢＵ：Proxy binding Update）メッセージをローカルモビリティアンカへ送信する。このＰＢＵメッセージによって、MN.Prefixとモバイルアクセスゲートウェイの気付アドレスとの関連付けが行われる。そして、このバインディングによって、ローカルモビリティアンカは、適切なモバイルアクセスゲートウェイ経由でパケットをモバイルノードに発送することが可能となる。

図１には、上述のようなネットワークベースのモビリティ管理に用いられるシステムの一例が図示されている。図１では、ローカルモビリティドメイン１０は、ローカルモビリティアンカ（ＬＭＡ）１０１と複数のモバイルアクセスゲートウェイ（ＭＡＧ）１０２、１０３、１０４を有している。モバイルノード（ＭＮ）１１は、アクセス認証処理の過程でその識別情報（ＭＮ−ＩＤ）を提示して、モバイルアクセスゲートウェイ（ＭＡＧ）１０２とインタフェース（ＩＦ）１１０を接続する。

アクセス認証に成功した後、ＭＡＧ１０２は、ＭＮ１１のＭＮ−ＩＤに基づいて、ローカルサーバからＭＮ１１のポリシプロファイルを取得する。これは、ＭＡＧ１０２が、ＭＮ１１に関するモビリティシグナリングを実行するために必要なすべての情報を把握できることを意味する。したがって、ＭＡＧ１０２は、モバイルノードのネットワークプレフィックス（MN.Prefix）を通知するルータ通知を周期的にＭＮ１１へ送信する。ＭＮ１１は、このMN.Prefixを参照すると、通信に用いられるＩＦ１１０のＩＰアドレスを構成する。ＭＮ１１がローカルモビリティドメイン１０内のどの位置に移動するかに関係なく、ＩＦ１１０は、常に同一の割り当てられたネットワークプレフィックスを参照することができる。これは、ＭＮ１１が接続する各モバイルアクセスゲートウェイが、常にローカルサーバからＭＮ１１のプロファイルを検索することによる。例えば、ＭＮ１１がＭＡＧ１０３へ移動してＩＦ１１０によって接続を行う場合、ＭＡＧ１０３は、認証処理の間に提示されるＭＮ−ＩＤに基づいて、ＭＮ１１に割り当てられるネットワークプレフィックスをローカルサーバから取得する。したがって、ローカルモビリティドメイン１０内のＭＮ１１の位置によらず、ＭＮ１１は、通信を行うために、常に同一のＩＰアドレスを使用することが可能となる。

上述のように、ＬＭＡ１０１は、各モバイルノードに対して論理的なアンカポイントとして機能するとともに、各モバイルノードの到達可能状態も管理する。各モバイルノードのアンカポイントであるため、ＬＭＡ１０１には、各モバイルノードの現在位置についてアップデートされる必要がある。したがって、モバイルノードがモバイルアクセスゲートウェイに接続する際はいつも、モバイルアクセスゲートウェイは、プロキシバインディングアップデート（ＰＢＵ）メッセージをＬＭＡ１０１へ送信する。このＰＢＵによって、ＬＭＡ１０１は、モバイルノードのユニークな識別情報（ＭＮ−ＩＤ）に基づいて、モバイルノードに関するルーティングエントリを作成することができるようになる。ＬＭＡ１０１は、このルーティングエントリにおいて、モバイルノードに割り当てられたネットワークプレフィックスを、モバイルアクセスゲートウェイの気付アドレスと関連付ける。このバインディングによって、ＬＭＡ１０１は、適切なモバイルアクセスゲートウェイを通じてパケットをモバイルノードに発送することができる。ＬＭＡもまた一種のルータであり、バインディング登録によりバインディングエントリ（単にバインディングと呼ぶこともある）を生成する。ＬＭＡがパケットをルーティングする際にはルーティングエントリを参照し、パケットを送信するが、そのルーティングエントリの１つとしてバインディングエントリを参照することが可能である。なお、ルーティングエントリは、その他のルーティングプロトコルによっても生成されるため、同様の仕組みとして、バインディングエントリからルーティングエントリを明示的に生成することも可能である。本明細書においては、バインディング登録に基づくものをバインディングエントリ、ルーティングの際に参照する場合にはルーティングエントリとして説明する場合があるが、上述のように、実施の上での区別は当業者の任意の実装に依存するものであり、バインディングエントリとルーティングエントリの読み替えや、バインディングエントリからルーティングエントリの生成を前提とすることができる。

図１において、ＭＮ１１は、ＩＦ１１０を使用してＭＡＧ１０２と接続し、必要な認証処理を実行する。認証に成功した後、ＭＡＧ１０２は、ＰＢＵをＬＭＡ１０１へ送信する。ＬＭＡ１０１は、このＰＢＵの内容に基づいて、バインディングキャッシュにおいて、モバイルノードのホームネットワークプレフィックス又はホームアドレスを、ＭＡＧ１０２の気付アドレスと関連付ける。ＬＭＡ１１０がＭＮ１１のホームアドレスあてのパケットを受信した場合には、ＬＭＡ１１０は、バインディングキャッシュをチェックして、パケットのルーティングパスを調べる。ここでは、ＬＭＡ１１０は、このパケットがＭＮ１１あてであることを特定し、バインディングキャッシュのエントリに基づいてＭＡＧ１０２にパケットをトンネルし、ＭＡＧ１０２はＭＮ１１へパケットを転送する。

近年、ネットワークベースのモビリティ管理方式において、マルチインタフェースを有するモバイルノードからの同時アクセスのサポートに関する議論が行われてきた。ここでは主に、現在の携帯電子機器に複数のネットワークインタフェースが組み込まれることから、所定のホームアドレスに対して複数の気付アドレスを登録する機能を導入することに関して議論されてきた。以下、この技術を、モバイルノード／ルータが実現するマルチホーミング機能と呼ぶことにする。この議論の過程において、非特許文献２が改訂され、ローカルモビリティアンカがマルチホーミングをサポートするために考慮すべき問題に関して言及された。この改訂版は下記の非特許文献３として発行されている。

また、下記の非特許文献４には、複数の気付アドレスの登録を行うための方法が説明されている。この方法は、ＢＩＤ（Binding Unique Identification）と呼ばれる識別番号を使用して、あるホームアドレスに対して関連付けられている複数のバインディングの識別を行う。ＢＩＤは、モバイルノード／ルータのホームアドレスに関連付けられたインタフェース又は気付アドレスに割り当てられている。したがって、ホームアドレスは、モバイルノード／ルータ自体に関連付けられている一方、ＢＩＤは、モバイルノードによって登録された同時アクセスによる各バインディングを識別する。モバイルノードは、バインディングアップデート（ＢＵ）メッセージを使用して、ホームエージェントにＢＩＤを通知し、ホームエージェントは、ＢＩＤをそのバインディングキャッシュに記録する。また、モバイルノード／ルータがプリファレンスをホームエージェントに設定し、複数の気付アドレスを通じたトラフィックフローの選択的なルーティングを行えるようにすることも可能である。

また、下記の非特許文献５には、非特許文献４の技術を用いてモバイルノードがマルチホーミングを行う際にローカルモビリティドメイン内で発生する問題に基づいて分析が行われている。ここでは、ローカルモビリティアンカにおいて何らかの機能が欠けており、ローカルモビリティドメインがマルチホーミングをサポートできない場合の問題が注目されており、非特許文献３及び非特許文献４の技術の統合が考察されている。

ここで、セルラのオペレータが非特許文献３及び非特許文献４の両方の技術をシステムに導入する場合を考える。第３世代パートナーシッププロジェクト（３ＧＰＰ：Third Generation Partnership Project ）から発展した第４世代（４Ｇ）移動通信技術が、セルラネットワークのオールＩＰシステム化を目指していることは想像に難くない。また同様に、オールＩＰシステムは、国際モバイルテレコミュニケーションズ−２０００（ＩＭＴ−２０００：International Mobile Telecommunications-2000）プロジェクトの第３世代パートナーシッププロジェクト２（３ＧＰＰ２）においても研究されている。これらのプロジェクトでは、ほとんどのセルラのオペレータが、モバイル通信の迅速性及び容易性を向上させる目的を達成するという条件を満たす候補として、非特許文献３で説明されている技術を考慮している。また、非特許文献３ではローカルモビリティドメインにおけるマルチホーミングのサポートに言及されているので、将来、セルラネットワークはマルチホーミングをサポートする可能性が高いと思われる。さらに、非特許文献３に開示されている技術は、こうしたシステム内でデータのロードバランシングを実行する手段を実現することが可能であり、セルラのオペレータがマルチホーミングをサポートできるという利点がある。

例えば、図１において、ＭＮ１１のＩＦ１１０及びＩＦ１１１の両方のインタフェースが同時にローカルモビリティドメイン１０に接続されているとする。ここでは、ＩＦ１１０はＭＡＧ１０２に接続されており、ＩＦ１１１はＭＡＧ１０３に接続されているとする。これらの接続は両方共、ＬＭＡ１０１に登録される。ＬＭＡ１０１は、ＭＮ１１あてのパケットが届くと、ローカルモビリティドメイン１０のネットワーク条件に基づいて、ＭＡＧ１０２又はＭＡＧ１０３のどちらかを経由してＭＮ１１へパケットを転送するよう選択することが可能である。ＭＡＧ１０２がパケット処理に関して過負荷である場合には、ＬＭＡ１０１は、ＭＮ１１あてのパケットをＭＡＧ１０２に送信する代わりに、ＭＡＧ１０３経由で転送することが可能である。これにより、ＭＡＧ１０２の処理負荷が低減されるようになる。このように、ローカルモビリティドメイン内でマルチホーミングをサポートする利点として、ローカルモビリティアンカによって負荷バランシングが実行できることが挙げられる。

セルラのオペレータがシステム内でマルチホーミングのサポートを行うよう設定した場合には、注意すべき点が生じるかもしれない。注意すべき点の１つは、マルチホーミングをサポートする際にローカルモビリティアンカが過負荷な状態にならないようにすることである。ローカルモビリティアンカは、ローカルモビリティドメイン内でパケット発送に関する主要装置として動作しており、モバイルノードへの複数のルーティングパスを同時に扱う場合には比較的簡単な構成とすることが望ましい。また、別の注意すべき点として、モバイルアクセスゲートウェイがマルチホーミングをサポートするための複雑な機能を使用する必要はないことが挙げられる。モバイルアクセスゲートウェイが、例えば非特許文献４に記載の技術に従って、マルチホーム状態のモバイルノードのサポートを行えるようにすることが望ましい。

ＩＥＴＦ（Internet Engineering Task Force）における現在の作業では、ネットワークベースのモビリティ管理に関するマルチホーミングは、今後作業すべき事項と考えられている。ネットワークベースのモビリティ管理に関する基本プロトコルが完全に構築された場合に、この作業事項が調べられることになる。したがって、セルラのオペレータは、まず基本的なネットワークベースのモビリティ管理方式を配備して、その後、システムにマルチホーミングのサポートを統合する可能性が高い。セルラのオペレータは、この機能の統合に際してシステムを試行するので、最初、マルチホーム状態のモバイルノードをサポートするモバイルアクセスゲートウェイと、マルチホーム状態のモバイルノードをサポートしないモバイルアクセスゲートウェイとがシステムに混在することが予想される。さらに、マルチホーミング機能の利用に際して、各モバイルアクセスゲートウェイに関してライセンス料が徴収される場合には、オペレータは、いくつかのモバイルアクセスゲートウェイのみがマルチホーミング機能を有するようにすることで、維持費を最小限に抑えることが可能となる。

また、セルラのオペレータすべてが必ずしもシステム内でマルチホーミングのサポートを行うことを望んでいないこともあり得る。セルラのオペレータは、特定の地域に対する消費者市場に基づき、その消費者の大半がマルチホーミング機能を使用しないと判断した場合には、マルチホーミングサポートを配備しない可能性がある。このような環境で、特に、オペレータ間のローミング協定が存在する場合は、マルチホーム状態のモバイルノードが、マルチホーミングをサポートするモバイルアクセスゲートウェイ及びマルチホーミングをサポートしないモバイルアクセスゲートウェイに同時に接続することになる可能性がある。

米国特許公開２００７／０２５４６７７

D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. 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. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-07.txt, November 04, 2007. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Internet Engineering Task Force Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. M. Jeyatharan, C. Ng and J. Hirano, "Multiple Interfaced Mobile Nodes in NetLMM", Internet Engineering Task Force Internet Draft: draft-jeyatharan-netlmm-multi-interface-ps-00.txt, September, 2007.

上述のように、マルチホーム状態のモバイルノードが、マルチホーミングをサポートするモバイルアクセスゲートウェイ及びマルチホーミングをサポートしないモバイルアクセスゲートウェイに同時に接続する場合には、マルチホーム状態のモバイルノードに関するバインディングエントリがローカルモビリティアンカで失われてしまう可能性がある。バインディングエントリが無くなる理由は、非特許文献４に述べられているように、モビリティアンカポイント（例えばホームエージェント）がマルチホーム状態のモバイルノードに関する複数のバインディングエントリを保持しており、ＢＩＤを含まないバインディング登録を受信した場合には、保持しているすべてのバインディングエントリは消去するとともに新たに受信したＢＩＤを含まないバインディング登録で置き換えてしまうことによる。また、モビリティアンカポイントがマルチホーム状態のモバイルノードに関してバインディングエントリを１つ維持しており、ＢＩＤを有するバインディング登録を受信した場合も同様に、保持していたバインディングエントリが、ＢＩＤを有する受信バインディング登録のバインディングエントリで置き換えられてしまうことになる。その結果、モバイルノードはマルチホーム状態を失うことになり、マルチホーム状態のモバイルノードに関するサービスエクスペリエンスの低減を引き起こすことになる。

以下、図１を参照しながら、この問題について説明する。図１において、ローカルモビリティドメイン１０はマルチホーミングをサポートするエンティティを有している。ＬＭＡ１０１は、マルチホーム状態のモバイルノードに関するバインディングの処理方法を把握している。また同様に、ＭＡＧ１０２はマルチホーミングのサポート機能を有している。この場合、ＭＡＧ１０２は非特許文献４に記載されている技術を実行する。一方、ＭＡＧ１０３は、マルチホーミングのサポート機能を有していないとする。

ＩＦ１１０がＭＡＧ１０２に接続する場合、ＭＡＧ１０２は、その接続を登録するために、ＢＩＤを有するＰＢＵをＬＭＡ１０１へ送信する。この登録はバインディングエントリとしてＬＭＡ１０１に記録される。ＭＮ１１は、ローカルモビリティドメイン１０内で同時バインディングを実現しようとしており、ＩＦ１１１によってＭＡＧ１０３へ接続しようとする。これにより、ＭＡＧ１０３は、この接続の登録を行うために、ＰＢＵをＬＭＡ１０１へ送信する。ＭＡＧ１０３は、マルチホーミングのサポート機能を有していないのでＭＡＧ１０３からのＰＢＵにはＢＩＤは含まれていない。このＢＩＤを含まないＰＢＵの受信によって、ＬＭＡ１０１は、ＭＮ１１に関するすべてのバインディングを削除し、ＭＡＧ１０３へのバインディングエントリ１つに置き換えてしまう。その結果、ＭＮ１１は、ＬＭＡ１０１からＭＡＧ１０２への有効なパスを失ってしまうことになる。

また、ＭＡＧ１０２がＰＢＵをＬＭＡ１０１へ再送する場合には同一のバインディングエントリの置き換え動作が行われ、ＬＭＡ１０１は、ＭＡＧ１０３へのバインディングエントリを削除し、ＭＡＧ１０２へのバインディングエントリに置き換えてしまう。このような動作は、ＭＮ１１がこのシステムにおいてマルチホーミングを実現できないことを意味する。

なお、こうした問題を解消するための解決方法の１つが、例えば、上記の特許文献１においても説明されている。特許文献１における方法は、モバイルノードとの通信に使用可能なプロキシノードのＩＰアドレスを記載したバインディングメッセージをモバイルノードからアンカポイントへ送信させるものである。特許文献１における方法では、モバイルノードがプロキシノードに関する情報をアンカポイントに直接通知するので、アンカポイントが異なるタイプのバインディング登録メッセージを受信する場合が少なくなる。すなわち、モバイルノードからアンカポイントへ通知を行えるようにすることで、プロキシノードがマルチホーミングをサポートしているか否かにかかわらず、プロキシノードを経由してマルチホーミング機能が継続されるようになる。

本発明は、従来のマルチホーミングにおける問題点を解決することを目的とする。本発明は、特に、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対して、マルチホーミングをサポートし続けることを可能にする移動端末及びネットワークノードを提供することを目的とする。

上記の目的を達成するため、本発明の移動端末は、ネットワークベースのモビリティ管理を行うとともにマルチホーミングをサポートするローカルモビリティドメイン内で移動を行う移動端末であって、
複数の経路でパケットの送受信を行うことを可能とする、前記複数の経路のそれぞれに対応する複数の通信インタフェースと、
前記複数の通信インタフェースの少なくとも１つによって前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティに対して通知する機能情報通知手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティ（ローカルモビリティアンカ）は、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対してマルチホーミングをサポートし続けることが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノード（モバイルアクセスゲートウェイ）がマルチホーミングをサポートしていないことが把握できた場合、その旨をローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立していない場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノードとの間でアクセス認証が完了する前に、移動端末が接続しようとしている接続ノードがマルチホーミングをサポートしていない旨をローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードから、前記接続ノードがマルチホーミングをサポートしているか否かを示す情報を受信する機能情報受信手段を有する。
この構成により、例えば、接続ノードから受信するルータ通知メッセージに含まれている接続ノードの機能情報によって、接続ノードがマルチホーミングをサポートしているか否かを把握することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしているか否かを示す情報を、ファストモバイルＩＰを利用して取得する機能情報取得手段を有する。
この構成により、移動端末は、ファストモバイルＩＰを利用して、接続ノードがマルチホーミングをサポートしているか否かを把握することが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末は、接続ノードにまもなく接続しようとしている通信インタフェースを除く、ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、ローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立している場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノードとの間でアクセス認証が完了した後に、消去されてしまった可能性のあるすべての通信インタフェースに関する接続情報をローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを要求する確認要求手段を有する。
この構成により、移動端末は、ローカルモビリティドメイン内のエンティティにおいて正常な処理が行われたか否かを把握することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記確認メッセージを受信できなかった場合には、前記ローカルモビリティドメイン内のエンティティに対して、前記移動端末の接続に関するルーティング情報の再構築を要求するルーティング再構築要求手段を有する。
この構成により、移動端末は、ローカルモビリティドメイン内のエンティティにおいて正常な処理が行われなかったと判断した場合に、移動端末の接続に関するルーティング情報の再構築を要求することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内のエンティティから、前記移動端末のマルチホーム状態が失われた旨の通知を受信した場合、前記移動端末のマルチホーム状態を再構成するための情報を前記ローカルモビリティドメイン内のエンティティへ通知する再構成手段を有する。
この構成により、移動端末は、所望のマルチホーム状態を構成することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内のエンティティにおけるルーティングエントリが削除されたと判断できる場合、削除されたと判断された前記ルーティングエントリの復元を要求する復元要求手段を有する。
この構成により、移動端末は、ルーティングエントリの復元を要求することで、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記復元要求手段が、前記移動端末が接続しているマルチホーミングをサポートしている前記接続ノードに対して、前記ルーティングエントリを再構築させるための登録メッセージの再送を依頼するよう構成されている。
この構成により、移動端末は、マルチホーミングをサポートしている接続ノードに登録メッセージを再送させることで、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記復元要求手段が、前記移動端末が接続している前記接続ノードの中から、前記登録メッセージの再送を依頼する前記接続ノードを選択するよう構成されている。
この構成により、移動端末は、所望の接続ノード（例えば、マルチホーミングをサポートしていることが分かっている接続ノード）を確実に選択して、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内の前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を収集し、リスト情報として格納する情報収集格納手段を有する。
この構成により、リスト情報を用いて検索手順を効率化することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を通知するバインディング特定情報通知手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティにおいて、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報に、置き換えられる対象のバインディングに関連する通信インタフェースを識別する固有の識別情報が含まれている。
この構成により、ローカルモビリティドメイン内のエンティティにおいて、移動端末のインタフェースの識別情報に基づいて、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。

また、上記の目的を達成するため、本発明のネットワークノードは、ローカルモビリティドメインにおいて、ネットワークベースのモビリティ管理を行うとともに、前記ローカルモビリティドメインに接続する移動端末のマルチホーミングをサポートする前記ローカルモビリティドメイン内のネットワークノードであって、
前記移動端末の通信インタフェースが前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記通信インタフェースと前記接続ノードとの対応をルーティング情報として保持するルーティングキャッシュと、
前記移動端末が保持する複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段と、
前記機能情報受信手段で受信した前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に基づいて、前記移動端末に関するルーティング情報の更新を行うルーティング更新手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティ（ローカルモビリティアンカ）は、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対してマルチホーミングをサポートし続けることが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていない旨を前記移動端末から受信した場合、通知を受けた前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を識別する固有の識別情報を準備する識別情報準備手段と、
通知を受けた前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を示す情報を受信した場合に、前記通信インタフェースと前記接続ノードとの対応を示すルーティング情報に前記固有の識別情報を付加して前記ルーティングキャッシュに格納させるルーティング情報管理手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末が接続しようとしている接続ノードがマルチホーミングをサポートしていない旨を把握し、その接続に関するルーティング情報の登録を行うために、その接続に対応する固有の識別情報を割り当てる準備を行うことが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を前記移動端末から受信した場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報に基づき、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に対応するルーティング情報を前記ルーティングキャッシュに追加するルーティングキャッシュ更新手段を有する。
この構成により、移動端末がマルチホーミングをサポートしていない接続ノードと接続したことによって、ローカルモビリティドメイン内のエンティティが消去してしまった可能性のあるすべての通信インタフェースに関する接続情報をルーティング情報として登録することが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを前記移動端末へ送信する確認送信手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末から受信した情報に対して正常な処理を行うことができたか否かを移動端末へ通知することが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記移動端末に関するルーティング情報を前記ルーティングキャッシュから消去するとともに、前記移動端末のマルチホーム状態が失われた旨を前記移動端末へ通知するルーティング情報消去通知手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末に所望のマルチホーム状態を改めて構成させることが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記移動端末に関するルーティング情報を消去する場合に、消去対象のルーティング情報に係るルーティングを無効にするとともに一定期間消去を保留し、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信した場合には前記消去対象のルーティング情報を有効にし、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信しなかった場合には前記一定期間経過後に前記消去対象のルーティング情報を完全に削除するルーティング情報消去手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、ルーティングエントリの復元の要求を移動端末から受信した場合に、移動端末が所望するルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を前記移動端末から受信した場合、前記ルーティング更新手段が、前記置き換えられる対象のバインディングを示す情報によって特定されるバインディングを、まもなく接続しようとしている前記接続ノードに関するバインディングに置き換えるよう構成されている。
この構成により、ローカルモビリティドメイン内のエンティティは、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。

本発明は、上記の構成により、従来のマルチホーミングにおける問題点を改善できるという効果を有する。本発明は、上記の構成により、特に、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対してマルチホーミングをサポートし続けることを可能にするという効果を有する。

本発明の実施の形態及び従来の技術におけるネットワークベースのモビリティ管理に用いられる通信システムの一例を示す図 本発明の好適な実施の形態におけるルータ機能メッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、受信した機能情報に基づいてモバイルノードが行う動作の一例を示すフローチャート 本発明の好適な実施の形態において、ローカルモビリティドメイン内のエンティティに通知するために用いられる接続メッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、ローカルモビリティアンカによって行われる処理の一例を示すフローチャート 本発明の好適な実施の形態における再関連付けメッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、リカバリ動作をサポートするルーティングキャッシュの一例を示す図 本発明の好適な実施の形態におけるモバイルノードの機能アーキテクチャの一例を示すブロック図

以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているに過ぎず、本発明を限定するものではない。例えば、本発明を明瞭に示すために、周知の構成要素及びモジュールはブロックダイアグラムで表される。

本発明の実施の形態では、マルチホーム状態のモバイルノード（multi-homed mobile node）がローカルモビリティアンカに対して、ローカルモビリティドメインでマルチホーミングをサポートするための情報を提供できるようにする方法について説明する。この方法をサポートするため、モバイルノードは、まず、モバイルノードが接続しようとしているモバイルアクセスゲートウェイの機能（capability）を判断する必要がある。モバイルノードは、モバイルアクセスゲートウェイがマルチホーミングをサポートしていないことを把握できた場合には、これをトリガとして、まもなく行おうとしている接続に関する情報をローカルモビリティアンカへ提供する。ローカルモビリティアンカは、この提供された情報を用いることで、たとえモバイルアクセスゲートウェイにマルチホーミングのサポート機能が備わっていない場合であっても、モバイルノードへのマルチホーミングのサポートを維持することが可能となる。

モバイルノードが判断処理を実行することによって、モバイルノードは、ローカルモビリティドメインにおけるモバイルノードのマルチホーミングのサポートを維持するためにローカルモビリティアンカへ情報を伝える必要があるかどうかを判断することが可能となる。

また、本発明において、モバイルノードに関するマルチホーミングをサポートする機能をモバイルアクセスゲートウェイが実行可能かどうかをモバイルノードが把握するための好適な方法としては、例えば、モバイルアクセスゲートウェイがモバイルノードに対してその機能を保持していることを通知する方法が可能である。この方法を実現可能とするやり方の１つとして、モバイルアクセスゲートウェイがＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１で記述されているビーコン送信方法を利用する方法が挙げられる。また、この方法を実現可能とする別のやり方としては、モバイルアクセスゲートウェイがＩＥＴＦ（Internet Engineering Task Force）で記述されているルータ通知送信方法を利用する方法が挙げられる。また、３Ｇネットワークでは各無線アクセス技術における（レイヤ２技術に相当する）報知情報を利用することもできる。

図２には、本発明の好適な実施の形態におけるルータ機能メッセージ（router capability message）のフォーマットの一例が図示されている。図２において、ルータ機能メッセージ２０は、パケットヘッダ２００、ルータＩＤ（ルータ識別子）２０１、ルータ機能フィールド２０２を有している。

パケットヘッダ２００は、メッセージの送信元（ルータ機能メッセージの送信者）やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ２００には、例えば、送信元やあて先のＩＰｖ４アドレス又はＩＰｖ６アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

また、ルータＩＤ２０１は、そのルータの機能を通知するルータ識別情報を提供するためのフィールドである。なお、ルータＩＤ２０１は、モバイルアクセスゲートウェイのＭＡＣアドレスや、ローカルモビリティドメインのサービスプロバイダによって設定されたモバイルアクセスゲートウェイ固有の名前などを用いて形成されることが望ましい。

また、ルータ機能フィールド２０２は、モバイルアクセスゲートウェイの特徴（機能情報）を伝送するためのフィールドである。なお、本発明の実施の形態では、ルータ機能フィールド２０２は、モバイルアクセスゲートウェイがマルチホーミングのサポートを行えること（すなわち、マルチホーミングのサポート機能を有しており、かつ、その機能が実行可能であること）をモバイルノードに知らせるためのフラグ（ここでは、“Ｍ”フラグと記載する）２０２０を有している。

“Ｍ”フラグ２０２０は、例えば、１ビットの２進数の値によって実現可能である。例えば、“１”の値は、モバイルアクセスゲートウェイがマルチホーミングのサポート機能を備えていることを示しており、逆に、“０”の値は、モバイルアクセスゲートウェイがマルチホーミングのサポート機能を備えていないこと（あるいは、マルチホーミングのサポート機能を備えているとしても、その機能を実行できないこと）を示している。

なお、例えば、“Ｍ”フラグ２０２０のデフォルト値は“０”に設定されることが好ましい。これにより、マルチホーミングのサポートが可能なモバイルアクセスゲートウェイだけが、“Ｍ”フラグ２０２０の値を“１”の値に変えればよい。その結果、マルチホーミングのサポート機能を保持していないモバイルアクセスゲートウェイの機能を変更する必要が少なくなり、レガシノードであっても本発明に係るシステムで動作可能となる。なお、この値の設定は、レガシノードが未使用領域として“Ｍ”フラグ２０２０の値に相当する部分を“０”と設定していることを前提としている。

以下、ルータ機能メッセージ２０の使用方法の簡単な一例について説明する。図１において、ローカルモビリティドメイン１０では、ＭＡＧ１０２はマルチホーミングプロトコルを実装している。したがって、ＭＡＧ１０２は、“１”の値（マルチホーミングのサポートを行っていることを示す値）にセットされた“Ｍ”フラグ２０２０を有するルータ機能メッセージ２０を用いた通知を行う。このルータ機能メッセージ２０を受信することによって、ＭＮ１１は、ＭＡＧ１０２がマルチホーミングのサポートを行っていることを把握する。

一方、図１において、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。したがって、ＭＡＧ１０３は、“０”の値にセットされた“Ｍ”フラグ２０２０を有するルータ機能メッセージ２０を用いた通知を行う。このルータ機能メッセージ２０を受信することによって、ＭＮ１１は、ＭＡＧ１０３がマルチホーミングのサポートを行っていないことを把握する。

また、モバイルアクセスゲートウェイがマルチホーミングのサポートを行っているかどうかをモバイルノードが把握できるようにするための別の好適な方法として、ＩＥＥＥ８０２．２１の情報サービス（ＩＳ：Information Service）に関する手法を用いるやり方が挙げられる。この手法では、モバイルノードは、モバイルアクセスゲートウェイの機能に関して、ＩＳサーバへ問い合わせを行う。ＩＳサーバは、モバイルノードからの問い合わせに対する応答を行う。

以下、ＩＥＥＥ８０２．２１の情報サービスを用いる方法の一例について説明する。図１において、ローカルモビリティドメイン１０は、ローカルモビリティドメイン１０内に存在するすべてのモバイルアクセスゲートウェイ（ＭＡＧ１０２〜１０４）の機能に関する情報を格納しているＩＳサーバ（図１には不図示）を更に有している。ＭＮ１１は、ＭＡＧ１０３とＩＦ１１１で接続を行う前に、ＭＡＧ１０３がＭＮ１１に対してマルチホーミングのサポートを行えるかどうかを問い合わせるＩＳクエリメッセージをＩＳサーバへ送信する。ここで、ＩＳサーバのデータベースにおいて、ＭＡＧ１０３がマルチホーミングプロトコルを実装していないと判断されたとする。このとき、ＩＳサーバは、ＭＡＧ１０３がマルチホーミングのサポートを行うことができない旨を示す応答をモバイルノードへ行う。

モバイルノードは、モバイルアクセスゲートウェイの機能に関する情報（以下、機能情報と記載する）を受信すると、この受信した機能情報を解析し、この解析結果に基づく動作を行う。図３には、本発明の好適な実施の形態において、受信した機能情報に基づいてモバイルノードが行う動作の一例を示すフローチャートが図示されている。

図３において、モバイルノードは、モバイルアクセスゲートウェイの機能情報を受信すると、その機能情報から、モバイルアクセスゲートウェイがマルチホーミングをサポートしているか否かを特定する（ステップＳ３１）。モバイルアクセスゲートウェイがマルチホーミングをサポートしている場合には、処理は終了となる。この場合、モバイルノードはこれ以上特別な処理を行うことなく、モバイルアクセスゲートウェイとの間でのアクセス認証処理を行うことが可能となる。

一方、モバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、モバイルノードは、ローカルモビリティドメインにおけるマルチホーミングを維持するために、ローカルモビリティドメイン内のエンティティに通知を行う必要がある。このエンティティは、例えば、ローカルモビリティアンカであってもよく、モバイルアクセスゲートウェイであってもよい。

モバイルノードがマルチホーミングを維持するためにローカルモビリティドメイン内のエンティティへ通知を行う場合、例えば下記のように、２つのモードのうちのいずれかを採用することが可能である。なお、それぞれのモード（モード１及びモード２）において、モバイルノードは異なるタイプの情報を送信する。

モバイルノードの動作モードがモード１の場合（ステップＳ３２で『モード１』）には、モバイルノードは、ローカルモビリティドメイン内のエンティティに対して、そのモバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続しようとしている旨を通知する（ステップＳ３３）。その結果、この通知を受けたエンティティは、ローカルモビリティドメインにおいてモバイルノードのマルチホーミングを中断しないようにするための更なるステップを行うことが可能となる。

この方法は、モバイルノードがモバイルアクセスゲートウェイの機能を事前に検出することができる場合に特に有用である。モバイルノードは、この情報に基づいて、マルチホーミングの機能を有していないモバイルアクセスゲートウェイからバインディング登録メッセージが送信されることを事前に把握することが可能となる。なお、モバイルアクセスゲートウェイの機能を事前に検出できるように方法として、例えば、ＩＥＴＦで構築されたファストモバイルＩＰ（Fast Mobile IP）を利用する方法を用いることも可能である。

また、モバイルノードの動作モードがモード２の場合（ステップＳ３２で『モード２』）には、モバイルノードは、ローカルモビリティドメイン内のエンティティに対して、ローカルモビリティドメインでの現在の接続に関する情報を通知する（ステップＳ３４）。この情報の通知を受けたローカルモビリティドメイン内のエンティティは、モバイルノードのルーティングキャッシュを再構築し、マルチホーミングのサービスをモバイルノードへ提供し続けることが可能となる。

この方法は、マルチホーミングの機能を有していないモバイルアクセスゲートウェイがバインディング登録メッセージを送信するよりも前に、モバイルノードがエンティティに通知を行うことができない場合に特に有用である。なお、このような場合が起こり得る状況としては、例えば、モバイルノードのインタフェースが、あるモバイルアクセスゲートウェイから、マルチホーミングをサポートしていない別のモバイルアクセスゲートウェイにハンドオフするシナリオが考えられる。

上述の両方のモード（モード１及びモード２）共、モバイルノードはローカルモビリティドメイン内のエンティティに対して通知を行った後、処理は終了となる。なお、モバイルノードは、この通知を行うためのメッセージ（後述の接続メッセージ４０）に、確認メッセージ（ＡｃＫ）をリクエストする旨を示す情報を挿入してもよい。

次に、上述のフローチャートに示す方法について、図１を参照しながら、より詳細に説明する。図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１はＩＦ１１０をＭＡＧ１０２に接続しており、ＬＭＡ１０１は、ＭＡＧ１０２経由で受信したＭＮ１１のバインディングを保持しているとする。このバインディングは、バインディングに固有の識別情報（ＢＩＤ１）で識別される。

このとき、ＭＮ１１は、同時アクセスによってＭＡＧ１０３へＩＦ１１１を接続しようとしている場合には、マルチホーミングのサポートに関連するＭＡＧ１０３の情報（ＭＡＧ１０３の機能情報）を取得する。

ＭＮ１１がＭＡＧ１０３との間でアクセス認証を確立する前にこの機能情報（ＭＡＧ１０３がマルチホーミングをサポートしていない旨を示す情報）を取得した場合には、ＭＮ１１は、ＭＡＧ１０３への接続が行われようとしている旨を通知するためのメッセージをＬＭＡ１０１へ送信する。なお、このメッセージは、ＭＮ１１からＬＭＡ１０１に直接送信されてもよく、あるいは、ＭＮ１１からＭＡＧやその他の任意のエンティティに渡されてからＬＭＡ１０１に到達してもよい。また、このメッセージはＭＡＧ１０２を通じて送信されてもよく、ＭＡＧ１０３によって送信されるバインディング登録メッセージに挿入（ピギーバック）されてもよい。

一方、ＭＮ１１がＭＡＧ１０３との間でアクセス認証を確立した後にこの情報（ＭＡＧ１０３がマルチホーミングをサポートしていない旨を示す情報）を取得した場合には、ＭＮ１１は、ＭＡＧ１０２との接続を更に通知する同様のメッセージをＬＭＡ１０１へ送信する。この場合も同様に、ＭＡＧ１０２又はＭＡＧ１０３経由でメッセージの送信が可能である。

このようにしてＭＮ１１から通知された情報をＬＭＡ１０１が参照することで、ＭＮ１１がローカルモビリティドメイン１０においてマルチホーミングのサービスを確実に受け続けることができるようになる。

以下、いくつかの実施例を挙げて、マルチホーミングを維持するためにモバイルノードからローカルモビリティドメイン内のエンティティに送信されるメッセージ（以下、接続メッセージと記載する）の詳細について説明する。なお、この接続メッセージは、モバイルノードから１つ又は複数のモバイルアクセスゲートウェイ（マルチホーミングサポートを有していてもよく、あるいは有していなくてもよい）を経由して送信可能である。

図４には、本発明の好適な実施の形態において、ローカルモビリティドメイン内のエンティティに通知するために用いられる接続メッセージのフォーマットが示されている。接続メッセージ４０は、パケットヘッダ４００、モバイルノード識別情報（ＭＮ−ＩＤ）４０１、接続ステータスフィールド４０２を有している。

パケットヘッダ４００は、メッセージの送信元（接続メッセージの送信者）やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ４００には、例えば、送信元やあて先のＩＰｖ４アドレス又はＩＰｖ６アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

またＭＮ−ＩＤ４０１は、モバイルノードの識別情報を提供するためのフィールドである。この識別情報によって、ローカルモビリティドメイン内のエンティティは、この接続メッセージ４０が適用されるモバイルノードの接続ステータスを識別することが可能となる。

また、接続ステータスフィールド４０２は、モバイルノードが現在どのモバイルアクセスゲートウェイに接続しているかを示す情報（あるいは、モバイルノードがどのモバイルアクセスゲートウェイに接続しようとしているかを示す情報）を、ローカルモビリティドメイン内のエンティティへ通知するためのフィールドである。なお、接続ステータスフィールド４０２には、例えば１つ又は複数のルータＩＤ（ルータ識別情報）４０２０が含まれており、このルータＩＤ４０２０によって、どのモバイルアクセスゲートウェイが対象とされているかを接続メッセージ４０の受信者が把握できるようにすることが望ましい。

また、各ルータＩＤ４０２０は、そのルータＩＤ４０２０によって特定されるモバイルアクセスゲートウェイがマルチホーミングをサポートすることが可能か否かを接続メッセージの受信者４０が識別できるようにするための“Ｍ”フラグ４０２１と関連付けられていることが望ましい。“Ｍ”フラグ４０２１は、１ビットの値によって実現可能である。“１”の値の“Ｍ”フラグ４０２１は、ルータＩＤ４０２０によって特定されるモバイルアクセスゲートウェイがマルチホーミングをサポートしていることを示している。逆に、“０”の値の“Ｍ”フラグ４０２１は、モバイルアクセスゲートウェイがマルチホーミングをサポートしていないことを示している。

以下、本発明の好適な実施の形態（モード１の場合）における接続メッセージ４０の具体的な使用方法について説明する。図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１はＩＦ１１０をＭＡＧ１０２に接続しており、ＬＭＡ１０１は、ＭＡＧ１０２経由で受信したＭＮ１１のルーティングエントリを保持しているとする。このルーティングエントリは、バインディングに固有の識別情報（ＢＩＤ１）で識別される。ＬＭＡもまた一種のルータであり、バインディング登録によりバインディングエントリ（単にバインディングと呼ぶこともある）を生成する。ＬＭＡがパケットをルーティングする際にはルーティングエントリを参照し、パケットを送信するが、そのルーティングエントリの1つとしてバインディングエントリを参照することが可能である。なお、ルーティングエントリは、その他のルーティングプロトコルによっても生成されるため、同様の仕組みとして、バインディングエントリからルーティングエントリを明示的に生成することも可能である。本明細書においては、バインディング登録に基づくものをバインディングエントリ、ルーティングの際に参照する場合にはルーティングエントリとして説明する場合があるが、上述のように、実施の上での区別は当業者の任意の実装に依存するものであり、バインディングエントリとルーティングエントリの読み替えや、バインディングエントリからルーティングエントリの生成を前提とすることができる。

このとき、ＭＮ１１は、同時アクセスによってＭＡＧ１０３へＩＦ１１１を接続しようとしている場合には、マルチホーミングのサポートに関連するＭＡＧ１０３の情報（ＭＡＧ１０３の機能情報）を取得する。

ここで、ＭＮ１１がＭＡＧ１０３との間でアクセス認証を確立する前にこの機能情報（ＭＡＧ１０３がマルチホーミングをサポートしていない旨を示す情報）を含むＩＥＥＥ８０２．１１ビーコンを受信したとする。この場合には、ＭＮ１１は、ＭＡＧ１０３がＭＮのプレフィックスとＭＡＧ１０３の気付アドレスとを関連付けるＰＢＵを送信する前に、まもなく行おうとしているＭＡＧ１０３への接続に関する情報をＬＭＡ１０１に通知する旨を決定する。そして、ＭＮ１１は、ＭＡＧ１０３の識別情報を示すルータＩＤ４０２０、及び、“０”の値にセットされた“Ｍ”フラグ４０２１を有する接続ステータスフィールド４０２を含む接続メッセージ４０をＬＭＡ１０１へ送信する。この結果、ＬＭＡ１０１は、マルチホーミングをサポートしていないＭＡＧ１０３にＭＮ１１が接続しようとしている旨を把握し、ローカルモビリティドメインにおいてＭＮ１１のマルチホーミングを中断しないようにするための更なるステップを行うことが可能となる。

また、以下では、本発明の別の実施の形態（モード２の場合）における接続メッセージ４０を使用する方法について説明する。図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１はＩＦ１１０をＭＡＧ１０２に接続しており、ＬＭＡ１０１は、ＭＡＧ１０２経由で受信したＭＮ１１のルーティングエントリを保持しているとする。このルーティングエントリ（バインディング）は、バインディングに固有の識別情報（ＢＩＤ１）で識別される。

ＭＮ１１は、ＩＦ１１１をＭＡＧ１３０に接続して同時アクセスを行おうとしている場合に、マルチホーミングのサポートに関連するＭＡＧ１０３の情報を取得する。ＭＡＧ１０３とのアクセス認証を完了した後、ＭＮ１１は、ＭＡＧ１０３がマルチホーミングのサポート機能を有していない旨を示すルータ通知を受信したとする。この場合、ＭＮ１１は、ローカルモビリティドメイン１０へのすべての接続に関する情報をＬＭＡ１０１へ通知する旨を決定する。この決定に従って、ＭＮ１１は、“１”の値がセットされた“Ｍ”フラグ４０２１及びＭＡＧ１０２の識別情報を示すルータＩＤ４０２０と、“０”の値がセットされた“Ｍ”フラグ４０２１及びＭＡＧ１０３の識別情報を示すルータＩＤ４０２０とを有する接続ステータスフィールド４０２を含む接続メッセージ４０をＬＭＡ１０１へ送信する。これにより、ＬＭＡ１０１は、ＭＮ１１のルーティングキャッシュを更新し、ＭＮ１１がローカルモビリティドメイン１０内でマルチホーミングの利益を確実に受け続けられるようにすることが可能となる。

なお、上述した両方の例（モード１及びモード２の両方の例）において、モバイルノードから送信された接続メッセージ４０は、モバイルアクセスゲートウェイによってローカルモビリティアンカへ中継される。これにより、モバイルノードは、ローカルモビリティアンカのＩＰアドレスを探索する必要はなくなり、モバイルノードの限られたバッテリ寿命を保つことが可能となる。

さらに、現在のモバイルアクセスゲートウェイとの接続やまもなく行われるモバイルアクセスゲートウェイとの接続を経由して接続メッセージ４０を伝送すべきか否かを、モバイルノードが選択することが可能である。各モバイルアクセスゲートウェイはモバイルノードから受信したパケットをローカルモビリティアンカへ転送するので、ローカルモビリティアンカは、現在のモバイルアクセスゲートウェイとの接続やまもなく行われるモバイルアクセスゲートウェイとの接続のどちらかを利用して接続メッセージ４０を受信することが可能である。

まもなく行われるモバイルアクセスゲートウェイとの接続を経由して接続メッセージ４０を送信した場合には、この接続メッセージ４０が最小の遅延で確実にローカルモビリティアンカに届くという利点がある。なお、まもなく接続しようとしているモバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、このモバイルアクセスゲートウェイから送信されるＰＢＵは、モバイルノードがモバイルアクセスゲートウェイの機能を把握する前に、ローカルモビリティアンカに届いてしまう可能性がある。その結果、モバイルノードのすべてのアクティブな接続に関する情報が、ローカルモビリティアンカから削除されてしまう可能性がある。したがって、ローカルモビリティアンカは、こうしたモバイルアクセスゲートウェイからモバイルノードに関連するデータを受信することを予想していないので、モバイルアクセスゲートウェイから受信するモバイルノードに関連するパケットは、ローカルモビリティアンカにおいて廃棄されてしまう可能性がある。

また、モバイルノードがローカルモビリティアンカとの間のアクティブな接続を切断した場合に、ローカルモビリティアンカがバインディング取り消しメッセージを、対応するモバイルアクセスゲートウェイへ送信してしまう可能性もある。これは、事実上、モバイルノードのデータをローカルモビリティアンカへプロキシしないようにモバイルアクセスゲートウェイへ指示するものであり、モバイルノードからモバイルアクセスゲートウェイへ送信される接続メッセージ４０が廃棄されてしまうことになりかねない。このような場合でも、マルチホーミングをサポートしているローカルモビリティアンカや、現在接続を維持できているローカルモビリティアンカを、接続メッセージを送信する経由先として優先的に選択することで、状況が改善される可能性がある。

なお、当業者であれば、上述の説明によって、モバイルノードがマルチホーミングの動作を維持できるようになる方法（本発明に係る方法）が、特許文献１に説明されている方法とは異なることが理解できるであろう。特許文献１に開示されている従来の技術では、モバイルノードが、プロキシノードのＩＰアドレスを示すメッセージをアンカポイント（anchoring point）へ送信するようトリガされる。これによって、アンカポイント（anchoring point）は、モバイルノードとの接続を維持し続けることが可能となる。

また、同様に、トリガを行ってアンカポイントをアップデートする方法に関しては、非特許文献１や非特許文献４にも開示されている。これらの非特許文献１及び非特許文献４の両方における技術では、モバイルノードは、ＩＰアドレスを変更した場合は常にアンカポイントを更新するようトリガされる。また、非特許文献４では、モバイルノードによって使用されている各ＩＰアドレスを識別することが可能となる識別情報が、アンカポイントへ送信されるメッセージに含まれている。

上述の従来の技術及び本発明は共に、新しい接続ポイントに関する情報をアンカポイントにアップデートする動作をモバイルノードに行わせるという点においては同じ概念を用いている。しかしながら、本発明では、アンカポイントへのメッセージには、プロキシノードの機能に関連する情報が更に含まれている。この情報を用いることで、アンカポイントは、モバイルノードとの接続を維持できるようになる。また、本発明は、この情報をより適切なプロキシノードを経由して送信できるようしており、情報を通知する効率、安定性が向上する。以上のように、本発明と従来の技術とは大きく異なっている。

上述においては、本発明によって、モバイルノードがモバイルアクセスゲートウェイの機能に関する情報をローカルモビリティアンカへ送信するようトリガされることによって、ローカルモビリティドメインでのマルチホーミング機能が維持される方法について説明した。モバイルアクセスゲートウェイの機能に関する情報がローカルモビリティアンカに到達した場合には、ローカルモビリティアンカが行うべき次の動作方針を決定するために、この情報の処理が行われる必要がある。

以下、図５に図示されているフローチャートを参照しながら、本発明の実施の形態において、ローカルモビリティアンカによって行われる処理の一例について説明する。ローカルモビリティアンカが接続メッセージ４０を受信した場合に、図５の処理が開始される。ローカルモビリティアンカは、処理を開始すると、まず、接続メッセージ４０内に含まれている情報のタイプ（モバイルノードの動作モード）を判断する（ステップＳ５１）。

例えば、この情報が、モバイルアクセスゲートウェイがマルチホーミング機能をサポートしていないことを示す情報である場合（上述の図３のステップＳ３３において、モバイルノードの動作モードが、マルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続しようとしている旨を通知するモード１の場合）には、ローカルモビリティアンカは、まもなく行われるモバイルノードとの接続を注目して、この登録を行うためのユニークなバインディング識別子（ＢＩＤ）を準備する（ステップＳ５２）。

一方、例えば、この情報が、モバイルノードが接続されているすべてのモバイルアクセスゲートウェイに関する情報である場合（上述の図３のステップＳ３４において、モバイルノードの動作モードが、ＭＡＧとの現在の接続に関する情報を通知するモード２の場合）には、ローカルモビリティアンカは、通知されたこの情報を用いて、モバイルノードのルーティングを定めるバインディングキャッシュエントリ（ＢＣＥ：Binding Cache Entry）を更新する（ステップＳ５３）。

ステップＳ５２又はステップＳ５３における情報処理が行われた後、ローカルモビリティアンカは、モバイルノードに対して確認メッセージ（Ａｃｋ）が送信されるべきか否かのチェックを行う（ステップＳ５４）。なお、この確認メッセージのリクエストは、例えば、モバイルノードによって接続メッセージ４０内に挿入されてもよい。また、モバイルノードが確認メッセージのリクエストを行っていない場合であっても、ローカルモビリティアンカは、この確認メッセージをモバイルノードへ返してもよい。確認メッセージの送信が必要な場合（例えば、接続メッセージ４０に確認メッセージの送信リクエストが挿入されている場合）には、ローカルモビリティアンカは、確認メッセージをモバイルノードへ送信する（ステップＳ５５）。一方、確認メッセージの送信が必要ではない場合には、そのまま何もせずに処理は終了となる。

以下、より詳細に上述の方法を示す例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＬＭＡ１０１がＭＮ１１から接続メッセージ４０を受信した場合、ＬＭＡ１０１は、接続ステータスフィールド４０２をチェックして、どんなタイプの情報がメッセージに挿入されているかを判断する。

ＬＭＡ１０１が受信した接続メッセージ４０に、例えば“０”の値にセットされた“Ｍ”フラグ４０２１と共にＭＡＧ１０３の識別子を示すルータＩＤ４０２０が接続ステータスフィールド４０２に含まれているとする。この場合、ＬＭＡ１０１は、後にＭＮ１１に関するＰＢＵをＭＡＧ１０３から受信することになる旨を把握する。したがって、ＬＭＡ１０１は、このＰＢＵに関連して、このエントリに関するユニークなバインディング識別子（ＢＩＤ）を準備する。ＭＡＧ１０３から送信されたＰＢＵがＬＭＡ１０１に到着すると、ＭＮ１１のルーティングキャッシュに、準備しておいたＢＩＤを含むエントリが付加される。この結果、ＬＭＡ１０１は、ローカルモビリティドメイン１０におけるＭＮ１１のマルチホーミングをサポートし続けることが可能となる。

一方、ＬＭＡ１０１が受信した接続メッセージ４０に、例えば“１”の値にセットされた“Ｍ”フラグ４０２１と共にＭＡＧ１０２の識別子を示すルータＩＤ４０２０が接続ステータスフィールド４０２に含まれているとする。この場合、ＬＭＡ１０１は、ＭＮ１１がローカルモビリティドメイン１０内でマルチホーミングのサポートを受けたい旨を把握する。

なお、この接続メッセージ４０の受信前に、ＬＭＡ１０１は、ＭＡＧ１０３からＰＢＵを既に受信している可能性があり、このＰＢＵによって、ＭＡＧ１０３へのルーティングエントリを除くルーティングキャッシュ内のＭＮ１１に関するすべてのエントリが削除されてしまっている可能性がある。しかしながら、ＬＭＡ１０１は、接続メッセージ４０内の情報を参照することで、ＭＡＧ１０３へのルーティングエントリを削除することなく、ＭＡＧ１０２へのルーティングエントリが含まれるようにＭＮ１１に関するルーティングキャッシュを修正することが可能となる。

また、ＬＭＡ１０１は、接続メッセージ４０の受信後にＭＡＧ１０３からＰＢＵを受信した場合においても、マルチホーミングをサポートしていないモバイルアクセスゲートウェイにモバイルノードが接続されていることを考慮して、ＭＮ１１に関するルーティングキャッシュを維持することが可能となる。ルーティングキャッシュを維持するための方法としては、例えばＬＭＡ１０１が、ルーティングキャッシュをアップデートする際に、特別なＢＩＤをＭＡＧ１０３に関するエントリに割り当てる方法が挙げられる。ＬＭＡ１０１は、ＭＮ１１によるＭＡＧ１０３への接続に関するアップデートを行うためのＰＢＵを受信した場合は常に、ＭＮ１１のルーティングキャッシュに従ってＰＢＵの処理を行うように特別な配慮を行う。

また、例えば、マルチホーミングプロトコルの機能を実装するモバイルアクセスゲートウェイが、ユニークなＢＩＤを割り当てるプロセスを実行することも可能である。これは、モバイルアクセスゲートウェイがローカルモビリティアンカあてのメッセージを受信（intercept）し、マルチホーミングプロトコルの機能を有していないことが確認されているモバイルアクセスゲートウェイに関連するユニークなＢＩＤを付加することを示している。この動作が行われる場合には、ローカルモビリティアンカがレガシノード（すなわち、ルーティングキャッシュエントリに特別なＢＩＤを割り当てることができないローカルモビリティアンカ）である場合にも本発明が適用可能となるという利点がある。また、ローカルモビリティアンカによって実行される動作のロードバランスを行うために、モバイルアクセスゲートウェイにＢＩＤを割り当てる処理負荷を分散させることが可能となるという利点もある。

以下、この動作を示すより詳細な例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＩＦ１１１は、ＭＮ１１はＩＦ１１０を通じてＭＡＧ１０２と接続しており、さらに、ＩＦ１１１によってＭＡＧ１０３へ接続しようとしている。

ＭＡＧ１０３は、ＭＮ１１がＭＡＧ１０３とまもなく接続する旨を通知するための接続メッセージ４０を、ＭＡＧ１０２経由でＬＭＡ１０１へ送信するようＭＮ１１に指示する。ＭＮ１１はこの指示に従って、ＭＡＧ１０２経由でＬＭＡ１０１へ接続メッセージ４０を送信し、ＭＡＧ１０２は、例えば、パケットヘッダ４００のパケットタイプを検査することによってＭＮ１１から送信された接続メッセージ４０を特定すると、この接続メッセージ４０にＭＡＧ１０３に関するＢＩＤを付加する。そして、ＢＩＤが付加された接続メッセージがＭＡＧ１０２からＬＭＡ１０１に転送され、ＬＭＡ１０１において処理される。

さらに、別の好適な実施の形態において、ローカルモビリティアンカが、モバイルノードからの接続メッセージ４０を受信すると、確認メッセージをモバイルノードに送信してもよい。なお、確認メッセージの送信は、モバイルノードによってリクエストされてもよい。また、モバイルノードからリクエストされない場合であっても、確認メッセージの送信が行われてもよい。確認メッセージの送信が行われた場合には、ローカルモビリティアンカへの接続メッセージ４０内の情報の伝送に成功したことをモバイルノードが把握できるという利点がある。例えば、確認メッセージを受信したモバイルノードは、マルチホーミングプロトコルを実施していないモバイルアクセスゲートウェイとの間で、アクセス認証処理を開始することが可能となる。

以下、この動作を示すより詳細な例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＭＮ１１は、ＩＦ１１０を通じてＭＡＧ１０２と接続しており、さらに、ＩＦ１１１によってＭＡＧ１０３へ接続しようとしている。

ＭＡＧ１０３は、ＭＮ１１がＭＡＧ１０３とまもなく接続する旨を通知するための接続メッセージ４０を、ＭＡＧ１０２経由でＬＭＡ１０１へ送信するようＭＮ１１に指示する。ＭＮ１１は、ＬＭＡ１０１から確認メッセージを受信するまで、ＭＡＧ１０３とのアクセス認証処理を行わないよう決定し、これによって、ＬＭＡ１０１のルーティングキャッシュに矛盾が生じないようにする。一方、ＬＭＡ１０１が接続メッセージ４０の受信に成功すると、ＬＭＡ１０１は、ＭＮ１１に確認メッセージを送り返す。ＭＮ１１は、成功を示す確認メッセージを受信することで、ＭＡＧ１０３との間でアクセス認証処理を開始するようＩＦ１１１に対して指示を行うことが可能となる。

さらに、別の好適な実施の形態において、モバイルノードは、モバイルノードとアクティブな接続を有するマルチホーミングをサポートしているモバイルアクセスゲートウェイに対して、ローカルモビリティアンカへの登録メッセージの再送を依頼することも可能である。なお、本明細書では、ローカルモビリティアンカへの登録メッセージの再送をモバイルノードがモバイルアクセスゲートウェイにリクエストするためのメッセージを、再関連付けメッセージ（rebind message）と呼ぶことにする。

このように、ローカルモビリティアンカへの登録メッセージの再送を要求する理由は、例えば、ローカルモビリティアンカからの確認メッセージがモバイルノードに返されなかった場合に、モバイルアクセスゲートウェイとの間のアクセス認証処理の開始が大きく遅れてしまうからである。この場合、モバイルノードは、マルチホーミングをサポートしていないモバイルアクセスゲートウェイとの間でアクセス認証処理を開始し、次に、マルチホーミングをサポートしているモバイルアクセスゲートウェイに対して登録メッセージの再送を依頼する。このような場合は、ローカルモビリティアンカがマルチホーミングをサポートしていないモバイルアクセスゲートウェイから登録メッセージを受信した場合に、モバイルノードのマルチホーミング機能がローカルモビリティドメイン内ではサポートされていないことにより生じる。

モバイルアクセスゲートウェイから登録メッセージが再送された場合は、モバイルノードが、ローカルモビリティアンカにおけるモバイルノードのルーティングキャッシュの再構築を望んでいることを示している。さらに、モバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイとアクティブな接続を有している場合には、モバイルアクセスゲートウェイに関する登録を、マルチホーミングをサポートしているモバイルアクセスゲートウェイへ委譲することが可能である。

また、図６には、本発明の好適な実施の形態における再関連付けメッセージのフォーマットの一例が図示されている。再関連付けメッセージ６０は、パケットヘッダ６００、モバイルノード識別子（ＭＮ−ＩＤ）６０１、アシストバインディングフィールド６０２を有している。

パケットヘッダ６００は、メッセージの送信元（再関連付けメッセージの送信者）やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ６００には、例えば、送信元やあて先のＩＰｖ４アドレス又はＩＰｖ６アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

ＭＮ−ＩＤ６０１は、モバイルノードの識別子を含むフィールドであり、このモバイルノードの識別子によって、どのモバイルノードのバインディングに関してローカルモビリティアンカへの再送が必要とされているのかをモバイルアクセスゲートウェイが識別できるようになる。

また、アシストバインディングフィールド６０２は、モバイルノードが、追加バインディング情報を記載できるようにするためのフィールドである。追加バインディング情報は、モバイルノードが、ローカルモビリティアンカへの登録に関してモバイルアクセスゲートウェイの援助を受けようとしていることを示すものである。なお、例えば、アシストバインディングフィールド６０２には、１つ又は複数のルータ識別子（ルータＩＤ）６０２０が含まれていることが望ましく、このルータ識別子６０２０によって、モバイルノードは、ローカルモビリティアンカへの登録メッセージに挿入されるべき追加のモバイルアクセスゲートウェイを指定することが可能となる。

以下、より詳細に再関連付けメッセージ６０の利用例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＭＮ１１は、ＭＡＧ１０３とのアクセス認証処理を遅らせたくないので、この処理をＩＦ１１１に開始させる。また同時に、ＬＭＡ１０１へのＰＢＵの再送を依頼する再関連付けメッセージ６０をＭＡＧ１０２へ送信する。なお、ＭＮ１１は、ＬＭＡ１０１への登録を行う際にＭＡＧ１０３に関するＢＩＤの割り当てを行うようＭＡＧ１０２へ依頼するために、アシストバインディングフィールド６０２にＭＡＧ１０３の識別情報を追加する。ＭＡＧ１０２は、自身のバインディングに加えてＭＡＧ１０３のバインディングが記載されたＰＢＵをＬＭＡ１０１へ送信する。これによって、ＬＭＡ１０１は、ＭＮ１１がマルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続されていることを把握できるようになる。また、ＬＭＡ１０１は、ＭＮ１１に関するルーティングキャッシュを維持する際にマルチホーミングに関して配慮するよう注意することが可能となる。

また、別の好適な実施の形態において、モバイルノードは、再関連付けメッセージによって、ローカルモビリティドメインにおける現在のすべての登録を扱うことが可能なマルチホーミングをサポートしているモバイルアクセスゲートウェイの１つを選択することが可能である。この場合、アシストバインディングフィールド６０２には、マルチホーミングをサポートしているか否かに関係なく、モバイルアクセスゲートウェイの識別子が挿入される。

例えば、図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。ＭＮ１１は、ＭＡＧ１０３がマルチホーミングをサポートしていないことを把握し、ＭＡＧ１０３に関してＬＭＡ１０１への登録の処理を行うよう依頼する再関連付けメッセージ６０をＭＡＧ１０２へ送信する。これにより、ＭＡＧ１０２は、ＬＭＡ１０１にルーティングエントリを登録するためのＰＢＵを、ＭＡＧ１０３に代わって送信する。このエントリは、さらにＭＡＧ１０２によって割り当てられたＢＩＤが付加される。また、ＭＡＧ１０２は、ＭＮ１１がマルチホーミングをサポートしていないモバイルアクセスゲートウェイへ接続する旨をＬＭＡ１０１へ通知することが可能である。この結果、ＬＭＡ１０１は、ＭＮ１１に関するＭＡＧ１０３経由の登録処理をＭＡＧ１０２へ委譲するよう決定してもよい。

さらに別の好適な実施の形態において、ローカルモビリティアンカが、ローカルモビリティドメイン内のモバイルノードのためにマルチホーミングをサポートするために、何らかの特別な機能を実装してもよい。例えば、ローカルモビリティアンカが、モバイルノードのマルチホーミング機能を事実上サポートしていないモバイルアクセスゲートウェイからの登録メッセージを検出した場合、ローカルモビリティアンカは、モバイルノードのルーティングキャッシュを変更せず、代わりにこの新たな登録に関して一時的なエントリを作成する。同時に、ローカルモビリティアンカは、この登録メッセージによってモバイルノードに関するマルチホーミング機能が失われてしまうことが判明した場合には、モバイルノードに確認を行う。

また、別の好適な実施の形態において、ローカルモビリティアンカは、モバイルノードのルーティングキャッシュを変更する処理を行い、これによって、モバイルノードが、ローカルモビリティドメインにおけるマルチホーミング機能を失うようにすることも可能である。このとき、ローカルモビリティアンカは、ローカルモビリティドメインにおけるマルチホーミング機能が失われたことを通知するメッセージをモバイルノードに送信する。さらに、このメッセージによって、ローカルモビリティアンカがマルチホーミングをサポートしていないモバイルアクセスゲートウェイからモバイルノードの登録を受信したという原因によってモバイルノードのマルチホーミング機能が失われる旨を、モバイルノードへ通知してもよい。こうしたメッセージをローカルモビリティアンカから送信することで、モバイルノードが現在接続されているモバイルアクセスゲートウェイの機能をモバイルノードにチェックさせることができるという利点がある。なお、この場合には、モバイルノードは、例えば本発明に係る方法を利用して、ローカルモビリティドメインにおけるマルチホーミング機能の再構成（再登録処理）を行うことが可能である。

さらに、別の好適な実施の形態において、モバイルアクセスゲートウェイの機能をチェックすることで、モバイルノードが、ローカルモビリティドメイン内のモバイルアクセスゲートウェイのリストや各モバイルアクセスゲートウェイの機能に関する情報を集めることも可能である。このリストは、例えば、一定期間あるいは一定のリスト項目数だけ保持されてもよい。また、ローカルモビリティドメイン内のモバイルアクセスゲートウェイの機能を把握するために、このリストがローカルモビリティアンカに送信されてもよい。これは特に、ローカルモビリティアンカ及びモバイルアクセスゲートウェイが同一プロバイダに属していないが、同一のローカルモビリティドメイン内に共設されている場合に有用である。例えば、この一例として、セルラのオペレータ間でローミング協定が行われている場合が挙げられる。このローミング協定では、例えば、モバイルアクセスゲートウェイが、相手オペレータのモバイルノードに関するルーティングパスを相手オペレータのローカルモビリティアンカに登録することが可能である。なお、こうしたリストをローカルモビリティドメイン側（あるいは、１つ又は複数のオペレータ側）で作成してもよい。

例えば、モバイルノードは、このリストを用いて、マルチホーミングをサポートしていないモバイルアクセスゲートウェイの使用に関する優先度（プリファレンス）をローカルモビリティアンカにセットする。例えば、この一例として、モバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイへの接続を望まず、マルチホーミングをサポートしているモバイルアクセスゲートウェイだけを通知してほしいとローカルモビリティアンカに依頼する場合が挙げられる。

また、別の例として、モバイルノードが、これから接続を予定しているモバイルアクセスゲートウェイの使用に対して低い優先度をローカルモビリティアンカに設定することも可能である。この場合、モバイルノードの近傍に存在する別の適切なモバイルアクセスゲートウェイをモバイルノードが探索する動作を、ローカルモビリティアンカが支援することが可能となる。

モバイルノードのインタフェースがローカルモビリティドメイン内で移動した場合には、モバイルノードのマルチホーミング機能を確実に維持するように更なる配慮が行われる必要がある。例えば、図１において、ＭＡＧ１０２及びＭＡＧ１０３は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０４はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１のＩＦ１１０はＭＡＧ１０２に接続されており、ＭＮ１１のＩＦ１１１はＭＡＧ１０３に接続されているとする。このとき、ＭＮ１１のＩＦ１１１がＭＡＧ１０３からＭＡＧ１０４に移動を行おうとしている場合を考える。

本発明の好適な実施の形態において、ＭＮ１１がＭＡＧ１０４とまもなく接続する旨をＬＭＡ１０１へ通知した場合、ＬＭＡ１０１は、まもなく行われる接続によってどのバインディングが置き換えられるのか分からないという問題が生じる。これは特に、例えばＭＡＧ１０２とＬＭＡ１０１との間のネットワーク輻輳などの原因によって、ＭＡＧ１０２からの登録削除メッセージ（de-registration message）がＭＡＧ１０４の接続に関する登録よりも遅れてＬＭＡ１０１に届く場合に問題が生じる。このような場合を考慮して、モバイルノードは、まもなく行われる接続によってどのバインディングが置き換えられるのかをローカルモビリティアンカへ通知するためのより詳細な情報を加える必要がある。

このように接続（バインディング）を特定するために追加される情報は、例えば、ローカルモビリティアンカがモバイルノードの複数のインタフェースのそれぞれをユニークに識別できるインタフェース識別子（ＩＦ−ＩＤ）の形式にすることが可能である。ここで挙げた例の場合、ＬＭＡ１０１では、例えば、各ルーティングエントリがＭＮ１１のＩＦ−ＩＤと関連付けられる。例えば、ＭＡＧ１０２へのルーティングエントリはＩＦ１１０のＩＦ−ＩＤと関連付けられ、ＭＡＧ１０３へのルーティングエントリはＩＦ１１１のＩＦ−ＩＤと関連付けられる。ＭＮ１１は、ＩＦ１１１のＩＦ−ＩＤを使用することによって、まもなく行われるＭＡＧ１０４との接続がＩＦ１１１によって行われることをＬＭＡ１０１へ通知することが可能となる。これにより、ＬＭＡ１０１は、まもなく行われるＭＡＧ１０４との接続がＭＡＧ１０３へのルーティングエントリを置き換えるべきものであることを把握することが可能となる。

また、別の好適な実施の形態において、モバイルノードに関する各ルーティングエントリを識別するために使用される識別子（ＢＩＤ）がモバイルアクセスゲートウェイのタイプに関係なく共通のものである場合には、こうしたエントリが予定外に削除されてしまうことによって、モバイルノードがローカルモビリティアンカへのアクティブなルートをいくつか失ってしまう可能性がある。

例えば、上述のシナリオにおいて、ＩＦ１１１がＭＡＧ１０３からＭＡＧ１０４へ移動するという通知をＬＭＡ１０１が受けた場合には、ＭＡＧ１０４に関するルーティングエントリに、ＭＡＧ１０３へあらかじめ割り当てられているＢＩＤが使用されている可能性がある。このようにＢＩＤを再利用する方法は、ローカルモビリティアンカが保持しなければならないＢＩＤの数を制限する場合に一般的に用いられる。このとき、例えばネットワーク輻輳によってＭＡＧ１０３からの登録削除メッセージがＬＭＡ１０１へ届くのが遅くなった場合には、この登録削除メッセージは、既に置き換えられたルーティングエントリ（ＭＡＧ１０４へのルーティングエントリ）を削除することになる。これは、登録削除メッセージに、ＭＡＧ１０４に割り当てられたものと同一のＢＩＤが含まれていることによる。

このような状況を回避するためには、モバイルノードの各ルーティングエントリを識別するために使用するユニークなバインディング識別子（ＢＩＤ）が、異なるモバイルアクセスゲートウェイのタイプで区別されるようにする必要がある。例えば、ローカルモビリティドメインでマルチホーミングをサポートしていないモバイルアクセスゲートウェイに対しては、ＢＩＤ＃１２８以上を使用することによって区別する。

また、この問題を解決する別の実施の形態において、動作シーケンスの順序で、バインディング識別子（ＢＩＤ）が使用されるようにしてもよい。例えば、ローカルモビリティアンカは、ローカルモビリティアンカが異なるモバイルアクセスゲートウェイから受信する各登録メッセージに関して、１つずつＢＩＤのカウントを増加させる。例えば、ＭＡＧ１０２のエントリがＢＩＤ＃１を使用しており、ＬＭＡ１０１が、ＭＮ１１に関するＭＡＧ１０３からの登録メッセージを受信した場合には、このエントリ（ＭＡＧ１０３のエントリ）に対してＢＩＤ＃２を割り当てる。こうしたカウンタは、モバイルノードが一定期間動作していない場合に、最初の開始値に戻るよう再設定することが可能である。

さらに別の好適な実施の形態において、モバイルノードに関するルーティングエントリがすぐには削除されず、その代わり、ある期間経ってから削除されるようにマークが付されてもよい。ルーティングキャッシュから削除されることを示すマークが付されると、このルーティングエントリにはタイマが設定される。タイマが満了した場合には、このルーティングエントリはルーティングキャッシュから完全に削除される。

このリカバリ動作は、モバイルノードが予定外に削除されてしまったバインディングを復元させたいと望む場合に有用である。例えば、ローカルモビリティアンカにおいて、マルチホーミング機能をサポートしていないモバイルアクセスゲートウェイからの登録メッセージを受信することによって、モバイルノードに関するルーティングキャッシュ内のエントリが削除されてしまう場合が挙げられる。この場合、モバイルノードは、リカバリメッセージを送って、削除されたモバイルノードに関するすべてのルーティングエントリ（あるいは、所望のマルチホーム状態を得るために復元が必要な特定のルーティングエントリ）を元に戻すようローカルモビリティアンカに依頼する。このリカバリメッセージは、ローカルモビリティアンカへ送信される任意のメッセージに挿入されたフラグとして実現されてもよい。

図７には、本発明の好適な実施の形態において、リカバリ動作をサポートするルーティングキャッシュの一例が図示されている。なお、本発明を実現する任意のエンティティ（モバイルノードやローカルモビリティアンカなど）内に当該ルーティングキャッシュの機能を配置することが可能である

通常、ルーティングキャッシュ７０はモバイルノードの識別子（ＭＮ−ＩＤ）欄７１、バインディング識別子（ＢＩＤ）欄７２、気付アドレス（ＣｏＡ）欄７３、パス欄７４、非動作タイマ欄７５を有している。

ＭＮ−ＩＤ欄７１は、通常、ローカルモビリティドメインで使用するためにモバイルノードに割り当てられたプレフィックスを有している。また、ＢＩＤ欄７２も通常、モバイルノードの異なるルーティングエントリを区別するために使用されるユニークなバインディング識別子を有している。また、ＣｏＡ欄７３は、モバイルノードが接続されているモバイルアクセスゲートウェイの気付アドレスを識別するものである。以上の情報によって、モバイルノードへのパケットのルーティングが可能となる。

本発明では、パス欄７４によって、エンティティは、そのルーティングがローカルモビリティドメイン内でまだアクティブであるか否かを把握することが可能である。パス欄７４においてエントリが“無効”とマークされている場合には、このルーティングパスは使用不可能であることを示している。一方、エントリが“有効”とマークされている場合には、このルーティングパスは使用可能であることを示している。また、非動作タイマ欄７５は、エンティティに対して、ルーティングパスがルーティングキャッシュから完全に消去されてしまうまでの残り時間を通知するための情報を含んでいる。非動作タイマ欄７５は通常、パス欄７４が“非動作”を示す場合に設定される。

以下、上述の本発明に係るリカバリ動作の一例について説明する。図７において、ＬＭＡ１０１は、マルチホーミングをサポートしていないモバイルアクセスゲートウェイ（ＭＡＧ１０４）から登録メッセージを受信した場合に、図７に示すルーティングキャッシュを構築する。この登録メッセージを受信した場合、ＭＡＧ１０２とＭＡＧ１０３の両方のエントリがＬＭＡによって削除対象としてマークされる。これによって、ＬＭＡ１０１が両方のエントリを“非動作”とし、それらのエントリに、ルーティングキャッシュから完全に削除されるまでタイマ（例えば６０分）をセットする。

一方、ＭＮ１１は、ＩＦ１１０がＭＡＧ１０２との接続を失っていることを発見し、ＬＭＡ１０１のルーティングキャッシュに何らかの問題が生じていることを把握する。ＭＮ１１は、ＬＭＡ１０１とＭＡＧ１０２との間のルーティングパスを再構成するため、非動作バインディングの回復を依頼するリカバリメッセージをＬＭＡ１０１へ送信する。このリカバリメッセージを受信したＬＭＡ１０１は、ＭＡＧ１０２及びＭＡＧ１０３の両方のエントリを回復するために“アクティブ”のマークを付ける。なお、ＬＭＡ１０１は、“アクティブ”の状態に戻す前に、ＭＡＧ１０２及びＭＡＧ１０３に対して、どのエントリがまだアクティブかを判断するための問い合わせを行うことが可能である。あるいは、ＭＮ１１がＬＭＡ１０１へのリカバリメッセージ内にどのエントリ（この場合には、ＭＡＧ１０２に関するエントリ）の回復を望んでいるかを記載し、このエントリのみを“アクティブ"の状態に戻すことも可能である。

また、本発明の別の実施の形態において、モバイルノードと、ローカルモビリティドメイン内のＡＡＡ（認証、許可、課金）サーバとの間におけるＡＡＡ処理期間中に、本発明に係る情報（の一部）が送信されてもよい。例えば、モバイルノードは、ローカルモビリティドメイン内でマルチホーミングのサポートを望んでいることをＡＡＡサーバに通知してもよい。このモバイルノードからの要望は、ＡＡＡサーバからモバイルノードのルーティングキャッシュを取り扱っているローカルモビリティキャッシュへ渡される。これにより、ローカルモビリティアンカは、モバイルノードのマルチホーミング機能を削除してしまうような登録メッセージを受信した場合に、更なる動作を行って、マルチホーミング機能が中断されないようにすることが可能である。なお、ローカルモビリティアンカによって行われるこうした動作は、本発明の方法に従って行われることが望ましい。

また、モバイルノードがＡＡＡ処理の間に、モバイルアクセルゲートウェイ及びその機能のリストに関するリクエストを行うことも可能である。これにより、モバイルノードは、接続するためのマルチホーミングをサポートしているモバイルアクセスゲートウェイを検索することが可能となる。例えば、モバイルノードのインタフェースの１つがマルチホーミングをサポートしていないモバイルアクセスゲートウェイを発見した場合には、モバイルノードは、ローカルモビリティドメインでのマルチホーミング機能を維持するために、そのインタフェースに対して、そのモバイルアクセスゲートウェイと接続を行わないように指示する。

次に、本発明を実現可能とする装置について説明する。図８は、本発明の好適な実施の形態におけるモバイルノードの機能アーキテクチャの一例を示すブロック図である。図８において、モバイルノードの機能アーキテクチャ８０は、ネットワークインタフェース８００、アプリケーション８０１、データベース８０２、機能チェックエンジン８０３、ルータバインディングエンジン８０４により構成されている。

ネットワークインタフェース８００は、任意の通信媒体を介して別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。関連する周知の技術用語を用いた場合、ネットワークインタフェース８００は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルなどを表している。なお、図８にはネットワークインタフェース８００が１つのみ図示されているが、モバイルノードは１つ又は複数のネットワークインタフェース８００を有していてもよい。

また、シグナル／データパス８１０を介して、ネットワークインタフェース８００と機能チェックエンジン８０３とが相互に通信を行うことが可能であり、トリガ／パケットが伝送可能となる。例えば、ネットワークインタフェース８００で受信したルータ機能メッセージ２０は、シグナル／データパス８１０を通じて機能チェックエンジン８０３に伝送され、これにより、機能チェックエンジン８０３は、特定のモバイルアクセスゲートウェイに関する機能を特定することが可能となる。

また、シグナル／データパス８１６を介して、ネットワークインタフェース８００とルータバインディングエンジン８０４とが相互に通信を行うことが可能であり、トリガ／パケットが伝送可能となる。例えば、接続メッセージ４０は、ルータバインディングエンジン８０４からネットワークインタフェース８００へ伝送され、ネットワークインタフェース８００からローカルモビリティドメイン内のエンティティへ送信可能となる。

また、アプリケーション８０１は、通信プロトコルスタックのネットワークレイヤの上位に位置するプロトコルやプログラムを包含する機能ブロックを示している。このアプリケーション８０１は、例えば、トランスポートセッションプロトコル（ＴＣＰ：Transmission Control Protocol）、ストリーム制御トランスポートプロトコル（ＳＣＴＰ：Stream Control Transport Protocol）、ユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）や、他のノードとの通信に必要なプログラム及びソフトウェアなど、任意のトランスポートレイヤプロトコル又はセッションレイヤを有している。なお、図８にはアプリケーション８０１が１つのみ図示されているが、モバイルノードは１つ又は複数のアプリケーション８０１を有していてもよい。

また、シグナル／データパス８１１を介して、アプリケーション８０１とルータバインディングエンジン８０４とが相互に通信を行うことが可能であり、トリガ／パケットが伝送可能となる。例えば、アプリケーション８０１はシグナル／データパス８１１を介して、ネットワークインタフェース８００近傍に存在する特定のモバイルアクセスゲートウェイの機能情報をリクエストするようルータバインディングエンジン８０４をトリガする。

また、データベース８０２は、モバイルノードによって必要とされる情報の格納を行うことが可能である。なお、データベース８０２は、例えば、加入者ポリシ８０２０、ルーティングキャッシュ８０２１、ルータデータベース８０２２によって構成可能である。

加入者ポリシ８０２０は、通常、特定のサービスの加入者に関する情報を有している。例えば、特定のサービスの加入者に関する情報として、ローカルモビリティドメインに接続している際にモバイルノードを識別するために使用されるモバイルノード識別子（ＭＮ−ＩＤ）を用いることが可能である。ルータバインディングエンジン８０４は、接続メッセージ４０を作成する際、シグナル／データパス８１２を介して、加入者ポリシ８０２０からＭＮ−ＩＤを参照することが可能である。

また、ルーティングキャッシュ８０２１は、ローカルモビリティドメイン内でモバイルノードが維持しているモバイルアクセスゲートウェイとのアクティブな接続に関するエントリを有している。ルータバインディングエンジン８０４は、ローカルモビリティドメインにおけるモバイルノードのマルチホーミング機能を再確立するための接続メッセージ４０を作成する際、シグナル／データパス８１３を介して、ルーティングキャッシュ８０２１に格納されているすべての接続に関する情報を検索する。

また、ルータデータベース８０２２は、ローカルモビリティドメインのモバイルアクセスゲートウェイに関する情報を有している。例えば、すべてのモバイルアクセスゲートウェイ及びそれらの対応する機能のリストが、ルータデータベース８０２２に格納される。機能チェックエンジン８０３は、シグナル／データパス８１４を介して、ローカルモビリティドメイン内に存在するモバイルアクセスゲートウェイ及びそれらの対応する機能に関する情報をルータデータベース８０２２にアップデートすることが可能である。

本発明の実施の形態では、機能チェックエンジン８０３が、ルータ機能メッセージ２０に含まれる機能情報を受信する機能情報受信部として動作し、モバイルアクセスゲートウェイがマルチホーミングをサポートしているか否かをルータ機能メッセージ２０から判断することが可能である。ルータ機能メッセージ２０から判断されるモバイルアクセスゲートウェイの機能情報は、ルータデータベース８０２２に格納される。なお、機能チェックエンジン８０３は、任意の方法（例えば、ファストモバイルＩＰ）を用いて、まもなく接続しようとしているローカルモビリティアンカの機能情報を取得してもよい。

機能チェックエンジン８０３は、モバイルアクセスゲートウェイの機能情報に従って、シグナル／データパス８１５を介して、ルータバインディングエンジン８０４が行うべき適切な動作をトリガすることが可能である。例えば、モバイルアクセスゲートウェイがマルチホーミングをサポートしているのであれば、機能チェックエンジン８０３は、通常の処理と同様に、ルータバインディングエンジン８０４に対してアクセス認証処理を開始するよう依頼する。しかしながら、モバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、機能チェックエンジン８０３は、例えば、ルータバインディングエンジン８０４に対して、まもなく行われる接続をローカルモビリティドメイン内のエンティティに通知するための接続メッセージ４０を準備するよう依頼する。

また、本発明の実施の形態では、モバイルノードがローカルモビリティドメイン内でマルチホーミング機能を確実に維持できるようにするために、ローカルモビリティドメイン内のエンティティに対して確実に通知が行われるようにする目的で、ルータバインディングエンジン８０４が導入される。ルータバインディングエンジン８０４は、マルチホーミング機能を確実に維持できるようにするための情報として、モバイルノードが接続しているローカルモビリティアンカの機能情報をローカルモビリティドメイン内のエンティティへ通知する機能情報通知部の機能を実現する。さらに、ルータバインディングエンジン８０４は、この通知とともに、処理結果を要求する確認メッセージの生成及び送信を行う確認要求部としても機能する。

本発明の実施の形態においては、マルチホーミング機能を確実に維持できるようにするための情報は、接続メッセージ４０によって通知される。この通知により、ローカルモビリティドメイン内のエンティティは、モバイルノードがマルチホーミング機能をサポートしていないモバイルアクセスゲートウェイにまもなく接続しようとしていることや、ローカルモビリティドメイン内のモバイルアクセスゲートウェイを経由するモバイルノードのすべてのアクティブな接続に関して把握できるようになる。

また、ルータバインディングエンジン８０４は、ローカルモビリティドメイン内のエンティティへ通知するための様々なメッセージ（モバイルノードの接続に関するルーティング情報の再構築を要求するメッセージ、モバイルノードのマルチホーム状態を再構成するための情報を通知するメッセージモバイルノードのルーティングエントリが削除されたと判断できる場合にそのルーティングエントリの復元を要求するメッセージなど）の生成及び送信を行う機能も有している。

なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各装置の構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明らかである。例えば、モバイルルータが図８に図示されている機能アーキテクチャを実装してもよい。これにより、モバイルルータは、ローカルモビリティドメイン内に位置している間は、モバイルネットワーク内のノードに関するマルチホーミングのサービスを維持することが可能となる。

また、当業者であれば、モバイルノードが最初マルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続している際、マルチホーミングをサポートしたモバイルアクセスゲートウェイが別のインタフェースで検出され、ローカルモビリティドメイン内でマルチホーミングを使用しようとする場合においても、本発明が適用可能であることは明らかである。この場合も、マルチホーミングをサポートしているモバイルアクセスゲートウェイからの登録メッセージが、マルチホーミングをサポートしていないモバイルアクセスゲートウェイのルーティングエントリを削除することで、同様の問題が生じる。このとき、モバイルノードはローカルモビリティドメイン内でマルチホーミングのサポートを所望している旨をローカルモビリティアンカに通知する本発明に係る方法を使用することが可能である。

さらに、当業者であれば、本発明に係る方法が、各インタフェースにおいてそれぞれ異なるタイプのモビリティプロトコルを実装しているモバイルノードに関しても有用であることが明らかである。例えば、このような場合の一例として、あるインタフェース（ＩＦ１）が、非特許文献１で説明されるようなモバイルＩＰｖ６プロトコルに関連付けられており、別のインタフェース（ＩＦ２）が非特許文献４で説明されるような拡張モバイルＩＰｖ６プロトコルに関連付けられている場合が挙げられる。この場合には、ＩＦ１からの登録メッセージによって、同一ホームエージェントに存在するＩＦ２からの登録エントリが削除されてしまう可能性がある。この場合には、モバイルノードは、モバイルノードのマルチホーミングを維持するための詳細な情報をホームエージェントに提供する前に、各インタフェースにおける機能（各インタフェースが接続しているモバイルアクセスゲートウェイの機能）の問い合わせを行ってもよい。なお、アドレス体系の差異を各ノードで整合させる必要があるが、ＩＰｖ４アドレス（モバイルＩＰｖ４プロトコルやプロキシモバイルＩＰｖ４プロトコル）との混在や、プレフィックス登録（ネットワークプレフィックスを登録の対象とする）の技術との混在においても、登録するアドレス（プレフィックス）情報のビット長や、対応するアドレスとの関連付けなどの実装の変更を行えば、有用であることは明らかである。

また、本明細書では、モバイルノードのネットワークインタフェースが複数であることを前提に説明を行っている部分があるが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。

また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、モバイルアクセスゲートウェイがモバイルノードの直接的なアクセスルータである構成や、モバイルアクセスゲートウェイが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるモバイルアクセスゲートウェイに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータやモバイルノードからモバイルアクセスゲートウェイへの到達手順、モバイルノードの通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。

また、上述の実施の形態では、ローカルモビリティ管理の環境であることが仮定されているが、モバイルルータ（ＭＲ：Mobile Router）（及びその配下のノード）により構成されたモバイルネットワーク（Mobile Network)（若しくは階層化されたモバイルネットワーク）に本発明を適用することも可能である。

例えば、モバイルネットワークの構成方法の１つであるＮＥＭＯ（NEtwork Mobility)はＭＲがＨＡ（Home Agent）に移動ネットワーク（及びモバイルノード）の移動登録を行うことにより、移動端末に対するモビリティサポートを提供しているが、本明細書におけるモバイルノードがＭＲに対応する形で適用可能である。この場合、ローカルモビリティアンカはＭＲのＨＡに対応すると考えることができる。さらに、ＰＭＩＰを用いたネットワークを提供するネットワークオペレータがローミング関係などにより、ＰＭＩＰで構成しているモバイルアクセスゲートウェイ≡ローカルモビリティアンカ間のトンネルを多段に用いるような場合は階層化されたモバイルネットワークに相当する。

さらに、オーバレイネットワークの環境に本発明を適用することも可能である。例えば、モバイルアクセスゲートウェイによるモバイルノードに対するモビリティサポートをｐＨＡ（Proxy HA）に対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはローカルモビリティアンカに対応すると考えることができる。

また、モバイルノードは複数の通信デバイスから構成されるものであってもよく、例えばパーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュールや非３ＧＰＰ通信デバイスモジュールを装着する場合などがあり、こうした多様なモバイルノードにおいても本発明は同等の効果を有するものである。

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

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

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

本発明は、パケット交換型データ通信ネットワークシステムにおける通信技術に適用可能であり、特に、ネットワークベースのモビリティ管理技術やモバイルノードのマルチホーミング機能を実現するための技術に適用可能である。

本発明は、パケット交換型データ通信ネットワークシステムにおける通信技術に関する。本発明は、特に、マルチホーミング機能を有するモバイルノードがローカルモビリティドメインに接続している場合に、マルチホーミングのサービスを受けることができるようにするための移動端末及びネットワークノードに関する。

下記の非特許文献１に記載のモバイルＩＰｖ６（ＭＩＰｖ６）によれば、移動端末（ＭＮ：Mobile Node、モバイルノード）は、インターネットへの接続ポイントを変更する場合にインターネットプロトコル（ＩＰ）アドレスを変更せずに維持することが可能である。

このＭＩＰｖ６において変更されることのないＩＰアドレスは、モバイルノードのホームネットワークドメインにおけるアドレスであり、ホームアドレス（home address）と呼ばれている。モバイルノードが外部（foreign）ネットワークドメインに接続されている間は、モバイルノードは、外部ネットワークドメインによって通知されるサブネットプレフィックスから、使用すべきＩＰアドレスを構成することが可能である。このように構成されたＩＰアドレスは、気付アドレス（care-of address）と呼ばれ、モバイルノードはこのアドレス経由でも到達可能となる。

モバイルノードは、その接続位置によらずに到達可能性を維持するため、気付アドレスとホームアドレスとを関連付けてホームエージェントに登録する。ＭＩＰｖ６では、ホームエージェントは、モバイルノードのホームネットワークドメイン内のルータであり、モバイルノードの現在の気付アドレスとそのホームアドレスのバインディングを登録する。これは、モバイルノードがバインディングアップデート（ＢＵ：Binding Update）メッセージをホームエージェントへ送信することによって実現される。モバイルノードがホームネットワークドメインから離れている場合には、ホームエージェントは、モバイルノードのホームアドレスあてのパケットを受信（intercept）し、関連付けられた気付アドレス経由で受信したパケットをモバイルノードへ向けトンネルする。上述のＭＩＰｖ６の説明から分かるように、ＭＩＰｖ６では、ホスト（モバイルノード）がモビリティ管理を行う。したがって、ＭＩＰｖ６は、ホストベースのモビリティ管理プロトコルとしても知られている。

一方、モバイルノードがローカルモビリティドメインを移動している際に、モビリティ関連シグナリングを行わないですむ別のモビリティ管理方式が存在する。このモビリティ管理方式では、ローカルモビリティドメイン内に存在するプロキシエンティティが、モバイルノードのモビリティ管理を行う。こうしたモビリティ管理方式は、ネットワークベースのモビリティ管理と呼ばれ、例えば、下記の非特許文献２に記載されている。

ローカルモビリティドメイン内を移動するモバイルノードは、アクセス認証処理の過程で、モバイルノードの識別情報（ＭＮ−ＩＤ）を提示することによって、プロキシエンティティ）に接続する。このプロキシエンティティは、例えば、非特許文献２に記載されているＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）である。ＭＮ−ＩＤは、ローカルサーバから取得可能なモバイルノードのポリシプロファイルを関連付けるために用いられる。ポリシプロファイルには、提供されるネットワークベースのモビリティサービスの特性やその他の関連するパラメータ（例えば、モバイルノードに割り当てられるネットワークプレフィックス（例えばMN.Prefix）、許可されているアドレス構成モード、移動ポリシ、ネットワークベースのモビリティサービスを提供するために不可欠なその他のパラメータなど）が含まれている。

モバイルアクセスゲートウェイは、アクセス認証に成功した後、ローカルサーバからモバイルノードのポリシプロファイルを取得する。これは、モバイルアクセスゲートウェイが、モバイルノードに関するモビリティシグナリングを実行するために必要なすべての情報を把握できることを意味する。したがって、モバイルアクセスゲートウェイは、モバイルノードのネットワークプレフィックス（MN.Prefix）を通知するルータ通知を周期的にモバイルノードへ送信する。モバイルノードは、MN.Prefixを参照すると、ローカルモビリティドメインに接続されているインタフェースに対して、通信を行うためのＩＰアドレス（例えば、ホームアドレス）を構成する。モバイルノードがローカルモビリティドメイン内のどの場所を移動しても、接続インタフェースは、常にMN.Prefixを参照することが可能である。これは、モバイルノードが接続する各モバイルアクセスゲートウェイが常にローカルサーバに問い合わせを行って、モバイルノードのプロファイルを取得することによる。その結果、モバイルノードは、ローカルモビリティドメインのどの位置に接続している場合であっても、通信を行うために、常に最初に構成されたＩＰアドレスを使用することが可能となる。

このネットワークベースのモビリティ管理を実現するため、ローカルモビリティアンカ（ＬＭＡ：Local Mobility Anchor）と呼ばれるエンティティが、ローカルモビリティドメイン内の各モバイルノードに対して論理的なアンカポイントとして機能する。さらに、ローカルモビリティアンカは、各モバイルノードに関する到達可能状態の管理を行う。したがって、ローカルモビリティアンカは、非特許文献１に記載のホームエージェントと類似していると言える。各モバイルノードに関するアンカポイントとして機能するために、ローカルモビリティアンカには、各モバイルノードの現在位置がアップデートされる必要がある。したがって、モバイルノードがモバイルアクセスゲートウェイに接続する際は常に、モバイルアクセスゲートウェイは、プロキシバインディングアップデート（ＰＢＵ：Proxy binding Update）メッセージをローカルモビリティアンカへ送信する。このＰＢＵメッセージによって、MN.Prefixとモバイルアクセスゲートウェイの気付アドレスとの関連付けが行われる。そして、このバインディングによって、ローカルモビリティアンカは、適切なモバイルアクセスゲートウェイ経由でパケットをモバイルノードに発送することが可能となる。

図１には、上述のようなネットワークベースのモビリティ管理に用いられるシステムの一例が図示されている。図１では、ローカルモビリティドメイン１０は、ローカルモビリティアンカ（ＬＭＡ）１０１と複数のモバイルアクセスゲートウェイ（ＭＡＧ）１０２、１０３、１０４を有している。モバイルノード（ＭＮ）１１は、アクセス認証処理の過程でその識別情報（ＭＮ−ＩＤ）を提示して、モバイルアクセスゲートウェイ（ＭＡＧ）１０２とインタフェース（ＩＦ）１１０を接続する。

アクセス認証に成功した後、ＭＡＧ１０２は、ＭＮ１１のＭＮ−ＩＤに基づいて、ローカルサーバからＭＮ１１のポリシプロファイルを取得する。これは、ＭＡＧ１０２が、ＭＮ１１に関するモビリティシグナリングを実行するために必要なすべての情報を把握できることを意味する。したがって、ＭＡＧ１０２は、モバイルノードのネットワークプレフィックス（MN.Prefix）を通知するルータ通知を周期的にＭＮ１１へ送信する。ＭＮ１１は、このMN.Prefixを参照すると、通信に用いられるＩＦ１１０のＩＰアドレスを構成する。ＭＮ１１がローカルモビリティドメイン１０内のどの位置に移動するかに関係なく、ＩＦ１１０は、常に同一の割り当てられたネットワークプレフィックスを参照することができる。これは、ＭＮ１１が接続する各モバイルアクセスゲートウェイが、常にローカルサーバからＭＮ１１のプロファイルを検索することによる。例えば、ＭＮ１１がＭＡＧ１０３へ移動してＩＦ１１０によって接続を行う場合、ＭＡＧ１０３は、認証処理の間に提示されるＭＮ−ＩＤに基づいて、ＭＮ１１に割り当てられるネットワークプレフィックスをローカルサーバから取得する。したがって、ローカルモビリティドメイン１０内のＭＮ１１の位置によらず、ＭＮ１１は、通信を行うために、常に同一のＩＰアドレスを使用することが可能となる。

上述のように、ＬＭＡ１０１は、各モバイルノードに対して論理的なアンカポイントとして機能するとともに、各モバイルノードの到達可能状態も管理する。各モバイルノードのアンカポイントであるため、ＬＭＡ１０１には、各モバイルノードの現在位置についてアップデートされる必要がある。したがって、モバイルノードがモバイルアクセスゲートウェイに接続する際はいつも、モバイルアクセスゲートウェイは、プロキシバインディングアップデート（ＰＢＵ）メッセージをＬＭＡ１０１へ送信する。このＰＢＵによって、ＬＭＡ１０１は、モバイルノードのユニークな識別情報（ＭＮ−ＩＤ）に基づいて、モバイルノードに関するルーティングエントリを作成することができるようになる。ＬＭＡ１０１は、このルーティングエントリにおいて、モバイルノードに割り当てられたネットワークプレフィックスを、モバイルアクセスゲートウェイの気付アドレスと関連付ける。このバインディングによって、ＬＭＡ１０１は、適切なモバイルアクセスゲートウェイを通じてパケットをモバイルノードに発送することができる。ＬＭＡもまた一種のルータであり、バインディング登録によりバインディングエントリ（単にバインディングと呼ぶこともある）を生成する。ＬＭＡがパケットをルーティングする際にはルーティングエントリを参照し、パケットを送信するが、そのルーティングエントリの１つとしてバインディングエントリを参照することが可能である。なお、ルーティングエントリは、その他のルーティングプロトコルによっても生成されるため、同様の仕組みとして、バインディングエントリからルーティングエントリを明示的に生成することも可能である。本明細書においては、バインディング登録に基づくものをバインディングエントリ、ルーティングの際に参照する場合にはルーティングエントリとして説明する場合があるが、上述のように、実施の上での区別は当業者の任意の実装に依存するものであり、バインディングエントリとルーティングエントリの読み替えや、バインディングエントリからルーティングエントリの生成を前提とすることができる。

図１において、ＭＮ１１は、ＩＦ１１０を使用してＭＡＧ１０２と接続し、必要な認証処理を実行する。認証に成功した後、ＭＡＧ１０２は、ＰＢＵをＬＭＡ１０１へ送信する。ＬＭＡ１０１は、このＰＢＵの内容に基づいて、バインディングキャッシュにおいて、モバイルノードのホームネットワークプレフィックス又はホームアドレスを、ＭＡＧ１０２の気付アドレスと関連付ける。ＬＭＡ１１０がＭＮ１１のホームアドレスあてのパケットを受信した場合には、ＬＭＡ１１０は、バインディングキャッシュをチェックして、パケットのルーティングパスを調べる。ここでは、ＬＭＡ１１０は、このパケットがＭＮ１１あてであることを特定し、バインディングキャッシュのエントリに基づいてＭＡＧ１０２にパケットをトンネルし、ＭＡＧ１０２はＭＮ１１へパケットを転送する。

近年、ネットワークベースのモビリティ管理方式において、マルチインタフェースを有するモバイルノードからの同時アクセスのサポートに関する議論が行われてきた。ここでは主に、現在の携帯電子機器に複数のネットワークインタフェースが組み込まれることから、所定のホームアドレスに対して複数の気付アドレスを登録する機能を導入することに関して議論されてきた。以下、この技術を、モバイルノード／ルータが実現するマルチホーミング機能と呼ぶことにする。この議論の過程において、非特許文献２が改訂され、ローカルモビリティアンカがマルチホーミングをサポートするために考慮すべき問題に関して言及された。この改訂版は下記の非特許文献３として発行されている。

また、下記の非特許文献４には、複数の気付アドレスの登録を行うための方法が説明されている。この方法は、ＢＩＤ（Binding Unique Identification）と呼ばれる識別番号を使用して、あるホームアドレスに対して関連付けられている複数のバインディングの識別を行う。ＢＩＤは、モバイルノード／ルータのホームアドレスに関連付けられたインタフェース又は気付アドレスに割り当てられている。したがって、ホームアドレスは、モバイルノード／ルータ自体に関連付けられている一方、ＢＩＤは、モバイルノードによって登録された同時アクセスによる各バインディングを識別する。モバイルノードは、バインディングアップデート（ＢＵ）メッセージを使用して、ホームエージェントにＢＩＤを通知し、ホームエージェントは、ＢＩＤをそのバインディングキャッシュに記録する。また、モバイルノード／ルータがプリファレンスをホームエージェントに設定し、複数の気付アドレスを通じたトラフィックフローの選択的なルーティングを行えるようにすることも可能である。

また、下記の非特許文献５には、非特許文献４の技術を用いてモバイルノードがマルチホーミングを行う際にローカルモビリティドメイン内で発生する問題に基づいて分析が行われている。ここでは、ローカルモビリティアンカにおいて何らかの機能が欠けており、ローカルモビリティドメインがマルチホーミングをサポートできない場合の問題が注目されており、非特許文献３及び非特許文献４の技術の統合が考察されている。

ここで、セルラのオペレータが非特許文献３及び非特許文献４の両方の技術をシステムに導入する場合を考える。第３世代パートナーシッププロジェクト（３ＧＰＰ：Third Generation Partnership Project ）から発展した第４世代（４Ｇ）移動通信技術が、セルラネットワークのオールＩＰシステム化を目指していることは想像に難くない。また同様に、オールＩＰシステムは、国際モバイルテレコミュニケーションズ−２０００（ＩＭＴ−２０００：International Mobile Telecommunications-2000）プロジェクトの第３世代パートナーシッププロジェクト２（３ＧＰＰ２）においても研究されている。これらのプロジェクトでは、ほとんどのセルラのオペレータが、モバイル通信の迅速性及び容易性を向上させる目的を達成するという条件を満たす候補として、非特許文献３で説明されている技術を考慮している。また、非特許文献３ではローカルモビリティドメインにおけるマルチホーミングのサポートに言及されているので、将来、セルラネットワークはマルチホーミングをサポートする可能性が高いと思われる。さらに、非特許文献３に開示されている技術は、こうしたシステム内でデータのロードバランシングを実行する手段を実現することが可能であり、セルラのオペレータがマルチホーミングをサポートできるという利点がある。

例えば、図１において、ＭＮ１１のＩＦ１１０及びＩＦ１１１の両方のインタフェースが同時にローカルモビリティドメイン１０に接続されているとする。ここでは、ＩＦ１１０はＭＡＧ１０２に接続されており、ＩＦ１１１はＭＡＧ１０３に接続されているとする。これらの接続は両方共、ＬＭＡ１０１に登録される。ＬＭＡ１０１は、ＭＮ１１あてのパケットが届くと、ローカルモビリティドメイン１０のネットワーク条件に基づいて、ＭＡＧ１０２又はＭＡＧ１０３のどちらかを経由してＭＮ１１へパケットを転送するよう選択することが可能である。ＭＡＧ１０２がパケット処理に関して過負荷である場合には、ＬＭＡ１０１は、ＭＮ１１あてのパケットをＭＡＧ１０２に送信する代わりに、ＭＡＧ１０３経由で転送することが可能である。これにより、ＭＡＧ１０２の処理負荷が低減されるようになる。このように、ローカルモビリティドメイン内でマルチホーミングをサポートする利点として、ローカルモビリティアンカによって負荷バランシングが実行できることが挙げられる。

セルラのオペレータがシステム内でマルチホーミングのサポートを行うよう設定した場合には、注意すべき点が生じるかもしれない。注意すべき点の１つは、マルチホーミングをサポートする際にローカルモビリティアンカが過負荷な状態にならないようにすることである。ローカルモビリティアンカは、ローカルモビリティドメイン内でパケット発送に関する主要装置として動作しており、モバイルノードへの複数のルーティングパスを同時に扱う場合には比較的簡単な構成とすることが望ましい。また、別の注意すべき点として、モバイルアクセスゲートウェイがマルチホーミングをサポートするための複雑な機能を使用する必要はないことが挙げられる。モバイルアクセスゲートウェイが、例えば非特許文献４に記載の技術に従って、マルチホーム状態のモバイルノードのサポートを行えるようにすることが望ましい。

ＩＥＴＦ（Internet Engineering Task Force）における現在の作業では、ネットワークベースのモビリティ管理に関するマルチホーミングは、今後作業すべき事項と考えられている。ネットワークベースのモビリティ管理に関する基本プロトコルが完全に構築された場合に、この作業事項が調べられることになる。したがって、セルラのオペレータは、まず基本的なネットワークベースのモビリティ管理方式を配備して、その後、システムにマルチホーミングのサポートを統合する可能性が高い。セルラのオペレータは、この機能の統合に際してシステムを試行するので、最初、マルチホーム状態のモバイルノードをサポートするモバイルアクセスゲートウェイと、マルチホーム状態のモバイルノードをサポートしないモバイルアクセスゲートウェイとがシステムに混在することが予想される。さらに、マルチホーミング機能の利用に際して、各モバイルアクセスゲートウェイに関してライセンス料が徴収される場合には、オペレータは、いくつかのモバイルアクセスゲートウェイのみがマルチホーミング機能を有するようにすることで、維持費を最小限に抑えることが可能となる。

また、セルラのオペレータすべてが必ずしもシステム内でマルチホーミングのサポートを行うことを望んでいないこともあり得る。セルラのオペレータは、特定の地域に対する消費者市場に基づき、その消費者の大半がマルチホーミング機能を使用しないと判断した場合には、マルチホーミングサポートを配備しない可能性がある。このような環境で、特に、オペレータ間のローミング協定が存在する場合は、マルチホーム状態のモバイルノードが、マルチホーミングをサポートするモバイルアクセスゲートウェイ及びマルチホーミングをサポートしないモバイルアクセスゲートウェイに同時に接続することになる可能性がある。

米国特許公開２００７／０２５４６７７

D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. 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. S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", Internet Engineering Task Force Internet Draft: draft-ietf-netlmm-proxymip6-07.txt, November 04, 2007. R. Wakikawa, T. Ernst and K. Nagami, "Multiple Care-of Addresses Registration", Internet Engineering Task Force Internet Draft: draft-ietf-monami6-multiplecoa-00.txt, June 12, 2006. M. Jeyatharan, C. Ng and J. Hirano, "Multiple Interfaced Mobile Nodes in NetLMM", Internet Engineering Task Force Internet Draft: draft-jeyatharan-netlmm-multi-interface-ps-00.txt, September, 2007.

上述のように、マルチホーム状態のモバイルノードが、マルチホーミングをサポートするモバイルアクセスゲートウェイ及びマルチホーミングをサポートしないモバイルアクセスゲートウェイに同時に接続する場合には、マルチホーム状態のモバイルノードに関するバインディングエントリがローカルモビリティアンカで失われてしまう可能性がある。バインディングエントリが無くなる理由は、非特許文献４に述べられているように、モビリティアンカポイント（例えばホームエージェント）がマルチホーム状態のモバイルノードに関する複数のバインディングエントリを保持しており、ＢＩＤを含まないバインディング登録を受信した場合には、保持しているすべてのバインディングエントリは消去するとともに新たに受信したＢＩＤを含まないバインディング登録で置き換えてしまうことによる。また、モビリティアンカポイントがマルチホーム状態のモバイルノードに関してバインディングエントリを１つ維持しており、ＢＩＤを有するバインディング登録を受信した場合も同様に、保持していたバインディングエントリが、ＢＩＤを有する受信バインディング登録のバインディングエントリで置き換えられてしまうことになる。その結果、モバイルノードはマルチホーム状態を失うことになり、マルチホーム状態のモバイルノードに関するサービスエクスペリエンスの低減を引き起こすことになる。

以下、図１を参照しながら、この問題について説明する。図１において、ローカルモビリティドメイン１０はマルチホーミングをサポートするエンティティを有している。ＬＭＡ１０１は、マルチホーム状態のモバイルノードに関するバインディングの処理方法を把握している。また同様に、ＭＡＧ１０２はマルチホーミングのサポート機能を有している。この場合、ＭＡＧ１０２は非特許文献４に記載されている技術を実行する。一方、ＭＡＧ１０３は、マルチホーミングのサポート機能を有していないとする。

ＩＦ１１０がＭＡＧ１０２に接続する場合、ＭＡＧ１０２は、その接続を登録するために、ＢＩＤを有するＰＢＵをＬＭＡ１０１へ送信する。この登録はバインディングエントリとしてＬＭＡ１０１に記録される。ＭＮ１１は、ローカルモビリティドメイン１０内で同時バインディングを実現しようとしており、ＩＦ１１１によってＭＡＧ１０３へ接続しようとする。これにより、ＭＡＧ１０３は、この接続の登録を行うために、ＰＢＵをＬＭＡ１０１へ送信する。ＭＡＧ１０３は、マルチホーミングのサポート機能を有していないのでＭＡＧ１０３からのＰＢＵにはＢＩＤは含まれていない。このＢＩＤを含まないＰＢＵの受信によって、ＬＭＡ１０１は、ＭＮ１１に関するすべてのバインディングを削除し、ＭＡＧ１０３へのバインディングエントリ１つに置き換えてしまう。その結果、ＭＮ１１は、ＬＭＡ１０１からＭＡＧ１０２への有効なパスを失ってしまうことになる。

また、ＭＡＧ１０２がＰＢＵをＬＭＡ１０１へ再送する場合には同一のバインディングエントリの置き換え動作が行われ、ＬＭＡ１０１は、ＭＡＧ１０３へのバインディングエントリを削除し、ＭＡＧ１０２へのバインディングエントリに置き換えてしまう。このような動作は、ＭＮ１１がこのシステムにおいてマルチホーミングを実現できないことを意味する。

なお、こうした問題を解消するための解決方法の１つが、例えば、上記の特許文献１においても説明されている。特許文献１における方法は、モバイルノードとの通信に使用可能なプロキシノードのＩＰアドレスを記載したバインディングメッセージをモバイルノードからアンカポイントへ送信させるものである。特許文献１における方法では、モバイルノードがプロキシノードに関する情報をアンカポイントに直接通知するので、アンカポイントが異なるタイプのバインディング登録メッセージを受信する場合が少なくなる。すなわち、モバイルノードからアンカポイントへ通知を行えるようにすることで、プロキシノードがマルチホーミングをサポートしているか否かにかかわらず、プロキシノードを経由してマルチホーミング機能が継続されるようになる。

本発明は、従来のマルチホーミングにおける問題点を解決することを目的とする。本発明は、特に、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対して、マルチホーミングをサポートし続けることを可能にする移動端末及びネットワークノードを提供することを目的とする。

上記の目的を達成するため、本発明の移動端末は、ネットワークベースのモビリティ管理を行うとともにマルチホーミングをサポートするローカルモビリティドメイン内で移動を行う移動端末であって、
複数の経路でパケットの送受信を行うことを可能とする、前記複数の経路のそれぞれに対応する複数の通信インタフェースと、
前記複数の通信インタフェースの少なくとも１つによって前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティに対して通知する機能情報通知手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティ（ローカルモビリティアンカ）は、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対してマルチホーミングをサポートし続けることが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノード（モバイルアクセスゲートウェイ）がマルチホーミングをサポートしていないことが把握できた場合、その旨をローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立していない場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノードとの間でアクセス認証が完了する前に、移動端末が接続しようとしている接続ノードがマルチホーミングをサポートしていない旨をローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードから、前記接続ノードがマルチホーミングをサポートしているか否かを示す情報を受信する機能情報受信手段を有する。
この構成により、例えば、接続ノードから受信するルータ通知メッセージに含まれている接続ノードの機能情報によって、接続ノードがマルチホーミングをサポートしているか否かを把握することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしているか否かを示す情報を、ファストモバイルＩＰを利用して取得する機能情報取得手段を有する。
この構成により、移動端末は、ファストモバイルＩＰを利用して、接続ノードがマルチホーミングをサポートしているか否かを把握することが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末は、接続ノードにまもなく接続しようとしている通信インタフェースを除く、ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、ローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末では、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立している場合、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている。
この構成により、移動端末が接続しようとしている接続ノードとの間でアクセス認証が完了した後に、消去されてしまった可能性のあるすべての通信インタフェースに関する接続情報をローカルモビリティドメイン内のエンティティへ通知することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを要求する確認要求手段を有する。
この構成により、移動端末は、ローカルモビリティドメイン内のエンティティにおいて正常な処理が行われたか否かを把握することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記確認メッセージを受信できなかった場合には、前記ローカルモビリティドメイン内のエンティティに対して、前記移動端末の接続に関するルーティング情報の再構築を要求するルーティング再構築要求手段を有する。
この構成により、移動端末は、ローカルモビリティドメイン内のエンティティにおいて正常な処理が行われなかったと判断した場合に、移動端末の接続に関するルーティング情報の再構築を要求することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内のエンティティから、前記移動端末のマルチホーム状態が失われた旨の通知を受信した場合、前記移動端末のマルチホーム状態を再構成するための情報を前記ローカルモビリティドメイン内のエンティティへ通知する再構成手段を有する。
この構成により、移動端末は、所望のマルチホーム状態を構成することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内のエンティティにおけるルーティングエントリが削除されたと判断できる場合、削除されたと判断された前記ルーティングエントリの復元を要求する復元要求手段を有する。
この構成により、移動端末は、ルーティングエントリの復元を要求することで、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記復元要求手段が、前記移動端末が接続しているマルチホーミングをサポートしている前記接続ノードに対して、前記ルーティングエントリを再構築させるための登録メッセージの再送を依頼するよう構成されている。
この構成により、移動端末は、マルチホーミングをサポートしている接続ノードに登録メッセージを再送させることで、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記復元要求手段が、前記移動端末が接続している前記接続ノードの中から、前記登録メッセージの再送を依頼する前記接続ノードを選択するよう構成されている。
この構成により、移動端末は、所望の接続ノード（例えば、マルチホーミングをサポートしていることが分かっている接続ノード）を確実に選択して、ローカルモビリティドメイン内のエンティティに登録したいルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記ローカルモビリティドメイン内の前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を収集し、リスト情報として格納する情報収集格納手段を有する。
この構成により、リスト情報を用いて検索手順を効率化することが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を通知するバインディング特定情報通知手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティにおいて、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。

さらに、本発明の移動端末は、上記の移動端末に加えて、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報に、置き換えられる対象のバインディングに関連する通信インタフェースを識別する固有の識別情報が含まれている。
この構成により、ローカルモビリティドメイン内のエンティティにおいて、移動端末のインタフェースの識別情報に基づいて、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。

また、上記の目的を達成するため、本発明のネットワークノードは、ローカルモビリティドメインにおいて、ネットワークベースのモビリティ管理を行うとともに、前記ローカルモビリティドメインに接続する移動端末のマルチホーミングをサポートする前記ローカルモビリティドメイン内のネットワークノードであって、
前記移動端末の通信インタフェースが前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記通信インタフェースと前記接続ノードとの対応をルーティング情報として保持するルーティングキャッシュと、
前記移動端末が保持する複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段と、
前記機能情報受信手段で受信した前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に基づいて、前記移動端末に関するルーティング情報の更新を行うルーティング更新手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティ（ローカルモビリティアンカ）は、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対してマルチホーミングをサポートし続けることが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていない旨を前記移動端末から受信した場合、通知を受けた前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を識別する固有の識別情報を準備する識別情報準備手段と、
通知を受けた前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を示す情報を受信した場合に、前記通信インタフェースと前記接続ノードとの対応を示すルーティング情報に前記固有の識別情報を付加して前記ルーティングキャッシュに格納させるルーティング情報管理手段とを、
有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末が接続しようとしている接続ノードがマルチホーミングをサポートしていない旨を把握し、その接続に関するルーティング情報の登録を行うために、その接続に対応する固有の識別情報を割り当てる準備を行うことが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を前記移動端末から受信した場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報に基づき、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に対応するルーティング情報を前記ルーティングキャッシュに追加するルーティングキャッシュ更新手段を有する。
この構成により、移動端末がマルチホーミングをサポートしていない接続ノードと接続したことによって、ローカルモビリティドメイン内のエンティティが消去してしまった可能性のあるすべての通信インタフェースに関する接続情報をルーティング情報として登録することが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを前記移動端末へ送信する確認送信手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末から受信した情報に対して正常な処理を行うことができたか否かを移動端末へ通知することが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記移動端末に関するルーティング情報を前記ルーティングキャッシュから消去するとともに、前記移動端末のマルチホーム状態が失われた旨を前記移動端末へ通知するルーティング情報消去通知手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、移動端末に所望のマルチホーム状態を改めて構成させることが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記移動端末に関するルーティング情報を消去する場合に、消去対象のルーティング情報に係るルーティングを無効にするとともに一定期間消去を保留し、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信した場合には前記消去対象のルーティング情報を有効にし、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信しなかった場合には前記一定期間経過後に前記消去対象のルーティング情報を完全に削除するルーティング情報消去手段を有する。
この構成により、ローカルモビリティドメイン内のエンティティは、ルーティングエントリの復元の要求を移動端末から受信した場合に、移動端末が所望するルーティングエントリを迅速に登録（復元）することが可能となる。

さらに、本発明のネットワークノードは、上記のネットワークノードに加えて、前記機能情報受信手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を前記移動端末から受信した場合、前記ルーティング更新手段が、前記置き換えられる対象のバインディングを示す情報によって特定されるバインディングを、まもなく接続しようとしている前記接続ノードに関するバインディングに置き換えるよう構成されている。
この構成により、ローカルモビリティドメイン内のエンティティは、更新対象のバインディング情報を正しく特定できるようにすることが可能となる。

本発明は、上記の構成により、従来のマルチホーミングにおける問題点を改善できるという効果を有する。本発明は、上記の構成により、特に、ローカルモビリティドメイン内で移動する移動端末（モバイルノード）に対してマルチホーミングをサポートし続けることを可能にするという効果を有する。

本発明の実施の形態及び従来の技術におけるネットワークベースのモビリティ管理に用いられる通信システムの一例を示す図 本発明の好適な実施の形態におけるルータ機能メッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、受信した機能情報に基づいてモバイルノードが行う動作の一例を示すフローチャート 本発明の好適な実施の形態において、ローカルモビリティドメイン内のエンティティに通知するために用いられる接続メッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、ローカルモビリティアンカによって行われる処理の一例を示すフローチャート 本発明の好適な実施の形態における再関連付けメッセージのフォーマットの一例を示す図 本発明の好適な実施の形態において、リカバリ動作をサポートするルーティングキャッシュの一例を示す図 本発明の好適な実施の形態におけるモバイルノードの機能アーキテクチャの一例を示すブロック図

以下、図面を参照しながら、本発明の実施の形態について説明する。なお、以下の説明では、本発明を説明するために、特定の番号や時間、構造、プロトコル名、及びその他のパラメータなどが詳細に説明される場合があるが、本明細書で用いられている特定の条件は、本発明を説明するために用いられているに過ぎず、本発明を限定するものではない。例えば、本発明を明瞭に示すために、周知の構成要素及びモジュールはブロックダイアグラムで表される。

本発明の実施の形態では、マルチホーム状態のモバイルノード（multi-homed mobile node）がローカルモビリティアンカに対して、ローカルモビリティドメインでマルチホーミングをサポートするための情報を提供できるようにする方法について説明する。この方法をサポートするため、モバイルノードは、まず、モバイルノードが接続しようとしているモバイルアクセスゲートウェイの機能（capability）を判断する必要がある。モバイルノードは、モバイルアクセスゲートウェイがマルチホーミングをサポートしていないことを把握できた場合には、これをトリガとして、まもなく行おうとしている接続に関する情報をローカルモビリティアンカへ提供する。ローカルモビリティアンカは、この提供された情報を用いることで、たとえモバイルアクセスゲートウェイにマルチホーミングのサポート機能が備わっていない場合であっても、モバイルノードへのマルチホーミングのサポートを維持することが可能となる。

モバイルノードが判断処理を実行することによって、モバイルノードは、ローカルモビリティドメインにおけるモバイルノードのマルチホーミングのサポートを維持するためにローカルモビリティアンカへ情報を伝える必要があるかどうかを判断することが可能となる。

また、本発明において、モバイルノードに関するマルチホーミングをサポートする機能をモバイルアクセスゲートウェイが実行可能かどうかをモバイルノードが把握するための好適な方法としては、例えば、モバイルアクセスゲートウェイがモバイルノードに対してその機能を保持していることを通知する方法が可能である。この方法を実現可能とするやり方の１つとして、モバイルアクセスゲートウェイがＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１で記述されているビーコン送信方法を利用する方法が挙げられる。また、この方法を実現可能とする別のやり方としては、モバイルアクセスゲートウェイがＩＥＴＦ（Internet Engineering Task Force）で記述されているルータ通知送信方法を利用する方法が挙げられる。また、３Ｇネットワークでは各無線アクセス技術における（レイヤ２技術に相当する）報知情報を利用することもできる。

図２には、本発明の好適な実施の形態におけるルータ機能メッセージ（router capability message）のフォーマットの一例が図示されている。図２において、ルータ機能メッセージ２０は、パケットヘッダ２００、ルータＩＤ（ルータ識別子）２０１、ルータ機能フィールド２０２を有している。

パケットヘッダ２００は、メッセージの送信元（ルータ機能メッセージの送信者）やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ２００には、例えば、送信元やあて先のＩＰｖ４アドレス又はＩＰｖ６アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

また、ルータＩＤ２０１は、そのルータの機能を通知するルータ識別情報を提供するためのフィールドである。なお、ルータＩＤ２０１は、モバイルアクセスゲートウェイのＭＡＣアドレスや、ローカルモビリティドメインのサービスプロバイダによって設定されたモバイルアクセスゲートウェイ固有の名前などを用いて形成されることが望ましい。

また、ルータ機能フィールド２０２は、モバイルアクセスゲートウェイの特徴（機能情報）を伝送するためのフィールドである。なお、本発明の実施の形態では、ルータ機能フィールド２０２は、モバイルアクセスゲートウェイがマルチホーミングのサポートを行えること（すなわち、マルチホーミングのサポート機能を有しており、かつ、その機能が実行可能であること）をモバイルノードに知らせるためのフラグ（ここでは、“Ｍ”フラグと記載する）２０２０を有している。

“Ｍ”フラグ２０２０は、例えば、１ビットの２進数の値によって実現可能である。例えば、“１”の値は、モバイルアクセスゲートウェイがマルチホーミングのサポート機能を備えていることを示しており、逆に、“０”の値は、モバイルアクセスゲートウェイがマルチホーミングのサポート機能を備えていないこと（あるいは、マルチホーミングのサポート機能を備えているとしても、その機能を実行できないこと）を示している。

なお、例えば、“Ｍ”フラグ２０２０のデフォルト値は“０”に設定されることが好ましい。これにより、マルチホーミングのサポートが可能なモバイルアクセスゲートウェイだけが、“Ｍ”フラグ２０２０の値を“１”の値に変えればよい。その結果、マルチホーミングのサポート機能を保持していないモバイルアクセスゲートウェイの機能を変更する必要が少なくなり、レガシノードであっても本発明に係るシステムで動作可能となる。なお、この値の設定は、レガシノードが未使用領域として“Ｍ”フラグ２０２０の値に相当する部分を“０”と設定していることを前提としている。

以下、ルータ機能メッセージ２０の使用方法の簡単な一例について説明する。図１において、ローカルモビリティドメイン１０では、ＭＡＧ１０２はマルチホーミングプロトコルを実装している。したがって、ＭＡＧ１０２は、“１”の値（マルチホーミングのサポートを行っていることを示す値）にセットされた“Ｍ”フラグ２０２０を有するルータ機能メッセージ２０を用いた通知を行う。このルータ機能メッセージ２０を受信することによって、ＭＮ１１は、ＭＡＧ１０２がマルチホーミングのサポートを行っていることを把握する。

一方、図１において、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。したがって、ＭＡＧ１０３は、“０”の値にセットされた“Ｍ”フラグ２０２０を有するルータ機能メッセージ２０を用いた通知を行う。このルータ機能メッセージ２０を受信することによって、ＭＮ１１は、ＭＡＧ１０３がマルチホーミングのサポートを行っていないことを把握する。

また、モバイルアクセスゲートウェイがマルチホーミングのサポートを行っているかどうかをモバイルノードが把握できるようにするための別の好適な方法として、ＩＥＥＥ８０２．２１の情報サービス（ＩＳ：Information Service）に関する手法を用いるやり方が挙げられる。この手法では、モバイルノードは、モバイルアクセスゲートウェイの機能に関して、ＩＳサーバへ問い合わせを行う。ＩＳサーバは、モバイルノードからの問い合わせに対する応答を行う。

以下、ＩＥＥＥ８０２．２１の情報サービスを用いる方法の一例について説明する。図１において、ローカルモビリティドメイン１０は、ローカルモビリティドメイン１０内に存在するすべてのモバイルアクセスゲートウェイ（ＭＡＧ１０２〜１０４）の機能に関する情報を格納しているＩＳサーバ（図１には不図示）を更に有している。ＭＮ１１は、ＭＡＧ１０３とＩＦ１１１で接続を行う前に、ＭＡＧ１０３がＭＮ１１に対してマルチホーミングのサポートを行えるかどうかを問い合わせるＩＳクエリメッセージをＩＳサーバへ送信する。ここで、ＩＳサーバのデータベースにおいて、ＭＡＧ１０３がマルチホーミングプロトコルを実装していないと判断されたとする。このとき、ＩＳサーバは、ＭＡＧ１０３がマルチホーミングのサポートを行うことができない旨を示す応答をモバイルノードへ行う。

モバイルノードは、モバイルアクセスゲートウェイの機能に関する情報（以下、機能情報と記載する）を受信すると、この受信した機能情報を解析し、この解析結果に基づく動作を行う。図３には、本発明の好適な実施の形態において、受信した機能情報に基づいてモバイルノードが行う動作の一例を示すフローチャートが図示されている。

図３において、モバイルノードは、モバイルアクセスゲートウェイの機能情報を受信すると、その機能情報から、モバイルアクセスゲートウェイがマルチホーミングをサポートしているか否かを特定する（ステップＳ３１）。モバイルアクセスゲートウェイがマルチホーミングをサポートしている場合には、処理は終了となる。この場合、モバイルノードはこれ以上特別な処理を行うことなく、モバイルアクセスゲートウェイとの間でのアクセス認証処理を行うことが可能となる。

一方、モバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、モバイルノードは、ローカルモビリティドメインにおけるマルチホーミングを維持するために、ローカルモビリティドメイン内のエンティティに通知を行う必要がある。このエンティティは、例えば、ローカルモビリティアンカであってもよく、モバイルアクセスゲートウェイであってもよい。

モバイルノードがマルチホーミングを維持するためにローカルモビリティドメイン内のエンティティへ通知を行う場合、例えば下記のように、２つのモードのうちのいずれかを採用することが可能である。なお、それぞれのモード（モード１及びモード２）において、モバイルノードは異なるタイプの情報を送信する。

モバイルノードの動作モードがモード１の場合（ステップＳ３２で『モード１』）には、モバイルノードは、ローカルモビリティドメイン内のエンティティに対して、そのモバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続しようとしている旨を通知する（ステップＳ３３）。その結果、この通知を受けたエンティティは、ローカルモビリティドメインにおいてモバイルノードのマルチホーミングを中断しないようにするための更なるステップを行うことが可能となる。

この方法は、モバイルノードがモバイルアクセスゲートウェイの機能を事前に検出することができる場合に特に有用である。モバイルノードは、この情報に基づいて、マルチホーミングの機能を有していないモバイルアクセスゲートウェイからバインディング登録メッセージが送信されることを事前に把握することが可能となる。なお、モバイルアクセスゲートウェイの機能を事前に検出できるように方法として、例えば、ＩＥＴＦで構築されたファストモバイルＩＰ（Fast Mobile IP）を利用する方法を用いることも可能である。

また、モバイルノードの動作モードがモード２の場合（ステップＳ３２で『モード２』）には、モバイルノードは、ローカルモビリティドメイン内のエンティティに対して、ローカルモビリティドメインでの現在の接続に関する情報を通知する（ステップＳ３４）。この情報の通知を受けたローカルモビリティドメイン内のエンティティは、モバイルノードのルーティングキャッシュを再構築し、マルチホーミングのサービスをモバイルノードへ提供し続けることが可能となる。

この方法は、マルチホーミングの機能を有していないモバイルアクセスゲートウェイがバインディング登録メッセージを送信するよりも前に、モバイルノードがエンティティに通知を行うことができない場合に特に有用である。なお、このような場合が起こり得る状況としては、例えば、モバイルノードのインタフェースが、あるモバイルアクセスゲートウェイから、マルチホーミングをサポートしていない別のモバイルアクセスゲートウェイにハンドオフするシナリオが考えられる。

上述の両方のモード（モード１及びモード２）共、モバイルノードはローカルモビリティドメイン内のエンティティに対して通知を行った後、処理は終了となる。なお、モバイルノードは、この通知を行うためのメッセージ（後述の接続メッセージ４０）に、確認メッセージ（ＡｃＫ）をリクエストする旨を示す情報を挿入してもよい。

次に、上述のフローチャートに示す方法について、図１を参照しながら、より詳細に説明する。図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１はＩＦ１１０をＭＡＧ１０２に接続しており、ＬＭＡ１０１は、ＭＡＧ１０２経由で受信したＭＮ１１のバインディングを保持しているとする。このバインディングは、バインディングに固有の識別情報（ＢＩＤ１）で識別される。

このとき、ＭＮ１１は、同時アクセスによってＭＡＧ１０３へＩＦ１１１を接続しようとしている場合には、マルチホーミングのサポートに関連するＭＡＧ１０３の情報（ＭＡＧ１０３の機能情報）を取得する。

ＭＮ１１がＭＡＧ１０３との間でアクセス認証を確立する前にこの機能情報（ＭＡＧ１０３がマルチホーミングをサポートしていない旨を示す情報）を取得した場合には、ＭＮ１１は、ＭＡＧ１０３への接続が行われようとしている旨を通知するためのメッセージをＬＭＡ１０１へ送信する。なお、このメッセージは、ＭＮ１１からＬＭＡ１０１に直接送信されてもよく、あるいは、ＭＮ１１からＭＡＧやその他の任意のエンティティに渡されてからＬＭＡ１０１に到達してもよい。また、このメッセージはＭＡＧ１０２を通じて送信されてもよく、ＭＡＧ１０３によって送信されるバインディング登録メッセージに挿入（ピギーバック）されてもよい。

一方、ＭＮ１１がＭＡＧ１０３との間でアクセス認証を確立した後にこの情報（ＭＡＧ１０３がマルチホーミングをサポートしていない旨を示す情報）を取得した場合には、ＭＮ１１は、ＭＡＧ１０２との接続を更に通知する同様のメッセージをＬＭＡ１０１へ送信する。この場合も同様に、ＭＡＧ１０２又はＭＡＧ１０３経由でメッセージの送信が可能である。

このようにしてＭＮ１１から通知された情報をＬＭＡ１０１が参照することで、ＭＮ１１がローカルモビリティドメイン１０においてマルチホーミングのサービスを確実に受け続けることができるようになる。

以下、いくつかの実施例を挙げて、マルチホーミングを維持するためにモバイルノードからローカルモビリティドメイン内のエンティティに送信されるメッセージ（以下、接続メッセージと記載する）の詳細について説明する。なお、この接続メッセージは、モバイルノードから１つ又は複数のモバイルアクセスゲートウェイ（マルチホーミングサポートを有していてもよく、あるいは有していなくてもよい）を経由して送信可能である。

図４には、本発明の好適な実施の形態において、ローカルモビリティドメイン内のエンティティに通知するために用いられる接続メッセージのフォーマットが示されている。接続メッセージ４０は、パケットヘッダ４００、モバイルノード識別情報（ＭＮ−ＩＤ）４０１、接続ステータスフィールド４０２を有している。

パケットヘッダ４００は、メッセージの送信元（接続メッセージの送信者）やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ４００には、例えば、送信元やあて先のＩＰｖ４アドレス又はＩＰｖ６アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

またＭＮ−ＩＤ４０１は、モバイルノードの識別情報を提供するためのフィールドである。この識別情報によって、ローカルモビリティドメイン内のエンティティは、この接続メッセージ４０が適用されるモバイルノードの接続ステータスを識別することが可能となる。

また、接続ステータスフィールド４０２は、モバイルノードが現在どのモバイルアクセスゲートウェイに接続しているかを示す情報（あるいは、モバイルノードがどのモバイルアクセスゲートウェイに接続しようとしているかを示す情報）を、ローカルモビリティドメイン内のエンティティへ通知するためのフィールドである。なお、接続ステータスフィールド４０２には、例えば１つ又は複数のルータＩＤ（ルータ識別情報）４０２０が含まれており、このルータＩＤ４０２０によって、どのモバイルアクセスゲートウェイが対象とされているかを接続メッセージ４０の受信者が把握できるようにすることが望ましい。

また、各ルータＩＤ４０２０は、そのルータＩＤ４０２０によって特定されるモバイルアクセスゲートウェイがマルチホーミングをサポートすることが可能か否かを接続メッセージの受信者４０が識別できるようにするための“Ｍ”フラグ４０２１と関連付けられていることが望ましい。“Ｍ”フラグ４０２１は、１ビットの値によって実現可能である。“１”の値の“Ｍ”フラグ４０２１は、ルータＩＤ４０２０によって特定されるモバイルアクセスゲートウェイがマルチホーミングをサポートしていることを示している。逆に、“０”の値の“Ｍ”フラグ４０２１は、モバイルアクセスゲートウェイがマルチホーミングをサポートしていないことを示している。

以下、本発明の好適な実施の形態（モード１の場合）における接続メッセージ４０の具体的な使用方法について説明する。図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１はＩＦ１１０をＭＡＧ１０２に接続しており、ＬＭＡ１０１は、ＭＡＧ１０２経由で受信したＭＮ１１のルーティングエントリを保持しているとする。このルーティングエントリは、バインディングに固有の識別情報（ＢＩＤ１）で識別される。ＬＭＡもまた一種のルータであり、バインディング登録によりバインディングエントリ（単にバインディングと呼ぶこともある）を生成する。ＬＭＡがパケットをルーティングする際にはルーティングエントリを参照し、パケットを送信するが、そのルーティングエントリの1つとしてバインディングエントリを参照することが可能である。なお、ルーティングエントリは、その他のルーティングプロトコルによっても生成されるため、同様の仕組みとして、バインディングエントリからルーティングエントリを明示的に生成することも可能である。本明細書においては、バインディング登録に基づくものをバインディングエントリ、ルーティングの際に参照する場合にはルーティングエントリとして説明する場合があるが、上述のように、実施の上での区別は当業者の任意の実装に依存するものであり、バインディングエントリとルーティングエントリの読み替えや、バインディングエントリからルーティングエントリの生成を前提とすることができる。

このとき、ＭＮ１１は、同時アクセスによってＭＡＧ１０３へＩＦ１１１を接続しようとしている場合には、マルチホーミングのサポートに関連するＭＡＧ１０３の情報（ＭＡＧ１０３の機能情報）を取得する。

ここで、ＭＮ１１がＭＡＧ１０３との間でアクセス認証を確立する前にこの機能情報（ＭＡＧ１０３がマルチホーミングをサポートしていない旨を示す情報）を含むＩＥＥＥ８０２．１１ビーコンを受信したとする。この場合には、ＭＮ１１は、ＭＡＧ１０３がＭＮのプレフィックスとＭＡＧ１０３の気付アドレスとを関連付けるＰＢＵを送信する前に、まもなく行おうとしているＭＡＧ１０３への接続に関する情報をＬＭＡ１０１に通知する旨を決定する。そして、ＭＮ１１は、ＭＡＧ１０３の識別情報を示すルータＩＤ４０２０、及び、“０”の値にセットされた“Ｍ”フラグ４０２１を有する接続ステータスフィールド４０２を含む接続メッセージ４０をＬＭＡ１０１へ送信する。この結果、ＬＭＡ１０１は、マルチホーミングをサポートしていないＭＡＧ１０３にＭＮ１１が接続しようとしている旨を把握し、ローカルモビリティドメインにおいてＭＮ１１のマルチホーミングを中断しないようにするための更なるステップを行うことが可能となる。

また、以下では、本発明の別の実施の形態（モード２の場合）における接続メッセージ４０を使用する方法について説明する。図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１はＩＦ１１０をＭＡＧ１０２に接続しており、ＬＭＡ１０１は、ＭＡＧ１０２経由で受信したＭＮ１１のルーティングエントリを保持しているとする。このルーティングエントリ（バインディング）は、バインディングに固有の識別情報（ＢＩＤ１）で識別される。

ＭＮ１１は、ＩＦ１１１をＭＡＧ１３０に接続して同時アクセスを行おうとしている場合に、マルチホーミングのサポートに関連するＭＡＧ１０３の情報を取得する。ＭＡＧ１０３とのアクセス認証を完了した後、ＭＮ１１は、ＭＡＧ１０３がマルチホーミングのサポート機能を有していない旨を示すルータ通知を受信したとする。この場合、ＭＮ１１は、ローカルモビリティドメイン１０へのすべての接続に関する情報をＬＭＡ１０１へ通知する旨を決定する。この決定に従って、ＭＮ１１は、“１”の値がセットされた“Ｍ”フラグ４０２１及びＭＡＧ１０２の識別情報を示すルータＩＤ４０２０と、“０”の値がセットされた“Ｍ”フラグ４０２１及びＭＡＧ１０３の識別情報を示すルータＩＤ４０２０とを有する接続ステータスフィールド４０２を含む接続メッセージ４０をＬＭＡ１０１へ送信する。これにより、ＬＭＡ１０１は、ＭＮ１１のルーティングキャッシュを更新し、ＭＮ１１がローカルモビリティドメイン１０内でマルチホーミングの利益を確実に受け続けられるようにすることが可能となる。

なお、上述した両方の例（モード１及びモード２の両方の例）において、モバイルノードから送信された接続メッセージ４０は、モバイルアクセスゲートウェイによってローカルモビリティアンカへ中継される。これにより、モバイルノードは、ローカルモビリティアンカのＩＰアドレスを探索する必要はなくなり、モバイルノードの限られたバッテリ寿命を保つことが可能となる。

さらに、現在のモバイルアクセスゲートウェイとの接続やまもなく行われるモバイルアクセスゲートウェイとの接続を経由して接続メッセージ４０を伝送すべきか否かを、モバイルノードが選択することが可能である。各モバイルアクセスゲートウェイはモバイルノードから受信したパケットをローカルモビリティアンカへ転送するので、ローカルモビリティアンカは、現在のモバイルアクセスゲートウェイとの接続やまもなく行われるモバイルアクセスゲートウェイとの接続のどちらかを利用して接続メッセージ４０を受信することが可能である。

まもなく行われるモバイルアクセスゲートウェイとの接続を経由して接続メッセージ４０を送信した場合には、この接続メッセージ４０が最小の遅延で確実にローカルモビリティアンカに届くという利点がある。なお、まもなく接続しようとしているモバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、このモバイルアクセスゲートウェイから送信されるＰＢＵは、モバイルノードがモバイルアクセスゲートウェイの機能を把握する前に、ローカルモビリティアンカに届いてしまう可能性がある。その結果、モバイルノードのすべてのアクティブな接続に関する情報が、ローカルモビリティアンカから削除されてしまう可能性がある。したがって、ローカルモビリティアンカは、こうしたモバイルアクセスゲートウェイからモバイルノードに関連するデータを受信することを予想していないので、モバイルアクセスゲートウェイから受信するモバイルノードに関連するパケットは、ローカルモビリティアンカにおいて廃棄されてしまう可能性がある。

また、モバイルノードがローカルモビリティアンカとの間のアクティブな接続を切断した場合に、ローカルモビリティアンカがバインディング取り消しメッセージを、対応するモバイルアクセスゲートウェイへ送信してしまう可能性もある。これは、事実上、モバイルノードのデータをローカルモビリティアンカへプロキシしないようにモバイルアクセスゲートウェイへ指示するものであり、モバイルノードからモバイルアクセスゲートウェイへ送信される接続メッセージ４０が廃棄されてしまうことになりかねない。このような場合でも、マルチホーミングをサポートしているローカルモビリティアンカや、現在接続を維持できているローカルモビリティアンカを、接続メッセージを送信する経由先として優先的に選択することで、状況が改善される可能性がある。

なお、当業者であれば、上述の説明によって、モバイルノードがマルチホーミングの動作を維持できるようになる方法（本発明に係る方法）が、特許文献１に説明されている方法とは異なることが理解できるであろう。特許文献１に開示されている従来の技術では、モバイルノードが、プロキシノードのＩＰアドレスを示すメッセージをアンカポイント（anchoring point）へ送信するようトリガされる。これによって、アンカポイント（anchoring point）は、モバイルノードとの接続を維持し続けることが可能となる。

また、同様に、トリガを行ってアンカポイントをアップデートする方法に関しては、非特許文献１や非特許文献４にも開示されている。これらの非特許文献１及び非特許文献４の両方における技術では、モバイルノードは、ＩＰアドレスを変更した場合は常にアンカポイントを更新するようトリガされる。また、非特許文献４では、モバイルノードによって使用されている各ＩＰアドレスを識別することが可能となる識別情報が、アンカポイントへ送信されるメッセージに含まれている。

上述の従来の技術及び本発明は共に、新しい接続ポイントに関する情報をアンカポイントにアップデートする動作をモバイルノードに行わせるという点においては同じ概念を用いている。しかしながら、本発明では、アンカポイントへのメッセージには、プロキシノードの機能に関連する情報が更に含まれている。この情報を用いることで、アンカポイントは、モバイルノードとの接続を維持できるようになる。また、本発明は、この情報をより適切なプロキシノードを経由して送信できるようしており、情報を通知する効率、安定性が向上する。以上のように、本発明と従来の技術とは大きく異なっている。

上述においては、本発明によって、モバイルノードがモバイルアクセスゲートウェイの機能に関する情報をローカルモビリティアンカへ送信するようトリガされることによって、ローカルモビリティドメインでのマルチホーミング機能が維持される方法について説明した。モバイルアクセスゲートウェイの機能に関する情報がローカルモビリティアンカに到達した場合には、ローカルモビリティアンカが行うべき次の動作方針を決定するために、この情報の処理が行われる必要がある。

以下、図５に図示されているフローチャートを参照しながら、本発明の実施の形態において、ローカルモビリティアンカによって行われる処理の一例について説明する。ローカルモビリティアンカが接続メッセージ４０を受信した場合に、図５の処理が開始される。ローカルモビリティアンカは、処理を開始すると、まず、接続メッセージ４０内に含まれている情報のタイプ（モバイルノードの動作モード）を判断する（ステップＳ５１）。

例えば、この情報が、モバイルアクセスゲートウェイがマルチホーミング機能をサポートしていないことを示す情報である場合（上述の図３のステップＳ３３において、モバイルノードの動作モードが、マルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続しようとしている旨を通知するモード１の場合）には、ローカルモビリティアンカは、まもなく行われるモバイルノードとの接続を注目して、この登録を行うためのユニークなバインディング識別子（ＢＩＤ）を準備する（ステップＳ５２）。

一方、例えば、この情報が、モバイルノードが接続されているすべてのモバイルアクセスゲートウェイに関する情報である場合（上述の図３のステップＳ３４において、モバイルノードの動作モードが、ＭＡＧとの現在の接続に関する情報を通知するモード２の場合）には、ローカルモビリティアンカは、通知されたこの情報を用いて、モバイルノードのルーティングを定めるバインディングキャッシュエントリ（ＢＣＥ：Binding Cache Entry）を更新する（ステップＳ５３）。

ステップＳ５２又はステップＳ５３における情報処理が行われた後、ローカルモビリティアンカは、モバイルノードに対して確認メッセージ（Ａｃｋ）が送信されるべきか否かのチェックを行う（ステップＳ５４）。なお、この確認メッセージのリクエストは、例えば、モバイルノードによって接続メッセージ４０内に挿入されてもよい。また、モバイルノードが確認メッセージのリクエストを行っていない場合であっても、ローカルモビリティアンカは、この確認メッセージをモバイルノードへ返してもよい。確認メッセージの送信が必要な場合（例えば、接続メッセージ４０に確認メッセージの送信リクエストが挿入されている場合）には、ローカルモビリティアンカは、確認メッセージをモバイルノードへ送信する（ステップＳ５５）。一方、確認メッセージの送信が必要ではない場合には、そのまま何もせずに処理は終了となる。

以下、より詳細に上述の方法を示す例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＬＭＡ１０１がＭＮ１１から接続メッセージ４０を受信した場合、ＬＭＡ１０１は、接続ステータスフィールド４０２をチェックして、どんなタイプの情報がメッセージに挿入されているかを判断する。

ＬＭＡ１０１が受信した接続メッセージ４０に、例えば“０”の値にセットされた“Ｍ”フラグ４０２１と共にＭＡＧ１０３の識別子を示すルータＩＤ４０２０が接続ステータスフィールド４０２に含まれているとする。この場合、ＬＭＡ１０１は、後にＭＮ１１に関するＰＢＵをＭＡＧ１０３から受信することになる旨を把握する。したがって、ＬＭＡ１０１は、このＰＢＵに関連して、このエントリに関するユニークなバインディング識別子（ＢＩＤ）を準備する。ＭＡＧ１０３から送信されたＰＢＵがＬＭＡ１０１に到着すると、ＭＮ１１のルーティングキャッシュに、準備しておいたＢＩＤを含むエントリが付加される。この結果、ＬＭＡ１０１は、ローカルモビリティドメイン１０におけるＭＮ１１のマルチホーミングをサポートし続けることが可能となる。

一方、ＬＭＡ１０１が受信した接続メッセージ４０に、例えば“１”の値にセットされた“Ｍ”フラグ４０２１と共にＭＡＧ１０２の識別子を示すルータＩＤ４０２０が接続ステータスフィールド４０２に含まれているとする。この場合、ＬＭＡ１０１は、ＭＮ１１がローカルモビリティドメイン１０内でマルチホーミングのサポートを受けたい旨を把握する。

なお、この接続メッセージ４０の受信前に、ＬＭＡ１０１は、ＭＡＧ１０３からＰＢＵを既に受信している可能性があり、このＰＢＵによって、ＭＡＧ１０３へのルーティングエントリを除くルーティングキャッシュ内のＭＮ１１に関するすべてのエントリが削除されてしまっている可能性がある。しかしながら、ＬＭＡ１０１は、接続メッセージ４０内の情報を参照することで、ＭＡＧ１０３へのルーティングエントリを削除することなく、ＭＡＧ１０２へのルーティングエントリが含まれるようにＭＮ１１に関するルーティングキャッシュを修正することが可能となる。

また、ＬＭＡ１０１は、接続メッセージ４０の受信後にＭＡＧ１０３からＰＢＵを受信した場合においても、マルチホーミングをサポートしていないモバイルアクセスゲートウェイにモバイルノードが接続されていることを考慮して、ＭＮ１１に関するルーティングキャッシュを維持することが可能となる。ルーティングキャッシュを維持するための方法としては、例えばＬＭＡ１０１が、ルーティングキャッシュをアップデートする際に、特別なＢＩＤをＭＡＧ１０３に関するエントリに割り当てる方法が挙げられる。ＬＭＡ１０１は、ＭＮ１１によるＭＡＧ１０３への接続に関するアップデートを行うためのＰＢＵを受信した場合は常に、ＭＮ１１のルーティングキャッシュに従ってＰＢＵの処理を行うように特別な配慮を行う。

また、例えば、マルチホーミングプロトコルの機能を実装するモバイルアクセスゲートウェイが、ユニークなＢＩＤを割り当てるプロセスを実行することも可能である。これは、モバイルアクセスゲートウェイがローカルモビリティアンカあてのメッセージを受信（intercept）し、マルチホーミングプロトコルの機能を有していないことが確認されているモバイルアクセスゲートウェイに関連するユニークなＢＩＤを付加することを示している。この動作が行われる場合には、ローカルモビリティアンカがレガシノード（すなわち、ルーティングキャッシュエントリに特別なＢＩＤを割り当てることができないローカルモビリティアンカ）である場合にも本発明が適用可能となるという利点がある。また、ローカルモビリティアンカによって実行される動作のロードバランスを行うために、モバイルアクセスゲートウェイにＢＩＤを割り当てる処理負荷を分散させることが可能となるという利点もある。

以下、この動作を示すより詳細な例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＩＦ１１１は、ＭＮ１１はＩＦ１１０を通じてＭＡＧ１０２と接続しており、さらに、ＩＦ１１１によってＭＡＧ１０３へ接続しようとしている。

ＭＡＧ１０３は、ＭＮ１１がＭＡＧ１０３とまもなく接続する旨を通知するための接続メッセージ４０を、ＭＡＧ１０２経由でＬＭＡ１０１へ送信するようＭＮ１１に指示する。ＭＮ１１はこの指示に従って、ＭＡＧ１０２経由でＬＭＡ１０１へ接続メッセージ４０を送信し、ＭＡＧ１０２は、例えば、パケットヘッダ４００のパケットタイプを検査することによってＭＮ１１から送信された接続メッセージ４０を特定すると、この接続メッセージ４０にＭＡＧ１０３に関するＢＩＤを付加する。そして、ＢＩＤが付加された接続メッセージがＭＡＧ１０２からＬＭＡ１０１に転送され、ＬＭＡ１０１において処理される。

さらに、別の好適な実施の形態において、ローカルモビリティアンカが、モバイルノードからの接続メッセージ４０を受信すると、確認メッセージをモバイルノードに送信してもよい。なお、確認メッセージの送信は、モバイルノードによってリクエストされてもよい。また、モバイルノードからリクエストされない場合であっても、確認メッセージの送信が行われてもよい。確認メッセージの送信が行われた場合には、ローカルモビリティアンカへの接続メッセージ４０内の情報の伝送に成功したことをモバイルノードが把握できるという利点がある。例えば、確認メッセージを受信したモバイルノードは、マルチホーミングプロトコルを実施していないモバイルアクセスゲートウェイとの間で、アクセス認証処理を開始することが可能となる。

以下、この動作を示すより詳細な例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＭＮ１１は、ＩＦ１１０を通じてＭＡＧ１０２と接続しており、さらに、ＩＦ１１１によってＭＡＧ１０３へ接続しようとしている。

ＭＡＧ１０３は、ＭＮ１１がＭＡＧ１０３とまもなく接続する旨を通知するための接続メッセージ４０を、ＭＡＧ１０２経由でＬＭＡ１０１へ送信するようＭＮ１１に指示する。ＭＮ１１は、ＬＭＡ１０１から確認メッセージを受信するまで、ＭＡＧ１０３とのアクセス認証処理を行わないよう決定し、これによって、ＬＭＡ１０１のルーティングキャッシュに矛盾が生じないようにする。一方、ＬＭＡ１０１が接続メッセージ４０の受信に成功すると、ＬＭＡ１０１は、ＭＮ１１に確認メッセージを送り返す。ＭＮ１１は、成功を示す確認メッセージを受信することで、ＭＡＧ１０３との間でアクセス認証処理を開始するようＩＦ１１１に対して指示を行うことが可能となる。

さらに、別の好適な実施の形態において、モバイルノードは、モバイルノードとアクティブな接続を有するマルチホーミングをサポートしているモバイルアクセスゲートウェイに対して、ローカルモビリティアンカへの登録メッセージの再送を依頼することも可能である。なお、本明細書では、ローカルモビリティアンカへの登録メッセージの再送をモバイルノードがモバイルアクセスゲートウェイにリクエストするためのメッセージを、再関連付けメッセージ（rebind message）と呼ぶことにする。

このように、ローカルモビリティアンカへの登録メッセージの再送を要求する理由は、例えば、ローカルモビリティアンカからの確認メッセージがモバイルノードに返されなかった場合に、モバイルアクセスゲートウェイとの間のアクセス認証処理の開始が大きく遅れてしまうからである。この場合、モバイルノードは、マルチホーミングをサポートしていないモバイルアクセスゲートウェイとの間でアクセス認証処理を開始し、次に、マルチホーミングをサポートしているモバイルアクセスゲートウェイに対して登録メッセージの再送を依頼する。このような場合は、ローカルモビリティアンカがマルチホーミングをサポートしていないモバイルアクセスゲートウェイから登録メッセージを受信した場合に、モバイルノードのマルチホーミング機能がローカルモビリティドメイン内ではサポートされていないことにより生じる。

モバイルアクセスゲートウェイから登録メッセージが再送された場合は、モバイルノードが、ローカルモビリティアンカにおけるモバイルノードのルーティングキャッシュの再構築を望んでいることを示している。さらに、モバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイとアクティブな接続を有している場合には、モバイルアクセスゲートウェイに関する登録を、マルチホーミングをサポートしているモバイルアクセスゲートウェイへ委譲することが可能である。

また、図６には、本発明の好適な実施の形態における再関連付けメッセージのフォーマットの一例が図示されている。再関連付けメッセージ６０は、パケットヘッダ６００、モバイルノード識別子（ＭＮ−ＩＤ）６０１、アシストバインディングフィールド６０２を有している。

パケットヘッダ６００は、メッセージの送信元（再関連付けメッセージの送信者）やあて先に関する情報を伝送するためのフィールドである。パケットヘッダ６００には、例えば、送信元やあて先のＩＰｖ４アドレス又はＩＰｖ６アドレス、メッセージタイプを示すタイプフィールド、メッセージの長さを示す長さフィールドなどが含まれている。

ＭＮ−ＩＤ６０１は、モバイルノードの識別子を含むフィールドであり、このモバイルノードの識別子によって、どのモバイルノードのバインディングに関してローカルモビリティアンカへの再送が必要とされているのかをモバイルアクセスゲートウェイが識別できるようになる。

また、アシストバインディングフィールド６０２は、モバイルノードが、追加バインディング情報を記載できるようにするためのフィールドである。追加バインディング情報は、モバイルノードが、ローカルモビリティアンカへの登録に関してモバイルアクセスゲートウェイの援助を受けようとしていることを示すものである。なお、例えば、アシストバインディングフィールド６０２には、１つ又は複数のルータ識別子（ルータＩＤ）６０２０が含まれていることが望ましく、このルータ識別子６０２０によって、モバイルノードは、ローカルモビリティアンカへの登録メッセージに挿入されるべき追加のモバイルアクセスゲートウェイを指定することが可能となる。

以下、より詳細に再関連付けメッセージ６０の利用例について説明する。図１において、ＭＡＧ１０２は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０３は、マルチホーミングプロトコルを実装していないとする。ＭＮ１１は、ＭＡＧ１０３とのアクセス認証処理を遅らせたくないので、この処理をＩＦ１１１に開始させる。また同時に、ＬＭＡ１０１へのＰＢＵの再送を依頼する再関連付けメッセージ６０をＭＡＧ１０２へ送信する。なお、ＭＮ１１は、ＬＭＡ１０１への登録を行う際にＭＡＧ１０３に関するＢＩＤの割り当てを行うようＭＡＧ１０２へ依頼するために、アシストバインディングフィールド６０２にＭＡＧ１０３の識別情報を追加する。ＭＡＧ１０２は、自身のバインディングに加えてＭＡＧ１０３のバインディングが記載されたＰＢＵをＬＭＡ１０１へ送信する。これによって、ＬＭＡ１０１は、ＭＮ１１がマルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続されていることを把握できるようになる。また、ＬＭＡ１０１は、ＭＮ１１に関するルーティングキャッシュを維持する際にマルチホーミングに関して配慮するよう注意することが可能となる。

また、別の好適な実施の形態において、モバイルノードは、再関連付けメッセージによって、ローカルモビリティドメインにおける現在のすべての登録を扱うことが可能なマルチホーミングをサポートしているモバイルアクセスゲートウェイの１つを選択することが可能である。この場合、アシストバインディングフィールド６０２には、マルチホーミングをサポートしているか否かに関係なく、モバイルアクセスゲートウェイの識別子が挿入される。

例えば、図１において、ＭＡＧ１０２はマルチホーミングプロトコルを実装しているが、ＭＡＧ１０３はマルチホーミングプロトコルを実装していないとする。ＭＮ１１は、ＭＡＧ１０３がマルチホーミングをサポートしていないことを把握し、ＭＡＧ１０３に関してＬＭＡ１０１への登録の処理を行うよう依頼する再関連付けメッセージ６０をＭＡＧ１０２へ送信する。これにより、ＭＡＧ１０２は、ＬＭＡ１０１にルーティングエントリを登録するためのＰＢＵを、ＭＡＧ１０３に代わって送信する。このエントリは、さらにＭＡＧ１０２によって割り当てられたＢＩＤが付加される。また、ＭＡＧ１０２は、ＭＮ１１がマルチホーミングをサポートしていないモバイルアクセスゲートウェイへ接続する旨をＬＭＡ１０１へ通知することが可能である。この結果、ＬＭＡ１０１は、ＭＮ１１に関するＭＡＧ１０３経由の登録処理をＭＡＧ１０２へ委譲するよう決定してもよい。

さらに別の好適な実施の形態において、ローカルモビリティアンカが、ローカルモビリティドメイン内のモバイルノードのためにマルチホーミングをサポートするために、何らかの特別な機能を実装してもよい。例えば、ローカルモビリティアンカが、モバイルノードのマルチホーミング機能を事実上サポートしていないモバイルアクセスゲートウェイからの登録メッセージを検出した場合、ローカルモビリティアンカは、モバイルノードのルーティングキャッシュを変更せず、代わりにこの新たな登録に関して一時的なエントリを作成する。同時に、ローカルモビリティアンカは、この登録メッセージによってモバイルノードに関するマルチホーミング機能が失われてしまうことが判明した場合には、モバイルノードに確認を行う。

また、別の好適な実施の形態において、ローカルモビリティアンカは、モバイルノードのルーティングキャッシュを変更する処理を行い、これによって、モバイルノードが、ローカルモビリティドメインにおけるマルチホーミング機能を失うようにすることも可能である。このとき、ローカルモビリティアンカは、ローカルモビリティドメインにおけるマルチホーミング機能が失われたことを通知するメッセージをモバイルノードに送信する。さらに、このメッセージによって、ローカルモビリティアンカがマルチホーミングをサポートしていないモバイルアクセスゲートウェイからモバイルノードの登録を受信したという原因によってモバイルノードのマルチホーミング機能が失われる旨を、モバイルノードへ通知してもよい。こうしたメッセージをローカルモビリティアンカから送信することで、モバイルノードが現在接続されているモバイルアクセスゲートウェイの機能をモバイルノードにチェックさせることができるという利点がある。なお、この場合には、モバイルノードは、例えば本発明に係る方法を利用して、ローカルモビリティドメインにおけるマルチホーミング機能の再構成（再登録処理）を行うことが可能である。

さらに、別の好適な実施の形態において、モバイルアクセスゲートウェイの機能をチェックすることで、モバイルノードが、ローカルモビリティドメイン内のモバイルアクセスゲートウェイのリストや各モバイルアクセスゲートウェイの機能に関する情報を集めることも可能である。このリストは、例えば、一定期間あるいは一定のリスト項目数だけ保持されてもよい。また、ローカルモビリティドメイン内のモバイルアクセスゲートウェイの機能を把握するために、このリストがローカルモビリティアンカに送信されてもよい。これは特に、ローカルモビリティアンカ及びモバイルアクセスゲートウェイが同一プロバイダに属していないが、同一のローカルモビリティドメイン内に共設されている場合に有用である。例えば、この一例として、セルラのオペレータ間でローミング協定が行われている場合が挙げられる。このローミング協定では、例えば、モバイルアクセスゲートウェイが、相手オペレータのモバイルノードに関するルーティングパスを相手オペレータのローカルモビリティアンカに登録することが可能である。なお、こうしたリストをローカルモビリティドメイン側（あるいは、１つ又は複数のオペレータ側）で作成してもよい。

例えば、モバイルノードは、このリストを用いて、マルチホーミングをサポートしていないモバイルアクセスゲートウェイの使用に関する優先度（プリファレンス）をローカルモビリティアンカにセットする。例えば、この一例として、モバイルノードがマルチホーミングをサポートしていないモバイルアクセスゲートウェイへの接続を望まず、マルチホーミングをサポートしているモバイルアクセスゲートウェイだけを通知してほしいとローカルモビリティアンカに依頼する場合が挙げられる。

また、別の例として、モバイルノードが、これから接続を予定しているモバイルアクセスゲートウェイの使用に対して低い優先度をローカルモビリティアンカに設定することも可能である。この場合、モバイルノードの近傍に存在する別の適切なモバイルアクセスゲートウェイをモバイルノードが探索する動作を、ローカルモビリティアンカが支援することが可能となる。

モバイルノードのインタフェースがローカルモビリティドメイン内で移動した場合には、モバイルノードのマルチホーミング機能を確実に維持するように更なる配慮が行われる必要がある。例えば、図１において、ＭＡＧ１０２及びＭＡＧ１０３は、マルチホーミングプロトコルを実装しており、ＭＡＧ１０４はマルチホーミングプロトコルを実装していないとする。また、ＭＮ１１のＩＦ１１０はＭＡＧ１０２に接続されており、ＭＮ１１のＩＦ１１１はＭＡＧ１０３に接続されているとする。このとき、ＭＮ１１のＩＦ１１１がＭＡＧ１０３からＭＡＧ１０４に移動を行おうとしている場合を考える。

本発明の好適な実施の形態において、ＭＮ１１がＭＡＧ１０４とまもなく接続する旨をＬＭＡ１０１へ通知した場合、ＬＭＡ１０１は、まもなく行われる接続によってどのバインディングが置き換えられるのか分からないという問題が生じる。これは特に、例えばＭＡＧ１０２とＬＭＡ１０１との間のネットワーク輻輳などの原因によって、ＭＡＧ１０２からの登録削除メッセージ（de-registration message）がＭＡＧ１０４の接続に関する登録よりも遅れてＬＭＡ１０１に届く場合に問題が生じる。このような場合を考慮して、モバイルノードは、まもなく行われる接続によってどのバインディングが置き換えられるのかをローカルモビリティアンカへ通知するためのより詳細な情報を加える必要がある。

このように接続（バインディング）を特定するために追加される情報は、例えば、ローカルモビリティアンカがモバイルノードの複数のインタフェースのそれぞれをユニークに識別できるインタフェース識別子（ＩＦ−ＩＤ）の形式にすることが可能である。ここで挙げた例の場合、ＬＭＡ１０１では、例えば、各ルーティングエントリがＭＮ１１のＩＦ−ＩＤと関連付けられる。例えば、ＭＡＧ１０２へのルーティングエントリはＩＦ１１０のＩＦ−ＩＤと関連付けられ、ＭＡＧ１０３へのルーティングエントリはＩＦ１１１のＩＦ−ＩＤと関連付けられる。ＭＮ１１は、ＩＦ１１１のＩＦ−ＩＤを使用することによって、まもなく行われるＭＡＧ１０４との接続がＩＦ１１１によって行われることをＬＭＡ１０１へ通知することが可能となる。これにより、ＬＭＡ１０１は、まもなく行われるＭＡＧ１０４との接続がＭＡＧ１０３へのルーティングエントリを置き換えるべきものであることを把握することが可能となる。

また、別の好適な実施の形態において、モバイルノードに関する各ルーティングエントリを識別するために使用される識別子（ＢＩＤ）がモバイルアクセスゲートウェイのタイプに関係なく共通のものである場合には、こうしたエントリが予定外に削除されてしまうことによって、モバイルノードがローカルモビリティアンカへのアクティブなルートをいくつか失ってしまう可能性がある。

例えば、上述のシナリオにおいて、ＩＦ１１１がＭＡＧ１０３からＭＡＧ１０４へ移動するという通知をＬＭＡ１０１が受けた場合には、ＭＡＧ１０４に関するルーティングエントリに、ＭＡＧ１０３へあらかじめ割り当てられているＢＩＤが使用されている可能性がある。このようにＢＩＤを再利用する方法は、ローカルモビリティアンカが保持しなければならないＢＩＤの数を制限する場合に一般的に用いられる。このとき、例えばネットワーク輻輳によってＭＡＧ１０３からの登録削除メッセージがＬＭＡ１０１へ届くのが遅くなった場合には、この登録削除メッセージは、既に置き換えられたルーティングエントリ（ＭＡＧ１０４へのルーティングエントリ）を削除することになる。これは、登録削除メッセージに、ＭＡＧ１０４に割り当てられたものと同一のＢＩＤが含まれていることによる。

このような状況を回避するためには、モバイルノードの各ルーティングエントリを識別するために使用するユニークなバインディング識別子（ＢＩＤ）が、異なるモバイルアクセスゲートウェイのタイプで区別されるようにする必要がある。例えば、ローカルモビリティドメインでマルチホーミングをサポートしていないモバイルアクセスゲートウェイに対しては、ＢＩＤ＃１２８以上を使用することによって区別する。

また、この問題を解決する別の実施の形態において、動作シーケンスの順序で、バインディング識別子（ＢＩＤ）が使用されるようにしてもよい。例えば、ローカルモビリティアンカは、ローカルモビリティアンカが異なるモバイルアクセスゲートウェイから受信する各登録メッセージに関して、１つずつＢＩＤのカウントを増加させる。例えば、ＭＡＧ１０２のエントリがＢＩＤ＃１を使用しており、ＬＭＡ１０１が、ＭＮ１１に関するＭＡＧ１０３からの登録メッセージを受信した場合には、このエントリ（ＭＡＧ１０３のエントリ）に対してＢＩＤ＃２を割り当てる。こうしたカウンタは、モバイルノードが一定期間動作していない場合に、最初の開始値に戻るよう再設定することが可能である。

さらに別の好適な実施の形態において、モバイルノードに関するルーティングエントリがすぐには削除されず、その代わり、ある期間経ってから削除されるようにマークが付されてもよい。ルーティングキャッシュから削除されることを示すマークが付されると、このルーティングエントリにはタイマが設定される。タイマが満了した場合には、このルーティングエントリはルーティングキャッシュから完全に削除される。

このリカバリ動作は、モバイルノードが予定外に削除されてしまったバインディングを復元させたいと望む場合に有用である。例えば、ローカルモビリティアンカにおいて、マルチホーミング機能をサポートしていないモバイルアクセスゲートウェイからの登録メッセージを受信することによって、モバイルノードに関するルーティングキャッシュ内のエントリが削除されてしまう場合が挙げられる。この場合、モバイルノードは、リカバリメッセージを送って、削除されたモバイルノードに関するすべてのルーティングエントリ（あるいは、所望のマルチホーム状態を得るために復元が必要な特定のルーティングエントリ）を元に戻すようローカルモビリティアンカに依頼する。このリカバリメッセージは、ローカルモビリティアンカへ送信される任意のメッセージに挿入されたフラグとして実現されてもよい。

図７には、本発明の好適な実施の形態において、リカバリ動作をサポートするルーティングキャッシュの一例が図示されている。なお、本発明を実現する任意のエンティティ（モバイルノードやローカルモビリティアンカなど）内に当該ルーティングキャッシュの機能を配置することが可能である

通常、ルーティングキャッシュ７０はモバイルノードの識別子（ＭＮ−ＩＤ）欄７１、バインディング識別子（ＢＩＤ）欄７２、気付アドレス（ＣｏＡ）欄７３、パス欄７４、非動作タイマ欄７５を有している。

ＭＮ−ＩＤ欄７１は、通常、ローカルモビリティドメインで使用するためにモバイルノードに割り当てられたプレフィックスを有している。また、ＢＩＤ欄７２も通常、モバイルノードの異なるルーティングエントリを区別するために使用されるユニークなバインディング識別子を有している。また、ＣｏＡ欄７３は、モバイルノードが接続されているモバイルアクセスゲートウェイの気付アドレスを識別するものである。以上の情報によって、モバイルノードへのパケットのルーティングが可能となる。

本発明では、パス欄７４によって、エンティティは、そのルーティングがローカルモビリティドメイン内でまだアクティブであるか否かを把握することが可能である。パス欄７４においてエントリが“無効”とマークされている場合には、このルーティングパスは使用不可能であることを示している。一方、エントリが“有効”とマークされている場合には、このルーティングパスは使用可能であることを示している。また、非動作タイマ欄７５は、エンティティに対して、ルーティングパスがルーティングキャッシュから完全に消去されてしまうまでの残り時間を通知するための情報を含んでいる。非動作タイマ欄７５は通常、パス欄７４が“非動作”を示す場合に設定される。

以下、上述の本発明に係るリカバリ動作の一例について説明する。図７において、ＬＭＡ１０１は、マルチホーミングをサポートしていないモバイルアクセスゲートウェイ（ＭＡＧ１０４）から登録メッセージを受信した場合に、図７に示すルーティングキャッシュを構築する。この登録メッセージを受信した場合、ＭＡＧ１０２とＭＡＧ１０３の両方のエントリがＬＭＡによって削除対象としてマークされる。これによって、ＬＭＡ１０１が両方のエントリを“非動作”とし、それらのエントリに、ルーティングキャッシュから完全に削除されるまでタイマ（例えば６０分）をセットする。

一方、ＭＮ１１は、ＩＦ１１０がＭＡＧ１０２との接続を失っていることを発見し、ＬＭＡ１０１のルーティングキャッシュに何らかの問題が生じていることを把握する。ＭＮ１１は、ＬＭＡ１０１とＭＡＧ１０２との間のルーティングパスを再構成するため、非動作バインディングの回復を依頼するリカバリメッセージをＬＭＡ１０１へ送信する。このリカバリメッセージを受信したＬＭＡ１０１は、ＭＡＧ１０２及びＭＡＧ１０３の両方のエントリを回復するために“アクティブ”のマークを付ける。なお、ＬＭＡ１０１は、“アクティブ”の状態に戻す前に、ＭＡＧ１０２及びＭＡＧ１０３に対して、どのエントリがまだアクティブかを判断するための問い合わせを行うことが可能である。あるいは、ＭＮ１１がＬＭＡ１０１へのリカバリメッセージ内にどのエントリ（この場合には、ＭＡＧ１０２に関するエントリ）の回復を望んでいるかを記載し、このエントリのみを“アクティブ"の状態に戻すことも可能である。

また、本発明の別の実施の形態において、モバイルノードと、ローカルモビリティドメイン内のＡＡＡ（認証、許可、課金）サーバとの間におけるＡＡＡ処理期間中に、本発明に係る情報（の一部）が送信されてもよい。例えば、モバイルノードは、ローカルモビリティドメイン内でマルチホーミングのサポートを望んでいることをＡＡＡサーバに通知してもよい。このモバイルノードからの要望は、ＡＡＡサーバからモバイルノードのルーティングキャッシュを取り扱っているローカルモビリティキャッシュへ渡される。これにより、ローカルモビリティアンカは、モバイルノードのマルチホーミング機能を削除してしまうような登録メッセージを受信した場合に、更なる動作を行って、マルチホーミング機能が中断されないようにすることが可能である。なお、ローカルモビリティアンカによって行われるこうした動作は、本発明の方法に従って行われることが望ましい。

また、モバイルノードがＡＡＡ処理の間に、モバイルアクセルゲートウェイ及びその機能のリストに関するリクエストを行うことも可能である。これにより、モバイルノードは、接続するためのマルチホーミングをサポートしているモバイルアクセスゲートウェイを検索することが可能となる。例えば、モバイルノードのインタフェースの１つがマルチホーミングをサポートしていないモバイルアクセスゲートウェイを発見した場合には、モバイルノードは、ローカルモビリティドメインでのマルチホーミング機能を維持するために、そのインタフェースに対して、そのモバイルアクセスゲートウェイと接続を行わないように指示する。

次に、本発明を実現可能とする装置について説明する。図８は、本発明の好適な実施の形態におけるモバイルノードの機能アーキテクチャの一例を示すブロック図である。図８において、モバイルノードの機能アーキテクチャ８０は、ネットワークインタフェース８００、アプリケーション８０１、データベース８０２、機能チェックエンジン８０３、ルータバインディングエンジン８０４により構成されている。

ネットワークインタフェース８００は、任意の通信媒体を介して別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。関連する周知の技術用語を用いた場合、ネットワークインタフェース８００は、レイヤ１（物理層）及びレイヤ２（データリンク層）の通信コンポーネント、ファームウェア、ドライバ、通信プロトコルなどを表している。なお、図８にはネットワークインタフェース８００が１つのみ図示されているが、モバイルノードは１つ又は複数のネットワークインタフェース８００を有していてもよい。

また、シグナル／データパス８１０を介して、ネットワークインタフェース８００と機能チェックエンジン８０３とが相互に通信を行うことが可能であり、トリガ／パケットが伝送可能となる。例えば、ネットワークインタフェース８００で受信したルータ機能メッセージ２０は、シグナル／データパス８１０を通じて機能チェックエンジン８０３に伝送され、これにより、機能チェックエンジン８０３は、特定のモバイルアクセスゲートウェイに関する機能を特定することが可能となる。

また、シグナル／データパス８１６を介して、ネットワークインタフェース８００とルータバインディングエンジン８０４とが相互に通信を行うことが可能であり、トリガ／パケットが伝送可能となる。例えば、接続メッセージ４０は、ルータバインディングエンジン８０４からネットワークインタフェース８００へ伝送され、ネットワークインタフェース８００からローカルモビリティドメイン内のエンティティへ送信可能となる。

また、アプリケーション８０１は、通信プロトコルスタックのネットワークレイヤの上位に位置するプロトコルやプログラムを包含する機能ブロックを示している。このアプリケーション８０１は、例えば、トランスポートセッションプロトコル（ＴＣＰ：Transmission Control Protocol）、ストリーム制御トランスポートプロトコル（ＳＣＴＰ：Stream Control Transport Protocol）、ユーザデータグラムプロトコル（ＵＤＰ：User Datagram Protocol）や、他のノードとの通信に必要なプログラム及びソフトウェアなど、任意のトランスポートレイヤプロトコル又はセッションレイヤを有している。なお、図８にはアプリケーション８０１が１つのみ図示されているが、モバイルノードは１つ又は複数のアプリケーション８０１を有していてもよい。

また、シグナル／データパス８１１を介して、アプリケーション８０１とルータバインディングエンジン８０４とが相互に通信を行うことが可能であり、トリガ／パケットが伝送可能となる。例えば、アプリケーション８０１はシグナル／データパス８１１を介して、ネットワークインタフェース８００近傍に存在する特定のモバイルアクセスゲートウェイの機能情報をリクエストするようルータバインディングエンジン８０４をトリガする。

また、データベース８０２は、モバイルノードによって必要とされる情報の格納を行うことが可能である。なお、データベース８０２は、例えば、加入者ポリシ８０２０、ルーティングキャッシュ８０２１、ルータデータベース８０２２によって構成可能である。

加入者ポリシ８０２０は、通常、特定のサービスの加入者に関する情報を有している。例えば、特定のサービスの加入者に関する情報として、ローカルモビリティドメインに接続している際にモバイルノードを識別するために使用されるモバイルノード識別子（ＭＮ−ＩＤ）を用いることが可能である。ルータバインディングエンジン８０４は、接続メッセージ４０を作成する際、シグナル／データパス８１２を介して、加入者ポリシ８０２０からＭＮ−ＩＤを参照することが可能である。

また、ルーティングキャッシュ８０２１は、ローカルモビリティドメイン内でモバイルノードが維持しているモバイルアクセスゲートウェイとのアクティブな接続に関するエントリを有している。ルータバインディングエンジン８０４は、ローカルモビリティドメインにおけるモバイルノードのマルチホーミング機能を再確立するための接続メッセージ４０を作成する際、シグナル／データパス８１３を介して、ルーティングキャッシュ８０２１に格納されているすべての接続に関する情報を検索する。

また、ルータデータベース８０２２は、ローカルモビリティドメインのモバイルアクセスゲートウェイに関する情報を有している。例えば、すべてのモバイルアクセスゲートウェイ及びそれらの対応する機能のリストが、ルータデータベース８０２２に格納される。機能チェックエンジン８０３は、シグナル／データパス８１４を介して、ローカルモビリティドメイン内に存在するモバイルアクセスゲートウェイ及びそれらの対応する機能に関する情報をルータデータベース８０２２にアップデートすることが可能である。

本発明の実施の形態では、機能チェックエンジン８０３が、ルータ機能メッセージ２０に含まれる機能情報を受信する機能情報受信部として動作し、モバイルアクセスゲートウェイがマルチホーミングをサポートしているか否かをルータ機能メッセージ２０から判断することが可能である。ルータ機能メッセージ２０から判断されるモバイルアクセスゲートウェイの機能情報は、ルータデータベース８０２２に格納される。なお、機能チェックエンジン８０３は、任意の方法（例えば、ファストモバイルＩＰ）を用いて、まもなく接続しようとしているローカルモビリティアンカの機能情報を取得してもよい。

機能チェックエンジン８０３は、モバイルアクセスゲートウェイの機能情報に従って、シグナル／データパス８１５を介して、ルータバインディングエンジン８０４が行うべき適切な動作をトリガすることが可能である。例えば、モバイルアクセスゲートウェイがマルチホーミングをサポートしているのであれば、機能チェックエンジン８０３は、通常の処理と同様に、ルータバインディングエンジン８０４に対してアクセス認証処理を開始するよう依頼する。しかしながら、モバイルアクセスゲートウェイがマルチホーミングをサポートしていない場合には、機能チェックエンジン８０３は、例えば、ルータバインディングエンジン８０４に対して、まもなく行われる接続をローカルモビリティドメイン内のエンティティに通知するための接続メッセージ４０を準備するよう依頼する。

また、本発明の実施の形態では、モバイルノードがローカルモビリティドメイン内でマルチホーミング機能を確実に維持できるようにするために、ローカルモビリティドメイン内のエンティティに対して確実に通知が行われるようにする目的で、ルータバインディングエンジン８０４が導入される。ルータバインディングエンジン８０４は、マルチホーミング機能を確実に維持できるようにするための情報として、モバイルノードが接続しているローカルモビリティアンカの機能情報をローカルモビリティドメイン内のエンティティへ通知する機能情報通知部の機能を実現する。さらに、ルータバインディングエンジン８０４は、この通知とともに、処理結果を要求する確認メッセージの生成及び送信を行う確認要求部としても機能する。

本発明の実施の形態においては、マルチホーミング機能を確実に維持できるようにするための情報は、接続メッセージ４０によって通知される。この通知により、ローカルモビリティドメイン内のエンティティは、モバイルノードがマルチホーミング機能をサポートしていないモバイルアクセスゲートウェイにまもなく接続しようとしていることや、ローカルモビリティドメイン内のモバイルアクセスゲートウェイを経由するモバイルノードのすべてのアクティブな接続に関して把握できるようになる。

また、ルータバインディングエンジン８０４は、ローカルモビリティドメイン内のエンティティへ通知するための様々なメッセージ（モバイルノードの接続に関するルーティング情報の再構築を要求するメッセージ、モバイルノードのマルチホーム状態を再構成するための情報を通知するメッセージモバイルノードのルーティングエントリが削除されたと判断できる場合にそのルーティングエントリの復元を要求するメッセージなど）の生成及び送信を行う機能も有している。

なお、本明細書では、本発明が最も実用的かつ好適な実施例となるように考慮されて図示及び説明されているが、当業者であれば、上述の各装置の構成要素に係る設計やパラメータの詳細において、発明の範囲から逸脱しない程度に様々な変更が行われてもよいことは明らかである。例えば、モバイルルータが図８に図示されている機能アーキテクチャを実装してもよい。これにより、モバイルルータは、ローカルモビリティドメイン内に位置している間は、モバイルネットワーク内のノードに関するマルチホーミングのサービスを維持することが可能となる。

また、当業者であれば、モバイルノードが最初マルチホーミングをサポートしていないモバイルアクセスゲートウェイに接続している際、マルチホーミングをサポートしたモバイルアクセスゲートウェイが別のインタフェースで検出され、ローカルモビリティドメイン内でマルチホーミングを使用しようとする場合においても、本発明が適用可能であることは明らかである。この場合も、マルチホーミングをサポートしているモバイルアクセスゲートウェイからの登録メッセージが、マルチホーミングをサポートしていないモバイルアクセスゲートウェイのルーティングエントリを削除することで、同様の問題が生じる。このとき、モバイルノードはローカルモビリティドメイン内でマルチホーミングのサポートを所望している旨をローカルモビリティアンカに通知する本発明に係る方法を使用することが可能である。

さらに、当業者であれば、本発明に係る方法が、各インタフェースにおいてそれぞれ異なるタイプのモビリティプロトコルを実装しているモバイルノードに関しても有用であることが明らかである。例えば、このような場合の一例として、あるインタフェース（ＩＦ１）が、非特許文献１で説明されるようなモバイルＩＰｖ６プロトコルに関連付けられており、別のインタフェース（ＩＦ２）が非特許文献４で説明されるような拡張モバイルＩＰｖ６プロトコルに関連付けられている場合が挙げられる。この場合には、ＩＦ１からの登録メッセージによって、同一ホームエージェントに存在するＩＦ２からの登録エントリが削除されてしまう可能性がある。この場合には、モバイルノードは、モバイルノードのマルチホーミングを維持するための詳細な情報をホームエージェントに提供する前に、各インタフェースにおける機能（各インタフェースが接続しているモバイルアクセスゲートウェイの機能）の問い合わせを行ってもよい。なお、アドレス体系の差異を各ノードで整合させる必要があるが、ＩＰｖ４アドレス（モバイルＩＰｖ４プロトコルやプロキシモバイルＩＰｖ４プロトコル）との混在や、プレフィックス登録（ネットワークプレフィックスを登録の対象とする）の技術との混在においても、登録するアドレス（プレフィックス）情報のビット長や、対応するアドレスとの関連付けなどの実装の変更を行えば、有用であることは明らかである。

また、本明細書では、モバイルノードのネットワークインタフェースが複数であることを前提に説明を行っている部分があるが、本発明を実施するうえでの論理的なインタフェースが複数あればよい。例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。

また、ここでは、図示されているような簡単なネットワーク構成に基づいて本発明の説明を行ったが、ローカルネットワークドメインの構成は、複数オペレータ間のローミング関係も含めて多岐に渡ることが考えられる。例えば、モバイルアクセスゲートウェイがモバイルノードの直接的なアクセスルータである構成や、モバイルアクセスゲートウェイが異なるアクセスネットワーク（ローミングを含む）との境界ルータであり、モバイルノードはいったんその異なるアクセスネットワークに接続した後、そのアクセスネットワークを介して境界ルータであるモバイルアクセスゲートウェイに接続するという構成が考えられる。しかしながら、いずれの構成又は条件の場合においても、様々なパラメータやモバイルノードからモバイルアクセスゲートウェイへの到達手順、モバイルノードの通信手順などの設計部分が異なるものの、本発明の動作に関しては同様に適用可能であることは明白である。

また、上述の実施の形態では、ローカルモビリティ管理の環境であることが仮定されているが、モバイルルータ（ＭＲ：Mobile Router）（及びその配下のノード）により構成されたモバイルネットワーク（Mobile Network)（若しくは階層化されたモバイルネットワーク）に本発明を適用することも可能である。

例えば、モバイルネットワークの構成方法の１つであるＮＥＭＯ（NEtwork Mobility)はＭＲがＨＡ（Home Agent）に移動ネットワーク（及びモバイルノード）の移動登録を行うことにより、移動端末に対するモビリティサポートを提供しているが、本明細書におけるモバイルノードがＭＲに対応する形で適用可能である。この場合、ローカルモビリティアンカはＭＲのＨＡに対応すると考えることができる。さらに、ＰＭＩＰを用いたネットワークを提供するネットワークオペレータがローミング関係などにより、ＰＭＩＰで構成しているモバイルアクセスゲートウェイ−ローカルモビリティアンカ間のトンネルを多段に用いるような場合は階層化されたモバイルネットワークに相当する。

さらに、オーバレイネットワークの環境に本発明を適用することも可能である。例えば、モバイルアクセスゲートウェイによるモバイルノードに対するモビリティサポートをｐＨＡ（Proxy HA）に対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはローカルモビリティアンカに対応すると考えることができる。

また、モバイルノードは複数の通信デバイスから構成されるものであってもよく、例えばパーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュールや非３ＧＰＰ通信デバイスモジュールを装着する場合などがあり、こうした多様なモバイルノードにおいても本発明は同等の効果を有するものである。

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

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

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

本発明は、パケット交換型データ通信ネットワークシステムにおける通信技術に適用可能であり、特に、ネットワークベースのモビリティ管理技術やモバイルノードのマルチホーミング機能を実現するための技術に適用可能である。

Claims (23)

1. ネットワークベースのモビリティ管理を行うとともにマルチホーミングをサポートするローカルモビリティドメイン内で移動を行う移動端末であって、
   複数の経路でパケットの送受信を行うことを可能とする、前記複数の経路のそれぞれに対応する複数の通信インタフェースと、
   前記複数の通信インタフェースの少なくとも１つによって前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティに対して通知する機能情報通知手段とを、
   有する移動端末。
2. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項１に記載の移動端末。
3. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立していない場合、前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項２に記載の移動端末。
4. 前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードから、前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段を更に有する請求項２に記載の移動端末。
5. 前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を、ファストモバイルＩＰを利用して取得する機能情報取得手段を更に有する請求項２に記載の移動端末。
6. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項１に記載の移動端末。
7. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへ接続するためのアクセス認証が確立している場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を、前記ローカルモビリティドメイン内のエンティティへ通知するよう構成されている請求項２に記載の移動端末。
8. 前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを要求する確認要求手段を更に有する請求項１に記載の移動端末。
9. 前記確認メッセージを受信できなかった場合には、前記ローカルモビリティドメイン内のエンティティに対して、前記移動端末の接続に関するルーティング情報の再構築を要求するルーティング再構築要求手段を更に有する請求項８に記載の移動端末。
10. 前記ローカルモビリティドメイン内のエンティティから、前記移動端末のマルチホーム状態が失われた旨の通知を受信した場合、前記移動端末のマルチホーム状態を再構成するための情報を前記ローカルモビリティドメイン内のエンティティへ通知する再構成手段を更に有する請求項１に記載の移動端末。
11. 前記ローカルモビリティドメイン内のエンティティにおけるルーティングエントリが削除されたと判断できる場合、削除されたと判断された前記ルーティングエントリの復元を要求する復元要求手段を更に有する請求項１に記載の移動端末。
12. 前記復元要求手段が、前記移動端末が接続しているマルチホーミングをサポートしている前記接続ノードに対して、前記ルーティングエントリを再構築させるための登録メッセージの再送を依頼するよう構成されている請求項１１に記載の移動端末。
13. 前記復元要求手段が、前記移動端末が接続している前記接続ノードの中から、前記登録メッセージの再送を依頼する前記接続ノードを選択するよう構成されている請求項１１に記載の移動端末。
14. 前記ローカルモビリティドメイン内の前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を収集し、リスト情報として格納する情報収集格納手段を更に有する請求項１に記載の移動端末。
15. 前記機能情報通知手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていないことが把握できた場合、まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を通知するバインディング特定情報通知手段を更に有する請求項１に記載の移動端末。
16. まもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す前記情報に、置き換えられる対象のバインディングに関連する通信インタフェースを識別する固有の識別情報が含まれている請求項１５に記載の移動端末。
17. ローカルモビリティドメインにおいて、ネットワークベースのモビリティ管理を行うとともに、前記ローカルモビリティドメインに接続する移動端末のマルチホーミングをサポートする前記ローカルモビリティドメイン内のネットワークノードであって、
    前記移動端末の通信インタフェースが前記ローカルモビリティドメイン内の接続ポイントとして機能する接続ノードへ接続する場合、前記通信インタフェースと前記接続ノードとの対応をルーティング情報として保持するルーティングキャッシュと、
    前記移動端末が保持する複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報を受信する機能情報受信手段と、
    前記機能情報受信手段で受信した前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に基づいて、前記移動端末に関するルーティング情報の更新を行うルーティング更新手段とを、
    有するネットワークノード。
18. 前記機能情報受信手段が前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードがマルチホーミングをサポートしていない旨を前記移動端末から受信した場合、前記接続ノードと前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を識別する固有の識別情報を準備する識別情報準備手段と、
    前記接続ノードから前記接続ノードと前記接続ノードとまもなく接続しようとしている前記通信インタフェースとの対応を示す情報を受信した場合に、前記通信インタフェースと前記接続ノードとの対応を示すルーティング情報に前記固有の識別情報を付加して前記ルーティングキャッシュに格納させるルーティング情報管理手段とを、
    更に有する請求項１７に記載のネットワークノード。
19. 前記機能情報受信手段が前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報を前記移動端末から受信した場合、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に関する情報に基づき、前記ローカルモビリティドメインへ接続しているすべての通信インタフェースの接続に対応するルーティング情報を前記ルーティングキャッシュに追加するルーティングキャッシュ更新手段を更に有する請求項１７に記載のネットワークノード。
20. 前記複数の通信インタフェースのうちの１つ又はすべてが接続する前記接続ノードがマルチホーミングの機能をサポートしているか否かを示す情報に対する処理結果を示す確認メッセージを前記移動端末へ送信する確認送信手段を更に有する請求項１７に記載のネットワークノード。
21. 前記移動端末に関するルーティング情報を前記ルーティングキャッシュから消去するとともに、前記移動端末のマルチホーム状態が失われた旨を前記移動端末へ通知するルーティング情報消去通知手段を更に有する請求項１７に記載のネットワークノード。
22. 前記移動端末に関するルーティング情報を消去する場合に、消去対象のルーティング情報に係るルーティングを無効にするとともに一定期間消去を保留し、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信した場合には前記消去対象のルーティング情報を有効にし、前記消去対象のルーティング情報に関する復元要求を前記一定期間内に前記移動端末から受信しなかった場合には前記一定期間経過後に前記消去対象のルーティング情報を完全に削除するルーティング情報消去手段を更に有する請求項１７に記載のネットワークノード。
23. 前記機能情報受信手段が、前記複数の通信インタフェースの少なくとも１つによってまもなく接続しようとしている前記接続ノードへの接続によって置き換えられる対象のバインディングを示す情報を前記移動端末から受信した場合、前記ルーティング更新手段が、前記置き換えられる対象のバインディングを示す情報によって特定されるバインディングを、まもなく接続しようとしている前記接続ノードに関するバインディングに置き換えるよう構成されている請求項１７に記載のネットワークノード。