JP2009539286A - 通信セッションのためのロケーション・プライバシーとルート最適化とを同時に実施する方法及び装置 - Google Patents

Abstract

本発明は、複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムでパケットをルーティングする方法であって、モバイル・ノードが少なくとも第１のホーム・アドレスを有し、複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して通信相手ノードと通信する方法に関する。この方法は、モバイル・ノードによって実行される下記のステップ、すなわち、通信相手ノードからアプリケーション・レイヤ要求メッセージを受信するステップと、アプリケーション・レイヤ要求メッセージの一部から通信相手ノードのアドレスを検索するステップと、通信相手ノードのアドレスを用いてモバイル・ノードと通信相手ノードとの間の直接経路の近傍の複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するステップと、第２のホーム・アドレスを入手するために第２のホーム・エージェントを用いてブート・ストラップしてするステップと、通信相手ノードへのアプリケーション・レイヤ応答メッセージの一部に第２のホーム・アドレスを挿入して通信相手ノードがモバイル・ノードとのデータ通信のために第２のホーム・アドレスを使用できるようにするステップとを含む。
【選択図】図１１

Description

本発明は、モバイル・パケット・ベースの通信ネットワークにおける最適化されたルーティングとロケーション・プライバシーとに関する。

本発明は、Ｍｏｂｉｌｅ ＩＰｖ６（インターネット・プロトコル・バージョン６）のモバイル・ノードが通信相手ノードからそのロケーションを隠し、同時にデータ・パケットの最適化されたルーティングを提供するための方法及びシステムと、通信相手ノードからそのロケーションを隠し、同時にデータ・パケットの最適化されたルーティングを提供できるモバイル・ノードと、Ｍｏｂｉｌｅ ＩＰｖ６（インターネット・プロトコル・バージョン６）のモバイル・ノードが通信相手ノードからそのロケーションを隠し、同時にデータ・パケットの最適化されたルーティングを提供するためのコンピュータ読み取り可能媒体とについて説明する。

通信システムは、インターネット・プロトコル（ＩＰ）ベースのネットワークを目指して進化を遂げる。それらの通信システムは、音声及びデータが断片（いわゆるパケット）の形で端末間で送信される多数の相互接続されたネットワークからなる。これらのパケットは、コネクションレス方式でルータによって宛先へルーティングされる。従って、パケットは、ＩＰヘッダ及びペイロード情報から構成され、ヘッダは、とりわけ送信元及び宛先ＩＰアドレスを含む。スケーラビリティの理由から、ＩＰネットワークは、階層アドレッシング方式を使用する。従って、ＩＰアドレスは、対応する端末を識別するだけでなく、この端末に関するロケーション情報も含む。ルーティング・プロトコルによって追加情報が提供され、ネットワーク内のルータは、特定の宛先へ向けて次のルータを識別することができる。

端末が、これ以降モバイル・ノード（ＭＮ）と呼ぶ移動機であって、サブネット間を移動する場合、階層アドレッシング方式のために、端末は、ＩＰアドレスをトポロジー的に正しいＩＰアドレスに変更しなければならない。しかし、ＴＣＰ接続などの上位レイヤでの接続は、通信ノードのＩＰアドレス（及びポート）で定義されるので、ノードの一方が移動などが理由でそのＩＰアドレスを変更すると接続は切断される。

Ｍｏｂｉｌｅ ＩＰｖ６［Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「ＩＰｖ６におけるモビリティサポート（Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６）」、ＩＥＴＦ ＲＦＣ３７７５、２００４年６月］は、ＭＮが上位レイヤ及びアプリケーションにトランスペアレントに、すなわち、上位レイヤの接続を切断されないような形でサブネット間を移動できるようにするＩＰベースのモビリティ・プロトコルである。従って、ＭＮは、２つのＩＰアドレス、すなわち、気付けアドレス（ＣｏＡ）とホーム・アドレス（ＨｏＡ）を構成している。ＭＮの上位レイヤは、以後通信相手ノード（ＣＮ）と呼ぶ通信相手（宛先端末）との通信にＨｏＡを使用する。このアドレスは変更されず、ＭＮの識別に役立つ。トポロジーの観点からは、このアドレスは、ＭＮのホーム・ネットワーク（ＨＮ）に属する。これに対して、ＣｏＡは移動のたびに変更され、サブネットが変更され、ルーティング・インフラストラクチャのロケータとして用いられる。トポロジーの観点からは、このアドレスは、ＭＮが現在訪れているネットワークに属する。ホーム・リンク上に位置する一組のホーム・エージェント（ＨＡ）のうちの１つがＭＮのＨｏＡへのＭＮのＣｏＡのマッピングを維持し、ＭＮへの着信トラフィックを現在位置にリダイレクトする。単一のＨＡでなく一組のＨＡを有する理由は冗長性と負荷分散である。特定のＣＮアドレスと特定のＭＮ ＨｏＡとの間のデータ通信セッションは、Ｍｏｂｉｌｅ ＩＰデータ・セッションと呼ばれる。

Ｍｏｂｉｌｅ ＩＰｖ６は、現在２つの動作モード、すなわち、双方向トンネリングとルート最適化とを定義している。双方向トンネリングを使用する場合、ＣＮがＭＮのＨｏＡに宛てて送信したデータ・パケットは、ＨＮ内のＨＡによってインターセプトされ、ＭＮのＣｏＡへトンネリングされる。ＭＮが送信したデータ・パケットは、ＨＡへ逆方向トンネリングされ、ＨＡはパケットをカプセル開放し、ＣＮへ送信する。この動作で、ＭＮのＣｏＡはＨＡだけに通知される。従って、ＭＮは、ＨＡへＢｉｎｄｉｎｇ Ｕｐｄａｔｅ（ＢＵ）メッセージを送信する。これらのメッセージは、ＩＰｓｅｃセキュリティ・アソシエーション上で送信されるので、認証され完全性が保護されている。ＣＮはＭＮのＣｏＡを認識していないので、ＭＮのロケーションを推理できず、ロケーション・プライバシーが提供される。しかし、ＭＮがホーム・ネットワークから離れ、ＣＮがＭＮに近い場合、通信パスは不必要に長く、非効率的なルーティングと長いパケット遅延が生じる（図１を参照）。

最近、Ｍｏｂｉｌｅ ＩＰｖ６が拡張され、ＭＮは、ＨＡで動的にブート・ストラップが可能になった［Ｇ．Ｇｉａｒｅｔｔａ、Ｊ．Ｋｅｍｐｆ，Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「分割シナリオにおける、Ｍｏｂｉｌｅ ＩＰｖ６ブート・ストラップ（Ｍｏｂｉｌｅ ＩＰｖ６ ｂｏｏｔｓｔｒａｐｐｉｎｇ ｉｎ ｓｐｌｉｔ ｓｃｅｎａｒｉｏ）」、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｂｏｏｔｓｔｒａｐｐｉｎｇ−ｓｐｌｉｔ−０２．ｔｘｔ、２００６年３月］。ブート・ストラップは、ＨＡを発見するステップと、対応するＨｏＡを構成するステップと、このＨＡとのＩＰｓｅｃセキュリティ・アソシエーションを設定するステップとを含む。モバイル・ノードの手動の構成は実際的でもスケーラブルでもないため、Ｍｏｂｉｌｅ ＩＰｖ６は、特に大規模な実施ではブート・ストラップ拡張を実施されると想定することができる。ブート・ストラップ拡張によって、ＭＮはローカルＨＡを用いてブート・ストラップして双方向トンネリング・モードでのルート最適化を実行することができる。しかし、ＨｏＡ（普通、ＣＮで知られる）は、ロケーション情報を含むため、このことはロケーション・プライバシー・サポートを無効にするおそれがある。例えば、ＨＡがＭＮに対してローカルである（例えば、ローカルＨＡを用いてブート・ストラップすることがオペレータのポリシーである）とＣＮが認識している場合、ＣＮはＭＮのＨｏＡに基づいてＭＮのロケーションを推定できる。さらに、ブート・ストラップによってＨＡを変更する場合、ＨｏＡを変更する必要がある。これは、実行中のデータ・セッションの中断を意味する。従って、実行中のデータ・セッションのルート最適化はサポートされない。

ロケーション・プライバシーのさまざまな態様を区別することができることに留意されたい。本発明が目的とする１つの態様は、ＭＮのロケーションをＣＮから隠すことである。別の態様は、ロケーションを盗聴者から隠す、又はＭＮのロケーションの追跡を防止することである。

ルート最適化モードは、ＣＮとＭＮとの間の直接経路を用いて双方向トンネリング・モードの非効率性を防止することができる（図１を参照）。従って、ＭＮはＣＮへＢＵメッセージを送信し、次に、ＣＮはＭＮへ直接データ・パケットを送信することができる（直接経路上でのパケットの送信にはタイプ２ルーティング・ヘッダが用いられる）。ＣＮは、当然、Ｍｏｂｉｌｅ ＩＰｖ６ルート最適化サポートを実施しなければならない。ＢＵメッセージの認証のため、ＭＮ及びＣＮは、いわゆるリターン・ルータビリティ手順を実行する。この手順は、ＨｏＡ及びＣｏＡへのＭＮの到達可能性を試験し、共有セッション鍵（以下を参照）を生成する。しかし、ＣＮは、ＢＵメッセージによってＭＮのＣｏＡを知るのでそのロケーションを推理できる。すなわち、ロケーション・プライバシーは提供されない。

以下に、ルート最適化又はロケーション・プライバシーをある程度提供できる従来技術の文献について論じ、これらの解決策の欠点を示す。

ＨＭＩＰ［Ｈｅｓｈａｍ Ｓｏｌｉｍａｎ，Ｃｌａｕｄｅ Ｃａｔｅｌｌｕｃｃｉａ，Ｋａｒｉｍ Ｅｌ Ｍａｌｋｉ，Ｌｕｄｏｖｉｃ Ｂｅｌｌｉｅｒ，「階層型Ｍｏｂｉｌｅ ＩＰｖ６のモビリティ管理（ＨＭＩＰｖ６）（Ｈｉｅｒａｒｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ（ＨＭＩＰｖ６））」、ＩＥＴＦ ＲＦＣ４１４０，２００５年８月］は、（潜在的に離れた）ＨＡにＢＵメッセージを送信することに起因する待ち時間と信号オーバヘッドを低減するために開発された。モビリティを部分的にローカルに扱うことが提案されている。従って、訪問先ネットワーク内にモビリティ・アンカーポイント（ＭＡＰ）の階層構造が導入される。ＭＮは、ローカルＭＡＰにＣｏＡを登録するだけでよい。追加のＣｏＡ、いわゆるリージョナルＣｏＡ（ＲＣｏＡ）がＭＡＰのサブネットから入手され、ＭＡＰは、これを用いてＭＡＰの領域内のＭＮのモビリティをＨＡ（又はルート最適化の場合は、ＣＮ）から隠す。さらに、ＭＮは、ＣｏＡとしてＲＣｏＡを用いてルート最適化モードを開始することができる。従って、ある程度のルート最適化とロケーション・プライバシーの同時サポートが提供できるが、ＣＮはＲＣｏＡ、すなわちＭＮが現在位置するＭＡＰ領域を依然として認識しているので、ロケーション・プライバシーのサポートが極めて限定的である。

