JP2022549714A

JP2022549714A - イーサネット・ヘッダ圧縮とロバスト・ヘッダ圧縮の併用

Info

Publication number: JP2022549714A
Application number: JP2022519395A
Authority: JP
Inventors: イソマキマルクス; コジオルダビド; マラパッティラビンドライアディーパ
Original assignee: ノキアテクノロジーズオサケユイチア
Priority date: 2019-09-27
Filing date: 2020-09-14
Publication date: 2022-11-28
Anticipated expiration: 2040-09-14
Also published as: JP7365502B2; AU2020354589A1; EP3827534A4; WO2021058855A1; US11310352B2; US20210099555A1; EP3827534A1; CN112868213A

Abstract

【課題】イーサネット・ヘッダ圧縮とロバスト・ヘッダ圧縮の併用。【解決手段】本発明は、イーサネット・ヘッダ圧縮およびロバストなヘッダ圧縮の併用使用のための方法を提供する。より詳細には、イーサネット・パケット・データのイーサネット・ヘッダに対する第１の圧縮／解凍操作を実行することと、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断することと、イーサネット・パケット・データ内の少なくとも１つのインターネット・プロトコル・パケットを識別することと、前記少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対して第２の圧縮／解凍操作を実行することと、を含む方法であって、前記第２の圧縮／解凍操作は前記第１の圧縮／解凍操作とは独立したコンテキストまたはプロファイルのうちの示された少なくとも１つに基づく、方法が開示される。【選択図】図５Ａ

Description

［関連出願］
本出願は２０１９年９月２７日に出願されたインド特許出願第２０１９４１０３９１８６号からの優先権を主張し、その全体が本明細書に組み込まれる。本発明の例示的な実施形態による教示は、一般に、通信ヘッダの圧縮に関し、より具体的には、イーサネット（登録商標）および／またはＩＰヘッダを圧縮するためのロバスト・ヘッダ圧縮とイーサネット・ヘッダ圧縮との組み合わせ使用に関する。

このセクションは、特許請求の範囲に記載されている本発明の背景またはコンテキストを提供することを意図している。本明細書の説明は追求することができる概念を含むことがあるが、必ずしも以前からの着想または追求された概念ではない。したがって、本明細書で特に断らない限り、このセクションに記載されているものは、本明細書の説明および特許請求の範囲の先行技術ではなく、このセクションに含めることによって先行技術であると認められるものではない。

本明細書および／または図面に見られる一定の略語は、以下のように定義される。
５ＧＳ：５Ｇシステム
ＤＲＢ：データ無線ベアラ
ＥＨＣ：イーサネット・ヘッダ圧縮
ｇＮＢ：５Ｇ基地局
ＩＥＥＥ：電気電子技術者協会（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）
ＩＰ：インターネットプロトコル
ＰＤＣＰ：パケットデータ収束プロトコル
ＰＤＵ：プロトコルデータ単位
ＲｏＨＣ：ロバスト・ヘッダ圧縮
ＴＳＮ：時間敏感ネットワーキング（ｔｉｍｅｓｅｎｓｉｔｉｖｅｎｅｔｗｏｒｋｉｎｇ）
ＵＥ：ユーザ機器

データ通信ネットワークは、互いにデータを通信するように結合され構成された、様々なルータ、スイッチ、ブリッジ、および基地局またはユーザ装置のような他のネットワーク装置を含むことができる。これらの装置は本明細書では「ネットワーク装置」または「ネットワークノード」と呼ぶことができ、通信ネットワーク上の様々なネットワーク要素は、事前定義されたプロトコルを使用して互いに通信する。これらの異なるプロトコルは、ネットワーク要素間の通信のためにどのように信号が形成されるべきかのような、通信の異なる態様を実行するために使用されてもよい。

一般的に実装されているネットワーキングまたはインターネットワーキングプロトコルの１つは、イーサネットと呼ばれる。イーサネットプロトコルは、ＩＥＥＥ（ＩｎｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｉｃａｌａｎｄＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）によって定義されている。プロトコルファミリ（ＩＥＥＥ８０２．３）は、ローカルエリアネットワークのイーサネットを定義し、もう１つのプロトコルファミリ（ＩＥＥＥ８０２．１）はキャリアネットワークなどのワイドエリアネットワークで使用するイーサネットを定義する。

いくつかの無線通信システムは、ＵＥと通信する音声またはビデオ送信のようなパケット送信のためのシグナリングオーバヘッドを低減するためにロバスト・ヘッダ圧縮（ＲｏＨＣ）を使用する。その結果、圧縮操作を管理し改善するための方法が有益であることが分かる。

本発明の例示的な実施形態は、上述のイーサネットなどのプロトコルの通信および圧縮を改善するように働く。

本開示の様々な実施形態の上記および他の態様、特徴、および利点は、添付の図面を参照した以下の詳細な説明からより完全に明らかになる。図面は本開示の実施形態のより良い理解を容易にするために示すものであり、必ずしも縮尺通りには描かれていない。
図１は、本発明の種々の態様を実施する際に使用される種々のデバイスの高レベルブロック図を示す。図２は、本発明の例示的な実施形態による、第１のオプションのためのイーサネット・ヘッダ圧縮器およびＲｏＨＣ圧縮器の併用操作を示す。図３Ａは、本発明の例示的な実施形態による、第１のオプションのためのイーサネット・ヘッダ解凍器およびＲｏＨＣ解凍器の併用操作を示す。図３Ｂは、本発明の例示的な実施形態による、第２のオプションのためのイーサネット・ヘッダ圧縮器およびＲｏＨＣ圧縮器の併用操作を示す。図３Ｃは、本発明の例示的な実施形態による、第２のオプションのためのイーサネット・ヘッダ解凍器およびＲｏＨＣ解凍器の別の併用操作を示す。図４は、本発明の例示的な実施形態によるフィードバックメッセージフォーマットを示す。図５Ａおよび図５Ｂは、それぞれ、装置によって実行され得る、本発明の例示的な実施形態による方法を示す。図５Ａおよび図５Ｂは、それぞれ、装置によって実行され得る、本発明の例示的な実施形態による方法を示す。

本発明の例示的な実施形態では、少なくとも、イーサネットおよび／またはＩＰヘッダを圧縮するために、ロバスト・ヘッダ圧縮とイーサネット・ヘッダ圧縮との組み合わせ使用を実行する方法および装置が提案される。

３ＧＰＰＲＡＮ２ＷＧでは、ＮＲＩｎｄｕｓｔｒｉａｌＩｏＴＷＩの一環として、イーサネットＰＤＵセッションのイーサネット・ヘッダ圧縮（ＥＨＣ）を標準化しており、その中の１つの提案で以下のように示されている。
－－－－－以下引用－－－－－
３．ＮＲＴＳＣ関連強化の詳細な目標は以下のとおりである。
（．．．）
● 構造認識アルゴリズム［ＲＡＮ２］に基づいてイーサネット・ヘッダ圧縮を指定する。
○ ＮＲの設計原理が合意されると、ＬＴＥのためのイーサネット・ヘッダ圧縮ソリューションが指定される。影響を受けたＬＴＥ仕様は、最新ＲＡＮ＃８５で追加される。
－－－－－以上引用－－－－－

ＲＡＮ２では、ＩＰＰＤＵセッションのＩＰおよびトランスポートプロトコル層のヘッダを圧縮するために使用されるＲｏＨＣ（ＲｏｂｕｓｔＨｅａｄｅｒＣｏｍｐｒｅｓｓｉｏｎ）をＥＨＣのベースとせず、新しいフレームワークを開発することが決定されており、ＲｏＨＣの原理の少なくとも一部を、潜在的に簡略化した形で再利用すると期待される。

