JPWO2008105176A1 - 通信方法、通信システム、モバイルノード、代理ノード及び管理ノード - Google Patents

Abstract

モバイルノードがハンドオーバした場合にバインディングＩＤを取得する技術が開示され、その技術によればＭＮ１０がＮｏｎ３ＧＰＰネットワーク３０で初期起動すると、ＡＡＡサーバ５０がバインディングＩＤを生成して記憶するとともに代理ノード３１に送信し、代理ノードがバインディングＩＤが割り当てられていることを示す割り当て情報をＭＮに送信する。ＭＮが３ＧＰＰネットワーク２０にハンドオーバするとＨＡ３２にバインディングＩＤを要求し、ＨＡがＡＡＡサーバにバインディングＩＤを要求し、ＡＡＡサーバがＨＡにバインディングＩＤを送信し、ＨＡがバインディングＩＤを受信してＭＮに送信する。

Description

本発明は、モバイルノードがハンドオーバした場合にバインディングＩＤを取得するための通信方法、通信システム、モバイルノード、代理ノード及び管理ノードに関する。

ホストベースのレイヤ３移動制御プロトコルとして Mobile ＩＰｖ６（下記の非特許文献１）が存在するのに対し、ネットワークベースのレイヤ３移動制御プロトコルとして、Proxy Mobile ＩＰｖ６（下記の非特許文献２）が存在する。ホストベースのプロトコルである Mobile ＩＰｖ６では、移動ノード（Mobile Node、以下、ＭＮ）自身が移動検出から位置情報（ケアオブアドレス、バインディングキャッシュエントリ）登録までを行う。また、複数ケアオ ブアドレス登録手法（下記の非特許文献３）を用いることで、ＭＮ
が複数の通信インタフェース（以下、インタフェース）を備えている場合、それぞれのインタフェースに割り当てられる複数のケアオブアドレスを１つのホームアドレスに関連付けて登録することができる。その際には、登録されるそれぞれのバインディングキャッシュには Binding Unique Identifier （以下、ＢＩＤ又はバインディングＩＤ）が付加され、このＢＩＤはケアオブアドレスの登録・更新・削除の際に、バインディングキャッシュエントリを特定する情報として使われる。

一方、ネットワークベースの移動制御プロトコル（以下、ネットワークベースのプロトコル）では、ＭＮの移動管理がネットワーク側で行われるため、ＭＮ自身は移動制御のための処理を行う必要がなくなる。そのため、ネットワークベースのプロトコルが提供されているドメイン内のネットワークに接続しているときには、ＭＮは単なるＩＰｖ６ノードとして動作することができ、ホームエージェント（ＨＡ：Home Agent、又はＬＭＡ：Local Mobility Anchor、以下ではＨＡの方を用いる）の存在を知る必要もない。ネットワーク側に存在する代理ノード（ＰＭＩＰｖ６の場合、ＰＭＡ：Proxy Mobile Agent、又はＭＡＧ：Mobile Access Gateway、以下では代理ノード、又はＰＭＡを用いる）がＭＮのために代理で移動制御を行う。

図１に示すネットワーク構成について説明する。図１では、ネットワークベースのプロトコルが提供されているネットワーク３０（オペレータＢ）と、ネットワークベースのプロトコルが提供されていないネットワーク２０（オペレータＡ）の２つ、さらには別のネットワーク４０（オペレータＣ）が存在する。ＭＮ（モバイルノード）１０はネットワーク４０に接続可能なインタフェースＩＦ１１と、ネットワーク３０、２０の両方に接続可能なインタフェースＩＦ２２を有し、インタフェースＩＦ２２を用いてネットワーク３０、２０間をハンドオーバすることができる。また、もう一方のインタフェースＩＦ１１を用いて別のネットワーク４０に接続することができる。また、ネットワーク３０では、ネットワークベースのプロトコルとして例えばＰＭＩＰｖ６（Proxy Mobile ＩＰｖ６）が提供されており、ＭＮ１０の移動制御を担う代理ノード３１とホームエージェント（以下、ＨＡ）３２が存在する。

ＭＮ１０が２つのインタフェースＩＦ１１、ＩＦ２２を通信に利用するためには、ＨＡ３２が管理しているホームアドレスＨｏＡ１に対してそれぞれのインタフェースＩＦ１１、ＩＦ２２に対応するアドレスが転送先としてＨＡに登録されていなければならない。ネットワーク２０に接続している場合には、そのインタフェースＩＦ２２に割り当てられているアドレスがケアオブアドレスＣｏＡ１として登録されるが、ネットワーク３０に接続している場合には、代理ノード３１のアドレスがケアオブアドレスとして登録される。そのため、ＭＮ１０のインタフェースＩＦ２２がネットワーク３０に接続しているときは、代理ノード３１が位置情報登録メッセージ（Proxy Binding Update メッセージ）を送信し、ネットワーク２０に接続しているときは、ＭＮ１０自身が位置情報登録メッセージ（Binding Updateメッセージ）を送信する。このとき、ＭＮ１０のインタフェースＩＦ１１がネットワーク４０に接続している場合には、ＨＡ３２には複数のバインディングキャッシュが登録されることになるため、それぞれの位置情報登録メッセージ内のケアオブアドレスには、ＢＩＤが付加されている必要がある。
D.Johnson, C.Perkins, J.Arkko, "Mobility Support in IPv6", RFC3775, June 2004. S.Gundavelli, K.Leung, V.Devarapalli, "Proxy Mobile IPv6", draft-sgundave-mipv6-proxymipv6-00, October 2006. R.Wakikawa, T.Ernst, K.Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 2006.

ところで、ＭＮ１０のインタフェースＩＦ１１はネットワーク４０に接続しているとき、ＭＮ１０自身が位置情報の登録を行うため、登録されるケアオブアドレスＣｏＡ２には、ＭＮ１０によってセットされたＢＩＤが付加される。一方、ＭＮ１０のインタフェースＩＦ２２がネットワーク３０で初期起動した場合、代理ノード３１が位置情報を登録するため、登録されるケアオブアドレス（代理ノードのアドレス）には、代理ノード３１によってセットされたＢＩＤが付加される。また、ＭＮ１０のインタフェースＩＦ２２がネットワーク２０で初期起動した場合は、ＭＮ１０自身が位置情報の登録を行うため、登録されるケアオブアドレス（ＣｏＡ１）には、ＭＮ１０によってセットされたＢＩＤが付加される。

このため、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク３０からネットワーク２０にハンドオーバする場合、移動前の位置情報は代理ノード３１によって登録されているため、ネットワーク２０へハンドオーバした後、ＭＮ１０が位置情報を登録することになったときに、登録するＭＮ１０の移動後の位置情報に、移動前に代理ノード３１によって使われたＢＩＤを指定することができないため、その位置情報登録メッセージを受信したＨＡ３２は、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまうという問題が発生する。また、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク３０からネットワーク２０にハンドオーバする場合、ネットワーク２０へハンドオーバした後にＭＮ１０がＢＩＤを指定せずに位置情報の登録を行った場合、その位置情報登録メッセージを受信したＨＡ３２は、置き換える対象となる位置情報を特定するためのＢＩＤがメッセージ内に含まれていないため、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまうという問題も発生する。

また、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク２０からネットワーク３０にハンドオーバする場合、移動前の位置情報はＭＮ１０自身によって登録されているため、ネットワーク３０へハンドオーバした後、代理ノード３１が位置情報を登録することになったときに、登録するＭＮ１０の移動後の位置情報に、移動前にＭＮ１０によって使われたＢＩＤを指定することができないため、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまうという問題が発生する。また、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク２０からネットワーク３０にハンドオーバする場合、ネットワーク３０へハンドオーバした後に、代理ノード３１がＢＩＤを指定せずに位置情報の登録を行った場合、その位置情報登録メッセージを受信したＨＡ３２は、置き換える対象となる位置情報を特定するためのＢＩＤがメッセージ内に含まれていないため、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまい、登録されている全ての位置情報を削除してしまうという問題も発生する。

また、ＭＮ１０は、ネットワーク３０に接続したときに、自身のホームプレフィックスが含まれる Router Advertisement を受信するため、ホームネットワークに接続した際の Mobile ＩＰｖ６の処理として、ＨＡ３２に登録されているバインディングキャッシュの削除を実行してしまう。しかし、実際にはネットワークベースのプロトコルが提供されていて、代理ノード３１による位置情報の登録が行われているため、ＭＮ１０は削除処理を行ってはならない。
すなわち、従来技術においては、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新が行なわれる可能性があった。

本発明は上記従来技術の問題点に鑑み、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新を防止する通信方法、通信システム、モバイルノード、代理ノード及び管理ノードを提供することを目的とする。

本発明の通信方法は上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信方法であって、
前記モバイルノードが、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信するステップと、
前記代理ノードが、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信するステップと、
前記管理ノードが、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信するステップと、
前記代理ノードが、前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信するステップと、
前記モバイルノードが、前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの前記管理ノードに対して前記バインディングＩＤの要求メッセージを送信するステップと、
前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、
前記管理ノードが、前記バインディングＩＤを前記モバイルノードに送信するステップとを有する。
上記方法により、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

本発明の通信システムは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続する前記モバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信する手段と、
前記代理ノードが前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信する手段と、
前記モバイルノードが、前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの管理ノードに対して前記バインディングＩＤの要求メッセージを送信する手段と、
前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、
前記管理ノードが前記バインディングＩＤを前記モバイルノードに送信する手段とを有する。
上記システムにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

本発明のモバイルノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースのプロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信し、前記代理ノードが前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信した場合に、前記割り当て情報を受信する手段と、
前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの前記管理ノードに対して前記バインディングＩＤの要求メッセージを送信する手段と、
前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、前記管理ノードが前記バインディングＩＤを前記モバイルノードに送信した場合に、前記バインディングＩＤを受信する手段とを、
備えた。
上記モバイルノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

本発明の代理ノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信した場合に、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信した場合に、前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信する手段とを、
備えた。
上記代理ノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の通信方法は上記目的を達成するために、
前記バインディングＩＤ割り当て要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであり、
前記代理ノードが送信する前記バインディングＩＤが割り当てられていることを示す割り当て情報は、ＤＨＣＰリプライメッセージであることを特徴とする。

また、本発明の通信方法は上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信方法であって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信するステップと、
前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信するステップと、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信するステップと、
前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信するステップとを有する。
上記通信方法により、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の通信システムは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信する手段と、
前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信する手段とを有する。
上記通信システムにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明のモバイルノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信し、前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信した場合、前記バインディングＩＤを受信する手段とを有する。
上記モバイルノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の代理ノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信した場合、前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信した場合、前記バインディングＩＤを受信して前記モバイルノードに対して送信する手段とを有する。
上記代理ノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の通信方法は上記目的を達成するために、
前記バインディングＩＤ要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであり、
前記代理ノードが送信する前記バインディングＩＤは、ＤＨＣＰリプライメッセージに含まれることを特徴とする。

また、本発明の通信方法は上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信方法であって、
前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信するステップと、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶するステップと、
前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信するステップと、
前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信するステップと、
前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信するステップとを有する。
上記通信方法により、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明の通信システムは上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムであって、
前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶する手段と、
前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信する手段とを有する。
上記通信システムにより、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明のモバイルノードは上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信する手段を備えて、前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶するようにし、
前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信する手段を備えて、前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信するようにした。
上記モバイルノードにより、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明の代理ノードは上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ要求を受信して、前記バインディングＩＤを生成して記憶し、前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信した場合、前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信した場合、前記バインディングＩＤを受信する手段とを有する。
上記代理ノードにより、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明の通信方法は、前記バインディングＩＤ取得要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであることを特徴とする。
また、前記代理ノードが前記バインディングＩＤを前記モバイルノードに対して送信する場合、前記代理ノードが前記モバイルノードからのＤＨＣＰレスポンスメッセージに応答するＤＨＣＰリプライメッセージで送信することを特徴とする。
また、前記代理ノードが前記バインディングＩＤを前記モバイルノードに対して送信する場合、前記代理ノードが前記モバイルノードからのアクセス認証要求メッセージに応答するアクセス認証完了メッセージで送信することを特徴とする。

また、本発明の通信方法は、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信方法であって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信するステップと、
前記バインディングアップデートメッセージを受信した前記管理ノードが、前記置換された位置情報に対応するバインディングＩＤを前記モバイルノードに送信するステップとを、
有する。

また、本発明の通信システムは、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムであって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信する手段と、
前記バインディングアップデートメッセージを受信した前記管理ノードが、前記置換された位置情報に対応するバインディングＩＤを前記モバイルノードに送信する手段とを、
備えた。

また、本発明のモバイルノードは、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムにおける前記モバイルノードであって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信する手段と、
前記バインディングアップデートメッセージを受信した前記管理ノードから、前記置換された位置情報に対応するバインディングＩＤを受信する手段とを、
備えた。

また、本発明の管理ノードは、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムにおいて前記位置情報を管理する管理ノードであって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報と供に前記モバイルノードから受信する手段と、
前記置換した位置情報に対応するバインディングＩＤを前記モバイルノードに送信する手段とを、
備えた。

本発明によれば、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができるので、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新を防止することができる。
また、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができるので、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新を防止することができる。

本発明の第１の実施の形態並びに従来の技術におけるネットワークの構成を示すブロック図 本発明の第１の実施の形態における通信シーケンスを示す説明図 本発明の第１の実施の形態におけるモバイルノードの構成を示すブロック図 本発明の第１の実施の形態における代理ノードの構成を示すブロック図 本発明の第１の実施の形態におけるＡＡＡサーバの構成を示すブロック図 本発明の第２の実施の形態における通信シーケンスを示す説明図 本発明の第３の実施の形態における通信シーケンスを示す説明図 本発明の第３の実施の形態におけるモバイルノードの構成を示すブロック図 本発明の第３の実施の形態における代理ノードの構成を示すブロック図 本発明の第４の実施の形態におけるネットワークの構成を示すブロック図 本発明の第４の実施の形態における通信シーケンスを示す説明図 図１のネットワークの変形例を示すブロック図 図１のネットワークの他の変形例を示すブロック図 図３のＩＫＥリクエストメッセージ生成部の処理を説明するためのフローチャート 本発明の第１の実施の形態におけるホームエージェントの構成を示すブロック図 本発明の第５の実施の形態におけるネットワークの構成を示すブロック図 図１６のネットワークの変形例を示すブロック図 図１６のネットワークの他の変形例を示すブロック図 本発明の第５の実施の形態におけるＩＫＥリクエストメッセージ生成部の処理を説明するためのフローチャート 本発明の第５の実施の形態におけるネットワーク構成の具体例を示すブロック図 図２０のＬＭＡが保持するＭＮのバインディングキャッシュ・エントリ（ＢＣＥ）を示す説明図 本発明の第６の実施の形態におけるネットワークの構成を示すブロック図 本発明におけるＢＵメッセージのフォーマットの一例を示す説明図 本発明におけるＢＵメッセージのフォーマットの他の例を示す説明図 本発明の第７の実施の形態における通信シーケンスを示す説明図 本発明の第７の実施の形態におけるモバイルノードの構成を示すブロック図 本発明の第７の実施の形態におけるＲＳメッセージを示す説明図 本発明の第７の実施の形態におけるモバイルノードの処理を示すフローチャート 本発明の第７の実施の形態における代理ノードの構成を示すブロック図 本発明の第７の実施の形態におけるホームエージェントの構成を示すブロック図 本発明の第８の実施の形態における通信シーケンスを示す説明図

以下、図面を参照して本発明の実施の形態について説明する。
図１は本発明の第１の実施の形態におけるネットワークの構成を示すブロック図であり、ネットワークベースのプロトコルが提供されていないネットワーク４０は一例として、セルラなどの３ＧＰＰ（3rd Generation Partnership Project）ネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。ネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。

また、図１２に示すように、ネットワーク４０とネットワーク３０は、同一のオペレータＡによって提供されていてもよく、その場合、ホームエージェント３２はネットワーク２０、３０、４０のすべてにとって共通のホームエージェントとなる。オペレータＡが提供するネットワーク４０は一例として、セルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。オペレータＢのネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。図１２におけるオペレータＡを３ＧＰＰオペレータとし、オペレータＢをＮｏｎ３ＧＰＰオペレータと想定してもよい。

さらに、図１３に示すように、ネットワーク２０、３０、４０のすべてが同一のオペレータＡによって提供されていてもよく、その場合も、ホームエージェント３２はネットワーク２０、３０、４０のすべてにとって共通のホームエージェントとなる。ネットワーク４０は一例としてセルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。ネットワークベー スのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。なお、図１、図１２、図１３において、ネットワーク３０とネットワーク４０に接続した際に取得するアドレスは、同じアドレスであってもよい。その場合オペレータＡは、ＭＮ１０のＩＦ１１及びＩＦ２２が接続しているオペレータＡ内での移動を管理する機能を持つ。

なお、上記のネットワーク構成において、ネットワーク２０及びネットワーク４０はネットワークベースのプロトコルが提供されていないネットワークとしているが、ネットワークベースのプロトコルが提供されているがＭＮ１０はそれを使用していないという場合でもよい。すなわち本発明の第１の実施の形態におけるＭＮは、ネットワーク３０ではネットワークベースのプロトコルを使用し、ネットワーク２０では使用していない。

図２は本発明の第１の実施の形態における通信シーケンスとして、ＭＮ１０がネットワーク３０で初期起動してネットワーク３０の代理ノード３１（ＰＭＡ：Proxy Mobile Agent、ＭＡＧ：Mobile Access Gateway、以下では代理ノード、ＰＭＡのいずれかを用いるが同じものを指す）によりＢＩＤが指定された後に、ネットワーク２０にハンドオーバした場合の通信シーケンスを示す。なお、図２における丸付き数字は、本明細書では括弧付き数字で示す。

＜ネットワーク３０で初期起動した場合＞
（１）アクセス及びモビリティ認証
・ＭＮ１０はネットワーク３０で初期起動すると、ＰＭＡ３１に対してアクセス認証要求メッセージ（以下の説明及び通信シーケンス図では、「メッセージ」は省略）を送信する。
・ＰＭＡ３１はＭＮ１０からのアクセス認証要求を受信すると、ＡＡＡ（Authentication, Authorization, Accounting）サーバ５０に対してＡＡＡリクエスト（request）でＭＮ認証要求を送信する。
・ＡＡＡサーバ５０はＰＭＡ３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、ＢＩＤ２を生成し、ＢＩＤ２を割り当てたＭＮ１０とＰＭＡ３１を記憶して、ＰＭＡ３１に対して、ＡＡＡ reply で認証ＯＫ、MobileIPv6 ＯＫ、ＢＩＤ２を通知する。
・ＰＭＡ３１はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してアクセス認証完了を通知する。

（２）ＰＭＡによる位置登録、アドレス割り当て
・ＰＭＡ３１はＨＡ３２に対して、Proxy ＢＵ（Binding Update）を送信してＰＭＡ３１のアドレス（ＰＭＡ addr）とＢＩＤ２を登録する。
・ＨＡ３２がこの受信後、ＡＡＡサーバ５０に対してＡＡＡ Query を送信し、ＡＡＡサーバ５０がＡＡＡ Query を受信して、ＨＡ３２に対してＡＡＡ Reply を送信することにより、ＰＭＡ認証プロセスを実行する。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ Reply を受信すると、ＰＭＡ３１に対してProxy ＢＡ（Binding Acknowledgement）を送信する。
・ＰＭＡ３１はＨＡ３２から位置登録ＯＫを示す Proxy ＢＡを受信すると、ＭＮ１０に対してＲＡ（Router Advertisement）を送信して Home Prefix とＭフラグを通知する。
・ＭＮ１０はＰＭＡ３１からのＲＡを受信すると、ＰＭＡ３１に対してＤＨＣＰ（Dynamic Host Configuration Protocol）request を送信する。
・ＰＭＡ３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信して、ＭＮ１０へ割り当てるアドレスとともに、ＨＡ３１のアドレス（ＨＡ address）と、ＰＭＩＰネットワークに位置していることを示すＩｓＰＭＩＰ情報と、ＢＩＤが割り当てられていることを示すＢＩＤ割り当てＯＫ（ＢＩＤAllocＯＫ）を通知する。
なお、ＩｓＰＭＩＰ情報及びＢＩＤ Alloc情報はＲＡの中に含まれていてもよい。また、ＲＡのＭフラグがセットされていない場合には、ＭＮ１０はアドレスを自動生成し、ＤＨＣＰによる取得は行わなくてよい。

ＭＮ１０はＰＭＡ３１からのＤＨＣＰ reply を受信すると、ＩｓＰＭＩＰ情報により以下を認識する。
・ネットワークベースの移動制御プロトコル（ＰＭＩＰ）が提供されている。
・割り当てられたアドレスがＨｏＡである。
また、ＭＮ１０はＢＩＤAlloc情報により以下を認識する。
・他のＩＦのＣｏＡを登録できる。

＜ネットワーク２０にハンドオーバ＞
ＭＮ１０はネットワーク２０にハンドオーバすると、ＩｓＰＭＩＰ情報により以下を認識する。
・ＨｏＡ取得不要
また、ＭＮ１０はＢＩＤAlloc情報により以下を認識する。
・ＢＩＤ取得可能。

（３）ＳＡ（Security Association）の生成：ＩＫＥ（Internet Key Exchange）ｖ２
・ＭＮ１０はネットワーク２０にハンドオーバすると、ＨＡ３２に対して、ＩＫＥリクエストメッセージであるＩＫＥ＿ＡＵＴＨを送信してＢＩＤを要求する。
・ＨＡ３２がＭＮ１０からのＩＫＥ＿ＡＵＴＨを受信して、ＡＡＡサーバ５０に対してＡＡＡ request を送信してＭＮ認証とＢＩＤを要求し、ＡＡＡサーバ５０がこのＡＡＡ request を受信して、ＨｏＡに対応 するＢＩＤを選択し、ＨＡ３２に対してＡＡＡ replyを送信して認証ＯＫとＢＩＤ２を通知することにより、Mobile ＩＰｖ６初期化プロセスを実行する。このとき、ＡＡＡサーバ５０は既に登録されているＢＩＤがあれば、そのＢＩＤは以前にＰＭＡ３１が要求したものであるのでそれを返す。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してＩＫＥレスポンスメッセージであるＣＦＧ＿ＲＥＰＬＹを送信してＢＩＤ２を通知する。
なお、ＭＮ１０は、ハンドオーバ前のネットワーク３０に接続中にＩＫＥｖ２を開始してもよい。その場合、ネットワーク２０へハンドオーバしてアクセス認証が完了した後すぐに、ＢＵメッセージを送信して位置情報の登録を行うことができる。

（４）位置登録
・ＭＮ１０はＨＡ３２からのＣＦＧ＿ＲＥＰＬＹを受信すると、ＨＡ３２に対してＢＵを送信して Addr2 とＢＩＤ２を登録する。
・ＨＡ３２はＭＮ１０からのＢＵを受信すると、登録されているＭＮ１０の位置情報の中から、ＢＩＤ２に対応する位置情報を更新して、ＭＮ１０に対してＢＡを送信して位置登録ＯＫを通知する。

図３はＭＮ１０の構成を示すブロック図である。ＭＮ１０は前述したインタフェースＩＦ１１、ＩＦ２２の他、送信部１０１と、受信部１０２と、ＤＨＣＰリクエストメッセージ生成部１０３と、Binding Update（ＢＵ）メッセージ生成部１０４と、ＩＫＥリクエストメッセージ生成部１０５と、ＲＳ（Router Solicitation）送信処理部１０６と、ネットワーク接続検出部１０７と、アクセス認証処理部１０８と、ＲＡ（Router Advertisement）処理部１０９と、ＤＨＣＰメッセージ処理部１１０と、ＩＫＥレスポンスメッセージ処理部１１１と、ＢＡ（Binding Acknowledgement）メッセージ処理部１１２と、登録済位置情報保持部１１３と接続ネットワーク情報保持部１１４を有する。

以下では、ＭＮ１０が備える主要構成要素について説明する。ＲＳ送信処理部１０６は、アクセス認証処理部１０８からアクセス認証が完了したことの通知を受けて、接続しているネットワーク２０又は３０又は４０に対してＲＡメッセージの送信を要求するためのＲＳメッセージを生成して送信部１０１に対して送信するよう指示する。なお、ＲＳメッセージは、送信する前にＲＡメッセージを受信することができた場合は、送信する必要はない。ＤＨＣＰリクエストメッセージ生成部１０３は、アクセス認証処理部１０８からアクセス認証が完了したことの通知を受けたとき、あるいはＲＡ処理部１０９からＤＨＣＰ開始の指示を受けたときに、接続しているネットワーク２０又は３０又は４０に対してＤＨＣＰリクエストメッセージを生成して送信部１０１に対して送信するよう指示する。

ＩＫＥリクエストメッセージ生成部１０５は、ＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした後、アクセス認証処理部１０８からアクセス認証が完了したことの通知を受けて、自身のホームエージェントとの間で Security Association（ＳＡ）を生成するためにＩＫＥｖ２を開始する。その際に、図１４に示す判断を行い、ＢＩＤの取得・通知を要求するためのメッセージとしてＩＫＥリクエストメッセージ（ＣＦＧ＿ＲＥＱＵＥＳＴ）を生成し、その中にＢＩＤの通知を要求する情報を付加して送信する。

図１４に示す判断処理について説明する。ネットワーク間を移動すると（ステップＳ１）、移動先ネットワークにネットワークベースのプロトコル（ネットワークベースの移動制御プロトコル）があるか否かを判断する（ステップＳ２）。ここで、ある場合は、ＭＮ１０のホームプレフィックスが広告され、ない場合にはフォリンプレフィックス(foreign prefix)が広告されているので、この判断を行うことができる。ステップＳ２で移動先ネットワークにネットワークベースプロトコルがない場合には、後述するステップＳ７に進む。他方、ある場合には、その移動先ネットワークが移動前ネットワークと同一ドメインか否かを判断する（ステップＳ３）。ここで、同一ドメインの場合には、移動前ネットワークと同じホームプレフィックスが移動先ネットワークで広告されているので、この判断を行うことができる。ステップＳ３で同一ドメインの場合には、移動制御を行わない（ステップＳ４）。他方、ステップＳ３で同一ドメインでない場合には、移動先ネットワークのネットワークベースプロトコルに切り替えるか否かを判断し（ステップＳ５）、切り替える場合にはホームアドレスを切り替えるが、移動制御を行わない（ステップＳ６）。他方、切り替えない場合にはステップＳ７に進む。

ステップＳ７では移動前のネットワークのＨＡを使用するか否かを判断し、使用しない場合には別のＨＡへＢＵを送信し、移動制御を行う（ステップＳ８）。なお、ステップＳ８において、別のＨＡへＢＵを送信せずに、移動制御を行わないという選択をしてもよい。他方、移動前のネットワークのＨＡを使用する場合には、移動前ネットワークではネットワークベースプロトコルを使用していたか否かを判断する（ステップＳ９）。そして、使用していた場合には、移動前ネットワークから接続中に使用されていたＢＩＤを取得し（ステップＳ１０）、次いでこの取得したＢＩＤを含むＢＵを送信する（ステップＳ１２）。他方、ステップＳ９で使用していなかった場合には、移動前ネットワークから、新たなＢＩＤを取得し（ステップＳ１１）、次いでこのＢＩＤを含むＢＵを送信する（ステップＳ１２）。なお、ステップＳ１１において、移動前ネットワークで自ら移動制御を行っていた場合には、移動前ネットワークで使用していたＢＩＤを引き続き使用する。

ＩＫＥレスポンスメッセージ処理部１１１は、ＩＫＥリクエストメッセージ（ＣＦＧ＿ＲＥＱＵＥＳＴ）に対する応答であるレスポンスメッセージ（ＣＦＧ＿ＲＥＰＬＹ）の中に含まれているＢＩＤを取得し、接続ネットワーク情報保持部１１４に対して保持するよう指示する。なお、ＢＩＤの取得・通知を要求するメッセージとしては、ＲＳメッセージや、ＮＳ（Neighbor Solicitation）メッセージ、ＤＨＣＰ requestメッセージ、さらにはＢＵメッセージでもよい。その場合、ＭＮ１０は、それらのメッセージの中にＢＩＤの通知を要求する情報（フラグなど）を付加して送信し、それを受けたＰＭＡ３１は、認証結果保持部１４２や、バインディングアップデートリストからＭＮ１０の位置情報登録に使用しているＢＩＤを取得し、ＲＡメッセージや、ＮＡ（Neighbor Advertisement）メッセージ、ＤＨＣＰ replyメッセージ、ＢＡメッセージを用いてそのＢＩＤをＭＮ１０へ通知する。これらのメッセージは、移動後に限らず、移動前つまりネットワーク３０に接続中に送信されてもよい。

Binding Update メッセージ生成部１０４は、ＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした後、ＩＫＥレスポンスメッセージ処理部１１１からＳＡ生成及びＢＩＤの取得が完了したことの通知を受けて、自身で位置情報を登録するときに、接続ネットワーク情報保持部１１４に保持されているネットワーク３０から割り当てられたＢＩＤを取得し、そのＢＩＤを付加してケアオブアドレスを登録するためのＢＵメッセージを生成する。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用する場合、Binding Updateメッセージ生成部１０４は、ＢＩＤが付加されていないＢＵメッセージをＨＡ３２へ送信し、それを受けたＨＡ３２が、以前ＰＭＡ３１によって登録された位置情報を特定し、その位置情報を新しい位置情報で置き換えると共に、旧位置情報に付加されていたＢＩＤをＢＣ（Binding Cache：バインディングキャッシュ）から取得し、そのＢＩＤをＢＡメッセージに含めて送信する。
また、ＨＡ３２は、置き換え対象である位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバや、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。このＢＡメッセージを受けたＭＮは、受信したＢＡメッセージに含まれているＢＩＤを、以降の位置情報の登録の際に使用する。この場合のＢＵメッセージ３００には、図２３に示すように、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４がＢＩＤの取得を要求することを示す情報として使われてもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。
ＢＡメッセージ処理部１１２は、Binding Update メッセージ生成部１０４によって生成・送信された、ＩＦ２２の位置情報とネットワーク３０から割り当てられたＢＩＤを含むＢＵメッセージに対する応答であるＢＡメッセージの受信に関する処理を行う。ＢＡメッセージには、位置情報の登録が完了したことを示す情報が含まれており、登録位置情報保持部１１３に対して、ＨＡ３２に登録した位置情報を保持するよう指示する。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用した場合、ＢＡメッセージには、位置情報の登録完了を示す結果と共にネットワーク３０から割り当てられたＢＩＤが含まれており、登録位置情報保持部１１３に対して、割り当てられたＢＩＤと共にＨＡ３２に登録した位置情報を保持するよう指示する。登録位置情報保持部１１３は、ＢＡメッセージ処理部１１２から指示を受け、登録済みである位置情報を示す情報として、登録した位置情報を保持する。なお、ＢＡメッセージによって割り当てられたＢＩＤを取得する場合は、ＢＩＤも保持する。

ＲＡ処理部１０９は、接続するネットワーク２０、３０、４０上のルータ（ＰＭＡ３１など）から受信したＲＡメッセージの処理を行い、このＲＡメッセージの中に含まれているＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報（ＢＩＤAlloc情報）を取得し、接続ネットワーク情報保持部１１４に保持するよう指示する。ＩｓＰＭＩＰ情報は、ネットワーク２０、３０、４０側が、ネットワークベースの移動制御プロトコルを提供しているネットワークであるかどうかをＭＮ１０に対して示すための情報であり、フラグなどを用いてその情報を示すことができる。フラグはＲＡメッセージの Reserved フィールドに新たなＩｓＰＭＩＰフラグを設けてもよい。また、ＲＡメッセージに付加される Prefix Information Option の中の Reserved フィールドであってもよい。なお、ＢＩＤの取得・通知を要求するためのメッセージとしてＲＳメッセージを使用した場合、受信するＲＡメッセージにはＢＩＤが含まれているため、ＲＡ処理部１０９は、ＩＫＥレスポンスメッセージ処理部１１１と同様に、取得したＢＩＤを接続ネットワーク情報保持部１１４に対して保持するよう指示する。

ＩｓＰＭＩＰ情報がセットされているＲＡメッセージをネットワークから受信した場合、ＭＮ１０は、接続しているネットワークではネットワークベースの移動制御プロトコル（ＰＭＩＰ）が動作していること、さらには取得したアドレスが自身のホームアドレスであることを認識する。そのため、ＭＮ１０は、ネットワーク３０に接続しているＩＦ２２に関する位置情報の登録を自身で行う必要がないため、ホームエージェント３２のアドレスを知るための処理や、ホームエージェント３２との間に Security Association を生成するための処理を行う必要がないことを認識する。特に、ＩＦ１１がネットワーク４０に接続していないときには、ＭＮ１０がネットワーク３０に接続しているときであればホームエージェント３２のアドレスを一切知る必要はないためこの効果は大きい。ＩＦ２２がハンドオーバした後には、自身で位置情報を登録しなければならないため、ホームエージェント３２のアドレスを知る必要があるが、それでもハンドオーバ前に行う必要はなく、ハンドオーバ後でも行うことができるため、ＭＮ１０はネットワーク３０に接続中はホームエージェント３２のアドレスを知る必要はない。

しかし、ＩＦ１１がネットワーク４０に接続しているときには、たとえＩＦ２２がネットワーク３０に接続しているときであっても、自身でＩＦ１１の位置情報を登録するためにホームエージェント３２のアドレスを知らなければならないため、ＭＮ１０はホームエージェント３２のアドレスの取得を行う必要がある。このホームエージェント３２のアドレスの取得方法としては、主なものとして以下の３つがある。なお、図２のシーケンス図では、（１）の場合を示している。
（１）ＭＮ１０は、ハンドオーバ前に接続しているネットワーク３０経由でホームエージェント３２のアドレスを取得する、
（２）ハンドオーバ後に接続するネットワーク２０経由でホームエージェント３２のアドレスを取得する、さらには
（３）ＩＦ１１が接続しているネットワーク４０経由で取得する。

ハンドオーバ前に取得する場合には、アクセス認証プロセスの中で、ＡＡＡサーバ５０がＭＮ１０にホームエージェント３２を割り当てて、代理ノード３１へその結果を通知し、最終的にＭＮ１０は、ＤＨＣＰを用いてネットワーク３０側から割り当てられたホームエージェント３２のアドレスを取得することができる。またハンドオーバ後に取得する場合には、接続ネットワークに対するアクセス認証が完了した後に、ＤＮＳ（Domain Name System）サーバ（不図示）に対してホームエージェント３２を提供するオペレータのドメイン名を問い合わせてホームエージェント３２のアドレスを取得する。また、ネットワーク４０経由で取得する場合も同様に、ＤＮＳサーバへの問い合わせでホームエージェント３２のアドレスを取得することができる。

第１の実施の形態におけるＭＮ１０は、上記３つのいずれかを使ってホームエージェント３２のアドレスを取得してもよいが、ネットワーク３０経由で取得する場合、ＤＨＣＰレスポンスメッセージには、ＭＮ１０に割り当てられるアドレスとともに、ホームエージェント３２のアドレスも含まれている。そのため、ＭＮ１０はホームエージェント３２のアドレスのプレフィックスと、自身の割り当てられたアドレス又はＲＡメッセージの中のプレフィックスを比較し、両者が一致した場合には割り当てられたアドレスがホームアドレスであることを認識することもできる。

しかし、この場合は、ホームネットワークであることは認識できるが、ネットワークベースの移動制御プロトコルが提供されているネットワークであるかどうかは依然として分からないため、ＩｓＰＭＩＰ情報が存在しない場合には、Mobile ＩＰｖ６又は複数ケアオブアドレス登録手法で規定されているホームネットワークに接続したときの動作（ＨＡ３２に登録しているバインディングキャッシュをすべて削除、又はホームプレフィックスからケアオブアドレスを生成して登録、さらにはホームネットワークに接続していることを示す情報を登録など）を行おうとしてしまう。しかしＩｓＰＭＩＰ情報をＭＮ１０へ通知することでこれを回避することができる。

また、ＢＩＤ Allocation 情報は、ネットワークベースの移動制御プロトコルを提供している代理ノード３１が、ＭＮ１０のための位置情報をホームエージェント３２へ登録する際にＢＩＤを付加して登録したかどうか、すなわちＭＮ１０は複数ケアオブアドレスの登録が許可されているノードかどうか、を示す情報であり、フラグなどを用いてその情報を示すことができる。ＢＩＤ Allocation 情報がセットされているＲＡメッセージをネットワークから受信した場合、ＭＮ１０はネットワーク３０側の代理ノード３１によってＢＩＤが付加された位置情報がホームエージェント３２に登録されていること、さらには、ＳＡを生成する際にＢＩＤを要求すれば、代理ノード３１が使用したＢＩＤを知ることができることを認識する。

そのため、ＩＦ２２がハンドオーバしてネットワーク２０に接続したときに、自身で登録する位置情報に付加するＢＩＤを、代理ノード３１によって付加されたＢＩＤと同じ値にし、既に登録されているバインディングキャッシュを新たなアドレスで上書きするために、ＭＮ１０はＩＫＥｖ２を行ってＢＩＤを取得する。ＢＩＤ Allocation 情報は、ホームエージェント３２に登録されているバインディングキャッシュにＢＩＤが付加されているかどうかだけを示す情報であるため、フラグなどの必要最小限の情報で構成することができる。これにより、ＭＮ１０のＩＦ２２がオペレータＢのネットワーク３０以外に接続しないときには、代理ノード３１によって使われた実際のＢＩＤを知る必要はなく、付加されたか否かだけを知れば十分であるため、ＢＩＤ Allocation 情報は効果的である。