ＡＲＥＣ［ＷＯ２００４０５５９９３号；Ｇ．Ｋｒｉｓｈｎａｍｕｒｔｈｉ，Ｈ．Ｃｈａｓｋａｒ，Ｒ．Ｓｉｒｅｎ，「ＩＰベースの移動体通信におけるエンド・ツー・エンドのロケーション・プライバシーの提供（Ｐｒｏｖｉｄｉｎｇ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｌｏｃａｔｉｏｎ Ｐｒｉｖａｃｙ ｉｎ ＩＰ−ｂａｓｅｄ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）」、ＩＥＥＥ ＷＣＮＣ，２００４年３月］は、各々の訪問先ネットワークの各アクセス・ルータ（ＡＲ）の変更を必要とする。ＨＡからＣＮとＭＮのそれぞれのＡＲにバインディング情報が送信され、ＨＡが関与せずにＭＮ及びＣＮのＡＲ間でデータ・パケットがトンネリングされる。こうして、ＭＮとＣＮ間の直接の、すなわち、最短のルートが使用され、ロケーション・プライバシーがサポートされる。ＷＯ２００４０１０６６８号に、非常に類似している手法が記載されている。しかし、ＨＡからＡＲへのバインディング情報の配布のためにセキュリティの問題が発生し、ＨＡからＡＲへのバインディング情報の配布は新しい複雑なプロトコルを必要とし、このプロトコルを利用するには標準化とユニバーサルな展開が必要であろう。

ＯＲＣ［Ｒｙｕｊｉ Ｗａｋｉｋａｗａ，「最適化ルートキャッシュプロトコル（ＯＲＣ）（Ｏｐｔｉｍｉｚｅｄ Ｒｏｕｔｅ Ｃａｃｈｅ Ｐｒｏｔｏｃｏｌ（ＯＲＣ））」、インターネット草稿ｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ，２００４年１０月］は、移動体ネットワーク（ＮＥＭＯ）内のルート最適化のために開発され、バインディング情報の提供を含む訪問先ネットワークのエッジ・ルータの変更を必要とする。ＭＮは、ＣＮの現在のネットワーク（ＣＮが移動機であると仮定して）のエッジ・ルータへデータ・パケットをトンネリングし、ＣＮは、ＭＮの現在の訪問先ネットワークのエッジ・ルータへデータ・パケットをトンネリングすることができる。パケットをエッジ・ルータへトンネリングするために、各ノードは、通信相手エッジ・ルータのＩＰアドレスを認識している必要がある。セキュリティの問題が起こり、使用するのにユニバーサルな実施を必要とする新しいプロトコルを標準化しなければならない。さらに、変更されたエッジ・ルータがＣＮのネットワーク内に配備され、ルータがＭＮとＣＮ間の直接経路上にある場合にのみ、ロケーション・プライバシーとルート最適化が同時にサポートされる。

ＧｌｏｂａｌＨＡＨＡ［Ｐ．Ｔｈｕｂｅｒｔ，Ｒ．Ｗａｋｉｋａｗａ，Ｖ．Ｄｅｖａｒａｐａｌｌｉ，「グローバルＨＡ−ＨＡプロトコル（Ｇｌｏｂａｌ ＨＡ ｔｏ ＨＡ ｐｒｏｔｏｃｏｌ）」、ＩＥＴＦインターネット草稿ｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００，２００４年１０月］によって、複数のＨＡに様々なトポロジー上のロケーションからホーム・ネットワーク・プレフィックスへのルートを公示させることで普通ホーム・リンクに宛てたインターネット内のＨＡの分散を可能にする。ＭＮは、プロキシＨＡの役割を果たす最も近いＨＡにバインドすることができ、最適ルートが得られる。双方向トンネリングが使用されれば、ロケーション・プライバシーが提供される。従って、ルート最適化とロケーション・プライバシーとが同時に提供される。しかし、すべての訪問先ネットワークが他のすべてのネットワーク（すべて幾つかのＭＮのホーム・ネットワーク）にルートを公示すれば、もはやアドレス階層構造は基本的に得られないため、ルーティング・スケーラビリティの問題が発生する場合がある。さらに、分散ホーム・ネットワークは、手動でそのように構成しなければならない。安全なオンデマンド構成はサポートされず、利用するには標準化とユニバーサルな展開が必要な新しい複雑なプロトコルが必要であろう。

ＷＯ０３０４１３５８号では、いわゆるロケーション・プライバシー・エージェント（ＬＰＡ）及びロケーション・プライバシー・サーバ（ＬＰＳ）があらゆるネットワークに導入される。ＭＮは、そのＬＰＡへロケーション・プライバシー要求メッセージを送信する。次に、ＬＰＡは、ＣＮに近いＬＰＡを選択する。次に、このＬＰＡのアドレスがＭＮに与えられ、次に、このＬＰＡへＢＵメッセージを送信する。従って、この手法は、ＯＲＣの手法と似ている。ＬＰＡはＣＮのネットワークに近いため、ある程度ＣＮのロケーションを認識し、ＣＮが移動機の場合にロケーション・プライバシー・サポートが無効になる。さらに、この解決策は新しい信号プロトコルを必要とし、新しいエンティティを導入する。

ＵＳ２００５０４１６７５号及びＷＯ２００４０４３０１０号では、ロケーション・プライバシーが暗号化で変更されたＩＰアドレスのプレフィックスによって達成される。プレフィックスは、普通、ルータがＩＰパケットのルーティングに使用するため、この手法は、インターネット内の全ルータの変更が必要である。これは現実的な選択肢ではないか、又は極めて限られたロケーション・プライバシーしか提供することができない。

ＷＯ０３０４４６２６号では、ＣｏＡとしてマルチキャスト・アドレスが使用される。マルチキャスト・アドレスはロケーション情報を含まないため、ルート最適化モードでもロケーション・プライバシーは提供される。しかし、この解決策ではＭＮの数のスケーリングはできない。これは、大規模な展開の結果、インターネット内でフラット・ルーティングとなるからである。

ＵＳ２００４０２３６９３７号で提案されたような機構は、盗聴者からＭＮの識別、及び従って、また、ロケーションを隠す処理しか行わない。ＣＮからＭＮのロケーションを隠すことはできないため、所与の問題を解決できない。

Ｊ．Ｚｈａｎｇ及びＤ．Ｐｅａｒｃｅ（「Ｍｏｂｉｌｅ ＩＰｖ４ルート最適化のためのエージェント・ベースのリターン・ルータビリティ（Ａｇｅｎｔ−Ｂａｓｅｄ Ｒｅｔｕｒｎ Ｒｏｕｔａｂｉｌｉｔｙ Ｔｅｓｔ ｆｏｒ Ｍｏｂｉｌｅ ＩＰｖ４ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ）」、ＩＥＴＦインターネット草稿ｄｒａｆｔ−ｚｈａｎｇ−ｍｏｂｏｐｔｓ−ａｇｅｎｔ−ｍｉｐ４ｒｒ−００．ｔｘｔ、２００５年８月）では、ＭＩＰｖ４ルート最適化のためのＭＩＰｖ６ルート最適化方式を採用することを提案している。リターン・ルータビリティに関してＣＮのプロキシとなる通信相手エージェント（ＣＡ）が導入される。こうしてＣＮの実施態様を変更する必要はなく、ＭＮとＣＡとの間でデータ・パケットを直接トンネリングすることができる。ＣＡの副作用は、ＭＮのロケーションがＣＮから隠されることである。この手法は、ＯＲＣに似ている。従って、セキュリティの問題が発生し、新しいプロトコルを標準化しなければならず、ＣＡを導入する必要がある。さらに、ＣＡがＣＮのネットワーク内に配備されこのＣＡがＭＮとＣＮ間の直接経路上にある場合にのみ、ロケーション・プライバシーとルート最適化が同時にサポートされる。

最後に、Ｃ．Ｃａｓｔｅｌｌｕｃｃｉａ，Ｆ．Ｄｕｐｏｎｔ及びＧ．Ｍｏｎｔｅｎｅｇｒｏ（「Ｍｏｂｉｌｅ ＩＰｖ６用の簡単なプライバシー拡張（Ａ ｓｉｍｐｌｅ Ｐｒｉｖａｃｙ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ Ｍｏｂｉｌｅ ＩＰｖ６）」、ｄｒａｆｔ−ｄｕｐｏｎｔ−ｍｉｐ６−ｐｒｉｖａｃｙｅｘｔ−０２．ｔｘｔ、２００５年７月）は、ＨｏＡを暫定モバイル識別（ＴＭＩ）で置き換えることを提案する。ＭＮがセッションを開始した場合、ＨｏＡをＣＮから隠すことができ、ＴＭＩだけを明らかにすることができる。ＣＮはＭＮのＣｏＡを認識するが、ＣＮはＣｏＡに対応する実際の識別を知らないためＭＮのロケーションを明らかにすることはない。しかし、ＣＮがＭＮとの通信を開始することができるためには、ＣＮはＭＮのＨｏＡを認識しなければならず、従ってそのようなシナリオでは、ロケーション・プライバシーは提供されない（上位レイヤのセッションを生かすためＨｏＡを変更することはできないことに留意されたい）。

多くの場合、通信セッションを確立するには、アプリケーション・レイヤでの信号方式が必要である。このために使用される（例えば、ＶｏＩＰアプリケーションによって）普及しているプロトコルは、セッション開始プロトコル（ＳＩＰ）（Ｊ．Ｒｏｓｅｎｂｅｒｇ他、ＳＩＰ：セッション開始プロトコル、ＲＦＣ３２６１、２００２年６月）である。ＭＮとＣＮ間のＳＩＰを用いたセッション確立信号方式の一例を図１０に示す。この例は、図を見やすくするために簡単化したシグナリング・フローを示している。例えば、ＩＭＳ（ＩＰマルチメディア・サブシステム）を使用する場合、リソースの確保及び課金の理由などから送信するシグナリング・メッセージの数は増える。

