JP5205468B2 - ネットワーク・ベース・モビリティからホスト・ベース・モビリティへのハンドオーバ時におけるルート最適化の継続性 - Google Patents

Description

本発明は、一般に、移動通信に関し、より詳細には、ネットワーク・ベース・モビリティとホスト・ベース・モビリティ間のハンドオーバに関する。

本発明は、ネットワーク・ベース・モビリティ方式対応アクセス・ネットワーク（ネットワーク・ベース・モビリティ・ドメイン）とネットワーク・ベース・モビリティ方式非対応アクセス・ネットワーク（ホスト・ベース・モビリティ・ドメイン）間のハンドオーバに関する。

以下において、本願を通じて使用される用語のいくつかを説明する。

ＭＩＰ（クライアント・モバイルＩＰ）：ホスト・ベース・モビリティ・メカニズム。クライアント（ホスト又はモバイル・ノード、ＭＮ）は、自身の新しい位置を登録するため、ホーム・エージェント（ＨＡ）に登録メッセージを送信する。２００４年のＪｏｈｎｓｏｎ等による文献（Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、“Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６”、ＲＦＣ ３７７５、２００４年６月）には、モバイルＩＰバージョン６（ＭＩＰｖ６）プロトコルについて明記されている。

ＰＭＩＰ（プロキシ・モバイルＩＰ）：モバイルＩＰプロトコルに基づくネットワーク・ベース・モビリティ・メカニズム。（モバイル・アクセス・ゲートウェイ、ＭＡＧと呼ばれる）プロキシ・モビリティ・エンティティは、ＭＮの新しい位置を登録するため、ＭＮに代わって登録メッセージをＨＡに送信する。ＰＭＩＰにおけるＨＡは、ＭＡＧによるプロキシ登録を処理するよう調整されているので、ローカル・モビリティ・アンカー（ＬＭＡ）とも呼ばれる。ＰＭＩＰメカニズムにおいて、ＭＮはモビリティに関連する処理には関与していない。プロキシＭＩＰｖ６プロトコル（ＰＭＩＰｖ６）は現在制定中のプロトコルであり、その現在の仕様が２００７年のＧｕｎｄａｖｅｌｌｉ等による文献（Ｓ．Ｇｕｎｄａｖｅｌｌｉ、Ｋ．Ｌｅｕｎｇ、Ｖ．Ｄｅｖａｒａｐａｌｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙ、「Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰｖ６」、ＲＦＣ５２１３、２００８年８月）に記載されている。この文献では、ＰＭＩＰという用語がネットワーク・ベースという意味を有し、例えば、“ＰＭＩＰモビリティ”が“ネットワーク・ベース・モビリティ”と置き換え可能に使用できることに留意されたい。

バインディング・アップデート（ＢＵ）：ＨＡ又は各ＬＭＡにＭＮの新しいアドレス（すなわち、トポロジー的な位置）を通知するためにモバイル・ノード又は各ＭＡＧによって送信される登録メッセージ。本発明では、以下において、ホスト・ベース・モビリティ・メカニズムにおいてＭＮが送信するＢＵをＢＵと呼び、ネットワーク・ベース・モビリティ・メカニズムにおいてＭＡＧが送信するＢＵをＰＢＵ（プロキシＢＵ）と呼び、区別する。同様に、ホストが送信するバインディング・アップデート確認応答メッセージはＢＡと呼び、ＭＡＧが送信するバインディング・アップデート確認応答メッセージはＰＢＡ（プロキシＢＡ）と呼ぶ。

キーゲントークン：キーゲントークンとは、リターン・ルータビリティ手順においてＣＮにより提供される番号であり、モバイル・ノードがＣＮに送信されるバインディング・アップデートの認証に必要なバインディング管理鍵を算出できるようにするものである。

バインディング・キャッシュ・エントリ：ホーム・リンク上のホーム・エージェントは、各モバイル・ノードに対してバインディング・キャッシュ・エントリを保持し、そのバインディング・キャッシュ・エントリを用いてモバイル・ノード又はモバイル・ネットワークに向けられた任意のトラフィックのルーティングを行う。通常、バインディング・キャッシュ・エントリは、モバイル・ノードのホーム・アドレスとその気付アドレスを結び付ける。モバイル・ノードは、ホーム・エージェントにてバインディング・キャッシュ・エントリを有していない場合、そのホーム・アドレスでは到達不可能であり、そのホーム・アドレスでは新しいセッションを設定できない。バインディング・キャッシュ・エントリは、別のクライアント（例えば、モバイル・ノード）によって確立されたクライアント（例えば、通信相手ノード）にも存在し得る。バインディング・キャッシュ・エントリは、ルーティング・テーブルにおけるエントリを変更するため、ルーティング状態とも称される。

以下において、ＨＡとＬＭＡが一緒に配置されたもの（コロケーション）はＨＡ／ＬＭＡと示される。

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

ネットワーク内のルータは、ルーティング・プロトコルによって提供される追加情報を用いて、特定の宛先へ向けて次のルータを同定することができる。

端末（以下、モバイル・ノード（ＭＮ）と呼ぶ）が移動可能であって、サブネット間を移動する場合、インターネット・プロトコル（ＩＰ）においては階層型アドレッシング方式が使用されているので、端末は自身のＩＰアドレスをトポロジー的に正しいＩＰアドレスに変更しなければならない。しかしながら、ＴＣＰ接続などの上位層における接続は、通信中ノードのＩＰアドレス（及びポート）で定義されるので、ノードの一方が例えば移動のためＩＰアドレスを変更すると、接続が切れてしまう。

モバイルＩＰｖ６（Ｊｏｈｎｓｏｎ等、２００４年）は、上位層及びアプリケーションにトランスペアレントに、すなわち、上位層の接続を切断することなく、ＭＮのサブネット間移動を可能にするＩＰベースのモビリティ・プロトコルである。従って、１つのＭＮに対し、２つのＩＰアドレス、すなわち、気付アドレス（ＣｏＡ）とホーム・アドレス（ＨｏＡ）が設定される。ＭＮの上位層は、通信相手（宛先端末、以下、通信相手ノード（ＣＮ）と呼ぶ）との通信にＨｏＡを使用する。このアドレスは不変であり、ＭＮを識別するという目的にかなう。トポロジー的には、このアドレスはＭＮのホーム・ネットワーク（ＨＮ）に属する。一方、ＣｏＡは、サブネットの変更を伴う移動の度に変化し、ルーティング・インフラストラクチャのロケータとして使用される。トポロジー的には、このアドレスは、ＭＮが現在訪れているネットワークに属する。ホーム・リンク上に位置する一群のホーム・エージェント（ＨＡ）のうちの１つが、ＭＮのＣｏＡからＭＮのＨｏＡへのマッピングを保持し、ＭＮへの着信トラフィックをＭＮの現在位置に転送する。単一のＨＡではなく一群のＨＡを配置する理由は、冗長性と負荷分散のためである。

モバイルＩＰｖ６（ＭＩＰｖ６）は現在、２つの動作モード、すなわち、双方向トンネリングとルート最適化とを定義している。双方向トンネリングが用いられる場合、ＣＮにより送信されたＭＮのＨｏＡ宛てのデータ・パケットは、ＨＮ内のＨＡによりインターセプトされ、ＭＮのＣｏＡへトンネリングされる。ＭＮにより送信されたデータ・パケットは、ＨＡへ逆方向トンネリングされ、ＨＡは、これらのパケットのカプセル化を開放し、ＣＮへ送信する。この処理のために、ＨＡは、ＭＮのＣｏＡを通知されていなければならない。従って、ＭＮは登録メッセージ（以下バインディング・アップデート・メッセージ、ＢＵと呼ぶ）をＨＡに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティ・アソシエーションを介して送信されるので、正当であると認証されその完全性が保護されている。ＭＮがＨＡとＩＰｓｅｃアソシエーションを持つためには、ＭＮは事前にブートストラッピングを行う必要がある。ブートストラッピングとは、少なくともホーム・アドレス、ホーム・エージェント・アドレス、ホーム・エージェントとのセキュリティ・アソシエーションといった情報を取得する処理のことである。これらの情報は、ＭＮがＣｏＡをホーム・エージェントに登録する前に必要となる。

モビリティ関連のシグナリングはホスト（又はクライアント）とＨＡの間で行われるので、モバイルＩＰはホスト・ベース（又はクライアント・ベース）のモビリティ管理に分類される。モバイルＩＰはこのため、クライアント・モバイルＩＰ（ＣＭＩＰ）と呼ばれることがある。

別の手法は、限られた地理上の領域におけるＩＰモビリティ管理を対象とし、ネットワークによって管理されるためＭＮにトランスペアレントである。この手法はネットワーク・ベースのローカルＩＰモビリティと呼ばれる。ネットワーク・ベース・モビリティの主な特徴の１つは、アクセス・ネットワーク・エンティティがＭＮの移動を検出しＭＮの現在位置に関する情報を交換するよう適宜構成されており、ＭＮがモビリティ処理に関与しなくてもよいということである。従って、無線インターフェースを介したモビリティ関連のシグナリングが回避される。ネットワーク・ベースのモビリティ管理のその他の利点としては、ＭＩＰｖ６カプセル化を必要としないため無線でのパケット・オーバヘッドが少ないこと、及び単純なＩＰノード（すなわち、非ＭＩＰ対応ノード）に関するモビリティ・サポートであることがあげられる。

インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ）は、モバイルＩＰプロトコルに基づく局所的モビリティ管理に関するこうした手法に取り組んでいる。ネットワーク・エンティティがＭＮに代わってプロキシとして動作しているため、プロトコルはプロキシ・モバイルＩＰｖ６（ＰＭＩＰｖ６）と呼ばれる。ＰＭＩＰｖ６と呼ばれるＩＰｖ６の変形（Ｇｕｎｄａｖｅｌｌｉ等、２００７年）、及びＰＭＩＰｖ４と呼ばれるＩＰｖ４の変形（Ｋ．Ｌｅｕｎｇ、Ｇ．Ｄｏｍｍｅｔｙ、Ｐ．Ｙｅｇａｎｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙによる「Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ ｕｓｉｎｇ Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰｖ４」、ｄｒａｆｔ−ｌｅｕｎｇ−ｍｉｐ４−ｐｒｏｘｙ−ｍｏｄｅ−０２．ｔｘｔ、２００７年１月）がある。

本発明では、ネットワーク・ベースのモビリティ管理のプロトコルとしてＰＭＩＰｖ６を想定しているが、本発明はＰＭＩＰｖ６に限らず、ＰＭＩＰｖ４などの他のネットワーク・ベースのモビリティ管理プロトコルにも適用可能である。

ＰＭＩＰｖ６は、アクセス・ルータ（ＡＲ）と同じ場所に配置されてＭＮに代わってＢＵメッセージを送信する、モバイル・アクセス・ゲートウェイ（ＭＡＧ）と呼ばれる新しい論理エンティティを導入する。これらのＢＵメッセージはフラグでマーク付けされるため、プロキシＢＵ（ＰＢＵ）メッセージとして識別可能である。さらに、ＰＢＵメッセージはＭＮ識別子（通常、ネットワーク・アクセス識別子ＮＡＩがこのために使用される）オプション、ホーム・プレフィックス・オプション、及びタイムスタンプ（あるいはシーケンス番号）オプションを含む。ＮＡＩオプションは、「ユーザ名＠ｒｅａｌｍ」の形を有し、ＭＮを識別するために使用されるＮＡＩ［ＲＦＣ４２８２］を含む。

