JP2005509381A6 - ヘッダ圧縮を行う無線通信装置 - Google Patents

ヘッダ圧縮を行う無線通信装置 Download PDF

Info

Publication number
JP2005509381A6
JP2005509381A6 JP2003543331A JP2003543331A JP2005509381A6 JP 2005509381 A6 JP2005509381 A6 JP 2005509381A6 JP 2003543331 A JP2003543331 A JP 2003543331A JP 2003543331 A JP2003543331 A JP 2003543331A JP 2005509381 A6 JP2005509381 A6 JP 2005509381A6
Authority
JP
Japan
Prior art keywords
packet
protocol
unit
header
header compression
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
JP2003543331A
Other languages
English (en)
Other versions
JP2005509381A (ja
Inventor
ディエゴ メルピグナノ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Priority claimed from PCT/IB2002/004459 external-priority patent/WO2003041424A2/en
Publication of JP2005509381A publication Critical patent/JP2005509381A/ja
Publication of JP2005509381A6 publication Critical patent/JP2005509381A6/ja
Abandoned legal-status Critical Current

Links

Abstract

【課題】ヘッダ圧縮を用いた、パケットに基づいた改良された無線通信装置、およびこの無線通信装置の改良された操作方法、ならびにこのような改良された通信装置と方法に関連付けて用いられる改良された通信ユニットとソフトウエア製品を提供すること。
【解決手段】第一ユニットAPと第二ユニットMT間で無線伝達を行うための方法が開示されている。この方法には、当該ユニットAP, MTが、リアルタイム・ビット・ストリーム（例えば、VoIP、オーディオ、およびビデオ）を、最大長が予め決定されている一つ以上のペイロードに変換することが含まれる。前記ペイロードまたは各当該ペイロードに、一つ以上の予め定義されているヘッダ（RTP/UDP/IP）が適用されて、当該ユニットAP, MT間での伝送を予め定義されている通信プロトコルに従って行うために適したパケットが生成される。次いで、このパケットまたは各パケットは、このパケットまたは各パケットをユニットMT, AP間の無線接続全体に転移するように適合化されているカプセル化プロトコル（BNEP）のフレームにカプセル化される。次に、予め定義されているヘッダ圧縮技法（IETF ROHC）が、前記カプセル化されたパケット、または各カプセル化されたパケットに適用される。

Description

本発明は、無線通信装置と、無線通信装置の操作方法とに関し、具体的には、パケットに基づいた無線通信装置と、ヘッダ圧縮 (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」は、以下の説明のように選択される。
(1)式を、vがその中で変化することが予測される区間とする。オフセット・パラメータpは、圧縮すべき特定フィールドのふるまいに応じて選択可能である。
次に、コンプレッサでは、
となるように値kを選択することができる。
したがって、kは、vが区間f(v_ref, k)内に入るような最小値ということになる。
しかしながら、この方式は、エラーに対しては堅固でないかも知れない。なぜならば、コンプレッサは、デコンプレッサが同じ参照値（これは伝送エラーのため、実際には異なる場合がある）を用いていることを知らないからである。これに代えて、可変スライディング・ウィンドウが導入される。
(3)式は、伝送済みの最後のw番目の値を含んでいる。新たな値がコンプレッサに入力する度に、この値はVSWに付加される。コンプレッサは、VSW内の古い値の幾つかが正確に受信済みであることを十分に確信すると、これらの値はVSWから除去される。
(4)式では、VSWの最小値と最大値が定義される。LSBコード化方式の場合、kは以下の式に従って選択される。
式中のg()は、(2)で定義済みである。
このように、伝送されたm個のビットをデコード化するために十分な参照区間をデコンプレッサが有していることは確実でないので、より多数のビットを用いてフィールドをコード化する。実際には、デコンプレッサでのデコード化技法は、以下のアルゴリズムに基づいている。
式(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]を有する。これを、以下に展開する。
この区間内で「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に従ってコード化される。
表1−RTPヘッダの動的フィールドのコード化
IP-IDは、通常、シーケンス番号と同じデルタだけ増加し、かつタイムスタンプは、これと同じデルタの固定値倍だけ増加するので、多くの場合、RTP TSフィールドとIP-IDフィールドはRTP SNから導出可能である。したがって、これらの条件が該当する場合、圧縮ヘッダ内にはRTP SNしか含まれず、かつ他のフィールドを導出する関数が、コンテキストに含まれる。
ROHCパケットは、以下のフォーマットを有する。
表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に示す。
表3‐パケットのプリフィックス
デコンプレッサは、パケットを受信すると、直ちに最初のバイトを解析し、かつこの結果、その状態マシンを駆動させる。
IRパケット：
初期化とリフレッシュ（IR）用のパケットにより、デコンプレッサは、RTP/UDP/IPフローのためのコンテキストを作り出すことができる。その構造を、以下の表4に示す。
表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に示されている。この場合、動的チェーンしか運ばれない。
表5‐IR-DYNのパケット・フォーマット
一般的なパケット・フォーマット
圧縮パケット・フォーマットを表6に示す。この構造は、多くの条件（Cx）に依存するので、その処理が明確でない場合があることを認めることができる。
表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のための以下の表を構築することができる。
表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つのビデオ・チャネル）を有しているからである。
本願明細書に開示されている、提案されている堅固なヘッダ圧縮技法を、移動端末とアクセス・ポイント間に適用することにより、バンド幅を節約し、かつこれにより、同じピノネット内でより多数の接続を扱うことが可能となる。
本発明を、好ましい実施例を参照しながら具体的に示しかつ説明してきたが、形状と細部の変更が本発明の範囲内で可能であることは、当業者によって理解されるであろう。
用語集：
通信システムの概要図である。 本発明の一実施例による通信ユニット用であり、かつ図1のシステム内での使用に適したプロトコル・スタックである。 図2の通信ユニットのネットワーク構成の流れ図である。 本発明を実施する際に使用されるヘッダ・コンプレッサの流れ図である。 本発明を実施する際に使用されるヘッダ・デコンプレッサの流れ図である。 本発明の実施例の機能に関する線図である。 ヘッダの圧縮と解凍のチェーンの概要図である。 コンプレッサの各状態のブロック図である。 デコンプレッサの各状態のブロック図である。 図4aのヘッダ・コンプレッサ用の状態マシンである。

Claims (21)

  1. 第一ユニットと第二ユニット間で、パケットに基づく無線伝送を行うための方法であって、
    当該ユニットが、
    a) リアルタイム・ビット・ストリームを、最大長が予め決定されている１つ以上のペイロードに変換することと、
    b) 予め定義されている１つ以上のヘッダを前記ペイロードまたは各当該ペイロードに適用して、予め定義されている通信プロトコルに従って当該ユニット間で伝送を行うために適したパケットを生成することと、
    c) 前記パケットまたは各当該パケットを当該ユニット間の無線接続全体に転移するように適合化されているカプセル化プロトコルのフレーム内に、前記パケットまたは各当該ペイロードをカプセル化することと、
    d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されたパケットまたは各当該カプセル化されたペイロードに適用することと、
    を含む方法。
  2. VoIPストリーム、オーディオ・ストリームまたはビジュアル・ストリームなどのインターネット・プロトコル（IP）のトラフィックを有する当該リアルタイム・ビット・ストリームから、前記ペイロード、または各当該ペイロードを生成することを含む、請求項１に記載の方法。
  3. 当該第一ユニットと当該第二ユニット間でサービス発見プロシージャを行い、かつ当該サービス発見プロシージャの間に、当該ヘッダ圧縮技法をアドバタイズすることを含む、請求項１または請求項２に記載の方法。
  4. セグメントを一つ以上構成し、リアセンブリを行い、かつ圧縮されたビット・ストリームを運ぶ当該予め定義されている通信プロトコルのサービスを多重化することを含む、前記請求項の何れかに記載の方法。
  5. 例えば当該カプセル化プロトコルの静的ヘッダ・フィールドを有するカプセル化プロトコル情報を、当該ヘッダ圧縮技法を適用するように適合化されているコンプレッサとデコンプレッサのコンテキストに加えることにより、当該ヘッダ圧縮を適用することを含む、前記請求項の何れかに記載の方法。
  6. 当該ユニットが、Bluetoothネットワーク部分を含み、かつ、
    当該方法が、Bluetoothネットワーク・カプセル化プロトコル（BNEP）を有するカプセル化プロトコルを用いて、前記パケットまたは各当該パケットをカプセル化すること、
    を含む、前記請求項の何れかに記載の方法。
  7. 好ましくは、当該予め決定されているヘッダとBNEPヘッダを組み合わせたものを予め決定されている長さ（例えば、3バイト）に縮小することにより、前記カプセル化されたパケットまたは各当該カプセル化されたパケットを、当該ヘッダ圧縮技法を用いて単一スロットのBluetoothベースバンド・パケットに圧縮することを含む、請求項6に記載の方法。
  8. 当該ヘッダ圧縮技法を、インターネット技術特別調査委員会（IETF）により承認されたROHCなどの堅固なヘッダ圧縮（ROHC）フレームワークの形態で適用することを含む、前記請求項の何れかに記載の方法。
  9. 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に記載の方法。
  10. 予め決定されている当該フレームしか当該ヘッダ圧縮技法により圧縮されないように、カプセル化フレームを分類することを含む、前記請求項の何れかに記載の方法。
  11. リアルタイム・プロトコル（RTP）、ユニバーサル・データグラム・プロトコル（UDP）、およびインターネット・プロトコル（IP）の１つ以上に従って、当該ペイロードにヘッダを適用することを含む、前記請求項の何れかに記載の方法。
  12. 当該ユニットが、当該ユニット間で通信を行うための複数のロジカル・チャネルを構成し、
    少なくとも一つの当該チャネルが、当該圧縮カプセル化されたパケットの転移を専用とすること、
    を含む、前記請求項の何れかに記載の方法。
  13. 当該ヘッダ圧縮技法を、W-LSB（Window-Least Significant Bit coding）に基づいて行なうことを含む、前記請求項の何れかに記載の方法。
  14. エラー回復要求と、オプションでコンテキスト更新の受信通知を行うように適合化された、当該ユニット間のフィードバック・チャネルを設けることにより、コンプレッサ状態とデコンプレッサ状態間のスイッチングを管理することを含む、前記請求項の何れかに記載の方法。
  15. 当該ユニットが、ベースバンド・パケットにセグメント化された一連の当該圧縮カプセル化されたフレームを受信し、
    各当該パケットの肯定的な受信通知を行ってから、次の当該パケットが伝送され、かつ、
    最新の当該パケットまたは受信通知メッセージの何れかの中で伝送エラーが発生した場合は、当該最新のパケットが再伝送されること、
    を含む、前記請求項の何れかに記載の方法。
  16. 当該パケットの再伝送を、
    a) ベースバンド・パケット・アクセス・コードが受信されない場合、
    b) 補正不可能なエラーが、ベースバンド・パケット・ヘッダ内に存在する場合、または、
    c) 補正不可能なエラーが、当該パケットの当該ペイロード内に存在する場合、
    の少なくとも1つの場合に行うことを含む、請求項15に記載の方法。
  17. 例えば、当該フレームの送出に成功するまでのタイムアウトを設定することにより、当該圧縮されたカプセル化されたフレームの再伝送の回数を制限することを含む、前記請求項の何れかに記載の方法。
  18. 第一通信ユニットと第二通信ユニット間で、パケットに基づいた無線通信を実行するためのソフトウエア製品であって、
    a) リアルタイム・ビット・ストリームを、最大長が予め決定されている１つ以上のペイロードに変換し、
    b) １つ以上の予め定義されているヘッダを前記ペイロードまたは各当該ペイロードに適用して、予め定義されている通信プロトコルに従って当該ユニット間での伝送を行うために適したパケットを生成し、
    c) 当該ユニット間の無線接続全体に前記パケットまたは各当該パケットを転移させるように適合化されているカプセル化プロトコルのフレーム内の前記パケットまたは各当該パケットをカプセル化し、かつ、
    d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されたパケットまたは各当該カプセル化されたパケットに適用する、
    ためのコードを含む、ソフトウエア製品。
  19. 実質的にリアルタイムで第二ユニットに情報を通信するように適合化されている第一ユニットを有する、パケットに基づいた無線通信装置であって、
    当該第一ユニットが、
    a) リアルタイム・ビット・ストリームを最大長が予め決定されている１つ以上のペイロードに変換し、
    b) 予め定義されている通信プロトコルに従って当該ユニット間で伝送を行うために適したパケットを生成するために、予め定義されている１つ以上のヘッダを、前記ペイロード、または当該ペイロードの各々に適用し、
    c) 前記パケット、または当該パケットの各々を、当該ユニット間の無線接続全体に転移するように適合化されているカプセル化プロトコルのフレーム内で、前記パケット、または当該パケットの各々をカプセル化し、かつ
    d) 予め定義されているヘッダ圧縮技法を、前記カプセル化されているパケット、または当該カプセル化されているパケットの各々に適用する、
    ように適合化されている、パケットに基づいた無線通信装置。
  20. 当該第一ユニットが、前記Bluetoothプロトコルに従って動作可能であり、
    当該カプセル化プロトコルが、Bluetoothネットワーク・カプセル化プロトコル（BNEP）を有することが好ましく、かつ、
    当該ヘッダ圧縮技法が、インターネット技術特別調査委員会（IETF）の堅固なヘッダ圧縮（ROHC）技法との互換性を有することが好ましい、
    請求項20に記載の無線通信装置。
  21. 請求項1〜19の何れかに記載の前記方法に従って動作するように適合化され、かつBluetooth通信ネットワークのマスタ・ユニットとスレーブ・ユニットの少なくとも一つとして少なくとも一時的に構成されることが好ましい、無線通信ユニット。
