JP2006502654A - ヘッダ圧縮方法 - Google Patents

Abstract

本発明はパケットを基本とした通信システムにおけるヘッダ圧縮に関するものである。圧縮器が望まないモード変更の要求を拒絶することができる機構が提案される。圧縮器は伸張器に対してモード変更要求が無視されていることを示唆すると、これ以降、圧縮器がこれを拒絶する正当な理由があると理解するなら、伸張器は開始されたモード移行を中断できる。圧縮器は好ましくは、リンク監視によりその拒絶が成功したかどうかを判断し、拒絶成功の場合には、圧縮器は現在のモードに留まる。好適な実施例では、再定義されたモード値を用いたモード変更拒絶メッセージを介して明示的な拒絶シグナリングを実行する。本発明の拒絶シグナリングにより、圧縮器は特定のモードへの移行を不能にすることが可能になり、全てのモードのサブセットのみをもつ実施形を可能にする。

Description

本発明は一般的にパケットを基本とした通信システムに関するものであり、特に、ヘッダ圧縮に関する方法と手段に関するものである。

インターネットの非常に大きな成功により、全ての種類のリンクにわたりインターネットプロトコル（ＩＰ）を利用することが挑戦的な仕事になってきている。しかしながら、一般にＩＰプロトコルパケットのヘッダは、そのデータ（ペイロード）に比べてかなり大きなものであるので、セルラリンクのようなバンド幅の狭いリンクについては、このことは特に困難である。例えば、通常の会話データがインターネット電話（ＶｏＩＰ）に用いられるプロトコルにより転送されるとき、そのヘッダはしばしばそのパケットの７０％ほどの大きさを表すものとなり、この結果、リンク利用は最も非効率なものとなる。

ヘッダ圧縮とは、ポイント−ツウ−ポイントリンクによるホッピング毎を基本にして（per-hop basis）ヘッダで搬送される情報のために必要なバンド幅を最小にする技術に言及したものである。ＲＦＣ１１４４（非特許文献１）、ＲＦＣ２５０７（非特許文献２）、ＲＦＣ２５０８（非特許文献３）を含むいくつかのヘッダ圧縮プロトコルがある。ヘッダ圧縮の原理は、いくつかのヘッダフィールドはフロー内で変化しないか、或いは、小さな或いは予測可能な値で変化するという事実を利用している。これらの特性は、ヘッダ圧縮方式により用いられ、その方式では最初にだけ静的情報を送信する一方、変化するフィールドはその絶対値か或いはパケットからパケットへの差として送信される。完全にランダムな情報が、少しの圧縮もなく送信されねばならない。

ヘッダ圧縮は、回路交換の音声に代わって無線によるＶｏＩＰ（ＶｏＩＰｏＷ）を経済的にも可能性のあるものとするための重要な要素であり、この目的のため、ロバストヘッダ圧縮（ＲＯＨＣ）のための解決策が開発されてきた。ＲＦＣ３０９５（非特許文献４）で定義されているようにＲＯＨＣは広範な枠組みであり、そのため種々のプロトコルの圧縮についてのプロファイルが定義される。ＶｏＩＰについては、アプリケーションデータが、エンド−ツウ−エンドで、ＩＰ／ユーザデータグラムプロトコル（ＵＤＰ）／リアルタイム転送プロトコル（ＲＴＰ）ストリーム内を転送される。ＩＰ／ＵＤＰ／ＲＴＰのヘッダ圧縮は、ＲＯＨＣプロファイル０ｘ０００１（ＲＯＨＣ ＲＴＰ）で定義され、中でもＶｏＩＰサービスに適用可能である。ＲＯＨＣ ＲＴＰヘッダ圧縮方式は、任意のリンクレイヤにより効率的にヘッダを圧縮するために設計されたものである。たいていの機能性はＲＯＨＣ ＲＴＰ方式それ自身により扱われ、ネゴシエーションを除く、フレーミングとエラー検出だけがリンクレイヤにより提供されることが必要である。

ＲＯＨＣは３つの異なる動作モードをもっている。それは、具体的なコンテキストに対しては、異なる状態のヘッダ圧縮動作中に、実行するための動作とロジックとともに、用いるためのパケットタイプとを制御する。許されているパケットタイプとフォーマットとはあるモードから別のモードへと変化するかもしれない。別のモードへの移行が発生する前に、単方向モード（Ｕ−モード）が、何らかのＲＯＨＣ圧縮の始まりで用いられる。双方向オプティミスティックモード（Ｏ−モード）は圧縮効率を最大にする目的をもち、ほとんど用いられないフィードバックチャネルと関係する。双方向リライアブルモード（Ｒ−モード）は、損失とコンテキスト損傷の伝播に対抗する耐性を最大にする目的をもつ。

Ｕ−モードにおいて、パケットが圧縮器から伸張器にだけ送信されるとき、このモードは、伸張器から圧縮器への戻り経路が望まれていないか、或いは利用可能ではない場合のリンクにより利用可能であり、そして、定期的なリフレッシュがこのモードでは用いられる。Ｏ−モードはＵ−モードと類似しているが、異なる点は、フィードバックチャネルがエラー回復要求と（オプション的に）伸張器から圧縮器への重要なコンテキストの更新の確認応答を送信するために用いられる点である。Ｕ−モードとＯ−モードとは、その特性が非常に類似しているので、しばしばいっしょにされてＵ／Ｏモードとして言及される。Ｒ−モードは２つの他のモードとはかなり異なっており、その違いは主としてフィードバックチャネルがより広範に用いられ、コンテキスト更新を実行するロジックがより厳密である点である。Ｒ−モードはまた、このモードで理解され有用な２〜３の異なるパケットタイプを用いるだけである。

