JP5721713B2 - ＢｌｕｅｔｏｏｔｈＬｏｗＥｎｅｒｇｙデバイスとして動作する時の低消費電力化のための方法および装置 - Google Patents

Description

本明細書は、概して、Bluetooth通信の分野に関し、より具体的には、Bluetooth Low Energy（BLE）デバイスに関する。

背景

BLE規格（バージョン0.9）は、http://www.Bluetooth.com/Bluetooth/SIG/で、Bluetooth Special Interest Group（BT SIG）で確認することができる。

Bluetooth Low Energy（BLE）技術は、低電力消費を必要とするデバイス、例えば、センサ、キーフォブ等の、1つ以上のボタン電池バッテリで動作し得るデバイスを対象としている。市場の中で一定の位置を占める技術にとって、そのようなバッテリは、例えば、デバイスがBLE規格に規定されているようにスレーブモードで動作した時に、1年を超えて持続しなければならないことが期待される。

このBLE規格は、以下のような、デバイスのためのいくつかの状態および役割を有する。
・ アドバタイジング状態
−発見可能／接続可能／ブロードキャスト
・ スキャニング状態
−アクティブまたはパッシブスキャニング
・ 開始状態
−アドバタイザへの接続を開始する
・ 接続された状態
−イニシエータは、マスター役になる
−アドバタイザは、スレーブ役になる

簡潔にするため、例えばアドバタイジングモードにおいて、要求された時間間隔で、または特定の要求を伴わずにデータを送信することができる、感知デバイスの例を検討する。マスター／収集デバイスと、データを提供するスレーブセンサとの間のリンクは、そのようなバッテリの寿命を延ばすために、低デューティサイクルで動作してもよい。低デューティサイクルは、この文脈において、一例に過ぎないが、1秒に1回だけ、または数秒に1回でも、温度等のデータを収集することを意味する。

例示的なBLEセンサデバイスは、ウェイクアップしてマスター／収集デバイスと通信するように構成されてもよい。例示的な実施形態において、BLEセンサは、いくつかの情報を標示する、または搬送するために、ある時間間隔の中で、ある期間にわたってマスター／収集デバイスと接続し、残りの期間は待機するように構成される。スレーブまたはマスターデバイスは、通信中はバッテリ電力をかなり多く消費し、待機中はより少ない消費電力ですむ。スリープ間隔は、スリープクロックを使用して計時されてもよい。データは、スレーブデバイスおよびマスターデバイスによって、パケットで送信されてもよい。現在のBluetooth Low Energy規格バージョン0.9は、図1に示されるように、パケット構造を定義する。パケット構造を、以下に詳述する。

例示的な実施形態では、パケットはプリアンブルを含み、その後にアクセスアドレスが続く。プリアンブルは、アクセスアドレスの第1ビットに応じて、「01010101」または「10101010」の固定パターンである。アクセスアドレスの第1ビットが「1」である場合、プリアンブルは「10101010」であり、それ以外の場合、プリアンブルは「01010101」である。メッセージ構成の可能な例は、図1に示されている。

図1は、データチャネル上でスレーブデバイスと通信しているマスターの例示的なメッセージ1を示す。マスターデバイスは、通信を開始してもよい。スレーブデバイスは、パケットを受信し、マスターからのパケットが終了した後、短い時間（例えば、150μs）内に応答してもよい。マスターからパケットを受信するために、スレーブデバイスは、受信機をオンにする。送信機および／または受信機のタイミングが不正確なために、スレーブデバイスは、マスターからのパケットに対する公称受信時間の前に、受信機を同時にオンにしなければならない場合がある。スレーブデバイスが受信機をオンにする時間は、受信ウィンドウと呼ばれる。例示的な実施形態において、受信ウィンドウは、スリープクロックの不正確さのため、パケットを受信するための時間に加え、付加的な早期ウェイクアップの持続時間を含む。

メッセージ構造のコンテンツには、複数の選択肢が存在する。例えば、図1を再度参照すると、パケット構造の中のPDUフィールドは、16ビットヘッダおよびいくつかの（ユーザ）データから成ってもよい。空のデータパケットの別の例において、PDUフィールドは、図1のメッセージ2に示されるように、16ビットヘッダだけから成る。近接使用の場合等のさらなる例において、図1に示されるように、空のパケット（例えば、図1のメッセージ2に示される）が、通信リンクを維持するために使用されてもよい。通信デバイスは、80ビットの空パケットを送信および受信する。

16ビットヘッダは、以下で構成されてもよい。
ペイロードデータユニット（Payload data Unit：PDU）
巡回冗長検査（Cyclic redundancy Check：CRC）
論理リンク識別子（Logical Link Identifier：LLID）
次の予想されるシーケンス（Next Expected Sequence：NESN）
シーケンス番号（Sequence number：SN）
さらなるデータ（More Data：MD）
将来使用するために予約（Reserved for Future Use：RFU）

摘要

本発明の実施例の種々の側面は、特許請求の範囲に記載する。

