Suppression of the header in a wireless communication network

インターネットプロトコル（ＩＰ）は、有線ネットワークと無線ネットワークの両方において主要な転送プロトコルとなり、電気通信ネットワーク及びデータネットワークの集中をもたらした。 多くのサービス及びアプリケーション（例えばＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）、双方向ゲーム、インスタントメッセージングなど）では、ＩＰパケットのペイロードはヘッダとほぼ同じサイズか又はそれよりもさらに小さい。 パケットデータネットワークにおいて効率的な転送を行うために、ＩＰネットワークのプロトコルに加えて他のプロトコル（例えばリアルタイムプロトコル（ＲＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）など）が、元の情報ビットに付加される。

幸いにも、常にパケットごとに膨大なＲＴＰ／ＵＤＰ／ＩＰのヘッダを送信する必要はない。 代わりにロバストヘッダ圧縮（ＲｏＨＣ）などのヘッダ圧縮アルゴリズムを使用することができる。 ヘッダ圧縮の背後にある基本的な考え方は、ＲＴＰ／ＵＤＰ／ＩＰのヘッダの中のフィールドの大部分は静的であり、したがってこれらは送信側のコンプレッサから受信側のデコンプレッサに、第１の通信（例えば無線システムにおいて最初に伝送されるパケット）中に圧縮されないまま一度送信されることが可能であるというものである。 デコンプレッサが静的な情報を確実に取得すると、コンプレッサはヘッダの動的部分に関する情報を伝える圧縮されたヘッダの送信を開始する。 デコンプレッサは、圧縮されたヘッダからＲＴＰ／ＵＤＰ／ＩＰのヘッダを完全に再構成し、このパケットを次に渡すことができる。 このようにして、パケットごとに大きなヘッダは送信されず、結果として容量の著しい節約になる。

しかしながら、現在のヘッダ圧縮方法にはいくつかの欠点がある。 説明を簡単にするために、従来の無線通信システムにおいて実施されるヘッダ圧縮に関して、このような欠点を説明する。

図１は、よく知られている無線通信ネットワークの一般的なアーキテクチャを示している。 図のように、アクセス端末（ＡＴ）１０が、無線インターフェースによって基地局（ＢＴＳ）１２と通信する。 ＡＴの例には、移動局、移動体、無線電話、無線装備されたＰＤＡ又はコンピュータなどがある。 複数の基地局１２が、無線ネットワーク制御装置（ＲＮＣ）１４と通信し、ＲＮＣは各無線データのセッションに対してシグナリング及びトラフィック処理を提供する。 図１は、ＡＴ１０、ＢＴＳ１２、ＲＮＣ１４を示しており、こうした構成要素間のインターフェースは、無線アクセスネットワーク（ＲＡＮ）として知られるものを形成している。 ＲＡＮはコアネットワークと通信し、例えばインターネットにアクセスする。 図１の例ではコアネットワークは、ＲＮＣ１４と例えばインターネット（図示せず）との間に接続された１つ又は複数のパケットデータサービスノード（ＰＤＳＮ）１６を含んでいる。

一例ではヘッダの圧縮は、ＡＴ１０とＰＤＳＮ１６との間、ＡＴ１０とＲＮＣ１４との間などで行うことができる。 ＡＴ１０が、例えばＶｏＩＰ呼のようなネットワークと通信を確立すると、アプリケーション層のパケットは、ＲＴＰ／ＵＤＰ／ＩＰのプロトコルスタックによって運ばれることになる。 ＲＴＰ／ＵＤＰ／ＩＰのヘッダは、例えば上述のＲｏＨＣアルゴリズムを使用して、ＡＴ１０のコンプレッサによって圧縮される。 圧縮されたパケットは、ＢＴＳ１２からＲＮＣ１４へ、さらにＲＮＣ１４からＰＤＳＮ１６へアップリンクに送信される。 ＲＮＣ１４又はＰＤＳＮ１６のデコンプレッサは、ＲｏＨＣヘッダを復元してＲＴＰ／ＵＤＰ／ＩＰのヘッダを再構築する。 同様にダウンリンク方向では、ＰＤＳＮ１６及びＲＮＣ１４がパケットを受信し、ＰＤＳＮ１６又はＲＮＣ１４のコンプレッサが、ＲＴＰ／ＵＤＰ／ＩＰのヘッダを圧縮してＲｏＨＣすなわち圧縮されたヘッダを生成する。 圧縮されたヘッダを有するパケットが、ＢＴＳ１２に送信され、さらにＡＴ１０に送信される。 ＡＴ１０のデコンプレッサがＲｏＨＣヘッダを復元して元のＲＴＰ／ＵＤＰ／ＩＰのヘッダを取得し、このパケットをアプリケーション層に渡す。

図２は、無線通信ネットワークの別のアーキテクチャ、いわゆるフラットＩＰネットワークアーキテクチャを示している。 図のようにＡＴ１０は、無線インターフェースによって基地局（ＢＳ）２０と通信する。 このＢＳ２０は、複数の移動体ネットワーク要素を単一のエンティティに集中し、シグナリング及びベアラを結合して１つのＩＰ接続にする。 このフラットＩＰアーキテクチャではＢＳ２０が、無線アクセス技術に基づく機能をすべて含んでいる。 言い換えれば図１のＢＴＳ、ＲＮＣ、及びＰＤＳＮの中の機能が、ＢＳに集中されている。 ＢＳ２０は、ネットワークの中でルータのように機能し、他のＢＳ及びネットワーク要素と通信する。 図１と比較すると、別個のＲＮＣ要素及びＰＤＳＮ要素はもはやない。 ＢＳはまた、アクセスゲートウェイ２２と通信することができ、アクセスゲートウェイはインターネットのような他のネットワークとの外部接続を行う。