各動作モードは、圧縮効率、耐性、及び処理の複雑さの点から異なる特性をもつ。ＲＯＨＣは（ＲＯＨＣ圧縮がＵ−モードでいつも開始しなければならないことを除き）各モードがいつどのように用いられるべきであるのかを規定していない。これにより、モード移行のロジックは実施上の問題になる。モード移行は伸張器により開始されるだけかもしれないし、ロバストヘッダ圧縮（ＲＦＣ３０９５）についての現在の仕様によれば、ＲＯＨＣの実施毎に全てのモードの動作をサポートしなければならない。

従来のヘッダ圧縮方式の上記の特性は要求は数多くの問題や欠点と関係している。

ヘッダ圧縮のベンダはおそらく、動作の具体的なモードについての圧縮器の実施形を最適化するであろう。例えば、それは、メモリ要求や要求される処理能力を最小化するためである。しかしながら、特定の実施形が実際にその好適なモードで用いられることの保証はない。その代わりに、最適とはいえない動作が無理やり押し付けられ、結果として、圧縮効率やリンク性能が低下してしまうことがあるかもしれない。

別の問題は、ＲＯＨＣの実施形が全ての圧縮モードをサポートするために多くの機能が必要とされる点にある。かなりの実施形や確認や試験が実現されねばならず、それは相対的に長期の実行時間と高い実行費用とを意味する。具体的なある環境では、全てのモードが必ずしも有用ではないかもしれない。さらにその上、プログラムの規模と相互動作可能なＲＯＨＣアルゴリズムの実施形を構築するために必要な時間との内、少なくともいずれかを最小にするために、特定の実施作業者の展開戦略に一致したモードだけをサポートすることがしばしば望ましい。

