JP2004511178A - ヘッダ圧縮鍵を用いたリンクレイヤでのコンテクスト識別 - Google Patents

Abstract

圧縮されたヘッダ（２４’）を有するパケット（２２）を送信して通信する第１及び第２のエンティティ（２０_１及び２０_２）を有する電気通信ネットワークである。ヘッダ圧縮鍵（２３）はパケットに関連づけされる（例えばパケットに含まれる）。ヘッダ圧縮鍵は、本発明の第１のモードにおいて、圧縮されたパケットの異なるフローを区別するためだけに用いられる第１のフィールド（ＣＩＤ）を有する。本発明の第２のモードにおいて、ヘッダ圧縮鍵の第１のフィールド（２３Ａ）は圧縮されたパケットの異なるフローを区別するためもしくは異なるヘッダ圧縮識別子を区別するために利用することができる。ヘッダ圧縮鍵の第１のフィールドが、圧縮されたパケットの異なるフローを区別するためにのみ用いられる（第１のモード）か、異なるヘッダ圧縮識別子を区別するためにも用いられる（第２のモード）かは、ヘッダ圧縮鍵の第２のフィールド（２３Ｂ）の値に依存する。第２のモードにおいて、異なるヘッダ圧縮識別子を区別するために、ヘッダ圧縮鍵の第１のフィールドに対する値の第１サブセットが用いられる。一方、圧縮されたパケットの異なるフローを区別するためには、第１のフィールドに対する値の第２のサブセットが用いられる。

Description

