JP3940159B2 - ヘッダ圧縮のための効率的ハンド・オフ処理手順 - Google Patents

Description

本発明は複数のネットワーク・エンティティと移動端末装置間でのヘッダの圧縮／解凍機能に関する。

［関連出願の相互参照］
本願は、“ヘッダ圧縮ための効率的ハンド・オフ処理手順”という表題の米国仮出願番号６０／１６４,３２９の出願日（１９９９年１１月９日出願）の利益を享受するものである。“データ・パケット内でのヘッダ・フィールドの圧縮技法”（上記出願と同一日付）という表題の米国特許出願番号０９/５２２,３６３への参照も行われる。該特許はその全体が本明細書に参考文献として取り入れられている。

リアルタイム・トランスポート・プロトコルの導入以来、ＩＰベースのネットワークを介する実時間のマルチメディア・トラフィックの搬送が大きな関心の対象になっている。無線ネットワークのような低帯域ネットワークでは望ましくないＩＰ／ＵＤＰ／ＲＴＰヘッダのサイズの大きさに起因して、好適なヘッダ圧縮メカニズムが求められている。すべての公知のＲＴＰヘッダ圧縮技法では、圧縮装置（送信機）と解凍装置（受信機）におけるパケットのヘッダの圧縮と解凍に利用されるコンテキスト情報の格納と、ほぼフル・ヘッダの送信による圧縮／解凍処理の初期化が求められる。ヘッダの圧縮／解凍が無線リンクで利用される場合、アップリンク・トラフィックで送信されたヘッダが、移動端末装置により圧縮され、ネットワーク・エンティティにより解凍される。ダウンリンク・トラフィックでは、ネットワーク・エンティティはヘッダの圧縮を行い、移動端末装置はヘッダの解凍を行う。

圧縮／解凍の正常動作時、圧縮用コンテキスト情報によって圧縮されたヘッダの解凍に解凍用コンテキスト情報が利用される場合、元の未圧縮ヘッダが再構成されるという意味で、解凍用コンテキスト情報は圧縮用コンテキスト情報と同期している。到来ヘッダなどに基づいて、圧縮装置と解凍装置により圧縮用コンテキスト情報と解凍用コンテキスト情報の双方をそれぞれ連続して更新することができる。しかし、これら２つのコンテキスト情報は通常同期状態にある。

新しいネットワーク・エンティティへのコンテキスト情報の転送の効率的処理手順が定義されていない場合、移動端末装置が別のネットワーク・エンティティによるサービスを受ける別の無線セルへハンド・オフされると、ヘッダの圧縮／解凍処理は再び再初期化を経て進まなければならない。この再初期化はダウンリンク・トラフィックとアップリンク・トラフィックの双方でフル・ヘッダの送信を必要とする。フル・ヘッダを用いるこのような再初期化は、進行中の通信を破壊し、かつ、エア・インターフェースを介して帯域を費消する。圧縮及び解凍用コンテキスト情報の転送は１つの挑戦である。なぜなら、圧縮／解凍処理は、ハンド・オフ処理に関連して非同期であると同時にハンド・オフ処理から独立しているからである。というのは、前者の圧縮はパケットのフローにより動かされるのに対して、後者の解凍は無線状態により動かされるからである。このため、新しいネットワーク・エンティティが転送されたコンテキスト情報を使用するときまでに、この情報は移動端末装置におけるコンテキストとはすでに同期していていない可能性がある。

図１は、無線ハンド・オフと関連する圧縮及び解凍用コンテキスト情報の転送に関わる従来技術の問題点を例示したものである。ノン・ゼロ・ハンド・オフ準備時間（ＳＴ１〜ＳＴ２）が存在し、その時間中、古いネットワーク・エンティティによって圧縮及び解凍用コンテキスト情報の更新を行うことが可能であり、この更新により、圧縮及び解凍用コンテキスト情報の転送値は古くなったものにされる。その結果、無線ハンド・オフ後の圧縮と解凍が不正確なものになる。さらに、移動端末装置（ＭＳ）が情報交換に関与する場合もあるが、エア・インターフェースを介する情報の転送は最小限に抑える必要がある。

ＲＦＣ２５０８では、各パケット内に短いシーケンス番号が含まれ、エラーやパケット紛失の検出が行われるようになっている。解凍装置が、前回の番号から連続しないシーケンス番号を持つヘッダを受信すると、パケット紛失が検出され、或る回復方式が採用されて、圧縮装置と解凍装置の再同期化が行われる。

長い紛失が頻繁に生じる可能性がある無線ネットワークの場合のようなエラーを受け易いネットワークにとって、パケットの紛失を検出するための短いシーケンス番号の使用はロバストではない。長い紛失は、‘シーケンス・サイクル’の紛失すなわち連続する多くのパケットの紛失として定義される。

長い紛失が生じると、解凍装置によって受信されたパケット内のシーケンス番号がラップ・アラウンドを起こす。例えば、シーケンス番号がｋビットから成ると仮定すると、シーケンス番号・サイクルは２ｋパケットに等しくなる。２ｋのパケットが連続して紛失した場合、連続するシーケンス番号がまだ着信パケットの中で利用できるため、解凍装置はパケットの紛失を検出することはできない。

例えばＲＦＣ２５０８で、S. Casner, V. Jacobsonの“低速直列リンク用ＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮”（インターネット技術タスク・フォース（ＩＥＴＰ）、１９９９年２月）ＲＦＣ２５０８（この文献はその全体が本明細書に参考文献として取り入れられている）に記載されているようなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式は、ヘッダの中で運ばれるある一定の情報フィールドが、１.）変化しない（‘タイプ１’ヘッダ・フィールド）、あるいは、２.）かなり予測可能な方法で変化する（‘タイプ２’ヘッダ・フィールド）という事実を利用するものである。‘タイプ３’ヘッダ・フィールドと呼ばれる別のフィールドは変化するので、すべてのパケットで或る形式で送信を行う必要がある（すなわちこれらの情報フィールドは圧縮可能ではない）。

タイプ１ヘッダ・フィールドの例としてＩＰアドレス、ＵＤＰポート番号、ＲＴＰ ＳＳＲＣ（同期ソース）などがある。これらのフィールドは、（例えばセッション設定時に転送されるパケットの１部として）受信装置／解凍装置へ１回送信するだけで十分である。タイプ１フィールドは‘不変’フィールドとも呼ばれる。

タイプ２ヘッダ・フィールドの例としてはＲＴＰタイム・スタンプ、ＲＴＰシーケンス番号、ＩＰ ＩＤフィールドがある。すべては、パケット（ｎ）からパケット（ｎ＋１）へある一定量だけ増分する傾向がある。したがって、すべてのヘッダでこれらの値を送信する必要はない。上記増分する振舞いを示す各フィールドと関連する一定の増分値（以後第１オーダーの差分（ＦＯＤ）と呼ぶ）は受信装置／解凍装置に認知させる必要があるにすぎない。受信装置／解凍装置は、元のヘッダの再構成を行うとき、これらのＦＯＤを利用してアップ・ツー・デイトなタイプ２フィールド値の再生を行う。タイプ２フィールドは‘変化する’フィールドである。

タイプ２フィールドは時折ある不規則な方法で変化することを強調しておくべきである。このようなイベントの周波数は、（音声やビデオなどの）送信メディアのタイプや、実際のメディア・ソース（例えば音声の場合、上記振舞いは話し手によって変動する可能性がある）や、同じＩＰアドレスを同時に共用する接続チャネル数を含むいくつかの要因に左右される。

タイプ３ヘッダ・フィールドの一例としてＲＴＰ Ｍビット（マーカー）があり、これはメディア内での或る境界（ビデオ・フレームの端部など）の発生を示す。メディアは予想できない方法で通常変化するため、この情報はまったく予測不能である。タイプ３フィールドは‘変化する’フィールドである。

解凍装置は、ヘッダの再構成に関連するすべての関連情報を含む解凍用コンテキスト情報を保持する。この情報は主としてタイプ１フィールド、ＦＯＤ値及びその他の情報である。パケットが紛失したり、破損したりすると、解凍装置は圧縮装置との同期を失う可能性があり、そのためそれ以上パケットの正しい再構成を行うことができなくなる。圧縮装置と解凍装置との間で送信中パケットが脱落したり、破損したりしたとき同期が失われることもある。

上記の現象が生じたとき、圧縮装置はセッションのコース中３つの異なるタイプのヘッダを送信する必要がある：
フル・ヘッダ（ＦＨ）：すべてのヘッダ・フィールド（タイプ１，２，３）の完全なセットを含む。このタイプのヘッダはそのサイズの大きさ（例えばＩＰｖ４の場合４０バイトなど）に起因して送信に最も不適なものである。一般に、（受信機でタイプ１データを設定するために）セッション開始時にのみＦＨパケットの送信を行うことが望ましい。追加ＦＨパケットの送信は圧縮アルゴリズムの効率に悪い影響を与える。圧縮装置は、ＦＨパケットを送信したとき‘ＦＨ状態’にあると言われる。

第１オーダー（ＦＯ）：最低限のヘッダ情報（タイプ３フィールド）と、圧縮装置／解凍装置専用制御フィールド（使用中の圧縮アルゴリズム専用）と、その時点でのＦＯＤフィールドの変化を記述する情報が含まれる。ＦＯパケットは基本的にはＳＯパケット（以下説明する）であり、１以上のタイプ２フィールドに対する新しいＦＯＤ情報の設定を解凍装置で行う追加情報が伴う。ヘッダ圧縮がＶｏＩＰ（インターネット・プロトコルを介する音声）ストリームに適用された場合、ＦＯパケットの送信は、音声内の無音間隔後のトーク・スパート（talk spurt）の発生によりトリガーされる場合がある。このようなイベントの結果、ＲＴＰタイム・スタンプ値の或る予期せぬ変化が生じ、その時点でのＦＯＤ以外の或る値分だけ受信機でＲＴＰタイム・スタンプの更新を行う必要が生じる。ＦＯパケットのサイズは、変化した第１オーダーの差分（および各変化の絶対値の量）を持つタイプ２フィールドの数に依存する。圧縮装置は、ＦＯパケットを送信したとき‘ＦＯ状態’にあると言われる。

第２オーダー（ＳＯ）：ＳＯパケットは最低限のヘッダ情報（タイプ３フィールドなど）と圧縮装置と解凍装置専用の制御フィールドを含む。圧縮装置と解凍装置の望ましい動作モードは、これらのフィールドの最低限のサイズ（わずか２バイトのオーダー）に起因するＳＯパケットの送受信である。圧縮装置がＳＯパケットを送信するとき、装置は‘ＳＯ状態’にあると言われる。ＳＯパケットは、現時点のヘッダがＦＯＤのパターンにぴったり合った場合にだけ送信される。

本発明は、パケットのヘッダの圧縮と解凍に利用される圧縮及び解凍用コンテキスト情報の転送を行い、第１の古いネットワーク・エンティティ（ＡＮＩ ＡＤ）から第２の新しいネットワーク・エンティティ（ＡＮＩ ＡＤ）への、圧縮／解凍機能の切れ目のないリロケーションを可能にする（第１のネットワーク・エンティティ（ＡＮＩ ＡＤ）が停止したところからエンティティは切れ目無く圧縮と解凍を継続する）ものである。本発明はＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮に適用可能であるが、これに限定されるものではない。

本発明の第１の実施態様では、リロケーションは無線ハンド・オフと同時に行われる。ダウンリンク・トラフィックの場合、第１のネットワーク・エンティティは移動解凍装置にその解凍用コンテキスト情報を問い合わせる。移動解凍装置はその解凍用コンテキスト情報のスナップ・ショットをとり、第１のネットワーク・エンティティへコンテキスト情報の表現を送信する。第１のネットワーク・エンティティは同期中（in-synchronism）圧縮用コンテキスト情報を導き出し、第２のネットワーク・エンティティへこの情報を送信する。第２のネットワーク・エンティティは、受信したこのコンテキスト情報を第２のネットワーク・エンティティのコンテキスト情報として格納する。第２のネットワーク・エンティティはこの格納された圧縮用コンテキスト情報を利用して、移動解凍装置へ送信された少なくとも１つのパケットのヘッダを圧縮し、移動解凍装置は予め保存された解凍用コンテキスト情報を利用して少なくとも１つのデータ・パケットのヘッダの解凍を行う。アップリンク・トラフィックの場合、第１のネットワーク・エンティティは、その現時点の圧縮用コンテキスト情報のスナップ・ショットをとり、このコンテキスト情報の値あるいはコンテキスト情報の表現を移動圧縮装置へ送信する。移動圧縮装置は、受信情報の中から同期中の圧縮用コンテキスト情報を導き出し、後続の使用のためにこの情報を保存し、第１のネットワーク・エンティティへ肯定応答を返送する。第１のネットワーク・エンティティは上記スナップ・ショット解凍用コンテキスト情報を第２のネットワーク・エンティティへ送信する。移動圧縮装置は、上記保存されたコンテキスト情報を持つ少なくとも１つのパケットの少なくとも１つのヘッダの圧縮を行い、この圧縮された少なくとも１つのパケットの少なくとも１つのヘッダを第２のネットワーク・エンティティへ送信する。第２のネットワーク・エンティティは、受信した少なくとも１つのヘッダの少なくとも１つのパケットを格納された解凍用コンテキスト情報を利用して解凍する。

本発明の第２の実施態様では、コンテキスト情報のリロケーションは無線ハンド・オフ後まで送信が延期される。第１のネットワーク・エンティティから第２のネットワーク・エンティティへのコンテキスト情報の転送は無線ハンド・オフ後に行われる。ダウンリンク・トラフィック・モードの場合、パケットのヘッダの圧縮に利用する圧縮用コンテキスト情報は、第１のネットワーク・エンティティから第２のネットワーク・エンティティへ転送される。第２のネットワーク・エンティティは受信した圧縮用コンテキスト情報を格納し、その後若干の時間を経て、第２のネットワーク・エンティティによって圧縮された圧縮ヘッダを持つ少なくとも１つのパケットを上記１つの移動解凍装置へ送信する。また、第２のネットワーク・エンティティは、その後若干の時間を経て、第１のネットワーク・エンティティへ圧縮用コンテキスト情報の受信通知を送信し、第１のネットワーク・エンティティは第２のネットワーク・エンティティへの圧縮ヘッダを持つパケットの転送を停止する。アップリンク・トラフィック・モードでは、第１のネットワーク・エンティティにより格納された解凍用コンテキスト情報は第１のネットワーク・エンティティから第２のネットワーク・エンティティへ送信される。次いで、第２のネットワーク・エンティティは、移動圧縮装置から受信したパケットのヘッダの解凍に利用する解凍用コンテキスト情報として受信した解凍用コンテキスト情報を格納する。少なくとも１つのパケット（移動圧縮装置から送信された圧縮されたヘッダを持つ第１の受信パケットである必要はない）の受信に応答する第１のネットワーク・エンティティは、第１のネットワーク・エンティティが圧縮ヘッダを持つ少なくとも１つのパケットを受信した旨のフィードバック情報を第２のネットワーク・エンティティへ、次いで、移動圧縮装置へ送信する。さらに、このフィードバック情報に基づいて、第２のネットワーク・エンティティは上記格納された解凍用コンテキスト情報の更新を行う。上記解凍用コンテキスト情報の格納に応じて、上記第２のネットワーク・エンティティは上記移動圧縮装置から受信したパケット内の少なくとも１つの圧縮ヘッダの解凍も行い、解凍された少なくとも１つのヘッダを上記第１のネットワーク・エンティティへ送信する。

本発明の第１の実施態様では、リロケーションは無線ハンド・オフと同時に行われる。第１のネットワーク・エンティティから第２のネットワーク・エンティティへのコンテキスト情報の転送は無線ハンド・オフ前及び／又は無線ハンド・オフ中に行われる。ダウンリンク・トラフィックの場合、第１のネットワーク・エンティティは、リロケーション時に使用する圧縮用コンテキスト情報のスナップ・ショットを撮る。第１のネットワークは、このスナップ・ショット圧縮用コンテキスト情報を第２のネットワーク・エンティティへ送信する。第２のネットワーク・エンティティは、このエンティティから上記１つの移動端末装置へ送信されたパケットのヘッダ圧縮に利用する圧縮用コンテキスト情報として、この受信された圧縮用コンテキスト情報を格納する。第１のネットワーク・エンティティから第２のネットワーク・エンティティへの圧縮用コンテキスト情報の送信には、圧縮されたヘッダ情報と共に第２のネットワーク・エンティティによって移動解凍装置へ送信される圧縮用コンテキストの識別子が含まれてもよい。次いで、格納されたコンテキスト情報を利用して圧縮ヘッダを持つ少なくとも１つの受信パケットの解凍に利用する解凍用コンテキスト情報を決定するために、上記１つの移動解凍装置は上記識別子を利用する。アップリンク・トラフィックの場合、第１のネットワーク・エンティティは、上記１つの移動圧縮装置から第２のネットワーク・エンティティへ送信された圧縮ヘッダを持つパケットを解凍するために第２のネットワーク・エンティティが利用する解凍用コンテキスト情報を選択する。この選択された解凍用コンテキスト情報は第１のネットワーク・エンティティから第２のネットワーク・エンティティへ送信され、この第２のネットワーク・エンティティによって上記解凍用コンテキスト情報が格納され上記１つの移動端末装置から受信したパケットのヘッダの解凍が行われる。ハンドオフ・コマンドが第１のネットワーク・エンティティから上記移動圧縮装置へ送信されるが、このハンドオフ・コマンドは解凍用コンテキスト識別子を持つものであってもよい。上記１つの移動圧縮装置からの圧縮ヘッダを持つ少なくとも１つのパケットが第２のネットワーク・エンティティへ送信され、第２のネットワーク・エンティティは上記格納された解凍用コンテキスト情報を利用して、移動圧縮装置から受信した圧縮ヘッダを持つ少なくとも１つの受信パケットの解凍を行う。

本発明は、関連する圧縮または解凍用コンテキスト情報を取得し、新しい第２のネットワーク・エンティティへこの情報を送信する古い第１のネットワーク・エンティティをベースとするものである。移動圧縮装置と移動解凍装置の範囲内で圧縮用コンテキスト情報の転送を行う必要はない。リロケーションが無線ハンド・オフと同時に行われるこれらの実施態様では、移動圧縮装置または移動解凍装置に対してハンド・オフが通知される（該装置が第２のネットワーク・エンティティとの交信を開始したとき）。

ダウンリンク・トラフィックについての第１の実施態様では、第１のネットワーク・エンティティは、解凍用コンテキスト情報のスナップ・ショットから得た圧縮用コンテキスト情報を第２のネットワーク・エンティティへ送信する。上記スナップ・ショット時に、スナップ・ショットで撮られた移動解凍装置における解凍用コンテキスト情報は、通常圧縮用コンテキスト情報と同期している。しかし、第２のネットワーク・エンティティがその圧縮用コンテキスト情報を利用し始めるまでには、移動機におけるスナップ・ショットの解凍用コンテキストがもはやスナップ・ショットの圧縮用コンテキスト情報と同期してない可能性がある。というのは、圧縮用コンテキストがその間に展開している可能性があるからである。したがって、スナップ・ショット時に、ネットワーク・エンティティは移動解凍装置とのハンドシェイクを行って、移動解凍装置が圧縮用コンテキスト情報と同期している上記解凍用コンテキスト情報の格納を保証することも可能である。ハンド・オフの直後に、上記第２のエンティティは第１のネットワーク・エンティティから受信した圧縮用コンテキスト情報を利用し、移動解凍装置はスナップ・ショット解凍用コンテキスト情報を利用する。

アップリンク・トラフィックの場合、第１のネットワーク・エンティティは、現時点での解凍用コンテキスト情報のスナップ・ショットをとり、移動圧縮装置へそのコンテキスト識別子を送信する。移動圧縮装置は、対応する同期中の圧縮用コンテキスト情報を導き出し、この情報を格納し、次いで、肯定応答を返送する。

第１のネットワーク・エンティティは第２のネットワーク・エンティティへ上記スナップ・ショット解凍用コンテキスト情報を送る。ハンド・オフの直後に、上記第２のネットワーク・エンティティは第１のネットワーク・エンティティから受信した解凍用コンテキスト情報を利用し、上記移動圧縮装置は格納された圧縮用コンテキスト情報を利用する。

上記アプローチのすべての利点として、最適の圧縮／解凍オペレーションを行うために、圧縮装置と解凍装置が無線ハンド・オフの前後に該装置のコンテキスト情報の更新を行うことが可能になるという利点が挙げられる。そうであったとしても、スナップ・ショットが撮られたこれらのコンテキストは、スナップ・ショットの圧縮及び解凍用コンテキスト情報が同期しているため後程で使用することも可能である。

移動圧縮装置と移動解凍装置によるコンテキスト圧縮情報とコンテキスト解凍情報の交換は、数値順索引などの圧縮技術により非常に効率的に行うことも可能である。