ＳＩＰは、新しいインフラストラクチャ・エンティティを定義する。各ＳＩＰノードは、登録先であって、普通、ＳＩＰシグナリング・メッセージを送受信する相手先であるＳＩＰレジスタ又はプロキシ・サーバを割り当てている。ＣＮとのセッションを確立するために、ＭＮはプロキシ・サーバに招待メッセージを送信する。招待メッセージは、メディア・タイプ、トランスポート・プロトコル、セッションのアドレス及びポートなどのセッションの記述を含む。招待メッセージは、さらに、通信相手ノードのＳＩＰ統一資源識別子（ＵＲＩ）を含まなければならない。ＳＩＰ ＵＲＩは、例えば、「Ｂｏｂ＠ｄｏｍａｉｎ．ｃｏｍ」である。記述は、普通、セッション記述プロトコル（ＳＤＰ）によって掲載される。［Ｍ．Ｈａｎｄｌｅｙ他、ＳＤＰ：セッション記述プロトコル（ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＲＦＣ４５６６、２００６年７月］。ＳＩＰ内のＳＤＰは、オファー−応答モデルに従う。すなわち、一方のノードがメディア・タイプ、コーデックなどを提案し、他方のノードがこのオファーを受け入れるか、又は拒絶する。ＳＤＰオファー及び応答は、さまざまなＳＩＰメッセージに追加できる。ＭＮのプロキシ・サーバは、ＳＩＰ ＵＲＩ及びＤＮＳを用いてＣＮのプロキシ・サーバを発見し、このプロキシに招待メッセージを送信する。ＣＮのプロキシは、ＣＮから送信された以前の登録メッセージからＣＮのアドレスを認識し、招待メッセージをＣＮへ転送する。このメッセージを受信するとユーザへの着信音などによる通知がトリガされる。同時に、ＣＮは通知をＭＮへ返送し、ＭＮはプロキシ・サーバ上で逆の経路をルーティングされる。ユーザが呼に応答すると、ＣＮはＯＫメッセージをＭＮへ返送する。ＣＮアドレスを含むＳＤＰ応答は、リンギング又はＯＫ招待メッセージなどの応答メッセージのいずれにも追加できる。さらに、ＳＩＰヘッダ内のコンタクト・フィールドは、送信元エンドポイントのアドレスを含むことができる。いずれにせよ、ＯＫ招待メッセージが受信されると、エンドポイントのアドレスは認識され、プロキシを経ずにＭＮはＣＮへデータの送信を開始することができ、又はその逆も可能である。

Ｍｏｂｉｌｅ ＩＰとＳＩＰなどのアプリケーション・レイヤ信号方式の効率的な相互動作は独自の問題である。いくつかの解決策が提案されており、以下にそれを説明する。

ＷＯ２００５０４６１３２号及びＥＰ１６８０８９４号では、Ｍｏｂｉｌｅ ＩＰ（ＭＩＰ）とＳＩＰの両方をサポートするシステムの最適化が提案されている。基本的なアイデアは、ＭＮがＳＩＰサーバにＨｏＡを登録し、ＭＮがＳＩＰヘッダのコンタクト・フィールドにＨｏＡを挿入することでＨｏＡをＣＮに通知するというものである。その結果、ＳＩＰセッションに対応するデータはＭＮのＨｏＡへルーティングされ、ＭＮが移動していてもＭＮへ送達できる。さらに、ＭＮのネットワーク・レイヤ・ハンドオーバでＳＩＰ信号方式は不要である。

ＵＳ２００４０１６５５９４号は、Ｍｏｂｉｌｅ ＩＰルート最適化を使用する時のＭｏｂｉｌｅ ＩＰとＳＩＰ間の相互動作の最適化方法を記述する。このアイデアは、ＳＩＰシグナリング・フローにおいてすでに、より詳細には、ＭＮが受信したＳＩＰメッセージからＣＮのアドレスを認識した時点で、Ｍｏｂｉｌｅ ＩＰルート最適化をトリガする方法である。アプリケーション・レイヤからネットワーク・レイヤへのレイヤ間トリガによって、ＳＩＰとＭＩＰのルート最適化信号方式は少なくとも部分的に同時に実行され、最初のデータ・パケットについて最適化ルートがデータ・セッションの開始時点ですでに利用可能である。しかし、Ｍｏｂｉｌｅ ＩＰルート最適化を使用するため、この方法でロケーション・プライバシーは提供することができない。ＥＰ１６０５６６２は、ＭＩＰ−ＳＩＰ相互動作シナリオにおけるルート最適化方法を提案する。従って、ＭＮは、ＳＩＰサーバでのハンドオーバ後にＨｏＡとＣｏＡの両方を登録する。さらに、ＣＮは、両方のアドレスを通知される。これによって、ルート最適化のためのＣＮとＦＡ（フォーリン・エージェント）の間及びＳＩＰサーバとＦＡの間、又はＭＮとＳＩＰサーバの間及びＭＮとＣＮの間のトンネルの設定が可能になる。しかし、この手法はロケーション・プライバシーを提供できず、ＦＡ及びＳＩＰサーバを変更する必要がある。

ＧＢ２４１２５４３号もＭＩＰ及びＳＩＰの相互動作を考慮する。ここで、ＭＩＰ又はＦＭＩＰがハンドオーバを検出した後にＭＮがトリガされてＳＩＰサーバに新しいアドレスを登録することが提案される。

ＷＯ２００１０７２００７号は、ＣＮから送信されたＭＮ宛のＳＩＰ招待メッセージがＳＩＰサーバで受信されると、ＭＮがネットワークによりページングされることを提案する。次に、ＭＮがＩＰアドレスを割り当てられ、最後に、ＳＩＰ招待メッセージはＭＮへ送達されてＣＮとのセッションが確立される。従って、ＭＮのロケーションについてネットワークが維持しなければならない状態は、ＭＮがアクティブな通信セッションを有さない限り、大幅に低減される。

ＶｏＩＰなどの対話型アプリケーションは短いパケット遅延しか要求しないので、ロケーション・プライバシーとルート最適化の両方を提供する機構は確かに望ましい。この機構では、Ｍｏｂｉｌｅ ＩＰｖ６メッセージ・フォーマット及びＭｏｂｉｌｅ ＩＰｖ６エンティティの実施態様へのわずかな変更しか必要ではない。さらに、ＭＮが通信セッションを開始し、ＣＮがセッションを開始するシナリオをサポートすればよい。
ＷＯ２００４０５５９９３号 ＷＯ０３０４１３５８号 ＵＳ２００５０４１６７５号 ＷＯ２００４０４３０１０号 ＷＯ０３０４４６２６号 ＵＳ２００４０２３６９３７号 ＷＯ２００５０４６１３２号 ＥＰ１６８０８９４号 ＵＳ２００４０１６５５９４号 ＧＢ２４１２５４３号 ＷＯ２００１０７２００７号 Ｍｏｂｉｌｅ ＩＰｖ６［Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、「Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６」、ＩＥＴＦ ＲＦＣ３７７５、２００４年６月］ Ｇ．Ｇｉａｒｅｔｔａ、Ｊ．Ｋｅｍｐｆ，Ｖ．Ｄｅｖａｒａｐａｌｌｉ、「Ｍｏｂｉｌｅ ＩＰｖ６ ｂｏｏｔｓｔｒａｐｐｉｎｇ ｉｎ ｓｐｌｉｔ ｓｃｅｎａｒｉｏ」、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｂｏｏｔｓｔｒａｐｐｉｎｇ−ｓｐｌｉｔ−０２．ｔｘｔ、２００６年３月 ＨＭＩＰ［Ｈｅｓｈａｍ Ｓｏｌｉｍａｎ，Ｃｌａｕｄｅ Ｃａｔｅｌｌｕｃｃｉａ，Ｋａｒｉｍ Ｅｌ Ｍａｌｋｉ，Ｌｕｄｏｖｉｃ Ｂｅｌｌｉｅｒ，「Ｈｉｅｒａｒｃｈｉｃａｌ Ｍｏｂｉｌｅ ＩＰｖ６ ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ（ＨＭＩＰｖ６）」、ＩＥＴＦ ＲＦＣ４１４０，２００５年８月］ Ｇ．Ｋｒｉｓｈｎａｍｕｒｔｈｉ，Ｈ．Ｃｈａｓｋａｒ，Ｒ．Ｓｉｒｅｎ，「Ｐｒｏｖｉｄｉｎｇ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｌｏｃａｔｉｏｎ Ｐｒｉｖａｃｙ ｉｎ ＩＰ−ｂａｓｅｄ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ」、ＩＥＥＥ ＷＣＮＣ，２００４年３月 ＯＲＣ［Ｒｙｕｊｉ Ｗａｋｉｋａｗａ，「Ｏｐｔｉｍｉｚｅｄ Ｒｏｕｔｅ Ｃａｃｈｅ Ｐｒｏｔｏｃｏｌ（ＯＲＣ）」、インターネット草稿ｄｒａｆｔ−ｗａｋｉｋａｗａ−ｎｅｍｏ−ｏｒｃ−０１．ｔｘｔ，２００４年１０月］ ＧｌｏｂａｌＨＡＨＡ［Ｐ．Ｔｈｕｂｅｒｔ，Ｒ．Ｗａｋｉｋａｗａ，Ｖ．Ｄｅｖａｒａｐａｌｌｉ，「Ｇｌｏｂａｌ ＨＡ ｔｏ ＨＡ ｐｒｏｔｏｃｏｌ」、ＩＥＴＦインターネット草稿ｄｒａｆｔ−ｔｈｕｂｅｒｔ−ｎｅｍｏ−ｇｌｏｂａｌ−ｈａｈａ−００，２００４年１０月］ Ｊ．Ｚｈａｎｇ及びＤ．Ｐｅａｒｃｅ（「Ａｇｅｎｔ−Ｂａｓｅｄ Ｒｅｔｕｒｎ Ｒｏｕｔａｂｉｌｉｔｙ Ｔｅｓｔ ｆｏｒ Ｍｏｂｉｌｅ ＩＰｖ４ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ」、ＩＥＴＦインターネット草稿ｄｒａｆｔ−ｚｈａｎｇ−ｍｏｂｏｐｔｓ−ａｇｅｎｔ−ｍｉｐ４ｒｒ−００．ｔｘｔ、２００５年８月） Ｍ．Ｈａｎｄｌｅｙ他、ＳＤＰ：Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ、ＲＦＣ４５６６、２００６年７月 Ｋ．Ｃｈｏｗｄｈｕｒｙ，「Ｎｅｔｗｏｒｋ Ｂａｓｅｄ Ｌａｙｅｒ ３ Ｃｏｎｎｅｃｔｉｖｉｔｙ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ ＩＰｖ４」、ｄｒａｆｔ−ｃｈｏｗｄｈｕｒｙ−ｎｅｔｍｉｐ４−００．ｔｘｔ、２００６年２月 Ｋ．Ｃｈｏｗｄｈｕｒｙ，Ａ．Ｓｉｎｇｈ、「Ｎｅｔｗｏｒｋ Ｂａｓｅｄ Ｌａｙｅｒ ３ Ｃｏｎｎｅｃｔｉｖｉｔｙ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ ＩＰｖ６」、ｄｒａｆｔ−ｃｈｏｗｄｈｕｒｙ−ｎｅｔｍｉｐ６−００．ｔｘｔ、２００６年２月 Ｊ．Ｗｏｏｄ，Ｋ．Ｎｉｓｈｉｄａ，「Ｅｄｇｅ Ｍｏｂｉｌｉｔｙ Ｐｒｏｔｏｃｏｌ（ＥＭＰ）」、ｄｒａｆｔ−ｗｏｏｄ−ｎｅｔｌｍｍ−ｅｍｐ−ｂａｓｅ−００．ｔｘｔ、２００５年１０月

