JP2010517344A - ルート最適化手順によるデータパケットのヘッダ縮小の方法 - Google Patents

Abstract

【課題】データパケットのヘッダサイズを縮小する。
【解決手段】
本発明は、モバイルノード（ＭＮ）とモバイルノードのホームエージェント（ＨＡ）の間で交換されるデータパケットのヘッダサイズを縮小する方法に関する。コレスポンデントノードとＭＮのＨＡとの間で、そしてＭＮとそのＨＡとの間では、異なるタイプのヘッダが利用される。ＭＮとそのＨＡの間で用いられるタイプのヘッダは、前記データ経路部上で交換されたパケットのヘッダサイズを縮小することを可能にする。その理由は、ＣＮとＨＡとの間で用いられる既存のタイプのヘッダは２個必要であることと比べて、ヘッダが１個のみ必要であるからである。これを達成するために、修正されたルート最適化手順がＭＮとそのＨＡとの間で実行され、ＨＡはＣＮに代わってＲＯに参加する。このように、ＲＯはＣＮに対してトランスペアレント性を保ったままであり、一方ＭＮは、通常のＲＯが起こっていると考える。本発明は、前記方法に参加するいくつかのネットワークエンティティにも関する。
【選択図】図４

Description

本発明は、モバイルノードと通信相手ノード（コレスポンデントノード）の間で交換されるデータパケット用のルート最適化ならびにルート非最適化ヘッダを利用することによって、データパケットのヘッダサイズを縮小する方法に関する。本発明は、主として、ＭＮとＣＮの間の通信に適用され、通信において中間ノードは、データパケットの付加的なカプセル化を適用し、これによって、データトラフィックを増加させる。とりわけ、ルート最適化ならびにルート非最適化ヘッダは、モバイルノードと、通信相手ノードを代行する中間ノードとの間で最適化手順を実行することによって確立される。さらに本発明は、本発明に参加するネットワークエンティティ及びネットワーク制御エンティティに関する。

通信システムは、インターネットプロトコル（ＩＰ）ベースのネットワークへとますます進化している。通信システムは典型的には、互いに接続された多くのネットワークから成り、ネットワーク内では、音声及びデータが、一端末から別の端末へばらばらにパケットで送られる。ＩＰパケットはルータによって、接続のない態様であて先へとルーティングされる。そのため、パケットはＩＰヘッダ及びペイロード情報を含み、ヘッダはとりわけ、送信元（ソース）及びあて先のＩＰアドレスを含む。

ＩＰネットワークは、拡張性を理由に、階層的なアドレス指定スキームを用いる。それゆえ、ＩＰアドレスは対応する端末を識別するだけでなく、付加的に該端末についての位置情報を含む。ルーティングプロトコルによって提供された付加的な情報によって、ネットワーク内のルータは、特定のあて先に向かう次のルータを識別することができる。

とりわけ、ルーティングと呼ばれる処理は、データパケットをソースからあて先へと少なくとも一つの中間ネットワーク上で移動させるのに用いられる。データパケットがあて先に到達するためには、データパケットは、あて先デバイスの物理的ネットワークに到着するまで、ある一つのルータから別のルータへと渡される必要がある。これは、ネクスト ホップ ルーティングとも呼ばれる。その理由は、ルーティングは段階的な方法に基づいているから、すなわち、ソースとあて先の間の正確な経路は開始時には知られていないが、それぞれの中間ルータはデータパケットを転送するネクスト ホップ ルータを知っているからである。これによって達成される主要な利点は、それぞれのルータは、すべてのあて先ネットワークへの正確なルートは知らずに、所定のデータパケットに対して隣接するどのルータが次の受信ルータであるべきかを知る必要があるのみという点である。

例示的には、ソースデバイスがパケットをそのローカルルータへと送った後に、ローカルルータのデータリンク層は、パケットをルータのＩＰレイヤへ至るまで渡す。これに対応して、レイヤ２のフレームを除去した後に、パケットのレイヤ３のヘッダが検査され、ルータは、パケットが送られるべき次のルータがどれであるかを決定する。結果として、パケットは適切なレイヤ２のフレームで再カプセル化され、データリンクレイヤへと戻され、データリンクレイヤはパケットを、決定された次のルータへルータの物理的ネットワークリンクのうちの一リンク上に送信する。

この点において、ルータはルーティングテーブルと呼ばれる一連の情報を保持する。該ルーティングテーブルは、異なるネットワークＩＤと、該ルータが接続された他のルータとの間のマッピングを提供する。これに対応してルータは、ルーティングテーブルのエントリと最も長く一致するあて先アドレスに基づいて、ネクスト ホップ ルータを決定するために、データパケットのあて先ＩＰアドレスをルーティングテーブルのエントリと照合してチェックする。加えて、それぞれのルーティングテーブルのエントリに対して定義された計量値が、特定のルーティングエントリを所定の基準に基づいて評価し、ひいては、いくつかの考えられる経路の中から最良の経路を選択することが可能になる。

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

ネットワークレイヤ３（ＯＳＩ）は、パケットのルーティングが実際に発生している層であり、中間ネットワークを介してルーティングされている間は、データパケットのレイヤ３ヘッダは変化しない。ソース及びあて先のより高位のレイヤは「論理的に」のみ接続されているため、すなわち、実際の接続がないため、パケットが下位のレイヤ２及び１を渡って、あて先へと物理的に配信されることが必要である。それぞれのネットワークレイヤ内で異なるプロトコルが用いられるため、例えばレイヤ３からレイヤ２へと通過するそれぞれのデータパケットは、適切にフレーム化されなければならない。

したがって、データパケットのカプセル化は通常、上位レイヤプロトコルから下位レイヤプロトコルを介してデータを送るのに用いられる。例えば、インターネットはＩＰｖ６プロトコルを利用するが、一方、大部分のアプリケーションは、データ用にユーザデータプロトコル（ＵＤＰ）又は通信制御プロトコル（ＴＣＰ）のいずれかを用いる。結果として、ユーザデータがＵＤＰデータグラム（レイヤ４）内でカプセル化され、次いでＩＰパケット（レイヤ３）内でカプセル化される。続いて、ＩＰパケットはカプセル化されたユーザデータとともに、データリンクレイヤプロトコル（例えばイーサネット（登録商標）、レイヤ２）上に送ってもよく、ここでも再びカプセル化を伴う。

さらに、ある特定のレイヤのある一つのプロトコルが、同じ特定レイヤの別のプロトコルによってカプセル化されたデータパケットを運搬するために用いられる場合には、同じレイヤの内部でカプセル化を用いてもよい。トンネルとよばれる論理構造が、カプセル化を行うデバイスとカプセル化解除を行うデバイスとの間で確立される。この処理自体はトンネリングと呼ばれる。トンネリングは、一つのネットワークプロトコルのデータパケットを、さもなければそのパケットをサポートしない（別のプロトコルによって制御される）であろうネットワークを介して送るために用いてもよい。また、トンネリングは、プライベートアドレス指定といった、様々なタイプの仮想プライベートネットワーク（ＶＰＮ）機能を提供するのに用いてもよい。例えば、ＧＰＲＳトンネリングプロトコル（ＧＴＰ）、ポイント ツー ポイント トンネリングプロトコル（ＰＰＴＰ）、又はＩＰセキュリティプロトコル（ＩＰｓｅｃ）がある。

最も一般的に用いられるトンネリング機構の一つが、ＩＰ（レイヤ３）−ｉｎ−ＩＰ（レイヤ３）カプセル化であり、これは、ＩＰデータグラムを別のＩＰヘッダでカプセル化する処理のことを言い、例えばＭｏｂｉｌｅ ＩＰ用に用いられうる。モバイルＩＰｖ６はＭＩＰｖ６とも表され（非特許文献１を参照）、モバイルノードがサブネット間を、高位レイヤ及びアプリケーションにトランスペアレントな態様で、すなわち、高位レイヤの接続を断つことなく、移動することを可能にするＩＰベースのモビリティプロトコルである。言い換えれば、モバイルノードはＩＰｖ６インターネットネットワーク内を動き回っている間は、到達可能のままである。

通常、端末の電源が入ると、端末は、アクセスネットワークのＩＰアドレスプリフィックスに基づくＩＰアドレスを構成する。端末が移動体、いわゆるモバイルノード（ＭＮ）であり、異なるＩＰプリフィックスアドレスを持ったサブネット間を移動する場合、端末は、階層的なアドレス指定スキームを理由に、自己のＩＰアドレスを位相的に正しいアドレスへと変更しなければならない。しかしながら、ＴＣＰ接続といった高位レイヤの接続は、通信ノードのＩＰアドレス（及びポート）で定義されるので、ノードの一つが例えば移動を理由に自己のＩＰアドレスを変更する場合、アクティブＩＰセッションへの接続が切れる。前記課題に対処する一つの考えられうるプロトコルはＭＩＰｖ６プロトコルである。

ＭＩＰｖ６の主要な原理は、モバイルノードが、インターネット内の自己の位相的な位置にかかわらず、常に自己のホームアドレス（ＨｏＡ）によって識別され、一方、モバイルノードの気付アドレス（ＣｏＡ）はモバイルノードの現在の位相的な位置についての情報を提供する。

より詳細には、モバイルノードは構成された２個のＩＰアドレス、気付アドレス及びホームアドレスを有する。モバイルノードの高位レイヤは、以降主にコレスポンデントノード（ＣＮ）と称する通信パートナー（あて先端末）との通信のためにホームアドレスを用いる。このアドレスは変化せず、モバイルノードの識別という目的を担う。位相的には、ホームアドレスはモバイルノードのホームネットワーク（ＨＮ）に属する。対照的に、気付アドレスは、サブネット変化に帰着するあらゆる移動で変化して、ルーティングの下部構造のためのロケータとして用いられる。気付アドレスは位相的には、モバイルノードが現在訪問中のネットワークに属する。ホームリンク上に位置する一連のホームエージェント（ＨＡ）のうち１個のＨＡは、モバイルノードのホームアドレスに対するモバイルノードの気付アドレスのマッピングを保持するとともに、モバイルノードへのトラフィックの向きをＨＡの現在の位置へと変える。１個のホームエージェントではなく一連のホームエージェントを配備する理由は、例えば冗長性やロードバランシングのためである。

