(57)【特許請求の範囲】
【請求項１】
コンテキストが、データパケット・フローの圧縮装置と伸張装置に対し定義され、前記コンテキストは、前記圧縮装置と伸張装置の動作をコントロールするものであって、前記コンテキストはデータパケットに付加されるコンテキスト識別子により識別され、前記コンテキスト識別子長さは、圧縮装置と伸張装置間のデータ転送により定義されるものであって、
前記転送されるデータパケットの前記コンテキスト識別子の一部として前記コンテキスト識別子の長さの定義を含むことを特徴とするデータパケットのヘッダフィールド圧縮時のコンテキスト識別子の定義方法。
【請求項２】
前記コンテキスト識別子は、コンテキスト識別子長さを定義するために、１ビット以上のフィールドを有することを特徴とする請求項１記載の方法。
【請求項３】
前記データパケットの各転送コンテキスト識別子の前記コンテキスト識別子長さを定義することを特徴とする請求項１又は２記載の方法。
【請求項４】
最初に転送されるデータパケットのコンテキスト識別子においてのみ前記コンテキスト識別子長さを定義することを特徴とする請求項１又は２記載の方法。
【請求項５】
伸張装置から圧縮装置へ転送されるデータパケット・フローのコンテキスト識別子と比べ、圧縮装置から伸張装置へ転送されるデータパケット・フローのコンテキスト識別子に対して、異なる長さを定義することを特徴とする、請求項１〜４のいずれか１項記載の方法。
【請求項６】
ＲＯＨＣの規定に基づいて前記ヘッダフィールド圧縮を行うことを特徴とする、請求項１〜５のいずれか１項記載の方法。
【請求項７】
ＵＭＴＳを含む移動システムのラジオインターフェースにおける前記ヘッダフィールド圧縮を行うことを特徴とする請求項１〜６記載の方法。
【請求項８】
データパケットのヘッダフィールドを圧縮するための圧縮システムであって、
該システムは、転送されるデータパケット・フローを圧縮する圧縮装置と、
受信されたデータパケット・フローを伸張する伸張装置を有し、
データパケットフローの前記圧縮装置と伸張装置は、前記圧縮装置と伸張装置の動作を制御するコンテキストを定義するように構成され、前記コンテキストは、前記データパケットに付加するコンテキスト識別子により識別されるように構成され、前記コンテキスト識別子長さは、前記前記圧縮装置・伸張装置間のデータ転送が定義するように構成されるものであって、
前記コンテキスト識別子長さは、転送されるデータパケットのコンテキスト識別子の一部として含まれるように構成されることを特徴とする圧縮システム。
【請求項９】
前記コンテキスト識別子は、コンテキスト識別子長さを定義するために１ビット以上のフィールドを有することを特徴とする請求項８記載のシステム。
【請求項１０】
前記コンテキスト識別子長さは、転送される各データパケットのコンテキスト識別子において定義されるように構成されることを特徴とする請求項８又は９記載のシステム。
【発明の詳細な説明】
【０００１】
（発明の背景）
本発明は、データパケット中のヘッダフィールドを圧縮する時のコンテキスト識別子の定義方法に関するものである。
【０００２】
ＩＰ（インターネットプロトコール）技術の進歩は、ここ数年更に発展し、従来のインターネットデータ転送以外の、異なるＩＰベースのアプリケーションを使うことができるようになった。特に、ＩＰベースの電話アプリケーションは、長足な進歩を遂げた。その結果、従来の電話ネットワークと移動ネットワークにおいてさえ、呼の転送パス（ｃａｌｌ ｔｒａｎｓｍｉｓｓｉｏｎ ｐａｔｈ）の拡大部分は、原則、ＩＰ技術を用いて実施されるようになった。
【０００３】
特に移動ネットワークにおいて、ＩＰ技術は、多くの長所を提供する。というのは、移動ネットワークの従来の音声サービス（各種のＩＰ音声アプリケーションが提供するような）に加えて、移動ネットワークは、将来、次々に各種のデータサービスを提供するだろうからである。例えば、インターネットブラウジング、ｅメールサービス、ゲーム等であり、これらは、最も好ましくは、パケット切替のＩＰベースのサービスとして実装されている。このように、移動システムプロトコールにおいて配備されたＩＰレイヤは、オーディオ／ビデオサービス及び各種データサービスに使われる。
【０００４】
移動ネットワークにおいて、特に重要なことは、有限な無線リソースを可能な限り効率的に使用することである。これにより、それ自身で、無線インターフェースにおけるＩＰプロトコールの利用が複雑になる。なぜなら、ＩＰベースのプロトコールにおいて、転送データにおける各種ヘッダフィールドの占める割合がかなり大きく、従ってペイロードの割合が小さいからである。更に、無線インターフェースのビットエラー率（ＢＥＲ）とアップリンク・ダウンリンクを使った往復時間（ＲＴＴ）は、悪条件の場合、かなり大きくなり、よく知られたヘッダフィールド圧縮方法に関して、様々な問題が発生する。このために、異なるＩＰプロトコールに適合するヘッダフィールド圧縮方法を開発する必要性がある。該方法は、特に無線インターフェース上のデータ転送に適合するものが望ましい。効率的なヘッダフィールド圧縮は、しかし、ビットエラー率と往復時間がかなり大きくなる条件下で使用できるものであることが望ましい。
【０００５】
このために、ＩＥＴＦ（インターネット技術タスクフォース）は、最近、ＲＯＨＣ（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ）として知られるヘッダフィールド圧縮方法の標準化について作業を行ってきた。ＲＯＨＣ開発の背後にある考え方は、データパケット転送で使用される複数のＩＰヘッダフィールドの間には、データパケットの内部ばかりでなく、それらの間にも、かなりの冗長性があるという点である。
換言すれば、ヘッダフィールドのかなりの量の情報は、データパケットの転送の間に全く変化しないので、例え、それが転送されなくても、復元することは容易である。圧縮時に注意しなければならないことは、ヘッダフィールドの一部の情報である。更に、ＲＯＨＣには複数の圧縮レベルがあり、圧縮効率は、高レベルに移行するに従って、向上する。ＲＯＨＣは、常に、最高効率の圧縮を使用するものであるが、より高位レベルに移る前には、レベル操作について、常に十分な信頼性を確保する必要がある。又、ＲＯＨＣの典型的な特徴は、圧縮方法の使用で重要な複数の事項を低位リンクレイヤに委ねていることである。
【０００６】
低位リンクレイヤを介して送信器と受信器間（例えば圧縮装置と伸張装置）でネゴシエートする事項は、例えば所定の無線リンクで使用されるコンテキスト識別子（ＣＩＤ）の長さの定義である。該コンテキスト識別子ＣＩＤは、同一無線リンク上を伝送する複数パケットデータ・フローを互いに区別するのに使用される。コンテキスト識別子ＣＩＤの長さとして、０、１、又は２バイト（０、８、１６ビット）が使われ、数値０は、リンクにデータフローが唯一存在する時に使われる。前記ＣＩＤの長さは、このように伝送データの圧縮を開始する前にネゴシエートされ、ネゴシエート後のコンテキスト識別子ＣＩＤの長さは、以後アップリンク、ダウンリンク方向で使用される。
【０００７】
前記方法の問題は、コンテキスト識別子ＣＩＤの長さが固定的である点である。ＣＩＤの長さは、圧縮を開始する前に、ネゴシエートされているから、その変更は、圧縮装置と伸張装置間の再ネゴシエーションで行われるのみである。その際、圧縮は中止される。もう一つの問題は、一つのラジオ・ベアラを使うとき、アップリンクとダウンリンク方向で、同じＣＩＤ長さが使用される。しかし、例えば移動システムでは、通常、アップリンク方向での好ましいＣＩＤ長さは、ダウンリンク方向のものより、かなり短い。もし従来の方法によって、ラジオベアラのＣＩＤ長さをダウンリンク方向条件で決めるならば、アップリンク方向のラジオリソースは最適に使用できないことになる。もしＣＩＤ長さをアップリンク方向だけを考慮して決めるならば、ダウンリンク方向の伸長で問題が起こる。伸張には、ネゴシエート後のＣＩＤ長さより、長いＣＩＤ長さを必要とするからである。
【０００８】
（発明の簡単な説明）
従って、本発明の目的は、前記問題を解決するための方法と該方法を実施する為の装置を開発することである。本発明の目的は、特許請求の範囲の独立クレームにおける記載で特徴づけられる方法とシステムにより達成される。本発明の好ましい実施例は、従属クレームに記載する。
【０００９】
本発明のアイデアは、データパケットフローに対し、コンテキスト識別子長さを定義するニーズがある時に、該長さの定義を転送する次のデータパケットに、好ましくはそのコンテキスト識別子フィールドに付加する、それにより前記コンテキスト識別子の新規長さを１以上のビット（ｂｉｔｓ）で指示する、というアイデアに基礎を置くものである。本発明の好ましい実施例によると、この長さの定義は転送される各データパケットに付加するもので、コンテキスト識別子長さは、各データパケットからチェックされる。本発明の第２の実施例によると、この定義は、転送される第１データパケットだけに付加され、その後、このコンテキスト識別子は、再定義があるまで、データパケット・フローで使用される。
【００１０】
本発明の方法とシステムの提供する利点は、前記コンテキスト識別子長さをアップリンクとダウンリンク方向毎に別々に、決めることができることであり、それによりデータ転送リソースを効率的に利用できる。又、本発明の方法の提供する利点は、圧縮装置と伸張装置を中止したり、前記長さを変更する必要がある度毎にコンテキスト識別子をネゴシエートしたりする必要がないことである。本発明のもう一つの利点は、同一データ転送接続に対し、異なるコンテキスト識別子長さを持つデータパケットを多重化することが可能になることである。
【００１１】
以下、本発明について、好ましい実施例を使って、図面を参照しながら詳細に説明する。
【００１２】
（発明の詳細な説明）
以下問題となるヘッダフィールド圧縮方法ＲＯＨＣの実施例を、本発明に不可欠な部分について説明する。問題となるヘッダフィールド圧縮方法の詳細な説明については、未完のインターネット草案「Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ（ＲＯＨＣ）」バージョン０２、２０００年９月１８日を参照されたい。
【００１３】
各種の圧縮方法において、コンテキストが、典型的に圧縮装置と伸張装置に対し規定される。前記コンテキストとは、圧縮装置が転送ヘッダフィールドを圧縮し、伸張装置が受信ヘッダフィールドを伸張するのに使用する状態である。典型的には、コンテキストは、データ伝送接続において、転送される（圧縮装置）又は受信される（伸張装置）前のヘッダフィールドの非圧縮バージョンを含む。更に、コンテキストは、例えば、データパケットのシーケンス番号又はタイムスタンプのような、データパケット・フローを識別する情報を含む。従って、コンテキストは、典型的には、静的情報（全データパケット・フローに対し同一を保つ）と動的情報（全データパケット・フロー間変化するが、規定されたパターン煮従って）を含む。
【００１４】
ＲＯＨＣは、圧縮に３レベルを使っており、その圧縮を最低レベルから、次第に高レベルになるようにする。基本原則は、圧縮を最高レベルで行うことがであるが、その場合、圧縮装置は、伸張装置が問題のレベルで伸張を行うのに充分な情報を有しているという点について充分な確信を持たねばならない。圧縮レベル間の移動に影響を与える要因は、連続するヘッダフィールドにおける変動、伸張装置から受け取ったポジティブ、ネガティブのアクノリッジメント、及び、アクノリッジメントが無い時特定のシーケンシャルなカウンタの終了である。対応して、高位圧縮レベルから低位圧縮レベルへ移ることは可能である。
【００１５】
ＲＯＨＣがＩＰ（インターネットプロトコール）、ＵＤＰ（ユーザデータグラムプロトコール）とＲＴＰ（リアルタイムプロトコール）と接続して使う圧縮は、イニシエーション／リフレッシュ（ＩＲ）、第１オーダ（ＦＯ）、及び第２オーダ（ＳＯ）であり、これらレベル間の移動は図１のブロック図に示される。ＩＲレベルは、伸張装置のためにコンテキストを作成するのに、又は、エラー状態から回復するのに使用される。前記圧縮装置がＩＲレベルに移る時は、ヘッダフィールド圧縮が伸張装置の要請でスタートする時、又は、アップデートタイマが終了する時である。ＩＲレベルの時、圧縮装置は、非圧縮フォーマットのＩＲヘッダフィールドを送信する。圧縮装置がより高位のレベルに移行するように試みる時は、伸張装置がアップデート情報を確かに受信した時である。
【００１６】
ＦＯレベルは、データパケット・フローのヘッダフィールドにおける不規則性を受信者に通知するのに使われる。ＩＲレベルの後、圧縮装置は、ヘッダフィールドが一様なパターン（換言すれば、連続ヘッダフィールドは、変化を予測できないようなランダムな変化をする）を形成しない状況におけるＦＯレベルで動作する。即ち圧縮装置は、伸張装置が一様なパターンのヘッダフィールドを定めるパラメータを受信したことを確認することはできない。例えば、この典型的な状態は、音声を転送する時である。ＦＯレベルでは、圧縮装置は、圧縮したＦＯヘッダフィールドを送信する。圧縮装置が、再度、より高位レベルに移ろうと試みるのは、ヘッダフィールド圧縮が一様なパターンを形成し、伸張装置が一様なパターンを表すパラメータを受信したことが確かな時である。ＦＯレベルのデータパケットは、典型的には、コンテキスト・アップデート情報を含む。それは、伸張に成功するには、連続ＦＯヘッダフィールドの転送を成功させる必要があることを意味する。このように、伸張のプロセスを成功させる為には、ＦＯレベルのパケットの消失、破壊に敏感に対応する必要がある。
【００１７】
ＳＯレベルにおいては、圧縮は最適である。ヘッダフィールドは、一様なパターンを形成する。該パターンは、圧縮装置が圧縮されたＳＯヘッダフィールドで表現するものであり、前記ＳＯヘッダフィールドは、実際には、データパケットのシーケンス数である。一様なパターンのヘッダフィールドを規定するパラメータについての情報は、伸張装置に転送される。そして、パラメータと受信シーケンス番号に基づいて、伸張装置は、元のヘッダフィールドを外挿する。ＳＯレベルで送られるデータパケットは、実際には、相互に独立であり、伸張のエラー感度は低い。
ヘッダフィールドがもはや一様なパターンにならない時には、圧縮装置はＦＯレベルに戻る。
【００１８】
伸張にも圧縮レベルは、３レベルあって、伸張装置のコンテキスト規定に拘束される。コンテキストが未だに規定されていなかった（ｎｏ Ｃｏｎｔｅｘｔ）場合、伸張装置は最低レベルから動作を開始する。その時、伸張装置は、いかなるデータパケットをも伸張していない。伸張装置が、静的及び動的コンテキスト情報を有する第１データパケットを伸張した時、中間レベル（静的コンテキスト）を超えて、直接最上位レベル（フルコンテキスト）に移る。最上位レベルで複数エラー状態がある場合、伸張装置は中間レベルに移動する。しかし、典型的に、成功裏に伸張されたデータパケットは、伸張装置を最上位レベルに戻す。
【００１９】
複数伸張レベルに加えて、ＲＯＨＣは３動作モードを有する。即ち、一方向モード（Ｕモード）、双方向最適モード（Ｏモード）そして、双方向信頼モード（Ｒモード）であり、これを図２に示す。図２によると、各圧縮装置レベル（ＩＲ、，ＦＯ、ＳＯ）は、各モードにおける前記機能を説明するものであるが、各モードは、それぞれ独自に機能し、独自の仕方でレベル間の移動を定義する。各圧縮状態に対するモードの選択は、使用データ転送接続のパラメータ、例えば戻りチャネルを使用する可能性、エラー確率、分布、ヘッダフィールド規模の変動の影響に基づいて決まる。
【００２０】
一方向モードでは、データパケットの転送は、圧縮装置から伸張装置への転送のみである。従って、ＲＯＨＣのＵモードが有効であるのは、戻りチャネルの使用が出来ない場合、又は、望ましくない状況の場合である。Ｕモードでは、各圧縮レベル間の移動は、シーケンスカウンタの終了の結果、又は、ヘッダフィールド・パターンの変動、を基にして行われる。戻りチャネルが使用されないから、Ｕモードでの圧縮は余り有効ではない。又、伝送路におけるデータパケットの消失は、双方向モードにおけるより更に発生する可能性が高い。ＲＯＨＣの使用は、常にＵモードから始まり、双方向モードへ移ることができるのは、伸張装置が１以上のパケットを受信した時であって、この時パケットへの応答として、伸張装置は、モード変更が必要であることを指示する。
【００２１】
双方向最適（Ｏ）モードは、一方向モードと類似しているが、相違する点は、Ｏモードでは、戻りチャネルを使用して、エラー状態を訂正し、伸張装置から圧縮装置へ重要なコンテキスト・アップデートをアクノリッジする点である。Ｏモードでは、シーケンシャルなアップデートは行わない。Ｏモードが適しているのは、小さい戻りチャネル・トラフィックを持った、最適圧縮効率を必要とする接続である。Ｏモードは適度に信頼性のあるデータパケット転送を提供する。その場合、圧縮装置・伸張装置間の同期化が典型的に保持されており、データパケットはほとんど消失しない。もし消失したとしても無視できる数である。しかし、伝送路では、データパケットは、極端に高いビットエラー率で消失する。
【００２２】
双方向信頼（Ｒ）モードは、明らかに、前記モードとは異なる。Ｒモードは、戻りチャネルを使って、全コンテキスト・アップデートをアクノリッジする。このように、Ｒモードでは、圧縮装置・伸張装置間でデータパケットをほぼ全体的に確実に転送する事ができる。Ｒモードでは、ヘッダフィールド圧縮をしてもパケットの消失は起こらない。Ｒモードの欠点は、複数ケースにおいて、ヘッダフィールド・サイズが前記のモードに比して、少し大きめであり、戻りチャネルトラフィックがかなり増加する点である。
【００２３】
３つの動作モードとＲＯＨＣの３つの圧縮レベルは、ヘッダフィールド圧縮に対する各種動作状態を形成する。各状態は、圧縮装置と伸張装置の動作、及び、両装置間のパケットの伝送の定義を必要とする。当座は、ＲＯＨＣに対し、６つの異なるデータパケットタイプを定義する。内４つは圧縮装置から伸張装置への伝送に使用され、２つは、伸張装置から圧縮装置へ戻りチャネルデータパケットとして使用される。使用データパケット・タイプの数は、将来変わるかもしれないが、全データパケット・タイプは、特徴を有している。それは、伝送路にパケットを送出する前に、毎回使用されるコンテキストを定義コンテキスト識別子ＣＩＤを、各データパケットの先頭に付加することである。
【００２４】
各データパケットフロー毎に別々に、圧縮装置と伸張装置は、コンテキスト識別子ＣＩＤの長さをネゴーシエイトする。ＲＯＨＣの定義によれば、最低プロトコールレイヤ（リンクレイヤ）は、毎回使用され、パラメータ（例えば、ヘッダフィールド圧縮に使用されるコンテキスト識別子長さ）のネゴーシエイションのメカニズムを提供しなければならない。圧縮を開始する前に、パラメータをネゴーシエイトして、データパケット／フローのコンテキスト識別子長さを従来技術に倣って、０、８、又は１６ビットと定めることができる。一つの論理データ転送チャネル上で、複数データパケット・フローを同時に転送する事ができる。そのコンテキストは、コンテキスト識別子ＣＩＤにより、相互に識別、区別することができる。もしチャネル上で、データパケット・フローを一つだけ転送する場合は、これはＶｏＩＰアプリケーション（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）の典型例であるが、コンテキスト識別子長さに対し０値を与える。複数のデータパケット・フローを同一チャネルで転送する時、コンテキスト識別子長さについて、使用アプリケーション、データ転送プロトコール及びチャネル条件に基づいて、各データパケットフローに対し、８ビット、１６ビットを定義する。
【００２５】
前記双方向動作モード（ＯモードとＲモード）でネゴーシエイトするコンテキスト識別子長さは、戻りチャネルでも使用される。しかし、移動システムでは、例えば、フォワードチャネル（アップリンク）に比して戻りチャネル（ダウンリンク）において、より長いコンテキスト識別子を使用することが往々にして好ましい。何故ならば、特にパケットデータ・サービスを使用する場合、アップリンク方向よりダウンリンク方向で、より大量のデータが転送されるからである。次に、ＲＯＨＣによるヘッダフィールド圧縮が使われる時、典型的に、コンテキスト識別子長さを、戻りチャネル条件に従って定義する必要がある。その場合は、圧縮装置から伸張装置へのフォワードチャネルは、効率的に使用するできない。
【００２６】
図３のブロック図を使って、現在のＲＯＨＣ方法において、８ビットコンテキスト識別子がフォワードチャネルで定義され、１６ビットコンテキスト識別子が戻りチャネルで定義される場合に生じる問題を説明する。移動システムでは、例えば、アップリンクとダウンリンクチャネルは、自分自身の圧縮装置−伸張装置対を有し、例えば、端末は圧縮装置Ｃ１を有し、ネットワークサイドのアップリンク方向には、伸張装置Ｄ１がある。これに対応し、ネットワークのダウンリンク方向には、圧縮装置Ｃ２があり、そのカウンタパートは端末の伸張装置Ｄ２である。このように、圧縮装置Ｃ１は、８ビットコンテキスト識別子を有するデータパケット３００をアップリンクチャネル上で伸張装置Ｄ１に送信する。
【００２７】
ある段階で、例えば圧縮レベルが変化するとき、ネットワーク伸張装置Ｄ１は、ダウンリンクチャネルを使って、アクノレッジメントを端末に送信する。該アクノレッジメントは、データパケットを圧縮装置Ｃ２（３０２）に転送することにより、生成される。これは、８ビットコンテキスト識別子を前記アクノレッジメントに付加するものである。なぜなら、現在のＲＯＨＣ定義によると、両チャネルは、同一コンテキスト識別子長さを使用する必要があるからである。圧縮装置Ｃ２は、前記アクノレッジメントパケットをデータフロー（３０４）に付加し、ダウンリンクチャネルを使って端末に転送する。伸張装置Ｄ２は、前記アクノレッジメントパケットをチェックするが、伸張装置が１６ビットコンテキスト識別子を持つデータパケットを予想しているので、前記８ビットコンテキスト識別子に続く前記データパケットヘッダフィールドの第１バイトをコンテキスト識別子ＣＩＤの部分と解釈する。このため前記アクノレッジメントパケット又はその伸張装置について、エラーが発生する。
【００２８】
前記問題は、基本的に、従来技術の方法で回避することができる。例えば、アクノレッジメントが、戻りチャネルを使って伸張装置から到来する度に毎回、圧縮を妨害したり、フォワードチャネルのコンテキスト識別子長さを再ネゴシエーションする方法を使えばよい。しかし、こうすると、データフロー転送を相当スローダウンさせ、事実上、複数のアプリケーションでは、ＲＯＨＣの利用が不可能になる。実施における解決法は、圧縮装置を中断し、両方向に対し、１６ビットコンテキスト識別子フィールドをネゴシエーションすることである。しかし、これによれば、又、結果的にデータ転送リソースを最適に利用できないことになる。
【００２９】
前記問題は、本発明によれば、回避することができる。本発明は、データパケットコンテキスト識別子フィールドにおけるコンテキスト識別子長さを定義し、コンテキスト識別子長さの変化に対応するからである。前記データパケットのコンテキスト識別子長さを指示するために、１以上のコンテキスト識別子フィールドを予備に取っておくことが望ましい。又実際のコンテキスト識別子は、これらビットの後に、付加されることが望ましい。前記コンテキスト識別子長さは、各データパケット毎に別々に定義することが望ましく、その場合、データパケットフローにおける各データパケットが、特にそのコンテキスト識別子フィールドが、長さを定義する情報を有することが望ましい。
【００３０】
本方法においては、コンテキスト識別子長さを定義する情報を、各データパケットに、コンテキスト識別子フィールドの最初の複数ビット（ｂｉｔｓ）に付加することが望ましく、これにより新規のコンテキスト識別子が確実に受信装置に転送される。代替の方法として、コンテキスト識別子長さを前記の方法により決めることもでき、コンテキスト識別子長さの再定義後に、長さを定義する前記情報を有する第１データパケットだけが、転送される。しかし、これは、伸張装置に新規コンテキスト識別子を転送する方法として信頼できるものではない。
【００３１】
コンテキスト識別子長さの定義について、図４のテーブルに示す。これは、例示であって、本発明のコンテキスト識別子フィールド構成を有するデータパケットを示す。ＲＯＨＣに基づいて、コンテキスト識別子（ＣＩＤ）は、データパケットの第バイトの最初に付いており、データパケットのパケットヘッダ情報フィールド（ＰＨＩ）とデータパケットのペイロードが続いている。しかし、コンテキスト識別子は、又、各データパケットにおいて、問題となるデータパケットのコンテキスト識別子長さ（ＣＩＤ＿ｌｅｎ）を定義するフィールドを実質的に有する。図４のレイヤでは、前記長さを定義するフィールドの長さは、２ビットであるが、１から８ビットの間で変化することができることが好ましい。このように、コンテキスト識別子長さを表示するフィールドの情報が、問題となるデータパケットに対して、コンテキスト識別子長さを定義する。そして、次のデータパケットにおける長さ情報は、問題のデータパケットに対し、コンテキスト識別子長さを再定義する。実際のコンテキスト識別子（ＣＩＤ）は、数バイト、必要に応じ、２バイト以上有する。
【００３２】
このように、本発明の方法によれば、フォワードチャネル、戻りチャネルに対する各種のコンテキスト識別子を決めることが可能になり、これにより、データ転送リソースの使用が一層効率的になる。更に、圧縮と伸張を中止すること、及び、前記長さ変更を必要とする度毎に、コンテキスト識別子長さを再度ネゴシエーションすることは、本発明の方法により回避することができる。本発明の方法によれば、同一データ転送接続に対し、異なるコンテキスト識別子長さを持つデータパケットを多重化することが可能になる。
【００３３】
前記の方法を、例えば、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ）とＩＭＴ−２０００（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｐｈｏｎｅ Ｓｙｓｔｅｍ）のような第３世代移動システム、及び、第２世代移動システムの開発プロジェクト、例えばＧＥＲＡＮ（ＧＭＳ Ｅｄｇｅ  Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）に応用することができる。例えば、ＵＭＴＳシステムのデータパケットサービスにおいて、ラジオベアラを決めるパラメータの１つは、端末で使うデータパケットヘッダフィールドの圧縮装置方法である。データパケットのヘッダフィールドを圧縮し、受信データパケットを伸張することは、ＵＭＴＳシステムにおいて、パケットデータプロトコールに属するパケットデータ・コンバージェンス・プロトコールＰＤＣＰレイヤにおいて実行される。
【００３４】
ＰＤＣＰレイヤのタスクは、チャネル効率の改善に関係する機能を含み、これは、典型的には、各種の最適化方法、例えばデータパケット・ヘッダフィールドの圧縮アルゴリズムの利用、に基づくものである。現在、ＵＭＴＳのために計画されているネットワークレベルのプロトコールはＩＰプロトコールであるから、使用される圧縮装置アルゴリズムは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が標準化したものである。従って、前記ＲＯＨＣ圧縮方法は、特にＵＭＴＳシステムに最適である。端末のＰＤＣＰレイヤは、複数のヘッダフィールド圧縮方法をサポートするので、可能な限り多くのネットワークレベルのプロトコールタイプとの接続を確立することができる。
【００３５】
ＵＭＴＳシステムのパケットデータサービスで使用するアプリケーションにおけるアップリンクとダウンリンク方向で転送されるデータ量は、相互にかなり異なるもので、結果、かなり多量のデータが、アップリンク方向よりもダウンリンク方向で転送される。このように、本発明の構成においては、コンテキスト識別子は、アップリンク方向よりダウンリンク方向における方がより長くなるように決められるので、本発明によれば、ＵＭＴＳシステムにおいてラジオリソースの使用を改善できる。
【００３６】
技術が進歩する中で、本発明の基本アイデアを多くの様々な方法で実施することができることは当業者にとって明らかである。本発明とその実施は、従って、前記実施例に限定されるものではなく、特許請求の範囲内で変更しえるものである。
【図面の簡単な説明】
【図１】ＲＯＨＣの各種圧縮レベル間の移動を表すブロック図である。
【図２】ＲＯＨＣの各種圧縮モード間の移動を表すブロック図である。
【図３】フォワードチャネルと戻りチャネルにおける各種異なるコンテキスト識別子長さについて、従来のＲＯＨＣ技術が引き起こす問題の状態のブロック図である。
【図４】本発明の好ましい実施例のコンテキスト識別子フィールドを有するデータパケットである。
【図１】
0003559271.tif 000002
【図２】
0003559271.tif 000003
【図３】
0003559271.tif 000004
【図４】
0003559271.tif 000005