本発明の第1の側面によれば、Bluetooth通信トランシーバを備える、装置が開示される。前記装置は、少なくともタイミング測定を実行するように構成されるプロセッサも備える、BLEスレーブデバイスとして構成される。タイミング測定は、省電力のために使用されてもよく、プロセッサは、一組の測定に基づいて、前記装置の少なくともRx起動タイミングを調整してもよい。このようにして、スレーブデバイスのスリープクロックの同期は、規則的または不規則的間隔で確認されてもよい。この手法は、後述の側面のうちのいくつかと連動して使用されてもよい。例示的な実施形態において、BLEスレーブは、BLEスレーブセンサ、またはBLEシステムのスレーブデバイスとして構成される装置であってもよく、または、いくつかの例示的な実施形態では、BLEシステムのマスターデバイスとして構成されてもよい。前記装置は、バッテリによって駆動され、低消費電力で動作してもよい。前記装置は、携帯型装置、センサ装置／センサを備える装置等であってもよい。

本発明のさらなる側面によれば、前述した装置は、接続時間間隔を測定するためにタイマーを使用してもよい。装置は、接続時間間隔の測定から計算され、かつ少なくとも以降の時間間隔のための起動ウィンドウのサイズを少なくとも部分的に縮小するために使用される、オフセット値を提供してもよい。

本発明のさらなる側面によれば、記載される装置のプロセッサは、起動ウィンドウのための開始点として、スレーブデバイスの固有のアクセスアドレスの検出を使用してもよい。

本発明のさらに別の側面によれば、前述した装置のプロセッサは、ヘッダの中の論理リンク識別子（LLID）フィールドを検出して、起動ウィンドウを早期にオフにするためにこれを使用してもよい。

本発明のさらなる側面によれば、前述した装置のプロセッサは、接続が固定データ長のパケットを含むことを検出してもよい。例示的な実施形態において、パケットは、既知である、または例えば、第1のパケットの受信の後に予測可能である、巡回冗長検査（CRC）値を含む。CRC値の手法の検出からの情報に少なくとも部分的に基づいて、起動ウィンドウが開始される。CRC値自体の値が予想通りであった場合、該値は、以降の起動ウィンドウを開始するために、プリアンブルの代わりに使用されてもよい。前の例に示されるように、デバイスの種類、機能、および／またはアクティブであるプロファイルに従って起動時間が節約されてもよい。

本発明のさらに別の側面によれば、スレーブデバイスおよびマスターデバイスとして構成される装置間の距離は固定であってもよい。したがって、装置とマスターデバイスとの間の伝送遅延時間も固定である。装置のプロセッサが、遅延時間が固定されていると決定した時に、該プロセッサは、マスターデバイスからのリクエストへの応答回数を少なくとも部分的に減らしてもよい。

本発明のさらなる側面によれば、前述した装置は、受信したマスター遷移における省電力のために、少なくとも1つのタイミング測定を実行するようプロセッサを利用することを含む方法を実行してもよい。次いで、少なくとも1つのタイミング測定に基づいて、前記方法は、装置の受信起動ウィンドウの調整を実行することをさらに含んでもよい。

本発明のさらなる側面によれば、接続時間間隔が測定される前述の方法は、少なくとも1つのタイミング測定に基づいて、オフセット値をさらに決定してもよい。決定されたオフセット値はまた、以降の時間間隔のための起動ウィンドウのサイズを縮小するために使用されてもよい。

本発明のさらに別の側面によれば、前述した方法は、装置がスレーブデバイスとして構成された時に、固有のアクセスアドレスの使用に関連するイベントを検出することをさらに含んでもよい。検出されたイベントは、起動ウィンドウのための開始点として使用されてもよい。

本発明のさらなる側面によれば、前記方法は、ヘッダの中のLLIDフィールドを検出することをさらに含んでもよい。LLIDフィールドの検出された値に基づいて、プロセッサは、起動ウィンドウを早期にオフにしてもよい。

本発明のさらなる側面によれば、接続が固定データ長のものであることをプロセッサが検出し得る方法も開示される。これは、例えば、CRC値が既知である、1つのメッセージ構造であってもよい。よって、この実施例において、CRC値を受信する直前の時間は、起動ウィンドウを開始するために、プロセッサによってプリアンブルの代わりに使用することができる。

前述した側面は、デバイスの種類、機能、アクティブであるプロファイルに従って、同時に起動されてもよい。

本発明のもう1つの側面によれば、BLE装置が開示され、該装置は、マスターの遷移の1つ以上のタイミングをサンプリングし、アクティブメッセージの種類、機能、およびプロファイルのうちの少なくとも1つから、記載される1つまたは複数の起動時間節約方法のうちのどれが実行可能であるかを決定するように構成される。これに基づいて、プロセッサは、それに応じてスレーブの受信起動ウィンドウを調整してもよい。

本発明のさらなる側面によれば、第1の側面において前述した装置は、プロセッサと、プロセッサによって実行された場合、装置に、マスターの遷移のタイミングをサンプリングさせ、どの起動時間節約が実行可能であるかを決定させ、かつそれに応じて、スレーブの受信起動ウィンドウを調整させる、実行可能な命令を含む、少なくとも1つのメモリとを備える。

本発明のさらなる側面によれば、コンピュータプログラムが開示され、該コンピュータプログラムは、そのコンピュータプログラムがプロセッサ上で実行された時に、マスターの遷移のタイミングをサンプリングするためのコードと、どの起動時間節約が実行可能であるかを決定するためのコードと、それに応じて、スレーブの受信起動ウィンドウを調整するためのコードとを含む。

本発明の種々の側面の種々の実施形態によれば、前述した側面のうちのいずれかによるコンピュータプログラムは、前述した機能を実装するためにプロセッサで使用することができる、その中に具現化されるコンピュータプログラムコードを担持する、有形のコンピュータが読み取り可能な媒体を備える、コンピュータプログラム製品の中に実装されてもよい。

