JP3857688B2 - データパケット接続におけるヘッダ圧縮識別子の伝送 - Google Patents

Description

本発明は、データパケット接続のための、特に移動体通信システムに圧縮を適用する際のヘッダ圧縮の決定に関する。

過去数年間のＩＰ（インターネットプロトコル）技術の急速な進展により、従来のインターネットデータ伝送の域を越えた様々なＩＰベースのアプリケーションの好適な使用法が拡大している。特に、ＩＰベースの電話アプリケーションは急速に改良されており、この結果、基本的にＩＰ技術を従来の交換電話網（ＰＳＴＮ／ＩＳＤＮ（公衆交換電話網／統合デジタル通信網））と移動体通信網（ＰＬＭＮ（Ｐｕｂｌｉｃ Ｌａｎｄ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋ））との両方において利用して実現可能な通話伝送路の比率は拡大の一途にある。

特に、移動体通信網の場合には、様々なＩＰ音声アプリケーションによって実現可能な従来の通話サービスに加え、通常、パケット交換によるＩＰベースのサービスとして実現するのが最も有利なインターネットブラウジング、電子メールサービス、及びゲームなどの様々なデータサービスが提供されるため、ＩＰ技術により、種々の利点を享受することができる。即ち、移動体通信システムのプロトコルにＩＰレイヤを包含すれば、オーディオ／ビデオサービス及び様々なデータサービスの両方をサービスできるようになるのである。

移動体通信網の場合、限られたリソースを可能な限り効率的に利用することが特に重要である。しかしながら、ＩＰベースのプロトコルの場合には、伝送対象のデータにおける様々なヘッダの比率が非常に大きいため（従って、ペイロードの比率が小さくなり）、無線インターフェースにおけるＩＰプロトコルの効率的な利用は困難である。更に、不良な通信状態においては、無線インターフェースのビット誤り率（ＢＥＲ）とアップリンク及びダウンリンクの往復時間（ＲＴＴ）が大幅に増大し、この結果、大部分の従来技術によるヘッダ圧縮法において問題が発生する。このため、様々なＩＰプロトコル及び無線インターフェースにおけるデータ伝送に適したヘッダ圧縮法（特に、ビット誤り率と遅延が大幅に増大する状態において利用可能なヘッダの効率的な圧縮法）を考案することが求められていた。

ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が、最近、ＲＯＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ：ロバストヘッダ圧縮）と呼ばれるヘッダ圧縮法を標準化したのは、これを理由とするものである。このＲＯＨＣ開発の基礎となった考え方の１つが、データパケット転送に使用される種々のＩＰヘッダ間には、データパケット内だけでなく、それらの間にも、多数の冗長性が存在しているという事実である。即ち、ヘッダ内の大部分の情報は、データパケットの伝送時にまったく変化しておらず、従って、それらを伝送しなくても、受信端においてヘッダ内に含まれる情報を容易に再構築可能であり、圧縮において注意を要する情報を含んでいるのは少数のヘッダに過ぎないのである。又、ＲＯＨＣは、いくつかの圧縮レベルを有しており、上位の圧縮レベルにシフトするほど圧縮効率が上昇する。ＲＯＨＣでは、利用可能な最も効率の高い圧縮を使用するべく常に試みるが、次のレベルにシフトする前に、その対象のレベルにおける動作が十分な信頼性を有していることを常に確認する。

ＲＯＨＣにおいては、同一無線リンクにおいて伝送される複数のパケットデータフローをコンテキスト識別子ＣＩＤによって相互に区別している。このコンテキスト識別子は、伝送対象のデータパケットに付加され、受信者は、このコンテキスト識別子により、そのデータパケットが属するパケットデータフローと圧縮コンテキストを判定することができる。第３世代移動体通信システム、特に、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）に適用する際には、少なくとも２つの方法により、コンテキスト識別子ＣＩＤを伝送対象のデータパケットに付加することができる。まず、コンテキスト識別子は、ＲＯＨＣの内部手順において付加することが可能であり、ＲＯＨＣ規格によれば、圧縮データパケットは、コンテキスト識別子ＣＩＤを付加するための固有のＣＩＤフィールドを有している。もう１つの選択肢は、移動体通信システムのプロトコルレイヤのデータパケットヘッダ（コンバージェンスプロトコルレイヤのデータパケットヘッダが好ましい）に対してコンテキスト識別子を付加（又は、関連付け）し、この結果、ＲＯＨＣ規格に準拠して圧縮データパケットにコンテキスト識別子ＣＩＤを含めるのではなく、そのＲＯＨＣ圧縮プロトコルパケットがマッピングされたコンバージェンスデータパケット（特に、このデータパケットのヘッダ）にコンテキスト識別子又はこれに関連する識別子を付加するようにする方法である。

ＵＭＴＳ規格（３ＧＰＰ ＴＳ ２５．３２３、第４．０．０版、第５．１．３節）には、ＲＯＨＣ圧縮を使用する際には、前述の方法のいずれかを選択しなければならないと定義されているが、その選択方法については定義されていない。従って、この選択を実行できるようにＵＭＴＳシステムを設定する方法の発明が求められているのである。

本発明の目的は、前述の欠点を軽減する方法及びこの方法を実現する装置を提供することにある。本発明のこの目的は、独立請求項における開示内容によって特徴付けられる方法及びシステムによって達成される。又、本発明の好適な実施例については、従属請求項に記述されている。

本発明は、データパケットのヘッダにおいて利用可能なスペース、即ち、利用可能なＰＩＤ値の数、とＲＯＨＣがコンバージェンスプロトコルレイヤなどの通信システムのプロトコルレイヤにおいて所与の時点で利用可能なコンテキスト識別子ＣＩＤの数の比較に基づいたものであり、利用可能なＰＩＤ値がＲＯＨＣに対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回っている場合に、好ましくは、ＣＩＤ値はコンバージェンスプロトコルレイヤのデータパケットに付加される。この結果、無線インターフェースにおいて伝送されるデータ内のヘッダ比率を極小化し、ＣＩＤ値の伝送の設定に必要なシグナリングを削減することが可能となる。一方、コンテキスト識別子ＣＩＤの数が利用可能なＰＩＤ値の数を上回っている場合には、コンテキスト識別子は常にＲＯＨＣデータパケットのＣＩＤフィールドに付加される。

