JP2022532020A - 圧縮処理方法、解圧縮処理方法及び関連機器 - Google Patents

Abstract

本発明は、圧縮処理方法、解圧縮処理方法及び関連機器を開示し、ここで、前記圧縮処理方法は、送信されるイーサーネットデータパケットヘッダの状態を決定することと、前記送信されるイーサーネットデータパケットヘッダの状態に基づいて、前記送信されるイーサーネットデータパケットヘッダのデータを処理することと、を含み、前記イーサーネットデータパケットヘッダの状態は、非圧縮状態及び圧縮状態のうちの少なくとも１つを含む。

Description

本発明は、情報処理技術分野、特に、圧縮処理方法、解圧縮処理方法、圧縮側機器、解圧縮側機器及びコンピュータ記憶媒体、チップ、コンピュータ可読記憶媒体、コンピュータプログラム製品並びにコンピュータプログラムに関する。

５Ｇ ニューラジオ（ＮＲ：Ｎｅｗ Ｒａｄｉｏ） システムでは、インターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｌ）をサポートすることに加えて、ＰＤＵセッション（ｓｅｓｓｉｏｎ）は、イーサーネットもサポートすることができる。つまり、ＰＤＵ Ｓｅｓｓｉｏｎは、ＩＰパケットタイプであってもよいし、イーサーネットパケットタイプであってもよい。図１－１に示すように、ＰＤＵ層（ＰＤＵ ｌａｙｅｒ）の場合、ＰＤＵ Ｓｅｓｓｉｏｎのタイプは、ＩＰｖ４、ＩＰｖ６、及びＩＰｖ４ｖ６のうちの少なくとも１つである。つまり、当該ＰＤＵ ｓｅｓｓｉｏｎに対応するデータパケットは、ＩＰｖ４データパケット、ＩＰｖ６データパケット、ＩＰｖ４ｖ６データパケットのうちの少なくとも１つである。ＰＤＵ Ｓｅｓｓｉｏｎのタイプがイーサーネット（Ｅｔｈｅｒｎｅｔ）である場合、当該ＰＤＵセッションに対応するデータパケットは、イーサーネットデータパケットである。

しかしながら、ＰＤＵセッションにおけるイーサーネットデータパケットの圧縮処理について、関連する処理方式が提案されていないため、イーサーネットデータパケットの伝送リソースを節約することができない。

上記の技術的課題を解決するために、本発明の実施例は、圧縮処理方法、解圧縮処理方法、圧縮側機器、解圧縮側機器及びコンピュータ記憶媒体、チップ、コンピュータ可読記憶媒体、コンピュータプログラム製品並びにコンピュータプログラムを提供する。

第１態様によれば、圧縮処理方法を提供し、前記圧縮処理方法は、
送信されるイーサーネットデータパケットヘッダの状態を決定することと、
前記送信されるイーサーネットデータパケットヘッダの状態に基づいて、前記送信されるイーサーネットデータパケットヘッダのデータを処理することと、を含み、
ここで、前記イーサーネットデータパケットヘッダの状態は、非圧縮状態及び圧縮状態のうちの少なくとも１つを含む。

第２態様によれば、解圧縮処理方法を提供し、前記解圧縮処理方法は、
イーサーネットデータを受信することと、
解圧縮状態を決定し、前記解圧縮状態に基づいて、前記イーサーネットデータパケットヘッダのデータを処理することと、を含み、
ここで、前記解圧縮状態は、コンテキストなし状態、コンテキストあり状態のうちの少なくとも１つを含む。

第３態様によれば、圧縮側機器を提供し、前記圧縮側機器は、
送信されるイーサーネットデータパケットヘッダの状態を決定し、前記送信されるイーサーネットデータパケットヘッダの状態に基づいて、前記送信されるイーサーネットデータパケットヘッダのデータを処理するように構成される第１処理ユニットを備え、
ここで、前記イーサーネットデータパケットヘッダの状態は、非圧縮状態及び圧縮状態のうちの少なくとも１つを含む。

第４態様によれば、解圧縮側機器を提供し、前記解圧縮側機器は、
イーサーネットデータを受信するように構成される第２通信ユニットと、
解圧縮状態を決定し、前記解圧縮状態に基づいて、前記イーサーネットデータパケットヘッダのデータを処理するように構成される第２処理ユニットと、を備え、
ここで、前記解圧縮状態は、コンテキストなし状態、コンテキストあり状態のうちの少なくとも１つを含む。

第５態様によれば、圧縮側機器を提供し、前記圧縮側機器は、プロセッサおよびメモリを備える。当該メモリは、コンピュータプログラムを記憶するように構成され、当該プロセッサは、当該メモリに記憶されたコンピュータプログラムを呼び出して実行することにより、上記の第１態様又はその各実施形態における方法を実行するように構成される。

第６態様によれば、解圧縮側機器を提供し、前記解圧縮側機器は、プロセッサおよびメモリを備える。当該メモリは、コンピュータプログラムを記憶するように構成され、当該プロセッサは、当該メモリに記憶されたコンピュータプログラムを呼び出して実行することにより、上記の第２態様又はその各実施形態における方法を実行するように構成される。

第７態様によれば、チップを提供し、前記チップは、上記の第１態様及び第２態様のいずれか又はその各実施形態における方法を実現するように構成される。

具体的に、当該チップは、プロセッサを備え、前記プロセッサは、メモリからコンピュータプログラムを呼び出して実行することにより、当該チップが実装されている機器に、上記の第１態様及び第２態様のいずれか又はその各実施形態における方法を実行させるように構成される。

第８態様によれば、コンピュータプログラムを記憶するように構成されるコンピュータ可読記憶媒体を提供し、当該コンピュータプログラムは、コンピュータに、上記の第１態様及び第２態様のいずれか又はその各実施形態における方法を実行させる。

第９態様によれば、コンピュータプログラム命令を含むコンピュータプログラム製品を提供し、当該コンピュータプログラム命令は、コンピュータに、上記の第１態様及び第２態様のいずれか又はその各実施形態における方法を実行させる。

第１０態様によれば、コンピュータプログラムを提供し、前記コンピュータプログラムがコンピュータで実行されるときに、コンピュータに、上記の第１態様及び第２態様のいずれか又はその各実施形態における方法を実行させる。

上記の解決策を採用することにより、イーサーネットデータパケットを送受信する際に、データパケットヘッダが圧縮され、異なる状態に従って、現在採用すべき圧縮又は解圧縮方式を決定することができる。それにより、イーサーネットデータパケットヘッダをどのように圧縮するかという問題を解決する同時に、エアインターフェイスのリソースオーバーヘッドを削減する。

システムの概略構造図である。 本願実施例に係る通信システムのアーキテクチャの第１の概略図である。 本願実施例に係る圧縮処理方法の例示的なフローチャートである。 本願実施例に係る解圧縮処理方法の例示的なフローチャートである。 本願実施例に係る状態変換の第１の概略図である。 本願実施例に係る状態変換の第２の概略図である。 本願実施例に係る状態変換の第３の概略図である。 本願実施例に係る状態変換の第４の概略図である。 本願実施例に係る処理フローの第１の概略図である。 非圧縮状態のデータパケットフォーマットの概略図である。 圧縮状態のデータパケットフォーマットの概略図である。 本願実施例に係る状態変換の第５の概略図である。 本願実施例に係る処理フローの第２の概略図である。 状態変換の第６の概略図である。 状態変換の第７の概略図である。 本願実施例に係る圧縮側機器の構成の概略構造図である。 本願実施例に係る解圧縮側機器の構成の概略構造図である。 本発明の実施例に係る通信機器の構成の概略構造図である。 本願実施例に係るチップの概略的なブロック図である。 本願実施例に係る通信システムのアーキテクチャの第２の概略図である。

本発明の実施例の特徴および技術内容をより詳細に理解するために、以下、図面を参照して本発明の実施例の具現を詳細に説明し、添付の図面は、例示のみを目的として、本発明の実施例を限定することを意図するものではない。

以下、本願実施例における図面を参照して、本願実施例における技術的解決策を説明するが、説明された実施例は、本願実施例の一部であり、実施例の全部ではないことは明らかである。本願実施例に基づき、創造的な努力なしに当業者が取得した他のすべての実施例は、本願の保護範囲に含まれる。

本願実施例の技術案は、例えば、グローバル移動通信システム（ＧＳＭ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｏｆ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ）、コード分割多重アクセス（ＣＤＭＡ：Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）システム、広帯域コード分離多重アクセス（ＷＣＤＭＡ：Ｗｉｄｅｂａｎｄ Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）システム、汎用パケット無線サービス（ＧＰＲＳ：Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）、ロングタームエボリューション（ＬＴＥ：Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システム、ＬＴＥ周波数分割複信（ＦＤＤ：Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）システム、ＬＴＥ時分割二重化（ＴＤＤ：Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｄｕｐｌｅｘ）、ユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）、ワイマックス（ＷｉＭＡＸ：Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）通信システム又は５Ｇシステムなど、様々な通信システムに適用されることができる。

例示的に、本願実施例に適用される通信システム１００は図－２に示すことができる。当該通信システム１００は、ネットワーク機器１１０を
備えることができ、ネットワーク機器１１０は、端末機器１２０（又は通信端末、端末と称する）と通信する機器であってもよい。ネットワーク機器１１０は、特定の地理的エリアに通信カバレッジを提供することができ、当該カバレッジエリア内に位置する端末機器と通信することができる。例示的に、当該ネットワーク機器１１０は、ＧＳＭシステム又はＣＤＭＡシステムのネットワーク機器（ＢＴＳ：Ｂａｓｅ Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎ）であってもよく、ＷＣＤＭＡシステムのネットワーク機器（ＮＢ：ＮｏｄｅＢ）であってもよく、さらに、ＬＴＥシステムの進化型ネットワーク機器（ｅＮＢ又はｅＮｏｄｅＢ：Ｅｖｏｌｕｔｉｏｎａｌ Ｎｏｄｅ Ｂ）、又はクラウド無線アクセスネットワーク（ＣＲＡＮ：Ｃｌｏｕｄ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）無線コントローラであってもよく、又は、当該ネットワーク機器は、モバイルスイッチングセンタ、リレーステーション、アクセスポイント、車載機器、ウェアラブル機器、ハブ、スイッチ、ブリッジ、５Ｇネットワークのネットワーク側の機器、又は未来進化の公衆陸上移動通信網（ＰＬＭＮ：Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ）のネットワーク機器などであってもよい。

当該通信システム１００は、ネットワーク機器１１０のカバレッジエリア内に位置する少なくとも１つの端末機器１２０をさらに備える。ここで使用される「端末機器」は、公衆交換電話網（ＰＳＴＮ：Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋｓ）、デジタル加入者線（ＤＳＬ：Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）、デジタルケーブル、直接ケーブルを介した接続などの有線回線接続を介した、および／又は別のデータ接続／ネットワークを介した、および／又は、セルラーネットワーク、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ：Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＤＶＢ－Ｈネットワークなどのデジタルテレビネットワーク、衛星ネットワーク、ＡＭ－ＦＭ放送送信機などに対する無線インターフェースを介した、および／又は別の端末の、通信信号を送受信するように設定された装置、および／又は物事のインターネットシステム（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）機器を含むが、これらに限定されない。無線インターフェースを介して通信するように設定された端末機器は、「無線通信端末」、「無線端末」又は「モバイル端末」と称し得る。

例示的に、端末機器１２０間では、装置対装置（Ｄ２Ｄ：Ｄｅｖｉｃｅ ｔｏ Ｄｅｖｉｃｅ）通信を実行することができる。

本明細書における「システム」および「ネットワーク」という用語は、本明細書で常に互換的に使用されることを理解されたい。本明細書における「および／又は」という用語は、関連付けられたオブジェクトを説明する単なる関連付けであり、３タイプ類の関係が存在することができることを示し、例えば、Ａおよび／又はＢは、Ａが独立で存在する場合、ＡとＢが同時に存在する場合、Ｂが独立で存在する場合など３つの場合を表す。さらに、本明細書における記号「／」は、一般的に、コンテキストオブジェクトが「又は」の関係であることを示す。

本発明の実施例の特徴および技術内容をより詳細に理解するために、以下、図面を参照して本発明の実施例の具現を詳細に説明し、添付の図面は、例示のみを目的として、本発明の実施例を限定することを意図するものではない。

本願で言及される数目を表す任意の１つの英語のアルファベットに対応する数目は、同じでも異なっていてもよいことに留意されたい。例えば、ＮとＭの値は同じでも異なってもよい。さらに、前記数目は、１より大きいか等しい整数であってもよい。

本願実施例は、圧縮処理方法を提供し、図２－１に示すように、前記圧縮処理方法は、次のステップを含む。

