JPWO2010073620A1 - ハンドオーバ方法、その方法で用いられる移動端末及びホームエージェント - Google Patents

Abstract

ハンドオーバ先のネットワークがホームリンクであることを早期に検出し、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減し通信効率を向上させるなどできるハンドオーバ方法などを提供する技術が開示され、その技術によれば移動端末１０７が、現在接続しているハンドオーバ前のアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、移動端末に割り当てられるハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージをハンドオーバ先のアクセスルータへ送信するステップと、移動端末のホームエージェント１０６が、アドレス取得要求メッセージによりハンドオーバ先のアドレス割り当てサーバ又はホームエージェントによって割り当てられた移動端末のアドレスの種別を示す情報を含む通知メッセージをハンドオーバ前のアクセスルータを介して移動端末へ送信するステップとを備える。

Description

本発明は、異なるＩＰバージョンに対応したネットワーク間を移動しながら通信を行う通信システムにおけるハンドオーバ方法、その方法で用いられる移動端末及びホームエージェント（位置管理サーバ）に関する。

従来の移動通信システムでは、インターネットプロトコル通信（ＩＰ通信）を行う移動端末の移動管理プロトコルとして、Mobile IPv4（ＭＩＰｖ４）あるいはMobile IPv6（ＭＩＰｖ６）があった。これら技術の詳細はそれぞれ下記の非特許文献１、非特許文献２に開示されている。また、従来、ＩＰｖ６をサポートするアクセスネットワークでしか動作しなかったＭＩＰｖ６をＩＰｖ４のみサポートするアクセスネットワークでも動作するように拡張したDual Stack Mobile IP（ＤＳＭＩＰ）があり、技術の詳細が非特許文献３に開示されている。

非特許文献２に基づくＭＩＰｖ６プロトコルでは、移動端末がホームエージェント（位置管理サーバ）にＩＰｖ６ホームアドレス（ＨｏＡｖ６）とＩＰｖ６気付けアドレス（ＣｏＡｖ６）を登録し、ホームエージェントにてそれらアドレスの関係性（バインディング）を管理するが、すべてのメッセージはＩＰｖ６プロトコルに基づくものであり、ＩＰｖ６をサポートするアクセスネットワークからしか利用することができなかった。ＤＳＭＩＰはＭＩＰｖ６を拡張したものであり、移動端末がＩＰｖ４のみサポートするアクセスネットワークに接続したときに、アクセスネットワークから取得したＩＰｖ４気付けアドレス（ＣｏＡｖ４）をＨｏＡｖ６とバインドさせてＩＰｖ４のみサポートするアクセスネットワークからもＨｏＡｖ６を用いた通信を可能とさせるものである。

また、ＤＳＭＩＰは、ホームエージェントがＩＰｖ４アドレスを有することを前提に、ＣｏＡｖ４とホームエージェントのＩＰｖ４アドレスをアドレスフィールドに記載したＩＰｖ４ヘッダでカプセリングすることでＭＩＰｖ６に基づくバインディング制御メッセージ（Binding Update（ＢＵ）あるいはBinding Acknowledge（ＢＡ）など）を交換可能としたり、ＩＰｖ４ホームアドレス（ＨｏＡｖ４）を移動端末に割り当ててＩＰｖ４アドレスのみ有する通信相手（Correspondent Node：ＣＮ）と通信を可能としたりするものである。

なお、ＩＰｖ４のみサポートするアクセスネットワークに接続した移動端末に対するＭＩＰｖ６に基づくバインディング管理を可能とする方法は下記の特許文献１にも開示されている。携帯電話による移動通信システムにおいても、同様の技術を用いたハンドオーバ方法が検討されている。下記の非特許文献４では、ＤＳＭＩＰを用いて３ＧＰＰアクセスネットワーク（ＬＴＥなど）から非３ＧＰＰアクセスネットワーク（無線ＬＡＮネットワークシステム、ＷｉＭＡＸネットワークシステム、３ＧＰＰ２ネットワークシステムなど）へのハンドオーバ方法が開示されている。

上記従来技術において、移動端末はホームアドレスＨｏＡｖ６が属するＩＰｖ６ホームプレフィクスを対象にしたホームリンク検出しか行ってこなかった。つまり、ＩＰｖ４アドレスを用いたホームリンク検出は行わず、アクセスネットワークから取得したＩＰｖ４アドレス（ＣｏＡｖ４に相当）のサブネットとＨｏＡｖ４のサブネットが同じであっても、アクセスネットワークから取得したＩＰｖ６プレフィクスとＩＰｖ６ホームプレフィクスが同じでない限り、そのアクセスネットワークはホームリンクとはみなさなかった。

したがって、実際にはＩＰｖ４サブネットの観点でホームリンクとなり得る場合であっても、移動端末がＨｏＡｖ４を用いる場合はすべてのパケット（バインディング制御メッセージ、ユーザデータ）にＩＰｖ４トンネルヘッダを余計に付加する必要があった。これにより、ヘッダオーバヘッドが増加して、特に限られた通信帯域を複数の移動端末によって共有する無線通信システムにおいては通信効率が低下するという問題があった。

ここで、図１、１３を用いて従来の移動通信システムにおける課題について詳しく説明する。図１はＤＳＭＩＰを用いた移動通信システムの一例の構成図であり、ＩＰｖ６をサポートするアクセスネットワーク１０１、ＩＰｖ４のみサポートするアクセスネットワーク１０２、それらアクセスネットワーク経由で接続可能なコアネットワーク１０３が配置されている。各々のアクセスネットワークには、アクセスルータＡＲ１０４、ＡＲ１０５が配備され、アクセスネットワークシステムのオペレーションによってＩＰｖ６ルータであったり、ＩＰｖ４ルータであったりする。

コアネットワーク１０３には、ＤＳＭＩＰに基づくホームエージェントＨＡ１０６が配備される。移動端末ＵＥ１０７はアクセスネットワーク１０１経由でＨＡ１０６と接続してＩＰｖ６ホームアドレス（ＨｏＡｖ６）を取得した後、アクセスネットワーク１０２に移動し、ハンドオーバ処理を実施する。

図１３は従来のハンドオーバ処理手順の一例を説明するためのシーケンスチャートである。移動端末ＵＥ１０７がアクセスネットワーク１０２へのハンドオーバ処理の開始を検出する（ステップＳ１３０１）と、アタッチ処理を開始する（ステップＳ１３０２）。アタッチ処理は認証サーバＨＳＳ／ＡＡＡ１３０１による接続認証処理（ステップＳ１３０３）を含み、接続が許可されるとアタッチ処理が完了する。続いてＵＥ１０７はＤＨＣＰプロトコルを用いるなどしてＩＰｖ４アドレスを取得し（ＩＰｖ４アドレス取得要求、ＩＰｖ４アドレス割り当て：ステップＳ１３０４、Ｓ１３０５）、これを気付けアドレス（ＣｏＡｖ４）として先に取得してあるＨｏＡｖ４とともにＨＡに登録するためのバインディング要求メッセージ（Binding Update：ＢＵ）を送信する（ステップＳ１３０６）。

このとき、ＵＥ１０７はＢＵを用いて、ＤＳＭＩＰプロトコルに基づくＩＰｖ４ホームアドレス（ＨｏＡｖ４）割り当て要求を実施する。ＨＡ１０６はＨｏＡｖ４割り当て要求付きのＢＵを受信すると、ＨｏＡｖ６とＣｏＡｖ４の組をバインディングキャッシュに登録し、ＨｏＡｖ４を割り当てるためバインディング応答メッセージ（Binding Acknowledge：ＢＡ）を用いてＵＥ１０７に通知する（ステップＳ１３０７）とともに、ＨｏＡｖ４とＣｏＡｖ４の組をバインディングキャッシュに登録する。

ここで、ＵＥ１０７は、取得したＨｏＡｖ４とＣｏＡｖ４のサブネット部を比較することにより、従来実施していなかったＩＰｖ４サブネットの観点でホームリンク検出を行う（ステップＳ１３０８）ことができる。その結果、ＨｏＡｖ４とＣｏＡｖ４のサブネット部が一致する場合は、そのアクセスネットワーク１０２をＩＰｖ４観点でのホームリンクとみなすことができ、ＨＡ１０６と交換するパケットに冗長なＩＰｖ４トンネルヘッダを付与する必要がなくなる。

もし、サブネット部が一致しなかった場合は、アクセスネットワーク１０２はホームリンクではないので、ＨＡ１０６と交換するすべてのパケットにＩＰｖ４トンネルヘッダを付与する必要がある。なお、従来はＩＰｖ４観点のホームリンク検出を行っていなかったので、ＨＡ１０６と交換するすべてのパケットにＩＰｖ４トンネルヘッダを付与していた。

ここで、好ましくはすべての場合においてＩＰｖ４トンネルヘッダを付与させることなく、ヘッダオーバヘッドを削減することである。多くの無線通信システムにおいては、移動端末とＡＲ間のリンクはポイントツーポイントリンクで構成されるので、１つのＡＲが複数の移動端末を収容する場合であっても、それぞれの移動端末に異なるサブネットに属するＩＰｖ４アドレスを配布することが可能となる。

また、移動端末は、ＣｏＡｖ４を取得してからＢＵ送信するまでにＨＡとの間で図１３に示すような鍵更新処理を行うことがある。例えば、動的鍵更新をサポートしていない移動端末は、気付けアドレスが変更される都度、鍵更新をしなければならない。鍵更新は移動端末、ＨＡ双方において暗号計算を伴う長時間の処理が必要とされるため、移動端末がＩＰｖ４観点のホームリンク検出を完了して実際にパケットを送受信できるまで相当の時間を要することになる。

特許文献２では、上記問題を解決するために、移動端末がＰＭＩＰプロトコルをサポートするアクセスネットワークに接続するときに、アタッチポイントであるＭＡＧ（ＡＲ１０５に相当）が、移動端末から端末能力情報を取得する。さらにＭＡＧは、取得した端末能力情報をもとに、ネットワークが移動端末に提供するモビリティプロトコル（ＤＳＭＩＰ、ＰＭＩＰ、ＭＩＰｖ４など）を決定し、決定したプロトコルに基づくＩＰ設定情報を移動端末に通知する。移動端末は、通知されたＩＰ設定情報などをもとに決定されたモビリティプロトコルを知ることができる。決定されたモビリティプロトコルがＰＭＩＰである場合は、併せて取得したＩＰアドレスがホームアドレスであると認識することができる。

特開２００５−７３２７１号公報（要約） 国際公開２００８−９９８０２号公報（要約）

C.Perkins "IP Mobility Support for IPv4", IETF RFC3344 August 2002 D.Johnson, C.Perkins, J.Arkko "Mobility Support in IPv6", IETF RFC3775 June 2004 Hesham soliman "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-05.txt July 2008 "Architecture enhancements for non-3GPP accesses (Release8)", 3GPP TS23.402 v.8.2.0 p.136-139 June 2008

しかしながら、上記従来技術においてはホームアドレスを取得したことを知るきっかけとなる通知は、接続処理中あるいは接続したばかりのハンドオーバ先アクセスネットワーク（上記特許文献２ではＭＡＧ）から直接取得するものである。ここで、移動端末のハンドオーバ先アクセスネットワークは、様々なアクセスタイプやネットワークシステムに相当し、管理運用するオペレータも一様ではないことが想定される。つまり、移動端末は、これから接続しようとするすべてのアクセスネットワークにおいて、上記の通知を取得できると期待することは、特にシステムの導入初期においては旧来システムの総入れ替えが発生することから現実的に不可能といえる。移動端末は様々なアクセスネットワークに接続しながらも、共通の手順により所望のコアネットワークリソースをあまねく享受できるという次世代ネットワークの目指す姿を実現するためには、移動端末が多種多様な管理運用ポリシを制約とすることなく、平等にサービスを受けられる環境を提供しなくてはならない。

このように、ＷｉＭＡＸやＷＬＡＮ、３ＧＰＰ、３ＧＰＰ２など、世界中のすべてのアクセスネットワークで上記のような通知機能がサポートされていることを期待するのは、多様な管理運用ポリシの観点から、ほぼ不可能と考えてもよく、そうした場合にも、移動端末がＩＰｖ４観点のホームリンク検出を早期に完了できる方法が必要となる。

本発明は、上記の問題点に鑑み、ＤＳＭＩＰを用いた移動通信システムにおいて、ＩＰｖ６ホームアドレスのみ有する移動端末がＩＰｖ４のみサポートするアクセスネットワークにハンドオーバする際に、ハンドオーバ先のネットワークで移動端末に割り当てられたＩＰアドレスの種別（ホームアドレス又はケアオブアフドレス）を、ホームエージェントがハンドオーバ元のネットワーク経由で移動端末に通知し、移動端末は通知取得タイミングに応じてホームリンク検出を行う。これにより、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェント間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができるハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントを提供することを目的とする。

上記目的を達成するために、本発明によれば、移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間を移動する前記移動端末のハンドオーバ方法であって、前記移動端末が、現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージを前記ハンドオーバ先のアクセスルータへ送信するステップと、前記移動端末のホームエージェントが、前記アドレス取得要求メッセージにより前記ハンドオーバ先のアクセスルータ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを前記ハンドオーバ前のアクセスルータを介して前記移動端末へ送信するステップとを、備えるハンドオーバ方法が提供される。この構成により、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。

また、本発明によれば、移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間をハンドオーバする前記移動端末であって、前記移動端末が、現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージを生成するメッセージ生成手段と、生成された前記アドレス取得要求メッセージを前記ハンドオーバ先のアクセスルータへ送信する送信手段と、前記アドレス取得要求メッセージにより前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを、前記移動端末のホームエージェントから前記ハンドオーバ前のアクセスルータを介して受信する受信手段とを、備える移動端末が提供される。この構成により、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。

また、本発明によれば、移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間をハンドオーバする前記移動端末のホームエージェントであって、前記移動端末が現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージに基づき、前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを生成するメッセージ生成手段と、生成された前記通知メッセージを前記ハンドオーバ前のアクセスルータを介して前記移動端末へ送信する送信手段とを、備えるホームエージェントが提供される。この構成により、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。

本発明のハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントは、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。また、ハンドオーバ元アクセスネットワーク経由で既に確立されたＤＳＭＩＰコネクションを利用することにより、ハンドオーバ先アクセスネットワークが移動端末に直接通知する機能を有していない場合でも、所望の動作を実施させることができる。

本発明の実施の形態における通信システムの構成の一例を示す構成図 本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャート 本発明の実施の形態におけるハンドオーバ方法の一例を説明するための他のシーケンスチャート 本発明の実施の形態におけるハンドオーバ方法の一例を説明するための他のシーケンスチャート 本発明の実施の形態におけるハンドオーバ方法の一例を説明するための他のシーケンスチャート 本発明の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の実施の形態に係る移動端末における処理フローの一例を示すフローチャート 本発明の実施の形態に係る移動端末における他の処理フローの一例を示すフローチャート 本発明の実施の形態に係る移動端末における他の処理フローの一例を示すフローチャート 本発明の実施の形態に係るホームエージェントの構成の一例を示す構成図 本発明の実施の形態に係るホームエージェントにおける処理フローの一例を示すフローチャート 本発明の実施の形態に係るホームエージェントにおける他の処理フローの一例を示すフローチャート 従来技術を説明するための図

本発明の実施の形態の詳細な動作について説明する。図１は本発明によるシステム構成を説明するための図であり、少なくともＩＰｖ６をサポートするアクセスネットワーク１０１、ＩＰｖ４のみサポートするアクセスネットワーク１０２、それらアクセスネットワーク経由で接続可能なコアネットワーク１０３が配置される。各々のアクセスネットワークには、アクセスルータＡＲ１０４、ＡＲ１０５が配備され、アクセスネットワークシステムのオペレーションによってＩＰｖ６ルータであったり、ＩＰｖ４ルータであったり、またその双方であったりする。また、コアネットワーク１０３には、移動端末１０７の接続要求に応じて、システム全体のＱｏＳ（Quality of Service）などに関する制御を実施するＰＣＲＦ（Policy Control and Charging Rules Function）サーバ１０８が配備される。

さらに詳細には、アクセスネットワークが採用する規格に応じて、アクセスルータは、アクセスゲートウェイ（Access Gateway：ＡＧＷ）、モビリティアンカーゲートウェイ（Mobility Anchor Gateway：ＭＡＧ）、パケットデータゲートウェイ（Packet Data Gateway：ＰＤＧ、enhanced Packet Data Gateway：ｅＰＤＧ）、サービングゲートウェイ（Serving Gateway：ＳＧＷ）、サービングＧＰＲＳサービングノード（Serving GPRS Serving Node：ＳＧＳＮ）などと称されることもある。また、コアネットワーク１０３には、ＤＳＭＩＰに基づくホームエージェント（ＨＡ）１０６が配備され、コアネットワーク１０３が採用する規格に応じて、このＨＡ１０６はパケットデータネットワークゲートウェイ（Packet Data Network Gateway：ＰＤＮ ＧＷ）、ゲートウェイＧＰＲＳサービングノード（Gateway GPRS Serving Node：ＧＧＳＮ）などと称されることもある。

