JP2013243690A - サイレント抑圧時のｒｏｈｃパフォーマンスを向上させる方法と装置 - Google Patents

Abstract

【課題】サイレント抑圧を行うときのロバストヘッダーコンプレッション（ＲｏＨＣ）圧縮器のパフォーマンスを向上させる。
【解決手段】連続するパケットについて所定数のパケットが一定のタイムスタンプインクリメント値を有するようになるまでＲＴＰタイムスタンプインクリメントが計算される。この一定のＲＴＰタイムスタンプインクリメント値はタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として圧縮のために割り当てられ、各ＲＴＰタイムスタンプ（ＴＳ）値はタイムスタンプストライド（ＴＳ＿ＳＴＲＩＤＥ）により縮尺され、ヘッダーをこの割り当てられた値を用いて圧縮する。
【選択図】図１５

Description

本発明は通信システムに係り、特にこの明細書の実施形態ではサイレント抑圧時の強力なヘッダー圧縮（ＲＯＨＣ）用の圧縮器のパフォーマンスを向上させる方法と装置に関する。

インターネットプロトコル（ＩＰ）は送信プロトコルとして有線および無線のネットワークを必要とし、特に遠距離通信およびデータのネットワークの必要性が増してきている。プロトコルヘッダーの圧縮について多くの努力が為されているが、その努力はヘッダー圧縮方式の有効且つ強力な開発に向けられている。

本出願は、“サイレント抑圧時のＲＯＨＣパフォーマンスを向上させる方法と装置”と題して２００６年１月６日に出願され本譲受人に譲渡された米国特許仮出願番号６０／７５６，６５８号の優先権の利益を主張する。

以下に開示される実施形態はサイレント圧縮に関してロバストヘッダーコンプレッション圧縮器（ＲｏＨＣ）のパフォーマンスを向上させるための方法とシステムに関する。これらの実施形態は、携帯電話ネットワーク、公衆電話回線（ＰＳＴＮｓ）、無線インターネット、衛星ネットワーク、広域ネットワーク（ＷＡＮｓ）、無線ローカルエリアネットワーク（ＷＬＡＮｓ）、ＶｏＩＰネットワーク、ＩＰ準拠マルチメディアシステムなどのような無線、有線通信システムに用いることができる。

図１は通信システムにおけるフレームとパケットとを示す。 図２はヘッダー圧縮の一例を示す。 図３は通信システムの一例を示す。 図４はＢＴＳ−ＲＮＣ−ＰＤＳＮのハードウエアとソフトウエアの例を示す。 図５はアクセス端末のハードウエアとソフトウエアの例を示す。 図６はパケットストリーム中の一連のパケットを示す。 図７Ａは会話の一連のパケットを示す。 図７Ｂは６個の一連のパケットで示された会話セグメントを示す。 図８は一実施形態におけるサイレント抑圧の例を示す。 図９は他の実施形態におけるサイレント抑圧の例を示す。 図１０はＴＳ−ＳＴＲＩＤＥの変化を示す。 図１１はＲｏＨＣのパフォーマンスを向上させるように構成されたプロセスの一例を示す。 図１２はＡＭＲ中の一連の会話の期間とサイレントの期間とを示す。 図１３はＲｏＨＣのパフォーマンスを向上させるように構成されたプロセスの一例のフローチャートを示す。 図１４は図１３の方法に対応する手段を示す。 図１５はＲｏＨＣのパフォーマンスを向上させるように構成されたプロセスの他の例のフローチャートを示す。 図１６は図１５の方法に対応する手段を示す。

多くのサービスおよびアプリケーション、たとえばＩＰ電話（ＶｏＩＰ）、ビデオ電話、双方向ゲーム、伝言サービスなどにおいて、データはパケット状にされてネットワークを介して送信される。以下の説明ではフレームとは通信システム上に送信されるようにフォーマットされたデータフレームの部分を意味する。図１に幾つかのパケット１０２とフレーム１０４とを示す。フレーム１０４は適切な時間幅、例えば２０ｍｓｅｃを有し、パケット１０２の時間幅と同じでも良いし、または異なる時間幅でも良い。各パケットは通常はヘッダー内に含まれた割り当てアドレスに従ってその目的とするネットワーク上の送り先に送信される。ヘッダーはパケットの開始を指定し、トレイラはパケットの終了を指定し、「ペイロード」はパケットのデータ部を指定する。パケットはインターネットプロトコル（ＩＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、リアルタイムトランスポートプロトコル（ＲＴＰ）、およびトランスミッションコントロールプロトコル（ＴＣＰ）ヘッダーのような種々の形式のヘッダーを持つことができる。ある種の方法では、ＩＰパケットのペイロードはヘッダーと同等のサイズ或いはヘッダーより小さくても良い。

ランドラインまたはワイヤラインシステムにおいて、バンド幅についての制限は少なく、パケット全体を連続して送信することによりデータ通信を行うことができる。しかしながら無線通信システムにおいてはバンド幅に制限があり、データを保護する必要がある。パケットのオーバーヘッドの縮小はパケットヘッダーのサイズを縮小することにより実現することができる。ヘッダーを圧縮することによりネットワーク通信の品質、速度および効率を向上させることができる。さらに、このヘッダー圧縮により双方向応答速度が向上し、一定のチャネルバンド幅内でより多くのユーザが利用可能となる。このことにより拡大コストの減少がもたらされる。図２は音声通信システムにおけるヘッダー圧縮の一例を示す。この例においては４０バイト以上の非圧縮ヘッダーがオーバーヘッドに付加されている。ヘッダー圧縮により、オーバーヘッドは２−４バイトとなっている。このヘッダー圧縮により、ネットワークにおける必要なバンド幅の維持が可能となる。

図３は通信システム３００の一例を示し、ここではこの発明における一つまたは複数の方法が示されている。第１のアクセス端末（ＡＴ）３０１Ａはリバースリンク（またはアップリンク）ヘッダー圧縮器３０２を含む。この第１のアクセス端末３０１Ａは無線により、リバースリンク（ＲＬ）を介して基地局３０４Ａと通信を行い、さらにラジオアクセスネットワーク（ＲＡＮ）内の基地局送受信システム／パケットデータ供給ノード（ＢＴＳ−ＲＮＣ−ＰＤＳＮ）３０６Ａと通信を行う。

ＢＴＳ−ＲＮＣ−ＰＤＳＮ３０６Ａはリバースリンクヘッダー伸長器３１０を含み、これは以下に説明する一つまたは複数の方法を実施することができる。ＢＴＳ−ＲＮＣ−ＰＤＳＮ ３０６Ａはパケットデータ供給ノード／基地局送受信システム（ＰＤＳＮ−ＢＴＳ）３０６ＢとＶｏＩＰネットワーク３１２を介して通信を行う。このＰＤＳＮ−ＢＴＳ ３０６Ｂはフォワードリンク（またはダウンリンク）ヘッダー圧縮器３１２を含む。

基地局３０４ＢとＰＤＳＮ−ＢＴＳ ３０６Ｂは第２のアクセス端末３０１Ｂとフォワードリンクを介して無線で通信を行うことができる。この第２のアクセス端末３０１Ｂはフォワードリンクヘッダー伸長器３１４を含み、以下に説明する一つまたは複数の方法を実施することができる。２個の無線アクセス端末３０１Ａ，３０１Ｂを用いる代わりに、そのうちの１個を有線アクセス端末としてもよい。リバースリンクヘッダー圧縮器３０２とリバースリンクヘッダー逆圧縮器３１０とは第１の圧縮器−伸長器ペアを構成する。フォワードリンクヘッダー圧縮器３１２とフォワードリンクヘッダー伸長器３１４とは第２の圧縮器−伸長器ペアを構成する。