ステップ２１において、送信されるイーサーネットデータパケットヘッダの状態を決定する。

ステップ２２において、前記送信されるイーサーネットデータパケットヘッダの状態に基づいて、前記送信されるイーサーネットデータパケットヘッダのデータを処理する。

ここで、前記イーサーネットデータパケットヘッダの状態は、非圧縮状態及び圧縮状態のうちの少なくとも１つを含む。

本実施例は、端末機器又はネットワーク機器などの送信機器に適用されることができ、データ送信を行う必要のある任意の機器は、本実施例に記載の送信機器と見なすことができる。

本実施例における圧縮状態は、２つの状況、すなわち、圧縮状態と未圧縮状態を含み得る。又は、圧縮状態は、初期化状態及び更新状態（ＩＲ：ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ）、即ち、非圧縮状態を含むと理解できる。

又は、前記圧縮状態は、部分データ圧縮状態及び全データ圧縮状態のうちの少なくとも１つを含む。

つまり、本実施例では、圧縮状態と非圧縮状態の２つの状況があり得る。また、非圧縮状態、部分データ圧縮状態、及び全データ圧縮状態の３つの状況があり得る。つまり、それらはそれぞれ、初期化と更新状態（ＩＲ：ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ）と、中間状態（ＦＯ：Ｆｉｒｓｔ ｏｒｄｅｒ）と、完全状態（ＳＯ：Ｓｅｃｏｎｄ ｏｒｄｅｒ）と呼ばれることもできる。ここで、完全状態（ＳＯ：Ｓｅｃｏｎｄ ｏｒｄｅｒ）は、全データ圧縮状態であってもよく、中間状態は、部分データ圧縮状態であってもよい。

上記のステップ２２の後、該圧縮処理方法は、処理後のイーサーネットデータパケットヘッダを含む前記イーサーネットデータパケットを送信することを更に含み得ることに留意されたい。

ステップ２１において、送信されるイーサーネットデータパケットヘッダの状態を決定することは、状態が変換するかどうかを決定し、送信されるイーサーネットデータパケットヘッダの状態を決定することを含む。

具体的には、
第１プリセットルールに基づいて、送信されるイーサーネットデータパケットヘッダの状態を決定することを含み得、
ここで、前記第１プリセットルールは、
周期に基づいて、異なる状態間で状態変換を行うと決定すること、
タイマに基づいて、異なる状態間で状態変換を行うと決定すること、
同じ状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、別の圧縮状態に変換することであって、Ｎは整数であること、
確認情報を受信した場合、ある状態から別の状態に変換すること、
否定確認情報を受信した場合、ある状態から別の状態に変換すること、
特定の指示を受信した場合、ある状態から別の状態に変換すること、のうちの少なくとも１つを含む。

つまり、第１プリセットルールに基づいて、現在送信されるイーサーネットデータパケットヘッダの圧縮状態を決定することができる。

以下の説明では、ヘッダ圧縮状態の名前は、初期化状態（ＩＲ）、中間状態（ＦＯ）及び／又は完全状態（ＳＯ）を表す、ヘッダ圧縮の異なる効率（低から高へ）に従って前から後ろに付けられることに留意されたい。

具体的には、周期に基づいて、異なる状態間で状態変換を行うことを決定することは、処理プロセスにおいて、プリセットされた周期に基づいて、複数の状態間で変換を行うことを決定することであり得、更に、現在使用されるイーサーネットデータパケットヘッダの状態を決定することができる。例えば、図３－１を参照すると、圧縮状態及び非圧縮状態の２つの状態の場合、最初の周期では圧縮状態を採用し、次の周期では非圧縮状態を採用することに基づき、現在の周期に従って、現在送信されるデータパケットの状態を決定することができる。又は、３つの状態の場合も、現在の周期に基づいて、送信されるデータパケットの状態を決定することができる。

タイマに基づいて、異なる圧縮状態間で状態変換を行うことを決定することは、上記と同様であり、異なる状態について同じ又は異なるタイマを設定することができ、タイマの期間が対応する時間に達する場合、ある状態から別の状態への変換が実行される。例えば、圧縮状態のタイマがタイムアウトした場合、非圧縮状態に変換し、その逆も同様である。現在のタイマの状態に従って、送信されるイーサーネットデータパケットヘッダが、対応する状態になるように制御する。

前記同じ圧縮状態のＮ個のデータパケットを送信した場合、別の圧縮状態に変換することは、
非圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、非圧縮状態から圧縮状態に変換すること、
非圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、非圧縮状態から部分データ圧縮状態に変換すること、
部分データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、部分データ圧縮状態から全データ圧縮状態に変換すること、
非圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、非圧縮状態から全データ圧縮状態に変換すること、
圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、圧縮状態から非圧縮状態に変換すること、
全データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、全データ圧縮状態から非圧縮状態に変換すること、
全データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、全データ圧縮状態から部分データ圧縮状態に変換すること、
部分データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、部分データ圧縮状態から非圧縮状態に変換すること、のうちの少なくとも１つを含む。

留意されたいこととして、上記の特定の状態でのＮ個のデータパケットを送信することは、特定の状態でのＮ個のデータパケットを連続して送信すること、又は、特定の状態でのＮ個のデータパケットを不連続的に送信することとして理解できる。通常、特定の状態のＮ個のデータパケットを連続して送信する方式を採用する。

つまり、ある状態の複数のデータパケットを送信した場合、次の状態に変換する。元の状態が非圧縮状態であり、２つの状態がある場合、次の状態は圧縮状態であり得、３つの状態がある場合、次の状態は、部分データ圧縮状態又は全データ圧縮状態であり得る。さらに、元の状態が圧縮状態である場合、次の状態は、非圧縮状態であり得る。又は、３つの状態があり、元の状態が全データ圧縮状態である場合、次の状態は、部分データ圧縮状態又は非圧縮状態である。３つの状態の場合、別の状況があり、元の状態が部分データ圧縮状態である場合、次の状態は、全データ圧縮状態又は非圧縮状態であり得る。具体的には、プリセットされたプロトコルに従って、次の状態を決定することができる。

上記に基づいて、本実施形態では、現在送信されるイーサーネットデータパケットヘッダの状態は、現在の送信された少なくとも１つのイーサーネットデータパケットのデータパケットヘッダの状態に基づいて決定できる。例えば、ある状態で現在送信されているデータパケットの数がＮより小さい場合、依然として当該状態で、現在送信されるイーサーネットデータパケットを送信し、データパケットの数がＮに等しい場合、別の状態でイーサーネットデータパケットヘッダを処理して、イーサーネットデータパケットを送信する。

前記確認情報を受信した場合、ある状態から別の状態に変換することは、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、非圧縮状態から圧縮状態に変換すること、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、非圧縮状態から部分データ圧縮状態に変換すること、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、部分データ圧縮状態から全データ圧縮状態に変換すること、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、圧縮状態から全データ圧縮状態に変換すること、のうちの少なくとも１つを含み、
ＭとＣは両方とも１より大きいか等しい整数である。

ここで、ＭとＣは同じでも異なっていてもよく、例えば、ＭがＣより小さくてもよい。つまり、確認情報を連続して受信したと判断した場合、より少ない、受信した確認情報の数で状態変換を実行するかどうかを決定することができ、確認情報を不連続的に受信した場合、それらの確認情報の間には否定確認情報がある可能性がある。この場合、より多くの不連続な確認情報を受信した後、状態変換を実行するかどうかを決定することができる。もちろん、その逆も可能であり、例えば、ＭはＣより大きく、具体的には、両者間のプロトコルに従って決定することができる。

具体的には、元々、非圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＭ個の連続する確認情報、又はＣ個の不連続な確認情報を受信した場合、圧縮状態に変換してイーサーネットデータパケットヘッダを処理し、３つの状態がある場合、部分データ圧縮状態又は全データ圧縮状態に変換することができる。

別の例として、元々、圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＭ個の連続する確認情報、又はＣ個の不連続な確認情報を受信した場合、非圧縮状態に変換してイーサーネットデータパケットヘッダを処理する。

別の例として、元々、部分データ圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＭ個の連続する確認情報、又はＣ個の不連続な確認情報を受信した場合、全データ圧縮状態又は非圧縮状態に変換してイーサーネットデータパケットヘッダを処理する。又は、元々、全データ圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＭ個の連続する確認情報、又はＣ個の不連続な確認情報を受信した場合、部分データ圧縮状態又は非圧縮状態に変換してイーサーネットデータパケットヘッダを処理する。

現在送信されるイーサーネットデータパケットヘッダの状態は、元の状態及び受信された確認情報に基づいて決定できる。例えば、現在、圧縮状態が採用されており、受信した連続する確認情報の数がＭより小さい場合、又は受信した不連続な確認情報の数がＣより小さい場合、現在の状態を変換せずに、データパケットヘッダを処理し、それ以外の場合は、非圧縮状態を採用して処理を実行する。他のシナリオも同様であり、ここでは網羅的な列挙をしない。

別の状況では、確認情報に基づいて高圧縮状態へ移行する場合、２つのタイプの確認情報（ＡＣＫ）を用いてフィードバックする方式、又は３つのタイプのＡＣＫを用いてフィードバックする方式を採用することができる。以下では、２つのタイプの確認情報と３つのタイプの確認情報の処理方式についてそれぞれ説明する。

２つのタイプの確認情報の処理方式：
第１数目の第１タイプのＡＣＫを受信した場合、非圧縮状態又は部分圧縮状態から全データ圧縮状態へ移行することができ、第２数目の第２タイプのＡＣＫを受信した場合、非圧縮状態から部分データ圧縮状態へ移行することができる。つまり、第１タイプの確認情報（ＡＣＫ）は、最も効率の高い状態への状態移行をトリガーするために使用され、第２タイプの確認情報は、より効率の高い状態への状態移行をトリガーするために使用される。ここで、第１数目及び第２数目は、同じでも異なっていてもよく、両方とも、１より大きいか等しい整数である。

３つのタイプの確認情報の処理方式：
第３数目の第１タイプの確認情報を受信した場合、非圧縮状態から全データ圧縮状態に変換し、
第４数目の第２タイプの確認情報を受信した場合、部分データ圧縮状態から全データ圧縮状態に変換し、
第４数目の第３タイプの確認情報を受信した場合、非圧縮状態から部分データ圧縮状態に変換する。

つまり、この処理方式では、第１タイプの確認情報は、全データ圧縮状態への移行をトリガーするために使用され、第２タイプの確認情報は、部分データ圧縮状態から全データ圧縮状態への移行をトリガーするために使用され、第３タイプの確認情報は、非圧縮状態からより効率の高い部分データ圧縮状態への移行をトリガーするために使用される。

同様に、この処理方式では、第３数目、第４数目及び第５数目は、１より大きいか等しい整数であり、同じであるとは限らない。

更に留意されたいこととして、上記の２つの処理方式において、受信した確認情報の数目は、送信されたイーサーネットデータヘッダの数目とは異なる場合があり、例えば、Ｎ個のイーサーネットデータパケットを送信する場合、受信した確認情報の数目は、Ｎより小さいか等しくてもよい。

前記確認情報を受信した場合、ある状態から別の状態に変換することは、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、全データ圧縮状態から部分データ圧縮状態に変換すること、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、全データ圧縮状態から非圧縮状態に変換すること、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、のうちの少なくとも１つを含み、
Ｋ和Ｌは両方とも１より大きいか等しい整数である。

ここで、ＫとＬは、同じでも異なってもよい。

具体的には、元々、非圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＫ個の連続する否定確認情報、又はＬ個の不連続な否定確認情報を受信した場合、圧縮状態に変換してイーサーネットデータパケットヘッダを処理し、３つの状態がある場合、部分データ圧縮状態又は全データ圧縮状態に変換することができる。

別の例として、元々、圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＫ個の連続する否定確認情報、又はＬ個の不連続な否定確認情報を受信した場合、非圧縮状態に変換してイーサーネットデータパケットヘッダを処理する。

別の例として、元々、部分データ圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＫ個の連続する否定確認情報、又はＬ個の不連続な否定確認情報を受信した場合、全データ圧縮状態又は非圧縮状態に変換してイーサーネットデータパケットヘッダを処理する。又は、元々、全データ圧縮状態でイーサーネットデータパケットヘッダを処理し、当該データパケットに対するＫ個の連続する否定確認情報、又はＬ個の不連続な否定確認情報を受信した場合、部分データ圧縮状態又は非圧縮状態に変換してイーサーネットデータパケットヘッダを処理する。