また、ＲＡ処理部１０９は、ＲＡメッセージ内のＭフラグがセットされている場合には、ＤＨＣＰリクエストメッセージ生成部１０３に対してＤＨＣＰリクエストメッセージを生成するよう指示する。なお、ＲＡメッセージに含まれるＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報は、ＤＨＣＰメッセージ処理部１１０が生成するＤＨＣＰレスポンスメッセージの中に含まれていてもよい。特に、ＭＮ１０自身がアドレスを自動生成する場合は、ＤＨＣＰを使わないため、ネットワーク側はＲＡメッセージを接続ネットワーク情報の通知手段として使用できる。一方、ＭＮ１０がＤＨＣＰを用いてアドレスの割り当てを受ける場合には、ネットワーク側はＤＨＣＰレスポンスメッセージを情報の通知手段として使用できる。また、ＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報を示す手段としては、フラグだけでなく、ＲＡメッセージやＤＨＣＰレスポンスメッセージに付加可能なオプションとして示されてもよい。

アクセス認証処理部１０８は、ネットワーク接続検出部１０７からアクセスネットワークに接続したことの通知を受け、そのネットワークに対する認証処理を開始するためのアクセス認証リクエストをネットワークに対して送信し、その認証結果をネットワークから受信する。その認証結果がＭＮ１０の接続を許可するものであった場合には、ＲＳ送信処理部１０６、ＤＨＣＰリクエストメッセージ生成部１０３、ＩＫＥリクエストメッセージ生成部１０５に対して認証の完了を通知する。アクセス認証では、ＩＥＥＥ８０２．１ｘやＩＥＥＥ８０２．１１ｉなどの方法が用いられ、認証方式としては、ＥＡＰ−ＭＤ５、ＥＡＰ−ＴＬＳ、ＥＡＰ−ＴＴＬＳ、ＥＡＰ−ＰＥＡＰなどが用いられる。アクセス認証部１０８が生成するアクセス認証要求メッセージは特に新しい情報を持たないが、ＰＭＡ３１が送信する認証リクエストメッセージのトリガとなり、さらにその後のＡＡＡサーバによるＢＩＤ割り当てをトリガするメッセージでもある。このためＭＮ１０およびＰＭＡ３１にとっては、ＢＩＤの割り当てを要求するためのメッセージとみなすことができる。なお、アクセス認証要求メッセージの中に明示的にＢＩＤの割り当てを要求する情報を含めてもよい。

図４は本発明の第１の実施の形態における代理ノード（ＰＭＡ）３１の構成を示す図である。代理ノード３１はネットワークとの通信インタフェースであるインタフェース１３１と、送信部１３２と、受信部１３３と、認証リクエストメッセージ生成部１３４と、アクセス認証結果通知メッセージ生成部１３５と、代理 Binding Update（ＢＵ）メッセージ生成部１３６と、ＤＨＣＰ reply メッセージ生成部１３７と、ＲＡ 生成部１３８と、接続ネットワーク情報判断部１３９と、アクセス認証要求メッセージ処理部１４０と、認証レスポンスメッセージ処理部１４１と、認証結果保持部１４２と、代理ＢＡメッセージ処理部１４３と、ＤＨＣＰ request メッセージ処理部１４４を有する。

図４において、アクセス認証要求メッセージ処理部１４０は、ＭＮ１０からのアクセス認証要求メッセージを処理し、認証リクエストメッセージ生成部１３４に対して認証リクエストメッセージを生成し、送信するよう指示する。なお、認証リクエストメッセージには、明示的にＢＩＤの割り当て、及びＢＩＤの取得・通知を要求することを示す情報（フラグなど）を付加してもよい。認証レスポンスメッセージ処理部１４１は、ＡＡＡサーバ５０から受信した認証レスポンスメッセージを処理し、そのメッセージに含まれている認証結果とＭＮ１０に対して割り当てられたＢＩＤを取得して認証結果保持部１４２に保持する。また、アクセス認証結果通知メッセージ生成部１３５に対してＡＡＡサーバ５０から取得した認証結果をＭＮ１０へ通知するためのアクセス認証結果通知メッセージを生成するよう指示する。さらに代理ＢＵメッセージ生成部１３６に対して、認証の完了を通知する。

認証結果保持部１４２は、ＭＮの認証結果と共にＭＮ１０に割り当てられたＢＩＤを保持する。なお、ＭＮ１０に割り当てられたＢＩＤは、ＭＮ１０の管理情報を格納するＢＵＬ（Binding Update List：バインディングアップデートリスト）に保持してもよく、ＢＵＬが認証結果保持部１４２として機能していてもよい。その場合、代理ＢＡメッセージ処理部１４３から指示を受け、登録済みである位置情報を示す情報として、登録した位置情報を保持する。なお、代理ＢＡメッセージによって割り当てられたＢＩＤを取得する場合は、ＢＩＤも保持する。代理ＢＵメッセージ生成部１３６は、認証レスポンスメッセージ処理部１４１から認証完了の通知を受け、認証結果保持部１４２からＭＮ１０に対して割り当てられたＢＩＤを取得し、そのＢＩＤを付加したケアオブアドレスを登録するための代理ＢＵメッセージを生成する。なお、代理ＢＵメッセージ生成部１３６は、ＢＵＬからＭＮ１０に割り当てられたＢＩＤを取得してもよい。なお、ＢＩＤの取得・通知を要求するメッセージとして、代理ＢＵメッセージを使用してもよい。この場合、代理ＢＵメッセージ生成部１３６は、ＢＩＤが付加されていない代理ＢＵメッセージをＨＡ３２へ送信してＢＩＤの通知を要求し、それを受けたＨＡ３２が、以前ＭＮ１０によって登録された位置情報に付加されているＢＩＤをＢＣから取得し、そのＢＩＤを代理ＢＡメッセージに含めて送信する。この場合の代理ＢＵメッセージには、図２３のＢＵメッセージ３００と同様に、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４がＢＩＤの取得を要求することを示す情報として機能してもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。
さらに、ＨＡ３２は、特定した位置情報を新しい位置情報で置き換えると共に、この代理ＢＵメッセージに対して送信する代理ＢＡメッセージに、置き換え対象である位置情報に付加されているＢＩＤをＢＣ（Binding Cache：バインディングキャッシュ）から取得し、そのＢＩＤを 代理ＢＡメッセージに含めて送信する。また、置き換え対象である位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、代理ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバや、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。

代理ＢＡメッセージ処理部１４３は、代理ＢＵメッセージ生成部１３６が送信した代理ＢＵメッセージに対する応答である代理ＢＡメッセージの処理を行い、通知した位置情報が登録されたかどうかの結果を取得する。位置情報が登録された場合には、ＲＡ生成部１３８に対してＭＮ１０のホームプレフィックスを含むＲＡメッセージを送信するよう指示する。なお、ＢＩＤの取得・通知を要求するメッセージとして、代理ＢＵメッセージを使用した場合、代理ＢＡメッセージには、位置情報の登録完了を示す結果と共にネットワーク３０から割り当てられたＢＩＤが含まれており、認証結果保持部１４２に対して、割り当てられたＢＩＤと共にＨＡ３２に登録した位置情報を保持するよう指示する。
ＲＡ生成部１３８は、接続ネットワーク情報判断部１３９に対して、ＲＡメッセージに含める情報であるＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報をセットするべきかどうかを確認する。セットするべきとの判断が返ってきた場合には、ホームプレフィックスを含むＲＡメッセージにＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報をセットして送信部１３２に対して、インタフェース１３１を介してネットワークに送信するよう指示する。なお、ＭＮ１０から、ＲＳメッセージによってＢＩＤの通知要求を受けた場合、ＲＡ生成部１３８は、ＭＮ１０の位置情報の登録に使用しているＢＩＤを含むＲＡメッセージを生成してＭＮ１０へ送信する。また、ＭＮ１０からＲＳメッセージを受信しなくても、ＲＡ生成部１３８は、ＭＮ１０の位置情報の登録に使用しているＢＩＤを含むＲＡメッセージを生成してＭＮ１０へ送信してもよい。この場合、ＲＡメッセージには、ＭＮ１０のプレフィックスとＢＩＤの両方が含まれる。なお、この場合のＢＩＤは、ＰＭＡ３１がＨＡ３２又はＡＡＡサーバ５０から取得したＢＩＤでもよいし、ＰＭＡ３１自身が生成し、代理ＢＵメッセージの送信に使用するＢＩＤでもよい。
なお、ＰＭＡ３１がＭＮ１０から受信したＲＳメッセージ内に、ＢＩＤが含まれていた場合には、そのＢＩＤは、ＰＭＡ３１が位置情報を登録する際に使用してほしいＢＩＤとしてＭＮ１０が通知したＢＩＤであると認識し、認証結果保持部１４２に保持するよう指示すると共に、そのＢＩＤが正しく保持されたことを示す情報を含むＲＡメッセージを生成してＭＮ１０へ送信する。この場合、ＭＮ１０が通知するＢＩＤは、ＭＮ１０がネットワーク３０にハンドオーバする以前に、ネットワーク２０に接続していた場合には、そこで使用していたＢＩＤとなる。一方、ＭＮ１０がネットワーク３０に接続する前に、どのネットワークにも接続していなかった場合、あるいはＢＩＤを使用していなかった場合には、ＭＮ１０が新たに生成したＢＩＤとなる。

なお、ＲＡメッセージに含まれるＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報は、ＤＨＣＰ reply メッセージ生成部１３７が生成するＤＨＣＰレスポンスメッセージの中に含まれていてもよい。特に、ＭＮ１０自身がアドレスを自動生成する場合は、ＤＨＣＰを使わないため、ネットワーク側はＲＡメッセージを接続ネットワーク情報の通知手段として使用できる。一方、ＭＮ１０がＤＨＣＰを用いてアドレスの割り当てを受ける場合には、ネットワーク側はＤＨＣＰレスポンスメッセージを情報の通知手段として使用できる。また、ＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報を示す手段としては、フラグだけでなく、ＲＡメッセージやＤＨＣＰレスポンスメッセージに付加可能なオプションとして示されてもよい。なお、ＰＭＡ３１がＭＮ１０へＢＩＤを通知する場合には、ＤＨＣＰレスポンスメッセージの中にＢＩＤを含めてもよい。

接続ネットワーク情報判断部１３９は、認証結果保持部１４２に保持されているＭＮ１０の認証結果を参照し、ＭＮ１０のアクセス認証結果がＯＫであり、かつMobile ＩＰｖ６（ホームエージェント３２）の利用がＯＫの場合は、ＩｓＰＭＩＰ情報をセットするべきと判断する。アクセス認証結果がＯＫであるということは、ネットワークベースの移動制御プロトコルが提供されているネットワーク３０をＭＮ１０が利用できることを意味し、Mobile ＩＰｖ６の利用がＯＫであるということは、ＭＮ１０自身がホームエージェント３２に対して位置情報の登録を行うことができることを意味する。

そのため、ＭＮ１０の Mobile ＩＰｖ６利用がＯＫでない場合には、ＭＮ１０はホームエージェント３２を使用する権利がないため、ＩｓＰＭＩＰ情報をセットせずに、ネットワーク３０を単なるアクセスネットワークとして見せるだけでよい。しかし、ＭＮ１０が Mobile ＩＰｖ６を利用できる場合には、ネットワーク３０では代理ノード３１がＭＮ１０の代わりに位置情報の登録を行うため、ＭＮ１０はネットワーク３０ではネットワークベースの移動制御プロトコルが提供されていることを知ることで、ネットワーク３０に接続しているＩＦに関しては、自分自身で位置情報の登録をする必要がないことを認識する必要がある。

また、ＭＮ１０は、ＩｓＰＭＩＰ情報によって、ネットワーク３０で取得したアドレスが自身のホームアドレスであることも認識する。仮にＩｓＰＭＩＰ情報がない場合、ＭＮ１０は接続しているネットワークを通常のアクセスネットワークと認識するため、取得したアドレスもケアオブアドレスであると認識してしまう。そして、自身のモビリティの効果を得るために、ホームエージェント３２、あるいは他のネットワークに存在するホームエージェントのアドレスの取得を行い、そのホームエージェントに対して、取得したアドレスをケアオブアドレスとして登録しようとしてしまう。このような動作を防ぐために、ネットワーク側はＩｓＰＭＩＰ情報を用いて、ネットワーク３０ではネットワークベースのプロトコルが提供されていることをＭＮ１０へ通知する。

また、接続ネットワーク情報判断部１３９は、ＭＮ１０の複数ケアオブアドレスの登録が許可されている場合には、ＢＩＤ Allocation 情報をセットするべきと判断する。複数ケアオブアドレスの登録が許可されているということは、ＭＮ１０は、他のインタフェースに関する位置情報をホームエージェントに対して登録することができることを意味する。そのため、ＭＮ１０が、複数ケアオブアドレスの登録が許可されていない場合には、ＭＮ１０はホームエージェント３２に対して他のインタフェースに関する位置情報を登録する権利がないため、代理ノード３１がＢＩＤを付加して位置情報を登録したかどうかを通知する必要はない。

しかし、複数ケアオブアドレスの登録が許可されている場合には、ＭＮ１０はＩＦ１１に関する位置情報を登録する際にＢＩＤを付加して登録することになるため、代理ノード３１が送信する位置情報にＢＩＤが付加されているかどうか、すなわち複数ケアオブアドレスの登録が許可されているか否かを事前に知る必要がある。仮にＭＮ１０は複数ケアオブアドレスの登録が許可されていない場合、代理ノード３１が登録した位置情報にＢＩＤが付加されないため、ＢＩＤが付加されたＩＦ１１に関する位置情報を追加でホームエージェント３２へ登録することができない。そのため、ネットワーク側はＢＩＤ Allocation 情報を用いて、ＭＮ１０へ複数ケアオブアドレスの登録が許可されているかどうか、ホームエージェント３２が複数ケアオブアドレスの登録に対応しているかどうか、さらには、代理ノード３１がＢＩＤを付加して位置情報を登録したかどうかを、ＭＮ１０へ通知する。

なお、Mobile ＩＰｖ６利用がＯＫである場合は、複数ケアオブアドレスの登録もＯＫであると判断するようにしてもよいし、また、アクセス認証結果がＯＫである場合には Mobile ＩＰｖ６利用もＯＫであると判断するようにしてもよい。またさらに、アクセス認証結果がＯＫである場合には、Mobile ＩＰｖ６利用も複数ケアオブアドレスの登録もＯＫであると判断するようにしてもよい。

ＤＨＣＰ request メッセージ処理部１４４は、ＭＮ１０から受信したＤＨＣＰリクエストメッセージに関する処理を行い、ＤＨＣＰ reply メッセージ生成部１３７に対して、ＭＮ１０のホームアドレスを含むＤＨＣＰレスポンスメッセージを生成するよう指示する。なお、代理ノードはＤＨＣＰサーバであってもよいし、ＤＨＣＰリレーエージェントであってもよい。ＭＮ１０に割り当てるべきアドレスは、ネットワーク３０が提供するＤＨＣＰサーバや、ＭＮ情報の管理サーバなどから取得するようにしてもよい。

図１５は本発明の第１の実施の形態におけるＨＡ３２の構成を示すブロック図である。ＨＡ３２はインタフェース１６１と、送信部１６２と、受信部１６３と、ＢＡメッセージ生成部１６４と、ＩＫＥレスポンスメッセージ生成部１６５と、認証リクエストメッセージ生成部１６６と、代理ＢＡ（Binding Acknowledgement）メッセージ生成部１６７と、ＩＫＥリクエストメッセージ処理部１６８と、代理ＢＵ（Binding Update）メッセージ処理部１６９と、ＭＮ管理情報保持部１７０と、認証レスポンスメッセージ処理部１７１とＢＵ（Binding Update）メッセージ処理部１７２とを有する。

以下では、ＨＡ３２が備える主要構成要素について説明する。ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０から受信したＩＫＥリクエストメッセージに関する処理を行い、認証リクエストメッセージ生成部１６６に対して、ＭＮ１０の認証、及びＢＩＤの割り当て・取得・通知を要求するための認証リクエストメッセージを生成するよう指示する。また、ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０からＩＫＥリクエストメッセージを受信した際、ＡＡＡサーバ５０に対するＭＮ１０の認証が不要な場合には、認証リクエストメッセージ生成部１６６に対して認証リクエストメッセージの生成を指示せずに、ＭＮ管理情報保持部１７０からＭＮ１０へ割り当てられているＢＩＤを取得して、そのＢＩＤを含むＩＫＥレスポンスメッセージを生成するようＩＫＥレスポンスメッセージ生成部１６５へ指示する。なお、ＭＮ１０の認証が必要な場合であったとしても、ＡＡＡサーバ５０からＢＩＤを取得するのではなく、ＭＮ管理情報保持部１７０からＭＮ１０へ割り当てられているＢＩＤを取得してもよい。

認証リクエストメッセージ生成部１６６は、ＡＡＡサーバ５０に対してＭＮ１０の認証を要求するための認証リクエストメッセージを生成する。メッセージには、ＭＮを特定する情報としてＭＮ１０のＩＤ、又はホームアドレスなどが含まれる。なお、認証リクエストメッセージには、明示的にＢＩＤの割り当て、及びＢＩＤの取得・通知を要求することを示す情報（フラグなど）を付加してもよい。また、認証リクエストメッセージ生成部１６６は、ＭＮ管理情報保持部１７０が保持しているＭＮ１０の情報（Binding Cache）からＭＮ１０へ割り当てられているＢＩＤを取得し、それを認証リクエストメッセージに付加してもよい。また、メッセージの中に明示的にＭＮ１０に割り当てられているＢＩＤを要求する情報（フラグなど）を含めてもよい。

ＭＮ管理情報保持部１７０は、ＭＮ１０に関する情報として、代理ＢＵメッセージ処理部１６９から渡されたＭＮ１０の位置情報や、認証レスポンスメッセージ処理部１７１から渡されたＭＮ１０の認証結果などを保持する。ＭＮ１０の位置情報には、ＰＭＡ３１によって付加されたＢＩＤが関連付けられており、ＩＫＥリクエストメッセージ処理部１６８及びＢＵメッセージ処理部１７２からＭＮ１０に割り当てられているＢＩＤの取得要求を受けた際にそのＢＩＤを渡す。

認証レスポンスメッセージ処理部１７１は、ＡＡＡサーバ５０から受信した認証レスポンスメッセージに関する処理を行い、メッセージに含まれるＭＮ１０の認証結果と、割り当てられているＢＩＤをＭＮ管理情報保持部１７０へ渡し、保持するよう指示する。また、ＩＫＥレスポンスメッセージ生成部１６５に対して、取得したＢＩＤを含むＩＫＥレスポンスメッセージを生成するよう指示する。ＩＫＥレスポンスメッセージ生成部１６５は、ＩＫＥリクエストメッセージ処理部１６８及び認証レスポンスメッセージ処理部１７１からの指示を受け、渡されたＭＮ１０に割り当てられているＢＩＤを含むＩＫＥレスポンスメッセージを生成し、それを送信部１６２に渡して送信するよう指示する。

代理ＢＵメッセージ処理部１６９は、ＰＭＡ３１から受信した代理ＢＵメッセージに関する処理を行い、メッセージに含まれるＭＮ１０の位置情報をＭＮ管理情報保持部１７０に渡して保持するよう指示する。代理ＢＵメッセージ処理部１６９はさらに、ＭＮ１０の位置情報の登録の結果を示す情報を含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部１６７に指示する。さらに、代理ＢＵメッセージ処理部１６９は、認証リクエストメッセージ生成部１６６に対して、ＰＭＡ３１の認証を要求するための認証リクエストメッセージを生成するよう指示する。

なお、ＰＭＡ３１がＢＩＤの割当を要求するメッセージとして認証リクエストメッセージではなく代理ＢＵメッセージを使用しているとき、代理ＢＵメッセージ処理部１６９は、受信した代理ＢＵメッセージにＢＩＤが含まれていないこと、あるいはＢＩＤ要求を示す情報を確認した場合、認証リクエストメッセージ生成部１６６に対して、ＰＭＡ３１の認証、及びＢＩＤの割り当て・取得・通知を要求するための認証リクエストメッセージを生成するよう指示する。また、代理ＢＵメッセージ処理部１６９は、ＰＭＡ３１から代理ＢＵメッセージを受信した際、ＡＡＡサーバ５０に対するＰＭＡ３１の認証が不要な場合には、認証リクエストメッセージ生成部１６６に対して認証リクエストメッセージの生成を指示せずに、置き換え対象となる位置情報に付加されているＢＩＤを取得，または自らＭＮ１０に割り当てるＢＩＤを生成し、そのＢＩＤを登録するＭＮ１０の位置情報と共に保持するようＭＮ管理情報保持部１７０に指示する。さらに、ＭＮ１０の位置情報の登録の結果を示す情報と共に、生成したＢＩＤを含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部１６７に指示する。なお、ＭＮ１０の認証が必要な場合であったとしても、ＡＡＡサーバ５０からＢＩＤを取得するのではなく、置き換え対象となる位置情報に付加されているＢＩＤを取得，または自らＭＮ１０に割り当てるＢＩＤを生成してもよい。ＭＮ１０の位置情報には、ＭＮ１０を特定する情報として、ＭＮ１０のＩＤ、ホームアドレス、ホームプレフィックスなど、及びＭＮ１０の接続先としてＰＭＡ３１のアドレスが含まれる。さらに、この位置情報には、ＭＮ１０によってこの位置情報に関連付けられたＢＩＤも含まれている。

代理ＢＡメッセージ生成部１６７は、代理ＢＵメッセージ処理部１６９からの指示を受け、ＭＮ１０に関する位置情報の登録の結果を示す情報を含む代理ＢＡメッセージを生成し、送信部１６２へ渡して送信するよう指示する。また、ＰＭＡ３１がＢＩＤの割当を要求するメッセージとして代理ＢＵメッセージを使用しているとき、代理ＢＡメッセージ生成部１６７は、代理ＢＵメッセージ処理部１６９が生成したＢＩＤを含む代理ＢＡメッセージを生成し、それを送信部１６２へ渡して送信するよう指示する。

ＢＵメッセージ処理部１７２は、ＭＮ１０からのＢＵメッセージに関する処理を行い、メッセージに含まれるＭＮ１０の位置情報をＭＮ管理情報保持部１７０に渡して保持するよう指示する。また、ＭＮ１０が、割り当てられているＢＩＤの取得を要求するメッセージとしてＩＫＥリクエストメッセージではなくＢＵメッセージを使用しているとき、ＢＵメッセージ処理部１７２は、受信したＢＵメッセージにＢＩＤが含まれていないこと、あるいはＢＩＤを要求する情報を確認した場合、ＭＮ管理情報保持部１７０から、置き換え対象となる位置情報に付加されているＢＩＤを取得、または自らＭＮ１０に割り当てるＢＩＤを生成して、そのＢＩＤを含むＢＡメッセージを生成するようＢＡメッセージ生成部１６４に対して指示する。この場合のＢＵメッセージには、ＢＩＤを通知するためのオプションの中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプションが含まれていて、このオプションがＢＩＤの取得を要求することを示す情報として機能してもよいし、又はモビリティヘッダの中や、ＢＩＤを通知するためのオプション、及び代替ＣｏＡオプションの中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。

ＢＡメッセージ生成部１６４は、ＢＵメッセージ処理部１７２からの指示を受け、ＭＮ１０の位置情報の登録の結果（登録完了）を示す情報を含むＢＡメッセージを生成し、それを送信部１６２へ渡して送信するよう指示する。また、ＭＮ１０が、割り当てられているＢＩＤを取得するメッセージとしてＩＫＥリクエストメッセージではなくＢＵメッセージを使用しているとき、ＢＡメッセージ生成部１６４は、ＢＵメッセージ処理部１７２がＭＮ管理情報保持部１７０から取得したＢＩＤを含むＢＡメッセージを生成し、それを送信部１６２へ渡して送信するよう指示する。

図５は本発明の第１の実施の形態におけるＡＡＡサーバ５０の構成を示す図である。ＡＡＡサーバ５０は、ＰＭＡがＭＮ１０の位置情報を登録する際に使用するＢＩＤを割り当てる管理サーバとして機能する。ＡＡＡサーバ５０はネットワークとのインタフェース１５１と、送信部１５２と、受信部１５３と、認証レスポンスメッセージ生成部１５４と、認証判定部１５５と、認証リクエストメッセージ処理部１５６と、ＭＮ情報保持部１５７とＢＩＤ割り当て部１５８を有する。認証リクエストメッセージ処理部１５６は、代理ノード３１から受信したＭＮ１０のアクセス認証要求、及びＨＡ３２から受信した代理ノード３１の認証要求に関する認証リクエストメッセージの処理を行い、認証判定部１５５に対して認証の要求元であるＭＮ１０の認証を行うよう指示する。

認証判定部１５５は、認証リクエストメッセージ処理部１５６からの指示を受け、ＭＮ情報保持部１５７を参照し、ＭＮ１０の認証を行う。ＭＮ１０に対しネットワーク３０の利用が許可されているかどうか、Mobile ＩＰｖ６（ホームエージェント）の利用が許可されているかどうか、複数ケアオブアドレスの登録が 許可されているかどうか、などの点での認証が行われる。また、ＭＮ１０に対し複数ケアオブアドレスの登録が許可されている場合、ＩＦ２２の位置情報を登録する際に使用するＢＩＤを割り当てるために、ＢＩＤ割り当て部１５８からＭＮ１０に割り当てるＢＩＤを取得し、認証結果と共にＢＩＤを含む認証レスポンスメッセージを生成するよう認証レスポンスメッセージ生成部１５４に対して指示する。

なお、認証リクエストメッセージ処理部１５６が受信した代理ノード３１からの認証リクエストメッセージの中にＢＩＤが含まれている場合には、ＭＮ１０に割り当てたＢＩＤとして保持するようＭＮ情報保持部１５７に指示し、認証結果と共にそのＢＩＤの使用可能及び登録完了を示す認証レスポンスメッセージを生成するよう認証レスポンスメッセージ生成部１５４に対して指示する。また、受信したＨＡ３２からの認証リクエストメッセージの中にＢＩＤが含まれている場合も同様にＭＮ１０に割り当てたＢＩＤとして保持するようＭＮ情報保持部１５７に指示し、認証結果と共にそのＢＩＤの使用可能及び登録完了を示す認証レスポンスメッセージを生成するよう認証レスポンスメッセージ生成部１５４に対して指示する。

ＢＩＤ割り当て部１５８は、認証判定部１５５から指示を受け、認証対象であるＭＮ１０に対して割り当てるべきＢＩＤを生成・取得する。その際に、ＭＮ情報保持部１５７を参照し、既に割り当て済みのＢＩＤがある場合にはそれを認証判定部１５５へ返し、割り当て済みのＢＩＤがない場合には、新たに生成したＢＩＤを返し、それをＭＮ情報保持部１５７へ保持するよう指示する。認証レスポンスメッセージ生成部１５４は、認証判定部１５５からの指示を受け、通知されたＭＮ１０の認証結果と割り当てられたＢＩＤを含む認証レスポンスメッセージを生成し、送信部１５２に対して送信するよう指示する。なお、受信した認証リクエストメッセージの中に代理ノード３１が生成したＢＩＤが含まれている場合には、使用可能及び登録完了を示す認証レスポンスメッセージを生成し、送信部１５２に対して送信するよう指示する。
本発明の第１の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されているネットワークから、提供されていないネットワークへ移動した場合でも、移動前に代理ノードによって登録された位置情報を更新するために、代理ノードによって登録された位置情報に付加されているＢＩＤを使って、新たな位置情報の登録が可能となる。

＜第２の実施の形態＞
第２の実施の形態のネットワーク構成は第１の実施の形態と同じである。各エンティティの構成は第１の実施の形態とほぼ同じあり、第１の実施の形態との違いは、図６に示すようにＲＡ／ＤＨＣＰレスポンスに含まれる情報がＢＩＤ Allocation 情報ではなく、ＢＩＤそのものである点である。よってＭＮ１０はハンドオーバ後のＩＫＥｖ２でＢＩＤを要求しない。

図６に示す通信シーケンスについて説明する。
（１）アクセス及びモビリティ認証
第１の実施の形態と同じであるので、説明を省略する。
（２）ＰＭＡによる位置登録、アドレス割り当て
「Proxy ＢＵ」、「ＡＡＡ Query」、「ＡＡＡ Reply」、「Proxy ＢＡ」、「ＲＡ」、「ＤＨＣＰ request」は第１の実施の形態と同じであるので、説明を省略する。
・ＰＭＡ３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信してＨＡ３１のアドレス（ＨＡ address）と、ＩｓＰＭＩＰ情報と、ＢＩＤ２（第１の実施の形態では、ＢＩＤAllocＯＫ）を通知する。

ＭＮ１０はＰＭＡ３１からのＤＨＣＰ reply を受信すると、ＩｓＰＭＩＰ情報により以下を認識する。
・割り当てられたアドレスがＨｏＡである。
また、ＭＮ１０はＢＩＤ２により以下を認識する。
・他のＩＦのＣｏＡを登録できる。

＜ネットワーク２０にハンドオーバ＞
ＭＮ１０はネットワーク２０にハンドオーバすると、ＩｓＰＭＩＰ情報により以下を認識する。
・ＨｏＡ取得不要。

（３）ＩＫＥｖ２
・ＭＮ１０はネットワーク２０にハンドオーバすると、ＨＡ３２に対して、ＩＫＥ＿ＡＵＴＨを送信してＨｏＡを通知する（第１の実施の形態では、ＢＩＤを要求）。
・ＨＡ３２がＭＮ１０からのＩＫＥ＿ＡＵＴＨを受信して、ＡＡＡサーバ５０に対してＡＡＡ request を 送信してＭＮ認証要求とＨｏＡ（第１の実施の形態ではＢＩＤ）を送信し、ＡＡＡサーバ５０がこのＡＡＡ request を受信して、ＨＡ３２に対してＡＡＡ reply を送信して認証ＯＫを通知することにより、Mobile ＩＰｖ６初期化プロセスを実行する（第１の実施の形態ではＢＩＤを通知）。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してＣＦＧ＿ＲＥＰＬＹ を送信してＯＫ（第１の実施の形態ではＢＩＤ２）を通知する。
（４）位置登録
第１の実施の形態と同じであるので、説明を省略する。

＜第３の実施の形態＞
第３の実施の形態のネットワーク構成は第１の実施の形態と同じである。第３の実施の形態の第１の実施の形態との違いは、図７に示すようにＩｓＰＭＩＰ情報とＢＩＤがアクセス認証完了通知メッセージに含まれている点である。よって、第２の実施の形態と同じく、ＭＮ１０はハンドオーバ後のＩＫＥｖ２でＢＩＤを要求しない。

図７に示す通信シーケンスについて説明する。
（１）アクセス及びモビリティ認証
「アクセス認証要求」、「ＡＡＡ request」、「ＡＡＡ reply」は、第１の実施の形態と同じであり、よって、ＡＡＡサーバ５０はＰＭＡ３１からのＡＡＡ request（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、ＢＩＤ２を生成し、ＢＩＤ２を割り当てたＭＮ１０とＰＭＡ３１を記憶して、ＰＭＡ３１に対して、ＡＡＡ reply で認証ＯＫ、Mobile ＩＰｖ６ ＯＫ、ＢＩＤ２を通知する。
・第３の実施の形態では、ＰＭＡ３１はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してアクセス認証完了メッセージを送信してＢＩＤ２とＩｓＰＭＩＰ情報を通知する。

（２）ＰＭＡによる位置登録、アドレス割り当て
「Proxy ＢＵ」、「ＡＡＡ Query」、「ＡＡＡ Reply」、「Proxy ＢＡ」、「ＲＡ」、「ＤＨＣＰ request」は、第１の実施の形態と同じである。
・第３の実施の形態では、ＰＭＡ３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信してＨＡ３２のアドレス（ＨＡ address）を通知し、ここでは、ＩｓＰＭＩＰ情報と、ＢＩＤ割り当てＯＫ（ＢＩＤAllocＯＫ）を通知しない。以下の処理は、第２の実施の形態と同じであるので、説明を省略する。

図８は第３の実施の形態におけるＭＮ１０の構成を示し、図３に示すＤＨＣＰリクエストメッセージ生成部１０３が省略されている他は、同じ構成である。図９は第３の実施の形態における代理ノードの構成を示し、アクセス認証結果通知メッセージ生成部１３５ａとＤＨＣＰ reply メッセージ生成部１３７ａの処理が図４と異なる。なお、本発明の第１〜第３の実施の形態においては、ＡＡＡサーバ５０がＢＩＤを生成し、それを認証レスポンスメッセージで代理ノード３１へ通知しているが、別の方法として、代理ノード３１自身がＢＩＤを生成し、そのＢＩＤを使用することをＡＡＡサーバへ通知してもよい。その場合、認証リクエストメッセージ生成部１３４は、ＭＮ１０の位置情報登録の際に使用するＢＩＤを生成し、それを含む認証リクエストメッセージを生成してＡＡＡサーバへ送信する。また、この場合、ＭＮ認証プロセスではなく、代理ノード３１による位置登録及びＰＭＡ認証プロセスの中でＢＩＤを通知してもよい。その場合、代理ＢＵメッセージ生成部１３６は、ＭＮ１０に関する位置情報を登録するための代理ＢＵメッセージを生成する際にＢＩＤを生成し、メッセージに含めてＨＡ３２へ送信する。

この代理ＢＵメッセージを受けたＨＡ３２は、メッセージに含まれているＢＩＤをＡＡＡ Queryの中に含めてＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤを付加してＭＮ１０の位置情報を保持する。なお、ここでのＨＡ３２からＡＡＡサーバ５０へのＢＩＤの通知は省略してもよい。その場合、ＨＡ３２はＰＭＡ３１からの代理ＢＵメッセージに含まれるＢＩＤをバインディングキャッシュに保持し、ＭＮ１０からのＢＩＤ通知要求を受信した場合に、そのＢＩＤを通知する。また、ＭＮ１０はＨＡ３２に対して行うＩＫＥの中で、ＢＩＤを要求して、ＰＭＡ３１によって使用されたＢＩＤを取得する。

さらに別の方法として、ＨＡ３２がＢＩＤを生成し、そのＢＩＤを使用することをＡＡＡサーバへ通知してもよい。その場合、ＰＭＡ３１から代理ＢＵメッセージを受信したＨＡ３２は、ＰＭＡ３１から登録の要求を受けたＭＮ１０の位置情報に付加するＢＩＤを生成し、それを含むＡＡＡ QueryをＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤを登録されるＭＮ１０のエントリに付加して保持する。また、そのＢＩＤを代理ＢＡメッセージの中に含めてＰＭＡ３１へ送信する。ＢＩＤを含む代理ＢＡメッセージを受信したＰＭＡ３１は、以降ＭＮ１０の代理ＢＵメッセージを送信する際には、そのＢＩＤを付加して送信する。

このように、ＡＡＡサーバ５０とＨＡ３２は、ＢＩＤを生成して通知するノード、あるいは、ＢＩＤの通知を受けるノードとして機能するノードになり得るため、ネットワーク内のエンティティとして、これらの機能をすべて持つ一体化した管理ノードとみなすことができる。

また、本発明の第１〜第３の実施の形態では、ネットワーク３０からネットワーク２０へハンドオーバして接続するネットワークが変わることで、ＭＮ１０がネットワークベースのプロトコルを使用している状態から使用しない状態へ移行するケースについて記述しているが、別のケースとして、ＭＮ１０のＩＦ２２がネットワーク３０に接続しているときに、ＭＮ自身の判断による切り替え、又はネットワーク側の判断による切り替えで、ネットワークベースのプロトコルを使用している状態から使用しない状態へ切り替わるケースにも本発明の手法を適用することができる。

また、ＭＮ１０が、ハンドオーバせずにネットワークベースのプロトコルを使用している状態（ネットワーク２０へハンドオーバする前や、ネットワーク４０でネットワークベースのプロトコルが提供されているが、ＩＦ１１はハンドオーバしないとき）であっても、ネットワーク３０、及びネットワーク４０において、ホームエージェントや通信相手へフロー制御情報を登録するためにＢＩＤを必要とする場合などに、本発明の手法を使用してＢＩＤを取得することもできる。
また、不図示ではあるが、本発明の手法を使用して取得したＢＩＤは、位置情報の登録だけでなく、フロー制御情報を登録する際にも利用可能である。

＜第４の実施の形態＞
図１０は本発明の第４の実施の形態におけるネットワークの構成を示す図であり、第１の実施の形態との違いは、ハンドオーバが、ネットワーク２０からネットワーク３０へ行われる点である。各エンティティの構成や処理は第１の実施の形態と同じであるが、図１１に示すように第１の実施の形態では移動前に行っていた処理が第４の実施の形態では移動後に行われ、第１の実施の形態では移動後に行っていた処理が第４の実施の形態では移動前に行われるという点が異なる。

なお、図１０では、各ネットワークを提供するオペレータについては図示していないが、第１の実施の形態における図１と同様に、各ネットワークが異なるオペ レータによって提供されていてもよい。また、第１の実施の形態における図１２と同様に、ネットワーク４０とネットワーク３０は、同一のオペレータＡによって提供されていてもよく、その場合、ホームエージェント３２はネットワーク２０とネットワーク３０の両方にとって共通のホームエージェントとなる。オペレータＡが提供するネットワーク４０は一例として、セルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。オペレータＢのネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。

さらに、第１の実施の形態における図１３と同様に、ネットワーク２０、３０、４０のすべてが同一のオペレータＡによって提供されていてもよく、その場合、ホームエージェント３２はネットワーク２０、３０、４０のすべてにとって共通のホームエージェントとなる。ネットワーク４０は一例としてセルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。ネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。なお、上記のネットワーク構成において、ネットワーク２０はネットワークベースのプロトコルが提供されていないネットワークとしているが、ネットワークベースのプロトコルが提供されているがＭＮ１０はそれを使用していないという場合でもよい。すなわち本発明の第４の実施の形態におけるＭＮは、ネットワーク３０ではネットワークベースのプロトコルを使用し、ネットワーク２０では使用していない。