ホーム・プレフィックス・オプションは、ＭＮのＨｏＡ又はホーム・プレフィックスを含む。いわゆるｐｅｒ−ＭＮ−ｐｒｅｆｉｘアドレッシングモデルでは、各ＭＮが固有のホーム・プレフィックスを有し、このプレフィックスに基づいて１つ又は複数のＭＮのグローバルＩＰアドレスが設定される。ＭＮが複数のインターフェースを持つ場合、ＭＮの異なるインターフェースに同じプレフィックスを割り当てるのか、それとも異なるプレフィックスを割り当てるのかを判断するのはネットワーク・オペレータのポリシー次第である。

タイムスタンプ・オプションは、ＭＡＧによってＰＢＵが送信された時間を含み、ＰＢＵメッセージの新しさを識別するために、ローカル・モビリティ・アンカー（ＬＭＡ）によって使用される。ＰＢＵがタイムスタンプ・オプションを含まない場合、ＬＭＡは、ＭＩＰｖ６（Ｊｏｈｎｓｏｎ等、２００４年）プロトコルのセクション５．２．６及び９．５に定められた通り、シーケンス番号方式に頼らざるを得ない。シーケンス番号方式は前のＭＡＧと新しいＭＡＧとの間にコンテキスト転送メカニズムが存在する場合に使用でき、現在のシーケンス番号をハンドオーバ手順中に新しいＭＡＧへと伝えることができる。タイムスタンプ・オプションでは、ＭＡＧ間のコンテキスト転送をハンドオーバ中に行う必要がない。

ＭＮは、新しいＭＡＧに接続されると、ＥＡＰフレームワーク［ＲＦＣ３７４８］及びＥＡＰ−ＡＫＡ［ＲＦＣ４１８７］などのＥＡＰ方法を使用して、ネットワークを認証する。ＭＡＧは、通常、パススルー認証として働き、ＥＡＰパケットをＭＮに関するＡＡＡサーバ／インフラストラクチャに転送する。ＭＮはＮＡＩを識別子として使用しうる。ネットワーク認証が成功すると、ＭＡＧはＡＡＡサーバからＭＮのプロファイルを取得する。

ＭＡＧによるホーム・ネットワーク・プレフィックス（ＨＮＰ）の取得にはいくつかの方法がある。文献（Ｇｕｎｄａｖｅｌｌｉ等、２００７年）に記載されているデフォルト方法の１つとして、ＬＭＡによりＨＮＰを割り当てる方法がある。この場合、ＭＡＧは、ＰＢＵのＨＮＰオプションを空にした状態で、ＭＮのプレフィックスを要求するＰＢＵをＬＭＡに送信する。ＬＭＡは、ＨＮＰを含むプロキシ・バインディング確認応答（ＰＢＡ）をＭＡＧに返送する。

別の方法としては、認証プロセス中にＡＡＡサーバによってＨＮＰを割り当てる方法がある。ＨＮＰが割り当てられＭＡＧに認識されると、ＭＡＧはそのプレフィックスを含むＭＮにユニキャストルータ通知（ＲＡ）を送信する。ＭＮはＨＮＰを使ってグローバル・ユニキャストＩＰアドレスを設定する。このようなホストＩＰ設定は、ステートレス自動設定として知られている。

図１に、ステートレス自動設定の場合における初期接続手順中のＰＭＩＰｖ６の信号フローの一例を示す。図１にはさらに、ＭＮが新しいＩＰアドレスを設定する度に行う一般的な重複アドレス検出（ＤＡＤ）手順も示されている。ＤＡＤ手順は、ＩＰアドレスが所定のＩＰリンク上で他と重複しないことを検出するために行われる。

図２は、ハンドオーバが同じＰＭＩＰドメイン内のＭＡＧ間で行われる場合の信号フローを示す。ＭＮはＡＲ／ＭＡＧ２領域に移動した場合、図１に示すような認証手順を開始する。ＭＡＧ２はＥＡＰキートランスポート・メッセージを受け取った後、ＰＢＵ［ＮＡＩ、タイムスタンプ］を送信するＨＡとともに登録プロセスを開始することができる。ＭＡＧ２はＭＮを登録しＨＮＰを取得するためにＰＢＵをＬＭＡに送信する。ＬＭＡはＰＢＡのＨＮＰをＭＡＧに通知する。ＭＮは現在のＩＰ構成が依然として有効であるか否かのチェックを開始し、すなわちＭＮはＲＳメッセージを送信する。ＡＲ／ＭＡＧ２はＬＭＡによって得られたＨＮＰを含むユニキャストＲＡで応答する。ＭＮは同じプレフィックスを受信したので、ＩＰリンクには変更がないと判断し、ＭＮはハンドオーバより前に設定されたＩＰ構成を保持する。こうしてＭＮはＩＰ接続され、データ・パケットを送受信することができる。

ＲＦＣ３７７５に定義されたＨＡの機能は、大部分が再使用されるが、ＰＭＩＰｖ６をサポートするためには幾つかの変更が必要である。以下、ＲＦＣ３７７５で定義されたＨＡは単にＨＡと呼び、２００７年のＧｕｎｄａｖｅｌｌｉ等による文献に定義されたホーム・エージェントはローカル・モビリティ・アンカー（ＬＭＡ）と呼ぶ。本発明では、ＰＭＩＰ−ＨＡ及びＣＭＩＰ−ＨＡが同じ位置に配置されるシナリオが想定される（以下ＣＭＩＰ／ＰＭＩＰ−ＨＡは単にＨＡ／ＬＭＡと呼ぶ）。

ＭＩＰｖ６におけるルート最適化
ＭＮとＣＮとが直接会話すること、すなわち、ホーム・エージェントを迂回することを可能にするルート最適化（ＲＯとも略す）方式にはＭＩＰｖ６プロトコルがつきものである。ルート最適化では、モバイル・ノードが現在のホーム・アドレスと気付アドレスとのバインディング（ＨｏＡ−＞ＣｏＡ）を通信相手ノードにて登録する必要がある。ＣＮはこのバインディングを認識すると、（ＭＮのバインディング・キャッシュ・エントリを有するＨＡと同様に）バインディング・キャッシュ・エントリを設定する。ＣＮからのパケットはＭＮのＣｏＡに直接ルーティングできる。ＣＮは、任意のＩＰｖ６宛先にパケットを送信する場合、パケットの宛先アドレスに対してエントリのキャッシュしたバインディングをチェックする。この宛先アドレスに対してキャッシュしたバインディングが見つかった場合、ＣＮは新しいタイプのＩＰｖ６ルーティング・ヘッダを使ってパケットをこのバインディングに示されたＣｏＡ経由でＭＮへとルーティングする。

ＭＩＰｖ６仕様（Ｊｏｈｎｓｏｎ等、２００４年）には、ＭＮによって送信されたＢＵを暗号トークン交換（キーゲントークン）を用いて認証するリターン・ルータビリティ（ＲＲとも略す）手順が定義されている。ＣＮはＭＮのホーム・アドレス及び気付アドレスの到達可能性を事前に証明したＭＮからしかバインディング・アップデートを受け付けないので、このような手順が必要となる。ＭＮによるバインディング・アップデートは、ホーム・アドレスと気付アドレスとで別々にＣＮから取得したキーゲントークンに基づいて生成されたバインディング管理鍵（Ｋｂｍ）で署名される。ＲＲ手順は、ＭＮとＣＮでメッセージをやり取りすることで、事前に決められたセキュリティ・アソシエーションなしに相互検証を可能にする。

図３に、ＲＯで行われる信号フローを示す。ＭＮはＣＮに異なるルートを介して２つのメッセージを送信する。そのうちの一方のメッセージ、ホーム・テスト開始（ＨｏＴｉ）メッセージはＭＩＰ ＩＰ‐ｉｎ‐ＩＰトンネルを介してＨＡに送信され、ＨＡはその後そのメッセージをＣＮに転送する。他方のメッセージ、気付テスト開始（ＣｏＴｉ）はＣＮに直接送信される。ＨｏＴｉ及びＣｏＴｉメッセージはいずれも、ＣＮによってＭＮに返送されるクッキーを含む。ＣＮは、ＨｏＴｉ及びＣｏＴｉメッセージを受信後、異なるルートを介してＭＮに２つのメッセージを再度返送する。ホーム・テスト（ＨｏＴ）メッセージはＭＮのＨｏＡ、すなわちＨＡに送信され、ＨＡはそのメッセージをＭＩＰｖ６トンネルを介してＭＮに転送する。気付テスト（ＣｏＴ）はＭＮに直接送信される。

両方のＨｏＴ及びＣｏＴメッセージは、「ホーム・キーゲントークン」及び「気付キーゲントークン」をそれぞれ含む。これらのトークンはＣＮの現在有効な秘密鍵、ノンス、そしてホーム又は気付アドレス（のそれぞれ）に基づくものである。ＨｏＴ及びＣｏＴメッセージがＭＮに到着した後、ＭＮはキーゲントークンを使ってバインディング・アップデート（ＢＵ）メッセージを生成し、それをＣＮに送信する。ＣＮはそのメッセージを受信後、ＭＮのＨｏＡとＣｏＡのバインディングを用いてバインディング・キャッシュを更新することができる。ＲＲ及びＲＯ手順の詳細については、２００４年のＪｏｈｎｓｏｎ等による文献のセクション５．２、６．１、９．４、９．５に記載されている。

ＲＦＣ４８６６（Ｊ．Ａｒｋｋｏ、Ｃ．Ｖｏｇｔ、Ｗ．Ｈａｄｄａｄ、「Ｅｎｈａｎｃｅｄ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ Ｍｏｂｉｌｅ ＩＰｖ６」、ＲＦＣ４８６６、２００７年５月）には、ハンドオーバ遅延の低減、セキュリティ強化、及び信号オーバヘッドの軽減を実現することを目的とする改良されたルート最適化メカニズムが規定されている。この文献では、セキュリティが強化された、ＲＦＣ３９７２に規定されているように暗号により生成されたホーム・アドレスの、配置が想定されている。ハンドオーバ遅延を低減するために、文献には、ハンドオーバの前にＣＮが取得したＨｏＴキーゲントークンによってのみ署名される「初期バインディング・アップデート」（初期ＢＵ）をハンドオーバ後にＭＮが送信するメカニズムが規定されている。初期ＢＵにはＣｏＴｉメッセージも含まれる。ＣＮは、初期ＢＵを受信すると、使用された署名を検証し、結果が肯の場合には、ＭＮに対し一時的なＢＣＥを設定する。ＣＮはさらに、ＣｏＴｉメッセージに応答を付加する、すなわち、ＣｏＴキーゲントークンを含むバインディング・アップデート確認応答（ＢＡ）を送信する。ＭＮは、ＢＡを受信後、「完全ＢＵ」を生成しＣＮに送信する。ＣＮは、完全ＢＵを受信すると、ＭＮのＢＣＥを更新する。改良されたルート最適化のさらなる詳細については、２００７年のＡｒｋｋｏ等による文献を参照されたい。

ＰＭＩＰｖ６におけるルート最適化
ＰＭＩＰｖ６におけるルート最適化については現時点では規定されていない。しかしながら、そのルート最適化の達成手法は２つのグループに大別される。

なお、ＲＯを行うエンティティが、末端ノードにおけるパケット処理は助けるがインターネット内でのルーティングに影響を与えないＩＰヘッダ・オプションをさらに含むため、ルート最適化パスはルート最適化トンネルと呼ばれることがある。

