(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-11-28
(54)【発明の名称】イーサネット・ヘッダ圧縮とロバスト・ヘッダ圧縮の併用
(51)【国際特許分類】
H04L 69/04 20220101AFI20221118BHJP
H04W 80/04 20090101ALI20221118BHJP
H04L 69/22 20220101ALI20221118BHJP
H04W 28/06 20090101ALI20221118BHJP
H04W 80/02 20090101ALI20221118BHJP
【FI】
H04L69/04
H04W80/04
H04L69/22
H04W28/06 110
H04W80/02
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2022519395
(86)(22)【出願日】2020-09-14
(85)【翻訳文提出日】2022-03-25
(86)【国際出願番号】 FI2020050584
(87)【国際公開番号】W WO2021058855
(87)【国際公開日】2021-04-01
(31)【優先権主張番号】201941039186
(32)【優先日】2019-09-27
(33)【優先権主張国・地域又は機関】IN
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
(71)【出願人】
【識別番号】515076873
【氏名又は名称】ノキア テクノロジーズ オサケユイチア
(74)【代理人】
【識別番号】100099759
【氏名又は名称】青木 篤
(74)【代理人】
【識別番号】100123582
【氏名又は名称】三橋 真二
(74)【代理人】
【識別番号】100092624
【氏名又は名称】鶴田 準一
(74)【代理人】
【識別番号】100141162
【氏名又は名称】森 啓
(72)【発明者】
【氏名】マルクス イソマキ
(72)【発明者】
【氏名】ダビド コジオル
(72)【発明者】
【氏名】ディーパ マラパッティ ラビンドライア
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067AA13
5K067BB21
5K067HH21
(57)【要約】
【課題】イーサネット・ヘッダ圧縮とロバスト・ヘッダ圧縮の併用。
【解決手段】本発明は、イーサネット・ヘッダ圧縮およびロバストなヘッダ圧縮の併用使用のための方法を提供する。より詳細には、イーサネット・パケット・データのイーサネット・ヘッダに対する第1の圧縮/解凍操作を実行することと、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断することと、
イーサネット・パケット・データ内の少なくとも1つのインターネット・プロトコル・パケットを識別することと、前記少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対して第2の圧縮/解凍操作を実行することと、を含む方法であって、前記第2の圧縮/解凍操作は前記第1の圧縮/解凍操作とは独立したコンテキストまたはプロファイルのうちの示された少なくとも1つに基づく、方法が開示される。
【選択図】
図5A
【特許請求の範囲】
【請求項1】
イーサネット・パケット・データのイーサネット・ヘッダへの第1圧縮操作を実行するステップを含む方法であって、
前記イーサネット・パケットがインターネット・プロトコル・パケットを含むと決定するステップと、
前記イーサネット・パケット・データ内の少なくとも1つのインターネット・プロトコル・パケットを識別するステップと、
前記少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダへの第2圧縮操作を実行するステップであって、前記第2圧縮操作は、前記第1圧縮操作とは独立したコンテキストまたはプロファイルのうちの少なくとも1つに基づく、ステップと、
を含む、方法。
【請求項2】
前記イーサネット・パケットが前記インターネット・プロトコル・パケットを含むと決定する前記ステップは、前記イーサネット・ヘッダのイーサタイプフィールドに基づく、請求項1に記載の方法。
【請求項3】
前記コンテキストまたはプロファイルのうちの少なくとも1つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む、請求項1に記載の方法。
【請求項4】
前記コンテキストまたはプロファイルの少なくとも1つは、イーサネット・パケット・データのイーサネット・ヘッダに関連する値に基づく、請求項3に記載の方法。
【請求項5】
IPv4またはIPv6タイプのペイロードのいずれかである、前記イーサネット・パケット・データのイーサネット・ペイロードの識別されたタイプに基づいて、前記少なくとも1つのインターネット・プロトコル・パケットのパケット長を決定するステップを含み、
前記イーサネット・パケット・データのパケット長が前記インターネット・プロトコル・パケットの前記パケット長より長い場合には、前記方法は、前記イーサネット・パケット・データからイーサネットレベル・パディングバイトを削除するステップを含む、
請求項1に記載の方法。
【請求項6】
前記第1圧縮操作を実行する前記ステップは、前記第2圧縮操作に、前記第2圧縮操作によって使用するために、前記少なくとも1つのインターネット・プロトコル・パケットまたは前記少なくとも1つのインターネット・プロトコル・パケットの第1パケットへのポインタを提供するステップを含む、請求項1に記載の方法。
【請求項7】
前記方法は、通信ネットワークの少なくとも1つのユーザデバイスまたは少なくとも1つの基地局のうちの1つによって実行される、請求項1に記載の方法。
【請求項8】
前記第1圧縮操作はイーサネット・ヘッダ圧縮操作を含み、
前記第2圧縮操作は、ロバストなヘッダ圧縮操作を含む、
請求項1に記載の方法。
【請求項9】
制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを受信するステップをさらに含む、請求項1に記載の方法。
【請求項10】
前記圧縮フィードバック・メッセージは、前記第1圧縮操作および前記第2圧縮操作のうちの少なくとも1つに対するサポートを示すパケットデータ制御プロトコルデータユニットタイプを含む、請求項9に記載の方法。
【請求項11】
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、または、イーサネット・ヘッダ圧縮フィードバックとロバスト・ヘッダ圧縮フィードバックとの組み合わせを示す、請求項9に記載の方法。
【請求項12】
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮のうちの少なくとも1つのコンテキスト割り当てからのフィードバックを含む、請求項9に記載の方法。
【請求項13】
イーサネット・パケット・データのイーサネット・ヘッダへの第1解凍操作を実行するステップを含む方法であって、
該実行するステップは、前記イーサネット・パケットがインターネット・プロトコル・パケットを含むと決定するステップと、
前記イーサネット・パケット・データ内の少なくとも1つのインターネット・プロトコル・パケットを識別するステップと、
前記少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダへの第2解凍操作を実行するステップであって、前記第2解凍操作は、前記第1解凍操作とは独立したコンテキストまたはプロファイルの少なくとも1つに基づく、ステップと、を含む、方法。
【請求項14】
前記イーサネット・パケットが前記インターネット・プロトコル・パケットを含むと決定する前記ステップは、前記イーサネット・ヘッダのイーサタイプフィールドに基づく、請求項13に記載の方法。
【請求項15】
前記コンテキストまたはプロファイルのうちの少なくとも1つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む、請求項13に記載の方法。
【請求項16】
前記コンテキストまたはプロファイルの少なくとも1つは、前記イーサネット・パケット・データの前記イーサネット・ヘッダに関連する値に基づく、請求項15に記載の方法。
【請求項17】
前記コンテキストまたはプロファイルの少なくとも1つは、前記イーサネット・パケット・データの前記イーサネット・ヘッダに関連付けられ、
前記イーサネット・パケット・データは、前記少なくともイーサネット・パケットの前記ヘッダに関連付けられたIPv6パケットのIPv4を含む、
請求項13に記載の方法。
【請求項18】
前記第1解凍操作を実行するステップは、前記第2解凍操作に、前記第2解凍操作によって使用するために、前記少なくとも1つのインターネット・プロトコル・パケットまたは前記少なくとも1つのインターネット・プロトコル・パケットの第1パケットへのポインタを提供するステップを含む、請求項13に記載の方法。
【請求項19】
前記方法は、通信ネットワークの少なくとも1つのユーザデバイスまたは少なくとも1つの基地局のうちの1つによって実行される、請求項13に記載の方法。
【請求項20】
前記第1解凍操作はイーサネット・ヘッダ解凍操作を含み、
前記第2解凍操作は、ロバスト・ヘッダ解凍操作を含む、
請求項13に記載の方法。
【請求項21】
制御プロトコル・データ・ユニットにおいて圧縮フィードバック・メッセージを通信するステップをさらに含む、請求項13に記載の方法。
【請求項22】
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、または、イーサネット・ヘッダ圧縮フィードバックとロバスト・ヘッダ圧縮フィードバックとの組み合わせを示す、請求項21に記載の方法。
【請求項23】
少なくとも1つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも1つのメモリと、を備える装置であって、
前記少なくとも1つのメモリと、前記コンピュータ・プログラム・コードとは、前記少なくとも1つのプロセッサを用いて、前記装置に、請求項1ないし12のいずれか1項、または、請求項13ないし22のいずれか1項に記載の方法を実行させるように構成される、装置。
【請求項24】
請求項1ないし12のいずれか1項、または、請求項13ないし22のいずれか1項に記載の方法を実行するための手段を含む装置。
【請求項25】
請求項1ないし12のいずれか1項、または、請求項13ないし22のいずれか1項に記載の方法を実行するためのプログラムコードを含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
[関連出願]
本出願は2019年9月27日に出願されたインド特許出願第201941039186号からの優先権を主張し、その全体が本明細書に組み込まれる。本発明の例示的な実施形態による教示は、一般に、通信ヘッダの圧縮に関し、より具体的には、イーサネット(登録商標)および/またはIPヘッダを圧縮するためのロバスト・ヘッダ圧縮とイーサネット・ヘッダ圧縮との組み合わせ使用に関する。
【背景技術】
【0002】
このセクションは、特許請求の範囲に記載されている本発明の背景またはコンテキストを提供することを意図している。本明細書の説明は追求することができる概念を含むことがあるが、必ずしも以前からの着想または追求された概念ではない。したがって、本明細書で特に断らない限り、このセクションに記載されているものは、本明細書の説明および特許請求の範囲の先行技術ではなく、このセクションに含めることによって先行技術であると認められるものではない。
【0003】
本明細書および/または図面に見られる一定の略語は、以下のように定義される。
5GS:5Gシステム
DRB:データ無線ベアラ
EHC:イーサネット・ヘッダ圧縮
gNB:5G基地局
IEEE:電気電子技術者協会(Institute of Electrical and Electronics Engineers)
IP:インターネットプロトコル
PDCP:パケットデータ収束プロトコル
PDU:プロトコルデータ単位
RoHC:ロバスト・ヘッダ圧縮
TSN:時間敏感ネットワーキング(time sensitive networking)
UE:ユーザ機器
【0004】
データ通信ネットワークは、互いにデータを通信するように結合され構成された、様々なルータ、スイッチ、ブリッジ、および基地局またはユーザ装置のような他のネットワーク装置を含むことができる。これらの装置は本明細書では「ネットワーク装置」または「ネットワークノード」と呼ぶことができ、通信ネットワーク上の様々なネットワーク要素は、事前定義されたプロトコルを使用して互いに通信する。これらの異なるプロトコルは、ネットワーク要素間の通信のためにどのように信号が形成されるべきかのような、通信の異なる態様を実行するために使用されてもよい。
【0005】
一般的に実装されているネットワーキングまたはインターネットワーキングプロトコルの1つは、イーサネットと呼ばれる。イーサネットプロトコルは、IEEE(Institute of Electrical and Electronics Engineers)によって定義されている。プロトコルファミリ(IEEE 802.3)は、ローカルエリアネットワークのイーサネットを定義し、もう1つのプロトコルファミリ(IEEE802.1)はキャリアネットワークなどのワイドエリアネットワークで使用するイーサネットを定義する。
【0006】
いくつかの無線通信システムは、UEと通信する音声またはビデオ送信のようなパケット送信のためのシグナリングオーバヘッドを低減するためにロバスト・ヘッダ圧縮(RoHC)を使用する。その結果、圧縮操作を管理し改善するための方法が有益であることが分かる。
【0007】
本発明の例示的な実施形態は、上述のイーサネットなどのプロトコルの通信および圧縮を改善するように働く。
【図面の簡単な説明】
【0008】
本開示の様々な実施形態の上記および他の態様、特徴、および利点は、添付の図面を参照した以下の詳細な説明からより完全に明らかになる。図面は本開示の実施形態のより良い理解を容易にするために示すものであり、必ずしも縮尺通りには描かれていない。
【
図1】
図1は、本発明の種々の態様を実施する際に使用される種々のデバイスの高レベルブロック図を示す。
【
図2】
図2は、本発明の例示的な実施形態による、第1のオプションのためのイーサネット・ヘッダ圧縮器およびRoHC圧縮器の併用操作を示す。
【
図3A】
図3Aは、本発明の例示的な実施形態による、第1のオプションのためのイーサネット・ヘッダ解凍器およびRoHC解凍器の併用操作を示す。
【
図3B】
図3Bは、本発明の例示的な実施形態による、第2のオプションのためのイーサネット・ヘッダ圧縮器およびRoHC圧縮器の併用操作を示す。
【
図3C】
図3Cは、本発明の例示的な実施形態による、第2のオプションのためのイーサネット・ヘッダ解凍器およびRoHC解凍器の別の併用操作を示す。
【
図4】
図4は、本発明の例示的な実施形態によるフィードバックメッセージフォーマットを示す。
【
図5A】
図5Aおよび
図5Bは、それぞれ、装置によって実行され得る、本発明の例示的な実施形態による方法を示す。
【
図5B】
図5Aおよび
図5Bは、それぞれ、装置によって実行され得る、本発明の例示的な実施形態による方法を示す。
【発明を実施するための形態】
【0009】
本発明の例示的な実施形態では、少なくとも、イーサネットおよび/またはIPヘッダを圧縮するために、ロバスト・ヘッダ圧縮とイーサネット・ヘッダ圧縮との組み合わせ使用を実行する方法および装置が提案される。
【0010】
3GPP RAN2 WGでは、NR Industrial IoT WIの一環として、イーサネットPDUセッションのイーサネット・ヘッダ圧縮(EHC)を標準化しており、その中の1つの提案で以下のように示されている。
----- 以下引用 -----
3.NR TSC関連強化の詳細な目標は以下のとおりである。
(...)
● 構造認識アルゴリズム[RAN2]に基づいてイーサネット・ヘッダ圧縮を指定する。
○ NRの設計原理が合意されると、LTEのためのイーサネット・ヘッダ圧縮ソリューションが指定される。影響を受けたLTE仕様は、最新RAN#85で追加される。
-----以上引用-----
【0011】
RAN2では、IP PDUセッションのIPおよびトランスポートプロトコル層のヘッダを圧縮するために使用されるRoHC(Robust Header Compression)をEHCのベースとせず、新しいフレームワークを開発することが決定されており、RoHCの原理の少なくとも一部を、潜在的に簡略化した形で再利用すると期待される。
【0012】
EHCは、ペイロードサイズが小さく、タイムセンシティブ(時間に敏感な)イーサネット通信に最も有用である。このタイプのトラフィックは、現在、イーサネット上では通常IPを使用せず、プロフィネット(Profinet)やイーサキャット(Ethercat)などの産業用イーサネットアプリケーションプロトコルを使用している。しかしながら、エンドツーエンドIP通信は、タイムセンシティブアプリケーション(産業制御、仮想現実、...)に対しても広く使用される可能性が高いが、これらの場合のいくつかでは、遅延と信頼性保証が3GPP標準によってもサポートされているTSNのようなメカニズムを通して、イーサネットレベルで提供されている。
【0013】
したがって、いくつかのタイムセンシティブネットワーキング展開では、IPパケットが、5GイーサネットPDUセッションを介してイーサネットで伝送されるか、または、IPパケットが、5G IP PDUセッションを介してイーサネットで伝送される可能性がある。どちらの場合も、イーサネット・ヘッダだけでなく、IPヘッダとUDP/IPヘッダも圧縮できると有用である。3GPP TR38.825バージョン16.0.0は、産業IoT強化に関する3GPP RAN WGの試験フェーズを要約しており、この側面を以下のように要約している。
-----以下引用-----ーー
6.6.2.3 IPヘッダ圧縮との関係
イーサネットは、IPまたは非IPトラフィックを転送できる。この態様は、例えばR2ー1817572([13])に記載されている。IPヘッダ圧縮は、イーサネット・ヘッダ圧縮が採用される場合に考慮されてもよく、この場合、イーサネットおよびIPの併用/統合ヘッダ圧縮と同様に、独立/分離ヘッダ圧縮ソリューションの両方を想定することができる。併用圧縮方式における固有の複雑さとモジュール方式の利点を考えると、構造を考慮したイーサネット・ヘッダ圧縮方式を開発した場合、併用ソリューションの中でIPヘッダ圧縮を考慮すべきではない。
-----以上引用-----ーー
【0014】
IPとイーサネットの両方を圧縮するアルゴリズムの併用操作は複雑であると考えられていたため、イーサネットとIPヘッダの両方を圧縮することを可能にする解決策が必要であったので、別々のアルゴリズムを使用することが好ましいとされた。これは、EHCとRoHCを重ね合わせて活用することで実現できるが、一方で、課題も抱えている。
【0015】
実際的な問題は、イーサネット・ヘッダ圧縮(EHC)と既存のRoHC圧縮フレームワークのために3GPP RAN2がとるアプローチを与えられた場合、最も効率的で標準準拠の方法でIP/イーサネットとUDP/IP/イーサネット・ヘッダ構造を圧縮する方法である。原則として3つのアプローチがある。
1.イーサネットだけでなく、上位層ヘッダを圧縮できるEHC用の追加プロファイルを定義する。
【0016】
このアプローチの問題は、EHCが非常に静的なイーサネット・ヘッダを扱えるようになるように、意図的にできるだけ簡単に定義されており、より複雑で動的なIPおよびトランスポート層ヘッダに容易に拡張できないことである。この手法は、前述のNR IIoTに関する検討段階でも複雑と見られていた。
【0017】
2.イーサネット・ヘッダと既存のIPおよびトランスポート層プロファイルを組み合わせた追加のRoHCプロファイルを定義する。
【0018】
これは技術的に最も実行可能なアプローチであるが、3GPP RAN2において拒絶された。
【0019】
3.EHCとRoHCを同じIPまたはイーサネットPDUセッション内で使用する方法を、EHCがイーサネット・ヘッダを圧縮し、RoHCが上位層ヘッダをそのプロファイルのいずれかで圧縮するように定義する。
【0020】
これは、本発明の例示的な実施形態において採用されるアプローチである。それは、2つの圧縮フレームワークが特定のPDUセッションに対して同時にどのようにネゴシエートされるか、それらの各々が可能な限り他から独立するようにそれらがどのように操作し相互作用するかを解決することを必要とする。
【0021】
EHCとRoHCの組合せは、イーサネットとIPパッドの両方についての理解の組合せであり、IP/イーサネット・パケットからイーサネットレベルパディングを取り除く機会を与えることに注目する価値がある。イーサネット標準では、歴史的な理由により、最小フレームサイズは64バイトである。フレーム内の実際のペイロードが64バイトに達するまでに必要な量より小さい場合、パディングバイトがペイロードの先端に追加される。イーサネット・ヘッダ圧縮の一部として、イーサネットフレームからパディングを削除できることは有益である。これには実際のペイロードの終わりとパッドの開始位置を知るために、IPパケット長などの上位層ヘッダを調べる必要がある。したがって、デフォルトではEHCはそれ自体ではこれを行うことができない。しかしながら、RoHCとEHCとを組み合わせて使用する場合には、これが可能である。これを行うための方法が、本発明の例示的な実施形態に含まれている。
【0022】
EHCは3GPPでの仕様にすぎず、この問題は、EHCとRoHCが、イーサネットまたはIP PDUセッションを介してIP/イーサネット・ヘッダで連携することにおいて非常に特有である。
【0023】
IETFでは2009年ごろ、802(イーサネット、Wi-Fi)ネットワークを介したRoHCに関する提案があったが、これらは、RoHCが、本発明の例示的な実施形態の場合のようなイーサネットリンクの中間ではなく、イーサネットリンクの終点に配備される場合に対処するものである。ここで、RoHCとEHCはイーサネットリンクの終点で操作するのではなく、その中間で操作する。さらに、IETF提案はイーサネット・ヘッダの圧縮を考慮しておらず、IETFでの作業は放棄された。
【0024】
イーサネットパディング除去のために、3GPPでは、EHC圧縮器が、さもなければ小さすぎるのであろうフレームにパディングを追加することによってパディングを除去した状況のために、EHC解凍器を準備すべきであるという提案がなされている。しかしながら、EHC圧縮器がどのようにこれを行うことができるかについての仕様はなく、これは独自のオプションとして残されている。
【0025】
IPとイーサネット・ヘッダ圧縮の併用操作の態様は、本出願時のいくつかのRAN2の貢献の一部として、本明細書で議論されている。しかしながら、これらの寄与は、本明細書に開示されるような本発明の実施形態による詳細を開示しない。例えば、これらの寄与のいずれも、本発明の例示的な実施形態の焦点でいかなるEHCおよびRoHC圧縮器/解凍器相互作用も開示せず、圧縮スキーム確立中のフィードバックのいかなる態様も開示または議論しない。
【0026】
適切に協働するために、本発明の例示的な実施形態は、EHCとRoHCとの間の少なくとも4つの必要な態様を解決する。これらの態様には、
1.複合操作のサポートを曖昧さなく表現できるようにする、同一PDCPコンテキストにおけるEHCとRoHCのネゴシエーションのシンタックスとセマンティクス、
2.EHCおよびRoHC圧縮アルゴリズムを使用するデータパケットのための圧縮器操作、
3.EHC および RoHC 解凍アルゴリズムを使用したデータパケットの解凍操作、および/または、
4.EHCとRoHCの両方に対する複合フィードバックオプションを含むフィードバックメッセージング、
を含む。
【0027】
本発明の例示的な実施形態では、これらのそれぞれに対する解決策が提示される。
【0028】
本発明の例示的な実施形態をさらに詳細に説明する前に、
図1を参照する。
図1は、本発明の種々の態様を実施する際に使用される種々のデバイスの高レベルブロック図を示す。
【0029】
図1を参照すると、この図は、例示的な実施形態を実施することができる1つの可能な非限定的な例示的なシステムを示している。
図1において、ユーザ機器(UE)110は、無線ネットワーク100と無線通信している。UEは、無線ネットワークにアクセスできる無線装置(典型的にはモバイルデバイス)である。UEは例えば、携帯電話(または「携帯」電話と呼ばれる)および/または携帯端末機能を有するコンピュータであってもよい。例えば、UEまたは情報処理装置は、ポータブル、ポケット、ハンドヘルド、コンピュータ埋め込みまたは車載モバイルデバイスであってもよく、言語シグナリングおよび/またはRANとのデータ交換を実行する。
【0030】
UE110は、1つ以上のバス127を介して相互接続された1つ以上のプロセッサ120、1つ以上のメモリ125、および1つ以上のトランシーバ130を含む。1つ以上のトランシーバ130の各々は、受信機、Rx、132および送信機、Tx、133を含む。1つ以上のバス127は、アドレス、データ、または制御バスとすることができ、マザーボードまたは集積回路上の一連のライン、光ファイバまたは他の光通信機器などの任意の相互接続機構を含むことができる。1つ以上のトランシーバ130は、1つ以上のアンテナ128に接続される。1つ以上のメモリ125は、コンピュータ・プログラム・コード123を含む。UE110は、いくつかの方法で実装され得る部分140-1および/または140ー2の一方または両方を備えるモジュールを含む。UE110は、圧縮モジュール140ー1および140ー2を含む処理コンポーネントを含む。これらの圧縮モジュールは、本明細書で開示されるような本発明の例示的な実施形態を実行するように実装され得るプロセッサ構成を含むことができる。圧縮モジュールは1つ以上のプロセッサ120の一部として実装されるように、圧縮モジュール140-1としてハードウェアで実装されてもよい。圧縮モジュール140ー1は、集積回路として、またはプログラマブル・ゲート・アレイなどの他のハードウェアを介して実装することもできる。別の例では、圧縮モジュールがコンピュータ・プログラム・コード123として実装され、1つ以上のプロセッサ120によって実行される圧縮モジュール140-2として実装されてもよい。例えば、1つ以上のメモリ125およびコンピュータ・プログラム・コード123は、1つ以上のプロセッサ120を用いて、ユーザ装置110に本明細書に記載する1つ以上の操作を実行させるように構成してもよい。UE110は、無線リンク111を介して無線アクセスネットワーク(RAN)ノード170と通信する。
【0031】
RANノード170は、UE110のような無線装置による無線ネットワーク100へのアクセスを提供する基地局であってもよい。例えば、RANノード170は、gNB(UE110に向けてNR利用者プレーンおよび制御プロトコル終端を提供するノード)またはng-eNB(UE110に向けてE-UTRA利用者プレーンおよび制御プレーンプロトコル終端を提供し、NGインタフェースを介してコアネットワーク(すなわち、5Gコア(5GC))に接続されるノード)などのNR/5Gネットワーク内のノード(例えば、基地局)とすることができる。RANノード170は、1つ以上のプロセッサ152と、1つ以上のメモリ155と、1つ以上のネットワークインターフェース(N/W I/F)161と、1つ以上のバス157を介して相互接続された1つ以上のトランシーバ160とを含む。1つ以上のトランシーバ160の各々は、受信機、Rx、162および送信機、Tx、163を含む。1つ以上のトランシーバ160は、1つ以上のアンテナ158に接続される。1つ以上のメモリ155は、コンピュータ・プログラム・コード153を含む。RANノード170は、いくつかの方法で実装され得る部分150-1および/または150-2の一方または両方を備える圧縮モジュールを含む。圧縮モジュールは1つ以上のプロセッサ152の一部として実装されるように、圧縮モジュール150-1としてハードウェアで実装されてもよい。圧縮モジュール150-1は、集積回路として、またはプログラマブル・ゲート・アレイなどの他のハードウェアを介して実装することもできる。別の例では、圧縮モジュールが、コンピュータ・プログラム・コード153として実装され、1つ以上のプロセッサ152によって実行される圧縮モジュール150-2として実装されてもよい。例えば、1つ以上のメモリ155およびコンピュータ・プログラム・コード153は1つ以上のプロセッサ152を用いて構成され、RANノード170に、本明細書に記載するように、1つ以上の操作を実行させる。1つ以上のネットワークインターフェース161は、リンク176および131を介してなどのネットワークを介して通信する。2つ以上のRANノード170は、例えばリンク176を用いて通信する。リンク176は有線であっても、無線であっても、またはその両方であってもよく、たとえば、5GのためのXnインタフェース、LTEのためのX2インタフェース、または他の規格のための他の適切なインタフェースを実装することができる。
【0032】
1つ以上のバス157はアドレス、データ、または制御バスとすることができ、
マザーボードまたは集積回路上の一連のライン、光ファイバまたは他の光通信機器、無線チャネルなどの任意の相互接続機構を含むことができる。例えば、1つ以上のトランシーバ160は、遠隔無線ヘッド(RRH)195として実装されてもよく、RANノード170の他の要素はRRHとは物理的に異なる位置にあり、1つ以上のバス157はRANノード170の他の要素をRRH195に接続するために、部分的に光ファイバケーブルとして実装されてもよい。
【0033】
無線ネットワーク100は、コアネットワーク機能を含み、電話回線網および/またはデータ通信ネットワーク(例えばインターネット)のようなさらなるネットワークとのリンクまたはリンクを介して接続性を提供するネットワーク制御素子または素子NCE190を含んでもよい。このような5Gのコアネットワーク機能には、アクセスおよびモビリティ管理機能(AMF)および/またはユーザプレーン機能(UPF)および/またはセッション管理機能(SMF)が含まれる。LTEのためのそのようなコアネットワーク機能は、MME(モビリティ管理エンティティ)/SGW(サービングゲートウェイ)機能を含むことができる。これらは、NCE190によってサポートされ得る単なる例示的な機能であり、5G機能およびLTE機能の両方がサポートされ得ることに留意されたい。RANノード170は、リンク131を介してNCE190のようなネットワーク制御エレメントに結合される。リンク131は例えば、5GのためのNGインタフェース、またはLTEのためのS1インタフェース、または他の規格のための他の適切なインタフェースとして実装され得る。NCE190は、1つ以上のバス185を介して相互接続された、1つ以上のプロセッサ175、1つ以上のメモリ171、および1つ以上のネットワークインターフェース(N/W I/F)180を含む。1つ以上のメモリ171は、コンピュータ・プログラム・コード173を含む。1つ以上のメモリ171およびコンピュータ・プログラム・コード173は、1つ以上のプロセッサ175によって、NCE190に1つ以上の操作を実行させるように構成される。
【0034】
[1.ネゴシエーション]
3GPPにおけるRoHCネゴシエーションロジックは、現在、UEがUE能力においてサポートされるRoHCプロファイルのリストを提供するように機能する。ベースステーションがこれらのRoHCプロファイルをサポートしている場合、DRB(Data Radio Bearer)は、データ無線ベアラ(PDCPレイヤのデータセッションと見なすことができる)として設定することができ、RoHCはそのDRB内で送信されるすべてのIPパケットに対して有効である。サポートされているプロファイルのいずれにも当てはまらないパケット(例えば、両方のピアがUDP/IPとRTP/UDP/IPプロファイルのみをサポートしていたが、送信されたパケットがTCP/IPであるという理論的なケース)でも、RoHCパケットとしてカプセル化された特別なUNCOMPRESSEDプロファイルを使用して送信される。これは、ネゴシエーションとネットワーク設定に基づいてRoHCが有効になっている場合、すべてのデータパケットはRoHCパケットであり、RoHCデータとRoHCフィードバックの間を除き、それらを明確に識別する必要はないことを意味する。RoHCフィードバックパケットを特別に識別する理由は、PDCPレイヤですでに優先順位をつける(可能性を与える)必要性から生じている。
【0035】
同様に、ピア間で共通のRoHCプロファイルが見つからない場合、RoHCは無効になり(つまり、ネットワークによって設定されていない)、そのセッションでは何の役割も果たさない。RoHCがEHCと一緒にネゴシエート/設定されている場合にこのアプローチに従うと、一般的にサポートされているプロファイルに基づいてRoHCが有効になっている場合、イーサネット・ペイロードとして伝送され、EHCが使用されているときにEHCパケットに続くすべてのIPパケットが実際にRoHCパケットであることがわかる。したがって、パケットがRoHCパケットであるか(RoHCが有効な場合は常に有効)、プレーンIPパケットであるか(RoHCが無効な場合は常に有効)、特にPDCPまたはEHCヘッダで示す必要はない。特別なケースの1つは、フィードバックパケット/メッセージの同定であり、以下でさらに詳しく説明する。
【0036】
PDCPコンテキストのためのRoHCのためのサポートおよびチャネルパラメータは、3GPP TS38.331におよびRRCによってネゴシエートされる。このネゴシエーションの最も重要な態様は、UEがサポートされるRoHCプロファイルのリストを基地局に提供することである。その後、基地局は、(圧縮コンテキストが適切にセットアップされた後に)一定のデータ無線ベアラ(DRB)内のパケットを圧縮/解凍するために使用される、UEによって広告され、かつそれがサポートするRoHCプロファイルのいずれかを構成することができる。
【0037】
EHCネゴシエーションは現在のところ3GPPによって定義されていないが、同じパターンに従うと仮定することができる。UEは、EHCをサポートする能力と、UEがサポートするEHCプロファイルとを提供する。当初、規格には単一のものしか定義できないため、EHCにおけるプロファイルネゴシエーションがまったく含まれるかどうかは確かではないが、少なくともEHCをサポートするUE能力が示されなければならない。
【0038】
1つの新しい態様は、RoHCとEHCの併用をどのように取り決めるかである。
【0039】
UEがイーサネットPDUセッションのためのEHC(特定のプロファイルを有する)およびRoHC(特定のプロファイルを有する)の両方の支持を広告する場合、UEが、その特定のPDUセッションのためのEHCおよびRoHCの組み合わせた使用を支持することを意味する。広告されたすべてのEHCプロファイルがイーサネット・ヘッダでのみ操作し、アナウンスされたすべてのRoHCプロファイルがイーサネットの上に直接IPまたはその他のヘッダで操作する限り、任意のEHCまたはRoHCプロファイルを一緒に使用できる。しかしながら、将来のEHCがイーサネット上のヘッダ上でも操作するプロファイルを定義するか、RoHCがイーサネット・ヘッダ上で操作するプロファイルを定義するなら、アナウンスでは、層間を横断しないプロファイルのみを複合的にサポートすることを意味する。
【0040】
代替的に、UEはEHCおよびRoHCを組み合わせて操作させる能力を追加的にシグナリングする必要があり得る、すなわち、UEがEHCサポートおよびRoHCサポートをシグナリングするが、組み合わせ操作サポートをシグナリングしない場合、ネットワークはDRBのためにEHCまたはROHCのいずれか一方を構成することができるが、それらの両方を同時に構成することはできない。組み合わされた操作が示される場合、ネットワークは、単一のDRBのためにEHCおよびRoHCの両方を構成することができる。
【0041】
ネゴシエーション手順は、本発明の例示的な実施形態の新規な部分ではない場合がある。しかしながら、これは、以下に列挙されるさらなる手順のための前提条件であるため、本明細書に記載される。
【0042】
[オプション1:]
[2.データパケットの圧縮操作]
ここでは、RoHCとEHCを組み合わせて送信パケットのヘッダを圧縮する方法について説明する。組み合わせ操作の前提条件は、ネゴシエーションに基づいて、EHCおよびRoHCの両方がDRBに対して有効にされていることである。RoHCケースでは、これは、ピアが少なくとも1つの共通RoHCプロファイルに対する支援を示したことを意味する。EHC圧縮器とRoHC圧縮器の次の組合せ操作を提案した。
1.圧縮されていないパケットは、最初にEHC圧縮器に供給される、
2.EHCはイーサネット・ヘッダを圧縮し、イーサネットペイロードタイプ(type/Ethertype)をチェックする、
3.イーサネットペイロードタイプがIPv4またはIPv6の場合、EHCはIPパケット長をチェックし、イーサネット・ペイロードがIPパケットサイズよりも長い場合は、オプションで追加のバイトを削除する(パディングであることがわかっているため)、その後、EHCはIPパケット(またはIPパケットの開始位置へのポインタ)をRoHCに渡す、
4.RoHCは、他のピアでサポートされているプロファイルにおよび宿Pパケットを操作する、
● RoHCコンテキスト割り当ては、EHCコンテキスト割り当てから独立している、および、
5.結果のパケットは、送信のために下位層に与えられる。
結果のパケットは次の形式になる、
|EHCヘッダ|RoHCヘッダ|RoHCプロファイルを超えたペイロード|パディング(オプションで削除)|
【0043】
図2は、この第1のオプションについて、IP/イーサネット・パケットを圧縮する後続のステップ、および、処理中にEHCおよびRoHC圧縮器がどのように協働するかを示す。また、圧縮の異なる段階におけるパケット構造も示している。
図2に示すように、パケット構造210と、EHC圧縮器220と、ROHC圧縮器230とがある。パケット構造210はパケット構造AからFを含み、EHC圧縮器220は、本発明の実施形態例にしたがった操作フローを含む。EHC圧縮器220フローのこれらの操作は、ステップAにおいて、EHC圧縮器に到着する新しいPDCP SDUがあり、ステップBにおいて、イーサネットヘッダがEHC圧縮器によって圧縮され、ステップCにおいて、パケットがイーサネットフレームに含まれる場合、パディングが除去され、
ステップDにおいて、パケットがイーサネットフレームから抽出される場合、圧縮されていないIPパケットがROHC圧縮器230に提供され、IPパケットがROHC圧縮器230フローのステップD1に示されるようにROHC圧縮器に到着することを含む。あるいは、EHC圧縮器がパケット構造210のステップCに見られるように、EHCヘッダと共に、IPパケットが開始する場所へのポインタと共に、パケットを提供してもよい。いずれの場合も、ROHC圧縮器230はIPパケット上でのみ操作し、EHCヘッダ上では操作しない。ROHC圧縮器230において、IPヘッダはROHC圧縮器230のフローのステップD2に示されるように圧縮され、次いで、圧縮されたIPパケットがEHC圧縮器220に供給され、EHC圧縮器220のフローのステップEにおいて、圧縮されたIPパケットがEHC圧縮器に到着し、EHC圧縮器220のフローのステップFにおいて、圧縮されたイーサネット・ヘッダが再挿入され、次いで、EHC圧縮器220のフローのステップGにおいて、パケットが送信のために下位レイヤに供給される。ステップDの場合、EHC圧縮器はフルパケットにポインタを提供し、ステップEにおいて、EHC圧縮器はEHCヘッダおよびROHCヘッダの両方を有するパケットを受信しており、これは、送信のために下位レイヤに直接提供されてもよい。
【0044】
[3.データパケットの解凍操作]
1.圧縮されたパケットがEHC解凍器に渡される、
2.EHCはイーサネット・ヘッダを解凍し、イーサネットペイロードタイプをチェックする、
3.イーサネット・ペイロードがIPv4またはIPv6EHCの場合、イーサネットペイロード(またはそのポインタ)はRoHCに渡される、この場合のペイロードは実際にはRoHCパケットである、
4.RoHCは示されたコンテキストおよびプロファイルにしたがってパケットを操作し、結果として非圧縮IPパケットを生成する、
5.RoHC操作後、パッド追加のためにパケットがEHCに返される、および/または、
6.EHCは、必要に応じてパディングバイトを追加して、フレームが必須の最小サイズに達するようにする。
【0045】
図3Aは、IP/イーサネット・パケットを解凍するこの第1のオプションの後続ステップと、処理中にEHCおよびRoHC解凍器がどのように連動するかを示す。また、解凍の異なる段階でのパケット構造も示す。
【0046】
図3Aに示すように、パケット構造310と、EHC解凍器320と、ROHC解凍器330とがある。パケット構造310はパケット構造AからFを含み、EHC解凍器320は、本発明の実施形態例にしたがった操作フローを含む。EHC解凍器320フローのこれらの操作は、第1のステップではEHC解凍器に到着する圧縮パケットがあり、その後のステップではイーサネット・ヘッダが解凍され、別のステップでは圧縮されたIPパケットがイーサネットフレームから抽出され、ROHC解凍器330に提供されることを含む。あるいは、EHC解凍器が解凍されたイーサネット・ヘッダを含むパケットに、ROHCヘッダが開始する場所へのポインタを提供してもよい。次に、ROHC解凍器330はROHC解凍器330フローのステップC1に示すように、ROHC解凍器に到着する圧縮IPパケット上で作動し、ここで、IPヘッダは、ROHC解凍器330フローのC2に示すように解凍され、次いで、解凍されたIPパケットはEHC解凍器320に供給され、ここで、EHC解凍器320フローのステップDで、解凍されたIPパケットが到着し、EHC解凍器320フローのステップEで、イーサネット・ヘッダが再挿入され、ステップFで、必要に応じてパディングが再挿入され、次いで、非圧縮パケットのステップGで、上位階層に提供される。前のステップにおいて、EHC解凍器はROHCヘッダが始まる場所へのポインタをもつイーサネット・ヘッダを含むパケットを提供した場合には、次いで、ステップDにおいて、EHC解凍器はイーサネット・ヘッダとIPヘッダの両方をもつパケットを受信しており、これは上位階層に直接提供されてもよい。
【0047】
[オプション2:]
[データパケットの圧縮操作]
EHC圧縮器とRoHC圧縮器の次の組合せ操作を提案した。
1.圧縮されていないパケットは、最初にEHC圧縮器に供給される、
2.EHCはイーサネット・ヘッダを圧縮し、EHCヘッダを追加する、EHCはイーサネットペイロードタイプ(type/Ethertype)をチェックする、
3.イーサネットペイロードタイプがIPv4またはIPv6の場合、EHCはIPパケット長をチェックし、イーサネット・ペイロードがIPパケットサイズよりも長い場合は、オプションで追加のバイトを削除する(パディングであることがわかっているため)、次に、EHC圧縮器は、IPパケット(またはIPパケットが開始する場所へのポインタ)をRoHCに与える、
4.RoHCは、他のピアでサポートされているプロファイルにしたがってIPパケットを操作する、
● RoHCコンテキスト割り当ては、EHCコンテキスト割り当てから独立している、および、
5.結果のパケットは、送信のために下位層に与えられる。
|RoHCヘッダ|EHCヘッダ|ペイロード|パッディング(オプションとして除去)
【0048】
図3Bは、本発明の実施例にしたがった第2の選択肢のためのEHC圧縮器とRoHC圧縮器の結合操作を示す。
【0049】
図3Bに同様に示すように、パケット構造310、EHC圧縮器320、およびROHC圧縮器330を示す。パケット構造310はパケット構造AからEを含み、EHC圧縮器320は、本発明の実施形態例による操作フローを含む。EHC圧縮器320のフローのこれらの操作は、第1のステップにおいて、EHC圧縮器320に到着する新しいPDCP SDUがあり、後続のステップにおいて、イーサネット・ヘッダがEHC圧縮器によって圧縮され、別の後続のステップにおいて、イーサネットフレームに含まれる場合、パディングが除去され、次いで、IPパケットへのポインタがROHCに提供されることを含む。
図3BのステップD1に示すように、IPパケットはROHC圧縮器に到着している。
図3BのステップD2において、IPヘッダが圧縮される。次に、
図3BのステップD3に示すように、パケットは、送信のために下位レイヤに提供される。
【0050】
[データパケットの解凍操作:]
1.圧縮されたパケットは、EHCが有効か無効かの表示と共にRoHC解凍器に与えられる、
2.RoHCは示されたコンテキストおよびプロファイルにしたがってパケットを操作し、結果として非圧縮IPパケットを生成する、
3.RoHC操作の後、パケットはEHC解凍器に与えられる、
4.EHCはイーサネット・ヘッダを解凍し、イーサネットペイロードタイプをチェックする、および、
5.イーサネットのペイロードがIPv4またはIPv6の場合、EHCはフレームが必須の最小サイズになるように、必要に応じてパディングバイトを識別し追加する。
【0051】
図3Cは、本発明の例示的な実施形態による、この第2のオプションのためのEHC解凍器およびRoHC解凍器の併用操作を示す。
【0052】
図3Cは、パケット構造310、EHC解凍器320、およびROHC解凍器330を示す。パケット構造310はパケット構造AからFを含み、EHC解凍器320は、本発明の実施形態例にしたがった操作フローを含む。ROHC解凍器330フローのこれらの操作は、第1のステップでROHC解凍器に到着する圧縮パケットがあり、後続のステップでIPヘッダが解凍され、後続のステップで解凍されたIPパケットがEHC解凍器320に提供されることを含む。
図3CのステップA1に示すように、EHCが有効か無効かを示す情報と共に、圧縮パケットがPDCPによって提供される。
図3CのステップA2に示すように、IPヘッダは解凍され、ペイロードの前に追加される。次に、
図3Cに示すように、解凍されたIPパケットはEHC解凍器に供給される。
【0053】
[4.フィードバック・メッセージ]
EHCおよびRoHCの両方は、解凍器から圧縮器にフィードバック・メッセージを送信する必要がある。これらは、PDCPによって異なるペイロード識別子を付与することによって区別される。
図4は、本発明の例示的な実施形態による、そのようなフィードバックの例を示す。
【0054】
図4に示すように、1ビットD/C401、3ビットPDUタイプ420、および4ビットR(予約済み)430が示されている。ここで、
図4について、
1ビットD/C401は、
0-PDCP制御PDU、または、
1-PDCPデータPDU、
に対する、および、
3ビットPDUタイプ420は、
000-PDCPステータスレポート、
001-散在ROHCフィードバック、
010-EHCフィードバック、
011-EHC+ROHCフィードバック、および、
100-111-リザーブ、
に対する。
【0055】
現在、PDCP PDUタイプは、PDCP制御PDUが散在RoHCフィードバックであるかどうかを区別する。このアプローチはもともと、PDCPレイヤ上に既にあるフィードバック・メッセージに特別な処理(優先権)を与えることができるように選択されており、EHCとRoHCが一緒に操作する場合にもこの原理に従うことが重要であると考えられる。新しいアプローチはEHCフィードバックおよびEHC+RoHCフィードバックの組み合わせオプションをサポートするために、新しいPDUタイプ(例えば、上述のように「010」および「011」)を導入することである。組み合わされたフィードバックは、EHCフィードバックが常に固定長であるか、またはその長さが、例えば、構造内に明示的な長さヘッダ/インジケータを含めることによって、その構造から推定され得ることを必要とする。RoHCフィードバック長さは、既にこの特性を有する。
【0056】
この新しいアプローチはまた、タイプEHC+RoHCフィードバックの単一のPDCP制御PDU内で、複数のEHCおよび/またはRoHCコンテキストからのフィードバック・メッセージを組み合わせることを可能にする。
【0057】
単一のPDCP制御PDUにおいてデータ無線ベアラ(DRB)のEHCフィードバックとRoHCフィードバックとを組み合わせることは、各パケットに対して追加される下位レイヤヘッダのオーバヘッドが回避されるので、Uuインタフェースを介して(すなわち、UEとgNBとの間で)送信されるバイトの総数を低減するのに役立つ。
【0058】
図5Aは、限定はしないが、例えば、
図1におけるようなeNBまたはUE110のようなRANノードケ70のようなネットワークノードのようなネットワークデバイスによって実行され得る操作を示す。
図5Aのステップ510に示すように、イーサネット・パケット・データのイーサネット・ヘッダに対する第1の圧縮操作が実行される。
図5Aのステップ520に示すように、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判定される。
図5Aのステップ530に示すように、イーサネット・パケット・データ内に少なくとも1つのインターネット・プロトコル・パケットを識別するものがある。次に、
図5Aのステップ540に示すように、少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対して第2の圧縮操作を実行し、第2の圧縮操作は、第1の圧縮操作のコンテキストまたはプロファイルとは独立した、示されたコンテキストまたはプロファイルのうちの少なくとも1つに基づく。
【0059】
上記の段落に記載されている実施例にしたがって、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断することは、イーサネット・ヘッダのイーサタイプフィールドに基づく。
【0060】
上記段落で説明した例示的な実施形態によれば、示されたコンテキストまたはプロファイルのうちの少なくとも1つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む。
【0061】
上記段落で説明した例示的な実施形態によれば、示されたコンテキストまたはプロファイルのうちの少なくとも1つは、イーサネット・パケット・データのイーサネット・ヘッダに関連付けられた値に基づく。
【0062】
上述の段落に記載された実施形態例によれば、イーサネット・パケット・データの識別されたタイプのイーサネット・ペイロードがIPv4またはIPv6タイプのペイロードの1つことに基づいて、少なくとも1つのインターネット・プロトコル・パケットのパケット長を決定すること、およびイーサネット・パケット・データのパケット長がインターネット・プロトコル・パケットのパケット長より長い場合には、イーサネット・パケット・データからイーサネット・レベル・パッド・バイトを除去することがある。上記の段落で説明した例示的な実施形態によれば、第1の圧縮操作を実行することは、第2の圧縮操作によって使用される少なくとも1つのインターネット・プロトコル・パケットまたは少なくとも1つのインターネット・プロトコル・パケットの第1のパケットへのポインタを第2の圧縮操作に提供することを含む。
【0063】
上記の段落で説明した例示的な実施形態による操作が、通信ネットワークの少なくとも1つのユーザデバイスまたは少なくとも1つの基地局のうちの1つによって実行される。
【0064】
上記段落で説明した例示的な実施形態によれば、第1の圧縮操作はイーサネット・ヘッダ圧縮操作を含み、第2の圧縮操作はロバストなヘッダ圧縮操作を含む。
【0065】
上記段落で説明した例示的な実施形態によれば、制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを受信する。
【0066】
上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、第1の圧縮操作および第2の圧縮操作のうちの少なくとも1つに対する支持を示すパケットデータ制御プロトコルデータユニットタイプを備える。
【0067】
上記段落で説明した例示的な実施形態によれば、パケットデータ制御プロトコルデータユニットタイプは3ビットを含む。
【0068】
上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、またはイーサネット・ヘッダ圧縮フィードバックまたはロバスト・ヘッダ圧縮フィードバックのうちの組み合わせられた少なくとも1つを示す。
【0069】
上記段落で説明した例示的な実施形態によれば、組み合わされたイーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮フィードバックのうちの少なくとも1つと、イーサネット・ヘッダ圧縮の長さヘッダまたはインジケータのうちの少なくとも1つとが含まれる。
【0070】
上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮のうちの少なくとも1つのコンテキスト割り当てからのフィードバックを含む。
【0071】
上記段落で説明した例示的な実施形態によれば、ロバスト・ヘッダ圧縮のコンテキスト割り当ては、イーサネット・ヘッダ圧縮のコンテキスト割り当てから独立している。
【0072】
上述したような本発明の例示的な実施形態によれば、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160、メモリ125および/またはメモリ155、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150-2、および、
図1のようなプロセッサ120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1)イーサネット・パケット・データのイーサネット・ヘッダに対して、第1圧縮操作を実行するための手段を備える装置であって、該実行する手段は、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160、メモリ125および/またはメモリ155、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150-2、および、プロセッサ120および/または圧縮モジュール140-1、および/または、プロセッサ152、および/または、圧縮モジュール150-1、
図1を参照)イーサネット・パケットが、インターネット・プロトコル・パケットを含むと決定する手段と、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160と、メモリ125および/またはメモリ155と、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2と、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150-2と、プロセッサ120および/または圧縮モジュール140-1と、プロセッサ152および/または圧縮モジュール150-1、
図1を参照)イーサネット・パケット・データ内の少なくとも1つのインターネット・プロトコル・パケットを識別する手段と、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160と、メモリ125および/またはメモリ155と、コンピュータ・プログラム・コード123および/または圧縮モジュール140ー2、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150ー2、および、120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1、
図1参照)少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対する第2の圧縮操作であって、第1圧縮操作のコンテキストまたはプロファイルとは独立した、示されたコンテキストまたはプロファイルのうちの少なくとも1つに基づく、第2圧縮操作を実行する手段と、を備える、装置が存在する。
【0073】
上記のパラグラフによる例示的な態様において、実施、決定、および識別のための少なくとも手段が、少なくとも1つのプロセッサ[
図1のプロセッサ120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1]によって実行可能なコンピュータプログラム[コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/または、コンピュータ・プログラム・コード153および/または圧縮モジュール150-2]で符号化された非一時的なコンピュータ可読媒体[
図1のメモリ125および/またはメモリ155]を含む、
【0074】
図5Bは、限定されるものではないが、例えば、
図1におけるようなeNBまたはUE110のようなRANノードケ70のようなネットワークノードのようなネットワークデバイスによって実行されることができる操作を示す。
図5Bのステップ550に示すように、イーサネット・パケット・データのイーサネット・ヘッダへの第1の解凍操作が実行される。
図5Bのステップ560に示すように、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断する。
図5Bのステップ570に示されるように、イーサネット・パケット・データ内の少なくとも1つのインターネット・プロトコル・パケットを識別する。
次に、
図5Bのステップ580に示すように、少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダに対する第2の解凍操作が実行され、第2の解凍操作は、第1の解凍操作とは独立したコンテキストまたはプロファイルの示された少なくとも1つに基づく。
【0075】
上記の段落に記載されている実施例にしたがって、イーサネット・パケットがインターネット・プロトコル・パケットを含むと判断することは、イーサネット・ヘッダのイーサタイプフィールドに基づく。
【0076】
上記段落で説明した例示的な実施形態によれば、示されたコンテキストまたはプロファイルのうちの少なくとも1つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む。
【0077】
上記段落で説明した例示的な実施形態によれば、示されたコンテキストまたはプロファイルのうちの少なくとも1つは、イーサネット・パケット・データのイーサネット・ヘッダに関連付けられた値に基づく。
【0078】
上述の段落に記載された実施例にしたがって、示されたコンテキストまたはプロファイルの少なくとも1つはイーサネット・パケット・データのイーサネット・ヘッダに関連付けられ、イーサネット・パケット・データは少なくともイーサネット・パケットのヘッダに関連付けられたIPv6パケットの示されたIPv4を含む。
【0079】
上記段落に記載された例示的な実施形態によれば、第1解凍操作を実行することは、第2解凍操作に、少なくとも1つのインターネット・プロトコル・パケット、または第2の解凍操作によって使用される少なくとも1つのインターネット・プロトコル・パケットの第1のパケットへのポインタを提供することを含む。
【0080】
上記の段落で説明した例示的な実施形態による操作は、通信ネットワークの少なくとも1つのユーザデバイスまたは少なくとも1つの基地局のうちの1つによって実行される。
【0081】
上記段落で説明した例示的な実施形態によれば、第1の解凍操作は、イーサネット・ヘッダ解凍操作を含み、第2の解凍操作はロバストなヘッダ解凍操作を含む。
【0082】
上記段落で説明した例示的な実施形態によれば、制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを通信することがある。
【0083】
上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、第1の圧縮操作および第2の圧縮操作のうちの少なくとも1つに対する支持を示すパケットデータ制御プロトコルデータユニットタイプを備える。
【0084】
上記段落で説明した例示的な実施形態によれば、パケットデータ制御プロトコルデータユニットタイプは3ビットを含む。
【0085】
上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、またはイーサネット・ヘッダ圧縮フィードバックまたはロバスト・ヘッダ圧縮フィードバックのうちの組み合わせられた少なくとも1つを示す。
【0086】
上記段落で説明した例示的な実施形態によれば、組み合わされたイーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮フィードバックのうちの少なくとも1つと、イーサネット・ヘッダ圧縮の長さヘッダまたはインジケータのうちの少なくとも1つとが組み合わされる。
【0087】
上記段落で説明した例示的な実施形態によれば、圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮のうちの少なくとも1つのコンテキスト割り当てからのフィードバックを含む。
【0088】
上記段落で説明した例示的な実施形態によれば、ロバスト・ヘッダ圧縮のコンテキスト割り当ては、イーサネット・ヘッダ圧縮のコンテキスト割り当てから独立している。
【0089】
上記のような本発明の実施形態例にしたがって、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160、メモリ125、および/またはメモリ155、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150-2、ならびに、プロセッサ120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1、
図1参照)イーサネット・パケット・データのイーサネット・ヘッダへの第1解凍操作を実行する手段と、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160、メモリ125および/またはメモリ155、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコ、ンピュータプログラムコード153および/または圧縮モジュール150-2、およびプロセッサ120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1、
図1参照)イーサネット・パケットがインターネット・プロトコル・パケットを含むと決定する手段と、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160、
図1のように、イーサネット・パケットがインターネット・プロトコル・パケットを含むこと、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコンピュータプログラムコード153および/または圧縮モジュール150-2、およびプロセッサ120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1、
図1参照)イーサネット・パケット・データの内の少なくとも1つのインターネット・プロトコル・パケットを識別する手段と、(1つ以上のトランシーバ130および/または1つ以上のトランシーバ160、メモリ125および/またはメモリ155、コンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150-2、および、プロセッサ120および/または圧縮モジュール140-1、および/またはプロセッサ152および/または圧縮モジュール150-1、
図1参照)少なくとも1つのインターネット・プロトコル・パケットのインターネット・プロトコル・ヘッダへ第2解凍操作を実行する手段であって、前記第2圧縮解除操作は、示された、前記第1圧縮解除操作とは独立したコンテキストまたはプロファイルの少なくとも1つに基づく、実行する手段と、を備える装置が存在する。
【0090】
上記段落に係る発明の実施例の態様において、少なくとも、実行、決定、および識別するための手段は、コンピュータプログラムで符号化された[
図1のようなコンピュータ・プログラム・コード123および/または圧縮モジュール140-2、および/またはコンピュータ・プログラム・コード153および/または圧縮モジュール150-2]、少なくとも1つのプロセッサによって実行可能な[
図1のメモリ125および/またはメモリ155]、非一時的なコンピュータ可読媒体を構成する[
図1のような、メモリ125、および/または、メモリ155]。
【0091】
一般に、様々な態様は、ハードウェアまたは専用回路、ソフトウェア、ロジック、またはそれらの任意の組合せで実装され得る。例えば、いくつかの態様はハードウェアで実装されてもよく、他の態様はコントローラ、マイクロプロセッサ、または他の計算装置によって実行されてもよいファームウェアまたはソフトウェアで実装されてもよい。しかしながら、本発明はそれに限定されない。本発明の様々な態様はブロック図、フローチャートとして、またはいくつかの他の絵画的表現を使用して図示および目的され得るが、本明細書で目的されるこれらのブロック、装置、システム、技術、または方法は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路もしくは論理、汎用ハードウェアもしくはコントローラ、または他の計算装置、あるいはそれらのいくつかの組合せで実装され得ることをよく理解されたい。
【0092】
本発明の実施形態は、集積回路モジュールなどの様々な部品で実施することができる。集積回路の設計は高度に自動化された処理によるものであり、大規模である。論理レベルの設計を、エッチングされ、半導体基板上に形成される準備ができている整った半導体回路設計に変換するための、複雑で強力なソフトウェアツールが利用可能である。
【0093】
「例示的」という語は、本明細書では「例、または例示として働く」ことを意味するために使用され、「例示的」として本明細書で説明される任意の実施形態は必ずしも、他の実施形態よりも好ましい、または有利であると解釈されるべきではない。この詳細な説明に記載される実施形態の全ては、当業者が本発明を実施または使用することを可能にするために提供される例示的な実施形態であり、特許請求の範囲によって定義される本発明の範囲を限定するものではない。
【0094】
前述の説明は、本発明を実施するために本発明者によって現在企図されている最良の方法および装置の完全かつ有益な説明を、例示的かつ非限定的な例として提供した。しかしながら、添付の図面および付随の請求項を熟読する際に、前述の説明を考慮して、種々の修正および適合が、当業者に明白になるであろう。しかしながら、本発明の教示の全てのそのような同様の修正は、依然として本発明の範囲内にある。
【0095】
用語「接続された」、「結合された」、またはその任意の変形は2つ以上の要素間の直接または間接の任意の接続または結合を意味し、「接続された」または「結合された」2つの要素間の1つ以上の中間要素の存在を包含し得ることに留意されたい。要素間の結合または接続は物理的、論理的、またはそれらの組み合わせであり得る。本明細書で使用されるように、2つの要素は、1つ以上のワイヤ、ケーブル、および/または印刷された電気的接続の使用によって、ならびに無線周波数領域、マイクロ波領域、および光学(可視および不可視の両方)領域における波長を有する電磁エネルギーなどの電磁エネルギーの使用によって、いくつかの非限定的かつ非網羅的な例として、「接続された」または「結合された」とみなされ得る。
【0096】
さらに、本発明の好ましい実施形態の特徴のいくつかは、他の特徴を対応して使用することなく有利に使用することができる。したがって、前述の説明は、本発明の原理を単に例示するものであって、本発明を制限するものではないと考えられるべきである。
【手続補正書】
【提出日】2022-03-25
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
イーサネット・パケット・データのイーサネット・ヘッダへの第1圧縮操作を実行するステップ
と、
前記イーサネット・パケット・データがインターネット・プロトコル・パケットを含むと決定するステップと、
前記イーサネット・パケット・データ内の少なくとも1つのインターネットプロトコルパケットを識別するステップと、
前記少なくとも1つのインターネットプロトコルパケットのインターネットプロトコルヘッダへの第2圧縮操作を実行するステップであって、前記第2圧縮操作は、前記第1圧縮操作とは独立したコンテキストまたはプロファイルのうちの少なくとも1つに基づく、ステップと、
を含む、方法。
【請求項2】
前記イーサネット・パケット・データが前記インターネットプロトコルパケットを含むと決定する前記ステップは、
前記イーサネット・ヘッダのイーサタイプフィールドに基づく、請求項1に記載の方法。
【請求項3】
前記コンテキストまたはプロファイルのうちの少なくとも1つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む、請求項1に記載の方法。
【請求項4】
前記コンテキストまたはプロファイルの少なくとも1つは、前記イーサネット・パケット・データの
前記イーサネット・ヘッダに関連する値に基づく、
請求項1に記載の方法。
【請求項5】
IPv4またはIPv6タイプのペイロードのいずれかである、前記イーサネット・パケット・データのイーサネット・ペイロードの識別されたタイプに基づいて、前記少なくとも1つのインターネットプロトコルパケットのパケット長を決定するステップを含み、
前記イーサネット・パケット・データのパケット長が前記インターネットプロトコルパケットの前記パケット長より長い場合には、前記方法は、前記イーサネット・パケット・データからイーサネットレベル・パディングバイトを削除するステップを含む、
請求項1に記載の方法。
【請求項6】
前記第1圧縮操作を実行する前記ステップは、前記第2圧縮操作に、前記第2圧縮操作によって使用するために、前記少なくとも1つのインターネットプロトコルパケットまたは前記少なくとも1つのインターネットプロトコルパケットの第1パケットへのポインタを提供するステップを含む、請求項1に記載の方法。
【請求項7】
前記方法は、通信ネットワークの少なくとも1つのユーザデバイスまたは少なくとも1つの基地局のうちの1つによって実行される、請求項1に記載の方法。
【請求項8】
前記第1圧縮操作はイーサネット・ヘッダ圧縮操作を含み、
前記第2圧縮操作は、ロバストなヘッダ圧縮操作を含む、
請求項1に記載の方法。
【請求項9】
制御プロトコルデータユニットにおいて圧縮フィードバック・メッセージを受信するステップをさらに含む、請求項1に記載の方法。
【請求項10】
前記圧縮フィードバック・メッセージは、前記第1圧縮操作および前記第2圧縮操作のうちの少なくとも1つに対するサポートを示すパケットデータ制御プロトコルデータユニットタイプを含む、請求項9に記載の方法。
【請求項11】
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、または、イーサネット・ヘッダ圧縮フィードバックとロバスト・ヘッダ圧縮フィードバックとの組み合わせを示す、請求項9に記載の方法。
【請求項12】
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮またはロバスト・ヘッダ圧縮のうちの少なくとも1つのコンテキスト割り当てからのフィードバックを含む、請求項9に記載の方法。
【請求項13】
イーサネット・パケット・データのイーサネット・ヘッダへの第1解凍操作を実行するステップ
と、
前記イーサネット・パケット・データがインターネット・プロトコル・パケットを
含むと決定するステップと、
前記イーサネット・パケット・データ内の少なくとも1つのインターネットプロトコルパケットを識別するステップと、
前記少なくとも1つのインターネットプロトコルパケットのインターネットプロトコルヘッダへの第2解凍操作を実行するステップであって、前記第2解凍操作は、前記第1解凍操作とは独立したコンテキストまたはプロファイルの少なくとも1つに基づく、ステップと、
を含む、方法。
【請求項14】
前記イーサネット・パケット・データが前記インターネットプロトコルパケットを含むと決定する前記ステップは、前記イーサネット・ヘッダのイーサタイプフィールドに基づく、請求項13に記載の方法。
【請求項15】
前記コンテキストまたはプロファイルのうちの少なくとも1つは、データ通信セッションのために構成された圧縮コンテキストまたはプロファイルを含む、請求項13に記載の方法。
【請求項16】
前記コンテキストまたはプロファイルの少なくとも1つは、前記イーサネット・パケット・データの
前記イーサネット・ヘッダに関連する値に基づく、
請求項13に記載の方法。
【請求項17】
前記コンテキストまたはプロファイルの少なくとも1つは、前記イーサネット・パケット・データの前記イーサネット・ヘッダに関連付けられ、
前記イーサネット・パケット・データは、前記少なくとも
1つのイーサネット・パケットの前記
イーサネット・ヘッダに関連付けられたIPv6パケットのIPv4を含む、
請求項13に記載の方法。
【請求項18】
前記第1解凍操作を実行する前記ステップは、前記第2解凍操作に、前記第2解凍操作によって使用するために、前記少なくとも1つのインターネットプロトコルパケットまたは前記少なくとも1つのインターネットプロトコルパケットの第1パケットへのポインタを提供するステップを含む、請求項13に記載の方法。
【請求項19】
前記方法は、通信ネットワークの少なくとも1つのユーザデバイスまたは少なくとも1つの基地局のうちの1つによって実行される、請求項13に記載の方法。
【請求項20】
前記第1解凍操作はイーサネット・ヘッダ解凍操作を含み、
前記第2解凍操作は、ロバスト・ヘッダ解凍操作を含む、
請求項13に記載の方法。
【請求項21】
制御プロトコル・データ・ユニットにおいて圧縮フィードバック・メッセージを通信するステップをさらに含む、請求項13に記載の方法。
【請求項22】
前記圧縮フィードバック・メッセージは、イーサネット・ヘッダ圧縮フィードバック、または、イーサネット・ヘッダ圧縮フィードバックとロバスト・ヘッダ圧縮フィードバックとの組み合わせを示す、請求項21に記載の方法。
【請求項23】
少なくとも1つのプロセッサと、コンピュータ・プログラム・コードを含む少なくとも1つのメモリと、を備える装置であって、
前記少なくとも1つのメモリと、前記コンピュータ・プログラム・コードとは、前記少なくとも1つのプロセッサを用いて、前記装置に、請求項1ないし12のいずれか1項、または、請求項13ないし22のいずれか1項に記載の方法を実行させるように構成される、装置。
【請求項24】
請求項1ないし12のいずれか1項、または、請求項13ないし22のいずれか1項に記載の方法を実行するための手段を含む装置。
【請求項25】
請求項1ないし12のいずれか1項、または、請求項13ないし22のいずれか1項に記載の方法を実行するためのプログラム・コードを含むコンピュータ・プログラム。
【国際調査報告】