図１において、移動端末ＵＥ１０７はアクセスネットワーク１０１経由でＨＡ１０６と接続してＩＰｖ６ホームアドレス（ＨｏＡｖ６）を取得した後、アクセスネットワーク１０２に移動し、ハンドオーバ処理を実施する。

図２は、本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャートである。移動端末ＵＥ１０７がアクセスネットワーク１０２へのハンドオーバ処理開始を検出する（ステップＳ２０１）と、ＵＥ１０７はアクセスネットワーク１０２のアタッチポイント（ここではＡＲ１０５）に対してアタッチ処理を開始する（ステップＳ２０２）。ＡＲ１０５は、アタッチ処理の過程で、ＵＥ１０７に対する接続認証処理をＨＳＳ／ＡＡＡ１３０１に依頼する（ステップＳ２０３）。接続認証処理が成功すると、ＡＲ１０５は付随する処理を実施してアタッチ処理を完了する。

アタッチ処理を通じてＩＰアドレスが割り当てられなかった場合やネットワークから指示された場合、ＵＥ１０７はＤＨＣＰなどのプロトコルを用いてＩＰｖ４アドレスを取得する。すなわち、ＵＥ１０７はＩＰｖ４アドレス取得要求メッセージをＡＲ１０５に送信する（ステップＳ２０４）。ここで、要求されたＩＰアドレスをコアネットワーク１０３が割り当てる場合、すなわちＡＲ１０５においてＤＨＣＰ Ｒｅｌａｙ（リレー）機能が有効に設定されている場合、ＩＰｖ４アドレス取得要求メッセージはＡＲ１０５からＨＡ１０６に転送される。ＨＡ１０６は要求を受けてホームアドレスを割り当て（ステップＳ２０５）、ＩＰｖ４アドレス割り当てメッセージを用いてＵＥ１０７に通知する（ステップＳ２０６）。

また、ＡＲ１０５がＭＡＧの機能を有しており、ＰＭＩＰプロトコルによってＨＡ１０６との間のモビリティ機能を実現している場合は、ＵＥ１０７からのＩＰｖ４アドレス取得要求メッセージを受けてＡＲ１０５（ＭＡＧ）がＰＢＵ（Proxy Binding Update）メッセージをＨＡ１０６に発行することがある。この場合も、ＨＡ１０６は同様にホームアドレスを割り当て、ＰＢＵへの応答であるＰＢＡ（Proxy Binding Ack）メッセージを用いてＡＲ１０５に通知し、ＡＲ１０５がＩＰｖ４アドレス割り当てメッセージを用いて割り当てられたホームアドレスをＵＥ１０７に通知する。

ここで、ＨＡ１０６は受信したアドレス取得要求メッセージがＵＥ１０７からのものであることを次のようにして認識する。ＡＲ１０５はアタッチ処理時に取得したＵＥ１０７の識別子（例えば、Network Access Identifier：ＮＡＩ）を、アタッチ処理によって確立された通信ベアラ（例えば３ＧアクセスシステムではベアラＩＤが割り当てられるように）と関連付けて保存する。ＵＥ１０７が送信するアドレス取得要求メッセージは、アタッチ処理によって確立された通信ベアラ上で転送されるので、ＡＲ１０５は受信したアドレス取得要求メッセージがＵＥ１０７から送信されたものであることを識別し、先に保存しておいたＵＥ１０７の識別子（例えばＮＡＩ）を取得する。

ＡＲ１０５は、アドレス取得要求メッセージあるいはＰＢＵにＵＥ１０７の識別子（ＮＡＩ）を記載した上でＨＡ１０６に転送あるいは送信する。ＤＨＣＰメッセージには、ＮＡＩを記載するための“client field”が用意されており、ＰＢＵにも同様にＮＡＩを記載するためのオプションが用意されている。ＨＡ１０６はＵＥ１０７の識別子（ＮＡＩ）が記載されたメッセージを取得して、ＵＥ１０７から送信されたものであることを認識することができる。あるいはＵＥ１０７がメッセージに自信の識別子を含めて送信することにより、ＡＲ１０５で識別を行う必要がなくなる。

ＨＡ１０６は、割り当てたＩＰアドレスをＵＥ１０７に通知するのと同時に、既に接続を確立済みのＵＥ１０７に対するＤＳＭＩＰバインディング情報（バインディングキャッシュに蓄積されたホームアドレスとケアオブアドレスをはじめとする情報）を用いて、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージを送信し（ステップＳ２０７）、割り当てたＩＰアドレスがホームアドレスであることを通知する。割り当てアドレス種別通知メッセージは、例えばBinding Revocation RequestやBinding Refresh Request、Binding Ackなどを用いてもよいし、独自のメッセージを用いてもよい。

また、割り当てアドレス種別通知メッセージに割り当てたホームアドレスの値を記載してもよいが、単にホームアドレスかケアオブアドレスかのフラグ（少なくとも１ビット）を添付するようにしてもよい。フラグのみ送信することにより、アドレスの値を送る場合に比べて、少ないビット数で所望の情報をＵＥ１０７に通知することができ、通信リソースを有効活用することができる。

割り当てアドレス種別通知メッセージを取得したＵＥ１０７は、ハンドオーバ先アクセスネットワークで取得したＩＰアドレスがホームアドレスである、すなわちハンドオーバ先アクセスネットワークがホームリンクであると認識する。すなわち、本来続けて行われるバインディング処理（ＢＵ／ＢＡ交換）の中で取得するホームアドレスと先に取得したアドレスのサブネットの一致検査、すなわちホームリンク検出を省略することができ、特にバインディング処理の前に鍵更新処理を実施する必要がある場合は、鍵交換処理を省略あるいは遅延させることができ、ハンドオーバ時間の削減を図ることができる。なぜなら、鍵更新処理はＢＵ／ＢＡ交換を行う前に実施する必要がある（ＢＵ／ＢＡを保護するためのＩＰｓｅｃ鍵を更新するのが目的であるため）が、ＢＵ／ＢＡ交換を省略できるようになるので鍵更新処理をハンドオーバ処理完了後、任意のタイミングで実施できるようになるためである。

なお、ＡＲ１０５がＭＡＧの機能を有しており、ＨＡ１０６との間のモビリティ機能がＰＭＩＰプロトコルによって実現されており、アタッチ処理の過程でＨＡ１０６とＭＡＧの間でＰＢＵ／ＰＢＡが既に交換されている場合がある。さらにこのとき、割り当てられたＩＰアドレスがアタッチ処理の過程でＵＥ１０７に通知されている場合と、割り当てられたＩＰアドレスはＭＡＧが保有した状態でアタッチ処理の過程でＵＥ１０７に通知されていない場合とがある。後者の場合、続けて実施されるＤＨＣＰなどを用いたアドレス取得処理によって、割り当てアドレスがＵＥ１０７に通知される。

これらのケースでは、いずれもＨＡ１０６によるホームアドレス割り当てはアタッチ処理の過程で実施されている。したがって、ＨＡ１０６はアタッチ処理の過程で実施されるホームアドレス割り当ての完了と同時に割り当てアドレス種別通知メッセージを送信することが可能となり、ＵＥ１０７においてもアタッチ処理を行っている最中あるいはアタッチ処理の完了とほぼ同じタイミングでアドレス種別通知をハンドオーバ元アクセスネットワーク経由で取得することができる。なお、ＵＥ１０７は、アドレス種別通知メッセージを通じて割り当てアドレスの値を教えてもらうこともでき、アタッチ処理の過程でアドレスが通知されなかった場合にＤＨＣＰなどを用いたアドレス取得処理が不要となる。

次に、ハンドオーバ先アクセスネットワークにおいてケアオブアドレスが割り当てられる場合の動作について説明する。図３は、本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャートである。移動端末ＵＥ１０７がアクセスネットワーク１０２へのハンドオーバ処理開始を検出する（ステップＳ３０１）と、ＵＥ１０７はアクセスネットワーク１０２のアタッチポイント（ここではＡＲ１０５）に対してアタッチ処理を開始する（ステップＳ３０２）。ＡＲ１０５は、アタッチ処理の過程で、ＵＥ１０７に対する接続認証処理をＨＳＳ／ＡＡＡ１３０１に依頼する（ステップＳ３０３）。接続認証処理が成功すると、ＡＲ１０５は付随する処理を実施してアタッチ処理を完了する。

ここでは、割り当てるアドレスがホームアドレス（ＨｏＡ：Home Address）ではなくケアオブアドレス（ＣｏＡ：Care-of Address）、すなわちアクセスネットワーク１０２が独自にアドレスを割り当てることができるため、ＵＥ１０７が送信するＩＰアドレス取得要求メッセージ（ステップＳ３０４）は、アクセスネットワーク１０２内のサーバ（例えばＤＨＣＰサーバ：ＡＲ１０５内に併設されることもあり、以下ではそのケースについて説明する）で処理される。すなわち、ＵＥ１０７にケアオブアドレスが割り当てられる（ステップＳ３０５）。ＵＥ１０７にケアオブアドレスが割り当てられると、後にＵＥ１０７がバインディングを行ったときのＱｏＳポリシ適用に備えて（ひいてはコアネットワークリソースを用いた通信を可能とするために）、割り当てられたケアオブアドレスをＡＲ１０５がＰＣＲＦサーバ１０８に通知する（ステップＳ３０６：ＣｏＡ通知メッセージ）。ＣｏＡ通知メッセージは、Gateway Control Session Establishment、Gateway Control and QoS Rules Request、Gateway Control and QoS Rules Provisionなどともよぶ。また、ＡＲ１０５がローミングネットワークに配置される場合、すなわちＵＥ１０７がローミングネットワークにアタッチした場合、ＣｏＡ通知メッセージはローミングネットワークに配置されたプロキシＰＣＲＦサーバに配送され、コアネットワーク１０３のＰＣＲＦサーバ１０８に転送される。

ＣｏＡ通知メッセージを受信したＰＣＲＦサーバ１０８は、ＨＡ１０６が割り当てアドレス種別通知メッセージをＵＥ１０７に送信できるよう、受信したＣｏＡ通知メッセージをＨＡ１０６に転送、あるいは単にＵＥ１０７にケアオブアドレスが割り当てられたことをＨＡ１０６に通知する（ステップＳ３０７：ＣｏＡ通知）。すなわち、ハンドオーバ先のＡＲ１０５によってＵＥ１０７のケアオブアドレスが割り当てられた場合、ＨＡ１０６が、ハンドオーバ先のＡＲ１０５によって割り当てられたアドレスの種別を示す情報をＰＣＲＦ１０８から受信する。これを受けて、ＨＡ１０６はハンドオーバ元アクセスネットワーク経由で、ＵＥ１０７に割り当てアドレス種別通知メッセージを送信し（ステップＳ３０８）、ケアオブアドレスが割り当てられたことを通知する。

ここで、ＰＣＲＦサーバ１０８及びＨＡ１０６は、受信したアドレス取得要求メッセージがＵＥ１０７からのものであることを次のようにして認識する。ＡＲ１０５はアタッチ処理時に取得したＵＥ１０７の識別子（例えば、Network Access Identifier：ＮＡＩ）を、アタッチ処理によって確立された通信ベアラ（３ＧアクセスシステムではベアラＩＤが割り当てられる）と関連付けて保存する。ＵＥ１０７が送信するアドレス取得要求メッセージは、アタッチ処理によって確立された通信ベアラ上で転送されるので、ＡＲ１０５は受信したアドレス取得要求メッセージがＵＥ１０７から送信されたものであることを識別し、先に保存しておいたＵＥ１０７の識別子（例えばＮＡＩ）を取得する。

ＡＲ１０５は、アドレス取得要求メッセージあるいはＰＢＵにＵＥ１０７の識別子（ＮＡＩ）を記載した上でＨＡ１０６に転送あるいは送信する。ＤＨＣＰメッセージには、ＮＡＩを記載するための“client field”が用意されており、ＰＢＵでも同様にＮＡＩを記載するためのオプションが用意されている。ＰＣＲＦサーバ１０８及びＨＡ１０６はＵＥ１０７の識別子（ＮＡＩ）が記載されたメッセージを取得して、ＵＥ１０７から送信されたものであることを認識することができる。あるいは、ＵＥ１０７がメッセージに自身の識別子を含めて送信することにより、ＡＲ１０５で識別を行う必要がなくなる。

ケアオブアドレスが割り当てられたことを認識したＵＥ１０７は、取得したケアオブアドレスをＨＡ１０６に登録して、外部リンクにおける通信を開始する。このとき、ＩＰｖ４ホームアドレスを取得していない場合は、ＨＡ１０６とのバインディング処理（ＢＵ／ＢＡ交換：ステップＳ３０９、Ｓ３１０）の過程で新規に取得する必要があるが、先に取得した割り当てアドレス種別通知メッセージを利用してＩＰｖ４ホームアドレスをＨＡ１０６から通知してもらうことも可能である。その際、ＵＥ１０７はバインディング手順などを通じて（すなわちBinding Updateメッセージを用いるなどして）ＨＡ１０６にあらかじめ通知を要求しておいてもよい。

また、ＵＥ１０７がハンドオーバ先アクセスネットワークへのアタッチ処理と同時に、ハンドオーバ元アクセスネットワーク経由で要求メッセージ（例えばＩＰｖ４ホームアドレスを要求するフラグを付加したＢＵメッセージ）をＨＡ１０６に送っておき、ＨＡ１０６はその応答として割り当てアドレス種別通知メッセージ（例えばＩＰｖ４ホームアドレスを記載したＢＡメッセージ）をＵＥ１０７に送信するものであってもよい。これによって、アタッチ処理ないしアドレス取得処理と併行してホームアドレスを取得して、その後のバインディング処理を不要とすることができ、ハンドオーバ全体時間の削減を図ることができる。

なお、ここでもアタッチ処理時にケアオブアドレスがＵＥ１０７に通知されることがある。この場合、ＡＲ１０５からＰＣＲＦサーバ１０８へのＣｏＡ通知メッセージの送信はアタッチ処理の過程で実施されている。したがって、ＨＡ１０６はアタッチ処理の過程でＰＣＲＦサーバ１０８から転送あるいは通知された内容（ＵＥ１０７にＣｏＡが割り当てられたこと）を受けて、割り当てアドレス種別通知メッセージを送信することが可能となる。これにより、ＵＥ１０７においても、アタッチ処理を行っている最中あるいはアタッチ処理の完了とほぼ同じタイミングで、アドレス種別通知をハンドオーバ元アクセスネットワーク経由で取得することができる。なお、ＵＥ１０７は既にＩＰアドレスを取得済みであるので、ＤＨＣＰなどを用いたＩＰアドレス取得要求を送信する必要はない。

ここで、上記説明では、ＡＲ１０５がＣｏＡ通知メッセージを送信する宛先ノードをＰＣＲＦサーバ１０８としたが、例えばＨＳＳ／ＡＡＡサーバ１３０１などのその他のノードであってもよいし、ＨＡ１０６に直接ＣｏＡ通知メッセージあるいは相当の情報を含むメッセージを送信するものであってもよい。

以上、ＨＡ１０６はＵＥ１０７に割り当てられたアドレス種別（ホームアドレスあるいはケアオブアドレス）を、既に確立された通信コネクション（すなわちハンドオーバ元アクセスネットワークのＤＳＭＩＰバインディングコネクション）を利用してＵＥ１０７に通知することで、アクセスネットワークがＵＥ１０７に直接通知する手段を実装していない場合でも、迅速なホームリンク検出を可能とさせることができる。

さて、ＨＡ１０６は割り当てアドレスの種別に関する情報を、それぞれ異なるルートから取得する。つまり、ホームアドレスを割り当てたことは自分自身から、ケアオブアドレスを割り当てたことはＰＣＲＦサーバ１０８などのサーバを介してハンドオーバ先アクセスネットワークに位置するＡＲ１０５から取得する。

ＣｏＡ割り当て通知は、実際にアドレスが割り当てられてからＰＣＲＦサーバ１０８を経由してＨＡ１０６に配送されるため、ホームアドレス（ＨｏＡ）割り当て通知に比べて、ＵＥ１０７が通知を取得するまでに多くの配送時間を要することが想定される。すなわち、ＩＰアドレス取得にＤＨＣＰを用いる場合、ＨｏＡ割り当て通知（割り当てアドレス種別通知メッセージ（ＨｏＡ））はＤＨＣＰ処理完了直後に配送され得るのに対して、ＣｏＡ割り当て通知（割り当てアドレス種別通知メッセージ（ＣｏＡ））は、ＤＨＣＰ処理完了してからしばらく後にＵＥ１０７に到着するものと想定される。

ＵＥ１０７はこの特性を利用して、割り当て通知の到着タイミングを以て、ＨｏＡ／ＣｏＡいずれのアドレスが割り当てられたかを判定することもできる。つまり、ＵＥ１０７の例えばホームリンク判定制御部６０７は、ＤＨＣＰ処理完了直後に割り当てアドレス種別通知メッセージを受信できた場合はＨｏＡが、通知を受信できなかった場合はＣｏＡが割り当てられたものと判断することができ、特にＣｏＡ割り当て時のメッセージ待ち時間を削減して、ハンドオーバ処理のさらなる高速化を図ることができる。この際、後述するように、ＨＡ１０６がＨｏＡ割り当て通知をハンドオーバ元アクセスネットワーク経由で送信したことをＵＥ１０７に通知するようにしてもよい。すなわち、ＨＡ１０６が、割り当てアドレス種別通知メッセージの他に、ＵＥ１０７に割り当てられたアドレスの種別が何かを示す情報を含むメッセージをＵＥ１０７に送信し、ＵＥ１０７が受信するようにしてもよい。