本発明の別の側面によれば、命令でコード化されたコンピュータが読み取り可能な媒体が開示される。命令は、プロセッサによって実行された時に、マスターの遷移のタイミングをサンプリングすること、どの起動時間節約が実行可能であるかを決定すること、およびそれに応じて、スレーブの受信起動ウィンドウを調整することを実行することができる、または可能にし得る。コンピュータプログラム命令は、電磁担体信号を介して装置に到達してもよく、またはコンピュータプログラム製品、メモリデバイス、またはこれに限定されないが、CD-ROMまたはDVD等の記録媒体、および／またはコンピュータプログラムを明らかに具現化している製品等の、物理的実体からコピーされてもよい。

「コンピュータが読み取り可能な記憶媒体」、「コンピュータプログラム製品」、「明らかに具現化されたコンピュータプログラム」等、または「プロセッサ」もしくは「処理回路」等の記述は、シングル／マルチプロセッサアーキテクチャ、およびシーケンサ／パラレルアーキテクチャ等の異なるアーキテクチャを有するコンピュータだけでなく、フィールドプログラマブルゲートアレイ（field programmable gate arrays：FPGA）、特定用途向け集積回路（application specific integrated circuits：ASIC）、信号処理デバイス、および他のデバイス等の、特殊回路も包含するものと理解されたい。コンピュータプログラム、命令、コード等の記述は、プロセッサのための命令としてのハードウェアデバイスのプログラム可能なコンテンツ等のプログラマブルプロセッサのファームウェアのためのソフトウェア、または固定機能デバイス、ゲートアレイ、プログラマブル論理デバイス等のための構成されたまたは構成設定を表すものと理解されたい。

種々の時間節約から選択する選択肢は、他のBTデバイスとの接続の種類に依存してもよい。さらに、1つ以上の予想されるメッセージの種類および頻度を定義する、デバイスの現在のプロファイルに依存してもよい。

本発明の例示的な実施形態をより完全に理解するために、以下、添付図面に関連してなされる以下の説明を参照する。
いくつかのBLEの例示的なメッセージ構成を示す。 マスターおよびスレーブの受信および伝送スロットのタイミング関係の例示的な実施形態を示す。 アクセスアドレスの節約が実行可能である時の、マスターおよびスレーブのタイミング関係の例示的な実施形態を示す。 LLIDの空パケットに対するマスターおよびスレーブのタイミング関係の例示的な実施形態を示す。 データパケットの固定データ長が適用可能な時の、マスターおよびスレーブのタイミング関係の例示的な実施形態を示す。 マスターが接続に関する空パケットを送信する時の、マスターおよびスレーブのタイミング関係の例示的な実施形態を示す。 本発明の例示的な実施形態による、固定の接続時間間隔プロセスのフロー図である。 アクセスアドレスに接続するためのプロセスフロー図の例示的な実施形態を示す。 固定データ長を有するパケットと接続するためのプロセスフロー図の例示的な実施形態を示す。 マスターが空パケットを接続毎に送信する時の、プロセスフロー図の例示的な実施形態を示す。 接続近接度が決定された時の、接続時間間隔のプロセスフロー図の例示的な実施形態を示す。 スレーブRXウィンドウタイミング制御のためのプロセスフロー図の例示的な実施形態を示す。 Bluetoothスレーブデバイスの例示的な実施形態を示す。 有形メモリ媒体の例示的な実施形態を示す。 Bluetoothスレーブデバイスの例示的な実施形態のソフトウェア（SW）の概観を示す。

詳細な説明

図1は、BLEの例示的なメッセージ構成を示す。例示的なメッセージ構成は、この明細書の背景技術の項に詳述される。

上述の明細書において、特に重要であると考えられる本発明の特徴に注意を向けるように努めているが、本出願人は、上文に参照および／または図面に示されたあらゆる特許性のある特徴もしくは特徴の組み合わせに関して、それに関して特に強調されたか否かに関わらず、保護を主張することを理解されたい。

本発明の例示的な実施形態およびその潜在的な利点は、図2〜15の図面を参照することによって理解される。

図2は、マスターおよびスレーブの受信および伝送スロットのタイミング関係の例示的な実施形態を示す。マスターラインから開始して、この例示的な実施形態は、ショートバースト（201）（例えば、データのリクエスト）としてメッセージを送信するマスター、およびスレーブの応答のためのマスター受信スロット（202）を示す。スレーブは、受信の開始を逃さないように、十分に前もって受信ウィンドウ（203）を開く。これにより、マスターから特定の範囲内にある場合に、マスターからのショートバースト（201）を検出する確率を高められる。したがって、スレーブは、マスターの伝送を逃さないよう、最初に広い受信ウィンドウ（203）を開く。このため、この手法を使用して、スレーブは、マスターとより良好に連結する機会を得られる。