リバースリンクとフォワードリンクとは一つまたは複数の通信プロトコル、例えば符号分割多重接続（ＣＤＭＡ）１ｘ、ＣＤＭＡ１ｘＥＶ−ＤＯ（エボリュウション・データ・オプティマイズド）、ワイドバンドＣＤＭＡ（ＷＣＤＭＡ（登録商標））、時間分割同期（ＴＤ−ＳＣＤＭＡ）、グローバルシステム用モバイル通信（ＧＳＭ（登録商標））、ＯＦＤＭ（直交周波数分割多重）、ＩＥＥＥ標準に準拠したシステム、例えば８０２．１１（Ａ，Ｂ，Ｇ）、８０２．１６などを用いることができる。

ここで、「アクセス端末」とは種々の形式の装置を意味し、例えば、有線電話、携帯電話、ラップトップコンピュータ、無線通信パーソナルコンピュータ（ＰＣ）カード、パーソナルデジタルアシスタント（ＰＤＡ）、外付けモデム、内蔵モデムなどである。アクセス端末は、たとえば光ケーブルまたは同軸ケーブルを用いた無線チャネルまたは有線チャネルを介して通信を行うどのようなデータ装置であってもよい。アクセス端末は多くの名前を持ち、それらはアクセスユニット、加入者ユニット、モバイルステーション、モバイル装置、モバイルユニット、モバイル電話、モバイル、リモートステーション、リモート端末、リモートユニット、ユーザ装置、ユーザ設備、携帯装置などである。アクセス端末は携帯型または固定型であり、図３の通信システム３００内で分散されている。アクセス端末は一つまたは複数の基地局送受信システム（ＢＴＳｓ）と交信を行い、このシステムは基地局、アクセスネットワーク、アクセルポイント、ノードＢｓ、またはモデムプールトランシーバ（ＭＰＴｓ）などと呼ばれ、あるいはこれらを含むものである。

図４は図３に示したＢＴＳ−ＲＮＣ−ＰＤＳＮ３０６Ａおよび／またはＰＤＳＮ−ＢＴＳ３０６Ｂのハードウエアおよびソフトウエアの幾つかの例を示す。その一つの例ではプロセッサ４００、アプリケーションスペシフィック集積回路（ＡＳＩＣ）４０２、トランシーバ４０４、およびメモリ４０６を含む。メモリ４０６は一つまたは複数の上位レイヤー、たとえばアプリケーションレイヤー４０８、トランスポートレイヤー４１０、およびネットワークレイヤー４１２を記憶する。アプリケーションレイヤー４０８はリアルタイムトランスポートプロトコル（ＲＴＰまたはＲＴＣＰ）のヘッダーを処理する。トランスポートレイヤー４１０はトランスミッションコントロールプロトコル（ＴＣＰ）およびユーザデータグラムプロトコル（ＵＤＰ）のヘッダーを処理する。ネットワークレイヤー４１２はＩＰのヘッダーを処理する。

メモリ４０６は更に、ロバストヘッダーコンプレッション圧縮器３１２およびロバストヘッダーコンプレッション伸長器３１０を記憶する。ロバストヘッダーコンプレッション圧縮器３１２はタイムスタンプ計算ユニット３１２Ａを記憶でき、また、ロバストヘッダーコンプレッション伸張器３１０はタイムスタンプ計算ユニット３１０Ａを記憶することができる。メモリ４０６は更に、一つまたは複数の下位レイヤー４２０、例えばリンクレイヤー媒体アクセス制御（ＭＡＣ）レイヤー４１４を記憶することができ、このレイヤー４１４はラジオリンクプロトコル（ＲＬＰ）サブレイヤーを含むことができる。この下位レイヤー４２０は物理レイヤー４１６を含むこともできる。

図５は図３に示したアクセス端末３０１Ａ、３０１Ｂのハードウエアおよびソフトウエアの幾つかの構成を示す。その一つは、プロセッサ５００、ＡＳＩＣ５０２、トランシーバ５０４、メモリ５０６などを含む。メモリ５０６はアプリケーションレイヤー５０８、トランスポートレイヤー５１０、ネットワークレイヤー５１２などの一つまたは複数の上位レイヤーを含む。アプリケーションレイヤー５０８はＲＴＰヘッダーを処理する。トランスポートレイヤー５１０はＴＣＰおよびＵＤＰヘッダーを処理する。ネットワークレイヤー５１２はＩＰヘッダーを処理する。

メモリ５０６はロバストヘッダーコンプレッション圧縮器３０２およびロバストヘッダーコンプレッション伸張器３１４とを記憶することができる。ロバストヘッダーコンプレッション圧縮器３０２はタイムスタンプ計算ユニット３０２Ａを記憶し、ロバストヘッダーコンプレッション伸張器３１４はタイムスタンプ計算ユニット３１４Ａを記憶することができる。メモリ５０６はリンクレイヤーＭＡＣレイヤー５１４のような一つまたは複数の下位レイヤー５２０を記憶することができ、このレイヤー５１４はＲＬＰサブレイヤーを含むことができる。下位レイヤー５２０は物理レイヤー５１６を含むこともできる。

ＲｏＨＣはヘッダー圧縮機構であって、ＲＴＰ／ＵＤＰ／ＩＰヘッダーを効率的に圧縮することができる。ロバストヘッダー圧縮については、リクエストフォーコメント（ＲＦＣ）３０９５に「ロバストヘッダーコンプレッション（ＲＯＨＣ）：フレームワークおよび４つのプロファイル：ＲＴＰ、ＵＤＰ、ＥＳＰおよび伸張」として記載されており、これは、２００１年７月に、インターネットソサエティのネットワークワーキンググループによりインターネットスタンダードトラックプロトコルとして頒布されている。

一般に、リンク上を伝送されるパケットは互いに独立したものではなく、例えばソースアドレス、目的地アドレス、などの特定の共通なパラメータを共有している。ヘッダー圧縮は、同じパケット内の、または同じパケットストリームに属する連続するパケット間のヘッダーフィールド内の有効リダンダンシーによって可能となる。「パケットストリーム」とは連続するパケットを意味し、通常は、音声パケットストリームまたはビデオパケットストリームなどの論理的にグループ化されたパケット群である。ＲｏＨＣアルゴリズムはパケットストリーム中の共通パラメータを用いて一部の状態情報を保持した状態でパケットヘッダーを圧縮する。この状態情報は「コンテクスト」と称される。

圧縮器−伸張器のペアは各パケットストリームに対してそれぞれコンテクストを持っている。各パケットストリームのコンテクストは圧縮器と伸張器において同じコンテクスト同定フィールド（ＣＩＤ）によって同定される。例えば、図３のＲＬヘッダー圧縮器３０２とＲＬヘッダー伸張器３１０とは特定の音声フロー「ＶＦ１］に対してコンテクスト「ＣＩＤ１」をそれぞれ有する。このコンテクストは、パケットストリーム中の先行ヘッダーからの情報と圧縮と伸張のための有効な参照値を有する。パケットストリームを表すデータ、例えばＩＰ特定フィールドがどのように変化したかおよび順次番号（ＳＮ）またはタイムスタンプ（ＴＳ）における中間のパケットがどのように増加したかの情報がコンテクスト内に含まれる。ロバストヘッダー圧縮機構を確認するためにはコンテクストの不一致を回避する機構と、不一致のときにコンテクストを一致させる機構とが必要である。

