JP4965670B2 - 無線通信システムにおいてヘッダ圧縮コンテキストを再配置する方法および装置 - Google Patents

Description

本発明は、無線通信システムにおける方法および装置に関し、特に、ヘッダ圧縮テキストの再配置を可能にする装置、および、そのような再配置の方法に関する。

インターネットの大成功により、全種類のリンクを介してインターネットプロトコル（ＩＰ）を利用することが挑戦的な課題となっている。しかし、ＩＰプロトコルのヘッダがやや大きいという事実から、狭帯域のリンク、例えば無線セルラのリンクについて、このことを実現することは常に簡単な課題ではない。例として、ＶｏＩＰ（Ｖｏｉｃｅ−ｏｖｅｒ−ＩＰ）のために利用されるプロトコル（ＩＰ、ＵＤＰ、ＲＴＰ）により送信される普通の音声データを考えると、この場合、リンクを非常に非効率的に利用した結果、ヘッダがパケットの約７０％であることもある。

ヘッダ圧縮（ＨＣ：ｈｅａｄｅｒ ｃｏｍｐｒｅｓｓｉｏｎ）（以下でさらに定義する）という語は、２地点間リンクを介してホップごとのベースでヘッダで伝送される情報のために必要な帯域幅を最小限にする技術を含んでいる。一般的な技術は、インターネットの世界では１０年以上の歴史を有し、ファン・ヤコブソン(ＶＪ：Ｖａｎ Ｊａｃｏｂｓｏｎ)、ＩＰヘッダ圧縮（ＩＰＨＣ：ＩＰ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）、および、ＣＲＴＰ（ｃｏｍｐｒｅｓｓｅｄ ｒｅａｌ−ｔｉｍｅ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ）のような、幾つかの一般に利用されるプロトコルが存在する。ヘッダ圧縮は、ヘッダ内の幾つかのフィールドがフロー内で変化しない、または、小さい、および／または予測可能な値で変化するという事実を利用する。ヘッダ圧縮スキームはこれら特徴を利用し、最初に静的な情報のみ送信する。一方、変化するフィールドは、パケットからパケットへと、その絶対値と共に送信される、または差分として送信される。完全にランダムな情報は、全く圧縮されずに送信される必要がある。

従って、ヘッダ圧縮は、音声およびビデオサービスのような、無線を介するＩＰサービスを経済的に実現可能にするための重要な要素である。ヘッダ圧縮の解決策は、このようなサービスの効率を改善するために、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）のロバストなヘッダ圧縮（ＲＯＨＣ：Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）作業グループによって開発されてきた。

他のタイプの圧縮のような他の最適化も、帯域幅が制限されたシステムの性能をさらに向上させるために利用されてもよい。これは、ペイロード圧縮と、シグナリング圧縮と、ヘッダ削除および再生成と、ヘッダ圧縮と、を含む。これら圧縮スキームの多くは、圧縮および／または伸張コンテキストを利用するために設計されてもよい。

新しいアーキテクチャモデルを利用する進化および設計は、無線インタフェースのより近くに最適化機能を移動させる傾向がある。例えば、ＳＡＥ／ＬＴＥ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ／Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）では、ヘッダ圧縮機能は、拡張ＮｏｄｅＢ（ｅＮＢ：ｅｎｈａｎｃｅｄ ＮｏｄｅＢ）に置かれている。他のシステムは、例えば、コアネットワーク（ＣＮ：Ｃｏｒｅ Ｎｅｔｗｏｒｋ）または無線ネットワークコントローラ（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）内にヘッダ圧縮機能を有する。

ほとんどのシステムでは、最適化（例えば、ヘッダ圧縮）を提供する機能を実行するノードを変更する移動イベントは、通常、この機能が再始動されることを必要とする。幾つかの例において、３ＧＰＰ仕様（ＲＲＣシグナリング）で定義されるように、これら機能のためのコンテキストの再配置がサポートされてもよい。コンテキスト（すなわち、最適化機能により利用される状態）の再配置は、可能な場合には、機能が一定レベルの効率を保持するため助けとなり、かつ通常では、機能により利用されるコンテキストを確立する全手続きを再始動する必要が無くなる。

ロバストなヘッダ圧縮（ＲＯＨＣ）
ヘッダ圧縮は多くの場合、コンテキスト（以下の定義を参照）内の圧縮されているフローに関する幾つかの状態情報を保持する、コンプレッサ・ステートマシーンとデコンプレッサ・ステートマシンとの相互作用として特徴付けられる。

ＲＯＨＣは、様々なプロトコルの圧縮のためのプロファイルが定義されてもよい、拡張可能なフレームワークである。実時間のマルチメディアサービス（例えば、音声、ビデオ）のために、アプリケーションデータが、ＩＰ／ＵＤＰ／ＲＴＰストリームで、エンド・ツー・エンドで伝送される。ＩＰ／ＵＤＰ／ＲＴＰのヘッダ圧縮は、ＲＯＨＣプロファイル０ｘ０００１（ＲＯＨＣ ＲＴＰ）およびＲｏＨＣｖ２プロファイル（０ｘ０１０１）により定義されており、他のサービスと並んで、ＶｏＩＰ（Ｖｏｉｃｅ−ｏｖｅｒ−ＩＰ）に適用可能である。

ＲＯＨＣヘッダ圧縮スキームは、任意のリンクレイヤを介してヘッダを効率良く圧縮する（ｃｏｍｐｒｅｓｓ）ために設計されてきた。交渉を除いて、ＲＯＨＣプロファイルは、リンクレイヤにより提供されるエラー検出およびフレミングを必要とし、一方、全他の機能は、ＲＯＨＣスキーム自体によって処理される。

複数のＲＯＨＣプロファイルが、以下の圧縮のために定義されている。
・圧縮なし、全ＩＰスタックの組み合わせ：プロファイル０ｘ００００、
・ＩＰ／ＵＤＰ／ＲＴＰヘッダ ：プロファイル０ｘ０００１、０ｘ０１０１、
：プロファイル０ｘ０００５、０ｘ０１０５、
・ＩＰ／ＵＤＰヘッダ ：プロファイル０ｘ０００２、０ｘ０１０２、
・ＩＰ／ＥＳＰヘッダ ：プロファイル０ｘ０００３、０ｘ０１０３、
・ＩＰ−ｏｎｌｙヘッダ ：プロファイル０ｘ０００４、０ｘ０１０４、
・ＩＰ／ＴＣＰヘッダ ：プロファイル０ｘ０００６、
・ＩＰ／ＵＤＰ−Ｌｉｔｅ／ＲＴＰヘッダ：プロファイル０ｘ０００７、０ｘ０１０７、
・ＩＰ／ＵＤＰ−Ｌｉｔｅヘッダ ：プロファイル０ｘ０００８、０ｘ０１０８．

圧縮をしないプロファイル（０ｘ００００）は、圧縮不可能であるが（ヘッダ・コンビネーションのタイプのためのプロファイルがない、または、圧縮（解除）のためのリソースが不足）、ＲｏＨＣチャネルを介する圧縮されたフローと共存するべきＩＰトラフィックのためにあることに注意されたい。このようなトラフィックのために、利用可能なリソースに余裕があれば、ＩＰ−ｏｎｌｙプロファイルが用いられてもよい。

ヘッダ圧縮ステートマシーンとコンテキストの同期化
通常では、（ＲＯＨＣプロファイルのような）ヘッダ圧縮スキームは、ステートマシーンとして認識することが可能であり、挑戦的な課題は、コンテキストと呼ばれる、コンプレッサの状態およびデコンプレッサの状態を、互いに一致させたまま保つ一方で、ヘッダのオーバーヘッドを可能な限り低く保つことである。コンプレッサのための１つのステートマシーンと、デコンプレッサのための１つのステートマシーンと、が存在する。コンプレッサ・ステートマシーンは、圧縮効率のレベルに直接的に影響を及ぼす。なぜならば、それは、送信されるべき圧縮されたパケットタイプの選択を制御するロジックの重要な部分であるからである。デコンプレッサ・ステートマシンの目的は、主に、（適用可能であれば）フィードバックのためのロジックを提供すること、および、圧縮が試みられてもよいパケットタイプを識別することである。