ＥＨＣは、ペイロードサイズが小さく、タイムセンシティブ（時間に敏感な）イーサネット通信に最も有用である。このタイプのトラフィックは、現在、イーサネット上では通常ＩＰを使用せず、プロフィネット（Ｐｒｏｆｉｎｅｔ）やイーサキャット（Ｅｔｈｅｒｃａｔ）などの産業用イーサネットアプリケーションプロトコルを使用している。しかしながら、エンドツーエンドＩＰ通信は、タイムセンシティブアプリケーション（産業制御、仮想現実、．．．）に対しても広く使用される可能性が高いが、これらの場合のいくつかでは、遅延と信頼性保証が３ＧＰＰ標準によってもサポートされているＴＳＮのようなメカニズムを通して、イーサネットレベルで提供されている。

したがって、いくつかのタイムセンシティブネットワーキング展開では、ＩＰパケットが、５ＧイーサネットＰＤＵセッションを介してイーサネットで伝送されるか、または、ＩＰパケットが、５ＧＩＰＰＤＵセッションを介してイーサネットで伝送される可能性がある。どちらの場合も、イーサネット・ヘッダだけでなく、ＩＰヘッダとＵＤＰ／ＩＰヘッダも圧縮できると有用である。３ＧＰＰＴＲ３８．８２５バージョン１６．０．０は、産業ＩｏＴ強化に関する３ＧＰＰＲＡＮＷＧの試験フェーズを要約しており、この側面を以下のように要約している。
－－－－－以下引用－－－－－ーー
６．６．２．３ＩＰヘッダ圧縮との関係
イーサネットは、ＩＰまたは非ＩＰトラフィックを転送できる。この態様は、例えばＲ２ー１８１７５７２（［１３］）に記載されている。ＩＰヘッダ圧縮は、イーサネット・ヘッダ圧縮が採用される場合に考慮されてもよく、この場合、イーサネットおよびＩＰの併用／統合ヘッダ圧縮と同様に、独立／分離ヘッダ圧縮ソリューションの両方を想定することができる。併用圧縮方式における固有の複雑さとモジュール方式の利点を考えると、構造を考慮したイーサネット・ヘッダ圧縮方式を開発した場合、併用ソリューションの中でＩＰヘッダ圧縮を考慮すべきではない。
－－－－－以上引用－－－－－ーー

ＩＰとイーサネットの両方を圧縮するアルゴリズムの併用操作は複雑であると考えられていたため、イーサネットとＩＰヘッダの両方を圧縮することを可能にする解決策が必要であったので、別々のアルゴリズムを使用することが好ましいとされた。これは、ＥＨＣとＲｏＨＣを重ね合わせて活用することで実現できるが、一方で、課題も抱えている。

実際的な問題は、イーサネット・ヘッダ圧縮（ＥＨＣ）と既存のＲｏＨＣ圧縮フレームワークのために３ＧＰＰＲＡＮ２がとるアプローチを与えられた場合、最も効率的で標準準拠の方法でＩＰ／イーサネットとＵＤＰ／ＩＰ／イーサネット・ヘッダ構造を圧縮する方法である。原則として３つのアプローチがある。
１．イーサネットだけでなく、上位層ヘッダを圧縮できるＥＨＣ用の追加プロファイルを定義する。

このアプローチの問題は、ＥＨＣが非常に静的なイーサネット・ヘッダを扱えるようになるように、意図的にできるだけ簡単に定義されており、より複雑で動的なＩＰおよびトランスポート層ヘッダに容易に拡張できないことである。この手法は、前述のＮＲＩＩｏＴに関する検討段階でも複雑と見られていた。

２．イーサネット・ヘッダと既存のＩＰおよびトランスポート層プロファイルを組み合わせた追加のＲｏＨＣプロファイルを定義する。

これは技術的に最も実行可能なアプローチであるが、３ＧＰＰＲＡＮ２において拒絶された。

３．ＥＨＣとＲｏＨＣを同じＩＰまたはイーサネットＰＤＵセッション内で使用する方法を、ＥＨＣがイーサネット・ヘッダを圧縮し、ＲｏＨＣが上位層ヘッダをそのプロファイルのいずれかで圧縮するように定義する。

これは、本発明の例示的な実施形態において採用されるアプローチである。それは、２つの圧縮フレームワークが特定のＰＤＵセッションに対して同時にどのようにネゴシエートされるか、それらの各々が可能な限り他から独立するようにそれらがどのように操作し相互作用するかを解決することを必要とする。

ＥＨＣとＲｏＨＣの組合せは、イーサネットとＩＰパッドの両方についての理解の組合せであり、ＩＰ／イーサネット・パケットからイーサネットレベルパディングを取り除く機会を与えることに注目する価値がある。イーサネット標準では、歴史的な理由により、最小フレームサイズは６４バイトである。フレーム内の実際のペイロードが６４バイトに達するまでに必要な量より小さい場合、パディングバイトがペイロードの先端に追加される。イーサネット・ヘッダ圧縮の一部として、イーサネットフレームからパディングを削除できることは有益である。これには実際のペイロードの終わりとパッドの開始位置を知るために、ＩＰパケット長などの上位層ヘッダを調べる必要がある。したがって、デフォルトではＥＨＣはそれ自体ではこれを行うことができない。しかしながら、ＲｏＨＣとＥＨＣとを組み合わせて使用する場合には、これが可能である。これを行うための方法が、本発明の例示的な実施形態に含まれている。

ＥＨＣは３ＧＰＰでの仕様にすぎず、この問題は、ＥＨＣとＲｏＨＣが、イーサネットまたはＩＰＰＤＵセッションを介してＩＰ／イーサネット・ヘッダで連携することにおいて非常に特有である。

ＩＥＴＦでは２００９年ごろ、８０２（イーサネット、Ｗｉ－Ｆｉ）ネットワークを介したＲｏＨＣに関する提案があったが、これらは、ＲｏＨＣが、本発明の例示的な実施形態の場合のようなイーサネットリンクの中間ではなく、イーサネットリンクの終点に配備される場合に対処するものである。ここで、ＲｏＨＣとＥＨＣはイーサネットリンクの終点で操作するのではなく、その中間で操作する。さらに、ＩＥＴＦ提案はイーサネット・ヘッダの圧縮を考慮しておらず、ＩＥＴＦでの作業は放棄された。

イーサネットパディング除去のために、３ＧＰＰでは、ＥＨＣ圧縮器が、さもなければ小さすぎるのであろうフレームにパディングを追加することによってパディングを除去した状況のために、ＥＨＣ解凍器を準備すべきであるという提案がなされている。しかしながら、ＥＨＣ圧縮器がどのようにこれを行うことができるかについての仕様はなく、これは独自のオプションとして残されている。

ＩＰとイーサネット・ヘッダ圧縮の併用操作の態様は、本出願時のいくつかのＲＡＮ２の貢献の一部として、本明細書で議論されている。しかしながら、これらの寄与は、本明細書に開示されるような本発明の実施形態による詳細を開示しない。例えば、これらの寄与のいずれも、本発明の例示的な実施形態の焦点でいかなるＥＨＣおよびＲｏＨＣ圧縮器／解凍器相互作用も開示せず、圧縮スキーム確立中のフィードバックのいかなる態様も開示または議論しない。

適切に協働するために、本発明の例示的な実施形態は、ＥＨＣとＲｏＨＣとの間の少なくとも４つの必要な態様を解決する。これらの態様には、
１．複合操作のサポートを曖昧さなく表現できるようにする、同一ＰＤＣＰコンテキストにおけるＥＨＣとＲｏＨＣのネゴシエーションのシンタックスとセマンティクス、
２．ＥＨＣおよびＲｏＨＣ圧縮アルゴリズムを使用するデータパケットのための圧縮器操作、
３．ＥＨＣおよびＲｏＨＣ解凍アルゴリズムを使用したデータパケットの解凍操作、および／または、
４．ＥＨＣとＲｏＨＣの両方に対する複合フィードバックオプションを含むフィードバックメッセージング、
を含む。

