JP2003529247A - データ・パケットのヘッダ・フィールドを圧縮するための技術 - Google Patents

Abstract

(57)【要約】 タイマーに基づくヘッダ圧縮／解凍技術とタイマー及び基準に基づく技術とが提供される。ソースは、ＲＴＰタイムスタンプなどの、ヘッダ・フィールドを作る。該ヘッダ・フィールドを含むパケットが圧縮器へ送られ、これは該ソースからの該パケットのヘッダ・フィールドとジッター量とに基づいて圧縮されているヘッダ・フィールドを計算する。圧縮されているヘッダ・フィールドは、該圧縮器の前のネットワークがパケットの伝送に及ぼすジッター効果を計算し且つ該圧縮器と解凍器との間のネットワークがパケットの伝送に及ぼすジッター効果を計算することによって計算される。その圧縮されているヘッダ・フィールドを含むパケットは、ローカル・タイマーを含む解凍器へ送られる。該解凍器は、前のパケットの到着からの経過時間と該前のパケットのフィールド値とに基づいて該ヘッダ・フィールドの近似値を計算することによって、該圧縮されているヘッダ・フィールドを解凍する。該ヘッダ・フィールドの近似値は、該パケットに供給されている圧縮されているヘッダ・フィールドに基づいて訂正される。

Description

【発明の詳細な説明】

【０００１】 （技術分野） 本発明は、データ・パケットのヘッダ・フィールドを圧縮する方法及び装置に
関する。より具体的には、本発明はタイマー及び基準に基づく方式を用いてデー
タ・パケットのヘッダ・フィールドを圧縮するための方法及び装置に関する。

【０００２】 インターネット・プロトコル（ＩＰ）に基づく実時間マルチメディアのために
、「実時間転送プロトコル（ＲＴＰ）」プロトコルがユーザー・データグラム・
プロトコル（ＵＤＰ／ＩＰの上で主として使用されている。結合されたＩＰ／Ｕ
ＤＰ／ＲＴＰヘッダのサイズはＩＰｖ４については少なくとも４０バイトであり
、ＩＰｖ６については少なくとも６０バイトである。パケットあたり４０−６０
バイトのオーバーヘッドは、スペクトル効率が主な関心事であるシステム（例え
ば、セルラー・ネットワークなど）では重いと考えられることがある。従って、
適当なＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方法が必要である。現在のヘッダ圧縮方
式がＲＦＣ２５０８に記載されており、それは４０／６０バイトのＩＰ／ＵＤＰ
／ＲＴＰヘッダをポイントツーポイント・リンクで２または４バイトまで圧縮す
ることができる。現存するヘッダ圧縮アルゴリズムは、ＩＰパケット・ヘッダの
殆どのフィールドはセッションの期間中パケット・ストリーム中で不変のままで
あるという所見に基づいている。従って、解凍器において圧縮状態（全ヘッダ情
報）を確立し、最少量のヘッダ情報を圧縮器から解凍器へ伝えることによりヘッ
ダ情報を圧縮することが可能である。

【０００３】 ＲＦＣ２５０８は、殆どの時間、パケット毎に異なるＲＴＰタイムスタンプな
どのＲＴＰフィールドを線形補外法により予測することができるという着想に基
づいている。本質的に、送られなければならない唯一の情報は、エラー及びパケ
ット喪失検出（コンテキストＩＤも）のために使われるシーケンス番号である。
センダー（送信側）が現在のパケットに線形補外法を適用できないと判定したと
きには、直前のパケットに関する一次差情報が送られる。セッションを開始する
ために、完全なヘッダが送られる。更に、レシーバー（受信側）は、（シーケン
ス番号が２以上増大したことにより検出される）パケット喪失があると判定した
ときには、再同期化を可能とするために完全なヘッダを送ることをセンダーには
っきり要求する。

【０００４】 しかし、ＲＦＣ２５０８で定義されているヘッダ圧縮は、帯域幅が非常に貴重
であってエラーがありふれている或る環境（セルラーまたは無線の環境）には良
く適してはいない。ＲＦＣ２５０８ヘッダ圧縮方式では、ＲＴＰタイムスタンプ
は殆どの時間線形に増大するパターンを有すると仮定される。ヘッダがそのパタ
ーンに従っているときには、圧縮されているヘッダには本質的に短いシーケンス
番号が必要とされるに過ぎない。ヘッダがそのパターンに従っていないときには
、圧縮されているヘッダで現在のヘッダのＲＴＰタイムスタンプと前のものとの
差が送られる。符号化テーブルを使用することにより更に最適化することが可能
である。このアプローチには三つの欠点がある。最初の一つは、前のヘッダの喪
失が現在のヘッダの解凍を無効にするので、それはエラーに対して強くないこと
である。第２のは、ＲＴＰタイムスタンプの差或いはジャンプが非常に大きくて
符号化ルックアップ・テーブルからはみ出すことがあることである。例えば、媒
体が声であるならば、その様な大きな差は無言間隔により生じることがある。第
３のは、結果としての符号化されている差のサイズが変化しやすく、そのために
、割り当てられるべき帯域幅を予測し管理することがいっそう困難になることで
ある。

【０００５】 従って、フィールドの値（例えばＲＴＰタイムスタンプの値）の任意のジャン
プに配慮することができ、より一貫した或いは一定のサイズを生じさせ、エラー
に対してより強いヘッダ圧縮方式が必要である。

【０００６】 （発明の開示） 本発明の実施態様に従って、タイマーに基づくヘッダ解凍技術が提供される。
ＲＴＰソースは、ＲＴＰタイムスタンプなどのヘッダ・フィールドを作る。該タ
イムスタンプはネットワークを介して圧縮器に送られる。該圧縮器において、受
信されたタイムスタンプ（ヘッダ）のジッターが過度であるか否か判定するため
にジッター減少機能（ＪＲＦ）が使用される。もしジッターが過度であれば、そ
のパケットは捨てられる。さもなければ、該圧縮器は、ＲＴＰタイムスタンプと
該タイムスタンプの初期値とに基づいて圧縮されているヘッダ・フィールド（圧
縮されているタイムスタンプ）を計算する。その圧縮されているタイムスタンプ
は、該ソースと解凍器との間のネットワークがパケットの伝送に及ぼす効果とし
て計算されるジッターを表す。その計算されたジッターは、ソースと圧縮器との
間のネットワークがパケットの伝送に及ぼす効果を表すネットワーク・ジッター
と圧縮器と解凍器との間のネットワークがパケットの伝送に及ぼす効果を表す無
線ジッターとの集積である。本書で使用される“ネットワーク”という用語は、
例えば無線電気通信ネットワークにおける無線リンクを排除しない広い用語であ
るべく意図されている。圧縮されているタイムスタンプを含むＲＴＰパケットは
、リンクまたはネットワークを介して解凍器へ送られる。

【０００７】 解凍器は、始めに端末に置かれているタイマーの現在の値に基づいて（即ち、
経過した時間に基づいて）タイムスタンプの見積もり或いは近似値を計算するこ
とにより、圧縮されているタイムスタンプを解凍する。そのタイムスタンプの近
似値は、パケット・ヘッダに与えられている圧縮されているタイムスタンプに基
づいて改良或いは訂正される。この様に、現在のパケット（ヘッダ）についての
タイムスタンプがローカル・タイマーと現在のヘッダに与えられている圧縮され
ているタイムスタンプとに基づいて再生される。そのパケットと再生されたタイ
ムスタンプとは、処理のためにＲＴＰエンドポイントに供給される。

【０００８】 本発明のタイマーに基づく方式は幾つかの利点を包含している。本書で使用さ
れる“タイマーに基づく方式”という用語は、圧縮されているタイムスタンプを
使用するタイマーに基づく方式と、本書で開示されるタイマー及び基準に基づく
方式とを含む。圧縮されているタイムスタンプ（或いは他のヘッダ・フィールド
）のサイズは一定で小さい。更に、サイズは沈黙の間隔の長さの関数として変化
しない。（タイムスタンプを作る）ＲＴＰソースにおけるタイマー・プロセスと
解凍器プロセスにおけるタイマーとの間に同期化は不要である。また、圧縮され
ているヘッダの部分的タイムスタンプ情報は自己充足していて、完全なＲＴＰタ
イムスタンプ値を作るためには解凍器タイマー値と結合されるだけでよいので、
この技術はエラーに対して強い。ヘッダの喪失或いは破損は後の圧縮されている
ヘッダを無効にしない。

【０００９】 本発明の第２の実施態様は、伝送の前に（例えばＲＴＰタイムスタンプを含ん
でいる）ヘッダがＲＴＰパケットからはぎ取られ或いは取り除かれるヘッダはぎ
取り（ヘッダフレーム除去（stripping））方式を提供する。回路のような接続
（例えば回路または仮想回路）または本質的に一定ビットレートのチャネルを通
してヘッダはぎ取り器とヘッダ生成器とが接続される。初期化後、該ヘッダはぎ
取り器は各パケットからヘッダをはぎ取り或いは取り除き（タイムスタンプとシ
ーケンス番号とを取り除くことを含む）、その後にその無ヘッダ・パケットをヘ
ッダ生成器へ送る。ヘッダはぎ取り器でパケット・ジッターを除去するために、
パケットはヘッダ中のＲＴＰタイムスタンプ（ＴＳ）に従って時間間隔を置いて
送られることができる。従って、この実施態様では、タイムスタンプはＲＴＰパ
ケットに明示的には供給されない（圧縮されているタイムスタンプも）。むしろ
、タイミング情報は、ヘッダはぎ取り器と再生器との間の本質的に一定ビットレ
ートのチャネルに基づいてヘッダ再生器に暗示的に供給される。本質的に一定ビ
ットレートのチャネルは幾つかの異なる方法で設けられることができる。

【００１０】 この第２実施態様では、初期化が行われた後（例えば最初のシーケンス番号及
びタイムスタンプをヘッダ再生器に提供するなど）ヘッダ再生器は、Ｔミリ秒毎
にTS_ｓｔｒｉｄｅだけローカル・タイムスタンプ・カウンターをインクリメン
トすることにより引き続くパケットのためにタイムスタンプを再生することがで
きると共にパケット持続時間毎にローカルＳＮカウンターを１だけインクリメン
トすることによりパケットのシーケンス番号を再生することができる。これらの
フィールドは、パケット・ジッターが導入されないヘッダはぎ取り器とヘッダ再
生器との間に設けられている本質的に一定ビットレートのチャネルの故にローカ
ル・タイマーまたはカウンターのみに基づいて再生されることができる。従って
、初期化後、これらのヘッダ・フィールドはローカル・クロックのみに関してヘ
ッダ再生器で再生されることができる。

【００１１】 しかし、もし対処されなければ、フィールド再生のためにローカル・タイマー
またはクロックのみに依拠するヘッダーはぎ取りアプローチをおそらく無効にし
かねないような１つまたは数個の基本的不連続事象（例えば、パケット・サイズ
またはTS_ｓｔｒｉｄｅの変化、タイムスタンプの非線形シフト、など）が発生
するかも知れない。ヘッダ・ストリングは、既知のまたは線形予測可能なフィー
ルドを有する一連のパケット・ヘッダである。１つのストリングから他のへの移
行は幾つかの不連続事象のうちのいずれかにより引き起こされることができる。
これが発生するとき、ヘッダはぎ取り器は、不連続事象を特定して、タイムスタ
ンプ及びシーケンス番号の再生が続いて行われ得るように該事象に関連する更新
されたヘッダ情報をヘッダ再生器へ送る。ハンドオーバーがあるときにも、更新
されたヘッダ情報を提供する同様の技術を使用することができる。

【００１２】 本発明は、添付図面と関連させて以下の詳細な説明を考慮すればいっそう明ら
かとなろう。

【００１３】 （発明を実施するための最良の形態） Ｉ．圧縮されているタイムスタンプを使用するタイマーに基づく方式 Ａ．アーキテクチャ 図１は、本発明の実施例に従うシステムを図解するブロック図である。端末１
０２がＩＰネットワーク１０８に接続されている。端末１０２は、ＲＴＰ／ＵＤ
Ｐ／ＩＰを動作させ、ネットワーク１１０を介して伝送されるＲＴＰパケットで
パケット化された音声サンプルを供給するパーソナルコンピュータ等であること
ができる。端末１０２は、この端末（例えば、ＩＰアドレス、ポート番号などを
含んでいる）をＲＴＰパケットについてのソースまたはデスティネーションとし
て特定するＲＴＰエンドポイント１０４を含んでいる。ＩＰネットワークは例と
してあげられるけれども、代わりに他の種類のパケット交換ネットワーク等を使
用することができる。本書で使用される“ネットワーク”という用語は、例えば
無線電気通信ネットワークにおける無線リンクを排除しない広い用語であるべく
意図されている。端末１０２は、タイムスタンプを作るためのローカル・タイマ
ー１０３も含む。

【００１４】 アクセス・ネットワーク・インフラストラクチャー（ＡＮＩ）１１０がＩＰネ
ットワーク１０８に接続されている。無線端末１３０は無線周波数（ＲＦ）リン
ク１４０を介してＡＮＩ１１０に結合される。本書に記載されている無線端末１
３０は、例えば、その環境に応じて無線圧縮器または無線解凍器であることがで
きる。これは、特にパケットのソースまたはパケットのデスティネーションが無
線端末１３０とは別であるときに、そうなる。ＲＦリンク１４０は、アップリン
ク１４２（端末１３０からＡＮＩ１１０へ）及びダウンリンク１４４（ＡＮＩ１
１０から端末１３０へ）を含む。ＡＮＩ１１０は、一つの領域内の１つ以上の無
線（或いは無線周波数）端末（端末１３０を含む）をインターフェースでＩＰネ
ットワーク１０８と接続させ、ワイヤーライン信号（ＩＰネットワーク１０８か
ら供給される）と無線またはＲＦ信号（端末１３０へまたはそれから供給される
）との間の変換を含んでいる。従って、ＡＮＩ１１０は、ＩＰネットワーク１０
８から受信されるＲＴＰパケットがＲＦリンク１４０を介して無線端末１３０へ
送られることを可能にすると共に、ＲＴＰパケットが端末１３０からＩＰネット
ワーク１０８を介して端末１０２などの他の端末へ送られることを可能にする。

【００１５】 本発明の実施態様に従って、ＡＮＩ１１０はＡＮＩ＿ＡＤ１１２及びＡＮＩ＿
ＡＤ１１４などの１つ以上のＡＮＩアダプター（ＡＮＩ＿ＡＤ）を含んでおり、
その各々が好ましくはタイマーを含む。各ＡＮＩ＿ＡＤは、ヘッダ圧縮（ダウン
リンク伝送の前に）及び解凍（アップリンク伝送後に）を実行する。ＩＰネット
ワーク１０８から受信されるＲＴＰパケットについてのヘッダ（または、タイム
スタンプなどの１つ以上のヘッダ・フィールド）はダウンリンク１４２を介して
の端末１３０への伝送の前にＡＮＩ＿ＡＤ１１２により圧縮され、端末１３０か
ら受信されるパケット・ヘッダはＩＰネットワーク１０８への伝送の前にＡＮＩ
＿ＡＤ１１２により解凍される。従って、各ＡＮＩ＿ＡＤは圧縮器／解凍器１１
５と見なされても良い。各ＡＮＩ＿ＡＤは、領域内の特定のまたは異なる区域に
位置する端末をインターフェースでＩＰネットワーク１０８に接続することがで
きる。ＡＮＩ＿ＡＤ１１２は、タイマーに基づく解凍技術を実行するためにタイ
マー１１３を含んでいる。ＡＮＩ＿ＡＤ１１２は、ネットワーク１０８を介して
受信されたパケット（またはヘッダ）についてのジッターを測定して過度のジッ
ターを有するパケット／ヘッダを捨てるジッター減少機能（ＪＲＦ）１１５も含
んでいる。

【００１６】 追加の領域内に位置する他の端末をインターフェースでＩＰネットワーク１０
８に接続するためにＡＮＩ１２０などの追加のＡＮＩを設けることができる。Ａ
ＮＩ１２０は同様にＡＮＩ＿ＡＤ１２２（図１）などの１つ以上のＡＮＩ＿ＡＤ
を含んでいる。各ＡＮＩ＿ＡＤはタイマーとＪＲＦとを含んでいる。

【００１７】 端末１３０は、ＲＴＰパケットのソース及び／又はデスティネーション（レシ
ーバー）であるＲＴＰエンドポイント１３２を含んでいる。端末１３０は、（ア
ップリンク１４２で伝送されるべきパケットのための）ヘッダ圧縮と（ダウンリ
ンク１４４を介して受信されるパケットに対する）解凍とを実行する端末アダプ
ター（ｔｅｒｍ＿ＡＤ）１３６を含む。そこで、端末アダプター（ｔｅｒｍ＿Ａ
Ｄ）は、ＡＮＩ＿ＡＤと同様の、ヘッダ圧縮器／解凍器１３７と見なされ得るも
のである。

【００１８】 端末アダプター（ｔｅｒｍ＿ＡＤ）１３６は、現在のヘッダのＲＴＰタイムス
タンプの近似値（または見積もり）を計算するためのタイマー１３４（レシーバ
ー・タイマー）も含む。端末アダプター（ｔｅｒｍ＿ＡＤ）１３６は、ＲＴＰヘ
ッダ内の付加的情報を使用してタイムスタンプ近似値を改良或いは訂正する。本
発明の実施態様に従って、タイムスタンプ近似値はＲＴＰヘッダで供給される圧
縮されているタイムスタンプに基づいて訂正または調整される。この様に、ロー
カル・タイマーと圧縮されているタイムスタンプとを使用して各ＲＴＰヘッダに
ついて正しいタイムスタンプを再生することができる。それ自身のＲＴＰエンド
ポイント、端末アダプター及びタイマーを各々包含する他の端末（端末１５０な
ど）を設けることができる。

【００１９】 図１に示されている構成は単に例として与えられているに過ぎず、本発明はこ
れに限定されない。むしろ、図１は、帯域幅が非常に貴重であってエラーが希な
データリンクまたはシステム（無線リンク１４０など）を介してＲＴＰデータが
送られる例を一つ与えているに過ぎない。本発明は、無線リンクには限定されな
くて、多様なリンク（無線リンク等を含む）に適用され得る。

【００２０】 タイマーに基づくヘッダ圧縮及び解凍方式が役に立つことのある１つのアプリ
ケーション例は、ＩＰ経由音声（Voice over IP)（またはＩＰ電話）パケットが
セルラー・システムを介して伝送されるところにある。ＶｏＩＰがセルラーシス
テムに適用されるときには、無線またはエアー（ＲＦ）インターフェースの帯域
幅が限られていることによるＩＰ／ＵＤＰ／ＲＴＰヘッダのオーバーヘッドを最
小限にすることが重要である。その様なシステムでは、例えば、ＡＮＩ＿ＡＤは
、ＩＰネットワークを、ＲＴＰ／ＵＤＰ／ＩＰ（例えば、端末１３０）を動作さ
せると共に無線またはＲＦリンクを介してＲＴＰパケットを受信するためのセル
ラーまたはＲＦインターフェースを有するコンピュータ端末にインターフェース
で接続する。これは本発明の圧縮／解凍技術の単なる１例に過ぎない。

【００２１】 図２は、本発明の実施態様に従うＲＴＰパケットの圧縮されていないフォーマ
ットを図解する図である。図２に示されているように、圧縮されていないＲＴＰ
パケットは、ＩＰヘッダ、ＵＤＰヘッダ２１２、ＲＴＰヘッダ２１４、及び音声
サンプル２１６であって良いペイロードを含む。

【００２２】 図３は、本発明の実施例に従う圧縮されていないＲＴＰヘッダ・フォーマット
を図解する図である。図３に示されているように、圧縮されていないＲＴＰヘッ
ダはタイムスタンプ（ＴＳ）３１０と、シーケンス番号（Ｓ．Ｎ．）３１２と、
他の何らかのフィールド３１４とを含む。ＩＰネットワーク１０８のパケット交
換性の故に、ＲＴＰパケットは順番が狂って到着することがある。シーケンス番
号３１２は、ＲＴＰレシーバーまたはＲＴＰデスティネーション（例えば、端末
１３０、図１）においてＲＴＰ音声サンプルを正しい順序に組み立てるために使
用される。しかし、ＲＴＰパケット内のシーケンス番号は、フィールド内の如何
なる非線形変化（例えば、音声信号の沈黙の間隔）をも反映しない。従って、各
パケットの相対的タイミングを示すためにタイムスタンプ（ＴＳ）３１０が供給
される。

【００２３】 前述したように、各ＲＴＰパケット内のＩＰ／ＵＤＰ／ＲＴＰヘッダにより供
給される４０−６０バイト・ヘッダ・オーバーヘッドは大きすぎるという心配が
ある。特に、低速のまたは限られた帯域幅のリンク（リンク１４０など）を介し
て動作するＲＴＰパケットのためには４バイトＲＴＰタイムスタンプは特に負担
となる。その結果として、ＲＴＰヘッダを効率的に圧縮し、特にＲＴＰヘッダの
タイムスタンプ・フィールドを圧縮する方法が必要である。

