(57)【要約】【課題】改良されたワイヤレス通信アレンジメントと、改良されたワイヤレス通信アレンジメントを動作させる方法を提供すること。【解決手段】  第一ユニットと第二ユニットの間でパケットベースのワイヤレス伝送を行うための方法であって、一方の当該ユニットが、  a) 当該ユニット間の伝送に適したパケットを生成し、  b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、  c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、  d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定すること、を含む方法が開示されている。
2005525049.tif 000002
【特許請求の範囲】
【請求項１】
第一ユニットと第二ユニットの間でパケットベースのワイヤレス伝送を行うための方法であって、一方の当該ユニットが、
a) 当該ユニット間の伝送に適したパケットを生成し、
b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、
c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、
d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定すること、
を含む方法。
【請求項２】
チャネル・ビット・エラー・レート (BER) であることが好ましい、エラー・レートの評価、またはエラー・レートに関連する特徴もしくはエラー・レートから導出された特徴に少なくともある程度したがって当該ステータスを決定することを含む、請求項１に記載の方法。
【請求項３】
幾つかのタイムアウト・イベント、パケット再伝送レート、または受信信号強度 (RSSI) 測定値から当該エラー・レートを導出することを含む、請求項2に記載の方法。
【請求項４】
当該パケットの前記伝送にタイムアウトを適用することと、
当該活性期間と当該低パワー・モードの少なくとも1つを当該タイムアウトの持続期間に少なくともある程度依存して設定することと、
を含む、前記請求項の何れかに記載の方法。
【請求項５】
当該パケットの伝送にかかる時間長にある程度依存して当該タイムアウトの前記持続期間を設定することを含む、請求項4に記載の方法。
【請求項６】
当該活性期間と当該低パワー・モードとの少なくとも1つを、当該パケットの生成レートに少なくともある程度依存して設定することを含む、前記請求項の何れかに記載の方法。
【請求項７】
当該ユニット間のワイヤレス・チャネルのコンディションの評価から当該ステータスを決定することを含む、前記請求項の何れかに記載の方法。
【請求項８】
一方の当該ユニットをマスタ・ユニットとして構成すること、および他方の当該ユニットをスレーブ・ユニットとして構成すること、ならびに、
これらのユニット間の既存のベースバンド接続に対して少なくとも当該活性期間だけ実施を行うようにネゴシエートすること、
を含む、前記請求項の何れかに記載の方法。
【請求項９】
当該チャネルのコンディションのステータスを周期的に検査すること、および当該ステータス検査の結果規定の状況下に置かれた場合、当該活性期間だけ継続させかつフラッシュ・タイムアウトを行うように再ネゴシエートすることを含む、請求項8に記載の方法。
【請求項１０】
承認された当該活性期間の間だけ当該スレーブ・ユニットのポーリングを行う役割を当該マスタ・ユニットに与えることを含む、請求項8または請求項9に記載の方法。
【請求項１１】
当該活性期間の間における規定数の当該時間スロットの間のポーリングの試みに対するリスニングを行い、かつそのアドレスを持っている当該パケットを受信した場合には規定のリスニング・タイムアウトに対するリスニングを継続させるように当該スレーブ・ユニットを構成することを含む、請求項8〜10の何れかに記載の方法。
【請求項１２】
当該スレーブ・ユニットが当該チャネル上で活性状態で費やす時間量を当該リスニング・タイムアウトに依存して設定すること、および当該リスニング・タイムアウトをチャネルのコンディションに依存して変えることを含む、請求項11に記載の方法。
【請求項１３】
規定の状況下ではパケット通信が当該活性期間の持続期間を越えて延長できるようにすることを含む、前記請求項の何れかに記載の方法。
【請求項１４】
許容可能な数のパケット再伝送を設定すること、および当該数が設定されたレベルよりもチャネル・ビット・エラー・レートが増加したことに応じて当該数を増加させることを含む、前記請求項の何れかに記載の方法。
【請求項１５】
当該パケットを運ぶために用いられる論理チャネルに関連付けられているフラッシング・タイムアウトを、当該活性期間内の時間スロット数に依存して変えることを含む、前記請求項の何れかに記載の方法。
【請求項１６】
当該パケットを、
a) リアルタイム・ビット・ストリームを規定の最大長の1つ以上のペイロードに変換し、かつ1つ以上の予め定義されているヘッダを前記ペイロードつまり各当該ペイロードに適用して、予め定義されている通信プロトコルにしたがって当該パケットを生成することと、
b) 予め定義されているヘッダ圧縮技術を前記カプセル化されたパケットつまり各当該カプセル化されたパケットに適用し、かつ前記パケットつまり各当該パケットを当該ユニット間のワイヤレス接続の全体に渡って転移させるように適合化されているカプセル化プロトコルのフレーム内に前記パケットつまり各当該パケットをカプセル化すること、
により生成することを含む、前記請求項の何れかに記載の方法。
【請求項１７】
前記ペイロードつまり各当該ペイロードを、VoIP (Voice-over-Internet-Protocol)、オーディオ・ストリーム、またはビジュアル・ストリームなどのインターネット・プロトコル (IP) トラヒックを有する当該リアルタイム・ビット・ストリームから生成することを含む、前記請求項の何れかに記載の方法。
【請求項１８】
当該ユニットをBluetoothプロトコルにしたがって動作させることを含み、かつ当該低パワー・モードがBluetooth SNIFFモードを有することが好ましい、前記請求項の何れかに記載の方法。
【請求項１９】
第一ユニットと第二ユニットの間でパケットベースのワイヤレス伝送を実行させるためのソフトウエア製品であって、
a) 当該ユニット間の伝送に適したパケットを生成し、
b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、
c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、
d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定する、
ためのコードを含むソフトウエア製品。
【請求項２０】
第二ユニットに情報を実質的にリアルタイムに通信するように適合化されている第一ユニットを有する、パケットベースのワイヤレス通信アレンジメントであって、当該第一ユニットが、
a) 当該ユニット間の伝送に適したパケットを生成し、
b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、
c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、
d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定する、
ように適合化されている、パケットベースのワイヤレス通信アレンジメント。
【請求項２１】
当該ユニットが、Bluetoothプロトコルにしたがって動作可能であり、かつ当該低パワー・モードが、Bluetooth SNIFFモードを有していることが好ましい、請求項20に記載のワイヤレス通信アレンジメント。
【請求項２２】
請求項1〜18に記載の何れかの方法にしたがって動作するように適合化されており、かつBluetooth通信ネットワークのマスタ・ユニットとスレーブ・ユニットの内の少なくとも1つとして少なくとも一時的に構成されることが好ましい、ワイヤレス通信ユニット。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレス通信アレンジメントおよびワイヤレス通信アレンジメントを動作させる方法に関し、具体的にはワイヤレス通信アレンジメント、およびパケット伝送が1つのワイヤレス・ユニットから別のワイヤレス・ユニットに送信されるワイヤレス通信アレンジメントを動作させる方法に関する。本発明は、このようなアレンジメント内で使用される通信ユニットとソフトウエア製品にも関する。
【背景技術】
【０００２】
無線ユニットと、共有された資源ネットワークにこれらの無線ユニットを少なくとも一時的にグループ化するために用いられる接続とに基づいたワイヤレス通信システムが知られている。この一般的なタイプの現在の実施態様の1つは、ショートレンジの周波数ホッピング・ネットワークの形態をしており、かつ本技術分野ではBluetooth通信として知られている。このアレンジメントはBluetooth規格により管理されており、かつBluetooth通信に適合した完全な仕様は、SIG (Bluetooth Special Interests Group) を通して見つけ出すことができる。SIGのウェブサイトwww.bluetooth.comには、現在のBluetooth規格と関連情報が掲載されている。なおこの仕様書全体に渡って、BluetoothはBluetooth SIGの商標であることが認識されている。
【０００３】
Bluetooth通信に関する役立つ解説は、テキスト本の形態ではJennifer BrayとCharles F. Sturmanによる「Bluetooth、ワイヤを用いない接続 (Bluetooth, Connect Without Wires)」(Prentice Hall PTR, ISBN 0-13-089840-6) に見出すことができる。
【０００４】
更なる従来技術は、例えば、公開済みの米国特許出願第2001/0010689号と第2001/0006512号に見出すことができる。これらの特許出願では、この分野での現在の最新技術の側面が幾つか論じられている。
【０００５】
読者は上述の出典を参照して、Bluetoothの一般的な背景情報を得たり、かつ更に例えば、本明細書で用いられているが詳細には定義されていない技術用語を明確にされたい。
【０００６】
企業ネットワークでは、移動ユーザとの音声接続を行うためには通常、DECTシステムの場合のように、専用のアクセス・ポイントと端末を有する別々のインフラストラクチャが必要となる。様々な端末内にBluetooth (BT) トランシーバを大規模に配備することにより、BTの使用が可能な移動電話またはPDAを、企業音声サービスに対しても再利用することが可能となる。更に、同一のBluetoothアクセス・ポイントを、音声サービスとデータ・サービスの両方に使用することが可能となる。
【０００７】
Bluetoothネットワーク内の各アクセス・ポイントは、例えば、移動通信ハンドセットなどの移動端末を１つ以上有するBluetoothピコネットを形成する。明らかになりつつあるBluetoothの用途は、インターネット全体と企業ネットワーク／イントラネット内に配備されている、VoIP (Voice over Internet Protocol) プロトコル、およびデータまたはオーディオ／ビジュアル・トラヒックなどの他のタイプのIPトラヒックを配信することである。VoIPの主な利点は、通常はデータに用いられる既存のネットワーク・インフラストラクチャの音声トラヒックによりVoIPが用いられていることである。
【０００８】
Bluetooth規格の場合、音声通信には、2つのBluetoothデバイス間のいかなるリンクの上部にも確立可能な「同期接続型 (SCO: Synchronous Connection Oriented)」と命名された専用チャネルが使用される。このようなアレンジメントは、具体的には図2を参照して示されている。この方式によると、64 kbpsの音声チャネル全体で全二重通信を行うために、各々6個のベースバンド・スロットの内の2つが確保される。この音声リンクは、例えば、移動端末MTとアクセス・ポイントAPとの間で確立させることができる。同一のアクセス・ポイントには多数のハンドセット（または他の端末）を付属させてもよいので、幾つかの移動端末MTの、限られた利用可能なバンド幅（ピコネット毎に1 Mbpsの総容量）と低いパワー備蓄との使用効率を最大化させることが重要であることが分かる。データ・トラヒックを送信する必要がない場合、移動端末は2つの連続するSCOパケットの対の間で利用可能な4つのスロットの間に、低パワー・モードしか用いることができない。更に、単純なA-law PCMまたはμ-law PCMによって音声がコード化されるので、音声対話における沈黙の間でさえ2つのベースバンド・スロットが使用されてしまう。現在のSCOアレンジメントは、管理は容易だが、バンド幅および／またはパワーを浪費してしまうことを証明できることが分かる。
【０００９】
【特許文献１】米国特許出願第2001/0010689号
【特許文献２】米国特許出願第2001/0006512号
【非特許文献１】W. Tuttlebee「ワールドワイドなコードレス通信 (Cordless Telecommunications Worldwide)」（Springer, 1997年）
【非特許文献２】S. CasnerとV. Jacobson「低速シリアルリンクのためのIP/UDP/RTPヘッダの圧縮 (Compressing IP/UDP/RTP Headers for Low-Speed Serial Links)」
【発明の開示】
【課題を解決するための手段】
【００１０】
本発明の目的は、改良されたワイヤレス通信アレンジメントおよび改良されたワイヤレス通信アレンジメントを動作させる方法を提供することである。本発明の更なる目的は、ワイヤレス通信アレンジメントを改良すること、およびパケット伝送が1つのワイヤレス・ユニットから別のワイヤレス・ユニットに送信されるワイヤレス通信アレンジメントを動作させる方法を改良することである。本発明の目的は特に、このようなアレンジメントと方法で、最新技術よりもパワーを節約させることである。本発明の更なる目的は、このようなアレンジメントと方法で用いられる改良された通信ユニットとソフトウエア製品とを提供することである。
【００１１】
したがって、本発明は、
第一ユニットと第二ユニットとの間でパケットベースのワイヤレス伝送を行うための方法であって、一方の当該ユニットが、
a) 当該ユニット間の伝送に適したパケットを生成し、
b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、
c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、
d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定すること、
を含む方式を提供する。
【００１２】
本方法は、チャネル・ビット・エラー・レート (BER) の評価、エラー・レートの他のいかなる同等な評価、またはこのBERに関連付けられている伝送特徴もしくはこのBERから導出された伝送特徴に少なくともある程度したがって当該ステータスを決定することを含んでもよい。
【００１３】
本方法は、例えば、幾つかのタイムアウト・イベント、パケット再伝送レート、または受信信号強度 (RSSI) の測定値から当該ビット・エラー・レートを導出することを含んでもよい。
【００１４】
本方法は、当該パケットの前記伝送にタイムアウトを適用することと、当該活性期間と当該低パワー・モードの少なくとも1つを当該タイムアウトの持続期間に少なくともある程度依存して設定することと、を含んでもよい。
【００１５】
本方法は、当該パケットの伝送にかかる時間長にある程度依存して当該タイムアウトの前記持続期間を設定することを含んでもよい。
【００１６】
本方法は、当該活性期間と当該低パワー・モードとの少なくとも1つを、当該パケットの生成レートに少なくともある程度依存して設定することを含んでもよい。
【００１７】
本方法は、当該ユニット間のワイヤレス・チャネルのコンディションの評価から当該ステータスを決定することを含んでもよい。
【００１８】
本方法は、一方の当該ユニットをマスタ・ユニットとして構成すること、および他方の当該ユニットをスレーブ・ユニットとして構成すること、ならびにこれらのユニット間の既存のベースバンド接続に対して少なくとも当該活性期間だけ実施を行うようにネゴシエートすることを含んでもよい。
【００１９】
本方法は、当該チャネル・コンディションのステータスを周期的に検査すること、および当該ステータス検査の結果規定の状況下に置かれた場合は、当該活性期間とフラッシュ・タイムアウトとの持続期間を再ネゴシエートすることを含んでもよい。本方法は、承認された当該活性期間の間だけ当該スレーブ・ユニットのポーリングを行う役割を当該マスタ・ユニットに与えることを含んでもよい。本方法は、当該活性期間の間における規定数の当該時間スロットの間のポーリングの試みに対するリスニングを行い、かつそのアドレスを持っている当該パケットを受信した場合には規定のリスニング・タイムアウトに対するリスニングを継続させるように当該スレーブ・ユニットを構成することを含んでもよい。本方法は、当該スレーブ・ユニットが当該チャネル上で活性状態で費やす時間量を当該リスニング・タイムアウトに依存して設定すること、および当該リスニング・タイムアウトをチャネルのコンディションに依存して変えることを含んでもよい。
【００２０】
本方法は、規定の状況下ではパケット通信が当該活性期間の持続期間を越えて延長できるようにすることを含んでもよい。
【００２１】
本方法は、許容可能な数のパケット再伝送を設定すること、および当該数が設定されたレベルよりもチャネル・ビット・エラー・レートが増加したことに応じて当該数を増加させることを含んでもよい。
【００２２】
本方法は、当該パケットを運ぶために用いられる論理チャネルに関連付けられているフラッシング・タイムアウトを、当該活性期間内の時間スロット数に依存して変えることを含んでもよい。
【００２３】
本方法は、
当該パケットを、
a) リアルタイム・ビット・ストリームを規定の最大長の1つ以上のペイロードに変換し、かつ1つ以上の予め定義されているヘッダ (RTP, UDP, IP) を前記ペイロードつまり各当該ペイロードに適用して、予め定義されている通信プロトコル (BT) にしたがって当該パケットを生成することと、
b) 予め定義されているヘッダ圧縮技術 (ROHC) を前記カプセル化されたパケットつまり各当該カプセル化されたパケットに適用し、かつ前記パケットつまり各当該パケットを当該ユニット (MT, AP) 間のワイヤレス接続の全体に渡って転移させるように適合化されているカプセル化プロトコル (BNEP) のフレーム内に前記パケットつまり各当該パケットをカプセル化すること、
により生成することを含んでもよい。当該プロトコルは、Bluetoothプロトコルを有することが好ましい。
【００２４】
本方法は、前記ペイロードつまり各当該ペイロードを、VoIP (Voice-over-Internet-Protocol)、オーディオ・ストリーム、またはビジュアル・ストリームなどのインターネット・プロトコル (IP) トラヒックを有する当該リアルタイム・ビット・ストリームから生成することを含んでもよい。
【００２５】
本方法は、当該ユニットをBluetoothプロトコルにしたがって動作させることを含み、かつ当該低パワー・モードがBluetooth SNIFFモードを有することが好ましい。
【００２６】
本発明は、
第一ユニットと第二ユニットの間でパケットベースのワイヤレス伝送を実行させるためのソフトウエア製品であって、
a) 当該ユニット間の伝送に適したパケットを生成し、
b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、
c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、
d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定する、
ためのコードを含むソフトウエア製品も提供する。
【００２７】
本発明は、
第二ユニットに情報を実質的にリアルタイムに通信するように適合化されている第一ユニットを有する、パケットベースのワイヤレス通信アレンジメントであって、当該第一ユニットが、
a) 当該ユニット間の伝送に適したパケットを生成し、
b) ワイヤレス・チャネル上の、規定の持続期間の幾つかの時間スロットだけ間隔を置いて離れている連続的な当該活性期間の間に、当該パケットを連続的に伝送し、
c) 当該活性期間の間の時間スロット内で低パワー・モードを実施し、
d) 当該活性期間と当該低パワー・モードの内の少なくとも1つでの動作持続期間を、当該チャネルのステータスに依存して設定する、
ように適合化されている、パケットベースのワイヤレス通信アレンジメントも提供する。
【００２８】
当該ユニットはBluetoothプロトコルにより動作可能であり、かつ当該低パワー・モードはBluetooth SNIFFモードを有することが好ましい。
【００２９】
本発明は、本発明の方法にしたがって動作するように適合化されるワイヤレス通信ユニットであって、無線通信ネットワーク（例えば、Bluetooth通信ネットワーク）のマスタ・ユニットとスレーブ・ユニットの内の少なくとも１つとして少なくとも一時的に構成されることが好ましいワイヤレス通信ユニットも提供する。
【発明を実施するための最良の形態】
【００３０】
次に、特定の実施例を参照しながらかつ上述した図面を参照しながら、本発明を説明する。このような説明は単なる例示的なものであり、かつ本発明はこの説明には限定されない。本発明を特に無線通信ネットワークに関して説明するが、本発明は無線通信ネットワークには限定されない。「ワイヤレス (wireless)」という用語は、固定されたワイヤ線による通信をその伝送の一部に対して用いない何れの通信システムもカバーするものとして、広く解釈されるべきである。代替のワイヤレス通信システムには、拡散赤外線を用いて動作する光システムなどの光システムが含まれる。「ワイヤレス」という用語には、いわゆるコードレス・システムも含まれることに留意すべきである。コードレス通信システムの一般的な態様は、例えばW. Tuttlebeeによる著作、「ワールドワイドなコードレス通信 (Cordless Telecommunications Worldwide)」（Springer, 1997年）に解説されている。コードレス・システムは一般に、レンジが制限された、ローカルな組織化されていない無線通信ネットワークである。しかしながら、本発明の全ての実施例は、Bluetooth（登録商標）プロトコルとの併用が可能である点に留意されたい。Bluetooth（登録商標）にしたがって動作するネットワークは、組織化されていないセルラ・システムとして説明できる。
【００３１】
このようなシステムの特徴には、以下の内容が一つ以上含まれていてもよい。
‐ 拡散スペクトル技法としての低速周波数ホッピング。
‐ マスタ・ユニットとスレーブ・ユニットにより、マスタ・ユニットがホッピング・シーケンスを設定できること。
‐ 各デバイスが、それ自体のクロックとそれ自体のアドレスを持っていること。
‐ マスタ・ユニットのホッピング・シーケンスをそのアドレスから決定できること。
‐ 1つのマスタと通信する1組のスレーブ・ユニットが全て、（このマスタと）同一のホッピング周波数を持ちかつピコネットを形成すること。
‐ 共通のスレーブ・ユニットを通してピコネットをリンクさせて、スキャッタ・ネットを形成できること。
‐ スレーブ・ユニットとマスタ・ユニットとの間で時分割多重伝送 (TDMA: Time Division Multiplex Transmissions) が行われること。
‐ スレーブ・ユニットとマスタ・ユニットとの間で時分割複信 (TDD: Time Division Duplex) 伝送が行われること。
‐ スレーブ・ユニットとマスタ・ユニットとの間の伝送が同期または非同期の何れかでよいこと。
‐ スレーブ・ユニットがいつ伝送を行うことができるのかをマスタ・ユニットが決定すること。
‐ マスタ・ユニットによりアドレス指定されている場合にしかスレーブ・ユニットが応答できないこと。
‐ クロックが自走型であること。
‐ 組織化されていないネットワークであって、特にライセンスフリーの2.4 GHzのISMバンドで動作するネットワークであること。
‐ アプリケーションが他のBluetooth（登録商標）デバイスをエリア内で見つけることを可能にするソフトウエア・スタック。
‐ 他のデバイスがディスカバリ／照会手順により見つかること。
‐ ハード・ハンドオーバとソフト・ハンドオーバ。
周波数ホッピングに関して、「低速周波数ホッピング」とはホッピング周波数が変調レートよりも遅いことであり、かつ「高速周波数ホッピング」とはホッピング・レートが変調レートより速いことである。本発明は、低速ホッピングまたは高速ホッピングの何れかに必ずしも限定されるわけではない。
【００３２】
更に以下では「移動端末」に言及するが、本発明は、全てのユーザ端末が移動型であると限定するわけではない。固定された端末（例えば、デスクトップ・コンピュータ）を本発明に同様に使用してもよい。「パケット」にも言及するが、本発明はパケット交換システムに限定されるわけではない。「パケット・ベース (packet based)」という用語は、システムがパケット交換型かまたは回路交換型かを問わず、伝送のための情報パケットを使用するシステムのことである。
【００３３】
図2に概略的に表されている企業ネットワーク10では、ユーザ端末（例えば、第三世代 (3G) の移動電話の形態をした移動端末 (MT)）は、IPスタックが埋め込まれており、かつコードレス電話ハンドセットとして動作することができる。このような動作は、企業ネットワーク10内でVoIP接続を確立させることにより達成され、これをイントラネットとして具体化させてもよい。移動ハンドセットMTは、イントラネット内の1組のアクセス・ポイントAP1nの内の1つを用いてVoIP接続を確立して、発話または受話を行う。これらの発話は、ルータと専用ゲートウェイ (PABX/GW) を通して電話ネットワークに対して行うか、またはH.263つまりセッション初期化プロトコル (SIP: Session Initiation Protocol) シグナリング規格を用いることにより、例えば、1つ以上の他のハンドセットMT（更なる端末は図示しない）を有するイントラネット内で行うか、の何れでもよい。
【００３４】
移動電話MTとアクセス・ポイントAP1…nとの間でSCOリンクを使用する代わりに、従来のデータリンクが作成され、かつ移動電話とPABXゲートウェイとの間でアクセス・ポイントを通してVoIPトラヒックが交換される。移動端末MTは、従来の技法を使用してVoIP端末全体を実施しなければならない。関連付けられているプロトコル・スタックは、具体的には図3を参照すると示されている。
【００３５】
Bluetoothプロトコル・スタック上のVoIP：
VoIPソリューションでは、音声は（例えばGSMで使用される）G.723.1規格にしたがって（サイレンス抑制により）5.3 kbpsでエンコードされ、かつコード化されたサンプルは最初に20バイトのペイロードにパケット化され、次いでリアルタイム・プロトコル (RTP) にしたがってタイムスタンプされ、かつ最後にUDP/IPデータグラムに伝送される。このような方式によって、音声サンプルを運ぶIPデータグラムは30 ms毎に生成される。
【００３６】
VoIPパケットは、40バイトのヘッダと20バイトのペイロードを持っているので、堅固なヘッダ圧縮 (ROHC) アルゴリズムを適用して、連続したヘッダ・フィールド間の冗長性を活用することによりバンド幅を節約し、かつヘッダ長を（チャネルのコンディションに応じて）4〜10バイトに低減させなければならない。このヘッダ圧縮アルゴリズムには、パケット損失を引き起こしてしまう伝送エラーに対する堅固性がなければならない。ヘッダの圧縮 (compression) と解凍 (decompression) の概要は、具体的には図6a〜6cを参照すると示されている。
【００３７】
本明細書ではヘッダ圧縮技法と特にROHC (Robust Header Compression) を参照してきたので、これらの技法の幾つかの側面を説明することが有効と思われるが、より詳細に理解するためには、C. Borman外による2001年7月の論文「堅固なヘッダ圧縮 (ROHC)：フレームワークおよび4つのプロフィール：RTP, UDP, ESP、および非圧縮」を参照されたい。この論文は、IETF (Internet Engineering Task Force) のウェブサイトから参照番号 ”RFC3095” (URL:http://www.ietf.org/rfc/rfc3095.txt) でアクセス可能である。
【００３８】
ヘッダ圧縮機構は一般に、例えば、IPアドレスとUDPポートを有する静的ヘッダ・フィールドはセッション間には変化しないので、全てのパケットで静的ヘッダ・フィールドを送信する必要はない、という事実を利用することによりヘッダ・オーバヘッドを低減させる。更に、セッション間に変化するフィールド（例えば、RTPタイムスタンプ、RTPシーケンス番号、およびIP識別）を効率的に取り扱うことができるので、ヘッダ・オーバヘッドをより低減させることができる。単純な線形外挿法を用いて、これらのいわゆる「変更フィールド」が直前のパケットから予測可能となる場合もある。他のヘッダ・フィールド（例えば、IPヘッダ長とUDP長）はデータリンク・レベルから推定可能なので、これらのヘッダ・フィールドを伝送する必要はない。これらのフィールドは、「推定されたフィールド」と称される。
【００３９】
ヘッダ圧縮方式は、S. CasnerとV. Jacobsonによる1999年2月の論文「低速シリアルリンクのためのIP/UDP/RTPヘッダの圧縮 (Compressing IP/UDP/RTP Headers for Low-Speed Serial Links)」（インターネットRFC 2508）で提唱された。このアレンジメントは、RTP/UDP/IPヘッダを圧縮するが、典型的なワイヤレス・リンク上で発生するエラー・レートと往復遅延を扱うような設計はされなかった。
【００４０】
ヘッダ圧縮を、例えば、 "ACE" (Adaptive header Compression) と "ROCCO"(Robust Checksum-based header Compression) などのワイヤレス環境に適合化させるための技法が提案されてきている。"ACE"は、フィールド・エンコーディング方式「変更フィールド (changing fields)」（「ウィンドウ・ベースの最下位ビット」W-LSB）を導入する。この方式では、可変スライディング・ウィンドウ (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コンプレッサ (compressor) とデコンプレッサ (decompressor) は、リアルタイム・フローの動的フィールドが正確に処理され、かつこれに応じてヘッダが再構築されて、静的ヘッダ・フィールド（つまり所与のコンテキスト内で不変のままとなるフィールド）が全く伝送されないように、コンテキスト情報を維持する必要がある。圧縮と解凍の連鎖の線図は、具体的には図6aを参照すると見ることができる。
【００４４】
RTP/UDP/IPフローの動的フィールドを以下に列挙する。
‐ IP識別（16ビット）            IP-ID
‐ UDPチェックサム（16ビット）
‐ RTPマーカ（1ビット）          M-ビット
‐ RTPシーケンス番号（16ビット）  SN
‐ RTPタイムスタンプ（32ビット）  TS
他の全てのヘッダ・フィールドは静的か、または推定される。
【００４５】
コンプレッサは、最初、「初期化とリフレッシュ」 (IR) 状態にある。ここでヘッダは圧縮されずに送信されるので、デコンプレッサはIPフローのためのコンテキストを作成することができる。「第一オーダ」(FO) 状態では、コンテキストを台無しにしてしまう可能性があるストリーム内の不規則性を補償するために、コンプレッサは静的フィールドのアップデートしかデコンプレッサに送信しない。したがってこの状態では、コンプレッサは、コンテキストのアップデートしか送信しない。「第二オーダ」 (SO) 状態では、コンプレッサは、デコンプレッサが有効なコンテキストを既に受信済みであることを確信しているので、圧縮されたヘッダを送信する。具体的には図6bを参照されたい。
【００４６】
デコンプレッサは、「コンテキストがない」 (NC) 状態で開始する。ヘッダの解凍に成功するとデコンプレッサは直ちに、「完全なコンテキスト」 (FC) 状態へ移動する。この状態が通常の動作状態である。デコンプレッサはヘッダを繰り返し解凍して初めて、「静的コンテキスト」 (SC) 状態へ移動する。ここでデコンプレッサは、FO状態のコンプレッサによるコンテキスト・アップデート・パケットの送信を待機する。デコンプレッサは、有効なコンテキストを回復することができない場合、NC状態に戻る。具体的には図6cを参照されたい。
【００４７】
各状態間の移行は、オペレーティング・モードにより決定される。これらのモードの内、ROHCは、「一方向モード」（Uモード）、「双方向オプティミスティック・モード」（Oモード）、および「双方向信頼モード」（Rモード）の3種類を定めている。Uモードでは、デコンプレッサからコンプレッサへのフィードバック・チャネルは存在しないので（または使用不可能なので）、コンプレッサの状態間の移行は、入来するパケットのヘッダ内の周期的なタイムアウトと不規則性のみに基づいたものとなる。この場合、コンテキストを周期的にリフレッシュさせる必要がある。Oモードでは、フィードバック・チャネルは、エラー回復要求と、（オプションで）コンテキスト・アップデートの確認応答とを行うために使用される。このオペレーティング・モードの背景にある目的は、フィードバック・チャネルの使用を最小化することである。最後にRモードは、フィードバック・チャネルを集中的に使用して、損失の伝搬とダメージの伝搬とに対する堅固性を最大化させる。
【００４８】
W-LSBエンコーディング：
W-LSBアルゴリズムは、圧縮すべきヘッダ・フィールドの値「v」が与えられると、適切な基準値 (v_ref) がコンプレッサとデコンプレッサの両方で維持される場合、その最下位ビットしか伝送しない。「v_ref」値間のミスマッチをなくすために、可変スライディング・ウィンドウVSW内の「v_ref」を選択する適切な堅固なアルゴリズムが定義されている。圧縮される値「v」に対して伝送すべき最下位ビットの数「k」は、下述するように選択される。
【００４９】
下式を、vが変わることが予期される間隔とする。
2005525049.tif 000003
オフセット・パラメータpは、圧縮すべき特定のフィールドの挙動にしたがって選択することができる。
【００５０】
次にコンプレッサでは、値kを下式のように選択することができる。
2005525049.tif 000004
したがってkは、vが間隔 f(v_ref, k) 内に入るような最小値になることになる。
【００５１】
しかしながら、この方式は、エラーに対しては堅固でないかもしれない。なぜならばコンプレッサは、デコンプレッサが同じ基準値（この値は、伝送エラーのため実際には異なるものである可能性がある）を使用していることを知らないからである。この代わりに、可変スライディング・ウィンドウが導入される。
2005525049.tif 000005
この式には、伝送済みの最後のw個の値が含まれている。新たな値がコンプレッサに入ると、この値は必ずVSWに添付される。VSW内の幾つかの古い値が正確に受信済みであることをコンプレッサが十分に確信している場合、これらの値はVSWから除去される。
【００５２】
下式を、VSW内の最小値と最大値として定義する。
2005525049.tif 000006
【００５３】
W-LSBコーディング方式では、kは以下の公式にしたがって選択される。
2005525049.tif 000007
式中のg()は式 (2) で定義されている。
【００５４】
このように、伝送されたm個のビットをデコードするために十分な参照間隔をデコンプレッサが持っていることが確実でないので、フィールドをエンコードするためにより高い数のビットが使用される。実際には、デコンプレッサでのデコーディング技法は、以下のアルゴリズムに基づいている。
【００５５】
下式を、最後に正確に解凍された値v_ref_dと、受信済みのビット数mとが与えられた、解釈間隔として定義する。
2005525049.tif 000008
解凍済みのフィールドは、その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] を持っている。これは以下のように拡張される。
2005525049.tif 000009
この間隔の中で、その3個のLSBが '100' というパターンにマッチングしている唯一の値が156であることに気づくことができる。元のヘッダにCRCを少し（モードに応じて3〜8ビット）適用することによりデコンプレッサの正確さを検査して、未検出の伝送エラーによって解凍される値が誤ったものとなってしまい、この誤った値が今度は基準値として後で使用されてダメージが伝搬してしまうことを防ぐことができる。ダメージがある値の検出にCRCが失敗しても、ROHCフレームワーク内で補償される。
【００５９】
他のエンコーディング方式：
ROHCフレームワーク内で使用可能なアルゴリズムは、W-LSBコーディング・アルゴリズムだけではない。例えばRTPタイムスタンプなどの、通常は時間とともに規則的なステップで（TS_STRIDE値の倍数だけ）増加するある種のヘッダ・フィールドの特定の特徴を活かした他の方式が存在する。この特徴は、「スケール化されたRTPタイムスタンプ」エンコーディングにより活用されている。
【００６０】
RTPタイムスタンプは、一定レートで生成されるトラヒック、固定されたサンプリング周波数、およびパケット生成がこのサンプリング周波数にロックされるときに対する、一日の時刻の線形関数により近似化させることもできる。この場合、「タイマーベースのRTPタイムスタンプの圧縮」が適用される。
【００６１】
IP識別フィールド (IP-ID) は、IP-IDとRTPシーケンス番号との間のオフセット（RTPシーケンス番号は新たなパケット毎に1つ増加する）のみを考慮し、かつW-LSBエンコーディングをこのようなオフセットに適用することによりエンコードされる。
【００６２】
ROHCを用いたヘッダ圧縮後、パケットは、次に説明するBluetoothネットワーク・エミュレーション・プロトコル (BNEP: Bluetooth Network Emulation Protocol) を用いてカプセル化される。パーソナル・エリア・ネットワーク (PAN: Personal Area Network) ワーキング・グループは、Bluetooth上のIP (IP over Bluetooth) を規格化しており、かつこのために、Bluetoothネットワーク・カプセル化プロトコル (BNEP: Bluetooth Network Encapsulation Protocol) と命名された新たなプロトコルを開発している。このプロトコルは、Bluetooth媒体上に共通のネットワーキング・プロトコルを転移させるために用いられる、Bluetoothネットワークのカプセル化を行うためのパケット形式を定義している。BNEPは、Bluetoothに合わせてイーサネット（登録商標）のエミュレーションを行い、かつ3〜15バイトの長さ範囲の別のヘッダを追加する。BNEPによって、IPデータグラムはイーサネット・フレームにカプセル化され、かつ下にあるL2CAPレイヤに送信される。イーサネット・エミュレーション・レイヤを導入することにより、例えば、ネットワーク・アクセス・ポイント内またはBluetooth特別ネットワーク内で、ブロードキャスティング、マルチキャスティング、およびレイヤ2ブリッジング機能を実施することが可能となる。BNEPに関する詳細は、上記に参照したBluetooth SIG、およびこれらのウェブサイトから豊富に得ることができる。最後に、BNEPパケットはL2CAPフレームにカプセル化され、このL2CAPフレームは複数のベースバンド・パケットに区分化される。RTP/UDP/IPヘッダ圧縮方式の場合、各VoIPパケットはDM1パケットを2つ伝送させる必要がある。図3に示すプロトコル・スタックの変種を用いた特殊な状況では、VoIPフレームを単一のベースバンド・スロットで伝送することができる。
【００６３】
音声のリアルタイム・トラヒックの遅延感応性：
VoIPトラヒックには遅延に対する感応性があるので、各パケットは、特定量の時間内でレシーバに到達しなければならない。チャネル・エラーによりベースバンド・パケットが再伝送されたためにVoIPフレームが特定の制限時間を越えて遅延してしまった場合、このVoIPフレームは廃棄しなければならない。したがってチャネルのコンディションが悪い場合、設定可能な閾値範囲内で完全には伝送されなかった、遅延に対して感応性があるL2CAPフレームを自動的にフラッシュして、バンド幅とパワーを節約しなければならない。Bluetooth規格の場合、2つのピア・エンティティ間の各L2CAP論理チャネル上で自動フラッシュ・タイムアウトを行うようにネゴシエートすることができる。このネゴシエーションは、図5のフローチャートを参照すれば分かるように、L2CAPチャネルの構成処理の間に行われる。
【００６４】
本発明によると、VoIPコーデックを用い、かつBluetoothで利用可能な低パワー・モードを適切に管理することにより、移動音声端末MTのパワー消費を従来の技法と比べてかなり低減させることが可能となる。本発明は、このことを、チャネルのビット・エラー・レート評価と再伝送タイムアウトとにしたがって、いわゆる「SNIFF」低パワー・モードの持続期間を選択する、チャネル状態に依存するアルゴリズムを提供することにより達成する。
【００６５】
VoIPパケットをBluetooth ACLリンク上で伝送させる時間量は、様々な要因に依存する。第一に、ワイヤレス・チャネルのコンディションが挙げられる。つまりビット・エラー・レートが高くなるほど、ベースバンド・パケット毎に伝送すべき再伝送の数が多くなる。第二に、パケットの長さが挙げられる。つまり、ROHCアルゴリズムによれば、（L2CAPタイムアウトのために）フレーム損失が生じてしまった場合は、パケットのヘッダに対する圧縮比が減少して、伝送されるフレームがより長くなってしまう。
【００６６】
図4には、パケット再伝送が行われない理想的な場合に、VoIPフレームの伝送に必要な時間が、Bluetoothスロットに換算して示されている。マスタ（例えば、アクセス・ポイントAP）とスレーブ（例えば、移動端末MT）の間で2つの音声パケットを交換させるために必要な活性期間が、かなり制限されていることが分かる。実際には、パケット1は第一のDM1パケットをマスタからスレーブに運び、パケット2はパケット1の確認応答を行い、かつ第一DM1パケットをスレーブからマスタに運ぶ。パケット3はパケット2の確認応答を行い、かつ第二DM1パケットをマスタからスレーブに運ぶ。最後に、パケット5はパケット4に対する確認応答を運ぶだけである。
【００６７】
本発明によると、移動電話のトランシーバがパケット生成レートとチャネルのコンディションとに関する知識を与えられると、伝送される2つの連続するVoIPパケット間でスリープ状態になるように、Bluetooth SNIFFモードは用いられる。活性SNIFF期間は、図4の太線12により示されている。
【００６８】
パケット再伝送が行われない理想的な場合、トランシーバ活性期間と、音声パケットが生成される期間との間の比は、以下のようになる。
2005525049.tif 000010
これは、SCOリンクを使用した場合と比べるとパワー消費に換算して
2005525049.tif 000011
のゲインとなることを表している（ここで、ベースバンド・パケットの伝送と受信に消費されるパワーは同じであると仮定されている）。ビット・エラー・レートが増加するにつれて、ゲインは tA* まで減少する。この場合、理論的には、システムはSCOリンクを用いているシステムと同じパワーを消費する。しかしながら実際には、G.723.1音声コーデックはサイレンス抑制を用いているので、VoIPシステムは、SCOリンクを有するより単純なシステムよりもパワー効率がより良好となる。
【００６９】
SNIFFモードの適合性：
本発明の一態様によると、SNIFFモードで用いられる活性期間を、評価されたワイヤレス・チャネルのコンディションに応じて適合化させることが提案されている。既存のベースバンド接続の場合、SNIFFモードは、マスタとスレーブ間でネゴシエートされる。活性期間が一度承認されると、マスタは示された活性期間の間、スレーブをポーリングする役割を果たす（後のセクションを参照されたい）。必要な場合は、パケット再伝送をsniff活性期間の限界を越えて延長させることができる。L2CAPタイムアウトが12.5 ms（20個のベースバンド・スロット）の場合、本出願人が行った試験のシミュレーション結果によると、DM1パケットを使用すると、10 %未満のVoIPフレームが廃棄されて、ビット・エラー・レート (BER) が最大 2.7×10-2 となることが示されている。
【００７０】
したがって、SNIFF活性期間を、（ベースバンド・スロットの数で測定して）以下のように設定することが提案される。
2005525049.tif 000012
この単純な3-レベルの定量化方式は、ビット・エラー・レート測定値、ならびにBG（チャネルのコンディションが良い）およびBB（チャネルのコンディションが悪い）という2つの閾値に基づいている。これは、（例えば、移動端末がアクセス・ポイントから離れたために）チャネル・ビット・エラー・レートが増加してしまった場合に、ベースバンドの再伝送をより多く行えるようにするという発想である。
【００７１】
VoIP接続を運ぶために用いられる論理チャネルに関連付けられているL2CAP自動フラッシュ・タイムアウトは、下式などの単純な関係にしたがってSNIFF活性モードに適合化させなければならない。
2005525049.tif 000013
(1) に示されているビット・エラー・レートは、BTシステムで直接測定することはできないが、生成されたL2CAPタイムアウト・イベントの数、パケット再伝送のレート、または受信信号強度 (RSSI: Received Signal Strength) 測定から推定することができる。
【００７２】
移動端末内の処理は、評価されたチャネルのコンディションを周期的に検査し、かつ必要な場合は、SNIFF活性期間とL2CAPフラッシュ・タイムアウトの再ネゴシエーションを活性化させる必要がある。
【００７３】
実施に関する問題：
このセクションでは、本出願の一部を形成するパワー節約技法を適用するために用いられる、関連するBluetoothコマンドと制約事項に関する幾つかの詳細事項を説明する。
【００７４】
Bluetooth SNIFFモードのパラメータ：
sniffモードでは、スレーブ（移動端末）は、パケットがそのAM_ADDRと共に受信されるまで、幾つかの Nsniff attempt スロットの間だけsniffスロットのリスニングを行うことを開始する。その後、スレーブ（移動端末）は、受信されたパケットがスレーブ自体のAM_ADDRにマッチングするまで、Nsniff timeout スロットに対するリスニングを継続させる。最後にスレーブは、スリープ状態に戻り、この状態が次のsniffスロット・イベントまで続く。上記に詳述したVoIPの例の場合、以下のパラメータを使用しなければならない。
Nsniff attempts = 3
Nsniff timeout = {8, 14, 20}
Nsniff attempt = 3に設定すれば、マスタはそれが実行している他の活動を理由に、スレーブへのVoIPパケットの伝送を遅延させることが可能だが、それでもスレーブはフレームを受信することが可能となるであろう。Nsniff timeout は、チャネルのコンディションに適合化されたパラメータであり、かつデバイスがBluetooth (BT) チャネル上で活性のままとなる時間量を決定する。
【００７５】
sniffモードには、HCI_Sniff_Modeコマンドによって入る。このコマンドのパラメータは、以下の通りである。
Connection_Handle,
Sniff_Max_Interval,
Sniff_Min_Interval,
Sniff_Attempt,
Sniff_Timeout
Sniff_Max_Interval と Sniff_Min_Interval は同一でなければならず、かつVoIPパケットの生成レートにマッチングする。
【００７６】
留意しなければならない点は、ベースバンド・リンク、つまりこのリンクを用いる全てのL2CAP論理チャネルにSNIFFモードが適用されることである。したがって、他のトラヒック・ソースが同一のBTリンクを用いる場合、sniff活性期間をこれに応じて増加させ、かつ（HCIレイヤより上の）適切なスケジューリング・ポリシにより、VoIPフレームを運んでいるL2CAPフレームの優先度が他のトラヒック・ソースよりも高くなっていることを保証する必要がある。
【００７７】
L2CAP MTUに関連する考慮事項は、別のセクションで論じられているように考慮に入れなければならない。
【００７８】
より低いレイヤ：
SNIFFモードでのスレーブは、それ自体のAM_ADDRにマッチングするパケットが到着するまでチャネルでのリスニングを継続させるので、パワー節約技法が全体的に損なわれてしまう場合がある。したがって、マスタAPとスレーブMT内で、HCI_Write_Automatic_Flush_Timeoutコマンドを使用することが推薦される。このことにより、スレーブMTにチャネルへのリスニングを継続させてパワーを不必要に浪費してしまう、sniff活性期間を越えて延長するパケット再伝送が、マスタAPによりアボートされることが保証される。スレーブ内ではこのコマンドにより、1つのsniff活性期間の間にスレーブへの送信が成功していないベースバンド・パケットがベースバンド内でフラッシュされて、次のL2CAPフレームの第一パケットのための空間が作られることが確実となる。CI_Write_Automatic_Flush_Timeout コマンドのパラメータは、SNIFF活性期間にマッチングしなければならない。ベースバンド・パケットがフラッシュされる毎に、フェイルドコンタクト・カウンタ (Failed Contact Counter) が１だけ増える。
【００７９】
ここで差し当たり具体的には図5を参照すると、本発明の一実施例のフローチャートが設けられている。VoIPアプリケーションが一度開始すると、移動端末MT内の管理エンティティがチャネルリンクの特徴を構成し、かつL2CAPタイムアウトのためのパラメータを設定する。その後、sniff期間がピア・デバイスにネゴシエートされ、かつベースバンド自動フラッシュ・タイムアウトが、L2CAPタイムアウトにマッチングするように設定される。チャネルのコンディションのモニタリングは別の作業であり、他の処理とは独立して動作する。このメカニズムは、受信信号強度指標 (RSSI: received signal strength indicator）、ベースバンド・パケット再伝送率、L2CAPタイムアウト・レート、またはこれらを組み合せたものに基づいて測定されたワイヤレス・チャネルのコンディションに適合化される。チャネルのコンディションが著しく変化すると、L2CAPの再ネゴシエーションとベースバンド・フラッシュ・タイムアウトが開始する。このことを例えば、会話中の中断の間に行って、音声アプリケーションへの干渉を最小化させることができる。変更されたチャネルのコンディションにsniffパラメータとタイムアウト・パラメータが一度マッチングすると、パケット化された音声サンプルが伝送される正常状態にシステムは戻る。
【００８０】
提示されている技法は、移動端末の複雑性がある程度増加してしまうという犠牲を払って、Bluetoothリンク内でパワーを著しく節約させることを達成する。更に、本発明の開示で提示されている方法を、データ・サービスと音声サービスとを統合したワイヤレスネットワーク・インフラストラクチャに統合させることができる。
【００８１】
本発明を好ましい実施例に関して示しかつ説明してきたが、本発明の範囲内で形態と詳細部分の変更が可能であることを当業者は理解するであろう。
省略形の用語集：
【００８２】
2005525049.tif 000014
【図面の簡単な説明】
【００８３】
【図１】Bluetooth SCOリンクを表したものである。
【図２】本発明の態様が実施される通信システムの概略図である。
【図３】本発明の一実施例によるアレンジメントのプロトコル・スタックを表す。
【図４】図2のシステム内のVoIP接続での活性期間を表したものである。
【図５】本発明の一実施例によるワイヤレス伝送の高レベルなフローチャートである。
【図６ａ】ヘッダを圧縮と解凍の連鎖の概略図である。
【図６ｂ】コンプレッサの状態のブロック図である。
【図６ｃ】デコンプレッサの状態のブロック図である。
【図１】
2005525049.tif 000015
【図２】
2005525049.tif 000016
【図３】
2005525049.tif 000017
【図４】
2005525049.tif 000018
【図５】
2005525049.tif 000019
【図６ａ】
2005525049.tif 000020
【図６ｂ】
2005525049.tif 000021
【図６ｃ】
2005525049.tif 000022
【国際調査報告】
2005525049.tif 000023
2005525049.tif 000024