圧縮ヘッダを持つパケットの送信を行うパケット・ネットワークにおける本発明の通信方法には、上記パケットのヘッダの圧縮と解凍に利用されるコンテキスト情報を上記第１のノードと上記第２のノードに格納することを含む、第１のネットワーク・ノードと第２のネットワーク・ノードとの間の接続を確立するステップと、上記第１のネットワーク・ノードと上記第２のネットワーク・ノードとの間の接続を、上記第２のネットワーク・ノードと第３のネットワーク・ノードとの間の接続へ変更するステップであって、上記第１のノードにより格納され、次いで、上記第３のノードのコンテキスト情報として上記第３のノードにより格納されるコンテキスト情報を表すコンテキスト情報を上記第３のネットワーク・ノードへ転送し、上記第２及び第３のノードでパケットのヘッダの圧縮と解凍を行うために、上記第２のノードと上記第３のノードにおいて上記格納されたコンテキスト情報を利用することを含むステップと、が含まれる。上記格納されたコンテキスト情報は、第１及び第２のオーダーの圧縮ヘッダの圧縮と解凍のために利用してもよい。上記格納されたコンテキスト情報は、上記パケットのヘッダの圧縮に利用する少なくとも１つのタイプの情報と、上記パケットのヘッダの解凍に利用する少なくとも１つのタイプの情報とを含むものであってもよい。上記第３のネットワーク・ノードは、上記第２のノードである移動解凍装置へのダウンリンク・トラフィック時にパケットの送信機であるネットワーク・エンティティであってもよく、上記ダウンリンク・トラフィック時に送信する上記パケットのヘッダの圧縮を行って、上記第３のノードにより上記格納されたコンテキスト情報を利用してもよい。上記第２のノードは、ネットワーク・エンティティである上記第３のノードへのアップリンク・トラフィックのパケットの送信機である移動圧縮装置であってもよく、上記格納されたコンテキスト情報は、上記アップリンク時に上記パケットのヘッダの圧縮を行うために上記移動圧縮装置により利用されてもよい。上記第３のネットワーク・ノードは、移動圧縮装置である上記第２のノードからのアップリンク・トラフィック時にパケットの受信機であるネットワーク・エンティティであってもよく、上記格納されたコンテキスト情報を上記第３のネットワーク・ノードにより利用して、上記アップリンク・トラフィック時に送信される上記パケットのヘッダの解凍を行ってもよい。上記第２のノードは、ネットワーク・エンティティである上記第３のノードからのダウンリンク・トラフィック時にパケットの受信機である移動解凍装置であってもよく、上記格納されたコンテキスト情報を上記移動解凍装置により利用して、上記ダウンリンク・トラフィック時に送信されるパケットの解凍を行ってもよい。上記第２のノードは、上記第３のノードへ送信されるパケットのヘッダを圧縮するために利用されるコンテキスト情報を格納することができ、上記第３のノードにより格納される上記コンテキスト情報は、上記第２のノードにより格納された上記コンテキスト情報から導き出すことができる。上記第３のノードにより格納される上記コンテキスト情報は、上記第２のノードにより格納された上記コンテキスト情報と同一であってもよい。上記第１のネットワーク・ノードは、上記第２のノードである移動解凍装置へのダウンリンク・トラフィック時のパケットの送信機であるネットワーク・エンティティであってもよく、上記格納されたコンテキスト情報は、上記ダウンリンク時に送信される上記パケットのヘッダの圧縮を行うために、上記第３のノードにより利用され上記格納されたコンテキスト情報を上記第１のノードにより利用して、上記ダウンリンク・トラフィック時に送信する上記パケットのヘッダの圧縮を行ってもよい。上記第１のネットワーク・ノードの格納されたコンテキスト情報は、第１または第２の圧縮度まで上記パケットのヘッダを圧縮するために接続の変更に先行して利用される情報であってもよい。上記第２のノードは、ネットワーク・エンティティである上記第１のノードへのアップリンク・トラフィック時に上記接続の変更に先行してパケットの送信機である移動圧縮装置であってもよく、上記格納されたコンテキスト情報を上記移動圧縮装置により利用して、上記アップリンク・トラフィック時に上記パケットのヘッダの圧縮を行ってもよい。上記移動圧縮装置の格納されたコンテキスト情報は、第１または第２の圧縮度まで上記パケットのヘッダを圧縮するために利用される情報であってもよい。上記第１のノードから上記第３のノードへ送信される上記コンテキスト情報は、時間関連のコンテキスト情報構成部を有するものであってもよく、時間に関連する上記コンテキスト情報構成部は、少なくとも１つの前回のパケットのタイム・スタンプと到着時のうちの少なくとも一方に関連する要素を含むものであってもよく、現時点のタイマ値であってもよく、さらに、現時点のタイマ値から構成されるものであってもよい。

１つの移動解凍装置が第１のネットワーク・エンティティから第２のネットワーク・エンティティへハンド・オフされるとき、複数のネットワーク・エンティティの中の１つから複数の移動解凍装置の中の１つへのダウンリンク・トラフィックで送信されるパケットのヘッダの圧縮を行うために利用されるコンテキスト情報を転送する本発明による方法には、移動解凍装置が、上記第１のネットワーク・エンティティから上記１つの移動解凍装置へ送信されるパケットの圧縮を行うために利用されるコンテキスト情報であって、上記第２のネットワーク・エンティティへハンド・オフされる時点のコンテキスト情報を上記第１のネットワーク・エンティティに格納するステップと、上記格納されたコンテキスト情報から上記第１のネットワーク・エンティティを上記１つの移動解凍装置へ送信する、あるいは、上記１つの移動端末装置の上記格納されたコンテキスト情報を得るために、上記１つの移動解凍装置によって利用される、上記第１のネットワーク・エンティティに格納された上記コンテキスト情報を表す情報を上記１つの移動端末装置へ送信するステップと、上記格納されたコンテキスト情報、または、上記コンテキスト情報を表す情報を上記１つの移動解凍装置によって受信した旨のフィードバック情報情報を上記１つの移動解凍装置から上記第１のネットワーク・エンティティへ送信するステップと、上記フィードバック情報の受信に応答して、上記第１のネットワーク・エンティティから、上記受信したコンテキスト情報を格納する上記第２のネットワーク・エンティティへ上記コンテキスト情報を送信するステップとが含まれる。上記第２のネットワーク・エンティティは、上記格納されたコンテキスト情報を利用して、上記１つの移動解凍装置へ送信されるパケットのヘッダの圧縮を行ってもよい。上記パケットのヘッダの圧縮を行うために上記第２のネットワーク・エンティティにより利用される上記格納されたコンテキスト情報は、上記ヘッダの第１または第２のオーダーの圧縮を示すことができる。上記１つの移動解凍装置は上記第２のネットワーク・エンティティから送信された上記圧縮パケットのヘッダを解凍することができる。上記第２のネットワーク・エンティティから送信された上記パケットのヘッダの解凍に利用される上記格納されたコンテキスト情報は、第１または第２のオーダー圧縮を持つヘッダの解凍を与えることができる。上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ送信される上記コンテキスト情報は、時間関連のコンテキスト情報構成部を有するものであってもよく、時間に関連する上記コンテキスト情報構成部は、少なくとも１つの前回のパケットのタイム・スタンプと到着時のうちの少なくとも一方に関連する要素を含むものであってもよく、現時点のタイマ値であってもよく、さらに、現時点のタイマ値から構成されるものであってもよい。

１つの移動圧縮装置が、第１のネットワーク・エンティティから第２のネットワーク・エンティティへハンド・オフされるとき、複数の移動圧縮装置の中の１つから複数のネットワーク・エンティティの中の１つへアップリンク・トラフィック時に送信されたパケットのヘッダの圧縮に利用するコンテキスト情報を転送する本発明による方法には、上記１つの移動圧縮装置が、上記１つの移動圧縮装置から上記第１のネットワーク・エンティティへ送信される上記パケットのヘッダの圧縮時に上記１つの移動圧縮装置により利用されるコンテキスト情報の格納を求める旨のリクエストを上記１つの移動圧縮装置へ送信するステップと、上記リクエストに応じて、上記１つの移動圧縮装置に上記コンテキスト情報を格納し、上記格納されたコンテキスト情報または上記格納されたコンテキスト情報を表す情報を上記第１のネットワーク・エンティティへ送信するステップと、上記１つの移動圧縮装置から受信した上記コンテキスト情報から、あるいは、上記１つの移動圧縮装置から受信した上記格納されたコンテキスト情報を表す情報から、上記第１のネットワーク・エンティティにおいて解凍用コンテキスト情報を導き出し、上記解凍用コンテキスト情報を格納する上記第２のネットワーク・エンティティへ上記解凍用コンテキスト情報を送信するステップと、上記１つの移動圧縮装置から受信した上記コンテキスト情報から、あるいは、上記１つの移動圧縮装置から受信した上記格納されたコンテキスト情報を表す情報から、上記第１のネットワーク・エンティティにおいて解凍用コンテキスト情報を導き出し、上記解凍用コンテキスト情報を格納する上記第２のネットワーク・エンティティへ上記解凍用コンテキスト情報を送信するステップと、が含まれる。上記方法には、上記１つの移動圧縮装置から受信した上記コンテキスト情報から、あるいは、上記１つの移動圧縮装置から受信した上記格納されたコンテキスト情報を表す情報から、上記第１のネットワーク・エンティティにおいて解凍用コンテキスト情報を導き出し、上記解凍用コンテキスト情報を格納する上記第２のネットワーク・エンティティへ上記解凍用コンテキスト情報を送信するステップと、上記第２のネットワーク・エンティティへ送信されたデータ・パケットのヘッダを圧縮するために、上記格納された圧縮用コンテキスト情報を上記１つの移動圧縮装置において利用するステップと、がさらに含まれる。上記第１のネットワーク・エンティティは、上記第２のネットワーク・エンティティへの解凍用コンテキスト情報の送信前に、上記第１のネットワーク・エンティティの解凍用コンテキスト情報のフィードバック情報を上記１つの移動圧縮装置へ送信することができる。上記フィードバック情報を上記リクエストと共に上記１つの移動圧縮装置へ送信してもよい。上記パケットのヘッダを圧縮するために上記１つの移動圧縮装置により利用される上記格納された圧縮用コンテキスト情報は、上記ヘッダの第１または第２のオーダーの圧縮を与えることができる。ハンド・オフ後、上記１つの移動圧縮装置は、上記第２のネットワーク・エンティティへ送信されたデータ・パケットのヘッダを圧縮することができ、上記第２のネットワーク・エンティティは、上記格納された解凍用コンテキスト情報を利用して、上記１つの移動圧縮装置から受信した上記データ・パケットのヘッダを解凍することができる。上記コンテキスト情報を表す情報は数値順索引を含むものであってもよく、また、１つのパケットのシーケンス番号であってもよい。上記第１のネットワーク・エンティティは、上記第１のネットワーク・エンティティにコンテキスト情報の格納を求める旨の上記リクエストと関連して上記第１のネットワーク・エンティティが受信したパケットの受信を示すフィードバック情報を上記１つの移動圧縮装置へ送信することができる。上記１つの移動圧縮装置の上記格納されたコンテキスト情報は、上記フィードバック情報を考慮して更新することができる。さらに、上記更新されたコンテキスト情報、または、上記第１のネットワーク・エンティティが上記コンテキスト情報を得るために利用する最後の受信パケットのコンテキスト情報を表す情報を上記第２のネットワーク・エンティティへ送信することができる。上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ送信される上記解凍用コンテキスト情報は、時間関連のコンテキスト情報構成部を有するものであってもよく、時間に関連する上記コンテキスト情報構成部は、少なくとも１つの前回のパケットのタイム・スタンプと到着時のうちの少なくとも一方に関連する要素を含むものであってもよく、現時点のタイマ値であってもよく、さらに、現時点のタイマ値から構成されるものであってもよい。

圧縮されたヘッダを有するパケット送信の本発明による方法には、パケット・ネットワークの第１のノードに格納された圧縮用コンテキスト情報を用いて圧縮された圧縮ヘッダを持つ少なくとも１つのパケットと、上記圧縮用コンテキスト情報とを上記パケット・データ・ネットワークの第２のノードへ送信するステップと、上記第２のノードに上記圧縮用コンテキスト情報を格納するステップと、上記パケット・ネットワークにおいて上記第２のノードから第３のノードへ圧縮ヘッダを持つ上記少なくとも１つのパケットを送信するステップと、が含まれる。上記第２のノードは、上記第２のノードが上記圧縮用コンテキスト情報を受信した旨の通知を上記第１のノードへ送信する。上記方法には、圧縮ヘッダを持つ上記少なくとも１つのパケットの送信後、上記第１のノードが、上記第１のノードに格納された上記圧縮用コンテキスト情報を用いて圧縮された圧縮ヘッダを持つ上記少なくとも１つの追加パケットであって、各々が、圧縮されていない対応するヘッダと対を成す追加パケットを上記第２のノードへ送信するステップと、圧縮ヘッダを持つ少なくとも１つの新しいパケットを形成するために、上記第２のノードに格納された上記圧縮用コンテキスト情報を利用して、上記第２のノードにおいて圧縮されていない上記少なくとも１つの対応するヘッダを圧縮するステップと、上記第２のノードに格納された上記圧縮用コンテキストから形成される圧縮ヘッダを持つ上記少なくとも１つの新しいパケットを上記第２のノードから上記第３のノードへ送信するステップと、をさらに含むものであってもよい。上記第１のノードが上記通知を受信後、上記第１のノードは、上記第１のノードに格納された上記圧縮用コンテキスト情報により圧縮されたヘッダの転送を停止することができる。上記第１のノードは、上記第１のノードに格納された上記圧縮用コンテキスト情報により圧縮されたヘッダの送信を停止した後、上記第１のノードは少なくとも１つの未圧縮ヘッダを上記第２のノードへ送信することができ、上記第２のノードは、上記第１のノードから受信した上記少なくとも１つの未圧縮ヘッダを上記第２のノードに格納された上記圧縮用コンテキスト情報を用いて圧縮することができ、上記第２のノードは、上記第２のノードにおいて圧縮された上記少なくとも１つのヘッダを上記第３のノードへ送信することができる。上記方法は、上記第１のノードが、上記第１のノードに格納された上記コンテキスト情報により圧縮されたヘッダの転送を停止した後、未圧縮ヘッダを持つ少なくとも１つの追加パケットが、上記第１のノード以外のソースから上記第２のノードにより受信されるステップと、上記第２のノードが、上記第１のノード以外のソースから上記第２のノードにより受信される、未圧縮ヘッダを持つ上記少なくとも１つの追加パケットを上記第２のノードに格納された上記圧縮用コンテキスト情報を用いて圧縮し、圧縮されたヘッダを持つ新しい少なくとも１つの追加パケットを形成するステップと、上記第２のノードが、圧縮されたヘッダを持つ上記新しい少なくとも１つの追加パケットを上記第３のノードへ送信するステップと、を含むことも可能である。上記第１のノードと第２のノードが上記パケット・ネットワーク内のネットワーク・エンティティであってもよく、上記第３のノードが移動端末装置であってもよい。上記第１のノードに格納された上記圧縮用コンテキスト情報を用いて圧縮された圧縮ヘッダを持つ上記少なくとも１つのパケットを送信する前に上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへの無線ハンド・オフを行うことができる。上記圧縮用コンテキスト情報は、上記第１のノードに格納された上記圧縮用コンテキスト情報を用いて圧縮された圧縮ヘッダを持つ少なくとも１つのパケットの送信の一部として送信することができる。上記第２のノードは、上記第１のノードに格納された上記圧縮用コンテキスト情報を用いて圧縮された圧縮ヘッダと、圧縮されていない対応するヘッダとを持つ上記少なくとも１つの追加パケットの受信前に、上記圧縮用コンテキスト情報を上記第２のノードにより受信してもよい。上記第２のノードにより格納された上記圧縮用コンテキスト情報をフィードバック情報に基づいて更新するフィードバック情報が上記第３のノードから上記第２のノードへ送信される。上記圧縮されたヘッダは第１または第２のオーダー圧縮を持つヘッダであってもよい。上記圧縮用コンテキスト情報は、上記圧縮用コンテキスト情報がどの圧縮されたヘッダに基づいているかを示す識別子によってマークしてもよい。また、上記第２のネットワーク・エンティティは、上記圧縮用コンテキスト情報が依拠するパケットを特定するために上記識別子を利用してもよい。上記第２のノードは、上記第３のノードで受信したヘッダの解凍に利用される解凍用コンテキスト情報のフィードバック情報を第３のノードから受信してもよい。上記フィードバック情報が上記圧縮用コンテキスト情報の前に上記第２のノードにより受信されたとき、上記フィードバック情報は、上記第１のノードと第２のノードとの間の送信遅延時刻よりも古くなく、かつ、上記識別子により特定されるパケットよりも新しい場合にのみ、上記第２のノードに格納された上記圧縮用コンテキスト情報を更新するために上記フィードバック情報を利用してもよい。上記第１のノードから上記第３のノードへ送信される上記コンテキスト情報は時間関連のコンテキスト情報構成部を含むものであってもよく、また、上記時間関連のコンテキスト情報構成部は少なくとも１つの前回のパケットのタイム・スタンプと到着時に関連する要素を含むものであってもよく、また、現時点のタイマ値であってもよく、現時点のタイマ値から構成されるものであってもよい。

圧縮されたヘッダを有するパケット送信の本発明による方法には、パケット・ネットワークの第１のノードから上記パケット・ネットワーク内の第２のノードへ、圧縮ヘッダを持つ少なくとも１つのパケットを送信するステップと、圧縮ヘッダを持つ上記少なくとも１つのパケットの解凍を行うために、上記第３のノードが利用する解凍用コンテキスト情報を格納する圧縮ヘッダを持つ上記少なくとも１つのパケットを上記パケット・ネットワークの上記第２のノードから第３のノードへ送信するステップと、上記第３のノードに圧縮ヘッダを持つ上記少なくとも１つのパケットの受信に応答して、圧縮ヘッダを持つ上記少なくとも１つのパケットの解凍を行うために、上記第３のノードが利用する解凍用コンテキスト情報を上記第２のノードへ送信するステップと、が含まれる。圧縮ヘッダを持つ上記少なくとも１つのパケットの送信後、上記第１のノードは、少なくとも１つの追加パケットを送信することができる。上記第２のノードは、圧縮ヘッダを持つ少なくとも１つのパケットの少なくとも１つを上記第３のノードへ送信するものであってもよい。上記第２のノードは、上記第２のノードにより受信された圧縮ヘッダを持つ上記少なくとも１つの追加パケットの少なくとも１つを上記格納された解凍用コンテキスト情報を用いて解凍するものであってもよく、上記第２のノードは、上記解凍された少なくとも１つのパケットを上記第３のノードへ送信するものであってもよい。解凍用コンテキスト情報の格納後に上記第２のノードによって受信される上記少なくとも追加のパケットのすべては、上記格納された解凍用コンテキスト情報を用いて上記第２のノードで解凍され、上記第３のノードへ送信されるものであってもよい。上記第２のノードは、上記第２のノードが上記解凍用コンテキスト情報を格納した旨のフィードバック情報を上記第３のノードへ送信するものであってもよい。上記フィードバック情報に応じて、上記第３のノードは、上記第２のノードから受信した圧縮ヘッダの解凍を停止するものであってもよい。上記方法は、上記第２のノードにおいて圧縮ヘッダを持つ上記少なくとも１つのパケットを受信する上記第３のノードに応じて、上記第３のノードは、圧縮ヘッダを持つ上記少なくとも１つの追加パケットの解凍を行う上記第３のノードに基づいて追加の解凍用コンテキスト情報を送信するステップをさらに含むものであってもよい。また、上記第２のノードは、上記受信された、追加の解凍用コンテキスト情報に基づいて上記格納された解凍用コンテキスト情報を更新し、上記第１のノードから受信した圧縮ヘッダを持つ少なくとも１つの後続して受信されるパケットを上記更新された格納された解凍用コンテキスト情報を用いて解凍する。上記第１のノードは移動端末装置であってもよく、上記第２と第３のノードはネットワーク・エンティティであってもよい。上記少なくとも１つのパケットの上記圧縮されたヘッダは第１のまたは第２のオーダーの圧縮ヘッダを含むものであってもよい。上記第３のノードから上記第２のノードへ送信される上記解凍用コンテキスト情報は、時間関連のコンテキスト情報構成部を有するものであってもよく、時間に関連する上記コンテキスト情報構成部は、少なくとも１つの前回のパケットのタイム・スタンプと到着時のうちの少なくとも一方に関連する要素を含むものであってもよく、現時点のタイマ値であってもよく、さらに、現時点のタイマ値から構成されるものであってもよい。

１つの移動解凍装置が、第１のネットワーク・エンティティから第２のネットワーク・エンティティへハンド・オフされるとき、複数のネットワーク・エンティティの中の１つから複数の移動解凍装置の中の１つへのダウンリンク・トラフィックで送信されるデータ・パケットのヘッダの圧縮を行うために利用されるコンテキスト情報を転送する方法には、上記第１のネットワーク・エンティティから上記１つの移動解凍装置へ送信されるパケットのヘッダを圧縮するために、上記移動解凍装置が上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへハンド・オフされる時点に利用される圧縮用コンテキスト情報を上記第１のネットワーク・エンティティに格納するステップと、上記格納された圧縮用コンテキスト情報と、上記第２のネットワーク・エンティティにより格納された圧縮用コンテキスト情報の識別子を上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ送信するステップであって、上記第２のネットワーク・エンティティから上記１つの移動解凍装置へ送信されるパケットのヘッダを圧縮するために、上記第２のネットワーク・エンティティにより格納された上記圧縮用コンテキスト情報が利用されるステップと、上記第２のネットワーク・エンティティから上記１つの移動解凍装置へ、上記第２のネットワーク・エンティティに格納された上記圧縮用コンテキスト情報を用いて圧縮ヘッダを持つ少なくとも１つのパケットを送信するステップであって、上記圧縮用コンテキスト情報の識別子が、上記格納された圧縮用コンテキスト情報を用いて圧縮されたヘッダを持つ上記少なくとも１つのパケットを圧縮するために利用されるステップと、解凍用コンテキスト情報を得るために上記１つの移動解凍装置において上記識別子を利用し、さらに、上記第２のネットワーク・エンティティに格納された上記格納された圧縮用コンテキスト情報を用いて圧縮ヘッダを持つ上記少なくとも１つのパケットの解凍を行うために上記格納された解凍用コンテキスト情報を利用するステップとが含まれる。上記圧縮されたヘッダは、第１のオーダーまたは第２のオーダーの圧縮ヘッダを含むものであってもよい。上記第１のネットワーク・エンティティによる上記圧縮用コンテキスト情報の格納後、及び、上記第２のネットワーク・エンティティが上記圧縮用コンテキスト情報を格納した後、上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへの上記１つの移動解凍装置の無線ハンド・オフが行われる。上記第２のネットワーク・エンティティから上記１つの移動解凍装置への送信の同期を保持するために、上記圧縮用コンテキスト情報を用いて圧縮されたヘッダと上記圧縮用コンテキスト情報の複数の識別子とを持つ複数のパケットが上記第２のネットワーク・エンティティから上記１つの移動解凍装置へ送信されてもよい。上記圧縮用コンテキスト情報の上記複数の識別子の送信後、上記第２のネットワーク・エンティティは、任意のコンテキスト識別子の上記送信を停止し、上記圧縮用コンテキスト情報識別子を用いて圧縮されたヘッダの転送を継続してもよい。圧縮用コンテキスト情報の少なくとも１つの識別子の受信に応答する上記移動解凍装置は、上記第２のネットワーク・エンティティへ少なくとも１つのフィードバック情報を送信してもよい。また、少なくとも１つのフィードバック情報の受信に応答する上記第２のネットワーク・エンティティは、任意の識別子を停止し、上記圧縮用コンテキスト情報を用いて圧縮されたヘッダの転送を継続してもよい。上記少なくとも１つのフィードバック情報が上記１つの移動解凍装置から上記新しいネットワーク・エンティティへ送信される少なくとも１つの肯定応答パケットを含むものであってもよい。上記第２のネットワーク・エンティティは、上記肯定応答パケットの受信に応答して、上記格納された圧縮用コンテキスト情報を更新してもよい。上記識別子はシーケンス番号であってもよく、また、このシーケンス番号は、上記第２のネットワーク・エンティティにより格納された上記圧縮用コンテキスト情報を最後に更新したパケットの識別番号であってもよい。上記第２のネットワーク・エンティティに格納された上記圧縮用コンテキスト情報を用いて圧縮ヘッダを持つ上記少なくとも１つのパケットは、上記第１のネットワーク・エンティティから受信した未圧縮のパケット・ヘッダを持つ少なくとも１つのパケットから形成されたものであってもよい、あるいは、上記第１のネットワーク・エンティティ以外のソースから受信した未圧縮のヘッダを持つ少なくとも１つのパケットから形成されたものであってもよい。上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ送信される上記コンテキスト情報は、時間関連のコンテキスト情報構成部を有するものであってもよく、時間に関連する上記コンテキスト情報構成部は、少なくとも１つの前回のパケットのタイム・スタンプと到着時のうちの少なくとも一方に関連する要素を含むものであってもよく、現時点のタイマ値であってもよく、さらに、現時点のタイマ値から構成されるものであってもよい。