現在送信されるイーサーネットデータパケットヘッダの状態は、元の状態及び受信された確認情報に基づいて決定できる。例えば、現在、圧縮状態が採用されており、受信した連続する否定確認情報の数がＫより小さい場合、又は、受信した不連続な否定確認情報がＬより小さい場合、現在の状態を変換せずに、データパケットヘッダを処理し、それ以外の場合は、非圧縮状態を採用して処理を実行する。他のシナリオも同様であり、ここでは網羅的な列挙をしない。

前記否定確認情報を受信した場合、ある状態から別の状態に変換することは、
Ａ個の第１タイプの否定確認情報を受信した場合、又は連続するＦ個の第１タイプの否定確認情報を受信した場合、全データ圧縮状態から部分データ圧縮状態に変換することであって、Ａ及びＦは、１より大きいか等しい整数であること、
Ａ個の第１タイプの否定確認情報を受信した場合、又は連続するＦ個の第１タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
Ａ個の第１タイプの否定確認情報を受信した場合、又は連続するＦ個の第１タイプの否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、
Ｂ個の第２タイプの否定確認情報を受信した場合、又は連続するＥ個の第２タイプの否定確認情報を受信した場合、全データ圧縮状態から非圧縮状態に変換すること、
Ｂ個の第２タイプの否定確認情報を受信した場合、又は連続するＥ個の第２タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
Ｂ個の第２タイプの否定確認情報を受信した場合、又は連続するＥ個の第２タイプの否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、
Ｇ個の第３タイプの否定確認情報を受信した場合、又は連続するＰ個の第３タイプの否定確認情報を受信した場合、全データ圧縮状態から非圧縮状態に変換することであって、Ｇ及びＰは整数であること、
Ｇ個の第３タイプの否定確認情報を受信した場合、又は連続するＰ個の第３タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
Ｇ個の第３タイプの否定確認情報を受信した場合、又は連続するＰ個の第３タイプの否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、のうちの少なくとも１つを含み、
ここで、前記第１タイプの否定確認情報、第２タイプの否定確認情報、及び第３タイプの否定確認情報は、互いに異なる。

上記のブランチは、様々な状況で組み合わせることができることに留意されたい。つまり、第１タイプの否定確認情報、第２タイプの否定確認情報、及び第３タイプの否定確認情報は、異なる状況で異なる可能性がある。

例えば、第１タイプの否定確認情報は、全データ圧縮状態に対応するフィードバックに用いられ、これに対応して、全データ圧縮状態から非圧縮状態への変換を制御したり、圧縮状態から非圧縮状態への変換を制御したりすることができる。第２タイプの否定確認情報は、部分データ圧縮状態に対応するフィードバックに用いられ、これに対応して、送信側が部分データ圧縮状態を非圧縮状態に変換するようにすることができる。第３タイプの否定確認情報は、全データ圧縮状態のフィードバックに用いられ、これに対応して、送信側が全データ圧縮状態を部分データ圧縮状態に変換するようにすることができる。

あるいは、２つのタイプの否定確認情報のみを採用し、ここで、第１タイプの否定確認情報は、全データ圧縮状態へのフィードバックに用いられ、これに対応して、送信側は、全データ圧縮状態を非圧縮状態に変換することができ、又は、第１タイプの否定確認情報は、全データ圧縮状態のフィードバックに用いられ、これに対応して、送信側は、全データ圧縮状態を部分データ圧縮状態に変換することができる。第２タイプの否定確認情報は、部分データ圧縮状態のフィードバックに用いられ、これに対応して、送信側は、部分データ圧縮状態を非圧縮状態に変換する。

あるいは、２つのタイプの否定確認情報のみを採用し、ここで、第１タイプの否定確認情報は、非圧縮状態のフィードバックに用いられ、これに対応して、送信側は、全データ圧縮状態又は部分データ圧縮状態を非圧縮状態に変換することができ、第２タイプの否定確認情報は、部分データ圧縮状態のフィードバックに用いられ、これに対応して、送信側は、全データ圧縮状態を部分データ圧縮状態に変換することができる。

あるいは、３つのタイプの否定確認情報を採用し、ここで、第１タイプの否定確認情報は、全データ圧縮状態のフィードバックに用いられ、これに対応して、送信側は、部分データ圧縮状態を非圧縮状態又は全データ圧縮状態に変換することができる。第２タイプの否定確認情報は、非圧縮状態のフィードバックに用いられ、これに対応して、送信側は、非圧縮状態を全データ圧縮状態又は部分データ圧縮状態に変換することができ、第３タイプの否定確認情報は、部分データ圧縮状態のフィードバックに用いられ、これに対応して、送信側は、部分データ圧縮状態を非圧縮状態又は全データ圧縮状態に変換することができる。

もちろん、他の組み合わせが存在する可能性もあり、要するに、異なるタイプの否定確認情報は、異なる状態に対応する場合もあれば、異なる状態変換に対応する場合もあり、理解されたいこととして、否定確認情報の状態変換は、低効率又は最低効率の状態への変換である。

これに対応して、送信側は、自体の状態を決定する際に、元の状態、及び受信した第１タイプの否定確認状態、第２タイプ又は第３タイプの否定確認情報に従って、現在使用する状態を決定することができる。

例えば、初期状態が部分データ圧縮状態であり、連続するＢ個の第２のタイプの否定確認情報又は不連続なＥ個の第２タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換する。

理解されたいこととして、このシナリオはまた、周期又はタイマと組み合わせて更に処理できる。例えば、初期状態が非圧縮状態である場合、周期期間が満たされると、別の状態、例えば、圧縮状態、全データ圧縮状態、又は部分データ圧縮状態などに変換することができる。別の例として、初期状態が非圧縮状態である場合、当該タイマの期間が満たされると、別の状態、例えば、圧縮状態、全データ圧縮状態、又は部分データ圧縮状態などに変換することができる。

特定の指示を受信した場合、ある状態から別の状態に変換することは、受信側によって送信された対応する指示の内容に基づいて、どの状態に変換するかを決定することであり得る。例えば、最初に送信されたデータパケットが圧縮状態であり、受信側によってフィードバックされた特定の指示を受信し、当該指示の内容が非圧縮状態に変換することを指示する場合、当該指示に基づいて変換を実行する。つまり、現在送信されるデータパケットヘッダの圧縮状況を決定した場合、特定の指示に基づいて変換された後の状態で送信を行うと決定する。又は現在、部分データ圧縮状態にある場合、特定の指示に従って、全データ圧縮状態への変換を決定するか、又は特定の指示に従って、非圧縮状態への変換を決定する。

更に留意されたいこととして、特定の指示は、上記の確認情報又は否定確認情報及びタイマなどのルールと組み合わせて処理を行うことができる。例えば、第３タイプの否定確認情報を受信した場合、初期状態の全データ圧縮状態から非圧縮状態に変換する同時に、初期状態の全データ圧縮状態から部分データ圧縮状態に変換することを示す特定の指示を受信する必要がある。この場合、プリセットされた様々なルールの優先度に従って処理方法を決定することができ、例えば、特定の指示の優先度が高い場合、特定の指示の内容に基づいて、状態を部分データ圧縮状態に変換することができる。

上記の実施例では、イーサーネットデータパケットヘッダの状態変換は、図３－２に示された２つの状態、すなわち、非圧縮状態と圧縮状態との間の状態変換を参照して説明する。非圧縮状態から圧縮状態への状態変換は、タイマータイムアウトのルールによってトリガーされる状態変換であってもよく、理解されたいこととして、図示されていないが、状態変換は、実際には、様々なルールによってトリガーされることができ、ここでは繰り返して説明しない。圧縮状態から非圧縮状態への状態変換は、タイマータイムアウトによってトリガーされることができ、図に示すように、否定確認情報（ＮＡＣＫ）を受信することによってトリガーされることができ、ここで、ＮＡＣＫを受信することは、複数のＮＡＣＫを受信こと、又は複数のＮＡＣＫを連続して受信することであってもよい。同様に、他のルールによってトリガーされる状態変換は、図示されていないが、実際には、上記の実施例で説明したように、周期的にトリガーされる場合や、指示を受け取ることによってトリガーされる場合など、他のルールによってトリガーされることができ、ここでは繰り返して説明しない。

別の実施例では、受信機器の解圧縮処理方法は、図２－２を参照でき、前記解圧縮処理方法は、次のステップを含む。

ステップ３１において、イーサーネットデータを受信する。

ステップ３２において、解圧縮状態を決定し、前記解圧縮状態に基づいて、前記イーサーネットデータパケットヘッダのデータを処理する。

ここで、前記解圧縮状態は、コンテキストなし状態、コンテキストあり状態のうちの少なくとも１つを含む。

前記コンテキストあり状態は、静的コンテキスト状態及び完全コンテキスト状態のうちの少なくとも１つを含む。

ここで留意されたいこととして、解圧縮状態は、上記の状態に対応することができ、２つのタイプ又は３つのタイプの解圧縮状態があり得る。２つのタイプの解圧縮状態がある場合、コンテキストなし状態は、解圧縮不要状態であってもよく、コンテキストあり状態は、解圧縮する必要がある状態であってもよい。

さらに、３つのタイプの解圧縮状態がある場合、それらは、コンテキストなし状態、静的コンテキスト状態、及び完全コンテキスト状態を含み得る。ここで、コンテキストなし状態も同様に、解圧縮不要状態であってもよく、静的コンテキスト状態は、一部が解圧縮される必要がある状態であってもよく、完全コンテキスト状態は、すべてが解圧縮される必要がある状態であってもよい。

解圧縮状態を決定するプロセスは、状態が変換されるかどうかを決定することを含み得る。

解圧縮状態を決定するプロセスは、プリセットルールに従って実行することができる。つまり、送信側に対応して、圧縮に対応する解圧縮のための第２プリセットルールが提供され、これは、具体的には、
第２プリセットルールに基づいて、解圧縮状態を決定することを含み、
ここで、前記第２プリセットルールは、
周期に基づいて、異なる解圧縮状態間で状態変換を行うと決定すること、
タイマに基づいて、異なる解圧縮状態間で状態変換を行うと決定すること、
同じ解圧縮状態のＨ個のデータパケットを受信又は連続して受信した場合、別の解圧縮状態に変換することであって、Ｈは整数であること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することであって、Ｗは整数であること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することであって、Ｒは整数であり、第１タイプは、第２タイプとは異なること、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することであって、Ｑは整数であり、ここで、第３タイプ、第１タイプ及び第２タイプは互いに異なること、
移行指示を受信した場合、前記移行指示に基づいて解圧縮状態を変換すること、
ある解圧縮状態でのデータパケットの解圧縮が失敗した場合、別の解圧縮状態に変換すること、のうちの少なくとも１つを含む。

特定のデータパケット又は指示を送信した場合、異なる解圧縮状態間で状態変換を行うと決定する。

具体的には、周期に基づいて、異なる解圧縮状態間で状態変換を行うことを決定することは、プロセスにおいて、プリセットされた周期に基づいて、複数の解圧縮状態間で変換を行うことを決定することであり得、更に、現在使用されるイーサーネットデータパケットヘッダの状態を決定することができる。例えば、図４を参照すると、コンテキストなし状態及びコンテキストあり状態の２つの状態の場合、最初の周期ではコンテキストなし状態を採用し、次の周期ではコンテキストあり状態を採用することに基づき、現在の周期に従って、現在のデータパケットの解圧縮状態を決定することができる。又は、３つの状態の場合も、現在の周期に基づいて、解圧縮状態を決定することができる。

タイマに基づいて、異なる解圧縮状態間で状態変換を行うと決定することは、上記と同様であり、異なる状態について同じ又は異なるタイマを設定することができ、タイマの期間が対応する時間に達する場合、ある解圧縮状態から別の解圧縮状態への変換が実行される。例えば、コンテキストあり状態のタイマがタイムアウトした場合、コンテキストなし状態に変換し、その逆も同様である。現在のタイマの状態に従って、送信されるイーサーネットデータパケットヘッダが、対応する状態になるように制御する。

前記同じ解圧縮状態のＨ個（Ｈは整数である）のデータパケットを受信又は連続して受信した場合、別の解圧縮状態に変換することは、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストなし状態からコンテキストあり状態に変換すること、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストあり状態からコンテキストなし状態に変換すること、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストなし状態から静的コンテキスト状態に変換すること、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストなし状態から完全コンテキスト状態に変換すること、
静的コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、静的コンテキスト状態から完全コンテキスト状態に変換すること、
完全コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、完全コンテキスト状態からコンテキストなし状態に変換すること、
完全コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、完全コンテキスト状態から静的コンテキスト状態に変換すること、
静的コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、静的コンテキスト状態からコンテキストなし状態に変換すること、のうちの少なくとも１つを含む。