最初に、圧縮器と伸張器とが任意のパケットストリームについてその圧縮と伸張の動作に不一致が生じることがある。圧縮器はパケットストリームに関するスタティックおよびダイナミック情報を有するＲｏＨＣパケットを伸張器に送ってコンテクストを形成する。スタティックとダイナミックフィールドの双方が設定されると、圧縮器は最小の情報を送って圧縮されたヘッダーフィールドを通常の順序に進める。圧縮器と伸張器とは所定のイベント毎にそのコンテクストを更新させる。

スタティックヘッダーフィールドは、これらのフィールドがその後一定に保持されるので、コンテクストの確定のときにのみ送信される。ヘッダーフィールドのダイナミック部分の圧縮にはより複雑なアルゴリズムが必要である。ダイナミックヘッダーフィールドはＲｏＨＣアルゴリズムによって直接に圧縮され、伸張される。しかしながら、増加ＳＮまたはＴＳのような他のフィールドのリニア関数を用いてヘッダーフィールドを更に効率的に圧縮または伸張することができる。この方法はより少ないビット数で実現できる。スタティックフィールド情報を最初に送ることにより、他のフィールドに対する従属関係と予測性とを用いることにより、ヘッダーサイズは多くのパケットについて大きく減少させることができる。

ＲＴＰパケットのＳＮは送信されたパケットのそれぞれについてインクリメントされ、受信器によってパケット順序が再現され、パケットロスが検出されるように使用される。ＴＳはＲＴＰデータパケットの最初の８個のサンプリング時間を反映する。このサンプリング時間は時間に対して単調に直線的に増加するクロックから抽出することができる。音声を処理するアプリケーションにおいては、ＴＳは各音声パケット内のサンプル数に対応する一定のデルタによってインクリメントされる。例えば、ある入力装置が１６０サンプリング期間を有する音声パケットを受信すると、ＴＳは各パケットについて１６０個だけインクリメントされる。図６は１６０インクリメントの順次ＳＮとＴＳとを有するストリーム内の一連のパケットを示す。ここで、ＴＳインクリメントは一定の１６０であり、これはパケットが音声セグメントを有する場合もサイレントのセグメントを有する場合も同じである。このことはサイレンス抑圧が行われていても行われていなくても同じである。サイレンス抑圧は以下により詳細に説明される。

ＲｏＨＣ圧縮器は二つの連続して発生されるパケット間のＲＴＰ ＴＳ内のインクリメントを推定する。ＲＴＰパケットが連続する番号を有している場合、このインクリメントはＴＳ＿ ＳＴＲＩＤＥと称される。通常、同じ形式の連続するパケット間のＴＳ＿ＳＴＲＩＤＥは固定の大きさを有する。例えば、図７Ａはあるアプリケーションを示し、ＳＮ_１、...ＳＮ_６は順次ＳＮ_Ｓ、１、...６を持つ音声パケットを示す。図に示したように、各一対のパケット間のＴＳ＿ＳＴＲＩＤＥは一つのパケットとそれに先行する他のパケットとの間の差ＴＳを示す。図示したように、２個のパケット間のＴＳ＿ＳＴＲＩＤＥはＴＳ_ｊ−ＴＳ_ｉで表され、ここで、ｉおよびｊは連続するＳＮ_Ｓである。図７Ａにおいて、ＴＳ＿ＳＴＲＩＤＥ＝（ＴＳ_ｊ−ＴＳ_ｉ）＝（ＴＳ_ｋ−ＴＳ_ｊ）＝（ＴＳ_ｌ−ＴＳ_ｋ）．．．である。この一定の差の値を知ることにより、圧縮動作の前に圧縮器の縮尺のスケールを決定することができる。従って、ＲＴＰタイムスタンプフィールドの効率的な圧縮のためにパケット間のＴＳ＿ＳＴＲＩＤＥを精密に決定することが必要となる。

縮小したＲＴＰ ＴＳを使うことでより小さい値の圧縮とこれに伴うビット数が減少するためにヘッダーのオーバーヘッドが減少される。例えば、ＲＴＰ／ＵＤＰ／ＩＰにより伝送される音声を考える。８ＫＨｚでサンプリングされた２０ｍｓｅｃのパケットを形成する音声ＣＯＤＥＣでは、ＲＴＰ ＴＳは２０ｍｓｅｃ内に含まれるサンプル数、すなわち８０００＊０．０２＝１６０のサンプル数に応じて増加する。６個の連続するパケットによって表された音声セグメントが図７Ｂに示されている。ＲＴＰ ＴＳは連続するパケットの間で１６０だけ増加し、従って、最初のパケットのＲＴＰ ＴＳは１６０で、第２のパケットのＲＴＰ ＴＳは３２０、３番目のパケットのＲＴＰ ＴＳは４８０などとなる。ここで、圧縮器のダウンスケール（縮尺）のＲＴＰ ＴＳの値は１６０、３２０、４８０等の代わりに１、２、３などの値となる。後者の場合には圧縮器は１６０の変化を符号化しなければならないが、前者の場合には１の変化分を符号化すればよく、従ってビット数が減少される。一例として、ＲｏＨＣアルゴリズムはＲＴＰ ＴＳフィールドを圧縮し、ＲＴＰ ＳＮからＲＴＰ ＴＳのような他の変化フィールドに関して直線的な関係を使うことになる。

この発明の他の形態において、最下位ビット（ＬＳＢ）符号化がヘッダーフィールドの圧縮のために使用できる。このＬＳＢ符号化を用いることで、フィールド値におけるｋ個の下位ビットが全体のフィールド値の代わりに伝送される。ここで、ｋは正の整数である。伸張器はこのｋ個のビットを受信して前もって受信した値を基準として用いて元の値を復元する。この基準値は”ｖ＿ｒｅｆ”と称される。例えば、ＬＳＢ符号化を用いる場合、バイナリ数の００００１０１０（１０進数の１０に対応する）は最上位ビット（ＭＳＢ）が００００で、ＬＳＢが１０１０である。元の値の８ビットすべてを送信する代わりに、４個のＬＳＢビット１０１０を受信装置に送信することができる。この受信が問題なく行われると、伸張器はｖ＿ｒｅｆの値を用いて元のパケット値を取り出す。このｖ＿ｒｅｆの値はコンテクスト内に保存される。一つの実施形態において、ｖ＿ｒｅｆは最後の正しく伸張されたパケット値を表している。受信されたヘッダーの伸張が正しく行われた場合、伸張器のコンテクストは００００１０１０に更新され、元のパケットが復元される。この復元が正しく行われると、ｖ＿ｒｅｆが現在の正しい伸張値に更新され、記憶される。次に送信される値が００００１１１１（１０進数で１５）であるとすると、４個のＬＳＢビット１１１１が送信され、これが正しく受信されると、伸張器は現在のコンテクスト値のＭＳＢに受信した値１１１１を付加してそのコンテクストを更新し、この発生された値が判断期間内にあるか否かがチェックされる。この場合、現在のコンテクスト値は００００１０１０であり、ＭＳＢは００００である。伸張器はそのコンテクスト値を００００１１１１に更新し、元の送信されたパケット値を復元させる。

音声の符号化において、その背景雑音が音声とともに伝送される。音声の伝送が中断されると、これに伴って背景雑音も中断される。このような背景雑音の断続は通信リンクの相手側からの応答を期待するリスナーを混乱させることになる。通常は背景雑音は応答として受け取られる。サイレント期間（重複する会話全体のなかで少なくともその一つのパーティがサイレント状態の時）では、通話チャネルはこの背景雑音情報を小さいサイズのパケットを用いて伝送させる。例えば、多くのＣＤＭＡシステムは背景雑音を送信するためにサイレント期間のときに２０ｍｓｅｃ毎にパケットの８分の１の割合で連続したパケットを送信する。パケット切り替えシステムのバンド幅を維持するためにサイレント部を表すパケットの大部分が欠落させられる。このことは通信チャネルの品質を低下させることなく行われ、サイレント抑圧と称される。