１つの移動圧縮装置が、第１のネットワーク・エンティティから第２のネットワーク・エンティティへハンド・オフされるとき、複数の移動圧縮装置の中の１つから複数のネットワーク・エンティティの中の１つへアップリンクで送信されるデータ・パケットのヘッダの圧縮を行うために利用されるコンテキスト情報を転送する方法には、上記１つの移動圧縮装置から上記第２のネットワーク・エンティティへ送信された圧縮ヘッダを持つデータ・パケットを解凍するために、上記第２のネットワーク・エンティティにより利用される、上記第１のネットワーク・エンティティに解凍用コンテキスト情報を格納するステップと、上記１つの移動圧縮装置から受信したパケットのヘッダの解凍を行うために上記解凍用コンテキスト情報を格納する上記第２のネットワーク・エンティティへ上記解凍用コンテキスト情報を送信するステップと、上記第１のネットワーク・エンティティから上記１つの移動圧縮装置へ上記第２のネットワーク・エンティティにより利用される上記解凍用コンテキスト情報を特定するための解凍用コンテキスト識別子を送信するステップと、上記コンテキスト識別子の受信に応答して、上記１つの移動端末装置が、上記１つの移動圧縮装置から上記第２のネットワーク・エンティティへ送信されるパケットのヘッダの圧縮を行うために利用される圧縮用コンテキスト情報を導き出すステップと、上記１つの移動圧縮装置は、圧縮ヘッダを持つ少なくとも１つのパケットを上記第２のネットワーク・エンティティへ送信するステップと、上記第２のネットワーク・エンティティは、圧縮ヘッダを持つ少なくとも１つの受信パケットを解凍するために上記格納された解凍用コンテキスト情報を利用するステップと、が含まれる。上記識別子はシーケンス番号であってもよいし、上記シーケンス番号は、上記第２のネットワーク・エンティティにより格納された上記解凍用コンテキスト情報を最後に更新したパケットの識別番号であってもよいし、あるいは、上記１つの移動圧縮装置から、上記第２のネットワーク・エンティティにより格納された上記解凍用コンテキスト情報を最後に更新した上記第２のネットワーク・エンティティへのフィードバック情報の識別子であってもよい。上記圧縮されたヘッダは、第１のオーダーまたは第２のオーダーの圧縮ヘッダを含むものであってもよい。上記第２のネットワーク・エンティティへの上記１つの移動圧縮装置の転送を引き起こす上記第１のネットワーク・エンティティでの上記解凍用コンテキスト情報の格納後、上記第１のネットワーク・エンティティから上記１つの移動圧縮装置へハンドオフ・コマンドが送信されるものであってもよい。上記ハンドオフ・コマンドは、上記１つの移動圧縮装置へ上記解凍用コンテキスト識別子を用いて送信されるものであってもよい。

第１のネットワーク・エンティティから第２のネットワーク・エンティティへの解凍機能のリロケーションの前に、複数の移動圧縮装置の中の１つから複数のネットワーク・エンティティの中の１つへアップリンクで送信されるパケットのヘッダの解凍に利用される時間関連のコンテキスト情報構成部を含むコンテキスト情報を転送する本発明による方法には、第２のネットワーク・エンティティを介して上記１つの移動圧縮装置から上記第１のネットワーク・エンティティへ少なくとも１つの圧縮ヘッダを送信するステップと、パケットの受信時刻を格納する上記第２のネットワーク・エンティティにおいてタイマを始動させるステップと、上記第１のネットワーク・エンティティにおいて上記少なくとも１つの圧縮ヘッダを解凍するステップと、上記第１のネットワーク・エンティティにおける上記少なくとも１つの圧縮ヘッダの解凍後、上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ上記時間関連の解凍用コンテキスト情報構成部の一部分を送信するステップと、上記第２のネットワーク・エンティティにおける上記時間関連の解凍用コンテキスト情報構成部の上記部分を格納するステップと、上記１つの移動圧縮装置から受信された圧縮ヘッダを持つ少なくとも１つの追加パケットの受信時刻を格納し、上記少なくとも１つの追加パケットを解凍し、上記時間関連の解凍用コンテキスト情報構成部の別の部分を取得する上記第１のネットワーク・エンティティへ上記少なくとも１つの追加パケットを送信するステップと、上記第２のネットワーク・エンティティと関連する時刻である上記解凍用コンテキスト情報構成部の上記別の部分を送信するステップと、上記少なくとも１つの追加パケットの受信時刻、及び、上記時間関連の解凍用コンテキスト情報構成部の上記別の部分を格納後、上記第２のネットワーク・エンティティにおける完全な解凍用コンテキスト情報構成部を格納し、上記格納された、完全な解凍用コンテキスト情報構成部を利用して、上記第２のネットワーク・エンティティで受信された圧縮ヘッダを持つ少なくとも１つのパケットの解凍を行うステップと、が含まれる。上記部分は、ＴＳ０とＴ ｓｔｒｉｄｅを含む非時間変動時間関連情報を含むものであってもよい。上記別の部分は、少なくとも１つの追加パケットのタイム・スタンプまたは別の情報を含むものであってもよい。識別子は、少なくとも１つの圧縮ヘッダと共に送信されるものであってもよい。上記第１のネットワーク・エンティティはタイム・スタンプと共に識別子を返送するものであってもよい。また、上記第２のネットワーク・エンティティは、上記タイム・スタンプと関連する上記少なくとも１つの圧縮ヘッダのいずれかのヘッダを相関づけ、決定するために上記識別子を利用するものであってもよい。上記識別子はシーケンス番号であってもよい。

第１のネットワーク・エンティティから第２のネットワーク・エンティティへの圧縮機能のリロケーションの前に、複数のネットワーク・エンティティの中の１つから複数の移動解凍装置の中の１つへダウンリンクで送信されるパケットのヘッダの圧縮を行うために利用される時間関連のコンテキスト情報構成部を含むコンテキスト情報を転送する本発明による方法には、パケットの受信時刻を格納する上記第２のネットワーク・エンティティにおいてタイマを始動させるステップと、上記時間関連のコンテキスト情報構成部の一部分を含む圧縮ヘッダを持つ少なくとも１つのパケットを上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ送信するステップと、時間関連のコンテキスト情報構成部の時間関連構成要素の部分を上記第２のネットワーク・エンティティに格納するステップと、受信した圧縮ヘッダと対応する未圧縮ヘッダを持つ上記最少の１つの追加パケットの受信時刻とタイム・スタンプ、または、上記第１のネットワーク・エンティティからの上記対応する未圧縮ヘッダから得られる情報要素を上記第２のネットワーク・エンティティに格納するステップと、上記圧縮されたヘッダを含む少なくとも１つの追加パケットを上記１つの移動解凍装置へ送信し、上記１つの移動解凍装置で上記少なくとも１つの追加パケットの解凍を行うステップと、上記１つの移動解凍装置が、圧縮ヘッダを持つ上記少なくとも１つの追加パケットを解凍した旨のフィードバック情報を上記第２のネットワーク・エンティティへ送信するステップと、フィードバック情報の受信後、上記格納部分が上記時間関連のコンテキスト情報構成部として機能するのに十分であると判定し、上記時間関連のコンテキスト情報構成部として上記格納部分を利用して、上記１つの移動解凍装置へ送信される後続パケットの圧縮を上記第２のネットワーク・エンティティで開始するステップと、が含まれる。上記第２のネットワーク・エンティティが後続パケットの圧縮を開始する旨のフィードバック情報を上記第２のネットワーク・エンティティから上記第１のネットワーク・エンティティへ送信してもよい。さらに、上記第１のネットワーク・エンティティは、上記フィードバック情報に応じて、上記第２のネットワーク・エンティティへの、圧縮ヘッダを持つパケットの送信を停止してもよい。時間に関連する上記コンテキスト情報構成部の上記部分は非時間変動時間関連情報を含むものであってもよく、また、上記部分はＴＳ０とＴ ｓｔｒｉｄｅであってもよい。上記第２のネットワーク・エンティティへの上記フィードバック情報により、上記格納部分（少なくとも１つの追加パケットのタイム・スタンプ及び受信時刻）が上記時間関連のコンテキスト情報構成部として機能するのに十分であることを上記第２のネットワーク・エンティティが判定できるようにする。

第１のネットワーク・エンティティから第２のネットワーク・エンティティへの圧縮機能のリロケーションの前に、複数のネットワーク・エンティティの中の１つから複数の移動解凍装置の中の１つへダウンリンクで送信されるパケットのヘッダの圧縮を行うために利用される時間関連のコンテキスト情報構成部を含むコンテキスト情報を転送する本発明による方法には、パケットの受信時刻を格納する上記第２のネットワーク・エンティティにおいてタイマを始動させるステップと、上記時間関連のコンテキスト情報構成部の一部分を含む圧縮ヘッダを持つ少なくとも１つのパケットを上記第１のネットワーク・エンティティから上記第２のネットワーク・エンティティへ送信するステップと、時間関連のコンテキスト情報構成部の時間関連構成要素の部分を上記第２のネットワーク・エンティティに格納するステップと、上記第２のネットワーク・エンティティを介して、上記第１のネットワーク・エンティティから上記１つの移動解凍装置へ、圧縮ヘッダと、対応する未圧縮ヘッダとを持つ複数の追加パケットを送信するステップと、圧縮ヘッダと、対応する未圧縮ヘッダとを持つ上記第２のネットワーク・エンティティで上記複数の追加パケットを受信後、上記複数の追加パケットから得られる時間関連構成要素である圧縮用コンテキスト情報の第２の部分を上記第２のネットワーク・エンティティに格納するステップと、時間に関連する上記コンテキスト情報構成部の上記格納された第１及び第２の部分後、ヘッダの圧縮を行うために利用される完全な時間関連のコンテキスト情報構成部の取得及び上記第２のネットワーク・エンティティにおける上記構成要素の格納を行うステップと、上記第２のネットワーク・エンティティにおいて少なくとも１つの後続パケットを圧縮するために、時間に関連する完全なコンテキスト情報の上記格納された構成要素を利用し、上記圧縮された少なくとも１つの後続パケットを上記１つの移動解凍装置へ送信するステップと、が含まれる。上記第２の部分は上記複数の追加パケットのタイム・スタンプと受信時刻を含むものであってもよい。上記１つの移動圧縮装置で少なくとも１つの後続パケットを解凍してもよい。上記複数の追加ヘッダの数は、上記１つの移動解凍装置へ送信される上記複数の追加ヘッダの少なくとも１つが上記１つの移動解凍装置により受信される確率が十分高くなるように選択されるものであってもよい。

上記第３のエンティティが第１のエンティティから上記第２のエンティティへハンド・オフされた後、第２のエンティティから第３のエンティティへ送信されるパケットのヘッダを圧縮する本発明による方法には、第１の複数のパケットから導き出された元の圧縮用コンテキスト情報を上記第２のエンティティに格納するステップと、解凍用として上記第３のエンティティへ送信される新しい圧縮されたヘッダを上記第１の複数のヘッダに加えることにより、複数のヘッダから導き出された上記元の圧縮用コンテキスト情報を利用して、上記第２のエンティティにおいて、未圧縮ヘッダから追加の複数の圧縮ヘッダを形成するステップと、上記複数の追加の圧縮されたヘッダを送信後、上記第１の複数のヘッダ内の上記ヘッダを棄却し、圧縮されたヘッダとして上記第３のエンティティへ送信される、少なくとも１つの後続する未圧縮ヘッダを上記第２のエンティティにおいて圧縮するために、上記複数の追加の圧縮されたヘッダから導き出された圧縮用コンテキスト情報を利用するステップと、が含まれる。上記元の及び追加の複数の圧縮ヘッダは同一番号のパケットを含むものであってもよい。上記元の及び追加の複数の圧縮ヘッダが年齢（age）によって追跡することができ、上記元の複数の圧縮されたヘッダが棄却された後、上記追加の複数の圧縮ヘッダに各新しいヘッダを加え、次いで、上記追加の複数の圧縮ヘッダ内の最も古い圧縮されたヘッダを棄却することにより、各新しいヘッダの受信時に上記追加の複数の圧縮ヘッダを更新することもできる。上記第３のエンティティは、各受信された圧縮パケット内に含まれる識別子と同期する解凍用コンテキスト情報を用いて受信パケットのヘッダを解凍し、上記解凍されるヘッダから上記第３のエンティティにより格納された解凍用コンテキスト情報を更新することができる。上記圧縮用コンテキスト情報は時間関連情報を含むものであってもよい。上記時間関連情報は、タイム・スタンプ、パケットの送信時刻、ＴＳ０及びＴＳ ｓｔｒｉｄｅを含むものであってもよい。上記同一番号のパケットは、上記同一番号のパケットの送信に必要な或る時間間隔の間に、少なくとも１つのパケットが上記第３のエンティティにより受信される或る確率を持つように選択することができる。送信媒体は無線送信媒体であってもよい。上記第３のエンティティの解凍用コンテキスト情報は、上記第２のエンティティにより圧縮された圧縮ヘッダを含む第１の受信パケットを用いて更新されてもよい。

上記第３のエンティティが第１のエンティティから上記第２のエンティティへハンド・オフされた後、第１のエンティティから第２のエンティティへ送信されるパケットのヘッダを圧縮する本発明による方法には、第１の複数のパケットから導き出された元の圧縮用コンテキスト情報を上記第３のエンティティに格納するステップと、解凍用として上記第２のエンティティへ送信される新しい圧縮されたヘッダを上記第１の複数のヘッダに加えることにより、複数のヘッダから導き出された上記元の圧縮用コンテキスト情報を利用して、未圧縮ヘッダから追加の複数の圧縮ヘッダを上記第３のエンティティに形成するステップと、上記複数の追加の圧縮されたヘッダを送信後、上記第１の複数のヘッダ内の上記ヘッダを棄却し、圧縮されたヘッダとして上記第２のエンティティへ送信される、少なくとも１つの後続する未圧縮ヘッダを圧縮するために、上記第３のエンティティにおいて上記複数の追加の圧縮されたヘッダから導き出された圧縮用コンテキスト情報を利用するステップと、が含まれる。上記元の及び追加の複数の圧縮ヘッダは同一番号のパケットを含むものであってもよい。上記元の及び追加の複数の圧縮ヘッダが年齢（age）によって追跡することができ、上記元の複数の圧縮されたヘッダが棄却された後、上記追加の複数の圧縮ヘッダに各新しいヘッダを加え、次いで、上記追加の複数の圧縮ヘッダ内の最も古い圧縮されたヘッダを棄却することにより、各新しいヘッダの受信時に上記追加の複数の圧縮ヘッダを更新することもできる。上記第２のエンティティは、各受信された圧縮パケット内に含まれる識別子と同期する解凍用コンテキスト情報を用いて受信パケットのヘッダを解凍し、上記解凍されるヘッダから上記第２のエンティティにより格納された解凍用コンテキスト情報を更新することができる。上記圧縮用コンテキスト情報は時間関連情報を含むものであってもよい。上記時間関連情報は、タイム・スタンプ、パケットの送信時刻、ＴＳ０及びＴＳ ｓｔｒｉｄｅを含むものであってもよい。上記同一番号のパケットは、少なくとも１つのパケットが上記第２のエンティティにより受信される或る確率を持つように選択することができる。送信媒体は無線送信媒体であってもよい。上記第２のエンティティの解凍用コンテキスト情報は、上記第３のエンティティにより圧縮された圧縮ヘッダを含む第１の受信パケットを用いて更新されてもよい。

図２は、本発明の様々な実施態様の実施が可能な例示のシステムを例示する。しかし、本発明はこの例示システムに限定されるものではなく、その他のシステムのアーキテクチャも同様に本発明の実施に適用可能であると理解されたい。端末装置１０２はＩＰネットワーク１０８と接続されている。端末装置１０２は、限定なしでＲＴＰ／ＵＤＰ／ＩＰを実行し、ＩＰネットワーク１０８を介する送信用としてＲＴＰパケットでパケット化された音声サンプルを出力するパーソナル・コンピュータまたは同種のものであってもよい。端末装置１０２には、ＲＴＰパケットのソース及び／又は宛先として、この端末装置（ＩＰアドレス、ポート番号などを含む）を特定するＲＴＰエンドポイント１０４が含まれる。ＩＰネットワーク１０８はパケット・ネットワークの一例として提供されるものではあるが、別のタイプのパケット交換方式ネットワークあるいはその類のネットワークも代わりに適切に使用することが可能である。端末装置１０２には、タイム・スタンプを生成するためのローカル・タイマ１０３も含まれる。

アクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）１１０と１２０（これらは基地局サブシステム（ＢＳＳ）内に常駐していてもよい）はＩＰネットワーク１０８と接続される。ＡＮＩはネットワーク・エンティティでありかつネットワーク・ノードである。エンティティでありかつネットワーク・ノードであり、さらに、移動圧縮装置かつ移動解凍装置（２つの無線端末装置１３０と１５０が例示されている）として機能する複数の無線移動端末装置は無線周波数（ＲＦ）リンク１４０を介してＡＮＩ１１０と１２０と結合される。移動端末装置１３０及び／又は１５０のうちの一方が移動する場合、一方のＡＮＩとの無線接続範囲を越える移動の結果、端末装置が時折もう一方のＡＮＩへハンド・オフを行うことが必要になる。ヘッダの圧縮と解凍が利用され、ＡＮＩの中にヘッダの圧縮と解凍が配置されている場合、この処理は、例えば、移動端末装置１３０及び／又は１５０がＡＮＩ１１０からＡＮＩ１２０へ移動し、ハンド・オフが行われる場合などに、１つの（古い）ＡＮＩから別の（新しい）ＡＮＩへの圧縮及び解凍用コンテキスト情報の転送を行って、切れ目のない転送（seamlessness）を達成することも必要となる。この転送は、以下に解説するように、様々な時点で生じる可能性があるが、中断を最小限にするために、新しいＡＮＩが古いＡＮＩからヘッダ圧縮／解凍の役割を引き継ぐときまでに転送が完了していることが望ましい。新しいネットワーク・エンティティがある時点でこの役割を引き継いだときに、圧縮／解凍機能のリロケーションが生じる。一方、コンテキスト情報の転送は或る時間にわたって拡散する場合があり、リロケーションに先行する。例示されているように、ＲＦリンク１４０には、（移動端末装置１３０と１５０からＡＮＩ１１０への）アップリンク・トラフィック１４２と、（ＡＮＩ１１０から移動端末装置１３０と１５０への）ダウンリンク・トラフィック１４４とが含まれる。１以上の移動端末装置がＡＮＩ１２０などの別のＡＮＩへ移動した場合、ＡＮＩ１１０などの１つのＡＮＩから移動端末装置１３０及び／又は１５０のハンド・オフが行われる。各ＡＮＩは、（ＩＰネットワーク１０８から出力される）有線信号と（端末装置１３０と１５０から出力される）無線すなわちＲＦ信号との間の変換を含めて、ＩＰネットワーク１０８とつながる或る領域内の１以上の無線（すなわち高周波無線）端末装置（端末装置１３０を含む）とのインターフェースを行う。したがって、各ＡＮＩによって、ＲＦリンク１４０を介するＩＰネットワーク１０８から無線端末装置１３０と１５０のうちの少なくとも一方へ送受信されるＲＴＰパケット（但しこのパケットに限定されるものではない）などのパケット送信が可能になり、また、ＲＴＰパケット（但しこのパケットに限定されるものではない）などのパケット送信をＩＰネットワーク１０８によって端末装置１３０と１５０から端末装置１０２などの別の端末装置へ行うことが可能になる。

各ＡＮＩには複数のエンティティが含まれる。アーキテクチャ及びネットワークにおけるＡＮＩのすべてのオペレーションについての理解を容易にするために、ＡＮＩ１１０のさらに詳細な叙述と説明を行う。すべてのＡＮＩはＡＮＩ１１０と同じアーキテクチャであってもよいが、これらすべてのＡＮＩが同程度に詳細に例示されているわけではない。ＡＮＩ１１０には、ＡＮＩ ＡＤ１１２（詳細に例示されている）及びＡＮＩ_ＡＤ１１４などの１以上のＡＮＩアダプタ（ＡＮＩ ＡＤ）が含まれ、これらのＡＮＩアダプタの各々にはタイム・スタンプを出力するタイマ１１３が好適に含まれる。各ＡＮＩ ＡＤは（ダウンリンク・トラフィックに先行して）ヘッダ圧縮を行い、次いで（アップリンク・トラフィック後）解凍を行う。ＩＰネットワーク１０８から受信されたＲＴＰパケット用のヘッダ（タイム・スタンプとシーケンス番号などの１以上のヘッダ・フィールド）は、ダウンリンク・トラフィック１４２を介して端末装置１３０と１５０への送信に先行してＡＮＩ ＡＤ１１２により圧縮される。次いで、移動端末装置１３０と１５０から受信されたパケット・ヘッダは、ＩＰネットワーク１０８への送信前にＡＮＩ ＡＤ１１２により解凍される。ＡＮＩ ＡＤ１１０は、送信機／受信機（送受信装置）として、具体的には、送信に先行してデータ・パケットを圧縮する圧縮装置と、受信後データ・パケットを解凍する解凍装置とを備えた圧縮装置／解凍装置１１５として機能する。ＡＮＩ ＡＤ１１０は、ＩＰネットワーク１０８とつながる領域内の特定エリアまたは異なるエリアに配置される端末装置とのインターフェースを行う。ＡＮＩ ＡＤ１１２にはタイマ・ベースの解凍方法を実施するためのタイマ１１３が含まれる。ＡＮＩ ＡＤ１１２には、ネットワーク１０８を介して受信されるパケット（またはヘッダ）に関してジッタを測定し、過度のジッタを持ついずれのパケット／ヘッダも棄却するように動作するジッタ低減機能（ＪＲＦ）１１６も含まれる。

各端末装置には複数のエンティティが含まれる。類似の設計とオペレーションを持つネットワークにおけるすべての移動端末装置１３０と１５０の設計とオペレーションについての理解を容易にするために移動端末装置１３０についてのさらに詳細な説明を行う。移動端末装置の各々は、ＡＮＩの１１０と１２０を介する具体的には別のネットワークとの通信時に圧縮装置／解凍装置としても機能することができる。移動端末装置１３０には、ＲＴＰパケット用のソース（送信機）及び／又は宛先（受信機）端末装置のＩＰアドレス、ポート番号などを特定するＲＴＰエンドポイント１３２が含まれる。移動端末装置１３０には、（アップリンク・トラフィック１４２を介して送信を行う対象パケットの）ヘッダ圧縮と、（ダウンリンク・トラフィック１４４を介して受信されるパケットの）解凍とを行うターミナル・アダプタ（ＭＳ ＡＤ）１３６が含まれる。したがって、ターミナル・アダプタ（ＭＳ ＡＤ）１３６は、ＡＮＩ ＡＤ圧縮装置／解凍装置と類似するヘッダ圧縮装置／解凍装置（送受信装置）１３７であると考えることができる。ＭＳ ＡＤという術語はＡＤと同じ意味を持つ。

ＭＳ ＡＤ１３６には、現時点のヘッダのＲＴＰタイム・スタンプの近似値（または推定値）を計算し、フェージングなどの無線による減損に起因する、端末装置への送信中のパケットの紛失を見つけるために連続して受信されるパケット間の経過時間を測定するためのタイマ１３４（受信機用タイマ）も含まれる。同時継続の特許出願シリアル番号０９/３７７，９１３（１９９９年８月２０日出願、本発明と同じ譲受人に譲受）に記載のように、ＭＳ ＡＤ１３６は、ＲＴＰヘッダ内の追加情報を利用して、タイム・スタンプの近似値の微調整や修正を行うこともできる。上記出願はその全体が本明細書に参考文献として取り入れられている。タイム・スタンプの近似値は、ＲＴＰヘッダの中に付与される圧縮されたタイム・スタンプに基づいて修正または調整を行うことができる。このようにして、ローカル・タイマと、圧縮されたタイム・スタンプとを利用して、各ＲＴＰヘッダ用の正確なタイム・スタンプの再生を行うことが可能となる。

圧縮ヘッダと未圧縮ヘッダを持つパケットを含むＲＴＰパケットは、データ・リンク（無線リンク１４０などの）を介して、図２の例示ネットワーク（但しこのネットワークに限定されるものではない）のようなネットワークで送信される。この場合帯域はオプションであり、通常エラーが発生する。本発明は、無線リンクに限定されるものではなく（有線リンクなどを含む）多種多様のリンクに適用可能である。

図３は圧縮用コンテキスト情報と複数の例とを概念的に例示するものである。圧縮用コンテキスト情報は、情報の１つのセット、サブセットまたはサブセットの表示であり、この情報は、圧縮ヘッダを形成するために圧縮アルゴリズムへの入力として圧縮装置が使用するヘッダ内の任意のタイプの情報であってもよいし、１つのエンティティから別のエンティティへの送信であってもよい。もう一方の入力は圧縮対象ヘッダのヘッダ・ソースから得られる。

図４は、解凍用コンテキスト情報と例とを概念的に例示するものである。解凍用コンテキスト情報は、情報の１つのセット、サブセットまたはサブセットの表示であり、この情報は、解凍ヘッダを形成するために解凍アルゴリズムへの入力として解凍装置が使用するヘッダ内の任意のタイプの情報であってもよいし、１つのエンティティから別のエンティティへの送信であってもよい。もう一方の入力は解凍対象ヘッダのヘッダ・ソースから得られる。

圧縮用コンテキスト情報と解凍用コンテキスト情報の双方は動的なものである。更新周波数はヘッダ圧縮方式に依存する。圧縮装置における圧縮用コンテキスト情報の更新という結果をもたらすことができるイベントには、到来ヘッダの圧縮、解凍装置からのフィードバック情報の受信が含まれる。圧縮装置における解凍用コンテキスト情報の更新という結果をもたらすことができるイベントには到来ヘッダの解凍が含まれる。

本発明の実施態様の説明では以下の表記法を使用する：
Ｓ ｕ：アップリンク・トラフィック方向でヘッダ圧縮用としてＭＳ ＡＤが利用する圧縮用コンテキスト情報
Ｓ ｄ：ダウンリンク・トラフィック方向にヘッダの圧縮を行うためのＡＮＩ ＡＤが利用する圧縮用コンテキスト情報
Ｒ ｕ：アップリンク・トラフィック方向でのヘッダ解凍用としてＡＮＩ ＡＤが利用する解凍用コンテキスト情報
Ｒ ｄ：ダウンリンク・トラフィック方向で解凍を行うためのＭＳ ＡＤが利用する解凍用コンテキスト情報
ＡＮＩ１１０及び１２０などのネットワーク・エンティティすなわちノードの範囲内の圧縮装置または移動端末装置１３０と１４０は現時点のヘッダを圧縮するために圧縮用コンテキスト情報を利用する。ＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮の場合、圧縮用コンテキスト情報はＳＯとＦＯ圧縮用コンテキスト情報から構成されるものであってもよい。同様に、解凍用コンテキスト情報はＳＯとＦＯ解凍用コンテキスト情報から構成される。使用表記法：Ｓ ＦＯ ｕとＳ ＳＯ ｕは、それぞれ、Ｓ ｕのＦＯ及びＳＯ圧縮用コンテキスト情報であり、Ｓ ｕ、Ｓ_ＳＯ_ｄ及びＳ_ＦＯ_ｄは、Ｓ_ｄ、Ｒ_ＳＯ_ｕ、Ｒ_ＦＯ_ｕ、Ｒ_ＳＯ_ｄ，Ｒ_ＦＯ_ｄのＦＯ及びＳＯ圧縮用コンテキスト情報である。ＦＯ圧縮用コンテキスト情報は常時使用可能であるが、その少ない圧縮状態から見て最適ではない圧縮が結果として生じる場合がある。ＳＯ圧縮用コンテキスト情報の利用の結果、さらに最適な圧縮がもたらされるが、現時点のヘッダがＳＯで指定されているパターンにぴったり合った場合にのみＳＯを利用するようにしてもよい。

ネットワーク・エンティティすなわちノードの範囲内の圧縮装置は、本発明の様々な実施態様と関連して以下に説明するように、解凍装置からの到来ヘッダ及び／又はフィードバック情報の結果として、ＦＯ圧縮用コンテキスト情報を更新するものであってもよい。圧縮装置は、ヘッダ内に観察されるパターン、及び、解凍装置からのフィードバック情報に基づいてＳＯ圧縮用コンテキスト情報の更新を行う。

ＡＮＩの１１０と１２０などのネットワーク・エンティティすなわちノード、あるいは、移動端末装置１３０と１４０などのネットワーク・エンティティすなわちノードの範囲内の解凍装置はＦＯ及びＳＯ解凍用コンテキスト情報を利用して、ＦＯ及びＳＯ解凍用コンテキスト情報によってそれぞれ圧縮ヘッダの解凍を行う。圧縮用コンテキスト情報の更新を行う決定は圧縮装置により行われる。ＦＯまたはＳＯ圧縮用コンテキスト情報を更新するとき、圧縮装置は、解凍装置がそのＦＯまたはＳＯ解凍用コンテキスト情報を更新して同期を保持することができる旨を暗黙のうちにあるいは明白に解凍装置に知らせなければならない。従来技術と関連する上述のような待ち時間に起因して、２つのコンテキスト情報が同期状態にならない短い時間窓を設けてもよい。しかし、ヘッダ圧縮と解凍方式は、ヘッダが解凍する時までに解凍装置と圧縮装置とが一貫した解凍及び圧縮用コンテキスト情報を持つように動作することが求められる。

ハンド・オフ時のコンテキスト圧縮及び解凍用コンテキスト情報を転送する効率的でかつ正しい処理手順により、以下の問題の処理が行われる。

問題１： 古いＡＮＩ_ＡＤはＳ_ｄとＲ_ｕを格納し、Ｓ_ｄとＲ_ｕを新しいＡＮＩ_ＡＤへ転送できなければならない。この場合の問題点として、例えば図５、６、７などと関連して以下に説明するように、タイム信号の待ち時間に起因して、Ｓ_ｄとＲ_ｕとが格納時の圧縮装置の図と一致しない場合があるということが挙げられる。格納値は、Ｒ_ｕ＊のようなアスタリスク（＊）付きで表示される。

問題点２：コンテキスト情報のリロケーションが無線ハンド・オフと同時に行われて、いったん正しい格納が行われた場合、図６と図７のＳＴ１とＳＴ２の間で上記古いＡＮＩ_ＡＤとＭＳ_ＡＤによりそれぞれ更新されるＲ_ｕ、Ｓ_ｄ、Ｒ_ｄ、Ｓ_ｕに対処する方法を設ける必要がある。

問題点３：ハンド・オフの前後のエア・インターフェースでの信号を（スペクトル効率ために）最小限にすることが望ましい。

問題点４：古いＡＮＩ_ＡＤと新しいＡＮＩ_ＡＤ間の圧縮及び解凍用コンテキスト情報転送は、例えば図８、９などに例示されているリロケーションＳＴ４前に完了することが望ましい。但し本発明はこれに限定されるものではない。

問題点５：（例えば無線リンクのエラー状態、ＡＮＩ_ＡＤ間の信号送信ネットワークの輻輳状態などに起因して、あるいは、ハンド・オフの実行速度に起因して）図８と９などのリロケーションＳＴ４前にエア・インターフェース、信号送信、あるいは圧縮及び解凍用コンテキスト情報の送信を実行することができない場合、バックアップ処理手順を設けて、情報が部分的にしか転送されない場合、あるいは、まったく転送されない場合でさえ、新しいＡＮＩ_ＡＤが圧縮／解凍を再開できるようにる必要がある。コンテキスト情報の転送の完了後までリロケーションの送信を延期することにより無線ハンド・オフが行われればこの問題は解決される。

例えば図６に例示されているような問題点１及び２に関連するダウンリンク・トラフィックの場合、３つの重要なＳＴ１、ＳＴ２、ＳＴ３で処理が行われる。

ＳＴ１で、古いＡＮＩ_ＡＤはその解凍用コンテキスト情報を求めるクエリを行う。ＳＴ２で、ＭＳ_ＡＤはその解凍用コンテキスト情報を格納し、コンテキスト識別子を返送する。ＳＴ３で、古いＡＮＩ_ＡＤは対応する圧縮用コンテキスト情報を導き出し、次いで、新しいＡＮＩ_ＡＤへその圧縮用コンテキスト情報を送信する。

例えば図７に例示されているように、アップリンク・トラフィックの場合にも３つの重要な時刻により処理が行われる。ＳＴ１で、古いＡＮＩ_ＡＤはその解凍用コンテキスト情報のスナップ・ショットをとり、その解凍用コンテキスト情報を識別子としてＭＳ_ＡＤへ送信する。ＳＴ２で、ＭＳ_ＡＤは、対応する圧縮用コンテキスト情報を導き出し、その圧縮用コンテキスト情報を格納し、肯定応答を返送する。ＳＴ３で、古いＡＮＩ_ＡＤはスナップ・ショット解凍用コンテキスト情報を新しいＡＮＩ_ＡＤへ送信する。

このダウンリンク・トラフィックとアップリンク・トラフィックの処理手順を組み合わせて単一の処理手順にしてもよい。

上記問題点３に関連して、（スペクトル効率を図るために）ハンド・オフ前後のエア・インターフェースでの信号送信を最小限にすることが望ましい。エア・インターフェースを介して送信される上記情報の中には、（１）ＡＮＩ_ＡＤからＭＳへ送信されるクエリと、（２）コンテキスト情報と、（３）コンテキスト情報への肯定応答とが含まれる。上記クエリとコンテキスト情報への肯定応答とはショート・メッセージである。無線帯域を保存するために、コンテキスト情報は（数値順索引などのような）短縮形で好適に符号化され、解凍装置で利用するコンテキスト情報の特定が上記コンテキスト情報により解凍装置において行われる。

上記問題点４及び５に関連して、転送される圧縮及び解凍用コンテキスト情報は最小限に保持され、高速リンクが２つのＡＮＩ_ＡＤ間に想定される。ダウンリンク・トラフィック（それぞれのアップリンク・トラフィック）の場合、新しいＡＮＩ_ＡＤが圧縮及び解凍用コンテキスト情報を得たとき、ＭＳ_ＡＤとのハンドシェイクが成功した場合にのみ、圧縮及び解凍用コンテキスト情報が新しいＡＮＩ_ＡＤへ転送されるので、ＭＳ_ＡＤが、解凍（それぞれ圧縮）を行うために、対応する解凍用コンテキスト情報を持っていることを安全に想定することが可能となる。失敗の唯一のケースとしては、新しいＡＮＩ_ＡＤが、何らかの理由で、古いＡＮＩ_ＡＤから上記コンテキスト情報を得られなくなったケースが考えられる。その場合、ヘッダの圧縮／解凍処理はフル・ヘッダを用いて再開される。

ハンド・オフの応用の一例として、フィードバック情報（以下のような肯定応答ベースのヘッダ圧縮の実施態様）について考察することにする。

圧縮装置の３つの動作状態
肯定応答を用いるＦＯ及びＳＯ状態への遷移
肯定応答（ＡＣＫ）パケットには通常、正しく受信／解凍されたヘッダを特定するためのコンテキスト識別子（ＣＩＤ）とシーケンス番号（ＣＤ_ＳＮ）とが含まれる（但し、他のオプション情報を運ぶことも可能である）。

新しいセッションが始まると、少なくとも１つのＦＨパケットを受信した旨を示す解凍装置からの肯定応答（ＡＣＫ）を受信するまで圧縮装置はＦＨ状態で動作する。解凍装置がＦＨパケットを受信するとすぐにＦＨパケットにＡＣＫを行うことは解凍装置の役割であり、それによって圧縮装置はＦＨ状態からＦＯ状態への推移を行うことが可能となる。

ＦＯ状態では、圧縮装置はＦＯパケットを送信し、解凍装置はＦＯパケット（必ずしもすべてのＦＯパケットであるとはかぎらない）に対して確認応答を行うものと予期されている。圧縮装置が、解凍装置が（肯定応答に基づいて）ＦＯＤを確立したと判断し、次いで、ＦＯＤが、送信中の現時点のヘッダと最後に送信されたヘッダとの間のＦＯＤと同じであると判断した場合、圧縮装置はＳＯ状態へ進み、ＳＯパケットの送信を開始する。ＳＯを用いて圧縮が可能な一連のヘッダは列と呼ぶことができる。

上述の理由のため、圧縮装置はＳＯ状態からＦＯ状態へ後退する場合もある。しかし、システム・ラッシュに起因して解凍装置がその解凍用コンテキスト情報を失う場合などのような何らかの例外的イベントが生じない限り、圧縮装置が元のＦＨ状態へ推移することは決してない。圧縮装置は、ＦＯ状態にあるときはいつでも上述のようなＳＯ状態への進行を試みる。

長い紛失を検出するための周期的肯定応答
ラップ・アラウンド／長い紛失問題を処理するために、解凍装置は、通常ｓｅｑ_ｃｙｃｌｅヘッダ毎に少なくとも１回ＡＣＫを受信できるように十分密接間隔の規則的に離間した間隔で肯定応答の送信を行う（但しｓｅｑ_ｃｙｃｌｅ＝２ｋ）。

送信遅延を考慮するために、解凍装置は周期的肯定応答の送信時期の予想を行う。解凍装置は、十分早めに周期的肯定応答を送信して、圧縮装置が、通常、１ｓｅｑ_ｃｙｃｌｅ毎に少なくとも１回肯定応答を受信するようにする。往復時間を考慮に入れて、解凍装置は（ｓｅｑ_ｃｙｃｌｅ−Ｎ_ＲＴ）ヘッダ毎に少なくとも１回ＡＣＫを送信しなければならない。この場合、Ｎ_ＲＴとは往復時間（ＲＴＴ）中に圧縮装置により送信される予測ヘッダ数である。

圧縮装置は、ｓｅｑ_ｃｙｃｌｅ以内に肯定応答を受信しなかった場合、シーケンス番号を運ぶためにｌ_ｅｘｔｅｎｄｅｄ＞ｋビットを利用する。ＲＴＴがその上限に達した場合でも、ｌ_ｅｘｔｅｎｄｅｄビットがラップ・アラウンドしないように選択される。さらに一般的アプローチとして、シーケンス番号の可変長符号化（ＶＬＥ）を利用する、以下検討するアプローチがあることに留意されたい。このアプローチでは、マルチ・レベル符号化は２レベル符号化の代わりに使用される。ＶＬＥ符号化された値での長さフィールドは、さらに多くのビットを要する可能性があるので、レベルの数は注意深い選択を行うことが望ましい。

デルタ符号化による肯定応答ベースの実施態様
ＦＯヘッダ内の各変化フィールドの符号化方法は、デルタ符号化か可変長符号化（ＶＬＥ）のいずれか、もしくは別の好適な方法を利用することが可能である。

デルタ符号化に関しては、圧縮値ｖが（ｖ_ｖ_ｒｅｆ）として送信される。但しｖ_ｒｅｆは、確認応答を受けた基準ヘッダ内の値である。解凍では同じ基準ヘッダが用いられる。
その場合:
Ｓ_ＦＯ_ｕはＳ_ＲＦＨ_ｕに対応する（Ｓ_ＲＦＨ_ｕはＡＮＩ_ＡＤによって確認応答を受けたヘッダであり、ＭＳ_ＡＤにより圧縮されてＦＯヘッダになる基準ヘッダとして使用される）。
Ｓ_ＳＯ_ｕはＳ_ＤＦＯＤに対応する（ＭＳ_ＡＤにより使用されるＦＯＤであって、圧縮されてＳＯヘッダになる）。
Ｒ_ＦＯ_ｕはＲ_ＲＦＨ_ｕに対応する（Ｒ_ＲＦＨ_ｕはＳ_ＲＦＨ_ｕと同じ内容を持ち、基準ヘッダとしてＡＮＩ_ＡＤにより使用されＦＯヘッダの解凍を行う）。

Ｒ_ＳＯ_ｕはＲ_ＤＦＯＤに対応する（ＡＮＩ_ＡＤにより使用されるＦＯＤであって、ＳＯヘッダの解凍を行う）。
Ｓ_ＦＯ_ｄは、Ｓ_ＲＦＨ_ｄに対応する（Ｓ_ＲＦＨ_ｄは、ＭＳ_ＡＤにより確認応答を受けたヘッダであり、基準ヘッダとしてＡＮＩ_ＡＤにより使用され、圧縮されてＦＯヘッダになる）。

Ｓ_ＳＯ_ｄは、Ｓ_ＤＦＯＤに対応する（ＡＮＩ_ＡＤにより使用されるＦＯＤであって、圧縮されてＳＯヘッダになる）。
Ｒ_ＦＯ_ｄはＲ_ＲＦＨ_ｄに対応する（Ｒ_ＲＦＨ_ｄはＳ_ＲＦＨ_ｄと同じ内容を持ち、基準ヘッダとしてＭＳ_ＡＤにより使用されてＦＯヘッダの解凍を行う）。
Ｒ_ＳＯ_ｄはＲ_ＤＦＯＤに対応する（ＭＳ_ＡＤにより使用されるＦＯＤであってＳＯヘッダの解凍を行う）。

効率を図るために、初めてネットワーク・エンティティにより受信されていないすべてのコンテキスト圧縮及び解凍用コンテキスト情報（圧縮または解凍用コンテキスト情報を予め格納していない新しいＡＮＩのような新しいネットワーク・エンティティ）は、制限なく、圧縮ヘッダの列内のシーケンス番号であってもよい数値順索引の場合と同様に、圧縮または解凍用コンテキスト情報の表現としてエア・インターフェースを介してＭＳ_ＡＤと古いＡＮＩ_ＡＤとの間で好適に交換される。Ｓ_ＦＯ_ｕまたはＳ_ＦＯ_ｄには、フル・ヘッダと同じフィールドが実質的に含まれる。Ｓ_ＦＯ_ｕまたはＳ_ＦＯ_ｄは、数値順索引（確認応答を受けたフル・ヘッダに対応するＲＴＰまたは短縮シーケンス番号）として好適に符号化される。Ｓ_ＳＯ_ｕまたはＳ_ＳＯ_ｄは、現時点の列または最も新しい列に属するすべてのヘッダが一致するパターンを指定する成分を持つベクトルである。列とは、ＳＯとして圧縮可能な一続きのヘッダである。この列は、数値順索引（確認応答を受けたヘッダに対応するＲＴＰまたは短縮シーケンス番号）として符号化される。古いＡＮＩ_ＡＤは、フル・ベクトルとして圧縮または解凍用コンテキスト情報を新しいＡＮＩ_ＡＤへ送信する。

ＶＬＥによる肯定応答ベースの実施態様
ＶＬＥを用いる場合、圧縮対象値ｖはそのｋ最下位ビットとして送信される。前述のヘッダ圧縮方式でＦＯパケットのフィールドを符号化するために、肯定応答を利用して、ｋの値と、圧縮装置により保持されているヘッダの可変スライディング・ウィンドウ（ＶＳＷ）のサイズとを小さくすることが可能である。基本的に、このような肯定応答の受信時に圧縮装置は以下のようなアクションをとる：
解凍装置から特定のｖに対する肯定応答を受信すると、圧縮装置は、ｖよりも古いＶＳＷ内のいずれの値も削除し、次いで、ｖ_ｍｉｎとｖ_ｍａｘを更新する。

ＶＬＥを用いて、ＦＯヘッダのいくつかのフィールドの符号化が可能である。ＶＬＥは、ｖ（ｎ）_ｋ（ｖ（ｎ）のｋ最下位ビット）の送信により、ヘッダ（ｎ）のフィールドＦ（表示ｖ（ｎ））を圧縮する。ビット数ｋは、圧縮装置により前回圧縮され、送信された値：ｖ（ｍ），ｖ（ｍ＋１），...，ｖ（ｎ−１）を持つウィンドウＶＳＷの関数として圧縮装置により選択される。

ｖ_ｍａｘとｖ_ｍｉｎをウィンドウの最大値及び最小値とする。圧縮された所定値ｖに対して、ｒ＝ｍａｘ（｜ｖ−ｖ_ｍａｘ｜，｜ｖ−ｖ_ｍｉｎ｜）とする。圧縮装置は天井（ログ２（２＊ｒ＋１））としてｋを選択する。圧縮装置は、ＶＳＷの中へｖを加算し、ｖ_ｍｉｎとｖ_ｍａｘを更新する。この場合、ｘ．ｙの形の任意の数について、ｙ＝０ならば、天井（ｘ．ｙ）＝ｘ、ｙ≠０ならば、天井（ｘ．ｙ）＝ｘ＋１である。

解凍装置は、ｖ_ｒｅｆに最も近い値を解凍値として選択する。最も近い値のｋ ＬＳＢは受信した圧縮値に等しい。

この場合、このような各フィールドＦについて、コンテキスト圧縮と解凍情報のフィールド（ＶＬＥフィールドと呼ばれる）がＶＬＥにより符号化される場合：
Ｓ_ＦＯ_ｕは、ＭＳ_ＡＤにより保持される（ｖ_ｍｉｎ，ｖ_ｍａｘ）の対を含む。但し、格納値Ｓ_ＦＯ_ｕ＊は、図７などに例示されているようなアップリンク・トラフィック処理手順のＳＴ１で確認応答を受けたヘッダ内のフィールド値ｖである。ハンド・オフ後、ＭＳ_ＡＤは圧縮用としてｖ＝ｖ_ｍｉｎ＝ｖ_ｍａｘを利用する。新しいＡＮＩ_ＡＤは解凍用基準値と同じ値ｖ（Ｒ_ＦＯ_ｕ＊）を利用する。

Ｓ_ＳＯ_ｕはＳ_ＤＦＯＤに対応する（ＭＳ_ＡＤにより使用されるＦＯＤであって、圧縮されてＳＯヘッダになる）。
Ｒ_ＦＯ_ｕはＡＮＩ_ＡＤにおいて最も新しく受信した値ｖを含む。
Ｒ_ＦＯ_ｕ＊はＳ_ＦＯ_ｕ＊に等しい。
Ｒ_ＳＯ_ｕはＲ_ＤＦＯＤに対応する（ＡＮＩ_ＡＤにより使用されるＦＯＤであって、ＳＯヘッダの解凍を行う）。

Ｓ_ＦＯ_ｄは、ＡＮＩ_ＡＤにより保持される（ｖ_ｍｉｎ，ｖ_ｍａｘ）の対を含む。
Ｓ_ＦＯ_ｄ＊は最後に確認応答を受けたヘッダ内のフィールド値ｖである。ハンド・オフ後、新しいＡＮＩ_ＡＤはｖ＝ｖ_ｍｉｎ＝ｖ_ｍａｘを用いて圧縮を再開する。ＭＳ_ＡＤは基準値（Ｒ_ＦＯ_ｄ＊）と同じ当該ｖを用いて解凍を行う。
Ｓ_ＳＯ_ｄはＳ_ＤＦＯＤに対応する（ＡＮＩ_ＡＤにより使用されるＦＯＤであって、圧縮されてＳＯヘッダになる）。

Ｒ_ＦＯ_ｄは、ＭＳ_ＡＤにおいて最も新しく受信した値ｖを含む。
Ｒ_ＦＯ_ｄ＊はＳ_ＦＯ_ｄ＊に等しい。
Ｒ_ＳＯ_ｄはＲ_ＤＦＯＤに対応する（ＭＳ_ＡＤにより使用されるＦＯＤであってＳＯヘッダの解凍を行う）。

効率を図るために、デルタ符号化の場合のように、エア・インターフェースを介してＭＳ_ＡＤとＡＮＩ_ＡＤとの間で交換されるすべての圧縮及び／又は解凍用コンテキスト情報は数値順索引として符号化されることが望ましい。これらのコンテキストはＲ_ＳＯ_ｄ、Ｒ_ＦＯ_ｄ、Ｒ_ＳＯ_ｕ、Ｒ_ＦＯ_ｕである。これらのコンテキストはフル・ヘッダと同じフィールドを実質的に含み、数値順索引として符号化が可能である（確認応答を受けたフル・ヘッダに対応するＲＴＰまたは短縮シーケンス番号）。

古いＡＮＩ_ＡＤはフル・ベクトルとして新しいＡＮＩ_ＡＤへこのコンテキストを送信する。

本発明の実施態様は、無線ハンド・オフと同時に行われる圧縮と解凍、あるいは、無線ハンド・オフの完了後に行われる圧縮と解凍を行うネットワーク・エンティティの切れ目のないリロケーションを提供するものである。

この動作モードでは、無線ハンド・オフ後リロケーションの送信が延期されるとき移行期間が存在し、この移行期間中、古いネットワーク・エンティティ（ＡＮＩ_ＡＤ）の中を通り、新しいネットワーク・エンティティ（ＡＮＩ_ＡＤ）へ向かうダウンリンク・トラフィックとアップリンク・トラフィックのパス・フローが生じる。一般に、このモードでは、ハンド・オフ処理手順は、ＭＳ_ＡＤが別の無線セルへ移動する第１の無線ハンド・オフに関与するが、古いＡＮＩ_ＡＤはそのままヘッダの圧縮／解凍を行う。その後、圧縮用コンテキストと解凍用コンテキスト情報は古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ転送される。最終的に、この圧縮及び解凍用コンテキスト情報の転送完了後、新しいＡＮＩ_ＡＤによる圧縮／解凍を開始される。すなわち、リロケーションが行われる。

リロケーション後、圧縮対象ヘッダを含むパケットを新しいＡＮＩ_ＡＤへ直接送信するためにネットワークの再構成を行ってもよい。上記送信延期モードの実施態様では、新しいＡＮＩ_ＡＤは、古いＡＮＩ_ＡＤとＭＳ_ＡＤとの間に圧縮ヘッダを持つデータ・パケットをリレーする機能を実行し、一方、新しいＡＮＩ_ＡＤからＭＳ_ＡＤへ送信されるデータ・パケットを持つヘッダを圧縮するために最終的に利用される上記コンテキスト情報は、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ徐々に転送される。

図８は、無線ダウンリンク・トラフィックの場合の上記一続きのイベントを例示するものであり、このイベントの中で、圧縮用コンテキスト情報は無線ハンド・オフ後に古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ送信される。例示されているように、最初の圧縮ヘッダ（４）は、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤを介してＭＳ_ＡＤへ送信され、該ＭＳ_ＡＤは、古いＡＮＩ_ＡＤにより圧縮されたものとして或る形で上記圧縮ヘッダ（４）を受信する。ＳＴ１で、古いＡＮＩ_ＡＤは、圧縮ヘッダ（５）プラス圧縮用コンテキスト情報を新しいＡＮＩ_ＡＤへ送信し、この新しいＡＮＩ_ＡＤ（５）は上記圧縮ヘッダと上記圧縮用コンテキスト情報との組合せをＳＴ２で受信する。ＳＴ１での送信は、圧縮ヘッダ（５）と圧縮用コンテキスト情報との組合せであることに留意されたい。しかし、上記とは別に、例示されているように、本実施態様に従って、圧縮ヘッダ（６）と元の未圧縮ヘッダ（６）の受信時点までの任意の時刻に、新しいＡＮＩ_ＡＤにより上記圧縮用コンテキスト情報の受信を行ってもよい。ＳＴ２で、新しいＡＮＩ_ＡＤは、圧縮用コンテキスト情報を受信した旨の通知を古いＡＮＩ_ＡＤへ返送する。この通知の受信後のある時点に、古いＡＮＩ_ＡＤは新しいＡＮＩ_ＡＤへの圧縮ヘッダの送信を停止する。しかし、例示されているように、古いＡＮＩ_ＡＤは、ヘッダ圧縮機能を実行する新しいＡＮＩ_ＡＤへ未圧縮ヘッダをリレーするヘッダ・ソースとしての機能の継続が可能であり、古いＡＮＩ_ＡＤ以外のパケット・ソースが圧縮対象ヘッダを持つパケットを提供することができる。ＳＴ２で、新しいＡＮＩ_ＡＤはこの圧縮用コンテキスト情報を格納し、この圧縮用コンテキスト情報によって新しいＡＮＩ_ＡＤは後程ヘッダ圧縮機能に着手することが可能になり、古いＡＮＩ_ＡＤからＭＳ_ＡＤへ圧縮ヘッダ（４）の転送を行う。その後、圧縮ヘッダを含む追加パケットを設けてもよい（例示されているように、圧縮ヘッダ（６）と（７）、及び、元の未圧縮ヘッダ（６）と（７）は、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ送信される）。圧縮されたヘッダと元の未圧縮ヘッダの双方のデュアル送信により、新しいＡＮＩ_ＡＤが十分な情報を任意の時点に得ることが可能になり、古いＡＮＩ_ＡＤが圧縮ヘッダの送信を中止する時点に無関係に（非同期的に）新しいＡＮＩ_ＡＤは未圧縮ヘッダの圧縮機能に着手できるようになる。例示されているように、圧縮ヘッダ（６）と（７）とは、新しいＡＮＩ_ＡＤで圧縮され、新しいＡＮＩ_ＡＤからＭＳ_ＡＤへの送信が行われる。最終的に、上述のように、新しいＡＮＩ_ＡＤによりヘッダの圧縮機能が想定された後、任意のソースから得られる元の未圧縮ヘッダ（６）、（７）、（８）の圧縮が新しいＡＮＩ_ＡＤにより行われる。該任意のソースとは、例示されているように、未圧縮ヘッダ（６）と（７）用としては古いＡＮＩ_ＡＤであり、また、未圧縮ヘッダ（８）用としては古いＡＮＩ_ＡＤまたはパケット・ソースであってもよい。

ＡＮＩ_ＡＤがＳＴ２で生成された通知を受信していないことから明らかなように、何らかの理由のために、ＳＴ１で始まる圧縮用コンテキスト情報の転送開始が無効となった場合、古いＡＮＩ_ＡＤは、上に説明したような圧縮用コンテキスト情報の転送の再試行を１回以上試みることが可能である。これらの新しい試行は、新しいＡＮＩ_ＡＤから通知が受信されなかったことにより証明されるような或る期間の期限切れ後に行われる。

到来ヘッダの連続するフローに起因して、古いＡＮＩ_ＡＤから送信された圧縮用コンテキスト情報は変化する可能性があり、そのため、圧縮ヘッダ（５）と共にリレーする圧縮用コンテキスト情報の更新がＳＴ１で必要となることを理解されたい。しかし、ヘッダ（５）の後で、新しいＡＮＩ_ＡＤは古いＡＮＩ_ＡＤから未圧縮ヘッダを利用できるので、新しいＡＮＩ_ＡＤは受信した圧縮用コンテキスト情報に対して更新を行うことができる。

圧縮用コンテキスト情報にタグを付けて、圧縮ヘッダ（５）などからその圧縮用コンテキスト情報をどの時点でとったかを示すようにしもよい。その結果、新しいＡＮＩ_ＡＤにより、ヘッダ（５）に後続する任意のヘッダを用いて受信した圧縮用コンテキストの更新が行われる。元の未圧縮ヘッダの値を利用して、更新された圧縮用コンテキスト情報を提供するようにしてもよい。

使用するヘッダ圧縮メカニズムに応じて、圧縮用コンテキスト情報が基づいているＡＮＩ_ＡＤの圧縮ヘッダに関する情報を新しいＡＮＩ_ＡＤに与える適時要件のために、圧縮ヘッダ（５）などのような圧縮用コンテキスト情報と関連するヘッダに後続するいずれかのヘッダの受信前に、新しいＡＮＩ_ＡＤによる圧縮用コンテキスト情報の受信が必要となる。上記の環境で、新しいＡＮＩ_ＡＤは、ヘッダ（６）より前に圧縮用コンテキスト情報を受信した場合にのみ通知を送信する。これを行う１つの方法として、ヘッダ（５）に圧縮用コンテキスト情報を付け、高帯域を用いて単一の送信として上記情報全体の送信を行う方法がある。しかし、圧縮されたヘッダ及びそれと関連する圧縮用コンテキスト情報の送信時点を分割する別のアプローチも可能である。

別のヘッダ圧縮方式として、たとえヘッダ（６）に関する上記例よりも後に圧縮用コンテキスト情報を受信した場合であっても、新しいＡＮＩ_ＡＤは、受信した圧縮用コンテキスト情報に対して遡及的に更新を適用することが可能であり、その場合、上記圧縮用コンテキスト情報が圧縮ヘッダ（５）と関連して送信されるが、上記圧縮用コンテキスト情報の送信時点は、送信ヘッダ（６）の送信時点と同じ位遅い時点であってもよい。この場合、この新しいＡＮＩ_ＡＤはそのメモリの中に最も新しく受信した元の未圧縮ヘッダを保持し、圧縮用コンテキスト情報を更新するために適切なヘッダの検索を行う。図８に例示されているようにヘッダ番号は、ＲＴＰシーケンス番号とは無関係であり、ヘッダの番号付けは古いＡＮＩ_ＡＤにより行われる機能であることに留意されたい。

図９は、圧縮の実施態様の一部として、図８と関連して上述したような、ＭＳ_ＡＤから古いＡＮＩ_ＡＤへのダウンリンク・トラフィックの場合の上記フィードバック情報の利用を例示する図である。肯定応答（ＡＣＫ（１））の形での上記第１のフィードバック情報がＭＳ_ＡＤと、ＳＴ１前に受信された古いＡＮＩ_ＡＤとの間で行われる。この時刻より前に、第４の圧縮ヘッダ（４）を持つパケットが新しいＡＮＩ_ＡＤへ送信され、この新しいＡＮＩ_ＡＤによりパケットはＭＳ_ＡＤへリレーされる。肯定応答ＡＣＫ（１）の受信により、ＭＳ_ＡＤが受信した圧縮ヘッダの受信状態を古いＡＮＩ_ＡＤに知らせる情報が古いＡＮＩ_ＡＤに与えられる。ＳＴ１で、古いＡＮＩ_ＡＤは、圧縮ヘッダ（５）、及び、図８と関連して上述したものと類似しているが、圧縮用コンテキスト識別子［１］をさらに含む圧縮用コンテキスト情報を送信する。識別子［１］は、圧縮用コンテキストが、ＡＣＫ（１）を考慮に入れているが、ＡＣＫ（１）より若い肯定応答は考慮していないことを新しいＡＮＩ_ＡＤに対して示す。ＳＴ２で、新しいＡＮＩ_ＡＤは圧縮用コンテキストを格納する。しかし、図８の通信シーケンスの場合とは異なり、第２の肯定応答（ＡＣＫ（２））の形のＭＳ_ＡＤからのフィードバック情報が新しいＡＮＩ_ＡＤにより受信される。このことにより、新しいＡＮＩ_ＡＤは、上記第２のフィードバック情報（ＡＣＫ（２））で受信した上記情報に基づくよりもむしろ、圧縮ヘッダ（５）と関連する圧縮用コンテキスト情報と関連する識別子［１］に基づいて、新しいＡＮＩ_ＡＤの圧縮用コンテキスト情報の更新を行うことが可能になる。古いＡＮＩ_ＡＤは、ＭＳ_ＡＤから受信した（ＡＣＫ（１））の最後のフィードバック情報のシーケンス番号から圧縮用コンテキストの識別子を生成する。ＭＳ_ＡＤにより解凍された最後のヘッダに関する最新の情報は最後のフィードバック情報により提供されるので、最後のフィードバック情報だけしか利用されない。したがって、ＳＴ２で、新しいＡＮＩ_ＡＤは、最後に受信したフィードバック情報（ＡＣＫ（２））と共にこのコンテキスト情報を格納する。新しいＡＮＩ_ＡＤは、ＳＴ２より前にいずれかの別のフィードバック情報を受信したかどうかのチェックも行う。ＳＴ２は、古いＡＮＩ_ＡＤと新しいＡＮＩ_ＡＤとの間の通信用往復時間として定義されるＴ１秒未満の値であるが、Ｔ１の別の時間設定も可能である。新しいＡＮＩ_ＡＤがＴ１秒未満の時点ＳＴ２より前に何らかのフィードバック情報を受信した場合、受信した上記フィードバック情報が例えば上記第１のフィードバック情報（ＡＣＫ（１））などの基準フィードバック情報よりも若いかどうかを調べるチェックが行われる。上記フィードバック情報が新しいものである場合、新しいＡＮＩ_ＡＤに格納された圧縮用コンテキストはそのフィードバック情報を用いて更新される。これらの更新値は受信されるフィードバック情報の順に適用される。ＳＴ２後、新しいＡＮＩ_ＡＤは、（ＡＣＫ（ｎ））として特定された、ＭＳ_ＡＤから受信した任意のフィードバック情報を用いて圧縮用コンテキストを連続して更新する。図９に例示されている信号フローの残り部分は図８の信号フローと同一であるが、例図を簡略化するために削除されている。

図１０は、古いＡＮＩから新しいＡＮＩへの解凍用コンテキスト情報の転送に先行して無線ハンド・オフが行われる場合のアップリンク・トラフィックでの動作を例示する。ＭＳ_ＡＤは、古いＡＮＩ_ＡＤへリレーされる新しいＡＮＩ_ＡＤを介して少なくとも１つの圧縮ヘッダを送信する。上記第１の圧縮ヘッダ（１）は新しいＡＮＩ_ＡＤから古いＡＮＩ_ＡＤへ転送される。ＳＴ１で、新しいＡＮＩ_ＡＤへ送信するために、古いＡＮＩ_ＡＤはその解凍用コンテキスト情報のスナップ・ショットをとる。ＳＴ２で、新しいＡＮＩ_ＡＤは解凍用コンテキスト情報を受信し格納する。その後、新しいＡＮＩ_ＡＤはＭＳ_ＡＤから受信した後続のヘッダ（４）、（５）、（６）のいずれをも解凍する。送信シーケンスで、上記第１の３つのヘッダ（１）、（２）、（３）は、ヘッダのいずれの解凍も新しいＡＮＩ_ＡＤで行うことなくＭＳ_ＡＤから新しいＡＮＩ_ＡＤを介して送信される。しかし、解凍用コンテキスト情報の時刻ＳＴ２での格納の結果、次に受信されるヘッダはＳＴ３で解凍が行われ古いＡＮＩ_ＡＤへ送信される。解凍されたヘッダの受信に起因して、古いＡＮＩ_ＡＤは新しいＡＮＩ_ＡＤから受信したヘッダの解凍を停止する。ヘッダ圧縮方式がフィードバック情報に基づくものである場合、古いＡＮＩ_ＡＤはＭＳ_ＡＤへフィードバック情報を送信してもよい。その場合、新しいＡＮＩ_ＡＤにより、上記フィードバック情報はＭＳ_ＡＤへリレーされ、また、上記フィードバック情報（図１０のＡＣＫ（２））に基づいてその解凍用コンテキストの更新も行われる。

様々な実施態様でオプションとして利用されるコンテキスト識別子は、コンテキスト構成部の識別子のコレクションである（これらの識別子は、複数のコンテキスト構成部に共通のものであれば繰り返し使用する必要はない）。

図１１と１２は、それぞれ、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへの圧縮機能（ダウンリンク・トラフィック）と解凍機能（アップリンク・トラフィック）の、無線ハンド・オフと同時に行われるリロケーションを例示するものである。本実施態様は、古いＡＮＩ_ＡＤが圧縮または解凍用コンテキスト情報を取得し、ＭＳ_ＡＤへ／から転送される情報を要求することなく、新しいＡＮＩ_ＡＤへ上記解凍用コンテキスト情報を送信するステップに基づいているが、新しいＡＮＩ_ＡＤとその交信を行うことを考慮して、ＭＳ_ＡＤの圧縮装置／解凍装置機能がハンド・オフを行うようにアドバイスを受ける実施態様である。

図１１に例示されているように、古いＡＮＩ_ＡＤは、ＣＣ_Ｄで示される圧縮用コンテキスト情報を格納し、識別子ＣＣ_Ｄ_ＩＤを持つこの圧縮用コンテキスト情報ＣＣ_Ｄを新しいＡＮＩ_ＡＤへ送信する。新しいＡＮＩ_ＡＤは圧縮用コンテキスト情報ＣＣ_Ｄと識別子ＣＣ_Ｄ_ＩＤとを格納する。無線ハンド・オフの直後、上記格納された圧縮用コンテキスト情報の利用開始時に、新しいＡＮＩ_ＡＤは、圧縮ヘッダの中に圧縮用コンテキストＣＣ_Ｄの識別子を含め、この圧縮ヘッダと、及び、ＭＳ_ＡＤに格納されたコンテキスト識別子ＣＣ_Ｄ_ＩＤとをＭＳ_ＡＤへ送信する。識別子ＣＣ_Ｄ_ＩＤにより、ＭＳ_ＡＤは、新しいＡＮＩ_ＡＤにより利用される圧縮用コンテキストに対応する正しい解凍用コンテキストの検索を行って、受信ヘッダの解凍を行うことが可能になる。ヘッダ圧縮の実施態様に基づくフィードバック情報（肯定応答など）で、ＭＳ_ＡＤから、ＭＳ_ＡＤの解凍用コンテキスト情報の新しいＡＮＩ_ＡＤへ肯定応答（ＡＣＫ）が送信される。いったんフィードバック情報が受信されると、ＭＳ_ＡＤへ送信する圧縮ヘッダの中にＣＣ_Ｄ_ＩＤを含める必要はもはやなくなるが、ヘッダ圧縮方式に依っては、ＣＣ_Ｄ_ＩＤを含めてもよい。ＣＣ_Ｄ_ＩＤはパケット列のシーケンス番号であってもよい。

図１２は、アップリンク・トラフィック時の古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへの、無線ハンド・オフと同時に行われる解凍機能のリロケーションを例示する。古いＡＮＩ_ＡＤは、新しいＡＮＩ_ＡＤへ送信する解凍用コンテキストＤＣ_ｕと解凍用コンテキストのＤＣ_ｕ_ＩＤ識別子を選択する。新しいＡＮＩ_ＡＤは解凍用コンテキストＤＣ_ｕを格納する。例示されているように、古いＡＮＩ_ＡＤは、解凍用コンテキスト識別子ＤＣ_ｕ_ＩＤと共にハンドオーバー・コマンドをＭＳ_ＡＤへ送信する。ＭＳ_ＡＤはこの識別子を用いて、対応する圧縮用コンテキストＣＣ_ｕを導き出し、この圧縮用コンテキストＣＣ_ｕの格納を行うが、本発明はハンドオーバー・コマンドとＤＣ_ｕ_ＩＤとのジョイント送信に限定されるものではない。無線ハンド・オフ後、ＭＳ_ＡＤは解凍用として直ちにＣＣ_ｕを利用する。新しいＡＮＩ_ＡＤはＤＣ_ｕを用いて解凍を行う。ハンドオーバー・コマンドは、ハンド・オフを行うために必要なメッセージであることに留意されたい。したがって、量ＤＣ_ｕ_ＩＤはハンドオフ・コマンドにピギーバックされるものであるため、新しいメッセージを必要としない。

圧縮及び解凍用コンテキスト識別子は、それらがシーケンス番号などの数値順索引に基づいていることを考慮して効率的に符号化される。

図１３は解凍装置がヘッダ（ｎ）の受信に基づいてその解凍用コンテキストの更新を行う一例を例示するものである。数値順索引はシーケンス番号、または、何らかの別のシーケンス番号であってもよい。数値順索引は上記コンテキスト情報を特定するために利用される。新しい圧縮装置は、ヘッダ（ｎ）の受信に基づいてその解凍用コンテキストを更新するヘッダ解凍装置へ圧縮ヘッダ（ｎ）を送信する。数値順索引ｎは更新された解凍用コンテキストの表現として利用される。その後、ヘッダ解凍装置は肯定応答（ＡＣＫ（ｎ））の形でフィードバック情報を送信し、この肯定応答（ＡＣＫ（ｎ））により、圧縮装置は特定の肯定応答の受信に基づいてその圧縮用コンテキストの更新を行い、新しく更新されたコンテキストの表現として数値順索引ｎが利用される。

古いＡＮＩ_ＡＤとＭＳ_ＡＤとの間で送信される圧縮及び／又は解凍状態を効率的に更新するために必要な情報量は、全部の圧縮または解凍情報の代わりに、圧縮または解凍用コンテキスト識別子などの圧縮及び／又は解凍情報の表現の送信により減らすことができる。この表現は上述したコンテキスト識別子であってもよい。

完全なＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮の実施態様では、元のヘッダ（ＲＴ ＰＴＳ、ＲＴ ＰＳＮなど）の各フィールド及びすべてのフィールドの圧縮が行われる。圧縮対象のヘッダ・フィールドに応じて、様々な圧縮技法の利用が可能である。したがって、完全なヘッダ圧縮は、個々の圧縮技法の様々なの組合せであってもよい。例えば、ヘッダ圧縮方式は、ＲＴＰ ＳＮフィールドを圧縮するＶＬＥによる圧縮技法を用いるものであってもよいし、ＩＰアドレス・フィールドを圧縮する暗黙の符号化技法を用いるものであってもよい。各技法について、圧縮装置は圧縮を行うための何らかの情報を必要とする。同様に解凍装置も解凍を行うための何らかの情報を必要とする。この情報は、それぞれ、圧縮用コンテキスト構成部及び解凍用コンテキスト構成部と呼ばれる。この場合、この圧縮（それぞれ解凍）コンテキストは、個々の圧縮（それぞれ解凍）コンテキスト構成部のコレクションである。コンテキスト識別子はコンテキスト構成部の識別子のコレクションである（これらの識別子は、複数のコンテキスト構成部に共通のものであれば繰り返し使用する必要はない）。上述の例と同じ例を用いる場合、圧縮用コンテキスト情報は、ＶＬＥ技法によりＲＴ ＰＳＮを圧縮するための圧縮用コンテキスト構成部を含むものであってもよいし、暗黙の符号化技法によりＩＰアドレスを圧縮するための圧縮用コンテキスト構成部を含むものであってもよい。

上記暗黙の符号化技法は固定フィールド、すなわちヘッダによる変化が生じないフィールドに対して適用される。圧縮値としてデータの送信を行う必要はない。圧縮用コンテキスト構成部はこの固定値から構成される。解凍用コンテキスト構成部は圧縮用コンテキスト構成部と同一である。

デルタ符号化の場合、所定のフィールドについて、圧縮装置は対応する基準ヘッダ内の値を基準とする元の未圧縮ヘッダ内の値の差分を圧縮値として送信する。例えば、元の未圧縮ヘッダのＲＴＰタイム・スタンプが５００で、基準ヘッダのＲＴＰタイム・スタンプが４５０である場合、圧縮されるＲＴＰタイム・スタンプは５０となる。解凍装置は、基準ヘッダ（４５０）のＲＴＰタイム・スタンプに、受信した解凍値（５０）を加算することにより解凍を行う。この場合、圧縮及び解凍用コンテキスト構成部は、基準ヘッダ内のＲＴＰタイム・スタンプの内容と同一であり、基準ヘッダ内のＲＴＰタイム・スタンプの内容に等しい。コンテキスト構成部識別子は、基準ヘッダのＲＴＰシーケンス番号であってもよいし、あるいは、基準ヘッダから成る或る短縮形であってもよい。

ＶＬＥの場合、圧縮装置は、圧縮された、ウィンドウＷに属する元の未圧縮の値の範囲Ｖ_ｍｉｎ、Ｖ_ｍａｘを追跡しつづける。上記フィードバック情報を伴うＶＬＥでは、ウィンドウＷは、最後に確認応答を受けた値からずっと未圧縮の形で圧縮されてきた値から構成される。フィードバック情報を伴わないＶＬＥでは、ウィンドウはＬ個の最も最近圧縮された値（但しＬはパラメータである）から構成される。圧縮装置は、元の未圧縮の値のｋ最下位ビットを圧縮値として送信する。値ｋはＶ_ｍｉｎとＶ_ｍａｘの関数として計算される。解凍装置は最後の解凍値Ｖ_ｌａｓｔを保持する。設計により、Ｖ_ｍｉｎはＶ_ｌａｓｔ及びＶ_ｍａｘ以下とする。解凍装置は、Ｖ_ｌａｓｔに最も近い値である解凍値を用いてヘッダの解凍を行ためにＶ_ｌａｓｔを使用する。上記最も近い値のｋ最下位ビットは上記圧縮値に一致する。圧縮用コンテキスト構成部は、圧縮用コンテキスト構成部が（Ｖ_ｍｉｎ，Ｖ_ｍａｘ）の一対の値であるため、解凍用コンテキスト構成部とは異なる。これに対して、解凍用コンテキスト構成部は単一のｖａｌｕｅ_Ｖ_ｌａｓｔである。この場合、解凍用コンテキスト構成部は、（Ｖ_ｍｉｎ，Ｖ_ｍａｘ）を選択することにより圧縮用コンテキスト構成部から導き出すことが可能である（但し、Ｖ_ｍｉｎ＝Ｖ_ｍａｘ＝Ｖ_ｌａｓｔ）。

図１４−１７は、圧縮及び解凍用コンテキスト情報と識別子とに関連する符号化技法の利用を要約するテーブルである。

タイマと基準値に基づく実施態様
Ａ．概観
タイマと基準値に基づく実施態様は、以下の（１）及び（２）の観察に基づくものである。（１）ＲＴＰソースで生成された場合、ＲＴＰタイム・スタンプはパケット間の経過時間の線形関数と相関する。（２）ＲＴＰ ＴＳは式ＴＳ０＋ｉｎｄｅｘ＊ＴＳ ｓｔｒｉｄｅで表される。但し、ＴＳ０とＴＳ ｓｔｒｉｄｅは定数であり、ｉｎｄｅｘは整数である（本明細書では以後このｉｎｄｅｘをパックされたＲＴＰ ＴＳと呼ぶことにする）。したがって、正常動作時に、解凍装置で受信されたＲＴＰタイム・スタンプも連続的に増分するタイマと相関することになり、その場合、ソースと解凍装置間の累積ジッタにより生じる歪みが発生する。累積ジッタには、“ネットワーク”ジッタ（ソースと圧縮装置間のジッタ）と、“無線”ジッタ（圧縮装置と解凍装置間のジッタ）とが含まれるため、観察されたネットワーク・ジッタに無線ジッタの上限値を加算することにより、圧縮装置は累積ジッタの上限値の計算が可能となる。次いで、圧縮装置によって、圧縮されたＲＴＰ ＴＳとしてパックされたＲＴＰ ＴＳの“ｋ”最下位ビットが単に送信される。解凍装置ではまず近似値が計算され、次いで、圧縮されたＲＴＰ ＴＳ内の上記情報を用いてこの近似値を微調整することによりＲＴＰ ＴＳの解凍が行われ、正確な値が決定される。前回解凍されたヘッダを受信したときからの経過時間に比例する値を前回解凍されたヘッダのＲＴＰ ＴＳに加算することにより上記近似値が得られる。ＲＴＰ ＴＳの正確な値は上記近似値に最も近い値として計算される。対応するパックされたＲＴＰ ＴＳの上記最も近い値のｋ最下位ビットは上記圧縮されたＲＴＰ ＴＳに一致する。圧縮装置は、累積ジッタの上限値に基づいて、解凍装置が正しく解凍を行うことが可能になるような許される最小値として値ｋを選択する。

Ｂ．音声の場合
まず、タイマと基準値に基づく実施態様について音声との関連で説明する。一例として、連続音声サンプル間の時間間隔が２０ミリ秒の場合、ヘッダｎのＲＴＰタイム・スタンプ（時刻ｎ＊２０ミリ秒に生成された）＝ヘッダ０のＲＴＰタイム・スタンプ（時刻０に生成された）＋ＴＳ ｓｔｒｉｄｅ＊ｎとなる（但し、ＴＳ ｓｔｒｉｄｅは音声コーデックに依存する定数であり、Ｔミリ秒毎のＲＴＰ ＴＳ増分値である）。したがって、解凍装置の中へ入ってくるヘッダ内のＲＴＰ ＴＳは、時間の関数として調整された線形パターンにも従う。但し、ソースと解凍装置間の遅延ジッタに起因して厳密に従うものではない。正常動作時（クラッシュや故障が存在しない場合）には、実時間通話トラフィックの要件を満たすために遅延ジッタに制限が設けられる。

本実施態様では、解凍装置でタイマが使用され、現時点のヘッダ（解凍対象ヘッダ）のＲＴＰ ＴＳの近似値が取得され、次いで、圧縮ヘッダで受信した追加情報によりこの近似値の微調整が行われる。

例えば、以下のように仮定する：
Ｌａｓｔ ｈｅａｄｅｒは最後に解凍に成功したヘッダである。但し、ＴＳ ｌａｓｔは最後のＲＴＰ ＴＳであり、ｐ ＴＳ ｌａｓｔは（解凍装置で）最後にパックされたＲＴＰ ＴＳである。
Ｔは、２つの連続音声サンプル間の通常の時間間隔である。
ＴＳ ｓｔｒｉｄｅはＴミリ秒毎のＲＴＰ ＴＳの増分値である。
ｃｕｒｒｅｎｔ_ｈｅａｄｅｒは解凍対象の現時点のパケットのヘッダである。但し、ＴＳ_ｃｕｒｒｅｎｔは現時点のＲＴＰ ＴＳであり、ｐ_ＴＳ_ｃｕｒｒｅｎｔは現時点のパックされたＲＴＰ ＴＳである。

ＲＦＨは、圧縮装置から肯定応答を受信したヘッダのシーケンス番号である。但し、ＴＳ_ＲＦＨはＲＴＰ ＴＳであり、ｐ_ＴＳ_ＲＦＨはパックされたＲＴＰ ＴＳである。

タイマはＴミリ秒毎に増分されるタイマである。但し、圧縮装置と解凍装置の双方は各々そのＴｉｍｅｒ（Ｓ_ｔｉｍｅｒとＲ_ｔｉｍｅｒでそれぞれ示され、タイマ１１３と１３４であってもよい）を保持する。

Ｔ_ＲＦＨはＲＦＨを受信したときのＴｉｍｅｒの値であり、Ｔ_ｃｕｒｒｅｎｔはＣｕｒｒｅｎｔ_ｈｅａｄｅｒを受信したときの同じＴｉｍｅｒの値である。
Ｎ_ｊｉｔｔｅｒ（ｎ，ｍ）は、ヘッダｍを基準として観察されたヘッダｎのネットワーク・ジッタである（ヘッダｎはヘッダｍに後続して受信される）。
但し、Ｎ_ｊｉｔｔｅｒ（ｎ，ｍ）は圧縮装置により以下のように計算される：
Ｎ_ｊｉｔｔｅｒ（ｎ，ｍ）＝Ｔｉｍｅｒ（ｎ，ｍ）−（ヘッダｎのパックされたＲＴＰ ＴＳ−ヘッダｍのパックされたＲＴＰ ＴＳ）
但し、Ｔｉｍｅｒ（ｎ，ｍ）は、Ｔミリ秒の単位で表されるヘッダｍからヘッダｎへの経過時間である。Ｎ_ｊｉｔｔｅｒ（ｎ，ｍ）は正または負の値をとり得る。圧縮装置におけるＮ_ｊｉｔｔｅｒは、Ｔミリ秒の単位で量子化されたネットワーク・ジッタである。

Ｒ_ｊｉｔｔｅｒ（ｎ，ｍ）は、圧縮装置により予測されるヘッダｍを基準とするヘッダｎの無線ジッタである。Ｒ_ｊｉｔｔｅｒは圧縮装置−解凍装置チャネル（ＣＤ−ＣＣ）の特性により決められる。Ｒ_ｊｉｔｔｅｒの正確な計算を行う必要はない。Ｒ_ｊｉｔｔｅｒの十分な上限値があれば十分である。例えば、既知であれば、上限値としてＭａｘ−Ｒ_ｊｉｔｔｅｒ（ＣＤ−ＣＣでの最大ジッタ値）を用いてもよい。

したがって、上述の仮定により、パケットの累積ジッタは、以下のようにネットワーク・ジッタと無線ジッタの和として計算される：
Ｊｉｔｔｅｒ（ｎ，ｍ）＝Ｎ_ｊｉｔｔｅｒ（ｎ，ｍ）＋Ｒ_ｊｉｔｔｅｒ（ｎ，ｍ）
さらにＲＴＰ ＴＳは以下のように計算される：
ＲＴＰ ＴＳ＝ＴＳ０＋ｉｎｄｅｘ*ＴＳ_ｓｔｒｉｄｅ、
但し、ＴＳ０＜ＴＳ_ｓｔｒｉｄｅであり、ｉｎｄｅｘは整数とする。
したがって、ＴＳ_ｌａｓｔ＝ＴＳ０＋ｉｎｄｅｘ_ｌａｓｔ＊ＴＳ_ｓｔｒｉｄｅ、かつ，ＴＳ_ｃｕｒｒｅｎｔ＝ＴＳ０＋ｉｎｄｅｘ_ｃｕｒｒｅｎｔ＊ＴＳ_ｓｔｒｉｄｅ

１．圧縮装置
圧縮装置は、ｐ_ＴＳ_ｃｕｒｒｅｎｔのｋ最下位ビットを圧縮ヘッダの形で送信する。
圧縮装置はｋを決定するために以下のアルゴリズムを実行する：
Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒを計算する。
Ｊ１＝Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒ＋Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒ＋Ｊを計算する。

但し、Ｊ＝２は、圧縮装置と解凍装置においてＴｉｍｅｒにより生じる量子化によるエラーを考慮する係数であり、このエラー値は＋１または−１の値をとる可能性がある。

以下の条件を満たす最小の整数ｋを見つける：
（２＊Ｊ１＋１）＜２ｋ
圧縮装置におけるネットワーク・ジッタは３つの異なる方法に従って計算が可能であり、第１の方法は図１８時に、第２の方法は図１９に、第３の方法は図２０に例示されている。上記第２及び第３の方法について、それぞれ、オプション１及びオプション２として以下説明する。第１の方法はネットワーク・ジッタの計算に適している。しかし、圧縮装置におけるネットワーク・ジッタの好ましい計算方法は、オプション１及びオプション２として以下それぞれ説明する第２及び第３の方法である。

図１８に例示しているように、上記第１の方法に従って圧縮装置における特定のパケットについてネットワーク・ジッタは、直前のパケットと関連する情報を利用して計算される。したがって、例えば、パケット２（ｊ２）のネットワーク・ジッタは、パケット１と関連する情報を利用して計算され、パケット３（ｊ３）のネットワーク・ジッタは、パケット２と関連する情報を利用して計算され、パケット４（ｊ４）のネットワーク・ジッタは、パケット３と関連する情報を利用して計算され、パケット５（ｊ５）のネットワーク・ジッタは、パケット４と関連する情報を利用して計算される。

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

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

図１９に例示されているようなオプション１の第２の方法に従って、ジッタｊ３＝２、ジッタｊ４＝３及びジッタｊ５＝−１と仮定されば、パケット５に先行して、Ｎ_ｊｉｔｔｅｒ_ｍｉｎ＝２かつＮ_ｊｉｔｔｅｒ_ｍａｘ＝３となり、これに対して、パケット５では、Ｎ_ｊｉｔｔｅｒ_ｍｉｎ＝−１かつＮ_ｊｉｔｔｅｒ_ｍａｘ＝３となる。したがって、パケット５における最大（Ｍａｘ）ネットワーク・ジッタ＝Ｎ_ｊｉｔｔｅｒ_ｍａｘ−Ｎ_ｊｉｔｔｅｒ_ｍｉｎ＝４となる。したがって、パケット５のネットワーク・ジッタは４である。オプション１の方法に準拠するネットワーク・ジッタの計算式及びその計算式についての解説を以下行う。

現時点のパケットのネットワーク・ジッタは、以下のようなオプション１の方法に従って計算される：
Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ）＝（Ｔ_ｃｕｒｒｅｎｔ−Ｔ_ＲＦＨ）−（ｐ_ＴＳ_ｃｕｒｒｅｎｔ−ｐ_ＴＳ_ＲＦＨ）
Ｎ_ｊｉｔｔｅｒ_ｍａｘとＮ_ｊｉｔｔｅｒ_ｍｉｎを更新する。但しＮ_ｊｉｔｔｅｒ_ｍａｘはＭａｘ｛Ｎ_（ｊ，ＲＦＨ）｝として定義される（すべてのヘッダについて、ｊはＲＦＨから送信されたＲＦＨを含む）。Ｎ_ｊｉｔｔｅｒ_ｍｉｎは、Ｍｉｎ｛Ｎ_ｊｉｔｔｅｒ（ｊ，ＲＦＨ）｝として定義される（すべてのヘッダについて、ｊはＲＦＨから送信されたＲＦＨを含む）。

Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒ＝（Ｎ_ｊｉｔｔｅｒ_ｍａｘ）−（Ｎ_ｊｉｔｔｅｒ_ｍｉｎ）を計算する
Ｎ_ｊｉｔｔｅｒ_ｍａｘとＮ_ｊｉｔｔｅｒ_ｍｉｎは正または負の値をとり得るが、（Ｎ_ｊｉｔｔｅｒ_ｍａｘ）−（Ｎ_ｊｉｔｔｅｒ_ｍｉｎ）は正であることに留意されたい。

オプション２
オプション２の第３の方法用としてネットワーク・ジッタの計算に使用されるステップが、図２０に例示されている。オプション２では、特定のパケットにおけるネットワーク・ジッタは、関心対象パケットと、所定数の先行パケットの各々との間のジッタ計算値を用いて計算される。この所定数の先行パケットはウィンドウとして定義されるものであり、このようなウィンドウは任意の値とすることが可能である。図２０に例示されている例では、このウィンドウは４つの先行パケットを示す値を有する。ウィンドウは、例えば７パケットなどのような任意の別の値に設定することも可能である。さらに、このウィンドウは、例えば、最後の基準パケットからのパケット数に等しい値になるような設定も可能である。

図２０に例示のように、パケット５用のネットワーク・ジッタは、パケット１、ｊ（５，１）、パケット２、ｊ（５，２）、パケット３、ｊ（５，３）、パケット４、ｊ（５，４）に関する情報を用いて計算される。図２０に例示されているように、各パケットに関連するパケット５について計算されるネットワーク・ジッタが、パケット１がｊ（５，１）＝−２、パケット２がｊ（５，２）＝３、パケット３がｊ（５，３）＝４、パケット４がｊ（５、４）＝７である場合、Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒ＝７となる。オプション２の第３の方法及びその記述に従うネットワーク・ジッタの計算式を以下に記載する。

現時点のパケットのネットワーク・ジッタは、オプション２の方法に従って以下のように計算される：
現時点のヘッダ前に送信され、かつ、ウィンドウＷに属するすべてのヘッダｊについて、Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ｊ）＝（Ｔ_ｃｕｒｒｅｎｔ-Ｔ_ｊ）−（ｐ_ＴＳ_ｃｕｒｒｅｎｔ−ｐ_ＴＳ_ｊ）を計算する。但し、Ｔ_ｊはヘッダｊ受信時のタイマ値であり、ｐ_ＴＳ_ｊはヘッダｊのパックされたＲＴＰ ＴＳである。

ウィンドウＷ内のすべてのｊについて、Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒ＝｜Ｍａｘ_Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ｊ）｜を計算する。

解凍装置から得られるフィードバック情報が利用可能な場合、ウィンドウＷには、最後のヘッダ（確認応答などによって、正しく受信されたことがわかっている）から送信されたヘッダが含まれる。フィードバック情報が存在しない場合には、ウィンドウＷには送信された最後のＬ個のヘッダが含まれる。但し、Ｌはパラメータである。

２．解凍装置
Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒのＲＴＰ ＴＳを解凍するために、解凍装置は、Ｌａｓｔ_ｈｅａｄｅｒが受信されてからの経過時間をＴミリ秒の単位で計算する。その時間、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，Ｌａｓｔ_ｈｅａｄｅｒ）にｐ_ＴＳ_ｌａｓｔが加算され、ｐ_ＴＳ_ｃｕｒｒｅｎｔの近似値が与えられる。次いで、解凍装置は、上記近似値に最も近い値を選択することによりｐ_ＴＳ_ｃｕｒｒｅｎｔの正確な値を計算する。この最も近い値のｋ最下位ビットは圧縮されたＲＴＰ ＴＳに一致する。ＴＳ_ｃｕｒｒｅｎｔは、ＴＳ０＋（ｐ_ＴＳ_ｃｕｒｒｅｎｔ）＊ＴＳ_ｓｔｒｉｄｅとして計算される。

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