また、本発明の第４の実施の形態では、ネットワーク２０からネットワーク３０へハンドオーバして接続するネットワークが変わることで、ＭＮ１０がネットワークベースのプロトコルを使用していない状態から使用する状態へ移行するケースについて記述しているが、別のケースとして、ＭＮ１０のＩＦ２２がネットワーク２０に接続しているときに、ＭＮ自身の判断による切り替え、又はネットワーク側の判断による切り替えで、ネットワークベースのプロトコルを使用していない状態から使用する状態へ切り替わるケースにも本発明の手法を適用することができる。

図１１に示す通信シーケンスについて説明する。
・ＭＮ１０はネットワーク２０で初期起動すると、アクセス認証を行う。
（１）ＨＡアドレス取得（Split シナリオ）
・ＭＮ１０は、ＤＮＳなどを用いて、ＨＡ３２のアドレスの取得を行う。
（２）ＩＫＥｖ２
・ＭＮ１０はＨＡ３２に対して、ＩＫＥ＿ＡＵＴＨを送信してＨｏＡとＢＩＤを要求する。
・ＨＡ３２がＭＮ１０からのＩＫＥ＿ＡＵＴＨを受信して、ＡＡＡサーバ５０に対してＡＡＡ request を送信してＭＮ認証とＢＩＤを要求し、ＡＡＡサーバ５０がこのＡＡＡ request を受信して、ＢＩＤ２を生成して、そのＢＩＤ２を割り当てたＭＮ１０を記憶し、ＨＡ３２に対してＡＡＡ reply を送信して認証ＯＫとＢＩＤ２を通知することにより、初期化プロセスを実行する。このとき、ＡＡＡサーバ５０、ＨＡ３２のいずれかがＢＩＤ２を割り当ててもよい。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してＣＦＧ＿ＲＥＰＬＹ を送信してＨｏＡとＢＩＤ２を通知する。

（３）位置登録
第１の実施の形態の（４）位置登録と同じである。すなわち、
・ＭＮ１０はＨＡ３２からのＣＦＧ＿ＲＥＰＬＹを受信すると、ＨＡ３２に対してＢＵを送信して Addr2 とＢＩＤ２を登録する。
・ＨＡ３２はＭＮ１０からのＢＵを受信すると、ＭＮ１０に対してＢＡを送信して位置登録ＯＫを通知する。

ＭＮ１０がネットワーク２０からネットワーク３０にハンドオーバすると、以下の処理が行われる。
（４）アクセス及びモビリティ認証
・ＭＮ１０はネットワーク３０にハンドオーバすると、ＰＭＡ３１に対してアクセス認証要求を送信する。
・ＰＭＡ３１がＭＮ１０からのアクセス認証要求を受信してＡＡＡサーバ５０に対してＡＡＡ request でＭＮ認証要求を送信し、ＡＡＡサーバ５０がＰＭＡ３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信してＭＮに対するＢＩＤを選択し、ＰＭＡ３１に対してＡＡＡ reply で認証ＯＫ、ＢＩＤ２を通知することにより、ＭＮ認証プロセスを実行する。
・ＰＭＡ３１はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してアクセス認証完了メッセージでＭＩＰ処理不要を示すＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報を通知する。

なお、アクセス認証後に受信するＲＡや、ＤＨＣＰ reply にＩｓＰＭＩＰ情報を含めてもよい。ＭＮ１０がＰＭＡ３１に対して送信するアクセス認証要求メッセージは特に新しい情報を持たないが、ＰＭＡ３１が送信する認証リクエストメッセージのトリガとなり、さらにその後のＡＡＡサーバからのＢＩＤ取得するメッセージのトリガでもある。このためＭＮ１０およびＰＭＡ３１にとっては、ＢＩＤの取得を要求するためのメッセージとみなすことができる。なお、アクセス認証要求メッセージの中に明示的にＢＩＤの取得を要求する情報を含めてもよい。

（５）ＰＭＡによる位置登録
第１の実施の形態の（２）ＰＭＡによる位置登録、と同じである。また、アドレス登録も第１の実施の形態と同じである。
なお、本発明の第４の実施の形態においては、ＡＡＡサーバ５０がＢＩＤを生成し、それを認証レスポンスメッセージで代理ノード３１へ通知しているが、別の方法として、ＨＡ３２がＢＩＤを生成し、そのＢＩＤを使用することをＡＡＡサーバへ通知してもよい。その場合、ＭＮ１０からからＩＫＥリクエストメッセージを受信したＨＡ３２は、ＭＮ１０が位置情報を登録する際に付加するＢＩＤを生成し、それを含むＡＡＡ QueryをＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤをＩＫＥレスポンスメッセージの中に含めてＭＮ１０へ送信する。ＢＩＤを含むＩＫＥレスポンスメッセージを受信したＭＮ１０は、代理ＢＵメッセージを送信する際には、そのＢＩＤを付加して送信する。

さらに別の方法として、ＭＮ１０自身がＢＩＤを生成し、そのＢＩＤを使用することをＨＡ３２、及びＡＡＡサーバ５０へ通知してもよい。その場合、ＩＫＥリクエストメッセージ生成部１０５は、自身の位置情報登録の際に使用するＢＩＤを生成し、それを含むＩＫＥリクエストメッセージを生成してＨＡ３２へ送信する。また、この場合、ＭＮ認証プロセスではなく、ＭＮ１０による位置登録でＢＩＤを通知してもよい。その場合、ＢＵメッセージ生成部１０４は、位置情報を登録するためのＢＵメッセージを生成する際にＢＩＤを生成し、メッセージに含めてＨＡ３２へ送信する。このＢＵメッセージを受けたＨＡ３２は、メッセージに含まれているＢＩＤをＡＡＡ Queryの中に含めてＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤを付加してＭＮ１０の位置情報を保持する。なお、ここでのＨＡ３２からＡＡＡサーバ５０へのＢＩＤの通知は省略してもよい。その場合、ＨＡ３２はＰＭＡ３１からの代理ＢＵメッセージに含まれるＢＩＤをバインディングキャッシュに保持し、ＭＮ１０からのＢＩＤ通知要求を受信した場合に、そのＢＩＤを通知する。また、ＰＭＡ３１はＨＡ３２に対して行うＩＫＥ、又は代理ＢＵの中で、ＢＩＤを要求して、ＭＮ１０によって使用されたＢＩＤを取得する。

また、ＭＮ１０がネットワーク３０へハンドオーバした後、ＰＭＡ３１がＭＮ１０の位置情報登録の際に使用するべきＢＩＤを取得する方法として、ＭＮ１０の位置情報を含む代理ＢＵメッセージでＢＩＤを要求してもよい。この場合、ＰＭＡ３１からの代理ＢＵメッセージを受信したＨＡ３２は、ＭＮ１０に割り当てられたＢＩＤを要求するためにＡＡＡサーバ５０に対してＡＡＡ Queryを送信し、ＡＡＡ Replyの中に含まれているＢＩＤを登録されるＭＮ１０のエントリに付加して保持する。さらに、ＰＭＡ３１へ送信する代理ＢＡメッセージにそのＢＩＤを含めて送信する。ＰＭＡ３１は、以降代理ＢＵメッセージを送信する際には、そのＢＩＤを付加してＨＡ３２へ送信する。また、ＰＭＡ３１から代理ＢＵメッセージを受信したＨＡ３２は、ＡＡＡサーバ５０に問い合わせるのではなく、自身が保持するＢＣＥから、ＭＮ１０に割り当てられているＢＩＤを取得して、代理ＢＡメッセージでそのＢＩＤを通知してもよい。

このように、ＡＡＡサーバ５０とＨＡ３２は、ＢＩＤを生成して通知するノード、あるいは、ＢＩＤの通知を受けるノード、さらには、ＢＩＤを選択して通知するノードとして機能するノードになり得るため、ネットワーク内のエンティティとして、これらの機能をすべて持つ一体化した管理ノードとみなすことができる。
本発明の第４の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されていないネットワークから、提供されているネットワークへ移動した場合でも、代理ノードが、移動前にＭＮ１０が登録した位置情報を更新するために、ＭＮ１０によって登録された位置情報に付加されているＢＩＤを使って、新たな位置情報の登録が可能となる。

＜第５の実施の形態＞
図１６、図１７、図１８は第５の実施の形態のネットワークの構成を示すブロック図であり、それぞれ図１、図１２、図１３の変形例である。図１、図１２、図１３では、ＭＮ１０のＩＦ１１が通信を行っているネットワーク４０は、ネットワークベースの移動制御プロトコル（ネットワークベースプロトコル）が提供されていないのに対し、図１６、図１７、図１８におけるネットワーク４０ａは、ネットワークベースプロトコル（ＰＭＩＰ）が提供されていて、代理ノード３１ａが存在する。図１６、図１７、図１８における他の構成は、図１、図１２、図１３と同じである。

このようなネットワーク構成において、移動前のＭＮ１０のＩＦ１１、ＩＦ２２がそれぞれ、ネットワークベースプロトコルのネットワーク４０ａ、３０と通信を行っている状態から、ＭＮ１０が移動してＩＦ２２のみが、ネットワークベースプロトコルが提供されていないネットワーク２０にハンドオーバして、ＢＩＤをホームエージェント３２に要求した場合、ホームエージェント３２はＩＦ１１、ＩＦ２２のどちらがハンドオーバしたか知得できず、実際にハンドオーバしたＩＦ２２のＢＩＤをＭＮ１０に転送できないという問題点がある。そこで、第５の実施の形態では、ホームエージェント３２がＩＦ１１、ＩＦ１２の各インタフェースを特定する情報であるＭＡＣアドレスに対応してそれぞれのＢＩＤを記憶して、どのＢＩＤの要求かを判断している。

第５の実施の形態におけるＭＮ１０の構成は、第１の実施の形態における図３と同じであるが、図１９に示すようにＩＫＥリクエストメッセージ生成部１０５の判断処理が異なる。図１９におけるステップＳ１〜Ｓ９は、第１の実施の形態における図１４と同じである。ステップＳ９において移動前ネットワークでネットワークベースプロトコルを使用していたか否かを判断して、使用していた場合には、ステップＳ２０において別ＩＦ（ハンドオーバしていないＩＦ１１）も、ハンドオーバしたＩＦ１２と同じドメインのネットワークに接続し、ネットワークベースプロトコルを使用しているかどうかを判断する。そして、同じドメインネットワークに接続し、ネットワークベースプロトコルを使用していた場合に、ハンドオーバしたＩＦ２２のＭＡＣアドレスを接続ネットワーク情報保持部１１４から取得し、この取得したＩＦ２２のＭＡＣアドレスを使用して移動前ネットワークから接続中に使用されていたＢＩＤを取得し（ステップＳ２１）、次いでこの取得したＢＩＤを含むＢＵを送信する（ステップＳ２２）。同じＨＡ３２を使用していない場合には、ＢＵを送信する（ステップＳ２２）。また、ステップＳ９で、移動前ネットワークでネットワークベースプロトコルを使用していなかった場合には、移動前ネットワークから、新たなＢＩＤを取得し（ステップＳ２３）、次いでこのＢＩＤを含むＢＵを送信する（ステップＳ２２）。なお、ステップＳ２３において、移動前ネットワークで自ら移動制御を行っていた場合には、移動前ネットワークで使用していたＢＩＤを引き続き使用する。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用する場合、Binding Updateメッセージ生成部１０４が、図１９に示す処理を行い、ＭＡＣアドレスを含むＢＵメッセージを送信するべきか否かを判断する。

第５の実施の形態における代理ノード３１及び３１ａは、第１の実施の形態における図４と同じであるが、以下のブロックの処理が異なる。まず、認証結果保持部１４２は、ＭＮ１０の認証結果に関する情報とともに、ＭＮ１０に割り当てられたＢＩＤとＭＡＣアドレスを保持する。ＢＵＬが認証結果保持部１４２として機能してもよく、その場合、認証結果保持部１４２はＭＮ１０がＨＡやＣＮに登録している位置情報も保持する。認証リクエストメッセージ生成部１３４は、ＢＩＤの取得・通知を要求するメッセージとして認証リクエストメッセージを生成する際に、接続ネットワーク情報判断部１３９からＭＮ１０のＭＡＣアドレスを取得し、取得したＭＡＣアドレスをセットした認証リクエストメッセージを生成する。認証レスポンスメッセージ処理部１４１は、認証結果保持部１４２に対して、取得したＭＮ１０のＢＩＤと対応するＩＦのＭＡＣアドレスを保持するよう指示する。また、代理ＢＵメッセージ生成部１３６に対して、ＭＮ１０の位置情報を登録するための代理ＢＵメッセージを生成するよう指示する。代理ＢＵメッセージ生成部１３６は、認証レスポンスメッセージ処理部１４１の指示を受け、認証結果保持部１４２から、ＭＮ１０に割り当てられたＢＩＤとＭＡＣアドレスを取得し、それらを含む代理ＢＵメッセージを生成する。

第５の実施の形態におけるＡＡＡサーバ５０は、第１の実施の形態における図５と同じであるが、以下のブロックの処理が異なる。ＢＩＤ割り当て部１５８は、ＭＮ１０のＭＡＣアドレスに対して割り当てるＢＩＤを生成する。ＭＮ情報保持部１５７を参照し、既に通知されたＭＮ１０のＭＡＣアドレスに対して割り当て済みのＢＩＤがある場合には、それを認証判定部１５５に返す。認証リクエストメッセージ処理部１５６は第１の実施の形態と異なり、認証リクエストメッセージには ＭＡＣアドレスが含まれているので、認証判定部１５５に対して、ＭＮ１０の認証を行うよう指示すると共に、メッセージに含まれているＭＡＣアドレスを渡す。認証判定部１５５は、認証リクエストメッセージ処理部１５６から渡されたＭＮ１０のＭＡＣアドレスをＢＩＤ割り当て部１５８へ渡し、このＭＡＣアドレスに対してＢＩＤを割り当てるよう指示する。ＭＮ情報保持部１５７はＭＮ１０のＭＡＣアドレスも一緒に保持する。

第５の実施の形態におけるＨＡ３２は、第１の実施の形態における図１５と同じであるが、以下のブロックの処理が異なる。ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０から受信したＩＫＥリクエストメッセージに関する処理を行い、メッセージに含まれているＭＮに関する情報の１つとして、ＭＮ１０のＭＡＣアドレスを取得し、認証リクエストメッセージ生成部１６６にそのＭＡＣアドレスを渡して、ＭＮ１０の認証を要求するための認証リクエストメッセージを生成するよう指示する。この場合、この認証リクエストメッセージは、ＭＮ１０に割り当てられているＢＩＤで、かつＭＡＣアドレスに対応するＢＩＤを要求するメッセージとなる。また、ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０からＩＫＥリクエストメッセージを受信した際、ＡＡＡサーバ５０に対するＭＮ１０の認証が不要な場合には、認証リクエストメッセージ生成部１６６に対して認証リクエストメッセージの生成を指示せずに、ＭＮ管理情報保持部１７０から、ＭＮ１０のＭＡＣアドレスに対応するＢＩＤを取得して、そのＢＩＤを含むＩＫＥレスポンスメッセージを生成するようＩＫＥレスポンスメッセージ生成部１６５へ指示する。なお、ＭＮ１０の認証が必要な場合であったとしても、ＡＡＡサーバ５０からＢＩＤを取得するのではなく、ＭＮ管理情報保持部１７０からＭＮ１０へ割り当てられているＢＩＤを取得してもよい。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用する場合、ＢＡメッセージ生成部１１２が、ＩＫＥリクエストメッセージ処理部１６８と同様の処理を行う。

ＩＫＥレスポンスメッセージ生成部１６５は、ＩＫＥリクエストメッセージ処理部１６８、及び認証レスポンスメッセージ処理部１７１からの指示を受け、渡されたＭＮ１０に割り当てられているＢＩＤを含むＩＫＥレスポンスメッセージを生成し、それを送信部１６２に渡して送信するよう指示する。なお、ＭＮ１０のＭＡＣアドレスを含んでいてもよい。ＭＮ管理情報保持部１７０は、ＭＮ１０に関する情報として、代理ＢＵメッセージ処理部１６９から渡されたＭＮ１０の位置情報や、認証レスポンスメッセージ処理部１７１から渡されたＭＮ１０の認証結果などを保持する。ＭＮ１０の位置情報には、代理ノード３１、３１ａによって付加されたＢＩＤとＭＡＣアドレスが関連付けられており、ＩＫＥリクエストメッセージ処理部１６８、及びＢＵメッセージ処理部１７２からＭＮ１０に割り当てられているＢＩＤの取得要求を受けた際に、そのＢＩＤを渡す。

＜具体例＞
図２０は第５の実施の形態の具体例を示す。ＭＮ１６０１のＩＦ１１、ＩＦ１２はそれぞれ、移動前には実線で示すように、ＭＮ１６０１の代理ノードであるＭＡＧ（Mobile Access Gateway）１３０１（及びリンク１３５１）、ＭＡＧ１４０１（及びリンク１４５１）を経由して、ネットワークベースプロトコルのローカルネットワーク１００１に接続されている。そして、ＭＡＧ１３０１、１４０１の両方がＭＮ１６０１の現在位置をＬＭＡ（Local Mobility Anchor）１２０１に登録している。ＬＭＡ１２０１はモバイルＩＰ
が使用されているときにＭＮ１６０１のホームエージェントとして動作する。以下では、ＬＭＡの方を用いて説明する。

次に破線で示すように、ＭＮ１６０１のＩＦ１１はそのままで、ＩＦ１２のみがローカルネットワーク１００１の外に移動して、フォリンネットワーク１１０１内のＡＲ（アクセスルータ）１５０１（及びリンク１５５１）に接続すると、ＭＮ１６０１はモバイルＩＰの動作を開始して、ＡＲ１５０１から取得した新しいケアオブアドレス（ＣｏＡ）をＬＭＡ１２０１に登録しようとする。このとき、ＢＩＤ割り当てに関しては、ＭＮ１６０１はＢＩＤ要求メッセージをモビリティ管理ノードに送信して、移動前のＩＦ１２に対して使用されていたＢＩＤを要求する。ここでモビリティ管理ノードとは、ＬＭＡ１２０１、ＡＡＡサーバ５０、パケットデータゲートウェイ（ＰＤＧ）、ＭＮ１６０１のＢＩＤを知得している他のネットワークノードなどである。モビリティ管理ノードがＬＭＡ１２０１であると仮定すると、ＬＭＡ１２０１はＭＮ１６０１からのＢＩＤ要求メッセージを受信すると、ＭＮ１６０１のＢＩＤエントリが２つあることを知得するので、第１〜第４の実施の形態ではどのＢＩＤを応答していいかわからない。

そこで、この具体例では、ＭＡＧ１３０１、１４０１は、ＬＭＡ１２０１に送信する代理ＢＵ内にＭＮ１６０１のリンク識別子を埋め込む。そしてさらに、ＭＮ１６０１は、移動したＩＦ１２に関してのＢＩＤ要求メッセージの中に、ＩＦ１２に関するリンク識別子を含めて送信する。このリンク識別子により、ＬＭＡ１２０１は簡単に、ＭＮ１６０１がどの代理ＢＵで使われているＢＩＤを要求しているかを決定して、ＭＡＧ１３０１、１４０１に問い合わせることなくＢＩＤを通知することができる。このリンク識別子は、例えばＭＮ１６０１のＩＦ１１、ＩＦ１２のリンクレイヤアドレスであり、ＭＮ１６０１がＷｉＦｉやイーサネット（登録商標）のようなＩＥＥＥ８０２に対応するインタフェースを使用している場合にはＩＦ１１、ＩＦ１２のＭＡＣアドレスである。

ここで、ＭＡＧ１３０１、１４０１は種々の方法で、ＭＮ１６０１のＩＦ１１、ＩＦ１２のリンクレイヤアドレスを取得することができる。例えばＭＡＧ１３０１、１４０１はＭＮ１６０１との送信中に、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６のように下位の層の通信プロトコルでリンクレイヤアドレスを取得することができる。ＭＡＣアドレスはＭＮ１６０１から到着するパケットの送信元アドレスのフィールドに記述されている。他の方法としては、ＭＮ１６０１が最初にＭＡＧ１３０１、１４０１に接続したときのアソシエーションフェーズか認証フェーズの間にＭＡＣアドレスにアクセスすることができる。また、他の方法として、ＩＰレベルの近隣探索（Neighbor Discovery）を実行することにより取得することができる。また、他の方法として、ネットワークポリシーを有するか、認証を行うサーバに問い合わせてもよい。以下では、リンク識別子の代わりにＭＡＣアドレスを用いて説明してもよい。

図２１は、ＭＮ１６０１のＩＦ１１、ＩＦ１２がともにローカルネットワーク１００１に接続しているときにＬＭＡ１２０１が保持するＭＮ１６０１のバインディングキャッシュ・エントリ（ＢＣＥ）を示す。このＢＣＥは、ＭＮ１６０１のＮＡＩ（Network Access Identifier）であるMN.NAI２００と、ＭＮ１６０１に割り当てられているプレフィックスであるMN.Prefix２１０を有し、さらにＭＡＧ１３０１、１４０１の各エントリとして、代理ノードによって登録されたエントリであることを示す代理フラグ２２０（Proxy Flag 1）、２６０（Proxy Flag 2）と、その代理ノードを示すＭＡＧ１３０１のアドレス２３０（MAG1 Address）、ＭＡＧ１４０１のアドレス２７０（MAG2 Address）と、ＭＮ１６０１のＩＦ１１が接続するリンク１３５１に対応するリンク１記述子２４０（Link 1 Descriptor）、ＩＦ１２が接続するリンク１４５１に対応するリンク２記述子２８０（Link 2 Descriptor）と、それぞれのエントリに対して割り当てられているＢＩＤ２５０（ＢＩＤ１）、ＢＩＤ２９０（ＢＩＤ２）とを有している。

ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動してモバイルＩＰを開始すると、まずＢＩＤ要求メッセージをＬＭＡ１２０１に送信する。このＢＩＤ要求メッセージは、フォリンネットワーク１１０１に移動したＩＦ１２のＭＡＣアドレスを含む。ＬＭＡ１２０１はこのＢＩＤ要求メッセージを受信すると、メッセージ内のＭＡＣアドレスをマッチングすることにより、要求されたＢＩＤ２９０（ＢＩＤ２）を正しく特定してＢＩＤ要求メッセージに即刻応答することができる。

他の例として、ＭＡＧ１３０１、１４０１は、ＭＮ１６０１と通信している自身のインタフェースのＭＡＣアドレスを、ＬＭＡ１２０１に送信する代理ＢＵ内に含ませるようにしてもよい。この場合には、ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動してモバイルＩＰを開始し、ＢＩＤ要求メッセージをＬＭＡ１２０１に送信するとき、このＢＩＤ要求メッセージ内に、前の接続点であるＭＡＧ１４０１のＩＦのＭＡＣアドレスを含ませる。したがって、ＬＭＡ１２０１はこのＢＩＤ要求メッセージを受信すると、メッセージ内のＭＡＣアドレスをマッチングすることにより、要求されたＢＩＤ２９０（ＢＩＤ２）を正しく特定してＢＩＤ要求メッセージに即刻応答することができる。

他の例として、ＭＮ１６０１がＩＦ１１、ＩＦ１２の各コネクションに対してローカルにユニークな識別子を使用してもよい。この利点は、複数のリンクを同時にサポートするＩＦ１１、ＩＦ１２の各リンクを明確に特定することができることにある。但し、この場合には、ＭＮ１６０１は、使用しているコネクションＩＤのＭＡＧ１３０１、１４０１を明確に通知しなければならない。この通知は、アソシエーションフェーズの間に別のメッセージを送ることにより実現することができる。ＭＡＧ１３０１、１４０１はＭＡＣアドレスの代わりに、このコネクションＩＤを、ＬＭＡ１２０１に対する代理ＢＵ内に含ませる。ＬＭＡ１２０１はＭＡＣアドレスの代わりに、このコネクションＩＤをＢＣＥ内に含ませる。そして、ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動してＢＩＤ要求メッセージをＬＭＡ１２０１に送信するとき、このＢＩＤ要求メッセージ内に、ＩＦ１２が関連するコネクションＩＤを含ませる。ＬＭＡ１２０１はこのＢＩＤ要求メッセージ内のコネクションＩＤをマッチングして正しいＢＩＤ２９０（ＢＩＤ２）を応答することができる。

他の例として、ＭＡＧ１３０１がＭＮ１６０１に対して直接にフィードバックするようにしてもよい。この場合、まず、ＭＮ１６０１はアソシエーション中に、ＭＡＧ１３０１に対して、ネットワークが割り当てたＢＩＤを知得したい旨を通知する。この通知は、アソシエーションフェーズの間にフラグか別のメッセージを送ることにより実現することができる。また、ＭＮ１６０１は、ＭＡＧ１３０１の通信中はいつでもＭＡＧ１３０１に問い合わせをするように選択してもよい。ＭＡＧ１３０１はこの通知を受信すると、ＬＭＡ１２０１から得られたＢＩＤをＭＮ１６０１に通知する。

ＭＡＧ１３０１はまた、他の種々の方法でＢＩＤをＭＮ１６０１に通知してもよい。その１つは、ＢＩＤをＭＮ１６０１に対するルータ広告メッセージ（ＲＡ：Router Advertisement）に追加する方法である。この方法は、ネットワークベースの移動制御プロトコルの（ＰＭＩＰ）ドメインが、１つのＭＮに対して１つのプリフィックス割り当てる形態を使用している場合に特に有用である。この理由は、ＭＮ１６０１が他のノードには見えないユニキャストＲＡを受信するからである。もし、ＲＡをブロードキャストすると、どのＢＩＤがどのＭＮに属するかわからないという混乱が発生するが、ユニキャストＲＡはこれを防止することができる。他の方法として、ＭＡＧ１３０１からＭＮ１６０１へのＢＩＤを専用のメッセージで通知するようにしてもよく、また、この専用のメッセージは、ＭＮ１６０１あての既存のパケットに付加して送信してもよい。

他の例として、ＡＲ１５０１はＰＭＩＰのローカルネットワーク１００１の一部ではないが、ＡＲ１５０１がこの問題点を解決するようにしてもよい。この場合には、ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動して、ＭＮ１６０１がモバイルＩＰを開始し、ＢＩＤ要求メッセージをＬＭＡ１２０１あてに送信すると、ＡＲ１５０１はこのＢＩＤ要求メッセージを含むパケットを受信してＢＩＤ要求メッセージを検出し、オプションとしてＭＮ１６０１のリンク識別子をＢＩＤ要求メッセージに追加する。このオプションのリンク識別子は、ＬＭＡ１２０１あてのＢＩＤ要求メッセージに付加して送信するか、別のパケットで送信してもよい。ＬＭＡ１２０１はリンク識別子を含むこのオプションを解釈し、ＢＩＤ要求メッセージを上記と同様な手順で処理する。

一方、ＭＮ１６０１がフォリンネットワーク１１０１内のＡＲ１５０１からローカルネットワーク１００１内のＭＡＧ１４０１に移動した場合、ＭＡＧ１４０１はＭＮ１６０１がＰＭＩＰサービスを受けることができ、ＰＭＩＰサービスを開始すると決定する。そして、ＭＡＧ１４０１はＭＮ１６０１のリンク識別子を含むＢＩＤ要求メッセージをＬＭＡ１２０１あてに送信する。

＜第６の実施の形態＞
図２２は本発明の第６の実施の形態におけるネットワークの構成を示す図であり、第４の実施の形態における図１０と同様に、ハンドオーバがネットワーク２０からネットワークベースプロトコルのネットワーク３０へ行われるが、図１０との違いは、ネットワーク４０ａは、ネットワークベースプロトコルが提供されていて代理ノード３１ａが存在する点である。そして、移動前のＭＮ１０のＩＦ１１、ＩＦ１２がそれぞれ、ネットワークベースプロトコルのネットワーク４０ａと、ネットワークベースプロトコルでないネットワーク２０と通信を行っている状態から、ＭＮ１０が移動してＩＦ１２のみがネットワークベースプロトコルのネットワーク３０にハンドオーバした場合にも同様に、ＩＦ１１、ＩＦ１２のＭＡＣアドレスにより、ＩＦ１２のＢＩＤをネットワーク３０内の代理ノード３１に通知することができる。

＜第７の実施の形態＞
本発明の第７の実施の形態では、ＭＮ１０のハンドオーバが、ネットワークベースの移動制御プロトコルが提供されているネットワーク３０から、ネットワークベースの移動制御プロトコルが提供されていないネットワーク２０へ行われる。また、第7の実施の形態のネットワーク構成は、第1の実施の形態で図１、図１２、図１３を用いて説明した構成と同じであるため、説明を省略する。

図２５は、本発明の第７の実施の形態におけるシーケンスとして、ＭＮ１０がネットワーク３０で初期起動してネットワーク３０の代理ノード３１（ＭＡＧ：Mobile Access Gateway、ＰＭＡ(Proxy Mobile Agent)、以下、代理ノードを用いる）によりＭＮ１０の位置情報が、ホームエージェント３２（ＨＡ：Home Agent、又はＬＭＡ：Local Mobility Anchor、以下ではＨＡの方を用いる）に登録された後に、ネットワーク２０にハンドオーバした場合の通信シーケンスを示す。

（１）アクセス及びモビリティ認証
・ＭＮ１０はネットワーク３０で初期起動すると、代理ノード３１に対してアクセス認証要求メッセージ（以下の説明及び通信シーケンス図では、「メッセージ」は省略）を送信する。
・代理ノード３１はＭＮ１０からのアクセス認証要求を受信すると、ＡＡＡ（Authentication, Authorization, Accounting）サーバ５０に対してＡＡＡリクエスト（request）でＭＮ認証要求を送信する。
・ＡＡＡサーバ５０は代理ノード３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、代理ノード３１に対して、ＡＡＡリプライで認証ＯＫを通知する。
・代理ノード３１はＡＡＡサーバ５０からのＡＡＡリプライを受信すると、ＭＮ１０に対してアクセス認証完了を通知する。

（２）代理ノードによる位置情報登録
・代理ノード３１はＨＡ３２に対して、代理ＢＵ（Proxy Binding Update）を送信して、ＭＮ１０のホームプレフックスに代理ノード３１のアドレス（ＭＡＧ addr）を関連付けた情報を、ＭＮ１０の位置情報としてＨＡ３２へ登録する。
・ＨＡ３２がこの受信後、ＡＡＡサーバ５０に対してＡＡＡリクエストを送信し、ＡＡＡサーバ５０がＡＡＡリクエストを受信して、ＨＡ３２に対してＡＡＡリプライを送信することにより、代理ノード認証プロセスを実行する。なお、代理ノード３１の認証が不要な場合は、ＡＡＡリクエストの送信は省略してもよい。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡリプライを受信すると、代理ノード３１に対して代理ＢＡ（Proxy Binding Acknowledgement）を送信する。
・代理ノード３１はＨＡ３２から位置情報登録ＯＫを示す代理ＢＡを受信すると、ＭＮ１０に対してＲＡ（Router Advertisement）を送信してＭＮ１０のホームプレフィックスを通知する。

・ＭＮ１０は代理ノード３１からのＲＡを受信すると、メッセージに含まれているプレフィックスを用いてアドレスを生成し、ＩＦへ割り当てる。さらにメッセージに含まれているプレフィックスが自身のホームプレフィックスである場合には、ＭＮ１０はホームネットワークに接続していると認識する。なお、ＲＡにホームプレフィックスが含まれている場合には、ホームネットワークに接続していることと同時に、その状態がネットワークベースの移動制御プロトコルによって実現されていると認識するようにしてもよい。また、本発明の第1の実施の形態に示すように、ＩｓＰＭＩＰ情報がＲＡに含まれている場合に、ネットワークベースの移動制御プロトコルが提供されていると認識するようにしてもよい。
なお、ＲＡにＭフラグが含まれている場合には、ＭＮ１０は、代理ノード３１に対してＤＨＣＰ（Dynamic Host Configuration Protocol）request を送信する。この場合、代理ノード３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信して、ＭＮ１０へ割り当てるアドレスを通知する。なお、本発明の第1の実施の形態に示すように、ＭＮ１０へ割り当てるアドレスと共に、ＨＡ３２のアドレス（ＨＡ address）と、ＩｓＰＭＩＰ情報を通知してもよい。

（３）ＭＮによる位置情報登録
・ＭＮ１０はネットワーク２０に移動すると、移動前に接続していたネットワーク３０がホームネットワークであったことを判断し、ネットワーク２０で取得したアドレス（Ａｄｄｒ２）と共に、移動前にホームネットワークに接続していたことを示す情報（以下、移動前ホームネットワーク接続情報）をＢＵメッセージに付加してＨＡ３２へ送信する。
・ＨＡ３２はＭＮ１０からのＢＵメッセージを受信すると、メッセージの中に移動前ホームネットワーク接続情報が存在することを確認し、新しい位置情報で置き換えるべき対象が、代理ノードによって登録された位置情報であると判断する。そして、すでに登録されているＭＮ１０の位置情報の中から代理ノードによって登録された位置情報を特定して、それを新しい移動後の位置情報で置き換える。そして、ＨＡ３２は、位置情報の登録の結果を含むＢＡメッセージをＭＮ１０へ送信する。

図２６は第７及び後述する第８の実施の形態におけるＭＮ１０の構成を示すブロック図である。ＭＮ１０は前述したインタフェースＩＦ１１、ＩＦ２２の他、送信部８０３と、受信部８０４と、Binding Update（ＢＵ）メッセージ生成部８０５と、移動前ネットワーク情報保持部８０６と、ＲＳ（Router Solicitation）送信処理部８０７と、ネットワーク接続検出部８０８と、アクセス認証処理部８０９と、ＲＡ（Router Advertisement）処理部８１０と、ＢＡ（Binding Acknowledgement）メッセージ処理部８１１と、登録済位
置情報保持部８１２と接続ネットワーク情報保持部８１３を有する。

以下では、ＭＮ１０が備える主要構成要素について説明する。インタフェースＩＦ１１、ＩＦ２２の存在は、ＭＮ１０が２つのインタフェースを有することを示している。また、送信部８０３及び受信部８０４は、インタフェースＩＦ１１、ＩＦ２２のそれぞれを通じてパケットの送受信を行う機能を有している。ＢＵメッセージ生成部８０５は、接続ネットワーク情報保持部８１３から、ＩＦ１１またはＩＦ２２がハンドオーバして接続するネットワークが変更になったことの通知を受け、ＨＡ３２に登録されている移動前の位置情報を、移動後の位置情報で更新するためのＢＵメッセージを生成する。

移動後のネットワークが外部ネットワークである場合には、ＢＵメッセージ生成部８０５は、移動前ネットワーク情報保持部８０６を確認し、移動前に接続していたネットワークがホームネットワークであったか否かを判断する。その結果、移動前のネットワークがホームネットワークであった場合には、生成するＢＵメッセージの中に、移動前のネットワークがホームネットワークであったこと、あるいは移動前のネットワークではネットワークベースの移動制御プロトコルが提供されていたことを示す情報（移動前ホームネットワーク接続情報と呼ぶ、フラグなどで実現してもよい）を付加する。例えば、ＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバして、接続ネットワーク情報保持部８１３から、ＩＦ２２が接続するネットワークが変わったことの通知を受け、外部ネットワークに接続したことを認識した場合、移動前ネットワーク情報保持部８０６を確認して、移動前のネットワークがホームネットワークであったことを認識する。そして、移動後のネットワークで取得したアドレスと共に、移動前ホームネットワーク接続情報を含むＢＵメッセージを生成してＨＡ３２へ送信する。なお、移動前ホームネットワーク接続情報を含むＢＵメッセージに、ＩＦ２２に関する位置情報を登録する際に使用するＢＩＤとして、ＭＮ１０が生成したＢＩＤをＢＵメッセージに付加して送信してもよい。

ＭＮ１０が送信するＢＵメッセージ内の移動前ホームネットワーク接続情報は、図２４に示すように、モビリティヘッダ３０１の中や、代替ＣｏＡオプション３０３の中にフラグなどとして含まれていてもよいし、ＢＩＤを含むオプション３０４の中に含まれていてもよい。また、後述する移動前外部ネットワーク接続情報と同じ位置のフラグを用いることで、フラグがセットされている場合は、移動前ホームネットワーク接続情報を示し、フラグがセットされていない場合は、移動前外部ネットワーク接続情報を示すようにしてもよいし、又はその逆でもよい。

この場合、このＢＵメッセージを受信したＨＡ３２は、メッセージ内の移動前ホームネットワーク接続情報により、ＭＮ１０の移動前の位置情報が代理ノード３１によって登録された位置情報であることを認識し、ＭＮ１０からのＢＵメッセージ内に含まれる新しい位置情報で置き換える対象として、代理ノード３１によって登録された位置情報を特定することができる。さらに、ＨＡ３２は、特定した位置情報を新しい位置情報で置き換え、このＢＵメッセージに対するレスポンスメッセージとして送信するＢＡメッセージの中に、位置情報の置換の結果を示す情報として置換が成功したことを示す情報を含めて送信する。

また、本発明の第１の実施の形態に示すように、移動前ホームネットワーク接続情報を含むＢＵメッセージを用いて、ＩＦ２２の位置情報の登録に使用するＢＩＤを要求するようにしてもよい。この場合、移動前ホームネットワーク接続情報を含むＢＵメッセージを受信したＨＡ３２が、移動前ホームネットワーク接続情報を用いて特定したＭＮ１０の移動前の位置情報に付加されているＢＩＤをＢＣ（Binding Cache：バインディングキャッシュ）から取得し、ＢＡメッセージに含めてＭＮ１０へ通知する。なお、ＭＮ１０の移動前の位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバ５０や、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。

