JP2012533213A - バックワードルッキングロバストヘッダ圧縮レシーバ - Google Patents

Abstract

ロバストヘッダ圧縮（ＲＯＨＣ）はデータのより効率的な伝送のためにパケットヘッダ情報を圧縮する手法を提供する。圧縮はトランスミッタ及びレシーバによって設定される種々のコンフィデンスモードを使用して達成される。イニシャライゼーションアンドリフレッシュ状態（ＩＲ）がコンプレッサの第１の状態である。これにより、送信されているデータの完全な非圧縮コンテキストが提供される。典型的な動作において、ＲＯＨＣコンプレッサは周期的にコンテキスト情報を提供するＩＲパケットを伝送することにより、ＲＯＨＣデコンプレッサがＩＲパケットに続く１つまたは複数のパケットを復元できるようにする。しかしながら、デコンプレッサの起動時等の特定の条件下では、デコンプレッサはＩＲパケットを受信しない場合もある。説明されている例示的な方法及び装置において、デコンプレッサは後に受信されるＩＲパケットを使用して、以前のパケット（このパケットについては、デコンプレッサはコンテキスト情報を受信していない）を復元する。

Description

[関連特許出願]
本出願は米国特許仮出願第６１／２７０，４６６号（２００９年７月８日出願）の米国特許法第１１９条（ｅ）項に規定する優先権の利益を主張し、この仮出願の全開示内容は全ての目的において本願明細書に組み込まれたものとする。

本発明はデジタル通信システム及び方法に関し、特に、パケット通信システム及びパケット通信方法に関する。

ワイヤレスリンクを使用するインターネットプロトコル（ＩＰ）が双方向音声会話または画像等の機能のために用いられる場合の問題点は、例えば、ヘッダのオーバーヘッドが大きいことである。ＩＰ電話の音声データ及び画像データは通常、リアルタイムトランスポートプロトコル（ＲＴＰ）を利用して移送される。パケットは、リンク層フレーミング（ｌｉｎｋ ｌａｙｅｒ ｆｒａｍｉｎｇ）に加え、ＩＰヘッダ（ＩＰｖ４の場合、２０オクテット）、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダ（８オクテット）及びＲＴＰヘッダ（１２オクテット）を有する（合計で４０オクテット）。ＩＰｖ６の場合、ＩＰヘッダは４０オクテットであるので、合計で６０オクテットとなる。パケットのペイロードのサイズは使用されるフレーム及びスピーチ符号化方法に依存し、１５−２０オクテット程度である。

ロバストヘッダ圧縮（ＲＯＨＣ：Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）はデータをより効率的に伝送するためにヘッダ情報を圧縮する手法を提供する（ネットワークワーキンググループ、リクエストフォーコメント３０９５（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ， Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ３０９５）を参照されたい）。圧縮は例えば、幾つかのヘッダフィールドは先験的に良く知られた値を有し、全てを送信する必要がないことを認識し、且つ、幾つかのヘッダフィールドはパケットストリームの寿命が尽きるまでの間一定でありパケットストリームの最初に一度送信するだけで良いことを認識することによって、達成される。ＲＯＨＣにおいて、過去のパケットからの関連情報はコンテキストに維持される。コンテキスト情報は、その後のパケットを圧縮及び復元（解凍）する際に用いられる。イニシャライゼーションアンドリフレッシュ（ＩＲ）パケットは、伝送されているデータの完全な非圧縮コンテキストを提供する。

コンプレッサ及びデコンプレッサは、所定の事象が生じた場合に、コンテキストを更新する。欠陥（ｉｍｐａｒｉｍｅｎｔ）事象が生ずると、コンプレッサのコンテキストとデコンプレッサのコンテキストとの間に不一致が生ずることがあり、当該不一致により不正確な復元をしてしまう場合がある。典型的なストリーミング環境において、パケットは連続的に受信される。どのようなパケット損失であっても、コンテキストリッチな新しいパケット（例えば、ＩＲパケット）がデコンプレッサによって受信されるまで、サービスの質を低下させるおそれがある。

バースト（ｂｕｒｓｔ）モデルの動作では、同じ原理が働く。しかしバースト動作においては、データがバースト形式で送出されるので、レシーバは所定時間のデータにアクセスすることができる。バースト動作は帯域幅使用効率が良いが、エラーが無いわけではない。もしバースト伝送の間に損失があれば、レシーバは複数のパケットを含む全バーストデータを捨ててしまうおそれがあり、その結果、サービスの質が低下する。これはストリーミング動作モードの場合よりも顕著であることが多い。

バースト動作は種々のシステムにおいて使用されており、その一例はデジタル放送システム（例えば、ＡＴＳＣ−Ｍ／Ｈ（Ａｄｖａｎｃｅｄ Ｔｅｌｅｖｉｓｉｏｎ Ｓｙｓｔｅｍｓ Ｃｏｍｍｉｔｔｅｅ Ｍｏｂｉｌｅ/Ｈａｎｄｈｅｌｄ）規格に基づいたシステム）である。このようなシステムにおいて、複数のサービスのデータは所定の物理チャネルを介してバーストデータとして多重送信される。よって、レシーバは選択されたサービスのデータを周期的なバーストとして（安定的なストリームとしてではなく）受信する。従って、レシーバは獲得可能なバーストデータを突然得ることになり、その後、次のバーストデータを待たなければならない。各バーストデータは例えば、１秒間相当のストリーミング音声コンテンツ及び／もしくは画像コンテンツである。

