JP2010518718A - 経路最適化処理によるデータ・パケットのネットワーク制御オーバーヘッド削減 - Google Patents

Abstract

【解決手段】本発明は、モバイル・ノード（ＭＮ）と、ＭＮと通信相手ノード（ＣＮ）間に位置するゲートウェイとの間で交換されるデータ・パケットのヘッダ・サイズを低減させる方法に関する。ＭＮとゲートウェイ間およびゲートウェイとＣＮ間で異なる種類のヘッダが利用される。最適化処理により得られた種類のヘッダにより、前記データ・パス部分において交換されるパケットのヘッダ・サイズを低減させることが可能となる。これを達成するため、ＭＮと、ＣＮの代わりとして機能するゲートウェイとの間で、変更された経路最適化（ＲＯ）処理が実行される。第１ＲＯ処理終了後、ＭＮは、ＣＮとして機能するゲートウェイとの間の第２ＲＯ処理を開始および実行する。経路最適化の両処理終了後、ＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードに切り替えた後に、ＣＮとゲートウェイとの間でデータ・パケット送信が行われる。
【選択図】図１３

Description

本発明は、モバイル・ノード（ＭＮ）と通信相手ノード（ＣＮ）間で交換されるデータ・パケットの経路最適化ヘッダおよび経路非最適化ヘッダを利用することにより、データ・パケットのヘッダ・サイズを低減させる方法に関する。本発明は、主に、モバイル・ノードと通信相手ノード間の通信であって、該通信におけるゲートウェイ（ＰＤＧ）がデータ・パケットの追加カプセル化を行うことにより、データ・トラフィックを増大させる通信に適用される。特に、上記経路最適化ヘッダおよび経路非最適化ヘッダは、通信相手ノードの代わりにゲートウェイがモバイル・ノードとゲートウェイ間の第１経路最適化処理を実行し、かつ、モバイル・ノードがモバイル・ノードとゲートウェイ間の第２経路最適化処理を開始及び実行することにより設定される。さらにまた、経路最適化の両処理終了後は、他のＩＰｓｅｃモードに切り替えてからデータ・パケット交換が行われる。

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

スケーラビリティ上の理由により、ＩＰネットワークは階層型アドレッシング方式を使用する。従って、ＩＰアドレスは、対応する端末を識別するだけではなく、この端末に関する位置情報もさらに含む。ネットワーク内のルータは、ルーティング・プロトコルによって提供される追加情報を用いて、特定の宛先へ向けて次のルータを識別することができる。

具体的には、ルーティングと称されるプロセスは、少なくとも１つの中間ネットワークを介して送信元から宛先へデータ・パケットを移動するために用いられる。データ・パケットがその宛先に到達するためには、データ・パケットが宛先デバイスの物理ネットワークに到達するまで、データ・パケットを１つのルータから別のルータへ伝達する必要がある。この処理は、ネクスト・ホップ・ルーティングとも称される。その理由は、ルーティングが段階的に行われるからである。つまり、初めの段階では送信元と宛先間の正確なパスは不明であるが、各中間ルータはデータ・パケットを転送すべきネクスト・ホップ・ルータを把握しているからである。このルーティングによって達成される主な利点は、各ルータは、すべての宛先ネットワークへの正確な経路を把握するのではなく、近隣のどのルータが次に所定データ・パケットを受け取るべきかさえ知っていれば十分ということである。

例えば、送信元デバイスがそのローカル・ルータへパケットを送信した後、このローカル・ルータのデータ・リンク層は、そのパケットをルータのＩＰ層へと引き渡す。それに対応して、レイヤー２フレーム除去後、パケットのレイヤー３ヘッダが調べられ、ルータは、パケットを次にどのルータに送るかを決定する。その結果、パケットは適当なレイヤー２フレームに再カプセル化され、データ・リンク層へと戻され、データ・リンク層は、ルータの物理ネットワーク・リンクの１つを介して、そのパケットを決定した次のルータに送る。

この点において、ルータは、自身が接続している複数の他のルータと、異なるネットワークＩＤとのマッピングを提供する、ルーティング・テーブルと呼ばれる情報セットを保持する。それにより、ルータは、データ・パケットの宛先ＩＰアドレスを、ルーティング・テーブルのエントリと照合し、宛先アドレスとルーティング・テーブルのエントリとの最長一致に基づいて、ネクスト・ホップ・ルータを決める。また、ルーティング・テーブルのエントリごとに定められたメトリック値は、特定のルーティング・エントリを一定の基準に基づき評定することを可能とし、それにより、いくつかの可能なパスの中から最適なパスを選択することが可能となる。

このように、ルーティング・テーブルは、効率的なデータの提供に適切であり、管理者によって手動で、または、動的に設定されてもよい。絶えず変化する一般的なインターネットでは、主に動的ルーティング・テーブルが適用されるのに対し、静的経路の手動設定は、小さいネットワークに対してのみ実行可能である。ルーティング・テーブルの自動構築は、ルータ間で交換されるルーティング情報を含む一連の定期的またはオンデマンドのメッセージを含むルーティング・プロトコルによって管理および更新される。

ネットワーク層３（ＯＳＩ）は、パケットのルーティングが実際に行われる層であり、データ・パケットのレイヤー３ヘッダは、中間ネットワークを介してルーティングされている間は変化しない。送信元および宛先の上位層はただ“論理的に”接続されているだけ、つまり、現実の接続性はないので、パケットは、物理的に宛先へ送られるためには下位レイヤー２、１を通過する必要がある。各ネットワーク層では異なるプロトコルが使用されるので、例えばレイヤー３やレイヤー２から送られる各データ・パケットは適切に構成されなければならない。

従って、データ・パケットのカプセル化は、通常、上位層プロトコルから下位層プロトコルを介してデータを送信するために使用される。例えば、多くのアプリケーションが、データに関してユーザ・データ・プロトコル（ＵＤＰ）または伝送制御プロトコル（ＴＣＰ）を使用するのに対し、インターネットはＩＰｖ６プロトコルを利用する。そのため、ユーザ・データはＵＤＰデータグラム（レイヤー４）でカプセル化され、その後ＩＰパケット（レイヤー３）でカプセル化される。その後、ＩＰパケットは、カプセル化されたユーザ・データと共に、データ・リンク層プロトコル（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、レイヤー２）を介して送信されてもよく、この場合もやはりカプセル化を伴うことになる。

さらにまた、特定のレイヤーの１つのプロトコルが、同じ特定のレイヤーの他のプロトコルによってカプセル化されたデータ・パケットを移送するために用いられる場合、同じレイヤー内でカプセル化が利用されてもよい。トンネルと呼ばれる論理的構成は、カプセル化を行うデバイスとカプセル開放を行うデバイスとの間で確立され、その処理自体はトンネリングと呼ばれる。トンネリングは、あるネットワーク・プロトコルのデータ・パケットを、トンネリングなしでは当該プロトコルをサポートしないネットワーク（別のプロトコルで制御されるネットワーク）を介して送信するために使用されてもよい。また、トンネリングは、プライベート・アドレッシングなど、様々なタイプの仮想プライベート・ネットワーク（ＶＰＮ）の機能を提供するために利用されてもよい。例えば、ＧＰＲＳトンネリング・プロトコル（ＧＴＰ）、ポイント・ツー・ポイント・トンネリング・プロトコル（ＰＰＴＰ）またはＩＰセキュリティ・プロトコル（ＩＰｓｅｃ）がある。ＩＰｓｅｃの動作には、２つのモードがある。一方はトランスポート・モードの動作、他方はトンネル・モードの動作である。トランスポート・モードでは、データ・パケットのペイロードのみが暗号化され、ＩＰヘッダが平文として送られるため、完全にルーティング可能である。トンネル・モードでは、ＩＰパケット全体が暗号化され、その後、ルーティング処理のためにカプセル化され、新しいＩＰパケットとならなければならない。トンネル・モードは、ネットワーク間通信を行うため、すなわち、ルータ間に安全なトンネルを設置するために用いられる。

最も一般的なトンネリング機構の１つに、ＩＰ（レイヤー３）内ＩＰ（レイヤー３）カプセル化があり、これはＩＰデータグラムを他のＩＰヘッダと共にカプセル化する処理のことであり、例えばモバイルＩＰに利用してもよい。モバイルＩＰｖ６―ＭＩＰｖ６とも表記される―（Ｄ．Ｊｏｈｎｓｏｎ，Ｃ．Ｐｅｒｋｉｎｓ， Ｊ．Ａｒｋｋｏ，”Ｍｏｂｉｌｉｔｙ Ｓｕｐｐｏｒｔ ｉｎ ＩＰｖ６”，ＩＥＴＦ ＲＦＣ ３７７５，２００４年６月を参照のこと。この文献はｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇにて入手可能であり、参照することによりここに組み込まれる）はＩＰベースのモビリティ・プロトコルであり、上位層およびアプリケーションに対してトランスペアレントに、すなわち、上位層の接続を切断することのない形で、モバイル・ノードがサブネット間を移動できるようにする。言い換えれば、モバイル・ノードは、ＩＰｖ６インターネット・ネットワーク内を移動している間も、到達可能な状態が維持される。

通常、端末は、電源がオンになると、アクセス・ネットワークのＩＰアドレス・プレフィックスに基づくＩＰアドレスを設定する。端末が、移動可能な、いわゆるモバイル・ノード（ＭＮ）であって、異なるＩＰプレフィックス・アドレスを持つサブネット間を移動する場合、階層型アドレッシング方式のため、端末はＩＰアドレスをトポロジー的に正しいアドレスに変更しなければならない。しかしながら、ＴＣＰ接続などの上位層における接続は、通信ノードのＩＰアドレス（およびポート）で定義されるので、ノードの一方が例えば移動するなどしてそのＩＰアドレスを変更すると、アクティブなＩＰセッションへの接続が切れてしまう。上記問題に対処するために考えられるプロトコルの１つに、ＭＩＰｖ６プロトコルがある。

ＭＩＰｖ６の主要原理は、モバイル・ノードの気付アドレス（ＣｏＡ）がモバイル・ノードの現在のトポロジー的位置に関する情報を提供するのに対し、モバイル・ノードは常に、インターネット上のトポロジー的位置にかかわらず、そのホーム・アドレス（ＨｏＡ）によって識別されることにある。

具体的には、１つのモバイル・ノードに対し、２つのＩＰアドレス、すなわち、気付アドレスとホーム・アドレスが設定される。モバイル・ノードの上位層は、以後主に通信相手ノード（ＣＮ）と呼ぶ通信相手（宛先端末）との通信にホーム・アドレスを使用する。このアドレスは不変であり、モバイル・ノードを識別するという目的にかなう。トポロジー的には、このアドレスはモバイル・ノードのホーム・ネットワーク（ＨＮ）に属する。一方、気付アドレスは、サブネットの変更を伴う移動の度に変化し、ルーティング・インフラストラクチャのロケータとして使用される。トポロジー的には、このアドレスは、モバイル・ノードが現在訪れているネットワークに属する。ホーム・リンク上に位置する一群のホーム・エージェント（ＨＡ）のうちの１つが、モバイル・ノードの気付アドレスからモバイル・ノードのホーム・アドレスへのマッピングを保持し、モバイル・ノードへの着信トラフィックをモバイル・ノードの現在位置に転送する。単一のホーム・エージェントではなく一群のホーム・エージェントを配置する理由は、例えば、冗長性と負荷分散である。

モバイルＩＰｖ６は現在、２つの動作モード、すなわち、双方向トンネリング（図１）と後述の経路最適化（図２）とを定義している。モバイル・ノード１０２のホーム・アドレスに宛てて通信相手ノード１０１により送信されたデータ・パケットは、双方向トンネリングを用いて、ホーム・ネットワーク１１０内のホーム・エージェント１０５によりインターセプトされる。インターセプトされた各データ・パケットはネットワークを介してＭＮ１０２の気付アドレスに再送されなければならないので、ＩＰ−ｉｎ−ＩＰカプセル化が必要となる。その結果、インターセプトされた各データ・パケットは、ＭＮ１０２のＣｏＡに宛てて、外部（フォーリン）ネットワーク１２０に位置するＭＮ１０２へトンネリングされた新しいＩＰデータ・パケット内のペイロードとして含まれる。通信トンネルの出発点はカプセル化を行うホーム・エージェント１０５で、終点はモバイル・ノード１０２である。外部ネットワーク１２０内のローカル・エージェントがモバイル・ノードに代わってメッセージを受け取り、外部ＩＰヘッダを取り除き、カプセル開放されたデータ・パケットをモバイル・ノード（図示せず）へ送信することも可能である。

モバイル・ノード１０２により送信されたデータ・パケットは、ホーム・エージェント１０５へ逆方向トンネリングされ、ホーム・エージェント１０５は、これらのパケットをカプセル開放し、通信相手ノード１０１へ送信する。逆方向トンネリングとは、モバイル・ノードによって“順方向”トンネルとは“逆”の方法で、パケットがホーム・エージェントへトンネリングされることを意味する。

ＭＩＰｖ６におけるこの動作では、ホーム・エージェント１０５だけがモバイル・ノード１０２の気付アドレスを通知される。従って、モバイル・ノードはバインディング・アップデート（Ｂｉｎｄｉｎｇ Ｕｐｄａｔｅ：ＢＵ）メッセージをホーム・エージェントに送信する。これらのメッセージは、ＩＰｓｅｃセキュリティ・アソシエーションを介して有利に送信されるので、認証され完全性が保護されている。