図２のアーキテクチャでは、ＡＴ１０とＢＳ２０との間、又はＡＴ１０とアクセスゲートウェイ２２との間でヘッダの圧縮を行うことができる。 ＡＴ１０が例えばＶｏＩＰ呼などのネットワークと通信を確立すると、アプリケーション層のパケットは、ＲＴＰ／ＵＤＰ／ＩＰのプロトコルスタックによって運ばれることになる。 ＲＴＰ／ＵＤＰ／ＩＰのヘッダは、例えば上述のＲｏＨＣアルゴリズムを使用して、ＡＴ１０のコンプレッサによって圧縮される。 圧縮されたパケットは、ＡＴ１０からＢＳ２０へ、又はＡＴ１０からＢＳ２０へさらにＢＳ２０からアクセスゲートウェイ２２へ、アップリンクで送信されることになる。 ＢＳ２０又はアクセスゲートウェイ２２のデコンプレッサは、ＲｏＨＣヘッダを復元してＲＴＰ／ＵＤＰ／ＩＰのヘッダを再構築する。 同様にダウンリンク方向では、アクセスゲートウェイ２２及びＢＳ２０がパケットを受信し、アクセスゲートウェイ２２又はＢＳ２２のコンプレッサが、ＲＴＰ／ＵＤＰ／ＩＰのヘッダを圧縮してＲｏＨＣすなわち圧縮されたヘッダを生成する。 圧縮されたヘッダを有するパケットは、ＡＴ１０へ送信される。 ＡＴ１０のデコンプレッサがＲｏＨＣヘッダを復元して元のＲＴＰ／ＵＤＰ／ＩＰのヘッダを取得し、このパケットをアプリケーション層に渡す。

ロバストヘッダ圧縮（ＲｏＨＣ）アルゴリズムは、そのプロトコルのヘッダの中の動的フィールドの圧縮に、ウィンドウベースの最下位ビット符号化アルゴリズム（ｗｉｎｄｏｗ−ｂａｓｅｄ ｌｅａｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔｓ ｅｎｃｏｄｉｎｇ ａｌｇｏｒｉｔｈｍ）などの、いくつかの符号化方式を使用する。 ＲｏＨＣ圧縮アルゴリズムはまた、フィードバック機構を組み込んでいる。 ＲｏＨＣ圧縮アルゴリズムは、高いエラー率及び／又は長いラウンドトリップ時間を有する無線リンクにおいて非常に有効である。 ＲｏＨＣ圧縮アルゴリズムはその効率性及びロバスト性のために、無線リソースに費用がかかる無線ネットワークにおいて好適である。

しかしながら、ＲｏＨＣ圧縮を用いても、ヘッダの中の非静的すなわち動的なフィールドは送信されなければならない。 ＲＴＰ／ＵＤＰ／ＩＰのヘッダの中で最も動的に変化するフィールドは、ＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプである。 各ＲＴＰのヘッダは、ＲＴＰのパケットを正確に順序付けできるようにＲＴＰのシーケンス番号を含んでいる。 したがって、各ＲＴＰのパケットのヘッダは、それぞれ異なる、一般に徐々に増えていくシーケンス番号を有する。 ＲＴＰのタイムスタンプは、ＲＴＰのパケットの中の第１のバイトのサンプリング時間を示している。

本発明は、無線リンクによるヘッダの圧縮／復元を改良することに関する。 詳細には本発明は、ＲＴＰのヘッダの動的フィールドの少なくとも１つを抑制する方法を提供する。

一実施形態では、受信された無線リンクプロトコル（ＲＬＰ）のパケットの中のＲＬＰのシーケンス番号と受信されたＲＬＰのパケットによって表されるリアルタイムプロトコル（ＲＴＰ）のパケットのＲＴＰのシーケンス番号との間で関係を決定する。 圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのシーケンス番号は、この決定された関係、及び圧縮されたＲＴＰのパケットを形成する受信されたＲＬＰのパケット若しくはパケット群のＲＬＰのシーケンス番号の少なくとも１つに基づいて決定される。 この圧縮されたＲＴＰのパケットは、ＲＴＰのシーケンス番号を含んでいない。

別の実施形態では、受信された無線リンクプロトコル（ＲＬＰ）のパケットと関連するプロトコルのタイムスタンプと、受信されたＲＬＰのパケットによって表されるリアルタイムプロトコル（ＲＴＰ）のパケットの中のＲＴＰのタイムスタンプとの間で関係を決定する。 プロトコルのタイムスタンプは、ネットワーク要素のインターフェースプロトコル（例えばＢＴＳ／ＲＮＣのインターフェースプロトコル）によって付加されるタイムスタンプである。 圧縮されたＲＴＰのパケットと関連付けられるＲＴＰのタイムスタンプは、この決定された関係、及び圧縮されたＲＴＰのパケットを形成する受信されたＲＬＰのパケット若しくはパケット群のプロトコルのタイムスタンプの少なくとも１つに基づいて決定される。 この圧縮されたＲＴＰのパケットは、ＲＴＰのタイムスタンプを含んでいない。

