(57)【要約】コンプレッサ及びデコンプレッサの動作を制御するコンテキストが接続の一パラメータとして定義されるデータパケット接続のヘッダフィールド圧縮を定義する方法及びヘッダフィールド圧縮システムである。コンプレッサとデコンプレッサ間におけるデータ伝送用のデータパケット接続の識別に使用されるコンテキスト識別子に対して１つの接続で伝送されるデータパケット接続の最大数を定義する長さが定義される。それぞれのデータパケット接続は独自のコンテキスト識別子によって識別される。接続のパラメータは、コンテキスト識別子長が許容するデータパケット接続数を超過した場合にも少なくとも定義されたコンテキスト識別子長が許容する数のデータパケット接続のヘッダフィールド圧縮が可能となるように定義される。
2004512743.tif 000002
【特許請求の範囲】
【請求項１】
コンプレッサ及びデコンプレッサの動作を制御する接続の一パラメータとして前記コンプレッサ及びデコンプレッサに対してコンテキストを定義すると共に、前記コンプレッサ及びデコンプレッサ間におけるデータ伝送のデータパケット接続の識別に使用するコンテキスト識別子に対して１つの接続で伝送される圧縮データパケット接続の最大数を定義する長さを定義し、独自のコンテキスト識別子によって各データパケット接続が識別されるデータパケット接続のヘッダフィールド圧縮を定義する方法において、
前記コンテキスト識別子長が許容するデータパケット接続数を超過した場合にも、少なくとも前記定義されたコンテキスト識別子長が許容する数のデータパケット接続のヘッダフィールドを圧縮できるように前記接続のパラメータを定義する段階を有することを特徴とする方法。
【請求項２】
非圧縮データフローに対し、前記定義されたコンテキスト識別子長の少なくとも１つの値を予約する段階を有する請求項１記載の方法。
【請求項３】
圧縮がモバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
前記コンテキスト識別子長が許容するデータパケット接続数を超過した際に、前記コンテキスト識別子長の新しい値によってすべてのデータパケット接続のヘッダフィールドの圧縮が可能になるように無線ベアラパラメータを再定義するべく前記モバイルシステムをガイドする段階を有する請求項１又は２記載の方法。
【請求項４】
前記コンバージェンス・プロトコル・レイヤのデータパケット識別子に定義される値を使用して前記コンテキスト識別子長の新しい値を定義する段階を有する請求項３記載の方法。
【請求項５】
圧縮が前記モバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
新しいデータパケット接続を確立する際にそれが関連する無線ベアラを決定するモバイルシステム・エンティティに対してそれぞれの無線ベアラ用に定義されている同時データパケット接続の最大数を通知する段階と、
前記コンテキスト識別子長が許容するデータパケット接続数を超過した際に、前記コンテキスト識別子長の新しい値によってすべてのデータパケット接続のヘッダフィールドの圧縮が可能になるように無線ベアラパラメータを再定義するべく前記モバイルシステムをガイドする段階と、
を有する請求項１又は２記載の方法。
【請求項６】
圧縮が前記モバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
新しいデータパケット接続を確立する際にそれが関連する無線ベアラを決定するモバイルシステムエンティティに対してそれぞれの無線ベアラ用に定義されている同時データパケット接続の最大数を通知する段階と、
前記コンテキスト識別子長の最大値が許容するデータパケット接続数を超過した際に、更なるデータパケット接続用の新しい無線ベアラを定義するように前記モバイルシステムをガイドする段階と、
を有する請求項１又は２記載の方法。
【請求項７】
圧縮が前記モバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
前記コンテキスト識別子長の最大値が許容するデータパケット接続数を超過した際に、ヘッダフィールド圧縮なしで前記更なるデータパケット接続を伝送するように前記コンバージェンス・プロトコル・レイヤ又はそのコンプレッサをガイドする段階を有する請求項１又は２記載の方法。
【請求項８】
当該パケットが圧縮解除なしで受信されるということに基づき、前記更なるデータパケット接続に識別子を付加する段階を有する請求項７記載の方法。
【請求項９】
圧縮が前記モバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
前記コンテキスト識別子長の最大値が許容するデータパケット接続数を超過した際に、前記データパケット接続に対して該データパケット接続が割り当てられるいくつかのリンクレベル接続を定義するべく前記コンバージェンス・プロトコル・レイヤをガイドする段階を有する請求項１又は２記載の方法。
【請求項１０】
圧縮が前記モバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
前記コンテキスト識別子長の最大値が許容するデータパケット接続数を超過した際に、前記更なるデータパケット接続をリジェクトするべく前記コンバージェンス・プロトコル・レイヤをガイドする段階を有する請求項１又は２記載の方法。
【請求項１１】
前記端末が同時データパケット接続数を前記コンテキスト識別子長の最大値が許容するデータパケット接続数よりも小さく制限する請求項３から請求項１０までの請求項中のいずれか一項記載の方法。
【請求項１２】
コンプレッサ及びデコンプレッサと、
前記コンプレッサ及びデコンプレッサ間におけるデータパケット接続に対して前記接続の一パラメータとして定義され、前記コンプレッサ及びデコンプレッサの動作を制御すると共に、前記データパケット接続を識別するコンテキスト識別子を有するコンテキストと、
前記コンプレッサ及びデコンプレッサ間におけるデータ伝送用の前記コンテキスト識別子に対して定義され、１つの接続で伝送される圧縮データパケット接続の最大数を定義する長さと、
を有し、前記データパケット接続がコンテキスト識別子によって識別されるヘッダフィールド圧縮システムであって、
前記接続のパラメータは、前記コンテキスト識別子長が許容するデータパケット接続数を超過した場合にも、少なくとも前記定義されたコンテキスト識別子長が許容する数のデータパケット接続のヘッダフィールドが圧縮可能となるように定義されることを特徴とするシステム。
【請求項１３】
非圧縮データフローに対し、前記定義されたコンテキスト識別子長の少なくとも１つの値が予約される請求項１２記載のシステム。
【請求項１４】
圧縮がモバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
前記コンテキスト識別子長が許容するデータパケット接続数を超過した際に、前記コンテキスト識別子長の新しい値によってすべてのデータパケット接続のヘッダフィールドの圧縮が可能になるように無線ベアラパラメータを再定義するべく前記モバイルシステムがガイドされる請求項１２又は１３記載のシステム。
【請求項１５】
圧縮が前記モバイルシステムのコンバージェンス・プロトコル・レイヤによって制御されており、
前記コンテキスト識別子長の最大値が許容するデータパケット接続数を超過した際に、前記データパケット接続に対して該データパケット接続が割り当てられる複数のリンクレベル接続を定義するべく前記コンバージェンス・プロトコル・レイヤがガイドされる請求項１２又は１３記載のシステム。
【発明の詳細な説明】
【０００１】
（技術分野）
本発明は、データパケット接続のヘッダフィールド圧縮の定義方法に関し、更に詳しくは、モバイルシステムに圧縮を適用する際のデータパケット接続のヘッダフィールド圧縮の定義方法に関する。
【０００２】
（背景技術）
過去数年間のＩＰ（インターネットプロトコル）技術の急速な進歩により、従来からのインターネットデータ伝送以外の分野においても、ＩＰベースの様々なアプリケーションを使用する可能性が拡大している。特にＩＰベースの電話アプリケーションが急速な発展を遂げた結果、ＩＰ技術を利用することにより、原則的に、従来の電話網（ＰＳＴＮ／ＩＳＤＮ：公衆交換電話網／統合サービスデジタル網）及びモバイルネットワーク（ＰＬＭＮ：公衆陸上移動網）においても通話伝送路の更なる拡張が可能になっている。
【０００３】
モバイルネットワークの場合には、様々なＩＰ音声アプリケーションを利用して提供可能な従来からの音声サービスに加え、通常、パケット交換ＩＰベースのサービスとして実装することが最も好ましいインターネットブラウジング、電子メールサービス、及びゲームなどの様々な数多くのデータサービスが提供されるため、ＩＰ技術は、特にモバイルネットワークにおいて多数の利点をもたらすものであり、モバイルシステムのプロトコル内に配置されたＩＰレイヤは、オーディオ／ビデオサービスと様々なデータサービスの両面で有用な存在になるであろう。
【０００４】
モバイルネットワークでは、限られた無線リソースを可能な限り効率的に利用することが特に重要である。しかしながら、ＩＰベースのプロトコルは、転送データの様々なヘッダフィールドの割合が非常に大きく（従って、ペイロードの割合が小さく）、これが無線インターフェイスでのＩＰプロトコルの活用を複雑なものにしている原因の１つである。更には、悪条件下では、無線インターフェイスのビット誤り率（ＢＥＲ）とアップリンク／ダウンリンクの合計往復時間（ＲＴＴ）が大幅に増大し、この結果、既存の大部分のヘッダフィールド圧縮法において問題が発生する。以上のことから、特に無線インターフェイスによるデータ転送に適した（即ち、ビット誤り率と往復時間が大幅に増大する条件下でも使用可能な）様々なＩＰプロトコルに好適なヘッダフィールド圧縮法の開発に対するニーズが従来存在していたのである。
【０００５】
このために、近年、ＩＥＴＦ（インターネット・エンジニアリング・タスクフォース）がＲＯＨＣ（ロバストヘッダ圧縮）と呼ばれるヘッダフィールド圧縮法の標準化作業を行ってきた。このＲＯＨＣ開発の背後にあるのは、データパケットの転送に使用する複数のＩＰヘッダフィールド間には（データパケットの内部のみならずそれらの間においても）大きな冗長性が存在している、という考え方である。即ち、ヘッダフィールド内の情報のかなりの部分はデータパケット転送の際にまったく変化しないため、例え伝送されずとも、それらの再構築は容易である。圧縮の際に注意を要する情報を有しているのは、ヘッダフィールドの限られた部分にすぎない。ＲＯＨＣでは、複数の圧縮レベルを有しており、上位レベルに遷移すると圧縮効率が向上する。又、ＲＯＨＣでは、常に、可能な最も効率の高い圧縮を使用するべく試みるが、次のレベルに遷移する前に、そのレベルにおける動作の十分な信頼性を常に確認するようになっている。又、ＲＯＨＣの固有の特性として、圧縮法の使用に不可欠ないくつかの項目を下位のリンクレイヤによる処理に委ねている。
【０００６】
この送信者と受信者間（即ち、コンプレッサとデコンプレッサ間）で下位のリンクレイヤを介してネゴシエートされる項目の１つが無線リンクで使用するコンテキスト識別子（ＣＩＤ）の長さの定義である。コンテキスト識別子ＣＩＤとは、同一無線リンクによって伝送される複数のパケットデータフローを区別するために使用されるものであって、コンテキスト識別子ＣＩＤ長としては、大小いずれの値も許されており、大きな値の場合には、コンテキスト識別子長は１又は２バイト（８又は１６ビット）、小さな値の場合には０バイト（０ビット）である。尚、短いＣＩＤ長（０バイト）の場合には、コンテキスト識別子ＣＩＤによって複数の同時データフローを区別することはできないが、ＲＯＨＣには内部メカニズムがあって、コンテキスト識別子フィールド長が０バイトに定義されている場合にも、この内部メカニズムによって最大１６の同時データフローを区別することができる。ＣＩＤ長は、伝送対象データの圧縮を開始する前にネゴシエートされ、このネゴシエートされたコンテキスト識別子ＣＩＤ長がアップリンク及びダウンリンクの両方向で使用される。
【０００７】
この方式における１つの問題点は、例えば、定義されたコンテキスト識別子長が許容する最大数の同時データ接続が、無線ベアラ上で伝送されている状態で、端末ユーザーが更にもう１つの同時データフローの形成を所望した場合である。既に最大数のコンテキスト識別子が使用されているため、新しいデータフローに対してコンテキスト識別子を定義することは不可能であり、新しいデータフローの圧縮伝送が必要な場合には、既に使用されているデータフローコンテキストがその新しいデータフローに定義されることになる。これは、同一のコンテキスト識別子を備える２つの圧縮データ接続の確立を意味している。デコンプレッサはそれらを区別することができないため、圧縮システム全体がエラー状態となる。ＲＯＨＣの現方式は、この新しい「追加」データフローの取り扱い方法を定義していないため、上述の問題は、無線ベアラがコンテキスト識別子ＣＩＤが許容する最大数のデータ接続を使用している状態で、端末ユーザーが新しいデータフローのオープンを試みると常に発生することになる。又、例えば、ＲＯＨＣをモバイルシステムに適用する際には、使用端末に、例えば、メモリ空間などに起因する同時データ接続に対する独自の内部的制限が設定されている場合があり、これらの制限は、ＲＯＨＣが要求するものよりも厳しいものであることが多い。
【０００８】
（発明の簡単な説明）
従って、上述の欠点を軽減するための方法を実装する方法及び装置を開発することが本発明の目的である。この本発明の目的は、独立請求項の記述内容によって特徴付けられる方法及びシステムによって達成される。又、本発明の好適な実施例は、従属請求項に記述されている。
【０００９】
本発明は、コンテキスト識別子長が許容するデータパケット接続数を超過した場合にも、少なくとも定義されたコンテキスト識別子長が許容する数のデータパケット接続のヘッダフィールドを圧縮できるように無線ベアラパラメータを定義するという考え方に基づいている。本発明の好適な実施例によれば、定義されたコンテキスト識別子長の少なくとも１つの値を非圧縮データフローに割り当てることにより、これを実装することができる。本発明の第２の好ましい実施例は、モバイルシステムのコンバージェンス・プロトコル・レイヤが圧縮を制御するものであるが、これによれば、オリジナルのコンテキスト識別子長が許容するデータパケット接続数を超過した際に、新しいコンテキスト識別子長の値によってすべてのデータパケット接続のヘッダフィールド圧縮が可能となるように、無線ベアラパラメータを再定義するべくモバイルシステムをガイドする。本発明の更なる好適な実施例によれば、コンテキスト識別子長の最大値が許容するデータパケット接続数を超過した際に、それらのデータパケット接続に対して該データパケット接続が割り当てられる複数のリンクレベル接続を定義するように、コンバージェンス・プロトコル・レイヤをガイドする。
【００１０】
本発明の方法とシステムによれば、あらゆる状況において、少なくともコンテキスト識別子長の最大値が許容する数と同数の無線ベアラ伝送データ接続を圧縮することができるという利点が提供される。又、本発明の手順によれば、圧縮伝送データ接続の圧縮の中断が、回避されるという利点もある。そして、更なる本発明の利点は、本発明によれば最も効率的な方法でデータ接続に対してヘッダフィールド圧縮を適用できるということであり、無線リソースの効率的な利用ができる。
【００１１】
（発明の詳細な説明）
まず、本発明の不可欠な要素である対象とするヘッダフィールド圧縮法ＲＯＨＣの実装について説明するが、この圧縮法の更に詳細な情報については、未完のインターネットドラフト「ロバストヘッダ圧縮（ＲＯＨＣ）、０４版、２０００年１０月１１日（Ｒｏｂｕｓｔ Ｈｅａｄｅｒ Ｃｏｍｐｒｅｓｓｉｏｎ （ＲＯＨＣ）， ｖｅｒｓｉｏｎ ０４， １１ Ｏｃｔｏｂｅｒ ２０００）」を参照されたい。
【００１２】
各種の圧縮法では、通常、コンプレッサとデコンプレッサの両方に対してコンテキストが定義されるが、このコンテキストとは、コンプレッサが送信対象ヘッダフィールドの圧縮に使用すると共に、デコンプレッサが受信ヘッダフィールドの圧縮解除に使用する状態のことである。通常、コンテキストは、データ転送接続によって送信（コンプレッサ）又は受信（デコンプレッサ）された以前の非圧縮バージョンのヘッダフィールドから構成されており、更に、データパケットのシーケンス番号やタイムスタンプなどのデータパケットフローを識別する情報を有することができる。従って、コンテキストは、通常、データパケットフロー全体で同一に維持される静的情報と、データパケットフローにおいて変化するが、定義されたパターンに従って変化することが多い動的情報と、から構成されている。
【００１３】
ＲＯＨＣでは、３つの圧縮レベルが使用されており、圧縮は、最下位レベルから始まって徐々に上位レベルに継続される。基本的な原則は、常に、可能な最上位レベルで圧縮を実行するというものであるが、その際に、コンプレッサは、当該レベルで圧縮解除を実行するのに十分な情報をデコンプレッサが備えていることを十分に確認するようになっている。異なる圧縮レベル間での移動に影響を与える要因は、連続ヘッダフィールドにおける変化、デコンプレッサから受信したポジティブ及びネガティブなアクノリッジ、及びアクノリッジがない場合には、特定のシーケンシャルカウンタの期限満了である。同様に、上位圧縮レベルから下位レベルに移動することも可能である。
【００１４】
ＩＰ（インターネットプロトコル）、ＵＤＰ（ユーザーデータグラムプロトコル）、及びＲＴＰ（リアルタイムプロトコル）プロトコルと関連してＲＯＨＣが使用する圧縮レベルは、ＩＲ（イニシエーション／リフレッシュ）、ＦＯ（ファーストオーダー）、及びＳＯ（セカンドオーダー）であり、これらのレベル間での遷移が図１に示されている。ＩＲレベルは、デコンプレッサのためのコンテキスト作成やエラー状態からの回復のために使用されるものであり、コンプレッサは、ヘッダフィールド圧縮の開始、デコンプレッサによる要求、又は更新タイマの期限満了の際にＩＲレベルに移動する。このＩＲレベルでは、コンプレッサは、非圧縮フォーマットでＩＲヘッダフィールドを送信する。コンプレッサは、デコンプレッサが更新情報を受信したことが確認された時点で上位レベルへの移動を試みる。
【００１５】
ＦＯレベルは、データパケットフローのヘッダフィールドにおける不正について受信者に通知するために使用される。ＩＲレベルの後、ヘッダフィールドが一定のパターンを形成していないか（即ち、連続ヘッダフィールドが予測不能な様式でランダムに変化している）、或いはデコンプレッサがヘッダフィールドの一定のパターンを定義するパラメータを受信したことをコンプレッサが確認できない場合に、コンプレッサはＦＯレベルで動作する。これは、例えば、音声伝送を開始する際（特に、最初の音声バースト）に特有な状況であり、このＦＯレベルでは、コンプレッサは、圧縮されたＦＯヘッダフィールドを送信する。そして、ヘッダフィールドが一定のパターンを形成し、その一定のパターンを定義するパラメータをデコンプレッサが受信したことが確認された場合に、コンプレッサは再度上位レベルへの移動を試みる。ＦＯレベルのデータパケットは、通常、コンテキスト更新情報を有しており、これは、圧縮解除に成功するには連続ＦＯヘッダフィールドの伝送にも成功する必要があることを意味している。従って、圧縮解除プロセスの成否は、ＦＯレベルパケットの消失又は損傷の影響を受け易い。
【００１６】
ＳＯレベルにおいては、圧縮が最適化されている。ヘッダフィールドは、コンプレッサが圧縮ＳＯヘッダフィールド（実際には、これらはデータパケットのシーケンス番号である）を使って表わす一定のパターンを形成している。ヘッダフィールドの一定パターンを定義するパラメータに関する情報は、既にＦＯレベルでデコンプレッサに対して伝送されており、デコンプレッサは、それらのパラメータと受信したシーケンス番号に基づいてオリジナルのヘッダフィールドを推定する。このＳＯレベルで送信されるデータパケットは、実際には、互いに独立しているため、圧縮解除のエラー感度も低い。ヘッダフィールドが一定パターンを形成しなくなると、コンプレッサはＦＯレベルに戻る。
【００１７】
圧縮解除も、デコンプレッサのコンテキスト定義に結びついた３つのレベルを有している。コンテキストが定義されていない場合には（Ｎｏ Ｃｏｎｔｅｘｔ）、デコンプレッサは常に最下位レベルからその動作を開始する。この場合、デコンプレッサは、データパケットの圧縮解除をまだ１つも行っていない状態である。静的及び動的コンテキスト情報を有する最初のデータパケットを圧縮解除すると、デコンプレッサは、中間レベル（Ｓｔａｔｉｃ Ｃｏｎｔｅｘｔ）をスキップして直接最上位レベル（Ｆｕｌｌ Ｃｏｎｔｅｘｔ）に移動することができる。そして、最上位レベルでエラーが発生すると、デコンプレッサは中間レベルに戻るが、通常、データパケットの圧縮解除に１回成功するだけで、デコンプレッサは再度最上位レベルに戻る。
【００１８】
これらの圧縮レベルに加え、ＲＯＨＣは、単一方向モード（Ｕモード）、双方向オプティミスティックモード（Ｏモード）、及び双方向高信頼性モード（Ｒモード）という３つの異なる動作モードを備えており、これらが図２に示されている。この図２によれば、前述の各圧縮レベル（ＩＲ、ＦＯ、ＳＯ）はそれぞれのモードで機能するが、各モードは独自の方法で各レベルにおいて機能すると共に、独自の方法によってレベル間での遷移を決定する。各圧縮状況におけるモードの選択は、リターンチャネル使用の可能性、エラー確率と分布、ヘッダフィールドサイズの変化の影響など、使用するデータ転送接続のパラメータによって左右される。
【００１９】
単一方向モードにおいては、データパケットは、コンプレッサからデコンプレッサに対してのみ伝送される。従って、ＲＯＨＣのＵモードは、リターンチャネルの使用が不可能であるか、或いは、望ましくない状況において有用である。このＵモードでは、異なる圧縮レベル間における遷移は、シーケンシャルカウンタの期限満了、又はヘッダフィールドパターンの変化に基づいて実行される。リターンチャネルを使用しないため、Ｕモードにおける圧縮効率は低く、双方向モードのいずれと比べても伝送路におけるデータパケット消失の確率が高い。ＲＯＨＣの使用は、常にＵモードから始まり、いずれかの双方向モードへの遷移は、デコンプレッサが少なくとも１つのパケットを受信し、そのパケットに対する応答としてデコンプレッサがモード変更の必要性を通知した場合に行われる。
【００２０】
双方向オプティミスティックモードは、リターンチャネルによるエラー状態の訂正とデコンプレッサからコンプレッサへの重要なコンテキスト更新のアクノリッジを行うことを除けば、単一方向モードに類似している。シーケンシャル更新は、Ｏモードでは実行されない。好ましいことに、Ｏモードは、低リターンチャネルトラフィックで最適な圧縮効率を必要とする接続に適している。Ｏモードは、かなりの信頼性を有するデータパケット転送を提供するものであり、通常、コンプレッサとデコンプレッサ間の同期を良好に維持することが可能であって、データパケットの消失は稀である（発生しても、無視可能な数である）。但し、ビット誤り率が非常に高い場合には、伝送路においてデータパケットが消失する可能性がある。
【００２１】
双方向高信頼性モードは、前述の各モードとは明らかに異なっている。このＲモードでは、リターンチャネルを使用してすべてのコンテキスト更新をアクノリッジすると共に、シーケンス番号の更新もアクノリッジする。従って、Ｒモードにおいては、略全体的に高信頼性を維持しつつコンプレッサとデコンプレッサ間でデータパケットを伝送することが可能であり、Ｒモードでは、ヘッダフィールドの圧縮によってデータパケットが消失することはない。Ｒモードの欠点は、ヘッダフィールドのサイズが前述の各モードと比べてわずかに大きい場合があることと、リターンチャネルトラフィックが大幅に増加することである。
【００２２】
以上のＲＯＨＣの３つの動作モードと３つの圧縮レベルによってヘッダフィールド圧縮用の様々な動作状態が形成されており、これらそれぞれの状態毎に、コンプレッサ及びデコンプレッサの動作とそれらの間のパケット伝送の定義が必要となる。ＲＯＨＣでは、異なる動作状態に異なるパケットが使用される。現在、ＲＯＨＣには、６つの異なるデータパケットタイプが定義されており、この中の４つはコンプレッサからデコンプレッサへの伝送に使用され、２つはデコンプレッサからコンプレッサへのリターンチャネル・データパケットとして使用される。使用するデータパケットタイプの数は将来変化する可能性がある。データパケットを伝送パスに送信する前に、それぞれのパケットにその都度使用するコンテキストを定義するコンテキスト識別子ＣＩＤが付加されるという特徴は、すべてのデータパケットタイプに共通している。
【００２３】
このコンテキスト識別子ＣＩＤの長さは、各無線ベアラ毎に個別にコンプレッサとデコンプレッサによってネゴシエートされる。ＲＯＨＣの定義によれば、その都度使用される下位プロトコルレイヤ（リンクレイヤ）は、ヘッダフィールド圧縮に使用するコンテキスト識別子長などのパラメータをネゴシエートするためのメカニズムを提供しなければならない。これらのパラメータは、圧縮を開始する前にネゴシエートされ、従来技術により、この接続においてデータパケットフローのコンテキスト識別子長を、０、８、又は１６ビットに定義することができる。コンテキスト識別子ＣＩＤによって、コンテキストが識別及び区別される複数のデータパケットフローを、１つの論理データ転送チャネルによって同時に伝送することが可能である。チャネルで１つのデータパケットフローのみを伝送する場合には（これは、例えば、様々なＶｏＩＰ（Ｖｏｉｃｅ　ｏｖｅｒ　ＩＰ）アプリケーションに特有の状況である）、コンテキスト識別子ＣＩＤの長さは、「短く」設定される（即ち、値０が付与される）。しかしながら、この場合にも、内部ＲＯＨＣメカニズムを利用して最大１６の同時データフローを区別することが可能である（即ち、コンテキスト識別子ＣＩＤ長がゼロに定義されている場合にも、オリジナルのデータフローに加え、１５の新しいデータ接続が常にオープン可能である）。これは、最初の接続を常にコンテキスト識別子なしで伝送すると共に、後続のデータ接続に対して１バイトを付加することによって実装されている（この１バイトの最初の４ビットはそれがコンテキスト識別子であることを示し、後続の４ビットが実際のコンテキスト識別子値を示している）。但し、無線ベアラを定義する際に、同一チャネルで複数のデータパケットフローを伝送することが明らかな場合には、その無線ベアラで使用するアプリケーション、データ伝送プロトコル、及びチャネルの状態に応じて、コンテキスト識別子長として大きな値（即ち、１又は２バイト（８又は１６ビット））を定義することが好ましい。
【００２４】
ＲＯＨＣ規格に準拠したヘッダフィールド圧縮法の適用対象となる通信システムの１つが、ＵＭＴＳ（ユニバーサル移動電話システム）やＩＭＴ−２０００（国際移動通信システム）と呼ばれる第３世代モバイルシステムである。以下では、図３に基づいてＵＭＴＳシステムの構造について簡単に説明する。
【００２５】
この図３には、本発明の説明に不可欠なブロックのみが含まれているが、従来の携帯電話システムに、本明細書で詳細に説明する必要のないその他の機能や構造が含まれていることは、当業者には明らかである。携帯電話システムの主要構成要素は、携帯電話システムの固定ネットワークを形成するコアネットワークＣＮとＵＭＴＳ携帯電話システム陸上無線アクセスネットワークＵＴＲＡＮ、及び移動局（即ち、ユーザー機器）ＵＥである。そして、ＣＮとＵＴＲＡＮ間のインターフェイスはｌｕと呼ばれ、ＵＴＲＡＮとＵＥ間の無線インターフェイスはＵｕと呼ばれている。
【００２６】
ＵＴＲＡＮは、通常、複数の無線ネットワークサブシステムＲＮＳを有しており、ＲＮＳ間のインターフェイスは、ｌｕｒ（図示していない）と呼ばれている。ＲＮＳは、無線ネットワークコントローラＲＮＣと１つ又は複数のノードＢとも呼ばれる基地局ＢＳを有しており、ＲＮＣとＢＳ間のインターフェイスはｌｕｂと呼ばれている。基地局ＢＳは、通常、無線伝搬路の実装を担当し、無線ネットワークコントローラＲＮＣは、少なくとも、無線リソースの管理、セル間でのハンドオーバーの制御、電力調節、タイミング及び同期化、加入者端末のページングを管理している。
【００２７】
コアネットワークＣＮは、携帯電話システムに属すと共にＵＴＲＡＮには外部となるインフラから構成されている。コアネットワークにおいては、移動交換局／ビジタロケーションレジスタ３Ｇ−ＭＳＣ／ＶＬＲがホームロケーションレジスタＨＬＲに接続されており、インテリジェント・ネットワークのサービス制御ポイントにも接続されていることが好ましい。ホームロケーション・レジスタＨＬＲとビジタロケーション・レジスタＶＬＲは移動加入者に関する情報を有している（ホームロケーション・レジスタＨＬＲはモバイルネットワーク内の全加入者と彼らが加入しているサービスに関する情報を有しており、ビジタロケーション・レジスタＶＬＲは特定移動交換局ＭＳＣのエリアを訪問する移動局に関する情報を有している）。パケット無線システム３Ｇ−ＳＧＳＮ（サービングＧＰＲＳサポートノード）のサービングノードへの接続はインターフェイスＧｓ’を介して形成されており、固定電話網ＰＳＴＮ／ＩＳＤＮへの接続はゲートウェイ移動交換局ＧＭＳＣ（図示していない）を介して形成される。サービングノード３Ｇ−ＳＧＳＮから外部データネットワークＰＤＮへの接続は、インターフェイスＧｎを介してゲートウェイノードＧＧＳＮ（ゲートウェイＧＰＲＳサポートノード）に対して形成された後に、このＧＧＳＮが外部データネットワークＰＤＮに接続されている。移動交換局３Ｇ−ＭＳＣ／ＶＬＲ及びサービングノード３Ｇ−ＳＧＳＮから無線ネットワークＵＴＲＡＮ（ＵＭＴＳ陸上無線アクセスネットワーク）への接続は、インターフェイスｌｕを介して設定されている。尚、ＵＭＴＳシステムは、例えば、コアネットワークＣＮがＧＳＭシステムのコアネットワークと同一であって、ネットワークインフラ全体の再構築が不要となるように設計されていることに留意されたい。
【００２８】
ネットワークの構成要素名にＧＰＲＳシステムという用語が登場していることからもわかるように、ＵＭＴＳシステムは、ＧＳＭネットワークに接続されたＧＰＲＳシステムにかなり準拠して実装されたパケット無線システムを有している。ＵＭＴＳパケット無線システムは、複数のゲートウェイとサービングノードを有することができ、複数のサービングノード３Ｇ−ＳＧＳＮは、通常、１つのゲートウェイノード３Ｇ−ＧＧＳＮに接続される。両ノード３Ｇ−ＳＧＳＮ及び３Ｇ−ＧＧＳＮは、移動局のモビリティをサポートするルーターとして機能し、これらのルーターがモバイルシステムを制御し、それらの場所及び使用プロトコルとは無関係に、データパケットを移動局にルーティングする。サービングノード３Ｇ−ＳＧＳＮは、無線ネットワークＵＴＲＡＮを介して移動局ＵＥと接続される。サービングノード３Ｇ−ＳＧＳＮのタスクは、そのサービスエリア内のパケット無線接続能力を有する移動局を検出し、それらの移動局との間でデータパケットを送受信すると共に、そのサービスエリア内の移動局の場所を追跡することである。更に、サービングノード３Ｇ−ＳＧＳＮは、シグナリング・インターフェイスＧｓ’を介して移動交換局３Ｇ−ＭＳＣ及びビジタロケーション・レジスタＶＬＲと接続されており、インターフェイスＧｒを介してホームロケーション・レジスタＨＬＲと接続されている。このホームロケーション・レジスタＨＬＲには、パケット無線サービスに関連した加入者固有パケットデータプロトコルの内容を有するレコードも保存される。
【００２９】
ゲートウェイノード３Ｇ−ＧＧＳＮは、ＵＭＴＳネットワークパケット無線システムと外部データネットワークＰＤＮ（パケットデータネットワーク）間のゲートウェイとして機能する。これらの外部データネットワークには、第２のネットワーク事業者のＵＭＴＳ又はＧＰＲＳネットワーク、インターネット、Ｘ．２５ネットワーク、又はプライベート・ローカルエリアネットワークが含まれる。ゲートウェイノード３Ｇ−ＧＧＳＮは、インターフェイスＧｉを介してこれらのデータネットワークと接続されている。ゲートウェイノード３Ｇ−ＧＧＳＮとサービングノード３Ｇ−ＳＧＳＮ間で伝送されるデータパケットは、常に、ゲートウェイトンネリングプロトコルＧＴＰに従ってカプセル化される。ゲートウェイノード３Ｇ−ＧＧＳＮには、移動局のＰＤＰ（パケットデータプロトコル）アドレスとルーティング情報（即ち、３Ｇ−ＳＧＳＮアドレス）も格納されている。このルーティング情報を使用して外部データネットワークとサービングノード３Ｇ−ＳＧＳＮ間におけるデータパケットがリンクされる。ゲートウェイノード３Ｇ−ＧＧＳＮとサービングノード３Ｇ−ＳＧＳＮ間のネットワークにはＩＰプロトコルが採用されており、ＩＰｖ６（インターネットプロトコル第６版）であることが好ましい。
【００３０】
図４ａ及び図４ｂは、ＵＭＴＳシステムのパケット無線サービスにおける制御シグナリング（制御プレーン）とユーザーデータ伝送（ユーザープレーン）に使用するＵＭＴＳプロトコルスタックを示している。まず、図４ａは、移動局ＭＳとコアネットワークＣＮ間における制御シグナリングに使用するプロトコルスタックを示している。移動局のモビリティ管理ＭＭ、呼制御ＣＣ、及びセッション管理ＳＭは、中間に位置する基地局ＢＳと無線ネットワークコントローラＲＮＣがこのシグナリングにトランスペアレントになるように移動局ＭＳとコアネットワークＣＮ間の最上位プロトコルレイヤにおいてシグナリングされる。移動局ＭＳと基地局ＢＳ間における無線リンクの無線リソース管理は、無線ネットワークコントローラＲＮＣから基地局ＢＳに制御データを伝送する無線リソース管理システムＲＲＭによって管理されている。モバイルシステムの一般的な管理に関係するこれらの機能は、コアネットワークプロトコル（ＣＮプロトコル）と呼ばれるグループを形成しており、非アクセス階層（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）とも呼ばれている。同様に、移動局ＭＳ、基地局ＢＳ、及び無線ネットワークコントローラＲＮＣ間での無線ネットワーク制御に関連するシグナリングは、無線アクセスネットワークプロトコル（ＲＡＮプロトコル）と呼ばれるプロトコルレイヤ（即ち、アクセス階層（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ））上で実行される。これらは、最下位レベルの転送プロトコルを含んでおり、転送プロトコルによって伝送される制御シグナリングは、更なる処理のために上位レベルに転送される。上位アクセス階層の最も本質的な要素は、移動局ＭＳと無線ネットワークＵＴＲＡＮ間の無線リンクの確立、構成、維持管理、解放、並びにコアネットワークＣＮ及び無線ネットワークＲＡＮから移動局ＭＳへの制御情報の伝送を担当する無線リソース制御プロトコルＲＲＣである。又、この無線リソース制御プロトコルＲＲＣは、例えば、アプリケーションに基づいて容量を割り当てる際に、無線リソース管理システムＲＲＭの指示に従って無線ベアラに十分な容量を割り当てる責任をも負っている。
【００３１】
図４ｂに示されているプロトコルスタックは、ＵＭＴＳのパケット交換ユーザーデータの伝送に使用されるものである。無線ネットワークＵＴＲＡＮと移動局ＭＳ間のインターフェイスＵｕにおいて、物理レイヤでの低レベルのデータ伝送がＷＣＤＭＡ又はＴＤ−ＣＤＭＡプロトコルによって実行される。物理レイヤの上位に位置するＭＡＣレイヤは、物理レイヤとＲＬＣレイヤ間のデータパケット伝送を行い、ＲＬＣレイヤは、様々な無線ベアラの無線リンクの論理的な管理を実行する。このＲＬＣの機能には、例えば、伝送するユーザーデータ（ＲＬＣ−ＳＤＵ）を１つ又は複数のＲＬＣデータパケットＲＬＣ−ＰＤＵに分割することが含まれている。ＲＬＣの上位に位置するＰＤＣＰレイヤのデータパケット（ＰＤＣＰ−ＰＤＵ）のＩＰヘッダフィールドは、任意選択で圧縮可能である。この後、ＰＤＣＰ−ＰＤＵは、ＲＬＣに送られるが、それらは１つのＲＬＣ−ＳＤＵに対応している。ユーザーデータとＲＬＣ−ＳＤＵは分割され、ＲＬＣフレームで伝送されるが、これらには、データ伝送に不可欠なアドレスと検証情報が付加される。又、ＲＬＣレイヤは、損傷フレームの再送も実行する。サービングノード３Ｇ−ＳＧＳＮは、無線ネットワークＲＡＮを介して移動局ＭＳから正しいゲートウェイノード３Ｇ−ＧＧＳＮに到来するデータパケットのルーテイングを管理している。この接続では、コアネットワークを介して伝送されるすべてのユーザーデータとシグナリングをカプセル化して通過させるトンネリングプロトコルＧＴＰを使用している。ＧＴＰプロトコルは、コアネットワークが使用するＩＰの上で稼動する。
【００３２】
図５ａは、ＰＤＣＰレイヤの機能的モデルを示しており、それぞれの無線ベアラごとに１つのＰＤＣＰエンティティが定義されている。現在のシステムでは、それぞれの無線ベアラ毎に個別のＰＤＰコンテキストが定義されているため、各ＰＤＰコンテキスト毎に１つのＰＤＣＰエンティティが定義され、ＲＬＣレイヤ上の各ＰＤＣＰエンティティ毎に特定のＲＬＣエンティティが定義される。前述のように、原則的には、複数のＰＤＰコンテキストがＰＤＣＰレイヤで多重化され、ＰＤＣＰレイヤの下位のＲＬＣレイヤ上で１つのＲＬＣエンティティが複数の無線ベアラから同時にデータパケットを受信するようにＰＤＣＰレイヤを機能的に実装することも可能である。
【００３３】
図５ｂは、ＰＤＣＰエンティティが２つの異なるアプリケーションＡ及びＢから１つの無線ベアラを介してデータパケットを受信する状況を示している。無線ベアラ内のデータフローは、ＰＤＣＰエンティティのヘッダフィールドコンプレッサの前の段階で（この後、データフローが取得され圧縮される）、ＩＰヘッダフィールドに基づいて区別される。コンプレッサは、別個のコンテキスト識別子を定義することによってこれらのデータフローを区別し、受信者のデコンプレッサは、それらの識別子を利用して再度データフローを区別して圧縮解除することができる。尚、これを示すために、図５ｂでは、コンプレッサエンティティを２つの別個のボックスで示しているが、実際には、同一の圧縮エンティティ内に２つの圧縮コンテキストが存在している。但し、圧縮されたデータフローは、同一のＲＬＣ接続によって伝送される。
【００３４】
各ＰＤＣＰエンティティは、１つ又は複数のヘッダフィールド圧縮アルゴリズムを使用することができるが、まったく使用しなくてもよい。又、複数のＰＤＣＰエンティティが同一のアルゴリズムを使用することも可能である。無線リソースコントローラＲＲＣは、各ＰＤＣＰエンティティ用の適切なアルゴリズムをそのアルゴリズムを制御するパラメータと共にネゴシエートした後に、それら選択したアルゴリズムとパラメータをＰＤＣＰ−Ｃ−ＳＡＰポイント（ＰＤＣＰコントロールサービスアクセスポイント）を介してＰＤＣＰレイヤに通知する。使用する圧縮法は、接続上で使用されるネットワークレベルのプロトコルタイプによって異なるが、このタイプは、ＰＤＰコンテキストがアクティブになった際に無線リソースコントローラに通知される。
【００３５】
ＵＭＴＳシステムの場合には、伝送するデータパケットのヘッダフィールドの圧縮と受信データパケットの圧縮解除は、コンバージェンス・プロトコル・レイヤＰＤＣＰ上で行われる。このＰＤＣＰレイヤのタスクには、チャネル効率の改善に関連する機能が含まれており、これらは、通常、データパケットヘッダフィールドの圧縮アルゴリズムの利用などの様々な最適化法に基づいている。現在、ＵＭＴＳに計画されているネットワークレベルのプロトコルはＩＰプロトコルであり、使用する圧縮アルゴリズムはＩＥＴＦ（インターネット・エンジニアリングタスクフォース）が標準化したものとなる。従って、ＲＯＨＣ圧縮法は、とりわけＵＭＴＳシステムに適している。通常、端末のＰＤＣＰレイヤは、可能な限り多くのネットワークレベルのプロトコルタイプと接続を確立できるよう、複数のヘッダフィールド圧縮法をサポートしている。
【００３６】
ＲＯＨＣをＵＭＴＳのコンバージェンス・プロトコル・レイヤに適用する場合には、送信ＰＤＣＰ及び受信ＰＤＣＰの両方が、送信データパケットを圧縮すると共に受信データパケットを圧縮解除するコンプレッサ／デコンプレッサのペアを有している。コンバージェンス・プロトコル・レイヤＰＤＣＰは、ＲＯＨＣ圧縮法に対して各無線ベアラ用のコンテキスト識別子長をネゴシエートするためのメカニズムを提供する。このメカニズムは、実際には、ＰＤＣＰレイヤがコンプレッサ及びデコンプレッサのメッセージをＲＲＣに伝送し、実際のネゴシエーションはＲＲＣシグナリングによって実行される方式で実装される。可能な限り効率的に無線リソースを利用できるようにするには、無線ベアラ用のコンテキスト識別子ＣＩＤ長をゼロに定義することが好ましい。
【００３７】
無線ベアラ用に定義したコンテキスト識別子ＣＩＤ長が「短か」く（即ち、０バイト）て、可能な１６のデータ接続のすべてが使用されており、且つこのような定義を備える無線ベアラに対して端末ユーザーが更にもう１つの同時データフローの確立を望む時、問題が発生する。何故ならこの「短かい」コンテキスト識別子によって１７の同時データフローを区別することができないからである。ＲＯＨＣ規格に準拠したコンテキスト識別子では、この新しいデータフローを識別できないため、このデータフローに対して既存のデータフローのコンテキスト識別子が定義されることになる。その場合、同一のコンテキスト識別子を備えた２つのデータフローが同時に伝送されるが、デコンプレッサがそれらのデータ接続を区別できないため、結果的にエラーとなる。その他のＣＩＤ長の定義値に関しても、無線ベアラがコンテキスト識別子ＣＩＤ長に定義されている最大数のデータ接続を使用している状態で、端末ユーザーが新しいデータフローのオープンを試みると、同様の問題が発生する。一方、無線インターフェイスによって複数のデータフローをヘッダフィールドの圧縮をせず伝送すると、無線リソースの利用は最適化されない。そしてモバイルシステム全体の効率的な使用が妨げられる。
【００３８】
本発明の手順によって、この問題を軽減することができる。本発明によれば、前述のコンテキスト識別子長が許容するデータパケット接続数を超過した場合にも、少なくとも定義されているコンテキスト識別子長が許容する数のデータパケット接続ヘッダフィールドを圧縮できるように、無線ベアラパラメータが定義される。この結果、例えば、無線ベアラのコンテキスト識別子長がゼロに設定され、端末ユーザーがその無線ベアラに１７番目の同時データフローの確立を望む場合にも、少なくともオリジナルの１６（好ましくは１７）のデータフローをＲＯＨＣを使用して伝送することが可能になる。同様に、その他のＣＩＤの定義値についても、無線ベアラがコンテキスト識別子長に定義されている最大数のデータ接続を使用しており、端末ユーザーが新しいデータフローのオープンを試みた場合にも、少なくともオリジナルの数に対応する数のデータ接続（好ましくはすべてのデータフロー）をＲＯＨＣを使用して伝送することができるようになる。
【００３９】
本発明の第１の実施例によれば、ＲＯＨＣを使って前述の定義を行い、各無線ベアラ用にネゴシエートされたコンテキスト識別子ＣＩＤ長（ＣＩＤスペース）の少なくとも１つの値（好ましくは最後のもの）を常に非圧縮データフロー用に予約するべくＲＯＨＣアルゴリズムを定義することができる。この結果、既に使用中のデータ接続を圧縮伝送すると同時に、新しいデータ接続を圧縮なしで確立することができるようになる。例えば、コンテキスト識別子フィールドがゼロに設定されていれば、最初の１５のデータフローを圧縮し、端末のユーザーが新たな（１６番目の）データフローの形成を試みた場合に、そのデータフロー及びその後に形成されるあらゆる同時データフローを圧縮しないで受信者に伝送するよう、コンプレッサとデコンプレッサの間のネゴシーションに基づいてＲＯＨＣアルゴリズムを定義することができる。これらの非圧縮データパケットにはＣＩＤフィールドを付加し、それらのヘッダフィールドが圧縮されておらず、従って、デコンプレッサをスキップする必要があることを受信者に通知する。又、無線ベアラ用にネゴシエートされたコンテキスト識別子フィールドのＣＩＤスペースの複数の値を非圧縮データフロー用に予約することもできる。
【００４０】
本発明の第２の実施例によれば、コンバージェンス・プロトコル・レイヤＰＤＣＰがデータ接続数を監視し、許容されているデータ接続数を超過した場合に、ＰＤＣＰレイヤがこれを無線リソース制御プロトコルＲＲＣに通知し、ＲＲＣが無線ベアラの再構成を実行して各データフローのヘッダフィールドをＲＯＨＣに従って圧縮できるように無線ベアラパラメータ（特にコンテキスト識別子長）を再定義する。例えば、無線ベアラのコンテキスト識別子長がゼロに設定されている場合に、ＰＤＣＰレイヤが１７以上の同時データフローを検出すると、無線ベアラが再構成され、コンテキスト識別子フィールドの最大値がゼロよりも大きなものに定義される。このためには、新しい機能をＰＤＣＰレイヤに付加して各無線ベアラのデータ接続数を監視することが必要になる。無線ベアラ上のデータ接続数がコンテキスト識別子長の最大値に対応している場合には、新しいデータ接続が確立され、前述のようにＰＤＣＰがＲＲＣに通知する。例えば、端末の仕様上の制約により、ＲＲＣシグナリングを介して同時データ接続数を、例えば、４データフローに設定することも可能である。この場合、同時データ接続の最大数がコンテキスト識別子フィールドの最大値よりも小さければＲＯＨＣメカニズムが機能しないため、前述のように、ＰＤＣＰレイヤが同時データ接続数を監視できるようにする必要である。
【００４１】
好適な実施例によるこれら第１及び第２実施例は、第２実施例に従ってＰＤＣＰレイヤが無線ベアラ上のデータ接続数を監視すると共に、必要に応じ、最大コンテキスト識別子値が許容するデータ接続数を超過した追加のデータ接続についてヘッダフィールド圧縮を実行しないように第１実施例に従って定義する形態で、ＰＤＣＰレイヤを利用して使用することができる。この結果、少なくともオリジナルのデータフローを最適に圧縮伝送することができるようになる。この場合、無線ベアラのコンテキスト識別子長が、例えば、ゼロに定義された状態で、ＰＤＣＰレイヤが１７の同時データフローを検出すると、この最後の（１７番目）のフローは、ヘッダフィールド圧縮なしで伝送され、ＰＤＣＰレイヤの前述の機能により、この新しいデータフローはコンプレッサをスキップするようにガイドされる。好適な実施例によれば、ＰＤＣＰレイヤの前述の機能により、圧縮データフローを選択することも可能であり、この場合には、コンプレッサをスキップするようにガイドされるデータフローは、自動的に最後に形成されたデータフローにはならない。
【００４２】
第３の実施例によれば、データ接続を確立する際に新しいデータフローが属する無線ベアラを決定するＵＭＴＳエンティティ（例：セッション管理プロトコルＳＭ）に対し、データ接続を確立する際に、同時データ接続数に関するコンテキスト識別子の最大値の制限が通知される（特に、無線ベアラコンテキスト識別子長がゼロに設定されている場合）。この場合、１６のデータフローが使用中の状態で１７以上の同時データフローに対するニーズが検出された際には、新しい「追加」のデータフローに対して別途の独自の無線ベアラを定義するか、或いは、第１の無線ベアラを再構成してコンテキスト識別子フィールドの長さにゼロよりも大きな値を付与することができ、いずれの場合にも、各データフローのヘッダフィールドはＲＯＨＣに従って圧縮可能である。又、この実施例の場合にも、端末の仕様上の制約のために同時データ接続の最大数が、例えば、４データフローしかない状況を考慮しなければならず、このような場合には、前述のように、データ接続の確立を制御するエンティティが同時データ接続数を監視できるようにする必要である。
【００４３】
第４の実施例によれば、ＰＤＣＰレイヤのデータパケット構造内のパケット識別子（ＰＩＤ）を使用してコンテキスト識別子長に必要な変更を通知する。ＰＤＣＰレイヤでは、データパケットＰＤＵに付加されたパケット識別子ＰＩＤを利用して異なる圧縮法を示すと共に区別している。それぞれのＰＤＣＰエンティティごとに、パケット識別子ＰＩＤ値のテーブルが作成され、このテーブル内で様々な圧縮アルゴリズムが様々なデータパケットとマッチングされ、これらの組み合わせとしてパケット識別子ＰＩＤ値が決定される。圧縮アルゴリズムを使用していない場合には、パケット識別子ＰＩＤは値としてゼロを取得する。ＰＩＤ値は、それぞれの圧縮アルゴリズムのＰＩＤ値がｎ＋１から始まるように（ここで、ｎは、以前の圧縮アルゴリズムに定義した最後のＰＩＤ値）、それぞれの圧縮アルゴリズムとその異なるデータパケットタイプとの組み合わせ毎に連続的に定義され、圧縮アルゴリズムの順序は、無線リソースコントローラＲＲＣとのネゴシエーションにおいて決定される。このＰＩＣ値テーブルに基づき、パケットデータ接続の両端のＰＤＣＰエンティティは、送受信されるデータパケットの圧縮アルゴリズムを識別することができる。
【００４４】
本発明のこの実施例では、図６に示すテーブルに従ってＲＯＨＣの異なるコンテキスト識別子フィールド値（０、１、又は２バイト）に３つのＰＩＤ値を割り当てる形態で、これらのＰＩＤ値を利用することができる。この代わりに、２つのＰＩＤ値を割り当てて、ＣＩＤスペース値の「短い（０バイト）」及び「長い（１又は２バイト）」を表すことも可能である。そして、「長い」ＣＩＤスペース値の場合には、ＣＩＤフィールド拡張ビットを使用し、それが８或いは１６ビットＣＩＤフィールドのいずれであるかをより詳細に示すことができる。この場合、無線ベアラのコンテキスト識別子長がゼロに設定された状態で、ＰＤＣＰレイヤが１７の同時データフローを検出すると、受信ＰＤＣＰエンティティに対してこれらのＰＩＤ値を利用してＣＩＤフィールド長の変更を通知することができる。このＰＩＤ値は、無線ベアラが再構成されるか、或いはデータ接続数が１６に戻るまで伝送されることが好ましい。
【００４５】
第５の実施例によれば、ＣＩＤスペースの最大値を超過した場合に、ＣＩＤフィールド長の再定義を行わず、異なるデータ接続に対して別個のＲＬＣ接続を確立することができる。これは、ＣＩＤスペースの最大値を超過した場合に、それぞれの新しいデータ接続が別個のＲＬＣ接続（ＣＩＤフィールド長がゼロであることが好ましい）を取得する方式で実装することができる。この代わりに、ＣＩＤフィールド長がゼロに設定された別個のＲＬＣ接続を、それぞれのデータフローに定義することも可能である。更に、３２データフローが使用されている状況では、それらのデータフローを２つのＲＬＣ接続に分散することが可能であって、この場合、データフローを２つのＲＬＣ接続に分散することにより、好ましいことに、それぞれのＲＬＣ接続のＣＩＤフィールド長をゼロに維持することができる。尚、この場合には、ＰＤＣＰレイヤの仕様を変更して１つのＰＤＣＰエンティティが複数のＲＬＣ接続を同時に使用できるようにする必要がある。無線リソースの活用のためには、この実施例が最適であり、その理由は、それぞれの同時データフローをＣＩＤフィールドなしで（ＣＩＤ長＝０）伝送可能であり、伝送データのペイロード部分を最大化できるためである。
【００４６】
第６の実施例によれば、コンテキスト識別子に定義された最大値を超過した同時データ接続は、伝送するべく受け付けない。即ち、無線ベアラのコンテキスト識別子長が、例えば、ゼロに設定されており、１６のデータフローが使用されている状態で、１７番目の同時データフローの形成が試みられた場合には、ＰＤＣＰレイヤ及び／又はコンプレッサは、この１７番目のデータ接続を確立すべく受け付けを行わず、そのデータパケットはリジェクトされる。
【００４７】
このように、本発明の手順によれば、あらゆる状況において、少なくともその無線ベアラに定義されているコンテキスト識別子フィールドの最大長が許容する数と同数の無線ベアラ伝送データ接続を圧縮することができるようになる。更に、本発明の手順を利用すれば、圧縮伝送されているデータ接続の圧縮の中断を回避することができる。本発明の手順は、可能な最も効率的な方法でデータ接続に対するヘッダフィールド圧縮の適用を可能にするものであり、無線リソースの効率的な利用に有利である。
【００４８】
以上、ＵＭＴＳシステムを一例として使用し、本発明の手順について説明した。しかしながら、ＲＯＨＣによるヘッダフィールド圧縮はＵＭＴＳシステムに限定されるものではなく、好ましいことにＩＰデータパケットを伝送するあらゆる通信システムに適用することができる。又、本発明の手順は、好ましいことに、例えば、ＧＥＲＡＮ（ＧＳＭエッジ無線アクセスネットワーク）などの第２世代モバイルシステムの更なる開発プロジェクトにも適用可能である。
【００４９】
技術の進展に伴い、本発明の基本的なアイデアが様々な方法で実施可能であることは当業者には明らかである。従って、本発明及びその実施例は、前述の例に限定されるものではなく、添付の請求項の範囲内で変化し得るものである。
【図面の簡単な説明】
【図１】
ＲＯＨＣの様々な圧縮レベル間における遷移を示すブロックダイアグラムである。
【図２】
ＲＯＨＣの様々な動作モード間における遷移を示すブロックダイアグラムである。
【図３】
ＵＭＴＳシステムの構造を示す概略ブロックダイアグラムである。
【図４ａ】
制御シグナリング用のＵＭＴＳパケットデータサービスのプロトコルスタックを示す図である。
【図４ｂ】
ユーザーデータ伝送用のＵＭＴＳパケットデータサービスのプロトコルスタックを示す図である。
【図５ａ】
ＰＤＣＰレイヤの動作モードを示す図である。
【図５ｂ】
ＰＤＣＰレイヤの動作モードを示す図である。
【図６】
本発明の実施例によるデータパケット識別子の定義方法を示す図である。
【図４ａ】
2004512743.tif 000003
【図５ａ】
2004512743.tif 000004
【図５ｂ】
2004512743.tif 000005
【国際公開パンフレット】
2004512743.tif 000006
2004512743.tif 000007
2004512743.tif 000008
2004512743.tif 000009
2004512743.tif 000010
2004512743.tif 000011
2004512743.tif 000012
2004512743.tif 000013
2004512743.tif 000014
2004512743.tif 000015
2004512743.tif 000016
2004512743.tif 000017
2004512743.tif 000018
2004512743.tif 000019
2004512743.tif 000020
2004512743.tif 000021
2004512743.tif 000022
2004512743.tif 000023
2004512743.tif 000024
2004512743.tif 000025
2004512743.tif 000026
2004512743.tif 000027
2004512743.tif 000028
2004512743.tif 000029
2004512743.tif 000030
2004512743.tif 000031
2004512743.tif 000032
2004512743.tif 000033
【国際調査報告】
2004512743.tif 000034
2004512743.tif 000035
2004512743.tif 000036