また、この場合のＢＵメッセージ３００には、図２３に示すように、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４が、移動前ホームネットワーク接続情報、及びＢＩＤの取得を要求することを示す情報として使われてもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。また、ＭＮ１０からのＢＵメッセージ内にＭＮ１０が生成したＢＩＤが付加されている場合には、ＨＡ３２は、そのＢＩＤと共に移動後の位置情報を保持し、位置情報の置換の結果を示す情報として置換が成功したことを示す情報と共に、そのＢＩＤをＢＡメッセージに含めてＭＮ１０へ送信する。このＢＡメッセージを受けたＭＮは、以降ＩＦ２２に関する位置情報の登録の際に、受信したＢＡメッセージに含まれていたＢＩＤを使用する。なお、ＢＵメッセージ、及びＢＡメッセージの代わりに、ＩＫＥリクエストメッセージ、及びＩＫＥレスポンスメッセージを用いてもよい。

移動前ネットワーク情報保持部８０６は、接続ネットワーク情報保持部８１３から渡された、ＩＦ１１及びＩＦ２２が移動する前に接続していたネットワークに関する情報を保持する。

ＲＳ送信処理部８０７は、アクセス認証処理部８０９からアクセス認証が完了したことの通知を受けて、接続しているネットワーク２０又は３０又は４０に対してＲＡメッセージの送信を要求するためのＲＳメッセージを生成して送信部８０３に対して送信するよう指示する。なお、ＲＳメッセージは、送信する前にＲＡメッセージを受信することができた場合は、送信する必要はない。

また、ＲＳ送信処理部８０７は、接続ネットワーク情報保持部８１３から、ＩＦ１１またはＩＦ２２がハンドオーバして接続するネットワークが変更になったことの通知を受けたとき、ＨＡ３２に登録されている移動前の位置情報を移動後の位置情報で更新するための代理ＢＵメッセージを送信する代理ノード３１に対して、ＲＳメッセージを送信する。このとき、移動後のネットワークがホームネットワークである場合には、ＲＳ送信処理部８０７は、移動前ネットワーク情報保持部８０６を確認し、移動前に接続していたネットワークが外部ネットワーク、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワークであったか否かを判断する。

その結果、移動前のネットワークが外部ネットワークであった場合には、生成するＲＳメッセージの中に、移動前のネットワークが外部ネットワークであったこと、すなわち移動前のネットワークではネットワークベースの移動制御プロトコルが提供されていなかったことを示す情報（以下、移動前外部ネットワーク接続情報、フラグなど）を付加する。例えば、ＩＦ２２がネットワーク２０からネットワーク３０へハンドオーバして、接続ネットワーク情報保持部８１３から、ＩＦ２２が接続するネットワークが変わったことの通知を受け、ホームネットワークに接続したことを認識した場合、移動前ネットワーク情報保持部８０６を確認して、移動前のネットワークが外部ネットワークであったことを認識する。そして、移動前外部ネットワーク接続情報を含むＲＳメッセージを生成して代理ノード３１へ送信する。なお、移動前外部ネットワーク接続情報を通知するためのメッセージとして、ＮＳメッセージやＤＨＣＰリクエストメッセージ、認証リクエストメッセージ、さらにはＢＵメッセージなどを用いてもよい。なお、ＭＮ１０が送信するＲＳメッセージ内の移動前外部ネットワーク接続情報は、図２７に示すように、ＲＳメッセージ３１０のヘッダ部３１１の中にフラグとして含まれていてもよいし、新たなオプション３１２の中に含めてもよい。

この場合、このＲＳメッセージを受信した代理ノード３１はＨＡ３２に対して、ＭＮ１０から通知された移動前外部ネットワーク接続情報を付加した代理ＢＵメッセージを送信する。なお、代理ノード３１が送信する代理ＢＵメッセージ内の移動前外部ネットワーク接続情報は、図２４の移動前ホームネットワーク接続情報と同様に、モビリティヘッダ３０１の中や、代替ＣｏＡオプション３０３の中にフラグなどとして含まれていてもよいし、ＢＩＤを含むオプション３０４の中に含まれていてもよい。また、移動前ホームネットワーク接続情報と同じ位置のフラグを用いることで、フラグがセットされている場合は、移動前ホームネットワーク接続情報を示し、フラグがセットされていない場合は、移動前外部ネットワーク接続情報を示すようにしてもよいし、又はその逆でもよい。

この代理ＢＵメッセージを受信したＨＡ３２は、メッセージ内の移動前外部ネットワーク接続情報により、ＭＮ１０の移動前の位置情報がＭＮ１０自身によって登録された位置情報であることを認識し、代理ノード３１からの代理ＢＵメッセージ内に含まれる移動後の位置情報で置き換える対象として、ＭＮ１０によって登録された位置情報を特定することができる。さらに、ＨＡ３２は特定した位置情報を新しい位置情報で置き換え、この代理ＢＵメッセージに対するレスポンスメッセージとして送信する代理ＢＡメッセージの中に、位置情報の置換の結果を示す情報として置換が成功したことを示す情報を含めて送信する。

また、本発明の第１の実施の形態に示すように、代理ノード３１は、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを用いて、ＭＮ１０のＩＦ２２の位置情報の登録に使用するＢＩＤを要求するようにしてもよい。この場合、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを受信したＨＡ３２が、移動前外部ネットワーク接続情報を用いて特定したＭＮ１０の移動前の位置情報に付加されているＢＩＤをＢＣから取得し、代理ＢＡメッセージに含めて代理ノード３１へ通知する。なお、ＭＮ１０の移動前の位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、ＨＡ３２が新たなＢＩＤを生成し、代理ＢＡメッセージに含めて送信する。

なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバ５０や、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。この場合の代理ＢＵメッセージには、図２３に示すように、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４がＢＩＤの取得を要求することを示す情報として使われてもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。また、代理ノード３１からの代理ＢＵメッセージ内に代理ノード３１が生成したＢＩＤが付加されている場合には、ＨＡ３２は、そのＢＩＤと共に移動後の位置情報を保持し、位置情報の置換の結果を示す情報として置換が成功したことを示す情報と共に、そのＢＩＤをＢＡメッセージに含めて代理ノード３１へ送信する。この代理ＢＡメッセージを受けた代理ノード３１は、以降ＭＮ１０のＩＦ２２に関する位置情報の登録の際に、受信した代理ＢＡメッセージに含まれていたＢＩＤを使用する。

図２８に示す判断処理について説明する。ＭＮ１０が別のネットワークへ移動すると（ステップＳ３１）、移動先ネットワークが外部ネットワークであるかホームネットワークであるかを判断する（ステップＳ３２）。ここで、移動先ネットワークがホームネットワークである場合には（ステップＳ３２でＮＯ）、後述するステップＳ３３に進む。他方、移動先ネットワークが外部ネットワークである場合には、移動前のネットワークがホームネットワークであったか否かを判断する（ステップＳ３７）。ここで、移動前のネットワークがホームネットワークであった場合には、生成するＢＵメッセージに移動前ホームネットワーク接続情報を付加して（ステップＳ３８）、位置情報と共に送信する（ステップＳ３９）。他方、移動前のネットワークがホームネットワークでなかった場合には、移動前に使用していたＢＩＤを使用した位置情報登録を通常通り行う（ステップＳ４０）。

ステップＳ３３では、移動前のネットワークが外部ネットワークであった場合には、生成するＲＳメッセージに移動前外部ネットワーク接続情報を付加して（ステップＳ３５）、送信する（ステップＳ３６）。他方、移動前のネットワークがホームネットワークであった場合（ステップＳ３３でＮＯ）には、引き続きネットワークベースの移動制御プロトコルを使用する判断をして、移動制御を行わない（ステップＳ３４）。

また別の方法として、ＭＮ１０のＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバする以前に、ＭＮ１０が、ＩＦ１１に関する位置情報をＨＡ３２に登録するために送信するＢＵメッセージ内に、ＭＮ１０の他のＩＦ（ＩＦ２２）がホームネットワークに接続していること、あるいはネットワークベースの移動制御プロトコルが提供されているネットワークに接続していることを示す情報（フラグなど、以下、ＩＦホームネットワーク接続情報）を付加してもよい。

この場合、このメッセージを受信したＨＡ３２は、登録する位置情報と共にＩＦホームネットワーク接続情報をＢＣ内に保持する。そして、ＭＮ１０のＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした後、ＨＡ３２は、ＭＮ１０からＩＦ２２の新しい位置情報を含むＢＵメッセージを受信した際に、そのメッセージの中に、ＩＦホームネットワーク接続情報が含まれていない場合には、ＭＮ１０はすでにホームネットワークに接続していないこと、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワーク（ネットワーク２０）へ移動したことを認識し、ＭＮ１０からのＢＵメッセージ内に含まれる新しい位置情報で置き換える対象が、代理ノード３１によって登録された位置情報であること、あるいはＩＦホームネットワーク接続情報が付加されていない位置情報であることを認識することができる。

なお、ＭＮ１０から、ＩＦホームネットワーク接続情報を含むＢＵメッセージを受信したＨＡ３２は、ＭＮ１０のＩＦ２２がホームネットワークに接続していること、あるいはネットワークベースの移動制御プロトコルが提供されているネットワークに接続していることを示す情報（ＩＦホームネットワーク接続情報）を、ＢＣ内の代理ノード３１によって登録された位置情報に対して付加してもよい。この場合、ＨＡ３２が、ＭＮ１０からＩＦ２２の新しい位置情報を含むＢＵメッセージを受信した際に、そのメッセージの中にＩＦホームネットワーク接続情報が含まれていない場合には、ＭＮ１０はすでにホームネットワークに接続していないこと、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワーク（ネットワーク２０）へ移動したことを認識し、ＭＮ１０からのＢＵメッセージ内に含まれる新しい位置情報で置き換える対象が、代理ノード３１によって登録された位置情報であること、あるいはＩＦホームネットワーク接続情報が付加されている位置情報であることを認識することができる。なお、ＨＡ３２は、置き換え対象の位置情報を特定する際に、位置情報にＭＡＧ登録情報が付加されているかどうかを確認し、付加されている場合に置き換え対象の位置情報であると判断してもよい。

さらに、ＨＡ３２は、特定した位置情報を新しい位置情報で置き換えると共に、このＢＵメッセージに対して送信するＢＡメッセージに、置き換え対象である位置情報に付加されているＢＩＤをＢＣから取得し、そのＢＩＤをＢＡメッセージに含めて送信する。また、置き換え対象である位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバ５０や、ＭＮ１０の情報を保持している情報サーバ（不図示）などに対して、ＢＩＤの取得・生成を要求してもよい。なお、ＨＡ３２は、ＭＮ１０からのＢＵメッセージを受けてＢＣに登録した新しい位置情報の中に、その位置情報によって置き換えられた位置情報が、以前代理ノード３１によって登録された位置情報であったことを示す情報（ＭＡＧ登録情報）を保持してもよい。この情報は、以降ＭＮ１０からの位置情報の更新があった場合でも消去されずに保持される。

図２６に示すＢＡメッセージ処理部８１１は、Binding Update メッセージ生成部８０５によって生成・送信されたＢＵメッセージに対するレスポンスメッセージであるＢＡメッセージの受信処理を行う。例えば、ＭＮ１０のＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした場合、ＢＡメッセージには、代理ノード３１によって登録された移動前の位置情報に対して、移動後の位置情報での置換が成功したことを示す情報が含まれている。また、以降のＩＦ２２の位置情報を登録する際に使用するＢＩＤが含まれている場合、そのＢＩＤと共に、登録した位置情報を登録済位置情報保持部８１２に保持するよう指示する。

ＲＡ処理部８１１は、接続しているネットワークから受信したＲＡメッセージに関する処理を行い、接続しているネットワークを特定する情報として、ＲＡメッセージに含まれているプレフィックス情報などを接続ネットワーク情報保持部８１３に渡して保持するよう指示する。接続ネットワーク情報保持部８１３は、ＲＡ処理部８１０から渡された接続ネットワーク情報と自身が保持している接続ネットワーク情報とを比較し、両者が異なる場合は、接続ネットワークが変わったと判断し、ＢＵメッセージ生成部８０５及びＲＳ送信処理部８０７に対して、接続ネットワークが変わったことを通知する。さらに、変わる前の接続ネットワーク情報を移動前ネットワーク情報保持部８１２へ渡し、保持するよう指示する。登録済位置情報保持部８１２は、ＭＮ１０がＨＡ３２及び通信相手に登録している位置情報を保持する。モバイルＩＰにおけるＢＵＬ（バインディングアップデートリスト）として機能する。

アクセス認証処理部８０９は、ネットワーク接続検出部８０８からアクセスネットワークに接続したことの通知を受け、そのネットワークに対する認証処理を開始するためのアクセス認証リクエストをネットワークに対して送信し、その認証結果をネットワークから受信する。その認証結果がＭＮ１０の接続を許可するものであった場合には、ＲＳ送信処理部８０７に対して認証の完了を通知する。アクセス認証では、ＩＥＥＥ８０２．１ｘやＩＥＥＥ８０２．１１ｉなどの方法が用いられ、認証方式としては、ＥＡＰ−ＭＤ５、ＥＡＰ−ＴＬＳ、ＥＡＰ−ＴＴＬＳ、ＥＡＰ−ＰＥＡＰなどが用いられる。アクセス認証部８０９が生成するアクセス認証要求メッセージは特に新しい情報を持たないが、代理ノード３１が送信する認証リクエストメッセージのトリガとなり、さらにその後のＡＡＡサーバ５０によるＢＩＤ割り当てをトリガするメッセージでもある。

図２９は本発明の第７の実施の形態における代理ノード３１の構成を示す図である。代理ノード３１はネットワークとの通信インタフェースであるインタフェース８２１と、送信部８２３と、受信部８２４と、アクセス認証処理部８２５と、代理ＢＵメッセージ生成部８２６と、ＲＳメッセージ処理部８２７と、ＲＡ生成部８２８と、代理ＢＡメッセージ処理部８２９と、登録済位置情報保持部８３０を有する。送信部８２３及び受信部８２４は、インタフェースを通じてパケットの送受信を行う機能を有している。アクセス認証処理部８２５は、ＭＮ１０からのアクセス認証メッセージを処理し、それをＡＡＡサーバ５０に転送して、ＭＮ１０の認証を要求する。そして、ＡＡＡサーバ５０からＭＮ１０の認証結果を含むレスポンスメッセージを受信し、その結果をＭＮ１０へ返す。

代理ＢＵメッセージ生成部８２６は、ＭＮ１０の認証が完了した後に、アクセス認証処理部８２５からの指示を受け、ＭＮ１０の位置情報として、ＭＮ１０のホームプレフィックスに代理ノード３１自身のアドレスを関連付けた情報をＨＡ３２へ登録するための代理ＢＵメッセージを生成し、送信部８２３へ送信するよう指示する。ＭＮ１０のホームプレフィックスや、登録先のＨ３２のアドレスなどは、ＭＮ１０の管理情報を保持している情報サーバ（不図示）に問い合わせて取得することができる。また、代理ＢＵメッセージ生成部８２６は、ＲＳメッセージ処理部８２７から指示を受け、ＭＮ１０の位置情報として、ＭＮ１０のホームプレフィックスに代理ノード３１自身のアドレスを関連付けた情報と共に、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを生成し、送信部８２３に対してＨＡ３２へ送信するよう指示する。

なお、ＭＮ１０のホームプレフィックスの割り当てをＨＡ３２に対して要求するために、ホームプレフィックスを指定しない代理ＢＵメッセージを送信してもよい。この場合の代理ＢＵメッセージには、ホームプレフィックスを通知するためのオプションの中の、ホームプレフィックスを含むべきフィールド部分が空（ゼロ値）になっている状態のオプションが含まれていて、このオプションがホームプレフィックスの割り当てを要求することを示す情報として使われてもよい。また、ＭＮ１０の識別情報として、ＭＮ１０の識別子（ＮＡＩ：Network Access Identifier）を代理ＢＵメッセージに含めてもよい。さらに、ＨＡ３２に登録されているＭＮ１０の他の位置情報との識別をするために、ＢＩＤを生成して代理ＢＵメッセージに付加して送信してもよい。また、前述したように、ＢＩＤの割り当てを要求するために、ＢＩＤを指定せずにＢＵメッセージを送信してもよい。

代理ＢＡメッセージ処理部８２９は、代理ＢＵメッセージ生成部８２６が生成・送信した代理ＢＵメッセージに対するレスポンスとして受信した代理ＢＡメッセージに関する処理を行い、代理ＢＡメッセージに含まれる位置情報の登録結果を取得して、登録が成功した位置情報を登録済位置情報保持部８３０へ渡し保持するよう指示する。また、移動前外部ネットワーク接続情報を用いた登録が成功したことを示す結果が含まれている場合には、その情報も保持するよう指示する。なお、登録が失敗したことを示す情報を登録済位置情報保持部８３０へ保持するよう指示し、移動前ホームネットワーク接続情報及び移動前外部ネットワーク接続情報に対応していないことを示す情報として利用してもよい。

さらに、代理ＢＡメッセージ処理部８２９は、ＭＮ１０の位置情報の登録が成功した場合には、ＲＡ生成部８２８に対し、ＭＮ１０のホームプレフィックスを含むＲＡメッセージを生成して送信するよう指示する。また、代理ＢＡメッセージに移動前外部ネットワーク接続情報を用いた登録が成功したことを示す結果が含まれていた場合には、ＭＮ１０のホームプレフィックスと共に、移動前外部ネットワーク接続情報による登録が成功したことを示す情報を含むＲＡメッセージを生成するよう指示する。また、代理ＢＡメッセージ処理部８２９は、受信した代理ＢＡメッセージ内に、ＢＩＤが含まれている場合には、以降の位置情報登録の際に、そのＢＩＤを代理ＢＵメッセージに付加して送信する。

ＲＳメッセージ処理部８２７は、ＭＮ１０から受信したＲＳメッセージに関する処理を行い、ＲＡ生成部８２８に対して、ＭＮのホームプレフィックスを含むＲＡメッセージを生成して送信するよう指示する。また、ＲＳメッセージ生成部８２７は、ＭＮ１０から受信したＲＳメッセージに移動前外部ネットワーク接続情報が含まれている場合には、代理ＢＵメッセージ生成部８２６に対して、ＭＮ１０の位置情報として、ＭＮ１０のホームプレフィックスに代理ノード３１自身のアドレスを関連付けた情報と共に、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを生成するよう指示する。なお、移動前外部ネットワーク接続情報を通知するためのメッセージとしてアクセス認証要求メッセージを使用する場合には、アクセス認証処理部８２５が、代理ＢＵメッセージ生成部８２６へ同様の指示を出す。

ＲＡ生成部８２８は、代理ＢＵメッセージに対するレスポンスとして代理ＢＡメッセージを受信した代理ＢＡメッセージ処理部８２９からの指示を受け、渡されたＭＮ１０のホームプレフィックスを含むＲＡメッセージを生成し、送信部８２３に対してＭＮ１０へ送信するよう指示する。また、ＲＡ生成部８２８は、代理ＢＡメッセージ処理部８２９から、移動前外部ネットワーク接続情報による登録が成功したことを通知された場合には、ＭＮ１０のホームプレフィックスと共に、移動前外部ネットワーク接続情報による登録が成功したことを示す情報を含むＲＡメッセージを生成し、送信部８２３に対してＭＮ１０へ送信するよう指示する。登録済位置情報保持部８３０は、代理ＢＡメッセージ処理部８２９の指示を受け、ＨＡ３１及び通信相手に対して登録しているＭＮ１０の位置情報に関する情報を保持する。

図３０は本発明の第７の実施の形態におけるＨＡ３２の構成を示すブロック図である。ＨＡ３２はインタフェース８４１と、送信部８４２と、受信部８４３と、認証処理部８４４と、ＢＡメッセージ生成部８４５と、代理ＢＡ（Binding Acknowledgement）メッセージ生成部８４６と、代理ＢＵ（Binding Update）メッセージ処理部８４７と、ＢＵ（Binding Update）メッセージ処理部８４８と、ＭＮ管理情報保持部８４９とを有する。送信部８４２及び受信部８４３は、インタフェース８４１を通じてパケットの送受信を行う機能を有している。

認証処理部８４４は、代理ＢＵメッセージ処理部８４７の指示を受け、代理ＢＵメッセージを送信した代理ノード３１の認証をするための認証リクエストメッセージをＡＡＡサーバ５０へ送信する。また、ＢＵメッセージ処理部８４８の指示を受け、ＢＵメッセージを送信したＭＮ１０の認証をするための認証リクエストメッセージをＡＡＡサーバ５０へ送信する。そして、ＡＡＡサーバ５０から代理ノード３１、及びＭＮ１０の認証結果を含む認証レスポンスメッセージを受信し、その結果を代理ＢＵメッセージ処理部８４７、及びＢＵメッセージ処理部８４８へ通知する。

代理ＢＵメッセージ処理部８４７は、代理ノード３１から送信された代理ＢＵメッセージに関する処理を行い、メッセージに含まれているＭＮ１０の位置情報を取得し、ＭＮ管理情報保持部８４９へ保持するよう指示する。また、代理ＢＵメッセージ処理部８４７は、メッセージ内に移動前外部ネットワーク接続情報が含まれている場合には、置き換え対象となる移動前の位置情報が、ＭＮ１０によって登録された位置情報であることを判断し、その結果特定された位置情報を新しい位置情報で置き換える。そして、置き換えによる登録が正しく行われたことを示す情報を含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部８４６へ指示する。また、置き換え対象の位置情報にＢＩＤが付加されていた場合には、置き換えによる登録が正しく行われたことを示す情報と共に、そのＢＩＤを含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部８４６へ指示する。

なお、受信した代理ＢＵメッセージに、移動前外部ネットワーク接続情報と共に、代理ノード３１が指定したＢＩＤが含まれている場合には、位置情報の登録が正しく行われたことを示す情報と共に、そのＢＩＤを含むＢＡメッセージを生成するよう代理ＢＡメッセージ生成部８４６へ指示する。また、受信した代理ＢＵメッセージにＢＩＤが含まれていない場合や、置き換え対象の位置情報にＢＩＤが付加されていない場合には、新たに生成したＢＩＤを付加してもよい。なお、代理ＢＵメッセージを送信した代理ノード３１の認証が必要な場合には、認証処理部に対して代理ノード３１の認証を行い、その結果認証が成功した場合に上記の処理を実行するようにしてもよい。

ＢＵメッセージ処理部８４８は、ＭＮ１０から送信されたＢＵメッセージに関する処理を行い、メッセージに含まれているＭＮ１０の位置情報を取得し、ＭＮ管理情報保持部８４９へ保持するよう指示する。受信したＢＵメッセージ内に、移動前ホームネットワーク接続情報が含まれている場合には、ＭＮ１０はすでにホームネットワーク、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワークへ移動したと認識できるため、置き換え対象となる移動前の位置情報が代理ノード３１によって登録された位置情報であることを判断し、その結果特定された位置情報を新しい位置情報で置き換える。そして、置き換えによる登録が正しく行われたことを示す情報を含むＢＡメッセージを生成するようＢＡメッセージ生成部８４５へ指示する。また、置き換え対象の位置情報にＢＩＤが付加されていた場合には、置き換えによる登録が正しく行われたことを示す情報と共に、そのＢＩＤを含む代理ＢＡメッセージを生成するようＢＡメッセージ生成部８４５へ指示する。

なお、受信したＢＵメッセージにＭＮ１０が指定したＢＩＤが含まれている場合には、位置情報の登録が正しく行われたことを示す情報と共に、そのＢＩＤを含むＢＡメッセージを生成するようＢＡメッセージ生成部８４５へ指示する。また、受信したＢＵメッセージにＢＩＤが含まれていない場合や、置き換え対象の位置情報にＢＩＤが付加されていない場合には、新たに生成したＢＩＤを付加してもよい。なお、ＢＵメッセージを送信したＭＮ１０の認証が必要な場合には、認証処理部８４４に対してＭＮ１０の認証を行い、その結果認証が成功した場合に上記の処理を実行するようにしてもよい。

代理ＢＡメッセージ生成部８４６は、代理ＢＵメッセージ処理部８４７または認証処理部８４４の指示を受け、ＭＮ１０の位置情報の登録の結果を示す情報を含む代理ＢＡメッセージを生成し、送信部８４２に対し代理ノード３１へ送信するよう指示する。また、代理ＢＵメッセージ処理部８４７から、ＢＩＤを渡された場合には、そのＢＩＤも含む代理ＢＡメッセージを生成する。なお、位置情報の登録が代理ノードから通知された移動前外部ネットワーク接続情報を用いて行われた場合には、移動前外部ネットワーク接続情報を用いて行われた置換が成功したことを示す情報を用いてもよい。

ＢＡメッセージ生成部８４５は、ＢＵメッセージ処理部８４８または認証処理部８４４の指示を受け、ＭＮ１０の位置情報の登録の結果を示す情報を含むＢＡメッセージを生成し、送信部８４２に対してＭＮ１０へ送信するよう指示する。また、ＢＵメッセージ処理部８４８から、ＢＩＤを渡された場合には、そのＢＩＤも含むＢＡメッセージを生成する。なお、位置情報の登録が、ＭＮ１０から通知された移動前ホームネットワーク接続情報を用いて行われた場合には、移動前ホームネットワーク接続情報を用いて行われた置換が成功したことを示す情報を用いてもよい。

ＭＮ管理情報保持部８４９は、代理ＢＵメッセージ処理部８４７、及びＢＵメッセージ処理部８４８からの指示を受け、代理ノード３１及びＭＮ１０から通知されたＭＮ１０の位置情報を保持する。なお、ＭＮ管理情報保持部８４９は、登録した新しい位置情報の中に、その新しい位置情報によって置き換えられた移動前の位置情報が、代理ノード３１によって登録された位置情報であったことを示す情報（ＭＡＧ登録情報）を保持してもよい。この情報は、以降ＭＮ１０からの位置情報の更新があった場合でも消去されずに保持され、代理ノード３１から移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを受信した際に、このＭＡＧ登録情報が付加されている位置情報が、ＭＮ１０によって登録された情報であり、かつ、以前は代理ノード３１によって登録された位置情報に相当するものであることを判断することができる。つまり、ＭＮ１０によって一旦は置き換えられた位置情報を、再度代理ノード３１によって置き換えることができるようになる。なお、移動前ホームネットワーク接続情報は、図２４に示すように、モビリティヘッダ３０１の中や、代替ＣｏＡオプション３０３の中にフラグなどとして含まれていてもよいし、ＢＩＤを含むオプション３０４の中に含まれていてもよい。

なお、第５の実施の形態での説明したのと同様に、本実施の形態においてもＩＦ２２がネットワークベースのプロトコルが提供されているネットワーク３０からネットワーク２０へハンドオーバした際、インタフェースＩＦ１１が接続しているネットワークベースのプロトコルが提供されているネットワーク４０ａとＩＦ２２が接続していたネットワークベース３０とが同一のドメインである場合に、モバイルノード１０から送信されるバインディングアップデートメッセージは、 モバイルノード１０のインタフェースＩＦ１１を特定する識別情報（ＭＡＣアドレスなど）を含んでもよい。
本発明の第７の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されているネットワークから、提供されていないネットワークへ移動した場合でも、移動前に代理ノードによって登録された位置情報を更新するために、送信するＢＵメッセージで移動前外部ネットワーク情報をＨＡへ通知することで、代理ノードによって登録された位置情報を新たな位置情報で更新することが可能となる。

＜第８の実施の形態＞
本発明の第８の実施の形態では、ＭＮ１０のハンドオーバが、ネットワークベースの移動制御プロトコルが提供されていないネットワーク２０から、ネットワークベースの移動制御プロトコルが提供されているネットワーク３０へ行われる。また、本発明の第８の実施の形態におけるネットワーク構成は、本発明の第４の実施の形態で図１０を用いて説明した構成と同じであるため説明を省略する。また、各エンティティの構成や処理は第７の実施の形態ですでに説明しているため、ここでの説明は省略する。

図３１は、本発明の第８の実施の形態におけるシーケンスとして、ＭＮ１０がネットワーク２０で初期起動して、位置情報の登録を行った後に、ネットワーク３０にハンドオーバした場合の通信シーケンスを示す。
（１）ＭＮによる位置情報登録
・ＭＮ１０はネットワーク２０で初期起動すると、アクセス認証を行った後に、ＨＡ３２に対して位置情報の登録を行う。
（２）アクセス認証
・ＭＮ１０はネットワーク３０へ移動すると、代理ノード３１に対してアクセス認証要求を送信する。
・代理ノード３１はＭＮ１０からのアクセス認証要求を受信すると、ＡＡＡ（Authentication, Authorization, Accounting）サーバ５０に対してＡＡＡリクエスト（request）でＭＮ認証要求を送信する。
・ＡＡＡサーバ５０は代理ノード３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、代理ノード３１に対して、ＡＡＡリプライで認証ＯＫを通知する。
・代理ノード３１はＡＡＡサーバ５０からのＡＡＡリプライを受信すると、ＭＮ１０に対してアクセス認証完了を通知する。

（３）代理ノードによる位置情報登録
・ＭＮ１０は、アクセス認証が完了した後、移動前に接続していたネットワーク２０が外部ネットワークであったことを判断し、移動前に外部ネットワークに接続していたことを示す情報（以下、移動前外部ネットワーク接続情報）をＲＳメッセージに付加して代理ノード３１へ送信する。
・代理ノード３１は、ＭＮ１０からＲＳメッセージを受信すると、移動前外部ネットワーク接続情報がメッセージに含まれていることを確認し、その移動前外部ネットワーク接続情報を含む代理ＢＵメッセージをＨＡ３２へ送信する。
・ＨＡ３２は、代理ノード３１から代理ＢＵメッセージを受信すると、ＡＡＡサーバ５０に対してＡＡＡリクエストを送信し、ＡＡＡサーバ５０がＡＡＡリクエストを受信して、ＨＡ３２に対してＡＡＡリプライを送信することにより、代理ノード認証プロセスを実行する。なお、代理ノード３１の認証が不要な場合は、ＡＡＡリクエストの送信は省略してもよい。

・ＨＡ３２は、ＡＡＡサーバ５０からＡＡＡリプライを受信すると、ＢＵメッセージの中に移動前外部ネットワーク接続情報が存在することを確認し、新しい位置情報で置き換えるべき対象が、ＭＮ１０によって登録された位置情報であると判断する。そして、すでに登録されているＭＮ１０の位置情報の中から、ＭＮ１０自身によって登録された位置情報を特定して、それを新しい移動後の位置情報で置き換える。なお、ＭＮ１０の位置情報の中に、後述するＭＡＧ登録情報が付加されている位置情報があるかどうかを確認して、置き換える対象の位置情報を特定してもよい。そして、ＨＡ３２は、位置情報の登録の結果を含む代理ＢＡメッセージを代理ノード３１へ送信する。

なお、本発明の第７〜第８の実施の形態に示されているＭＮ１０が、ＨＡ３２が管理する複数の代理ノードに同時に接続している際には、本発明の第５、第６の実施の形態に示されているリンク識別子を利用した形態を用いて位置情報を特定することが可能である。
本発明の第８の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されていないネットワークから、提供されているネットワークへ移動した場合でも、代理ノードが、移動前にＭＮ１０が登録した位置情報を更新するために、ＭＮ１０から通知され移動前外部ネットワーク接続情報を、送信する代理ＢＵメッセージでＨＡへ通知することで、ＭＮ１０によって登録された位置情報を新たな位置情報で更新することが可能となる。

なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサー を利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明は、モバイルノードが、ネットワークベースのプロトコルが提供されている第１のネットワークで初期起動などして、モバイルノードのバインディングＩＤが第１のネットワークの代理ノードに対して設定された後に、モバイルノードが、ネットワークベースのプロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができるという効果を有し、ネットワークベースのプロトコルが提供されていないネットワークとしてセルラなどの３ＧＰＰネットワークに、また、ネットワークベースのプロトコルが提供されているネットワークとしてワイヤレスＬＡＮなどのＮｏｎ３ＧＰＰネットワークに利用することができる。

本発明は、モバイルノードがハンドオーバした場合にバインディングＩＤを取得するための通信方法、通信システム、モバイルノード、代理ノード及び管理ノードに関する。

ホストベースのレイヤ３移動制御プロトコルとして Mobile ＩＰｖ６（下記の非特許文献１）が存在するのに対し、ネットワークベースのレイヤ３移動制御プロトコルとして、Proxy Mobile ＩＰｖ６（下記の非特許文献２）が存在する。ホストベースのプロトコルである Mobile ＩＰｖ６では、移動ノード（Mobile Node、以下、ＭＮ）自身が移動検出から位置情報（ケアオブアドレス、バインディングキャッシュエントリ）登録までを行う。また、複数ケアオ ブアドレス登録手法（下記の非特許文献３）を用いることで、ＭＮ
が複数の通信インタフェース（以下、インタフェース）を備えている場合、それぞれのインタフェースに割り当てられる複数のケアオブアドレスを１つのホームアドレスに関連付けて登録することができる。その際には、登録されるそれぞれのバインディングキャッシュには Binding Unique Identifier （以下、ＢＩＤ又はバインディングＩＤ）が付加され、このＢＩＤはケアオブアドレスの登録・更新・削除の際に、バインディングキャッシュエントリを特定する情報として使われる。

一方、ネットワークベースの移動制御プロトコル（以下、ネットワークベースのプロトコル）では、ＭＮの移動管理がネットワーク側で行われるため、ＭＮ自身は移動制御のための処理を行う必要がなくなる。そのため、ネットワークベースのプロトコルが提供されているドメイン内のネットワークに接続しているときには、ＭＮは単なるＩＰｖ６ノードとして動作することができ、ホームエージェント（ＨＡ：Home Agent、又はＬＭＡ：Local Mobility Anchor、以下ではＨＡの方を用いる）の存在を知る必要もない。ネットワーク側に存在する代理ノード（ＰＭＩＰｖ６の場合、ＰＭＡ：Proxy Mobile Agent、又はＭＡＧ：Mobile Access Gateway、以下では代理ノード、又はＰＭＡを用いる）がＭＮのために代理で移動制御を行う。

図１に示すネットワーク構成について説明する。図１では、ネットワークベースのプロトコルが提供されているネットワーク３０（オペレータＢ）と、ネットワークベースのプロトコルが提供されていないネットワーク２０（オペレータＡ）の２つ、さらには別のネットワーク４０（オペレータＣ）が存在する。ＭＮ（モバイルノード）１０はネットワーク４０に接続可能なインタフェースＩＦ１１と、ネットワーク３０、２０の両方に接続可能なインタフェースＩＦ２２を有し、インタフェースＩＦ２２を用いてネットワーク３０、２０間をハンドオーバすることができる。また、もう一方のインタフェースＩＦ１１を用いて別のネットワーク４０に接続することができる。また、ネットワーク３０では、ネットワークベースのプロトコルとして例えばＰＭＩＰｖ６（Proxy Mobile ＩＰｖ６）が提供されており、ＭＮ１０の移動制御を担う代理ノード３１とホームエージェント（以下、ＨＡ）３２が存在する。

ＭＮ１０が２つのインタフェースＩＦ１１、ＩＦ２２を通信に利用するためには、ＨＡ３２が管理しているホームアドレスＨｏＡ１に対してそれぞれのインタフェースＩＦ１１、ＩＦ２２に対応するアドレスが転送先としてＨＡに登録されていなければならない。ネットワーク２０に接続している場合には、そのインタフェースＩＦ２２に割り当てられているアドレスがケアオブアドレスＣｏＡ１として登録されるが、ネットワーク３０に接続している場合には、代理ノード３１のアドレスがケアオブアドレスとして登録される。そのため、ＭＮ１０のインタフェースＩＦ２２がネットワーク３０に接続しているときは、代理ノード３１が位置情報登録メッセージ（Proxy Binding Update メッセージ）を送信し、ネットワーク２０に接続しているときは、ＭＮ１０自身が位置情報登録メッセージ（Binding Updateメッセージ）を送信する。このとき、ＭＮ１０のインタフェースＩＦ１１がネットワーク４０に接続している場合には、ＨＡ３２には複数のバインディングキャッシュが登録されることになるため、それぞれの位置情報登録メッセージ内のケアオブアドレスには、ＢＩＤが付加されている必要がある。
D.Johnson, C.Perkins, J.Arkko, "Mobility Support in IPv6", RFC3775, June 2004. S.Gundavelli, K.Leung, V.Devarapalli, "Proxy Mobile IPv6", draft-sgundave-mipv6-proxymipv6-00, October 2006. R.Wakikawa, T.Ernst, K.Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-00.txt, June 2006.

ところで、ＭＮ１０のインタフェースＩＦ１１はネットワーク４０に接続しているとき、ＭＮ１０自身が位置情報の登録を行うため、登録されるケアオブアドレスＣｏＡ２には、ＭＮ１０によってセットされたＢＩＤが付加される。一方、ＭＮ１０のインタフェースＩＦ２２がネットワーク３０で初期起動した場合、代理ノード３１が位置情報を登録するため、登録されるケアオブアドレス（代理ノードのアドレス）には、代理ノード３１によってセットされたＢＩＤが付加される。また、ＭＮ１０のインタフェースＩＦ２２がネットワーク２０で初期起動した場合は、ＭＮ１０自身が位置情報の登録を行うため、登録されるケアオブアドレス（ＣｏＡ１）には、ＭＮ１０によってセットされたＢＩＤが付加される。