しかしながら、レシーバに提供されるサービス（例えば、ＲＴＰを介した画像及び音声）は、安定的なデータストリームの概念においてモデル化されたメカニズムを介して提供される。ストリーミングモデルを使用すると、パケットは時間的に連続して受信される。後のパケットを受信する前に、レシーバは現在のパケットと当該後のパケットとの間の全てのパケットを受信する。これは概念的にバーストモデルと異なる。バーストモデルでは、レシーバは１回の受信によって所定時間長のパケットのフルセットを受信する。

例示的な実施形態において本発明の方法は、ロバストヘッダ圧縮（ＲＯＨＣ）デコンプレッサが後に受信されるコンテキスト・リッチなパケットを使用して、前に受信したパケットを復元する。当該前に受信したパケットについてはコンテキスト情報が受信されていない。例示的なＲＯＨＣデコンプレッサは、コンテキスト情報を欠くパケットを捨てるのではなく、後に受信するコンテキストリッチなパケット（例えば、ＩＲパケット）を用いて、当該前に受信したパケットに関連するコンテキスト情報を再形成する。このように再形成されたコンテキスト情報を使用して、当該前に受信したパケットを復元する。

上記記載に鑑みると共に下記の詳細な説明から明らかになるように、他の実施形態及び構成を採用することも可能であり、それらは本発明の原理の範囲内にある。

本発明の装置及び／または方法の幾つかの実施形態が、例示として、図面を参照しつつ以下に記載される。

典型的なＲＯＨＣシステムの概略図である。 ＲＯＨＣシステムにおけるパケット送信（ＩＲパケットの周期的な送信を含む）を示す図である。 図２の送信における第１のＩＲパケットが消失した場合を示す図である。 ＩＲパケットのフォーマットを示す図である。 ＩＲ−ＤＹＮパケットのフォーマットを示す図である。 インターネットプロトコルバージョン４（ＩＰｖ４）のＲＯＨＣのＩＲパケットヘッダのスタティック部分およびダイナミック部分を示す図である。 ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）のＲＯＨＣのＩＲパケットヘッダのスタティック部分およびダイナミック部分を示す図である。 ＲＴＰ（Ｒｅａl−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）サブヘッダのスタティック部分およびダイナミック部分を示す図である。 本発明に基づく、後に受信したＩＲパケットのコンテンツを使用して前に受信したパケットを復元する方法の例示な実施形態のフローチャートである。

本発明の技術思想を除き、図面に示された要素は周知であり、詳細には説明しない。例えば、本発明の技術的思想を除き、パケットデータ通信（例えば、ＩＰ（インターネットプロトコル）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）及びＲＯＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ））並びに、例えば、ＡＴＳＣ−Ｍ／ＨもしくはＤＶＢ−Ｈ等の通信システムについては良く知られていると仮定し、これらを本明細書において説明することはしない。尚、本発明概念の態様は従来のプログラミング技術を用いて実装することができ、当該プログラミング技術そのものを本明細書において説明することはしない。また、異なる図面における同様の参照番号は同様の要素を示している。

本発明の発明者は、バーストモードが通信における特有の課題を与えることを見出した。特に、本発明者はＲＯＨＣを例えばＲＴＰの基本プロトコルとともに使用すると、特定の現象が得られることを見出した。知られているように、ＲＯＨＣは所与の（基本の）プロトコルに対しては拡張ヘッダを使用するし、基本プロトコル（例えば、ＲＴＰ）に基づいてフォーマット化されたデータも含む。上記したように、ＲＯＨＣはＩＲパケットを使用して、所定の制御情報を送信する。バーストモードにおいて、本発明者は、もしＩＲパケットが消失したり、エラーを含んでいたり、あるいはレシーバ側で利用不能であるならば、レシーバは通常、当該消失ＩＲパケットに依存するデータパケットを捨ててしまうことに気付いた。

例示的な実施形態において、後に受信されるＩＲパケットを使用して、消失したＩＲパケットの中の色々な情報片についての値を決定または推定することができる。例示的な実施形態において、データパケットを復号化するのに使用される情報だけが、決定または推定される。他の実施形態においては、ＩＲパケット全体が決定または推定される。

図１はＲＯＨＣを採用する典型的なシステムの概略図である。ＲＦＣ３０９５はＲＯＨＣを記述すると共に種々の基本プロトコル（ＲＴＰその他を含む）への適用を記述する。図１に示されているように、典型的なＲＯＨＣ方式は、ＲＯＨＣ適応のコンプレッサもしくはトランスミッタ１１０とＲＯＨＣ適応のデコンプレッサもしくはレシーバ１２０とを介して、クライアント１０２に接続されたデータパケットのソース１０１を含む。ソース１０１及びコンプレッサ１１０は通常、同じ位置に配置され、クライアント１０２及びデコンプレッサ１２０も同じ位置に配置されるが、そのような配置は必須ではない。コンプレッサ１１０及びデコンプレッサ１２０は任意の適切な有線リンク（単数または複数）もしくは無線リンク（単数または複数）によって繋がれる。

