(57)【特許請求の範囲】
【請求項１】
パケットサーバで用いられる方法であって、
ＧＰＲＳ（General Packet Radio Service）に基づくトンネリングプロトコル（ＧＴＰ）、ユーザデータグラムプロトコル（ＵＤＰ）およびインターネットプロトコル（ＩＰ）のヘッダ情報を含むＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮をＧＴＰピアとネゴシエートするステップを備え、該ネゴシエートするステップが、
まずＧＴＰピアへＧＴＰ／ＵＤＰ／ＩＰヘッダを送信するステップ、及び
次に圧縮ＧＴＰ／ＵＤＰ／ＩＰヘッダをＧＴＰピアへ送信するステップ
を含み、
圧縮ＧＴＰ／ＵＤＰ／ＩＰヘッダが少なくとも、拡張フィールドの有無を示す拡張ビットフィールド、及びトンネル識別子フィールドの有無を示すトンネル識別子存在フィールドを含む、方法。
【請求項２】
請求項１の方法において、圧縮ＧＴＰ／ＵＤＰ／ＩＰヘッダが長さ４バイト以下のトンネル識別子フィールドを少なくとも含む方法。
【請求項３】
請求項１の方法であって、さらに、
ＵＤＰおよびＩＰのヘッダ情報を有するＲＴＰ（Real Time Protocol）に従ってデータパケットをフォーマットするステップ、及び
パケットを送信する前にＲＴＰ／ＵＤＰ／ＩＰヘッダを圧縮するステップであって、
圧縮ＲＴＰ／ＵＤＰ／ＩＰヘッダの１つのフィールドがＵＤＰチェックサムフィールドの有無を定義している、ステップ
からなる方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、通信に関し、特に、パケット通信システムに関する。
【０００２】
【従来の技術】
ワイヤレスシステムが発展するとともに、移動通信交換センタ（ＭＳＣ）と基地局の間の通信は、インターネットプロトコル（ＩＰ）に基づくトランスポートメカニズムに移行しつつある。（ここで、ワイヤレスシステムという用語は、例えば、ＣＤＭＡ（符号分割多元接続）、ＧＳＭ(Global System for Mobile Communications)、提案されているＵＭＴＳ(Universal Mobile Telecommunications System)などを指す。）ワイヤレス通信の性質（例えば、リアルタイム音声）を考慮すると、ＩＰベースのトランスポートは、リアルタイムアプリケーションを収容するプロトコルを利用する必要がある。
【０００３】
そのようなプロトコルの１つは、ＲＴＰ(Real Time Protocol)である（例えば、H. Schulzrinne, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889、を参照）。ＲＴＰが注目されているのは、それが、リアルタイムストリームを扱うために利用可能なＩＥＴＦ(Internet Engineering Task Force)プロトコルであるためである。ＲＴＰトラフィックは、ＵＤＰ（ユーザデータグラムプロトコル）、およびＩＰパケットにカプセル化される。
【０００４】
【発明が解決しようとする課題】
残念ながら、ＲＴＰ／ＵＤＰ／ＩＰを使用すると、voice-over-ＩＰアプリケーションがワイヤレスネットワークで実行される際に大きいオーバーヘッドが生じる。音声ペイロードは通常小さい（例えば、１０から２０バイト）が、ＲＴＰ／ＵＤＰ／ＩＰヘッダは４０バイトであるためである。
【０００５】
【課題を解決するための手段】
ＲＴＰ／ＵＤＰ／ＩＰヘッダに伴う大きいオーバーヘッド以外にも、この状況は、ＧＴＰ(General Packet Radio Service Tunneling Protocol)カプセル化パケットを使用することによってさらに悪化する。この場合、ＧＴＰ／ＵＤＰ／ＩＰオーバーヘッドは、１０バイトの音声ペイロードの約９８０％となる。そこで、本発明によれば、ＧＴＰ／ＵＤＰ／ＩＰヘッダは送信のために圧縮される。
【０００６】
本発明の実施例では、ＵＭＴＳコアネットワークは、ＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮（以下、「ＧＴＰヘッダ圧縮」あるいは「圧縮ＧＴＰヘッダ」という）を行う圧縮フレームワークをサポートする。さらに、ＵＭＴＳコアネットワークは、ＧＴＰヘッダ圧縮とは独立に、ＲＴＰ／ＵＤＰ／ＩＰヘッダ圧縮（以下、「ＲＴＰヘッダ圧縮」あるいは「圧縮ＲＴＰヘッダ」という）もサポートする。その結果、ＵＭＴＳコアネットワークは、小さいマルチメディアＲＴＰパケットをより効率的にトランスポートすることが可能となる。
【０００７】
【発明の実施の形態】
当業者に知られている（リリース９７バージョン）非圧縮（圧縮されていない）ＧＴＰカプセル化ＲＴＰパケット１０の例示的フォーマットを図１に示す。ＧＴＰ／ＵＤＰ／ＩＰヘッダ１１は、ＩＰ／ＵＤＰヘッダ１２およびＧＴＰヘッダ１３からなる。ＧＴＰ／ＵＤＰ／ＩＰヘッダ１１は、当業者に知られているように、ＧＴＰペイロード１４の最上位に位置する。例えば１０バイトに等しい音声ペイロード（例えば、図１のペイロード１５）の場合、ＧＴＰ／ＵＤＰ／ＩＰヘッダ１１の結果として、オーバーヘッドは約９８０％となる。そこで、本発明によれば、ＧＴＰ／ＵＤＰ／ＩＰヘッダは送信のために圧縮される。図１からわかるように、ＧＴＰペイロード１４は、ＩＰヘッダおよびＵＤＰヘッダもトランスポートする。当業者に知られているように、ＩＰ／ＵＤＰヘッダ１２は、トンネルに関する発信側および着信側情報を含むが、ＧＴＰペイロード１４のＩＰヘッダおよびＵＤＰヘッダは、通信エンドポイントに関する発信側および着信側情報を含む。（注意すべき点であるが、ＴＩＤ値は、"Global System for Mobile Communications (GSM) 04.08 document, Digital cellular telecommunications system (Phase 2+); mobile radio interface layer 3 - specification"で定義されたリリース９７バージョンに基づいている。ＴＩＤ値は、以下の８バイトを含む：ＭＣＣ  １２ビット、ＭＮＣ  ８ビット、ＭＳＩＮ  ４０ビットおよびＮＳＡＰＩ  ４ビット。ＭＣＣ、ＭＮＣ、ＭＳＩＮおよびＮＳＡＰＩは、GSM 04.08 documentで定義されたＩＭＳＩの一部である。）
【０００８】
本発明の原理に従って修正された例示的なＵＭＴＳネットワーク２００を図２に示す。本発明の概念以外は、図２に示した要素は周知であり、詳細に説明しない。例えば、ＵＭＴＳネットワーク２００は、無線アクセスネットワーク（ＲＡＮ：radio access network）、コアネットワーク（ＣＮ：core network）、バックボーンネットワーク、および、ＩＰエンドホスト２４０によって表される例示的なエンドポイントを有する。バックボーンネットワークは、インターネットおよび公衆交換電話網（ＰＳＴＮ）を含む。ＲＡＮは、移動局（ＭＳ）２０５、ノードＢ２１０および無線ネットワークコントローラ（ＲＮＣ：radio network controller）２１５を有する。（ＵＭＴＳは「ノードＢ」(node B)という用語を使用しているが、これは基地局ともいう。）ＣＮは、サービスＧＰＲＳサポートノード（ＳＧＳＮ：serving GPRS support node）２２０、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ：gateway GPRS support node）２２５および要素２３０を有する。要素２３０は、ゲートキーパ（ＧＫ）（ＩＴＵ  Ｈ．３２３のコンポーネント）およびＩＰ／ＰＳＴＮゲートウェイ（ＧＷ）（Ｈ．３２３とＰＳＴＮの間の翻訳のため）を有する。図では、ＵＭＴＳネットワーク２００の要素は、単一ブロックの要素として示されているが、蓄積プログラム制御プロセッサ、メモリ、および適当なインタフェースカード（図示せず）を有する。本発明の説明のため、あるエンドツーエンドコネクションがＭＳ２０５とＩＰエンドホスト２４０（これはエンドポイントともいう）の間にあるとする。以下、「パケットサーバ」という用語は、任意のパケットプロセッサを指す。その例は、上記のＵＭＴＳ２００の要素である。
【０００９】
本発明によれば、ＵＭＴＳネットワーク２００は、ＧＴＰヘッダ圧縮を行う圧縮フレームワークをサポートする。さらに、ＵＭＴＳネットワーク２００は、ＧＴＰヘッダ圧縮とは独立に、ＲＴＰヘッダ圧縮もサポートする。（ここで、「ＧＴＰヘッダ圧縮」あるいは「圧縮ＧＴＰヘッダ」という用語は、ＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮を指す。同様に、「ＲＴＰヘッダ圧縮」あるいは「圧縮ＲＴＰヘッダ」という用語は、ＲＴＰ／ＵＤＰ／ＩＰヘッダの圧縮を指す。）ＧＴＰヘッダ圧縮は、ＲＴＰヘッダ圧縮とは独立であるため、ＧＴＰピアは、ＲＴＰピアとは異なることが可能である（しかしこれが要求されるわけではない）。これは、多少の設計の自由度（フレキシビリティ）も提供する。マルチメディアトラフィックには、ＲＴＰを使用せず、純粋にＵＤＰカプセル化を使用するものもあるからである。その結果、ＵＭＴＳネットワーク２００は、小さいマルチメディアパケットをより効率的にトランスポートすることができる。以下で、本発明の概念について説明する。
【００１０】
ヘッダ圧縮の概観
理解されるべき点であるが、本発明によれば、ＲＴＰヘッダ圧縮およびＧＴＰヘッダ圧縮は、ピア間で独立にネゴシエートすることができる（詳細は後述）。本発明の概念以外については、圧縮／伸長技術は周知であり、ここでは説明しない。例えば、通常、圧縮／伸長を行うもの（コンプレッサ(compressor)／デコンプレッサ(decompressor)）は、例えばＭＳ２０５のメモリ（図示せず）に記憶されたソフトウェアモジュールであり、例えばＭＳ２０５の蓄積プログラム制御マイクロプロセッサ（図示せず）によって実行される。このソフトウェアモジュールは、従来のプログラミング技法（したがって、同じくここでは説明しない）を用いて、共有情報を記憶し（後述）、伝送用に圧縮（短縮）された形式のＧＴＰ／ＵＤＰ／ＩＰヘッダあるいはＲＴＰ／ＵＤＰ／ＩＰヘッダを形成（フォーマット）する。
【００１１】
移動局（例えば、図２のＭＳ２０５）に関して、コンプレッサ／デコンプレッサを有する２つの例示的なプロトコルスタックを図３および図４に示す。図３のプロトコルスタックでは、ＲＴＰコンプレッサ／デコンプレッサは、ＩＰ層とＲＬＣ／ＭＡＣ（無線リンク制御／メディアアクセス制御）リンク層との間に位置する。（簡単のため、プロトコルスタックの物理層は図示していない。）図４のプロトコルスタックでは、ＲＴＰコンプレッサ／デコンプレッサは、アプリケーション層とＲＬＣ／ＭＡＣリンク層との間に位置する。（これも、物理層は図示していない。）（ＲＴＰヘッダ圧縮の形式については以下で説明するが、注意すべき点として、図４の実施例は、ＲＴＰヘッダが単に完全に除去されるようなＲＴＰヘッダ圧縮の形式も表している（ＲＴＰヘッダは図１３に例示する）。）
【００１２】
相補的に、対応するＲＴＰコンプレッサ／デコンプレッサおよびＧＴＰコンプレッサ／デコンプレッサが、ＵＭＴＳネットワーク内に配置される。ＵＭＴＳネットワーク２００におけるＲＴＰコンプレッサ／デコンプレッサおよびＧＴＰコンプレッサ／デコンプレッサの配置例を図５に示す。図５において、ＲＴＰコンプレッサ／デコンプレッサ（Ｃ／Ｄ）は、ＭＳ２０５およびＩＰエンドホスト２４０内に配置され（すなわち、ＭＳ２０５とＩＰエンドホスト２４０はＲＴＰピアである）、ＧＴＰコンプレッサ／デコンプレッサ（Ｃ／Ｄ）は、ＲＮＣ２１５およびＧＧＳＮ２２５内に配置される（すなわち、ＲＮＣ２１５とＧＧＳＮ２２５はＧＴＰピアである）。
【００１３】
ＲＴＰは、ポイントツーポイントプロトコルである。したがって、ＲＴＰヘッダ圧縮ピアにとって注意すべき点であるが、このことは、リンク層識別子（ＩＤ）が各ＲＴＰセッション識別子にマップされると仮定している。本発明の実施例のＲＴＰセッション識別子は、ＩＰ終点（宛先、デスティネーション）アドレスおよびＩＰ終点ポート番号（これらはエンドポイントのものである）、ＳＳＲＣ識別子（例えば、図１３を参照）、ならびに、ＵＤＰ終点ポート（例えば、図１２を参照）を含む。ＡＴＭ（非同期転送モード）がトランスポートとして使用される場合、例示的なリンク層ＩＤは、対応するＶＰＩ／ＶＣＩ（仮想パス識別子／仮想コネクション識別子）である。リンク層ＩＤとＲＴＰセッションのマッピングは、各ＲＴＰピア内で行われる。
【００１４】
また、注意すべき点であるが、ＲＴＰコンプレッサ／デコンプレッサは、別法として、無線アクセスネットワーク内に（例えば、ＲＮＣ２１５内に）、あるいは、コアネットワーク内に（例えば、ＳＧＳＮ２２０に）置くことも可能である。
【００１５】
コアネットワーク内では、ＧＧＳＮ２２５にＧＴＰコンプレッサ／デコンプレッサを置くことが（要求されるわけではないが）好ましい。ＧＴＰコンプレッサ／デコンプレッサがＳＧＳＮ２２０に配置される場合、ＳＲＮＳ（サービス無線ネットワークサブシステム：Serving Radio Network Subsystem）再配置によるハンドオーバ（「ハンドオフ」ともいう）も考慮しなければならないことがあるからである。（ＵＭＴＳで知られているように、ＳＲＮＳは、特定のＲＡＮだけでなく、サポート要素（例えばデータベース（図示せず））をも含む。）しかし、ＧＴＰコンプレッサ／デコンプレッサがＧＧＳＮ２２５に配置される場合、ＳＲＮＳ再配置の場合でもコンテクスト転送は不要である。
【００１６】
次に、図６〜図１０に、ＵＭＴＳネットワーク２００でＧＴＰヘッダ圧縮およびＲＴＰヘッダ圧縮を使用するための例示的なメッセージフローを示す。本発明の概念以外は、以下の説明では周知のＵＭＴＳメッセージフローを利用し、これについては説明しない。図６〜図１０では、ＧＴＰヘッダピアはＲＮＣ２１５とＧＧＳＮ２２５であり、ＲＴＰヘッダピアはＭＳ２０５とＩＰエンドホスト２４０であると仮定する。
【００１７】
図６に、図２および図５の移動局（例えば、ＭＳ２０５）が、どのようにしてＧＴＰヘッダ圧縮／伸長をネゴシエートするかを示す。"Attach Procedures"がＭＳ２０５とＲＮＣ２１５の間で実行（当業者に知られているように）された後、ＭＳ２０５は、本発明に従って、あらかじめ定義された識別子"GTP_Comp"によって表されるＧＴＰヘッダ圧縮要求を含むように修正された"Activate PDP context" request（ＰＤＰ(packet data protocol)コンテクスト起動要求）メッセージをＳＧＳＮ２２０へ送信する。これに応答して、ＳＧＳＮ２２０は、ＧＴＰヘッダ圧縮に対する要求を意味する"Create PDP context" request（ＰＤＰコンテクスト作成要求）メッセージ（"GTP_Comp"識別子を含むように修正したもの）をＧＧＳＮ２２５へ送る。ＧＧＳＮ２２５は、確認応答(acknowledgment)として、"Create PDP context" response（ＰＤＰコンテクスト作成応答）メッセージ（"GTP_Comp"識別子を含むように修正したもの）で応答する。ＳＧＳＮ２２０は、この"Create PDP context" responseメッセージを受信すると、"Activate PDP context" response（ＰＤＰコンテクスト起動応答）メッセージ（"GTP_Comp"識別子を含むように修正したもの）をＭＳ２０５に送る。
【００１８】
上記のように、ＧＴＰヘッダ圧縮コンテクストを設定するためには、GTP_Compressed（ＧＴＰ圧縮）フラグ（例えば、あらかじめ定義されたビットパターン）またはGTP Header Compression_Context IE（ＧＴＰヘッダ圧縮コンテクスト情報エレメント（ＩＥ：information element））を、従来のメッセージセットに追加する。このGTP Header Compression_Context IEは、ＧＴＰの完全なヘッダ情報を含むことになる。このエレメントが存在する場合、ＧＴＰヘッダコンテクストを設定するために完全なＧＴＰヘッダを送る必要はない。そうでない場合、ＧＴＰヘッダコンテクストを設定するために、完全なＧＴＰヘッダとともに１個以上のパケットを送信する必要が生じる場合がある。（注意すべき点であるが、ＧＴＰコンプレッサ／デコンプレッサがＳＧＳＮに配置され、ＳＲＮＳ再配置の結果ＳＧＳＮの変更が生じる場合、新ＳＧＳＮは旧ＳＧＳＮにＧＴＰコンテクスト問合せメッセージを送り、旧ＳＧＳＮが適当なＧＴＰコンテクスト応答メッセージで応答することにより、新ＳＧＳＮがＧＴＰヘッダ圧縮のための新たなコンプレッサ／デコンプレッサポイントとなることができる。
【００１９】
次に、図７に、例示的なパケットフローを示す。ＧＴＰヘッダ圧縮の場合、ＧＴＰピア（ここでは、ＲＮＣ２１５とＧＧＳＮ２２５によって表される）間でＧＴＰ圧縮ヘッダコンテクストを確立する（図７、（Ａ））ために、完全なＧＴＰヘッダを有する少なくとも１つのパケットを送信する。前述のように、パケットは、ＧＧＳＮ２２５とＲＮＣ２１５の間でＧＴＰを用いて通信される（すなわち、ＧＴＰは、ＧＧＳＮ２２５およびＲＮＣ２１５で終端する）。ＧＴＰヘッダ圧縮がネゴシエートされた後、各ＧＴＰピア（例えば、ＧＧＳＮ２２５）は、ＧＴＰに従ってパケットをフォーマットしてから、そのＧＴＰピア（ここではＲＮＣ２１５）へパケットを送信する前にＧＴＰヘッダを圧縮し（後述）、このＧＴＰピアは、ＧＴＰヘッダを圧縮解除して、ＭＳ２０５へ送信するためにペイロード（これは、ＲＴＰを含むことも含まないこともある）を回復する。同様に、逆向きには、ＲＮＣ２１５は、ＧＧＳＮ２２５へ送信するためにＧＴＰヘッダを圧縮し、ＧＧＳＮ２２５は、ＧＴＰヘッダを圧縮解除して、ペイロードを回復する。パケットは、当業者に知られているように、リンク層で、ＧＧＳＮ２２５とＩＰエンドホスト２４０の間で通信される。ＧＴＰヘッダ圧縮ネゴシエーションに続き、オプションとして、図６のＧＴＰヘッダ圧縮ネゴシエーションの場合に示したのと同様にして、ＲＴＰヘッダ圧縮を、ＭＳ２０５とＩＰエンドホスト２４０の間でネゴシエートすることも可能である（図７、（Ｂ））。
【００２０】
ＲＴＰヘッダ圧縮コンテクストメッセージ交換の例を図８に示す。（この場合も、従来のシグナリングメッセージの修正を仮定する。したがって、追加のメッセージ要件、例えば、これが"RTP context set up"（ＲＴＰコンテクスト設定）メッセージであることを識別するために、あらかじめ定義されたビット値が追加される。）最初に、２つのＲＴＰピアは、ＲＴＰヘッダ圧縮コンテクストを設定するためにシグナリングメッセージを交換する。"RTP context set up" request（ＲＴＰコンテクスト設定要求）メッセージが、一方のＲＴＰピア（例えば、ＭＳ２０５）から、他方のＲＴＰピア（例えば、ＩＰエンドホスト２４０）に送られる。"RTP context set up" response（ＲＴＰコンテクスト設定応答）メッセージが、ハンドシェイクを完了する。ＲＴＰコンテクストに変更がある場合、ＲＴＰ圧縮ヘッダ内で運ばれる追加変更（差分、デルタ）情報を示すために、適当なコンテクスト更新コードが圧縮ＲＴＰヘッダ（後述）の第１バイトに用いられる。このように、"RTP context update" request（ＲＴＰコンテクスト更新要求）メッセージは、ＲＴＰ圧縮ヘッダ内のインプリシット（暗黙的）なメッセージである。しかし、"RTP context update" response（ＲＴＰコンテクスト更新応答）メッセージは、オプションである。（注意すべき点であるが、２つのＲＴＰピア（ここでは、ＭＳ２０５およびＩＰエンドホスト２４０によって表される）の間のＲＴＰヘッダ圧縮は、帯域外シグナリングメッセージを交換してＲＴＰヘッダ圧縮を開始することも可能である。この場合も、ＧＴＰヘッダ圧縮とＲＴＰヘッダ圧縮は互いに独立であるため、必ずしもＲＴＰヘッダ圧縮をネゴシエートする必要はない（その場合、パケットは、圧縮ＧＴＰヘッダおよび非圧縮ＲＴＰペイロードからなる）。同様に、ＲＴＰヘッダ圧縮を使用するかどうかにかかわらず、必ずしもＧＴＰヘッダ圧縮をネゴシエートする必要はない。）
【００２１】
図７に戻り、ＲＴＰヘッダ圧縮コンテクストが設定された後、ＧＴＰヘッダ圧縮およびＲＴＰヘッダ圧縮を用いて、後続のパケットが送信される（図７、（Ｃ））（上記のように、ＧＴＰヘッダ圧縮およびＲＴＰヘッダ圧縮が両方とも開始されると仮定する）。ＲＴＰコンテクスト再同期が要求される場合、受信側ＲＴＰピアは、"RTP context repair"（ＲＴＰコンテクスト修復）メッセージを送信側ＲＴＰピアへ送ることができる。これを、図９、（Ｄ）に示す。ここで、受信側ＲＴＰピアはＩＰエンドホスト２４０によって表され、送信側ＲＴＰピアは、ＭＳ２０５によって表される。その後、送信側ＲＴＰピアは、完全なヘッダを有する１個以上のＲＴＰパケットを送信（図９（Ｅ））した後、圧縮ＲＴＰパケットを送信する（図９（Ｆ））。
【００２２】
同様に、ＧＴＰパケットが損失した場合、受信側ＧＴＰピアは、"GTP context repair"（ＧＴＰコンテクスト修復）メッセージを送信側ＧＴＰピアへ送ることができる。これを図１０、（Ｇ）に示す。ここで、受信側ＧＴＰピアはＧＧＳＮ２２５によって表され、送信側ＧＴＰピアはＲＮＣ２１５によって表される。その後、送信側ＧＴＰピアは、完全なＧＴＰヘッダを有する１個以上のパケットを送信（図１０、（Ｈ））した後、圧縮ＧＴＰヘッダを有するパケットを送信する（図１０、（Ｉ））。（理解されるように、この例では、ＲＴＰヘッダ圧縮同期は喪失していない。）
【００２３】
ＧＴＰヘッダ圧縮あるいはＲＴＰヘッダ圧縮のいずれに対する上記のコンテクスト修復メカニズムも、損失パケットがあれば実行される。注意すべき点であるが、再同期のために明示的なコンテクスト修復メッセージが一定期間後に送信側へ送られるように、あらかじめ定義された期間しきい値を設定することも可能である。）
【００２４】
いずれかのＧＴＰピアがＧＴＰコンテクストを破棄したい場合、ＧＴＰコンテクスト破棄メッセージ（図示せず）を送信することができる。同様に、ＲＴＰピアは、ＲＴＰコンテクスト破棄メッセージ（図示せず）の送信により、ＲＴＰコンテクストを破棄することができる。
【００２５】
ＲＴＰヘッダ圧縮
ＵＭＴＳ環境に直接に適用可能ではないが、４０バイトのＲＴＰ／ＵＤＰ／ＩＰヘッダを４〜５バイトに短縮する従来のいくつかの提案がある（例えば、
・S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", IETF RFC2508
・L. Jonsson, M. Degermark, H. Hannu and K. Svanbro, "Robust Checksum-based Header Compression", IETF internet draft, Oct 1999を参照）。そこで、図１１〜図１３に、従来のＩＰ、ＲＴＰおよびＵＤＰのヘッダフォーマットを参考のために示すが、これらについて詳細にはここでは説明しない。
【００２６】
一般に、ＩＰヘッダに関しては（現在使用されているＩＰバージョンであるＩＰｖ４の使用を仮定する）、通常、全長（パケット長、total length）、パケットＩＤ（識別）およびヘッダチェックサムフィールドのみが変化する。しかし、全長は、リンク層によっても提供されるため、冗長である。パケットＩＤは通常、各パケットごとに１または小さい数だけインクリメントされる。仮にＩＰパケット断片化がないとすると、このフィールドも通信する必要がなくなる。しかし、無損失圧縮を維持するために、パケットＩＤの変化を送信することも可能である。
【００２７】
ＵＤＰヘッダに関しては、ＩＰ全長フィールドと、長さがリンク層によって示されることのため、長さフィールドは冗長である。始点（送信元、ソース）がＵＤＰチェックサムを生成しないことを選択した場合、ＵＤＰチェックサムフィールドは常に０となる。そうでない場合、無損失圧縮を保持するために、ＵＤＰチェックサムはもとのまま通信されなければならないことを発明者は認識した。
【００２８】
ＲＴＰヘッダに関しては、与えられたコンテクストにおいて、ＳＳＲＣ（同期始点：synchronization source）識別子は一定である。これは、特定のコンテクストを識別するものの一部であるからである。ほとんどのパケットの場合、シーケンス番号およびタイムスタンプのみがパケットごとに変化する。パケットがコンプレッサの上流で損失または順序誤りを生じない場合、シーケンス番号は各パケットごとに１だけインクリメントされることになる。一定期間のオーディオパケットの場合、タイムスタンプは、各パケットで運ばれるサンプル周期の数だけインクリメントされる。ビデオの場合、タイムスタンプは、各フレームの最初のパケットで変化するが、フレーム内の後続のパケットでは一定のままである。各ビデオフレームが１パケットのみを占めるが、ビデオフレームは一定レートで生成される場合も、フレームからフレームへのタイムスタンプ変化は一定である。注意すべき点であるが、これらの各場合で、シーケンス番号およびタイムスタンプフィールドの２次差分は０であるため、次のパケットヘッダは、前の非圧縮ヘッダとともにセッションコンテクストに記憶されているこれらのフィールドに対する１次差分を加えることによって、前のパケットヘッダから構成することができる。２次差分が０でない場合、変化量は通常、フィールド内の全ビット数よりもずっと小さいため、絶対値ではなく新たな１次差分を符号化し送信することによって、サイズを縮小することができる。
【００２９】
オーディオ有音部(talkspurt)の最初のパケットおよびビデオフレームの最後のパケットではＭビットがセットされる。仮にこれを、変化ごとに完全なＲＴＰヘッダの送信を要求するような定数フィールドとして扱うと、ヘッダ圧縮の効率が大幅に低下する。従って、以下でさらに詳細に説明するように、ＲＴＰ圧縮ヘッダはＭビットを明示的に運ぶことにする。
【００３０】
パケットがＲＴＰミキサを通る場合（オーディオではほとんどの場合そうである）、ＣＳＲＣリストおよびＣＣカウントも変化する。しかし、ＣＳＲＣリストは通常、有音部以上の期間で一定であるため、変化したときにのみ送信すればよい。
【００３１】
ＲＴＰヘッダ圧縮プロトコルの一部として使用するための、圧縮ＲＴＰヘッダの例示的なフォーマットを図１４に示す。上記のように、ＲＴＰピアは圧縮ＲＴＰヘッダを送信し、ある共有情報の集まり（例えば、コンプレッサとデコンプレッサの間で一貫した状態でメモリ（図示せず）に記憶される）を維持すると仮定する。圧縮ＲＴＰヘッダは、以下のフィールドを有する。
・コンテクスト更新コード（１バイト）
・ＲＴＰ  Ｍビットに対するＭフィールド（１ビット）
・タイムクリックフィールド（７ビット）
・ＵＤＰチェックサムフィールド（２バイト）
・ＩＰパケットＩＤ（２バイト）
・ＣＳＲＣリスト（２バイト）
・ＲＴＰヘッダ拡張（２バイト）
【００３２】
コンテクスト更新フィールドの値は、どのような情報が図１４に示すＲＴＰ圧縮ヘッダに含まれるかを示す。ＲＴＰ圧縮ヘッダの最小の長さは２バイトである。ＲＴＰタイムスタンプは、タイムクリック番号（１バイト）で置換される。ＵＤＰチェックサム、ＩＰｖ４パケットＩＤ、ＣＳＲＣリストおよびＲＴＰヘッダ拡張を含める必要がある場合、圧縮ＲＴＰヘッダは図１４に示すよりも長くなる。しかし、ほとんどの場合、圧縮ＲＴＰヘッダは２バイトのみ（コンテクスト更新コードバイトと、Ｍ＋タイムクリックバイト）となる。
【００３３】
各ＲＴＰピアに記憶される共有情報に関しては、ＩＰ始点および終点アドレス、ＵＤＰ始点および終点アドレス、ならびにＲＴＰ  ＳＳＲＣフィールド（前述）の特定の組合せによって定義される、各ＩＰ／ＵＤＰ／ＲＴＰパケットストリームごとに個別のセッションコンテクストがある。維持されるセッションコンテクストの数は、コンプレッサとデコンプレッサの間でネゴシエートすることが可能である。各ＲＴＰコンテクストを、ＧＴＰ  ＴＩＤ（ＧＴＰトンネルＩＤ）にマップすることが可能である（ネゴシエート可能な最大数は６５５３６である）。各ＲＴＰヘッダ圧縮コンテクストは、固有の別個のシーケンス番号空間を有し、単一のパケット損失が１つのコンテクストしか無効にする必要がないようにしている。
【００３４】
各ＲＴＰヘッダ圧縮コンテクストにおける共有情報は、以下の項目を有する。
・完全なＩＰ、ＵＤＰおよびＲＴＰヘッダ。おそらくは、コンプレッサにより送信された、または、デコンプレッサにより再構築された最終パケットに対するＣＳＲＣリストを含む。
・ＩＰｖ４  ＩＤフィールドに対する１次差分。このコンテクストに対する非圧縮ＩＰヘッダが受信されると１に初期化され、デルタＩＰｖ４ＩＤフィールドが圧縮パケットで受信されるごとに更新される。
【００３５】
上記のように、また、図１４に示すように、圧縮ＲＴＰヘッダには、ＲＴＰヘッダ（例えば、図１３を参照）のＲＴＰタイムスタンプフィールドを置き換えるタイムクリックフィールドがある。そこで、ＲＴＰ受信側ピアにおいて、タイムクリックフィールド値からタイムスタンプ値およびシーケンス番号を計算（すなわち、回復）するメカニズムが必要である。このため、以下の定義をする。
ｓｄ：サンプル期間（単位：ｍｓ）
ＴＳold：前のパケットのタイムスタンプ番号
ＴＳnew：このパケットのタイムスタンプ番号
ＷＴold：前のパケットのウォールクロックの読み（ウォールクロック（壁掛け時計）とは、単に、ネットワーク基準クロックのことである）
ＷＴnew：このパケットのウォールクロックの読み
ＴＮold：圧縮ヘッダにおける前のパケットのタイムクリック番号
ＴＮnew：圧縮ヘッダにおけるこのパケットのタイムクリック番号
ＳＮold：前のパケットのＲＴＰシーケンス番号
ＳＮnew：このパケットのＲＴＰシーケンス番号
Ｔ：サンプル期間を単位として、ｎビットを用いて表される期間（１サイクル周期）。Ｔ＝２nサンプル（Ｔ＝２n（ｓｄ）ミリ秒（ｍｓ））
Ｍ：圧縮ヘッダにおけるＭビットの値
【００３６】
以下の式を用いて、ＲＴＰ受信側ピアにおいて、タイムクリックフィールド値からタイムスタンプ値およびシーケンス番号を計算（すなわち、回復）する。
【数１】
0004602568.tif 000002
【００３７】
有音期間中、タイムクリックフィールド値は１サンプルだけ増大する。無音期間中、タイムクリックフィールド値は、アイドル期間分（サンプル数で表される）だけ増大する。
【００３８】
タイムスタンプフィールドについて、解決すべき主要な問題は、７ビットタイムクリック番号がラップアラウンドした場合にどうするかである。無音期間中に、コンプレッサにより送信されるパケットがない場合、その無音期間の時間経過を（何個のクロックサイクルが経過したかに関して）検出しなければならない。例えば、この問題を解決するために、当業者に知られているウォールクロック（上記のように、例えば、ＷＴoldおよびＷＴnew）が用いられる。デコンプレッサにおけるこの別個のウォールクロックが、サイクルをカウントするために使用される。このウォールクロックは、粗い粒度（刻み、グラニュラリティ）で進行する（例えば、Ｔ／４の期間ごとに１だけ増大する。ただし、Ｔは、７ビットを用いて表される１サイクルの期間である）。
【００３９】
ＲＴＰシーケンス番号フィールドに関して、順序づけ（シーケンシング）が必要な場合、シーケンス番号を有する圧縮ヘッダが、Ｔ／４サンプルごとに、有音部の開始時に含められるべきである。必要であれば、完全なＲＴＰヘッダを要求するために、コンテクスト修復メッセージを送信することができる。タイムクリック値がＴ／４を超え、しかも、損失パケットがある場合には、ＲＴＰ受信側がシーケンス番号情報を有するパケットを得るまで、ＲＴＰシーケンス番号を適切に更新することができない。
【００４０】
タイムスタンプおよびシーケンス番号の回復を行うためにこの更新アルゴリズムがどのように動作するかを以下で例示する。連続するシーケンス番号１〜１８を有する１８個のパケットが、例えばＭＳ２０５から送信されると仮定する。ＲＴＰ受信側（例えば、ＩＰエンドホスト２４０）では、パケット１８のみが受信される（パケット７〜１７が失われる）とする。
【００４１】
第１の例として、シーケンス番号６のパケットが受信されるときのウォールクロック値が３（３（Ｔ／４）を意味する）であり、ＴＳold＝１１０であると仮定する。パケット１８が受信されるとき、ウォールクロック値は６である。パケット６および１８の受信時のタイムクリック値はそれぞれ１１０および７５である。上記の式を用いると、以下の計算結果が得られる。
【数２】
0004602568.tif 000003
【００４２】
次の第２の例では、ＴＳold＝３８であり、パケット６に対するウォールクロック値は５であり、パケット１８に対するウォールクロック値は９であると仮定する。パケット６および１８の受信時のタイムクリック値はそれぞれ３８および３２である。
【数３】
0004602568.tif 000004
【００４３】
次の第３の例では、ＴＳold＝５７であり、パケット６に対するウォールクロック値は６であり、パケット１８に対するウォールクロック値は９であると仮定する。パケット６および１８の受信時のタイムクリック値はそれぞれ５７および２８である。
【数４】
0004602568.tif 000005
【００４４】
ＧＴＰヘッダ圧縮
図１５に、圧縮ＧＴＰヘッダの例示的フォーマットを示す。圧縮ＧＴＰヘッダは、バージョンフィールド（Vers、３ビット）、ペイロードタイプフィールド（ＰＴ、１ビット）、拡張ビットフィールド（Ｅ、１ビット）、シーケンス番号フィールド（Ｓ、１ビット）、トンネル識別子（ＴＩＤ）存在フィールド（Ｔ、１ビット）、ＳＮＤＣＰ存在フィールド（Ｎ、１ビット）、メッセージタイプフィールド（Msg TYPE、１バイト）、２バイトの長さ（ヘッダ長、LENGTH）フィールド、２または４バイトのトンネル識別子（ＴＩＤ）フィールド、２バイトのシーケンス番号フィールド、４ビットの拡張コードフィールド、４ビットの拡張長さフィールド、および拡張内容フィールドからなる。
【００４５】
ＴＩＤフィールドに関して、最上位ビットは、ＴＩＤフィールドのサイズを示すために使用される。最上位ビットの値が０の場合、ＴＩＤフィールドサイズは２バイトである。このビットの値が１の場合、ＴＩＤフィールドサイズは４バイトである。さらに、ＴＩＤフィールドは、Ｔビットフィールドの値がセットされている場合、すなわち、２進数１に等しい場合にのみ存在する。Ｅビットフィールドは、拡張ヘッダが存在するかどうかを示すために使用される。それぞれの拡張ヘッダは、４ビットの拡張ヘッダタイプ(EXT. TYPE)フィールド、４ビットの拡張ヘッダ長(EXT. LENGTH)フィールド、および拡張内容(EXT. CONTENT)フィールド（そのサイズは、拡張ヘッダ長フィールドの値によって示される）からなる。拡張ヘッダ長フィールドの値は、２バイトの倍数で表される。例えば、ＵＤＰチェックサムが存在する必要がある場合、適当な拡張ヘッダタイプがこれに対して定義され、拡張ヘッダ長は１である（これは、ＵＤＰチェックサムの長さが２バイトであるため、拡張内容フィールドのサイズが２バイトであることを意味する）。
【００４６】
拡張ヘッダタイプフィールドの幅は４ビットであるため、１６個の拡張タイプを定義することができる。拡張ヘッダ長フィールドの幅は４ビットであるため、拡張内容フィールドの最大サイズは３２バイト（すなわち、２バイトの１６倍）である。注意すべき点であるが、さらに多くの拡張タイプを割り当てる必要がある場合、これらのフィールドのサイズを調整（例えば、それぞれのサイズを１バイトに）することも可能である。
【００４７】
各ＧＴＰヘッダ圧縮コンテクスト内の（すなわち、各ＧＴＰピアに記憶された）共有情報は、以下の項目を含む（これらの項目は、最初の「完全な」ＧＴＰヘッダで受信される値に基づいて初期化される）。
・完全なＩＰおよびＵＤＰヘッダ（この場合も、ＵＤＰチェックサムが必要な場合、受信側ＧＴＰピアは単に、受信ＵＤＰデータに基づいてそれを再計算する）。
・２バイトのフローラベルおよびＬＬＣフレーム番号。
・ＴＩＤ値。
【００４８】
上記のように、図１５に示すＧＴＰヘッダ圧縮フォーマットは、２または４バイトの選択的なＴＩＤ値をサポートする。（上記のように、ＴＩＤの９７リリースバージョンは８バイトである。しかし、ＴＩＤ値は、さらに少ないバイト数からなるように将来再定義される可能性がある（そのため、圧縮ＧＴＰヘッダにおいては、ＴＩＤ値を２または４バイトのいずれかにする選択肢がある）。図１５のＧＴＰヘッダ圧縮フォーマットにおけるＴＩＤフィールドは、ＴＩＤ情報を更新するために（Ｔビットの値を通じて）オプションとして使用される。
【００４９】
次に、図１６に、本発明の原理に従って使用される代表的なパケットサーバの高水準ブロック図を示す。パケットサーバ６０５は、蓄積プログラム制御方式のプロセッサアーキテクチャであり、プロセッサ６５０、メモリ６６０（例えば、上記のＧＴＰヘッダ圧縮などに従って通信するためのプログラム命令およびデータを記憶するためのもの）、および、パス６６６によって表される１つまたは複数のパケット通信ファシリティに接続するための通信インタフェース６６５を有する。
【００５０】
以上は本発明の原理の単なる例示であり、理解されるように、当業者であれば、ここに明示していなくても、本発明の技術的範囲内で、本発明の原理を実現するさまざまな代替実施例を考えることが可能である。例えば、ここではＵＭＴＳの場合を例示したが、本発明の概念は、トンネリングプロトコルの使用を必要とする任意のワイヤレス方式（例えば、ＵＭＴＳなど）あるいはアプリケーションに適用可能である。
【００５１】
【発明の効果】
以上述べたごとく、本発明によれば、ＧＴＰ／ＵＤＰ／ＩＰヘッダの圧縮により、ＵＭＴＳコアネットワークにおいて、小さいマルチメディアＲＴＰパケットをより効率的にトランスポートすることが可能となる。
【図面の簡単な説明】
【図１】従来の圧縮されていないＧＴＰカプセルかＲＴＰパケットを示す図である。
【図２】本発明の原理を実現するＵＭＴＳネットワークを示す図である。
【図３】移動局で用いられる例示的なプロトコルスタックを示す図である。
【図４】移動局で用いられる例示的なプロトコルスタックを示す図である。
【図５】図２のＵＭＴＳネットワークにおける例示的なコンプレッサ／デコンプレッサ配置を示す図である。
【図６】例示的なメッセージフローを示す図である。
【図７】例示的なメッセージフローを示す図である。
【図８】例示的なメッセージフローを示す図である。
【図９】例示的なメッセージフローを示す図である。
【図１０】例示的なメッセージフローを示す図である。
【図１１】従来のＩＰヘッダフォーマットを示す図である。
【図１２】従来のＵＤＰヘッダフォーマットを示す図である。
【図１３】従来のＲＴＰヘッダフォーマットを示す図である。
【図１４】圧縮ＲＴＰヘッダの例示的フォーマットを示す図である。
【図１５】圧縮ＧＴＰヘッダの例示的フォーマットを示す図である。
【図１６】本発明の原理に従ってＧＴＰヘッダ圧縮を実行する際に用いられるパケットサーバの例示的な高水準ブロック図である。
【符号の説明】
１０  非圧縮ＧＴＰカプセル化ＲＴＰパケット
１１  ＧＴＰ／ＵＤＰ／ＩＰヘッダ
１２  ＩＰ／ＵＤＰヘッダ
１３  ＧＴＰヘッダ
１４  ＧＴＰペイロード
１５  ペイロード
２０  バイトＩＰヘッダ
２００  ＵＭＴＳネットワーク
２０５  移動局（ＭＳ）
２１０  ノードＢ
２１５  無線ネットワークコントローラ（ＲＮＣ）
２２０  サービスＧＰＲＳサポートノード（ＳＧＳＮ）
２２５  ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）
２４０  ＩＰエンドホスト
６０５  パケットサーバ
６５０  プロセッサ
６６０  メモリ
６６５  通信インタフェース
【図１】
0004602568.tif 000006
【図２】
0004602568.tif 000007
【図３】
0004602568.tif 000008
【図４】
0004602568.tif 000009
【図５】
0004602568.tif 000010
【図６】
0004602568.tif 000011
【図７】
0004602568.tif 000012
【図８】
0004602568.tif 000013
【図９】
0004602568.tif 000014
【図１０】
0004602568.tif 000015
【図１１】
0004602568.tif 000016
【図１２】
0004602568.tif 000017
【図１３】
0004602568.tif 000018
【図１４】
0004602568.tif 000019
【図１５】
0004602568.tif 000020
【図１６】
0004602568.tif 000021