【００２４】 ＲＦＣ２５０８に記載されているヘッダ圧縮技術は、最初に、全てのフィール
ドを含む完全な（圧縮されていない）ＲＴＰパケットをＲＴＰデスティネーショ
ン／レシーバーに送る。接続中ヘッダのフィールドの多くには変化が無く、従っ
て、最初のパケットが送られて受信された後は送られなくても良い。殆どのパケ
ットについては、シーケンス番号とタイムスタンプだけがパケット毎に変化する
。ＲＦＣ２５０８に従って、不変ではないフィールド（例えば、タイムスタンプ
及びシーケンス番号）は、（固定されている）一次差をレシーバーに蓄積されて
いるそれらのフィールドの前の値に加えることによってレシーバーで更新される
。例えば、受信された各々のＲＴＰパケットのシーケンス番号は各パケットにつ
いて１だけ自動的にインクリメントされる。不変ではないフィールドにおける付
加的なジャンプまたは変化（即ち、一次差とは異なる）は別々にレシーバーに送
られなければならない。あいにく、ＲＦＣ２５０８では、前のヘッダの喪失はレ
シーバーにおける解凍を無効にする。また、差のサイズは変化し、それはＲＦＣ
２５０８の圧縮技術を用いて帯域幅を管理し予測することをいっそう困難にする
。

【００２５】 本発明の実施態様に従って、パケット・ヘッダのＲＴＰタイムスタンプ（また
は他のフィールド）をより効率良く圧縮するために使用することのできるヘッダ
圧縮技術が提供される。本発明の実施態様に従って、該圧縮方式はＲＴＰタイム
スタンプ値の任意のジャンプに配慮し、同時に一定サイズの圧縮されているＲＴ
Ｐヘッダ（または一定サイズＲＴＰタイムスタンプ）を生じさせることができる
。

【００２６】 図４は、本発明の実施例に従う圧縮されているＲＴＰヘッダ・フォーマットを
図解する図である。図４に示されているように、圧縮されているＲＴＰヘッダは
、メッセージのタイプを示すメッセージ・タイプ４１０と、変化するフィールド
を特定するビット・マスク４１２と、圧縮されているタイムスタンプ・フィール
ド４１４とから成ることができる。メッセージ・タイプ４１０は、もし圧縮され
ているタイムスタンプがパケット・ヘッダに設けられているならば、圧縮されて
いるタイムスタンプを示すことができる。本発明の実施態様に従って、圧縮され
ているタイムスタンプ・フィールド４１４は、パケットとパケットとの間に経過
した時間を示すことのできる値のｋ個の最下位ビット（ｌｓｂｓ）を含む。本発
明の実施態様に従って、圧縮されているタイムスタンプ４１４はソース・カウン
ター値（またはカウンター差）の一部分（即ち、ｋ個の最下位ビット）を提供す
ることができる。ソース・カウンターは、各ＲＴＰパケット・ヘッダについてタ
イムスタンプを作るために使用されることができる。オプション・フィールド４
１６は、ビット・マスク４１２で特定されているフィールドのために更新されて
いるまたは変更されているフィールドを提供するために使用されることができる
。

【００２７】 Ｂ．タイムスタンプ圧縮及び解凍の全動作 本発明の実施態様に従って、ＲＴＰタイムスタンプの圧縮及び解凍を簡単に説
明する。実施態様に従って、ＲＴＰパケットはＲＴＰエンドポイント（端末１０
２のＲＴＰエンドポイント１０４など）で作られて他のＲＴＰエンドポイントへ
アドレス指定される。この例では、ＲＴＰエンドポイント１０４は、端末１３０
のＲＴＰエンドポイント１３２（デスティネーション）へ送られるべき１つ以上
のＲＴＰパケットのソースである。ＲＴＰパケット・ヘッダはタイムスタンプを
含み、それは柱時計に基づいてＲＴＰソースで（例えば端末１０２で）作られる
。

【００２８】 ＲＴＰパケットは、ＩＰネットワーク１０８を介してＡＮＩ１１０のＡＮＩ＿
ＡＤ１１２へ送られる。ＡＮＩ＿ＡＤ１１２はＲＴＰパケットのヘッダの１つ以
上のフィールドを圧縮する。特に、ＡＮＩ＿ＡＤは、ＲＴＰタイムスタンプ３１
０（図３）を圧縮して圧縮済みタイムスタンプ４１４（図４）にする。ヘッダ内
の他のフィールドは、それらを除去することにより或いは他の何らかの技術を用
いることにより、圧縮されることができる。圧縮されているタイムスタンプ４１
４を含むＲＴＰパケットは、ＲＦリンク１４０のダウンリンク１４４を介して端
末１３０へ送られる。

【００２９】 圧縮されているヘッダ（即ち、圧縮されているタイムスタンプ４１４）を伴う
ＲＴＰパケットを受信すると、端末１３０の端末アダプター（ｔｅｒｍ＿ＡＤ）
１３６はタイムスタンプ値を解凍する。端末アダプター１３６は、始めにタイマ
ー１３４の現在の値に基づいてタイムスタンプの見積もりまたは近似値を計算す
ることにより、圧縮されているタイムスタンプ４１４を解凍する。次にそのタイ
ムスタンプの近似値は、パケット・ヘッダに設けられている圧縮されているタイ
ムスタンプ４１４に基づいて改良または訂正される。この様に、現在のパケット
（ヘッダ）についてのタイムスタンプは、ローカル・タイマー（タイマー１３４
）と、現在のヘッダに設けられている圧縮されているタイムスタンプとに基づい
て再生される。該パケット・ヘッダの他のフィールド（シーケンス番号など）も
再生されることができる。該パケットと再生されたタイムスタンプとは、処理の
ためにＲＴＰエンドポイント１３２へ供給される。するとＲＴＰエンドポイント
１３２は、（シーケンス番号により明示される）正しい順序で且つ（例えば沈黙
の間隔を償うために）再生されたタイムスタンプにより明示される適切なタイミ
ングをもって、音声サンプルを再生する。

【００３０】 ＡＮＩ＿ＡＤ１１２はＲＦリンク１４０を介して（圧縮されているタイムスタ
ンプを含む）圧縮されているヘッダを受信することもでき、前記のタイマーに基
づく解凍技術を用いてそのタイムスタンプを解凍する。従って、ＡＮＩ＿ＡＤ１
１２は、該ＡＮＩ＿ＡＤが前記のように圧縮されているタイムスタンプを解凍し
得るように通常はタイマーを含むことができる。同様に、端末１３０のｔｅｒｍ
＿ＡＤ１３６も、ＲＴＰパケットがＲＦリンク１４０を介してＡＮＩ１１０へ送
られる前に該ＲＴＰパケットのタイムスタンプを圧縮することができる。本発明
の実施例の説明を簡単にするために、説明の大半はダウンリンク経路１４４へ向
けられる。本発明の実施態様に従って、ＲＴＰパケットは両方向（アップリンク
１４２及びダウンリンク１４４）に送られることができる。従って、ＡＮＩ１１
０のＡＮＩ＿ＡＤ１１２と端末１３０のｔｅｒｍ＿ＡＤとは、共に、（ＲＦリン
ク経由でのヘッダ／パケットの伝送のための）タイムスタンプ圧縮器及び（ＲＦ
リンク１４０を介して受信される圧縮されているヘッダの受信の後）解凍器とし
て作用することができる。

【００３１】 Ｃ．タイムスタンプ圧縮及び解凍の実施例 タイムスタンプ圧縮及び解凍の実施例を簡単に説明する。ＲＴＰパケット内の
データは音声データであると仮定する。下記の変数及び式は本発明の特徴の幾つ
かを説明する助けとなるように定義されているに過ぎず、本発明はそれに限定さ
れない。また、本発明は、同じまたは類似のタイプの変数を使用するシステムに
は限定されず、また以下に記載する特定の計算を実行するシステムに限定されな
い。それらの変数及び計算は単に本発明の実施例として提供されるに過ぎない。 Ｔ−はＲＴＰ音声サンプル間の時間間隔である。（もし各ＲＴＰパケットに１
つの音声サンプルが供給されているならば、ＴはＲＴＰパケット・ヘッダ間の間
隔でもある）。 ＴＳ−タイムスタンプ ＴＳ＿ｓｔｒｉｄｅ−ＲＴＰタイムスタンプはＴミリ秒毎にＴＳ＿ｓｔｒｉｄ
ｅだけインクリメントされる。換言すると、ＲＴＰタイムスタンプは新しいＲＴ
Ｐパケット毎にＴＳ＿ｓｔｒｉｄｅだけ大きくなる。ＴＳ＿ｓｔｒｉｄｅは、音
声コーデックに依存する定数（例えば１００）である。ＴＳ＿ｓｔｒｉｄｅは、
レシーバー（端末１３０）とＡＮＩ＿ＡＤ１１２とに供給される。 ＴＳ０−ＲＴＰレシーバーで受信されるセッションの第１ヘッダのＲＴＰタイ
ムスタンプ。セッションの第１ヘッダは、同期化のために使われるので、同期化
ヘッダであると見なされる。ＴＳ０は、セッションの始めに（同期化のために）
圧縮器（例えば、ＡＮＩ＿ＡＤ１１２）と解凍器（例えばｔｅｒｍ＿ＡＤ１３６
）との両方に供給されるＲＴＰタイムスタンプの初期値である。一つの実施態様
に従って、ＡＮＩ＿ＡＤとｔｅｒｍ＿ＡＤとは、圧縮されていないヘッダ（ＴＳ
０を与える圧縮されていないタイムスタンプを含む）を伴うＲＴＰパケットを受
信することにより初期化或いは同期化される。本発明の一つの実施態様に従って
、タイマーに基づく解凍技術は、初期タイムスタンプＴＳ０を（例えば、圧縮さ
れていない最初のまたは同期化ヘッダを通して）タイムスタンプ圧縮器（即ち、
ＡＮＩ＿ＡＤ１１２）に供給すると共に、圧縮されているヘッダが適切に解凍さ
れる前に（即ち、解凍器が該タイムスタンプを正しく再生できるように）解凍器
（即ち、ｔｅｒｍ＿ＡＤ１３６）に供給することを必要とする。 （時間ｍ＊Ｔミリ秒において作られた）パケット・ヘッダｍのＲＴＰタイムス
タンプ＝ＴＳ０＋ＴＳ＿ｓｔｒｉｄｅ＊ｍ。これは、各音声サンプルについて１
つのヘッダがあることを仮定している。以下で説明する例において示されるよう
に、この式は、１パケット・ヘッダあたりに複数の音声サンプル（例えば、３音
声サンプル）がある場合に拡張されることができる。 ｍ−送られた音声サンプルの数を示す整数。ｍは、セッションの始めに０にリ
セットまたはクリアされる。ｍは、セッションの始まりから経過した時間の量に
比例し（またはその量を示す）。ｍは、Ｔミリ秒毎に１だけインクリメントされ
る。 ＴＳ＿ｃｕｒｒｅｎｔ＝ＴＳ０＋ｍ＿ｃｕｒｒｅｎｔ＊ＴＳ＿ｓｔｒｉｄｅ；
現在のパケット・ヘッダについての現在のタイムスタンプ。 レシーバー・タイマー−端末１３０のタイマー１３４などの、ＲＴＰレシーバ
ー（またはＲＴＰデスティネーション）にあるタイマー。ローカル・レシーバー
・タイマーは通常はフリーランニングであり、セッションの始まりにリセットさ
れない。むしろ、２つのパケット・ヘッダの受信の間にＲＴＰレシーバーで経過
した時間を、前のパケット・ヘッダが受信されたときのレシーバー・タイマー値
から現在のヘッダのタイマー値を差し引くことによって、得ることができる。レ
シーバー・タイマーがフリーランニングすることを許すことにより、１つのレシ
ーバー・タイマーを多数のフローまたはセッションが共有することができる。そ
の代わりに、レシーバー・タイマーを各セッションの始めにリセットすることが
できる。セッションの始めに（即ち、初期化ヘッダの受信時に）レシーバー・タ
イマーをリセットまたはクリアするためには、各セッションまたはフローのため
に専用のレシーバー・タイマー（タイマー・プロセス）が必要となろう。セッシ
ョンの第１の圧縮されていないタイムスタンプ（ＴＳ０）を初期化ヘッダでＡＮ
Ｉ＿ＡＤ及びｔｅｒｍ＿ＡＤに供給することができる。第１ヘッダは、圧縮器（
ＡＮＩ＿ＡＤ１１２）及び解凍器（ｔｅｒｍ＿ＡＤ１３６）を初期化するために
供給される。その後、レシーバー・タイマーはＴミリ秒毎に１だけインクリメン
トされる。ＡＮＩ＿ＡＤ１１２（圧縮器）は、ＴＳ０値を使用してその後のＲＴ
Ｐパケット・ヘッダのタイムスタンプを圧縮する。ｔｅｒｍ＿ＡＤ１３６（解凍
器）は、ＴＳ０値を使用して、圧縮されているタイムスタンプ値を解凍する（例
えば、その後に受信されたＲＴＰヘッダのタイムスタンプを再生するために）。 ｃｕｒｒｅｎｔ＿ｔｉｍｅｒ−現在のヘッダが受信されたときのＲＴＰレシー
バー（例えば、端末１３０）におけるタイマーの値 ｌａｓｔ＿ｔｉｍｅｒ−最後のヘッダが受信されたときのレシーバーにおける
時間の値。（タイムスタンプの次のヘッダ計算のためにｃｕｒｒｅｎｔ＿ｔｉｍ
ｅｒはｌａｓｔ＿ｔｉｍｅｒとして蓄積される）。 ｍ＿ｌａｓｔ−最後に受信されたヘッダについてのｍの値；ｍは初期化ヘッダ
から経過した音声フレームの数を示す。

【００３２】 現在のパケットのタイムスタンプを圧縮するために、ＡＮＩ＿ＡＤ１１２はｍ
の現在の値を： ｍ＿ｃｕｒｒｅｎｔ＝（ＴＳ＿ｃｕｒｒｅｎｔ−ＴＳ０）／Ｔ
Ｓ＿ｓｔｒｉｄｅとして計算する。従って、ＡＮＩ＿ＡＤは、（セッションの始
めにおける）タイムスタンプの初期値を現在のタイムスタンプから差し引く。こ
の差は、タイムスタンプ・ストライド（ＴＳ＿ｓｔｒｉｄｅ）で割られる。しか
し、或る実施態様では、割り算を実際に実行することは不要であるかも知れない
。割り算を実行せずにｍ＿ｃｕｒｒｅｎｔを適切に作るために他の方法を使用す
ることができるが、それは高いプロセッサ・オーバーヘッドを必要とするかも知
れない。

【００３３】 その後、ｍ＿ｃｕｒｒｅｎｔのｋ個の最下位ビットが圧縮されているタイムス
タンプ４１４として供給される。圧縮されているタイムスタンプ４１４を含むＲ
ＴＰパケットは、ＲＦリンク１４０を介してＲＴＰデスティネーションまたはレ
シーバー（例えば、端末１３０）に送られる。

【００３４】 ＲＴＰレシーバー（例えば、端末１３０）において、端末アダプター（ｔｅｒ
ｍ＿ＡＤ）１３６は、圧縮されているタイムスタンプ４１４を解凍する。前のヘ
ッダのｃｕｒｒｅｎｔ＿ｔｉｍｅｒ値は始めにｌａｓｔ＿ｔｉｍｅｒとして蓄積
される。それから、現在のヘッダが到達したとき、ｔｅｒｍ＿ＡＤ１３６はレシ
ーバー・タイマー１３４の値を読み、それをｃｕｒｒｅｎｔ＿ｔｉｍｅｒとして
メモリーに蓄積する。次に、ｔｉｍｅｒ＿ｄｉｆｆがｔｉｍｅｒ＿ｄｉｆｆ＝ｃ
ｕｒｒｅｎｔ＿ｔｉｍｅｒ−ｌａｓｔ＿ｔｉｍｅｒとして計算される。ＡＮＩ＿
ＡＤは整数ｄを発見することによりｍ＿ｃｕｒｒｅｎｔの正確な値を計算し、こ
こで： （−Ｌ／２＜ｄ≦Ｌ／２、ここでＬ＝２^k）： （方程式１） （ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）のｋ個の最下位ビット＝圧
縮されているタイムスタンプ４１４（現在のヘッダについての）である。 （方程式２）

【００３５】 前記の様に、受信される圧縮されているタイムスタンプもｋビットである。方
程式１及び２を用いてｄが計算されると、次にＴＳ＿ｃｕｒｒｅｎｔを： ＴＳ＿ｃｕｒｒｅｎｔ＝ＴＳ０＋（ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉ
ｆｆ）＊ＴＳ＿ｓｔｒｉｄｅ （方程式３） として計算することができる。方程式３において、ｍ＿ｃｕｒｒｅｎｔの実際の
または正しい値は（ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）として括弧内に
示されている。ｍ＿ｌａｓｔ＋ｔｉｍｅｒはｍ＿ｃｕｒｒｅｎｔの近似値であり
、ｄはｍ＿ｃｕｒｒｅｎｔの近似値とｍ＿ｃｕｒｒｅｎｔの正しい値との差であ
る。また、ＴＳ０＋（ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）＊ＴＳ＿ｓｔｒｉ
ｄｅは現在のタイムスタンプ値の近似値であり、ｄ＊ＴＳ＿ｓｔｒｉｄｅは、近
似された現在のタイムスタンプと現在のタイムスタンプの実際の（または正しい
）値との差である。

【００３６】 従って、ＲＴＰレシーバーは、始めに、現在のヘッダと（正しく解凍された）
前のヘッダの受信の間に経過した時間に基づいて現在のタイムスタンプの近似値
（または見積もり）を：近似された現在のタイムスタンプ＝ＴＳ０＋（ｍ＿ｌａ
ｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）＊ＴＳ＿ｓｔｒｉｄｅ、として計算することが分
かる。その近似された現在のタイムスタンプは、次に、正しい現在のタイムスタ
ンプ値（ＴＳ＿ｃｕｒｒｅｎｔ）を計算するためにｄ＊ＴＳ＿ｓｔｒｉｄｅの量
だけ調整または訂正される。

【００３７】 ＴＳ＿ｃｕｒｒｅｎｔが計算された後、現在のＲＴＰパケット（その再生され
たまたは解凍されたタイムスタンプ、ＴＳ＿ｃｕｒｒｅｎｔ、を含む）がＲＴＰ
エンドポイント１３２まで供給される。この圧縮及び解凍のプロセスはＲＴＰエ
ンドポイントにとっては透明である。

【００３８】 図５は、本発明の実施態様に従うヘッダ圧縮及び解凍の動作例を図解する図で
ある。この例は、本発明の幾つかの特徴を例証するために前述の具体的な式の一
部を適用する。この実施例では、ＲＴＰソース５０２とＲＴＰレシーバー５０４
とのタイマーは同じ周波数を有するけれども通常は同期していないということが
仮定されている。ＲＴＰソースのタイマー（例えば、Ｔミリ秒毎に１だけインク
リメントする）はタイムスタンプを作るために使用され、ＲＴＰレシーバーのタ
イマー（例えば、タイマー１３４）はＲＴＰタイムスタンプを再生または解凍す
るために使用される。

【００３９】 図５を参照すると、セッションの始めに、初期タイムスタンプ値（ＴＳ０）を
含む初期化ヘッダ５０８がＲＴＰソースで作られる。初期化ヘッダ５０８はＡＮ
Ｉに送られ、次にＲＴＰレシーバー５０４（例えば、端末１３０）に回送される
。初期化ヘッダ内のタイムスタンプは圧縮されていない。初期化ヘッダが受信さ
れると、初期タイムスタンプ値（ＴＳ０）はＴＳ＿ｓｔｒｉｄｅと共にＡＮＩ＿
ＡＤのメモリーに蓄積される。１実施態様では、二つの初期化ヘッダがＡＮＩ＿
ＡＤに送られることができる。その後、ＡＮＩ＿ＡＤはＴＳ＿ｓｔｒｉｄｅを第
２タイムスタンプ−第１タイムスタンプとして計算することができる。ｔｅｒｍ
＿ＡＤは同様にＴＳ＿ｓｔｒｉｄｅを計算し或いはパケットでその値を受け取る
ことができる。

【００４０】 同様に、初期化ヘッダ５０８がＲＴＰレシーバー（端末１３０）に受信された
とき、初期タイムスタンプ（ＴＳ０）はＴＳ＿ｓｔｒｉｄｅと共にメモリーに蓄
積される。また、初期化ヘッダ５０８の受信５１０時に（図５）、ｍ＿ｃｕｒｒ
ｅｎｔがクリアされまたはゼロ（０）にリセットされ、次にレシーバー・タイマ
ーが読まれてｉｎｉｔｉａｌ＿ｒｅｃｅｉｖｅｒ＿ｔｉｍｅｒとして蓄積される
、５１６。セッションの始まりにタイマーを読む代わりに、レシーバー・タイマ
ーをリセットまたはクリアすることができる。この例では、セッションの始まり
におけるレシーバー・タイマーの読まれた値は簡単のためにたまたまゼロ（０）
である。従って、セッションの始まりにフリーランニングのタイマーがゼロとし
て読まれるので、図５に示されている例は両方の実施態様（単にレシーバー・タ
イマーを読むか、またはそれをゼロにリセットする）にあてはまる。同様に、ｍ
＿ｃｕｒｒｅｎｔをクリアする必要はなくて、その代わりにｍ＿ｃｕｒｒｅｎｔ
について一つの値を記録することができる。その後、レシーバー・タイマーはＴ
ミリ秒毎に（例えば、１だけ）インクリメントされる。（これは、タイムスタン
プを作るために使われるＲＴＰソース５０２のタイマーと同じ周波数である）。
初期化ヘッダ５０８は、固定された遅延（バルク遅延５１２）及び可変遅延（累
積ジッター５１４）の後にＲＴＰレシーバー５０２に到着する。