送信されているデータに応じて、ＲＯＨＣは３つのうちの１つのモードで動作することができる。すなわち、Ｕモード（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｍｏｄｅ：ユニディレクショナルモード）、Ｏモード（Ｏｐｔｉｍｉｓｔｉｃ ｍｏｄｅ：オプティミスティックモード）またはＲモード（Ｒｅｌｉａｂｌｅ Ｍｏｄｅ：リライアブルモード）である。Ｕモードの場合、フィードバックチャネルは無いと考える。Ｏモード及びＲモードはフィードバックメカニズムを有し、よって、コンプレッサ１１０はデコンプレッサ１２０からのフィードバックに基づいて使用される圧縮レベルを変えることができる。

ＲＯＨＣ動作は通常、ＩＲ（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ ａｎｄ Ｒｅｆｒｅｓｈ）パケットの送信で開始する。ＩＲパケットは圧縮されていないパケットであり、送信されるデータのプロファイルに関する完全なコンテキスト情報を含んでいる。Ｕモードの場合、パケットはコンプレッサ１１０からデコンプレッサ１２０へフィードバック無しで送信される。コンプレッサ１１０は、デコンプレッサ１２０がどの情報を受信しなかったのかを示すフィードバックを受け取らないので、ＲＯＨＣのＵモードはタイムアウトメカニズム（所定時間が経過すると圧縮モードを切り替えるメカニズム）を有し、コンプレッサ１１０が異なる（複数の）圧縮モードの間で切り替えられるようになっている。

Ｕモード動作の場合（これは例えばＡＴＳＣ−Ｍ／Ｈ送信において使用することができるものである）、完全なコンテキストを含むＩＲパケットを周期的に送信することができる。このような動作が図２に示されている。ＩＲパケットはコンテキスト情報のスタティック部分及びダイナミック部分を非圧縮形式で含むか、またはスタティック部分のみを含む。関連するパケットタイプ（ＩＲ−ＤＹＮパケット）は、コンテキスト情報のダイナミック部分のみを含む。コンプレッサ１１０はこれら２つのタイプのＩＲパケットを一定間隔で交互に送信することができる。これは、Ｕモードにはフィードバックが無いので、特に有効である。ＩＲパケット及びＩＲ−ＤＹＮパケットのフォーマットは下記において詳述する。

図２に示されているように、ＩＲパケットＩＲ１はパケットＡ、Ｂ及びＣを復元するためのコンテキスト情報を含み、ＩＲパケットＩＲ２はパケットＰ、Ｑ及びＲを復元するためのコンテキスト情報を含む。図２に示されている例示的な状況において、パケットＩＲ１、Ａ、Ｂ及びＣは１つのタイムスライスとして一緒に送信され、パケットＩＲ２、Ｐ、Ｑ及びＲは後のタイムスライスとして一緒に送信される。タイムスライス化処理は送信方法の１つであり、各送信が所定時間の間、データのバーストとして伝送されるものであり、ＡＴＳＣ−Ｍ／ＨまたはＤＶＢ−Ｈ等の一方向放送システムに広く採用されている。例示的な実施形態において、各タイムスライスは、１つのＩＲパケットと、当該ＩＲパケットに含まれているコンテキスト情報が関連している複数のパケットとを含む。各タイムスライスはＩＲパケットでスタートする。タイムスライスは、本実施形態で説明されたパケット及びＩＲパケットとは異なる数のパケット及びＩＲパケットを有することもできる。

デコンプレッサ１２０がタイムスライスのデータの送信の間にＯＮになると、デコンプレッサ１２０は当該タイムスライスの幾つかのパケットを受信するが、当該パケットより前のＩＲパケットは受信しない。よって、デコンプレッサ１２０はそれらのパケットを復元するのに必要な関連ＩＲパケット無しで当該パケットを受信することになる。そのような場面が図３に示されている。図３において、パケットＡ、Ｂ及びＣは受信されるが、ＩＲパケットＩＲ１は受信されない。パケットＡ、Ｂ及びＣに関連するＩＲパケットがデコンプレッサ１２０によって受信されなかったので、ＩＲパケットに含まれているパケットＡ、Ｂ及びＣ復元用コンテキスト情報をデコンプレッサ１２０が使用することはできない。しかしながら、１つもしくは複数の後続のＩＲパケットを後続のスライスにおいて、後に受信することは出来る。図３に示された状況では、パケットＰ、Ｑ及びＲの前のＩＲパケットＩＲ２がデコンプレッサ１２０によって受信される。しかし上述したように、ＩＲパケットは当該ＩＲパケットの後に続くパケットのためのコンテキスト情報を含む。

本発明の例示的な実施形態によれば、ＲＯＨＣデコンプレッサはＩＲパケットに含まれているコンテキスト情報を使用して、当該ＩＲパケットの前のパケットを復元する。図３に示された場面では、デコンプレッサ１２０はＩＲパケットＩＲ２に含まれているコンテキスト情報を使用してパケットＡ、Ｂ及びＣを復元する（こうする以外に、これらパケットについてはコンテキスト情報が無い）。これは、連続するＩＲパケット（例えば、ＩＲ２及びＩＲ１）が共通の情報を含むので、可能となる。さらに、前の消失ＩＲパケットの情報の一部もしくは全部は、後続のＩＲパケットから再形成することができる。例えば、ＩＲパケットＩＲ２の中のＲＴＰタイムスタンプ（ＴＳ：Ｔｉｍｅｓｔａｍｐ）、タイムスタンプストライド（ＴＳ＿Ｓｔｉｒｄｅ）及びＲＴＰシーケンスナンバ（ＳＮ：Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）を用いて、ＩＲパケットＩＲ１の中の対応する情報を再構成することができる。