しかしながら、上記の方法、すなわちＨＡ１０６からの割り当てアドレス種別通知メッセージの受信タイミングによってＨｏＡとＣｏＡのいずれかが割り当てられたかを判定するためには、ＵＥ１０７においてＤＨＣＰ処理完了時点を起点とする割り当てアドレス種別通知メッセージの受信タイミングを検出するためのタイマを新規に設置する必要がある。そこで、本発明ではＨＡ１０６におけるＨｏＡ割り当て通知の送信タイミングを最適化することにより、ＵＥ１０７が通知メッセージを受信したタイミングから通知内容を確実に判定可能な方法を開示する。

図４は本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャートである。本発明では、ＤＨＣＰによるＩＰアドレス割り当て処理が２往復分のシーケンスによって構成されていることに着目する。すなわち、従来のＤＨＣＰシーケンスは、ＤＨＣＰディスカバリー（ＵＥ→ＨＡ：ステップＳ４０１）、ＤＨＣＰオファー（ＨＡ→ＵＥ：ステップＳ４０２）、ＤＨＣＰリクエスト（ＵＥ→ＨＡ：ステップＳ４０３）、ＤＨＣＰアック（ＨＡ→ＵＥ：ステップＳ４０４）の順に実施されるものである。３ＧＰＰなどのセルラシステムにおいては、ＵＥ１０７にアドレスを割り当てるＤＨＣＰサーバ（ここではＨＡ１０６と同等）はＵＥ１０７に対して一つに決まるという特徴がある。したがって、ＨＡ１０６ではＤＨＣＰオファー送信時点でＵＥ１０７に割り当てるホームアドレスが既に決定しているので、ＤＨＣＰオファー送信と同時にＨｏＡ割り当て通知を送信することが可能である。すなわち、ＨＡ１０６が、ＤＨＣＰによるＤＨＣＰディスカバリーに対する応答メッセージであるＤＨＣＰオファーと同時に、ＨｏＡ割り当て通知のメッセージをＵＥ１０７に送信することが可能である。

これにより、ＨＡ１０６が送信するＨｏＡ割り当て通知は、ＤＨＣＰ処理中にＵＥ１０７に配送される（割り当てアドレス種別通知メッセージ：ステップＳ４０５）。したがって、割り当てアドレス種別通知メッセージをＤＨＣＰ処理完了までに受信できなかった場合は、ＣｏＡが割り当てられたと判断することができる。すなわち、ＵＥ１０７に新たなタイマを設けることなく、早期（ＤＨＣＰ処理が完了するまで）にＨｏＡあるいはＣｏＡのいずれかが割り当てられたかを検出できるようになり、ハンドオーバ時間の更なる短縮を図ることができる。

しかしながら、上記の最適化方法においては、ハンドオーバ元アクセスネットワークの混雑状況などにより、ＨｏＡ割り当て通知が遅れてＵＥ１０７に配送されることが考えられる。その場合、ＵＥ１０７はＣｏＡが割り当てられたものと誤認し、ハンドオーバ先アクセスネットワーク経由で鍵交換処理やＢＵ／ＢＡ交換を開始してしまう。こうした問題を解決するために、以下の２通りの方法が考えられる。

１つ目の方法は以下のようなものである。ハンドオーバ先アクセスネットワーク経由の鍵交換処理あるいはＢＵ／ＢＡ交換時に、ＨＡ１０６がＨｏＡ割り当て通知をハンドオーバ元アクセスネットワーク経由で送信したことをＵＥ１０７に通知する。しかし、鍵交換処理やＢＵ／ＢＡ交換処理時にＨｏＡ割り当て通知を送信したことを伝えるためのプロトコルを、ハンドオーバ先アクセスネットワークにおいてサポートしている必要がある。また、割り当てアドレスが実際にはＨｏＡであった場合に、ＵＥ１０７は最悪の場合、数秒にものぼる鍵交換処理の完了や一往復分のＢＵ／ＢＡ交換の完了を待つ必要がある。

２つ目の方法は以下のようなものである。ＤＨＣＰ処理完了後、ＨＡ１０６からのＨｏＡ割り当て通知を受けるかもしれないので、ＵＥ１０７はタイマを起動して所定時間待つ。しかし、ＵＥ１０７は新規にタイマを実装する必要があり、使用リソースを増加させることになる（バッテリ消費量の増大などが懸念される）。

そこで、本発明ではハンドオーバ元アクセスネットワークが配送遅延を伴う場合であっても、ＨｏＡ割り当て通知をＤＨＣＰ処理完了と同程度のタイミングでＵＥ１０７に配送させる方法を更に開示する。

すなわち、先に説明した図４において、ＵＥ１０７はＤＨＣＰオファーの受信後、所定の遅延時間をおいてＤＨＣＰリクエストを送信することにより、ＤＨＣＰ処理完了以前にハンドオーバ元アクセスネットワーク経由でＨｏＡ割り当て通知を確実に受け取ることができるようになる。すなわち、ＵＥ１０７が、ＤＨＣＰオファーのメッセージを受信後、所定の時間経過後にＤＨＣＰオファーのメッセージに対するメッセージであるＤＨＣＰリクエストを送信することにより、ＨｏＡ割り当て通知を確実に受け取ることができる。ここで、所定の遅延時間とは、例えば、ＨｏＡ割り当て通知が配送されるハンドオーバ元アクセスネットワークにおけるＵＥ１０７−ＨＡ１０６間の伝送遅延など、あらかじめ測定しておいた値を設定することができる。あるいは、通信のたびに伝送遅延を測定しておき、ダイナミックに設定してもよい。

ＤＨＣＰプロトコルでは、ＤＨＣＰオファー受信からＤＨＣＰリクエスト送信までの間に所定の遅延を設けることができるよう、プロトコルとしてタイマが規定されており、上記方法を用いることにより、新規タイマを追加することなく、既存リソース（プロトコルタイマ）を活用しながら、ＵＥ１０７にＨｏＡ割り当て通知が配送されるタイミング調整を実施させることができる。また、ハンドオーバ元アクセスネットワーク経由で既に確立されたＤＳＭＩＰコネクションを利用するので、ハンドオーバ先アクセスネットワークがＵＥ１０７に直接通知する機能を有していない場合でも、所望の動作を実施させることができる。さらには、所定の遅延は片方向の配送遅延相当であるので、鍵交換処理やＢＵ／ＢＡ交換に要する時間に対して短いものである。

以上の方法は、特に３ＧＰＰや３ＧＰＰ２のようなセルラシステムに特有のシステム条件を利用したものである。つまり、ＤＨＣＰサーバ（ここではＨＡ１０６に相当）がネットワーク接続時に一つに決定されるため、割り当てアドレスはＤＨＣＰオファーに記載されたものとなることが決まっており、すなわちＤＨＣＰオファー送信時点でＵＥ１０７に割り当てられるＩＰアドレスは既に決定している。

したがって、ＵＥ１０７は本方式の実施に先立ち、接続先ネットワークあるいはコアネットワークが３ＧＰＰなどのセルラシステム、または上記条件を満たすような、すなわちＵＥ１０７が問い合わせるＤＨＣＰサーバが論理的／物理的に一台に決まりうるようなシステムによって提供されるものであることを確認あるいは推定してもよい。その結果、ＤＨＣＰサーバが複数存在するようなシステムに接続しようとしている場合、ＵＥ１０７は本方式を実施しない。すなわち、ＵＥ１０７が、ハンドオーバ先のネットワークＡＲ１０５又はハンドオーバ先ネットワークを含む通信ネットワーク１０３が所定の条件を満たすネットワークであるか否かを確認し、条件を満たす場合に本方式を実施する。すなわち、ＵＥ１０７は割り当てアドレス種別通知メッセージの取得を待ったり、ＤＨＣＰオファーを受信してからＤＨＣＰリクエスト送信までのタイミング調整を行ったりする。３ＧＰＰネットワークへの接続であることの確認は、アタッチ時にＵＥ１０７が通知する接続先ネットワークの識別子（ＡＰＮ：Access Pont Name）のネットワーク識別部に３ＧＰＰやそれと同等の情報（オペレータ名など）が含まれることによって判定できる。

なお、ＣｏＡを割り当てる場合もＡＲ１０５（ここではＤＨＣＰサーバと同等）において同様に、ＤＨＣＰオファー送信（ステップＳ５０１）と同じタイミングでＰＣＲＦサーバ１０８にＣｏＡ割り当て通知（ステップＳ５０２）を送信してもよい（図５を参照）。すなわち、ハンドオーバ先のＡＲ１０５によってＣｏＡが割り当てられた場合、ハンドオーバ先のＡＲ１０５が、ＨＡ１０６に代わってＤＨＣＰオファーのメッセージを送信すると同時に、割り当てられたアドレスの種別を示す情報をＰＣＲＦ１０８に通知し、ＨＡ１０６が、割り当てられたアドレスの種別を示す情報をＰＣＲＦ１０８から受信し、それに基づいて割り当てアドレス種別通知メッセージを送信する。

これによって、ＣｏＡ割り当て通知がＵＥ１０７に配送されるまでの遅延を短縮することができ、特にＵＥ１０７が単に受信した割り当て通知種別通知メッセージに記載された内容からＨｏＡ／ＣｏＡ割り当てを判定する場合に、ハンドオーバ全体時間の削減を図ることができる。しかし、コアネットワーク１０３に配備される場合と異なり、アクセスネットワークには配備されるＤＨＣＰサーバが複数存在することが考えられる。したがって、すべてのＡＲ（ＤＨＣＰサーバ）において本方式がサポートされるとは限らないことに注意しなければならない。すなわち、すべてのアクセスネットワークにおいて本方式がサポートされていることを期待すべきではない。

なお、本発明による方法では、ＵＥ１０７が双方のアクセスネットワーク１０１、１０２に同時に接続できることが要件となる。したがって、ＵＥ１０７は、自身がデュアルインタフェース対応であることを事前にＢＵメッセージや認証処理メッセージを通じてＨＡ１０６や他のネットワークノードに知らせておき、ＨＡ１０６がＵＥ１０７のデュアル対応状況に応じて（すなわちデュアル対応時のみ）本処理を実施するようにしてもよい。これは、ＴＤＤ対応のシングルＩ／Ｆであることの通知であってもよい。また、ＨＡ１０６はＨｏＡ通知とともに、ネットワーク側で実施しているモビリティプロトコル（ＧＴＰやＰＭＩＰなど）をＵＥ１０７に通知してもよい。

また、ハンドオーバ元アクセスネットワークが３ＧＰＰアクセスの場合、ＤＳＭＩＰシグナリングではなく、３ＧＰＰシグナリング（ＮＡＳメッセージなど）で割り当てアドレスの種別（ＨｏＡまたはＣｏＡ）を通知するようにしてもよい。３ＧＰＰ標準を実装することにより普及を促進できるとともに、サポートエリアを広範に確保することができる。また、上記実施例は、ＩＰｖ６アクセスネットワークからＩＰｖ４のみ対応するアクセスネットワークへのハンドオーバを想定したものだが、原理としては他の例（IPv4からIPv6へのハンドオーバ）や一般化したケースでも同様に適用可能である。すなわち、ハンドオーバ先で割り当てたアドレスがＨｏＡ／ＣｏＡのいずれであるかを通知する機構があってもよい。

次に、本発明の実施の形態に係る移動端末（ＵＥ）の動作の一例について、図６から図９を用いて説明する。図６は本発明の実施の形態に係る移動端末の構成の一例を説明するための構成図である。送受信部６０１、６０２はそれぞれアクセスネットワーク１０１、１０２と接続するための通信インタフェースに相当し、ＩＰレイヤより下位の通信プロトコル処理並びにモデム処理を実施する。ＩＰ処理部６０３はＩＰレイヤ処理を実施し、ＭＩＰ処理部６０４はＤＳＭＩＰに基づくＭｏｂｉｌｅ ＩＰプロトコル処理を実施する。

ＤＨＣＰ処理部６０５はＤＨＣＰプロトコル処理（クライアント機能）を実施する。ハンドオーバ制御部６０６は送受信部６０１、６０２から得た通信状況などからハンドオーバの実施可能性や実施タイミングを判断あるいは検出し、ＭＩＰ処理部６０４や送受信部６０１、６０２、ＤＨＣＰ処理部６０５などにハンドオーバ実施のための指示を送出し、ハンドオーバ処理を制御する。ホームリンク判定制御部６０７は、本発明において特徴的なものであり、その動作の一例について図７から図９を用いて周辺の動作を交えながら説明する。

図７は、ＵＥ１０７がＨＡ１０６から受信した割り当てアドレス種別通知メッセージの内容に基づいて、ＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合の処理フローの一例を示すフローチャートである。ハンドオーバ制御部６０６がハンドオーバを開始するか否かを判断する（ステップＳ７０１）。ハンドオーバすると判断した場合、ハンドオーバ制御部６０６が送受信部６０２にハンドオーバ先ネットワーク（アクセスネットワーク１０２）へのアタッチ処理開始を指示する（ステップＳ７０２）。アタッチ処理時にはＩＰアドレスが割り当てられず、アタッチ処理完了後にＤＨＣＰなどのプロトコルを用いてＩＰアドレスを取得する場合、送受信部６０２からアタッチ処理が完了したことの通知を受けてハンドオーバ制御部６０６がＤＨＣＰ処理部６０５にＩＰアドレス取得を開始するよう指示する。

ＤＨＣＰ処理部６０５はＤＨＣＰディスカバリーメッセージをＩＰ処理部６０３、送受信部６０２を介してアクセスネットワーク１０２に送出し、その応答として割り当てられたＩＰｖ４アドレスを含むＤＨＣＰオファーメッセージを送受信部６０２、ＩＰ処理部６０３経由で取得する。さらに、応答を受けたサーバからのアドレス割り当てを受け入れるために、ＤＨＣＰリクエストメッセージを同様に送出し、その応答としてＤＨＣＰアックメッセージを同様に取得する（ＩＰアドレス取得処理：ステップＳ７０３）。以上の手続きによりＩＰアドレス取得処理を完了し、取得したＩＰアドレスはＩＰ処理部６０３に設定される。

このとき、ハンドオーバ元アクセスネットワーク（アクセスネットワーク１０１）経由で、ＨＡが送信した割り当てアドレス種別通知メッセージ（例えば、Binding Revocation RequestやBinding Refresh Request、Binding Ackや、専用フィールドや専用フラグを設けるように改造したメッセージ）がＵＥ１０７によって取得される（ステップＳ７０４）。アドレス種別通知メッセージは、送受信部６０１、ＩＰ処理部６０３を介して受信され、ＭＩＰ処理部６０４に転送される。ＭＩＰ処理部６０４では、割り当てアドレス種別通知メッセージの内容をホームリンク判定制御部６０７に転送あるいは通知する。

ホームリンク判定制御部６０７では、割り当てアドレス種別通知メッセージの内容を評価して、ハンドオーバ先アクセスネットワーク（アクセスネットワーク１０２）経由で取得したＩＰアドレスがＨｏＡとＣｏＡのいずれであるかを検出する（通知内容がＨｏＡか：ステップＳ７０５）。割り当てられたアドレスがＨｏＡであった場合は、ハンドオーバ先アクセスネットワークがホームリンクであると判断し、鍵交換処理やバインディング処理（ＢＵ／ＢＡ交換）を行うことなく通信を開始する（ステップＳ７０６）。割り当てられたアドレスがＣｏＡであった場合は、ハンドオーバ先アクセスネットワークが外部リンクであると判断し、必要に応じて鍵交換処理やバインディング処理（ＢＵ／ＢＡ交換）を実施する（ステップＳ７０７）。

最後にハンドオーバ制御部６０６は送受信部６０１にハンドオーバ元ネットワーク（アクセスネットワーク１０１）からのデタッチ処理の開始を指示し（ステップＳ７０８）、デタッチ処理の完了をもってハンドオーバ処理を完了する。デタッチ処理は省略されたり、ネットワークからの指示を受けて実施されたりすることもある。

ここで、アタッチ処理の過程で、アクセスネットワーク１０２からＩＰアドレスが割り当てられた場合について説明する。この場合、ＵＥ１０７はＤＨＣＰによるＩＰアドレス取得を行う必要がなく、アタッチ処理完了と同程度のタイミングでハンドオーバ元アクセスネットワークから割り当てアドレス種別通知メッセージを取得する（送受信部６０１、ＩＰ処理部６０３、ＭＩＰ処理部６０４を経て、メッセージの内容がホームリンク判定制御部６０７に転送あるいは通知される）。以降の処理は上述したのと同じであるので、ここでは省略する。

次に、ＵＥがＨＡからの割り当てアドレス種別通知メッセージの受信タイミング内容に基づいてＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合の処理フローの一例について図８を用いて説明する。ＵＥ１０７がハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージを受信して、メッセージの内容がホームリンク判定制御部６０７に転送あるいは通知されるところまでは上述したものと同じ処理なので、ここでは説明を省略する。上述したように、ＨｏＡ割り当て時とＣｏＡ割り当て時で、割り当てアドレス種別通知メッセージがＵＥ１０７に配送されるタイミングが異なるため、ＵＥ１０７はこの特性を活用してホームリンク判定を実施する（割り当てアドレス種別通知メッセージの受信タイミングの違いについては図２から図５を参照）。

