図面中の対応する要素は、同じ参照番号によって示される。
図1は、本発明のシステム及び電子デバイスの実施形態を示す。図1の実施形態では、ブリッジ1は、本発明のワイヤレスネットワーク内のメッセージルーティングを制御するためのシステム並びに本発明の存在及び/又は位置検出のための無線周波数信号を送信、受信及び/又は処理するためのワイヤレスネットワーク内の1つ以上のデバイスを選択するためのシステムの機能性を組み合わせている。代替的な実施形態では、ブリッジ1は、これら2つの機能性のうち1つのみを実装する。異なる実施形態では、システムは、異なるタイプのデバイスに実装される。各システムは、1つ以上のデバイスを含んでもよい。
図1の実施形態では、本発明の2つの電子デバイス、照明デバイス11及び12が示されている。図1には、他の3つの照明デバイス、照明デバイス13、14及び15が示されている。照明デバイス11は、Hue go照明器具であり、照明デバイス12は、LEDストリップを含み、照明デバイス13は、シーリングランプであり、照明デバイス14は、フロアスタンド型ランプであり、照明デバイス15は、テーブルランプである。図1の実施形態では、照明デバイス13~15は、照明デバイス11及び12とは異なり、期間の第1の部分でRFベースのセンシング又はアセットトラッキングを行い、この期間の第2の部分でネットワークメッセージを取得するように構成されていない。代替的な実施形態では、照明デバイス13~15も、照明デバイス11及び12と同様に、期間の第1の部分でRFベースのセンシング又はアセットトラッキングを行い、この期間の第2の部分でネットワークメッセージを取得するように構成される。ブリッジ1及び照明デバイス11~15は、無線メッシュネットワークを形成し、ノードとも呼ばれる。
ブリッジ1は、プロセッサ5、トランシーバ3及びメモリ7を備える。プロセッサ5は、照明デバイス11~15の第1のサブセットを決定するように構成される。第1のサブセットは、無線周波数ベースの存在及び/又は位置検出機能を割り当てられる1つ以上のデバイスを含む。プロセッサ5はさらに、ソースノード(source node)からデスティネーションノード(destination node)への複数のルートを決定するように構成される。複数のルートのうちの少なくとも1つは、1つ以上の中間ノードを含む。プロセッサ5はさらに、複数のルートの各々の中間ノードのうちのいくつが複数のノードの第1のサブセットの一部であるかに基づいて複数のルートのうちの1つを選択し、ワイヤレスメッシュネットワークに選択されたルートに従ってメッセージルーティングを行わせるために1つ以上のメッセージを送信するためトランシーバ3を使用するように構成される。
一部の無線規格、例えば、Zigbeeでは、さまざまなルーティングメカニズムが利用可能及び/又はアクティブであることができる。これらのうちの一部は、送信デバイスによって決定され(ソースルーティング:送信者がメッセージのために使用されるべきパスを指示する)、これらのうちの一部は、Zigbeeネットワーク内のノードが送信及び受信されるメッセージに基づいてルーティングテーブルを構築する分散態様(distributed fashion)で決定される(AODVルーティング)。前者の場合、プロセッサ5は、特定のルートを使用するように送信デバイスに(例えば、Manufacturer Specificメッセージを介して)指示することができる。後者の場合、プロセッサ5は、例えば、ルーティングコストを意図的に調整することによって、前段落で述べられるような好ましいルートが達成される(又は奨励される)ように、及び/又は不要な経路が回避される(又は阻止される)ように、この分散プロセスに影響を与えるように様々なZigbeeノードに指示するためにManufacturer Specificメッセージを送信することによって、ルーティングに影響を与えることができる。別のメカニズムは、ノードの役割(NCN/BRM)、及び場合によっては近隣デバイスの役割が、ノードが行うルーティング決定(及び/又はノードがアナウンスするルーティングコスト)に影響を与え、斯くして、近隣デバイスのルーティング決定にも影響を与えるために使用されることである。
プロセッサ5はさらに、存在及び/又は位置検出のための無線周波数信号を送信、受信及び/又は処理するための照明デバイス11~15の各々の適合性を決定する、複数のデバイスの各々について決定される適合性に基づいて複数のデバイスからデバイスのサブセットを選択する、及び、存在及び/又は位置検出のための無線周波数信号を送信、受信、及び/又は処理するためのデバイスとして動作するようにデバイスのサブセットのうちの少なくとも1つに指示するように構成される。受信ライトがRFベースのセンシングに利用されるRSSIを決定することができる、送信されたワイヤレスメッセージのペイロードは、送信デバイス自身がネットワーク内の他のデバイスから先に受信した他のメッセージのRSSIデータのレポーティングを含んでもよい。したがって、RFベースのセンシングメッセージは、単なるダミーのペイロードだけではなく、意味のあるペイロードを有し得る。
照明デバイス11及び12は、プロセッサ25、トランシーバ23、メモリ27、及び光源29を備える。プロセッサ25は、複数の期間の各々の第1の部分の間に無線周波数信号を送信及び/又は受信するために第1のプロトコルを使用するように構成される。無線周波数信号は、存在及び/又は位置検出のために使用される。プロセッサ25はさらに、複数の期間の各々の第2の部分の間にワイヤレス送信されるネットワークメッセージを取得するために第2のプロトコルを使用するように構成される。第2の部分は、第1の部分とオーバーラップしない。第1の部分の持続時間は、複数の期間のうちの少なくとも2つの期間で異なり、及び/又は、第2の部分の持続時間は、複数の期間のうちの少なくとも2つの期間で異なる。
RFベースの存在検出は、RFベースのセンシングとも呼ばれる。RFベースのセンシングは、専用の送信機又は受信機を担持せず、信号を送信又は受信しないターゲットが検出される必要がある場合に使用されてもよい。RFベースの位置特定(又は位置検出)は、RFベースのアセットトラッキングとも呼ばれる(アセットは、例えば、物体、動物、又は人であってもよい)。RFベースのアセットトラッキングは、専用の送信機又は受信機を担持している又は組み込んでいるターゲット/アセットが検出及び/又は位置特定される必要がある場合に使用されてもよい。追跡されるアセットは、例えば、BLEビーコンを受信又は送信してもよい。RFベースのセンシングは、例えば、ネットワークの異なるノード間のワイヤレスリンクにおける受信信号強度又はその他のネットワーク診断データ(例えば、メッセージが成功裏に配信されるまでのリトライの数)の変化等、ワイヤレス通信システムの診断データ及び通信パラメータの動的な変化を分析することによって動き又は存在を検出する可能性を提供する。
図1に示されるブリッジ1の実施形態では、ブリッジ1は1つのプロセッサ5を含む。代替的な実施形態では、ブリッジ1は複数のプロセッサを含む。ブリッジ1のプロセッサ5は、例えばARMベースの、汎用プロセッサ、又は特定用途向けプロセッサであってよい。ブリッジ1のプロセッサ5は、例えば、Unixベースのオペレーティングシステムを実行してもよい。メモリ7は、1つ以上のメモリユニットを含んでもよい。メモリ7は、例えば、1つ以上のハードディスク及び/又はソリッドステートメモリを含んでもよい。メモリ7は、例えば、コネクテッドライトのテーブル(table of connected lights)を記憶するために使用されてもよい。
トランシーバ3は、ライトデバイスと通信するために1つ以上の通信技術、例えば、Zigbee、Thread及び/若しくはBluetooth、並びに/又は、無線LAN/インターネットアクセスポイント(図示せず)と通信するために1つ以上の有線若しくは無線通信技術、例えば、Ethernet若しくはWi-Fiを使用してもよい。代替的な実施形態では、単一のトランシーバの代わりに複数のトランシーバが使用される。図1に示される実施形態では、受信機及び送信機は、トランシーバ3に組み合わされている。代替的な実施形態では、1つ以上の別個の受信機構成要素及び1つ以上の別個の送信機構成要素が使用される。ブリッジ1は、電源コネクタ等のネットワークデバイスに典型的な他の構成要素を含んでもよい。本発明は、1つ以上のプロセッサで実行されるコンピュータプログラムを使用して実装されてもよい。
図1の実施形態におけるブリッジ1によって実行される機能の一部は、代替的な実施形態ではインターネットサーバによって実行される。これは、より洗練されたRFベースの存在検出アルゴリズム又はRFベースの人カウントに特に有益である。セキュリティクラスのユースケースでは、より長いレイテンシ(例えば、10秒)が典型的には許容されるが、照明クラスのユースケース(例えば、ライトをオンにする)では、0.5秒以下のレイテンシが望ましく、インターネットサーバへの往復が潜在的に問題となる。
図1に示される照明デバイス11及び12の実施形態では、照明デバイス11及び12は、1つのプロセッサ25を含む。代替的な実施形態では、照明デバイス11及び12は複数のプロセッサを含む。照明デバイス11及び12のプロセッサ25は、汎用プロセッサ、又は特定用途向けプロセッサであってよい。光源29は、例えば、1つ以上のLEDダイオードを含んでもよい。メモリ27は、1つ以上のメモリユニットを含んでもよい。メモリ27は、例えば、ソリッドステートメモリを含んでもよい。
図1に示される実施形態では、受信機及び送信機は、トランシーバ23に組み合わされている。代替的な実施形態では、1つ以上の別個の受信機構成要素及び1つ以上の別個の送信機構成要素が使用される。代替的な実施形態では、単一のトランシーバの代わりに複数のトランシーバが使用される。トランシーバ23は、ブリッジ1と通信するために1つ以上の無線通信技術、例えば、Zigbee、Thread及び/又はBluetoothを使用してもよい。ブリッジ11は、電源コネクタ等の照明デバイスに典型的な他の構成要素を含んでもよい。図1の実施形態では、本発明の2つの電子デバイスは、照明デバイスである。代替的な実施形態では、本発明の電子デバイスは、他のタイプのデバイス、例えば、照明システムに関連する非照明デバイス(存在/位置検出のために使用され得る無線センサ及びスイッチ等)、又は他の非照明デバイスである。
無線周波数信号を送信、受信及び/又は処理するための1つ以上のデバイスを選択する方法の第1の実施形態が図2に示されている。ステップ101は、存在及び/又は位置検出のための無線周波数信号を送信、受信及び/又は処理するための複数のデバイスの各々の適合性を決定することを含む。ステップ103は、複数のデバイスの各々について決定される適合性に基づいて複数のデバイスからデバイスのサブセットを選択することを含む。ステップ105は、存在及び/又は位置検出のための無線周波数信号を送信、受信、及び/又は処理するためのデバイスとして動作するようにデバイスのサブセットのうちの少なくとも1つに指示することを含む。ステップ105はさらに、ネットワークメッセージ、例えば、照明制御システムのメッセージ(例えば、消費電力のレポーティング)を送信するようにデバイスのサブセットのうちの少なくとも1つに指示することを含んでもよい。
ワイヤレス(例えば、メッシュ)ネットワーク内のメッセージルーティングを制御する方法の第1の実施形態が、図3に示される。ステップ111は、複数のノードの第1のサブセットを決定することを含む。第1のサブセットは、無線周波数ベースの存在及び/又は位置検出機能を割り当てられる1つ以上のデバイスを含む。ステップ113は、ソースノードからデスティネーションノードへの複数のルートを決定することを含む。複数のルートのうちの少なくとも1つは、1つ以上の中間ノードを含む。ステップ115は、複数のルートの各々の中間ノードのうちのいくつが複数のノードの第1のサブセットの一部であるかに基づいて複数のルートのうちの1つを選択することを含む。ステップ117は、ワイヤレスメッシュネットワークに選択されたルートに従ってメッセージルーティングを行わせるために1つ以上のメッセージを送信することを含む。これらのステップは、図1のブリッジ1に関連して述べたやり方で実行されてもよい。
無線周波数信号を送信、受信及び/又は処理するための1つ以上のデバイスを選択する方法並びにメッセージルーティングを制御する方法の第2の実施形態が図4に示されている。この第2の実施形態では、図2及び図3の方法が組み合わされる。ステップ101の後、図2のステップ103及び図3のステップ111の両方を含むステップ121が実行される。ステップ111は、ステップ103と同じステップであってもよく、又は、ステップ111は、例えば、ステップ103で決定されるサブセットからさらに狭いデバイスのサブセットを選択することを含んでもよい。ステップ121の後、図3に示されるステップ113及び115が実行される。
ステップ115の後、図2のステップ105及び図3のステップ117の両方を含むステップ123が実行される。ステップ105は、ステップ117と同じ、すなわち、1つ以上のメッセージが、存在及び/又は位置検出のための無線周波数信号を送信、受信、及び/又は処理するためのデバイスとして動作するようにデバイスのサブセットのうちの少なくとも1つに指示してもよい。斯くして、RFベースのセンシング又はアセットトラッキングを行う(又は行わない)ようにデバイスに指示する及びルーティング指示を含む単一のメッセージが、単一のデバイスに送信されてもよい。代替的に、ステップ117は、例えば1つ以上のネットワークノードのルーティングプロトコルを変更するために、異なるメッセージを送信することを含んでもよい。次に、ある時間又はイベントの後、例えば、ステップ101又はステップ121が再び実行されてもよい。第1の例として、ステップ101、121、113、115及び117は、まずコミッショニング中に実行され、後で再びコミッショニング後及び使用後に実行されてもよい。第2の例として、ステップ101、121、113、115及び117は、まずコミッショニング中に実行されてもよく、ステップ121、113、115及び123は、後で再びコミッショニング後及び使用後に実行されてもよい。
本発明のネットワークメッセージを取得する方法の第1の実施形態が図5に示されている。ステップ141は、複数の期間の各々の第1の部分の間に無線周波数信号を送信及び/又は受信するために第1のプロトコルを使用することを含む。無線周波数信号は、存在及び/又は位置検出のために使用される。ステップ143は、複数の期間の各々の第2の部分の間に第2のプロトコルを使用してワイヤレス送信されるネットワークメッセージを取得することを含む。第2の部分は、第1の部分とオーバーラップしない。第1の部分の持続時間は、複数の期間のうちの少なくとも2つの期間で異なり、及び/又は、第2の部分の持続時間は、複数の期間のうちの少なくとも2つの期間で異なる。
この方法は、例えば、図1の照明デバイス11及び12によって実行されてもよい。本発明のシステム、例えば、図1のブリッジ1は、本発明の方法を実行するようにネットワークノードに指示してもよく、場合によっては本発明の方法をどのように実行するかをネットワークノードに指示してもよい。この指示は、例えば、図4のステップ123の一部として送信されてもよい。本発明のシステムの代替的な実施形態では、ネットワークノードのいずれも、図5の方法を実行しない。
無線周波数信号を送信、受信及び/又は処理するための1つ以上のデバイスを選択する方法の第3の実施形態が図6に示されている。この第3の実施形態は、RFベースのセンシング(存在検出)アプリケーションで使用される。図6の実施形態では、以下の基準の1つ以上が、コミッショニング中にステップ101において個々のデバイスの適合性を決定するために評価されてもよい。
ハードウェア能力に関する基準
RFベースのセンシングへの参加は、典型的には、送信機が余分なワイヤレスメッセージを送信する及び受信機がRSSI(Received Signal Strength Indication)の分析及び保存を行うことを必要とする。これは、追加の処理及びメモリリソースを必要とし、したがって、利用可能な処理及びメモリリソースを評価することは有益である。
例えば、第1世代のPhilips Hue電球は、最新世代のPhilips Hue電球よりも性能の低いマイクロコントローラを使用している。後者は、より多くのメモリ及び処理リソースを備えており、RFベースのセンシングのためのアルゴリズムを実行し、より多くのシグネチャ(これらのシグネチャは、RSSIの変化が、例えば人の存在を判断するために、分類されることを可能にする)を保存することができる、又は、複数の検出アルゴリズムを並行して実行することができる(例えば、第1のアルゴリズムは、低レイテンシを持つ照明グレードの占有検出であり、第2のアルゴリズムは、家の所有者が留守の間に家の中に誰かが存在することを警告する、信頼性の高いセキュリティグレードのアルゴリズムである)。同じエリアに位置する2つの同一のHue電球の動作上の使用が異なる場合もある。例えば、第1のランプには1つのシーンしか保存されていなく、したがって、30のシーンが保存されている第2のランプに比べて空きメモリが多い。ランプのシーン数は静的なパラメータではなく、ユーザ/システムが変更する可能性があるため、典型的には、ランプの寿命にわたり変化する。また、利用可能なメモリの量は、ランプのソフトウェアアップデートにより変わることがある。
RFセンシングに適したワイヤレスビーム形状を作る等、適切なRF特性を有する照明器具タイプに関する基準
異なる照明器具形状及びRFデザインは、異なるRF特性、例えば、ワイヤレスビーム形状を招く。例えば、ガラス面を持つ天井照明器具は、メタルコーンテーブルランプとは異なるワイヤレスビーム形状を持つ。メタルコーン形状のシールドを有する第1のテーブルトップ照明器具内に配置される同じワイヤレスランプは、照明器具の外形は同じであるが、布製テキスタイルシールドを有する第2のテーブルランプと比較して、より狭いワイヤレスビームパターンをもたらす。したがって、照明器具をそのRF特性、例えば、RFベースのセンシング特性に関して分類することが有益である。これは、照明器具のモデル識別(例えば、「Philips Hue Beyond White luminaire」)又はユーザがランプが置かれている照明器具の写真をアップロードすることで行われることができる。照明器具のセンシング特性は、形状及び材料を分析すること、又は、それらをデータベースで調べることによって決定されてもよい。同じ照明器具でも異なる環境に設けられることができ、RF性能は、例えば、照明器具の上にあるコンクリートの床までの距離及びオフィスの天井の上にあるメタルパイプの存在等、環境の違いに左右され得るので、コミッショニング後に実際のRF性能を測定することも有益である。
干渉及び到達性(reachability)に関する基準
干渉及び到達性に関する基準を評価することは、RFベースのセンシングを行う照明デバイスの能力に影響を与える非照明デバイスによるワイヤレス干渉を受ける可能性がある、又はそのようなワイヤレス干渉を受けると(例えば、履歴データに基づいて)判断された照明デバイスを避けることを可能にする。例えば、RF放射を発する又はRF送信機を備える他のデバイス(例えば、テレビ又はWiFiアクセスポイント)の近くに位置する照明デバイスは、妨害を受ける可能性がある。例えば、電子レンジ及び電動工具は、スプリアス副作用(by-product)としてRF放射を発する。例えば、Philips Hueライトに対するテレビ等のエンターテインメントデバイスの位置は、Philips Hue Entertainment機能を設定する際にユーザによって提供されるマッピングに基づいて、カメラによって撮影される画像に基づいて、ライトの名前(例えば、「テレビライト」)に基づいて、BIM(Building Information Model)に基づいて、又は部屋の3Dモデルに基づいて決定されてもよい。
好ましくは、同じコンパクトな空間にある2つのライト等、互いに近すぎるライトは、(送信デバイス及び1つ以上の受信デバイスの)同じグループには含まれない。例えば、照明器具に5つのスポットが取り付けられ得る場合、それらのうちの2つをペアにしないことが有益である。なぜなら、人がそれらの間で検出信号を生成する可能性は非常に低いからである。
到達性は、2つのデバイスの間にある金属製のドアが閉じられる又は開いていることに起因して、場合によっては直接通信でき、場合によってはそうできない、2つのデバイス間のリンクステータスを指す。このようなリンクは、RFベースのセンシングが、(火災の拡大を防ぐために価値がある)自動防火扉が閉じられているか開いているかを監視するために使用されない限り、好ましくない。
エンドユーザの使用パターンに関する基準
・ エンドユーザの使用パターンに関する基準を評価することは、1日の大半がオンしている照明デバイスと対比して、オンとオフの間を遷移することが多い照明デバイス(例えば、センサ制御されるクローゼット照明)を選択しないことを可能にする。RFベースのセンシングにより導入されるレイテンシは、人にとって、ライトがオンからオフに遷移する場合よりも、ライトがオフからオンに遷移する場合にはるかに顕著である(例えば、ユーザが部屋に入りすぎて、暗闇の中で家具に衝突する場合がある)。
・ エンドユーザの使用パターンに関する基準を評価することは、ユーザが動的なライトシーン(特に、低レイテンシを必要とするシーン)のために最も使用する照明デバイスを選択しないことを可能にする。
・ エンドユーザの使用パターンに関する基準を評価することは、オフよりもオンされていることが多い照明デバイスを選択することを可能にする。RFセンシングは、処理に起因して遅延を発生させるので、ライトをオンに設定するための外部トリガは、ライトがすでにオンされている場合と比べて、ライトが以前にオフされていた場合に顕著な遅延を持つ可能性がある。
ネットワークの特定のローカルサブパート(local sub-part)又は特定のデバイスにおけるローカルに利用可能な空きデータレート(spare data-rate)に関する基準
・ 良好なRFベースのセンシング性能を得るために必要な、コントローラ及びペアリングされたランプ間の追加のRF信号を送信するためにネットワークに十分なヘッドルームがない(すなわち、空きデータレートが低い)場合、このコントローラはRFベースのセンシングにあまり適していない。例えば、コントローラのZigbee無線機は、すべてのライトとトーク(talk)する(すなわち、RFセンシングに関連しないトラフィックを送信及び/又は受信する)ので、多くのトラフィックを処理しなければならない。RFセンシングに関連しないトラフィックを送信することは、ライト制御コマンドを送信すること又はライトから高帯域のセンサデータをバックホール(backhaul)すること、例えば、PointGrabセンサが、室内の占有者の数及び室内で行われている作業タスク等の追加のコンテキストに関する豊富で精度の高いメトリックをゲートウェイに送信することを含んでもよい。RFセンシングに関連しないトラフィックを送信及び/又は受信することはさらに、例えば、異なるネットワークセクション間でのポーリング、レポーティング、センサデータの収集、及び/又はデータのプッシュを含んでもよい。コントローラのアグリゲータ機能は、その利用可能なTx/Rxリソースを少なくする可能性があるが、同じネットワーク内(ましては、その近傍)の他のZigbeeノードは、このような問題を持たない。したがって、大規模なネットワークでは、コントローラのZigbee無線はすでに最大容量に達している可能性があり、コントローラは、ワイヤレスライトとRFセンシングペアを形成するための良い候補ではなく、とりわけRFベースのセンシングのためのRF信号を送信するための良い候補ではない可能性があるが、集約されたRSSIデータを時折共有することは、状況によってはまだ可能であるかもしれない。しかしながら、コントローラは、RFセンシングペアのリスニングパート(listening part)として機能する、すなわち、各ライトから受信するメッセージのRSSIを記録するのに良い候補であるかもしれない。各ライトは、メッセージがこの特定のライトに宛てられたものであるかどうかに関わらず、コントローラから送られるすべてのメッセージのRSSIを記録してもよい。しかしながら、容量いっぱいまで(to capacity)コントローラの無線機に負荷をかけることは望ましくない。さもなくば、望ましくない照明制御レイテンシがシステムに導入されるからである(他のライトのペアは、アプリケーションの観点から遅延が重要ではないので、最大の無線容量に満たされてもよい)。
・ 建物若しくは建物のフロアの2つのサブエリア間の又はコントローラへのネットワーク通信パスで重要な役割を果たすランプの選択は、好ましくは避けられるべきである(例えば、階段にある1つの照明は、システムが上階のメディアルームと通信するための重要なルータである)。
・ 第1のランプが送信する一方、第2及び第3のランプはRSSIを記録することができる。第2又は第3のランプがRSSIをRFベースのセンシンググループのコーディネータと共有することによりレポートするかどうかは、RFベースのセンシンググループのコミッショニング中になされる選択に依存してもよい。第1のランプのヘッドルームだけが重要ではない。第2のランプは、第1のランプからある距離にあり、第1のランプとは異なるヘッドルームを持つかもしれない。第2のランプがそのRSSIをレポートする場合、そのヘッドルームも重要である。そのため、最大のヘッドルームを持つランプをRFベースのセンシングのためのRF信号の送信デバイスとして割り当て、帯域幅の少ない他のデバイスは主にメッセージを聞き、集約されたRSSIデータを時折レポートするだけにすることが有利であり得る。RFベースのセンシングに使用されるRF信号が短い持続時間を有する場合、送信デバイスは、最大のヘッドルームを持つデバイスである必要はない。この場合、最大のヘッドルームを持つランプをRFベースのセンシングのためのRF信号の受信デバイスとして割り当てることが有利であり得る。なぜなら、この場合、送信デバイスがRFベースのセンシングのためのRF信号を送信している一方、受信デバイスが他の信号を送信又は受信していない確率が最も高いからである。
・ 商業施設では、フロアごとに複数のWiFi対応ゲートウェイが使用され、各ゲートウェイがZigbeeライトのサブセットからのデータをクラウドにバックホールし、例えば、高度な機械学習及び分析(例えば、人カウント)のために、大量のRFベースのセンシングデータがクラウドにバックホールされる場合、クラウドバックホールのための最大の空き容量(spare capacity)を持つゲートウェイに接続されているライトが最も適している。
・ 異なるセンシングレートが空間のサブエリアに割り当てられることがある(例えば、自動ライトオン挙動が必要なエリアには高いレートが割り当てられ、ライトが既にオンされている空間の他のエリアには低いメッセージレートが割り当てられる)。典型的には、RFベースのセンシングアルゴリズムでは、複数の送信デバイスの各々が、1ループにつき1回、RF信号を送信する。しかしながら、送信デバイスに、1ループにつき複数回、RF信号を送信させることにより特定のエリアにおけるセンシングレートを高めることができる。例えば、通常の状況では、各センシングループは、ノード1、2、3、4、5からのメッセージを得る。センシングレートは、センシングループを1、2、2、3、4、5、5、5に変更することによって(ノード2及び5は入口に近いため、特別にスナッピー(extra snappy)である)特定のサブエリアにおいて高められてもよい。これらの異なるセンシングレートは、ネットワークの利用可能な帯域幅を決定し、これに基づいてデバイスの適合性を評価する場合に考慮されることが好ましい。
空間的基準
Philips Hueランプは通常、部屋ごとにグループ化される。そのため、ユーザがグルーピングのための何らかの論理的な基準を使用したと仮定すれば、各ランプがどの部屋にあるのかがわかる。しかしながら、Hueシステムは、建物(例えば、家)又は建物のフロアの全レイアウトは分からない。他のセンシング技術とは異なり、RFベースのセンシングは、占有センシングターゲットエリアの(中ではなく)近く(例えば、隣接する部屋の中)のランプの使用も考慮することができ、第1の部屋の占有マッピングを成功裏に行うことができる。Philips Hueシステムでは、典型的な部屋は、RFベースのセンシングの観点から、照明器具の配置、高さ、照明器具のタイプ等に起因して、多くの異なるタイプの照明器具を含む。隣接する2つのベッドルームは、同様のタイプの照明器具が存在することがよくある(例えば、1つのシーリングライト、1つのテーブルライト、及び床の高さにあるストリップ)。
性能を向上させるために、RFベースのセンシングのためのデバイスの適合性の決定は、各部屋内のどこに、及びどのような相対的な高度にライトが位置付けられるかを考慮に入れる。例えば、図7に示されるように、3つのベッドルームの住宅の1階において、部屋41(部屋A)については、2つの天井照明器具51及び52がRFベースのセンシングを行うために割り当てられ、部屋41(部屋A)に隣接する部屋42(部屋B)については、2つのテーブルトップランプ54及び55がRFベースのセンシングのために割り当てられ、部屋43(部屋C)については、ソファ/テレビの下にあるLEDストリップ57が割り当てられることがある。照明器具の配置及びタイプの違いに起因して、記録されるRFベースのシグネチャは大きく異なり、部屋41(部屋A)の2つの天井照明器具51及び52間の送信により、システムが部屋41(部屋A)で高いRSSI信号を見る場合、部屋41(部屋A)の2つの天井照明器具51及び52間の送信により、システムが部屋42(部屋B)で減衰された(しかし依然として高い)RSSIを見る場合もある。
通常、これは、部屋42(部屋B)でフォールスポジティブをトリガしてしまうであろうが、部屋42(部屋B)は意図的にRFベースのセンシングに天井を使用せず、むしろ照明器具の異なる一般形状及び異なる減衰を持つテーブルトップランプ54、55を活用するので、フォールスポジティブを識別し無視することは容易である。RFベースのセンシングがどのように実装されるかに依存して、RFベースのセンシングのために、占有検出ターゲットエリア内にある天井及びテーブルライトを選択せず、むしろテーブルトップランプ54又は55等、隣接する部屋に位置する別のテーブルランプと組み合わされる(図示せず)ターゲットエリア内のテーブルランプを選択することが有利であり得る。これは、テーブルライトがほとんど空気によって囲まれているのに対して、シーリングライトは、鉄を有するコンクリート天井によって形成される潜在的にRFを反射する表面に片側で面しているため、同じ高度のライトが最適なRFベースのセンシング解像度をもたらすからである。状況によっては、シーリングライトは、オフィス家具等の他の物体によって最も邪魔されにくく、したがってRFベースのセンシングを行うための最適な場所となることもある。ミリ波(超短波(Extremely High Frequency))無線技術が使用される場合、この無線技術は非常に指向性であるため、ランプ間に見通し(line of sight)パスがあることが重要である。
さらに、排水管(トイレの洗浄水の水塊が誤ったトリガ(false trigger)の原因になり得る)、葉が濡れた揺れる木、及び道路に直接つながっている家の中の歩道から離れているデバイスが好ましい。
部屋の外の廊下を人が歩くことに起因して誤ったトリガを与える照明器具を避けることは有益であり得る。可能ではない又は望ましくない場合、このような照明器具からのトリガは、2ステップの占有検出プロセスの第1のステップとして使用されてもよい(例えば、第1のトリガは、廊下に近い照明器具によって生成され、この第1のトリガは、部屋の中でより遠くに位置するが、依然として第1の照明器具に近い照明器具の検出閾値を下げる。この2ステッププロセスは、部屋に入る人の良好な検出を可能にする。)さらに、部屋の中で必要とされる動きよりも大きな動きでなければ、外の検出をトリガできないように、異なる重みが、このような照明器具に割り当てられてもよい。
(単に部屋の検出が占有/非占有ではなく)人カウント(people counting)を行うデバイスの適合性
人カウントは、常に正確なカウントであるということではなく、場合によっては単に部屋の中の2レベル又は数レベルの占有を区別することでもある。例えば、部屋が適度に混雑しているのか、非常に混雑しているのかを知ることは、冷暖房空調(HVAC:Heating, Ventilation and Air Conditioning)の空気の流れを(受身的ではなく)能動的に増やすことを可能にする。したがって、RFベースのセンシングを用いて、以前よりも空間に関するコンテキスト情報を少し多く得ることができる。人カウントのためには、RFベースのセンシングに対する要求は、部屋が占有されている又は占有されていないかどうかの単なる検出のためのものよりも高い。
経時的にバイオマスの空間的な位置を決定するため(例えば、倉庫(サイト及びエリア(site & area)照明器具のグリッドを有する大きなスクエア)内の人又は運転手がいるフォークリフトを追跡するため)のライトの適合性
ワイヤレス通信信号は水によって強く吸収されるため、RFベースのセンシングは、バイオマス(すなわち、水分を多く含むボディ)の存在に対するディテクタである。したがって、例えば、製造現場において、WiFiを備えた照明器具の規則的な天井グリッドによって行われるRFベースのセンシングは、従業員を追跡することができる。さらに、フォークリフト等の大きな金属面はワイヤレス信号を反射し、したがって2つの照明器具間のフォークリフトの存在によって生じる変化が検出され、(人体ではなく)フォークリフトとポジティブにリンク付けられることができる。
取付向きに関する基準
取付向きに関する基準を評価することは、ターゲットエリアに対して適切なRF特性、例えば、RFビーム形状をもたらす取付向きを持つデバイスを選択することを可能にする。スポット照明器具等、一部のライトは、調整可能な方向を持つ。通常、照明器具の方向は、器具の設置中にユーザによって一度設定され、その後調整されることはない。例えば、メタル形状のスポットライトは、上向き、下向き、又は左若しくは右に向けられ得る。スポットの向きに起因して、RF送信の方向性及びメタルコーン内から空間へのその伝搬は大きく異なる。
例えば、ワイヤレスビームが、ミリ波(EHF)無線機又は(複数の)指向性アンテナを備えるWiFi無線機を使用してターゲットエリアに向けられ、他のRF特性も適している場合、照明器具内のHueランプは、RFベースのセンシングに適しているかもしれないが、ビームが天井に向いている場合、同じランプは、(他のRF特性が適している場合でも)適していないかもしれない。モバイル照明器具は、ユーザに照明器具(例えば、装飾的な照明のためのキューブ形状の照明器具)の異なる向きを提供することができ、その結果、無線機がその時点でどこに位置しているかに依存して、異なるRF特性、例えば、RFビームがもたらされる。これらの向きは、内部的に例えばジャイロスコープ等のオンボードセンサを用いて、又は、外部的に例えばカメラの使用によって容易に検出されることができる。
特に照明器具に関する様々な基準
・ ドライバの配置。金属の中に配置される/金属の周りにある/金属によって囲まれるワイヤレスドライバは、RF性能に対するその影響に起因して好ましくない。例えば、HVACダクト等の主要な金属物の近く、金属配線の近く、又は柱及び鉄骨等の構造要素の近くにあるワイヤレスドライバは避けられることが好ましくない。照明デバイスにおけるドライバは、主として、光源、例えば、LEDを光らせるために、入力主電源又はDC電圧供給バス(例えば、48V又はソーラーからの高電圧DC)を制御された電圧に変換する回路である。ワイヤレスドライバはまた無線機を有し、結果として照明器具はワイヤレスで通信することができる。ドライバは光源の近くにある必要はない。例えば、光源は天井から吊るされていて、光源に給電するドライバは天井の裏側にあることがある。これは、予想と異なるRF性能を招き得る。
・ 照明器具のハウジングのタイプ。プラスチックの照明器具のハウジングは、穴あき金属の照明器具のハウジングよりも好ましく、穴あき金属の照明器具のハウジングは、連続した金属の照明器具のハウジングよりも好ましい。金属は場合によってはRF信号を整形するのに役立つことができるが、通常、ドライバが自由な空気(free air)に近いほど良い。金属は、(RF目的のためには)自由な空気とはほとんど反対のものである。
・ 照明器具の開口の方向及び大きさ。WiFiベースのRFベースのセンシングでは、より高い周波数のWiFi(5GHz)は、金属のより小さい開口を有する照明器具に割り当てられるのが好ましい。
・ 無線機/照明器具が面している(facing)方向。吊下げオフィス照明器具は、ワークデスクの真上の目の高さに位置することがよくあり、天井に向けたアップライティング及びデスクのタスクエリアに向けたダウンライティングのための2つの独立した光源を持つことがよくある。これらの2つの光源は、ワイヤレス無線機を備える2つの独立したLEDドライバによって制御されることがある。例えば、上方に面する無線機を備えるワイヤレスLEDドライバは、例えば、ワイヤレス信号の反射につながる多くの金属梁及び金属面を含むオフィス家具から離れているので、下方に面するLEDドライバを備えるワイヤレスLEDドライバよりも好ましい。さらに、椅子等の物体の位置がワイヤレス信号の吸収に影響を与え、ベースライン信号に変化を与えることがある。照明器具の上面にあるワイヤレスLEDドライバは、空気の柱(column)に向かって上方に面し、したがってワイヤレス信号は、よく予測可能且つ再現可能な態様で伝搬する。
図6の実施形態では、デバイスの適合性はまた、デバイスのグループごとに適合性を決定することによって決定される。これは、ステップ101のサブステップ161~164で実行される。各グループは、少なくとも2つのデバイス、典型的には、送信デバイスと、1つ以上の、例えば、2~4つの受信デバイスとを含む。ステップ161は、デバイスの複数のグループを選択することを含む。上述の基準を評価した後に選択されたすべてのデバイスは、潜在的にのグループに含まれる可能性がある。互いに一定の距離内にあるすべての選択されたデバイスがグループ化されてもよい。複数のデバイスが互いに協力してもよい。その後、これらのデバイスは、同じグループ内の他のデバイスの一部又は全部によって送信されるRF信号のRSSIを記録する。この場合、グループ内のデバイスのRSSIが、空間が占有されているかどうかを判断するために評価される。斯くして、グループは2つ以上のデバイスを含み、それらのデバイス間の一部又はすべての一対一接続(「ペア」)が使用されることがある。
直ちに必要な数以上のデバイスが選択されてもよい。これらのスペアデバイスは、オン/オフスイッチを有するテーブルライトのエリア等、ノードが給電停止される可能性が高い1つ以上の検出エリア内で/そのために選択されてもよい。例えば、4つのデバイスではなく、6つのデバイスが、RFベースのセンシングのために協働するように採用されてもよい。この結果、より高いネットワーク負荷及びより高いマイクロコントローラ(uC)負荷がもたらされるが、1つ又は2つのデバイス(例えば、ライト)が給電停止される(次のイベントでどのデバイスが給電停止されるかは、事前にはわからない)場合に検出エリアが依然として機能することを確実にする。
ステップ162は、共通のデバイスを有し、同じ又は隣接したセンシングエリアをターゲットにしている複数のグループのうちの2つのグループがあるかどうかを判断することを含む。言い換えれば、ステップ162は、相互に排他的なデバイス、例えば、照明器具、グループを決定/選択することを含む。この判断が肯定的である場合、2つのグループのうちの1つは適していないと判断される。RFベースのセンシングの1つの不利な点は、部屋Aにいる人が部屋Bの壁の近くにいると、部屋Bでもワイヤレス障害(wireless disturbance)をもたらすことである。したがって、先行技術のRFベースのセンシングでは、2つの部屋のうちの正しい1つにユーザの位置を定めるための信頼性が損なわれる。
家全体又は建物の一部(すなわち、単一のターゲット検出エリアではなく、複数のターゲット検出エリア)に対してRFベースのセンシングを行う場合、隣接する部屋でRFベースのセンシングに使用されるライトの2つのグループが相互に排他的なグループである(すなわち、1つのライトが、2つの隣接するRFベースのセンシンググループのうちの一方にしか属し得ない)ように、RFベースのセンシング機能を割り当てることが有益である。相互に排他的な照明器具グループを選択することは、2つの異なるライトグループのRFベースのセンシング信号ができるだけ異なって見えることを確実にする。これは、部屋Aでの検出不良(poor detection)が部屋Bによって「盗られる」可能性を減らし、したがって曖昧さ及び占有検出のフォールスポジティブを減らす。
同じ原理は、グループが3つ以上のライト、例えば、1つの送信ライト及び複数の受信ライトを含む場合にも使用され得る。同じライトは、負荷をよりよく分担するために複数のグループに対するRFベースのセンシングアルゴリズム処理をすべて行うコントローラになるべきではない。しかしながら、(a)聞くメッセージのRSSIを記録し、(b)RSSIをレポートする非コントローラノードは、2つの異なるグループに同時に参加することがある。この場合、これは、第1のライトグループによって受信されるRF信号のRSSIだけでなく、第2のライトグループのRSSIもレポートする。
ステップ163は、複数のデバイスのうちのペア間の通信品質がある閾値を下回るかどうかを判断することを含む。この判断が肯定的である場合、このペアは適していないと判断される。通信品質は、典型的には、RFベースのセンシングパスをブロックする障害物があるかどうかに依存する。RFベースのセンシング方法は、必ずしもデバイス間の直接の見通しを必要としない。しかしながら、ワイヤレス信号は、特定の障害物を見通すことはできない。例えば、エンドユーザが大きな金属製家具(例えば、本棚)を再配置する場合、デバイス間のRFセンシングパスが損なわれる可能性がある。
通信品質は、静的な信号パスの変化により、デバイスのペア、例えば、ランプ1及びランプ2の間の検出パスが壊れる場合、ある閾値を下回るとみなされてもよい。壊れたRFベースの検出パスを検出するために、システムは、部屋の現在のRFシグネチャと、検出エリアに存在する人からの寄与がない可能性が非常に高い深夜(例えば、午前2時)に、又は、すべての占有者が家を出ていることが分かっている場合の当該部屋のRFシグネチャとを比較してもよい。
通常、デバイスが互いに通信できる場合でも、通信品質は、ある閾値を下回ることがある。信号が弱い場合、妨げになる(in the way)人体によってもたらされる等の潜在的な一時的障害物により、パスが一時的に効果的に壊れていることを意味する。したがって、人体によってもたらされる障害物を含む、最悪のシナリオを考慮しながら、通信品質を測定/推定することは有益である。ステップ164において、残りの(すなわち、適切な)グループのデバイスは、適していると判断される。例えば、ステップ162は、コミッショニング中及びコミッショニング後に実行されてもよく、ステップ163は、コミッショニング後に実行されてもよい。
ステップ101、103及び105がコミッショニング中に実行された後、システムの通常の動作が開始されてもよく、すなわち、RFベースの存在及び/又は位置検出が、ステップ105で指示された少なくとも1つのデバイスによってステップ166で実行されてもよい。ステップ167において、一定の時間が経過した及び/又は別の基準が満たされ、したがってデバイスの適合性が再評価される必要があるかどうかが(すなわち、コミッショニング後に)チェックされる。そうでない場合は、RFベースの存在及び/又は位置検出はステップ166で継続されてもよい。そうである場合、ステップ101が再度実行されてもよい。
例えば、ステップ167において、天候が(大きく)変化したかどうかがチェックされてもよい。例えば、RFベースのセンシングが(例えば、人カウントのため)外部のガーデン照明に適用されており、システムが現在雪が降っていることを知り、ワイヤレス信号の送信に影響を与える可能性がある場合、RFベースのセンシングのために異なるライトを選択することが有益であり得る。天気の良いときには、庭のドアから5メートル離れた家の壁に取り付けられた主電源式のライトが、RFベースのセンシングを行うために使用されてもよい。雪が降っているときは、庭のドアのすぐそばに位置するバッテリ式のガーデンライトが、RFベースのセンシングを行うために使用されてもよい。同様に、霧又は雨は、ワイヤレス信号を減衰させることが知られている。
また、デバイスの適合性は、RFベースのセンシングモードが、例えば、人カウント、人位置特定(people locating)、誰もいない部屋への人入室の検出、及びセキュリティの間で切り替えられる場合に再評価されてもよい。例えば、人カウントは、タイムクリティカルな機能(time critical feature)ではない。部屋に3人の人がいると結論付けるのに例えば10~30秒かかることは通常完全に許容できる。ある選択基準に基づいて、照明器具1、2、3、4は、人が部屋に入る場合に即座の検出を提供するものであるため、照明制御に最適であると第1の時点で結論付けられるかもしれない。しかしながら、システムは、アプリケーションの目的が、まず(ライトをオンにするために)部屋に誰かいるかどうかを判断し、その後でのみ何人いるかをカウントするように、層構造にされることができる。
このような場合、最も簡単な方法は、システムを常に動きセンシングモードで動作させることである(これは最も低いレイテンシを招く)。部屋の中に少なくとも一人の人がいることが確実になると、システムは自動的に人カウントモードに切り替わることができる(これは、最も豊かな(richest)情報を提供する)。しかしながら、ライト1、2、3、4は、部屋の中央ではなく、入り口に近い場所にある等、人カウントに理想的なライトではない可能性がある。この場合、システムは、RFベースのセンシングのために例えば、3、4、5、6、7の照明器具を選択することができる(これらの照明器具は、人カウントに最適な照明器具である)。同様のことは、照明制御モード(例えば、日中)及びセキュリティモード(夜間又は週末及び休日)間の切り替えにも当てはまる。
(コミッショニング後に実行される)ステップ101の第2の反復において、無線周波数信号の送信、受信及び/又は処理のための複数のデバイスの各々のさらなる適合性が決定される。ステップ103の第2の反復において、複数のデバイスの各々について決定されるさらなる適合性に基づいて複数のデバイスからさらなるデバイスのサブセットが選択される。ステップ105の第2の反復において、さらなるデバイスのサブセットのうちの少なくとも1つが、存在及び/又は位置検出のための無線周波数信号を送信、受信及び/又は処理するためのデバイスとして動作するように指示される。
図6の実施形態では、以下の基準の1つ以上が、コミッショニング後にステップ101において個々のデバイスの適合性を決定するために評価されてもよい。
ネットワーク到達性に関する履歴
ネットワーク到達性に関する履歴を評価することは、ネットワーク到達性の履歴が悪いランプへの、RFベースのセンシングを行うタスクの割り当てを避けることを可能にする。
・ ユーザは、レガシー壁スイッチで特定のランプをオフにする、すなわち、ワイヤレスランプの給電を停止し、したがってRFベースのセンシングを行えなくする傾向があるかもしれない。このランプをRFベースのセンシングに使用しないのが良い。
・ 特定のランプは、ワイヤレス干渉に起因して(例えば、同じ2.4GHz帯が、隣のアパートメントのオーディオストリーミングシステムによって使用される場合)到達性が悪くなることがある。
メッシュネットワークにおいて、メディアルームは、キッチンエリアに位置するランプ1及び2を介してメッシュすることによってしか到達されることができず、ランプ1が、例えばユーザがレガシー壁スイッチを頻繁に使用するため、悪い履歴的な到達性を有する場合、ランプ2がRFベースのセンシングのためのクリティカルなライトでない限り、コア照明制御コマンドがメディアルームに到達するためのクリティカルパスの問題を避けるために、ランプ2をRFベースのセンシングノードとして選択しないことが最善である。例えば、他の候補がなく、メディアルームへのメッセージがネットワークを完全に満たしていない場合、ランプ2をRFベースのセンシングノードとして選択することはまだ良い可能性がある。この場合、ランプ2は、RFベースのセンシングデバイスとして適しているが、他のデバイスよりも少ない時間でRFベースのセンシングタスクに割り当てられてもよい。斯くして、ランプ2は、適していると考えられるが、他のデバイスよりも適していないと考えられ、デバイスによって実行されるRFベースのセンシングの程度は、その適合性の程度に依存してもよい。ランプ2によってRFベースのセンシングに費やされる時間は、ランプ2がオーディオ及び/又はビデオコンテンツに付随するライトコマンドのストリーミングに使用されるかどうかに依存してもよい。
動きセンサ、バッテリ式のスイッチ、又は主電源供給されるZigbeeスイッチによる制御
デバイスが動きセンサ、バッテリ式のスイッチ、又は主電源供給されるワイヤレス(例えば、Zigbee)スイッチによって制御されるかどうかを評価することは、動きセンサ、バッテリ式のスイッチ、又は主電源供給されるZigbeeスイッチのいずれかによって制御されるRFベースのセンシングノードしてのライトを選好することを可能にする。これらのライトは、ワイヤレスランプへの電力を途絶する、レガシー壁スイッチを使用するライトよりも、ユーザによってオフにされる可能性が低い。
リアルタイムのワイヤレス干渉に関する基準
リアルタイムのワイヤレス干渉に関する基準を評価することは、非照明デバイス及び他の照明システムによって引き起こされる(したがって、RFベースのセンシングを行うランプの能力に影響を与える)ワイヤレス干渉の影響を目下受けているランプを避ける一方、同じ場所ではあっても、後の時点においては、この基準の評価の結果、これらのランプが、RFベースのセンシングを行うための有効な候補と見なされることを可能にする。
・ 他の無線機を備える家電機器(例えば、テレビ又はWiFiアクセスポイント)の近くに位置する、ランプは、家電機器がオンにされる、又はWiFiでのビデオストリーミングが始まるや否や妨害を受けることになる。しかしながら、テレビがオフしている場合、テレビの近くにあるランプは干渉を受けず、したがって該ランプはRFベースのセンシングを行うのに適した候補である。Philips Hueライトに対するテレビ等のエンターテインメントデバイスの位置は、Philips Hue Entertainment機能の設定時にユーザによって提供されるマッピングに基づいて決定されてもよい。テレビのリアルタイムの状態(オン又はオフ)は、テレビのAPI又はホームオートメーションシステム(例えば、Apple Homekit/Apple TV又はGoogle Home)のAPIを介して、Philips Hueシステムによって取得されてもよい。
・ さらに、干渉は他の照明システムから発生することもある。例えば、隣人のリビングルームの近くに位置するランプは、例えば、ChromeCastによって使用される等WiFiを介した該隣人のテレビへのビデオストリーミングのたびたびの期間、又は同じZigbeeチャネルで動作している該隣人のメッシュ照明ネットワークからのワイヤレス干渉を受ける可能性がある。
エンドユーザの使用パターンに関する基準
・ エンドユーザの使用パターンに関する基準を評価することは、1日の大半がオンしている階段にあるライト(又は常にオンしている非常用ライト)と対比して、オンとオフの間を遷移することが多いことがシステムによって分かっているランプ(例えば、ライトの瞬時のオンを必要とする、センサを備えるウォークインクローゼットライト)を選択しないことを可能にする。RFセンシングにより導入されるレイテンシは、人にとって、ライトがオフからオンに遷移する場合にはるかに顕著である(例えば、ユーザが部屋に入りすぎて、暗闇の中で家具に衝突する場合がある)。
・ エンドユーザの使用パターンに関する基準を評価することは、ユーザが動的な照明シーンのために最も使用するランプ(特に、低レイテンシを必要とするシーンに参加するランプ)をRFベースのセンシングのために選択しないことを可能にする。
ワイヤレスネットワーク全体内の現在のフリーで利用可能なデータレート(current freely available data-rate)に関する基準
何百ものライトを含む大規模なZigbeeネットワークでは、15秒ごとにリンクステータスを送信するZigbeeルータデバイスによって引き起こされるトラフィックは、すでに総Zigbeeエアタイムバジェットの15%を消費する可能性がある。典型的には、これは直ちに、大規模なネットワークにとって、システムが通常の基本的なシステムタスクに加えて新しい一時的なタスクを実行しなければならない場合(例えば、OTAUファームウェアアップデート、動的に調整可能な白色照明シーンの実行、高解像度のRFベースのセンシング、エンターテイメントのストリーミング)、帯域幅の不足を招く。したがって、大規模なネットワークでは、少ないデバイスが、RFベースのセンシングの役割のために選択されてもよく、適合性の要件は、より厳しく、正確な情報に基づいて適用されることが好ましい。小規模なネットワーク(例えば、30個のワイヤレスライトを含むネットワーク)では、より多くのエアタイムヘッドルームが、RFベースのセンシング等の追加タスクを実行するライトに対して利用可能である。
Zigbeeネットワーク内の現在利用可能なフリーエアタイム(currently available free airtime)
どのランプグループがRFベースのセンシングに最適であるかは、通常、Zigbeeネットワーク内で現在利用可能なフリーエアタイムに依存する。RFベースのセンシングへの参加は、典型的には、送信機が余分なワイヤレスメッセージ又は他の信号を送信する及び受信機がRSSI及び他のネットワーク診断パラメータを決定し、RSSIの分析及び保存を行うことを必要とする。例えば、ランプA及びランプBの間のリンクは、最高のデータレートでのみ最良の占有検出結果を与えるかもしれない(例えば、Philips Hueエンターテイメントモードが実行されている場合)。低い帯域幅しか(例えば、混雑したスペクトルに起因して)ランプ間で利用可能ではない場合、ランプB及びランプCの間のリンクが、占有検出を行うのに最適であるかもしれない。
典型的には、単一の送信デバイスと複数の受信デバイスとの間のリンクが、RFベースのセンシングのために評価される。典型的には、RFベースのセンシンググループは、3~5個のランプがメッセージを送信すること、及び、他のランプから受信されるメッセージのRSSIを決定することを含む。ランプのうちの1つは、占有検出アルゴリズムの処理を行うように割り当てられ、他のランプは、メッセージを送信し、存在検出処理アルゴリズムを行う当該1つのランプにRSSIをレポートするだけでもよい。
Zigbeeネットワーク内の予測されるフリーエアタイム(forecasted free-airtime)
(コンテキストに基づいて)Zigbeeネットワーク内のフリーエアタイムを予測することにより、RFベースのセンシングを行うランプの選択を能動的に調整することができる。多くの場合、照明システムは、(1)特定のスケジュール(例えば、午後8時にスケジュールされている動的なシーン)、(2)履歴から分かる、その後あるピーク負荷を引き起こすようなセンシングされるパラメータ(例えば、人が8時30分にメディアルームに入ることは、該人が動的なAmbilightサラウンド照明を用いてテレビを見ることを意味する可能性が高い)、(3)スケジュールソフトウェアアップデートサイクル(OTAU)等の状況に起因して追加のネットワーク負荷が発生するであろうことを事前に分かっている。これらの場合、相応にRFベースのセンシングを行うランプの選択を能動的に調整することが有益である。
例えば、照明システムは、メディアルームでエンターテイメント照明シーンがまもなくアクティブにされることを予測する。システムは、階段にある照明が、コントローラ/ブリッジが上階のメディアルームのエンターテイメント照明と通信するための重要なZigbeeルータになるであろうことを知っている。したがって、システムは、このランプをRFベースのセンシングノードとして選択せず、又は、RFベースのセンシングに特有の追加のRF信号を送信するため及び/若しくはRFベースのセンシングに特有の処理を実行するためにこのランプを選択しない。
建物若しくは建物のフロアの2つのサブエリア間の又はコントローラへのネットワーク通信パスで重要な役割を果たすランプの選択も、好ましくは避けられるべきである(例えば、階段にある1つの照明は、システムが上階のメディアルームと通信するための重要なルータである)。特別な状況では、階段にある照明は、自身の照明制御に関連するメッセージから、頻繁で経時的によく分布される通信パターンをすでに決定している可能性があり、このランプは、RFベースのセンシングに特有の余分なメッセージ又は信号を追加する必要なくRFベースのセンシングに適し得る。
パラメータを修正する又アクションを遅らせる可能性
パラメータ又はアクションが修正/遅延されることができるデバイスが好ましい。なぜなら、これは、ほぼ完璧なRFベースのセンシングがあることを確実にし得るからである。例えば、ライトのファームウェアのOTAUを実行する場合、照明システムは、占有検出ターゲットエリアの各々について現在必要なRFベースのセンシングエリアモードを実行するのに十分な帯域幅を残すようにOTAU速度を適応させることができるのが好ましい。代替的に、消費エネルギ及び温度等の非レイテンシクリティカルなパラメータのレポートのタイミングが、RFベースのセンシング性能を最大化するために修正されてもよい。
現在利用可能なフリー処理能力の量(amount of free processing power)
デバイスの現在利用可能な処理リソースを評価することは、RFベースのセンシングデータ及び検出アルゴリズムの高速処理を保証するために現在利用可能なフリー処理能力の量を持つランプを選択することを可能にする。例えば、レイテンシが低い照明クラスの検出アルゴリズム、及び、検出信頼性は非常に高いがレイテンシが高い、空き家への侵入者を検出するためのセキュリティクラスのアルゴリズム等、複数の検出アルゴリズムが並行して実行されることがある。
例えば、RFベースのセンシング信号の処理時間が0.2秒を超える場合、照明制御のレイテンシは、エンドユーザにとって許容できないものになる可能性がある(特に、ライトがオフにされていて、占有センシングに基づいてアクティブにされる必要がある場合)。例えば、同じエリアに位置する2つの同一のHue電球の動作上の使用が異なる場合がある。例えば、第1のランプには1つのシーンしか保存されていなく、したがって、30のシーンが保存されている第2のランプに比べて空きメモリが多い。ランプのシーン数は静的なパラメータではなく、システムの寿命にわたり変化する可能性がある。また、利用可能なフリー処理能力は、ランプによって異なり、例えば、マイクロ波センサを内蔵した複雑なライト効果を行うランプは、静的なランプに比べて空きCPUリソースが少なくなる。
Philips Hueシステムでは、一部の電球が、ZigbeeエンドノードのためのZigbee親ノードとして動作する。親ノードになると、非親ノードの電球に比べて追加のリソース(例えば、処理、データストレージ、エンドノードとの定期的な無線コンタクト)を消費する。典型的なZigbeeエンドノードは、壁スイッチ及びセンサ等のバッテリ式のデバイス又はバッテリ式のライトである。Zigbeeエンドノードは、最適なワイヤレスリンクに基づいて親を動的に選択する。したがって、Zigbeeエンドノードの親デバイスは、寿命にわたり数回変わる可能性がある。したがって、Zigbee親デバイス及びZigbeeエンドデバイスを単一のRFベースのセンシンググループに割り当てることは、有利ではないかもしれない。さらに、RFベースのセンシングは、典型的には、追加のRF信号及び/又は処理を必要とし、したがってZigbeeエンドデバイスのバッテリ寿命を短くする。
RFベースのセンシングが、複数のアプリケーション、例えば、セキュリティ及びライト制御に使用される場合、典型的には、複数のアルゴリズムが実行される必要がある。1つのデバイスが両方のアルゴリズムを処理できれば理想的であるが、複数のアルゴリズムのうちの1つを実行できるデバイスも適していると考えられ得る。このようにして、他の基準を鑑みて適しているすべてのデバイスが無視されないが、利用可能な処理能力の基準は、オールオアナッシングのアプローチではなく、複数のノードに分けられるように、責任が分けられてもよい。これは、アルゴリズムが「スタック」される場合に使用されてもよい。例えば、動きがあることをすぐに判断するのはアルゴリズムAであるが、より深く見て、より高いレイテンシを犠牲にしてもはるかに高い信頼度で存在を結論付けるのはアルゴリズムBである。アプリケーションは両方の結果を得たいと思うかもしれないが、このスタッキングに起因して、ノードは、A又はBのいずれかの実行に適しているが、両方を実行するのには適しないという状況に達する可能性がある。
ライトのオン/オフ状態
ライトのオン/オフ状態を評価することは、RFベースのセンシング時の照明システムのスタンバイ電力を最適化することを可能にする。典型的には、デバイスは、(ライトがオン又はオフであるかどうかに関係なく、ルータランプデバイスのアイドル状態である)受信時よりも送信時にやや多くの電力を必要とする。したがって、ライトが「オフ」である際にRFベースのセンシングのための重いワイヤレストラフィックを送信することは、(ライトがオフであるため「待機電力」と見なされ得る)消費電力を増加させる可能性がある。潜在的な将来のより厳しい待機電力規制を満たすためには、現在オンである、すなわち、(可能であれば)光を発しているライトを、RFベースのセンシングを行うために優先的に選択することが有利であり得る。
現在の熱安定性
ランプの現在の熱安定性を評価することにより、RFベースのセンシングを行うために現在熱的に安定しているランプを選択することができる。ランプの温度は、動作状態が点灯/消灯の間で変えられる場合にドリフトする可能性がある。この結果、無線電子機器における温度ドリフトをもたらし、結果として、ワイヤレストランシーバ特性(例えば、受信感度)のドリフティングをもたらす。したがって、熱的に「安定した」ランプを選択することは、消灯と点灯との間を遷移したばかりのライトを利用するよりも無線機間のオフセットが小さくなる。より熱的に安定しないランプの場合、これらのドリフト/オフセットにより、システムは環境のダイナミックな特性が変化したと錯覚し、動きがあったと結論づける可能性がある(これはフォールスポジティブである)。
日光への曝露
日中、特定のエリアにおいて十分な自然光が得られるため、特定のライトが決してオンされないことがある。これらのライトは、ユーザによってオンされることが予想されず、したがって、ランプはオフされているにも関わらず、照明制御に低いレイテンシを必要としないので、RFベースのセンシングの優れた候補である。これらのランプがオンされる場合、既に存在している日光の量が、別の以前暗かった部屋がオンに遷移する状況と比較して、潜在的なレイテンシの問題の影響を隠す助けとなるであろう。それゆえ、日光への曝露が高いランプを選択することは有益である。しかしながら、あるライトは、日中には優れたRFベースのセンシングノードであっても、夜間にはよくない選択(poor choice)となる可能性がある(この空間のために低レイテンシ制御が必要である等)。(例えば、窓のない廊下、又は、オフィスタイムに常に誰かがいる建物のエリアで使用される)常にオンしているライトも良い候補である。一般的には、オフからオンへの切り替えがそれほどないライトは、レイテンシが懸念される場合良い候補である。
照明コマンド送信アクティビティ
照明コマンド送信アクティビティを評価することにより、照明制御コマンドを送信するのに現在それほどアクティブではないランプを、RFベースのセンシングに関連するリスニング、処理、及び保存に対処するのによりアクティブであるように割り当てることが可能である。非常にインタラクティブなランプ、例えば、(アクティブな)エンターテイメントグループのライトは、システム内のどこかに割り当てられることができるRFベースのセンシングのための基本的な作業を行うために割り当てられるべきではない。例えば、(オーディオ及び/又はビデオコンテンツに合わせて光をレンダリングする)エンターテイメントグループのライトは、RFセンシングのために良好である、多くのトラフィックを生成(又は受信)するが、ユーザに完璧な照明体験を提供することに主に集中すべきである。一つのオプションは、RFベースのセンシングを行うためにエンターテイメントグループの一部であるライトを割り当てるが、データストレージ及びCPU負荷の高いデータ分析処理をエンターテイメントグループの一部ではないライトによって行わせることである。例えば、エンターテインメントライトコマンドを送信するデバイスは、複数のRFベースのセンシンググループにおける送信デバイスであってもよい。これらのグループの他のデバイスは、例えば、エンターテイメントグループの内部又は外部のライトであってもよい。
現在利用可能なスペアネットワークデータレート(currently available spare network data-rate)
現在利用可能なスペアネットワークデータレートを評価することにより、十分な現在利用可能なスペアネットワークデータレートを持つデバイスを選択することが可能になる。例えば、コントローラ/ブリッジ内のZigbee無線機が、キッチンのランプのOTAUファームウェアアップグレードを現在実行していることがある。家の中の他のライトとの通常の照明制御トラフィックと相まって、コントローラ/ブリッジ内の無線機は現在、多くのワイヤレストラフィックを処理している。したがって、コントローラ/ブリッジ内のZigbee無線機は、すでに容量一杯である可能性があり、(キッチンライトのファームウェアアップデートが終わるまで)リビングルームのワイヤレスライトとRFセンシンググループを形成するのに、今は良い候補ではない可能性がある。1つのオプションは、RFベースのセンシングに参加するようにコントローラ/ブリッジを割り当てるが、データストレージ及びCPU負荷の高いデータ分析処理を、OTAUアップグレードの一部ではなく、したがって十分な空きコンピューティング能力及びメモリを持つライトによって行わせることである。
占有検出ターゲットエリアに対するRF特性、例えば、ビーム形状
占有検出ターゲットエリアに対するRF特性、例えば、ビーム形状を評価することにより、現在の物理的な位置が占有検出ターゲットエリアに対する適切なRF特性、例えば、ビーム形状をもたらす照明器具を選択することが可能である。例えば、(Hue Goと同様の)キューブ形状のバッテリ式照明器具は6つの異なる面を持ち、ユーザが、キューブの向きを選択することを可能にし得る。無線チップ、例えば、WiFi無線チップ又は60GHzミリ波無線チップを含む面が、その時点でターゲット検出エリアに向けられている場合、キューブ照明器具は、RFベースのセンシングによく適したものとなる。無線機が床に面している場合、照明器具は、RFベースのセンシングを行うにはよく適していない。
ある向きに位置付けられる照明器具の適合性は、その周囲にある他の材料にも依存する可能性がある。例えば、金属製テーブルの上にある場合、キューブが下方に向けられることは、RFベースのセンシングの悪い結果をもたらすが、テーブルが薄い木でできている場合は、RFベースのセンシングは、満足に行われることができる。無線チップが電球に組み込まれ、この電球が金属照明器具に配置される場合、これは、無線チップ自体、例えば、Zigbee無線チップのRF性能が均一であっても、指向性のあるRF性能となり得る。
ここ数ページで、コミッショニング時に使用するための第1の基準のセットが述べられ、コミッショニング後に使用するための第2の基準のセットが述べられている。一部の基準は両方のセットに存在する。一部の他の基準は、これらセットのうちの1つにしか存在しないが、コミッショニング中及びコミッショニング後の両方で使用可能な場合もある。RFベースのセンシング(動き検出、真の存在検出(true presence detection)、又は体の姿勢若しくはジェスチャを検出することができるきめ細かなセンシング(fine-grained sensing))に関連して述べられた基準は、RFベースのアセットトラッキング(位置特定)にも使用できる可能性がある。
上記の選択基準は、図6の実施形態においてRFベースのセンシングを行うために特定のランプを避けるために使用されているが、上述のRFベースのセンシングのマイナスのシステム影響(negative system impact)を軽減するためにRFベースのセンシングを故意にスロットル(throttle)することも可能である。極端なケースでは、RFベースのセンシングは、Zigbeeネットワーク内で送信される非センシング関連メッセージだけが使用される程度までスロットルされることができる。
ワイヤレス(例えば、メッシュ)ネットワーク内のメッセージルーティングを制御する方法の第3の実施形態が、図8に示される。図3に関連して述べたように、この方法の目的は、どのノードに、ネットワークルーティングを実行するように、すなわち、それらが受信するメッセージを転送するように指示するかを決定することである。これらの指示の結果、ネットワークルーティングが調整され、RFベースのセンシング及び/又はアセットトラッキングの実行のためにワイヤレススペクトルが局所的に解放されることになり、これについては図1のブリッジ1に関連してより詳細に述べられている。
前述のように、ステップ111は、複数のノードの第1のサブセットを決定することを含み、この第1のサブセットは、無線周波数ベースの存在及び/又は位置検出機能を割り当てられる1つ以上のデバイスを含む。この第1のサブセットは、手動又は自動で選択されてもよい。
第1のサブセットは、すべてのノードから選択されてもよく、又は、例えば、図2及び図4に関連して述べたように、RFベースの存在検出及び/又は位置特定に適していると判断されるノードから選択されてもよい。第1のサブセットのうちの1つ以上のノードが、RFベースの位置特定(RFベースのアセットトラッキング)を実行する必要がある場合、1つのノードを選択することで十分であり得る。第1のサブセットの1つ以上のノードが、(RFベースのアセットトラッキングを行うよりも困難であり、検出されるべき物体、人、又は動物がRF送信機及び/又は受信機を担持しない)RFベースの存在検出(RFベースのセンシング)を実行する必要がある場合、典型的には、少なくとも2つのノードの少なくとも1つのグループが必要とされ、これらのノードは、典型的には、1つ以上のターゲットセンシングエリアに基づいて選択される。
次に、ステップ172において、複数のノードの第2のサブセットが、第1のサブセットの1つ以上のノードの位置に基づいて選択される。第1のサブセットの1つ以上のノードは、無線周波数ベースの存在及び/又は位置検出機能のための1つ以上の無線周波数信号を送信及び/又は受信するが、第2のサブセットの1つ以上のノードはそうしない。代わりに、第2のサブセットの1つ以上のノードは、他のノードを対象とした、一部のネットワークメッセージ又はいかなるネットワークメッセージ(例えば、照明制御コマンド)を再送信しないことによって、RFベースの存在及び/又は位置検出に引き起こされる干渉を制限することを試みる(この実施形態では、センシング及び/又はアセットトラッキングRF信号は、インバンドで送信される)。第2のサブセットの1つ以上のノードは、RFベースの存在及び/又は位置検出のためのRF信号を受信するかもしれないが、それらのRSSIを記録する必要はない。第2のサブセットのノードは、それが適切な位置にない又は他のノードで既に可能なこと以上の追加情報を追加しないことに起因して、第1のサブセットではなく第2のサブセットに含まれてもよい。次に、ステップ173は、複数のノードの残りのノード(すなわち、第1のサブセット又は第2のサブセットの一部として選択されていないノード)から成るノードの第3のサブセットを作ることを含む。第2のサブセットの1つ以上のノードとは異なり、第3のサブセットの1つ以上のノードは、他のノードを対象としたすべてのネットワークメッセージを再送信する、すなわち、通常のルーティング機能を実行する。
図3に関連して上述したように、ステップ113は、ソースノードからデスティネーションノードへの複数のルートを決定することを含む。図3のステップ115は、サブステップ175を含む。ステップ175は、複数のルートの各々の中間ノードのうちのいくつが複数のノードの第1のサブセット又は第2のサブセットの一部であるかに基づいて複数のルートのうちの1つを選択することを含む。ステップ117は、ワイヤレス(例えば、メッシュ)ネットワークに選択されたルートに従ってメッセージルーティングを行わせるために1つ以上のメッセージを送信することを含む。これは、図1のブリッジ1に関連してより詳細に述べられている。
ステップ117において、これらの1つ以上のメッセージは、通常、RFベースの存在検出及び/又は位置特定を行うのに使用されるプロトコル(例えば、Bluetooth)とは異なるプロトコル(例えば、Zigbee)を使用して送信される。図8の実施形態では、第1のサブセットの1つ以上のノード及び第2のサブセットの1つ以上のノードは、(例えば、照明制御コマンド又は通常のネットワーク「ハウスキーピング」メッセージのための)メッセージルーティングを行わないように、又はそれらが行うメッセージルーティングを制限するように指示される。さらに、第1のサブセットの1つ以上のノードは、RFベースの存在及び/又は位置検出を行うように指示される。第2のサブセットのノードは、第1のサブセットのノードにできるだけ干渉しないように指示される。第3のサブセットのノードは、ネットワークルーティングを行う、すなわち、他のノードを対象とした、それらが受信するメッセージを転送するように指示される。
これらの指示の結果、ネットワークルーティングが調整され、RFベースのセンシング及び/又はアセットトラッキングの実行のためにワイヤレススペクトルが局所的に解放される。第1のサブセットの1つ以上のノード及び第2のサブセットの1つ以上のノードは、(本明細書において後にモード2とも呼ばれる)機能性が低下した(例えば、Zigbee)ルータノードとして動作するように指示されてもよく、これは、ノードが自身に直接宛てられたメッセージのためにZigbeeメッシュネットワーク上でリッスンするが、ノードは他のZigbeeノードからのメッセージを転送しないことを意味する。
代替的に、第1のサブセットの1つ以上のノード及び第2のサブセットの1つ以上のノードは、(本明細書において後にモード3とも呼ばれる)(例えば、Zigbee)エンドノードとして動作するように指示されてもよく、これらのノードは、メッシュネットワークに全く参加せず、ある期間(例えば、0.5秒以上)ごとに、それらの親ノードによって受信され一時的に保存されるこのノード宛てのメッセージをチェックするだけである。代替的に、例えば、第1のサブセットの1つ以上のノードは、機能性が低下したルータノードとして動作するように指示され、第2のサブセットの1つ以上のノードは、エンドノードとして動作するように指示されてもよく、又はその逆であってもよい。第3のサブセットのノードは、(本明細書において後にモード1とも呼ばれる)本格的な(full-fledged)(例えば、Zigbee)メッシングノードとして動作し、それによってロバストな建物レベルの(例えば、メッシュ)ネットワークのためのバックボーンを提供する。
図8の実施形態又は代替的な実施形態では、RFベースのセンシングのためのRF信号を送信する必要がある第1のサブセットの1つ以上のノードは、ある期間の間に間断なくRF信号を送信する、例えば、他のノードによって到達可能であることを気にすることなくRF信号をフルブラストで送信するように指示されてもよく、RFベースのセンシングのためのRF信号を受信する必要がある第1のサブセットのノードは、このある期間の間に間断なくRF信号を受信するように指示されてもよい。これは、「高空間解像度(high-spatial-resolution)」センシングモードと呼ばれる。第1のサブセットのこれらのノードが照明デバイスである場合、このモードは、ある期間の間選択されてもよく、又は、ある期間自体が、ライトデバイスがこのある期間の間に光出力状態が変わらないことが予想されるという予想(expectation)に依存して選択されてもよい。
ステップ111、172、173、113、115及び117がコミッショニング中に実行された後、システムの通常の動作が開始されてもよく、すなわち、RFベースの存在及び/又は位置検出が、ステップ117で指示されたデバイスによってステップ176で実行されてもよい。ステップ177において、一定の時間が経過した及び/又は別の基準が満たされ、第1及び第2のサブセットが再選択される必要があるかどうかがチェックされる。そうでない場合は、RFベースの存在及び/又は位置検出はステップ176で継続されてもよい。そうである場合、ステップ111が再び実行され、第1のサブセットの1つ以上のノード及び第2のサブセットの1つ以上のノードの新たな選択が実行されてもよい。
第1及び第2のサブセットは、RFベースのセンシング(存在検出)に使用されるターゲットセンシングエリアが変わる場合に再選択される必要があってもよい。ステップ177は、ユーザアクティビティが変化した又は変化することが予想され、したがって存在が異なるターゲットセンシングエリアで検出される必要があるかどうかを検出することを含んでもよい。例えば、ターゲットの人が家の中の第1のエリアから第2のエリアに移動する場合、ネットワーク内のルーティングが動的に調整されてもよい。斯くして、当該人は、高強度のRFベースのセンシング「ハロー」(high-intensity-RF-based-sensing "halo")を伴って新しいエリアに移動する。言い換えれば、(例えば、照明)システムは、第2のエリアのRFベースのセンシングのためのワイヤレススペクトラムを解放する(free up)ためにルーティングを調整し、一方、第1のエリアの照明制御のための追加のスペクトラムを「リリース(release)」する。さらに、ワイヤレス信号は第1のエリアと第2のエリアの間を伝搬する可能性があるため、このアプローチは、第1のエリアと第2のエリアとが不必要に互いに干渉しないことを保証する。
ここで、図1のデバイス間で決定されるルートの2つの例が、図8の方法を説明する助けとなるように提供される。第1の例として、リビングルーム32のテーブルランプ15及びフロアスタンディングランプ14が、コンテキストアウェアネスの目的で占有者の数をカウントするために高解像度のRFベースのセンシングスキャン(high-resolution RF-based sensing scan)を実行している。同時に、LEDストリップ12は、(エントランスエリア34に位置する)ブリッジ1とメディアルーム33との間でかなりの(例えば、Zigbee)トラフィックを必要とする動的エンターテイメント効果を実行するためにメディアルーム33で使用されている。エントランスエリア34のHueブリッジ1とメディアルーム33との間の距離は、(例えば、Zigbee)通信が2つの部屋の間で少なくとも1つのネットワークホップを必要とするようなものである。
テーブルランプ15及びフロアスタンディングランプ14が、ブリッジ1からLEDストリップ12へのエンターテイメントメッセージの転送に参加しないようにネットワーク内のルーティングを調整することにより、テーブルランプ15及びフロアスタンディングランプ14は、それらの処理リソース及び/又はメッセージ送信及び/又はワイヤレスコマンドのリスニング(Zigbeeデバイスは、典型的には、同時にトーク及びリッスンすることはできない)を、高解像度のRFベースのセンシングを実行するのに集中させることができる。テーブルランプ15及びフロアスタンディングランプ14は、例えば、機能性が低下したZigbeeルータノード又はZigbeeエンドノードになり得る。また、RFベースのセンシング目的で優先的にリッスンするように割り当てられるノードのみがZigbeeエンドノードとなるように割り当てられ、このノードがZigbee親デバイスによってコンタクトされる場合にのみRSSI統計をレポートすることも可能である。
他方、子供のベッドルーム35のシーリングランプ13がステップアップ(step up)し、メディアルーム33へのエンターテイメントトラフィックのためのルーティングを提供する。さらに、通常は(例えば、Zigbee)エンドデバイスとして動作する、バッテリ式のHue go照明器具11さえも、高解像度のRFベースのセンシングスキャンが実行されるリビングルーム32からトラフィックを遠ざけるために(消費エネルギが増加するにも関わらず)ルーティングノードとして利用され得る。ブリッジ1とLEDストリップ12との間には、Hue go照明器具11及びシーリングランプ13を経由するルートと、フロアスタンディングランプ14を経由するルートとの2つの論理的ルートがある。フロアスタンディングランプ14が高解像度のRFベースのセンシングスキャンに関与しているので、(典型的なルーティングアルゴリズムは、関与するホップが少ないためフロアスタンディングランプ14を経由するルートを選択するかもしれないが)Hue go照明器具11及びシーリングランプ13を経由するルートが選択される。
第2の例として、テーブルランプ15及びLEDストリップ12が、メディアルーム33で高解像度RFベースのセンシングスキャンを行っており、ブリッジ1からLEDストリップ12へのネットワークルートが決定される必要がある。ブリッジ1とLEDストリップ12との間には9つのルート、すなわち、1-14-12、1-14-13-12、1-14-15-12、1-11-13-12、1-11-13-14-12、1-11-13-14-15-12、1-11-14-12、1-11-14-13-12、1-11-14-15-12がある。照明デバイス15が、RFベースのセンシング機能を割り当てられているため、ノードの第1のサブセットに含まれる。高解像度RFベースのセンシングスキャンへの干渉を防ぐために、フロアスタンディングランプ14は、ネットワークメッセージルーティングを行わないことが好ましく、したがってノードの第2のサブセットに含まれる。テーブルランプ15が第1のサブセットに含まれ、フロアスタンディングランプ14が第2のサブセットに含まれるので、Hue go照明器具11及びシーリングランプ13を経由するルート(1-11-13-12)が選択される。
上記の例では、第1のサブセットの決定は、ノードがRFベースのセンシングエリア機能を割り当てられるかどうかのみを考慮している。第1のサブセットを決定する際に、現在必要とされているRFベースのセンシングスキャンの解像度(例えば、メジャーな動き検出(major motion detection)、マイナーな動き検出(minor motion detection)、真の存在検出、人カウント等)をさらに考慮することにより、選択されるルートは、現在の要件(requirement)にさらによく適合されることができる。高帯域幅のRFベースのセンシングが、マイナーな動きの検出に必要とされる。これにより、センシングアルゴリズムは、以前の閾値/ベースラインに対するワイヤレス通信パラメータの変動が、ワイヤレスチャネルノイズに起因するのか、又は、人がほとんど動かずにラップトップをタイピングしていることに起因するのかを信頼性(confidence)を持って判断することができる。
きめ細かなRFベースのセンシング(fine grained RF-based sensing)は、存在を検出するだけでなく、存在する人の数(又は、1人、数人、大勢といった相対的な人の量)を区別することもできる。きめ細かなRFベースのセンシングでは、毎秒送られるメッセージの量と、空間が占有されているかどうか又はそこに何人の人がいるかを信頼性を持って判断するためのレイテンシとの間にトレードオフがある。したがって、判断を行うのに必要なレイテンシと必要な信頼性との組み合わせに基づいてメッセージ量を調整することが有益である(例えば、家の所有者に警告することを含む侵入者のセキュリティクラスの検出では、信頼度(confidence level)は、ライトをオンにする場合よりもはるかに高い必要がある(後者の場合、フォールスポジティブがあっても、ライトを再度オフにすることにより容易に是正され得るので、害はない)。
真の存在検出(true presence detection)は、RFベースの基本動きセンシング(RF-based basic motion sensing)のさらにきめ細かなバージョンであり、解像度が、椅子に座っている又はソファに伸びている人でも、以前に知られた誰もいない部屋の状況と比較して通信パラメータの変化を分析することによりピックアップされることができるように高められる。したがって、必要とされるセンシング解像度が高いほど、RFベースのセンシングに関連するライト間の通信のデータレートが高くなり、ターゲット占有者検出エリアを囲むネットワークへの負担が大きくなる。
RFベースのセンシングは、人カウントにも使用されることができる。エリア内の10人を区別できるようにすることは、エリア毎に最大3人をカウントするよりも、より高解像度のRFベースのセンシングを必要とする。「多占有者カウント(counting-many-occupants)」モードが、10~20~30人を区別するために最適化されてもよく、一方、「通常モード(normal-mode)」において、RFベースのセンシングは、室内の1~2~3人を高い精度で区別するようにしてもよい。
前述の「高空間解像度」センシングスキャンは、人が部屋Aにいるのか、部屋Bにいるのかを高い信頼性で判断するために使用されてもよい。「高空間解像度」センシングモードはまた、人の軌跡をトラッキングするために使用されてもよい。高空間解像度又は多占有者(many-occupants)のRFセンシングスキャンを実行している間、ライトのグループは、それらの帯域幅の100%がRFベースのセンシングデータの獲得に専念される、特別な「センシングブーストモード(sensing-boost mode)」に入ってもよい。これは、ライトが一時的にZigbeeネットワーク内の他のライトによって到達可能ではない、又はレイテンシがより長くなることを伴ってもよい。ネットワークルーティングは、この「高空間解像度」センシングスキャン、又は人カウント等のためのその他の高解像度スキャンを促進するために一時的に調整されてもよい。
好ましくは、前項で述べたセンシングブーストモードは、オンされている及び/又は安定モード(stable mode)にあるライトによって実行される。安定モードは、ライトが、当面の間変化のない光出力状態のままであることが予想されることを意味する。例えば、バッテリ式のセンサが最近動きを検出した場合、ライトは安定モードにある。これは、ライトが少なくともあと5分は(当該期間に動きが検出されるかどうかに関わらず)オンのままであり、4分のブーストモードの持続時間が、照明制御の観点から許容可能であろうことを意味する。
ライトが(例えば、占有されていない家で)現在オフされいてる場合、ライトは、安全上の理由から、例えば家のエントランスエリアにおいて、高解像度センシングモードの持続時間の間オンにされてもよい。オフィスにおいて、RFベースのセンシングは、15分ごとにオフィスの異常がスキャンされる、夜間のソフトセキュリティのために使用されてもよい。実際には従業員が泊りがけでオフィス内で仮眠をとっていたが、システムは、オフィスに誰もいないと誤認して、あり得る侵入者について高解像度のスキャンを開始する可能性がある。従業員が起床すると、照明システムは0.5秒以内に壁スイッチに応答しなければならない、又は代替的に、レイテンシの影響がある(latency-impacting)高解像度のセンシングスキャンが実行される間、ライトは(恐らくは安全性を確保するために低調光レベルで)オンされる必要がある。
オプションとして、システムは、(ターゲットセンシングエリアとも呼ばれる)RFベースのセンシングハローが、家のあるエリアから別のエリアに移動しているユーザに追従するかどうか及びどのように(例えば、どのような遅延で)追従するかを決定するためにホームオートメーションシステム内の他のセンシングモダリティ(例えば、電子ロック、PIRセンサ、Apple TV)を活用する。例えば、テレビを見ている人がNetflixを一時停止しており、トイレに行きそうであるというコンテキストを仮定すると、RFベースのハローはテレビルーム内に留まり、ユーザに追従しない。しかしながら、人がキッチンに行き、スナックを用意するために冷蔵庫を30秒以上開ける場合、RFベースのセンシングハローは、キッチンへ当該人を追従する。この場合、RFベースのセンシング機能のデバイスへの割り当てが再度行われてもよく、ネットワークルートが再度決定されてもよい。冷蔵庫自体が、例えば、冷蔵庫が30秒以上開けられたことを検出できるようにしてもよい。代替的に、別のタイプの存在センシングが、当該人又は一般に人がより長い時間キッチンにいることを検出するために使用されてもよく、それによってRFベースのセンシングハローがキッチンに移動するようにしてもよい。
RFベースのセンシングは、人を検出するためだけでなく、物体を検出ために使用されてもよい。例えば、RFベースのセンシングは、冷蔵庫及びドアの開きを検出するために使用されてもよい。このコンテキスト情報は、例えば、高齢者介護に役立ち得る。これは、新たに発生する健康状態を示す可能性のあるパターンの変化を検出するために使用され得る重要なデータポイントの収集に役立つ。
Bluetooth Low Energy(BLE)メッシュベースの(例えば、照明)ネットワークでは、(1)通常は照明ネットワークの一部ではないBLEを備えた電子デバイスと(2)BLEライト(又はZigbee/BLEライトを組み合わせたライト)との間のインタラクション(interaction)に基づいてRFベースのセンシングを行うことが可能であり得る。
Zigbeeメッシュベースの(例えば、照明)ネットワークでは、Zigbee/BLEを組み合わせたライトとBLE電子デバイスとの間のRFベースのセンシングインタラクションは、帯域外(out-of-band)通信(Zigbeeの代わりにBLE)によって行われてもよい。この場合、ZigbeeスペクトラムとBLEスペクトラムとの間にいくらかのオーバーラップがあっても、BLEの周波数ホッピングスペクトラム拡散送信(frequency-hopping spread spectrum transmission)がZigbeeの直接スペクトラム拡散送信(direct-sequence spread spectrum transmission)に干渉しないため、照明制御に使用されるZigbeeスペクトル(チャネル)は、RFベースのセンシングスキャンによって影響を受けない。しかしながら、(Zigbee)ネットワークトラフィックは、(BLE)RFベースのセンシングスキャンに干渉しないが、RFベースのセンシングスキャンを行うノードは、(BLE)RFベースのセンシングスキャンを行うために時間が必要であり、ノードがBLEとZigbeeネットワークとの間でタイムシェアリングを実行する単一の無線機を備える場合、この時間の間(Zigbee)ネットワークメッセージを受信するために利用できない可能性がある。
非照明デバイス(例えば、テレビ)によって引き起こされるワイヤレス干渉は、RFベースのセンシングを行うランプの能力に影響を与える。家の第1のノイジーなエリアで信頼性の高い存在検出を行うためには、RFベースのセンシングのデータレートが、通常、ワイヤレス干渉の少ない家の第2のより静かなエリアと比較して増加されるべきである。それゆえ、第1の占有検出ターゲットエリアのランプは、より多くのエアタイムをRFベースのセンシングに割り当て、ネットワークルーティングを行う時間(又はCPU及びメモリ等のリソース)が少なくなるか、又はゼロになる。したがって、好ましくは、ネットワークルーティングは、建物の他の部分のライトをステップアップさせ、照明メッシュネットワーキングキャノピー(lighting mesh networking canopy)により貢献するように、すなわち、どこでもカバレッジの適切なメッシュネットワークバックボーンがあることを保証する助けとなるように調整されるべきである。
本発明のネットワークメッセージを取得する方法の第2の実施形態が図9に示されている。この実施形態では、電子デバイスは、時間の第1の部分をRFベースのセンシングに使用し、時間の第2の部分をネットワークメッセージ、例えば、照明コマンドの送信及び受信に使用する。電子デバイスは、以下の3つのモードのいずれかで動作する。
モード1)通常のZigbeeルータ(通常のメッシュモード)、RFベースの存在及び/又は位置検出:なし。
モード2)機能性が低下したZigbeeルータ(Zigbee router with reduced functionality)、RFベースの存在及び/又は位置検出:あり。
モード3)ZigBeeエンドデバイス、RFベースの存在及び/又は位置検出:あり。
代替的な実施形態では、これらのモードのサブセットのみ、例えば、モード1+2若しくはモード1+3が使用されてもよく、及び/又は、追加のモードが使用されてもよい。このような追加モードの例は、電子デバイスが通常のZigbeeルータとして動作し(通常のメッシュモード)、RFベースの存在及び/又は位置検出も行うモードである。Bluetooth、例えば、BLEがRFベースの存在及び/又は位置検出に使用される場合、これは、電子デバイスがRFベースの存在及び/又は位置検出を実行している間にZigbeeメッセージを受信しないため、効率の低下をもたらす。
最初のステップとして、ステップ180が実行される。ステップ180は、方法を実行する電子デバイスがモード1、2又は3に設定されているかどうかを判断することを含む。図9の実施形態では、図1のブリッジ1は、電子デバイスがどのモードを使用すべきかを該電子デバイスに指示する。代替的な実施形態では、電子デバイスは、どのモードを使用するかを、例えば、自動的に、又はそのネイバー(neighbor)を伴う何らかの決定アルゴリズムを使用して、又は自身のメモリに格納されるコンフィギュレーション設定に基づいて、自身で決定する。電子デバイスがモード2又は3に設定されている場合、ステップ181が実行される。電子デバイスがモード1に設定されている場合、ステップ185が実行される。
ステップ181は、第1の周波数チャネルのセットを選択することを含む。第1の周波数チャネルのセットは、例えば直接スペクトラム拡散の場合、単一のチャネルを含んでもよく、又は、例えば周波数ホッピングの場合、複数のチャネルを含んでもよい。図9の実施形態では、第1のプロトコル、例えば、Bluetoothが、複数の期間の各々の第1の部分の間にステップ141においてこの第1の周波数チャネルのセットで無線周波数信号を送信及び/又は受信するために使用される。ステップ183は、方法を実行する電子デバイスがモード2又は3に設定されているかどうかを判断することを含む。図5のステップ143は、2つのサブステップ、すなわち、ステップ185及び187を含む。電子デバイスがモード2に設定されている場合、ステップ185が実行される。電子デバイスがモード3に設定されている場合、ステップ187が実行される。
ステップ185は、第2の周波数チャネルのセットで、第2のプロトコル、例えば、Zigbeeを使用してワイヤレスに、ネットワークメッセージ、例えば、照明制御メッセージを受信することを含む。これは、複数の期間の各々の第2の部分の間に起こる。第2の周波数チャネルのセットは、例えば直接スペクトラム拡散の場合、単一のチャネルを含んでもよく、又は、例えば周波数ホッピングの場合、複数のチャネルを含んでもよい。電子デバイスがモード1に設定されている場合、電子デバイスは、RFベースの存在及び/又は位置検出のためのRF信号を送信又は受信する必要がないため、ネットワークメッセージ(例えば、照明制御メッセージ)をその間中(entire time)送信及び受信することができる。
この場合、電子デバイスが(RFベースの存在又は位置検出がこのデバイスによって行われないことを意味する)モード1に設定されたままである場合、RF信号、例えば、Bluetooth信号がRFベースの存在及び位置検出のために送信及び/又は受信される第1の部分の継続時間は0秒である。電子デバイスがモード1からモード2又は3に切り替わる場合、第1の部分の持続時間は増やされ、第2の部分の持続時間は減らされる。(図9には示されていない)代替的な実施形態では、電子デバイスは、モード1(すなわち、通常の(Zigbee)メッシュモード(該デバイスはまた、受信したメッセージを転送する))である場合、短い時間間隔でのみ、RFベースの存在及び位置検出のためのRF信号、例えば、Bluetooth信号を送信及び/又は受信する。
図9の実施形態では、電子デバイスがモード3に設定されている場合に実行される、ステップ187は、第2のプロトコルを使用してワイヤレスで送信されるネットワークメッセージを、ネットワークメッセージを代理で受信した他のデバイス(電子デバイスの親ノード)から取得することを含む。電子デバイスの親ノードから取得されるネットワークメッセージは、常に該電子デバイス自身を対象としている。ステップ195が、ステップ187の後に実行される。
ステップ185の後、ステップ189において、ステップ185で受信したメッセージが電子デバイス自身に宛てられているか、又は他のノードに宛てられているかがチェックされる。メッセージが電子デバイス自身に宛てられている場合、ステップ195が実行される。メッセージが他のノードに宛てられている場合、ステップ191が実行される。ステップ191は、電子デバイスがモード1又は2に設定されているかどうかをチェックすることを含む。モード1において、受信したメッセージはステップ193において転送される。モード2において、受信したメッセージは転送されず、次にステップ181が実行される。代替的な実施形態では、他のノードを意図した受信メッセージは、選択的に転送される、すなわち、決して転送されないのではなく、常に転送されないが、時として転送される。
ステップ195は、ステップ185又は187で取得したメッセージがモードコンフィグメッセージ(mode config message)であるかどうかを判断することを含む。そうである場合、電子デバイスは、ステップ197において、このモードコンフィグメッセージで指示されるモードに設定される。そうでない場合、取得されたメッセージはステップ198において通常通り処理され、ステップ198の後にステップ181が実行される。ステップ197の後、ステップ199において、新しいモードがモード1であるかどうかがチェックされる。そうである場合、次にステップ185が実行され、それによりステップ181、141及び183はスキップされる。そうでない場合、次にステップ181が実行される。
ステップ181の次の反復において、任意選択的に、ステップ181の前の反復とは異なる周波数チャネルのセット、例えば、第3の周波数チャネルのセットが選択されてもよい。そうである場合、第1のプロトコルが、ステップ141の次の反復において、この異なる、例えば、第3の周波数チャネルのセットでRF信号を送信及び/又は受信するために使用される。RF信号がRFベースのセンシングに使用される場合、このRF信号は、好ましくは、ある空間エリア内で一意である。好ましくは、RFベースのセンシング専用の(例えば、Zigbeeの)帯域は、ローカルに一意であり、家又は建物のフロア内でRFベースのセンシングを行うデバイス、例えば、ランプの各グループごとに異なる。したがって、RFベースのセンシングを行うデバイス(例えば、ランプ)の各グループは、(例えば、照明)制御ネットワーク又はRFベースのセンシングを行うデバイス(例えば、ランプ)の他のグループのニーズを考慮する必要なく、(例えば、Zigbee)メッセージストームを送信することができる。これは、最適なセンシング性能をもたらす。
複数の機能を有するRF送信機及び/又は受信機、例えば、デュアル無線トランシーバが使用されてもよく、1つの機能、例えば、BLE無線機能がステップ141を実行するために使用され、別の機能、例えば、Zigbee無線機能がステップ143を実行するために使用されてもよい。代替的に、複数の送信機及び/又は受信機が、それぞれステップ141及び143を実行するために使用されてもよい。
一例として、図9の方法は、家の照明システムにおいてRFベースのセンシングを行うために使用されてもよい。この例では、専用のZigbeeチャネルがRFベースのセンシングに使用され、異なるZigbeeチャネルが照明制御(ネットワークメッセージ)に使用される。RFベースのセンシングのタスクを現在割り当てられているライトは、ほとんどの時間、ローカルに一意の、専用のワイヤレスチャネルを利用するZigbeeRFベースのセンシングモードにおいてフルブラストで動作する(すなわち、家レベルのZigbee照明ネットワークとの干渉はない)。ごく一部の時間、RFベースのセンシングを行うライトは、Zigbee照明ネットワークに参加する。
照明ネットワーク内では、一般的に、このようなRFベースのセンシングを行うライトは、(モード3で動作する)スリーピーな(sleepy)Zigbeeエンドデバイス、又は(モード2で動作する)機能性が低下したZigbeeルータとして動作してもよい。ライトがZigbeeエンドデバイスとして動作する場合、ライトは、時折のみ(例えば、0.5秒以上ごとに)、自身の親ノードから、家レベルのZigbeeネットワークから代理で受信された照明制御メッセージを取得する。ライトは、RFベースのセンシングスキャンに入ると、(モード1で動作する)通常のメッシュノードから(モード3で動作する)エンドノードへと遷移し、それに応じてライトはZigbee親ノードを決定してもよい。
代替的に、ライトは、RFベースのセンシングスキャンに入ると、(モード1で動作する)通常のメッシュノードから(モード2で動作する)機能性が低下したZigbeeルータに遷移してもよい。この場合、ライトは、メッシュからメッセージを受信するためにZigbeeネットワーク上で定期的に(ただし、コンスタントではない)到達可能になる。しかしながら、ライトは、メッシュネットワーク上の他のライトからのメッセージのルーティングには貢献していない。モード1で動作するライトは、ロバストな家レベルのメッシュネットワークのバックボーンを提供している。代替的な実施形態では、ライトは、RFベースのセンシングスキャンを行う場合、Zigbeeネットワーク上で公式に(一時的に)到達不能になることができてもよく、ライトは、親デバイスのメールボックスを定期的にチェックすることなく、メッシュネットワークにレポートバックするだけでもよい。
上記の例では、Zigbeeチャネルが、RFベースのセンシングを行うために使用されている。また、(1)BLE(Bluetooth Low Energy)を備えた家電機器と、(2)優勢的にBLEモードで動作するデュアル無線ライトとの間の帯域外インタラクションに基づいてRFベースのセンシングインタラクションを行うことも可能であり、この場合、ライトはBLEを介して家電機器とインターフェースし、このようにしてBLEベースのRFセンシングペアを形成する。
RFベースのセンシングに少なくとも1つの家電機器を含めることが有利である。ほとんどの照明ノードは天井に取り付けられる。しかしながら、2つのシーリングライト間のRFベースのセンシングは、床に近い物体(例えば、小さな子供)の検出品質を制限する。家電機器(例えば、TV、音声アシスタント)は、照明デバイスよりも低い高さに位置する。したがって、RFベースのセンサの1つとして家電機器(例えば、テレビ)を含めることが有利である。この場合、RFベースのセンシングによって検出されるべき人間のバイオマスが、シーリングライト及び家電機器の間にあるからである。家電機器の代わりに、天井に取り付けられていないライトデバイスが含められてもよい。
家電機器(consumer electronics device)でRFベースのセンシングを行う場合、ライト及びCEデバイスは必ずしもネットワークを形成する必要はない。例えば、ライトは、各CEデバイスによって送出されるBLE広告のRSSIを(スカベンジング(scavenging)アプローチを用いて)分析してもよい。また、ライトは、故意にメッセージを送出するためにBLEデバイスをトリガしてもよい。例えば、ライトは、BLE参加要求を送信し、これは、最終的には該ライトによって許可されないが、それにもかかわらず、RSSIが埋め込まれているので、センシングに使用されることができるレスポンスをトリガする。
家のあるエリアで低解像度のRFベースのセンシングスキャンを行うライトは、照明システムによって使用される標準的なZigbee照明制御バンドでこれを行ってもよく、一方、高解像度のスキャンを行うライトは、別の専用ワイヤレスバンドを使用してもよい。好ましくは、ライトの各々の周波数チャネル選択はまた、占有検出ターゲットエリアの各々に現在必要なRFベースのセンシング解像度、特にメジャーな動き検出、マイナーな動き検出、真の存在検出、人カウント、体の姿勢検出、ジェスチャ検出が必要かどうかを考慮する。
高帯域幅のRFベースのセンシングは、マイナーな動き検出若しくは人カウントに、又は人が部屋Aにいるのか、部屋Bにいるのかを高い信頼性で判断するために使用される「高空間解像度」のセンシングモードに必要とされる。したがって、必要とされるセンシング解像度が高いほど、RFベースのセンシングに関連するライト間の通信のデータレートが高くなる。さらに、RFベースのセンシングメッセージを経時的に拡散させる(すなわち、時間軸上でこれらを均等に分散させる)ことで、長いブラインド期間(prolonged blind period)がないため、最高の占有検出となる。通常のRFベースのセンシングは、デバイスごとに毎秒3メッセージであってもよく、一方、高解像度スキャンは、毎秒10メッセージ、さらには毎秒100メッセージを採用してもよい。
非照明デバイス(例えば、テレビ)によって引き起こされるワイヤレス干渉は、RFベースのセンシングを行うランプの能力に影響を与える。家のノイジーなエリアで信頼性の高い存在検出を行うことができるためには、RFベースのセンシングのデータレートが家の第2のより静かなエリアと比較して増加される必要があるか、又は、RFベースのセンシングのためのワイヤレスチャネルが変更される必要がある。
家の異なるエリアは異なるワイヤレス干渉源に曝されるため、エリアの各々についてRFベースのセンシングのための専用の比較的「静かな」ワイヤレスチャネルを選択するのが有利である。特定のエリアについて選択される帯域外ワイヤレスチャネルは、経時的に変化してもよい。例えば、RFベースのセンシングセッションごとに、チャネルが新たに決定されてもよい。これは、1つのセンシングセッション中に行われてもよい。得られるセンシング結果が期待したほど正確でない場合、帯域外チャネルが変更されてもよい。しかしながら、新しいチャネルを選択することは、新しいチャネルのためのベースラインが決定される必要があるため、いくらかのレイテンシを招く可能性がある。
システムが、1つのチャネルに決定する前に(達成されるセンシングエリア品質の評価を含む)あるアエリアについての複数の帯域外チャネルの試行を意図的に行うことも可能である。例えば、試行は、チャネルの各々に対するRFベースのセンシングのフォールスポジティブ又はフォールスネガティブの数を分析することを含んでもよい。オプションとして、1つの帯域外のRFベースのセンシングスキャン(one single out-of-band RF-based sensing scan)は、サブスキャンを融合することにより占有検出の精度を高めるために、明確に異なるワイヤレスチャネル(例えば、最低周波数802.15.4のバンドと最高周波数802.15.4のバンド)を利用してもよい。また、WiFiライトの場合、最新のWiFi無線機で利用可能な複数の指向性アンテナを利用する、ワイヤレス送信の異なる方向性が採用されてもよい。
物理的な位置が簡単に変えられることができるライト(例えば、Philips Hue Go)の場合、帯域外チャネルの選択は、(1)直前のRFベースのセンシングセッションの精度と、(2)ライトが最近移動又は回転されたかどうかについてある信頼性を与えるライトのオンボードセンサとの組み合わせに基づいてもよい。
さらに、2つの異なるRFベースのセンシングペアのライトペアは、同じ帯域外チャネルを利用することを選択できる。例えば、ライトは、(1)関与する照明器具の物理的特性(照明器具の配置高さ、照明器具の材料)及び(2)変更され得、RFベースのセンシングに影響を与え得る、関与する照明器具のパラメータ(無線送信電力、照明器具の蓋の開閉、熱安定性等)を考慮して、2つのライトのペアによって生成されるそれぞれの動きシグネチャ(motion signature)が十分に異なるため、2つのRFベースのセンシンググループ間の干渉にもかかわらず、信頼性のある占有検出が実行されることができることを結論付けてもよい。これは、利用可能である適切な帯域外チャネルがほとんどないエリア(例えば、2.4GHz帯の多くが混雑しているニューヨーク市のアパート等)に関連する可能性がある。
最後の数ページの説明は、RFベースのセンシング(存在検出)アプリケーションを述べているが、述べられた原理の一部は、RFベースのアセットトラッキング(位置検出)アプリケーションにも適用可能であり得る。次の数ページでは、RFベースのアセットトラッキングアプリケーションでネットワークメッセージを取得する方法の第3の実施形態が述べられる。しかしながら、述べられた原理の一部は、RFベースのセンシングアプリケーションにも適用可能であり得る。
さらに、一部の実施形態では、同じ照明システムが、(ビーコンを持たない物体についての)RFベースの動き/存在検出、及び、BLEを備えたアセットのアセットトラッキングの両方を実行してもよい。一部の実施形態では、病院のクラッシュカート又はBLEビーコンを備えたバッジを持つ従業員等の同じ物体が、RFベースのセンシングシステム及びBLEアセットトラッキングシステムの両方によって検出され、両方のセンシングモダリティが、クラッシュカートのムーブメント(crash cart movement)に対する位置精度及び応答時間を向上させるために照明システムによってマージされてもよい。また、このシステムで述べられるビーコン送信は、アセットの温度、アセットの向き(医療用コンテナが逆さまになった場合にフラグを立てる)、医療用クールボックスのバッテリ状態等、他のセンシングデータを含んでもよい。
この第3の実施形態では、L1~L10とラベル付けされ、図10に示される、10個の照明器具201~210が、異なるモードで動作する異なる照明器具グループにグループ化される。グループの構成は経時的に変化し、その結果、照明器具によって実行されるRFベースのアセットトラッキングの量及びメッセージ転送の量も経時的に変化する。Bluetooth Low Energy(BLE)ビーコン(例えば、ビーコン219)が、アセット(例えば、物体、動物及び/又は人)の位置が決定されることを可能にするために、アセットに取り付けられている。
コントローラ、例えば、図1のブリッジ1は、ビーコン受信モード(BRM:beacon receiver mode)の照明器具201~205(L1~L5)から成る第1のグループG1を割り当てる。ビーコン受信ノードは、BLEビーコンを収集し、アセットに取り付けられたBLEタグから受信する信号のRSSIを決定する。同時に、これらのノードは、照明制御データ及びアセットトラッキング関連データをコントローラと交換する、並びに、照明関連コマンドのために、Zigbeeネットワークを断続的にリッスンする(例えば、BRMモードのノードは、99%BLEをリッスンし、1%Zigbeeをリッスン及び送信してもよい)。BLEモードとZigbeeモードとの間の時間配分、及び、これらのデバイスが自身の親ノードをチェックする頻度は、固定されてもよく、コントローラデバイスによって可変的にコンフィギュレーションされてもよく、又は受信したビーコン信号に基づいて動的に変化してもよい(例えば、G1デバイスが「新しい」アセットを検出する場合、G1デバイスは、すぐに自身の親(又は自身の親を介してコントローラ)に通知してもよく、一方、エリア内に静止しているアセット又はトラッキングされることがそれほど重要ではないデバイスであるアセットに関連する測定値は、ある間隔で集約されたメッセージで送信されてもよい)。残りの照明器具206~210(L6~L10)(グループG2)は、自身のBLE(受信)機能性が非アクティブにされる、又は、BLE機能性がごく短い時間割合(percentage of time)だけアクティブにされる通常のZigbeeルータ(ネットワークキャノピーモード(NCM:Network Canopy Mode)としてコンフィギュレーションされる。
BRMデバイスは通常のZigbeeルータとしてコンフィギュレーションされる一方、例えば、それらのうちの一部、例えば、L1が、(BLEビーコンをリッスンするようにコンフィギュレーションされるので)いくらか/ほとんどの時間Zigbeeネットワークをリッスンしていない場合、これは、Zigbeeネットワーク上でパフォーマンスの問題を引き起こす可能性がある。なぜなら、L1にメッセージを送信することを試みる、「通常の」デバイス、例えば、L7は、L1が(いくらか/ほとんどの時間)Zigbeeをリッスンしていないので、メッセージ配信が失敗することに典型的には気付くことになるからである。Zigbeeの基本的なメカニズムは、いくらか/ほとんどの時間利用可能ではないデバイスのために準備されていない。
したがって、G1内のすべての照明器具は、例えば、Zigbeeエンドデバイス(又は、機能性が低下したルータ)として動作するようにコンフィギュレーションされ、したがって、Zigbeeメッシュネットワークに(完全に)参加していなくてもよい。G1の照明器具の各々は、Zigbeeルータデバイスのうちの1つ(例えば、L6)を親として選択し、当該親は、(子と呼ばれる)L1デバイスとのZigbee通信に使用される。デバイスL7がそのような子デバイスにメッセージを送信したい場合、L7は、親デバイスL6にメッセージを送信する。親デバイスは、子(例えば、L1)の代理で当該メッセージを保存する。子L1は、典型的には、保留メッセージについて自身の親L6と定期的にチェック(「ポーリング」)し、それらを取得して処理する。Zigbeeネットワーク上のいずれかのデバイスにメッセージを送信したい子L1は、自身の親L6にメッセージを送信し、親は、そのデスティネーションへのZigbeeメッシュを介したメッセージのさらなる中継を担う。
G1のノードは、自身の親とZigbeeで通信するために限られた期間しか必要としないため、ほとんどの時間BLEメッセージをリッスンすることができる。このアプローチは、G1デバイスがBLEビーコンの高品質なアセットトラッキングを行う能力を最大限にする。また、これは、(G2ノード間のZigbee通信は、Zigbeeで通常通り機能し、G1-G2通信は、通常のZigbee子-親通信であるため)上述したZigbeeのグループキャスト/ブロードキャストの特異性(Zigbee groupcast/broadcast peculiarity)を回避する。
G1デバイスは、アセットトラッキングデータを収集し、自身の親を介して他のデバイスに(可能であればフィルタリング及び集約(aggregation)後に)送信する。アセットトラッキングデータは、最終的にはG2デバイスのうちの1つ以上、又はG2デバイスのうちの1つ以上を介して接続されるデバイスに行く。また、すべてのデバイスは、照明ネットワークとしても機能し、中央又は分散インテリジェンスから制御されることができる。G2デバイスは、Zigbeeルータデバイスであるので、直接到達されることができる。G1デバイスは、(G2デバイスである)自身の親を介して到達されることができる。また、同じ照明Zigbeeネットワークは、G1/G2デバイス又は他のZigbeeデバイスからスイッチ/センサデータを収集するために使用されることもできる。
Zigbee子-親通信のためのタイムスロットは、デバイスが、いつBLEビーコンが典型的に到来するかを学習し、したがって自身のZigbee通信のためにそれらのタイムスロットを避ける場合、子によってインテリジェントに選択されることができる。
Zigbeeネットワーク上の一部のデバイスが照明を制御するためにコマンドを送信する場合、これらは、ルータデバイス、例えば、L2によって直ちに受信される。これらは、子デバイス、例えば、L1のためにコマンドを保存し、子デバイスがその親をポーリングする場合にのみ、子デバイスは、保留メッセージを見つけ出し、自身の照明レベルを適合させることができる。これは、例えば、ポーリング間隔が1秒に設定されている場合、ライトL1は、ライトL6と比較して0~1秒遅れた応答を有することを意味する。特定の状況では、1秒の遅延は許容される。例えば、ライトがオンされていて、ユーザが壁スイッチを押してライトを調光又はオフにする場合、背景照明の別のソースが部屋で既にオンされている場合、エンドユーザが壁スイッチボタンを押して即座の応答を期待するのではなく、システムからのタイムスケジュール/動きセンサに基づいてライトが自動的に切り替えられる場合等である。この場合、グループG2の照明器具は、調光コマンドに直ちに反応する(したがって、壁スイッチボタンの押下が処理されているという視覚的なフィードバックをユーザに提供する)。
グループG1の照明器具は、遅れた応答を有する。G2とG1との間の遅延は、すべてのライトにフェードトランジション(faded transition)(例えば、オフまでに3秒のフェードタイム)を採用することにより緩和されることができる。また、G1は、G1が最終的に調光コマンドを受信するとG2に「追いつく(catch up)」ようにコンフィギュレーションされてもよい。G2とG1との間の遅延はさらに、1つ以上のルータデバイス、例えば、L6が、1つ以上の自身の子デバイスのための(タイムクリティカルな)メッセージを受信するとBLEメッセージを送信し、これらの子デバイスにそれらの親をポーリングする必要があることを認識させることにより緩和されることができる。また、BLEメッセージに、タイムクリティカルなメッセージの関連する本文を含めてもよい。これは、照明デバイスについてのエンドデバイスの挙動に関連するレイテンシをなくすであろう。
G2とG1との間の遅延はさらに、照明制御、ライトデバイス及びセンサからのデータの収集、並びに、BLEビーコンデータの収集に必要とされる通信を可能にするために以下のメカニズムを採用することにより緩和されることができる。ライトがオフされている場合、ポーリングレートが上げられ、ゆえに、知覚されるスイッチオンのレイテンシが減らされる。ライトがオンされている場合、ライトは、典型的には、最後の人がエリアを出た後しばらくしてから(動きセンサ)又は人が退出時にエリアの周囲にある中央ライトスイッチを操作する場合にオフするため、(知覚される)スイッチオフのレイテンシはあまり気にならないので、ポーリングレートは減らされる。
BLEビーコンデータは、1つのビーコンが受信される場合、複数のビーコンがグループ化される場合、又はビーコンデータがさらに処理される場合(例えば、特定のビーコンからの複数のRSSI値を平均して集約値にする等)、L1からL6に直接送信されることができる。アセットトラッキングのレイテンシと、子からその親へのビーコンデータ取得についてのZigbee送信時間(したがって、BLEビーコンのリスニングに利用可能な時間)との間には、トレードオフがある。
好ましくは、グループG1及びG2の構成は、経時的に変化する。これは、グループG1及びG2のすべてのデバイスに対してBRMとNCMとの間で機能をローテーションすることにより実現されてもよい。グループG1、G2のすべてのデバイスに対するBRMとNCMとの間での機能のストレートスワップ(straight swap)は、Zigbeeネットワークがしばらくの間最適ではない状態になる、また、どのデバイスが存在するか(及びその信号強度)を知らずにBLEビーコン受信が初期状態になる可能性がある。それゆえ、例えば、先ずNCMノードの数を増やす、先ずNCMノードの数を減らす、又は、BRMノードの数を一定に保つ等、より緩やかな変更(gradual change)が有益であり得る。
より緩やか変更のためのいくつかのオプションが図11に示されている。照明器具L1~L10は、それぞれ列201~210により表されている。第1のオプションとして、期間211~213において、NCMノードの数が先ず増やされる。期間211において、各BRM/NCMグループは、5つのネットワークノードを含む。L1~L5は、BRMノードであり、L6~10は、NCMノードである。期間212において、1つのノード(L5)が、BRMからNCMに切り替えられる。ある時間後、期間213において、別のノード(L10)が、元々の比率に戻すためにNCMからBRMに切り替えられる。
第2のオプションとして、期間214~216において、NCMノードの数が先ず減らされる。期間214において、各BRM/NCMグループは、5つのネットワークノードを含む。期間215において、1つのノード(L10)が、NCMからBRMに切り替えられる。ある時間後、期間216において、別のノード(L5)が、元々の比率に戻すためにBRMからNCMに切り替えられる。
第3のオプションとして、期間217~218において、ダイレクトスワップが行われる。期間217において、各BRM/NCMグループは、5つのネットワークノードを含む。期間218において、1つのノード(L5)が、BRMからNCMに切り替えられ、(ほぼ)同時に別のノード(L10)が、元々の比率を維持するためにNCMからBRMに切り替えられる。代替的に、他のオプションが使用されてもよい。
図11に示されるステップの繰返し適用が、グループG1及びG2のデバイスの役割のスワップを実現するために使用されてもよい(図12参照)。図12の例では、第1のオプション(「先ずNCMノードの数を増やす」)のステップ211~213が数回繰り返される。期間234において、1つの別のノード(L4)が、NCMからBRMに切り替えられる。ある時間後、期間235において、別のノード(L9)が、元々の比率に戻すためにBRMからNCMに切り替えられる。期間236において、1つの別のノード(L3)が、NCMからBRMに切り替えられる。ある時間後、期間237において、別のノード(L8)が、元々の比率に戻すためにBRMからNCMに切り替えられる。
期間238において、1つの別のノード(L2)が、NCMからBRMに切り替えられる。ある時間後、期間239において、別のノード(L7)が、元々の比率に戻すためにBRMからNCMに切り替えられる。期間240において、1つの別のノード(L1)が、NCMからBRMに切り替えられる。ある時間後、期間241において、別のノード(L6)が、元々の比率に戻すためにBRMからNCMに切り替えられる。
図12の211から241までの一連のステップは、すべての関与するノードの役割を入れ替えている。このようなスワップの目的は、ある時点でL1~L5付近のアセットをより正確にモニタリングできるようにすること、及び、別の時点でL6~L10付近のアセットを正確にモニタリングできるようにすることである。したがって、正確なアセットトラッキングがすべてのロケーションで可能である。ローテーションメカニズムが適用されなかった場合、正確なモニタリングは一部のノードの付近でのみ可能であり、他のノードの付近では可能ではなく、全体のエリアのカバレッジが不均等になる。
また、同様の変更方法は、(例えば、新しいアセットが空間に入ってきた場合にトラッキング性能を向上させるために)システム内のG1/G2ノードの異なる比率を動的に変更するために使用されることも可能である(図13参照)。期間261において、各BRM/NCMグループは、5つのネットワークノードを含む。期間262において、一部のノード(L1及びL5)が、BRMからNCMに切り替えられ、これによりNCMノード数を増やす。期間263において、各BRM/NCMグループは、5つのネットワークノードを含む。期間264において、一部のノード(L7及びL10)が、NCMからBRMに切り替えられ、これによりBRMノード数を増やす。
ルータRからエンドデバイスED(又はその逆)への切り替えは、Zigbeeデバイスにとって簡単ではない。なぜなら、仕様(ここでは適用可能ではない、デバイスが、親が該デバイスのための空間がない場合、参加時にEDからRに又はその逆にフォールバックすることができるという言及を除く)及び典型的な実装は、このために準備されていないからである。例えば、他のデバイスからEDとして知られているデバイスが黙って役割を切り替え、Route Request(ルートリクエスト)メッセージを送信する場合、これは、(EDからのRoute Requestを予想していないため)他のデバイスを混乱させる可能性がある。このセクションは、どのようにしてこのような切り替えが、望ましくない副作用なしにZigbeeシステム内で実行することができるかを述べる。
役割変更の両方向(ED=>R及びR=>ED)について、デバイスは、Leave(離脱)メッセージを送信する(ゆえに、該デバイスと直に隣接する他のデバイスは、該デバイスが最早ネットワークに存在しないことを認識する。これにより、他のデバイスは、該デバイスとその役割を「忘れる」、すなわち、このデバイスに関して保存されている永続的及び一時的な情報をすべてクリアする。)これは、ネットワーク内の他のデバイスに追加の変更を必要とすることなく、標準に準拠した方法で変更を可能にする。デバイス自身は、Zigbeeチャネル、並びに、PAN、EPID、ネットワークキー、ネットワークアップデートID、ショートアドレス、Trust Center(トラストセンター)アドレス、(使用されている場合)Trust Centerリンクキー等の他の関連するネットワーク特性を覚えている。そのため、役割を変更した後、該デバイスは、再びネットワークの一部となり、新しい役割で機能することを開始することができる。該デバイスは、保存されているネットワークパラメータ及びクレデンシャルを使用してネットワークに再び参加する。
集中セキュリティモード(centralized security mode)(すなわち、Trust Center)が使用される場合、デバイスは、Trust Centerで(新しい役割で)自身をアナウンスする必要がある。以前に送信されたLeaveメッセージ(又は親によって結果として生成されるUpdate device(アップデートデバイス)メッセージ)がTCに到達している可能性があるため、TCが、デバイスが役割を切り替えることに関するすべての情報を削除すること、が防止されるべきである。役割切替(role switching)を担うオーケストレータ、例えば、図1のコントローラ1は、Trust Center自身である可能性があるため、どのデバイスが役割変更(role change)に指名されたかを覚え、指名されたデバイスからステータス0x02=デバイス離脱(device left)を持つLeave/Update Device(離脱/アップデートデバイス)を受信すると、Trust Centerは、エントリを完全に削除するのではなく、このデバイスに関する何らかの情報(例えば、デバイスタイプ)を適応させることができる。
ED=>R:役割を変更した後、Rとして機能するEDは、メッシュ内の自身の接続性を維持するために(通常は15秒間隔で送信される)Link Status(リンクステータス)メッセージを定期的に送信することを開始する。1つのこのようなメッセージは、近隣の他のRデバイスが新しいデバイスを認識できるように、ネットワークに再参加した直後に送信されることが好ましい。新しく追加されたデバイスがLink Statusメッセージで空のネイバーリストを持つことに気付く、このような他のRデバイスは、(通常の15秒間隔よりも)早く自身のLink Statusメッセージで応答してもよく、ゆえに、新しいデバイスは、自身のネイバーテーブルをセットアップするために周囲にある他のルータを知り、斯くして、メッシュを介して通信する準備をする。
役割を変更したデバイスのルーティングテーブルを迅速に構築する代替的なやり方は、Rに切り替える場合にこれらのテーブルを事前ポピュレート(pre-populate)することである。例えば、
- 最後にRであった時のテーブルで開始する(古いものである可能性があり、一部のデバイスは最早Rではない可能性がある)、
- (この時点で誰がRであるかを知っている)オーケストレータによって提案される初期ネイバーテーブルで開始する。オーケストレータ又はデバイスは、各接続の(履歴又は最近の)リンクコストを知っている可能性がある。
- 第一近似として、Rに切り替わるEDノードは、EDであった時の何らかの情報を再利用することができる。例えば、自身の親ルータを自身のNTに残しておき(これは、既にメッシュとの接続を与えるであろう)、Rの役割を続けることでNTを拡張することができる。
いずれの場合も、受信したメッセージに基づいてエントリ(ネイバーリスト及び関連するリンクコストの両方)を更新することは、通常とは異なるやり方で行われてもよい(例えば、異なる重みが、経時的に値を平均化するために使用されることができる、(リンクステータスメッセージだけではなく)追加のメッセージが、近隣ノードを追加するために使用されてもよい、メッセージを送信する頻度が、増加されてもよい、等)。なぜなら、事前ポピュレートされたデバイス及びリンクコストは、古いものであって、したがってライブデータよりもあまり「信用(trustworthy)」がない可能性があるからである。
(通常の「ゼロからのスタート(starting from scratch)」に勝る)これらの方法の利点は、ネイバーテーブルをポピュレートするためにデバイス間で送信するメッセージの数が少なくて済むことである。他のアプローチは、EDが、EDとしての動作中に、Zigbeeトラフィックをリッスンして(プロミスキャスモード(promiscuous mode))、信号強度及びアドレス情報を含め、どのデバイスが近隣にあるかを学習し、斯くして、(Rに役割を変更した後に)この情報を使用してRとしての機能を開始することである。
R=>ED:RからEDに役割を変更する前に、Rが、切替(switch)により影響される可能性のある機能を実行しているかどうか、例えば、他のZEDの親であるかどうか、他のデバイスの代理でルーティングをしているかどうか、すなわち、(コンセントレータ/Trust Center/オーケストレータへの多対一のルート以外の)ルーティングテーブルのエントリを持っているかどうか、及び/又は、プロキシとしてGreen Power Deviceの代理で通信を転送しているかどうか、がチェックされてもよい。もしそうであれば、切替の影響を最小限にするためのアクションが取られてもよい。例えば、切り替え(又は離脱メッセージの送信)の直前に、Rは、新しいルートが発見されることができるように、ルート障害のステータス(status route failure)を持つネットワークステータスメッセージを送信することができる(関連するルートディスカバリ(route discovery)が開始される際にまだ存在する場合、ルータは、ルートレコード(route record)メッセージを転送することを控えることができる)。
自身のZEDの子らに対処するために、切り替わるデバイスは、(Rejoin=TRUEを持つ)Leave Request(離脱リクエスト)メッセージを送信し、斯くして、ZEDの子に新しい親を探索させることができる(ZEDがペアレントディスカバリ(parent discovery)を開始する時点でまだ存在する場合、切り替わるRは、NWK再参加要求(rejoin request)に応答することを控えることができる)。代替的に、オーケストレータ、例えば、図1のコントローラ1は、実際の切り替えの前又は後に、例えば、別のノードにGPDのためのProxy Table(プロキシテーブル)エントリを作成する、ネットワークステータス(ルート障害)メッセージを送信する、又は、切り替えようとしているRの子であるZEDにRejoin=TRUEを持つMgmt_Leave_Requestメッセージを送信する等の切り替えの態様を担うことができる。
役割を変更した後、EDとして機能するRは、親デバイスを見つける必要がある。通常、この処理は、EDがMAC Beacon(マックビーコン)メッセージ(又はNWK再参加(rejoin)メッセージ)を送信することを伴い、それを受信したすべてのR(Beaconの場合、他のZigbeeネットワークのRも含む)の応答が後続し、返信してきたRデバイスから潜在的な親を選択する。これは(時間的及びネットワーク負荷的に)あまり効率的ではないので、EDがRとして機能するために使用されていたネットワークのPANID及び動作チャネルにネットワーク検索(network search)を制限する等、最も明らかな改善に加えて、いくつかの追加的な改善が使用されることができる。例えば、
- デバイスは、以前の期間で最も良い(例えば、最も低いリンクコストの)ネイバー(Rデバイス)をRとして覚え、当該Rに(セキュアな)NWK Rejoin Request(ネットワーク再参加要求)を送信してもよい。
- その役割をRからEDに変更することをデバイスに指示する、オーケストレーションを行うデバイス、例えば、図1のコントローラ1から提案される親での事前コンフィギュレーション。これは、ブロードキャストメッセージとしてネットワーク全体に送信されてもよい。そのようなメッセージを送信することは、Leaveメッセージの送信及び親探索(parent search)を廃れさせる。さらに、このような専用メッセージを受信することにより、受信デバイスは、切り替わるノードに関する変化しない情報、例えば、バインディング情報(binding information)を保持し、変化する情報(例えば、NTエントリ及びルーティングテーブルエントリ)のみをパージ(purge)することができる。また、このメッセージは、例えば、ルートリペア(route repair)を引き起こすための専用メッセージの必要性を失くす。
- さらに別の実装形態では、Leaveメッセージを送信してから親を選択するのではなく、RからEDに切り替えようとしているノードが、役割切替に関する情報、及び、新たに選択された親(例えば、リンクコストが最も良いネイバーR)のアドレスの両方を含む、新しいメッセージを送信することができる。そのようなメッセージを送信することは、Leaveメッセージの送信及び親探索の必要性を失くす。さらに、このような専用メッセージを受信することにより、受信デバイスは、切り替わるノードに関する変化しない情報、例えば、バインディング情報を保持し、変化する情報(例えば、NTエントリ及びルーティングテーブルエントリ)のみをパージすることができる。また、このメッセージは、例えば、ルートリペアを引き起こすための専用メッセージの必要性を失くす。
デフォルトでは、ネットワークから離脱するデバイスは、バインディング、グループメンバーシップ等、以前に使用していた制御情報を忘れる(削除する)。明らかに、ライト制御は、役割変更オペレーション後も継続する必要があり、ゆえに、このような情報の損失は避けられるべきである。第1のステップとして、デバイスはこの情報を覚え、役割を変更した後に再利用することができる。いくつかの例(「スイッチ」は「センサ」と読まれることもできる):
- ランプはスイッチから制御され、スイッチがLeaveメッセージを送信する。通常、スイッチは、どのランプを制御していたかを忘れてしまう。好ましい実装形態では、スイッチは、制御していたランプのリストを覚えておく。リストは、ユニキャスト又はグループキャストアドレスのリストであってもよい。
- ランプはユニキャストでスイッチから制御され、ランプがLeaveメッセージを送信する。スイッチは、(Leaveメッセージのため)自身のバインディングテーブルからランプを削除し、ゆえに、ランプ(又はオーケストレータ、例えば、図1のコントローラ1等の別のデバイス)は、バインディングを再確立する必要がある。
- ランプはグループキャストでスイッチから制御され、ランプがLeaveメッセージを送信する。スイッチは、(送られるのはグループであるため)自身のバインディングテーブルからランプを削除せず、ゆえに、ランプは、自身のグループのメンバーシップ及び関連する設定を覚えておく必要がある。
(特定のコマンド機能をネーミングする)上記のメカニズムのいくつかは、現在のZigbee規格の使用を前提としている。もちろん、Zigbeeメカニズム及びメッセージに対する拡張(例えば、「I'm switching role(私は役割を切り替える)」メッセージ)を定義し、(潜在的にメッセージの数を減らす、又は収束を早めることを伴う)よりスムーズな切替を実現するためにこれらをデバイスに実装してもよい。
照明器具のほんの一部がビーコン受信機として動作する密な照明器具のグリッドの場合、RSSIビーコン受信機の機能性は、第1のライトから、第1のライトに隣接せず、むしろ離れている第2のライトに意図的にローテーションされてもよい。これは、ローテーション前及びローテーション後の期間に取得される集約されたRSSIデータを用いるアセットの適切なトリラテレーション(tri-lateration)を保証する。
G1及びG2の間で役割をリバース(reverse)する瞬間は、全体的なアプリケーション及びエンドユーザ体験に対して予想される混乱が最も少ないことに基づいて選択されてもよい(例えば、あるエリアのライトが現在オンされている場合、役割のリバース(role reversal)の実行に起因するいくらかの照明レイテンシを導入することは許容される、又は、システム内の一部の照明器具が高解像度のRFベースのセンシングスキャンを行っている場合、高解像度のRFベースのセンシングスキャンを尊重し、したがってそれが終了するまで待つ)。
1つ以上の中央ノードが、様々なノードからのRSSIデータを収集する。アセットからのRSSIデータは、各ノードでパートタイム(part-time)にしか収集されないため、アセットトラッキングシステムは、欠落するRSSIデータサンプル、及び、ある時間前にサンプルされたものであるという事実に対処する必要があり、ビーコンを受信する複数のネットワークノードが同時にビーコンを(アクティブに)受信し、処理しないとしても、これら複数のネットワークノードからの総合データ(combined data)を活用することもできる。
これは、改善されたアセットのトリラテレーション及び/又はそのトラッキングを有利に提供することができる。処理は、アセットが移動している可能性があることを考慮してもよく、ゆえに、「ライブ」データが、(アセットが異なる位置にあったことに起因する可能性がある)「過去」データよりも信頼性が高いと考えられることができる。また、アセットのムーブメントに関する追加データを考慮してもよい。例:部屋にモーションセンサ(PIR又はRFベースのセンシング)もあり、動きが検出されない場合、アセットも移動しない可能性が高い(典型的には、アセットは、移動する場合に動きセンサによって検出される人間によって移動される)。一方、エリアの一部で動きが検出される場合、当該エリアにあるアセットは、エリア内で又はエリア外に移動する可能性がある。この場合、RFベースのセンシングが動きを検出すると、RFベースのセンシング及びアセットトラッキングのジョイントシステムは、優勢的にモーションセンシングを行うことから、優勢的にアセットトラッキングを行うことへ焦点を変更してもよい。これは望ましいことである。なぜなら、ライトがBLEを介してアセットタグをリスニングすればするほど、Zigbee無線機でRFベースのセンシングを行うのに費やすことができる時間が少なくなるからである。
変形例(Variant)1:有向アセット探索(Directed asset search)
好ましくは、コントローラ、例えば、図1のブリッジ1は、以下を考慮しながら、(1)トラッキングノード及び非トラッキングノードとして動作する照明器具の比率、(2)それぞれの位置及び(3)BLE対Zigbeeのデューティーサイクル(及びオプションとして「新しい」又は「価値の高い」アセット対その他のアセットのレポーティングストラテジ)を動的且つ適応的に割り当てる。
・ 照明制御システムのコンテキスト(例えば、この期間にどれだけの照明コマンドが予想されるか、照明レイテンシ要件は何か、等)
・ データ収集システムのコンテキスト(例えば、中央デバイスが多くのデバイスからデータを収集する期間があり得る、等)
・ アセットトラッキングシステムのコンテキスト、例えば、
- 新たなアセットが入室した場合、ビーコン受信機の照明器具の数が、迅速に正確なロケーションフィックス(location fix)を取得するために一時的に増やされ得る。
- 動いている人がトラッキングされている場合、ジョイントシステムのアセットトラッキング機能のビーコン受信強度が上げられる。
- 履歴データに基づいて予想されるアセットのムーブメント軌跡(movement trajectory)。
アセットが移動している又は移動している可能性があるというインディケーションがある場合、システムは、トリラテレーション精度及び/又は速度を向上させるために、潜在的に移動しているアセットの近くでBRMノードがアクティブであることを確実にするようにBRM/NCM機能の配分を動的に最適化する。
第1の例として、空間の一部(特にドア付近)で動きが検出される場合、アセットはそこで空間に入る又は出る可能性があり、ゆえに、強化されたアセットトラッキング性能が、空間のこの部分で望まれる。これは、追加のBRMノードを割り当てる(ある期間BRM/NCMの比率を調整する)、又は、(BRM/NCMの比率をおおよそ(more or less)一定に保ちながら)BRMノードの当該エリアへの「シフト」により実現されてもよい。
第2の例として、特定の価値の高いアセットが検出される場合、当該エリアのより多くのBRMノードが、より速い及び/又はより精度の高いフィックスを得るために一時的にアクティブにされる。第3の例として、割り当ては、特定のアセット又はアセットのタイプに関する履歴データに基づいてもよい(清掃トロリーは、典型的には、緊急用のクラッシュカートとは別の位置にあり、典型的には、異なる速度及びパターンで移動する可能性がある)。
変形例2:NCM及びBRM間のトランジショナルモデル(Transitional mode)
任意の所与の瞬間にZigbeeネットワークの安定性を確保するために、モード間のZigbeeルータ/エンドデバイス機能性のハードスワップ(hard swapping)は避けられるべきである。
したがって、この変形例は、ライトが、追加のモード、トランジショナルモード(TM)を介してビーコン受信モード(Beacon Receiver Mode)及びネットワークキャノピーモード(Network Canopy Mode)間で徐々に移行するメカニズムを提案する。トランジショナルモードTMのデバイスは、ネットワークキャノピー(ネットワークカバレッジ)のニーズを考慮しながら、プライマリZigbee(Primary-Zigbee)(NCM)機能性及びプライマリBLEアセットトラッキングモード(primary-BLE-asset-tracking mode)(BRM)の間を移行するプロセスにある。モードTMのデバイスは、例えば、ビーコン受信機として動作しながらも、ネットワークキャノピーの機能を維持するためにZigbeeルータ又は機能性を低下させたZigbeeルータとして動作してもよい(例えば、50%、ビーコン受信機、及び、50%、Zigbeeルーティングノード)。
したがって、この変形例では、デバイスは3つの可能なモードを持つ。例えば、
・ 100%の時間、Zigbeeルータ(NCM)
・ 99%の時間、BLE受信機、及び、1%の時間、Zigbeeエンドデバイス(BRM)
・ 50%、Zigbeeルータ、及び、50%、BLE受信機のパートタイム(TM)
TM「デバイス」について、以下のようにすることが有利であり得る。
- このようなノードを介してトラフィックをルーティングしない(他のルータデバイスは、一部の時間しかこれらと通信することができないため)1つのメカニズムは、Link Status(リンクステータス)において及び/又はRoute Request(ルートリクエスト)転送する場合に、Link Cost(リンクコスト)フィールドを(高いコストを意味する)高い値に設定することにより、他のノードがTMノードを経由してトラフィックをルーティングすることを阻止することである。別のメカニズムは、Route Requestの転送を遅らせる、又は、Route Requestをまったく転送しないことであり、これは、ルートがTMノードを経由して構築されるのを防止する。
- エンドデバイスが通信したい場合に親(TMデバイス)がZigbeeで利用可能ではない可能性があるため、Zigbeeエンドデバイスの親にならないようにする。
変形例3:BRMノードがメッセージを受信するが、メッセージを再ブロードキャストしない
BRMノードをZigbeeエンドデバイスとして定義する代替例として、BRMデバイスは、他のノードから受信するメッセージを再ブロードキャストしないようにコミッショニングされてもよい。したがって、これらのBRMノードは、ルーティング機能性を持たないルータとしてZigbeeネットワーク上で動作してもよい。すなわち、BRMノードは、自身のトラフィックのためだけにZigbeeルーティングデバイスのように動作するが、他のデバイスに由来するメッセージをルーティングしない(すなわち、BRMデバイスは、他のノードのルートディスカバリメッセージに応答しない)。このアプローチは、BRMノードをZigbeeエンドデバイスにして、ブロードキャストを直接受信せず、親ノードによるメッセージのバッファリングを必要とする場合よりも有利であり得る。ルーティング機能性を持たないルータノードは、バッファリングを必要としない。Zigbeeエンドデバイスは、メッセージのために定期的に自身の親ノードをポーリングすることが必要とされることにより、追加のネットワークトラフィック、及びこのようなデバイスにメッセージを送信する際のレイテンシを引き起こすことに留意されたい。「再ブロードキャストしない(not rebroadcasting)」とは、例えば、(「オン」等の)より重要な照明制御メッセージは再ブロードキャストする、及び、それほど重要でないメッセージは再ブロードキャストしないことにより、選択的であってもよい。
変形例4:追加の照明器具のグループがメッセージを受信するが、メッセージを再ブロードキャストしない
通常のZigbeeルータ(NCM)としてコンフィギュレーションされるノードのグループ及びZigbeeエンドデバイス(BRM)としてコンフィギュレーションされるノードのグループに加えて、ルーティング機能性を持たないZigbeeルータとしてコンフィギュレーションされる追加のノードのグループがあってもよい。図8に関連して説明されたように、BRMノードへの干渉を防ぐために、BRMノードの付近にあるノードがこのグループに入れられてもよい(図8において、このグループは「第2のサブセット」と呼ばれた)。
ノードの動作モードは、方法の第2の実施形態(図9参照)及び方法の第3の実施形態に関連して述べたように、ノードが使用されているときに変更されることが好ましい。照明器具L1が動作モードを変更する例が、図14の列201に示されている。この例では、照明器具L1は、期間281及び282において(ルーティング)機能性が低下したZigbeeルータ(図9の動作モード2)として動作し、期間283及び284においてZigbeeエンドデバイス(図9の動作モード3)として動作し、期間285において通常のZigbeeルータ(図9の動作モード1)として動作する。
期間の部分291において、照明器具L1は、RFベースのアセットトラッキング(又は代替的な実施形態ではRFベースのセンシング)を行う。部分292~294において、照明器具L1は、ネットワークメッセージを取得する。部分292及び294において、照明器具L1は、通常のZigbeeルータノードからネットワークメッセージを受信する。部分293において、照明器具L1は、自身の親ノードからネットワークメッセージを取得する。部分294において、照明器具L1はさらに、自身が受信した及び他のノードを意図したネットワークメッセージを転送する。また、照明器具L1は、部分292~294において他のZigbeeデバイスに自身のネットワークメッセージ(すなわち、他のZigbeeデバイスから受信していないネットワークメッセージ)を送信してもよい。
変形例5:Threadメッシュネットワークのためのデュアル無線照明制御/アセットトラッキング
この変形例では、Zigbeeプロトコルの代わりにThreadプロトコルが照明制御メッセージに使用される。Thread規格は、ネットワークごとに最大32個のルータ、残りのデバイスは非ルータノード(エンドデバイス)であることを認めている。Threadは、例えば、ネットワーク内のルータの総数、ネイバーの数、ネイバーとのリンク品質、隣接するルータのルータテーブル等の基準に基づくルータノード選択プロトコルを述べている。Threadにおいて、エンドデバイスのうちの1つが、自身のルータノードへの接続を失う場合、エンドデバイス自身が、別のルータの探索を開始する。また、Thread規格は、エンドデバイスがルータノードになるように遷移する及びその逆のためのメカニズムを述べていて、例えば、エンドデバイスが、自身がルータになった方が良いと考える場合、ルータになることを要求(request)する。Threadルータノードは、ルータノードとしての動作を停止する(エンドデバイスの役割に変更する)場合、それぞれの子デバイスに、親として代替的なルータノードに切り替える必要があることを通知する。
Threadネットワーキング規格は、上述のZigbeeベースの例と比較して、本発明の文脈に関連するいくつかの機能性を持っている。Threadでは、2つのデバイスタイプ及び6つのデバイスの役割があり、デバイスタイプは固定されるが、デバイスの役割は経時的に変わることができる。2つのデバイスのタイプは、以下の通りである。(a)(Leader、Router、REED、FEDのいずれかの役割を持つことができる)フルThreadデバイス(full Thread device)、及び、(b)(MED及びSEDの役割を持つことができる)ミニマルThreadデバイス(minimal Thread device)。
デバイスが持つことのできる6つの役割は、以下の通りである(これらの最初の3つはRouter(ルータ)(R)、最後の3つはEnd Device(エンドデバイス)(ED))。
・ Leader(リーダ)(選出されたルータ(elected router)、ブックキーピング(bookkeeping)、ルータのリスト)
・ Router(ルータ)
・ REED(Router Eligible End Device(ルータエリジブルエンドデバイス):ルータになる可能性はあるが、現在は非アクティブ、すなわち、EDとして動作している。REED=FED+、ルータになる必要があるかどうかをチェックするアルゴリズムを実行)
・ FED(Full End Device(フルエンドデバイス)):FED=MED+、1つの親を持ち、マルチキャストを受信するために複数のデバイスにリンクする)
・ MED(Minimal End Device(ミニマルエンドデバイス):1つの親を持ち、無線は常にオン、親はMEDが起きていることを予想し、メッセージは親を介して送信され、MEDは親のメッセージが成功裏に到着しない場合に対処するメカニズムを持っていない)
- したがって、現在のThread規格に述べられているMEDデバイスは、MEDがコンスタントにThreadメッセージをリッスンする必要があり、BLEメッセージをリッスンする時間がないため、デュアル無線(Thread+BLE)照明器具として直接機能するのには適していない。
・ SED (Sleepy End Device(スリーピーエンドデバイス):MEDのようであるが、Threadに関する限りスリーピーである)
- このSEDは、(Threadに関する限り)スリープすることができる唯一のものであるが、本発明において、デバイスは、Threadでリッスンしていない時間を使って別のチャネル(BLE)をリッスンしてもよい。他は、常にThreadデバイスとしてリッスンしている。
ゆえに、デュアル無線照明器具の場合、BRMデバイスはSEDの役割を使用し、NCMデバイスは「ルータ」の役割(リーダー、ルータ、REED)のいずれかを使用することになる。Threadの仕様では役割の変更が認められているので、SEDから他の(ルータ)モードのうちの1つに及びその逆に変更することは、Zigbeeのような問題ではないはずである(上記のZigbeeの説明及び問題点の回避策を参照)。
考慮すべき1つの態様は、Threadネットワーク内の特定のタイプのノードの数を自動的にバランスさせることである:
- 大規模なネットワークでは、Threadはデフォルトで約23個のデバイスをRとして、残りをEDとして割り当てる。
- Threadでは、システム内に約24個以上のルータがある場合、RがEDになることを志願(volunteer)する。
- システム内に約22個以下のルータがある場合、EDがRになることを要求(request)する。
これは、分散アルゴリズムを使用した、デバイス間のローカルなインタラクションに基づく自動割り当てである。このような自動割り当ては、照明とアセットトラッキングとを組み合わせたネットワークにとって望ましい結果にはならないであろう。なぜなら、Threadの自動割り当てでは、場合によっては、すべてのThreadルータが部屋の左側に、すべてのEDが右側に位置することがあり、これは、アセットトラッキングのためのトリラテレーションの妨げとなるからである。さらに、Threadでは、(トリラテレーションを向上させるために必要とされる)位置に対して役割を動的に変更するためのトリガがない。
上述したように、アセットトラッキングアプリケーションに適したデバイスの分布を得るようにルータの割り当てをオーケストレーション(orchestrate)することが望ましい。Threadルータの自動割り当てを防ぐために、Thread規格は、セントラルポイント(central point)が、役割を変更するように(帯域外チャネルを介して)デバイスに指示することができ、デバイスは、自身の変更された役割について自身のネイバーに通知することをすでに認めている。したがって、Threadプロトコルは、このための上手い仕組み(nice hook)及び標準メッセージをすでに提供し、一方、上述したように、Zigbeeは斯かるメッセージを欠いている。
以下のシーケンスは、NCMのためにThread Router(R)及びBRMのためにSleepy End Device(SED)の役割を使用して、ThreadシステムにおけるNCM及びBRM間の役割変更(role-changing)を実装するやり方を述べている。
BRM=>NCM(SED=>R):SEDは、先ず通常のEDとして帰属し、その後ルータにアップグレードし、他のEDをSEDにダウングレードする(NCM=>BRM)。自律的な変更のために、Thread規格は、安定(stabilization)のための遅延(0~120s)を持つ。これは、アプリケーションにとって長すぎる可能性がある。このような変更が、オーケストレーションされるようになされた場合、これは、数秒以内に実行され得るであろう。変更メッセージはネットワークトラフィックのピークにつながる可能性があることに留意されたい。したがって、Threadは、状況が安定している場合徐々に増加するトリクルタイムメカニズム(trickle time mechanism)を適用する。役割変更のセントラルオーケストレーション(central orchestration)を適用することが好ましく、これは、変更メッセージトラフィックピークを避けるためにネットワークレベルにおいて緩やかな役割変更を可能にする。
(例えば、住宅用アプリケーションにおいて)限られた数のノードを持つまばらな(sparse)Threadネットワークでは、すべてのThreadデバイスは数分後にルータになる。好ましくは、このようなまばらなThreadネットワークにおいても、一部のデバイスは、アセットタグによって送信されるBLEビーコン信号をリッスンするのに十分な時間を持つように、意図的にスリーピーエンドデバイスSEDとしてコンフィギュレーションされる。これは、Threadスタックが現在のThread規格に準拠する場合、これらのデバイスのThreadスタックの修正(modification)を必要とする可能性がある。
変形例6:よりまばらな(sparse)ネットワーク、例えば、Philips Hueネットワーク
オフィス又は病院等の業務用照明アプリケーションで使用されるネットワークは、典型的には、多くのノードを有し、ゆえに、異なる機能性を持つグループへのノードの分割は、Zigbeeネットワークの性能及び「健全性」に効果的な影響を与えることなく実現され得る可能性が高い。
家庭用照明アプリケーション等、まばらなネットワークでは、役割が、Zigbeeネットワークが完全に機能を維持すること、及び、ビーコン受信(アセットトラッキング)機能性が許容可能なトラッキング性能を持って機能を維持することの両方を確実にするように慎重に割り当て及び変更される必要があるため、これらのメカニズムを適用することはより困難になる可能性がある。一方、このような家庭環境では、G1及びG2間でモードスワップを繰り返しスワップすることが、Zigbeeネットワーク性能を十分に確保しつつ、位置精度を高めることができる可能性がある。
典型的なホームネットワークは、典型的な業務用照明アプリケーションネットワークよりもノード数が少ないため、Zigbeeネットワーク負荷は低く、タグ付けされたアセットの数も少ないと予想される。それゆえ、大部分のノードがNCMとしてコンフィギュレーションされて機能するZigbeeメッシュを維持しつつ、BRMのためにデバイスの総数のうちの数デバイスを使用してもよい。役割をローテーションすることは、アセットロケーションのより正確なカバレッジを得ることを可能にする。
さらに、ホームネットワークでは、一部のライトが、主電源電圧壁スイッチによって一時的に給電停止されることがあり、したがって一時的にアセットトラッキングシステムに貢献することができない。それゆえ、ライトの給電が停止すると、システムは、当該ライトが再びパワーアップされるまでG1及びG2間のノードの分布を再構成する。
十分なノードが、家の特定のエリアでアセットトラッキング及びRFベースのセンシングの両方を実行するのに利用可能ではない場合、システムは、コンテキストに依存して2つの機能性のうちの一方をディスエーブルにする。例えば、家の所有者が外出している場合、RFベースのモーション/占有者検出が、あり得る侵入者について家を監視するために実行される。所有者が家にいる場合、システムは、RFベースのセンシングを用いた自動照明制御をディスエーブルにし(ユーザは代わりにバッテリ式の壁スイッチを使用する必要がある)、一方、システムは、家中でBLEを備えた家電機器の位置をトラッキングする。
変形例7:WiFi+BLE複合無線
将来、ライトは、例えば802.11s規格を用いる、WiFi照明制御ネットワークで制御される見込みがある。すでにWiFiチップは、一般にBLE無線も備えている。したがって、これは、BLE無線がビーコンを受信するために使用され、WiFiがネットワークキャノピーを提供する、時分割(time-shared)BLE+WiFiコンボ無線をライトにおいて可能にする。
WiFi 802.11s規格は、ルータノードとエンドデバイスとを区別する。WiFiソリューションでは、照明器具は、(ゲートウェイを持たないスタンドアロンネットワークでWiFiを介してユーザのスマートフォンとインターフェースする)Mesh(メッシュ) AP又はMesh(メッシュ)ノード(照明器具にAPがない。スマートフォンは、中央ゲートウェイとトークする)として動作することができる。
一実施形態では、一部のWiFiライトは、ビーコン受信機として半並行的(semi-concurrently)に動作する。この実施形態では、WiFiライトは、Wifi Mesh APノードとして、又はWiFi Mesh Nodeとして、又はWiFi Mesh AP+Beacon Receiverノードとして、又はWiFi Mesh Node+Beacon Receiverノードとして動作するように割り当てられる。
拡張例(Extension)1:現在の照明レイテンシ要件を考慮する
・ ライトが、電気照明が必要とされる時間帯又は日光のない空間でオフされている場合、典型的には人は存在せず、ゆえに、アセットはこの空間/部屋内で移動し得ない。したがって、(両方とも、ライトがオンすることが必要な場合に素早く反応することを目的に)この空間内のNCMノードの数を増やす及び/又は親へのBRMノードのポーリングレートを上げることが可能である。さらに、システム全体のネットワークキャノピーが、占有されていないサブ空間からのより多くのNCMモードを持つことにより強化される。
- 各空間内に(直接反応する)NCMノードと(親のポーリングが必要であることに起因していくらかのレイテンシを伴って反応する)BRMノードとが混在するという事実は、エンドユーザによって知覚されるレイテンシには限定的な影響しかない。なぜなら、多くのライト(NCMノード)は直ちにオンし、一部のノード(BRMノード)の応答が遅いという事実を視覚的に隠し得るからである。(すべてのノード、特にNCMノードに)遷移時間を採用することも、この事実を隠す助けになる。オプションとして、遅れて始まるにもかかわらず、BRMノードのライトフェージング処理の終点がNCMデバイスの終点と一致するようにBRMノードの調光遷移時間をスマートに短くすることも可能であり得る。
・ ライトがオンされている場合、典型的には人が空間に存在し、ゆえに、アセットは移動し得る。したがって、この空間でライトがオンされている場合にはアセットを正確にトラッキングできるようにBRMノードの数を増やすことが有益である。照明制御のレイテンシは、ライトがオンされている場合あまり気にならない。典型的には、最後の人が部屋を出てからしばらくしてライトはオフにされる必要があるので、一部のノードに対するスイッチオフコマンドのレイテンシの影響は気付かれない可能性が高い。
拡張例2:ポーリングの巧みな(clever)瞬間
Zigbeeエンドデバイスは、(めったにではないが)BLEビーコンの短い期間を逃してしまうように自身の親とたまにトークする必要がある。BLEビーコンは規則的なパターンで送信されるので、そのエリアの既知のアセットからのBLEビーコンが予想されない瞬間にZigbeeの親をポーリングすることが有利であり得る。
図15は、図2~6及び8~9を参照して述べられたような方法を実行し得る、例示的なデータ処理システムを示すブロック図を示す。
図15に示されるように、データ処理システム300は、システムバス306を介してメモリ要素304に結合される、少なくとも1つのプロセッサ302を含んでもよい。それゆえ、データ処理システムは、メモリ要素304内にプログラムコードを記憶してもよい。さらに、プロセッサ302は、システムバス306を介してメモリ要素304からアクセスされるプログラムコードを実行してもよい。一態様では、データ処理システムは、プログラムコードを記憶及び/又は実行するために好適な、コンピュータとして実装されてもよい。しかしながら、データ処理システム300は、本明細書内で述べられる機能を実行することが可能な、プロセッサ及びメモリを含む任意のシステムの形態で実装されてもよい点を理解されたい。
メモリ要素304は、例えば、ローカルメモリ308及び1つ以上の大容量記憶デバイス310等の、1つ以上の物理メモリデバイスを含んでもよい。ローカルメモリとは、プログラムコードの実際の実行中に一般に使用される、ランダムアクセスメモリ又は他の非永続的メモリデバイスを指してもよい。大容量記憶デバイスは、ハードドライブ又は他の永続的データ記憶デバイスとして実装されてもよい。処理システム300はまた、実行中に大容量記憶デバイス310からプログラムコードが取得されなければならない回数を低減するために、少なくとも一部のプログラムコードの一時記憶を提供する、1つ以上のキャッシュメモリ(図示せず)を含んでもよい。また、処理システム300は、例えば、処理システム300がクラウドコンピューティングプラットフォームの一部である場合、別の処理システムのメモリ要素を使用することができてもよい。
入力デバイス312及び出力デバイス314として示される、入出力(input/output:I/O)デバイスが、オプションとして、データ処理システムに結合されることができる。入力デバイスの例としては、限定するものではないが、キーボード、マウス等のポインティングデバイス、(例えば、ボイス及び/又はスピーチ認識のための)マイク等を挙げることができる。出力デバイスの例としては、限定するものではないが、モニタ又はディスプレイ、スピーカ等を挙げることができる。入力デバイス及び/又は出力デバイスは、直接、又は介在I/Oコントローラを介して、データ処理システムに結合されてもよい。
一実施形態では、入力デバイス及び出力デバイスは、(入力デバイス312及び出力デバイス314を取り囲む破線で図15に示されるような)複合型入力/出力デバイスとして実装されてもよい。そのような複合型デバイスの一例は、「タッチスクリーンディスプレイ」又は単に「タッチスクリーン」と称される場合もある、タッチ感知ディスプレイである。そのような実施形態では、デバイスへの入力は、タッチスクリーンディスプレイ上、又はタッチスクリーンディスプレイの近くでの、例えばスタイラス又はユーザの指等の、物理的実体の移動によって提供されてもよい。
ネットワークアダプタ316もまた、データ処理システムに結合されて、介在する私設ネットワーク又は公衆ネットワークを介して、データ処理システムが、他のシステム、コンピュータシステム、リモートネットワークデバイス、及び/又はリモート記憶デバイスに結合されることを可能にしてもよい。ネットワークアダプタは、上述のシステム、デバイス、及び/又はネットワークによってデータ処理システム300に送信されるデータを受信するための、データ受信機と、データ処理システム300から上述のシステム、デバイス、及び/又はネットワークにデータを送信するための、データ送信機とを含んでもよい。モデム、ケーブルモデム、及びEthernetカードは、データ処理システム300と共に使用されてもよい、種々のタイプのネットワークアダプタの例である。
図15に示されるように、メモリ要素304は、アプリケーション318を記憶してもよい。様々な実施形態では、アプリケーション318は、ローカルメモリ308、1つ以上の大容量記憶デバイス310内に記憶されてもよく、あるいは、ローカルメモリ及び大容量記憶デバイスとは別個であってもよい。データ処理システム300はさらに、アプリケーション318の実行を促すことが可能な(図15には示されない)オペレーティングシステムを実行してもよい点を理解されたい。アプリケーション318は、実行可能プログラムコードの形態で実装されており、データ処理システム300によって、例えばプロセッサ302によって、実行されることができる。アプリケーションの実行に応答して、データ処理システム300は、本明細書で述べられる1つ以上の動作又は方法ステップを実行するように構成されてもよい。
本発明の様々な実施形態は、コンピュータシステムと共に使用するためのプログラムプロダクトとして実装されてもよく、このプログラムプロダクトのプログラムは、(本明細書で説明される方法を含めた)実施形態の機能を定義する。一実施形態では、このプログラムは、様々な非一時的コンピュータ可読記憶媒体上に含まれることができ、本明細書で使用されるとき、「非一時的コンピュータ可読記憶媒体」という表現は、全てのコンピュータ可読媒体を含むが、唯一の例外は一時的な伝搬信号である。別の実施形態では、このプログラムは、様々な一時的コンピュータ可読記憶媒体上に含まれることができる。例示的なコンピュータ可読記憶媒体としては、限定するものではないが、(i)情報が永続的に記憶される、書き込み不可記憶媒体(例えば、CD-ROMドライブによって読み取り可能なCD-ROMディスク、ROMチップ、又は任意のタイプの不揮発性固体半導体メモリ等の、コンピュータ内部の読み出し専用メモリデバイス)、及び(ii)変更可能な情報が記憶される、書き込み可能記憶媒体(例えば、フラッシュメモリ、ディスケットドライブ若しくはハードディスクドライブ内部のフロッピーディスク、又は任意のタイプのランダムアクセス固体半導体メモリ)が挙げられる。コンピュータプログラムは、本明細書で述べられるプロセッサ302上で実行されてもよい。
本明細書で使用される用語法は、特定の実施形態を説明することのみを目的とするものであり、本発明を限定することを意図するものではない。本明細書で使用されるとき、単数形「a」、「an」、及び「the」は、文脈がそうではないことを明確に示さない限り、複数形も含むことが意図される。本明細書で使用されるとき、用語「含む(comprises)」及び/又は「含んでいる(comprising)」は、記述された特徴、整数、ステップ、動作、要素、及び/又は構成要素の存在を指定するものであるが、1つ以上の他の特徴、整数、ステップ、動作、要素、構成要素、及び/又はそれらの群の存在若しくは追加を排除するものではない点が、更に理解されるであろう。