アドバンスドマルチレート（ＡＭＲ）コーデックおよびエンハンスドバリアブルレートコーデック（ＥＶＲＣ）などのボコーダにおいて、データ圧縮機構が音声の符号化のために用いられている。このようなアプリケーションにおいて、送信側における背景雑音と同様な合成雑音が受信（ＲＸ）側で発生される。音声がない時は、合成雑音が送信側で推定されて受信側に断続的に送信される。これにより、受信側での合成雑音が送信側での雑音の変化に対応できる。例えばＡＭＲ符号化において、サイレント期間では推定された背景雑音がパケットに符号化され、サイレンスデスクリプター（ＳＩＤ）パケットと称される。ＳＩＤパケットとして符号化される背景雑音パラメータは８個の連続するパケットに対して計算され、ＳＩＤパケットは８個のパケット毎に受信側に送信される。従って、発生された８個の内の７個のＳＩＤパケットが送信側で効果的に欠落される。従って、サイレント期間内で、ＡＭＲコーデックはＳＩＤパケットを８＊２０＝１６０ｍｓｅｃ毎に発生させ、送信させる。このことは、通話における通常の音声パケットが２０ｍｓｅｃ毎に発生されるのと対照的である。受信側においては、有効なＳＩＤパケットが受信されたときに背景雑音の発生がスタートされ、あるいは更新される。

サイレント抑圧を行うシステムにおいて、ＲＴＰ ＴＳはサイレント期間の長さに比例してジャンプする。サイレント抑圧期間において、幾つかのパケットは欠落されるが、ＲＴＰ ＴＳはインクリメントされ続けるが、ＲＴＰ ＳＮはインクリメントされない。このことが図８に示され、ここではパケットが発生され、ＳＮが１でＴＳが１６０として分配される。このパケットは音声セグメントを表している。次に送信側で３個のパケットが欠落される。この欠落されたパケットは背景雑音を表す８分の１の割合のパケットである。図面において、欠落された３個のパケットは順次ＴＳ３２０、４８０、６４０に割り当てられる。これらは割り当てられたＳＮではない。図８において、５番目のパケットであるサイレント期間の後の通話セグメントを表すパケットが形成され、ＳＮ２が割り当てられる。この第５のパケットはＴＳのインクリメントが１６０であるので、８００のＴＳが割り当てられる。この図において、最初に受信されたパケットＳＮ＝１と最後に受信されたパケットＳＮ＝２との間のＴＳ＿ＳＴＲＩＤＥは８００−１６０＝６４０として計算される。

通常、連続するパケット間のＴＳ＿ＳＴＲＩＤＥは固定された値であり、ダウンスケーリングされたＲＴＰ ＴＳの圧縮された値は圧縮器から伸張器に送信されて伸張される。固定されたＴＳ＿ＳＴＲＩＤＥ値に対して圧縮された値を伸張器に送信するためにＵＯＲ−０、ＵＯＲ−１パケット内において数バイト必要である。これらのパケットフォーマットについての詳細な説明がＲＦＣ３０９５にある。これらのパケットは通常は１ないし３バイトの長さを有し（必要なときには更にＵＤＰチェックサムの２バイト）、ＳＮ、ＴＳ、ＣＲＣ情報を含み、これらの情報はヘッダー圧縮機構のコンテクストを更新するために用いられる。例えば、図９において、ソースがサイレント抑圧を行うものとする。パケットＳＮ_１、ＳＮ_２、ＳＮ_３、ＳＮ_４がそれぞれＴＳ＝１６０、３２０、４８０、９６０により送信されるものとする。ここで、パケットＳＮ_３とＳＮ_４との間の２個のサイレントパケットがサイレント抑圧されるものとする。さらに、圧縮器において、各パケットのＴＳがＴＳ＿ＳＴＲＩＤＥ＝１６０により圧縮されるものとする。従って、最初のパケットは縮尺ＴＳの１を有し、第２のパケットはダウンスケールＴＳの２を有し、３番目のパケットはＴＳの３を有し、４番目のパケットはＴＳの６を有する。ここで、ＬＳＢ符号化を用いると、第２のパケットＳＮ２を受信することでＲｏＨＣアルゴリズムは圧縮器のコンテクストをダウンスケール値の２である００１０を表すように更新する。第３のパケットＳＮ３を受信すると、コンテクストはＴＳ情報により更新され、ビット００１０が００１１に更新される。この方法により、最後の数ビットを変化させるのみでよい。このように、コンテクストはＵＯＲ−０、ＵＯＲ−１パケットのような小さいパケットを用いて更新できる。小さいサイズのＵＯＲ−０、ＵＯＲ−１パケットによりバンド幅を効率的に使用することができる。

ＴＳ＿ＳＴＲＩＤＥの値が変化する場合には、このＴＳ＿ＳＴＲＩＤＥの変化を伝送するためにＵＯＲ−０またはＵＯＲ−１より大きいパケットが必要である。たとえば、ＵＯＲ−２ｅｘｔ３、ＩＲ−ＤＹＮまたはＩＲパケットを用いることができる。特に、これらのパケットを複数回送信する必要があるとき（もし、ＴＳ＿ＳＴＲＩＤＥ変化が高い信頼度で送られる必要があるときに、これらのパケットは数回繰り返して送信される）、これらのパケットは少なくとも７、８バイトの長さを持ち、バンド幅も関係する。サイレント抑圧を用いたＲＴＰソースがサイレント状態から会話状態（および会話状態からサイレント状態）に移行すると、ＲｏＨＣ圧縮器はＴＳ＿ＳＴＲＩＤＥが変化したと判断し、更新されたＴＳ＿ＳＴＲＩＤＥを送信する。このＴＳ＿ＳＴＲＩＤＥを信頼性を維持して送信するために、この更新されたＴＳ＿ＳＴＲＩＤＥは複数回送信する必要がある。例えば、図１０において、ＴＳ＿ＳＴＲＩＤＥは最初の値であり、第１の会話セグメントにおけるＴＳ＿ＳＴＲＩＤＥｉは第２の値であり、ＴＳ＿ＳＴＲＩＤＥｋはサイレント期間の値であり、ＴＳ＿ＳＴＲＩＤＥｊは会話の第２の期間における値である。各ＴＳ＿ＳＴＲＩＤＥの変化の期間、例えばＴＳ＿ＳＴＲＩＤＥｉからＴＳ＿ＳＴＲＩＤＥｋまでの期間では、ＲｏＨＣ圧縮器はそのコンテクストを更新し、これにより、ＴＳ＿ＳＴＲＩＤＥの更新された値を示すために多くのビット数が必要になる。すなわち、複数回送信されるためのより大きなＵＯＲ−２ｅｘｔ３パケットが変化したＴＳ＿ＳＴＲＩＤＥの送信に用いられる。再び図９において、サイレント抑圧のためにパケットＳＮ３とＳＮ４との間にＴＳ＿ＳＴＲＩＤＥのジャンプが存在する。パケットＳＮ_３を受信すると圧縮器はＴＳ＿ＳＴＲＩＤＥが１６０であると推定し、ＳＮ_４を受信するとＴＳ＿ＳＴＲＩＤＥが４８０であると推定する。ＲＴＰソースが音声に復帰すると、圧縮器はふたたびＴＳ＿ＳＴＲＩＤＥが１６０であると推定する。ＴＳ＿ＳＴＲＩＤＥが変化するたびに、圧縮器はこの変化を伸張器に通知するためにＵＯＲ−２ｅｘｔ３（またはＩＲまたはＩＲ−ＤＹＮ）パケットを送信する必要がある。

