(57)【要約】  パケット交換ネットワークで使用するために、パケットの誤った順序の程度に関する外部情報を使用して、ヘッダ圧縮をそのような誤った順序に対してより強くするための方法が提供される。
2009524289.tif 000002
【特許請求の範囲】
【請求項１】
各々のシーケンス番号を有する複数の低レベルパケットを受信することと、
低レベルパケットを高レベルパケットとして再構成するステップであって、１つまたは複数の低レベルパケットが、前記高レベルパケットの各々の構成要素であることと、
高レベルパケットのうちの少なくとも１つをさらなる処理のために転送することとを含む方法であって、
シーケンス番号のいくつかから、１より多いシーケンシャル位置に対応するデルタＳＮの量によって、少なくとも１つの高レベルパケットの構成要素が順番より進んで到着したことを判定することと、
デルタＳＮが１より多いシーケンシャル位置に対応する特定の限度を上回る場合、前記少なくとも１つの高レベルパケットの転送を遅延させることとを特徴とする、方法。
【請求項２】
少なくとも１つの前記高レベルパケットが遅延されている間、遅延されたパケットよりも順番が先行する１つまたは複数の高レベルパケットが再構成されて転送され、それによって転送された高レベルパケットを部分的に順序を並べ替える、請求項１に記載の方法。
【請求項３】
遅延の間に１つまたは複数の順番が先行する高レベルパケットを転送することによって、デルタＳＮが減少し、
デルタＳＮが特定の限度内に入る場合に、遅延された高レベルパケットが転送される、請求項２に記載の方法。
【請求項４】
遅延の間に１つまたは複数の順番が先行する高レベルパケットを転送することによって、デルタＳＮが減少し、
（ａ）デルタＳＮが特定の限度内に入る場合、または（ｂ）遅延について特定の限界が達せられた場合の早い方の発生時に、遅延された高レベルパケットが転送される、請求項２に記載の方法。
【請求項５】
デルタＳＮの量が、低レベルパケットのシーケンス番号がアウトオブオーダーである程度から判定され、
特定の限度が、先に到着する低レベルパケットのシーケンス番号が次に到着する低レベルパケットのシーケンス番号を上回る量についての限度である、請求項１に記載の方法。
【請求項６】
高レベルパケットが、ｐと呼ばれる誤った順序の最大許容程度を有し、
特定の限度が、まとめてｐの高レベルパケットを構成してもよい低レベルパケットの数に設定される、請求項５に記載の方法。
【請求項７】
高レベルパケットのすべてが、同じ数ｑの低レベルパケットによって構成され、特定の限度がｐ×ｑである、請求項６に記載の方法。
【請求項８】
高レベルパケットが、最小でｑの変更可能な数の低レベルパケットによって構成され、特定の限度がｐ×ｑである、請求項６に記載の方法。
【請求項９】
失われたか、または廃棄されたものとして識別された低レベルパケットのシーケンス番号が、低レベルパケットのシーケンス番号がアウトオブオーダーであると判定される程度を減少させるために考慮に入れられる、請求項５に記載の方法。
【請求項１０】
到着するパケットの中の誤った順序の量を測定することと、アウトオブオーダーのパケット配信がどれだけ生じるかについての少なくとも１つの統計的推定値を提供することとをさらに含む、請求項１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はパケット交換ネットワークに関し、より詳細には、そのようなネットワークの中でのヘッダ圧縮に関する。
【背景技術】
【０００２】
インターネットプロトコル（ＩＰ）は、有線ネットワークとワイヤレスネットワークとの両方で有力な伝送プロトコルとなっており、遠距離通信とデータネットワークとの収束につながっている。例えばボイスオーバＩＰ、双方向ゲーム、インスタントメッセージング等の多くのサービスおよびアプリケーションでは、ＩＰパケットのペイロードは、ヘッダとほとんど同じサイズか、またはヘッダよりも小さい場合さえある。ＩＰ伝送プロトコルに加えて、ＲＴＰ（リアルタイムプロトコル）、ＵＤＰ（ユーザデータグラムプロトコル）などのその他のプロトコルは、パケットデータネットワークでの効果的な伝送のために、本来の情報ビットに付加される。複数のホップから構成されるエンドトゥエンド接続では、これらのプロトコルヘッダは非常に重要であるが、まさしく１つのリンク（ホップトゥホップ）では、これらのヘッダは圧縮されることが可能である（またリンクの別のエンドでは、解凍されなければならない）。９０％以上の節約の多くの場合では、これらのヘッダを圧縮することは可能であり、したがって帯域幅を節約し、高価なリソースを効率よく使用する。またＩＰヘッダの圧縮は、パケットロスの減少および改善された双方向の応答時間など、その他の重要な利点を提供する。
【０００３】
図１は、ワイヤレス通信ネットワークの一般的な構造を示す。アクセス端末（ＡＴ）は、エアインタフェースを介して基地局（ＢＴＳ）と通信する。複数の基地局は、各ワイヤレスデータセッションのために信号通信およびトラフィック処理を提供する無線ネットワークコントローラ（ＲＮＣ）と通信する。ＡＴ、ＢＴＳ、ＲＮＣおよび構成要素間のインタフェースは、無線アクセスネットワーク（ＲＡＮ）から構成されている。パケットデータサービスノード（ＰＤＳＮ）はコアネットワークの中に存在し、ＡＴがサービスセッションを開始するサービスネットワークによって割り当てられる。ＡＴは、ネットワークとのデータセッションのために、アクティブ接続を確立する。パケットは、ＡＴからＢＴＳ、ＲＮＣ、ＰＤＳＮおよびコアネットワークへ向けて送信され、受信される。
【０００４】
ＩＰヘッダ圧縮は、不十分な帯域幅を保存し、伝送効率を改善するために、ＲＡＮの中で通信リンクを介して送信されるパケットに適用される。ＡＴとＲＮＣとの間か、またはＡＴとＰＤＳＮとの間の、コンプレッサおよびデコンプレッサが属することが可能な２つの選択肢がある。ＡＴがネットワークとの接続を確立する場合、例えばＶｏＩＰ呼び出しなど、アプリケーション層のパケットは、ＲＴＰ／ＵＤＰ／ＩＰプロトコルスタックを介して運搬される。ＲＴＰ／ＵＤＰ／ＩＰプロトコルヘッダは、例えばロバストヘッダ圧縮（Ｒｏｂｕｓｔ  Ｈｅａｄｅｒ  Ｃｏｍｐｒｅｓｓｉｏｎ）（ＲＯＨＣ）アルゴリズムを使用して、コンプレッサによって圧縮される。圧縮されたパケットは、ＲＮＣおよびＰＤＳＮに送信される。ＲＮＣまたはＰＤＳＮのいずれかのデコンプレッサは、ＲＯＨＣヘッダを解凍して本来のＲＴＰ／ＵＤＰ／ＩＰヘッダを再確立し、それをコアネットワークへのアプリケーション層パケットに付加する。ダウンリンク方向では、ＰＤＳＮおよびＲＮＣは、コアネットワークからＩＰパケットを受信する。ＰＤＳＮまたはＲＮＣのいずれかのコンプレッサは、ＲＯＨＣヘッダを生成するＲＴＰ／ＵＤＰ／ＩＰヘッダを圧縮し、それをＡＴに向けて送信する。ＡＴのデコンプレッサは、本来のＲＴＰ／ＵＤＰ／ＩＰを再生し、それらをアプリケーション層に伝える。
【０００５】
有線およびワイヤレスネットワークで、様々なヘッダ圧縮アルゴリズムが提案され、実施されてきた。ヘッダ圧縮アルゴリズムの背景にある基本概念は、同じパケットストリームからのヘッダの中の冗長性を利用するというものである。パケットからパケットで変化することないヘッダの中の一部の静的フィールドは、はじめに一度送信されるだけである。ヘッダの中の変化するフィールドについては、フィールドの値の中の差だけを送信して、送信されるビットの数を最小化するために、デルタ圧縮が使用される。ＲＯＨＣ圧縮アルゴリズムは、プロトコルヘッダの中の動的フィールドの圧縮のために、ウィンドウベース最下位ビットコード化を使用する。ＲＯＨＣ圧縮アルゴリズムは、フィードバックメカニズムも組み込む。ＲＯＨＣは、エラー率が高く、ラウンドトリップ時間が長いワイヤレスリンク上で強い。ＲＯＨＣは非常に効果的で強く、無線リソースが高価なワイヤレスネットワークのために適している。
【０００６】
ヘッダ圧縮の動作を含む一般的な手順は、以下のように説明される。
１．コンプレッサおよびデコンプレッサは最初に、圧縮および解凍のために使用されるコンテキスト情報を確立しなければならない。
２．コンテキストの確立後、コンプレッサは圧縮されたヘッダを備えたパケットを送信し始める。
３．コンプレッサとデコンプレッサとの両方について定義される状態が存在する。コンプレッサは最も低い圧縮状態から、徐々により高い圧縮状態に移行する。より高い圧縮状態では、コンプレッサはより効率的に、すなわちより低い圧縮状態よりもより小さなサイズの圧縮パケットにヘッダを圧縮することができる。
４．デコンプレッサはそのより低い圧縮状態から開始し、徐々により高い状態に移行する。一旦パケットが適切に解凍されると、デコンプレッサは最も高い状態、すなわち「フルコンテキスト」状態に移行し、確立されたコンテキスト情報に基づいてパケットを解凍することができる。
５．理想的には、パケットロスまたはチャネルに沿ったパケットの誤った順序が存在しない場合、コンプレッサは最も効果的な圧縮ヘッダを作り出す最適な圧縮状態に達し、デコンプレッサはパケットを首尾よく解凍することができる。
６．大量のパケットロスまたはかなりの程度のパケットの誤った順序が存在する場合には、解凍の失敗が生じることがある。失敗が繰り返し生じる場合、デコンプレッサは通常、フルヘッダパケットを送信することによって、コンプレッサに圧縮状態を再同期するかどうかを尋ねる送信者に、フィードバックパケットを送信する。フルヘッダ情報を受信する前に、デコンプレッサは圧縮ヘッダを備えた受信パケットを、そのパケットが損なわれていなくても廃棄する。コンプレッサとデコンプレッサとの間の再同期の間、さらなるパケットロスが生じるので、処理能力および呼び出しの品質が低下する。したがって、圧縮の失敗を迅速に回復し、全体のパケットロスを最小化することが重要である。
【０００７】
ほとんどのヘッダ圧縮アルゴリズムは、コンプレッサとデコンプレッサとの間のチャネルが、各圧縮フローについてのパケット順序を維持することを要求されるという仮定に基づいて設計されたものである。この仮定の背景にある動機は、考慮される第１候補のチャネルが、ヘッダが圧縮されたパケットのインオーダー配信を保証するというものであった。この仮定を用いて、アルゴリズム設計のための要件リストのトップに近い目的である、圧縮の効率性およびパケットロスに対する許容度を改善することができる。
【０００８】
しかしながら、少なくとも一部のネットワークの一部のチャネルは、インオーダー配信を常に保証するわけではない。一部のチャネルは、遅延の影響を受けやすいアプリケーションのために順番の並べ替え遅延を減少させるために、パケットのインオーダー配信を行わないことを選択する場合がある。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ヘッダが圧縮されたパケットの順序を並べ替えることができるチャネルに適応するために、ヘッダ圧縮アルゴリズムを強化することが求められている。ヘッダ圧縮アルゴリズムにとっては、前述のような順序の並べ替えの予想されるレベルに対して強化されることが有利であろう。
【課題を解決するための手段】
【００１０】
本発明者は、前述のような誤った順序に対してヘッダ圧縮をより強くするために、パケットの誤った順序の程度に関する外部情報を使用するための方法を発見した。
【発明を実施するための最良の形態】
【００１１】
一旦コンプレッサおよびデコンプレッサのロジック、ならびに操作上の手順が定義されると、パケットの誤った順序に対するヘッダ圧縮の強さがわかる。パケットの誤った順序に対する強さとパケットロスとの間には、しばしば妥協点が存在する。換言すれば、圧縮効率が同じである（圧縮されたヘッダのサイズが同じである）と考えると、アルゴリズムがパケットロスに対してより強い場合には、誤った順序に対してはあまり強くない。アルゴリズムをパケットの誤った順序に対してより強くし、パケットロスに対して同じ強さを維持するためには、通常、大きな圧縮ヘッダのサイズが必要とされ、その結果圧縮効率はより少なくなる。さらに、状態移行パラメータなどのコンプレッサおよびデコンプレッサのロジックは、パケットのロスと誤った順序との両方について、チャネル上で最適化されなければならない。
【００１２】
この説明の中で使用される専門用語は、以下のような定義を有する。
シーケンシャリーアーリーパケット（Ｓｅｑｕｅｎｔｉａｌｌｙ  ｅａｒｌｙ  ｐａｃｋｅｔ）
チャネル上で遅れた同じパケットフローのうちの１つまたは複数のパケットよりも前にデコンプレッサに到着するパケット。シーケンシャリーアーリーパケットの到着時には、チャネル上で遅れたパケットは、失われたパケットから区別されることは不可能である。
シーケンシャリーレイトパケット（Ｓｅｑｕｅｎｔｉａｌｌｙ  ｌａｔｅ  ｐａｃｋｅｔ）
パケットは、同じパケットフローに属する１つまたは複数のその他のパケットが受信された後でデコンプレッサに到着する場合、その連続の中で遅れるが、シーケンシャリーレイトパケットはその他のパケットよりも前にコンプレッサから送信されたものである。
【００１３】
本発明者は、チャネル上で生じている誤った順序の量を示す外的な手段が存在することを仮定する。これは、ネットワークの中でパケット配信を制御することによって認識されることが可能である。例えばＲＡＮの中では、無線リンクプロトコル（ＲＬＰ）層はそれ自体のシーケンス番号を有するので、パケットの誤った順序は検出され、制御されることが可能である。ＲＡＮなどの十分に管理されたネットワークが関与する別の実施例では、パケットの誤った順序の量は測定および／または推定されることが可能である。この情報は、圧縮能力を最適化するために、コンプレッサとデコンプレッサとのペアに渡されることが可能である。
【００１４】
本発明の１つの例示的な実施形態は、図２に示されているように、チャネル上で生じている誤った順序の程度を説明する外部情報を使用する。コンプレッサおよびデコンプレッサは、前述のような情報を取得すると実施パラメータを選択するので、コンプレッサとデコンプレッサとのペアは予想される誤った順序の程度を許容することが可能である。その結果、アウトオブオーダーのパケットはおそらく解凍の失敗を起こしにくくなり、したがって圧縮の効率は改善することになる。
【００１５】
例えばＲＯＨＣアルゴリズムでは、ウィンドウベースの最下位ビット（ＷＬＳＢ）圧縮アルゴリズムの中のパラメータｐは、アウトオブオーダーのパケットの状況を処理するために構成されることが可能である。
【００１６】
より具体的には、ロバストヘッダ圧縮（ＲＯＨＣ）は、規格ＲＦＣ３０９５（２００１年６月）の中で説明されている。ＲＦＣ３０９５のセクション４．５＿１は、最下位ビット（ＬＳＢ）コード化を説明している。関連部分の中では、ＲＦＣ３０９５はＬＳＢコード化におけるロバストヘッダ圧縮について説明している：
ｋを正の整数として、ｋ個のフィールド値の最下位ビットは本来のフィールド値の代わりに送信される。ｋビットを受信した後、デコンプレッサは、基準（ｖ＿ｒｅｆ）として先に受信された値を使用して、本来の値を導き出す。
この方式は、コンプレッサとデコンプレッサとの各々が、
１）本来の値が存在し、
２）本来の値が、送信されたものとまさに同じｋ個の最下位ビットを有する唯一の値である解釈区間を使用するのであれば、適切なものであることが保証される。
解釈区間は、関数ｆ（ｖ＿ｒｅｆ，ｋ）として説明されることが可能である。ｐを整数として、ｆ（ｖ＿ｒｅｆ，ｋ）＝［ｖ＿ｒｅｆ−ｐ，ｖ＿ｒｅｆ＋（２∧ｋ−１）−ｐ］とする。関数ｆは、任意の値ｋについて、ｋ個の最下位ビットがｆ（ｖ＿ｒｅｆ，ｋ）の中の値を独自に識別するという属性を有する。
【００１７】
パラメータｐの目的は、ｖ＿ｒｅｆに対して解釈区間をシフトすることを可能にすることである。ｐの値は、特定の種類のフィールドに対してコード化効率を改善するために、異なる特性のフィールドに適応されることが可能である。現在のＲＯＨＣ規格であるＲＦＣ３０９５では、ｋとｐとの間の関係は固定されている。換言すれば、一旦コンプレッサが、圧縮フィールドのためにどれだけのビット（ｋ）が使用されるのかを判断すると、ｐの値はｋの値から間接的に判定される。ｐの値をｋから独立させるため、またはｋの値によってｐを変更可能にするための新たな提案が存在する。
【００１８】
シーケンス番号ｘを備えたシーケンシャリーレイトパケットは、シーケンシャリーアーリーパケットが、ｘ＋ｐよりも少ないシーケンス番号を備えたシーケンシャリーレイトパケットよりも前に到着する場合、適切にデコードされることが可能である。コンプレッサおよびデコンプレッサは、チャネル上の誤った順序の程度を示す外部表示を取得することが可能な場合、処理能力を最適化するために、しかるべくパラメータｐを選択することができる。
【００１９】
本発明の別の例示的な実施形態では、図３に示されているように、コンプレッサ状態の中の状態移行パラメータを最適化するために外部情報が使用される。コンプレッサは常に最低の圧縮状態で開始し、はじめにデコンプレッサとのコンテキストを確立するために、フルヘッダを備えたパケットを送信する。コンプレッサは、一旦デコンプレッサがフルコンテキストを受信したと確信すると、より高い圧縮状態へ移行する。
【００２０】
コンプレッサは、例えばフルヘッダパケットの連続番号を送信することによって、またはデコンプレッサから肯定応答パケットを受信することによって、または両方のイベントによって、デコンプレッサがフルコンテキストを受信したという確信を得る。送信されるフルヘッダパケットの数はチャネル特性によって、すなわちパケットロスおよびパケットの誤った順序の程度によって決まってもよい。送信されるフルヘッダパケットの数を特定する設計パラメータは、どれだけのパケットロスおよび誤った順序がチャネル上で予想されるのかをコンプレッサが知っている場合、最適化されることが可能である。例えば、パケットロスが小さく、パケットがインオーダー配信されるチャネルについては、コンプレッサは状態移行に先行するフルヘッダパケットの数を３であると選択してもよい。パケットロスが小さく、例えば程度４などのある程度の誤った順序のあるチャネルについては、状態移行に先行するフルヘッダパケットの数は、代わりに６に設定されてもよい。このパラメータは、パケットロス率とパケットの誤った順序の程度との両方を考慮することによって、最適化されることが可能である。
【００２１】
本発明のさらなる例示的な実施形態では、図４に示されているように、ＲＡＮは、誤った順序の量を検出することによって、デコーディングの際にデコンプレッサを支援する。ＲＡＮが、コンプレッサおよびデコンプレッサによるアウトオブオーダーパケットを処理する能力を認識している場合、ＲＡＮは誤った順序の状況を検出し、パケットの到着があまりにも遅い場合、パケットを配信しないことを選択することができる。代替として、ＲＡＮは依然として到着の遅いパケットをデコンプレッサに配信してもよい。しかしながらパケットの配信は、このパケットがどれくらい遅れて到着したのかを示すために、シーケンス番号のギャップを示す表示を含んでもよい。デコンプレッサは、デコーディングを補助するために、前述のような到着の遅れを示す表示を使用することができる。
【００２２】
本明細書と同日に出願した同一所有者による特許出願、米国特許出願第１１／３３２，７６１号、Ｃ．Ｆ．Ｍｏｏｎｅｙ  ａｎｄ  Ｑ．Ｚｈａｎｇ、「Ｍｅｔｈｏｄ  ｆｏｒ  Ｃｏｎｔｒｏｌｌｉｎｇ  Ｐａｃｋｅｔ  Ｄｅｌｉｖｅｒｙ  ｉｎ  ａ  Ｐａｃｋｅｔ  Ｓｗｉｔｃｈｅｄ  Ｎｅｔｗｏｒｋ」の中で、本発明者は、無線アクセスネットワーク（ＲＡＮ）およびその他のパケット交換ネットワークで、パケット配信におけるパケットの誤った順序を制御するための方法を説明している。同特許出願の中で説明されているように、ＲＬＰ層または同様のものは、対応する上層のパケットをインオーダーで配信するように、到着するＲＬＰパケットの順番の並べ替えを実行してもよい。このことは受信されたＲＬＰパケットをバッファリングし、そのシーケンス番号を調べ、上層パケットを再び組み立てるＲＬＰ層によって達成される。ＲＬＰは、エラーで受信されたパケットを検出する場合、そのパケットを廃棄し、次に配信されるパケットの予想ＲＬＰシーケンス番号（ＳＮ）を前に進める。ＲＬＰパケットが送信中に失われる場合、このパケットについての肯定応答タイマは期限切れとなり、ＲＬＰ層は次に配信されるパケットの予想ＳＮを前に進める。
【００２３】
パケットのアウトオブシーケンス配信については、ＲＬＰはアウトオブシーケンスの上層パケットを配信することができる。換言すれば、上層パケットを構成するＲＬＰパケットは、常にインオーダーで配信される。しかしながらＲＬＰによって配信される上層パケットは、アウトオブシーケンスで配信されてもよい。
【００２４】
上層パケットが単一のＲＬＰパケットの中に封入されている場合、ＲＬＰ層は、先に受信されたＲＬＰパケットからシーケンス番号のギャップを有するＲＬＰパケットを受信すると直ちに、上層パケットを配信することができる。しかしながら、上層パケットが複数のＲＬＰパケットに分解されている場合、ＲＬＰ層は、完全な、または部分的な上層パケットを組み立てることができるように、すべてのデータセグメントが到着するのを待たなければならない。その場合、上層パケットを構成するＲＬＰパケットは、適切に順序を並べ替えられる。しかしながら、言及されているように、異なる上層パケットがアウトオブオーダーで配信されてもよい。
【００２５】
本発明のコンテキストでは、ＲＬＰ層は誤った順序の程度の外部推定値とともに、誤った順序に関する統計値を提供することによって、ヘッダ圧縮のプロセスを補助することができる。誤った順序の程度は、到着するパケットのシーケンス番号におけるギャップを検出することによって測定される。したがって、例えば図５に示されているように、連続して到着するシーケンス番号は、アウトオブオーダーのパケット到着の場合、変数「アウトオブオーダー」として計算される。統計値は、例えばアウトオブオーダーの（例えば何らかの適切なタイムウィンドウにわたる）平均値、最大値および最小値について維持され、更新される。
【図面の簡単な説明】
【００２６】
【図１】ワイヤレス通信ネットワークの一般的な構造を示す図である。
【図２】外部情報を用いる順序並べ替えチャネルを介したヘッダ圧縮を示す流れ図である。
【図３】外部情報を用いるコンプレッサの状態移行パラメータ構成を示す流れ図である。
【図４】ＲＡＮの支援を用いる順序並べ替えチャネル上でのヘッダ解凍を示す流れ図である。
【図５】パケットの誤った順序の程度を測定するための例示的なアルゴリズムの流れ図である。
【図１】
2009524289.tif 000003
【図２】
2009524289.tif 000004
【図３】
2009524289.tif 000005
【図４】
2009524289.tif 000006
【図５】
2009524289.tif 000007
【手続補正書】
【提出日】平成20年8月19日(2008.8.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
パケット交換ネットワークのチャネルに到着したパケットの誤った順序の測定値を取得することと、
取得された誤った順序の測定値に応じて、少なくとも１つのパケットヘッダ圧縮アルゴリズムの作動パラメータを変更することと、
前記変更されたパラメータにしたがって、前記チャネルに到着したパケットのヘッダを圧縮することを含む、方法。
【請求項２】
圧縮アルゴリズムが、本来のフィールド値の一部が送信され、本来の値が以前に受信されたフィールド値Ｖｒｅｆについての解釈区間内に送信された一部を解釈することによって回復される様な種類のアルゴリズムであり、
少なくとも１つの変更されるべき作動パラメータが、Ｖｒｅｆに関連した解釈区間の位置を含む、請求項１に記載の方法。
【請求項３】
圧縮アルゴリズムが、変更可能な数の連続パケットが、パケットを圧縮されたヘッダとともに送信する前にコンテクストを確立するために、フルヘッダとともに送信される様な種類のアルゴリズムであり、
少なくとも１つの変更されるべき作動パラメータが、フルヘッダとともに送信されるべき連続パケットの数を含む、請求項１に記載の方法。
【請求項４】
遅れて到着するパケットの配信を、解凍アルゴリズムへの入力として制御することをさらに含む、請求項１に記載の方法。
【請求項５】
制御するステップが、解凍アルゴリズムによって許容されることが可能なパケットの遅れの程度を判定することを含む、請求項４に記載の方法。
【請求項６】
制御するステップが、遅れて到着するパケットが特定の量よりも遅れている場合、それらの配信を保留することを含む、請求項４に記載の方法。
【請求項７】
制御するステップが、少なくともいくつかの遅れて到着するパケットの各々を、パケットが遅れていることを示す表示と一緒に配信することを含む、請求項４に記載の方法。
【請求項８】
制御するステップが、少なくともいくつかの遅れて到着するパケットの各々を、パケットがどれだけ遅れて到着したのかを示す表示と一緒に配信することを含む、請求項４に記載の方法。
【請求項９】
パケットがどれだけ遅れて到着したのかを示す表示が、到着したパケットのシーケンス番号の差に基づく、請求項８に記載の方法。
【国際調査報告】
2009524289.tif 000008
2009524289.tif 000009