【００４１】 次に、ＲＴＰソース５０２は次のＲＴＰパケット（初期化ヘッダ後の該セッシ
ョンの第１ＲＴＰパケット）を作る。このＲＴＰパケットは、初期化ヘッダが作
られてから３＊Ｔミリ秒後に作られ、従って通常は、例えば、３音声サンプルを
含む。他の数も可能である。従って、図５に示されているように、このパケット
のヘッダについてのタイムスタンプは：ＴＳ（１）＝ＴＳ０＋３＊ＴＳ＿ｓｔｒ
ｉｄｅである。ＴＳ（１）は、初期化から３Ｔミリ秒後に作られるタイムスタン
プを指す。この例では、例えば、ＴＳ＿ｓｔｒｉｄｅは１００であるということ
が仮定される。ＴＳ０は、例えば、０であると仮定される。従って、ＴＳ（１）
＝３００である。

【００４２】 このパケットについてのタイムスタンプ値ＴＳ（１）は、ＡＮＩ＿ＡＤで受信
され、ＴＳ（１）（該タイムスタンプ値）、ＴＳ０（初期タイムスタンプ値）及
びＴＳ＿ｓｔｒｉｄｅ（タイムスタンプがＴミリ秒毎にインクリメントする量）
に基づいて圧縮される。一つの実施例では、圧縮されているタイムスタンプをｍ
＿ｃｕｒｒｅｎｔのｋ個の最下位ビットとして計算することができる。ＡＮＩ＿
ＡＤ１１２は、ｍの現在の値を：ｍ＿ｃｕｒｒｅｎｔ＝（ＴＳ＿ｃｕｒｒｅｎｔ
−ＴＳ０）／ＴＳ＿ｓｔｒｉｄｅとして計算する。この例では、ＴＳ＿ｓｔｒｉ
ｄｅは例えば１００であると仮定される。この例では、ｍ＿ｃｕｒｒｅｎｔは：
ｍ＿ｃｕｒｒｅｎｔ＝（３００−０）／１００＝３として計算される。この例で
はｋは２である。従って、ｍ＿ｃｕｒｒｅｎｔの２個の最下位ビット（二進数で
１１）がこのパケットについての圧縮されているタイムスタンプ４１４（ＣＴＳ
１）として供給される、図５。

【００４３】 圧縮されているタイムスタンプ（ＣＴＳ１）はＲＴＰレシーバー５０２に到達
し、ＲＴＰレシーバーのｔｅｒｍ＿ＡＤ１３６は、現在のパケットについて、タ
イムスタンプＴＳ（１）を再生または解凍する。ｃｕｒｒｅｎｔ＿ｔｉｍｅｒの
値（ゼロ）はｌａｓｔ＿ｔｉｍｅｒとして蓄積され、ｍ＿ｃｕｒｒｅｎｔはｍ＿
ｌａｓｔとして蓄積される。ｍ＿ｃｕｒｒｅｎｔは前にセッションの始まりに（
即ち、同期化ヘッダの受信時に）ゼロにセットされた。レシーバー・タイマー値
（この場合は３）が読まれてｃｕｒｒｅｎｔ＿ｔｉｍｅｒとして蓄積される。次
にＴｉｍｅｒ＿ｄｉｆｆがｃｕｒｒｅｎｔ＿ｔｉｍｅｒ−ｌａｓｔ＿ｔｉｍｅｒ
として計算され、それは３−０＝３である。Ｔｉｍｅｒ＿ｄｉｆｆ＋ｍ＿ｌａｓ
ｔはｍ＿ｃｕｒｒｅｎｔの近似値である。

【００４４】 次にｔｅｒｍ＿ＡＤ１３６は、方程式（１）及び（２）を用いてｍ＿ｃｕｒｒ
ｅｎｔの正確なまたは訂正された値を計算する。方程式（２）を使用すると、（
ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）の２個の最下位ビット＝ＣＴＳ１（
現在のヘッダについての圧縮されているタイムスタンプ）である。この場合には
、ｍ＿ｌａｓｔはゼロ（０）であり、ｔｉｍｅｒ＿ｄｉｆｆは３であり、ＣＴＳ
１は３である。従って、（ｄ＋０＋３）の２個の最下位ビット＝３である。従っ
て、ｄはゼロに等しい。

【００４５】 次に方程式（３）を用いて、このパケットについての解凍されているタイムス
タンプが：ＴＳ（１）＝ＴＳ０＋（ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）
＊ＴＳ＿ｓｔｒｉｄｅとして計算される。従って、その結果として、ＴＳ（１）
＝０＋（０＋０＋３）＊１００＝３００である。このパケットについての解凍さ
れているタイムスタンプＴＳ（１）＝３００は、次に、ＲＴＰデータ及び他の解
凍されているヘッダ・フィールドと共に、ＲＴＰソースのＲＴＰエンドポイント
１３２に供給される。ｍ＿ｃｕｒｒｅｎｔについての正しいまたは実際の値は（
ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）である。従って、このパケットにつ
いては、ｍ＿ｃｕｒｒｅｎｔの近似値はｍ＿ｃｕｒｒｅｎｔの正しい値と同じで
あることが分かる（しかし、一般の場合にはそうではない）。次にｍ＿ｃｕｒｒ
ｅｎｔは更新されて３になる。

【００４６】 次のパケット及びタイムスタンプが、タイムスタンプＴＳ（２）＝０＋６＊１
００＝６００を含めて、ＲＴＰソースで作られる。ＡＮＩ＿ＡＤにおいて、ＴＳ
（２）＝６００は（６００−０）／１００＝６の２個の最下位ビットとして圧縮
されて圧縮済みタイムスタンプとなる。この場合、６の二進数は１１０である。
従って、１１０の２個の最下位ビットは１０である。従って、ＣＴＳ２は二進数
で１０である。

【００４７】 次に、このパケットについての圧縮されているタイムスタンプ（ＣＴＳ２）は
バルク遅延及び累積ジッターのためにレシーバー・タイマーが７の値に到達した
後にｔｅｒｍ＿ＡＤ１３６で受信される。ｃｕｒｒｅｎｔ＿Ｔｉｍｅｒの値（３
）はｌａｓｔ＿ｔｉｍｅｒとして蓄積され、ｍ＿ｃｕｒｒｅｎｔ（３）はｍ＿ｌ
ａｓｔとして蓄積される。現在のレシーバー・タイマー値（この場合には７）が
読まれてｃｕｒｒｅｎｔ＿ｔｉｍｅｒとして蓄積される。次にｔｉｍｅｒ＿ｄｉ
ｆｆがｃｕｒｒｅｎｔ＿ｔｉｍｅｒ−ｌａｓｔ＿ｔｉｍｅｒとして計算され、そ
れは７−３＝４である。ｔｉｍｅｒ＿ｄｉｆｆ＋ｍ＿ｌａｓｔはｍ＿ｃｕｒｒｅ
ｎｔの近似値であり、それは７である。

【００４８】 次に、ｔｅｒｍ＿ＡＤ１３６は、方程式（１）及び（２）を用いてｍ＿ｃｕｒ
ｒｅｎｔについての正確なまたは訂正された値を計算する。方程式（２）を用い
ると、（ｄ＋ｍ＿ｌａｓｔ＋ｔｉｍｅｒ＿ｄｉｆｆ）の２個の最下位ビット＝Ｃ
ＴＳ（２）（現在のヘッダについての圧縮されているタイムスタンプ）である。
この場合、ｍ＿ｌａｓｔは３であり、ｔｉｍｅｒ＿ｄｉｆｆは４であり、ＣＴＳ
２は１０（二進数、これは十進法では３である）である。方程式２はｄについて
次のように解かれる：２ｌｓｂｓ（ｄ＋３＋４）＝２。７は二進法では１１１で
ある。従ってｄ＝−１である。ｄは、ｍ＿ｃｕｒｒｅｎｔの近似値とｍ＿ｃｕｒ
ｒｅｎｔの実際の値との差である。ｄを方程式（３）に入れて、このパケットに
ついてのタイムスタンプはＴＳ（２）＝０＋（−１＋３＋４）＊１００＝６００
として計算される。従って、ＲＴＰレシーバーのｔｅｒｍ＿ＡＤ１３６は、ロー
カル・タイマーと圧縮されているタイムスタンプとに基づいてＲＴＰタイムスタ
ンプを正しく再生（例えば解凍）している。

【００４９】 前の技術とは違って、１つ以上のパケットがＲＴＰレシーバーに到着しなかっ
た場合に初期化ヘッダを送り直す必要がないことに注意するべきである。換言す
ると、ＲＴＰソースとレシーバーとの同期化はセッションまたは接続の始まりに
１回だけ必要である。その理由は、現在のタイムスタンプがＲＴＰレシーバーに
おいてｍ＿ｌａｓｔ及びｔｉｍｅｒ＿ｄｉｆｆの両方に基づいて計算されること
にある。ｔｉｍｅｒ＿ｄｉｆｆはｃｕｒｒｅｎｔ＿ｔｉｍｅｒ−ｌａｓｔ＿ｔｉ
ｍｅｒとして計算される。従って、ｍ＿ｌａｓｔ及びｌａｓｔ＿ｔｉｍｅｒの値
は、どのパケットが最後に受信されたかということとは関わりなく（例えば、“
最後の”パケットの後に送られたパケットが間違って落とされまたは失われたか
ということとは無関係に）、最後のパケットに対応する。その結果として、本発
明の実施態様に従うタイマーに基づく圧縮方式は、エラーに対して強くて、また
エラーが検出された（例えば、１つ以上のパケットが落とされまたは失われた）
場合に（例えば全てのヘッダについて完全な圧縮されていない値を含む）新しい
同期化パケットを送る必要がないので、帯域幅要件を減少させる。

【００５０】 正常な動作時には、ｍ＿ｃｕｒｒｅｎｔの近似値と正確な値との食い違いの原
因は： ａ）ＲＴＰタイムスタンプの真のソースとレシーバーとの間の累積ジッター；
実際の遅延＝バルク遅延＋累積ジッター、ここでバルク遅延は一定であり、累積
ジッターはヘッダ毎に変化し、０≦累積ジッター≦最大累積ジッターである；並
びに ｂ）タイマーの実施態様に依存する、タイマー・プロセスと解凍器プロセスと
の存在することのある非同時性。その非同時性に起因して、タイマー値（ｃｕｒ
ｒｅｎｔ＿ｔｉｍｅｒ）にプラスまたはマイナスのまたは１（＋または−１）の
エラーがあり得る。

【００５１】 図６は、本発明のもう一つの実施態様に従うヘッダ圧縮及び解凍の動作例を図
解する図である。図５と同じく、図６はジッターとタイマー非同時性との効果を
図解する図である。図５では、レシーバー・タイマーはセッションの始まりにだ
けリセットまたはクリアされる。（レシーバー・タイマーはただ動作し続けるこ
とを許されるので、これは不要である。）しかし、図６で図解されている実施例
では、レシーバー・タイマーは各パケットについてゼロ（０）にリセットまたは
クリアされる。従って、圧縮されているパケット・ヘッダが受信されると、タイ
マー値が読まれ、それは前記のｔｉｍｅｒ＿ｄｉｆｆ値を示す（タイマーは最後
のパケット・ヘッダから経過した時間を示すので）。本発明を実施する方法はい
ろいろあり得る。重要なことは、最後に首尾良く解凍されたタイムスタンプと現
在のタイムスタンプとの間の（ローカル・レシーバー・タイマーにより測定され
た）経過時間を示すタイマー差が測定されるべきであるということである（図５
に記載されているｔｉｍｅｒ＿ｄｉｆｆ）。

【００５２】 図６を参照すると、ヘッダｎがタイムスタンプ＝ＴＳ０＋３＊ＴＳ＿ｓｔｒｉ
ｄｅを伴って作られる。ヘッダｎのこのタイムスタンプは、圧縮されてＲＴＰレ
シーバーに送られ、解凍される。そのときレシーバーにおいてタイマーがリセッ
トされる。次のヘッダ、（ｎ＋１）、（ｎ＋２）及び（ｎ＋３）が作られて送ら
れるが、ヘッダ（ｎ＋３）だけが受信される（即ち、ヘッダｎ＋１とｎ＋２とは
失われる）。簡単のためにヘッダ（ｎ＋２）と（ｎ＋３）とは図６に示されては
いない。ヘッダ（ｎ＋１）は図６においてヘッダｍ＋ｎとして示されている。ヘ
ッダ（ｍ＋ｎ）は、タイムスタンプＴＳ＝ＴＳ０＋６＊ＴＳ＿ｓｔｒｉｄｅを伴
って作られて送られる。ヘッダ（ｍ＋ｎ）のこのタイムスタンプは圧縮され、次
にＲＴＰレシーバーに送られる。タイマー値は４である（ｔｉｍｅｒ＿ｄｉｆｆ
を示す）。この値は、ヘッダ（ｍ＋ｎ）についてのタイムスタンプを解凍するた
めに使用される。従って、図６においては各ヘッダの受信後にタイマーがリセッ
トされることを除いて、図６の例は図５に示されている例に非常に良く似ている
。

【００５３】 どの技術が用いられるかに関わらず（図５または図６）、効率的なタイマーに
基づく圧縮方式を用いることができる。しかし、もし累積ジッターが過度であれ
ば、圧縮されているタイムスタンプに基づいて正しいタイムスタンプを再生でき
ない可能性がある。多くの事例において、図５及び／又は図６に図解されている
タイマーに基づく圧縮方式が適切に働くことを可能にするためにはｋにより次の
条件が満たされるべきである： [条件１]（最大積分ジッター＋２）＜２^k、 ここで最大積分ジッター（ＭＩＪ）は、Ｔミリ秒の単位で表示された、次に大き
い整数に丸められた最大累積ジッターである。例えば、もしＴ＝２０ミリ秒であ
るならば、１５ミリ秒の最大累積ジッターはＭＩＪ＝１という結果をもたらす。
タイマー非同時性に起因して生じる可能性のあるエラーを償うために２がそのＭ
ＩＪに加えられる。

【００５４】 会話実時間要件のために、正常動作時の累積ジッターはＴミリ秒のわずか数倍
であるかも知れない。従って、その様な場合には、ＲＴＰレシーバーにおいて１
６音声サンプル（即ち、１６＊Ｔミリ秒）に及ぶ食い違いが訂正され得るので、
４に等しいｋの値は十二分であろう。異常なまたはエラー状態は、ジッターが正
常値を上回るという結果をもたらすかも知れない。圧縮器から見たジッターが許
容し得る範囲内にとどまることを確実にするために圧縮器の上流側にジッター減
少エンティティーを加えることができる。

【００５５】 図５及び／又は６に図解されているタイムスタンプ圧縮方式の利点は下記を含
む： ａ）タイムスタンプのサイズが一定で小さい。圧縮されているヘッダは通常は
、メッセージのタイプを示すメッセージ・タイプと（ｋ１ビット）、どのフィー
ルドが変化しているか示すビット・マスクと、ｍ＿ｃｕｒｒｅｎｔのｋ個の最下
位ビットを含むフィールド（ｋビット）とから成る。ＲＦＣ２５０８の場合と同
じく４ビットＭＳＴ１ビット・マスクが使用され、且つｋ１＝４であると仮定す
ると、ＲＴＰ ＴＳだけが変化するとき（この場合がずばぬけて頻繁である）圧
縮されているヘッダのサイズは１．５バイトである。更に、サイズは沈黙の間隔
の長さの関数としては変化しない。 ｂ）例えば図６に示されているように、レシーバー・タイマーは（最初のタイ
ムスタンプを作るために使用される）ＲＴＰソース・タイマーと同じ周波数で動
作する；ソース・タイマーとレシーバー・タイマーとの位相同期化は不要である
（それは測定された経過時間であるから、レシーバー・タイマーはタイムスタン
プを再生するために使用されるものである）。 ｃ）レシーバーにおいて、タイマー・プロセスと解凍器プロセスとの同期化は
不要である。例えばタイマー・プロセスはＴミリ秒毎にタイマーを１だけインク
リメントして良く、解凍器プロセスは新しいヘッダが受信されたときに解凍を行
うべく目覚めさせられる。しかし、タイマーがインクリメントする点とヘッダが
受信される点とが整列或いは同期化される必要はない（図６を参照）。 ｄ）エラーに対する強さ、圧縮されているヘッダ内の部分的ＲＴＰ ＴＳ情報
は自己充足していて、完全なＲＴＰ ＴＳ値を作るためにはレシーバー・タイマ
ーと結合されることを必要とするだけである。ヘッダの喪失或いは破損は、後の
圧縮されているヘッダを無効にはしない。 ｅ）ＲＴＰ ＴＳ圧縮／解凍を目的としてメモリー又は値を圧縮器により維持
または蓄積する必要はない。

【００５６】 Ｄ．ハンドオフ 一つの実施態様では、各ＡＮＩ＿ＡＤは特定の地域に割り当てられる（例えば
、特定の地域に置かれている端末とインターフェースする）。端末（端末１３０
など）は１つの地域から他へと移動することができる。端末が１つの地域から他
へ移動するとき、端末は１つのＡＮＩ＿ＡＤから他のＡＮＩ＿ＡＤへと渡され、
或いは転換されなければならない。

【００５７】 考察するべきハンドオフの一つの場合はＡＮＩ＿ＡＤ間ハンドオフであり、そ
の場合には旧ＡＮＩ＿ＡＤから新ＡＮＩ＿ＡＤへの転換により引き起こされる中
断があることがある。問題は、ハンドオフ後にｔｅｒｍ＿ＡＤ１３６及び新ＡＮ
Ｉ＿ＡＤにおいて圧縮／解凍が中断無く続くように、ハンドオフ中に情報の連続
性をどの様にして維持するかということである。

【００５８】 １．ダウンリンク レシーバー側に不連続性は無いが、それは端末である（例えば、端末１３０、
図１）。圧縮器の役割は一つのＡＮＩ＿ＡＤから他へと移される。ハンドオフ後
、ヘッダは旧ＡＮＩ＿ＡＤの代わりに新ＡＮＩ＿ＡＤを通る新しい経路で送られ
る。更に、システムのデザインにより、ハンドオフ中に輸送中のパケットの再経
路指定があることもあり、無いこともある。輸送中のパケットとは、ソースによ
り作られたけれどもハンドオフの時までにレシーバーに未だ到達していないもの
である。再経路指定は、輸送中のパケットを端末に配達しようと試みる。

【００５９】 ハンドオフを実行するために、旧ＡＮＩ＿ＡＤは、セッションについてのタイ
ムスタンプの初期値（ＴＳ０）とＴＳ＿ｓｔｒｉｄｅとを新ＡＮＩ＿ＡＤに転送
しなければならない。これら二つの値は、新ＡＮＩ＿ＡＤがＲＴＰソース（例え
ば、端末１０２）から受信された新しいタイムスタンプ（新しいパケット・ヘッ
ダ中の）を圧縮し続けることを可能にする。Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒがハ
ンドオフ後にｔｅｒｍ＿ＡＤにより解凍されるべき正に第１のヘッダであり、そ
のＴＳ＿ｃｕｒｒｅｎｔがそのＲＴＰタイムスタンプであるとする。ｔｅｒｍ＿
ＡＤは、次の条件： [条件２]（ダウンリンク過渡積分ジッター＋２）＜２^k、 が満たされる限りはＴＳ＿ｃｕｒｒｅｎｔを解凍することができ、ここでダウン
リンク過渡積分ジッター（ＤＴＩＪ）はＴミリ秒単位で表示された、次に大きい
整数に丸められたＣｕｒｒｅｎｔ＿Ｈｅａｄｅｒのダウンリンク過渡ジッターで
ある。ダウンリンク過渡ジッターは、＝Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒの総遅延
−旧経路でのバルク遅延と定義される。もしＣｕｒｒｅｎｔ＿ｈｅａｄｅｒが再
経路指定された輸送中のパケットでなければ、Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒの
総遅延は新経路でのバルク遅延＋新経路でのＣｕｒｒｅｎｔ＿ｈｅａｄｅｒにつ
いての累積ジッターでもある。従って、ダウンリンク過渡ジッター＝新経路での
バルク遅延−旧経路でのバルク遅延＋Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒについての
累積ジッターである。

【００６０】 もしＣｕｒｒｅｎｔ＿ｈｅａｄｅｒが再経路指定された輸送中のパケットのヘ
ッダであるならば、Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒの総遅延＝経路指定及び再経
路指定によりもたらされる総遅延である。実際には、システムは、好ましくは、
ダウンリンク過渡ジッターを安定な状態（即ち、ハンドオフの無い）における累
積ジッターと同じ値の範囲内に維持するように設計されるべきである。従って、
これらの仮定（これらは、常に当てはまるとは限らない）に基づいて、もし条件
１（上に書き留められている）が満たされるならば、ダウンリンクについてハン
ドオフに関連する特別の問題は予期されない。

