JP2012501129A - ネットワークによって用いられるモビリティマネジメント機能の検出 - Google Patents

Abstract

本発明は、モバイルノードが接続されているネットワークが、モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いているか否かを検出できる方法及びモバイルノードに関する。モバイルノードが、モバイルノードに対するネットワークベースのモビリティ機能をネットワークが用いているか否かを、ＰＤＮ接続又はＩＰセッションの確立の後すぐに検出できるようにするために、モバイルノードは、自己に宛てられたネットワークにプローブメッセージを送信し、モバイルノードに返信されたプローブメッセージの修正に基づいて、ネットワークが、モバイルノードに対するネットワークベースのモビリティ機能を用いているか否かを判定する。

Description

本発明は、モバイルノードが接続されているネットワークが、モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いているか否かを検出できる方法及びモバイルノードに関する。さらに、本発明は、この検出プロセスに用いられたプローブメッセージのフォーマットの定義及び検出プロセスに参加する各ノードの適合に関する。

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

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

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

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

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

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

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

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

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

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

クライアントベース対ネットワークベースのモビリティマネジメント
モバイルＩＰは、モビリティマネジメントシグナリングがホスト／クライアントとホームエージェントの間にあることから、ホストベースのプロトコル又はクライアントベースのプロトコルである。それゆえに、ＭＩＰは時にはクライアントモバイルＩＰ、クライアントＭＩＰもしくはＣＭＩＰとも呼ばれる。ユーザ装置がＩＰｖ６ネットワークと同様であるＩＰｖ４にも接続するのを可能にするために、デュアルスタックＭＩＰｖ６又はＤＳＭＩＰと呼ばれるＣＭＩＰ拡張が、モバイルノード又はユーザ装置によって実装できる（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇより入手可能であり、参照によって本明細書に包含される、Ｓｏｌｉｍａｎの「デュアルスタックホスト及びルータ用のモバイルＩＰｖ６サポート」、ＩＥＴＦインターネットドラフト、ｄｒａｆｔ−ｉｅｔｆ−ｍｅｘｔ−ｎｅｍｏ−ｖ４ｔｒａｖｅｒｓａｌ−０５.ｔｘｔ、２００８年７月を参照のこと）。ＤＳＭＩＰという用語は、本文書中において時にはＣＭＩＰ又はＭＩＰｖ６と同じ意味で用いられる。

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

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

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

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

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

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

ネットワークはＰＭＩＰをサポートしても、サポートしなくてもよく（すなわち、モバイルノードのアクセスルータはＭＡＧ機能をサポートしても、サポートしなくてもよい）、ネットワークがＰＭＩＰをサポートする場合は、ＰＭＩＰサービスをモバイルノードに提供しても、提供しなくてもよい。ＰＭＩＰは元来、モバイルノードに対して透過的（トランスペアレント）に作動するよう設計されるが、いくつかのシナリオでは、モバイルノードが、自己がネットワークからＰＭＩＰサービスを受信することをわかっている場合、それが有用となりうる。

１つの例は、ＩＰモビリティモード選択（ＩＰＭＳ）である（３ＧＰＰ ＴＳ２３.４０２を参照のこと）。モバイルノードとネットワークの両方が、複数のモビリティマネジメントメカニズム（ＭＩＰｖ６、ＰＭＩＰｖ６）をサポートしてもよい。モバイルノードは、モバイルノードがＭＩＰｖ６登録手順をトリガするか否かを決定するために、ある特定のＰＤＮ接続又はＩＰセッションに対して、ネットワークによっていずれのモビリティマネジメントメカニズムが選択されたかを知っている必要がある。例えば、ネットワークがＰＭＩＰサービスを用いておらず、かつ、モバイルノードが、それを知らず、アプリケーションに対してＭＩＰホームアドレスの代わりに割り当てられたアドレスを用いる場合は、セッションの継続性は保証されない。現在の３ＧＰＰ ＳＡＥシステムでは、ＣＭＩＰ又はＰＭＩＰサービスのいずれかがあるモバイルノードに用いられるが、決して両方が同時には用いられない。

現在は、ネットワークによって選択されたモビリティマネジメントモードを、モバイルノードが学習する方法について２つの可能性がある。第１として、ネットワークが、選択されたモビリティマネジメントプロトコルをモバイルノードに明示的に信号を送ってもよい。しかしながら、配置、事業者の方針、及びアクセス技術に応じて、このことは常に可能ではなく、それゆえ、明示的な指示は随意となる。第２の可能性は、ローカルに割り当てられたプレフィクスと、ＭＩＰｖ６ブートストラップ中に割り当てられたホームプレフィクスを比較することによって、ネットワークがモバイルノードに対してＭＩＰ又はＰＭＩＰを選択したか否かを見出すべく、モバイルノードがＭＩＰｖ６ブートストラップを開始することである。モバイルノードが、自己がホームにあるか否かを実際に検出していることから、この手順は、ホームリンク検出手順と呼ばれる。プレフィクスが異なる場合、すなわち、モバイルノードがホームにない場合にのみ、モバイルノードは、ネットワークがＭＩＰを選択したと想定して、モバイルノードはＭＩＰ手順を実行しなければならない。このことが機能するのは、現在の３ＧＰＰ標準化では、ＰＭＩＰのみがホームリンク上で用いられるからである。それゆえに、プレフィクスが同じである場合は、モバイルノードは、ＰＭＩＰサービスがネットワーク内で用いられると想定するかもしれない。しかしながら、ＰＭＩＰがネットワークによって選択された場合には、ブートストラップメカニズムは多数の不必要なオーバーヘッド及び遅延を導入してしまい、ＭＩＰブートストラップは、複数回の往復シグナリング交換を必要とし、この場合には検出後にＭＩＰは実際には用いられないからである。さらに、ＰＭＩＰは、外部リンク上でも用いることができるか、又は、ＰＭＩＰ及びＣＭＩＰが同時に用いることができるかの高度なシナリオがサポートされている場合は、このメカニズムはもはや機能しない。

本発明の目的は、ネットワークが、モバイルノードに対してネットワークベースのモビリティマネジメント機能を用いるか否か、又は、モバイルノードが、セッションの継続性を保証することを所望する場合にクライアントベースのモビリティマネジメント機能を用いることによって、自己のモビリティを自ら管理する必要があるか否かを、ネットワークに接続するモバイルノードが検出できるようにすることである。他の目的は、モバイルノードの無線インタフェイスリソースを介した必要なシグナリングを低減できように、及び／又は、モビリティマネジメントが移動体端末の移動をサポートすることを可能にするシグナリングに要する時間を低減するように、本方法を設計することである。

目的の少なくとも１つは独立請求項の主題によって解決される。有利な実施形態は従属請求項の対象となる。

本発明の態様の１つは、モバイルノードが、ネットワークによって用いられるモビリティマネジメント機能を検出することを可能にすることである。それによって、この基本的なアプローチは、モバイルノードは、モバイルノードに宛てられたプローブメッセージをネットワークへと送信させることである。送信されたプローブメッセージ及び受信されたプローブメッセージの変更を検出することによって、移動体端末は、ネットワークによって用いられるモビリティマネジメント機能について結論付ける。

１例において、モバイルノードは、モバイルノードからネットワークへ経路設定され、モバイルノードへと戻っている時に、プローブメッセージが横切るホップの数に基づいて、ネットワークによって用いられるモビリティマネジメント機能を検出してもよい。プローブメッセージのホップカウントを監視するために、プローブメッセージはＩＰパケットとして送信されてもよい。受信されたプローブメッセージのＩＰヘッダ中のホップカウントフィールドに基づいて、モバイルノードはネットワークによって用いられるモビリティマネジメント機能を結論付けることができる。

他の例において、モバイルノードは、モバイルノードによってネットワークへと送信されることと、モバイルノードに宛てられたプローブメッセージとに基づいて、ネットワークによって用いられるモビリティマネジメント機能を検出してもよい。モバイルノードは、モバイルノードに対してネットワークベースのモビリティマネジメント機能を用いるネットワークエンティティを介して経路設定された場合には、ネットワークベースのモビリティマネジメント機能の使用の指示がプローブメッセージに追加されたか否かを確認する。例えば、プローブメッセージが含みうるホップカウントの代わりに、ネットワークベースのモビリティマネジメント機能が活用される場合には、プローブメッセージヘッダ中のフラグもしくはフィールド、又はペイロードが、ローカルモビリティアンカ又はモバイルアクセスゲートウェイによって修正される。したがって、プローブメッセージ中のフラグ又はフィールドのステータスは、ネットワークによって用いられるモビリティマネジメント機能を、モバイルノードに対して指示する。

上記の２つの例において論じられた両方のソリューションを組み合わせてもよい。さらに、両方の例では、モバイルノードは、モバイルノードからネットワークを経由して経路設定されて、モバイルノードへと戻っている時に、１つ以上のネットワークノードによるプローブメッセージの修正に基づいて、ネットワークによって用いられるモビリティマネジメント機能を判定することができる。第１の例では、モバイルノードはホップカウントフィールドの増加を確認し、一方、第２の例では、モバイルノードは、ローカルモビリティアンカ又はモバイルアクセスゲートウェイによって、プローブメッセージ中のフラグ又はフィールドが修正されたか否かを確認する。