図３は、ＭＮ１０２のホーム・エージェント１１１を介したＣＮ１０１とＭＮ１０２間のデータ・パケット交換を例示する図であり、通信中のパケット・フォーマットが詳細に示されている。ＣＮとＭＮ間のすべての通信がＭＮのＨＡ１１１を介して行われる、つまり、まだ経路最適化が行われていないものとする。そこで、ＣＮからＭＮへ送信されたデータ・パケットのＩＰヘッダは、ＭＮのホーム・アドレスを宛先アドレスとして含み、ＣＮのＩＰアドレスを送信元アドレスとして含む。ＭＮのホーム・アドレスであるパケットの宛先アドレスに従って、データ・パケットはホーム・ネットワークへルーティングされ、その後ＭＮのホーム・エージェントへルーティングされる。

以上説明したように、データ・パケットを受信した際、ＨＡはＭＩＰｖ６の手順に基づきＩＰ−ｉｎ−ＩＰカプセル化を適用し、カプセル化されたパケットをＭＮへ送信する。言い換えれば、ＨＡは、ＩＰ−ｉｎ−ＩＰカプセル化を適用することにより、受信したデータ・パケットをＭＮへトンネリングする。さらに具体的には、ＨＡは別のＩＰヘッダをパケットに付加する。このパケットは、自身のアドレスを送信元アドレスとして、また、ＭＮの気付アドレスを追加ヘッダの宛先アドレスとして含む。これにより、図３からも分かるように、パケット・サイズがもう４０バイト増大される。

同様に、ＭＮによって返送されたデータ・パケットは、２つのＩＰヘッダを用いてカプセル化される。外部ヘッダは、ＨＡへのデータ・パケットのトンネリングに関し、それにより、ＨＡのアドレスを宛先アドレスとして、また、ＭＮの気付アドレスを送信元アドレスとして含む。一方、内部ＩＰヘッダは、ＣＮのアドレスを宛先アドレスとして、また、ＭＮのホーム・アドレスを送信元アドレスとして含む。

従って、ＭＮとＣＮ間の通信セッションの各データ・パケットは、ＨＡとＭＮとの間で増大され、これにより該当する通信ネットワーク内にさらなるトラフィックが生じることになる。このことは、特に、限られたデータ帯域幅の機能を有するネットワーク、例えば、無線ネットワークにおいて不利となる。

従って、既存の最新技術における上記問題に鑑みて、本発明の目的の１つは、通信相手ノードとの通信において、モバイル・ノードと中間ノード間のデータ・パケットの交換を改善することにある。

さらに、本発明のもう１つの目的は、通信相手ノードとの通信において、モバイル・ノードとゲートウェイ間で交換されるデータ・パケットのヘッダ・サイズを低減させることにある。２つの異なるネットワークをつなぐゲートウェイを介したスループットを向上させるには、データ・パケットのヘッダ・サイズを低減させることが必要である。

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

本発明の態様の１つは、２つの異なる種類のヘッダを特定のデータ・パス部分に適用することによりデータ・パケットのＩＰヘッダ・サイズを低減させることである。特に、通信相手ノードとゲートウェイとの間では、経路非最適化ＩＰヘッダが使用され、ゲートウェイとモバイル・ノードとの間では、経路最適化ＩＰヘッダが使用される。これにより、ゲートウェイとモバイル・ノード間のデータ・パス上でのヘッダ・サイズが低減できる。必要となるであろう２つの経路非最適化ＩＰヘッダと比べ、上記経路部分では経路最適化ＩＰヘッダは１つしか必要ない。

本発明の別の態様は、異なるタイプのＩＰヘッダを設定するために経路最適化処理を適用することに関する。特に、ゲートウェイは、通信相手ノードが経路最適化が行われていることに気付かないよう、通信相手ノードとして機能し、経路最適化処理にかかわる。その結果、ゲートウェイとＭＮ１０２との間では経路最適化ＩＰヘッダが、交換されたデータ・パケットに適用されるのに対し、ＣＮ１０１はデータを送信するために引き続き経路非最適化ＩＰヘッダを使うこととなる。

本発明のさらに別の態様は、第１経路最適化処理を行った後に、異なるタイプのＩＰヘッダを設定するために第２経路最適化処理を開始および実行することにある。特に、モバイル・ノードは、ＣＮとして機能するゲートウェイとの間の第２経路最適化処理を開始し、実行する。経路最適化の両処理終了後の効果としては、ＩＰｓｅｃトンネル・ヘッダおよび通常のＩＰヘッダの送信元および宛先アドレスが類似していることである。これによって、ゲートウェイまたはＭＮがＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードに切り替えることにより、各データ・パケットのヘッダを大幅に低減させることが可能となる。

その結果、交換されたＩＰパケットに対しオーバーヘッドの軽減を伴う経路最適化ＩＰヘッダを用いてゲートウェイとモバイル・ノード間ではデータ・パケットの交換が行われるのに対し、ＣＮ１０１はデータを送信するために引き続き経路非最適化ＩＰヘッダを使うこととなる。

本発明の一実施の形態は、モバイル・ノードとゲートウェイ間の通信リンク上のデータ・パケットのヘッダ・サイズを低減させる方法を提供する。データ・パケットは、ゲートウェイを介してモバイル・ノードと通信相手ノードとの間で交換される。通信相手ノードは経路非最適化ヘッダを使ってデータ・パケットをモバイル・ノードへ送信するのに対し、モバイル・ノードは経路最適化ヘッダを使ってデータ・パケットを通信相手ノードへ送信する。そして、ゲートウェイは、モバイル・ノードからのデータ・パケットの経路最適化ヘッダを、通信相手ノードが使用する経路非最適化ヘッダに変換する。ゲートウェイは、さらに、通信相手ノードからのデータ・パケットの経路非最適化ヘッダを、モバイル・ノードが使用する経路最適化ヘッダに変換する。

本発明の他の実施の形態によれば、経路最適化ヘッダは、ゲートウェイとモバイル・ノード間において第１経路最適化処理を行うことにより得られる。経路最適化処理は、通信相手ノードに代わってゲートウェイにより開始および実行される。さらに、第１経路最適化処理終了後、通信相手ノードに代わるゲートウェイとモバイル・ノード間において第２経路最適化処理が行われる。第２経路最適化処理はモバイル・ノードにより開始される。第２経路最適化処理終了後、ゲートウェイとモバイル・ノードは、トランスポート・モードでＩＰセキュリティを使用するための新しいセキュリティ・アソシエーションを確立する。トランスポート・モードは、ペイロード暗号化を可能にするために、ゲートウェイとモバイル・ノードとの間でデータ・パケットを交換するための追加セキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替えることを可能にする。追加セキュリティ・トンネルを使用するのではなく、セキュリティ・オプションを付加することにより、データ・パケットのオーバーヘッドが軽減される。

別の実施の形態は、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダを含む経路非最適化ヘッダを、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１および第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダへ変換することに関する。さらに、経路非最適化ヘッダのＩＰヘッダは新しいＩＰヘッダと置き換えられ、第１および第２経路最適化ヘッダ・オプションとＩＰセキュリティ・オプション・フィールドとが経路非最適化ヘッダに挿入される。

さらに別の実施の形態は、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１および第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダを、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダを含む経路非最適化ヘッダへ変換することに関する。ここで、第１および第２経路最適化ヘッダ・オプションとＩＰセキュリティ・オプション・フィールドとが経路最適化ヘッダから取り除かれる。さらに、経路最適化ヘッダのＩＰヘッダは新しいＩＰヘッダと置き換えられ、ＩＰトンネル・カプセル化ヘッダが経路最適化ヘッダに挿入される。

本発明の一実施の形態は、データ・パケットのヘッダ・サイズを低減させるためのゲートウェイを提供する。データ・パケットは、モバイル・ノードと通信相手ノードとの間で交換され、すべてのデータ・パケットはゲートウェイを介して交換される。ゲートウェイの受信部は、モバイル・ノードから送られてくるデータ・パケットを受信し、モバイル・ノードから送られてくるデータ・パケットは、経路最適化ヘッダを含む。受信部はさらに、通信相手ノードから送られてくるデータ・パケットを受信し、通信相手ノードから送られてくるデータ・パケットは、経路非最適化ヘッダを含む。その後、ゲートウェイの処理部は、モバイル・ノードから送られてくるデータ・パケットの経路最適化ヘッダを経路非最適化ヘッダへと変換する。そして、処理部は、さらに、通信相手ノードから送られてくるデータ・パケットの経路非最適化ヘッダを経路最適化ヘッダへと変換する。

本発明の別の実施の形態において、ゲートウェイが第２経路最適化処理の第２バインディング・アップデートメッセージを受信して、ゲートウェイとモバイル・ノード間の新しいセキュリティ・アソシエーションが確立された後、ゲートウェイは、ゲートウェイとモバイル・ノード間のセキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替える。

本発明の他の実施の形態において、ゲートウェイは、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダを含む経路非最適化ヘッダを、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１および第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダへ変換する。ゲートウェイの処理部は、経路非最適化ヘッダからＩＰトンネル・カプセル化ヘッダを取り除く。処理部は、さらに、経路非最適化ヘッダのＩＰヘッダを新しいＩＰヘッダと置き換える。処理部は、さらに、第１および第２経路最適化ヘッダ・オプションとＩＰセキュリティ・オプション・フィールドを経路非最適化ヘッダに挿入する。

本発明の他の実施の形態によれば、ゲートウェイは、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１および第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダを、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダを含む経路非最適化ヘッダへ変換する。ゲートウェイの処理部は、第１および第２経路最適化ヘッダ・オプションとＩＰセキュリティ・オプション・フィールドとを、経路最適化ヘッダから取り除く。処理部は、さらに、経路最適化ヘッダのＩＰヘッダを新しいＩＰヘッダと置き換える。処理部は、さらに、ＩＰトンネル・カプセル化ヘッダを経路最適化ヘッダに挿入する。

また、本発明の他の実施の形態において、モバイル・ノードは、モバイル・ノードのホーム・エージェントを介して通信相手ノードとデータ・パケットを交換し、モバイル・ノードの第２位置依存ＩＰアドレスを第２経路最適化処理に関する自身の送信元アドレスとして用い、通信相手ノードと第２経路最適化処理を行う。

さらに、本発明の別の実施の形態において、モバイル・ノードは、第２経路最適化処理の第２バインディング・アップデートメッセージをゲートウェイへ送信し、ゲートウェイとモバイル・ノード間の新しいセキュリティ・アソシエーションが確立された後、モバイル・ノードとゲートウェイ間のセキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替える。

以下において、添付の図面を参照して、本発明をより詳細に説明する。図面において類似または対応する部分には、同じ参照番号を付してある。
モバイル・ノードと通信相手ノードとの間のＭＩＰｖ６に従った通信のための双方向トンネリングの使用を例示する。 モバイル・ノードと通信相手ノードとの間のＭＩＰｖ６に従った通信のための経路最適化の使用を例示する。 ＭＩＰｖ６の双方向トンネリング・モードで、ＭＮとＣＮ間の通信中に使用されるデータ・パケット・フォーマットを示す。 ＭＩＰｖ６双方向トンネリング・モードとＭＩＰｖ６経路最適化モードに使用される各データ・パケット・フォーマットを対比した説明を示す。 ＭＮとＣＮとの間のＭＩＰｖ６に従った経路最適化処理のシグナリング図、および、関連するメッセージのパケット・フォーマットを示す。 簡易化されたＷＬＡＮネットワーク・モデルの概要を示す。 相互に作用する３ＧＰＰ−ＷＬＡＮプロトコル・スタックと、通信に使用されるデータ・パケット・フォーマットを示す。 ＷＬＡＮのシナリオにおいてＭＮが位置する場合に、通信中に使用されるデータ・パケット・フォーマットを示す。 本発明の一実施の形態に係る、ＣＮに代わってゲートウェイにより第１経路最適化を行った際のシグナリング図およびメッセージ・フォーマットを示す。 本発明の一実施の形態に係る、第１経路最適化終了後のデータ・パケット・フォーマットを示す。 本発明の他の実施の形態に係る、経路最適化メッセージがゲートウェイ１０３からＭＮ１０２へと直接送信される第２経路最適化をＭＮ１０２により行った際のシグナリング図およびメッセージ・フォーマットを示す。 本発明の一実施の形態に係る、ゲートウェイから送信された経路最適化メッセージがＨＡ（ＭＮ）１０５を介してＭＮ１０２へと送信される第２経路最適化をＭＮ１０２により行った際のシグナリング図およびメッセージ・フォーマットを示す。 本発明の実施の形態に係る、ＭＮ１０２による第２経路最適化が終了し、ＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードに切り替えた後の、経路最適化ヘッダを用いたデータ・パケット・フォーマットを示す。

以下の各節で、本発明の種々の実施の形態について説明する。例示的な目的でのみ、実施の形態の大半を、上記背景技術の項および今後述べるような３ＧＰＰ−ＷＬＡＮ通信システムに関連して概説している。本発明は、例えば、３ＧＰＰ−ＷＬＡＮ通信システムなどの移動通信システムに関連して有利に使用され得るものであるが、本発明はこの特定の例示的な通信ネットワークでの使用に限定されないことに留意されたい。