【００６１】 ２．アップリンク このアップリンク解説では、端末（例えば、端末１３０）のｔｅｒｍ＿ＡＤ１
３６は、タイムスタンプを圧縮し、それをＲＦリンク１４０を介してローカルの
または対応するＡＮＩ＿ＡＤに送る。この場合にはＲＴＰソースは端末１３０で
ある。ＲＴＰソース（端末１３０）が物理的位置を変更するときにも（ＡＮＩ＿
ＡＤでのハンドオフを必要とする）、レシーバー（解凍器）の役割は１つのＡＮ
Ｉ＿ＡＤから他へと移される。ＲＴＰソースは該端末（例えば端末１３０，図１
）に固定されたままである。

【００６２】 図７は、本発明の実施態様に従うハンドオフの動作例を図解する図である。エ
アー・インターフェース・オーバーヘッドを最小限にするために、旧ＡＮＩ＿Ａ
Ｄ７１０から新ＡＮＩ＿ＡＤ７１２へハンドオフのために情報が転送されなけれ
ばならない。その情報は旧ＡＮＩ＿ＡＤにおけるタイマー値である。旧ＡＮＩ＿
ＡＤ７１０は、旧ＡＮＩ＿ＡＤにおけるタイマーの現在の値（Ｔ＿ｕ）を読み（
或いはそのスナップ写真を撮り）、それをＴＳ０、ＴＳ＿ｓｔｒｉｄｅ及びｍ＿
ｃｕｒｒｅｎｔと共に新ＡＮＩ＿ＡＤに送る、ブロック７１４（図７）。新ＡＮ
Ｉ＿ＡＤはそのタイマーを（Ｔ＿ｕ）から再びインクリメントし始める。Ｔ＿ｔ
ｒａｎｓｆｅｒ７１５（図７）は該タイマーを転送するときであるとする。また
、旧及び新ＡＮＩ＿ＡＤにおけるタイマー・プロセスは多くてＴミリ秒の位相差
を有することがある。Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒはハンドオフ後に新ＡＮＩ
＿ＡＤにより解凍されるべき正に第１のヘッダであり、ＴＳ＿ｃｕｒｒｅｎｔは
そのＲＴＰタイムスタンプであるとする。新ＡＮＩ＿ＡＤは次の条件： [条件３]（アップリンク過渡積分ジッター＋２＋１）＜２^k、 が満たされる限りはＴＳ＿ｃｕｒｒｅｎｔを解凍することができ、ここでアップ
リンク過渡積分ジッター（ＵＴＩＪ）はＴミリ秒単位で表示された、次に大きい
整数に丸められたアップリンク過渡ジッターである。アップリンク過渡ジッター
は、＝Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒの総遅延−旧経路でのバルク遅延＋Ｔ＿ｔ
ｒａｎｓｆｅｒと定義される。Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒの総遅延＝新経路
でのバルク遅延＋Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒについての累積ジッターである
ので、アップリンク過渡ジッター＝新経路でのバルク遅延−旧経路でのバルク遅
延＋Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒについての累積ジッター＋Ｔ＿ｔｒａｎｓｆ
ｅｒである。ダウンリンクの場合と比べると、旧ＡＮＩ＿ＡＤタイマーと新ＡＮ
Ｉ＿ＡＤタイマーとの位相差を償うために１が加えられている。

【００６３】 具体的には、図７はアップリンク過渡ジッターも図解しており、それはバルク
遅延差とＴ＿ｔｒａｎｓｆｅｒとを含んでいる。この例では、旧ＡＮＩ＿ＡＤは
、タイマーがタイマーをインクリメントする前にハンドオフに備えることを決定
する。従ってそれはＴ＿ｕ＝０を新ＡＮＩ＿ＡＤ７１２に送る。Ｔ＿ｔｒａｎｓ
ｆｅｒは約Ｔミリ秒である。新ＡＮＩ＿ＡＤ７１２において、タイマー・プロセ
スの非同時性に起因して、タイマーがインクリメントされる前に殆どＴミリ秒が
経過する。新経路においてもヘッダ（ｎ＋ｍ）について累積ジッターがある。そ
の結果として、ヘッダ（ｎ＋ｍ）が受信されるときに読まれるタイマー値は２で
あるが、真の値は４であるべきである。従って、−２のスキューがある。条件３
が満たされる限りは、該スキューを除去し、ＲＴＰタイムスタンプを正しく解凍
することができる。

【００６４】 一つの実施態様では、旧及び新ＡＮＩ＿ＡＤを接続する高速シグナリング・ネ
ットワークでＴ＿ｕが伝送される。従って、時間Ｔ＿ｔｒａｎｓｆｅｒは多くて
も僅か数Ｔミリ秒であるべきである。しかし、Ｔ＿ｕの転送が成功しないか、或
いは充分に時宜を得ていない場合を考慮しなければならない。その様な場合には
、新ＡＮＩ＿ＡＤはｔｅｒｍ＿ＡＤに通知し、それは肯定応答が受信されるまで
完全な（圧縮されていない）ＲＴＰタイムスタンプを送る。

【００６５】 Ｅ．ジッター減少 本発明の一つの実施態様では、圧縮されているタイムスタンプとローカル・レ
シーバー・タイマーとを使用するタイマーに基づく圧縮方式は下記の条件が満た
されることに基づくことができる： [条件１]（最大積分ジッター＋２）＜２^k [条件２]（ダウンリンク過渡積分ジッター＋２）＜２^k、 [条件３]（アップリンク過渡積分ジッター＋２＋１）＜２^k。

【００６６】 会話実時間要件のために、上記のいろいろなジッターが正常動作時には数Ｔミ
リ秒の程度であると合理的に予期することができる。従って、スキューまたはエ
ラーを訂正し得るためにはｋの値は普通は小さな値、例えば４、で十二分である
。しかし、ジッターが過度になる、ＲＴＰソースからレシーバーまでの経路での
異常な状態（故障など）またはその他の状態が存在することがある（その場合、
圧縮されているタイムスタンプ及びローカル・レシーバー・タイマーに基づいて
正しいタイムスタンプを作ることができない）。これらの場合に対処するために
、過度のジッターを有する（例えば、上記の条件１、２または３のいずれかが満
たされない）パケットを濾過して取り除く（或いは捨てる）ために、ジッター減
少機能（ＪＲＦ）１１５（図１）を圧縮器のフロントエンドとして設けることが
できる。

【００６７】 過度のＭＩＪを有するパケットを排除し或いは特定するために、ジッター減少
機能（ＪＲＦ）は、ネットワーク１０８を介して受信された各パケットのジッタ
ーを計算する。もし測定されたパケット・ジッターが２^k−２より大きければ、
それは過度のジッターであると見なされ、そのパケットは捨てられる。さもなけ
れば、ヘッダ（またはヘッダ・フィールド）が圧縮され（前述したように）、次
にレシーバー端末（例えば、端末１３０）に送られる。

【００６８】 ＪＲＦは現在のパケットのジッターを次のように計算する：ジッター＝（ＴＳ
２−ＴＳ１−ＪＲＦｔｉｍｅｒ＿ｄｉｆｆ）の絶対値、ここでＴＳ２は現在のパ
ケットのタイムスタンプであり、ＴＳ１は前のパケットのタイムスタンプであり
、ＪＲＦｔｉｍｅｒ＿ｄｉｆｆは現在のパケットと前のパケットとの間のＪＲＦ
＿ｔｉｍｅｒの差である（経過した時間）。このジッター値は２^k−２と比較さ
れる。もし該ジッターが２^k−２より大きければ、そのパケットは捨てられる。
そうでなければ、該パケット・ヘッダはＡＮＩ＿ＡＤで圧縮され、その圧縮され
ているヘッダを伴うパケットがＲＴＰレシーバーに送られる。

【００６９】 このジッター減少機能（ＪＲＦ）１１５は、レシーバー端末により受信された
パケットのジッターを制限する有効な技術である（ＲＦリンクを介して導入され
るジッターは無視できると考えて良いから）。更に、ＪＲＦはＲＦリンク１４０
で利用できる帯域幅を効率よく使用するように動作する。ＪＲＦ１１５が無けれ
ば、２^k−２より大きなジッターを有する１つ以上のパケットがリンク１４０を
介してＲＴＰレシーバーに送られるかも知れない。しかし、レシーバーにおいて
、もしジッターが過度であれば（即ち、条件１が満たされなければ）、正しいタ
イムスタンプ値を作ることができなくて、レシーバーに該パケットを捨てさせる
。従って、ＪＲＦは、レシーバーにおいていずれにせよ捨てられることになる過
度のジッターを有するパケットを単に取り除くように動作するだけである（リン
ク１４０での貴重な帯域幅の浪費を避ける）。

【００７０】 ＩＩ．ヘッダはぎ取り方式 本発明の第２の実施態様はタイマーに基づくヘッダはぎ取り方式を提供し、そ
の方式では低帯域幅リンクで（例えばＲＦリンク１４０で、図１）伝送される前
にヘッダまたは１つ以上のヘッダ・フィールド（例えば、ＲＴＰタイムスタンプ
を含む）がＲＴＰパケットからはぎ取られる。その様な場合、そのタイムスタン
プはＲＴＰパケットで明示的には提供されない。むしろ、ヘッダはぎ取り器（例
えば、これはＡＮＩ＿ＡＤに存在することができる）とヘッダ再生器（例えば、
これは端末１３０に存在することができる）との間の本質的に一定ビットレート
のチャネルまたは回路のような接続に基づいてローカル・タイマーをインクリメ
ントするためにタイミング情報が暗示的にヘッダ再生器に提供されることができ
る。

【００７１】 Ａ．ヘッダはぎ取り器概観 ヘッダはぎ取りは、或るアプリケーションまたはサービスのためには、ＩＰ／
ＵＤＰ／ＲＴＰヘッダに含まれている情報の全てを送る必要が無いというアイデ
アに基づいており、その必要がない理由は、それらが変化しないこと、またはそ
れらが該アプリケーション／サービスにとってあまり重要ではないことである。
基本的な音声は典型的な例である。現存するセルラー音声サービス（例えば、Ｒ
Ｆリンク１４０、図１を介する）と同等のサービスを提供するために、非常に重
要な唯一の可変情報はＲＴＰタイムスタンプ（ＴＳ）である。ＲＴＰシーケンス
番号（ＳＮ）について透明性を維持することも望ましい。ここで（ＳＮについて
）透明性とは、はぎ取り／再生後のＳＮが元のＳＮに等しいことを意味する。ヘ
ッダはぎ取りは、ローカル・タイマーまたはカウンターのみに基づいてＲＴＰタ
イムスタンプが再生され得るように回路のような接続または本質的に一定ビット
レートのチャネル（そこではパケット・ジッターは導入されない）により提供さ
れる暗示的タイミング情報に依拠する。これはタイムスタンプを明示的に送る必
要を（或いは圧縮されているタイムスタンプを送る必要も）無くする。ＳＮの透
明性を達成するために、その回路のようなチャネルまたは接続からのタイミング
情報と組み合わせて圧縮されているＳＮを使用することができる。回路のような
接続は、本質的に一定のビットレートを有するチャネルを提供する。音声サンプ
ルが無いとき（例えば沈黙間隔）、該チャネルは他のトラフィック及び／又はユ
ーザーに割り当てられることができたり割り当てられることができなかったりす
る。このヘッダはぎ取り方式の利点は下記を含む： ａ）他の如何なる方式も比肩し得ない最低のヘッダ・オーバーヘッド（図１
−６において前述された圧縮ヘッダ技術よりも少ない）。 ｂ）エラーに対する強さ。回路のような伝送または本質的に一定のビットレ
ートのチャネルからのタイミング情報は本質的にエラーによる影響を受けないか
ら ｃ）もしそれが望まれるならば、コール中にヘッダ圧縮（例えば、図１−６
の技術）に転換する可能性。これはもしコールがマルチメディアになるならば非
音声媒体が音声に加えられるので有益である。更に、ヘッダはぎ取りは、もし実
行されたならばより低い層で行われる可能性のある統計的多重化を権限委託また
は排除しないことに注意しなければならない。

【００７２】 図８は本発明の実施例に従うスタック例を図解するブロック図である。ヘッダ
はぎ取りスタック８０２とヘッダ再生スタック８３０とが示されている。例とし
て、ヘッダはぎ取りスタック８０２はパケットから１つ以上のヘッダ・フィール
ドをはぎ取るために使用され得るコンポーネントのうちの幾つかを図解し、ヘッ
ダ再生スタック８３０はパケット・ヘッダを再生するために使用され得るコンポ
ーネントのうちの幾つかを図解している。ヘッダはぎ取りスタック８０２は例え
ば１つのタイプのＡＮＩアダプター（例えば、ＡＮＩ＿ＡＤ１１２、図１）の中
に設けられることができ、ヘッダ再生スタック８３０は、例えば、１つのタイプ
の端末アダプター（例えば、ｔｅｒｍ＿ＡＤ１３６、図１）に常駐することがで
きる。

【００７３】 図８を参照すると、ヘッダはぎ取りスタック８０２はＲＴＰ及びＵＤＰ層８０
４、ＩＰ層８０６を含む。ＲＴＰ／ＵＤＰ／ＩＰ層はＲＴＰパケット８０８を作
る（これはＲＴＰヘッダ内のタイムスタンプを含む）。次に、ヘッダはぎ取りス
タック８０２において、１つ以上のヘッダまたはヘッダ・フィールドをはぎ取り
或いは除去するためにＲＴＰパケット８０８はヘッダはぎ取り器（ＨＳ）８１０
に提供される。層Ｌ１及びＬ２ ８１２が設けられており、ここで、例えば、Ｌ
２はデータ・リンク層であって良く、層Ｌ１は物理層であって良い。必要に応じ
て他の層を設けることができる。同様に、ヘッダ再生スタック８３０は対応する
層Ｌ１及びＬ２ ８２０、完全なＲＴＰパケット８２４（ＲＴＰ／ＵＤＰ／ＩＰ
ヘッダを含む）を提供するためにヘッダ（ＲＴＰタイムスタンプを含む）を再生
するヘッダ再生器（ＨＲ）８２２を含む。パケット８２４はＩＰ層８２６に、次
にＵＤＰ及びＲＴＰ層８２８に提供される。ヘッダはぎ取りスタック８０２及び
ヘッダ再生スタック８３０の層Ｌ１及びＬ２は、リンク８１５またはエアー・イ
ンターフェース（ＲＦリンク１４０など）を介して或いはネットワークを介して
通信する。例えば、ＩＰ経由音声パケットはリンク８１５（例えば、無線リンク
またはネットワーク）経由での伝送の前にヘッダはぎ取り器８１０を通過させら
れる。受信端において（ヘッダ再生スタック８３０において）、ヘッダ再生器８
２２は、受信者への配達の前にヘッダを再生する。層Ｌ２／Ｌ１は、ヘッダはぎ
取り器８１０とヘッダ再生器８２２との間に回路のような接続を提供することが
でき、即ち本質的に一定ビットレートのチャネルを提供する。更に、最大効率の
ために、層Ｌ１は、最適化されたチャネル符号化及びインターリービングに加え
て、不均一ビット保護のような音声ペイロード最適化も実行することができる。
ヘッダはぎ取りという概念はペイロード最適化が行われるか否かに関わらず適用
されることに注意せよ。

【００７４】 動作時には、ヘッダはぎ取り器（ＨＳ）８１０は、入ってきたＲＴＰパケット
のジッターを除去し、それらをヘッダ内のＲＴＰタイムスタンプ（ＴＳ）に従っ
て再生する。ここで、ジッターを除去するということは、回路のような接続また
は本質的に一定ビットレートのチャネルでの音声サンプルの伝送をタイムスタン
プに従って予定することを意味する。換言すると、パケットは、ヘッダの除去ま
たははぎ取りの後、パケット内のそれらのタイムスタンプを基礎とする時に回路
のようなチャネルまたは本質的に一定ビットレートのチャネルで伝送される。過
度のジッターを伴うパケットは例えばジッター減少機能（ＪＲＦ１１５、図１）
を用いて捨てられる。ヘッダ再生器（ＨＲ）８２２はＩＰ／ＵＤＰ／ＲＴＰフィ
ールドを復元し、それらは次の範疇に分類され得る： ａ）静止：セッションの間中、値は変化しない、例えばＩＰアドレス ｂ）非静止：値がパケットから次のパケットへと変化する可能性があるが、
実際には、音声については、ヘッダはぎ取り中に保存されるべき非常に重要な唯
一の非静止フィールドはＲＴＰタイムスタンプ（ＴＳ）である。ＲＴＰシーケン
ス番号（ＳＮ）も保存される。静止フィールドは、セッションの開始時に、初期
化段階において完全なヘッダの一部分として一回だけ転送されることができる。
信頼できる配達メカニズムを使用することができる（例えば初期化情報の受け取
りを知らせるためにＲＴＰレシーバーからの肯定応答即ちＡｃｋｓを使用する）
。タイムスタンプとシーケンス番号について簡単に論じる。

【００７５】 １．ＲＴＰタイムスタンプ（ＴＳ） 音声の場合には、ＲＴＰタイムスタンプ（ＴＳ）はＲＴＰソースの柱時計（即
ちソース・タイマー）の関数として線形に増大する。もし連続する音声サンプル
間の時間間隔がＴミリ秒であれば、ヘッダｎのＲＴＰタイムスタンプ（時点ｎ＊
Ｔミリ秒において作られる）＝ヘッダ０（時点０において作られる）のＲＴＰタ
イムスタンプ＋ＴＳ＿ｓｔｒｉｄｅ＊ｎであり、ここでＴＳ＿ｓｔｒｉｄｅ及び
Ｔは音声コーデックに依存する定数である。１スピーチ（音声）サンプルあたり
に１つのパケットがあるならば、これが当てはまる。より一般的には、ＲＴＰタ
イムスタンプ（ＴＳ）はＴＳ０＋ｍ＊ＴＳ＿ｓｔｒｉｄｅの形であり、ここでＴ
Ｓ０は＜ＴＳ＿ｓｔｒｉｄｅであり、ｍは整数である。ジッターが除去された後
にヘッダはぎ取り器（ＨＳ）において同じ挙動が見られる。

【００７６】 セッションまたは接続の始まりに、ＲＴＰレシーバーを初期化する（即ち、ヘ
ッダ再生器を初期化する）初期化段階が実行される。この初期化段階において、
ヘッダはぎ取り器は、レシーバーからＡｃｋが受信されるまで初期化情報（Ｉｎ
ｉｔ＿ｉｎｆｏ）を送り続ける。Ｉｎｉｔ＿ｉｎｆｏ（ｎ）は本質的に完全なＩ
Ｐ／ＵＤＰ／ＲＴＰヘッダｎ（初期タイムスタンプとシーケンス番号とを含む）
から成る。ＲＴＰシーケンス番号は、この特定の初期化ヘッダを特定するために
使用されるが、それは、後の初期化ヘッダがより大きなシーケンス番号を含むか
らである（該第１初期化ヘッダが肯定応答されないと仮定して）。

【００７７】 ヘッダ再生器（ＨＲ）８２２において、Ｉｎｉｔ＿ｉｎｆｏ（ｎ）が正しく受
信されたとき、ＨＲ８２２はａｃｋ（ｎ）を送る。ヘッダ再生器（ＨＲ）８２２
が完全なヘッダに肯定応答すると、ＨＳは完全なヘッダを送るのをやめる。ＨＲ
８２２は、また、Ｉｎｉｔ＿ｉｎｆｏ（ｎ）で受信されるＲＴＰタイムスタンプ
に初期化されているローカル・タイムスタンプ・カウンターを始動させる。該Ｔ
Ｓカウンターは図１のレシーバー・タイマーに似ているけれども、該ＴＳカウン
ターはＴミリ秒毎にＴＳ＿ｓｔｒｉｄｅだけ（１ではなくて。しかし、それはレ
シーバー・タイマーと同じ原理である）インクリメントされる。後のはぎ取られ
ている音声フレーム（即ち、ヘッダがはぎ取られまたは除去されているＲＴＰパ
ケット）について、ＲＴＰ ＴＳがタイムスタンプ（ＴＳ）カウンターから再生
される。レシーバー・タイマー（ＴＳタイマー）は、タイムスタンプを作るため
にＲＴＰソースで使用される時計またはタイマー（即ち、ソース・タイマー）と
同じ周波数を有する。更に、回路のような接続は本質的に一定のビットレートを
提供し、従ってパケット遅延は可変ではなくてパケット毎に変化しない。その結
果として、本質的に一定ビットレートのチャネルに起因するパケット・ジッター
は無い。従って、初期タイムスタンプ値（ＴＳ０）を含む初期化情報をＲＴＰレ
シーバーが受け取った後、ＲＴＰレシーバーはタイムスタンプ・カウンター（或
いはレシーバー・タイマー）だけに基づいて後の各パケット（初期化後）につい
ての正しいタイムスタンプを再生することができる。

【００７８】 ヘッダはぎ取り器８１０とヘッダ再生器８２２との間に設けられている本質的
に一定ビットレートのチャネルはヘッダはぎ取り器８１０とヘッダ再生器８２２
の間で所定期間にわたって所定数のビットを提供するだけでよいが、この機能は
異なるいろいろな方法で実行されることができる。例えば、該チャネルは、はぎ
取り器８１０及び再生器８２２に専用され或いは数人のユーザーに共有される一
定ビットレートのチャネルであることができる。該チャネルは、例えば１ミリ秒
毎に１ビットを提供することができ、或いは１００ミリ秒毎に１００ビットを提
供することができるけれどもその場合にはデータ転送速度は１００ｍｓの期間内
で一定でなくても良い（即ち、変化しても良い）。追加の例として、該チャネル
は、ヘッダはぎ取り器とヘッダ再生器との間で１つ以上のデータ・バーストを通
じて所定数のビットを提供することができる。例えば、該チャネルは１０ミリ秒
毎に１０００ビットの塊またはバーストを提供することができる。従って、本質
的に一定ビットレートのチャネルは所定期間にわたって所定数のビットを提供す
るだけでよく、これをいろいろな技術を用いて達成することができる。