例示的な実施形態において、接続時間間隔（例えば、図2の2つのマスター伝送の間の時間間隔）は、既知である。スレーブデバイスは、常時動作するスリープクロックを起動してもよい。したがって、スリープクロックは、主クロックが停止した時（例えば、スレーブデバイスがスリープ状態である時）に起動する。故に、スリープクロックは、2つのマスター伝送の間の時間を測定するために使用されてもよい。スレーブデバイスは、マスター伝送に関してその主クロックをキャリブレーションするために、2つのマスター伝送の間の測定した時間からキャリブレーション値を導出してもよい。スレーブデバイスはまた、マスター伝送に関連してスリープクロックを調整するために、測定から導出されるキャリブレーション値を使用してもよい。スレーブデバイスは、測定したオフセット（205）から導出された量だけ受信ウィンドウ（204）を縮小してもよく、縮小された受信ウィンドウ（206）を提供する。このようにして、スレーブデバイスは、ウェイクアップと、データの第1ビットの到着時間との間のオフセット（205）を測定することによって、スリープクロックを構成することができる。このリスニングウィンドウ（206）の縮小は、その接続期間の間の以降の時間間隔に適用することができる。

これは、スレーブのスリープクロックをキャリブレーションする／マスターデバイスのクロックに固定することによって達成される。このマスターデバイスのクロックに対するスレーブのスリープクロックのキャリブレーション／固定を実行することによって、規定の繰り返し速度で2つのデバイスの間を論理的に交わされるメッセージを含む、以降の接続バーストのための受信ウィンドウのタイミングに対して、複数の他の調整が行われてもよい。可能な調整の種類は、予想されるメッセージフォーマット、それが規定の繰り返し速度を有するという予想等に少なくとも部分的に依存してもよい。

マスターおよびスレーブデバイスが既知の接続時間間隔で接続された時に、スレーブデバイスは、ウェイクアップ時間と、マスター伝送の第1ビットの到着時間との間の時間を測定することによって、スリープクロックをキャリブレーションしてもよい。このキャリブレーションによるデータは、次の接続時間間隔におけるウェイクアップ時間を最小化するようにオフセットされた時間を提供するために使用されてもよい。スリープクロックのキャリブレーションは、例えば、マスターまたはスレーブデバイスの発振器の周波数のシフトを引き起こし得る温度変化を補うために、設定された時間間隔で実行されてもよい。例示的な実施形態において、キャリブレーションが設定された時間間隔で実行されることを確実にするために、タイマーが設定されてもよい。

新しい接続が確立された時に、このプロセスは繰り返されてもよい。スリープクロックの測定値、キャリブレーション値等の1つ以上の検出されたパラメータは、後述する図7および図12に関連して示されるプロセスに渡されてもよい。

図3は、アクセスアドレスの節約が実行可能である時の、マスターおよびスレーブのタイミング関係の例示的な実施形態を示すマスターラインから開始して、この例示的な実施形態は、特定の固有のアクセスアドレスを使用し続ける時の、データパケットのデータ構造を示す。この例示的な実施形態において、メッセージデータコンテンツは、以下の部分で構成される。
最初に、プリアンブル（302）、
2番目に、アクセスアドレス（303）、
次に、2〜39オクテットであってもよい、ペイロードデータユニット（PDU）（304）、
最後に、CRC（305）。

例示的な実施形態において、メッセージデータのコンテンツは、多数のパケットに同様に構成される。アクセスアドレスフィールドの終りまでに、そのアクセスアドレスの検出に基づいて、スレーブ受信機は、メッセージがそれを宛先として処理するものであるか、および該メッセージに応答するかどうかを知ってもよい。メッセージがスレーブ受信機を宛先としていない場合は、受信起動ウィンドウを閉じてもよい。メッセージがスレーブ受信機を宛先としている場合、アクセスアドレス（303）の最後の部分は、プリアンブル（302）の開始の代わりに、受信されたパケットデータの開始として使用することができる。このようにして、スレーブ受信機を宛先とするパケットを受信した時に、Rx起動時間（306）の節約を実行できる。1つ以上の検出されたパラメータは、後述する図8および図12に示されるプロセスで、最初に図8、次いで図12のプロセスの順に渡されてもよい。

図4は、LLIDの空パケットに対するマスターおよびスレーブのタイミング関係の例示的な実施形態を示す。マスターTXラインから開始して、この例示的な実施形態は、マスターが接続毎に少なくとも1つの空パケットを送信する時の状態を示す。マスターからの送信メッセージは、以下から成る。
最初に、プリアンブル（402）、
次に、アクセスアドレス（403）、
次いで、ヘッダ（404）および、
最後に、CRC（405）。

通常のスレーブ受信起動ウィンドウは（401）で示される。メッセージヘッダ（404）の中のLLIDフィールドは空パケットを標示するため、この例示的な実施形態においてゼロメッセージデータコンテンツを標示するようにLLID値が1に設定されていることを検出した時点（またはその直後）で、スレーブ受信起動ウィンドウは切り詰められてもよい。残りのメッセージは無視できるので、（406）で示されるように受信起動時間を節約できる。

例示的な実施形態において、スレーブからマスターへの伝送の際に、類似した時間節約が、マスターで達成され得る。1つ以上の検出されたパラメータは、本明細書の、最初に図9に、次いで図12に記載されるプロセスに渡されてもよい。この手法は、LLID=1という値で示される空パケットを有するデータについて、同じ方法でマスターデバイスに適用されてもよい。

図5は、データパケットの固定データ長が適用可能な時の、マスターおよびスレーブのタイミング関係の例示的な実施形態を示す。この例示的な実施形態において、再度マスターTXラインから開始して、データパケットのメッセージ構造は、以下を有する。
最初に、プリアンブル（502）、
2番目に、アクセスアドレス（503）、
次に、ヘッダ（504）および、
最後に、CRC（505）。

通常のスレーブ受信起動ウィンドウは（501）で示される。マスターおよびスレーブデバイスが接続され、かつメッセージの種類が固定長である時（例えば、パケットが固定フォーマットおよび長さを有する時）、CRC（505）値は、プリアンブル（505）の開始の代わりにスレーブの受信モードを開始するためのトリガ点として使用されてもよい。例示的な実施形態において、マスターは、80ビットの固定メッセージをスレーブに送信し、スレーブは、応答としての80ビットの別のメッセージを返信する。受信起動ウィンドウは、（506）で示されるように、予想されるCRCが到着し、CRCコンテンツが確認される前の短時間に縮小される。CRCが予想通りである場合、プロセスは繰り返されてもよい。このようにして、規定のメッセージのうちのいくつかは、繰り返しに過ぎないので、例えば、形式が固定である時、受信機の起動時間は、受信起動ウィンドウタイミングの修正によって短縮される。CRC値がメッセージシーケンスにおいて常に予想通りでない場合、受信起動ウィンドウタイミングは、例えば、受信起動ウィンドウ時間（501）のように、受信起動ウィンドウタイミングの短縮が実行される前の長さまで再度延長されてもよい。このように、プリアンブル、アクセスアドレス、またはヘッダのコンテンツだけでなくCRCフィールドのコンテンツも確認ことによって、受信起動ウィンドウが（506）で示される持続期間の値まで短縮され、時間を節約できる。1つ以上の検出されたパラメータは、後述する図10および図12に示されるプロセスで、最初に図10、最後に図12のプロセスに渡されてもよい。類似する、または同一の手法が、メッセージシーケンスの中の固定長パケットについて、マスターデバイスに適用されてもよい。

図6は、マスターが接続に関する空のパケットを送信する時の、マスターおよびスレーブのタイミング関係の例示的な実施形態を示す。この例示的な実施形態において、マスターアクティビティラインから開始して、繰り返しシーケンスが示される。例えば、マスターが、マスターTXバースト（601）で送信されたそのメッセージに対するスレーブの応答についてリスニングしている時には、マスターTXバースト（601）に続いて、マスターRXバースト（602）がある。例示的な実施形態では、マスターおよびスレーブデバイスが接続され、近接度検出機能は、スレーブにおいて可能にされる。例えば、スレーブは、事前設定された範囲内のマスターからの受信信号の受信信号強度インジケータ（received signal strength indicator：RSSI）を追跡する。事前設定された範囲内でRSSIレベルが一定である場合、スレーブは、マスターに対する近接度が変化していないとみなすことができる。

スレーブが、マスターに対する近接度が変化していないとみなした時に、スレーブは、スレーブアクティビティラインで示されるように、マスターからのリクエストに対する送信応答数を減らしてもよい。アイテム（603）は、スレーブRXバーストであり、アイテム（604）は、スレーブ応答TXバーストである。RSSIレベルが変化しない時、スレーブは、持続期間（606）中に示されるように、全てのマスターのリクエストに応答するわけではない。適用されるスレーブ遅延時間は、マスターのリクエストに対するスレーブの応答回数等のように、例えば、2回に1度、3回に1度、4回に1度、5回に1度等に固定することができ、またはアプリケーションによって動的に設定されてもよい。図6に示される例示的な実施形態において、スレーブ遅延時間は、4回に1度と設定されている。1つ以上の検出されたパラメータは、後述する図11および図12に示されるプロセスで、最初に図11、最後に図12のプロセスに渡されてもよい。

この例示的な実施形態において、RSSIは、持続期間（607）中に変化してもよく、スレーブ遅延はオフにされる。したがって、スレーブは全てのマスターパケット伝送に（例えば、空パケットの伝送にも）応答する。

さらなる例示的な実施形態において、例えば、スリープクロックが適切な許容度の範囲内でキャリブレーションされる場合、スレーブデバイスは、受信アクティビティを完全にスキップしてもよい。この例示的な実施形態において、受信起動ウィンドウは、1つ以上のインスタンスについて、ゼロにされてもよく、よって、スレーブは、次の交信時に、リスニングも応答も行わない。

さらに別の例示的な実施形態において、前述した例示的な実施形態のうちの1つ以上は、受信起動ウィンドウタイミングの管理を制御するように組み合わせられてもよい。

図7は、本発明の例示的な実施形態に従う、固定の接続時間間隔プロセスのフロー図を示す。この例示的な実施形態において、マスターおよびスレーブデバイスは、既知の接続時間間隔で接続される。接続時間間隔は、接続の種類およびメッセージの構成から決定されてもよい。ブロック（701）で、接続時間間隔が固定かどうか確認される。接続時間間隔が固定である場合、図2の（205）で示して説明したように、ブロック（702）でオフセットが測定される。次いで、ブロック（703）で、スリープクロックオフセットが計算される。これは、ステージ（704）で、パラメータとして定義されて、スレーブ受信起動ウィンドウの制御プロセスに渡されてもよい。エラー状態を発見した場合、同じまたは別のパラメータ通過メッセージとして、一組のパラメータで図12に記載される次のプロセスに渡されてもよい。ブロック（701）で、接続の種類が固定の接続時間間隔を提供していないと決定された場合、プロセスは終了する。1つ以上の検出されたパラメータは、ステージ（704）で定義されてもよく、後述する図12に示されるプロセスに渡される。プロセスは、ステージ（705）で終了する。