上記の態様によると、本発明の１つの実施形態は、ネットワークによって用いられるＩＰモビリティマネジメント機能を検出する方法を提供する。モバイルノードは、ＩＰヘッダを含むＩＰパケットの形態でプローブメッセージをネットワークへと送信し、プローブメッセージのＩＰヘッダは、プローブメッセージを移動体端末のＩＰアドレスへと宛てる。ネットワーク内の経路設定はプローブメッセージをモバイルノードに戻し、モバイルノードは、ネットワークからプローブメッセージを受信している。送信されたプローブメッセージを受信されたプローブメッセージと比較することによって、モバイルノードは、ネットワークによって用いられるモビリティマネジメント機能を検出できる。

本発明の１つの例示的な実施形態において、この検出は、ＩＰヘッダのＩＰホップカウントフィールド中に含まれるホップカウントに基づいており、モバイルノードは、ネットワークがネットワークベースのモビリティマネジメント機能を用いるか否か、又は用いない場合は、セッションの継続性を可能にするためにクライアントベースのモビリティマネジメント機能を用いる必要があるか否かを検出する。

本発明の他の実施形態では、検出は、ネットワークベースのモビリティマネジメント機能を用いるネットワークエンティティを介して経路設定された際に、ネットワークベースのモビリティマネジメント機能の使用の指示がプローブメッセージに追加されたことをモバイルノードが観察することに基づいている。例えば、ネットワーク内の中間ノードのうち１つが、プローブメッセージ中のフラグを切り替えることができ、ネットワークベースのモビリティマネジメント機能の使用を指示するためにＩＰヘッダのフィールドを修正することができるであろう。

本発明の別の実施形態では、モバイルノードは、ネットワークベースのモビリティマネジメント機能を用いていないネットワークを検出したことに応答して、（モバイルノードのホームネットワーク内でモバイルノードの役割を果たすホームエージェントとのＩＰｓｅｃセキュリティアソシエーション等を確立し、ホームアドレスを割り当てるために）クライアントベースのブートストラップ、及び（ホームエージェントにおいて、モバイルノードの新しい気付アドレスを登録するためのバインディングアップデートを送信する等によって）アドレス登録手順を開始する。

モバイルノードのプロトコルスタックの実装に応じて、プローブメッセージが、モバイルノードのＩＰアドレスがプローブメッセージの宛先アドレスとして指示されているために、モバイルノードの内部で経路設定され、ネットワークを介して送信されないことが起こりうる。プローブメッセージがネットワークを介して経路設定されたことを保証するために、本発明の１つの実施形態は、プローブメッセージを、モバイルノードが接続されているネットワーク内のアクセスルータにトンネリングすることを提案している。他の実施形態では、プローブメッセージは、モバイルノードが接続されているネットワーク内のアクセスルータのリンク層アドレスに送信されるが、プローブメッセージの宛先アドレスはモバイルノードのＩＰアドレスを指示している。モバイルノードが接続されているネットワーク内のアクセスルータにプローブメッセージをトンネリングする場合には、ＩＰ対ＭＡＣのアドレスマッピング中に、トンネリングされたプローブメッセージのＩＰ宛先アドレス（すなわち、アクセスルータのＩＰアドレス）が、アクセスルータの対応するリンク層アドレスに対してマッピングされることに留意するべきである。

別の実施形態によると、モバイルノードは、モバイルノードに対するネットワークベースのモビリティマネジメント機能をネットワークが用いるか否かを、モバイルノードによるプローブメッセージの送信時と受信時との間におけるホップカウントの差に基づいて検出する。より具体的には、１例では、モバイルノードにて、ホップカウントがプローブメッセージの送信時と受信時との間で閾値を上回って増加する場合に、ネットワークベースのモビリティマネジメント機能が検出され、そうでない場合で、セッションの継続性がサポートされるべきであるならば、モバイルノードはクライアントベースのモビリティマネジメント機能を実装する必要がある。例えば、ホップカウントが、モバイルノードによって／にてプローブメッセージを送信する時と受信する時の間で１より大きく変化している場合には、ネットワークベースのモビリティマネジメントがモバイルノードによって想定されうる。

いくつかの状況において、モバイルノードが、ネットワークによって用いられるモビリティマネジメント機能について結論付けることを可能にする他の指示又は状況が存在する場合には、モバイルノードはプローブメッセージを送信しない。例えば、１つの実施形態では、以下の条件のうち１つ以上が満たされる場合には、モバイルノードはプローブメッセージのみを送信する：
−ネットワークによるモバイルノードの認証と、ネットワークによるモバイルノードへのアドレス割当の間の期間が閾値時間よりも長いこと、
−ネットワークへの前回の接続より、ネットワークによって用いられるモビリティマネジメント機能がわかっていること。

例えば、モバイルノードが、ネットワークベースのモビリティを用いないネットワークに接続する場合、ネットワークへの接続後すぐに、モバイルノードのネットワーク認証を終了する時と、ローカルアドレスプレフィクスを提供する最初のルータ通知を受信する時との時間差は、小さい（すなわち、閾値時間よりも小さい）可能性があり、一方で、ネットワークベースのモビリティを用いるネットワークにおいて、この例のプロキシＭＩＰｖ６において、モバイルアクセスゲートウェイ（アクセスルータ）が、同一のネットワーク内に通知する前に、モバイルノードのアドレスプレフィクスを取得しなければならないことに鑑みて、タイムスパンはより長くなる可能性がある。

別の実施形態では、モバイルノードは、ネットワークに接続後すぐにネットワーク内のモバイルノードを認証するために、ネットワークへの認証手順を実行している。これによって、ネットワークへのＩＰ層の接続性を確立する前に、認証は実行される。

本発明の他の実施形態では、ネットワークによって用いられるＩＰモビリティマネジメント機能の検出が、ネットワークに対するモバイルノードの初期接続の後すぐに、新しいＩＰセッションを確立した後すぐに、又は、ネットワークによる新しいＩＰアドレスのモバイルノードへの割当の後すぐに実行される。

本発明の他の実施形態は、ネットワークによって用いられるＩＰモビリティマネジメント機能を検出するモバイルノードに関連している。このモバイルノードは、ＩＰヘッダの付いたプローブメッセージ−移動体端末のＩＰアドレスに宛てられるとともに、ＩＰホップカウントフィールドを含むプローブメッセージ−をネットワークへと送信する送信機と、ネットワークからプローブメッセージを受信する受信機とを備える。モバイルノードはさらに、ＩＰホップカウントフィールド中に含まれるホップカウントに基づいて、ネットワークがネットワークベースのモビリティマネジメント機能を用いるか否かを検出する処理装置を備える。

本発明の他の実施形態では、モバイルノードは、本明細書中に論じられた様々な実施形態の１つによるネットワークによって用いられるＩＰモビリティマネジメント機能を検出する方法のステップを実行する手段をさらに含む。

本発明の別の実施形態は、モバイルノードの処理装置によって実行される時に、ＩＰヘッダ付きのプローブメッセージをネットワークへと送信し、プローブメッセージは、移動体端末のＩＰアドレスに宛てられ、ＩＰホップカウントフィールドを含むことと、ネットワークからプローブメッセージを受信することと、ネットワークが、ＩＰホップカウントフィールド中に含まれるホップカウントに基づいて、モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いているか否かを検出することとによって、ネットワークによって用いられるモバイルノードに対するＩＰモビリティマネジメント機能をモバイルノードに検出させる指示を保存するコンピュータで読み取り可能な媒体に関する。

別の実施形態によるコンピュータで読み取り可能な媒体は、モバイルノードの処理装置によって実行される時に、本明細書中に論じられた様々な実施形態の１つによる、ネットワークによって用いられるＩＰモビリティマネジメント機能を検出する方法のステップをモバイルノードに実行させる指示をさらに保存している。

以下、添付図面を参照して本発明をより詳細に説明する。図面中の類似又は対応する詳細事項には、同一の参照番号が付けられている。

本発明の例示的な実施形態による、ネットワークベースのモビリティを用いるネットワーク内における、プローブメッセージの経路設定を示す 本発明の例示的な実施形態による、クライアントベースのモビリティを用いるネットワークにおける、プローブメッセージの経路設定を示す 本発明の異なる実施形態によるプローブメッセージの例示的なフォーマットを示す 本発明の異なる実施形態によるプローブメッセージの例示的なフォーマットを示す 本発明の例示的な実施形態によるモバイルノードからネットワークのアクセスルータ（ＡＲ／ＭＡＧ）へとプローブメッセージをトンネリングするためのＩＰパケットのフォーマットを示す 本発明の例示的な実施形態によるプローブメッセージのためのＩＰ対リンク層アドレスマッピングを示す モバイルノードが、モバイルノードに対するネットワークベースのモビリティマネジメントを用いるネットワークに接続する、本発明の実施形態による例示的なシグナリング手順を示す モバイルノードが、モバイルノードに対するネットワークベースのモビリティマネジメントを用いないネットワークに接続する、本発明の実施形態による例示的なシグナリング手順を示す ３ＧＰＰベースのユーザ装置が、ネットワークベースのモビリティマネジメントを用いる信頼できる非３ＧＰＰアクセスネットワークに接続し、アクセスネットワーク内でローカルである、本発明の例示的な実施形態による例示的なネットワークアーキテクチャを示す