解決すべき主要な問題は、ＭＮのロケーションをＣＮから隠し、同時にデータ・パケットの最適なルーティングを提供することである。これは、ＭＮとＣＮとによって開始された通信セッションで可能になり、Ｍｏｂｉｌｅ ＩＰｖ６への最小限の変更しか要しない。さらに、ロケーション・プライバシー・サポートには制限がない。すなわち、通信相手ノードは、モバイル・ノードが現在位置するリンクも、ネットワークも、ドメインも推測できない。無線上及びネットワーク内のプロトコル及びトンネリングのオーバヘッドは潜在的に大きく、ＳＩＰベースのサービスをサポートする効率的な方法を見つけなければならない。

本発明は、上記の状況を考慮して構築された。本発明の目的は、ＳＩＰなどのアプリケーション・レイヤ信号方式を用いて通信セッションが確立されるシナリオを考慮しながら、モバイル・ノードのロケーションを通信相手ノードから隠し、同時にこの通信相手ノードへのデータ・パケットの最適なルーティングを提供することである。

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

この目的を達成するため、本発明は、複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムにおける方法、装置、システム及びコンピュータ読み取り可能媒体を提供し、上記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、上記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して上記通信相手ノードと通信し、上記方法は、上記モバイル・ノードによって実行される下記のステップ、すなわち、上記通信相手ノードからアプリケーション・レイヤ要求メッセージを受信するステップと、上記アプリケーション・レイヤ要求メッセージの一部から上記通信相手ノードのアドレスを検索するステップと、上記通信相手ノードのアドレスを用いて上記モバイル・ノードと上記通信相手ノードとの間の直接経路の近傍の上記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するステップと、第２のホーム・アドレスを入手するために上記第２のホーム・エージェントを用いてブート・ストラップするステップと、上記通信相手ノードへのアプリケーション・レイヤ応答メッセージの一部に上記第２のホーム・アドレスを挿入して上記通信相手ノードが上記モバイル・ノードとのデータ通信のために上記第２のホーム・アドレスを使用することができるようにするステップとを含む。

有利な実施の形態では、上記アプリケーション・レイヤ要求メッセージは、セッション開始プロトコル招待である。

別の実施の形態では、特定ステップは、上記アプリケーション・レイヤ要求メッセージのセッション記述プロトコル部又はコンタクト・フィールド内の上記通信相手ノードのアドレスを検索するステップを含む。

別の好ましい実施の形態では、アプリケーション・レイヤ応答メッセージの一部に上記第２のホーム・アドレスを挿入するステップは、上記アプリケーション・レイヤ応答メッセージのセッション記述プロトコル部又はコンタクト・フィールド内に上記第２のホーム・アドレスを挿入するステップを含む。

さらに別の好ましい実施の形態では、上記アプリケーション・レイヤ応答メッセージは、セッション開始プロトコル２００ｏｋ応答である。

別の好ましい実施の形態では、複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムでパケットをルーティングする方法、装置、システム及びコンピュータ読み取り可能媒体が提供され、上記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、上記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して上記通信相手ノードと通信し、上記方法は、上記モバイル・ノードによって実行される下記のステップ、すなわち、第１のアプリケーション・レイヤ要求メッセージを上記通信相手ノードへ送信するステップと、上記通信相手ノードからアプリケーション・レイヤ応答メッセージを受信するステップと、上記アプリケーション・レイヤ応答メッセージの一部から上記通信相手ノードのアドレスを検索するステップと、上記通信相手ノードのアドレスを用いて上記モバイル・ノードと上記通信相手ノードとの間の直接経路の近傍の上記複数のホーム・エージェントのうちの第２のホーム・エージェントを検出するステップと、第２のホーム・アドレスを入手するために上記第２のホーム・エージェントを用いてブート・ストラップするステップと、上記モバイル・ノードとのデータ通信のために上記第２のホーム・アドレスを使用するように上記通信相手ノードに通知するステップとを含む。

別の好ましい実施の形態では、上記アプリケーション・レイヤ応答メッセージは、セッション開始プロトコル１８０リンギング応答である。

本発明の別の態様では、上記通信相手ノードに通知するステップは、セッション開始プロトコル再招待メッセージ又はセッション開始プロトコル更新メッセージを送信するステップを含む。

添付の図面に示す本発明の種々の実施の形態の以下の詳細な説明を読むことで他の特徴及び利点が明らかになろう。

以下の各節で、ＭＮ開始及びＣＮ開始セッションのそれぞれについて記載した所与の問題を解決する手順を含む本発明の種々の実施の形態について説明する。

例示的な目的でのみ、大半の実施の形態は、Ｍｏｂｉｌｅ ＩＰｖ６通信システムに関連して説明している。以下の項で使用する用語は、主としてＭｏｂｉｌｅ ＩＰｖ６の用語に関連する。しかし、使用した用語とＭｏｂｉｌｅ ＩＰｖ６のアーキテクチャに関連する実施の形態の説明は、本発明の原理とアイデアとをそのようなシステムに限定するものではない。

また、上記背景技術の項目に示した詳細な説明は、以下に記述するほとんどがＭｏｂｉｌｅ ＩＰｖ６に固有の例示的な実施の形態を単によりよく理解するためだけのものであって、本発明をＭｏｂｉｌｅ ＩＰｖ６ネットワークにおけるプロセッサ及び機能の記述された特定の実施態様に限定するものと理解すべきではない。

本発明が従うロケーション・プライバシーの基本手法は、ＭＮのＣｏＡをＣＮから隠すことである。本発明の第１の主要なアイデアは、ＭＮとＣＮとの間の直接経路の近傍に位置するＨＡを発見してこのＨＡを用いてブート・ストラップし、対応するＣＮとの通信時に双方向トンネリング・モードでこのＨＡを用いて最適化されたルーティングを提供することである。ＭＮ開始シナリオでは、この手法で同時のロケーション・プライバシーと最適化されたルーティングの問題が解決済みである。

より困難なＣＮ開始シナリオでは、将来ＣＮがＭＮにデータの送信を開始するということと、どのＣＮがそうするかを、ＭＮは一般に事前に認識していないため、これでは十分でない。このシナリオで上記問題を解決するための主要なアイデアは、第１のＨＡへの登録を永続させ、対応するＨｏＡを開示してアクセス可能にし、ＣＮからパケットを受信可能にし、新しい通信セッションの第１のパケットを受信したら、第２のＨＡを用いてブート・ストラップして以下のように第２のＨｏＡを入手して最適化されたルーティングを達成するという方法である。第１のＨＡから第２のＨＡへＭｏｂｉｌｅ ＩＰデータ・セッションを移動させるために、ＭＮは第２のＨＡへの双方向トンネルを介してルート最適化モードを実行し、ルート最適化モードでＣｏＡが第２のＨｏＡに設定される。双方向トンネリング上でルート最適化モードを使用し、ＨｏＡ（第２のＨＡに対応する）をＣＮへのＣｏＴ／ＣｏＴｉ／ＢＵ（Ｃａｒｅ−ｏｆ Ｔｅｓｔ／Ｃａｒｅ−ｏｆ Ｔｅｓｔ ｉｎｉｔ／Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ）メッセージ内のＣｏＡとして使用することは本発明の第２の主要なアイデアと考えられる。

このアイデアは、ＨＡ負荷分散、ブート・ストラップの最適化及びマルチホーミングシナリオなどのロケーション・プライバシー以外の目的にも使用することができる。

ＭＮ開始通信セッション
ＣＮにＣｏＡを露呈することを防止し、ロケーション・プライバシーを提供するために、ＭＮはＣＮとの通信に双方向トンネリング・モードを使用する。ＭＮがＣＮとの通信を開始すると、複数のＨＡとＨｏＡとが利用可能であれば、ＣＮとの通信のためのＨＡ及び対応するＨｏＡを自由に選択できる。最適化されたルーティングを提供するというアイデアは、ＭＮとＣＮとの間の直接経路の近傍にあるＨＡを発見して、そのＨＡを用いてブート・ストラップし、ＣＮとの通信のために双方向トンネリング・モードでこのＨＡを用いるということである。

ＭＮに近いＨＡは、ＨｏＡにロケーション情報を追加し、従って、ロケーション・プライバシーを無効にする場合があるので、新しいＨＡはＣＮに近いほうがよい。ＣＮに近いＨＡの別の利点は、ＭＮのモビリティが重い場合であっても短いルートを提供するということである。そのようなＨＡは、まず、特定のＣＮの最適化されたルーティングに使用されるので、これを「ルート最適化」（ＲＯ）−ＨＡと呼ぶ。

ブート・ストラップは、上に概説したＧ．Ｇｉａｒｅｔｔａ、Ｊ．Ｋｅｍｐｆ，Ｖ．Ｄｅｖａｒａｐａｌｌｉ（「分割シナリオにおける、Ｍｏｂｉｌｅ ＩＰｖ６ブート・ストラップ（Ｍｏｂｉｌｅ ＩＰｖ６ ｂｏｏｔｓｔｒａｐｐｉｎｇ ｉｎ ｓｐｌｉｔ ｓｃｅｎａｒｉｏ）」、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｂｏｏｔｓｔｒａｐｐｉｎｇ−ｓｐｌｉｔ−０２．ｔｘｔ、２００６年３月）に記載されているように実行される。ＭＮは、１つ又は複数のＨＡに登録した後にＲＯ−ＨＡを用いてブート・ストラップできる。

