JP5089584B2 - 動的で耐性のあるヘッダ圧縮 - Google Patents

動的で耐性のあるヘッダ圧縮 Download PDF

Info

Publication number
JP5089584B2
JP5089584B2 JP2008518092A JP2008518092A JP5089584B2 JP 5089584 B2 JP5089584 B2 JP 5089584B2 JP 2008518092 A JP2008518092 A JP 2008518092A JP 2008518092 A JP2008518092 A JP 2008518092A JP 5089584 B2 JP5089584 B2 JP 5089584B2
Authority
JP
Japan
Prior art keywords
packet
link
header
compression
bits
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2008518092A
Other languages
English (en)
Other versions
JP2008547308A (ja
JP2008547308A5 (ja
Inventor
イヒュスライン ペレティエル，
ラーシュ−エリク ジョンソン，
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン（パブル） filed Critical テレフオンアクチーボラゲット エル エム エリクソン（パブル）
Publication of JP2008547308A publication Critical patent/JP2008547308A/ja
Publication of JP2008547308A5 publication Critical patent/JP2008547308A5/ja
Application granted granted Critical
Publication of JP5089584B2 publication Critical patent/JP5089584B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/187—Details of sliding window management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Description

本発明は一般に通信、特にメディアパケットなどのパケットヘッダの圧縮に関する。ここで説明する技術は、極く一般的にはヘッダ圧縮に適用可能であり、ＲＯＨＣアルゴリズムや符号化方法への現在のメカニズムに制約されることなく、むしろ再配列が存在するとして、基礎をなすリンクの実際の特性に基づいて圧縮をより良く調整するための新しいメカニズムを提案するものである。
背景技術には、“圧縮データの可変長符号化（Variable-length encoding of compressed data）”と題する特許文献１が含まれる。一方、特許文献１は連続的に増加するフィールドの符号化に適用され、これらフィールドのための損失に対する耐性を提供している。
他の関連文献には非特許文献１が含まれ、これはＲＯＨＣへの新規要求のためのＩＥＴＦ ＲＯＨＣ作業部会の提案である。カプーア（Kapoor）は、連続的に増加するフィールドをＬＳＢ符号化する場合の再配列に対する耐性の改善法に関する示唆が提案されていることを示しているが、問題の取り上げ方が異なる。
インターネットの大いなる成功により、あらゆる種類のリンクを経るインターネットプロトコル（ＩＰ）の使用が挑戦する業務となった。一方、ＩＰプロトコルのヘッダがどちらかといえば大きいため、例えば、セルラリンクなどの狭帯域リンクにとり、これを現実にするのは必ずしも簡単ではない。一例として、ボイスオーバＩＰ（ＶｏＩＰ）に使用するプロトコル（ＩＰ、ＵＤＰ、ＲＴＰ）により伝送する通常の通話データを考察すると、この場合、ヘッダはパケットの約７０％を表し、その結果、リンクを非常に非能率的に使用されることになる。
用語“ヘッダ圧縮（ＨＣ）”はポイント・ツー・ポイント・リンクを経るホップ当りを基本とするヘッダにおいて搬送する情報に必要な帯域幅を最小にする技術を包含する。一般に、ヘッダ圧縮技術にはインターネットコミュニティにおいて１０年を超える歴史がある。次の幾つかの一般的に使用するヘッダ圧縮プロトコルが存在し、これら全ては参照によりその全てが本願組み込まれる。即ち、非特許文献２、非特許文献３、非特許文献４である。
ヘッダ圧縮は、ヘッダの幾つかのフィールドがフロー内において変化しないか、小さな値と予測可能な値との内の少なくともいずれかにより変化することを利用する。ヘッダ圧縮方式はこれらの特徴を使用し、最初にのみ静的情報を送信し、一方変化するフィールドはパケット毎にその絶対値と共にまたは差分として送信する。完全にランダムな情報は全くなんら圧縮することなく送信しなければならない。
ヘッダ圧縮は従って、無線を経る音声やビデオサービスなどのＩＰサービスを経済的に実施可能にする重要な構成要素である。ヘッダ圧縮の解決策は、このようなサービスの効率を改善するためにインターネット技術実行委員会（ＩＥＴＦ）の耐性のあるヘッダ圧縮（ＲＯＨＣ）作業部会により開発された。
ＲＦＣ３０９５（“［ＲＯＨＣ］”、即ち、ボールマン、Ｃ（Bormann C.）「耐性のあるヘッダ圧縮（ＲＯＨＣ）：フレームワークと４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰ、及び非圧縮」、ＲＦＣ３０９５、インターネット技術実行委員会、２００１年７月）に定義されるように、耐性のあるヘッダ圧縮（ＲＯＨＣ）は、種々のプロトコルの圧縮のためのプロファイルを定義される拡張可能な枠組みである。実時間マルチメディアサービス（例えば、音声、ビデオ）のために、アプリケーションデータをＩＰ／ＵＤＰ／ＲＴＰのストリームの中でエンド・ツー・エンドに伝送する。ＩＰ／ＵＤＰ／ＲＴＰのヘッダ圧縮は、ＲＯＨＣプロファイル０ｘ０００１（ＲＯＨＣ ＲＴＰ）により定義され、中でもボイスオーバＩＰ（ＶｏＩＰ）に適用可能である。ＲＯＨＣ ＲＴＰヘッダ圧縮方式は任意のリンクレイヤを経るＩＰ／ＵＤＰ／ＲＴＰのヘッダを能率的に圧縮するために設計されたものである。
圧縮のために幾つかの他のＲＯＨＣプロファイルも定義されている。これらの中には次のものがある。即ち、（１）ＩＰ／ＵＤＰ／ＲＴＰヘッダ（ジョンソン、Ｌ（Jonsson L.）及びＧ．ペレッティア（G.Pelletier）著、“耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)：ＩＰ／ＵＤＰ／ＲＴＰのためのリンクレイヤ支援ＲＯＨＣプロファイル（A Link-Layer Assisted ROHC Profile for IP/UDP/RTP）”、ＩＥＴＦ ＲＦＣ３２４２、２００２年４月、及び、リウ、Ｚ（Liu Z）及びＫ．リー（K. Le）著、“拡張リンクレイヤにより支援する耐性のあるヘッダ圧縮（ＲＯＨＣ）プロファイルにおける双方向性の信頼性のあるモード（Ｒ−モード）のためのゼロ・バイト・サポート（Zero-byte Support for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust Header Compression (ROHC) Profile）”、ＩＥＴＦ ＲＦＣ３４０８、２００２年１２月に記載）、（２）ＩＰのみのヘッダ（ジョンソン、Ｌ（Jonsson L.）及びＧ．ペレッティア（G.Pelletier）著、「耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)：ＩＰのための圧縮プロファイル（A compression profile for IP）」、ＩＥＴＦ ＲＦＣ３８４３、２００４年６月に記載）、（３）ＩＰ／ＴＣＰヘッダ（ペレッティア、Ｇ（Pelletier G.）、ジョンソン、Ｌ（Jonsson L.）他著、「耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)）：ＴＣＰ／ＩＰのためのプロファイル（ＲＯＨＣ−ＴＣＰ）（A Profile for TCP/IP (ROHC-TCP)」、インターネット草案（作業進行中）＜draft-ietf-rohc-l1.txt＞２００６年１月４日に記載）、（４）ＩＰ／ＵＤＰ‐Ｌｉｔｅ／ＲＴＰヘッダ（ペレッティア、Ｇ（Pelletier G.）著、「耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)）：ＵＤＰ−Ｌｉｔｅのためのプロファイル（Profiles for UDP-Lite）」、ＩＥＴＦ ＲＦＣ４０１９、２００５年３月に記載）。ここで引用された全てのＲＦＣは参照によりその全てが本願に組み込まれる。
ネゴシエーション（ボールマン、Ｃ（Bormann C.）著「ＰＰＰを経る耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC) over PPP）」、ＩＥＴＦ ＲＦＣ３２４１、２００２年４月も参照）を除いて、ＲＯＨＣプロファイルはリンクレイヤにより提供するフレーム化と誤り検出のみを必要とするが、他の機能は全て、ＲＯＨＣ方式それ自体により扱われる。
ヘッダ圧縮方式（ＲＯＨＣプロファイルなどの）を状態マシンとして概念化したり、実現したりすることの内、少なくともいずれかを行うことができる。挑戦する業務は、コンテキストと呼ばれる圧縮器と伸張器の状態を互に矛盾なく維持する一方、ヘッダオーバヘッドを可能な限り低く維持することである。圧縮器に１つの状態マシンが存在し、伸張器に１つの状態マシンが存在する。圧縮器の状態マシンは送信する圧縮パケットのタイプの選択を制御する重要な論理部であるので、圧縮器の状態マシンは圧縮能率のレベルに直接影響を与える。伸張器の状態マシンの目的は主として、（適用可能であれば）フィードバックのための論理を提供し、伸張を試みることができるパケットタイプを特定することである。
圧縮コンテキストは過去のパケットに関して関係のある情報を含み、かつ維持し、この情報を使用して、後続パケットを圧縮し、伸張する。ＲＯＨＣの文献において説明されるように、圧縮器のコンテキストは圧縮器がヘッダを圧縮するために使用する状態である。伸張器のコンテキストは伸張器がヘッダを伸張するために使用する状態である。どちらを意味するかが明確な場合、これらのいずれか、または２つを組み合わせて通常、“コンテキスト”と呼ぶ。コンテキストは、静的フィールドなどのパケットストリームにおける以前のヘッダに関係する情報と、圧縮と伸張のための可能な参照値とを含む。さらに、パケットストリームを記述する追加情報はコンテキストの一部であり、例えば、ＩＰ識別子フィールドがどのように変化するのかに関する情報や、シーケンス番号或いは時間スタンプのパケット間における典型的な増加などである。
伸張器が伸張の成功を検証する手段を提供するパケットはコンテキスト更新パケットである。伸張を検証されるので、このタイプのパケットはコンテキストを更新することができる。ＲＯＨＣのために、コンテキスト更新パケットのタイプはそのフォーマット内に循環冗長符号（ＣＲＣ）を有する。これは元の非圧縮ヘッダに対して計算するチェックサムである。このＣＲＣを使用して、各パケットの伸張の成功を検証する。その伸張が成功すると、コンテキストを更新することができる。
伸張の成功を保証するために他の手段に頼るパケット、即ち、パケットフォーマットは伸張器が伸張の成功を検証する手段を提供せず、ただ伸張自体に必要な情報を搬送するパケットは自己完結型パケットである。これらのパケットはコンテキストを更新しない。
ＲＦＣ３０９５、ＲＦＣ３２４２、ＲＦＣ３４０８において定義されるＲＯＨＣプロファイル、“ＩＰのみ（IP-ONLY）”（ジョンソン、Ｌ（Jonsson L.）及びＧ．ペレッティア（G. Pelletier）著、“耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)）：ＩＰのための圧縮プロファイル（A compression profile for IP）”）、ＩＥＴＦ ＲＦＣ３８４３、２００４年６月と、“ＲＯＨＣ−ＵＤＰ−Ｌｉｔｅ”（ペレッティア、Ｇ（Pelletier G.）著、“耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)：ＵＤＰ−Ｌｉｔｅのためのプロファイル（Profiles for UDP-Lite）”、インターネット草案（作業進行中）、ＲＦＣ４０１９、２００５年４月”とは全て、３つの異なる動作モードをサポートする。要するに、特定のコンテキストに対して、動作モードは、実行するための動作及び論理と共に、ヘッダ圧縮操作の異なる状態の間に使用するパケットタイプを制御する。許されているパケットタイプとフォーマットはあるモードから別のモードへと変化するかもしれない。他モードへの遷移が生じうる前に、ＲＯＨＣ圧縮の始めに、単方向モード（Ｕ−ｍｏｄｅ）が用いられる。双方向最適モード（Ｏ−ｍｏｄｅ）は圧縮能率の最大化とフィードバックチャネルの疎な使用を追求する。双方向性の信頼性のあるモード（Ｒ−ｍｏｄｅ）は損失のある伝播やコンテキストに障害を与える伝播に対する耐性を最大化することを追求する。
Ｕモードの場合、パケットを圧縮器から伸張器へのみ送信する。Ｕモードは従ってリンクを経て使用することができ、この場合、伸張器から圧縮器への返送経路は望ましくないか、または利用不可能かのいずれかである。Ｕモードでは、周期的リフレッシュを使用する。Ｕモードは同報やマルチキャストチャネルに特に適用可能である。
ＯモードはＵモードに類似しており、相違はフィードバックチャネルを使用して、伸張器から圧縮器へ誤り回復要求および重要なコンテキスト更新の（オプション的に）確認応答を送信することである。
なお、大部分のＲＯＨＣプロファイルの場合、ＵモードおよびＯモードは用語“Ｕ／Ｏモード”を用いて暗に言及されることが多い。これは、ＵモードとＯモードがコンテキスト更新を行うのに両モードに対する同じパケットフォーマットセットと共に類似論理などのようなどちらかと言えば類似する特性を有するからである。この論理は最適手法と呼ばれ、Ｕ／Ｏモードにおけるコンテキスト更新手順のためのパケット損失に対する耐性を提供する。さらなる詳細については、ＲＦＣ３０９５［ＲＯＨＣ］、５．３．１．１．１節も参照されたい。
Ｒモードは他の２つのモードとかなり相違する。特に、Ｒモードはこのモードにおいてのみ理解され、有用な幾つかの異なるパケットタイプを使用する。しかしながら、Ｒモードは主としてフィードバックチャネルをより拡張的に使用することにより異なり、コンテキスト更新の実行に対してより厳格な論理を使用する。この論理は安全な参照原理に基づき、Ｒモードにおけるコンテキスト更新手順のためのパケット損失に対する耐性を提供する。さらなる詳細については、ＲＦＣ３０９５［ＲＯＨＣ］、５．５．１．２節も参照されたい。
ＲＦＣ３０９５［ＲＯＨＣ］において定義されるヘッダ圧縮プロファイルは、圧縮器と伸張器との間のチャネルがヘッダ圧縮パケットを再配列することはないであろし、そのチャネルは各圧縮フローに対するパケットの順序化を維持する必要があるという仮定で設計されている。この仮定の動機となったのは、ＲＯＨＣを使用する可能性のある候補と最初に考えられたチャネルがパケットの順序に従う配信を保証したからである。この仮定は圧縮能率とパケット損失に対する許容度を改善するのに有用であり、当時の要求リストにおいて最高にランク付けされた目的であった。ＩＰヘッダのみの圧縮プロファイル［ＩＰ−ＯＮＬＹ］とＵＤＰ−Ｌｉｔｅのためのプロファイルは実質的に、ＲＦＣ３０９５［ＲＯＨＣ］に見い出されるプロファイルの拡張である。それ故、これらのプロファイルはまた順序に沿う配信という同じ仮定を継承する。
ヘッダ圧縮器は、コンテキストの更新を実行する場合にヘッダオーバヘッドを削減する“最適手法”を使用することができる。圧縮器は通常、伸張器が情報の受信に成功したことをかなり確信するまで、同じ更新を繰り返す。この確信を得るのに必要な連続パケット数は通常、実装次第であり、この数は通常、ヘッダ圧縮を使用するリンクのパケット損失特性に関係する。最適手法を使用する全てのパケットタイプはコンテキスト更新を行う。
ヘッダ圧縮器は、パケット損失により圧縮器と伸張器との間のコンテキスト同期が失われ得ないことを保証する“安全な参照原理”を使用することができる。この安全な参照原理を使用して、圧縮器は伸張器により受信された確認応答に基づいて、伸張器がコンテキスト更新パケットからコンテキストの更新に成功したことのその確信を得る。しかしながら、安全な参照原理を使用する大部分のパケットタイプは自己完結型であり、従って、テキストを更新することを意図していない。
ＩＥＴＦオーディオ−ビデオ伝送（ＡＶＴ）作業部会（ＷＧ）は、複数ホップを経るヘッダ圧縮に関して作業を行っている。ヘッダ圧縮は主として帯域幅が乏しい低速リンクを取り扱うことを考慮するが、高価格でその中で搬送するかなりのトラフィック量のために、バックボーン設備における帯域幅の節約も重要である。ヘッダ圧縮はバックボーンネットワークにおける各ノード間においてポイント・ツー・ポイントに適用されるが、これにはパケットを伸張し、各ノードで再圧縮することが必要である。複数ホップの経路により、バックボーンネットワークにおける非隣接ノード間において圧縮を実行することにより、処理を少なくすることができる。
例えば、複数ホップ経路はバックボーンネットワークにおけるマルチプロトコルラベル交換（ＭＰＬＳ）ルート、或いは、ＩＰトンネルで良い。より高いパケット損失率と起こりうるパケットの再配列は、複数ホップに亘るそのようなバーチャルリンクの特徴となる。これは、ノードの輻輳または障害によりパケットがノードにおいて再経路指定されるか、または単に廃棄されることから結果から生じうる。アッシュ、Ｊ（Ash J.）、グーデ、Ｂ（Goode B.）、及びハンド、Ｊ（Hand J.）著、“ＭＰＬＳを経るヘッダ圧縮に対する要求条件（Requirements for Header Compression over MPLS）”、インターネット草案（作業進行中）、ＲＦＣ４２４７、２００５年１１月「ＡＶＴ‐ＨＣ」、及び、アッシュ、Ｊ（Ash J.）他著、“ＭＰＬＳを経るヘッダ圧縮のためのプロトコルの拡張（Protocol Extensions For Header Compression over MPLS）”、ＩＥＴＦインターネット草案ＡＶＴ作業部会、＜draft-ietf-avt-hc-over-mpls-protocol-07.txt＞、２００６年５月に、複数ホップを経るヘッダ圧縮に対する要求条件が記載されている。
ＩＥＴＦの耐性のあるヘッダ圧縮（ＲＯＨＣ）作業部会（ＷＧ）は、耐性のあるヘッダ圧縮に関して作業を行っており、圧縮プロファイルが今日のＲＯＨＣプロファイルの優れた耐性特性を維持する一方、再配列を扱うことができるように、近々その圧縮プロファイルを調整するための主要規格をＲＦＣ３０９５更新の目標とする模様である。
最下位ビット（ＬＳＢ）符号化方法として公知の符号化方法を使用してヘッダフィールドを符号化するが、ヘッダフィールドの値は通常、シーケンス番号（ＳＮ）、例えば、ＲＴＰプロトコルシーケンス番号（ＳＮ）或いはそのヘッダフォーマット内にシーケンス番号を付すことのないプロトコルを圧縮する場合に伸張器において創成されるシーケンス番号などの小さな変化に従う。最下位ビット（ＬＳＢ）符号化方法ではフィールド値全体の代わりに、フィールド値の最下位ｋビットを送信する。ここで、ｋは正の整数である。これらのビットを受信する場合、伸張器は以前の受信値ｖ＿ｒｅｆを使用して元の値を導出する。
圧縮器と伸張器の双方が“解釈区間”を使用し、その区間に元の値が所在し、元の値が送信したものと同じＬＳＢを有する唯一の値であれば、最下位ビット（ＬＳＢ）符号化方法は正しい結果を与えることを保証する。解釈区間の概念を図１に示す。図１の解釈区間に示すように、（“区間シフトパラメータ”または“オフセット”として知られる）パラメータｐを使用して、以前の受信値ｖ＿ｒｅｆに関して解釈区間をシフトさせる。
最下位ビット（ＬＳＢ）符号化方法からの派生であり、ウィンドウＬＳＢ符号化として知られる別の符号化方法は、ｖ＿ｒｅｆ候補の窓を使用する。安全な参照原理により、伸張器からの確認応答により、圧縮器はスライドする窓から確認応答されたものより古いｖ＿ｒｅｆの値を除去することが可能である。ＬＳＢとＷ−ＬＳＢは、ＲＦＣ３０９５［ＲＯＨＣ］に記載されている。より詳細には図２に示すように、解釈区間は２つの（サブ）区間、例えば、“再配列”サブ区間や“耐性”サブ区間に明確に分割することができる。
要約すると、ＬＳＢ符号化を使用する符号化値の正しい解釈は以下のことに依存する。即ち、（１）正しい区間内に正しい値を回復するのに十分な符号化ビット数、（２）起こりうる再配列を酌量、或いは、削減するのに十分大きな再配列サブ区間、（３）起こりうるパケット損失、またはパケットの再配列の際に一時的に見失うパケットを考慮するのに十分大きな耐性のサブ区間である。
安全な参照原理（全てのパケットがコンテキストの更新を行わない）の１つの結果として、伸張器により確認応答される値のみがウィンドウ・スライディング符号化（例えば、ＬＳＢ或いはＷ−ＬＳＢ符号化）における参照として含まれる。安全な参照に適用したＬＳＢ符号化ビットの受信は正しい伸張に十分であるので、この耐性の原理は伸張器が（例えば、元の非圧縮ヘッダに対するチェックサムを使用して）正しい伸張を検証する手段を含まないフォーマットにより圧縮パケットを送信することを可能にする。Ｒモードにおける最適パケットタイプであるパケットタイプ０（Ｒ−０）とパケットタイプＲ−１＊は、非圧縮ヘッダに対して計算したチェックサムである循環冗長性符号（ＣＲＣ）を搬送しない。これらのパケットタイプは大部分のヘッダ圧縮トラフィックを担う。伸張は安全な参照への以前の更新の累積効果に完全に依存し、圧縮データは、圧縮器と伸張器双方に対して同じでなければならない参照値の現在値に基づいている。これは圧縮器と伸張器との間の順序に従う配信が保証される場合に適する。
一方、再配列が発生することがあれば、この耐性の原理の結果として、伸張器は自己完結型パケットの伸張を検証する手段を持たない、即ち、安全な参照を更新することを考慮しない。これらのパケットは通常、圧縮器と伸張器との間で交換する大部分のパケットを担う。
Ｒモードで動作する場合に耐性の問題を最少化するために、さらに多くのシーケンス番号（ＳＮ）ビットが送信されるか、解釈区間が修正されるのかの内の少なくともいずれかのことがなされ、再配列の解釈区間内により多くの値が存在することが許される。
次に、最悪ケースの再配列の深さの値を提供するために、３ＧＰＰ２ ＥＶ−ＤＯ（EVolution for Data Only）の転送リンクについて考察する。３ＧＰＰ２ ＥＶ−ＤＯ（EVolution for Data Only）の転送リンクの場合、以下の表現により、ｍｓで障害遅延（out-of-order delay）を提供する。
遅延（障害）＝［＃送信スロット］＊［インタリーブの深さ］＊［スロット時間期間］。
ＡＲＱ−２における１スロットの送信に続くＡＲＱ−１における１６スロットの送信を使用する構成を考察する。
［＃送信スロット］＝１６−２（ＡＲＱ−２の送信終了部分を占める）
［インタリーブの深さ］＝４
［スロット時間期間］＝１．６６７ｍｓ。
転送リンクにおける最悪ケースの遅延は、１０６．２４−３．３３４＝１０２．９０６ｍｓである。遅延ＡＲＱを使用すれば、ＡＲＱ−１により送信したパケットが受信されなかったことを認識するために追加時間デルタが存在するであろうし、同じパケットを再送出する。デルタが１０ｍｓであると仮定すると、その障害の深さは、２＊１０６．２４＋１０＝２２２．４８ｍｓとなる。
従って換言すれば、ＶｏＩＰなどの２０ｍｓのサービスに対して、転送リンクにおけるパケットの最大再配列の深さは最大２２２．４８／２０であり、これは凡そ１１パケットである。
ヘッダ圧縮の現在の技術では、各フィールドに対し固定ビット数により予め定義するパケットフォーマットを使用する。パケットフォーマットそれ自体の中でその存在が明確に搬送される拡張の使用を通じて、幾つかのパケットフォーマットは幾つかのフィールドに追加ビットを提供することができる。これは、特に、ＬＳＢ符号化の解釈区間を増加させるのに有用である。
特に、ＲＦＣ３０９５［ＲＯＨＣ］で定義されるＲＯＨＣプロファイルの場合、区間シフトパラメータｐは次のように定義される。
プロファイル０ｘ０００１、０ｘ０００３、及び０ｘ０００７に対して、
ビット（ＳＮ）≦４の場合、ｐ＝１、
その他の場合、ｐ＝２（ビット（ＳＮ）−５）−１
である。
これらの従来のＲＯＨＣプロファイルに対する解釈区間を表１により表す。表１に示すように、障害のあるパケットを扱うＲＯＨＣの能力は各パケットにおいて送信されるビット数に依存する。例えば、順次遅延するタイプ０のパケット（４或いは６のＳＮビットを有する）は、その制限を伸張成功が可能であるようにシーケンス中の１パケットに設定する。
これに対して、プロファイル０ｘ０００２、０ｘ０００４、及び０ｘ０００８については、ビット（ＳＮ）に関わらず、“区間シフトパラメータ”または“オフセット”パラメータｐ＝−１である。ｐ＝−１の値は、解釈区間のオフセットが正の値のみをとり、リンクにより再配列が生じれば、順次遅延するパケットを伸張することが出来ないことを意味する。
要約すると、表１によれば、１ｘＥＶ−ＤＯリンクに対して耐性を補償するためには、シーケンス番号（ＳＮ）の少なくとも９ビットが常時送信されるべきである。これは３００ｍｓの最大再配列の発生をもたらすとともに、４９５の連続パケット損失を削減する。数個に満たない連続パケット損失を保証することに関して、このリンクは確かに十分信頼性があり、９ビットのシーケンス番号を有することにより最小圧縮パケットサイズより少なくとも２乃至３オクテット大きいパケットタイプの使用を強いることを考えると、このトレードオフはうまくバランスがとれていない。
上記手法の欠点は、パケットフォーマットを僅か幾つかの特定のシナリオのために調整することである。例えば、ＲＯＨＣの場合には、パケットフォーマットが非常に小さな数の再配列を扱う（或いは、幾つかの場合には全然扱わない）一方、リンクにより連続損失の最大予測数を扱うことができるために、パケットフォーマットが定義される。
従って、任意のタイプのリンクに対して動作する、パケット損失に対する耐性と十分に大きな再配列の深さの双方を一般的な方法で扱うことができる耐性のあるパケットフォーマットを設計する場合、この手法ではトレードオフが存在する。最も能率的な圧縮において動作する場合、多くのフィールドは静的で変化がないが、他の場合にはＲＴＰシーケンス番号（ＳＮ）フィールドなどのシーケンス番号に対しては確立された線形関数をもつ。従って、単にそのシーケンス番号に対して十分なビットを搬送すれば、全てのヘッダフィールドに対する変更の搬送が可能になる。ＬＳＢ解釈区間を使用するトレードオフを図３に示す。
より速いビット速度とより短い待ち時間（ビット速度に対して待ち時間はなお比較的長い）を有する無線リンクが近い将来に展開されるなら、順序に従う配信を想定することは最早適用できない。このようなリンクには、３ＧＰＰ高速データパケットアクセス（ＨＳＤＰＡ）、３ＧＰＰ２（Evolution for Data and Voice）ＥＶ−ＤＶ及び３ＧＰＰ２（Evolution for Data Only）ＥＶ−ＤＯを含む。
国際公開第０１／３５５３４号パンフレット カプーア、Ｒ（Kapoor, R）、ハイペン、Ｊ（Haipeng, J）およびＭ、クレッツ（M. Kretz）著「耐性のあるヘッダ圧縮（Robust Header Compression、ＲＯＨＣ）：再配列および固定ＩＰ‐ＩＤのサポート（Support for Reordering and Constant IP-ID）、インターネット草案（作業進行中）、＜draft-ietf-kapoor-rohc-rtp-new-requirements-00.txt＞、２００５年３月 ハン・ヤコブソン（Van Jacobson）著「低速直列リンクのためのＴＣＰ／ＩＰヘッダの圧縮（Compressing TCP/IP Headers for Low-Speed Serial Links）」、ＩＥＴＦネットワーク作業部会、ＩＥＴＦ ＲＦＣ１１４４、１９９０年２月 ミカエル・デーゲルマルク（Mikael Degermark）、ビヨルン・ノルトグレン（Bjorn Nordgren）、ステフェン・ピンク（Stephen Pink）著「ＩＰヘッダの圧縮（IP Header Compression）」、ＩＥＴＦネットワーク作業部会、ＩＥＴＦ ＲＦＣ２５０７、１９９９年２月 スティーブン・キャスナー（Steven Casner）、ハン・ヤコブソン（Van Jacobson）著「低速直列リンクのためのＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮（Compressing IP/UDP/RTP Header for Low-Speed Serial Links）」、ＩＥＴＦネットワーク作業部会、ＩＥＴＦ ＲＦＣ２５０８、１９９９年２月
従って、有線インフラストラクチャにおけるＩＰトンネルの異なるシナリオに対して、非特許文献１にも記載されるように、パケット損失に対してだけでなく、パケットの再配列に対しても耐性のあるヘッダ圧縮アルゴリズムについての必要がある。従って、課題は、任意のタイプのリンク特性／構成に対して、圧縮アルゴリズム自体の中で、再配列と耐性のある間隔との間でできるだけ能率的なトレードオフを行うことにある。
複数ホップによるヘッダ圧縮に関する作業がＩＥＴＦで進行中である。ＡＶＴ ＷＧは関係する要求条件を定義中である。例えば、アッシュ、Ｊ（Ash, J）、グーデ、Ｂ（Goode, B）、及びハンド、Ｊ（Hand, J）著、“ＭＰＬＳを経るヘッダ圧縮に対する要求条件（Requirement for Header Compression over MPLS）”、ＲＦＣ４２４７、インターネット草案（作業進行中）、２００５年１１月と、アッシュ、Ｊ（Ash, J）他著、“ＭＰＬＳを経るヘッダ圧縮のためのプロトコルの拡張（Protocol Extensions For Header Compression over MPLS）ＡＶＴ作業部会ＩＥＴＦインターネット草案＜draft-ietf-avt-hc-over-mpls-protocol-07.txt＞”、２００６年５月を参照されたい。その作業部会は、次いでこれらの要求条件の結果として、少なくともｅＣＲＴＰ（例えば、コーレン、Ｔ（Koren, T）、キャスナー、Ｓ（Casner, S）、ジーバーギース、Ｊ（Geervarghese, J）、トンプソン、Ｂ（Thomson, B）、及びＰ．ラッディ（P. Ruddy）著、“長い遅延、パケット損失、及び再配列があるリンクのための高度圧縮ＲＴＰ（ＣＲＴＰ）（Enhanced Compressed RTP(CRTP) for Links with High Delay, Packet Loss and Reordering）”、ＩＥＴＦネットワーク作業部会ＩＥＴＦ ＲＦＣ３５４５、２００３年７月を参照）と、ＲＯＨＣ（例えば、カールステン、ボールマン他（Carsten Bormann et al.）著、“耐性のあるヘッダ圧縮（ＲＯＨＣ）（RObust Header Compression (ROHC)：枠組みおよび４つのプロファイル（Framework and four profiles）：ＲＴＰ、ＵＤＰ、ＥＳＰおよび非圧縮（RTP, UDP, ESP and Uncompressed）”、ＩＥＴＦ ＲＦＣ３０９５、２００１年４月を参照）をリンクの再配列に対して使用可能になるであろう作業を完了することが期待されている。
前述のように、幾つかのヘッダ圧縮アルゴリズム（例えば、ＲＯＨＣ）は、圧縮器と伸張器との間のチャネルが圧縮器から出力するのと同じ順序で伸張器にパケットを配信するという仮定により設計された。これは、圧縮するヘッダ特性と、リンクの可能な再配列特性ではなく、コンテキストとに基づいて、現在技術の圧縮器が通常、最適パケットタイプを選択するであろうことを意味する。
これはまた、現在技術の圧縮アルゴリズムにはリンクレイヤの任意のタイプの再配列／損失パターンに対して能率的な方法で再配列および耐性の双方を扱う能力がないであろうことも意味する。
図４は、解釈区間、例えば、ＬＳＢ解釈区間による現在技術の典型的な例を示す。図４の表は、再配列を扱うことに関してパケット損失（耐性）を扱うことへの偏りがあることを明らかに示す値を示す。４ビットのＳＮを有するパケットは１パケットの再配列の深さを可能にするが、伸張に成功するために受信に先立って最大１４個の連続損失を被る。
損失パターンが殆ど存在しない（ゼロに近い損失）ことに伸張器が遭遇し、パケットを例えば、最大１４パケットまで再配列することができるリンクの場合、この場合に必要とするであろうよりさらに多い、少なくとも９ビットのＳＮを使用することを圧縮器に要求する。さらに、パケットフォーマットが有するＬＳＢビット数が多いと、通常能率は悪く、通常シーケンス情報よりより多くを搬送する。
従って部分的に以上を要約すると、耐性とＬＳＢ符号化の再配列（例えば、ＲＯＨＣにおける）に対する許容度は、パケットフォーマットにおけるシーケンス番号（ＳＮ）ビット数とオフセットパラメータｐとにも拘束される。従来技術では、パケットフォーマット（ＰＦ）とパラメータｐの値を各プロファイルに対して静的に定義する。最も能率的な圧縮操作におけるＲＴＰプロトコルのシーケンス番号（ＳＮ）は、例えば、ＬＳＢ符号化を使用してビットを圧縮形式で搬送する唯一のフィールドである（他のフィールドはＳＮに基づき伸張することができるか、または変化しない）。
解釈区間は、ＬＳＢ符号化が扱うであろう再配列の深さと連続パケット損失数を定義する。従来、オフセットパラメータｐとパケットにおけるシーケンス番号（ＳＮ）ビット数の双方は固定である。しかしながら、再配列／耐性区間の割合は種々のリンク技術や構成に対して具体的に決められる。例えば、高速リンク（１ｘＥＶ−ＤＯ、ＨＳＤＰＡ）は信頼しうるが（〜０損失）、再配列が多いか（最大２２０ｍｓ）、再配列のない（再送信は０）、実時間でありうる（５〜１０％のＦＥＲ）。
それ故、必要なこと及び本発明の目的は、パケット損失だけでなく、パケットの再配列に対しても耐性のあるヘッダ圧縮の装置、技術、及び方法の提供である。
装置は、無線リンクを経てパケットにおいて送信する情報に関する圧縮操作または伸張操作を実行する。その無線リンクによる送信は、パケットを送信シーケンスから再配列されるようになされるかもしれない。圧縮操作と伸張操作は、耐性と再配列の深さとのトレードオフに関係する。その耐性は圧縮操作と伸張操作とにより許容されるリンクによる情報損失の程度の指標である。その再配列の深さは圧縮操作と伸張操作とにより許容されるパケット再配列の程度である。その装置はリンク特性に従って耐性と再配列の深さとのトレードオフを動的に調整する。実施例では、圧縮操作と伸張操作とが実行される情報はパケットヘッダのシーケンス番号情報である。
幾つかの非限定的な実施例では、動的に調整を実行する装置は、圧縮操作を実行する圧縮器である。その圧縮器は無線リンクを経て伸張操作を実行する伸張器にトレードオフの調整に関係する少なくとも１つのファクタをシグナリングする。その圧縮器は無線リンクの送信側において知覚されるようなリンク特性に従ってパケットのパケットフォーマットを調整する。
他の非限定的な実施例では、動的に調整を実行する装置は、伸張操作を実行する伸張器である。その伸張器は無線リンクを経て圧縮操作を実行する圧縮器にトレードオフの調整に関係するファクタをシグナリングする。その伸張器は無線リンクの受信側において知覚されるようなリンク特性に従ってパケットのパケットフォーマットを調整する。幾つかのこれらの実施例では、その伸張器と圧縮器とは、トレードオフの動的調整を反映する新規パケットフォーマットへの移行を同期させる。トレードオフの調整の結果、新規パケットフォーマットを得る。幾つかのこれらの実施例では、新規パケットフォーマットのフィールドは、新規パケットフォーマットのサイズパラメータの指示を搬送し、これにより新規パケットフォーマットに関する無線リンクを経る同期を不要にする。実装例では、そのサイズパラメータは、新規パケットフォーマットのシーケンス番号フィールドのビット数である。
トレードオフを解釈区間により表し、次いでその解釈区間を圧縮ビット数と解釈区間のオフセットＰvarにより表す。再配列の深さは、解釈区間のオフセットＰvarに依存し、耐性は圧縮ビット数と解釈区間のオフセットＰvarに依存する。実装例では、圧縮ビット数と解釈区間のオフセットを動的に変更することにより、装置はトレードオフを動的に調整する。例えば、その圧縮ビット数はファクタｋと高度化ファクタＳにより表すことができ、高度化ファクタＳを変更することにより、装置は圧縮ビット数を動的に変更する。装置は高度化ファクタＳと解釈区間のオフセットを相手装置に無線リンクを経てシグナリングする。
ここで記述する本発明の１つの側面からすれば、この技術は通信ネットワークを運用する方法を含む。この方法は、圧縮パケットヘッダを形成するパケットヘッダ情報に関する圧縮操作を実行する工程を含む。その圧縮操作は、耐性と再配列の深さとのトレードオフとに関与する（耐性は圧縮操作により許容されるリンクを経る情報損失の程度の指標であり、再配列の深さは圧縮操作により許容されるパケット再配列の程度である）。この方法はまた、パケットが送信シーケンスから再配列されるかもしれない無線リンクを経て圧縮パケットヘッダを送信する工程を含む。この方法はさらに、リンク特性に従って、耐性と再配列の深さとのトレードオフを動的に調整する工程を含む。
従って、この態様例の１つでは、本発明の技術は、（１）圧縮器から伸張器へｐの値をシグナリングすること、（２）コンテキストに維持される値Ｓ：Ｓ（＋０、１、２オクテット）に基づいて、可変サイズのパケットフォーマットセット全体の作成すること、及び（３）圧縮器から伸張器へのコンテキスト値Ｓをシグナリングすることを含む。
本発明の以上およびその他の目的、特徴および利点は、添付図面に図示された好適な実施例に関する次のより詳細な記述から明らかであろう。なお、添付図面では種々の図を通じて参照文字は同じ部分を参照する。図面は必ずしもスケーリングされているものではなく、代わって本発明の原理の図示に力点が置かれている。
以下の記載は、説明のためであり、制限するためではなく、本発明の完全な理解をもたらすために、特定のアーキテクチュア、インタフェース、技術などの具体的な詳細が説明される。しかしながら、具体的な詳細から離れる他の実施例においても本発明が実施できることは当業者に明らかであろう。即ち、当業者であれば、ここで明確に記述、または図示しなくとも、本発明の原理を実施し、本発明の精神と範囲内に含まれる種々の構成を考えることができるであろう。幾つかの例では、公知のデバイス、回路および方法の詳細な記述を省略し、不要な詳細により本発明の記述を不明瞭にしないようにしている。ここで本発明の原理、種々の側面、及び実施例について述べる全ての記述と、その具体的な例は、本発明の構成的機能的な等価物な包含することが意図されている。さらに、そのような等価物は、現在公知の等価物と将来開発される等価物、即ち、構成に関わらず同じ機能を実行するあらゆる要素も含むことが意図されている。
従って、例えば、ここでのブロック図が、技術原理を実施する例示的回路の概念図を表すことを当業者は認識するであろう。同様に、コンピュータやプロセッサが明示されているかどうかに係わらず、任意のフローチャート、状態遷移図、擬似符号などがコンピュータ可読媒体において実質的に表現され、コンピュータまたはプロセッサにより実行されうる種々の処理を表すことが認識されるであろう。
専用ハードウエアと、適切なソフトウエアと関連してソフトウエアを実行することができるハードウエアとの使用により、“プロセッサ”または“コントローラ”と名付けられた機能ブロックを含む種々の構成要素の機能を提供することができる。プロセッサにより提供される場合、その機能は単一の専用プロセッサ、単一の共有プロセッサ、または複数の個別プロセッサにより提供することができ、その機能の内の幾つかは共有、または分散することができる。さらに、用語“プロセッサ”または“コントローラ”の明白な使用は、ソフトウエアを実行可能なハードウエアを排他的に指すと解釈すべきではなく、制限なくデジタル信号プロセッサ（ＤＳＰ）のハードウエア、ソフトウエアを格納するための読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を含んでも良い。
ここで記述する種々の実施例や態様におけるヘッダ圧縮システムには再配列と耐性との間のトレードオフを動的に調整する能力がある。さらにそして、選択肢として、リンク特性を反映するパケットフォーマットを同期して調整する手段を提供する。
再配列／耐性トレードオフの動的調整を図５に示す。図５は２つの新規パラメータと共に解釈区間を示すが、２つの内の１つまたは両方が可変である。図５で、ファクタＳ（シーケンス番号（ＳＮ）高度化ファクタとしても公知）は、パケットフォーマットに適用され、圧縮シーケンス番号（ＳＮ）ビット数を増加させるファクタである。パラメータＰvarは、“区間シフトパラメータ”または“オフセット”として以前に公知のパラメータに対する可変値であり、従ってここでも可変オフセットまたは可変区間シフトパラメータとして、即ち、動的オフセットまたは動的区間シフトパラメータＰvarとしても言及される。パラメータＰvarを動的に調整し、再配列とリンクの損失特性との間の妥当な割合を提供することができる。
特に、非限定的な実施例とここで検討する態様に従い、例えば、解釈区間を動的にし（その解釈区間は、例えば、シーケンス番号に使用する最下位ビット（ＬＳＢ）符号化に使用される）、圧縮器と伸張器との間で区間の境界（例えば、可変オフセットパラメータＰvarの値）と共に、パケットフォーマットに存在する圧縮ビット（例えば、ある最少ビット数を超える）量をシグナリングすることにより、以上で検討した課題を扱う。（例えば、ＣＲＣと伝送レイヤチェックサムとの内、少なくともいずれかを使用して）伸張を検証することができるパケットタイプと、耐性のための安全な参照原理に頼るもの双方にとり、これらの態様は有用である。これらの技術は特に、排他的でなくＲＯＨＣプロファイルに関係する。
次に、以上の手法に基づき、また、これに制限されるものではないが、ＲＦＣ−３０９５［ＲＯＨＣ］の圧縮器と伸張器の動作に基づいて、可能性のある実施例について説明する。即ち、以下の実施例は以上で定義した可変区間シフトパラメータＰvarとシーケンス番号高度化ファクタＳを使用する。
図６は通信ネットワーク２０の例を示している。通信ネットワーク２０では、パケットストリームをパケットソース２１により供給する。図６は、例えば、プロトコルスタック２３に加えられる、ペイロード（ＰＡＹ）とヘッダ（Ｈ）とを持つ（メディアパケットなどの）パケット２２を示している。プロトコルスタックを含む特定のプロトコルは変化し、通常はインターネットプロトコルの下の伝送プロトコルの下にアプリケーションプロトコルを含むことができる。詳細な例示では、プロトコルスタック２３はメディアパケット２２にプロトコルヘッダ２４（例えば、ＩＰ、ＵＤＰ、及びＲＴＰ）を添付する役割を果たす。添付されたプロトコルヘッダ２４を有するパケット２２はパケットヘッダ圧縮器２５に印加される。パケット圧縮器２５はプロトコルヘッダ２４を圧縮し、その結果、パケットに対する圧縮ヘッダ（ＣＰ）２６を得る。ヘッダ圧縮器２５は、従来の（例えば、ＲＯＨＣまたはＳｉｇＣｏｍｐなど）またはその他のいずれかの多くの適切なヘッダ圧縮アルゴリズムのいずれかに従ってヘッダ圧縮を実行する。ヘッダ圧縮器２５によりパケットヘッダを圧縮した後、パケットフォーマッタ２６はトランシーバ２９に加えるパケットに圧縮ヘッダを組み込む。トランシーバ２９はインタフェース３８によりリンク３６を経て遠隔装置４０へ、圧縮ヘッダ２６を有するパケット３０などのパケットをパケットフロー３４で送信する役割を果たす。パケットフロー３４は恐らく大部分が圧縮ヘッダを有しているが、連続である必要はなく、それに代わり、関係するパケットサービスのタイプとそのパケットサービスに含まれるデータの性質（例えば、メディアタイプ）に応じて散在しても良い。
図６のパケットソース２１から発行されるパケットストリームは種々の方法で実現することができる。例えば、そのパケットストリームは、（１）サーバにより事前に記録し、送信するか（この場合、元のパケット２２におけるコンテンツ（例えば、メディア）は既に符号化されている）、（２）（ソースからの元のコンテンツを恐らくより適切であるか、端末によってサポートされるかの少なくともいずれかである別の（例えば、メディア）符号化に適合させる）トランスコーダから到来するか、或いは、（３）（例えば、生のメディアの）実時間符号化を実行するソースから到来するかのいずれかで良い。従って、ヘッダ圧縮器は、ＩＰネットワーク内のどこかの幾つかのタイプのいずれかのソースから入力パケットを受信することができる。パケットソース２１は、例えば、メディアサーバなどの任意の適するソースで良く、ヘッダ圧縮器２５に共通または離れたノードまたはネットワークに位置することができる。
図６のインタフェース３８の左に示す前述の通信構成要素は、ここでの検討に密接に関係する一定の代表的な構成要素としてのみ図示され、多くの他の図示しない構成要素も存在するので、前述の通信構成要素が通信ネットワーク２０の全体を構成している訳ではないことは理解できることである。さらに図示する構成要素のセットは、１つ以上のノードまたはネットワーク（例えば、コアネットワークまたは無線接続ネットワーク）全体に分散されても良く、幾つかの例では、個別の構成要素自体は複数のプラットフォームと複数のノードとの内、少なくともいずれかに分散されても良い。従って、簡単化のために、例示する構成要素をまとめて図６のように直接および連続的に接続するものとして示す。
遠隔装置４０には多数の構成要素があるが、遠隔装置４０により実行されるヘッダ伸張の理解に適切な一定の基本的、代表的な構成要素が図６に示されている。これらの構成要素の中に、リンク３６において受信するパケットをリンクレイヤ装置４３に、次いでパケットフォーマット解除器４４に加えるトランシーバ４２がある。パケットフォーマット解除器４４は本質的に受信パケットから圧縮ヘッダを抽出する役割を果たす。圧縮ヘッダが抽出された後、圧縮ヘッダは伸張のためにヘッダ伸張器４６に送信される。ヘッダ伸張器４６によりパケットヘッダを伸張した後、伸張ヘッダを含むパケットはバッファマネジャ４８により伸張パケットバッファ４９に格納される。バッファマネジャ４８はまた、パケット利用アプリケーション５０、例えば、メディアストリームなどの受信に関係する特定のアプリケーションのために必要な場合に、伸張パケットバッファ４９から伸張パケットを取り出す。さらに、遠隔装置４０は、リンク３６（並びにパケットフォーマッタ５２からアップストリームの不図示の種々の構成要素）を経て返送されるパケットを準備するためのパケットフォーマッタ５２を含む。
ヘッダ圧縮器２５は、パケットソース２１により供給され、おそらくさらに符号化されたパケット（これに限定されるものではないが、メディアパケットなど）のヘッダを圧縮する役割を果たす。そのヘッダ圧縮と共に、ヘッダ圧縮器２５はメディアパケットの圧縮ヘッダを伸張するのに伸張器により使用するために、その伸張器にコンテキスト情報を送信する。ここで用いられるように、“コンテキスト情報”はコンテキスト初期化情報とコンテキストリフレッシュ情報のいずれか、または両方を包含する。コンテキスト情報は遠隔装置４０へのパケットフローに含むことができる。
ヘッダ伸張器４６は従って、（移動局、移動端末、無線端末、またはユーザ機器装置などのような多数のデバイス／名称の形を取るか、または、前記のデバイス／名称として公知である）遠隔装置４０による使用に適合する。図６に示す実施例では、ヘッダ伸張器４６はたまたま無線遠隔装置４０に位置する。遠隔装置４０はそれ自体として、図６において一点鎖線３８により示されるエア或いは無線インタフェースにより無線周波数による送信を受信する。無線遠隔装置４０の使用は、例えば、ここで引用され、そして、参照により組み込まれるＲＦＣと整合性がある。さらに、ここで記述される技術は、何らかの特定のタイプの遠隔端末或いは端末インタフェースの使用に制限されるものではなく、その代わりに、或いは付加的に、その技術は無線でない伝送に、或いは、放射または無線以外の波動による伝送により利用できることが認識されるであろう。例えば、同じ仮想リンクに種々の物理経路があり、従って種々の遅延がある場合、有線リンクネットワークまたはシステムでシーケンスパケット以外に、受信が生じるかもしれない。
遠隔装置４０はエアインタフェースなどのリンク３６により、圧縮されたヘッダを持つパケットを含むパケットを受信する。パケットは一般に連続する順序でリンクにより送信される。しかしながら、遠隔装置４０は再配列を経たものを含むシーケンス以外のパケットを扱うことができる。
従って、図６に示す一般的実施例では、ヘッダ圧縮器２５は圧縮操作を実行する一方、ヘッダ伸張器４６は無線リンク３６によりパケットで送信されるヘッダ情報（例えば、パケットヘッダのシーケンス番号情報）に関して伸張操作を実行する。無線リンク３６による送信は、パケットが送信シーケンスから再配列されることがあるものである。圧縮操作と伸張操作とは、耐性と再配列の深さとのトレードオフに関係する。その耐性は圧縮操作と伸張操作とにより許容されるリンクを経る情報損失の程度の指標である。再配列の深さは圧縮操作と伸張操作とにより許容されるパケット再配列の程度である。
図６の一般的実施例では、ヘッダ圧縮器２５或いはヘッダ伸張器４６のいずれかは、リンク特性に従って、耐性と再配列の深さとのトレードオフを動的に調整する装置である。耐性／再配列の深さのトレードオフまたは割合の動的調整を容易にするために、ヘッダ圧縮器２５は、圧縮側動的再配列／損失アダプタ６０を備え、ヘッダ伸張器４６は、伸張側動的再配列／損失アダプタ６２を備える。動的調整に関係する２つの装置、ヘッダ圧縮器２５とヘッダ伸張器４６とは、耐性／再配列の深さのトレードオフまたは割合の動的調整を整合させるためにそれぞれの間でシグナリングを実行する。このようなシグナリングは“圧縮適合シグナリング”と名付ける信号により図６に反映されている。
図７Ａは非限定的な実施例を示し、そこでは、動的調整を実行する装置は圧縮操作を実行するヘッダ圧縮器２５である。図７Ａの実施例で、ヘッダ圧縮器２５は耐性／再配列の深さのトレードオフまたは割合の動的調整に変化が必要であることを判断し、その判断に従いトレードオフの調整に関係する少なくとも１つのファクタを（伸張操作を実行する）ヘッダ伸張器４６に無線リンク３６によりシグナリングする。
以上から理解されるように、耐性／再配列の深さのトレードオフまたは割合を解釈区間により表し、解釈区間を次いで圧縮ビット数と解釈区間のオフセットとにより表す。再配列の深さは解釈区間のオフセット（Ｐvar）に依存し、耐性は圧縮ビット数と解釈区間のオフセットとに依存する。実装例では、圧縮ビット数と解釈区間のオフセット（Ｐvar）とを動的に変更することにより、その装置はトレードオフを動的に調整する。例えば、圧縮ビット数はファクタｋと高度化ファクタＳにより表すことができ、高度化ファクタＳを変更することにより、その装置は圧縮ビット数を動的に変更する。解釈区間、ファクタｋ、Ｓ（高度化ファクタ）、及びＰvar（解釈区間のオフセット）は図５に関して理解される。
図７Ａの実施例は、ヘッダ圧縮器２５を圧縮ロジック６４と圧縮側の動的再配列／損失アダプタ６０をさらに含むものとして示されている。解釈区間調整器７０と、パラメータメモリ７２と、信号生成器／ハンドラ７４とをさらに含むものとして、圧縮側の動的再配列／損失アダプタ６０が図７Ａに示されている。ファクタｋ、Ｓ、及びＰvarを格納するためのレジスタ、或いは、メモリロケーション７５、７６、及び７７を持つものとして、パラメータメモリ７２が図示されている。
図７Ａの実施例はまた、ヘッダ伸張器４６を伸張ロジック７８と伸張側の動的再配列／損失アダプタ６２とを含むものとして示されている。解釈区間調整器８０と、パラメータメモリ８２と、信号生成器／ハンドラ８４とをさらに含むものとして、伸張側の動的再配列／損失アダプタ６２が図７Ａに示されている。パラメータｋ、Ｓ、及びＰvarを格納するためのレジスタ、或いは、メモリロケーション８５、８６、及び８７を持つものとしてパラメータメモリ８２が図示されている。
図７Ａの実施例では、圧縮ロジック６４はヘッダ圧縮すべきパケットをプロトコルスタック２３から受信し、（解釈区間調整器７０により通知されるように）実際にファクタと解釈区間とに整合性のある圧縮を実行する。解釈区間調整器７０はそれぞれのメモリロケーション７５、７６、及び７７からファクタの値、例えば、ファクタｋ、Ｓ、及びＰvarの値を得る。
さらに必要であれば、ヘッダ圧縮器２５は無線リンクの送信側において知覚されるようなリンク特性に従って、パケットのパケットフォーマットを調整する。特に、図７Ａは、リンクレイヤモニタ９０を持つリンクレイヤ２８を示している。矢印９２により示されるように、リンクレイヤモニタ９０はヘッダ圧縮器２５の解釈区間調整器７０に、圧縮／伸張操作に密接に関係する何らかの適切な（単数または複数の）リンク特性情報を送信する。このようなリンク特性（単数または複数）情報は、例えば、往復時間（ＲＴＴ）、遅延、（無線リンクコントロール（ＲＬＣ）とハイブリッド自動再送要求（Ｈ−ＡＲＱ）との内の少なくともいずれかの）再送信数、ハンドオーバの発生、バッファレベル、構成変更、サービス品質（ＱｏＳ）パラメータの変更、リンク再設定、サービス・データ・ユニット（ＳＤ）の廃棄、ビット誤り率の計測結果などの中の１つ以上を含むことができる。リンク状態（単数または複数）を変更した結果として、ファクタＳとＰvarとの内の少なくともいずれかの変更（例えば、新しい値）を必要とすることがあれば、解釈区間調整器７０により判断されるように、ファクタＳとＰvarに対する新しい値をそれぞれのメモリロケーション７６と７７に格納する。
さらに図７Ａの実施例で、ヘッダ圧縮器２５の信号生成器／ハンドラ７４は、矢印９４Ａにより示される圧縮適合シグナリングとして、高度化ファクタＳと解釈区間オフセットＰvarをヘッダ伸張器４６に無線リンクによりシグナリングする。なお、ファクタの新しい値に注目すれば、ファクタの新しい値は、解釈区間調整器８０により伸張操作のために用いられ、それぞれのメモリロケーション８６及び８７に格納される。
従って、図７Ａの第１実施例で、ヘッダ圧縮器２５はＰvarとＳの値とをシグナリングする。パケットフォーマットの最下位（ＬＳＢ）シーケンス番号（ＳＮ）ビット数はファクタＳだけ拡張する。即ち、ヘッダ圧縮器２５は（矢印９４Ａにより示される圧縮適合シグナリングとして）ＰvarとＳの値とをシグナリングし、効果的にヘッダ伸張器４６におけるコンテキスト入力を確定する。一度これを行うと、ヘッダ圧縮器２５により生成した各圧縮ヘッダは、フォーマットの静的定義に関して追加シーケンス番号オクテット数Ｓ（或いは、オクテット境界に向けて整列しないパケットフォーマットの場合、ビット）を持つ。同じ手順を使用して、値を何時でも再確定することができる。これらの値を受信ノードから帯域外でのシグナリングにより提供しても良いし、或いは、ヘッダ圧縮器２５はリンクレイヤの挙動を正確に記述する局所的な構成パラメータを使用しても良い。“帯域外でのシグナリング”は本質的に同じ終端ノード間で別のプロトコルを使用することを意味し、その目的は他のプロトコルレイヤのために情報をシグナリングすることである。帯域外でのシグナリングは同じか、または異なる物理チャネルを使用することができるが、異なる論理チャネルを使用する。要点は、帯域外でのシグナリングがヘッダ圧縮プロトコル内で交換されるメッセージの定義外にあることである。現状の場合のパケットタイプと新規パケットフォーマットとを図８Ａ及び図８Ｂにそれぞれ示す。
図７Ｂの非限定的な実施例において、動的調整を実行する装置は伸張操作を実行するヘッダ伸張器４６である。図７Ｂの実施例で、ヘッダ伸張器４６は耐性／再配列の深さのトレードオフまたは割合の動的調整に変化が必要であることを判断し、その判断に従いトレードオフの調整に関係する少なくとも１つのファクタを（圧縮操作を実行する）ヘッダ圧縮器２５に無線リンクによりシグナリングする。ヘッダ伸張器４６は、無線リンクの受信側において知覚されるようなリンク特性に従って、パケットのパケットフォーマットを調整する。
図７Ａの実施例によるように、図７Ｂの実施例は、圧縮ロジック６４と圧縮側の動的再配列／損失アダプタ６０をさらに含むものとしてヘッダ圧縮器２５を示しており、圧縮側の動的再配列／損失アダプタ６０は、解釈区間調整器７０と、パラメータメモリ７２と、信号生成器／ハンドラ７４とをさらに含む。パラメータｋ、Ｓ、及びＰvarを格納するためのレジスタ、或いは、メモリロケーション７５、７６、及び７７を持つものとして、パラメータメモリ７２が図示されている。同様に、図７Ｂの実施例はまた、伸張ロジック７８と、伸張側の動的再配列／損失アダプタ６２とを含むものとしてヘッダ伸張器４６を示している。解釈区間調整器８０と、パラメータメモリ８２と、信号生成器／ハンドラ８４とをさらに含むものとして、伸張側の動的再配列／損失アダプタ６２もまた、図７Ｂに示されている。パラメータｋ、Ｓ、及びＰvarを格納するためのレジスタ、或いは、メモリロケーション８５、８６、及び８７を持つものとしてパラメータメモリ８２が図示されている。
図７Ｂの実施例において、ヘッダ伸張器４６は無線リンクの受信側において知覚されるようなリンク特性に従って、パケットのパケットフォーマットを調整する。特に、図７Ｂは、リンクレイヤモニタ９４を持つリンクレイヤ装置／ロジック４３を示している。矢印９６により示されているように、リンクレイヤモニタ９４はヘッダ伸張器４６の解釈区間調整器８０に圧縮／伸張操作に密接に関係する何らかの適切な（単数または複数の）リンク特性情報を送信する。（単数または複数の）リンク特性情報は、例えば、モニタ９０に関して前にリストした特性或いはパラメータで良い。（単数または複数の）リンク状態を変更した結果として、ファクタＳとＰvarとの内の少なくともいずれかに変更（例えば、新しい値）を必要とすることがあれば、解釈区間調整器８０により判断されるように、ファクタＳとＰvarに対する新しい値をそれぞれのメモリロケーション８６及び８７に格納する。
さらに図７Ｂの実施例において、ヘッダ伸張器４６の信号生成器／ハンドラ８４は、矢印９４Ｂにより示される圧縮適合シグナリングとして高度化ファクタＳと解釈区間オフセットＰvarとをヘッダ圧縮器２５に無線リンクによりシグナリングする。なお、ファクタの新しい値に注目すれば、そのファクタの新しい値は解釈区間調整器７０により圧縮操作のために用いられ、それぞれのメモリロケーション７６と７７に格納される。
従って、図７Ｂの第２実施例では、ヘッダ伸張器４６はＰvarとＳの値をヘッダ圧縮器２５にシグナリングする。ヘッダ圧縮器２５とヘッダ伸張器４６との間の同期のために、３工程のハンドシェーク（three-way handshake）が用いられる。パケットフォーマットの最下位（ＬＳＢ）シーケンス番号（ＳＮ）ビット数はファクタＳだけ拡張する。即ち、１つの実施形では、最初にヘッダ圧縮器２５とヘッダ伸張器４６とは、ＰvarとＳのデフォルト値を使用しても良い。伸張器側（例えば、ヘッダ伸張器４６）はリンクの挙動を監視し、ＰvarとＳの新しい値をヘッダ圧縮器２５に返信する。
図７Ｂの実施例のシグナリングは、パケットフォーマットに影響することがあるので、新規フォーマットへの移行を正確に同期させるために、ヘッダ圧縮器２５およびヘッダ伸張器４６は３工程のハンドシェークを使用しなければならないことがある。一般に、このような３工程のハンドシェークでは、第１のステップとして、ヘッダ伸張器４６はヘッダ圧縮器２５に（例えば、ＰvarとＳの値を含む）メッセージを送信する。第２のステップとして、ヘッダ圧縮器２５は確認或いは確認応答メッセージによりヘッダ伸張器４６に応答し、ヘッダ圧縮器２５が値を有する第１のステップでのメッセージを受信したことを確認する。第３のステップとして、ヘッダ伸張器４６はヘッダ圧縮器２５からの確認メッセージ（第２のステップでのメッセージ）の受信時に動作する。図７Ｂの特定のシナリオでは、行うべきことはパケットフォーマットの解釈を第１のパケットフォーマットの解釈から第２のパケットフォーマットの解釈へと変更することであり、例えば、ヘッダ伸張器４６とヘッダ圧縮器２５との間で交換したメッセージがどのようにヘッダ圧縮器２５により整えられるのかということである。
次いで、３工程のハンドシェークをさらに詳細に記述すると、ヘッダ圧縮器２５は第１のパケットフォーマットの解釈或いは第２のパケットフォーマットの解釈が使用されようとも、解釈できる圧縮ヘッダフォーマット（例えば、両解釈に共通のフォーマット、或いは、トランザクションを実行するのに使用するフォーマットを解釈するのに第１のパケットフォーマットの解釈が用いられるのか、或いは第２のパケットフォーマットの解釈が用いられるのかを判断するのに十分な情報を搬送するフォーマット）を送信する。ヘッダ圧縮器２５がヘッダ伸張器４６から確認を受信するまで、ヘッダ圧縮器２５はこの“共通”フォーマットを使用し続けることができる。ヘッダ伸張器４６はメッセージを受信し、（例えば、フィードバックメッセージにおいて受信するパケットのシーケンス番号（ＳＮ）を使用して）受信メッセージに確認応答（ＡＣＫ）を送信する。次いで、ヘッダ圧縮器２５は解釈を変更したパケットに対する確認応答（ＡＣＫ）を受信し、シーケンス番号を知る。このようにしてヘッダ圧縮器２５は次に、ヘッダ伸張器４６が今や新規フォーマットの正確な解釈を開始できることを知る。従って、ヘッダ圧縮器２５は次いで新規パケットフォーマットの使用を開始することができる。
一度このハンドシェークを行うと、ヘッダ圧縮器２５により生成される各圧縮ヘッダはフォーマットの静的定義に関して、追加シーケンス番号オクテット数Ｓ（或いは、オクテット境界に対して整列しないパケットフォーマットの場合、ビット）を持つ。同じ手順を使用して、値を何時でも再確定することができる。
第３実施例は、ＬＳＢ符号化ＳＮビットに適用する自己記述可変符号化値を利用する。ＬＳＢ符号化ＳＮビットを送信する場合、ヘッダ圧縮器２５は自己記述可変符号化を使用する。ヘッダ伸張器４６は、Ｐvarのより適切な値と、再配列の最大深さ及びフィードバックを使用するリンクに対して予期される連続損失との内の少なくともいずれかをヘッダ圧縮器２５に返信し、その圧縮器は構成された値を使用しても良い。第３実施例では、パケットフォーマットのＬＳＢ ＳＮビット数は、ヘッダ圧縮器２５とヘッダ伸張器４６との間のハンドシェークなく拡張することができる。
第３の実施例をさらに詳細に考察すると、最初にヘッダ圧縮器２５はＰvarのデフォルト値を使用することができる。ヘッダ圧縮器２５はＬＳＢ符号化ＳＮビットに自己記述可変符号化を適用する。換言すれば、フィールドの始めのビットパターンを使用して、シーケンス番号（ＳＮ）フィールドを構成するシーケンス番号オクテット（或いは、ビット）数をシグナリングする。これは、本質的には、ＲＦＣ３０９５、３５頁の第４．５．６節に記載される自己記述可変長（Self-Describing Variable Length、ＳＤＶＬ）符号化である。このように使用できるフィールドは、例えば、ＬＳＢビットを使用する場合に、その元の値を正確に回復するのに幾らかのビットのみを送信する必要がある何らかのフィールドである。例えば、フィールドが０で始まれば、１オクテットのみがある。フィールドが１０で始まれば、２オクテットがあり、１１０であれば、３オクテットがあるなどである。
ヘッダ伸張器４６はリンクの挙動を監視することができ、Ｐvarの新しい値をシグナリングするか、または受信終端側において恐らく観測される再配列の最大量と耐性とに関する報告を送信する。このシグナリングがパケットフォーマットで送信する追加ビット数に影響することがあったとしても、パケットフォーマット自体にはそのフィールドのビット数を導出するのに必要な情報を既に搬送しているので、ヘッダ圧縮器２５とヘッダ伸張器４６とは新規フォーマットへの移行を同期させなくとも良い。同じ手順を使用して、その値を何時でも再確定することができる。
図７Ａの矢印９４Ａと図７Ｂの矢印９４Ｂとにより示される圧縮適合シグナリングはまた、無線リンク３６により搬送されることを当業者は認識するであろう。図７Ａの矢印９４Ａと図７Ｂの矢印９４Ｂとにより示される圧縮適合シグナリングは、帯域内シグナリングでも良いし、または、帯域外でのシグナリングでも良い。信号生成器／ハンドラ７４と信号生成器／ハンドラ８４との間の矢印による例示は、主としてこのようなシグナリングの通信終端点を強調するためのものである。
個別のハードウエア回路を用いることと、１つ以上の適切にプログラムされたデジタルマイクロプロセッサ或いは汎用コンピュータに関連して機能するソフトウエアを用いることと、アプリケーション専用集積回路（ＡＳＩＣ）を用いることと、１つ以上のデジタル信号プロセッサ（ＤＳＰ）とを用いることとの内、少なくともいずれかを用いて、上記の圧縮と伸張の内少なくともいずれかを行う構成要素と機能を分離して、或いは、集約して実施することができる。
確かにＲＦＣ３０９５［ＲＯＨＣ］，［ＩＰ−ＯＮＬＹ（ＩＰのみ）］、及び［ＲＯＨＣ‐ＵＤＰＬｉｔｅ］により関係するものであるが、汎用用語“ヘッダ圧縮”、“ヘッダ圧縮器”、及び“ヘッダ伸張器”を使用して、上記全ての思想の適用が特定のヘッダ圧縮方式に制限されないことを示す。
上記ネットワークの実施形の非限定的な環境の例は図９Ａに示すものなどのような通信ネットワーク１００である。例である通信ネットワーク１００は、無線接続ネットワーク１１０とコアネットワーク１１２の双方を含む。コアネットワーク１１２は回線交換ドメイン１１３とパケット交換ドメイン１１４を含むものとして示されている。特に図示された例では、回線交換ドメイン１１３（例えば、ＰＳＴＮ／ＩＳＤＮ接続指向のネットワーク）は、移動体交換センタ（ＭＳＣ）／在圏ロケーションレジスタ（ＶＬＲ）ノード１１５とゲートウェイＭＳＣノード１１６を含むものとして示されている。例示のために、パケット交換ドメイン１１４は、ゲートウェイ汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＧＧＳＮ）１１８に接続するサービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）１１７を含むものとして示されている。
ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１１８は、パケット交換ネットワーク（例えば、インターネット、Ｘ．２５外部ネットワーク）へのインタフェースを提供し、そのようなものとして、データフォーマット、シグナリングプロトコル、及びアドレス情報を変換する役割を果たし、種々のネットワーク間の通信を可能にする。サービングＧＰＲＳサポートノード（ＳＧＳＮ）１１７はＳＧＳＮサービス領域からルーティングされる、或いは、ＳＧＳＮサービス領域にルーティングされるパケットの経路指定を行い、ＳＧＳＮサービス領域内に物理的に位置するＧＰＲＳ加入者にサービスを提供する。サービングＧＰＲＳサポートノード（ＳＧＳＮ）１１７は、認証、暗号化、移動性管理、課金データ、ユーザ機器装置への論理リンク管理などの機能を提供する。ロケーションに応じてネットワークにおけるＳＧＳＮにより、ＧＰＲＳ加入者にサービスを提供することができる。サービングＧＰＲＳサポートノード（ＳＧＳＮ）１１７とゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１１８の機能は同じノードで結合されても良いし、図９Ａに示されるように分離したノードに存在しても良い。
図９Ａの実施例で、コアネットワーク１１２のサービング汎用パケット無線サービス（ＧＰＲＳ）サポート（ＳＧＳＮ）ノード１１７はまた、ヘッダ圧縮器２５−９Ａのホストとしても示されている。ヘッダ圧縮器２５−９Ａの構成と動作は前述のヘッダ圧縮器２５の実施例のそれと本質的に類似している。
コアネットワーク１１２は、一点鎖線１３２により示される無線接続ネットワークインタフェースを経て無線接続ネットワーク１１０に接続する。無線接続ネットワーク１１０は、１つ以上の制御ノード１２６と１つ以上の無線基地局（ＢＳ）１２８とを含む。無線接続ネットワーク１１０がＵＭＴＳ地上無線接続ネットワーク（ＵＴＲＡＮ）である非限定的な実施形では、一点鎖線１３２により示される無線接続ネットワークインタフェースはｌｕインタフェースとして公知であり、制御ノード１２６は無線ネットワークコントローラ（ＲＮＣ）の形を取る。例えば、ダイバーシチハンドオーバユニット、（単数または複数の）コントローラ、及び種々のインタフェースなどの無線ネットワーク制御ノード１２６の機能や構成要素を、当業者は理解している。無線接続ネットワーク１１０の他の実施形では、制御ノード１２６は、基地局コントローラ（ＢＳＣ）、無線ネットワーク制御ノードなどの他の名称を有することがある。とにかく簡単化のために、図９Ａの無線接続ネットワーク１１０を２つの基地局（ＢＳ）１２８に接続する１つの制御ノード１２６というただ１つの制御ノードのみにより示されていることを理解されたい。当業者により理解されるように、無線接続ネットワーク１１０には典型的には、（ｌｕｒインタフェースなどの）不図示のインタフェースを経て接続される多数の制御ノード１２６がある。
再び、簡単化のために、２つの基地局ノード１２８のみが代表する制御ノード１２６に接続するように示されている。種々の数の基地局１２８が各制御ノード１２６によりサービスの提供を受けることができ、制御ノード１２６は同じ数の基地局にサービスを提供する必要がないことが認識されるであろう。さらに当業者は、この技術分野では、基地局を時に無線基地局、ノードＢ、或いは、Ｂ−ノードとして言及されることを認識するであろう。
簡潔化のために以下の考察では、各基地局１２８は１つのセルにサービスを提供することを仮定する。しかしながら、基地局がエアインタフェースを経て１つ以上のセルに対して通信サービスを提供しても良いことを当業者は認識するであろう。例えば、２つのセルは同じ基地局サイトに位置する資源を利用することができる。さらに、夫々が１つ以上のセル／搬送波を有する１つ以上のセクタに各セルを分割しても良い。
遠隔装置１４０は、無線またはエアインタフェース１３８を経て１つ以上のセルまたは１つ以上の基地局（ＢＳ）１２８と通信する。異なる実施形では、遠隔装置１４０は、例えば、遠隔端末、無線端末または無線装置、移動局またはＭＳ、移動端末またはＭＴ、或いはユーザ機器装置（ＵＥ）などの異なる名称により知られる。勿論、図示を容易にするために、図９Ａでは１つの遠隔装置１４０のみを示すが、各基地局は通常、多くの遠隔装置にサービスを提供する。
上記のＵＭＴＳの実施形の例では、無線接続は好ましくはＣＤＭＡ拡散符号を使用して割り当てられた個々の無線チャネルを有する広帯域符号分割多元接続（ＷＣＤＭＡ）に基づく。勿論、他の接続方法を使用することができる。
遠隔装置１４０はヘッダ伸張器４６を有する。遠隔装置１４０とヘッダ伸張器４６の構成及び動作は、例えば、前記のヘッダ伸張器のいずれかで良く、それらの特徴のいずれかの側面と関連している。構成要素であるトランシーバ、プロトコルスタック、復号化器、バッファなどの構成及び動作を含む遠隔装置１４０の他の不図示の構成要素は当業者には理解されるものである。
図９Ｂの実施例では、ゲートウェイ汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＧＧＳＮ）１１８はＳＧＳＮ１１７に存在するホスト機能に代わり、ヘッダ圧縮器２５−９Ｂをホストするものとして示されている。ヘッダ圧縮器２５−９Ｂの構成及び動作は本質的に前述のもののいずれかに類似している。
図９Ｃの実施例では、無線ネットワークコントローラノード１２６を１つのコアネットワークノードに代わり、ヘッダ圧縮器２５−９Ｃをホストするものとして示されている。ヘッダ圧縮器２５−９Ｃの構成及び動作は本質的に前述のヘッダ圧縮器２５のいずれかに類似している。
図９Ａ、図９Ｂ、及び図９Ｃに図示されるようなノードには、当業者であれば理解するように、無数の他の構成要素および機能があるが、ここで記述するコンテキスト情報伝送技術を説明するのに必要か或いは有用な構成要素と機能のみがここでは図示されている。
なお、汎用用語である“ヘッダ圧縮”、“ヘッダ圧縮器”、及び“（ヘッダ）伸張器”を使用したとしても、この考え方の適用は特定のヘッダ圧縮方式に限定されない。このことは特に、これに限定されるものではないが、ＲＯＨＣ−ＴＣＰ（０ｘ０００６）、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＵＤＰ‐Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）ヘッダ圧縮プロファイルを含む大部分のＲＯＨＣプロファイルに適用可能である。提案する解決策の幾つかにはまた、いずれのＲＯＨＣ規格に対しても何らの変更を要しない利点がある。
なお、ここで記述されたヘッダ伸張技術とその他の動作は、ここで図示されたか説明されたかの内、少なくともいずれかのものと同一の構成をもつノードまたは端末において実行する必要はない。むしろ、種々の機能は他のノードまたはデバイス、またはネットワーク（例えば、コアネットワークと無線接続ネットワーク）にも分散されても良いし、または分離しても良い。さらに、ヘッダ圧縮機能でさえも、所望であれば複数のノードかデバイスの少なくともいずれかに分散することができる。
例えば、前の記述を見ると、ここで使用される用語“ネットワークノード”は、何らかのノードまたは装置、またはノードまたは装置の一部に言及するものであり、これらは全体的または部分的に、ここで記述するコンテキスト情報伝送制御を実行する。
さらに、ヘッダ圧縮器２５のホストを果たすノードまたは機器は、受信エンティティから離れた１つ以上のノードまたはネットワークインタフェースに位置しても良いし、或いは位置しなくても良い。例えば、コンテキスト情報をエアまたは無線インタフェースを経て受信エンティティ（例えば、遠隔装置４０）に送信するとここで述べることは、ノードまたは無線インタフェースとの境界をなす位置にヘッダ圧縮器２５を置くことを必要としない。
上記の新技術により提供される利点には以下の１つ以上のことを含む。即ち、
・ヘッダ圧縮アルゴリズムはフロー毎に信頼性対再配列の深さに関して（予測または
観測）リンク特性に対して調整することができる
・（圧縮器から伸張器へ）交換されるパラメータに基づき、そのフォーマットを変更
しない万能パケット、例えば、ＲＦＣ３０９５［ＲＯＨＣ］に関する拡張を有する
ＩＲ、ＩＲ‐ＤＹＮ、或いは、ＵＯＲを使用するか、或いは、（伸張器から圧縮器
への）フィードバックを使用して、動的−パラメータがシグナリングされる。これ
を長期に亘るリンク特性変動に使用することができる
・実際のリンク特性に関してパラメータを正確に設定（または交換）される場合、こ
の技術により、最も能率的なパケットが損失と再配列の双方に対して耐性をもつこ
とが可能になる。（今日の技術水準では必要以上に大きなパケットを送信すること
が必要である）。
この技術自体を標準化し、再配列の量と連続パケット損失をシグナリングするＰvarとＳと、他のパラメータとの内のいずれかを、例えば、ＩＲ、ＩＲ‐ＤＹＮに、また、同様におそらく幾つかの拡張［ＲＯＨＣ］に追加すべきである。
ここで記述した技術により、安全な参照原理を使用するヘッダ圧縮アルゴリズムを、圧縮器と伸張器との間で誤って伸張されるパケットを生成するリスクを遥かに少なくしたパケットを再配列することができるチャネルにより使用することが可能になる。これは再配列特性を考慮することにより、符号化ＬＳＢ ＳＮビット数を安全な参照原理の耐性特性に適合させることから可能になる。
このことは特に、これに限定されるものではないが、ＲＯＨＣ ＲＴＰ（０ｘ０００１）、ＵＤＰ（０ｘ０００２）、ＩＰ（０ｘ０００４）、ＥＳＰ（０ｘ０００３）、ＵＤＰ−Ｌｉｔｅ（０ｘ０００８）、ＲＴＰ／ＵＤＰ−Ｌｉｔｅ（０ｘ０００７）、及び、ＴＣＰ（０ｘ００６）ヘッダ圧縮プロファイルを含む大部分のＲＯＨＣプロファイルに適用可能である。
実施例と実施形に応じて、ここで記述した特徴は、限定されるものではないが、次の１つ以上を含む。即ち、
・ヘッダ圧縮器は最下位ビット（ＬＳＢ）符号化に使用する解釈区間のオフセットを
表す値と符号化フィールドを表すのに使用する追加ビット数の値をシグナリングす
る。これらの値はリンク特性を表し、そのリンクではヘッダ圧縮を再配列と連続パ
ケット損失に関して使用する
・ヘッダ圧縮器は、再配列と連続パケット損失とに関してシグナリングされた値に基
づきシーケンス番号に対するＬＳＢ符号化ビット数を拡大する
・ヘッダ伸張器は再配列と連続パケット損失に関して圧縮器により受信した値をその
状態で保持する
・ヘッダ伸張器は、存在する（またはパケットフォーマットの静的定義を超える）Ｌ
ＳＢ符号化シーケンス番号ビット数に関して維持する値を使用して、対応するフィ
ールドを抽出する
・ヘッダ伸張器は、ＬＳＢ符号化シーケンス番号ビットとして受信したビットをＬＳ
Ｂ復号化する際に区間を解釈する場合に、圧縮器により受信した値を使用する
・例えば、（往復時間（ＲＴＴ）、遅延、（無線リンク制御（ＲＬＣ）とハイブリッ
ド自動再送信要求（Ｈ−ＡＲＱ）との内の少なくともいずれかの）再送信数、ハン
ドオーバの発生、バッファレベル、構成変更、サービス品質（ＱｏＳ）パラメータ
の変更、リンク再設定、サービスデータユニット（ＳＤ）の廃棄、ビット誤り率の
計測結果などの中の１つ以上のような）ベアラ（リンク）特性の明確な変更に基づ
いて、ヘッダ圧縮器は随時、パラメータの新しい値をシグナリングすることができ
る。
また、実施例と実施形に応じた他の特徴として、伸張器はＬＳＢ符号化のための動的パラメータを通知する。例えば、
・ヘッダ圧縮器は最下位ビット（ＬＳＢ）符号化に使用する解釈区間のオフセットを
表す値に対する構成された、或いはデフォルトパラメータととともに、符号化フィ
ールドを表すのに使用する追加ビット数の値を最初に使用することができる
・ヘッダ伸張器はリンクの信頼性と再配列特性を監視することができる
・ヘッダ伸張器は最下位ビット（ＬＳＢ）符号化に使用する解釈区間のオフセットを
表す値と符号化フィールドを表すのに使用する追加ビット数の値をシグナリングす
る。これはフィードバックメッセージを使用して行うことができる。これらの値は
リンク特性を表し、そのリンクでは、ヘッダ圧縮を再配列と連続パケット損失に関
して使用する
・伸張器と移行が同期されるために（例えば、３工程のハンドシェークを使用して）
、一度正しいハンドシェークが発生すると、ヘッダ圧縮器は、再配列と連続パケッ
ト損失に関して伸張器によりシグナリングされた値に基づいてシーケンス番号のた
めのＬＳＢ符号化ビット数を拡大する
・例えば、観測リンク特性に基づくか、或いは、（ハンドオフ、構成変更、或いは、
ＱｏＳの変更などの）ベアラ（リンク）特性のより明確な変更に基づいて、ヘッダ
伸張器は随時パラメータの新しい値をシグナリングすることができる。
種々の特徴を組み合わせることができる。例えば、（ＬＳＢ符号化追加ビット数に対するコンテキスト値を維持する代わりに）ＬＳＢ符号化ビットを搬送するフィールドに対する自己記述可変符号化値の使用する。これは、次の１つ以上として生じる：
・ＬＳＢ符号化ビットをパケットフォーマット内で搬送するフィールドに適用する自
己記述可変符号化が動的ＬＳＢ符号化ビット数を必要とする、上記のように機能す
るヘッダ圧縮器
・受信パケットを使用して解釈するＬＳＢ符号化ビットを搬送するフィールドを自己
記述可変符号化値として解釈する（従ってこのためにコンテキスト値を維持する必
要はない）、上記のように機能するヘッダ伸張器。
特徴の組み合わせの別の例として、自己記述符号化値を（ＬＳＢ符号化追加ビット数に対するコンテキスト値を維持する代わりに）ＬＳＢ符号化ビットを搬送するフィールドに使用することができる。これは、次の１つ以上のこととして生じる：
・ＬＳＢ符号化ビットを搬送するパケットフォーマット内のフィールドに適用する自
己記述符号化が動的ＬＳＢ符号化ビット数を必要とする、上記のように機能するヘ
ッダ圧縮器
・受信パケットを使用して解釈するＬＳＢ符号化ビットを搬送するフィールドを自己
記述符号化値として解釈する（従って、このためにコンテキスト値を維持する必要
はない）、上記のように機能するヘッダ伸張器。
以上の点で、ハンドシェークすることなく、再配列と連続パケット損失とに関して伸張器によりシグナリングされた値に基づき、ヘッダ圧縮器はシーケンス番号のためのＬＳＢ符号化ビット数を拡張することができる。自己記述可変符号化値を使用するので、パケットフォーマットの変更を伸張器と同期させる必要はない。
［ＲＯＨＣ］と［ＩＰ−ＯＮＬＹ］と［ＲＯＨＣ−ＴＣＰ］と［ＲＯＨＣ−ＵＤＰＬｉｔｅ］と他の任意のヘッダ圧縮方式との内の少なくともいずれかに従って、ヘッダ圧縮器と伸張器の少なくともいずれかを実装することができる。
種々の実施例を示し、詳細に記述したが、請求の範囲は特定の実施例や例示に制限されるものではない。以上の記述はいずれも、特定の構成要素、工程、範囲、または機能が含まれなけれならない本質的なものであることを示唆するものとして読まれるべきではない。本発明は開示する実施例に限定されず、逆に種々の変形や等価な構成を含むことが意図されていることを理解すべきである。
最下位ビット符号化法における解釈区間の模式図である。 ウィンドウＬＳＢ符号化法における解釈区間の模式図である。 ＬＳＢ解釈区間を使用するトレードオフを示す模式図である。 （従来技術の）解釈区間の典型例を示すテーブルを含む模式図である。 オフセットパラメータｐの可変値と可変ファクタＳにより解釈区間を示すテーブルを含む模式図である。 ヘッダ圧縮のための再配列／耐性トレードオフを動的に調整する能力を有するヘッダ圧縮器とヘッダ伸張器を持つ通信システムの共通実施例を示すブロック図である。 ヘッダ圧縮器がヘッダ圧縮のための再配列／耐性トレードオフの調整を動的に制御する実施例を示すブロック図である。 ヘッダ伸張器がヘッダ圧縮のための再配列／耐性トレードオフの調整を動的に制御する実施例を示すブロック図である。 、 従来技術の場合と新規パケットフォーマットとの夫々におけるパケットタイプを示す模式図である。 本発明が使用されるコンテキスト例としての役目を果たす特定の通信システムの概要図であり、ヘッダ圧縮器がサービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）に含まれている。 本発明が使用されるコンテキスト例としての役目を果たす特定の通信システムの概要図であり、ヘッダ圧縮器がゲートウェイ汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＧＧＳＮ）に含まれている。 本発明が使用されるコンテキスト例としての役目を果たす特定の通信システムの概要図であり、圧縮器が無線ネットワークコントローラ（ＲＮＣ）に含まれている。