以下の段落は、本発明の様々な実施形態を記載する。例示的目的のみのために、大部分の実施形態は上記の背景技術のセクションに論じられたクライアントＭＩＰｖ６又はプロキシＭＩＰｖ６ネットワークを用いるのに関連して概略が説明されるが、本発明は、この特定の例示的な通信ネットワークにおけるこれらプロトコルの使用に限定されない。

したがって、本明細書中にて用いられる用語は、主として、モバイルＩＰｖ６及びプロキシＭＩＰｖ６の標準化におけるＩＥＴＦによって用いられる用語と、さらに、３ＧＰＰに特有の特徴を論じる際に用いられる用語とに基づいている。しかしながら、モバイルＩＰｖ６、プロキシＭＩＰｖ６又は、３ＧＰＰシステムに特有の特徴に関する本実施形態の用語及び記載は、本発明の原理及び思想をシステム及びプロトコルに限定することを意図していない。

上記の背景技術のセクションで提供された説明は、本明細書中に記載された具体的な例示的な実施形態をよりよく理解するよう意図されており、移動体通信ネットワーク内におけるプロセス及び機能の記載された具体的な実装に、本発明を限定するものとして理解されるべきではない。それにもかかわらず、本明細書中において提案された改善は、背景技術のセクションで記載されたプロトコル／システムに容易に応用されてもよく、本発明のいくつかの実施形態における、これらプロトコル／システムの標準化及び改善された手順を利用してもよい。

以下において、本文書中に頻繁に用いられるいくつかの用語の定義が提供される。

モバイルノードは通信ネットワーク内の物理的なエンティティである。１個のノードがいくつかの機能上のエンティティを持ちうる。機能上のエンティティは、前もって定められた１組の機能を、ノードの他の機能上のエンティティ又はネットワークに実装する、及び／又は、提供するソフトウェア又はハードウェアモジュールのことを言う。ノードは、通信施設、又はノードが通信可能な媒体にノードを接続する１個以上のインタフェイスを持ちうる。同様に、ネットワークエンティティは、機能上のエンティティを、通信施設、又は、当該ネットワークエンティティが他の機能上のエンティティ又はノードと通信しうる媒体に接続する論理インタフェイスを持ちうる。

典型的には、ノードのインタフェイスには１個のＩＰアドレスが割り当てられる。しかしながら、複数のＩＰアドレスを１個のインタフェイスに割り当てることもまた可能である。さらに、複数の機能上のエンティティを備えるノードの場合には、１つ以上のアドレスは、それぞれの機能上のエンティティの論理インタフェイスに関連付けられてもよい。

一般に、各ネットワークは少なくとも１つの番号、例えばいわゆるプレフィクスによって識別される。この番号は、ネットワークでノードへのパケットの経路設定することを可能にする、すなわち、ロケータの目的に資する。さらに、この番号は、ネットワーク内のノードによって用いられることができる識別子のプールのことを言う。ネットワーク内のアドレスは、識別子のプールからの識別子であり、同時に、経路設定下部構造におけるロケータである。例えば、ＩＰｖ６では、あるネットワークの番号は、ＩＰｖ６プレフィクスであり、あるネットワーク内のアドレスは、ＩＰｖ６プレフィクス及びＩＰｖ６ホスト部から成るＩＰｖ６アドレスである。様々なネットワークでは、例えば、ホームネットワーク及び外部（フォーリン）ネットワークでは、異なるアドレスが用いられる。

以下に記載された本発明の実施形態では、ＩＰｖ６プロトコルが、プロトコルスタック内のネットワーク層（レイヤ３）を（少なくとも１部）形成すると想定されるものとする。

モバイルノードのホームネットワーク（すなわちホームリンク）は、典型的には、モバイルノードがモバイルノードの所定のホームアドレスに対する自己の気付アドレス（単数又は複数）を登録するホームエージェントの位置によって識別される。ホームアドレスとは、モバイルノードの恒久的なＩＰアドレスとして典型的に用いられたモバイルノードに割り当てられたＩＰアドレスである。このアドレスはモバイルノードのホームネットワークのプレフィクスを有する。気付アドレスとは、外部（フォーリン）ネットワークを訪問中にモバイルノードと関連付けられたＩＰアドレスである。気付アドレスのプレフィクスは、典型的には、ＣＭＩＰを用いる場合には、在圏ネットワーク（visited network）のプレフィクスに等しい。モバイルノードは１個以上の気付アドレスを同時に持ちうる。モバイルノードがＰＭＩＰドメイン内を移動中である場合には、ネットワークは、ＰＭＩＰドメイン内を移動中に、モバイルノードの特有のプレフィクスをモバイルノードに提供するので、移動はモバイルノードのＩＰ層に透過的（トランスペアレント）となる。したがって、上記の背景技術のセクションに記載されたように、ネットワーク内のプロキシ（モバイルアクセスゲートウェイ）は、モバイルノードから／へのデータグラムの適切な経路設定を保証するべく、モバイルノードのＰＭＩＰドメイン内の移動を管理するローカルモビリティアンカで新しい気付アドレス（プロキシバインディングアップデート）を登録するものとする。

ホームエージェントは、モバイルノードが自己の現在の気付アドレス（単数又は複数）を登録するモバイルノードのホームネットワーク上に経路設定機能を提供するルータ又は機能エンティティである。モバイルノードがホームから離れている一方で、例えば、モバイルノードのホームアドレスに宛てられたパケットをホームリンク上で受信（intercept）することと、それらをカプセル化することと、それらを１個又はいくつかのモバイルノードの登録された気付アドレス（単数又は複数）へとトンネリングすることとによって、ホームエージェントは、モバイルノードにモビリティサービスを提供してもよい。ＰＭＩＰを用いる時は、ローカルモビリティアンカ（ＬＭＡ）は、ＰＭＩＰドメイン内におけるモバイルノードのホームエージェントとも呼ぶことができる。

ＩＰｓｅｃセキュリティアソシエーションは、２個のノード又は機能エンティティが安全な通信をサポートするために共有する１組のセキュリティ情報として定義されてもよい。ＩＰｓｅｃセキュリティアソシエーションは、特に、モバイルノードと自己のサービングホームエージェントの間のいわゆるブートストラップを用いて確立されてもよい。例えば、セキュリティアソシエーションは、データ暗号化アルゴリズム、データ暗号化キー（単数又は複数）（例えば、秘密鍵又は公開／私有鍵の対、初期化ベクトル（単数又は複数）、デジタル証明書等）を含んでもよい。ＣＭＩＰでは、典型的には、外部（フォーリン）ネットワーク内のモバイルノードとホームネットワーク内の自己のホームエージェントとの間で提供されるセキュリティアソシエーションが存在する。こうして、たとえモバイルノードが外部（フォーリン）ネットワークに接続されている場合であっても、ホームエージェントとモバイルノードの間で（例えば安全なトンネルを通って）暗号化及び／又は認証／許可された通信が保証されてもよい。セキュリティアソシエーションは、典型的には、各終点のアドレス、すなわち、ホームエージェントアドレス及びモバイルノードのアドレスの１個（典型的にはホームアドレス）と結合している。

本発明の態様の１つは、ネットワークによってモバイルノードに対して用いられるモビリティマネジメント機能をモバイルノードが検出することを可能にする。基本的なアプローチは、これによって、モバイルノードは、モバイルノードに宛てられたプローブメッセージをネットワークへと送信させることである。モバイルノードからネットワークを介して経路設定され、モバイルノードへと戻っている場合に、１個以上のネットワークノードによるプローブメッセージの修正に基づいて、モバイルノードは、ネットワークがネットワークベースのモビリティマネジメント機能を用いているか否かを判定することができる。

本発明の別の１つの態様によると、モバイルノードは、モバイルノードからネットワークへと経路設定され、モバイルノードへと戻っている時に、プローブメッセージが横切るホップの数に基づいて、ネットワークによって用いられるモビリティマネジメント機能を検出し、モバイルノードは、ネットワークによって用いられるモビリティマネジメント機能について結論付けることができる。プローブメッセージのホップカウントを監視するために、プローブメッセージは、ＩＰパケットとして送信されてもよい。プローブメッセージのＩＰヘッダ中のホップカウントフィールドに基づいて、モバイルノードは、ネットワークによって用いられるモビリティマネジメント機能について結論付けることができる。

例えば、ネットワークがＰＭＩＰ（すなわち、ネットワークベースのモビリティマネジメント機能がモバイルノードに用いられる）を図１に示すネットワークアーキテクチャ内で稼動すると仮定した場合は、プローブメッセージは、ＰＭＩＰプロトコルによるとＩＰホップ（ＭＡＧ→ＬＭＡ→ＭＡＧ）を介して少なくとも経路設定されるであろうと思われ、ＭＡＧは、デフォルトで、接続されたモバイルノードから受信したすべてのデータパケットをＬＭＡへと転送する；ＭＡＧがローカル転送を適用するよう設定される場合のみ、このことがあてはまらない（以下を参照のこと）。ネットワークがネットワークベースのモビリティを用いない、すなわち、クライアントベースのモビリティマネジメント機能（例えばＣＭＩＰ）が、セッションの継続性を保証するためにモバイルノードによって用いられる必要がある場合には、プローブメッセージは、１個のホップのみを経由して、すなわち、ネットワークのアクセスルータ（ＡＲ）がモバイルノードへと戻って、通常経路設定されるであろう。それゆえに、モバイルノードは、より早期に自己のＩＰアドレスへと送信された受信されたプローブメッセージのホップカウントに基づいて、ネットワークがＰＭＩＰを稼動するか否か、又は、ＣＭＩＰを用いる必要があるか否かを検出できる。