このため、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク３０からネットワーク２０にハンドオーバする場合、移動前の位置情報は代理ノード３１によって登録されているため、ネットワーク２０へハンドオーバした後、ＭＮ１０が位置情報を登録することになったときに、登録するＭＮ１０の移動後の位置情報に、移動前に代理ノード３１によって使われたＢＩＤを指定することができないため、その位置情報登録メッセージを受信したＨＡ３２は、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまうという問題が発生する。また、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク３０からネットワーク２０にハンドオーバする場合、ネットワーク２０へハンドオーバした後にＭＮ１０がＢＩＤを指定せずに位置情報の登録を行った場合、その位置情報登録メッセージを受信したＨＡ３２は、置き換える対象となる位置情報を特定するためのＢＩＤがメッセージ内に含まれていないため、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまうという問題も発生する。

また、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク２０からネットワーク３０にハンドオーバする場合、移動前の位置情報はＭＮ１０自身によって登録されているため、ネットワーク３０へハンドオーバした後、代理ノード３１が位置情報を登録することになったときに、登録するＭＮ１０の移動後の位置情報に、移動前にＭＮ１０によって使われたＢＩＤを指定することができないため、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまうという問題が発生する。また、ＭＮ１０がインタフェースＩＦ１１でネットワーク４０へ接続しているときに、インタフェースＩＦ２２がネットワーク２０からネットワーク３０にハンドオーバする場合、ネットワーク３０へハンドオーバした後に、代理ノード３１がＢＩＤを指定せずに位置情報の登録を行った場合、その位置情報登録メッセージを受信したＨＡ３２は、置き換える対象となる位置情報を特定するためのＢＩＤがメッセージ内に含まれていないため、置き換える対象となる位置情報を特定することができない、あるいは登録されているＭＮ１０に関する全ての位置情報を置き換える対象として扱ってしまい、登録されている全ての位置情報を削除してしまうという問題も発生する。

また、ＭＮ１０は、ネットワーク３０に接続したときに、自身のホームプレフィックスが含まれる Router Advertisement を受信するため、ホームネットワークに接続した際の Mobile ＩＰｖ６の処理として、ＨＡ３２に登録されているバインディングキャッシュの削除を実行してしまう。しかし、実際にはネットワークベースのプロトコルが提供されていて、代理ノード３１による位置情報の登録が行われているため、ＭＮ１０は削除処理を行ってはならない。
すなわち、従来技術においては、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新が行なわれる可能性があった。

本発明は上記従来技術の問題点に鑑み、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新を防止する通信方法、通信システム、モバイルノード、代理ノード及び管理ノードを提供することを目的とする。

本発明の通信方法は上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信方法であって、
前記モバイルノードが、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信するステップと、
前記代理ノードが、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信するステップと、
前記管理ノードが、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信するステップと、
前記代理ノードが、前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信するステップと、
前記モバイルノードが、前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの前記管理ノードに対して前記バインディングＩＤの要求メッセージを送信するステップと、
前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、
前記管理ノードが、前記バインディングＩＤを前記モバイルノードに送信するステップとを有する。
上記方法により、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

本発明の通信システムは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続する前記モバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信する手段と、
前記代理ノードが前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信する手段と、
前記モバイルノードが、前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの管理ノードに対して前記バインディングＩＤの要求メッセージを送信する手段と、
前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、
前記管理ノードが前記バインディングＩＤを前記モバイルノードに送信する手段とを有する。
上記システムにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

本発明のモバイルノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースのプロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信し、前記代理ノードが前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信した場合に、前記割り当て情報を受信する手段と、
前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの前記管理ノードに対して前記バインディングＩＤの要求メッセージを送信する手段と、
前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、前記管理ノードが前記バインディングＩＤを前記モバイルノードに送信した場合に、前記バインディングＩＤを受信する手段とを、
備えた。
上記モバイルノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

本発明の代理ノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信した場合に、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信した場合に、前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信する手段とを、
備えた。
上記代理ノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の通信方法は上記目的を達成するために、
前記バインディングＩＤ割り当て要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであり、
前記代理ノードが送信する前記バインディングＩＤが割り当てられていることを示す割り当て情報は、ＤＨＣＰリプライメッセージであることを特徴とする。

また、本発明の通信方法は上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信方法であって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信するステップと、
前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信するステップと、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信するステップと、
前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信するステップとを有する。
上記通信方法により、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の通信システムは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信する手段と、
前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信する手段とを有する。
上記通信システムにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明のモバイルノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信し、前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信した場合、前記バインディングＩＤを受信する手段とを有する。
上記モバイルノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の代理ノードは上記目的を達成するために、
ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信した場合、前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信した場合、前記バインディングＩＤを受信して前記モバイルノードに対して送信する手段とを有する。
上記代理ノードにより、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができる。

また、本発明の通信方法は上記目的を達成するために、
前記バインディングＩＤ要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであり、
前記代理ノードが送信する前記バインディングＩＤは、ＤＨＣＰリプライメッセージに含まれることを特徴とする。

また、本発明の通信方法は上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信方法であって、
前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信するステップと、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶するステップと、
前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信するステップと、
前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信するステップと、
前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信するステップとを有する。
上記通信方法により、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明の通信システムは上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムであって、
前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶する手段と、
前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信する手段と、
前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信する手段とを有する。
上記通信システムにより、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明のモバイルノードは上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信する手段を備えて、前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶するようにし、
前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信する手段を備えて、前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信するようにした。
上記モバイルノードにより、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明の代理ノードは上記目的を達成するために、
モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ要求を受信して、前記バインディングＩＤを生成して記憶し、前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信した場合、前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信する手段と、
前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信した場合、前記バインディングＩＤを受信する手段とを有する。
上記代理ノードにより、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができる。

また、本発明の通信方法は、前記バインディングＩＤ取得要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであることを特徴とする。
また、前記代理ノードが前記バインディングＩＤを前記モバイルノードに対して送信する場合、前記代理ノードが前記モバイルノードからのＤＨＣＰレスポンスメッセージに応答するＤＨＣＰリプライメッセージで送信することを特徴とする。
また、前記代理ノードが前記バインディングＩＤを前記モバイルノードに対して送信する場合、前記代理ノードが前記モバイルノードからのアクセス認証要求メッセージに応答するアクセス認証完了メッセージで送信することを特徴とする。

また、本発明の通信方法は、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信方法であって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信するステップと、
前記バインディングアップデートメッセージを受信した前記管理ノードが、前記置換された位置情報に対応するバインディングＩＤを前記モバイルノードに送信するステップとを、
有する。

また、本発明の通信システムは、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムであって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信する手段と、
前記バインディングアップデートメッセージを受信した前記管理ノードが、前記置換された位置情報に対応するバインディングＩＤを前記モバイルノードに送信する手段とを、
備えた。

また、本発明のモバイルノードは、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムにおける前記モバイルノードであって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信する手段と、
前記バインディングアップデートメッセージを受信した前記管理ノードから、前記置換された位置情報に対応するバインディングＩＤを受信する手段とを、
備えた。

また、本発明の管理ノードは、ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムにおいて前記位置情報を管理する管理ノードであって、
前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報と供に前記モバイルノードから受信する手段と、
前記置換した位置情報に対応するバインディングＩＤを前記モバイルノードに送信する手段とを、
備えた。

本発明によれば、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができるので、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新を防止することができる。
また、モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に第１のネットワークの代理ノードがバインディングＩＤを取得することができるので、複数のインタフェースを備えるＭＮがネットワークベースのプロトコルが提供されているネットワークと、ネットワークベースのプロトコルが提供されていないネットワーク間をハンドオーバした場合に、位置情報の誤った更新を防止することができる。

以下、図面を参照して本発明の実施の形態について説明する。
図１は本発明の第１の実施の形態におけるネットワークの構成を示すブロック図であり、ネットワークベースのプロトコルが提供されていないネットワーク４０は一例として、セルラなどの３ＧＰＰ（3rd Generation Partnership Project）ネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。ネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。

また、図１２に示すように、ネットワーク４０とネットワーク３０は、同一のオペレータＡによって提供されていてもよく、その場合、ホームエージェント３２はネットワーク２０、３０、４０のすべてにとって共通のホームエージェントとなる。オペレータＡが提供するネットワーク４０は一例として、セルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。オペレータＢのネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。図１２におけるオペレータＡを３ＧＰＰオペレータとし、オペレータＢをＮｏｎ３ＧＰＰオペレータと想定してもよい。

さらに、図１３に示すように、ネットワーク２０、３０、４０のすべてが同一のオペレータＡによって提供されていてもよく、その場合も、ホームエージェント３２はネットワーク２０、３０、４０のすべてにとって共通のホームエージェントとなる。ネットワーク４０は一例としてセルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。ネットワークベー スのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。なお、図１、図１２、図１３において、ネットワーク３０とネットワーク４０に接続した際に取得するアドレスは、同じアドレスであってもよい。その場合オペレータＡは、ＭＮ１０のＩＦ１１及びＩＦ２２が接続しているオペレータＡ内での移動を管理する機能を持つ。

なお、上記のネットワーク構成において、ネットワーク２０及びネットワーク４０はネットワークベースのプロトコルが提供されていないネットワークとしているが、ネットワークベースのプロトコルが提供されているがＭＮ１０はそれを使用していないという場合でもよい。すなわち本発明の第１の実施の形態におけるＭＮは、ネットワーク３０ではネットワークベースのプロトコルを使用し、ネットワーク２０では使用していない。

図２は本発明の第１の実施の形態における通信シーケンスとして、ＭＮ１０がネットワーク３０で初期起動してネットワーク３０の代理ノード３１（ＰＭＡ：Proxy Mobile Agent、ＭＡＧ：Mobile Access Gateway、以下では代理ノード、ＰＭＡのいずれかを用いるが同じものを指す）によりＢＩＤが指定された後に、ネットワーク２０にハンドオーバした場合の通信シーケンスを示す。なお、図２における丸付き数字は、本明細書では括弧付き数字で示す。

＜ネットワーク３０で初期起動した場合＞
（１）アクセス及びモビリティ認証
・ＭＮ１０はネットワーク３０で初期起動すると、ＰＭＡ３１に対してアクセス認証要求メッセージ（以下の説明及び通信シーケンス図では、「メッセージ」は省略）を送信する。
・ＰＭＡ３１はＭＮ１０からのアクセス認証要求を受信すると、ＡＡＡ（Authentication, Authorization, Accounting）サーバ５０に対してＡＡＡリクエスト（request）でＭＮ認証要求を送信する。
・ＡＡＡサーバ５０はＰＭＡ３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、ＢＩＤ２を生成し、ＢＩＤ２を割り当てたＭＮ１０とＰＭＡ３１を記憶して、ＰＭＡ３１に対して、ＡＡＡ reply で認証ＯＫ、MobileIPv6 ＯＫ、ＢＩＤ２を通知する。
・ＰＭＡ３１はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してアクセス認証完了を通知する。

（２）ＰＭＡによる位置登録、アドレス割り当て
・ＰＭＡ３１はＨＡ３２に対して、Proxy ＢＵ（Binding Update）を送信してＰＭＡ３１のアドレス（ＰＭＡ addr）とＢＩＤ２を登録する。
・ＨＡ３２がこの受信後、ＡＡＡサーバ５０に対してＡＡＡ Query を送信し、ＡＡＡサーバ５０がＡＡＡ Query を受信して、ＨＡ３２に対してＡＡＡ Reply を送信することにより、ＰＭＡ認証プロセスを実行する。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ Reply を受信すると、ＰＭＡ３１に対してProxy ＢＡ（Binding Acknowledgement）を送信する。
・ＰＭＡ３１はＨＡ３２から位置登録ＯＫを示す Proxy ＢＡを受信すると、ＭＮ１０に対してＲＡ（Router Advertisement）を送信して Home Prefix とＭフラグを通知する。
・ＭＮ１０はＰＭＡ３１からのＲＡを受信すると、ＰＭＡ３１に対してＤＨＣＰ（Dynamic Host Configuration Protocol）request を送信する。
・ＰＭＡ３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信して、ＭＮ１０へ割り当てるアドレスとともに、ＨＡ３１のアドレス（ＨＡ address）と、ＰＭＩＰネットワークに位置していることを示すＩｓＰＭＩＰ情報と、ＢＩＤが割り当てられていることを示すＢＩＤ割り当てＯＫ（ＢＩＤAllocＯＫ）を通知する。
なお、ＩｓＰＭＩＰ情報及びＢＩＤ Alloc情報はＲＡの中に含まれていてもよい。また、ＲＡのＭフラグがセットされていない場合には、ＭＮ１０はアドレスを自動生成し、ＤＨＣＰによる取得は行わなくてよい。

ＭＮ１０はＰＭＡ３１からのＤＨＣＰ reply を受信すると、ＩｓＰＭＩＰ情報により以下を認識する。
・ネットワークベースの移動制御プロトコル（ＰＭＩＰ）が提供されている。
・割り当てられたアドレスがＨｏＡである。
また、ＭＮ１０はＢＩＤAlloc情報により以下を認識する。
・他のＩＦのＣｏＡを登録できる。

＜ネットワーク２０にハンドオーバ＞
ＭＮ１０はネットワーク２０にハンドオーバすると、ＩｓＰＭＩＰ情報により以下を認識する。
・ＨｏＡ取得不要
また、ＭＮ１０はＢＩＤAlloc情報により以下を認識する。
・ＢＩＤ取得可能。

（３）ＳＡ（Security Association）の生成：ＩＫＥ（Internet Key Exchange）ｖ２
・ＭＮ１０はネットワーク２０にハンドオーバすると、ＨＡ３２に対して、ＩＫＥリクエストメッセージであるＩＫＥ＿ＡＵＴＨを送信してＢＩＤを要求する。
・ＨＡ３２がＭＮ１０からのＩＫＥ＿ＡＵＴＨを受信して、ＡＡＡサーバ５０に対してＡＡＡ request を送信してＭＮ認証とＢＩＤを要求し、ＡＡＡサーバ５０がこのＡＡＡ request を受信して、ＨｏＡに対応 するＢＩＤを選択し、ＨＡ３２に対してＡＡＡ replyを送信して認証ＯＫとＢＩＤ２を通知することにより、Mobile ＩＰｖ６初期化プロセスを実行する。このとき、ＡＡＡサーバ５０は既に登録されているＢＩＤがあれば、そのＢＩＤは以前にＰＭＡ３１が要求したものであるのでそれを返す。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してＩＫＥレスポンスメッセージであるＣＦＧ＿ＲＥＰＬＹを送信してＢＩＤ２を通知する。
なお、ＭＮ１０は、ハンドオーバ前のネットワーク３０に接続中にＩＫＥｖ２を開始してもよい。その場合、ネットワーク２０へハンドオーバしてアクセス認証が完了した後すぐに、ＢＵメッセージを送信して位置情報の登録を行うことができる。

（４）位置登録
・ＭＮ１０はＨＡ３２からのＣＦＧ＿ＲＥＰＬＹを受信すると、ＨＡ３２に対してＢＵを送信して Addr2 とＢＩＤ２を登録する。
・ＨＡ３２はＭＮ１０からのＢＵを受信すると、登録されているＭＮ１０の位置情報の中から、ＢＩＤ２に対応する位置情報を更新して、ＭＮ１０に対してＢＡを送信して位置登録ＯＫを通知する。

図３はＭＮ１０の構成を示すブロック図である。ＭＮ１０は前述したインタフェースＩＦ１１、ＩＦ２２の他、送信部１０１と、受信部１０２と、ＤＨＣＰリクエストメッセージ生成部１０３と、Binding Update（ＢＵ）メッセージ生成部１０４と、ＩＫＥリクエストメッセージ生成部１０５と、ＲＳ（Router Solicitation）送信処理部１０６と、ネットワーク接続検出部１０７と、アクセス認証処理部１０８と、ＲＡ（Router Advertisement）処理部１０９と、ＤＨＣＰメッセージ処理部１１０と、ＩＫＥレスポンスメッセージ処理部１１１と、ＢＡ（Binding Acknowledgement）メッセージ処理部１１２と、登録済位置情報保持部１１３と接続ネットワーク情報保持部１１４を有する。

以下では、ＭＮ１０が備える主要構成要素について説明する。ＲＳ送信処理部１０６は、アクセス認証処理部１０８からアクセス認証が完了したことの通知を受けて、接続しているネットワーク２０又は３０又は４０に対してＲＡメッセージの送信を要求するためのＲＳメッセージを生成して送信部１０１に対して送信するよう指示する。なお、ＲＳメッセージは、送信する前にＲＡメッセージを受信することができた場合は、送信する必要はない。ＤＨＣＰリクエストメッセージ生成部１０３は、アクセス認証処理部１０８からアクセス認証が完了したことの通知を受けたとき、あるいはＲＡ処理部１０９からＤＨＣＰ開始の指示を受けたときに、接続しているネットワーク２０又は３０又は４０に対してＤＨＣＰリクエストメッセージを生成して送信部１０１に対して送信するよう指示する。

ＩＫＥリクエストメッセージ生成部１０５は、ＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした後、アクセス認証処理部１０８からアクセス認証が完了したことの通知を受けて、自身のホームエージェントとの間で Security Association（ＳＡ）を生成するためにＩＫＥｖ２を開始する。その際に、図１４に示す判断を行い、ＢＩＤの取得・通知を要求するためのメッセージとしてＩＫＥリクエストメッセージ（ＣＦＧ＿ＲＥＱＵＥＳＴ）を生成し、その中にＢＩＤの通知を要求する情報を付加して送信する。

図１４に示す判断処理について説明する。ネットワーク間を移動すると（ステップＳ１）、移動先ネットワークにネットワークベースのプロトコル（ネットワークベースの移動制御プロトコル）があるか否かを判断する（ステップＳ２）。ここで、ある場合は、ＭＮ１０のホームプレフィックスが広告され、ない場合にはフォリンプレフィックス(foreign prefix)が広告されているので、この判断を行うことができる。ステップＳ２で移動先ネットワークにネットワークベースプロトコルがない場合には、後述するステップＳ７に進む。他方、ある場合には、その移動先ネットワークが移動前ネットワークと同一ドメインか否かを判断する（ステップＳ３）。ここで、同一ドメインの場合には、移動前ネットワークと同じホームプレフィックスが移動先ネットワークで広告されているので、この判断を行うことができる。ステップＳ３で同一ドメインの場合には、移動制御を行わない（ステップＳ４）。他方、ステップＳ３で同一ドメインでない場合には、移動先ネットワークのネットワークベースプロトコルに切り替えるか否かを判断し（ステップＳ５）、切り替える場合にはホームアドレスを切り替えるが、移動制御を行わない（ステップＳ６）。他方、切り替えない場合にはステップＳ７に進む。

ステップＳ７では移動前のネットワークのＨＡを使用するか否かを判断し、使用しない場合には別のＨＡへＢＵを送信し、移動制御を行う（ステップＳ８）。なお、ステップＳ８において、別のＨＡへＢＵを送信せずに、移動制御を行わないという選択をしてもよい。他方、移動前のネットワークのＨＡを使用する場合には、移動前ネットワークではネットワークベースプロトコルを使用していたか否かを判断する（ステップＳ９）。そして、使用していた場合には、移動前ネットワークから接続中に使用されていたＢＩＤを取得し（ステップＳ１０）、次いでこの取得したＢＩＤを含むＢＵを送信する（ステップＳ１２）。他方、ステップＳ９で使用していなかった場合には、移動前ネットワークから、新たなＢＩＤを取得し（ステップＳ１１）、次いでこのＢＩＤを含むＢＵを送信する（ステップＳ１２）。なお、ステップＳ１１において、移動前ネットワークで自ら移動制御を行っていた場合には、移動前ネットワークで使用していたＢＩＤを引き続き使用する。

ＩＫＥレスポンスメッセージ処理部１１１は、ＩＫＥリクエストメッセージ（ＣＦＧ＿ＲＥＱＵＥＳＴ）に対する応答であるレスポンスメッセージ（ＣＦＧ＿ＲＥＰＬＹ）の中に含まれているＢＩＤを取得し、接続ネットワーク情報保持部１１４に対して保持するよう指示する。なお、ＢＩＤの取得・通知を要求するメッセージとしては、ＲＳメッセージや、ＮＳ（Neighbor Solicitation）メッセージ、ＤＨＣＰ requestメッセージ、さらにはＢＵメッセージでもよい。その場合、ＭＮ１０は、それらのメッセージの中にＢＩＤの通知を要求する情報（フラグなど）を付加して送信し、それを受けたＰＭＡ３１は、認証結果保持部１４２や、バインディングアップデートリストからＭＮ１０の位置情報登録に使用しているＢＩＤを取得し、ＲＡメッセージや、ＮＡ（Neighbor Advertisement）メッセージ、ＤＨＣＰ replyメッセージ、ＢＡメッセージを用いてそのＢＩＤをＭＮ１０へ通知する。これらのメッセージは、移動後に限らず、移動前つまりネットワーク３０に接続中に送信されてもよい。

Binding Update メッセージ生成部１０４は、ＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした後、ＩＫＥレスポンスメッセージ処理部１１１からＳＡ生成及びＢＩＤの取得が完了したことの通知を受けて、自身で位置情報を登録するときに、接続ネットワーク情報保持部１１４に保持されているネットワーク３０から割り当てられたＢＩＤを取得し、そのＢＩＤを付加してケアオブアドレスを登録するためのＢＵメッセージを生成する。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用する場合、Binding Updateメッセージ生成部１０４は、ＢＩＤが付加されていないＢＵメッセージをＨＡ３２へ送信し、それを受けたＨＡ３２が、以前ＰＭＡ３１によって登録された位置情報を特定し、その位置情報を新しい位置情報で置き換えると共に、旧位置情報に付加されていたＢＩＤをＢＣ（Binding Cache：バインディングキャッシュ）から取得し、そのＢＩＤをＢＡメッセージに含めて送信する。
また、ＨＡ３２は、置き換え対象である位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバや、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。このＢＡメッセージを受けたＭＮは、受信したＢＡメッセージに含まれているＢＩＤを、以降の位置情報の登録の際に使用する。この場合のＢＵメッセージ３００には、図２３に示すように、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４がＢＩＤの取得を要求することを示す情報として使われてもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。
ＢＡメッセージ処理部１１２は、Binding Update メッセージ生成部１０４によって生成・送信された、ＩＦ２２の位置情報とネットワーク３０から割り当てられたＢＩＤを含むＢＵメッセージに対する応答であるＢＡメッセージの受信に関する処理を行う。ＢＡメッセージには、位置情報の登録が完了したことを示す情報が含まれており、登録位置情報保持部１１３に対して、ＨＡ３２に登録した位置情報を保持するよう指示する。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用した場合、ＢＡメッセージには、位置情報の登録完了を示す結果と共にネットワーク３０から割り当てられたＢＩＤが含まれており、登録位置情報保持部１１３に対して、割り当てられたＢＩＤと共にＨＡ３２に登録した位置情報を保持するよう指示する。登録位置情報保持部１１３は、ＢＡメッセージ処理部１１２から指示を受け、登録済みである位置情報を示す情報として、登録した位置情報を保持する。なお、ＢＡメッセージによって割り当てられたＢＩＤを取得する場合は、ＢＩＤも保持する。

ＲＡ処理部１０９は、接続するネットワーク２０、３０、４０上のルータ（ＰＭＡ３１など）から受信したＲＡメッセージの処理を行い、このＲＡメッセージの中に含まれているＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報（ＢＩＤAlloc情報）を取得し、接続ネットワーク情報保持部１１４に保持するよう指示する。ＩｓＰＭＩＰ情報は、ネットワーク２０、３０、４０側が、ネットワークベースの移動制御プロトコルを提供しているネットワークであるかどうかをＭＮ１０に対して示すための情報であり、フラグなどを用いてその情報を示すことができる。フラグはＲＡメッセージの Reserved フィールドに新たなＩｓＰＭＩＰフラグを設けてもよい。また、ＲＡメッセージに付加される Prefix Information Option の中の Reserved フィールドであってもよい。なお、ＢＩＤの取得・通知を要求するためのメッセージとしてＲＳメッセージを使用した場合、受信するＲＡメッセージにはＢＩＤが含まれているため、ＲＡ処理部１０９は、ＩＫＥレスポンスメッセージ処理部１１１と同様に、取得したＢＩＤを接続ネットワーク情報保持部１１４に対して保持するよう指示する。

ＩｓＰＭＩＰ情報がセットされているＲＡメッセージをネットワークから受信した場合、ＭＮ１０は、接続しているネットワークではネットワークベースの移動制御プロトコル（ＰＭＩＰ）が動作していること、さらには取得したアドレスが自身のホームアドレスであることを認識する。そのため、ＭＮ１０は、ネットワーク３０に接続しているＩＦ２２に関する位置情報の登録を自身で行う必要がないため、ホームエージェント３２のアドレスを知るための処理や、ホームエージェント３２との間に Security Association を生成するための処理を行う必要がないことを認識する。特に、ＩＦ１１がネットワーク４０に接続していないときには、ＭＮ１０がネットワーク３０に接続しているときであればホームエージェント３２のアドレスを一切知る必要はないためこの効果は大きい。ＩＦ２２がハンドオーバした後には、自身で位置情報を登録しなければならないため、ホームエージェント３２のアドレスを知る必要があるが、それでもハンドオーバ前に行う必要はなく、ハンドオーバ後でも行うことができるため、ＭＮ１０はネットワーク３０に接続中はホームエージェント３２のアドレスを知る必要はない。

しかし、ＩＦ１１がネットワーク４０に接続しているときには、たとえＩＦ２２がネットワーク３０に接続しているときであっても、自身でＩＦ１１の位置情報を登録するためにホームエージェント３２のアドレスを知らなければならないため、ＭＮ１０はホームエージェント３２のアドレスの取得を行う必要がある。このホームエージェント３２のアドレスの取得方法としては、主なものとして以下の３つがある。なお、図２のシーケンス図では、（１）の場合を示している。
（１）ＭＮ１０は、ハンドオーバ前に接続しているネットワーク３０経由でホームエージェント３２のアドレスを取得する、
（２）ハンドオーバ後に接続するネットワーク２０経由でホームエージェント３２のアドレスを取得する、さらには
（３）ＩＦ１１が接続しているネットワーク４０経由で取得する。

ハンドオーバ前に取得する場合には、アクセス認証プロセスの中で、ＡＡＡサーバ５０がＭＮ１０にホームエージェント３２を割り当てて、代理ノード３１へその結果を通知し、最終的にＭＮ１０は、ＤＨＣＰを用いてネットワーク３０側から割り当てられたホームエージェント３２のアドレスを取得することができる。またハンドオーバ後に取得する場合には、接続ネットワークに対するアクセス認証が完了した後に、ＤＮＳ（Domain Name System）サーバ（不図示）に対してホームエージェント３２を提供するオペレータのドメイン名を問い合わせてホームエージェント３２のアドレスを取得する。また、ネットワーク４０経由で取得する場合も同様に、ＤＮＳサーバへの問い合わせでホームエージェント３２のアドレスを取得することができる。

第１の実施の形態におけるＭＮ１０は、上記３つのいずれかを使ってホームエージェント３２のアドレスを取得してもよいが、ネットワーク３０経由で取得する場合、ＤＨＣＰレスポンスメッセージには、ＭＮ１０に割り当てられるアドレスとともに、ホームエージェント３２のアドレスも含まれている。そのため、ＭＮ１０はホームエージェント３２のアドレスのプレフィックスと、自身の割り当てられたアドレス又はＲＡメッセージの中のプレフィックスを比較し、両者が一致した場合には割り当てられたアドレスがホームアドレスであることを認識することもできる。

しかし、この場合は、ホームネットワークであることは認識できるが、ネットワークベースの移動制御プロトコルが提供されているネットワークであるかどうかは依然として分からないため、ＩｓＰＭＩＰ情報が存在しない場合には、Mobile ＩＰｖ６又は複数ケアオブアドレス登録手法で規定されているホームネットワークに接続したときの動作（ＨＡ３２に登録しているバインディングキャッシュをすべて削除、又はホームプレフィックスからケアオブアドレスを生成して登録、さらにはホームネットワークに接続していることを示す情報を登録など）を行おうとしてしまう。しかしＩｓＰＭＩＰ情報をＭＮ１０へ通知することでこれを回避することができる。

また、ＢＩＤ Allocation 情報は、ネットワークベースの移動制御プロトコルを提供している代理ノード３１が、ＭＮ１０のための位置情報をホームエージェント３２へ登録する際にＢＩＤを付加して登録したかどうか、すなわちＭＮ１０は複数ケアオブアドレスの登録が許可されているノードかどうか、を示す情報であり、フラグなどを用いてその情報を示すことができる。ＢＩＤ Allocation 情報がセットされているＲＡメッセージをネットワークから受信した場合、ＭＮ１０はネットワーク３０側の代理ノード３１によってＢＩＤが付加された位置情報がホームエージェント３２に登録されていること、さらには、ＳＡを生成する際にＢＩＤを要求すれば、代理ノード３１が使用したＢＩＤを知ることができることを認識する。

そのため、ＩＦ２２がハンドオーバしてネットワーク２０に接続したときに、自身で登録する位置情報に付加するＢＩＤを、代理ノード３１によって付加されたＢＩＤと同じ値にし、既に登録されているバインディングキャッシュを新たなアドレスで上書きするために、ＭＮ１０はＩＫＥｖ２を行ってＢＩＤを取得する。ＢＩＤ Allocation 情報は、ホームエージェント３２に登録されているバインディングキャッシュにＢＩＤが付加されているかどうかだけを示す情報であるため、フラグなどの必要最小限の情報で構成することができる。これにより、ＭＮ１０のＩＦ２２がオペレータＢのネットワーク３０以外に接続しないときには、代理ノード３１によって使われた実際のＢＩＤを知る必要はなく、付加されたか否かだけを知れば十分であるため、ＢＩＤ Allocation 情報は効果的である。

また、ＲＡ処理部１０９は、ＲＡメッセージ内のＭフラグがセットされている場合には、ＤＨＣＰリクエストメッセージ生成部１０３に対してＤＨＣＰリクエストメッセージを生成するよう指示する。なお、ＲＡメッセージに含まれるＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報は、ＤＨＣＰメッセージ処理部１１０が生成するＤＨＣＰレスポンスメッセージの中に含まれていてもよい。特に、ＭＮ１０自身がアドレスを自動生成する場合は、ＤＨＣＰを使わないため、ネットワーク側はＲＡメッセージを接続ネットワーク情報の通知手段として使用できる。一方、ＭＮ１０がＤＨＣＰを用いてアドレスの割り当てを受ける場合には、ネットワーク側はＤＨＣＰレスポンスメッセージを情報の通知手段として使用できる。また、ＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報を示す手段としては、フラグだけでなく、ＲＡメッセージやＤＨＣＰレスポンスメッセージに付加可能なオプションとして示されてもよい。

アクセス認証処理部１０８は、ネットワーク接続検出部１０７からアクセスネットワークに接続したことの通知を受け、そのネットワークに対する認証処理を開始するためのアクセス認証リクエストをネットワークに対して送信し、その認証結果をネットワークから受信する。その認証結果がＭＮ１０の接続を許可するものであった場合には、ＲＳ送信処理部１０６、ＤＨＣＰリクエストメッセージ生成部１０３、ＩＫＥリクエストメッセージ生成部１０５に対して認証の完了を通知する。アクセス認証では、ＩＥＥＥ８０２．１ｘやＩＥＥＥ８０２．１１ｉなどの方法が用いられ、認証方式としては、ＥＡＰ−ＭＤ５、ＥＡＰ−ＴＬＳ、ＥＡＰ−ＴＴＬＳ、ＥＡＰ−ＰＥＡＰなどが用いられる。アクセス認証部１０８が生成するアクセス認証要求メッセージは特に新しい情報を持たないが、ＰＭＡ３１が送信する認証リクエストメッセージのトリガとなり、さらにその後のＡＡＡサーバによるＢＩＤ割り当てをトリガするメッセージでもある。このためＭＮ１０およびＰＭＡ３１にとっては、ＢＩＤの割り当てを要求するためのメッセージとみなすことができる。なお、アクセス認証要求メッセージの中に明示的にＢＩＤの割り当てを要求する情報を含めてもよい。

図４は本発明の第１の実施の形態における代理ノード（ＰＭＡ）３１の構成を示す図である。代理ノード３１はネットワークとの通信インタフェースであるインタフェース１３１と、送信部１３２と、受信部１３３と、認証リクエストメッセージ生成部１３４と、アクセス認証結果通知メッセージ生成部１３５と、代理 Binding Update（ＢＵ）メッセージ生成部１３６と、ＤＨＣＰ reply メッセージ生成部１３７と、ＲＡ 生成部１３８と、接続ネットワーク情報判断部１３９と、アクセス認証要求メッセージ処理部１４０と、認証レスポンスメッセージ処理部１４１と、認証結果保持部１４２と、代理ＢＡメッセージ処理部１４３と、ＤＨＣＰ request メッセージ処理部１４４を有する。

図４において、アクセス認証要求メッセージ処理部１４０は、ＭＮ１０からのアクセス認証要求メッセージを処理し、認証リクエストメッセージ生成部１３４に対して認証リクエストメッセージを生成し、送信するよう指示する。なお、認証リクエストメッセージには、明示的にＢＩＤの割り当て、及びＢＩＤの取得・通知を要求することを示す情報（フラグなど）を付加してもよい。認証レスポンスメッセージ処理部１４１は、ＡＡＡサーバ５０から受信した認証レスポンスメッセージを処理し、そのメッセージに含まれている認証結果とＭＮ１０に対して割り当てられたＢＩＤを取得して認証結果保持部１４２に保持する。また、アクセス認証結果通知メッセージ生成部１３５に対してＡＡＡサーバ５０から取得した認証結果をＭＮ１０へ通知するためのアクセス認証結果通知メッセージを生成するよう指示する。さらに代理ＢＵメッセージ生成部１３６に対して、認証の完了を通知する。

認証結果保持部１４２は、ＭＮの認証結果と共にＭＮ１０に割り当てられたＢＩＤを保持する。なお、ＭＮ１０に割り当てられたＢＩＤは、ＭＮ１０の管理情報を格納するＢＵＬ（Binding Update List：バインディングアップデートリスト）に保持してもよく、ＢＵＬが認証結果保持部１４２として機能していてもよい。その場合、代理ＢＡメッセージ処理部１４３から指示を受け、登録済みである位置情報を示す情報として、登録した位置情報を保持する。なお、代理ＢＡメッセージによって割り当てられたＢＩＤを取得する場合は、ＢＩＤも保持する。代理ＢＵメッセージ生成部１３６は、認証レスポンスメッセージ処理部１４１から認証完了の通知を受け、認証結果保持部１４２からＭＮ１０に対して割り当てられたＢＩＤを取得し、そのＢＩＤを付加したケアオブアドレスを登録するための代理ＢＵメッセージを生成する。なお、代理ＢＵメッセージ生成部１３６は、ＢＵＬからＭＮ１０に割り当てられたＢＩＤを取得してもよい。なお、ＢＩＤの取得・通知を要求するメッセージとして、代理ＢＵメッセージを使用してもよい。この場合、代理ＢＵメッセージ生成部１３６は、ＢＩＤが付加されていない代理ＢＵメッセージをＨＡ３２へ送信してＢＩＤの通知を要求し、それを受けたＨＡ３２が、以前ＭＮ１０によって登録された位置情報に付加されているＢＩＤをＢＣから取得し、そのＢＩＤを代理ＢＡメッセージに含めて送信する。この場合の代理ＢＵメッセージには、図２３のＢＵメッセージ３００と同様に、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４がＢＩＤの取得を要求することを示す情報として機能してもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。
さらに、ＨＡ３２は、特定した位置情報を新しい位置情報で置き換えると共に、この代理ＢＵメッセージに対して送信する代理ＢＡメッセージに、置き換え対象である位置情報に付加されているＢＩＤをＢＣ（Binding Cache：バインディングキャッシュ）から取得し、そのＢＩＤを 代理ＢＡメッセージに含めて送信する。また、置き換え対象である位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、代理ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバや、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。

代理ＢＡメッセージ処理部１４３は、代理ＢＵメッセージ生成部１３６が送信した代理ＢＵメッセージに対する応答である代理ＢＡメッセージの処理を行い、通知した位置情報が登録されたかどうかの結果を取得する。位置情報が登録された場合には、ＲＡ生成部１３８に対してＭＮ１０のホームプレフィックスを含むＲＡメッセージを送信するよう指示する。なお、ＢＩＤの取得・通知を要求するメッセージとして、代理ＢＵメッセージを使用した場合、代理ＢＡメッセージには、位置情報の登録完了を示す結果と共にネットワーク３０から割り当てられたＢＩＤが含まれており、認証結果保持部１４２に対して、割り当てられたＢＩＤと共にＨＡ３２に登録した位置情報を保持するよう指示する。
ＲＡ生成部１３８は、接続ネットワーク情報判断部１３９に対して、ＲＡメッセージに含める情報であるＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報をセットするべきかどうかを確認する。セットするべきとの判断が返ってきた場合には、ホームプレフィックスを含むＲＡメッセージにＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報をセットして送信部１３２に対して、インタフェース１３１を介してネットワークに送信するよう指示する。なお、ＭＮ１０から、ＲＳメッセージによってＢＩＤの通知要求を受けた場合、ＲＡ生成部１３８は、ＭＮ１０の位置情報の登録に使用しているＢＩＤを含むＲＡメッセージを生成してＭＮ１０へ送信する。また、ＭＮ１０からＲＳメッセージを受信しなくても、ＲＡ生成部１３８は、ＭＮ１０の位置情報の登録に使用しているＢＩＤを含むＲＡメッセージを生成してＭＮ１０へ送信してもよい。この場合、ＲＡメッセージには、ＭＮ１０のプレフィックスとＢＩＤの両方が含まれる。なお、この場合のＢＩＤは、ＰＭＡ３１がＨＡ３２又はＡＡＡサーバ５０から取得したＢＩＤでもよいし、ＰＭＡ３１自身が生成し、代理ＢＵメッセージの送信に使用するＢＩＤでもよい。
なお、ＰＭＡ３１がＭＮ１０から受信したＲＳメッセージ内に、ＢＩＤが含まれていた場合には、そのＢＩＤは、ＰＭＡ３１が位置情報を登録する際に使用してほしいＢＩＤとしてＭＮ１０が通知したＢＩＤであると認識し、認証結果保持部１４２に保持するよう指示すると共に、そのＢＩＤが正しく保持されたことを示す情報を含むＲＡメッセージを生成してＭＮ１０へ送信する。この場合、ＭＮ１０が通知するＢＩＤは、ＭＮ１０がネットワーク３０にハンドオーバする以前に、ネットワーク２０に接続していた場合には、そこで使用していたＢＩＤとなる。一方、ＭＮ１０がネットワーク３０に接続する前に、どのネットワークにも接続していなかった場合、あるいはＢＩＤを使用していなかった場合には、ＭＮ１０が新たに生成したＢＩＤとなる。

