JP5367109B2 - モビリティ管理方式の変更直後のホームエージェントの発見 - Google Patents

Description

本発明は、モバイルノードがパケット交換方式ネットワーク内において自身のモビリティ管理方式を変更した直後に当該モバイルノードを管理する（ｓｅｒｖｅ；サーブする）ホームエージェントを発見する方法、並びに当該モバイルノードに関する。さらに、本発明は、モバイルノードが当該モビリティ管理方式を変更した直後に自身のサービングホームエージェントを発見する際にモバイルノードをサポートするホームエージェントに関する。

通信システムは、インターネットプロトコル（ＩＰ）ベースのネットワークへとますます進化している。当該通信システムは相互接続された多くのネットワークから成り、当該ネットワーク内では音声及びデータは、一端末から別の端末へと断片状いわゆるパケット状で送信される。各パケットは各ルータによって接続のない状態であて先へとルーティングされる。したがって、ＩＰパケットはＩＰヘッダ及びペイロード情報から成るとともに、当該ヘッダは特にソース及びあて先ＩＰアドレスを含む。拡張性の理由から、大きなＩＰネットワークは通常はサブネットへと分割されており、階層的なアドレス指定スキームを用いている。それゆえに、ＩＰアドレスは対応する端末を識別するだけでなく、この端末についての位置情報（現在のサブネット）を含んでいる。また、この位置情報は典型的には、ＩＰアドレスのプレフィクスとも呼ばれる。ルーティングプロトコルによって提供される追加的な情報によって、パケット交換方式ネットワーク内の各ルータは特定のあて先へと向かう次のルータを識別できる。

端末が移動体、いわゆるモバイルノード（ＭＮ）で、サブネット間を移動する場合、当該端末は、階層的なアドレス指定スキームを理由として（当該モバイルノードが自身のアドレスを保持することを可能にする他の機構が提供されていない場合は、下記のプロキシモバイルＩＰの論考を参照のこと）、自身のＩＰアドレスを、サブネットのプレフィクス（ドメイン）を用いる位相的に正しいアドレスへと変更しなければならない。しかしながら、ＯＳＩモデルのトランスポート層上のＴＣＰ接続といったより高位層での接続は、通信側ノードのＩＰアドレス（及びポート）によって定義されるので、当該ノードのうち一つが、例えば、移動により自身のＩＰアドレスを変更する場合には、接続は断たれる。

モバイルＩＰｖ６
Ｊｏｈｎｓｏｎらの「ＩＰｖ６内の移動性サポート」、ＩＥＴＦ ＲＦＣ ３７７５、２００４年６月（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇにて利用可能であり、参照により本明細書に組み込まれる）によって規定されたモバイルＩＰｖ６（ＭＩＰｖ６）は、より高位層及びアプリケーションに対してトランスペアレントな態様で、すなわち、より高位層の接続を断つことなく各モバイルノードがサブネット間を移動するのを可能にするＩＰベースの移動体プロトコルである。したがって、１個のモバイルノードは２個のＩＰアドレス：気付アドレス（ＣｏＡ）及びホームアドレス（ＨｏＡ）を構成してきた。モバイルノードの高位層は、あて先端末と関連付けられている通信パートナー、いわゆる通信相手（ＣＮ）との通信のためにホームアドレスを用いる。このアドレスは変化せず、及び、モバイルノードの識別の目的に資する。位相的には、ホームアドレスはモバイルノードのホームネットワーク（ＨＮ）に属している。

対照的に、当該気付アドレスは、サブネットの変化をきたすすべての移動ごとに変化する（新たなプレフィクスが通告されている）とともに、ルーティング下部構造のためのロケータとして用いられる。位相的には、気付アドレスは、モバイルノードが現在接続中であるネットワークに属している。ホームリンク上に配置された一組のアンカ、いわゆるホームエージェント（ＨＡ）のうち一つは、モバイルノードの気付アドレスのマッピングを当該モバイルノードのホームアドレスに保持するとともに、当該モバイルノードのための着信トラフィックを自身の現在位置へとリダイレクトする。一つのホームエージェントではなく一組のホームエージェントを持つ理由は、冗長及びロードバランシングである。

現在、モバイルＩＰｖ６は、双方向トンネリング及びルート最適化という２つの動作モードを定義している。双方向トンネリングが用いられる場合、通信相手によって送信されるとともにモバイルノードのホームアドレスへとアドレス指定されたデータパケットは、ホームネットワーク内のホームエージェントによって傍受され、モバイルノードの気付アドレスへとトンネリングされる。当該モバイルノードによって送信されたデータパケットは、ホームエージェントへとリバーストンネリングされ、当該ホームエージェントはパケットのデカプセル化を行うとともに、それらパケットを通信相手へと送信する。この動作のために、ホームエージェントには、モバイルノードの現在位置（すなわち、気付アドレス）が通知されなければならない。したがって、モバイルノードは、ＭＩＰｖ６においてバインディングアップデート（ＢＵ）メッセージと呼ばれる位置更新メッセージをホームエージェントへと送信する。バインディングアップデートメッセージは、バインディングアップデートメッセージの新しさ及び正しい順序をホームエージェントが識別できるように、シーケンス番号を含む。これらバインディングアップデートメッセージはＩＰｓｅｃセキュリティアソシエーション上で送信されるとともに、データ発生元認証及び完全性保護を提供するべく暗号で保護されている。このことは、モバイルノード及びホームエージェントが秘密鍵を共有することを必要とする。それゆえに、ホームエージェントは対応する共有鍵によって暗号で保護されている当該モバイルノードのホームアドレスのためのバインディングアップデートメッセージのみを受け取る。

モバイルＩＰｖ６への拡張
モバイルＩＰｖ６は近年、モバイルノードがホームエージェントによる動的なブートストラップを可能にするべく拡張されてきた（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｇｉａｒｅｔｔａら、「分割シナリオにおけるモバイルＩＰｖ６ブートストラップ」、ＲＦＣ ５０２６、２００７年１０月を参照のこと）。ブートストラップには、ホームエージェントを発見すること、モバイルＩＰシグナリングを確保するためにセキュリティアソシエーションを設定すること、及び、ホームエージェントとの対応するホームアドレスを構成することを含む。

ＩＰｓｅｃセキュリティアソシエーションはＩＫＥｖ２を用いて動的に確立してもよい。
ＩＫＥｖ２は、Ｋａｕｆｍａｎの「インターネットキー交換（ＩＫＥｖ２）プロトコル」、ＩＥＴＦ ＲＦＣ ４３０６、２００５年１２月；Ａｒｋｋｏらの「モバイルノードとホームエージェントとの間のモバイルＩＰｖ６シグナリングを保護するためのＩＰｓｅｃの使用」、ＩＥＴＦ ＲＦＣ ３７７６、２００４年６月、及び、Ｄｅｖａｒａｐａｌｌｉらの「ＩＫＥｖ２によるモバイルＩＰｖ６動作及び改定ＩＰｓｅｃアーキテクチャ」、ＩＥＴＦ ＲＦＣ ４８７７、２００７年４月（３文書すべてがｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇにて利用可能であり、参照により本明細書に組み込まれる）に定義されている。モバイルＩＰシグナリングを確保するためのセキュリティアソシエーションの確立を可能にするもう一つのプロトコルは、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含されるＰａｔｅｌらの「モバイルＩＰｖ６のための認証プロトコル」、ＩＥＴＦ ＲＦＣ ４２８５、２００６年１月による認証プロトコルである。

モバイルノードによってホームエージェントを発見するために、複数の方法が存在している。一つの選択肢は、モバイルノードが、ホームエージェントのＤＮＳ名で事前に構成されており、ホームエージェントのＩＰアドレスのリストを得るべくＤＮＳ（ドメイン名システム）に問い合わせることである（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｇｉａｒｅｔｔａらの「分割シナリオにおけるモバイルＩＰｖ６ブートストラップ」、ＲＦＣ ５０２６、２００７年１０月を参照のこと）。別の選択肢は、モバイルノードがエニーキャストホームエージェントアドレスのサフィックスで事前に構成されており、エニーキャストを介してホームエージェントの一群へと、ＤＨＡＡＤメッセージ（ＩＥＴＦ ＲＦＣ ３７７５を参照のこと）又はＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージ（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｄｕｐｏｎｔらの「モバイルＩＰｖ６／ＮＥＭＯブートストラップにおけるＩＫＥｖ２ベースのホームエージェントの割り当て」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｄｕｐｏｎｔ−ｉｋｅｖ２−ｈａｓｓｉｇｎ−０２．ｔｘｔ、２００７年１月を参照のこと）を送信することである。エニーキャストホームエージェントアドレスのプレフィクスは、モバイルノード上で事前に構成すること、あるいは、ネットワークから動的に取得することができる。さらに当該プレフィクスは、モバイルノードのホームアドレスのプレフィクスと同じであってもよい。

このエニーキャストの概念によって、複数のホームエージェントに同一のエニーキャストアドレスが割り当てられるとともに、このエニーキャストへと送信されたメッセージは、エニーキャストグループの一部である任意のホームエージェントへと配信される。典型的には、当該メッセージは、送信者に最も近い位置にあるホームエージェントへと配信される。ＤＮＳベースのホームエージェントの発見及びエニーキャストベースのホームエージェントの発見を組み合わせることもできる。したがって、モバイルノードはＤＮＳ名で事前に構成されており、ＤＮＳはエニーキャストアドレスを返す。図１はＩＫＥエニーキャスティングを用いたホームエージェントの発見の一例を示す。

アクセスネットワーク事業者とホームネットワーク事業者が同じであるか、若しくは、信頼関係を持っている配備シナリオにおいて、当該モバイルノードのためのホームエージェントアドレスは、ホームネットワーク又は訪問ネットワークによって割り当てられ、ＡＡＡプロトコルを介してアクセスネットワークに配信され、ＤＨＣＰプロトコルを用いてモバイルノードに割り当てることができる。このアプローチによって、モバイルノードはＤＨＣＰサーバーに問い合わせて、ホームエージェントＩＰアドレスを取得する（ともにｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｃｈｏｗｄｈｕｒｙらの「統合シナリオのためのＭＩＰ６ブートストラッピング」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｂｏｏｔｓｔｒａｐｐｉｎｇ−ｉｎｔｅｇｒａｔｅｄ−ｄｈｃ−０５．ｔｘｔ、２００７年６月、及びＨｅｅ Ｊｉｎ Ｊａｎｇらの「ＭＩＰｖ６におけるホーム情報発見のためのＤＨＣＰオプション」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｈｉｏｐｔ−１０．ｔｘｔ、２００８年１月を参照のこと）。

クライアントベース対ネットワークベースのモビリティ管理
モビリティ管理シグナリングはホスト／クライアントとホームエージェントの間にあるので、モバイルＩＰはホストベース又はクライアントベースのプロトコルである。それゆえに、ＭＩＰは時にはクライアントモバイルＩＰ（クライアントＭＩＰ又はＣＭＩＰ）とも呼ばれる。

人気が高まりつつある別のアプローチは、ＩＰモビリティ管理のためのネットワークベースのアプローチである。訪問アクセスネットワーク内のエンティティは、モバイルノードのためのプロキシとして機能し、ホームエージェントへの位置更新のシグナリングを初めとする当該モバイルノードに対する移動性を管理する。ネットワークベースのモビリティ管理は、無線よりもシグナリングオーバーヘッドがより少ないこと、及び、単純なＩＰノード（すなわち、非クライアントＭＩＰ可能ノード）に対する移動性サポートといったいくつかの利点があるとみなされる。一般的に特定される欠点は、この管理には訪問アクセスネットワークからのサポートを必要とすることである。

ＩＥＴＦ（インターネット技術タスクフォース）は、モバイルＩＰプロトコルに基づくローカルなモビリティ管理のためのかかるアプローチに取り組んでいる。ネットワークエンティティは当該モバイルノードに代わってプロキシの機能を果たすので、当該プロトコルはプロキシモバイルＩＰ（プロキシＭＩＰ又はＰＭＩＰ）と呼ばれる。ＰＭＩＰｖ６と呼ばれるＩＰｖ６の変形（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｇｕｎｄａｖｅｌｌｉらの「プロキシモバイルＩＰｖ６」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｉｅｔｆ−ｎｅｔｌｍｍ−ｐｒｏｘｙｍｉｐ６−１０．ｔｘｔ、２００８年２月を参照のこと）、及び、プロキシＭＩＰｖ４と呼ばれるＩＰｖ４の変形（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含されるＬｅｕｎｇらの「ＷｉＭＡＸフォーラム／３ＧＰＰ３プロキシモバイルＩＰｖ４」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｌｅｕｎｇ−ｍｉｐ４−ｐｒｏｘｙ−ｍｏｄｅ−０７．ｔｘｔ、２００８年２月を参照のこと）がある。

ＰＭＩＰｖ６はモバイルアクセスゲートウェイ（ＭＡＧ）と呼ばれる新しい論理エンティティを導入しており、当該ＭＡＧは典型的には、モバイルノードが現在接続中であるアクセスルータ（ＡＲ）と同じ位置に配置されているとともに、当該モバイルノードの代わりにバインディングアップデートメッセージを送信する。プロキシＭＩＰ−ホームエージェントは拡張されたクライアントＭＩＰ−ホームエージェントアンカであり、ローカルモビリティアンカ（ＬＭＡ）と呼ばれる。ローカルモビリティアンカにはホームエージェント機能が含まれているので、当該ローカルモビリティアンカは本明細書中においてホームエージェントと示されることもある。当該モバイルアクセスゲートウェイによって送信された各バインディングアップデートメッセージには、フラグによって印が付けられており、その結果、当該バインディングアップデートメッセージは、ローカルモビリティアンカによってプロキシバインディングアップデート（ＰＢＵ）メッセージとして識別することができ、モバイルノードによって送信された各バインディングアップデートメッセージ（すなわち、ＣＭＩＰシグナリングメッセージ）とは区別することができる。