本発明の別の態様によると、モバイルノードは、ネットワーク内の中間ネットワークノードによるプローブメッセージの修正に基づいて、ネットワークによって用いられるモビリティマネジメント機能を検出してもよい。例えば、プローブメッセージは、ネットワークベースのモビリティマネジメント機能が活用される場合には、ローカルモビリティアンカ又はモバイルアクセスゲートウェイによって修正されるフラグ又はフィールドを含んでもよい。ホップカウントの代わりに（又はそれに加えて）、プローブメッセージ中のフラグ又はフィールドのステータスは、モバイルノードに対して、ネットワークベースのモビリティマネジメント機能がネットワークによって用いられるか否かを指示している。ＰＭＩＰを実施するネットワークの場合には、モバイルアクセスゲートウェイ（ＭＡＧ）又はローカルモビリティアンカ（ＬＭＡ）は、ＭＡＧ又はＬＭＡの存在、すなわちＰＭＩＰの使用、を指示しているプローブメッセージ中のフラグをそれぞれ切り替えうるであろうが、一方で、ＰＭＩＰを用いないネットワーク内のアクセスルータは、プローブメッセージ中のフラグを切り替えないであろう。

プローブメッセージは、すなわちＩＰヘッダ及びペイロードを含むＩＰパケットとして送信されてもよい。ペイロードのサイズは、例えば、プローブメッセージがＩＰヘッダの手段によって識別されうる場合には、ゼロであるかもしれない。例えば、ＩＰｖ６ヘッダの「トラフィッククラス」又は「フローラベル」フィールドは、ネットワークベースのモビリティマネジメントを指示するべく、中間ネットワークノード（例えば、ＬＭＡ又はＭＡＧ）中において修正されうる。別の代替例は、ネットワークベースのモビリティマネジメントを指示するべく、中間ネットワークノード中に切り替えられるプローブメッセージのペイロードセクションへと、フラグを含める。

本発明の原理は、図１及び図２に基づいて、さらに詳細に以下に概略を説明する。図１は、本発明の例示的な実施形態によるネットワークベースのモビリティ機能を用いることを想定されるネットワーク内におけるプローブメッセージの経路設定を示す。この例示的な実施形態では、ネットワークベースのモビリティマネジメント機能はＰＭＩＰであり、モバイルノード１００はＰＭＩＰドメインのネットワークに最初に接続している。

一般に、モバイルノード１００は、ＰＤＮ接続又はＩＰセッション（例：初期接続の後すぐに）を、ＷｉＦｉネットワーク、ＷＬＡＮネットワーク、ＧＳＭ、ＵＭＴＳ、ＬＴＥ／ＳＡＥ等の３ＧＰＰベースのネットワークといったＩＰ接続性を提供するネットワークの任意の種類と確立してもよい。このコンテキストにおいて、ＰＤＮ接続又はＩＰセッションを確立することは、モバイルノード１００が、ある１つのアクセスシステムから別のアクセスシステムへの、又は、ある特定のＩＰセッションの事業者の１つのサービスエリアから別のサービスエリアへの、ハンドオーバを実行していないことを意味するが、ネットワークに接続し、及び、新しいパケットデータネットワーク（ＰＤＮ）接続、それぞれのＩＰセッションとのネットワークと確立する。３ＧＰＰでは、ＰＤＮ接続の確立は、新しいＩＰアドレス又はＩＰプレフィクスの割当を、モバイルノードへと含める。また、本発明は、モバイルノードごとに複数回のＰＤＮ接続（３ＧＰＰ用語においてユーザ装置ＵＥと呼ばれる）が許可される時にも適用することができ、モバイルノードは追加的又は新しいＰＤＮ接続を確立し、それは既存のＰＤＮ接続（単数又は複数）とは異なるモビリティマネジメントスキームを用いるかもしれない。

図１を参照すると、モバイルノード１００は、モバイルノードに対するネットワークによって用いられるモビリティマネジメント機能を検出するために、自己に宛てられたプローブメッセージをネットワークへ送信する。ネットワークがＰＭＩＰドメインに属すると仮定すると、ネットワーク内のかかるプローブメッセージを受信するＩＰ層エンティティは、ネットワーク内におけるモバイルノード１００のＩＰ層アクセスルータであると想定されうる、いわゆるモバイルアクセスゲートウェイ（ＭＡＧ）１０１である。モバイルノードから、ＩＰパケット、すなわちこの例ではプローブメッセージを受信する時には、ＭＡＧ１０１は、デフォルトで、ＰＭＩＰドメイン内のモバイルノード１００に対するホームエージェントとして機能するＰＭＩＰドメイン内のローカルモビリティアンカ（ＬＭＡ）１０２へと、ＩＰパケットを転送する。ＭＡＧ１０１は、プローブメッセージを転送する前に、ＩＰヘッダフィールド中のホップカウントを１ずつ増加させる。ＬＭＡ１０２は、プローブメッセージを受信し、ＭＡＧ１０１を介して、モバイルノード１００へと戻すよう経路設定し、両ノードはＩＰヘッダ中のホップカウントを増加させる。したがって、モバイルノードに対するＰＭＩＰを用いるネットワークへとプローブメッセージを送信する時は、モバイルノード１００によって送信されたプローブメッセージと、モバイルノード１００へと返信されたプローブメッセージとのホップカウントの差は３（図１のトポロジーがあること、及び、さらなる中間ＩＰホップ／ルータがないと仮定する）である。

図２は、モバイルノードに対するネットワークベースのモビリティ機能がネットワーク内で用いられないと仮定して、本発明の例示的な実施形態によるネットワーク内のプローブメッセージの経路設定を示す。ネットワークがネットワークベースのモビリティマネジメント機能を用いないことから、モバイルノード１００は、クライアントベースのモビリティマネジメント機能を用いる必要があり、ここでは、例示的な目的では、ＣＭＩＰ（ＭＩＰｖ４又はＭＩＰｖ６）は、新しいＩＰセッションに対するセッション継続性を保証する。モバイルノード１００は、最初は、ネットワークに接続するか、又は、ＰＤＮ接続もしくはＩＰセッションを確立するか、又は、ネットワークによって新しいＩＰアドレスが割り当てられる。本質的に、図２における開始点は図１の開始点と類似している。しかしながら、モバイルノード１００に送信され、かつ宛てられたプローブメッセージは、ネットワークのアクセスルータ（ＡＲ）２０１によって受信され、それは、プローブメッセージのＩＰヘッダ中のホップカウントを増加した後、プローブメッセージをモバイルノード１００へと戻すよう経路設定している。したがって、正常な状況のもとでは、モバイルノード１００によって送信されたプローブメッセージと、プローブメッセージに返信されたモバイルノード１００との間のホップカウントの差は、ネットワークによってネットワークベースのモビリティが用いられない場合では、１である。

上記に示したように、本発明のいくつかの実施形態では、モバイルノードは、モバイルノードに対してネットワークによって用いられるモビリティマネジメント機能を検出し、必要に応じて適切なステップをとるべく、プローブメッセージを送信する時と受信する時の間のホップカウントの差を考慮する。

ＩＰプロトコル仕様によってプローブメッセージを送信することが許可され、ネットワーク内のＩＰルータによってプローブメッセージを適切に経路設定するべくように、モバイルノード１００は、ネットワーク内で有効なＩＰアドレスで構成される必要があることが、一般に留意されるべきである。したがって、モバイルノードは、典型的には、ネットワークによってサポートされるモビリティマネジメント機能を発見する前に、ネットワーク内で有効なＩＰアドレスを設定しなければならないかもしれない。

ここで図３及び図４に向けて、本発明の異なる実施形態によるプローブメッセージの構成をより詳細に記載する。図３及び図４は、本発明の異なる実施形態によるＩＰパケットとしてのメッセージのフォーマットを示す。両方のメッセージフォーマットは、プローブメッセージ、すなわちＩＰパケットをまとまって形成する、ＩＰヘッダ及びペイロードセクションから成る。

両方のメッセージフォーマットでは、モバイルノードは、プローブメッセージのＩＰソースアドレス（ｓｒｃ：ＭＮ）及びＩＰ宛先アドレス（ｄｓｔ：ＭＮ）を、ネットワーク内に設定された自己のＩＰアドレスに設定する。さらに、ＩＰヘッダのホップカウントフィールドは、ネットワークを介した経路設定するためにホップカウントフィールド中の変更をモバイルノードが検出できるように、所定の値（モバイルノード内で保存される）又はゼロに初期化されてもよい。

図３及び図４に示されるメッセージフォーマットにおいて、プローブメッセージは、モバイルノードが、送信されたプローブメッセージを受信されたプローブメッセージと対応付けることができるように、識別子ＩＤ（例えばノンス又はシーケンス番号）を随意的に含んでもよい。このことは、モバイルノードが１個以上のプローブメッセージを送信している場合には有用であるかもしれない。