本発明の好適な実施例により、この方法を移動体通信システムに適用する場合には、移動局と無線ネットワークの両方に同一の比較アルゴリズムが保存され、この結果、パケットデータ接続の両端に位置する両方の主体がこのアルゴリズムを使用しコンテキスト識別子の伝送に使用する方法を選択できるようになる。この場合には、好ましいことに、移動局と無線ネットワークの間に別個のシグナリングが不要であり、使用する方法を両方の主体が自動的に設定することができる。

本発明の別の好適な実施例によれば、好ましくは、比較アルゴリズムを無線ネットワーク側にのみ保存することが可能であり、前述の比較は、無線ネットワークにおいて実行される。無線ネットワークは、コンテキスト識別子の伝送に使用する方法を定義した後に、その決定内容について、好ましくは、ＲＲＣシグナリングにより、移動局に通知する。

本発明の方法及びシステムの利点は、ＣＩＤ値の伝送方法を判定することが可能であり、且つその方法を使用するべく移動局ＭＳと無線ネットワークＵＴＲＡＮの両方を設定できることである。本発明による方法が有する別の利点は、無線インターフェースで伝送するデータの合計量におけるヘッダの比率を最適化できることである。本発明の更なる利点は、既存のシグナリングに対するごくわずかの変更により（好ましくは、変更なしに）、実現可能なことである。本発明によれば、無線リソースの効率的な利用が可能となる一方で、システムに対する変更の必要性は軽減されており、有利である。

以下の添付図面を参照し、好適な実施例を利用して本発明について詳細に説明する。
まず、ＲＯＨＣヘッダ圧縮法の実現について基本的に説明する。この圧縮法の詳細については、ＲＦＣ３０９５の「Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）」を参照されたい。

通常、それぞれの圧縮法は、コンプレッサとデコンプレッサの両方のコンテキストを判定する段階を有しており、このコンテキストとは、伝送するヘッダを圧縮するためにコンプレッサが使用し、且つ受信したヘッダを圧縮解除するためにデコンプレッサが使用する状態を表している。このコンテキストには、通常、データ伝送接続において伝送された（コンプレッサ）又は受信された（デコンプレッサ）先行ヘッダの非圧縮バージョンが含まれている。又、コンテキストには、データパケットのシーケンス番号やタイムスタンプなどのデータパケットフローを識別するデータを含むこともできる。従って、コンテキストには、通常、パケットフローの全体を通じて同一に維持される静的な情報と、パケットフローにおいて変化する（但し、判定可能なパターンで変化することが多い）動的な情報の両方が含まれている。

ＲＯＨＣでは、３つの圧縮レベルが採用されており、圧縮は最下位レベルから始まり、徐々に上位レベルにシフトする。常に可能な限り高いレベルで圧縮を実行することが基本原則となっているが、対象のレベルにおいて圧縮解除を実行するに十分な情報をデコンプレッサが有しており、デコンプレッサをコンプレッサが信頼できる状態でなければならない。異なる圧縮レベル間の遷移に影響を与える要因としては、連続するヘッダにおける変動、デコンプレッサから受信する肯定的又は否定的なアクノリッジ、並びに、アクノリッジを使用しない場合には、特定のシーケンスカウンタの満了が含まれる。尚、必要に応じて、上位圧縮レベルから下位レベルへの遷移も同様に可能である。

ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、及びＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）プロトコルとの関連でＲＯＨＣにおいて使用される圧縮レベルは、ＩＲ（Ｉｎｉｔｉａｔｉｏｎ／Ｒｅｆｒｅｓｈ ｏｒｄｅｒ）、ＦＯ（Ｆｉｒｓｔ Ｏｒｄｅｒ）、及びＳＯ（Ｓｅｃｏｎｄ Ｏｒｄｅｒ）である。図１には、これらのレベル間における遷移が示されている。ＩＲレベルは、デコンプレッサ用のコンテキストの生成、又はエラーからの回復に使用する。コンプレッサは、デコンプレッサからの要求によって（又は、更新タイマの満了に伴って）ヘッダの圧縮を開始する際に、このＩＲレベルにシフトする。ＩＲレベルにおいては、コンプレッサは、データパケットを圧縮されていない形態で伝送する。コンプレッサは、更新に関する情報をデコンプレッサが受信したという確認を受信すると、上位レベルへのシフトを試みる。

ＦＯレベルは、データパケットフローのヘッダにおける不規則性について受信機に通知するために使用されるものである。ＩＲレベルの後に、ヘッダが均一なパターンを形成しなかったり（即ち、連続するヘッダがランダムに変化して変化が予測不能である）、或いは、ヘッダの均一なパターンを定義するパラメータをデコンプレッサが受信したかどうかをコンプレッサが確認できない場合に、コンプレッサは、このＦＯレベルにおいて動作する。この状況は、例えば、通話伝送の開始時点に（特に、ブレーク後の最初の音声バーストにおいて）特有のものである。このＦＯレベルにおいては、コンプレッサは、圧縮されたＦＯヘッダを伝送する。そして、ヘッダが均一なパターンを形成しており、均一なパターンのパラメータをデコンプレッサが受信したという確認を受信した場合に、コンプレッサは、上位レベルへのシフトを再び試みる。ＦＯレベルのデータパケットには、通常、コンテキスト更新に関する情報が含まれており、圧縮解除の成功には、連続したＦＯヘッダの伝送に成功することも必要とされる。従って、圧縮解除プロセスの成功／不成功は、ＦＯレベルパケットの消失や損傷の影響を受けやすい。

ＳＯレベルにおいては、圧縮は最適化されている。ヘッダは、圧縮されたＳＯヘッダによってコンプレッサが記述する均一なパターンを形成しており、これらの圧縮ＳＯヘッダは、実際には、データパケットのシーケンス番号の一部を形成している。デコンプレッサには、既にＦＯレベルにおいて、均一なパターンを定義するパラメータが通知されている。デコンプレッサは、これらのパラメータと受信したシーケンス番号に基づいて、オリジナルのヘッダを推定可能である。ＳＯレベルにおいて伝送されるデータパケットは、実際には、互いに独立しているため、デコンプレッサに対するエラーの影響度は低い。ヘッダが均一なパターンを形成しなくなると、コンプレッサはＦＯレベルに戻る。

このデコンプレッサのコンテキスト定義に依存した３つのレベルは、デコンプレッサについても決定される。デコンプレッサの動作は、常に最下位レベルにおいて始まり、このレベルでは、まだなんのコンテキストも定義されてはいない（Ｎｏ Ｃｏｎｔｅｘｔ）。この場合、デコンプレッサは、まだ１つのデータパケットも圧縮解除してはいない。静的及び動的コンテキスト情報の両方を含む最初のデータパケットをデコンプレッサが圧縮解除した後に、コンプレッサは、中間レベル（Ｓｔａｔｉｃ Ｃｏｎｔｅｘｔ）を飛び越えて、最上位レベル（Ｆｕｌｌ Ｃｏｎｔｅｘｔ）に直接シフトすることができる。そして、最上位レベルにおけるいくつかのエラーの結果、デコンプレッサは、中間レベルにシフトするが、通常、１つのデータパケットの圧縮解除に成功するだけで、デコンプレッサは最上位レベルに戻る。

ＲＯＨＣに対しては、これらの様々な圧縮レベルに加え、Ｕ（Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ：単一方向）モード、Ｏ（ｂｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｏｐｔｉｍｉｓｔｉｃ：双方向楽観）、及びＲ（ｂｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｒｅｌｉａｂｌｅ：双方向高信頼性）モードという３つの異なる動作モードが定義されており、図２に、これらが示されている。この図２に示されているように、前述の各圧縮レベル（ＩＲ、ＦＯ、ＳＯ）がそれぞれのモードにおいて動作するが、それぞれのモードは、それぞれのレベルにおける動作が異なると共に、独自の方法でレベル間の遷移を決定している。所与の圧縮状況において、どの動作モードを選択するかは、リターンチャネルを使用する可能性、エラー確率とエラー分布、及びヘッダサイズの変化による影響などの使用するデータ伝送接続のパラメータによって決まる。

単一方向モードのデータパケットは、コンプレッサからデコンプレッサに対してのみ伝送され、従って、このＲＯＨＣのＵモードは、リターンチャネルが使用できない（或いは、リターンチャネルの使用状況が不十分な）場合に実用的である。双方向楽観モードは、エラー訂正とデコンプレッサからコンプレッサに対する重要なコンテキスト更新のアクノリッジにリターンチャネルを使用する点を除いて、単一方向モードと同一である。このＯモードは、好ましくは、わずかなリターンチャネルトラフィックによって最適な圧縮効率を必要とする接続に適している。一方、双方向高信頼性モードは、前述の各モードとは、明瞭に異なっている。このＲモードでは、すべてのコンテキスト更新のアクノリッジにリターンチャネルを使用しており、従って、シーケンス番号更新の特定の部分についてもアクノリッジされる。この結果、Ｒモードにおいては、コンプレッサとデコンプレッサ間でデータパケットを略完全且つ確実に伝送することができる。

これらのＲＯＨＣの３つの動作モード及び３つの圧縮レベルにより、ヘッダ圧縮用の異なる動作状況が形成される。それぞれの状況において、コンプレッサ及びデコンプレッサ、並びにそれらの間におけるパケットの伝送を定義する必要がある。ＲＯＨＣでは、異なる動作状況に異なるパケットが使用される。現時点では、ＲＯＣＨには、６つの異なるデータパケットタイプが定義されており、この中の４つは、コンプレッサからデコンプレッサへの伝送に使用され、２つは、デコンプレッサからコンプレッサへのリターンチャネルのデータパケットである。今後、使用するデータパケットタイプの数は変化する可能性があるが、パケットを伝送路に伝送する前に、各データパケットに対して、所与の時点で使用するコンテキストを識別するコンテキスト識別子ＣＩＤを付加できるという点がすべてのデータパケットタイプに共通する特徴である。

ＲＯＨＣでは、同一の無線リンクにおいて伝送される複数のデータパケットフローをコンテキスト識別子ＣＩＤによって互いに区別している。このコンテキスト識別子は、伝送するデータパケットに付加され、このコンテキスト識別子により、受信機は、そのデータパケットが属するパケットデータフローと圧縮コンテキストを判定することができる。

ＲＯＨＣ規格に準拠するヘッダ圧縮法を適用可能な通信システムは、少なくともＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）及びＩＭＴ−２０００（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｐｈｏｎｅ Ｓｙｓｔｅｍ）という名称で呼ばれる第３世代移動体通信である。次に、図３を参照し、このＵＭＴＳシステムについて簡単に説明する。

図３に含まれているのは、本発明の説明に関連するブロックのみであるが、当業者には、本明細書において詳細な説明を必要としないその他の機能や構造が従来の移動体通信システムに含まれていることは明らかである。移動体通信システムの主要な要素は、移動体通信システムの固定ネットワークを形成するコアネットワークＣＮ及びＵＴＲＡＮ（ＵＭＴＳ ｔｅｒｒｅｓｔｒｉａｌ ｒａｄｉｏ ａｃｃｅｓｓ ｎｅｔｗｏｒｋ）と、移動局、即ち、ユーザー機器ＵＥである。このＣＮとＵＴＲＡＮ間のインターフェースは、ｌｕと呼ばれ、ＵＴＲＡＮとＵＥ間のインターフェースは、Ｕｕと呼ばれている。

ＵＴＲＡＮは、通常、いくつかの無線ネットワークサブシステムＲＮＳから構成されており、これらの間には、ｌｕｒと呼ばれるインターフェースが存在している（図示されてはいない）。ＲＮＳは、無線ネットワークコントローラＲＮＣと１つ又は複数の基地局ＢＳ（これは、ノードＢとも呼ばれる）から構成されている。このＲＮＣとＢＳ間のインターフェースは、ｌｕｂと呼ばれている。基地局ＢＳは、通常、無線経路を実現する責任を負っており、無線ネットワークコントローラＲＮＣは、少なくとも、無線リソース管理、セル間のハンドオーバーの制御、電力制御、タイミングと同期化、加入者端末の呼び出しに対する責任を負っている。

コアネットワークＣＮは、ＵＴＲＡＮ以外の移動体通信システムに属するインフラストラクチャから構成されている。コアネットワークにおいては、移動交換局／ビジタロケーションレジスタ３Ｇ−ＭＳＣ／ＶＬＲがホームロケーションレジスタＨＬＲと通信し、好ましくは、インテリジェントネットワークのサービス制御ポイントＳＣＰとも通信している。ホームロケーションレジスタＨＬＲ及びビジタロケーションレジスタＶＬＲは、移動体加入者に関する情報を格納しており、ホームロケーションレジスタＨＬＲは、移動体通信ネットワークの全加入者と彼らが発注しているサービスに関する情報を格納し、ビジタロケーションレジスタＶＬＲは、特定の移動交換局ＭＳＣのエリアを訪問する移動局に関する情報を格納する。無線システムのサービングＧＰＲＳサポートノード３Ｇ−ＳＧＳＮに対する接続は、Ｇｓ’インターフェースを介して確立され、公衆交換電話網ＰＳＴＮ／ＩＳＤＮに対しては、ゲートウェイ移動交換局ＧＭＳＣを介して確立される（ゲートウェイＭＳＣは図示されてはいない）。サービングサポートノード３Ｇ−ＳＧＳＮからゲートウェイＧＰＲＳサポートノードＧＧＳＮに対しては、Ｇｎインターフェースを介して接続が確立され、更にＧＧＳＮから外部のデータネットワークＰＤＮに対して接続が確立される。移動交換局３Ｇ−ＭＳＣ／ＶＬＲとサービングサポートノード３Ｇ−ＳＧＳＮは、いずれもｌｕインターフェースを介して無線ネットワークＵＴＲＡＮ（ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）と通信する。尚、このＵＭＴＳシステムは、例えば、コアネットワークＣＮがＧＳＭシステムのコアネットワークと同一になるように設計されていることに留意されたい。この場合は、ネットワークインフラストラクチャ全体を再構築する必要がなくなる。

即ち、ＵＭＴＳシステムは、ＧＳＭネットワークに接続されたＧＰＲＳシステムにかなりの程度準拠して実現されたパケット無線システムを有しており、ネットワーク要素の名称にＧＰＲＳシステムに対する参照が含まれているのは、このためである。ＵＭＴＳのパケット無線システムは、複数のサービングサポートノード及びゲートウェイサポートノードを有することが可能であり、通常、複数のサービングサポートノード３Ｇ−ＳＧＳＮが１つのゲートウェイサポートノード３Ｇ−ＧＧＳＮに接続されている。３Ｇ−ＳＧＳＮノードと３Ｇ−ＧＧＳＮノードのいずれもが、移動局のモビリティをサポートし、移動体通信システムを制御すると共に、移動局の位置と使用するプロトコルに関係なく、データパケットを移動局にルーティングするルーターとして機能する。サービングサポートノード３Ｇ−ＳＧＳＮは、無線ネットワークＵＴＲＡＮを介して移動局ＵＥと通信する。サービングサポートノード３Ｇ−ＳＧＳＮの機能は、そのエリア内のパケット無線接続能力を有する移動局を検出し、これらの移動局との間でデータパケットを送受信すると共に、そのサービスエリア内における移動局の位置を監視することである。更に、サービングサポートノード３Ｇ−ＳＧＳＮは、シグナリングインターフェースＧｓ’を介して移動交換局３Ｇ−ＭＳＣ及びビジタロケーションレジスタＶＬＲと通信すると共に、Ｇｒインターフェースを介してホームロケーションレジスタＨＬＲとも通信する。ホームロケーションレジスタＨＬＲには、加入者固有のパケットデータプロトコルのコンテンツを含むパケット無線サービスに関連するレコードも格納されている。

ゲートウェイサポートノード３Ｇ−ＧＧＳＮは、ＵＭＴＳネットワークのパケット無線システムと外部データネットワークＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）間におけるゲートウェイとして機能する。この外部データネットワークには、別のネットワーク事業者のＵＭＴＳ又はＧＰＲＳネットワーク、インターネット、Ｘ．２５ネットワーク、又はプライベートエリアネットワークが含まれる。ゲートウェイサポートノード３Ｇ−ＧＧＳＮは、Ｇｉインターフェースを介してこれらのデータネットワークと通信する。ゲートウェイサポートノード３Ｇ−ＧＧＳＮとサービングサポートノード３Ｇ−ＳＧＳＮ間で伝送されるデータパケットは、ＧＴＰ（Ｇａｔｅｗａｙ Ｔｕｎｎｅｌｌｉｎｇ Ｐｒｏｔｏｃｏｌ）によって常にカプセル化される。ゲートウェイサポートノード３Ｇ−ＧＧＳＮには、移動局のＰＤＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ）アドレスとルーティングデータ（即ち、３Ｇ−ＳＧＳＮアドレス）も格納されている。従って、このルーティングデータを使用し、外部データネットワークとサービングサポートノード３Ｇ−ＳＧＳＮ間におけるデータをリンクする。ゲートウェイサポートノード３Ｇ−ＧＧＳＮとサービングサポートノード３Ｇ−ＳＧＳＮ間のネットワークは、ＩＰプロトコルを利用するネットワークである（ＩＰｖ６（インターネットプロトコル、第６版）が好ましい）。

図４ａ及び図４ｂには、ＵＭＴＳシステムのパケット無線サービスにおける制御シグナリング（制御プレーン）とユーザーデータの伝送（ユーザープレーン）用のＵＭＴＳプロトコルスタックが示されている。図４ａには、移動局ＭＳとコアネットワークＣＮ間の制御シグナリングに使用されるプロトコルスタックが示されている。移動局ＭＳのモビリティ管理ＭＭ、通話制御ＣＣ、セッション管理ＳＭは、移動局ＭＳとコアネットワークＣＮ間における最上位のプロトコルレイヤにおいてシグナリングされており、この結果、これらの間の基地局ＢＳ及び無線ネットワークコントローラＲＮＣは、シグナリングに対してトランスペアレントになっている。移動局ＭＳと基地局ＢＳ間における無線接続の無線リソース管理は、無線リソース管理ＲＲＭシステムによって制御されており、制御データは無線ネットワークコントローラＲＮＣから基地局ＢＳに伝送される。移動体通信システムの一般的な管理に関連するこれらの機能は、コアネットワークプロトコル（ＣＮプロトコル）と呼ばれる１組のプロトコルを形成しており、これは、ＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）とも呼ばれている。同様に、移動局ＭＳ、基地局ＢＳ、及び無線ネットワークコントローラＲＮＣ間の無線リソース管理に関連するシグナリングは、集合的に無線ネットワークプロトコル（ＲＡＮプロトコル）と呼ばれるプロトコルレイヤにおいて実行される（即ち、ＡＳ（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）である）。これらには、更なる処理のために上位レイヤに転送される制御シグナリングを伝送する伝送プロトコルが最下位レベルに含まれている。最も重要な上位ＡＳ（ａｃｃｅｓｓ ｓｔｒａｔｕｍ）レイヤは、無線リソース制御ＲＣＣプロトコルであり、これは、移動局ＭＳと無線ネットワークＵＴＲＡＮ間の無線接続の確立、設定、維持、及び切断と、コアネットワークＣＮ及び無線ネットワークＲＡＮから移動局ＭＳへの制御情報の伝送に対する責任を負っている。更に、無線リソース制御ＲＲＣプロトコルは、例えば、アプリケーションに基づいた容量の予約の際に、無線リソース管理ＲＲＭシステムの指示に従って端末接続用に十分な容量を予約する責任をも負っている。