Claims (15)

  1. 無線リンク（３６）により送信シーケンスから再配列されるかもしれないパケットの送信のための情報を圧縮することに関し、耐性と再配列の深さとのトレードオフを含む圧縮操作を実行し、前記耐性が前記圧縮操作により許容される前記リンクによる情報損失の程度の指標となり、前記再配列の深さが前記圧縮操作により許容されるパケット再配列の程度である圧縮装置（２５）であって、
    前記パケットの送信中に、可変区間シフトパラメータＰ VAR と圧縮ビット数を制御する高度化ファクタＳとを動的に調整するよう構成された解釈区間調整器（７０）と、
    前記パケットの送信中に、前記圧縮操作に適切なリンク特性をモニタし、前記解釈区間調整器（７０）にリンク特性の情報を送信するよう構成されたリンクレイヤモニタ（９０）と、
    前記調整された可変区間シフトパラメータＰ VAR と高度化ファクタＳとを伸長装置（４６）に送信するよう構成された信号生成器（７４）とを有し、
    前記解釈区間調整器（７０）は前記リンクレイヤモニタ（９０）から受信した前記リンク特性に従って前記圧縮ビット数と可変区間シフトパラメータＰ VAR を動的に調整することにより変化するリンク特性に応じて、前記パケットの送信中に、前記耐性と前記再配列の深さとのトレードオフを動的に調整することを特徴とする装置。
  2. 圧縮操作が施され、無線リンク（３６）により送信シーケンスから再配列されるかもしれないパケットで送信される情報について伸張操作を実行し、前記圧縮操作と前記伸張操作には耐性と再配列の深さとのトレードオフを含み、前記耐性が前記圧縮操作と前記伸張操作とにより許容される前記リンクによる情報損失の程度の指標となり、前記再配列の深さが前記圧縮操作と前記伸張操作とにより許容されるパケット再配列の程度である伸張装置（４６）であって、
    前記パケットの受信中に、可変区間シフトパラメータＰ VAR と圧縮ビット数を制御する高度化ファクタＳとを動的に調整するよう構成された解釈区間調整器（８０）と、
    前記パケットの受信中に、前記圧縮操作に適切なリンク特性をモニタし、前記解釈区間調整器（８０）にリンク特性の情報を送信するよう構成されたリンクレイヤモニタ（９４）と、
    前記調整された可変区間シフトパラメータＰ VAR と高度化ファクタＳとを圧縮装置（４６）に送信するよう構成された信号生成器（８４）とを有し、
    前記解釈区間調整器（８０）は前記リンクレイヤモニタ（９４）から受信した前記リンク特性に従って前記圧縮ビット数と可変区間シフトパラメータＰ VAR を動的に調整することにより変化するリンク特性に応じて、前記パケットの受信中に、前記耐性と前記再配列の深さとのトレードオフを動的に調整することを特徴とする装置。
  3. 前記圧縮操作と前記伸張操作が実行される前記情報はパケットヘッダのシーケンス番号情報であることを特徴とする請求項２に記載の装置。
  4. 前記伸張装置（４６）と前記圧縮装置（２５）は、前記トレードオフの動的調整を反映する新規パケットフォーマットへの移行を同期させることを特徴とする請求項１又は２に記載の装置。
  5. 前記トレードオフの調整の結果、新規パケットフォーマットを得、
    前記新規パケットフォーマットのフィールドは前記新規パケットフォーマットのサイズパラメータの指標を搬送し、これにより前記新規パケットフォーマットに関する前記無線リンク（３６）を経る同期を不要にすることを特徴とする請求項１又は２に記載の装置。
  6. 前記サイズパラメータは前記新規パケットフォーマットのシーケンス番号フィールドのビット数であることを特徴とする請求項５に記載の装置。
  7. 前記装置（２５，４６）は、前記リンク特性に従って前記パケットのパケットフォーマットを調整することを特徴とする請求項１又は２に記載の装置。
  8. 前記リンク特性の情報は、
    往復時間（ＲＴＴ）と、
    遅延と、
    無線リンクコントロール（ＲＬＣ）とハイブリッド自動再送要求（Ｈ−ＡＲＱ）のいずれかの再送信数と、
    ハンドオーバの発生と、
    バッファレベルと、
    構成変更と、
    サービス品質（ＱｏＳ）パラメータの変更と、
    リンク再設定と、
    サービス・データ・ユニット（ＳＤＵ）の廃棄と、
    ビット誤り率（ＢＥＲ）の計測結果と
    の中の少なくとも１つを含むことを特徴とする請求項１又は２に記載の装置。
  9. 通信ネットワークを運用する方法であって、
    圧縮装置（２５）により、圧縮パケットヘッダを形成するためのパケットヘッダ情報に関して、圧縮操作により許容されるリンクによる情報損失の程度の指標である耐性と、前記圧縮操作により許容されるパケット再配列の程度である再配列の深さとのトレードオフを含む圧縮操作を実行する工程と、
    送信シーケンスから再配列されるかもしれない前記圧縮パケットヘッダを無線リンク（３６）により送信する工程と、
    リンクレイヤモニタ（９０）により、パケットの送信中に、前記圧縮操作に適切なリンク特性をモニタする工程と、
    前記リンクレイヤモニタ（９０）から解釈区間調整器（７０）に前記リンク特性の情報を送信する工程と、
    前記パケットの送信中に、前記解釈区間調整器（７０）により可変区間シフトパラメータＰ VAR と圧縮ビット数を制御する高度化ファクタＳとを動的に調整する工程と、
    信号生成器（７４）により、前記調整された可変区間シフトパラメータＰ VAR と高度化ファクタＳとを伸長装置（４６）に送信する工程とを有し、
    前記解釈区間調整器（７０）は、前記リンクレイヤモニタ（９０）から受信した前記リンク特性に従って前記圧縮ビット数と可変区間シフトパラメータＰ VAR を動的に調整することにより前記パケットの送信中に前記耐性と前記再配列の深さとのトレードオフを動的に調整することを特徴とする方法。
  10. 前記パケットヘッダ情報は、パケットヘッダのシーケンス番号情報であることを特徴とする請求項９に記載の方法。
  11. 前記圧縮装置と前記伸張装置との間で、前記トレードオフの動的調整を反映する新規パケットフォーマットへの移行を同期させる工程をさらに有することを特徴とする請求項９に記載の方法。
  12. 前記トレードオフの調整の結果、新規パケットフォーマットを得、
    前記新規パケットフォーマットのフィールドで前記新規パケットフォーマットのサイズパラメータの指標を搬送し、これにより前記新規パケットフォーマットに関する前記無線リンク（３６）を経る同期を不要にする工程をさらに有することを特徴とする請求項１１に記載の方法。
  13. 前記サイズパラメータは前記新規パケットフォーマットのシーケンス番号フィールドのビット数であることを特徴とする請求項１２に記載の方法。
  14. 前記リンク特性に従って前記パケットのパケットフォーマットを調整する工程をさらに有することを特徴とする請求項９に記載の方法。
  15. 前記リンク特性の情報は、
    往復時間（ＲＴＴ）と、
    遅延と、
    無線リンクコントロール（ＲＬＣ）とハイブリッド自動再送要求（Ｈ−ＡＲＱ）のいずれかの再送信数と、
    ハンドオーバの発生と、
    バッファレベルと、
    構成変更と、
    サービス品質（ＱｏＳ）パラメータの変更と、
    リンク再設定と、
    サービス・データ・ユニット（ＳＤＵ）の廃棄と、
    ビット誤り率（ＢＥＲ）の計測結果と
    の中の少なくとも１つを含むことを特徴とする請求項９に記載の方法。
