JP2010530681A - データ・パケットのヘッダ・サイズ縮小 - Google Patents

Abstract

【課題】データ・パケットのヘッダ・サイズ縮小
【解決手段】
本発明は、少なくとも 外部ヘッダがルーティング目的のために残存するデータ・パケットから、内部ヘッダを除去することによって、データ・パケットのヘッダ・サイズを縮小する方法に関する。データ・パケットから内部ヘッダを除去する時には、受信側および／または送信側エンティティの新たに設定されたアドレスが、データ・パケットの残存する外部ヘッダ中に挿入される。除去された内部ヘッダを再構築するために、コンテクスト情報が受信側エンティティ内に提供され、該コンテクスト情報は、新たに設定されたアドレスによって、すなわち、外部ヘッダのソースおよび／または宛先アドレス中に参照される。縮小されたデータ・パケットは１個のヘッダのみが付いて送信され、これによって各データ・パケットのサイズを大幅に縮小する。元パケットは受信側エンティティにおいて完全に再構築され、これによって、各データ・パケットの通常の処理を続行することを可能にする。
【選択図】図６

Description

本発明は、ある特定の通信経路上にあるデータ・パケットのヘッダ・サイズを縮小する方法に関する。本発明はＭＮとＣＮの間の通信に主として適用され、中間ノードはデータ・パケットの付加的なカプセル化を利用し、これによって、データ・トラフィックを増加させる。とりわけ本発明は、送信側エンティティ内においてデータ・パケットの内部ヘッダを外部ヘッダのアドレスへとコード化し、後に受信側エンティティ内において、外部ヘッダ中の該アドレスによって識別される以前に生成されたコンテクスト情報から該内部ヘッダを復旧するための様々な方法ステップを提供する。さらに本発明は、本発明に参加するネットワーク・エンティティおよび移動ノードに関する。

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

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

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

例示的には、ソース・デバイスがパケットを自己のローカル・ルータへと送信した後に、ローカル・ルータのデータ・リンク層は、該パケットをルータ上方のＩＰ層へと渡す。これに対応して、レイヤ２フレームを取り除いた後に、パケットのレイヤ３ヘッダが調べられ、ルータは、いずれのネクスト・ルータにパケットが送信されるべきかを決定する。それゆえに、パケットは適切なレイヤ２フレーム内で再カプセル化されて、下方のデータ・リンク層へと戻される。データ・リンク層は、パケットを、ルータの物理的ネットワーク・リンクのうち一リンクを介して、決定されたネクスト・ルータへと送信する。

この点においてルータは、様々なネットワークＩＤ（ＩＰアドレス・プレフィクス）と該ルータが接続される他のルータとの間のマッピングを提供する、ルーティングテーブルと呼ばれる一連の情報を保持する。これに対応してルータは、あるデータ・パケットの宛先ＩＰアドレスをルーティングテーブルに照らして確認し、ルーティングテーブルに対する該宛先アドレスの最も長い一致に基づいて、ネクスト・ホップ・ルータを判定する。加えて、ルーティングテーブルごとに定義された計量値によって、所定の基準に基づいて特定のルーティング入力を評価し、ひいては、いくつかの考えられる経路のうち最良の経路を選択することが可能になる。

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

ネットワーク層３（ＯＳＩ）は、パケットのルーティングが実際に発生している層であり、あるデータ・パケットのレイヤ３ヘッダは、中間ネットワークを介してルーティングされている間は変更されない。あるソースおよび宛先のより高位層は単に「論理的に」接続されている、すなわち、真の／物理的な接続性が全くないため、パケットは、下位層２および１を横断して、宛先へと物理的に配信される必要がある。それぞれのレイヤ２内では異なるプロトコルが用いられうるので、たとえばレイヤ３からレイヤ２へと渡される各データ・パケットは、適切に構成されなければならない。

したがって、通常、データ・パケットのカプセル化はある上位層プロトコルからある下位層プロトコルを介してデータを送信するのに用いられる。たとえば、ＩＰｖ４およびＩＰｖ６プロトコルはネットワーク層プロトコルであり、また、ユーザ・データ・プロトコル（ＵＤＰ）または送信制御プロトコル（ＴＣＰ）はトランスポート層プロトコルである。それゆえに、ユーザ・データはＵＤＰデータグラム（レイヤ４）中でカプセル化され、該ＵＤＰデータグラムは次いでＩＰパケット（レイヤ３）中でカプセル化される。続いてＩＰパケットは、カプセル化されたユーザ・データと一緒に、データ・リンク層プロトコル（イーサネット(登録商標)、レイヤ２等）上を送信されてもよく、データ・リンク層プロトコルでも再びカプセル化を伴う。

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

最も一般的に用いられるトンネリング機構の一つがＩＰ（レイヤ３）-ｉｎ-ＩＰ（レイヤ３）カプセル化であり、これは、ＩＰデータグラムを他のＩＰヘッダでカプセル化する処理のことを言い、モバイルＩＰ等に用いられうる。ＭＩＰｖ６とも表されるモバイルＩＰｖ６（D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", IETF RFC 3775, June 2004、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ）は、移動ノードが、より高位層およびアプリケーションにトランスペアレントな態様で、すなわち、より高位層の接続を断つことなく、サブネット間を移動するのを可能にするＩＰベースのモビリティプロトコルである。言い換えれば移動ノードは、ＩＰｖ６インターネット・ネットワーク内を動き回っている間、到達可能なままである。

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

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

より詳細には、移動ノード（主としてＭＮまたはユーザ装置ＵＥと呼ばれる）は、設定された２個のＩＰアドレス、気付アドレスおよびホーム・アドレスを有する。移動ノードのより高位層は、以降主としてコレスポンデント・ノード（ＣＮ）と呼ばれる通信パートナー（宛先端末）との通信のためにホーム・アドレスを用いる。このアドレスは変化せず、移動ノードを識別する目的に資する。該アドレスは位相的には、移動ノードのホーム・ネットワーク（ＨＮ）に属する。対照的に気付アドレスは、移動のたびに変化し結果としてサブネットの変更をきたし、ルーティング下部構造のためのロケータとして用いられる。気付アドレスは位相的には、移動ノードが現在訪問中のネットワークに属する。ホーム・リンク上に位置する一組のホーム・エージェント（ＨＡ）のうち１個が、移動ノードのホーム・アドレスへの移動ノードの気付アドレスのマッピングを保持するとともに、当該移動ノードに対する着信トラフィックを自己の現在の位置へと向け直す。単一のホーム・エージェントの代わりに一組のホーム・エージェントを配置する理由は、冗長およびロード・バランシング等である。

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

移動ノード１０２によって送信されたデータ・パケットは、ホーム・エージェント１１１へとリバース・トンネリングされ、該ホーム・エージェント１１１はパケットのカプセル化解除を行い、パケットをコレスポンデント・ノード１０１へと送信する。リバース・トンネリングとは、パケットが移動ノードによってホーム・エージェントへとトンネリングされることを意味し、「フォワード」トンネリングと「逆向きの」態様である。

ＭＩＰｖ６におけるこの動作に関して、ホーム・エージェント１１１のみが移動ノード１０２の気付アドレスについて通知される。したがって移動ノードは、バインディング更新（ＢＵ）メッセージをホーム・エージェントへと送信する。これらメッセージは都合よく、ＩＰｓｅｃセキュリティ・アソシエーションを介して送信され、ひいては認証され完全性が保護される。

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

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

上記に説明したようにＨＡは、データ・パケットの受信後ただちに、ＭＩＰｖ６手順に基づいてＩＰ−ｉｎ−ＩＰカプセル化を適用し、該カプセル化されたパケットをＭＮへと送信する。言い換えればＨＡは、ＩＰ−ｉｎ−ＩＰカプセル化を適用することによって該受信されたデータ・パケットをＭＮへとトンネリングする。より具体的にはＨＡは、他のＩＰヘッダをパケットに付加し、該付加的なヘッダは自己のアドレスをソース・アドレスとして、ＭＮの気付アドレスを宛先アドレスとして含む。図３から明らかなように、これによってパケット・サイズをさらに４０バイト拡張させる。本発明の様々な実施形態の以下の議論および記載のために、ＨＡにて適用されるＩＰ−ｉｎ−ＩＰヘッダが主として「外部ヘッダ」と呼ばれる一方で、外部ヘッダによってカプセル化されたヘッダは「カプセル化されたヘッダ」または「内部ヘッダ」と呼ばれることに留意するべきである。外部ヘッダおよびカプセル化されたヘッダ（単数または複数）はヘッダ連結を形成する。

ＭＮによって戻されたデータ・パケットは、２個のＩＰヘッダでカプセル化される。外部ヘッダは、パケットをルーティングするためにルータによって用いられるとともに、データ・パケットのＨＡへのトンネリングに関するものであり、ＨＡのアドレスを宛先アドレスとして、ＭＮの気付アドレスをソース・アドレスとして含む。内部ＩＰヘッダは、ＣＮのアドレスを宛先として、ＭＮのホーム・アドレスをソース・アドレスとして含む。

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

このことは、付加的オーバーヘッドが、データ・パケットの受信側エンティティへの転送中に生成される一例にすぎない。他のシナリオでは、さらに付加的なヘッダのバイトを含んでもよい。たとえば、ある特定の経路上にデータのセキュリティが必要である場合には、前記経路上の暗号化されたデータ・パケットを送信するのに、ＩＰｓｅｃプロトコルが用いられてもよいが、該プロトコルはさらに４８バイトを付加する。さらに、前記経路がＨＡと移動ノードの間にあるならば、各データ・パケットが、８８バイト（４０バイト（ＩＰ−ｉｎ−ＩＰ）＋４８バイト（ＩＰｓｅｃ））のオーバーヘッドを有することを意味する。

したがって、従来の上記の課題に鑑みて、本発明の一目的は、移動通信ネットワーク内の２個のエンティティ間でのデータ・パケットの交換を改善することである。

本発明のより具体的な目的は、移動通信システム内の２個のエンティティ間で交換されるデータ・パケットのヘッダ・サイズを縮小することである。

上記目的のうちのうち少なくとも一つは、独立請求項によって解決される。本発明の有利な実施形態は従属請求項である。

２個の端点間のトンネル内では、数個の異なるフローが移送できる。ＩＰフローの場合には、各内部フローは、異なるＩＰヘッダ、すなわちソース／宛先アドレス、トラフィック・クラス、フロー・ラベル等の異なるＩＰヘッダを有してもよい。内部ヘッダをまず除去して後に完全に再構築できるためには、受信機での内部ヘッダの再構築を可能にするために、いくつかの情報がデータ・パケットとともに移送される必要がある。

頑強なヘッダ圧縮（ＲＯＨＣ）機構等、ヘッダ・オーバーヘッドを縮小するためのいくつかの提案は、移送されたデータ・パケットに付加される付加情報に基づいている。このこともまた、回避されるべきいくつかのオーバーヘッドを付加する。本発明中に記載されたヘッダ除去機構は、付加的オーバーヘッドをパケットへと付加せず、ひいては、あるトンネリングされたパケットのヘッダを単一のヘッダ、すなわち、外部ヘッダへと縮小しうる。

本発明の一態様によると、通信経路上のデータ・パケットは、内部ヘッダの一部（単数または複数）を除去することによって、次いで、内部ヘッダを再構築するための情報を含むコンテクストを手段として用いて受信側エンティティ内に内部ヘッダを再構築することによって、縮小される。該コンテクストはコンテクスト識別子によって受信側エンティティ内で識別され、該コンテクスト識別子は、送信側エンティティによって、データ・パケットの外部ヘッダのソースおよび／または宛先アドレスへとコード化され、該外部ヘッダから内部ヘッダの一部（単数または複数）が除去される。それゆえに、このことは付加的オーバーヘッドを何ら付加せず、最良の場合、外部ヘッダのみが残存する。

本発明の一実施形態は、第１のエンティティと第２のエンティティの間の移動通信システムにおいて、通信経路上で交換されるデータ・フローのデータ・パケットのサイズを縮小する方法を提供する。前記通信経路上のデータ・パケットはヘッダ連結を含み、ヘッダ連結中の外部ヘッダは第１および第２のエンティティの間の通信経路上でデータ・パケットを交換するのに用いられる。データ・パケット中においてヘッダ連結を再構築するための情報を含むコンテクストを固有に識別する新しいアドレスが設定される。

次いで、外部ヘッダの宛先またはソース・アドレス・フィールド中のアドレスが、該設定された新しいアドレスで置換される。該外部ヘッダではない少なくとも１個のヘッダの少なくとも一部が、該データ・パケットを第２のエンティティへと送信する前に、ヘッダ連結から除去される。最後に、該少なくとも１個のヘッダの該少なくとも一部が除去されたヘッダ連結がついたデータ・パケットが、第１のエンティティから第２のエンティティへと該通信経路を介して、該宛先またはソース・アドレス・フィールド中の設定された新しいアドレスがついた該外部ヘッダを用いて、送信される。

本発明の他の実施形態によると、ヘッダ連結を再構築するための情報を含むコンテクストは第１および第２のエンティティの間で交換される。新しいアドレスを設定した後ただちに、設定された新しいアドレスはヘッダ連結を再構築するための情報を含むコンテクストと関連付けられる。

本発明の有利な実施形態に関して、第１／第２のエンティティは、該外部ヘッダ以外の、ヘッダ連結中の該少なくとも１個のヘッダの少なくとも一部がデータ・パケットから除去および再構築されるべきダウンリンクおよび／またはアップリンク方向を決定する。決定した後ただちに、第２／第１のエンティティは、該ヘッダ連結中の該少なくとも１個のヘッダのいずれの少なくとも一部が、除去および再構築されるべきかについて通知される。

本発明の別の実施形態では、該第１のエンティティは新しいアドレスを設定する。第１のエンティティから第２のエンティティへと送信されたデータ・パケットの外部ヘッダのソース・アドレス・フィールド中のアドレスが、第１のエンティティの該設定された新しいアドレスで置換される。同様に、第２のエンティティから第１のエンティティへと送信されたデータ・パケットの外部ヘッダの宛先アドレス・フィールド中のアドレスも同じく、第１のエンティティの該設定された新しいアドレスで置換される。１個のみの新しいアドレスを用いることによる一の利点は、１個のエンティティ（ここでは第１のエンティティ）のみが新しいアドレスを設定する必要があることである。このことは、第２のエンティティが配置されているネットワークが、制限されたアドレス空間等を理由に新しいアドレスを設定できない場合には、とりわけ有利である。

本発明のさらに別の実施形態によると、第１のエンティティおよび第２のエンティティのそれぞれが１個の新しいアドレスを設定する。前記場合において、第１のエンティティから第２のエンティティへと送信されたデータ・パケットの外部ヘッダ中のソース／宛先アドレス・フィールドが、第１／第２のエンティティの該設定された新しいアドレスで置換される。

反対に、第２のエンティティから第１のエンティティへと送信されたデータ・パケットの外部ヘッダ中のソース／宛先アドレス・フィールドは、第２／第１のエンティティの該設定された新しいアドレスで置換される。ソース・アドレスが用いられる場合の考えられる一の利点は、いずれのパケットも前記アドレスへと向かわないので、受信側エンティティのインタフェース上で、付加的なＩＰアドレス設定する必要がないことである。

本発明の他の実施形態では、データ・パケットの外部ヘッダは、プレフィクスとインタフェース識別子とから成る元アドレスを含む。新しいアドレスは、元アドレスのプレフィクスを保持しインタフェース識別子を変更することによって、または、プレフィクスおよびインタフェース識別子を変更することによって設定される。

本発明のより有利な実施形態によると、データ・フロー内において、データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部は、データ・パケットごとに変化しうる値を備えたフィールドを含む。前記場合において、変動値は、除去されるべき少なくとも１個のヘッダから、該少なくとも１個のヘッダの該少なくとも一部中の該変動値を備えたフィールドに対応する外部ヘッダ中のフィールドへと複写される。これによって、本発明の実施形態を完全に静的でないヘッダへと適用することが簡単に可能となる。

本発明の異なる実施形態を参照すると、データ・フロー内において、データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダは、データ・パケットごとに変化しうる値を備えたフィールドを含む。除去されるべき該少なくとも１個のヘッダの該少なくとも一部のフィールド中の該値の変化の割合は、データ・パケットごとに決定される。本発明の実施形態は、該値の変化の割合が所定値未満である場合にのみ実行される。

本発明のより有利な実施形態では、データ・フロー内において、データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部は、データ・パケットごとに変化しうる値を備えたフィールドを含む。前記フィールドのこれら変動値のうち異なる値それぞれに対し、異なる新しいアドレスが設定される、異なる新しいアドレスそれぞれは、異なる値を含むヘッダ連結を再構築するための情報を含む異なるコンテクストを固有に識別する。

このことが有利なのは、例えば、除去されるべきヘッダ中のフィールドを変更することにかかわらず、あるデータ・パケットのヘッダを、最良の場合わずか１個の外部ヘッダへと縮小することが可能であるからである。