留意されたいこととして、上記の任意の状態でのＨ個のデータパケットの受信は、特定の解圧縮状態でのＨ個のデータパケットの連続受信、又は特定の解圧縮状態でのＨ個のデータパケットの不連続受信として理解できる。通常、特定の状態でＨ個のデータパケットを連続して受信する方式を採用する。

つまり、ある解圧縮状態の複数のデータパケットを受信した場合、次の解圧縮状態に変換する。元の状態がコンテキストなし状態であり、２つの状態がある場合、次の状態はコンテキストあり状態であり得、３つの状態がある場合、次の状態は、静的コンテキスト状態又は完全コンテキスト状態であり得る。さらに、元の状態が完全コンテキスト状態である場合、次の状態は、静的コンテキスト状態であってもよい。又は、３つの状態があり、元の状態が完全コンテキスト状態である場合、次の状態は、静的コンテキスト状態又はコンテキストなし状態である。３つの状態の場合、別の状況があり、元の状態が静的コンテキスト状態である場合、次の状態は、コンテキストなし状態又は完全コンテキスト状態であり得る。具体的には、プリセットされたプロトコルに従って、次の状態を決定することができる。

上記に基づいて、本実施形態において、現在の解圧縮状態は、現在受信した少なくとも１つのトデータパケットの解圧縮状態に基づいて決定できる。例えば、現在の解圧縮状態で処理されるデータパケットの数がＨより小さい場合、依然として当該解圧縮状態で処理を行い、データパケットの数がＨより大きいか等しい場合、別の解圧縮状態でイーサーネットデータパケットヘッダを処理する。

前記Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することは、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、コンテキストなし状態からコンテキストあり状態に変換すること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、コンテキストなし状態から静的コンテキスト状態に変換すること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、コンテキストなし状態から完全コンテキスト状態に変換すること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態から完全コンテキスト状態に変換すること、のうちの少なくとも１つを含む。

前記Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することは、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、コンテキストあり状態からコンテキストなし状態に変換すること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態からコンテキストなし状態に変換すること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、完全コンテキスト状態からコンテキストなし状態に変換すること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、完全コンテキスト状態から静的コンテキスト状態に変換すること、のうちの少なくとも１つを含む。

また、Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することは、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、コンテキストあり状態からコンテキストなし状態に変換すること、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態からコンテキストなし状態に変換すること、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態から完全コンテキスト状態に変換すること、のうちの少なくとも１つを含む。

上記のブランチは、様々な状況で組み合わせることができることに留意されたい。つまり、第１タイプ、第２タイプ、及び第３タイプのデータパケットは、異なる状況で異なる可能性がある。

例えば、第１タイプのデータパケットは、圧縮なし状態のデータパケットであってもよく、複数の第１タイプのデータパケットを受信又は連続して受信した場合、圧縮側がデータパケットの状態を圧縮状態に変換すると見なすことができ、そうすると、それに対応して、コンテキストなし状態からコンテキストあり状態に変換する。あるいは、３つの状態がある場合、コンテキストなし状態から静的コンテキスト状態に変換するか、又はコンテキストなし状態から完全コンテキスト状態に変換することができる。あるいは、第１タイプのデータパケットは、圧縮なし状態のデータパケットであってもよく、複数の第１タイプのデータパケットを受信又は連続して受信した場合、圧縮側がデータパケットの状態を非圧縮状態に変換すると見なすことができ、そうすると、それに対応して、コンテキストあり状態からコンテキストなし状態に変換する。あるいは、３つの状態がある場合、完全コンテキスト状態から静的コンテキスト状態に変換するか、又は完全コンテキスト状態からコンテキストなし状態に変換することができる。

あるいは、第２タイプのデータパケットは、圧縮状態のデータパケットであってもよく、複数の第２タイプのデータパケットを受信した場合、圧縮側が非圧縮状態に変換すると見なすことができ、そうすると、それに対応して、解圧縮側は、状態をコンテキストなし状態に変換する必要がある。３つの解圧縮状態がある場合、圧縮側が圧縮状態から部分データ圧縮状態に変換する場合があり、それに対応して、解圧縮側は、状態を静的コンテキスト状態に変換することができる。あるいは、圧縮側が非圧縮状態に変換する場合があり、それに対応して、解圧縮側は、解圧縮状態を全コンテキストなし状態に変換することができる。

第３タイプのデータパケットは、圧縮側での部分データ圧縮状態として理解でき、複数の第３タイプのデータパケットを受信又は連続して受信した場合、圧縮側が全データ圧縮状態に変換すると見なすことができ、そうすると、それに対応して、解圧縮側は、状態を完全コンテキスト状態に変換する必要がある。あるいは、圧縮端が、非圧縮状態に変換する場合があり、それに対応して、解圧縮側は、状態をコンテキストなし状態に変換する必要がある。

移行指示を受信した場合、前記移行指示に基づいて解圧縮状態を変換することは、送信側より、受信側が採用する解圧縮状態を指示することであり得、この状況は、送信側によって異なる場合があり、つまり、送信側は、自身の状態に従って、処理に採用される解圧縮状態を受信したことを示す。このような指示は、送信側の状態変換が発生したときに送信される場合もあれば、送信された要求情報を受信したときにフィードバック情報を介して送信される場合もある。又は、データが送信されるたびに、対応する解圧縮状態の指示がデータとともに送信される場合もある。

上記のある解圧縮状態でのデータパケットの解圧縮が失敗した場合、別の解圧縮状態に変換することは、より低い状態への移行として理解でき、例えば、完全コンテキストで解圧縮が失敗した場合、静的コンテキスト状態に変換して解圧縮を実行することができ、再度失敗した場合、コンテキストなし状態に変換して解圧縮を実行することができる。もちろん、高い状態に移行することもでき、例えば、コンテキストなし状態で解圧縮が失敗した場合、静的コンテキスト状態又は完全コンテキスト状態に変換して解圧縮を実行することができる。

更に留意されたいこととして、送信側に対応して、受信側は、複数の確認情報を送信又は連続して送信した場合、すなわち、特定の解圧縮状態のデータパケットを連続して正常に処理した場合、解圧縮状態の移行を決定することができる。例えば、コンテキストなし状態から完全コンテキスト状態又は静的コンテキスト状態に変換するなど、より高い状態に移行することができる。又は、静的コンテキスト状態から完全コンテキスト状態に変換することができる。

又は、受信側が複数の否定確認情報を送信又は連続して送信した場合、すなわち、特定の解圧縮状態で複数のデータパケットの処理に失敗した場合、受信側は、解圧縮状態の移行を決定することができる。例えば、コンテキストあり状態からコンテキストなし状態に移行するなど、より低い状態に移行することができる。又は、完全コンテキスト状態から静的コンテキスト状態に変換するか、又は完全コンテキスト状態からコンテキストなし状態に変換することができる。あるいは、静的コンテキスト状態からコンテキストなし状態に変換することもできる。

図５は、２つの解圧縮状態の場合、２つの解圧縮状態が互いに変換し得ることを示し、コンテキストなし状態のタイマがタイムアウトした場合、コンテキストあり状態に変換するか、又は、コンテキストなし状態で複数のデータパケットを受信又は正常に受信した場合、コンテキストあり状態に変換することができる。もちろん、上記の第２プリセットルールの１つ又は複数のルールの組み合わせに従って、状態変換を制御することができる。コンテキストあり状態にある場合、タイマがタイムアウトしたとき、又はデータパケットを正常に受信しなかったとき、又はデータパケットの解圧縮に失敗したときに、コンテキストなし状態に変換することができる。同様に、上記の第２プリセットルールの１つ又は複数のルールの組み合わせに従って、状態変換を制御することもでき、ここでは繰り返して説明しない。図５は、２つの状態間の変換のみ示しているか、３つの状態間の変換は類似しており、図示しないことに過ぎない。

以下では、送信側がアップリンクデータを送信する端末機器であり、受信側がアップリンクデータを受信するネットワーク機器であることを例として、複数のシナリオについて説明する。具体的には、後続のシナリオの説明において、端末機器は、ユーザ機器（ＵＥ）であってもよく、ネットワーク機器は、ネットワーク側の基地局であってもよい。理解されたいこととして、別の状況では、送信側がネットワーク機器であり、受信側が端末機器である場合があり、この場合、ダウンリンクデータの送受信の処理を行う状況であり得る。どちらのデバイスが送信側又は受信側デバイスとして使用されるかに関係なく、処理方法は同じであるが、本実施形態では網羅的な列挙をしない。

シナリオ１
図６を参照すると、プロセスは、次の通りである。

ステップ４１において、基地局は、イーサーネットデータパケットのためのヘッダ圧縮パラメータを構成し、ＲＲＣメッセージを介して、構成データを伝送し、イーサーネットデータパケットヘッダ圧縮構成をＵＥに構成する。つまり、指示には、ヘッダ圧縮を実行するかどうかの指示、及びヘッダ圧縮の方式が含まれていることができる。

ステップ４２において、ＵＥは、基地局の指示に従って、ヘッダ圧縮を実行するかどうか、及びヘッダ圧縮を実行する方法を決定する。

ここで、ＵＥは、基地局によって送信されたイーサーネットデータパケットヘッダ圧縮構成情報に従って、Ｅｔｈｅｒｎｅｔヘッダ圧縮を実行するかどうか、及びヘッダ圧縮を実行するサブヘッダ／サブヘッダタイプなどを決定する。

例えば、フィールドの一部、すなわち、宛先アドレス（ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ）、ソースアドレス（ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ）、タイプ又は長さ（ＴＹＰＥ／ＬＥＮＧＴＨ）、仮想ドメイン（Ｑ－ＴＡＧｓ）（ｉｎｃｌｕｄｉｎｇ ａｌｌ ｓｕｂ－ｆｉｅｌｄｓ）に対してのみ、ヘッダ圧縮を実行することができる。

別の例として、イーサーネットデータパケットヘッダの静的な部分又は変化しない部分に対してヘッダ圧縮処理を実行する。ヘッダ圧縮を実行する特定の対象又はフィールド又はフィールドタイプは、プロトコルで事前に作成されているか、ＲＲＣ構成で指示される場合がある。

圧縮可能なフィールドを分類することができる。

静的フィールドタイプは、ＤＥＳＴＩＮＡＴＩＯＮ ＡＤＤＲＥＳＳ、ＳＯＵＲＣＥ ＡＤＤＲＥＳＳ、ＴＹＰＥ／ＬＥＮＧＴＨ、Ｑ－ＴＡＧｓ（ｉｎｃｌｕｄｉｎｇ ａｌｌ ｓｕｂ－ｆｉｅｌｄｓ）のうちの少なくとも１つを含むが、これらに限定されない。

可変フィールドタイプは、ＴＹＰＥ、ＰＲＩ／ＰＣＰ、ＣＦＩ／ＤＥＩのうちの少なくとも１つを含むが、これらに限定されない。

留意されたいこととして、ほとんどの場合、圧縮可能なＥｔｈｅｒｎｅｔヘッダの全てのｆｉｅｌｄは、ＭＡＣアドレス、Ｑ－Ｔａｇｓ、Ｔｙｐｅ／ｌｅｎｇｔｈなどの静的タイプに属すると見なすことができる。

ステップ４３において、ＵＥは、上記のステップに基づいて、状態移行を含むヘッダ圧縮操作を実行する。

具体的な状態変換は、例示的に、次の通りである。

初期のヘッダ圧縮状態は、非圧縮状態又はＩＲ状態である。

ヘッダ圧縮機能が開始するとき、又は最初の時刻に、ＵＥ（圧縮側）は、非圧縮状態又はＩＲ状態にあり、ＵＥは、圧縮していないＥｔｈｅｒｎｅｔデータパケットを送信する。

留意されたいこととして、イーサーネットデータパケットヘッダのフォーマットで運ばれる情報は、イーサーネットデータパケットフレームヘッダ圧縮識別子、コンテキスト識別子、フレームチェックシーケンス（ＦＣＳ）／識別子、ヘッダが圧縮されているかどうかの指示、シーケンス番号（ＳＮ）、巡回冗長検査（ＣＲＣ）、非圧縮フィールド／サブヘッダの識別子、及び非圧縮フィールド／サブヘッダの指示のうちの少なくとも１つを含む。

前記イーサーネットデータパケットヘッダのフォーマットの場合、圧縮状態のデータパケットと非圧縮状態のデータパケットは異なるフォーマット（すなわち、独立したパケットフォーマット）を採用する。つまり、異なるタイプのパケットは、異なるパケットフォーマットを使用する。例えば、イーサーネットデータパケットヘッダ圧縮を実行する少なくとも１つのパケットのフォーマットと、非圧縮（完全なパケット情報を含む）Ｅｔｈｅｒｎｅｔフレームのパケットフォーマットを定義する。及び／又は、圧縮状態のデータパケットと非圧縮状態のデータパケットは同じフォーマットを採用し、圧縮状態のデータパケットの識別ビットの値は、非圧縮状態のデータパケットの識別ビットの値と少なくとも１ビットの値が異なる。つまり、パケットフォーマットは統一され、圧縮パケット及び非圧縮パケット（完全なパケット情報を含む）は、同じパケットフォーマットを採用する。