また、上記背景技術の項で行った説明は、ここに記載されている主に３ＧＰＰの具体的で例示的な実施の形態をよりよく理解するためのものであって、ここに具体的に記載されている通りに処理および機能を上記移動体通信ネットワークに実装することに本発明を限定するものと理解すべきではない。しかしながら、ここで提案される改良は、背景技術の項に記載のアーキテクチャ／システムに容易に適用し得るものであり、また、本発明のいくつかの実施の形態においては、これらのアーキテクチャ／システムの標準的な手順および改良された手順を利用し得る。
用語の定義

以下に、本明細書において頻繁に使用されるいくつかの用語の定義を記載する。

モバイル・ノード（ＭＮ）は通信ネットワーク内の物理エンティティである。１つのノードがいくつかの機能エンティティを有してもよい。機能エンティティとは、ノードまたはそのネットワークの他の機能エンティティに対して所定の機能群を実現するおよび／または提供するソフトウェア・モジュールまたはハードウェア・モジュールのことである。ノードはそれぞれ、ノードの通信が可能な通信設備または通信媒体に自身を接続する１つまたは複数のインタフェースを有してもよい。同様に、ネットワーク・エンティティは、他の機能エンティティまたは通信相手ノードとの通信が可能な通信設備または通信媒体にこの機能エンティティを接続する論理インタフェースを有してもよい。

モバイル・ノードのホーム・ネットワーク（すなわちホーム・リンク）は、一般的には、そのモバイル・ノードが、与えられたそのモバイル・ノードのホーム・アドレスに対して１つまたは複数の気付アドレスを登録する、ホーム・エージェントの位置により識別される。ホーム・アドレスとは、モバイル・ノードに割り当てられるアドレスであり、そのモバイル・ノードのパーマネント・アドレスとして使用される。従って、ホーム・アドレスは、位置に依存しない。このアドレスは、モバイル・ノードのホーム・ネットワークのプレフィックスを有する。気付アドレスとは、モバイル・ノードが外部ネットワークを訪れているときにそのモバイル・ノードに関連付けられるアドレスであるので、位置に依存する。気付アドレスのプレフィックスは一般的には、その在圏ネットワークのプレフィックスに等しい。モバイル・ノードは同時に１つまたは複数の気付アドレスを有してもよい。

ホーム・エージェント（ＨＡ）とは、モバイル・ノードが現在の１つまたは複数の気付アドレスを登録するためのルーティング機能を、モバイル・ノードのホーム・ネットワーク上で提供するルータまたは機能エンティティである。ホーム・エージェントは、モバイル・ノードに対するモビリティ・アンカー・ポイントとして機能する。モバイル・ノードがホームから離れている間、ホーム・エージェントは、例えば、そのモバイル・ノードのホーム・アドレス宛てのホーム・リンク上にあるパケットをインターセプトし、それらのパケットをカプセル化し、モバイル・ノードの登録済み気付アドレスのうちの１つまたはいくつかへそれらをトンネリングさせることによって、そのモバイル・ノードにモビリティ・サービスを提供してもよい。

経路最適化ヘッダとは、経路非最適化ヘッダとは異なるタイプの第１種のヘッダである。本発明の一実施の形態において、これらの２つのタイプのヘッダは、あらかじめ経路最適化（ＲＯ）が少なくとも１度は行われたかどうかで互いに区別される。つまり、経路非最適化ヘッダはＲＯが行われなかった場合に使用されるのに対し、経路最適化ヘッダは、通常、ＲＯが行われた後に使用される。

ゲートウェイとは、通信ネットワーク内の物理エンティティを示す中間ノードである。特に、ゲートウェイは、モバイル・ノードとそのモバイル・ノードのホーム・エージェントとの間に位置するルータである。本発明の一実施の形態において、ゲートウェイは、３ＧＰＰネットワークとＷＬＡＮネットワーク間の交差点を示してもよい。ゲートウェイとホーム・エージェントが２つの個々のエンティティとして実現されれば好都合である。１つのノードがいくつかの機能エンティティを有してもよい。機能エンティティとは、ノードまたはそのネットワークの他の機能エンティティに対して所定の機能群を実現するおよび／または提供するソフトウェア・モジュールまたはハードウェア・モジュールのことである。ノードはそれぞれ、ノードの通信が可能な通信設備または通信媒体に自身を接続する１つまたは複数のインタフェースを有してもよい。同様に、ネットワーク・エンティティは、他の機能エンティティまたは通信相手ノードとの通信が可能な通信設備または通信媒体にこの機能エンティティを接続する論理インタフェースを有してもよい。

ＩＰカプセル化ヘッダとは、ＩＰトンネルを介してデータ・パケットを送信するために使用されるヘッダである。このヘッダは、ペイロードおよびそのペイロードの元のＩＰヘッダをカプセル化する。ＩＰカプセル化ヘッダはＩＰカプセルヘッダであってもよい。

図４に、パケット・ヘッダに関するＭＩＰｖ６の２つの動作モードを比較したものを示す。図４の上部には、前述の節ですでに説明したように、ＨＡ１０５、１０６により適用されるＩＰ−ｉｎ−ＩＰカプセル化が示されている。図４の下部では、ＲＯ処理がＭＮ１０２により開始および実行された後、経路最適化された経路がＣＮ１０１とＭＮ１０２との間で使用されている。そのＲＯの結果、ＣＮ１０１は、ＨＡ１０５、１０６を通る迂回をなくし、それによりＩＰ−ｉｎ−ＩＰカプセル化を回避することにより、自身のＣｏＡからＭＮ１０２のＣｏＡへデータ・パケットを直接送信する。あるいは、ターゲットの受信アプリケーションのアドレスを示す、ＭＮ１０２のホーム・アドレスを含む通信相手ノードにより、経路最適化ヘッダ・オプション（Ｒ．Ｈ．Ｏ．）が挿入される。上記Ｒ．Ｈ．Ｏ．は、ＣＮへパケットを送信するためのアプリケーション（例えば、ＨＴＴＰ）で使用されるＭＮのＩＰアドレス（ＨｏＡ）を含む。従って、ＭＮは、パケット受信後、そのパケットがどのアプリケーションに属するかをＲ．Ｈ．Ｏ．のアドレスに基づき導き出すことができる。これに対応して、ＭＮはＨＡ（ＣＮ）を介してＣＮにデータ・パケットを送信する。その際、ＭＮは、自身のＣｏＡを送信元アドレスとして用い、自身のＨｏＡをホーム・アドレス・オプション（Ｈ．Ａ．Ｏ．）フィールドに挿入することで、どれが送信アプリケーション・アドレスかをＣＮに示す。

経路最適化モードで使用されるＩＰヘッダのサイズは、双方向トンネリング・モードのＩＰ‐ｉｎ‐ＩＰヘッダよりも小さいので、ＭＮ１０２のネットワークにおけるトラフィック・ロードが軽減される。例えば、ＭＩＰで使用される追加ＩＰヘッダが４０バイトであるのに対し、Ｒ．Ｈ．Ｏ．フィールドおよびＨ．Ａ．Ｏ．フィールドのサイズはそれぞれ２４バイト、２０バイトである。そのため、ＭＮとＣＮ間のデータ経路の最適化は別として、経路最適化処理により、経路非最適化モードと比べて、データ・パケットのヘッダ・サイズが大幅に低減できることは明らかである。

しかしながら、データ・パケットにルーティング・ヘッダ・オプションを挿入することから生じる欠点の１つとして、図４からも分かるように、ＣＮ１０１のネットワークにおけるトラフィックが、双方向トンネリングの場合に比べて、増大してしまうということがある。各データ・パケットは、アップリンク・データ・パケット用の２０バイトを有するＨ．Ａ．Ｏ．またはダウンリンク・データ・パケット用の２４バイトを有するＲ．Ｈ．Ｏ．である、追加ルーティング・オプション・フィールドを含む。さらに、ＨＡ（ＭＮ）１０５は、ＲＯ実行後、ＣＮ１０１からＭＮ１０２へ向かうダウンリンク方向の通信中にバイパスされるが、これは一部の機器およびサービスには適用できない場合がある。例えば、運営会社は、アカウンティングやセキュリティの理由から、すべてのトラフィックを管理し続ける必要がある、つまり、すべてのデータはＨＡ（ＭＮ）１０５を介して転送されなければならない。さらに他の欠点としては、ＣＮ１０１への、または、ＣＮ１０１からのシグナリング・トラフィックが実際のＲＯ処理により生じるということがある。さらに、ＣＮ１０１は、データ・パケット内でのＣｏＡが位置依存性を有するため、ＭＮの物理的な位置を導き出すことがあり、これは必然的にＭＮの位置プライバシーに影響を与えることになる。

本発明の実施の形態では、通常のＲＯに伴う弊害を回避しつつ、パケット・ヘッダ・サイズを低減させる利点を活用する。

図５は、ＭＩＰｖ６でのＲＯに対して行われるシグナリング・フロー、および、そこで使用されるほとんどのメッセージのパケット・フォーマットを示す図である。通信相手ノードに送られるバインディング・アップデートの保護には、セキュリティ・アソシエーションの設定や、モバイル・ノードと通信相手ノード間の認証インフラストラクチャの存在は必要とされない。その代りに、リターン・ルータビリティ手順と呼ばれる手法を用いて、正しいモバイル・ノードがメッセージを送っているということを保証する。

リターン・ルータビリティ手順は、通信相手ノードが、モバイル・ノードはそれが主張する気付アドレスおよびホーム・アドレスで実際に宛先となることができるというそれなりの保証を得ることを可能にする。この保証が得られた場合のみ、通信相手ノードはモバイル・ノードからのバインディング・アップデートを受理することができ、その後モバイル・ノードは通信相手ノードにそのモバイル・ノードのデータ・トラフィックをその主張された気付アドレスへ転送するよう指示する。

これは、上記主張された２つのアドレス宛てのパケットがモバイル・ノードにルーティングされたか否かをテストすることで行われる。モバイル・ノードは、通信相手ノードがそれらのアドレスに送った特定のデータ（“鍵生成トークン”）を受信したという証拠を提供できる場合のみ、そのテストに合格することができる。これらのデータは、モバイル・ノードにより結合され、バインディング管理キーとなる。通信相手ノードへのバインディング・アップデートメッセージの完全性および信頼性は、バインディング管理キーを使用することで保護される。

具体的には、それぞれ異なる経路を介してではあるが、２つのメッセージがＭＮによりＣＮ１０１へと送信される。そのうちの１つ−ホーム・テスト開始（ＨｏＴｉ）メッセージ−がＭＩＰのＩＰ‐ｉｎ‐ＩＰトンネルを介してＨＡに送信され、その結果としてＨＡはそのメッセージをＣＮ１０１に転送する。モバイル・ノードは、ホーム・テスト開始メッセージを（ホーム・エージェントを介して）通信相手ノードに送信し、ホーム鍵生成トークンを取得する。図５からも分かるように、メッセージは、ＣＮ１０１が後に返送しなければならないホーム開始クッキー（Ｃｏｏｋｉｅ）を含み、ＭＮ１０２のホーム・アドレスをＣＮに伝達する。他方のメッセージ―気付テスト開始（ＣｏＴｉ）―は、気付鍵生成トークンを取得するため直接ＣＮ１０１に送信される。ＣｏＴｉメッセージは、ＭＮの現在の気付アドレスをＣＮ１０１に通知し、気付開始クッキーを含む。

ＨｏＴｉメッセージおよびＣｏＴｉメッセージを受信した後、ＣＮ１０１はＭＮ１０２へ２つのメッセージを返送する。この場合も、メッセージは異なる経路を介して送られる。ホーム・テスト（ＨｏＴ）メッセージは、ＨｏＴｉメッセージに応答して、ＭＮのＨｏＡ、すなわち、ＨＡ１０５へ送信される。そして、ＨＡ１０５はそのメッセージをＭＩＰｖ６トンネルを介してＭＮ１０２へ送信する。それに対し、気付テスト（ＣｏＴ）メッセージは直接ＭＮ１０２へと送信される。ＨｏＴメッセージおよびＣｏＴメッセージの両メッセージは、上記ＨｏＴｉメッセージおよびＣｏＴｉメッセージから受け取ったホーム開始クッキーと気付開始クッキーと共に、それぞれ、“ホーム鍵生成トークン”と“気付鍵生成トークン”を含む。トークンは、いずれも、ＣＮの現在有効な秘密鍵と、ノンスと、ホーム・アドレスまたは気付アドレスとに基づいている。

ＨｏＴメッセージおよびＣｏＴメッセージがＭＮに到着した後、ＭＮはそれらの鍵生成トークンを使って、ＨｏＴメッセージおよびＣｏＴメッセージと共に受け取ったトークンからバインディング管理キーを生成する。バインディング管理キーを作成した後、モバイル・ノードは検証可能なバインディング・アップデートを通信相手ノードに提供する。ＣＮ１０１は、そのバインディング・アップデートメッセージを受領した後、ＭＮのＨｏＡおよびＣｏＡのバインディングにより、自身のバインディング・キャッシュを更新することができ、データ・パケットをＭＮ１０２へ直接送信することが可能となる。

このように、ＭＩＰｖ６は、ＣＮ１０１においてＭＮ１０２のＨｏＡおよびＣｏＡのマッピングを確立することにより、ＣＮ１０１とＭＮ１０２との間の経路最適化を可能にする。