ＲＲベースのＰＭＩＰ ＲＯ手法
インターネットドラフト（Ｂ．Ｓａｒｉｋａｙａ、Ａ．Ｑｉｎ、Ａ．Ｈｕａｎｇ、Ｗ．Ｗｕ、「ＰＭＩＰｖ６ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」、ｄｒａｆｔ−ｑｉｎ−ｎｅｔｌｍｍ−ｐｍｉｐｒｏ−００．ｔｘｔ、２００８年２月）には、モバイルＩＰｖ６のＲＦＣ４８６６に規定された改良されたルート最適化の、ＰＭＩＰｖ６への適用性について記載されている。ＭＮが接続されているＭＡＧは、ＭＮに代わってＣＮ（又はＣＮのＭＡＧ）とリターン・ルータビリティを行い、「ホーム・キーゲントークン」及び「気付キーゲントークン」を得る。ＭＡＧのＩＰアドレスはＣｏＡとして使用される。また、ＭＡＧは、初期のホーム・テスト後にホーム・テストを一切不要とするよう、暗号により生成されたホーム・アドレスを任意で使用してもよい。ハンドオーバの際、次のＭＡＧに対するホーム・テストを不要とするためハンドオーバ・ホーム・キーゲントークンが使用される。このため、ＭＮのＭＡＧはＣＮ（又はＣＮのＭＡＧ）にＢＣＥを設定する。このような場合、ＣＮからのパケットはＭＮのＭＡＧアドレス（これはＭＮのＣｏＡの役割を果たす）に送信される。ＣＮが移動可能である場合、ＣＮ（又はＣＮのＭＡＧ）がＭＮのＭＡＧにもＢＣＥを設定すると有利である。これはＲＲ手順によって達成し得る。これを図４に示す。実線はＭＡＧ１とＭＡＧ２間のルート最適化パスを示し、点線はＨＡ／ＬＭＡ１及びＨＡ／ＬＭＡ２を介したルート最適化が行われる前のルートを示す。ＭＡＧ１及びＭＡＧ２における吹き出しは、プロキシ・バインディング・アップデートのやり取りが行われた後にこれらエンティティにより設定されたＢＣＥを示す。

さらに、２００８年のＳａｒｉｋａｙａ等に提案されている方法では、新しいＭＡＧにＣＮからのホーム・キーゲントークンを通知して初期ＢＵを送信可能にするため、ＭＮがハンドオーバを実行中に、前のＭＡＧと新しいＭＡＧとの間でコンテキスト転送を行うことが提案されている。結果として、ＭＮのＭＡＧとＣＮのＭＡＧとの間にルート最適化パスが得られる。全手順が末端ノードにトランスペアレントである。

つまり、２００８年のＳａｒｉｋａｙａ等には、ＲＲ手順に基づくＰＭＩＰ ＲＯ手法が提案されている。その利点として、ＭＡＧが信頼関係を有していないことがあっても、ＲＲ手順を通して動的に信頼関係を確立することができることである。

ＬＭＡ−ＭＡＧ間の交換に基づく手法（ＬＭＡベースのＰＭＩＰ ＲＯ）
関与するＬＭＡとＭＡＧ間におけるＲＯ関連のメッセージ交換に基づくＰＭＩＰ ＲＯには別の一般的な手法がある。この異なる特色を持つ一般的な手法は、２００７年のＭ．Ｌｉｅｂｓｃｈ等（Ｍ．Ｌｉｅｂｓｃｈ、Ｌ．Ｌｅ、Ｊ．Ａｂｅｉｌｌｅ、「Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ ｆｏｒ Ｐｒｏｘｙ Ｍｏｂｉｌｅ Ｉｐｖ６」、ｄｒａｆｔ−ａｂｅｉｌｌｅ−ｎｅｔｔｌｍｍ−ｐｒｏｘｙｍｉｐ６ｒｏ−０１．ｔｘｔ、２００７年１１月）、２００８年のＲ．Ｋｏｏｄｌｉ等（Ｒ．Ｋｏｏｄｌｉ、Ｋ．Ｃｈｏｗｄｈｕｒｙ、「Ｌｏｃａｌ Ｆｏｒｗａｒｄｉｎｇ ｉｎ Ｐｒｏｘｙ Ｍｏｂｉｌｅ ＩＰｖ６」、ｄｒａｆｔ−ｋｏｏｄｌｉ−ｎｅｔｌｍｍ−ｌｏｃａｌ−ｆｏｒｗａｒｄｉｎｇ−００．ｔｘｔ、２００８年７月）、及び２００８年のＡ．Ｄｕｔｔａ等（Ａ．Ｄｕｔｔａ等、「Ｐｒｏｘｙ ＭＩＰ Ｅｘｔｅｎｓｉｏｎ ｆｏｒ Ｉｎｔｅｒ−ＭＡＧ Ｒｏｕｔｅ Ｏｐｔｉｍｉｚａｔｉｏｎ」、ｄｒａｆｔ−ｄｕｔｔａ−ｎｅｔｌｍｍ−ｐｍｉｐｒｏ−０１．ｔｘｔ、２００８年７月）に記載されている。これらすべての文献には、１つのＬＭＡ（通信中のＭＮがいずれも同じＬＭＡに接続されている場合）又は複数のＬＭＡ（通信中のＭＮが異なるＬＭＡに接続されている場合）がＰＭＩＰ ＲＯについて決断を下し、ＭＡＧにデータ・パケットを直接転送し合うよう指示するという共通の概念がある。ＲＯトンネルを設定するＭＡＧは同じネットワーク・オペレータの一部であるか、若しくは、少なくともこれらのＭＡＧは互いを信頼しており、データ・パケットを転送するためのセキュリティ・トンネルを相互間に設定できるものとする。

図４のシナリオに基づき、上記手法がどのように機能するのかについての一例を説明することができる。ＬＭＡ１及びＬＭＡ２が、ＭＡＧ１とＭＡＧ２の間でＰＭＩＰ ＲＯが必要であり、実行されるべきであることを何らかの形で発見・合意しうると前提を置く。そして、ＬＭＡはＭＮ及び対応するＭＡＧに関する情報を交換する。例えば、ＬＭＡ２は、ＭＮ１とＭＮ２との間でＰＭＩＰ ＲＯが望まれており、ＭＮ２がＭＡＧ２に接続されていることをＬＭＡ１に報告しうる。

続いて、ＬＭＡ１は、ＭＡＧ１に対するルート更新メッセージを生成し、ＭＡＧ１に、ＭＮ２宛てのパケットをトンネルを介してＭＡＧ２に転送すること開始させる。同様に、ＬＭＡ２はルート更新メッセージをＭＡＧ２に送信し、ＭＡＧ２に、ＭＮ１宛てのパケットをトンネルを介してＭＡＧ１に転送することを開始させる。

ＭＡＧ１及びＭＡＧ２は、ルート更新メッセージを処理した後、ＭＮ１‐ＭＮ２間のトラフィックのためにパケットの相互トンネリングを開始する。

このようなＬＭＡ間のＰＭＩＰ ＲＯに関する詳細な説明は、２００８年のＤｕｔｔａ等のセクション４．２．を参照されたい。この段落に説明されている手法は、「ＬＭＡベースのＰＭＩＰ ＲＯ」とも呼ぶことができる。

２００８年のＢ．Ｓａｒｉｋａｙａ等に記載のＲＲベースの手法、及び、２００８年のＬｉｅｂｓｃｈ等、２００８年のＫｏｏｄｌｉ等、２００８年のＤｕｔｔａ等に記載のＬＭＡ−ＭＡＧ交換ベースの手法はいずれも、ＰＭＩＰドメインに位置するＭＮがネットワーク・ベース・モビリティ方式からホスト・ベース・モビリティ方式へ、若しくはその逆に変更する場合を考慮していない。

本願ではこの後者シナリオに明らかに着目している。従来の出願では、２００８年のＢ．Ｓａｒｉｋａｙａ等に記載されている概念がＰＭＩＰｖ６におけるＲＯの設定方法として想定されていた。

本発明ではこの後者のシナリオに明らかに着目している。ＰＭＩＰｖ６におけるＲＯの設定方法として２００８年のＢ．Ｓａｒｉｋａｙａ等に記載されている概念がすでに想定されているが、本願では上記文献に示される手法も考慮されている。

図５に、本発明で検討するシナリオを示す。図５において、ＣＮも移動可能でありうるので、２００４年のＪｏｈｎｓｏｎ等にも示されているように、ＣＮの役割はＭＮ２で示される。実施例においてはＭＮ１及びＭＮ２は異なるＰＭＩＰｖ６ドメインに位置するものとするが、本発明はＭＮ１及びＭＮ２が同じＰＭＩＰｖ６ドメインに位置する場合にも適用可能である。移動前において、ＰＭＩＰｖ６のＲＯがＭＮのＭＡＧとＣＮのＭＡＧの間に設定されている。ＭＮ及びＣＮはＲＯパスに気付いていない。ＭＮは、ＰＭＩＰドメイン外へ移動した場合、そのホーム・エージェントへＭＩＰｖ６トンネルを設ける。しかしながら、ＣＮのＭＡＧは、ＭＮの以前のＭＡＧへデータ・パケットをルーティングし続けるため、結果としてデータ・パケット損失が起きる。

さらに、ＭＮがＰＭＩＰドメイン外にハンドオーバを行った後、データ・パケットがどうにかホーム・エージェントに転送されたとすると、ｅｎｄ−ｔｏ−ｅｎｄ遅延が大幅に増加し、その結果トランスポート層で再送タイムアウトが生じうる。

本発明は、データ・パケットがＭＮのＭＡＧからＣＮ（又は必要に応じてＣＮのＭＡＧ）への最適なルートを取るよう、ＭＡＧが、ＰＭＩＰドメインのＭＮに代わってプロキシ・ルート最適化を設定するシナリオに関する。ＲＯを両方向に機能させるため、ＣＮ（又はＣＮのＭＡＧ）はＲＯも開始し、ＭＮのＭＡＧにＢＣＥを設定してもよい。ＭＮがＰＭＩＰドメインから移動し、ＨＡ／ＬＭＡとＭＩＰｖ６登録を行った場合、ＣＮのデータ・パケットはＭＡＧに到着するため失われる。従って、ＣＮがＭＮのＨｏＡへのデータ・パケットの転送を開始できるよう、ＣＮのＢＣＥを遅延なく更新する、つまり、ＭＮのＢＣＥを削除する手段が必要となる。しかしながら、たとえこの最適化が実施されたとしても、データ・パケットは非最適パス上をルーティングされることとなり、結果としてｅｎｄ−ｔｏ−ｅｎｄ遅延が増大してしまい、アプリケーションのパフォーマンスに影響を与えてしまうこともある。特に、ＭＡＧ―ＬＭＡ間の距離が長い場合、ハンドオーバを行う前のルート最適化パスの往復時間が、ハンドオーバ後の非最適パスの往復時間よりもかなり短いことがある。このような場合、最適化ルートから非最適パスへの移行によりトランスポート・プロトコル・タイムアウトが生じ、ひいてはアプリケーションのパフォーマンスの劣化を引き起こすこともある。

本発明が対象とする主な問題は、ＭＩＰモビリティ・ドメインと比べて、ハンドオーバのアプリケーションへの影響の増大を回避すること、例えば、ＲＦＣ４８６６と同様の性能を実現することにある。

本発明は、上述した事情を考慮してなされたものであり、ＭＮがＰＭＩＰドメインとＭＩＰｖ６との間でハンドオーバを行う場合のパケット損失を防止すること、またデータ・パケットのｅｎｄ−ｔｏ−ｅｎｄ遅延を低減することを目的とする。

上記目的は独立クレームによって達成される。本発明の好ましい実施の形態は従属クレームの対象である。

本発明は、上記目的を達成するため、モバイル・ノード、モバイル・アクセス・ゲートウェイ、通信相手ノード、及びホーム・エージェントを少なくとも備えるパケット交換通信ネットワークにおける、ネットワーク・ベース・モビリティ対応アクセス・ネットワークとネットワーク・ベース・モビリティ非対応アクセス・ネットワークとの間でのモバイル・ノードのハンドオーバ方法、モバイル・ノード、モバイル・アクセス・ゲートウェイ、ホーム・エージェント、及び、通信システムを提供する。その方法は、モバイル・ノードに代わって通信相手ノードに対してプロキシ・ルート最適化を行うステップと、現在のアクセス・ネットワークから対象のアクセス・ネットワークへハンドオーバを行うステップと、ハンドオーバ後にプロキシ・ルート最適化を行う必要があるか否かを判断するステップとを含む。ハンドオーバ後にプロキシ・ルート最適化が必要な場合、リターン・ルータビリティに基づくルート最適化を実行するか、ホームに基づくルート最適化を実行するかを判断し、リターン・ルータビリティに基づくルート最適化を実行する場合、プロキシ・ルート最適化に関する情報がホーム・エージェントによってモバイル・ノードに送信される。ホーム・エージェントに基づくルート最適化を実行する場合、上記方法は、モバイル・ノードのホーム・エージェントによってモバイル・ノードのルート最適化状態を生成及び管理するステップと、通信相手ノードのルーティング状態をモバイル・ノードの新しい位置で更新するステップとをさらに含む。

さらに好ましい実施の形態では、モバイル・ノードにおいてルート最適化状態を生成及び管理した後、通信相手ノードが同じホーム・エージェントに接続されている場合、ホーム・エージェントはモバイル・ノードの新しい位置を通信相手ノードに登録し、通信相手ノードのホーム・エージェントがモバイル・ノードのホーム・エージェントと異なる場合、モバイル・ノードのホーム・エージェントは通信相手のホーム・エージェントに新しいモバイル・ノードの位置を通知し、通信相手ノードのホーム・エージェントは通信相手ノードのルーティング状態を更新する。

本発明の更なる実施の形態は、ホーム・エージェントが、プロキシ・ルート最適化に関する情報をモバイル・ノードに送信した後、モバイル・ノードが通信相手ノードのルーティング状態を更新する。

本発明の更なる実施の形態において、ハンドオーバ後にプロキシ・ルート最適化を行う必要があるか否かを判断した後、ハンドオーバ後にプロキシ・ルート最適化を行う必要がない場合に、モバイル・アクセス・ゲートウェイ又はホーム・エージェントは、通信相手ノード又は通信相手ノードのモバイル・アクセス・ゲートウェイとのプロキシ・ルート最適化の登録を取り消す。

本発明の別の好ましい実施の形態は、ホーム・エージェントによってモバイル・アクセス・ゲートウェイのルーティング状態が更新される。

更に好ましい実施の形態によれば、モバイル・ノード、通信相手ノード、ホーム・エージェント、及びモバイル・アクセス・ゲートウェイ間での通信を可能にするシグナリングは、ルート最適化シグナリングにより実行される。更に好ましい実施の形態では、ルート最適化シグナリングには完全性保護又は暗号化が利用される。

更なる特徴及び利点は、以下の説明及び添付図面に示される様々な実施の形態のより具体的な説明から明らかとなる。
初期接続時のＰＭＩＰｖ６の例示的な信号フローを示す図である。 ＭＡＧ間ハンドオーバ時のＰＭＩＰｖ６の例示的な信号フローを示す図である。 ＭＩＰｖ６ルート最適化シグナリング・メッセージとそれらのフォーマットを示す図である。 ＰＭＩＰｖ６におけるプロキシ・エンティティ（ＭＡＧ１及びＭＡＧ２）間のＲＯの例を示す図である。 本発明で想定される、ＭＮがＰＭＩＰｖ６ドメインを出てアクセス・ルータへ移動し、モビリティのためにＭＩＰｖ６を利用するシナリオを示す図である。 ＭＡＧ１とＬＭＡ１との間でコンテキスト転送を事前に（ハンドオーバの前に）行う場合の信号フローを示す図である。 ＭＡＧ１とＬＭＡ１との間でコンテキスト転送を反動的に（ハンドオーバの後に）行う場合の信号フローを示す図である。 本発明の一実施の形態のフロー図である。 ＨＡがＭＮ及びＭＡＧのＲＯ状態を管理する場合の実施の形態の信号フローを示す図である。 本発明の一実施の形態のフロー図である。

以下の段落で、ネットワーク・ベース・モビリティからホスト・ベース・モビリティへのハンドオーバ時におけるルート最適化の継続性を含む本発明の様々な実施の形態について説明する。さらに、別の構成についても説明する。

単なる例示の目的で、ほとんどの実施の形態は、ＭＩＰｖ６通信システムと関連して概説され、以下のセクションで使用する用語はＭＩＰｖ６の用語に関連するものである。しかし、ＭＩＰｖ６アーキテクチャに関する、使用される用語及び実施の形態の説明は、上記システムの本発明の原理や概念を限定するものではない。

前述の技術背景のセクションでなされた詳細な
説明は、以下で説明されるほぼＭＩＰｖ６に限定された例示的実施の形態をより良く理解することを意図するものであり、本発明を、モバイル通信ネットワークにおける説明された特定のプロセッサ及び機能の実装に限定するものであると解釈されるべきではない。

ホスト・ベース（モバイルＩＰｖ６プロトコル、ＭＩＰｖ６として知られる）やネットワーク・ベース（プロキシ・モバイルＩＰｖ６プロトコル、ＰＭＩＰｖ６として知られる）などの異なるモビリティ管理方式は、データ・ネットワーク内のモバイル・ノード（ＭＮ）の移動中にセッションの継続性をサポートするために適用可能である。ホスト・ベースのモビリティ方式では、ＭＮと通信相手ノード（ＣＮ）との間でルート最適化が設定されＭＮにより管理される。一方、ネットワーク・ベースのモビリティの場合、モビリティ関連のシグナリングをネットワーク・エンティティにより管理することが目的であるため、ルート最適化はＭＮのプロキシ・モビリティ・エンティティ（例えば、モバイル・アクセス・ゲートウェイ、ＭＡＧ）とＣＮとの間に設定される。従って、モビリティ方式によって、異なったエンティティがＣＮとのルート最適化を管理している。ここで、ＭＮが上記２つのモビリティ方式間でハンドオーバを行い、ルート最適化がハンドオーバの前に設定された場合、利用可能な先行技術によれば、ルート最適化パスを断ち切らなければならない。

ルート最適化シグナリングという用語は、一般的に、ルート最適化情報を運ぶシグナリングを意味している。このシグナリングは、状況によって多少異なる特定の影響力を持つ場合もある。ＲＦＣ３７７５及びＲＦＣ４８６６に従ったＭＩＰｖ６ルート最適化の場合、ルート最適化シグナリングは、ＭＮとＣＮ間のＲＲシグナリングを含む。本願の文脈及び上述のようなＲＲベースのルート最適化においては、ルート最適化シグナリングは、ルート最適化情報を運ぶＨＡ及びＭＮ間のシグナリング（拡張ＢＡ又は拡張ＧＳＭシグナリング）を含む。ＨＡベースのルート最適化の場合では、ルート最適化シグナリングは、ＨＡとＭＮ間及びＨＡとＣＮ間の拡張ＢＡ又は拡張ＧＳＭシグナリングを意味している。

本願には、ＭＮがホスト・ベース・モビリティ・ドメインへのハンドオーバ中に、ＭＮが、ネットワーク・ベース・モビリティ・ドメインに設定されたプロキシ・ルート最適化を保持できるようにする方法が開示されている。これを達成するために、ＭＡＧによって設定されたＣＮとのプロキシ・ルート最適化についてＭＮに報告する。この報告は、ＭＮのＭＩＰｖ６登録プロセス中、すなわち、ホーム・エージェント（ＨＡ）とのバインディング・アップデート（ＢＵ）及びバインディング確認応答（ＢＡ）メッセージの交換中に行われる。また、ＨＡは、ＭＮがホスト・ベース・モビリティ・ドメインからルート最適化を行うのに必要な情報を記憶する。ＨＡがプロキシ・ルート最適化に関する情報をＭＮに送信するので、ＨＡによるルート最適化と呼ぶことができる。ＭＮはいずれかのＣＮとルート最適化を開始するかどうかについて測定を行ったり決断を下したりする必要がない。

本願には、ＭＮがホスト・ベース・モビリティ・ドメインへのハンドオーバ中に、ＭＮがＰＭＩＰドメインに設定されたＲＯパスを保持できるようにする方法が開示されている。これを達成するために、ＨＡは、ＭＮのＭＡＧが関与している現在のプロキシ・ルート最適パスのそれぞれについてＭＮに報告する。この報告は、ＭＮのＭＩＰｖ６登録プロセス中、すなわち、ＨＡとのバインディング・アップデート（ＢＵ）及びバインディング確認応答（ＢＡ）メッセージの交換中に行われる。プロキシＲＯ関連情報は、ＣＮのアドレスと、任意的に、ＭＮのＭＡＧによって行われるプロキシＲＲ手順中にＣＮによって生成されるＨｏＴキーゲントークンとを運ぶ拡張ＢＡメッセージで運ばれる。ＭＮは、この情報を利用して、ＭＩＰ登録後直ちにＣＮのＢＣＥを更新できる。また、ＨＡはＭＮが必要とするプロキシＲＯ関連情報を記憶する。本発明では、ＬＭＡをＭＮごとにルート最適化パスが更新された状態とするために、ＭＡＧとＬＭＡとの間でメッセージを交換するメカニズムが記載されている。ＨＡがＲＯ関連情報をＭＮに送信するので、ＨＡによるＲＯと呼ぶことができる。ＭＮはいずれかのＣＮとＭＩＰｖ６ＲＯを開始するかどうかについて測定を行ったり決断を下したりする必要がない。

図８は、本発明の方法の高レベルフローチャートである。ステップ８０２において、モバイル・アクセス・ゲートウェイ（ＭＡＧ）はモバイル・ノード（ＭＮ）に対してプロキシ・ルート最適化（ＰＲＯ）を行う。ＭＮは、ステップ８０４に示すように、ネットワーク・ベース・モビリティ方式とも呼ばれるネットワーク・ベース・モビリティ対応アクセス・ネットワークからホスト・ベース・モビリティ方式とも呼ばれるネットワーク・ベース・モビリティ非対応アクセス・ネットワークへ移動した場合にハンドオーバを行う。このハンドオーバを行った後、ステップ８０６において、プロキシ・ルート最適化を保持又は維持するかどうか判断しなければならない。一般にＭＡＧがこの判断を下すことになる。一実施の形態では、ホーム・エージェント（ＨＡ）がこの判断を下しており、この場合はＭＡＧは判断を下さない。

ＰＲＯが維持されない場合、ＣＮからＭＮのＢＣＥを削除するため、ＭＡＧはＣＮからＭＮの登録を取り消すための処置をとる。そのような登録取消が行われた後、ＣＮはＭＮのＨｏＡへパケット転送を開始する、すなわち、パケットがＬＭＡ／ＨＡに到着する。

一方、ＰＲＯが維持される場合、ステップ８０８において、ＨＡはＰＲＯに関する情報をＭＮに送信する。その後、ステップ８１０において、ＭＮはモバイルＩＰ登録が行われた後に通信相手ノード（ＣＮ）のバインディング・キャッシュ・エントリ（ＢＣＥ）を更新する。

本発明の概念を以下にさらに詳しく説明する。

図５に示すように、初期の時点で、ＭＮ１ ５０２及びＭＮ２ ５０８に対応するＭＡＧ１ ５０４とＭＡＧ２ ５０６との間にＰＭＩＰｖ６ルート最適化パスが設けられているものとする。さらに、ＭＡＧ１ ５０４とＭＡＧ２ ５０６は、各ルート最適化パスに対して、複数のバインディング・キャッシュ・エントリ（ＢＣＥ）を維持するものとする。ＭＡＧ１ ５０４とＭＡＧ２ ５０６は、互いのＢＣＥを更新できる。ＢＣＥを更新する方法の一つとして、２００７年のＱｉｎ等に記載されているプロキシＲＲ及びＲＯ手順を使うことが考えられるが、他の方法も可能である。上記提示された解決法は、ＭＡＧ１ ５０４とＭＮ２ ５０８との間にＲＯパスが設けられた場合にも有効である。図５には、ＭＮ１ ５０２とＭＮ２ ５０８が別々のＰＭＩＰｖ６ドメインに接続されている様子が示されているが、上記提案された解決法は、両ノードが同じＰＭＩＰｖ６ドメインに接続されている場合にも適用可能である。