従って、従来の通信システムのヘッダ圧縮は満足から程遠いものにあり、ヘッダ圧縮方法の改善に強い必要があり、特に、圧縮モードの柔軟性を提供する方法が強く望まれる。
ヴァン ジェイコブソン(Van Jacobson)著、低速シリアルリンク用ＴＣＰ／ＩＰヘッダ(TCP/IP Headers for Low-Speed Serial Links)、ＩＥＴＦ ＲＦＣ１１４４、ＩＥＴＦネットワーク作業グループ(IETF Networking Group)、１９９０年２月 ミカエル デーゲルマーク(Mikael Degermark)、ビヨルン ノルドゲン(Bjorn Nordgen)、ステファン ピンク(Stephen Pink)著、ＩＰヘッダ圧縮(IP Header Compression)、ＩＥＴＦ ＲＦＣ２５０７、ＩＥＴＦネットワーク作業グループ(IETF Networking Group)、１９９９年２月 スティーブン キャスナー(Steven Casner)、ヴァン ジェイコブソン(Van Jacobson)著、低速シリアルリンク用ＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮(Compressing IP/UDP/RTP Headers for Low-Speed Serial Links)、ＩＥＴＦ ＲＦＣ２５０８、ＩＥＴＦネットワーク作業グループ(IETF Networking Group)、１９９９年２月 カールステン ボルマン（Carsten Bormann）他著、ロバストヘッダ圧縮（ＲＯＨＣ）：フレームワークと４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰ、及び非圧縮(RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed)、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月 ギスライン ペレティエル(Ghyslain Pelletier)著、ロバストヘッダ圧縮（ＲＯＨＣ）：ＵＤＰ系のプロファイル：(RObust Header Compression (ROHC): Profiles for UDP-Lite)、インターネットドラフト版、２００３年４月 インターネット(http://www.ietf.org/internet-drafts/draft-ietf-rohc-udp-lite-00.txt) ラルス−エリク イョンソン(Lars-Erik Jonsson)、ギスライン ペレティエル(Ghyslain Pelletier)著、ロバストヘッダ圧縮（ＲＯＨＣ）：ＩＰ用圧縮プロファイル(RObust Header Compression (ROHC): A compression profile for IP)、インターネットドラフト版、２００３年６月 インターネット(http://www.ietf.org/internet-drafts/draft-ietf-rohc-ip-only-02.txt) ラルス−エリク イョンソン(Lars-Erik Jonsson)、ギスライン ペレティエル(Ghyslain Pelletier)著、ロバストヘッダ圧縮（ＲＯＨＣ）：ＩＰ／ＵＤＰ／ＲＴＰ用リンクレイヤアシステッドＲＯＨＣプロファイル(RObust Header Compression (ROHC): A Link-Layer Assisted ROHC Profile for IP/UDP/RTP)、ＩＥＴＦ ＲＦＣ３２４２、２００２年２月 チガング リウ(Zhigang Liu)、キーム リー(Khiem Le)著、拡張されたリンクレイヤアシステッドＲＯＨＣプロファイルにおけるＲ−モード用０−バイトサポート（0-byte Support for R-mode in Extended Link Layer Assisted ROHC Profile）インターネットドラフト版、２００２年４月

本発明の概括的な目的は、より効率的なヘッダ圧縮を達成することにある。具体的な目的は、圧縮モードに関して、柔軟的なヘッダ圧縮についての機構を提供することにある。別の目的は、ヘッダ圧縮方式を容易に実施することを可能にすることにある。

これらの目的は、添付した請求の範囲に従って達成される。

簡単に言えば、本発明は、圧縮器が伸張器からの望ましくないモード変更要求を拒絶することを可能にした機構によってより効率的なヘッダ圧縮を達成する。提案された方法に従えば、その圧縮器は、好ましくは、暗示的な或いは明示的なシグナリングにより、伸張器に対して、モード変更要求が拒絶／無視されていることを示唆する。この示唆に応答して、伸張器は、その後、その伸張器がモード移行を拒絶する正当な理由をもつことを理解するなら、その開始された移行を中断する。もし、圧縮器がその示唆された拒絶に気づくなら、拒絶が成功することを意味する拒絶確認応答の動作により応答する。その拒絶確認応答は、例えば、モード変更要求の再送信の頻度を少なくすることや再送信の終了を伴ったり、或いは、明示的な拒絶確認応答のメッセージを伴うことができる。圧縮器は、好ましくは、伸張器のシグナリングの挙動を監視そして解釈することにより、その拒絶が成功かどうかを決定し、そして、拒絶の成功の場合には、その圧縮器は、現在のモードに留まる。

本発明の好適な実施例は、再定義されたモード値をもつモード変更拒絶メッセージを圧縮器から伸張器に送信することにより、明示的な拒絶シグナリングを達成し、意図的に所定の期間、その要求を無視することにより、暗示的な拒絶シグナリングを達成する。明示的な拒絶シグナリングと暗示的なシグナリングとが結合された実施例があっても良い。

従って、本発明に従うメッセージング方法により、ヘッダ圧縮器は、伸張器からの要求を安全に無視できるか、或いはモード変更要求を明示的に拒絶するシグナリングを行うことができる。これにより、圧縮器は、伸張器には知られていな何かを含む異なる因子を考慮するのを好むなら、特定のモードへの移行を不能にさせることができる。また、ヘッダ圧縮についての動作モード全てのサブセットだけをサポートする圧縮器の実現をも可能にしている。特に、ＲＯＨＣ仕様と整合性のある有利なＵ／Ｏモードだけの実施形が提供される。

本発明を他の側面から見ると、通信システムとヘッダ圧縮ユニットが提供される。

本発明に従うヘッダ圧縮は次の利点を提供する。即ち、
−ヘッダ圧縮効率の改善
−利用可能なバンド幅の効率的利用
−実施形スペース(footprint)の削減
−メモリ要求の削減
−実施、実証、及び試験のための機能の削減
−実現のための時間と費用面での改善
−ＲＯＨＣ製品のより容易な展開
−モードを特定した実施形（例えば、Ｕ／Ｏ）の広範囲な実現である。

本発明とさらなる目的やその利点は、以下の説明と添付図面を参照することより最良の理解が得られる。

図１は、本発明が用いられる代表的な汎欧州デジタル移動電話方式／汎用パケット無線サービス（ＧＳＭ／ＧＰＲＳ）通信ネットワークを図示したブロック図である。移動体電話、ラップトップ、及び無線中継器のような数多くの移動局／端末１０を含み、無線リンク１１によって基地局サブシステム（ＢＳＳ）と通信する無線ネットワークが示されている。ＢＳＳは典型的には、非常に数多くの基地無線局（ＢＴＳ）１２と基地局制御局（ＢＳＣ）１３とを含んでいる。各ＢＴＳは各カバレッジ領域内の移動体端末に対してサービスを行い、いくつかのＢＴＳはＢＳＣにより制御され、そのＢＳＣはコアネットワークに対するアクセスを提供している。そのコアネットワークは移動体交換センタ（ＭＳＣ）１４とゲートウェイ移動体交換センタ（ＧＭＳＣ）１５とを有している。ＧＳＭのトラフィックはＭＳＣ１４を介してルーティングされる。そのＭＳＣは、移動体端末１０の現在位置を担当する在圏ロケーションレジスタ（ＶＬＲ）と関係している。外部ネットワークに対する或いは外部ネットワークからの通信はＧＭＳＣ１５により扱われる。パケット交換サブネットワークに戻ると、それは、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１６とゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１７とを有している。ＧＧＳＮは外部パケットデータネットワークに対するインタフェースとして作用し、一方、ＳＧＳＮはそのサービス領域内の端末に対する或いは端末からのパケット配信を担当する。

実際のところ、たいていのネットワークは、図１の基本的な例よりもはるかに複雑な方法で構成された多数のネットワークノードを有している。さらにその上、図１は、本発明が用いられる通信システムの１つのタイプの例である。本発明は、例えば、ｃｄｍａ２０００無線パケットデータ通信ネットワークやＷＬＡＮのような無線ＩＰのための他の無線技術を含む他のパケットデータ通信ネットワークでも適用可能である。

ヘッダ圧縮は通常、図示された通信ネットワークにおいて１つ以上のリンクの要求されるバンド幅を小さくし、それにより、その送信効率と速度とを改善するために用いられる。特に、無線通信ではしばしば、そのようなバンド幅の縮小を必要とするが、ヘッダ圧縮は、静的な／有線のリンクを含む他のリンクでも同様に有用である。一般に、ヘッダ圧縮が適用されるリンクの各終端には圧縮器と伸張器の両方がある。無線システムでは、リンク１１の終端については、しばしば、移動局１０に位置するが、例えば、中継器として用いられる送信機と受信機の各側に位置していても良い。リンク１１のネットワーク側では圧縮器と伸張器とは、次のノードの内の１つ以上のもの、即ち、ＧＰＲＳを基本としたパケットデータシステムではＳＧＳＮ１６或いはＧＧＳＮ１７、ｃｄｍａ２０００パケットデータシステムではパケットデータサービングノード（ＰＤＳＮ）（不図示）、或いは基地局１２や無線アクセスネットワークの別のノードに構成される。

図２には、ヘッダ圧縮の一般的な原理が図示されている。ヘッダ圧縮ユニット２０とヘッダ伸張ユニット２２とが示されている。これらのユニット２０、２２はリンクによりフォワードチャネル（圧縮器から伸張器へ）とオプションのフィードバックチャネルとで通信を行う。実際のデータ／ペイロードの他に、ヘッダ圧縮ユニットに入力される各ＩＰパケットは、発信元アドレスと宛先アドレスとをもつヘッダ部（図２では斜線が施されたフィールドにより表現されている）と、エラーチェックと、ポートと、プロトコルフィールドなどから構成される。そのヘッダ部はしばしば、データよりもパケットの大きな部分を構成する。完全なパケットを転送することは従って、大きなバンド幅を必要とし、それ故に、そのパケットは、バンド幅の制限されたリンク（図１の１１）により転送される前にヘッダ圧縮ユニット２０において冗長なヘッダ情報を除去することにより圧縮される。ヘッダ伸張ユニット２２はそのパケットを実質的に元々の入力パケットと同一の伸張されたパケットへと再構成する。

ヘッダ圧縮は基本的には、同じストリームに属するパケットの多くのヘッダフィールドが一定であり、ほとんど変化せず、完全なヘッダフィールドはそれ故に、時々だけ送信されねばならないものであるという認識に依存している。ヘッダ圧縮の詳細や規則は、いくつものヘッダ圧縮プロトコルで提供されている。この開示では、代表的な例示のために、主としてＲＯＨＣに焦点を合わせるが、本発明がたとえＲＯＨＣ、そして、特に、ＲＯＨＣ ＲＴＰ、ＵＤＰ、及びＥＳＰプロファイル（ＲＦＣ３０９５、非特許文献４）、ＲＯＨＣ ＵＤＰ系プロファイル（非特許文献５）、ＲＯＨＣ ＩＰのみのプロファイル（非特許文献６）、ＬＬＡプロファイル（ＲＦＣ３２４２、非特許文献７）、またＬＬＡプロファイルへのＲ−モードの拡張（非特許文献８）に関連して非常に有用であったとしても、それによって本発明が決してそこに限定されるものではない。他の現在の或いは将来のヘッダ圧縮方式、ＲＯＨＣであろうとなかろうと、それらもまた本発明の範囲内にある。

背景技術の項で示したように、ロバストヘッダ圧縮（ＲＦＣ３０９５）についての仕様は、“全てのＲＯＨＣの実施形は３つの動作モード全てを実施してサポートしなければならない”と述べている。そのモード移行は次のように実行される。

ＵモードからＯモードへ
フィードバックチャネルが利用可能であるなら、伸張器は、Ｏ−モードへのモード変更要求を搬送するフィードバックパケットを送信することにより、Ｕ−モードからＯ−モードへのモード移行を開始することを決定して良い。その伸張器は、Ｕ−モードとＯ−モードの両方で用いられるパケットタイプは同じなので、既にＯ−モードに移行することが許可される。圧縮器はその要求が受信されるとすぐに、Ｏ−モードに移行する。

ＯモードからＲモードへ
伸張器は、圧縮器への要求を送信することにより、Ｏ−モードからＲ−モードへのモード移行を開始して良い。その移行が一旦開始されたなら、その圧縮器は、Ｕ／Ｏ−モードとＲ−モードとの間での解釈が異なることがなければ、通常は最も効率的なパケットフォーマットである共通の識別子を用いて如何なるパケットタイプも用いることは許されない。伸張器がそのモード変更に関して圧縮器からの確認を受信するまでは、その伸張器は圧縮器から受信した各パケットについてこのモード要求を送信し続ける。圧縮器は、移行中には許された特定のパケットタイプの“モード”フィールドを用い、それを要求されたモードに設定して変更を確認する。２ビットのモードフィールドのセマンティックスは次のように定義される。即ち、
圧縮モード ０＝予約
１＝単方向（Ｕ−モード）
２＝双方向オプティミスティック（Ｏ−モード）
３＝双方向リライアブル（Ｒ−モード）
である。

Ｕ−モードからＲ−モードへ
Ｏ−モードからＲ−モードへの場合と同じ手順である。

Ｒ−モードからＯ−モードへ
Ｏ−モードからＲ−モードへの場合と同じ手順である。

Ｕ−モードへ戻る移行もまた常に可能である。

ＲＯＨＣ（ＲＦＣ３０９５）に従えば、その圧縮処理はＵ−モードで開始しなければならない。Ｕ−モードとＯ−モードとは実際には互いに非常に類似しており、それ故に、両者は即座にサポートされる、Ｒ−モードはかなり２つの他のモードとは異なっているので、多くの場合において、Ｒ−モードを離れて、Ｕ／Ｏ−モードのみの実施形を用いるのは便利である。

Ｕ／Ｏ−モードのみの実施形のような、実施するのにより少ない機能しか備えない最適化されたヘッダ圧縮器を可能にする、ＲＯＨＣの柔軟なモードの実施が非常に都合が良いことは明白である。伸張器により要求されたときであっても、多くの圧縮器はしばしば、他のモード、例えば、Ｒ−モードに移行しないことを好む。例えば、Ｒ−モードのような特定のモードに対するサポートを実施することを避け、依然として、ＲＯＨＣ仕様に安全に準拠することも望ましい。

しかしながら、ＲＯＨＣはＵ／Ｏ−モードのみの実施形などを創りだす可能性を許してはいない。非特許文献４により、モード移行を要求するのは伸張器のみである。このことは次に、全ての定義されたモードを常にサポートするために圧縮器の実施形に対して要求を向けることになる。圧縮器は従って、異なるソースからの伸張器の実施形は単に、圧縮器が最適化されたものに対するのとは異なるモードを好むかもしれないという理由のためにさほど最適とは言えない動作を強いられるかもしれない。

本発明は、ただサブセットのみをサポートするのが必要されるか、或いは望ましいときでさえも、常に絶対に全ての動作モードをサポートするために圧縮器の実施形に向けられたＲＯＨＣアルゴリズムにより持ち出された制限を取り除く解決策を提供することを目的としている。

第１の考えは、伸張器からのモード変更要求を単に無視するというものである。しかしながら、Ｕ−モード或いはＯ−モードからＲ−モードへのモード移行に関し、現在のＲＨＯＣ仕様では、“Ｄ＿ＴＲＡＮＳがＩである間、伸張器は各受信パケットのためにＣＲＣオプションを搬送するＮＡＣＫ或いはＡＣＫを送信する”と読める。言い換えると、伸張器がモード要求を送信したとき、その伸張器は、圧縮器からのモード変更確認を受信するまで、各受信パケットに対してその要求を再送する。さらにその上、“伸張器がＵＯＲ−２、ＩＲ−ＤＹＮ、或いはＲに設定されたモード変更パラメータをもつＩＲパケットを受信しない限り、オプティミスティック（Optimistic）モードに留まらねばならない”とも記載されている。このことは、伸張器が、圧縮器からのモード変更確認を受信する前に、モードを（例えば、Ｒ−モードに）変更することは許されてはいないことを意味する。その結果、伸張は、圧縮器が実際にモード移行を実行してその要求を確認するまで、安全に継続できる。

ＲＯＨＣ伸張器は、モード変更の確認が圧縮器から受信されるまで、Ｕ／Ｏモードに留まらねばならないので、伸張器からのＲ−モードへのモード変更要求を無視する圧縮器の実施形は、伸張器が続けてロバスト伸張を実行することを停止しないであろう。それにもかかわらず、伸張器による要求再送のためにフィードバックチャネルでの増加を生み出すことになり、バンド幅の最適とは言えない使用がなされることになる。伸張器の実施形に依存して、この挙動は持続的であるかもしれないし、間歇的であるかもしれないし、一時的であるかもしれない。従って、伸張器からのＲ−モードへのモード変更要求を単に無視することは、あまり制御できない方法で、不定の時間にわたりフィードバックチャネルによるトラフィック量の増加を生み出すという問題を招くことになる。

その代わり、本発明は、圧縮器が伸張器に対してモード変更要求が拒絶されていることを示唆できるメッセージング手順を提案している。この示唆された拒絶に応答して、伸張器は、圧縮器がモード移行を拒絶する正当な理由をもっていることを理解するなら、開始された移行を中断できるかもしれない。例えば、そのような理由は、圧縮器がリンク状態についてより良い知識をもっていることと、圧縮器が現在のモード動作に最適化されていることと、その要求モードが利用可能ではないこととの内、少なくともいずれかで良い。

提案された方法に従えば、望まれないモード変更に対する要求を受信した圧縮器は、従って、モード変更要求の拒絶を伸張器に対して、通常は明示的或いは暗示的なシグナリングを介して示唆する。もし、伸張器がその示唆された拒絶に気づくなら、例えば、変更されたシグナリングの挙動と明示的なメッセージとの内、少なくともいずれかを介したその拒絶の確認応答により応答する。そのような拒絶応答確認の動作は、圧縮器による拒絶の成功として解釈され、その圧縮器は現在のモードに留まることになる。

従って、本発明は、圧縮器が伸張器からのモード変更要求を暗示的に或いは明示的に拒絶することを許している。これは、圧縮器が特定のモードへの移行を不能にすることを可能にし、圧縮器が動作モードの全てを実現するという必要をさえ取り除くものである。

本発明の原理を例示するために、その第１と第２の実施例について、図３と図４とを参照して説明する。これらの例は主として、Ｕ或いはＯ−モードからＲ−モードへのモード移行を扱うものであり、モード移行要求を開始するときの上述した圧縮器の挙動に基づいている。しかしながら、（ＲＯＨＣモードと他のヘッダ圧縮の動作モードに関する）他のモード変更要求がある実施例もまた、本発明の範囲の中にある。従って、第１のヘッダ圧縮モードから第２のヘッダ圧縮モードへのモード移行の何らかの要求は、本発明に従って処理できる。例えば、単方向（Ｕ）モード、双方向オプティミスティック（Ｏ）モード）、双方向リライアブル（Ｒ）モード、双方向（Ｂ）モードのグループから選択されたモードからの或いは、そのモードへの要求などである。

明示的な拒絶シグナリング
第１のアプローチに従えば、圧縮器は、モード変更要求が無視／拒絶されるであろうことを伸張器に明示的にシグナリングする。そのとき、伸張器はこの信号を用いて開始した移行を中断し、Ｕ／Ｏモードに留まり、モード変更要求を送信することを停止する。

好適な実施例では、再定義されたビットを用いてモード変更要求の拒絶を明示的に信号発信する。前述のように、そのモード値はＲＯＨＣ（ＲＦＣ３０９５）において次のように定義されている。即ち、
圧縮モード ０＝予約
１＝単方向（Ｕ−モード）
２＝双方向オプティミスティック（Ｏ−モード）
３＝双方向リライアブル（Ｒ−モード）
である。

ＲＯＨＣ（ＲＦＣ３０９５）からのＵＯＲ−２、ＩＲ−ＤＹＮ、或いはＩＲのモード値は、このアプローチに従えば、次のように再定義される。即ち、
圧縮モード ０＝モード変更要求無視／取消
１＝単方向（Ｕ−モード）
２＝双方向オプティミスティック（Ｏ−モード）
３＝双方向リライアブル（Ｒ−モード）
である。

前に予約された（即ち、値“０”をもつ全てのビットが無視されるという意味において特別な意味はない）値“０”は結果として、モード変更要求がヘッダ圧縮ユニットにより拒絶／無視されることを示唆するために用いられる。従って、圧縮器はモード値“０”をもつパケットを、望まれないモード変更要求に応答して伸張器に送信する。伸張器が新しいモード定義に気づくなら、それは、更なる要求送信を中断するなどの適切な動作をとることができる。他の実施形がその信号に気づくためには、ある標準化の努力が求められるかもしれない。

本発明はまた、モード変更要求が無視されることを伸張器に対して明示的に（バンド内(in-band)で或いはバンド外で(out-of-band)）シグナリングするための別の機構を用いた実施形もカバーする。従って、好適なＲＯＨＣモード値の再定義の代わりに、明示的なシグナリングのために他のビット／値が用いられても良く、それには、特別なパケットタイプ、モードビット以外のビットフラグ、パケットフォーマット内でのオプション、拡張内でのオプションなどを含む。

図３は、本発明の代表的な実施例に従う、明示的な拒絶シグナリングを行うヘッダ圧縮方法のフローチャートである。ステップＳ１では、ヘッダ伸張器はモード移行を開始し、新しいモードへの変更要求を、パケット転送リンクによりヘッダ圧縮ユニットに送信する。モード移行が、例えば、Ｒ−モードへの変更を伴うものである場合、その要求の圧縮モードはＭＯＤＥ＝３（Ｒ−モード）にセットされる。それから、伸張器は現在もモードに留まり、圧縮器からの確認を待ち合わせる。その確認までに受信した各パケットに関し、伸張器はフィードバックチャネルによりその要求を再送する。

圧縮器はモード変更要求を受信するが、現在の動作モードに留まることを好む。圧縮器はその伸張器に対して、好ましくは、パケット転送リンクによりモード変更拒絶メッセージを送信することにより（ステップＳ２）、そのモード変更要求の拒絶をシグナリングする。ＲＯＨＣパケットのモード値の上述の再定義を用いる好適な実施例では、圧縮器は１つ以上のＵＯＲ−２、ＩＲ−ＤＹＮ、或いはＩＲパケットを送信し、ＭＯＤＥ＝０（要求取消）をセットする。

さて、伸張器がＭＯＤＥ＝０のパケット或いは他の明示的な信号を受信するとき、モード変更要求の拒絶を理解するかどうかに依存して（ステップＳ３）、この手順は異なる経路をとる。もし、伸張器がその拒絶信号、例えば、新しく定義されたモード値のセマンティックスに気づくなら、ステップＳ４において、フィードバックチャネルによりモード変更要求を送信するのを中止する。そのとき、モード移行は中断され、伸張器は現在の動作モードを継続する。好ましくは、その伸張器はまた、拒絶を確認したことを示唆するメッセージを圧縮器に送信する（ステップＳ５）。そのような拒絶確認応答メッセージは、例えば、ＭＯＤＥパラメータセットをもつＲＯＨＣパケットを、“０”、或いは、伸張器がモード変更要求を開始した時点でアクティブであるモード値に、即ち、圧縮器が保持することを望む（“最初の”／“現在の”）モードに戻すことを含んでいる。

好ましくは、圧縮器は、伸張器のシグナリングの挙動を解釈することで拒絶が成功したかどうかを決定する。一般に、そのことには、拒絶が伸張器により理解され確認されたというある種の示唆を探索してパケット転送リンクを監視することを含む。この示唆は上述した拒絶確認応答メッセージで良い。或いは、モード変更要求の拒絶が成功したことの示唆は、圧縮器が、信号が伸張器に達したことを強く確信するフィードバックチャネルによる新しいモードでのモード変更要求を受信することを停止したことから成り立っていても良い。十分な確実性は通常、少なくとも１リンク往復時間（ＲＴＴ）を必要とし、通常は１〜２ＲＴＴの範囲である。拒絶の成功に応答して、圧縮器は現在のモードの使用を継続する（ステップＳ６）。

これに対して、伸張器が拒絶のシグナリング、例えば、再定義したモード値を理解しないなら、要求を無視して現在の動作モードに留まる。伸張は通常継続され、非特許文献４に従って、伸張器は圧縮器からの確認を待ち合わせる。この場合、拒絶の信号は伸張器に達したことが確実ではあるが、圧縮器は依然としてフィードバックチャネルにより新しいモードへのモード変更要求を受信する。圧縮器は拒絶のシグナリングが成功ではなかったと結論し、ステップＳ７ではその要求を重視するべきかどうかを尋ねる。もし、重視されるべきであるなら、圧縮器は圧縮モードを変更し、好ましくは新しいモード値をもつパケットのような確認を伸張器に対して返却する（ステップＳ８）。伸張器はその結果、モードを変更し、更なる再送要求を中断する（ステップＳ９）。或いは、その要求が拒絶が不成功にも係らず重視されない。その代わり、圧縮器は好ましくは、図４を参照して後で説明する暗示的なシグナリングへとフォールバックする。

ステップＳ７での判断は、一般的な実施形特有の特徴により決定されるか、或いは、個々の特定の状況の解釈に基づいて決定される。例えば、もし、実施形が要求されたモードをサポートしていないなら、そのモードを重視するオプションはなく、その結果、このモードに対する全ての要求は無視される。しかしながら、圧縮器は、圧縮器側では現在のところ処理資源が少ししかないとか、リンク特性をより良く理解しているなどのような理由のために、その場合場合により移行を拒絶することもあるかもしれない。

図３により例示されたアプローチは、モード変更要求が重視されないという信号を伸張器に発信する圧縮器にとって最も効率的な方法であるという利点があり、そのような信号を解釈できる伸張器は適切な動作を行うであろう。そのような伸張器は現在のモードに留まり、モード変更要求を再送することによりフィードバックチャネルでのトラフィックを増加させることはない。

別の利点は、本発明のこの実施例に従う方法が、全てのモードをサポートするがＵ／Ｏモードを好む圧縮器が提案された再定義を認知できない伸張器の実施形とともに用いられたとき、相互動作可能な状態に留まり、標準に従う形に留まることができる点にある。この再定義を理解しない伸張器は、ＲＯＨＣ仕様によれば、この値を単に無視するだけであろう。そのとき、圧縮器は以下に示す暗示的なシグナリングに助けを求め、モード変更要求を重視できるかもしれない。

暗示的な拒絶シグナリング
別のアプローチは、圧縮器がモード変更要求の拒絶を暗示的に示唆することである。好適な実施例では、暗示的なシグナリングは、限定された時間だけ、伸張器からのモード変更要求を意図的に無視し、現在のモードに留まることにより達成される。言い換えると、伸張器に対してその拒絶を示唆するために、制御された方法でその要求を安全に無視することが提案されている。もし、フィードバックチャネルによって送信されるモード変更要求が終了するか、或いは一定の時間以後に間歇的になるなら、圧縮器は、性能低下を生じることなく、例えば、Ｕ／Ｏ−モードのような現在のモードに留まることができる。さもなければ、即ち、フィードバックチャネルでのトラフィックが持続的なものであるなら、圧縮器はモード変更を実行し、モード変更要求を重視する決定を行うかもしれない。

圧縮器がモード変更要求を無視し、伸張器からの可能性のある反応を待ち合わせる時間の長さは通常は、１〜２ＲＴＴのオーダである。これは、伸張器は一般に、要求送信後、約１ＲＴＴ（最短）で、圧縮器からの“回答”を受信することを期待できるためである。より長い時間を要することもあるし、あるリンクのＲＴＴは時間とともに変化することもある。しかしながら、たいていの場合、暗示的な拒絶シグナリングのための所定時間は、１〜２ＲＴＴの範囲で表現できる。

図４は、本発明の代表的な実施例に従う、暗示的な拒絶を行うヘッダ圧縮方法のフローチャートである。前に述べたように、ヘッダ伸張器はモード移行を開始し、変更要求をヘッダ圧縮ユニットに送信する（ステップＳ１０）。伸張器は現在のモードに留まり、圧縮器からの確認を待ち合わせる。その確認までに受信した各パケットに関し、伸張器はフィードバックチャネルによりその要求を再送する。

圧縮器はモード変更要求を受信するが、現在の動作モードに留まることを好む。それ故に、圧縮器は、この場合には暗示的な拒絶シグナリングにより、モード変更の拒絶を示唆する。好ましくは、ここでは、その要求を無視し、現在のモードを続行するが、同時にタイマがスタートし、フィードバックチャネルを監視する（ステップＳ１１）。そのタイマは、伸張器がモード変更要求に対する応答がないのに気づいたと圧縮器が強く確信できる値、例えば、１〜２ＲＴＴの範囲にセットされる。このタイマの代わりに、例えば、シーケンス番号に基づいた代替機構が用いられて制御された暗示的な拒絶を達成しても良い。

それ以後、伸張器がモード変更要求の暗示的な拒絶に気づくかどうかに依存して（ステップＳ１２）、この手順は異なる経路をとる。もし、伸張器が、その要求が圧縮器に達し、従って、モード変更が実行されたことを強く確信するが、依然として圧縮器からの応答待ち／応答がないことに気づくなら、拒絶されたとして解釈し、ステップＳ１３では、フィードバックチャネルによるモード変更要求の再送を停止する。或いは、伸張器は、モード変更要求の送信頻度を低くする。そのモード移行は中断され、伸張器は現在の動作モードに留まる。

圧縮器に関し、それは再び、その拒絶が成功したかどうかを判断する。好ましくは、その拒絶結果の解釈は、リンク監視と、伸張器のシグナリングの挙動の解釈とを含んでいる。もし、圧縮器がタイマの切れる前に、フィードバックチャネルによるモード変更要求送信の頻度が少なくなったことや或いはその送信がなくなったことに気づくなら、その拒絶は成功であり、圧縮器は現在のモードに留まる（ステップＳ１４）。

これに対して、伸張器が拒絶に気づかないなら、圧縮器によりセットされたタイマは、フィードバックチャネルによるモード変更要求の再送についての何の変化もないまま時間切れとなる。圧縮器はこの挙動を拒絶の不成功と解釈し、手順はステップＳ１５へと続く。ステップＳ１５では、モード変更要求が重視されるべきかどうかを調べる。もし、そのようにされる場合であるなら、圧縮器は圧縮器のモードを変更して、通常は新しいモード値をもつパケットのような確認を伸張器に対して返却する（ステップＳ１６）。伸張器はその結果、モードを変更し、更なる再送要求を中断する（ステップＳ１７）。さもなければ、圧縮器はその要求を無視し続け、現在のモードに留まる（ステップＳ１８）。ステップＳ１５の結果は、図３のステップＳ７のそれに類似の考慮に基づいている。ステップＳ１８は通常、好適なオプションではないが、圧縮器が伸張器が要求しているモードを実現していない場合には有用であるかもしれない。

このアプローチは相互動作可能であり、標準に従っているという利点がある。標準の如何なる変更も要求するものではない。図４に例示の方法はまた、明示的な信号がモード変更要求を拒絶するのに用いられ、伸張器が圧縮器により送信された信号のセマンティックスを理解していないときのフォールバック機構として用いられても良い。しかしながら、これは、制御された方法であり、制限された時間ではあるが、フィードバックチャネルによりトラフィック量の増加を生み出すものとなる。

図３と図４とにより夫々例示された実施例は夫々、利点と関係があり、最適な方法の選択は、互いに対する相互動作性や性能のような因子を重み付けすることに関係している。各シグナリング方式は別々に用いられても良いし、もし明示的なシグナリング（図３）が拒絶の成功という結果にならないなら、付加的なフォールバック機構として、例えば、暗示的なシグナリング（図４）との組み合わせて用いられても良い。

要約すれば、本発明により、ヘッダ圧縮器はヘッダ伸張器からのモード変更要求を拒絶し、伸張器には知られていない因子を含む異なる因子を考慮してもし適切と思われるなら現在の動作モードを用い続けることが可能になる。また、ヘッダ圧縮に関する全ての動作モードのサブセットだけをサポートする圧縮器の実現を可能にする。特に、本発明により、依然として完全にＲＯＨＣ仕様（非特許文献４）に準拠しながらも、Ｕ／Ｏモードだけを効率的に実施する形態を創りだすことが可能である。

本発明は、モード移行に関して伸張器に向けられた圧縮器依存性を取り除いている。その結果、ヘッダ圧縮効率が改善し、また、メモリ要求、実施のための時間や費用を削減できる。特に、明示的なシグナリングという手法により、利用可能なバンド幅のより効率的な利用が達成され、これに受信器やアプリケーションの挙動や動作に悪い影響を与えることはない。さらにその上、本発明により、Ｕ−、Ｏ−モードを用いるだけの実施形のような、ＲＯＨＣの複雑さの少ない、効率化された実施形が可能となる。

本発明を具体的に例示した実施例を参照して説明したが、本発明は、開示された特徴の同等物や当業者には明白な変形例や変更をもカバーするものであることを強調しておきたい。例えば、たとえ本発明はＲＯＨＣ（ＲＦＣ３０９５（非特許文献４））について代表例をあげているとしても、説明した例以外の動作モードに関連した方式を含む他のヘッダ圧縮方式にも適用できる。本発明の範囲は添付した請求の範囲によってのみ限定されるものである。

本発明が用いられる代表的な通信ネットワークを図示したブロック図である。 本発明が用いられるヘッダ圧縮機構を図示している。 本発明の代表的な第１の実施例に従うヘッダ圧縮方法のフローチャートである。 本発明の代表的な第２の実施例に従うヘッダ圧縮方法のフローチャートである。

Claims (32)

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. 単一方向（Ｕ）モードと、双方向オプティミスティック（Ｏ）モードと、双方向リライアブル（Ｒ）モードと、双方向（Ｂ）モードと、それらの組み合わせとのグループから選択される前記第１及び第２の圧縮モードを備えたロバストヘッダ圧縮（ＲＯＨＣ）方式に従って実現されることを特徴とする請求項２６乃至３１のいずれかに記載のヘッダ圧縮ユニット。
    

Images