例えば、異なる状態のデータパケットフォーマットは、図７及び図８に示されている。図７及び図８では、圧縮パケットのタイプの識別ビットの値が異なるため、２つのタイプが区別されていることが分かる。ここで、非圧縮状態のフォーマットは図７に示され、識別ビットの値は「１１１１１１０Ｄ」又は「１１１１１１１０」であり得る。図８の圧縮状態のデータパケットフォーマットにおいて、その識別ビットの値は「１１１１１０００」であり、異なる状態のデータパケットは、識別ビットの値によって区別できることがわかる。

さらに、異なる状態のデータパケットのフォーマットは、異なるフォーマットに従って区別することができ、図７及び図８は、依然として説明のために使用される。図７は、２つのデータパケットのフォーマットを示し、両方とも、非圧縮状態のデータパケットを表す。ここから分かるように、データパケットのフォーマットは、動的チェーン及び静的チェーンを含み得るか、又は動的チェーンのみを含み得る。図８では、圧縮状態のデータパケットのフォーマットは、静的チェーン及び動的チェーンを含まないか、又は、静的チェーンと動的チェーンのうちの１つを含むことがわかる。

部分データ圧縮状態でのデータパケットのフォーマット及び全データ圧縮状態でのデータパケットのフォーマットも、異なっていてもよい。図８を参照すると、部分データ圧縮状態でのデータパケットのフォーマットは、図８の左側部分であり得、すなわち、静的チェーンを含み、フォーマットの識別ビットは「１１１１１０００」であり、又はフォーマットは、図８の中間部分であり得、動的チェーンのみを含み、識別ビットは「１１１１１０００」である。全データ圧縮状態のフォーマットは、静的チェーン及び動的チェーンを含まなくてもよく、フォーマットは「１１１１１０００」である。

別の例として、データパケットの異なる状態は、異なる識別子（すなわち、識別ビットの異なる値）によって区別される。例えば、部分データ圧縮状態のデータパケットの識別子は「１１１１１０００」であり、全データ圧縮状態のデータパケットの識別子は「１１１１１１００」であり、非圧縮状態のデータパケットの識別子は「１１１１１１１０」である。

更に理解されたいこととして、フォーマットに関する上記の２つの定義は、組み合わせて使用でき、例えば、フォーマットに違いがあり、識別ビットによっても区別される場合もある。上記のとおり、ここでは繰り返して説明しない。

圧縮されたパケットは下向きに配信され、ＰＤＣＰ層及び／又はＲＬＣ層などの層の処理を実行する。

ステップ４４において、基地局に圧縮されたパケットを送信する。

Ｎ個の圧縮されていないＥｔｈｅｒｎｅｔデータパケットを送信した後、ＵＥは状態移行を実行し、状態を圧縮状態又はＣＯ（Ｃｏｍｐｒｅｓｓｉｏｎ Ｏｒｄｅｒ）状態に変換する。

ＵＥが圧縮状態又はＣＯ状態にある場合、タイマがタイムアウト（ｔｉｍｅｏｕｔ）した後、ＵＥは、低圧縮状態、即ち、非圧縮状態への移行を実行する。

その後、上記のステップを繰り返して実行する。可能な循環処理方式は、図９を参照でき、例えば、パケットが最初に非圧縮状態にある場合、非圧縮状態にあるＮ個のデータパケットを送信した後、圧縮状態に変換し、さらに、タイマを組み合わせて、タイマがタイムアウト時間に達すると、非圧縮状態に変換する。

圧縮側及び解圧縮側は、特定のルールに従って、これらの状態間で移行して、ヘッダの圧縮及び解圧縮の操作を完了する。

基地局は、解圧縮側として、圧縮されたパケットを解圧縮し、解圧縮後のパケットを上方に配信し、具体的には、次のステップを含み得る。

ステップ４５において、基地局は、状態移行を含む解圧縮処理を実行する。

具体的には、基地局は、ＵＥからの圧縮されたデータパケットを受信した後、対応するルール及びマッピング関係に従って、受信されたパケットのタイプ（圧縮されているかどうか）を決定し、圧縮されていないパケットに対してコンテキスト（Ｃｏｎｔｅｘｔ）更新／格納を実行し、受信した圧縮パケットに対して解圧縮処理を実行し、対応する状態移行を実行する。

具体的な状態変換は、例示的に、次の通りである。

初期の解圧縮状態は、Ｎｏ ｃｏｎｔｅｘｔ状態である。

ヘッダ圧縮機能が開始するとき、又は最初の時刻に、基地局（解圧縮側）は、コンテキストなし状態にあり、基地局は、圧縮側によって送信された圧縮されていないＥｔｈｅｒｎｅｔデータパケットを受信した後、異なるパス（ｃｏｎｔｅｘｔ ＩＤなど）に従って、データパケットに対してｃｏｎｔｅｘｔの更新又は格納を実行する。

Ｎ個の圧縮されていないＥｔｈｅｒｎｅｔデータパケットを受信した後、又はＮ個の圧縮していないＥｔｈｅｒｎｅｔデータパケットを正常に受信／解圧縮した後、解圧縮側は、高圧縮状態、すなわち、ｃｏｎｔｅｘｔが格納されている状態（ｆｕｌｌ ｃｏｎｔｅｘｔ状態、又はｓｔａｔｉｃ ｃｏｎｔｅｘｔ状態と呼ばれることができる）への状態移行を実行する。

解圧縮側、すなわち、基地局がｃｏｎｔｅｘｔが格納されている状態（ｆｕｌｌ ｃｏｎｔｅｘｔ状態、又はｓｔａｔｉｃ ｃｏｎｔｅｘｔ状態と呼ばれることができる）にある場合、ｔｉｍｅｏｕｔした後、基地局は、低圧縮状態、すなわち、Ｎｏ ｃｏｎｔｅｘｔ状態への移行を実行する。

その後、上記のステップを繰り返して実行する。

このシナリオでは、上記の圧縮側の２つの状態の説明に加えて、実際には、３つの状態間で移行が発生する可能性がある。

例えば、圧縮側が非圧縮状態（ＩＲ状態）で複数のパケットを送信した後、部分データ圧縮状態（ＦＯ状態）への移行を実行し、部分データ圧縮状態（ＦＯ状態）で複数のパケットを送信した後、全データ圧縮状態（ＳＯ状態）への移行を実行する。全データ圧縮状態（ＳＯ状態）のタイマがタイムアウトすると、部分データ圧縮状態（ＦＯ状態）に戻り、部分データ圧縮状態（ＦＯ状態）でタイマがタイムアウトすると、非圧縮状態（ＩＲ状態）に戻る。

これに対応して、解圧縮側は、３つの状態の場合の処理を実行することができる。

例えば、コンテキストなし状態で複数の正常に解圧縮されたパケットを受信した後、静的コンテキスト状態への移行が実行され、静的コンテキスト状態で複数の正常に解圧縮されたパケットを受信した後、完全コンテキスト状態への移行が実行される。完全コンテキスト状態でタイマがタイムアウト（ｔｉｍｅｏｕｔ）すると、静的コンテキスト状態に戻り、静的コンテキスト状態でタイマがｔｉｍｅｏｕｔすると、コンテキストなし状態に戻る。

留意されたいこととして、異なる状態間の変換のために、同様のメカニズムを採用してもよいし、異なるメカニズムを採用してもよい。例えば、すべての変換にタイマを採用してもよい。別の例として、一部の状態変換は、タイマメカニズムを採用し、他の変換は複数のパケットを送信する方法を採用する。ここではそれらに対して限定しない。

留意されたいこととして、３つの状態が定義されている場合でも、それらのうちの２つだけが使用できる。

シナリオ２では、圧縮端と解圧縮側との間で、ヘッダ圧縮フィードバックパケット（フィードバック状態パケット）の伝送をサポートし、言い換えれば、フィードバックに基づく状態変換方式を採用することにより、圧縮側と解圧縮側との間の状態移行がより信頼できる又は効率的な方式で実行されることができる。

イーサーネットデータパケットヘッダの圧縮側及び／又は解圧縮側の状態移行は、フィードバックベースの状態移行方法に基づいている。

イーサーネットデータパケットヘッダフォーマットで運ばれるパラメータ又は識別子情報、フォーマット及び状態は、上記のものと同様であり、ここでは繰り返して説明しない。

以下では、ＵＬデータパケットの処理についてのみ説明し、ダウンリンクパケットのヘッダ圧縮処理も同様である。図１０に示されたように、プロセスは、次の通りである。

ステップ５１において、基地局は、イーサーネットデータパケットヘッダ圧縮パラメータを構成し、ＵＥのための構成データの伝送を実行し、イーサーネットデータパケットヘッダ圧縮構成を伝送する。例えば、基地局は、ＲＲＣメッセージを介して、Ｅｔｈｅｒｎｅｔ ｆｒａｍｅ情報ヘッダ圧縮のパラメータを構成する。

ステップ５２において、ＵＥは、基地局の指示に従って、ヘッダ圧縮を実行するかどうか、及びヘッダ圧縮を実行する方法を決定する。

具体的には、ＵＥは、基地局によって送信されたＥｔｈｅｒｎｅｔヘッダ圧縮構成情報に従って、Ｅｔｈｅｒｎｅｔヘッダ圧縮を実行するかどうか、及びヘッダ圧縮を実行するサブヘッダ／サブヘッダタイプなどを決定する。例えば、Ｅｔｈｅｒｎｅｔヘッダのソースアドレス、目標基地局、Ｅｔｈｅｒｎｅｔ ｔｙｐｅ、Ｔ－ｔａｇｓに対してヘッダ圧縮処理を実行する。例えば、Ｅｔｈｅｒｎｅｔヘッダの静的な部分又は変化しない部分に対してヘッダ圧縮処理を実行する。ヘッダ圧縮を実行する特定の対象又はｆｉｅｌｄ又はｆｉｅｌｄタイプは、プロトコルで事前に作成されているか、ＲＲＣ構成で指示される場合がある。

ステップ５３において、ＵＥは、上記のステップに基づいて、状態移行を含むヘッダ圧縮操作を実行する。

具体的な状態変換は、例示的に、次の通りである。

初期のヘッダ圧縮状態は、非圧縮状態又はＩＲ状態である。

可能な状態の移行は、図１１に示す。例えば、ヘッダ圧縮機能が開始するとき、又は最初の時刻に、ＵＥ（圧縮側）は、非圧縮状態又はＩＲ状態にあり、ＵＥは、圧縮していないＥｔｈｅｒｎｅｔデータパケットを送信する。Ｎ個の圧縮されていないＥｔｈｅｒｎｅｔデータパケットを送信した後、ＵＥは、圧縮状態又はＣＯ状態への状態移行を実行する。さらに、ＵＥが非圧縮状態又はＩＲ状態にある場合、ＵＥは、非圧縮状態のＮ個のデータパケットを送信し、解圧縮側機器によってフィードバックされたＮ個の確認情報（ＡＣＫ）を受信したとき、状態移行を実行する。例えば、圧縮状態又はＣＯ状態に移行することができる。これに対応して、解圧縮側は、非圧縮状態のＭ個のデータパケットを受信又は正常に受信した後、又は正常に解圧縮した後、Ｍ個の確認情報をＵＥにフィードバックする同時に、解圧縮側は、高い状態に移行する。ここで、ＭとＮは異なり、ＭはＮより小さくてもよい。

ＵＥが圧縮状態又はＣＯ状態にある場合、解圧縮側によって送信された状態レポートを受信し、状態レポートがＮＡＣＫ状態を指示する場合、又はＹ個の圧縮パケットのＮＡＣＫ解圧縮状態を受信した後、ＵＥは、状態を低圧縮状態、すなわち、非圧縮状態に移行する。さらに、ＵＥが圧縮状態又はＣＯ状態にある場合、ＵＥは、圧縮状態のＹ個のデータパケットを送信し、解圧縮側機器によってフィードバックされたＬ個の否定確認情報（ＮＡＣＫ）を受信した場合、状態移行を実行し、状態を低圧縮状態、例えば、非圧縮状態に移行することができる。これに対応して、解圧縮側が圧縮状態のＬ個のデータパケットを受信できない場合、又は圧縮状態のＬ個のデータパケットを正常に解圧縮できない場合、Ｌ個の否定確認情報（ＮＡＣＫ）をＵＥにフィードバックする同時に、解圧縮側は、低い状態に移行する。ここで、ＬとＹは異なってもよく、例えば、ＬはＹより小さくてもよい。