さらに、プロキシバインディングアップデートメッセージは、とりわけ、ネットワークアクセス識別子（ＮＡＩ）オプション、ホームプレフィクスオプション、及びタイムスタンプオプションを含む。ＮＡＩオプションは（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含されるＡｂｏｄａらの「ネットワークアクセス識別子」、ＩＥＴＦ ＲＦＣ ４２８２、２００５年１２月に規定された）モバイルノードのＮＡＩを含み、当該ＮＡＩは「ｕｓｅｒｎａｍｅ＠ｒｅａｌｍ」の形式を持つとともに、モバイルノードを識別するのに用いられる。

ホームプレフィクスオプションは、モバイルノードのホームアドレス又はホームプレフィクスを含む。プロキシＭＩＰｖ６では、典型的にはあらゆるモバイルノードには固有のプレフィクスが割り当てられている。モバイルノードが新しいモバイルアクセスゲートウェイに接続すると、モバイルアクセスゲートウェイは、プロキシバインディングアップデートをローカルモビリティアンカへと送信して、当該モバイルノードの新しい位置を登録する。プロキシバインディングアップデートは、例えば、ネットワーク認証の成功によって、ＤＨＣＰ（動的ホスト構成プロトコル）メッセージ又はその他によって、トリガすることができる。さらに、モバイルアクセスゲートウェイはモバイルノードに対し、当該モバイルノードのホームプレフィクスを通知する。それゆえに、モバイルノードのＩＰスタックは、当該モバイルノードがプロキシＭＩＰドメインの内部を移動する限り、自身がホームにあると考え、自身がサブネットを変更することには気付かない。ローカルモビリティアンカとモバイルアクセスゲートウェイの間のトンネルが確立され、及び、当該モバイルノードから／へのすべてのトラフィックはこのトンネルを通って転送される。

３ＧＰＰ ＳＡＥシステム（ともにｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇで利用可能であり、参照により本明細書に組み込まれる３ＧＰＰ ＴＳ ２３．４０１「進化型ＵＭＴＳ無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）のための汎用パケット無線サービス（ＧＰＲＳ）の向上」、バージョン８．０．０、及び、３ＧＰＰ ＴＳ ２３．４０２、「非３ＧＰＰアクセス向けのアーキテクチャ向上」、バージョン８．０．０を参照のこと）は、アクセス技術間のハンドオーバーに対するモビリティ管理のためのＭＩＰｖ６及びプロキシＭＩＰｖ６の両方（クライアント）を規定している。ホームエージェント機能及びローカルモビリティアンカ機能は、パブリックデータネットワークゲートウェイ（ＰＤＮ−ＧＷ）の一部であり、モバイルノード機能はユーザ装置の一部（モバイルノードと等価）であり、及び、モバイルアクセスゲートウェイ機能は、非３ＧＰＰネットワークの進化型パケットデータゲートウェイ（ｅＰＤＧ）、アクセスゲートウェイ及びアクセスルータの一部である。以下において等価の語が交換可能に用いられている。

３ＧＰＰ ＳＡＥシステムは異なる種類のアクセスネットワークを定義している。３ＧＰＰアクセスネットワークは、ＧＳＭ（登録商標）／ＧＰＲＳ、ＵＭＴＳ、ＬＴＥといった３ＧＰＰ無線技術を用いて、ネットワークアクセスを端末へと提供する一方で、非３ＧＰＰアクセスネットワークは、ＷＬＡＮ、ＷｉＭａｘ、ＣＤＭＡ２０００等といった非３ＧＰＰ無線技術を用いて、ネットワークアクセスを提供する。非３ＧＰＰアクセスネットワークはさらに、３ＧＰＰ事業者による信頼のレベルに応じて、信頼された非３ＧＰＰアクセスネットワーク及び信頼されていない非３ＧＰＰアクセスネットワークに分割することが可能である。信頼された非３ＧＰＰアクセスネットワーク内に位置している端末は、ＰＤＮ−ＧＷによって提供されたモバイルＩＰｖ６サービス等の３ＧＰＰサービスに直接的にアクセスできる一方、信頼されない非３ＧＰＰアクセスネットワーク内に位置している端末は、ｅＰＤＧ上にある時にのみ３ＧＰＰサービスにアクセスしてもよい。端末はまずｅＰＤＧにおいて認証する必要があり、次いで、当該端末から／へのすべてのトラフィックは完全性及び機密性をもって保護されて、安全なＩＰｓｅｃトンネル上をｅＰＤＧへと送信されるという意味で、ｅＰＤＧはＶＰＮサーバーに類似している。端末は典型的には、ＤＮＳを用いてｅＰＤＧアドレスを発見し、ＩＫＥｖ２を用いてＩＰｓｅｃトンネルを設定する。

いくつかのアクセスネットワークはＰＭＩＰをサポートするが他のアクセスネットワークはサポートしないことが起こりうる。それゆえに、モバイルノードのためのモビリティ管理は、セッション中にＰＭＩＰｖ６からＭＩＰｖ６へと、又は逆に、移行することができる。あるモバイルノードが、ネットワークベースのモビリティ管理を備えたドメインからホストベースのモビリティ管理を備えたドメインへと移行中である場合は、当該モバイルノードは、セッション継続性を保証できるためには、ネットワークによってかつて用いられたアンカ（ホームエージェント）を発見し、ならびに、登録する必要がある。移動性が当該ネットワークによって管理されている場合において当該モバイルノードは典型的には自身のホームエージェントを知らないので、データサービス中の目に見える割り込みを防止するためには、モバイルノードが急に受信可能地域外へと出たこと等を理由に少なくとも当該発見を予測可能な方法でハンドオーバーの前に行うことができない場合は、モバイルノードは特定のホームエージェントをできる限り迅速に発見する必要がある。さらに、あるノードが別のモバイルノードをサーブするホームエージェントを識別できるべきでない。そうでなければ、経路外攻撃者が、ある特定のモバイルノードのホームエージェントに対して的を絞ったサービス妨害（ＤｏＳ）攻撃を実装することが可能である。

本発明の目的は、モバイルノードが自身のモビリティ管理方式を変更した直後に、シームレスな態様でセッション継続性を保持するホームエージェント発見方式を提案することである。

本目的は、独立請求項の主題によって解決される。本発明の有利な実施形態は従属請求項の主題である。

本発明の主たる要旨は、モバイルノードが、アンカ（ホームエージェント）発見プロセス中に、自身のかつての移動又は（かつての接続ポイントといった）位置についての情報をネットワークに明らかにすることである。モバイルノードからのホームエージェント発見メッセージがホームエージェント又はホームエージェント発見サーバーによって受信される場合は、当該ホームエージェント又はホームエージェント発見サーバーは、当該モバイルノードが正しいアンカ（すなわち、モビリティ管理方式の変更の前にモバイルノードが登録されるホームエージェント）を発見するのを支援する手がかりを当該モバイルノードに返すことができる。

いくつかの場合において、応答メッセージ中の手がかりは、サービングホームエージェントを固有に識別し、その結果、別のホームエージェント発見メッセージがモバイルノードによって正しいホームエージェントで受信されるには、すでに十分であるかもしれない。そうでない場合は、ホームエージェントはまた、モバイルノードが正しいアンカを発見するのを支援する手がかりを含む応答メッセージを、当該モバイルノードに戻してもよく、当該モバイルノードは別のホームエージェント発見メッセージを送信する際にこれらの新しい手がかりを用いてもよい。一般に、応答メッセージ中の手がかりは例えば、モバイルノードによってホームエージェント発見メッセージ中に含められる当該モバイルノードのかつての位置の情報に基づいて、ホームエージェント（発見サーバー）によって決定されてもよい。

本発明の例示的な一実施形態によると、ネットワークベースのモビリティ管理方式を提供するアクセスシステムにモバイルノードが当初接続したときに選択されたホームエージェントに、モバイルノードをリダイレクトさせるホームエージェントであって、前記モバイルノードがクライアントベースのモビリティ管理方式を提供するアクセスシステムへの接続を行う際、前記ホームエージェントとセキュリティアソシエーションを確立するためのＩＫＥｖ２要求メッセージであって、前記モバイルノードの識別子を含むＩＫＥｖ２要求メッセージを前記モバイルノードから受信する受信部と、ネットワークベースのモビリティ管理方式を提供する前記アクセスシステムに前記モバイルノードが当初接続したときに選択された前記ホームエージェントのＩＰアドレスを含んでいるリダイレクト情報を含むＩＫＥｖ２応答メッセージを前記モバイルノードに送信する送信部とを備えるホームエージェントが提供される。

また、本発明のホームエージェントにおいて、クライアントベースのモビリティ管理方式を提供する前記アクセスシステムにおいて、前記モバイルノードによって発見された前記ホームエージェントが、ネットワークベースのモビリティ管理方式を提供する前記アクセスシステムに前記モバイルノードが当初接続したときに選択された前記ホームエージェントとは異なることは、本発明の好ましい態様である。

また、本発明のホームエージェントにおいて、前記ＩＫＥｖ２要求メッセージのあて先アドレスとして、エニーキャストアドレス又はマルチキャストアドレス又はユニキャストアドレスが用いられることは、本発明の好ましい態様である。

また、本発明のホームエージェントにおいて、前記ＩＫＥｖ２応答メッセージ中に含める前記リダイレクト情報を、前記モバイルノードによってＩＫＥｖ２要求メッセージ中に提供された前記モバイルノードの識別子に基づいて決定することは、本発明の好ましい態様である。

また、本発明のホームエージェントにおいて、クライアントベースのモビリティ管理方式が用いられるドメイン内に位置していることは、本発明の好ましい態様である。

また、本発明のホームエージェントにおいて、前記モバイルノードの識別子が、ネットワークアクセス識別子（ＮＡＩ）であることは、本発明の好ましい態様である。

また、本発明のホームエージェントにおいて、前記モバイルノードの識別子が、前記モバイルノードに割り当てられたネットワークアクセスプレフィックスであることは、本発明の好ましい態様である。

以下において、本発明は添付図面を参照してより詳細に記載される。図面中の類似の又は対応する詳細事項には、同一の参照番号が付けられている。
Ｄｕｐｏｎｔらの「モバイルＩＰｖ６／ＮＥＭＯブートストラップにおけるＩＫＥｖ２- ベースのホームエージェント割り当て」によるＩＫＥｖ２シグナリング手順を示す。 様々なネットワークエリア内に様々なモビリティ管理方式を提供する例示的なパケット交換方式のネットワークを図示し、これに基づいて、本発明の各態様がより詳細に例示的に説明される。 モバイルノードをサーブするホームエージェントを発見し、及び、当該モバイルノードを発見されたサービングホームエージェントに登録するための、本発明の例示的な一実施形態による例示的なシグナリングフローを示す。 モバイルノードをサーブするホームエージェントを発見すること、サービングホームエージェントとのＩＰｓｅｃセキュリティアソシエーションを確立すること、及び引き続いて、当該サービングホームエージェントへとバインディングアップデートを送信することを許容する、本発明の例示的な実施形態による修正されたＩＫＥｖ２シグナリング手順を示す。 モバイルノードをサーブするホームエージェントを発見し、及び、当該モバイルノードを発見されたサービングホームエージェントに登録するための、本発明の例示的な一実施形態による例示的なシグナリングフローを示し、第１ホームエージェント発見メッセージを受信するホームエージェントは、当該モバイルノードをサーブするホームエージェントを識別しなくてもよい。 本発明の例示的な一実施形態による、修正された動的なホームエージェント発見手順の例示的なシグナリングフローを示す。 モバイルノードが登録されているホームエージェントを発見するための認証オプションを用いた、本発明の例示的な一実施形態による拡張されたバインディングアップデート手順を示す。 モバイルノードが登録されているホームエージェントを発見するための本発明の例示的な一実施形態による例示的なＤＨＣＰシグナリングを示す。 本発明の別の態様による例示的なシナリオを示し、モバイルノードのためのデータパスが、信頼されたアクセスネットワークから信頼されていないアクセスネットワークへの当該モバイルノードの移動の後に最適化される。

以下において、本発明の諸原理を様々な実施形態に関して説明する。例示目的のために、以下の例のほとんどはネットワークベースの移動性方式からクライアントベースの移動性方式への変更、又は、プロキシモバイルＩＰドメインの受信可能地域から出て、（クライアント）モバイルＩＰが用いられるネットワーク領域に入るモバイルノードに関する。

モバイルノードがネットワークベースのモビリティ管理を用いるネットワークに接続しつつある時は、当該ネットワークは当該モバイルノードのためにアンカ（ホームエージェント／ローカルモビリティアンカ）を選択し、標準的なシグナリング機構を用いて当該モバイルノードをこのホームエージェント／ローカルモビリティアンカに登録する。当該モバイルノードが、ネットワークベースのモビリティ管理を用いるこのネットワークエリアから、ホストベースのモビリティ管理が用いられるネットワークエリアへと移動する場合には、この新しいネットワークエリア内のＩＰアドレスプレフィクスは典型的には、ネットワークベースのモビリティ管理を用いるネットワークエリア内のモバイルノードに提供されるもの（ＰＭＩＰの場合、当該モバイルノードのホームアドレスプレフィクス）とは異なる。したがって、モバイルノードは、新しいアクセスエリア内で通知されたプレフィクスにしたがって新しいＩＰアドレスを構成するとともに、新たに構成されたアドレスを自身の気付アドレスとして自身のアンカ（ホームエージェント）に登録する必要がある。