【０００１】
（発明が属する技術分野）
本発明は電気通信ネットワークにおけるパケット伝送に関し、特にこれらパケットのヘッダ圧縮に関する。
【０００２】
（背景技術）
典型的なセルラ無線システムにおいて、移動ユーザ装置ユニット（ＵＥ）は無線アクセスネットワーク（ＲＡＮ）を介して１つ又はより多くのコアネットワークと通信する。ユーザ装置ユニット（ＵＥ）は移動電話機（”セルラ”電話機）及び移動終端機能（ｍｏｂｉｌｅ ｔｅｒｍｉｎａｔｉｏｎ）を有するラップトップコンピュータといった移動機であってよく、従って、例えば、音声及び／又はデータを無線アクセスネットワークと通信する、ポータブル装置、ポケット装置、ハンドヘルド装置、コンピュータに内蔵される移動装置又は車載の移動装置であってよい。
【０００３】
無線アクセスネットワーク（ＲＡＮ）はセル領域に分割された地理的領域をカバーし、各セル領域は基地局によってサービスされている。セルは、基地局サイトにおける無線基地局装置によって無線カバレージが提供される地理的領域である。各セルは、セル内に報知される固有のＩＤによって識別される。基地局はエアインタフェース（例えば無線周波数）を介して、その基地局の範囲内のユーザ装置ユニット（ＵＥ）と通信する。無線アクセスネットワークにおいて、いくつかの基地局は一般に無線ネットワークコントローラ（ＲＮＣ）に（例えば陸上通信線又はマイクロ波によって）接続される。基地局コントローラ（ＢＳＣ）とも呼ばれる無線ネットワークコントローラは、接続される複数の基地局の様々な動作を管理、調整する。無線ネットワークコントローラは一般に１つ又はより多くのコアネットワークに接続される。
【０００４】
無線アクセスネットワークの一例はユニバーサル移動通信システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ）陸上無線アクセスネットワーク（ＵＴＲＡＮ）である。ＵＴＲＡＮは欧州において開発された、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）として知られる無線アクセス技術に一部立脚した第３世代システムである。ＵＴＲＡＮは本質的には広帯域符号分割多元アクセス（Ｗ−ＣＤＭＡ）システムである。無線アクセスネットワークの他の例はＧＰＲＳ ＥＤＧＥ無線アクセスネットワーク（ＧＥＲＡＮ）である。
【０００５】
電気通信の世界は回線交換型のコネクションオリエンテッドな情報伝送から、パケット交換型のコネクションレス伝送へパラダイムがシフトしている。従って、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ）陸上無線アクセスネットワーク（ＵＴＲＡＮ）は回線交換型及びパケット交換型コネクションの両方に対応している。例えば、ＵＴＲＡＮにおいて、回線交換型コネクションは、移動通信交換局（ＭＳＣ）と通信する無線ネットワークコントローラ（ＲＮＣ）を含み、ＭＳＣは（例えば）公衆交換電話網（ＰＳＴＮ）及び／又は統合サービスディジタルネットワーク（ＩＳＤＮ）であるかもしれないコネクションオリエンテッドな外部コアネットワークに接続される。一方、ＵＴＲＡＮにおいてパケット交換型コネクションは在圏ＧＰＲＳサポートノード（ＳＧＳＮ）と通信する無線ネットワークコントローラを含み、ＳＧＳＮは、バックボーンネットワーク及び関門ＧＰＲＳサポートノード（ＧＧＳＮ）を通じてパケット交換ネットワーク（例えばインターネット、Ｘ．２５外部ネットワーク）に接続される。
【０００６】
ＵＴＲＡＮには興味深いいくつかのインタフェースが存在する。無線ネットワークコントローラ（ＲＮＣ）及びコアネットワークの間のインタフェースは”Ｉｕ”インタフェースと呼ばれる。無線ネットワークコントローラ（ＲＮＣ）及びその基地局との間のインタフェースは”Ｉｕｂ”インタフェースと呼ばれる。ユーザ装置ユニット（ＵＥ）及び基地局の間のインタフェースは”エアインタフェース”、”無線インタフェース”又は”Ｕｕ”インタフェースとして知られている。
【０００７】
アプリケーションへの非依存及び転送及び交換コスト削減のため、エアインタフェースからエンドユーザ装置に至る全てにおいて、パケット交換型インターネットプロトコル（ＩＰ）を利用することは魅力的である。すなわち、インターネットプロトコルをエアインタフェースの前で終端しないことには利点がある。これまで、エアインタフェースを越えてインターネットプロトコルを使用しないことの主な理由は、音声パケットに関連する所定の”ヘッダ”（例えばＩＰ／ＵＤＰ／ＲＴＰヘッダ）によって課される比較的大きなオーバヘッドであるとされてきた。
【０００８】
従って、インターネットプロトコルを用い、無線（例えばエア）インタフェースを越えて音声を伝送することの主要な問題は、インターネット上で音声データを送信する際に用いられるプロトコルの、サイズの大きなヘッダである。例えば、音声データを有するＩＰｖ４パケットはＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダを有し、これらは合計で２０＋８＋１２＝４０オクテットとなる。ＩＰｖ６ではＩＰヘッダは４０オクテットとなり、合計は６０オクテットとなる。音声データのサイズはコーデックに依存するが、１５から３０オクテットとなりうる。これらの比較的大きな数は、ＩＰ／ＵＤＰ／ＲＴＰヘッダが高ビットレートを必要とし、従って高価な無線スペクトルを不効率に使用する原因となるため、ＩＰプロトコルをエアインタフェースの前で終端することを支持しする方向に作用する。
【０００９】
これまでの説明から、比較的誤りが起こりやすく、狭帯域のセルラチャネル上で、全てのヘッダフィールドのトランスペアレンシを維持しつつ、ＩＰヘッダに関連するオーバヘッドを削減するということが、根本的に難問であることが理解される。この難問は、成功の程度は異なるが、ヘッダ圧縮技術を用いて解決される。
【００１０】
音声パケット中のヘッダ情報は全て必要だが、同じパケットストリーム、例えば同じパケットフローに属する、連続したパケットのヘッダ中のヘッダフィールド間には高い冗長性が存在する。この所見を最大限に利用し、ヘッダ圧縮アルゴリズムは一般に”コンテクスト”を維持しようとする。ヘッダ圧縮が実行されるチャネルの両端で維持されるコンテクストは、基本的に、送信された最後のヘッダの非圧縮バージョンである。圧縮されたヘッダは、数ある中でもコンテクストの変化を伝える。ヘッダ圧縮手法は一般に、コンテクストをインストールするための機構、コンテクストが無効（ｏｕｔ ｏｆ ｄａｔｅ）であることを検出するための機構及びダウンストリームコンテクストが無効の場合、それを修復するための機構を有する。
【００１１】
同一のリンクに複数の圧縮ヘッダフローが存在する場合、特定のパケット圧縮フロー（例えば特定のパケットストリーム）に属する特定の圧縮ヘッダを判定するための何らかの方法が必要である。これは、圧縮器（ｃｏｍｐｒｅｓｓｏｒ）及び伸張器（ｄｅｃｏｍｐｒｅｓｓｏｒ）が、ヘッダをどのようにして圧縮／伸張するかを決定するために状態（ｓｔａｔｅ）、すなわち、上述したコンテクストを用いるため重要である。パケット伝送の典型的なシナリオにおいて、圧縮器は特定のパケットフローに属する非圧縮のヘッダを受信し、そのヘッダを圧縮するためにそのパケットフローの正しいコンテクスト（ｃｏｒｒｅｃｔ ｃｏｎｔｅｘｔ）を用いる。圧縮されたヘッダは、このヘッダがどの特定のフローに属するのかを識別するための何らかの機構を用いて伝送される。リンクの他端で、伸張器は圧縮ヘッダを受信し、そのヘッダがどのフロー又はコンテクストに属するかを確かめる機構を用いる。そして、伸張器は、識別されたコンテクストを、そのヘッダを伸張するため用いることが可能になる。
【００１２】
ＣＴＣＰとして知られる初期のヘッダ圧縮手法が、Ｊａｃｏｂｓｏｎ， Ｖ．の「低速シリアルリンクのためのＴＣＰ／ＩＰヘッダ圧縮（Ｃｏｍｐｒｅｓｓｉｎｇ ＴＣＰ／ＩＰ Ｈｅａｄｅｒｓ ｆｏｒ Ｌｏｗ−Ｓｐｅｅｄ ＳｅｒｉａｌＬｉｎｋｓ）」、ＲＦＣ１１４４、１９９０年２月、によって提案された。ＣＴＣＰは４０オクテットのＩＰ＋ＴＣＰヘッダを４オクテット２つ（ｔｗｏ−ｆｏｕｒ ｏｃｔｅｔｓ）に圧縮する。ＣＴＣＰ圧縮器はトランスポートレベル再送信（ｔｒａｎｓｐｏｒｔ−ｌｅｖｅｌ ｒｅｔｒａｎｓｍｉｓｓｉｏｎｓ）を検出し、それが発生した際にはコンテクストを完全に更新するヘッダを送信する。
【００１３】
ＩＰヘッダ圧縮（ＩＰＨＣ）として知られる汎用ＩＰヘッダ圧縮手法は任意のＩＰ、ＴＣＰ及びＵＤＰヘッダを圧縮可能である。ＴＣＰヘッダ以外を圧縮する場合、ＩＰＨＣはデルタ符号化を用いず、ロバストである。ＴＣＰを圧縮する際、ＣＴＣＰの修復機構は修復速度を上げるリンクレベルナッキング（ｌｉｎｋ−ｌｅｖｅｌ ｎａｃｋｉｎｇ）手法によって補強される。ＩＰＨＣはＲＴＰヘッダを圧縮しない。
【００１４】
リアルタイムＩＰサービス用に、ＣＲＴＰとして知られるヘッダ圧縮手法が提案されている。Ｓ． Ｃａｓｎｅｒ， Ｖ． Ｊａｃｏｂｓｏｎによる「低速シリアルリンクのためのＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮（Ｃｏｍｐｒｅｓｓｉｎｇ ＩＰ／ＵＤＰ／ＲＴＰ Ｈｅａｄｅｒｓ ｆｏｒ Ｌｏｗ−Ｓｐｅｅｄ ＳｅｒｉａｌＬｉｎｋｓ）」、ＲＦＣ２５０８、１９９９年２月を参照されたい。ＣＲＴＰは４０オクテットのＩＰｖ４／ＵＤＰ／ＲＴＰヘッダを最小で２オクテットに圧縮することかできる。コンテクスト修復に関し、ＣＲＴＰは伸張器がヘッダ更新の要求を送信するアップストリームリンクの存在に依存している。コンテクストが無効である間、全ての受信パケットを伸張することができない。
【００１５】
ロバストヘッダ圧縮（ＲＯＨＣ）として知られるヘッダ圧縮手法は、セルラ処理（ｃｅｌｌｕｌａｒ ｕｓａｇｅ）に適している。Ｃ． Ｂｏｒｍａｎ等による、「ロバストヘッダ圧縮（ＲＯＨＣ）」、ｄｒａｆｔ−ｉｅｔｆ−ｒｏｈｃ−ｒｔｐ−０２．ｔｘｔ（作業中の未完成版）、２０００年９月を参照されたい。ＲＯＨＣにおいては、コンテクストが無効であること、ローカルで行った修復が成功したことを検出するための信頼できる方法を導入するため、元の（非圧縮の）ヘッダをカバーするチェックサムが圧縮ヘッダ中に含ませられる。ＲＯＨＣは可能な限り高い性能を達成するため、異なる種類のＲＴＰ−ストリーム及びチャネル状況を処理するための異なる圧縮プロファイルを導入する。加えて、ＲＯＨＣは、例えばセルラリンク上のロスによって、どのようにヘッダフィールドが変化したかに関するヒントを伸張器に与えるコードを圧縮ヘッダに含ませる。ＲＯＨＣにおいて、パケットタイプ識別はヘッダ圧縮手法に統合されており、従ってこの機能はリンクレイヤから必要とされない。この点に関し、ＲＯＨＣは０，１又は２バイトのコンテクスト識別子（ＣＩＤ）を有することができる。
【００１６】
第３世代パートナーシッププロジェクト（３ＧＰＰ）として知られる取り組みが、ＵＤＰ／ＩＰ及びＴＣＰ／ＩＰヘッダについてのヘッダ圧縮を含む、将来的なＵＴＲＡＮ及びＧＳＭベースの無線アクセスネットワーク技術を発展させようと努めている。ヘッダ圧縮手法にとって重要な３ＧＰＰシステムの１つの見知は、（（例えば、インターネットといった）完全に共有されたチャネルに代わる）論理的に分離されたチャネル又は無線ベアラのコンセプトである。圧縮ヘッダの伸張にどのコンテクストを用いるべきかを識別するために、コンテクスト識別子（ＣＩＤ）を利用することが提案されている。Ｓ． Ｃａｓｎｅｒ， Ｖ． Ｊａｃｏｂｓｏｎによる「低速シリアルリンクのためのＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮（Ｃｏｍｐｒｅｓｓｉｎｇ ＩＰ／ＵＤＰ／ＲＴＰ Ｈｅａｄｅｒｓ ｆｏｒ Ｌｏｗ−Ｓｐｅｅｄ ＳｅｒｉａｌＬｉｎｋｓ）」、ＲＦＣ２５０８、１９９９年２月及び、Ｍｉｌａｅｌ Ｄｅｇｅｒｍａｒｋ， Ｂｊｏｒｎ Ｎｏｒｄｇｒｅｎ， Ｓｔｅｐｈｅｎ Ｐｉｎｋによる「ＩＰヘッダ圧縮」、ＲＦＣ２５０７、１９９９年２月を参照のこと。３ＧＰＰセルラシステムにおいては、既に異なる無線ベアラ上へトラフィックを多重分離（ｄｅ−ｍｕｌｔｉｐｌｅｘｉｎｇ）しており（無線ベアラの定義が必要。図ＴＳ２５．３０１の無線プロトコルインタフェースアーキテクチャが必要）、この分離はコンテクスト識別の必要性を削減している。そのため、無線ベアラ当たりのコンテクスト数は比較的小さい（このような感じで）。
【００１７】
第３世代パートナーシッププロジェクト（３ＧＰＰ）仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）は、パケットデータ集中プロトコル（ｐａｃｋｅｔ ｄａｔａ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｔｏｃｏｌ：ＰＤＣＰ）と呼ばれるリンクレイヤプロトコルを記述する。パケットデータ集中プロトコル（ＰＤＣＰ）の主な機能の一部は、（１）無線リンクコントロール（ＲＬＣ）プロトコルによって提供されるサービスを用いるパケットデータプロトコルユーザデータの転送及び、（２）ヘッダ圧縮（例えば、冗長制御情報の圧縮）である。パケットデータ集中プロトコル（ＰＤＣＰ）はそのサービスを、ユーザ装置ユニット（ＵＥ）における、又は無線ネットワークコントローラ（ＲＮＣ）のリレーにおけるＰＤＣＰエンティティを経由して提供する。現在の形式（例えば、ＴＳ２５．３２３ Ｖ．３．３．０）では、パケットデータ集中プロトコル（ＰＤＣＰ）において全ての無線ベアラが１つのＰＤＣＰエンティティに接続され、１つのＰＤＣＰエンティティが１つのＲＬＣエンティティに接続される。全てのＰＤＣＰエンティティは、所定のパラメータを用いる０、１又はいくつかのヘッダ圧縮アルゴリズム形式を用い、いくつかのＰＤＣＰエンティティは同一のアルゴリズム形式を用いうる。
【００１８】
パケットデータ集中プロトコル（ＰＤＣＰ）において、ヘッダ圧縮方法は各ネットワークレイヤプロトコル形式に固有である。ヘッダ圧縮アルゴリズム及びそのパラメータは各ＰＤＣＰエンティティに対する無線資源コントロール（ＲＲＣ）によって取り決められ、ＰＤＣＰコントロールサービスアクセスポイント（ＰＤＣＰ−Ｃ−ＳＡＰ）を通じてＰＤＣＰへ指示される。圧縮器及び伸張器が発するピアＰＤＣＰエンティティ間のシグナリングが、動作中にユーザプレーンで実行される。
【００１９】
３ＧＰＰ仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）に示されるように、パケットデータ集中プロトコル（ＰＤＣＰ）は３つの形式の１つを取りうるプロトコルデータユニット（ＰＤＵ）を特徴とする。第１の形式はＰＤＣＰ−Ｎｏ−ＨｅａｄｅｒＰＤＵ、第２の形式はＰＤＣＰ ＤａｔａＰＤＵ、第３の形式はＰＤＣＰ ＳｅｑＮｕｍＰＤＵである。ＰＤＣＰ ＤａｔａＰＤＵ及びＰＤＣＰ ＳｅｑＮｕｍＰＤＵは３ビットのＰＤＵ形式フィールドと５ビットのＰＩＤフィールドを含む。３ビットのＰＤＵ形式フィールドの値は、そのＰＤＵがＰＤＣＰ ＤａｔａＰＤＵ及びＰＤＣＰ ＳｅｑＮｕｍＰＤＵのどちらであるかを示す（３ＧＰＰ仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）、セクション８．３．１を参照）。５ビットのＰＩＤフィールドは使用されたヘッダ圧縮及びパケット形式を示す。
【００２０】
３ビットのＰＤＵ形式フィールド及び５ビットのＰＩＤフィールドを有するＰＤＣＰ ＤａｔａＰＤＵは、３ＧＰＰ仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）に示される。以下の表１は、ＰＤＣＰ ＤａｔａＰＤＵについての５ビットのＰＩＤフィールドに対するＰＩＤ値の例を示すものとして、３ＧＰＰ仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）から抜粋したものである。
【００２１】
【表１】