すなわち、割り当てアドレス種別通知メッセージの内容を取得したホームリンク判定制御部６０７は、ＤＨＣＰ処理実施中であるか判断し（ステップＳ８０５）、ＤＨＣＰ処理が実施中である場合（ＹＥＳの場合）はＨｏＡが割り当てられたものと判断し（ハンドオーバ先ネットワークをホームリンクと判断：ステップＳ８０６）、それ以外の場合（ＮＯの場合）はＣｏＡが割り当てられたものと判断する（ハンドオーバ先ネットワークを外部リンクと判断：ステップＳ８０７）。さらには、ホームリンク判定制御部６０７がＤＨＣＰ処理完了までに割り当てアドレス種別通知メッセージの内容を既に取得できている場合は、その内容を確認した上でＨｏＡが割り当てられたことを確実に判定することができる。また、ＤＨＣＰ処理完了までに割り当てアドレス種別通知メッセージを受信できたが、取得した割り当てアドレス種別通知メッセージがＣｏＡを割り当てた旨の内容を示すものであった場合、メッセージの内容に従うものとする。

最後にハンドオーバ制御部６０６は送受信部６０１にハンドオーバ元ネットワーク（アクセスネットワーク１０１）からのデタッチ処理の開始を指示し（ステップＳ８０８）、デタッチ処理の完了をもってハンドオーバ処理を完了する。デタッチ処理は省略されたり、ネットワークからの指示を受けて実施されたりすることもある。

さらに、ＵＥがＨＡからの割り当てアドレス種別通知メッセージの受信タイミング内容に基づいてＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合に、ハンドオーバ元アクセスネットワークにおける伝送遅延の影響を排除するための最適化処理の一例について図９を用いて説明する。ＵＥ１０７がハンドオーバ先アクセスネットワークにアタッチするところまでは上述したものと同じ処理なので、ここでは説明を省略する。アタッチ処理時にはＩＰアドレスが割り当てられず、アタッチ処理完了後にＤＨＣＰなどのプロトコルを用いてＩＰアドレスを取得する場合、送受信部６０２からアタッチ処理が完了したことの通知を受けてハンドオーバ制御部６０６がＤＨＣＰ処理部６０５にＩＰアドレス取得を開始するよう指示する。

ＤＨＣＰ処理部６０５はＤＨＣＰディスカバリーメッセージをＩＰ処理部６０３、送受信部６０２を介してアクセスネットワーク１０２に送出し、その応答として割り当てられたＩＰｖ４アドレスを含むＤＨＣＰオファーメッセージを送受信部６０２、ＩＰ処理部６０３経由で取得する（ＩＰアドレス取得処理１：ステップＳ９０３）。

ここで、ハンドオーバ元アクセスネットワークにおける伝送遅延のゆらぎが原因となり、本来ＣｏＡ割り当て通知よりも先行して配送されるはずのＨｏＡ割り当てが、遅延して配送されることが考えられる。こうした影響を排除するため、ＤＨＣＰ処理部６０５はタイマを起動して（ステップＳ９０４）、ＤＨＣＰリクエストメッセージ送信までに所定の遅延を設ける。タイマに設定される時間値は、例えばハンドオーバ元アクセスネットワークにおける伝送遅延値をＵＥ１０７が測定した結果（平均値や最悪値）を用いてもよいし、あらかじめ定めた固定値であってもよい。また、ＤＨＣＰ処理部６０５にあらかじめ設定しておいてもよいし、ＤＨＣＰ処理の度に設定（変更）するものであってもよい。後者の場合、動的に変化するネットワークの状況に応じた遅延値を設定することができ、ひいてはハンドオーバ処理の効率化を図ることができる。

所定の遅延時間が経過してから、応答を受けたサーバからのアドレス割り当てを受け入れるために、ＤＨＣＰリクエストメッセージを同様に送出し、その応答としてＤＨＣＰアックメッセージを同様に取得する（ＩＰアドレス取得処理２：ステップＳ９０５）。以上の手続きによりＩＰアドレス取得処理を完了し、取得したＩＰアドレスはＩＰ処理部６０３に設定される。このとき、ハンドオーバ元アクセスネットワーク（アクセスネットワーク１０１）経由で、ＨＡ１０６が送信した割り当てアドレス種別通知メッセージがＵＥ１０７によって取得され、上述の順序でホームリンク判定制御部６０７に転送あるいは通知される。

割り当てアドレス種別通知メッセージの内容を取得したホームリンク判定制御部６０７は、ＤＨＣＰ処理が実施中であるか又は完了した直後であるか（例えば、ＤＨＣＰ処理完了時点を境に判定を行うことが可能であり、またＤＨＣＰ処理完了からの経過時間が所定の閾値内であるなどにより判定が可能である）をＤＨＣＰ処理部６０５の動作状況をもとに検出し（ステップＳ９０６）、条件に合致する場合はＨｏＡが割り当てられたものと判断し（ハンドオーバ先ネットワークをホームリンクと判断：ステップＳ９０７）、合致しない場合はＣｏＡが割り当てられたものと判断する（ハンドオーバ先ネットワークを外部リンクと判断：ステップＳ９０８）。条件に合致した場合、すなわちホームリンク判定制御が割り当てアドレス種別通知メッセージの内容を既に取得している場合は、その内容をもってＨｏＡが割り当てられたことを確実なものとすることができる。また、条件に合致したが、取得した割り当てアドレス種別通知メッセージがＣｏＡを割り当てた旨の内容を示すものであった場合、メッセージの内容に従うものとする。

最後にハンドオーバ制御部６０６は送受信部６０１にハンドオーバ元ネットワーク（アクセスネットワーク１０１）からのデタッチ処理の開始を指示し（ステップＳ９０９）、デタッチ処理の完了をもってハンドオーバ処理を完了する。デタッチ処理は省略されたり、ネットワークからの指示を受けて実施されたりすることもある。

次に、本発明の実施の形態に係るホームエージェント（ＨＡ）の動作の一例について図１０から図１２を用いて説明する。図１０は本発明の実施の形態に係るＨＡの構成の一例を説明するための構成図である。送受信部１００１はコアネットワーク１０３内のノードと通信を行うための通信インタフェースに相当し、ＩＰレイヤより下位の通信プロトコル処理並びにモデム処理を実施する。ＩＰ処理部１００２はＩＰレイヤ処理を実施し、ＭＩＰ処理部１００３はＤＳＭＩＰに基づくＭｏｂｉｌｅ ＩＰプロトコル処理を実施する。ＰＭＩＰ処理部１００４はＰＭＩＰプロトコル処理を実施する。ＤＨＣＰ処理部１００５はＤＨＣＰプロトコル処理（サーバ機能）を実施する。ホームアドレス割り当て部１００６は、本発明において特徴的なものであり、その動作の一例について周辺の動作を交えながら図１１と図１２を用いて説明する。

図１１は、ＵＥがＨＡから受信した割り当てアドレス種別通知メッセージの内容に基づいて、ＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合のＨＡの処理フローの一例を示すフローチャートである。ＡＲ１０５から転送されたＵＥ１０７からのＩＰアドレス取得要求メッセージ（あるいはＰＢＵメッセージ）が送受信部１００１、ＩＰ処理部１００２を介してＤＨＣＰ処理部１００５に転送されたか否かを判断し（ＩＰアドレス取得要求あるいはＰＢＵ受信か：ステップＳ１１０１）、受信したと判断された場合、ＤＨＣＰ処理部１００５は割り当てるＩＰアドレスをホームアドレス割り当て部１００６から取得し（ＨｏＡ割り当て：ステップＳ１１０２）、ＩＰアドレス割り当てメッセージに含めてＩＰ処理部１００２、送受信部１００１を介して送信し（ステップＳ１１０３）、ＤＨＣＰリレーとして動作しているＡＲ１０５経由でＵＥ１０７に転送される。そして、ホームアドレス割り当て部１００６は、割り当てアドレス種別通知メッセージをＡＲ１０４経由で送信する（ステップＳ１１０４）。

ここで、受信したＩＰアドレス取得要求メッセージには、ＵＥ１０７の識別子（例えば、Network Access Identifier：ＮＡＩ）を含み、ＨＡ１０６はＵＥ１０７からのＤＨＣＰ要求であることを判別できる。また、ＡＲ１０５がＵＥ１０７からのＩＰアドレス取得要求メッセージを受信したことを受けてＰｒｏｘｙ ＭＩＰのＰＢＵ（Ｐｒｏｘｙ ＢＵ）をＨＡ１０６に送信する場合は、送受信部１００１とＩＰ処理部１００２を介してＰＭＩＰ処理部１００４がＰＢＵメッセージを受信し、ホームアドレスをホームアドレス割り当て部１００６から取得し、ＰＢＡメッセージに記載して送信する。なお、この場合もＰＢＵにはＵＥ１０７の識別子（例えばＮＡＩ）が含まれているので、ＨＡ１０６はＵＥ１０７に対するアドレス割り当てであることを判別できる。

ホームアドレス割り当て部１００６は、上記ＤＨＣＰプロトコルあるいはＰＭＩＰプロトコルにもとづいてホームアドレスをＵＥ１０７に払いだすと同時に、ＵＥ１０７が生成したＤＳＭＩＰのバインディング情報（ＭＩＰ処理部１００３が保持している）をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する。メッセージにはＨｏＡを割り当てた旨の情報が記載されている。アドレス種別通知メッセージは、例えば、ＭＩＰ処理部１００３が処理可能なBinding Revocation RequestやBinding Refresh Request、Binding Ackであったり、それらに専用フィールドや専用フラグを設けるように改造したものであったり、独自のメッセージを規定してもよい。

また、ＰＣＲＦサーバ１０８が送信したＣｏＡ割り当て通知メッセージが、送受信部１００１、ＩＰ処理部１００２を介してホームアドレス割り当て部１００６に転送あるいは到着が通知されたか否かを判断し（ＣｏＡ割り当て通知取得か：ステップＳ１１０５）、通知されたと判断されると、ホームアドレス割り当て部１００６は、同様にＵＥ１０７のＤＳＭＩＰのバインディング情報をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する（ステップＳ１１０６）。メッセージにはＣｏＡを割り当てた旨の情報が記載されている。

次に、ＵＥがＨＡからの割り当てアドレス種別通知メッセージの受信タイミング内容に基づいてＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合に、ハンドオーバ元アクセスネットワークにおける伝送遅延の影響を排除するための最適化処理を行う場合のＨＡ処理フローの一例について図１２を用いて説明する。ＡＲ１０５から転送されたＵＥ１０７からのＤＨＣＰディスカバリーメッセージが送受信部１００１、ＩＰ処理部１００２を介してＤＨＣＰ処理部１００５に転送されたか否かを判断し（ＤＨＣＰディスカバリー受信か：ステップＳ１２０１）、転送されたと判断された場合、ＤＨＣＰ処理部１００５は割り当てるＩＰアドレスをホームアドレス割り当て部１００６から取得し（ＨｏＡ割り当て：ステップＳ１２０２）、ＤＨＣＰオファーメッセージに含めてＩＰ処理部１００２、送受信部１００１を介して送信する（ＤＨＣＰオファー送信：ステップＳ１２０３）。

これを受けてホームアドレス割り当て部１００６は、ＵＥ１０７が生成したＤＳＭＩＰのバインディング情報（ＭＩＰ処理部１００３が保持している）をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する（ステップＳ１２０４）。メッセージにはＨｏＡを割り当てた旨の情報が記載されている。これに続いて、ＤＨＣＰ処理部１００５がＵＥ１０７からのＤＨＣＰリクエストメッセージを受信する（ＤＨＣＰリクエスト受信：ステップＳ１２０５）と、ＤＨＣＰアックメッセージを送信する（ＤＨＣＰアック送信：ステップＳ１２０６）。ここで、いち早くＵＥ１０７に割り当て通知メッセージを到着させるために、ステップＳ１２０３より先にステップＳ１２０４を実施してもよい。

また、ＰＣＲＦサーバ１０８が送信したＣｏＡ割り当て通知メッセージが、送受信部１００１、ＩＰ処理部１００２を介してホームアドレス割り当て部１００６に転送あるいは到着が通知されたか否かを判断し（ＣｏＡ割り当て通知取得か：ステップＳ１２０７）、通知されたと判断されると、ホームアドレス割り当て部１００６は、同様にＵＥ１０７のＤＳＭＩＰのバインディング情報をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する（ステップＳ１２０８）。メッセージにはＣｏＡを割り当てた旨の情報が記載されている。

なお、上記では、移動端末がＩＰアドレスを取得するためにＩＰアドレス取得要求メッセージとＩＰアドレス割り当てメッセージを用いることを説明した。ここで、ＩＰアドレス取得要求メッセージとはＩＰアドレス取得処理を開始するメッセージであり、ＤＨＣＰプロトコルでいうところのＤＨＣＰディスカバリーメッセージ、あるいは既にＤＨＣＰサーバが明らかな場合や、ＤＨＣＰディスカバリーメッセージの送信を省略する場合はＤＨＣＰリクエストメッセージに相当する。また、ＩＰアドレス割り当てメッセージとはＩＰ取得処理において移動端末へのＩＰアドレス割り当てを完了するためのメッセージであり、ＤＨＣＰプロトコルでいうところのＤＨＣＰアックメッセージに相当する。

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

本発明のハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントは、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができ、またハンドオーバ元アクセスネットワーク経由で既に確立されたＤＳＭＩＰコネクションを利用することにより、ハンドオーバ先アクセスネットワークが移動端末に直接通知する機能を有していない場合でも、所望の動作を実施させることができるため、異なるＩＰバージョンに対応したネットワーク間を移動しながら通信を行う通信システムにおけるハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントなどに有用である。

本発明は、異なるＩＰバージョンに対応したネットワーク間を移動しながら通信を行う通信システムにおけるハンドオーバ方法、その方法で用いられる移動端末及びホームエージェント（位置管理サーバ）に関する。

従来の移動通信システムでは、インターネットプロトコル通信（ＩＰ通信）を行う移動端末の移動管理プロトコルとして、Mobile IPv4（ＭＩＰｖ４）あるいはMobile IPv6（ＭＩＰｖ６）があった。これら技術の詳細はそれぞれ下記の非特許文献１、非特許文献２に開示されている。また、従来、ＩＰｖ６をサポートするアクセスネットワークでしか動作しなかったＭＩＰｖ６をＩＰｖ４のみサポートするアクセスネットワークでも動作するように拡張したDual Stack Mobile IP（ＤＳＭＩＰ）があり、技術の詳細が非特許文献３に開示されている。

非特許文献２に基づくＭＩＰｖ６プロトコルでは、移動端末がホームエージェント（位置管理サーバ）にＩＰｖ６ホームアドレス（ＨｏＡｖ６）とＩＰｖ６気付けアドレス（ＣｏＡｖ６）を登録し、ホームエージェントにてそれらアドレスの関係性（バインディング）を管理するが、すべてのメッセージはＩＰｖ６プロトコルに基づくものであり、ＩＰｖ６をサポートするアクセスネットワークからしか利用することができなかった。ＤＳＭＩＰはＭＩＰｖ６を拡張したものであり、移動端末がＩＰｖ４のみサポートするアクセスネットワークに接続したときに、アクセスネットワークから取得したＩＰｖ４気付けアドレス（ＣｏＡｖ４）をＨｏＡｖ６とバインドさせてＩＰｖ４のみサポートするアクセスネットワークからもＨｏＡｖ６を用いた通信を可能とさせるものである。

また、ＤＳＭＩＰは、ホームエージェントがＩＰｖ４アドレスを有することを前提に、ＣｏＡｖ４とホームエージェントのＩＰｖ４アドレスをアドレスフィールドに記載したＩＰｖ４ヘッダでカプセリングすることでＭＩＰｖ６に基づくバインディング制御メッセージ（Binding Update（ＢＵ）あるいはBinding Acknowledge（ＢＡ）など）を交換可能としたり、ＩＰｖ４ホームアドレス（ＨｏＡｖ４）を移動端末に割り当ててＩＰｖ４アドレスのみ有する通信相手（Correspondent Node：ＣＮ）と通信を可能としたりするものである。

なお、ＩＰｖ４のみサポートするアクセスネットワークに接続した移動端末に対するＭＩＰｖ６に基づくバインディング管理を可能とする方法は下記の特許文献１にも開示されている。携帯電話による移動通信システムにおいても、同様の技術を用いたハンドオーバ方法が検討されている。下記の非特許文献４では、ＤＳＭＩＰを用いて３ＧＰＰアクセスネットワーク（ＬＴＥなど）から非３ＧＰＰアクセスネットワーク（無線ＬＡＮネットワークシステム、ＷｉＭＡＸネットワークシステム、３ＧＰＰ２ネットワークシステムなど）へのハンドオーバ方法が開示されている。