セッション継続性を提供するためには、モバイルノードは、ネットワークベースのモビリティ管理を用いた際に自身が登録した同一のアンカ（ホームエージェント）に登録する必要がある。言い換えれば、モバイルノードがＰＭＩＰドメインを離れて、（ＰＭＩＰドメイン内で提供されたＩＰアドレスプレフィクスとは異なるＩＰアドレスプレフィクスを持つ）別のドメインに入る場合には、当該モバイルノードは、位相的に正しいＩＰアドレスを、ＰＭＩＰドメイン内の自身のＰＭＩＰプロキシによって登録されていたＰＭＩＰドメイン内のホームエージェントに登録する必要がある。したがって、モバイルノードは、ネットワークが当該モバイルノードをかつて登録したことがあるホームエージェントのアドレスを発見するために、有効化されるべきである。その理由は、ＰＭＩＰドメイン内でのモバイルノードの登録は当該モバイルノードに対してトランスペアレントであったため、その結果、当該モバイルノードは自身のサービングホームエージェントを知らないからである。

とりわけ、モバイルノードが多くのホームエージェントを有する巨大なパケット交換方式ネットワーク（例えば、中国、インド又は米国内の大規模事業者のネットワーク）内を移動中であり、当該モバイルノードが初期接続以降のセッション中に遠距離を移動してきた場合には、当該モバイルノードが、（クライアント）モバイルＩＰブートの開始時に異なるネットワーク領域内で誤ったホームエージェントを発見する可能性がある。その理由は、ホームエージェントの発見又は割り当てのメカニズムは典型的には、モバイルノードの現在位置に近いホームエージェントを割り当てるよう設計されているからである。例えば、エニーキャストホームエージェント発見メッセージは典型的には、すべてのエニーキャストグループメンバーのうち最も近いメンバーへと配信される。しかしながら当該メンバーは、必ずしも、移動後に新しいネットワーク領域内でのブートの前にモバイルノードをサーブしていたホームエージェントではない。

図２は、様々なネットワークエリア内の様々なモビリティ管理方式を提供する例示的なパケット交換方式のネットワークを図示し、これに基づいて本発明の各態様が例示的により詳細に説明される。例えば、当該ネットワークの一方のエリア内には、自身の無線アクセスネットワークを介してアクセスを提供する３ＧＰＰベースのネットワークと、ネットワークベースのモビリティ管理があってもよく（図２の左側を参照のこと）、一方、第２のネットワークエリア（図２中右側を参照のこと）があり、例えば無線ＬＡＮアクセスが提供され、クライアントベースの移動性方式が用いられる。当該第１及び第２のネットワークエリアは典型的には、無線リンク上の様々なアドレスプレフィクスを通知する。

事業者又はその一部のコアネットワークは、モバイルノードのＣＭＩＰホームネットワークとみなされもよい。各アクセスネットワークに接続されたコアネットワークは、異なる領域に論理的に分割されてもよく、領域番号１のコアネットワークは三つのホームエージェント２０４、２０５、２０６を備え、当該ホームエージェントでは、モバイルアクセスゲートウェイＭＡＧ２０１、２０２、２０３が、３ＧＰＰネットワークエリア内に提供されるＰＭＩＰドメイン内のモバイルノードを登録する。さらに、異なるコアネットワーク領域内のホームエージェントアドレスの各アドレスプレフィクスは同じであっても又は異なっていてもよい。ある特定領域の各ホームエージェントは、それぞれが一般的なグループ識別子（例：ＤＮＳ名、エニーキャストアドレス又はマルチキャストアドレス）を持つ異なるグループに割り当てられてもよい。

領域番号２のコアネットワークもまた三つのホームエージェント２０８、２０９、２１０を備え、当該ホームエージェントはアクセスルータＡＲ２０７によってアクセスネットワークに接続されている。異なるコアネットワーク領域内の各ノードは相互に接続されており、また、インターネットに接続したいくつかのあて先（例：通信相手）へとトラフィックを経路設定するべくインターネットに個別に接続されてもよい。例示目的のために、３ＧＰＰベースのアクセスを提供するとともにネットワークベースの移動性方式を用い、コアネットワーク領域番号１が割り当てられているネットワークエリアは、地理的には中国の上海に位置している。一方、ＷＬＡＮアクセス及びクライアントベースのモビリティ管理方式を提供するとともに、コアネットワーク領域番号２が割り当てられているネットワークエリアは地理的には中国の北京に位置している。

モバイルノード２００は、ネットワークベースのモビリティ管理を用いており、ホームエージェント２０４をモバイルノード２００に割り当てる中国の上海の３ＧＰＰベースのネットワークエリアに初期接続されると想定されてもよい。次いでモバイルノード２００のユーザは中国の北京へと遠距離を移動し、北京において、ホストベースのモビリティ管理を用いるネットワークエリアへと移動する。中国の北京で（クライアント）モバイルＩＰｖ６のブートを開始する場合は、モバイルノード２００はコアネットワーク領域番号２内の三つのホームエージェントのうち一つ（例えば、ホームエージェント２０８）を発見し、当該ホームエージェントはモバイルノードが登録されているホームエージェント２０４ではなく、それゆえ「誤った」ホームエージェントであり、セッション継続性を提供できない。

この望ましくない状況を克服するために本発明によって検討される一アプローチは、モバイルノード２００がまず自身が移動したネットワークエリア内にある任意、のホームエージェントを発見することを開始し、及び、当該移動モード２０１が自身の新しいアドレスを発見したホームエージェント（この例ではホームエージェント２０８）に登録するよう試行する時には、当該ホームエージェント２０８は、モバイルノード２００を正しいホームエージェント（この例ではホームエージェント２０４）へと移転させることである。しかしながらこのアプローチは、ネットワーク内のすべてのホームエージェントのバインディングキャッシュを同期化して、その結果、すべてのホームエージェントがあらゆるモバイルノードの正しいホームエージェントを知っており、バインディングアップデート手順の間にモバイルノードを正しいホームエージェントへと移転させることができる必要がある。明らかに、多くのホームエージェント及びモバイルノードがサーブされる大きなネットワークでは、これは煩雑かつ不効率でありうるものの、ＡＡＡサーバーといった別のエンティティへの移転決定を取り除くことによって解決されうる。

たとえかかるソルーションが実装されても、別の重大な論点はハンドオーバー遅延である。この提案されたソルーションにおけるハンドオーバー遅延は、ハンドオーバーの前にホームエージェント発見を先を見越して行うことができない場合に（常に可能ではない）、非常に高いと想定してもよい。その理由は、当該モバイルノードはまずセキュリティアソシエーションをブートストラップし、次いで誤ったホームエージェントに登録し、次いでセキュリティアソシエーション及び登録を再び解体し、及び最後に、ブートを正しいホームエージェントで開始する必要があるからである。このことは、（ユーザの観点から）サービスの望ましくない割り込み又は受容できない割り込みさえももたらしうる。ＡＡＡのような中央エンティティへの移転決定を取り除くことは、典型的にはホームエージェントと中央エンティティ（ＡＡＡサーバー）の間に追加的なシグナリングを必要とするので、ハンドオーバー遅延をさらに増大させうる。

本発明の主な態様による別の、潜在的により好ましいアプローチは、当該モバイルノードが、自身が登録されている自身のホームエージェントを発見することが必要である時に、自身のかつての移動又は位置についての情報をネットワークに明らかにすることである。モバイルノードからのかかる情報を含むホームエージェント発見メッセージがホームエージェント又はホームエージェント発見サーバーによって受信される場合は、当該ホームエージェント又はホームエージェント発見サーバーは、モバイルノードが登録されているホームエージェントを当該モバイルノードが発見するのを支援する手がかりをモバイルノードへと返すことができる。モバイルノードは、例えば、当該モバイルノードの移動、当該モバイルノードの信頼されていないアクセスネットワークへの移動等に起因するモビリティ管理方式の変更の直後に、例えば自身のサービングホームエージェントを発見するよう試みてもよい。

ホームエージェント又はホームエージェント発見サーバーによってそれに対する応答に含められた情報は、例えば、モバイルノードが有効なアドレス（例：エニーキャストグループアドレス、マルチキャストグループアドレス又はユニキャストアドレス）を導き出すのを可能にする手がかりを含んでもよい。一般に、モバイルノードに提供される１つ又は複数の手がかりは例えば、アドレスプレフィクス、アドレスサフィックス、又は、モバイルノードが登録されているホームエージェントが配置されるべきであると、当該ホームエージェント又はホームエージェント発見サーバーが想定するドメインのＤＮＳドメイン名（の一部）であってもよい。他の可能性は、利用可能な場合には、１つ又は複数のアドレスを応答メッセージに含めることである。

モバイルノードに提供されるべき手がかり又はリダイレクト情報を、ホームエージェント又はホームエージェント発見サーバーが決定するのを援助するために、例えば当該モバイルノードは、当該ホームエージェント発見メッセージに、モビリティ管理方式を変更するか信頼されていないアクセスネットワークに接続する前の、初期接続時の当該モバイルノードの位置といった、当該モバイルノードの位置又は移動を示す情報を含めてもよく、これによって、当該ネットワークが、ネットワーク内のすべてのホームエージェントのバインディングキャッシュの同期化を求めることなく、モバイルノードをサーブしているホームエージェントを識別するのを手助けしうる。

本明細書中では位置情報とも呼ばれるかかる情報は、例えば、識別子（例えば、ＩＰアドレス、基地局のレイヤ２アドレス（例：ＭＡＣアドレス）等）、当該モバイルノードが接続したモバイルアクセスゲートウェイ又はアクセスルータ、（例えば、ＧＰＳ受信器から取得される）当該モバイルノードの地理的位置、セルＩＤ、ＳＳＩＤ、ルーティング／トラッキングエリア、公衆地上移動ネットワーク識別子、又は、さらに通告されたサービス情報、アクセスネットワーク又はアクセス技術の種類であってもよい。当該モバイルノードは、定期的又はイベントによってトリガされるベース等で当該モバイルノードによって決定される、初期接続時の自身の位置について及び／又は当該パケット交換方式ネットワーク内を移動中に自身が訪問した位置についての情報を含んでもよい。一部の場合には、ホームエージェント又はホームエージェント発見サーバーが、モバイルノードをサービングホームエージェントの正しい位置又はアドレスについての手がかりを取得するのを可能にするためには、単一のかつての位置（例えば、初期接続時の位置）のみを、ホームエージェント発見メッセージに含めることで十分であるかもしれない。

位置情報に加えて、又は代替的に、モバイルノードはまた、当該モバイルノードの識別子をホームエージェント発見メッセージ中に指示してもよい。例えば、かかる識別子はモバイルノードのＮＡＩ、自身の現在のアドレス又はプレフィクスであってもよい。

それゆえに、当該ホームエージェント又はホームエージェント発見サーバーは、モバイルノードの識別子及び／又はホームエージェント発見メッセージ中の位置情報に基づいて、自身が当該ホームエージェント発見応答メッセージ内の要求側モバイルノードと通信する手がかりを導き出すことができる。さらに、当該ホームエージェント又はホームエージェント発見サーバーは、別の情報、マッピング情報を保持してもよく、このことによって、位置情報及び／又は当該モバイルノードの識別子（の一部）を当該モバイルノードが正しいホームエージェントを発見するのを支援する手がかりにマッピングすることを可能にする。例えば、ホームエージェントは、手がかりとしてモバイルノードに提供される、パケット交換方式ネットワーク内の所定の領域を識別することを可能にするモバイルアクセスゲートウェイ識別子、例えば、ドメイン又はアドレスプレフィクスのリストを保持しうる。別の選択肢は、識別されたネットワーク領域に基づいて、ホームエージェントが、当該ホームエージェント又はホームエージェント発見サーバーが当該モバイルノードに提供する経路設定可能なアドレス（エニーキャスト、マルチキャスト、又はユニキャスト）を決定できることであってもよい。

いくつかの場合には、第１ホームエージェント発見メッセージが送信されたエンティティから受信された応答メッセージ中の手がかりは、サービングホームエージェントを固有に識別するためには十分であったかもしれない（たとえユニキャストアドレスが応答メッセージ中において第１ホームエージェントアドレス発見メッセージに対して提供される場合であっても、このアドレスは、モバイルノードが登録されているホームエージェントのアドレスであるべきであるが、必ずしもそうである必要ではないことに留意すること）。随意的には、ホームエージェント発見メッセージは、当該ホームエージェント発見中に手がかりの確実性を示すフラグを持ってもよい。例えば、ホームエージェントが、モバイルノードが登録されているホームエージェントの（ユニキャスト）ホームエージェントアドレスを識別できる場合には、当該ホームエージェントは（ユニキャスト）ホームエージェントアドレスを応答メッセージ中に含めるとともに、そして、指示されたアドレスが正しいことを当該ホームエージェントが確信していることを当該モバイルノードに対して示すために、その中にフラグを設定してもよい。これによって、シグナリングオーバーヘッドを低減することが可能である。モバイルノードは、指示されたホームエージェントが実際に当該モバイルノードが登録されているホームエージェントであるか否かを確認しなくてもよく、そして、当該モバイルノードは当該ホームエージェントへと送信される次のメッセージ中に位置情報を含める必要はない。

ホームエージェント発見応答中の情報が正しくない場合は、モバイルノードによって送信された別のホームエージェント発見メッセージを受信するホームエージェントはまた、当該モバイルノードが正しいアンカを発見するのを支援する新しい手がかりを含む応答メッセージを当該モバイルノードに戻してもよく、そして、当該モバイルノードは別のホームエージェント発見メッセージを送信する際に当該新しい手がかりを用いてもよい。一般に、応答メッセージ中の手がかりは、例えば、モバイルノードによってホームエージェント発見メッセージ中に含められた当該モバイルノードのかつての位置（１つ又は複数）についての情報に基づいて、ホームエージェント又はホームエージェント発見サーバーによって決定されてもよい。