なお、ＲＡメッセージに含まれるＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報は、ＤＨＣＰ reply メッセージ生成部１３７が生成するＤＨＣＰレスポンスメッセージの中に含まれていてもよい。特に、ＭＮ１０自身がアドレスを自動生成する場合は、ＤＨＣＰを使わないため、ネットワーク側はＲＡメッセージを接続ネットワーク情報の通知手段として使用できる。一方、ＭＮ１０がＤＨＣＰを用いてアドレスの割り当てを受ける場合には、ネットワーク側はＤＨＣＰレスポンスメッセージを情報の通知手段として使用できる。また、ＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報を示す手段としては、フラグだけでなく、ＲＡメッセージやＤＨＣＰレスポンスメッセージに付加可能なオプションとして示されてもよい。なお、ＰＭＡ３１がＭＮ１０へＢＩＤを通知する場合には、ＤＨＣＰレスポンスメッセージの中にＢＩＤを含めてもよい。

接続ネットワーク情報判断部１３９は、認証結果保持部１４２に保持されているＭＮ１０の認証結果を参照し、ＭＮ１０のアクセス認証結果がＯＫであり、かつMobile ＩＰｖ６（ホームエージェント３２）の利用がＯＫの場合は、ＩｓＰＭＩＰ情報をセットするべきと判断する。アクセス認証結果がＯＫであるということは、ネットワークベースの移動制御プロトコルが提供されているネットワーク３０をＭＮ１０が利用できることを意味し、Mobile ＩＰｖ６の利用がＯＫであるということは、ＭＮ１０自身がホームエージェント３２に対して位置情報の登録を行うことができることを意味する。

そのため、ＭＮ１０の Mobile ＩＰｖ６利用がＯＫでない場合には、ＭＮ１０はホームエージェント３２を使用する権利がないため、ＩｓＰＭＩＰ情報をセットせずに、ネットワーク３０を単なるアクセスネットワークとして見せるだけでよい。しかし、ＭＮ１０が Mobile ＩＰｖ６を利用できる場合には、ネットワーク３０では代理ノード３１がＭＮ１０の代わりに位置情報の登録を行うため、ＭＮ１０はネットワーク３０ではネットワークベースの移動制御プロトコルが提供されていることを知ることで、ネットワーク３０に接続しているＩＦに関しては、自分自身で位置情報の登録をする必要がないことを認識する必要がある。

また、ＭＮ１０は、ＩｓＰＭＩＰ情報によって、ネットワーク３０で取得したアドレスが自身のホームアドレスであることも認識する。仮にＩｓＰＭＩＰ情報がない場合、ＭＮ１０は接続しているネットワークを通常のアクセスネットワークと認識するため、取得したアドレスもケアオブアドレスであると認識してしまう。そして、自身のモビリティの効果を得るために、ホームエージェント３２、あるいは他のネットワークに存在するホームエージェントのアドレスの取得を行い、そのホームエージェントに対して、取得したアドレスをケアオブアドレスとして登録しようとしてしまう。このような動作を防ぐために、ネットワーク側はＩｓＰＭＩＰ情報を用いて、ネットワーク３０ではネットワークベースのプロトコルが提供されていることをＭＮ１０へ通知する。

また、接続ネットワーク情報判断部１３９は、ＭＮ１０の複数ケアオブアドレスの登録が許可されている場合には、ＢＩＤ Allocation 情報をセットするべきと判断する。複数ケアオブアドレスの登録が許可されているということは、ＭＮ１０は、他のインタフェースに関する位置情報をホームエージェントに対して登録することができることを意味する。そのため、ＭＮ１０が、複数ケアオブアドレスの登録が許可されていない場合には、ＭＮ１０はホームエージェント３２に対して他のインタフェースに関する位置情報を登録する権利がないため、代理ノード３１がＢＩＤを付加して位置情報を登録したかどうかを通知する必要はない。

しかし、複数ケアオブアドレスの登録が許可されている場合には、ＭＮ１０はＩＦ１１に関する位置情報を登録する際にＢＩＤを付加して登録することになるため、代理ノード３１が送信する位置情報にＢＩＤが付加されているかどうか、すなわち複数ケアオブアドレスの登録が許可されているか否かを事前に知る必要がある。仮にＭＮ１０は複数ケアオブアドレスの登録が許可されていない場合、代理ノード３１が登録した位置情報にＢＩＤが付加されないため、ＢＩＤが付加されたＩＦ１１に関する位置情報を追加でホームエージェント３２へ登録することができない。そのため、ネットワーク側はＢＩＤ Allocation 情報を用いて、ＭＮ１０へ複数ケアオブアドレスの登録が許可されているかどうか、ホームエージェント３２が複数ケアオブアドレスの登録に対応しているかどうか、さらには、代理ノード３１がＢＩＤを付加して位置情報を登録したかどうかを、ＭＮ１０へ通知する。

なお、Mobile ＩＰｖ６利用がＯＫである場合は、複数ケアオブアドレスの登録もＯＫであると判断するようにしてもよいし、また、アクセス認証結果がＯＫである場合には Mobile ＩＰｖ６利用もＯＫであると判断するようにしてもよい。またさらに、アクセス認証結果がＯＫである場合には、Mobile ＩＰｖ６利用も複数ケアオブアドレスの登録もＯＫであると判断するようにしてもよい。

ＤＨＣＰ request メッセージ処理部１４４は、ＭＮ１０から受信したＤＨＣＰリクエストメッセージに関する処理を行い、ＤＨＣＰ reply メッセージ生成部１３７に対して、ＭＮ１０のホームアドレスを含むＤＨＣＰレスポンスメッセージを生成するよう指示する。なお、代理ノードはＤＨＣＰサーバであってもよいし、ＤＨＣＰリレーエージェントであってもよい。ＭＮ１０に割り当てるべきアドレスは、ネットワーク３０が提供するＤＨＣＰサーバや、ＭＮ情報の管理サーバなどから取得するようにしてもよい。

図１５は本発明の第１の実施の形態におけるＨＡ３２の構成を示すブロック図である。ＨＡ３２はインタフェース１６１と、送信部１６２と、受信部１６３と、ＢＡメッセージ生成部１６４と、ＩＫＥレスポンスメッセージ生成部１６５と、認証リクエストメッセージ生成部１６６と、代理ＢＡ（Binding Acknowledgement）メッセージ生成部１６７と、ＩＫＥリクエストメッセージ処理部１６８と、代理ＢＵ（Binding Update）メッセージ処理部１６９と、ＭＮ管理情報保持部１７０と、認証レスポンスメッセージ処理部１７１とＢＵ（Binding Update）メッセージ処理部１７２とを有する。

以下では、ＨＡ３２が備える主要構成要素について説明する。ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０から受信したＩＫＥリクエストメッセージに関する処理を行い、認証リクエストメッセージ生成部１６６に対して、ＭＮ１０の認証、及びＢＩＤの割り当て・取得・通知を要求するための認証リクエストメッセージを生成するよう指示する。また、ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０からＩＫＥリクエストメッセージを受信した際、ＡＡＡサーバ５０に対するＭＮ１０の認証が不要な場合には、認証リクエストメッセージ生成部１６６に対して認証リクエストメッセージの生成を指示せずに、ＭＮ管理情報保持部１７０からＭＮ１０へ割り当てられているＢＩＤを取得して、そのＢＩＤを含むＩＫＥレスポンスメッセージを生成するようＩＫＥレスポンスメッセージ生成部１６５へ指示する。なお、ＭＮ１０の認証が必要な場合であったとしても、ＡＡＡサーバ５０からＢＩＤを取得するのではなく、ＭＮ管理情報保持部１７０からＭＮ１０へ割り当てられているＢＩＤを取得してもよい。

認証リクエストメッセージ生成部１６６は、ＡＡＡサーバ５０に対してＭＮ１０の認証を要求するための認証リクエストメッセージを生成する。メッセージには、ＭＮを特定する情報としてＭＮ１０のＩＤ、又はホームアドレスなどが含まれる。なお、認証リクエストメッセージには、明示的にＢＩＤの割り当て、及びＢＩＤの取得・通知を要求することを示す情報（フラグなど）を付加してもよい。また、認証リクエストメッセージ生成部１６６は、ＭＮ管理情報保持部１７０が保持しているＭＮ１０の情報（Binding Cache）からＭＮ１０へ割り当てられているＢＩＤを取得し、それを認証リクエストメッセージに付加してもよい。また、メッセージの中に明示的にＭＮ１０に割り当てられているＢＩＤを要求する情報（フラグなど）を含めてもよい。

ＭＮ管理情報保持部１７０は、ＭＮ１０に関する情報として、代理ＢＵメッセージ処理部１６９から渡されたＭＮ１０の位置情報や、認証レスポンスメッセージ処理部１７１から渡されたＭＮ１０の認証結果などを保持する。ＭＮ１０の位置情報には、ＰＭＡ３１によって付加されたＢＩＤが関連付けられており、ＩＫＥリクエストメッセージ処理部１６８及びＢＵメッセージ処理部１７２からＭＮ１０に割り当てられているＢＩＤの取得要求を受けた際にそのＢＩＤを渡す。

認証レスポンスメッセージ処理部１７１は、ＡＡＡサーバ５０から受信した認証レスポンスメッセージに関する処理を行い、メッセージに含まれるＭＮ１０の認証結果と、割り当てられているＢＩＤをＭＮ管理情報保持部１７０へ渡し、保持するよう指示する。また、ＩＫＥレスポンスメッセージ生成部１６５に対して、取得したＢＩＤを含むＩＫＥレスポンスメッセージを生成するよう指示する。ＩＫＥレスポンスメッセージ生成部１６５は、ＩＫＥリクエストメッセージ処理部１６８及び認証レスポンスメッセージ処理部１７１からの指示を受け、渡されたＭＮ１０に割り当てられているＢＩＤを含むＩＫＥレスポンスメッセージを生成し、それを送信部１６２に渡して送信するよう指示する。

代理ＢＵメッセージ処理部１６９は、ＰＭＡ３１から受信した代理ＢＵメッセージに関する処理を行い、メッセージに含まれるＭＮ１０の位置情報をＭＮ管理情報保持部１７０に渡して保持するよう指示する。代理ＢＵメッセージ処理部１６９はさらに、ＭＮ１０の位置情報の登録の結果を示す情報を含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部１６７に指示する。さらに、代理ＢＵメッセージ処理部１６９は、認証リクエストメッセージ生成部１６６に対して、ＰＭＡ３１の認証を要求するための認証リクエストメッセージを生成するよう指示する。

なお、ＰＭＡ３１がＢＩＤの割当を要求するメッセージとして認証リクエストメッセージではなく代理ＢＵメッセージを使用しているとき、代理ＢＵメッセージ処理部１６９は、受信した代理ＢＵメッセージにＢＩＤが含まれていないこと、あるいはＢＩＤ要求を示す情報を確認した場合、認証リクエストメッセージ生成部１６６に対して、ＰＭＡ３１の認証、及びＢＩＤの割り当て・取得・通知を要求するための認証リクエストメッセージを生成するよう指示する。また、代理ＢＵメッセージ処理部１６９は、ＰＭＡ３１から代理ＢＵメッセージを受信した際、ＡＡＡサーバ５０に対するＰＭＡ３１の認証が不要な場合には、認証リクエストメッセージ生成部１６６に対して認証リクエストメッセージの生成を指示せずに、置き換え対象となる位置情報に付加されているＢＩＤを取得，または自らＭＮ１０に割り当てるＢＩＤを生成し、そのＢＩＤを登録するＭＮ１０の位置情報と共に保持するようＭＮ管理情報保持部１７０に指示する。さらに、ＭＮ１０の位置情報の登録の結果を示す情報と共に、生成したＢＩＤを含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部１６７に指示する。なお、ＭＮ１０の認証が必要な場合であったとしても、ＡＡＡサーバ５０からＢＩＤを取得するのではなく、置き換え対象となる位置情報に付加されているＢＩＤを取得，または自らＭＮ１０に割り当てるＢＩＤを生成してもよい。ＭＮ１０の位置情報には、ＭＮ１０を特定する情報として、ＭＮ１０のＩＤ、ホームアドレス、ホームプレフィックスなど、及びＭＮ１０の接続先としてＰＭＡ３１のアドレスが含まれる。さらに、この位置情報には、ＭＮ１０によってこの位置情報に関連付けられたＢＩＤも含まれている。

代理ＢＡメッセージ生成部１６７は、代理ＢＵメッセージ処理部１６９からの指示を受け、ＭＮ１０に関する位置情報の登録の結果を示す情報を含む代理ＢＡメッセージを生成し、送信部１６２へ渡して送信するよう指示する。また、ＰＭＡ３１がＢＩＤの割当を要求するメッセージとして代理ＢＵメッセージを使用しているとき、代理ＢＡメッセージ生成部１６７は、代理ＢＵメッセージ処理部１６９が生成したＢＩＤを含む代理ＢＡメッセージを生成し、それを送信部１６２へ渡して送信するよう指示する。

ＢＵメッセージ処理部１７２は、ＭＮ１０からのＢＵメッセージに関する処理を行い、メッセージに含まれるＭＮ１０の位置情報をＭＮ管理情報保持部１７０に渡して保持するよう指示する。また、ＭＮ１０が、割り当てられているＢＩＤの取得を要求するメッセージとしてＩＫＥリクエストメッセージではなくＢＵメッセージを使用しているとき、ＢＵメッセージ処理部１７２は、受信したＢＵメッセージにＢＩＤが含まれていないこと、あるいはＢＩＤを要求する情報を確認した場合、ＭＮ管理情報保持部１７０から、置き換え対象となる位置情報に付加されているＢＩＤを取得、または自らＭＮ１０に割り当てるＢＩＤを生成して、そのＢＩＤを含むＢＡメッセージを生成するようＢＡメッセージ生成部１６４に対して指示する。この場合のＢＵメッセージには、ＢＩＤを通知するためのオプションの中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプションが含まれていて、このオプションがＢＩＤの取得を要求することを示す情報として機能してもよいし、又はモビリティヘッダの中や、ＢＩＤを通知するためのオプション、及び代替ＣｏＡオプションの中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。

ＢＡメッセージ生成部１６４は、ＢＵメッセージ処理部１７２からの指示を受け、ＭＮ１０の位置情報の登録の結果（登録完了）を示す情報を含むＢＡメッセージを生成し、それを送信部１６２へ渡して送信するよう指示する。また、ＭＮ１０が、割り当てられているＢＩＤを取得するメッセージとしてＩＫＥリクエストメッセージではなくＢＵメッセージを使用しているとき、ＢＡメッセージ生成部１６４は、ＢＵメッセージ処理部１７２がＭＮ管理情報保持部１７０から取得したＢＩＤを含むＢＡメッセージを生成し、それを送信部１６２へ渡して送信するよう指示する。

図５は本発明の第１の実施の形態におけるＡＡＡサーバ５０の構成を示す図である。ＡＡＡサーバ５０は、ＰＭＡがＭＮ１０の位置情報を登録する際に使用するＢＩＤを割り当てる管理サーバとして機能する。ＡＡＡサーバ５０はネットワークとのインタフェース１５１と、送信部１５２と、受信部１５３と、認証レスポンスメッセージ生成部１５４と、認証判定部１５５と、認証リクエストメッセージ処理部１５６と、ＭＮ情報保持部１５７とＢＩＤ割り当て部１５８を有する。認証リクエストメッセージ処理部１５６は、代理ノード３１から受信したＭＮ１０のアクセス認証要求、及びＨＡ３２から受信した代理ノード３１の認証要求に関する認証リクエストメッセージの処理を行い、認証判定部１５５に対して認証の要求元であるＭＮ１０の認証を行うよう指示する。

認証判定部１５５は、認証リクエストメッセージ処理部１５６からの指示を受け、ＭＮ情報保持部１５７を参照し、ＭＮ１０の認証を行う。ＭＮ１０に対しネットワーク３０の利用が許可されているかどうか、Mobile ＩＰｖ６（ホームエージェント）の利用が許可されているかどうか、複数ケアオブアドレスの登録が 許可されているかどうか、などの点での認証が行われる。また、ＭＮ１０に対し複数ケアオブアドレスの登録が許可されている場合、ＩＦ２２の位置情報を登録する際に使用するＢＩＤを割り当てるために、ＢＩＤ割り当て部１５８からＭＮ１０に割り当てるＢＩＤを取得し、認証結果と共にＢＩＤを含む認証レスポンスメッセージを生成するよう認証レスポンスメッセージ生成部１５４に対して指示する。

なお、認証リクエストメッセージ処理部１５６が受信した代理ノード３１からの認証リクエストメッセージの中にＢＩＤが含まれている場合には、ＭＮ１０に割り当てたＢＩＤとして保持するようＭＮ情報保持部１５７に指示し、認証結果と共にそのＢＩＤの使用可能及び登録完了を示す認証レスポンスメッセージを生成するよう認証レスポンスメッセージ生成部１５４に対して指示する。また、受信したＨＡ３２からの認証リクエストメッセージの中にＢＩＤが含まれている場合も同様にＭＮ１０に割り当てたＢＩＤとして保持するようＭＮ情報保持部１５７に指示し、認証結果と共にそのＢＩＤの使用可能及び登録完了を示す認証レスポンスメッセージを生成するよう認証レスポンスメッセージ生成部１５４に対して指示する。

ＢＩＤ割り当て部１５８は、認証判定部１５５から指示を受け、認証対象であるＭＮ１０に対して割り当てるべきＢＩＤを生成・取得する。その際に、ＭＮ情報保持部１５７を参照し、既に割り当て済みのＢＩＤがある場合にはそれを認証判定部１５５へ返し、割り当て済みのＢＩＤがない場合には、新たに生成したＢＩＤを返し、それをＭＮ情報保持部１５７へ保持するよう指示する。認証レスポンスメッセージ生成部１５４は、認証判定部１５５からの指示を受け、通知されたＭＮ１０の認証結果と割り当てられたＢＩＤを含む認証レスポンスメッセージを生成し、送信部１５２に対して送信するよう指示する。なお、受信した認証リクエストメッセージの中に代理ノード３１が生成したＢＩＤが含まれている場合には、使用可能及び登録完了を示す認証レスポンスメッセージを生成し、送信部１５２に対して送信するよう指示する。
本発明の第１の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されているネットワークから、提供されていないネットワークへ移動した場合でも、移動前に代理ノードによって登録された位置情報を更新するために、代理ノードによって登録された位置情報に付加されているＢＩＤを使って、新たな位置情報の登録が可能となる。

＜第２の実施の形態＞
第２の実施の形態のネットワーク構成は第１の実施の形態と同じである。各エンティティの構成は第１の実施の形態とほぼ同じあり、第１の実施の形態との違いは、図６に示すようにＲＡ／ＤＨＣＰレスポンスに含まれる情報がＢＩＤ Allocation 情報ではなく、ＢＩＤそのものである点である。よってＭＮ１０はハンドオーバ後のＩＫＥｖ２でＢＩＤを要求しない。

図６に示す通信シーケンスについて説明する。
（１）アクセス及びモビリティ認証
第１の実施の形態と同じであるので、説明を省略する。
（２）ＰＭＡによる位置登録、アドレス割り当て
「Proxy ＢＵ」、「ＡＡＡ Query」、「ＡＡＡ Reply」、「Proxy ＢＡ」、「ＲＡ」、「ＤＨＣＰ request」は第１の実施の形態と同じであるので、説明を省略する。
・ＰＭＡ３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信してＨＡ３１のアドレス（ＨＡ address）と、ＩｓＰＭＩＰ情報と、ＢＩＤ２（第１の実施の形態では、ＢＩＤAllocＯＫ）を通知する。

ＭＮ１０はＰＭＡ３１からのＤＨＣＰ reply を受信すると、ＩｓＰＭＩＰ情報により以下を認識する。
・割り当てられたアドレスがＨｏＡである。
また、ＭＮ１０はＢＩＤ２により以下を認識する。
・他のＩＦのＣｏＡを登録できる。

＜ネットワーク２０にハンドオーバ＞
ＭＮ１０はネットワーク２０にハンドオーバすると、ＩｓＰＭＩＰ情報により以下を認識する。
・ＨｏＡ取得不要。

（３）ＩＫＥｖ２
・ＭＮ１０はネットワーク２０にハンドオーバすると、ＨＡ３２に対して、ＩＫＥ＿ＡＵＴＨを送信してＨｏＡを通知する（第１の実施の形態では、ＢＩＤを要求）。
・ＨＡ３２がＭＮ１０からのＩＫＥ＿ＡＵＴＨを受信して、ＡＡＡサーバ５０に対してＡＡＡ request を 送信してＭＮ認証要求とＨｏＡ（第１の実施の形態ではＢＩＤ）を送信し、ＡＡＡサーバ５０がこのＡＡＡ request を受信して、ＨＡ３２に対してＡＡＡ reply を送信して認証ＯＫを通知することにより、Mobile ＩＰｖ６初期化プロセスを実行する（第１の実施の形態ではＢＩＤを通知）。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してＣＦＧ＿ＲＥＰＬＹ を送信してＯＫ（第１の実施の形態ではＢＩＤ２）を通知する。
（４）位置登録
第１の実施の形態と同じであるので、説明を省略する。

＜第３の実施の形態＞
第３の実施の形態のネットワーク構成は第１の実施の形態と同じである。第３の実施の形態の第１の実施の形態との違いは、図７に示すようにＩｓＰＭＩＰ情報とＢＩＤがアクセス認証完了通知メッセージに含まれている点である。よって、第２の実施の形態と同じく、ＭＮ１０はハンドオーバ後のＩＫＥｖ２でＢＩＤを要求しない。

図７に示す通信シーケンスについて説明する。
（１）アクセス及びモビリティ認証
「アクセス認証要求」、「ＡＡＡ request」、「ＡＡＡ reply」は、第１の実施の形態と同じであり、よって、ＡＡＡサーバ５０はＰＭＡ３１からのＡＡＡ request（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、ＢＩＤ２を生成し、ＢＩＤ２を割り当てたＭＮ１０とＰＭＡ３１を記憶して、ＰＭＡ３１に対して、ＡＡＡ reply で認証ＯＫ、Mobile ＩＰｖ６ ＯＫ、ＢＩＤ２を通知する。
・第３の実施の形態では、ＰＭＡ３１はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してアクセス認証完了メッセージを送信してＢＩＤ２とＩｓＰＭＩＰ情報を通知する。

（２）ＰＭＡによる位置登録、アドレス割り当て
「Proxy ＢＵ」、「ＡＡＡ Query」、「ＡＡＡ Reply」、「Proxy ＢＡ」、「ＲＡ」、「ＤＨＣＰ request」は、第１の実施の形態と同じである。
・第３の実施の形態では、ＰＭＡ３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信してＨＡ３２のアドレス（ＨＡ address）を通知し、ここでは、ＩｓＰＭＩＰ情報と、ＢＩＤ割り当てＯＫ（ＢＩＤAllocＯＫ）を通知しない。以下の処理は、第２の実施の形態と同じであるので、説明を省略する。

図８は第３の実施の形態におけるＭＮ１０の構成を示し、図３に示すＤＨＣＰリクエストメッセージ生成部１０３が省略されている他は、同じ構成である。図９は第３の実施の形態における代理ノードの構成を示し、アクセス認証結果通知メッセージ生成部１３５ａとＤＨＣＰ reply メッセージ生成部１３７ａの処理が図４と異なる。なお、本発明の第１〜第３の実施の形態においては、ＡＡＡサーバ５０がＢＩＤを生成し、それを認証レスポンスメッセージで代理ノード３１へ通知しているが、別の方法として、代理ノード３１自身がＢＩＤを生成し、そのＢＩＤを使用することをＡＡＡサーバへ通知してもよい。その場合、認証リクエストメッセージ生成部１３４は、ＭＮ１０の位置情報登録の際に使用するＢＩＤを生成し、それを含む認証リクエストメッセージを生成してＡＡＡサーバへ送信する。また、この場合、ＭＮ認証プロセスではなく、代理ノード３１による位置登録及びＰＭＡ認証プロセスの中でＢＩＤを通知してもよい。その場合、代理ＢＵメッセージ生成部１３６は、ＭＮ１０に関する位置情報を登録するための代理ＢＵメッセージを生成する際にＢＩＤを生成し、メッセージに含めてＨＡ３２へ送信する。

この代理ＢＵメッセージを受けたＨＡ３２は、メッセージに含まれているＢＩＤをＡＡＡ Queryの中に含めてＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤを付加してＭＮ１０の位置情報を保持する。なお、ここでのＨＡ３２からＡＡＡサーバ５０へのＢＩＤの通知は省略してもよい。その場合、ＨＡ３２はＰＭＡ３１からの代理ＢＵメッセージに含まれるＢＩＤをバインディングキャッシュに保持し、ＭＮ１０からのＢＩＤ通知要求を受信した場合に、そのＢＩＤを通知する。また、ＭＮ１０はＨＡ３２に対して行うＩＫＥの中で、ＢＩＤを要求して、ＰＭＡ３１によって使用されたＢＩＤを取得する。

さらに別の方法として、ＨＡ３２がＢＩＤを生成し、そのＢＩＤを使用することをＡＡＡサーバへ通知してもよい。その場合、ＰＭＡ３１から代理ＢＵメッセージを受信したＨＡ３２は、ＰＭＡ３１から登録の要求を受けたＭＮ１０の位置情報に付加するＢＩＤを生成し、それを含むＡＡＡ QueryをＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤを登録されるＭＮ１０のエントリに付加して保持する。また、そのＢＩＤを代理ＢＡメッセージの中に含めてＰＭＡ３１へ送信する。ＢＩＤを含む代理ＢＡメッセージを受信したＰＭＡ３１は、以降ＭＮ１０の代理ＢＵメッセージを送信する際には、そのＢＩＤを付加して送信する。

このように、ＡＡＡサーバ５０とＨＡ３２は、ＢＩＤを生成して通知するノード、あるいは、ＢＩＤの通知を受けるノードとして機能するノードになり得るため、ネットワーク内のエンティティとして、これらの機能をすべて持つ一体化した管理ノードとみなすことができる。

また、本発明の第１〜第３の実施の形態では、ネットワーク３０からネットワーク２０へハンドオーバして接続するネットワークが変わることで、ＭＮ１０がネットワークベースのプロトコルを使用している状態から使用しない状態へ移行するケースについて記述しているが、別のケースとして、ＭＮ１０のＩＦ２２がネットワーク３０に接続しているときに、ＭＮ自身の判断による切り替え、又はネットワーク側の判断による切り替えで、ネットワークベースのプロトコルを使用している状態から使用しない状態へ切り替わるケースにも本発明の手法を適用することができる。

また、ＭＮ１０が、ハンドオーバせずにネットワークベースのプロトコルを使用している状態（ネットワーク２０へハンドオーバする前や、ネットワーク４０でネットワークベースのプロトコルが提供されているが、ＩＦ１１はハンドオーバしないとき）であっても、ネットワーク３０、及びネットワーク４０において、ホームエージェントや通信相手へフロー制御情報を登録するためにＢＩＤを必要とする場合などに、本発明の手法を使用してＢＩＤを取得することもできる。
また、不図示ではあるが、本発明の手法を使用して取得したＢＩＤは、位置情報の登録だけでなく、フロー制御情報を登録する際にも利用可能である。

＜第４の実施の形態＞
図１０は本発明の第４の実施の形態におけるネットワークの構成を示す図であり、第１の実施の形態との違いは、ハンドオーバが、ネットワーク２０からネットワーク３０へ行われる点である。各エンティティの構成や処理は第１の実施の形態と同じであるが、図１１に示すように第１の実施の形態では移動前に行っていた処理が第４の実施の形態では移動後に行われ、第１の実施の形態では移動後に行っていた処理が第４の実施の形態では移動前に行われるという点が異なる。

なお、図１０では、各ネットワークを提供するオペレータについては図示していないが、第１の実施の形態における図１と同様に、各ネットワークが異なるオペ レータによって提供されていてもよい。また、第１の実施の形態における図１２と同様に、ネットワーク４０とネットワーク３０は、同一のオペレータＡによって提供されていてもよく、その場合、ホームエージェント３２はネットワーク２０とネットワーク３０の両方にとって共通のホームエージェントとなる。オペレータＡが提供するネットワーク４０は一例として、セルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。オペレータＢのネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。

さらに、第１の実施の形態における図１３と同様に、ネットワーク２０、３０、４０のすべてが同一のオペレータＡによって提供されていてもよく、その場合、ホームエージェント３２はネットワーク２０、３０、４０のすべてにとって共通のホームエージェントとなる。ネットワーク４０は一例としてセルラネットワークであり、ネットワークベースのプロトコルが提供されているネットワーク３０は一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。ネットワークベースのプロトコルが提供されていないネットワーク２０も同様に一例として、ワイヤレスＬＡＮ（802.11a/b/g/n）や、ＷｉＭＡＸ、Bluetooth（登録商標）などのネットワークである。なお、上記のネットワーク構成において、ネットワーク２０はネットワークベースのプロトコルが提供されていないネットワークとしているが、ネットワークベースのプロトコルが提供されているがＭＮ１０はそれを使用していないという場合でもよい。すなわち本発明の第４の実施の形態におけるＭＮは、ネットワーク３０ではネットワークベースのプロトコルを使用し、ネットワーク２０では使用していない。

また、本発明の第４の実施の形態では、ネットワーク２０からネットワーク３０へハンドオーバして接続するネットワークが変わることで、ＭＮ１０がネットワークベースのプロトコルを使用していない状態から使用する状態へ移行するケースについて記述しているが、別のケースとして、ＭＮ１０のＩＦ２２がネットワーク２０に接続しているときに、ＭＮ自身の判断による切り替え、又はネットワーク側の判断による切り替えで、ネットワークベースのプロトコルを使用していない状態から使用する状態へ切り替わるケースにも本発明の手法を適用することができる。

図１１に示す通信シーケンスについて説明する。
・ＭＮ１０はネットワーク２０で初期起動すると、アクセス認証を行う。
（１）ＨＡアドレス取得（Split シナリオ）
・ＭＮ１０は、ＤＮＳなどを用いて、ＨＡ３２のアドレスの取得を行う。
（２）ＩＫＥｖ２
・ＭＮ１０はＨＡ３２に対して、ＩＫＥ＿ＡＵＴＨを送信してＨｏＡとＢＩＤを要求する。
・ＨＡ３２がＭＮ１０からのＩＫＥ＿ＡＵＴＨを受信して、ＡＡＡサーバ５０に対してＡＡＡ request を送信してＭＮ認証とＢＩＤを要求し、ＡＡＡサーバ５０がこのＡＡＡ request を受信して、ＢＩＤ２を生成して、そのＢＩＤ２を割り当てたＭＮ１０を記憶し、ＨＡ３２に対してＡＡＡ reply を送信して認証ＯＫとＢＩＤ２を通知することにより、初期化プロセスを実行する。このとき、ＡＡＡサーバ５０、ＨＡ３２のいずれかがＢＩＤ２を割り当ててもよい。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してＣＦＧ＿ＲＥＰＬＹ を送信してＨｏＡとＢＩＤ２を通知する。

（３）位置登録
第１の実施の形態の（４）位置登録と同じである。すなわち、
・ＭＮ１０はＨＡ３２からのＣＦＧ＿ＲＥＰＬＹを受信すると、ＨＡ３２に対してＢＵを送信して Addr2 とＢＩＤ２を登録する。
・ＨＡ３２はＭＮ１０からのＢＵを受信すると、ＭＮ１０に対してＢＡを送信して位置登録ＯＫを通知する。

ＭＮ１０がネットワーク２０からネットワーク３０にハンドオーバすると、以下の処理が行われる。
（４）アクセス及びモビリティ認証
・ＭＮ１０はネットワーク３０にハンドオーバすると、ＰＭＡ３１に対してアクセス認証要求を送信する。
・ＰＭＡ３１がＭＮ１０からのアクセス認証要求を受信してＡＡＡサーバ５０に対してＡＡＡ request でＭＮ認証要求を送信し、ＡＡＡサーバ５０がＰＭＡ３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信してＭＮに対するＢＩＤを選択し、ＰＭＡ３１に対してＡＡＡ reply で認証ＯＫ、ＢＩＤ２を通知することにより、ＭＮ認証プロセスを実行する。
・ＰＭＡ３１はＡＡＡサーバ５０からのＡＡＡ reply を受信すると、ＭＮ１０に対してアクセス認証完了メッセージでＭＩＰ処理不要を示すＩｓＰＭＩＰ情報とＢＩＤ Allocation 情報を通知する。

なお、アクセス認証後に受信するＲＡや、ＤＨＣＰ reply にＩｓＰＭＩＰ情報を含めてもよい。ＭＮ１０がＰＭＡ３１に対して送信するアクセス認証要求メッセージは特に新しい情報を持たないが、ＰＭＡ３１が送信する認証リクエストメッセージのトリガとなり、さらにその後のＡＡＡサーバからのＢＩＤ取得するメッセージのトリガでもある。このためＭＮ１０およびＰＭＡ３１にとっては、ＢＩＤの取得を要求するためのメッセージとみなすことができる。なお、アクセス認証要求メッセージの中に明示的にＢＩＤの取得を要求する情報を含めてもよい。

（５）ＰＭＡによる位置登録
第１の実施の形態の（２）ＰＭＡによる位置登録、と同じである。また、アドレス登録も第１の実施の形態と同じである。
なお、本発明の第４の実施の形態においては、ＡＡＡサーバ５０がＢＩＤを生成し、それを認証レスポンスメッセージで代理ノード３１へ通知しているが、別の方法として、ＨＡ３２がＢＩＤを生成し、そのＢＩＤを使用することをＡＡＡサーバへ通知してもよい。その場合、ＭＮ１０からからＩＫＥリクエストメッセージを受信したＨＡ３２は、ＭＮ１０が位置情報を登録する際に付加するＢＩＤを生成し、それを含むＡＡＡ QueryをＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤをＩＫＥレスポンスメッセージの中に含めてＭＮ１０へ送信する。ＢＩＤを含むＩＫＥレスポンスメッセージを受信したＭＮ１０は、代理ＢＵメッセージを送信する際には、そのＢＩＤを付加して送信する。

さらに別の方法として、ＭＮ１０自身がＢＩＤを生成し、そのＢＩＤを使用することをＨＡ３２、及びＡＡＡサーバ５０へ通知してもよい。その場合、ＩＫＥリクエストメッセージ生成部１０５は、自身の位置情報登録の際に使用するＢＩＤを生成し、それを含むＩＫＥリクエストメッセージを生成してＨＡ３２へ送信する。また、この場合、ＭＮ認証プロセスではなく、ＭＮ１０による位置登録でＢＩＤを通知してもよい。その場合、ＢＵメッセージ生成部１０４は、位置情報を登録するためのＢＵメッセージを生成する際にＢＩＤを生成し、メッセージに含めてＨＡ３２へ送信する。このＢＵメッセージを受けたＨＡ３２は、メッセージに含まれているＢＩＤをＡＡＡ Queryの中に含めてＡＡＡサーバ５０へ送信し、ＡＡＡサーバ５０からのＡＡＡ replyが認証ＯＫである場合には、そのＢＩＤを付加してＭＮ１０の位置情報を保持する。なお、ここでのＨＡ３２からＡＡＡサーバ５０へのＢＩＤの通知は省略してもよい。その場合、ＨＡ３２はＰＭＡ３１からの代理ＢＵメッセージに含まれるＢＩＤをバインディングキャッシュに保持し、ＭＮ１０からのＢＩＤ通知要求を受信した場合に、そのＢＩＤを通知する。また、ＰＭＡ３１はＨＡ３２に対して行うＩＫＥ、又は代理ＢＵの中で、ＢＩＤを要求して、ＭＮ１０によって使用されたＢＩＤを取得する。

また、ＭＮ１０がネットワーク３０へハンドオーバした後、ＰＭＡ３１がＭＮ１０の位置情報登録の際に使用するべきＢＩＤを取得する方法として、ＭＮ１０の位置情報を含む代理ＢＵメッセージでＢＩＤを要求してもよい。この場合、ＰＭＡ３１からの代理ＢＵメッセージを受信したＨＡ３２は、ＭＮ１０に割り当てられたＢＩＤを要求するためにＡＡＡサーバ５０に対してＡＡＡ Queryを送信し、ＡＡＡ Replyの中に含まれているＢＩＤを登録されるＭＮ１０のエントリに付加して保持する。さらに、ＰＭＡ３１へ送信する代理ＢＡメッセージにそのＢＩＤを含めて送信する。ＰＭＡ３１は、以降代理ＢＵメッセージを送信する際には、そのＢＩＤを付加してＨＡ３２へ送信する。また、ＰＭＡ３１から代理ＢＵメッセージを受信したＨＡ３２は、ＡＡＡサーバ５０に問い合わせるのではなく、自身が保持するＢＣＥから、ＭＮ１０に割り当てられているＢＩＤを取得して、代理ＢＡメッセージでそのＢＩＤを通知してもよい。