本発明の例示的な実施形態では、これらのそれぞれに対する解決策が提示される。

本発明の例示的な実施形態をさらに詳細に説明する前に、図１を参照する。図１は、本発明の種々の態様を実施する際に使用される種々のデバイスの高レベルブロック図を示す。

図１を参照すると、この図は、例示的な実施形態を実施することができる１つの可能な非限定的な例示的なシステムを示している。図１において、ユーザ機器（ＵＥ）１１０は、無線ネットワーク１００と無線通信している。ＵＥは、無線ネットワークにアクセスできる無線装置（典型的にはモバイルデバイス）である。ＵＥは例えば、携帯電話（または「携帯」電話と呼ばれる）および／または携帯端末機能を有するコンピュータであってもよい。例えば、ＵＥまたは情報処理装置は、ポータブル、ポケット、ハンドヘルド、コンピュータ埋め込みまたは車載モバイルデバイスであってもよく、言語シグナリングおよび／またはＲＡＮとのデータ交換を実行する。

ＵＥ１１０は、１つ以上のバス１２７を介して相互接続された１つ以上のプロセッサ１２０、１つ以上のメモリ１２５、および１つ以上のトランシーバ１３０を含む。１つ以上のトランシーバ１３０の各々は、受信機、Ｒｘ、１３２および送信機、Ｔｘ、１３３を含む。１つ以上のバス１２７は、アドレス、データ、または制御バスとすることができ、マザーボードまたは集積回路上の一連のライン、光ファイバまたは他の光通信機器などの任意の相互接続機構を含むことができる。１つ以上のトランシーバ１３０は、１つ以上のアンテナ１２８に接続される。１つ以上のメモリ１２５は、コンピュータ・プログラム・コード１２３を含む。ＵＥ１１０は、いくつかの方法で実装され得る部分１４０－１および／または１４０ー２の一方または両方を備えるモジュールを含む。ＵＥ１１０は、圧縮モジュール１４０ー１および１４０ー２を含む処理コンポーネントを含む。これらの圧縮モジュールは、本明細書で開示されるような本発明の例示的な実施形態を実行するように実装され得るプロセッサ構成を含むことができる。圧縮モジュールは１つ以上のプロセッサ１２０の一部として実装されるように、圧縮モジュール１４０－１としてハードウェアで実装されてもよい。圧縮モジュール１４０ー１は、集積回路として、またはプログラマブル・ゲート・アレイなどの他のハードウェアを介して実装することもできる。別の例では、圧縮モジュールがコンピュータ・プログラム・コード１２３として実装され、１つ以上のプロセッサ１２０によって実行される圧縮モジュール１４０－２として実装されてもよい。例えば、１つ以上のメモリ１２５およびコンピュータ・プログラム・コード１２３は、１つ以上のプロセッサ１２０を用いて、ユーザ装置１１０に本明細書に記載する１つ以上の操作を実行させるように構成してもよい。ＵＥ１１０は、無線リンク１１１を介して無線アクセスネットワーク（ＲＡＮ）ノード１７０と通信する。

ＲＡＮノード１７０は、ＵＥ１１０のような無線装置による無線ネットワーク１００へのアクセスを提供する基地局であってもよい。例えば、ＲＡＮノード１７０は、ｇＮＢ（ＵＥ１１０に向けてＮＲ利用者プレーンおよび制御プロトコル終端を提供するノード）またはｎｇ－ｅＮＢ（ＵＥ１１０に向けてＥ－ＵＴＲＡ利用者プレーンおよび制御プレーンプロトコル終端を提供し、ＮＧインタフェースを介してコアネットワーク（すなわち、５Ｇコア（５ＧＣ））に接続されるノード）などのＮＲ／５Ｇネットワーク内のノード（例えば、基地局）とすることができる。ＲＡＮノード１７０は、１つ以上のプロセッサ１５２と、１つ以上のメモリ１５５と、１つ以上のネットワークインターフェース（Ｎ／ＷＩ／Ｆ）１６１と、１つ以上のバス１５７を介して相互接続された１つ以上のトランシーバ１６０とを含む。１つ以上のトランシーバ１６０の各々は、受信機、Ｒｘ、１６２および送信機、Ｔｘ、１６３を含む。１つ以上のトランシーバ１６０は、１つ以上のアンテナ１５８に接続される。１つ以上のメモリ１５５は、コンピュータ・プログラム・コード１５３を含む。ＲＡＮノード１７０は、いくつかの方法で実装され得る部分１５０－１および／または１５０－２の一方または両方を備える圧縮モジュールを含む。圧縮モジュールは１つ以上のプロセッサ１５２の一部として実装されるように、圧縮モジュール１５０－１としてハードウェアで実装されてもよい。圧縮モジュール１５０－１は、集積回路として、またはプログラマブル・ゲート・アレイなどの他のハードウェアを介して実装することもできる。別の例では、圧縮モジュールが、コンピュータ・プログラム・コード１５３として実装され、１つ以上のプロセッサ１５２によって実行される圧縮モジュール１５０－２として実装されてもよい。例えば、１つ以上のメモリ１５５およびコンピュータ・プログラム・コード１５３は１つ以上のプロセッサ１５２を用いて構成され、ＲＡＮノード１７０に、本明細書に記載するように、１つ以上の操作を実行させる。１つ以上のネットワークインターフェース１６１は、リンク１７６および１３１を介してなどのネットワークを介して通信する。２つ以上のＲＡＮノード１７０は、例えばリンク１７６を用いて通信する。リンク１７６は有線であっても、無線であっても、またはその両方であってもよく、たとえば、５ＧのためのＸｎインタフェース、ＬＴＥのためのＸ２インタフェース、または他の規格のための他の適切なインタフェースを実装することができる。

１つ以上のバス１５７はアドレス、データ、または制御バスとすることができ、
マザーボードまたは集積回路上の一連のライン、光ファイバまたは他の光通信機器、無線チャネルなどの任意の相互接続機構を含むことができる。例えば、１つ以上のトランシーバ１６０は、遠隔無線ヘッド（ＲＲＨ）１９５として実装されてもよく、ＲＡＮノード１７０の他の要素はＲＲＨとは物理的に異なる位置にあり、１つ以上のバス１５７はＲＡＮノード１７０の他の要素をＲＲＨ１９５に接続するために、部分的に光ファイバケーブルとして実装されてもよい。

無線ネットワーク１００は、コアネットワーク機能を含み、電話回線網および／またはデータ通信ネットワーク（例えばインターネット）のようなさらなるネットワークとのリンクまたはリンクを介して接続性を提供するネットワーク制御素子または素子ＮＣＥ１９０を含んでもよい。このような５Ｇのコアネットワーク機能には、アクセスおよびモビリティ管理機能（ＡＭＦ）および／またはユーザプレーン機能（ＵＰＦ）および／またはセッション管理機能（ＳＭＦ）が含まれる。ＬＴＥのためのそのようなコアネットワーク機能は、ＭＭＥ（モビリティ管理エンティティ）／ＳＧＷ（サービングゲートウェイ）機能を含むことができる。これらは、ＮＣＥ１９０によってサポートされ得る単なる例示的な機能であり、５Ｇ機能およびＬＴＥ機能の両方がサポートされ得ることに留意されたい。ＲＡＮノード１７０は、リンク１３１を介してＮＣＥ１９０のようなネットワーク制御エレメントに結合される。リンク１３１は例えば、５ＧのためのＮＧインタフェース、またはＬＴＥのためのＳ１インタフェース、または他の規格のための他の適切なインタフェースとして実装され得る。ＮＣＥ１９０は、１つ以上のバス１８５を介して相互接続された、１つ以上のプロセッサ１７５、１つ以上のメモリ１７１、および１つ以上のネットワークインターフェース（Ｎ／ＷＩ／Ｆ）１８０を含む。１つ以上のメモリ１７１は、コンピュータ・プログラム・コード１７３を含む。１つ以上のメモリ１７１およびコンピュータ・プログラム・コード１７３は、１つ以上のプロセッサ１７５によって、ＮＣＥ１９０に１つ以上の操作を実行させるように構成される。