ＲＲベースのＰＭＩＰ ＲＯ
ＭＮ１ ５０２は、ＰＭＩＰｖ６ドメイン外へ移動した後、ＨＡ５１０とＭＩＰｖ６登録手順を開始する。ＭＮ１ ５０２は、ＨＡ発見を行いＨＡ５１０とのセキュリティ・アソシエーションを確立すると、ＢＵを送信できる状態になる。

本願の一実施の形態において、ＰＭＩＰドメイン内の可能なプロキシによって取得されうる既存のプロキシ・ルート最適化パスに関する要求情報を含む拡張ＢＵがＭＮ５０２によって送信されるものとする。２００７年のＧｕｎｄａｖｅｌｌｉ等の明細書によれば、ＭＮ５０２はＰＭＩＰエンティティの存在に気付いていないので、ＭＮのモビリティを支援するプロキシ・エンティティ（例えば、ＭＡＧ）の存在を示唆することしかできない。上記要求情報は以下のいずれかである。
例えば「プロキシＲＯ」（Ｐ−ＲＯ）と呼ばれるフラグ、又は
ＭＮが現在通信を行っているＣＮのＩＰアドレス（例えば、ＣＮのホーム・アドレス）

ＭＮ５０２は上記要求情報を他の方法で示してもよい。また、ＭＮ５０２は２００４年のＪｏｈｎｓｏｎ等に記載の標準ＢＵを送信してもよい。

ＭＮ５０２は、ＨＡ５１０に拡張ＢＵを送信するか標準ＢＵを送信するかを判断する決定メカニズムを実装していてもよい。現在の最新技術によれば、ＭＮ５０２はネットワーク側のＰＭＩＰｖ６機能の存在に気付かない。言い換えれば、ＭＮ５０２はネットワーク内のＭＡＧ及びＬＭＡエンティティの存在に気付いていない。上記決定メカニズムは以下の通りである。
ＭＮ５０２がＰＭＩＰｖ６機能の存在を認識する何らかの手段を有し、ＰＭＩＰｖ６からＭＩＰｖ６ネットワークへのハンドオーバを行う場合、ＭＮ５０２は拡張ＢＵをＨＡ５１０に送信してもよい。
ＭＮ５０２は、ＰＭＩＰドメイン機能を認識していない場合、例えばホームから外部リンクへのハンドオーバを行う際はいつも拡張ＢＵを送信してもよい。
ＭＮ５０２は、上記以外の場合、標準ＢＵをＨＡ５１０に送信する。

ＨＡ５１０は、ＭＮ５０２からＢＵを受信すると、まず、ＢＵが（ＲＯ要求情報を含む）拡張されたものであるか、標準ＢＵであるかをチェックする。
ＢＵが拡張されたものである場合、ＨＡ５１０は（もしあれば）プロキシＲＯ関連情報を拡張ＢＡで提供しなければならない。ＨＡ５１０は、ＬＭＡ機能を実装しており、ＭＮ５０２がハンドオーバの前にこのＬＭＡ５１０に接続されていた場合にのみプロキシＲＯ関連情報を処理可能である。
ＢＵが標準ＢＵである場合、ＨＡ／ＬＭＡ５１０は、プロキシＲＯ関連情報がＭＮ５０２に使用可能であれば、その情報の拡張ＢＡでのシグナリングを確実にする責任がある。ＨＡ５０２は、ＭＮ５０２がすでにＬＭＡに登録されているかどうか、またそのＭＮ５０２にはプロキシ・ルート最適化パスがあるかどうか、ＬＭＡデータベースを調べる。そうである場合には、ＨＡ／ＬＭＡ５１０は拡張ＢＡにプロキシＲＯ関連情報を組み込み、ＭＮ５０２に返送する。

ＭＮ５０２がＬＭＡのデータベースに存在しない場合、又は、ＰＭＩＰｖ６ドメインにはこのＭＮ５０２に関するプロキシＲＯ関連情報が記憶されていない場合、ＨＡ／ＬＭＡ５１０は標準ＢＵ（プロキシＲＯ関連情報なし）又はプロキシＲＯ情報が存在しないという情報を含む拡張ＢＡで返答する。後者は、例えば、負状態に設定されたプロキシＲＯ「Ｐ−ＲＯ」フラグであってもよい。

ＨＡ／ＬＭＡ５１０は、ＭＮ５０２に関するプロキシＲＯ関連情報を有する場合、正状態に設定された「Ｐ−ＲＯ」フラグとプロキシＲＯ関連情報を含む拡張ＢＵで返答する。プロキシＲＯ関連情報には、ＲＯセッションが存在するＣＮのＩＰアドレスが含まれている。ＨＡ５１０は、所定のＣＮ５０８がＭＡＧ５０６に接続されていることを把握している場合、ＣＮのＣｏＡとしてＭＡＧのＩＰアドレスを含む。さらに、拡張ＢＡには、特定のＣＮとの各ＲＯセッションに対するＨｏＴキーゲントークンが含まれている。

なお、ＬＭＡはＭＮのＢＣＥを、ＭＡＧによるこのＭＮの登録取消後直ちに削除しないので、本発明では、２００７年のＧｕｎｄａｖｅｌｌｉ等に記載のようにＬＭＡの動作が変更される。ＬＭＡはあらかじめ定められた時間ＢＣＥエントリを非アクティブ状態（すなわち、ＭＡＧへのデータ・パケットの転送に使用されない）にする。この時間の経過後、ＬＭＡはＢＣＥを削除する。この動作は、ＨＡ／ＬＭＡに、ＭＮからＭＩＰｖ６登録が到着する前に、ＭＡＧからＰＭＩＰｖ６登録取消が到着する場合、必要となる。

プロキシＲＯ関連情報を持たない標準ＢＡを受信すると、ＭＮ５０２は２００４年のＪｏｈｎｓｏｎ等に記載のような標準ＭＩＰｖ６モバイル・ノードとして機能する。しかしながら、ＭＮ５０２は、プロキシＲＯ関連情報を含む拡張ＢＡを受信した場合、拡張ＢＡにリストアップされたＣＮによりＲＯを開始する。拡張ＢＡに所定のＣＮのＣｏＡが含まれる場合（すなわち、ＭＡＧ１がＣＮのＭＡＧでもあり得るＣＮのＣｏＡに対してＲＯを設定する、若しくはＣＮが外部ネットワークに存在し、ＣｏＡを設定した場合）、ＭＮ５０２はＣＮに一時的なＢＣＥを作成しなければならない。

ＲＯ登録遅延を軽減するため、本発明の好ましい実施の形態では、ＭＮ５０２がＨＡ５１０からの拡張ＢＵで報告された各ＣＮに初期ＢＵを送信する。このため、ＭＮ５０２は自身の新しいＣｏＡでＣＮのＢＣＥを更新することとなる。初期ＢＵには、バインディング管理鍵（Ｋｂｍ）が含まれている。各ＣＮに対する初期ＢＵ内のＫｂｍは、拡張ＢＡに含まれる各ＨｏＴキーゲントークンに基づいて生成される。ＭＮ５０２は拡張ＢＡで報告されたＣＮアドレスにこの初期ＢＵを送信する。ＭＮ５０２は、拡張ＢＡで報告されたＣＮアドレスがＣｏＡであるためＢＣＥを作成する場合、初期ＢＵをＣＮのＣｏＡに送信する。

本発明の別の実施の形態では、ＭＮ５０２は、拡張ＢＡを受信後、ＣＮ５０８とＲＲ手順を開始し、ＣＮ５０８のＢＣＥを作成／更新するためＢＵを連続して送信する。本実施の形態には、ＭＮ５０２がＣＮへＢＵを送信するより先にＲＲ手順が完了していなければならないため、ＣＮのＢＣＥの更新には大きな遅延が生じるという欠点がある。

それに対して、上述した好ましい実施の形態では、ＭＮ５０２は拡張ＢＡの受信直後に初期ＢＵを送信する。なお、初期ＢＵはＣＮ５０８の一時的なＢＣＥのみを設定するだけである。ＲＲ手順はその後に行われるべきであって、完全なＢＵはＣＮ５０８に送信されなければならない。

なお、本願では、他のノード（これは上記説明では他のＣＮを指す）へパケットをルーティングするためのＢＣＥ作成に関連して、ＭＮ５０２の動作が変更される。２００４年のＪｏｈｎｓｏｎ等には、通信相手ノードによって有効なＢＵを受信後、ＭＮがその通信相手ノードに対してＢＣＥを作成することが記載されている。本発明では、ＭＮ５０２は、ＨＡ５１０から受信した拡張ＢＡに含まれる情報に基づいてＢＣＥを作成することができる。拡張ＢＡに所定のＣＮ５０８のＣｏＡが含まれる場合、ＭＮ５０２はそのＣＮ５０８の一時的なＢＣＥを作成しなければならない。

このセクションでは、上記メカニズムに対する正確な信号フローについて２つの例が示されている。これら２つの例は図６及び図７を用いて示されている。両図に太字のイタリック体でハイライトされているテキストは、既存のメッセージ・フォーマットでの新しいメッセージ又は新しいオプションを示している。

図６に上記信号フローを示す。なお、図５と同様に想定されている、すなわち、ＭＮ５０２及びＣＮがそれぞれＭＮ１ ５０２とＭＮ２に対応するものとして示され、ＭＡＧ１ ５０４とＭＡＧ２ ５０６との間にＲＯが設定されることに留意されたい。本発明では、ＭＡＧ１ ５０４がＭＡＧ１−ＭＡＧ２間ルート最適化パスをどのようにＨＡ／ＬＭＡ５１０に報告するのかに関して２つのオプションが説明されている。図６の上部には、ＭＡＧ１ ５０４とＬＭＡ１ ５１０間の、事前コンテキスト交換と呼ばれる情報交換のオプション１が示されている。ここで、ＭＡＧ１ ５０４は、ＲＯパス設定完了直後にＭＮ１ ５０２のＭＡＧ１−ＭＡＧ２間ルート最適化パスをＬＭＡ１ ５１０に報告する。ＭＡＧ１ ５０４はＭＮのＲＯセッションに関する完全な情報（以下、この情報を「プロキシＲＯ関連情報」と呼ぶ）を送信し、ＬＭＡ１ ５１０はこの情報をＭＮ１の拡張されたバインディング・キャッシュに記憶する。図６では、上記交換は、「ＭＡＧ１−ＬＭＡ１間コンテキスト交換」と呼ばれるボックスとして示されている。ＭＡＧ１ ５０４から送信されＬＭＡ１ ５１０に記憶されるプロキシＲＯ関連情報の一例は以下のとおりである。
少なくともＣＮのアドレスが含まれている。ＲＯパスがＣＮに直接設定された場合、ＬＭＡ５１０はＣＮのＩＰアドレスだけを記憶する。ＲＯパスがＣＮのＣｏＡに設定された場合、ＣＮはＭＩＰｖ６を使用するので、ＬＭＡ１ ５１０はＣＮのＨｏＡとＣｏＡ間のバインディング（例えば、データ構造は以下のようになる：ＭＮ２＿ＨｏＡ−＞ＭＡＧ２＋「Ｐｒｏｘｙ」フラグ）を記憶する。ＲＯパスがプロキシとして機能するＣＮのＭＡＧ５０８に設定された場合、ＬＭＡ１ ５１０はＭＮ２のＣｏＡとしてＭＡＧ２のＩＰアドレスと、ＭＡＧ２ ５０６がプロキシであるという情報（例えば、データ構造は以下のようになる：ＭＮ２＿ＨｏＡ−＞ＭＡＧ２＋「Ｐｒｏｘｙ」フラグ）を記憶する。上記「Ｐｒｏｘｙ」フラグは、ＭＡＧ５０６がＭＮ２のプロキシとして機能していることを示している。
ＭＡＧ１ ５０４は、各ＭＮのＲＯパスに、ＭＡＧ２ ５０６によって生成されたＨｏＴキーゲントークンを送信してもよい。ＬＭＡ１ ５１０は、各ＭＮについて、ＲＯパスごとのＨｏＴキーゲントークンを記憶しなければならない。