図４ＡはＲＴＰのＩＲパケットのフォーマットを示し、図４ＢはＲＴＰのＩＲ−ＤＹＮパケットのフォーマットを示している（図４Ａ及び図４ＢはＲＦＣ３０９５から導出したものである）。ＩＲパケットタイプはコンテキストのスタティック部分（つまり、一定ＳＮ関数の値）を送信する。また、必要であれば、コンテキストのダイナミック部分（つまり、一定でないＳＮ関数のパラメータ）を送信することも可能である。さらに、必要であれば、元のパケットのペイロード（もし存在するならば）を送信することも可能である。ＩＲ−ＤＹＮパケットタイプはコンテキストのダイナミック部分（つまり、一定でないＳＮ関数のパラメータ）を送信する。パケットの各フィールドには、各フィールドのオクテット数が括弧書きで示されている。

図４Ａ及び図４Ｂに示されているように、各ＩＲパケット及びＩＲ−ＤＹＮパケットはコンテキスト識別子情報（Ａｄｄ−ＣＩＤ、ＣＩＤ）を含み、この情報により、異なるコンテキストを有する複数のパケットストリームが１つのチャネルを共有することができる。各パケットの第２のオクテットはパケットタイプ（ＩＲまたはＩＲ−ＤＹＮ）を特定し、ＩＲパケットの場合、ｂｉｔ Ｄであり、これはダイナミックチェーンフィールドが存在するかどうかを表す。

図４Ａ及び図４Ｂに示されているように、各ＩＲパケット及びＩＲ−ＤＹＮパケットはヘッダ圧縮プロファイルオクテットを含む。このオクテットは、ある種類のパケットストリームのヘッダをある種類のリンクを介してどのように圧縮するのかを示す。圧縮プロファイルはＲＯＨＣヘッダ圧縮フレームワークの詳細を示す。

図４Ａ及び図４Ｂに示されているように、各ＩＲパケットヘッダ及びＩＲ−ＤＹＮパケットヘッダは、ヘッダの完全性をチェックするためのＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ：巡回冗長検査）オクテットを含んでいる。

例示的な実施形態において、図４Ａ及び図４ＢのＩＲヘッダ情報はＡｄｄ−ＣＩＤ、パケットヘッダ、プロファイル及びＣＲＣのフィールドを含んでいるが、消失したＩＲパケットのために再形成されることはない。なぜならこれらはデータパケットを復号化する際に使用されないからである。

ＩＲパケットヘッダにおいては、ＣＲＣオクテットの後にスタティックチェーンフィールドが存在しており、その後にダイナミックチェーンフィールドが存在することもある。ＩＲ−ＤＹＮパケットヘッダにおいては、ＣＲＣオクテットの後にダイナミックチェーンフィールドが存在する。ＩＲパケットもしくはＩＲ−ＤＹＮパケットのヘッダの後には、対応する元のパケットのペイロードが位置する（もし当該ペイロードがあれば）。

スタティックチェーンフィールドはスタティックサブヘッダ情報のチェーン（一連のスタティックサブヘッダ情報）を含み、ダイナミックチェーンフィールドはダイナミックサブヘッダ情報のチェーン（一連のダイナミックサブヘッダ情報）を含む。どのようなダイナミック情報が存在するかは、スタティックチェーンフィールドから推測する。圧縮可能なサブヘッダはスタティック部分とダイナミック部分に分けられる。

図５Ａ〜図５Ｃはインターネットプロトコルバージョン４（ＩＰｖ４）、ＵＤＰ（Ｕｓｅr Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）及びＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）サブヘッダ用のＲＯＨＣのＩＲパケットヘッダのスタティック部分とダイナミック部分をそれぞれ示している。（図５Ａ〜図５ＣはＲＦＣ３０９５から導取したものである。）しかし後述するように、ＵＤＰヘッダ及びＩＰヘッダの内容は通常、ＲＴＰヘッダのコンテンツよりも頻繁に変化しない。

図３に示されているようにパケットＩＲ１が消失した場合、パケットＡ、Ｂ及びＣに関連するスタティック情報及びダイナミック情報は消失する。しかしながら、後続のＩＲパケットＩＲ２は受信され、当該パケットＩＲ２は通常、消失したパケットＩＲ１に含まれていたのと同じスタティック情報を含むと共に消失したパケットＩＲ１に含まれていたダイナミック情報に幾らかの変更がなされたものを含む。よって、パケットＩＲ２に含まれているスタティック情報及びダイナミック情報を再利用することにより、消失したパケットＩＲ１に含まれていたスタティック情報及びダイナミック情報を再形成することができる。例示的な実施形態において、パケットＩＲ２のスタティック情報はパケットＩＲ１のスタティック情報として再利用され、パケットＩＲ２のダイナミック情報及び／もしくはスタティック情報はパケットＩＲ１のダイナミック情報を導出するために使用される。