パケットタイプとコンテキスト更新
デコンプレッサが成功裏の圧縮を検証するための手段を提供するパケットは、コンテキスト更新パケット（ｃｏｎｔｅｘｔ−ｕｐｄａｔｉｎｇ ｐａｃｋｅｔ）である。伸張が検証可能なので、このタイプのパケットは、コンテキストを更新することが可能である。ＲＯＨＣについて、コンテキスト更新パケットタイプは、自身のフォーマットで巡回冗長コード（ＣＲＣ：Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｏｄｅ）を伝送する、すなわちこれは、元の圧縮されてないヘッダにわたって算出されたチェックサムである。このＣＲＣは、各パケットの成功裏の伸張を検証するために利用され、成功した場合には、コンテキストが更新可能である。

成功裏の伸張を保障するための他の手段に依拠するパケットは、すなはち、パケットフォーマットが、デコンプレッサが成功裏の伸張を検証するための手段を提供しないということであるが、伸張自体に必要な情報を伝送するパケットは、自己完結型（ｓｅｌｆ−ｃｏｎｔａｉｎｅｄ）パケットである。これらパケットはコンテキストを更新しない。

動作モード
Ｃａｒｓｔｅｎ Ｂｏｒｍａｎｎ，ｅｔ ａｌ.ＲＯｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）：Ｆｒａｍｅｗｏｒｋ ａｎｄ ｆｏｕｒ ｐｒｏｆｉｌｅｓ：ＲＴＰ，ＵＤＰ，ＥＳＰ ａｎｄ
ｕｎｃｏｍｐｒｅｓｓｅｄ．ＩＥＴＦ ＲＦＣ ３０９５，Ａｐｒｉｌ ２００１；Ｊｏｎｓｓｏｎ，Ｌ．ａｎｄ Ｇ．Ｐｅｌｌｅｔｉｅｒ，ＲＯｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）：Ａ ｃｏｍｐｒｅｓｓｉｏｎ ｐｒｏｆｉｌｅ ｆｏｒ ＩＰ，ＩＥＴＦ ＲＦＣ ３８４３，Ｊｕｎｅ
２００４、および、Ｐｅｌｌｅｔｉｅｒ，Ｇ．ＲＯｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）：Ｐｒｏｆｉｌｅｓ ｆｏｒ ＵＤＰ−Ｌｉｔｅ，ＩＥＴＦ ＲＦＣ ４０１９，Ａｐｒｉｌ ２００５において定義されるＲＯＨＣプロファイルは全て、３つの異なる動作モードをサポートする。簡単に言えば、特定コンテキストのために、モードが、実行するアクションおよびロジックと、ヘッダ圧縮動作の異なる状態の間に利用するパケットタイプと、を制御する。許容されるパケットタイプおよびフォーマットは、モードごとに異なってもよい。一方向モード（Ｕモード：Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ ｍｏｄｅ）は、他のモードへの任意の移行が起こる前に、任意のＲＯＨＳ圧縮の開始時に利用される。双方向楽観モード（Ｏモード：Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｍｉｓｔｉｃ ｍｏｄｅ）は、圧縮効率と、フィードバックチャネルのまばらな利用と、を最大限にすることを試みる。双方向信頼モード（Ｒモード：Ｂｉｄｉｒｅｃｔｉｏｎａｌ Ｒｅｌｉａｂｌｅ ｍｏｄｅ）は、損失の伝播およびコンテキストのダメージの伝播に対するロバスト性を最大限にすることを試みる。各動作モードは、圧縮効率、ロバスト性、および処理の複雑性の観点から異なるプロパティを有する。

Ｕモードでは、パケットは、コンプレッサからデコンプレッサへのみ送信される。すなわち、このモードは、デコンプレッサからコンプレッサへの返送経路が望まれない、または利用可能ではないリンクを介して、このように利用可能であり、周期的な最新化がこのモードで利用される。Ｕモードは、特に、チャネルをブロードキャストする、またはマルチキャストするために適応可能である。

ＯモードはＵモードと同様であるが、フィードバックチャネルが、エラー回復要求、および（任意に）重要なコンテキスト更新の肯定応答を、デコンプレッサからコンプレッサへと送信するために利用される点で異なっている。

ほとんどのＲＯＨＣプロファイルのために、ＵモードおよびＯモードは、多くの場合に暗に、Ｕ／Ｏモードという用語を用いて言及されることに注意されたい。これは、ＵモードおよびＯモードが、両モードのための同一のパケットフォーマット一式、および、コンテキスト更新を実行するための同様のロジックのような、やや類似した特徴を有することによる。このロジックは、楽観的アプローチと呼ばれており、Ｕ／Ｏモードでのコンテキスト更新手続きについてのパケット損失に対するロバスト性を供給する。

Ｒモードは、２つの他のモードと非常に異なっている。特に、Ｒモードは、このモードでのみ理解され、かつ有益な、幾つかの異なるパケットタイプを利用する。しかし、Ｒモードは、主に、フィードバックチャネルをより幅広く利用することが異なっており、かつ、コンテキスト更新を実行するためのより厳密なロジックを利用する。このロジックは、確実な参照の原則(ｓｅｃｕｒｅ ｒｅｆｅｒｅｎｃｅ ｐｒｉｎｃｉｐｌｅ)に基づいており、Ｒモードでのコンテキスト更新手続きについてのパケット損失に対するロバスト性を提供する。

ロバストなヘッダ圧縮におけるロバスト性の原則−楽観的アプローチ
ヘッダ・コンプレッサは、コンテキスト更新を実行する際のヘッダのオーバーヘッドを低減するために、楽観的なアプローチを利用してもよい。コンプレッサは、通常では、デコンプレッサが情報の受信に成功したことをかなり確信するまで、同じ更新を繰り返す。この確信を得るために必要な、連続するパケットの数は、典型的に実装次第であり、この数は、通常では、ヘッダ圧縮が利用されるリンクのパケット損失の特徴に関連する。楽観的アプローチにより利用されるパケットタイプは全て、コンテキスト更新型である。

コンプレッサは、通常では、自身が送信する各パケットについての自身の圧縮コンテキストを更新する。

ヘッダ・コンプレッサは、通常では、伸張の結果の検証後に、（楽観的アプローチを利用した動作の際にパケットフォーマットに常に存在する）圧縮されたヘッダで伝送されるＣＲＣを利用して、自身のコンテキストを更新する。

ロバストなヘッダ圧縮におけるロバスト性の原則−確実な参照の原則
ヘッダ・コンプレッサは、パケット損失によっても失われえない、コンプレッサとデコンプレッサとの間のこのコンテキストの同期化を保証するために、確実な参照の原則を利用してもよい。コンプレッサは、デコンプレッサにより受信された肯定応答に基づいて、デコンプレッサがコンテキスト更新パケットからコンテキストを成功裏に更新したという自身の確信を得る。確実な参照の原則により利用されるパケットタイプは、自己完結型であり、従ってコンテキストを更新することを意図されていない。

コンプレッサは、通常では、（フィードバックメッセージ内のＭＳＮを利用して識別される）コンテキスト更新パケットのために、デコンプレッサから肯定応答を受信した後にのみ、自身の圧縮コンテキストを更新する。

デコンプレッサは、通常では、圧縮されたヘッダ内で伝送されるＣＲＣ（パケットフォーマット内に存在する場合、確実な参照の原則を利用した動作の際には必ずしも当てはまらない）を利用して、伸張の結果の検証後に自身のコンテキストを更新する。レート制限に従って、デコンプレッサは通常、コンプレッサに更新を肯定応答する。

ＲｏＨＣの現在の状況
「簡略化されたＲＯＨＣフレームワーク」、または独立した文書としてのＲＯＨＣフレームワークの仕様書が、ＩＥＴＦ ＲＦＣ４０９５として公表されている。

現在開発されているＲｏＨＣｖ２プロファイルは、他の改善の他に、圧縮エンドポイント間での障害のある配信に対処する。

新アーキテクチャにおける現在の傾向および進化
ＧＳＭ／ＥＤＧＥシステムでは、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）が、通常、ヘッダ圧縮機能を主に果たす。

ＵＴＲＡＮアーキテクチャでは、無線ネットワーク制御（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌ）機能が、ヘッダ圧縮機能を主に果たす。