【００７９】 ２．ＲＴＰシーケンス番号（ＳＮ） （ＨＳ８１０が見る）ＲＴＰ ＳＮは普通は１つのパケットから次のパケット
へ１だけ大きくなる。例外はパケットが失われまたは順番が狂ったときだけであ
る。アップリンクでは、パケット喪失または順番の狂いは生じないと思われるが
、それは、ヘッダはぎ取り器（ＨＳ）８１０とＲＴＰソースとが互いに非常に近
いからである。従って、次に述べる事柄はダウンリンクに当てはまる。ＨＳ８１
０は、パケットを、そのヘッダをはぎ取る前に、整理し直そうと試みるために限
られた緩衝を行う。ＲＴＰ ＳＮ ｎを伴うパケットは、もしそれがＲＴＰ Ｓ
Ｎ （ｎ＋１）を伴うパケットのヘッダがはぎ取られるときまでに未だ受信され
ていなければ、失われたと見なされる。ＲＴＰ ＳＮ ｍを伴うパケットは、も
しそれが受信されるときまでにＲＴＰ ＳＮ ｋを伴うパケットのヘッダがはぎ
取られていて、且つｋ＞ｍであれば、順番が狂っている。整理し直しバッファー
の長さは設計パラメータである。バッファーが長すぎれば遅延が過度に大きくな
り、バッファーが短すぎれば過度に多くのパケットが捨てられる結果となる。該
パラメータはＨＳ８１０の上流側でＩＰネットワーク１０８により提供される品
質にもよる。ＨＲ８２２は、ＳＮの最良の見積もりであるＳＮカウンターを維持
する。Ｉｎｉｔ＿ｉｎｆｏを観察することにより、ＨＲ８２２は、初期ＳＮと、
パケット・サイズ（ｐ＿ｓｉｚｅ）としても知られているパケットに含まれてい
るビットの数とを得ることができる。ＨＲ８２２はＳＮカウンターをＩｎｉｔ＿
ｉｎｆｏ中のＳＮで初期化する。ＨＲ８２２は、本質的に一定ビットレートのチ
ャネルを介して受信される音声ビットを“数え”、音声のｐ＿ｓｉｚｅビット毎
にＳＮカウンターを１インクリメントする（それは、例えば沈黙間隔の間など、
パケットが受信されないときにはインクリメントされない）。一つの実施態様で
は、ＨＲ８２２は実際には受信されたビットを数えない。むしろ、ＨＲ８２２の
ＳＮカウンターはパケット持続時間毎に１だけインクリメントされ、ここでパケ
ット持続時間はビット（ｐ＿ｂｉｔｓ）のパケットを受信するのに必要な時間で
ある。従って、パケット持続時間はパケット・サイズ（ｐ＿ｓｉｚｅ）とビット
レート（これは回路のような接続において一定である との関数である。

【００８０】 従って、（初期ＳＮ及びＴＳをＨＲ８２２に供給する）初期化が行われた後、
ＨＲ８２２は、Ｔミリ秒毎にＴＳカウンターをＴＳ＿ｓｔｒｉｄｅだけインクリ
メントすると共にパケット持続時間毎にＳＮカウンターを１だけインクリメント
することによって連続するパケットのためにタイムスタンプを作ることができる
ことが分かる。従って、初期化後、これらのフィールドはローカル・クロックの
みと関連してＨＲ８２２で再生されることができる（ＴＳ＿ｓｔｒｉｄｅ及びパ
ケット持続時間がＨＲ８２２に知られていると仮定して）。受信されたビットを
実際に数えるのではなくて時間（パケット持続時間）に基づいてＳＮカウンター
をインクリメントすることは、エラーに対して強い。１つ以上のビットがＨＲ８
２２に到着する前に落とされた場合には、ＳＮカウンターは真の値を反映し、失
われたビットには影響されない。

【００８１】 Ｂ．不連続性及びストリング 上述の説明は、ＴＳ及びＳＮがリンク（例えば、ＲＦリンク１４０）を介して
の伝送の前にＨＳ８１０により完全にはぎ取られ、その後ローカル・クロックま
たはタイマー（例えば、Ｔミリ秒毎にＴＳカウンターをＴＳ＿ｓｔｒｉｄｅだけ
インクリメントしパケット持続時間毎にＳＮカウンターを１だけインクリメント
する）を維持するＨＲ８２２によって再生され得ることを示している。しかし、
もし対処しなければ前述したタイマーに基づく再生アプローチを無効にしかねな
い１つ以上の不連続事象が発生することがある。該不連続事象のうちの幾つかは
下記を含むことがある： ａ）事象“新スパート”：パケットｎと（ｎ＋１）との間のＴＳ差の過渡変
化（新しい話のスパートの始まり）；これはタイムスタンプ（ＴＳ）における非
線形の変化またはシフトとしても記述されることができる。 ｂ）事象“サイズ変化”：パケットに詰め込まれている音声フレームの数及
び／又は音声フレームのサイズの変化に起因する、ＲＴＰパケット・サイズ（ｐ
＿ｓｉｚｅ）の変化 ｃ）事象“ストライド変化”：ＴＳ＿ｓｔｒｉｄｅの変化（例えばペイロー
ドのタイプＰＴの変化に起因する）。

【００８２】 私達は、全てのパケットが同じサイズ（ｐ＿ｓｉｚｅ）を有し、シーケンス番
号が連続しており、即ちｎ、ｎ＋１、（ｎ＋２）など、且つ連続するパケットの
タイムスタンプ（ＴＳ）が同じ増分ＴＳ＿ｓｔｒｉｄｅだけの間隔を置いている
ようなパケット・ヘッダのシーケンスとしてヘッダ・ストリングを定義する。換
言すると、ヘッダ・ストリングは、或るパケット・フィールド（例えばパケット
・サイズ）を共通に持っていると共にＳＮ及びＴＳなどの、連続するパケットに
おいて線形に増大する他のフィールドを持っているヘッダのストリングであると
見なされて良い。ストリングは普通は話のスパート（例えば、沈黙の合間と合間
の間にある１系列の音声サンプル）である。

【００８３】 １つのストリングから他のストリングへの移行は、別々の或いは組み合わされ
たいずれかの不連続事象により引き起こされることができる。この方式では、一
つのストリングが始まる（且つ前のストリングが終わっている）とき、ＨＳ８１
０は、どの不連続事象が生じたのか判定し、それに応じて必要とされるストリン
グ初期化（ｓｔｒｉｎｇ＿ｉｎｉｔ）情報をＨＲ８２２に送る。

【００８４】 図９は、本発明の実施例によってメッセージ中に設けられることのできる情報
を図解する表である。Ｉｎｉｔ＿ｉｎｆｏは通常は完全なヘッダ（完全なＳＮ及
びＴＳを含む）を含んでいて、セッションの始まりにＨＳ８１０からＨＲ８２２
へ（ＨＲ８２２を初期化するために）送られる。ＨＳ８１０は、ヘッダの無いデ
ータ・パケットを送り始める前に、ＨＲ８２２からａｃｋを受け取るまでｉｎｉ
ｔ＿ｉｎｆｏを送り直し続ける。その後、１つ以上のストリングが生じるかも知
れず、それはストリング毎に変化するフィールドまたは値の追加の更新を必要と
するかも知れない。それらの変更された値は、ｓｔｒｉｎｇ＿ｉｎｉｔを用いて
ＨＲ８２２に供給される。

【００８５】 ｓｔｒｉｎｇ＿ｉｎｉｔは、ｐ＿ｓｉｚｅ値（もしそれが前のストリングから
変化しているならば）とＴＳ＿ｓｔｒｉｄｅ値（もしそれが前のストリングから
変化しているならば）とを含んでいる。ＴＳの非線形シフトが一つのストリング
から次のストリングへと生じなければ、ＨＲ８２２は、旧ストリングに使用され
たＴＳカウンターに基づいてＴＳを再生し続けることができる。しかし、ストリ
ング間でタイムスタンプ（ＴＳ）に非線形シフトが生じたならば（即ち、タイミ
ングの喪失）、更新されたタイムスタンプはＨＳ８１０からＨＲ８２２へｓｔｒ
ｉｎｇ＿ｉｎｉｔで明示的に送られなければならない。前述したように、条件１
が満たされる限り、更新されたＴＳは前述の圧縮されたタイムスタンプ４１４（
図４を参照）として送られることができる。そうではなくて、もし条件１が満た
されなければ、完全な更新されたタイムスタンプがＨＲ８２２へ送られなければ
ならない。

【００８６】 ａｃｋモードにおいて、ＨＳ８１０がｓｔｒｉｎｇ＿ｉｎｉｔをＨＲ８２２へ
送った後、ＨＳ８１０が更なるデータ・パケット（ヘッダの無いパケット）をＨ
Ｒ８２２へ送ることができる前にＨＳ８１０は、更新されたストリング情報（ｓ
ｔｒｉｎｇ＿ｉｎｉｔ）を受け取ったことを知らせる（ａｃｋする）ようにＨＲ
８２２に要求することができる。肯定応答或いはａｃｋのモードでは、ＨＳ８１
０がｓｔｒｉｎｇ＿ｉｎｉｔメッセージについてＨＲ８２２からａｃｋを受け取
るまでＨＳ８１０はｓｔｒｉｎｇ＿ｉｎｉｔメッセージをＨＲ８２２へ繰り返し
送る。ＨＲ８２２からａｃｋを受け取った後、ＨＳ８１０は（新しいストリング
のパケットについてのＴＳ及びＳＮは今やローカル・クロックまたはタイマーだ
けを用いて再生されることができるので）該ストリングの残りのパケットをヘッ
ダがはぎ取られているパケットとして送る。ｓｔｒｉｎｇ＿ｉｎｉｔメッセージ
についてのａｃｋ要求（肯定応答モードで）は、ＨＳ８１０がＨＲ８２２に知ら
せずに新しいストリングを送るのを阻止する。例えば、ＨＳ８１０とＨＲ８２２
との間のリンクが一時的に遮断されている間にＨＳ８１０が（例えば、不連続事
象に関連する更新されたフィールドまたは情報を提供する）新しいｓｔｒｉｎｇ
＿ｉｎｉｔメッセージを送ったならば、ＨＳ８１０はＨＲ８２２からａｃｋを初
めて受け取るまではヘッダがはぎ取られているパケットを送り始めることはでき
ない。

【００８７】 ＨＳ８２２がｓｔｒｉｎｇ＿ｉｎｉｔ情報を受け取ったとＨＳ８１０が確信す
ると、該ストリームの残余についてはヘッダ無しで音声フレーム（例えば、デー
タ・パケット）が送られる。これらのヘッダの無いフレームについては、ＴＳ及
びＳＮはＨＲ８２２でローカル・クロックを用いることにより再生される。

【００８８】 ＨＳ８１０は次のように事象を判定することができる： ａ）事象“新スパート”：ＳＮ＝ｎを有するパケットとＳＮ＝（ｎ＋１）を
有するパケットとのＴＳ差がＴＳ＿ｓｔｒｉｄｅとは異なる。これは新しいスト
リングまたは話のスパートの始まりを意味する。この場合、ＳＮ同期化を確保す
るために、ｓｔｒｉｎｇ＿ｉｎｉｔはＳＮまたは圧縮されたＳＮ（Ｃ＿ＳＮ）か
ら成る。もし送られたＳＮ情報が無ければ、ＨＲ８２２は、パケット持続時間毎
にＳＮカウンターを１だけインクリメントしても正確なＳＮを与えることになる
のかどうか確信できない。その理由は、その間にＨＳ８１０とＨＲとの間で音声
ビットが失われるリンク切断があったかも知れないことにある。 ｂ）事象“サイズ変化”：ＳＮ＝ｎを有するＲＴＰパケットのサイズが前に
受信されたパケットと違っている；これはパケット持続時間（ＳＮカウンターが
インクリメントされる速度）の値に影響を及ぼす。ｓｔｒｉｎｇ＿ｉｎｉｔは新
しいｐ＿ｓｉｚｅ値を含んでいる。 ｃ）事象“ストライド変化”：ＲＴＰパケットのペイロード・タイプ（ＰＴ
）フィールドを分析することから判定される；ｓｔｒｉｎｇ＿ｉｎｉｔは新しい
ＴＳ＿ｓｔｒｉｄｅ値を含む。

【００８９】 これらの不連続事象は例として提供されるに過ぎない。他のタイプの不連続事
象もあり得る。

【００９０】 複数の事象が結合して生じることがある（複合事象）。その場合、ｓｔｒｉｎ
ｇ＿ｉｎｉｔは対応する基本事象からの全ての情報を含む。例えば、もし“新ス
パート”が“サイズ変化”と結合して生じたならば、ｓｔｒｉｎｇ＿ｉｎｉｔ＝
｛Ｃ＿ＳＮ、新しいｐ＿ｓｉｚｅ値｝である。

【００９１】 Ｃ．Ｉｎｉｔ＿ｉｎｆｏ、Ｓｔｒｉｎｇ＿ｉｎｉｔを送る手続 ｉｎｉｔ＿ｉｎｆｏは普通はａｃｋモードで送られ、その場合ＨＳ８１０はＨ
Ｒ８２２によりａｃｋ（肯定応答）されるまでＩｎｉｔ＿ｉｎｆｏを送る。ｓｔ
ｒｉｎｇ＿ｉｎｉｔはａｃｋまたはｕｎａｃｋモードで送られることができる。
ａｃｋモードでは、ＨＳ８１０は、ＨＲ８２２により肯定応答されるまで全ての
パケットでＳｔｒｉｎｇ＿ｉｎｉｔを送る。ａｃｋが受信されると、ＨＳ８１０
は、該ストリームの残余について如何なるヘッダも無しで音声ビットだけを送る
。ｕｎａｃｋモードでは、ＨＳ８１０は、該ストリングの残余についてだけ音声
ビットを送る前にＳｔｒｉｎｇ＿ｉｎｉｔを一定（所定）回数だけ送る。随意に
、ＨＲ８２２が同期化される（例えば適切な値を有する）ことを保証するために
該ストリング中に或る間隔を置いてｓｔｒｉｎｇ＿ｉｎｉｔが反復されることが
できる。

【００９２】 “サイズ変化”または“ストライド変化”基本事象を含む複合事象は、通常は
、Ｓｔｒｉｎｇ＿ｉｎｉｔがａｃｋモードで送られることを必要とする。その場
合、ｓｔｒｉｎｇ＿ｉｎｉｔは生成番号を伝える。生成番号は、ｐ＿ｓｉｚｅま
たはＴＳ＿ｓｔｒｉｄｅが変化する毎にインクリメントされるカウンターである
。それは、どの変化がＨＲ８２２により肯定応答されたのか追跡するためにｐ＿
ｓｉｚｅまたはＴＳ＿ｓｔｒｉｄｅが急速に連続して変化する場合に使用される
。例えば、もしｐ＿ｓｉｚｅが値ｐ＿ｓｉｚｅ＿０からｐ＿ｓｉｚｅ＿１へ変化
し、次に再び値ｐ＿ｓｉｚｅ＿２へと変化するならば、ＨＳ８１０は生成番号例
えば３と共に、ｐ＿ｓｉｚｅ＿１を含むｓｔｒｉｎｇ＿ｉｎｉｔを送り、その後
に生成番号４と共に、ｐ＿ｓｉｚｅ＿２を含むもう一つのｓｔｒｉｎｇ＿ｉｎｉ
ｔを送る。第２のｓｔｒｉｎｇ＿ｉｎｉｔの後のａｃｋの受信は、もしそれが肯
定応答されたｓｔｒｉｎｇ＿ｉｎｉｔの生成番号を伝えなかったならば、不明瞭
である。もし複合事象が“新スパート”だけであれば、Ｓｔｒｉｎｇ＿ｉｎｉｔ
（Ｃ＿ＳＮ）がａｃｋまたはｕｎａｃｋモードで送られることができる。ｕｎａ
ｃｋモードは、少なくとも全ての話のスパートの始まりにＣ＿ＳＮが反復される
というアイデアに基づいている。従って、ＨＲ８２２がそのＳＮを決して再同期
化しない確率は漸近的に小さい。更に、もしＳＮの同期が失われたとすると、そ
れはＨＳ８１０とＨＲ８２２との間でのパケットの喪失にのみ起因する。従って
ＳＮの同期喪失の効果は、再生されたＳＮ＜正しいＳＮということである。これ
は、次のＣ＿ＳＮが受信されたならば直ちにその差だけＳＮを大きくすることに
よって訂正される一時的な不一致にすぎない。２以上のＳＮの増大は、受信をす
るＲＴＰエンドポイントによりパケットの喪失と解釈され、普通は受信されたパ
ケット自体の再生に影響を及ぼすべきではない。ｕｎａｃｋモードは、安定な状
態で、即ちコール・セットアップ後のハンドオーバーとハンドオーバーとの間に
ａｃｋを伝えるチャネルを省くことを可能にする。

【００９３】 Ｄ．ハンドオーバー ヘッダはぎ取り／再生がセルラーシステムにまたはステーション端末が１つの
ネットワーク・アダプター（ＡＮＩ＿ＡＤ）から他のへと移動することがあり得
る他のシステムに適用されるときには、ハンドオーバーまたはハンドオフが考慮
されるべきである。

【００９４】 ハンドオーバーは、３段階：即ちハンドオーバー準備、ハンドオーバー実行及
びハンドオーバー完了、を通過することとしてモデル化されることができる。ハ
ンドオーバー準備を開始することを決定するハンドオーバー（ＨＯ）マネージャ
ーと呼ばれる機能（これはＡＮＩ１１０に設けられることができる）がある。伝
統的に、ハンドオーバー準備は、ターゲット・システムの資源を取っておくと共
にターゲット・セルに関する必要な情報を得るためにターゲット・システムとシ
グナリング・メッセージを交換することから成る。ハンドオーバー実行は、ター
ゲット・セルに関する情報と共にＨＯコマンドをレシーバー端末（または移動局
）に送るソースＨＯマネージャーにより開始される。ＨＯコマンドに答えて、該
端末（または移動局）はハンドオーバーを実行する。ハンドオーバー完了は、端
末または移動局とターゲット・システムとの間でのシグナリングと、ソースへの
通知と、（ソースの）最早不要となった資源の解放とを必要とする。

【００９５】 １．アップリンク ＡＮＩ＿ＡＤはアップリンク・データ伝送（図１，アップリンク１４２を参照
）についてＨＲ８２２として作用する。ターゲットＡＮＩ＿ＡＤは完全なヘッダ
を再生するのに必要な情報を提供されなければならない。主な制約条件は、ハン
ドオーバー（ＨＯ）を通じてのＲＴＰ ＴＳとＲＴＰ ＳＮの連続性を含む。

【００９６】 図１０は、本発明の実施例によるハンドオーバー・プロセスを図解する図であ
る。端末１３０（或いは移動局ＭＳ）は、例として、パケットのサイズが変化し
たことをｓｔｒｉｎｇ＿ｉｎｉｔメッセージを用いてソースＡＮＩ＿ＡＤ１１２
に知らせることができる、ステップ９０２。ソースＡＮＩ＿ＡＤ１１２は、ｐ＿
ｓｉｚｅのこの更新を肯定応答する、ステップ９０４。その後、端末１３０はタ
ーゲットＡＮＩ＿ＡＤ１１４により覆われる新しい地域へ移動し、ＨＯマネージ
ャー９０１はソースＡＮＩ＿ＡＤにハンドオーバ（ハンドオフ）のための準備に
ついて通知する、ステップ９０６。ソースＡＮＩ＿ＡＤは次にＨＯ＿初期化（Ｈ
Ｏ＿ｉｎｉｔ＿ｕ）情報をターゲットＡＮＩ＿ＡＤ１１４に送る、ステップ９０
８。ＨＯ＿ｉｎｉｔ＿ｕは、完全なＩＰ／ＵＤＰ／ＲＴＰヘッダの見積もられた
概観である。その見積もられた概観は、ＲＴＰ ＴＳがＴＳ０＿ｕと置き換えら
れている最後に再生されたヘッダ、ｍ＿ｌａｓｔ＿ｕ、ＴＳ＿ｓｔｒｉｄｅ＿ｕ
、及びＴＳ Ｔｉｍｅｒ＿ｕの値から成る。これらの値はＴＳ＿ｌａｓｔ、最後
に再生されたヘッダのＲＴＰ ＴＳと次のように関連する：ＴＳ＿ｌａｓｔ＝Ｔ
Ｓ０＿ｕ＋ｍ＿ｌａｓｔ＿ｕ＊ＴＳ＿ｓｔｒｉｄｅ＿ｕ。ＴＳ Ｔｉｍｅｒ＿ｕ
は、Ｔミリ秒毎に１だけインクリメントされたソースＡＮＩ＿ＡＤのカウンター
である。更に、ＨＯ＿ｉｎｉｔ＿ｕはｐ＿ｓｉｚｅ＿ｕ（アップリンク方向にお
けるパケットの現在のサイズ）を含む。ＨＯ＿ｉｎｉｔ＿ｕから、ターゲットＡ
ＮＩ＿ＡＤは静止フィールドと、変化するフィールド（ＲＴＰ ＴＳ及びＲＴＰ
ＳＮ）についてのおおよその初期値とを導出する。ハンドオーバー・コマンド
がＨＯマネージャー９０１から端末１３０（移動局）へ送られて、ステップ９１
０、端末１３０に転換をさせて今や通信のためにターゲットＡＮＩ＿ＡＤを使用
させる。しかし、他の技術を使用してハンドオーバーを開始することができるの
で、ＨＯマネージャーは必要ないかも知れない。