プロキシＲＯ関連情報は、拡張ＢＡメッセージを介して、ＭＮ５０２へと送られる。オプション１のプロキシＲＯ関連コンテキスト交換は、ＭＮ５０２がハンドオーバを行うことを予測可能かどうかに関係なく、プロキシ・エンティティ（これは本例ではＭＡＧ１ ５０４）に基づくＲＯパスの設定後はいつも実行される。

図６にはさらに、ＬＭＡ１ ５１０からＭＮ５０２へ拡張ＢＡが送信された後、ＬＭＡ１ ５１０がＭＡＧ１ ５０４に登録取消メッセージを送信することが示されている。この登録取消メッセージは、プロキシＢＡ（ＰＢＡ）であってもよい。ＰＢＡには、ＭＡＧ１ ５０４に受信データ・パケットをＬＭＡ５１０へ転送するよう要求する情報（例えば、フラグ）が含まれていてもよい。この情報は、ＭＮ１ ５０２がＭＮ２の（又はＭＡＧ２の）ＢＣＥを更新する際に起こり得るパケット損失を回避するために必要である。

ＭＮ１ ５０２は、拡張ＢＡを受信後、自身のＣＮとの既存のプロキシＲＯパスの存在を認識する。拡張ＢＡに所定のＣＮ、例えば図６に示すＭＮ２のＣｏＡが含まれている場合、ＭＮ５０２は、このＣＮのＨｏＡとＣｏＡとを結び付けるＣＮに一時的なＢＣＥを作成しなければならない。

以上のように、ＭＮ５０２がＣＮのＢＣＥを迅速に更新するために初期ＢＵをＭＮ２へ送信することは有効である。拡張ＢＡにはＭＮ２のＣｏＡとしてＭＡＧ２のアドレスが含まれているので、ＭＮ１ ５０２は初期ＢＵをＭＡＧ２ ５０６へ直接送信する。ＭＡＧ２ ５０６は、初期ＢＵを受信すると、ＭＮ１のＢＣＥを更新し、ＡＲにおけるＭＮのＣｏＡに直接データ・パケットを送信し始める。その後、ＭＮ１ ５０２はＭＡＧ２ ５０６とＲＲ手順を行い、新しいＨｏＴ及びＣｏＴキーゲントークンを取得し、ＭＡＧ２ ５０６へ完全なＢＵを送信する。

ＭＮ１ ５０２がＭＡＧ２ ５０６のＢＣＥを更新した後、ＭＡＧ２ ５０６は、ＭＮ５０２の一時的なＢＣＥを更新するためＲＲ及びＲＯ手順も実行する必要があるということを検出するための論理を実装してもよい。通常、ＭＡＧ２ ５０６は、ＭＡＧ１ ５０４からのＨｏＴ及びＣｏＴキーゲントークンの寿命が終わる前にＲＲ及びＲＯ手順を開始する。しかしながら、ＭＡＧ１ ５０４はもはやＲＯプロセスに関与していないので、ＭＡＧ２ ５０６がキーゲントークンをＭＮ１ ５０２から取得しなければならない。従って、ＭＡＧ２ ５０６は、ＭＮ１ ５０２がプロキシＲＯからＭＩＰｖ６ ＲＯへと移行するかどうかを検出する機能を実装していてもよい。

ＭＡＧ２ ５０６がプロキシ・モビリティ・エージェント（例えばＭＡＧ１など）によって作成されたＢＣＥに「プロキシＲＯ」フラグを持っているとすると、ＭＡＧ２ ５０６は、「プロキシＲＯ」フラグを持たない新しいクライアントＢＵの受信に基づき、プロキシＲＯからＭＩＰｖ６ ＲＯへの移行を判断できる。ＭＡＧ２ ５０６によって開始されるＲＲ及びＲＯ手順を、図６の下部に太字のイタリック体で示す。

本願では、図７の信号フローに示される、ＭＡＧ１ ５０４とＬＭＡ５１０の間のコンテキスト交換の第２オプションが定義されている。本発明では、ＭＡＧ１ ５０４とＬＭＡ１ ５１０間のコンテキスト交換はＭＮ５０２がＰＭＩＰｖ６ドメインから移動しＨＡ／ＬＭＡ５１０にＢＵを送信した後に行われるので、上記第２オプションは反動的コンテキスト交換と呼ばれる。

このシナリオでは、ＬＭＡ１ ５１０はハンドオーバ実行前にはプロキシＲＯ関連コンテキストを保持していない。ＭＮ１ ５０２が「Ｐ−ＲＯ」フラグを持つ拡張ＢＵ、又は、標準ＢＵを送信した後、ＬＭＡ１ ５１０はまずＭＡＧ１ ５０４に登録取消メッセージを送信し、さらにプロキシＲＯ関連コンテキストを要求する。この登録取消メッセージは、プロキシＢＡ（ＰＢＡ）であってもよく、（ＭＮからＨＡへと送られる拡張ＢＵと同様に）ルート最適化の要求情報を含むよう拡張されていてもよい。ＭＡＧ１ ５０４は、登録取消メッセージとプロキシＲＯ関連情報の要求を受信後、所定のＭＮ５０２のＲＯパス（これは本例ではＭＮ１ ５０２であり、ＲＯパスはＭＡＧ１ ５０４とＭＡＧ２ ５０６との間のパスである）をＬＭＡ１ ５１０に通知する。ＬＭＡ５１０に送信された情報には、オプション１と同様のプロキシＲＯ関連情報（すなわち、ＣｏＡであり得るＣＮのアドレス、及び、ＨｏＴキーゲントークン）が含まれている。ＭＡＧ１ ５０４は、ＭＮ１ ５０２へのデータ・パケットをＬＭＡ１ ５１０へ転送し始める。ＨＡ／ＬＭＡ５１０は、ＲＯ関連情報を受信後、上述のように、拡張ＢＡをＭＮ１ ５０２に送信する。図７の残りの部分は図６と同様である。

オプション１と比べて、オプション２には、ＨＡ／ＬＭＡ１が拡張ＢＣＥデータベースを実装しなくてもよく、プロキシＲＯ関連情報を記憶しなくてもよいという利点がある。さらに、ＭＮ１がプロキシＲＯパスの期間中ＭＡＧ１から動かない場合、ＭＡＧ１とＨＡ／ＬＭＡ１間においてコンテキスト交換やプロキシＲＯ関連シグナリングは必要ない。しかしながら、オプション２には、拡張ＢＡのＭＮ１への送信の際の遅延が（オプション１と比較して）増大してしまい、その結果ＭＩＰｖ６登録の遅延も増大してしまうといった欠点がある。

ＨＡベースのクライアントＲＯの詳細な説明
以上説明したいくつかの解決方法の特徴は、ＰＭＩＰ ＲＯがＬＭＡ−ＭＡＧ間におけるルーティング・アップデート・メッセージの交換に基づくものである、すなわち、いわゆるＬＭＡベースのＰＭＩＰ ＲＯである場合には有効でなくなる。そのような特徴を以下に示す。
ＭＡＧ間のＰＭＩＰ ＲＯがＭＩＰｖ６ ＲＲに基づいていない。従って、ＭＡＧ１−ＭＡＧ２間のＲＯにＨｏＴ／ＣｏＴキーゲントークンが使用されていない。その代わりに、ＬＭＡ１及びＬＭＡ２がＭＡＧ１及びＭＡＧ２のルーティング状態を更新する。
ＬＭＡがＰＭＩＰ ＲＯを開始するので、ＬＭＡはＭＡＧ１−ＭＡＧ２間ＲＯについて把握しており、図６の第１ステップに示したように、ＭＡＧがＬＭＡにＰＭＩＰ ＲＯについて報告する必要がなくなる。
ＨｏＴキーゲントークンがＰＭＩＰ ＲＯに使用されていないため、ＨＡはそのような情報を持っておらず、拡張ＢＡを介してＭＮ１に情報を送信できない。さらに、ＭＮ１は初期ＢＵをＭＡＧ２に送信できない。
ＭＡＧ２のＢＣＥがＭＩＰｖ６ ＲＲに基づいて作成されない（でＬＭＡ２から受信したルート更新メッセージに基づいて作成される）ので、ＭＡＧ２はＭＮ１との共有鍵を持っていない。ＭＡＧ２は（初期ＢＵなどの）更新メッセージをＭＮ１から受け付けない。

この節では、ＰＭＩＰ ＲＯのＬＭＡ−ＭＡＧ間の交換に基づくシナリオを対象とする変形解決方法について詳細に説明する。このシナリオを対象とするために、完全にＨＡに基づいてＭＮのＲＯに対するＢＣＥの管理（すなわち、作成、保持、及び削除）するための解決方法について説明する。

ＭＮ及びＨＡはセキュリティ・アソシエーションを有しており、互いを信頼しているので、ＨＡは、ＲＯのＢＣＥを管理するためのメッセージをＭＮに送信できる。そのようなメッセージはＭＩＰｖ６のセキュリティ・モデルに影響を与えるものではない。特に、ＨＡベースのＲＯは、例えば３ＧＰＰ又は３ＧＰＰ２ネットワークなどの、ＭＮに厳しい管理が敷かれているネットワークに適用可能である。

前のセクションにおける方法では、ＭＮのＲＯに対するＢＣＥを作成するための情報は拡張ＢＡメッセージを介してＨＡから送ることができると説明した。しかし、ＨＡがＨＡベースのＲＯをＭＮのＣｏＡの登録時に直ちに実行したくない、又は例えば、他のＣＮとのＲＯに対するＭＮのＢＣＥを更新するために、（例えばＢＣＥを削除する目的で）ＲＯ関連情報を定期的に又は時々ＭＮに送信したい場合、拡張ＢＡでは実現不可能である。なぜなら、ＢＡは単にＢＵへの返答として送信されるにすぎないからである。従って、ここでは、ＲＯ関連ＢＣＥ情報の送信方法を拡張することが提案されており、ＭＮとＨＡ間でより一般的なシグナリングを使用することが提案されている。一つの可能な例として、２００８年のＨａｌｅｙ等に詳しく定義されているジェネリック・シグナリング・メッセージ（ＧＳＭ）を使用する方法があり、そのようなメッセージはＭＩＰｖ６エンティティ間におけるシグナリング・イベントを送受信するために使用される。シグナリング又はＲＯ関連情報のために、メッセージには、少なくともメッセージが完全性を保護されていることを示すＩＰｓｅｃ情報が含まれており、それにより受信者（例えば、ＭＮ）は送信者（例えば、ＨＡ）を信頼することができる。この情報を暗号化すれば、より信頼性の高いＲＯ関連情報をＨＡ−ＭＮ間で通信することができる。