［１．ネゴシエーション］
３ＧＰＰにおけるＲｏＨＣネゴシエーションロジックは、現在、ＵＥがＵＥ能力においてサポートされるＲｏＨＣプロファイルのリストを提供するように機能する。ベースステーションがこれらのＲｏＨＣプロファイルをサポートしている場合、ＤＲＢ（ＤａｔａＲａｄｉｏＢｅａｒｅｒ）は、データ無線ベアラ（ＰＤＣＰレイヤのデータセッションと見なすことができる）として設定することができ、ＲｏＨＣはそのＤＲＢ内で送信されるすべてのＩＰパケットに対して有効である。サポートされているプロファイルのいずれにも当てはまらないパケット（例えば、両方のピアがＵＤＰ／ＩＰとＲＴＰ／ＵＤＰ／ＩＰプロファイルのみをサポートしていたが、送信されたパケットがＴＣＰ／ＩＰであるという理論的なケース）でも、ＲｏＨＣパケットとしてカプセル化された特別なＵＮＣＯＭＰＲＥＳＳＥＤプロファイルを使用して送信される。これは、ネゴシエーションとネットワーク設定に基づいてＲｏＨＣが有効になっている場合、すべてのデータパケットはＲｏＨＣパケットであり、ＲｏＨＣデータとＲｏＨＣフィードバックの間を除き、それらを明確に識別する必要はないことを意味する。ＲｏＨＣフィードバックパケットを特別に識別する理由は、ＰＤＣＰレイヤですでに優先順位をつける（可能性を与える）必要性から生じている。

同様に、ピア間で共通のＲｏＨＣプロファイルが見つからない場合、ＲｏＨＣは無効になり（つまり、ネットワークによって設定されていない）、そのセッションでは何の役割も果たさない。ＲｏＨＣがＥＨＣと一緒にネゴシエート／設定されている場合にこのアプローチに従うと、一般的にサポートされているプロファイルに基づいてＲｏＨＣが有効になっている場合、イーサネット・ペイロードとして伝送され、ＥＨＣが使用されているときにＥＨＣパケットに続くすべてのＩＰパケットが実際にＲｏＨＣパケットであることがわかる。したがって、パケットがＲｏＨＣパケットであるか（ＲｏＨＣが有効な場合は常に有効）、プレーンＩＰパケットであるか（ＲｏＨＣが無効な場合は常に有効）、特にＰＤＣＰまたはＥＨＣヘッダで示す必要はない。特別なケースの１つは、フィードバックパケット／メッセージの同定であり、以下でさらに詳しく説明する。

ＰＤＣＰコンテキストのためのＲｏＨＣのためのサポートおよびチャネルパラメータは、３ＧＰＰＴＳ３８．３３１におよびＲＲＣによってネゴシエートされる。このネゴシエーションの最も重要な態様は、ＵＥがサポートされるＲｏＨＣプロファイルのリストを基地局に提供することである。その後、基地局は、（圧縮コンテキストが適切にセットアップされた後に）一定のデータ無線ベアラ（ＤＲＢ）内のパケットを圧縮／解凍するために使用される、ＵＥによって広告され、かつそれがサポートするＲｏＨＣプロファイルのいずれかを構成することができる。

ＥＨＣネゴシエーションは現在のところ３ＧＰＰによって定義されていないが、同じパターンに従うと仮定することができる。ＵＥは、ＥＨＣをサポートする能力と、ＵＥがサポートするＥＨＣプロファイルとを提供する。当初、規格には単一のものしか定義できないため、ＥＨＣにおけるプロファイルネゴシエーションがまったく含まれるかどうかは確かではないが、少なくともＥＨＣをサポートするＵＥ能力が示されなければならない。

１つの新しい態様は、ＲｏＨＣとＥＨＣの併用をどのように取り決めるかである。

ＵＥがイーサネットＰＤＵセッションのためのＥＨＣ（特定のプロファイルを有する）およびＲｏＨＣ（特定のプロファイルを有する）の両方の支持を広告する場合、ＵＥが、その特定のＰＤＵセッションのためのＥＨＣおよびＲｏＨＣの組み合わせた使用を支持することを意味する。広告されたすべてのＥＨＣプロファイルがイーサネット・ヘッダでのみ操作し、アナウンスされたすべてのＲｏＨＣプロファイルがイーサネットの上に直接ＩＰまたはその他のヘッダで操作する限り、任意のＥＨＣまたはＲｏＨＣプロファイルを一緒に使用できる。しかしながら、将来のＥＨＣがイーサネット上のヘッダ上でも操作するプロファイルを定義するか、ＲｏＨＣがイーサネット・ヘッダ上で操作するプロファイルを定義するなら、アナウンスでは、層間を横断しないプロファイルのみを複合的にサポートすることを意味する。

代替的に、ＵＥはＥＨＣおよびＲｏＨＣを組み合わせて操作させる能力を追加的にシグナリングする必要があり得る、すなわち、ＵＥがＥＨＣサポートおよびＲｏＨＣサポートをシグナリングするが、組み合わせ操作サポートをシグナリングしない場合、ネットワークはＤＲＢのためにＥＨＣまたはＲＯＨＣのいずれか一方を構成することができるが、それらの両方を同時に構成することはできない。組み合わされた操作が示される場合、ネットワークは、単一のＤＲＢのためにＥＨＣおよびＲｏＨＣの両方を構成することができる。

ネゴシエーション手順は、本発明の例示的な実施形態の新規な部分ではない場合がある。しかしながら、これは、以下に列挙されるさらなる手順のための前提条件であるため、本明細書に記載される。

［オプション１：］
［２．データパケットの圧縮操作］
ここでは、ＲｏＨＣとＥＨＣを組み合わせて送信パケットのヘッダを圧縮する方法について説明する。組み合わせ操作の前提条件は、ネゴシエーションに基づいて、ＥＨＣおよびＲｏＨＣの両方がＤＲＢに対して有効にされていることである。ＲｏＨＣケースでは、これは、ピアが少なくとも１つの共通ＲｏＨＣプロファイルに対する支援を示したことを意味する。ＥＨＣ圧縮器とＲｏＨＣ圧縮器の次の組合せ操作を提案した。
１．圧縮されていないパケットは、最初にＥＨＣ圧縮器に供給される、
２．ＥＨＣはイーサネット・ヘッダを圧縮し、イーサネットペイロードタイプ（ｔｙｐｅ／Ｅｔｈｅｒｔｙｐｅ）をチェックする、
３．イーサネットペイロードタイプがＩＰｖ４またはＩＰｖ６の場合、ＥＨＣはＩＰパケット長をチェックし、イーサネット・ペイロードがＩＰパケットサイズよりも長い場合は、オプションで追加のバイトを削除する（パディングであることがわかっているため）、その後、ＥＨＣはＩＰパケット（またはＩＰパケットの開始位置へのポインタ）をＲｏＨＣに渡す、
４．ＲｏＨＣは、他のピアでサポートされているプロファイルにおよび宿Ｐパケットを操作する、
● ＲｏＨＣコンテキスト割り当ては、ＥＨＣコンテキスト割り当てから独立している、および、
５．結果のパケットは、送信のために下位層に与えられる。
結果のパケットは次の形式になる、
｜ＥＨＣヘッダ｜ＲｏＨＣヘッダ｜ＲｏＨＣプロファイルを超えたペイロード｜パディング（オプションで削除）｜