このように、ＡＡＡサーバ５０とＨＡ３２は、ＢＩＤを生成して通知するノード、あるいは、ＢＩＤの通知を受けるノード、さらには、ＢＩＤを選択して通知するノードとして機能するノードになり得るため、ネットワーク内のエンティティとして、これらの機能をすべて持つ一体化した管理ノードとみなすことができる。
本発明の第４の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されていないネットワークから、提供されているネットワークへ移動した場合でも、代理ノードが、移動前にＭＮ１０が登録した位置情報を更新するために、ＭＮ１０によって登録された位置情報に付加されているＢＩＤを使って、新たな位置情報の登録が可能となる。

＜第５の実施の形態＞
図１６、図１７、図１８は第５の実施の形態のネットワークの構成を示すブロック図であり、それぞれ図１、図１２、図１３の変形例である。図１、図１２、図１３では、ＭＮ１０のＩＦ１１が通信を行っているネットワーク４０は、ネットワークベースの移動制御プロトコル（ネットワークベースプロトコル）が提供されていないのに対し、図１６、図１７、図１８におけるネットワーク４０ａは、ネットワークベースプロトコル（ＰＭＩＰ）が提供されていて、代理ノード３１ａが存在する。図１６、図１７、図１８における他の構成は、図１、図１２、図１３と同じである。

このようなネットワーク構成において、移動前のＭＮ１０のＩＦ１１、ＩＦ２２がそれぞれ、ネットワークベースプロトコルのネットワーク４０ａ、３０と通信を行っている状態から、ＭＮ１０が移動してＩＦ２２のみが、ネットワークベースプロトコルが提供されていないネットワーク２０にハンドオーバして、ＢＩＤをホームエージェント３２に要求した場合、ホームエージェント３２はＩＦ１１、ＩＦ２２のどちらがハンドオーバしたか知得できず、実際にハンドオーバしたＩＦ２２のＢＩＤをＭＮ１０に転送できないという問題点がある。そこで、第５の実施の形態では、ホームエージェント３２がＩＦ１１、ＩＦ１２の各インタフェースを特定する情報であるＭＡＣアドレスに対応してそれぞれのＢＩＤを記憶して、どのＢＩＤの要求かを判断している。

第５の実施の形態におけるＭＮ１０の構成は、第１の実施の形態における図３と同じであるが、図１９に示すようにＩＫＥリクエストメッセージ生成部１０５の判断処理が異なる。図１９におけるステップＳ１〜Ｓ９は、第１の実施の形態における図１４と同じである。ステップＳ９において移動前ネットワークでネットワークベースプロトコルを使用していたか否かを判断して、使用していた場合には、ステップＳ２０において別ＩＦ（ハンドオーバしていないＩＦ１１）も、ハンドオーバしたＩＦ１２と同じドメインのネットワークに接続し、ネットワークベースプロトコルを使用しているかどうかを判断する。そして、同じドメインネットワークに接続し、ネットワークベースプロトコルを使用していた場合に、ハンドオーバしたＩＦ２２のＭＡＣアドレスを接続ネットワーク情報保持部１１４から取得し、この取得したＩＦ２２のＭＡＣアドレスを使用して移動前ネットワークから接続中に使用されていたＢＩＤを取得し（ステップＳ２１）、次いでこの取得したＢＩＤを含むＢＵを送信する（ステップＳ２２）。同じＨＡ３２を使用していない場合には、ＢＵを送信する（ステップＳ２２）。また、ステップＳ９で、移動前ネットワークでネットワークベースプロトコルを使用していなかった場合には、移動前ネットワークから、新たなＢＩＤを取得し（ステップＳ２３）、次いでこのＢＩＤを含むＢＵを送信する（ステップＳ２２）。なお、ステップＳ２３において、移動前ネットワークで自ら移動制御を行っていた場合には、移動前ネットワークで使用していたＢＩＤを引き続き使用する。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用する場合、Binding Updateメッセージ生成部１０４が、図１９に示す処理を行い、ＭＡＣアドレスを含むＢＵメッセージを送信するべきか否かを判断する。

第５の実施の形態における代理ノード３１及び３１ａは、第１の実施の形態における図４と同じであるが、以下のブロックの処理が異なる。まず、認証結果保持部１４２は、ＭＮ１０の認証結果に関する情報とともに、ＭＮ１０に割り当てられたＢＩＤとＭＡＣアドレスを保持する。ＢＵＬが認証結果保持部１４２として機能してもよく、その場合、認証結果保持部１４２はＭＮ１０がＨＡやＣＮに登録している位置情報も保持する。認証リクエストメッセージ生成部１３４は、ＢＩＤの取得・通知を要求するメッセージとして認証リクエストメッセージを生成する際に、接続ネットワーク情報判断部１３９からＭＮ１０のＭＡＣアドレスを取得し、取得したＭＡＣアドレスをセットした認証リクエストメッセージを生成する。認証レスポンスメッセージ処理部１４１は、認証結果保持部１４２に対して、取得したＭＮ１０のＢＩＤと対応するＩＦのＭＡＣアドレスを保持するよう指示する。また、代理ＢＵメッセージ生成部１３６に対して、ＭＮ１０の位置情報を登録するための代理ＢＵメッセージを生成するよう指示する。代理ＢＵメッセージ生成部１３６は、認証レスポンスメッセージ処理部１４１の指示を受け、認証結果保持部１４２から、ＭＮ１０に割り当てられたＢＩＤとＭＡＣアドレスを取得し、それらを含む代理ＢＵメッセージを生成する。

第５の実施の形態におけるＡＡＡサーバ５０は、第１の実施の形態における図５と同じであるが、以下のブロックの処理が異なる。ＢＩＤ割り当て部１５８は、ＭＮ１０のＭＡＣアドレスに対して割り当てるＢＩＤを生成する。ＭＮ情報保持部１５７を参照し、既に通知されたＭＮ１０のＭＡＣアドレスに対して割り当て済みのＢＩＤがある場合には、それを認証判定部１５５に返す。認証リクエストメッセージ処理部１５６は第１の実施の形態と異なり、認証リクエストメッセージには ＭＡＣアドレスが含まれているので、認証判定部１５５に対して、ＭＮ１０の認証を行うよう指示すると共に、メッセージに含まれているＭＡＣアドレスを渡す。認証判定部１５５は、認証リクエストメッセージ処理部１５６から渡されたＭＮ１０のＭＡＣアドレスをＢＩＤ割り当て部１５８へ渡し、このＭＡＣアドレスに対してＢＩＤを割り当てるよう指示する。ＭＮ情報保持部１５７はＭＮ１０のＭＡＣアドレスも一緒に保持する。

第５の実施の形態におけるＨＡ３２は、第１の実施の形態における図１５と同じであるが、以下のブロックの処理が異なる。ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０から受信したＩＫＥリクエストメッセージに関する処理を行い、メッセージに含まれているＭＮに関する情報の１つとして、ＭＮ１０のＭＡＣアドレスを取得し、認証リクエストメッセージ生成部１６６にそのＭＡＣアドレスを渡して、ＭＮ１０の認証を要求するための認証リクエストメッセージを生成するよう指示する。この場合、この認証リクエストメッセージは、ＭＮ１０に割り当てられているＢＩＤで、かつＭＡＣアドレスに対応するＢＩＤを要求するメッセージとなる。また、ＩＫＥリクエストメッセージ処理部１６８は、ＭＮ１０からＩＫＥリクエストメッセージを受信した際、ＡＡＡサーバ５０に対するＭＮ１０の認証が不要な場合には、認証リクエストメッセージ生成部１６６に対して認証リクエストメッセージの生成を指示せずに、ＭＮ管理情報保持部１７０から、ＭＮ１０のＭＡＣアドレスに対応するＢＩＤを取得して、そのＢＩＤを含むＩＫＥレスポンスメッセージを生成するようＩＫＥレスポンスメッセージ生成部１６５へ指示する。なお、ＭＮ１０の認証が必要な場合であったとしても、ＡＡＡサーバ５０からＢＩＤを取得するのではなく、ＭＮ管理情報保持部１７０からＭＮ１０へ割り当てられているＢＩＤを取得してもよい。なお、ＢＩＤの取得・通知を要求するメッセージとして、ＢＵメッセージを使用する場合、ＢＡメッセージ生成部１１２が、ＩＫＥリクエストメッセージ処理部１６８と同様の処理を行う。

ＩＫＥレスポンスメッセージ生成部１６５は、ＩＫＥリクエストメッセージ処理部１６８、及び認証レスポンスメッセージ処理部１７１からの指示を受け、渡されたＭＮ１０に割り当てられているＢＩＤを含むＩＫＥレスポンスメッセージを生成し、それを送信部１６２に渡して送信するよう指示する。なお、ＭＮ１０のＭＡＣアドレスを含んでいてもよい。ＭＮ管理情報保持部１７０は、ＭＮ１０に関する情報として、代理ＢＵメッセージ処理部１６９から渡されたＭＮ１０の位置情報や、認証レスポンスメッセージ処理部１７１から渡されたＭＮ１０の認証結果などを保持する。ＭＮ１０の位置情報には、代理ノード３１、３１ａによって付加されたＢＩＤとＭＡＣアドレスが関連付けられており、ＩＫＥリクエストメッセージ処理部１６８、及びＢＵメッセージ処理部１７２からＭＮ１０に割り当てられているＢＩＤの取得要求を受けた際に、そのＢＩＤを渡す。

＜具体例＞
図２０は第５の実施の形態の具体例を示す。ＭＮ１６０１のＩＦ１１、ＩＦ１２はそれぞれ、移動前には実線で示すように、ＭＮ１６０１の代理ノードであるＭＡＧ（Mobile Access Gateway）１３０１（及びリンク１３５１）、ＭＡＧ１４０１（及びリンク１４５１）を経由して、ネットワークベースプロトコルのローカルネットワーク１００１に接続されている。そして、ＭＡＧ１３０１、１４０１の両方がＭＮ１６０１の現在位置をＬＭＡ（Local Mobility Anchor）１２０１に登録している。ＬＭＡ１２０１はモバイルＩＰ
が使用されているときにＭＮ１６０１のホームエージェントとして動作する。以下では、ＬＭＡの方を用いて説明する。

次に破線で示すように、ＭＮ１６０１のＩＦ１１はそのままで、ＩＦ１２のみがローカルネットワーク１００１の外に移動して、フォリンネットワーク１１０１内のＡＲ（アクセスルータ）１５０１（及びリンク１５５１）に接続すると、ＭＮ１６０１はモバイルＩＰの動作を開始して、ＡＲ１５０１から取得した新しいケアオブアドレス（ＣｏＡ）をＬＭＡ１２０１に登録しようとする。このとき、ＢＩＤ割り当てに関しては、ＭＮ１６０１はＢＩＤ要求メッセージをモビリティ管理ノードに送信して、移動前のＩＦ１２に対して使用されていたＢＩＤを要求する。ここでモビリティ管理ノードとは、ＬＭＡ１２０１、ＡＡＡサーバ５０、パケットデータゲートウェイ（ＰＤＧ）、ＭＮ１６０１のＢＩＤを知得している他のネットワークノードなどである。モビリティ管理ノードがＬＭＡ１２０１であると仮定すると、ＬＭＡ１２０１はＭＮ１６０１からのＢＩＤ要求メッセージを受信すると、ＭＮ１６０１のＢＩＤエントリが２つあることを知得するので、第１〜第４の実施の形態ではどのＢＩＤを応答していいかわからない。

そこで、この具体例では、ＭＡＧ１３０１、１４０１は、ＬＭＡ１２０１に送信する代理ＢＵ内にＭＮ１６０１のリンク識別子を埋め込む。そしてさらに、ＭＮ１６０１は、移動したＩＦ１２に関してのＢＩＤ要求メッセージの中に、ＩＦ１２に関するリンク識別子を含めて送信する。このリンク識別子により、ＬＭＡ１２０１は簡単に、ＭＮ１６０１がどの代理ＢＵで使われているＢＩＤを要求しているかを決定して、ＭＡＧ１３０１、１４０１に問い合わせることなくＢＩＤを通知することができる。このリンク識別子は、例えばＭＮ１６０１のＩＦ１１、ＩＦ１２のリンクレイヤアドレスであり、ＭＮ１６０１がＷｉＦｉやイーサネット（登録商標）のようなＩＥＥＥ８０２に対応するインタフェースを使用している場合にはＩＦ１１、ＩＦ１２のＭＡＣアドレスである。

ここで、ＭＡＧ１３０１、１４０１は種々の方法で、ＭＮ１６０１のＩＦ１１、ＩＦ１２のリンクレイヤアドレスを取得することができる。例えばＭＡＧ１３０１、１４０１はＭＮ１６０１との送信中に、ＩＥＥＥ８０２．１１、ＩＥＥＥ８０２．１６のように下位の層の通信プロトコルでリンクレイヤアドレスを取得することができる。ＭＡＣアドレスはＭＮ１６０１から到着するパケットの送信元アドレスのフィールドに記述されている。他の方法としては、ＭＮ１６０１が最初にＭＡＧ１３０１、１４０１に接続したときのアソシエーションフェーズか認証フェーズの間にＭＡＣアドレスにアクセスすることができる。また、他の方法として、ＩＰレベルの近隣探索（Neighbor Discovery）を実行することにより取得することができる。また、他の方法として、ネットワークポリシーを有するか、認証を行うサーバに問い合わせてもよい。以下では、リンク識別子の代わりにＭＡＣアドレスを用いて説明してもよい。

図２１は、ＭＮ１６０１のＩＦ１１、ＩＦ１２がともにローカルネットワーク１００１に接続しているときにＬＭＡ１２０１が保持するＭＮ１６０１のバインディングキャッシュ・エントリ（ＢＣＥ）を示す。このＢＣＥは、ＭＮ１６０１のＮＡＩ（Network Access Identifier）であるMN.NAI２００と、ＭＮ１６０１に割り当てられているプレフィックスであるMN.Prefix２１０を有し、さらにＭＡＧ１３０１、１４０１の各エントリとして、代理ノードによって登録されたエントリであることを示す代理フラグ２２０（Proxy Flag 1）、２６０（Proxy Flag 2）と、その代理ノードを示すＭＡＧ１３０１のアドレス２３０（MAG1 Address）、ＭＡＧ１４０１のアドレス２７０（MAG2 Address）と、ＭＮ１６０１のＩＦ１１が接続するリンク１３５１に対応するリンク１記述子２４０（Link 1 Descriptor）、ＩＦ１２が接続するリンク１４５１に対応するリンク２記述子２８０（Link 2 Descriptor）と、それぞれのエントリに対して割り当てられているＢＩＤ２５０（ＢＩＤ１）、ＢＩＤ２９０（ＢＩＤ２）とを有している。

ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動してモバイルＩＰを開始すると、まずＢＩＤ要求メッセージをＬＭＡ１２０１に送信する。このＢＩＤ要求メッセージは、フォリンネットワーク１１０１に移動したＩＦ１２のＭＡＣアドレスを含む。ＬＭＡ１２０１はこのＢＩＤ要求メッセージを受信すると、メッセージ内のＭＡＣアドレスをマッチングすることにより、要求されたＢＩＤ２９０（ＢＩＤ２）を正しく特定してＢＩＤ要求メッセージに即刻応答することができる。

他の例として、ＭＡＧ１３０１、１４０１は、ＭＮ１６０１と通信している自身のインタフェースのＭＡＣアドレスを、ＬＭＡ１２０１に送信する代理ＢＵ内に含ませるようにしてもよい。この場合には、ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動してモバイルＩＰを開始し、ＢＩＤ要求メッセージをＬＭＡ１２０１に送信するとき、このＢＩＤ要求メッセージ内に、前の接続点であるＭＡＧ１４０１のＩＦのＭＡＣアドレスを含ませる。したがって、ＬＭＡ１２０１はこのＢＩＤ要求メッセージを受信すると、メッセージ内のＭＡＣアドレスをマッチングすることにより、要求されたＢＩＤ２９０（ＢＩＤ２）を正しく特定してＢＩＤ要求メッセージに即刻応答することができる。

他の例として、ＭＮ１６０１がＩＦ１１、ＩＦ１２の各コネクションに対してローカルにユニークな識別子を使用してもよい。この利点は、複数のリンクを同時にサポートするＩＦ１１、ＩＦ１２の各リンクを明確に特定することができることにある。但し、この場合には、ＭＮ１６０１は、使用しているコネクションＩＤのＭＡＧ１３０１、１４０１を明確に通知しなければならない。この通知は、アソシエーションフェーズの間に別のメッセージを送ることにより実現することができる。ＭＡＧ１３０１、１４０１はＭＡＣアドレスの代わりに、このコネクションＩＤを、ＬＭＡ１２０１に対する代理ＢＵ内に含ませる。ＬＭＡ１２０１はＭＡＣアドレスの代わりに、このコネクションＩＤをＢＣＥ内に含ませる。そして、ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動してＢＩＤ要求メッセージをＬＭＡ１２０１に送信するとき、このＢＩＤ要求メッセージ内に、ＩＦ１２が関連するコネクションＩＤを含ませる。ＬＭＡ１２０１はこのＢＩＤ要求メッセージ内のコネクションＩＤをマッチングして正しいＢＩＤ２９０（ＢＩＤ２）を応答することができる。

他の例として、ＭＡＧ１３０１がＭＮ１６０１に対して直接にフィードバックするようにしてもよい。この場合、まず、ＭＮ１６０１はアソシエーション中に、ＭＡＧ１３０１に対して、ネットワークが割り当てたＢＩＤを知得したい旨を通知する。この通知は、アソシエーションフェーズの間にフラグか別のメッセージを送ることにより実現することができる。また、ＭＮ１６０１は、ＭＡＧ１３０１の通信中はいつでもＭＡＧ１３０１に問い合わせをするように選択してもよい。ＭＡＧ１３０１はこの通知を受信すると、ＬＭＡ１２０１から得られたＢＩＤをＭＮ１６０１に通知する。

ＭＡＧ１３０１はまた、他の種々の方法でＢＩＤをＭＮ１６０１に通知してもよい。その１つは、ＢＩＤをＭＮ１６０１に対するルータ広告メッセージ（ＲＡ：Router Advertisement）に追加する方法である。この方法は、ネットワークベースの移動制御プロトコルの（ＰＭＩＰ）ドメインが、１つのＭＮに対して１つのプリフィックス割り当てる形態を使用している場合に特に有用である。この理由は、ＭＮ１６０１が他のノードには見えないユニキャストＲＡを受信するからである。もし、ＲＡをブロードキャストすると、どのＢＩＤがどのＭＮに属するかわからないという混乱が発生するが、ユニキャストＲＡはこれを防止することができる。他の方法として、ＭＡＧ１３０１からＭＮ１６０１へのＢＩＤを専用のメッセージで通知するようにしてもよく、また、この専用のメッセージは、ＭＮ１６０１あての既存のパケットに付加して送信してもよい。

他の例として、ＡＲ１５０１はＰＭＩＰのローカルネットワーク１００１の一部ではないが、ＡＲ１５０１がこの問題点を解決するようにしてもよい。この場合には、ＭＮ１６０１のＩＦ１２がフォリンネットワーク１１０１に移動して、ＭＮ１６０１がモバイルＩＰを開始し、ＢＩＤ要求メッセージをＬＭＡ１２０１あてに送信すると、ＡＲ１５０１はこのＢＩＤ要求メッセージを含むパケットを受信してＢＩＤ要求メッセージを検出し、オプションとしてＭＮ１６０１のリンク識別子をＢＩＤ要求メッセージに追加する。このオプションのリンク識別子は、ＬＭＡ１２０１あてのＢＩＤ要求メッセージに付加して送信するか、別のパケットで送信してもよい。ＬＭＡ１２０１はリンク識別子を含むこのオプションを解釈し、ＢＩＤ要求メッセージを上記と同様な手順で処理する。

一方、ＭＮ１６０１がフォリンネットワーク１１０１内のＡＲ１５０１からローカルネットワーク１００１内のＭＡＧ１４０１に移動した場合、ＭＡＧ１４０１はＭＮ１６０１がＰＭＩＰサービスを受けることができ、ＰＭＩＰサービスを開始すると決定する。そして、ＭＡＧ１４０１はＭＮ１６０１のリンク識別子を含むＢＩＤ要求メッセージをＬＭＡ１２０１あてに送信する。

＜第６の実施の形態＞
図２２は本発明の第６の実施の形態におけるネットワークの構成を示す図であり、第４の実施の形態における図１０と同様に、ハンドオーバがネットワーク２０からネットワークベースプロトコルのネットワーク３０へ行われるが、図１０との違いは、ネットワーク４０ａは、ネットワークベースプロトコルが提供されていて代理ノード３１ａが存在する点である。そして、移動前のＭＮ１０のＩＦ１１、ＩＦ１２がそれぞれ、ネットワークベースプロトコルのネットワーク４０ａと、ネットワークベースプロトコルでないネットワーク２０と通信を行っている状態から、ＭＮ１０が移動してＩＦ１２のみがネットワークベースプロトコルのネットワーク３０にハンドオーバした場合にも同様に、ＩＦ１１、ＩＦ１２のＭＡＣアドレスにより、ＩＦ１２のＢＩＤをネットワーク３０内の代理ノード３１に通知することができる。

＜第７の実施の形態＞
本発明の第７の実施の形態では、ＭＮ１０のハンドオーバが、ネットワークベースの移動制御プロトコルが提供されているネットワーク３０から、ネットワークベースの移動制御プロトコルが提供されていないネットワーク２０へ行われる。また、第7の実施の形態のネットワーク構成は、第1の実施の形態で図１、図１２、図１３を用いて説明した構成と同じであるため、説明を省略する。

図２５は、本発明の第７の実施の形態におけるシーケンスとして、ＭＮ１０がネットワーク３０で初期起動してネットワーク３０の代理ノード３１（ＭＡＧ：Mobile Access Gateway、ＰＭＡ(Proxy Mobile Agent)、以下、代理ノードを用いる）によりＭＮ１０の位置情報が、ホームエージェント３２（ＨＡ：Home Agent、又はＬＭＡ：Local Mobility Anchor、以下ではＨＡの方を用いる）に登録された後に、ネットワーク２０にハンドオーバした場合の通信シーケンスを示す。

（１）アクセス及びモビリティ認証
・ＭＮ１０はネットワーク３０で初期起動すると、代理ノード３１に対してアクセス認証要求メッセージ（以下の説明及び通信シーケンス図では、「メッセージ」は省略）を送信する。
・代理ノード３１はＭＮ１０からのアクセス認証要求を受信すると、ＡＡＡ（Authentication, Authorization, Accounting）サーバ５０に対してＡＡＡリクエスト（request）でＭＮ認証要求を送信する。
・ＡＡＡサーバ５０は代理ノード３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、代理ノード３１に対して、ＡＡＡリプライで認証ＯＫを通知する。
・代理ノード３１はＡＡＡサーバ５０からのＡＡＡリプライを受信すると、ＭＮ１０に対してアクセス認証完了を通知する。

（２）代理ノードによる位置情報登録
・代理ノード３１はＨＡ３２に対して、代理ＢＵ（Proxy Binding Update）を送信して、ＭＮ１０のホームプレフックスに代理ノード３１のアドレス（ＭＡＧ addr）を関連付けた情報を、ＭＮ１０の位置情報としてＨＡ３２へ登録する。
・ＨＡ３２がこの受信後、ＡＡＡサーバ５０に対してＡＡＡリクエストを送信し、ＡＡＡサーバ５０がＡＡＡリクエストを受信して、ＨＡ３２に対してＡＡＡリプライを送信することにより、代理ノード認証プロセスを実行する。なお、代理ノード３１の認証が不要な場合は、ＡＡＡリクエストの送信は省略してもよい。
・ＨＡ３２はＡＡＡサーバ５０からのＡＡＡリプライを受信すると、代理ノード３１に対して代理ＢＡ（Proxy Binding Acknowledgement）を送信する。
・代理ノード３１はＨＡ３２から位置情報登録ＯＫを示す代理ＢＡを受信すると、ＭＮ１０に対してＲＡ（Router Advertisement）を送信してＭＮ１０のホームプレフィックスを通知する。

・ＭＮ１０は代理ノード３１からのＲＡを受信すると、メッセージに含まれているプレフィックスを用いてアドレスを生成し、ＩＦへ割り当てる。さらにメッセージに含まれているプレフィックスが自身のホームプレフィックスである場合には、ＭＮ１０はホームネットワークに接続していると認識する。なお、ＲＡにホームプレフィックスが含まれている場合には、ホームネットワークに接続していることと同時に、その状態がネットワークベースの移動制御プロトコルによって実現されていると認識するようにしてもよい。また、本発明の第1の実施の形態に示すように、ＩｓＰＭＩＰ情報がＲＡに含まれている場合に、ネットワークベースの移動制御プロトコルが提供されていると認識するようにしてもよい。
なお、ＲＡにＭフラグが含まれている場合には、ＭＮ１０は、代理ノード３１に対してＤＨＣＰ（Dynamic Host Configuration Protocol）request を送信する。この場合、代理ノード３１はＭＮ１０からのＤＨＣＰ request を受信すると、ＭＮ１０に対してＤＨＣＰ reply を送信して、ＭＮ１０へ割り当てるアドレスを通知する。なお、本発明の第1の実施の形態に示すように、ＭＮ１０へ割り当てるアドレスと共に、ＨＡ３２のアドレス（ＨＡ address）と、ＩｓＰＭＩＰ情報を通知してもよい。

（３）ＭＮによる位置情報登録
・ＭＮ１０はネットワーク２０に移動すると、移動前に接続していたネットワーク３０がホームネットワークであったことを判断し、ネットワーク２０で取得したアドレス（Ａｄｄｒ２）と共に、移動前にホームネットワークに接続していたことを示す情報（以下、移動前ホームネットワーク接続情報）をＢＵメッセージに付加してＨＡ３２へ送信する。
・ＨＡ３２はＭＮ１０からのＢＵメッセージを受信すると、メッセージの中に移動前ホームネットワーク接続情報が存在することを確認し、新しい位置情報で置き換えるべき対象が、代理ノードによって登録された位置情報であると判断する。そして、すでに登録されているＭＮ１０の位置情報の中から代理ノードによって登録された位置情報を特定して、それを新しい移動後の位置情報で置き換える。そして、ＨＡ３２は、位置情報の登録の結果を含むＢＡメッセージをＭＮ１０へ送信する。

図２６は第７及び後述する第８の実施の形態におけるＭＮ１０の構成を示すブロック図である。ＭＮ１０は前述したインタフェースＩＦ１１、ＩＦ２２の他、送信部８０３と、受信部８０４と、Binding Update（ＢＵ）メッセージ生成部８０５と、移動前ネットワーク情報保持部８０６と、ＲＳ（Router Solicitation）送信処理部８０７と、ネットワーク接続検出部８０８と、アクセス認証処理部８０９と、ＲＡ（Router Advertisement）処理部８１０と、ＢＡ（Binding Acknowledgement）メッセージ処理部８１１と、登録済位
置情報保持部８１２と接続ネットワーク情報保持部８１３を有する。

以下では、ＭＮ１０が備える主要構成要素について説明する。インタフェースＩＦ１１、ＩＦ２２の存在は、ＭＮ１０が２つのインタフェースを有することを示している。また、送信部８０３及び受信部８０４は、インタフェースＩＦ１１、ＩＦ２２のそれぞれを通じてパケットの送受信を行う機能を有している。ＢＵメッセージ生成部８０５は、接続ネットワーク情報保持部８１３から、ＩＦ１１またはＩＦ２２がハンドオーバして接続するネットワークが変更になったことの通知を受け、ＨＡ３２に登録されている移動前の位置情報を、移動後の位置情報で更新するためのＢＵメッセージを生成する。

移動後のネットワークが外部ネットワークである場合には、ＢＵメッセージ生成部８０５は、移動前ネットワーク情報保持部８０６を確認し、移動前に接続していたネットワークがホームネットワークであったか否かを判断する。その結果、移動前のネットワークがホームネットワークであった場合には、生成するＢＵメッセージの中に、移動前のネットワークがホームネットワークであったこと、あるいは移動前のネットワークではネットワークベースの移動制御プロトコルが提供されていたことを示す情報（移動前ホームネットワーク接続情報と呼ぶ、フラグなどで実現してもよい）を付加する。例えば、ＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバして、接続ネットワーク情報保持部８１３から、ＩＦ２２が接続するネットワークが変わったことの通知を受け、外部ネットワークに接続したことを認識した場合、移動前ネットワーク情報保持部８０６を確認して、移動前のネットワークがホームネットワークであったことを認識する。そして、移動後のネットワークで取得したアドレスと共に、移動前ホームネットワーク接続情報を含むＢＵメッセージを生成してＨＡ３２へ送信する。なお、移動前ホームネットワーク接続情報を含むＢＵメッセージに、ＩＦ２２に関する位置情報を登録する際に使用するＢＩＤとして、ＭＮ１０が生成したＢＩＤをＢＵメッセージに付加して送信してもよい。

ＭＮ１０が送信するＢＵメッセージ内の移動前ホームネットワーク接続情報は、図２４に示すように、モビリティヘッダ３０１の中や、代替ＣｏＡオプション３０３の中にフラグなどとして含まれていてもよいし、ＢＩＤを含むオプション３０４の中に含まれていてもよい。また、後述する移動前外部ネットワーク接続情報と同じ位置のフラグを用いることで、フラグがセットされている場合は、移動前ホームネットワーク接続情報を示し、フラグがセットされていない場合は、移動前外部ネットワーク接続情報を示すようにしてもよいし、又はその逆でもよい。

この場合、このＢＵメッセージを受信したＨＡ３２は、メッセージ内の移動前ホームネットワーク接続情報により、ＭＮ１０の移動前の位置情報が代理ノード３１によって登録された位置情報であることを認識し、ＭＮ１０からのＢＵメッセージ内に含まれる新しい位置情報で置き換える対象として、代理ノード３１によって登録された位置情報を特定することができる。さらに、ＨＡ３２は、特定した位置情報を新しい位置情報で置き換え、このＢＵメッセージに対するレスポンスメッセージとして送信するＢＡメッセージの中に、位置情報の置換の結果を示す情報として置換が成功したことを示す情報を含めて送信する。

また、本発明の第１の実施の形態に示すように、移動前ホームネットワーク接続情報を含むＢＵメッセージを用いて、ＩＦ２２の位置情報の登録に使用するＢＩＤを要求するようにしてもよい。この場合、移動前ホームネットワーク接続情報を含むＢＵメッセージを受信したＨＡ３２が、移動前ホームネットワーク接続情報を用いて特定したＭＮ１０の移動前の位置情報に付加されているＢＩＤをＢＣ（Binding Cache：バインディングキャッシュ）から取得し、ＢＡメッセージに含めてＭＮ１０へ通知する。なお、ＭＮ１０の移動前の位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバ５０や、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。

また、この場合のＢＵメッセージ３００には、図２３に示すように、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４が、移動前ホームネットワーク接続情報、及びＢＩＤの取得を要求することを示す情報として使われてもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。また、ＭＮ１０からのＢＵメッセージ内にＭＮ１０が生成したＢＩＤが付加されている場合には、ＨＡ３２は、そのＢＩＤと共に移動後の位置情報を保持し、位置情報の置換の結果を示す情報として置換が成功したことを示す情報と共に、そのＢＩＤをＢＡメッセージに含めてＭＮ１０へ送信する。このＢＡメッセージを受けたＭＮは、以降ＩＦ２２に関する位置情報の登録の際に、受信したＢＡメッセージに含まれていたＢＩＤを使用する。なお、ＢＵメッセージ、及びＢＡメッセージの代わりに、ＩＫＥリクエストメッセージ、及びＩＫＥレスポンスメッセージを用いてもよい。

移動前ネットワーク情報保持部８０６は、接続ネットワーク情報保持部８１３から渡された、ＩＦ１１及びＩＦ２２が移動する前に接続していたネットワークに関する情報を保持する。

ＲＳ送信処理部８０７は、アクセス認証処理部８０９からアクセス認証が完了したことの通知を受けて、接続しているネットワーク２０又は３０又は４０に対してＲＡメッセージの送信を要求するためのＲＳメッセージを生成して送信部８０３に対して送信するよう指示する。なお、ＲＳメッセージは、送信する前にＲＡメッセージを受信することができた場合は、送信する必要はない。

また、ＲＳ送信処理部８０７は、接続ネットワーク情報保持部８１３から、ＩＦ１１またはＩＦ２２がハンドオーバして接続するネットワークが変更になったことの通知を受けたとき、ＨＡ３２に登録されている移動前の位置情報を移動後の位置情報で更新するための代理ＢＵメッセージを送信する代理ノード３１に対して、ＲＳメッセージを送信する。このとき、移動後のネットワークがホームネットワークである場合には、ＲＳ送信処理部８０７は、移動前ネットワーク情報保持部８０６を確認し、移動前に接続していたネットワークが外部ネットワーク、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワークであったか否かを判断する。

その結果、移動前のネットワークが外部ネットワークであった場合には、生成するＲＳメッセージの中に、移動前のネットワークが外部ネットワークであったこと、すなわち移動前のネットワークではネットワークベースの移動制御プロトコルが提供されていなかったことを示す情報（以下、移動前外部ネットワーク接続情報、フラグなど）を付加する。例えば、ＩＦ２２がネットワーク２０からネットワーク３０へハンドオーバして、接続ネットワーク情報保持部８１３から、ＩＦ２２が接続するネットワークが変わったことの通知を受け、ホームネットワークに接続したことを認識した場合、移動前ネットワーク情報保持部８０６を確認して、移動前のネットワークが外部ネットワークであったことを認識する。そして、移動前外部ネットワーク接続情報を含むＲＳメッセージを生成して代理ノード３１へ送信する。なお、移動前外部ネットワーク接続情報を通知するためのメッセージとして、ＮＳメッセージやＤＨＣＰリクエストメッセージ、認証リクエストメッセージ、さらにはＢＵメッセージなどを用いてもよい。なお、ＭＮ１０が送信するＲＳメッセージ内の移動前外部ネットワーク接続情報は、図２７に示すように、ＲＳメッセージ３１０のヘッダ部３１１の中にフラグとして含まれていてもよいし、新たなオプション３１２の中に含めてもよい。

この場合、このＲＳメッセージを受信した代理ノード３１はＨＡ３２に対して、ＭＮ１０から通知された移動前外部ネットワーク接続情報を付加した代理ＢＵメッセージを送信する。なお、代理ノード３１が送信する代理ＢＵメッセージ内の移動前外部ネットワーク接続情報は、図２４の移動前ホームネットワーク接続情報と同様に、モビリティヘッダ３０１の中や、代替ＣｏＡオプション３０３の中にフラグなどとして含まれていてもよいし、ＢＩＤを含むオプション３０４の中に含まれていてもよい。また、移動前ホームネットワーク接続情報と同じ位置のフラグを用いることで、フラグがセットされている場合は、移動前ホームネットワーク接続情報を示し、フラグがセットされていない場合は、移動前外部ネットワーク接続情報を示すようにしてもよいし、又はその逆でもよい。

この代理ＢＵメッセージを受信したＨＡ３２は、メッセージ内の移動前外部ネットワーク接続情報により、ＭＮ１０の移動前の位置情報がＭＮ１０自身によって登録された位置情報であることを認識し、代理ノード３１からの代理ＢＵメッセージ内に含まれる移動後の位置情報で置き換える対象として、ＭＮ１０によって登録された位置情報を特定することができる。さらに、ＨＡ３２は特定した位置情報を新しい位置情報で置き換え、この代理ＢＵメッセージに対するレスポンスメッセージとして送信する代理ＢＡメッセージの中に、位置情報の置換の結果を示す情報として置換が成功したことを示す情報を含めて送信する。

また、本発明の第１の実施の形態に示すように、代理ノード３１は、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを用いて、ＭＮ１０のＩＦ２２の位置情報の登録に使用するＢＩＤを要求するようにしてもよい。この場合、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを受信したＨＡ３２が、移動前外部ネットワーク接続情報を用いて特定したＭＮ１０の移動前の位置情報に付加されているＢＩＤをＢＣから取得し、代理ＢＡメッセージに含めて代理ノード３１へ通知する。なお、ＭＮ１０の移動前の位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、ＨＡ３２が新たなＢＩＤを生成し、代理ＢＡメッセージに含めて送信する。

なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバ５０や、ＭＮ１０の情報を保持している情報サーバなどに対して、ＢＩＤの取得・生成を要求してもよい。この場合の代理ＢＵメッセージには、図２３に示すように、ＢＩＤを通知するためのオプション３０４の中の、ＢＩＤを含むべきフィールド部分が空（ゼロ値）になっている状態のオプション３０４が含まれていて、このオプション３０４がＢＩＤの取得を要求することを示す情報として使われてもよいし、又はモビリティヘッダ３０１の中や、ＢＩＤを通知するためのオプション３０４の中にＢＩＤの取得を要求することを示す情報（フラグなど）を付加してもよいし、両方の組み合わせでもよい。なお、ＢＩＤを要求することを示すフラグは、代替ＣｏＡオプション３０３に含まれていてもよい。また、代理ノード３１からの代理ＢＵメッセージ内に代理ノード３１が生成したＢＩＤが付加されている場合には、ＨＡ３２は、そのＢＩＤと共に移動後の位置情報を保持し、位置情報の置換の結果を示す情報として置換が成功したことを示す情報と共に、そのＢＩＤをＢＡメッセージに含めて代理ノード３１へ送信する。この代理ＢＡメッセージを受けた代理ノード３１は、以降ＭＮ１０のＩＦ２２に関する位置情報の登録の際に、受信した代理ＢＡメッセージに含まれていたＢＩＤを使用する。

