(57)【要約】  ブルートゥースローエネルギー（ＢＬＥ）デバイスのための接続セットアップの種々の手法が開示される。種々の実施例は電力を節約する。一例において、装置（ＢＬＥスレーブなど）が、アドバタイジングパケット（１０２、１０８、１１４）を送信するように構成されるコントローラ（２２）を含む。コントローラ（２２）は、パケットに対する応答及びその欠落に基づいて、スキャンウィンドウ（１１２）及びスキャンインタバル（１１８）の長さを推定する。別の実施例において、マスターデバイスなどの装置が、スキャンウィンドウ長さ、スキャンインタバル、及びそのマスターに対する開始及び終了時間を特定するスキャン更新パケットを生成するように構成される。コントローラは、パケットを１つ又は複数のスレーブデバイスに送信するように構成される。
2014518492.tif 000002
【特許請求の範囲】
【請求項１】
装置であって、
ワイヤレストランシーバにワイヤレスパケットを送信及び受信させるように構成されるコントローラ、
を含み、
前記コントローラがキャリブレーションプロセスを実行するように構成され、前記キャリブレーションプロセスにおいて、前記コントローラがアドバタイジングパケットを送信し、応答が前記アドバタイジングパケットから受信されたか否かに基づいて、別のワイヤレスデバイスにより実装されるスキャンウィンドウ及びスキャンインタバルの長さを前記コントローラが推定する、
装置。
【請求項２】
請求項１に記載の装置であって、前記コントローラにより応答が受信されるまでワイヤレスアドバタイジングパケットが送信されるようにすることにより前記スキャンインタバルの前記長さを推定することにより、前記コントローラが前記キャリブレーションプロセスを実行し、前記応答が受信される時点で、応答が受信された時間を前記コントローラが第１の時間として記録する、装置。
【請求項３】
請求項２に記載の装置であって、応答が受信されないことを前記コントローラが判定するまでワイヤレスアドバタイジングパケットが送信されるようにし続けることにより、前記コントローラが前記キャリブレーションプロセスを実行し、前記判定する時点で、前記コントローラが、応答が受信されない時間を第２の時間として記録し、前記第１の時間を前記第２の時間から減じることにより前記スキャンウィンドウを推定する、装置。
【請求項４】
請求項２に記載の装置であって、応答が受信されないことを前記コントローラが判定するまでワイヤレスアドバタイジングパケットが送信されるようにし続けることにより、前記コントローラが前記キャリブレーションプロセスを実行し、その後更に、応答が再び受信されるまでアドバタイジングパケットが送信されるようにし続け、前記応答が再び受信される時点で、前記コントローラが、応答が受信された時間を第３の時間として再び記録する、装置。
【請求項５】
請求項４に記載の装置であって、前記第１の時間を前記第３の時間から減じることによって前記スキャンインタバルを推定することにより、前記コントローラが前記キャリブレーションプロセスを実行する、装置。
【請求項６】
請求項１に記載の装置であって、前記キャリブレーションプロセスを完了した後、アドバタイジングパケットのラウンドを前記コントローラが送信し、このようなアドバタイジングパケットに対する応答が受信されない場合、前記推定されたスキャンインタバルが、アドバタイジングパケットのラウンドを送信するための時間より単一のアドバタイジングパケットを送信するための時間だけ短いものよりも大きいか否かを前記コントローラが判定する、装置。
【請求項７】
請求項１に記載の装置であって、前記推定されたスキャンインタバルが、アドバタイジングパケットのラウンドを送信するための前記時間より単一のアドバタイジングパケットを送信するための時間だけ短いものよりも大きいと前記コントローラが判定することに基づいて、アドバタイジングパケットのラウンドを送信するための少なくとも前記時間より単一のアドバタイジングパケットを送信するための時間だけ短い間、前記コントローラがアドバタイジングパケットを送信することを中止する、装置。
【請求項８】
請求項７に記載の装置であって、アドバタイジングパケットのラウンドを送信するための少なくとも前記時間より単一のアドバタイジングパケットを送信するための時間だけ短い間、アドバタイジングパケットを送信することを中止すると、前記コントローラが、アドバタイジングパケットのラウンドを再び送信し、再び判定し、応答が受信されない場合、アドバタイジングパケットのラウンドを送信するための少なくとも前記時間より単一のアドバタイジングパケットを送信するための時間だけ短い間、前記コントローラがアドバタイジングパケットを送信することを再び中止する、装置。
【請求項９】
請求項１に記載の装置であって、前記コントローラがブルートゥースローエネルギー（ＢＬＥ）プロトコルを実装する、装置。
【請求項１０】
装置であって、
ワイヤレストランシーバにワイヤレスパケットを送信及び受信させるように構成されるコントローラ、
を含み、
前記コントローラが、
ワイヤレスアドバタイジングパケットの第１のラウンドを送信するように、及び
前記アドバタイジングパケットのうちの任意のものに応答が受信されたか否かを判定するように、及び
前記アドバタイジングパケットのうちの任意のものに応答が受信されなかったことに基づいて、少なくともアドバタイジングパケットのラウンドを送信するための時間より単一のアドバタイジングパケットを送信するための時間だけ短い時間の期間、前記ワイヤレストランシーバにアドバタイジングパケットをワイヤレスに送信させることを中止するように、
構成される、
装置。
【請求項１１】
請求項１０に記載の装置であって、前記コントローラが、前記時間期間の間前記トランシーバにアドバタイジングパケット送信させることを中止した後、再び、前記トランシーバに、アドバタイジングパケットの第２のラウンドをワイヤレスに送信させるように、及びこのようなアドバタイジングパケットのうちの任意のものに応答が受信されるか否かを判定させるように構成される、装置。
【請求項１２】
請求項１１に記載の装置であって、前記第２のラウンドにおける前記アドバタイジングパケットのうちの任意のものに応答が受信されなかったことに基づいて、前記コントローラが、少なくとも、アドバタイジングパケットのラウンドを送信する時間の期間より単一のアドバタイジングパケットを送信するための時間だけ短い時間の期間、ワイヤレスアドバタイジングパケットを送信することを再び中止するように構成される、装置。
【請求項１３】
請求項１０に記載の装置であって、前記コントローラがキャリブレーションプロセスを実行するように構成され、前記キャリブレーションプロセスにおいて、前記コントローラがアドバタイジングパケットを送信し、前記アドバタイジングパケットからの応答が受信されたか否かに基づいて、別のワイヤレスデバイスにより実装されるスキャンウィンドウ及びスキャンインタバルの長さを前記コントローラが推定する、装置。
【請求項１４】
請求項１２に記載の装置であって、前記コントローラが、
前記トランシーバにアドバタイジングパケットを反復的に送信させること、
応答がアドバタイジングパケットに受信されるポイントを第１の時間として記録すること、
応答がアドバタイジングパケットに受信されないポイントを後続の第２の時間として記録すること、及び
前記第２の時間より後に、応答が再びアドバタイジングパケットに受信されるポイントを第３の時間として記録すること、
により、前記スキャンウィンドウ及びスキャンインタバルの前記長さを推定する、装置。
【請求項１５】
方法であって、
ワイヤレスアドバタイジングパケットの第１のラウンドを送信すること、
前記アドバタイジングパケットのうちの任意のものに応答が受信されるか否かを判定すること、及び
前記アドバタイジングパケットのうちの任意のものに応答が受信されなかったことに基づいて、少なくともアドバタイジングパケットのラウンドを送信する時間より単一のアドバタイジングパケットを送信するための時間だけ短い時間期間である時間の期間、アドバタイジングパケットをワイヤレスに送信することを中止すること、
を含む、方法。
【請求項１６】
請求項１５に記載の方法であって、前記時間期間アドバタイジングパケットを送信することを中止した後、アドバタイジングパケットの第２のラウンドをワイヤレスに送信し、このようなアドバタイジングパケットのうちの任意のものに応答が受信されるか否かを判定する、方法。
【請求項１７】
請求項１６に記載の方法であって、前記第２のラウンドにおける前記アドバタイジングパケットのうちの任意のものに応答が受信されなかったことに基づいて、少なくともアドバタイジングパケットのラウンドを送信する時間より単一のアドバタイジングパケットを送信するための時間だけ短い時間の期間、ワイヤレスアドバタイジングパケットを送信することを再び中止する、方法。
【請求項１８】
請求項１７に記載の方法であって、スキャンインタバルを推定することを更に含み、前記スキャンインタバルを推定することが、
アドバタイジングパケットを反復的に送信すること、
アドバタイジングパケットに応答が受信されるポイントを第１の時間として記録すること、
アドバタイジングパケットに応答が受信されないポイントを後続の第２の時間として記録すること、及び
前記第２の時間より後に、アドバタイジングパケットに応答が再び受信されるポイントを第３の時間として記録すること、
を含む、方法。
【請求項１９】
方法であって、
応答が受信されるまでアドバタイジングパケットを送信すること、
前記応答が最初に受信された第１の時間を記録すること、
応答が受信されなくなるまで付加的なアドバタイジングパケットを送信すること、
応答が受信されない第２の時間を記録すること、及び
前記第１及び第２の記録された時間に基づいてスキャンウィンドウを推定すること、
を含む、方法。
【請求項２０】
請求項１９に記載の方法であって、応答が再び受信されるまで付加的なアドバタイジングパケットを送信すること、及び応答が受信される第３の時間を記録することを更に含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
ブルートゥースローエネルギー（ＢＬＥ）は、短い範囲内（約１６０フィートまで）のワイヤレスデバイス向けの新たな主として低電力及び低レイテンシー用途のワイヤレス無線技術である。ＢＬＥネットワークは、特に、ヘルスケア、フィットネス、セキュリティ、及びホームエンターテイメント産業における幅広い範囲の用途、及び一層小さなフォームファクタデバイスによく適している。その名が示すとおり、ＢＬＥは、センサ又はディスポーザブルデバイス、特に、比較的少ないデータを送信するもの及び滅多に送信しないものとして、このようなエネルギー制約用途に意図される。ＢＬＥは、例えば、コイン電池バッテリーで、拡張された時間期間動作する小型デバイスとのワイヤレス接続を可能とするように設計された。ＢＬＥ技術を用いるネットワークの一つの目的は、ロバストであり、情報の安全な搬送であるが、バッテリー電力を節約することも重要である。
【発明の概要】
【０００２】
装置が、ワイヤレストランシーバにワイヤレスパケットを送信及び受信させるように構成されるコントローラを含む。コントローラはキャリブレーションプロセスを実行するように構成される。キャリブレーションプロセスにおいて、コントローラがアドバタイジングパケットを送信し、応答がアドバタイジングパケットから受信されたか否かに基づいて、別のワイヤレスデバイスにより実装されるスキャンウィンドウ及びスキャンインタバルの長さをコントローラが推定する。
【０００３】
他の実施例において、装置が、ワイヤレストランシーバにワイヤレスパケットを送信及び受信させるように構成されるコントローラを含む。コントローラは、ワイヤレスアドバタイジングパケットの第１のラウンドを送信するように、及びアドバタイジングパケットのうちの任意のものに応答が受信されたか否かを判定するように、及びアドバタイジングパケットのうちの任意のものに応答が受信されなかったことに基づいて、少なくともアドバタイジングパケットのラウンドを送信するための時間より単一のアドバタイジングパケットを送信するための時間だけ短い時間の期間、ワイヤレストランシーバにアドバタイジングパケットをワイヤレスに送信させることを中止するように構成される。
【０００４】
更に別の実施例が或る方法を含み、この方法は、ワイヤレスアドバタイジングパケットの第１のラウンドを送信すること、及びアドバタイジングパケットのうちの任意のものに応答が受信されるか否かを判定することを含む。アドバタイジングパケットのうちの任意のものに応答が受信されなかったことに基づいて、この方法は更に、少なくともアドバタイジングパケットのラウンドを送信する時間より単一のアドバタイジングパケットを送信するための時間だけ短い時間期間である時間の期間、アドバタイジングパケットをワイヤレスに送信することを中止することを含む。
【０００５】
別の方法実施例が、応答が受信されるまでアドバタイジングパケットを送信すること、応答が最初に受信された第１の時間を記録すること、応答が受信されなくなるまで付加的なアドバタイジングパケットを送信すること、及び応答が受信されない第２の時間を記録することを含む。第１及び第２の記録された時間に基づいてスキャンウィンドウが推定される。
【図面の簡単な説明】
【０００６】
【図１】図１は、種々の実施例に従ったスレーブとワイヤレス通信するマスターデバイスを示す。
【０００７】
【図２】図２は、種々の実施例に従ったスレーブ又はマスターデバイスの例示の実装を示す。
【０００８】
【図３】図３は、種々の実施例に従ったアドバタイジングＡＤＶ＿ＩＮＤパケット及び応答を図示する。
【０００９】
【図４】図４は、種々の実施例に従ったアドバタイジングＡＤＶ＿ＤＩＲ＿ＩＮＤパケット及び応答を図示する。
【００１０】
【図５】図５は、種々の実施例に従ったスレーブデバイス上に実装されるキャリブレーションプロセスにおいて、スキャンウィンドウ及びスキャンインタバルが推定される種々の実施例に従った方法を示す。
【００１１】
【図６】図６は、種々の実施例に従ったキャリブレーションプロセスを示すタイムラインを図示する。
【００１２】
【図７】図７は、種々の実施例に従って、スレーブデバイスが図５の方法からの推定を用いる方法を示す。
【００１３】
【図８】図８は、種々の実施例に従った、スレーブデバイスに対しスキャンウィンドウ及びスキャンインタバルを特定するためマスターデバイスにより用いられ得るパケットを図示する。
【００１４】
【図９】図９は、種々の実施例に従った、現在の時間がスキャンウィンドウ間のデッドタイム時間にあるタイムライン例を示す。
【００１５】
【図１０】図１０は、種々の実施例に従った、現在の時間がスキャンウィンドウ内にあるタイムライン例を示す。
【００１６】
【図１１】図１１は、種々の実施例に従った、スレーブデバイス推定が、マスターデバイスにより提供されるスキャン更新情報を用いる方法を示す。
【発明を実施するための形態】
【００１７】
幾つかのワイヤレスネットワークにおいて、ワイヤレスデバイスは、データ転送を促進するため互いとの接続をセットアップする。本開示はＢＬＥネットワークに焦点を置くが、本開示の範囲及び特許請求の範囲は、他のネットワークタイプにも適用する。接続セットアッププロセスに関する問題は、ＢＬＥスレーブデバイスが接続セットアップフェーズにかなりの時間を費やすことである。概して、ＢＬＥデバイスは、要求される機能性に応じて異なるモードで動作し得る。オペレーションの主なモードには、アドバタイジングモード、スキャニングモード、マスターデバイスモード、及びスレーブデバイスモードが含まれる。アドバタイジングモードでは、ＢＬＥデバイスは、アドバタイジングパケットを周期的に送信し、他のデバイスからの要求に対し更なる情報で応答し得る。スキャニングモードでは、ＢＬＥデバイスは、他のデバイスにより送信されたアドバタイジングパケットを聞き、受信し、アドバタイジングパケットの発信者から付加的な情報を要求し得る。スレーブデバイスは単一のマスターに接続するが、マスターは同時に複数のスレーブデバイスに接続してもよい。
【００１８】
接続を確立するため、第１のＢＬＥデバイスがアドバタイジングフレームを送信する。第２のＢＬＥデバイスが、アドバタイジングフレームに応答し、付加的な情報を要求し得る。付加的な情報が要求される場合、第１のデバイスは要求された情報を送信する。接続はその後、スレーブデバイスである第１のデバイス及びマスターデバイスである第２のデバイスと確立され得る。本開示において、「スレーブデバイス」という言及は、アドバタイジングパケットを送出するＢＬＥデバイスを指し、「マスターデバイス」は、アドバタイジングパケットを受信し、アドバタイジングパケットに応答するＢＬＥデバイスである。
【００１９】
スレーブデバイスが、アドバタイジングインジケータ（ＡＤＶ＿ＩＮＤ）及びアドバタイジングディレクティッド（ＡＤＶ＿ＤＩＲＥＣＴＥＤ＿ＩＮＤ：これは図４におけるＡＤＶ＿ＤＩＲ＿ＩＮＤと同じである）パケットなどのアドバタイジングパケットを送信する。そして、ＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤパケットは、特定のマスターデバイスに向けられ、ターゲットマスターデバイスの媒体アクセス制御（ＭＡＣ）アドレスを含む。ＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤパケットは、スレーブデバイスが、接続を確立するためその特定のマスターデバイスへの接続を所望していることを示す。ＡＤＶ＿ＩＮＤパケットは、任意特定のマスターデバイスに特定のものではなく、スレーブデバイスの存在を示す。
【００２０】
図１は、２つのワイヤレスデバイス１０及び２０を示す。ワイヤレスデバイス１０はマスターデバイスであり、ワイヤレスデバイス２０はスレーブデバイスである。上述のように、マスター及びスレーブデバイス１０、２０間の接続を確立するため、スレーブデバイス２０がアドバタイジングパケットを送信し、アドバタイジングパケットは、マスター１０により受信される場合、マスターデバイスにスレーブデバイス２０の存在を示す。マスターデバイス１０は、スキャン要求（ＳＣＡＮ＿ＲＥＱ）パケットで応答し得る。スレーブデバイス２０は、接続確立前に必要な場合、付加的なデータを提供するためスキャン応答（ＳＣＡＮ＿ＲＳＰ）でパケットＳＣＡＮ＿ＲＥＱに応答する。マスター及びスレーブデバイス１０、２０はそのため接続を確立する前の情報交換に関与する。
【００２１】
図２はスレーブデバイス２０のブロック図を示す。図示するように、スレーブデバイス２０は、コントローラ２２、トランシーバ２４、アンテナ２６、及びバッテリー２８を含む。バッテリー２８は、電力をコントローラ２２及びトランシーバ２４に提供する。トランシーバ２４は、アンテナ２６を介してワイヤレスに送信するため、コントローラ２２から信号を受け取る。同様に、アンテナ２６により受信されたワイヤレス信号が、処理のためトランシーバ２４によりコントローラ２２に提供される。そのため、トランシーバ２４は、マスターデバイス１０などの別のワイヤレスデバイスとの双方向データ通信ができる。コントローラ２２はまた、ソフトウェアを実行するプロセッサを含み得る。コントローラ２２は、好ましくは、スレーブデバイス２０に帰するように本明細書に記載の機能性の幾つか又は全てを実行する。図２に示したアーキテクチャは、マスターデバイス１０を実装するためにも用いられ得る。
【００２２】
ＢＬＥプロトコルにおいて、チャネル３７、３８、及び３９（「チャネルインデックス」と呼ぶこともある）は、アドバタイジングパケット及び関連する応答の送信専用である。マスターデバイス１０は、各アドバタイジングチャネルで時間のスキャンウィンドウインタバル（「ｓｃａｎＷｉｎｄｏｗ」）を聞く。スキャンインタバル（「ｓｃａｎＩｎｔｅｒｖａｌ」）は、２つの連続するスキャンウィンドウ間の時間と定義される。各ｓｃａｎＩｎｔｅｒｖａｌの間、マスターデバイス１０は、スケジュールコンフリクトがない限りｓｃａｎＷｉｎｄｏｗインタバルを聞く。マスターデバイスは、ｓｃａｎＷｉｎｄｏｗインタバルの間それを受信するＡＤＶ＿ＩＮＤ又はＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤパケットに応答する。
【００２３】
図３及び図４は、ＢＬＥスレーブからのアドバタイジングパケットに対するＢＬＥマスター応答の例を図示する。図３は、上述のような目的専用の３つのアドバタイジングチャネルインデックス３７〜３９の各々においてＡＤＶ＿ＩＮＤパケットを送信するスレーブデバイス２０を図示する。３つの専用アドバタイジングチャネルインデックスの各々においてアドバタイジングパケットを送信することを、本明細書ではアドバタイジングパケットの「ラウンド」と称する。図３において、マスターデバイス１０は、チャネルインデックス３７及び３９におけるアドバタイジングパケット３０及び５０に応答しないが、接続を確立するためスレーブデバイス２０から付加的な情報を要求するスキャン要求（ＳＣＡＮ＿ＲＥＱ）フレーム４２でチャネルインデックス３８においてアドバタイジングパケット４０に応答する。スレーブデバイスは、全てのこのような要求された情報を提供するためスキャン応答（ＳＣＡＮ＿ＲＳＰ）フレーム４４で応答する。
【００２４】
図３の例において図示するように、ＡＤＶ＿ＩＮＤアドバタイジングパケット３０、４０、及び５０は、一つずつ、最大１０ｍｓｅｃのインタバルで、送信される。そのため、アドバタイジングパケットのラウンドは最大で３０ｍｓｅｃかかる。
【００２５】
マスターデバイス１０がアドバタイジングパケットを聞くスキャンウィンドウは、スキャンインタバルの一部である。スキャンインタバルの残りの部分の間、マスターデバイス１０はスレーブデバイスからのアドバタイジングパケットに応答しないため、スキャンインタバルのこの部分を本明細書では「デッド」時間と称する。ｓｃａｎＷｉｎｄｏｗインタバルが終了した後（即ち、デッドタイムの間）スレーブデバイスがアドバタイジングパケットを送信し始める場合、ｓｃａｎＷｉｎｄｏｗの外側のスキャンインタバルの部分の間、スレーブデバイスは、マスターデバイスにより返答されない３（ｓｃａｎＩｎｔｅｒｖａｌ−ｓｃａｎＷｉｎｄｏｗ）／３０ｍｓｅｃ程度のアドバタイジングパケットを送信し得る。そのため、これらのアドバタイジングパケットはスレーブデバイスによりエネルギーを浪費する。
【００２６】
図４において、スレーブデバイスは、ディレクティッドアドバタイジングフレーム（ＡＤＶ＿ＤＩＲ＿ＩＮＤ）を特定のマスターデバイスに送る。マスター及びスレーブデバイスのペアが何らかの前の時間に既に接続され得るが、この接続は失われているか又は何らかの理由で終了される可能性がある。任意のレートにおいて、スレーブデバイスは、同じマスターデバイスへの接続の再確立を所望する。図４の例において、マスターデバイスは、第１の２つのＡＤＶ＿ＤＩＲ＿ＩＮＤフレーム６０及び７０に応答しないが、第３のＡＤＶ＿ＤＩＲ＿ＩＮＤフレーム８０に、接続特定情報をスレーブに搬送する接続セットアップ要求フレーム（ＣＯＮＮ＿ＳＥＴＵＰ＿ＲＥＱ）８４で応答する。
【００２７】
図４の例において図示するように、ＡＤＶ＿ＤＩＲ＿ＩＮＤアドバタイジングパケット６０〜８０は、３．７５ｍｓｅｃの時間期間で送信される全ての３つのパケットで送信される。そのため、マスター特定アドバタイジングパケットのラウンドは３．７５ｍｓｅｃかかる。スレーブデバイスがｓｃａｎＷｉｎｄｏｗインタバルが終了した後アドバタイジングパケットを送信し始める場合、スレーブデバイスは、３×（ｓｃａｎＩｎｔｅｒｖａｌ−ｓｃａｎＷｉｎｄｏｗ）／３．７５ｍｓｅｃ程度のＡＤＶ＿ＤＩＲ＿ＩＮＤフレームを送信し得、これらのフレームはマスターデバイスに回答されないためエネルギーを浪費する。
【００２８】
上述の例は、各ウィンドウインタバルの、回答されないアドバタイジングフレームを送信するためスレーブがエネルギーを費やす部分（「デッド」時間）があることを図示する。本発明の好ましい実施例に従って、スレーブデバイスは、マスターデバイスがスレーブデバイスのアドバタイジングフレームに応答しない可能性がある時間期間の間ほど多くのアドバタイジングフレームを送信しない。スレーブデバイスに対する接続セットアップを改善するため本発明の種々の実施例を説明する。そのような実施例は電力節約となる。
スレーブデバイスによるスキャンインタバル推定
【００２９】
一実施例において、スレーブデバイス２０は、マスターデバイスからアドバタイジングパケットに対する応答、又はその欠落に基づいて、スキャンウィンドウ及びスキャンインタバル時間期間を推定する。スレーブデバイスはその後、推定されたスキャンウィンドウ及びスキャンインタバル値を、マスターデバイス１０との将来の接続を確立するために用いる。
【００３０】
図５は、所与のマスターに対するスキャンウィンドウ及びスキャンインタバルのサイズを推定するための方法１００を図示する。図５に示すアクションは、図示した順で又は異なる順で実行され得る。また、２つ又はそれ以上のアクションが、順次にではなく並行して実行され得る。図５に示す方法は、スレーブデバイス２０によって一度に実行されるキャリブレーションルーティンであるが、スレーブデバイスは、所望なように２度以上キャリブレーションルーティンを実行することができる。図５に示したキャリブレーションルーティンの終わりにおいて、スレーブデバイスは、マスターのスキャンウィンドウ及びスキャンインタバルの推定を演算し終わり得る。
【００３１】
図６を簡単に参照すると、３つのスキャンウィンドウ１１５、１１２、及び１１９が示されている。スキャンインタバルも示されている。図５の方法１００を説明しながら図６を参照する。１０２において、スレーブデバイス２０はＡＤＶ＿ＩＮＤパケットを送信し始める。図５において、アドバタイジングパケットを送信するという言及は、好ましくは、種々のアドバタイジングパケットにおけるアドバタイジングチャネルのラウンドを送信することを意味する。第１のこのようなパケットを図６の例において１２０で示す。マスターデバイスがそのスキャンウィンドウにより定義されるそのスキャニングモードにある一方で、図らずもＡＤＶ＿ＩＮＤパケットが送信された場合、スレーブデバイス２０は、マスターデバイス１０から応答（例えば、ＳＣＡＮ＿ＲＥＱ）を受信し得る。しかし、スレーブデバイス２０は、スキャンウィンドウのどの部分においてＡＤＶ＿ＩＮＤパケットが送られたかをまだ知らない。一方、スレーブデバイス２０は、マスターデバイスがＡＤＶ＿ＩＮＤパケットに応答しないスキャンウィンドウ間の「デッド」時間の間、ＡＤＶ＿ＩＮＤパケットを送った可能性がある。またこの状況において、スレーブデバイスは、デッドタイムのどの部分においてそれがＡＤＶ＿ＩＮＤパケットを送ったかを知らない。スレーブデバイス２０が判定することができるのは、デッドタイムの間又はスキャンウィンドウの間にＡＤＶ＿ＩＮＤパケットが送られたか否かである。
【００３２】
ＡＤＶ＿ＩＮＤパケットに対する応答が受信されない（１０４）場合、これは図６におけるＡＤＶ＿ＩＮＤパケット１２０の場合であり得るが、スレーブデバイス２０は、デッドタイムの間アドバタイジングパケットが送られたと判定する。スレーブデバイス２０は、次のスキャンウィンドウの始めを見つけようと試みており、そのため、スレーブデバイスは、応答がマスターデバイスから受信されるまで、付加的なアドバタイジングパケットを反復的に送り、これは、スキャンウィンドウ１１２の始めにおいてスレーブデバイスがアドバタイジングパケット１２２を送信した結果起こり得る。
【００３３】
スレーブデバイス２０が、マスターから応答（例えば、ＳＣＡＮ＿ＲＥＱ）を最終的に受信するとき、スレーブデバイスは、それが現在スキャンウィンドウにあると判定する。このように、１０６においてスレーブデバイスは、応答が受信された又はアドバタイジングパケット１２２が送信された時間を記録する。記録される時間は、スキャンインタバルの始め及びスキャンウィンドウ１１８の始めの推定である。代替の実施例において、スレーブデバイスは、スキャンウィンドウの長さを測定するためのタイマー、及びスキャンインタバルの長さを測定するための別個のタイマーを開始し得る。
【００３４】
スレーブデバイス２０はスキャンウィンドウ及びスキャンインタバルの始めを見つけたため、スレーブデバイスは、スキャンウィンドウの終わり（具体的には、図６においてスキャンウィンドウ１１２の終わり）を見つける試みにおいて１０８でアドバタイジングパケットを送信し続ける。アドバタイジングパケットに対する応答が受信される（１１０）限り、スレーブデバイスは、マスターがまだスキャニングモードにある（即ち、まだスキャンウィンドウにある）と判定する。図６の例において、マスター応答は、アドバタイジングパケット１２４、１２６、及び１２８に対し受信される。
【００３５】
スレーブデバイスがアドバタイジングパケットに対する応答の受信に失敗するとすぐ、スレーブデバイスは、それがスキャンウィンドウを出て、デッドタイムの始めを見つけたと判定する。図６において、スレーブデバイスは、アドバタイジングパケット１３０に対する応答を受信しない。この判定が成されると、スレーブデバイス２０は再び、スキャンウィンドウの終わりを示すか、又はタイマーが用いられる場合はスキャンウィンドウタイマーを停止する時間（１１２）を記録する。スレーブデバイス２０はここで、開始時間を終了時間から減じること又はタイマーの時間値を記すことにより、スキャンウィンドウの長さを推定し得る。
【００３６】
スレーブデバイス２０は、次のスキャンウィンドウ１１９の始めでもある、デッドタイムの終わりを見つける試みにおいて、１１４でアドバタイジングパケットを送信し続ける。応答が受信されない（１１６）限り、スレーブデバイスは、それがまだデッドタイムにあると判定し、アドバタイジングパケットを送り続ける。スレーブデバイスがデッドタイムで送信し得、そのため応答のない最後のアドバタイジングパケットは、パケット１３２である。次のパケット１３４が次のスキャンウィンドウ１１９で送信され、そのため、応答が、マスターデバイスにより生成され得、スレーブデバイスにより受信され得る。この時点で、スレーブデバイス１１８は再び、スキャンインタバルの終わりを示すか又はスキャンインタバルタイマーを停止する時間を記録する。スキャンインタバルの長さは、（パケット１２２に対して）１０６において記録された開始時間を、１１８において記録された終了時間から減算することにより推定され得る。代替として、スキャンインタバルは、タイマーが用いられる場合、スキャンインタバルタイマーにおける時間値であってもよい。
【００３７】
上述の推定プロセスは特定のマスターデバイスに関連する。スレーブデバイスのワイヤレスに近辺に一つ以上のマスターデバイスがある場合、スレーブデバイスは、応答機アドレスに（スキャン要求又は別フレームのいずれかに）基づいてこのようなマスターデバイスを区別することができる。スレーブデバイスは、この目的のため各マスターデバイスに対し異なるタグを維持し得る。
【００３８】
スキャンウィンドウ及びインタバルは、アドバタイジングチャネルの全てにわたって測定された時間値の最大として推定され得る。所望とされる場合、各チャネルに対し別個の統計を用いることもできる。また、スキャンウィンドウ及びスキャンインタバルの推定は、精度を改善するため増大され得る。例えば、１００ｍｓｅｃのｓｃａｎＷｉｎｄｏｗ値及び種々のアドバタイジングチャネルにおけるパケットのラウンド内のＡＤＶ＿ＩＮＤパケット間のインタバルでは、つくられ得る最大誤差は３０ｍｓｅｃである。しかし、ＡＤＶ＿ＩＮＤパケット間のインタバルが５ｍｓｅｃまで低減される場合、最大誤差は約１５ｍｓｅｃである。これは精度が７０％から８５％まで増大され得ることを意味する。スキャンウィンドウに対する推定は、図５のプロセスにおいて判定されたものから最大誤差の量だけ増大され得る。
【００３９】
図７は、ＡＤＶ＿ＩＮＤパケットの送信をいつ中止するかを判定するために、スレーブデバイス２０が、推定されたスキャンウィンドウ及びスキャンインタバルをどのように用いるかを図示する方法１４０を示す。図７に示すアクションは、図示した順で又は異なる順で実行され得る。また、２つ又はそれ以上のアクションが、順次にではなく並行して実行され得る。
【００４０】
１４２で、スレーブデバイス２０は、アドバタイジングパケットのラウンドを送る。ＢＬＥの場合、これは、スレーブデバイスが３つのアドバタイジングチャネル３７〜３９の各々において単一のＡＤＶ＿ＩＮＤパケットを送っていることを意味する。１４４で判定されるように、ＡＤＶ＿ＩＮＤパケットの任意のものに対するスキャン要求応答（ＳＣＡＮ＿ＲＥＱ）をスレーブデバイスが受信する場合、１４６で接続が確立される。しかし、ＡＤＶ＿ＩＮＤパケットの任意のものに対するスキャン要求応答をスレーブデバイスが受信しない場合、１４８で、スレーブデバイスは、ＡＤＶ＿ＩＮＤパケットのラウンドを送信するために要求される時間より単一のアドバタイジングチャネルにおいて単一のＡＤＶ＿ＩＮＤパケットを送信するために要求される時間だけ短いものよりも、推定されたスキャンウィンドウが大きいか否かを判定する。１４８での判定が「ＮＯ」である場合、制御ループは１４２に戻り、スレーブデバイスはアドバタイジングパケットの別のラウンドを送る。
【００４１】
しかし、ＡＤＶ＿ＩＮＤパケットのラウンドを送信するために要求される時間より単一のアドバタイジングチャネルにおいて単一のＡＤＶ＿ＩＮＤパケットを送信するために要求される時間だけ短いものよりも、推定されたスキャンウィンドウが実際に大きい場合、１５０で、スレーブデバイスはＡＤＶ＿ＩＮＤパケットを送信することを一時的に中止する。具体的には、スレーブデバイスは、推定されたスキャンウィンドウから、ＡＤＶ＿ＩＮＤパケットのラウンドを送信するために要求される時間より単一のアドバタイジングチャネルにおいて単一のＡＤＶ＿ＩＮＤパケットを送信するために要求される時間だけ短いものを減じたものに等しい時間の期間、アドバタイジングパケットを送信することを停止する。スレーブデバイスがアドバタイジングパケットを送信することを中止する時間期間の満了後、スレーブデバイスは、マスターデバイスが現在スキャンウィンドウにあり、且つ、アドバタイジングパケットを受信する用意ができている場合にアドバタイジングパケットを送信し続ける。
スキャンインタバル情報のマスター始動更新
【００４２】
スレーブデバイスが送信するアドバタイジングパケットの数を低減するための別の実施例が、接続セットアップの時に又はスキャン更新手順を介する接続事象の間、マスターデバイスのためにそのスキャニングインタバルをアドバタイズすることである。
【００４３】
例えば、マスターデバイスは、スレーブへの接続が確立される前にそのスキャンウィンドウインタバルの間異なるチャネルアドバタイジングインデックスでスキャン更新フレームを送り得る。図８は、この点で用いることができるフレーム２００フォーマットを図示する。フレームは、そのスキャンウィンドウインタバルの間マスターデバイスにより送信されたＡＤＶ＿ＳＣＡＮ＿ＩＮＤフレームであり得る。代替として、フレームタイプ０１１１又は１１１１など、予めリザーブされたフレームタイプが用いられてもよい。
【００４４】
図６に示すフレームは、マスターデバイス１０により生成され、スレーブデバイス２０に送信されるスキャン更新フレームである。図８に示す例示のフレーム２００は種々のフィールドを含み、種々のフィールドは、プリアンブルフィールド２０２、アクセスアドレスフィールド２０４、ヘッダーフィールド２０６、アドバタイジングアドレス（ＡｄｖＡ）フィールド２０８、ｓｃａｎＷｉｎｄｏｗフィールド２１０、ｓｃａｎＩｎｔｅｒｖａｌフィールド２１２、ｓｃａｎＰａｒａｍｅｔｅｒｓＳｔａｒｔＴｉｍｅフィールド２１４、ｓｃａｎＰａｒａｍｅｔｅｒｓＥｎｄＴｉｍｅフィールド２１６、及び巡回冗長検査（ＣＲＣ）フィールド２０８を含む。
【００４５】
プリアンブルフィールド２０２は無線同期化に用いられる情報を含む。アクセスアドレスフィールド２０４は物理的リンク識別に用いられる。ヘッダーフィールド２０６は、プロトコルデータユニット（ＰＤＵ）のタイプを含む。例えば、ＰＤＵタイプは、ＡＤＶ＿ＳＣＡＮ＿ＩＮＤパケットタイプを示すため０１１０に設定され得る。Ａｄｖフィールド２０８はマスターアドレスに用いられる。ＣＲＣフィールドは、ＰＤＵにおけるデータの正しさを保証する。
【００４６】
ｓｃａｎＷｉｎｄｏｗフィールド２１０及びｓｃａｎＩｎｔｅｒｖａｌ２１２は、マスターに対し、それぞれ、ｓｃａｎＷｉｎｄｏｗ及びｓｃａｎＩｎｔｅｒｖａｌの長さの値を含む。ｓｃａｎＰａｒａｍｅｔｅｒＳｔａｒｔＴｉｍｅフィールド２１４及びｓｃａｎＰａｒａｍｅｔｅｒｓＥｎｄＴｉｍｅフィールド２１６は、対応するｓｃａｎＷｉｎｄｏｗ及びｓｃａｎＩｎｔｅｒｖａｌ値が有効である開始及び終了時間を含む。
【００４７】
マスターデバイス１０は、マスターデバイスに現在接続されるスレーブデバイス２０にスキャン更新フレームを送信し得る。例えば、新たなスレーブがネットワークにジョインした可能性があり、マスターデバイスがスキャンインタバルを更新する必要があるため、マスターデバイス１０はこのような更新フレームを送り得る。これは、予めセットアップされたスキャンインタバルに優先し得る。このような更新フレームは、（アドバタイジングチャネルではなく）データチャネルの間送信されるべきであり、そのため、リザーブされたフレームタイプ（例えば、００ｂ）と予め示される新たなフレームタイプであり得る。代替として、サブタイプがｓｃａｎ＿ｕｐｄａｔｅ情報である、既存のフレームタイプが用いられてもよい（例えば、ＬＬ制御ＰＤＵ）。一例において、ＬＬ制御ＰＤＵのヘッダーにおけるオペコードフィールドは、ＬＬ＿ＳＣＡＮ＿ＵＰＤＡＴＥと示される新しいサブタイプ（例えば、０ｘ０Ｅ）を定義し得る。何れの場合も、スキャンインタバル更新フレームのペイロードは、ｓｃａｎＷｉｎｄｏｗ、ｓｃａｎＩｎｔｅｒｖａｌ、ｓｃａｎＰａｒａｍｅｔｅｒＳｔａｒｔＴｉｍｅ、及びｓｃａｎＰａｒａｍｅｔｅｒｓＥｎｄＴｉｍｅを含む。
【００４８】
マスターデバイスとスレーブデバイスとの間の任意の将来の接続セットアップは、前述の更新フレームのうち任意のもの（例えば、フレーム２００）においてこのようなスレーブに予め提供される情報に基づき得る。図９はタイムラインを図示し、このタイムラインは、パケット２００におけるｓｃａｎＰａｒａｍｅｔｅｒＳｔａｒｔＴｉｍｅフィールドにより特定される開始時間（図９で「Ｓ」と示される）、パケット２００におけるｓｃａｎＰａｒａｍｅｔｅｒｓＥｎｄＴｉｍｅフィールドにより特定される終了時間（「Ｅ」）、及び現在の時間（「ＣＴ」）を有する。Ｓ及びＥの値は、更新フレーム（例えば、フレーム２００）において提供される。このタイムラインは、スキャンウィンドウ２５０及びスキャンインタバル（ＳＩと示される）を図示する。現在の時間（ＣＴ）は、図９の例において２つのスキャンウィンドウの間であり、そのため、マスターデバイスがスレーブデバイスアドバタイジングパケットを聞いていないデッドタイムに、示されている。図１０は、現在の時間（ＣＴ）がスキャンウィンドウ２５０内に置かれるタイムライン例を提供する。
【００４９】
現在の時間がスキャンウィンドウ間のデッドタイムにある場合に、マスターデバイスのスキャンウィンドウ２５０の開始をスレーブデバイスが推定し得る。現在の時間及びｓｃａｎＰａｒａｍｅｔｅｒｓＳｔａｒｔＴｉｍｅ（Ｓ）を、開始時間以降現在の時間までに経過したｓｃａｎＩｎｔｅｒｖａｌ（ＳＩ）の数を演算するために用いることができる。図９及び図１０は、経過した時間インタバル（ＥＴＩ）を示し、これは下記のように演算され得る。
ＥＴＩ＝［（ＣＴ−Ｓ）／ＳＩ］×ＳＩ
【００５０】
直前のスキャンウィンドウ２５０から現在の時間までに残る時間は、図９及び図１０にＲＥＭとして示し、下記のように演算される。
ＲＥＭ＝ＣＴ−［Ｓ＋ＥＴＩ］
残りの時間（ＲＥＭ）はその後、更新フレームにおいて提供されるスキャンウィンドウ（ＳＷ）の長さと比較される。ＲＥＭがスキャンウィンドウより大きい場合（これは図９の場合である）、スレーブデバイスは次のスキャンウィンドウの始めまで待機することが好ましく、次のスキャンウィンドウは、（ＣＴ＋ＳＷ−ＲＥＭ）で起こり得、図９にＴＴＮＳＷ（次のスキャンウィンドウまでの時間）として示す。図１０の場合、ＲＥＭがスキャンウィンドウより小さく、これは、現在の時間がスキャンウィンドウの中間にあることを示している。この場合、スレーブデバイスは、ＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤ（又はＡＤＶ＿ＩＮＤ）フレームを、それが前に接続されていたマスターデバイスに送る。
【００５１】
図１１は対応する方法２６０を図示する。図１１に示したアクションは、図示した順で又は異なる順で実行され得る。また、２つ又はそれ以上のアクションが、順次にではなく並行して実行され得る。
【００５２】
２６２で、スレーブデバイス２０はＥＴＩをｆｌｏｏｒ（（ＣＴ−Ｓ）／ＳＩ）×ＳＩとして演算する。２６４で、スレーブデバイスはＲＥＭをＣＴ−［Ｓ＋ＥＴＩ］として演算する。２６６で、スレーブデバイス２０は、ＲＥＭがＳＷ（スキャンウィンドウ長さ）より大きいか否かを判定する。ＲＥＭがＳＷより小さい場合、２６８で、スレーブデバイスはアドバタイジングパケットを送信する。
【００５３】
しかし、ＲＥＭがＳＷより大きい場合、スレーブデバイスは、２７０で、ＮＳＷをＣ＋ＳＩ−ＲＥＭとして演算し、スレーブデバイスがマスターのスキャンウィンドウにあることを保証するため２７２でＮＳＷ時間期間待機する。ＮＳＷ時間待機した後、２７４で、スレーブデバイスはアドバタイジングパケットを送信する。
【００５４】
接続セットアップのための最大レイテンシーは（ＳＩ−ＳＷ）である。ただし、このインタバルの間、スレーブデバイス２０は、接続をセットアップするためにＡＤＶ＿ＩＮＤ又はＡＤＶ＿ＤＩＲＥＣＴ＿ＩＮＤフレームを送る必要はないことが好ましい。スレーブデバイスは、ＲＥＭ＜ＳＷである場合、送信されたフレームについて衝突はないと仮定して、マスターデバイスとの接続を確立するために３つのフレームを必要とし得る。
【００５５】
また、スケジュールコンフリクトに起因して、マスターデバイス１０は、幾つかのスキャンウィンドウの間スキャニングを実行することができない可能性があることがあり得る。マスターデバイスは、接続セットアップフェーズにおいて、又はパケット２００に付加され得る付加的なフィールドを介する接続事象の間、この情報を搬送することができる。このシナリオにおいて、マスターは、時間オフセット及び時間オフ期間を導入し得る。時間オフセットは、時間オフ期間が開始するｓｃａｎＷｉｎｄｏｗインタバル内の開始時間を示す。時間オフ期間の間、マスターは、ネットワークにおける他のスレーブデバイス（例えば、既に確立された接続事象の間の送信／受信パケット）をサーブし得る。
【００５６】
接続セットアップフェーズの間パケットが搬送される場合、時間オフセット及び時間オフは、接続がまだ確立されていないため、恐らく、現在のスレーブを含まないネットワークにおける他のスレーブデバイスに対するものである。接続事象の間パケットが搬送される場合、パケットは、現在のスレーブデバイスを含み得るネットワークにおける他のスレーブデバイスに対する時間オフセット及び時間オフを搬送する。現在のスレーブデバイスを含むことは、マスターデバイスにおける手順を簡易化し得、スキャン更新されたパラメータを搬送するため異なるＢＬＥスレーブに異なるパケットペイロードを送らないこととなり得る。
【００５７】
スキャンインタバルの一層細かい粒度で助け／搬送し得る、付加的なフィールドが付加され得ることに留意されたい。フィールドの期間は、付加される新しいフィールドに対応するよう変更し得る。例えば、付加的なフィールドは、スキャンインタバルが、異なる期間の複数のスキャンウィンドウ、及び各このようなスキャンウィンドウの期間を含むことを特定し得る。更なる例として、付加的なフィールドは、複数の交番するスキャンインタバルがそれら自体の開始及び終了時間で実装されることを特定し得る。
【００５８】
幾つかの実施例において、スキャン更新情報を搬送するために複数のパケットが送られ得る。この情報は、ネットワークにおけるスレーブデバイス毎の付加的な時間オフセット及び時間オフフィールド、又はスキャンインタバルを知るためスレーブデバイスを助け得る任意の他の情報を含み得る。これらのシナリオのもとで、更なるデータビット、及び／又はスキャン更新情報を必要とする付加的なパケットが、パケットタイプの直後に含まれ得る。これは、異なるスレーブデバイスが、ｓｃａｎＷｉｎｄｏｗインタバルにおいて単に「パンチホール」する異なる接続インタバルを有するシナリオに適応し得る。
【００５９】
当業者であれば、本発明の特許請求の範囲内で、説明した例示の実施例に変形が成され得ること、及び多くの他の実施例が可能であることが分かるであろう。
【図１】
2014518492.tif 000003
【図２】
2014518492.tif 000004
【図３】
2014518492.tif 000005
【図４】
2014518492.tif 000006
【図５】
2014518492.tif 000007
【図６】
2014518492.tif 000008
【図７】
2014518492.tif 000009
【図８】
2014518492.tif 000010
【図９】
2014518492.tif 000011
【図１０】
2014518492.tif 000012
【図１１】
2014518492.tif 000013
【国際調査報告】
2014518492.tif 000014
2014518492.tif 000015