図２は、この第１のオプションについて、ＩＰ／イーサネット・パケットを圧縮する後続のステップ、および、処理中にＥＨＣおよびＲｏＨＣ圧縮器がどのように協働するかを示す。また、圧縮の異なる段階におけるパケット構造も示している。図２に示すように、パケット構造２１０と、ＥＨＣ圧縮器２２０と、ＲＯＨＣ圧縮器２３０とがある。パケット構造２１０はパケット構造ＡからＦを含み、ＥＨＣ圧縮器２２０は、本発明の実施形態例にしたがった操作フローを含む。ＥＨＣ圧縮器２２０フローのこれらの操作は、ステップＡにおいて、ＥＨＣ圧縮器に到着する新しいＰＤＣＰＳＤＵがあり、ステップＢにおいて、イーサネットヘッダがＥＨＣ圧縮器によって圧縮され、ステップＣにおいて、パケットがイーサネットフレームに含まれる場合、パディングが除去され、
ステップＤにおいて、パケットがイーサネットフレームから抽出される場合、圧縮されていないＩＰパケットがＲＯＨＣ圧縮器２３０に提供され、ＩＰパケットがＲＯＨＣ圧縮器２３０フローのステップＤ１に示されるようにＲＯＨＣ圧縮器に到着することを含む。あるいは、ＥＨＣ圧縮器がパケット構造２１０のステップＣに見られるように、ＥＨＣヘッダと共に、ＩＰパケットが開始する場所へのポインタと共に、パケットを提供してもよい。いずれの場合も、ＲＯＨＣ圧縮器２３０はＩＰパケット上でのみ操作し、ＥＨＣヘッダ上では操作しない。ＲＯＨＣ圧縮器２３０において、ＩＰヘッダはＲＯＨＣ圧縮器２３０のフローのステップＤ２に示されるように圧縮され、次いで、圧縮されたＩＰパケットがＥＨＣ圧縮器２２０に供給され、ＥＨＣ圧縮器２２０のフローのステップＥにおいて、圧縮されたＩＰパケットがＥＨＣ圧縮器に到着し、ＥＨＣ圧縮器２２０のフローのステップＦにおいて、圧縮されたイーサネット・ヘッダが再挿入され、次いで、ＥＨＣ圧縮器２２０のフローのステップＧにおいて、パケットが送信のために下位レイヤに供給される。ステップＤの場合、ＥＨＣ圧縮器はフルパケットにポインタを提供し、ステップＥにおいて、ＥＨＣ圧縮器はＥＨＣヘッダおよびＲＯＨＣヘッダの両方を有するパケットを受信しており、これは、送信のために下位レイヤに直接提供されてもよい。

［３．データパケットの解凍操作］
１．圧縮されたパケットがＥＨＣ解凍器に渡される、
２．ＥＨＣはイーサネット・ヘッダを解凍し、イーサネットペイロードタイプをチェックする、
３．イーサネット・ペイロードがＩＰｖ４またはＩＰｖ６ＥＨＣの場合、イーサネットペイロード（またはそのポインタ）はＲｏＨＣに渡される、この場合のペイロードは実際にはＲｏＨＣパケットである、
４．ＲｏＨＣは示されたコンテキストおよびプロファイルにしたがってパケットを操作し、結果として非圧縮ＩＰパケットを生成する、
５．ＲｏＨＣ操作後、パッド追加のためにパケットがＥＨＣに返される、および／または、
６．ＥＨＣは、必要に応じてパディングバイトを追加して、フレームが必須の最小サイズに達するようにする。

図３Ａは、ＩＰ／イーサネット・パケットを解凍するこの第１のオプションの後続ステップと、処理中にＥＨＣおよびＲｏＨＣ解凍器がどのように連動するかを示す。また、解凍の異なる段階でのパケット構造も示す。

図３Ａに示すように、パケット構造３１０と、ＥＨＣ解凍器３２０と、ＲＯＨＣ解凍器３３０とがある。パケット構造３１０はパケット構造ＡからＦを含み、ＥＨＣ解凍器３２０は、本発明の実施形態例にしたがった操作フローを含む。ＥＨＣ解凍器３２０フローのこれらの操作は、第１のステップではＥＨＣ解凍器に到着する圧縮パケットがあり、その後のステップではイーサネット・ヘッダが解凍され、別のステップでは圧縮されたＩＰパケットがイーサネットフレームから抽出され、ＲＯＨＣ解凍器３３０に提供されることを含む。あるいは、ＥＨＣ解凍器が解凍されたイーサネット・ヘッダを含むパケットに、ＲＯＨＣヘッダが開始する場所へのポインタを提供してもよい。次に、ＲＯＨＣ解凍器３３０はＲＯＨＣ解凍器３３０フローのステップＣ１に示すように、ＲＯＨＣ解凍器に到着する圧縮ＩＰパケット上で作動し、ここで、ＩＰヘッダは、ＲＯＨＣ解凍器３３０フローのＣ２に示すように解凍され、次いで、解凍されたＩＰパケットはＥＨＣ解凍器３２０に供給され、ここで、ＥＨＣ解凍器３２０フローのステップＤで、解凍されたＩＰパケットが到着し、ＥＨＣ解凍器３２０フローのステップＥで、イーサネット・ヘッダが再挿入され、ステップＦで、必要に応じてパディングが再挿入され、次いで、非圧縮パケットのステップＧで、上位階層に提供される。前のステップにおいて、ＥＨＣ解凍器はＲＯＨＣヘッダが始まる場所へのポインタをもつイーサネット・ヘッダを含むパケットを提供した場合には、次いで、ステップＤにおいて、ＥＨＣ解凍器はイーサネット・ヘッダとＩＰヘッダの両方をもつパケットを受信しており、これは上位階層に直接提供されてもよい。

［オプション２：］
［データパケットの圧縮操作］
ＥＨＣ圧縮器とＲｏＨＣ圧縮器の次の組合せ操作を提案した。
１．圧縮されていないパケットは、最初にＥＨＣ圧縮器に供給される、
２．ＥＨＣはイーサネット・ヘッダを圧縮し、ＥＨＣヘッダを追加する、ＥＨＣはイーサネットペイロードタイプ（ｔｙｐｅ／Ｅｔｈｅｒｔｙｐｅ）をチェックする、
３．イーサネットペイロードタイプがＩＰｖ４またはＩＰｖ６の場合、ＥＨＣはＩＰパケット長をチェックし、イーサネット・ペイロードがＩＰパケットサイズよりも長い場合は、オプションで追加のバイトを削除する（パディングであることがわかっているため）、次に、ＥＨＣ圧縮器は、ＩＰパケット（またはＩＰパケットが開始する場所へのポインタ）をＲｏＨＣに与える、
４．ＲｏＨＣは、他のピアでサポートされているプロファイルにしたがってIＰパケットを操作する、
● ＲｏＨＣコンテキスト割り当ては、ＥＨＣコンテキスト割り当てから独立している、および、
５．結果のパケットは、送信のために下位層に与えられる。
｜ＲｏＨＣヘッダ｜ＥＨＣヘッダ｜ペイロード｜パッディング（オプションとして除去）

図３Ｂは、本発明の実施例にしたがった第２の選択肢のためのＥＨＣ圧縮器とＲｏＨＣ圧縮器の結合操作を示す。

図３Ｂに同様に示すように、パケット構造３１０、ＥＨＣ圧縮器３２０、およびＲＯＨＣ圧縮器３３０を示す。パケット構造３１０はパケット構造ＡからＥを含み、ＥＨＣ圧縮器３２０は、本発明の実施形態例による操作フローを含む。ＥＨＣ圧縮器３２０のフローのこれらの操作は、第１のステップにおいて、ＥＨＣ圧縮器３２０に到着する新しいＰＤＣＰＳＤＵがあり、後続のステップにおいて、イーサネット・ヘッダがＥＨＣ圧縮器によって圧縮され、別の後続のステップにおいて、イーサネットフレームに含まれる場合、パディングが除去され、次いで、ＩＰパケットへのポインタがＲＯＨＣに提供されることを含む。図３ＢのステップＤ１に示すように、ＩＰパケットはＲＯＨＣ圧縮器に到着している。
図３ＢのステップＤ２において、ＩＰヘッダが圧縮される。次に、図３ＢのステップＤ３に示すように、パケットは、送信のために下位レイヤに提供される。