図２８に示す判断処理について説明する。ＭＮ１０が別のネットワークへ移動すると（ステップＳ３１）、移動先ネットワークが外部ネットワークであるかホームネットワークであるかを判断する（ステップＳ３２）。ここで、移動先ネットワークがホームネットワークである場合には（ステップＳ３２でＮＯ）、後述するステップＳ３３に進む。他方、移動先ネットワークが外部ネットワークである場合には、移動前のネットワークがホームネットワークであったか否かを判断する（ステップＳ３７）。ここで、移動前のネットワークがホームネットワークであった場合には、生成するＢＵメッセージに移動前ホームネットワーク接続情報を付加して（ステップＳ３８）、位置情報と共に送信する（ステップＳ３９）。他方、移動前のネットワークがホームネットワークでなかった場合には、移動前に使用していたＢＩＤを使用した位置情報登録を通常通り行う（ステップＳ４０）。

ステップＳ３３では、移動前のネットワークが外部ネットワークであった場合には、生成するＲＳメッセージに移動前外部ネットワーク接続情報を付加して（ステップＳ３５）、送信する（ステップＳ３６）。他方、移動前のネットワークがホームネットワークであった場合（ステップＳ３３でＮＯ）には、引き続きネットワークベースの移動制御プロトコルを使用する判断をして、移動制御を行わない（ステップＳ３４）。

また別の方法として、ＭＮ１０のＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバする以前に、ＭＮ１０が、ＩＦ１１に関する位置情報をＨＡ３２に登録するために送信するＢＵメッセージ内に、ＭＮ１０の他のＩＦ（ＩＦ２２）がホームネットワークに接続していること、あるいはネットワークベースの移動制御プロトコルが提供されているネットワークに接続していることを示す情報（フラグなど、以下、ＩＦホームネットワーク接続情報）を付加してもよい。

この場合、このメッセージを受信したＨＡ３２は、登録する位置情報と共にＩＦホームネットワーク接続情報をＢＣ内に保持する。そして、ＭＮ１０のＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした後、ＨＡ３２は、ＭＮ１０からＩＦ２２の新しい位置情報を含むＢＵメッセージを受信した際に、そのメッセージの中に、ＩＦホームネットワーク接続情報が含まれていない場合には、ＭＮ１０はすでにホームネットワークに接続していないこと、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワーク（ネットワーク２０）へ移動したことを認識し、ＭＮ１０からのＢＵメッセージ内に含まれる新しい位置情報で置き換える対象が、代理ノード３１によって登録された位置情報であること、あるいはＩＦホームネットワーク接続情報が付加されていない位置情報であることを認識することができる。

なお、ＭＮ１０から、ＩＦホームネットワーク接続情報を含むＢＵメッセージを受信したＨＡ３２は、ＭＮ１０のＩＦ２２がホームネットワークに接続していること、あるいはネットワークベースの移動制御プロトコルが提供されているネットワークに接続していることを示す情報（ＩＦホームネットワーク接続情報）を、ＢＣ内の代理ノード３１によって登録された位置情報に対して付加してもよい。この場合、ＨＡ３２が、ＭＮ１０からＩＦ２２の新しい位置情報を含むＢＵメッセージを受信した際に、そのメッセージの中にＩＦホームネットワーク接続情報が含まれていない場合には、ＭＮ１０はすでにホームネットワークに接続していないこと、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワーク（ネットワーク２０）へ移動したことを認識し、ＭＮ１０からのＢＵメッセージ内に含まれる新しい位置情報で置き換える対象が、代理ノード３１によって登録された位置情報であること、あるいはＩＦホームネットワーク接続情報が付加されている位置情報であることを認識することができる。なお、ＨＡ３２は、置き換え対象の位置情報を特定する際に、位置情報にＭＡＧ登録情報が付加されているかどうかを確認し、付加されている場合に置き換え対象の位置情報であると判断してもよい。

さらに、ＨＡ３２は、特定した位置情報を新しい位置情報で置き換えると共に、このＢＵメッセージに対して送信するＢＡメッセージに、置き換え対象である位置情報に付加されているＢＩＤをＢＣから取得し、そのＢＩＤをＢＡメッセージに含めて送信する。また、置き換え対象である位置情報にＢＩＤが付加されていない場合や、置き換え対象となる位置情報が存在しない場合には、新たなＢＩＤを生成し、ＢＡメッセージに含めて送信する。なお、ＢＩＤを取得・生成する手法として、ＨＡ３２は、ＡＡＡサーバ５０や、ＭＮ１０の情報を保持している情報サーバ（不図示）などに対して、ＢＩＤの取得・生成を要求してもよい。なお、ＨＡ３２は、ＭＮ１０からのＢＵメッセージを受けてＢＣに登録した新しい位置情報の中に、その位置情報によって置き換えられた位置情報が、以前代理ノード３１によって登録された位置情報であったことを示す情報（ＭＡＧ登録情報）を保持してもよい。この情報は、以降ＭＮ１０からの位置情報の更新があった場合でも消去されずに保持される。

図２６に示すＢＡメッセージ処理部８１１は、Binding Update メッセージ生成部８０５によって生成・送信されたＢＵメッセージに対するレスポンスメッセージであるＢＡメッセージの受信処理を行う。例えば、ＭＮ１０のＩＦ２２がネットワーク３０からネットワーク２０へハンドオーバした場合、ＢＡメッセージには、代理ノード３１によって登録された移動前の位置情報に対して、移動後の位置情報での置換が成功したことを示す情報が含まれている。また、以降のＩＦ２２の位置情報を登録する際に使用するＢＩＤが含まれている場合、そのＢＩＤと共に、登録した位置情報を登録済位置情報保持部８１２に保持するよう指示する。

ＲＡ処理部８１１は、接続しているネットワークから受信したＲＡメッセージに関する処理を行い、接続しているネットワークを特定する情報として、ＲＡメッセージに含まれているプレフィックス情報などを接続ネットワーク情報保持部８１３に渡して保持するよう指示する。接続ネットワーク情報保持部８１３は、ＲＡ処理部８１０から渡された接続ネットワーク情報と自身が保持している接続ネットワーク情報とを比較し、両者が異なる場合は、接続ネットワークが変わったと判断し、ＢＵメッセージ生成部８０５及びＲＳ送信処理部８０７に対して、接続ネットワークが変わったことを通知する。さらに、変わる前の接続ネットワーク情報を移動前ネットワーク情報保持部８１２へ渡し、保持するよう指示する。登録済位置情報保持部８１２は、ＭＮ１０がＨＡ３２及び通信相手に登録している位置情報を保持する。モバイルＩＰにおけるＢＵＬ（バインディングアップデートリスト）として機能する。

アクセス認証処理部８０９は、ネットワーク接続検出部８０８からアクセスネットワークに接続したことの通知を受け、そのネットワークに対する認証処理を開始するためのアクセス認証リクエストをネットワークに対して送信し、その認証結果をネットワークから受信する。その認証結果がＭＮ１０の接続を許可するものであった場合には、ＲＳ送信処理部８０７に対して認証の完了を通知する。アクセス認証では、ＩＥＥＥ８０２．１ｘやＩＥＥＥ８０２．１１ｉなどの方法が用いられ、認証方式としては、ＥＡＰ−ＭＤ５、ＥＡＰ−ＴＬＳ、ＥＡＰ−ＴＴＬＳ、ＥＡＰ−ＰＥＡＰなどが用いられる。アクセス認証部８０９が生成するアクセス認証要求メッセージは特に新しい情報を持たないが、代理ノード３１が送信する認証リクエストメッセージのトリガとなり、さらにその後のＡＡＡサーバ５０によるＢＩＤ割り当てをトリガするメッセージでもある。

図２９は本発明の第７の実施の形態における代理ノード３１の構成を示す図である。代理ノード３１はネットワークとの通信インタフェースであるインタフェース８２１と、送信部８２３と、受信部８２４と、アクセス認証処理部８２５と、代理ＢＵメッセージ生成部８２６と、ＲＳメッセージ処理部８２７と、ＲＡ生成部８２８と、代理ＢＡメッセージ処理部８２９と、登録済位置情報保持部８３０を有する。送信部８２３及び受信部８２４は、インタフェースを通じてパケットの送受信を行う機能を有している。アクセス認証処理部８２５は、ＭＮ１０からのアクセス認証メッセージを処理し、それをＡＡＡサーバ５０に転送して、ＭＮ１０の認証を要求する。そして、ＡＡＡサーバ５０からＭＮ１０の認証結果を含むレスポンスメッセージを受信し、その結果をＭＮ１０へ返す。

代理ＢＵメッセージ生成部８２６は、ＭＮ１０の認証が完了した後に、アクセス認証処理部８２５からの指示を受け、ＭＮ１０の位置情報として、ＭＮ１０のホームプレフィックスに代理ノード３１自身のアドレスを関連付けた情報をＨＡ３２へ登録するための代理ＢＵメッセージを生成し、送信部８２３へ送信するよう指示する。ＭＮ１０のホームプレフィックスや、登録先のＨ３２のアドレスなどは、ＭＮ１０の管理情報を保持している情報サーバ（不図示）に問い合わせて取得することができる。また、代理ＢＵメッセージ生成部８２６は、ＲＳメッセージ処理部８２７から指示を受け、ＭＮ１０の位置情報として、ＭＮ１０のホームプレフィックスに代理ノード３１自身のアドレスを関連付けた情報と共に、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを生成し、送信部８２３に対してＨＡ３２へ送信するよう指示する。

なお、ＭＮ１０のホームプレフィックスの割り当てをＨＡ３２に対して要求するために、ホームプレフィックスを指定しない代理ＢＵメッセージを送信してもよい。この場合の代理ＢＵメッセージには、ホームプレフィックスを通知するためのオプションの中の、ホームプレフィックスを含むべきフィールド部分が空（ゼロ値）になっている状態のオプションが含まれていて、このオプションがホームプレフィックスの割り当てを要求することを示す情報として使われてもよい。また、ＭＮ１０の識別情報として、ＭＮ１０の識別子（ＮＡＩ：Network Access Identifier）を代理ＢＵメッセージに含めてもよい。さらに、ＨＡ３２に登録されているＭＮ１０の他の位置情報との識別をするために、ＢＩＤを生成して代理ＢＵメッセージに付加して送信してもよい。また、前述したように、ＢＩＤの割り当てを要求するために、ＢＩＤを指定せずにＢＵメッセージを送信してもよい。

代理ＢＡメッセージ処理部８２９は、代理ＢＵメッセージ生成部８２６が生成・送信した代理ＢＵメッセージに対するレスポンスとして受信した代理ＢＡメッセージに関する処理を行い、代理ＢＡメッセージに含まれる位置情報の登録結果を取得して、登録が成功した位置情報を登録済位置情報保持部８３０へ渡し保持するよう指示する。また、移動前外部ネットワーク接続情報を用いた登録が成功したことを示す結果が含まれている場合には、その情報も保持するよう指示する。なお、登録が失敗したことを示す情報を登録済位置情報保持部８３０へ保持するよう指示し、移動前ホームネットワーク接続情報及び移動前外部ネットワーク接続情報に対応していないことを示す情報として利用してもよい。

さらに、代理ＢＡメッセージ処理部８２９は、ＭＮ１０の位置情報の登録が成功した場合には、ＲＡ生成部８２８に対し、ＭＮ１０のホームプレフィックスを含むＲＡメッセージを生成して送信するよう指示する。また、代理ＢＡメッセージに移動前外部ネットワーク接続情報を用いた登録が成功したことを示す結果が含まれていた場合には、ＭＮ１０のホームプレフィックスと共に、移動前外部ネットワーク接続情報による登録が成功したことを示す情報を含むＲＡメッセージを生成するよう指示する。また、代理ＢＡメッセージ処理部８２９は、受信した代理ＢＡメッセージ内に、ＢＩＤが含まれている場合には、以降の位置情報登録の際に、そのＢＩＤを代理ＢＵメッセージに付加して送信する。

ＲＳメッセージ処理部８２７は、ＭＮ１０から受信したＲＳメッセージに関する処理を行い、ＲＡ生成部８２８に対して、ＭＮのホームプレフィックスを含むＲＡメッセージを生成して送信するよう指示する。また、ＲＳメッセージ生成部８２７は、ＭＮ１０から受信したＲＳメッセージに移動前外部ネットワーク接続情報が含まれている場合には、代理ＢＵメッセージ生成部８２６に対して、ＭＮ１０の位置情報として、ＭＮ１０のホームプレフィックスに代理ノード３１自身のアドレスを関連付けた情報と共に、移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを生成するよう指示する。なお、移動前外部ネットワーク接続情報を通知するためのメッセージとしてアクセス認証要求メッセージを使用する場合には、アクセス認証処理部８２５が、代理ＢＵメッセージ生成部８２６へ同様の指示を出す。

ＲＡ生成部８２８は、代理ＢＵメッセージに対するレスポンスとして代理ＢＡメッセージを受信した代理ＢＡメッセージ処理部８２９からの指示を受け、渡されたＭＮ１０のホームプレフィックスを含むＲＡメッセージを生成し、送信部８２３に対してＭＮ１０へ送信するよう指示する。また、ＲＡ生成部８２８は、代理ＢＡメッセージ処理部８２９から、移動前外部ネットワーク接続情報による登録が成功したことを通知された場合には、ＭＮ１０のホームプレフィックスと共に、移動前外部ネットワーク接続情報による登録が成功したことを示す情報を含むＲＡメッセージを生成し、送信部８２３に対してＭＮ１０へ送信するよう指示する。登録済位置情報保持部８３０は、代理ＢＡメッセージ処理部８２９の指示を受け、ＨＡ３１及び通信相手に対して登録しているＭＮ１０の位置情報に関する情報を保持する。

図３０は本発明の第７の実施の形態におけるＨＡ３２の構成を示すブロック図である。ＨＡ３２はインタフェース８４１と、送信部８４２と、受信部８４３と、認証処理部８４４と、ＢＡメッセージ生成部８４５と、代理ＢＡ（Binding Acknowledgement）メッセージ生成部８４６と、代理ＢＵ（Binding Update）メッセージ処理部８４７と、ＢＵ（Binding Update）メッセージ処理部８４８と、ＭＮ管理情報保持部８４９とを有する。送信部８４２及び受信部８４３は、インタフェース８４１を通じてパケットの送受信を行う機能を有している。

認証処理部８４４は、代理ＢＵメッセージ処理部８４７の指示を受け、代理ＢＵメッセージを送信した代理ノード３１の認証をするための認証リクエストメッセージをＡＡＡサーバ５０へ送信する。また、ＢＵメッセージ処理部８４８の指示を受け、ＢＵメッセージを送信したＭＮ１０の認証をするための認証リクエストメッセージをＡＡＡサーバ５０へ送信する。そして、ＡＡＡサーバ５０から代理ノード３１、及びＭＮ１０の認証結果を含む認証レスポンスメッセージを受信し、その結果を代理ＢＵメッセージ処理部８４７、及びＢＵメッセージ処理部８４８へ通知する。

代理ＢＵメッセージ処理部８４７は、代理ノード３１から送信された代理ＢＵメッセージに関する処理を行い、メッセージに含まれているＭＮ１０の位置情報を取得し、ＭＮ管理情報保持部８４９へ保持するよう指示する。また、代理ＢＵメッセージ処理部８４７は、メッセージ内に移動前外部ネットワーク接続情報が含まれている場合には、置き換え対象となる移動前の位置情報が、ＭＮ１０によって登録された位置情報であることを判断し、その結果特定された位置情報を新しい位置情報で置き換える。そして、置き換えによる登録が正しく行われたことを示す情報を含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部８４６へ指示する。また、置き換え対象の位置情報にＢＩＤが付加されていた場合には、置き換えによる登録が正しく行われたことを示す情報と共に、そのＢＩＤを含む代理ＢＡメッセージを生成するよう代理ＢＡメッセージ生成部８４６へ指示する。

なお、受信した代理ＢＵメッセージに、移動前外部ネットワーク接続情報と共に、代理ノード３１が指定したＢＩＤが含まれている場合には、位置情報の登録が正しく行われたことを示す情報と共に、そのＢＩＤを含むＢＡメッセージを生成するよう代理ＢＡメッセージ生成部８４６へ指示する。また、受信した代理ＢＵメッセージにＢＩＤが含まれていない場合や、置き換え対象の位置情報にＢＩＤが付加されていない場合には、新たに生成したＢＩＤを付加してもよい。なお、代理ＢＵメッセージを送信した代理ノード３１の認証が必要な場合には、認証処理部に対して代理ノード３１の認証を行い、その結果認証が成功した場合に上記の処理を実行するようにしてもよい。

ＢＵメッセージ処理部８４８は、ＭＮ１０から送信されたＢＵメッセージに関する処理を行い、メッセージに含まれているＭＮ１０の位置情報を取得し、ＭＮ管理情報保持部８４９へ保持するよう指示する。受信したＢＵメッセージ内に、移動前ホームネットワーク接続情報が含まれている場合には、ＭＮ１０はすでにホームネットワーク、すなわちネットワークベースの移動制御プロトコルが提供されていないネットワークへ移動したと認識できるため、置き換え対象となる移動前の位置情報が代理ノード３１によって登録された位置情報であることを判断し、その結果特定された位置情報を新しい位置情報で置き換える。そして、置き換えによる登録が正しく行われたことを示す情報を含むＢＡメッセージを生成するようＢＡメッセージ生成部８４５へ指示する。また、置き換え対象の位置情報にＢＩＤが付加されていた場合には、置き換えによる登録が正しく行われたことを示す情報と共に、そのＢＩＤを含む代理ＢＡメッセージを生成するようＢＡメッセージ生成部８４５へ指示する。

なお、受信したＢＵメッセージにＭＮ１０が指定したＢＩＤが含まれている場合には、位置情報の登録が正しく行われたことを示す情報と共に、そのＢＩＤを含むＢＡメッセージを生成するようＢＡメッセージ生成部８４５へ指示する。また、受信したＢＵメッセージにＢＩＤが含まれていない場合や、置き換え対象の位置情報にＢＩＤが付加されていない場合には、新たに生成したＢＩＤを付加してもよい。なお、ＢＵメッセージを送信したＭＮ１０の認証が必要な場合には、認証処理部８４４に対してＭＮ１０の認証を行い、その結果認証が成功した場合に上記の処理を実行するようにしてもよい。

代理ＢＡメッセージ生成部８４６は、代理ＢＵメッセージ処理部８４７または認証処理部８４４の指示を受け、ＭＮ１０の位置情報の登録の結果を示す情報を含む代理ＢＡメッセージを生成し、送信部８４２に対し代理ノード３１へ送信するよう指示する。また、代理ＢＵメッセージ処理部８４７から、ＢＩＤを渡された場合には、そのＢＩＤも含む代理ＢＡメッセージを生成する。なお、位置情報の登録が代理ノードから通知された移動前外部ネットワーク接続情報を用いて行われた場合には、移動前外部ネットワーク接続情報を用いて行われた置換が成功したことを示す情報を用いてもよい。

ＢＡメッセージ生成部８４５は、ＢＵメッセージ処理部８４８または認証処理部８４４の指示を受け、ＭＮ１０の位置情報の登録の結果を示す情報を含むＢＡメッセージを生成し、送信部８４２に対してＭＮ１０へ送信するよう指示する。また、ＢＵメッセージ処理部８４８から、ＢＩＤを渡された場合には、そのＢＩＤも含むＢＡメッセージを生成する。なお、位置情報の登録が、ＭＮ１０から通知された移動前ホームネットワーク接続情報を用いて行われた場合には、移動前ホームネットワーク接続情報を用いて行われた置換が成功したことを示す情報を用いてもよい。

ＭＮ管理情報保持部８４９は、代理ＢＵメッセージ処理部８４７、及びＢＵメッセージ処理部８４８からの指示を受け、代理ノード３１及びＭＮ１０から通知されたＭＮ１０の位置情報を保持する。なお、ＭＮ管理情報保持部８４９は、登録した新しい位置情報の中に、その新しい位置情報によって置き換えられた移動前の位置情報が、代理ノード３１によって登録された位置情報であったことを示す情報（ＭＡＧ登録情報）を保持してもよい。この情報は、以降ＭＮ１０からの位置情報の更新があった場合でも消去されずに保持され、代理ノード３１から移動前外部ネットワーク接続情報を含む代理ＢＵメッセージを受信した際に、このＭＡＧ登録情報が付加されている位置情報が、ＭＮ１０によって登録された情報であり、かつ、以前は代理ノード３１によって登録された位置情報に相当するものであることを判断することができる。つまり、ＭＮ１０によって一旦は置き換えられた位置情報を、再度代理ノード３１によって置き換えることができるようになる。なお、移動前ホームネットワーク接続情報は、図２４に示すように、モビリティヘッダ３０１の中や、代替ＣｏＡオプション３０３の中にフラグなどとして含まれていてもよいし、ＢＩＤを含むオプション３０４の中に含まれていてもよい。

なお、第５の実施の形態での説明したのと同様に、本実施の形態においてもＩＦ２２がネットワークベースのプロトコルが提供されているネットワーク３０からネットワーク２０へハンドオーバした際、インタフェースＩＦ１１が接続しているネットワークベースのプロトコルが提供されているネットワーク４０ａとＩＦ２２が接続していたネットワークベース３０とが同一のドメインである場合に、モバイルノード１０から送信されるバインディングアップデートメッセージは、 モバイルノード１０のインタフェースＩＦ１１を特定する識別情報（ＭＡＣアドレスなど）を含んでもよい。
本発明の第７の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されているネットワークから、提供されていないネットワークへ移動した場合でも、移動前に代理ノードによって登録された位置情報を更新するために、送信するＢＵメッセージで移動前外部ネットワーク情報をＨＡへ通知することで、代理ノードによって登録された位置情報を新たな位置情報で更新することが可能となる。

＜第８の実施の形態＞
本発明の第８の実施の形態では、ＭＮ１０のハンドオーバが、ネットワークベースの移動制御プロトコルが提供されていないネットワーク２０から、ネットワークベースの移動制御プロトコルが提供されているネットワーク３０へ行われる。また、本発明の第８の実施の形態におけるネットワーク構成は、本発明の第４の実施の形態で図１０を用いて説明した構成と同じであるため説明を省略する。また、各エンティティの構成や処理は第７の実施の形態ですでに説明しているため、ここでの説明は省略する。

図３１は、本発明の第８の実施の形態におけるシーケンスとして、ＭＮ１０がネットワーク２０で初期起動して、位置情報の登録を行った後に、ネットワーク３０にハンドオーバした場合の通信シーケンスを示す。
（１）ＭＮによる位置情報登録
・ＭＮ１０はネットワーク２０で初期起動すると、アクセス認証を行った後に、ＨＡ３２に対して位置情報の登録を行う。
（２）アクセス認証
・ＭＮ１０はネットワーク３０へ移動すると、代理ノード３１に対してアクセス認証要求を送信する。
・代理ノード３１はＭＮ１０からのアクセス認証要求を受信すると、ＡＡＡ（Authentication, Authorization, Accounting）サーバ５０に対してＡＡＡリクエスト（request）でＭＮ認証要求を送信する。
・ＡＡＡサーバ５０は代理ノード３１からのＡＡＡリクエスト（ＭＮ認証要求）を受信すると、ＭＮ認証プロセスを実行して、代理ノード３１に対して、ＡＡＡリプライで認証ＯＫを通知する。
・代理ノード３１はＡＡＡサーバ５０からのＡＡＡリプライを受信すると、ＭＮ１０に対してアクセス認証完了を通知する。

（３）代理ノードによる位置情報登録
・ＭＮ１０は、アクセス認証が完了した後、移動前に接続していたネットワーク２０が外部ネットワークであったことを判断し、移動前に外部ネットワークに接続していたことを示す情報（以下、移動前外部ネットワーク接続情報）をＲＳメッセージに付加して代理ノード３１へ送信する。
・代理ノード３１は、ＭＮ１０からＲＳメッセージを受信すると、移動前外部ネットワーク接続情報がメッセージに含まれていることを確認し、その移動前外部ネットワーク接続情報を含む代理ＢＵメッセージをＨＡ３２へ送信する。
・ＨＡ３２は、代理ノード３１から代理ＢＵメッセージを受信すると、ＡＡＡサーバ５０に対してＡＡＡリクエストを送信し、ＡＡＡサーバ５０がＡＡＡリクエストを受信して、ＨＡ３２に対してＡＡＡリプライを送信することにより、代理ノード認証プロセスを実行する。なお、代理ノード３１の認証が不要な場合は、ＡＡＡリクエストの送信は省略してもよい。

・ＨＡ３２は、ＡＡＡサーバ５０からＡＡＡリプライを受信すると、ＢＵメッセージの中に移動前外部ネットワーク接続情報が存在することを確認し、新しい位置情報で置き換えるべき対象が、ＭＮ１０によって登録された位置情報であると判断する。そして、すでに登録されているＭＮ１０の位置情報の中から、ＭＮ１０自身によって登録された位置情報を特定して、それを新しい移動後の位置情報で置き換える。なお、ＭＮ１０の位置情報の中に、後述するＭＡＧ登録情報が付加されている位置情報があるかどうかを確認して、置き換える対象の位置情報を特定してもよい。そして、ＨＡ３２は、位置情報の登録の結果を含む代理ＢＡメッセージを代理ノード３１へ送信する。

なお、本発明の第７〜第８の実施の形態に示されているＭＮ１０が、ＨＡ３２が管理する複数の代理ノードに同時に接続している際には、本発明の第５、第６の実施の形態に示されているリンク識別子を利用した形態を用いて位置情報を特定することが可能である。
本発明の第８の実施の形態で述べたように、ＭＮ１０は、ネットワークベースの移動制御プロトコルが提供されていないネットワークから、提供されているネットワークへ移動した場合でも、代理ノードが、移動前にＭＮ１０が登録した位置情報を更新するために、ＭＮ１０から通知され移動前外部ネットワーク接続情報を、送信する代理ＢＵメッセージでＨＡへ通知することで、ＭＮ１０によって登録された位置情報を新たな位置情報で更新することが可能となる。

なお、上記実施の形態の説明に用いた各機能ブロックは、典型的には集積回路であるＬＳＩとして実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサー を利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適用などが可能性としてあり得る。

本発明は、モバイルノードが、ネットワークベースのプロトコルが提供されている第１のネットワークで初期起動などして、モバイルノードのバインディングＩＤが第１のネットワークの代理ノードに対して設定された後に、モバイルノードが、ネットワークベースのプロトコルが提供されていない第２のネットワークにハンドオーバした場合にバインディングＩＤを取得することができるという効果を有し、ネットワークベースのプロトコルが提供されていないネットワークとしてセルラなどの３ＧＰＰネットワークに、また、ネットワークベースのプロトコルが提供されているネットワークとしてワイヤレスＬＡＮなどのＮｏｎ３ＧＰＰネットワークに利用することができる。

本発明の第１の実施の形態並びに従来の技術におけるネットワークの構成を示すブロック図 本発明の第１の実施の形態における通信シーケンスを示す説明図 本発明の第１の実施の形態におけるモバイルノードの構成を示すブロック図 本発明の第１の実施の形態における代理ノードの構成を示すブロック図 本発明の第１の実施の形態におけるＡＡＡサーバの構成を示すブロック図 本発明の第２の実施の形態における通信シーケンスを示す説明図 本発明の第３の実施の形態における通信シーケンスを示す説明図 本発明の第３の実施の形態におけるモバイルノードの構成を示すブロック図 本発明の第３の実施の形態における代理ノードの構成を示すブロック図 本発明の第４の実施の形態におけるネットワークの構成を示すブロック図 本発明の第４の実施の形態における通信シーケンスを示す説明図 図１のネットワークの変形例を示すブロック図 図１のネットワークの他の変形例を示すブロック図 図３のＩＫＥリクエストメッセージ生成部の処理を説明するためのフローチャート 本発明の第１の実施の形態におけるホームエージェントの構成を示すブロック図 本発明の第５の実施の形態におけるネットワークの構成を示すブロック図 図１６のネットワークの変形例を示すブロック図 図１６のネットワークの他の変形例を示すブロック図 本発明の第５の実施の形態におけるＩＫＥリクエストメッセージ生成部の処理を説明するためのフローチャート 本発明の第５の実施の形態におけるネットワーク構成の具体例を示すブロック図 図２０のＬＭＡが保持するＭＮのバインディングキャッシュ・エントリ（ＢＣＥ）を示す説明図 本発明の第６の実施の形態におけるネットワークの構成を示すブロック図 本発明におけるＢＵメッセージのフォーマットの一例を示す説明図 本発明におけるＢＵメッセージのフォーマットの他の例を示す説明図 本発明の第７の実施の形態における通信シーケンスを示す説明図 本発明の第７の実施の形態におけるモバイルノードの構成を示すブロック図 本発明の第７の実施の形態におけるＲＳメッセージを示す説明図 本発明の第７の実施の形態におけるモバイルノードの処理を示すフローチャート 本発明の第７の実施の形態における代理ノードの構成を示すブロック図 本発明の第７の実施の形態におけるホームエージェントの構成を示すブロック図 本発明の第８の実施の形態における通信シーケンスを示す説明図

Claims (22)

1. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信方法であって、
   前記モバイルノードが、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信するステップと、
   前記代理ノードが、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信するステップと、
   前記管理ノードが、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信するステップと、
   前記代理ノードが、前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信するステップと、
   前記モバイルノードが、前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの前記管理ノードに対して前記バインディングＩＤの要求メッセージを送信するステップと、
   前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、
   前記管理ノードが、前記バインディングＩＤを前記モバイルノードに送信するステップとを、
   有する通信方法。
2. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続する前記モバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムであって、
   前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信する手段と、
   前記代理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信する手段と、
   前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信する手段と、
   前記代理ノードが前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信する手段と、
   前記モバイルノードが、前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの管理ノードに対して前記バインディングＩＤの要求メッセージを送信する手段と、
   前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、
   前記管理ノードが前記バインディングＩＤを前記モバイルノードに送信する手段とを、
   有する通信システム。
3. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースのプロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
   前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信する手段と、
   前記代理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信し、前記代理ノードが前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信した場合に、前記割り当て情報を受信する手段と、
   前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記割り当て情報に基づいて前記第１のネットワークの前記管理ノードに対して前記バインディングＩＤの要求メッセージを送信する手段と、
   前記管理ノードが前記モバイルノードからの前記バインディングＩＤの要求メッセージを受信して、前記管理ノードが前記バインディングＩＤを前記モバイルノードに送信した場合に、前記バインディングＩＤを受信する手段とを、
   備えたモバイルノード。
4. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
   前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ割り当て要求メッセージを送信した場合に、前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ割り当て要求メッセージを送信する手段と、
   前記管理ノードが前記バインディングＩＤ割り当て要求メッセージを受信して、前記バインディングＩＤを生成して記憶するとともに前記代理ノードに送信した場合に、前記バインディングＩＤを受信して、前記バインディングＩＤが割り当てられていることを示す割り当て情報を前記モバイルノードに対して送信する手段とを、
   備えた代理ノード。
5. 請求項１に記載の通信方法において、
   前記バインディングＩＤ割り当て要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであり、
   前記代理ノードが送信する前記バインディングＩＤが割り当てられていることを示す割り当て情報は、ＤＨＣＰリプライメッセージであることを特徴とする通信方法。
6. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信方法であって、
   前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信するステップと、
   前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信するステップと、
   前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信するステップと、
   前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信するステップとを、
   有する通信方法。
7. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムであって、
   前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
   前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信する手段と、
   前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信する手段と、
   前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信する手段とを、
   有する通信システム。
8. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
   前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
   前記代理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信し、前記代理ノードが前記バインディングＩＤを受信して前記モバイルノードに対して送信した場合、前記バインディングＩＤを受信する手段とを、
   有するモバイルノード。
9. ネットワークベースの移動制御プロトコルが提供されている第１のネットワークに接続するモバイルノードのバインディングＩＤが前記第１のネットワークの代理ノードに対して設定された後に、前記モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークにハンドオーバした場合に前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
   前記モバイルノードが、前記第１のネットワークで、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ要求メッセージを送信した場合、前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを管理する管理ノードに対して前記バインディングＩＤ要求メッセージを送信する手段と、
   前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して前記代理ノードに送信した場合、前記バインディングＩＤを受信して前記モバイルノードに対して送信する手段とを、
   有する代理ノード。
10. 請求項６に記載の通信方法において、
    前記バインディングＩＤ要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであり、
    前記代理ノードが送信する前記バインディングＩＤは、ＤＨＣＰリプライメッセージに含まれることを特徴とする通信方法。
11. モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信方法であって、
    前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信するステップと、
    前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶するステップと、
    前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信するステップと、
    前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信するステップと、
    前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信するステップとを、
    有する通信方法。
12. モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムであって、
    前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信する手段と、
    前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶する手段と、
    前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信する手段と、
    前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信する手段と、
    前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信する手段とを、
    有する通信システム。
13. モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムにおける前記モバイルノードであって、
    前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信する手段を備えて、前記管理ノードが前記バインディングＩＤ要求メッセージを受信して、前記バインディングＩＤを生成して記憶するようにし、
    前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信する手段を備えて、前記代理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信するようにしたモバイルノード。
14. モバイルノードが、ネットワークベースの移動制御プロトコルが提供されていない第２のネットワークでバインディングＩＤが指定された後に、ネットワークベースの移動制御プロトコルが提供されている第１のネットワークにハンドオーバした場合に前記第１のネットワークの代理ノードが前記バインディングＩＤを取得する通信システムにおける前記代理ノードであって、
    前記モバイルノードが、前記第２のネットワークで、前記第１のネットワークの前記バインディングＩＤを管理する管理ノードに対してバインディングＩＤ要求メッセージを送信し、前記管理ノードが前記バインディングＩＤ要求を受信して、前記バインディングＩＤを生成して記憶し、前記モバイルノードが、前記第２のネットワークから前記第１のネットワークにハンドオーバした場合に、前記第１のネットワークの前記代理ノードに対してバインディングＩＤ取得要求メッセージを送信した場合、前記バインディングＩＤ取得要求メッセージを受信して、前記管理ノードに対して前記バインディングＩＤ取得要求メッセージを送信する手段と、
    前記管理ノードが前記バインディングＩＤ取得要求メッセージを受信して、前記代理ノードに対して前記記憶したバインディングＩＤを送信した場合、前記バインディングＩＤを受信する手段とを、
    有する代理ノード。
15. 請求項１１に記載の通信方法において、
    前記バインディングＩＤ取得要求メッセージは、前記モバイルノードのアクセス認証を要求するメッセージであることを特徴とする通信方法。
16. 請求項６に記載の通信方法において、
    前記代理ノードが前記バインディングＩＤを前記モバイルノードに対して送信する場合、前記代理ノードが前記モバイルノードからのＤＨＣＰレスポンスメッセージに応答するＤＨＣＰリプライメッセージで送信することを特徴とする通信方法。
17. 請求項６に記載の通信方法において、
    前記代理ノードが前記バインディングＩＤを前記モバイルノードに対して送信する場合、前記代理ノードが前記モバイルノードからのアクセス認証要求メッセージに応答するアクセス認証完了メッセージで送信することを特徴とする通信方法。
18. ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信方法であって、
    前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信するステップと、
    前記バインディングアップデートメッセージを受信した前記管理ノードが、前記置換された位置情報に対応するバインディングＩＤを前記モバイルノードに送信するステップとを、
    有する通信方法。
19. ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムであって、
    前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信する手段と、
    前記バインディングアップデートメッセージを受信した前記管理ノードが、前記置換された位置情報に対応するバインディングＩＤを前記モバイルノードに送信する手段とを、
    備えた通信システム。
20. ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムにおける前記モバイルノードであって、
    前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報を管理する管理ノードに対して前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報を付加して送信する手段と、
    前記バインディングアップデートメッセージを受信した前記管理ノードから、前記置換された位置情報に対応するバインディングＩＤを受信する手段とを、
    備えたモバイルノード。
21. ネットワークベースの移動制御プロトコルが提供されている第１のネットワーク及びネットワークベースの移動制御プロトコルが提供されていない第２のネットワークに接続可能なモバイルノードの第１のインタフェースが、前記第１のネットワークに接続している際に代理ノードによって位置情報が登録された後に、前記モバイルノードの第１のインタフェースが第２のネットワークにハンドオーバした場合に前記位置情報を置換する通信システムにおいて前記位置情報を管理する管理ノードであって、
    前記モバイルノードの第１のインタフェースが前記第１のネットワークから前記第２のネットワークにハンドオーバした場合に、前記位置情報の置換を要求するバインディングアップデートメッセージを、移動前のネットワークがホームネットワークであったことを示す移動前ホームネットワーク接続情報と供に前記モバイルノードから受信する手段と、前記置換した位置情報に対応するバインディングＩＤを前記モバイルノードに送信する手段とを、
    備えた管理ノード。
22. 請求項１８に記載の通信方法において、
    前記モバイルノードはネットワークベースの移動制御プロトコルが提供されている第３のネットワークに接続可能な第２のインタフェースをさらに有し、前記第１のインタフェースが前記第１のネットワークから前記第２のネットワークへハンドオーバした際、前記第２のインタフェースが接続している前記第３のネットワークが前記第１のネットワークと同一のドメインである場合に、前記モバイルノードから送信される前記バインディングアップデートメッセージは、 前記モバイルノードの前記第１のインタフェースを特定する識別情報をさらに含むことを特徴とする通信方法。