JP3608660B2 - 圧縮ヘッダデータを送信する方法、装置、およびシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、一般に、圧縮ヘッダデータを送信機から受信機に送信する方法、送信機、およびシステムに関し、より特定的には、信頼性のない通信路と共に用いられ得るヘッダ圧縮機構に関する。
【０００２】
【従来の技術】
１つの端末から別の端末にデータを送信する通信技術がいくつか存在し、パケット指向、またはＩＰ（インターネットプロトコル）に基づくプロトコルがしばしば、好適に選択される。パケット内の不必要なデータの送信を避けるため、パケットは送信される前に圧縮される。
【０００３】
図１は、送信機１として動作する第１の端末、および受信機２として動作する第２の端末を有する典型的なシステムを示す図である。送信機１は、パケットを受信機２に送信する送信ユニット４と、送信ユニット４に接続されたコンプレッサ３と、受信機２からパケットを受信する受信ユニット５とを備える。受信機２は、送信機１からパケットを受信する受信ユニット６と、受信ユニット６に接続されたデコンプレッサ７と、パケットを送信機１に送信する送信ユニット８とを備える。
【０００４】
送信機から受信機に送信されたパケットは、パケットのストリームによって転送される主要な情報を含むパケットデータと、異なるプロトコル層のパケットの管理に必要とされるヘッダデータとを含む。
【０００５】
例えば、ユーザデータグラムプロトコル（ＵＤＰ）／インターネットプロトコル（ＩＰ）に従って送信されるリアルタイム伝送プロトコル（ＲＴＰ）パケットのヘッダは、少なくとも４０バイトである。このヘッダは冗長な情報を含んでいるので、このヘッダも圧縮される。ヘッダ圧縮プロトコルは、一般に、ヘッダの冗長性をなくし、送信される情報を効率的に符号化する。例えば、４０バイトを超えるヘッダは、最良の場合には、単一のバイトに低減され得る。
【０００６】
無線リンク等の信頼性がない通信路用に特別に開発されたヘッダ圧縮プロトコルは、非特許文献１に示されている。
【０００７】
非特許文献１には、ＩＰ／ＵＤＰ／ＲＴＰパケットのヘッダを圧縮するための３つの方式が記載されている。第３のモード、または信頼性のあるモードは、特殊な圧縮アルゴリズムを用いることにより、圧縮リンク上でのパケットの消失に対する頑健性が達成される。
【０００８】
入力パケットのヘッダを圧縮するために、変化することのないヘッダファイルが、パケットストリームを送信するセッションの開始時に一度だけ送信される。変数値を有し得る残りのヘッダフィールドは、通常、ＲＴＰシーケンス番号の値を用いて算出される。よって、大半の場合において、ＲＴＰシーケンス番号のみが各パケットとともに送信されなければならない。従って、ヘッダフィールドの大半の値は、ＲＴＰシーケンス番号から算出されるか、または以前に送信されて格納された値を用いて単純に解凍される。
【０００９】
以下、ＲＴＰシーケンス番号を圧縮し、送信する方法を述べる。なお、ここでは、ＲＴＰシーケンス番号をシーケンス番号と呼ぶことにする。
【００１０】
ヘッダデータを圧縮する上述のアプローチに対応して、シーケンス番号もまた、必要とされる場合に個別に送信するために、定数部および変数部に分割することによって圧縮される。シーケンス番号の最上位ビットは、一度だけでデコンプレッサに転送され、定数部として選択される。反対に、シーケンス番号の最下位ビットは、各パケットとともにデコンプレッサに送信されなければならない、変数部または圧縮シーケンス番号を表わす。コンプレッサおよびデコンプレッサは、変化し得る圧縮シーケンス番号を基準として格納されたシーケンス番号に加えることによって、各パケットごとにシーケンス番号を算出する。
【００１１】
最初に、共通の基準を確立するために、圧縮されていないシーケンス番号が、ＣＲＣを含むパケットで送信される。ＣＲＣは、解凍されたパケットを検証するため、例えば、圧縮パケットにおけるビットエラーを検出するために用いられる。デコンプレッサがパケットを解凍することができ、そのパケットの正当性を検証すると、解凍されたシーケンス番号を含む確認応答（ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）をコンプレッサに送る。この確認されたシーケンス番号は、共通の基準シーケンス番号として用いられる。
【００１２】
【非特許文献１】
Ｃ．Ｂｏｒｍａｎｎ等、“Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）”、［ＲＦＣ３０９５］、Ｊｕｌｙ ２００１
【００１３】
【発明が解決しようとする課題】
よって、確認応答を受信後、入力シーケンス番号は、コンプレッサによって圧縮され得る。しかしながら、コンプレッサは、確認されたシーケンス番号の後に圧縮され、送られたシーケンス番号のウインドウを維持しなければならない。従って、初期のウインドウは、確認されたシーケンス番号のみを含む。圧縮シーケンス番号は、その最下位ビットに依存する。すでに送信されたシーケンス番号のウインドウに基づいて、コンプレッサは、そのシーケンス番号を一意的に特定するために、最下位ビット（ＬＳＢ）がいくつ必要であるかを算出する。よって、ＬＳＢの数は、ウインドウ内のパケット数とともに増加する。最小数のＬＳＢが判明した後、コンプレッサは、少なくとも算出された数のシーケンス番号に必要なビットを含むパケットタイプを選択しなければならない。上記の第３のモード、または信頼性のあるモードでは、最小のパケットは、そのシーケンス番号の６個のＬＳＢを含む。
【００１４】
次いで、パケットがデコンプレッサに送られ、シーケンス番号がウインドウに加えられる。しかしながら、ウインドウのサイズによってＬＳＢの最小数が大きくなるにつれて、パケットサイズも同様に増大する。
【００１５】
コンプレッサは、すでに最適でない可能性があり得る最小パケットサイズの送信を継続するか、あるいは少数のより大きなＣＲＣを有するパケットを送ることによって、ウインドウのサイズを減少することを決定し得る。ＣＲＣを有するパケットを送ることによって、コンプレッサは、新たな共通の基準を確立し始める。これに応じて、さらなるＣＲＣバイトは、基準シーケンス番号の再初期化を受信機に示す。
【００１６】
ＣＲＣパケットがデコンプレッサに送信され、正常に解凍されると、解凍されたシーケンス番号を含む確認応答を送信機内のコンプレッサに送信する。さらに、受信機は、以前のパケットの全てをウインドウから除去し、解凍されたシーケンス番号を新たな基準シーケンス番号として用いる。
【００１７】
受信機から確認応答を受信すると、コンプレッサは、そのウインドウから、確認されたパケットの前に送られたパケットの全てを除去する。後続のパケットの圧縮のために、必要な最下位ビットの最小数を低減する、より小さなウインドウサイズが用いられ得る。
【００１８】
コンプレッサは、再初期化処理を開始したいシーケンス番号の値を決定しなければならない。しかしながら、大きすぎるシーケンス番号で再初期化処理を開始する場合、ビットレートは浪費される。これは、パケットのパケットサイズが増大するためである。一方、小さすぎるシーケンス番号で再初期化処理を開始する場合、ビットレートは浪費される。これは、送られる再初期化を示すパケットが多すぎるためである。よって、各場合において、ビットレートが浪費されるため、従来技術によるシステムは非効率に動作する。
【００１９】
それゆえ、本発明の目的は、送信効率の点で、特に、再初期化処理に関して最適化された圧縮ヘッダデータを送信する改善された方法、送信機、およびシステムを提供することである。
【００２０】
【課題を解決するための手段および発明の効果】
上記目的は、独立請求項の主題によって解決される。従属請求項は、本発明の好適な実施形態を記載している。
【００２１】
本発明では、圧縮するヘッダデータアイテムの値を再初期化する再初期化処理を実行するために必要な期間が推定され、再初期化処理を開始するための最適時間を判定するために用いられる。再初期化処理の期間を推定することによって、再初期化処理は、限界シーケンス番号（ｃｒｉｔｉｃａｌ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を含む入力パケットが送信されることが必要となる直前に、処理が完了する時間に開始され得る。よって、平均ヘッダサイズは低減され、圧縮の効率が増加し、ビットレートの浪費が避けられる。
【００２２】
本発明による方法の有利な実施形態では、再初期化を示すパケットを受信機に送信してこのパケットの確認応答を受信する間の時間が測定され、この測定された時間が、再初期化処理に必要な期間を推定するために用いられる。受信機における処理処理時間がパケット送信のセッション中は安定したままであると仮定すると、その期間は確実に推定され得る。
【００２３】
本発明によるさらに改善された方法では、ヘッダデータアイテムの値が限界値に達することが予想される限界時間が推定され、再初期化処理を開始するための最適時間が、推定された再初期化処理の期間を限界時間から減算することによって判定される。本方法は、特に、ちょうど最適化された時間に再初期化処理を開始するように適合する。
【００２４】
本発明による方法のさらに有利な実施形態は、コンプレッサ内に格納された送信機と受信機との間のリンク状況に関する情報に従って、消失したパッケージの再送信に必要な時間を推定する。よって、既存の情報を用いることによって、最適時間の推定がさらに改善され得る。
【００２５】
【発明の実施の形態】
以下に、添付の図面を参照して、本発明の好適な実施形態を説明する。
図２〜図５に示す方法は、図１に示すような送信機で実行される。
【００２６】
図２は、圧縮ヘッダデータをパケットのストリームで送信機から受信機に送信する方法を示すフローチャートである。ヘッダデータは、好ましくは、ＲＯＨＣアルゴリズムを用いて圧縮される。ここで、ヘッダデータアイテムは、以下においてシーケンス番号と呼ばれるＲＴＢシーケンス番号である。
【００２７】
工程２１で、図３によって詳細が明らかにされる初期化処理が実行される。
【００２８】
その後、転送されるパケットのシーケンス番号が工程２２で判定され、工程２３で圧縮される。圧縮する工程２３では、シーケンス番号の最下位ビットを圧縮シーケンス番号として使用する工程、またはシーケンス番号の最下位ビットから同じものを導出する工程を含み得る。よって、最上位ビット、またはシーケンス番号の全体が、それぞれ、基準シーケンス番号として用いられる。
【００２９】
再初期化チェックを実行する工程２４では、圧縮シーケンス番号を含むパケットを送る工程２６を実行することによってパケットを送信する通常の処理を継続するべきか、またはシーケンス番号の値を再初期化する再初期化処理を実行する工程２５に分岐するべきかをチェックする。
【００３０】
第１のケースでは、圧縮シーケンス番号を含むパケットが工程２６で送信される。工程２７において、送信される次のパケットが存在するか否かが判断され、存在する場合、次のパケットのシーケンス番号を判定する工程２２で継続処理される。
【００３１】
再初期化チェック２４では、再初期化処理を開始する時間が判定される。これに応じて、再初期化処理は、現在の時間ｔが判定された最適時間（ｔｏｐｔ）：
ｔ≧ｔｏｐｔ
に達したか、またはそれを超過したときに開始される。
【００３２】
最適時間を判定するために、再初期化処理を実行するために必要な推定期間（ｔｉｎｉｔ）が用いられる。
【００３３】
図３は、工程３０〜３７を含む初期化処理を示すフローチャートである。最初に、定数値を有するヘッダデータアイテムが工程３１で判定される。その後、初期シーケンス番号（ＳＮ）が工程３２で判定される。次に、工程３３において、圧縮ヘッダデータが送信機から受信機に送信される。送信されたヘッダデータは、定数ヘッダデータアイテム、および初期シーケンス番号を含む。受信機は、受信したパケットを解凍し、その中に含まれるＣＲＣを検証する。初期シーケンス番号を基準シーケンス番号として格納し、初期シーケンス番号を含む確認応答を送信機に送る。送信機は、工程３４で、初期シーケンス番号の確認応答を受信する。さらに、工程３６で、初期シーケンス番号は、基準シーケンス番号として送信機に格納される。
【００３４】
再初期化処理を実行するために必要な期間を推定するために、送信機は、工程３５で、ヘッダデータの送信から確認応答の受信までの期間を測定する。
【００３５】
次に、図２の再初期化チェック２４および再初期化処理２５を、それぞれ、図４および図５を参照してより詳細に説明する。
【００３６】
図４は、工程４０〜４６を含む再初期化チェックを示すフローチャートである。最初に、工程４１で、現在の基準シーケンス番号（ＳＮｒｅｆ）に関して、最大シーケンス番号（ＳＮｍａｘ）が判定される。ＳＮｍａｘは、対応する圧縮シーケンス番号（ＣＳＮ）が最小パケットタイプに適合する最大シーケンス番号を表わす。よって、圧縮ＣＳＮｍａｘがパケット内にｋ個のビットを必要とする場合、ＣＳＮｍａｘ＋１は、後続のパケットの各々に少なくともｋ＋１個のビットを必要とする。
【００３７】
圧縮シーケンス番号に必要な最小数のビット（ｋ）は、以下の式：
ｋ＝［ｌｏｇ_２ （ＳＮｍａｘ−ＳＮｒｅｆ）］
によって判定され、この式は、
ＳＮｍａｘ＝ＳＮｒｅｆ＋２ｋ
に変換され得る。
【００３８】
例えば、ＲＯＨＣの信頼性のあるモードでは、ｋは６に等しい。
【００３９】
ｋは所定値であるため、最大シーケンス番号は、ＳＮｒｅｆが分かるとすぐに算出され得る。よって、この計算は工程４１で実行され得るが、それ以前に、図３に示す初期化処理でも実行され得る。
【００４０】
最大シーケンス番号の情報に基づいて、限界時間（ｔｍａｘ）が４２で判定される。限界時間（ｔｍａｘ）は、最大シーケンス番号に達する可能性がある時間を表わす。
【００４１】
一般に、パケットは、ほぼ線形の時間−シーケンス番号の関係でコンプレッサに到達し、シーケンス番号は、一般に、一定の段階で増大する。よって、コンプレッサは、以下の式：
ｔｍａｘ＝ｔｎｏｗ＋（ＳＮｍａｘ−ＳＮｎｏｗ）Ｔ
に従って、必要なビット数が最小パケットタイプのビット数を超過する時間を推定し得る。ここで、ｔｍａｘはシーケンス番号ＳＮｍａｘを有するパケットの推定到達時間を示し、ｔｎｏｗは現在の時間であり、Ｔは入力パケット間の推定平均時間である。
【００４２】
限界時間を修正する工程４３では、再初期化処理に関して予想され得る変動を補償するようにさらに低減され得る。限界時間は、例えば、消失したパケットの再送に必要な推定時間を反映する予想再送期間に従って、低減される。再送期間を推定するために、好ましくは、圧縮アルゴリズムで用いられるコンプレッサに格納される現在の送信条件が推定される。限界時間の修正はまた、入力パケットストリーム内のパケットの到達時間の変動、および／または、例えば、デコンプレッサにおける処理時間を変動させることによって生じ得るｔｉｎｉｔをさらに考慮し得る。従って、限界時間がさらに低減され得る。
【００４３】
最終的に再初期化処理を開始する時間を判定するために、工程４４で、対応する最適時間（ｔｏｐｔ）が算出される。
【００４４】
ｔｏｐｔは、サイズが増大したパケットを送信する前に再初期化処理を完了することが可能になるように選択されなければならない。よって、ＳＮｍａｘは、再初期化以前に用いられた最後のシーケンス番号であるべきである。次のパケットは、時間ｔｍａｘ＋Ｔに送信されなければならない。他の実施形態では、限界時間は、シーケンス番号ＳＮｍａｘ＋１（ｔｍａｘ［ＳＮｍａｘ＋１］＝ｔｍａｘ＋Ｔ）を有するパケットの到達時間として定義され得る。
【００４５】
従って、最適時間は、シーケンス番号ＳＮｍａｘ＋１を有するパケットの判定された到達時間から再初期化処理を実行する推定期間（ｔｉｎｉｔ）を減算することによって算出される。
ｔｏｐｔ＝（ｔｍａｘ＋Ｔ）−ｔｉｎｉｔである。
【００４６】
その後、工程４５で、現在の時間が最適時間に達したか、またはそれを超過したかがチェックされ得る。
【００４７】
上記から明白なように、限界時間を修正する工程４３は、再初期化処理を実行するために必要な推定期間を修正する対応する工程に置き換えられてもよい。よって、再初期化処理２５および／または初期化処理２１でも実行され得る。
【００４８】
最適時間に達した場合、図５により詳細に示す再初期化処理が開始される。
【００４９】
工程５１において、ＣＲＣおよびシーケンス番号を含むパケットが、送信機から受信機に送られる。次に、工程５２において、シーケンス番号を含む受信機の確認応答が受信される。工程５３において、送信工程５１と受信工程５２との間の時間が測定される。工程５４において、測定された時間に基づいて、再初期化処理の平均時間が判定される。最後に、工程５５において、確認されたシーケンス番号が、基準シーケンス番号として格納される。
【００５０】
より詳細には、測定する工程５３のために、コンプレッサは、ＣＲＣパケットが送られた時間（ｔｃｒｃ）、さらには、そのシーケンス番号も格納する。確認応答の時間（ｔａｃｋ）およびシーケンス番号もまた格納される。確認応答を受信した後、コンプレッサは、例えば、重みつき平均：
ｔｉｎｉｔ＝０の場合、ｔｉｎｉｔ＝ｔａｃｋ−ｔｃｒｃ、
それ以外の場合、ｔｉｎｉｔ＝（１−α）・ｔｉｎｉｔ＋α・（ｔａｃｋ−ｔｃｒｃ）、
として、期間（ｔｉｎｉｔ）の新たな推定値を算出する。
【００５１】
重み係数αは、現在測定された時間の実行平均推定値に対する影響を示す。しかしながら、代わりに、任意のタイプの平均計算が用いられ得る。さらに、ｔｉｎｉｔは、最初に、初期化処理中に設定され得る。平均時間ｔｉｎｉｔを判定する工程５４は、再初期化チェック中に実行されてもよい。
【００５２】
パケットを送信して往来させるために必要な時間に対応する往復の時間を単に判定する代わりに、上述した測定する工程５３は、推定期間にデコンプレッサにおける処理時間をさらに考慮している。この処理時間は、デコンプレッサでＣＲＣパケットを受信し、対応する確認応答をデコンプレッサから送る間の時間を含む。処理時間は、一般に、送信機内のコンプレッサには認識されないが、再初期化処理に必要な時間を推定するために考慮されなければならない。圧縮セッション中、その環境は変化しないため、デコンプレッサにおける処理時間は一定である可能性がある。従って、推定平均時間ｔｉｎｉｔは信頼性があると想定され得る。
【００５３】
図２〜図５を参照して、例示的な条件を用いて、好適な実施形態を説明した。すでに示したように、工程のうちのいくつかは、処理の異なる場所で実行され得る。しかしながら、下記より明らかなように、上述の特徴は、さらなる実施形態の種々の構成に変更され得る。
【００５４】
本発明による方法は、一般に、そのシステムにおいて最適化された効率のために再初期化処理を必要とするシステムに適用され得る。例えば、ヘッダデータアイテムは、再初期化されなければサイズが増大する、送信される任意の可変データアイテムであり得る。さらにまた、限界値は、ヘッダデータアイテム自体の値である必要はないが、例えば、実行されるアルゴリズムの限界複雑性によっても表わされ得る。ここで、アルゴリズムの複雑性は、ヘッダデータアイテムの再初期化によって低減される。
【００５５】
さらに、再初期化処理では、ヘッダデータアイテムの値は所定の初期値に設定され得るが、ヘッダデータアイテムの現在値、またはその最上位ビットに設定されてもよい。従って、ヘッダデータアイテムの基準値として格納された値は、シーケンス番号の最上位ビットによってか、またはシーケンス番号自体によって形成され得る。好ましくは、圧縮アルゴリズム、および基準値は、再初期化することなく、できる限り多くのパケットが送信されることが可能となるように選択される。さらに、ヘッダデータアイテムの値の最下位ビットの数は、最小または適切なパケットタイプで利用可能なビット数に従って判定され得る。
【００５６】
本発明による方法を実行するために用いられ得る図１のシステムは、必要とされる基本的な機能要素のみを示す。しかしながら、送信機１は、通常、送信される入力パケットを受信する入力部、コントローラ、およびコンプレッサの一部であり得る格納ユニット等の図示されないユニットをさらに備える。さらに、送信機１および受信機２は、パケット送信のために、有線または無線リンクを介して接続され得る。
【００５７】
本発明に従って構成された好適な物理的実施形態に関して本発明を説明したが、上記の教示を鑑み、特許請求の範囲を予め参照することによって、本発明の精神および意図された範囲を逸脱することなく、本発明の種々の修正、変更、および改善がなされ得ることは当業者には明らかである。また、本明細書中に記載された発明を不必要に不明瞭にしないため、本明細書中においては、当業者が精通していると思われる領域は説明していない。従って、本発明は、特定の例示的実施形態によって限定されるべきでなく、特許請求の範囲によってのみ限定されることが理解される。
【図面の簡単な説明】
【図１】送信機および受信機を備える、圧縮ヘッダデータの送信用の典型的なシステムを示す図である。
【図２】本発明の好適な実施形態による送信機から受信機にパケットを送信する方法のフローチャートである。
【図３】図２の処理で実行される初期化処理のフローチャートである。
【図４】図２の処理で実行される再初期化チェックのフローチャートである。
【図５】図２の処理で実行される再初期化処理のフローチャートである。
【符号の説明】
１ 送信機
２ 受信機
３ コンプレッサ
４，８ 送信ユニット
５，６ 受信ユニット
７ デコンプレッサ