モバイルＩＰｖ６は現在、２つの動作のモードを定義し、そのうち一つは双方向性トンネリングである（図１）。もう一方のモードはルート最適化モードであり（図２）、後に詳述する。双方向トンネリングを用いる際に、コレスポンデントノード１０１によって送られ、モバイルノード１０２のホームアドレスあてのデータパケットは、ホームネットワーク１１０内のホームエージェント１１１によって傍受（インターセプト）される。傍受されるそれぞれのデータパケットはＭＮ１０２の気付アドレスへネットーク上に再送される必要があるので、ＩＰ−ｉｎ−ＩＰカプセル化が必要とされる。したがって、傍受されたそれぞれのデータパケットは、ＭＮ１０２のＣｏＡへ宛てられてＭＮ１０２へトンネリングされた新しいＩＰデータパケット内に、ペイロードとして含められており、該ＭＮ１０２は、外部ネットワーク１２０に位置している。対応するトンネリングの開始は、カプセル化を行うホームエージェント１１１であり、終点はモバイルノード１０２である。外部ネットワーク１２０内のローカルエージェントが、モバイルノードに代わってメッセージを受信し、外側のＩＰヘッダを取り外し、カプセル化を解除されたデータパケットをモバイルノード（不図示）へと配信することも可能である。

モバイルノード１０２によって送られたデータパケットは、ホームエージェント１１１へとリバース トンネリングされ、該ホームエージェント１１１はパケットのカプセル化解除を行い、パケットをコレスポンデントノード１０１へ送信する。リバース トンネリングとは、パケットがモバイルノードによってホームエージェントへと「フォワード」トンネリングと「逆の」態様でトンネリングされることを意味する。ＭＩＰｖ６におけるこの動作に関しては、ホームエージェント１１１のみがモバイルノード１０２の気付アドレスについて通知される。したがって、モバイルノードは、バインディングアップデート（ＢＵ）メッセージをホームエージェントへ送信する。これらのメッセージは、都合がよく、ＩＰｓｅｃセキュリティ アソシエーション（バインディング）上を送られ、認証され、完全性が保護される。

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

上記に説明したとおり、ＨＡは、データパケットを受け取ると、ＭＩＰｖ６手順に基づいてＩＰ−ｉｎ−ＩＰカプセル化を適用し、カプセル化されたパケットをＭＮへ送る。言い換えればＨＡは、ＩＰ−ｉｎ−ＩＰカプセル化を適用することによって、受け取ったデータパケットをＭＮへトンネリングする。より具体的にはＨＡは、ソースアドレスとして自己のアドレスと、付加的なヘッダのあて先アドレスとしてＭＮの気付アドレスとを含む別のＩＰヘッダをパケットに付加する。図３から明らかなように、これによってパケットサイズをさらに４０バイト拡張させる。

同様に、ＭＮによって戻されたデータパケットは、２個のＩＰヘッダでカプセル化される。外側のヘッダは、ＨＡへのデータパケットのトンネリングに関し、したがって、あて先アドレスとしてＨＡのアドレスと、ソースアドレスとしてＭＮの気付アドレスとを含む。内側のＩＰヘッダは、あて先としてＣＮのアドレスと、ソースアドレスとしてＭＮのホームアドレスとを含む。

したがって、ＭＮとＣＮの間の通信セッションのそれぞれのデータパケットは、ＨＡとＭＮの間で拡張され、その結果として、対応するネットワーク内に付加的なトラフィックを生じる。これはとりわけ、データ帯域幅能力が限定されているネットワーク、例えば、無線ネットワーク内において不利である。

Ｄ．Ｊｏｈｎｓｏｎ、Ｃ．Ｐｅｒｋｉｎｓ、Ｊ．Ａｒｋｋｏ、"Mobility Support in IPv6"、ＩＥＴＦ ＲＦＣ ３７７５、２００４年６月

したがって、従来技術における上記の課題に鑑みて、本発明の一つの目的は、コレスポンデントノードとの通信において、モバイルノードと、中間ノードとの間のデータパケットの交換を改良することである。

より具体的には、本発明の一つの目的は、コレスポンデントノードとの通信において、モバイルノードと、中間ノードとの間で交換されるデータパケットのＩＰヘッダサイズを縮小することである。

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

本発明の一つの実施態様は、所定のデータ経路部に二つの異なる種類のヘッダを適用することによって、データパケットのＩＰヘッダサイズを縮小することである。とりわけ、コレスポンデントノードと中間ノードの間では、非ルート最適化ＩＰヘッダが用いられる。次いで、中間ノードとモバイルノードの間では、ルート最適化ＩＰヘッダが用いられる。これによって、ヘッダサイズを縮小することが可能になる。その理由は、そうでない場合に必要とされる２個の非ルート最適化ＩＰヘッダと比べて、前記ルート部には、１つのルート最適化ＩＰヘッダのみ必要であるからである。

したがって、本発明の別の実施態様は、異なるタイプのＩＰヘッダを設定するためにルート最適化手順を適用することに関する。とりわけ、中間ノードはコレスポンデントノードとしての働きをし、ルート最適化手順に参加し、その結果、コレスポンデントノードはルート最適化が起こっていることを知らない。したがって、ＣＮは依然として非ルート最適化ＩＰヘッダを用いてデータを送り、一方、中間ノードとＭＮの間では、交換されたデータパケットにルート最適化ＩＰヘッダが適用される。

本発明の一つの実施の形態は、モバイルノードとそのホームエージェントの間の通信リンク上のデータパケットのヘッダサイズを縮小する方法を提供する。データパケットは、モバイルノードとコレスポンデントノードの間で交換され、すべてのデータパケットはホームエージェントを介して交換される。モバイルノードは、ルート最適化ヘッダを利用することによって、データパケットをコレスポンデントノードへ送り、一方、コレスポンデントノードは、非ルート最適化ヘッダを利用することによって、データパケットをモバイルノードへ送る。ホームエージェントは、モバイルノードからのデータパケットのルート最適化ヘッダを、コレスポンデントノードによって利用されるルート非最適化ヘッダへと変換する。さらに、ホームエージェントは、コレスポンデントノードからのデータパケットのルート非最適化ヘッダを、モバイルノードによって利用されるルート最適化ヘッダへと変換する。

本発明の有利な実施の形態では、ルート最適化手順がモバイルノードとホームエージェントの間で実行される。とりわけ、ホームエージェントはコレスポンデントノードに代わってルート最適化手順に参加する。また、上記のステップは、ルート最適化手順を実行した後に行われる。この目的のために新しい完全なプロトコルが開発される予定はないので、本発明の実施は既存の手順の使用によって促進される。

別の実施の形態によると、モバイルノードとホームエージェントの間の上記のルート最適化手順は、モバイルノードとホームエージェントの間の許可メッセージの交換を含む。ホームエージェントによって受け取られたモバイルノードからの許可メッセージは、コレスポンデントノードへと向かう。さらにホームエージェントは、コレスポンデントノードのアドレスを、モバイルノードへと送られた許可メッセージのソースアドレスとして利用する。許可メッセージは最適化手順全体のセキュリティを向上させる。

本発明の別の実施の形態は、許可メッセージの交換に関する。とりわけ、モバイルノードはコレスポンデントノードへ向かう第１及び第２の許可メッセージを送る。しかしながら、第１及び第２の許可メッセージはホームエージェントによって傍受される。第１及び第２の許可メッセージに応答して、ホームエージェントは第３及び第４の許可メッセージをモバイルノードへと送る。より詳細には、コレスポンデントノードのアドレスは、第３及び第４の許可メッセージのソースアドレスとして利用される。対応するメッセージがホームエージェントによって傍受されるので、コレスポンデントノードはルート最適化手順について見つけ出さない。

本発明の追加的な実施の形態では、モバイルノードは、コレスポンデントノードへ向かうバインディングアップデートメッセージを送る。バインディングメッセージの目的は、モバイルノードの位置依存アドレスを、モバイルノードの位置独立アドレスとバインディングすることである。バインディングアップデートメッセージは、ホームエージェントによって再び傍受される。

本発明の有利な実施の形態によると、モバイルノードがアクセスネットワーク内に位置するとともに、アクセスネットワーク内のアクセスルータが、モバイルノードのためにアクセスネットワークへの接続を提供する。前記の場合において、アクセスルータはルート最適化手順のメッセージをホームエージェントへ転送し、該メッセージはコレスポンデントノードへ向かう。さらに、ルート最適化手順はモバイルノードとホームエージェントの間で実行され、一方、ホームエージェントはコレスポンデントノードに代わってルート最適化手順に参加する。アクセスルータは、コレスポンデントノードへ向かう関連するメッセージを代わりにホームエージェントに送ることによって、コレスポンデントノードをルート最適化手順から除外するための助けにもなる。

本発明の別の実施の形態では、データパケットはモバイルノードとアクセスルータの間でセキュリティトンネルを介して交換される。このことは、前記リンク上のセキュリティを向上させる。

本発明の異なる実施の形態は、アクセスルータが、データパケットをホームエージェントへとトンネリングする前に、モバイルノードから受け取ったデータパケットのヘッダからオプションフィールドを取り除く可能性に関する。これにより、アクセスルータはデータパケットのヘッダサイズを縮小するための助けにもなる。

本発明の別の実施の形態によると、アクセスネットワークは無線又は有線タイプのアクセスネットワークである。本発明のこの実施の形態は両方の種類のネットワークに適用され、有利である。

本発明の別の有利な実施の形態では、コレスポンデントノードから送られたデータパケットのルート非最適化ヘッダは、ソースアドレスフィールド内にコレスポンデントノードのアドレスを含む。加えて、それらヘッダは、あて先アドレスフィールド内にモバイルノードの位置独立アドレスをさらに含む。これに対して、モバイルノードから送られたデータパケットのルート最適化ヘッダは、ソースアドレスフィールド内にモバイルノードの位置依存アドレスを含む。さらに、それらヘッダは、あて先アドレスフィールド内にコレスポンデントノードのアドレスを、ルーティングヘッダフィールド内にモバイルノードの位置独立アドレスを、あわせて含む。