［データパケットの解凍操作：］
１．圧縮されたパケットは、ＥＨＣが有効か無効かの表示と共にＲｏＨＣ解凍器に与えられる、
２．ＲｏＨＣは示されたコンテキストおよびプロファイルにしたがってパケットを操作し、結果として非圧縮ＩＰパケットを生成する、
３．ＲｏＨＣ操作の後、パケットはＥＨＣ解凍器に与えられる、
４．ＥＨＣはイーサネット・ヘッダを解凍し、イーサネットペイロードタイプをチェックする、および、
５．イーサネットのペイロードがＩＰｖ４またはＩＰｖ６の場合、ＥＨＣはフレームが必須の最小サイズになるように、必要に応じてパディングバイトを識別し追加する。

図３Ｃは、本発明の例示的な実施形態による、この第２のオプションのためのＥＨＣ解凍器およびＲｏＨＣ解凍器の併用操作を示す。

図３Ｃは、パケット構造３１０、ＥＨＣ解凍器３２０、およびＲＯＨＣ解凍器３３０を示す。パケット構造３１０はパケット構造ＡからＦを含み、ＥＨＣ解凍器３２０は、本発明の実施形態例にしたがった操作フローを含む。ＲＯＨＣ解凍器３３０フローのこれらの操作は、第１のステップでＲＯＨＣ解凍器に到着する圧縮パケットがあり、後続のステップでＩＰヘッダが解凍され、後続のステップで解凍されたＩＰパケットがＥＨＣ解凍器３２０に提供されることを含む。図３ＣのステップＡ１に示すように、ＥＨＣが有効か無効かを示す情報と共に、圧縮パケットがＰＤＣＰによって提供される。図３ＣのステップＡ２に示すように、ＩＰヘッダは解凍され、ペイロードの前に追加される。次に、図３Ｃに示すように、解凍されたＩＰパケットはＥＨＣ解凍器に供給される。

［４．フィードバック・メッセージ］
ＥＨＣおよびＲｏＨＣの両方は、解凍器から圧縮器にフィードバック・メッセージを送信する必要がある。これらは、ＰＤＣＰによって異なるペイロード識別子を付与することによって区別される。図４は、本発明の例示的な実施形態による、そのようなフィードバックの例を示す。

図４に示すように、１ビットＤ／Ｃ４０１、３ビットＰＤＵタイプ４２０、および４ビットＲ（予約済み）４３０が示されている。ここで、図４について、

１ビットＤ／Ｃ４０１は、
０－ＰＤＣＰ制御ＰＤＵ、または、
１－ＰＤＣＰデータＰＤＵ、
に対する、および、

３ビットＰＤＵタイプ４２０は、
０００－ＰＤＣＰステータスレポート、
００１－散在ＲＯＨＣフィードバック、
０１０－ＥＨＣフィードバック、
０１１－ＥＨＣ＋ＲＯＨＣフィードバック、および、
１００－１１１－リザーブ、
に対する。

現在、ＰＤＣＰＰＤＵタイプは、ＰＤＣＰ制御ＰＤＵが散在ＲｏＨＣフィードバックであるかどうかを区別する。このアプローチはもともと、ＰＤＣＰレイヤ上に既にあるフィードバック・メッセージに特別な処理（優先権）を与えることができるように選択されており、ＥＨＣとＲｏＨＣが一緒に操作する場合にもこの原理に従うことが重要であると考えられる。新しいアプローチはＥＨＣフィードバックおよびＥＨＣ＋ＲｏＨＣフィードバックの組み合わせオプションをサポートするために、新しいＰＤＵタイプ（例えば、上述のように「０１０」および「０１１」）を導入することである。組み合わされたフィードバックは、ＥＨＣフィードバックが常に固定長であるか、またはその長さが、例えば、構造内に明示的な長さヘッダ／インジケータを含めることによって、その構造から推定され得ることを必要とする。ＲｏＨＣフィードバック長さは、既にこの特性を有する。

この新しいアプローチはまた、タイプＥＨＣ＋ＲｏＨＣフィードバックの単一のＰＤＣＰ制御ＰＤＵ内で、複数のＥＨＣおよび／またはＲｏＨＣコンテキストからのフィードバック・メッセージを組み合わせることを可能にする。

単一のＰＤＣＰ制御ＰＤＵにおいてデータ無線ベアラ（ＤＲＢ）のＥＨＣフィードバックとＲｏＨＣフィードバックとを組み合わせることは、各パケットに対して追加される下位レイヤヘッダのオーバヘッドが回避されるので、Ｕｕインタフェースを介して（すなわち、ＵＥとｇＮＢとの間で）送信されるバイトの総数を低減するのに役立つ。

図５Ａは、限定はしないが、例えば、図１におけるようなｅＮＢまたはＵＥ１１０のようなＲＡＮノードケ７０のようなネットワークノードのようなネットワークデバイスによって実行され得る操作を示す。図５Ａのステップ５１０に示すように、イーサネット・パケット・データのイーサネット・ヘッダに対する第１の圧縮操作が実行される。図５Ａのステップ５２０に示すように、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判定される。図５Ａのステップ５３０に示すように、イーサネット・パケット・データ内に少なくとも１つのインターネット・プロトコル・パケットを識別するものがある。次に、図５Ａのステップ５４０に示すように、少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対して第２の圧縮操作を実行し、第２の圧縮操作は、第１の圧縮操作のコンテキストまたはプロファイルとは独立した、示されたコンテキストまたはプロファイルのうちの少なくとも１つに基づく。

上記の段落に記載されている実施例にしたがって、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断することは、イーサネット・ヘッダのイーサタイプフィールドに基づく。

上記段落で説明した例示的な実施形態によれば、示されたコンテキストまたはプロファイルのうちの少なくとも１つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む。

上記段落で説明した例示的な実施形態によれば、示されたコンテキストまたはプロファイルのうちの少なくとも１つは、イーサネット・パケット・データのイーサネット・ヘッダに関連付けられた値に基づく。

上述の段落に記載された実施形態例によれば、イーサネット・パケット・データの識別されたタイプのイーサネット・ペイロードがＩＰｖ４またはＩＰｖ６タイプのペイロードの１つことに基づいて、少なくとも１つのインターネット・プロトコル・パケットのパケット長を決定すること、およびイーサネット・パケット・データのパケット長がインターネット・プロトコル・パケットのパケット長より長い場合には、イーサネット・パケット・データからイーサネット・レベル・パッド・バイトを除去することがある。上記の段落で説明した例示的な実施形態によれば、第１の圧縮操作を実行することは、第２の圧縮操作によって使用される少なくとも１つのインターネット・プロトコル・パケットまたは少なくとも１つのインターネット・プロトコル・パケットの第１のパケットへのポインタを第２の圧縮操作に提供することを含む。

上記の段落で説明した例示的な実施形態による操作が、通信ネットワークの少なくとも１つのユーザデバイスまたは少なくとも１つの基地局のうちの１つによって実行される。

上記段落で説明した例示的な実施形態によれば、第１の圧縮操作はイーサネット・ヘッダ圧縮操作を含み、第２の圧縮操作はロバストなヘッダ圧縮操作を含む。

上記段落で説明した例示的な実施形態によれば、制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを受信する。

上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、第１の圧縮操作および第２の圧縮操作のうちの少なくとも１つに対する支持を示すパケットデータ制御プロトコルデータユニットタイプを備える。