その後、上記のステップを繰り返して実行する。

ＵＥは、圧縮されたパケットを下方に配信し、ＰＤＣＰ層及び／又はＲＬＣ層などの層の処理を実行する。

ステップ５４において、圧縮後のデータパケットを基地局に送信する。

基地局は、解圧縮側として、圧縮されたパケットを解圧縮し、次に、解圧縮後のパケットを上方に配信する。

ステップ５５において、基地局は、状態移行処理を含む解圧縮処理を実行する。

ステップ５６において、基地局は、フィードバックパケットをＵＥに送信する。

具体的には、基地局は、ＵＥからの圧縮されたデータパケットを受信した後、対応するルール及びマッピング関係に従って、受信されたパケットのタイプ（圧縮されているかどうか）を決定し、圧縮されていないパケットに対してＣｏｎｔｅｘｔ更新／格納を実行し、受信した圧縮パケットに対して解圧縮処理を実行し、対応する状態移行を実行する。

具体的な状態変換は、例示的に、次の通りである。

初期の解圧縮状態は、Ｎｏ ｃｏｎｔｅｘｔ状態である。

例えば、図１２を参照すると、ヘッダ圧縮機能が開始するとき、又は最初の時刻に、基地局（解圧縮側）は、Ｎｏ ｃｏｎｔｅｘｔ状態にあり、基地局は、圧縮側によって送信された圧縮されていないＥｔｈｅｒｎｅｔデータパケットを受信した後、異なるパス（ｃｏｎｔｅｘｔ ＩＤなど）に従って、データパケットに対してｃｏｎｔｅｘｔの更新又は格納を実行する。

Ｎ個の圧縮されていないＥｔｈｅｒｎｅｔデータパケットを受信した後、又はＮ個の圧縮していないＥｔｈｅｒｎｅｔデータパケットを正常に受信／解圧縮した後、解圧縮側は、高圧縮状態、すなわち、ｃｏｎｔｅｘｔが格納されている状態（ｆｕｌｌ ｃｏｎｔｅｘｔ状態、又はｓｔａｔｉｃ ｃｏｎｔｅｘｔ状態と呼ばれることができる）への状態移行を実行する。

解圧縮側、すなわち、基地局がｃｏｎｔｅｘｔが格納されている状態（ｆｕｌｌ ｃｏｎｔｅｘｔ状態、又はｓｔａｔｉｃ ｃｏｎｔｅｘｔ状態と呼ばれることができる）にある場合、解圧縮によりＹ個の圧縮パケットのＮＡＣＫ解圧縮状態を取得した後、又は、ＮＡＣＫ状態が搬送されているＥｔｈｅｎｅｔ状態レポートを送信した後、基地局は、低圧縮状態、すなわち、Ｎｏ ｃｏｎｔｅｘｔ状態への移行を実行する。

その後、上記のステップを繰り返して実行する。

更に留意されたいこととして、上記の説明は、２つの圧縮状態及び２つの解圧縮状態に関するものであるか、実際には、圧縮側に３つの状態が存在する可能性があり、３つの状態間の移行は、次の通りである。

圧縮側は、非圧縮状態（ＩＲ状態）でＮ個のパケットを送信した後、部分データ圧縮状態（ＦＯ状態）に移行し、部分データ圧縮状態（ＦＯ状態）でＮ個のパケットを送信した後、全データ圧縮状態（ＳＯ状態）に移行する。

これに対応して、解圧縮側はまた、３つの状態の処理を実行することができる。

例えば、コンテキストなし状態で複数の正常に解圧縮されたパケットを受信した後、静的コンテキスト状態に移行し、静的コンテキスト状態で複数の正常に解圧縮されたパケットを受信した後、完全コンテキスト状態に移行する。完全コンテキスト状態で第１タイプのＮＡＣＫを送信した場合、静的コンテキスト状態に戻り、静的コンテキスト状態で第１タイプのＮＡＣＫを送信した場合、コンテキストなし状態に戻る。

留意されたいこととして、異なる状態間の変換のために、同様のメカニズムを採用してもよいし、異なるメカニズムを採用してもよい。例えば、すべての変換にタイマを採用してもよい。別の例として、一部の状態変換は、指示情報に従って実行され、他の状態変換は、受信されたＮＡＣＫ又はＡＣＫに従って決定されることができ、ここでは網羅的な列挙をしない。

ここから分かるように、上記の解決策を採用することにより、イーサーネットデータパケットを送受信する際に、データパケットヘッダが圧縮され、異なる状態に従って、現在採用すべき圧縮又は解圧縮方式を決定することができる。それにより、イーサーネットデータパケットヘッダをどのように圧縮するかという問題を解決する同時に、エアインターフェイスのリソースオーバーヘッドを削減する。

本願実施例は、圧縮側機器を提供し、図１３に示すように、前記圧縮側機器は、第１処理ユニット６１を備える。

前記第１処理ユニット６１は、送信されるイーサーネットデータパケットヘッダの状態を決定し、
前記送信されるイーサーネットデータパケットヘッダの状態に基づいて、前記送信されるイーサーネットデータパケットヘッダのデータを処理するように構成され、
ここで、前記イーサーネットデータパケットヘッダの状態は、非圧縮状態及び圧縮状態のうちの少なくとも１つを含む。

本実施例は、端末機器又はネットワーク機器などの送信機器に適用されることができ、データ送信を行う必要のある任意の機器は、本実施例に記載の送信機器と見なすことができる。

本実施例における圧縮状態は、２つの状況、すなわち、圧縮状態と未圧縮状態を含み得る。又は、圧縮状態は、初期化状態及び更新状態（ＩＲ：ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ）、即ち、非圧縮状態を含むと理解できる。

又は、前記圧縮状態は、部分データ圧縮状態及び全データ圧縮状態のうちの少なくとも１つを含む。

つまり、本実施例では、圧縮状態と非圧縮状態の２つの状況があり得る。また、非圧縮状態、部分データ圧縮状態、及び全データ圧縮状態の３つの状況があり得る。つまり、それらはそれぞれ、初期化と更新状態ＩＲ（ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ）と、中間状態（ＦＯ：Ｆｉｒｓｔ ｏｒｄｅｒ）と、完全状態（ＳＯ：Ｓｅｃｏｎｄ ｏｒｄｅｒ）と呼ばれることもできる。ここで、完全状態（ＳＯ：Ｓｅｃｏｎｄ ｏｒｄｅｒ）は、全データ圧縮状態であってもよく、中間状態は、部分データ圧縮状態であってもよい。

前記圧縮側機器は更に、処理後のイーサーネットデータパケットヘッダが含まれている前記イーサーネットデータパケットを送信するように構成される第１通信ユニットを備えることができることに留意されたい。

第１処理ユニット６１が、送信されるイーサーネットデータパケットヘッダの状態を決定することは、状態が変換されるかどうかを決定し、送信されるイーサーネットデータパケットヘッダの状態を決定することを含む。

具体的には、
第１プリセットルールに基づいて、送信されるイーサーネットデータパケットヘッダの状態を決定することを含み得、
ここで、前記第１プリセットルールは、
周期に基づいて、異なる状態間で状態変換を行うと決定すること、
タイマに基づいて、異なる状態間で状態変換を行うと決定すること、
同じ状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、別の圧縮状態に変換することであって、Ｎは整数であること、
確認情報を受信した場合、ある状態から別の状態に変換すること、
否定確認情報を受信した場合、ある状態から別の状態に変換すること、
特定の指示を受信した場合、ある状態から別の状態に変換すること、のうちの少なくとも１つを含む。

つまり、第１プリセットルールに基づいて、現在送信されるイーサーネットデータパケットヘッダの圧縮状態を決定することができる。

以下の説明では、ヘッダ圧縮状態の名前は、初期化状態（ＩＲ）、中間状態（ＦＯ）及び／又は完全状態（ＳＯ）を表す、ヘッダ圧縮の異なる効率（低から高へ）に従って前から後ろに付けられることに留意されたい。

前記第１処理ユニット６１は、
非圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、非圧縮状態から圧縮状態に変換すること、
非圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、非圧縮状態から部分データ圧縮状態に変換すること、
部分データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、部分データ圧縮状態から全データ圧縮状態に変換すること、
非圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、非圧縮状態から全データ圧縮状態に変換すること、
圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、圧縮状態から非圧縮状態に変換すること、
全データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、全データ圧縮状態から非圧縮状態に変換すること、
全データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、全データ圧縮状態から部分データ圧縮状態に変換すること、
部分データ圧縮状態のイーサーネットデータパケットヘッダのＮ個のデータパケットを送信した場合、部分データ圧縮状態から非圧縮状態に変換すること、のうちの少なくとも１つを実行するように構成される。

留意されたいこととして、上記の特定の状態でのＮ個のデータパケットを送信することは、特定の状態でのＮ個のデータパケットを連続して送信すること、又は、特定の状態でのＮ個のデータパケットを不連続的に送信することとして理解できる。通常、特定の状態のＮ個のデータパケットを連続して送信する方式を採用する。

つまり、ある状態の複数のデータパケットを送信した場合、次の状態に変換する。元の状態が非圧縮状態であり、２つの状態がある場合、次の状態は圧縮状態であり得、３つの状態がある場合、次の状態は、部分データ圧縮状態又は全データ圧縮状態であり得る。さらに、元の状態が圧縮状態である場合、次の状態は、非圧縮状態であり得る。又は、３つの状態があり、元の状態が全データ圧縮状態である場合、次の状態は、部分データ圧縮状態又は非圧縮状態である。３つの状態の場合、別の状況があり、元の状態が部分データ圧縮状態である場合、次の状態は、全データ圧縮状態又は非圧縮状態であり得る。具体的には、プリセットされたプロトコルに従って、次の状態を決定することができる。

上記に基づいて、本実施形態では、現在送信されるイーサーネットデータパケットヘッダの状態は、現在の送信された少なくとも１つのイーサーネットデータパケットのデータパケットヘッダの状態に基づいて決定できる。例えば、ある状態で現在送信されているデータパケットの数がＮより小さい場合、依然として当該状態で、現在送信されるイーサーネットデータパケットを送信し、データパケットの数がＮに等しい場合、別の状態でイーサーネットデータパケットヘッダを処理して、イーサーネットデータパケットを送信する。

前記第１処理ユニット６１は、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、非圧縮状態から圧縮状態に変換すること、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、非圧縮状態から部分データ圧縮状態に変換すること、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、部分データ圧縮状態から全データ圧縮状態に変換すること、
連続するＭ個の確認情報を受信した場合、又はＣ個の確認情報を受信した場合、圧縮状態から全データ圧縮状態に変換すること、のうちの少なくとも１つを実行するように構成され、
ＭとＣは両方とも１より大きいか等しい整数である。

ここで、ＭとＣは同じでも異なっていてもよく、例えば、ＭがＣより小さくてもよい。つまり、確認情報を連続して受信したと判断した場合、より少ない、受信した確認情報の数で状態変換を実行するかどうかを決定することができ、確認情報を不連続的に受信した場合、それらの確認情報の間には否定確認情報がある可能性がある。この場合、より多くの不連続な確認情報を受信した後、状態変換を実行するかどうかを決定することができる。もちろん、その逆も可能であり、例えば、ＭはＣより大きく、具体的には、両者間のプロトコルに従って決定することができる。

前記第１処理ユニット６１は、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、全データ圧縮状態から部分データ圧縮状態に変換すること、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、全データ圧縮状態から非圧縮状態に変換すること、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
連続するＫ個の否定確認情報を受信した場合、又は、Ｌ個の否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、のうちの少なくとも１つを実行するように構成され、
Ｋ和Ｌは両方とも１より大きいか等しい整数である。

ここで、ＫとＬは、同じでも異なってもよい。