【００２２】
３ＧＰＰ仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）、セクション５．１．１に記述されるように、ＰＣＤＰエンティティにおける所定のアルゴリズムに対するＰＩＤ値の割り当ては（ｎ＋１）から開始する（ｎは他のアルゴリズムに既に割り当てされているＰＩＤ値の数）。この割り当ては無線資源コントロールによってアルゴリズムが取り決められた順番で行われる。表１の例において、ＲＦＣ２５０７はピア無線資源コントロールエンティティ間で交換されるＰＤＣＰ情報エレメントにおいて割り当てされた最初のアルゴリズム、方法Ａは２番目のアルゴリズム、方法Ｂは３番目のアルゴリズムである。
【００２３】
コンテクストを区別するための上述の機構は、コンテクスト識別子（ＣＩＤ）の利用によってヘッダ圧縮手法内に明示されてもよいし、圧縮されたフローを区別するためのリンクレイヤ機構によって暗示されても良い。明示的なＣＩＤの利用は、ヘッダ圧縮レベルにおけるＲＯＨＣ技術と同様、圧縮ヘッダ中に余分なビットを必要とする。一方、パケットデータ集中プロトコル（ＰＤＣＰ）といったリンクレイヤレベルでの暗示的なコンテクスト識別の利用は、リンクレイヤレベルにおいて更なるコストを課す。
【００２４】
ＰＤＣＰヘッダを用いない手法（３ＧＰＰ仕様書３Ｇ　ＴＳ２５．３２３ Ｖ３．３．０（２０００−０９）、セクション８．２．１を参照）では、ＰＤＣＰによるヘッダ圧縮パケット形式のリンクレイヤ識別を提供できる可能性はない。これは、ＰＤＣＰがヘッダを用いないというオプションを用いて設定されている場合には、ＩＰヘッダ圧縮（ＲＦＣ２５０７）を使用できないことを意味する。しかし、ヘッダ圧縮パケット形式識別がＲＯＨＣ内部で完結される際には、ＲＯＨＣアルゴリズムを用いることができる。
【００２５】
ＲＯＨＣがＲＴＰ／ＵＤＰ／ＩＰ圧縮をサポート可能であるのに対し、ＲＦＣ２５０７圧縮アルゴリズムは（他にもあるが）ＴＣＰ／ＩＰ圧縮をサポートする。将来、ＲＴＰ／ＵＤＰ／ＩＰ及びＴＣＰ／ＩＰトラフィックの両方を調和させるための所定のアプリケーションは、ストリーミングサービス（例えば、リアルタイムマルチメディアアプリケーション）等において有用になると思われる。
【００２６】
従って、リンクレベルにおいてパケット形式識別が必要な１つ又はそれより多くの圧縮アルゴリズムによって圧縮されたヘッダを有するパケットを、リンクレベルにおいてパケット形式識別が不要な１つ又はそれより多くの圧縮アルゴリズムによって圧縮されたヘッダを有するパケットとの混合を容易にする方法が必要とされており、同時に本発明の目的である。
【００２７】
（発明の概要）
電気通信ネットワークは、圧縮されたヘッダを有するパケットを送信することによって通信する第１及び第２のエンティティを有する。ヘッダ圧縮鍵がパケットに関連づけされる（例えばパケットに含まれる）。ヘッダ圧縮鍵は、本発明の第１のモードにおいて、圧縮されたパケットの異なるフローを区別するためだけに用いられる第１のフィールドを有する。本発明の第２のモードにおいて、ヘッダ圧縮鍵の第１のフィールドは圧縮されたパケットの異なるフローを区別するためもしくは異なるヘッダ圧縮識別子を区別するために利用することができる。
【００２８】
ヘッダ圧縮鍵の第１のフィールドが、圧縮されたパケットの異なるフローを区別するためにのみ用いられる（第１のモード）か、異なるヘッダ圧縮識別子を区別するためにも用いられる（第２のモード）かは、ヘッダ圧縮鍵の第２のフィールドの値に依存する。
【００２９】
第２のモードにおいて、異なるヘッダ圧縮識別子を区別するために、ヘッダ圧縮鍵の第１のフィールドに対する値の第１サブセットが用いられる。一方、圧縮されたパケットの異なるフローを区別するためには、第１のフィールドに対する値の第２のサブセットが用いられる。第２のサブセットの値は第１のサブセットの値の後に続くことが好ましい。
【００３０】
１つの例示的な実施形態において、ヘッダ圧縮鍵はリンクレイヤプロトコルのプロトコルデータユニットのヘッダであり、特にパケットデータ集中プロトコル（ＰＤＣＰ）と呼ばれるプロトコルに関するプロトコルデータユニットについてのヘッダである。本実施形態において、第１のフィールドはプロトコルデータユニットのヘッダのＰＩＤ形式フィールド、第２のフィールドはプロトコルデータユニットのヘッダのＰＤＵ形式フィールドである。圧縮されたパケットの異なるフローの識別は、圧縮／伸張アルゴリズムに関するコンテクスト識別子によって実行され、圧縮／伸張アルゴリズムは好ましくはロバストヘッダ圧縮（ＲＯＨＣ）等のリンクレイヤレベルでパケット形式識別を必要としないアルゴリズムである。第２のモードについて、本実施形態におけるヘッダ圧縮識別子はヘッダ圧縮方法及びパケット形式を意味する。
【００３１】
本発明の実装例は、第１のエンティティが無線ネットワークコントローラノード（ＲＮＣ）に位置するヘッダ圧縮／伸張エンティティであり、第２のエンティティがユーザ装置ユニット（ＵＥ）、例えばセルラ電話機又は移動終端機能を有する他の装置におけるヘッダ圧縮／伸張エンティティであるセルラ電気通信ネットワークである。
【００３２】
本発明は、有利なことに、プロトコルデータユニットのデータ部分（例えば、ヘッダでない部分）で伝送される圧縮レベルヘッダ（例えば、ＲＯＨＣヘッダ）が、そのコンテクスト識別子を省略することを可能にする。これは、リンクレイヤプロトコルデータユニットのヘッダ中でコンテクスト識別子が代わりに伝送されるためである。従って、本発明はヘッダ伝送に関連するオーバヘッドを削減することが可能である。さらに、本発明は、圧縮／伸張方法がリンクレベルでパケット形式識別を必要とするか否かにかかわらず、圧縮／伸張方法の混合、例えばロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズム及びＲＦＣ２５０７等のＩＰヘッダ圧縮アルゴリズムの混合を容易にする。このような混合は、ＲＴＰ／ＵＤＰ／ＩＰトラフィック（ＲＯＨＣを用いる）とＴＣＰ／ＩＰトラフィック（ＲＦＣ２５０７を用いる）の混合といった、複雑なアプリケーションの組み合わせのサポートを可能にする。
【００３３】
本発明の上述した目的及び他の目的、特徴及び長所は、参照数字が様々な図面を通じて同一部分を参照する添付図面に図示される好適な実施形態の、以下のより具体的な説明から明らかになるであろう。図面は必ずしも縮尺されておらず、代わりに本発明の原理の説明に強調が加えられている。
【００３４】
（発明の詳細な説明）
以下の説明においては、限定ではなく説明を目的として、本発明の完全な理解を与えるため、特定のアーキテクチャ、インタフェース、方法等の特定の詳細が記述される。しかし、本技術分野に属する当業者は本発明がこれら特定の詳細を離れた他の実施形態においても実施されうることを理解するであろう。他の事例において、周知の装置、回路及び方法の詳細な説明は、本発明の説明が不要な詳細によってわかりにくくならないように省略される。
【００３５】
図１は、本発明の例示的な、それに限定されない実施形態としての電気通信ネットワーク１０を示す。電気通信ネットワーク１０は、パケット２２を送信することによってリンク２１を介して互いに通信する第１及び第２の集中プロトコルエンティティ２０_１、２０_２を有する。以下に説明するように、本発明によれば、パケット２２は圧縮されたヘッダ２４’及びペイロード２５を含むデータ部分のみならす、ヘッダ圧縮鍵２３を用いる。
【００３６】
図１の実施形態例において、第１及び第２の集中プロトコルエンティティ２０_１、２０_２は電気通信ネットワークの各ノード２６_１、２６_２に位置している。図１に示される特定のシナリオにおいて、ノード２６_１はユーザプレーンから複数のパケットストリームＰＦ_Ｘ、例えばパケットフローＰＦ_０−ＰＦ_ｎを受信する。パケットフローＰＦ_ｘの各パケットは非圧縮ヘッダ２４及びペイロード２５を有する。パケットがノード２６_１で受信されると、様々な動作が実行される。本発明に密接に関係するのは、ノード２６_１の集中プロトコルエンティティ２０_１に含まれる圧縮エンティティシステム２９_１によって実行されるヘッダ圧縮動作である。ヘッダ圧縮と関連して、圧縮エンティティシステム２９_１はコンテクスト識別子（ＣＩＤ）を各パケットに対して生成する。例えば、図１は、パケットフローＰＦ_０内のパケットに対して生成されたコンテクスト識別子ＣＩＤ_０及びパケットフローＰＦ_ｎ内のパケットに対して生成されたコンテクスト識別子ＣＩＤ_ｎを示している。ＰＦ_ｘからＣＩＤ_ｙへのマッピングは任意（ｘ及びｙの範囲は０からｎ）であり、一般にはｘ＝ｙである。
【００３７】
ノード２６_１に入来する各パケットに対し、集中プロトコルエンティティ２０_１は、図１においてパケット２２としても図示されるリンクレイヤプロトコルデータユニットを生成する。図示の実施形態において、リンクレイヤプロトコルデータユニット２２は図示される２つのレイヤのうちレイヤ１もしくは最低位のレイヤであるリンク２１上を、ノード２６_２の集中プロトコルエンティティ２０_１からノード２６_２の集中プロトコルエンティティ２０_２へ伝送される。リンクレイヤプロトコルデータユニット（パケット２２）は、おそらくヘッダを有し、そのようなヘッダの一部又は全部は、本明細書においてヘッダ圧縮鍵２３としても参照される。集中プロトコルエンティティ２０_１は、ヘッダ圧縮鍵２３を生成又はフォーマットする鍵フォーマッタ部１００_１を含む。いくつかのパケットフロー（例えば、ＩＰ／ＵＤＰ／ＲＴＰ及びＴＣＰ／ＩＰフロー）が鍵フォーマッタ部１００_１に入来すると、鍵フォーマッタ部１００_１は適切なヘッダ圧縮鍵２３を構築し、このヘッダ圧縮鍵２３はペイロード２５に付加される。
【００３８】
受信があると、ノード２６_２の集中プロトコルエンティティ２０_２は、リンク２１を介して受信したパケットに、ヘッダ圧縮鍵２３をデフォーマットするための鍵でフォーマッタ１００_２及びヘッダ２４’を伸張するための伸張システム２９_２の呼び出しを含む様々な動作を実行する。伸張後、ノード２６_２は、ノード２６_２から（例えば、ユーザプレーンへ向かって）発する適切なパケットフローＰＦ_ｘへパケットをルーティングすることが可能となる。
【００３９】
上述したように、パケット又はリンクレイヤプロトコルデータユニット２２は、パケット２２のリンクレイヤプロトコルデータ部分に鍵２３を含んでいる。一実施形態において、鍵２３は本質的にリンクレイヤプロトコルデータユニット２２に対するヘッダであり、集中プロトコルエンティティ２０_１に含まれる鍵フォーマット機能１００_１によって生成される。パケット２２のリンクプロトコルデータ部分は圧縮されたヘッダ２４’（圧縮エンティティシステム２９_１の圧縮動作によって得られる）及びユーザプレーンパケットのペイロード２５を含む。
【００４０】
図２は、ノード２６_１の集中プロトコルエンティティ２０_１からノード２６_２の集中プロトコルエンティティ２０_２へ移動するリンクレイヤプロトコルデータユニット２２又はパケットを多少拡大して示している。図２の図示された実施形態において、ヘッダ圧縮鍵２３はリンクレイヤプロトコルデータユニット２２の第１オクテットであり、２つのフィールド、具体的には第１のフィールド２３Ａ及び第２のフィールド２３Ｂを有する。ここではたまたま、ヘッダ圧縮鍵２３において下位５ビットが第１のフィールド２３Ａを、上位３ビットが第２のフィールド２３Ｂを構成しているが、他の実施形態でこれらフィールドの配置及びサイズが変化しうることを理解すべきである。
【００４１】
本発明は様々なモードで動作することが可能であり、そのうち２つが図２で第１のモード及び第２のモードとして示されている。第２のフィールド２３Ｂの値は所与のパケットに対して本発明のどのモードが用いられているかを示す。例えば、第２のフィールド２３Ｂ中のビットパターン０１０は本発明の第１のモードが適用可能であることを示すことが可能であり、一方第２のフィールド２３Ｂ中のビットパターン０００は本発明の第２モードが適用可能であることを示すことができる。もちろん、第２のフィールド２３Ｂに対して他のビットパターンの取り決めを用いることができる。さらに、２３Ｂはコンテクスト識別とともに用いるべき特定のヘッダ圧縮アルゴリズムを示すことも可能である。
【００４２】
本発明の第１のモードにおいて、第１のフィールド２３Ａの値は圧縮されたパケットの異なるフローを区別するためだけに用いられる。換言すれば、ヘッダ圧縮鍵２３の第２のフィールド２３Ｂが、第１のモードが実施されていることを示す場合、第１のフィールド２３Ａはコンテクスト識別子（ＣＩＤ）を格納していることが理解される。この本発明の第１のモードにおいて、第１のフィールド２３Ａ中の数の全てはコンテクスト識別子（ＣＩＤ）であり、その結果コンテクスト識別子（ＣＩＤ）の番号付けは０から始まり、新しいパケットフローの各々について１つずつ増加しうる。
【００４３】
本発明の第２のモードにおいて、ヘッダ圧縮鍵の第１のフィールド２３Ａは異なるヘッダ圧縮識別子を区別するため、又は圧縮パケットの異なるフローを区別するために利用できる。具体的には、第２のモードにおいて、異なるヘッダ圧縮識別子を区別するためにヘッダ圧縮鍵の第１のフィールド２３Ａに対する値の第１のサブセットが用いられ、一方圧縮パケットの異なるフローを区別するために第１のフィールド２３Ａに対する値の第２のサブセットが用いられる。第２のサブセットの値は第１のサブセットの値に引き続くことが好ましい。
【００４４】
第２のモードの例として、ヘッダ圧縮鍵２３の第１のフィールド２３Ａの値の最初のｋ個の値はｋ個の異なるヘッダ圧縮識別子（例えば、ヘッダ圧縮識別子０から（ｋ−１））を区別するために用いられる。第１のフィールド２３Ａの残りの値は１つ又はそれより多いヘッダ圧縮アルゴリズムに対する圧縮されたパケット（ＣＩＤ）の異なるフローを区別するために用いることができる。従って、第１のフィールド２３Ａが５ビットを有する場合、第１のフィールド２３ＡのＫ＋１番目から３２番目の値を圧縮コンテクスト識別子と呼ぶことができる。
【００４５】
これまでの説明から、ヘッダ圧縮鍵２３の第１のフィールド２３Ａ中の値が、取りうる値の最初のｋ番目までの１つであれば、それはヘッダ圧縮識別子として認識される。一方、ヘッダ圧縮鍵２３の第１のフィールド２３Ａ中の値が、取りうる値の最初のｋ番目の外側（例えばそれより大きい）であれば、それはフロー識別子（例えばＣＩＤ）として認識される。
【００４６】
図１は、２つのノード２６_１及び２６_２を含む汎用的な電気通信ネットワークにおいて本発明がそのヘッダ圧縮鍵２３とともに実装可能であることを示している。他の、例示的な、それに限定されない本発明の実装は、第１のエンティティが無線ネットワークコントローラノード（ＲＮＣ）に位置するヘッダ圧縮／伸張エンティティであり、第２のエンティティが例えばセルラ電話機又は移動終端機能を有する他の装置であるユーザ装置ユニット（ＵＥ）内のヘッダ圧縮／伸張エンティティであるセルラ電気通信ネットワークである。このような実装のための構成の一例であり、それに限定されない構成は、図３に示すユニバーサル移動通信システム（ＵＭＴＳ）３−１０である。他の例はＧＥＲＡＮ、又はＰＤＣＰレイヤをエアインタフェースプロトコルスタックで用いる他の任意の無線アクセスネットワークである。
【００４７】
図３のユニバーサル移動通信システム（ＵＭＴＳ）３−１０において、雲形３−１２として示される、代表的な、コネクションオリエンテッドな外部コアネットワークは、例えば公衆交換電話網（ＰＳＴＮ）及び／又は統合サービスディジタルネットワーク（ＩＳＤＮ）であろう。雲形３−１４として示される、代表的な、コネクションレスオリエンテッドな外部コアネットワークは、、例えばインターネットであろう。両コアネットワークは対応するサービスノード３−１６に接続される。ＰＳＴＮ／ＩＳＤＮコネクションオリエンテッドネットワーク３−１２は移動通信交換局（ＭＳＣ）ノード３−１８として示される、回線交換サービスを提供するコネクションオリエンテッドサービスノードに接続される。インターネットコネクションレスオリエンテッドネットワーク３−１４はパケット交換タイプのサービスを提供するように調整された、時には在圏ＧＰＲＳサービスノード（ＳＧＳＮ）とも呼ばれる汎用パケット無線サービス（ＧＰＲＳ）ノードに接続される。
【００４８】
コアネットワークサービスノード３−１８及び３−２０の各々は、Ｉｕインタフェースと呼ばれる無線アクセスネットワークインタフェースを介してＵＭＴＳ陸上無線アクセスネットワーク（ＵＴＲＡＮ）３−２４に接続する。ＵＴＲＡＮ３−２４は１つかそれより多い無線ネットワークコントローラ（ＲＮＣ）３−２６を含む。便宜上、図３のＵＴＲＡＮ３−２４は１つだけのＲＮＣノード３−２６とともに示されている。各ＲＮＣ３−２６は一般に複数の基地局（ＢＳ）３−２８に接続される。例として、ここでも便宜上、１つの基地局３−２８がＲＮＣ３−２６に接続された状態を示す。各ＲＮＣが異なる数の基地局を扱いうること、またこれらＲＮＣが同一数の基地局を取り扱う必要がないことは理解されるであろう。
【００４９】
図３に示される、ユーザ装置ユニット（ＵＥ）３−３０といったユーザ装置ユニット（ＵＥ）は、無線又はエアインタフェース３−３２を介して１つ又はそれより多い基地局（ＢＳ）３−２８と通信する無線インタフェース３−３２、Ｉｕインタフェース及びＩｕｂインタフェースは図３において一点鎖線で示されている。
【００５０】
好ましくは、無線アクセスは個々の無線チャネルがＣＤＭＡ拡散符号を用いて割り当てされる広帯域の符号分割多元アクセス（ＷＣＤＭＡ）に基づく。もちろん、他のアクセス方法、例えばＧＥＲＡＮを用いることも可能である。ＷＣＤＭＡは広い帯域幅をマルチメディアサービス及び他の高伝送速度要求に対して提供するとともに、高品質を保証するためのダイバーシチハンドオフ及びＲＡＫＥ受信器のようなロバスト性を高める機能を提供する。基地局３−２８が特定のユーザ装置ユニット（ＵＥ）からの伝送を識別するためのみならず、ユーザ装置ユニット（ＵＥ）が基地局からそのユーザ装置ユニット（ＵＥ）に宛てられた伝送を、同一領域内に存在する他の全ての伝送及び雑音から識別するため、ユーザ移動機又は装置ユニット（ＵＥ）３−３０の各々は、固有のスクランブル符号を割り当てられる。
【００５１】
図４はユーザ装置ユニット（ＵＥ）３−３０の選択された一般面及び無線ネットワークコントローラ３−２６及び基地局３−２８といったノードの具体例を示す。図４に示すユーザ装置ユニット（ＵＥ）３−３０は、ユーザ装置ユニット（ＵＥ）によって要求された様々な動作を制御するためのデータ処理及び制御部３−３１を含んでいる。ＵＥのデータ処理及び制御部３−３１はアンテナ３−３５に接続された無線送受信器にデータ及び制御信号を供給する。
【００５２】
図４に示す例示的な無線ネットワークコントローラ３−２６及び基地局３−２８はその各々が、ＲＮＣ３−２６とユーザ装置ユニット（ＵＥ）３−３０間での通信を行うのに必要な様々な動作を制御するための、対応するデータ処理及び制御部３−３６及び３−３７を含む無線ネットワークノードである。基地局データ処理及び制御部３−３７によって制御される装置の一部には、１つ又はそれより多いアンテナ３−３９に接続される複数の無線送受信器３−３８が含まれる。
【００５３】
図３及び図４のユニバーサル移動通信システム（ＵＭＴＳ）３−１０において、集中プロトコルエンティティ２０_１及び集中プロトコルエンティティ２０_２はそれぞれパケットデータ集中プロトコル（ＰＤＣＰ）エンティティ２０_１及び２０_２の形態を取っている。ＰＤＣＰエンティティ２０_１及び２０_２はそれぞれ無線ネットワークコントローラ（ＲＮＣ）ノード３−２６及びユーザ装置ユニット（ＵＥ）３−３０に位置している。従って、その意味では、ユーザ装置ユニット（ＵＥ）３−３０は少なくともリンクレイヤに関連するノードとして見ることができる。図１の実施形態のように、ＰＤＣＰエンティティ２０_１及び２０_２はそれぞれ圧縮システム２９_１及び２９_２を有する。また、図１の鍵フォーマッタ／デフォーマッタ機能１００と同様に、ＰＤＣＰエンティティ２０_１及び２０_２はそれぞれＰＤＣＰ ＰＤＵヘッダフォーマッタ／デフォーマッタ１００_１及び１００_２を有する。
【００５４】
図３に示される時点では、無線ネットワークコントロール（ＲＮＣ）ノード３−２６からユーザ装置ユニット（ＵＥ）３−３０への方向のパケットフローのみが示されている。この時点で、ＰＤＣＰエンティティ２０_１は（本発明のヘッダ圧縮鍵２３を挿入するＰＤＣＰ ＰＤＵヘッダフォーマッタ／デフォーマッタ１００を用いて）ヘッダ圧縮を実行しており、その間ＰＤＣＰエンティティ２０_２は伸張等を実行している。しかし、パケットフローは通常双方向性であり、パケットはユーザ装置ユニット（ＵＥ）３−３０から無線ネットワークコントロール（ＲＮＣ）ノード３−２６へも移動し、このパケットに対してＰＤＣＰエンティティ２０_２が（本発明のヘッダ圧縮鍵２３を挿入するＰＤＣＰ ＰＤＵヘッダフォーマッタ／デフォーマッタ１００_２を用いて）ヘッダ圧縮を実行し、その間ＰＤＣＰエンティティ２０_１は伸張を実行することを理解すべきである。
【００５５】
図３及び図４の実施形態例において、ヘッダ圧縮鍵はリンクレイヤプロトコルのプロトコルデータユニットのヘッダであり、特にパケットデータ集中プロトコル（ＰＤＣＰ）として知られるプロトコルについてのプロトコルデータユニットのヘッダである。上述したように、パケットデータ集中プロトコル（ＰＤＣＰ）は例えば第３世代パートナーシッププロジェクト（３ＧＰＰ）仕様書３Ｇ ＴＳ ２５．３２３ Ｖ３．３．０（２０００−０９）に記載されている。図３及び図４の実施形態において、ヘッダ圧縮鍵２３の第１のフィールド２３Ａはプロトコルデータユニット（ＰＤＵ）のヘッダのＰＩＤ形式フィールドであり、第２のフィールド２３Ｂはプロトコルデータユニット（ＰＤＵ）のヘッダのＰＤＵ形式フィールドである。
【００５６】
図５は図１と似ているが、ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）に対するプロトコルデータユニットのヘッダであり、またパケットフローがインターネットプロトコル（ＩＰ）パケットフローである、図３及び図４の実施形態の特別な場合を示している。この実施形態例において、圧縮されたパケットの異なるフロー間の区別は、ヘッダ圧縮鍵２３のＰＩＤフィールド（例えば、フィールド２３Ａ）に挿入される、圧縮／伸張アルゴリズムについてのコンテクスト識別子によって容易になる。圧縮／伸張アルゴリズムについてのコンテクスト識別子（ＣＩＤ）は、リンクレイヤでのパケット形式識別を必要としないロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズムのような圧縮／伸張アルゴリズムに関するものであることが好ましい。
【００５７】
図５及び図６から、ＰＤＣＰサービスデータユニット（ＰＤＣＰ ＳＤＵ）として知られるパケットが、ユーザプレーンから（ＰＤＣＰエンティティ２０_１といった）ＰＤＣＰエンティティで受信されることがわかる。ＰＤＣＰ ＳＤＵは一般にヘッダ２４及びペイロード２５を含む。本実施形態においてＰＤＣＰ ＳＤＵヘッダ２４はＩＰヘッダ、ＵＤＰヘッダ及びＲＴＰヘッダ（これらを全てまとめてＩＰヘッダと呼ぶ）を含んでいる。別の例としては、ＰＤＣＰ ＳＤＵヘッダ２４がＩＰヘッダ及びＴＣＰヘッダを有する。ＲＯＨＣ圧縮アルゴリズムの使用において、圧縮エンティティ２９_１はヘッダ２４を圧縮し、圧縮ヘッダ２４’を形成する。圧縮ヘッダ２４’はまた、図６においてＲＯＨＣヘッダと呼ばれる。ペイロート又はデータ２５は圧縮ヘッダ２４’とともにＰＤＣＰ ＰＤＵデータを形成する。ここで検討される一実施形態例において、圧縮ヘッダ２４’はＲＯＨＣヘッダだが、任意のヘッダ圧縮アルゴリズムから圧縮ヘッダを挿入することが可能である。
【００５８】
ＰＤＣＰエンティティ２０_１はＰＤＣＰプロトコルデータユニット（ＰＤＣＰ ＰＤＵ）を生成する。動作のあるケース（図６に示すケースＡ）において、ＰＤＣＰ ＰＤＵはＰＤＣＰ ＰＤＵヘッダとして知られるヘッダを有する。しかし、動作の他のケース（図６に示すケースＢ）においては、ＰＤＣＰ ＰＤＵはヘッダを持つ必要がない（第３世代パートナーシッププロジェクト（３ＧＰＰ）仕様書３Ｇ ＴＳ ２５．３２３ Ｖ３．３．０（２０００−０９）、セクション８．２．１を参照）。ＰＤＣＰヘッダが含まれる場合には、上述したように、ＰＤＣＰ ＤＰＵヘッダフォーマッタ／デフォーマッタ１００がヘッダ圧縮鍵２３を含むようにＰＤＣＰヘッダを生成する。
【００５９】
図５及び図６によっても説明される図３及び図４の実施形態は、（本質的に図１の実施形態と同様にして）本発明の第１のモード又は第２のモードで動作可能である。第１のモードにおいて、ＰＤＣＰ ＰＤＵヘッダのＰＩＤフィールド２３Ａは圧縮パケットの異なるフロー間の区別のためにのみ用いられ、従ってＰＩＤフィールド２３Ａ内の全ての数はコンテクスト識別子（ＣＩＤ）と見なされる。本発明の第２のモードにおいて、ＰＩＤフィールド２３Ａの値が値の第１のサブセット又は範囲内であれば、ＰＩＤフィールド２３Ａの中身は特定の圧縮識別子（ｃｏｍｐｒｅｓｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）であると見なされる。一方、第２のモードにおいて、ＰＩＤフィールド２３Ａの値が値の第２のサブセット又は範囲内であれば、ＰＩＤフィールド２３Ａの中身は異なるパケットフローを区別するための特定のコンテクスト識別子（ＣＩＤ）であると見なされる。
【００６０】
図１の実施形態のように、フィールド２３Ｂ、例えばＰＤＵ形式フィールドの中身は、ＰＤＣＰ ＰＤＵが第１のモード又は第２のモードのどちらの対象であるかを示す。ＰＤＵ形式フィールドにおけるビットパターンを表２に説明する。
【００６１】
【表２】

【００６２】
表３は、ＰＩＤフィールド２３Ａが５ビットであるとした場合、本発明の第１のモードにおいて、ＰＩＤフィールド２３ＡにどのようにＣＩＤ値が割り当てられるかを説明する。表３において、ＲＦＣｘｘｘｘは例えばＲＦＣ２５０７といった任意のＲＦＣ関連圧縮手法を参照することが可能である。
【００６３】
【表３】

【００６４】
表４は、ＰＩＤフィールド２３Ａが同じビットサイズ（５ビット）であると仮定して、ＲＯＨＣ及びＲＦＣ２５０７圧縮の両方で同じＰＤＣＰ ＰＤＵ形式がが使用される際に、本発明の第２のモードに従ってＰＩＤフィールド２３ＡにＣＩＤ値がどのように割り当てされるかを説明する。図４に示す特定の状況において、ＰＩＤ値の最初の１０個は表１と同様に割り当てられている。
【００６５】
【表４】

【００６６】
図６に示すように、ＲＯＨＣ圧縮ヘッダ２４’は自らのパケット形式を表すことが可能であるため、ＰＤＣＰヘッダ２３は明示的には必要とされない。しかし、ＲＯＨＣ圧縮ヘッダ２４’はコンテクストフローを識別するためにＣＩＤフィールドを必要とする。ＣＩＤフィールドはＲＯＨＣ圧縮ヘッダ２４’中８ビット又は１６ビットの長さを取りうる。コンテクストＩＤ（ＣＩＤ）がヘッダ圧縮鍵２３（例えば、ＰＤＣＰ ＰＤＵヘッダ）のＰＩＤフィールド２３Ａのフォーマットの中で表現できる場合、ＣＩＤ表示は代わりにＰＤＣＰ ＰＤＵヘッダの中で行うことが可能であり、その場合にはＲＯＨＣ圧縮ヘッダ２４’のＣＩＤフィールドは節約のために除去することができる。
【００６７】
上述の説明及び表４から、ＲＯＨＣパケット形式又はコンテクスト識別子（ＣＩＤ）の数が、フィールド２３Ａ（例えばＰＩＤフィールド）のサイズ及び、既に圧縮識別子が使用している（例えばＲＦＣ２５０７圧縮が使用している）値のサブセットのサイズに依存することが理解されるであろう。ＲＦＣ２５０７パケット形式に対する圧縮識別子の一般的な数は約６であろうと考えられ、それによってフィールド２３Ａが２６のパケットフロー（ＣＩＤ）にも対応することを可能にしている。好ましい実施形態において、パケットフローがヘッダ圧縮鍵２３に含まれるＣＩＤを有する場合（例えば、ＰＤＣＰ ＰＤＵヘッダのＰＩＤフィールド）、そのＣＩＤがＲＯＨＣ圧縮ヘッダ２４’に含まれる必要はない（例えば、ＲＯＨＣはその”０バイトＣＩＤモード”（０−ｂｙｔｅ−ＣＩＤ−ｍｏｄｅ）で動作することが可能である）。
【００６８】
フィールド２３Ａがパケットフローの数に対応するための利用可能な十分な値を第２のサブセットに持たない場合には、ＲＯＨＣがバックボーンにおいても使用可能であることに留意すべきであり、その場合には存在し得るより多くのフローをサポートするために１又は２バイトのＣＩＤフィールドを利用することが可能である。すなわち、ＲＯＨＣパケット（例えば図６の、例えば圧縮パケット２４’）にはさらなるＣＩＤ値を含めることが可能である。
【００６９】
図７は、本発明に利用可能な、例示的な、それに限定されないＲＮＣノード３−２６をいくぶん詳細に示している。図７のＲＮＣノード３−２６はたまたま切替器３−２６−１２０を有する交換回線ベースのノードである。切替器３−２６−１２０はＲＮＣノード３−２６の他の構成要素の相互接続を提供する。このような他の構成要素は、拡張端子（ｅｘｔｅｎｓｉｏｎ ｔｅｒｍｉｎａｌ）３−２６−１２４及び拡張端子３−２６−１２２_１〜３−２６−１２２_ｎを含む。基本的に、拡張端子３−２６−１２２_１〜３−２６−１２２_ｎはＲＮＣノード３−２６をＲＮＣノード３−２６によってサービス提供される基地局３−２８に接続し、拡張端子３−２６−１２４はＲＮＣノード３−２６をＩｕインタフェースを越えてコアネットワークへ接続するように機能する。図示していないが、ＲＮＣノード３−２６をＩｕｒインタフェースとして知られる別のインタフェースを越えて他のＲＮＣへ接続するための、１つ又はそれより多い拡張端子がおそらく存在する。
【００７０】
ＲＮＣノード３−２６の更に他の構成要素は、ダイバーシチハンドオーバ装置３−２６−１２６、ＡＬＴ部３−２６−１２８、コーデック３−２６−１３０、タイミング装置３−２６−１３２、データサービスアプリケーション装置３−２６−１３４及びメインプロセッサ３−２６−１４０を含む。本技術分野に属する当業者は通常これら構成要素の機能を理解するであろう。ＡＬＴ装置３−２６−１２８は例えば、セルの、異なるプロトコルに関して、多重化及び多重分離並びに（オプションで）待機を提供する装置である。図７の例示的なＲＮＣノード３−２６において、メインプロセッサ３−２６−１４０がＰＤＣＰエンティティ２０を提供し、従ってＰＤＣＰ ＤＰＵヘッダフォーマッタ／デフォーマッタ１００を提供する。
【００７１】
図８は、本発明の一実施形態に係る基地局（ＢＳ）ノード３−２８の例の更なる詳細を、それに限定されることなく示している。ＲＮＣノード３−２６と同様に、図８の基地局（ＢＳ）ノード３−２８は、基地局（ＢＳ）ノード３−２８の他の構成要素の相互接続を提供する切替器３−２８−２２０を有する交換回線ベースのノードである。このような他の構成要素は、拡張端子３−２８−２２２、ＡＬＴ装置３−２８−２２８、ＢＳメインプロセッサ３−２８−２４０及びインタフェース基板３−２８−４２を含む。
【００７２】
拡張端子３−２８−２２は、基地局（ＢＳ）ノード３−２８を無線ネットワークコントローラ（ＲＮＣ）ノード３−２６に接続し、従ってＩｕｂインタフェースを備える。無線ネットワークコントローラ（ＲＮＣ）ノード３−２６と同様に、ＡＬＴ装置３−２８−２２８はセルの異なるプロトコルに関して例えば多重化及び多重分離並びに（オプションで）待機を提供する。
【００７３】
図８に示される基地局（ＢＳ）ノード３−２８の具体化は、複数のサブラックを有するラックに収容される。各サブラックはそこに実装される１つ又はそれより多い基板、例えば回路基板を有する。第１のサブラック３−２８−２５０は拡張端子３−２８−２２２、ＡＬＴ装置３−２８−２２８、ＢＳメインプロセッサ３ー２８−２４０及びインタフェース基板３−２８−４２のそれぞれに対する基板を格納する。各インタフェース基板３−２８−２４２は別のサブラック上の基板、例えば送信器基板３−２８−２６０の１つ又は受信器基板２−２８−２７０の１つに接続される。各受信器基板３−２８−２７０は対応する送信器基板３−２８−２６０内の所定の送信器／受信器資源を共用するため、送信器基板３−２８−２６０に接続される。送信器基板３−２８−２６０は増幅器及びフィルタ基板３−２８−２８０の対応する１つに接続される。増幅器及びフィルタ基板３−２８−２８０は適切なアンテナ３−３９に接続される。例えば、インタフェース基板３−２８−２４２_１−Ｔは送信器基板３−２８−６０_１に接続され、一方インタフェース基板３−２８−２４２_１−Ｒは受信器基板３−２８−２７０_１に接続される。送信器基板３−２８−２６０_１及び受信器基板３−２８−２７０_１の組は、次いで増幅器及びフィルタ基板３−２８−２８０_１に接続される。同様の接続が送信器基板３−２８−２６０_２及び受信器基板３−２８−２７０_２の２番目の組についても存在し、それぞれインタフェース基板３−２８−２４２_２−Ｔ及びインタフェース基板３−２８−２４２_２−Ｒを介してインタフェースする。図４の送受信器３−３８の各々は、このようにして、送信器基板３−２８−２６０、受信器基板３−２８−２７０及び増幅器及びフィルタ基板３−２８−２８０を含むサブラックを構成する。
【００７４】
一実施形態例において、基地局（ＢＳ）ノード３−２８は様々なＡＴＭインタフェース機能を実行するインタフェース基板３−２８−２４２を有する、ＡＴＭに基づくノードである。送信器基板３−２８−２６０及び受信器基板３ー２８−２７０の各々は、いくつかの装置を含む。例えば、各送信器基板３−２８−２６０は、対応するインタフェース基板３−２８−２４２に接続されるインタフェース、符号化器、変調器及びベースバンド送信器といった、図示しない要素を含む。さらに、送信器基板３−２８−２６０は、受信器基板３ー２８−２７０と共用する送信器／受信器資源を含む。この送信器／受信器資源には無線周波数送信器を含む。各受信器基板３−２８−２７０は、対応するインタフェース基板３−２８−２４２に接続されるインタフェース、復号化器、復調器及びベースバンド受信器といった、図示しない要素を含む。増幅器及びフィルタ基板３−２８−２８０の各々は例えばＭＣＰＡ及びＬＮＡ増幅器といった増幅器を含む。
【００７５】
本発明は、有利なことに、プロトコルデータユニットのデータ部分（例えば、ヘッダでない部分）で伝送される圧縮レベルヘッダ（例えば、ＲＯＨＣヘッダ）が、そのコンテクスト識別子を省略することを可能にする。これは、リンクレイヤプロトコルデータユニットのヘッダ中でコンテクスト識別子が代わりに伝送されるためである。従って、本発明はヘッダ伝送に関連するオーバヘッドを削減することが可能である。さらに、本発明は、圧縮／伸張方法がリンクレベルでパケット形式識別を必要とするか否かにかかわらず、圧縮／伸張方法の混合、例えばロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズム及びＲＦＣ２５０７等のＩＰヘッダ圧縮アルゴリズムの混合を容易にする。このような混合は、ＲＴＰ／ＵＤＰ／ＩＰトラフィック（ＲＯＨＣを用いる）とＴＣＰ／ＩＰトラフィック（ＲＦＣ２５０７を用いる）の混合といった、複雑なアプリケーションの組み合わせのサポートを可能にする。
【００７６】
便宜上、図１の実施形態においてノード２６はそれぞれ１つの集中プロトコルエンティティ２０を有するものとして記述してきた。同様に、またこれも便宜上、図３及び図４の実施形態においてＲＮＣ３−２６及びユーザ装置ユニット（ＵＥ）３−３０の各々が１つのＰＤＣＰエンティティ２０を有するものとして記述してきた。しかし、図１Ａにおいて説明した例示方法と同様に、各ノード（例えば、ＲＮＣ又はＵＥ）は、実際には複数のエンティティ２０を備え得る。例えば、図１Ａの代表ノード２６は３つの集中プロトコルエンティティ２０Ａ〜２０Ｃを有し、各集中プロトコルエンティティは１つかそれより多い圧縮エンティティ（例えば、各々が異なる圧縮／伸張アルゴリズムを実行する複数の圧縮／伸張エンジン）を有する。例えば、集中プロトコルエンティティ２０Ａが圧縮エンティティ３０Ａ_１及び３０Ａ_２を、集中プロトコルエンティティ２０Ｂが圧縮エンティティ３０Ｂ_１及び３０Ｂ_２を、集中プロトコルエンティティ２０Ａが圧縮エンティティ３０Ａ_１及び３０Ａ_２を、集中プロトコルエンティティ２０Ｃが圧縮エンティティ３０Ｃ_１を有する。集中プロトコルエンティティ２０Ａ〜２０Ｃの１つ又はそれより多くが同一又は類似の圧縮エンティティを有しても良い。例えば、圧縮エンティティ３０Ｃ_１が圧縮エンティティ３０Ａ_１と同じ圧縮アルゴリズムを実施しても良い。
【００７７】
ここで、本発明がＲＯＨＣ及びＲＦＣｘｘｘｘ（例えばＲＦＣ２５０７）圧縮アルゴリズムの利用に制限されず、他の圧縮アルゴリズムが完全に本発明の範囲内に含まれることを、特に図１の汎用的な実施形態に関して理解すべきである。ＲＯＨＣを用いて実施する場合には、ＲＯＨＣをＲＦＣ２５０７とともに用いる場合、例えばＴＣＰ／ＩＰ（ベストエフォート）フロー及びＲＴＰ／ＵＤＰ／ＩＰ（リアルタイム）が同一のＰＤＣＰヘッダに含まれる場合には、少なくともＲＯＨＣパケット当たり１バイトのオーバヘッドが省かれる。
【００７８】
本発明を現時点で最も現実的で好ましいと実施形態であると思われるものに関して説明してきたが、本発明が開示された実施形態に限定されるべきものではなく、むしろ添付の請求項の精神及び範囲内に含まれる様々な変形物及び等価構成を含むことを意図していることを理解すべきである。
【図面の簡単な説明】
【図１】
本発明の実施形態によるヘッダ圧縮鍵を用いるヘッダ圧縮手法を実施する電気通信ネットワークの機能ブロック図である。
【図１Ａ】
図１に示すような電気通信ネットワークのノードが本発明の実施形態に従って複数の集中プロトコルエンティティを有しうることを示す機能ブロック図である。
【図２】
ヘッダ圧縮鍵を用いるリンクレイヤプロトコルデータユニットのフォーマット例を示す図である。
【図３】
本発明のヘッダ圧縮鍵を好適に利用可能な移動通信システムの例を示す図である。
【図４】
ユーザ装置ユニット（ＵＥ）局、無線ネットワークコントローラ及び基地局を含む、図３のシステムの一部を単純化した機能ブロック図である。
【図５】
ヘッダ圧縮鍵の実現をさらに詳細に示す、図３の電気通信ネットワークの機能ブロック図である。
【図６】
図３〜５の実施形態に係るＰＤＣＰ　ＳＤＵ及びＰＤＣＰ　ＰＤＵのフォーマット例を示す図である。
【図７】
本発明の一実施形態に係るＲＮＣノードの例を示す模式図である。
【図８】
本発明の一実施形態に係る基地局ノードの例を示す模式図である。

Claims (54)

1. 圧縮されたヘッダ（２４’）を有するパケット（２２）を送信して第２のエンティティ（２０_２）と通信する第１のエンティティ（２０_１）を有する電気通信ネットワークであって、
   前記第１のエンティティがさらに前記第２のエンティティへ前記パケットに関するヘッダ圧縮鍵（２３）を送信するとともに、前記ヘッダ圧縮鍵２３が、圧縮されたパケットの異なるフローを区別するために用いられる第１のフィールド（２３Ａ）を有することを特徴とする電気通信ネットワーク。
2. 圧縮されたヘッダ（２４’）を有するパケット（２２）を送信して第２のエンティティ（２０_２）と通信する第１のエンティティ（２０_１）を有する、セルラ電気通信ネットワークのノード（２６）であって、
   前記第１のエンティティがさらに前記第２のエンティティへ前記パケットに関するヘッダ圧縮鍵（２３）を送信するとともに、前記ヘッダ圧縮鍵２３が、圧縮されたパケットの異なるフロー（ＰＦ_０〜ＰＦ_ｎ）を区別するために用いられる第１のフィールド（２３Ａ）を有することを特徴とするノード。
3. 圧縮されたヘッダ（２４’）を有するパケット（２２）を送信して、セルラ電気通信ネットワークのノード（２６）に位置する第２のエンティティ（２０_２）と通信する第１のエンティティ（２０_１）を有するユーザ装置ユニット（ＵＥ）（３−３０）であって、
   前記第１のエンティティがさらに前記第２のエンティティへ前記パケットに関するヘッダ圧縮鍵（２３）を送信するとともに、前記ヘッダ圧縮鍵２３が、圧縮されたパケットの異なるフロー（ＰＦ_０〜ＰＦ_ｎ）を区別するために用いられる第１のフィールド（２３Ａ）を有することを特徴とするユーザ装置ユニット。