本発明のより具体的な実施の形態では、モバイルノードからのデータパケットのルート最適化ヘッダのルート非最適化ヘッダへの変換は、ソースアドレスフィールド内のモバイルノードの位置依存アドレスと、ルーティングヘッダフィールド内のモバイルノードの位置独立アドレスとの交換を含む。この変換は、ルーティングヘッダフィールドの削除をさらに含む。この変換は実行されたルート最適化をコレスポンデントノードから隠すことを可能にする。その理由は、それぞれのデータパケットのヘッダが、ルート最適化手順の前に用いられ、コレスポンデントノードによって予測されるヘッダへと変更されるからである。

本発明の別の実施の形態によると、コレスポンデントノードからのデータパケットのルート非最適化ヘッダのルート最適化ヘッダへの変換は、ルーティングヘッダフィールド内にモバイルノードの位置独立アドレスを含めることを含む。加えて、あて先アドレスフィールド内のモバイルノードの位置独立アドレスは、モバイルノードの位置依存アドレスと交換される。前とは反対に、モバイルノードは、ルート最適化手順がコレスポンデントノードで実行されたと信じ込ませられている。

本発明の別の実施の形態は、モバイルノードが第１のネットワークエリア内に位置するとともに、コレスポンデントノードが第２のネットワークエリア内に位置し、第１及び第２のネットワークエリアが異なるアクセス技術を用いるという選択肢に関する。アクセス技術に制限はないので、本発明の実施の形態を実施するための柔軟性が増強される。

本発明の一つの実施の形態は、データパケットのヘッダサイズを縮小するためのネットワークエンティティを提供する。データパケットはモバイルノードとコレスポンデントノードの間で交換され、すべてのデータパケットは該ネットワークエンティティを介して交換される。ネットワークエンティティの受信装置はモバイルノードから着信するデータパケットを受け取り、モバイルノードから着信するデータパケットはルート最適化ヘッダを含む。受信装置はコレスポンデントノードから着信するデータパケットをさらに受け取り、コレスポンデントノードから着信するデータパケットはルート非最適化ヘッダを含む。ネットワークエンティティ内の処理装置がモバイルノードから着信するデータパケットのルート最適化ヘッダをルート非最適化ヘッダへと変換する。したがって、処理装置はさらに、コレスポンデントノードから着信するデータパケットのルート非最適化ヘッダをルート最適化ヘッダへと変換する。

本発明の別の実施の形態によると、ネットワークエンティティの受信装置は、コレスポンデントノードへ向かう第１及び第２の許可メッセージを、モバイルノードから受け取る。処理装置は、第１及び第２の許可メッセージに応答して、モバイルノードのための第３及び第４の許可メッセージを生成する。詳細には、処理装置は、コレスポンデントノードのアドレスを、第３及び第４の許可メッセージのソースアドレスとして利用する。続いて、ネットワークエンティティの送信装置は、第３及び第４の許可メッセージをモバイルノードへと送る。これにより、ネットワークエンティティは、コレスポンデントノードに代わって、ルート最適化手順内に実行することができるようになる。本発明の別の実施の形態では、受信装置はモバイルノードからのデータパケットを受け取る。加えて、モバイルノードからのデータパケットのルート最適化ヘッダは、ソースアドレスフィールド内のモバイルノードの位置依存アドレスを含む。データパケットのルート最適化ヘッダは、あて先フィールド内にコレスポンデントノードのアドレスを、ルーティングヘッダフィールド内にモバイルノードの位置独立アドレスをさらに含む。ネットワークエンティティの処理装置は、ソースアドレスフィールド内のモバイルノードの位置依存アドレスを、ルーティングヘッダフィールド内のモバイルノードの位置独立アドレスと交換する。さらに、処理装置はルーティングヘッダフィールドを削除する。ネットワークエンティティの送信装置は、モバイルノードの位置依存アドレスを位置独立アドレスと交換した後に、そしてルーティングヘッダフィールドを削除した後に、データパケットをコレスポンデントノードへ送る。ネットワークに関する別の実施の形態は、コレスポンデントノードからのデータパケットを受け取る受信装置に関する。前記の場合において、コレスポンデントノードからのデータパケットのルート非最適化ヘッダは、ソースアドレスフィールド内にコレスポンデントノードのアドレスを、あて先アドレスフィールド内にモバイルノードの位置独立アドレスを含む。ネットワークエンティティの処理装置は、ルーティングヘッダフィールド内にモバイルノードの位置独立アドレスを含む。さらに、処理装置は、あて先アドレスフィールド内のモバイルノードの位置依存アドレスを、モバイルノードの位置依存アドレスと交換する。送信装置は、位置独立アドレスを含めた後に、そしてモバイルノードの位置依存アドレスを交換した後に、データパケットをモバイルノードへ送る。

本発明の一つの実施の形態は、モバイルノードが接続されたネットワークエリア内にある、モバイルノードから受け取ったデータパケットを転送するためのアクセスルータを提供する。モバイルノードは、ホームエージェントを介してデータパケットをコレスポンデントノードと交換し、すべてのデータパケットはアクセスルータを介してホームエージェントとモバイルノードの間で交換される。アクセスルータ中の処理装置は、モバイルノードから着信するデータパケットが、モバイルノードとホームエージェントの間で実行されたルート最適化手順に関連するか否かを判定する。ホームエージェントはコレスポンデントノードに代わってルート最適化手順に参加する。モバイルノードから着信するデータパケットがルート最適化手順に関連すると処理装置が判定する場合には、送信装置はデータパケットをホームエージェントに送る。

さらに、本発明の別の実施の形態では、複数のホームエージェントがアクセスルータに接続されている。アクセスルータ内のデータベースは、データパケットがコレスポンデントノードと交換される際に介するホームエージェントとのモバイルノードの関連付けについての情報を含む。アクセスルータの処理装置は、モバイルノードから着信するそれぞれのデータパケットについて、データパケットがコレスポンデントノードと交換される際に介するホームエージェントを決定する。この決定は、データベース、及び、データパケットのソースアドレスフィールド内のモバイルノードのアドレスに基づいている。

本発明の一つの実施の形態は、ホームエージェントを介してデータパケットをコレスポンデントノードと交換するモバイルノードを提供する。モバイルノードは、自己のホームネットワークとは異なる外部ネットワーク内に位置するとともに、別の外部ネットワークへと変更すると、ホームエージェントでルート最適化手順を実行するよう構成されている。さらに、ホームエージェントは、コレスポンデントノードに代わってルート最適化手順に参加する。

本発明によれば、ＭＮとそのＨＡの間で用いられるタイプのヘッダは、前記データ経路部上で交換されたパケットのヘッダサイズを縮小することができる。

ＭＩＰｖ６によるモバイルノードとコレスポンデントノードの間の通信のための双方向トンネリングの使用の一例を示す図 ＭＩＰｖ６によるモバイルノードとコレスポンデントノードの間の通信のためのルート最適化の使用の一例を示す図 ＭＩＰｖ６の双方向トンネリングモードにある場合の、ＭＮとＣＮの間の通信中に用いられるデータパケットフォーマットの一例を示す図 本発明の一つの実施の形態を実行する前後の、ＭＮとＣＮの間の通信中に用いられるデータパケットフォーマットの一例を示す図 ＭＩＰｖ６によるＭＮとＣＮの間のルート最適化手順のためのシグナリング、及び関連するメッセージのパケットフォーマットの一例を示す図 ＭＩＰｖ６双方向トンネリングモード及びＭＩＰｖ６ルート最適化モードに用いられる、それぞれのデータパケットフォーマットの比較の一例を示す図 本発明の一つの実施の形態によるＭＮとＨＡの間のルート最適化手順のためのシグナリング、及び、関連するメッセージのデータパケットフォーマットの一例を示す図 簡略化したＷＬＡＮネットワークモードの概観の一例を示す図 相互作用する３ＧＰＰ−ＷＬＡＮプロトコルスタック及び通信に用いられるデータパケットフォーマットの一例を示す図 ＭＮがＷＬＡＮシナリオ内に位置する場合に通信中に用いられるデータパケットフォーマットの一例を示す図 本発明の別の実施の形態によるルート最適化手順のためのシグナル、及びデータパケットフォーマット関連するメッセージのデータパケットフォーマットの一例を示す図 ＭＮがＷＬＡＮ内に位置する場合に、本発明の実施の形態を実行する前後に、ＭＮとＣＮの間での通信中に用いられるデータパケットフォーマットの一例を示す図

以下の段落は本発明の様々な実施の形態を記載する。例示的な目的のみのため、大部分の実施の形態は、上記の背景技術の段落及び以降に論じられる３ＧＰＰ−ＷＬＡＮ通信システムと関連して概説される。本発明は有利的には、３ＧＰＰ−ＷＬＡＮ通信システムといった、例えば移動通信システムとの接続に用いてもよいが、本発明は、この特定の例示的な通信ネットワーク内での使用には限定されないことに留意するべきである。

上記の技術的背景の項で提供された説明は、本明細書中に記載される主に３ＧＰＰに特有の例示的な実施の形態をより良く理解するよう意図されており、本発明を移動通信ネットーク中の処理及び機能の特定の記載された実施に制限するものとして理解されるべきではない。それにもかかわらず、本明細書中に提案された改良は、背景技術の項に記載された構造／システム中に容易に適用されうるとともに、本発明のいくつかの実施の形態においてこれらの構造／システムの標準的及び改良された手順を活用してもよい。

定義
以下において、本文書中に高頻度に用いられるいくつかの術語の定義を提供する。

モバイルノードは、通信ネットワーク内にある物理的なエンティティである。１個のノードがいくつかの機能エンティティを有する。機能エンティティとは、所定の一連の機能をノード又はネットワークの他の機能エンティティに実装及び／又は提供するソフトウェア又はハードウェアモジュールのことをいう。ノードは、通信施設もしくはノードの通信を可能にする媒体にノードをくっつける一つ以上のインタフェースを有している。同様に、ネットワークエンティティは、通信施設、もしくは、他の機能エンティティ又はコレスポンデントノードとの通信を可能にする媒体に機能エンティティをくっつける論理インタフェースを有している。

モバイルノードのホームネットワーク（すなわちホームリンク）は典型的には、該モバイルノードがその所定のホームアドレスに対する自己の気付アドレス（単数又は複数）を登録したホームエージェントの位置によって識別される。ホームアドレスはモバイルノードに割り当てられ、モバイルノードの恒久アドレスとして用いられ、そのため、位置独立アドレスである。このアドレスは、モバイルノードのホームネットワークのプリフィックスを有する。気付アドレスは、外部ネットワークを訪問中にモバイルノードと関連付けられ、そのため、位置依存アドレスである。気付アドレスのプリフィックスは、典型的には訪問したネットワークのプリフィックスと等しい。モバイルノードは、一つ以上の気付アドレスを同時に有してもよい。