図９に、ＨＡベースのＲＯの場合の信号フローを示す。初めに、ＭＡＧ１とＭＡＧ２との間にＰＭＩＰ ＲＯが存在する。ＭＮ１が外部リンクへと移動し、ＢＵをＨＡ／ＬＭＡ１に送信すると、ＨＡ／ＬＭＡ１は、最適化ルーティングのためのハンドオーバを行う前に使用されたＣＮの気付アドレス、すなわち、ＭＡＧ２のＩＰアドレスを含む拡張ＢＡで返答する。２００４年のＪｏｈｎｓｏｎ等に述べられているように、ＭＮはＣＮの気付アドレスに対してＢＣＥエントリを作成し、ＢＣＥに従ってパケット送信を開始する。

これは、ＩＰヘッダにはＭＮのＨｏＡが挿入されるホーム・アドレス・オプションが含まれていることを意味し、ＩＰヘッダの送信元アドレスはＭＮのＣｏＡである。また、ＨＡ／ＬＭＡ１は、ＭＡＧ２のＢＣＥを更新するため、ＲＯ更新メッセージをＭＮの新しいＣｏＡを含むＭＡＧ２へ送信する。ＭＡＧ２はＭＮに直接パケットを転送し始めるが、ＭＡＧ間転送（例えばＰＭＩＰ ＲＯの場合）のようなＩＰ−ｉｎ−ＩＰトンネリングを使用するのではなく、２００４年のＪｏｈｎｓｏｎ等に記載されているようなＲＯのデータ・パケット・フォーマットを使用する。

上記では、ＭＮの新しい気付アドレス（ＣｏＡ）を新しいＩＰアドレス又は単に新しい位置と呼ぶこともできる。

これは、宛先アドレスがＭＮのＣｏＡに設定され、ＩＰヘッダにはＭＮのＨｏＡを含む宛先オプションが含まれていることを意味する。ＲＯ更新メッセージの処理後、ＭＡＧ２はＢＣＥを更新する。その結果、すべてのデータ・パケットがＭＮとＭＡＧ２との間を直接流れることとなる。ＨＡ／ＬＭＡ１は、図９の下部に示すように、ＲＯ更新メッセージを送信することでＭＮ及びＭＡＧ２のＢＣＥ状態を定期的に更新できる。

ＨＡは、信頼関係、例えば、ＩＰｓｅｃベースのセキュリティ・アソシエーションを有する任意のノード（これは移動可能又は固定されている、すなわち、このノードはＭＮ又はＭＡＧである）とのＨＡベースのＲＯを開始できる。ＲＯ関連情報を含むメッセージを処理し、ＲＯのＢＣＥを作成するのに必要な機能がノードに実装されていることが重要である。さらに、ＨＡによって送信されたＲＯ関連情報を取得するノードは必ずしも外部リンクに接続される必要はない、すなわち、ノードは必ずしもＭＩＰを起動させたりＣｏＡをＨＡに登録したりする必要はない。ＨＡとノードとの間に信頼関係（例えば、ＩＰｓｅｃベースのセキュリティ・アソシエーション）が存在するということが唯一の要件である。

以下において、再び図１０を用いて上記プロセスを少し異なった観点から説明する。

本発明の一実施の形態では、ステップ９０２に示すように、モバイル・ノードに対して、通信相手ノードとの、リターン・ルータビリティ・ベースの、又は、ＬＭＡ／ＭＡＧ交換ベースのＰＭＩＰルート最適化を行う。ルート最適化は、必ずしもプロセスの第１ステップとは限らないが、ここに挿入されているのは単に例示目的である。その後、モバイル・ノードはステップ９０４においてハンドオーバを行い、ステップ９０６においてプロキシ・ルート最適化が必要であるか否かを判断する。プロキシ・ルート最適化が必要でない場合は、ステップ９１２において、モバイル・アクセス・ゲートウェイ又はＬＭＡが、通信相手ノード又はそのモバイル・アクセス・ゲートウェイとのプロキシ・ルート最適化の登録を取り消す。

一方、プロキシ・ルート最適化が必要である場合は、ステップ９１４において、どのタイプのルート最適化を採用するのかを決定しなければならない。リターン・ルータビリティ・ベースのルート最適化が採用される場合、ステップ９０８において、ホーム・エージェントはプロキシ・ルート最適化に関する情報をモバイル・ノードに送信する。この情報は、例えば通信相手ノードのアドレスで構成される。ステップ９１０において、モバイル・ノードは、モバイルＩＰ登録後、通信相手ノードのバインディング・キャッシュ・エントリを更新する。これでプロセスは終了する。

ホーム・エージェント・ベースのルート最適化を採用すると判断した場合、モバイル・ノードのホーム・エージェントは、図１０のステップ９１６において、モバイル・ノードのルート最適化状態を生成及び管理する。ステップ９１８において、通信相手ノードのホーム・エージェントは、モバイルＩＰ登録後、モバイル・ノードの新しい位置での通信相手ノードのルーティング状態を更新する。その後プロセスが終了する。

上記解決法は、移動しているＭＮ１に適用される。同様に、その解決法は、プロキシＲＯパスがＭＡＧ１とＭＡＧ２との間で利用可能である、移動しているＭＮ２にも適用可能である。上述の解決法には変更を加える必要がない。

他のシナリオでは、ＭＡＧ１がＭＮ１に代わってプロキシ通信相手ノードとして機能し、ＲＯがＭＮ２によって開始されるといった状況が生じることもある。すなわち、ＭＡＧ１がＭＮ２のＢＣＥを有するよう、ＲＯパスがＭＮ２／ＭＡＧ２によって設定されるが、ＭＡＧ１はＲＯを行わない。このような状況では、ＭＮ１がＰＭＩＰｖ６からＭＩＰｖ６への移行を行い、ＢＵをＨＡ／ＬＭＡ１に送信した場合、ＨＡ／ＬＭＡ１はＣＮのＨｏＡ及びＣｏＡを含むがＨｏＴキーゲントークンは含まない拡張ＢＡで返答することになる。上記説明の状況において、ＭＮ１はＭＮ２／ＭＡＧ２とのＲＲ及びＲＯ手順を開始することになる。しかしながら、ＭＮ１は、ＲＲ及びＲＯ手順を実行しないで、ＭＮ２／ＭＡＧ２のＢＣＥの作成のみを行わなければならいので、上記動作は間違いである。

そのような誤動作を回避するため、拡張ＢＡにはプロキシＲＯパスが設定されるべきＲＯ方向を示す情報が含まれていてもよい。例えば、ＣＮ（ＭＮ２）に対して「ＴＯ／ＦＲＯＭ」方向を特定する２ビットを含むフィールドが備えられていてもよい。「ＴＯ」はＭＮ１がＣＮのＢＣＥを更新するためにＲＲ及びＲＯ手順を実行すべきであるということを意味する。「ＦＲＯＭ」はＭＮ１がＣＮのＢＣＥを作成すべきであることを意味し、この場合、拡張ＢＡにはＣＮのＣｏＡが含まれていなければならないことを意味する。「ＴＯ／ＦＲＯＭ」フィールドの設定には以下のようにさまざまな可能性が考えられる。
「ＴＯ」＝１、「ＦＲＯＭ」＝０
「ＴＯ」＝０、「ＦＲＯＭ」＝１
「ＴＯ」＝１、「ＦＲＯＭ」＝１

上記提案された「ＨＡベースのＲＯ」の解決法は、完全なホスト・ベース・モビリティ（ＭＩＰｖ６）の、すなわち、ＰＭＩＰｖ６を使わないシナリオに適用可能である。このようなシナリオでは、ＨＡは、ＭＮが通信を行っているＣＮの存在を把握していなければならず、ＭＮのＲＯ ＢＣＥ状態を設定できる。つまり、ＨＡは、ＨＡがアンカーである、ＭＮのＲＯセッションを開始・制御・管理する。主な利点としては、ＭＮはＣＮに定期的にＲＲを実行しなくてもよい（ＲＲ手順は通常６分毎に実行される）。

上述したように、ＨＡ及びＭＮは、「ＨＡベースのＲＯ」解決法を適用する完全なＭＩＰｖ６の場合におけるＲＯ関連情報の交換にもＩＰｓｅｃの完全性が保護されたジェネリック・シグナリング・メッセージ（ＧＳＭ）を使用できる。そのような情報を交換するのにさらに安全な方法は、ＲＯ情報を含むＧＳＭメッセージにＩＰｓｅｃ暗号を使う、すなわち、ＩＰｓｅｃをトンネル・モードで適用することである。その結果、中間ノードはＧＳＭメッセージに含まれたＲＯ関連情報を読むことができない。

ＲＲに基づく手法と、ここで紹介された別のＨＡ制御のＲＯとの２つの異なるＲＯ手法が利用可能であるため、どちらの手法を使うべきかを選択するための判断基準が必要となる。この判断にはさまざまな基準が適用されてもよい。

例えば、ＨＡベースのＲＯは、ネットワーク・オペレータがデータ・トラフィック・ルートをさらに制御するよう努める、３ＧＰＰネットワークにより適している。従って、ネットワーク（すなわち、ＨＡ）は、ＵＥが特定のＣＮにＲＯを行うべきか否かを判断することができる。同じＨＡに接続されるＭＮにはさまざまなタイプのものがあってもよい。一部のＭＮにＨＡベースのＲＯを適用する一方で、その他のＭＮはＲＯを設定するためにＭＩＰｖ６のＲＲ手順を利用できる。また、ＲＲベースの手法のみを実施するＭＮがあったり、ＨＡベースの手法のみを実施するＭＮがあったりしてもよい。

現実的なシナリオを以下にいくつか示す。
ＨＡは、ＭＮのＣｏＡに基づいて、ＭＮの位置を決定したり、ＣＮに対するＲＯが有効か否かを判断したりできる。ＣＮはＨＡとセキュリティ・アソシエーションを持っていなければならない。ネットワーク・ポリシーがＲＯを許可し、それが有効である場合、ＨＡは、ＣＮのＲＯ ＢＣＥを設定するために、ＲＯ関連情報を持つメッセージを送信してもよい。ＭＮがそのＣｏＡを変更するたび、ＨＡはＣＮのＲＯ ＢＣＥを更新する。
２つのＭＮが同じＨＡに接続されており、ＲＯが有効であることをＭＮの位置に基づいてＨＡが判断した場合、ＨＡは両方のＭＮのＲＯ ＢＣＥ状態を開始、制御できる。ＨＡが一番先にＭＮの新しい位置を知るため（ＭＮはＣｏＡの変更後いつもＢＵをＨＡに送信することから）、ＨＡは、ＲＯ関連情報を含む更新メッセージを通信相手のＭＮに送信し、他のＭＮにおけるＣｏＡの変更を報告することができる。

ＨＡベースのＲＯのアプリケーションは、通信相手（ＭＮ）の両方が同じＨＡに接続されていないシナリオでは適用がさらに難しくなる。ＭＮ１がＨＡ１に接続され、ＭＮ２がＨＡ２に接続されているものとする。ＨＡ１とＨＡ２との間に安全な接続がある、例えば、同じオペレータがＨＡ１及びＨＡ２に対応している場合、これらのＨＡは通信相手のＭＮの現在位置に関する情報を交換しなければならない。例えば、ＨＡ１はＭＮ１のＣｏＡ変更をＨＡ２に報告し、逆に、ＨＡ２はＭＮ２のＣｏＡ変更をＨＡ１に報告しなければならない。

ＨＡベースのＲＯが開始された場合、特に、ここでＨＡがＭＮのＣＮを知らない場合は、また別問題である。解決法としては、ＭＮがＣＮとＲＲ手順を開始したときに、ＨＡがＨＡベースのＲＯを開始することが考えられる。