一般に、術語「ホームエージェント発見メッセージ」及び「ホームエージェント発見サーバー」が本明細書中に用いられてきたことに留意するべきである。その理由は、モバイルノードの位置情報をいずれのシグナリング手順に含めるかについては異なる可能性があるからである。したがって、術語「ホームエージェント発見メッセージ」は、モバイルノードの位置情報とモバイルノード識別子のうち少なくとも一つを含むとともに、当該ホームエージェント発見メッセージを受信するエンティティがモバイルノードが登録されているホームエージェントでない場合には、当該モバイルノードが自身のサービングホームエージェントを発見することを可能にする手がかりを送信することによって、受信側ノードに応答（「ホームエージェント発見応答」）するようトリガするシグナリングメッセージとして理解されるものとする。この点において、ホームエージェント発見サーバーは、ホームエージェント発見メッセージを受信し、それに応答している、移動体通信システムのコアネットワーク又はパケット交換方式ネットワーク内のサーバー又はネットワークノードのことを示す。

ホームエージェント発見メッセージ及び応答は、例えば既存のシグナリング手順に追加される新たに定義されるシグナリングメッセージであってもよく、又は、既存のシグナリング手順の拡張されたシグナリングメッセージであってもよい。例えば、いくつかの実施形態では、ホームエージェント発見メッセージとそれに対する応答メッセージは、モバイルノードを認証するための、又は、共有されたキーを交換するとともに当該モバイルノードとホームエージェント発見メッセージを受信するノードとの間のセキュリティアソシエーションを確立する認証手順のメッセージである。この認証手順は例えば、ＩＰｓｅｃセキュリティアソシエーションを確立するためのＩＫＥｖ２シグナリング手順（本明細書中に以前に記載されたＩＥＴＦＲＦＣ ４３０６、ＩＥＴＦ ＲＦＣ３７７６、及びＩＥＴＦ ＲＦＣ４８７７を参照のこと）であってもよく、ホームエージェント発見メッセージとそれに対する応答はこのシグナリング手順の修正されたメッセージであってもよい。

本発明のいくつかの他の実施形態では、ホームエージェント発見サーバーへと送信されたホームエージェント発見メッセージは、位置情報によって拡張される（ＩＥＴＦ ＲＦＣ４２８５中に提供される）認証オプションを含むバインディングアップデートである。したがって、この例示的な実施形態中のホームエージェント発見サーバーはホームエージェントであり、そして、その応答メッセージは、モバイルノードが正しいホームエージェントを発見するのを支援する手がかりを追加的に含むバインディング受信確認である。

本発明のさらに他の実施形態では、ホームエージェント発見サーバーへと送信されたホームエージェント発見メッセージは、追加的な位置情報及び任意でモバイルノードの識別子を含むＤＨＣＰ情報要求メッセージである。したがって、この例示的な実施形態におけるホームエージェント発見サーバーは、モバイルノードが正しいホームエージェントを発見するのを支援する手がかりを含むＤＨＣＰ情報応答によって、ＤＨＣＰ要求メッセージに応答しているＤＣＨＰサーバーである。

図３は、本発明の例示的な一実施形態による、モバイルノード２００をサーブするホームエージェントを発見し、そして、モバイルノード２００を、発見したサーブするホームエージェント２０４に登録するための例示的なシグナリングフローを示す。モバイルノード２００はネットワークを通って移動している間には進行中のセッションを有し、及び、ＰＭＩＰドメイン内に位置している時には、ネットワークベースのモビリティ管理プロトコル（ここでは例示目的のためにプロキシＭＩＰｖ６）を活用して、セッションデータを転送する３０１と想定されうる。

例えば、モバイルノード２００は、ハンドオーバー／ＰＭＩＰドメインのアクセスネットワークへの受信可能地域を失うか、ＰＭＩＰドメインを離れるか、又は、より良いサービスの質が別のアクセス技術によって提供可能なネットワークエリアへと移動した直後に、モビリティ管理方式（ここでは例示目的のためにクライアントＭＩＰｖ６）を変更する（ステップ３０２）。クライアントＭＩＰｖ６への変更は、クライアントＭＩＰｖ６ネットワークエリアの内部のモバイルノード２００での通信のための新しい位相的に正しい気付アドレスの構成（例えば、サブネット又は（サブ）ドメイン）を必要とする。セッション継続性を保証するためには、モバイルノード２００は、モビリティ管理方式を変更する前に、自身の新たに構成された気付アドレスを、モバイルノード２００をサーブしてきたホームエージェントに登録する必要がある。モビリティ管理方式のクライアントＭＩＰｖ６への変更の前に、初期接続の直後にプロキシＭＩＰｖ６が用いられてきたので、モバイルノード２００は、自身のサービングホームエージェントを知らないと想定されうる。

モバイルノード２００は、ホームエージェント発見メッセージを新しいネットワークエリア（この例ではクライアントＭＩＰｖ６アクセスネットワークエリア及びコアネットワーク領域番号２）へと送信する（ステップ３０３）。このメッセージは例えば、ネットワーク内のすべてのホームエージェントのエニーキャストアドレスをあて先アドレスとして用いて、送信されてもよい。

ホームエージェント発見メッセージは、当該メッセージの受信者がモバイルノードをサーブしている正しいホームエージェントを識別する（ステップ３０４）のを支援するか、又は、サービングホームエージェントが見出されるべきである位置又はネットワークエリアに関する手がかり（例：コアネットワーク領域番号１への手がかり）をモバイルノード２００に提供することを少なくとも可能にしうるというローカル情報を含んでいる。

ホームエージェント発見メッセージに含められたローカル情報は例えば、移動性方式（この例ではプロキシＭＩＰｖ６ドメイン）を変更する前のネットワークエリア内のモバイルノード２００の初期の接続ポイントについての情報であってもよい。その理由は、この初期の接続ポイントは、ネットワークがモバイルノード２００のためにホームエージェントを割り当てるとともに、ホームエージェント割り当てアルゴリズムは典型的にはモバイルノードの現在位置を考慮している場所であるからである。

接続のポイントは、例えば、前に述べたように、識別された地理的位置（例えば、モバイルノード２００がＧＰＳ受信器を備える場合）、ＭＡＧ／デフォルトルータのＩＰアドレス、セルＩＤ、ＳＳＩＤ、（モバイルノード２００が以前３ＧＰＰアクセス内にあった場合には）ルーティング／トラッキングエリア、公衆地上移動ネットワーク識別子、通告されたサービス情報、アクセスネットワーク又はアクセス技術の種類でありうる。ネットワークがモバイルノードに割り当てるＰＭＩＰホームアドレス及びプレフィクスが特定のホームエージェントに宛てられる場合は、モバイルノードのアドレスのプレフィクスは、モバイルノード２００がホームエージェント発見メッセージ中に含んでもよくかつ初期接続時の当該モバイルノードのホームエージェント（例：３ＧＰＰ ＳＡＥネットワーク内のＰＤＮ−ＧＷ）をネットワークが識別するのを手助けしてもよい別のローカル情報である。プロキシモバイルＩＰが、モバイルノード２００の自身のＰＭＩＰプロキシとのトンネルインタフェースに基づいていた（例えば、３ＧＰＰ ＳＡＥネットワーク内のｅＰＤＧがＰＭＩＰプロキシとしてモバイルノード２００をサーブしてきた）場合は、当該モバイルノードはまた、位置情報として、トンネル終点ＩＰアドレス（例：ｅＰＤＧのＩＰアドレス又はｅＰＤＧによって当該モバイルノードに割り当てられた遠隔のアドレス）といったトンネル終点についての情報の信号を送ってもよい。

一般に、ホームエージェント発見メッセージは、以下のパラメータ：ネットワークがモバイルノードを識別するのを可能にするモバイルノード識別子（例：ＮＡＩ又は疑似ＮＡＩ）、セッションを識別するセッション識別子（ＰＭＩＰホームアドレス）、及び、既存のセッションを継続するためのホームエージェント／ローカルモビリティアンカが要求されている旨のフラグのうち一つ以上を任意で含む。モバイルＩＰの実際的な実装において、ＭＩＰが多くの場合ＡＡＡとの接続に用いられることに留意するべきである。したがって、各ホームエージェント内のバインディングキャッシュエントリーは典型的には、各モバイルノードのそれぞれのホームアドレスによって識別されるだけでなく、ＮＡＩもバインディングを体系化し及び検索するのに追加的に用いられる。

プロキシＭＩＰｖ６ドメインからクライアントＭＩＰｖ６ネットワークエリアへと移動する例では、モバイルノード２００は当該モバイルノードを識別するＮＡＩ又は疑似ＮＡＩの信号を送ってもよい（この識別子はホームエージェントによって登録バインディングキャッシュ中の気付アドレスを保持及び識別するために用いられると想定してもよいため）。したがって、ホームエージェントが、指示されたモバイルノード識別子のためのバインディングキャッシュエントリーを保持しない場合には、当該ホームエージェントは、自身がモバイルノード２００をサーブしていない（これまでサーブしていなかった）とともに、モバイルノード２００をサーブするホームエージェント又はサービングホームエージェントへの手がかりを識別する（ステップ３０４）ことを想定してもよい。

図３に示される例では、ホームエージェント発見メッセージは、コアネットワーク領域番号２内のホームエージェント２０８へとルーティングされる（図２を参照のこと）。例示目的のために、ホームエージェント２０８が、モビリティ管理方式を変更する前にモバイルノード２００をサーブしてきた正しいホームエージェントのアドレス（すなわちホームエージェント２０４のアドレス）を識別しうることがさらに想定される。したがって、ホームエージェント２０８は、ホームエージェント発見メッセージに応答してモバイルノード２００へと送信される（ステップ３０５）応答メッセージ中に、リダイレクト情報オプションを含める。このリダイレクト情報はホームエージェント２０４の（ユニキャスト）アドレスを含む。

ホームエージェント２０８からのホームエージェント発見応答は、モバイルノード２００に当該ホームエージェント２０８が自身がサーブ中であるホームエージェントでないことについて通知する。モバイルノード２００は応答メッセージ中にリダイレクト情報オプションを検知し、及び、その中の情報をユニキャストアドレスとして識別する（ステップ３０６）。したがって、モバイルノード２００は、別のホームエージェント発見メッセージを生成し、そして、ホームエージェント２０８から受信された（ステップ３０５）当該ホームエージェント発見応答メッセージ中に指示されたアドレスを、新しいホームエージェント発見メッセージのあて先として用いて、当該ホームエージェント発見メッセージをホームエージェント２０４へと送信する（ステップ３０７）。

この新しいホームエージェント発見メッセージのコンテンツは、ホームエージェント２０８へと送信された（ステップ３０３）コンテンツと類似していてもよい。ホームエージェント発見メッセージを受信する（ステップ３０７）ホームエージェント２０４は、サービングホームエージェントであるので、当該ホームエージェント２０４は、自らがモバイルノード２００が登録されているホームエージェントであることを示す別のホームエージェント発見メッセージを付けて、応答する（ステップ３０８）。応答を受信した直後に、モバイルノード２００は、バインディングアップデートをホームエージェント２０４へと送信して（ステップ３０９）、当該モバイルノードのバインディングを更新中であるホームエージェント２０４に新しい（気付）アドレスを登録し、そして、更新されたバインディングを受信確認する（ステップ３１０）。モバイルノードのバインディングを更新した直後に、ホームエージェント２０４及びモバイルノード２００はセッションを継続することができ、セッションデータを交換してもよい（ステップ３１１）。

本発明の別の実施形態では、図３の手順がさらに最適化されてもよい。例えば、バインディングアップデートを送信するために必要なすべての情報が、モバイルノード２００に対して利用可能な場合、例えば、当該バインディングアップデート中に含めまれるべきすべてのセキュリティに関連するパラメータはモバイルノード２００に対して利用可能であり、及び／又は、モバイルノード２００がホームエージェント２０８からの応答中に指示されたアドレスが正しいことを（例えば、当該応答中に設定中であるそれぞれのフラグによって）確信している場合には、ステップ３０６及びステップ３０７は省略されてもよく、及び、モバイルノード２００は、リダイレクト情報の付いたホームエージェント発見応答をホームエージェント２０８から受信した直後に、バインディングアップデートをホームエージェント２０４へと送信してもよい（ステップ３０８）。この例示的な実施形態では、モバイルノード２００は、ホームエージェント発見応答中のリダイレクト情報が正しいことを信頼してもよく、その結果、リダイレクト情報がユニキャストアドレスを示すか、又はあらゆる他の態様で正しいホームエージェントを固有に識別する場合には、モバイルノード２００は、リダイレクト情報が正しいサービングホームエージェント２０４と識別するものと想定してもよく（又はこの情報はフラグによって応答上に指示されてもよく）、その結果、いずれのホームエージェント発見メッセージもホームエージェント２０４へと送信される必要がない。同様に、たとえリダイレクト情報が特定のアドレスを指示しないが正しいホームエージェントを識別するのを支援する手がかり（例えば、図３に関して論じられた例でのコアネットワーク領域番号１のプレフィクス）を含むとともに、さらにモバイルノード２００が当該リダイレクト情報を用いてサービングホームエージェントを固有に識別してもよい（例えば、このプレフィクスの付いたホームエージェント１個のみ存在する）と想定する場合であっても、モバイルノード２００は、さらに別のホームエージェント発見メッセージを送信せずに、バインディングアップデートを送信してもよい。