ホームエージェントは、モバイルノードが自己の現在の気付アドレス（単数又は複数）を登録した、該モバイルノードのホームネットワーク上に、ルーティング機能を提供するルータ又は機能エンティティである。モバイルノードがホームから離れている間、ホームエージェントは、例えば、モバイルノードのホームアドレスへ向けたホームリンク上のパケットを傍受し、パケットをカプセル化し、モバイルノードの登録済の気付アドレス（単数又は複数）へパケットをトンネリングすることによって、モビリティサービスをモバイルノードに提供する。

ルート最適化ヘッダは、第一のタイプのヘッダであり、ルート非最適化ヘッダのタイプのヘッダとは異なる。本発明の一つの実施の形態では、これら二つのタイプのヘッダは、ルート最適化（ＲＯ）が前もって実行されたか否かによって差別化される。すなわち、ルート最適化ヘッダのタイプは、ＲＯが行われた後に通常利用され、一方、ルート非最適化ヘッダのタイプは、ＲＯが起こらなかった場合に用いられる。

図４は、本発明の一つの実施の形態が適用されるネットワーク構造を、ＨＡ１１１を介してＣＮ１０１とＭＮ１０２の間で交換されるデータパケットの対応するヘッダフォーマットとともに示す。アクセスルータ（ＡＲ）１０３は、ＭＮが現在接続されているアクセスネットワーク内のＭＮのデフォルトルータである。本発明の実施の形態によると、異なるＩＰヘッダクラスが特定のデータ経路上のデータパケットに適用される。具体的には図４は、本発明の実施の形態を適用した後の相違を図示する。ＨＡ１１１とＭＮ１０２の間では、異なるタイプのヘッダ（ヘッダ・クラス２）は、ＨＡ１１１とＣＮ１０１の間のルート部（ヘッダ・クラス１）より他のペイロードをカプセル化するために利用される。（図３と関連して論じるように）本発明を適用する前にＨＡとＭＮの間で用いられるヘッダも、図４に示されている。本発明の実施の形態を適用する前、ヘッダは、それぞれが４０バイトで合計８０バイトとなるクラス１のヘッダ２個を含む。逆に、この実施の形態が用いられるクラス２のヘッダは、より少ない空間、例えば、ＡＲとＭＮの間のアップリンク内、すなわちＭＮのアクセスネットワーク内で６０バイトを必要とし、一方、データパケットのヘッダは、ＡＲとＨＡの間で１００バイトまで拡張される。ＡＲとＨＡの間のアップリンク内には付加的なＩＰ−ｉｎ−ＩＰカプセル化が必要である。その理由は、ＭＮによって送り出されたデータパケットはＣＮのＩＰアドレスへと向かうからである（図４中のＤＡフィールドを参照）。このように、データパケットはＡＲによってＣＮの方向にルーティングされる。すべてのデータパケットはＨＡを通過しなければならないので、データパケットをＨＡへとトンネリングするべく付加的なＩＰ−ｉｎ−ＩＰカプセル化を適用することが必要である。

さらに、ダウンリンクでは、ヘッダサイズはＨＡとＭＮの間で６４バイトに縮小される。これにより、データパケットのサイズは、本発明の適用前と比べて、それぞれ２０バイト及び１６バイト縮小した。クラス２のヘッダのサイズにおけるダウンリンク上とアップリンク上での差は、ダウンリンク及びアップリンクに用いられる異なるオプションフィールドに基づいている。

ヘッダのタイプをクラス１からクラス２へ、及び、その反対方向に変更するために必要なステップは、ＨＡによって行われる。とりわけ、ＣＮからクラス１のヘッダを有するデータパケットを受け取る場合、ＨＡは、データパケットのあて先フィールド内のＭＮのホームアドレスを、内部データベース内のＭＮの対応する気付アドレスと一致させる。引き続き、ＭＮの位置依存アドレスＣｏＡを決定すると、あて先アドレスフィールドは、ＭＮのＨｏＡからＭＮのＣｏＡへ変更される。追加的に、データパケットをＭＮへと転送する前に、ＭＮのＨｏＡはヘッダの適切なオプションフィールドに挿入される。ＭＮの内部において、ＣＮと通信している正しいアプリケーションへパケットが転送できるように、オプションフィールド内のＨｏＡがＭＮ内に必要である。これに対して、クラス２のヘッダが付いたデータパケットをＨＡがＭＮから受け取るときは、クラス２のヘッダをクラス１のヘッダへと変換しなければならない。この点において、まず、最初にＡＲからＨＡへのトンネリングに用いられた付加的なＩＰヘッダを取り外すことが必要である。次いでＨＡは、ソースアドレスフィールド内のＭＮのＣｏＡを、クラス２のヘッダのオプションフィールド内に定義されたＭＮのＨｏＡと交換し、後にＭＮのＨｏＡが付いたオプションフィールドを取り除く。

ホームネットワークの外部にあるＭＮの特定の位置は、本発明の実施の形態にとっては何の重要性もないことに留意するべきである。そのためＭＮは、自己のホームネットワークとは異なるいずれのネットワーク内に位置してもよい。しかしながら、ＭＮは、ＭＮが自己のＣｏＡを変更するかまたは新しいＣＮとの通信を開始するたびに、本発明の実施の形態によるルート最適化を開始しなければならない。ＭＮがホームネットワーク内にあるときはＩＰ−ｉｎ−ＩＰトンネリングは必要ない。その理由は、パケットはネットワークの内部でローカルにＭＮへとルーティングされているからである。このように、データパケットには１個だけのＩＰヘッダが用いられるので、ヘッダサイズを縮小する必要はない。

要するに、ＣＮとＭＮは異なるＩＰヘッダのタイプを用いて、自己のペイロードをカプセル化し、ＣＮは、本発明を適用する前にも用いられた第１のタイプのヘッダを用い、ＭＮは、第２のタイプのヘッダを用いる。クラス２のヘッダは、クラス２のヘッダが１個のみ付いたデータパケットを送ることが可能であるため、データパケットのサイズを縮小する。一方、クラス１のヘッダを用いるときは、クラス１のヘッダが２個付いたペイロードをカプセル化する必要がある。例外として、アップリンク中のＡＲとＨＡの間で、付加的なＩＰヘッダが必要であり、したがって、以前の８０バイトと比べて、ヘッダサイズを１００バイトまで実際に増加させている。しかしながら、この経路部は通常は十分な帯域を有するコアネットワーク内にあるので、ヘッダサイズが増加しても、本発明の実施の形態によって達成されたＭＮのネットワーク内でのヘッダサイズの縮小と比べて、あまり関係はない。

ＨＡによる２つの異なるヘッダタイプ間の切り替えが必要である。その理由は、それぞれのエンティティ、ＣＮとＭＮは、自己が使用するタイプのヘッダでカプセル化されたデータパケットを受け取ることを予測するからである。すなわち、ＣＮはクラス１のヘッダの付いたデータパケットを受け取ることを予測する。言い換えれば、ソースアドレスフィールド内に用いられるＩＰアドレス（すなわちＭＮのＣｏＡ）はＣＮには知られていないので、ＣＮは前記パケットがＭＮとの通信に属しているとは認識しない。したがって、ＭＮはクラス２のヘッダを受け取ることを必要とする。その理由は、ＭＮもまたクラス２のヘッダを用いて、ＣＮとの通信のためにデータパケットをカプセル化するからである。

都合よく、本発明は、すでに公知の機構を用いて、ＣＮとＭＮによるちょうど今論じたような異なるヘッダクラスの使用を達成することを示唆している。この点において、例えば、ＭＩＰｖ６プロトコルのルート最適化手順を用いてもよい。これによって達成される一つの利点は、ＭＮが修正される必要がないことである。その理由は、標準的な手順（すなわちＭＩＰｖ６によるルート最適化）を実行するための対応する機能が、すべてのＭＮ内に標準で含まれていると想定されるからである。

背景技術のところですでに述べたように、ＭＩＰｖ６は、双方向トンネリングモード以外の別の動作のモード、ルート最適化モード、をサポートする（図２を参照）。ルート最適化モードは、コレスポンデントノードとモバイルノードの間の直接経路を利用することによって、双方向トンネリングモードのデータ経路の長さに関連した非効率性を防止するのに用いられる。ルート最適化を用いるとき、モバイルノードはバインディングアップデートメッセージをコレスポンデントノードへと送り、該コレスポンデントノードは、データパケットをモバイルノードへと直接送ることができる。もちろんコレスポンデントノードは、モバイルＩＰｖ６ルート最適化ポートを実装しなければならない。

より具体的には、ルート最適化を実行するために、モバイルノードとコレスポンデントノードは、モビリティヘッダプロトコルの一部であるシグナリングメッセージを交換する。該モビリティヘッダは、バインディングの作成及び管理に関連するすべてのメッセージング内で、モバイルノード、コレスポンデントノード及びホームエージェントによって用いられる拡張ヘッダである。ルート最適化に関して、４つのメッセージタイプがモビリティヘッダプロトコルに規定されている。

図５は、ＭＩＰｖ６においてＲＯに対して実行されるシグナリングフロー、及びその中で用いられる大部分のメッセージのパケットフォーマットの一例を図示する。コレスポンデントノードへと送られたバインディングアップデートの保護にあたっては、モバイルノードとコレスポンデントノードの間にはセキュリティ アソシエーションの構成又は認証基盤の存在は必要でない。代わりに、リターンルータビリティ手順とよばれる方法が用いられて、正当なモバイルノードがメッセージを送っていることを保証する。

リターンルータビリティ手順によって、コレスポンデントノードは、モバイルノードが実際にそのホームアドレスだけでなく、獲得された気付アドレスにおいてもアドレス可能であることの一定の合理的な保証を得ることができる。コレスポンデントノードはこの保証のみによって、モバイルノードからのバインディングアップデートを受け取ることができ、モバイルノードは、コレスポンデントノードに対し、モバイルノードのデータトラフィックを自己の獲得された気付アドレスへと向けるよう指示する。