本発明の他の実施形態によると、データ・フロー内において、データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部は、データ・パケットごとに変化しうる値を備えたフィールドを含む。第１のエンティティおよび第２のエンティティのそれぞれが新しいアドレスを設定することがさらに想定される。このような場合には、該外部ヘッダの該ソース／宛先アドレス・フィールド中のアドレスは、第１のエンティティの該設定された新しいアドレスで置換される。さらに、該外部ヘッダの該宛先／ソース・アドレス・フィールド中のアドレスは、第２のエンティティの該設定された新しいアドレスで置換される。該第１／第２のエンティティの該設定された新しいアドレスは、該変動値を備えた該フィールドを再構築するためのコンテクストを固有に識別し、該第２／第１のエンティティの該設定された新しいアドレスは、該変動値を備えた該フィールドを除いて、ヘッダ連結を再構築するためのコンテクストを固有に識別する。この融合的なアプローチは、少なくとも、変化するフィールドに対処するためにおそらく１個のエンティティのみが多数のＩＰアドレスを割り当てる必要がある一方、他のエンティティは、除去されるべき内部ヘッダの静的なフィールドの１個の新しいＩＰアドレスのみでなんとかやっていけるという理由で、有利である。

本発明の異なる実施形態に関して、第１のエンティティは、ヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部を表す第１のハッシュ値を生成する。第１のハッシュ値は、該少なくとも１個のヘッダの該少なくとも一部のフィールドにある特定の計算を実行することから生じる。該生成された第１のハッシュ値と、該設定された新しいアドレスと、第１のハッシュ値の計算が実行される該少なくとも１個のヘッダの該少なくとも一部のフィールドの情報と、を含むメッセージが、第１のエンティティから第２のエンティティへと送信される。第２のエンティティは、該受信された情報によって指示された、該少なくとも１個のヘッダの該少なくとも一部のフィールドに該特定の計算を、各受信されたデータ・パケットごとに実行することによって、第２のハッシュ値を生成する。第２のエンティティは、該受信された第１のハッシュ値を受信されたデータ・パケットそれぞれの第２のハッシュ値と照合することによって、再構築されるべきであり、および／または、少なくとも１個のヘッダの少なくとも一部が除去されなければならない、受信されたデータ・パケットのヘッダ連結を、識別する。さらに第２のエンティティは、第１のエンティティの該受信された設定された新しいアドレスを、該識別されたヘッダ連結を再構築するためのコンテクストで関連付ける。完全なヘッダを第２のエンティティへと送信する代わりに、ハッシュ値を送信するだけで十分であり、これによってメッセージのサイズを縮小する。

本発明のより有利な実施形態によると、第１のエンティティは、ヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部を表す第１のハッシュ値を生成する。第１のハッシュ値は、該少なくとも１個のヘッダの該少なくとも一部のフィールドにある特定の計算を実行することから生じる。該生成された第１のハッシュ値と、第１のハッシュ値の計算が実行される該少なくとも１個のヘッダの該少なくとも一部のフィールドの情報と、を含むメッセージが、第１のエンティティから第２のエンティティへと送信される。第２のエンティティは、該受信された情報によって指示された、該少なくとも１個のヘッダの該少なくとも一部のフィールドに該特定の計算を、各受信されたデータ・パケットごとに実行することによって、第２のハッシュ値を生成する。第２のエンティティは、該受信された第１のハッシュ値を受信されたデータ・パケットそれぞれの第２のハッシュ値と照合することによって、再構築されるべきであり、および／または、少なくとも１個のヘッダの少なくとも一部が除去されなければならない、受信されたデータ・パケットのヘッダ連結を識別する。第２のエンティティは、第１のエンティティの元アドレスと比較してサブネット・プレフィクスを保持し、第１のハッシュ値を第１のエンティティの新しいアドレスのインタフェース識別子として用いることによって、第１のエンティティの新しいアドレスを演繹する。さらに、第２のエンティティは、第１のエンティティの該演繹された新しいアドレスを、該識別されたヘッダ連結を再構築するためのコンテクストと関連付ける。ただし、第２のエンティティが任意のインタフェース識別子を設定することができるならば、第２のエンティティは、アドレスを設定するのに第１のエンティティの第１のハッシュ値を用いてもよい。次いで、第１のエンティティも第１のハッシュ値を知っているので、第１のエンティティは、いずれのＩＰアドレスが第２のエンティティによって用いられるかを知っている。したがって、第２のエンティティの該新しいアドレスについて第１のエンティティに連絡するべく、メッセージを第１のエンティティへと送信する必要はない。

本発明の一実施形態は、不完全なヘッダ連結を含む受信されたデータ・パケットから、ヘッダ連結を含むデータ・パケットを生成する方法を提供する。データ・パケットは、第１のエンティティと第２のエンティティの間の移動通信システムにおいて、通信経路上で交換されるデータ・フローに属する。不完全なヘッダ連結であるが、少なくとも外部ヘッダを含むデータ・パケットが受信される。データ・パケット中の該外部ヘッダは、第１のエンティティと第２のエンティティの間の通信経路上のデータ・パケットの交換のために用いられてきた。さらに該外部ヘッダは、完全なヘッダ連結を再構築するための情報を含むコンテクストを固有に識別するアドレスを含む。該受信されたデータ・パケットのための完全なヘッダ連結は、該受信されたデータ・パケットの外部ヘッダ中のアドレスによって識別されたコンテクスト中の情報に基づいて、再構築される。

本発明の他の実施形態によると、第２のエンティティは完全なヘッダ連結を再構築するか否かを決定する。完全なヘッダ連結を再構築しないと決定される場合には、完全なヘッダ連結のうちいずれの部分が再構築されるべきかが決定される。次いで、完全なヘッダ連結のうち該決定された部分が、該受信されたデータ・パケットの外部ヘッダ中のアドレスによって識別されたコンテクスト中の情報に基づいて再構築される。

本発明の一実施形態は、自己と第２のエンティティの間の移動通信システムにおいて通信経路上のデータ・フローのデータ・パケットのサイズを縮小するエンティティを提供する。前記通信経路上のデータ・パケットはヘッダ連結を含み、ヘッダ連結中の外部ヘッダは、エンティティと第２のエンティティの間の通信経路上でデータ・パケットを交換するのに用いられる。該エンティティ内の処理装置は、データ・パケット中のヘッダ連結の再構築のための情報を含むコンテクストを固有に識別する、新しいアドレスを設定する。処理装置は、外部ヘッダの宛先またはソース・アドレス・フィールド中のアドレスを、該設定された新しいアドレスで置換する。処理装置は、該外部ヘッダではない少なくとも１個のヘッダの少なくとも一部をヘッダ連結から除去する。該エンティティ内の送信機は、該宛先またはソース・アドレス・フィールド中の該設定された新しいアドレスがついた該外部ヘッダを用いて、該外部ヘッダではない該少なくとも１個のヘッダの該少なくとも一部が除去されたヘッダ連結がついたデータ・パケットを、第２のエンティティへと送信する。

本発明の一実施形態は、不完全なヘッダ連結を含む受信されたデータ・パケットから、ヘッダ連結を含むデータ・パケットを生成するエンティティを提供する。該データ・パケットは、第１のエンティティと該エンティティの間の移動通信システムにおいて通信経路上で交換されるデータ・フローに属する。該エンティティ内の受信機が、不完全なヘッダ連結であるが、第１のエンティティと該エンティティの間の通信経路上のデータ・パケットの交換に用いられてきた、少なくとも外部ヘッダを含むデータ・パケットを受信する。外部ヘッダは、完全なヘッダ連結を再構築するための情報を含むコンテクストを固有に識別するアドレスを含む。処理装置が、該受信されたデータ・パケットの外部ヘッダ中のアドレスによって識別されたコンテクスト中の情報に基づいて、該受信されたデータ・パケットのための完全なヘッダ連結を再構築する。

本発明の別の実施形態は、第１のエンティティと第２のエンティティの間で交換されるデータ・フローのデータ・パケットのサイズを縮小する方法を提供する。前記データ・フローのデータ・パケットは、第１および第２のエンティティの間でデータ・パケットを交換するのに用いられる外部ヘッダと第１の内部ヘッダとを含むヘッダ連結を含む。さらに、第１および第２のエンティティは、インターネット・プロトコル・バージョン４をサポートするネットワーク内に配置されている。あるデータ・パケットの外部ヘッダは、インターネット・プロトコル・バージョン４タイプに適応している。データ・パケット中でヘッダ連結を再構築するための情報を含むコンテクストの固有に識別する新しいポート番号が、設定される。ヘッダ連結の該第１の内部ヘッダの宛先またはソース・フィールド中のポート番号は、該設定された新しいポート番号で置換される。データ・パケットを第２のエンティティへと送信する前に、該外部ヘッダおよび該第１の内部ヘッダではない、少なくとも１個のヘッダの少なくとも一部がヘッダ連結から除去される。引き続いて、該少なくとも１個のヘッダの該少なくとも一部が除去されたヘッダ連結がついたデータ・パケットが、該設定された新しいポート番号がついた該外部ヘッダおよび該第１の内部ヘッダを用いて、第１のエンティティから第２のエンティティへと送信される。

本発明の有利な実施形態によると、第１の内部ヘッダおよび該第１の内部ヘッダ中のポート番号は、ユーザ・データグラム・プロトコルまたは送信制御プロトコルに属する。

本発明の別の実施形態を参照すると、データ・フロー内において、データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部は、データ・パケットごとに変化しうる値を備えたフィールドを含む。前記場合において変動値は、除去されるべき該少なくとも１個のヘッダの該少なくとも一部から、外部ヘッダ中の適切なフィールドへと複写される。代替的には、該変動値を備えたフィールドは全く除去されない。さらに代替的には、該フィールド中に変動値を含むデータ・パケット中でヘッダ連結を再構築するための情報を含むコンテクストをそれぞれ固有に識別する新しいポート番号が、フィールドの各変動値に設定される。

本発明の他の有利な実施形態では、ネットワーク・アドレス変換、ＮＡＴが第２のエンティティに用いられ、データ・パケットはＮＡＴルータを介して第１および第２のエンティティの間で交換される。ＮＡＴルータ内で該設定された新しいポート番号を用いて、第１のエンティティからのデータ・パケットの受信および転送を可能にするために、データ・パケットは、宛先またはソース・フィールド中の該設定された新しいポート番号を用いて、第２のエンティティからＮＡＴルータを介して第１のエンティティへと送信される。

本発明の異なる実施形態によると、ネットワーク・アドレス変換、ＮＡＴが第２のエンティティに用いられ、データ・パケットはＮＡＴルータを介して第１および第２のエンティティの間で交換される。設定メッセージは、第２のエンティティから第１のエンティティへとＮＡＴルータを介して送信され、該設定メッセージは、第２のエンティティから、該第１の内部ヘッダのソース・フィールド中の第１のポート番号を用いて送信され、該設定メッセージは、ＮＡＴルータから第１のエンティティへと、該第１の内部ヘッダのソース・フィールド中の第２のポート番号を用いて転送される。次いで第１のエンティティ内で、第２のポート番号が、データ・パケット中でヘッダ連結を再構築するための情報を含むコンテクストを固有に識別する新しいポート番号として決定される。

本発明の別の実施形態では、該設定された新しいポート番号は、少なくともデータ・パケットが交換されるエンティティに関して、少なくとも１個のデータ・フローが存在するセッションに関して、および、データ・パケットのデータ・フローに関して階層的に構成されている。

本発明の一実施形態は、不完全なヘッダ連結を含む受信されたデータ・パケットから、ヘッダ連結を含むデータ・パケットを生成する方法を提供する。該データ・パケットは、第１のエンティティと第２のエンティティの間で交換されるデータ・フローに属する。不完全なヘッダ連結であるが、第１のエンティティと第２のエンティティの間のデータ・パケットの交換に用いられてきた、少なくとも外部ヘッダと第１の内部ヘッダとを含むデータ・パケットが受信される。第１の内部ヘッダは、完全なヘッダ連結を再構築するための情報を含むコンテクストを固有に識別するポート番号を含む。該受信されたデータ・パケットのための完全なヘッダ連結は、該受信されたデータ・パケットの該第１の内部ヘッダ中のポート番号によって識別されたコンテクスト中の情報に基づいて、再構築される。

本発明の一実施形態は、自己と第２のエンティティの間で交換されるデータ・フローのデータ・パケットのサイズを縮小するエンティティを提供する。該データ・パケットはヘッダ連結を含み、ヘッダ連結中の外部ヘッダと第１の内部ヘッダが、該エンティティと第２のエンティティの間でデータ・パケットを交換するのに用いられ、該エンティティと第２のエンティティとがインターネット・プロトコル・バージョン４をサポートするネットワーク内に配置される。該エンティティの処理装置が、あるデータ・パケットの外部ヘッダをインターネット・プロトコル・バージョン４タイプへと適合させる。該処理装置は、データ・パケット中のヘッダ連結の再構築のための情報を含むコンテクストを固有に識別する新しいポート番号をさらに設定する。該処理装置は次いで、該第１の内部ヘッダの宛先またはソース・フィールド中のポート番号を、該設定された新しいポート番号で置換する。該処理装置は、該外部ヘッダおよび該第１の内部ヘッダではない少なくとも１個のヘッダの少なくとも一部を、ヘッダ連結から除去する。該エンティティの送信機が、宛先またはソース・フィールド中の該設定された新しいポート番号がついた第１の内部ヘッダを用いて、該少なくとも１個のヘッダの該少なくとも一部が除去されたヘッダ連結がついたデータ・パケットを、第２のエンティティへと送信する。

本発明の一実施形態は、不完全なヘッダ連結を含む受信されたデータ・パケットから、ヘッダ連結を含むデータ・パケットを生成するエンティティをさらに提供する。該データ・パケットは、第１のエンティティと該エンティティの間で交換されるデータ・フローに属する。該エンティティの受信機が、不完全なヘッダ連結であるが、第１のエンティティと該エンティティの間のデータ・パケットの交換に用いられてきた、少なくとも外部ヘッダと第１の内部ヘッダとを含むデータ・パケットを受信する。該第１の内部ヘッダは、完全なヘッダ連結を再構築するための情報を含むコンテクストを固有に識別するポート番号を含む。次いで、該エンティティの処理装置が、該受信されたデータ・パケットの該第１の内部ヘッダ中のポート番号によって識別されたコンテクスト中の情報に基づいて、該受信されたデータ・パケットのための完全なヘッダ連結を再構築する。

ＭＩＰｖ６による移動ノードとコレスポンデント・ノードの間の通信のための双方向トンネリングの使用を例示する図である。 ＭＩＰｖ６による移動ノードとコレスポンデント・ノードの間の通信のためのルート最適化の使用を例示する図である。 ＭＩＰｖ６の双方向トンネリング・モードにある場合の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを示す図である。 様々なヘッダ・フィールドがついた標準的なＩＰヘッダを示す図である。 ２個の新しいアドレスが内部ヘッダを除去／再構築するのに用いられる本発明の実施形態の前および後に適用される、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 ２個の新しいアドレスが内部ヘッダを除去／再構築するのに用いられる本発明の実施形態による、ヘッダ除去を開始するためのＭＮとＨＡの間のメッセージ交換を図示するシグナリング図である。 本発明の一実施形態によるヘッダ除去コンテクスト識別子が、ソース・アドレス・フィールド中のＩＰアドレスのインタフェース識別子である、ＩＰヘッダを描写した図である。 １個の新しいアドレスのみが内部ヘッダを除去／再構築するのに用いられる本発明の他の実施形態による、ヘッダ除去を開始するためのＭＮとＨＡの間のメッセージ交換を図示するシグナリング図である。 １個の新しいアドレスのみが内部ヘッダを除去／再構築するのに用いられる本発明の一実施形態を適用する前および後に、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 実際の内部ヘッダの代わりにハッシュ値が計算されおよびＨＡへと送信される本発明の他の実施形態による、ヘッダ除去を開始するためのＭＮとＨＡの間のメッセージ交換を図示するシグナリング図である。 変化するフィールドの値（ここでは、内部ホップ・リミット）もまたソース・アドレスへとコード化される本発明の異なる実施形態によるＩＰヘッダを描写した図である。 変化するフィールドが外部ヘッダのソース・アドレスへとコード化され、静的なフィールドが外部ヘッダの宛先アドレスへとコード化される融合的なアプローチが実行される、本発明の他の実施形態によるダウンリンク／アップリンク・データ・パケットのＩＰヘッダを示す図である。 変化するフィールドが外部ヘッダの宛先アドレスへとコード化され、静的なフィールドが外部ヘッダのソース・アドレスへとコード化される本発明の先の実施形態による、アップリンク／ダウンリンク・データ・パケットのＩＰヘッダを示す図である。 融合的なアプローチが実行される本発明の先の実施形態を適用する前および後の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 ＭＮがＷＬＡＮ内に配置されている本発明の他の実施形態のネットワーク・シナリオの概観を示し、ここでは、様々なエンティティ間の様々なトンネルが図示された図である。 １個の外部ヘッダと３個の内部ヘッダとを含む本発明の先の実施形態のデータ・パケット・ヘッダを示す図である。 本発明の実施形態がＨＡとＭＮの間で実行され、その結果として、アップリンクおよびダウンリンクの２個の様々なフローをきたす、ネットワーク・シナリオの概観を示す図である。 本発明の先の実施形態を適用する前および後の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 ＳＩＰ／ＳＤＰ拡張を用いる際の本発明の実施形態のシグナリング図である。 本発明の一実施形態が適用されたネットワーク・シナリオの概観を示し、該実施形態は続いて、ネットワーク内の様々なネットワークでヘッダ除去を実行することを説明するための図である。 対応するヘッダ・フィールドがついた標準的なＩＰｖ４ヘッダを示す図である。 ２個のＩＰｖ４ソース・アドレスが内部ヘッダを除去／再構築するのに用いられる、本発明の一実施形態を適用する前および後で、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 外部ＩＰｖ４ヘッダが採用される場合に、さらに内部ヘッダの変化するフィールド中の特定の値Ｘが結果生じる外部ヘッダのアドレスへとコード化される場合に、本発明の一実施形態を適用する前および後でデータ・パケットを比較する図である。 外部ＩＰｖ４ヘッダが採用される場合に、さらに内部ヘッダの変化するフィールド中の特定の値Ｙが結果生じる外部ヘッダのアドレスへとコード化される場合に、本発明の一実施形態を適用する前および後でデータ・パケットを比較する図である。 外部ＩＰｖ４ヘッダが採用される場合に、さらに内部ヘッダの変化するフィールド中の特定の値Ｘがポート番号へとコード化される場合に、本発明の一実施形態を適用する前および後でデータ・パケットを比較する図である。 外部ＩＰｖ４ヘッダが採用される場合に、さらに内部ヘッダの変化するフィールド中の特定の値Ｙがポート番号へとコード化される場合に、本発明の一実施形態を適用する前および後でデータ・パケットを比較する図である。 ポート番号がコンテクスト識別子として用いられる本発明の一実施形態を適用する前および後の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 ポート番号がコンテクストＩＤとして用いられる本発明の一実施形態を適用した後に、ＭＮと２個のＣＮ、ＣＮ１およびＣＮ２の間での通信中に用いられるデータ・パケット・フォーマットを示す図である。 ＮＡＴルータがＨＡとＭＮの間で配置されていると想定され、ポート番号がヘッダ除去のためにコンテクストＩＤとして用いられる、本発明の一実施形態を適用する前および後の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。 ｅＰＤＧがＨＡとＭＮの間で配置されていると想定され、アドレスがヘッダ除去のためにコンテクストＩＤとして用いられる、本発明の一実施形態を適用する前および後の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比した図である。

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

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

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