例えば、パケット間のＴＳ＿ＳＴＲＩＤＥ値の変化による不都合を解消するために、圧縮器は新しいＴＳ＿ＳＴＲＩＤＥがＮ個だけ連続して出現するまではＴＳ＿ＳＴＲＩＤＥ値を変化させない。換言すれば、圧縮器はそれ以前に計算して得られたＴＳ＿ＳＴＲＩＤＥの値を、新しく計算されたＴＳ＿ＳＴＲＩＤＥの値が連続して所定数Ｎだけ同じ値として出現するまで使い続ける。この場合の例を図１１に示す。

図１１において、パケットＳＮ_１がＴＳ＝１６０として発生される。この後ろに２個のパケットが発生されるが、これらはサイレンス抑圧により送信側で欠落され、その後、４個のパケットＳＮ_２、ＳＮ_３、ＳＮ_４、ＳＮ_５が発生される。これらのパケットはそれぞれＴＳ値として６４０、８００、９６０、１１２０を有する。図示したように、最後の３個連続するＴＳ＿ＳＴＲＩＤＥの値はＴＳ＿ＳＴＲＩＤＥ＝１６０として一定となっている。従って、圧縮器は圧縮のためにこの値ＴＳ＿ＳＴＲＩＤＥ＝１６０を用いる。この説明では３個連続する場合を例にしたが、アプリケーションによってはどのような値Ｎであってもよい。さらに、パケットＳＮ３とＳＮ４との間でＲＴＰ ＴＳが４８０だけジャンプしても、圧縮器はこのＲＴＰ ＴＳの４８０のインクリメントが一度だけ生じたことから、そのＴＳ＿ＳＴＲＩＤＥの推定値を更新することはない。他の例として圧縮器はＴＳ＿ＳＴＲＩＤＥの正しい値を決定するために他のＮの値（例えば５）を用いることができる。

ＴＳ＿ＳＴＲＩＤＥ値がＮ個連続することを用いる方法は、サイレントの期間に複数（Ｎ以上の）連続するＳＩＤすなわち１／８の割合でパケットが送信される場合には最良の方法ではない。これらのパケットは送信側のソースで同じ時間間隔で間をおいて並べられ、従ってＲＴＰ ＴＳが同じように変化する。例えば、ＡＭＲアプリケーションにおいてＴＳ＿ＳＴＲＩＤＥがＮ個連続する値としてＴＳ＿ＳＴＲＩＤＥが選択された場合を考える。図１２に示したように、８個の２０ｍｓｅｃのパケット７０６が音声セグメント７０２間に送信され、ＴＳ＿ＳＴＲＩＤＥが（８０００ＫＨｚ＊０．０２０ｓｅｃ）＝１６０として計算される。サイレント期間において、一つのＳＩＤパケット７０８がサイレント期間７０４の間に８個のパケット毎に送信される。サイレント期間のＴＳ＿ＳＴＲＩＤＥは（８０００ＫＨｚ＊０．１６０ｓｅｃ）＝１２８０である。図１２において、パケットＳＮ_９はＴＳとして（１６０）＊（１８）＝１４４０を有し、パケットＳＮ_１０はＴＳとして（１６０）＊（１０）＝１６００を有し、ＳＩＤパケットＳＮ_１１はＴＳとして（１６０）＊（１８）＝２８８０を有し、ＳＩＤパケットＳＮ_１２はＴＳとして（１６０）＊（２６）＝４１６０などを有する。図に示したように、音声の第１の期間においては圧縮器はＴＳ＿ＳＴＲＩＤＥ＝１６０の値を検出し、サイレント期間においてはＴＳ＿ＳＴＲＩＤＥは１６０＊８＝１２８０に更新される。従って、Ｎが２で、Ｎの計算がパケットＳＮ_１２で開始される方法では、ＴＳ＿ＳＴＲＩＤＥ＝１２８０がＮ回連続して発生した時のＴＳ＿ＳＴＲＩＤＥの値となる。従って、ＲｏＨＣ圧縮器はサイレント期間においてＴＳ＿ＳＴＲＩＤＥの更新された値を推定し、これにより、より大きなパケットを送信する必要がある。

図１２において、最初の音声セグメントの期間にＴＳ＿ＳＴＲＩＤＥは１６０として推定され、圧縮されたヘッダーはＵＯＲ−０またはＵＯＲ−１パケットにより伸張器に向けて送信される。しかしながらサイレントの期間にＴＳ＿ＳＴＲＩＤＥが１２８０に更新されると、ＴＳ＿ＳＴＲＩＤＥの明らかな「ジャンプ」がより大きなＵＯＲ−２ｅｘｔ３、ＩＲ−ＤＹＮ、またはＩＲパケットの使用が伸張器への圧縮された値の送信のために必要となる。前述したように、これらのヘッダーは７または８バイトの長さを必要とし、従って、特別なバンド幅を必要とする。ＲＴＰソースが音声に復帰すると、ＴＳ＿ＳＴＲＩＤＥは再び１６０＊１＝１６０に変化し、伸張器の更新が必要となる。この変化は再度伸張器に対してより大きなＵＯＲ−２ｅｘｔ３、ＩＲまたはＩＲ−ＤＹＮヘッダーを介して送信される。この大きいパケットは変化を確実に送信するために複数回送信される必要があり、この結果、バンド幅の最適な使用から少し外れる場合がある。従って、ＲｏＨＣがＡＭＲにより発生されたパケットを圧縮している場合、Ｎ個の連続したパケットにより決定されたＴＳ＿ＳＴＲＩＤＥを用いると、通話における音声とサイレントとの間のＴＳ＿ＳＴＲＩＤＥでのジャンプが発生する。このことによりバンド幅が無駄に使用される場合が生じる。ここでは説明のためにＡＭＲを用いた。ここに記載された思想は他の音声符号化アルゴリズムにも適用できる。

例えば、同じＲＴＰ ＴＳインクリメントがＮ回以上連続したときにＴＳ＿ＳＴＲＩＤＥを更新する代わりに、「ＭＩＮ＿ＴＳ＿ＳＴＲＩＤＥ」の値を用いることもできる。このＭＩＮ＿ＴＳ＿ＳＴＲＩＤＥはフローにおいて計算された最小のＴＳ＿ＳＴＲＩＤＥの値である。ＭＩＮ＿ＴＳ＿ＳＴＲＩＤＥはソースがサイレント抑圧されていないとき、すなわち会話が行われているときの計算されたＴＳ＿ＳＴＲＩＤＥを表している。例えば、サイレント抑圧を用いたＶｏＩＰフローにおいて、ＭＩＮ＿ＴＳ＿ＳＴＲＩＤＥは、ソースがサイレント抑圧されていない場合のＲＴＰ ＴＳの変化に対応する。これは更に、圧縮のために用いられる実際のＴＳ＿ＳＴＲＩＤＥにも対応している。