【００９７】 ハンドオーバーは、進行中のストリングを中断するものと見なされる。従って
、ハンドオーバー完了後、正に最初に送られるべき音声サンプルは常に新しいス
トリングと同様に取り扱われ、それは初期化情報（ＨＯ＿ｓｙｎｃ＿ｕ）を送る
ことを必要とする、ステップ９１２。重要な時点が３つある：即ちＳＴ１、これ
はＨＯ準備の始まりである、ＳＴ２、これはＭＳによるＨＯコマンドの受信であ
る、及びＳＴ３、これはソースＡＮＩ＿ＡＤがＨＯ＿ｉｎｉｔ＿ｕで送られるべ
きその内部情報のスナップ写真を撮った時点である。ＨＯＴはＳＴ１からＳＴ２
までに経過した時間であるとする。システムのデザインから、ＨＯＴには上限が
ある：ＨＯＴ＜ＨＯＴ＿ｍａｘ。第４の重要な時点はＳＴ４である：端末１３０
がＨＯ後にターゲット・システムで音声を送る動作を再開したいと望む最初の時
点。ＳＴ４において、端末１３０（ＭＳ）はｐ＿ｓｉｚｅ＿ｕの最近の変化がＳ
Ｔ２−ＨＯＴ＿ｍａｘの時までに肯定応答されているか判定する。もしそうなら
ば、端末１３０はＨＯ＿ｉｎｉｔ＿ｕがｐ＿ｓｉｚｅ＿ｕの最新の値を含んでい
たと確信する。従って、それをＨＯ＿ｓｙｎｃ＿ｕに包含させる必要はない。そ
の理由は、それらの時点がＳＴ１＜ＳＴ３＜ＳＴ２という順序になっていること
にある。そうでなければ、端末１３０（ＭＳ）はｐ＿ｓｉｚｅ＿ｕの新しい値を
ＨＯ＿ｓｙｎｃ＿ｕに包含させる。同じアルゴリズムがＴＳ＿ｓｔｒｉｄｅ＿ｕ
にも当てはまる。

【００９８】 全ての場合に、ＨＯ＿ｓｙｎｃ＿ｕはＣ＿ＳＮを含む。Ｃ＿ＳＮは、ＨＯに起
因する中断があったために必要とされる。ソース及びターゲットのシステムにお
いてビットレート、パケット持続時間などが同期化されていなければ、Ｃ＿ＴＳ
が必要とされる。これが事実でありそうである。ＨＯ＿ｓｙｎｃ＿ｕはａｃｋモ
ードで好ましく送られる。

【００９９】 ＨＯ＿ｉｎｉｔ＿ｕ及びＨＯ＿ｓｙｎｃ＿ｕは、次のように完全なヘッダを再
生するためにターゲットＡＮＩ＿ＡＤ１１４により使用される。ＴＳ及びＳＮ以
外の全てのフィールドがＨＯ＿ｉｎｉｔ＿ｕからコピーされる。ＳＮは、ＨＯ＿
ｓｙｎｃ＿ｕの中のＣ＿ＳＮを解凍することにより得られる。ＴＳは、ＨＯ＿ｓ
ｙｎｃ＿ｕの中のＣ＿ＴＳを解凍することにより決定される。

【０１００】 ２．ダウンリンク ＨＳの役割は１つのＡＮＩ＿ＡＤから他へと移される。ハンドオフ後、ヘッダ
は、旧ＡＮＩ＿ＡＤの代わりに新しいＡＮＩ＿ＡＤを通る新しい経路で送られる
。その結果として、端末１３０（ＭＳ）においてＲＴＰ ＴＳ再生についてのタ
イミングに切れ目があり得る。

【０１０１】 アップリンクについてハンドオーバーを処理するために、ＨＯマネージャーは
、ハンドオーバー準備を開始することを決定したとき、ソースＡＮＩ＿ＡＤに通
知をする。ソースＡＮＩ＿ＡＤは次にＨＯ＿初期化（ＨＯ＿ｉｎｉｔ＿ｄ）情報
をターゲットＡＮＩ＿ＡＤに送る。ＨＯ＿ｉｎｉｔ＿ｄはｐ＿ｓｉｚｅ＿ｄとＴ
Ｓ＿ｓｔｒｉｄｅ＿ｄとから成り、それらは、それらの生成番号と共に、ＭＳに
より最後に肯定応答された値である。ターゲットＡＮＩ＿ＡＤがＨＯ後に音声を
初めて送ることを望むとき、ターゲットＡＮＩ＿ＡＤはＨＯ＿ｓｙｎｃ＿ｄを送
らなければならない。ＨＯ＿ｓｙｎｃ＿ｄはＣ＿ＴＳとＣ＿ＳＮとから成る。も
し新しいｐ＿ｓｉｚｅがｐ＿ｓｉｚｅ＿ｄと違っていれば、ＨＯ＿ｓｙｎｃ＿ｄ
はｐ＿ｓｉｚｅの新しい値も含む。もしそうでなければ、ＨＯ＿ｓｙｎｃ＿ｄは
ｐ＿ｓｉｚｅ＿ｄの生成番号ｎを含むだけである。ＭＳはその生成番号を使用し
て正しいｐ＿ｓｉｚｅを引き出す。これは、ＭＳが、メモリーに、ｐ＿ｓｉｚｅ
の最後の数個の値を、それらの生成番号と共に維持していることを仮定している
。同じアルゴリズムがＴＳ＿ｓｔｒｉｄｅに適用される。ＨＯ＿ｉｎｉｔ＿ｄは
、ＭＳ＿ＡＤにより肯定応答されるまで送られる。ＨＯ＿ｓｙｎｃ＿ｄはａｃｋ
モードで送られる。ハンドオーバー・プロセスは図２に描かれている。示されて
いる場合は：ｐ＿ｓｉｚｅの最近の変化がＳＴ２−ＨＯＴ＿ｍａｘの時までに肯
定応答されているという場合である。

【０１０２】 Ｅ．メッセージを送る 上記情報の各々はイン・バンド（バンド内）またはアウト・オブ・バンド（バ
ンド外）で送られることができる。イン・バンドのアプローチでは、情報は最下
位音声ビットをうまく手に入れることにより音声チャネルで送られる。アウト・
オブ・バンドのアプローチでは、専用の一時的チャネルが設立され、ａｃｋが受
信されたときに破壊される。イン・バンド及びアウト・オブ・バンドの結合が可
能であり、その場合にはアウト・オブ・バンドのアプローチが試みられるが、一
時的チャネルのための資源が無ければ、イン・バンドのアプローチがいざという
ときの解決策である。肯定応答は、イン・バンドで、またはアウト・オブ・バン
ドでそれら自身の専用ａｃｋチャネルで、または他の専用一時チャネル（ＴＩＣ
、など）でアウト・オブ・バンドで背負って運ばれることができる。

【０１０３】 １．イン・バンド 回路のような音声チャネルがどの様に実現されるのかということに関わらず、
それはＴミリ秒毎にＢビットを伝送することのできるチャネルとしてモデル化さ
れることができる。Ｓがビットを単位とする音声フレームのサイズであるならば
、Ｓ≦Ｂである。企図される音声コーデックでは、Ｉｎｉｔ＿ｉｎｆｏはＳより
大きいと期待される。従って、単一の音声フレームのスペースでＩｎｉｔ＿ｉｎ
ｆｏを送ることはできない。しかし、（Ｒ−１）＊Ｓ＜Ｈ≦Ｒ＊Ｓなどの要素Ｒ
≧１がある。Ｉｎｉｔ＿ｉｎｆｏ（ｎ）は、それらをＢビットの塊に分割してＴ
ミリ秒毎に１つの塊を送ることにより、回路のようなチャネルで運ばれることが
できる。完全なヘッダは、Ｒ個の連続する音声サンプルのスペースを消費する。
図１１は、本発明の実施例によるイン・バンドについての初期化を図解する図で
ある。連続的な音声活動があるならば、送られるＩｎｉｔ＿ｉｎｆｏは、ａｃｋ
（ｎ）が受信されるまで、Ｉｎｉｔ＿ｉｎｆｏ（０）、Ｉｎｉｔ＿ｉｎｆｏ（Ｒ
）、Ｉｎｉｔ＿ｉｎｆｏ（２Ｒ）、などである。図１１では、これらのｉｎｉｔ
＿ｉｎｆｏメッセージはｉｎｉｔ＿ｉｎｆｏ５００及びｉｎｉｔ＿ｉｎｆｏ５０
２として示されている。ヘッダはぎ取り器は、ｉｎｉｔ＿ｉｎｆｏ５００を受け
取ったことを知らせるが、ＨＳ８１０が第２のｉｎｉｔ＿ｉｎｆｏパケット５０
２を送る前にではない。次のパケット５０４は（ヘッダの無い）パケット・ペイ
ロード５０４としてＨＳ８１０からＨＲ８２２に送られる。ＨＲ８２２は次にＳ
Ｎ及びＴＳ及びその他のヘッダ・フィールドを再生する。

【０１０４】 Ｉｎｉｔ＿ｉｎｆｏ（０）は音声サンプル０、１、・・・、（Ｒ−１）に代わ
り、Ｉｎｉｔ＿ｉｎｆｏ（Ｒ）は音声サンプルＲ、（Ｒ＋１）、・・・、（２Ｒ
−１）に代わる、などである。もし不連続的音声活動があれば、例えばヘッダ０
の後にＬ＊Ｔミリ秒沈黙間隔が続けば、Ｉｎｉｔ＿ｉｎｆｏ（０）が繰り返され
る：他の情報（ｓｔｒｉｎｇ＿ｉｎｉｔ、ＨＯ＿ｓｙｎｃ＿ｄ、ＨＯ＿ｓｙｎｃ
＿ｕ、Ａｃｋ）は、全てＳよりかなり小さいサイズを有するので、音声フレーム
のスペースにぴったりはまり込む。それらは最下位音声ビットをうまく入手する
。簡単のために、分析はチャネル符号化に起因する拡大を考慮しないが、該構想
はチャネルがあってもなくても妥当である。イン・バンドの場合についての初期
化プロセスが図３に示されている。

【０１０５】 ２．アウト・オブ・バンド 図１２は、本発明の実施例によるアウト・オブ・バンドについての初期化を図
解する図である。アウト・オブ・バンドのアプローチでは、音声チャネルで運ば
れる音声と同時にＩｎｉｔ＿ｉｎｆｏだけを運ぶために適切な帯域幅を伴って別
のチャネルが設立される。その別のチャネルは一時的初期化チャネル（ＴＩＣ）
と称される。システムは、完全なヘッダをＴミリ秒に１回送ることを可能にする
ために充分な帯域幅をＴＩＣに割り当てようと試みることができる。ＴＩＣは、
音声チャネルと固定されたタイミング関係を有するように設計される。肯定応答
は、一時的肯定応答チャネル（ＴＡＣ）を割り当てることによりアウト・オブ・
バンドで送られることができ、或いはアウト・オブ・バンドで、しかし順方向一
時的チャネルで背負って運ばれることができる。ＨＯ＿ｓｙｎｃ＿ｕは一時的ア
ップリンク・ハンドオーバー同期化チャネル（ＴＵＨＯＳＣ）を介してアウト・
オブ・バンドで送られることができる。ＴＵＨＯＳＣは、ＨＯ＿ｓｙｎｃ＿ｕが
肯定応答されたときに破壊される。同じことがＨＯ＿ｓｙｎｃ＿ｄに当てはまる
が、これは一時的ダウンリンク・ハンドオーバー同期化チャネル（ＴＤＨＯＳＣ
）を使用する。

【０１０６】 ３．故障の場合 ハンドオーバー実行が完了するときまでにターゲットＡＮＩ＿ＡＤがＨＯ＿Ｉ
ｎｉｔを持たない場合があり得る。理由は、２つのＡＮＩ＿ＡＤ間のシグナリン
グ・ネットワークでの過度の遅延、ハンドオーバーを速く実行する必要、などを
含む。これらの場合には、ネットワークは通知をＭＳに送り、それはコールの始
まりの時の様に、初期化プロセスを再始動させる。

【０１０７】 ４．Ｐ＿Ｓｉｚｅ及びＴＳ＿ｓｔｒｉｄｅが一定であるありふれた場合 ｐ＿ｓｉｚｅ及びＴＳ＿ｓｔｒｉｄｅが一定である場合は音声については最も
ありふれている。この場合、ｐ＿ｓｉｚｅ及びＴＳ＿ｓｔｒｉｄｅのあり得る変
化に起因する考慮事項はいずれも当てはまらない。包括的な方式は簡単化される
。ＨＯ＿Ｉｎｉｔ＿ｄは不要である。ＨＯ＿ｓｙｎｃ＿ｄ及びＨＯ＿ｓｙｎｃ＿
ｕはＣ＿ＳＮ及びＣ＿ＴＳを運ぶだけである。Ｓｔｒｉｎｇ＿ｉｎｉｔはＣ＿Ｓ
Ｎを運ぶ。それは、１つのストリングから次のへとタイミング変化がある場合に
限ってＣ＿ＴＳを運ぶ。端末（ＭＳ）は、ｐ＿ｓｉｚｅ及びＴＳ＿ｓｔｒｉｄｅ
の最後の数個の値をメモリーに維持しなくても良い。ＨＯの場合、端末（ＭＳ）
はｐ＿ｓｉｚｅ＿ｕをＨＯ＿ｓｙｎｃ＿ｕに含めるかどうか決定しなくても良い
。

【０１０８】 前述したように、基本的音声のために必須のＩＰ／ＵＤＰ／ＲＴＰヘッダ中の
情報は静止フィールドとＲＴＰタイムスタンプ（ＴＳ）とであり、ＲＴＰシーケ
ンス番号（ＳＮ）も非常に望ましい。本書に記載されている方式は、これらの情
報フィールドについての透明性を達成し、有利なヘッダ・オーバーヘッド圧縮効
率を提供する。全ての静止フィールド及び非静止フィールドの連続性がハンドオ
ーバーの間維持される。イン・バンド・アプローチもアウト・オブ・バンド・ア
プローチも可能なので、帯域幅管理も容易になる。ＲＴＰ ＴＳ及びＲＴＰ Ｓ
Ｎについて透明性が維持されるので、ヘッダはぎ取り方式と全てのフィールドに
ついて透明性を維持する本書に記載されているヘッダ圧縮方式との間で切り換え
ることも可能である。ヘッダ圧縮への切り換えは、例えば他の媒体が音声に付け
加えられるときに必要になることがある。

【０１０９】 ＩＩＩ．タイマー及び基準に基づく方式 Ａ．タイマー及び基準に基づく方式概観 タイマー及び基準に基づく方式は、（１）ＲＴＰタイムスタンプはＲＴＰソー
スで作られるときにパケット間の経過時間の線形関数と相関させられ、（２）Ｒ
ＴＰ ＴＳはＴＳ０＋ｉｎｄｅｘ＊ＴＳ＿ｓｔｒｉｄｅの形であって、ここでＴ
Ｓ０及びＴＳ＿ｓｔｒｉｄｅは一定であり、ｉｎｄｅｘは整数である（以降、ｉ
ｎｄｅｘは圧縮されているＲＴＰ ＴＳと称される）という所見に基づいている
。従って、正常動作時には、解凍器で受信されるＲＴＰタイムスタンプも、ソー
スと解凍器との間の累積ジッターによってのみ生じる歪みを伴う、断続的にイン
クリメントするタイマーと相関している。該累積ジッターは“ネットワーク”ジ
ッター（ソースと圧縮器との間のジッター）と“無線”ジッター（圧縮器と解凍
器との間のジッター）とを含むので、圧縮器は、観測されたネットワーク・ジッ
ターに無線ジッターの上限を加えることによって累積ジッターの上限を計算する
ことができる。圧縮器は次に、単に、圧縮されているＲＴＰ ＴＳとして、圧縮
されているＲＴＰ ＴＳの“ｋ”個の最下位ビットを送る。解凍器は、始めに近
似値を計算し、次に正確な値を決定するために圧縮されているＲＴＰ ＴＳ中の
情報で該近似値を改良することによってＲＴＰ ＴＳを解凍する。近似値は、前
に解凍されたヘッダのＲＴＰ ＴＳに、前に解凍されたヘッダが受信されてから
経過した時間に比例する値を加えることによって得られる。ＲＴＰ ＴＳの正確
な値は、対応する圧縮されているＲＴＰ ＴＳのそのｋ個の最下位ビットが圧縮
されているＲＴＰ ＴＳと釣り合う、該近似値に最も近いものとして決定される
。圧縮器は、解凍器が累積ジッターの上限に基づいて正しく解凍することを許す
最小の許される値として値ｋを選ぶ。

【０１１０】 Ｂ．音声の場合 始めに、タイマー及び基準に基づく方式を音声に関して説明する。例として、
もし連続する音声サンプルの間の時間間隔が２０ミリ秒であるならば、ヘッダｎ
（時点ｎ＊２０ミリ秒において作られる）のＲＴＰタイムスタンプ＝ヘッダ０（
時点０で作られる）のＲＴＰタイムスタンプ＋ＴＳ＿ｓｔｒｉｄｅ＊ｎであり、
ここでＴＳ＿ｓｔｒｉｄｅは音声コーデックに依存する定数である。その結果と
して、解凍器に入ってくるヘッダ中のＲＴＰ ＴＳも、ソースと解凍器との間の
遅延ジッターのためあまり厳密にではないけれども、時間の関数として線形パタ
ーンに従う。正常動作時には（クラッシュ或いは故障が無い）、遅延ジッターは
制限されていて、会話実時間トラフィックの要件を満たす。

【０１１１】 この方式では、レシーバーは現在のヘッダ（解凍されるべきもの）のＲＴＰ
ＴＳの近似値を得るためにタイマーを使用し、次に圧縮されているヘッダで受信
される付加的情報で該近似値を改良する。

【０１１２】 例えば、下記を仮定する： Ｌａｓｔ＿ｈｅａｄｅｒは最後に首尾良く解凍されたヘッダであり、ここで
ＴＳ＿ｌａｓｔは最後のＲＴＰ ＴＳであり、ｐ＿ＴＳ＿ｌａｓｔは最後の圧縮
されているＲＴＰ ＴＳ（レシーバーにおける）である； Ｔは２つの連続する音声サンプル間の標準の時間間隔である； ＴＳ＿ｓｔｒｉｄｅはＴミリ秒毎のＲＴＰ ＴＳインクリメントである； Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒは解凍されるべき現在のパケットのヘッダで
あり、ここでＴＳ＿ｃｕｒｒｅｎｔは現在のＲＴＰ ＴＳであり、ｐ＿ＴＳ＿ｃ
ｕｒｒｅｎｔは現在の圧縮されているＲＴＰ ＴＳであり； ＲＦＨは、そのａｃｋが圧縮器により受信されたヘッダのシーケンス番号で
あり、ここでＴＳ＿ＲＦＨはＲＴＰ ＴＳであり、ｐ＿ＴＳ＿ＲＦＨは圧縮され
ているＲＴＰ ＴＳであり； ＴｉｍｅｒはＴミリ秒毎にインクリメントされるタイマーであり、ここで圧
縮器及び解凍器の両方は、各々、Ｓ＿ｔｉｍｅｒ及びＲ＿ｔｉｍｅｒとそれぞれ
表示されるそれらのＴｉｍｅｒを維持し； Ｔ＿ＲＦＨはＲＦＨが受信されているときのＴｉｍｅｒの値であり、Ｔ＿ｃ
ｕｒｒｅｎｔはＣｕｒｒｅｎｔ＿ｈｅａｄｅｒが受信されているときの同じＴｉ
ｍｅｒの値であり；そして Ｎ＿ｊｉｔｔｅｒ（ｎ，ｍ）は、ヘッダｍに対する相対的なヘッダｎの観測
されたネットワーク・ジッターである（ヘッダｎはヘッダｍの後に受信される）
、 ここでＮ＿ｊｉｔｔｅｒ（ｎ，ｍ）は圧縮器により次のように計算される： Ｎ＿ｊｉｔｔｅｒ（ｎ，ｍ）＝Ｔｉｍｅｒ（ｎ、ｍ）−（ヘッダｎの圧縮さ
れているＲＴＰ ＴＳ−ヘッダｍの圧縮されているＲＴＰ ＴＳ）、 ここでＴｉｍｅｒ（ｎ、ｍ）は、ヘッダｍからヘッダｎまでに経過した、Ｔ
ミリ秒を単位として表示された時間である。Ｎ＿Ｊｉｔｔｅｒ（ｎ、ｍ）は正ま
たは負であり得る。圧縮器におけるＮ＿Ｊｉｔｔｅｒは、Ｔミリ秒を単位として
量子化されたネットワーク・ジッターである。