ＵＭＴＳにおいては、パケット交換ユーザーデータの伝送の際に、図４ｂのプロトコルスタックが使用される。下位レベルのデータ伝送は、無線ネットワークＵＴＲＡＮと移動局ＭＳ間のインターフェースＵｕを介し、物理レイヤにおいて、ＷＣＤＭＡ又はＴＤ−ＣＤＭＡによって実行される。データパケットは、物理レイヤとＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ間の（物理レイヤの上位に位置する）ＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｌａｙｅｒ）レイヤによって伝送され、ＲＬＣレイヤは、様々な端末接続の無線リンクの論理的管理に対して責任を負っている。このＲＬＣの機能には、伝送するユーザーデータ（ＲＬＣ−ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ））を１つ又は複数のＲＬＣデータパケットＲＬＣ−ＰＤＵに断片化することも含まれている。必要に応じて、ＲＬＣの上位に位置するＰＤＣＰレイヤのデータパケット（ＰＤＣＰ−ＰＤＵ）に含まれているＩＰヘッダを圧縮することも可能である。この後に、１つのＲＬＣ−ＳＤＵに対応する複数のＰＤＣＰ−ＰＤＵがＲＬＣに供給される。ユーザーデータとＲＬＣ−ＳＤＵは断片化され、データ伝送に必要なアドレスと制御情報が付加されたＲＬＣフレームで伝送される。ＲＬＣレイヤは、損傷したフレームの再送に対する責任も負っている。サービングサポートノード３Ｇ−ＳＧＳＮは、移動局ＭＳから無線ネットワークＲＡＮを介して到来したデータパケットを正しいゲートウェイサポートノード３Ｇ−ＧＧＳＮにルーティングする責任を負っている。この接続は、コアネットワークを介して伝送されたすべてのユーザーデータとシグナリングのカプセル化とトンネル化を実行するトンネルプロトコルＧＴＰを使用している。このＧＴＰプロトコルは、コアネットワークが使用するＩＰ上で稼働する。

ＵＭＴＳシステムの場合には、伝送対象のデータパケットに対してヘッダ圧縮を実行し、コンバージェンスプロトコルレイヤＰＤＣＰにおいて受信されるデータパケットに対して圧縮解除を行う。ＰＤＣＰレイヤのタスクには、チャネル効率の改善に関係する機能が含まれており、これらの機能は、通常、データパケットヘッダ圧縮アルゴリズムの利用などの様々な最適化法に基づいたものである。ＵＭＴＳ用に設計されるネットワークレベルのプロトコルが最近ではＩＰプロトコルであるため、使用する圧縮アルゴリズムもＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）によって標準化されたアルゴリズムとなる。従って、ＲＯＨＣ圧縮法は、特にＵＭＴＳシステムに適している。端末のＰＤＣＰレイヤは、通常、できる限り多くのプロトコルタイプのネットワークレイヤに接続を確立できるよう、複数のヘッダ圧縮法をサポートしている。

ＲＯＨＣをＵＭＴＳコンバージェンスプロトコルレイヤに適用した場合、送信ＰＤＣＰと受信ＰＤＣＰのいずれもが、送信するデータパケットを圧縮し且つ受信したデータパケットを圧縮解除するコンプレッサ／デコンプレッサのペアを有することになる。コンバージェンスプロトコルレイヤＰＤＣＰは、それぞれの端末接続の圧縮を判定する異なるパラメータをネゴシエートするためのＲＯＨＣ圧縮法用のメカニズムを提供する。実際には、このメカニズムは、例えば、ＰＤＣＰレイヤがコンプレッサ及びデコンプレッサのメッセージをＲＲＣに転送し、実際のネゴシエーションがＲＲＣシグナリングとして実行されるように実現することができる。

ＵＭＴＳ規格によれば、コンテキスト識別子ＣＩＤは、少なくとも２つの方法により、伝送するデータパケットに付加することができる。まず、コンテキスト識別子は、ＲＯＨＣの内部手順において付加することが可能であり、ＲＯＨＣ規格によれば、圧縮されたデータパケットには、コンテキスト識別子ＣＩＤを付加するための固有のＣＩＤフィールドが含まれている。もう１つの選択肢は、コンテキスト識別子をＵＭＴＳ ＰＤＣＰレイヤのデータパケットＰＤＣＰ−ＰＤＵに付加（又は、関連付け）し、この結果、ＲＯＨＣ規格に従って圧縮されたデータパケットにはコンテキスト識別子ＣＩＤが含まれず、このＲＯＨＣ圧縮されたデータパケットがマッピングされたＰＤＣＰレイヤデータパケットＰＣＤＰ−ＰＤＵにコンテキスト識別子又はこれに関係する別の識別子を付加するようにする方法である。

ＰＤＣＰレイヤにおいては、データパケットＰＤＵに付加されるパケット識別子ＰＩＤにより、様々な圧縮法に関する通知が行われ、互いに区別されている。それぞれのＰＤＣＰエンティティごとに、パケット識別子ＰＩＤ値のテーブルが生成される。このテーブル内で、異なる圧縮アルゴリズムが異なるパケットタイプとマッチングされ、これらの組み合わせにより、パケット識別子ＰＩＤの値が定義される。通常、ＲＯＨＣに対して予約されるＰＩＤ値は１つだけである。ＰＩＤは、ＰＤＣＰ−ＰＤＵ構造内の５ビットのフィールドであり、０〜３１の値を取ることができる。圧縮アルゴリズムが使用されていない場合には、パケット識別子ＰＩＤには、値としてゼロが付与される。ＰＩＤ値は、それぞれの圧縮アルゴリズムと、その様々なデータパケットタイプとの組み合わせごとに連続的に判定され、この結果、それぞれの圧縮アルゴリズムのＰＩＤ値はｎ＋１から始まっている（ここで、ｎは先行する圧縮アルゴリズムに対して判定された最後のＰＩＤ値である）。圧縮アルゴリズムの順序は、無線リソースコントローラＲＲＣとのネゴシエーションにおいて判定される。このＰＩＤ値のテーブルに基づいて、パケットデータ接続の両端に位置するＰＤＣＰエンティティは、送受信するデータパケットの圧縮アルゴリズムとデータパケットタイプを識別することができる。