さらに別の実施形態では、圧縮されたリアルタイムプロトコル（ＲＴＰ）のパケットと関連付けられるＲＴＰのタイムスタンプは、圧縮されたＲＴＰのパケットを形成する受信された無線リンクプロトコル（ＲＬＰ）のパケット若しくはパケット群の少なくとも１つのプロトコルのタイムスタンプ、前に受信されたＲＬＰのパケットのプロトコルのタイムスタンプ、及び前に受信されたＲＴＰのパケットのＲＴＰのタイムスタンプに基づいて決定される。 プロトコルのタイムスタンプは、ネットワーク要素のインターフェースプロトコルによって付加されるタイムスタンプである。 この圧縮されたＲＴＰのパケットは、ＲＴＰのタイムスタンプを含んでいない。

またさらなる実施形態は、圧縮されたＲＴＰのパケットの中でＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプのうちの少なくとも１つを抑制することを含む。

さらに他の実施形態では、ネットワーク要素間（例えばＢＴＳとＲＮＣ間）のインターフェースが（例えばＢＳのアーキテクチャにおいて）簡略化され、集中されるとき、上記の実施形態の中のプロトコルのタイムスタンプを使用する代わりに、伝送パケット情報及びローカルのタイミング情報のうちの少なくとも１つから導出されるタイムスタンプを使用することができる。

以下に提供する詳細な説明、及び単に実例として示す添付の図面から、本発明はさらに十分に理解されるようになるであろう。 図面では、同じ参照符号が様々な図面の中で対応する部分を表している。

よく知られている無線通信ネットワークを示す図である。

いわゆるフラットＩＰ無線通信ネットワークを示す図である。

本発明の一実施形態による、上りリンクの通信のための無線通信システムの一部のアーキテクチャを示す図である。

本発明の一実施形態による、下りリンクの通信のための無線通信システムの一部のアーキテクチャを示す図である。

上述の図１を参照すると、無線ネットワークのリンク層によるデータパケットの伝送は、ＲＡＮにおけるパケットの引渡し及び処理を保証するための情報を含んでいる。 例えば、送信側における無線リンクプロトコル（ＲＬＰ）のレイヤは、ＲｏＨＣパケットをカプセル化し、パケットの引渡しのためにＲＬＰヘッダの中にシーケンス番号（ＳＮ）を与える。 シーケンス番号は、ＲＬＰのパケットの送信ごとに増え、したがって受信側で順序が乱れて受信されたパケットを正しく順序付けるためのメカニズムを提供する。 このメカニズムを使用して、欠落したデータパケットを認識することも可能である。

さらに、ＢＴＳ１２とＲＮＣ１４との間のバックホール上のインターフェースが、ＲＬＰのパケットをカプセル化するための別のプロトコル（以下「ＢＴＳ／ＲＮＣインターフェースプロトコル」）を加える。 より具体的には、ＢＴＳ／ＲＮＣインターフェースプロトコルは、ＢＴＳとＲＮＣとの間でＲＬＰのパケットが送信されるときに関するタイミング情報（例えばタイプスタンプ）を維持管理する。 上りリンクでは、このタイミング情報は、ＲＬＰのパケットがＡＴから送信されてＢＴＳによりＲＮＣに渡される伝送時間を表す。 下りリンクでは、ＢＴＳ／ＲＮＣインターフェースプロトコルの中にタイムスタンプフィールドがあり、ＲＬＰのパケットがＲＮＣで生成された時間を表している。 ＢＴＳがパケットを受信すると、ＢＴＳはその伝送スケジューリングの決定の際にこのタイミング情報を利用することができる。

前述の図２を参照すると、ネットワーク要素ＢＴＳ及びＲＮＣが単一の要素ＢＳに集中されるフラットＩＰアーキテクチャでは、機能エンティティＢＴＳとＲＮＣとの間のインターフェースプロトコルを簡略化することができる。 プロトコルのタイムスタンプは、パケットの伝送時間及びＢＳにおけるローカル時間から導出されるタイムスタンプに置き換えることができる。 つまり、プロトコルのタイムスタンプは、インターフェースプロトコルのフィールドの中の値の１つであり、ＢＳがＲＯＨＣパケットを生成し、且つＡＴからパケットを受信もするため、ＢＳはこの情報を完全に理解している。 下りリンクでは、ＢＳはＲＯＨＣパケットが生成されるタイムインスタンスに基づいてタイムスタンプを取得する。 上りリンクでは、ＢＳはＡＴからパケットを受信し、伝送フォーマット及びＭＡＣヘッダ情報に基づいて、パケットがＡＴから送信されるときを正確に知る。 プロトコルのタイムスタンプの使用に関する次の説明は、図２のフラットＩＰアーキテクチャにおいても導出されるタイムスタンプに同様に適用可能である。