このことは、２個の獲得されたアドレスへ宛てられたパケットがモバイルノードへとルーティングされたか否かをテストすることによって行われる。モバイルノードがテストに合格できるのは、コレスポンデントノードがそれらアドレスへと送る所定のデータ（「キーゲントークン」）をモバイルノードが受け取ったことの証拠をモバイルノードが提供できる場合のみである。これらのデータは、モバイルノードによって、バインディング管理キーへ組み合わせられる。コレスポンデントノードへのバインディングアップデートメッセージの完全性及び信頼性は、バインディング管理キーを用いることによって保護される。

より具体的には、ＭＮは２個のメッセージをＣＮへ送信するが、それぞれ異なるルート上で送信する。一方のメッセージであるホーム テスト イニット（ＨｏＴｉ）メッセージは、ＭＩＰ ＩＰ−ｉｎ−ＩＰトンネル上をＨＡへと送られ、ＨＡはメッセージをＣＮへと転送する。モバイルノードはホーム テスト イニット メッセージをコレスポンデントノードへ（ホームエージェントを介して）送って、ホームキーゲントークンを得る。図５から明らかなように、メッセージは、ＣＮが後で返さなければならないホーム イニット クッキーを含み、ＭＮのホームアドレスをＣＮへと伝える。もう一方のメッセージ、気付テスト イニット（ＣｏＴｉ）は、気付キーゲントークンを得るために、ＣＮへ直接送られる。ＣｏＴｉメッセージは、現在のＭＮの気付アドレスについてＣＮに通知し、気付イニットクッキーを含む。

ＨｏＴｉ及びＣｏＴｉメッセージを受信した後、ＣＮは２個のメッセージをＭＮへ、再び異なるルート上で送り返す。ホームテスト（ＨｏＴ）メッセージはＨｏＴｉメッセージに応答してＭＮのＨｏＡへ、すなわち、ＨＡへと送られる。ＨＡは、メッセージをＭＮへＭＩＰｖ６トンネル上で送る。これに対応して、気付テスト（ＣｏＴ）メッセージはＭＮへと直接送られる。ＨｏＴ及びＣｏＴの両方のメッセージは、「ホームキーゲントークン」及び「気付キーゲントークン」をそれぞれ、かつてのＨｏＴｉ及びＣｏＴｉメッセージから受信したホーム イニット クッキー及び気付イニットクッキーとともに含む。両方のトークンは、ＣＮの現在アクティブな秘密キー、ノンス（nonces）、及び、ホーム又は気付アドレス（それぞれ）に基づいている。

ＨｏＴ及びＣｏＴメッセージがＭＮに到達した後、ＭＮはそれらメッセージのキーゲントークンを用い、ＨｏＴ及びＣｏＴメッセージとともに受信したトークンからバインディング管理キーを生成する。モバイルノードがバインディング管理キーを作成した後は、検証可能なバインディングアップデートをコレスポンデントノードに提供することができる。バインディングアップデートメッセージを受信した後、ＣＮは、自己のバインディングキャッシュをＭＮのＨｏＡ及びＣｏＡのバインディングで更新することができ、データパケットをＭＮへ直接送ることができるようになる。

このようにＭＩＰｖ６は、ＣＮとＭＮの両ノードが直接通信できるように、ＭＮのＨｏＡ及びＣｏＡのＣＮ内のマッピングを可能にすることによって、ＣＮとＭＮの間のルートを最適化することを可能にする。

ルート最適化モードにおいて、ＭＮは、ソースアドレスとしてＭＮの気付アドレスを用いることによって、そしてＭＩＰｖ６に対して定義された特別なＩＰｖ６あて先オプション拡張ヘッダ内にＭＮのホームアドレスを含めることによって、データパケットをＣＮへと直接送信する。したがってＣＮは、あて先アドレスフィールド内のＭＮの気付アドレスを用いることによって、そしてＭＩＰｖ６に対して定義された特別なＩＰｖ６のタイプ２ルーティングヘッダ内にＭＮのホームアドレスを含めることによって、データをＭＮへと直接送信する。

パケットヘッダに関するＭＩＰｖ６内の２個の動作モード間の比較が、図６に示されている。左側には、これまでの段落で既に論じたＨＡによって適用されるＩＰ−ｉｎ−ＩＰカプセル化が図示されている。右側には、ルート最適化されたルートがＣＮとＭＮの間に用いられ、ＨＡを介した迂回を不要とし、ＩＰ−ｉｎ−ＩＰカプセル化を回避している。代わりに、ＭＮのホームアドレスを含むルーティングヘッダオプション（Ｒ．Ｈ．Ｏ．）が、コレスポンデントノードによって挿入され、該アドレスは標的となる受信側アプリケーションのアドレスを意味している。Ｒ．Ｈ．Ｏ．はＭＮのＩＰアドレス（ＨｏＡ）を含み、ＨｏＡがアプリケーション（例えばＨＴＴＰ）によって用いられて、パケットをＣＮへと送る。したがって、ＭＮがパケットを受信した後に、このパケットがどのアプリケーションに属しているかをＲ．Ｈ．Ｏ．のアドレスに基づいて、導き出すことができる。これと対応して、ＭＮはデータパケットをＣＮへと直接送り、ＭＮは、ＭＮのＣｏＡをソースアドレスとして用い、ＭＮのＨｏＡをホームアドレスオプション（Ｈ．Ａ．Ｏ．）フィールド内に挿入し、これによって、どれが送信側アプリケーションのアドレスかをＣＮに指示する。

ルート最適化モードにおいて用いられるＩＰヘッダは、双方向トンネリングモードのＩＰ−ｉｎ−ＩＰヘッダと比べて、サイズがより小さい。例えばサイズはＲ．Ｈ．Ｏ．フィールドは２４バイトでありＨ．Ａ．Ｏ．フィールドは２０バイトであるが、一方、ＭＩＰによって用いられる付加的なＩＰヘッダは４０バイトを有する。したがって、ＭＮとＣＮの間のデータルートを最適化することとは別に、ルート最適化手順が、非ルート最適化モードと比べて、データパケットのヘッダサイズを大幅に縮小できることは明らかである。

しかしながら、ルーティングヘッダオプションをデータパケット内に挿入することによる欠点の一つは、図６から明らかなように、双方向トンネリングと比べて、ＣＮのネットワーク内のトラフィックが増加することである。それぞれのデータパケットは付加的なルーティングオプションフィールドを含み、それらは、アップリンクデータパケットのための２０バイトのＨ．Ａ．Ｏ．又はダウンリンクデータパケットのための２４バイトのＲ．Ｈ．Ｏ．である。さらに、ＲＯが実行された後、通信中にＨＡが迂回されるが、これは、所定の装置及びサービスには許容されない可能性がある。例えばオペレータは、アカウンティング又はセキュリティの理由によってトラフィック全体の制御を続ける必要がある、すなわち、すべてのデータはＨＡを介して移送される必要がある。さらに別の欠点は、ＣＮへの／ＣＮからのシグナリングトラフィックは実際のＲＯ手順によって生成されることである。さらにＣＮは、ＭＮの物理的位置を導き出しうる。その理由は、データパケット内のＣｏＡは位置依存性であり、このことは、ＭＮの位置プライバシーに必然的に影響を及ぼすからである。

本発明の実施の形態は、パケットヘッダサイズを縮小する利点を活用する一方、通常のＲＯで伴う悪影響を回避している。

とりわけ、上記に紹介されたＭＩＰｖ６のルート最適化手順は、ＭＮとＭＮのＨＡとの間で実行され、ＭＮのＨＡは通常と同じようにＣＮに代わってＲＯ手順に参加する。すなわちＨＡは、ＭＮとＣＮの間で実行される通常のＲＯ手順のためのメッセージを傍受し、ＣＮに代わって正確に応答する。

本発明の一つの実施の形態によるＲＯ手順に関与するシグナリングが、本発明のＲＯ手順に用いられるメッセージフォーマットとともに図７に示される。外部ネットワークに接続した後に、ＭＮはまず、最初に自己の新しいＣｏＡをＨＡに登録する。ＭＮは次いで、ルーティング経路の長さを縮小するためにＣＮとのＲＯを開始する。

より具体的には、ＭＮは、ＨＡを介してＣＮへ送られるべきＨｏＴｉメッセージを生成することによってルート最適化の実行を開始する。図７に示されるように、ＨｏＴｉメッセージは、そのあて先アドレスとしてＣＮのアドレスを、そのソースアドレスとしてＭＮのＨｏＡとを含む。図７に示されるように、ＭＮはこのメッセージをＨＡへトンネリング（ＩＰ−ｉｎ−ＩＰカプセル化）し、このことは、ＭＮが、あて先アドレスフィールド内にＨＡのアドレス、ソースアドレスとしての自己のＨｏＡを有する付加的なＩＰヘッダでこのメッセージをカプセル化することを意味している。

これに対応して、ＭＮが、ＣｏＴｉメッセージのソースアドレスとしての自己のＣｏＡ、ＣｏＴｉのあて先アドレスとしてのＣＮのアドレスを有するＣｏＴｉメッセージを生成した後に、ＣｏＴｉメッセージはＨＡへ送られる。ＭＩＰｖ６による通常のＲＯ手順では、ＣｏＴｉメッセージはＨＡを通過せずにＣＮへと直接送られることに留意するべきである。しかしながら、本発明の実施の形態によると、ＨＡが、ＭＮからのＲＯ手順に関するすべてのメッセージを傍受することが必要である。したがって、ＭＮの第１ホップルータ（ＭＮのデフォルトルータとも表される）は、ＨＡがＣｏＴｉメッセージも傍受することができるように、ＣｏＴｉメッセージがＣＮへ直接ではなくＨＡへ転送されることを認識しなければならない。これを達成するために、デフォルトルータは、ＭＮのアドレス、すなわち、ＣｏＴｉのソースアドレスに基づいて、ＣｏＴｉメッセージをＨＡへトンネリングするか否かを決定する。このことは、特定のＭＮからのすべてのＲＯがＨＡを通過することを意味する。デフォルトルータは、ＭＮの登録手順中に及び／又はＭＮの加入者プロファイルに依存して、このトンネリングを行うことを決定することができる。