この後に、利用可能なＰＩＤ値の数と所与の時点でＲＯＨＣが利用可能なコンテキスト識別子の数を比較することにより、ＰＤＣＰ接続においてＣＩＤ値を伝送するための前述の選択を実行するメカニズムを生成することができる。即ち、利用可能なＰＩＤ値の数がＲＯＨＣに対して定義されたコンテキスト識別子の数と等しいか、或いはこれを上回る場合には、好ましくは、ＣＩＤ値はＰＤＣＰ−ＰＤＵデータパケットに付加する。この結果、無線インターフェースによって伝送されるデータの合計量におけるヘッダの比率を極小化すると共に、ＣＩＤ値の伝送の設定に必要なシグナリングを削減することができる。一方、コンテキスト識別子ＣＩＤの数が利用可能なＰＩＤ値の数を上回っている場合には、コンテキスト識別子は、常にＲＯＨＣデータパケットのＣＩＤフィールドに付加する。

この方法は、移動局ＭＳと無線ネットワークＵＴＲＡＮの両方に同一の比較アルゴリズムを保存することにより、適用可能であり、この結果、ＰＤＣＰ接続の両端に位置する主体の両方が、このアルゴリズムを使用しコンテキスト識別子の伝送に使用する方法を選択することができる。この場合、好ましいことに、移動局ＭＳと無線ネットワークＵＴＲＡＮは、方法に関して合意するためのそれらの間における別個のシグナリングを必要としておらず、使用する方法を自動的に設定可能である。

一方、状況によっては、コンテキスト識別子の伝送に使用する方法を無線ネットワークＵＴＲＡＮが常に判定する方が有利な場合も存在する。これは、例えば、比較アルゴリズムの更新を容易に実行できるようにする必要があったり、或いは、一般的に、できる限り無線ネットワークが移動局の動作を制御することが望ましい場合などである。このような場合には、比較アルゴリズムは、好ましくは、無線ネットワーク側にのみ保存することが可能であり、前述の比較を無線ネットワークにおいて実行することができる。無線ネットワークＵＴＲＡＮは、コンテキスト識別子の伝送に使用する方法を定義した後に、この決定について移動局ＭＳに通知する。これは、ＲＲＣシグナリングとして実行可能であり、前述の定義は、ごくわずかの変更によってＲＲＣシグナリングに追加することができる。この定義は、好ましくは、前述のコンテキスト識別子の伝送方法のいずれを使用するかを定義するフィールド（例：ＣＩＤ値フィールド）を追加することにより、好ましくは、例えば、規格（３ＧＰＰ ＴＳ２５．３３１、第４．０．０版、第１０．３．４．２節）に記述されているＰＤＣＰ情報定義に付加することが可能である。このメッセージは、移動局ＭＳには本質的に既知のＲＲＣシグナリングとして伝送され、移動局は、このメッセージをデコードし、そこに定義されているコンテキスト識別子の伝送方法を使用するべく設定する。

次に、図５を参照し、本発明の好適な実施例により実現される比較アルゴリズムについて説明する。まず、利用可能なＰＩＤ値の数をＲＯＨＣに割り当てられているコンテキスト識別子ＣＩＤの数と比較する（５００）。この利用可能なＰＩＣ値の数は、ＲＯＨＣ以外のその他の圧縮アルゴリズム対して予約されている圧縮アルゴリズムの数をＰＩＤ値の最大数である３１から減算することによって得られる。

利用可能なＰＩＤ値の数がＲＯＨＣに割り当てられているコンテキスト識別子ＣＩＤの数と等しいか、或いはこれを上回っている場合には、その他の接続定義がＰＤＣＰ−ＰＤＵデータパケットに対するヘッダの付加を必要としているかどうかをチェックする。そして、ＰＤＣＰ−ＰＤＵデータパケットにヘッダが必要とされている場合には、ＣＩＤ値は、好ましくは、ＰＤＣＰ−ＰＤＵデータパケットに付加される。これは、２つの段階によって実行可能であり、まず、その無線ベアラに複数の圧縮アルゴリズムが定義されているかどうかをチェックする（５０２）。その無線ベアラに複数の圧縮アルゴリズムが定義されておれば、ＰＤＣＰ−ＰＤＵデータパケットはヘッダを有しており、従って、ＣＩＤ値をＰＤＣＰ−ＰＤＵデータパケットに対して付加する方法を使用するべく定義する（５０４）。一方、複数の圧縮アルゴリズムがその無線ベアラに対して定義されていない場合には、その他の理由により（例えば、シーケンス番号を送信するために）、ＰＤＣＰ−ＰＤＵヘッダが必要とされているかどうかをチェックする（５０６）。これが該当すれば、この場合にも、ＣＩＤ値をＰＤＣＰ−ＰＤＵデータパケットに付加する方法を使用するべく定義する（５０４）。一方、ＰＤＣＰ−ＰＤＵデータパケットにヘッダが必要とされていない場合には、ＣＩＤ値の伝送のみのためにＰＤＣＰ−ＰＤＵデータパケットにヘッダを定義するのは有利ではないため、ＣＩＤ値をＲＯＨＣデータパケットのＣＩＤフィールドで伝送するべく定義する（５０８）。

一方、開始時点における比較段階（５００）において、利用可能なＰＩＤ値の数がＲＯＨＣに割り当てられているコンテキスト識別子ＣＩＤの数を下回っていることが判明した場合には、ＣＩＤ値をＲＯＨＣデータパケットのＣＩＤフィールドで直接伝送すると定義する（５０８）。

ＣＩＤ値はＰＩＤ値と必ずしも対応しているとは限らないため、好ましくは、伝送の前に、対応するＰＩＤ値をそれぞれのＣＩＤ値に関連付けることにより、前述のＰＤＣＰ−ＰＤＵデータパケットに対するＣＩＤ値の付加を実行することができる。ＰＩＤ値は、通常、ＰＤＣＰ−ＰＤＵのＰＩＤフィールドにおいて伝送される。

尚、前述の比較アルゴリズムは、ＣＩＤ値の伝送を定義する一方法に過ぎないことに留意されたい。当業者には、いくつかの方法によってこのアルゴリズムを定義し、本発明の概念の観点で同一の結果をもたらすことが可能であることが明らかである。又、本発明は、ＰＤＣＤ接続におけるＣＩＤ値の判定のみに限定されるものではなく、本発明は、その他のシステムの様々なプロトコルレイヤにおいて適用することも可能である。