ＩＰパケットヘッダ及びＵＤＰパケットヘッダについては、再利用することができるスタティック情報は、ソースアドレス、ソースポート、行先アドレス及び行先ポートを含む。放送に適用した場合（これは例示的な実施形態に包含される）、ソースネットワークアドレス、ソースネットワークポート、行先ネットワークアドレス及び行先ネットワークポートは通常、頻繁に変わらない。

同じことがＩＰｖ４ヘッダ（図５Ａ）のダイナミック部分についても言える。ＩＰｖ４ヘッダは幾つかのネットワークパラメータ、例えば、有効期間（Ｔｉｍｅ ｔｏ Ｌｉｖｅ（ＴＴＬ））及びサービスのタイプ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ（ＴＯＳ））等を含む。この情報は頻繁に変わらず、対応するＩＲパケットがないパケットに対して再利用することができる。

例えば、図５Ｃに示したようなＩＲパケットのＲＴＰヘッダの場合、再形成されるべき別の情報がある。図５Ｃに示されているように、ＲＴＰヘッダのスタティック部分はストリームのＳＳＲＣ（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ：同期ソース識別子）を含む。ＳＳＲＣはストリームを識別し、１つのＩＲパケットと次のＩＲパケットとの間で変わらないと考えられる。よって、次に受信されるＩＲパケットからのＳＳＲＣは、消失したＩＲパケットからのＳＳＲＣと同じであると考えられる。このような情報は時間経過と共に大きく変わらないので、再利用することができる。

ＲＴＰヘッダ（図５Ｃ）のダイナミック部分においては、最初の２バイト（バージョン数Ｖ、ＲＸ、ＣＣ、Ｍ及びペイロードタイプＰＴを含む）は通常、１つのＩＲパケットと次のＩＲパケットとの間で変わらないと考えられる。よって、例示的な実施形態にあっては、前記次に受信されたＩＲパケットからのこれら２つのバイトは、消失したＩＲパケットからの対応する２つのバイトと同じであると考えられ、再利用することができる。

ＩＲパケットＩＲ２のシーケンス番号（ＳＮ）を使用して、前のパケットのシーケンス番号を導出することができる。ＲＴＰの一部として、シーケンス番号は１つのパケットから次のパケットへ増加する（パケット毎に増加する）。消失したＩＲパケットのシーケンス番号は受信したＩＲパケットのシーケンス番号から判断することができる。例えば、「ｘ」個のＲＴＰデータパケットが消失したＩＲパケットと受信したＩＲパケットとの間にある場合、消失したＩＲパケットのシーケンス番号は受信したＩＲパケットのシーケンス番号から「ｘ」＋１を引くことによって得られる。従って、一例として、もし図３に示されているパケットＩＲ２が４というシーケンス番号を有しているなら、前のパケットＡ、Ｂ及びＣのシーケンス番号はそれぞれ１、２及び３であるという演算をすることができる。

図５Ｃに示されているように、ＲＴＰヘッダのダイナミック部分はタイムスタンプ（ＴＳ：Ｔｉｍｅｓｔａｍｐ）フィールド、ＴＳ＿Ｓｔｒｉｄｅフィールド及びＴｉｍｅ＿Ｓｔｒｉｄｅフィールドも含む。ＴＳ＿Ｓｔｒｉｄｅ及びＴｉｍｅ＿Ｓｔｒｉｄｅは、連続するＲＴＰタイムスタンプと連続する絶対タイムスタンプ（ウォールクロック）との間の変化を提供する。より詳しくは、ＴＳ＿Ｓｔｒｉｄｅはレシーバに、前のＩＲパケットからみた場合のＲＴＰタイムスタンプの予想変化を提示する。従って、消失ＩＲパケットのＲＴＰタイムスタンプは、受信したＩＲパケットのＴＳ＿Ｓｔｒｉｄｅ及びＲＴＰタイムスタンプから決定することができる。さらに、ＴＳ＿Ｓｔｒｉｄｅ及びＴｉｍｅ＿Ｓｔｒｉｄｅは通常、１つのＩＲパケットと次のＩＲパケットとの間で変わっていないと考えられる。例えば、「ｘ」個のデータＲＴＰパケットが消失ＩＲパケットと受信ＩＲパケットの間にある場合、当該消失ＩＲパケットのＴｉｍｅｓｔａｍｐは受信ＩＲパケットのＲＴＰのＴｉｍｅｓｔａｍｐから（ｘ＋１）×ＴＳ＿Ｓｔｒｉｄｅを引くことによって得られる。よって、一例として、もしＩＲパケットＩＲ２のＴｉｍｅｓｔａｍｐ値が１００でありＴＳ＿Ｓｔｒｉｄｅ値が１０の場合、前のパケットＡ、Ｂ及びＣのＴｉｍｅｓｔａｍｐ値はそれぞれ７０、８０及び９０であると推論される。

図５Ｃに示されているように、ＲＴＰヘッダのダイナミック部分はＣＲＬリストフィールドも含んでいる。ＣＲＬリストは通常、１つのＩＲパケットと次のＩＲパケットの間で変わらないと考えられる。従って、消失ＩＲパケットからのＣＲＬリストは、次に受信したＩＲパケットからのＣＲＬと同じであると考えられる。