図４の下部に戻り、経路最適化モードでは、ＭＮ１０２は、ＭＮの気付アドレスを送信元アドレスとして用い、ＭＩＰｖ６のために定義された特別なＩＰｖ６経路最適化ヘッダ・オプションにＭＮのホーム・アドレスを組み込むことで、まずはＨＡ（ＣＮ）１０６にデータ・パケットを送信する。ＨＡ（ＣＮ）１０６は、そのデータ・パケットをカプセル化し、ＭＩＰｖ６トンネルを介してＣＮ１０１に送信する。それにより、ＣＮ１０１は、宛先アドレス・フィールド内のＭＮの気付アドレスを用い、ＭＩＰｖ６のために定義された特別なＩＰｖ６経路最適化ヘッダ・オプションにＭＮのホーム・アドレスを組み込むことで、データを直接ＭＮ１０２へ送信する。

以下において、本発明の様々な実施の形態が適用可能な、例示的なネットワーク・アーキテクチャを説明する。

図６は、Ｉ−ＷＬＡＮアーキテクチャの簡単な概要を示す図であり、図中において、パケット・データ・ゲートウェイ（ＰＤＧ）１０３は外部ＩＰネットワークへのＷＬＡＮ ３ＧＰＰ ＩＰアクセスをサポートする。また、ＷＬＡＮは、ＷＬＡＮアクセス・ポイントと中間ＡＡＡ（認証、許可、アカウンティング）要素を含む。ＷＬＡＮは、さらに、ルータなどの他のデバイスを含んでもよい。ＷＬＡＮ対応ＭＮは、コンピュータ、ＷＬＡＮ無線インターフェース・アダプタなど、エンド・ユーザーが所有するあらゆる機器を含む。ＷＬＡＮにアタッチしたＭＮは、インターネットに直接アクセス（直接ＩＰアクセスと称す）してもよいし、３ＧＰＰ運営会社に接続して運営会社のサービスを利用してもよい。運営会社は一般的にＭＮのトラフィックを管理し続けたいので、ＭＮは３ＧＰＰ運営会社を介して、すなわち、ＰＤＧを介してデータ・サービスにアクセスするのが普通である。

モバイル・ノードがＷＬＡＮにアタッチする場合、ＭＮは、ＷＬＡＮネットワークにローカルＩＰアドレス（ＭＮ_LA）を設定し、その設定されたＭＮ_LAを使ってＰＤＧにＩＰｓｅｃトンネルを確立する。このＭＮ_LAは、通信相手ノードとの通信には使用されず、ＭＮがＷＬＡＮネットワークにおいてのみ、また、ＰＤＧとの通信を行うために使用するアドレスである。ＰＤＧとのＩＰｓｅｃトンネル（セキュリティ・アソシエーションなど）を確立した後、ＭＮはＰＤＧのＩＰプレフィックスに基づきリモートＩＰアドレスを設定する。当該リモートＩＰアドレスは、ＭＮがＨＡと通信を行う際に、ＭＮの新しいＣｏＡとして利用される。その後、ＭＮは、自身のＨＡにＣｏＡ（ＰＤＧのネットワークからのリモートＩＰアドレス）を登録するためＭＩＰ手順を実行しなければならない。そうすることでのみ、ＭＮは、ＷＬＡＮネットワークへのハンドオーバ以前に３ＧＰＰネットワークにおいてサービスを開始するために使用されていた自身の初期ホームＩＰアドレスを使用し続けることができる。従って、ＭＮは、それ自身とそのＨＡ間に確立されたＭＩＰｖ６トンネルを介して、ＣＮとデータ・パケットを送受信する。Ｉ−ＷＬＡＮの場合、ＨＡは、ＳＡＥ（システム・アーキテクチャ・エボリューション）アンカーにおいて実装されてもよい。

図７は、Ｉ−ＷＬＡＮアーキテクチャのプロトコル・スタックを示す図である。ここで、図７にはＷＬＡＮアクセス・ネットワーク（ＡＮ）とＷＬＡＮアクセス・ゲートウェイ（ＷＡＧ）も示されているが、それらは本発明では重要ではないので、さらには説明しない。ＭＮのリモートＩＰ層は、外部パケット・データ・ネットワークで宛先となるようＭＮにより使用され、該ネットワークでは、ＭＮのリモートＩＰアドレスは外部エンティティとの通信に利用される。図７の下部には、ＣＮから送信されたデータ・パケットがＭＮへ向かう途中の状態で示されており、ヘッダ・フォーマットが詳細に図示されている。図からも分かるように、ＰＤＧはリモートＩＰパケットを変更せずに処理するが、トンネリング層はトンネリング・ヘッダ内でリモートＩＰパケットをカプセル化する。それにより、ＭＮとＰＤＧとの間のエンド・ツー・エンドのトンネリングが可能になる。さらに、トランスポートＩＰ層は、中間エンティティや中間ネットワーク、および、ＷＬＡＮアクセス・ネットワークがリモートＩＰ層パケットを移送することを可能とし、ＭＮはこの層においてそのローカルＩＰアドレスにより宛先となる。トンネリング層は、トランスポート層と共に、トンネル・モードでＩＰｓｅｃプロトコルにより実装されてもよい。

一般的に、ＩＰｓｅｃは、他のプロトコルやアプリケーションが安全に通信できるよう、ＩＰ層においてセキュリティ・サービスを提供する。つまり、ＩＰｓｅｃは、安全でない中間システムを介して通信する２つのノードの間に安全なパスを設置する。この点において、ＩＰｓｅｃは、セキュリティ・サービスを提供するためのいつくかの構成要素から成り、そのうちの２つの主要構成要素として、認証ヘッダ（ＡＨ）プロトコルとカプセル化セキュリティ・ペイロード（ＥＳＰ：Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ）プロトコルがある。これらのプロトコルは、特定のヘッダをＩＰデータ・パケットに付加することでＩＰデータに信頼性およびプライバシーを提供する。

再び図７を参照し、ＭＮのローカル・アドレス（ＭＮ_LA）を宛先アドレスとして用い、ＰＤＧのアドレスを送信元アドレスとして用い、カプセル化セキュリティ・ペイロード（ＥＳＰ、長さ８バイト）を、対応するオプション・フィールドに組み込むことで、元のデータ・パケットはＩＰｓｅｃヘッダ内にカプセル化される。新しくカプセル化されたパケット、すなわち、元のデータ・パケットのペイロードが暗号化される。さらに、ＥＳＰはデータ・パケットの送信元としての信頼性、完全性、機密性を提供するが、ＩＰｓｅｃトンネルにより付加されたパケット・オーバーヘッドは合計４８バイトとなる。

以下に示す本発明の実施の形態は３ＧＰＰ−ＷＬＡＮアーキテクチャに限定されるが、ＭＮのネットワークにおけるその他のアクセス技術が可能であり、本発明のメカニズムも適宜適用可能である。その他の可能なアクセス技術としては、例えば、ＷＩＭＡＸ（ワールドワイド・インターオペラビリティ・フォー・マイクロウェーブ・アクセス）が挙げられる。

図８に通信システムを示す。図８において、モバイル・ノードは、ワイヤレス・ローカルエリア・ネットワーク（ＷＬＡＮｓ）１２０内に位置し、該ネットワークにおいて、パケット・データ・ゲートウェイ（ＰＤＧ）１０３によりＭＮ１０２がＷＬＡＮから外部ＩＰネットワークにアクセス可能となる。上記説明したように、ＩＰｓｅｃトンネルはＰＤＧ１０３とＭＮ１０２間のセキュリティ保護のため利用されるということも想定される。詳しく言うと、ＭＮとＰＤＧとの間で交換されるすべてのデータ・パケットおよびシグナリング・メッセージはこのＩＰｓｅｃトンネルを介して流れている。

ＣＮ１０１とＭＮ１０２間の通常の通信が、交換されたデータ・パケットの採用されたヘッダの詳細な図示と共に、ダウンリンクおよびアップリンクにおいて示されている。具体的には、ＣＮ１０１からのダウンリンクを参照した場合、元のデータ・パケットはＩＰヘッダを含み、ＩＰヘッダにおいて、ＣＮのＨｏＡは送信元アドレスであり、ＭＮのＨｏＡは宛先アドレスとして使用される。そして、データ・パケットはＭＩＰｖ６トンネルを介してＨＡ（ＣＮ）１０６へルーティングされる。ＭＩＰｖ６トンネルは、ホーム・ネットワークのある特定のＳＡＥにおける機能として組み込まれてもよい。しかしながら、ＨＡ（ＣＮ）１０６はホーム・ネットワークにおいても別のエンティティである、もしくは、異なるエンティティ内に実装される場合もあることに留意されたい。ＨＡ（ＣＮ）からＨＡ（ＭＮ）へ向かうダウンリンクにおいて、データ・パケットはＭＩＰｖ６トンネルを介して交換されるのではなく、それらの宛先アドレスに従ってルーティングされる。

一般的なＭＩＰｖ６手順に従って、ＨＡ（ＭＮ）はその後ＣＮ１０１からの元のデータ・パケットを追加ＩＰヘッダを有するペイロードとしてカプセル化する。該ＩＰヘッダは、自身のアドレスを送信元アドレスとして、ＭＮの気付アドレスを宛先アドレスとして含む。このＩＰ−ｉｎ−ＩＰカプセル化により、データ・パケットにもう４０バイト付加される。ＭＮのＣｏＡはＰＤＧのＩＰプレフィックスに基づいているため、データ・パケットはＰＤＧ１０３に到着し、ＰＤＧ１０３はＭＮ１０２が接続されているＷＬＡＮ１２０へのアクセスを提供する。ＰＤＧ１０３はＩＰｓｅｃトンネルの一終端であるので、ＰＤＧはＨＡ（ＭＮ）から受け取ったデータ・パケットをＩＰｓｅｃヘッダ構成内でカプセル化し、実際ここで全受信データ・パケットであるペイロードを暗号化する。具体的には、ＰＤＧにより作成されたＩＰｓｅｃヘッダは、ＰＤＧのアドレスを送信元アドレスとして、ＭＮのローカル・アドレスをローカル・ネットワーク内の宛先アドレスとして含み、対応するヘッダ・フィールドにＥＳＰを加える。このＩＰｓｅｃトンネリングにより、パケットにもう４８バイト付加され、そのパケットは、ＩＰ‐ｉｎ‐ＩＰトンネリングおよび通常のＩＰヘッダと共に、合計１２８バイトのオーバーヘッドとなる。

一方、ＭＮ１０２から送信されたデータ・パケットは、ＩＰｓｅｃヘッダ、ＩＰ‐ｉｎ‐ＩＰヘッダ、通常のＩＰヘッダと、３部にカプセル化される。それにより、データ・パケットはＣＮ１０１へ向かう途中でカプセル開放される、つまり、ＰＤＧがＩＰｓｅｃトンネルの終端であるのでＩＰｓｅｃヘッダがＰＤＧで取り除かれる。ＰＤＧはそのパケットをＨＡ（ＭＮ）へ転送し、ＨＡ（ＭＮ）でＩＰ‐ｉｎ‐ＩＰヘッダが取り除かれる。その後、ＨＡ（ＭＮ）は自身の方向にデータ・パケットを転送し、ＭＩＰｖ６トンネルを介してＣＮ１０１へデータ・パケットを送信するためそれらのデータ・パケットに対してＭＩＰｖ６カプセル化を適用する。

図９は、変更されたＲＯ処理のシグナリング・フローおよびメッセージ構造を示す図である。具体的には、図９は、本発明の一実施の形態に係る第１経路最適化処理の各手順を示す。この第１経路最適化処理は第１ステップとも呼ばれる。

ＭＮとＰＤＧ（ゲートウェイ）との間にＩＰｓｅｃに基づくセキュリティ・トンネルが確立され、すべてのデータ・パケットおよびシグナリング・メッセージはこのトンネルを介して流れている。このＩＰｓｅｃカプセル化が、シグナリング・フロー図に波形の線で示されているが、ＩＰｓｅｃヘッダはシグナリング・フロー図下方のメッセージ・フォーマットには図示されていない。メッセージ・フォーマットはＩＰヘッダを持つ実際のＲＯメッセージのみを示す。ＭＮがＷＬＡＮアクセス・ネットワークにアタッチした後、ＰＤＧは、ＭＮがＣＮの新しいＣｏＡはＰＤＧのＩＰアドレスであると見せかけている間に、第１ステップとして経路最適化処理を開始する。それにより、ＰＤＧ１０３は、ＣＮ１０１へ通知しないで、ＣＮ１０１に代わって機能する。ＰＤＧは、セッション開始プロトコル（ＳＩＰ）サーバまたはＭＮの通信相手に関する知識を持つコア・ネットワーク内の他のエンティティのようなポリシー・サーバやアプリケーション・サーバとコンタクトをとることにより、ＭＮ１０２と通信しているＣＮのＩＰアドレスを取得してもよい。