JP2008518092A 2005-06-21 2006-06-19 動的で耐性のあるヘッダ圧縮 Expired - Fee Related JP5089584B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US69225805P 2005-06-21 2005-06-21
US60/692,258 2005-06-21
PCT/SE2006/050208 WO2006137803A2 (en) 2005-06-21 2006-06-19 Dynamic robust header compression

Publications (3)

Publication Number Publication Date
JP2008547308A JP2008547308A (ja) 2008-12-25
JP2008547308A5 JP2008547308A5 (ja) 2009-07-09
JP5089584B2 true JP5089584B2 (ja) 2012-12-05

Family

ID=37570857

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008518092A Expired - Fee Related JP5089584B2 (ja) 2005-06-21 2006-06-19 動的で耐性のあるヘッダ圧縮

Country Status (6)

Country Link
US (2) US8804765B2 (ja)
EP (1) EP1894382B1 (ja)
JP (1) JP5089584B2 (ja)
CN (1) CN101204068B (ja)
RU (1) RU2424627C2 (ja)
WO (1) WO2006137803A2 (ja)

Families Citing this family (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20041005A0 (fi) * 2004-07-20 2004-07-20 Nokia Corp Otsikkotietojen pakkaus pakkaajan ja pakkauksen purkajan välillä
US8537741B2 (en) * 2006-01-13 2013-09-17 Alcatel Lucent Method of header compression over channels with out-of-order delivery
US8406212B2 (en) 2006-02-22 2013-03-26 Apple Inc. Service flow with robust header compression (ROHC) in a WiMAX wireless network
US8605649B2 (en) 2006-12-21 2013-12-10 Alcatel Lucent Method for providing reliable communication session establishment in a communication infrastructure
US8175075B2 (en) * 2006-12-26 2012-05-08 Alcatel Lucent Adaptive header compression in a wireless communication network
NZ578058A (en) * 2007-03-16 2012-06-29 Ericsson Telefon Ab L M Method and apparatus for relocating a header compression context in a wireless communication system
JP4861891B2 (ja) * 2007-05-10 2012-01-25 京セラ株式会社 通信方法およびそれを利用した無線装置
JP4930587B2 (ja) * 2007-05-11 2012-05-16 富士通株式会社 無線通信のヘッダ圧縮制御方法並びに無線基地局及び送信装置
US8266466B2 (en) * 2007-05-21 2012-09-11 Cisco Technology, Inc. Globally synchronized timestamp value counter
US8081603B2 (en) * 2007-07-18 2011-12-20 Qualcomm Incorporated Compression static and semi-static context transfer
US20090052453A1 (en) * 2007-08-22 2009-02-26 Minkyu Lee Method and apparatus for improving the performance of voice over IP (VoIP) speech communications systems which use robust header compression (RoHC) techniques
US8270972B2 (en) * 2007-10-23 2012-09-18 Motorola Mobility Llc Method and apparatus for detecting an alternate wireless communication network
WO2009072175A1 (ja) * 2007-12-03 2009-06-11 Fujitsu Limited パケット通信装置及びパケット通信方法
US7964050B2 (en) * 2008-06-04 2011-06-21 Barrday, Inc. Method for processing a composite
US7835399B2 (en) * 2009-01-06 2010-11-16 Alcatel Lucent IP header compression context identifier synergism
WO2010121410A1 (zh) * 2009-04-20 2010-10-28 华为技术有限公司 一种采用arq机制的头压缩通信方法和装置
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
FR2951342B1 (fr) * 2009-10-13 2017-01-27 Arteris Inc Reseau sur puce a latence nulle
CN102045132B (zh) * 2009-10-23 2014-04-30 华为技术有限公司 基于重传机制的对头压缩数据包进行传输的方法和装置
CN101707616B (zh) * 2009-11-27 2013-11-06 中兴通讯股份有限公司 一种用户数据报协议数据包压缩、解压缩的方法及装置
CN101984621B (zh) * 2010-10-25 2014-09-10 中兴通讯股份有限公司 鲁棒性头压缩中一种提高列表压缩效率的方法及装置
RU2459373C1 (ru) * 2010-12-15 2012-08-20 Государственное казенное образовательное учреждение высшего профессионального образования Академия Федеральной службы охраны Российской Федерации (Академия ФСО России) Способ определения длины кадра передачи кодеков речевых сигналов на основе линейного предсказания в сетях с пакетной коммутацией на основе ip-протокола
CN102045769A (zh) * 2010-12-23 2011-05-04 南京邮电大学 一种物联网预应式切换中信头压缩上下文转移方法
EP2675128B1 (en) * 2011-04-20 2018-12-26 ZTE Corporation Method and system for updating reorder depth in robust header compression
US9515925B2 (en) 2011-05-19 2016-12-06 Qualcomm Incorporated Apparatus and methods for media access control header compression
CN102291406B (zh) * 2011-08-12 2017-02-15 中兴通讯股份有限公司 鲁棒性头压缩处理方法及鲁棒性头压缩处理器
US9125181B2 (en) * 2011-08-23 2015-09-01 Qualcomm Incorporated Systems and methods for compressing headers
CN103959854A (zh) * 2011-12-01 2014-07-30 瑞典爱立信有限公司 降低由于高ecn比率造成的分组首部压缩开销
WO2014000307A1 (zh) * 2012-06-30 2014-01-03 华为技术有限公司 数据传输方法、网元设备及通信系统
US9432983B2 (en) 2012-11-13 2016-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Extension of radio link control transmit window
US9374443B2 (en) * 2013-07-11 2016-06-21 Qualcomm Incorporated Method and apparatus for efficient packet compression
US20160212042A1 (en) * 2013-08-19 2016-07-21 Lg Electronics Inc. Broadcast transmitting device, broadcast receiving device, operating method of the broadcast transmitting device, and operating method of the broadcast receiving device
US9351195B2 (en) * 2013-09-23 2016-05-24 Qualcomm Incorporated Handling incompressible data packets on multiple data flows
US9674803B2 (en) 2013-09-23 2017-06-06 Qualcomm Incorporated Out-of synchronization detection and correction during compression
WO2015102406A1 (en) * 2014-01-03 2015-07-09 Lg Electronics Inc. Method and apparatus for transmitting/receiving broadcast signal including robust header compression packet stream
US20150195326A1 (en) * 2014-01-03 2015-07-09 Qualcomm Incorporated Detecting whether header compression is being used for a first stream based upon a delay disparity between the first stream and a second stream
US10135886B2 (en) * 2014-03-10 2018-11-20 Samsung Electronics Co., Ltd. Method and device for retaining robust header compression (ROHC) compressor state
PT3324629T (pt) * 2014-05-28 2019-10-08 Koninklijke Philips Nv Métodos e aparelhos para codificação de imagens hdr e métodos e aparelhos para utilização de tais imagens codificadas
US9473979B2 (en) * 2014-06-30 2016-10-18 Motorola Solutions, Inc. Method and system for data transmission
US9924000B2 (en) 2016-03-14 2018-03-20 Sprint Communications Company L.P. Communication packet header data compression
CN107193642A (zh) * 2016-03-14 2017-09-22 阿里巴巴集团控股有限公司 任务数据压缩切换方法、宜压缩程度评价方法及相关装置
WO2018026393A1 (en) * 2016-08-02 2018-02-08 Intel IP Corporation User equipment (ue), evolved node-b (enb) and methods for voice over lte (volte) communication in accordance with robust header compression (rohc)
FR3064865B1 (fr) * 2017-03-29 2020-10-30 Acklio Procede d'apprentissage d'un contexte de compression/decompression, dispositif, systeme et produit programme d'ordinateur correspondants.
CN109217975A (zh) * 2017-06-29 2019-01-15 大唐移动通信设备有限公司 一种数据处理方法和装置
CN110289932B (zh) * 2018-03-19 2022-07-05 中兴通讯股份有限公司 一种乱序深度值更新方法和装置
US11831565B2 (en) * 2018-10-03 2023-11-28 Advanced Micro Devices, Inc. Method for maintaining cache consistency during reordering
CN111507072A (zh) * 2019-01-31 2020-08-07 瑞昱半导体股份有限公司 基于健壮性头压缩的压缩端与解压缩端及其数据处理方法
US11792302B2 (en) * 2019-03-27 2023-10-17 Apple Inc. Ethernet header compression
US11330665B2 (en) 2020-01-09 2022-05-10 Qualcomm Incorporated Increasing throughput efficiency in a PDCP channel with ROHC TCP profile
US11442908B2 (en) 2020-05-11 2022-09-13 Saudi Arabian Oil Company Optimized database migration for large systems between platforms with different endianness
US10983513B1 (en) 2020-05-18 2021-04-20 Saudi Arabian Oil Company Automated algorithm and real-time system to detect MPFM preventive maintenance activities
US20220174134A1 (en) * 2020-12-02 2022-06-02 Semiconductor Components Industries, Llc Abbreviated header communication

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2065578C (en) 1991-04-22 1999-02-23 David W. Carr Packet-based data compression method
US6496543B1 (en) 1996-10-29 2002-12-17 Qualcomm Incorporated Method and apparatus for providing high speed data communications in a cellular environment
US6879266B1 (en) 1997-08-08 2005-04-12 Quickshift, Inc. Memory module including scalable embedded parallel data compression and decompression engines
US6317430B1 (en) * 1998-02-19 2001-11-13 Lucent Technologies Inc. ARQ protocol support for variable size transmission data unit sizes using a hierarchically structured sequence number approach
US7129860B2 (en) 1999-01-29 2006-10-31 Quickshift, Inc. System and method for performing scalable embedded parallel data decompression
US6208273B1 (en) 1999-01-29 2001-03-27 Interactive Silicon, Inc. System and method for performing scalable embedded parallel data compression
AU5920000A (en) 1999-07-09 2001-02-13 Malibu Networks, Inc. Method for transmission control protocol (tcp) rate control with link-layer acknowledgements in a wireless point to multi-point (ptmp) transmission system
US6882637B1 (en) 1999-10-14 2005-04-19 Nokia Networks Oy Method and system for transmitting and receiving packets
US6782047B1 (en) 1999-11-09 2004-08-24 Nokia Networks Oy Variable length encoding of compressed data
US6608841B1 (en) 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
AU2001237877A1 (en) 2000-03-07 2001-09-17 Telefonaktiebolaget Lm Ericsson (Publ) Pre-verification of checksums used with checksum-based header compression
US6388584B1 (en) * 2000-03-16 2002-05-14 Lucent Technologies Inc. Method and apparatus for data compression of network packets
JP4592935B2 (ja) 2000-09-11 2010-12-08 パナソニック株式会社 ヘッダ復元装置およびヘッダ復元方法
FI111493B (fi) 2000-09-22 2003-07-31 Nokia Corp Kontekstitunnisteen määrittäminen otsikkokenttien kompressoinnissa
FI110739B (fi) 2000-10-18 2003-03-14 Nokia Corp Otsikkokenttien kompressoinnin määrittäminen datapakettiyhteydelle
US7290063B2 (en) 2001-01-10 2007-10-30 Nokia Corporation Relocating context information in header compression
FI111777B (fi) 2001-01-16 2003-09-15 Nokia Corp IP-datan siirtäminen tietoliikennejärjestelmässä
JP3512177B2 (ja) 2001-05-16 2004-03-29 松下電器産業株式会社 パケット受信装置及びパケット伝送方法
FI118244B (fi) 2001-06-27 2007-08-31 Nokia Corp Otsikkokenttien kompressiotunnisteen välittäminen datapakettiyhteydellä
US7289497B2 (en) 2001-07-03 2007-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Implicit packet type identification
JP3617967B2 (ja) 2001-09-28 2005-02-09 松下電器産業株式会社 ヘッダ圧縮パケット受信装置及び方法
ATE541425T1 (de) 2002-05-08 2012-01-15 Nokia Corp Dynamische zuweisung der radiobetriebsmittel
FR2841726B1 (fr) 2002-06-28 2005-04-29 Cit Alcatel Methode de decision securisee d'un etat de donnee d'un canal de communication pour systeme de transmission
FR2842683B1 (fr) 2002-07-22 2005-01-14 Cit Alcatel Dispositif de multiplexage, dispositif de multiplexage et systeme de multiplexage/demultiplexage
US7647421B2 (en) 2002-08-20 2010-01-12 Nokia Corporation Extension header compression
TWI250724B (en) 2002-10-11 2006-03-01 Ericsson Telefon Ab L M Method and communication system for packeting messaging, and header compressor unit
JP4711681B2 (ja) 2002-12-04 2011-06-29 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 階層化メディアビットストリームのパケット化
US7822067B2 (en) 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
US7623896B2 (en) 2004-02-04 2009-11-24 Sharp Kabushiki Kaisha Wireless communication circuit and wireless communication apparatus using the same
SE0400288D0 (sv) 2004-02-11 2004-02-11 Ericsson Telefon Ab L M Improvements in or relating to telecommunication services
US7613185B2 (en) * 2004-03-17 2009-11-03 Verizon Corporate Services Group Inc. Packet header compression for lossy channels
SE0401346D0 (sv) 2004-05-24 2004-05-24 Ericsson Telefon Ab L M Methods for Increased Tolerance Against Packet Reordering for the Secure Reference Principle in Robust Header Compression
FI20041005A0 (fi) 2004-07-20 2004-07-20 Nokia Corp Otsikkotietojen pakkaus pakkaajan ja pakkauksen purkajan välillä
US7924731B2 (en) 2004-11-15 2011-04-12 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for handling out-of-sequence packets in header decompression
US7817628B2 (en) 2004-11-15 2010-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for header compression with transmission of context information dependent upon media characteristic

Also Published As

Publication number Publication date
EP1894382A2 (en) 2008-03-05
EP1894382A4 (en) 2013-11-27
US9125088B2 (en) 2015-09-01
WO2006137803A3 (en) 2007-02-15
US20150016320A1 (en) 2015-01-15
US8804765B2 (en) 2014-08-12
RU2008102133A (ru) 2009-07-27
CN101204068B (zh) 2011-03-23
JP2008547308A (ja) 2008-12-25
RU2424627C2 (ru) 2011-07-20
EP1894382B1 (en) 2016-05-18
WO2006137803A2 (en) 2006-12-28
CN101204068A (zh) 2008-06-18
US20070058679A1 (en) 2007-03-15

Similar Documents

Publication Publication Date Title
JP5089584B2 (ja) 動的で耐性のあるヘッダ圧縮
JP4965670B2 (ja) 無線通信システムにおいてヘッダ圧縮コンテキストを再配置する方法および装置
USRE47719E1 (en) Relocating context information in header compression
JP3751823B2 (ja) 実時間サービスにおけるヘッダ圧縮
RU2303858C2 (ru) Способ передачи пакетных данных в системе связи
JP5139566B2 (ja) 無線通信ネットワーク上で実時間のパケット化された音声およびデータサービスを供給するための方法および装置
US7391736B2 (en) Method and apparatus for transmitting packet data having compressed header
JP3857688B2 (ja) データパケット接続におけるヘッダ圧縮識別子の伝送
JP4489971B2 (ja) データ通信においてポーリング要求を管理するための方法及び装置
US9072006B2 (en) Mobile communication method and system
EP1372310A1 (en) Apparatus and method for communicating data using header compression
EP1362446B1 (en) Transfer of ip data in communications system, using several logical connections for compressed fields on the basis of different contexts
JP4755173B2 (ja) 後で受信するデータを指示するため更新される圧縮状態レポートを生成する方法及び装置
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
JP2005509381A (ja) ヘッダ圧縮を行う無線通信装置
JP2003283592A (ja) ワイヤレスコミュニケーションシステムのデータ伝送確認方法
JP2007189697A (ja) 分散した局のネットワークでデータパケットを交換する方法、データパケットを圧縮する装置及びデータパケットを解凍する装置
US8031659B2 (en) Telecommunications network
KR20030068742A (ko) 문맥 재할당 방법
WO2008085337A2 (en) Adaptive header compression in a wireless communication network
CN113796057A (zh) 无线通信系统中防止数据丢失的用户数据压缩方法和装置
CN100518180C (zh) 一种实现分组数据聚合协议功能的系统及方法
RU2316906C2 (ru) Способ передачи пакетных данных в системе связи
JP2005217626A (ja) 無線アクセスネットワークを介するパケットデータ交換ノード、端末及びそのプログラム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090519

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090519

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20111007

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111014

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120111

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120817

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120911

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150921

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees