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

Description

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

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

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

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

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

タイマーに基づくヘッダ解凍技術等を提供する。

ＲＴＰソースは、ＲＴＰタイムスタンプなどのヘッダ・フィールドを作る。該タイムスタンプはネットワークを介して圧縮器に送られる。該圧縮器において、受信されたタイムスタンプ（ヘッダ）のジッターが過度であるか否か判定するためにジッター減少機能（ＪＲＦ）が使用される。もしジッターが過度であれば、そのパケットは捨てられる。さもなければ、該圧縮器は、ＲＴＰタイムスタンプと該タイムスタンプの初期値とに基づいて圧縮されているヘッダ・フィールド（圧縮されているタイムスタンプ）を計算する。その圧縮されているタイムスタンプは、該ソースと解凍器との間のネットワークがパケットの伝送に及ぼす効果として計算されるジッターを表す。その計算されたジッターは、ソースと圧縮器との間のネットワークがパケットの伝送に及ぼす効果を表すネットワーク・ジッターと圧縮器と解凍器との間のネットワークがパケットの伝送に及ぼす効果を表す無線ジッターとの集積である。本書で使用される“ネットワーク”という用語は、例えば無線電気通信ネットワークにおける無線リンクを排除しない広い用語であるべく意図されている。圧縮されているタイムスタンプを含むＲＴＰパケットは、リンクまたはネットワークを介して解凍器へ送られる。
解凍器は、始めに端末に置かれているタイマーの現在の値に基づいて（即ち、経過した時間に基づいて）タイムスタンプの見積もり或いは近似値を計算することにより、圧縮されているタイムスタンプを解凍する。そのタイムスタンプの近似値は、パケット・ヘッダに与えられている圧縮されているタイムスタンプに基づいて改良或いは訂正される。この様に、現在のパケット（ヘッダ）についてのタイムスタンプがローカル・タイマーと現在のヘッダに与えられている圧縮されているタイムスタンプとに基づいて再生される。そのパケットと再生されたタイムスタンプとは、処理のためにＲＴＰエンドポイントに供給される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明の実施例に従うシステムを図解するブロック図である。 本発明の実施態様に従うＲＴＰパケットの圧縮されていないフォーマットを図解する図である。 本発明の実施例に従う圧縮されていないＲＴＰヘッダ・フォーマットを図解する図である。 本発明の実施例に従う圧縮されているＲＴＰヘッダ・フォーマットを図解する図である。 本発明の実施態様に従うヘッダ圧縮及び解凍の動作例を図解する図である。 本発明のもう一つの実施態様に従うヘッダ圧縮及び解凍の動作例を図解する図である。 本発明の実施態様に従うハンドオーバーの動作例を図解する図である。 本発明の実施例に従うスタック例を図解するブロック図である。 本発明の実施例に従ってメッセージに供給されることのできる情報を図解する表である。 本発明の実施例に従うハンドオーバー・プロセスを図解する図である。 本発明の実施例に従うイン・バンドについての初期化を図解する図である。 本発明の実施例に従うアウトオブバンドについての初期化を図解する図である。 本発明の第１の方法に従ってネットワーク・ジッターを計算するステップを図解する図である。 本発明のオプション１として述べられる第２の方法に従ってネットワーク・ジッターを計算するステップを図解する図である。 本発明のオプション２として述べられる第３の方法に従ってネットワーク・ジッターを計算するステップを図解する図である。

Claims (25)

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. コンピュータに、
    解凍器において圧縮器からタイムスタンプを含むヘッダ・フィールドの初期値を受信した後、該圧縮器において現在のパケットの現在のヘッダ・フィールドとジッターとに基づいて計算された該現在のパケットの圧縮されているヘッダ・フィールドを受信する手順を実行させるプログラムであって、前記の圧縮されているヘッダ・フィールドは、ソースと該解凍器との間のネットワークがパケットの伝送に及ぼすジッター効果として計算される、前記初期値からの差分を示すフィールド値の一部分として圧縮器において計算されており；
    前記プログラムは、更に、
    コンピュータに、
    前の圧縮されているヘッダ・フィールドが該解凍器に到着してからの経過時間と前のパケットの解凍されているフィールド値とに基づいて該解凍器において該現在のパケットの該ヘッダ・フィールドの近似値を計算する手順；
    該現在のパケットの該圧縮されているヘッダ・フィールドに基づいて該解凍器において該現在のパケットについてのヘッダ・フィールド訂正量を計算する手順；そして
    該現在のパケットの該ヘッダ・フィールドの該近似値を該ヘッダ・フィールド訂正量に基づく量だけ調整することによって該解凍器において該現在のパケットの該圧縮されているヘッダ・フィールドを解凍する手順を実行させ、
    該圧縮されているヘッダ・フィールドは表現するのにより少ない数のビットを必要とする圧縮されている値の最下位ｋビットとして計算され、ここでｋは整数であり；そして
    該解凍器は、前のパケットの到着から経過した時間と該前のパケットの解凍されている値とに基づいて該圧縮されている値の近似値を計算するように構成され、
    前記のより少ない数のビットで表現された値は所定の時間間隔を単位として表わされ、
    前記ｋは（（前記のより少ない数のビットで表現され、次に大きい整数に丸められた最大累積ジッター）＋２）＜２ ^ｋ を満たす最小の整数である、
    ことを特徴とするプログラム。

Images