ＲＯ−ＨＡを発見する１つの方法は、Ｇ．Ｇｉａｒｅｔｔａ、Ｊ．Ｋｅｍｐｆ，Ｖ．Ｄｅｖａｒａｐａｌｌｉ（「分割シナリオにおける、Ｍｏｂｉｌｅ ＩＰｖ６ブート・ストラップ（Ｍｏｂｉｌｅ ＩＰｖ６ ｂｏｏｔｓｔｒａｐｐｉｎｇ ｉｎ ｓｐｌｉｔ ｓｃｅｎａｒｉｏ）」、ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐ６−ｂｏｏｔｓｔｒａｐｐｉｎｇ−ｓｐｌｉｔ−０２．ｔｘｔ、２００６年３月）に記載されているロケーション依存ＨＡディスカバリを使用することである。例えば、ＣＮのホスト名が「ｃｎ．ｅｕ．ｐａｎａｓｏｎｉｃ．ｃｏｍ」の場合、ＭＮは、ＤＮＳに「ｈａ．ｅｕ．ｐａｎａｓｏｎｉｃ．ｃｏｍ」又は「＿ｍｉｐ６．ｉｐｖ６．ｅｕ． ｐａｎａｓｏｎｉｃ．ｃｏｍ」を照会してＲＯ−ＨＡアドレス、この場合には、ＣＮと同じドメイン内のＨＡのアドレスを入手することができる。

ＲＯ−ＨＡアドレスを発見する第２の方法は、ＲＣ３７７５に規定する「動的ホーム・エージェント・アドレス・ディスカバリ（ＤＨＡＡＤ）（Ｄｙｎａｍｉｃ Ｈｏｍｅ Ａｇｅｎｔ Ａｄｄｒｅｓｓ Ｄｉｓｃｏｖｅｒｙ （ＤＨＡＡＤ））」などのエニーキャスト・ベースのＨＡディスカバリを使用することである。ＭＮは、ＣＮのアドレス・プレフィックスに基づいて構築するエニーキャスト・アドレスに要求を送信し、ＣＮのネットワーク内のＨＡがこの要求に応答する。

第３の方法は、ＣＮアドレスをこのＣＮの近くにある（すなわち、同じ又は近くのドメイン又はサブネット内の）ＨＡの１つ又は複数のアドレスにマッピングすることができるか、又は一組のＭＮとＣＮアドレスを最適化されたルートを提供する（すなわち、ＭＮとＣＮとの間の直接経路上又はその近くのドメイン又はサブネット内の）ＨＡの１つ又は複数のアドレスにマッピングすることができる専用のネットワーク・エンティティ（サーバ）を導入する方法である。これらのマッピングは、ネットワーク・オペレータが事前構成でき、又は例えば、上記機構を用いて動的に発見することができる。次に、ＭＮは、このネットワーク・エンティティに要求を送信し、ＲＯ−ＨＡアドレスを含む応答を受信する。

図２は、ＩＰヘッダ内にデータ経路及びアドレスを含む一例を示す。ＭＮ１００は、ＨＡ１ １０４に登録し、ＨｏＡ１で構成した後、ＣＮ１０２との通信を開始した。アプリケーションがＣＮ１０２との通信セッションを要求した後で、ＭＮ１００は、ＲＯ−ＨＡ「ＨＡ２」２０６を発見し、これを用いてブート・ストラップし、対応するＨｏＡ（「ＲＯ−ＨｏＡ」又は「ＨｏＡ２」）を構成し、双方向トンネリング・モードでＣＮ１０２との通信にこのＨｏＡを使用する。従って、ＭＮ１０２は、ＨＡ２ ２０６へデータ・パケットをトンネリングし、ＨＡ２ ２０６はデータ・パケットをカプセル開放してＣＮ１０２へ送信する。

ＣＮ（１０２）は、応答すると、パケットをＭＮのＲＯ−ＨｏＡ（ＨｏＡ２）２０６へ送信し、パケットは、ＲＯ−ＨＡ（ＨＡ２）２０６へルーティングされ、ＭＮ１００へトンネリングされる（図３を参照）。ＨｏＡ１ １０４は、この通信セッションでは使用しない。

同じＣＮ又はこのネットワーク又は近傍のネットワーク内の他のＣＮとの後続セッションでは、ＲＯ−ＨＡへのトンネルを再利用できる。移動時に、ＭＮは、ＨＡ１とＨＡ２にＢＵメッセージを送信する。

図８は、ＭＮ開始方法を流れ図で示す。ステップ８０２で、通信が要求される。ステップ８０４で、モバイル・ノードは、第１のＣＮとの間の直接経路の近傍の第１のＨＡを見つける。これを実行するため、上記方法又はサービス品質（ＱｏＳ）、ホップ数、及び／又はパケット遅延などの距離メトリックを用いる他の方法を使用することができる。ステップ８０６で、ＭＮは、ＨＡを用いてブート・ストラップする。これは、Ｍｏｂｉｌｉｔｙ Ｓｅｒｖｉｃｅ Ａｕｔｈｏｒｉｓｅｒ（ＭＳＡ）による認証及び認可が実施される前にＩＰｓｅｃセキュリティ・アソシエーションが設定されＨｏＡが割り当てられるという内容を含む。ステップ８０８で、ＭＮのロケーションは、第１のホーム・エージェントに登録され、次に、ステップ８１０でＣＮとの通信のために双方向トンネリング・モードで使用される。

ＣＮ開始通信セッション
ホームにいないアクティブなＭＮは、少なくとも１つのＨＡに登録される。このＨＡに対応するＭＮのＨｏＡをＣＮが認識していないとこのＣＮからアクセスできない。これは、例えば、ＤＮＳ（ドメイン名サーバ）内でＨｏＡを公開することで達成できる。このＨＡは、アクセスするためにＭＮが主として使用するが、以降はＩＰ−Ｒｅａｃｈａｂｉｌｉｔｙ（ＩＲ）−ＨＡ（図５のＨＡ１）と呼ぶ。ＣＮ開始のケースでは、ＣＮは、例えば、ＤＮＳにＭＮのホスト名を照会することによって、ＭＮのＩＲ−ＨｏＡ（すなわち、ＭＮのＩＲ−ＨＡの１つに属するＨｏＡ）の１つを選択し、ＭＮにアクセスする。従って、ＭＮは、自分でＨｏＡを選択できず、対応するＩＲ−ＨＡは短いルートを提供することができないことがある。

ＩＲ−ＨＡ１０４上でＣＮからの最初のデータ・パケットがＭＮ１００によって受信されると（図４のステップ４０１）、ＭＮ１００はルートを最適化する決定ができる（パケットの送信元であるＩＲ−ＨＡ１０４への距離に応じて）。従って、ＭＮ１００は、好ましくはＣＮ１０２の近くに位置し、好ましくはＭＮ１００とＣＮ１０２の間の直接経路の近傍のＨＡ２０６を発見してＨＡ２０６を用いてブート・ストラップする（ステップ４０２）。このＨＡも、ＭＮ開始のケースで定義したＲＯ−ＨＡ（図４のＨＡ２）である。ＲＯ−ＨＡ２０６は、強力なロケーション・プライバシー・サポートを維持し、ＭＮモビリティがある場合の頻繁なブート・ストラップを防止するために、ＭＮ１００よりもＣＮ１０２の方に近い位置にある必要があることに留意されたい。

ブート・ストラップの後、ＭＮ１００は、ＲＯ−ＨＡに登録し、ＲＯ−ＨＡ２０６への逆方向トンネル上でＣＮとリターン・ルータビリティ手順を開始する（ステップ４０３）。ＭＮは、ＩＲ−ＨｏＡ（ＨｏＡ１）をＨｏＡとして使用し、ＲＯ−ＨｏＡ（ＨｏＡ２）をＣｏＴｉ及びＢＵメッセージ内のＣｏＡとして使用して、ＲＯ−ＨＡ２０６への逆方向トンネル上でＣＮ１０２へこれらのメッセージを送信する。ＨＡへ送信されたＢＵメッセージは、「実際の」ＣｏＡを含んだままである。従って、ＣＮ１０２によって送信されたデータ・パケット（ステップ４０４）は、タイプ２ルーティング・ヘッダを用いてＲＯ−ＨＡ２０６へルーティングされ、ルーティング・ヘッダを含めてＭＮ１００へトンネリングされる。従って、ＣＮから見ると、ＭＮ１００は、ＲＯ−ＨＡ２０６のネットワーク内に位置する。結果として、セッションを中断させることなくルートが最適化され、ロケーション・プライバシーが提供される。ＨＡもＣＮも変更する必要がないため、この解決策は実施が容易で遷移の問題は発生しない。

図５は、ＲＯ−ＨＡ（ＨＡ２）２０６への逆方向トンネル上でＭＮがデータ・パケットを送信する場合の経路及びアドレスを示す図である。パケットは、ＨｏＡオプション内にＩＲ−ＨｏＡ（ＨｏＡ１）を含み、内部ＩＰヘッダ内にソース・アドレスとしてのＲＯ−ＨｏＡ（ＨｏＡ２）２０６を含む。この例は、ＣｏＡがルート最適化モードでソース・アドレスとして使用されることを規定するＲＦＣ３７７５とは異なることに留意されたい。

図９は、ＣＮ開始のケースを示す流れ図である。ステップ９０２で通信が要求された後、ステップ９０４で、ＭＮは第１のＣＮからデータ・パケットを受信する。ステップ９０６で、第１のＭＮと第１のＣＮとの間の直接経路の近傍の第２のＨＡが見つかり、ステップ９０８で、第２のＨＡを用いたブート・ストラップが実行される。ステップ９１０で、第１のＭＮのロケーションが第２のＨＡに登録され、ステップ９１２で、第２のＨＡのネットワークに属するホーム・アドレスが、第１のＭＮのロケーションとしてＣＮに登録される。ステップ９１４で、双方向トンネル上でＣｏＴ及びＣｏＴｉメッセージが送信され、ステップ９１６で、ルート最適化モードが使用され、両方のステップで、ＭＮの第２のＨｏＡがＣｏＡとして使用される。

同じＣＮ又はこのネットワーク又は近傍のネットワーク内の別のＣＮとの後続のセッションに対して、ＲＯ−ＨＡ（ＨＡ２）へのトンネルを再利用できる。移動時に、ＭＮは、ＩＲ−ＨＡ及びＲＯ−ＨＡにＢＵメッセージを送信する。しかし、ＲＦＣ３７７５のルート最適化モードで普通そうするようなＣＮへのＢＵメッセージの送信は行わない。ＭＮがＣＮへＢＵを送信するのは、ＭＮがルート最適化モードの基礎になる双方向トンネルをＲＯ−ＨＡから別のＲＯ−ＨＡに変更する（また周期的に変更してバインディング寿命の満了を防ぐために）場合に限られる。