一般に、いくつかの実施形態では、ホームエージェント発見メッセージ及び応答は、モバイルノードが自身のモビリティ管理方式を変更するか又はセッション継続性を保証するべく自身のサービングホームエージェントに登録される必要がある新しいアドレスを構成した直後に、行われる手順中の既存のシグナリングメッセージを拡張することによって実現されてもよいことに留意するべきである。登録の遅延を最小化するために、モバイルノードの位置情報及び当該モバイルノードをサーブするホームエージェントへの手がかりを含む応答は、当該モバイルノードが自身のモビリティ管理方式を変更するか又はセッション継続性を保証するべく自身のサービングホームエージェントに登録される必要がある新しいアドレスを構成した直後に行われるそれぞれの手順の第１のシグナリングメッセージ中に提供されてもよい。この態様は、図４に関して以下に例示的に概略説明する。

図４は、モバイルノードをサーブするホームエージェントを発見し、サービングホームエージェントとのＩＰｓｅｃセキュリティアソシエーションを確立し、そして、引き続いてバインディングアップデートを当該サービングホームエージェントへと送信することを可能にする、本発明の例示的な実施形態による修正されたＩＫＥｖ２シグナリング手順を示す。当該シグナリング手順は本質的に、ＩＥＴＦＲＦＣ ４３０６中に定義されるとともに、本明細書中に以前に記載されたＩＥＴＦ ＲＦＣ３７７６及びＩＥＴＦ ＲＦＣ４８７７中に示唆された別の構成を考慮するシグナリング手順に対応しており、このため、以下の記載ではこの例示的な実施形態によってこの手順によって適用される変化に焦点を当てる。

例示目的のためには、図３に関して概略説明された状況と実質的に類似した状況が、想定されてもよい。モバイルノード２００は、ネットワークのＰＭＩＰドメイン内のプロキシＭＩＰｖ６を用いることから当該ネットワークのクライアントＭＩＰｖ６サービスエリアへと自身のモビリティ管理方式を変更する（ＰＭＩＰ→ＣＭＩＰの移行）と想定されうる。モバイルノード２００は、クライアントＭＩＰｖ６が用いられる新しいネットワークエリア中に通告されたプレフィクスに基づいて新しいＩＰアドレス（気付アドレス）を設定し、そして、例えば、ネットワーク内のホームエージェントの前もって定められたＵＲＩのためのＩＰアドレスを取得するよう、ＤＮＳサーバーに問い合わせてもよい（例えば、ＤＮＳ記録中に「ｈｏｍｅａｇｅｎｔｓ．ｅｘａｍｐｌｅ．ｃｏｍ」のためのＤＮＳ入力が存在してもよい）。ＤＮＳサーバーは、ネットワーク内のホームエージェントが所属するエニーキャストグループのエニーキャストアドレス（ＡＮＹＣＡＳＴ）を返す。代替的には、エニーキャストアドレスはモバイルノード２００に知られていてもよく、又は、（例えば、ローカルホームエージェントアドレス又はプレフィクスのためのＤＨＣＰオプション中に）クライアントＭＩＰｖ６ネットワークエリア中に通告されたプレフィクスに基づいて構成されてもよく、その結果、この場合にはいかなるＤＮＳ要求も必要でない。

上記に指示したように、非サービングホームエージェントがホームエージェント発見メッセージを受信する場合には、ＩＫＥｖ２シグナリング手順中にできるだけ早くモバイルノード２００をリダイレクトすることが望ましい。位置情報を含む時間における最も早い時点は、セキュリティアソシエーション設定の第１のメッセージであろうと考えられ、当該第１のメッセージはＩＫＥｖ２シグナリング手順を用いる場合は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージである。それゆえに、この例示的な実施形態では、ＩＫＥｖ２シグナリング手順のＩＫＥ＿ＳＡ＿ＩＮＩＴ要求は、モバイルノードの位置情報を含むよう拡張されており、したがって、ホームエージェント発見メッセージの例示的な実装を表す。

位置情報は例えば、このシグナリングメッセージ中に新たに定義されるオプション中に含まれてもよい。これは、図４において、位置情報（例：ＰＭＩＰドメイン内のＭＡＧをサーブするモバイルノード２００のＭＡＧ ＩＰアドレス）を含むオプション「初期接続ｉｎｆｏ」の形式で例示的に図示される。さらに、ＩＫＥｖ２シグナリング手順のＩＫＥ＿ＳＡ＿ＩＮＩＴ要求は、モバイルノードの識別子の信号を送るためのオプションを含むように拡張されてもよい。これは図４において、例えば、モバイルノードのＮＡＩ又は疑似ＮＡＩでありうるパラメータＩＤを含むＩＫＥ＿ＳＡ＿ＩＮＩＴ要求によって指示される。

このＩＫＥ＿ＳＡ＿ＩＮＩＴ要求はエニーキャストアドレス（エニーキャスト）をあて先アドレスとして、及び、新たに構成されたモバイルノードの（気付）アドレスをソースアドレスとして用いて送信される。これは図４において、新たに構成された気付アドレスＣｏＡに対応するポート５００上のソースアドレスからポート５００に対するあて先ＡＮＹＣＡＳＴへとＩＫＥ＿ＳＡ＿ＩＮＩＴ要求が送信されることを意味する[ＣｏＡ：５００→ＡＮＹＣＡＳＴ：５００]によって例示的に示される。類似の表記が、図４に示す残りのシグナリングメッセージに対して用いられる。

ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求はホームエージェント２０８において受信され、当該ホームエージェント２０８は、当該メッセージを処理するとともに、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求中のモバイルノードのＮＡＩに対するバインディングキャッシュエントリーを識別できなかったことを理由に、自身がモバイルノード２００をサーブしていないことを認識する。したがって、ホームエージェント２０８は、位置情報、及び任意にネットワークトポロジー、ドメインプレフィクス等に関する追加的な知識を用いて、モバイルノード２００をサーブするホームエージェントを識別するよう試み、そして、ネットワークのＰＭＩＰドメインに接続する時に当該モバイルノードが最初に登録された潜在的なホームエージェントのホームエージェントアドレスＨＡ＿ＡＤＤＲＥＳＳを識別する。

ホームエージェント２０８は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求に対して、拡張されたＩＫＥ＿ＳＡＪＮＩＴ応答で応答する。このＩＫＥ＿ＳＡ＿ＩＮＩＴ応答は、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求を処理し、自身がモバイルノードのサービングホームエージェントでないことを検知する時には、ホームエージェントによって識別された正しいホームエージェント（又は自身のアドレス）に対する手がかりを含むリダイレクトオプションを含む。したがって、ホームエージェント２０８は、決定されたホームエージェントアドレスＨＡ＿ＡＤＤＲＥＳＳをＩＫＥ＿ＳＡ＿ＩＮＩＴ応答に含めて、当該応答メッセージをモバイルノード２００へと送信する。

ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答を受信するモバイルノード２００は、この応答を送信するホームエージェント２０８が、含められたリダイレクト情報に基づいてモバイルノード２００が登録されているホームエージェントでないことを認識した。したがって、モバイルノード２００は、ＩＫＥｖ２シグナリング手順に割り込んで、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求を、ホームエージェント２０８からのＩＫＥ−ＳＡ＿ＩＮＩＴ応答によって示されたあて先（この例ではアドレスＨＡ＿ＡＤＤＲＥＳＳ）、又は及び、モバイルノードがホームエージェント２０８からのＩＫＥ＿ＳＡ＿ＩＮＩＴ応答中のリダイレクト情報（手がかり）から導き出しうるアドレスへと向ける新しいＩＫＥｖ２シグナリング手順を開始してもよい（この動作は、モバイルノードがＩＫＥｖ２シグナリング手順を再開始すると称してもよい）。

ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求を受信する新しいホームエージェントは、自身がモバイルノードをサーブしていることに（ＮＡＩに基づいて）気が付き、そして、リダイレクト情報のない通常のＩＫＥ＿ＳＡＪＮＩＴ応答で応答する。モバイルノードは次いで、通常のＩＫＥｖ２シグナリングを継続し、そして、自身を認証し、ＩＰＳｅｃセキュリティアソシエーションを設定するべくＩＫＥ ＡＵＴＨメッセージを送信する。

ホームエージェント２０４からＩＫＥ＿ＡＵＴＨ応答メッセージを受信した直後に、モバイルノード２００は、ホームエージェント２０４とのＩＰｓｅｃセキュリティアソシエーションを確立し、したがって、新しい気付アドレスＣｏＡを自身のサービングホームエージェント２０４に登録するためのＭＩＰｖ６バインディングアップデートを生成及び送信するためのすべての関連するセキュリティパラメータを所有する。ホームエージェント２０４はバインディングを更新した直後に、ＭＩＰｖ６バインディング受信確認をモバイルノード２００へと送信する。

上記の図３及び図４を参照して記載された例示的な実施形態では、ホームエージェント発見メッセージを受信するホームエージェントが、（特に位置情報に基づいて）モバイルノードを識別するとともに、自らが登録されているホームエージェントについてモバイルノードに通知する能力があると想定されてきた。しかしながら、常にこのことがあてはまるわけではない。例えば、モバイルノードが、ホームエージェント発見メッセージを、正しいホームエージェントがメンバーであるエニーキャストグループへと送信する場合には、このグループ内の誤ったホームエージェントが当該メッセージを受信及び拒絶することが起こりうる。この場合には、モバイルノードは、当該メッセージが正しいホームエージェントへとルーティングされると期待するまで、同一のエニーキャストグループを備えたホームエージェント発見メッセージとともに送信することを再び試行するか、又は、当該誤ったホームエージェントがより精密な手がかり（例：正しいホームエージェントのユニキャストアドレス、又は、異なるエニーキャストグループを示す別のエニーキャストアドレス）を与えうる。ユニキャストアドレスを報告することは、例えば、ある一つのエニーキャストグループ内のすべてのホームエージェントが同一のエニーキャストグループのメンバーである他のすべてのホームエージェントのバインディングキャッシュを知っている場合に可能である。

このシナリオは、以下において図５に関してより詳細に例示的に概略説明される。図５は、本発明の例示的な一実施形態による、ホームエージェントをサーブするモバイルノード２００を発見するとともに、発見されたサービングホームエージェント２０４でモバイルノード２００を登録し、第１ホームエージェント発見メッセージを受信するホームエージェントは、当該モバイルノードをサーブするホームエージェントを識別しなくてもよい、例示的なシグナリングフローを示す。

実質的には、図３においてステップ５０１、５０２及び５０３はステップ３０１、３０２及び３０３に対応する。したがって、これら三つのステップに関しては上記の図３の記載が参照される。

ホームエージェント２０８は、図３のステップ３０４と本質的に類似したホームエージェント発見メッセージを処理する。しかしながら、今回は、ホームエージェント発見メッセージ中の位置情報（及び利用可能な別の情報）は、ホームエージェント２０８においてホームエージェントがサーブするモバイルノード２００を固有に識別するには十分ではない。しかしながら、ホームエージェント２０８に対して利用可能な情報は、例えば、領域番号１のＩＰアドレスプレフィクス、又はエニーキャストアドレス若しくはマルチキャストアドレス、又はＤＮＳ名をモバイルノード２００に示すには十分でないかもしれない。したがって、ホームエージェント２０８は、モバイルノード２００へと送信された（ステップ５０５）ホームエージェント発見応答中に、自身がモバイルノード２００が登録されているホームエージェントでないことを指示してもよく、そして、ホームエージェント２０８は、応答メッセージ中に、ＩＰエニーキャストアドレス若しくはマルチキャストアドレス、又はアドレスプレフィクス又はコアネットワーク領域番号１のＤＮＳ名を追加的に含んでもよい。

当該応答は、ホームエージェント２０８がモバイルノード２００がＰＭＩＰドメイン内に登録されていたホームエージェントでないことを、モバイルノード２００に対して通知する。モバイルノード２００は、コアネットワーク領域番号１のエニーキャストアドレス又はアドレスプレフィクス又はＤＮＳ名を示すリダイレクト情報をさらに用いて、アドレスプレフィクスに基づいてエニーキャストアドレスを決定する（ステップ５０６）。例えば、あるコアネットワーク領域内の各ホームエージェントはすべて、前もって定められた規則に従って自身のエニーキャストアドレスがネットワーク領域内に通告されたアドレスプレフィクスから決定されうるエニーキャストグループに属してもよく、その結果、モバイルノード２００はホームエージェント発見応答メッセージ中に提供されるアドレスプレフィクスから正しいエニーキャストアドレスを導き出すことができる。代替的には、リダイレクト情報は、モバイルノード２００がＤＮＳサービスを用いて解消するＤＮＳ名を含んでもよい。

ＰＭＩＰドメイン内のホームエージェントのエニーキャストアドレスを決定した直後に、モバイルノード２００はホームエージェント発見メッセージをこの決定したエニーキャストアドレスへと送信する（ステップ５０７）。ホームエージェント発見メッセージは、決定されたエニーキャストアドレスに宛てられていることを除いてステップ５０３のホームエージェント発見メッセージと類似している。