３．正しさの証明
タイマ及び基準値に基づく実施態様の正しさを証明するため、以下のことが仮定されている：
Ａｐｐｒｏｘ_ＴＳは、ｐ_ＴＳ_ｌａｓｔ＋Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，Ｌａｓｔ_ｈｅａｄｅｒ）として解凍装置により計算されるｐ_ＴＳ_ｃｕｒｒｅｎｔの近似値である。

Ｅｘａｃｔ_ＴＳは、ｐ_ＴＳ_ｃｕｒｒｅｎｔの正確な値である。次いで、上記仮定に基づいて：
｜Ａｐｐｒｏｘ_ＴＳ−Ｅｘａｃｔ_ＴＳ｜≦｜Ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，Ｌａｓｔ_ｈｅａｄｅｒ）｜
圧縮装置におけるＭａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒの定義により、
｜Ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，Ｌａｓｔ_ｈｅａｄｅｒ）｜≦Ｊ１
但し、Ｊ１＝Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒ＋Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒ＋Ｊ
Ｊは、圧縮装置と解凍装置においてＴｉｍｅｒにより生じる量子化によるエラーを考慮して加算される係数である。したがって、Ｊ＝２で十分である。

したがって、以下の結果が得られる：
｜Ａｐｐｒｏｘ_ＴＳ−Ｅｘａｃｔ_ＴＳ｜≦Ｊ１
曖昧さのないＥｘａｃｔ_ＴＳの計算を行うためには、（２＊Ｊ１＋１）＜２ｋという条件が満たされるようにｋを選択すれば十分である。

４．圧縮装置の前のパケットの順序の間違いの場合
パケットの順序の間違いは、ＲＴＰシーケンス番号（ＲＴＰ_ＳＮ）を減らすことにより検出可能である。このパケットの順序の間違いが生じた場合、圧縮装置はＶＬＥなどの異なる方式を用いて、パックされたＲＴＰ ＴＳの符号化を行うことができる。解凍装置は、圧縮ヘッダ内の適切な表示ビットにより、この異なる符号化についての通知を受ける。

別のオプションとして、通常のＴｉｍｅｒ値と基準値とに基づくアルゴリズムの適用がある。パケットの順序の間違いにより、さらに大きなｋの値が結果として生じることが予想される。

５．アップリンク
無線システムでは、アップリンク方向の場合、ネットワーク・ジッタはゼロ（これは、ＲＴＰソースと圧縮装置の双方が無線端末装置内に配置されていることに起因する）であり、無線ジッタは、一般に、非常に小さな値になるように限界が設けられ、制御される。したがって、予想されるｋは非常に小さな定数となり、それによってヘッダ・サイズの変動が最小限になる。アップリンクの場合、端末装置は、ネットワークから広い帯域を通常要求しなければならないため、ヘッダ・サイズの変動が最小限になることは、帯域管理のために非常に有意義な利点である。さらに、パケットの順序の間違いが発生しない。したがって、タイマに基づくこの方式はアップリンク用として非常に好適である。

６．ダウンリンク
ダウンリンク方向の場合、ネットワーク・ジッタはゼロではなく、ジッタ全体が実時間要件を満たすように一般に小さな値となる。予想されるｋは小さな値のままとなり、通常定数である。さらに多くのｋの変動が生じる場合もあるが、ネットワークにより帯域の割当てが制御されるので、帯域管理は問題になる程のものではない。

７．ハンド・オフ
セルラー・システムでは、ＭＳからネットワークへの無線リンクと、ネットワークからＭＳへの無線リンクとが存在し、それぞれ、アップリンク及びダウンリンクとして表される。圧縮／解凍がセルラーリンクに適用されると、ＭＳベースの機能、ＭＳ_ＡＤ（ＭＳアダプタ）が起動し、この機能によりアップリンクとダウンリンク用の圧縮及び解凍がそれぞれ行われる。ＡＮＩ_ＡＤ（アクセス・ネットワーク・インフラ・ストラクチャ・アダプタ）と呼ばれるネットワーク・ベースのエンティティが存在し、このエンティティによりアップリンクとダウンリンク用の圧縮及び解凍がそれぞれ行われる。

考慮する特定のハンド・オフのケースは、ＡＮＩ_ＡＤ間ハンド・オフであり、その場合、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへの切替えにより生じる瞬断が発生する場合もある。問題となるのは、ハンド・オフ後、ＭＳ_ＡＤと新しいＡＮＩ_ＡＤにおける圧縮／解凍が瞬断を伴わずに続くように、ハンド・オフを通じてずっと情報の継続性を保持する方法である。

ハンド・オフを行うための、以下に説明する２つの代替方法が存在する。
ａ．第１の方法
第１の方法では、ＡＮＩ_ＡＤとＭＳ_ＡＤとの間で交換されるコンテキスト情報の前述のスナップ・ショットがハンドシェイク法を用いて利用される。ＲＴＰ ＴＳ用として、上記コンテキスト情報には、基準ヘッダの全ＲＴＰ ＴＳが含まれる。ハンド・オフの直後に、圧縮装置（アップリンク用ＭＳ_ＡＤと、ダウンリンク用ＡＮＩ_ＡＤ）は、タイマ・ベースの方式の利用を一時的に中断し、基準値と関連して圧縮されたＲＴＰ ＴＳの送信を行う。いったん肯定応答が受信された場合、圧縮装置はＲＦＨとして確認応答を受けた値を使用し、元のタイマ・ベースの方式へ切替えを行う。

ｂ．第２の方法
第２の方法では、ハンド・オフの両端にわたってタイマ・ベースの実施態様が利用される。

ｉ．ダウンリンク
ＭＳである受信機側には中断は生じない。圧縮装置の役割は１つのＡＮＩ_ＡＤから別のＡＮＩ_ＡＤへ転送される。ハンド・オフ後、古いＡＮＩ_ＡＤの代わりに新しいＡＮＩ_ＡＤの中を貫通する新しいパスでヘッダの経路指定が行われる。

圧縮装置
古いＡＮＩ_ＡＤにより、以下の情報のスナップ・ショット、すなわち、Ｔ_ＲＦＨ、ｐ_ＴＳ_ＲＦＨ、Ｓ_ｔｉｍｅｒの現在値、ＴＳ０及びＴＳ_Ｓｔｒｉｄｅのスナップ・ショットがハンドシェイク法を用いて新しいＡＮＩ_ＡＤへ転送される（スナップ・ショット値はＴ_ＲＦＨ＊のようなアスタリスク（＊）付きで表示される）。新しいＡＮＩ_ＡＤは、古いＡＮＩ_ＡＤから受信したＳ_ｔｉｍｅｒの現在値を用いて、新しいＡＮＩ_ＡＤのＳ_ｔｉｍｅｒの初期化を行い、Ｔミリ秒毎にこのタイマの増分を開始する。古いＡＮＩ_ＡＤのＳ_ｔｉｍｅｒの現在値を用いるＳ_ｔｉｍｅｒの初期化は概念的記述である。多数のフローにより共有される単一のＳ_ｔｉｍｅｒが存在する場合、実際のＳ_ｔｉｍｅｒの再初期化が行われることはない。代わりにＳ_ｔｉｍｅｒと古いＡＮＩ_ＡＤから得られる値との間のオフセット値が記録される。このオフセット値は将来の計算時に考慮される。ハンド・オフ後、一番最初のヘッダを圧縮するために、新しいＡＮＩ_ＡＤによりｐ_ＴＳ_ｃｕｒｒｅｎｔのｋ最下位ビットの送信が行われる。上記新しいＡＮＩ_ＡＤにより、使用ビット数ｋの計算が以下のように行われる：
Ｊ２＝Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ,ＲＦＨ＊）の上限値＋Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒ＋Ｊ
但し、ｋは（２＊Ｊ２＋１）＜２ｋという条件を満たすように選択される。

上記では、Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒは、新しいＡＮＩ_ＡＤとＭＳ_ＡＤ間のセグメントに関する最大ジッタである。

Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）の上限値は以下のように計算される：
｜Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）−（ｐ_ＴＳ_ｃｕｒｒｅｎｔ−ｐ_ＴＳ_ＲＦＨ＊）｜＋Ｔ_ｔｒａｎｓｆｅｒ
但し、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）は（Ｔ_ｃｕｒｒｅｎｔーＴ_ＲＦＨ＊）である。
Ｔ_ｃｕｒｒｅｎｔは、Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ受信時の新しいＡＮＩ_ＡＤにおけるＳ_ｔｉｍｅｒの値である。
Ｔ_ＲＦＨは、古いＡＮＩ_ＡＤからの受信値である。
Ｔ_ｔｒａｎｓｆｅｒは、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ上記コンテキスト情報を転送するための、Ｔミリ秒の単位で表現される時間の上限値である。
Ｊ＝２

解凍装置
Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒのＲＴＰ ＴＳの解凍を行うために、解凍装置は、ＲＦＨを受信してからの経過時間をＴミリ秒の単位で計算する。その時間、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ）にｐ_ＴＳ_ＲＦＨが加算され、ｐ_ＴＳ_ｃｕｒｒｅｎｔの近似値が与えられる。次いで、解凍装置は、上記近似値に最も近い値を選択することによりｐ_ＴＳ_ｃｕｒｒｅｎｔの正確な値を計算する。上記近似値に最も近い値のｋ最下位ビットは圧縮されたＲＴＰ ＴＳに一致する。ＴＳ_ｃｕｒｒｅｎｔは、ＴＳ０＋（ｐ_ＴＳ_ｃｕｒｒｅｎｔ）＊ＴＳ_ｓｔｒｉｄｅとして計算される。

ＲＦＨを受信してからの経過時間は（Ｔ_ｃｕｒｒｅｎｔ-Ｔ_ＲＦＨ）として計算可能である。

ｉ．故障の場合
新しいＡＮＩ_ＡＤへ上記コンテキスト情報を適時に転送できない場合、新しいＡＮＩ_ＡＤは、肯定応答が受信されるまで全ＲＴＰ ＴＳの送信を行う。

ｉｉ．アップリンク
解凍装置の役割は１つのＡＮＩ_ＡＤから別のＡＮＩ_ＡＤへ転送される。圧縮装置はＭＳに固定されている。

解凍装置
古いＡＮＩ_ＡＤは、以下の情報のスナップ・ショット、すなわち、Ｔ_ＲＦＨ＊、ｐ_ＴＳ_ＲＦＨ＊、Ｒ_ｔｉｍｅｒ＊の現在値、ＴＳ０及びＴＳ_Ｓｔｒｉｄｅのスナップ・ショットをハンドシェイク法を用いて新しいＡＮＩ_ＡＤへ転送する。新しいＡＮＩ_ＡＤは、古いＡＮＩ_ＡＤ２から受信したＲ_ｔｉｍｅｒの現在値を用いて、そのＲ_ｔｉｍｅｒの初期化を行い、Ｔミリ秒毎にそのタイマの増分を開始する。古いＡＮＩ_ＡＤのＲ_ｔｉｍｅｒの現在値を用いるＲ_ｔｉｍｅｒの初期化とは、概念的記述にすぎない。多数のフローにより共有される単一のＲ_ｔｉｍｅｒが存在する場合、実際のＲ_ｔｉｍｅｒの再初期化が行われることはない。代わりにＲ_ｔｉｍｅｒと古いＡＮＩ_ＡＤから得られる値との間のオフセット値が記録される。このオフセット値は将来の計算時に考慮される。ハンド・オフ後、一番最初のヘッダを解凍するために、新しいＡＮＩ_ＡＤは、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ）を計算し、このＴｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ）にｐ_ＴＳ_ＲＦＨ＊を加算して、ｐ_ＴＳ_ｃｕｒｒｅｎｔの近似値を算出する。次いで、解凍装置は、上記近似値に最も近い値を選択することによりｐ_ＴＳ_ｃｕｒｒｅｎｔに対する正確な値を計算する。上記近似値に最も近い値のｋ最下位ビットは圧縮されたＲＴＰ ＴＳに一致する。ＴＳ_ｃｕｒｒｅｎｔは、ＴＳ０＋（ｐ_ＴＳ_ｃｕｒｒｅｎｔ）＊ＴＳ_ｓｔｒｉｄｅとして計算される。

Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ）は（Ｔ_ｃｕｒｒｅｎｔ−Ｔ_ＲＦＨ＊）として推定することができる。Ｔ_ｃｕｒｒｅｎｔは、Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ受信時のＲ_ｔｉｍｅｒの値である。

圧縮装置
ＭＳ_ＡＤはｐ_ＴＳ_ｃｕｒｒｅｎｔのｋ最下位ビットの送信を行う。ＭＳ_ＡＤは使用ビット数ｋの計算を以下のように行う。

ｋが（２＊Ｊ２＋１）＜２ｋの条件を満たすように選択されたとき、Ｊ２＝Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）＋Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒ＋Ｊの上限値を計算する。

ここで、Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒは、新しいＡＮＩ_ＡＤとＭＳ_ＡＤとの間でのセグメント上の最大ジッタである。

Ｎ_ｊｉｔｔｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）の上限値は、｜Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）−（ｐ_ＴＳ_ｃｕｒｒｅｎｔ−ｐ_ＴＳ_ＲＦＨ＊）｜＋Ｔ_ｔｒａｎｓｆｅｒとして計算される。

但し、Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）は（Ｔ_ｃｕｒｒｅｎｔ−Ｔ_ＲＦＨ＊）である。

Ｔ_ｃｕｒｒｅｎｔは、現時点のヘッダ受信時の新しいＡＮＩ_ＡＤでのＳ_ｔｉｍｅｒの値である。
Ｔ_ＲＦＨ＊は古いＡＮＩ_ＡＤからの受信値である。
Ｔ_ｔｒａｎｓｆｅｒは、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ上記コンテキスト情報を転送するための、Ｔミリ秒の単位で表現される時間の上限値であり、
Ｊ＝２である。

故障の場合
新しいＡＮＩ_ＡＤへ上記コンテキスト情報を適時に転送できない場合、新しいＡＮＩ_ＡＤは、ＭＳ_ＡＤに通知を行い、ＭＳ_ＡＤは肯定応答が受信されるまで全部のＲＴＰ ＴＳの送信を行う。

８．パフォーマンス
実時間通話要件に起因して、正常動作時の累積ジッタは、多くてＴミリ秒の数倍にすぎないと予想される。したがって、１６〜３２個までの音声サンプルのジッタの修正が可能なので、４乃至５ほどのｋの値で十分である。

本実施態様の利点は以下の通りである：
圧縮ヘッダのサイズは一定でかつ小さい。圧縮ヘッダには、メッセージのタイプ（ｋ１ビット）を示すメッセージ・タイプと、どのフィールドが変化しているかを示すビット・マスクと、ｉｎｄｅｘ_ｃｕｒｒｅｎｔのｋ最下位ビット（ｋビット）を含むフィールドとが一般に含まれる。４ビットＭＳＴＩビット・マスクとｋ１＝４が使用されると仮定すると、ＲＴＰ ＴＳが変化する場合（このケースが最も頻度が高い）の圧縮ヘッダのサイズは１.５バイトとなる。さらに、このサイズは無音間隔の長さの関数として変化しない。

タイマ処理と解凍処理との間の同期は必要なものではない。
圧縮ヘッダ内の部分的ＲＴＰ ＴＳ情報としての、エラーに対するロバスト性が自給され、解凍用タイマと組み合わされて、十分なＲＴＰ ＴＳ値がもたらされるようにする必要があるにすぎない。ヘッダの紛失あるいは破損に起因して後続する圧縮ヘッダが無効になることはない。

圧縮装置はメモリ情報を保持する必要がほとんどない：
オプション１では、Ｔ_ＲＦＨ、ｐ_ＴＳ_ＲＦＨ、Ｎ_ｊｉｔｔｅｒ_ｍａｘ、Ｎ_ｊｉｔｔｅｒ_ｍｉｎ、ＴＳ０、ＴＳ_Ｓｔｒｉｄｅ、及び、ウィンドウＷ内のすべてのｊについて｛Ｔ−ｊ，ｐ−ＴＳ−ｊ｝、さらに、オプション２では、ＴＳ_Ｓｔｒｉｄｅ

Ｃ．ジッタ削減
実時間通話要件に起因して、上述の様々なジッタは、正常動作時に数Ｔミリ秒のオーダーのものであることが当然予想される。しかし、ジッタがさらに大きくなり、したがってさらに大きなｋが必要となるケースを除外することはできない。例えば、ＲＴＰソースから受信機へのパスで異常事態（故障など）が生じ、その間ジッタが過大になる可能性がある。また、ｋの定数値が、所望の値または望ましい値であるケースが生じる場合もある。これらのケースに対処するために、フロント・エンドとして圧縮装置にジッタ削減機能を設けて過大なジッタ（或る閾値を上回るジッタ）を持つパケットをフィルターして取り除くようにすることも可能である。

（ハンド・オフが行われない）固定時のケースでは、ジッタはＪ１として計算され、以下のような固定閾値と比較される：
Ｊ１＝（Ｎ_ｊｉｔｔｅｒ_ｍａｘ-Ｎ_ｊｉｔｔｅｒ_ｍｉｎ）＋Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒ＋Ｊ
ハンド・オフの場合、ジッタはＪ２として以下のように計算され、ハンド・オフ閾値と比較される。

Ｊ２＝｜Ｔｉｍｅｒ（Ｃｕｒｒｅｎｔ_ｈｅａｄｅｒ，ＲＦＨ＊）−（ｐ_ＴＳ_ｃｕｒｒｅｎｔ−ｐ_ＴＳ_ＲＦＨ＊）｜＋Ｔ_ｔｒａｎｓｆｅｒ＋Ｍａｘ_ｒａｄｉｏ_ｊｉｔｔｅｒ＋Ｊ
ハンド・オフが行われない固定時のケースと関連する主な相違点として、Ｔ_ｔｒａｎｓｆｅｒの加算がある。実際には、ハンド・オフの実行を１００ミリ秒以内に可能にするためには、Ｔ_ｔｒａｎｓｆｅｒを約１００ミリ秒に制限する必要がある。従って、Ｔミリ秒の単位（Ｔ＝２０ミリ秒）では、Ｔ_ｔｒａｎｓｆｅｒ＝約５乃至６となる。ｋ＝５の値で十分である。

固定閾値とハンド・オフ閾値とは同じであってもよいし、同じでなくてもよい。

Ｄ．ビデオのケース
ＲＴＰのビデオ・ソースの場合、一定の時間間隔が存在することは必ずしも真であるとはかぎらない。ＲＴＰ ＴＳは、１つのパケットから次のパケットへ必ずしも一定のペース（stride）だけ増分するとはかぎらないからである。しかし、ＲＴＰ ＴＳ、及び、パケット間の時間間隔は離散的である。したがって、以下のようになる：
パケットのＲＴＰタイム・スタンプｍ＝（時刻０に生成された）パケット０のＲＴＰタイム・スタンプ＋ＴＳ_ｓｔｒｉｄｅ＊［ｉｎｄｅｘ＋ａｄｊｕｓｔ（ｍ）]
但し、ＴＳ_Ｓｔｒｉｄｅはコーデックに依存する定数であり、ａｄｊｕｓｔ（ｍ）は、ｍに依存し、音声の場合と同様、線形的振舞いと関連する差分を反映する。また、２つの連続するパケット間の時間間隔はＴミリ秒の倍数の整数となる。

以下では、ＲＴＰソースにおける上記振舞いは調整された線形的振舞いと呼ばれる。音声の場合と同じ表記法を使用すれば、ＴＳ_ｌａｓｔ＝ＴＳ０＋ＴＳ＋ｓｔｒｉｄｅ＊［ｉｎｄｅｘ_ｌａｓｔ＋ａｄｊｕｓｔ（ｉｎｄｅｘ_ｌａｓｔ）］、及び，ＴＳ_ｃｕｒｒｅｎｔ＝ＴＳ０＋ＴＳ_ｓｔｒｉｄｅ＊［ｉｎｄｅｘ_ｃｕｒｒｅｎｔ＋ａｄｊｕｓｔ（ｉｎｄｅｘ_ｃｕｒｒｅｎｔ）
Ａｄｊｕｓｔパラメータは正または負の値をとり得る。したがって、音声と比較した主な相違点として加算項Ａｄｊｕｓｔがある。

解凍装置の中へ入ってくるヘッダ内のＲＴＰ ＴＳは、時間の関数として調整された線形パターンにも従うが、これは、ソースと解凍装置間の遅延ジッタに起因して厳密なものではない。正常動作時（クラッシュや故障が存在しない場合）には、実時間通話トラフィックの要件を満たすために遅延ジッタに制限が設けられる。

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

圧縮装置
圧縮装置は、ｐ_ＴＳ_ｃｕｒｒｅｎｔのｋ最下位ビットを圧縮ヘッダで送信する。ｋの決定アルゴリズムは音声の場合と同じである。

解凍装置
使用アルゴリズムは音声の場合と同じである。
１．ハンド・オフ
音声について説明したハンド・オフの２つの代替方法がビデオについても同様に適用される。

２．ｋの値
音声の場合、ｋ＝４乃至５で十分である（２ｋ＝１６乃至３２）ことを示した。ビデオの場合には、Ａｄｊｕｓｔに起因してさらに大きなｋの値が必要となる。ビデオは毎秒３０個のフレームで構成されているため、｜Ａｄｊｕｓｔ｜＜３０となる。したがって、正常動作時にｋ＝７乃至８ビットで十分であることが望ましい。

ハンド・オフ実施態様の、タイマ・ベースの圧縮実施態様への適用
以下の記載は、タイマ・ベースの実施態様をＲＴＰ ＴＳの圧縮に利用する場合の様々なハンド・オフの実施態様の適用方法について解説するものである。

様々なハンド・オフ実施態様として以下のものがある：
ダウンリンク及びアップリンク・トラフィックでの、ハンドシェイクを伴うハンド・オフ（図８と９）
ダウンリンク及びアップリンク・トラフィックでの、ハンドシェイクを伴わないハンド・オフ（図１０と１２）
ダウンリンク及びアップリンク・トラフィックでの、ハンドシェイクを伴わないハンド・オフ（図と７）
タイマ・ベースの実施態様には以下のような３つのオプションがある：