一方で、ＰＤＧは、ＣＮのＨｏＡアドレスを送信元アドレスとして、ＭＮのＨｏＡを宛先アドレスとして有する第１経路最適化処理のＨｏＴｉメッセージを生成する。さらに、ＰＤＧは、ＭＮによりＣＮのＣｏＡとして受領されるＰＤＧのＩＰアドレス自体を送信元アドレスとして、ＭＮのＨｏＡを宛先アドレスとして有する、ＭＮ１０２に対する第１経路最適化処理のＣｏＴｉメッセージを生成する。ＨｏＴｉメッセージおよびＣｏＴｉメッセージはいずれも経路最適化処理の開始メッセージと見なされてもよい。その後、ＨｏＴｉおよびＣｏＴｉは共にＭＮ１０２へ送信される。ＭＮ１０２はそれに対応してＨｏＴメッセージおよびＣｏＴメッセージで返答する。ＣｏＴメッセージはＰＤＧ１０３へと送られるが、ＨｏＴメッセージはＣＮのＨｏＡへと送られる。従って、ＰＤＧ１０３は、ＭＮ１０２とＣＮ１０１間のデータ通信を監視し、ＰＤＧ１０３により作成され送信されたＨｏＴｉメッセージに対する返答である、ＭＮ１０２からのＨｏＴメッセージをインターセプトしなければならない。

経路最適化処理において、ＨｏＴｉメッセージおよびＨｏＴメッセージはトンネルを介して送信されるので、ＰＤＧ１０３は、ＭＮとＣＮ１０１との間に確立されたトンネル内の暗号化されたメッセージを監視できない場合がある。それにより、ＰＤＧはＣＮのＨｏＡ宛てのＨｏＴメッセージを検出できなくなる。そのような場合、ＰＤＧ１０３は、第１経路最適化処理の第１開始メッセージ（ＨｏＴｉ）を直接ＭＮのＣｏＡへ送信する必要がある。それに対し、ＭＮは、現在ＰＤＧ１０３により監視およびインターセプト可能となる第１経路最適化処理の第１応答メッセージ（ＨｏＴ）で返答する。ＨｏＴメッセージをＭＩＰトンネルを介して送信しないようにするため、ＭＮ１０２は、ＨｏＴｉメッセージがＭＩＰトンネルを介して受信されなかったことを認識することができる。このＭＮ１０２の動作は、ＭＮ１０２のネットワーク・アタッチ処理中にＰＤＧ１０３によって起動されてもよい。つまり、ＭＩＰトンネルを介さずＨｏＴメッセージを送信する機能は、ＭＮ１０２のネットワーク・アタッチ中に、まずＰＤＧ１０３によって要求されなければならない。この手段をとることにより、攻撃者がＭＩＰトンネルを介して送信されなかったメッセージをインターセプトするために行使するセキュリティ脅威を回避することができる。

ＰＤＧ１０３はＨｏＴメッセージおよびＣｏＴメッセージの両方を受信した後、バインディング・アップデート（ＢＵ）メッセージを生成し、ＭＮ１０２へ送信する。ＢＵメッセージは、ＣＮのＣｏＡを送信元アドレスとして、ＭＮのＨｏＡを宛先アドレスとして含む。

図１０に、ＣＮ１０１に代わって機能するゲートウェイ１０３によって第１経路最適化処理が終了した後のデータ・パケット・フォーマットを示す。第１ステップが完了すると、ＭＮ１０２はデータ・パケットを、ＰＤＧ１０３である直接ＣＮのＣｏＡへアップリンク方向に送信する。ＭＮ１０２は、データ・パケットに対し、通常のＩＰヘッダ以外に、ＣＮのＣｏＡ（前のＩＰヘッダの宛先アドレス）をＲ．Ｈ．Ｏ．となる経路最適化ヘッダ・オプションとして含む経路最適化ヘッダを使う。前のＭＩＰヘッダは削除される。さらに、データ・パケットは、ＩＰｓｅｃトンネル・モードにより送信される。図１０に示すように、アップリンク方向では、ＲＯ実行前のオーバーヘッドに比べて削減されたデータ・パケットのオーバーヘッドを使うことで、ＭＮ１０２とＰＤＧ１０３との間でデータが交換される。暗号化されたデータ・パケットがＰＤＧ１０３を通過する際、ＰＤＧは、あたかもＲＯが行われなかったかのように元のパケット・ヘッダを復元し、それらのパケットをさらにＣＮ１０１へと送信する。

ダウンリンク方向では、ＰＤＧ１０３は、データ・パケットのオーバーヘッド（ＭＩＰヘッダおよびＩＰヘッダ）に、さらに、ＩＰヘッダの送信元アドレスをＨ．Ａ．Ｏ．となる経路最適化ヘッダ・オプションとして含む。さらに、ＰＤＧ１０３は、送信元アドレスとして自身のＩＰアドレスを通常のＩＰヘッダに挿入し、ＩＰｓｅｃトンネル・モードおよびＭＩＰトンネルを介して、経路最適化ヘッダを持つデータ・パケットをＭＮ１０２へ送信する。つまり、ＰＤＧ１０３は、あたかもＣＮがＲＯにおいて実行し、ＣＮのＣｏＡがＰＤＧのＩＰアドレスであるかのように、ＨＡ（ＭＮ）１０５から受信したデータ・パケットを変更する。

ＭＮ１０２とＰＤＧ１０３間のデータ交換は、可読性を向上させるため、図１０には図示されていないＩＰｓｅｃトンネルを利用して行われる。

図１１に、本発明の他の実施の形態により、ＭＮ１０２が第２経路最適化を行った場合のシグナリング図およびメッセージ・フォーマットを示す。本実施形態では、経路最適化メッセージは、ゲートウェイ１０３によりＭＮ１０２へ直接送信される。特に、図１１は、本発明の一実施の形態に係る、第２経路最適化処理の各手順を示す。この第２経路最適化処理は第２ステップとも呼ばれる。

ＭＮ１０２とＰＤＧ１０３（ゲートウェイ）との間にＩＰｓｅｃに基づくセキュリティ・トンネルが確立され、すべてのデータ・パケットおよびシグナリング・メッセージはこのトンネルを介して流れている。このＩＰｓｅｃカプセル化が、シグナリング・フロー図に波形の線で示されているが、ＩＰｓｅｃヘッダはシグナリング・フロー図下方のメッセージ・フォーマットには図示されていない。メッセージ・フォーマットはＩＰヘッダを持つ実際のＲＯメッセージのみを示す。ＭＮ１０２とＨＡ（ＭＮ）１０５との間に、ＭＩＰｖ６トンネルが確立される。

図９および図１０に示す第１経路最適化処理が完了したら、ＭＮ１０２はＣＮ１０１に自身のローカルＩＰアドレス（ＭＮ_LA）を登録する。つまり、ＭＮ１０２は第２ＲＯを実行する。ＭＮはそのＭＮ_LAアドレスを非３ＧＰＰアクセス・ネットワーク、例えば、ＷＬＡＮから取得し、そのアドレスを新しいＣｏＡとして使う。

取得したＭＮ_LAを３ＧＰＰネットワークのＭＮに関するＣｏＡとして使用するためには、ＭＮ１０２の変更が必要である。他の変更としては、ＭＮ１０２が第２経路最適化を行うためにＣＮのＣｏＡを有利に使用することがある。ＭＮ１０２がＣＮのＨｏＡを使うかもしくはＣｏＡを使うかは通常定められていないが、本発明の目的として、ＭＮ１０２はＣＮのＣｏＡを使用する必要がある。

図１１に示す第２ステップによれば、ＭＮ１０２は、第１経路最適化処理によりＣＮのＣｏＡとしてＭＮ１０２にとって既知のＰＤＧのＩＰアドレスを宛先アドレスとして有するＨｏＴｉメッセージを生成する。ＨｏＴｉメッセージは、まず、ＭＮ１０２によりＭＩＰカプセル化され、ＭＩＰｖ６トンネルを介してＨＡ（ＭＮ）１０５へと送信される。ＨＡ（ＭＮ）１０５は、ＨｏＴｉメッセージを受け取り、ＭＩＰｖ６ヘッダを削除し、宛先アドレス（ＣＮのＣｏＡ）がＰＤＧ１０３であるので、そのＨｏＴｉメッセージをＰＤＧ１０３へ向けてルーティングする。ＨｏＴｉメッセージを受信したら、ＰＤＧ１０３は応答メッセージとしてＨｏＴメッセージを生成する。

ＰＤＧ１０３がＭＮ１０２へＨｏＴメッセージを送信する方法として、以下の２つのオプションがある。
１．通常の場合、ＭＮ１０２は、ＨＡ（ＭＮ）１０５からＭＩＰｖ６トンネルを介してＨｏＴメッセージを受け取ると予測している。しかしながら、ＭＮ１０２がＨＡ（ＭＮ）１０５以外から送られてくるＨｏＴを受理するよう変更された場合、ＰＤＧ１０３はＨｏＴを直接ＭＮ１０２へ送信してもよい。これを図１１に示す。
２．一方、図１２は、ＭＮ１０２がＨＡ（ＭＮ）１０５からＭＩＰｖ６トンネルを介してＨｏＴメッセージを受信しなければならない場合のシグナリング・フロー、特に、ＨｏＴメッセージを示す。このような場合、ＰＤＧ１０３は、まず、ＨｏＴをＨＡ（ＭＮ）１０５へ送信しなければならない。ＨｏＴメッセージの宛先アドレスがＭＮのＨｏＡであるので、ＨｏＴはＨＡ（ＭＮ）１０５へと自然にルーティングされる。なぜなら、ＭＮのＨｏＡはＨＡ（ＭＮ）１０５（ＳＡＥアンカー）にアンカリングされるからである。ＨＡ（ＭＮ）は、次に、ＨｏＴメッセージを通常通り処理する必要がある、すなわち、ＨｏＴメッセージを、図１２に示すように、ＭＩＰｖ６トンネルを介してＭＮ１０２へとトンネリングする。

第２経路最適化処理によれば、さらに、ＭＮ１０２は、ＰＤＧ１０３に向かう安全なトンネルを介して、ＣＮのＣｏＡ（ＰＤＧ１０３）へＣｏＴｉメッセージを送信する。ＰＤＧ１０３は、ＣＮ１０１として機能する間に、そのＣｏＴｉメッセージを受信し、ＣｏＴメッセージを返信する。ＨｏＴとＣｏＴの両メッセージを受け取った後、ＭＮ１０２はバインディング・アップデートメッセージＢＵを生成し、そのメッセージをＰＤＧ１０３へ送信する。

あるいは、第２経路最適化を開始するため、ＭＮ１０２は、ＣＮのＨｏＡを宛先アドレスとして有するＨｏＴｉメッセージを生成してもよい。第２ＲＯのＨｏＴｉメッセージの宛先アドレスとしてＣＮのＣｏＡを使用するのとは対照的に、ＭＮがＣＮのＨｏＡを使いＭＩＰｖ６トンネルを介してＨｏＴｉメッセージを送信するには、ＨＡ（ＭＮ）１０５にいくつかの変更を行うことが必要である。ＭＩＰｖ６トンネルの終端はＨＡ（ＭＮ）１０５であるため、ＨＡ（ＭＮ）はＨｏＴｉメッセージをインターセプトし、それをＰＤＧへとトンネリングするよう変更されてもよい。さらに、ＭＮは同様にＣｏＴｉメッセージをＣＮのＨｏＡへ送るが、メッセージは常にＩＰｓｅｃトンネルを通ってＰＤＧへと流れているため、ＰＤＧはＣｏＴｉをインターセプトする。その後、ＰＤＧは、ＣＮのＨｏＡを送信元アドレスとして有するＨｏＴメッセージを生成し、そのメッセージをまずトンネルを介してＨＡ（ＭＮ）へ送信する。ＨＡ（ＭＮ）はそのＨｏＴメッセージをＭＩＰｖ６トンネルにカプセル化し、ＭＮへと送信する。ＰＤＧは、ＣＮのＨｏＡを送信元アドレスとして有するＣｏＴメッセージを生成し、そのメッセージを直接ＭＮへ送信する。ＨｏＴとＣｏＴの両メッセージを受信すると、ＭＮはバインディング・アップデートを生成し、ＰＤＧにインターセプトされることとなるそのＢＵをＣＮのＨｏＡへ送信する。

ＭＮ１０２によって生成された、第２経路最適化処理の完了を示すバインディング・アップデートメッセージを受信したら、ゲートウェイ１０３は、内部データベースにマッピング・エントリを確立する。このマッピング・エントリは、第１および第２経路最適化処理が行われたＭＮ１０２から送られてくるデータ・パケットが、与えられたＨＡ（ＭＮ）１０５へのＭＩＰｖ６トンネルにカプセル化されなければならないという情報を含む。このデータ・パケットは、ＨＡ（ＭＮ）１０５のＩＰアドレスを宛先アドレスとして、ＭＮのＣｏＡを送信元アドレスとして含む、外部ＭＩＰｖ６トンネル・ヘッダを有している。例えば、マッピング・エントリは、ＨＡ（ＭＮ）１０５のＩＰアドレスおよびＭＮのＣｏＡに対応するＭＮ_LAアドレスを有してもよい。ゲートウェイ１０３が多数のホーム・エージェントと接続しており、どのＭＮ１０２がどのホーム・エージェントに接続されているか、とりわけ、ＭＮのＣｏＡはどれかをゲートウェイ１０３が把握しなければならない場合、ゲートウェイ１０５におけるこのマッピング・エントリが必要となる。さらに、マッピング・エントリによって、全経路最適化処理はＣＮ１０１およびＨＡ（ＭＮ）１０５にとってトランスペアレントであり続けることができる。