対照的に、ＳＡＥ／ＬＴＥアーキテクチャはＲＮＣを有していない。本来は、このアーキテクチャは、ヘッダ圧縮機能がアクセスゲートウェイ（ａＧＷ：Ａｃｃｅｓｓ Ｇａｔｅｗａｙ）のＰＤＣＰ内に置かれることを特定したが、後に、ＰＤＣＰ機能は、ｅＮＢに移された。この決定の影響は、起動イベントが、ヘッダ圧縮の観点から、ａＧＷ内に置かれる場合よりも頻度が高いことである。圧縮の再始動は、複数の圧縮されていないヘッダが送信されることを必要とし、このことは、十分に効率的ではないことがある。圧縮コンテキストの再配置のような、より進化した仕組みが必要とされることがある。

ヘッダ圧縮のためのコンテキストの再配置の構想は新規ではない。ＵＴＲＡＮにおいてコンテキストの再配置を適切にサポートするために、複数の従来技術が存在する。しかし、圧縮コンテキストは、１つの点から他の点へと幾らかのデータを転送するというだけの問題ではない。すなわち、例えば、圧縮コンテキストの全転送を説明するためには１つのＩＰヘッダを転送するだけで十分であると、多くの場合に考えられている。どのタイプのデータが、どのフォーマットで、どのように、ヘッダ圧縮アルゴリズムと相互作用する再配置工程を有するかということは非常に複雑な問題であり、従来技術のより詳細な分析が明らかにする問題が、適切に取り上げられていない。

１つの従来技術のアプローチが、複数のネットワークエンティティと、移動コンプレッサおよび／または移動デコンプレッサとの間で、ヘッダ圧縮／伸張機能を再配置する方法を開示した米国特許第６３００８８７号明細書に示されている。この方法は、確実な参照に依拠しており、かつ、絶対的なデコンプレッサ／コンプレッサのコンテキストの同期化に依拠している。さらに、コンプレッサとデコンプレッサとの間の（明示的な、または、待たれる）特定のコンテキストの同期化イベントを必要とし（例えば、肯定応答（ａｃｋ）およびコンテキストＩＤ／ＳＮによるデコンプレッサのフィードバック）、再配置の時点での（全ての、または部分的な）コンテキストについての有効性の特定の状態に依存する。さらに、一般的に、自身のコンテキストを絶えず更新するヘッダ圧縮アルゴリズムには適用可能ではなく（例えば、「ＲｏＨＣ Ｕ／Ｏモード」の動作タイプ）、Ｒモードにのみ適用可能である。さらに、
・全情報交換は、再配置の時点でのフローの状態に依存する。すなわちコンテキストは、
−パケットが利用可能である限り、および、
−フィードバックチャネルがアクティブである限り、および、
−コンテキストが有効である限り、
再配置不可能である
・コンプレッサのコンテキストとデコンプレッサのコンテキストとの間の同期化にのみ焦点を置いている
・コンテキストが再配置された後には、ソースでの圧縮は不可能である（ハードなハンドオフ）

他の従来技術のアプローチが、圧縮されたヘッダを有するパケットを送信するパケットネットワークにおいてヘッダ圧縮コンテキストを再配置する方法を開示した米国特許出願公開２００２９１８６０号明細書に示されている。再配置は、以下のことによりコンテキストの更新を停止させることに基づいている。
−デコンプレッサがフィーバックの送信を停止させる
−再配置の開始の際に、コンプレッサが圧縮されていないパケットを送信する
−コンプレッサが、デコンプレッサにより受信されるフィードバックを無視する

従って、最新技術は、以下のことを必要とする。
・ソースノードでの圧縮が停止されること。これにより、コンテキストは、ダウンリンクについてのソースコンプレッサとターゲットコンプレッサとの間で（または、アップリンクについてのデコンプレッサがそれぞれ）同期して凍結される。すなわち、手続きの同期化される観点は、最初に圧縮を停止させることにより、無線アクセスネットワーク（ＲＡＮ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）におけるコンテキスト情報の交換を同期させることに焦点を置いている。
・ソースが、再配置のために、ＵＥ内のコンテキストの状態に絶対的な確信を持つこと。すなわち、再配置は、肯定応答されたコンテキストのみ再配置可能であるという前提条件に基づいており、このことは必ずしも時宜｛じぎ｝に適っていない。

最新技術の上記の特徴の影響は、移動イベントの間の中断時間を最小限にすることが不可能なことであり、かつ、圧縮を停止させる結果、パケットがソースノードから送信不可能なことである。再配置は、コンテキストを準備するため幾らか追加的に遅延すること無しには、かつ、デコンプレッサからの肯定応答を待つこと無しには可能ではない可能性がある。

今日では、コンテキストの再配置の仕組みが以下のようなプロパティを有することを可能にする、作業中の解決策が存在しない。すなわち、
・（そこからコンテキストが得られる）ソースノードが、再配置されるコンテキスト情報が抽出されターゲットノードへと送信された後にも（すなわち、移動イベントの間に）、パケットの圧縮および送信を継続することを可能にするプロパティ、
・ターゲットノードが、ソースノードからコンテキストを受信した後に、自身が圧縮を開始する第１パケットから、最も効果的な比率で圧縮を再開することを可能にするプロパティ、
・相互運用的にコンテキストを再配置するプロパティ。すなわち、肯定応答および確実な参照（楽観的アプローチに依拠したアルゴリズム）に厳密に依拠しない圧縮アルゴリズムに基づく、コンテキストの再配置、
・再配置工程が、圧縮コンテキストの寿命の任意の時点に開始することを可能にするプロパティ。

本明細書で提案する発明が取り組む主な問題は、ハンドオーバ手続きのスペクトル効率と、中断時間を最小にすることとを改善するために、どのようにして、移動イベントの間にヘッダ圧縮コンテキストを適切に再配置するのか、ということである。

本発明が取り組む更なる問題は、肯定応答（および確実な参照）に厳密には基づかないヘッダ圧縮アルゴリズムのために、コンテキストの再配置を可能にすること、ソースノードが、移動イベントにおいてもパケットの圧縮および送信を継続することを可能にすること、ｅＮＢが、早期に再配置を開始すること、または自身のキューを空にすること、および／または任意の保留中の送信を完了することを可能にすること、および、移動端末を含まずに、いずれの任意の時間にも再配置の手続きを開始することを可能にすること、である。

従って、先に述べた問題の少なくとも１つを克服する方法および装置が必要である。

従って、本発明の１つの目的は、通信ネットワークシステムにおいて、移動イベントの間にソース通信ネットワークノードからターゲット通信ネットワークノードへと、データパケットのヘッダ圧縮コンテキストを再配置する改善された方法であって、上記圧縮されたヘッダを含む上記データパケットが、無線インタフェースを介して、最初に上記ユーザ機器内の圧縮エンドポイントと上記ソース通信ネットワークノード内の圧縮エンドポイントとの間で送信され、上記移動イベントの後に、上記ユーザ機器内の圧縮エンドポイントと上記ターゲット通信ネットワークノード内の圧縮エンドポイントとの間で送信される、上記再配置方法を提供することである。

本発明の第１の観点に従って、本目的は、再配置工程の間に各個々のヘッダのコンテキスト更新プロパティを無効化する工程を含む方法により、ヘッダ圧縮コンテキストが効率良く再配置されることを特定する、特許請求の範囲に記載の請求項１の特徴部によって達成される。

本発明の他の目的は、通信ネットワークシステムにおいて、移動イベントの間にソース通信ネットワークノードからターゲット通信ネットワークノードへと、データパケットのヘッダ圧縮コンテキストを再配置するための改善された装置であって、上記圧縮されたヘッダを含む上記データパケットが、無線インタフェースを介して、最初に上記ユーザ機器内の圧縮エンドポイントと上記ソース通信ネットワークノード内の圧縮エンドポイントとの間で送信され、上記移動イベントの後に、上記ユーザ機器内の圧縮エンドポイントと上記ターゲット通信ネットワークノード内の圧縮エンドポイントとの間で送信される、上記装置を提供することである。

本発明の第２の観点に従って、この他の目的は、再配置工程の間に各個々のヘッダのコンテキスト更新プロパティを無効化するための手段を含む装置により、ヘッダ圧縮コンテキストが効率良く再配置されることを特定する、特許請求の範囲に記載の請求項１６の特徴部によって達成される。