モバイルノードに対するＰＭＩＰを用いるネットワーク内では、プローブメッセージは少なくとも３個のＩＰホップ（ＭＡＧ１０１、ＬＭＡ１０２、ＭＡＧ１０１）を経由して経路設定されるであろうが、一方では、モバイルノードに対してＰＭＩＰを用いないネットワーク内では、プローブメッセージは１個のホップ（ＡＲ２０１）のみを経由してモバイルノードへと戻って経路設定されるであろう（図１及び図２を参照のこと）。それゆえに、モバイルノードは、受信されたプローブメッセージのホップカウントに基づいて、ネットワークがＰＭＩＰサービスを用いるか否かを検出することができ、それに、モバイルノードがより早期に自己のＩＰアドレスへと送信している。したがって、初期のホップカウントがゼロに設定されなかった場合には、モバイルノードは、モバイルノードによるその送信とその受信との間でプローブメッセージを通過させることによってホップの数を求めるために、受信されたプローブメッセージのホップカウント及び対応する（保存された）初期のホップカウントを差し引いてもよい。例えば、差が１を上回る場合は、モバイルノードはＰＭＩＰサービスが用いられていることを想定する。そうでない場合には、ネットワークベースのモビリティサポートのない単純なＩＰアクセスサービスを想定する。

ＩＰヘッダ中のホップカウントフィールドの代わりに又は加えて、プローブメッセージは、ネットワーク内におけるネットワークベースモビリティマネジメント機能の使用を指示するために、プローブメッセージが経路設定する中間ノードのうち１個によって設定されるフラグＦ−図４を参照−を含んでもよい。例えば、図１に戻ると、ＭＡＧ１０１又はＬＭＡ１０２は、ネットワークが、モビリティマネジメントに使用されているＰＭＩＰドメイン及びＰＭＩＰに属していることを指示するために、フラグＦをプローブメッセージ中のフラグＦを設定することができる。

モバイルノード１００のＩＰ宛先アドレスを備えたＩＰパケットをモバイルノード１００から送信することは、モバイルノード内でＩＰスタックがどのように実装されるか否か次第で問題となるであろう。したがって、モバイルノードのＩＰスタックは、パケットをモバイルノード入力インタフェイスへと内部的に、すなわち、プローブメッセージが、ネットワーク内のモバイルノード１００のアクセスルータ（ＭＡＧ１０１又はＡＲ２０１）を介して送信及び経路設定されることなく、経路設定するであろう。この問題を克服するために、本発明の別の実施形態によると、モバイルノード１００は、ＩＰトンネルを介して、ネットワーク内のデフォルトルータアドレス、すなわち、ルータネットワーク内の自己のアクセスルータにプローブメッセージを送信する。

図５は、かかるトンネリングされたプローブメッセージの例示的なフォーマットを示す。プローブメッセージ（ＩＰパケット）が、ヘッダがネットワーク内のアクセスルータのＩＰアドレス（ｄｓｔ：ＡＲ／ＭＡＧ）をＩＰ宛先アドレスとして指示している、別のＩＰパケットへのペイロードとしてカプセル化される。トンネリングされたプローブメッセージを受信するＡＲ２０１又はＭＡＧ１０１は、図２及び図１にそれぞれ示されるように、プローブメッセージを脱カプセル化し、モバイルノード１００へと戻すようを経路設定するか、又は、脱カプセル化されたプローブメッセージをＬＭＡ１０２へと転送するかのいずれかであろう。

代替的には、本発明の他の実施形態では、モバイルノードのＩＰ対リンク層アドレスマッピングは、モバイルノードが、プローブメッセージのリンク層宛先アドレスをネットワーク内のアクセスルータのデフォルトルータアドレス、すなわち、ＭＡＧ１０１又はＡＲ２０１のリンク層（レイヤ２）アドレスにと、プローブメッセージのリンク層ソースアドレスをモバイルノードリンク層ソースアドレスにと設定するように、修正される。このことは、図６に示される。

図７は、本発明の実施形態による例示的なシグナリング手順を示し、モバイルノード１００は、モバイルノード１００へのネットワークベースのモビリティマネジメントを用いるネットワークに接続する。

最初のステップでは、モバイルノード１００は、例えばモバイルノードの初期接続の後すぐに、アクセスネットワーク（ＡＮ）へのＰＤＮ接続（又はＩＰセッション）７０１を確立するためにトリガした。この接続手順は、モバイルノード１００と、ネットワークと、ネットワーク内のモバイルノード１００の認証との間で、レイヤ２の接続性を確立することを想定されている。さらに、この例示的な実施形態では、モバイルノード１００が接続するＭＡＧ１０１には、ネットワーク内でのモバイルノード１００の識別を可能にするモバイルノードのＩＤ（ＭＮ−ＩＤ）が提供されることが仮定される。

例えば、アクセスネットワークが、３ＧＰＰ ＳＡＥ仕様（３ＧＰＰ ＴＳ２３．４０２）によるＰＭＩＰを用いる信頼できる非３ＧＰＰアクセスネットワークである場合には、ＥＡＰ認証手順がモバイルノード（ＵＥ）によって実行される。ＭＡＧは、ＡＡＡクライアントとして機能し、レイヤ２認証手順中のモバイルノードから受信したＥＡＰメッセージを３ＧＰＰ ＡＡＡサーバへと転送する。認証の成功の後すぐに、ＡＡＡサーバは、いくつかある他の情報の中で、パケットデータネットワーク−ゲートウェイＰＤＮ−ＧＷ（ＬＭＡ）アドレス及びモバイルノードＩＤ（ＮＡＩ）をＭＡＧに戻し、次いで、それは、プロキシバインディングアップデート（ＰＢＵ）をローカルモビリティアンカに送信することができる。

ネットワークは、自己のサービスエリア内でＰＭＩＰを用いると仮定されることから、ＭＡＧ１０１は、認証手順中に取得したモバイルノード１００の識別子（ＭＮ−ＩＤ）の付いたプロキシバインディングアップデート（ＰＢＵ）を、「ＰＭＩＰホームエージェント」すなわちＬＭＡ１０２に送信する（ステップ７０２）。プロキシバインディングアップデートメッセージは、特に、モバイルノード１００（ＭＮ−ＩＤ）を識別するためのネットワークアクセス識別子（ＮＡＩ）オプションと、本明細書中の背景技術のセクションにて事前に説明したタイムスタンプオプションを含んでいる。

ＰＭＩＰでは、すべてのモバイルノードには典型的には固有のプレフィクス、いわゆるホームプレフィクスが割り当てられ、それはＰＭＩＰドメイン内のモビリティマネジメントに用いられる。モバイルノードのホームプレフィクスは、初期プロキシバインディングアップデートを送信する（ステップ７０２）時には、ＭＡＧ１０１に知られていない。このように、モバイルノード１００がＭＡＧ１０１を介して最初にネットワークに接続し、ＬＭＡ１０２がＭＡＧ１０１からプロキシバインディングアップデートを受信した（ステップ７０２）時は、ＬＭＡ１０２は、固有のプレフィクス（ＭＮ−プレフィクス）をモバイルノード１００に割り当て、モバイルノード１００へと宛てられるルータ通知（ＲＡ）を用いているモバイルノード１００への、ＭＡＧ１０１によるプレフィクスの通知（ステップ７０４）のために、プロキシバインディングアップデート確認（ＰＢＵ）内において、プレフィクスをＭＡＧ１０１に提供する（ステップ７０３）。モバイルノード１００は、プレフィクスに基づいてＩＰアドレスを構成する（ステップ７０５）ために、ルータ通知において受信されたプレフィクス（ＭＮ−プレフィクス）を用いる。

しかしながら、モバイルノード１００は、最初にネットワークに接続する時に、アクセスルータ（ここではＭＡＧ１０１）から受信したルータ通知ＲＡが、ネットワークのローカルプレフィクス又はＬＭＡに固定されたＰＭＩＰプレフィクスを含むか否か、−もしくは言い換えれば、ネットワークがこのモバイルに対してネットワークベースのモビリティを用いることを必要とするか否か−を知らない。一般的には、ネットワークによって用いられるモビリティマネジメント機能をモバイルノードが「推測する」のを可能にするモバイルノードへのいくつかのヒントがあるかもしれない。かかるヒントの評価は、ネットワークによって用いられるモビリティマネジメント機能が、幾分すでに知られているか、又は、モバイルノード１００によって推測できるか否かを、モバイルノードが評価することができることを、ステップ７０６にて例示されている。この随意的なステップに関する詳細が以下に説明される。

図７の例では、モバイルノード１００が、いくつかの手段によってネットワークによって使用されているネットワークベースのモビリティマネジメント機能を知っている場合には、モビリティがネットワークによって管理されることから、モバイルノード１００はすぐにＩＰ通信を開始してもよい（すなわち、ステップ７０６からステップ７１３は省略することができる）。

モバイルノード１００が、ネットワークによって用いられるモビリティマネジメント機能について定かでないか、又は、知らない場合には、モバイルノード１００は、上記の図３及び図４に示されるフォーマットの１つにより、プローブメッセージをＭＡＧ１０１に送信する（ステップ７０６）。プローブメッセージは、モバイルノード１００のＩＰ層へと内部的に戻すように、プローブメッセージが経路設定されていないことを確実にするために、ＭＡＧ１０１にトンネリングされてもよく、又は、ＩＰ対リンク層マッピングは、プローブメッセージのＩＰ宛先フィールド中のモバイルノード１００のＩＰアドレスを、ＭＡＧ１０１のリンク層アドレスと対応付ける。