4. 前記ヘッダ圧縮鍵の前記第１のフィールドに対する値の第１のサブセットが、異なるヘッダ圧縮識別子を区別するために用いられ、前記第１のフィールドに対する値の第２のサブセットが前記圧縮されたパケットの異なるフローを区別するために用いられることを特徴とする請求項１、請求項２又は請求項３に記載の装置。
5. 前記第２のサブセットの値が、前記第１のサブセットの値の後に続くことを特徴とする請求項４記載の装置。
6. 前記ヘッダ圧縮識別子がヘッダ圧縮方法及びパケット形式を示すことを特徴とする請求項４記載の装置。
7. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットのヘッダに含まれることを特徴とする請求項４記載の装置。
8. 前記ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）についてのプロトコルデータユニットのヘッダであり、前記第１のフィールドがＰＩＤ形式フィールドであることを特徴とする請求項７記載の装置。
9. 前記値の第２のサブセットが圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項４記載の装置。
10. 前記値の第２のサブセットが、リンクレイヤレベルでのパケット形式識別を必要としない圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項４記載の装置。
11. 前記圧縮／伸張アルゴリズムがロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズムであることを特徴とする請求項１０記載の装置。
12. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットに含まれることを特徴とする請求項４記載の装置。
13. 前記ヘッダ圧縮鍵が、前記ヘッダ圧縮鍵（２３）の前記第１のフィールド（２３Ａ）が、前記圧縮されたパケットの異なるフローの区別のみに使用されるか否かを示すために用いられる第２のフィールド（２３Ｂ）を有することを特徴とする請求項１、請求項２又は請求項３に記載の装置。
14. 前記ヘッダ圧縮鍵の前記第２のフィールドの第１の値が、前記ヘッダ圧縮鍵の前記第１のフィールドが前記圧縮されたパケットの異なるフローの区別のみに使用されることを示し、前記ヘッダ圧縮鍵の前記第２のフィールドの第２の値が、その値に応じて、ヘッダ圧縮識別子又はパケットフロー識別子のいずれかであり得る前記ヘッダ圧縮鍵の前記第１のフィールド内のデータを示すことを特徴とする請求項１３記載の装置。
15. 前記ヘッダ圧縮鍵の前記第１のフィールドの前記データが、値の第１のサブセットに含まれる場合、異なるヘッダ圧縮識別子を区別し、
    前記ヘッダ圧縮鍵の前記第１のフィールドの前記データが、値の第２のサブセットに含まれる場合、圧縮されたパケットの異なるフローを区別することを特徴とする請求項１４記載の装置。