従って、本発明による方法を採用すれば、ＣＩＤ値を伝送する方法を定義すると共に、その方法を使用するべく移動局ＭＳと無線ネットワークＵＴＲＡＮの両方を設定することができる。又、本発明によるこの方法によれば、無線インターフェースを介して伝送されるデータの合計量におけるヘッダの比率を最適化できるようになる。本発明によるこの方法は、既存のシグナリングに対するごくわずかの変更により（好ましくは、なんらの変更なしに）、実現可能である。この方法によれば、無線リソースの効率的な利用が可能になり、システムに対する変更の必要性が軽減されるため、有利である。

以上、一例としてＵＭＴＳシステムを使用し、本発明の方法について説明した。しかしながら、ＲＯＨＣによるヘッダ圧縮は、ＵＭＴＳシステムに限定されるものではなく、本発明は、好ましくは、ＩＰデータパケットを伝送するあらゆる通信システムに対して適用可能である。この本発明による方法は、好ましくは、ＧＥＲＡＮ（ＧＳＭ Ｅｄｇｅ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）などの第２世代移動体通信システムの更なる発展プロセスにおいても適用することができる。当業者には、技術の進展に伴い、本発明の概念を様々な方法によって実現可能であることが明らかである。従って、本発明及びその実施例は、前述の例に限定されるものではなく、添付の特許請求の範囲内で変化し得るものである。

異なるＲＯＨＣ圧縮レベル間における遷移を示すブロックダイアグラムである。 異なるＲＯＨＣ動作モード間における遷移を示すブロックダイアグラムである。 ＵＭＴＳシステムの概略構造を示すブロックダイアグラムである。 制御シグナリングとユーザーデータ伝送用のＵＭＴＳパケットデータサービスのプロトコルスタックを示している。 コンテキスト識別子の伝送法を判定するための本発明の実施例による比較アルゴリズムを示すフローチャートである。

Claims (20)

1. 通信システムにおけるデータパケット接続上でのヘッダ圧縮のコンテキスト識別子を伝送する方法であって、前記コンテキスト識別子（ＣＩＤ）は、圧縮されたデータパケットの一部として、或いは、前記通信システムのコンバージェンスプロトコルレイヤ（ＰＤＣＰ）において伝送されるデータパケット（ＰＤＣＰ−ＰＤＵ）のヘッダ内のいずれかによって伝送可能であり、前記ヘッダは、コンテキスト識別子を付加可能な値限定フィールド（ＰＩＤ）を有しており、前記方法は、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数を決定することにより前記コンテキスト識別子の送信方法を選択する段階と、圧縮法に対して定義されているコンテキスト識別子の数を決定する段階と、を備えている方法において、
   前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数が前記圧縮法に対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回っているという事実に応答し、前記データパケット接続のその他の定義がコンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているかどうかをチェックする段階と、
   前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているという事実に応答し、前記コンテキスト識別子を前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダに付加する段階と、或いは、この段階の代わりに、
   前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としていないという事実に応答し、前記コンテキスト識別子を圧縮されたデータパケットに付加する段階と、
   を有することを特徴とする方法。
2. 移動体通信システムにおけるデータパケット接続上でのヘッダ圧縮のコンテキスト識別子を伝送する方法であって、前記コンテキスト識別子（ＣＩＤ）は、圧縮されたデータパケットの一部として、或いは、前記移動体通信システムのコンバージェンスプロトコルレイヤ（ＰＤＣＰ）において伝送されるデータパケット（ＰＤＣＰ−ＰＤＵ）のヘッダ内のいずれかによって伝送可能であり、前記ヘッダは、コンテキスト識別子を付加可能な値限定フィールド（ＰＩＤ）を有している方法において、
   前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数を前記移動体通信システムの無線ネットワークにおいて圧縮法のみに対して定義されているコンテキスト識別子の数と比較する段階と、
   前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数が前記圧縮法に対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回っているという事実に応答し、前記データパケット接続のその他の定義がコンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているかどうかをチェックする段階と、
   前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているという事実に応答し、前記コンテキスト識別子を前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダに付加する段階と、或いは、この段階の代わりに、
   前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としていないという事実に応答し、前記コンテキスト識別子を圧縮されたデータパケットに付加する段階と、
   前記無線ネットワークから移動局に前記コンテキスト識別子を送信するために選択された方法に関する情報を送信する段階と、
   を有することを特徴とする方法。
3. 前記コンテキスト識別子を伝送する方法を示すための別個のフィールドを有しているＲＲＣシグナリングメッセージで前記情報を前記移動局に伝送する段階により特徴付けられる請求項２記載の方法。
4. 複数の圧縮アルゴリズムが前記データパケット接続に対して定義されているかどうかをチェックする段階により特徴付けられる請求項１から３のいずれか一項に記載の方法。
5. シーケンス番号の伝送のために前記データパケット接続に対してヘッダが定義されているかどうかをチェックする段階により特徴付けられる請求項１から４のいずれか一項に記載の方法。
6. 前記通信システムは、移動体通信システムであって、前記方法は、
   前記決定及び前記チェックを移動局と無線ネットワークにおいて別個に実行する段階と、
   前記移動局と前記無線ネットワークの両方において前記コンテキスト識別子の伝送方法を選択する段階と、
   を有することを特徴とする請求項１記載の方法。
7. ヘッダ圧縮のコンテキスト識別子（ＣＩＤ）が、圧縮されたデータパケットの一部として、或いは、通信システムのコンバージェンスプロトコルレイヤ（ＰＤＣＰ）において伝送されるデータパケット（ＰＤＣＰ−ＰＤＵ）のヘッダ内のいずれかによって伝送されるべく構成されており、前記ヘッダは、コンテキスト識別子を付加可能な値限定フィールド（ＰＩＤ）を有し、前記通信システムは、前記コンテキスト識別子の伝送方法を、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数とその圧縮法に対して定義されたコンテキスト識別子の数を判定することによって選択するべく構成されている、通信システムにおいて、
   前記通信システムは、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数が前記圧縮法に対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回っているという事実に応答し、前記データパケット接続のその他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているかどうかをチェックするべく構成されており、
   前記通信システムは、前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているという事実に応答し、前記コンテキスト識別子を、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダに付加するべく構成されており、或いは、この代わりに、
   前記通信システムは、前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としていないという事実に応答し、前記コンテキスト識別子を、圧縮されたデータパケットに付加するべく構成されている、
   ことを特徴とする通信システム。