各ＲＬＰのパケットが１つ又は複数のＲｏＨＣパケットを含むとき、ＲＬＰのシーケンス番号（ＳＮ）とＲｏＨＣヘッダの中の圧縮されたＲＴＰのＳＮとの間に一意マッピングがあることがわかった。 さらに、ＲＬＰのパケットがＲｏＨＣパケットの一部を含むとき、ＲＬＰのヘッダの中の「最初のデータ」及び「最後のデータ」のフィールドを使用して完全な上位レイヤのパケットを再構築することができる。 言い換えれば、ＲＬＰのヘッダの中の「最初のデータ」のフィールドが１に設定されている場合、このＲＬＰのパケットは上位レイヤのパケットの最初の部分を含んでいることを意味する。 「最後のデータ」のフィールドが１に設定されている場合、このＲＬＰのパケットは上位レイヤのパケットの最後の部分を含んでいることを意味する。 「最初のデータ」と「最後のデータ」の両方のフィールドが１に設定されている場合、このＲＬＰのパケットは完全な上位レイヤのパケットを含んでいることを意味する。 こうした様々な場合において、ＲＬＰのＳＮとＲＴＰのＳＮとの間には一意マッピングが存在する。 したがって、ＲＬＰのＳＮを使用してＲＴＰのパケットのＲＴＰのＳＮを回復することができ、ヘッダの中でＲＴＰのＳＮを抑制する（すなわち送信しない）ことが可能であるとわかった。

さらに、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイムスタンプは伝送タイミング情報を表すので、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイムスタンプはＲＴＰのタイムスタンプと一意の関係を有することがわかった。 本発明の諸実施形態によりこの関係を使用して、ヘッダからＲＴＰのタイムスタンプを抑制することができる。 この関係は特に、ＲＴＰ／ＵＤＰ／ＩＰのパケットがＡＴ１０においてアプリケーション層により生成され、ＲｏＨＣを用いて圧縮され、順次送出される上りリンクすなわちアップリンクに関する。 図２のアーキテクチャでは、導出されるタイムスタンプが、ＲＴＰのタイムスタンプと一意の関係を有する。

受信されたＲＴＰ／ＵＤＰ／ＩＰのパケットが順序通りである場合、ＲＴＰのタイムスタンプは独特なパターンを有し、ＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダの中のタイムスタンプは、ＲＴＰのタイムスタンプと相互に関係がある。 例えばＶｏＩＰパケットのＲＴＰのタイムスタンプは、一定の間隔（通常２０ｍｓすなわち１６０サンプル）で増える。 各ＶｏＩＰパケットの到着時間があまり変化しない場合、ＢＴＳ／ＲＮＣインターフェースプロトコルにおけるタイムスタンプもまた、ほぼ同じ間隔で増える。 一般にＲＮＣに到着するＶｏＩＰパケットは、ネットワークを通過している。 各パケットは、ＲＮＣに到着するとき遅延及び遅延ジッタを経験することになる。 一方、各ＶｏＩＰパケットの中のＲＴＰのタイムスタンプは、発信元（すなわち音声コーデック）で生成されたサンプリング時間を表す。 各ＶｏＩＰパケットが同じ遅延を経験せず、ゆえにＶｏＩＰパケット間に遅延ジッタがない場合、ＲＮＣでのパケットの到着時間には、元のＲＴＰのパケットと同じ独特なパターンがない。 したがって、本発明の諸実施形態による推定法を使用して、ＲＴＰのタイムスタンプとＢＴＳ／ＲＮＣインターフェースプロトコルにおけるタイムスタンプとの間のマッピングを見つけることができる。

ＴＳ _ＲＴＰ１ （サンプル数からｍｓに換算）をＲＴＰのパケットのタイムスタンプとし、ＴＳ _{Ｉｎｔｅｒｆａｃｅ１} （単位ｍｓ）をＢＴＳ／ＲＮＣインターフェースプロトコルにおける対応するＲＬＰのパケットのタイムスタンプとする。 ＴＳ _ＲＴＰ２ （サンプル数からｍｓに換算）を次に続くＲＴＰのパケットのタイムスタンプとし、ＴＳ _{Ｉｎｔｅｒｆａｃｅ２} （単位ｍｓ）をＢＴＳ／ＲＮＣインターフェースプロトコルにおける対応するＲＬＰのパケットのタイムスタンプとする。 またＴＳ _{ＲＴＰ＿ｉｎｔｅｒｖａｌ}をＲＴＰのパケット間のタイムスタンプの間隔（すなわち２０ｍｓ）とする。 インターフェースプロトコルにおけるタイムスタンプと、ＲＴＰのタイムスタンプとの間のマッピングは、次のように決定することができる。 すなわち、

_ＲＴＰ２が正しく復号できない場合、インターフェースプロトコルにおけるタイムスタンプを使用して、次のようにＴＳ

_{ＲＴＰ２＿ｅｓｔｉｍａｔｅｄ}を推定することができる。 すなわち、

無音圧縮中にＲＴＰのタイムスタンプにジャンプがあるとき、やはり上記の方法を使用してＲＴＰのタイムスタンプを推定することができる。

図２のアーキテクチャでは、プロトコルのタイムスタンプの代わりに導出されたタイムスタンプを使用することによって、同じ方法を適用することができる。