よって、後のＩＲパケットを使用することにより、必要な情報のほとんど（例えば、ＲＴＰパケットのペイロードタイプ（ＰＴ）、ＲＴＰバージョン（Ｖ）及びＴｉｍｅｓｔａｍｐ（ＴＳ））を再形成することができ、それをコンテキスト情報を持っていないパケットに利用することができる。これにより、よりロバスト性の高いサービスを提供することができる。また、これにより、レシーバにとってはチューニングをより速く行うことができるようになる。なぜなら、パケットに関連するＩＲパケットの受信ができなくても、当該パケットからの情報を復号化することができるからである。

例示的な実施形態においては、ＲＯＨＣヘッダの特定のフィールドに関する信号送信要件があるために、リバースシーケンスでパケットＡ、Ｂ及びＣを再構築する必要があり得る。例えば、ＲＴＰの場合、パケットＣがまず再構築され、その後パケットＢ、そしてパケットＡが再構築される。このようにするのは、ＳＮ（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ：シーケンス番号）情報及びＴＳ（Ｔｉｍｅｓｔａｍｐ：タイムスタンプ）情報をＲＯＨＣヘッダで信号送信する方法に合わせるためである。増加するデータしか利用できないので、パケットはＩＲから逆方向（バックワード）に処理を行うことによって再構築される。

例示的な実施形態では、ＲＯＨＣパケットヘッダのＣＲＣ情報は、上述したように再形成されたヘッダ情報の妥当性をチェックするために使用することができる。ＵモードＲＯＨＣの場合、例えば、各パケットのＲＯＨＣヘッダはＣＲＣを含む。別のＩＲパケット（例えばパケットＩＲ２）に含まれている情報から再形成された情報を使って復元されたパケットＡ、Ｂ及びＣのようなパケットについては、デコンプレッサは、パケットを復元して、復元パケットを受信されたパケットヘッダに含まれているＣＲＣと比較した後、各パケットについてＣＲＣを計算することによって前記再形成された情報の妥当性をテストすることができる。一致すれば、前記再形成されたデータが有効と判断され、当該パケットをクライアントに転送することができる。一致しなければ、そのパケットは廃棄される。

ＲＴＰ／ＵＤＰ／ＩＰパケットがＲＯＨＣを用いて圧縮されている場合、レシーバはＲＴＰ／ＵＤＰ／ＩＰヘッダを復元し、ＣＲＣを適用して当該得られたヘッダを確認することができる。しかし、もしパケットが消失しているなら、再構成されたパケットに不確定な部分が含まれていることもある。従って、パケット消失の無い通常動作においては、パケットＰ０、Ｐ１、Ｐ２、Ｐ３、…がコンプレッサ１１０によってそれぞれＲＯＨＣパケットＲ（Ｐ０）、Ｒ（Ｐ１）、Ｒ（Ｐ２）、Ｒ（Ｐ３）、…に圧縮され、デコンプレッサ１２０に送信され、デコンプレッサ１２０によって当該パケットがパケットＰ０、Ｐ１、Ｐ２、Ｐ３、…に復元される。しかし、例えば、Ｒ（Ｐ２）が消失している場合、Ｐ２を再構成することができず、Ｒ（Ｐ２）が異なる情報を含んでいたので、Ｐ３を不正確に再構成する可能性がある。

簡単な構成の実施形態においてレシーバは、次のＩＲパケットが受信されるまで、単にパケットＲ（Ｐ３）、Ｒ（Ｐ４）、…を無視する。より複雑な実施形態においてレシーバはＰ３を再構成して、そのＣＲＣを行う。もしＣＲＣをパスすれば、レシーバは後続のパケットＰ４、Ｐ５、…を復号化し続け、そうでなければ、復号化を停止して次のＩＲパケットを待つ。さらに別の実施形態においてレシーバは、もしＣＲＣをパスできなければ、パケットＰ３のコンテンツは変更され（例えば、消失パケットに基づいて推定される量だけＳＮ及びＴＳを増加することによって）、ＣＲＣは変更されたコンテンツに基づいて再計算され、ＣＲＣが再び試みられる。パケットコンテンツを変更してＣＲＣを再度行うという上記処理は、ＣＲＣをパスするまで繰り返されるか、または何らかの事象が起きるまで（例えば、所定時間が経過するまで）繰り返される。

上記したようにパケットが逆の順序で再構築される場合、たとえ消失パケットがなくても、当該パケットが曖昧部分無しに生成できるかは保証されない。従って、好ましくは、ＣＲＣによるチェックを実施する。さらに、上述のパケットコンテンツの変更及びＣＲＣの再チェックという処理を繰り返して行う場合もある。

図６は上記した記載に基づく方法の例示的な実施形態のフローチャートを示している。図６に示されているように、ステップ２０２において複数のパケットを含む１つのタイムスライス（例えば図２及び図３に示されているようなもの）がデコンプレッサによって受信される。デコンプレッサはタイムスライスを検査して、もしステップ２０４において当該タイムスライスにＩＲパケットが無いことが判明したならば（図３の場合）、動作はステップ２０６へ進む。ステップ２０６において、現在のタイムスライスで受信されている圧縮パケットが、後に実行される復元のために保存される。この保存は、後続のタイムスライスが、パケットを復元するために使用できるコンテキスト情報を含むＩＲパケットと共に受信されているという予想のもとに行われる。その後、ステップ２０２に戻り、別のタイムスライスの受信を待つ。