上記従来技術において、移動端末はホームアドレスＨｏＡｖ６が属するＩＰｖ６ホームプレフィクスを対象にしたホームリンク検出しか行ってこなかった。つまり、ＩＰｖ４アドレスを用いたホームリンク検出は行わず、アクセスネットワークから取得したＩＰｖ４アドレス（ＣｏＡｖ４に相当）のサブネットとＨｏＡｖ４のサブネットが同じであっても、アクセスネットワークから取得したＩＰｖ６プレフィクスとＩＰｖ６ホームプレフィクスが同じでない限り、そのアクセスネットワークはホームリンクとはみなさなかった。

したがって、実際にはＩＰｖ４サブネットの観点でホームリンクとなり得る場合であっても、移動端末がＨｏＡｖ４を用いる場合はすべてのパケット（バインディング制御メッセージ、ユーザデータ）にＩＰｖ４トンネルヘッダを余計に付加する必要があった。これにより、ヘッダオーバヘッドが増加して、特に限られた通信帯域を複数の移動端末によって共有する無線通信システムにおいては通信効率が低下するという問題があった。

ここで、図１、１３を用いて従来の移動通信システムにおける課題について詳しく説明する。図１はＤＳＭＩＰを用いた移動通信システムの一例の構成図であり、ＩＰｖ６をサポートするアクセスネットワーク１０１、ＩＰｖ４のみサポートするアクセスネットワーク１０２、それらアクセスネットワーク経由で接続可能なコアネットワーク１０３が配置されている。各々のアクセスネットワークには、アクセスルータＡＲ１０４、ＡＲ１０５が配備され、アクセスネットワークシステムのオペレーションによってＩＰｖ６ルータであったり、ＩＰｖ４ルータであったりする。

コアネットワーク１０３には、ＤＳＭＩＰに基づくホームエージェントＨＡ１０６が配備される。移動端末ＵＥ１０７はアクセスネットワーク１０１経由でＨＡ１０６と接続してＩＰｖ６ホームアドレス（ＨｏＡｖ６）を取得した後、アクセスネットワーク１０２に移動し、ハンドオーバ処理を実施する。

図１３は従来のハンドオーバ処理手順の一例を説明するためのシーケンスチャートである。移動端末ＵＥ１０７がアクセスネットワーク１０２へのハンドオーバ処理の開始を検出する（ステップＳ１３０１）と、アタッチ処理を開始する（ステップＳ１３０２）。アタッチ処理は認証サーバＨＳＳ／ＡＡＡ１３０１による接続認証処理（ステップＳ１３０３）を含み、接続が許可されるとアタッチ処理が完了する。続いてＵＥ１０７はＤＨＣＰプロトコルを用いるなどしてＩＰｖ４アドレスを取得し（ＩＰｖ４アドレス取得要求、ＩＰｖ４アドレス割り当て：ステップＳ１３０４、Ｓ１３０５）、これを気付けアドレス（ＣｏＡｖ４）として先に取得してあるＨｏＡｖ６とともにＨＡに登録するためのバインディング要求メッセージ（Binding Update：ＢＵ）を送信する（ステップＳ１３０６）。

このとき、ＵＥ１０７はＢＵを用いて、ＤＳＭＩＰプロトコルに基づくＩＰｖ４ホームアドレス（ＨｏＡｖ４）割り当て要求を実施する。ＨＡ１０６はＨｏＡｖ４割り当て要求付きのＢＵを受信すると、ＨｏＡｖ６とＣｏＡｖ４の組をバインディングキャッシュに登録し、ＨｏＡｖ４を割り当てるためバインディング応答メッセージ（Binding Acknowledge：ＢＡ）を用いてＵＥ１０７に通知する（ステップＳ１３０７）とともに、ＨｏＡｖ４とＣｏＡｖ４の組をバインディングキャッシュに登録する。

ここで、ＵＥ１０７は、取得したＨｏＡｖ４とＣｏＡｖ４のサブネット部を比較することにより、従来実施していなかったＩＰｖ４サブネットの観点でホームリンク検出を行う（ステップＳ１３０８）ことができる。その結果、ＨｏＡｖ４とＣｏＡｖ４のサブネット部が一致する場合は、そのアクセスネットワーク１０２をＩＰｖ４観点でのホームリンクとみなすことができ、ＨＡ１０６と交換するパケットに冗長なＩＰｖ４トンネルヘッダを付与する必要がなくなる。

もし、サブネット部が一致しなかった場合は、アクセスネットワーク１０２はホームリンクではないので、ＨＡ１０６と交換するすべてのパケットにＩＰｖ４トンネルヘッダを付与する必要がある。なお、従来はＩＰｖ４観点のホームリンク検出を行っていなかったので、ＨＡ１０６と交換するすべてのパケットにＩＰｖ４トンネルヘッダを付与していた。

ここで、好ましくはすべての場合においてＩＰｖ４トンネルヘッダを付与させることなく、ヘッダオーバヘッドを削減することである。多くの無線通信システムにおいては、移動端末とＡＲ間のリンクはポイントツーポイントリンクで構成されるので、１つのＡＲが複数の移動端末を収容する場合であっても、それぞれの移動端末に異なるサブネットに属するＩＰｖ４アドレスを配布することが可能となる。

また、移動端末は、ＣｏＡｖ４を取得してからＢＵ送信するまでにＨＡとの間で図１３に示すような鍵更新処理を行うことがある。例えば、動的鍵更新をサポートしていない移動端末は、気付けアドレスが変更される都度、鍵更新をしなければならない。鍵更新は移動端末、ＨＡ双方において暗号計算を伴う長時間の処理が必要とされるため、移動端末がＩＰｖ４観点のホームリンク検出を完了して実際にパケットを送受信できるまで相当の時間を要することになる。

特許文献２では、上記問題を解決するために、移動端末がＰＭＩＰプロトコルをサポートするアクセスネットワークに接続するときに、アタッチポイントであるＭＡＧ（ＡＲ１０５に相当）が、移動端末から端末能力情報を取得する。さらにＭＡＧは、取得した端末能力情報をもとに、ネットワークが移動端末に提供するモビリティプロトコル（ＤＳＭＩＰ、ＰＭＩＰ、ＭＩＰｖ４など）を決定し、決定したプロトコルに基づくＩＰ設定情報を移動端末に通知する。移動端末は、通知されたＩＰ設定情報などをもとに決定されたモビリティプロトコルを知ることができる。決定されたモビリティプロトコルがＰＭＩＰである場合は、併せて取得したＩＰアドレスがホームアドレスであると認識することができる。

特開２００５−７３２７１号公報（要約） 国際公開２００８−９９８０２号公報（要約）

C.Perkins "IP Mobility Support for IPv4", IETF RFC3344 August 2002 D.Johnson, C.Perkins, J.Arkko "Mobility Support in IPv6", IETF RFC3775 June 2004 Hesham soliman "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-05.txt July 2008 "Architecture enhancements for non-3GPP accesses (Release8)", 3GPP TS23.402 v.8.2.0 p.136-139 June 2008

しかしながら、上記従来技術においてはホームアドレスを取得したことを知るきっかけとなる通知は、接続処理中あるいは接続したばかりのハンドオーバ先アクセスネットワーク（上記特許文献２ではＭＡＧ）から直接取得するものである。ここで、移動端末のハンドオーバ先アクセスネットワークは、様々なアクセスタイプやネットワークシステムに相当し、管理運用するオペレータも一様ではないことが想定される。つまり、移動端末は、これから接続しようとするすべてのアクセスネットワークにおいて、上記の通知を取得できると期待することは、特にシステムの導入初期においては旧来システムの総入れ替えが発生することから現実的に不可能といえる。移動端末は様々なアクセスネットワークに接続しながらも、共通の手順により所望のコアネットワークリソースをあまねく享受できるという次世代ネットワークの目指す姿を実現するためには、移動端末が多種多様な管理運用ポリシを制約とすることなく、平等にサービスを受けられる環境を提供しなくてはならない。

このように、ＷｉＭＡＸやＷＬＡＮ、３ＧＰＰ、３ＧＰＰ２など、世界中のすべてのアクセスネットワークで上記のような通知機能がサポートされていることを期待するのは、多様な管理運用ポリシの観点から、ほぼ不可能と考えてもよく、そうした場合にも、移動端末がＩＰｖ４観点のホームリンク検出を早期に完了できる方法が必要となる。

本発明は、上記の問題点に鑑み、ＤＳＭＩＰを用いた移動通信システムにおいて、ＩＰｖ６ホームアドレスのみ有する移動端末がＩＰｖ４のみサポートするアクセスネットワークにハンドオーバする際に、ハンドオーバ先のネットワークで移動端末に割り当てられたＩＰアドレスの種別（ホームアドレス又はケアオブアフドレス）を、ホームエージェントがハンドオーバ元のネットワーク経由で移動端末に通知し、移動端末は通知取得タイミングに応じてホームリンク検出を行う。これにより、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェント間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができるハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントを提供することを目的とする。

上記目的を達成するために、本発明によれば、移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間を移動する前記移動端末のハンドオーバ方法であって、前記移動端末が、現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージを前記ハンドオーバ先のアクセスルータへ送信するステップと、前記移動端末のホームエージェントが、前記アドレス取得要求メッセージにより前記ハンドオーバ先のアクセスルータ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを前記ハンドオーバ前のアクセスルータを介して前記移動端末へ送信するステップとを、備えるハンドオーバ方法が提供される。この構成により、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。

また、本発明によれば、移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間をハンドオーバする前記移動端末であって、前記移動端末が、現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージを生成するメッセージ生成手段と、生成された前記アドレス取得要求メッセージを前記ハンドオーバ先のアクセスルータへ送信する送信手段と、前記アドレス取得要求メッセージにより前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを、前記移動端末のホームエージェントから前記ハンドオーバ前のアクセスルータを介して受信する受信手段とを、備える移動端末が提供される。この構成により、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。

また、本発明によれば、移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間をハンドオーバする前記移動端末のホームエージェントであって、前記移動端末が現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージに基づき、前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを生成するメッセージ生成手段と、生成された前記通知メッセージを前記ハンドオーバ前のアクセスルータを介して前記移動端末へ送信する送信手段とを、備えるホームエージェントが提供される。この構成により、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。

本発明のハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントは、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができる。また、ハンドオーバ元アクセスネットワーク経由で既に確立されたＤＳＭＩＰコネクションを利用することにより、ハンドオーバ先アクセスネットワークが移動端末に直接通知する機能を有していない場合でも、所望の動作を実施させることができる。

本発明の実施の形態における通信システムの構成の一例を示す構成図 本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャート 本発明の実施の形態におけるハンドオーバ方法の一例を説明するための他のシーケンスチャート 本発明の実施の形態におけるハンドオーバ方法の一例を説明するための他のシーケンスチャート 本発明の実施の形態におけるハンドオーバ方法の一例を説明するための他のシーケンスチャート 本発明の実施の形態に係る移動端末の構成の一例を示す構成図 本発明の実施の形態に係る移動端末における処理フローの一例を示すフローチャート 本発明の実施の形態に係る移動端末における他の処理フローの一例を示すフローチャート 本発明の実施の形態に係る移動端末における他の処理フローの一例を示すフローチャート 本発明の実施の形態に係るホームエージェントの構成の一例を示す構成図 本発明の実施の形態に係るホームエージェントにおける処理フローの一例を示すフローチャート 本発明の実施の形態に係るホームエージェントにおける他の処理フローの一例を示すフローチャート 従来技術を説明するための図

本発明の実施の形態の詳細な動作について説明する。図１は本発明によるシステム構成を説明するための図であり、少なくともＩＰｖ６をサポートするアクセスネットワーク１０１、ＩＰｖ４のみサポートするアクセスネットワーク１０２、それらアクセスネットワーク経由で接続可能なコアネットワーク１０３が配置される。各々のアクセスネットワークには、アクセスルータＡＲ１０４、ＡＲ１０５が配備され、アクセスネットワークシステムのオペレーションによってＩＰｖ６ルータであったり、ＩＰｖ４ルータであったり、またその双方であったりする。また、コアネットワーク１０３には、移動端末１０７の接続要求に応じて、システム全体のＱｏＳ（Quality of Service）などに関する制御を実施するＰＣＲＦ（Policy Control and Charging Rules Function）サーバ１０８が配備される。

さらに詳細には、アクセスネットワークが採用する規格に応じて、アクセスルータは、アクセスゲートウェイ（Access Gateway：ＡＧＷ）、モビリティアンカーゲートウェイ（Mobility Anchor Gateway：ＭＡＧ）、パケットデータゲートウェイ（Packet Data Gateway：ＰＤＧ、enhanced Packet Data Gateway：ｅＰＤＧ）、サービングゲートウェイ（Serving Gateway：ＳＧＷ）、サービングＧＰＲＳサービングノード（Serving GPRS Serving Node：ＳＧＳＮ）などと称されることもある。また、コアネットワーク１０３には、ＤＳＭＩＰに基づくホームエージェント（ＨＡ）１０６が配備され、コアネットワーク１０３が採用する規格に応じて、このＨＡ１０６はパケットデータネットワークゲートウェイ（Packet Data Network Gateway：ＰＤＮ ＧＷ）、ゲートウェイＧＰＲＳサービングノード（Gateway GPRS Serving Node：ＧＧＳＮ）などと称されることもある。

図１において、移動端末ＵＥ１０７はアクセスネットワーク１０１経由でＨＡ１０６と接続してＩＰｖ６ホームアドレス（ＨｏＡｖ６）を取得した後、アクセスネットワーク１０２に移動し、ハンドオーバ処理を実施する。

図２は、本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャートである。移動端末ＵＥ１０７がアクセスネットワーク１０２へのハンドオーバ処理開始を検出する（ステップＳ２０１）と、ＵＥ１０７はアクセスネットワーク１０２のアタッチポイント（ここではＡＲ１０５）に対してアタッチ処理を開始する（ステップＳ２０２）。ＡＲ１０５は、アタッチ処理の過程で、ＵＥ１０７に対する接続認証処理をＨＳＳ／ＡＡＡ１３０１に依頼する（ステップＳ２０３）。接続認証処理が成功すると、ＡＲ１０５は付随する処理を実施してアタッチ処理を完了する。

アタッチ処理を通じてＩＰアドレスが割り当てられなかった場合やネットワークから指示された場合、ＵＥ１０７はＤＨＣＰなどのプロトコルを用いてＩＰｖ４アドレスを取得する。すなわち、ＵＥ１０７はＩＰｖ４アドレス取得要求メッセージをＡＲ１０５に送信する（ステップＳ２０４）。ここで、要求されたＩＰアドレスをコアネットワーク１０３が割り当てる場合、すなわちＡＲ１０５においてＤＨＣＰ Ｒｅｌａｙ（リレー）機能が有効に設定されている場合、ＩＰｖ４アドレス取得要求メッセージはＡＲ１０５からＨＡ１０６に転送される。ＨＡ１０６は要求を受けてホームアドレスを割り当て（ステップＳ２０５）、ＩＰｖ４アドレス割り当てメッセージを用いてＵＥ１０７に通知する（ステップＳ２０６）。

また、ＡＲ１０５がＭＡＧの機能を有しており、ＰＭＩＰプロトコルによってＨＡ１０６との間のモビリティ機能を実現している場合は、ＵＥ１０７からのＩＰｖ４アドレス取得要求メッセージを受けてＡＲ１０５（ＭＡＧ）がＰＢＵ（Proxy Binding Update）メッセージをＨＡ１０６に発行することがある。この場合も、ＨＡ１０６は同様にホームアドレスを割り当て、ＰＢＵへの応答であるＰＢＡ（Proxy Binding Ack）メッセージを用いてＡＲ１０５に通知し、ＡＲ１０５がＩＰｖ４アドレス割り当てメッセージを用いて割り当てられたホームアドレスをＵＥ１０７に通知する。

ここで、ＨＡ１０６は受信したアドレス取得要求メッセージがＵＥ１０７からのものであることを次のようにして認識する。ＡＲ１０５はアタッチ処理時に取得したＵＥ１０７の識別子（例えば、Network Access Identifier：ＮＡＩ）を、アタッチ処理によって確立された通信ベアラ（例えば３ＧアクセスシステムではベアラＩＤが割り当てられるように）と関連付けて保存する。ＵＥ１０７が送信するアドレス取得要求メッセージは、アタッチ処理によって確立された通信ベアラ上で転送されるので、ＡＲ１０５は受信したアドレス取得要求メッセージがＵＥ１０７から送信されたものであることを識別し、先に保存しておいたＵＥ１０７の識別子（例えばＮＡＩ）を取得する。

ＡＲ１０５は、アドレス取得要求メッセージあるいはＰＢＵにＵＥ１０７の識別子（ＮＡＩ）を記載した上でＨＡ１０６に転送あるいは送信する。ＤＨＣＰメッセージには、ＮＡＩを記載するための“client field”が用意されており、ＰＢＵにも同様にＮＡＩを記載するためのオプションが用意されている。ＨＡ１０６はＵＥ１０７の識別子（ＮＡＩ）が記載されたメッセージを取得して、ＵＥ１０７から送信されたものであることを認識することができる。あるいはＵＥ１０７がメッセージに自信の識別子を含めて送信することにより、ＡＲ１０５で識別を行う必要がなくなる。