受信したＲＴＰ／ＵＤＰ／ＩＰのパケットの順序が乱れているとき、ＲＯＨＣコンプレッサがＲＮＣにある場合は、ＲＯＨＣコンプレッサがＲＬＰレイヤに再順序付け状態を知らせることができ、インターフェースプロトコルにおけるタイムスタンプを直ちに設定することができる。 ＲＯＨＣコンプレッサがＰＤＳＮにある場合は、ＰＤＳＮが再順序付け状態をＲＮＣに渡し、ＲＮＣがこれを直ちに利用できるようにする。 したがって同じ推定法を使用してＲＴＰのタイムスタンプを推定することができる。 したがって、ヘッダの中でＲＴＰのタイムスタンプを抑制する（すなわち送信しない）ことが可能である。

次に本発明の諸実施形態について詳細に説明する。 まず、上りリンクにおいてヘッダの抑制を行うアーキテクチャ及び方法の一実施形態について説明する。 次に、下りリンクにおいてヘッダの抑制を行うアーキテクチャ及び方法の一実施形態について説明する。 単に説明を簡単にするために、図１の無線通信ネットワークで使用されるものとして、これらの実施形態について説明する。 しかしながら、本発明のアーキテクチャ及び方法は、この無線システムにも、諸無線システムにも限定されないことを理解されたい。 例えば以下の説明は、導出されたタイムスタンプがプロトコルのタイムスタンプの代わりに使用される図２のアーキテクチャに適用することもできる。

上りリンク 図３は、本発明の一実施形態により、上りリンクすなわちアップリンク上で機能するＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の機能ブロック図を示している。 明瞭にするために、当技術分野でよく知られているＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の具体的な詳細は示していないことが理解されるであろう。

ＡＴ１０とＢＴＳ１２、ＡＴ１０とＲＮＣ１４、又はＡＴ１０とＰＤＳＮ１６との間に、ロバストヘッダ圧縮（ＲｏＨＣ）のチャネルを確立することができる。 上りリンクについては、コンプレッサ１０４及びデコンプレッサ１４４は、（図３に示すように）それぞれＡＴ１０及びＲＮＣ１４にある場合がある。 この実施形態を、この実装を使用して説明する。 しかしながら、この説明はＢＴＳ１２（ただしＢＴＳ１２がリンク層の情報を引き出す若しくは生成する）又はＰＤＳＮ１６（ただしＲＮＣ１４がリンク層の情報をＰＤＳＮ１６に渡す）にあるデコンプレッサにも同様に適用可能である。

図のようにＡＴ１０は、特定のアプリケーションに対してＩＰパケットを生成するアプリケーション層のＩＰジェネレータ１０２を含んでいる。 例えばＶｏＩＰ呼は、ＲＴＰ／ＵＤＰ／ＩＰのパケットにカプセル化された音声フレームからなる。 接続を確立すると、アプリケーション層のジェネレータ１０２が、アプリケーション層のパケットを生成し、これがプロトコルスタックを介してＲＴＰ／ＵＤＰ／ＩＰのパケットになる。 ヘッダコンプレッサ１０４は、圧縮／復元のコンテキストを確立するために、最初に１つ又は複数のＲＴＰ／ＵＤＰ／ＩＰのパケットを圧縮しない状態で送信する。 すなわち、圧縮／復元のコンテキストは、ヘッダの静的フィールドである。 これは、よく知られているいかなる方法でも行われる。 コンテキストを確立した後にヘッダコンプレッサ１０４は、このＲＴＰ／ＵＤＰ／ＩＰのパケットを、例えばＲｏＨＣアルゴリズムを使用してＲｏＨＣパケットに圧縮する。 しかしながら、この実施形態ではコンプレッサ１０４はまた、ＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを除去すなわち抑制もする。

その後リンク層のパケットジェネレータ１０６が、ＲｏＨＣパケットをＲＬＰのパケットに配列することによってリンク層のパケットを生成する。 リンク層のジェネレータ１０６は、上位層のパケット上で連結又は断片化を行うことができる。 この例では、ＲＬＰのパケットは、１つ又は複数のＲＯＨＣパケットからなる可能性がある。 またＲＬＰのパケットは、１つのＲＯＨＣパケットの一部のみを含む可能性もある。 ＲＬＰのパケットのサイズは、ＡＴがその時点で使用できる利用可能な伝送速度に基づいて決定される。 上述のようにＲＬＰのレイヤは、パケットの配信に対してＲＬＰのヘッダに独自のＳＮを与え、欠落したデータパケットを認識するメカニズムを提供する。

ＢＴＳ１２はＲＬＰのパケットを受信し、インターフェースプロトコル１０８がＲＬＰのパケットにヘッダを付加する。 より具体的には、ＢＴＳ／ＲＮＣインターフェースプロトコル１０８がＲＬＰのパケットをカプセル化し、このインターフェースプロトコルのパケットのヘッダには、ＡＴ１０におけるＲＬＰのパケットの伝送タイミング情報を表すパケットＩＤ（又はタイムスタンプ）が含まれている。 ＢＴＳ１２は、ＲＬＰのパケットを、ＲＮＣ１４又はＰＤＳＮ１６（図示せず）に渡して復元する。 システムの設計により、ＲＬＰ及びインターフェースプロトコルに加えて他のプロトコルを追加することも可能である。

ＲＮＣ１４は、ＲＬＰ処理モジュール１４２及びデコンプレッサ１４４を含んでいる。 ＲＬＰ処理モジュール１４２は、ＲＬＰのパケットを受信し、そこからＲＴＰ／ＵＤＰ／ＩＰのパケットを取得し、ＲＴＰ／ＵＤＰ／ＩＰのパケットと共にＲＬＰのＳＮ及び伝送タイミング情報（以後同義で「リンク層の情報」と呼ぶ）をデコンプレッサ１４４に渡す。