ＭＡＧ１０１は、ＲＦＣ５２１３に指示されたプローブメッセージのＩＰヘッダの「ホップカウント」フィールド中のホップカウント（ｈｃ＝１）を増加した（ステップ７０７）後すぐに、プローブメッセージをＬＭＡ１０２上で渡す（ステップ７０８）。同様に、ＬＭＡ１０２は、プローブメッセージがモバイルノード１００のＩＰアドレスに宛てられることを検出し、ホップカウント（ｈc＝２）を増加させ（ステップ７０９）、及び、プローブメッセージをＭＡＧ１０１に戻すよう経路設定する（ステップ７１０）。ＭＡＧ１０１は、再び、プローブメッセージのホップカウント（ｈc＝３）を増加させ（ステップ７１１）、同じものをモバイルノード１００へと転送する（ステップ７１２）。

上記に説明されたように、モバイルノード１００は、モビリティマネジメント機能を検出する（ステップ７１３）ために、返信されたプローブメッセージ（及び必要に応じて送信されたメッセージ）中のホップカウントを評価する。ホップカウントは、この例では、プローブメッセージが３個のホップを通過したことを指示することから、モバイルノード１００は、ネットワークがモバイルノードに対するネットワークベースのモビリティマネジメント機能を用いている、すなわち、通告された（ステップ７０４）プレフィクスがＰＭＩＰプレフィクスであることを結論付けた。モビリティマネジメントはこうしてネットワークによって取り扱われることから、モバイルノード１００は、こうして、すぐにＩＰ通信を開始してもよい。

図８は本発明の実施形態による例示的なシグナリング手順を示し、そこでは、モバイルノードは、ネットワークに接続するとともに、クライアントベースのモビリティマネジメントを用いる。図７に示される例示的な実施形態とは対照的に、例示的な目的により、本発明の実施形態により、ネットワークはネットワークベースのモビリティマネジメント機能を用いていないことが仮定される。

図７のように、モバイルノード１００は、ネットワークへのＰＤＮ接続（又はＩＰセッション）を最初に確立する（ステップ７０１）と仮定される。ネットワークに接続し、ＩＰ層の接続性を確立した後すぐに、モバイルノード１００は、ＡＲ２０１によって管理（serve）されるネットワーク／ドメインのローカルアドレスプレフィクス（ＡＮ−プレフィクス）をモバイルノード１００に提供しているルータ通知ＲＡを、ＡＲ２０１から受信する（ステップ８０１）。しかしながら、モバイルノードは、プレフィクスがローカルアクセスネットワーク内のＬＭＡ又はコアネットワーク内のＬＭＡのいずれに固定されているかを知らないので、ルータ通知ＲＡは、モバイルノード１００が、コアネットワークによって決定されるモビリティマネジメント機能について結論を出すには十分ではない。次のステップでは、モバイルノード１００は、通告されたプレフィクスにしたがってＩＰアドレス（すなわち気付アドレス−ＣｏＡ）を設定する（ステップ８０２）。

アドレス構成（ステップ８０２）の後に、モバイルノード１００の状況は、図７におけるアドレス構成（ステップ７０５）の後と同様である。図７のステップ７０６と類似して、モバイルノードは、プローブメッセージを送信することによりネットワークモビリティマネジメント機能を探索するための追加的なシグナリング遅延は不必要であるように、ネットワークによって用いられるネットワークマネジメント機能について結論付けるためのいくつかのヒントがあるか否かを随意的に確認する（ステップ８０３）ことで、ステップ８０４からステップ８０７は省略されてもよい。

モバイルノード１００が依然としてネットワークのモビリティサポートの種類を知らないことを考慮すると、モバイルノード１００は、上記の図３及び図４に示されるフォーマットの１つによるプローブメッセージを、ネットワークに対する自己のアクセスルータ、ここではＡＲ２０１へと送信する（ステップ８０４）。プローブメッセージは、モバイルノード１００のＩＰ層へと内部的に戻すように、プローブメッセージが経路設定されていないことを確実にするために、ＡＲ２０１へとトンネリングされてもよく、又は、ＩＰ対リンク層マッピングは、プローブメッセージのＩＰ宛先フィールド中のモバイルノード１００のＩＰアドレスを、ＡＲ２０１のリンク層アドレスに対応付ける。

ＡＲ２０１は、プローブメッセージを受信し、ホップカウント（ｈｃ＝１）を増加した（ステップ８０５）後に、プローブメッセージをモバイルノード１００へと戻すよう送信する（ステップ８０６）。

モバイルノード１００は、プローブメッセージを受信し、プローブメッセージを送信する時と受信する時とのホップカウントの差に基づいて、ＩＰアドレス変更の後すぐにセッション継続性を必要とする場合には、クライアントベースのモビリティマネジメントスキームを用いなければならないように、ネットワークがネットワークベースのモビリティ機能を用いないことを認識した（ステップ８０７）。

したがって、モバイルノード１００は、ホームネットワーク内の自己のホームエージェントによってブートストラップを実行しており（ステップ８０８）、それは、ホームネットワーク内のサービングホームエージェントを発見すること、モバイルＩＰシグナリングを確保するためにホームエージェントによるＩＰｓｅｃセキュリティアソシエーションを設定すること、及び、対応するホームアドレスをモバイルノード１００で構成することを含んでいる。ＩＰ層をブートストラップした後すぐに、モバイルノード１００は、ローカルプレフィクスＡＮ−プレフィクスに従って構成された自己の新しいＩＰアドレスを、自己のサービングホームエージェントでの自己の新しい気付アドレスＣｏＡとして（自己のホームアドレスＨｏＡのもとでは到達可能、かつ気付アドレスが変更している場合にはセッション継続性を可能にするべく）登録する（ステップ８０９）。

ステップ７０６及びステップ８０３に関して上記に示したように、モバイルノードが、接続直後にネットワークによって用いられるモビリティマネジメント機能の種類を知っているかもしれないか、もしくは、これを推測しうるかもしれない。モバイルノードの推測に対する１個のヒントは、ネットワークによる認証手順を終了する時間とアドレス割当（図７及び図８のステップ７０４及びステップ８０１を参照のこと）の間の時間が、所定の閾値時間よりも長くなりうることである。タイムスパンがより長い場合には、この長い時間によって、アクセスルータ（すなわちＭＡＧ１０１）がプロキシバインディングアップデートを送信し、ＰＭＩＰプレフィクスを含むＬＭＡ１０２の応答を待たなければならず、その後に、最も早い時間に「遅延した」アドレス割当をきたすことをＰＭＩＰプレフィクスに通告するのみであることが生じうる。したがって、モバイルノード１００は、ＰＭＩＰがネットワーク内で用いられると結論付けるかもしれない。対照的に、ＣＭＩＰを用いるときは、アドレス割当に対するルータ通知の伝送（図８、ステップ８０１を参照のこと）は、ネットワークエンティティからの追加的なプレフィクス割当によって遅延されない。したがって、モバイルノード１００の認証と最初のルータ通知の受信との間の遅延は短くするべきである。したがって、最初のルータ通知が閾値時間内で受信される場合には、モバイルノード１００は、ネットワークがネットワークベースのモビリティを用いていないと結論付けうる。

追加的なヒントは、ルータ通知がモバイルノード（単数又は複数）にアドレス指定される方法であってもよい。通常、非送信要請（unsolicited）型ルータ通知が非送信要請（unsolicited）型マルチキャストＩＰｖ６アドレスに送信されるが、一方、送信要請（solicited）型ルータ通知のみが、ユニキャストを介して、要請しているモバイルノードに送信される。ＰＭＩＰｖ６仕様は、モバイルノードあたり固有のホームプレフィクスを必要とし、このことは、ホームプレフィクスを通知するルータ通知メッセージが１個のモバイルノードによってのみ受信されることを意味する。

ＭＡＧとモバイルノードの間のレイヤ２リンクがポイントトゥポイントリンクである場合には、たとえ宛先アドレスがマルチキャストアドレスであっても、このリンク上で送信されるあらゆるルータ通知は、モバイルノードによってのみ受信される。レイヤ２リンクが共有リンクである場合には、ルータ通知の宛先ＩＰアドレスは、１個のモバイルノードのみがホームプレフィクスを受信することを保証するべく、ユニキャストアドレス（例えば、モバイルノードのリンクローカル（link-local）ＩＰアドレス）に設定されるべきである。それゆえに、レイヤ２リンクが共有リンクであり、モバイルノードによって受信された非送信要請（unsolicited）型ルータ通知が自己の宛先アドレスとしてのユニキャストアドレスを持つ場合には、モバイルノードは、このことをネットワークベースのモビリティがネットワークによって用いられていることのヒントとして考慮するかもしれない。

別のヒントは、モバイルノード１００の「接続履歴」を検討している可能性がある。例えば、モバイルノード１００は、ネットワーク、又は、アクセスルータ識別子（例えば、ＩＰアドレス又はＭＡＧアドレス）又は割り当てられたホームプレフィクスでの前回のセッション、及び、用いられたそれぞれのモビリティマネジメント機能の履歴を維持（保存）しうる。

別のオプションは、モバイルノード１００が、アクセスルータ（ＡＲ／ＭＡＧ）及び／又は存在する場合にはＬＭＡアドレスを求めるために、経路探索を実行することであってもよい。発見されたアドレス（単数又は複数）のモバイルノードのプレフィクスを、又は、発見されたアドレス（単数又は複数）のコアネットワークプレフィクスを比較することによって、モバイルノード１００は、プレフィクスが、コアネットワーク内のＬＭＡに固定されたＰＭＩＰプレフィクスであるか否かを結論付けうるであろうし、ネットワーク内で用いられているモビリティマネジメント機能で結論付けうるであろう。