例えば、ＭＮはＣＮとのＲＯを開始することを決定し、ＨｏＴｉ及びＣｏＴｉメッセージを送信する。ＨｏＴｉメッセージは、ＨＡがこのメッセージをインターセプトしてＣＮを決定できるよう、ＨＡを介する。ＨＡはＨｏＴｉメッセージをＣＮに転送せず、「ＨｏＴｉ失敗」を示すメッセージをＭＮに返送する（これはＭＮがＨｏＴｉメッセージを再送し続けないからである）。このような「ＨｏＴｉ失敗」メッセージは、現時点で存在しない新しいメッセージでありうる。その後、ＨＡは所定のＭＮに対してＣＮのＲＯ ＢＣＥ状態を設定するためにＲＯ関連情報を含むメッセージを送信し、ＣＮとＨＡベースのＲＯを開始する。ここでも同様に、ＨＡは、信頼できる方法でＲＯ関連情報を交・BR>キするために、ＣＮとセキュリティ・アソシエーションを有していなければならない。

ＭＮ１が外部リンクにＨＯを行い、ＨＡが、ＨＡに固定・接続されＭＮ１と通信を行う他のＭＮに代わってＨＡベースのＲＯを実行することを決定した場合、また別の手順を取ることも可能である。このようなシナリオでは、ＨＡは、ＨＡ制御のＲＯ情報が含まれている拡張ＢＡをＭＮ１のＢＵへの応答として送信する。このように、ＭＮ１から他のＭＮに向かう方向でＲＯが達成される。他のＭＮからＭＮ１に向かう方向でのＲＯが望まれる場合には、ＨＡは他のＭＮに対してＭＮ１に代わってＨＡベースのＲＯを実行する必要がある。

以下に、上記説明に従った関連するエンティティに対する変更についての概要を簡単に示す。この概要は完全ではないが、主要な点のいくつかを要約している。

ＭＮに対する変更
既存のプロキシ・ルート最適化パスに関する要求情報を含む拡張ＢＵを生成可能にする。さらに、ＭＮは、ＨＡに拡張ＢＵを送信するか標準ＢＵを送信するかを決定する決定メカニズムを実装してもよい。
拡張ＢＡ又は拡張ＧＳＭシグナリングを受信可能とし、対応して処理可能とする。このことは下記を意味する。
所定のＣＮにＢＣＥを作成する。そのＢＣＥに対して、拡張ＢＡでＣｏＡが報告され、「ＴＯ／ＦＲＯＭ」フィールドの「ＦＲＯＭ」フラグがポジティブな状態に設定される。このようなＢＣＥエントリは一時的に設定され、ＣＮ／ＭＡＧ２はある時点でＲＲ及びＲＯ手順を開始する。
ＨｏＴキーゲントークンが含まれる、及び／又は、「ＴＯ／ＦＲＯＭ」フィールドの「ＴＯ」フラグがポジティブな状態に設定される場合、ＭＮは拡張されたＲＲ及びＲＯ手順を開始し、拡張ＢＡからのＨｏＴキーゲントークンを、初期バインディング・アップデートでＫｂｍを生成するために使用する。
ＢＣＥ状態を更新又は削除するために、ＨＡからＲＯシグナリング（例えば、拡張ＧＳＭシグナリング又は拡張ＢＡ）を定期的に受信する場合。

ＭＡＧに対する変更
ＭＡＧは、ＭＮがリンクから離れたことを検出すると、データベース（例えば、ＢＣＥ）のＭＮのエントリを非アクティブ状態にするが、ある一定の時間その情報は削除しない。
所定のＭＮに利用可能である場合（オプション２の場合）、ＬＭＡからのプロキシＲＯ関連情報に対する要求を受け付けて処理し、その情報を返送する手段を実装する。このようなプロキシＲＯ関連情報には、少なくともＣＮのＩＰアドレス（ＨｏＡ）や、もし可能であればＣＮのＣｏＡやＨｏＴキーゲントークンが含まれている。
ＭＡＧが、データ・パケットの転送を要求する、ＭＮの登録取消メッセージをＬＭＡから受信した後、ＭＮの（ＲＯパスを介して受信する）データ・パケットをＬＭＡに転送する。
ＭＡＧがプロキシＭＮとして機能し、ＣＮがプロキシＲＯからＭＩＰｖ６のＲＯへの移行を行ったとＭＡＧが検出した場合、ＣＮとプロキシＲＲ及びＲＯ手順を開始する。このことは前述されている。

ＨＡ／ＬＭＡに対する変更
拡張ＢＵを受信可能にし、拡張ＢＡをＭＮへ送信可能にする。
ＲＯ関連情報についてＭＡＧとコンテキスト交換を行う手段を実装する。本発明では、ＰＭＩＰｖ６プロトコルがこの情報を伝送するよう拡張されているものとする。従って、オプション２では、ＬＭＡはＭＡＧ１からＲＯ情報を要求する拡張ＰＢＡを送信可能でなくてはならない。
ＭＡＧによって受信された、ＣＮのＨｏＴキーゲントークン及びＣＮのＣｏＡを記憶する（オプション１）。
ＲＯが所定のＭＮに存在する場合、ＭＡＧ１にＭＮの受信データ・パケットを転送するよう要求する。
ＭＡＧがＭＮの登録取消メッセージを送信する場合、ＨＡ／ＬＭＡはＭＮのＢＣＥを無効にするが、ある一定時間は削除しない。これは、ＢＵの前にＭＡＧからの登録取消メッセージがＨＡ／ＬＭＡに到着した場合に必要となる。これにより、ＨＡ／ＬＭＡは拡張ＢＡにてプロキシＲＯ関連情報を含むＭＮに応答可能となる。
ＨＡベースのＲＯを行う、すなわち、所定のＣＮに対して（例えば、拡張ＧＳＭメッセージを介して）ＭＮのＢＣＥを設定するためのシグナリングをサポートし、それらのＢＣＥを定期的に更新及び／又は削除する手段を実装する。さらに、ＣＮがＨＡ／ＬＭＡに接続されている場合、ＣＮのＢＣＥを更新可能にする、又は、それに対応して新しいＭＮのＣｏＡをＣＮのＨＡに通知可能にする。

本発明の別の実施の形態は、ハードウエア及びソフトウエアを用いた上述の様々な実施の形態の実現に関する。本発明の様々な実施の形態はコンピュータ機器（プロセッサ）を用いて実現又は実施し得ることが分かる。コンピュータ機器の例としては、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル・ゲートアレイ（ＦＰＧＡ）、又は他のプログラマブル論理装置などがある。本発明の様々な実施の形態は、これらの機器の組み合わせによっても実施又は具体化し得る。

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

Claims (8)

1. モバイル・ノード、モバイル・アクセス・ゲートウェイ、通信相手ノード、及びホーム・エージェントを少なくとも備えるパケット交換通信ネットワークにおける、ネットワーク・ベース・モビリティ対応アクセス・ネットワークとネットワーク・ベース・モビリティ非対応アクセス・ネットワークとの間での前記モバイル・ノードのハンドオーバ方法であって、
   ａ）ネットワーク・ベース・モビリティ対応アクセス・ネットワークからネットワーク・ベース・モビリティ非対応アクセス・ネットワークへのハンドオーバに関して、前記モバイル・ノードに代わって前記モバイル・アクセス・ゲートウェイが前記通信相手ノードに対するプロキシ・ルート最適化を行うステップと、
   ｂ）ネットワーク・ベース・モビリティ対応アクセス・ネットワークからネットワーク・ベース・モビリティ非対応アクセス・ネットワークへ前記モバイル・ノードがハンドオーバを行うステップと、
   ｃ）ハンドオーバ後に前記プロキシ・ルート最適化を行う必要があるか否かを前記モバイル・ノードのホーム・エージェントが判断するステップと、
   ｄ）行う必要がある場合に、リターン・ルータビリティに基づくルート最適化を実行するか、ホーム・エージェントに基づくルート最適化を実行するかを前記モバイル・ノードのホーム・エージェントが判断するステップと、
   ｅ）前記リターン・ルータビリティに基づくルート最適化を実行する場合には、前記モバイル・ノードのホーム・エージェントが前記プロキシ・ルート最適化に関する情報を前記モバイル・ノードに送信し、前記モバイル・ノードが前記通信相手ノードのルーティング状態を前記モバイル・ノードの新しい位置で更新するステップと、
   ｆ）前記ホーム・エージェントに基づくルート最適化を実行する場合には、前記モバイル・ノードのホーム・エージェントによって前記モバイル・ノードのルート最適化状態を生成及び管理し、前記通信相手ノードのホーム・エージェントが前記通信相手ノードのルーティング状態を前記モバイル・ノードの新しい位置で更新するステップとを、
   含むハンドオーバ方法。
2. 前記ステップｆ）の後に、
   ｇ）前記通信相手ノードが前記モバイル・ノードと同じホーム・エージェントに接続されている場合、前記モバイル・ノードのホーム・エージェントが前記モバイル・ノードの新しい位置を前記通信相手ノードに登録するステップと、
   ｈ）前記通信相手ノードのホーム・エージェントが前記モバイル・ノードのホーム・エージェントと異なる場合、前記モバイル・ノードのホーム・エージェントが前記通信相手ノードのホーム・エージェントに前記モバイル・ノードの新しい位置を通知するステップと、
   前記通信相手ノードのホーム・エージェントが前記通信相手ノードのルーティング状態を更新するステップとを更に有する請求項１に記載のハンドオーバ方法。
3. 前記ステップｃ）の後に、前記ハンドオーバ後に前記プロキシ・ルート最適化を行う必要がない場合、
   前記モバイル・アクセス・ゲートウェイ又は前記モバイル・ノードのホーム・エージェントが、前記通信相手ノード又は前記通信相手ノードのモバイル・アクセス・ゲートウェイとの前記プロキシ・ルート最適化の登録を取り消すステップを更に有する請求項１又は２に記載のハンドオーバ方法。
4. モバイル・アクセス・ゲートウェイのルーティング状態は、前記ホーム・エージェントによって更新される請求項１から３のいずれか１つに記載のハンドオーバ方法。
5. 前記モバイル・ノード、前記通信相手ノード、前記ホーム・エージェント及び前記モバイル・アクセス・ゲートウェイ間での通信を可能にするシグナリングは、ルート最適化シグナリングによって実行される請求項１から４のいずれか１つに記載のハンドオーバ方法。
6. 前記ルート最適化シグナリングにおいて完全性保護又は暗号化が利用される請求項５に記載のハンドオーバ方法。
7. ネットワーク・ベース・モビリティ対応アクセス・ネットワークとネットワーク・ベース・モビリティ非対応アクセス・ネットワークとの間でハンドオーバを行うモバイル・ノード、通信相手ノード、及びモバイル・アクセス・ゲートウェイを更に備えるパケット交換通信ネットワークにおけるホーム・エージェントであって、
   前記モバイル・ノードが前記ネットワーク・ベース・モビリティ対応アクセス・ネットワークから移動した場合に、ネットワーク・ベース・モビリティ対応アクセス・ネットワークとネットワーク・ベース・モビリティ非対応アクセス・ネットワークとの間のハンドオーバを行う通信手段と、
   ネットワーク・ベース・モビリティ対応アクセス・ネットワークからネットワーク・ベース・モビリティ非対応アクセス・ネットワークへのハンドオーバに関して、プロキシ・ルート最適化に関するルート最適化信号を前記モバイル・ノードに送信する送信手段と、
   前記モバイル・ノードでのルート最適化状態を生成及び管理し、前記通信相手ノードのルーティング状態を更新する管理手段と、
   リターン・ルータビリティに基づくルート最適化を実行するか、ホーム・エージェントに基づくルート最適化を実行するかを判断する決定手段とを、
   備えるホーム・エージェント。
8. 前記請求項２から６のいずれか１つに記載のハンドオーバ方法において、前記モバイル・ノードのホーム・エージェントによって実行されるステップを実行する請求項７に記載のホーム・エージェント。