ステップ２０４において現在のタイムスライスがＩＲパケットと共に受信されたと判断されると（図２に示された場合のように）、動作はステップ２０７へ進み、デコンプレッサは、復元を待っているステップ２０６で保存された以前のタイムスライスからの圧縮パケットがないかをチェックする。もしなければ、動作はステップ２１２に進み、現在のタイムスライスにおいて受信されたパケットヘッダが、現在のタイムスライスにおいて受信されたＩＲパケットに存在するコンテキスト情報に基づいて復元される。

ステップ２０７において、復元を待っている古いタイムスライスからの圧縮パケットが保存されていると判断されたならば、動作はステップ２０８へ進み、現在のＩＲパケットの情報が抽出される。抽出された情報はステップ２１０において、関連ＩＲパケットを持っていない保存パケットのためのスタティック情報及びダイナミック情報を再形成するために使用される。上記したように、コンテキスト情報を再形成するステップは、抽出したスタティック情報及び／もしくはダイナミック情報の一部もしくは全てを再利用し、且つ／または抽出したスタティック情報及び／もしくはダイナミック情報の一部もしくは全てからコンテキスト情報を導出することを含む場合がある。その後、動作はステップ２１２に進み、記憶されたパケットは上記した再形成されたコンテキスト情報に基づいて復元される。さらに、現在のタイムスライスにおいて受信されたパケットも、上記抽出された情報に基づいて復元される。その後、動作はステップ２０２に戻り、別のタイムスライスの受信を待つ。

上記において、パケットがバースト形式またはタイムスライス形式で送信されるバーストモードの動作の例示的実施形態を説明してきたが、本発明の原理はパケットが連続するストリームで送信されるストリーミングモードの動作にも適用可能である。

他の例示的な実施形態において、ＲＯＨＣデコンプレッサは前に受信したコンテキストリッチなパケットを使用して、後に受信するパケット（このパケットについては、コンテキスト情報が受信されない）を復元する。例示的なＲＯＨＣデコンプレッサは、コンテキスト情報を欠いているパケットを捨てる代わりに、前に受信したコンテキストリッチなパケット（例えばＩＲパケット）を使用して、後に受信したパケットに関するコンテキスト情報を再形成する。このように再形成されたコンテキスト情報は、受信したパケットを復元するために使用される。例示的な実施形態において、データパケットを復号化する際に使用される情報だけが、決定されまたは推定される。他の実施形態においては、ＩＲパケット全体が決定されまたは推定される。

さらに別の例示的な実施形態においては、ＲＯＨＣデコンプレッサは前に受信したコンテキストリッチなパケットと後に受信したコンテキストリッチなパケットとを使用して、コンテキスト情報を受信していないパケットを復元する。例示的なＲＯＨＣデコンプレッサは、コンテキスト情報を欠いているパケットを捨てる代わりに、ＩＲパケット等のコンテキストリッチな複数のパケット（コンテキスト情報を受信していないパケットの前のパケットと後のパケット）の組み合わせを使用して、当該パケットに関連するコンテキスト情報を再形成する。例えば、ＲＴＰを適用している場合、消失ＩＲパケットのＳＮ及びＴＳ等の情報は、前に受信したＩＲパケット（正しく受信されたＩＲパケット）及び後に受信したＩＲパケット（正しく受信されたＩＲパケット）の対応する値を補間することにより決定することができる。このように再形成されたコンテキスト情報が当該パケットを復元するために使用される。例示的な実施形態において、データパケットを復号化する際に使用される情報だけが決定されまたは推定される。別の実施形態においては、ＩＲパケット全体が決定されまたは推定される。

直近のＩＲパケット（例えば消失ＩＲパケットのすぐ前のＩＲパケットまたはすぐ後のＩＲパケット）が当該消失ＩＲパケットのコンテンツを再形成するための最も正確な情報を含んでいる可能性が最も高いと思われるが、離れたＩＲパケットからの情報を使用してもよい場合もある（特に、近くのＩＲパケットの情報の妥当性に疑問がある場合）。

本発明に基づく種々の例示的な実施形態が可能である。例えば、例示的な実施形態において、ＲＯＨＣシステム内において消失ＩＲパケットの全てもしくは一部を、異なるＩＲパケットを使用して再形成する方法が提供される。他の例示的な実施形態において、消失ＩＲパケットに基づくデータを処理する（例えば復号化する）方法が提供される。この処理は、再形成されたＩＲパケットを使用して行われる。他の例示的な実施形態においては、前記再形成を実行する処理装置及び／もしくは前記処理方法を実行する処理装置が提供される。他の例示的な実施形態においては、プリプロセッサ、エンコーダ、トランスミッタ、レシーバ、デコーダ、ポストプロセッサ、セットトップボックス、携帯電話、ラップトップコンピュータその他のパーソナルコンピュータ、ＰＤＡその他の家庭用（個人用）通信機器（上記した処理装置を含む）等の装置やデバイスが提供される。

本発明による実施形態は色々な用途に適用できる。例えば、実施形態は、ビデオデータの符号化及び／もしくは他のタイプのデータの符号化に利用することができる。さらに、実施形態は規格として利用できるし、または、規格に用いられるものとして利用できる。そのような規格の１つはＡＴＳＣ−Ｍ／Ｈ規格であるが、他の規格（既存の規格または将来作られる規格）にも適用できる。もちろん、実施形態は規格に利用される必要はない。