図１３はＲｏＨＣのパフォーマンスを向上させるために構成されたプロセスの一例を示すフローチャートである。図示したように、ステップ８０２でＲｏＨＣがシステムで用いられているか否かが決定される。ＮＯの場合にはプロセスは終了される。ＲｏＨＣが使用されている場合、パケットがステップ８０４で受信される。ステップ８０６で、受信したパケットと先行のパケットとの間のＲＴＰ ＴＳのインクリメントが決定される。この値はＴＳ＿ＩＮＣＲＥＭＥＮＴと称される。ＴＳ＿ＳＴＲＩＤＥの元の値がそれ以前の圧縮の際に用いられたものとする。ステップ８０８において、先行するＮ個の連続するパケットのＴＳ＿ＩＮＣＲＥＭＥＮＴが同じで、且つこの値が現在のＴＳ＿ＳＴＲＩＤＥ値と異なると判断された場合、プロセスは次のステップ８１０へ進む。若しそうでないときはプロセスはステップ８０６に戻る。ステップ８１０において、ＴＳ＿ＳＴＲＩＤＥは元の値からＴＳ＿ＩＮＣＲＥＭＥＮＴに更新される。

図１５はＲｏＨＣのパフォーマンスを向上させるために構成されたプロセスの他の例のフローチャートを示す。図において、ステップ９０２ではＲｏＨＣがシステムで用いられているか否かが判断される。ＮＯのときはプロセスは終了する。ＲｏＨＣが用いられているときは、ステップ９０４においてパケットが受信される。ステップ９０６では、現在のパケットストリームにおいてＲＴＰ ＴＳのインクリメントが最小のＴＳ＿ＳＴＲＩＤＥより小さいか否かが判断される。ＮＯのときはプロセスはステップ９０４に戻り、ＹＥＳのときはプロセスはステップ９０８に進む。ステップ９０８において、ＴＳ＿ＳＴＲＩＤＥはＲＴＰＴＳのインクリメント（フローにおいて最小のＴＳ＿ＳＴＲＩＤＥより小さい）に更新される。

図１３、１５に示された方法は図１４、１６に示された対応する「手段＋機能」ブロックにより実行される。換言すれば、図１３に示されたブロック８０２〜８１０は図１４に示された「手段＋機能」ブロック１８０２〜１８１０に対応する。図１５に示されたブロック９０２〜９０８は図１６に示された「手段＋機能」ブロック１９０２〜１９０８に対応する。

他の実施形態において、音声とサイレントとの間にＴＳ＿ＳＴＲＩＤＥの変化があった場合、この変化は伸張器に適切に伝達されないことがある。伸張器のコンテクストが圧縮器のコンテクストと一致いない場合に「コンテクストダメージ」が生じ、伸張が正しく行われずにヘッダーの復元に失敗する。この状況は圧縮器と伸張器との間でパケットが欠落しあるいは損傷を受けたときに生じ、あるいは圧縮器におけるＴＳ＿ＳＴＲＩＤＥの値が伸張器に正しく送信されない場合に生じる。コンテクストの不一致により伸張できなかったパケットはコンテクストダメージにより「欠落」となる。伸張されたけれどもコンテクストの不一致によるエラーを含むパケットはコンテクストダメージにより「ダメージパケット」となる。ＲＯＨＣは元のヘッダーについてサイクリックリダンダンシーチェック（ＣＲＣ）を用いて不正伸張を検出する。圧縮器が最初のＴＳ＿ＳＴＲＩＤＥ値をチェックし、伸張器が異なる値をチェックする方法ではこのＣＲＣ符号のエラーが生じることがある。

例えば前述したように、図１２において、最初の音声セグメントにおいてＴＳ＿ＳＴＲＩＤＥが１６０で、サイレントセグメントにおいて１２８０であるとする。更に、チャネル状態の不良により、ＴＳ＿ＳＴＲＩＤＥの変化を通知するために圧縮器から送られたすべてのＵＯＲ−２ｅｘｔ３ヘッダーが欠落したとする。この結果、ＴＳ＿ＳＴＲＩＤＥの値が圧縮器において１６０から１２８０に変化したとしても、伸張器はこの変化を検知しない。したがって、伸張器は次のパケットを再生するときに、更新された１２８０の値を用いる代わりにＴＳ＿ＳＴＲＩＤＥ＝１６０の値を用いる。この結果、再生されたパケットが元の送信されたパケットと異なるためにＣＲＣの動作はエラーとなる。これにより、伸張器は再生されたパケットを欠落させる。

ここで説明されたアルゴリズムの他の利点は、ＲＴＰソースが音声からサイレントに、またはサイレントから音声へと移行するときにＴＳ＿ＳＴＲＩＤＥの変化が推定されないので、ＲＴＰソースがサイレントと音声との間で移行するときにＴＳ＿ＳＴＲＩＤＥの更新によってもたらされる種々の実際上の不都合が回避できることである。

ここでは、サイレント抑圧が行われるときのＲｏＨＣのパフォーマンスの向上のための幾つかの実施形態を説明したが、これらの実施形態はいかなるＲｏＨＣ圧縮器、例えば、ＡＴ、ＡＮおよび他のヘッダー圧縮を用いた装置にも適用させることができる。ここで説明された種々のユニット、モジュールなどの実施形態はハードウエア、ソフトウエア、ファームウエア、またはこれらの組み合わせに適用させることができる。ハードウエアに適用させる場合、種々のユニットをアプリケーションスペシフィックインテグレーテッドデバイス（ＡＳＩＣ）、デジタルシグナルプロセッサ（ＤＳＰ）、デジタルシグナルプロセッシングデバイス（ＤＳＰＤ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プロセッサ、マイクロプロセッサ、コントローラ、マイクロコントローラ、プログラマブルロジックデバイス（ＰＬＤ）、他の電子ユニット、またはこれらの種々の組み合わせに用いることができる。ソフトウエアに適用する場合、種々のユニットをここで説明した機能を果たすモジュール（例えば工程、機能など）と共に用いることができる。このソフトウエアのコードはメモリユニットに記憶することができ、プロセッサ（またはプロセッシングユニット）により実行することができる。このメモリユニットはプロセッサ内部または外部において用いることができ、この場合、この分野で知られている多くの手段を介してプロセッサと通信的に結合させることができる。

当業者であれば情報や信号は種々のテクノロジーや技術を用いて表すことができることを理解できる。例えば、この明細書で開示されたデータ、インストラクション、コマンド、インフォーメーション、シグナル、ビット、シンボル、およびチップは電圧、電流、電磁波、磁界、または粒子、光波、光粒子、またはこれらのいかなる組み合わせで表すことができる。

当業者は更に、この発明の実施形態に関連して説明されている種々の論理ブロック、モジュール、回路およびアルゴリズムステップなどは電子的ハードウエア、コンピュータソフトウエア、またはこれらの組み合わせのなかで用いることができることを理解できる。このようなハードウエアとソフトウエアの組み合わせの可能性をより明確に説明するために、この明細書の説明では、種々のコンポーネント、ブロック、モジュール、回路およびステップがそれらの機能に関して説明されている。これらの機能がハードウエアに適用されるか、ソフトウエアに適用されるかは、特定のアプリケーションとシステム全体におけるデザインの内容によって決定される。当業者は、ここで説明された機能を特定のアプリケーションに適用して種々の方法で用いることができるが、これらの適用の決定はこの発明の範囲から逸脱しない範囲でなされるべきであることは勿論である。

この発明の実施形態に関連して説明された種々の論理ブロック、モジュール、および回路は通常の汎用プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、アプリケーションスペシフィックインテグレーテッドサーキット（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のプログラマブルロジックデバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウエアコンポーネント、またはここで説明された機能を果たすように設計されたこれらの組み合わせを用いて実現できる。汎用プロセッサは、マイクロプロセッサであるが、その他、従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシーンのいずれでもよい。プロセッサはさらに計算装置の組み合わせ、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサの組み合わせ、一つまたは複数のマイクロプロセッサとＤＳＰコアとの組み合わせ、またはこれらのいかなる組み合わせで構成してもよい。