上記のように、２つの経路最適化ステップでは、２つの経路最適化ヘッダ・オプション（Ｒ．Ｈ．Ｏ．およびＨ．Ａ．Ｏ．）が挿入される一方で、ＭＩＰヘッダが削除される。例えば、ダウンリンク方向では、各データ・パケットの新しいオーバーヘッドは、ＰＤＧ１０３のＩＰアドレスを送信元アドレスとして、ＭＮＬＡアドレスを宛先アドレスとして含み、さらに、上記２つの経路最適化ヘッダ・オプションＲ．Ｈ．Ｏ．、Ｈ．Ａ．Ｏ．も含む。

第２経路最適化処理が終了した後も、データ・パケットは、ＩＰｓｅｃトンネルを介してＰＤＧとＭＮとの間で送信される。上記２つの経路最適化を行うことで、ＩＰｓｅｃトンネル・ヘッダは、ＩＰヘッダと同じ送信元アドレスおよび宛先アドレスを備えることとなる。そこで、ＰＤＧとＭＮ間のデータ・パス上でＩＰｓｅｃモードがＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードにここで切り替えられる場合、同じ送信元アドレスおよび宛先アドレスを持つ２つのヘッダの内の１つだけの使用を利用できる。従って、ＰＤＧとＭＮ間に新しく確立された、上記初期ＩＰｓｅｃトンネルの代わりになる、トランスポート・モードのＩＰセキュリティ・アソシエーションを使用することにより、効果的かつ大幅なデータ・パケット・オーバーヘッドの削減が実現される。

ＩＰｓｅｃトンネル・モードをＩＰｓｅｃトランスポート・モードと置き換えた後、新しいデータ・パケット・オーバーヘッドをＩＰヘッダ、２つの経路最適化ヘッダ・オプションＲ．Ｈ．Ｏ．、Ｈ．Ａ．ＯおよびＥＳＰフィールドだけで構成する。

概して、トランスポート・モード・セキュリティ・アソシエーション（ＳＡ）は一般的には、エンド・ツー・エンドのセキュリティ・サービスを提供するため１対のホストの間に採用される。中間システム間（もしくはホストと中間システム間）でセキュリティが望まれる場合、多くの場合トンネル・モードのＩＰｓｅｃが配備される。ＭＮ１０２とＰＤＧ１０３が２つの理由に基づきトランスポート・モードのＩＰｓｅｃＳＡを確立することが提案されている。一方は、ＭＮ１０２とＰＤＧ１０３間の通信はＭＮの視点からはエンド・ツー・エンド通信と見なしていること、他方は無線リンクを介したヘッダ・サイズの低減を目的としていることである。

トランスポート・モードＳＡのセットアップは、ＰＤＧ１０３またはＭＮ１０２によって開始されてもよい。なぜなら、両エンティティは互いをエンド・ツー・エンドの通信相手として見ているからである。しかしながら、トンネル・モードのＩＰｓｅｃＳＡのセットアップは、ＰＤＧ１０３によって行われることが好ましい。なぜなら、それによりＭＮ１０２に対する変更が少なくてすむからである。トランスポート・モードのＩＰｓｅｃＳＡが中間エンティティ（この場合、例えば、ＰＤＧ１０３）によって使われた場合、アウトバウンド・パケット（中間システムから、例えば、ダウンリンクでＭＮ１０２へ送られるパケット）の送信元アドレスと、インバウンド・パケット（ＭＮ１０２から中間システム、例えば、アップリンクで受信されるパケット）の宛先アドレスとが中間システム自体に属するアドレスであると好都合である。この状態は、両経路最適化処理が完了した後、ＰＤＧ１０３に対して実現される。

次に、図１３に示すように、両ＲＯが完了し、ＩＰｓｅｃモードが使用された後トランジション・エンティティとして機能するＰＤＧにより行われる、ダウンリンクおよびアップリンク方向のデータ・パケットへの変更について説明する。

ダウンリンク方向では、ＰＤＧが両ＲＯを行うことによりＭＩＰトンネル・ヘッダが経路非最適化ヘッダから削除され、２つの経路最適化ヘッダが挿入される。経路最適化ヘッダ・オプションＨ．Ａ．Ｏ．は、２０バイトの長さを有し、受信部へ正しい送信ＩＰアドレスを示し、ＨＡ（ＭＮ）とＰＤＧ間のデータ・パスにおける経路非最適化ヘッダのＩＰヘッダの送信元アドレスである。経路最適化ヘッダ・オプションＲ．Ｈ．Ｏ．は、２４バイトの長さを有し、受信部がアプリケーションの正しいポート番号を認識するために使用され、ＨＡ（ＭＮ）とＰＤＧ間のデータ・パスにおける経路非最適化ヘッダのＩＰヘッダの宛先アドレスである。また、ＩＰヘッダの宛先アドレスはＭＮ_LAアドレスであり、送信元アドレスはＰＤＧのＩＰアドレスである。その後、ＩＰｓｅｃトランスポート・モードが上述のようにＰＤＧとＭＮ間で適用され、その結果、追加ＥＳＰヘッダ・フィールドが得られる。

アップリンク方向では、ＰＤＧが、ＩＰヘッダ、２つの経路最適化ヘッダ・オプションＨ．Ａ．Ｏ．、Ｒ．Ｈ．Ｏ．およびＥＳＰヘッダ・フィールドを含むオーバーヘッドを有するデータ・パケットを受信する。ＰＤＧはそれらを受信後、２つの経路最適化ヘッダ・オプションＨ．Ａ．Ｏ．、Ｒ．Ｈ．Ｏ．およびＥＳＰヘッダ・フィールドを削除することで経路最適化ヘッダを経路非最適化ヘッダに変換する。さらに、ＰＤＧは、ＭＮのＣｏＡをＭＩＰトンネル・ヘッダの送信元アドレスとして、ＨＡ（ＭＮ）のＩＰアドレスを宛先アドレスとして使用し、データ・パケットをＭＩＰトンネルを介してアップリンク方向に送信する。それにより、ＰＤＧは、各経路最適化のオーバーヘッド削減がＨＡ（ＭＮ）およびＣＮに対してトランスペアレントであるように、データ・パケットのオーバーヘッドを変更する必要がある。これは、ＰＤＧとＨＡ（ＭＮ）間のデータ・パス上のパケットのフォーマットがＲＯ実行前のものと同じであることを意味する。そのため、経路最適化処理はＣＮから隠されている。

図１３は、２つの経路最適化処理が行われる前のデータ・パケット・フォーマットも示す。データ・パケット・オーバーヘッドは、通常のＩＰヘッダ、ＭＩＰヘッダおよびＩＰｓｅｃトンネル・ヘッダを含む。

つまり、本発明の実施の形態に係るＲＯを適用することにより、データ・パケット・オーバーヘッドの大幅な削減の達成が可能である。本発明のいずれかの実施の形態に係る経路最適化を行わないＰＤＧ１０３とＭＮ１０２間のデータ送信を考えた場合、３つのヘッダが必要となる。特に、これらのヘッダは通常のＩＰヘッダ、ＭＩＰｖ６ヘッダおよびＩＰｓｅｃヘッダである。両ＲＯと、ＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードへの切り替えを考えた場合、ＰＤＧ１０３とＭＮ１０２間では、両経路最適化ヘッダ・オプションと共に、１つのＩＰヘッダだけで済む。

図１３に示すように、オーバーヘッド削減はアップリンクおよびダウンリンク方向で対称形を成し、１パケットにつき３６バイトである。図示のように、ＲＯが行われる前のデータ・パケットのすべてのオーバーヘッドは１２８バイト（４８バイトのＩＰｓｅｃヘッダ＋４０バイトのＭＩＰトンネル・ヘッダ＋元のＩＰヘッダからの４０バイト）である。両ＲＯが行われ、ＩＰｓｅｃトンネル・モードがＩＰｓｅｃトランスポート・モードへ変更された後、データ・パケットのすべてのオーバーヘッドは９２バイト（４０バイトのＩＰヘッダ＋２４バイトのＲ．Ｈ．Ｏ．＋２０バイトのＨ．Ａ．Ｏ．＋８バイトのＥＳＰオプション・フィールド）となる。

この大幅なオーバーヘッド削減は、ＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードへの切り替えと共に経路最適化処理の結果である。これらの変更された経路最適化処理は、主にＰＤＧにおいて行われてもよい。しかしながら、上記実施の形態の実現は、上記本発明の背景技術の項で述べたような、経路最適化処理のリターン・ルータビリティ・シグナリングへの変更を必要としない。

図１３に示す新しいデータ・パケット・オーバーヘッドは、本発明の実施の形態に係る、経路最適化ヘッダを示し、経路最適化ヘッダはＭＮ１０２とＰＤＧ１０３間での両方向のデータ・パケット送信に利用される。図１３には、経路最適化処理の前後に暗号化されるデータ・パケットの部分も示されている。両ＲＯが行われた後、ＰＤＧ１０３とＭＮ１０２間におけるデータ・パケットの送信のため、データ・ペイロードのみがＩＰｓｅｃトランスポート・モードで暗号化される。

つまり、ＰＤＧ１０３は、ＭＮの通信相手ノードに関する情報、すなわち、ＣＮのＩＰアドレスに関する情報を持っていなければならない。この情報を持つことで、ＰＤＧ１０３は、ＣＮのＣｏＡとしてのＰＤＧのＩＰアドレスを設定するため、ＣＮ１０１に代わってＭＮ１０２と経路最適化処理を開始する必要がある。このため、ＰＤＧ１０３は、ＭＮおよびＣＮ部分の完全なＭＩＰｖ６リターン・ルータビリティおよび経路最適化機能を実現する。つまり、ＰＤＧ１０３は自身で、ＭＮ部分を示すＲＯを開始し、ＣＮ部分を示すＲＯシグナリングに応答することが可能である。

第１経路最適化処理では、ＨｏＴｉメッセージのＩＰ送信元アドレスがＣＮのＨｏＡである。そのため、ＰＤＧ１０３は、ＰＤＧのＩＰアドレスとは異なる送信元アドレスを有するデータ・パケットを生成し送信するよう変更されなければならない。一方、ＨｏＴメッセージの宛先ＩＰアドレスはＣＮのＨｏＡであり、ＰＤＧは自身のアドレスとは異なる宛先アドレスを有するＨｏＴを受信し、処理できなければならない。そのようなパケットを受信し処理するかどうかの判断は、パケットの送信元アドレスに基づきなされてもよい。パケットの送信元アドレスが、ＰＤＧ１０３と共にすでにＲＯを行ったＭＮ１０２に属する場合、ＰＤＧ１０３はＨｏＴメッセージを受信し処理してもよい。

さらに、ＰＤＧ１０３は、トランスポート・モードでＭＮ１０２との新しいＩＰｓｅｃアソシエーションのセットアップを開始すべきか否かを決定する機能を実装しなければならない。つまり、ＰＤＧ１０３はＩＰｓｅｃトンネル・モードからＩＰｓｅｃトランスポート・モードへと変更するか否かを決定しなければならない。従って、ＰＤＧ１０３は、両ＲＯが順調に完了しＭＮ_LAがＭＮのＣｏＡとして使われているかどうかを監視する。もしそうなら、ＰＤＧ１０３は、トランスポート・モードでＭＮ１０２との新しいＩＰｓｅｃアソシエーションを開始する。このトランスポート・モードの新しいＩＰｓｅｃアソシエーションは、ＭＮ１０２とＣＮ１０１間のセッションのためのデータ・パケットのみを送信するために利用される。ＭＮ１０２がその他のＣＮとのセッションを有する場合、それらのセッションのデータ・パケットはトンネル・モードの古いＩＰｓｅｃアソシエーションを介してＭＮ１０２とＰＤＧ１０３間で送信される。

第２ＲＯに関しては、ＰＤＧは、ＨｏＴメッセージを直接ＭＮ１０２へ、または、ＨＡ（ＭＮ）１０５を介して送信するか否かを判断する機能を実装する。ＭＮ１０２とＰＤＧ１０３間の通信の初めは、ＭＮ１０２は、ＣＮ１０１から直接ＨｏＴメッセージを受信する機能を実装しているかどうかをＰＤＧ１０３に通知する。この情報により、ＰＤＧ１０３はどのように第２ＲＯを進めていけば良いかを適切に判断することができる。ＰＤＧ１０３はＭＮ１０２がＨｏＴメッセージを直接受信可能であるという通知を受けた場合、ＰＤＧはＨｏＴメッセージを直接ＭＮ１０２へ送信してもよい。ＰＤＧ１０３がＭＮ１０２がＨｏＴメッセージを直接受信不可能であるという通知を受けた場合、ＰＤＧはＨｏＴメッセージを、その後そのＨｏＴメッセージをＭＮ１０２へトンネリングするＨＡ（ＭＮ）１０５に送信してよい。

さらにまた、ＰＤＧ１０３は、図１３および上記節に述べたように、ダウンリンクおよびアップリンク方向でデータ・パケットのＩＰヘッダを変更する機能を有する。

以下にＭＮに対して可能ないくつかの変更を説明する。