本発明のさらなる目的は、通信ネットワークシステムにおいて、移動イベントの間にソース通信ネットワークノードからターゲット通信ネットワークノードへと、データパケットのヘッダ圧縮コンテキストを再配置する、ユーザ機器内の改善された方法であって、上記圧縮されたヘッダを含む上記記データパケットが、無線インタフェースを介して、最初に上記ユーザ機器内の圧縮エンドポイントと上記ソース通信ネットワークノード内の圧縮エンドポイントとの間で送信され、上記移動イベントの後に、上記ユーザ機器内の圧縮エンドポイントと上記ターゲット通信ネットワークノード内の圧縮エンドポイントとの間で送信される、上記方法を提供することである。

本発明の第３の観点に従って、この更なる目的は、再配置工程の間に各個々のヘッダのコンテキスト更新プロパティが無効化される場合に、再配置工程の間に上記ソース通信ネットワークノードから、更新無しとしてマーク付けされたデータパケットを受信する工程を含む方法により、ヘッダ圧縮コンテキストが効率良く再配置されることを特定する、特許請求の範囲に記載の請求項３１の特徴部によって達成される。

本発明のさらに別の目的は、通信ネットワークシステムにおいて、移動イベントの間にソース通信ネットワークノードからターゲット通信ネットワークノードへと、データパケットのヘッダ圧縮コンテキストを再配置するための改善されたユーザ機器であって、上記圧縮されたヘッダを含む上記データパケットが、無線インタフェースを介して、最初に上記ユーザ機器内の圧縮エンドポイントと上記ソース通信ネットワークノード内の圧縮エンドポイントとの間で送信され、上記移動イベントの後に、上記ユーザ機器内の圧縮エンドポイントと上記ターゲット通信ネットワークノード内の圧縮エンドポイントとの間で送信される、上記ユーザ機器を提供することである。

本発明の第４の観点に従って、このさらに別の目的は、再配置工程の間に各個々のヘッダのコンテキスト更新プロパティが無効化される場合に、再配置工程の間に上記ソース通信ネットワークノードから、更新無しとしてマーク付けされたデータパケットを受信するように構成される受信機を含むユーザ機器により、ヘッダ圧縮コンテキストが効率良く再配置されることを特定する、特許請求の範囲に記載の請求項３２の特徴部によって達成される。

更なる実施形態は、特許請求の範囲に記載の従属請求項において記載される。

送信元通信ネットワークノードが再配置工程の間にユーザ機器へとデータパケットを送信し続ける間、各個々のヘッダのコンテキスト更新プロパティを無効化する方法および装置の提供のおかげで、再配置の間に圧縮が継続するので、ハンドオーバにおける中断時間が最小限になる。さらに、ターゲット通信ネットワークノードが、最も効率が良い圧縮比率で第１パケットから開始することが可能になる、すなわち、ハンドオーバの間のスペクトル効率が最適化される。本発明は、ＮＡＣＫに基づくヘッダ圧縮、例えば、ＲｏＨＣ Ｕ／Ｏモードとも良好に機能にする。

本発明で新規であると考えられることは、以下のことである。すなわち、
・従来技術における再配置のエンドポイントに基づくのではなく、圧縮のエンドポイントに基づいてコンテキストの再配置を同期させること。すなわち、このことは、圧縮エンドポイント間での肯定応答に基づかないコンテキストの再配置工程を可能にする。さらに、ソースでの圧縮が、再配置工程中も継続することを可能にする。
・上記のことを可能にするための方法、および、再配置の間に交換される情報タイプ。

本発明は、楽観的アプローチに基づくヘッダ圧縮アルゴリズムに適用可能であり、
・ヘッダ圧縮のための確実な参照に依拠しない
・絶対的なデコンプレッサ／コンプレッサのコンテキストの同期化に依拠しない
・コンプレッサとデコンプレッサとの間のいずれの（明示的な、または待たれる）特定のコンテキストの同期化イベント（例えば、ＲｏＨＣ ＡＣＫ）も必要としない
・再配置時点に（全ての、または部分的な）コンテキストについての有効性の特定の状態に依存しない
・絶えず自身のコンテキストを更新するヘッダ圧縮アルゴリズムに一般的に適用可能である（例えば、ＲｏＨＣ Ｕ／Ｏモードの動作タイプ）

さらに、本発明は、コンテキストが「凍結された」（“ｆｒｏｚｅｎ”）後に、およびコンテキストが再配置されている間に、圧縮が、ソースノードにおいてロバストに継続することを可能にし、
・トラフィックは、再配置／ハンドオーバのセットアップの間に流れ続けてもよい
・再配置は、ハンドオーバより前に、性能に対する影響を最小に抑えて、かつ中断することなく実行可能である。

本発明のさらに他の目的および特徴は、添付の図面と関連して検討される、以下の詳細の記載から明らかとなろう。しかし、図面は、単に図示することを目的としており、添付の請求項の範囲が参照される本発明の限定を定義するものとして作成されていないことを理解されたい。当然のことながら、図面は、必ずしも縮尺どおりに描かれておらず、他に示されていない限り、単に、本明細書に記載される構造および手続きを概念的に図示するものとする。

定義
ヘッダ圧縮コンテキスト
圧縮コンテキストは、過去のパケットについての関連情報を含み保持し、この情報は、後続のパケットを圧縮する、および伸張するために利用される。Ｃａｒｓｔｅｎ
Ｂｏｒｍａｎｎ，ｅｔ ａｌ.ＲＯｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ(ＲＯＨＣ)：Ｆｒａｍｅｗｏｒｋ ａｎｄ ｆｏｕｒ ｐｒｏｆｉｌｅｓ：ＲＴＰ，ＵＤＰ，ＥＳＰ ａｎｄ
ｕｎｃｏｍｐｒｅｓｓｅｄ．ＩＥＴＦ ＲＦＣ ３０９５，Ａｐｒｉｌ ２００１から、以下のように引用する。

「コンプレッサのコンテキストは、コンプレッサがヘッダを圧縮するために利用する状態である。デコンプレッサのコンテキストは、デコンプレッサがヘッダを伸張するために利用する状態である。これら双方、または、この２つの組み合わせは、通常、どちらを意図するのか明確な場合に「コンテキスト」と呼ばれる。コンテキストは、静的フィールド、ならびに、圧縮および伸張のための可能な参照値のような、パケットストリームにおける以前のヘッダからの関連する情報を含む。さらに、パケットストリームを記述する追加的な情報、例えば、ＩＰ識別子フィールド、および、シーケンス番号またはタイムスタンプのパケット間における典型的な増加が、どのように変化するのかについての情報もコンテキストの一部である。

圧縮は、デコンプレッサのコンテキストが、この状態の、コンプレッサが有する観点と同期される限り可能である。そうでない場合には、コンプレッサは、通常、不一致を修復するためのロジックおよびパケットタイプ選択を開始する。

図面では、同様の参照部号は、幾つかの図を通して同様の要素を示す。
ＷＣＤＭＡ通信ネットワークアーキテクチャの例を示す。 ＬＴＥ通信ネットワークアーキテクチャの例を示す。 本発明に従った、一般的な手続きにおいて実行される工程のフローチャートである。 本発明に従った、コアネットワーク内のＬＴＥのためのシグナリングの例を示す。 本発明に従った、ｅＮＢ内のＬＴＥのためのシグナリングの例を示す。 最小位ビットの符号化の解釈間隔を示す。 最小位ビットで符号化されるスライドウィンドウを示す。 最小位ビット以外で符号化されるスライドウィンドウを示す。 再配置コンテナを示す。 進歩的なユーザ機器および通信ネットワークノードの簡略化されたブロック図である。

図１は、広帯域符号分割多重アクセス（ＷＣＤＭＡ：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）システムのような、通信システムを示している。当該通信システムは、ＵＭＴＳ地上波無線アクセスネットワーク（ＵＴＲＡＮ：ＵＭＴＳ
Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）アーキテクチャのような、無線アクセスネットワーク（ＲＡＮ：Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）を含む。当該無線アクセスネットワークは、１つ以上の無線ネットワークコントローラ（ＲＮＣ：Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ）１０（図１では１つだけ示される）に接続された、少なくとも１つの無線基地局（ＲＢＳ：Ｒａｄｉｏ Ｂａｓｅ Ｓｔａｔｉｏｎ）(またはＮｏｄｅＢ)１５ａ〜ｂを含む。ＲＡＮは、インタフェースを介してコアネットワーク（ＣＮ：Ｃｏｒｅ ｎｅｔｗｏｒｋ）１２に接続されており、このコアネットワーク１２は、公衆交換電話網（ＰＳＴＮ：Ｐｕｂｌｉｃ
Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）、または、総合デジタル通信網（ＩＳＤＮ：Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）のような、接続型の外部ＣＮであってもよく、および／または、インターネットのような無接続の外部ＣＮであってもよい。