オプション１
Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒは、（Ｎ_ｊｉｔｔｅｒ_ｍａｘ）−（Ｎ_ｊｉｔｔｅｒ_ｍｉｎ）として計算される。但し、Ｎ_ｊｉｔｔｅｒ_ｍａｘとＮ_ｊｉｔｔｅｒ_ｍｉｎとは、それぞれ、ウィンドウＷ内のすべてのヘッダｊについての、基準ヘッダのヘッダｊのジッタの最大値及び最小値である。ウィンドウＷは、基準ヘッダを含む、基準ヘッダの送信後に送信されたヘッダから構成される。基準ヘッダとは確認応答を受けたヘッダである。

オプション２
Ｍａｘ_ｎｅｔｗｏｒｋ_ｊｉｔｔｅｒは、ウィンドウＷに属するすべてのヘッダｊについて、ヘッダｊに対する現時点のヘッダのジッタの最大値として計算される。フィードバック情報があるか否かに応じて２つのサブオプションが存在する。

オプション２ａ：解凍装置からのフィードバック情報が存在する。Ｗは確認応答を受けた最後のヘッダを含む、該最後のヘッダ以来送信されたヘッダから構成される。

オプション２ｂ：解凍装置からフィードバック情報が存在しない。Ｗは最後のＬ個のヘッダから構成される。但しＬはパラメータである。

テーブル形式の図２１〜２６は本発明の実施態様の動作を例示するものである。

一例として、以下の技法が用いられるヘッダ圧縮の実施態様について考察する：
・ 固定フィールドを圧縮する暗黙の符号化技法
・ ＲＴＰ_ＳＮ及びＩＰ_ＩＤを圧縮する、フィードバック情報を利用する圧縮技法を用いるＶＬＥ
・ ＲＴＰ ＴＳを圧縮するタイマ・ベースのオプション２ａの圧縮技法
・ その他のフィールドのための直接符号化技法（すなわちその他のフィールドは圧縮されずにそのまま送信される）
圧縮用コンテキスト情報はＦＯコンテキスト情報及びＳＯコンテキスト情報である。順番に、各圧縮技法では圧縮用コンテキスト構成部が利用される。解凍用コンテキスト情報についても同じである。

図２７〜２８は、圧縮及び解凍用コンテキスト情報のそれぞれについて、ＦＯコンテキスト情報構成部及びＳＯコンテキスト情報構成部の要約を示すものである。

コンテキスト転送の最適化
本発明によるコンテキスト転送の最適化を示す実施態様が図２９に例示されている。図２９に例示のコンテキスト情報は、時と共に変化するＲタイマ及びＳタイマの値だけを持つ時間関連情報である。現時点のＲ_ｔｉｍｅｒあるいはＳ_ｔｉｍｅｒの値は、上記コンテキスト情報の中に含まれると、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ可能な限り短時間の内に転送されて、新しいＡＮＩ_ＡＤのタイマと、古いＡＮＩ_ＡＤのタイマとの間でいずれのスキューも最少化されることが望ましい。本実施態様では、Ｒ_ｔｉｍｅｒあるいはＳ_ｔｉｍｅｒの現時点の値はコンテキストの残り部分から別々に送信される。したがって、この値は、その他のコンテキスト情報と共に送信される場合よりも高速な転送が可能となる。時間関連のコンテキスト情報の残り部分はＴ_ＲＦＨ、ｐ_ＴＳ_ＲＦＨ、ＴＳ０及びＴＳ_Ｓｔｒｉｄｅである。本実施態様は、時間と関連するコンテキスト情報に加えて、古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへ送信される非時間関連のコンテキスト情報を用いて実施可能なものであると理解されたい。

古いＡＮＩ_ＡＤからの肯定応答の待機
図３０に例示されている本発明の別の実施態様は、アップリンク・トラフィックの場合の無線ハンド・オフ後に定義されるリロケーションのケースを表すものである。少なくとも１つの圧縮ヘッダ（１）が、ＭＳ_ＡＤから新しいＡＮＩ_ＡＤを介して古いＡＮＩ_ＡＤへ送信される。ＳＴ１で、古いＡＮＩ_ＡＤは、ＴＳ０とＴＳ_Ｓｔｒｉｄｅを含む、時間関連の解凍用コンテキスト構成部の第１の部分を新しいＡＮＩ_ＡＤへ送信する。この第１の部分は解凍用コンテキスト構成部のサブセットである。解凍用コンテキスト構成部のこの第１の部分は固定時間に関連する情報であり、この情報は、送信開始時を考慮することなく、あるいは、図２９に関して上述した実施態様の考慮事項である送信必要時間を考慮することなく送信が可能である。ＳＴ２で、新しいＡＮＩ_ＡＤはそのＲ_ｔｉｍｅｒを開始し、古いＡＮＩ_ＡＤへリレーされるすべての後続圧縮ヘッダのタイマ値を記録する（ヘッダのタイマ値とは、ヘッダ受信時のＲ_ｔｉｍｅｒの値である）。リレーされる各ヘッダは、新しいＡＮＩ_ＡＤにより割り当てられ、古いＡＮＩ_ＡＤへ送信されるＡＮＩ_ＡＤシーケンス番号［４］及び［５］と関連づけられる。ＳＴ３及びＳＴ４で記録された到着タイマ値（Ｔ-３及びＴ-４）を持つ複数の圧縮ヘッダ（３）及び（４）がＭＳ_ＡＤから新しいＡＮＩ_ＡＤへ送信される。圧縮ヘッダ（３）及びシーケンス番号（４）（このシーケンス番号（４）はＲＴＰシーケンス番号ではない）に応じて、古いＡＮＩ_ＡＤは、圧縮ヘッダ（３）を解凍し、パックされたタイム・スタンプｐ_ＴＳ_３と、シーケンス番号（４）とを含むフィードバック情報を肯定応答の形で新しいＡＮＩ_ＡＤへ送信する。ＳＴ５で、新しいＡＮＩ_ＡＤはシーケンス番号（４）を利用して、パケットのタイム・スタンプをヘッダと相関づけ、パケットのこのタイム・スタンプ値をタイマ値と関連づける。これによって解凍用コンテキスト情報構成部の第２の部分とサブセットとが創成され、完全な解凍用コンテキスト情報構成部が得られる。新しいＡＮＩ_ＡＤは、上記のようにして得られる格納された完全な解凍用コンテキスト構成部を利用して、ＳＴ５後に受信された圧縮ヘッダの解凍を行う。

本実施態様にはいくつかの利点がある。古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへの上記コンテキスト情報のリロケーションには切れ目が生じない。タイマ値（Ｒ_ｔｉｍｅｒまたはＳ_タイマの現在値）の送信を行う必要がない。本実施態様は、ヘッダ圧縮方式が肯定応答ベースであるか否かに拘らずすべてのケースで機能する。オプション２ｂでは、新しいＡＮＩ_ＡＤは、ＡＮＩ_ＡＤのシーケンス番号とタイム・スタンプとを肯定応答から取り除いた後、肯定応答をＭＳ_ＡＤへリレーすることができる。

オプション１と２ａでは、新しいＡＮＩ_ＡＤは、肯定応答からそのＡＮＩ_ＡＤのシーケンス番号とパケットのＲＴＰ ＴＳとを取り除き、その結果をＭＳ_ＡＤへリレーする。

ＭＳ_ＡＤからの肯定応答の待機
ＭＳ_ＡＤからの肯定応答の待機を示す実施態様が図３１に例示されている。ＳＴ１で、ＴＳ０とＴＳ_Ｓｔｒｉｄｅとから成るコンテキスト情報構成部が送信される。ＳＴ２の新しいＡＮＩ_ＡＤにより、そのＳ_ｔｉｍｅｒが始動され、ＭＳ_ＡＤへリレーされたすべての圧縮ヘッダのタイマ値とＲＴＰ ＴＳとが記録される（ヘッダのタイマ値とは、ヘッダ受信時のＳ_ｔｉｍｅｒの値である）。量ＲＴＰ ＴＳとＲＴＰ_ＳＮとは元の未圧縮ヘッダからＭＳ_ＡＤにより取り出される。その後、新しいＡＮＩ_ＡＤがＭＳ_ＡＤから肯定応答（６）を受信し、この肯定応答（６）が新しいＡＮＩ_ＡＤによりリレーされたヘッダに関係づけられると、ＳＴ４の新しいＡＮＩ_ＡＤにより、肯定応答（６）がリレーされ、ＲＦＨ以後リレーされたヘッダのウィンドウを用いて圧縮が開始される。ＲＦＨとは確認応答を受けたヘッダである。オプション１では、上記時間関連のコンテキスト情報構成部には（ｐ_ＴＳ_ＲＦＨ，Ｔ_ＲＦＨ，Ｎ_ｊｉｔｔｅｒ_ｍａｘ，Ｎ_ｊｉｔｔｅｒ_ｍｉｎ，ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）が含まれる。オプション２では、上記時間関連のコンテキスト情報構成部には｛ウィンドウＷ内のすべてのヘッダｊについての（ｐ_ＴＳ_ｊ，Ｔ_ｊ），ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ｝が含まれる。量ｐ_ＴＳ_ｊとＴ_ｊはヘッダｊのＲＴＰ ＴＳとタイマ値である。

ウィンドウ・フルの待機
図３２の実施態様は、新しいＡＮＩ_ＡＤが、圧縮開始が可能になる前に、（肯定応答を待機するのではなく）Ｌ個のリレーされたヘッダを待機しているという点を除けば、図３１のＭＳ_ＡＤからの肯定応答の待機の実施態様と同じである。ウィンドウＷは、新しいＡＮＩ_ＡＤがヘッダ（６）、（７）、（８）、（９）をリレーするにつれて徐々に構成され、ＲＴＰ ＴＳパケット値ｐ_ＴＳ_６、ｐ_ＴＳ_７、ｐ_ＴＳ_８、ｐ_ＴＳ_９とタイマ値Ｔ_６、Ｔ_７、Ｔ_８、Ｔ_９を記録する。時間関連部分である上記コンテキスト情報の圧縮には｛ウィンドウＷ内のすべてのヘッダｊについての（ｐ_ＴＳ_ｊ，Ｔ_ｊ），ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ｝が含まれる。量ｐ_ＴＳ_ｊとＴ_ｊは、ヘッダｊについてのＲＴＰ ＴＳとタイマ値である。本実施態様は、上記実施態様と同じ利点を持つものであり、ヘッダ圧縮が肯定応答ベースのものではない場合に機能する。

ウィンドウ管理
図３３と３４には、ウィンドウ管理を利用する実施態様が例示されている。この実施態様はダウンリンクとアップリンクに対して適用可能である。本実施態様では、無線ハンド・オフの直後に新しい圧縮装置が作動する。無線リンクは、送信中１以上のパケットが時々紛失するように動作すると想定されている。上記新しい圧縮装置は、初期化されたウィンドウがいくつかの要素を持っている状態で始動する。新しく圧縮された各ヘッダがこのウィンドウに追加され、Ｌ個のヘッダが送信されるまでＣＣ_Ｄ_Ｉｄと共に送信される。Ｌ個の無線パケットを送信する場合、このウィンドウのサイズは、当該パケットの受信時に少なくとも１つの無線パケットが受信されること、及び、解凍装置が時間に関連するその解凍用コンテキスト情報の更新が可能であることが保証されるように選択される。ウィンドウは、最も最近送信されたＬ個のヘッダとＣＣ_Ｄ_ＩＤだけを含むようにリセットされ、これらはそれ以上は送信されなくなる。その後、圧縮装置は、次の各送信パケットを用いて、圧縮装置の圧縮用コンテキスト情報の更新を行う。本実施態様はフィードバック情報なしで機能するものである。

図３５は、ヘッダのＶＬＥと時間関連の圧縮とを含む本発明の実施態様を例示する。図３５は、図８と図３１とを組み合わせたものである。

ＳＴ１で、古いＡＮＩ_ＡＤにより送信される圧縮用コンテキストは、ＳＯ圧縮用コンテキスト情報と（ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）とのサブセットである。ＳＴ４で、ＶＬＥのコンテキスト情報構成部は、ヘッダ（６）のＲＴＰ_ＳＮのＶ_ｍｉｎ＝Ｖ_ｍａｘ_ｖａｌｕｅと、ヘッダ（６）のＩＰ_ＩＤのＶ_ｍｉｎ＝Ｖ_ｍａｘ＝ｖａｌｕｅとして確定される。タイマのコンテキスト情報構成部は（ｐ_ＴＳ_６，Ｔ_６，ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ，Ｓ_ｔｉｍｅｒの値）として確定される。

図３６は、ＶＬＥとヘッダの時間関連解凍とを組み合わせた本発明の実施態様を例示するものである。図３６は図１０と図３０との組合せを例示する。ＳＴ１で、古いＡＮＩ_ＡＤにより送信された解凍用コンテキスト情報は、ＳＯの解凍用コンテキスト情報と、ＶＬＥ用解凍用コンテキスト情報構成部と、（ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）とのサブセットである。ＳＴ４で、古いＡＮＩ_ＡＤは解凍用コンテキスト情報（ｐ_ＴＳ_３）の別のサブセットを肯定応答の形で送信する。新しいＡＮＩ_ＡＤにより（ｐ_ＴＳ３，Ｔ_３）はタイマのコンテキスト解凍用情報構成部に追加される。新しいＡＮＩ_ＡＤは、肯定応答からＡＮＩ_ＡＤシーケンス番号を取り除き、この肯定応答をＭＳ_ＡＤへリレーすることが可能となる。

古いＡＮＩ_ＡＤが圧縮ヘッダの送信を停止する時点は、例えばＳＴ２や通信（新しいＡＮＩ_ＡＤからの通知など）の受信後のような時点であってもよい。さらに、新しいＡＮＩ_ＡＤは、解凍用コンテキスト情報（ＳＴ２など）の転送後いつでも解凍を開始してもよい。

アップリンクとダウンリンクでは、多くの可能な変形例が可能である。特に：
解凍用コンテキスト情報は必ずしも古いＡＮＩ_ＡＤから直接到来する必要はない。解凍用コンテキスト情報は、上記情報を保持するいずれのエンティティからでも到来が可能である。さらに、たとえコンテキストが古いＡＮＩ_ＡＤから到来したものであっても、解凍用コンテキスト情報は別のノード／エンティティの中を通って推移するものであってもよい。

古いＡＮＩ_ＡＤから新しいＡＮＩ_ＡＤへの（ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）の転送は、必ずしも、ＳＴ１で行われるとはかぎらない。この転送は、上記情報が新しいＡＮＩ_ＡＤにより受信されるならば、ＡＮＩ_ＡＤによる解凍開始前のいつでも行うことが可能である。

転送された情報は（ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）である必要はない。パックされたＴＳと同等の何らかの情報（元のＲＴＰ ＴＳまたはこのＲＴＰ ＴＳの何らかの機能）の利用が可能である。この情報は“タイム・スタンプ同等情報”と呼ばれる。パックされたＲＴＰ ＴＳとは異なるものを使用する場合、ＳＴ１で、（ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）の代わりに何らかの別の情報を送信することも可能である。ＳＴ１で送信された上記情報は、元のＲＴＰ ＴＳとタイム・スタンプ同等情報との間の変換に利用される。

ダウンリンク環境においてのみ、古いＡＮＩ_ＡＤが返送する圧縮ヘッダと肯定応答と共に、ＳＴ３で新しいＡＮＩ_ＡＤにより送信されるＡＮＩ_ＡＤシーケンス番号は、タイム・スタンプ同等情報のヘッダとの相関づけを新しいＡＮＩ_ＡＤに可能にさせるメカニズムのほんの一例にすぎない。別のメカニズムも可能である。

本発明についてその推奨実施態様と関連して解説してきたが、本発明の精神と範囲から逸脱することなく、本発明に対する多くの修正が可能であると理解されたい。例えば、時間関連または非時間関連の一般的情報内容を持つコンテキスト情報と関連して本発明について解説してきたが、解説のような本発明の実施態様はいずれかの特定タイプのコンテキスト情報の転送に限定されるものではないと理解されたい。パックされたＲＴＰ ＴＳの代わりに元のＲＴＰ ＴＳを用いる場合、（ＴＳ０，ＴＳ_Ｓｔｒｉｄｅ）の転送は必要ではない。かかる修正のすべては添付の請求項の範囲内に属するものとする。

スナップ・ショット後のコンテキスト情報の更新によって生じる古くなったコンテキスト情報という従来技術の問題を例示する。 本発明の実施が可能な例示のシステムを例示する。 圧縮用コンテキスト情報を概念的に例示する。 解凍用コンテキスト情報を概念的に例示する。 信号の待ち時間によって生じる古くなったコンテキスト情報という問題を例示する。 ダウンリンク・トラフィック時の本発明の実施態様の動作を例示する。 アップリンク・トラフィック時の本発明の実施態様の動作を例示する。 ダウンリンク・トラフィック時の本発明の実施態様の動作を例示する。 本発明の実施態様のフィードバックが移動解凍装置から生じる場合の、ダウンリンク・トラフィックの場合の動作を例示する。 アップリンク・トラフィック時の本発明の実施態様の動作を例示する。 ダウンリンク・トラフィックの場合の本発明の実施態様の動作を例示する。 アップリンク・トラフィックの場合の１実施態様を例示する。 コンテキスト情報を特定するために数値順索引を利用する方法を示す一例を例示する。 ダウンリンク・トラフィックの場合の本発明によるコンテキスト情報の利用を例示するテーブルである。 アップリンク・トラフィックの場合の本発明によるコンテキスト情報の利用を例示するテーブルである。 ダウンリンク・トラフィックの場合の本発明によるコンテキスト情報の利用を例示するテーブルである。 アップリンク・トラフィックの場合の本発明によるコンテキスト情報の利用を例示するテーブルである。 第１の方法に従ってネットワーク・ジッタの計算ステップを例示する図である。 オプション１である第２の方法に従ってネットワーク・ジッタの計算を行うステップを例示する図である。 オプション２である第３の方法に従ってネットワーク・ジッタの計算を行うステップを例示する図である。 本発明によるコンテキスト情報の利用を要約するテーブルである。 本発明によるコンテキスト情報の利用を要約するテーブルである。 本発明によるコンテキスト情報の利用を要約するテーブルである。 本発明によるコンテキスト情報の利用を要約するテーブルである。 本発明によるコンテキスト情報の利用を要約するテーブルである。 本発明によるコンテキスト情報の利用を要約するテーブルである。 本発明による圧縮と解凍を行うための符号化用ＦＯ及びＳＯコンテキスト情報を要約する。 本発明による圧縮と解凍を行うための符号化用ＦＯ及びＳＯコンテキスト情報を要約する。 本発明によるコンテキスト転送の最適化を例示する。 古いＡＮＩからの肯定応答を待つ本発明の実施態様を例示する。 ＭＳからの肯定応答を待つ本発明の実施態様を例示する。 ウィンドウ・フルの実施態様の待機を例示する。 ウィンドウ管理を利用する本発明の実施態様を例示する。 ウィンドウ管理を利用する本発明の実施態様を例示する。 複数のタイプのコンテキスト情報を含む、ダウンリンク時及びアップリンク時のそれぞれの本発明の実施態様を例示する。 複数のタイプのコンテキスト情報を含む、ダウンリンク時及びアップリンク時のそれぞれの本発明の実施態様を例示する。

Claims (6)

1. 圧縮ヘッダを持つパケットの送信を行うパケット・ネットワークにおける通信方法において、
   第１のネットワーク・ノードと第２のネットワーク・ノードとの間の接続を確立するステップであって、上記第１のネットワーク・ノードと上記第２のネットワーク・ノードにおけるパケットのヘッダの圧縮と解凍に利用されるコンテキスト情報の格納を含むステップと、
   上記第１のネットワーク・ノードと上記第２のネットワーク・ノードとの間の接続を上記第２のネットワーク・ノードと第３のネットワーク・ノードとの間の接続へ変更するステップであって、上記第１のネットワーク・ノードにより格納され、次いで、上記第３のネットワーク・ノードのコンテキスト情報として上記第３のネットワーク・ノードにより格納される上記コンテキスト情報を上記第３のネットワーク・ノードへ移動解凍装置がハンド・オフされる時点に転送し、上記第３のネットワーク・ノードから上記移動解凍装置への送信の同期を維持するために、上記第３のネットワーク・ノードに格納された上記コンテキスト情報を用いて圧縮されたヘッダと上記コンテキスト情報の複数の識別子とを持つ複数のパケットを上記第３のネットワーク・ノードから上記移動解凍装置へ送信し、上記複数の識別子のうちの少なくとも１つの識別子の受信に応答して上記移動解凍装置から上記第３のネットワーク・ノードへ少なくとも１つのフィードバック情報を送信し、上記フィードバック情報の受信に応答して上記第３のネットワーク・ノードにより該第３のネットワーク・ノードに格納された上記コンテキスト情報を更新し、上記第２及び第３のネットワーク・ノードにおいて上記パケットのヘッダの圧縮と解凍を行うために、上記第２のネットワーク・ノードと上記第３のネットワーク・ノードに格納された上記コンテキスト情報を利用することを含むステップと、を有することを特徴とする方法。
2. 請求項１に記載の方法において、上記識別子はシーケンス番号であることを特徴とする方法。
3. 請求項２に記載の方法において、上記シーケンス番号が、上記第３のネットワーク・ノードに格納された上記コンテキスト情報を最後に更新したパケットの識別番号であることを特徴とする方法。
4. 請求項３に記載の方法において、上記第３のネットワーク・ノードに格納された上記コンテキスト情報を用いて圧縮されたヘッダを持つ上記複数のパケットのうちの少なくとも１つのパケットは、上記第１のネットワーク・ノードから受信した未圧縮のパケット・ヘッダを持つ少なくとも１つのパケットから形成されたもの、あるいは、上記第１のネットワーク・ノード以外のソースから受信した未圧縮のヘッダを持つ少なくとも１つのパケットから形成されたものであることを特徴とする方法。
5. 請求項１乃至４のいずれかに記載の方法において、上記第１のネットワーク・ノードから上記第３のネットワーク・ノードへ送信される上記コンテキスト情報は、時間関連のコンテキスト情報構成部を有することを特徴とする方法。
6. 請求項５に記載の方法において、前記時間関連のコンテキスト情報構成部は、少なくとも１つの前回のパケットのタイム・スタンプと到着時のうちの少なくとも一方に関連する要素を含むことを特徴とする方法。

Images