本明細書に記載された実施形態は例えば、方法、プロセス、装置、ソフトウエアプログラム、データストリームまたは信号において実装することができる。たとえ１つの実施形態でのみ説明されたとしても（例えば方法として説明されたとしても）、上記した特徴の実施は他の形態（例えば装置またはプログラム）においても実施することができる。装置は、適切なハードウエア、ソフトウエア及びファームウエアにおいて実施することができる。方法は例えば装置（例えば、コンピュータ、マイクロコンピュータ、集積回路またはプログラム可能論理デバイスを含めて一般的に処理装置と称されるプロセッサ）において実施することができる。プロセッサは、通信装置（例えば、コンピュータ、携帯電話、携帯用情報端末（ｐｏｒｔａｂｌｅ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）／個人用情報端末（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）（ＰＤＡ）及びエンドユーザ間の情報通信のための他の装置）を含む。

本明細書に記載された種々のプロセス及び特徴は種々の異なる機器またはアプリケーション（たとえばデータ符号化及びデータ復号化に関連づけられた機器またはアプリケーション）において具体的に実施することができる。そのような機器の例は、エンコーダ、デコーダ、デコーダからの出力を処理するポストプロセッサ、エンコーダへの入力を提供するプリプロセッサ、ビデオコーダ、ビデオデコーダ、ビデオコーデック、ウエブサーバ、セットトップボックス、ラップトップコンピュータ、パーソナルコンピュータ、携帯電話、ＰＤＡ及びその他の通信装置である。明確にする必要があるならば、上記機器は移動できるものでもよく、さらに移動車両に設けられるものでもよい。

さらに、本発明の方法はコンピュータによって実行される命令として実装されてもよく、そのような命令（及び／または実行によって生成されるデータ値）は、例えば、集積回路、ソフトウエアキャリア、または、ハードディスク、コンパクトディスク、ランダムアクセスメモリ（ＲＡＭ）もしくはリードオンリーメモリ（ＲＯＭ）といった他の記憶装置等の、コンピュータ読取可能媒体に記憶されることもある。前記命令はコンピュータ読取可能媒体に実装されたアプリケーションプログラムとして実装されてもよい。命令は例えば、ハードウエア、ファームウエア、ソフトウエア、もしくはこれらの組み合わせにおいて実装される。命令は例えば、オペレーティングシステム、別個のアプリケーションもしくはこれらの組み合わせの中に見つけられるものであってもよい。従って、プロセッサは、例えば、方法を実施する装置と、方法を実施するための命令を保持するコンピュータ読取可能媒体（例えば記憶装置）を含む装置として特徴付けられる。さらに、コンピュータ読取可能媒体は命令に加えまたは命令の代わりに、実行によって生成されたデータ値を記憶することもできる。

上記において複数の実施形態が説明された。しかしながら、種々の変形が可能である。例えば、異なる実施形態の要素を組み合わせたり、追加したり、変形したり、除去したりすることによって、別の実施形態を作ることもできる。また、当業者であれば、異なる構造及び異なる手順を上記した内容の代わりに採用できることが理解できるであろうし、その結果として得られる実施形態が少なくとも上記実施形態と実質上同じ機能（単数または複数）を実質上同じ方法（単数または複数）で発揮して実質上同じ結果（単数または複数）を得ることができることも理解できるであろう。よって、上記した実施形態及び上記されなかった実施形態は本開示に包含され、本開示の範囲に含まれる。

上記の記載に鑑みれば、これまでの説明は単に本発明の原理を例示したにすぎず、当業者であれば多くの代替実施形態を考えることができるであろう。そのような代替実施形態は本明細書に明記されていないが、本発明の原理を具現化するものであって、本発明の範囲内のものである。例えば、別個の機能的要素として説明されていないが、当該機能的要素は１つもしくは複数の集積回路（ＩＣ）に実装することができる。同様に、別個の要素として図示されているが、当該要素の幾つかもしくは全ては、記憶されたプログラムにより制御されるプロセッサ（例えばデジタル信号プロセッサまたは汎用プロセッサ）に実装されてもよい。当該プロセッサは例えば１つもしくは複数のステップに対応する関連ソフトウエアを実行するプロセッサであり、当該ソフトウエアは種々の適切な記憶媒体のいずれかに実装されたものでよい。さらに、本発明の原理は種々のタイプのワイヤレス通信システム、例えば、地上放送、衛星放送、Ｗｉ−Ｆｉ通信、携帯通信その他に適用することができる。つまり、本発明の技術思想は固定式のトランスミッタ及びレシーバ、または移動式のトランスミッタ及びレシーバにも適用可能である。従って、多くの変形を上記実施形態になすことができ、その他の構成も本発明の精神及び範囲から離れることなく実施することができる。

１０１ ソース
１１０ コンプレッサ
１２０ デコンプレッサ
１０２ クライアント

Claims (30)

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. 前記受信する手段は、前記第１の圧縮データパケットの前に、それ以前の初期化パケットを受信し、当該それ以前の初期化パケットはコンテキスト情報を含み、前記第１の圧縮データパケットを復元するための前記コンテキスト情報は、前記初期化パケットに含まれているコンテキスト情報と前記それ以前の初期化パケットに含まれているコンテキスト情報とから再形成される、請求項２１記載の装置。

Images