【０１１３】 Ｒ＿Ｊｉｔｔｅｒ（ｎ、ｍ）は、圧縮器により予測される、ヘッダｍに対する
相対的なヘッダｎの無線ジッターである。Ｒ＿Ｊｉｔｔｅｒは、圧縮器−解凍器
チャネル（ＣＤ−ＣＣ）の特性のみに依存する。Ｒ＿Ｊｉｔｔｅｒは精密に計算
されなくても良くて、Ｒ＿Ｊｉｔｔｅｒについての良好な上限で充分である。例
えば、上限は、もしそれが知られているのならば、Ｍａｘ−ｒａｄｉｏ＿ｊｉｔ
ｔｅｒ、即ちＣＤ−ＣＣでの最大ジッターであって良い。

【０１１４】 従って、上記に従って、パケットについての累積ジッターはネットワーク・ジ
ッターと無線との合計として計算される： 更に、ＲＴＰ ＴＳは次のように計算される： ＲＴＰ ＴＳ＝ＴＳ０＋ｉｎｄｅｘ＊ＴＳ＿ｓｔｒｉｄｅ、 ここでＴＳ０＜ＴＳ＿ｓｔｒｉｄｅであり、ｉｎｄｅｘは整数である。 従ってＴＳ＿ｌａｓｔ＝ＴＳ０＋ｉｎｄｅｘ＿ｌａｓｔ＊ＴＳ＿ｓｔｒｉｄｅ
であり、そして ＴＳ＿ｃｕｒｒｅｎｔ＝ＴＳ０＋ｉｎｄｅｘ＿ｃｕｒｒｅｎｔ＊ＴＳ＿ｓｔｒｉ
ｄｅである。

【０１１５】 １．圧縮器 圧縮器は、圧縮されているヘッダで、ｐ＿ＴＳ＿ｃｕｒｒｅｎｔのｋ個の最下
位ビットを送る。

【０１１６】 圧縮器は次のアルゴリズムを動作させてｋを決定する： Ｍａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒを計算する； Ｊ１＝Ｍａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒ＋Ｍａｘ＿ｒａｄｉｏ＿ｊｉ
ｔｔｅｒ＋Ｊを計算する、 ここでＪ＝２は圧縮器及び解凍器においてＴｉｍｅｒｓにより生じる量子化
エラーを償うための因数であり、それは＋１または−１であることができ；そし
て 条件： （２＊Ｊ１＋１）＜２^k を満たす最小の整数ｋを発見する。

【０１１７】 圧縮器におけるネットワーク・ジッターは３つの異なる方法、即ち図１３に図
解されている第１の方法、図１４に図解されている第２の方法及び図１５に図解
されている第３の方法、に従って計算されることができる。第２の方法及び第３
の方法について以下でそれぞれオプション１及びオプション２として説明する。
第１の方法はネットワーク・ジッターを計算するためには充分である。しかし、
圧縮におけるネットワーク・ジッターを計算するための好ましい方法は以下でそ
れぞれオプション１及びオプション２として説明される第２及び第３の方法であ
る。

【０１１８】 図１３に図解されているように、第１の方法によると圧縮器における特定のパ
ケットについてのネットワーク・ジッターは直前のパケットに関する情報を用い
て計算される。例えば、パケット２についてのネットワーク・ジッター（ｊ２）
はパケット１に関する情報を用いて計算され、パケット３についてのネットワー
ク・ジッター（ｊ３）はパケット２に関する情報を用いて計算され、パケット４
についてのネットワーク・ジッター（ｊ４）はパケット３に関する情報を用いて
計算され、パケット５についてのネットワーク・ジッター（ｊ５）はパケット４
に関する情報を用いて計算される。

【０１１９】 従って、図１３によると、パケット２についてのネットワーク・ジッターは計
算されたジッターｊ２に等しく、パケット３についてのネットワーク・ジッター
は計算されたジッターｊ３に等しく、パケット４についてのネットワーク・ジッ
ターは計算されたジッターｊ４に等しく、パケット５についてのネットワーク・
ジッターは計算されたジッターｊ５に等しい。

【０１２０】 オプション１： オプション１の第２方法についてネットワーク・ジッターを計算するために使
用されるステップが図１４に図解されている。オプション１では、特定のパケッ
トについてのネットワーク・ジッターは、基準パケットに関する情報を用いて計
算される。パケット２が図１４に図解されている基準パケットであると仮定して
、パケット３のジッターｊ３は基準パケット２に関する情報を用いて計算され、
パケット４のジッターｊ４は基準パケット２に関する情報を用いて計算され、パ
ケット５のジッターｊ５は基準パケット２に関する情報を用いて計算される。

【０１２１】 図１４に図解されているオプション１の第２方法によると、ジッターｊ３＝２
、ジッターｊ４＝３、そしてジッターｊ５＝−１と仮定すると、パケット５の前
にはＮ＿ｊｉｔｔｅｒ＿ｍｉｎ＝２でＮ＿ｊｉｔｔｅｒ＿ｍａｘ＝３であり、パ
ケット５においてはＮ＿ｊｉｔｔｅｒ＿ｍｉｎ＝−１でＮ＿ｊｉｔｔｅｒ＿ｍａ
ｘ＝３である。従って、パケット５での最大（Ｍａｘ）ネットワーク・ジッター
＝Ｎ＿ｊｉｔｔｅｒ＿ｍａｘ−Ｎ＿ｊｉｔｔｅｒ＿ｍｉｎ＝４である。従って、
パケット５についてのＭａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒは４である。オプ
ション１の方法によりネットワーク・ジッターを計算するための方程式とその説
明とを以下に提示する。

【０１２２】 現在のパケットのネットワーク・ジッターはオプション１の方法に従って次の
ように計算される： Ｎ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ）＝ （Ｔ＿ｃｕｒｒｅｎｔ−Ｔ＿ＲＦＨ）−（ｐ＿ＴＳ＿ｃｕｒｒｅｎｔ−ｐ＿Ｔ
Ｓ＿ＲＦＨ）； Ｎ＿ｊｉｔｔｅｒ＿ｍａｘ及びＮ＿ｊｉｔｔｅｒ＿ｍｉｎを更新する、ここで
Ｎ＿ｊｉｔｔｅｒ＿ｍａｘは、ＲＦＨ以来送られてＲＦＨを含む全てのヘッダｊ
についてＭａｘ｛Ｎ＿ｊｉｔｔｅｒ（ｊ、ＲＦＨ）｝として定義される。Ｎ＿ｊ
ｉｔｔｅｒ＿ｍｉｎは、ＲＦＨ以来送られてＲＦＨを含む全てのヘッダｊについ
てＭｉｎ｛Ｎ＿ｊｉｔｔｅｒ（ｊ、ＲＦＨ）｝として定義され； Ｍａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒ＝（Ｎ＿ｊｉｔｔｅｒ＿ｍａｘ−Ｎ＿
ｊｉｔｔｅｒ＿ｍｉｎ）を計算する。

【０１２３】 Ｎ＿ｊｉｔｔｅｒ＿ｍａｘ及びＮ＿ｊｉｔｅｒ＿ｍｉｎは正または負であるこ
とができるけれども、（Ｎ＿ｊｉｔｔｅｒ＿ｍａｘ−Ｎ＿ｊｉｔｅｒ＿ｍｉｎ）
は正であることに注意するべきである。

【０１２４】 オプション２： オプション２の第３方法でネットワーク・ジッターを計算するために使用され
るステップが図１５に図解されている。オプション２では、特定のパケットでの
ネットワーク・ジッターは、興味あるパケットと所定数の先行パケットの各々と
の間のジッター計算を用いて計算される。その所定数の先行するパケットはウィ
ンドウとして定義され、そのウィンドウは如何なる値であっても良い。図１５に
図解されている例では、ウィンドウは４先行パケットの値を有する。該ウィンド
ウは例えば７パケットなど、他の如何なる値に設定されても良い。更に、例えば
、ウィンドウは最後の基準パケット以来のパケット数に等しい値に設定されても
良い。

【０１２５】 図１５に図解されているように、パケット５についてのネットワーク・ジッタ
ーは、パケット１に関する情報ｊ（５，１）、パケット２に関する情報ｊ（５，
２）、パケット３に関する情報ｊ（５，３）及びパケット４に関する情報ｊ（５
，４）を用いて計算される。図１５に図解されているように、パケット１の各々
に関してパケット５について計算されるネットワーク・ジッターがｊ（５，１）
＝２、パケット２に関してｊ（５，２）＝３、パケット３に関してｊ（５，３）
＝４，そしてパケット４に関してｊ（５，４）＝７であるならば、ｍａｘ＿ｎｅ
ｔｗｏｒｋ＿ｊｉｔｔｅｒ＝７である。オプション２の第３方法に従ってネット
ワーク・ジッターを計算するための方程式とそれについての説明を以下において
呈示する。

【０１２６】 現在のパケットのネットワーク・ジッターはオプション２の方法に従って次の
ように計算される： 現在のヘッダの前に送られた、ウィンドウＷに属する全てのヘッダｊについて
計算されたＮ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ｊ）＝（Ｔ＿ｃ
ｕｒｒｅｎｔ−Ｔ＿ｊ）−（ｐ＿ＴＳ＿ｃｕｒｒｅｎｔ−ｐ＿ＴＳ＿ｊ）であり
、ここでＴ＿ｊはヘッダｊが受信されたときのタイマー値であり、ｐ＿ＴＳ＿ｊ
はヘッダｊの圧縮されているＲＴＰ ＴＳである；そして ウィンドウＷ内の全てのｊにわたってＭａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒ
＝｜Ｍａｘ Ｎ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ｊ）｜を計算
する。

【０１２７】 解凍器からのフィードバックを利用できる場合には、ウィンドウＷは正しく受
信されたと分かっている（例えば、肯定応答された）最後のヘッダ以来送られた
ヘッダを含む。フィードバック無しの場合には、ウィンドウＷは送られた最後の
Ｌ個のヘッダを含み、このＬは１つのパラメータである。

【０１２８】 ２．解凍器 Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒのＲＴＰ ＴＳを解凍するために、レシーバー
は、Ｌａｓｔ＿ｈｅａｄｅｒが受信されてから経過した時間をＴミリ秒を単位と
して計算する。その時間、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、Ｌａｓ
ｔ＿ｈｅａｄｅｒ）がｐ＿ＴＳ＿ｃｕｒｒｅｎｔの近似値を与えるためにｐ＿Ｔ
Ｓ＿ｌａｓｔに加えられる。レシーバーは、その後、そのｋ個の最下位ビットが
圧縮されているＲＴＰ ＴＳと調和する、該近似値に最も近い値を選ぶことによ
ってｐ＿ＴＳ＿ｃｕｒｒｅｎｔの正しい値を決定する。次にＴＳ＿ｃｕｒｒｅｎ
ｔはＴＳ０＋（ｐ＿ＴＳ＿ｃｕｒｒｅｎｔ）＊ＴＳ＿ｓｔｒｉｄｅとして計算さ
れる。

【０１２９】 Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、Ｌａｓｔ＿ｈｅａｄｅｒ）は（
Ｔ＿ｃｕｒｒｅｎｔ−Ｔ＿ｌａｓｔ）として計算されることができ、ここでＴ＿
ｃｕｒｒｅｎｔ及びＴ＿ｌａｓｔはＣｕｒｒｅｎｔ＿ｈｅａｄｅｒ及びＬａｓｔ
＿ｈｅａｄｅｒがそれぞれ受信されたときのＲ＿Ｔｉｍｅｒの値である。

【０１３０】 ３．正しさの証拠 タイマー及び基準に基づく方式の訂正を証明するために、下記が仮定される： Ａｐｐｒｏｘ＿ＴＳは、ｐ＿ＴＳ＿Ｌａｓｔ＋Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿
ｈｅａｄｅｒ、Ｌａｓｔ＿ｈｅａｄｅｒ）として計算されたｐ＿ＴＳ＿ｃｕｒｒ
ｅｎｔの近似値であり； Ｅｘａｃｔ＿ＴＳはｐ＿ＴＳ＿ｃｕｒｒｅｎｔの正しい値である。 上記に基づいて： ｜Ａｐｐｒｏｘ＿ＴＳ−Ｅｘａｃｔ＿ＴＳ｜＜＝｜Ｊｉｔｔｅｒ（Ｃｕｒｒｅ
ｎｔ＿ｈｅａｄｅｒ、Ｌａｓｔ＿ｈｅａｄｅｒ）｜； 解凍器におけるＭａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒの定義により： ｜Ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、Ｌａｓｔ＿ｈｅａｄｅｒ）
｜≦Ｊ１、 ここでＪ１＝Ｍａｘ＿ｎｅｔｗｏｒｋ＿ｊｉｔｔｅｒ＋Ｍａｘ＿ｒａｄｉｏ＿
ｊｉｔｔｅｒ＋Ｊである。 Ｊは圧縮器及び解凍器におけるＴｉｍｅｒｓに起因する量子化エラーを償うた
めに加えられる因数であり、それは＋１または−１であることができる。従って
、Ｊ＝２で充分である。 従って、次のようになる： ｜Ａｐｐｒｏｘ＿ＴＳ−Ｅｘａｃｔ＿ＴＳ｜≦Ｊ１ アンビギュイティー無しでＥｘａｃｔ＿ＴＳを計算するためには、（２＊Ｊ１
＋１）＜２^kの条件が満たされるようにｋを選べば充分である。

【０１３１】 ４．圧縮器の前でのパケット誤配列の場合 パケット誤配列は減少するＲＴＰシーケンス番号（ＲＴＰ ＳＮ）により検出
されることができる。それが起こったときには、圧縮器は異なる方式、例えばＶ
ＬＥ、を用いて圧縮されているＲＴＰ ＴＳを符号化することができる。解凍器
は、その異なる符号化について、圧縮されているヘッダ内の適当なインジケータ
・ビットにより通知される。

【０１３２】 もう一つのオプションは標準のタイマー及び基準に基づく方式アルゴリズムを
適用することである−誤配列はおそらくより大きなｋの値をもたらす結果とる。

【０１３３】 ５．アップリンク 無線システムで、アップリンク方向については、ネットワーク・ジッターはゼ
ロであり（ＲＴＰソースと圧縮器との両方が無線端末に置かれているので）、無
線ジッターは普通は制限されていて非常に小さいままであるように制御される。
従って、予期されるｋは非常に小さくて一定であり、それはヘッダ・サイズの変
動を最小限にする。アップリンクについては、端末は普通はネットワークから増
大された帯域幅を要求しなければならないので、これは帯域幅管理については非
常に大きな利点である。更に、パケット誤配列は無い。その結果として、タイマ
ーに基づく方式はアップリンクに極めて良く適している。

【０１３４】 ６．ダウンリンク ダウンリンク方向については、ネットワーク・ジッターはゼロではないけれど
も、全体としてのジッターは普通は小さくて実時間要件を満たす。予期されるｋ
もなお小さくて普通は一定である。ｋにはより大きな変動があるかも知れないけ
れども、ネットワークが帯域幅割り当てを制御するので、帯域幅管理はあまり問
題ではない。

【０１３５】 ７．ハンドオフ セルラーシステムでは、アップリンク及びダウンリンクとそれぞれ表示される
、ＭＳからネットワークへの無線リンクとネットワークからＭＳへの無線リンク
とがある。圧縮／解凍がセルラー・リンクに適用されるときには、ＭＳに基づく
機能ＭＳ＿ＡＤ（ＭＳアダプター）があり、これはアップリンク及びダウンリン
クのために圧縮及び解凍をそれぞれ行う。アップリンク及びダウンリンクのため
に解凍及び圧縮をそれぞれ行うＡＮＩ＿ＡＤ（アクセス・ネットワーク・インフ
ラストラクチャー・アダプター）と呼ばれる、ネットワークに基づくエンティテ
ィーがある。

【０１３６】 考察するべきハンドオフの特別の場合はＡＮＩ＿ＡＤ間ハンドオフであり、こ
の場合には旧ＡＮＩ＿ＡＤから新ＡＮＩ＿ＡＤへの切り換えに起因する中断があ
り得る。問題は、ハンドオフ後にＭＳ＿ＡＤ及び新ＡＮＩ＿ＡＤでの圧縮／解凍
が中断無しに続く様にハンドオフの間情報の連続性をどの様に維持するかという
ことである。

【０１３７】 ハンドオフについては、以下で説明する２つの代替方法がある： ａ．第１の方法 第１の方法は、Ｋ．リにより“ヘッダ圧縮のための効率的ハンドオフ手続”に
ついて本出願と同日である１９９９年３月９日に出願された関連出願第０９／５
２２，４９７号に開示されているハンドシェイク方法と共に、ＡＮＩ＿ＡＤとＭ
Ｓ＿ＡＤとの間で交換されるコンテキスト情報のスナップ写真を撮る方式を使用
する。ＲＴＰ ＴＳについては、該コンテキスト情報は基準ヘッダの完全なＲＴ
Ｐ ＴＳを含む。ハンドオフの直後に、圧縮器（アップリンクについてはＭＳ＿
ＡＤ、ダウンリンクについてはＡＮＩ＿ＡＤ）は一時的にタイマーに基づく方式
の使用を中断して基準値に関しての圧縮されているＲＴＰ ＴＳを送る。例えば
、Ｋ．リにより“ヘッダ圧縮のための効率的ハンドオフ手続”について本出願と
同日である１９９９年３月９日に出願された関連出願第０９／５２２，４９７号
に開示されているＶＬＥ符号化を使用することができる。肯定応答が受信される
と、圧縮器は肯定応答された値をＲＦＨとして使用し、タイマーに基づく方式に
戻る。

【０１３８】 ｂ．第２の方法 第２の方法はハンドオフを渡ってタイマーに基づく方式を使用し続ける。

【０１３９】 ｉ．ダウンリンク ＭＳであるレシーバーの側には不連続はない。圧縮器の役割は１つのＡＮＩ＿
ＡＤから他へと移される。ハンドオフ後、ヘッダは旧ＡＮＩ＿ＡＤの代わりに新
ＡＮＩ＿ＡＤを通る新しい経路で送られる。

【０１４０】 −圧縮器 旧ＡＮＩ＿ＡＤは、該ハンドシェイク方法を使って、新ＡＮＩ＿ＡＤに次の情
報：即ちＴ＿ＲＦＨ、ｐ＿ＴＳ＿ＲＦＨ、Ｓ＿Ｔｉｍｅｒの現在の値、ＴＳ０、
及びＴＳ＿ｓｔｒｉｄｅのスナップ写真を渡す。（スナップショット値は、例え
ばＴ＿ＲＦＨ＊など、星印で表示される）。新ＡＮＩ＿ＡＤは、そのＳ＿Ｔｉｍ
ｅｒを旧ＡＮＩ＿ＡＤから受信されたＳ＿Ｔｉｍｅｒの現在の値で初期化し、そ
のタイマーをＴミリ秒毎にインクリメントし始める。旧ＡＮＩ＿ＡＤの現在のＳ
＿ｔｉｍｅｒ値でのＳ＿ｔｉｍｅｒの初期化は概念的記述である。もし単一のＳ
＿ｔｉｍｅｒが複数のフローにより共有されているならば、実際のＳ＿ｔｉｍｅ
ｒは再初期化されない。むしろ、そのＳ＿ｔｉｍｅｒと旧ＡＮＩ＿ＡＤからの値
とのオフセットが記録される。このオフセットは将来の計算において考慮される
。ハンドオフ後の正に第１のヘッダを圧縮するために、新ＡＮＩ＿ＡＤはｐ＿Ｔ
Ｓ＿ｃｕｒｒｅｎｔのｋ個の最下位ビットを送る。新ＡＮＩ＿ＡＤはｋ、即ち使
用されるべきビットの数、を次のように決定する： Ｊ２＝Ｎ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）の上限
＋Ｍａｘ＿ｒａｄｉｏ＿ｊｉｔｔｅｒ＋Ｊ、 ここでｋは（２＊Ｊ２＋１）＜２^kという条件を満たすように選択される。 上記において、Ｍａｘ＿ｒａｄｉｏ＿ｊｉｔｔｅｒは新ＡＮＩ＿ＡＤとＭＳ−
ＡＤとの間のセグメントでの最大ジッターである。 Ｎ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）の上限は次の
ように計算される： ｜Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）−（ｐ＿ＴＳ＿ｃ
ｕｒｒｅｎｔ−ｐ＿ＴＳ＿ＲＦＨ＊）｜＋Ｔ＿ｔｒａｎｓｆｅｒ、ここでＴｉｍ
ｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）は（Ｔ＿ｃｕｒｒｅｎｔ−Ｔ
＿ＲＦＨ＊）であり； Ｔ＿ｃｕｒｒｅｎｔは、Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒが受信されたときの新
ＡＮＩ＿ＡＤにおけるＳ＿Ｔｉｍｅｒの値であり； Ｔ＿ＲＦＨ＊は旧ＡＮＩ＿ＡＤから受信された値であり； Ｔ＿ｔｒａｎｓｆｅｒは、Ｔミリ秒を単位として表した、旧ＡＮＩ＿ＡＤから
新ＡＮＩ＿ＡＤへコンテキスト情報を転送する時間の上限であり； Ｊ＝２である。