経路最適化の仕様は、ＭＮがＣＮのＨｏＡとＣＮのＣｏＡとの間にバインディングを有している場合、経路最適化を行うためにどのＩＰアドレス―ＣＮのＨｏＡまたはＣＮのＣｏＡ―がＭＮによって使用されるべきかについて定義していない。本発明の目的のためには、ＭＮはＣＮのＣｏＡを用いて経路最適化を行う必要がある。

第１ＲＯがＰＤＧにより完了した後、ＭＮは、第２ステップにおいて、ローカルＩＰアドレス（ＭＮ_LA）を経路最適化のＣｏＡとして利用する。通常、ＭＮは、ＰＤＧにより得られたＩＰアドレスをＣｏＡとして利用しなければならない。しかしながら、ＣＮのＣｏＡがＰＤＧのＩＰアドレスである場合、ＭＮは経路最適化を開始するためＭＮ_LAをＣｏＡとして利用可能であるという論理がＭＮで実現される。

さらに、ＭＮでの経路最適化の実施は、ＭＮによりＨＡ（ＭＮ）１０５からＭＩＰｖ６を介してだけではなく直接ＣＮ１０１から、本発明の場合直接ＰＤＧから、ＨｏＴメッセージを受信することができるように拡張される。ＭＮとＰＤＧ間のアソシエーションの初めには、ＭＮおよびＰＤＧが上記拡張を実施するか否かの情報を交換する。

ＭＮがＰＤＧへデータ・パケットを送信する方法には２つのオプションがある。１つはトンネル・モードのＩＰｓｅｃアソシエーションを介して、他方はトランスポート・モードのＩＰｓｅｃアソシエーションを介しての送信である。経路最適化の第１及び第２ステップが行われた特定のＣＮに対するデータ・パケットは、トランスポート・モードのＩＰｓｅｃアソシエーションを介して送信される。他のすべてのＣＮに対するデータ・パケットはトンネル・モードのＩＰｓｅｃアソシエーションを介して送信される。本発明の別の実施の形態は、ハードウェアおよびソフトウェアを用いた上述の様々な実施の形態の実現に関する。上述の本発明の様々な実施の形態はコンピュータ機器（プロセッサ）、例えば、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル・ゲートアレイ（ＦＰＧＡ）、または他のプログラマブル・ロジック・デバイスなどを用いて実現または実施し得ることが分かる。本発明の様々な実施の形態は、これらの機器の組み合わせによっても実施または具体化し得る。

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

Claims (45)

1. モバイル・ノードとゲートウェイ間の通信リンク上において、前記ゲートウェイを介して前記モバイル・ノードと通信相手ノードとの間で交換されるデータ・パケットのヘッダ・サイズを低減させる方法であって、前記方法は、
   前記モバイル・ノードが経路最適化ヘッダを使ってデータ・パケットを前記通信相手ノードへ送信するステップと、
   前記通信相手ノードが経路非最適化ヘッダを使ってデータ・パケットを前記モバイル・ノードへ送信するステップと、
   前記ゲートウェイが前記モバイル・ノードからのデータ・パケットの前記経路最適化ヘッダを、前記通信相手ノードが使用する経路非最適化ヘッダに変換するステップと、
   前記ゲートウェイが前記通信相手ノードからのデータ・パケットの前記経路非最適化ヘッダを、前記モバイル・ノードが使用する経路最適化ヘッダに変換するステップとを、
   有する方法。
2. 前記モバイル・ノードは、前記ゲートウェイと前記モバイル・ノード間において経路最適化処理を行った後、前記経路最適化ヘッダを利用し、前記経路最適化処理は、前記通信相手ノードに代わって前記ゲートウェイにより開始および実行される請求項１に記載の方法。
3. 前記ゲートウェイは、前記経路最適化処理を行うことにより、前記モバイル・ノードに前記通信相手ノードに関するすべてのデータ・パケットを前記ゲートウェイへ送信するよう指示し、前記ゲートウェイは、前記通信相手ノードの新しいＩＰアドレスが前記ゲートウェイのＩＰアドレスであることを前記モバイル・ノードに通知する請求項２に記載の方法。
4. 前記経路最適化処理は、前記ゲートウェイが前記通信相手ノードのＩＰアドレスを送信元アドレスとして使用し、前記モバイル・ノードへ第１開始メッセージを送信するステップと、
   前記ゲートウェイが自身のＩＰアドレスを送信元アドレスとして使用し、前記モバイル・ノード宛ての第２開始メッセージを送信するステップとを、
   更に有する請求項２から３のいずれか１つに記載の方法。
5. 前記ゲートウェイが、前記第１開始メッセージに応答して前記モバイル・ノードから送信された第１応答メッセージをインターセプトするステップと、
   前記ゲートウェイが、前記第２開始メッセージに応答して前記モバイル・ノードによって送信された第２応答メッセージを受信するステップとを、
   更に有する請求項２から４のいずれか１つに記載の方法。
6. 前記ゲートウェイは、前記第１および第２応答メッセージに応答して前記モバイル・ノードへバインディング・アップデートメッセージを送信した後、前記経路非最適化ヘッダの前記経路最適化ヘッダへの変換および前記経路最適化ヘッダの前記経路非最適化ヘッダへの変換を前記各データ・パケットに対して行う請求項１から５のいずれか１つに記載の方法。
7. ＩＰヘッダとＩＰトンネル・カプセル化ヘッダとを含む経路非最適化ヘッダを、ＩＰヘッダと経路最適化ヘッダ・オプションとを含む経路最適化ヘッダに変換するステップは、
   前記経路非最適化ヘッダから前記ＩＰトンネル・カプセル化ヘッダを取り除くステップと、
   前記経路非最適化ヘッダの前記ＩＰヘッダを新しいＩＰヘッダと置き換えるステップと、
   前記経路最適化ヘッダ・オプションを前記経路非最適化ヘッダに挿入するステップとを、
   有する請求項１から６のいずれか１つに記載の方法。
8. 前記経路非最適化ヘッダの前記ＩＰトンネル・カプセル化ヘッダは前記モバイル・ノードのホーム・エージェントのＩＰアドレスを送信元アドレスとして、前記モバイル・ノードの第１位置依存ＩＰアドレスを宛先アドレスとして含み、前記経路非最適化ヘッダに挿入される前記経路最適化ヘッダ・オプションは前記通信相手ノードの位置非依存ＩＰアドレスを含み、前記新しいＩＰヘッダは前記通信相手ノードの位置依存ＩＰアドレスを送信元アドレスとして、前記モバイル・ノードの位置非依存ＩＰアドレスを宛先アドレスとして含む請求項７に記載の方法。
9. 前記ゲートウェイが前記モバイル・ノードへバインディング・アップデートメッセージを送信した後、ＩＰヘッダと経路最適化ヘッダ・オプションとを含む経路最適化ヘッダを、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダとを含む経路非最適化ヘッダに変換するステップは、
   前記経路最適化ヘッダから前記経路最適化ヘッダ・オプションを取り除くステップと、
   前記経路最適化ヘッダの前記ＩＰヘッダを新しいＩＰヘッダと置き換えるステップと、
   前記ＩＰトンネル・カプセル化ヘッダを前記経路最適化ヘッダに挿入するステップとを、
   更に有する請求項１から８のいずれか１つに記載の方法。
10. 前記経路最適化ヘッダの前記経路最適化ヘッダ・オプションは前記通信相手ノードの位置非依存ＩＰアドレスを含み、前記経路最適化ヘッダに付加される前記ＩＰトンネル・カプセル化ヘッダは前記モバイル・ノードの第１位置依存ＩＰアドレスを送信元アドレスとして、前記モバイル・ノードのホーム・エージェントのＩＰアドレスを宛先アドレスとして含み、前記新しいＩＰヘッダは前記モバイル・ノードの位置非依存ＩＰアドレスを送信元アドレスとして、前記通信相手ノードの位置非依存ＩＰアドレスを宛先アドレスとして含む請求項９に記載の方法。
11. 前記通信相手ノードに代わって前記ゲートウェイにより開始および実行される第１経路最適化処理を前記ゲートウェイと前記モバイル・ノード間において行うステップと、
    前記第１経路最適化処理終了後、前記モバイル・ノードにより開始される第２経路最適化処理を、前記通信相手ノードに代わる前記ゲートウェイと前記モバイル・ノード間において行うステップと、
    前記第２経路最適化処理終了後、ペイロード暗号化を可能にするために、前記ゲートウェイと前記モバイル・ノードとの間でデータ・パケットを交換するための追加セキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替えるステップとを、
    行うことにより前記経路最適化ヘッダが得られる請求項１に記載の方法。
12. 前記ゲートウェイは、前記第１経路最適化処理を行うことにより、前記モバイル・ノードに前記通信相手ノード宛てのすべてのデータ・パケットを前記ゲートウェイへ送信するよう指示し、前記ゲートウェイは、前記通信相手ノードの新しいＩＰアドレスが前記ゲートウェイのＩＰアドレスであることを前記モバイル・ノードに通知し、前記モバイル・ノードは、前記第２経路最適化処理を行うことにより、前記ゲートウェイに前記モバイル・ノード宛てのすべてのデータ・パケットを前記モバイル・ノードの第１位置依存ＩＰアドレスへ送信するよう指示する請求項１１に記載の方法。
13. 前記第１経路最適化処理は、
    前記ゲートウェイが、前記通信相手ノードのＩＰアドレスを送信元アドレスとして使用し、前記第１経路最適化処理に対応する第１開始メッセージを前記モバイル・ノードへ送信するステップと、
    前記ゲートウェイが、自身のＩＰアドレスを送信元アドレスとして使用し、前記第１経路最適化処理に対応する第２開始メッセージを前記モバイル・ノードへ送信するステップとを更に有し、
    前記第２経路最適化処理は、
    前記モバイル・ノードが、自身の位置非依存ＩＰアドレスを送信元アドレスとして使用し、前記第２経路最適化処理に対応する第１開始メッセージを前記ゲートウェイへ送信するステップと、
    前記モバイル・ノードが、自身の第２位置依存ＩＰアドレスを送信元アドレスとして使用し、前記第２経路最適化処理に対応する第２開始メッセージを前記ゲートウェイへ送信するステップとを、
    更に有する請求項１１から１２のいずれか１つに記載の方法。
14. 前記ゲートウェイが、前記第１経路最適化処理の第１開始メッセージに応答して前記モバイル・ノードにより送信される、前記第１経路最適化処理に対応した前記通信相手ノード宛ての第１応答メッセージをインターセプトするステップと、
    前記ゲートウェイが、前記第１経路最適化処理の第２開始メッセージに応答して前記モバイル・ノードにより送信される、前記第１経路最適化処理の第２応答メッセージを受信するステップと、
    前記ゲートウェイが前記第１経路最適化処理の第１および第２応答メッセージを受信した後、前記ゲートウェイが前記モバイル・ノードへ第１バインディング・アップデートメッセージを送信するステップと、
    前記モバイル・ノードが、前記第２経路最適化処理の第１および第２開始メッセージに応答して前記ゲートウェイによりそれぞれ送信された前記第２経路最適化処理の第１および第２応答メッセージを受信するステップと、
    前記モバイル・ノードが前記第２経路最適化処理の第１および第２応答メッセージを受信した後、前記モバイル・ノードが前記ゲートウェイへ第２バインディング・アップデートメッセージを送信するステップとを、
    更に有する請求項１３に記載の方法。
15. 前記ゲートウェイは前記第２経路最適化に対応する前記第１応答メッセージを前記モバイル・ノードの前記ホーム・エージェントへ送信し、該ホーム・エージェントはその後前記第１応答メッセージを前記モバイル・ノードへトンネリングする、請求項１４に記載の方法。
16. 前記モバイル・ノードが前記第２経路最適化処理の前記第１および第２応答メッセージに応答して前記第２バインディング・アップデートメッセージを前記ゲートウェイへ送信し、前記ゲートウェイと前記モバイル・ノードとの間でデータ・パケットを交換するためのセキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替えた後、前記ゲートウェイは前記経路非最適化ヘッダの前記経路最適化ヘッダへの変換および前記経路最適化ヘッダの前記経路非最適化ヘッダへの変換を前記各データ・パケットに対して行う請求項１４または１５に記載の方法。
17. ＩＰヘッダとＩＰトンネル・カプセル化ヘッダとを含む経路非最適化ヘッダを、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１及び第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダに変換するステップは、
    前記経路非最適化ヘッダから前記ＩＰトンネル・カプセル化ヘッダを取り除くステップと、
    前記経路非最適化ヘッダの前記ＩＰヘッダを新しいＩＰヘッダと置き換えるステップと、
    前記第１及び第２経路最適化ヘッダ・オプションと前記ＩＰセキュリティ・オプション・フィールドを、前記経路非最適化ヘッダに挿入するステップとを、
    更に有する請求項１、１１から１６のいずれか１つに記載の方法。
18. 前記新しいＩＰヘッダは前記ゲートウェイのＩＰアドレスを送信元アドレスとして、前記モバイル・ノードの前記第２位置依存アドレスを宛先アドレスとして含み、第１経路最適化ヘッダ・オプションは前記経路非最適化ヘッダのＩＰヘッダに送信元アドレスとして含まれる前記通信相手ノードの位置非依存アドレスを含み、第２経路最適化ヘッダ・オプションは前記経路非最適化ヘッダのＩＰヘッダに宛先アドレスとして含まれる前記モバイル・ノードの位置非依存ＩＰアドレスを含む請求項１７に記載の方法。
19. ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１及び第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダを、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダとを含む経路非最適化ヘッダに変換するステップは、
    前記経路最適化ヘッダから前記第１及び第２経路最適化ヘッダ・オプションと前記ＩＰセキュリティ・オプション・フィールドを取り除くステップと、
    前記経路最適化ヘッダの前記ＩＰヘッダを新しいＩＰヘッダと置き換えるステップと、
    前記ＩＰトンネル・カプセル化ヘッダを前記経路最適化ヘッダに挿入するステップとを、
    有する請求項１、１１から１８のいずれか１つに記載の方法。
