(57)【要約】【課題】ヘッダ圧縮を用いた、パケットに基づいた改良された無線通信装置、およびこの無線通信装置の改良された操作方法、ならびにこのような改良された通信装置と方法に関連付けて用いられる改良された通信ユニットとソフトウエア製品を提供すること。【解決手段】第一ユニットAPと第二ユニットMT間で無線伝達を行うための方法が開示されている。この方法には、当該ユニットAP,MTが、リアルタイム・ビット・ストリーム（例えば、VoIP、オーディオ、およびビデオ）を、最大長が予め決定されている一つ以上のペイロードに変換することが含まれる。前記ペイロードまたは各当該ペイロードに、一つ以上の予め定義されているヘッダ（RTP/UDP/IP）が適用されて、当該ユニットAP,MT間での伝送を予め定義されている通信プロトコルに従って行うために適したパケットが生成される。次いで、このパケットまたは各パケットは、このパケットまたは各パケットをユニットMT,AP間の無線接続全体に転移するように適合化されているカプセル化プロトコル（BNEP）のフレームにカプセル化される。次に、予め定義されているヘッダ圧縮技法（IETFROHC）が、前記カプセル化されたパケット、または各カプセル化されたパケットに適用される。
2005509381.tif 000002
【特許請求の範囲】
【請求項１】
第一ユニットと第二ユニット間で、パケットに基づく無線伝送を行うための方法であって、
当該ユニットが、
a) リアルタイム・ビット・ストリームを、最大長が予め決定されている１つ以上のペイロードに変換することと、
b) 予め定義されている１つ以上のヘッダを前記ペイロードまたは各当該ペイロードに適用して、予め定義されている通信プロトコルに従って当該ユニット間で伝送を行うために適したパケットを生成することと、
c) 前記パケットまたは各当該パケットを当該ユニット間の無線接続全体に転移するように適合化されているカプセル化プロトコルのフレーム内に、前記パケットまたは各当該ペイロードをカプセル化することと、
d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されたパケットまたは各当該カプセル化されたペイロードに適用することと、
を含む方法。
【請求項２】
VoIPストリーム、オーディオ・ストリームまたはビジュアル・ストリームなどのインターネット・プロトコル（IP）のトラフィックを有する当該リアルタイム・ビット・ストリームから、前記ペイロード、または各当該ペイロードを生成することを含む、請求項１に記載の方法。
【請求項３】
当該第一ユニットと当該第二ユニット間でサービス発見プロシージャを行い、かつ当該サービス発見プロシージャの間に、当該ヘッダ圧縮技法をアドバタイズすることを含む、請求項１または請求項２に記載の方法。
【請求項４】
セグメントを一つ以上構成し、リアセンブリを行い、かつ圧縮されたビット・ストリームを運ぶ当該予め定義されている通信プロトコルのサービスを多重化することを含む、前記請求項の何れかに記載の方法。
【請求項５】
例えば当該カプセル化プロトコルの静的ヘッダ・フィールドを有するカプセル化プロトコル情報を、当該ヘッダ圧縮技法を適用するように適合化されているコンプレッサとデコンプレッサのコンテキストに加えることにより、当該ヘッダ圧縮を適用することを含む、前記請求項の何れかに記載の方法。
【請求項６】
当該ユニットが、Bluetoothネットワーク部分を含み、かつ、
当該方法が、Bluetoothネットワーク・カプセル化プロトコル（BNEP）を有するカプセル化プロトコルを用いて、前記パケットまたは各当該パケットをカプセル化すること、
を含む、前記請求項の何れかに記載の方法。
【請求項７】
好ましくは、当該予め決定されているヘッダとBNEPヘッダを組み合わせたものを予め決定されている長さ（例えば、3バイト）に縮小することにより、前記カプセル化されたパケットまたは各当該カプセル化されたパケットを、当該ヘッダ圧縮技法を用いて単一スロットのBluetoothベースバンド・パケットに圧縮することを含む、請求項6に記載の方法。
【請求項８】
当該ヘッダ圧縮技法を、インターネット技術特別調査委員会（IETF）により承認されたROHCなどの堅固なヘッダ圧縮（ROHC）フレームワークの形態で適用することを含む、前記請求項の何れかに記載の方法。
【請求項９】
a) 当該パケットに対して、リアルタイム・プロトコル（RTP）のプロファイルを用いること；
b) IETF ROHCによる双方向のオプティミスティックなアプローチ(oモード)を用いること；
c) 小さなROHCコンテキスト識別子（R-CID）を用いること（R-CIDの初期設定は空である）；
d) ユニバーサル・データグラム・プロトコル（UDP）のチェックサムを伝送せず、オプションで、このチェックサムをデコンプレッサで再計算すること；
e) いかなる1つのパケット・フローの間にも、前記カプセル化プロトコルのヘッダ全体を前記静的コンテキスト部分として見なすこと；
f) 前記リアルタイム・プロトコル（RTP）のシーケンス番号および／または前記インターネット・プロトコル識別しか伝送しないこと；
g) コンプレッサ内の「初期化とリフレッシュ」（IR）状態と、「第一オーダ」（FO）」状態と、「第二オーダ」（SO）状態との間のトランジション、およびデコンプレッサ内の「コンテキストがない」（NC）状態と、「静的コンテキスト」（SC）状態と、「完全なコンテキスト」（FC）状態との間のトランジションを定義すること；
を1つ以上含む、請求項8に記載の方法。
【請求項１０】
予め決定されている当該フレームしか当該ヘッダ圧縮技法により圧縮されないように、カプセル化フレームを分類することを含む、前記請求項の何れかに記載の方法。
【請求項１１】
リアルタイム・プロトコル（RTP）、ユニバーサル・データグラム・プロトコル（UDP）、およびインターネット・プロトコル（IP）の１つ以上に従って、当該ペイロードにヘッダを適用することを含む、前記請求項の何れかに記載の方法。
【請求項１２】
当該ユニットが、当該ユニット間で通信を行うための複数のロジカル・チャネルを構成し、
少なくとも一つの当該チャネルが、当該圧縮カプセル化されたパケットの転移を専用とすること、
を含む、前記請求項の何れかに記載の方法。
【請求項１３】
当該ヘッダ圧縮技法を、W-LSB（Window-Least Significant Bit coding）に基づいて行なうことを含む、前記請求項の何れかに記載の方法。
【請求項１４】
エラー回復要求と、オプションでコンテキスト更新の受信通知を行うように適合化された、当該ユニット間のフィードバック・チャネルを設けることにより、コンプレッサ状態とデコンプレッサ状態間のスイッチングを管理することを含む、前記請求項の何れかに記載の方法。
【請求項１５】
当該ユニットが、ベースバンド・パケットにセグメント化された一連の当該圧縮カプセル化されたフレームを受信し、
各当該パケットの肯定的な受信通知を行ってから、次の当該パケットが伝送され、かつ、
最新の当該パケットまたは受信通知メッセージの何れかの中で伝送エラーが発生した場合は、当該最新のパケットが再伝送されること、
を含む、前記請求項の何れかに記載の方法。
【請求項１６】
当該パケットの再伝送を、
a) ベースバンド・パケット・アクセス・コードが受信されない場合、
b) 補正不可能なエラーが、ベースバンド・パケット・ヘッダ内に存在する場合、または、
c) 補正不可能なエラーが、当該パケットの当該ペイロード内に存在する場合、
の少なくとも1つの場合に行うことを含む、請求項15に記載の方法。
【請求項１７】
例えば、当該フレームの送出に成功するまでのタイムアウトを設定することにより、当該圧縮されたカプセル化されたフレームの再伝送の回数を制限することを含む、前記請求項の何れかに記載の方法。
【請求項１８】
第一通信ユニットと第二通信ユニット間で、パケットに基づいた無線通信を実行するためのソフトウエア製品であって、
a) リアルタイム・ビット・ストリームを、最大長が予め決定されている１つ以上のペイロードに変換し、
b) １つ以上の予め定義されているヘッダを前記ペイロードまたは各当該ペイロードに適用して、予め定義されている通信プロトコルに従って当該ユニット間での伝送を行うために適したパケットを生成し、
c) 当該ユニット間の無線接続全体に前記パケットまたは各当該パケットを転移させるように適合化されているカプセル化プロトコルのフレーム内の前記パケットまたは各当該パケットをカプセル化し、かつ、
d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されたパケットまたは各当該カプセル化されたパケットに適用する、
ためのコードを含む、ソフトウエア製品。
【請求項１９】
実質的にリアルタイムで第二ユニットに情報を通信するように適合化されている第一ユニットを有する、パケットに基づいた無線通信装置であって、
当該第一ユニットが、
a) リアルタイム・ビット・ストリームを最大長が予め決定されている１つ以上のペイロードに変換し、
b) 予め定義されている通信プロトコルに従って当該ユニット間で伝送を行うために適したパケットを生成するために、予め定義されている１つ以上のヘッダを、前記ペイロード、または当該ペイロードの各々に適用し、
c) 前記パケット、または当該パケットの各々を、当該ユニット間の無線接続全体に転移するように適合化されているカプセル化プロトコルのフレーム内で、前記パケット、または当該パケットの各々をカプセル化し、かつ
d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されているパケット、または当該カプセル化されているパケットの各々に適用する、
ように適合化されている、パケットに基づいた無線通信装置。
【請求項２０】
当該第一ユニットが、前記Bluetoothプロトコルに従って動作可能であり、
当該カプセル化プロトコルが、Bluetoothネットワーク・カプセル化プロトコル（BNEP）を有することが好ましく、かつ、
当該ヘッダ圧縮技法が、インターネット技術特別調査委員会（IETF）の堅固なヘッダ圧縮（ROHC）技法との互換性を有することが好ましい、
請求項20に記載の無線通信装置。
【請求項２１】
請求項1〜19の何れかに記載の前記方法に従って動作するように適合化され、かつBluetooth通信ネットワークのマスタ・ユニットとスレーブ・ユニットの少なくとも一つとして少なくとも一時的に構成されることが好ましい、無線通信ユニット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信装置と、無線通信装置の操作方法とに関し、具体的には、パケットに基づいた無線通信装置と、ヘッダ圧縮 (header compression)を用いたパケットに基づいた無線通信装置の操作方法とに関する。本発明は、通信ユニット、およびこのような装置内で用いられるソフトウエア製品にも関する。
【背景技術】
【０００２】
ラジオ・ユニットと、これらのラジオ・ユニットを共有リソース・ネットワークに少なくとも一時的に群化するために用いられる接続とに基づいた、無線通信システムが知られている。この一般タイプの現在の実施例の１つは、レンジが短い周波数ホッピングによるネットワークの形態をしており、かつ本技術分野では、Bluetooth（登録商標）通信として知られている。この装置は、Bluetooth規格により制御され、かつBluetooth通信に準拠した完全な仕様は、Bluetooth SIG（Special Interests Group）で見出すことができる。このウェブ・サイト（www.bluetooth.com）には、現在のBluetooth規格と関連情報を見出すことができる。
【０００３】
Bluetooth通信の役立つ解説は、Jennifer BrayとCharles F. Sturmanの教科書「Bluetoothによる無線接続（Bluetooth, Connect Without Wires）」（出版元：Prentice Hall PTR, ISBN 0-13-089840-6）の形態で見出すことができる。
【０００４】
さらなる従来技術は、例えば、国際特許公開公報第WO 01/20940号、米国特許第5,940,431号、および公開済みの米国出願第2001/0005368号と米国出願第2001/0033601号に見出すことができる。これらの文献には、本技術分野における現在の最新技術の側面も幾つか解説されている。
【０００５】
本明細書の読者は、上述の資料を参照して、Bluetoothの一般的な背景情報を得て、かつさらに、例えば本願明細書で用いられているものの、特に定義されていない技術用語を明確にすべきである。
【０００６】
Bluetoothネットワーク内の各アクセス・ポイントは、例えば、遠隔通信用ハンドセットなどの移動端末を一つ以上有する、Bluetoothピコネットを形成する。このBluetooth PANは、VoIPフロー、および他のタイプのIPトラフィックを運ぶことができる。多数のハンドセット（または他の端末）を同じアクセス点に取り付けることが可能なので、利用可能な限られたバンド幅を用いる際の効率最大化が重要であることが理解できる（ピコネット毎の総容量は、合計で1Mbpsである）。
【０００７】
Bluetoothの新たな用途は、インターネット・プロトコル（VoIP）上で音声(Voice)を送出することであり、これは、インターネット上および企業ネットワーク／イントラネット内で展開されている。企業ネットワーク／イントラネットの場合、VoIPの主な利点は、データ用に通常利用されている既存のネットワーク・インフラストラクチャの音声トラフィックにより、VoIPが用いられることである。しかしながら、バンド幅が限られた無線リンクを通じてVoIPトラフィックを運ばなければならない場合、VoIPフローは遅延による影響を受けやすく、かつヘッダによるオーバヘッドが著しくなるので、バンド幅の浪費を最小化することが重要である。
【０００８】
図1に表されているアーキテクチャは、IPスタックが埋め込まれ、かつイントラネットなどの企業ネットワーク内でVoIP接続を確立することによりコードレス電話用ハンドセットとして動作可能な、Bluetoothを利用可能な第三世代（3G）移動電話を、移動端末MT1-nの1群内の1つのMT1が有する、可能なシナリオを示している。移動ハンドセットMT1は、イントラネット内の1組のアクセス・ポイントAP1…nを用いて、VoIP接続を確立する。このVoIP接続は、電話ネットワークへの専用ゲートウェイ(PABX / VoIP GW)を介した接続、または例えば、他のハンドセットMTnを1つ以上有するイントラネット内での接続の何れでもよい。
【０００９】
このVoIPパラダイムによると、音声サンプルは、使用されている音声コーダにその長さが依存するパケットに圧縮(compress)される。対話中に長い遅延が発生しないように、このようなペイロード長は制限されなければならない。GSMの品質を得るために、20バイトの音声パケットを生じる、5.3 kb/sのG;723.1コーダを用いることができる。このペイロードは、リアルタイム・プロトコル（RTP）を用いてタイム・スタンプされており、これによりヘッダは12バイトとなる。さらに、この結果得られるセグメントはUDPデータグラムで運ばれ、これにより、それ自体の8バイトのヘッダがさらに追加される。RTPは時間同期を行うことを容易にし、UDPは非接続型ロジカル・チャネルに幾つかのストリームを同時に多重化する(multiplex)ことを可能にする。次に、このRTP/UDPパケットは、IPデータグラムにカプセル化され、これにより、20バイトのIPヘッダが追加される。この状況は、IPバージョン6（IPv6）が用いられる場合、さらに悪化してしまう場合がある。なぜならば、この場合IPヘッダは、20バイトから40バイトに増加し、20バイトしかないペイロードに対して、ヘッダ全体が60バイトになってしまう可能性があるからである。VoIPパケットが有線LANを通じて運ばれる場合、バンド幅の利用効率がこのように低いことは大きな問題ではないかも知れないが、これに代えて無線LANが用いられる場合、重大な制約が生じてしまう場合がある。
【００１０】
Bluetooth通信の特定の場合、パーソナル・エリア・ネットワーク（PAN）のワーキング・グループがBluetooth上のIPを標準化しており、かつこのために、「Bluetoothネットワーク・カプセル化プロトコル（BNEP）」と命名された新たなプロトコルを開発している。このプロトコルは、Bluetooth用メディア上に共通のネットワーキング・プロトコルを転移するために用いられる、Bluetoothネットワークでカプセル化を行うためのパケット・フォーマットを定義している。BNEPは、Bluetoothのためにイーサネット（登録商標）のエミュレーションを行い、これによりIPデータグラムは、イーサネット・フレームにカプセル化され、かつ下にあるL2CAPレイヤに送信される。イーサネット・エミュレーション・レイヤを導入することにより、例えば、ネットワーク・アクセス・ポイント内またはBluetooth特別ネットワーク内で、ブロードキャスティング、マルチキャスティング、およびレイヤ2のブリッジング機能が実施可能となる。BNEPの完全な詳細は、上述したBluetooth SIGとそのウェブサイトから得ることができる。
【００１１】
しかしながら、BNEPは極めて柔軟ではあるが、それ自体のヘッダを圧縮するメカニズムがあるにも関わらずオーバヘッドは大きくなってしまう。高位レイヤのプロトコルのオーバヘッドにBNEPを集約させると、幾つかのアプリケーションの場合、バンド幅がかなり浪費されてしまう。例えば、上述したVoIPアプリケーションの場合、BNEPを用いてRTP/UDP/IPパケットをカプセル化すると、既に長いヘッダにさらに3〜15バイトが追加されてしまうので、20バイトのペイロードに対して、ヘッダ全体が少なくとも（12+8+20 +3 = 43）バイトから、最大で（12+8+40+15 = 75）バイトとなってしまう可能性がある。同様の考察事項は、例えば、オーディオ信号および／またはビデオ信号などのメディアなど、他のタイプのIPトラフィックにも該当する。これらの他のタイプのIPトラフィックの場合、オーディオ／ビジュアル用アプリケーションにより生成されたパケットは、VoIPパケットよりも大きな場合があるが、やはりヘッダのオーバヘッドを最小化することは重要である。事実、Bluetoothシステムが用いられる場合、オーディオ・コーダ／ビジュアル・コーダが、L2CAPフレームに１対１にマッピング可能なパケットを生成することが一般的である。これにより、より良好な再伝送制御が可能となり、かつ有効なパケット寿命が終わった際は常にバッファをフラッシュすることが容易になる。ヘッダ寸法が最小化された場合、ベースバンド・パケットのペイロードが有効となるので、実際のオーディオ・ペイロード／ビジュアル・ペイロードに対して、より広いバンド幅が確保される。
【００１２】
【特許文献１】国際特許公開公報第WO 01/20940号
【特許文献２】米国出願第2001/0005368号
【特許文献３】米国出願第2001/0033601号
【特許文献４】米国出願第2001/0005368号
【特許文献５】米国出願第2001/0033601号
【非特許文献１】Jennifer BrayとCharles F. Sturmanの「Bluetoothによる無線接続（Bluetooth, Connect Without Wires）」（出版元：Prentice Hall PTR, ISBN 0-13-089840-6）
【非特許文献２】「堅固なヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTPプロファイル, UDPプロファイル, ESPプロファイル、および非圧縮プロファイル(Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed)」（インターネット技術特別調査委員会（IETF）のウェブサイト（参照番号「RFC3095」、URL：http://www.ietf.org/rfc/rfc3095.txt）
【非特許文献３】S. CasnerとV. Jacobsonの「低速シリアル・リンクのためのIP/UDP/RTPヘッダの圧縮(Compressing IP/UDP/RTP Headers for Low-Speed Serial Links)」（インターネットRFC 2508）
【発明の開示】
【課題を解決するための手段】
【００１３】
本発明の目的は、改良された無線通信装置と、この無線通信装置の改良された操作方法とを提供することである。本発明のさらなる目的は、ヘッダ圧縮を用いた、パケットに基づいた改良された無線通信装置と、この無線通信装置の改良された操作方法とを提供することである。本発明のさらなる目的は、このような改良された通信装置と方法に関連付けられて用いられる、改良された通信ユニットとソフト製品とを提供することである。このように本発明の目的は、具体的には、Bluetoothパーソナル・エリア・ネットワーク内における、VoIP、オーディオおよび／またはビデオなどのインターネット・プロトコル（IP）のビット・ストリームに対する、RTP/UDP/IP/BNEPヘッダに起因するオーバヘッドを低減させることである。
【００１４】
したがって、本発明は、第一ユニットと第二ユニット間で無線伝送(wireless transmission)を行うための方法であって、
当該ユニットが、
a) リアルタイム・ビット・ストリームを、最大長が予め決定されている１つ以上のペイロードに変換することと、
b) 予め定義されている１つ以上のヘッダを前記ペイロードまたは各当該ペイロードに適用して、予め定義されている通信プロトコルに従って当該ユニット間で伝送を行うために適したパケットを生成することと、
c) 前記パケットまたは各当該パケットを当該ユニット間の無線接続全体に転移するように適合化されているカプセル化プロトコルのフレーム内に、前記パケットまたは各当該ペイロードをカプセル化することと、
d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されたパケットまたは各当該カプセル化されたペイロードに適用することと、
を含む方法を提供する。
【００１５】
この方法は、VoIPストリーム、オーディオ・ストリームまたはビジュアル・ストリームなどのインターネット・プロトコル（IP）のトラフィックを有する当該リアルタイム・ビット・ストリームから、前記ペイロード、または各当該ペイロードを生成することを含んでもよい。
【００１６】
この方法は、当該第一ユニットと当該第二ユニット間でサービス発見プロシージャを行い、かつ当該サービス発見プロシージャの間に、当該ヘッダ圧縮技法をアドバタイズすることを含んでもよい。
【００１７】
この方法は、リアセンブリを行い、かつ圧縮されたビット・ストリームを運ぶ当該予め定義されている通信プロトコルのサービスを多重化することを含んでもよい。
【００１８】
この方法は、例えば、当該カプセル化プロトコルの静的ヘッダ・フィールドを有するカプセル化プロトコル情報を、当該ヘッダ圧縮技法を適用するように適合化されているコンプレッサ(compressor)とデコンプレッサ(decompressor)のコンテキストに加えることにより、当該ヘッダ圧縮を適用することを含んでもよい。
【００１９】
当該ユニットは、Bluetoothネットワークなどのラジオ通信ネットワーク部分を有してもよく、かつ当該方法は、BNEPを有するカプセル化プロトコルを用いて、前記パケットまたは各当該パケットをカプセル化することを含んでもよい。
【００２０】
この方法は、好ましくは、当該予め決定されているヘッダとBNEPヘッダを組み合わせたものを予め決定されている長さ（例えば、3バイト）に縮小することにより、前記カプセル化されたパケットまたは各当該カプセル化されたパケットを、当該ヘッダ圧縮技法を用いて単一スロットのBluetoothベースバンド・パケットに圧縮することを含んでもよい。
【００２１】
この方法は、当該ヘッダ圧縮技法を、インターネット技術特別調査委員会（IETF）により承認されたROHCなどの堅固なヘッダ圧縮（ROHC）フレームワークの形態で適用することを含んでもよい。
【００２２】
この方法は、
a) 当該パケットに対して、リアルタイム・プロトコル（RTP）のプロファイルを用いること；
b) IETF ROHCによる双方向のオプティミスティックなアプローチ(oモード)を用いること；
c) 小さなROHCコンテキスト識別子（R-CID）を用いること（R-CIDの初期設定は空である）；
d) ユニバーサル・データグラム・プロトコル（UDP）のチェックサムを伝送せず、オプションで、このチェックサムをデコンプレッサで再計算すること；
e) いかなる1つのパケット・フローの間にも、前記カプセル化プロトコル・ヘッダ全体を前記静的コンテキスト部分として見なすこと；
f) 前記リアルタイム・プロトコル（RTP）のシーケンス番号および／または前記インターネット・プロトコル識別しか伝送しないこと；
g) コンプレッサ内の「初期化とリフレッシュ」（IR）状態と、「第一オーダ」（FO）」状態と、「第二オーダ」（SO）状態との間のトランジション、およびデコンプレッサ内の「コンテキストがない」（NC）状態と、「静的コンテキスト」（SC）状態と、「完全なコンテキスト」（FC）状態との間のトランジションを定義すること；
を一つ以上含んでよい。
【００２３】
この方法は、予め決定されている当該フレームしか当該ヘッダ圧縮技法を用いて圧縮されないように、カプセル化フレームを分類する (classify)ことを含んでもよい。
【００２４】
この方法は、リアルタイム・プロトコル（RTP）、ユニバーサル・データグラム・プロトコル（UDP）、およびインターネット・プロトコル（IP）の１つ以上に従って、当該ペイロードにヘッダを適用することを含んでもよい。
【００２５】
この方法は、当該ユニットが当該ユニット間で通信を行うための複数のロジカル・チャネルを構成し、少なくとも一つの当該チャネルが、当該圧縮カプセル化されたパケットの転移を専用とすることを含んでもよい。
【００２６】
この方法は、当該ヘッダ圧縮技法を、W-LSB（Window-Least Significant Bit coding
）に基づいて行なうことを含んでもよい。
【００２７】
この方法は、エラー回復要求と、オプションでコンテキスト更新の受信通知を行うように適合化された、当該ユニット間のフィードバック・チャネルを設けることにより、コンプレッサ状態とデコンプレッサ状態間のスイッチングを管理することを含んでもよい。
【００２８】
この方法は、
当該ユニットが、ベースバンド・パケットにセグメント化された一連の当該圧縮カプセル化されたフレームを受信 (receive)し、
各当該パケットの肯定的な受信通知を行ってから、次の当該パケットが伝送され、かつ、
最新の当該パケットまたは受信通知メッセージの何れかの中で伝送エラーが発生した場合は、当該最新のパケットが再伝送されること、
を含んでもよい。
【００２９】
この方法は、当該パケットの再伝送を、
a) ベースバンド・パケット・アクセス・コードが受信されない場合、
b) 補正不可能なエラーが、ベースバンド・パケット・ヘッダ内に存在する場合、または、
c) 補正不可能なエラーが、当該パケットの当該ペイロード内に存在する場合、
の少なくとも1つで行うことを含んでもよい。
【００３０】
この方法は、
例えば、当該フレームの送出に成功するまでのタイムアウトを設定することにより、当該圧縮されたカプセル化されたフレームの再伝送の回数を制限することを含んでもよい。
【００３１】
本発明は、第一通信ユニットと第二通信ユニット間で、パケットに基づいた無線通信を実行するためのソフトウエア製品であって、
a) リアルタイム・ビット・ストリームを、最大長が予め決定されている１つ以上のペイロードに変換し、
b) １つ以上の予め定義されているヘッダを前記ペイロードまたは各当該ペイロードに適用して、予め定義されている通信プロトコルに従って当該ユニット間での伝送を行うために適したパケットを生成し、
c) 当該ユニット間の無線接続全体に前記パケットまたは各当該パケットを転移させるように適合化されているカプセル化プロトコルのフレーム内の前記パケットまたは各当該パケットをカプセル化し、かつ、
d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されたパケットまたは各当該カプセル化されたパケットに適用する、
ためのコードを含む、ソフトウエア製品も提供する。
【００３２】
当該ソフトウエア製品は、当該通信ユニットの一部を形成する、Bluetoothネットワークのインターフェース用ソフトウエアのドライバに関連させて走らせてもよい。
【００３３】
本発明は、
実質的にリアルタイムで第二ユニットに情報を通信するように適合化されている第一ユニットを有する、パケットに基づいた無線通信装置であって、
当該第一ユニットが、
a) リアルタイム・ビット・ストリームを最大長が予め決定されている１つ以上のペイロードに変換し、
b) 予め定義されている通信プロトコルに従って当該ユニット間で伝送を行うために適したパケットを生成するために、予め定義されている１つ以上のヘッダを、前記ペイロード、または当該ペイロードの各々に適用し、
c) 前記パケット、または当該パケットの各々を、当該ユニット間の無線接続全体に転移するように適合化されているカプセル化プロトコルのフレーム内で、前記パケット、または当該パケットの各々をカプセル化し、かつ
d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されているパケット、または当該カプセル化されているパケットの各々に適用する、
ように適合化されている、パケットに基づいた無線通信装置も提供する。
【００３４】
当該第一ユニットは、Bluetoothプロトコルに従って動作可能である。当該カプセル化プロトコルは、BNEPを有することが好ましく、かつ当該ヘッダ圧縮技法は、インターネット技術特別調査委員会（IETF）の堅固なヘッダ圧縮（ROHC）技法との互換性を有することが好ましい。
【００３５】
本発明は、アクセス・ポイントまたは移動端末などのBluetoothネットワークのマスタ・ユニットまたはスレーブ・ユニットを有することが好ましい、本発明の方法に従って動作するように適合化されている通信ユニットも提供する。ヘッダ圧縮、および／または、カプセル化されているパケットの解凍 (decompression)は、当該通信ユニットに関連付けられているBluetoothネットワークのインターフェース用ソフトウエアのドライバで走るソフトウエア製品の形態で実施してもよい。このソフトウエア製品には、BNEPレイヤとL2CAPレイヤ、フレーム・クラシファイア (frame classifier)、ROHCコーデック、および調和を図るためのマネージメント・エンティティ（ME）を含めてもよい。このマネージメント・エンティティは、HCI（ホスト制御インターフェース）を介してBluetoothベースバンド通信を行い、かつオペレーティング・システムが特定されたメカニズムにより上位プロトコル・レイヤと通信してもよい。例えば移動端末MT1-nとして具体化されているスレーブ通信ユニットが、例えばアクセス点AP1-nとして具体化されているマスタ・ユニットに接続するたびに、マネージメント・エンティティが、そのマスタ・ユニットのメディア・アクセス・アドレス (MAC)を登録することにより、当該スレーブ・ユニットに対するロジカル・チャネルを構成してもよい。
【発明を実施するための最良の形態】
【００３６】
次に、本発明を、特定の実施例を参照しながら、かつ上述した図面を参照しながら説明する。このような説明は、例示的なものでしかなく、かつ本発明は、この例示に限定されない。具体的には、パケットと、パケットに基づいた通信システムとを参照する。本発明は、パケット・スイッチト・システムには限定されず、データを伝送するための手段としてパケットを用いたいかなるシステム（つまり、このシステムが、パケット・スイッチト・システム、回路スイッチト・システム、または別のシステムか否かを問わない）に適用可能であることを、当業者は認識するであろう。「無線 (wireless)」という語が述べられた場合、これを、その最も広い意味で理解すべきである。例えば、無線には、その伝送のある部分が有線ネットワークに依存しない、いかなるシステムも含めることができる（例えば、拡散赤外線方式などの光学的伝送方法が含まれる）。しかしながら、本発明のすべての実施例は、Bluetoothプロトコルと共に利用可能であることに留意されたい。このようなシステムの特徴には、以下のことが１つ以上含まれていてよい。
‐散乱スペクトル技法として低速周波数ホッピングが用いられていること。
‐マスタ・ユニットとスレーブ・ユニットであって、このマスタ・ユニットがホッピング・シーケンスを設定できること。
‐各デバイスが、それ自体のクロックとそれ自体のアドレスとを有していること。
‐マスタ・ユニットのホッピング・シーケンスを、マスタ・ユニットのアドレスから決定できること。
‐１つのマスタ・ユニットと通信中の1組のスレーブ・ユニットがすべて、(このマスタ・ユニットと）同じホッピング周波数を有し、かつピコネットを形成すること。
‐共通のスレーブ・ユニットを介してピコネットをリンクして、スキャッタネットを形成できること。
‐スレーブ・ユニットとマスタ・ユニット間が、時分割多重伝送 (TDMA)であること。
‐スレーブ・ユニットとマスタ・ユニット間が、時分割複信 (TDD)であること。
‐スレーブ・ユニットとマスタ・ユニット間の伝送が、同期式または非同期式の何れでもよいこと。
‐スレーブ・ユニットがいつ伝送を行えるかを、マスタ・ユニットが決定すること。
‐スレーブ・ユニットが、マスタ・ユニットによりアドレス指定されている場合しか、応答してはならないこと。
‐クロックが自走式であること。
‐ネットワークが、調和が図られておらず、特に2.4 GHzのライセンスフリーのISMバンドで動作するものであること。
‐ソフトウエア・スタックによって、エリア内の他のBluetoothデバイスをアプリケーションが見つけることが可能になること。
‐他のデバイスは発見／照会プロシージャにより見つけられること。
‐ハード・ハンドオーバとソフト・ハンドオーバーが行われること。
【００３７】
周波数ホッピングに関しては、「低速周波数ホッピング (slow frequency hopping)」とは、ホッピング周波数が変調率よりも低速であることを指し、「高速周波数ホッピング (fast frequency hopping)」とは、ホッピング率が変調率よりも高速であることを指す。本発明は、低速ホッピングと高速ホッピングの何れにも限定されない。
【００３８】
以下に参照するユーザ端末は移動端末だが、本発明は移動端末に限定されず、コンピュータなどの固定式のユーザ端末も含んでいる。
【００３９】
本願明細書ではヘッダ圧縮技法を参照し、かつ具体的には、堅固なヘッダ圧縮 (ROHC)を参照する。これらの技法の側面を幾つか要約説明することが役立つと考えられるが、より詳しく理解するためには、C. Borman外による、2001年7月の論文、「堅固なヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTPプロファイル, UDPプロファイル, ESPプロファイル、および非圧縮プロファイル (Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed)」を参照されたい。本論文は、「インターネット技術特別調査委員会（IETF）」のウェブサイト（参照番号「RFC3095」）で見つけることができ、かつURL：http://www.ietf.org/rfc/rfc3095.txtからアクセス可能である。
【００４０】
一般に、ヘッダ圧縮メカニズムは、例えばIPアドレスとUDPポートを有する静的ヘッダ・フィールドは、セッション間には変化しないので、あらゆるパケット内で送信する必要はないという事実を利用することにより、ヘッダ・オーバヘッドを縮小させる。さらに、セッション間に変化するフィールド（例えば、RTPタイムスタンプ、RTPシーケンス番号、およびIP識別）を効率的に扱うことが可能なので、ヘッダ・オーバヘッドをさらに縮小させることができる。これらのいわゆる「変化するフィールド」は、単純な直線外挿を用いて、直前のパケットから予測可能な場合もある。他のヘッダ・フィールド（例えば、IPヘッダ長とUDP長）は、データリンク・レベルから推定可能であり、かつこれらのフィールドを伝送する必要はないので、これらのフィールドは「推定フィールド」と呼ばれる。
【００４１】
ヘッダ圧縮方式は、1999年2月の論文「低速シリアル・リンクのためのIP/UDP/RTPヘッダの圧縮 (Compressing IP/UDP/RTP Headers for Low-Speed Serial Links)」（インターネットRFC 2508）において、S. CasnerとV. Jacobsonにより提案された。この方式は、RTP/UDP/IPヘッダを圧縮するが、典型的な無線リンク上で遭遇するエラー率および往復遅延を扱うようには設計されていない。
【００４２】
例えば、「適合ヘッダ圧縮 (ACE: Adaptive header Compression)」および「堅固なチェックサムに基づいたヘッダ圧縮 (ROCCO: Robust Checksum-based header Compression)」などの、ヘッダ圧縮を無線環境に適合化するための技法が提案されている。「ACE」は、フィールドをコード化する方式である「変化するフィールド (changing fields)」（W-LSB (Window-based Least Significant BIT)）を導入している。この方式では、可変スライディング・ウィンドウ（VSW）内に含まれた幾つかの参照値が用いられ、これらの値がデコンプレッサに通信される。ROCCOはCRCを用いて、デコンプレッサ内で再構築が正確に行われたことを確証し、かつエラーが伝搬しないようにする。
【００４３】
IETF ROHCワーキング・グループは、現在、エラー率が高くかつ往復時間が長いリンク上で良好に作用する、新たな圧縮方式を研究している。これらの方式は、WCDMA、EDGE、およびCDMA-2000などの技術を用いて構築されたセル・リンクに対して、効果を発揮するに違いない。しかしながら、これらの方式は、一方向性リンク上での圧縮を達成できるように、損失が大きくかつ往復時間が長い他の将来のリンク技術にも適用可能にする必要がある。IETF ROHCは、ACEとROCCOにより研究されたすべての技法を用いており、かつこれらを結合している。詳細は、IETF ROHCワーキング・グループのURL：http://www.ietf.org/html.charters/rohc-charter.htmlに見出すことができる。
【００４４】
ROHCは、無線チャネル上のRTP/UDP/IPストリームに適用可能な、堅固なヘッダ圧縮のための拡張可能なフレームワークを提供する。TCP/IPヘッダと他の種類のプロトコル（例えば、Mobile IPv6）の圧縮に対する支援も追加されており、かつ現在までに以下の4つのプロファイルがROHC RFCにより定義されている。
0  圧縮されていないIPパケット
1  RTP/UDP/IP
2  UDP/IP
3  ESP/IP
【００４５】
本発明は、プロファイル1に焦点を当てる。
【００４６】
ROHCによるコンプレッサとデコンプレッサは、リアルタイム・フローの動的フィールドが正確に処理され、かつこれに応じてヘッダが再構築される一方、静的ヘッダ・フィールド（つまり、所定のコンテキスト内で不変のままとなるフィールド）が全く伝送されないように、コンテキスト情報を維持する必要がある。具体的には図6aを参照すると、圧縮と解凍のチェーンの線図を見ることができる。
【００４７】
RTP/UDP/IPフローの場合における動的フィールドのリストを以下に示す。
‐IP識別（16ビット）                IP-ID
‐UDPチェックサム（16ビット）
‐RTPマーカ（1ビット）              M-ビット
‐RTPシーケンス番号（16ビット）    SN
‐RTPタイムスタンプ（32ビット）    TS
【００４８】
他のすべてのヘッダ・フィールドは、静的フィールドまたは推定フィールドの何れかである。
【００４９】
最初、コンプレッサは、「初期化とリフレッシュ状態」（IR）にある。ここでは、ヘッダは、デコンプレッサがIPフローに対してコンテキストを作り出すことができるように、圧縮されずに送信される。「第一オーダ」（FO）状態では、コンテキストを改悪させる可能性があるストリーム内の異常を補償するために、コンプレッサは静的フィールドの更新しかデコンプレッサに送信しない。したがって、この状態では、コンプレッサは、コンテキストの更新しか送信しない。「第二オーダ」（SO）状態では、コンプレッサは、デコンプレッサが有効なコンテキストを既に受信していることを確信しているので、圧縮されたヘッダを送信する。具体的には図6bを参照されたい。
【００５０】
デコンプレッサは、「コンテキストがない (No-Context)」（NC）状態から開始する。デコンプレッサはヘッダの解凍に成功すると直ちに、通常の動作状態である「完全なコンテキスト (Full Context)」（FC）状態へ行く。デコンプレッサは、ヘッダを繰り返し解凍して初めて、「静的コンテキスト (Static Context)」（SC）状態へ行き、ここで、コンテキストが更新されたパケットがFO状態でコンプレッサにより送信されるのを待機する。有効なコンテキストを回復することができない場合、デコンプレッサは、NC状態に戻る。具体的には図6cを参照されたい。
【００５１】
各状態間のトランジションは、動作モードにより管理される。これらの動作モードの内、ROHCは、「一方向モード (unidirectional)」（Uモード）、「双方向オプティミスティック・モード (bi-directional optimistic)」（Oモード）、および「双方向信頼モード (bi-directional reliable)」（Rモード）を定義する。Uモードの場合、デコンプレッサからコンプレッサへのフィードバック・チャネルは存在しない（または使用できない）ので、コンプレッサの各状態間のトランジションは、入来するパケットのヘッダ内の周期的なタイムアウトと異常にしか基づかない。この場合、コンテキストを周期的にリフレッシュする必要がある。Oモードの場合、フィードバック・チャネルは、エラー回復要求と、（オプションの）コンテキスト更新の受信通知とに用いられる。この動作モードの目的は、フィードバック・チャネルの使用を最小限に抑えることである。最後に、Rモードは、損失の伝搬とダメージの伝搬に対する堅固性を最大限にするために、フィードバック・チャネルを集中的に用いる。
【００５２】
W-LSBコード化：
圧縮すべきヘッダ・フィールドの値が「v」として与えられた場合、適切な参照値（v_ref）がコンプレッサとデコンプレッサとで維持されていれば、W-LSBアルゴリズムは、その最下位ビットしか伝送しない。「v_ref」値間のミスマッチをなくすために、可変スライディング・ウィンドウVSW内の「v_ref」を選択する適切な堅固なアルゴリズムが定義される。圧縮される値「v」に対して伝送すべき最下位ビットの数「k」は、以下の説明のように選択される。
2005509381.tif 000003
【００５３】
(1)式を、vがその中で変化することが予測される区間とする。オフセット・パラメータpは、圧縮すべき特定フィールドのふるまいに応じて選択可能である。
【００５４】
次に、コンプレッサでは、
2005509381.tif 000004
となるように値kを選択することができる。
【００５５】
したがって、kは、vが区間f(v_ref, k)内に入るような最小値ということになる。
【００５６】
しかしながら、この方式は、エラーに対しては堅固でないかも知れない。なぜならば、コンプレッサは、デコンプレッサが同じ参照値（これは伝送エラーのため、実際には異なる場合がある）を用いていることを知らないからである。これに代えて、可変スライディング・ウィンドウが導入される。
2005509381.tif 000005
(3)式は、伝送済みの最後のw番目の値を含んでいる。新たな値がコンプレッサに入力する度に、この値はVSWに付加される。コンプレッサは、VSW内の古い値の幾つかが正確に受信済みであることを十分に確信すると、これらの値はVSWから除去される。
2005509381.tif 000006
【００５７】
(4)式では、VSWの最小値と最大値が定義される。LSBコード化方式の場合、kは以下の式に従って選択される。
【００５８】
2005509381.tif 000007
式中のg()は、(2)で定義済みである。
【００５９】
このように、伝送されたm個のビットをデコード化するために十分な参照区間をデコンプレッサが有していることは確実でないので、より多数のビットを用いてフィールドをコード化する。実際には、デコンプレッサでのデコード化技法は、以下のアルゴリズムに基づいている。
2005509381.tif 000008
【００６０】
式(6)を、解釈のための区間として定義する（最後に正確に解凍された値v_ref_dと、受信されたビット数mとが与えられている）。解凍されたフィールドを導出するには、単に、上記の解釈のための区間内の値であって、そのm個の最下位ビットが、受信されたm個のビットにマッチングする値を選択すればよい。
【００６１】
可変スライディング・ウィンドウのサイズwは、コンプレッサが、デコンプレッサの状態に対して有する確かさに依存する。このデコンプレッサ状態は、選択されたROHCモードに依存する。UモードとOモードの場合、wは実施例に依存する。ROHCによる圧縮されたパケットの構文（後で定義する）は、wの許容寸法を設定する。事実、各パケット・タイプには、コード化されたヘッダ・フィールドに対して確保されている特定ビット数があるので、これによりウィンドウ寸法が自ずと定まる。例えば、RTP-SNは、UO-0パケット内に4つのビットを確保している。これは、ウィンドウ長が16に設定される（すなわち、最多で15個のパケットを失うことができる）ことを意味する。Rモードの場合、デコンプレッサからの明確なフィードバックを用いて、スライディング・ウィンドウの寸法を最小化することにより、圧縮比を最大化することができる。
【００６２】
W-LSBアルゴリズムは、単純な実施例でさらに説明可能である。コンプレッサが、151、152、153、154、および155という値を送信し、かつ無線リンク上の伝送エラーにより、最後の3つの値が受信されなかったと仮定する。このとき、コンプレッサでは、
VSW = [151,152,153,154,155], vmin=151、およびvmax=155
となる。
【００６３】
次に、156という値がコンプレッサに入力される。伝送すべき最下位ビット数kは、式(5)により与えられ、この式からk = max (3,1) = 3が得られる。したがって、値156 =「10011100」の最後の3つのLSB（「100」）が伝送される。
【００６４】
デコンプレッサでは、153、154、および155という値が失われているので、最後の良好な基準値は152となる。式(6)によると、デコンプレッサは、解釈のための区間Id = [152、159]を有する。これを、以下に展開する。
【００６５】
2005509381.tif 000009
【００６６】
この区間内で「100」というパターンにその3つのLSBがマッチングするのは、156のみであることを認めることができる。未検出の伝送エラーによって誤った解凍値が生じ、この値が後で基準値として用いられてダメージが伝搬しないように、元のヘッダ（例えば、モードに応じた8つのビット）にCRCを少し適用することにより、解凍の正確さをチェックすることができる。ダメージを受けた値の検出にCRCが失敗しても、ROHCフレームワーク内で補償される。
【００６７】
他のコード化方式は、以下の通りである。
【００６８】
ROHCフレームワーク内で利用可能なアルゴリズムは、W-LSBコード化アルゴリズムのみではない。例えば、通常、時間とともに規則的なステップで（TS_STRIDEの値の倍数だけ）増加するRTPタイムスタンプなどの、ヘッダ・フィールドの特定の特徴を幾つか利用した他の方式が存在する。この特徴は、「スケール化されたRTPタイムスタンプ」のコード化により活用されている。
【００６９】
一定率で生成されるトラフィック、固定サンプリング周波数、およびこのサンプリング周波数にパケット生成が確定されるとき、に対する一日の時刻の線形関数を用いて、RTPタイムスタンプを近似化することもできる。この場合、「タイマに基づいてRTPタイムスタンプを圧縮すること」が適用される。IP-IDとRTPシーケンス番号との間のオフセットのみを考慮し（RTPシーケンス番号は、新たなパケットごとに1だけ増加する）、かつこのようなオフセットに、W-LSBによるコード化を適用することにより、IP識別フィールド（IP-ID）はコード化される。
【００７０】
ROHC RTPプロファイルは、以下の通りである。
【００７１】
圧縮されるべきRTP/UDP/IPストリームの一定のヘッダ・フィールドは、順序リストとして構成可能である。ROHCフレームワークは、デコンプレッサ内の（コンテキストを形成する）リスト項目をコンプレッサが柔軟に挿入、除去、または変更できるように、これらのリストを扱うための手段となる。
【００７２】
RTPヘッダの動的フィールドは、表1に従ってコード化される。
2005509381.tif 000010
表1−RTPヘッダの動的フィールドのコード化
【００７３】
IP-IDは、通常、シーケンス番号と同じデルタだけ増加し、かつタイムスタンプは、これと同じデルタの固定値倍だけ増加するので、多くの場合、RTP TSフィールドとIP-IDフィールドはRTP SNから導出可能である。したがって、これらの条件が該当する場合、圧縮ヘッダ内にはRTP SNしか含まれず、かつ他のフィールドを導出する関数が、コンテキストに含まれる。
【００７４】
ROHCパケットは、以下のフォーマットを有する。
2005509381.tif 000011
表2‐ROHCパケット
【００７５】
表2の各パケット要素は、ペイロード以外は、一意のビット・パターンから開始する。
【００７６】
ヘッダは、コンテキストID（CID）情報を運ぶ。これらのヘッダは、1〜15の小さなCIDの場合、（「1110」というパターンから開始する）1バイトの「追加のCID」をオクテット単位で含むか、またはCID空間が大きな場合（最大で2バイト）、埋め込まれたCID情報を運ぶことができる。ROHCコンテキスト識別子は、R-CIDと称される。CID = 0が伝送されない場合、パケットはパケットのタイプから始まる。これは、「1110」とは異なる一意のビット・パターンであり、かつCIDが空であることが推定される。
【００７７】
フィードバック情報は、どのROHCパケットにもピギーバックすることができ、かつコンテキストの更新およびヘッダ圧縮に対する否定的な受信通知と肯定的な受信通知を運ぶ。デコンプレッサはフィードバック・パケットを用いて、（例えば、UモードからOモードへの）モード間のトランジションを要求することもできる。
【００７８】
パケット・タイプ：
幾つかのパケット・タイプの定義が、これらのタイプの機能、使用されるモード、およびどのフィールドが運ばれるのかに応じて、ROHCにより行われる。ROHCパケットの表記法は、以下の通りである。
<モード>-<タイプ> <オプションのフィールド>
例えば、UOR-2のパケットは、U-モード、Oモード、またはR-モードで使用可能であり、かつタイプ2である。
【００７９】
以下に示すように、RTPプロファイル内では、3つのパケット・タイプを用いて圧縮ヘッダを識別し、かつ2つのパケット・タイプを用いて初期化とリフレッシュが行われる。
0.  （R-0, R-0-CRC, UO-0）これは、他のフィールドを導出するすべての関数がデコンプレッサに知られているので、W-LSBでコード化されたRTP-SNしか伝送されない、最小のパケット・タイプである。
1.  （R-1, R-1-ID, R-1-TS, UO-1, UO-1-ID, UO-1-TS）このパケットは、RTP-SNをコード化するために必要なビット数が、パケット・タイプ0で利用可能なビット数を超えた場合、またはRTP TSとIP-IDをIP-ID SNから導出する関数が変化した場合、用いられる。
2.  （UOR-2, UOR-2-ID, UOR-2-TS）いかなるSN関数のパラメータを変更するためにも用いられる。
3.  IR：  このパケットは、コンテキストの静的部分、すなわち一定のSN関数を通信するために用いられる。
4.  IR-DYN：このパケット・タイプは、コンテキストの動的部分、すなわち一定ではないSN関数を通信するために用いられる。
【００８０】
これらのパケット・タイプの各々に一意のプリフィックスを形成するビット・パターンを、表3に示す。
2005509381.tif 000012
表3‐パケットのプリフィックス
【００８１】
デコンプレッサは、パケットを受信すると、直ちに最初のバイトを解析し、かつこの結果、その状態マシンを駆動させる。
【００８２】
IRパケット：
初期化とリフレッシュ（IR）用のパケットにより、デコンプレッサは、RTP/UDP/IPフローのためのコンテキストを作り出すことができる。その構造を、以下の表4に示す。
2005509381.tif 000013
表4‐IRパケットのフォーマット
【００８３】
オクテット単位のAdd-CIDにより、パケットの残り部分内で運ばれる静的ヘッダ情報に、コンテキスト識別子を関連付けることができる。Dビットは、プロファイルが特化されており、かつRTPプロファイルの場合、静的チェーンの直後に動的なサブヘッダ情報が存在することを示す。CID情報フィールドは、大きなコンテキスト識別子を用いる必要がある場合しか存在しない。プロファイル・フィールドは、ROHCプロファイルのための識別子である。この後、8ビットのCRCが続くが、これに関しては、C. Borman外の「堅固なヘッダ圧縮 (ROHC)：フレームワーク、および4つのプロファイル（RTPプロファイル、UDPプロファイル、ESPプロファイル、および未圧縮プロファイル）」を参照されたい。これは、「インターネット技術特別調査委員会」（IETF）のウェブサイトから参照番号「RFC3095」で見出すことができる。各値がそのフィールド上で計算される生成多項式に関しては、第5.9.1項を参照されたい。
【００８４】
静的チェーンには、静的ヘッダ・フィールドの順序リストが含まれている。例えば、IPv4ヘッダは、バージョン、プロトコル、ソース・アドレス、および終点アドレスを含む静的部分により初期化する必要がある。IPv4ヘッダの動的部分は、サービス・タイプ、存続時間、識別、DF、RND、NBO、拡張ヘッダ・リストを含んでいる。
【００８５】
IR-DYNパケット：
このタイプのパケットを用いて、コンテキストの動的部分が更新され、かつそのフォーマットは、以下の表5に示されている。この場合、動的チェーンしか運ばれない。
2005509381.tif 000014
表5‐IR-DYNのパケット・フォーマット
【００８６】
一般的なパケット・フォーマット
圧縮パケット・フォーマットを表6に示す。この構造は、多くの条件（Cx）に依存するので、その処理が明確でない場合があることを認めることができる。
2005509381.tif 000015
表6−一般的な圧縮パケット・フォーマット
【００８７】
各条件は、直前にデコード化されたフラグ・フィールドの値に依存する。オプションで、さらなるROHC情報を運ぶヘッダ拡張部が存在してもよい（4つの異なる拡張部のタイプが定義されている）。このフィールドがランダムに変化することをコンテキストが示している場合、IP-IDフィールドが存在してもよい。
【００８８】
AHデータは、セキュリティ関連の値を含んでいる認証ヘッダを参照する。GREチェックサムは、GREトンネルを参照する（RFC2784、RFC2890）。UDPチェックサムは、コンテキスト内に明確に示された場合しか存在しない。
【００８９】
Bluetoothのための堅固なヘッダ圧縮：
本発明は、
a) Bluetooth通信システムに対する堅固なヘッダ圧縮(ROHC)の適用、および、
b) ROHCのBNEPへの拡張、
という2つの主な論点に焦点を当てる。
【００９０】
本発明は、VoIPフレーム、ビデオ・ストリーム／オーディオ・ストリーム、またはこれらの同等物を圧縮して、単一スロットのBluetoothベースバンド・パケットに適合させる、新たなプロトコルを提供している。なお、このプロトコルは、本願明細書では便宜上「ROHC-BNEP」と称されている。
【００９１】
本発明は、音声アプリケーションのみに限定されるのではなく、Bluetoothピコネット内でのリアルタイムIPサービスの転移を含む、オーディオ／ビデオのストリーム用アプリケーションなどの、他のIPトラフィックにも適用可能である。本発明によると、ROHCコンプレッサとデコンプレッサのコンテキストに、BNEP情報が加えられる。こうすることにより、IPパケットだけでなく、レイヤ2のフレームも圧縮される。
【００９２】
図2を具体的に参照すると、本発明の一実施例による、移動ハンドセットMT1-n用のプロトコル・スタックを見ることができる。音声エンコーダが生じる各パケットに対して12バイトのRTPヘッダを加えることにより、時間同期が可能になる。8バイトのUDPヘッダが加えられることによって、アプリケーション・フローを１つに多重化することが可能となり、かつヘッダ・チェックサムが加えられる。このUDPデータグラムは、IPパケットにカプセル化される。このIPパケットは、用いられるIPのバージョンが4か、または6かに応じて、20バイトまたは40バイトのヘッダを有する。IPパケットをBluetoothフレームにカプセル化するために用いられるBNEPヘッダは、3〜15バイトに及ぶ。RTP/UDP/IPフローを運ぶBNEPフレームに堅固なヘッダ圧縮 (ROHC)が適用されていることを、理解することができる。
【００９３】
この圧縮されたフレームを、27バイトのペイロードを有する単一スロットのDH1ベースバンド・パケット内で運ぶためには、かつ4バイトのL2CAPヘッダ・オーバヘッドを考慮すると、RTP/UDP/IP/BNEPヘッダをROHCコンプレッサによって3バイトに縮小しなければならない。この目標は、BTシステムとROHCコンプレッサが以下に説明するように適切に構成されている場合、到達することができる。
【００９４】
提案されている解決案は、以下の幾つかのステップを含んでいる。
‐標準的なBluetoothサービス発見プロトコルを用いて、ROHC圧縮能力をアドバタイズするステップ。
‐圧縮されたビット・ストリームを運ぶようにL2CAPチャネルを構成するステップ。
‐ROHCコンテキストにBNEP静的ヘッダ・フィールドを加えるステップ（すべてのBNEPヘッダ・フィールドは、単一のVoIPセッション内では静的である）。
‐Bluetoothベースバンド再伝送方式に、ROHCフレームワークを適合化するステップ。
‐VoIPパケットを運ぶフレームのみが、提案されているROHC-BNEPアルゴリズムを用いて圧縮されるように、BNEPフレームを分類するステップ。
【００９５】
上記では、一般的なROHCフレームワークを参照してきた。次項では、Bluetoothの事例に対するROHCフレームワークの適用を、用いるべきパケット・タイプ、これらのパケット・タイプの選択方法、およびコンプレッサの各状態間でのトランジションの管理方法を含めて、詳述する。ROHC-BNEPは、以下のツールを使用する。
‐RTPプロファイルが用いられる。
‐ROHC双方向オプティミスティック・モードが、用いられるアプローチである。ただし、解凍が成功しなかった場合はNACKSしかフィードバックされないので、できる限りNACKSの使用を最小限に抑えることを試みる。
‐小さなR-CIDのみ用いられる。大きなCID空間は必要でなく、空のR-CIDは、伝送する必要がないので、デフォルトで用いられる。
‐UDPチェックサムは伝送されない(ペイロードが暗号化されていない場合のみ、デコンプレッサでUDPチェックサムを再計算することが、オプションで可能である）。
‐BNEPヘッダ全体は、同じVoIPフローに対して変化することは決してないので、静的コンテキストの一部として考慮しなければならない。
‐RTP TSを導出する機能が知られているので、RTPシーケンス番号および／またはIP-IDしか伝送されない(サイレンス・サプレションを補償するためにタイマに基づいたコード化が適用される)。
‐デコンプレッサからコンプレッサに対するコンテキストの更新要求しか運ばないように、フィードバック・チャネルの使用は最小限に抑えられる。
‐トランジションは、コンプレッサの場合は、「初期化とリフレッシュ」（IR）状態、「第一オーダ」（FO）状態、および「第二オーダ」（SO）状態間のものが定義され、かつデコンプレッサの場合は、「コンテキストがない」（NC）状態、「静的コンテキスト」（SC）状態、および「コンテキストが完全」（FC）状態間のものが定義される。
【００９６】
図7の状態マシンにより、Bluetooth上でのROHCがさらに明示されている。各コンプレッサ状態に対して、どの情報が伝送されているか（上部）、どのパケットが用いられているか（底部）、かつヘッダ情報に何バイト送られているか（括弧の間）が示されている。各状態間のトランジションも示されている。以下、各状態間のトランジションに関して説明する。
【００９７】
最初、コンプレッサはIR状態にあり、かつコンテキストの静的かつ動的な部分はすべて、デコンプレッサに伝送されなければならない。IRからFOへのトランジションは、観察時間t lp(t)に失われたパケット数が、観察時間t-1 lp(t-1)に失われたパケット数よりも少ない場合のみ、行うことができる。これらの観察時間は、設定可能な時間閾値内にデコンプレッサへ旨く送出できなかったVoIPフレーム数をコンプレッサが登録する、時間の定点である。lp(t)は、区間（t-1, t）の間に、Bluetoothスタック内のL2CAPレイヤでL2CAPタイムアウト・イベントが受信される度に、1だけ増加する。入来するVoIPストリームが（例えば、音声コーダ内のサイレンス・サプレションなどの）異常を示していないことを、コンプレッサが登録した場合のみ、FOからSOへのトランジションは発生できる。コンプレッサは一旦SO状態になると、IPストリームが異常を示した場合、FOに戻る。コンプレッサはFO状態では、NAKパケットがフィードバック・チャネルを介して受信されて、静的コンテキストが壊されていることが示された場合、IR状態に戻る。
【００９８】
Bluetooth上でのROHC RTPのマッピング：
次項で説明するROHC-BNEPアルゴリズムは、ROHC双方向オプティミスティック・アプローチに該当する。このアプローチは、上記に参照した、C. Borman外の「堅固なヘッダ圧縮（ROHC）：フレームワークおよび4つのプロファイル：RTPプロファイル, UDPプロファイル, ESPプロファイル、および非圧縮プロファイル(Robust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP and uncompressed)」に詳述されている。
【００９９】
デコンプレッサからコンプレッサへのコンテキスト更新要求しか運ばないように、フィードバック・チャネルの使用は最小限に抑えられている。ROHC RTPプロファイルで用いられるパケット・タイプは、C. Borman外の論文の第5.2.7項に見出すことができる。デコンプレッサは、一方向モードから始まり、かつフィードバック・パケットをコンプレッサに送信し返して、コンテキスト情報を得た後の、オプティミスティック・モードへのトランジションを望んでいることを示す。コンプレッサは、このような要求を受信すると直ちに、IR更新を周期的に送信することを停止してOモードへ行くことにより、バンド幅を節約する。
【０１００】
Bluetoothシステム内におけるROHC-BNEP RTP/UDP/IPヘッダの圧縮アルゴリズムの効果を評価するためには、幾つかの点を考察しなければならない。第一に、Bluetoothロジカル・リンク制御と適合レイヤ（L2CAP）を考察し、次に、ベースバンド・エラーを扱うメカニズムを再度考察する。
【０１０１】
リンク・レイヤのフレーミング：
L2CAPレイヤは、ロジカル・チャネル、およびセグメント化とリアセンブリ（SAR）機能を、Bluetoothスタックに提供する。ロジカル・チャネルは、チャネルID（CID）により識別され、かつ、既存のベースバンド接続を利用した、ピア・エンティティ間における専用のL2CAPによるシグナリング・メッセージにより、セットアップされる。この同じベースバンド接続上の2つのBTデバイス間に、幾つかのロジカル・チャネルを確立することができる。各ロジカル・チャネルに対して、リンク・レイヤのMTU値（Maximum Transmission Unit）が定義され、これにより、L2CAPの最大フレーム・サイズが制限される。L2CAP SAR機能とは、L2CAPフレームが、複数のベースバンド・パケットに分割されて、これらのパケットがシーケンス伝送される機能である。
【０１０２】
ベースバンド・レイヤによりL2CAP接続間を区別することはできないので、異なるL2CAPフレームに属するベースバンド・パケットをインターリーブすることはできない。換言すれば、L2CAPフレームの第一パケットが一旦伝送されてしまうと、同じロジカル接続の残りの全パケットがこれに追従しなければならない。
【０１０３】
この特徴は、2つのアプリケーションが同じロジカル・チャネルを使用している場合（または、2つの異なるロジカル・チャネルを使用している場合でも）、優先度が低いより長いフレームが、優先度が高いより短いフレームの伝送を遅延させてしまう可能性があることを意味する。
【０１０４】
したがって、L2CAP MTUパラメータを適切に使用して、これらのブロッキング効果をなくすことが推奨される。一例として、VoIPアプリケーション、および一つ以上のTCP/IP接続を有するBTクライアントについて考察する。これらの2つのアプリケーションは、異なる特徴を有する。つまり、第一のアプリケーションは遅延による影響を受け易く、かつパケットが短く、一方、第二のアプリケーションは、遅延による制約を受けないが、パケットを最長1500バイトにすることができる。リアルタイムのトラフィックを遅延させないためには、IPレイヤ内の断片化のオーバヘッドが大きくなってしまうとしても、小さなMTU値をTCP/IP接続にも用いなければならない。
【０１０５】
これら上記の2つのアプリケーションは、信頼性要件が異なっている。リアルタイム・トラフィックの場合、特定の閾値を超えた伝送エラーのため遅延しているパケットは、もはや有効ではなくなるのでドロップさせることができるが、TCP/IPデータ接続の場合、このことは該当しない。
【０１０６】
自動フラッシュ・タイムアウトは、設定可能な値を用いて、各L2CAPロジカル・チャネルに適用可能である。本出願者によるシミュレーションの場合、VoIPフレームを廃棄するために、12.5 msのタイムアウトを用いた。
【０１０７】
本出願者による上記の例のように、TCP/IPとRTP/UDP/IPが同じBTリンク上に同時に存在する場合、VoIPアプリケーションの品質を向上させるために、TCP/IPフレームを廃棄可能にするか否かを評価しなければならない。この選択は多くの要因に依存し、かつリアルタイム・トラフィックとデータ・トラフィックの両方に関連している（データ・トラフィックの場合、TCP/IPでの再伝送を考察しなければならないだろう）。
【０１０８】
Bluetoothシステム内でROHC-BTアルゴリズムを適用する場合、ヘッダ圧縮メカニズムのエラーに対する堅固さを増大させるためには、遅延の影響を受け易いロジカル・チャネルのL2CAPタイムアウトの数が大きな役割を果たす。事実、L2CAPタイムアウト・イベントは、フレームが失われたことを示すので、ヘッダ・コンプレッサは、この情報を使用して、例えば、適当なROHCパケット・タイプを選択することによって、ウィンドウを増やすことができる。
【０１０９】
エラーの扱い：
Bluetoothベースバンド内のARQメカニズムとは、レシーバ (receiver)が、各ベースバンド・パケットの受信通知を、次のパケットが伝送される前に、明確に行わなければならないというメカニズムのことである。データ・パケット内または受信通知メッセージ内の何れかで伝送エラーが発生した場合、パケットを再伝送しなければならない。パケット再伝送を引き起こすエラー条件には、以下のものが含まれる。
‐ベースバンドのパケット・アクセス・コードが受信されないこと。
‐ベースバンド・パケット・ヘッダ内のエラーが補正不可能なこと。
‐パケット・ペイロード内のエラーが補正不可能なこと（受信通知パケット内でこのようなエラー条件が生じた場合のみ、ACKフィールドがパケット・ヘッダ内で運ばれているので、再伝送は起動されない)。
【０１１０】
同じL2CAPフレームの部分であるベースバンド・パケットは、レシーバでアセンブルされたフレームが上位レイヤに渡される前に、すべて正確に受信されなければならない。トランスミッタ (transmitter)では、L2CAPフレームがそれに分割化されているすべてのベースバンド・パケットの肯定的な受信通知を、設定可能な時間範囲内で行って、L2CAPタイムアウト・イベントを避けなければならない。
【０１１１】
L2CAPタイムアウト・イベントが生じた場合、トランスミッタは、L2CAPレイヤ内とホスト・コントローラ内の両方に残されているすべてのベースバンド・パケットを、HCI_Flushコマンドを用いてフラッシュする（Bluetooth SIGの「中心的な仕様v1.1」(第H：1部、第4.7.4項））を参照されたい）。このコマンドは、指定されている接続ハンドルに対する保留中のすべての再伝送を再設定する。新たなフレームの始まりとしてタグが付けられた新たなHCIデータ・パケットが受信された場合のみ、通常の動作が再開される。
【０１１２】
L2CAP接続の受信側は、L2CAPチャネル構成内のFlush_Timeoutオプションを用いて、トランスミッタのL2CAPタイムアウトの通知を受ける（Bluetooth SIGの「中心的な仕様v1.1.1」(第D部、第6.2項）を参照されたい）。
【０１１３】
ポイントからマルチポイントへ：
VoIPトランスミッタが、Bluetoothスレーブ内で走っており、かつマスタに他のスレーブが接続されている場合、ポーリング・アクセス方式をある程度考慮する必要がある。
【０１１４】
第一に、スレーブはマスタに対して、VoIPパケットの生成にマッチングした率（例えば、30 ms毎）でポーリングを行うように要求する必要がある。これは、LMP_quality_of_service_requestと翻訳されるHCI_QoS_setupコマンドを用いて、適切なTpollと交渉することにより達成される。
【０１１５】
しかしながら、ポイントからマルチポイント（point-to-multipoint）の構成の場合、BluetoothベースバンドのARQ方式の再送回数が制限されていないことは、スレーブがマスタに送信したパケットの受信通知を、次にマスタがスレーブをポーリングしたときに行えることを意味する。（Bluetooth SIGの「中心的な仕様v1.1」(第B部、第5.3.1項））を参照されたい）。これは、スレーブにおけるL2CAPタイムアウトの起動を、マスタのスケジューリング方針に応じて行うことができることを意味する。
【０１１６】
構成：
図3には、初期構成プロセスが示されている。この図には、パーソナル・エリア・ネットワーク・ユーザ（PANU）とネットワーク・アクセス・ポイントNAP（AP1-n）との間のフローが示されている。ハンドセットMTは、アクセス・ポイントAP1-nへの第一接続を行うと直ちに、SDP照会を行って、アクセス・ポイントAP1-nにより支援されているサービスに関する情報を得る。アクセス・ポイントAP1-nは、PAN能力を標準BNEPプロトコルに対してアドバタイズし（PSM値が割り当てられる）、かつ、ROHC-BNEP能力を、本明細書に明記されている新たなROHC-BNEPプロトコルに対してアドバタイズする（このために、動的なPSMを用いることができる）。
【０１１７】
最初は、BNEPに特有のPSMを要求することにより、L2CAPによる信頼性が高い接続が行われる。次に、SDPの記録内に既にアドバタイズされている、ROHC-BNEPのための動的PSM値を用いることにより、第二L2CAP接続が行われる。この第二接続は、L2CAPサービス品質（QoS）セットアップ・メッセージを用いて、信頼性がないものとして構成されるであろう。これにより、VoIPパケットの再伝送回数を制限することができる。事実、ある一定時間内にパケット送出が成功しなかった場合、このパケットはレシーバにとって無用なものとなるので廃棄可能となり、これによりバンド幅が節約される。このためには、L2CAPタイムアウトをベースバンド・フラッシュ・コマンドに結合することにより、パケット再伝送を延期し、かつBTリンク・マネージャ内のすべての関連するバッファを開放する必要がある。要約すると、移動ハンドセットは、標準のIPトラフィックを運ぶための一方のロジカル・チャネルと、VoIPストリームを圧縮するための他方のロジカル・チャネルとの、2つのロジカル・チャネルを構成する必要がある。これらのL2CAPロジカル・チャネルが一旦セットアップされると、次の小項目で説明するように、移動端末とアクセス・ポイントは、これらのチャネルを一貫して用いなければならない。
【０１１８】
アクセス・ポイントAPと移動端末MTとの間に、L2CAPチャネルを1つしか確立できない場合、VoIPフローを保護するために、この「信頼性のない」チャネルも用いてデータ接続を行う必要がある。この信頼性のないロジカル・チャネル上でのデータ・パケットの損失は、高位レイヤのプロトコル（例えば、TCP/IP）により処理可能である。
【０１１９】
トランスミッタとレシーバのロジック：
トランスミッタでは、BNEPフレームをL2CAPに送出しなければならない場合は常に、図4aに表されているアルゴリズムを用いることができる。
【０１２０】
まず、BNEPフレームを圧縮しなければならないか否かを理解するために、BNEPフレームを分類化しなければならない。実際には、RTP/UDP/IPパケットを運ぶBNEPフレームのみ、提案されているROHC-BNEPアルゴリズムによって処理しなければならない。
【０１２１】
以下のBNEPヘッダ・フィールドがチェックされる。
‐BNEP終点アドレス(ピアはROHC能力を有していなければならない）
‐BNEPプロトコル・タイプ（「IP」または「IPv6」でなければならない。さらに、QoSを支援するLAN内で用いられることから、IEEE802.1pとIEEE802.1qをイーサネットのフレームタグ付け用として解釈しなければならない。）
‐IPプロトコル・タイプ（UDPでなければならない。）
‐UDPポート（H.323対応でなければならない。）
BNEPフレームを圧縮しなければならない場合、そのROHCコンテキストが検索され、かつこの結果得られる圧縮フレームが、信頼性のないチャネルに対応するL2CAP CID（L-CID）を用いて、L2CAPレイヤに送信される。このフレームを圧縮する必要がない場合、これに代えて信頼性が高いチャネルのL-CIDが用いられる。
【０１２２】
レシーバでは、図4bに示すように、ROHC-BNEP L-CIDに対応するフレームが、信頼性のないチャネルから到達した場合、ROHC-BNEPの解凍を行わなければならないと想定される。このフレームは、再構築に成功後、BNEPレイヤに送出される。
【０１２３】
圧縮されたフレームを正確に再構築できなかった場合、このフレームはデコンプレッサ内で廃棄される。N2の圧縮された連続パケットを再構築できなかった場合、信頼性のないチャネルと、ROHCフィードバック・パケット・タイプとを用いて、否定的なACKがピアROHCコンプレッサに送信し返される（ROHCアルゴリズムの説明に関しては、後の項目を参照されたい）。N2は、例えば15に設定される。
【０１２４】
図5には、ROHC-over-BNEP構成のブロック図が示されている。ROHCコーデックおよびすべての関連したロジックは、Bluetoothネットワークのインターフェース用ソフトウエアのドライバに関連付けられて走るソフトウエア製品の形態で実施可能である。このソフトウエア製品には、BNEPレイヤとL2CAPレイヤ、フレーム・クラシファイア、ROHCコーデック、および様々なブロックの調和を図るマネージメント・エンティティ (ME)が含まれている。MEは、標準HCIインターフェース（存在する場合）を介して、BTベースバンドと通信することができ、かつオペレーティング・システムに特定のメカニズムによって、上位レイヤと通信することができる。
【０１２５】
移動端末MT1-nがAP1-nに接続する度に、MEはそのMACアドレスを登録し、かつこのアドレスに対するロジカル・チャネルを構成する。Bluetoothの場合、ロジカル・チャネルは、L2CAPチャネルID（L-CID）と命名された数個のチャネル終端ポイントを特徴とする。チャネルのセットアップ後直ちに、各ピアは、それ自身のローカルL-CIDを割り当て、かつこれを遠隔デバイスに送信する。したがって、ROHCのための以下の表を構築することができる。
2005509381.tif 000016
表9‐ROHC-BNEPの例示的なAP構成
【０１２６】
表9の例の場合、AP1には、2つの移動端末MT1, 2が接続されている
MT1は、一方は通常のIPトラフィック用と他方はVoIP用という、2つのロジカル・チャネルを構成している。この第二チャネルは、空のROHCコンテキストIDを用いるであろう。MT2がアクセス・ポイントAP1に接続すると、VoIP用のチャネルを構成する。この場合にも、空のR-CIDが使用可能である。しかしながら、MT1が、第二RTP/UDP/IP/BNEPフロー用の他のチャネルを構成する場合（第4列）、異なるROHCコンテキストを用いなければならない。なぜならば、MT1は今や、別々に扱わなければならない2つのリアルタイム・ストリーム（例えば、1つの音声チャネルと1つのビデオ・チャネル）を有しているからである。
【０１２７】
本願明細書に開示されている、提案されている堅固なヘッダ圧縮技法を、移動端末とアクセス・ポイント間に適用することにより、バンド幅を節約し、かつこれにより、同じピノネット内でより多数の接続を扱うことが可能となる。
【０１２８】
本発明を、好ましい実施例を参照しながら具体的に示しかつ説明してきたが、形状と細部の変更が本発明の範囲内で可能であることは、当業者によって理解されるであろう。
【０１２９】
用語集：
2005509381.tif 000017
【図面の簡単な説明】
【０１３０】
【図１】通信システムの概要図である。
【図２】本発明の一実施例による通信ユニット用であり、かつ図1のシステム内での使用に適したプロトコル・スタックである。
【図３】図2の通信ユニットのネットワーク構成の流れ図である。
【図４ａ】本発明を実施する際に使用されるヘッダ・コンプレッサの流れ図である。
【図４ｂ】本発明を実施する際に使用されるヘッダ・デコンプレッサの流れ図である。
【図５】本発明の実施例の機能に関する線図である。
【図６ａ】ヘッダの圧縮と解凍のチェーンの概要図である。
【図６ｂ】コンプレッサの各状態のブロック図である。
【図６ｃ】デコンプレッサの各状態のブロック図である。
【図７】図4aのヘッダ・コンプレッサ用の状態マシンである。
【図１】
2005509381.tif 000018
【図２】
2005509381.tif 000019
【図３】
2005509381.tif 000020
【図４ａ】
2005509381.tif 000021
【図４ｂ】
2005509381.tif 000022
【図５】
2005509381.tif 000023
【図６ａ】
2005509381.tif 000024
【図６ｂ】
2005509381.tif 000025
【図６ｃ】
2005509381.tif 000026
【図７】
2005509381.tif 000027
【国際調査報告】
2005509381.tif 000028
2005509381.tif 000029
2005509381.tif 000030
2005509381.tif 000031