したがって、ＣｏＴｉはＨＡへ送信されることになっているので、アクセスルータは、例えば、あて先ヘッダフィールド内にＨＡのアドレ、ＩＰヘッダのソースアドレスとしての自己のアドレスを有する付加的なＩＰヘッダでＣｏＴｉメッセージをカプセル化する。さらに、モバイルノードのデフォルトルータは、ＭＮが接続されたネットワークの種類に依存して異なってもよく、例えばノードＢ（Ｎｏｄｅ Ｂ）、ＰＤＧ、ＷＬＡＮネットワークのアクセスルータ、所定のアクセスネットワーク内でＭＮに対するデフォルトルータとして機能する他の任意のデバイスであってもよい。

結果として、ＨＡは両方のメッセージＨｏＴｉ及びＣｏＴｉを受信し、これらメッセージをＣＮへは転送しない。代わりに、ＨＡは適切な応答、ＨｏＴ及びＣｏＴを生成することができ、これによって、ＨｏＴｉ及びＣｏＴｉメッセージが向けられるＣＮとしての働きをする。ＨＡは図７よりわかるように、応答メッセージのソースアドレスとしてＣＮのＩＰアドレスを含み、それによって、仮にＣＮが発生元のＨｏＴｉ、ＣｏＴｉメッセージを受信していたならばＣＮによって生成されていたであろうメッセージと同一の応答メッセージを生成する。ＣｏＴ及びＨｏＴの残存するメッセージフォーマットも図７よりわかる。ＨｏＴメッセージはＭＮのＨｏＡへ宛てられ、ＣｏＴはＭＮのＣｏＡに向かう。したがって、少なくともＨｏＴメッセージは、ＭＮへとトンネリングされるべく、ＨＡによって別のＩＰヘッダ（ＩＰ−ｉｎ−ＩＰカプセル化）とともにカプセル化され、付加的なヘッダは、あて先アドレスとしてＭＮのＣｏＡを用いる。ＣｏＴメッセージはすでにモバイルノードの位置依存アドレスであるＣｏＡに向かっており、したがってＩＰ−ｉｎ−ＩＰカプセル化は必要でない。

上記の結果として、ＭＮはＨＡからＨｏＴ及びＣｏＴを受信し、通常のＲＯ手順のために規定されたＢＵメッセージを作成し、ＨｏＴ及びＣｏＴ中の受信したキーゲントークンに基づいたバインディング管理キーの生成を伴う。ＢＵはＣＮへ向かうが、ＣＮは今起こっているＲＯ手順をわかっていないので、ＨＡがＢＵメッセージを傍受することが必要である。これに対応して、ＭＮの外部ネットワーク内の第１ホップルータはＢＵメッセージを認識し、これをＣＮの方向にルーティングするのではなく、ＨＡへとトンネリングする。ＨＡはＢＵメッセージを受信し、ＭＮ及びＣＮのためのバインディングエントリーを作成する。このことは、ＣＮから着信し、ＭＮへと向けられたデータパケットのＩＰヘッダはクラス１からクラス２へと修正され、ＭＮから着信し、ＣＮへと向かうパケットに対してはその反対が行われることを意味する。言い換えれば、ＨＡ内のＭＮ−ＣＮバインディングエントリーの確立に成功した結果として、ＣＮとＭＮの間で交換されるすべてのデータパケットに対してＩＰヘッダの修正が必要となる。このように、ＲＯ手順が終了する。ＨＡ内のＭＮ−ＣＮバインディングエントリーは、ＭＮのＨｏＡ−ＣｏＡバインディングキャッシュエントリーとは異なることに留意して欲しい。前者は、本発明中に提示された修正されたＲＯの結果であり、後者は通常のＭＩＰｖ６手順の結果である。

ＭＮが参加したＲＯ手順の結果として、ＭＮは、ＳＡ、ＤＡ及びＨ．Ａ．Ｏ．フィールドから成るルーティングヘッダで、ＣＮへ向かうデータパケットのカプセル化を開始する。Ｈ．Ａ．Ｏ．は、図４と関連して紹介したオプションフィールドに対応し、ＭＮのＨｏＡを含む。ＭＮからのデータパケットはＣＮへと向かう（ＤＡを参照）が、上記に論じたように、用いられるヘッダのタイプを切り替えるべく、すべてのデータパケットは、まず、最初にＨＡへと送らなければならない。結果として、データパケットを受信するＭＮのローカルネットワークの内部にあるローカルな第１ホップルータは、ＭＮから受信し、ＣＮへ向かうすべてのデータパケットを、代わりにＨＡへと転送する必要がある。このことは、例えば、第１ホップルータ１０３とＨＡ１１１の間にＩＰトンネリングを設定することによって達成され、その結果、すべてのデータパケットがＨＡへ宛てられた標準的なＩＰヘッダでカプセル化される。このことは、図４中の左側にある付加的なカプセル化（ＳＡ：ＡＲ、ＤＡ：ＨＡ）によって示されている。

本発明の別の有利な実施の形態では、ＡＲは、ＭＮ（不図示）から受信したデータパケットからオプションフィールドを削除してもよい。したがって、データパケットを受信すると、ＡＲは、それぞれのデータパケットのヘッダからオプションフィールドを取り除き、該データパケットをＨＡへとトンネリングするべく、付加的なＩＰヘッダ内で、データパケットをカプセル化する。ＡＲとＨＡの間で用いられるヘッダサイズは、このように８０バイトへとさらに２０バイト分縮小され、ＲＯ手順を実行する前と同じになる。これにより、ＡＲとＨＡの間にＩＰトンネルを要するという欠点が、取り消される。当然のことながら、ＨＡ内で受信したデータパケットのヘッダ内にオプションフィールドが用いられない場合は、ＨＡは、データパケットをＣＮへと転送する前にオプションフィールドを削除する必要はない。

しかしながら、このことは、ＭＮがホームエージェントに登録されたＨｏＡを１個だけ用いる場合のみに可能である。その理由は、ＨＡは、ソースアドレスとしてＭＮのＨｏＡを含むことによって、受信したデータパケットのヘッダをＣＮへ送信されたそれぞれのデータパケットのＩＰヘッダへと適合させる必要があるからである。ＭＮがより多くのホームアドレスをＨＡ内に登録させていたならば、ＨＡは、どのＨｏＡをデータパケットのヘッダ内に含めるかを決定することができない。それにもかかわらずＭＮは、より多数のＨｏＡを他のネットワークに位置する他のＨＡに登録してもよいことに留意するべきである。したがってＡＲは、データパケットヘッダからオプションフィールドを取り除いてもよいか否かを知る必要がある。このことは、ＨＡとのネゴシエーションを介して起こってもよい。

これに対して、ＣＮは当然自己ではなくＨＡによって行われたルート最適化手順を知らないので、データパケットをＭＮへ通常の態様で送り続ける。したがって、ＣＮは依然として、ＭＮのＨＡのアドレスをデータパケットのあて先アドレスとして用い、データパケットは正確にＨＡへとルーティングされる。

ＭＮ及びＣＮは、他の通信パートナーに対しても、自らがそうするようにデータパケットをカプセル化するよう予測している。したがって、ＨＡの付加的な機能とは、ここでは、アップリンク及びダウンリンク内のデータパケットを修正して、ルート最適化がＣＮに対してトランスペアレントなままである一方、ＭＮは自らがデータパケットを、依然としてＨＡを介してではなく、ＣＮへと直接交換していると考えるようにさせることである。

したがって、図４と関連して前に論じたように、ＨＡによってデータパケットは変更されることとなる。すなわち要するに、ＭＮから到着するデータパケットは、ソースアドレスをＭＮのＨｏＡへ変更することによって、そしてＨ．Ａ．Ｏ．を削除することによって適合させられ、その結果、あたかもＭＮによって何のルート最適化も実行されなかったかのように、ＨＡとＣＮの間で交換されるデータパケット内に同一のヘッダ用いられる。これに対応して、ＣＮから着信するデータパケットはＭＮのＨｏＡを含むＲ．Ｈ．Ｏ．によって拡張され、パケットは、ＭＮのＨｏＡの代わりに、ＭＮのＣｏＡに対して再び宛てられる。これにより、ＭＮは、ＣＮがＲＯ手順に参加した、そしてＣＮは今やデータパケットをＭＮへと直接送り、もはやＭＮのＨＡを介さないと信じるようだまされる。

本発明の別の実施の形態によると、ＭＮ１０２は、無線ローカルネットワークエリア内に位置し、ＷＬＡＮは３ＧＰＰシステムと相互作用する。相互作用している３ＧＰＰ−ＷＬＡＮは、以降においてＩ−ＷＬＡＮと称される。無線ネットワークでは、限られた帯域のみが利用可能であるから、無線ネットワーク内のデータトラフィックを縮小することがとりわけ重要である。それにもかかわらず、当業者には容易に理解されうるように、後続のＷＬＡＮシナリオとは異なるネットワーク構造中で、本発明の様々な実施の形態の原理を実装することも可能である。

図８は、Ｉ−ＷＬＡＮ構造の簡略化した概観を図示しており、パケットデータゲートウェイ（ＰＤＧ）１０３は、外部ＩＰネットワークへのＷＬＡＮ ３ＧＰＰ ＩＰアクセスをサポートする。加えて、ＷＬＡＮは、ＷＬＡＮアクセスポイント及び中間ＡＡＡ（認証、許可及びアカウンティング）要素を含む。ＷＬＡＮはルータといった他のデバイスをさらに含んでもよい。ＷＬＡＮが可能なＭＮは、コンピュータ、ＷＬＡＮ無線インタフェースアダプターなどといった、エンドユーザの所有するすべての装置を備える。ＷＬＡＮに接続したＭＮは、インターネットに直接アクセス（直接ＩＰアクセスと呼ばれる）してもよく、又は、３ＧＰＰのオペレータに接続し、オペレータのサービスを用いてもよい。オペレータは通常ＭＮのトラフィック制御を保ちたいので、ＭＮが３ＧＰＰオペレータ上で、すなわちＰＤＧを介してデータサービスにアクセスすることは通常である。