以下に、ＳＩＰベースのＭｏｂｉｌｅ ＩＰデータ・セッションのためのルート最適化方法について説明する。上記実施の形態では、実行中のセッションは第１から第２のホーム・エージェントへ移動しなければならないため、ＣＮ開始シナリオではルーティング・ヘッダが必要であった。別の実施の形態で、ＭＮとＣＮがセッション開始プロトコル（ＳＩＰ）などのアプリケーション・レベルの信号方式を用いて通信セッションを確立する場合に、この追加のトンネリング・オーバヘッドを不要にすることができる方法について説明する。

従って、ＣＮからのＳＩＰ招待メッセージを受信する（１１０４）と、ＭＮはこのメッセージのＳＤＰ部内でＣＮアドレスを検索し、ＣＮに近い位置にある第２のＨＡの発見を開始する。次に、ＭＮはこの第２のＨＡを用いてブート・ストラップする。ブート・ストラップ手順の間、ＭＮは新しいＨｏＡを入手する。ＭＮは、この新しいＨｏＡを「ＯＫ応答」メッセージのＳＤＰ部に挿入し、このメッセージをＣＮへ返送する。次に、ＣＮは、その後のＭＮとの信号送受信及びデータ通信（１１１４）のためにこのＨｏＡを使用し、従って、最初から最適化ルートを使用する。セッションを１つのＨＡから別のＨＡへ移動させる必要はないので、リターン・ルータビリティ信号方式とルーティング・ヘッダは不要である。

ＭＮとＣＮがアプリケーション・レベル信号方式を用いて通信セッションを確立する場合に、この追加のトンネリング・オーバヘッドを不要にすることができる方法を以下に詳述する。主要なアイデアは、アプリケーション・レイヤ上のＳＩＰとネットワーク・レイヤ上のＭｏｂｉｌｅ ＩＰ（ＭＩＰ）とのレイヤ間通信を活用するということである。以下に、２つのシナリオ、すなわち、ＣＮがセッション開始プロトコル（ＳＩＰ）を用いてＭＮとのセッションを開始するシナリオ（図１１を参照）とその逆のシナリオ（図１２を参照）に関して、この提案の方法を説明する。ＭＮは、ＭＮのＳＩＰプロキシ・サーバにＳＩＰを介して登録され、ＣＮは、ＣＮのＳＩＰプロキシ・サーバにＳＩＰを介して登録されているものとする。

ＣＮ開始のケースでは、ＣＮは、ＳＩＰ招待メッセージをＭＮへ送信する（１１０４）ことでセッションの確立を開始する。招待メッセージを受信すると、ＭＮ内のＳＩＰモジュールは、ＳＤＰオファー内又はこのメッセージ内のＳＩＰヘッダのコンタクト・フィールド内のＣＮアドレスを検索し、トリガと共にこのアドレスをＭＩＰモジュールに提供する。トリガを受信すると、ＭＩＰモジュール（上記各節で説明した方法で拡張されている）は、ＲＯ−ＨＡ（すなわち、ＣＮの近くに位置するＨＡ）の発見を開始する。発見に成功すると、ＭＮはこのＲＯ−ＨＡを用いてブート・ストラップする。ブート・ストラップ手順の間、ＭＮは新しいホーム・アドレスＲＯ−ＨｏＡを入手する。このＲＯ−ＨｏＡは、次に、ＭＮ内のＭＩＰモジュールによってトリガと共にＳＩＰモジュールに提供され、ＳＩＰモジュールは、このＲＯ−ＨｏＡをＳＤＰ応答内及び／又はＣＮへ送信される次の適切なＳＩＰメッセージのＳＩＰヘッダのコンタクト・フィールド内に挿入する。これは、例えば、ＯＫ招待メッセージ（１１１０）であってもよい。その結果、ＣＮは、ＭＮとのセッションのＭＮアドレスとしてＲＯ−ＨｏＡを使用し、最適化ルートが、セッションの初めから、すなわち、ＭＮへ送信される最初のデータ・パケットで使用される。また、これは、上記のようにセッションをあるＨＡから別のＨＡへ移動させなくてもよいことを意味する。すなわち、リターン・ルータビリティ信号方式は不要で、データ・パケットはルーティング・ヘッダを搬送しないので、オーバヘッドは大幅に低減する。

この実施の形態の別の重要な用途は以下の通りである。通信セッションが存在しない限り、ＭＮはいかなるＨＡにも登録されない。代わりに、ＭＮは、自ら通信セッションを開始したい場合、又はＳＩＰ招待メッセージを受信した場合、すなわち、ＣＮがＭＮとの通信セッションを開始したい時に初めてＨＡに登録される。この手法は、特にＭＮが実際に通信セッションを開かずに長距離を移動する時に、ＭＮのバッテリ電力と無線信号送受信とを大幅に節約する。

ＭＮがセッションを開始した場合、この方法は多少異なったものになる。例えば、リンギング・メッセージのＳＤＰ応答（１２０２）又はＳＩＰヘッダ内のコンタクト・フィールドからＭＮはＣＮアドレスを入手する。このメッセージの受信後に、ＭＩＰモジュールがＣＮアドレスでトリガされる。一般に、ＳＤＰ応答は、最良の最適化を達成するために、できるだけ早くＭＮに送達しなければならない。ＲＯ−ＨＡを用いたブート・ストラップ（１２０４）とＲＯ−ＨｏＡの入手の後で、ＭＮは、ＭＮがＳＤＰオファー及び／又は初期招待メッセージのＳＩＰヘッダのコンタクト・フィールド内に挿入したアドレスの代わりにこのアドレスをセッションに使用するようにＣＮに通知する。このために、ＭＮは、例えば、ＳＤＰオファー内及び／又はＳＩＰヘッダのコンタクト・フィールド内にＲＯ−ＨｏＡを含む再招待メッセージ又はＵｐｄａｔｅメッセージを送信する（１２０８）（Ｊ．Ｒｏｓｅｎｂｅｒｇ，「セッション開始プロトコル（ＳＩＰ）ＵＰＤＡＴＥ方法、ＲＦＣ３３１１、２００２年９月」）。ＯＫ招待メッセージを受信する前にブート・ストラップが完了した場合、ＭＮは、再招待メッセージを送信することができない。代わりに、ＭＮは、ＲＯ−ＨｏＡを含むＵｐｄａｔｅメッセージを送信することができる。ブート・ストラップ・プロセスの完了前にＯＫメッセージを受信した場合、ＭＮは、ＲＯ−ＨｏＡを含む再招待メッセージを送信することができる。いずれにせよ、ＭＩＰブート・ストラップ・プロセス及びＳＩＰセッション・ネゴシエーション・プロセスは、少なくとも部分的に同時に実行することができる。これは、最適化ルートがこの最適化がない場合よりも早く確立されるということを意味する。

一般的な問題と変形形態
以下に、上記方法に対するいくつかの可能な最適化について論じ、次に、ロケーション・プライバシーを超える本発明の別の用途について説明する。

最適化
本発明で説明した機構の性能を増加させるためにいくつかの最適化が可能である。

最適化ルートを使用する前に、まずＲＯ−ＨＡを発見しなければならない。この発見にかかる時間を低減するために、２つのオプションが可能である。

第１に、ＩＲ−ＨＡは、ＨＡの構成リストに基づいて、又は動的にＲＯ−ＨＡを発見し、このＲＯ−ＨＡアドレスをＭＮに提案する。発見は、ＣＮからの最初のデータ・パケットの受信時に開始してもよい。ＲＯ−ＨＡアドレスの提案は、例えば、ＨＡの信頼性に対して定義されたトリガ・メッセージの送信によって行ってもよい。

第２に、ＣＮは、ＨＡの構成リストに基づいて、又は動的にＲＯ−ＨＡを発見し（例えば、ルータ公示又はＤＨＣＰメッセージなどのローカル・ネットワーク内の公示から）、このＲＯ−ＨＡアドレスをＭＮに提案する。ＲＯ−ＨＡアドレスの提案は、例えば、ＨＡの信頼性に対して定義されたトリガ・メッセージの送信によって行ってもよい。

最適化ルートは、ＭＮがＲＯ−ＨＡを用いたブート・ストラップ手順を完了して初めて使用することができる。この時間を低減するため、以下のオプションが可能である。

第１に、ＣＮから最初のデータ・パケットを受信すると、ＩＲ−ＨＡは、ＭＮのために、ＲＯ−ＨＡを用いてブート・ストラップする。その後、パラメータ及びＩｐｓｅｃ（インターネット・プロトコル・セキュリティ）のセキュリティ・アソシエーションの状態がＩＲ−ＨＡからＭＮへ転送される。従って、ＩＰｓｅｃセキュリティ・アソシエーションを確立する時間は低減される。

第２に、ＣＮから最初のデータ・パケットを受信すると、ＩＲ−ＨＡは、共有セッション鍵と認可データとを生成してＲＯ−ＨＡへ転送する。従って、ＡＡＡＨ（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ、Ａｕｔｈｏｒｉｓａｔｉｏｎ ａｎｄ Ａｃｃｏｕｎｔｉｎｇ，Ｈｏｍｅ ｄｏｍａｉｎ）サーバに問い合わせるための時間が節約される。

第３に、ＣｏＴ／ｉパケットをＩＲ−ＨＡ及びＲＯ−ＨＡを介してＭＮからＣＮへトンネリングすることで、ＣＮとのリターン・ルータビリティ手順は、ＲＯ−ＨＡを用いたブート・ストラップ手順と同時に実行することができる。ＲＯ−ＨＡ内の対応する状態をＩＲ−ＨＡによって確率することができる。

もう１つのポイントは、ルート最適化の決定にオペレータが参画することができるということである。従って、ＩＲ−ＨＡは、ＭＮをトリガしてルートを最適化させ（例えば、ＣＮから最初のデータ・パケットを受信した時点で）、ＲＯ−ＨＡを用いてブート・ストラップすることができる。従って、ＨＡの信頼性に関して定義されたトリガ・メッセージを再利用できる。

セッションが非最適化ルートから最適化ルートへ移動する時に、データ・パケットが失われるか、又は並べ替えられることがある。これは、サービス品質に悪影響を与える可能性がある。呼／接続設定信号交換（例えば、ＳＩＰベースの（信号開始プロトコル）サービス）を必要とするサービスでこのことを防止する１つのオプションは、最適化ルートの確立と並行して非最適化ルート上で呼／接続設定信号方式を実行することである。両方のプロセスが完了した場合にのみ、データ転送が開始される。これは、最適化ルートが確立されたことを示す新しいトリガ・メッセージを導入するか、又は呼／接続設定信号方式にこの情報を追加することで達成できる。