図8は、アクセスアドレスに接続するためのプロセスフロー図の例示的な実施形態を示す。この例示的な実施形態において、ステージ（801）で、固定のまたは固有のアクセスアドレスがアドレスマッチプロセスによって検出された時に、プロセスが開始されて、ステージ（802）に移動する。この例示的な実施形態において、メッセージ構造が図3に示されるようであるとすれば、ブロック（802）で、時間節約値が計算される。次のプロセスステージ（803）は、時間節約値を、実行可能な受信起動ウィンドウの縮小に変換する。ステージ（804）で、1つ以上のパラメータ（例えば、時間節約値）が、スレーブ受信起動ウィンドウの制御プロセスに渡される。パラメータメッセージが作成されて、後述する図12のプロセスに渡される。

何らかの種類のエラー状態を発見した場合、それは、同じまたは異なるパラメータメッセージの一部として、次のプロセスに渡されてもよい。接続時間間隔が固定でない場合、またはステージ（801）で固有のアクセスアドレスが検出された場合、プロセスは、渡されるパラメータの値を変化させることによって終了してもよい。ステージ（804）で、1つ以上の検出されたパラメータが渡されてもよい。パラメータメッセージが作成されて、後述する図12のプロセスに渡されてもよい。プロセスは、ステージ（805）で終了する。

図9は、固定データ長を有するパケットと接続するためのプロセスフロー図の例示的な実施形態を示す。この例示的な実施形態において、接続上のメッセージは、固定データ長を有するパケット（例えば、空パケットを標示する「1」に設定されたLLIDを有するパケット）とともに検出されてもよい。したがって、固定長であると検出された場合、ブロック（901）で、プロセスは、分岐「はい」に分岐して、ステージ（902）に進む。ステージ（902）で、値は事前設定済の「固定」値に設定される。ステージ（903）で、可能な受信起動ウィンドウの縮小（例えば、図4に関連して記載される受信起動ウィンドウの節約起動時間（406））が計算される。1つ以上の検出されたパラメータは、ステージ（904）で、後述する図12のプロセスに渡されてもよい。何らかの種類のエラー状態を発見した場合、それは、同じまたは別のメッセージの一部として、次のプロセスに渡されてもよい。ステージ（901）で、接続の種類が、固定の接続時間間隔を有するものでなかった場合（例えば、「0」に設定されたLLIDを有するパケットを伴う接続の場合）、1つ以上の検出されたパラメータは、ステージ（904）で、後述する図12のプロセスに渡されてもよい。プロセスは、ステージ（905）で終了する。

図10は、マスターが空パケットを接続毎に送信する時の、プロセスフロー図の例示的な実施形態を示すこの例示的な実施形態では、ブロック（1001）で、接続に送信されたメッセージの長さが固定であるかどうかが検出される。ステージ（1002）で、予想される節約時間が設定される。ブロック（1003）で、可能な受信起動ウィンドウの縮小が、図5に関連して前述したように計算されてもよい。1つ以上のパラメータは、ブロック（1004）で、後述する図12のプロセスに渡される。何らかの種類のエラー状態を発見した場合、これは、同じまたは別のメッセージの一部として、次のプロセスに渡されてもよい。ステージ（1001）で、接続の種類が、固定の接続時間間隔を有する接続として定義され得る場合、1つ以上の検出されたパラメータは、ステージ（1004）で、後述する図12のプロセスに渡されてもよい。プロセスは、ステージ（1005）で終了する。

図11は、接続近接度が決定された時の、接続時間間隔のプロセスフロー図の例示的な実施形態を示す。この例示的な実施形態において、ステージ（1101）で、RSSI測定（例えば、図6に示されるようなRSSI測定）が実行される。ステージ（1102）で最初の確認が実行され、測定したRSSI値が規定の範囲内にあるかどうかを確認する。測定したRSSI値が規定の範囲内になかった場合は、ステージ（1103）で、RSSI測定回数が十分であるかのテスト（例えば、所与の時間内に、所定の回数を超えるRSSI測定が実行されたかどうかのテスト）が実行される。十分なRSSI測定が実行されていなかった場合、プロセスは、より多くのRSSI測定を実行するために、ステージ（1101）に戻る。十分なRSSI測定が実行された場合、1つ以上の検出されたパラメータは、ステージ（1106）で、後述する図12のプロセスに渡されてもよい。プロセスは、ステージ（1107）で終了する。

ステージ（1102）で、必要とされる基準が達成された時（例えば、RSSI値が規定の範囲内にあると決定された時）、ステージ（1104）で、スキップ値が設定される。ステージ（1105）で、スキップすべき通信リクエスト数が計算される。この数は、図6に関連して前述したように使用されてもよい。1つ以上の検出されたパラメータ（例えば、スキップ値、スキップすべきリクエスト数等）は、ステージ（1106）で、後述する図12に記載されるプロセスに渡される。何らかの種類のエラー状態を発見した場合、これは、同じまたは別のメッセージの一部として、次のプロセスに渡されてもよい。ここでも、プロセスは、ステージ（1107）で終了する。