JP2003543331A 2001-11-06 2002-10-24 ヘッダ圧縮を行う無線通信装置 Abandoned JP2005509381A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP01204215.6 2001-11-06
EP01204215 2001-11-06
PCT/IB2002/004459 WO2003041424A2 (en) 2001-11-06 2002-10-24 Wireless communication arrangements with encapsulation and header compression

Publications (2)

Publication Number Publication Date
JP2005509381A JP2005509381A (ja) 2005-04-07
JP2005509381A6 true JP2005509381A6 (ja) 2005-08-04

Family

ID=8181187

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003543331A Abandoned JP2005509381A (ja) 2001-11-06 2002-10-24 ヘッダ圧縮を行う無線通信装置

Country Status (7)

Country Link
US (1) US20040264433A1 (ja)
EP (1) EP1514431A2 (ja)
JP (1) JP2005509381A (ja)
KR (1) KR20040053278A (ja)
CN (1) CN1636374A (ja)
AU (1) AU2002339605A1 (ja)
WO (1) WO2003041424A2 (ja)

Families Citing this family (95)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7136395B2 (en) * 2000-11-30 2006-11-14 Telefonaktiebolaget L M Ericsson (Publ) Method and system for transmission of headerless data packets over a wireless link
US7165112B2 (en) * 2001-06-22 2007-01-16 Motorola, Inc. Method and apparatus for transmitting data in a communication system
US7324516B2 (en) * 2002-08-14 2008-01-29 Intel Corporation Data packet header conversion
US7647421B2 (en) * 2002-08-20 2010-01-12 Nokia Corporation Extension header compression
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8270423B2 (en) 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7630305B2 (en) 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US8238241B2 (en) 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US8432800B2 (en) 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
US7822067B2 (en) * 2003-08-08 2010-10-26 Qualcomm Incorporated Header compression enhancement for broadcast/multicast services
US7372843B1 (en) * 2003-09-23 2008-05-13 Cisco Technology, Inc. System and method for compressing information flows in a network environment
US7269388B2 (en) * 2003-12-01 2007-09-11 Microsoft Corporation Bluetooth pan driver
JP4143547B2 (ja) * 2004-01-21 2008-09-03 Ｎｅｃアクセステクニカ株式会社 データ通信システム
US7957389B2 (en) * 2004-03-31 2011-06-07 Alcatel-Lucent Usa Inc. Method of stall identification and recovery
EP1603339A1 (en) * 2004-06-01 2005-12-07 STMicroelectronics S.r.l. Method and system for communicating video data in a packet-switched network, related network and computer program product therefor
US8031644B2 (en) 2004-06-23 2011-10-04 Nokia Corporation Non-native media codec in CDMA system
US8254379B1 (en) * 2004-07-15 2012-08-28 Sprint Spectrum L.P. Method and system for application based compression profile selection
KR100703494B1 (ko) * 2004-08-09 2007-04-03 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을 포함하는 음성패킷망의 패킷 송/수신 방법 및 장치
US20060039353A1 (en) * 2004-08-23 2006-02-23 Samuel Louis G Extended voice over internet protocol
US7675895B2 (en) * 2004-09-14 2010-03-09 Alcatel-Lucent Usa Inc. Method and apparatus for wireless communication using voice over internet protocol
US8966551B2 (en) 2007-11-01 2015-02-24 Cisco Technology, Inc. Locating points of interest using references to media frames within a packet flow
US9197857B2 (en) 2004-09-24 2015-11-24 Cisco Technology, Inc. IP-based stream splicing with content-specific splice points
US8165104B2 (en) 2004-12-08 2012-04-24 Qualcomm Incorporated Methods and systems for enhancing local repair in robust header compression
US7633879B2 (en) * 2004-12-13 2009-12-15 Cisco Technology, Inc. Method and apparatus for discovering the incoming media path for an internet protocol media session
US7656853B2 (en) * 2004-12-27 2010-02-02 Microsoft Corporation Reducing power consumption of a wireless device
US20060205449A1 (en) * 2005-03-08 2006-09-14 Broadcom Corporation Mechanism for improved interoperability when content protection is used with an audio stream
US8009699B2 (en) * 2005-07-12 2011-08-30 Qualcomm Incorporated Efficient encoding of out of order data packets in a network
US9031071B2 (en) 2005-08-26 2015-05-12 Alcatel Lucent Header elimination for real time internet applications
CN101258724A (zh) * 2005-09-06 2008-09-03 英国电讯有限公司 通信接口
WO2007031090A1 (en) * 2005-09-15 2007-03-22 Aalborg Universitet A method of compressing the header of a data packet
KR100800878B1 (ko) 2005-09-23 2008-02-04 삼성전자주식회사 이동통신 시스템에서 사용자 데이터 프로토콜 체크섬을포함하는 음성패킷의 송수신 방법 및 장치
EP1773004A1 (en) * 2005-10-10 2007-04-11 Nec Technologies (UK) Limited Header compression optimisation method during and after handovers in a cellular communication network
US20070086434A1 (en) * 2005-10-19 2007-04-19 Muthaiah Venkatachalam Efficient mechanisms for supporting VoIp in a wireless network
US8325600B2 (en) 2005-12-30 2012-12-04 Intel Corporation Segmentation interleaving for data transmission requests
US7907609B2 (en) * 2006-01-06 2011-03-15 Qualcomm, Incorporated Method and apparatus for enhancing RoHC performance when encountering silence suppression
WO2007091207A1 (en) * 2006-02-07 2007-08-16 Nokia Corporation Providing and handling information on a state of a media stream
JP2007258817A (ja) * 2006-03-20 2007-10-04 Fujitsu Ltd パケット伝送装置
US7936694B2 (en) * 2006-04-03 2011-05-03 Hewlett-Packard Development Company, L.P. Sniffing-based network monitoring
US8750334B2 (en) 2006-10-02 2014-06-10 Motorola Mobility Llc Link layer assisted robust header compression context update management
JP2008141254A (ja) * 2006-11-29 2008-06-19 Kyocera Corp 通信方法及び送信装置並びに受信装置
US7899025B2 (en) * 2006-12-26 2011-03-01 Alcatel-Lucent Usa Inc. Header suppression in a wireless communication network
US8027328B2 (en) * 2006-12-26 2011-09-27 Alcatel Lucent Header compression in a wireless communication network
US7813296B2 (en) * 2006-12-27 2010-10-12 Telefonaktiebolaget L M Ericsson (Publ) Adapting transmission and reception time in packet based cellular systems
DE102007018832B3 (de) 2007-04-20 2008-08-28 Siemens Ag Österreich Verfahren und Einrichtung zur Reduktion der Datenmenge in einem paketorientiertem Datennetz
US20080267168A1 (en) * 2007-04-27 2008-10-30 Zhijun Cai Slow Adaptation of Modulation and Coding for Packet Transmission
US8064390B2 (en) * 2007-04-27 2011-11-22 Research In Motion Limited Uplink scheduling and resource allocation with fast indication
US7936695B2 (en) 2007-05-14 2011-05-03 Cisco Technology, Inc. Tunneling reports for real-time internet protocol media streams
US8023419B2 (en) 2007-05-14 2011-09-20 Cisco Technology, Inc. Remote monitoring of real-time internet protocol media streams
EP2538614B1 (en) 2007-06-15 2014-06-11 BlackBerry Limited System and method for semi-persistent and dynamic scheduling and discontinuous reception control
EP2163056A4 (en) * 2007-06-15 2011-12-14 Research In Motion Ltd SYSTEM AND METHOD FOR DELIVERING LARGE PACKAGES DURING A SEMIPERSISTENT MEETING
CN101682857B (zh) * 2007-06-15 2013-10-30 捷讯研究有限公司 用于减小链路适配开销的系统和方法
US7835406B2 (en) 2007-06-18 2010-11-16 Cisco Technology, Inc. Surrogate stream for monitoring realtime media
US20090003347A1 (en) * 2007-06-29 2009-01-01 Yang Tomas S Backhaul transmission efficiency
US7817546B2 (en) 2007-07-06 2010-10-19 Cisco Technology, Inc. Quasi RTP metrics for non-RTP media flows
KR101377961B1 (ko) * 2007-07-27 2014-03-25 엘지전자 주식회사 헤더 오버헤드 감소를 위한 패킷 전송 방법
US20090034529A1 (en) * 2007-07-30 2009-02-05 Motorola, Inc. Method and apparatus for routing packets via header-compression channels
CN101364980B (zh) 2007-08-10 2012-06-20 华为技术有限公司 建立头压缩通信的方法及系统、头压缩策略功能实体
US20090046639A1 (en) * 2007-08-14 2009-02-19 Zhijun Cai System and Method for Handling Large IP Packets During VoIP Session
ES2907561T3 (es) 2007-08-20 2022-04-25 Blackberry Ltd Sistema y método para control de DRX y NACK/ACK
ES2378267T3 (es) 2007-09-14 2012-04-10 Research In Motion Limited Sistema y método para el tiempo de inicio de control de recepción discontinua
TWI395976B (zh) * 2008-06-13 2013-05-11 Teco Image Sys Co Ltd 掃描模組之光源投射裝置及其光源排列方法
US8031607B2 (en) * 2009-01-29 2011-10-04 Alcatel Lucent Implementation of internet protocol header compression with traffic management quality of service
US8254837B2 (en) * 2009-04-23 2012-08-28 Motorola Mobility Llc Establishing full-duplex audio over an asynchronous bluetooth link
US20110016313A1 (en) * 2009-07-15 2011-01-20 Qualcomm Incorporated HEADER COMPRESSION FOR TUNNELED IPsec PACKET
JP5278222B2 (ja) * 2009-07-22 2013-09-04 富士通株式会社 無線通信装置、無線通信方法および無線通信プログラム
US8886790B2 (en) * 2009-08-19 2014-11-11 Opanga Networks, Inc. Systems and methods for optimizing channel resources by coordinating data transfers based on data type and traffic
KR101655267B1 (ko) * 2009-09-07 2016-09-08 삼성전자주식회사 무선통신시스템에서 로버스트 헤더 압축을 지원하기 위한 시스템 및 방법
US8301982B2 (en) 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows
CN102215513B (zh) * 2010-04-02 2013-10-30 联芯科技有限公司 一种IPv4包头变化规律的检测方法和系统
CN101867572B (zh) * 2010-05-11 2015-08-12 中兴通讯股份有限公司 无线优盘的实现方法及系统
US8819714B2 (en) 2010-05-19 2014-08-26 Cisco Technology, Inc. Ratings and quality measurements for digital broadcast viewers
JP5734680B2 (ja) * 2011-01-26 2015-06-17 京セラ株式会社 移動通信方法及び基地局
RU2469244C1 (ru) * 2011-06-08 2012-12-10 Валерий Игнатьевич Гуров Водонагревательное устройство
CN102869044A (zh) * 2011-07-08 2013-01-09 联芯科技有限公司 分组域通信中标签形成方法、分组域通信方法及终端
US9331920B2 (en) * 2012-01-25 2016-05-03 Cisco Technology, Inc. Media path monitoring over a secure network
TWI524688B (zh) * 2012-07-13 2016-03-01 瑞昱半導體股份有限公司 藍牙服務估測裝置及其藍牙服務估測方法
US9973596B2 (en) * 2013-06-19 2018-05-15 Cisco Technology, Inc. Dynamically adjusting frame MTU to support low-latency communication
US9398253B2 (en) * 2013-07-26 2016-07-19 Qualcomm Incorporated Video pause indication in video telephony
JP6055389B2 (ja) * 2013-10-08 2016-12-27 株式会社Ｎｔｔドコモ 無線基地局
KR102192165B1 (ko) * 2013-11-25 2020-12-16 삼성전자주식회사 전자 장치에서 헤더 압축된 패킷을 처리하기 위한 장치 및 방법
WO2016144031A1 (ko) * 2015-03-11 2016-09-15 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9756455B2 (en) * 2015-05-28 2017-09-05 Sony Corporation Terminal and method for audio data transmission
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
WO2017130800A1 (ja) * 2016-01-26 2017-08-03 株式会社Ｎｔｔドコモ 基地局及び送信方法
JP7008714B2 (ja) * 2017-09-19 2022-01-25 株式会社日立国際電気 通信装置
EP3747179B1 (en) * 2018-01-29 2022-12-14 Koninklijke Philips N.V. Bluetooth-based ipv6 low power networking
ES2921983T3 (es) * 2018-03-16 2022-09-05 Acklio Método y aparato para procesar datos de mensaje
CN110971363B (zh) 2018-09-28 2022-03-08 华为技术有限公司 用于以太网数据的通信方法的方法和装置
US10979399B2 (en) 2019-05-24 2021-04-13 Sierra Nevada Corporation Unified communication gateway systems
CN110727542B (zh) * 2019-09-18 2023-02-28 陕西法士特齿轮有限责任公司 一种Hex文件处理方法及应用
US11330665B2 (en) * 2020-01-09 2022-05-10 Qualcomm Incorporated Increasing throughput efficiency in a PDCP channel with ROHC TCP profile
CN115250137A (zh) * 2021-04-28 2022-10-28 合肥炬芯智能科技有限公司 蓝牙设备、蓝牙系统及其音频传输方法
CN113709510A (zh) * 2021-08-06 2021-11-26 联想(北京)有限公司 高速率数据实时传输方法及装置、设备、存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5940431A (en) * 1996-12-23 1999-08-17 Telefonaktiebolaget Lm Ericsson Access technique of channel hopping communications system
EP1107520A1 (en) * 1999-12-06 2001-06-13 Telefonaktiebolaget Lm Ericsson Method and arrangement in a communication network
EP1107508A1 (en) * 1999-12-06 2001-06-13 Telefonaktiebolaget Lm Ericsson System, method and computer program product for sending broadcast messages
US6608841B1 (en) * 1999-12-30 2003-08-19 Nokia Networks Oy System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks
US6931051B2 (en) * 2000-03-01 2005-08-16 Texas Instruments Incorporated Frequency hopping wireless communication system with filtered adaptive slicer