ＲＡＮおよびＣＮ１２は、複数のユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）１８ａ〜ｄのための通信と制御を提供する。ＵＥ１８はそれぞれ、無線または無線インタフェースを介して少なくとも１つのＲＢＳ１５と通信するために、ダウンリンク（ＤＬ：ｄｏｗｎｌｉｎｋ）チャネルおよびアップリンク（ＵＬ：ｕｐｌｉｎｋ）チャネルを利用する。

ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムのような、他の通信システムが図２に示されている。上記他の通信システムは、無線基地局（ＲＢＳ）（またはｅＮｏｄｅ）１５ａ、１５ｂ、および１５ｃのうちの少なくとも１つを含む、無線アクセスネットワーク（ＲＡＮ）を含んでいる。ＲＡＮは、Ｓ１インタフェース２７のようなインタフェースを介して、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０ａと２０ｂの少なくとも１つに接続されており、このＥＰＣは、（図２に示されない）公衆交換電話網（ＰＳＴＮ）または総合デジタル通信網（ＩＳＤＮ）のような外部ネットワーク、および／またはインターネットのような無接続の外部ネットワークに接続されている。各ＥＰＣ２０ａおよび２０ｂは、例えば、移動のためのインスタンスについて制御シグナリングを処理するＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）ゲートウェイと、ＵＰＥ（Ｕｓｅｒ Ｐｌａｎｅ Ｅｎｔｉｔｙ）と、を含んでいる。

ＲＡＮは、（図２では１つだけ示される）複数のユーザ機器（ＵＥ）１８のための通信および制御を提供し、各ＲＢＳ１５ａ〜１５ｃは、ＵＥ１８がそれを通じて、およびその内部で移動する少なくとも１つのセル２９において、サービスを提供する。ＲＢＳ１５ａ〜１５ｃは、Ｘ２のような通信インタフェース２６を介して互いに通信する。ＵＥはそれぞれ、無線または無線インタフェースを介して少なくとも１つのＲＢＳと通信するために、ダウンリンク（ＤＬ）チャネル２２およびアップリンク（ＵＬ）チャネル２３を利用する。

本発明の好適な実施形態によれば、通信システムは、本明細書ではＷＣＤＭＡシステムおよびＬＴＥシステムとして記載される。しかし、当業者は、進歩的な方法および構成が、Ｗｉｍａｘのような全通信システムにおいて良好に機能することが分かる。ユーザ機器１８は、移動電話（「セルラ」電話）、および移動端末付きのラップトップのような移動局であってもよく、従って、例えば、ＲＡＮによって音声および／またはデータを通信する、携帯機器、小型装置、手持ち型機器、コンピュータ内蔵型または車載型移動機器であることも可能である。

本発明の基本的な構想は、ハンドオーバ手続きのような移動イベントの間に、圧縮されたパケットを更新無し（ｎｏｎ−ｕｐｄａｔｉｎｇ）としてマーク付けし、これにより、再配置のソースが含まれる際の圧縮エンドポイント間での再配置工程中に、各個々のヘッダ圧縮されたパケットタイプの更新プロパティを無効化し、さらに、再配置のターゲットでの再配置の完了後に圧縮されたヘッダのコンテキスト更新プロパティを復元することである。他の構想は、ターゲット圧縮エンドポイントを最も効率の良い圧縮率で直接的に開始させることを可能にするために、特定のヘッダ圧縮コンテンツを交換することである。コンプレッサのコンテキストの再配置の際には、この情報は、主に２つの「構成された」（“ｃｏｎｓｔｒｕｃｔｅｄ”）参照ヘッダ、すなわち、選択された情報を含むスライディングウィンドウ（ｓｌｉｄｉｎｇ ｗｉｎｄｏｗ）、このウィンドウに適用される有効性マスクから成る。デコンプレッサのコンテキストの再配置の際には、この情報は、主に、１つの参照ヘッダと、この参照ヘッダのフィールドのための有効性マスクと、から成る。

本発明の好適な実施形態によれば、図３に示されるような、データパケットのヘッダ圧縮コンテキストを効率良く再配置するための概略的な手続きは、以下のとおりである。
・ソースｅＮＢのようなソース通信ネットワークノードが、データパケットのヘッダを圧縮し、ヘッダが圧縮されたデータパケットを、ダウンリンクチャネルでユーザ機器へと送信し、ヘッダ圧縮コンテキストを更新する（ステップ３１）
・ハンドオーバの決定がソースｅＮＢによって行なわれる場合のように、移動イベントが起きた場合には、ソースｅＮＢから、ターゲットｅＮＢのようなターゲット通信ネットワークノードへの、ヘッダ圧縮コンテキストの再配置を開始する（ステップ３２）
・ソースｅＮＢは、ヘッダを圧縮し、データパケットをＵＥに送信することを継続するが、再配置工程の間は各個々のヘッダのコンテキスト更新プロパティを無効化する（ステップ３３）
・ターゲットｅＮＢへの再配置工程を終了する（ステップ３４）
・ターゲットｅＮＢにおいてコンテキスト更新プロパティを復元する（ステップ３５）
・ターゲット・ソースｅＮＢは、データパケットのヘッダを圧縮し、ヘッダが圧縮されたデータパケットをダウンリンクチャネルでユーザ機器へと送信し、ヘッダ圧縮コンテキストを更新する（ステップ３６）

以下では、本発明の実施形態が、背景技術で記載したようなコンプレッサおよびデコンプレッサの振る舞いを含むＲｏＨＣプロファイルに基づいて記載されるが、本発明の実施形態は、上記ＲｏＨＣプロファイルに限定されない。

移動の間の、更新無しとしての圧縮されたパケットのマーク付け
上記のように、本発明の１つの基本的構想は、再配置工程中に、各個々のヘッダ圧縮されたパケットタイプの更新プロパティを無効化することである。

更新無しパケット（ｎｏｎ−ｕｐｄａｔｉｎｇ Ｐａｃｋｅｔ）は、パケットを伸張する（ｄｅｃｏｍｐｒｅｓｓ）ためにデコンプレッサが利用するデコンプレッサの状態に対する、いずれの変化も招かない：
・パケットがコンテキスト更新型であるか否かは、典型的に、仕様書に定義される各パケットフォーマットのプロパティに関連し、例えばＲＯＨＣでは、フォーマットが元の圧縮されていないヘッダを介してＣＲＣを伝送するか否かがそうである（このＣＲＣは、デコンプレッサが伸張の試みの結果を検証することを可能にする）。ＣＲＣが存在するとしても、パケットタイプ識別子に依存することもある。
・圧縮エンティティが、同じフローのための次のパケットを処理する際に自身が利用する状態を修正するために、自身が正に処理した（圧縮した、または伸張した）パケット内の情報を利用する場合に、コンテキストが更新されると言われる。コンプレッサは、自身がコンテキスト更新型の（例えばＣＲＣを有する）パケットフォーマットを選択する場合に、自身の状態を更新することが可能である。理想的にはデコンプレッサでは、この状態が、正確にはＣＲＣを用いた伸張の試みの検証によって、検証されているべきである。

移動イベントの間の、例えばハンドオーバの手続きが開始する場合の好適な実施形態によれば、圧縮されたパケットは、以下の方法で、更新無しとしてマーク付けされる。
・ダウンリンクにおいて：ソースコンプレッサの出力が、ユーザ機器内のデコンプレッサのコンテキストのために、更新無しとしてマーク付けされる。この標識は、移動イベントの間、すなわち、ソースｅＮＢ内のソースコンプレッサから発せられる各圧縮されたパケットのために伝送される、または適用される。
・アップリンクにおいて：ユーザ機器内のコンプレッサの出力は、すなわち、ソースｅＮＢ内のソースコンプレッサにおけるデコンプレッサのコンテキストのために、更新無しとしてマーク付けされる。この標識は、移動イベントの間、コンプレッサから発せられる各圧縮されたパケットのために伝送される、または適用される。