この例では、モバイルノード２００によって決定されるエニーキャストアドレスは、図２に示されるコアネットワーク領域番号１内のホームエージェント２０４、２０５、２０６のグループアドレスである。ホームエージェント発見メッセージは、エニーキャストグループのホームエージェント２０５へとルーティングされると想定されうるが、しかしながら、当該ホームエージェント２０５はモバイルノード２００が登録されているホームエージェントではない。この例において、ある一つのエニーキャストグループの各ホームエージェントが他のグループメンバーによって保持されるバインディングを知っていると想定されうるので、その結果、ホームエージェント２０５は、モバイルノード及び／又はホームエージェント発見メッセージ中に指示されたセッション識別子を用いて、モバイルノード２００が登録されているエニーキャストグループの正しいホームエージェントを識別できる（ステップ５０８）。したがって、ホームエージェント２０５は、当該ホームエージェント２０５が自身がモバイルノード２００をサーブするホームエージェントではないことを示すとともに、ホームエージェント２０４がホームエージェント発見応答メッセージのリダイレクトオプション中にホームエージェント２０４のＩＰアドレス（ＨＡアドレス）を含むホームエージェント発見応答を送信することによって、ホームエージェント発見メッセージに応答する（ステップ５０９）。

応答メッセージを受信して、モバイルノード２００はさらに別のホームエージェント発見メッセージを正しいホームエージェント２０４へと今や送信してもよく（ステップ５１０）、そして、ホームエージェントから肯定応答を受信し（ステップ５１１）、その直後に、モバイルノード２００は自身の新しい気付アドレスをホームエージェント２０４に登録し（ステップ５１２、５１３）、当該セッションを継続する（ステップ５１４）。いくつかのシナリオでは、ステップ５１０からステップ５１４は図３のステップ３０６からステップ３１０に対応する。ステップ５１０及びステップ５１１は、上記のステップ３０８及びステップ３０９のために記載されたように随意的であってもよい。先述したように、マルチキャストアドレス又はユニキャストアドレスは同様に、エニーキャストアドレスの代わりに用いられうる。

一般に、モバイルノードは、自身が登録されていたホームエージェントを見出すまで、過去のホームエージェント発見応答メッセージに指示されたか又はホームエージェント発見応答メッセージから導き出されたあて先へと、新しいホームエージェント発見メッセージを送信するのを継続してもよいことに留意するべきである。しかしながら、終了条件があり、その結果、自身のサービングホームエージェントを決して発見しないことは望ましいようである。したがって、本発明の別の実施形態では、異なる終了条件は定義されてもよい。

例えば、ホームエージェント発見応答中に含まれるホームエージェントの手がかりが誤り続けており、モバイルノードがホームエージェント発見メッセージを誤ったエニーキャストグループへと送信する場合には、モバイルノードがこの誤ったエニーキャストグループ内を永久に検索するのを防止する何らかの機構が存在しなければならない。一つの選択肢は、モバイルノードが単に試行の数（例：５回）を限定するとともに、これら試行のうち正しいホームエージェントの内部を見出さない場合には、当該モバイルノードは次のより高次の範囲を持つエニーキャストグループ（例：コアネットワーク内のサブ領域のホームエージェントだけでなく、より大きなコアネットワーク領域若しくはコアネットワーク全体を含むエニーキャストグループのすべてのホームエージェントを含むグローバルエニーキャストアドレス）へと切り替える。別の選択肢は、モバイルノードが、同一の誤ったホームエージェントがホームエージェント発見要求に所定の回数回答することに気が付いた時に、当該モバイルノードがトリガすることである。

同一の誤ったホームエージェントを複数回ヒットすることを防止するためのさらなる選択肢は、発見メッセージを受信する誤ったホームエージェントがエニーキャストアドレスを設定解除し、エニーキャストグループから離れることである。しかしながら、このことには、典型的にはモバイルノードごとに固有のホームエージェントエニーキャストアドレスを必要とし、その結果、他のモバイルノードのホームエージェント発見プロセスは影響を受けない。

さらに、ホームエージェント発見応答が正しいホームエージェントへの手がかりをより厳密には与えない可能性がある場合には、別の終了条件を必要としてもよい。例えば、それとは異なるが非サービングのホームエージェントは、ホームエージェント発見メッセージへと応答し続けているものの、それらの手がかりは繰り返しであるか又は誤っている可能性があり、その結果、モバイルノードによるさらに別のホームエージェント発見メッセージを送信しても、当該モバイルノードをサーブするホームエージェントを発見する際に進展をきたさないことも起こりうる。したがって、モバイルノードが繰り返して例えば同一の手がかり（例：同一であるが誤ったユニキャストＩＰアドレス）を受信する場合には、当該モバイルノードは発見手順に割り込んでもよい。

過剰に時間を消費するホームエージェント発見、又は、モバイルノードがループに捕捉されることを回避するために、上記に論じた異なる選択肢もまたともに用いてもよい。

当然のことながら、ＩＰｓｅｃセキュリティアソシエーションを確立するためのＩＫＥｖ２シグナリング手順は、本発明の原理及び思想が実装されうる唯一のシグナリング手順ではない。本発明の別の実施形態による別の選択肢は、ＩＥＴＦ ＲＦＣ ３７７５に知られている動的なホームエージェントアドレス発見（ＤＨＡＡＤ）中の原理及び思想を用いることである。この例示的な実施形態では、ＤＨＡＡＤ要求メッセージは例えば、位置情報及び任意にはモバイルノード識別子を含むことによって拡張されてもよい。

図６は、本発明の例示的な実施形態による修正された動的なホームエージェント発見手順の例示的なシグナリングフローを示す。図３及び図５のステップ３０１、３０２及びステップ５０１、５０２と同様に、モバイルノード２００には進行中のセッションがあってもよく、及びセッションデータを自身のホームエージェント２０４と交換し（ステップ６０１）、モビリティ管理方式を変更してもよい（ステップ６０２）。次に、モバイルノード２００は新しい気付アドレス（図示されない）を構成するとともに、コアネットワーク内の各ホームエージェントに割り当てられていた可能性のあるエニーキャストアドレス（エニーキャスト）を取得してもよい（ステップ６０３）。このことは、例えば、ＤＮＳサーバーにホームエージェントのネットワーク内のＩＰアドレスを問い合わせる（例えば、「ｈｏｍｅａｇｅｎｔｓ．ｅｘａｍｐｌｅ．ｃｏｍ」といった事前に構成されたＤＮＳ名を問い合わせる）ことによって、達成されてもよい。代替的には、このエニーキャストアドレスはモバイルノード２００に知られてもよく、若しくは、モバイルノード２００が接続されているアクセスネットワーク内で通告されたネットワークプレフィクスから導き出されてもよい。

エニーキャストアドレスを取得した（ステップ６０３）直後に、モバイルノード２００は当該エニーキャストアドレスに宛てられたＤＨＡＡＤ要求を送信する（ステップ６０４）。ＤＨＡＡＤ要求は、本明細書中において前に説明したモバイルノード２００の位置情報を含むことによって拡張され、例えば、ＮＡＩ又は疑似ＮＡＩといったモバイルノード２００の識別子をさらに任意で含んでもよい。

図２の例示的なシナリオを考慮すると、モバイルノードは、アクセスルータＡＲ２０７がアクセスネットワークをサーブしているとともにクライアントＭＩＰｖ６がモビリティ管理のために用いられるネットワークエリアへと移動したかもしれない。したがって、ルーティングプロトコルは、ＤＨＡＡＤ要求を最も近いホームエージェントへとルーティングしてもよく、この例では、当該ホームエージェントがホームエージェント２０８であると想定される。ホームエージェント２０８は、自身が問い合わせを行っているモバイルノードをサーブ中でないことを（例えば、モバイルノード２００のためのバインディングキャッシュエントリーを見出すことができないことにより）決定し、それゆえ、ＤＨＡＡＤ要求中の位置情報及びホームエージェント２０８に対して利用可能な任意の別の情報に基づいて、モバイルノード２００をサーブしているホームエージェントへの手がかりを少なくとも決定する（ステップ６０５）ように試行する。エニーキャストグループ内の各ホームエージェントが互いのバインディングを知っているか、又は、ホームエージェント２０８が位置情報から、モビリティ管理方式を変更する前にいずれのホームエージェントがモバイルノード２００をサーブしたかを結論付けうると想定すると、ホームエージェント２０８は、自身がモバイルノード２００をサーブしていないことを示すとともに正しいホームエージェンへの（例えば、リダイレクト情報オプション中のホームエージェント２０４のユニキャスト、マルチキャスト又はエニーキャストアドレス又は自身のＤＮＳ名を示す）手がかりを含むＤＨＡＡＤ応答を送信することによって、ＤＨＡＡＤ要求へと応答する（ステップ６０６）。

応答を受信した直後に、モバイルノード２００は、ＤＨＡＡＤ応答中にサービングホームエージェントとして指示されたホームエージェント２０４がまさにモバイルノード２００が登録されていたホームエージェントであることを、ホームエージェント２０８からのＤＨＡＡＤ応答中に指示されたアドレスへと、別のＤＨＡＡＤ要求を自身の位置情報及び自身の識別子とともに送信する（ステップ６０７）ことによって、任意に確認してもよい。したがって、ホームエージェント２０４はＤＨＡＡＤ要求を受信するとともに、当該ＤＨＡＡＤ要求に対して、自身がまさに当該モバイルノード２００をサーブするホームエージェントであることを示して応答する（ステップ６０８）であろう。

モバイルノード２００は、例えばＩＥＴＦ ＲＦＣ ３７７５に規定されたバインディングアップデート手順（例えば、ＩＫＥｖ２シグナリング手順を用いるホームエージェント２０４とのＩＰｓｅｃセキュリティアソシエーションの確立を含む）を用いて、自身の気付アドレスをホームエージェント２０４に登録する（ステップ６０９）ことをさらに進めてもよい。ホームエージェント２０４でバインディングを更新した直後に、モバイルノード２００はセッションを継続してもよい（ステップ６１０）。

ＤＨＡＡＤ手順に関して上述のこの例示的な実施形態では、ＤＨＡＡＤ要求はホームエージェント発見メッセージとみなされ、ＤＨＡＡＤ応答はそれに対する応答とみなされる。したがって、この例示的な実施形態での術語「ホームエージェント発見サーバー」は、第１のＤＨＡＡＤ要求を受信するホームエージェントのことをいう。

本発明の別の実施形態では、本発明の原理及び思想は、本明細書中に以前に記載されたＩＥＴＦ ＲＦＣ４２８５から知られる認証プロトコルの認証オプションを用いたバインディングアップデート手順に適用される。この例は、本発明のこの例示的な実施形態による認証オプションを用いて拡張されたバインディングアップデート手順を示す図７を参照して、概略を説明する。

ここで再び、モバイルノード２００には進行中のセッションがあり（ステップ７０１）、モバイルノード２００はプロキシＭＩＰｖ６から（クライアント）ＭＩＰｖ６へと自身のモビリティ管理プロトコルを変更する（ステップ７０２）と想定する。新しい気付アドレス（ＣｏＡ）を構成した直後に、モバイルノード２００は、認証オプションを含むバインディングアップデート（ＢＵ）メッセージをコアネットワーク内のホームエージェントのエニーキャストアドレスへと送信する（ステップ７０３）。このバインディングアップデートは、本明細書中において前に説明したように、モバイルノード２００の位置情報及び任意でモバイルノード２００の識別子を含む追加オプションによって拡張される。バインディングアップデートは、コアネットワーク領域番号２内のホームエージェント２０８へとルーティングされる（図２を参照のこと）。ホームエージェント２０８は、モバイルノード２００が当該ホームエージェントに登録されていないことを認識し、本明細書中において先に説明したようにバインディングアップデート中の位置情報を用いて、当該モバイルノード２００をサーブするホームエージェントを識別することを試行する（ステップ７０４）。ホームエージェント２０８は、バインディングが更新されなかったことを示すバインディング受信確認メッセージをモバイルノード２００へと送信する（ステップ７０５）ことによって、バインディングアップデートに応答する。さらに、ホームエージェント２０８は、ホームエージェント２０４のＩＰアドレス若しくはそのＤＮＳ名、又は、モバイルノードがそれらを導き出すための情報を示すリダイレクト情報をバインディング受信確認へと含めており、当該ホームエージェント２０４は、モバイルノード２００をサーブするホームエージェントとしてホームエージェント２０８によって識別された。

モバイルノード２００は、ホームエージェント２０４のアドレスを備えたリダイレクト情報を含むバインディング受信確認を受信し、引き続いて、ホームエージェント２０８から受信されたバインディング受信確認中に示されたアドレスへと、新しいバインディングアップデートを送信する（ステップ７０６）。

モバイルノード２００が、バインディング受信確認中のホームエージェントのユニキャストアドレスを受信したか、若しくは、当該バインディング受信確認中に含まれたリダイレクト情報に基づいて自身のサービングホームエージェントのユニキャストアドレスを既に取得できている場合には、この新しいバインディングアップデートは、当該認証プロトコルによる認証オプションを含む最先端のバインディングアップデートであってもよい。この動作は、例えば、モバイルノード２００が、ホームエージェントアドレスが当該モバイルノード２００をサーブする正しいホームエージェントを識別していると確信している場合に用いられてもよい。モバイルノードが、新しいバインディングアップデートが自身のサービングホームエージェントへとルーティングされることを確信していない（例：グループアドレスがバインディング受信確認中に戻される）場合は、モバイルノード２００は、ステップ７０３のように、モバイルノード２００の位置情報及び任意で識別子を含むバインディングアップデートを送信してもよい。

ホームエージェント２０４が、モバイルノード２００が登録されているホームエージェントであると想定すると、当該ホームエージェント２０４は、ＩＥＴＦ ＲＦＣ４２８５に規定されたバインディングアップデートを処理し、モバイルノード２００のバインディングアップデートをＡＡＡサーバーで認証する（ステップ７０７、７０８）であろう。この認証が成功すると、ホームエージェント２０４は自身のバインディングキャッシュ中にモバイルノード２００の新しい気付アドレスを登録するとともに、バインディング受信確認（ＢＡｃｋ）をモバイルノード２００へと送信する（ステップ７０９）ことによって、バインディングの更新を確認する。したがってモバイルノード２００は、モビリティ管理方式を変更する前に開始されたセッションのセッションデータ７１０を交換することを継続してもよい。