20. 前記新しいＩＰヘッダは前記第２経路最適化ヘッダ・オプションに含まれる前記モバイル・ノードの位置非依存アドレスを送信元アドレスとして含み、前記新しいＩＰヘッダは前記第１経路最適化ヘッダ・オプションに含まれる前記通信相手ノードの位置非依存アドレスを宛先アドレスとして含み、前記経路最適化ヘッダに挿入される前記ＩＰトンネル・カプセル化ヘッダは前記モバイル・ノードの第１位置依存ＩＰアドレスを送信元アドレスとして、前記モバイル・ノードのホーム・エージェントのＩＰアドレスを宛先アドレスとして含む請求項１９に記載の方法。
21. 前記ゲートウェイと前記モバイル・ノード間の前記セキュリティ・トンネルは、前記ゲートウェイおよびモバイル・ノードによって前記データ・パケットを交換するために用いられる第１セキュリティ送信モードにより確立され、前記ゲートウェイと前記モバイル・ノード間で交換される各データ・パケットのヘッダへのセキュリティ・オプション・フィールドの付加は第２セキュリティ送信モードで行われる請求項１１から２０のいずれか１つに記載の方法。
22. 前記第１セキュリティ送信モードは前記データ・パケット内のＩＰｓｅｃヘッダを使うＩＰｓｅｃトンネル・モードであり、前記第２セキュリティ送信モードは前記データ・パケット内のカプセル化セキュリティ・ペイロード・フィールドを使うＩＰｓｅｃトランスポート・モードである請求項２１に記載の方法。
23. 前記第１及び第２経路最適化処理を行った後、前記経路最適化ＩＰヘッダと、前記ゲートウェイと前記モバイル・ノード間の前記第１セキュリティ送信モードを介して前記データ・パケットをカプセル化するために用いられるヘッダとは、前記各送信元および宛先アドレス・フィールドにおいて同じＩＰアドレスを有し、前記第２セキュリティ送信モードを使うことにより、前記ＩＰヘッダのみが前記ゲートウェイと前記モバイル・ノードとの間でデータ・パケットを交換するために使用される請求項２１から２２のいずれか１つに記載の方法。
24. 前記第２経路最適化処理は、前記第２経路最適化処理の第１及び第２開始メッセージにおいて前記通信相手ノードの位置非依存ＩＰアドレスを宛先アドレスとして用いる前記モバイル・ノードによって開始および実行される請求項１１から２３のいずれか１つに記載の方法。
25. 前記第２経路最適化処理は、
    前記モバイル・ノードの前記ホーム・エージェントが前記第２経路最適化処理の第１開始メッセージをインターセプトし、それを前記ゲートウェイへトンネリングするステップと、
    前記ゲートウェイが、前記通信相手ノードの位置非依存ＩＰアドレスを送信元アドレスとして有する前記モバイル・ノードのホーム・エージェントへ、前記第２経路最適化処理の第１応答メッセージを送信するステップと、
    前記ホーム・エージェントが、前記ゲートウェイから受信した前記第２経路最適化処理の第１応答メッセージを前記モバイル・ノードへとトンネリングするステップと、
    前記モバイル・ノードが前記第２経路最適化処理の第１及び第２応答メッセージを受信した後、前記モバイル・ノードが第２バインディング・アップデートメッセージを生成し、それを前記通信相手ノードの位置非依存ＩＰアドレスへ送信するステップと、
    前記ゲートウェイが、前記モバイル・ノードから受信した前記第２バインディング・アップデートメッセージをインターセプトするステップとを、
    更に有する請求項１１から２４のいずれか１つに記載の方法。
26. 前記モバイル・ノードは複数の通信相手ノードと同時に通信し、前記第１及び第２経路最適化処理は、各通信相手ノードに対し個別に、前記ゲートウェイ及び前記モバイル・ノードによってそれぞれ開始および実行される請求項１１から２５のいずれか１つに記載の方法。
27. 前記ゲートウェイは前記モバイル・ノードと通信中のすべての通信相手ノードに関する情報を保持し、前記ゲートウェイは前記モバイル・ノードが送受信するデータ・パケットを監視することで、または、前記モバイル・ノードのホーム・エージェントからの情報を要求することで前記すべての通信相手ノードに関する情報を取得する請求項１から２６のいずれか１つに記載の方法。
28. モバイル・ノードとゲートウェイ間の通信リンク上において、前記ゲートウェイを介して前記モバイル・ノードと通信相手ノードとの間で交換されるデータ・パケットのヘッダ・サイズを低減させるためのゲートウェイであって、
    前記モバイル・ノードから送られてくるデータ・パケットであり、経路最適化ヘッダを含む前記データ・パケットを受信するよう構成された受信部であって、
    前記通信相手ノードから送られてくるデータ・パケットであり、経路非最適化ヘッダを含む前記データ・パケットを受信するよう更に構成された前記受信部と、
    前記モバイル・ノードから送られてくる前記データ・パケットの前記経路最適化ヘッダを前記経路非最適化ヘッダへと変換するよう構成された処理部であって、
    前記通信相手ノードから送られてくる前記データ・パケットの前記経路非最適化ヘッダを前記経路最適化ヘッダへと変換するよう更に構成された前記処理部と、
    前記経路最適化ヘッダを有する前記データ・パケットを前記モバイル・ノードへ送信するよう構成された送信部であって、
    前記経路非最適化ヘッダを有する前記データ・パケットを前記通信相手ノードへ送信するよう更に構成された送信部とを、
    有するゲートウェイ。
29. 前記ゲートウェイは前記モバイル・ノードと通信中のすべての通信相手ノードに関する情報を保持するよう構成され、前記ゲートウェイは前記モバイル・ノードとの間で送信されるデータ・パケットを監視することで、または、前記モバイル・ノードのホーム・エージェントからの情報を要求することで前記すべての通信相手ノードに関する情報を取得する請求項２８に記載のゲートウェイ。
30. 前記ゲートウェイは前記通信相手ノードに代わって前記モバイル・ノードと第１経路最適化を開始および実行するよう構成される請求項２８から２９のいずれか１つに記載のゲートウェイ。
31. 前記処理部は、前記通信相手ノードの位置非依存ＩＰアドレスを送信元アドレスとして、前記モバイル・ノードの位置非依存ＩＰアドレスを宛先アドレスとして有する前記第１経路最適化処理の第１開始メッセージを生成するよう構成され、
    前記ゲートウェイの前記送信部は、前記第１経路最適化処理の第１開始メッセージを前記モバイル・ノードへ送信するよう構成され、
    前記処理部は、前記通信相手ノードの位置依存ＩＰアドレスを送信元アドレスとして、前記モバイル・ノードの位置非依存ＩＰアドレスを宛先アドレスとして有する前記第１経路最適化処理の第２開始メッセージを生成するよう構成され、
    前記ゲートウェイの前記送信部は、前記第１経路最適化処理の第２開始メッセージを前記モバイル・ノードへ送信するよう構成され、
    前記ゲートウェイの前記受信部は、前記通信相手ノード宛ての、前記モバイル・ノードからの前記第１経路最適化処理の第１応答メッセージをインターセプトするよう構成された請求項２８から３０のいずれか１つに記載のゲートウェイ。
32. 前記処理部は、前記受信部が前記第１経路最適化処理の前記第１及び第２応答メッセージを受信した後、第１バインディング・アップデートメッセージを生成するよう構成され、前記送信部は前記第１バインディング・アップデートメッセージを、前記通信相手ノードの位置依存ＩＰアドレスを送信元アドレスとして有する前記モバイル・ノードへ送信するよう構成される請求項２８から３１のいずれか１つに記載のゲートウェイ。
33. 前記モバイル・ノードが前記通信相手ノードの位置依存ＩＰアドレスを送信元アドレスとして有する第２経路最適化の第１応答メッセージを受信可能である場合、前記ゲートウェイは前記第２経路最適化の第１応答メッセージを直接前記モバイル・ノードへ送信するよう構成され、前記モバイル・ノードが前記通信相手ノードの位置依存ＩＰアドレスを送信元アドレスとして有する第２経路最適化の第１応答メッセージを受信不可能である場合、前記ゲートウェイは前記第２経路最適化の第１応答メッセージを前記モバイル・ノードのホーム・エージェントへ送信するよう構成され、前記メッセージは前記モバイル・ノードのホーム・エージェントにより前記モバイル・ノードへトンネリングされる請求項２８から３２のいずれか１つに記載のゲートウェイ。
34. 前記ゲートウェイは前記第２経路最適化処理の第２バインディング・アップデートメッセージを受信した後、前記ゲートウェイと前記モバイル・ノードとの間でセキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替える請求項３３に記載のゲートウェイ。
35. 前記ゲートウェイは、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダとを含む前記経路非最適化ヘッダを、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１及び第２経路最適化ヘッダ・オプションとを含む前記経路最適化ヘッダに変換するよう構成され、
    前記処理部は、前記経路非最適化ヘッダからＩＰトンネル・カプセル化ヘッダを取り除くよう構成され、
    前記処理部は、さらに、前記経路非最適化ヘッダのＩＰヘッダを新しいＩＰヘッダと置き換えるよう構成され、
    前記処理部は、さらに、前記第１及び第２経路最適化ヘッダ・オプションと前記ＩＰセキュリティ・オプション・フィールドを前記経路非最適化ヘッダに挿入するよう構成される請求項２８から３４のいずれか１つに記載のゲートウェイ。
36. 前記ゲートウェイは、ＩＰヘッダとＩＰセキュリティ・オプション・フィールドと第１及び第２経路最適化ヘッダ・オプションとを含む経路最適化ヘッダを、ＩＰヘッダとＩＰトンネル・カプセル化ヘッダとを含む経路非最適化ヘッダに変換するよう構成され、
    前記処理部は、前記経路最適化ヘッダから前記第１及び第２経路最適化ヘッダ・オプションと前記ＩＰセキュリティ・オプション・フィールドを取り除くよう構成され、
    前記処理部は、前記経路最適化ヘッダのＩＰヘッダを新しいＩＰヘッダと置き換えるよう構成され、
    前記処理部は、ＩＰトンネル・カプセル化ヘッダを前記経路最適化ヘッダに挿入するよう構成される請求項２８から３５のいずれか１つに記載のゲートウェイ。
37. 請求項１から２７のいずれか１つに記載の方法の各ステップを実行する、または、関与する手段を更に有する請求項２８から３６のいずれか１つに記載のゲートウェイ。
38. モバイル・ノードのホーム・エージェントを介して通信相手ノードとデータ・パケットを交換し、前記モバイル・ノードの第２位置依存ＩＰアドレスを第２経路最適化処理の送信元アドレスとして使用し、前記通信相手ノードと前記第２経路最適化処理を行うよう構成されるモバイル・ノード。
39. 前記モバイル・ノードは、前記第２経路最適化処理を行った後、前記通信相手ノードへデータ・パケットを送信するため経路最適化ヘッダを使用するよう構成される請求項３８に記載のモバイル・ノード。
40. 前記モバイル・ノードは、前記ゲートウェイのＩＰアドレスを送信元アドレスとして有する前記ゲートウェイから送信される、前記第２経路最適化処理の第１応答メッセージを前記ゲートウェイから直接受け取るよう構成される請求項３８から３９のいずれか１つに記載のモバイル・ノード。
41. 前記モバイル・ノードは、前記通信相手ノードの位置依存ＩＰアドレスを送信元アドレスとして有する前記ゲートウェイから、前記第２経路最適化処理の第１応答メッセージを直接受け取ることが可能かどうかを前記ゲートウェイに通知するよう構成される請求項４０に記載のモバイル・ノード。
42. 前記モバイル・ノードは、前記第２経路最適化処理の第２バインディング・アップデートメッセージを前記ゲートウェイへ送信した後、前記モバイル・ノードと前記ゲートウェイとの間でセキュリティ・トンネルを使用することから、セキュリティ・オプション・フィールドを各データ・パケットのヘッダへ付加することへと切り替える請求項３８から４１のいずれか１つに記載のモバイル・ノード。
43. 前記第１経路最適化処理の第１開始メッセージがトンネルを介して受信されていないことを検出した際、前記モバイル・ノードは、トンネルを介して送信するのではなく、前記第１経路最適化処理の第１応答メッセージを前記ゲートウェイへ直接送信するよう構成される請求項３８から４２のいずれか１つに記載のモバイル・ノード。
44. 請求項１から２７のいずれか１つに記載の方法の各ステップを実行する、または、関与する手段を更に有する請求項３８から４３のいずれか１つに記載のモバイル・ノード。
45. 請求項２８から３７のいずれか１つに記載のゲートウェイと、請求項３８から４４のいずれか１つに記載のモバイル・ノードとを有する通信システム。
    
    
    

Images