マーク付けは、例えば、圧縮プロトコルフォーマット内、すなわち、レイヤ２プロトコル（例えば、ＰＤＣＰヘッダ）内のインジケータであってもよい、または、シグナリングを利用しての状態の確立によって適用されてもよい、もしくは、両圧縮エンドポイントでの移動シグナリングから（黙示的に）得られてもよい。従って、個々のパケットは、ヘッダ圧縮プロトコル内の帯域内信号、ヘッダ圧縮をサポートするプロトコル内の信号、異なるレイヤ２のカプセル化、例えば（楽観的アプローチまたはフィードバックを用いた）制御フィールドの更新による、上記デコンプレッサの修正された状態、を利用してマーク付けされる。

送信元コンプレッサは、フローのための好適なコンテキスト情報をターゲットコンプレッサへと送信する。このことを、以下により詳細に記載する。

移動イベント、すなわち、ハンドオーバの手続きが完了している場合：
・ダウンリンクにおいて：ソースコンプレッサはパケットの処理を停止している。パケットのマーク付けなしに、ターゲットコンプレッサは、再配置されたコンテキストを利用して作業を開始する（すなわち、圧縮が、圧縮されたヘッダについての通常の更新プロパティによって再開する）。
・アップリンクにおいて：パケットのマーク付けなしに、ユーザ機器内のコンプレッサの出力が再開する（すなわち、圧縮が、圧縮されたヘッダについての通常の更新プロパティによって再開する）。

各個々のヘッダのコンテキスト更新プロパティは、再配置工程の後に、すなわち、好適には、デコンプレッサのフィードバックに基づく３方向ハンドシェイクを利用することによって、圧縮チャネルのエンドポイントがターゲット通信ネットワークノードへと動かされ、かつアクティブになる場合に、ハンドオーバの完了後に（例えば最初の）伸張成功の肯定応答を用いて、圧縮されたヘッダのコンテキスト更新プロパティを活性化／非活性化するためにコンテキストの状態が利用される場合に、復元される。

ＲｏＨＣ Ｕ／Ｏモードによって、コンプレッサのコンテキストは、通常では常に更新されるが、このことは、典型的に全パケットタイプが、デコンプレッサのコンテキストを更新してもよいことを意味している。しかし、デコンプレッサのコンテキストは、ＣＲＣが成功した場合にのみ更新され、すなわち、デコンプレッサのコンテキストが更新されない場合があることを意味している。

本発明の好適な実施形態によれば、制御通信ネットワークエンティティは、再配置の目的で更新プロパティを無効化する、または復元するために、再配置されるエンドポイントへとシグナリングする。さらに、ネットワーク部におけるコンテキストの再配置は、ユーザ機器を含まずに、好適にＸ２インタフェース上で互いに同期させられる。

ＰＤＣＰがコアネットワーク内にある場合の実施形態についての、ＬＴＥ通信ネットワークシステムのためのシグナリングの例が、図４に示されている。図４の破線の矢印はユーザデータを表し、シグナリングは、ユーザ機器１８と、ソース通信ネットワークノード（ソースｅＮＢ）１５ａと、ターゲット通信ネットワークノード（ターゲットｅＮＢ）１５ｂと、ＥＰＣ（ＭＭＥ／ＵＰＥ）２０と、の間である。

図４では、ＵＥ１８へと伝送されるユーザパケットデータが、ＭＭＥ／ＵＰＥ２０からソースｅＮＢ１５ａへと送信される。ソースｅＮＢ１５ａは、ＵＥ１８へデータを転送し、ＵＥ１８へＵＬ割り当てを送信する。ＵＥ１８は、４１で示されるように、送信元ｅＮＢ１５ａへ連続して測定報告を送信する。測定報告が通信の質が下がっていることを示す場合には、ソースｅＮＢ１５ａは、ターゲットｅＮＢ１５ｂによりサービスが提供されているセルへとＵＥ１８を移動させるために、ハンドオーバの決定を行なう。ソースｅＮＢ１５ａは、４２で、更新無しとしてマーク付けされたデータパケット（ＰＤＣＰ／ＨＣ ｎｏ＿ｕｐｄａｔｅ）の送信を開始し、４３で、ターゲットｅＮＢ１５ｂへとコンテキストのデータ（ＵＥ ＲＡＮ ｃｏｎｔｅｘｔ）を送信する。ＰＤＣＰ／ＨＣ ｎｏ＿ｕｐｄａｔｅは、ＨＯ命令を、ソースｅＮＢ１５ａからターゲットｅＮＢ１５ｂへのＸ２メッセージに結び付けることに黙示的に基づいてもよい。ターゲットｅＮＢ１５ｂは、ＵＥ ＲＡＮコンテキストを格納し、Ｃ−ＲＮＴＩを予約し、４４で、ソースｅＮＢ１５ａへと、コンテキスト確認（新Ｃ−ＲＮＴＩ）メッセージを送信する。ソースｅＮＢ１５ａは、ＵＥ１８へとＤＬ割り当てをシグナリングし、４５で、ハンドオーバ命令（新Ｃ−ＲＮＴＩ）を送信する。ＵＥ１８は旧セルから離れ、新セルと同期する。ソースｅＮＢ１５ａは、バッファリングされた、および移動中のパケットを、ターゲットｅＮＢ１５ｂへと伝送し、ターゲットｅＮＢ１５ｂは、ソースｅＮＢ１５ａから受信されたパケットをバッファリングする。その後、ＵＥ１８は、４６で、ターゲットｅＮＢ１５ｂと同期し、ターゲットｅＮＢ１５ｂからＵＬ割り当て、および時間割り当て（ＴＡ：ｔｉｍｅ ａｌｉｇｎｍｅｎｔ）を受信する。次に、ＵＥ１８は、４７で、ターゲットｅＮＢ１５ｂへハンドオーバ確認メッセージを送信する。ターゲットｅＮＢ１５ｂは、４８ａで、ソースｅＮＢ１５ａへハンドオーバ完了メッセージを送信し、４８ｂで、ＭＭＥ／ＵＰＥ２０へＵＥ更新メッセージを送信する。ＭＭＥ／ＵＰＥは、経路交換を行い、ソースｅＮＢ１５ａの代わりにターゲットｅＮＢ１５ｂへと、ユーザパケットデータを送信する。ソースｅＮＢ１５ａは、ＭＭＥ／ＵＰＥ２０が経路交換を実行していない限り、ＤＬバッファをフラッシュし、ターゲットｅＮＢ１５ｂへと、ＭＭＥ／ＵＰＥ２０から受信された移動中のパケットを伝送し続ける。その後、ターゲットｅＮＢ１５ｂは、４９で、マーク付けされていないユーザパケットデータ（ＰＤＣＰ／ＨＣ ｕｐｄａｔｅ）の送信を開始し、このことも黙示的であってもよい。

ＰＤＣＰがｅＮＢ内にあるＬＴＥ通信ネットワークシステムの、他の実施形態に従ったシグナリグの仕組みが、図５に示されている。ユーザデータおよびシグナリングは、ユーザ機器１８と、ソース通信ネットワークノード（ソースｅＮＢ）１５ａと、ターゲット通信ネットワークノード（ターゲットｅＮＢ）１５ｂと、ＥＰＣ（ＭＭＥ／ＵＰＥ）２０と、の間で送信される。