カプセル化されたヘッダは、他のヘッダによってカプセル化される任意の種類のヘッダである。

ヘッダ連結は、連結中のヘッダ間の厳密な関係、ならびに、連結中の各ヘッダのコンテンツ（内容）を含む、連続的に配置された少なくとも２個のヘッダを意味する。

以下の段落は、本発明の様々な実施形態を記載する。例示的な目的のためにのみ、実施形態のいくつかは３ＧＰＰ通信システムと関連して概略が説明される。本発明は、例えば３ＧＰＰ通信システムといった移動通信システムと関連して有利に用いられうるが、本発明は、この特定の例示的な通信ネットワーク内での使用には限定されないことに留意するべきである。

上記の技術分野のセクション中で提供された説明は、本明細書中に記載された具体的な例示的な実施形態をよりよく理解するよう意図されており、該説明は、本発明を、移動通信ネットワーク中の処理および機能を、特定の記載された実施に限定するものとして理解されるべきでない。それにもかかわらず、本明細書中に提案された改善は、技術分野のセクションで記載されたアーキテクチャ／システム中で容易に適用されてもよく、本発明のいくつかの実施形態において、これらアーキテクチャ／システムの標準的で改善された手順も活用してもよい。

本発明の様々な実施形態を詳細に論じる前に、ＩＰヘッダが図４中に提示される。該ヘッダは、データ・パケットごとに必要である。該ヘッダは、データ・パケットの処理およびルーティングを管理するのに用いられるアドレス指定および制御情報を含む。

図５は、本発明の一実施形態を適用する前および後の、ＣＮ１０１とＭＮ１０２の間でＨＡ１１１を介して交換されるデータ・パケットの対応するヘッダ・フォーマットを示す。一見したところ、ネットワーク・アーキテクチャは、前に紹介および議論された図３に非常に類似している。ヘッダ連結は２個のＩＰヘッダ、この例ではＭＩＰｖ６プロトコルに起因するＩＰヘッダから成る。

本発明の該実施形態によると、ＭＮとＨＡの間でデータ・パケットを交換するのに新しいアドレスが外部ヘッダ中で用いられ、データ・パケットを実際に送信する前に内部ヘッダが除去される。より詳細に図５に関して、本発明の本実施形態では、各データ・パケットの外部ヘッダのソース・アドレスが、該除去された内部ヘッダをコード化するのに用いられる。すなわち、新しいアドレスが、ＨＡとＭＮの間の前記通信経路上のデータ・パケットのソース・アドレスとして用いられる。例えば、ホーム・エージェントの元アドレスＨＡを用いる代わりに、新しいアドレスＨＡ２が、ホーム・エージェント１１１からＭＮ１０２へと送信されているデータ・パケットのソース・アドレスとして用いられる。同時に、内部ＩＰヘッダがダウンリンク・データ・パケットから除去される。類推的に、ＭＮの元アドレスＭＮ_COAの代わりに、新しいアドレスＭＮ_COA2が、ＭＮ１０２からＨＡ１１１へと送信されるデータ・パケットのソース・アドレスとして挿入され、および、該カプセル化されたヘッダは、データ・パケットを実際にＨＡへと送信する前に削除される。

ＭＮであれまたはＨＡであれ受信側エンティティが、ＨＡであれまたはＭＮであれ送信側エンティティによって以前削除されたカプセル化されたヘッダを含むヘッダ連結を再構築するには、該エンティティ内に適切なコンテクスト情報を保持することが必要である。より詳細にはＨＡは、ＭＮによって削除されたカプセル化されたヘッダの厳密なコンテンツを知っている必要がある。さらに、該受信されたデータ・パケットの外部ヘッダ中に用いられる新しいアドレスＭＮ_COA2が内部ヘッダをコード化するために採用されるので、削除された内部ヘッダと、コンテクストＩＤとしての役割を果たす新しいアドレスの間の関連付けは、ＨＡ内で利用可能でなければならない。したがって、ＨＡがソース・アドレスであるＭＮ_COA2がついたデータ・パケットを受信する時、ＨＡは、新しいソース・アドレスを手段として用いて、該データ・パケットを、本発明の実施形態によるヘッダ除去手順が適用されたデータ・パケットとして、認識する。

それゆえに、ＨＡは次いで、任意の種類の記憶装置内のＨＡ内に以前に保存されたカプセル化されたヘッダを、受信されたデータ・パケットへと挿入する。外部ヘッダは、終了時に、完全なヘッダ連結が外部ヘッダを含めて復旧されるように、本発明の実施形態が適用される前の外部ヘッダに類似するよう構成されてもよい。厳密には、外部ヘッダ中のソース・アドレスＭＮ_COA2は、ＭＮの元アドレスＭＮ_COAによって置き換えられる。次いで、データ・パケットは通常の形態でより高位層へと渡される。代替的には、外部ヘッダは、データ・パケットのＭＮからの受信の後にのみ、除去されうる。

反対に、ＭＮは、データ・パケットを、該受信されたデータ・パケットの外部ヘッダ中のソース・アドレスがＨＡ２の時に、本発明の実施形態によるヘッダ除去手順を受けたデータ・パケットとして認識する。かかるデータ・パケットを認識した後ただちに、ＭＮはアドレスＨＡ２を、任意の種類の記憶装置内において以前に保存された対応するカプセル化されたヘッダと照合するよう試みる。該関連付けられたカプセル化されたヘッダは、次いでデータ・パケットへと挿入され、外部ヘッダは上記に説明したように、同じく適合させられるか、あるいは単に除去される。

これによって、ＨＡとＭＮの間で送信されるデータ・パケットのサイズを大幅に縮小することが可能である。より詳細には、本発明の該実施形態の実行前のヘッダのサイズは、２個のＩＰヘッダが存在しているので８０バイトである。それとは対照的に、本発明の該実施形態を適用した後には、１個のヘッダのみが残存し、ひいては４０バイトのみがオーバーヘッドとなる。一見したところ、ヘッダ・サイズは２倍だけ縮小し、２個のエンド・エンティティ間の経路に対して、帯域幅使用の重要な縮小をもたらす。

しかしながら本発明は、完全な内部ヘッダを除去することに限定されないことに留意するべきである。本発明の原理は、内部ヘッダ（単数または複数）の具体的な部分のみを除去することにも同様に適用される。例えば、残存する内部ヘッダ構造およびコンテンツを保持しながら、アドレス・フィールド（ソースおよび宛先アドレス）が、内部ヘッダから除去されてもよい。内部ヘッダのいずれの部分が除去されるべきかは、完全に、前記態様または事業者を決定するエンティティ次第である。

図６は、本発明の実施形態を可能にするためのＭＮとＨＡの間のシグナル交換を図示し、ここでＭＮは、２個以上のヘッダが存在する（後述する）か、または、完全な内部ヘッダが除去されるべきでなくその一部のみが除去されるべきである場合には、いずれのヘッダが除去されるべきかを決定する。また、ＭＮは、ＨＡとＭＮの間でのデータ・フローのダウンリンクならびにアップリンク方向において、いずれのヘッダが除去されるべきかを決定してもよい。少なくとも１個のエンティティが、本発明の実施形態を適用するか否かを決定し、本発明の実施形態が適用されるべき場合には、アップリンクおよびダウンリンク方向においてすべての内部ヘッダを除去するかまたはその一部のみを除去するかを決定する能力を有する必要があることに留意するべきである。例えば、内部ヘッダが、ある具体的なＩＰフロー内をパケットからパケットへと変化するフィールドを有する場合があり、これは本発明の該実施形態の実行を困難にするであろうが、この件は後により詳細に説明される。

ＵＥが、図５の例に図示されるように、完全な内部ヘッダを除去することを決定すると想定する。さらに、本発明のこの例示的な実施形態では、該手順はＭＮによって開始され、ソース・アドレスは、内部ヘッダ情報を外部ヘッダへと識別するコンテクストＩＤをコード化するのに用いられるので、ＭＮとＨＡの両方が新しいＩＰアドレスを設定する必要がある。

前記観点において、ホスト中のＩＰｖ６アドレスの動的な、すなわち非手動もしくは非静的な構成には、２個の機構：ステートフルアドレス自動設定およびステートレスアドレス自動設定がある。該ステートレス自動設定は、ホストの非手動の事前設定を必要とせず、ルータの最小の設定を必要とし、ネットワーク内に付加的なサーバーを何ら必要としない。該ステートレス機構は、ホストが、ホストごとに特有のインタフェース識別子の情報（レイヤ２アドレス等）とルータによって通告されたプレフィクス情報の組み合わせを用いて、自己のアドレスを生成するのを許可する。ルータは、ＩＰリンクと関連付けられたサブネット（単数または複数）を識別するプレフィクスを通告し、一方、ホストはサブネット上のインタフェースを固有に識別する「インタフェース識別子」を生成する。通告されたプレフィクスと固有の識別子を組み合わせることによって、アドレスが形成される。ルータの非存在時には、ホストは公知のプレフィクスがついたリンク・ローカルなアドレスのみを生成することができる。しかしながら、同一のＩＰリンクに接続されたノード間の通信を可能にするには、リンク・ローカルなアドレスのみで十分である。

該ステートフル自動設定モデルでは、ホストは、ＩＰアドレスおよび／または設定情報、およびパラメータをサーバーから取得する。前記サーバーは、いずれのアドレスがいずれのホストに割り当てられたかを追跡するデータベースを保持する。

ステートフルアドレス自動設定とステートレスアドレス自動設定の両方を同時に用いることもまた可能である。例えば、ある１個のＩＰアドレスはステートフル自動設定を用いて、他のＩＰアドレスはステートレス自動設定を用いて設定されることができ、あるいは、あるＩＰアドレスはステートレス機構に基づいて形成されてもよいが、最大転送単位（ＭＴＵ）サイズ等、他のＩＰ設定パラメータは中央サーバーによって設定されてもよい。

例えば、ＭＮはＩＰアドレスを設定するためにステートレスアドレス自動設定を用いると想定すると、異なるインタフェース識別子が生成され、元の内部ヘッダを識別および再構築するために用いられる。すなわち、考えられる新しいＩＰアドレスＭＮ_COA2は同一のプレフィクス（着信パケットの正確なルーティングにとって必要である）を有するが、元アドレスＭＮ_COAとは異なるインタフェース識別子を有する。この場合、インタフェース識別子は、図７に示されるヘッダ除去コンテクスト識別子と呼ぶことができる。ソース・アドレスの半分のみが、ヘッダ除去コンテクストＩＤとして図示される。その理由は、この例示的な実施形態では、ＭＮの新しいＩＰアドレスＭＮ_COA2のインタフェース識別子のみが、元の識別子と比較して変更されている。

一般に、ＲＯＨＣのような圧縮機構は、外部ヘッダに添付される付加的なヘッダにコンテクスト識別子を含めることによって、ヘッダ・サイズを縮小する。本発明の他の実施形態によると、ＲＯＨＣ等の機構を用い、前述したようにＲＯＨＣコンテクスト識別子をソース、及び宛先アドレスにコード化することもまた可能である。

ＭＮが配置されているサブネットが２個以上のサブネット・プレフィクスを所有するそれらの場合には、後に元の内部ヘッダを再構築するために完全な新しいＩＰアドレスを設定することも可能である。このことは、サブネット・プレフィクスならびにインタフェース識別子が、元アドレスＭＮ_COAに関して新しいアドレスＭＮ_COA2中で変更されることを意味する。この場合、該完全なＩＰアドレスがヘッダ除去コンテクスト識別子として記載でき、しかしながら、このことは、図７に示されておらず、図７は、ヘッダ除去コンテクストＩＤがインタフェース識別子であることのみを図示する。

類似の考察は、ＭＮが該ステートフルアドレス自動設定（ＤＨＣＰに基づく等）を用いてＩＰアドレスを設定する場合に適用される。

ＭＮ中の新しいＩＰアドレスの考えられる割り当てを論じた後、我々は図６に戻り、この図では、インタフェース識別子がアップリンク・ヘッダ除去（ＨＲ）コンテクストＩＤである、新しいＩＰアドレスが設定されることが図示されている。

図６には図示されないものの、ＭＮが、後の使用のために、除去されるべきヘッダについての情報および新しいＩＰアドレスＭＮ_COA2を保持することもまた必要である。引き続いてＭＮは、ＨＡに、アップリンクＨＲコンテクストＩＤおよびヘッダ、すなわち、再構築されるべきアップリンク・ヘッダおよび除去されるべきダウンリンク・ヘッダの情報を含むヘッダ除去要求メッセージを連絡する。両方のヘッダを送信することによって、ＨＡは後に、指示されたアップリンク・ヘッダを挿入することによる再構築の実行、ならびに、該指示されたダウンリンク・ヘッダがついたデータ・パケットを認識し指示されたダウンリンク・ヘッダを除去することによる除去を実行することができる。

ホーム・エージェントはＨＲ要求を受信し、自己の新しいＩＰアドレスＨＡ２を設定することを開始する。ＨＡは、ＭＮよりも新しいＩＰアドレスを生成する確率は同じなので、この時点では、この話題に関する更に詳細な議論は行わない。図６から明らかなように、ＨＡは、元アドレスＨＡのインタフェース識別子を変更することによって新しいＩＰアドレスＨＡ２を生成し、ＨＡ２は次いで、ダウンリンクＨＲコンテクストＩＤとして用いられる。

さらに、ＨＡは、ＭＮの新しいＩＰアドレスＭＮ_COA2であるとともに、とりわけＭＮ_COA2の新しいインタフェース識別子であるアップリンクＨＲコンテクストＩＤを、アップリンク・パケットからＭＮによって除去されるべき内部ヘッダと関連付けることによって、アップリンク内部ヘッダを再構築するためのコンテクストを生成する。

ＭＮは、ＨＡから受信されたデータ・パケットの中から、内部ヘッダが復旧されるべき該受信されたデータ・パケットを認識できるように、新しい割り付けられたＨＡのＩＰアドレスについて通知される必要がある。したがって、ＨＡは、ＭＮによって期待されるダウンリンクＨＲコンテクストＩＤ、すなわち新しいアドレスＨＡ２、とりわけその中の新しいインタフェース識別子を含むヘッダ除去応答を、ＭＮへと送信する。ヘッダ除去応答の受信後ただちに、ＭＮは、ダウンリンクＨＲコンテクストＩＤを、ＨＡによって除去される内部ヘッダと関連付けることによって、削除されたダウンリンク内部ヘッダを復旧するコンテクストを生成することができ、その結果、該受信されたデータ・パケットの除去されたカプセル化されたヘッダを後に再構築することができる。例えば、ＭＮは、本発明の実施形態によるヘッダ除去手順のための特定のテーブルを設定することができ、該テーブルでは、ある受信されたデータ・パケットのソース・フィールド中のある特定のＩＰアドレスが、正確なデータ・パケット構成を達成するために挿入されなければならない適切な内部ヘッダと、関連付けられている。

上記に示唆されたＨＡとＭＮの間のシグナリングに対して変形が可能であることが、当業者によって簡単に理解されるべきである。前記シグナリングによって達成されるべき重要なことは、参加するエンティティの両方が、いずれのヘッダ（単数または複数）が除去／再構築されるべきであるかを知らなければならず、除去／再構築されるべき受信されたデータ・パケットをコード化／識別する対応するアップリンク／ダウンリンクＨＲコンテクスト識別子を知らなければならず、次いでいずれの内部ヘッダが受信および識別されたデータ・パケットに挿入されるべきかを知らなければならないことである。言い換えれば、外部ヘッダ情報と内部ヘッダの間の関係について互いに連絡するための手段が端点間に存在するべきである。再構築の後は、本発明のヘッダ除去手順を適用しなければ、受信されたデータ・パケットに差はないはずである。

一見したところ、様々な方法でシグナリングが行われうる。例えば、ＭＮがシグナリング手順を開始する代わりに、ＨＡが、いずれのヘッダが除去されるべきかを決定するのを開始し、新しいアドレスを割り当て、ヘッダ除去要求をＭＮへと送信してもよい。こうして、図６に例示されたシグナリング手順が反対に向きに実行される。