デコンプレッサ１４４は、コンテキスト及びリンク層の情報からＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを決定し、次にＲＴＰ／ＵＤＰ／ＩＰのパケットを、例えばＲＯＨＣアルゴリズムにより、よく知られている方法で復元する。

圧縮／復元のコンテキストが確立されるとき、すなわち圧縮されていないＲＴＰ／ＵＤＰ／ＩＰのパケットが送信されるとき、デコンプレッサ１４４は、特にＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを取得する。 デコンプレッサ１４４は、ＲＬＰのシーケンス番号をＲＴＰのシーケンス番号にマップし、またＢＴＳ／ＲＮＣインターフェースプロトコルのタイミング情報をＲＴＰのタイムスタンプにマップする。 例えば３つの連続するパケットについては、ＲＬＰのシーケンス番号は２０、２１、及び２２とすることができ、関連付けられる３つのＲＴＰのシーケンス番号は８、９、及び１０とすることができる。 したがって、以下の表１に示すように、ＲＬＰのシーケンス番号２０はＲＴＰのシーケンス番号８にマップされ（例えば関連付けて格納される）、ＲＬＰのシーケンス番号２１はＲＴＰのシーケンス番号９にマップされるなどとなる。

或いは、ＲＬＰ及びＲＴＰのシーケンス番号が一定量ずつ増え、関連したＲＬＰのシーケンス番号とＲＴＰのシーケンス番号との間に同じ一定のオフセットが存在する場合、デコンプレッサ１４４は、このオフセット量を代わりに又は加えて格納することができる。

上位層のＲＯＨＣパケットが複数のＲＬＰのパケットに断片化される場合、ＲＬＰヘッダの中の「最初のデータ」及び「最後のデータ」のフィールドを使用して、ＲＯＨＣパケットのフレームの境界（最初の部分及び最後の部分）を決定することができる。 例えば、６つの連続するパケットについては、ＲＬＰのシーケンス番号は２０、２１、２２、２３、２４、及び２５とすることができる。 ＲＬＰのパケット２０の中の「最初のデータ」のフィールドは１であるが、「最後のデータ」のフィールドは０である。 これは、ＲＬＰのパケット２０がＲＯＨＣのパケットの最初の部分であることを示す。 ＲＬＰのパケット２１の中の「最初のデータ」及び「最後のデータ」は、共に０である。 ＲＬＰのパケット２２の中の「最初のデータ」はゼロであり、ＲＬＰのパケット２２の中の「最後のデータ」は１である。 したがって、ＲＬＰのパケット２０、２１、及び２２が完全なＲＯＨＣパケットを形成し、対応するＲＴＰのＳＮは８である。 ＲＬＰのパケット２３の中の「最初のデータ」のフィールドは再び１となり、別の上位レイヤのパケットの開始を示している。 したがって、以下の表２に示すように、ＲＬＰのシーケンス番号２０はＲＴＰのシーケンス番号８にマップされ（例えば関連付けて格納される）、ＲＬＰのシーケンス番号２３はＲＴＰのシーケンス番号９にマップされるなどとなる。

インターフェースプロトコルのタイミング情報及びＲＴＰのタイムスタンプは、ＲＬＰからＲＴＰへのシーケンス番号のマッピングと同様の方法でマップされる。

最終的には、ＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプのない圧縮されたＲＴＰ／ＵＤＰ／ＩＰのパケットが受信される。 受信されたパケットは、ＲＬＰ処理モジュール１４２によってデコンプレッサ１４４に渡されることになる。 このようになるとデコンプレッサ１４４は、リンク層の情報及びコンテキストを使用する再構築メカニズム呼び出し、ＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを再構築しようと試みる。

再構築メカニズムは、パケットのＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを決定することを含んでいる。 このＲＴＰのシーケンス番号を決定するために、デコンプレッサ１４４はこのパケットのＲＬＰのシーケンス番号、及びＲＬＰからＲＴＰへのシーケンス番号のマップを使用する。 上記表１のＲＬＰからＲＴＰへのシーケンス番号のマップを使用して、ＲＴＰのシーケンス番号を決定する動作の一例を説明する。 次に受信されたパケットのＲＬＰのシーケンス番号が２３である場合、デコンプレッサ１４４はＲＴＰのＳＮは１１であると認識する。 これは表１に示すシーケンスに従っている。 したがってデコンプレッサ１４４は、同様にして、ＲＬＰのシーケンス番号を２５とする受信されたパケットのＲＴＰのシーケンス番号を１３と決定する。

或いは又はさらにデコンプレッサ１４４は、ＲＬＰからＲＴＰへのマッピングのオフセットを決定した場合がある。 表１の例では、このオフセットは−１２となる。 したがってこのマッピングのオフセットを使用すると、２５というＲＬＰのシーケンス番号は、ＲＴＰシーケンス番号１３（＝２５＋（−１２））にマップされる。

ＲＴＰのＳＮが決定されると、ＲＬＰのＳＮ及び決定された関連するＲＴＰのＳＮは、その後の決定で使用するためにマッピングテーブルに追加される。