本発明の他の実施形態による他の可能性は、ＤＣＨＰプロトコル手順を拡張することである。図８は、本発明の例示的な実施形態による、モバイルノード２００をサーブするホームエージェントを発見するための例示的なＤＨＣＰシグナリングを示す。これまでに記載された前の実施形態と同様に、モバイルノード２００には進行中のセッションがあり（ステップ８０１）、自身のモビリティ管理プロトコルをプロキシＭＩＰｖ６から（クライアント）ＭＩＰｖ６へと変更する（ステップ８０２）ことが、例示目的のために想定される。モバイルノード２００は、モビリティ管理方式を変更した直後に新しい気付アドレス（ＣｏＡ）を構成する。モバイルノード２００は、当該モバイルノードをサーブするホームエージェントに問い合わせるべく、（典型的にはモバイルノード内に前もって構成されている）自身の事業者のホームネットワークの識別子を含むＤＨＣＰ情報要求メッセージを送信する（ステップ８０３）。ＤＨＣＰ情報要求メッセージ中の従来の各パラメータ（ともにｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｄｒｏｍｓらの「ＩＰｖ６のための動的ホスト構成プロトコル（ＤＨＣＰｖ６）」、ＩＥＴＦ ＲＦＣ３３１５、２００３年７月、及びＨｅｅ Ｊｉｎ Ｊａｎｇらの「ＭＩＰｖ６におけるホーム情報発見のためのＤＨＣＰオプション」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｈｉｏｐｔ−１０．ｔｘｔ、２００８年１月を参照のこと）に加えて、モバイルノード２００は、受信側ＤＨＣＰサーバー（ＮＡＳ中継）が位置情報に基づいて自身のサービングホームエージェントを潜在的に識別することを可能にするために、自身の位置情報及び任意に自身の識別子のうち一つをメッセージに含める。ＤＨＣＰ情報要求メッセージは、ＤＨＣＰマルチキャストアドレス（ＤＨＣＰ＿ＭＵＬＴＩＣＡＳＴ）に宛てられてもよい。要求を受信するＤＨＣＰサーバーは、位置情報及びモバイルノード識別子に基づいて、モバイルノード２００をサーブするホームエージェントの識別を試行する（ステップ８０４）。モバイルノード２００が登録されているホームエージェントをＤＨＣＰサーバーが識別できると想定すると、当該ＤＨＣＰサーバーは、ホームエージェントアドレスを含んでいるホームエージェント情報オプションを応答メッセージ（ＤＨＣＰ情報応答）へと含めて、当該応答メッセージをモバイルノード２００へと送信する（ステップ８０５）。

モバイルノード２００は、応答を受信した直後に、ＩＥＴＦ ＲＦＣ ３７７５に規定されたバインディングアップデート手順（例えば、ＩＫＥｖ２シグナリング手順を例えば用いて、ホームエージェント２０４とのＩＰｓｅｃセキュリティアソシエーションの確立を含む）を用いて、ＤＨＣＰ応答中にアドレスが示されているホームエージェント２０４に、自身の気付アドレスを登録する（ステップ８０６）ことをさらに進めてもよい。ホームエージェント２０４でバインディングを更新した直後に、モバイルノード２００はセッションを継続してもよい（ステップ８０７）。

この例示的な実施形態において、ＤＨＣＰサーバー（ＮＡＳ中継）はホームエージェント発見サーバーとみなさしてもよく、術語「ホームエージェント発見メッセージ」及び「応答」は拡張されたＤＣＨＰ情報要求及び応答メッセージと等価であるとみなすことができる。

本明細書中において考慮されるシナリオにおいて発生しうる一問題は、モバイルノードのプロキシモバイルＩＰドメイン内での移動中に、ネットワークがホームエージェントを移転させた可能性があることである。本発明の他の実施形態によると、モバイルノードは当該モバイルノードが移動する際に接続した中間（アクセス）ネットワークについての追加的な情報を保存してもよい。モバイルノードは、モビリティ管理方式を変更した直後にこれら追加的な情報をネットワークへと提供する際には、当該追加的な情報を位置情報に含めてもよい。例えば、モバイルノードは、ホームエージェントの移転が起こったと推量するかもしれず、それゆえ、当該モバイルノードが（例えば、地理的位置情報、訪問アクセスルータ、セル等の数から測定した）所定の距離を移動した時、又は、アクセスネットワーク又は管理ドメインにわたって移動した時には、現在の中間ネットワークについての情報を保存するかもしれない。

エニーキャストホームエージェント発見メッセージを受信する「誤った」ホームエージェント発見サーバーは、例えば、モバイルノードによって示された位置をホームエージェントアドレスにマッピングするためのデータベースを保持してもよい。次いで、ホームエージェント発見サーバーは、要求を拒絶して、正しいホームエージェント又は上記に論じられた正しいホームエージェントが位置していそうな領域のために、新しいエニーキャスト又はユニキャストアドレス又は他の識別子等リダイレクトの手がかりを含んでもよい。モバイルノードは、新しいホームエージェント発見メッセージを、受信した手がかりから導き出された指示されたアドレスへと送信してもよい。

例示的な一実装では、配置の概念は、様々な領域、サービス又はアクセス技術に対して複数のホームエージェントエニーキャストグループを定義してもよい。異なるグループは異なる範囲を持ってもよく、及び、この「誤った」ホームエージェント又はホームエージェント発見サーバーは、モバイルノードに対して、より小範囲かより特定範囲を持つ別のエニーキャストグループについての手がかりを与えるであろう。モバイルノードは例えば最初に、上海（図２のコアネットワーク領域番号１）にあるプロキシモバイルＩＰネットワークに接続するとともに、ホームエージェント２０４を割り当てうるであろう。モバイルノードは、北京（図２のコアネットワーク領域番号２）へと移動した後に、ホームエージェント発見を開始し、最大範囲のエニーキャストアドレス（例えば、グローバルに有効なエニーキャストアドレス）への初期接続のポイントについての情報を含むＩＫＥメッセージを送信する。ホームエージェント２０８はこのメッセージを受信するとともに、モバイルノードがより特定のエニーキャストグループ、例えば、上海のホームエージェントのエニーキャストグループのエニーキャストアドレス（すなわち、図２のコアネットワーク領域番号１のホームエージェント）を試行するべきである旨の、モバイルノードのローカル情報から導き出された手がかりとともに応答する。モバイルノードは最後に、ＩＫＥメッセージを上海のホームエージェントのエニーキャストアドレスへと送信するとともに、このグループ内で正しいホームエージェント（ホームエージェント２０４）を発見する。

本発明の別の実施形態では、モバイルノードは誤ったホームエージェントに対してその手がかりについてのフィードバックを提供する。例えば、モバイルノードが、当該モバイルノードをサーブしていないホームエージェントに対して、前の手がかりが正しいホームエージェント発見するのに有用であったと伝えると、当該モバイルノードをサーブしていないホームエージェントは、例えば、自身のデータベース中にこの情報（すなわち、正しいホームエージェントアドレスのマッピング、及び、報告されたモバイルノードのかつての接続位置）を保存するとともに、このホームエージェントによる他のモバイルノードに対する将来の手がかりがより精密となるよう手がかりを提供する自身のプロセスを改善してもよい。

システム設計において考慮を必要としうる別の問題はセキュリティであるかもしれない。本発明のいくつかの実施形態では、ホームエージェント発見メッセージはモバイルノード識別子を含み、その結果、メッセージの受信者は、モバイルノードのバインディングキャッシュエントリー、及び、このモバイルノードが登録されているホームエージェントを識別することができる。しかしながら、経路外攻撃者が別のモバイルノードの識別子を含むホームエージェント発見メッセージを送信するだけでは、モバイルノードが現在登録されているホームエージェントを発見できないことが望ましいかもしれない。その理由は、そうでなければ、攻撃者はある特定のモバイルノードのホームエージェントに対して的を絞った攻撃を開始しうるからである。

本発明の例示的な一実施形態では、モバイルノードはホームエージェント発見中に一時的識別子又は疑似識別子を用いており、当該識別子の実際のモバイルノードのアイデンティティへのマッピングは、モバイルノード及びネットワークにのみ知られている（攻撃者には知られていない）。この疑似識別子は、（クライアント）モバイルＩＰへの移行前に、例えば、初期接続中又は過去の認証中に、ネットワークとモバイルノードの間でネゴシエートすることができる。各ＩＰネットワークにおいて、疑似ＮＡＩはプライバシー保護のための一般的な一時的識別子であり、この識別子は典型的にはネットワーク認証中にネットワークとモバイルノードの間でネゴシエートされる。したがって、モバイルノードは例えば、ホームエージェント発見メッセージへの包含のためにこの識別子を用いてもよい。代替的な一時的識別子又は疑似識別子は、当該モバイルノードのＴＭＳＩであってもよく、当該ＴＭＳＩは、ＧＳＭ（登録商標）／ＵＭＴＳ／ＬＴＥ通信ネットワーク内で用いられるネゴシエートされた一時的な疑似識別子でもある。

例示的な一実施形態によると、ネットワークとモバイルノードの両方が、３ＧＰＰアクセス内のネットワークとモバイルノードの間でネゴシエートされた疑似ＮＡＩを、ＴＭＳＩから生成しうる。例えば疑似ＮＡＩは、ユーザ名部のＴＭＳＩ及びドメイン部からのドメイン（例えば、「ＴＭＳＩ＠ｅｘａｍｐｌｅ．ｃｏｍ」）から構築されうる。モバイルノードが３ＧＰＰネットワークから非３ＧＰＰネットワークへと移動中である場合は、当該モバイルノードは、疑似ＮＡＩネゴシエーションから起因する追加的なシグナリング又は遅延を伴うことなく、疑似ＮＡＩを用いてもよい。モバイルノードのＴＭＳＩは典型的には３ＧＰＰネットワークの移動管理エンティティ（ＭＭＥ）に保存されているので、当該移動管理エンティティは、ハンドオーバーの前に、モバイルノードに割り当てられたＴＭＳＩをホームエージェントへと転送してもよい。この転送は、例えば、移動管理エンティティとホームエージェントとの間でＡＡＡ／ＨＳＳサーバーを介して、例えば、ネットワーク認証中に、直接的に実現されてもよい。

本発明の他の実施形態によると、あらゆるモバイルノードのホームエージェントを発見する脅威に対する別の方策は、ホームエージェントにエニーキャストアドレスを動的に構成することである。例えば、あらゆるモバイルノードが固有のホームエージェント発見エニーキャストアドレスを割り当てられ、かつ、モバイルノードがプロキシＭＩＰから（クライアント）ＭＩＰへと移動する時間の間にのみこのアドレスがホームエージェント上に構成される場合には、攻撃者がモバイルノードのホームエージェントを識別することは一般には可能でない。これは、モバイルノードがプロキシＭＩＰから（クライアント）ＭＩＰへの移行を行う時間にのみ可能であり、経路外攻撃者によって見出すことは一般に困難である。

上記に記載した本発明の実施形態のいくつかにおいて、ホームエージェント発見メッセージを受信したが、モバイルノードをサーブしていないホームエージェントは、典型的には、リダイレクト情報を含むホームエージェント発見応答によって応答し、そして、モバイルノードはそれに応答して別のホームエージェント発見メッセージを送信する。別の実施形態では、「誤った」ホームエージェントからのホームエージェント発見要求メッセージを拒絶して、正しいホームエージェントのアドレス若しくは領域を含むモバイルノードへと手がかりを送信する代わりに、モバイルノードをサーブしていないホームエージェントは、当該ホームエージェント発見メッセージを正しいホームエージェントアドレス又は領域へと転送してもよく、次いで、当該転送されたメッセージを受信するホームエージェントは、ホームエージェントがモバイルノードをサーブしている場合にはモバイルノードに応答してもよく、又は、再び当該ホームエージェント発見メッセージを転送してもよい。

本実施形態の一変形例では、ホームエージェント発見メッセージをモバイルノードへの応答を伴わずにホームエージェント間で転送させないために、ホームエージェント発見メッセージはメッセージが転送された回数を数えるカウンタオプションを含んでもよい。カウンタが閾値を超える（又はカウンタを１ずつ減らしてゼロに到達する）と、ホームエージェント発見メッセージを受信したホームエージェントは、当該ホームエージェントがモバイルノードをサーブしていない場合には、リダイレクトオプションを含むホームエージェント発見応答メッセージを送信することによって、当該モバイルノードに応答する。モバイルノードは次いで、ホームエージェント発見に割り込むか、又は、応答メッセージ中のリダイレクトの手がかりに基づいて（位置情報を含む）別のホームエージェント発見メッセージを再送信するかのいずれかを行ってもよい。

さらに、図２〜８に関して論じられた前の実施形態の大部分が、プロキシＭＩＰからクライアントＭＩＰへのモビリティ管理変更を想定していたものの、（クライアント）ＭＩＰからプロキシＭＩＰへのハンドオーバーにも本発明を同様に用いることもまた可能なことに留意するべきである。この場合には、（モバイルノードのプロキシの機能を果たす）モバイルアクセスゲートウェイは、当該モバイルノードが前に登録されたことのるホームエージェントを見出す必要があるかもしれず、及び、ホームエージェント発見を実行するかもしれない。例えば、モバイルアクセスゲートウェイは、モバイルノードからの過去のモバイルノードの位置についての情報を問い合わせるか、又は、当該情報が提供されてもよく、そして、本明細書中に前に記載されたように、ホームエージェントを発見するために、ローカル情報を含むホームエージェント発見メッセージをネットワークへと送信してもよい。