Claims (13)

1. 圧縮ヘッダデータをパケットストリームで送信機から受信機に送信する方法であって、
   ヘッダデータはヘッダデータアイテムを含んでおり、
   圧縮される前記ヘッダデータアイテムの値を再初期化する再初期化処理を実行するために必要な期間を推定する工程と、
   当該推定された期間に基づいて、前記再初期化処理を開始する時間を判定する工程と、
   当該判定された時間が到来したら前記再初期化処理を開始する工程とを含む、方法。
2. 前記ヘッダデータは、ＲｏＨＣ（ロバストヘッダ圧縮）アルゴリズムを用いて圧縮され、前記ヘッダデータアイテムは、ＲＴＰ（リアルタイム伝送プロトコル）シーケンス番号である、請求項１に記載の方法。
3. 前記再初期化処理を開始する工程は、ＣＲＣエレメントを含む再初期化パケットを送信する工程を有しており、当該ＣＲＣエレメントは少なくとも前記圧縮ヘッダデータアイテムに関して算出される、請求項１に記載の方法。
4. 前記推定する工程は、
   前記ヘッダデータアイテムを再初期化するために、前記受信機にパケットを送信する工程と、
   前記受信機から確認応答を受信する工程とを有する、請求項１に記載の方法。
5. 前記期間を推定する工程は、さらに、
   再初期化を示すパケットを送信して前記確認応答を受信する間の時間を測定する工程を有する、請求項４に記載の方法。