さらに、アップリンクおよびダウンリンク中でなく、アップリンクまたはダウンリンク中にのみに除去されるべきヘッダについてＭＮが決定しないことがありうる。次いで、ＨＡは、ダウンリンクまたはアップリンクから除去されるべきヘッダを決定し、ひいては、決定についてＭＮに連絡するであろう。当業技術を有する読者には、シグナリング手順の他の実施形態が同様に提示される残りの記載事項から、他の代替例も明らかになるであろう。

図６に例示されるようなシグナリング手順の結果として、ＨＡおよびＭＮは今や本発明の実施形態によるヘッダ除去を実行することができる。より具体的には、ＣＮ１０１からのダウンリンク・データ・パケットがＨＡ１１１に到達すると、ＨＡは、具体的なヘッダ構造によって、データ・パケットを、本発明の実施形態によるヘッダ除去が適用されたデータ・パケットとして認識する。したがって、ＨＡは、その目的のために特に割り付けられたＩＰアドレス（図５中、ＨＡ２）を、外部ヘッダのソース・アドレスへと挿入し、データ・パケット構造から内部ヘッダ（単数または複数）を除去する。変更されたデータ・パケットは今や、１個のヘッダとペイロードのみから成り、ＭＮへと転送される。ＭＮは今度は、前記変更されたデータ・パケットをＨＡから受信し、ソース・アドレス（図５中：ＨＡ２）を手段として用いて、該データ・パケットを、本発明の実施形態によるヘッダ除去を経験したデータ・パケットとして認識する。したがって、ＭＮは、再構築が実行されなければならないことを知っており、該ソース・アドレスに対する参照作業を実行する。ただし、図６のシグナリング手順の開始時にダウンリンク内部ヘッダを再構築するためにコンテクストが生成されたならば、ＭＮは前記コンテクストをソース・アドレス（ＨＡ２）によって固有に識別することができ、ＭＮは今や、適切な内部ヘッダを受信されたデータ・パケットへと挿入し、外部ヘッダを元のソース・アドレスＨＡと適合させることができる。こうしてＭＮは結局のところ、あたかもヘッダ除去が全く適用されなかったかのように、同一のデータ・パケットを取得し、さらに受信されたデータ・パケットを通常どおり処理することができる。

反対に、ＭＮからＨＡへと送信されるべきデータ・パケットは、サイズもまた同様に縮小されるべきである。ＭＮは内部ヘッダを認識することによって、ある特定のデータ・パケットが、本発明の実施形態によるヘッダ除去を受けなければならないデータ・パケットに属することを決定する。次いで、外部ヘッダのソース・アドレスは、前に設定されたＭＮの新しいＩＰアドレスＭＮ_COA2へと変更され、内部ヘッダは完全に削除される。その後すぐに、データ・パケットはＨＡへと送信され、ＨＡはデータ・パケットを受信し、（外部）ヘッダのソース・アドレス・フィールド中のアドレス（ＭＮ_COA2）を手段として用いて、そのヘッダ連結が復旧される必要があるデータ・パケットとして、それを認識する。これに対応して、正確なカプセル化されたヘッダが参照され、次いで受信されたパケットへと挿入される。さらに、とりわけソース・アドレス中の外部ヘッダが、初期に提供された外部ヘッダと類似するよう構成される、すなわち、ソース・アドレス・フィールド中のアドレスＭＮ_COA2が、ＭＮの元アドレスＭＮ_COAによって置換される。このようにして再構築されたデータ・パケットは、次いで本発明の実施の前と同じように処理されることができる。

本発明のヘッダ除去手順を停止するためには、両方エンティティに対して、さらなるヘッダ除去または再構築が何ら実行されないことを連絡すれば十分である。このことは、２個の参加するエンティティのうち一方によって、または、とりわけヘッダ除去を開始したエンティティによって行われうるが、それらには限定されない。ヘッダ除去手順の差し迫った停止を知っているかまたは該停止について通知される任意のエンティティが、順次参加するエンティティに通知することができる。次いで、エンティティは、データ・パケットを除去および／または再構築するのを中止する。

その中のデータ・パケットから除去されるべきカプセル化されたヘッダをコード化するのに、ソースＩＰアドレスを用いる一利点は、送信者が、ソースインタフェースを、ヘッダ除去のために用いられるすべてのＩＰアドレスで、設定する必要がないことである。その理由は、送信者が、このアドレスを宛先アドレスとして付けたパケットを必ずしも受信しないからである。データ・パケットのソース・アドレス・フィールド中のＨＲコンテクストＩＤをコード化する一欠点は、両方の端点が複数のＩＰアドレスを割り当てることができなければならないことである。

しかしながら、いくつかのヘッダ除去セッションのために新たに設定されたＩＰアドレスを再使用することが可能であり、すなわち、開始される新しいヘッダ除去手順それぞれに対して常に新しいＩＰアドレスを設定することは必要でない。例えば、ＭＮとＨＡの間の通信経路上の第１のＨＲセッションについて、新しいＩＰアドレスＨＡ２とＭＮ_COA2は、ＨＡおよびＭＮによってそれぞれ設定され、内部ヘッダの少なくとも一部が除去されるべきデータ・パケット中のソース・アドレスとして用いられることが想定される。結局のところ、第２のＨＲセッションが、他のＭＮ２とＨＡの間の通信経路上で開始される。前記場合において、以前に設定された新しいＩＰアドレスＨＡ２もまた、他のＭＮ２に送信されたデータ・パケットのソース・アドレスとして用いられうる。明らかに、ソース・アドレスとしてＨＡ２がついたデータ・パケットの受信後ただちに、他のＭＮ２は、前記パケットを認識し、ヘッダ除去開始手順中に最初に保存されたコンテクストから、元のヘッダ連結を復旧することができる。

反対に、ＭＮもまた、他のＨＲセッションのために自己のＩＰアドレスＭＮ_COA2を、他のホーム・エージェント（ＭＮが２個以上のホーム・エージェントを有する場合には）とともに、再使用しうる。

本発明の別の実施形態では、図８に図示されるように、１個のアドレス、ここでは、ＨＡのＩＰアドレスが、両方向において内部ヘッダを識別するのに用いられる。これは、アクセス・ネットワーク内の限定されたＩＰアドレス空間等を理由とする。ここでは、ＵＥはしたがって付加的なＩＰアドレスを割り当てることができない。図６に提示されたシグナリング処理と同様に、ＭＮはおそらくは最初に、アップリンクおよびダウンリンク・フローの除去されるべきヘッダ（単数または複数）を決定する。次いで、ヘッダ除去要求が、再構築されるべきアップリンク・ヘッダおよび除去されるべきダウンリンク・ヘッダの情報とともにＨＡへと送信される。

ヘッダ除去要求は、どのようにヘッダ除去手順が厳密に実行されるべきかを受信側エンティティが演繹できるパラメータおよび／またはオプション（選択肢）をさらに含みうる。例えば、ＨＲ要求中に含まれるべき情報は、内部ヘッダ（単数または複数）が再構築されなければならないパケットを受信することを認識し、除去されるべき内部ヘッダをコード化するために、外部ヘッダ中のいずれのアドレス・フィールドが用いられるかを指すことができる。このことは代替的には、ヘッダ除去のいずれの変形が用いられるかを「ネゴシエーションする」ための付加的なシグナリングを伴いうる。また、本発明の特定の変形を示すいくつかのまたはすべてのパラメータが、参加するエンティティのうち一つが配置されているネットワークの事業者によって設定されうる。

再び図８を参照すると、ＨＲ要求がＨＡ内に受信された後ただちに、ダウンリンクおよびアップリンク・フローに対して、新しいＩＰアドレスが割り当てられ、例えば、同一のサブネット・プレフィクスを元アドレスとして保持しながら、新しいインタフェース識別子が生成される。本発明の本実施形態によると、前記インタフェース識別子は、アップリンクおよびダウンリンクＨＲコンテクストの両方に対応する。

図８のシグナリング図中に描写されていないものの、ＨＡは、アップリンクＨＲコンテクストＩＤと、ＭＮによって各アップリンク・データ・パケットから除去されるアップリンク内部ヘッダとの間のマッピングを、提供するする必要がある。前記観点において、アップリンク内部ヘッダを再構築するための情報を含むコンテクストがＨＡ内に提供され、ＨＡ内の前記コンテクストは、アップリンクＨＲコンテクストＩＤによって固有に指示される。

ＨＡは、新しいＩＰアドレスであるかもしくはとりわけ新しいインタフェース識別子であるＨＲコンテクストＩＤがついたヘッダ除去応答を、ＵＥへと送信する。ＨＡ内のマッピングと同様に、再構築を実行できるようにするべく、ＭＮは、ＨＲコンテクストＩＤと、ＨＡによって各ダウンリンク・データ・パケットから除去されたダウンリンク内部ヘッダとの間の関連付けもまた必要とする。これに対応してＭＮは、不完全なヘッダ連結、この場合わずか１個の外部ヘッダを元の完全なヘッダ連結へと変換するのを許可するコンテクストを保持する。

ＨＲ応答の受信後に、ＵＥおよびＨＡは内部ヘッダを除去することを開始できる。ＵＥは、適切な宛先アドレスＨＡ２がついたデータ・パケットを、ホーム・エージェントへと送信し、ホーム・エージェントは、適切なソース・アドレスＨＡ２がついたデータ・パケットを、ＵＥへと送信する。他の端点は、ソース／宛先アドレス中のＨＲコンテクストＩＤに基づいて、データ・パケットを認識し、ＨＲコンテクストＩＤでタグ付けされたコンテクストを用いて、記憶装置に保存されている内部ヘッダを挿入することによって、ヘッダを再構築できる。

図９は、ホーム・エージェントの新しいアドレスＨＡ２の使用を、データ・パケット中の唯一の指標／コード化情報として図示する。見てわかるように、ダウンリンク・データ・パケットのソース・アドレス・フィールドおよびアップリンク・データ・パケットの宛先アドレス・フィールド中のホーム・エージェントの元アドレスＨＡは、ヘッダ除去中に新しいアドレスＨＡ２によって置換される。

したがって、コンテクストＩＤをコード化するためのソースＩＰアドレスの使用を宛先ＩＰアドレスの使用と比較すると、その結果、両方は利点および欠点を有し、以下の表に要約される。以下の表は、ヘッダ除去がＵＥとＨＡの間の通信経路上に適用されるときのシナリオに対して説明される。

表１：本発明の異なる実施形態による内部ヘッダ識別のための宛先ＩＰアドレスに対するソースの使用を比較する

図６または８に示されるハイ・レベルシグナリング手順では、常にヘッダ情報全体がヘッダ除去要求内で転送されることが想定される。ヘッダ除去要求とともに送信されるべきデータの量を縮小するためには、完全なアップリンクおよびダウンリンク・ヘッダを送信する代わり、真のアップリンクおよびダウンリンク・ヘッダを演繹しうるハッシュ値を送信することが示唆される。より具体的には、ＭＮが、アップリンクおよびダウンリンク・データ・パケットからいずれのヘッダが除去されるべきかを決定した後に、ＭＮは、内部ヘッダ、または、完全な内部ヘッダから特定のフィールド（ソースおよび宛先ＩＰアドレス等）を選択し、特別なハッシュ関数を実行することによって、その中からハッシュ値（アップリンク用に１個およびダウンリンク用に１個）を生成する。

それゆえに、アップリンクおよびダウンリンクの内部ヘッダをＨＡへと指示するためには、ハッシュ値を計算するのにいずれのヘッダ部分が用いられたかについての情報、および、該特定のハッシュ関数自体についての情報と一緒に、該２個のハッシュ値を送信すれば十分である。当然、当業者は、ハッシュ値を計算するのに用いられるヘッダ・フィールドおよび特定のハッシュ関数もまた、あらかじめ合意することができ、その結果、ハッシュ値のみを送信することが必要であり、しかし、ハッシュ関数またはヘッダ・フィールドについての情報は何ら必要ないことを知っている。

それ故に、本発明の本実施形態によるヘッダ除去要求は、２個のハッシュ値、ＭＮの該設定された新しいアドレス、および、随意的には計算に用いられた特定のハッシュ関数およびヘッダ・フィールドについての情報から成る。

ＨＡが前記ヘッダ除去要求メッセージを受信する時、ＨＡは、ＵＥにおいてすでに用いられた特定のハッシュ関数を、アップリンクおよびダウンリンク・フロー中のデータ・パケットの該合意または指示されたヘッダ・フィールドに対して実行できる。ダウンリンクおよびアップリンク・データ・パケットに対して計算されたハッシュ値は、ヘッダ除去要求中の受信されたハッシュ値に対して、ＨＡ内で照合される。これによって、ＭＮによって除去／再構築されるべきと決定されたヘッダは、結局のところＨＡ内で識別される。したがって、アップリンク内部ヘッダを再構築するためのコンテクストがＨＡ内で確立され、該コンテクストは、アップリンクＨＲコンテクストＩＤと関連付けられており、該アップリンクＨＲコンテクストＩＤは、アップリンク・データ・パケットが自己のソース・アドレス・フィールド中の新しいＩＰアドレスを有する場合には、ＭＮの新しいＩＰアドレス等でありうる。

それゆえにＨＡは、ヘッダが内部に再構築されるべきであるアップリンク・データ・パケットと、ヘッダが除去されるべきダウンリンク・データ・パケットを認識できる。用いられた本発明の特定の実施形態に依存して、ＨＡは、新しいＩＰアドレスを設定する必要がありうるが、該ＩＰアドレスは次いでＨＲ応答メッセージ中でＭＮへとシグナリングされる。

これによって達成される主な利点は、完全な内部ヘッダではなく、最良の場合でも２個のハッシュ値のみが送信されるので、ヘッダ除去要求メッセージは、サイズにおいてより小さいことである。しかしながら、ＨＡが正確なデータ・パケットを識別するためには、多数のハッシュ値が計算されなければならない可能性があるが、これは処理負荷を増加させる。この課題を緩和するために、ＨＡが、すべての受信されたデータ・パケットに対して多すぎるハッシュ値を計算する必要がないよう、付加情報（宛先アドレス等）の信号を送ることが可能である。受信されたデータ・パケットを、ＨＲ要求メッセージ中に指示された特定の宛先アドレス等がついたパケットのみに限定することによって、処理負荷を大幅に縮小することができる。

本発明の他の実施形態によるシグナリング手順をさらに最適化することが可能である。とりわけ、これまでのところは、ヘッダ除去セッションのためにＩＰアドレスを生成するのに用いられる機構には、特別な要件は全くない。しかしながら、ＵＥおよび／または他のＨＡが任意のインタフェース識別子（ヘッダ除去コンテクストＩＤ）を生成することが可能であるならば、例えば、ノードあたりのプレフィクスが通告される場合、次いでシグナリング手順をさらに最適化することができる。前記場合において、ＵＥは、上記に論じられたようなアップリンクおよびダウンリンク・パケットの関連ヘッダ・フィールドに関するハッシュ値を計算することができ、このハッシュ値は、ＭＮおよび／またはＨＡのＩＰアドレスのためのインタフェース識別子として、用いられうる。

より詳細に図１０を参照すると、ハッシュ値は、ＵＥによって以前に決定されたアップリンクおよびダウンリンク・ヘッダの一部（またはすべて）に基づいて計算される。アップリンク・ハッシュ値は次いで、ＭＮによってインタフェース識別子として、自己の新しいアドレスを設定するのに用いられる。ヘッダ除去コンテクストＩＤは、両方向において、それぞれのハッシュ値であるインタフェース識別子である。ＵＥは、ダウンリンク・ヘッダを復旧するための、ダウンリンクＨＲコンテクストＩＤ（インタフェース識別子＝ダウンリンク・ハッシュ値）によって固有に識別されるコンテクスト情報を生成するのに即座に使用可能になる。その理由は、ダウンリンクＨＲコンテクストＩＤがＨＡによって用いられて、ダウンリンク・データ・パケットの内部ヘッダをコード化することを、ＵＥはすでに知っているからである。

アップリンクおよびダウンリンクＨＲコンテクストＩＤ（アップリンクおよびダウンリンク・ハッシュ）、および随意的にハッシュ値の計算に用いられた特定のハッシュ関数およびヘッダ・フィールドの情報を含むＨＲ要求メッセージが、ＨＡへと送信される。さらに随意的にＨＲ要求は、計算が実行されなければならないデータ・パケットの量を縮小するための付加的な識別情報を含んでもよい。

これに対応して、ＨＡがＨＲ要求メッセージを受信する時は、ＨＡは、メッセージ中に含まれるダウンリンク・ハッシュ値を用いて、新しいＩＰアドレスを生成できる。ＨＡはまた、ヘッダ除去が適用される際に、これによって、ＭＮによってアップリンク・データ・パケットがコード化されるＩＰアドレスもまた知っている。ＨＡが設定する新しいＩＰアドレス、とりわけ、ダウンリンクＨＲコンテクストＩＤ（ダウンリンク・ハッシュ値であるインタフェース識別子が）を、ＭＮはすでに知っているので、ＨＲ応答メッセージの必要はない。

本実施形態は、ＨＲ要求メッセージはサイズにおいてさらに縮小されており、今や、アップリンクおよびダウンリンクＨＲコンテクストＩＤである２個のハッシュ値のみを最適に含むので有利である。図１０中のヘッダ・フィールド・ポインタは、前述したようにＨＡがいずれのフィールドが計算を実行するのに用いられるかを知っている場合には、まさに随意的である。また、ＭＮはダウンリンクＨＲコンテクストＩＤをすでに知っているので、何の応答メッセージももはや必要でない。