図12は、スレーブRXのウィンドウタイミング制御のためのプロセスフロー図の例示的な実施形態を示す。このプロセスは、受信機の受信起動ウィンドウに関する可能な時間節約の選択肢の一部または全てを設定または選択解除するために使用されてもよい。第1のステージ（1201）は、渡されたメッセージが少なくとも1つの有効なパラメータを有するかどうかを確認する。いかなるパラメータも提供されなかった場合、プロセスは、ステージ（1206）で終了する。パラメータが提供された場合、プロセスは、ステージ（1202）に進む。ステージ（1202）では、エラー状態（例えば、CRC計算によって検出されたエラー）が識別されたかどうかが確認される。エラー状態が識別された場合、プロセスは、ステージ（1203）に移動し、エラー応答に応じて1つ以上の値を再設定してもよい。ステージ（1203）の再設定イベントに続いて、プロセスは、ステージ（1206）で再度終了する。

ブロック（1202）で、渡されたデータがエラー状態を示さなかった時には、ステージ（1204）で、受信起動節約が適用される。受信起動節約は、示された状態の種類に依存してもよい。ステージ（1205）で、別の確認が実行される。状態が有効なままであるかどうかが確認される。状態がもはや有効ではない場合、ステージ（1201）で与えられた少なくとも1つのパラメータに対する受信起動節約を適用するためのプロセスは終了する。

図13は、Bluetoothスレーブデバイスの例示的な実施形態を示す。Bluetoothスレーブデバイス（1301）は、RAMおよび／またはROMを備え得るメモリユニット（1302）で実行可能な形態（1303）のコンピュータコードを含んでもよい。メモリユニット（1302）は、トランシーバ（1305）からの受信したメッセージに応答して命令が実行される、1つ以上のプロセッサ（1304）に接続されてもよい。トランシーバ（1305）は、別のBluetoothデバイスからパケットを伝送および受信するためのアンテナに接続されてもよい。

図14は、有形メモリ媒体の例示的な実施形態を示す。媒体（1401）は、プログラムコンテンツを有する、本発明に従う有形記憶媒体でもよい。媒体（1401）は、磁気、固体、光媒体等の、あらゆる形態の記憶媒体であってもよい。

図15は、Bluetoothスレーブデバイスの例示的な実施形態のソフトウェア（SW）の概観を示す。この図は、そのような装置またはデバイスに実装されてもよい、主なソフトウェア構成要素の例を示す。

このソフトウェア（SW）図において、装置は、オペレーティングシステム（OS）（1503）と、ハードウェア（HW）ドライバ（1505）とを有する。OS機能によって使用されるOSタイマーは、（1507）で示される。単一のボタンまたは複数のボタンであってもよい、マンマシンインターフェース（MMI）は、（1510）で示される。

インターフェース固有の構成要素は、Bluetooth（BT）無線インターフェースプロトコル制御スタック（1501）、RXまたはTXを選択するためにドライバ（1505）によって制御される実際のエアインターフェース（1502）、Bluetoothメッセージ構造およびキューを制御するメッセージマネージャ（1504）である。

さらに、装置は、少なくとも、前述のスリープタイマー（1506）を備えてもよい。それらは、本発明の特定の例示的な実施形態に関して記載された付加物がどのように任意の特定のSW構造で実装されたのかに応じて、OSタイマー（1507）を使用してもしなくてもよく、または独立に実装されてもよい。装置は、他のSW構成要素（1508）（例えば、BTプロファイルマネージャ）を備えてもよい。BTプロファイルマネージャは、デバイスのモードの管理や、提供または応答することも予想される付加的なメッセージの定義等を行ってもよい。例示的な実施形態において、デバイスは、単純で、かつ1つのプロファイルだけを有してもよい。別の例示的な実施形態において、デバイスは、より複雑であり、かつ複数のプロファイルを有しても、またはサポートしてもよい。

装置は、本発明の実施形態と直接的な相互作用を有し得ないのでこの明細書には記載されていない、さらなる随意のSW構成要素を備えてもよい。

本発明の実施形態は、ソフトウェア、ハードウェア、アプリケーション論理、またはソフトウェア、ハードウェア、およびアプリケーション論理の組み合わせで実装されてもよい。ソフトウェア、アプリケーション論理、および／またはハードウェアは、メモリ（1302）上、または（1401）で一例が示される任意のコンピュータ媒体上に存在してもよい。例示的な実施形態において、アプリケーション論理、ソフトウェア、または命令の組は、種々の従来のコンピュータが読み取り可能な媒体のうちのいずれか1つに保持される。この文書の文脈において、「コンピュータが読み取り可能な媒体」は、コンピュータ等の命令実行システム、装置、またはデバイス、図13に記載されて表現されるコンピュータの一例によって、またはこれに関連して使用するための命令を収容、記憶、通信、伝搬、転送することができる、任意の媒体または手段であってもよい。コンピュータが読み取り可能な媒体は、図14に示されるように、前述のように定義されたコンピュータ等の命令実行システム、装置、またはデバイスによって、またはこれに関連して使用するための命令を収容または記憶することができる、任意の媒体または手段であってもよい、コンピュータが読み取り可能な記憶媒体を含む。

本明細書に論じられる異なる機能は、必要に応じて、異なる順序で、および／または相互に同時に実行されてもよい。さらに必要であれば、前述した機能のうちの1つ以上は、任意選択であってもよく、または組み合わせられてもよい。

本発明の種々の側面が独立請求項に記載されているが、本発明の他の側面は、記載された実施形態からの特徴、および／または独立請求項の特徴を伴う従属請求項の他の組み合わせを含み、特許請求の範囲に明示的に記載された組み合わせに限定されない。