ここで述べられた実施形態に関連して説明された方法またはアルゴリズムのステップは直接にハードウエア、プロセッサにより実行されるソフトウエアモジュール、またはこれらの組み合わせにより実施することができる。ソフトウエアモジュールはランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、リードオンリーメモリ（ＲＯＭ）、エレクトリカリープログラマブルＲＯＭ（ＥＰＲＯＭ）、エレクトリカリーイレーザブルプログラマブルＲＯＭ（ＥＥＰＲＯＭ）、レジスタ、ハードディスク、リムーバブルディスク、ＣＤ−ＲＯＭ、またはこの分野で知られている種々の形態の記憶媒体の内部に存在する。記憶媒体のひとつはプロセッサに結合され、このプロセッサは記憶媒体から情報を読み出すことができ、または情報を書き込むことができる。他の形態として、記憶媒体はプロセッサと一体に構成することができる。プロセッサと記憶媒体とはＡＳＩＣ内に設けることができる。このＡＳＩＣはＡＴ内に設けることができる。あるいは、プロセッサと記憶媒体とはＡＴ内で互いに独立のコンポーネントとして設けることができる。

以上の実施形態の説明は当業者がこの発明を形成し、使用することができる程度に十分に記載されている。これらの実施形態の種々の変形例は当業者にとって自明であり、ここに説明された一般的な原理はこの発明の範囲を逸脱しない限りにおいて他の実施形態に適用することができる。このように、この発明はここに説明された実施形態に限定されることなく、記載された発明の原理と新規な特徴とに対応した広い範囲に及ぶものである。

以上の実施形態の説明は当業者がこの発明を形成し、使用することができる程度に十分に記載されている。これらの実施形態の種々の変形例は当業者にとって自明であり、ここに説明された一般的な原理はこの発明の範囲を逸脱しない限りにおいて他の実施形態に適用することができる。このように、この発明はここに説明された実施形態に限定されることなく、記載された発明の原理と新規な特徴とに対応した広い範囲に及ぶものである。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定し、
所定数のパケットが一定のタイムスタンプインクリメント値を持つまで連続するパケットのＲＴＰタイムスタンプインクリメントを計算し、
この一定のタイムスタンプインクリメント値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当て、
このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングし、
この割り当てられた値を用いてヘッダーを圧縮する、
ヘッダー圧縮方法。
［Ｃ２］
複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定し、
連続するパケットのＲＴＰタイムスタンプインクリメントを計算し、
フロー全体から最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を見つけ出し、
この最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当て、
このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングし、
この割り当てられた値を用いてヘッダーを圧縮する、
ヘッダー圧縮方法。
［Ｃ３］
前記圧縮は、
最下位符号化法に基づいたウインドウを用いて符号化値を決定し、
この符号化値によりコンテクストを更新する、
［Ｃ２］に記載の方法。
［Ｃ４］
前記圧縮は更に、
先行パケットに対応するコンテクスト中の第１の値と現在パケットに対応する第２の値との間の差を決定し、
この第２の値によりコンテクストを決定し、
この第２の値により現在パケットのヘッダーを圧縮する、
［Ｃ３］に記載の方法。
［Ｃ５］
前記ヘッダーは、インターネットプロトコル（ＩＰ）、実時間伝送プロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、送信制御プロトコル（ＴＣＰ）の少なくとも一つに関する情報を持つ、［Ｃ２］に記載の方法。
［Ｃ６］
前記タイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）はパケット内の複数のサンプルである、［Ｃ２］に記載の方法。
［Ｃ７］
前記所定数は５である、［Ｃ１］に記載の方法。
［Ｃ８］
前記所定数は第１タイプのデータに対する第１の値であり、また第２タイプのデータに対する第２の値である、［Ｃ１］に記載の方法。
［Ｃ９］
前記パケットは音声データを有する、［Ｃ７］に記載の方法。
［Ｃ１０］
複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定する手段と、
所定数のパケットが一定のタイムスタンプインクリメント値を持つまで連続するパケットのＲＴＰタイムスタンプインクリメントを計算する手段と、
この一定のＲＴＰタイムスタンプインクリメント値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当てる手段と、
このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングする手段と、
この割り当てられた値を用いてヘッダーを圧縮する手段と、
を具備するヘッダー圧縮装置。
［Ｃ１１］
複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定する手段と、
連続するパケットのＲＴＰタイムスタンプインクリメントを計算する手段と、
フロー全体から最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を見つけ出す手段と、
この最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当てる手段と、
このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングする手段と、
この割り当てられた値を用いてヘッダーを圧縮する手段と、
を具備するヘッダー圧縮装置。
［Ｃ１２］
前記圧縮手段は、
最下位符号化法に基づいたウインドウを用いて符号化値を決定する手段と、
この符号化値によりコンテクストを更新する手段と、
を具備した［Ｃ１１］に記載の装置。
［Ｃ１３］
前記圧縮手段は更に、
先行パケットに対応するコンテクスト中の第１の値と現在パケットに対応する第２の値との間の差を決定する手段と、
この第２の値によりコンテクストを更新する手段と、
この第２の値により現在パケットのヘッダーを圧縮する手段と、
を具備する［Ｃ１２］に記載の装置。
［Ｃ１４］
更に、圧縮されたヘッダーを送信する手段を具備する、［Ｃ１１］に記載の装置。
［Ｃ１５］
少なくとも一つのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値を受信する手段と、
少なくとも一つの圧縮されたパケットを受信する手段と、
最下位ビットウインドを用いてパケットを複号化する手段を含む、圧縮されたパケットを伸長する手段と、
受信されたタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値に基づいて少なくとも一つのパケットのタイムスタンプ（ＴＳ）の値を決定する手段と、
を具備する装置。
［Ｃ１６］
複数のパケットに対して最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）を決定する手段と、
現在パケットを受信する手段と、
現在パケットのタイムスタンプインクリメントを決定する手段と、
現在パケットのタイムスタンプインクリメントが複数のパケットの最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）より小さいときに、この最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を更新する手段と、
この更新された値を伸長器に送信する手段と、
次のパケットを受信する手段と、
前記次のパケットを更新された最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）に基づいて圧縮する手段と、
を具備する装置。
［Ｃ１７］
前記更新手段は、
前記最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を現在パケットのタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）に変更する手段を有する、［Ｃ１６］に記載の装置。
［Ｃ１８］
複数のパケットを受信する手段と、
受信されたパケットに対して複数のタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値を決定する手段と、
受信されたＮ個のパケットに対して複数のタイムスタンプインクリメント値が一定に保持されるかを決定する手段と、
この決定されたタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値をコンテクスト内に記憶されたタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値と比較する手段と、
最新に受信されたＮ個のパケットに対するタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値が同じ値であり且つ記憶された値とは異なるときにこの記憶された値を更新する手段と、
現在パケットを受信する手段と、
この現在パケットを更新されたタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）を用いて圧縮する手段と、
を具備する装置。
［Ｃ１９］
複数のパケットに対する最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）を決定するための第１の複数の符号と、
現在のパケットを受信するための第２の複数の符号と、
現在のパケットのタイムスタンプインクリメントを決定するための第３の複数の符号と、
現在のパケットのタイムスタンプインクリメントが複数のパケットに対する最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）より少ない場合に最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を更新するための第４の複数の符号と、
更新された値を伸張器に送信するための第５の複数の符号と、
次のパケットを受信するための第６の複数の符号と、
更新された最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）に基づいて次のパケットを圧縮するための第７の複数の符号と、
を具備する、コンピュータプログラム製品。
［Ｃ２０］
複数のパケットを受信するための第１の複数の符号と、
この受信されたパケットに対する複数のタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）を決定するための第２の複数の符号と、
複数のタイムスタンプ値がＮ個の受信パケットにわたって一定に保たれたか否かを決定するための第３の複数の符号と、
決定されたタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）をコンテクストに記憶されたタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）と比較するための第４の複数の符号と、
最新の連続するＮ個の受信パケットに対するタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）が同じ値でありかつ記憶された値と異なる場合にこの記憶された値を更新するための第５の複数の符号と、
現在パケットを受信するための第６の複数の符号と、
現在パケットを更新されたタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）を用いて圧縮するための第７の複数の符号と、
を具備するコンピュータプログラム製品。