上記段落で説明した例示的な実施形態によれば、パケットデータ制御プロトコルデータユニットタイプは３ビットを含む。

上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、またはイーサネット・ヘッダ圧縮フィードバックまたはロバスト・ヘッダ圧縮フィードバックのうちの組み合わせられた少なくとも１つを示す。

上記段落で説明した例示的な実施形態によれば、組み合わされたイーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮フィードバックのうちの少なくとも１つと、イーサネット・ヘッダ圧縮の長さヘッダまたはインジケータのうちの少なくとも１つとが含まれる。

上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮のうちの少なくとも１つのコンテキスト割り当てからのフィードバックを含む。

上記段落で説明した例示的な実施形態によれば、ロバスト・ヘッダ圧縮のコンテキスト割り当ては、イーサネット・ヘッダ圧縮のコンテキスト割り当てから独立している。

上述したような本発明の例示的な実施形態によれば、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０、メモリ１２５および／またはメモリ１５５、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２、および、図１のようなプロセッサ１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１）イーサネット・パケット・データのイーサネット・ヘッダに対して、第１圧縮操作を実行するための手段を備える装置であって、該実行する手段は、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０、メモリ１２５および／またはメモリ１５５、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２、および、プロセッサ１２０および／または圧縮モジュール１４０－１、および／または、プロセッサ１５２、および／または、圧縮モジュール１５０－１、図１を参照）イーサネット・パケットが、インターネット・プロトコル・パケットを含むと決定する手段と、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０と、メモリ１２５および／またはメモリ１５５と、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２と、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２と、プロセッサ１２０および／または圧縮モジュール１４０－１と、プロセッサ１５２および／または圧縮モジュール１５０－１、図１を参照）イーサネット・パケット・データ内の少なくとも１つのインターネット・プロトコル・パケットを識別する手段と、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０と、メモリ１２５および／またはメモリ１５５と、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０ー２、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０ー２、および、１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１、図１参照）少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対する第２の圧縮操作であって、第１圧縮操作のコンテキストまたはプロファイルとは独立した、示されたコンテキストまたはプロファイルのうちの少なくとも１つに基づく、第２圧縮操作を実行する手段と、を備える、装置が存在する。

上記のパラグラフによる例示的な態様において、実施、決定、および識別のための少なくとも手段が、少なくとも１つのプロセッサ［図１のプロセッサ１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１］によって実行可能なコンピュータプログラム［コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／または、コンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２］で符号化された非一時的なコンピュータ可読媒体［図１のメモリ１２５および／またはメモリ１５５］を含む、

図５Ｂは、限定されるものではないが、例えば、図１におけるようなｅＮＢまたはＵＥ１１０のようなＲＡＮノードケ７０のようなネットワークノードのようなネットワークデバイスによって実行されることができる操作を示す。図５Ｂのステップ５５０に示すように、イーサネット・パケット・データのイーサネット・ヘッダへの第１の解凍操作が実行される。図５Ｂのステップ５６０に示すように、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断する。図５Ｂのステップ５７０に示されるように、イーサネット・パケット・データ内の少なくとも１つのインターネット・プロトコル・パケットを識別する。
次に、図５Ｂのステップ５８０に示すように、少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対する第２の解凍操作が実行され、第２の解凍操作は、第１の解凍操作とは独立したコンテキストまたはプロファイルの示された少なくとも１つに基づく。

上述の段落に記載された実施例にしたがって、示されたコンテキストまたはプロファイルの少なくとも１つはイーサネット・パケット・データのイーサネット・ヘッダに関連付けられ、イーサネット・パケット・データは少なくともイーサネット・パケットのヘッダに関連付けられたＩＰｖ６パケットの示されたＩＰｖ４を含む。

上記段落に記載された例示的な実施形態によれば、第１解凍操作を実行することは、第２解凍操作に、少なくとも１つのインターネット・プロトコル・パケット、または第２の解凍操作によって使用される少なくとも１つのインターネット・プロトコル・パケットの第１のパケットへのポインタを提供することを含む。

上記の段落で説明した例示的な実施形態による操作は、通信ネットワークの少なくとも１つのユーザデバイスまたは少なくとも１つの基地局のうちの１つによって実行される。

上記段落で説明した例示的な実施形態によれば、第１の解凍操作は、イーサネット・ヘッダ解凍操作を含み、第２の解凍操作はロバストなヘッダ解凍操作を含む。

上記段落で説明した例示的な実施形態によれば、制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを通信することがある。

上記段落で説明した例示的な実施形態によれば、組み合わされたイーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮フィードバックのうちの少なくとも１つと、イーサネット・ヘッダ圧縮の長さヘッダまたはインジケータのうちの少なくとも１つとが組み合わされる。

上記のような本発明の実施形態例にしたがって、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０、メモリ１２５、および／またはメモリ１５５、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２、ならびに、プロセッサ１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１、図１参照）イーサネット・パケット・データのイーサネット・ヘッダへの第１解凍操作を実行する手段と、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０、メモリ１２５および／またはメモリ１５５、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコ、ンピュータプログラムコード１５３および／または圧縮モジュール１５０－２、およびプロセッサ１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１、図１参照）イーサネット・パケットがインターネット・プロトコル・パケットを含むと決定する手段と、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０、図１のように、イーサネット・パケットがインターネット・プロトコル・パケットを含むこと、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコンピュータプログラムコード１５３および／または圧縮モジュール１５０－２、およびプロセッサ１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１、図１参照）イーサネット・パケット・データの内の少なくとも１つのインターネット・プロトコル・パケットを識別する手段と、（１つ以上のトランシーバ１３０および／または１つ以上のトランシーバ１６０、メモリ１２５および／またはメモリ１５５、コンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２、および、プロセッサ１２０および／または圧縮モジュール１４０－１、および／またはプロセッサ１５２および／または圧縮モジュール１５０－１、図１参照）少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダへ第２解凍操作を実行する手段であって、前記第２圧縮解除操作は、示された、前記第１圧縮解除操作とは独立したコンテキストまたはプロファイルの少なくとも１つに基づく、実行する手段と、を備える装置が存在する。

上記段落に係る発明の実施例の態様において、少なくとも、実行、決定、および識別するための手段は、コンピュータプログラムで符号化された［図１のようなコンピュータ・プログラム・コード１２３および／または圧縮モジュール１４０－２、および／またはコンピュータ・プログラム・コード１５３および／または圧縮モジュール１５０－２］、少なくとも１つのプロセッサによって実行可能な［図１のメモリ１２５および／またはメモリ１５５］、非一時的なコンピュータ可読媒体を構成する［図１のような、メモリ１２５、および／または、メモリ１５５］。

一般に、様々な態様は、ハードウェアまたは専用回路、ソフトウェア、ロジック、またはそれらの任意の組合せで実装され得る。例えば、いくつかの態様はハードウェアで実装されてもよく、他の態様はコントローラ、マイクロプロセッサ、または他の計算装置によって実行されてもよいファームウェアまたはソフトウェアで実装されてもよい。しかしながら、本発明はそれに限定されない。本発明の様々な態様はブロック図、フローチャートとして、またはいくつかの他の絵画的表現を使用して図示および目的され得るが、本明細書で目的されるこれらのブロック、装置、システム、技術、または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路もしくは論理、汎用ハードウェアもしくはコントローラ、または他の計算装置、あるいはそれらのいくつかの組合せで実装され得ることをよく理解されたい。

本発明の実施形態は、集積回路モジュールなどの様々な部品で実施することができる。集積回路の設計は高度に自動化された処理によるものであり、大規模である。論理レベルの設計を、エッチングされ、半導体基板上に形成される準備ができている整った半導体回路設計に変換するための、複雑で強力なソフトウェアツールが利用可能である。