ＣＮが移動機であり、そのＩＲ−ＨＡから遠く離れている場合、ルートは十分には最適化されない。ＩＲ−ＨＡ又はＲＯ−ＨＡがＣＮのＨＡの場合、少なくとも１つのＨＡは、ＣｏＡと、ＭＮ及びＣＮの両方のロケーションを認識しており、従って、ＭＮ及びＣＮの訪問先ネットワーク間に位置する新しいＲＯ−ＨＡを発見することができる。従って、セッションを再び新しいＲＯ−ＨＡへ移動してさらにルート最適化を行うことができる。

ＭＮとＣＮが両方共同じＨＡにおいて登録されているという状況が偶然に、又は強制的に発生することがある。この状況を強制的に発生させる可能なオプションは、ＭＮ及びＣＮ又はその代わりの何らかの１つ又は複数のエンティティ（例えば、それらのＩＲ−ＨＡ）が共通のＨＡをネゴシエーションし、そのＭＮ／ＣＮをトリガして共通のＨＡを用いてブート・ストラップするという方法である。

ＣＮ開始セッション・シナリオで双方向トンネリング・モード上にルート最適化モードを使用することの不利な点は、逆方向トンネル内のルーティング・ヘッダによって引き起こされる追加のオーバヘッドである。このオーバヘッドを不要にするオプションは、例えば、ＲＯ−ＨＡがＲＯ−ＨｏＡに宛てたデータ・パケットをインターセプトし、ＩＰヘッダの宛先フィールド内のアドレスをルーティング・ヘッダ内のアドレスに置き換え、パケットのトンネリングの前にルーティング・ヘッダを削除する方法か、又はＭＮがＲＯ−ＨＡアドレスをＣｏＡとして（ＲＯ−ＨｏＡではなく）使用し、＜ＩＲ−ＨｏＡ、ＣｏＡ＞を含むＢＵメッセージをＲＯ−ＨＡへ送信する方法である。この場合、ルーティング・ヘッダは、ＲＯ−ＨＡによって自動的に削除される（ＲＯ−ＨＡのアドレスを含むため）。削除後、パケットはＩＲ−ＨｏＡへ宛てられ、ＩＲ−ＨｏＡは、ＲＯ−ＨＡをトリガしてそのバインディング・キャッシュを調査させ、パケットをＭＮのＣｏＡへトンネリングさせる。しかし、両方のオプションで、基本（非最適化）方法では不要なＨＡ実施態様への変更が必要である。

本発明の他の用途
本発明は、ロケーション・プライバシーだけでなくより広い用途を有する。より一般的には、本発明では、データ・セッションを中断させずに（すなわち、セッションのＨｏＡを変更せずに）データ・セッションを新しいアンカーＨＡへ移動させることが可能である。

１つの用途は、ＭＮが移動して新しいネットワーク（図６を参照）に進入すると、新しい（ローカルの）ＨＡを用いてブート・ストラップすることができる時のシナリオの最適化ルーティングである。本発明を用いてデータ・セッションをＨＡ１からＨＡ２へ移動させることで、ルートは双方向トンネリング・モードで最適化することができる。

第２の用途は、ＨＡの負荷分散である。高負荷のＨＡは負荷を低減し、ＭＮをトリガして別のＨＡを用いてブート・ストラップし、セッションをこのＨＡへ移動させることができる。本発明を用いて実行中のデータ・セッションを中断させることなく移動させることができる（図６を除き、この場合、ＭＮは必ずしも移動しないことに留意されたい）。これによって、異なるネットワークに位置するＨＡ間のインターネット全体にわたる負荷分散が可能になる。ＲＦＣ３７７５では、同じネットワーク内（すなわち、同じリンク上）に位置するＨＡ間の負荷分散のみがサポートされる。

複数のＨＡを用いてブート・ストラップし、複数の双方向トンネル（各々が双方向トンネリング・モード上でルート最適化モードを使用する）を維持することで負荷分散をさらに拡張することができる。これらのルート上で、ＭＮは、データ・パケットを、例えば、ラウンドロビン方式で送信することができる。しかし、このためには、ＭＮがＣＮに複数のＣｏＡを登録することを可能にする、現在ＩＥＴＦ ｍｏｎａｍｉ６ワーキング・グループで開発中のＲＦＣ３７７５の拡張が必要である。

第３の用途は、耐故障性である。ＭＮが本発明を用いてセッションをＨＡ１からＨＡ２へ移動させた時に、ＭＮとＣＮとの間のＨｏＡ１を用いた通信を中断させることなくＨＡ１を一時的に無効にすることができる。しかし、バインディング寿命が満了したか、又はＨＡ２が変更された時にＣＮのバインディングを更新するために必要なＨｏＴ／ＨｏＴｉ（Ｈｏｍｅ Ｔｅｓｔ／Ｈｏｍｅ Ｔｅｓｔ ｉｎｉｔ）メッセージをルーティングするために、ＨＡ１は依然として必要である。

第４の用途は、異なるネットワーク・インタフェース及びそれに対応するアンカー間で任意にデータ・セッションを移動させることである。例えば、ＭＮは、ＷＬＡＮ（無線ローカル・エリア・ネットワーク）及びセルラ・ネットワーク（例えば、ＵＭＴＳ、ユニバーサル移動体電気通信標準）インタフェース（ＩＦ）を備えることができ、対応するアドレスは、ＨＡ１及びＨＡ２でそれぞれＨｏＡとして登録される。次に、上記のように、本発明を用いて、ＭＮは、実行中のデータ・セッションをＷＬＡＮからＵＭＴＳインタフェースへ、又はＨＡ１からＨＡ２へこのセッションを移動させることでその逆の方向へ、又はその逆も可能である（図７を参照）。

Ｍｏｂｉｌｅ ＩＰｖ６プロトコルを実行するパケット交換システムに関して本発明を説明してきたが、本発明はこのプロトコルに限定されない。代わりに、本発明は、モビリティ・アンカーを通したデータ・パケットのルーティングとアンカーを経由しないデータ・パケットのルーティングの両方をサポートする任意のモビリティ管理プロトコルを実行するシステムに適用することができる。そのようなプロトコルの一例は、ルート最適化拡張機能を備えるＭｏｂｉｌｅ ＩＰｖ４［ＲＦＣ３３４４］である。

モバイル・ノード上で実行される代わりに、モビリティ管理プロトコルは、本発明の適用可能性を損なうことなくプロキシ・ノード上でも実行することができる。この場合、プロキシ・ノードは、モバイル・ノードのために、ネットワークへロケーション・アップデートを送信するステップを含む本発明に記載したすべての必要な動作を実行する。そのようなプロトコルの例は、任意の種類のＰｒｏｘｙ Ｍｏｂｉｌｅ（例えば、［Ｋ．Ｃｈｏｗｄｈｕｒｙ，「ＩＰｖ４用のネットワークベースのレイヤ３のコネクティビティ及びモビリティ管理（Ｎｅｔｗｏｒｋ Ｂａｓｅｄ Ｌａｙｅｒ ３ Ｃｏｎｎｅｃｔｉｖｉｔｙ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ ＩＰｖ４）」、ｄｒａｆｔ−ｃｈｏｗｄｈｕｒｙ−ｎｅｔｍｉｐ４−００．ｔｘｔ、２００６年２月］又は［Ｋ．Ｃｈｏｗｄｈｕｒｙ，Ａ．Ｓｉｎｇｈ、「ＩＰｖ６用のネットワークベースのレイヤ３のコネクティビティ及びモビリティ管理（Ｎｅｔｗｏｒｋ Ｂａｓｅｄ Ｌａｙｅｒ ３ Ｃｏｎｎｅｃｔｉｖｉｔｙ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ ｆｏｒ ＩＰｖ６）」、ｄｒａｆｔ−ｃｈｏｗｄｈｕｒｙ−ｎｅｔｍｉｐ６−００．ｔｘｔ、２００６年２月］）又はｎｅｔｌｍｍ ＷＧで提案され開発されたプロトコル（例えば、［Ｊ．Ｗｏｏｄ，Ｋ．Ｎｉｓｈｉｄａ，「エッジモビリティ・プロトコル（ＥＭＰ）（Ｅｄｇｅ Ｍｏｂｉｌｉｔｙ Ｐｒｏｔｏｃｏｌ（ＥＭＰ））」、ｄｒａｆｔ−ｗｏｏｄ−ｎｅｔｌｍｍ−ｅｍｐ−ｂａｓｅ−００．ｔｘｔ、２００５年１０月］）である。

本発明の別の実施の形態は、ハードウェア及びソフトウェアを用いた上記種々の実施の形態の実施に関する。種々の上記方法と上記種々の論理ブロック及びモジュールは、例えば、汎用プロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）又は他のプログラマブル論理装置などとして、コンピュータ装置（プロセッサ）を用いて実行される場合に実施することができることを理解されたい。本発明の種々の実施の形態は、また、これらの装置の組合せによって実行又は実施することができる。

さらに、本発明の種々の実施の形態は、また、プロセッサによって実行されるソフトウェアモジュールによって、又はハードウェアで直接実施することができる。また、ソフトウェアモジュールとハードウェア実施態様との組合せも可能である。ソフトウェアモジュールは、ＥＰＲＯＭ、ＥＥＰＲＯＭ，フラッシュメモリ、レジスタ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤなどのあらゆる種類のコンピュータ読み取り可能媒体、例えば、ＲＡに格納することができる。