6. 前記期間を推定する工程は、さらに、
   前記測定する工程の結果に基づいて、前記再初期化処理の平均所要時間を判定する工程を有する、請求項５に記載の方法。
7. 前記再初期化処理を開始する時間を判定する工程は、
   前記ヘッダデータアイテムの値が限界値に達することが予想される限界時間を推定する工程を有する、請求項１に記載の方法。
8. 前記再初期化処理を開始する時間を判定する工程は、さらに、
   前記限界時間から前記推定された時間を減算する工程を有する、請求項６に記載の方法。
9. 前記限界時間を推定する工程は、
   前記ヘッダデータアイテムの限界値から現在の値を減算する工程と、
   当該減算結果に当該ヘッダデータアイテムの値が変化しないままであることが予想される時間を表わす値を乗算する工程とを有する、請求項７に記載の方法。
10. 前記再初期化処理を開始する時間を判定する工程は、さらに、
    前記推定された限界時間を修正することにより、前記再初期化処理に関して、起こり得る時間変動を補償する工程を有する、請求項７に記載の方法。
11. 前記限界時間を修正する工程は、前記送信機と前記受信機との間の現在の送信条件を評価することによって、消失したパケットを再送するために必要な再送期間を推定する工程を有する、請求項１０に記載の方法。
12. 圧縮ヘッダデータをパケットストリームで受信機に送信する送信機であって、
    ヘッダデータはヘッダデータアイテムを含んでおり、
    圧縮される前記ヘッダデータアイテムの値を再初期化する再初期化処理を実行するために必要な期間を推定する手段と、
    当該判定された時間に基づいて、前記再初期化処理を開始する時間を判定する手段と、
    当該判定された時間が到来したら前記再初期化処理を開始する手段とを備える、送信機。
13. 圧縮ヘッダデータをパケットストリームで受信機に送信する送信機を備えたシステムであって、
    ヘッダデータはヘッダデータアイテムを含んでおり、
    前記送信機は、
    圧縮される前記ヘッダデータアイテムの値を再初期化する再初期化処理を実行するために必要な期間を推定する手段と、
    当該判定された時間に基づいて、前記再初期化処理を開始する時間を判定する手段と、
    当該判定された時間が到来したら前記再初期化処理を開始する手段とを含み、
    少なくとも１つの受信機を備える、システム。

Images