ＭＮの新しいＩＰアドレスのための、または、後のＨＡのための重複アドレス検出（ＤＡＤ）が失敗した場合、ＵＥは、異なるハッシュ関数またはハッシュ・キーを用いて新しいインタフェース識別子を計算することができ、この情報を再びＨＡへと信号を送ることができる。代替的には、ＨＡの新しいＩＰアドレスのためのＤＡＤが否定的である場合には、ＨＡは、任意に新しいＩＰアドレスを設定し、通常どおりのＨＲ応答メッセージがついた新しいＩＰアドレスを、ＵＥに連絡してもよい。

これまでに論じられた本発明によるヘッダ除去は内部ＩＰヘッダのみに限定されないことに留意するべきである。大抵は一定のフィールド（ＵＤＰヘッダ等）を有する他の内部ヘッダがある場合、前にすでに図示されたステップと同じステップを適用することによって、これらもまた同様に、簡単に除去および再構築することができる。

本発明によるヘッダ除去によると、元の内部ヘッダを再構築するためのコンテクストは、宛先アドレスであれまたはソース・アドレスであれ、外部ヘッダＩＰアドレスによって識別される。こうして、ＵＥがモバイルであり、自己のＬ３リンクを変更する場合、外部ヘッダ・アップリンク・ソースＩＰアドレスおよび外部ヘッダ・ダウンリンク宛先ＩＰアドレスもまたそれぞれ変化する。したがってＵＥは、他のトンネル端点、この場合、新しいＩＰアドレスがついたＨＡを更新しなければならない。ＵＥが（他のトンネル端点のＩＰアドレスの代わりに）自己のＩＰアドレスを用いて内部ヘッダを識別する場合、いくつかのヘッダ除去セッションがある場合、ＵＥは、ヘッダ除去要求またはヘッダ除去更新メッセージを再び用いることによって等、多くのＩＰアドレスに対する更新を同時に送信しなければならないかもしれない。より詳細には、ＵＥは、ダウンリンクおよび／またはアップリンクＨＲコンテクストＩＤとして使用されている複数の新しいＩＰアドレスを設定しなければならない。ＨＡ内での以前のアドレスとの関連付けを代用するためには、複数のヘッダ除去セッションに対して、ＵＥの新しいＨＲコンテクストＩＤおよび対応する内部ヘッダをそれぞれ含む複数のメッセージを送信することが必要である。

多くの更新メッセージの同時の送信を回避する一つの可能性は、大量のヘッダ除去要求／更新手順を用いることであり、該手順では、ＵＥは、いくつかのＩＰアドレス（ＨＲコンテクスト識別子）および合致する内部ヘッダ情報を含んでいる。

内部ヘッダを除去し、関連した情報を外部ヘッダ（ソース・アドレス等）へとコード化することによる一課題は、ＩＰｖ６ヘッダのホップ・リミットまたはフロー・ラベル・フィールド等、内部ヘッダのいくつかのフィールドが、パケットごとにと変化しうることである。それゆえに、再構築のためのコンテクスト情報が、データ・パケットごとに、変化するフィールド中の新しい値で更新されないならば、内部ヘッダのコンテンツは、その中で値が変化することを理由に正確に復旧できない。

しかしながら、例えば、ホップ・リミット・フィールドの目的はパケット寿命を制限することであり、ひいては、ホップ・リミット・フィールド中の変化は、ラスト・ホップではおそらく無視することができる、すなわち、ＵＥはホップ・リミット値の変化を知らない。とりわけ、値の変化は受信側エンティティ、ここではＵＥによって注目されることはない。その理由は、内部ヘッダは、ヘッダ除去手順を開始する時の初期値を指す情報から復旧されるからである。しかしながら、値の変化は、ＵＥの動作に否定的に影響しない。

本発明の他の実施形態によると、フロー・ラベルおよびトラフィック・クラス・フィールドのような他の変化するフィールドは、値を外部ヘッダ中の適切なフィールドへと複写し、次いで、受信側にて再構築のために複写して戻すことによって、簡単に取り扱われうる。当然これは、外部ヘッダの対応するフィールド（単数または複数）が空であるか、または、値が無関係である場合等何ら問題を引き起こさずに上書きされることができる場合にのみ可能である。外部ヘッダの対応するフィールド中の値が一定である場合における他の可能性は、受信側エンティティ内にあるコンテクスト中に、上書きされる外部ヘッダ中の対応するフィールドのコンテンツを再構築する情報を、残存する内部ヘッダとともに含むことである。例えば、まず最初に、コンテクスト情報が、変化するフィールドを除いて、内部ヘッダを再構築するのに用いられる。次いで、外部ヘッダ中の対応するフィールドの値は、内部ヘッダ中の同一のフィールドへと複写される。最後に、外部ヘッダ中の対応するフィールドを正確な値で再構築するのに、コンテクスト情報が再び用いられ、これによって、あたかも何のヘッダ除去も適用されなかったかのように、同一のヘッダ連結に到達する。

変化するフィールドに対処するための他の単純な方法は、パケットを高頻度に変化するフィールドで識別し、ヘッダ除去をそれらトンネリングされたパケットへと適用しないことである。すなわち、高頻度に変化するフィールド値がついたデータ・パケットは、ヘッダ除去がつかないパケットのようにトンネリングされる。例えば、変化するフィールドの最も頻度の高い値が、ヘッダ除去が適用される前および／または途中に決定され、最も頻度の高い値がついたヘッダのみが除去される。すなわち、変化するフィールド中に最も頻度の高い値とは異なる値を有するすべての他のパケットが、本発明のヘッダ除去手順を適用することがなくてもトンネリングされる。

それにもかかわらず、除去されるべき内部ヘッダの所定のフィールド中の変化する値とは独立して、常に内部ヘッダを除去することが望ましい。さらに、内部ヘッダのすべてのフィールドが正確に再構築されなければならないことが必要かもしれず、外部フィールドは異なる目的（ＱｏＳハンドリング等）のために必要なため、占有されているので、該外部フィールドを用いることができないこともまた起こりうる。次いで、内部のフィールドは、適切な外部フィールドへと複写できない。

本発明の他の実施形態に関して、変化するフィールドごとに、すなわち、除去される様々な内部ヘッダごとに別々に、ヘッダ除去を実行することが可能である。とりわけ、ホップ・リミット・フィールド、フロー・ラベル、トラフィック・クラスもまた、図１１中に描写されるように、外部ＩＰアドレスのインタフェース識別子へとコード化される。次いで、例えば、内部ＩＰソース・アドレス−ＩＰ宛先アドレスの一対に対し、異なるホップ・リミット値が発生しうる場合は、異なるホップ・リミット値を含む内部ヘッダをコード化するためには、異なるホップ・リミット値ごとに、（図５に関して論じられるように、ソース・アドレスが用いられる場合には）異なる外部ＩＰソース・アドレスが必要である。

しかしながら、このコード化の形態は、トンネル端点のインタフェース上で設定することができる利用可能なＩＰアドレスの数の制限と矛盾しうる。また、新しい割り付けられたＩＰアドレスごとに重複アドレス検出（ＤＡＤ）が必要である場合は、多くの遅延およびシグナリング・オーバーヘッドが付加される。ＤＡＤの課題を克服するための一つの可能性は、１個のノードごとにＩＰプレフィクスをＵＥへと割り当てることであり、次いで、ＵＥは任意のインタフェース識別子を設定することができ、ＤＡＤを実行する必要がない。

ＩＰヘッダ中のアドレス消耗および変化するフィールドに対処する他の可能性は、本発明の以下の実施形態による融合的なアプローチを用いることである。このことは、ダウンリンク・パケット（すなわちＨＡからＵＥへと）の場合、送信されるべきパケットの宛先ＩＰアドレス（ＵＥのＩＰアドレス等）は、内部ヘッダの静的なフィールド（バージョンフィールド、ネクスト・ヘッダ・フィールド、ソースＩＰアドレス、宛先ＩＰアドレス等）のことを指し、トンネル端点のソースＩＰアドレス（ＨＡのＩＰアドレス等）は、変化するフィールドの値（ホップ・リミット等）のことを指すことを意味する。このことは、図１２中に図示され、該図は、ホップ・リミット値が１個のデータ・パケットから他へと変化し、ダウンリンク・データ・パケットのソース・アドレスＨＡ２へとコード化されることが想定される外部ＩＰｖ６ヘッダを例示的に描写する。ＨＡによって除去されるべき内部ヘッダの静的部は、移動ノードの新しいアドレスＭＮ_COA2でコード化され、該アドレスは、宛先アドレスとしてダウンリンク・データ・パケット中に挿入される。

反対に、アップリンク・パケットのための外部ヘッダ・コンテンツが図１３に示される。すなわち、アップリンク・データ・パケット（すなわちＵＥからＨＡへと）に対しては、送信されるパケットのソースＩＰアドレスＭＮ_COA2（ＵＥのＩＰアドレス等）は、内部ヘッダの静的なフィールド（バージョンフィールド、ネクスト・ヘッダ・フィールド、ソースＩＰアドレス、宛先ＩＰアドレス等）のことを言い、対応するダウンリンク・パケットに用いられるＩＰアドレスと同じでありうる。トンネル端点の宛先ＩＰアドレス（ＨＡのＩＰアドレスＨＡ等）は、変化するフィールドの値（ホップ・リミット等）のことを指してもよい。融合的なアプローチを適用する場合のヘッダ・パケット・フォーマットは図１４中に描写される。

このアプローチの利点は、フローを識別するためには、ＵＥ側には１個の新しいＩＰアドレスのみが必要であることである。これに反して、他のトンネル端点（ＨＡ等）は、変化するフィールドに対処するために、多数のＩＰアドレスを割り当てる必要がある。しかしこれらＩＰアドレスは、すでに説明されたように、他のＵＥへとトンネリングするため等に再び用いることができる。

本発明の他の実施形態によると、ＭＮが無線ローカル・ネットワーク・エリアに配置されており、ＷＬＡＮが３ＧＰＰシステムと相互に作用する。相互に作用する３ＧＰＰ-ＷＬＡＮは、以下においてＩ−ＷＬＡＮと呼ばれる。無線ネットワーク内では、限定された帯域幅のみがその中で利用可能なので、データ・トラフィックを縮小することがとりわけ重要である。それにもかかわらず、当業者によって簡単に理解されうるように、ネットワーク・アーキテクチャ内で、後続のＷＬＡＮシナリオとは異なる本発明の様々な実施形態の原理を実施することもまた可能である。３ＧＰＰアクセス（ＧＥＲＡＮ、ＵＴＲＡＮ、Ｅ−ＵＴＲＡＮ等）、非３ＧＰＰアクセス（ＷＬＡＮ、ＷｉＭＡＸ、３ＧＰＰ２、等）および、それらの間のモビリティのサポートがますます重要になりつつある。

図１５は、３ＧＰＰ−ＷＬＡＮアーキテクチャの簡略化した概観を描写し、ここでは、３ＧＰＰおよび非３ＧＰＰアクセスの間のモビリティのためのアンカーはゲートウェイであり、該ゲートウェイは、外部パケット・データ・ネットワーク（ＰＤＮ）へのインタフェースもまたを提供し、ＰＤＮ−ＧＷと呼ばれる。３ＧＰＰおよび非３ＧＰＰアクセスの間のモビリティはモバイルＩＰに基づいており、これによって、用いられるプロトコルはクライアント・モバイルＩＰまたはプロキシ・モバイルＩＰのいずれかであることができる。非３ＧＰＰアクセスは、信頼されたアクセスと信頼されていないアクセスとに分けられる。信頼されていないアクセスでは、信頼されていないアクセス中のＵＥは事業者サービスにアクセスできる前に、進化したパケット・データ・ゲートウェイ（ｅＰＤＧ）への安全なトンネル（ＩＰｓｅｃに基づく等）を最初に必要とすることが想定される。ｅＰＤＧは、相互に作用するＷＬＡＮに用いられるＰＤＧに類似しており、これに反して、この安全なトンネルは、信頼されたアクセスからは必要とされていない。非３ＧＰＰアクセスが信頼されるか否かは事業者の決定であり、事業者ごとに異なってもよい。

加えて、ＷＬＡＮは、ＷＬＡＮアクセス・ポイントおよび中間ＡＡＡ（認証、許可およびアカウンティング）要素を含む。ＷＬＡＮは、ルータといった他のデバイスをさらに含んでもよい。ＭＮを可能なＷＬＡＮは、コンピュータ、ＷＬＡＮ無線インタフェース・アダプタ等といった、エンド・ユーザが所有するすべての装置を備える。Ｉ−ＷＬＡＮでは、ＷＬＡＮに接続されたＭＮは、直接的にインターネット（直接的ＩＰアクセスと呼ばれる）とアクセスするか、または、自己の３ＧＰＰ事業者に接続して事業者サービスを用いるかのいずれでもよい。事業者は通常はＭＮのトラフィックの制御を保ちたいので、ＭＮが３ＧＰＰ事業者を介して、すなわちｅＰＤＧを介して、データ・サービスにアクセスすることは普通である。

移動ノードがＷＬＡＮに接続する場合、ＭＮは、ＷＬＡＮネットワーク中にローカルＩＰアドレス（ＭＮ_LA）を設定する。ＭＮが、ＷＬＡＮ内でＭＩＰｖ６プロトコルを用いることがさらに想定されており、このことは、ＨＡがＷＬＡＮ内に提供されていることを意味する。次いでＭＮ_LAは、コレスポンデント・ノードとの通信には用いられず、むしろ、これはＭＮがｎ３Ｇ−ＨＡと自己との間のＷＬＡＮネットワーク中にのみ用いるアドレスであり、ＭＮ_LAは、データ・パケットをＷＬＡＮ内のＭＮへと転送するのにｎ３Ｇ−ＨＡによって用いられる。それ故に、ＭＮは非３ＧＰＰホーム・アドレスをｅＰＤＧとの通信のために用いる。すなわち、ＭＮとｅＰＤＧの間のＩＰｓｅｃトンネルが設定されたｎ３Ｇ−ＨｏＡを用いることによって確立される。

ＭＮがｅＰＤＧとのＩＰｓｅｃトンネル（セキュリティ・アソシエーション等）を確立すると、ＭＮはｅＰＤＧから遠隔のＩＰアドレスを受信する。ＭＮが３Ｇ−ＨＡと通信する場合、前記遠隔のＩＰアドレス（ＲＡ）がＭＮの新しいＣｏＡとして用いられる。その後、ＭＮはＭＩＰ手順を実行して、ＣｏＡ（ＰＤＧのネットワークからの遠隔のＩＰアドレス）を自己の３Ｇ−ＨＡに登録する必要がある。これを行う場合にのみ、ＭＮは、ＷＬＡＮネットワークへのハンドオーバーの前に、３ＧＰＰネットワーク中のサービスを開始するために用いられてきた自己の元のホームＩＰアドレスを継続して用いることができる。

この接続シナリオは図１５に図示される。ＷＬＡＮアクセス・ネットワーク内において、モバイルＩＰはローカルモビリティのために用いられ、こうして、ＵＥとＷＬＡＮアクセス・ネットワーク内の自己のホーム・エージェント（ｎ３Ｇ−ＨＡ）の間にはＩＰ−ｉｎ−ＩＰトンネルがある。さらに、ｅＰＤＧには安全なトンネルが必要であり、結果としてＵＥとｅＰＤＧとの間のＩＰｓｅｃトンネルをもたらす。次いで、３ＧＰＰと非３ＧＰＰアクセスの間のモビリティのためのクライアント・モバイルＩＰの使用によって、ＵＥとＰＤＮ−ＧＷ（３Ｇ−ＨＡ）の間には、３ＧＰＰネットワーク中のホーム・エージェントとして機能する他のＩＰ−ｉｎ−ＩＰトンネルがある。ＰＤＮ−ＧＷによって割り付けられたＩＰアドレスによって、ＵＥから送信されるかまたはＵＥによって受信されたＩＰパケットは、無線リンク上に４個のＩＰヘッダをもたらすと思われ、これは図１６で理解されることができる。とりわけ、付加的なヘッダ３×４０バイト＝１２０バイトに上る３個の内部ヘッダがある。とりわけＩＭＳ ＶｏＩＰサービス等の場合には、実際の音声データ・ペイロードは通常小さいので、莫大量のオーバーヘッドが付加される。

ＩＰｓｅｃトンネル・ヘッダもまたカプセル化セキュリティ・ペイロード（ＥＳＰ）等として付加的なセキュリティ情報を含むならば、内部ヘッダ内のバイトの量はさらに高いかもしれない。再び図１６を参照すると、元のデータ・パケットは、ＭＮのホーム・アドレス（ｎ３Ｇ−ＨｏＡ）を宛先アドレスとして、ｅＰＤＧのアドレスをソース・アドレスとして備え、対応するオプションフィールド中にカプセル化セキュリティ・ペイロード（ＥＳＰ、長さ８バイト；図示しない）を含むＩＰｓｅｃヘッダによってカプセル化される。新しいカプセル化されたパケット、すなわち元のデータ・パケットのペイロードは、暗号化されてもよい。さらにＥＳＰは、データ・パケットの発生元認証、完全性および機密性を提供し、一方、ＩＰｓｅｃトンネルによって付加されたパケット・オーバーヘッドは合計４８バイトになる。