「例示的」という語は、本明細書では「例、または例示として働く」ことを意味するために使用され、「例示的」として本明細書で説明される任意の実施形態は必ずしも、他の実施形態よりも好ましい、または有利であると解釈されるべきではない。この詳細な説明に記載される実施形態の全ては、当業者が本発明を実施または使用することを可能にするために提供される例示的な実施形態であり、特許請求の範囲によって定義される本発明の範囲を限定するものではない。

前述の説明は、本発明を実施するために本発明者によって現在企図されている最良の方法および装置の完全かつ有益な説明を、例示的かつ非限定的な例として提供した。しかしながら、添付の図面および付随の請求項を熟読する際に、前述の説明を考慮して、種々の修正および適合が、当業者に明白になるであろう。しかしながら、本発明の教示の全てのそのような同様の修正は、依然として本発明の範囲内にある。

用語「接続された」、「結合された」、またはその任意の変形は２つ以上の要素間の直接または間接の任意の接続または結合を意味し、「接続された」または「結合された」２つの要素間の１つ以上の中間要素の存在を包含し得ることに留意されたい。要素間の結合または接続は物理的、論理的、またはそれらの組み合わせであり得る。本明細書で使用されるように、２つの要素は、１つ以上のワイヤ、ケーブル、および／または印刷された電気的接続の使用によって、ならびに無線周波数領域、マイクロ波領域、および光学（可視および不可視の両方）領域における波長を有する電磁エネルギーなどの電磁エネルギーの使用によって、いくつかの非限定的かつ非網羅的な例として、「接続された」または「結合された」とみなされ得る。

さらに、本発明の好ましい実施形態の特徴のいくつかは、他の特徴を対応して使用することなく有利に使用することができる。したがって、前述の説明は、本発明の原理を単に例示するものであって、本発明を制限するものではないと考えられるべきである。

Claims

イーサネット・パケット・データのイーサネット・ヘッダへの第１圧縮操作を実行するステップを含む方法であって、
前記イーサネット・パケットがインターネット・プロトコル・パケットを含むと決定するステップと、
前記イーサネット・パケット・データ内の少なくとも１つのインターネット・プロトコル・パケットを識別するステップと、
前記少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダへの第２圧縮操作を実行するステップであって、前記第２圧縮操作は、前記第１圧縮操作とは独立したコンテキストまたはプロファイルのうちの少なくとも１つに基づく、ステップと、
を含む、方法。
前記イーサネット・パケットが前記インターネット・プロトコル・パケットを含むと決定する前記ステップは、前記イーサネット・ヘッダのイーサタイプフィールドに基づく、請求項１に記載の方法。
前記コンテキストまたはプロファイルのうちの少なくとも１つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む、請求項１に記載の方法。
前記コンテキストまたはプロファイルの少なくとも１つは、イーサネット・パケット・データのイーサネット・ヘッダに関連する値に基づく、請求項３に記載の方法。
ＩＰｖ４またはＩＰｖ６タイプのペイロードのいずれかである、前記イーサネット・パケット・データのイーサネット・ペイロードの識別されたタイプに基づいて、前記少なくとも１つのインターネット・プロトコル・パケットのパケット長を決定するステップを含み、
前記イーサネット・パケット・データのパケット長が前記インターネット・プロトコル・パケットの前記パケット長より長い場合には、前記方法は、前記イーサネット・パケット・データからイーサネットレベル・パディングバイトを削除するステップを含む、
請求項１に記載の方法。
前記第１圧縮操作を実行する前記ステップは、前記第２圧縮操作に、前記第２圧縮操作によって使用するために、前記少なくとも１つのインターネット・プロトコル・パケットまたは前記少なくとも１つのインターネット・プロトコル・パケットの第１パケットへのポインタを提供するステップを含む、請求項１に記載の方法。
前記方法は、通信ネットワークの少なくとも１つのユーザデバイスまたは少なくとも１つの基地局のうちの１つによって実行される、請求項１に記載の方法。
前記第１圧縮操作はイーサネット・ヘッダ圧縮操作を含み、
前記第２圧縮操作は、ロバストなヘッダ圧縮操作を含む、
請求項１に記載の方法。
制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを受信するステップをさらに含む、請求項１に記載の方法。
前記圧縮フィードバック・メッセージは、前記第１圧縮操作および前記第２圧縮操作のうちの少なくとも１つに対するサポートを示すパケットデータ制御プロトコルデータユニットタイプを含む、請求項９に記載の方法。
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、または、イーサネット・ヘッダ圧縮フィードバックとロバスト・ヘッダ圧縮フィードバックとの組み合わせを示す、請求項９に記載の方法。
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮のうちの少なくとも１つのコンテキスト割り当てからのフィードバックを含む、請求項９に記載の方法。
イーサネット・パケット・データのイーサネット・ヘッダへの第１解凍操作を実行するステップを含む方法であって、
該実行するステップは、前記イーサネット・パケットがインターネット・プロトコル・パケットを含むと決定するステップと、
前記イーサネット・パケット・データ内の少なくとも１つのインターネット・プロトコル・パケットを識別するステップと、
前記少なくとも１つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダへの第２解凍操作を実行するステップであって、前記第２解凍操作は、前記第１解凍操作とは独立したコンテキストまたはプロファイルの少なくとも１つに基づく、ステップと、を含む、方法。
前記イーサネット・パケットが前記インターネット・プロトコル・パケットを含むと決定する前記ステップは、前記イーサネット・ヘッダのイーサタイプフィールドに基づく、請求項１３に記載の方法。
前記コンテキストまたはプロファイルのうちの少なくとも１つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む、請求項１３に記載の方法。
前記コンテキストまたはプロファイルの少なくとも１つは、前記イーサネット・パケット・データの前記イーサネット・ヘッダに関連する値に基づく、請求項１５に記載の方法。
前記コンテキストまたはプロファイルの少なくとも１つは、前記イーサネット・パケット・データの前記イーサネット・ヘッダに関連付けられ、
前記イーサネット・パケット・データは、前記少なくともイーサネット・パケットの前記ヘッダに関連付けられたＩＰｖ６パケットのＩＰｖ４を含む、
請求項１３に記載の方法。
前記第１解凍操作を実行するステップは、前記第２解凍操作に、前記第２解凍操作によって使用するために、前記少なくとも１つのインターネット・プロトコル・パケットまたは前記少なくとも１つのインターネット・プロトコル・パケットの第１パケットへのポインタを提供するステップを含む、請求項１３に記載の方法。
前記方法は、通信ネットワークの少なくとも１つのユーザデバイスまたは少なくとも１つの基地局のうちの１つによって実行される、請求項１３に記載の方法。
前記第１解凍操作はイーサネット・ヘッダ解凍操作を含み、
前記第２解凍操作は、ロバスト・ヘッダ解凍操作を含む、
請求項１３に記載の方法。
制御プロトコル・データ・ユニットにおいて圧縮フィードバック・メッセージを通信するステップをさらに含む、請求項１３に記載の方法。
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、または、イーサネット・ヘッダ圧縮フィードバックとロバスト・ヘッダ圧縮フィードバックとの組み合わせを示す、請求項２１に記載の方法。
少なくとも１つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも１つのメモリと、を備える装置であって、
前記少なくとも１つのメモリと、前記コンピュータ・プログラム・コードとは、前記少なくとも１つのプロセッサを用いて、前記装置に、請求項１ないし１２のいずれか１項、または、請求項１３ないし２２のいずれか１項に記載の方法を実行させるように構成される、装置。
請求項１ないし１２のいずれか１項、または、請求項１３ないし２２のいずれか１項に記載の方法を実行するための手段を含む装置。
請求項１ないし１２のいずれか１項、または、請求項１３ないし２２のいずれか１項に記載の方法を実行するためのプログラムコードを含むコンピュータプログラム。