ネットワーク内のネットワークベースのモビリティの使用又は非使用についてのこれら異なるすべてのオプション及びヒントは、当然のことながら、モビリティマネジメント機能のフェールセイフ検出を保証しない。それゆえに、安全を期して、モバイルノード１００は、常にプローブメッセージを送信し、かつ、モビリティマネジメント機能上に存在するヒントをプローブメッセージによって随意的に確認するよう設定されうる。しかしながら、別の実装において、ネットワークベースのモビリティマネジメントがネットワークによって用いられているか否かの１つ以上のヒントによって、ネットワークベースのモビリティマネジメント機能の使用について結論付けるための十分に高いレベルの確実性を提供してもよいために、プローブメッセージを送信することを回避することができる。

次に、３ＧＰＰ ＬＴＥ／ＳＡＥシナリオに関連した他の例示的及びより具体的な実施形態の概略をより詳細に説明する。技術分野のセクションにおいて示されたように、ユーザ装置のホームコアネットワーク（３ＧＰＰ用語におけるモバイルノード）は３ＧＰＰベースのネットワークである。しかしながら、３ＧＰＰ ＬＴＥ／ＳＡＥシナリオでは、ユーザ装置は信頼されない、又は、信頼できる非３ＧＰＰベースのアクセスネットワーク（例えば、ＷＬＡＮ、ＷｉＭＡＸ等）にも接続しうる。ユーザ装置は非３ＧＰＰベースのネットワークに接続する可能性があるが、３ＧＰＰコアネットワーク内のＩＰモビリティモードセレクション（ＩＰＭＳ）機能は依然として、ユーザ装置によって用いられることとなるモビリティマネジメント機能を判定中である。

以下の実施形態は、検出プロセスの最適化を記載する。ユーザ装置が新しいＩＰセッション又はＰＤＮ接続を開始する場合には、上記に記載されたヒントによってＩＰＭＳの結果を推測してもよく、又は、クライアントベースマネジメントがＩＰＭＳによって選択されていると結論付けた場合には、すぐにいずれかのＤＳＭＩＰｖ６ブートストラップを実行してもよい。ユーザ装置の推測が正しかった、すなわち、ＤＳＭＩＰｖ６ブートストラップ中に実行されたホームリンク検出が、ユーザ装置がホームにないことを示している、すなわち、これによってクライアントベースのモビリティマネジメント機能の使用が確認される場合は、そのときに、プローブメッセージは送信される必要はなく、ＤＳＭＩＰ登録は、すぐにブートストラップに従うことができる。ユーザ装置が、反対に、ネットワークベースのモビリティ機能がＩＰＭＳによって選択されることを結論付けた場合には、ユーザ装置は、自己の仮定を確認するためにプローブメッセージをネットワークへと送信する。この場合には、ユーザ装置の仮定が正しかった場合には、ブートストラップは必要でない。

この３ＧＰＰ ＳＡＥ／ＬＴＥシナリオにおいて、非３ＧＰＰ事業者は、自己のアクセスネットワーク内におけるローカルモビリティマネジメントのための、ＰＭＩＰサービスといったネットワークベースのモビリティマネジメント機能を配置することが起こりうる、すなわち、ＬＭＡは、３ＧＰＰコアネットワークの代わりに、非３ＧＰＰアクセスネットワーク内に配置された非３ＧＰＰエンティティである。このネットワークベースのモビリティマネジメント機能サービスは、こうして、３ＧＰＰの適用範囲外となり、それゆえに、ＩＰＭＳの１部とはならないであろう。したがって、ＩＰＭＳがクライアントベースのモビリティマネジメントを選択したが、モバイルノードが、プローブメッセージを送信した結果として、ネットワークベースのモビリティマネジメントを検出することが起こりうる。このシナリオは、本発明の実施形態による例示的なネットワークアーキテクチャを描写する図９において、例として示され、ここでは、３ＧＰＰベースのユーザ装置（ＵＥ９００）が信頼できる非３ＧＰＰアクセスネットワークに接続しており、それは、局地的に、アクセスネットワーク内のネットワークベースのモビリティマネジメントを用いる。

図９では、ＵＥ９００は、非３ＧＰＰベースのアクセスネットワーク内でのネットワークベースのモビリティを可能にするために、モバイルアクセスゲートウェイ（ＡＲ＆ＭＡＧ９０１）として作動しているアクセスルータを介して、信頼できる非３ＧＰＰベースのアクセスネットワークに、最初に接続している。非３ＧＰＰベースのアクセスネットワークはさらに、ＵＥ９００の３ＧＰＰベースのホームネットワーク内のアクセスネットワーク内のネットワークベースのモビリティを可能にするための機能性を、ＬＭＡ９０２に提供する。非３ＧＰＰベースのアクセスネットワークはさらに、ＵＥ９００の３ＧＰＰベースのホームネットワーク内のパケットゲートウェイＰＤＮ−ＧＷ９０４に接続しているアクセスゲートウェイＡＧＷ９０３を介して、ＵＥ９００のホームネットワーク（３ＧＰＰベースのネットワーク）に接続しており、それは、ＣＭＩＰホームエージェントサービングＵＥ９００が位置していることを含める。

ＩＰＭＳは、ＵＥ９００に対してクライアントベースのモビリティマネジメントを選択しているので、ＵＥ９００は、３ＧＰＰコアネットワーク内の自己のホームエージェント（ＰＤＮ−ＧＷ９０４）で自己の新しい気付アドレスを登録するべきである。ＵＥ９００が、用いられることとなる適用可能なモビリティマネジメント機能を検出しようと試みていると仮定すると、ＵＥ９００は、上記に論じられたようなプローブメッセージを送信するものとする。非３ＧＰＰベースのアクセスネットワークの事業者もまたＰＭＩＰを提供していることから、ＡＲ＆ＭＡＧ９０１のＰＭＩＰ ＭＡＧ機能は、上記の図１及び図７に関して論じられたシナリオと同様にプローブメッセージをＵＥ９００へと戻すＬＭＡ９０２へとプローブメッセージを経路設定するものとする。したがって、ＵＥ９００は、ＩＰＭＳはクライアントベースのモビリティを選択したものとはいえ、ネットワークベースのモビリティマネジメント機能を検出するものとする。

ＩＰＭＳに知られていないネットワークベースのモビリティ機能を実施する非３ＧＰＰベースのアクセスネットワークの事業者によるモビリティ機能の誤検出を回避するために、ＵＥ９００は、ＬＭＡ９０２が３ＧＰＰエンティティであるか否かを検出するために有効にされうる。ＬＭＡ９０２が３ＧＰＰエンティティである場合には、それは、ＩＰＭＳに知られており、かつ、選択されたモビリティマネジメント機能を気付いていることを意味している。それゆえに、プローブメッセージが３ＧＰＰ ＬＭＡ機能を備えたネットワークノードを通過させられる場合には、ＵＥ９００は、ネットワークベースのモビリティマネジメントがＩＰＭＳによって選択されたと結論付けることができる。

ＵＥ９００が、ＬＭＡ９０２が３ＧＰＰエンティティであるか否かを検出できる複数の可能な方法がある。１例において、ＵＥ９００は、非３ＧＰＰ内のハンドオーバが、デフォルトルータの変更をきたすか否かを確認する。非３ＧＰＰネットワーク内においてデフォルトルータの変更がある場合には、ネットワークベースのモビリティが非３ＧＰＰネットワーク内で用いられる、すなわち、ＬＭＡ９０２が非３ＧＰＰエンティティである可能性が高い。他の可能性は、３ＧＰＰ ＬＭＡがプローブメッセージを修正するよう指示することができるので、モバイルノードは３ＧＰＰ ＬＭＡと（ローカル）非３ＧＰＰ ＬＭＡとを識別することができる。例えば、３ＧＰＰ ＬＭＡは、常にホップカウントを３より大きな数だけ増加させるよう、又は、プローブメッセージに対して指示を追加するよう設定されうる、―例えば、プローブメッセージのメッセージフォーマットは、ＬＭＡによって設定される（されない）場合には、ＬＭＡが３ＧＰＰエンティティであることを指示する他のフラグを含みうる。

他のオプションは、ＵＥ９００が、ローカルに割り当てられたアドレスが３ＧＰＰ事業者に属するか否かを確認することである。このアドレスが３ＧＰＰ事業者のネットワークプレフィクスの１部である場合には、ＬＭＡは３ＧＰＰエンティティである。モバイルノードは、ｈｔｔｐ：／／ｗｗｗ．ｉａｎａ．ｏｒｇ／ｎｕｍｂｅｒｓでＩＡＮＡ登録を確認することによって、３ＧＰＰ事業者のプレフィクスを求めることができる。さらに、他の可能性は、ＬＭＡのアドレスを含む中間のルータアドレスを求めるために、ＵＥ９００が自己のＩＰアドレスのための経路探索を送信する。いずれの中間のルータアドレスも３ＧＰＰ事業者のネットワークプレフィクスの１部でない場合には、関与する３ＧＰＰ ＬＭＡはない。

ＬＭＡが３ＧＰＰエンティティであるか否か、すなわち、検出されたモビリティマネジメント機能が本当にＩＰＭＳによって選択された機能であるか否かを検出するためのオプション及び可能性もまた、必要に応じて組み合わせられうる。