また、前述したものは、本発明の例示的な実施形態であるが、これらの説明は、限定的な意味で解釈されるべきではないことにも留意されたい。むしろ、添付の特許請求の範囲に定義される本発明の範囲から逸脱することのない複数の変形形態および修正形態があり得る。

Claims (13)

1. Bluetooth Low Energyデバイスとして構成される、Bluetooth通信トランシーバと、
   省電力のために、受信した伝送の少なくとも１つのタイミング測定を実行するように構成される、タイマーと、
   前記少なくとも１つのタイミング測定に少なくとも部分的に基づいて、前記Bluetooth通信トランシーバの受信タイミングを調整するように構成される、プロセッサと、
   を備え、ここで前記受信タイミングを調整することは、前記Bluetooth通信トランシーバの受信ウィンドウ幅を変更することを含む、装置。
2. 前記タイマーは、前記Bluetooth通信トランシーバの接続時間間隔において、前記少なくとも１つのタイミング測定を実行するように構成され、
   前記プロセッサは、前記Bluetooth通信トランシーバの前記受信タイミングの開始時間を調整するようにさらに構成される、請求項１に記載の装置。
3. 前記プロセッサは、前記Bluetooth通信トランシーバの前記受信タイミングの前記開始時間として、前記Bluetooth通信トランシーバのための固有のアクセスアドレスのタイミングを使用するように構成される、請求項２に記載の装置。
4. 前記プロセッサは、前記Bluetooth通信トランシーバによって受信したパケットのヘッダの中の論理リンク識別子フィールドを検出するように構成され、
   前記プロセッサは、前記論理リンク識別子フィールドのコンテンツに応じて、前記Bluetooth通信トランシーバの前記受信タイミングの終了時間を調整するようにさらに構成される、請求項１から３のいずれかに記載の装置。
5. 前記プロセッサは、巡回冗長検査値が既知であるように、接続が固定データ長のものであるかどうかを検出するように構成され、前記プロセッサは、前記Bluetooth通信トランシーバの受信起動ウィンドウタイミングの開始時間を、予想される巡回冗長検査値の受信の直前のタイミングにシフトするようにさらに構成される、請求項１から４のいずれかに記載の装置。
6. 前記プロセッサは、通信デバイスまでの距離が所定の範囲内であるかどうかを決定するように構成され、
   前記プロセッサは、前記Bluetooth通信トランシーバが所与の期間中の起動回数を減らすことによって、前記Bluetooth通信トランシーバ前記受信タイミングを調整するようにさらに構成される、請求項１から５のいずれかに記載の装置。
7. Bluetooth Low Energyデバイスとして構成されるBluetooth通信トランシーバで、省電力のために、受信した伝送の少なくとも１つのタイミング測定を実行することと、
   前記少なくとも１つのタイミング測定に少なくとも部分的に基づいて、受信タイミングを調整することと、
   を含み、ここで前記受信タイミングを調整することは、前記Bluetooth通信トランシーバの受信ウィンドウ幅を変更することを含む、方法。
8. 前記少なくとも１つのタイミング測定は、接続時間間隔の測定であり、
   少なくとも１つの以降の時間間隔において、前記受信タイミングの開始時間を調整することをさらに含む、請求項７に記載の方法。
9. 前記Bluetooth通信トランシーバのための固有のアクセスアドレスのタイミングは、前記Bluetooth通信トランシーバの前記受信タイミングの前記開始時間として使用される、請求項８に記載の方法。
10. 受信したパケットのヘッダの中の論理リンク識別子フィールドを検出することと、
    前記論理リンク識別子フィールドのコンテンツに応じて、前記Bluetooth通信トランシーバの前記受信タイミングの終了時間を調整することと、をさらに含む、請求項７から９のいずれかに記載の方法。
11. 巡回冗長検査値を知るように、接続が固定データ長のものであるかどうかを検出することと、
    前記Bluetooth通信トランシーバの前記受信起動ウィンドウタイミングの開始時間を、前記予想される巡回冗長検査値の受信の直前にシフトすることと、を含む、請求項７から１０のいずれかに記載の方法。
12. 少なくとも１つのプロセッサと、
    コンピュータプログラムコードを含む少なくとも１つのメモリと、
    を備え、
    前記コンピュータプログラムコードは、前記少なくとも１つのプロセッサによって実行されるとき、少なくとも、
    Bluetooth Low Energyデバイスとして構成されるBluetooth通信トランシーバでの、省電力のために、受信する伝送に対する少なくとも１つのタイミング測定の実行、および
    前記少なくとも１つのタイミング測定に少なくとも部分的に基づいた、受信タイミングの調整を、
    前記装置に実行させるように構成され、ここで前記受信タイミングを調整することは、前記Bluetooth通信トランシーバの受信ウィンドウ幅を変更することを含む、装置。
13. コンピュータプログラムコードを含むコンピュータプログラムであって、前記コンピュータプログラムコードは、装置のプロセッサによって実行されるとき、
    Bluetooth Low Energyデバイスとして構成されるBluetooth通信トランシーバで、省電力のために、受信した伝送の少なくとも１つのタイミング測定を実行することと、
    前記少なくとも１つのタイミング測定に少なくとも部分的に基づいて、受信タイミングを調整することと、
    を前記装置に実行させるように構成され、ここで前記受信タイミングを調整することは、前記Bluetooth通信トランシーバの受信ウィンドウ幅を変更することを含む、コンピュータプログラム。

Images