当業者は、上記に提示された発明のすべての実施形態は、図１６に提示されたシナリオにも適用可能であることを理解するであろう。本発明の原理は当該特定のシナリオに簡単に適合しうる。また、本発明の以下の実施形態は３ＧＰＰ−ＷＬＡＮアーキテクチャに限定されるものの、ＭＮのネットワーク中の他のアクセス技術が可能であり、本発明の機構も同じくそれに適切に適用されうる。例えば、ＭＮとＣＮの両方が、同一の種類のネットワークに接続されてもよく、該ネットワークは３ＧＰＰネットワークであってもよい。可能な他のアクセス技術は例えばＷｉＭＡＸ（マイクロ波アクセスの世界的相互運用性）である。

図１７および図１８には、ｎ３Ｇ−ＨＡがヘッダ除去を実行する本発明の一実施形態が図示され、ここでは、データ・パケットのソース・アドレスが、ヘッダ除去が適用されるデータ・パケットをコード化／認識するのに用いられる。図１８から、当業者は、各データ・パケットのサイズは、本発明の実施形態を実行した後に、１２８バイト（１６８バイト−４０バイト）縮小されることに気が付くであろう。

この例では、除去される３個の内部ヘッダ中には変化するフィールド（単数または複数）が全く存在しないことが想定される。しかしながら、当業者は、図１６のこのシナリオ中の変化するフィールドに対処するためにも同様に、前に論じられてきた変化するフィールドに関する原理を実施できる。

ＭＮとそのＨＡとの間で様々な実施形態を実行することは図示目的のための単なる例にすぎないことに留意するべきである。本発明はしかしながら、それに限定されない。本発明を、ＭＮと、ｅＰＤＧまたはＰＤＮ−ＧＷのような他のネットワーク・エンティティとの間の通信経路上で実施することもまた可能である。加えて、ｅＰＤＧおよび３Ｇ−ＨＡ等のような２個のネットワーク・エンティティの間のヘッダ除去セッションも、両方のエンティティが本発明の様々な実施形態を実行するための適切な手段を含む限り、同様に実行可能である。

これまでのところ図６、８および１０に、単純なハイ・レベルシグナリング手順が記載されており、シグナリングはＵＥとＨＡの間にある。しかしながら、ヘッダ除去に関連したシグナリングのための別々のプロトコルが必要とされないことに言及されるべきである。シグナリングもまた、既存のプロトコル（トンネル設定／修正のため等）にも基づくことができる。これによって達成される一利点は、標準的な手順（すなわちＭＩＰｖ６、ＭＯＢＩＫＥ等）を実行するための対応する機能性は、標準によって通常のネットワーク・エンティティ中に構成されると想定されるので、エンティティは修正される必要がないことである。

ヘッダ除去情報を交換するために拡張することができる考えられる一つのプロトコルは、ＩＫＥｖ２プロトコルである。ここでは、ヘッダ除去を実行するための情報は、例えば、構成ペイロードフィールド中に、または、ＣＲＥＡＴＥ＿ＣＨＩＬＤ＿ＳＡ中ないし付加情報交換中の付加的な通知フィールドとともに、移送されうる。

ヘッダ除去によって外部ヘッダのＩＰアドレスが元のトンネルパケットとどう変化したか比較し、そしてそれぞれのトンネル除去セッションごとに新たなＩＫＥｖ２の構築を必要とするかもしれない。そのため、ＭＯＢＩＫＥのようなＩＫＥｖ２変形が用いられる。ＭＯＢＩＫＥによって、ＩＰｓeｃ ＳＡとして用いられるＩＰアドレスを変更することが可能である。さらに、今や外部ヘッダ、すなわち外部ヘッダＩＰアドレスは、内部ヘッダをおよび適切なセキュリティ・アソシエーションをも再構築するための適切なコンテクストを固有に識別し、ひいては、ＥＳＰヘッダ中のセキュリティ・パラメータ指数（ＳＰＩ）はさらに省略することができる。この場合、セキュリティ・アソシエーション・データベース（ＳＡＤ）およびＩＰｓｅｃ処理は、外部ヘッダ（すなわち用いられたＩＰアドレス）が、用いられたＳＰＩの代わりにＳＡを識別するように、変更されるべきである。

ヘッダ除去フローごとの付加的な子ＩＰｓｅｃ ＳＡの作成によっても、ＳＡごとの付加的なキーの作成をもたらす。しかしながら、付加的なキーによるオーバーヘッドを縮小するために、異なるヘッダ除去ＩＰｓｅｃ ＳＡの間で１個のキーを共有することもまた可能である。

複数のヘッダ除去ＳＡが異なるフローに用いられる際に１個の共有されたキーによって確保されるであろうトラフィックの量は、１個の単一非ヘッダ除去ＳＡ中に１個のキーを用いて移送されるすべての異なるフローと比較して違いはないので、キーを共有する際に付加的なセキュリティ上のリスクはないはずである。

ヘッダ除去シグナリングを運搬するために拡張ができる他の考えられるプロトコルは、モバイルＩＰｖ６プロトコルである。次いで、ヘッダ除去要求は、おそらくは新しいモビリティ・オプション等として、ＭＩＰ６バインディング更新（ＢＵ）メッセージ中に含まれてもよく、ヘッダ除去応答は、同じくおそらくは新しいモビリティ・オプション等としてＭＩＰ６バインディング受信確認（ＢＡＣＫ）メッセージ中に含まれてもよい。ＢＵおよびＢＡＣＫは、除去できるヘッダについて、および、外部ＩＰヘッダ、すなわち、少なくとも用いられたソースおよび宛先ＩＰアドレスについて、もう一方のノードに連絡する。

ヘッダ除去シグナリングを実行するさらに別の方法は、例えば、ＧＷとＵＥの間でトラフィックがＩＰトンネリングされる場合に、アプリケーション層シグナリング（ＳＩＰ／ＳＤＰ）を活用することである。ここではＳＩＰ／ＳＤＰ（およびＱｏＳネゴシエーション）シグナリングの間、用いられたＩＰアドレス、フロー・ラベル、トラフィック・クラス、プロトコルがネゴシエーションされる。こうして、付加的なトリガ、および、ＳＩＰシグナリング中に含まれるおそらくは新たに割り付けられたＩＰアドレスは、ゲートウェイとＵＥの間のヘッダ除去の使用を指示することができるであろう。ＳＩＰ ＯＫメッセージは、最終的なヘッダ・パラメータについてＵＥに連絡するために拡張されうる。図１９は、ＳＩＰ／ＳＤＰシグナリングが用いられる時の例示的なシグナリング・フローを示す。

セッションが開始される前に、ＵＥは、このセッションに用いられる新しいＩＰアドレスを割り当ててもよい。ＵＥは、ヘッダ除去が適用されるべきであることを指示する付加的なフラグ、および、おそらくはこのフローをトンネリングするために用いられるべき新しいＩＰアドレスがついたＳＩＰ招待メッセージを、ＳＩＰプロキシ（Ｐ−ＣＳＣＦ）へと送信する。したがって、Ｐ−ＣＳＣＦはヘッダ除去が用いられるべきであることを検知する。内部ＩＰヘッダ・フィールドについての情報は、ＳＤＰメッセージから導き出すことができる。

ＵＥ間の通常のＳＩＰ交換が実行されるが、付加的なヘッダ除去指示を伴わない。Ｐ−ＣＳＣＦは、ポリシーおよび課金ルール機能（ＲＣＲＦ）に、ヘッダ除去要求および用いられるべきＩＰアドレスについて連絡する。ＲＣＲＦは今度は、要求を許可してもよく、ヘッダ除去、すなわち除去されるべき内部ヘッダおよびＵＥの新しいＩＰアドレスについて、ゲートウェイに連絡してもよい。ＧＷはその時も、該セッションのための新しいＩＰアドレスを割り当ててもよい。

ＧＷは、ヘッダ除去受信をＲＣＲＦへと送信し、ダウンリンクＨＲコンテクストＩＤ、すなわち、割り付けられたＩＰアドレスについて、ＲＣＲＦに連絡する。ＲＣＲＦは引き続いて、ダウンリンクＨＲコンテクストＩＤについて、Ｐ−ＣＳＣＦに連絡する。最後に、Ｐ−ＣＳＣＦは、ヘッダ除去受信メッセージおよびダウンリンクＨＲコンテクストＩＤを含むＳＩＰ ＯＫメッセージを、ＵＥへと送信する。

シグナリングのＳＩＰ手順への上記の実施は単に例示的であり、限定的として理解されないものとすることに留意するべきである。むしろ、当業者は、適用されうる変形を簡単に知るであろう。

ＩＥＴＦ ＭＥＸＴ作業グループにおいて現在論じられている話題は「一般的通知メッセージ」の実装である。この一般的なメッセージは、図１９に例示される「ヘッダ除去要求／応答」シグナリングを実行するために、ＳＩＰシグナリングおよび他の手段を用いる代わり、用いられてもよい。

前記観点における他の可能性は、新しいモビリティ・ヘッダの種類を用いることであろう。前記場合において、通常はモバイルＩＰの一部であるメッセージは、前記種類を指示する異なるヘッダを採用することによって「ヘッダ除去要求／応答」シグナリングのために用いられるであろう。

本発明の他の実施形態によると、ＵＥおよびＵＥ上のアプリケーションに依存して、すべての内部ヘッダを再構築することは必要でないかもしれない。より高位の層によって必要とされている最内部ヘッダのみを再構築することで十分でありうる。図１５を参照すると、例えば、ＵＥへ／からの複数のトンネル（ｎ３Ｇ−ＨＡへの１個のＩＰトンネル、ｅＰＤＧへの１個のＩＰｓｅｃトンネル、およびＰＤＮ−ＧＷへの他のＩＰトンネル等）がある場合、トンネリングを伴わない元のＩＰフロー（ＵＥと対応するホストの間の）のＩＰヘッダ、およびＵＥ−ＰＤＮＧＷトンネルのヘッダ、およびＵＥ−ｅＰＤＧトンネルのヘッダも、ヘッダ除去によって除去することができる。こうして、この特定のセッションのためのＵＥとｎ３Ｇ−ＨＡの間のトラフィックは、ダウンリンク・トラフィックのためのＵＥのＩＰアドレスを宛先アドレスとして、および、ｎ３Ｇ−ＨＡのＩＰアドレスをソース・アドレスとして有する１個のＩＰヘッダのみを有する。この場合、ＵＥが両トンネルのトンネル端点である場合、ＵＥ−ｅＰＤＧトンネルまたはＵＥ−ＰＤＮ−ＧＷ ＩＰトンネルを再構築する必要はない。より高位層のためには、ＵＥ−ＣＮセッションのために用いられるＩＰヘッダのみを再構築することで十分かもしれない。

さらに、アプリケーションに依存して、最内部ヘッダですら再構築される必要がないこともありうる。データ・ペイロードは直接アプリケーションに渡すことができる。

本発明の上記実施形態のうち一つによるヘッダ除去は、いくつかの内部ヘッダの除去を同時に許可する。例えば、図１７に示されるシナリオでは、ＷＬＡＮ内のＨＡは、ＵＥ−ｅＰＤＧトンネル、ＵＥ−ＰＤＮ−ＧＷトンネルおよびＵＥ−ＣＮ ＩＰセッションのヘッダを除去することができる。

しかしながら、トンネルは暗号化等することができ、そこで内部ヘッダは見えなくなり、それらを除去することは可能でない。この場合、複数の端点によってヘッダ除去がサポートされている場合は、ＭＮとＷＬＡＮ内の自己のＨＡの間のような、ある特定の通信経路上の同量のオーバーヘッド縮小を達成する連続的な態様で、ヘッダ除去は適用されうる。本実施形態によると、ＵＥは各トンネル端点で別々にヘッダ除去手順を実行する。

例えば、ＵＥとｅＰＤＧの間およびＵＥとＰＤＮ−ＧＷの間に安全なトンネルがありうる。次いで、ＷＬＡＮ内のＨＡがＵＥ−ＰＤＮ−ＧＷヘッダまたはＵＥ−ＣＮヘッダを除去することは可能でないと思われ、ｅＰＤＧがＵＥ−ＣＮヘッダを除去することも可能でないと思われる。本発明の本実施形態による連続的なヘッダ除去態様により、下記に論じられるようにＨＡとＭＮの間でヘッダ除去を達成することも依然として可能である。

ＵＥは、以下の態様で手順を実行してもよい；最初にＵＥは、ＰＤＮ−ＧＷでヘッダ除去を実行して、ＵＥ−ＣＮ ＩＰセッションのヘッダを除去する。引き続いて、ＵＥはｅＰＤＧでヘッダ除去を実行して、ＵＥ−ＣＮヘッダを除去するために以前に作成されたＵＥＰＤＮ−ＧＷセッションのヘッダを除去する。ＵＥは、ＷＬＡＮ内のＨＡでヘッダ除去を実行し、ＵＥ−ＰＤＮ−ＧＷヘッダを除去するために以前に作成されたＵＥ−ｅＰＤＧセッションのヘッダを除去する。

結果生じるフローが図２０に示される。ＣＮからＰＤＮ−ＧＷへのフローは変化しておらず、１個のＩＰヘッダを有する。ＰＤＮ−ＧＷからｅＰＤＧへのフローでは、内部ＵＥ−ＣＮヘッダが除去され、内部ヘッダごとに別々のフローが確立される。同じことが、ｅＰＤＧおよびＨＡに行われ、内部ヘッダが除去され、別々のフローが確立される。様々なエンティティ間の各通信経路上で、交換されるデータ・パケット中には１個のヘッダのみが存在する。

ＩＰｖ４はインターネットで依然として広範に用いられている。先の実施形態では、外部ヘッダは、実施形態のうち一つによるヘッダ除去を実行した後は、ＩＰｖ６タイプに属することが想定されてきた。次いで、外部ＩＰｖ６ヘッダの場合、および、ＵＥがＣＮを備えたＩＰｖ４セッション、すなわち内部ＩＰｖ４ヘッダを有し、両方のエンティティがＩＰｖ４アドレスを有する場合には、ＵＥおよびＣＮのＩＰｖ４アドレスの連結が、コンテクストＩＤとして、すなわち、外部ＩＰｖ６ヘッダのアドレスのインタフェース識別子として用いられうる。当然、ＵＥおよびＣＮのＩＰｖ４アドレスの他の組み合わせもまた、インタフェース識別子を形成するための同一のものの単一の単純な連結とは別に可能である。

他の最適化では、先の実施形態において詳細に論じられたように、内部ヘッダがＩＰｖ４タイプであり、外部ヘッダがＩＰｖ６タイプであり、代替的に、内部ヘッダ・フィールドを様々なソース／宛先アドレスへとコード化する場合には、内部ＩＰｖ４フィールドは以下の規則によって外部ＩＰｖ６ヘッダへと複写されてもよい。

すでに既述したように、上記に記載された本発明の様々な実施形態では、図４中に表示されるようにトンネリングされたデータ・パケットのヘッダ除去が、外部ヘッダがＩＰｖ６ヘッダである場合に適用されることが想定される。これは例えば、ＵＥがＩＰｖ６のみをサポートするアクセス・ネットワーク中にあり、ひいては、ＩＰｖ６ヘッダを外部ヘッダとして用いる場合である。しかしながら、本発明はＩＰｖ６ヘッダ・タイプのみに限定されない。少なくとも２個の付加的なシナリオが可能である。

第１のシナリオによると、ＩＰｖ６がサポートされていることは常には想定できない、すなわち、いくつかのアクセス・ネットワークはＩＰｖ４のみをサポートしうる。次いでＵＥは、ＩＰｖ４アドレスのみを割り当てることができ、トンネリング（ＤＳＭＩＰまたはＩＰｓｅｃ等）の場合には、たとえ内部パケットがＩＰｖ６パケットである場合であっても、外部ヘッダはＩＰｖ４ヘッダとなるであろう。

第２のシナリオによると、移動ノードが配置されているアクセス・ネットワークは、両方のＩＰバージョン、ＩＰｖ４およびＩＰｖ６、をサポートしてもよい。前記場合において、ＵＥは両者の間で選択してもよい。しかしながら、ＤＳＭＩＰｖ６等の場合には、ＭＮがＩＰｖ６気付アドレスを優先することが有利である。

第１のシナリオによる課題の一つは、本発明の先の実施形態において上記に詳しく記載した、外部ＩＰｖ６ヘッダを想定するヘッダ除去が、ＩＰｖ４と協働しないことである。第２のシナリオによる課題の一つは、ＩＰｖ６ヘッダの長さが４０バイトである一方で、ＩＰｖ４ヘッダのみは２０バイト（および２８バイトの付加的なＵＤＰヘッダ）であることである。こうして、選択されたＩＰｖ６ヘッダは、ＩＰｖ４ヘッダのサイズの約２倍（１．４３倍）であろう。

本発明の他の実施形態によると、外部ＩＰｖ６ヘッダを用いる代わりに、可能な場合には外部ヘッダがＩＰｖ４タイプへと常に変更される。より具体的には、ヘッダ除去を実行する際に、移動ノードおよびＰＤＮ−ＧＷのアクセス・ネットワークがＩＰｖ４をサポートする場合には、内部ＩＰｖ６ヘッダが除去され、外部ＩＰｖ４ヘッダがデータ・パケットに適用される。ＩＰｖ４タイプの例示的なヘッダが図２１に図示される。

主な利益は、ＩＰｖ４のみのアクセス・ネットワークに対するトンネル除去機構もまた可能になることである。さらに、ＩＰｖ４ならびにＩＰｖ６がサポートされている場合には、ＩＰｖ４外部ヘッダを用いるヘッダ除去機構は、ＩＰｖ６外部ヘッダでのヘッダ除去を用いる場合よりも、さらにより小さなデータ・パケットを結果としてもたらす。さらには、ヘッダ除去後に結果生じるデータ・パケットは、ＩＰｖ６ヘッダを用いてＣＮから送信された初期のデータ・パケットよりもさらに小さい。