ＨＡ１０６は、割り当てたＩＰアドレスをＵＥ１０７に通知するのと同時に、既に接続を確立済みのＵＥ１０７に対するＤＳＭＩＰバインディング情報（バインディングキャッシュに蓄積されたホームアドレスとケアオブアドレスをはじめとする情報）を用いて、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージを送信し（ステップＳ２０７）、割り当てたＩＰアドレスがホームアドレスであることを通知する。割り当てアドレス種別通知メッセージは、例えばBinding Revocation RequestやBinding Refresh Request、Binding Ackなどを用いてもよいし、独自のメッセージを用いてもよい。

また、割り当てアドレス種別通知メッセージに割り当てたホームアドレスの値を記載してもよいが、単にホームアドレスかケアオブアドレスかのフラグ（少なくとも１ビット）を添付するようにしてもよい。フラグのみ送信することにより、アドレスの値を送る場合に比べて、少ないビット数で所望の情報をＵＥ１０７に通知することができ、通信リソースを有効活用することができる。

割り当てアドレス種別通知メッセージを取得したＵＥ１０７は、ハンドオーバ先アクセスネットワークで取得したＩＰアドレスがホームアドレスである、すなわちハンドオーバ先アクセスネットワークがホームリンクであると認識する。すなわち、本来続けて行われるバインディング処理（ＢＵ／ＢＡ交換）の中で取得するホームアドレスと先に取得したアドレスのサブネットの一致検査、すなわちホームリンク検出を省略することができ、特にバインディング処理の前に鍵更新処理を実施する必要がある場合は、鍵交換処理を省略あるいは遅延させることができ、ハンドオーバ時間の削減を図ることができる。なぜなら、鍵更新処理はＢＵ／ＢＡ交換を行う前に実施する必要がある（ＢＵ／ＢＡを保護するためのＩＰｓｅｃ鍵を更新するのが目的であるため）が、ＢＵ／ＢＡ交換を省略できるようになるので鍵更新処理をハンドオーバ処理完了後、任意のタイミングで実施できるようになるためである。

なお、ＡＲ１０５がＭＡＧの機能を有しており、ＨＡ１０６との間のモビリティ機能がＰＭＩＰプロトコルによって実現されており、アタッチ処理の過程でＨＡ１０６とＭＡＧの間でＰＢＵ／ＰＢＡが既に交換されている場合がある。さらにこのとき、割り当てられたＩＰアドレスがアタッチ処理の過程でＵＥ１０７に通知されている場合と、割り当てられたＩＰアドレスはＭＡＧが保有した状態でアタッチ処理の過程でＵＥ１０７に通知されていない場合とがある。後者の場合、続けて実施されるＤＨＣＰなどを用いたアドレス取得処理によって、割り当てアドレスがＵＥ１０７に通知される。

これらのケースでは、いずれもＨＡ１０６によるホームアドレス割り当てはアタッチ処理の過程で実施されている。したがって、ＨＡ１０６はアタッチ処理の過程で実施されるホームアドレス割り当ての完了と同時に割り当てアドレス種別通知メッセージを送信することが可能となり、ＵＥ１０７においてもアタッチ処理を行っている最中あるいはアタッチ処理の完了とほぼ同じタイミングでアドレス種別通知をハンドオーバ元アクセスネットワーク経由で取得することができる。なお、ＵＥ１０７は、アドレス種別通知メッセージを通じて割り当てアドレスの値を教えてもらうこともでき、アタッチ処理の過程でアドレスが通知されなかった場合にＤＨＣＰなどを用いたアドレス取得処理が不要となる。

次に、ハンドオーバ先アクセスネットワークにおいてケアオブアドレスが割り当てられる場合の動作について説明する。図３は、本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャートである。移動端末ＵＥ１０７がアクセスネットワーク１０２へのハンドオーバ処理開始を検出する（ステップＳ３０１）と、ＵＥ１０７はアクセスネットワーク１０２のアタッチポイント（ここではＡＲ１０５）に対してアタッチ処理を開始する（ステップＳ３０２）。ＡＲ１０５は、アタッチ処理の過程で、ＵＥ１０７に対する接続認証処理をＨＳＳ／ＡＡＡ１３０１に依頼する（ステップＳ３０３）。接続認証処理が成功すると、ＡＲ１０５は付随する処理を実施してアタッチ処理を完了する。

ここでは、割り当てるアドレスがホームアドレス（ＨｏＡ：Home Address）ではなくケアオブアドレス（ＣｏＡ：Care-of Address）、すなわちアクセスネットワーク１０２が独自にアドレスを割り当てることができるため、ＵＥ１０７が送信するＩＰアドレス取得要求メッセージ（ステップＳ３０４）は、アクセスネットワーク１０２内のサーバ（例えばＤＨＣＰサーバ：ＡＲ１０５内に併設されることもあり、以下ではそのケースについて説明する）で処理される。すなわち、ＵＥ１０７にケアオブアドレスが割り当てられる（ステップＳ３０５）。ＵＥ１０７にケアオブアドレスが割り当てられると、後にＵＥ１０７がバインディングを行ったときのＱｏＳポリシ適用に備えて（ひいてはコアネットワークリソースを用いた通信を可能とするために）、割り当てられたケアオブアドレスをＡＲ１０５がＰＣＲＦサーバ１０８に通知する（ステップＳ３０６：ＣｏＡ通知メッセージ）。ＣｏＡ通知メッセージは、Gateway Control Session Establishment、Gateway Control and QoS Rules Request、Gateway Control and QoS Rules Provisionなどともよぶ。また、ＡＲ１０５がローミングネットワークに配置される場合、すなわちＵＥ１０７がローミングネットワークにアタッチした場合、ＣｏＡ通知メッセージはローミングネットワークに配置されたプロキシＰＣＲＦサーバに配送され、コアネットワーク１０３のＰＣＲＦサーバ１０８に転送される。

ＣｏＡ通知メッセージを受信したＰＣＲＦサーバ１０８は、ＨＡ１０６が割り当てアドレス種別通知メッセージをＵＥ１０７に送信できるよう、受信したＣｏＡ通知メッセージをＨＡ１０６に転送、あるいは単にＵＥ１０７にケアオブアドレスが割り当てられたことをＨＡ１０６に通知する（ステップＳ３０７：ＣｏＡ通知）。すなわち、ハンドオーバ先のＡＲ１０５によってＵＥ１０７のケアオブアドレスが割り当てられた場合、ＨＡ１０６が、ハンドオーバ先のＡＲ１０５によって割り当てられたアドレスの種別を示す情報をＰＣＲＦサーバ１０８から受信する。これを受けて、ＨＡ１０６はハンドオーバ元アクセスネットワーク経由で、ＵＥ１０７に割り当てアドレス種別通知メッセージを送信し（ステップＳ３０８）、ケアオブアドレスが割り当てられたことを通知する。

ここで、ＰＣＲＦサーバ１０８及びＨＡ１０６は、受信したアドレス取得要求メッセージがＵＥ１０７からのものであることを次のようにして認識する。ＡＲ１０５はアタッチ処理時に取得したＵＥ１０７の識別子（例えば、Network Access Identifier：ＮＡＩ）を、アタッチ処理によって確立された通信ベアラ（３ＧアクセスシステムではベアラＩＤが割り当てられる）と関連付けて保存する。ＵＥ１０７が送信するアドレス取得要求メッセージは、アタッチ処理によって確立された通信ベアラ上で転送されるので、ＡＲ１０５は受信したアドレス取得要求メッセージがＵＥ１０７から送信されたものであることを識別し、先に保存しておいたＵＥ１０７の識別子（例えばＮＡＩ）を取得する。

ＡＲ１０５は、アドレス取得要求メッセージあるいはＰＢＵにＵＥ１０７の識別子（ＮＡＩ）を記載した上でＨＡ１０６に転送あるいは送信する。ＤＨＣＰメッセージには、ＮＡＩを記載するための“client field”が用意されており、ＰＢＵでも同様にＮＡＩを記載するためのオプションが用意されている。ＰＣＲＦサーバ１０８及びＨＡ１０６はＵＥ１０７の識別子（ＮＡＩ）が記載されたメッセージを取得して、ＵＥ１０７から送信されたものであることを認識することができる。あるいは、ＵＥ１０７がメッセージに自身の識別子を含めて送信することにより、ＡＲ１０５で識別を行う必要がなくなる。

ケアオブアドレスが割り当てられたことを認識したＵＥ１０７は、取得したケアオブアドレスをＨＡ１０６に登録して、外部リンクにおける通信を開始する。このとき、ＩＰｖ４ホームアドレスを取得していない場合は、ＨＡ１０６とのバインディング処理（ＢＵ／ＢＡ交換：ステップＳ３０９、Ｓ３１０）の過程で新規に取得する必要があるが、先に取得した割り当てアドレス種別通知メッセージを利用してＩＰｖ４ホームアドレスをＨＡ１０６から通知してもらうことも可能である。その際、ＵＥ１０７はバインディング手順などを通じて（すなわちBinding Updateメッセージを用いるなどして）ＨＡ１０６にあらかじめ通知を要求しておいてもよい。

また、ＵＥ１０７がハンドオーバ先アクセスネットワークへのアタッチ処理と同時に、ハンドオーバ元アクセスネットワーク経由で要求メッセージ（例えばＩＰｖ４ホームアドレスを要求するフラグを付加したＢＵメッセージ）をＨＡ１０６に送っておき、ＨＡ１０６はその応答として割り当てアドレス種別通知メッセージ（例えばＩＰｖ４ホームアドレスを記載したＢＡメッセージ）をＵＥ１０７に送信するものであってもよい。これによって、アタッチ処理ないしアドレス取得処理と併行してホームアドレスを取得して、その後のバインディング処理を不要とすることができ、ハンドオーバ全体時間の削減を図ることができる。

なお、ここでもアタッチ処理時にケアオブアドレスがＵＥ１０７に通知されることがある。この場合、ＡＲ１０５からＰＣＲＦサーバ１０８へのＣｏＡ通知メッセージの送信はアタッチ処理の過程で実施されている。したがって、ＨＡ１０６はアタッチ処理の過程でＰＣＲＦサーバ１０８から転送あるいは通知された内容（ＵＥ１０７にＣｏＡが割り当てられたこと）を受けて、割り当てアドレス種別通知メッセージを送信することが可能となる。これにより、ＵＥ１０７においても、アタッチ処理を行っている最中あるいはアタッチ処理の完了とほぼ同じタイミングで、アドレス種別通知をハンドオーバ元アクセスネットワーク経由で取得することができる。なお、ＵＥ１０７は既にＩＰアドレスを取得済みであるので、ＤＨＣＰなどを用いたＩＰアドレス取得要求を送信する必要はない。

ここで、上記説明では、ＡＲ１０５がＣｏＡ通知メッセージを送信する宛先ノードをＰＣＲＦサーバ１０８としたが、例えばＨＳＳ／ＡＡＡサーバ１３０１などのその他のノードであってもよいし、ＨＡ１０６に直接ＣｏＡ通知メッセージあるいは相当の情報を含むメッセージを送信するものであってもよい。

以上、ＨＡ１０６はＵＥ１０７に割り当てられたアドレス種別（ホームアドレスあるいはケアオブアドレス）を、既に確立された通信コネクション（すなわちハンドオーバ元アクセスネットワークのＤＳＭＩＰバインディングコネクション）を利用してＵＥ１０７に通知することで、アクセスネットワークがＵＥ１０７に直接通知する手段を実装していない場合でも、迅速なホームリンク検出を可能とさせることができる。

さて、ＨＡ１０６は割り当てアドレスの種別に関する情報を、それぞれ異なるルートから取得する。つまり、ホームアドレスを割り当てたことは自分自身から、ケアオブアドレスを割り当てたことはＰＣＲＦサーバ１０８などのサーバを介してハンドオーバ先アクセスネットワークに位置するＡＲ１０５から取得する。

ＣｏＡ割り当て通知は、実際にアドレスが割り当てられてからＰＣＲＦサーバ１０８を経由してＨＡ１０６に配送されるため、ホームアドレス（ＨｏＡ）割り当て通知に比べて、ＵＥ１０７が通知を取得するまでに多くの配送時間を要することが想定される。すなわち、ＩＰアドレス取得にＤＨＣＰを用いる場合、ＨｏＡ割り当て通知（割り当てアドレス種別通知メッセージ（ＨｏＡ））はＤＨＣＰ処理完了直後に配送され得るのに対して、ＣｏＡ割り当て通知（割り当てアドレス種別通知メッセージ（ＣｏＡ））は、ＤＨＣＰ処理完了してからしばらく後にＵＥ１０７に到着するものと想定される。

ＵＥ１０７はこの特性を利用して、割り当て通知の到着タイミングを以て、ＨｏＡ／ＣｏＡいずれのアドレスが割り当てられたかを判定することもできる。つまり、ＵＥ１０７の例えばホームリンク判定制御部６０７は、ＤＨＣＰ処理完了直後に割り当てアドレス種別通知メッセージを受信できた場合はＨｏＡが、通知を受信できなかった場合はＣｏＡが割り当てられたものと判断することができ、特にＣｏＡ割り当て時のメッセージ待ち時間を削減して、ハンドオーバ処理のさらなる高速化を図ることができる。この際、後述するように、ＨＡ１０６がＨｏＡ割り当て通知をハンドオーバ元アクセスネットワーク経由で送信したことをＵＥ１０７に通知するようにしてもよい。すなわち、ＨＡ１０６が、割り当てアドレス種別通知メッセージの他に、ＵＥ１０７に割り当てられたアドレスの種別が何かを示す情報を含むメッセージをＵＥ１０７に送信し、ＵＥ１０７が受信するようにしてもよい。

しかしながら、上記の方法、すなわちＨＡ１０６からの割り当てアドレス種別通知メッセージの受信タイミングによってＨｏＡとＣｏＡのいずれかが割り当てられたかを判定するためには、ＵＥ１０７においてＤＨＣＰ処理完了時点を起点とする割り当てアドレス種別通知メッセージの受信タイミングを検出するためのタイマを新規に設置する必要がある。そこで、本発明ではＨＡ１０６におけるＨｏＡ割り当て通知の送信タイミングを最適化することにより、ＵＥ１０７が通知メッセージを受信したタイミングから通知内容を確実に判定可能な方法を開示する。

図４は本発明の実施の形態におけるハンドオーバ方法の一例を説明するためのシーケンスチャートである。本発明では、ＤＨＣＰによるＩＰアドレス割り当て処理が２往復分のシーケンスによって構成されていることに着目する。すなわち、従来のＤＨＣＰシーケンスは、ＤＨＣＰディスカバリー（ＵＥ→ＨＡ：ステップＳ４０１）、ＤＨＣＰオファー（ＨＡ→ＵＥ：ステップＳ４０２）、ＤＨＣＰリクエスト（ＵＥ→ＨＡ：ステップＳ４０３）、ＤＨＣＰアック（ＨＡ→ＵＥ：ステップＳ４０４）の順に実施されるものである。３ＧＰＰなどのセルラシステムにおいては、ＵＥ１０７にアドレスを割り当てるＤＨＣＰサーバ（ここではＨＡ１０６と同等）はＵＥ１０７に対して一つに決まるという特徴がある。したがって、ＨＡ１０６ではＤＨＣＰオファー送信時点でＵＥ１０７に割り当てるホームアドレスが既に決定しているので、ＤＨＣＰオファー送信と同時にＨｏＡ割り当て通知を送信することが可能である。すなわち、ＨＡ１０６が、ＤＨＣＰによるＤＨＣＰディスカバリーに対する応答メッセージであるＤＨＣＰオファーと同時に、ＨｏＡ割り当て通知のメッセージをＵＥ１０７に送信することが可能である。

これにより、ＨＡ１０６が送信するＨｏＡ割り当て通知は、ＤＨＣＰ処理中にＵＥ１０７に配送される（割り当てアドレス種別通知メッセージ：ステップＳ４０５）。したがって、割り当てアドレス種別通知メッセージをＤＨＣＰ処理完了までに受信できなかった場合は、ＣｏＡが割り当てられたと判断することができる。すなわち、ＵＥ１０７に新たなタイマを設けることなく、早期（ＤＨＣＰ処理が完了するまで）にＨｏＡあるいはＣｏＡのいずれかが割り当てられたかを検出できるようになり、ハンドオーバ時間の更なる短縮を図ることができる。

しかしながら、上記の最適化方法においては、ハンドオーバ元アクセスネットワークの混雑状況などにより、ＨｏＡ割り当て通知が遅れてＵＥ１０７に配送されることが考えられる。その場合、ＵＥ１０７はＣｏＡが割り当てられたものと誤認し、ハンドオーバ先アクセスネットワーク経由で鍵交換処理やＢＵ／ＢＡ交換を開始してしまう。こうした問題を解決するために、以下の２通りの方法が考えられる。

１つ目の方法は以下のようなものである。ハンドオーバ先アクセスネットワーク経由の鍵交換処理あるいはＢＵ／ＢＡ交換時に、ＨＡ１０６がＨｏＡ割り当て通知をハンドオーバ元アクセスネットワーク経由で送信したことをＵＥ１０７に通知する。しかし、鍵交換処理やＢＵ／ＢＡ交換処理時にＨｏＡ割り当て通知を送信したことを伝えるためのプロトコルを、ハンドオーバ先アクセスネットワークにおいてサポートしている必要がある。また、割り当てアドレスが実際にはＨｏＡであった場合に、ＵＥ１０７は最悪の場合、数秒にものぼる鍵交換処理の完了や一往復分のＢＵ／ＢＡ交換の完了を待つ必要がある。