モバイルノードがＷＬＡＮに接続すると、ＭＮはＷＬＡＮネットワーク内にローカルＩＰアドレス（ＭＮ_LA）を構成し、構成されたＭＮ_LAを用いてＰＤＧへのＩＰｓｅｃトンネルを確立する。このＭＮ_LAは、コレスポンデントノードとの通信に用いられず、むしろ、これは、ＷＬＡＮネットワーク内及びＰＤＧとの通信のためだけにＭＮが用いるアドレスである。ＭＮがＰＤＧとのＩＰｓｅｃトンネル（セキュリティ アソシエーションなど）を確立した後、ＭＮは、ＰＤＧのＩＰプリフィックスに基づいてリモートＩＰアドレスを構成する。前記リモートＩＰアドレスは、ＭＮがＨＡと通信するときにＭＮの新しいＣｏＡとして用いられる。後にＭＮは、ＭＩＰ手順を実行して、自己のＨＡにＣｏＡ（ＰＤＧのネットワークからのリモートＩＰアドレス）を登録する必要がある。これを行うときにのみ、ＭＮは自己の発生元のホームＩＰアドレスの使用を継続することができ、このアドレスは、ＷＬＡＮネットワークにハンドオーバする前に、３ＧＰＰネットワーク内でサービスを開始するのに用いられてきた。したがってＭＮは、データパケットを、自己とそのＨＡの間の確立したＭＩＰｖ６トンネル上を、ＣＮへ／から送信／受信する。Ｉ−ＷＬＡＮの場合には、ＨＡはＳＡＥ（システム アーキテクチャ エボルーション）アンカーに実装してもよい。

図９は、Ｉ−ＷＬＡＮ構造のプロトコルスタックを示す。この点において、図９はＷＬＡＮアクセスネットワーク（ＡＮ）及びＷＬＡＮアクセスゲートウェイ（ＷＡＧ）も示しているが、これらは本発明にとっては重要でなく、このため、これ以上論じないこととする。ＭＮのリモートＩＰレイヤは外部のパケットデータネットワーク内でのあて先のため、ＭＮによって用いられて、ＭＮのリモートＩＰアドレスは外部のエンティティとの通信のために利用される。図９の下部には、ＣＮから送信されたデータパケットがＭＮへ向かう途中にあることが示されており、ヘッダフォーマットが詳細に図示されている。明らかにわかるように、ＰＤＧはリモートＩＰパケットを修正を行わずに処理する。しかしながら、トンネリングレイヤは、トンネリングヘッダの内部にあるリモートＩＰパケットをカプセル化し、これによって、ＭＮとＰＤＧの間でのエンドツーエンドトンネリングを可能にする。さらに、トランスポートＩＰレイヤは、中間エンティティ／ネットワークとＷＬＡＮアクセスネットワークが、リモートＩＰレイヤパケットを送信することを可能にし、ここでは、このレイヤ内ではＭＮはローカルＩＰアドレスによって宛てられる。トンネリングレイヤはトランスポートレイヤとともに、ＩＰｓｅｃプロトコルによってトンネリングモードで実装してもよい。

一般にＩＰｓｅｃはＩＰレイヤで、セキュリティサービスを他のプロトコルとアプリケーションに対して提供し、それらが安全に通信できるようにする。すなわち、ＩＰｓｅｃは、安全でない中間システム上での２つの通信ノードの間で、安全な経路を設定する。この点において、ＩＰｓｅｃはセキュリティサービスを提供するいくつかの構成要素から構成され、そのうち２個の主要な構成要素は、認証ヘッダ（ＡＨ：Authentication Header）プロトコル及びカプセル化セキュリティペイロード（ＥＳＰ：Encapsulating Security Payload）プロトコルである。それらは、特定のヘッダをＩＰデータパケットに付加することによって、ＩＰデータに信頼性及びプライバシーを提供する。

再び図９を参照すると、オリジナルのデータパケットは、ＩＰｓｅｃヘッダ内でカプセル化され、あて先アドレスとしてＭＮのローカルアドレス（ＭＮ_LA）、ソースアドレスとしてＰＤＧのアドレスを有し、対応するオプションフィールド内にカプセル化セキュリティペイロード（ＥＳＰ、長さ８バイト）を含む。新しいカプセル化されたパケットのペイロード、すなわちオリジナルのデータパケットが暗号化される。さらにＥＳＰは、データパケットの発生元の信頼性、完全性及び機密性を提供し、一方、ＩＰｓｅｃトンネルによって付加されるパケットオーバーヘッドは合計４８バイトに上る。

本発明の以下の実施の形態は３ＧＰＰ−ＷＬＡＮ構造に制限されるが、ＭＮのネットワーク内の他のアクセス技術も可能であり、同様に本発明の機構も適切にそれら技術に適用されうる。例えば、ＭＮ及びＣＮの両方が同一の種類のネットワークに接続されてもよく、該ネットワークは３ＧＰＰネットワークであってもよい（図４及び７を参照）。考えられる別のアクセス技術はＷＩＭＡＸ（ワールドワイド インターオペラビリティ フォー マイクロウェーブ アクセス）である。

図１０はモバイルノードが無線ローカルエリアネットワーク（ＷＬＡＮ）１２０内に位置する通信システムを示し、パケットデータゲートウェイ（ＰＤＧ）１０３は、ＭＮ１０２がＷＬＡＮから外部のＩＰネットワークへアクセスするのを可能にする。上記に論じたように、ＩＰｓｅｃトンネルがＰＤＧ１０３とＭＮ１０２の間のセキュリティ目的のために利用されると仮定される。詳細には、ＭＮとＰＤＧの間で交換されるすべてのデータパケット及びシグナリングメッセージは、このＩＰｓｅｃトンネル上を流れている。

ＣＮとＭＮの間の通常の通信が、交換されたデータパケットの採用されたヘッダの詳細な図解とともに、ダウンリンク及びアップリンクで図示されている。とりわけ、ＣＮからのダウンリンクを参照すると、発生元のデータパケットはＩＰヘッダを含み、ＣＮのアドレスはソースアドレスであり、ＭＮのホームアドレスはあて先アドレスとして用いられる。したがって、データパケットは、この場合、ホームネットワークの特定の１個のＳＡＥ内における機能として統合されたＨＡへとルーティングされる。しかしながら、ＨＡは、ホームネットワーク内の別個のエンティティであってもよく、又は、異なるエンティティ中に実装されてもよいことに留意するべきである。ＨＡはＳＡＥアンカー内の機能として実装されると仮定されるので、以降においてＨＡ及びＳＡＥはほとんど同じ意味で使用される。

一般的なＭＩＰｖ６手順に従って、ＨＡは、付加的なＩＰヘッダで、ペイロードとしてＣＮからの発生元のデータパケットをカプセル化し、ＩＰヘッダは、ソースアドレスとして自己のアドレス、あて先アドレスとしてＭＮの気付アドレスを含む。このＩＰ−ｉｎ−ＩＰカプセル化は、データパケットにさらに４０バイトを付加する。ＭＮのＣｏＡはＰＤＧのＩＰプレフィックスに基づいているので、データパケットはＰＤＧ１０３に到達し、ＰＤＧ１０３は、ＭＮ１０２が接続されたＷＬＡＮ１２０へのアクセスを提供する。ＰＤＧ１０３はＩＰｓｅｃトンネルの一方の端部であるので、ＰＤＧは、ＩＰｓｅｃヘッダ構築内でＨＡから受信したデータパケットをカプセル化し、ペイロードを暗号化する。ペイロードはここでは、受信データパケット全体となる。より具体的には、ＰＤＧによって生成されたＩＰｓｅｃヘッダは、ローカルネットワーク内において、ソースアドレスとしてＰＤＧのアドレス、あて先アドレスとしてＭＮのローカルアドレスを含み、対応するフィールド内にＥＳＰを付加する。このＩＰｓｅｃトンネルはパケットにさらに別の４８バイトを付加し、ＩＰ−ｉｎ−ＩＰトンネルと合わせて合計８８バイトになる。

これに対応して、ＭＮ１０２から送信されるデータパケットは、３層：ＩＰｓｅｃヘッダ、ＩＰ−ｉｎ−ＩＰヘッダ、及び通常のＩＰヘッダでカプセル化される。したがって、データパケットはＣＮ１０１へ向う途中にカプセル化解除される。すなわち、ＰＤＧがＩＰｓｅｃトンネルの端部であるので、ＩＰｓｅｃヘッダはＰＤＧにおいて取り外される。ＰＤＧはパケットをＨＡへ転送し、ＩＰ−ｉｎ−ＩＰヘッダはホームエージェントで取り除かれ、ホームエージェントはデータパケットをＣＮの方向へ転送する。

図１１に図示される本発明の実施の形態によると、ＭＮはＨｏＴｉ、ＣｏＴｉメッセージを生成することによってルート最適化手順を開始する。ＩＰｓｅｃヘッダは、図１１の右側に図示されるメッセージフォーマットから省略されている。その理由は、ＩＰｓｅｃカプセル化は、ＭＮとＰＤＧの間で送られるすべてのメッセージに等しく適用されるためである。詳細には、ＨｏＴｉメッセージは、ＩＰｓｅｃトンネル上を、次いでＭＩＰトンネル上を（図１１に示されるＩＰカプセル化）をＨＡへ送られる。すべての送信データはＩＰｓｅｃトンネルを通過しなければならないので、ＣｏＴｉメッセージもまたＰＤＧに向けてＩＰｓｅｃトンネル上を送られる。引き続いて、ＣｏＴｉメッセージは通常はＣＮへ直接転送されてＨＡへは転送されないので、ＰＤＧは、ＣｏＴｉをＨＡへとトンネリングするよう構成されなければならず、このことは、ＩＰ−ｉｎ−ＩＰカプセル化とともに実装される。言い換えれば、ＣｏＴｉのあて先ＩＰアドレスはＣＮなので、ＰＤＧとＳＡＥａ（ＨＡ）の間のトンネリングが必要であり、そうでなければ、パケットはＣＮへとルーティングされる。

要するに、ＰＤＧは、ＭＮから送られ、ＣＮへ向けられたＣｏＴｉ及びＢＵメッセージを傍受するべく、制御／信号プレーン中に構成されなければならない。この点において、ＰＤＧは、ＰＤＧが接続されたノードからのすべてのパケットを監視する。データパケットが（ＭＩＰｖ６に用いられる）モビリティヘッダを含む場合には、ＰＤＧはデータパケットをさらに検査して、データパケットがＨｏＴｉ、ＣｏＴｉないしＢＵメッセージであるか否かを判定する。そうである場合、ＰＤＧはデータパケットのソースアドレスを調べ、どのＭＮがパケットを送っているかを判定し、ソースアドレスを内部データベースと比較することによって、対応するＭＮのＳＡＥ（ＨＡ）を導き出す。前記内部データベースは、ＭＮのマッピングをそれと対応するＨＡとともに保持するが、このことは、ＨＡが例えばＳＡＥアンカーの機能であり、いくつかのＳＡＥアンカーがＰＤＧに接続されている場合には、とりわけ重要である。また、ＰＤＧに接続されたＳＡＥアンカーがいくつかある場合には、ＰＤＧはそれぞれのＳＡＥアンカーへのトンネルを確立し、このトンネル（例えばＩＰ−ｉｎ−ＩＰ）は前もって構成されていてもよい。