これら２つの利益は、図２２を用いてより詳細に図示され、該図は一般に、先の実施形態の図５に対応する。図５および図２２を比較すると、ＨＡとＭＮの間で交換されるＩＰｖ６データ・パケット・ヘッダは図２２中のＩＰｖ４データ・パケット・ヘッダの２倍であることは明らかである。さらに、図２２内では、ＣＮとＨＡの間で交換されるデータ・パケット、および、ＨＡとＭＮの間で交換されるデータ・パケットはサイズもまた異なる。これは、ＩＰｖ４とＩＰｖ６の様々なヘッダ・サイズを理由とする。

本発明の先の実施形態においてすでにアドレス指定されたように、除去される内部ヘッダ中の変化するフィールド（すなわちトラフィック・クラス、フロー・ラベルまたはホップ・リミット）でありうる。前記フィールド内の値は、データ・パケットごとに変化しうるので、値は別々におよび変化するフィールドごとにアドレス指定される必要がある。この課題は、変更する値を備えた対応するフィールドを単に除去しないことによって、克服されうる。こうして、先に様々な異なる実施形態において説明された発明に関するヘッダ除去手順によると、静的なフィールドのみが除去されるであろう。

内部ヘッダ中の変化するフィールドを取り扱う他の可能性は、変化するフィールドのコンテンツを最終的な外部ヘッダへと複写することである。しかし、内部ＩＰｖ６ヘッダおよび外部ＩＰｖ４ヘッダの変化するフィールドの複写は、ＩＰｖ４およびＩＰｖ６ヘッダ・フィールドが異なるという点で課題を提起する。

しかしながら、たとえヘッダ・フィールドが異なっていても、考えられる一つの例示的な内部ＩＰｖ６ヘッダの外部ＩＰｖ４ヘッダへの複写方法が、以下の表に示される。

内部ＩＰｖ６フィールドの外部ＩＰｖ４フィールドへのこのマッピングは、外部ＩＰｖ４フィールドが用いられない場合にのみ可能である。とりわけフロー・ラベル・フィールドの複写のためには、ＩＰｖ６パケットはフラグメント化されない必要がある。そうでなければ、ＩＰｖ４識別フィールドは、除去された内部ＩＰｖ６フラグメント化ヘッダの識別を運搬するのは必至である。識別フィールドおよびフラグメント・オフセット・フィールドが内部フロー・ラベル・フィールドを運搬するのに用いられる場合は、より多くのフラグメント・フラグが０に設定されるべきである。外部ヘッダ・フィールドがすでに使用中である（識別フィールド等）場合には、内部ヘッダの対応するフィールド（フロー・ラベル等）は内部ヘッダ内で保守されるべきである。ここでの（いつもの通りの）一つの可能性は、この場合は、内部ＩＰｖ６フラグメント・ヘッダを除去しないことである。

外部ヘッダ・フィールドが変化する内部ＩＰｖ６ヘッダ・フィールド（ホップ・リミット等）をコード化できない場合を克服する他の可能性は、異なるＩＰｖ４ソースおよび／または宛先アドレスを用いることである。このことは、図１１、１２および１３と関連して論じられた実施形態と類似している。このことは、再び図２３および２４に図示され、図では異なるＩＰｖ６ホップ・リミットが異なる外部ＩＰｖ４宛先アドレスへとコード化される。

にもかかわらず、上記に記載された外部ヘッダ・フィールドに関する限定とは別に、ＩＰｖ４は、ＩＰｖ６と比較してさらなる限定を有する。まず、ＩＰｖ４はステートレスアドレス自動設定をサポートしない、すなわち、ＵＥは、プレフィクスおよび生成されたインタフェース識別子に基づいてアドレスを設定できない。さらに、ＩＰｖ４は、限定されたアドレス空間に悩まされる。ＵＥは、任意の数のＩＰｖ４アドレスを割り当てることはできないかもしれないが、非常に限定された数のみ、最悪の場合にはまたは１個の単一のアドレスを割り当てうる。別の課題は、ネットワーク・アドレス変換（ＮＡＴ）と関連する私設ＩＰｖ４アドレスが広範に用いられることである。簡略に説明すると、ＵＥには、アクセス・ネットワーク内に私設ＩＰｖ４アドレスが割り当てられ、次いで、外部ノードと通信して、該私設ＩＰアドレスは、ＮＡＴルータによって公開ＩＰアドレスへと変換される。これらの場合には、コンテクストＩＤの外部ＩＰｖ４ヘッダへのコード化は可能でない。

より具体的には、当業者にすでに知られているように、ＩＰｖ４は比較的小さいアドレス空間のみを有する。ネットワーク・アドレス変換は、ソースおよび／または宛先ＩＰアドレスを再書き込みすることを伴う対応するＮＡＴルータを介して、ネットワーク・トラフィック、および通常は、ＩＰパケットが通過する際のＴＣＰ／ＵＤＰポート数を送受信することによって、ＩＰｖ４アドレス不足に対処する。

典型的な設定では、ローカル・ネットワークは、指定された「私設」ＩＰアドレス・サブネットのうち一つを用い、前記サブネット内のノードは対応する私設アドレスを有する。さらに、当該ネットワーク上のＮＡＴルータもまた、当該アドレス空間内に私設アドレスを有し、単一の「公開」アドレス（「過負荷の」ＮＡＴとして知られる）またはインターネット・サービス・プロバイダー等によって割り当てられた複数の「公開」アドレスでインターネットに接続される。トラフィックがローカル・ネットワークからインターネットへと通過するとき、各パケット内のソース・アドレスは、オンザフライでノードの私設アドレスから公開アドレスへと（単数または複数）変換される。

ルータは、アクティブな接続（とりわけ 宛先アドレスおよびポート）それぞれについての基本的なデータを追跡する。応答がルータに戻ると、ルータは、アウトバウンド段階中に保存された接続追跡データを用いて、内部ネットワークのいずれに応答を転送するかを決定する。ＴＣＰまたはＵＤＰクライアント・ポート番号を用いて、過負荷のＮＡＴの場合にはパケットを逆多重化し、または、パケットの戻り時には、複数の公開アドレスが利用可能である場合にＩＰアドレスおよびポート番号を用いる。インターネット上のシステムに対し、ルータ自体が、このトラフィックに対するソース／宛先であるかのようである。

言い換えれば、ベーシック・ネットワーク・アドレス変換（Ｂａｓｉｃ ＮＡＴ）またはネットワーク・アドレス・ポート変換（ＮＡＰＴ）といった、様々な種類のＮＡＴが可能である。Ｂａｓｉｃ ＮＡＴによって、私設および公開ＩＰアドレスの間に一対一のマッピングがある。代替的には、ＮＡＴは過負荷であってもよい。次いで公開ＩＰｖ４アドレスが、ＮＡＴの後方のいくつかのホストによって用いられる。これら過負荷のＮＡＴを横断するために、ＮＡＰＴが用いられる。この場合、ＴＣＰまたはＵＤＰポート番号は、ＮＡＴの後方の、ホストへの接続をそれぞれ識別するのに用いられる。例えば、ＵＤＰトンネリングは、ＩＰｖ４アクセス・ネットワーク内のＤＳＭＩＰｖ６（デュアル・スタックＭＩＰｖ６）の場合に用いられ、すなわち、ＭＮとＨＡの間のパケットはＵＤＰおよびＩＰｖ４によってトンネリングされる。

本発明の他の実施形態によると、新しいソースおよび宛先ＩＰアドレスを割り付ける代わりに、データ・パケットを交換するために、ＵＤＰトンネリングでＩＰｖ４を用いる場合、（ＮＡＴを横断する等のため）ＵＤＰヘッダはヘッダ除去に再び用いることができる。例えばＵＤＰポート番号が、通信ピア・エンティティによって除去された内部ヘッダを再構築するために、コンテクストＩＤに新たに設定されてもよい。このことは、ＩＰアドレスをコンテクストＩＤとして用いる代わりに、または、これと組み合わせて行ってもよい。

加えて、変更する値を有するフィールドを取り扱うには、前記変化するフィールド中の各異なる値それぞれに対し１個の特別なＵＤＰポート番号を設定することが可能である。このことは図２５および２６に図示され、それぞれの図は、ヘッダ除去の前および後のデータ・パケットを示す。図２５中のＵＤＰポート番号はコンテクストＩＤとして用いられ、ホップ・リミット＝Ｘに属する。それゆえに、Ｘとは異なるホップ・リミットがついたデータ・パケットは、図２６に図示するようなコンテクストＩＤ「ｐｏｒｔ ｎｒ．Ｙ」に属するホップ・リミットＹといった異なるＵＤＰポート番号をコンテクストＩＤとして有するであろう。図２７は、図２６と関連して論じられた本発明の本実施形態によるヘッダ除去を適用する前および後の、ＭＮとＣＮの間の通信中に用いられるデータ・パケット・フォーマットを、ＨＡとＭＮの間の通信経路上のデータ・パケット・フォーマットと対比して示す。

ヘッダ除去手順の設定は、先の実施形態のものと同一であってもよい。さらに、ただし、ＵＥとＰＤＮ−ＧＷ（ＵＥのＨＡ）の間にヘッダ除去が適用されるべきであるならば、ヘッダ除去シグナリング・フロー内にて、ＵＥは、ＰＤＮ−ＧＷへのヘッダ除去要求メッセージ中に、除去されるべき内部ヘッダおよび考えられる変化するフィールドに関する望まれる挙動を指示する。ＵＥが、様々なフローのための付加的なＩＰアドレスに除去されたヘッダを割り当てられない場合、ＵＥは異なるフローに用いられるべき異なるＵＤＰポートを指示する。

図２８の例において、ＵＥが、私設ＩＰｖ４アクセス・ネットワークからＮＡＴを介した２個のＣＮと通信し、ヘッダ除去がＵＥとＰＤＮ−ＧＷの間で用いられる場合には、データ・パケットがどのように見えるかが示される。ＣＮ１およびＣＮ２は、ＩＰｖ６ヘッダがついたすなわちＰＤＮ−ＧＷにて割り付けられたデータ・パケットを、ＵＥのホーム・アドレスへと送信している。ＰＤＮ−ＧＷは、ＩＰｖ４およびＵＤＰトンネリングとともにＤＳＭＩＰｖ６を用いて、パケットをＵＥへとトンネリングする。加えて、本発明の本実施形態によるとＰＤＮ−ＧＷはＩＰｖ６ヘッダを除去し、異なるＣＮからのパケットに対し、異なるＵＤＰ宛先ポートを用いる。ＮＡＴにおいて、公開ＩＰｖ４アドレスは、ＵＥの私設ＩＰｖ４アドレスへと変更され、ポート番号もまたＮＡＴによって割り当てられた番号へと変更されうる。この場合、ＰＤＮ−ＧＷが宛先ポート４４４４（ＣＮ１からのパケット）または４４４５（ＣＮ２からのパケット）を検知する時には、ＰＤＮ−ＧＷは、本実施形態によるヘッダ除去を実行することを知っている。しかしながら、ＮＡＴルータでのＵＤＰポート番号の変更を理由として、ＵＥに対応するコンテクストＩＤはそれぞれ２３４５６および２３４５７である。それゆえに、ＵＥがＵＤＰポート番号２３４５６および２３４５７を検知する場合、ＵＥは、それぞれ完全なヘッダ連結を再構築する再構築コンテクストを識別しうる。

ＵＥがＮＡＴの後方にある場合に考慮されるべき１個の論点は、アドレス依存フィルタリングまたはアドレスおよびポート依存フィルタリングがＮＡＴ中に適用されうることである。この場合、内部端点または外部端点のポート番号が変化する場合、パケットはＮＡＴで落とされる。すなわち、上記の例では、ＰＤＮ−ＧＷがパケットをＵＥへと送信し、以前の通信中には用いられなかったポート番号（ＮＡＴの設定に依存するソースおよび／または宛先）を用いる場合は、パケットは転送される代わりにＮＡＴによって落とされる。これを克服するために、ＵＥは、パケットを、適切な内部ＩＰアドレスおよびポートから、外部ノードのＩＰアドレスおよびポートへと最初に送信しなければならない。このことは、ＮＡＴルータがＵＥへの着信パケットを受信および転送することを、可能にするであろう。

さらに、このことはまた、変化するフィールドがＰＤＮ−ＧＷから送信されるＵＤＰポート中でコード化される場合には、ＰＤＮ−ＧＷは、パケットをＰＤＮ−ＧＷアドレスおよび適切なポートへと送信するために、既存の接続上のＵＥをトリガしなければならないことを意味する。これは、変化するフィールドの新しい値が、発明に関するヘッダ除去に対して考慮される必要があるたびに、行われなければならない。

別の論点は、ＮＡＴがＵＤＰヘッダのポート番号を変更しうることである。例えば、ＮＡＴの後方の異なるホストが同一の外部ノードと通信している場合は、これらホストは内部で同一のポート番号を用いている。この場合は、ＰＤＮ−ＧＷに、用いられるべき宛先ポートについて連絡しても十分でないかもしれない。その理由は、図２８にすでに示したように、ＰＤＮ−ＧＷによって見られる宛先ポート番号はＵＥによって用いられる番号と異なりうるからである。実際のところ、２個以上のホストが内部で同一のポート番号を用いる場合、ＮＡＴは、１個の公開ＩＰアドレスのみを用いて、前記２個のホストに対するデータ・パケット着信を区別するべく、前記ポート番号を２個の異なるポート番号へと変更する必要がある。

したがって、本発明の一実施形態は、ＵＥが適切なアップリンクおよびダウンリンク・セッションに用いられるべき、ＵＤＰソース・ポートからの、ヘッダ除去要求メッセージを送信することを示唆している。言い換えれば、コンテクストＩＤを交換するための、再構築情報といった情報をさらにおそらくは含む、コンテクスト設定メッセージが、コンテクストＩＤ（ポート番号）を前記メッセージのソース・ポート番号として用いて、ＵＥからＰＤＮ−ＧＷへと送信される。次いで、ＮＡＴがＵＤＰポート番号を変更する時、ＰＤＮ−ＧＷに受信された設定メッセージは、実際のメッセージ内にコンテクストＩＤ（ポート番号）として指示されたメッセージとは異なるソース・ポート番号を有する。こうして、メッセージのソース・ポート番号は、実際のメッセージ中に指示されたメッセージの代わりに、コンテクストＩＤとして用いられることを、ＰＤＮ−ＧＷは決定しうる。

図２９は図２８と類似の配置を示すが、しかしながら、１個のＣＮのみで、両方向におけるデータ・パケット交換を図示している。ＮＡＴルータが、ＵＥと自己のＨＡであるＰＤＮ−ＧＷの間に配置されると想定する。図示された本発明のこの例示的な実施形態の場合、コンテクストＩＤがデータ・パケットのポート番号へとコード化されることもまた想定されている。

ダウンリンク、すなわちＣＮからＵＥまでは、コンテクストＩＤはＵＤＰ宛先ポートである。より具体的には、ＰＤＮ−ＧＷにはＵＤＰポート４４４４、ＵＥにはＵＤＰポート２３４５６である。データ・パケットがＵＤＰポート４４４４へと送信されるべきであるとＰＤＮ−ＧＷが検知すると、ＰＤＮ−ＧＷは、先の実施形態のうち一つによるヘッダ除去を実行し、ひいては、１個の外部ヘッダ、ここではＩＰｖ４ヘッダのみと、ＵＤＰヘッダを保持する。前記より小さいデータ・パケットは次いでＮＡＴへと送信され、ＮＡＴはＵＥの私設アドレスおよび異なるＵＤＰポート番号を用いることによって、データ・パケットの宛先フィールドを変更する。ＵＥはデータ・パケットを受信し、ＵＤＰポート番号２３４５６から、ヘッダ除去が適用されたことを認識してもよく、次いで、コンテクストＩＤによって識別されたコンテクストを用いて完全なヘッダ連結を再構築してもよい。

ヘッダ除去を適用しないデータ・パケット・フォーマットおよびコンテンツと比較すると、ＵＤＰヘッダの宛先フィールド中に用いられるＵＤＰポート番号は異なっている、すなわち、ＨＡとＮＡＴルータの間では３３３３、または、ＮＡＴルータとＭＮの間では５９８７であることが顕著である。

反対に、アップリンク上では、ソースＵＤＰポート番号がコンテクストＩＤとして用いられる。より詳細には、ソースＵＤＰポート番号２３４５６が、ＵＥに、発進データ・パケットにヘッダ除去を実行させることを促す。ソースＵＤＰポート番号４４４４は、ＰＤＮ−ＧＷを誘発して、コンテクストＩＤ４４４４によって識別されたコンテクスト情報を用いて、ヘッダ再構築を実行する。

ここで本発明の異なる実施形態を参照すると、考えられる一つのシナリオは、ＤＳＭＩＰｖ６のＵＥがまず信頼されたアクセスに接続されること、すなわち、ＰＤＮ−ＧＷがアクセス・ネットワークから到達可能であり、ＵＥは、バインディング更新を直接的にＰＤＮ−ＧＷへと送信できることである。加えて、ＵＥはＰＤＮ−ＧＷ中にヘッダ除去コンテクストを確立した可能性がある。次いでＵＥは、ハンドオーバーを信頼されていないアクセスへと行っており、ローカルＩＰｖ６プレフィクスを割り当て、対応するローカルＩＰｖ６アドレスを有する。さらに、ＰＤＮ−ＧＷはアクセス・ネットワークから直接的に到達可能でないので、ＵＥがＢＵをＰＤＮ−ＧＷへと送信できる前に、ＵＥはｅＰＤＧとの接続を確立する必要がある。ｅＰＤＧとの接続は、データ・パケットのさらなるカプセル化をさらに含んでもよい。図３０は、ＭＮが信頼されないネットワーク内に配置され、ｅＰＤＧを介してＰＤＮ−ＧＷおよびＣＮと通信する必要がある時の、パケット・フォーマットおよびコンテンツを図示している。