前記第１処理ユニット６１は、
Ａ個の第１タイプの否定確認情報を受信した場合、又は連続するＦ個の第１タイプの否定確認情報を受信した場合、全データ圧縮状態から部分データ圧縮状態に変換することであって、Ａ及びＦは、１より大きいか等しい整数であること、
Ａ個の第１タイプの否定確認情報を受信した場合、又は連続するＦ個の第１タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
Ａ個の第１タイプの否定確認情報を受信した場合、又は連続するＦ個の第１タイプの否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、
Ｂ個の第２タイプの否定確認情報を受信した場合、又は連続するＥ個の第２タイプの否定確認情報を受信した場合、全データ圧縮状態から非圧縮状態に変換すること、
Ｂ個の第２タイプの否定確認情報を受信した場合、又は連続するＥ個の第２タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
Ｂ個の第２タイプの否定確認情報を受信した場合、又は連続するＥ個の第２タイプの否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、
Ｇ個の第３タイプの否定確認情報を受信した場合、又は連続するＰ個の第３タイプの否定確認情報を受信した場合、全データ圧縮状態から非圧縮状態に変換することであって、Ｇ及びＰは整数であること、
Ｇ個の第３タイプの否定確認情報を受信した場合、又は連続するＰ個の第３タイプの否定確認情報を受信した場合、部分データ圧縮状態から非圧縮状態に変換すること、
Ｇ個の第３タイプの否定確認情報を受信した場合、又は連続するＰ個の第３タイプの否定確認情報を受信した場合、圧縮状態から非圧縮状態に変換すること、のうちの少なくとも１つを実行するように構成され、
ここで、前記第１タイプの否定確認情報、第２タイプの否定確認情報、及び第３タイプの否定確認情報は、互いに異なる。

上記のブランチは、様々な状況で組み合わせることができることに留意されたい。つまり、第１タイプの否定確認情報、第２タイプの否定確認情報、及び第３タイプの否定確認情報は、異なる状況で異なる可能性がある。

別の実施例では、解圧縮側機器を提供し、図１４を参照すると、前記解圧縮側機器は、
イーサーネットデータを受信するように構成される第２通信ユニット７１と、
解圧縮状態を決定し、前記解圧縮状態に基づいて、前記イーサーネットデータパケットヘッダのデータを処理するように構成される第２処理ユニット７２と、を備え、
ここで、前記解圧縮状態は、コンテキストなし状態、コンテキストあり状態のうちの少なくとも１つを含む。

前記コンテキストあり状態は、静的コンテキスト状態及び完全コンテキスト状態のうちの少なくとも１つを含む。

ここで留意されたいこととして、解圧縮状態は、上記の状態に対応することができ、２つのタイプ又は３つのタイプの解圧縮状態があり得る。２つのタイプの解圧縮状態がある場合、コンテキストなし状態は、解圧縮不要状態であってもよく、コンテキストあり状態は、解圧縮する必要がある状態であってもよい。

さらに、３つのタイプの解圧縮状態がある場合、それらは、コンテキストなし状態、静的コンテキスト状態、及び完全コンテキスト状態を含み得る。ここで、コンテキストなし状態も同様に、解圧縮不要状態であってもよく、静的コンテキスト状態は、一部が解圧縮される必要がある状態であってもよく、完全コンテキスト状態は、すべてが解圧縮される必要がある状態であってもよい。

解圧縮状態を決定するプロセスは、状態が変換されるかどうかを決定することを含み得る。

解圧縮状態を決定するプロセスは、プリセットルールに従って実行することができる。つまり、送信側に対応して、圧縮に対応する解圧縮のための第２プリセットルールが提供され、これは、具体的には、
第２プリセットルールに基づいて、解圧縮状態を決定することを含み得、
ここで、前記第２プリセットルールは、
周期に基づいて、異なる解圧縮状態間で状態変換を行うと決定すること、
タイマに基づいて、異なる解圧縮状態間で状態変換を行うと決定すること、
同じ解圧縮状態のＨ個のデータパケットを受信又は連続して受信した場合、別の解圧縮状態に変換することであって、Ｈは整数であること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することであって、Ｗは整数であること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することであって、Ｒは整数であり、第１タイプは、第２タイプとは異なること、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、ある解圧縮状態から別の解圧縮状態に変換することであって、Ｑは整数であり、ここで、第３タイプ、第１タイプ及び第２タイプは互いに異なること、
移行指示を受信した場合、前記移行指示に基づいて解圧縮状態を変換すること、
ある解圧縮状態でのデータパケットの解圧縮が失敗した場合、別の解圧縮状態に変換すること、のうちの少なくとも１つを含む。

特定のデータパケット又は指示を送信した場合、異なる解圧縮状態間で状態変換を行うと決定する。

具体的には、周期に基づいて、異なる解圧縮状態間で状態変換を行うことを決定することは、プロセスにおいて、プリセットされた周期に基づいて、複数の解圧縮状態間で変換を行うことを決定することであり得、更に、現在使用されるイーサーネットデータパケットヘッダの状態を決定することができる。例えば、図４を参照すると、コンテキストなし状態及びコンテキストあり状態の２つの状態の場合、最初の周期ではコンテキストなし状態を採用し、次の周期ではコンテキストあり状態を採用することに基づき、現在の周期に従って、現在のデータパケットの解圧縮状態を決定することができる。又は、３つの状態の場合も、現在の周期に基づいて、解圧縮状態を決定することができる。

タイマに基づいて、異なる解圧縮状態間で状態変換を行うと決定することは、上記と同様であり、異なる状態について同じ又は異なるタイマを設定することができ、タイマの期間が対応する時間に達する場合、ある解圧縮状態から別の解圧縮状態への変換が実行される。例えば、コンテキストあり状態のタイマがタイムアウトした場合、コンテキストなし状態に変換し、その逆も同様である。現在のタイマの状態に従って、送信されるイーサーネットデータパケットヘッダが、対応する状態になるように制御する。

前記第２処理ユニット７２は、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストなし状態からコンテキストあり状態に変換すること、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストあり状態からコンテキストなし状態に変換すること、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストなし状態から静的コンテキスト状態に変換すること、
コンテキストなし状態のＨ個のデータパケットを受信又は連続して受信した場合、コンテキストなし状態から完全コンテキスト状態に変換すること、
静的コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、静的コンテキスト状態から完全コンテキスト状態に変換すること、
完全コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、完全コンテキスト状態からコンテキストなし状態に変換すること、
完全コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、完全コンテキスト状態から静的コンテキスト状態に変換すること、
静的コンテキスト状態のＨ個のデータパケットを受信又は連続して受信した場合、静的コンテキスト状態からコンテキストなし状態に変換すること、のうちの少なくとも１つを実行するように構成される。

留意されたいこととして、上記の任意の状態でのＨ個のデータパケットの受信は、特定の解圧縮状態でのＨ個のデータパケットの連続受信、又は、特定の解圧縮状態でのＨ個のデータパケットの不連続受信として理解できる。通常、特定の状態でＨ個のデータパケットを連続して受信する方式を採用する。

前記第２処理ユニット７２は、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、コンテキストなし状態からコンテキストあり状態に変換すること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、コンテキストなし状態から静的コンテキスト状態に変換すること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、コンテキストなし状態から完全コンテキスト状態に変換すること、
Ｗ個の第１タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態から完全コンテキスト状態に変換すること、のうちの少なくとも１つを実行するように構成される。

前記第２処理ユニット７２は、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、コンテキストあり状態からコンテキストなし状態に変換すること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態からコンテキストなし状態に変換すること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、完全コンテキスト状態からコンテキストなし状態に変換すること、
Ｒ個の第２タイプのデータパケットを受信又は連続して受信した場合、完全コンテキスト状態から静的コンテキスト状態に変換すること、のうちの少なくとも１つを実行するように構成される。

更に、前記第２処理ユニット７２は、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、コンテキストあり状態からコンテキストなし状態に変換すること、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態からコンテキストなし状態に変換すること、
Ｑ個の第３タイプのデータパケットを受信又は連続して受信した場合、静的コンテキスト状態から完全コンテキスト状態に変換すること、のうちの少なくとも１つを実行するように構成される。

留意されたいこととして、イーサーネットデータパケットヘッダのフォーマットで運ばれる情報は、イーサーネットデータパケットフレームヘッダ圧縮識別子、コンテキスト識別子、フレームチェックシーケンス（ＦＣＳ）／識別子、ヘッダが圧縮されているかどうかの指示、シーケンス番号（ＳＮ）、巡回冗長検査（ＣＲＣ）、非圧縮フィールド／サブヘッダの識別子、及び非圧縮フィールド／サブヘッダの指示のうちの少なくとも１つを含む。

前記イーサーネットデータパケットヘッダのフォーマットの場合、圧縮状態のデータパケットと非圧縮状態のデータパケットは異なるフォーマット（すなわち、独立したパケットフォーマット）を採用する。つまり、異なるタイプのパケットは、異なるパケットフォーマットを使用する。例えば、イーサーネットデータパケットヘッダ圧縮を実行する少なくとも１つのパケットのフォーマットと、非圧縮（完全なパケット情報を含む）Ｅｔｈｅｒｎｅｔフレームのパケットフォーマットを定義する。及び／又は、圧縮状態のデータパケットと非圧縮状態のデータパケットは同じフォーマットを採用し、圧縮状態のデータパケットの識別ビットの値は、非圧縮状態のデータパケットの識別ビットの値と少なくとも１ビットの値が異なる。つまり、パケットフォーマットは統一され、圧縮パケット及び非圧縮パケット（完全なパケット情報を含む）は、同じパケットフォーマットを採用する。

例えば、異なる状態のデータパケットフォーマットは、図７及び図８に示されている。図７及び図８では、圧縮パケットのタイプの識別ビットの値が異なるため、２つのタイプが区別されていることがわかる。ここで、非圧縮状態のフォーマットは図７に示され、識別ビットの値は「１１１１１１０Ｄ」又は「１１１１１１１０」であり得る。図８の圧縮状態のデータパケットフォーマットにおいて、その識別ビットの値は「１１１１１０００」であり、異なる状態のデータパケットは、識別ビットの値によって区別できることがわかる。

さらに、異なる状態のデータパケットのフォーマットは、異なるフォーマットに従って区別することができ、図７及び図８は、依然として説明のために使用される。図７は、２つのデータパケットのフォーマットを示し、両方とも、非圧縮状態のデータパケットを表す。ここから分かるように、データパケットのフォーマットは、動的チェーン及び静的チェーンを含み得るか、又は動的チェーンのみを含み得る。図８では、圧縮状態のデータパケットのフォーマットは、静的チェーン及び動的チェーンを含まないか、又は、静的チェーンと動的チェーンのうちの１つを含むことがわかる。

部分データ圧縮状態でのデータパケットのフォーマット及び全データ圧縮状態でのデータパケットのフォーマットも、異なっていてもよい。図８を参照すると、部分データ圧縮状態でのデータパケットのフォーマットは、図８の左側部分であり得、すなわち、静的チェーンを含み、フォーマットの識別ビットは「１１１１１０００」であり、又はフォーマットは、図８の中間部分であり得、動的チェーンのみを含み、識別ビットは「１１１１１０００」である。全データ圧縮状態のフォーマットは、静的チェーン及び動的チェーンを含まなくてもよく、フォーマットは「１１１１１０００」である。別の例として、データパケットの異なる状態は、異なる識別子（すなわち、識別ビットの異なる値）によって区別される。例えば、部分データ圧縮状態のデータパケットの識別子は「１１１１１０００」であり、全データ圧縮状態のデータパケットの識別子は「１１１１１１００」であり、非圧縮状態のデータパケットの識別子は「１１１１１１１０」である。

更に理解されたいこととして、フォーマットに関する上記の２つの定義は、組み合わせて使用でき、例えば、フォーマットに違いがあり、識別ビットによっても区別される場合もある。上記のとおり、ここでは繰り返して説明しない。

ここから分かるように、上記の解決策を採用することにより、イーサーネットデータパケットを送受信する際に、データパケットヘッダが圧縮され、異なる状態に従って、現在採用すべき圧縮又は解圧縮方式を決定することができる。それにより、イーサーネットデータパケットヘッダをどのように圧縮するかという問題を解決する同時に、エアインターフェイスのリソースオーバーヘッドを削減する。

図１５は、本願実施例に係る通信機器８００の概略構造図であり、通信機器は、本実施例に記載の端末機器又はネットワーク機器であってもよい。図１６に示された通信機器８００はプロセッサ８１０を備え、プロセッサ８１０は、メモリからコンピュータプログラムを呼び出して実行することにより、本願実施例における方法を実現することができる。

例示的に、図１５に示されたように、通信機器８００はさらに、メモリ８２０を備えることができる。ここで、プロセッサ８１０は、メモリ８２０からコンピュータプログラムを呼び出して実行することにより、本願実施例における方法を実現することができる。

ここで、メモリ８２０は、プロセッサ８１０から独立した別個のデバイスであってもよいし、プロセッサ８１０に統合されてもよい。

例示的に、図１５に示されたように、通信機器８００は更に、トランシーバ８３０を備えることができ、プロセッサ８１０は、当該トランシーバ８３０を制御して、他の機器と通信することができ、具体的には、情報又はデータを他の機器に送信するか、又は他の機器によって送信された情報又はデータを受信することができる。

ここで、トランシーバ８３０は、送信機および受信機を備えることができる。トランシーバ８３０は更に、アンテナを備えることができ、アンテナの数は１つ又は複数であってもよい。