Claims (20)

1. 複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定し、
   所定数のパケットが一定のタイムスタンプインクリメント値を持つまで連続するパケットのＲＴＰタイムスタンプインクリメントを計算し、
   この一定のタイムスタンプインクリメント値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当て、
   このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングし、
   この割り当てられた値を用いてヘッダーを圧縮する、
   ヘッダー圧縮方法。
2. 複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定し、
   連続するパケットのＲＴＰタイムスタンプインクリメントを計算し、
   フロー全体から最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を見つけ出し、
   この最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当て、
   このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングし、
   この割り当てられた値を用いてヘッダーを圧縮する、
   ヘッダー圧縮方法。
3. 前記圧縮は、
   最下位符号化法に基づいたウインドウを用いて符号化値を決定し、
   この符号化値によりコンテクストを更新する、
   請求項２に記載の方法。
4. 前記圧縮は更に、
   先行パケットに対応するコンテクスト中の第１の値と現在パケットに対応する第２の値との間の差を決定し、
   この第２の値によりコンテクストを決定し、
   この第２の値により現在パケットのヘッダーを圧縮する、
   請求項３に記載の方法。
5. 前記ヘッダーは、インターネットプロトコル（ＩＰ）、実時間伝送プロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、送信制御プロトコル（ＴＣＰ）の少なくとも一つに関する情報を持つ、請求項２に記載の方法。
6. 前記タイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）はパケット内の複数のサンプルである、請求項２に記載の方法。
7. 前記所定数は５である、請求項１に記載の方法。
8. 前記所定数は第１タイプのデータに対する第１の値であり、また第２タイプのデータに対する第２の値である、請求項１に記載の方法。
9. 前記パケットは音声データを有する、請求項７に記載の方法。
10. 複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定する手段と、
    所定数のパケットが一定のタイムスタンプインクリメント値を持つまで連続するパケットのＲＴＰタイムスタンプインクリメントを計算する手段と、
    この一定のＲＴＰタイムスタンプインクリメント値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当てる手段と、
    このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングする手段と、
    この割り当てられた値を用いてヘッダーを圧縮する手段と、
    を具備するヘッダー圧縮装置。
11. 複数の連続するパケットの少なくとも１個に対する実時間伝送プロトコル（ＲＴＰ）タイムスタンプ（ＴＳ）を決定する手段と、
    連続するパケットのＲＴＰタイムスタンプインクリメントを計算する手段と、
    フロー全体から最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を見つけ出す手段と、
    この最小ＲＴＰタイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を圧縮のためのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値として割り当てる手段と、
    このタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値により各ＲＴＰタイムスタンプ（ＴＳ）の値をダウンスケーリングする手段と、
    この割り当てられた値を用いてヘッダーを圧縮する手段と、
    を具備するヘッダー圧縮装置。
12. 前記圧縮手段は、
    最下位符号化法に基づいたウインドウを用いて符号化値を決定する手段と、
    この符号化値によりコンテクストを更新する手段と、
    を具備した請求項１１に記載の装置。
13. 前記圧縮手段は更に、
    先行パケットに対応するコンテクスト中の第１の値と現在パケットに対応する第２の値との間の差を決定する手段と、
    この第２の値によりコンテクストを更新する手段と、
    この第２の値により現在パケットのヘッダーを圧縮する手段と、
    を具備する請求項１２に記載の装置。
14. 更に、圧縮されたヘッダーを送信する手段を具備する、請求項１１に記載の装置。
15. 少なくとも一つのタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値を受信する手段と、
    少なくとも一つの圧縮されたパケットを受信する手段と、
    最下位ビットウインドを用いてパケットを複号化する手段を含む、圧縮されたパケットを伸長する手段と、
    受信されたタイムスタンプストライド（ＴＳ_ＳＴＲＩＤＥ）値に基づいて少なくとも一つのパケットのタイムスタンプ（ＴＳ）の値を決定する手段と、
    を具備する装置。
16. 複数のパケットに対して最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）を決定する手段と、
    現在パケットを受信する手段と、
    現在パケットのタイムスタンプインクリメントを決定する手段と、
    現在パケットのタイムスタンプインクリメントが複数のパケットの最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）より小さいときに、この最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を更新する手段と、
    この更新された値を伸長器に送信する手段と、
    次のパケットを受信する手段と、
    前記次のパケットを更新された最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）に基づいて圧縮する手段と、
    を具備する装置。
17. 前記更新手段は、
    前記最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を現在パケットのタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）に変更する手段を有する、請求項１６に記載の装置。
18. 複数のパケットを受信する手段と、
    受信されたパケットに対して複数のタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値を決定する手段と、
    受信されたＮ個のパケットに対して複数のタイムスタンプインクリメント値が一定に保持されるかを決定する手段と、
    この決定されたタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値をコンテクスト内に記憶されたタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値と比較する手段と、
    最新に受信されたＮ個のパケットに対するタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）値が同じ値であり且つ記憶された値とは異なるときにこの記憶された値を更新する手段と、
    現在パケットを受信する手段と、
    この現在パケットを更新されたタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）を用いて圧縮する手段と、
    を具備する装置。
19. 複数のパケットに対する最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）を決定するための第１の複数の符号と、
    現在のパケットを受信するための第２の複数の符号と、
    現在のパケットのタイムスタンプインクリメントを決定するための第３の複数の符号と、
    現在のパケットのタイムスタンプインクリメントが複数のパケットに対する最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）より少ない場合に最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）値を更新するための第４の複数の符号と、
    更新された値を伸張器に送信するための第５の複数の符号と、
    次のパケットを受信するための第６の複数の符号と、
    更新された最小タイムスタンプインクリメント（ＭＩＮ_ＴＳ_ＳＴＲＩＤＥ）に基づいて次のパケットを圧縮するための第７の複数の符号と、
    を具備する、コンピュータプログラム製品。
20. 複数のパケットを受信するための第１の複数の符号と、
    この受信されたパケットに対する複数のタイムスタンプインクリメント（ＴＳ_ＳＴＲＩＤＥ）を決定するための第２の複数の符号と、
    複数のタイムスタンプ値がＮ個の受信パケットにわたって一定に保たれたか否かを決定するための第３の複数の符号と、
    決定されたタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）をコンテクストに記憶されたタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）と比較するための第４の複数の符号と、
    最新の連続するＮ個の受信パケットに対するタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）が同じ値でありかつ記憶された値と異なる場合にこの記憶された値を更新するための第５の複数の符号と、
    現在パケットを受信するための第６の複数の符号と、
    現在パケットを更新されたタイムスタンプインクリメント値（ＴＳ_ＳＴＲＩＤＥ）を用いて圧縮するための第７の複数の符号と、
    を具備するコンピュータプログラム製品。

Images