「前」とともに示されるデータ・パケットにおいて、ｅＰＤＧとＭＮの間には各データ・パケット中に合計３個のＩＰヘッダが存在することは明らかである。より詳細には、最内部ヘッダとは、データ・パケットを送信し導くためにＣＮによって用いられるヘッダのことを言う。第２の内部ヘッダはＭＩＰによりＨＡによって接続され、インターネット・プロトコルのバージョン６またはバージョン４、ここではＩＰｖ４に属しうる。ｅＰＤＧは次いで、別のヘッダ中の前記パケットをカプセル化し、セキュリティの理由でＩＰｓｅｃプロトコルのＥＳＰヘッダに接続する。それゆえに、ＵＥ内で受信されたパケットは３個のＩＰヘッダおよびＥＳＰヘッダを有する。

ＨＡおよびＵＥの間で先の実施形態によるヘッダ除去を実行することによって、図３０にＨＡとｅＰＤＧの間に「後」で示されるデータ・パケットより明らかなように、ＣＮによって用いられるＩＰｖ６ヘッダを除去することが可能である。

該ヘッダ除去後にＨＡによってデータ・パケットを送信するために用いられる、別のヘッダ除去をｅＰＤＧとＵＥの間で実行することによって、外部ヘッダを除去し、ひいては１個のヘッダおよび随意的にＥＳＰヘッダを保持することすら可能である。

例示的なコンテクストＩＤはダウンリンク中の下記である。

ＨＡは、あるデータ・パケットのソース・アドレス１１５．１．１．７を検知し、それに応答してヘッダ除去を実行する。ｅＰＤＧは、宛先アドレス１１０．１０．７があるデータ・パケットに用いられるであろうことを検知し、先の実施形態のうち一つによるヘッダ除去も実行する。次いで、データ・パケットを受信するＭＮは、宛先アドレス・フィールド中のコンテクストＩＤ１１０．１０．０．７に気が付き、ｅＰＤＧで設定されたヘッダ再構築を実行し、これによって、ＨＡによるヘッダ除去後のＨＡとｅＰＤＧの間で採用されるヘッダ構造がついたデータ・パケットになる。

引き続いて、ＭＮは、データ・パケットの外部ヘッダのソース・アドレス・フィールド中のコンテクストＩＤ１１５．１．１．７に気が付くと思われ、ＨＡで設定されたヘッダ再構築を実行し、これによって、「前」で示されるデータ・パケット・フォーマットによって図示される完全なヘッダ連結がついたデータ・パケットになる。

ハンドオーバー中のシグナリング・オーバーヘッドを縮小するこのシナリオにおける考えられる一つの代替的な最適化は、ｅＰＤＧへのトンネル確立中に、ＵＥがヘッダ除去を使用したい旨の信号を、ＵＥがｅＰＤＧに対して送ることである。同時に、ＵＥはｅＰＤＧからのアドレス・プレフィクスを要求し、次いで、新しいＣｏＡプレフィクスの付いたＢＵをＰＤＮ−ＧＷへと送信する。さらに、ＵＥはｅＰＤＧに対し、自己がパケットをカプセル化しＰＤＮＧＷからＵＥへとトンネリングするべきでないが、その代わりに、ｅＰＤＧが、ＰＤＮ−ＧＷからのダウンリンク・パケットの外部ヘッダのソース・アドレス・プレフィクスを、ｅＰＤＧからの新しいプレフィクスで置換するとともに宛先アドレス・プレフィクスをローカル・アドレス・プレフィクスによって置換するよう指示する。それゆえに、別のヘッダ除去をｅＰＤＧで確立する必要はないであろうが（図３０を参照のこと）、しかし、指示された外部ヘッダを変更する一方、ＥＳＰヘッダ、ひいてはｅＰＤＧとＭＮの間のセキュリティを保持することによって、付加的なトンネルを十分回避できるであろう。

シグナリング・オーバーヘッドを縮小するための、ＰＤＮ−ＧＷを離れる際のコンテクストＩＤの除去を簡素化する等、他の最適化は、コンテクストＩＤの構成中に階層を有することである。例えば、コンテクストＩＤは３つの部分に分けることができる：
１．ＰＤＮ−ＧＷを参照するＰＤＮ−ＧＷコンテクスト
２．いくつかのフロー（音声＋映像）から成る等、セッションを参照するセッション・コンテクストＩＤ、および
３．セッション中のフローを参照するフロー・コンテクストＩＤ。

例えば、ポート番号２３４５６等をコンテクストＩＤとして用いる場合、数「２３」は、これによってヘッダ除去セッションが確立されるであろうエンティティ、この場合ＰＤＮ−ＧＷを示すであろう。数「４」はセッションを指示しうるし、残りの数「５６」は異なるフローを区別するであろう。

したがって、ＵＥがあるＰＤＮ−ＧＷからのすべてのセッション／フローを終了したい場合、ＵＥはＰＤＮ−ＧＷコンテクストＩＤのみを指示し、すべてのヘッダ除去コンテクストを削除することができる。これに反して、ＵＥがあるセッションのすべてのフローを終了したい場合は、ＵＥはセッション・コンテクストＩＤのみを指示し、該セッションに属するすべてのヘッダ除去コンテクスト（すなわち、すべてのフロー）は、１ステップで終了することができる。

さらに、ＵＥは、ＣＮへのセッションに対するＵＥとＰＤＮ−ＧＷ等の間のトンネルのためのヘッダ除去コンテクストを作成したかもしれない。しかしながら、ＵＥが例えば信頼されない非３ＧＰＰアクセス・ネットワーク中にある場合、ＵＥは、同一のセッションに対するＵＥとｅＰＤＧの間のトンネルのためにヘッダ除去コンテクストを追加的に作成してもよい（図３０および対応する議論を参照のこと）。そこで、同一のセッションに対して、ＵＥ内には複数のコンテクストＩＤがある。このシナリオでは、ネットワーク内のリソースを縮小することが必要でない場合は、コンテクストＰＤＮ−ＧＷを休止状態に置くことができる。ｅＰＤＧがついたコンテクストのみが設定されてもよく、このコンテクストのみが次いで用いられるであろう。これに反して、該ネットワーク内のヘッダ除去が用いられるべきである場合は、１個のパケットには２個のコンテクストがある。ここで考えられる一つの改善策は、上記に記載された階層的な３部構成のコンテクストを用いて、ＰＤＮ−ＧＷコンテクストＩＤについて、ｅＰＤＧに連絡することとであり、ｅＰＤＧはコンテクストＩＤの他の部分を再使用してもよく、ＰＤＮＧＷコンテクストＩＤを自己のｅＰＤＧコンテクストＩＤへと変更する。

当業者に明らかなように、本発明の上記に論じられた実施形態は、本発明の背後にある概念を実施する方法についての単なる例である。先の実施形態の様々な組み合わせが可能であり、実施の実際の要件に依存しうる。例えば、コンテクストＩＤとしてのＵＤＰポート番号の使用は、コンテクストＩＤとしてのＩＰアドレスの使用、例えば、一方をアップリンク用他方をダウンリンク用に組み合わせてもよく、または、ポート番号とＩＰアドレスの１個のコンテクストＩＤとしての組み合わせでもよい。別の例示的な組み合わせは、ＩＰｖ４であれＩＰｖ６であれ、ＩＰアドレスに対する階層的に構成されたコンテクストＩＤの使用であろう。

一見したところ、本発明の原理は非常に柔軟であり、そこから最大の利益を達成するためにこの特定のシナリオに適合されうる。

あるデータ・パケットは、データ・パケット中のコンテクストＩＤを探す際に、ヘッダ除去手順に参加する２個のピア・エンティティ、例えばＵＥおよびＰＤＮ−ＧＷによってのみ、ヘッダ除去が実行されたデータ・パケットとして識別されうる。言い換えれば、外側からは、現在のデータ・パケットが、ヘッダ除去を行ったデータ・パケットか否かを決定することは可能でない。しかしながら、いくつかの機能にとっては、「通常の」データ・パケットを、いずれのヘッダ除去が実行されたか今後実行されるデータ・パケットから区別することは有利であるかもしれない。例えば、ネットワーク内の課金は、ペイロードのサイズに基づいて実行されてもよい。ヘッダ除去がついたパケットのペイロード部のほうが、ヘッダ除去がつかないパケットと比較してより大きい。したがって、パケットは異なって課金されるべきであり、ネットワーク内の課金機能はパケットを区別するできるべきである。

ＤＳＭＩＰｖ６の場合、データ・パケット中にてＴＬＶヘッダがＵＤＰヘッダの後に来る可能性がある。このＴＬＶヘッダが、データ・パケットがタイプ「除去されたヘッダがついたＩＰ」であることを示すのに用いられてもよい。次いで、前記ＴＬＶヘッダの後のペイロードは、除去された内部ヘッダ（の一部）がついた実際のデータ・パケットであろう。

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

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

以前の段落では、本発明の様々な実施形態およびその変形が記載されてきた。非常に多数の変形および／または修正が、広く記載されたような本発明の精神または範囲から逸脱することなく、具体的な実施形態中に示されるように、本発明に行われうることが、当業者によって理解されるであろう。

大部分の実施形態は、３ＧＰＰ−ベースの通信システムと関連して概略が説明されてきており、以前のセクション中に主として用いられた術語は、３ＧＰＰ術語に関することにさらに留意するべきである。しかしながら、３ＧＰＰベースのアーキテクチャに関する様々な実施形態の術語および記載は、本発明の原理および思想がかかるシステムに限定することを意図していない。

また、上記の技術分野のセクションで与えられた詳細な説明は、本明細書中に記載された大抵は３ＧＰＰに特有の例示的な実施形態をよりよく理解するよう意図されており、本発明が、移動通信ネットワーク中の処理および機能の記載された具体的な実施に限定されると理解されるべきでない。それにもかかわらず、本明細書中に提案される改善は、技術分野のセクションに記載されたアーキテクチャ中に容易に適用されてもよい。さらに、本発明の概念もまた、３ＧＧＰによって現在論じられたＬＴＥ ＲＡＮ内に容易に用いられてもよい。

Claims (58)

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. 該第１の内部ヘッダおよび該第１の内部ヘッダ中のポート番号が、ユーザ・データグラム・プロトコルまたは送信制御プロトコルに属する請求項４４に記載の方法。
46. 該データ・フロー内において、該データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部が、データ・パケットごとに変化しうる値を備えたフィールドを含み、該方法は、
    除去されるべき該少なくとも１個のヘッダの該少なくとも一部から、該外部ヘッダ中の適切なフィールドへと、変動値を複写するステップを更に含む請求項４４又は４５に記載の方法。
47. 該データ・フロー内において、該データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部が、データ・パケットごとに変化しうる値を備えたフィールドを含み、該除去するステップは、該変動値を備えた該フィールドを除去しない請求項４４又は４５に記載の方法。
48. 該データ・フロー内において、該データ・パケット中のヘッダ連結から除去されるべき該少なくとも１個のヘッダの該少なくとも一部が、データ・パケットごとに変化しうる値を備えたフィールドを含み、該フィールド中に変動値を含む該データ・パケット中でヘッダ連結を再構築するための情報を含むコンテクストをそれぞれ固有に識別する新しいポート番号が、フィールドの各変動値に設定される請求項４４又は４５に記載の方法。
49. ネットワーク・アドレス変換、ＮＡＴが該第２のエンティティに用いられ、該データ・パケットはＮＡＴルータを介して該第１および第２のエンティティの間で交換され、該方法は、
    ＮＡＴルータ内で該設定された新しいポート番号を用いて、該第１のエンティティからのデータ・パケットの受信および転送を可能にするために、宛先またはソース・フィールド中の該設定された新しいポート番号を用いて、該第２のエンティティから、該ＮＡＴルータを介して、該第１のエンティティへとデータ・パケットを送信するステップを更に含む請求項４４から４８のいずれか１つに記載の方法。
50. ネットワーク・アドレス変換、ＮＡＴが該第２のエンティティに用いられ、該データ・パケットはＮＡＴルータを介して該第１および該第２のエンティティの間で交換され、該方法は、
    設定メッセージを、該第２のエンティティから該第１のエンティティへと該ＮＡＴルータを介して送信するステップであって、該設定メッセージは、該第２のエンティティから、該第１の内部ヘッダのソース・フィールド中の第１のポート番号を用いて送信され、該設定メッセージは、該ＮＡＴルータから該第１のエンティティへと、該第１の内部ヘッダのソース・フィールド中の第２のポート番号を用いて転送されるステップと、
    該第１のエンティティ内で、該第２のポート番号を、該データ・パケット中でヘッダ連結を再構築するための情報を含む該コンテクストを固有に識別する該新しいポート番号として決定するステップと、
    を更に含む請求項４４から４９のいずれか１つに記載の方法。
51. 該設定された新しいポート番号が、少なくともデータ・パケットが交換されるエンティティに関して、少なくとも１個の・データ・フローが存在するセッションに関して、データ・パケットのデータ・フローに関して階層的に構成されている請求項４４から５０のいずれか１つに記載の方法。
52. 新しいアドレス又はポート番号を設定する際に、既に存在する新しいアドレス又はポート番号と比較して、前記新しいアドレス又はポート番号の関連する構造部のみが変更され、前記変更された構造部のみが通知される請求項２５又は５１に記載の方法。
53. 不完全なヘッダ連結を含む受信されたデータ・パケットから、ヘッダ連結を含むデータ・パケットを生成する方法であって、該データ・パケットは第１のエンティティと第２のエンティティの間で交換されるデータ・フローに属し、該方法は、
    不完全なヘッダ連結であるが、該第１のエンティティと該第２のエンティティの間の該データ・パケットの交換に用いられてきた、少なくとも外部ヘッダと第１の内部ヘッダとを含むデータ・パケットを受信するステップであって、該第１の内部ヘッダは、完全なヘッダ連結を再構築するための情報を含むコンテクストを固有に識別するポート番号を含むステップと、
    該受信されたデータ・パケットの該第１の内部ヘッダ中のポート番号によって識別された該コンテクスト中の情報に基づいて、該受信されたデータ・パケットのための完全なヘッダ連結を再構築するステップと、
    を含む方法。
54. エンティティと第２のエンティティの間で交換されるデータ・フローのデータ・パケットのサイズを縮小するエンティティであって、該データ・パケットはヘッダ連結を含み、ヘッダ連結中の外部ヘッダと第１の内部ヘッダが、該エンティティと該第２のエンティティの間でデータ・パケットを交換するのに用いられ、該エンティティと該第２のエンティティとがインターネット・プロトコル・バージョン４をサポートするネットワーク内に配置され、該エンティティは、
    あるデータ・パケットの外部ヘッダをインターネット・プロトコル・バージョン４タイプへと適合させるよう構成された処理装置と、
    該処理装置は、該データ・パケット中のヘッダ連結の再構築のための情報を含むコンテクストを固有に識別する新しいポート番号を設定するよう更に構成され、
    該処理装置は、該第１の内部ヘッダの宛先またはソース・フィールド中のポート番号を、該設定された新しいポート番号で置換するよう更に構成され、
    該処理装置は、該外部ヘッダおよび該第１の内部ヘッダではない少なくとも１個のヘッダの少なくとも一部を、ヘッダ連結から除去するよう更に構成され、
    宛先またはソース・フィールド中の該設定された新しいポート番号がついた該第１の内部ヘッダを用いて、該少なくとも１個のヘッダの該少なくとも一部が除去されたヘッダ連結がついた該データ・パケットを、該第２のエンティティへと送信するよう構成された送信機と、
    を含むエンティティ。
55. 請求項４４から５２のいずれか１つに記載の方法のステップを実行するかまたは参加する手段を更に含む請求項５４に記載のエンティティ。
56. 不完全なヘッダ連結を含む受信されたデータ・パケットから、ヘッダ連結を含むデータ・パケットを生成するエンティティであって、該データ・パケットは、第１のエンティティと該エンティティの間で交換されるデータ・フローに属し、該エンティティは、
    不完全なヘッダ連結であるが、該第１のエンティティと該エンティティの間の該データ・パケットの交換に用いられてきた、少なくとも外部ヘッダと第１の内部ヘッダとを含むデータ・パケットを受信するよう構成された受信機であって、該第１の内部ヘッダは、完全なヘッダ連結を再構築するための情報を含むコンテクストを固有に識別するポート番号を含む受信機と、
    該受信されたデータ・パケットの該第１の内部ヘッダ中のポート番号によって識別された該コンテクスト中の情報に基づいて、該受信されたデータ・パケットのための完全なヘッダ連結を再構築するよう構成された処理装置と、
    を含むエンティティ。
57. 請求項２９から３９のいずれか１つに記載のデータ・パケットのサイズを縮小するエンティティを備え、請求項４０から４３のいずれか１つに記載のデータ・パケットを生成するエンティティを備える通信システム。
58. 請求項５４又は５５に記載のデータ・パケットのサイズを縮小するエンティティを備え、請求項５６に記載のデータ・パケットを生成するエンティティを備える通信システム。

Images