さらに、各ホームエージェントを割り当てられうるエニーキャストグループは、事業者によって、例えば、ネットワークの大きさ、ＰＤＮ−ＧＷの数又は当該ネットワークに登録されたモバイルノードの数に適合させるべく、変更できることも留意される。

本発明の別の態様は、複数のアンカ（例：ｅＰＤＧ及びＰＤＮ−ＧＷ）が一つのデータセッションに用いられるシナリオにおけるデータパスの最適化である。本発明の別の態様によると、上記で論じたホームエージェント発見について同様のアプローチが用いられる。この思想はアンカのうち一つを別のアンカにより近い位置へと移転させることである。

例えば、３ＧＰＰ ＳＡＥでは、信頼されていない非３ＧＰＰネットワーク内に位置しているＵＥ（モバイルノード）は典型的には、モビリティ管理のためにＰＤＮ−ＧＷ（ホームエージェント／ローカルモビリティアンカ）に固定されており、さらに、３ＧＰＰネットワークにアクセスするためにｅＰＤＧへの安全なトンネルを保持している。さらに、ＵＥ（モバイルノード）が信頼されていないネットワーク内に位置している場合には、（モバイルノードの）ＵＥＥから／へのセッションデータのデータパスは、安全なトンネルを通ってコアネットワーク内のｅＰＤＧへと、及び、このｅＰＤＧから（別の安全なトンネルを通って）ＵＥ（モバイルノード）をサーブするＰＤＮ−ＧＷ（ホームエージェント／ローカルモビリティアンカ）へとルーティングされるべきであることに留意するべきである。ＰＤＮ−ＧＷはセッションデータのためのインターネットへの接続を確立する。

シナリオ例を図９に示す。ＵＥ（モバイルノード９００）は最初に、コアネットワークに接続された信頼された非３ＧＰＰ又は３ＧＰＰアクセスネットワーク（領域番号１）に接続され、ＰＤＮ−ＧＷ９０４（ホームエージェント）が割り当てられる。コアネットワーク領域番号１とコアネットワーク領域番号２はともに、一つのコアネットワークの一部である。ＵＥ（モバイルノード９００）が、同じくコアネットワークに接続されている（アクセスルータ９０７によってサーブされる）信頼されていない非３ＧＰＰネットワークへと移動する（ステップ９０８）と想定されうる。ＵＥが信頼されていない非３ＧＰＰネットワークに進入したので、ＵＥ（モバイルノード９００）は典型的には、ｅＰＤＧ（ここではｅＰＤＧ９０６）へのＩＰｓｅｃトンネルを発見してセットアップする（ステップ９０９）ことを開始する。ＵＥ（モバイルノード９００）は、初期接続位置についての位置情報及び識別子を、安全なトンネルをセットアップするためにｅＰＤＧ９０６へと送信された初期メッセージのうち一つに含める。例えば、図４に関して上記で論じた例と同様に、ＵＥ（モバイルノード９００）はＩＫＥｖ２シグナリング手順を用いてもよく、及び、自身の位置情報及び自身の識別子を含めることによって、ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージを拡張してもよい。ｅＰＤＧ９０６は、位置情報に基づいて現在のモバイルノードのＰＤＮ−ＧＷ（ＰＤＮ−ＧＷ９０４）を識別してもよく、そして、ＵＥ（モバイルノード９００）が別のｅＰＤＧ（この例ではｅＰＤＧ９０５）を用いればデータパスははるかに短くなるであろうことに気が付く。それゆえに、ｅＰＤＧ９０６は、ＩＫＥ要求を拒絶してもよく（ステップ９１０）、ＵＥ（モバイルノード９００）をｅＰＤＧ９０５へと移転させるか又はリダイレクトするべく、ＵＥ（モバイルノード９００）へと手がかりを送信する。次いで、ＵＥ（モバイルノード９００）はｅＰＤＧ９０５との安全なトンネルを確立するとともに、より短いデータパスを確立し、このことはより短いデータパケット遅延を示唆する。

上記の手順の一つの最適化として他の実施形態によれば、最初に発見されたｅＰＤＧ（ｅＰＤＧ９０６）はＩＫＥ要求を受け取ってもよく、その結果、ＵＥ（モバイルノード９００）は、より最適なｅＰＤＧ９０５への安全なトンネルが確立され、そして、ＵＥ（モバイルノード９００）が新しいｅＰＤＧ９０５へと完全に移転するまで、このｅＰＤＧを用いることができる。したがって、トンネル確立要求９０９への応答９１０は、トンネルの確立をさらに進めるよう指示してもよく、追加的にはｅＰＤＧ９０５へのリダイレクトの手がかりを含んでいる。２個のｅＰＤＧへのこの一時的な接続によって、最適化されたデータパスを保証しつつ、ハンドオーバー遅延を最小化しうる。

データパス最適化は、ハンドオーバーの前後に用いられたモビリティ管理の種類とは独立しており、モビリティ管理方式を変更することを伴う必要はない。しかしながら、（クライアント）ＭＩＰが移動（ハンドオーバー）の前に用いられた場合は、ＵＥは自身の現在のＰＤＮ−ＧＷアドレス（すなわちＰＤＮ−ＧＷ９０４のアドレス）をすでに知っていており、ＩＫＥ＿ＳＡ＿ＩＮＩＴメッセージ中にＰＤＮ−ＧＷのアドレスを含んでもよい。

代替的には、別の例示的な実施形態では、ＵＥはまた、既知のＰＤＮ−ＧＷのＤＮＳ名に基づいてＤＮＳ名を構築することによってｅＰＤＧ９０５を発見してもよい。例えば、既知のＰＤＮ−ＧＷ名は「ＰＤＮ−ＧＷ１．ｏｐｅｒａｔｏｒ．ｄｅ」であれば、ｅＰＤＧアドレスを発見するためのＤＮＳ名は「ｅＰＤＧ．ＰＤＮ−ＧＷ１．ｏｐｅｒａｔｏｒ．ｄｅ」となりうる。

共通のアンカが上記に概略説明された原理を用いて発見及び使用されうる別のシナリオは、モバイルノードがネットワーク（例えば、ＷＬＡＮ ＨＴＴＰセッション及びＬＴＥ ＶｏＩＰセッション）への複数の独立した取り付け、接続又はセッションをもつ状況である。かかるシナリオでは、効率性の理由からこれらセッションすべてに対して同一のアンカを用いることが望ましいかもしれない。モバイルノードが追加的な接続のためにホームエージェントを発見する場合には、モバイルノードは、当該モバイルノードが他の接続のために用いているホームエージェントを発見するために、当該モバイルノードの位置情報及び識別子を含んでもよい。

別のシナリオでは、本発明の別の例示的な実施形態によると、ＵＥ（モバイルノード）はクライアントベースのモビリティ管理を用いて新しい非３ＧＰＰアクセスネットワークへとハンドオーバーしているが、このアクセスネットワークが信頼された非３ＧＰＰネットワークであるのか、又は、信頼されていない非３ＧＰＰネットワークであるのかを知らない。それゆえに、ＵＥは、自身がこのｅＰＤＧへのＩＰｓｅｃトンネルをセットアップして、次いでｅＰＤＧトンネルを介してＰＤＮ−ＧＷに登録するためにｅＰＤＧを発見するべきか否か、又は、ＵＥがｅＰＤＧへの安全なトンネルの必要性なしに直接的にＰＤＮ−ＧＷに登録できるか否かを知らない。

この実施形態において、ＵＥは、自身が信頼されていないアクセスネットワーク内に位置しており、トンネルセットアップメッセージを送信することによってｅＰＤＧとの安全なトンネル（例：ＩＰｓｅｃトンネル）を開始すると想定してもよい。このトンネルセットアップメッセージは例えば、ｅＰＤＧへと送信されたＩＫＥｖ２シグナリング手順のＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージであってもよい。再び、このトンネルセットアップメッセージは、本明細書中に前に記載されたように位置情報を組み入れることによって拡張される。トンネルセットアップメッセージは、ハンドオーバーの直後にＵＥ（モバイルノード）によってソースアドレスとして構成された新しい気付アドレスを用いてもよい。ｅＰＤＧは、（例えば、ＩＫＥ＿ＳＡ＿ＩＮＩＴ要求メッセージのソースアドレスに基づいて又は当該メッセージ中の位置情報に基づいて）、ＵＥ（モバイルノード）が信頼された非３ＧＰＰアクセスネットワーク又は信頼されていない非３ＧＰＰアクセスネットワークに位置しているかについて気が付いてもよい。この情報に基づいて、ＵＥはトンネル確立を受け取ってトンネル確立を進めるか、又は、本発明の様々な実施形態で記載されたように、手がかりを含む応答メッセージ（例：ＩＫＥ＿ＳＡ＿ＩＮＩＴ応答メッセージ）をＵＥのＰＤＮ−ＧＷアドレスへと送信することによって、トンネルセットアップ要求を拒絶して、ＵＥ（モバイルノード）が当該ＵＥ（モバイルノード）をサーブするＰＤＮ−ＧＷへとリダイレクトすることができる。リダイレクト情報は、リダイレクトあて先がＰＤＮ−ＧＷ又はホームエージェントであってｅＰＤＧでない旨の情報を追加的に含んでもよく、その結果、モバイルノードはリダイレクトあて先に接続する時に挙動することが可能である。

本発明の他の実施形態は、ハードウェア及びソフトウェアを用いる上述の様々な実施形態の実装に関する。本発明の様々な実施形態は、演算装置（処理装置）を用いて実装又は実行されたことが認識されている。演算装置又は処理装置は例えば、汎用目的の処理装置、デジタル信号処理装置（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は他のプログラム可能な論理デバイス等であってもよい。

本発明の様々な実施形態はまた、これらデバイスの組み合わせによって実行又は具現化されてもよい。

さらに、本発明の様々な実施形態はまた、処理装置又は直接的にハードウェア内で実行されるソフトウェアモジュールによって実装されてもよい。ソフトウェアモジュール及びハードウェア実装の組み合わせもまた可能であろう。ソフトウェアモジュールは、任意の種類のコンピュータで読み取り可能な記憶媒体、例えば、ＲＡＭ、ＥＰＲＯＭ、ＦＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ等に保存されてもよい。

前の段落では、本発明の様々な実施形態及び変形例が記載されてきた。具体的な実施形態において示されたように、非常に多数の変形例及び／又は修正が、広く記載された本発明の精神又は範囲から逸脱することなく、本発明に対してなされうることが、当業者によって理解されるであろう。

さらに、実施形態の大部分が、３ＧＰＰベースの通信システムに関して概略説明されるとともに、前のセクションで用いられた術語は主として３ＧＰＰ術語及びＩＥＴＦ術語に関することに留意するべきである。しかしながら、ＩＥＴＦベース及び３ＧＰＰベースのアーキテクチャに関する様々な実施形態の術語及び記載は、本発明の原理及び思想をかかるシステムに限定することを意図していない。

また、上記の技術分野のセクションで与えられた説明は、本明細書中に記載された大部分はＩＥＴＦに特有の例示的な実施形態をよりよく理解するよう意図されており、本発明は、移動体通信ネットワークにおけるプロセス及び機能の記載された特有の実装に限定するものとして理解されるべきでない。それにもかかわらず、本明細書中で提案された諸改良は、技術分野のセクションに記載されたアーキテクチャ内に容易に適用されうる。さらに、本発明の概念は３ＧＰＰによって現在論じられたＬＴＥ ＲＡＮ内にも容易に用いられうる。

Claims (7)

1. ネットワークベースのモビリティ管理方式を提供するアクセスシステムにモバイルノードが当初接続したときに選択されたホームエージェントに、モバイルノードをリダイレクトさせるホームエージェントであって、
   前記モバイルノードがクライアントベースのモビリティ管理方式を提供するアクセスシステムへの接続を行う際、前記ホームエージェントとセキュリティアソシエーションを確立するためのＩＫＥｖ２要求メッセージであって、前記モバイルノードの識別子を含むＩＫＥｖ２要求メッセージを前記モバイルノードから受信する受信部と、
   ネットワークベースのモビリティ管理方式を提供する前記アクセスシステムに前記モバイルノードが当初接続したときに選択された前記ホームエージェントのＩＰアドレスを含んでいるリダイレクト情報を含むＩＫＥｖ２応答メッセージを前記モバイルノードに送信する送信部と、
   を備えるホームエージェント。
2. クライアントベースのモビリティ管理方式を提供する前記アクセスシステムにおいて、前記モバイルノードによって発見された前記ホームエージェントは、ネットワークベースのモビリティ管理方式を提供する前記アクセスシステムに前記モバイルノードが当初接続したときに選択された前記ホームエージェントとは異なる請求項１に記載のホームエージェント。
3. 前記ＩＫＥｖ２要求メッセージのあて先アドレスとして、エニーキャストアドレス又はマルチキャストアドレス又はユニキャストアドレスが用いられる請求項１に記載のホームエージェント。
4. 前記ＩＫＥｖ２応答メッセージ中に含める前記リダイレクト情報を、前記モバイルノードによってＩＫＥｖ２要求メッセージ中に提供された前記モバイルノードの識別子に基づいて決定する請求項１から３のいずれか１つに記載のホームエージェント。
5. クライアントベースのモビリティ管理方式が用いられるドメイン内に位置している請求項１に記載のホームエージェント。
6. 前記モバイルノードの識別子は、ネットワークアクセス識別子（ＮＡＩ）である請求項１に記載のホームエージェント。
7. 前記モバイルノードの識別子は、前記モバイルノードに割り当てられたネットワークアクセスプレフィックスである請求項１に記載のホームエージェント。