例示的に、前記通信機器８００は、具体的に、本願実施例に係る圧縮側機器又は解圧縮側機器であってもよく、前記通信機器８００は、本願実施例による各方法において、モバイル端末／端末機器によって実現される対応するプロセスを実現することができ、簡潔にするために、ここでは再び説明しない。

図１６は、本願実施例に係るチップの概略的な構造図である。図１６に示されたチップ９００は、プロセッサ９１０を備え、プロセッサ９１０は、メモリからコンピュータプログラムを呼び出して実行することにより、本願実施例における方法を実現することができる。

例示的に、図１６に示されたように、チップ９００は更に、メモリ９２０を備えることができる。ここで、プロセッサ９１０は、メモリ９２０からコンピュータプログラムを呼び出して実行することにより、本願実施例における方法を実現することができる。

ここで、メモリ９２０は、プロセッサ９１０から独立した別個のデバイスであってもよいし、プロセッサ９１０に統合されてもよい。

例示的に、当該チップ９００は更に、入力インターフェース９３０を備えることができる。ここで、プロセッサ９１０は、当該入力インターフェース９３０を制御して、他の機器又はチップと通信することができ、具体的には、他の機器又はチップによって送信される情報又はデータを取得することができる。

例示的に、当該チップ９００は更に、出力インターフェース９４０を備えることができる。ここで、プロセッサ９１０は、当該出力インターフェース９４０を制御して、他の機器又はチップと通信することができ、具体的には、情報又はデータを他の機器又はチップに出力することができる。

例示的に、当該チップは、本願実施例における圧縮側機器又は解圧縮側機器に適用されてもよく、さらに、当該チップは、本願実施例による各方法において、ネットワーク機器によって実現される対応するプロセスを実現することができ、簡潔にするために、ここでは繰り返して説明しない。

本願実施例で言及されるチップは、システムレベルのチップ、システムチップ、チップシステム又はシステムオンチップなどとも称し得ることを理解されたい。

図１７は、本願実施例に係る通信システム１０００の例示的なブロック図である。図１７に示されたように、当該通信システム１０００は、圧縮側機器１０１０及び解圧縮側機器１０２０を備える。

ここで、当該圧縮側機器１０１０は、上記の方法で端末機器によって実現される対応する機能を実現するように構成されることができ、当該解圧縮側機器１０２０は、上記の方法でネットワーク機器によって実現される対応する機能を実現するように構成されることができ、簡潔にするために、ここでは繰り返して説明しない。

本願実施例におけるプロセッサは、信号の処理能力を備えた集積回路チップであり得ることを理解されたい。実現プロセスにおいて、上記の方法の実施例の各ステップは、プロセッサにおけるハードウェアの集積論理回路又はソフトウェアの形の命令によって完了されることができる。上述のプロセッサは、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、特定用途向け集積回路（ＡＳＩＣ：Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ：Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）又は他のプログラマブルロジックデバイス、ディスクリートゲート又はトランジスタロジックデバイス、ディスクリートハードウェアコンポーネントなどであってもよい。本願実施例で開示された各方法、ステップおよび論理ブロック図を実現又は実行することができる。汎用プロセッサは、マイクロプロセッサであってもよいし、任意の従来のプロセッサなどであってもよい。本願実施例を組み合たせて開示された方法のステップは、ハードウェア復号化プロセッサによって実行されて完了すると直接に具現されることができ、又は復号化プロセッサにおけるハードウェアおよびソフトウェアモジュールの組み合わせによって実行されて完了してもよい。ソフトウェアモジュールは、ランダムメモリ、フラッシュメモリ、読み取り専用メモリ、プログラマブル読み取り専用メモリ又は電気的に消去可能なプログラマブルメモリ、レジスタなど当技術分野の熟知する記憶媒体に配置されてもよい。当該記憶媒体はメモリに配置され、プロセッサはメモリの情報を読み取り、そのハードウェアと組み合わせて前記方法のステップを完了する。

本願実施例におけるメモリは、揮発性メモリ又は不揮発性メモリであってもよく、又は揮発性および不揮発性メモリの両方を含んでもよいことを理解されたい。ここで、不揮発性メモリは、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、プログラム可能な読み取り専用メモリ（ＰＲＯＭ：Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）、消去可能なプログラム可能な読み取り専用メモリ（ＥＰＲＯＭ：Ｅｒａｓａｂｌｅ ＰＲＯＭ）、電気的に消去可能なプログラム可能な読み取り専用メモリ（ＥＥＰＲＯＭ：Ｅｌｅｃｔｒｉｃａｌｌｙ ＥＰＲＯＭ）又はフラッシュメモリであってもよい。揮発性メモリは、外部キャッシュとして使用されるランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）であってもよい。例示的であるが限定的ではない例示によれば、多くの形のＲＡＭ、例えば、スタティックランダムアクセスメモリ（ＳＲＡＭ：Ｓｔａｔｉｃ ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ：Ｄｙｎａｍｉｃ ＲＡＭ）、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ：Ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）、ダブルデータレートの同期ダイナミックランダムアクセスメモリ（ＤＤＲ ＳＤＲＡＭ：Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ ＳＤＲＡＭ）、拡張型同期ダイナミックランダムアクセスメモリ（ＥＳＤＲＡＭ：Ｅｎｈａｎｃｅｄ ＳＤＲＡＭ）、同期接続ダイナミックランダムアクセスメモリ（ＳＬＤＲＡＭ：Ｓｙｎｃｈｌｉｎｋ ＤＲＡＭ）およびダイレクトメモリバスランダムアクセスメモリ（ＤＲ ＲＡＭ：Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＲＡＭ）などが利用可能である。本明細書で説明されるシステムおよび方法のためのメモリは、これらおよび任意の他の適切なタイプのメモリを含むが、これらに限定されないことを意図していることを留意されたい。

上記のメモリは、例示的なものであるが、限定的なものではないことを理解されたい。例えば、本願実施例におけるメモリは、スタティックランダムアクセスメモリ（ＳＲＡＭ：ｓｔａｔｉｃ ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ：ｄｙｎａｍｉｃ ＲＡＭ）、同期ダイナミックランダムアクセスメモリ（ＳＤＲＡＭ：ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）、ダブルデータレートの同期ダイナミックランダムアクセスメモリ（ＤＤＲ ＳＤＲＡＭ：ｄｏｕｂｌｅ ｄａｔａ ｒａｔｅ ＳＤＲＡＭ）、拡張型同期ダイナミックランダムアクセスメモリ（ＥＳＤＲＡＭ：ｅｎｈａｎｃｅｄ ＳＤＲＡＭ）、同期接続ダイナミックランダムアクセスメモリ（ＳＬＤＲＡＭ：ｓｙｎｃｈ ｌｉｎｋ ＤＲＡＭ）およびダイレクトメモリバスランダムアクセスメモリ（ＤＲ ＲＡＭ：Ｄｉｒｅｃｔ Ｒａｍｂｕｓ ＲＡＭ）などであってもよい。つまり、本願実施例におけるメモリは、これらおよび他の任意の適切なタイプのメモリを含むが、これらに限定されないことを意図する。

本願実施例は、コンピュータプログラムを記憶するためのコンピュータ可読記憶媒体をさらに提供する。

例示的に、当該コンピュータ可読記憶媒体は、本願実施例におけるネットワーク機器に適用されることができ、さらに、当該コンピュータプログラムは、コンピュータに、本願実施例による各方法において、ネットワーク機器によって実現される対応するプロセスを実行させ、簡潔にするために、ここでは繰り返して説明しない。

例示的に、当該コンピュータ可読記憶媒体は、本願実施例における端末機器に適用されることができ、さらに、当該コンピュータプログラムは、コンピュータに、本願実施例による各方法において、モバイル端末／端末機器によって実現される対応するプロセスを実行させ、簡潔にするために、ここでは繰り返して説明しない。

本願実施例は、コンピュータプログラム命令を含むコンピュータプログラム製品をさらに提供する。

例示的に、当該コンピュータプログラム製品は、本願実施例におけるネットワーク機器に適用されることができ、さらに、当該コンピュータプログラム命令は、コンピュータに、本願実施例による各方法において、ネットワーク機器によって実現される対応するプロセスを実行させ、簡潔にするために、ここでは繰り返して説明しない。

例示的に、当該コンピュータプログラム製品は、本願実施例におけるモバイル端末／端末機器に適用されることができ、さらに、当該コンピュータプログラム命令は、コンピュータに、本願実施例による各方法において、モバイル端末／端末機器によって実現される対応するプロセスを実行させ、簡潔にするために、ここでは繰り返して説明しない。

本願実施例は、コンピュータプログラムをさらに提供する。

例示的に、当該コンピュータプログラムは、本願実施例におけるネットワーク機器に適用されることができ、当該コンピュータプログラムがコンピュータによって実行されるときに、コンピュータに、本願実施例による各方法において、ネットワーク機器によって実現される対応するプロセスを実行させ、簡潔にするために、ここでは繰り返して説明しない。

例示的に、当該コンピュータプログラムは、本願実施例のモバイル端末／端末機器に適用されることができ、当該コンピュータプログラムがコンピュータで実行されるときに、コンピュータに、本願実施例による各方法において、モバイル端末／端末機器によって実現される対応するプロセスを実行させ、簡潔にするために、ここでは繰り返して説明しない。

当業者なら自明であるが、本明細書で開示される実施例に関連して説明される各例示のユニットおよびアルゴリズムステップは、電子ハードウェア、又はコンピュータソフトウェアと電子ハードウェアの組み合わせによって実現されてもよい。これらの機能がハードウェアの形で実行されるかソフトウェアの形で実行されるかは、技術的解決策の特定の用途と設計上の制約条件に依存する。当業者は、各特定の用途について異なる方法を使用して、説明された機能を実現することができるが、このような実現は、本願の範囲を超えると見なされるべきではない。

当業者なら明確に理解できるが、説明の便宜及び簡潔さのために、上記に説明されたシステム、装置及びユニットの具体的な作業プロセスは、上記の方法の実施例における対応するプロセスを参照することができ、ここでは繰り返して説明しない
本願で提供されたいくつかの実施例において、開示されたシステム、装置及び方法は、他の方式で実現できることを理解されたい。例えば、上記の装置の実施例は、例示的なものに過ぎず、例えば、前記ユニットの分割は、論理機能の分割に過ぎず、実際の実現では、他の分割方法があり得、例えば、複数のユニット又はコンポーネントを別のシステムに統合又は集積したり、又は一部の特徴を無視したり、又は実行しないことができる。なお、表示又は議論される相互結合又は直接結合又は通信接続は、いくつかのインターフェースを介して実現でき、装置又はユニット間の間接的な結合又は通信接続は、電気的又は機械的な形であってもよいし、他の形であってもよい。

前記分離部材として説明されたユニットは、物理的に分離されている場合とされていない場合があり、ユニットとして表示された部材は、物理ユニットである場合もそうでない場合もあり、１箇所に配置される場合もあれば、複数のネットワークユニットに分散される場合もある。実際の必要に応じて、その中のユニットの一部又は全部を選択して本実施例の解決策の目的を達成することができる。

さらに、本願の各実施例における各機能ユニットは１つの処理ユニットに統合されてもよく、又は各ユニットは別個の物理的ユニットであってもよく、又は２つ以上のユニットが１つのユニットに統合されてもよい。

上述の機能がソフトウェア機能ユニットの形で実現され、かつスタンドアロン製品として販売又は使用される場合、１つのコンピュータ可読記憶媒体に記憶されることができる。このような理解に基づいて、本願の技術的解決策の本質的な部分、すなわち、先行技術に貢献のある部分、又は前記技術的解決策の一部は、ソフトウェア製品の形で具現されることができ、当該コンピュータソフトウェア製品は、１つの記憶媒体に記憶され、コンピュータ機器（パーソナルコンピュータ、サーバ、又はネットワーク機器等であり得る）に、本願の各実施例に記載の方法のステップの全部又は一部を実行させるためのいくつかの命令を含む。前述した記憶媒体は、Ｕディスク、モバイルハードディスク、読み取り専用メモリ（ＲＯＭ：Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ）、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、磁気ディスク又は光ディスク等のプログラムコードを記憶することができる様々な媒体を含む。

上記の説明は、本願の具体的な実施形態に過ぎず、本願の保護範囲はこれに限定されない。当業者は、本願に開示された技術的範囲内で容易に想到し得る変換又は置換は、すべて本願の保護範囲内に含まれるべきである。したがって、本願の保護範囲は、特許請求の範囲の保護範囲に従うものとする。

Claims (43)

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. コンピュータプログラムであって、
    コンピュータに、請求項１ないし１８のいずれか一項に記載の方法を実行させる、前記コンピュータプログラム。

Images