２つ目の方法は以下のようなものである。ＤＨＣＰ処理完了後、ＨＡ１０６からのＨｏＡ割り当て通知を受けるかもしれないので、ＵＥ１０７はタイマを起動して所定時間待つ。しかし、ＵＥ１０７は新規にタイマを実装する必要があり、使用リソースを増加させることになる（バッテリ消費量の増大などが懸念される）。

そこで、本発明ではハンドオーバ元アクセスネットワークが配送遅延を伴う場合であっても、ＨｏＡ割り当て通知をＤＨＣＰ処理完了と同程度のタイミングでＵＥ１０７に配送させる方法を更に開示する。

すなわち、先に説明した図４において、ＵＥ１０７はＤＨＣＰオファーの受信後、所定の遅延時間をおいてＤＨＣＰリクエストを送信することにより、ＤＨＣＰ処理完了以前にハンドオーバ元アクセスネットワーク経由でＨｏＡ割り当て通知を確実に受け取ることができるようになる。すなわち、ＵＥ１０７が、ＤＨＣＰオファーのメッセージを受信後、所定の時間経過後にＤＨＣＰオファーのメッセージに対するメッセージであるＤＨＣＰリクエストを送信することにより、ＨｏＡ割り当て通知を確実に受け取ることができる。ここで、所定の遅延時間とは、例えば、ＨｏＡ割り当て通知が配送されるハンドオーバ元アクセスネットワークにおけるＵＥ１０７−ＨＡ１０６間の伝送遅延など、あらかじめ測定しておいた値を設定することができる。あるいは、通信のたびに伝送遅延を測定しておき、ダイナミックに設定してもよい。

ＤＨＣＰプロトコルでは、ＤＨＣＰオファー受信からＤＨＣＰリクエスト送信までの間に所定の遅延を設けることができるよう、プロトコルとしてタイマが規定されており、上記方法を用いることにより、新規タイマを追加することなく、既存リソース（プロトコルタイマ）を活用しながら、ＵＥ１０７にＨｏＡ割り当て通知が配送されるタイミング調整を実施させることができる。また、ハンドオーバ元アクセスネットワーク経由で既に確立されたＤＳＭＩＰコネクションを利用するので、ハンドオーバ先アクセスネットワークがＵＥ１０７に直接通知する機能を有していない場合でも、所望の動作を実施させることができる。さらには、所定の遅延は片方向の配送遅延相当であるので、鍵交換処理やＢＵ／ＢＡ交換に要する時間に対して短いものである。

以上の方法は、特に３ＧＰＰや３ＧＰＰ２のようなセルラシステムに特有のシステム条件を利用したものである。つまり、ＤＨＣＰサーバ（ここではＨＡ１０６に相当）がネットワーク接続時に一つに決定されるため、割り当てアドレスはＤＨＣＰオファーに記載されたものとなることが決まっており、すなわちＤＨＣＰオファー送信時点でＵＥ１０７に割り当てられるＩＰアドレスは既に決定している。

したがって、ＵＥ１０７は本方式の実施に先立ち、接続先ネットワークあるいはコアネットワークが３ＧＰＰなどのセルラシステム、または上記条件を満たすような、すなわちＵＥ１０７が問い合わせるＤＨＣＰサーバが論理的／物理的に一台に決まりうるようなシステムによって提供されるものであることを確認あるいは推定してもよい。その結果、ＤＨＣＰサーバが複数存在するようなシステムに接続しようとしている場合、ＵＥ１０７は本方式を実施しない。すなわち、ＵＥ１０７が、ハンドオーバ先のネットワークＡＲ１０５又はハンドオーバ先ネットワークを含む通信ネットワーク１０３が所定の条件を満たすネットワークであるか否かを確認し、条件を満たす場合に本方式を実施する。すなわち、ＵＥ１０７は割り当てアドレス種別通知メッセージの取得を待ったり、ＤＨＣＰオファーを受信してからＤＨＣＰリクエスト送信までのタイミング調整を行ったりする。３ＧＰＰネットワークへの接続であることの確認は、アタッチ時にＵＥ１０７が通知する接続先ネットワークの識別子（ＡＰＮ：Access Pont Name）のネットワーク識別部に３ＧＰＰやそれと同等の情報（オペレータ名など）が含まれることによって判定できる。

なお、ＣｏＡを割り当てる場合もＡＲ１０５（ここではＤＨＣＰサーバと同等）において同様に、ＤＨＣＰオファー送信（ステップＳ５０１）と同じタイミングでＰＣＲＦサーバ１０８にＣｏＡ割り当て通知（ステップＳ５０２）を送信してもよい（図５を参照）。すなわち、ハンドオーバ先のＡＲ１０５によってＣｏＡが割り当てられた場合、ハンドオーバ先のＡＲ１０５が、ＨＡ１０６に代わってＤＨＣＰオファーのメッセージを送信すると同時に、割り当てられたアドレスの種別を示す情報をＰＣＲＦサーバ１０８に通知し、ＨＡ１０６が、割り当てられたアドレスの種別を示す情報をＰＣＲＦサーバ１０８から受信し、それに基づいて割り当てアドレス種別通知メッセージを送信する。

これによって、ＣｏＡ割り当て通知がＵＥ１０７に配送されるまでの遅延を短縮することができ、特にＵＥ１０７が単に受信した割り当てアドレス種別通知メッセージに記載された内容からＨｏＡ／ＣｏＡ割り当てを判定する場合に、ハンドオーバ全体時間の削減を図ることができる。しかし、コアネットワーク１０３に配備される場合と異なり、アクセスネットワークには配備されるＤＨＣＰサーバが複数存在することが考えられる。したがって、すべてのＡＲ（ＤＨＣＰサーバ）において本方式がサポートされるとは限らないことに注意しなければならない。すなわち、すべてのアクセスネットワークにおいて本方式がサポートされていることを期待すべきではない。

なお、本発明による方法では、ＵＥ１０７が双方のアクセスネットワーク１０１、１０２に同時に接続できることが要件となる。したがって、ＵＥ１０７は、自身がデュアルインタフェース対応であることを事前にＢＵメッセージや認証処理メッセージを通じてＨＡ１０６や他のネットワークノードに知らせておき、ＨＡ１０６がＵＥ１０７のデュアル対応状況に応じて（すなわちデュアル対応時のみ）本処理を実施するようにしてもよい。これは、ＴＤＤ対応のシングルＩ／Ｆであることの通知であってもよい。また、ＨＡ１０６はＨｏＡ通知とともに、ネットワーク側で実施しているモビリティプロトコル（ＧＴＰやＰＭＩＰなど）をＵＥ１０７に通知してもよい。

また、ハンドオーバ元アクセスネットワークが３ＧＰＰアクセスの場合、ＤＳＭＩＰシグナリングではなく、３ＧＰＰシグナリング（ＮＡＳメッセージなど）で割り当てアドレスの種別（ＨｏＡまたはＣｏＡ）を通知するようにしてもよい。３ＧＰＰ標準を実装することにより普及を促進できるとともに、サポートエリアを広範に確保することができる。また、上記実施例は、ＩＰｖ６アクセスネットワークからＩＰｖ４のみ対応するアクセスネットワークへのハンドオーバを想定したものだが、原理としては他の例（IPv4からIPv6へのハンドオーバ）や一般化したケースでも同様に適用可能である。すなわち、ハンドオーバ先で割り当てたアドレスがＨｏＡ／ＣｏＡのいずれであるかを通知する機構があってもよい。

次に、本発明の実施の形態に係る移動端末（ＵＥ）の動作の一例について、図６から図９を用いて説明する。図６は本発明の実施の形態に係る移動端末の構成の一例を説明するための構成図である。送受信部６０１、６０２はそれぞれアクセスネットワーク１０１、１０２と接続するための通信インタフェースに相当し、ＩＰレイヤより下位の通信プロトコル処理並びにモデム処理を実施する。ＩＰ処理部６０３はＩＰレイヤ処理を実施し、ＭＩＰ処理部６０４はＤＳＭＩＰに基づくＭｏｂｉｌｅ ＩＰプロトコル処理を実施する。

ＤＨＣＰ処理部６０５はＤＨＣＰプロトコル処理（クライアント機能）を実施する。ハンドオーバ制御部６０６は送受信部６０１、６０２から得た通信状況などからハンドオーバの実施可能性や実施タイミングを判断あるいは検出し、ＭＩＰ処理部６０４や送受信部６０１、６０２、ＤＨＣＰ処理部６０５などにハンドオーバ実施のための指示を送出し、ハンドオーバ処理を制御する。ホームリンク判定制御部６０７は、本発明において特徴的なものであり、その動作の一例について図７から図９を用いて周辺の動作を交えながら説明する。

図７は、ＵＥ１０７がＨＡ１０６から受信した割り当てアドレス種別通知メッセージの内容に基づいて、ＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合の処理フローの一例を示すフローチャートである。ハンドオーバ制御部６０６がハンドオーバを開始するか否かを判断する（ステップＳ７０１）。ハンドオーバすると判断した場合、ハンドオーバ制御部６０６が送受信部６０２にハンドオーバ先ネットワーク（アクセスネットワーク１０２）へのアタッチ処理開始を指示する（ステップＳ７０２）。アタッチ処理時にはＩＰアドレスが割り当てられず、アタッチ処理完了後にＤＨＣＰなどのプロトコルを用いてＩＰアドレスを取得する場合、送受信部６０２からアタッチ処理が完了したことの通知を受けてハンドオーバ制御部６０６がＤＨＣＰ処理部６０５にＩＰアドレス取得を開始するよう指示する。

ＤＨＣＰ処理部６０５はＤＨＣＰディスカバリーメッセージをＩＰ処理部６０３、送受信部６０２を介してアクセスネットワーク１０２に送出し、その応答として割り当てられたＩＰｖ４アドレスを含むＤＨＣＰオファーメッセージを送受信部６０２、ＩＰ処理部６０３経由で取得する。さらに、応答を受けたサーバからのアドレス割り当てを受け入れるために、ＤＨＣＰリクエストメッセージを同様に送出し、その応答としてＤＨＣＰアックメッセージを同様に取得する（ＩＰアドレス取得処理：ステップＳ７０３）。以上の手続きによりＩＰアドレス取得処理を完了し、取得したＩＰアドレスはＩＰ処理部６０３に設定される。

このとき、ハンドオーバ元アクセスネットワーク（アクセスネットワーク１０１）経由で、ＨＡが送信した割り当てアドレス種別通知メッセージ（例えば、Binding Revocation RequestやBinding Refresh Request、Binding Ackや、専用フィールドや専用フラグを設けるように改造したメッセージ）がＵＥ１０７によって取得される（ステップＳ７０４）。アドレス種別通知メッセージは、送受信部６０１、ＩＰ処理部６０３を介して受信され、ＭＩＰ処理部６０４に転送される。ＭＩＰ処理部６０４では、割り当てアドレス種別通知メッセージの内容をホームリンク判定制御部６０７に転送あるいは通知する。

ホームリンク判定制御部６０７では、割り当てアドレス種別通知メッセージの内容を評価して、ハンドオーバ先アクセスネットワーク（アクセスネットワーク１０２）経由で取得したＩＰアドレスがＨｏＡとＣｏＡのいずれであるかを検出する（通知内容がＨｏＡか：ステップＳ７０５）。割り当てられたアドレスがＨｏＡであった場合は、ハンドオーバ先アクセスネットワークがホームリンクであると判断し、鍵交換処理やバインディング処理（ＢＵ／ＢＡ交換）を行うことなく通信を開始する（ステップＳ７０６）。割り当てられたアドレスがＣｏＡであった場合は、ハンドオーバ先アクセスネットワークが外部リンクであると判断し、必要に応じて鍵交換処理やバインディング処理（ＢＵ／ＢＡ交換）を実施する（ステップＳ７０７）。

最後にハンドオーバ制御部６０６は送受信部６０１にハンドオーバ元ネットワーク（アクセスネットワーク１０１）からのデタッチ処理の開始を指示し（ステップＳ７０８）、デタッチ処理の完了をもってハンドオーバ処理を完了する。デタッチ処理は省略されたり、ネットワークからの指示を受けて実施されたりすることもある。

ここで、アタッチ処理の過程で、アクセスネットワーク１０２からＩＰアドレスが割り当てられた場合について説明する。この場合、ＵＥ１０７はＤＨＣＰによるＩＰアドレス取得を行う必要がなく、アタッチ処理完了と同程度のタイミングでハンドオーバ元アクセスネットワークから割り当てアドレス種別通知メッセージを取得する（送受信部６０１、ＩＰ処理部６０３、ＭＩＰ処理部６０４を経て、メッセージの内容がホームリンク判定制御部６０７に転送あるいは通知される）。以降の処理は上述したのと同じであるので、ここでは省略する。

次に、ＵＥがＨＡからの割り当てアドレス種別通知メッセージの受信タイミング内容に基づいてＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合の処理フローの一例について図８を用いて説明する。ＵＥ１０７がハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージを受信して、メッセージの内容がホームリンク判定制御部６０７に転送あるいは通知されるところまでは上述したものと同じ処理なので、ここでは説明を省略する。上述したように、ＨｏＡ割り当て時とＣｏＡ割り当て時で、割り当てアドレス種別通知メッセージがＵＥ１０７に配送されるタイミングが異なるため、ＵＥ１０７はこの特性を活用してホームリンク判定を実施する（割り当てアドレス種別通知メッセージの受信タイミングの違いについては図２から図５を参照）。

すなわち、割り当てアドレス種別通知メッセージの内容を取得したホームリンク判定制御部６０７は、ＤＨＣＰ処理実施中であるか判断し（ステップＳ８０５）、ＤＨＣＰ処理が実施中である場合（ＹＥＳの場合）はＨｏＡが割り当てられたものと判断し（ハンドオーバ先ネットワークをホームリンクと判断：ステップＳ８０６）、それ以外の場合（ＮＯの場合）はＣｏＡが割り当てられたものと判断する（ハンドオーバ先ネットワークを外部リンクと判断：ステップＳ８０７）。さらには、ホームリンク判定制御部６０７がＤＨＣＰ処理完了までに割り当てアドレス種別通知メッセージの内容を既に取得できている場合は、その内容を確認した上でＨｏＡが割り当てられたことを確実に判定することができる。また、ＤＨＣＰ処理完了までに割り当てアドレス種別通知メッセージを受信できたが、取得した割り当てアドレス種別通知メッセージがＣｏＡを割り当てた旨の内容を示すものであった場合、メッセージの内容に従うものとする。

最後にハンドオーバ制御部６０６は送受信部６０１にハンドオーバ元ネットワーク（アクセスネットワーク１０１）からのデタッチ処理の開始を指示し（ステップＳ８０８）、デタッチ処理の完了をもってハンドオーバ処理を完了する。デタッチ処理は省略されたり、ネットワークからの指示を受けて実施されたりすることもある。

さらに、ＵＥがＨＡからの割り当てアドレス種別通知メッセージの受信タイミング内容に基づいてＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合に、ハンドオーバ元アクセスネットワークにおける伝送遅延の影響を排除するための最適化処理の一例について図９を用いて説明する。ＵＥ１０７がハンドオーバ先アクセスネットワークにアタッチするところまでは上述したものと同じ処理なので、ここでは説明を省略する。アタッチ処理時にはＩＰアドレスが割り当てられず、アタッチ処理完了後にＤＨＣＰなどのプロトコルを用いてＩＰアドレスを取得する場合、送受信部６０２からアタッチ処理が完了したことの通知を受けてハンドオーバ制御部６０６がＤＨＣＰ処理部６０５にＩＰアドレス取得を開始するよう指示する。

ＤＨＣＰ処理部６０５はＤＨＣＰディスカバリーメッセージをＩＰ処理部６０３、送受信部６０２を介してアクセスネットワーク１０２に送出し、その応答として割り当てられたＩＰｖ４アドレスを含むＤＨＣＰオファーメッセージを送受信部６０２、ＩＰ処理部６０３経由で取得する（ＩＰアドレス取得処理１：ステップＳ９０３）。

ここで、ハンドオーバ元アクセスネットワークにおける伝送遅延のゆらぎが原因となり、本来ＣｏＡ割り当て通知よりも先行して配送されるはずのＨｏＡ割り当てが、遅延して配送されることが考えられる。こうした影響を排除するため、ＤＨＣＰ処理部６０５はタイマを起動して（ステップＳ９０４）、ＤＨＣＰリクエストメッセージ送信までに所定の遅延を設ける。タイマに設定される時間値は、例えばハンドオーバ元アクセスネットワークにおける伝送遅延値をＵＥ１０７が測定した結果（平均値や最悪値）を用いてもよいし、あらかじめ定めた固定値であってもよい。また、ＤＨＣＰ処理部６０５にあらかじめ設定しておいてもよいし、ＤＨＣＰ処理の度に設定（変更）するものであってもよい。後者の場合、動的に変化するネットワークの状況に応じた遅延値を設定することができ、ひいてはハンドオーバ処理の効率化を図ることができる。