8. ヘッダ圧縮のコンテキスト識別子（ＣＩＤ）が、圧縮されたデータパケットの一部として、或いは、移動体通信システムのコンバージェンスプロトコルレイヤ（ＰＤＣＰ）において伝送されるデータパケット（ＰＤＣＰ−ＰＤＵ）のヘッダ内のいずれかによって伝送されるべく構成されており、前記ヘッダは、コンテキスト識別子を付加可能な値限定フィールド（ＰＩＤ）を有し、前記移動体通信システムは、前記コンテキスト識別子の伝送方法を、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数とその圧縮法に対して定義されているコンテキスト識別子の数を比較することによって前記移動体通信システムの無線ネットワークにおいて選択されるべく構成されている、移動体通信システムにおいて、
   前記移動体通信システムは、その圧縮法に対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回る前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数に応答し、前記データパケット接続の他の定義が、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダの使用を要求するかどうかチェックするべく構成されており、それにより、
   前記移動体通信システムは、前記データパケット接続の他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を要求するという事実に応答して、前記コンバージェンスプロトコルレイヤデータパケットのヘッダに前記コンテキスト識別子を付加するように構成されており、又はこれに替えて、
   前記移動体通信システムは、前記データパケット接続の他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を要求しないという事実に応答して、圧縮データパケットに前記コンテキスト識別子を付加するように構成されており、
   前記移動体通信システムは、前記コンテキスト識別子を伝送するべく選択された方法に関する情報を、前記無線ネットワークから移動局に伝送するべく構成されていることを特徴とする移動体通信システム。
9. 前記無線ネットワークは、前記コンテキスト識別子を伝送するべく選択された前記方法を通知するための別個のフィールドを有するＲＲＣシグナリングメッセージにおいて前記情報を前記移動局に伝送するべく構成されていることを特徴とする請求項８記載の通信システム。
10. 前記通信システムは、前記データパケット接続に対して複数の圧縮アルゴリズムが定義されているかどうかをチェックするべく構成されていることを特徴とする請求項７から９のいずれか一項に記載の通信システム。
11. 前記通信システムは、シーケンス番号の伝送のために前記データパケット接続に対して前記ヘッダが定義されているかどうかをチェックするべく構成されている請求項７から１０のいずれか一項に記載の通信システム。
12. 前記通信システムは、移動体通信システムであって、
    前記決定及び前記チェックは、移動局と無線ネットワークにおいて別個に実行するべく構成されており、
    前記コンテキスト識別子の伝送方法は、前記移動局と前記無線ネットワークの両方において選択するべく構成されている、
    ことを特徴とする請求項７記載の通信システム。
13. 移動通信システム用ネットワーク要素であって、前記ネットワーク要素は、コンバージェンスプロトコルレイヤデータパケットの値限定フィールド（ＰＩＤ)ヘッダにおいて利用可能な値の数を、圧縮法に対して定義されているコンテキスト識別子の数と比較することにより、前記移動通信システムの無線ネットワーク内のヘッダ圧縮コンテキスト識別子の伝送方法を選択するべく構成されているものにおいて、
    前記ネットワーク要素は、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数が前記圧縮法に対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回っているという事実に応答し、前記データパケット接続のその他の定義がコンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているかどうかをチェックするべく構成されており、それにより、
    前記ネットワーク要素は、前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているという事実に応答し、前記コンテキスト識別子を前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダに付加するべく構成されているか、或いは、この代わりに、
    前記ネットワーク要素は、前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としていないという事実に応答し、前記コンテキスト識別子を圧縮されたデータパケットに付加するべく構成されている、
    ことを特徴とする移動通信システム用ネットワーク要素。
14. 前記ネットワーク要素は、テキスト識別子を伝送するために選択された方法に関する情報を送信するべく構成されていることを特徴とする、請求項１３記載のネットワーク要素。
15. 前記ネットワーク要素は、前記コンテキスト識別子を伝送するべく選択された前記方法を通知するための別個のフィールドを有するＲＲＣシグナリングメッセージにおいて前記情報を前記移動局に伝送するべく構成されていることを特徴とする請求項１４記載のネットワーク要素。
16. 前記ネットワーク要素は、前記データパケット接続に対して複数の圧縮アルゴリズムが定義されているかどうかをチェックするべく構成されていることを特徴とする請求項１３から１５のいずれか一項に記載のネットワーク要素。
17. 前記ネットワーク要素は、シーケンス番号の伝送のために前記データパケット接続に対して前記ヘッダが定義されているかどうかをチェックするべく構成されている請求項１３から１６のいずれか一項に記載のネットワーク要素。
18. 移動通信システム用移動局であって、前記移動局は、コンバージェンスプロトコルレイヤデータパケットの値限定フィールド（ＰＩＤ)ヘッダにおいて利用可能な値の数を、圧縮法に対して定義されているコンテキスト識別子の数と比較することにより、前記移動通信システムの無線ネットワーク内のヘッダ圧縮コンテキスト識別子の伝送方法を選択するべく構成されているものにおいて、
    前記移動局は、前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダにおいて利用可能な値の数が前記圧縮法に対して定義されているコンテキスト識別子の数と等しいか、或いはこれを上回っているという事実に応答し、前記データパケット接続のその他の定義がコンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているかどうかをチェックするべく構成されており、それにより、
    前記移動局は、前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としているという事実に応答し、前記コンテキスト識別子を前記コンバージェンスプロトコルレイヤデータパケットの前記ヘッダに付加するべく構成されているか、或いは、この代わりに、
    前記移動局は、前記データパケット接続の前記その他の定義が前記コンバージェンスプロトコルレイヤデータパケットにおけるヘッダの使用を必要としていないという事実に応答し、前記コンテキスト識別子を圧縮されたデータパケットに付加するべく構成されている、
    ことを特徴とする移動通信システム用移動局。
19. 前記移動局は、前記データパケット接続に対して複数の圧縮アルゴリズムが定義されているかどうかをチェックするべく構成されていることを特徴とする請求項１８記載の移動局。
20. 前記移動局は、シーケンス番号の伝送のために前記データパケット接続に対してヘッダが定義されているかどうかをチェックするべく構成されていることを特徴とする請求項１８又は１９に記載の移動局。

Images