【０１４１】 −解凍器 Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒのＲＴＰ ＴＳを解凍するために、レシーバー
はＲＦＨが受信されてから経過した時間をＴミリ秒の単位で計算する。その時間
、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ）、はｐ＿ＴＳ＿ｃｕｒ
ｒｅｎｔの近似値を与えるためにｐ＿ＴＳ＿ＲＦＨに加えられる。レシーバー、
次に、そのｋ個の最下位ビットが圧縮されているＲＴＰ ＴＳと調和する、該近
似値に最も近い値を選ぶことによって、ｐ＿ＴＳ＿ｃｕｒｒｅｎｔの正確な値を
決定する。次にＴＳ＿ｃｕｒｒｅｎｔがＴＳ０＋（ｐ＿ＴＳ＿ｃｕｒｒｅｎｔ）
＊ＴＳ＿ｓｔｒｉｄｅとして計算される。 ＲＦＨが受信されてから経過した時間は（Ｔ＿ｃｕｒｒｅｎｔ−Ｔ＿ＲＦＨ）
として計算されることができる。

【０１４２】 −故障の場合 コンテキスト情報が新ＡＮＩ＿ＡＤに時宜を得て転送され得なかったときには
、新ＡＮＩ＿ＡＤは肯定応答が受信されるまで完全なＲＴＰ ＴＳを送る。

【０１４３】 ｉｉ．アップリンク 解凍器の役割は１つのＡＮＩ＿ＡＤから他へと移される。圧縮器はＭＳに固定
されたままである。

【０１４４】 −解凍器 旧ＡＮＩ＿ＡＤは、ハンドシェイク方法を使って、新ＡＮＩ＿ＡＤに次の情報
：Ｔ＿ＲＦＨ＊、ｐ＿ＴＳ＿ＲＦＨ＊、Ｒ＿Ｔｉｍｅｒ＊の現在の値、ＴＳ０、
及びＴＳ＿ｓｔｒｉｄｅ、のスナップ写真を転送する。新ＡＮＩ＿ＡＤは、旧Ａ
ＮＩ＿ＡＤ²から受信されたＲ＿Ｔｉｍｅｒの現在の値でそのＲ＿Ｔｉｍｅｒを
初期化し、そのタイマーをＴミリ秒毎にインクリメントし始める。旧ＡＮＩ＿Ａ
Ｄの現在のＲ＿ｔｉｍｅｒ値でのＲ＿ｔｉｍｅｒの初期化というのは正に概念的
記述である。もし単一のＲ＿ｔｉｍｅｒが複数のフローにより共有されているな
らば、実際のＲ＿ｔｉｍｅｒは再初期化されない。むしろ、そのＲ＿ｔｉｍｅｒ
と旧ＡＮＩ＿ＡＤからの値とのオフセットが記録される。このオフセットは将来
の計算において考慮される。ハンドオフ後の正に第１のヘッダを解凍するために
、新ＡＮＩ＿ＡＤは、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ）を
計算し、ｐ＿ＴＳ＿ｃｕｒｒｅｎｔの近似値を与えるためにそれをｐ＿ＴＳ＿Ｒ
ＦＨ＊に加える。レシーバーは、次に、そのｋ個の最下位ビットが圧縮されてい
るＲＴＰ ＴＳと調和する、該近似値に最も近い値を選ぶことによって、ｐ＿Ｔ
Ｓ＿ｃｕｒｒｅｎｔへの正確な値を決定する。次にＴＳ＿ｃｕｒｒｅｎｔがＴＳ
０＋（ｐ＿ＴＳ＿ｃｕｒｒｅｎｔ）＊ＴＳ＿ｓｔｒｉｄｅとして計算される。

【０１４５】 Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ）は（Ｔ＿ｃｕｒｒｅｎ
ｔ−Ｔ＿ＲＦＨ＊）として見積もられることができる。Ｔ＿ｃｕｒｒｅｎｔは、
Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒが受信されたときのＲ＿ｔｉｍｅｒの値である。

【０１４６】 −圧縮器 ＭＳ＿ＡＤはｐ＿ＴＳ＿ｃｕｒｒｅｎｔのｋ個の最下位ビットを送る。それは
ｋ、即ち使用されるべきビットの数、を次のように決定する： ｋが（２＊Ｊ２＋１）＜２^kという条件を満たすように選択されたとき、Ｊ２
＝Ｎ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）の上限＋Ｍａ
ｘ＿ｒａｄｉｏ＿ｊｉｔｔｅｒ＋Ｊを計算する。 ここでＭａｘ＿ｒａｄｉｏ＿ｊｉｔｔｅｒは新ＡＮＩ＿ＡＤとＭＳ＿ＡＤとの
間のセグメントでの最大ジッターである。

【０１４７】 Ｎ＿ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）の上限は｜Ｔ
ｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）−（ｐ＿ＴＳ＿ｃｕｒｒ
ｅｎｔ＿ｈｅａｄｅｒ−ｐ＿ＴＳ＿ＲＦＨ＊）｜＋Ｔ＿ｔｒａｎｓｆｅｒとして
計算され、 ここでＴｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）は（Ｔ＿ｃｕ
ｒｒｅｎｔ−Ｔ＿ＲＦＨ＊）であり； Ｔ＿ｃｕｒｒｅｎｔは現在のヘッダが受信されたときの新ＡＮＩ＿ＡＤにおけ
るＳ＿Ｔｉｍｅｒの値であり； Ｔ＿ＲＦＨ＊は旧ＡＮＩ＿ＡＤから受信される値であり； Ｔ＿ｔｒａｎｓｆｅｒは、Ｔミリ秒の単位で表された、旧ＡＮＩ＿ＡＤから新
ＡＮＩ＿ＡＤへコンテキスト情報を転送する時間の上限であり；そして Ｊ＝２である。

【０１４８】 −故障の場合 コンテキスト情報が新ＡＮＩ＿ＡＤへ時宜を得て転送され得ないときには、新
ＡＮＩ＿ＡＤはＭＳ＿ＡＤに通知し、これは肯定応答が受信されるまで完全なＲ
ＴＰ ＴＳを送る。

【０１４９】 ８．該方式の性能 会話実時間要件のために、正常動作時の累積ジッターは大きくてもＴミリ秒の
僅か数倍であると予期される。従って、１６〜３２音声サンプルまでのジッター
が訂正され得るので、およそ４或いは５のｋの値で充分である。

【０１５０】 この方式の利点は次の通りである： 圧縮されているヘッダのサイズは一定で小さい。圧縮されているヘッダは、通
常、メッセージのタイプを示すメッセージ・タイプ（ｋ１ビット）と、どのフィ
ールドが変化するか示すビット・マスクと、ｉｎｄｅｘ＿ｃｕｒｒｅｎｔのｋ個
の最下位ビットを含むフィールド（ｋビット）とを含む。４ビットＭＳＴＩビッ
ト・マスクが使用され、ｋ１＝４であるとすると、ＲＴＰ ＴＳだけが変化する
ときの（この場合が断然最も頻繁である）圧縮されているヘッダのサイズは１．
５バイトである。更に、該サイズは沈黙の間隔の長さの関数としては変化しない
。 タイマー・プロセスと解凍器プロセスとの間に同期化は不要である。 エラーに対する強さ、圧縮されているヘッダ中の部分的ＲＴＰ ＴＳ情報は自
己充足していて、完全なＲＴＰ ＴＳ値を作るためにはレシーバー・タイマーと
結合されるだけでよいので。ヘッダの喪失または破損は、後の圧縮されているヘ
ッダを無効にはしない。 圧縮器は僅かな記憶情報を維持しなければならないだけである： オプション１ではＴ＿ＲＦＨ、ｐ＿ＴＳ＿ＲＦＨ、Ｎ＿ｊｉｔｔｅｒ＿ｍａｘ
、Ｎ＿ｊｉｔｔｅｒ＿ｍｉｎ、ＴＳ０、及びＴＳ＿ｓｔｒｉｄｅ、そしてオプシ
ョン２ではウィンドウＷ内の全てのｊについて｛Ｔ−ｊ、ｐ−ＴＳ−ｊ｝、ＴＳ
０、及びＴＳ＿ｓｔｒｉｄｅ。

【０１５１】 Ｃ．ジッター減少 会話実時間要件のために、上記のいろいろなジッターは正常動作時には数Ｔミ
リ秒程度であると合理的に予期することができる。しかし、ジッターがもっと大
きく、従ってもっと大きなｋを必要とする場合を除外することはできない。例え
ば、ＲＴＰソースからレシーバーへの経路に異常な状態（故障など）があって、
その間にジッターが過度になることがあり得る。また、ｋの一定の値が望まれ或
いは望ましいという場合もあり得る。これらの場合に対処するために、圧縮器に
対してのフロントエンドとしてジッター減少機能を実現して、過度のジッター（
即ち、何らかのスレショルド値を上回るジッター）を伴うパケットを除去するこ
とができる。

【０１５２】 静止の場合（ハンドオフ無し）には、ジッターは次のようにＪ１として計算さ
れて静止スレショルドと比較される： Ｊ１＝（ｎ＿ｊｉｔｔｅｒ＿ｍａｘ−Ｎ＿ｊｉｔｔｅｒ＿ｍｉｎ）＋Ｍａｘ＿
ｒａｄｉｏ＿ｉｔｔｅｒ＋Ｊ。

【０１５３】 ハンドオフの場合には、ジッターは次のようにＪ２として計算されてハンドオ
フ・スレショルド値と比較される： Ｊ２＝｜Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ＿ｈｅａｄｅｒ、ＲＦＨ＊）−（ｐ＿Ｔ
Ｓ−ｃｕｒｒｅｎｔ−ｐ＿ＴＳ＿ＲＦＨ＊）｜＋Ｔ＿ｔｒａｎｓｆｅｒ＋Ｍａｘ
＿ｒａｄｉｏ＿ｊｉｔｔｅｒ＋Ｊ。

【０１５４】 静止無ハンドオフの場合に関しての主な差は、Ｔ＿ｔｒａｎｓｆｅｒが加えら
れていることである。実際には、ハンドオフを１００ミリ秒で実行できるために
は、Ｔ＿ｔｒａｎｓｆｅｒは約１００ミリ秒までに制限されなければならないの
で、Ｔ＿ｔｒａｎｓｆｅｒ＝Ｔミリ秒（Ｔ＝２０ミリ秒）の単位で約５または６
である。ｋ＝５の値で充分である。

【０１５５】 静止スレショルドとハンドオフ・スレショルドとは同じであることもあり、同
じでないこともある。

【０１５６】 Ｄ．ビデオの場合 ＲＴＰビデオ・ソースの場合には、パケット間の時間間隔は必ずしも一定では
なく、更にＲＴＰ ＴＳは必ずしも１つのパケットから次へと一定ストライドだ
けインクリメントするとは限らない。しかし、ＲＴＰ ＴＳとパケット間の時間
間隔とは個別的である。従って、次の通りである： パケットｍのＲＴＰタイムスタンプ＝パケット０（時点０で作られる）のＲＴ
Ｐタイムスタンプ＋ＴＳ＿ｓｔｒｉｄｅ＊[ｉｎｄｅｘ＋ａｄｊｕｓｔ（ｍ）]、 ここでＴＳ＿ｓｔｒｉｄｅはコーデックに依存する定数であり、ａｄｊｕｓｔ
（ｍ）はｍに依存し音声の場合のように線形挙動に関して差を反映する整数であ
り； ２つの連続するパケット間の時間間隔はＴミリ秒の整数倍である。

【０１５７】 以降は、ＲＴＰソースにおけるその挙動は調整された線形挙動と称される。音
声についてのと同じ標記を使用して、ＴＳ＿ｌａｓｔ＝ＴＳ０＋ＴＳ＋ｓｔｒｉ
ｄｅ＊[ｉｎｄｅｘ＿ｌａｓｔ＋ａｄｊｕｓｔ（ｉｎｄｅｘ＿ｌａｓｔ）]、そし
てＴＳ＿ｃｕｒｒｅｎｔ＝ＴＳ０＋ＴＳ＿ｓｔｒｉｄｅ＊[ｉｎｄｅｘ＿ｃｕｒ
ｒｅｎｔ）＋ａｄｊｕｓｔ（ｉｎｄｅｘ−ｃｕｒｒｅｎｔ]。該Ａｄｊｕｓｔパ
ラメータは正または負であり得る。従って、音声と比べて主な差は追加の項Ａｄ
ｊｕｓｔである。

【０１５８】 ＲＴＰ ＴＳは解凍器に入ってくるヘッダであり、またソース及び解凍器の間
での遅延ジッターに起因してあまり厳密にではないけれども、時間の関数として
調整された線形パターンに従う。正常動作時には（クラッシュまたは故障が無い
）、該遅延ジッターは限られていて、会話実時間トラフィックの要件を満たす。

【０１５９】 上記のようにＣｕｒｒｅｎｔ＿ｈｅａｄｅｒの圧縮されているＲＴＰ ＴＳ＝
ｉｎｄｅｘ＿ｃｕｒｒｅｎｔ＋ａｄｊｕｓｔ（ｉｎｄｅｘ＿ｃｕｒｒｅｎｔ）で
あると仮定される。ｐ＿ＴＳ＿ｃｕｒｒｅｎｔに関して同じ表記が使用され、例
えば、

【０１６０】 圧縮器 圧縮器は、圧縮されているヘッダで、ｐ＿ＴＳ＿ｃｕｒｒｅｎｔのｋ個の最下
位ビットを送る。ｋを決定するアルゴリズムは音声についてと同じである。

【０１６１】 解凍器 使用されるべきアルゴリズムは音声についてと同じである。 １．ハンドオフ 音声について記述されたハンドオフのための２つの代替方法は、ビデオにも同
じく適用される。

【０１６２】 ２．ｋの値 音声については、ｋ＝４または５で充分である（２^k＝１６または３２）こと
が示された。ビデオの場合には、Ａｄｊｕｓｔの結果としてｋのもっと大きな値
が必要である。ビデオは１秒あたり３０フレームで構造化されるので、｜Ａｄｊ
ｕｓｔ｜＜３０である。従って、正常動作時にはｋ＝７または８ビットで充分で
あるはずである。

【０１６３】 本発明の幾つかの実施態様がここで明確に図解され且つ／又は説明されている
。しかし、本発明の精神及び所期の範囲から逸脱することなく本発明の修正形及
び別形が、以上の教示により、添付されている請求項の範囲内に含まれることが
認められるであろう。

【０１６４】 本発明は付随する図面において詳しく絵画的に記述されているけれども、当業
者に認識され得る多くの変更及び修正が、本発明に、その精神及び範囲から逸脱
することなく、なされ得るので、それはその様な詳細には限定されない。

【図面の簡単な説明】

【図１】 本発明の実施例に従うシステムを図解するブロック図である。

【図２】 本発明の実施態様に従うＲＴＰパケットの圧縮されていないフォーマットを図
解する図である。

【図３】 本発明の実施例に従う圧縮されていないＲＴＰヘッダ・フォーマットを図解す
る図である。

【図４】 本発明の実施例に従う圧縮されているＲＴＰヘッダ・フォーマットを図解する
図である。

【図５】 本発明の実施態様に従うヘッダ圧縮及び解凍の動作例を図解する図である。

【図６】 本発明のもう一つの実施態様に従うヘッダ圧縮及び解凍の動作例を図解する図
である。

【図７】 本発明の実施態様に従うハンドオーバーの動作例を図解する図である。

【図８】 本発明の実施例に従うスタック例を図解するブロック図である。

【図９】 本発明の実施例に従ってメッセージに供給されることのできる情報を図解する
表である。

【図１０】 本発明の実施例に従うハンドオーバー・プロセスを図解する図である。

【図１１】 本発明の実施例に従うイン・バンドについての初期化を図解する図である。

【図１２】 本発明の実施例に従うアウトオブバンドについての初期化を図解する図である
。

【図１３】 本発明の第１の方法に従ってネットワーク・ジッターを計算するステップを図
解する図である。

【図１４】 本発明のオプション１として述べられる第２の方法に従ってネットワーク・ジ
ッターを計算するステップを図解する図である。

【図１５】 本発明のオプション２として述べられる第３の方法に従ってネットワーク・ジ
ッターを計算するステップを図解する図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ， ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，Ｉ Ｓ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ， ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，Ｐ Ｔ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ， ＶＮ，ＹＵ，ＺＡ，ＺＷ Ｆターム(参考） 5J064 AA00 BA00 BB07 BC00 BC29 BD02 BD04 5K030 HA08 JA05 MB06 MB13

Claims (45)

【特許請求の範囲】
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. 【請求項３０】 該ソースと該解凍器との間の該ネットワークがパケットの
    伝送に及ぼす前記の第１及び第２のジッター効果は、該移動性のある圧縮器の前
    の該ネットワークのジッター効果を計算し、且つ該圧縮器と解凍器との間の該ネ
    ットワークのジッター効果を計算することによって計算される、請求項２９に記
    載の方法。
31. 【請求項３１】 該圧縮器と解凍器との間の該ネットワークの前記ジッター
    効果は、ジッターについての上限値に設定される、請求項３０に記載の方法。
32. 【請求項３２】 前記第１パケットはハンドオフの直前のパケットであり、
    前記第２パケットはハンドオフの直後のパケットである、請求項２９に記載の方
    法。
33. 【請求項３３】 前記の該移動性のある圧縮器の前の該ネットワークのジッ
    ター効果を計算することは： 基準パケットに関する情報を用いて現在のパケットのジッター効果を計算する
    ことを含む、請求項３０に記載の方法。
34. 【請求項３４】 前記の該移動性のある圧縮器の前の該ネットワークのジッ
    ター効果を計算することは： 前記の現在のパケットと所定数の先行するパケットの各々とに関する情報を用
    いて現在のパケットのジッター効果を計算することを含む、請求項３０に記載の
    方法。
35. 【請求項３５】 前記の該移動性のある圧縮器の前の該ネットワークのジッ
    ター効果を計算することは： 前記の現在のパケットと基準パケットまでの各々の先行するパケットとに関す
    る情報を用いて現在のパケットのジッター効果を計算することを含む、請求項３
    ０に記載の方法。
36. 【請求項３６】 前記ヘッダ・フィールドはタイムスタンプを含む、請求項
    ２９に記載の方法。
37. 【請求項３７】 該圧縮されているヘッダ・フィールドは、圧縮されている
    値の最下位ｋビットとして計算され、ここでｋは整数であり； 該解凍器は、前のパケットの到着から経過した時間と該前のパケットの解凍器
    圧縮されている値とに基づいて該圧縮されている値の近似値を計算する、請求項
    ２９に記載の方法。
38. 【請求項３８】 該圧縮されているヘッダ・フィールドは該フィールド値の
    最下位ｋビットとして計算され、ここでｋは整数である、請求項２９に記載の方
    法。
39. 【請求項３９】 通信システムであって、この通信システムは： 複数のパケットを供給するソースを含み、各パケットはヘッダ・フィールドを
    含み、該ソースはネットワークに結合され； 解凍器を含むレシーバーを含み； ネットワーク・エンティティーを含み、該ネットワーク・エンティティーは該
    ネットワークに結合され且つ該ネットワーク・エンティティーと該レシーバーと
    の間のネットワークによって該レシーバーに結合され、該ネットワーク・エンテ
    ィティーは該ソースから送られて該レシーバーへ向けられた該パケットのうちの
    少なくとも幾つかについてヘッダ・フィールド圧縮を実行するための圧縮器を含
    み、該ネットワーク・エンティティーは、該レシーバー端末へ向けられた該パケ
    ットのジッターを計算し且つ所定値より大きいジッターを有するパケットを捨て
    るためのジッター減少機能を含み、 該ジッターは該ソースと該レシーバーに含まれる該解凍器との間の該ネットワ
    ークに起因するジッターの量の合計として計算される通信システム。
40. 【請求項４０】 前記ジッターは、該圧縮器の前の該ネットワークのジッタ
    ー効果を計算し、且つ該圧縮器と解凍器との間の該ネットワークのジッター効果
    を計算することによって計算される、請求項３９に記載の通信システム。
41. 【請求項４１】 該圧縮器と解凍器との間の該ネットワークの前記ジッター
    効果は、ジッターについての上限値に設定される、請求項３９に記載の通信シス
    テム。
42. 【請求項４２】 該圧縮器の前の該ネットワークの前記ジッターは、基準パ
    ケットに関する情報を用いて現在のパケットのジッター効果を計算することによ
    って計算される、請求項４０に記載の通信システム。
43. 【請求項４３】 前記の該圧縮器の前の該ネットワークのジッター効果を計
    算することは： 前記の現在のパケットと所定数の先行するパケットの各々とに関する情報を用
    いて現在のパケットのジッター効果を計算することを含む、請求項４０に記載の
    通信システム。
44. 【請求項４４】 前記の該圧縮器の前の該ネットワークのジッター効果を計
    算することは： 前記の現在のパケットと基準パケットまでの各々の先行するパケットとに関す
    る情報を用いて現在のパケットのジッター効果を計算することを含む、請求項４
    ０に記載の通信システム。
45. 【請求項４５】 該圧縮されているヘッダ・フィールドは圧縮されている値
    の最下位ｋビットとして計算され、ここでｋは整数であり； 該解凍器は、前のパケットの到着から経過した時間と該前のパケットの解凍器
    圧縮されている値とに基づいて該圧縮されている値の近似値を計算する、請求項
    ３９に記載の通信システム。