ＵＥは、５１で示されるように、ソースｅＮＢ１５ａへと連続して測定報告を送信する。送信報告が通信の質が下がっていることを示す場合には、ソースｅＮＢ１５ａは、ターゲットｅＮＢ１５ｂによりサービスが提供されているセルへとＵＥ１８を移動させるために、ハンドオーバの決定を行ない、５２で、ターゲットｅＮＢ１５ｂへハンドオーバ要求メッセージを送信する。ターゲットｅＮＢ１５ｂはリソース予約を行い、５３で、ハンドオーバ要求確認メッセージを、ソースｅＮＢ１５ａへと返送する。ソースｅＮＢ１５ａはハンドオーバ命令５４を処理し、ＵＥ１８へと送信する。ソースｅＮＢ１５ａは、５５で、ＵＥ１８への、更新無しとしてマーク付けされたデータパケット（ＰＤＣＰ／ＨＣ ｎｏ＿ｕｐｄａｔｅ）の送信を開始し、受信されたユーザパケットデータをターゲットｅＮＢ１５ｂへと転送する。ＵＬ／ＤＬデータ双方は、最後のＴＴＩで送信されてもよい（エラーの場合、パケットはターゲットセル内で再送信される）。その後、ＵＥ１８はターゲットｅＮＢ１５ｂに切り替え、専用プリアンブルを利用してランダムアクセスメッセージ５６を送信する。ターゲットｅＮＢ１５ｂは、（ハンドオーバ完了およびＵＬデータのための）時間割り当て／スケジューリング付与メッセージ５７を処理し、ＵＥ１８へと送信する。ＤＬデータは、メッセージ５７の直後のＴＴＩにおいて送信される。ＵＥ１８は、ハンドオーバ完了メッセージ５８を処理し、ターゲットｅＮＢ１５ｂへと送信する。ターゲットｅＮＢ１５ｂは、ＭＭＥ／ＵＰＥ２０へと経路切り替え要求を送信し、ＭＭＥ／ＵＰＥ２０からの直接経路でデータを受信する。その後、ターゲットｅＮＢ１５ｂは、５９で、マーク付けされていないユーザパケットデータ（ＰＤＣＰ／ＨＣ ｕｐｄａｔｅ）の送信を開始する。ＵＬデータは、メッセージ５８、すなわち、ハンドオーバ完了メッセージと同じＴＴＩにおいて送信される。

再配置の間のコンテキスト情報の交換
本発明の他の基本的構想は、ターゲット圧縮エンドポイントを直接的に最も効率が良い圧縮率で開始させることを可能にするために、特定のヘッダ圧縮コンテキストを交換することである。コンプレッサのコンテキストの再配置の際に、この情報は、主に２つの「構成された」参照ヘッダ、すなわち、選択された情報を含むスライディングウィンドウ、このウィンドウに適用される有効性マスクから成る。デコンプレッサのコンテキストの再配置の際には、この情報は、主に、１つの参照ヘッダと、この参照ヘッダのフィールドについての有効性マスクと、から成る。

フィールドについてのコンテキストへの更新は、通常では、楽観的アプローチ（ＮＡＣＫに基づくスキーム）を利用する際には、同じタイプの情報を利用して何回も（「ＯＡ」）繰り返される。

図６は、最小位ビット（ＬＳＢ）符号化の解釈区間（ｉｎｔｅｒｐｒｅｔａｔｉｏｎ ｉｎｔｅｒｖａｌ）示しており、これは、典型的に連続して下降するフィールド（例えば、シーケンス番号）を圧縮するために、幾つかのヘッダ圧縮アルゴリズムにより利用されるロバストな符号化の方法である。解釈間隔は２^ｋのサイズを有し、６１は、並び替えに対するロバスト性、最大デルタ（ＳＮ）＝ｐに示し、６２は、連続損失に対するロバスト性、最大デルタ（ＳＮ）＝（２^ｋ−１）−ｐを示す。

基本的に、ｖ＿ｒｅｆは、ＬＳＢ符号化されるフィールドについての値を圧縮するため（符号化）、または、伸張するため（復号化）ために用いられる参照値である。符号化されたビットを解釈するための総間隔は、どれほど多くのビットが、符号化された値を表すために利用されるかに依存する。例えば、ｋ＝４ビットを利用すると、間隔は２^ｋ＝１６である。この間隔に対するオフセットが−１である場合には、ｒｅｆ＿ｍｉｎは、ｖ＿ｒｅｆ＋１に等しく、符号化は、符号化するフィールドが自身の前値から、ｒｅｆ＿ｍａｘ＝ｖ＿ｒｅｆ＋（２^４）＋１まで増加した場合にのみ適用可能である。オフセットが０の場合には、符号化する値は、ｒｅｆ＿ｍａｘ＝ｖ＿ｒｅｆ＋２^４まで、ｖ＿ｒｅｆと同じであってもよく、オフセットが＞０の場合には、ｖ＿ｒｅｆに関して下降した値が、すなわち、ｖ＿ｍｉｎ＝ｖ＿ｒｅｆ−ｐと、ｖ＿ｍａｘ＝ｖ＿ｒｅｆ＋２^４−ｐとの間の値が、符号化可能であることを意味している。

換言すれば、参照値ｖ＿ｒｅｆに関して値を符号化するために利用されるビット数は、どの最小値、およびどの最大値が符号化可能なのかを示している（図６のｒｅｆ＿ｍｉｎおよびｒｅｆ＿ｍａｘ）。オフセットの値は、符号化された値が、どれだけ多く参照値ｖ＿ｒｅｆから負方向に得られるのか（図８の領域６１）、さらに結果的に、どれだけ多く正方向に得られるのか（図６の領域６２）を示している。

コンプレッサについて、再配置された情報は以下のことを含んでいる。
・フィールドごとに、２つの「構成された」参照ヘッダＨＤＲ＿１、およびＨＤＲ＿２
・上記の第２のヘッダに、情報についての有効性マスク情報を含む（すなわち、受信されたフィードバックおよび楽観的アプローチに基づき、デコンプレッサのコンテキストのコンプレッサの観点を表す、ターゲット圧縮エンドポイントにおけるデコンプレッサの「状態」を得るため）

第１ヘッダ、すなわち、ＨＤＲ＿１は、動的に変化するフィールドのそれぞれについての、以前のヘッダの履歴からの最小値の集合であり、第２ヘッダ、すなわち、ＨＤＲ＿２は、同様に、動的に変化するフィールドのそれぞれについての、以前のヘッダの履歴からの最大値の集合である。非動的なフィールドに対応するコンテキスト情報は、フィールドが、ロバスト性を保証するために利用される繰り返し数（ＯＡ）に対応する履歴について一定である場合には、（各フィールドが個別に）有効としてマーク付けされ、そうでない場合には、無効としてマーク付けされる。

繰り返し数は、コンプレッサ実装パラメータである。ヘッダ圧縮がそれを介して適用されるリンクの特徴に従って、繰り返し数は、典型的に、以下のような値に設定される。
・ほとんどのパケットについて起こり得る最大数の連続損失に少なくとも等しい値（並び替えが予想されない場合）、または、
・ほとんどのパケットについて起こり得る最大の並び替えの深度（ｍａｘｉｍｕｍ ｒｅｏｒｄｅｒｉｎｇ ｄｅｐｔｈ）に関連する値（損失が予想されない場合）、または、
・上記双方を考慮に入れる値（損失および並び替え双方の可能性がある場合）
・チャネルが完全である（損失、並び替えが予想されない）場合には１（すなわち、繰り返しなし）

デコンプレッサについて、再配置された情報は以下のことを含んでいる。
・参照ヘッダ、すなわち、デコンプレッサのコンテキストを更新した、最新の成功裏に伸張されたヘッダ
・有効性マスクの情報（すなわち、ターゲット圧縮エンドポイントにおけるデコンプレッサの「状態」を得るため。これは、全コンテキストが、再配置が開始される瞬間に有効であるという保証はないので必要である。）有効性マスクは各フィールドに個別に適用される。

図７は、動的に変化するフィールドのためのスライディングウィンドウを示している。スライディングウィンドウは、「ＯＡ」のサイズであり、フィールドについてのＯＡ個の前値の履歴７１を含み、それぞれの前値は、フィールドを符号化する、または複合化するための参照値として用いられてもよい。構成されたＨＤＲ−１について各フィールドのために利用される値は、このウィンドウ（履歴）内のフィールドのための最小（最低）値である。構成されたＨＤＲ−２についての対応する値は、この同じウィンドウ内のこのフィールドの最大（最高）値である。従って、ＬＳＢ符号化される各フィールドについて、再配置情報は、以下のことを含んでいる。
・ＨＤＲ＿１は、スライディングウィンドウ内の最小値を含む（ＨＤＲ＿１はＭＩＮ（ｖ＿ｒｅｆ）である）
・ＨＤＲ＿２は、スライディングウィンドウ内の最大値を含む（ＨＤＲ＿２はＭＡＸ（ｖ＿ｒｅｆ）である）