さらにＨＡは、ＣＮに代わって、ＨｏＴｉ及びＣｏＴｉ両方のメッセージを処理できるものとし、このことは、ＨＡ（又はＳＡＥａ）内の付加的な機能を示唆している。例えば、制御／信号プレーンにおいて、データパケットがモビリティヘッダを含むか否か、それらがＨｏＴｉ、ＣｏＴｉないしＢＵメッセージであるか否かを判定するために、ＭＮから着信するパケットを検査する機能をＳＡＥは実装する必要がある。そうである場合、ＳＡＥａ（ＨＡ）は、ＲＯ手順に関する前記メッセージを傍受する。追加的に、ＨｏＴｉ、ＣｏＴｉ及びＢＵメッセージのＩＰあて先アドレスはＣＮのＩＰアドレスである。結果として、ＨＡは、自己のＩＰアドレスに向けられないパケットを受信し、処理しなければならない。さらに、このようなパケットを受信し、処理するか否かのＨＡの判定は、例えばパケットソースアドレスに基づいてなされる。このように、ＳＡＥがデータパケットを受信するためには、ソースアドレスはすでにＨＡに登録済のモバイルノードを示すものとする。

加えて、ＳＡＥａ（ＨＡ）は、ＭＩＰｖ６のＲＯの根幹をなす機構に関する通常のＭＩＰｖ６の能力が可能なコレスポンデントノードのいくつかの機能を実装する。すなわちＨＡは、有効なＣｏＴ及びＨｏＴメッセージを生成することができる一方、ルーティングメッセージのソースアドレスとして、ＨｏＴｉ／ＣｏＴｉが向かったＣＮのアドレスを用いる。ＳＡＥが、受信したＨｏＴｉ及びＣｏＴｉメッセージに対する２つの応答メッセージを首尾よく作成した後、ＨｏＴメッセージはＭＮへ直接ＩＰトンネリングされ、これは標準的な手順である。次いで、あて先アドレスはＭＮのＣｏＡであるので、ＣｏＴメッセージはＭＮへと正常にルーティングされる（トンネリングなしに）。ＣｏＴ及びＨｏＴはＩＰｓｅｃトンネルをＰＤＧからＭＮへと横断する。ＭＮはルーティングメッセージを受信し、ＣＮがルート最適化手順に参加していないことを知らずに、該メッセージがＣＮから到達すると考える。

これに対応して、ＭＮはバインディングアップデートメッセージを作成し、該メッセージをＰＤＧへＩＰｓｅｃトンネル上を送る。再び、ＰＤＧ中のＢＵメッセージを傍受し、代わりに、メッセージをＨＡへとトンネリングすることが必要である。ＢＵの受信時に、ＳＡＥアンカーはＭＮ及びＣＮのためのバインディングエントリーを作成し、データパケットのＩＰヘッダの修正を開始する。その結果、最適化手順全体はＣＮに対してトランスペアレント性を保ったままであり、ＭＮはＣＮがＲＯ手順に参加しなかったことを認識しない。

とりわけ、ＭＮからＣＮへのアップリンク内のデータパケットは、実行されたルート最適化手順がＣＮには見えないままであるように構成されなければならない。すなわち、パケットフォーマットはルート最適化の前と同一であるものとする。これに対応して、ＣＮからＭＮへのダウンリンクのデータパケットは、ＭＮとＣＮの間の通常の完成したルート最適化手順にしたがってパケットフォーマットを表すべく変更されなければならない。

図１２は、本発明の実施の形態によるルート最適化手順を実行する前後の、ＭＮとＣＮの間で交換されるデータパケットの適用されたヘッダフォーマットの詳細を示す。ＣＮから送信され、ＭＮへ向かうデータパケットに関して、開始時のデータパケットのヘッダフォーマットは通常のＩＰヘッダであり、あて先アドレスとしてＭＮのホームアドレス（ＭＮ_HOA）を伴う。実際のところ、ＨＡとＣＮの間のパケットフォーマットは、ＲＯ方式に関しては同一のままである。引き続き、データパケットはＨＡによって受信され、ＨＡはあて先アドレスをＭＮのＣｏＡへと変更する。さらに、ＨＡはモバイルノードのＨｏＡをＲ．Ｈ．Ｏ．フィールド内に導入する。ＩＰ−ｉｎ−ＩＰカプセル化はもはや必要でない。このようにして、本発明のＲＯ手順の前と比べて、ヘッダサイズは１６バイト縮小される。

データパケットは、位置依存性のＭＮのＣｏＡであるあて先アドレスにしたがって、ＰＤＧへルーティングされる。次いでＰＤＧは、データパケットを受信し、データパケットをＩＰｓｅｃトンネルを介してＭＮへと送る。このとき、新しいあて先アドレスとしてＭＮのローカルアドレスを有するＩＰｓｅｃヘッダでのカプセル化を伴う。

対して、ＭＮから送信されたデータパケットは、開始時には２つのヘッダ：ＩＰｓｅｃヘッダ及びルート最適化ヘッダを含むが、一方、本発明によるＲＯを実行する前には、３つのヘッダ：該ＩＰｓｅｃヘッダ及び２倍の通常のＩＰヘッダ（図１２を参照）があらかじめ必要であった。この図から明らかなように、これによって、ＭＮのＷＬＡＮネットワーク内において、すなわち、ＭＮとＰＤＧの間で、１データパケットあたり２０バイトを節約する。言い換えれば、ＨＡ内に別のＩＰカプセル化を適用するのではなく、代わりにルーティングヘッダオプションのみが挿入される。

ＩＰｓｅｃヘッダはＰＤＧで取り外され、カプセル化を解除されたパケットは、例えばＩＰ−ｉｎ−ＩＰカプセル化においてＨＡ（ＳＡＥａ）へとトンネリングされなければならない。その理由は、あて先アドレスはＣＮのＩＰアドレスなので、そうでなければデータパケットはＣＮへとルーティングされると思われるからである。こうして、ＰＤＧとＨＡ（ＳＡＥａ）の間で、ヘッダサイズは今や１００バイト（４０バイト＋４０バイト＋２０バイト）であり、この結果、ＲＯ手順が実行された前と比べて２０バイトの増加となる。しかしながら、これは逆である。その理由は、増加したヘッダは、コアネットワーク内に、通常用いられ、該ネットワークは、付加的なトラフィックに対処するために十分な帯域を有するからである。ＰＤＧとＭＮの間のＷＬＡＮネットワーク内の無線リンクは帯域が限定されていることがより重要であり、このため、前記リンク上のトラフィックを縮小することはことのほか重要である。

ＨＡは、パケットヘッダがＣＮが予測するパケットヘッダと合致するよう、受信したパケットのパケットヘッダを変更する必要がある。このことは、ソースアドレスフィールド内でのＭＮのＣｏＡとＭＮのＨｏＡとの交換、Ｈ．Ａ．Ｏ．の削除を含んでいる。こうしてＣＮは、ルート最適化手順が発生したことを認識することなくデータを正確に受信する。

要するに、本発明の実施の形態によるルート最適化を適用することによって、データパケットのオーバーヘッドの縮小を達成することができる。ダウンリンク内では、ＭＩＰｖ６が挿入されたＩＰ−ｉｎ−ＩＰトンネルは、２４バイトのみを有するルーティングヘッダオプションによって置き換えられる。４０バイトのＩＰ−ｉｎ−ＩＰオーバーヘッドと比べて、これによってダウンリンクチャンネルに対して１６バイトの節約をもたらす。したがって、アップリンク中では、ＭＩＰｖ６が挿入されたＩＰ−ｉｎ−ＩＰトンネルは、２０バイトを必要とするホームアドレスオプションに置き換えられる。このように、オーバーヘッド全体の縮小は合計２０バイトになる。これによって、ＨＡとＭＮの間でのデータトラフィックが縮小されるという大きな利点が生じる。このことは、ＰＤＧとＭＮの間のインタフェースにおいては、その無線でデータを送るためのリソースは通常は限定されているので、とりわけ有利である。

さらに、ＣＮのネットワークではルート最適化のためのシグナリングが必要でないので、ネットワーク内のデータトラフィックを縮小する。さらに、ルート最適化手順を適用しても、ＨＡがすべての関連したメッセージ傍受するので実際にはデータ経路中には変化が起こらず、その結果、ＣＮはルート最適化を知らない。したがって、すべてのデータは依然としてＨＡを通過しており、このことは所定のサービス又はオペレータによる必要条件になり得る。

また、ＨＡとＣＮの間で交換されるデータパケットはサイズが同一のままであるが、一方、通常のルート最適化によってルーティングオプションフィールドを含むこととなり、このためデータパケットのサイズが増加する。しかしながら、本発明の実施の形態によるＲＯはＣＮに影響しないので、データパケットは変更されない。別の利点は、データパケットからＨＡによって排除されるＭＮのＣｏＡをＣＮは知らないので、ＭＮの位置プライバシーが保持されることである。

本発明の別の実施の形態は、ハードウェア及びソフトウェアを用いた上記に記載された様々な実施の形態の実施に関する。上記本発明の様々な実施の形態は、コンピュータデバイス（処理装置）、例えば汎用の処理装置、デジタル信号処理装置（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド プログラマブル ゲート アレイ（ＦＰＧＡ）又は他のプログラム可能な論理デバイスなどを用いて、実装又は実行されてもよいと認められる。また、本発明の様々な実施の形態は、これらデバイスの組み合わせによって実行又は実施されてもよい。

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

Claims (29)

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. 請求項１５から２２のいずれか１つに記載のネットワークエンティティと、請求項２３から２６のいずれか１つに記載のアクセスルータと、請求項２７又は２８に記載のモバイルノードとを含む通信システム。

Images