同様にしてデコンプレッサ１４４は、ＢＴＳ／ＲＮＣタイミング情報からＲＴＰのタイムスタンプを決定することもできる。 例えば表３は、（４スロット単位すなわち６．６７ｍｓ中の）インターフェースプロトコルにおけるパケットＩＤ（又はタイムスタンプ）の値、対応する伝送時間（単位ｍｓ）、（サンプル単位の）ＲＴＰのタイムスタンプ値、及び対応するサンプリング時間を示している。

ＲＬＰのタイムスタンプ及び決定された関連するＲＴＰのタイムスタンプは次に、その後の決定で使用するためにマッピングテーブルに追加されることが可能である。

表３に関する例は、パケットがエンコーダで生成されてトランスミッタに渡された後に、ＡＴにおける各パケットの伝送時間が同じ遅延を経験すると仮定する。 しかしながら、これは保証されず、しばしば非常に小さい遅延及び遅延変動が存在する可能性がある。 したがって代わりに上記で詳細に説明したように、式（２）の推定方法を使用して、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイムスタンプからＲＴＰのタイムスタンプを決定することができる。 一例として表４は、表３中のものと同じＲＴＰのタイムスタンプ及び対応するサンプリング時間を示している。 しかしながらパケットＩＤ及び対応する伝送時間は、いくつかの遅延変動を有する。 パケットＩＤ６は、４０ｍｓ（６×６．６７ｍｓ＝４０ｍｓ）という伝送時間に対応する。 次のＲＴＰのパケットのパケットＩＤは１０であり、６６．７ｍｓの伝送時間に対応する。 またパケットＩＤ１２は、８０ｍｓという伝送時間に対応する。 連続したパケット間の伝送時間の間隔は、ＲＴＰのＴＳで表されるように正確に２０ｍｓではない。 しかしながら、伝送時間はやはり、式（２）の推定方法を使用して、ＲＴＰのタイムスタンプと相互に関連付けることができる。

決定されたＲＴＰのタイムスタンプ及び関連するＲＬＰのタイムスタンプは次に、その後の決定で使用するために表に追加される。

この決定する動作を行うとデコンプレッサ１４４は、従来の方法でＲＯＨＣパケットを復元し、復元後、決定されたＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを、受信されたパケットのＲＴＰのシーケンス番号及びタイムスタンプとして使用する。

圧縮されたＲＴＰ／ＵＤＰ／ＩＰのパケットからＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを除去することができることによって、無線インターフェース上で帯域幅のさらなる節約が実現される。

下りリンク 上記の詳細な説明は上りリンクにおける圧縮及び復元に関するものであったが、上述の本発明の方法は下りリンクにも適用可能である。 図４は、本発明の一実施形態により、下りリンクすなわちダウンリンク上で機能するＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の機能ブロック図を示している。 当技術分野でよく知られているＡＴ１０、ＢＴＳ１２、及びＲＮＣ１４の特定の詳細（例えばＲＴＰ／ＵＤＰ／ＩＰのプロトコルスタックなど）については、明瞭にするために示していないことを理解されたい。

ＡＴ１０とＢＴＳ１２、ＡＴ１０とＲＮＣ１４、又はＡＴ１０とＰＤＳＮ１６との間に、ロバストヘッダ圧縮（ＲｏＨＣ）のチャネルを確立することができる。 下りリンクについては、コンプレッサ２０４及びデコンプレッサ２４４は、（図４に示すように）それぞれＲＮＣ１４及びＡＴ１０にある場合がある。 この実装を使用して、この実施形態について説明する。 しかしながら、この説明は、ＢＴＳ１２又はＰＤＳＮ１６にあるコンプレッサにも同様に適用可能である。

図のようにＲＮＣ１４は、特定のアプリケーションに対してＩＰパケットを生成するアプリケーション層のＩＰジェネレータ２０２を含んでいる。 例えばＶｏＩＰ呼は、ＲＴＰ／ＵＤＰ／ＩＰのパケットにカプセル化された音声フレームからなる。 接続が確立するとアプリケーション層のジェネレータ２０２は、アプリケーション層のパケットを生成し、これがプロトコルスタックを介してＲＴＰ／ＵＤＰ／ＩＰのパケットになる。 ヘッダコンプレッサ２０４は、圧縮／復元のコンテキストを確立するために、最初に１つ又は複数のＲＴＰ／ＵＤＰ／ＩＰのパケットを圧縮しない状態で送信する。 すなわち、圧縮／復元のコンテキストは、ヘッダの静的フィールドである。 これは、よく知られているいかなる方法でも行われる。 コンテキストを確立した後にヘッダコンプレッサ２０４は、このＲＴＰ／ＵＤＰ／ＩＰのパケットを、例えばＲｏＨＣアルゴリズムを使用してＲｏＨＣパケットに圧縮する。 しかしながら、この実施形態ではコンプレッサ２０４はまた、ＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを除去すなわち抑制もする。

続いてリンク層のパケットジェネレータ２０６が、各ＲｏＨＣパケットをＲＬＰのパケットに配列することによってリンク層のパケットを生成する。 上述のようにＲＬＰのレイヤは、パケットの配信に対してＲＬＰのヘッダに独自のＳＮを与え、欠落したデータパケットを認識するメカニズムを提供する。 さらに、下りリンクに関連して触れたように、ＲｏＨＣパケットを２つ以上のＲＬＰのパケットに断片化することができる。