Similar Documents

Publication Publication Date Title
JP2005509381A6 (ja) ヘッダ圧縮を行う無線通信装置
JP2005509381A (ja) ヘッダ圧縮を行う無線通信装置
CA2429571C (en) Method and system for transmission of headerless data packets over a wireless link
JP3751823B2 (ja) 実時間サービスにおけるヘッダ圧縮
EP2098035B1 (en) Improved header compression in a wireless communication network
JP3559271B2 (ja) ヘッダフィールド圧縮時のコンテキスト識別子の定義方法
US9125088B2 (en) Dynamic robust header compression
US7391736B2 (en) Method and apparatus for transmitting packet data having compressed header
US6839339B1 (en) Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets
KR100697355B1 (ko) 확장 헤더 압축
US8310988B2 (en) Method of MAC header generation and data transmitting
US20090268667A1 (en) Header compression mechanism for transmitting RTP packets over wireless links
JP2005525049A (ja) パケット通信によるワイヤレス通信アレンジメント
WO2010121410A1 (zh) 一种采用arq机制的头压缩通信方法和装置
EP1972124B1 (en) Method of header compression over channels with out-of-order delivery
Kishi et al. A new inter-core built-in-self-test circuits for tri-state buffers in the system on a chip
KR101169724B1 (ko) 무선링크에 최적화된 헤더압축장치 및 그 방법
Ayed et al. Enhancing robust header compression over IEEE 802 networks
Marzegalli et al. Adaptive RTP/UDP/IP header compression for VoIP over Bluetooth
TW201421952A (zh) 蜂嘲式無線通信網路上支援網路語音服務方法及裝置