16. 前記第２のサブセットの値が、前記第１のサブセットの値の後に続くことを特徴とする請求項１５記載の装置。
17. 前記ヘッダ圧縮識別子がヘッダ圧縮方法及びパケット形式を示すことを特徴とする請求項１５記載の装置。
18. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットのヘッダに含まれることを特徴とする請求項１５記載の装置。
19. 前記ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）についてのプロトコルデータユニットのヘッダに含まれ、前記第１のフィールドがＰＩＤ形式フィールドであることを特徴とする請求項１８記載の装置。
20. 前記値の第２のサブセットが圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項１５記載の装置。
21. 前記値の第２のサブセットが、リンクレイヤレベルでのパケット形式識別を必要としない圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項２０記載の装置。
22. 前記圧縮／伸張アルゴリズムがロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズムであることを特徴とする請求項２１記載の装置。
23. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットのヘッダに含まれることを特徴とする請求項１３記載の装置。
24. 前記ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）についてのプロトコルデータユニットのヘッダに含まれ、前記第２のフィールドがＰＤＵ形式フィールドであることを特徴とする請求項２３記載の装置。
25. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットに含まれることを特徴とする請求項１３記載の装置。
26. 前記パケットがインターネットプロトコル（ＩＰ）パケットであることを特徴とする請求項１、請求項２又は請求項３に記載の装置。
27. 前記電気通信ネットワークがセルラ電気通信ネットワークであり、前記第１のエンティティが少なくとも部分的にエアインタフェース（３−３２）を介して前記第２のエンティティと通信することを特徴とする請求項１、請求項２又は請求項３記載の装置。
28. 前記電気通信ネットワークがセルラ電気通信ネットワークであり、前記第１のエンティティ及び前記第２のエンティティの少なくとも一方が無線ネットワークコントローラノード（ＲＮＣ）及びユーザ装置ユニット（ＵＥ）の一方に位置していることを特徴とする請求項１、請求項２又は請求項３記載の装置。
29. 圧縮されたヘッダ（２４’）を有するパケット（２２）を送信して第２のエンティティ（２０_２）と通信する第１のエンティティ（２０_１）を有する電気通信ネットワークを操作する方法であって、
    前記第１のエンティティがさらに前記第２のエンティティへ前記パケットに関するヘッダ圧縮鍵（２３）を送信するステップを有し、
    前記ヘッダ圧縮鍵２３が、圧縮されたパケットの異なるフロー（ＰＦ_０〜ＰＦ_ｎ）を区別するために用いられる第１のフィールド（２３Ａ）を有することを特徴とする方法。