ＬＳＢ以外でコード化される他のフィールド（すなわち、パケットごとに動的に変化しないフィールド）が、図８に示されている。このフィールドは、「ＯＡ」のサイズのスライディングウィンドウであり、８１は、以前のフィールド値の履歴を示している。各フィールドについて、ウィンドウ内の値（各フィールドについてのＯＡ値の履歴）が、予想される挙動を示した場合には、フィールドは有効としてマーク付けされる、そうでなければ無効としてマーク付けされる。従って、図８では、８２は、Ｆｉｅｌｄ＿１を表し、８３がＦｉｅｌｄ＿２を表す。値が最新のＯＡヘッダから一定である場合には、マスクは、再配置されたヘッダの対応するビットを、有効としてマーク付けし、そうでなければ、マスクはフィールドを未定義（“ｕｎｄｅｆｉｎｅｄ”）としてマーク付けする。図８では、Ｆｉｅｌｄ＿１は有効としてマスクされ、Ｆｉｅｌｄ＿２は有効としてマスクされる。

図９は、ＨＤＲ＿１、ＨＤＲ＿２、ＣＴＲＬフィールド（Ｃｔｒｌ ｆｉｅｌｄｓ）、マスク（Ｍａｓｋ）、およびリスト圧縮（Ｌｉｓｔｃｏｍｐ）を含む再配置コンテナを示している。リスト圧縮は、以下のいずれかである。
・全翻訳テーブル（索引、項目）と、リスト構造とを含む（コンプレッサまたはデコンプレッサ）
・最新ヘッダにのみ存在する項目と、リストの構造（項目の識別子）とを含む（コンプレッサのみ）
・それを含まない（コンプレッサのみ）、リスト圧縮の再初期化という結果になる

図１０は、通信ネットワークシステムにおいて、移動イベントの間に、ソース通信ネットワークノード１５ａからターゲット通信ネットワークノード１５ｂへと、データパケットのヘッダ圧縮コンテキストを効率良く再配置するための、ユーザ機器１８、ｅＮＢのようなソース通信ネットワークノード１５ａ、および、ｅＮＢのようなターゲット通信ネットワークノード１５ｂを示すブロック図である。この通信ネットワークシステムでは、上記圧縮されたヘッダを含む上記データパケットが、最初に上記ユーザ機器１８内の圧縮エンドポイントと、上記ソース通信ネットワークノード１５ａとの間で、および、上記移動イベントの後に、上記ユーザ機器１８内の圧縮エンドポイントと上記ターゲット通信ネットワークノード１５ｂ内の圧縮エンドポイントとの間で、無線インタフェースを介して、アップリンク１３およびダウンリンク１２上で送信される。

簡略化するために、以下では、図１０に示される２つのｅＮＢのうちの１つに関して記載する。ｅＮＢ１５は、無線送信機１０２および受信機１０１を含む。送信機１０２は、ダウンリンクチャネル１２上で、無線インタフェースを介して、ユーザ機器１８の受信機１０７へとデータを送信する。受信機１０１は、アップリンクチャネル１３上で、ユーザ機器１８からデータを受信する。ｅＮＢ１５はさらに、再配置工程の間、各個々のヘッダのコンテキスト更新プロパティを無効化するための手段１０３を含む。

ユーザ機器１８は、アップリンクチャネル１３上で、無線インタフェースを介して、ｅＮＢ１５ａおよびｅＮＢ１５ｂの受信機１０１へとデータパケットを送信するように構成される無線送信機１０６と、ダウンリンクチャネル１２上で、ｅＮＢ１５ａおよびｅＮＢ１５ｂの送信機１０２から送信されたデータパケットを受信するように構成される受信機１０７と、を含む。

考えられる主な実施形態は、コンテキストの再配置がネットワーク側で起こる移動イベントの間に、ユーザ機器内およびコアネットワーク内または無線アクセスネットワーク内に置かれる圧縮エンドポイントから成る装置である。

本発明は、ＬＴＥのｅＮＢ間またはａＧＷ間、ＵＴＲＡＮ ＲＮＣ間、ＳＧＳＮ間、ＵＥ、またはＰＤＳＮ間のような、ヘッダ圧縮が実行されるいずれのタイプのネットワークノードにも適用可能である。好適な実施形態によれば、本発明は、ＲｏＨＣに関連して、ＳＡＥ／ＬＴＥシステムにおいて、および、Ｘ２インタフェースを介してｅＮＢ間で利用可能である。

本発明はさらに、一般的なヘッダ圧縮に適用可能であるが、特に、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＴＣＰ（０ｘ０００６）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）、ＲＯＨＣｖ２ ＲＴＰ（０ｘ０１０１）、ＲＯＨＣｖ２ ＵＤＰ（０ｘ０１０２）、ＲＯＨＣｖ２ ＩＰ（０ｘ０１０４）、ＲＯＨＣｖ２ ＥＳＰ（０ｘ０１０３）、ＲＯＨＣｖ２ ＵＤＰ−Ｌｉｔｅ（０ｘ０１０８）、ＲＯＨＣｖ２ ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０１０７）ヘッダ圧縮プロファイルを含む、いずれのＲｏＨＣプロファイルにも適用可能であるが、上記プロファイルに限定されない。

提案される発明は、以下のような幾つかの修正と共に、ＲｏＨＣに全体的に含まれてもよい。
・（一般的な、またはプロファイル固有の）ＲｏＨＣヘッダフォーマットにおける追加的な仕組み、および、パケットごとにパケットの更新プロパティを無効化するため、または、デコンプレッサの更新ロジックを作動／非作動させるために、ＯＡを利用して更新されたコンテキストのエントリィを操作するための関連するロジック、
・幾つかの追加的なフィードバックロジック、
・コンテキストの更新を停止するための外部トリガ（ＨＣのみ、または、ＨＣおよびＨＤ双方、外部の同期化を利用）、および、
・再配置可能なコンテキストの部分の定義（および、どのフォーマット）。

または、提案される発明は、以下のような幾つかの修正と共に、３ＧＰＰ仕様に全体的に含まれてもよい。
・例えば、ＰＤＣＰヘッダ内の追加的なフラグ、および、パケットごとに更新プロパティを無効化するため、および、ＨＤにおけるコンテキスト更新を作動／非作動させるための、ＲｏＨＣ実装のための関連するロジック、
・ＲｏＨＣ実装、またはシグナリングのための幾つかのフィードバックロジック、
・コンテキストの更新を停止するための外部トリガ（ＨＣのみ、またはＨＣおよびＨＤ双方、外部の同期化を利用）、および、
・再配置可能なコンテキストの部分の定義（および、どのフォーマット）。

先に記載された本発明の実施形態への修正は、添付の特許請求の範囲に記載の請求項により定義される発明の範囲から逸脱することなく可能である。

本発明を記載する、および請求するために利用される、「含む」（“ｉｎｃｌｕｄｉｎｇ”）、「含む」（“ｃｏｍｐｒｉｓｉｎｇ”）、「組み込む」（“ｉｎｃｏｒｐｏｒａｔｉｎｇ”）、「〜から成る」（“ｃｏｎｓｉｓｔｉｎｇ、ｏｆ”）、「有する」（“ｈａｖｅ”）、「である」（“ｉｓ”）のような表現は、非排他的に解釈されるものとし、すなわち、明示的に存在すると記載されていない項目、構成要素または要素を可能にする。単数形での記載は複数形での記載に関連するものと解釈され、その反対もまた同様である。

添付の特許請求の範囲に記載の請求項における挿入句に含まれる数字は、請求項の理解を助けるものとし、これら請求項により請求される発明の主題を限定するものと決して解釈されるべきではない。

Claims (30)

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. 通信ネットワークシステムにおいて、移動イベントの間にソース通信ネットワークノードからターゲット通信ネットワークノードへと、データパケットのヘッダ圧縮コンテキストを再配置するためのユーザ機器であって、前記圧縮されたヘッダを含む前記データパケットが、無線インタフェースを介して、最初に前記ユーザ機器内の圧縮エンドポイントと前記ソース通信ネットワークノード内の圧縮エンドポイントとの間で送信され、前記移動イベントの後に、前記ユーザ機器内の圧縮エンドポイントと前記ターゲット通信ネットワークノード内の圧縮エンドポイントとの間で送信される、前記ユーザ機器において、
    前記ユーザ機器は、前記再配置工程の間に各個々のヘッダのコンテキスト更新プロパティが無効化される場合に、前記再配置工程の間に前記ソース通信ネットワークノードから、更新無しとしてマーク付けされたデータパケットを受信するように構成される受信機を含むことを特徴とする、ユーザ機器。

Images