Ｍｏｂｉｌｅ ＩＰｖ６双方向トンネリングとルート最適化モードのそれぞれのＩＰヘッダ内の従来技術のデータ経路及びアドレスを示す図である。 ＭＮが本発明のある実施の形態によるデータを送信する場合のＭＮ開始セッションのＩＰヘッダ内のデータ経路及びアドレスを示す図である。 ＣＮが本発明のある実施の形態によるデータを送信する場合のＭＮ開始セッションのＩＰヘッダ内のデータ経路及びアドレスを示す図である。 ＣＮが本発明のある実施の形態によるデータを送信する場合のＣＮ開始セッションのＩＰヘッダ内のデータ経路及びアドレスを示す図である。 ＭＮが本発明のある実施の形態によるデータを送信する場合のＣＮ開始セッションのＩＰヘッダ内のデータ経路及びアドレスを示す図である。 本発明のある実施の形態によるあるローカルＨＡから別のローカルＨＡへアンカーが移動する場合のデータ経路を示す図である。 本発明のある実施の形態による異なるネットワーク・インタフェースに各々が登録されたあるＨＡから別のＨＡへアンカーが移動する場合のデータ経路を示す図である。 本発明のある実施の形態によるＭＮ開始プロセスのブロック図である。 本発明のある実施の形態によるＣＮ開始プロセスのブロック図である。 ＳＩＰを用いた通信システムの確立の一例を示す図である。 本発明のある実施の形態によるＳＩＰベースのサービスを備えたＣＮ開始通信シナリオにおける最適化されたルーティング、ロケーション・プライバシー及び低トンネリング・オーバヘッドをサポートするシグナリング・フローを示す図である。 本発明のある実施の形態によるＳＩＰベースのサービスを備えたＭＮ開始通信シナリオにおける最適化されたルーティング、ロケーション・プライバシー及び高速トンネリング確立をサポートするシグナリング・フローを示す図である。

Claims (21)

1. 複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムでパケットをルーティングする方法であって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、前記方法が、前記モバイル・ノードによって実行される下記のステップ：
   ａ）前記通信相手ノードからアプリケーション・レイヤ要求メッセージを受信するステップ（１１０４）と、
   ｂ）前記アプリケーション・レイヤ要求メッセージの一部から通信相手ノードのアドレスを検索するステップと、
   ｃ）前記通信相手ノードのアドレスを用いて前記モバイル・ノードと前記通信相手ノードとの間の直接経路の近傍の前記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するステップと、
   ｄ）第２のホーム・アドレスを入手するために、前記第２のホーム・エージェントを用いてブート・ストラップするステップと、
   ｅ）前記通信相手ノードへのアプリケーション・レイヤ応答メッセージの一部に前記第２のホーム・アドレスを挿入して（１１１０）、前記通信相手ノードが前記モバイル・ノードとのデータ通信のために前記第２のホーム・アドレスを使用できるようにするステップ（１１１４）と、
   を含む方法。
2. 前記アプリケーション・レイヤ要求メッセージが、セッション開始プロトコル招待である、請求項１に記載のパケット・ルーティング方法。
3. 特定ステップｃ）が、前記アプリケーション・レイヤ要求メッセージのセッション記述プロトコル部又はコンタクト・フィールド内の前記通信相手ノードのアドレスを検索するステップを含む、請求項１又は２に記載のパケット・ルーティング方法。
4. ステップｅ）が、前記アプリケーション・レイヤ応答メッセージのセッション記述プロトコル部又はコンタクト・フィールド内に前記第２のホーム・アドレスを挿入するステップを含む、請求項１から３のいずれか１項に記載のパケット・ルーティング方法。
5. 前記アプリケーション・レイヤ応答メッセージが、セッション開始プロトコル２００ｏｋ応答である、請求項１から４のいずれか１項に記載のパケット・ルーティング方法。
6. 複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムでパケットをルーティングする方法であって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、前記方法が、前記モバイル・ノードによって実行される下記のステップ：
   第１のアプリケーション・レイヤ要求メッセージを前記通信相手ノードへ送信するステップ（１２００）と、
   前記通信相手ノードからアプリケーション・レイヤ応答メッセージを受信するステップ（１２０２）と、
   前記アプリケーション・レイヤ応答メッセージの一部から通信相手ノードのアドレスを検索するステップと、
   前記通信相手ノードのアドレスを用いて前記モバイル・ノードと前記通信相手ノードとの間の直接経路の近傍の前記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するステップと、
   第２のホーム・アドレスを入手するために、前記第２のホーム・エージェントを用いてブート・ストラップするステップ（１２０４）と、
   前記モバイル・ノードとのデータ通信のために前記第２のホーム・アドレスを使用するように前記通信相手ノードに通知するステップと、
   を含む方法。
7. 前記アプリケーション・レイヤ要求メッセージが、セッション開始プロトコル招待である、請求項６に記載のパケット・ルーティング方法。
8. 特定ステップが、前記アプリケーション・レイヤ応答メッセージのセッション記述プロトコル部又はコンタクト・フィールド内の前記通信相手ノードのアドレスを検索するステップを含む、請求項６又は７に記載のパケット・ルーティング方法。
9. 前記アプリケーション・レイヤ応答メッセージが、セッション開始プロトコル２００ｏｋ応答である、請求項６から８のいずれか１項に記載のパケット・ルーティング方法。
10. 前記アプリケーション・レイヤ応答メッセージが、セッション開始プロトコル１８０リンギング応答である、請求項６から９のいずれか１項に記載のパケット・ルーティング方法。
11. 前記通信相手ノードに通知するステップが、セッション開始プロトコル再招待メッセージ又はセッション開始プロトコル更新メッセージを送信するステップを含む、請求項６から１０のいずれか１項に記載のパケット・ルーティング方法。
12. 複数のホーム・エージェント及び少なくとも１つの通信相手ノード（１０２）を含むパケット交換ネットワークのシステムにおけるモバイル・ノード（１００）であって、前記モバイル・ノード（１００）が、少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェント（１０４）を経由して前記通信相手ノード（１０２）と通信し、
    前記通信相手ノードからアプリケーション・レイヤ要求メッセージを受信するように構成された受信手段と、
    前記アプリケーション・レイヤ要求メッセージの一部から通信相手ノードのアドレスを検索するように構成された手段と、
    前記通信相手ノードのアドレスを用いて前記モバイル・ノードと前記通信相手ノードとの間の直接経路の近傍の前記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するように構成された特定手段と、
    第２のホーム・アドレスを入手するために、前記第２のホーム・エージェントを用いてブート・ストラップするように構成されたブート・ストラップ手段と、
    前記通信相手ノードへのアプリケーション・レイヤ応答メッセージの一部に前記第２のホーム・アドレスを挿入して、前記通信相手ノードが前記モバイル・ノードとのデータ通信のために前記第２のホーム・アドレスを使用できるように構成された手段と、
    を含むモバイル・ノード（１００）。
13. 請求項２から５のいずれか１項に記載の方法ステップを実行するように構成された、請求項１２に記載のモバイル・ノード（１００）。
14. 複数のホーム・エージェント及び少なくとも１つの通信相手ノード（１０２）を含むパケット交換ネットワークのシステムにおけるモバイル・ノード（１００）であって、前記モバイル・ノード（１００）が少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、
    前記通信相手ノードへアプリケーション・レイヤ要求メッセージを送信するように構成された送信手段と、
    前記通信相手ノードからアプリケーション・レイヤ応答メッセージを受信するように構成された受信手段と、
    前記アプリケーション・レイヤ要求メッセージの一部から通信相手ノードのアドレスを検索するように構成された手段と、
    前記通信相手ノードのアドレスを用いて前記モバイル・ノードと前記通信相手ノードとの間の直接経路の近傍の前記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するように構成された特定手段と、
    第２のホーム・アドレスを入手するために、前記第２のホーム・エージェントを用いてブート・ストラップするように構成されたブート・ストラップ手段と、
    前記モバイル・ノードとのデータ通信のために前記第２のホーム・アドレスを使用するように前記通信相手ノードに通知するように構成された送信手段と、
    を含むモバイル・ノード（１００）。
15. 請求項７から１１のいずれか１項に記載の方法ステップを実行するように構成された、請求項１４に記載のモバイル・ノード（１００）。
16. 複数のホーム・エージェント、請求項１２又は１３に記載の少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークシステムであって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信するシステム。
17. 複数のホーム・エージェント、請求項１４又は１５に記載の少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークシステムであって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信するシステム。
18. 複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムにおけるコンピュータ読み取り可能媒体であって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、前記モバイル・ノードのプロセッサによって実行された場合に、前記モバイル・ノードに下記のステップ：
    ａ）前記通信相手ノードからアプリケーション・レイヤ要求メッセージを受信するステップと、
    ｂ）前記アプリケーション・レイヤ要求メッセージの一部から前記通信相手ノードのアドレスを検索するステップと、
    ｃ）前記通信相手ノードのアドレスを用いて前記モバイル・ノードと前記通信相手ノードとの間の直接経路の近傍の前記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するステップと、
    ｄ）第２のホーム・アドレスを入手するために、前記第２のホーム・エージェントを用いてブート・ストラップするステップと、
    ｅ）前記通信相手ノードへのアプリケーション・レイヤ応答メッセージの一部に前記第２のホーム・アドレスを挿入して、前記通信相手ノードが前記モバイル・ノードとのデータ通信のために、前記第２のホーム・アドレスを使用できるようにするステップと、
    を実行させる命令を記憶するコンピュータ読み取り可能媒体。
19. 複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムにおけるコンピュータ読み取り可能媒体であって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、前記モバイル・ノードのプロセッサによって実行された場合に前記モバイル・ノードに請求項２から５に記載の方法ステップを実行させる命令を記憶する、請求項１８に記載のコンピュータ読み取り可能媒体。
20. 複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムにおけるコンピュータ読み取り可能媒体であって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、前記モバイル・ノードのプロセッサによって実行された場合に、前記モバイル・ノードに下記のステップ：
    アプリケーション・レイヤ要求メッセージを前記通信相手ノードへ送信するステップと、
    前記通信相手ノードからアプリケーション・レイヤ応答メッセージを受信するステップと、
    前記アプリケーション・レイヤ要求メッセージの一部から前記通信相手ノードのアドレスを検索するステップと、
    前記通信相手ノードのアドレスを用いて前記モバイル・ノードと前記通信相手ノードとの間の直接経路の近傍の前記複数のホーム・エージェントのうちの第２のホーム・エージェントを特定するステップと、
    第２のホーム・アドレスを入手するために、前記第２のホーム・エージェントを用いてブート・ストラップするステップと、
    前記モバイル・ノードとのデータ通信のために前記第２のホーム・アドレスを使用するように前記通信相手ノードに通知するステップと、
    を実行させる命令を記憶するコンピュータ読み取り可能媒体。
21. 複数のホーム・エージェント、少なくとも１つのモバイル・ノード及び少なくとも１つの通信相手ノードを含むパケット交換ネットワークのシステムにおけるコンピュータ読み取り可能媒体であって、前記モバイル・ノードが少なくとも第１のホーム・アドレスを有し、前記複数のホーム・エージェントのうちの第１のホーム・エージェントを経由して前記通信相手ノードと通信し、前記モバイル・ノードのプロセッサによって実行された場合に前記モバイル・ノードに請求項７から１１のいずれか１項に記載の方法ステップを実行させる命令を記憶する、請求項２０に記載のコンピュータ読み取り可能媒体。