30. 前記ヘッダ圧縮鍵の前記第１のフィールドに対する値の第１のサブセットが、異なるヘッダ圧縮識別子を区別するために用いられ、前記第１のフィールドに対する値の第２のサブセットが前記圧縮されたパケットの異なるフローを区別するために用いられることを特徴とする請求項２９記載の方法。
31. 前記第２のサブセットの値が、前記第１のサブセットの値の後に続くことを特徴とする請求項３０記載の方法。
32. 前記ヘッダ圧縮識別子がヘッダ圧縮方法及びパケット形式を示すことを特徴とする請求項３０記載の方法。
33. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットのヘッダに含まれることを特徴とする請求項３０記載の方法。
34. 前記ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）についてのプロトコルデータユニットのヘッダであり、前記第１のフィールドがＰＩＤ形式フィールドであることを特徴とする請求項３３記載の方法。
35. 前記値の第２のサブセットが圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項３０記載の方法。
36. 前記値の第２のサブセットが、リンクレイヤレベルでのパケット形式識別を必要としない圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項３０記載の方法。
37. 前記圧縮／伸張アルゴリズムがロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズムであることを特徴とする請求項３６記載の方法。
38. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットに含まれることを特徴とする請求項３０記載の方法。
39. 前記ヘッダ圧縮鍵が、前記ヘッダ圧縮鍵（２３）の前記第１のフィールド（２３Ａ）が、前記圧縮されたパケットの異なるフローの区別のみに使用されるか否かを示すために用いられる第２のフィールド（２３Ｂ）を有することを特徴とする請求項２９記載の方法。
40. 前記ヘッダ圧縮鍵の前記第２のフィールドの第１の値が、前記ヘッダ圧縮鍵の前記第１のフィールドが前記圧縮されたパケットの異なるフローの区別のみに使用されることを示し、前記ヘッダ圧縮鍵の前記第２のフィールドの第２の値が、その値に応じて、ヘッダ圧縮識別子又はパケットフロー識別子のいずれかであり得る前記ヘッダ圧縮鍵の前記第１のフィールド内のデータを示すことを特徴とする請求項３９記載の方法。
41. 前記ヘッダ圧縮鍵の前記第１のフィールドの前記データが、値の第１のサブセットに含まれる場合、異なるヘッダ圧縮識別子を区別し、
    前記ヘッダ圧縮鍵の前記第１のフィールドの前記データが、値の第２のサブセットに含まれる場合、圧縮されたパケットの異なるフローを区別することを特徴とする請求項４０記載の方法。
42. 前記第２のサブセットの値が、前記第１のサブセットの値の後に続くことを特徴とする請求項４１記載の方法。
43. 前記ヘッダ圧縮識別子がヘッダ圧縮方法及びパケット形式を示すことを特徴とする請求項４１記載の方法。
44. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットのヘッダに含まれることを特徴とする請求項４１記載の方法。
45. 前記ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）についてのプロトコルデータユニットのヘッダに含まれ、前記第１のフィールドがＰＩＤ形式フィールドであることを特徴とする請求項４４記載の方法。
46. 前記値の第２のサブセットが圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項４４記載の方法。
47. 前記値の第２のサブセットが、リンクレイヤレベルでのパケット形式識別を必要としない圧縮／伸張アルゴリズムについてのコンテクスト識別子を含むことを特徴とする請求項４６記載の方法。
48. 前記圧縮／伸張アルゴリズムがロバストヘッダ圧縮（ＲＯＨＣ）アルゴリズムであることを特徴とする請求項４７記載の方法。
49. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットのヘッダに含まれることを特徴とする請求項３９記載の方法。
50. 前記ヘッダ圧縮鍵がパケットデータ集中プロトコル（ＰＤＣＰ）についてのプロトコルデータユニットのヘッダに含まれ、前記第２のフィールドがＰＤＵ形式フィールドであることを特徴とする請求項４９記載の方法。
51. 前記ヘッダ圧縮鍵がリンクレイヤプロトコルのプロトコルデータユニットに含まれることを特徴とする請求項３９記載の方法。
52. 前記パケットがインターネットプロトコル（ＩＰ）パケットであることを特徴とする請求項２９記載の方法。
53. 前記電気通信ネットワークがセルラ電気通信ネットワークであり、前記第１のエンティティが少なくとも部分的にエアインタフェース（３−３２）を介して前記第２のエンティティと通信することを特徴とする請求項２９記載の方法。
54. 前記電気通信ネットワークがセルラ電気通信ネットワークであり、前記第１のエンティティ及び前記第２のエンティティの少なくとも一方が無線ネットワークコントローラノード（ＲＮＣ）及びユーザ装置ユニット（ＵＥ）の一方に位置していることを特徴とする請求項２９記載の方法。

Images