所定の遅延時間が経過してから、応答を受けたサーバからのアドレス割り当てを受け入れるために、ＤＨＣＰリクエストメッセージを同様に送出し、その応答としてＤＨＣＰアックメッセージを同様に取得する（ＩＰアドレス取得処理２：ステップＳ９０５）。以上の手続きによりＩＰアドレス取得処理を完了し、取得したＩＰアドレスはＩＰ処理部６０３に設定される。このとき、ハンドオーバ元アクセスネットワーク（アクセスネットワーク１０１）経由で、ＨＡ１０６が送信した割り当てアドレス種別通知メッセージがＵＥ１０７によって取得され、上述の順序でホームリンク判定制御部６０７に転送あるいは通知される。

割り当てアドレス種別通知メッセージの内容を取得したホームリンク判定制御部６０７は、ＤＨＣＰ処理が実施中であるか又は完了した直後であるか（例えば、ＤＨＣＰ処理完了時点を境に判定を行うことが可能であり、またＤＨＣＰ処理完了からの経過時間が所定の閾値内であるなどにより判定が可能である）をＤＨＣＰ処理部６０５の動作状況をもとに検出し（ステップＳ９０６）、条件に合致する場合はＨｏＡが割り当てられたものと判断し（ハンドオーバ先ネットワークをホームリンクと判断：ステップＳ９０７）、合致しない場合はＣｏＡが割り当てられたものと判断する（ハンドオーバ先ネットワークを外部リンクと判断：ステップＳ９０８）。条件に合致した場合、すなわちホームリンク判定制御部６０７が割り当てアドレス種別通知メッセージの内容を既に取得している場合は、その内容をもってＨｏＡが割り当てられたことを確実なものとすることができる。また、条件に合致したが、取得した割り当てアドレス種別通知メッセージがＣｏＡを割り当てた旨の内容を示すものであった場合、メッセージの内容に従うものとする。

最後にハンドオーバ制御部６０６は送受信部６０１にハンドオーバ元ネットワーク（アクセスネットワーク１０１）からのデタッチ処理の開始を指示し（ステップＳ９０９）、デタッチ処理の完了をもってハンドオーバ処理を完了する。デタッチ処理は省略されたり、ネットワークからの指示を受けて実施されたりすることもある。

次に、本発明の実施の形態に係るホームエージェント（ＨＡ）の動作の一例について図１０から図１２を用いて説明する。図１０は本発明の実施の形態に係るＨＡの構成の一例を説明するための構成図である。送受信部１００１はコアネットワーク１０３内のノードと通信を行うための通信インタフェースに相当し、ＩＰレイヤより下位の通信プロトコル処理並びにモデム処理を実施する。ＩＰ処理部１００２はＩＰレイヤ処理を実施し、ＭＩＰ処理部１００３はＤＳＭＩＰに基づくＭｏｂｉｌｅ ＩＰプロトコル処理を実施する。ＰＭＩＰ処理部１００４はＰＭＩＰプロトコル処理を実施する。ＤＨＣＰ処理部１００５はＤＨＣＰプロトコル処理（サーバ機能）を実施する。ホームアドレス割り当て部１００６は、本発明において特徴的なものであり、その動作の一例について周辺の動作を交えながら図１１と図１２を用いて説明する。

図１１は、ＵＥがＨＡから受信した割り当てアドレス種別通知メッセージの内容に基づいて、ＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合のＨＡの処理フローの一例を示すフローチャートである。ＡＲ１０５から転送されたＵＥ１０７からのＩＰアドレス取得要求メッセージ（あるいはＰＢＵメッセージ）が送受信部１００１、ＩＰ処理部１００２を介してＤＨＣＰ処理部１００５に転送されたか否かを判断し（ＩＰアドレス取得要求あるいはＰＢＵ受信か：ステップＳ１１０１）、受信したと判断された場合、ＤＨＣＰ処理部１００５は割り当てるＩＰアドレスをホームアドレス割り当て部１００６から取得し（ＨｏＡ割り当て：ステップＳ１１０２）、ＩＰアドレス割り当てメッセージに含めてＩＰ処理部１００２、送受信部１００１を介して送信し（ステップＳ１１０３）、ＤＨＣＰリレーとして動作しているＡＲ１０５経由でＵＥ１０７に転送される。そして、ホームアドレス割り当て部１００６は、割り当てアドレス種別通知メッセージをＡＲ１０４経由で送信する（ステップＳ１１０４）。

ここで、受信したＩＰアドレス取得要求メッセージには、ＵＥ１０７の識別子（例えば、Network Access Identifier：ＮＡＩ）を含み、ＨＡ１０６はＵＥ１０７からのＤＨＣＰ要求であることを判別できる。また、ＡＲ１０５がＵＥ１０７からのＩＰアドレス取得要求メッセージを受信したことを受けてＰｒｏｘｙ ＭＩＰのＰＢＵ（Ｐｒｏｘｙ ＢＵ）をＨＡ１０６に送信する場合は、送受信部１００１とＩＰ処理部１００２を介してＰＭＩＰ処理部１００４がＰＢＵメッセージを受信し、ホームアドレスをホームアドレス割り当て部１００６から取得し、ＰＢＡメッセージに記載して送信する。なお、この場合もＰＢＵにはＵＥ１０７の識別子（例えばＮＡＩ）が含まれているので、ＨＡ１０６はＵＥ１０７に対するアドレス割り当てであることを判別できる。

ホームアドレス割り当て部１００６は、上記ＤＨＣＰプロトコルあるいはＰＭＩＰプロトコルにもとづいてホームアドレスをＵＥ１０７に払いだすと同時に、ＵＥ１０７が生成したＤＳＭＩＰのバインディング情報（ＭＩＰ処理部１００３が保持している）をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する。メッセージにはＨｏＡを割り当てた旨の情報が記載されている。アドレス種別通知メッセージは、例えば、ＭＩＰ処理部１００３が処理可能なBinding Revocation RequestやBinding Refresh Request、Binding Ackであったり、それらに専用フィールドや専用フラグを設けるように改造したものであったり、独自のメッセージを規定してもよい。

また、ＰＣＲＦサーバ１０８が送信したＣｏＡ割り当て通知メッセージが、送受信部１００１、ＩＰ処理部１００２を介してホームアドレス割り当て部１００６に転送あるいは到着が通知されたか否かを判断し（ＣｏＡ割り当て通知取得か：ステップＳ１１０５）、通知されたと判断されると、ホームアドレス割り当て部１００６は、同様にＵＥ１０７のＤＳＭＩＰのバインディング情報をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する（ステップＳ１１０６）。メッセージにはＣｏＡを割り当てた旨の情報が記載されている。

次に、ＵＥがＨＡからの割り当てアドレス種別通知メッセージの受信タイミング内容に基づいてＨｏＡとＣｏＡのいずれが割り当てられたかを判断する場合に、ハンドオーバ元アクセスネットワークにおける伝送遅延の影響を排除するための最適化処理を行う場合のＨＡ処理フローの一例について図１２を用いて説明する。ＡＲ１０５から転送されたＵＥ１０７からのＤＨＣＰディスカバリーメッセージが送受信部１００１、ＩＰ処理部１００２を介してＤＨＣＰ処理部１００５に転送されたか否かを判断し（ＤＨＣＰディスカバリー受信か：ステップＳ１２０１）、転送されたと判断された場合、ＤＨＣＰ処理部１００５は割り当てるＩＰアドレスをホームアドレス割り当て部１００６から取得し（ＨｏＡ割り当て：ステップＳ１２０２）、ＤＨＣＰオファーメッセージに含めてＩＰ処理部１００２、送受信部１００１を介して送信する（ＤＨＣＰオファー送信：ステップＳ１２０３）。

これを受けてホームアドレス割り当て部１００６は、ＵＥ１０７が生成したＤＳＭＩＰのバインディング情報（ＭＩＰ処理部１００３が保持している）をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する（ステップＳ１２０４）。メッセージにはＨｏＡを割り当てた旨の情報が記載されている。これに続いて、ＤＨＣＰ処理部１００５がＵＥ１０７からのＤＨＣＰリクエストメッセージを受信する（ＤＨＣＰリクエスト受信：ステップＳ１２０５）と、ＤＨＣＰアックメッセージを送信する（ＤＨＣＰアック送信：ステップＳ１２０６）。ここで、いち早くＵＥ１０７に割り当て通知メッセージを到着させるために、ステップＳ１２０３より先にステップＳ１２０４を実施してもよい。

また、ＰＣＲＦサーバ１０８が送信したＣｏＡ割り当て通知メッセージが、送受信部１００１、ＩＰ処理部１００２を介してホームアドレス割り当て部１００６に転送あるいは到着が通知されたか否かを判断し（ＣｏＡ割り当て通知取得か：ステップＳ１２０７）、通知されたと判断されると、ホームアドレス割り当て部１００６は、同様にＵＥ１０７のＤＳＭＩＰのバインディング情報をもとに、ハンドオーバ元アクセスネットワーク経由で割り当てアドレス種別通知メッセージをＵＥ１０７に送信する（ステップＳ１２０８）。メッセージにはＣｏＡを割り当てた旨の情報が記載されている。

なお、上記では、移動端末がＩＰアドレスを取得するためにＩＰアドレス取得要求メッセージとＩＰアドレス割り当てメッセージを用いることを説明した。ここで、ＩＰアドレス取得要求メッセージとはＩＰアドレス取得処理を開始するメッセージであり、ＤＨＣＰプロトコルでいうところのＤＨＣＰディスカバリーメッセージ、あるいは既にＤＨＣＰサーバが明らかな場合や、ＤＨＣＰディスカバリーメッセージの送信を省略する場合はＤＨＣＰリクエストメッセージに相当する。また、ＩＰアドレス割り当てメッセージとはＩＰ取得処理において移動端末へのＩＰアドレス割り当てを完了するためのメッセージであり、ＤＨＣＰプロトコルでいうところのＤＨＣＰアックメッセージに相当する。

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

本発明のハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントは、ハンドオーバ先アクセスネットワークがホームリンクであることを早期に検出して、移動端末とホームエージェントとの間のトンネルオーバヘッドを削減して通信効率を向上させるとともに、移動端末が鍵更新処理を行う場合であっても、鍵更新処理の前にホームリンク検出を実施することができ、時間を要する鍵更新処理の完了を待たずにパケットの送受信を可能とすることができ、ハンドオーバ時間の削減を図ることができ、またハンドオーバ元アクセスネットワーク経由で既に確立されたＤＳＭＩＰコネクションを利用することにより、ハンドオーバ先アクセスネットワークが移動端末に直接通知する機能を有していない場合でも、所望の動作を実施させることができるため、異なるＩＰバージョンに対応したネットワーク間を移動しながら通信を行う通信システムにおけるハンドオーバ方法、その方法で用いられる移動端末及びホームエージェントなどに有用である。

Claims (20)

1. 移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間を移動する前記移動端末のハンドオーバ方法であって、
   前記移動端末が、現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージを前記ハンドオーバ先のアクセスルータへ送信するステップと、
   前記移動端末のホームエージェントが、前記アドレス取得要求メッセージにより前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを前記ハンドオーバ前のアクセスルータを介して前記移動端末へ送信するステップとを、
   備えるハンドオーバ方法。
2. 前記アドレス取得要求メッセージは、アドレス付与を求めるための所定のプロトコルで用いられるメッセージである請求項１に記載のハンドオーバ方法。
3. 前記移動端末が、前記アドレス取得要求メッセージに基づいて割り当てられたアドレスの受信完了の直後若しくは前記受信完了前に前記通知メッセージを受信した場合、所定のアドレスが割り当てられたと判断する請求項２に記載のハンドオーバ方法。
4. 前記ホームエージェントは、前記通知メッセージの他に、前記移動端末に割り当てられたアドレスの種別が何かを示す情報を含む、前記アドレス取得要求メッセージに対する応答メッセージを前記移動端末に送信する請求項３に記載のハンドオーバ方法。
5. 前記ハンドオーバ先のアドレス割り当てサーバによって前記移動端末のアドレスが割り当てられた場合、
   前記ホームエージェントは、前記割り当てられたアドレスの種別を示す情報を所定のサーバから受信する請求項１から３のいずれか１つに記載のハンドオーバ方法。
6. 前記ホームエージェントは、前記アドレス取得要求メッセージに対する応答メッセージを送信すると同時に、前記通知メッセージを送信する請求項２に記載のハンドオーバ方法。
7. 前記移動端末は、前記応答メッセージを受信後、所定の時間経過後に前記応答メッセージに対するメッセージを送信する請求項６に記載のハンドオーバ方法。
8. 前記ハンドオーバ先のアドレス割り当てサーバは、前記ホームエージェントに代わって応答メッセージを送信すると同時に、前記割り当てられたアドレスの種別を示す情報を前記所定のサーバに通知し、
   前記ホームエージェントは、前記割り当てられたアドレスの種別を示す情報に基づいて前記通知メッセージを送信する請求項５に記載のハンドオーバ方法。
9. 前記移動端末は、前記ハンドオーバ先ネットワーク又は前記ハンドオーバ先ネットワークを含む通信ネットワークが所定の条件を満たすネットワークである場合に、前記アドレス取得要求メッセージを送信する請求項６又は７に記載のハンドオーバ方法。
10. 移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間をハンドオーバする前記移動端末であって、
    前記移動端末が、現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、
    前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージを生成するメッセージ生成手段と、
    生成された前記アドレス取得要求メッセージを前記ハンドオーバ先のアクセスルータへ送信する送信手段と、
    前記アドレス取得要求メッセージにより前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを、前記移動端末のホームエージェントから前記ハンドオーバ前のアクセスルータを介して受信する受信手段とを、
    備える移動端末。
11. 前記アドレス取得要求メッセージは、アドレス付与を求めるための所定のプロトコルで用いられるメッセージである請求項１０に記載の移動端末。
12. 前記受信手段が、前記アドレス取得要求メッセージに基づいて割り当てられたアドレスの受信完了の直後若しくは前記受信完了前に前記通知メッセージを受信した場合、
    所定のアドレスが割り当てられたと判断する判断手段を更に備える請求項１１に記載の移動端末。
13. 前記受信手段は、前記ホームエージェントによって送信される前記通知メッセージの他に、前記移動端末に割り当てられたアドレスの種別が何かを示す情報を含む、前記アドレス取得要求メッセージに対する応答メッセージを受信する請求項１２に記載の移動端末。
14. 前記受信手段は、前記アドレス取得要求メッセージに対する応答メッセージと、前記ホームエージェントから送信された前記通知メッセージを受信する請求項１１に記載の移動端末。
15. 前記メッセージ生成手段は、前記応答メッセージを受信後、所定の時間経過後に前記応答メッセージに対するメッセージを生成し、
    前記送信手段は、生成された前記応答メッセージに対するメッセージを送信する請求項１４に記載の移動端末。
16. 前記ハンドオーバ先のアドレス割り当てサーバによって前記移動端末のアドレスが割り当てられた場合、
    前記応答メッセージは、前記ホームエージェントに代わって前記ハンドオーバ先のアドレス割り当てサーバによって送信される請求項１４又は１５に記載の移動端末。
17. 前記ハンドオーバ先ネットワーク又は前記ハンドオーバ先ネットワークを含む通信ネットワークが所定の条件を満たすネットワークであるか否かを確認する確認手段を更に備え、
    前記送信手段は、前記所定の条件を満たすネットワークであると確認された場合に、前記アドレス取得要求メッセージを送信する請求項１４又は１５に記載の移動端末。
18. 移動端末の通信規約である固有の異なるＩＰバージョンにそれぞれ対応する少なくとも２つのネットワーク間をハンドオーバする前記移動端末のホームエージェントであって、
    前記移動端末が現在接続しているハンドオーバ前のネットワークのアクセスルータからハンドオーバ先の他のネットワークのアクセスルータへハンドオーバする際、
    前記移動端末に割り当てられる前記ハンドオーバ先のネットワークにおけるアドレスを取得するためのアドレス取得要求メッセージに基づき、前記ハンドオーバ先のアドレス割り当てサーバ又は前記ホームエージェントによって割り当てられた前記移動端末のアドレスの種別を示す情報を含む通知メッセージを生成するメッセージ生成手段と、
    生成された前記通知メッセージを前記ハンドオーバ前のアクセスルータを介して前記移動端末へ送信する送信手段とを、
    備えるホームエージェント。
19. 前記アドレス取得要求メッセージが、アドレス付与を求めるための所定のプロトコルで用いられるメッセージである場合、
    前記メッセージ生成手段は、前記アドレス取得要求メッセージに対する応答メッセージを生成し、
    前記送信手段は、前記応答メッセージと同時に、前記通知メッセージを送信する請求項１８に記載のホームエージェント。
20. 前記ハンドオーバ先のアドレス割り当てサーバによって前記移動端末のアドレスが割り当てられた場合、
    前記ハンドオーバ先のアドレス割り当てサーバによって割り当てられたアドレスの種別を示す情報を、前記ハンドオーバ先のアドレス割り当てサーバによって通知された所定のサーバから受信する受信手段を更に備え、
    前記メッセージ生成手段は、前記割り当てられたアドレスの種別を示す情報に基づいて前記通知メッセージを生成し、
    前記送信手段は、生成された前記通知メッセージを送信する請求項１８に記載のホームエージェント。