ＲＮＣにおけるＢＴＳ／ＲＮＣインターフェースプロトコル２０８は、ＲＬＰのパケットをＢＴＳに送信する前にＲＬＰのパケットにインターフェースプロトコルのヘッダを付加する。 より具体的には、ＢＴＳ／ＲＮＣインターフェースプロトコルはＲＬＰのパケットをカプセル化し、インターフェースプロトコルのパケットのヘッダには、ＲＬＰのパケットの伝送タイミング情報を表すシーケンス番号が含まれる。 ＢＴＳ１２は、ＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダを除去し、ＲＬＰのパケットをＡＴ１０に渡して復元する。 システムの設計により、ＲＬＰ及びインターフェースプロトコルに加えて他のプロトコルを追加することも可能である。

ＡＴ１０は、ＲＬＰ処理モジュール２４２及びデコンプレッサ２４４を含んでいる。 ＲＬＰ処理モジュール２４２は、ＲＬＰのパケットを受信し、そこからＲＴＰ／ＵＤＰ／ＩＰのパケットを取得し、ＲＴＰ／ＵＤＰ／ＩＰのパケットと共にＲＬＰのＳＮ及びおそらく伝送タイミング情報（以後同義で「リンク層の情報」と呼ぶ）をデコンプレッサ２４４に渡す。 ＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダは、ＲＬＰのパケットと共にＢＴＳからＡＴへ送信されない。 したがって、ＢＴＳ／ＲＮＣインターフェースプロトコルのタイミング情報は、ローカルの修復メカニズムにおいてＡＴが利用できない。

一実施形態では、このタイミング情報は、ＢＴＳ／ＲＮＣインターフェースプロトコルのヘッダの中ではないが、ＡＴに送信されることが可能である。 例えば、このタイミング情報は、付加的なシグナリングを介してＢＴＳによりＡＴに送信されることが可能であり、ＲＬＰのヘッダの中に付加的なフィールドを備えるか、又は付加的なメッセージを別個にＡＴに送信する。

デコンプレッサ２４４は、コンテキスト及びリンク層の情報からＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを決定し、その後このＲＴＰ／ＵＤＰ／ＩＰのパケットを、例えばＲＯＨＣアルゴリズムにより、よく知られている方法で復元する。

圧縮／復元のコンテキストが確立されるとき、すなわち圧縮されていないＲＴＰ／ＵＤＰ／ＩＰのパケットが送信されるとき、デコンプレッサ２４４は特にＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを取得する。 デコンプレッサ２４４は、ＲＬＰのシーケンス番号をＲＴＰのシーケンス番号にマップし、またタイミング情報をＲＴＰのタイムスタンプにマップする。

最終的には、ＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプのない圧縮されたＲＴＰ／ＵＤＰ／ＩＰのパケットが受信される。 受信されたパケットは、ＲＬＰ処理モジュール１４２によってデコンプレッサ１４４に渡されることになる。 このようになるとデコンプレッサ１４４は、リンク層の情報及びコンテキストを使用する再構築メカニズムを呼び出し、ＲＴＰのＳＮ及び／又はＲＴＰのタイムスタンプを再構築しようと試みる。

再構築メカニズムは、パケットのＲＴＰのシーケンス番号及びＲＴＰのタイムスタンプを決定することを含んでいる。 ＲＴＰのシーケンス番号を決定するのに、デコンプレッサ１４４はこのパケットのＲＬＰのシーケンス番号、及びＲＬＰからＲＴＰへのシーケンス番号のマップを使用する。 言い換えればＲＴＰのＳＮ及びＲＴＰのタイムスタンプを同じ方法で、すなわち上りリンクに関して上述した同じ実施形態により、再構築することができる。

別の実施形態では、ＲＴＰのタイムスタンプ（ＴＳ）は、決定されたＲＴＰのシーケンス番号（ＳＮ）を用いて推測される。 ＲＴＰのタイムスタンプは、ＲＴＰのパケットのペイロードを生成するために使用されるサンプルの数を識別するために定義される。 ＲＴＰのパケットが一定のサンプリング間隔に対応するペイロードを運び、サンプルレートが一定であるとき、ＴＳとＳＮとの間には一意マッピングがある。 例えば、従来の音声については、８ｋＨｚの一定のサンプリングレートが使用されることが多い。 音声のペイロードは、２０ｍｓごとに生成される。 これは、連続パケットについてはＲＴＰのＴＳの領域が１６０増加することに等しい。 言い換えれば、会話区間（ｔａｌｋ ｓｐｕｒｔ）（無音抑制（ｓｉｌｅｎｃｅ ｓｕｐｐｒｅｓｓｉｏｎ）が適用されない）の間に、ＲＴＮのＳＮ番号は１だけ増加し、ＴＳは１６０だけ増加する。 この場合、ＲＴＰのＳＮを回復する方法から、間接的にＴＳを回復することができる。

理解されるであろうが、提供するシステム及び方法による再構築メカニズムは、帯域幅の節約を高めることができる。

本発明を上記のように説明しているが、同様のものを様々に変更することが可能であることは明らかであろう。 このような変形形態は本発明からの逸脱とみなされてはならず、このような変更形態はすべて本発明の範囲内に含まれるものとする。