本明細書中で提案されたモビリティマネジメント機能検出メカニズムを用いる際に問題を引き起こしうる別の論点は、ローカルなＭＡＧ経路設定でありうる。ＰＭＩＰｖ６は、ソースと同じＭＡＧに接続されている宛先のためのパケットがＬＭＡを介した経路設定を経ないでローカルに配信されることを示す、ローカルなＭＡＧ経路設定（「ＥｎａｂｌｅＭＡＧＬｏｃａｌＲｏｕｔｉｎｇ」オプション）をサポートする。ローカルなＭＡＧ経路設定が使用可能となったので、ＰＭＩＰドメイン内においても、プローブメッセージはこうして、ＬＭＡを横断せずにＭＡＧからモバイルノードへと戻るように経路設定されるであろう。たとえ、ネットワークベースのモビリティがネットワークによって用いられるか否かを区別することをモバイルノードが許可しないネットワーク内においてＰＭＩＰサービスが用いられる場合であっても、ホップカウントの差は１となるであろう。

本発明の別の実施形態によると、ＰＭＩＰドメイン内で転送するローカルなＭＡＧによって引き起こされる潜在的な問題が克服される。この問題を回避する方法として複数の可能性が存在する。１つのオプションは、モバイルノードが、ローカル転送を、少なくともプローブメッセージに対しては、望まない旨の信号をネットワークへと送ることである。このことは、別々のシグナリングによって、又は、設定時にこのメッセージに対するローカルなＭＡＧ転送を切るフラグをプローブメッセージに含めることによって行われてもよい。他の可能性は、各ＭＡＧが、少なくともプローブメッセージへのローカル転送を適用せず、データパケットへのローカル転送のみを適用するよう構成されていることである。

ローカルなＭＡＧ経路設定に対処する他の可能性は、モバイルノードが、ＤＮＳメッセージ（ポート番号５３のＵＤＰ／ＴＣＰメッセージ）のような、所定の種類のメッセージがローカル転送の対象とならないことを知っている場合に、モバイルノードがこの種類のメッセージとともにプローブメッセージを送信することである。

別のオプションは、ＰＭＩＰ検出は主として新しいＩＰセッションを確立した直後に必要であることから、特定のモバイルノードのパケットに対するローカル転送が、それぞれのモバイルノードによって新しいＩＰセッション又はＰＤＮ接続を確立した以後に、ＭＡＧ中においてのみ有効にとされることであろう。さらに、別のオプションは、ＭＡＧが、ローカル転送も有効になるように、プローブメッセージ中のホップカウントを３ずつ増加させるよう修正され、このプローブメッセージのホップカウントの差が、ネットワークベースのモビリティマネジメントを用いないネットワーク内にてモバイルノードに返信されているプローブメッセージのホップカウントの差とは異なるようにすることであってもよい。

ローカルなＭＡＧ転送に対処する他の可能性は、モバイルノードがＭＡＧ内で有効とされたローカル転送がないことを知っている場合には、モバイルノードは、ネットワークによって用いられるモビリティマネジメント機能を検出するためにプローブメッセージを送信するのみとし、また、他の場合には、ＤＳＭＩＰブートストラップを用いるホームリンク検出といった他の効率のより低い検出手段を用いることである。ローカル転送がある特定のＭＡＧ内で有効とされているか否かは、例えば、事業者方針から、ネットワークへの前回の接続から、又は他の手段によって、モバイルノードに知らされるかもしれない。例えば、モバイルノードが、ＰＭＩＰがプローブメッセージの結果に基づいてサポートしていると想定するが、その接続がハンドオーバの後に断たれたことに気が付いた場合は、モバイルノードは、その仮定が誤っており、ネットワーク内ではＰＭＩＰが用いられていないことを知っている。次いで、モバイルノードは、このネットワーク内でローカル転送が用いられていると想定することができ、後の意思決定のためにこの情報を保存することができる。

明らかになったように、ＰＭＩＰドメイン内のモバイルアクセスゲートウェイによるパケットのローカル転送に起因する潜在的な問題に対処するためには、多数のオプションがある。当然のことながら、個々の対策は容易に互いに組み合わせることができることに留意するべきである。

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

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

さらに、本発明の異なる実施形態の個々の特徴は、個別に又は任意の組み合わせにおいて、別の発明の主題となりうることに留意するべきである。

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

Claims (15)

1. ネットワークによって用いられるＩＰモビリティマネジメント機能を検出する方法において、
   プローブメッセージを前記ネットワークへとＩＰパケットの形態で送信し、前記プローブメッセージのＩＰヘッダは、前記プローブメッセージを移動体端末のＩＰアドレスへと宛てるステップと、
   前記ネットワークから前記プローブメッセージを受信するステップと、
   前記送信されたプローブメッセージと前記受信されたプローブメッセージとの比較に基づいて、前記ネットワークが、前記モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いるか否かを検出するステップと、
   を含む方法。
2. 前記送信されたプローブメッセージと前記受信されたプローブメッセージの前記比較は、前記送信されたプローブメッセージ中と前記受信されたプローブメッセージ中の前記ＩＰヘッダのＩＰホップカウントフィールドの差を解析する請求項１に記載の方法。
3. 前記送信されたプローブメッセージと前記受信されたプローブメッセージの前記比較は、前記モバイルノードに対するネットワークベースのモビリティマネジメント機能を適用するネットワークエンティティを介して経路設定された場合に、ネットワークベースのモビリティマネジメント機能の使用の指示が前記プローブメッセージに追加されたか否かを確認することを含む請求項１又は２に記載の方法。
4. 前記モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いない前記ネットワークを検出したことに応答して、クライアントベースのモビリティマネジメントブートストラップ及びアドレス登録手順を開始するステップをさらに含む請求項１から３のいずれか１つに記載の方法。
5. 前記プローブメッセージが、前記モバイルノードが接続されている前記ネットワーク内のアクセスルータにトンネリングされる請求項１から４のいずれか１つに記載の方法。
6. 前記プローブメッセージが、前記モバイルノードが接続されている前記ネットワーク内のアクセスルータのリンク層アドレスに送信される請求項１から５のいずれか１つに記載の方法。
7. 前記ネットワークが、前記モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いるか否かの検出が、前記モバイルノードによる前記プローブメッセージの送信時と受信時との間における前記ホップカウントの差に基づいている請求項１から６のいずれか１つに記載の方法。
8. 前記モバイルノードにて、前記ホップカウントが前記プローブメッセージの送信時と受信時との間で閾値を上回って増加する場合に、前記ネットワークベースのモビリティマネジメント機能が検出され、そうでない場合に、クライアントベースのモビリティマネジメント機能が検出される請求項７に記載の方法。
9. 前記ネットワークによる前記モバイルノードの認証と、前記ネットワークによる前記モバイルノードへのアドレス割当との間の期間が、閾値時間よりも長い、
   前記ネットワークへの前回の接続により、提供される前記モビリティマネジメント機能がわかる、
   のうち１つ以上が満たされる場合にのみ、前記プローブメッセージが前記モバイルノードによって送信される請求項１から８のいずれか１つに記載の方法。
10. 接続後で、前記ネットワーク内で前記モバイルノードを認証するための前記ネットワークへの認証手順を実行するステップと、
    前記認証は、前記ネットワークへのＩＰ層の接続性を確立する前に実行されるステップと、
    をさらに含む請求項１から９のいずれか１つに記載の方法。
11. 前記モバイルノードの前記ネットワークへの初期接続の後すぐに、又は新しいＩＰセッションを確立した後すぐに、又は前記ネットワークによる新しいＩＰアドレスの割当後すぐに実行される、請求項１から１０のいずれか１つに記載の方法。
12. ネットワークによって用いられるＩＰモビリティマネジメント機能を検出するモバイルノードにおいて、
    ＩＰヘッダの付いたプローブメッセージを前記ネットワークへと送信し、前記プローブメッセージは移動体端末のＩＰアドレスに宛てられている送信機と、
    前記ネットワークから前記プローブメッセージを受信する受信機と、
    前記送信されたプローブメッセージと前記受信されたプローブメッセージとの比較に基づいて、前記ネットワークが、前記モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いるか否かを検出する処理装置と、
    を備えるモバイルノード。
13. 請求項２から１１のいずれか１つに記載のステップを実行する手段をさらに含む請求項１２に記載のモバイルノード。
14. モバイルノードの処理装置によって実行される時に、前記モバイルノードが、ネットワークによって用いられる前記モバイルノードに対するＩＰモビリティマネジメント機能を検出させる指示を保存する、コンピュータで読み取り可能な媒体において、
    ＩＰヘッダの付いたプローブメッセージを前記ネットワークへと送信し、前記プローブメッセージは移動体端末のＩＰアドレスに宛てられ、
    前記ネットワークから前記プローブメッセージを受信し、
    前記送信されたプローブメッセージと前記受信されたプローブメッセージとの比較に基づいて、前記ネットワークが、前記モバイルノードに対するネットワークベースのモビリティマネジメント機能を用いるか否かを検出する、
    媒体。
15. 前記モバイルノードの前記処理装置によって実行される時に、請求項２から１１のいずれか１つに記載のステップを前記モバイルノードに実行させる指示をさらに保存する、請求項１４に記載のコンピュータで読み取り可能な媒体。