JP7163507B2 - Ｒｆベースの存在及び／又は位置検出機能を備えるノードを避けるネットワークルートの決定 - Google Patents

Description

本発明は、ＲＦベースの存在検出及び／又は位置特定(localization)のためのシステム、方法及びコンピュータプログラムに関する。

とりわけ、本発明は、複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御するためのシステム、複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御する方法、及び、コンピュータシステムがそのような方法を実行することを可能にするコンピュータプログラムプロダクトに関する。

ＲＦベースの存在検出は、ＰＩＲベースの存在検出を置き換える又はそれを強化する可能性のある有望な技術である。ＲＦベースの位置特定は、デバイスが、屋内に位置することを可能にする。ＲＦベースの存在検出は、例えば、ＵＳ ２０１７／０３５９８０４ Ａ１に開示されている。

ＵＳ ２０１７／０３５９８０４ Ａ１は、ワイヤレスネットワーク内の第１のワイヤレス通信チャネルのサブセットでワイヤレスネットワークトラフィックを通信する第１のワイヤレスネットワークデバイスを開示している。第１のワイヤレスネットワークデバイスは、第２のワイヤレスネットワークデバイスによって空間を介して送信されるＲＦベースのセンシング信号を受信する。ＲＦベースのセンシング信号は、第２のワイヤレス通信チャネルのサブセットで受信される。ＲＦベースのセンシング信号は、空間内の物体の動きを検出するために処理される。

典型的には、ＲＦベースの存在検出及び／又は位置特定を実行できるすべてのデバイスが、このＲＦベースの存在検出及び／又は位置特定を実行するのを支援するように構成される。しかしながら、このタスクを実行することは、ワイヤレスネットワークトラフィックを通信するデバイスの容量を減らし、ＲＦベースの存在検出及び／又は位置特定を実行するためにすべての能力のあるデバイスを構成することは、リソースの最適な使用ではない。

ＵＳ２００９０１２９２７３Ａ１は、互いに階層的に管理されることができる複数のワイヤレスルータを含むワイヤレスメッシュ通信ネットワークであって、すべてのルータが、互いに通信するチャネル上の干渉を検出し、回避することができる、ワイヤレスメッシュ通信ネットワークを開示している。チャネルがアクティブであるか、アクティブでないかに依存して、ワイヤレスルータは干渉を受動的に検出して、それを避けるためにチャネルを切り替えるか、干渉を能動的に検出して、それを避けるためにチャネルを切り替えることができる。

本発明の第１の目的は、ネットワークノードのサブセットがＲＦベースの存在検出及び／又は位置特定を行うことを考慮しながらワイヤレスメッシュネットワークを構成することができる、システムを提供することである。

本発明の第２の目的は、ネットワークノードのサブセットがＲＦベースの存在検出及び／又は位置特定を行うことを考慮しながらワイヤレスメッシュネットワークを構成することができる、方法を提供することである。

本発明の第１の態様では、複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御するためのシステムは、前記複数のノードの第１のサブセットを決定し、前記第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む、ソースノードからデスティネーションノードへの複数のルートを決定し、前記複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む、及び、前記複数のルートの各々の前記中間ノードのうちのいくつが前記複数のノードの前記第１のサブセットの一部であるかに基づいて前記複数のルートのうちの１つを選択するように構成される少なくとも１つのプロセッサと、前記ワイヤレスネットワークに前記選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信するように構成される前記ワイヤレスネットワークへのインターフェースとを含む。このシステムは、「コントローラ」又は「オーケストレータ(orchestrator)」とも呼ばれる。

ノードが、（ネットワーク）メッセージを送信する、並びに、存在及び／又は位置検出機能を実行する場合、無線周波数ベースの存在及び／又は位置検出機能と（ネットワーク）メッセージの送信は、互いに干渉する可能性がある。この干渉の理由は、例えば、１）ワイヤレス（例えば、メッシュ）ネットワークにおいてメッセージを送信するためにノードによって発せられる無線周波数信号が、存在及び／又は位置検出の目的で発せられる無線周波数信号と干渉する、及び／又は、２）ノードは、ワイヤレス（例えば、メッシュ）ネットワークにおいてメッセージを送信する場合、（特に）存在及び／又は位置検出の目的でＲＦ信号を発することができない、等であり得る。斯くして、第１のタイプの干渉は、ワイヤレススペクトルにおけるＲＦ信号間であり、第２のタイプの干渉は、ＲＦ受信機及び／又は送信機のリソース間である。

ＲＦベースの存在及び／又は位置検出機能の割り当ては、ノード自身によって、又は、別のノード（例えば、存在を検出する隣接ノード又は中央コントローラノード）によって行われることができる。あるノードが存在及び／又は位置検出機能を割り当てられた場合、その周りの１つ以上のノードは、これらのノードが、このあるノードの存在及び／又は位置検出機能と干渉し得る無線周波数信号を発することを避けるために、メッセージルーティングを行わないように指示されてもよい。代替的又は追加的に、このあるノードの周りの１つ以上のノードは、より少ないメッセージルーティングを行うように指示されてもよい。

前記１つ以上のメッセージのうちの少なくとも１つのメッセージは、前記第１のサブセットのうちの少なくとも１つのノードに送信されてもよく、該少なくとも１つのメッセージは、該少なくとも１つのノードにメッセージルーティングを行わないように指示してもよい。１つ以上のメッセージは、例えば、ルーティング情報／指示が埋め込まれたデータメッセージ、又は、ワイヤレスネットワーク内のノードにルーティング情報を更新させるルーティング更新（すなわち、制御）メッセージであってもよい。第１のサブセット内の１つ以上のノードは、ワイヤレスメッシュネットワークにおいて（ルーティングノードではなく）自身のネットワークメッセージのみを送信するセンドノード(send-node)として動作するように設定されてもよい。代替的に、前記少なくとも１つのメッセージは、前記少なくとも１つのノードにより少ないメッセージルーティングを行うように指示してもよい。

存在検出は、例えば、人カウント(people counting)又は人トラッキング(people tracking)を行うために使用されてもよい。ユーザが存在すると検出される場合、該ユーザの体の姿勢又はムーブメント(movement)が決定されてもよい。ＲＦベースの存在検出という用語は、あらゆるＲＦベースのセンシングアプリケーションをカバーする。位置検出は、例えば、ジェスチャ検出を行うために使用されてもよい。ＲＦベースの位置検出という用語は、あらゆるＲＦベースのトラッキングアプリケーションをカバーする。ネットワークは、例えば、メッシュネットワーク又はスターネットワークであってもよい。例えば、スター構成では、ゲートウェイが、部屋のすべてのライトにシングルホップで接続してもよい。この場合、１つ以上のライトが、ＲＦベースのセンシングのために選択されてもよい。

本発明者らは、ワイヤレス（例えば、メッシュ）ネットワークにおけるデータメッセージのルーティングは、ＲＦベースのセンシング及び／若しくはＲＦベースのアセットトラッキングを改善するために、並びに／又は、メッセージのルーティング（及びそれによるネットワークカバレッジ）を改善するためにある状況においてより少なく又は可能な限り少なくＲＦベースのセンシング及び／又はＲＦベースのアセットトラッキングを行うデバイスを関与させるべきであることを認識した。これは、特にＲＦベースのセンシングメッセージを送信する役割を持つノード（ＲＦベースのセンシングペアのリスニングノードはそれほど問題ではない）について、ＲＦベースのセンシングを行うために、ルーティングされるネットワークメッセージ、例えば、それらのＲＳＳＩを使用することが可能ではない場合、又は追跡されるアセットがそれらのビーコン（ＲＦ信号）をいつ送信するかが事前に分からない場合に有益である。

ＲＦベースのセンシングを行うために、ルーティングされるネットワークメッセージ、例えば、それらのＲＳＳＩを使用することが可能である場合、メッセージをルーティングするためにより少なく又は可能な限り少なくＲＦベースのセンシングメッセージを受信する役割を持つノードを使用することが有益であり得る。送信されるネットワークメッセージ、例えば、照明制御メッセージは、ＲＦベースのセンシングに最適なペイロードを持たないかもしれないが、これらのメッセージから抽出されるＲＳＳＩは、依然としてアルゴリズムに役立ち得る。ＲＦベースのセンシングメッセージを受信する役割を持つノードは、ルーティングも行う必要がある場合、２つの問題を有する。これらは、ネットワークメッセージを送信する必要があるため、ＲＦベースのセンシングメッセージを受信するより少ない時間しか取ることができず、それらが送信するネットワークメッセージは、専用のＲＦベースのセンシングメッセージを送信しているノードによって送信されるペイロードよりも適切でないペイロードを持つ可能性がある。

ＲＦベースのセンシングメッセージのペイロードは、ＲＦベースのセンシングのために最適化されるだけでなく、測定されたＲＳＳＩ又は他のデバイスによって処理され得る他の関連情報を含んでもよい。代替的又は追加的に、これらの測定されたＲＳＳＩは、ネットワークメッセージを使用して送信されてもよい。ルーティングされるネットワークメッセージでＲＳＳＩ測定を行うことに加えて、ＲＳＳＩ測定はまた、他のネットワークメッセージ、ワンホップメッセージ、及びマルチホップメッセージで行われてもよい。

前記１つ以上のメッセージのうちの少なくとも１つのメッセージは、前記第１のサブセットのうちの少なくとも１つのノードに送信されてもよく、該少なくとも１つのメッセージは、該少なくとも１つのノードに前記無線周波数ベースの存在及び／又は位置検出機能のための１つ以上の無線周波数信号を送信及び／又は受信するように指示してもよい。これは、例えば、無線周波数ベースの存在及び／又は位置検出機能をノードに割り当てるのが（例えば、ノード自身ではなく）システムである場合に有益である。

前記第１のサブセットのうちの少なくとも１つのノードは、ある期間の間に間断なく(without interruption)前記１つ以上の無線周波数信号を送信するように指示されてもよく、前記第１のサブセットのうちの少なくとも１つの他のノードは、前記ある期間の間に間断なく前記１つ以上の無線周波数信号を受信するように指示されてもよい。これは、例えば、人カウントアプリケーション等、比較的高い帯域幅を必要とするＲＦベースのセンシングアプリケーションにとって有益である。これは、「高空間解像度(high-spatial-resolution)」センシングモードと呼ばれる。高空間解像度又は多占有者(many-occupants)のＲＦセンシングスキャンを実行している間、ライトのグループは、それらの帯域幅の１００％がＲＦベースのセンシングデータの獲得に専念される、特別な「センシングブーストモード(sensing-boost mode)」に入ってもよい。この少なくとも１つのノードが照明デバイスである場合、「高空間解像度モード」又は「センシングブーストモード」は、ある期間の間選択されてもよく、又は、ある期間自体が、ライトデバイスがこのある期間の間に光出力状態が変わらないことが予想されるという予想(expectation)に依存して選択されてもよい。

前記少なくとも１つのノード及び前記少なくとも１つの他のノードは、ライトデバイスであってもよく、前記少なくとも１つのノードは、前記ある期間の間に間断なく前記１つ以上の無線周波数信号を送信するように指示されてもよく、前記少なくとも１つの他のノードは、前記ライトデバイスが前記ある期間の間に光出力状態が変わらないことが予想されるという予想に依存して前記ある期間の間に間断なく前記１つ以上の無線周波数信号を受信するように指示されてもよい。光出力状態が変化しないことが予想される場合、光コマンドは予想されないので、ＲＦベースの存在及び／又は位置検出への時間割当に起因する光コマンドへの応答の遅れは予想されない。間断のない(uninterrupted)ＲＦベースのセンシングは、ネットワークメッセージの送信及び受信よりもＲＦベースのセンシングに（はるかに）高いプライオリティを割り当てることによって実現されてもよい。ネットワークメッセージのプライオリティは、ライトデバイスが「センシングブーストモード」にある間、ライトデバイスによってネットワークメッセージが送信されないように低く設定されてもよい。

前記少なくとも１つのプロセッサは、１つ以上のターゲットセンシングエリアの１つ以上の位置に基づいて前記第１のサブセットを決定するように構成されてもよい。これは、ＲＦベースのセンシングにとって、例えば、あるターゲットセンシングエリア、例えば、部屋の占有が判断される必要がある、又は、あるターゲットセンシングエリアにいる人の数がカウントされる必要がある場合に有益である。

前記少なくとも１つのプロセッサは、前記複数のノードの第２のサブセットを決定するように構成されてもよく、前記１つ以上のメッセージのうちの少なくとも１つのメッセージは、前記第２のサブセットのうちの少なくとも１つのノードに送信され、該少なくとも１つのメッセージは、該少なくとも１つのノードにメッセージルーティングを行わないように指示してもよい。第２のサブセットのノードは、ＲＦベースの存在及び／又は位置検出のための無線周波数信号を送信及び／又は受信しないだけでなく、ＲＦベースの存在及び／又は位置検出への干渉を防ぐためにネットワークメッセージをルーティングすることもしない。これは、例えば、ワイヤレスメッシュネットワークとＲＦベースの存在及び／又は位置検出とが同じ周波数チャネルで生じる場合に有益である。

第２のサブセットのノードは、ワイヤレスメッシュネットワーク、例えば、Ｚｉｇｂｅｅネットワークにおけるエンドノードであってもよいが、代替的に、ＲＦベースのセンシング及び／又はトラッキングメッセージに干渉しないためにメッシュネットワークにおけるルートの一部ではない（又は少なくとも多くのメッセージを送信していない）ルータであってもよい。前記少なくとも１つのプロセッサは、例えば、前記第１のサブセットのうちの１つ以上のノードの１つ以上の位置に基づいて前記複数のノードの前記第２のサブセットを決定するように構成されてもよい。

前記第１のサブセット及び前記第２のサブセットは、第１の時点で選択されてもよく、前記少なくとも１つのプロセッサは、第２の時点で前記第１のサブセット及び前記第２のサブセットの新たな選択を実行するように構成され、前記第１のサブセットは、前記第１の時点における１つ以上の第１のターゲットセンシングエリアの１つ以上の位置に基づいて、及び、前記第２の時点における１つ以上の第２のターゲットセンシングエリアの１つ以上の位置に基づいて選択されてもよい。ターゲットセンシングエリアをユーザに追従させる、又は、ターゲットセンシングエリアを時間帯に若しくは警戒レベル等の建物コンテキスト(building context)に依存させること（例えば、会社でのレイオフ時の混乱の恐れ又は特定のオフィスに機密性の高い文書が保管されている等、脆弱な状況である場合、特定のエリアにおけるＲＦベースのセンシングに優先度が与えられてもよい）は有益であり得る。この場合、それに応じてネットワークルーティングを適応させることが有益であり得る。

前記少なくとも１つのプロセッサは、ユーザアクティビティに依存して前記第１のサブセット及び前記第２のサブセットの前記新たな選択を実行するように構成されてもよい。例えば、起こる可能性の高い又は起こることが確実なユーザアクティビティに基づいて、ＲＦベースのセンシングのための新しいターゲットセンシングエリアを決定することが可能であってもよい。例えば、従業員が夜間にデータセンタに一人でいる（セキュリティ上の機密性が高い）場合、屋内ナビゲーションシステムを使用する従業員は、ＲＦベースのセンシングを行う照明器具の現在の選択によって最適にカバーされる特定の経路に沿って案内されてもよい。この場合、夜間にどのようなユーザアクティビティが起こるかは確実である。

前記第１のサブセットのうちの１つ以上のノードは、１つ以上の無線周波数信号を送信及び／又は受信するために第１のプロトコルを使用してもよく、前記インターフェースは、前記１つ以上のメッセージを送信するために第２のプロトコルを使用してもよい。これら２つのプロトコルの１つ以上は、例えば、Ｚｉｇｂｅｅ、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、ＬｏＲａ、Ｃｅｌｌｕｌａｒ又はＴｈｒｅａｄであってもよい。これは、ワイヤレスネットワークの要件を満たすために最適なプロトコルを選択するだけでなく、ＲＦベースの存在及び／又は位置検出の要件を満たすために最適なプロトコルを選択することを可能にする。

例えば、サイト及びエリア照明において、駐車場が５つの照明器具によって照らされる。照明器具の各々は、屋外照明器具コントローラ（ＯＬＣ：Outdoor Luminaire Controller）を備える。ＯＬＣは、セルラー無線及びＺｉｇｂｅｅ無線の両方を備えてもよい。高解像度のＲＦベースのセンシングを行わない通常の運用では、１つのセルラー無線だけがクラウドに接続され、他の４つのライトのすべてのＯＬＣは、アクティブなセルラー無線を備える第１のＯＬＣとＺｉｇｂｅｅを介して通信する。しかしながら、ＲＦベースのセンシングが行われる場合、５つのＯＬＣすべてのＺｉｇｂｅｅ無線は、自身のフルエアタイムを最適化されたＲＦベースのセンシングに専念し、一方、各ライトは、個々にセルラー無線を介してクラウドに接続する。第１及び第２のプロトコルは、同じ又は異なる周波数帯を使用してもよい。代替的に、同じプロトコルが、例えば、異なる周波数帯（例えば、２．４ＧＨｚ帯におけるＺｉｇｂｅｅチャンネル１１対チャンネル２０）を使用して、前記１つ以上の無線周波数信号を送信及び／又は受信する、並びに、前記１つ以上のメッセージを送信するために使用されてもよい。

本発明の第２の態様では、複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御する方法は、前記複数のノードの第１のサブセットを決定することであって、前記第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む、ことと、ソースノードからデスティネーションノードへの複数のルートを決定することであって、前記複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む、ことと、前記複数のルートの各々の前記中間ノードのうちのいくつが前記複数のノードの前記第１のサブセットの一部であるかに基づいて前記複数のルートのうちの１つを選択することと、前記ワイヤレスネットワークに前記選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信することとを含む。前記方法は、プログラマブルデバイスで実行されるソフトウェアによって実行されてもよい。このソフトウェアは、コンピュータプログラムプロダクトとして提供されてもよい。

さらに、本明細書で説明される方法を実践するためのコンピュータプログラム、並びに、そのコンピュータプログラムを記憶している非一時的コンピュータ可読記憶媒体が提供される。コンピュータプログラムは、例えば、既存のデバイスによってダウンロードされるか、又は、既存のデバイスにアップロードされてもよく、あるいは、これらのシステムの製造時に記憶されてもよい。

非一時的コンピュータ可読記憶媒体は、少なくともソフトウェアコード部分を記憶し、ソフトウェアコード部分は、コンピュータによって実行又は処理されると、複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御するための実行可能オペレーションを実行するように構成される。実行可能オペレーションは、前記複数のノードの第１のサブセットを決定することであって、前記第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む、ことと、ソースノードからデスティネーションノードへの複数のルートを決定することであって、前記複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む、ことと、前記複数のルートの各々の前記中間ノードのうちのいくつが前記複数のノードの前記第１のサブセットの一部であるかに基づいて前記複数のルートのうちの１つを選択することと、前記ワイヤレスネットワークに前記選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信することとを含む。

当業者には理解されるように、本発明の諸態様は、デバイス、方法、又はコンピュータプログラムプロダクトとして具現化されてもよい。したがって、本発明の諸態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、あるいは、ソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形態を取ってもよく、それらは全て、本明細書では「回路」、「モジュール」、又は「システム」と総称されてもよい。本開示で説明される機能は、コンピュータのプロセッサ／マイクロプロセッサによって実行される、アルゴリズムとして実装されてもよい。更には、本発明の諸態様は、１つ以上のコンピュータ可読媒体として具現化されている、コンピュータプログラムプロダクトの形態を取ってもよく、１つ以上のコンピュータ可読媒体は、その上に具現化されている、例えば記憶されている、コンピュータ可読プログラムコードを有する。

１つ以上のコンピュータ可読媒体の任意の組み合わせが、利用されてもよい。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体であってもよい。コンピュータ可読記憶媒体は、例えば、限定するものではないが、電子、磁気、光学、電磁気、赤外線、又は半導体の、システム、装置、若しくはデバイス、あるいは、上述の任意の好適な組み合わせであってもよい。より具体的なコンピュータ可読記憶媒体の例としては、限定するものではないが、１つ以上のワイヤを有する電気的接続、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（random access memory；ＲＡＭ）、読み出し専用メモリ（read-only memory；ＲＯＭ）、消去可能プログラマブル読み出し専用メモリ（erasable programmable read-only memory；ＥＰＲＯＭ又はフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスク読み出し専用メモリ（portable compact disc read-only memory；ＣＤ－ＲＯＭ）、光学記憶デバイス、磁気記憶デバイス、又は上述の任意の好適な組み合わせを挙げることができる。本発明の文脈では、コンピュータ可読記憶媒体は、命令実行システム、装置、若しくはデバイスによって、又はそれらに関連して使用するためのプログラムを含むか、又は記憶することが可能な、任意の有形媒体であってもよい。

コンピュータ可読信号媒体としては、例えばベースバンド内又は搬送波の一部として、その内部に具現化されているコンピュータ可読プログラムコードを有する、伝搬データ信号を挙げることができる。そのような伝搬信号は、限定するものではないが、電磁気、光学、又はこれらの任意の好適な組み合わせを含めた、様々な形態のうちのいずれを取ってもよい。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体ではなく、命令実行システム、装置、若しくはデバイスによって、又はそれらに関連して使用するためのプログラムを、通信、伝搬、又は伝送することが可能な、任意のコンピュータ可読媒体であってもよい。

コンピュータ可読媒体上に具現化されているプログラムコードは、限定するものではないが、無線、有線、光ファイバ、ケーブル、ＲＦ等、又は上述の任意の好適な組み合わせを含めた、任意の適切な媒体を使用して送信されてもよい。本発明の諸態様に関する動作を実施するためのコンピュータプログラムコードは、Ｊａｖａ（商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のオブジェクト指向プログラミング言語、「Ｃ」プログラミング言語又は同様のプログラミング言語等の従来の手続き型プログラミング言語、及び、Ｓｃａｌａ、Ｈａｓｋｅｌｌ等の関数型プログラミング言語を含めた、１つ以上のプログラミング言語の任意の組み合わせで書き込まれてもよい。このプログラムコードは、スタンドアロン型ソフトウェアパッケージとして、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で実行されてもよく、部分的にユーザのコンピュータ上かつ部分的にリモートコンピュータ上で、又は完全にリモートコンピュータ若しくはサーバ上で実行されてもよい。後者のシナリオでは、リモートコンピュータは、ローカルエリアネットワーク（local area network；ＬＡＮ）若しくは広域ネットワーク（wide area network；ＷＡＮ）を含めた任意のタイプのネットワークを通じて、ユーザのコンピュータに接続されてもよく、又は、この接続は、外部コンピュータに対して（例えば、インターネットサービスプロバイダを使用してインターネットを通じて）実施されてもよい。

本発明の実施形態による方法、装置（システム）、及びコンピュータプログラムプロダクトの、フローチャート図及び／又はブロック図を参照して、本発明の諸態様が以下で説明される。フローチャート図及び／又はブロック図の各ブロック、並びに、フローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータプログラム命令によって実装されることができる点が理解されるであろう。これらのコンピュータプログラム命令は、マシンを作り出すために、汎用コンピュータ、専用コンピュータ、又は他のプログラマブルデータ処理装置の、プロセッサ、特にマイクロプロセッサ又は中央処理ユニット（central processing unit；ＣＰＵ）に提供されてもよく、それにより、コンピュータ、他のプログラマブルデータ処理装置、又は他のデバイスのプロセッサを介して実行される命令が、フローチャート及び／又はブロック図のブロック内で指定されている機能／行為を実施するための手段を作り出す。

これらのコンピュータプログラム命令はまた、コンピュータ、他のプログラマブルデータ処理装置、又は他のデバイスに、特定の方式で機能するように指示することが可能な、コンピュータ可読媒体内に記憶されてもよく、それにより、コンピュータ可読媒体内に記憶されている命令が、フローチャート及び／又はブロック図のブロック内で指定されている機能／行為を実施する命令を含む、プロダクトを作り出す。

コンピュータプログラム命令はまた、コンピュータ実施プロセスを作り出すために、コンピュータ、他のプログラマブルデータ処理装置、又は他のデバイス上にロードされて、それらのコンピュータ、他のプログラマブルデータ処理装置、又は他のデバイス上で一連の動作ステップを実行させてもよく、それにより、コンピュータ又は他のプログラマブル装置上で実行される命令が、フローチャート及び／又はブロック図のブロック内で指定されている機能／行為を実施するためのプロセスを提供する。

図におけるフローチャート及びブロック図は、本発明の様々な実施形態によるデバイス、方法、及びコンピュータプログラムプロダクトの可能な実装の、アーキテクチャ、機能性、及び動作を示す。この点に関して、フローチャート又はブロック図内の各ブロックは、指定されている論理関数を実施するための１つ以上の実行可能命令を含む、コードのモジュール、セグメント、又は部分を表してもよい。また、一部の代替的実装形態では、ブロック内に記されている機能は、それらの図に記されている順序と異なる順序で行われてもよい点にも留意されたい。例えば、連続して示されている２つのブロックは、実際には、実質的に同時に実行されてもよく、又は、それらのブロックは、関与している機能性に応じて、逆の順序で実行される場合があってもよい。また、ブロック図及び／又はフローチャート図の各ブロック、並びに、それらブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定されている機能若しくは行為を実行する専用ハードウェアベースのシステム、又は、専用ハードウェアとコンピュータ命令との組み合わせによって実施されることができる点にも留意されたい。

本発明のこれらの態様及び他の態様は、以下の図面から明らかであり、例として、それらの図面を参照して更に解明されるであろう。
本発明のシステムの一実施形態及び本発明の電子デバイスの一実施形態のブロック図である。 本発明の第１の方法の第１の実施形態のフロー図である。 本発明の第２の方法の第１の実施形態のフロー図である。 本発明の第１の方法及び第２の方法の第２の実施形態のフロー図である。 本発明の第３の方法の第１の実施形態のフロー図である。 方法の第３の実施形態のフロー図である。 隣接する３つの部屋に設置される照明システムの一例を示す。 第２の方法の第３の実施形態のフロー図である。 第３の方法の第２の実施形態のフロー図である。 １０個の照明器具を含むライトネットワークの一例を示す。 ネットワークノードを機能グループに動的に割り当てる例を示す。 ネットワークノードを機能グループに動的に割り当てる例を示す。 ネットワークノードを機能グループに動的に割り当てる例を示す。 機能グループへのノードの時間的に変化する割り当ての一例を示す。 本発明の方法を実行するための例示的なデータ処理システムのブロック図である。

図面中の対応する要素は、同じ参照番号によって示される。

図１は、本発明のシステム及び電子デバイスの実施形態を示す。図１の実施形態では、ブリッジ１は、本発明のワイヤレスネットワーク内のメッセージルーティングを制御するためのシステム並びに本発明の存在及び／又は位置検出のための無線周波数信号を送信、受信及び／又は処理するためのワイヤレスネットワーク内の１つ以上のデバイスを選択するためのシステムの機能性を組み合わせている。代替的な実施形態では、ブリッジ１は、これら２つの機能性のうち１つのみを実装する。異なる実施形態では、システムは、異なるタイプのデバイスに実装される。各システムは、１つ以上のデバイスを含んでもよい。

図１の実施形態では、本発明の２つの電子デバイス、照明デバイス１１及び１２が示されている。図１には、他の３つの照明デバイス、照明デバイス１３、１４及び１５が示されている。照明デバイス１１は、Ｈｕｅ ｇｏ照明器具であり、照明デバイス１２は、ＬＥＤストリップを含み、照明デバイス１３は、シーリングランプであり、照明デバイス１４は、フロアスタンド型ランプであり、照明デバイス１５は、テーブルランプである。図１の実施形態では、照明デバイス１３～１５は、照明デバイス１１及び１２とは異なり、期間の第１の部分でＲＦベースのセンシング又はアセットトラッキングを行い、この期間の第２の部分でネットワークメッセージを取得するように構成されていない。代替的な実施形態では、照明デバイス１３～１５も、照明デバイス１１及び１２と同様に、期間の第１の部分でＲＦベースのセンシング又はアセットトラッキングを行い、この期間の第２の部分でネットワークメッセージを取得するように構成される。ブリッジ１及び照明デバイス１１～１５は、無線メッシュネットワークを形成し、ノードとも呼ばれる。

ブリッジ１は、プロセッサ５、トランシーバ３及びメモリ７を備える。プロセッサ５は、照明デバイス１１～１５の第１のサブセットを決定するように構成される。第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む。プロセッサ５はさらに、ソースノード(source node)からデスティネーションノード(destination node)への複数のルートを決定するように構成される。複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む。プロセッサ５はさらに、複数のルートの各々の中間ノードのうちのいくつが複数のノードの第１のサブセットの一部であるかに基づいて複数のルートのうちの１つを選択し、ワイヤレスメッシュネットワークに選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信するためトランシーバ３を使用するように構成される。

一部の無線規格、例えば、Ｚｉｇｂｅｅでは、さまざまなルーティングメカニズムが利用可能及び／又はアクティブであることができる。これらのうちの一部は、送信デバイスによって決定され（ソースルーティング：送信者がメッセージのために使用されるべきパスを指示する）、これらのうちの一部は、Ｚｉｇｂｅｅネットワーク内のノードが送信及び受信されるメッセージに基づいてルーティングテーブルを構築する分散態様(distributed fashion)で決定される（ＡＯＤＶルーティング）。前者の場合、プロセッサ５は、特定のルートを使用するように送信デバイスに（例えば、Ｍａｎｕｆａｃｔｕｒｅｒ Ｓｐｅｃｉｆｉｃメッセージを介して）指示することができる。後者の場合、プロセッサ５は、例えば、ルーティングコストを意図的に調整することによって、前段落で述べられるような好ましいルートが達成される（又は奨励される）ように、及び／又は不要な経路が回避される（又は阻止される）ように、この分散プロセスに影響を与えるように様々なＺｉｇｂｅｅノードに指示するためにＭａｎｕｆａｃｔｕｒｅｒ Ｓｐｅｃｉｆｉｃメッセージを送信することによって、ルーティングに影響を与えることができる。別のメカニズムは、ノードの役割（ＮＣＮ／ＢＲＭ）、及び場合によっては近隣デバイスの役割が、ノードが行うルーティング決定（及び／又はノードがアナウンスするルーティングコスト）に影響を与え、斯くして、近隣デバイスのルーティング決定にも影響を与えるために使用されることである。

プロセッサ５はさらに、存在及び／又は位置検出のための無線周波数信号を送信、受信及び／又は処理するための照明デバイス１１～１５の各々の適合性を決定する、複数のデバイスの各々について決定される適合性に基づいて複数のデバイスからデバイスのサブセットを選択する、及び、存在及び／又は位置検出のための無線周波数信号を送信、受信、及び／又は処理するためのデバイスとして動作するようにデバイスのサブセットのうちの少なくとも１つに指示するように構成される。受信ライトがＲＦベースのセンシングに利用されるＲＳＳＩを決定することができる、送信されたワイヤレスメッセージのペイロードは、送信デバイス自身がネットワーク内の他のデバイスから先に受信した他のメッセージのＲＳＳＩデータのレポーティングを含んでもよい。したがって、ＲＦベースのセンシングメッセージは、単なるダミーのペイロードだけではなく、意味のあるペイロードを有し得る。

照明デバイス１１及び１２は、プロセッサ２５、トランシーバ２３、メモリ２７、及び光源２９を備える。プロセッサ２５は、複数の期間の各々の第１の部分の間に無線周波数信号を送信及び／又は受信するために第１のプロトコルを使用するように構成される。無線周波数信号は、存在及び／又は位置検出のために使用される。プロセッサ２５はさらに、複数の期間の各々の第２の部分の間にワイヤレス送信されるネットワークメッセージを取得するために第２のプロトコルを使用するように構成される。第２の部分は、第１の部分とオーバーラップしない。第１の部分の持続時間は、複数の期間のうちの少なくとも２つの期間で異なり、及び／又は、第２の部分の持続時間は、複数の期間のうちの少なくとも２つの期間で異なる。

ＲＦベースの存在検出は、ＲＦベースのセンシングとも呼ばれる。ＲＦベースのセンシングは、専用の送信機又は受信機を担持せず、信号を送信又は受信しないターゲットが検出される必要がある場合に使用されてもよい。ＲＦベースの位置特定（又は位置検出）は、ＲＦベースのアセットトラッキングとも呼ばれる（アセットは、例えば、物体、動物、又は人であってもよい）。ＲＦベースのアセットトラッキングは、専用の送信機又は受信機を担持している又は組み込んでいるターゲット／アセットが検出及び／又は位置特定される必要がある場合に使用されてもよい。追跡されるアセットは、例えば、ＢＬＥビーコンを受信又は送信してもよい。ＲＦベースのセンシングは、例えば、ネットワークの異なるノード間のワイヤレスリンクにおける受信信号強度又はその他のネットワーク診断データ（例えば、メッセージが成功裏に配信されるまでのリトライの数）の変化等、ワイヤレス通信システムの診断データ及び通信パラメータの動的な変化を分析することによって動き又は存在を検出する可能性を提供する。

図１に示されるブリッジ１の実施形態では、ブリッジ１は１つのプロセッサ５を含む。代替的な実施形態では、ブリッジ１は複数のプロセッサを含む。ブリッジ１のプロセッサ５は、例えばＡＲＭベースの、汎用プロセッサ、又は特定用途向けプロセッサであってよい。ブリッジ１のプロセッサ５は、例えば、Ｕｎｉｘベースのオペレーティングシステムを実行してもよい。メモリ７は、１つ以上のメモリユニットを含んでもよい。メモリ７は、例えば、１つ以上のハードディスク及び／又はソリッドステートメモリを含んでもよい。メモリ７は、例えば、コネクテッドライトのテーブル(table of connected lights)を記憶するために使用されてもよい。

トランシーバ３は、ライトデバイスと通信するために１つ以上の通信技術、例えば、Ｚｉｇｂｅｅ、Ｔｈｒｅａｄ及び／若しくはＢｌｕｅｔｏｏｔｈ、並びに／又は、無線ＬＡＮ／インターネットアクセスポイント（図示せず）と通信するために１つ以上の有線若しくは無線通信技術、例えば、Ｅｔｈｅｒｎｅｔ若しくはＷｉ－Ｆｉを使用してもよい。代替的な実施形態では、単一のトランシーバの代わりに複数のトランシーバが使用される。図１に示される実施形態では、受信機及び送信機は、トランシーバ３に組み合わされている。代替的な実施形態では、１つ以上の別個の受信機構成要素及び１つ以上の別個の送信機構成要素が使用される。ブリッジ１は、電源コネクタ等のネットワークデバイスに典型的な他の構成要素を含んでもよい。本発明は、１つ以上のプロセッサで実行されるコンピュータプログラムを使用して実装されてもよい。

図１の実施形態におけるブリッジ１によって実行される機能の一部は、代替的な実施形態ではインターネットサーバによって実行される。これは、より洗練されたＲＦベースの存在検出アルゴリズム又はＲＦベースの人カウントに特に有益である。セキュリティクラスのユースケースでは、より長いレイテンシ（例えば、１０秒）が典型的には許容されるが、照明クラスのユースケース（例えば、ライトをオンにする）では、０．５秒以下のレイテンシが望ましく、インターネットサーバへの往復が潜在的に問題となる。

図１に示される照明デバイス１１及び１２の実施形態では、照明デバイス１１及び１２は、１つのプロセッサ２５を含む。代替的な実施形態では、照明デバイス１１及び１２は複数のプロセッサを含む。照明デバイス１１及び１２のプロセッサ２５は、汎用プロセッサ、又は特定用途向けプロセッサであってよい。光源２９は、例えば、１つ以上のＬＥＤダイオードを含んでもよい。メモリ２７は、１つ以上のメモリユニットを含んでもよい。メモリ２７は、例えば、ソリッドステートメモリを含んでもよい。

図１に示される実施形態では、受信機及び送信機は、トランシーバ２３に組み合わされている。代替的な実施形態では、１つ以上の別個の受信機構成要素及び１つ以上の別個の送信機構成要素が使用される。代替的な実施形態では、単一のトランシーバの代わりに複数のトランシーバが使用される。トランシーバ２３は、ブリッジ１と通信するために１つ以上の無線通信技術、例えば、Ｚｉｇｂｅｅ、Ｔｈｒｅａｄ及び／又はＢｌｕｅｔｏｏｔｈを使用してもよい。ブリッジ１１は、電源コネクタ等の照明デバイスに典型的な他の構成要素を含んでもよい。図１の実施形態では、本発明の２つの電子デバイスは、照明デバイスである。代替的な実施形態では、本発明の電子デバイスは、他のタイプのデバイス、例えば、照明システムに関連する非照明デバイス（存在／位置検出のために使用され得る無線センサ及びスイッチ等）、又は他の非照明デバイスである。

無線周波数信号を送信、受信及び／又は処理するための１つ以上のデバイスを選択する方法の第１の実施形態が図２に示されている。ステップ１０１は、存在及び／又は位置検出のための無線周波数信号を送信、受信及び／又は処理するための複数のデバイスの各々の適合性を決定することを含む。ステップ１０３は、複数のデバイスの各々について決定される適合性に基づいて複数のデバイスからデバイスのサブセットを選択することを含む。ステップ１０５は、存在及び／又は位置検出のための無線周波数信号を送信、受信、及び／又は処理するためのデバイスとして動作するようにデバイスのサブセットのうちの少なくとも１つに指示することを含む。ステップ１０５はさらに、ネットワークメッセージ、例えば、照明制御システムのメッセージ（例えば、消費電力のレポーティング）を送信するようにデバイスのサブセットのうちの少なくとも１つに指示することを含んでもよい。

ワイヤレス（例えば、メッシュ）ネットワーク内のメッセージルーティングを制御する方法の第１の実施形態が、図３に示される。ステップ１１１は、複数のノードの第１のサブセットを決定することを含む。第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む。ステップ１１３は、ソースノードからデスティネーションノードへの複数のルートを決定することを含む。複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む。ステップ１１５は、複数のルートの各々の中間ノードのうちのいくつが複数のノードの第１のサブセットの一部であるかに基づいて複数のルートのうちの１つを選択することを含む。ステップ１１７は、ワイヤレスメッシュネットワークに選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信することを含む。これらのステップは、図１のブリッジ１に関連して述べたやり方で実行されてもよい。

無線周波数信号を送信、受信及び／又は処理するための１つ以上のデバイスを選択する方法並びにメッセージルーティングを制御する方法の第２の実施形態が図４に示されている。この第２の実施形態では、図２及び図３の方法が組み合わされる。ステップ１０１の後、図２のステップ１０３及び図３のステップ１１１の両方を含むステップ１２１が実行される。ステップ１１１は、ステップ１０３と同じステップであってもよく、又は、ステップ１１１は、例えば、ステップ１０３で決定されるサブセットからさらに狭いデバイスのサブセットを選択することを含んでもよい。ステップ１２１の後、図３に示されるステップ１１３及び１１５が実行される。

ステップ１１５の後、図２のステップ１０５及び図３のステップ１１７の両方を含むステップ１２３が実行される。ステップ１０５は、ステップ１１７と同じ、すなわち、１つ以上のメッセージが、存在及び／又は位置検出のための無線周波数信号を送信、受信、及び／又は処理するためのデバイスとして動作するようにデバイスのサブセットのうちの少なくとも１つに指示してもよい。斯くして、ＲＦベースのセンシング又はアセットトラッキングを行う（又は行わない）ようにデバイスに指示する及びルーティング指示を含む単一のメッセージが、単一のデバイスに送信されてもよい。代替的に、ステップ１１７は、例えば１つ以上のネットワークノードのルーティングプロトコルを変更するために、異なるメッセージを送信することを含んでもよい。次に、ある時間又はイベントの後、例えば、ステップ１０１又はステップ１２１が再び実行されてもよい。第１の例として、ステップ１０１、１２１、１１３、１１５及び１１７は、まずコミッショニング中に実行され、後で再びコミッショニング後及び使用後に実行されてもよい。第２の例として、ステップ１０１、１２１、１１３、１１５及び１１７は、まずコミッショニング中に実行されてもよく、ステップ１２１、１１３、１１５及び１２３は、後で再びコミッショニング後及び使用後に実行されてもよい。

本発明のネットワークメッセージを取得する方法の第１の実施形態が図５に示されている。ステップ１４１は、複数の期間の各々の第１の部分の間に無線周波数信号を送信及び／又は受信するために第１のプロトコルを使用することを含む。無線周波数信号は、存在及び／又は位置検出のために使用される。ステップ１４３は、複数の期間の各々の第２の部分の間に第２のプロトコルを使用してワイヤレス送信されるネットワークメッセージを取得することを含む。第２の部分は、第１の部分とオーバーラップしない。第１の部分の持続時間は、複数の期間のうちの少なくとも２つの期間で異なり、及び／又は、第２の部分の持続時間は、複数の期間のうちの少なくとも２つの期間で異なる。

この方法は、例えば、図１の照明デバイス１１及び１２によって実行されてもよい。本発明のシステム、例えば、図１のブリッジ１は、本発明の方法を実行するようにネットワークノードに指示してもよく、場合によっては本発明の方法をどのように実行するかをネットワークノードに指示してもよい。この指示は、例えば、図４のステップ１２３の一部として送信されてもよい。本発明のシステムの代替的な実施形態では、ネットワークノードのいずれも、図５の方法を実行しない。

無線周波数信号を送信、受信及び／又は処理するための１つ以上のデバイスを選択する方法の第３の実施形態が図６に示されている。この第３の実施形態は、ＲＦベースのセンシング（存在検出）アプリケーションで使用される。図６の実施形態では、以下の基準の１つ以上が、コミッショニング中にステップ１０１において個々のデバイスの適合性を決定するために評価されてもよい。

ハードウェア能力に関する基準
ＲＦベースのセンシングへの参加は、典型的には、送信機が余分なワイヤレスメッセージを送信する及び受信機がＲＳＳＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ Ｓｔｒｅｎｇｔｈ Ｉｎｄｉｃａｔｉｏｎ）の分析及び保存を行うことを必要とする。これは、追加の処理及びメモリリソースを必要とし、したがって、利用可能な処理及びメモリリソースを評価することは有益である。

例えば、第１世代のＰｈｉｌｉｐｓ Ｈｕｅ電球は、最新世代のＰｈｉｌｉｐｓ Ｈｕｅ電球よりも性能の低いマイクロコントローラを使用している。後者は、より多くのメモリ及び処理リソースを備えており、ＲＦベースのセンシングのためのアルゴリズムを実行し、より多くのシグネチャ（これらのシグネチャは、ＲＳＳＩの変化が、例えば人の存在を判断するために、分類されることを可能にする）を保存することができる、又は、複数の検出アルゴリズムを並行して実行することができる（例えば、第１のアルゴリズムは、低レイテンシを持つ照明グレードの占有検出であり、第２のアルゴリズムは、家の所有者が留守の間に家の中に誰かが存在することを警告する、信頼性の高いセキュリティグレードのアルゴリズムである）。同じエリアに位置する２つの同一のＨｕｅ電球の動作上の使用が異なる場合もある。例えば、第１のランプには１つのシーンしか保存されていなく、したがって、３０のシーンが保存されている第２のランプに比べて空きメモリが多い。ランプのシーン数は静的なパラメータではなく、ユーザ／システムが変更する可能性があるため、典型的には、ランプの寿命にわたり変化する。また、利用可能なメモリの量は、ランプのソフトウェアアップデートにより変わることがある。

ＲＦセンシングに適したワイヤレスビーム形状を作る等、適切なＲＦ特性を有する照明器具タイプに関する基準
異なる照明器具形状及びＲＦデザインは、異なるＲＦ特性、例えば、ワイヤレスビーム形状を招く。例えば、ガラス面を持つ天井照明器具は、メタルコーンテーブルランプとは異なるワイヤレスビーム形状を持つ。メタルコーン形状のシールドを有する第１のテーブルトップ照明器具内に配置される同じワイヤレスランプは、照明器具の外形は同じであるが、布製テキスタイルシールドを有する第２のテーブルランプと比較して、より狭いワイヤレスビームパターンをもたらす。したがって、照明器具をそのＲＦ特性、例えば、ＲＦベースのセンシング特性に関して分類することが有益である。これは、照明器具のモデル識別（例えば、「Ｐｈｉｌｉｐｓ Ｈｕｅ Ｂｅｙｏｎｄ Ｗｈｉｔｅ ｌｕｍｉｎａｉｒｅ」）又はユーザがランプが置かれている照明器具の写真をアップロードすることで行われることができる。照明器具のセンシング特性は、形状及び材料を分析すること、又は、それらをデータベースで調べることによって決定されてもよい。同じ照明器具でも異なる環境に設けられることができ、ＲＦ性能は、例えば、照明器具の上にあるコンクリートの床までの距離及びオフィスの天井の上にあるメタルパイプの存在等、環境の違いに左右され得るので、コミッショニング後に実際のＲＦ性能を測定することも有益である。

干渉及び到達性(reachability)に関する基準
干渉及び到達性に関する基準を評価することは、ＲＦベースのセンシングを行う照明デバイスの能力に影響を与える非照明デバイスによるワイヤレス干渉を受ける可能性がある、又はそのようなワイヤレス干渉を受けると（例えば、履歴データに基づいて）判断された照明デバイスを避けることを可能にする。例えば、ＲＦ放射を発する又はＲＦ送信機を備える他のデバイス（例えば、テレビ又はＷｉＦｉアクセスポイント）の近くに位置する照明デバイスは、妨害を受ける可能性がある。例えば、電子レンジ及び電動工具は、スプリアス副作用(by-product)としてＲＦ放射を発する。例えば、Ｐｈｉｌｉｐｓ Ｈｕｅライトに対するテレビ等のエンターテインメントデバイスの位置は、Ｐｈｉｌｉｐｓ Ｈｕｅ Ｅｎｔｅｒｔａｉｎｍｅｎｔ機能を設定する際にユーザによって提供されるマッピングに基づいて、カメラによって撮影される画像に基づいて、ライトの名前（例えば、「テレビライト」）に基づいて、ＢＩＭ（Ｂｕｉｌｄｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ）に基づいて、又は部屋の３Ｄモデルに基づいて決定されてもよい。

好ましくは、同じコンパクトな空間にある２つのライト等、互いに近すぎるライトは、（送信デバイス及び１つ以上の受信デバイスの）同じグループには含まれない。例えば、照明器具に５つのスポットが取り付けられ得る場合、それらのうちの２つをペアにしないことが有益である。なぜなら、人がそれらの間で検出信号を生成する可能性は非常に低いからである。

到達性は、２つのデバイスの間にある金属製のドアが閉じられる又は開いていることに起因して、場合によっては直接通信でき、場合によってはそうできない、２つのデバイス間のリンクステータスを指す。このようなリンクは、ＲＦベースのセンシングが、（火災の拡大を防ぐために価値がある）自動防火扉が閉じられているか開いているかを監視するために使用されない限り、好ましくない。

エンドユーザの使用パターンに関する基準
・ エンドユーザの使用パターンに関する基準を評価することは、１日の大半がオンしている照明デバイスと対比して、オンとオフの間を遷移することが多い照明デバイス（例えば、センサ制御されるクローゼット照明）を選択しないことを可能にする。ＲＦベースのセンシングにより導入されるレイテンシは、人にとって、ライトがオンからオフに遷移する場合よりも、ライトがオフからオンに遷移する場合にはるかに顕著である（例えば、ユーザが部屋に入りすぎて、暗闇の中で家具に衝突する場合がある）。

・ エンドユーザの使用パターンに関する基準を評価することは、ユーザが動的なライトシーン（特に、低レイテンシを必要とするシーン）のために最も使用する照明デバイスを選択しないことを可能にする。

・ エンドユーザの使用パターンに関する基準を評価することは、オフよりもオンされていることが多い照明デバイスを選択することを可能にする。ＲＦセンシングは、処理に起因して遅延を発生させるので、ライトをオンに設定するための外部トリガは、ライトがすでにオンされている場合と比べて、ライトが以前にオフされていた場合に顕著な遅延を持つ可能性がある。

ネットワークの特定のローカルサブパート(local sub-part)又は特定のデバイスにおけるローカルに利用可能な空きデータレート(spare data-rate)に関する基準
・ 良好なＲＦベースのセンシング性能を得るために必要な、コントローラ及びペアリングされたランプ間の追加のＲＦ信号を送信するためにネットワークに十分なヘッドルームがない（すなわち、空きデータレートが低い）場合、このコントローラはＲＦベースのセンシングにあまり適していない。例えば、コントローラのＺｉｇｂｅｅ無線機は、すべてのライトとトーク(talk)する（すなわち、ＲＦセンシングに関連しないトラフィックを送信及び／又は受信する）ので、多くのトラフィックを処理しなければならない。ＲＦセンシングに関連しないトラフィックを送信することは、ライト制御コマンドを送信すること又はライトから高帯域のセンサデータをバックホール(backhaul)すること、例えば、ＰｏｉｎｔＧｒａｂセンサが、室内の占有者の数及び室内で行われている作業タスク等の追加のコンテキストに関する豊富で精度の高いメトリックをゲートウェイに送信することを含んでもよい。ＲＦセンシングに関連しないトラフィックを送信及び／又は受信することはさらに、例えば、異なるネットワークセクション間でのポーリング、レポーティング、センサデータの収集、及び／又はデータのプッシュを含んでもよい。コントローラのアグリゲータ機能は、その利用可能なＴｘ／Ｒｘリソースを少なくする可能性があるが、同じネットワーク内（ましては、その近傍）の他のＺｉｇｂｅｅノードは、このような問題を持たない。したがって、大規模なネットワークでは、コントローラのＺｉｇｂｅｅ無線はすでに最大容量に達している可能性があり、コントローラは、ワイヤレスライトとＲＦセンシングペアを形成するための良い候補ではなく、とりわけＲＦベースのセンシングのためのＲＦ信号を送信するための良い候補ではない可能性があるが、集約されたＲＳＳＩデータを時折共有することは、状況によってはまだ可能であるかもしれない。しかしながら、コントローラは、ＲＦセンシングペアのリスニングパート(listening part)として機能する、すなわち、各ライトから受信するメッセージのＲＳＳＩを記録するのに良い候補であるかもしれない。各ライトは、メッセージがこの特定のライトに宛てられたものであるかどうかに関わらず、コントローラから送られるすべてのメッセージのＲＳＳＩを記録してもよい。しかしながら、容量いっぱいまで(to capacity)コントローラの無線機に負荷をかけることは望ましくない。さもなくば、望ましくない照明制御レイテンシがシステムに導入されるからである（他のライトのペアは、アプリケーションの観点から遅延が重要ではないので、最大の無線容量に満たされてもよい）。

・ 建物若しくは建物のフロアの２つのサブエリア間の又はコントローラへのネットワーク通信パスで重要な役割を果たすランプの選択は、好ましくは避けられるべきである（例えば、階段にある１つの照明は、システムが上階のメディアルームと通信するための重要なルータである）。

・ 第１のランプが送信する一方、第２及び第３のランプはＲＳＳＩを記録することができる。第２又は第３のランプがＲＳＳＩをＲＦベースのセンシンググループのコーディネータと共有することによりレポートするかどうかは、ＲＦベースのセンシンググループのコミッショニング中になされる選択に依存してもよい。第１のランプのヘッドルームだけが重要ではない。第２のランプは、第１のランプからある距離にあり、第１のランプとは異なるヘッドルームを持つかもしれない。第２のランプがそのＲＳＳＩをレポートする場合、そのヘッドルームも重要である。そのため、最大のヘッドルームを持つランプをＲＦベースのセンシングのためのＲＦ信号の送信デバイスとして割り当て、帯域幅の少ない他のデバイスは主にメッセージを聞き、集約されたＲＳＳＩデータを時折レポートするだけにすることが有利であり得る。ＲＦベースのセンシングに使用されるＲＦ信号が短い持続時間を有する場合、送信デバイスは、最大のヘッドルームを持つデバイスである必要はない。この場合、最大のヘッドルームを持つランプをＲＦベースのセンシングのためのＲＦ信号の受信デバイスとして割り当てることが有利であり得る。なぜなら、この場合、送信デバイスがＲＦベースのセンシングのためのＲＦ信号を送信している一方、受信デバイスが他の信号を送信又は受信していない確率が最も高いからである。

・ 商業施設では、フロアごとに複数のＷｉＦｉ対応ゲートウェイが使用され、各ゲートウェイがＺｉｇｂｅｅライトのサブセットからのデータをクラウドにバックホールし、例えば、高度な機械学習及び分析（例えば、人カウント）のために、大量のＲＦベースのセンシングデータがクラウドにバックホールされる場合、クラウドバックホールのための最大の空き容量(spare capacity)を持つゲートウェイに接続されているライトが最も適している。

・ 異なるセンシングレートが空間のサブエリアに割り当てられることがある（例えば、自動ライトオン挙動が必要なエリアには高いレートが割り当てられ、ライトが既にオンされている空間の他のエリアには低いメッセージレートが割り当てられる）。典型的には、ＲＦベースのセンシングアルゴリズムでは、複数の送信デバイスの各々が、１ループにつき１回、ＲＦ信号を送信する。しかしながら、送信デバイスに、１ループにつき複数回、ＲＦ信号を送信させることにより特定のエリアにおけるセンシングレートを高めることができる。例えば、通常の状況では、各センシングループは、ノード１、２、３、４、５からのメッセージを得る。センシングレートは、センシングループを１、２、２、３、４、５、５、５に変更することによって（ノード２及び５は入口に近いため、特別にスナッピー(extra snappy)である）特定のサブエリアにおいて高められてもよい。これらの異なるセンシングレートは、ネットワークの利用可能な帯域幅を決定し、これに基づいてデバイスの適合性を評価する場合に考慮されることが好ましい。

空間的基準
Ｐｈｉｌｉｐｓ Ｈｕｅランプは通常、部屋ごとにグループ化される。そのため、ユーザがグルーピングのための何らかの論理的な基準を使用したと仮定すれば、各ランプがどの部屋にあるのかがわかる。しかしながら、Ｈｕｅシステムは、建物（例えば、家）又は建物のフロアの全レイアウトは分からない。他のセンシング技術とは異なり、ＲＦベースのセンシングは、占有センシングターゲットエリアの（中ではなく）近く（例えば、隣接する部屋の中）のランプの使用も考慮することができ、第１の部屋の占有マッピングを成功裏に行うことができる。Ｐｈｉｌｉｐｓ Ｈｕｅシステムでは、典型的な部屋は、ＲＦベースのセンシングの観点から、照明器具の配置、高さ、照明器具のタイプ等に起因して、多くの異なるタイプの照明器具を含む。隣接する２つのベッドルームは、同様のタイプの照明器具が存在することがよくある（例えば、１つのシーリングライト、１つのテーブルライト、及び床の高さにあるストリップ）。

性能を向上させるために、ＲＦベースのセンシングのためのデバイスの適合性の決定は、各部屋内のどこに、及びどのような相対的な高度にライトが位置付けられるかを考慮に入れる。例えば、図７に示されるように、３つのベッドルームの住宅の１階において、部屋４１（部屋Ａ）については、２つの天井照明器具５１及び５２がＲＦベースのセンシングを行うために割り当てられ、部屋４１（部屋Ａ）に隣接する部屋４２（部屋Ｂ）については、２つのテーブルトップランプ５４及び５５がＲＦベースのセンシングのために割り当てられ、部屋４３（部屋Ｃ）については、ソファ／テレビの下にあるＬＥＤストリップ５７が割り当てられることがある。照明器具の配置及びタイプの違いに起因して、記録されるＲＦベースのシグネチャは大きく異なり、部屋４１（部屋Ａ）の２つの天井照明器具５１及び５２間の送信により、システムが部屋４１（部屋Ａ）で高いＲＳＳＩ信号を見る場合、部屋４１（部屋Ａ）の２つの天井照明器具５１及び５２間の送信により、システムが部屋４２（部屋Ｂ）で減衰された（しかし依然として高い）ＲＳＳＩを見る場合もある。

通常、これは、部屋４２（部屋Ｂ）でフォールスポジティブをトリガしてしまうであろうが、部屋４２（部屋Ｂ）は意図的にＲＦベースのセンシングに天井を使用せず、むしろ照明器具の異なる一般形状及び異なる減衰を持つテーブルトップランプ５４、５５を活用するので、フォールスポジティブを識別し無視することは容易である。ＲＦベースのセンシングがどのように実装されるかに依存して、ＲＦベースのセンシングのために、占有検出ターゲットエリア内にある天井及びテーブルライトを選択せず、むしろテーブルトップランプ５４又は５５等、隣接する部屋に位置する別のテーブルランプと組み合わされる（図示せず）ターゲットエリア内のテーブルランプを選択することが有利であり得る。これは、テーブルライトがほとんど空気によって囲まれているのに対して、シーリングライトは、鉄を有するコンクリート天井によって形成される潜在的にＲＦを反射する表面に片側で面しているため、同じ高度のライトが最適なＲＦベースのセンシング解像度をもたらすからである。状況によっては、シーリングライトは、オフィス家具等の他の物体によって最も邪魔されにくく、したがってＲＦベースのセンシングを行うための最適な場所となることもある。ミリ波（超短波（Extremely High Frequency））無線技術が使用される場合、この無線技術は非常に指向性であるため、ランプ間に見通し(line of sight)パスがあることが重要である。

さらに、排水管（トイレの洗浄水の水塊が誤ったトリガ(false trigger)の原因になり得る）、葉が濡れた揺れる木、及び道路に直接つながっている家の中の歩道から離れているデバイスが好ましい。

部屋の外の廊下を人が歩くことに起因して誤ったトリガを与える照明器具を避けることは有益であり得る。可能ではない又は望ましくない場合、このような照明器具からのトリガは、２ステップの占有検出プロセスの第１のステップとして使用されてもよい（例えば、第１のトリガは、廊下に近い照明器具によって生成され、この第１のトリガは、部屋の中でより遠くに位置するが、依然として第１の照明器具に近い照明器具の検出閾値を下げる。この２ステッププロセスは、部屋に入る人の良好な検出を可能にする。）さらに、部屋の中で必要とされる動きよりも大きな動きでなければ、外の検出をトリガできないように、異なる重みが、このような照明器具に割り当てられてもよい。

（単に部屋の検出が占有／非占有ではなく）人カウント(people counting)を行うデバイスの適合性
人カウントは、常に正確なカウントであるということではなく、場合によっては単に部屋の中の２レベル又は数レベルの占有を区別することでもある。例えば、部屋が適度に混雑しているのか、非常に混雑しているのかを知ることは、冷暖房空調（ＨＶＡＣ：Heating, Ventilation and Air Conditioning）の空気の流れを（受身的ではなく）能動的に増やすことを可能にする。したがって、ＲＦベースのセンシングを用いて、以前よりも空間に関するコンテキスト情報を少し多く得ることができる。人カウントのためには、ＲＦベースのセンシングに対する要求は、部屋が占有されている又は占有されていないかどうかの単なる検出のためのものよりも高い。

経時的にバイオマスの空間的な位置を決定するため（例えば、倉庫（サイト及びエリア（ｓｉｔｅ ＆ ａｒｅａ）照明器具のグリッドを有する大きなスクエア）内の人又は運転手がいるフォークリフトを追跡するため）のライトの適合性
ワイヤレス通信信号は水によって強く吸収されるため、ＲＦベースのセンシングは、バイオマス（すなわち、水分を多く含むボディ）の存在に対するディテクタである。したがって、例えば、製造現場において、ＷｉＦｉを備えた照明器具の規則的な天井グリッドによって行われるＲＦベースのセンシングは、従業員を追跡することができる。さらに、フォークリフト等の大きな金属面はワイヤレス信号を反射し、したがって２つの照明器具間のフォークリフトの存在によって生じる変化が検出され、（人体ではなく）フォークリフトとポジティブにリンク付けられることができる。

取付向きに関する基準
取付向きに関する基準を評価することは、ターゲットエリアに対して適切なＲＦ特性、例えば、ＲＦビーム形状をもたらす取付向きを持つデバイスを選択することを可能にする。スポット照明器具等、一部のライトは、調整可能な方向を持つ。通常、照明器具の方向は、器具の設置中にユーザによって一度設定され、その後調整されることはない。例えば、メタル形状のスポットライトは、上向き、下向き、又は左若しくは右に向けられ得る。スポットの向きに起因して、ＲＦ送信の方向性及びメタルコーン内から空間へのその伝搬は大きく異なる。

例えば、ワイヤレスビームが、ミリ波（ＥＨＦ）無線機又は（複数の）指向性アンテナを備えるＷｉＦｉ無線機を使用してターゲットエリアに向けられ、他のＲＦ特性も適している場合、照明器具内のＨｕｅランプは、ＲＦベースのセンシングに適しているかもしれないが、ビームが天井に向いている場合、同じランプは、（他のＲＦ特性が適している場合でも）適していないかもしれない。モバイル照明器具は、ユーザに照明器具（例えば、装飾的な照明のためのキューブ形状の照明器具）の異なる向きを提供することができ、その結果、無線機がその時点でどこに位置しているかに依存して、異なるＲＦ特性、例えば、ＲＦビームがもたらされる。これらの向きは、内部的に例えばジャイロスコープ等のオンボードセンサを用いて、又は、外部的に例えばカメラの使用によって容易に検出されることができる。

特に照明器具に関する様々な基準
・ ドライバの配置。金属の中に配置される／金属の周りにある／金属によって囲まれるワイヤレスドライバは、ＲＦ性能に対するその影響に起因して好ましくない。例えば、ＨＶＡＣダクト等の主要な金属物の近く、金属配線の近く、又は柱及び鉄骨等の構造要素の近くにあるワイヤレスドライバは避けられることが好ましくない。照明デバイスにおけるドライバは、主として、光源、例えば、ＬＥＤを光らせるために、入力主電源又はＤＣ電圧供給バス（例えば、４８Ｖ又はソーラーからの高電圧ＤＣ）を制御された電圧に変換する回路である。ワイヤレスドライバはまた無線機を有し、結果として照明器具はワイヤレスで通信することができる。ドライバは光源の近くにある必要はない。例えば、光源は天井から吊るされていて、光源に給電するドライバは天井の裏側にあることがある。これは、予想と異なるＲＦ性能を招き得る。

・ 照明器具のハウジングのタイプ。プラスチックの照明器具のハウジングは、穴あき金属の照明器具のハウジングよりも好ましく、穴あき金属の照明器具のハウジングは、連続した金属の照明器具のハウジングよりも好ましい。金属は場合によってはＲＦ信号を整形するのに役立つことができるが、通常、ドライバが自由な空気(free air)に近いほど良い。金属は、（ＲＦ目的のためには）自由な空気とはほとんど反対のものである。

・ 照明器具の開口の方向及び大きさ。ＷｉＦｉベースのＲＦベースのセンシングでは、より高い周波数のＷｉＦｉ（５ＧＨｚ）は、金属のより小さい開口を有する照明器具に割り当てられるのが好ましい。

・ 無線機／照明器具が面している(facing)方向。吊下げオフィス照明器具は、ワークデスクの真上の目の高さに位置することがよくあり、天井に向けたアップライティング及びデスクのタスクエリアに向けたダウンライティングのための２つの独立した光源を持つことがよくある。これらの２つの光源は、ワイヤレス無線機を備える２つの独立したＬＥＤドライバによって制御されることがある。例えば、上方に面する無線機を備えるワイヤレスＬＥＤドライバは、例えば、ワイヤレス信号の反射につながる多くの金属梁及び金属面を含むオフィス家具から離れているので、下方に面するＬＥＤドライバを備えるワイヤレスＬＥＤドライバよりも好ましい。さらに、椅子等の物体の位置がワイヤレス信号の吸収に影響を与え、ベースライン信号に変化を与えることがある。照明器具の上面にあるワイヤレスＬＥＤドライバは、空気の柱(column)に向かって上方に面し、したがってワイヤレス信号は、よく予測可能且つ再現可能な態様で伝搬する。

図６の実施形態では、デバイスの適合性はまた、デバイスのグループごとに適合性を決定することによって決定される。これは、ステップ１０１のサブステップ１６１～１６４で実行される。各グループは、少なくとも２つのデバイス、典型的には、送信デバイスと、１つ以上の、例えば、２～４つの受信デバイスとを含む。ステップ１６１は、デバイスの複数のグループを選択することを含む。上述の基準を評価した後に選択されたすべてのデバイスは、潜在的にのグループに含まれる可能性がある。互いに一定の距離内にあるすべての選択されたデバイスがグループ化されてもよい。複数のデバイスが互いに協力してもよい。その後、これらのデバイスは、同じグループ内の他のデバイスの一部又は全部によって送信されるＲＦ信号のＲＳＳＩを記録する。この場合、グループ内のデバイスのＲＳＳＩが、空間が占有されているかどうかを判断するために評価される。斯くして、グループは２つ以上のデバイスを含み、それらのデバイス間の一部又はすべての一対一接続（「ペア」）が使用されることがある。

直ちに必要な数以上のデバイスが選択されてもよい。これらのスペアデバイスは、オン／オフスイッチを有するテーブルライトのエリア等、ノードが給電停止される可能性が高い１つ以上の検出エリア内で／そのために選択されてもよい。例えば、４つのデバイスではなく、６つのデバイスが、ＲＦベースのセンシングのために協働するように採用されてもよい。この結果、より高いネットワーク負荷及びより高いマイクロコントローラ（ｕＣ）負荷がもたらされるが、１つ又は２つのデバイス（例えば、ライト）が給電停止される（次のイベントでどのデバイスが給電停止されるかは、事前にはわからない）場合に検出エリアが依然として機能することを確実にする。

ステップ１６２は、共通のデバイスを有し、同じ又は隣接したセンシングエリアをターゲットにしている複数のグループのうちの２つのグループがあるかどうかを判断することを含む。言い換えれば、ステップ１６２は、相互に排他的なデバイス、例えば、照明器具、グループを決定／選択することを含む。この判断が肯定的である場合、２つのグループのうちの１つは適していないと判断される。ＲＦベースのセンシングの１つの不利な点は、部屋Ａにいる人が部屋Ｂの壁の近くにいると、部屋Ｂでもワイヤレス障害(wireless disturbance)をもたらすことである。したがって、先行技術のＲＦベースのセンシングでは、２つの部屋のうちの正しい１つにユーザの位置を定めるための信頼性が損なわれる。

家全体又は建物の一部（すなわち、単一のターゲット検出エリアではなく、複数のターゲット検出エリア）に対してＲＦベースのセンシングを行う場合、隣接する部屋でＲＦベースのセンシングに使用されるライトの２つのグループが相互に排他的なグループである（すなわち、１つのライトが、２つの隣接するＲＦベースのセンシンググループのうちの一方にしか属し得ない）ように、ＲＦベースのセンシング機能を割り当てることが有益である。相互に排他的な照明器具グループを選択することは、２つの異なるライトグループのＲＦベースのセンシング信号ができるだけ異なって見えることを確実にする。これは、部屋Ａでの検出不良(poor detection)が部屋Ｂによって「盗られる」可能性を減らし、したがって曖昧さ及び占有検出のフォールスポジティブを減らす。

同じ原理は、グループが３つ以上のライト、例えば、１つの送信ライト及び複数の受信ライトを含む場合にも使用され得る。同じライトは、負荷をよりよく分担するために複数のグループに対するＲＦベースのセンシングアルゴリズム処理をすべて行うコントローラになるべきではない。しかしながら、（ａ）聞くメッセージのＲＳＳＩを記録し、（ｂ）ＲＳＳＩをレポートする非コントローラノードは、２つの異なるグループに同時に参加することがある。この場合、これは、第１のライトグループによって受信されるＲＦ信号のＲＳＳＩだけでなく、第２のライトグループのＲＳＳＩもレポートする。

ステップ１６３は、複数のデバイスのうちのペア間の通信品質がある閾値を下回るかどうかを判断することを含む。この判断が肯定的である場合、このペアは適していないと判断される。通信品質は、典型的には、ＲＦベースのセンシングパスをブロックする障害物があるかどうかに依存する。ＲＦベースのセンシング方法は、必ずしもデバイス間の直接の見通しを必要としない。しかしながら、ワイヤレス信号は、特定の障害物を見通すことはできない。例えば、エンドユーザが大きな金属製家具（例えば、本棚）を再配置する場合、デバイス間のＲＦセンシングパスが損なわれる可能性がある。

通信品質は、静的な信号パスの変化により、デバイスのペア、例えば、ランプ１及びランプ２の間の検出パスが壊れる場合、ある閾値を下回るとみなされてもよい。壊れたＲＦベースの検出パスを検出するために、システムは、部屋の現在のＲＦシグネチャと、検出エリアに存在する人からの寄与がない可能性が非常に高い深夜（例えば、午前２時）に、又は、すべての占有者が家を出ていることが分かっている場合の当該部屋のＲＦシグネチャとを比較してもよい。

通常、デバイスが互いに通信できる場合でも、通信品質は、ある閾値を下回ることがある。信号が弱い場合、妨げになる(in the way)人体によってもたらされる等の潜在的な一時的障害物により、パスが一時的に効果的に壊れていることを意味する。したがって、人体によってもたらされる障害物を含む、最悪のシナリオを考慮しながら、通信品質を測定／推定することは有益である。ステップ１６４において、残りの（すなわち、適切な）グループのデバイスは、適していると判断される。例えば、ステップ１６２は、コミッショニング中及びコミッショニング後に実行されてもよく、ステップ１６３は、コミッショニング後に実行されてもよい。

ステップ１０１、１０３及び１０５がコミッショニング中に実行された後、システムの通常の動作が開始されてもよく、すなわち、ＲＦベースの存在及び／又は位置検出が、ステップ１０５で指示された少なくとも１つのデバイスによってステップ１６６で実行されてもよい。ステップ１６７において、一定の時間が経過した及び／又は別の基準が満たされ、したがってデバイスの適合性が再評価される必要があるかどうかが（すなわち、コミッショニング後に）チェックされる。そうでない場合は、ＲＦベースの存在及び／又は位置検出はステップ１６６で継続されてもよい。そうである場合、ステップ１０１が再度実行されてもよい。

例えば、ステップ１６７において、天候が（大きく）変化したかどうかがチェックされてもよい。例えば、ＲＦベースのセンシングが（例えば、人カウントのため）外部のガーデン照明に適用されており、システムが現在雪が降っていることを知り、ワイヤレス信号の送信に影響を与える可能性がある場合、ＲＦベースのセンシングのために異なるライトを選択することが有益であり得る。天気の良いときには、庭のドアから５メートル離れた家の壁に取り付けられた主電源式のライトが、ＲＦベースのセンシングを行うために使用されてもよい。雪が降っているときは、庭のドアのすぐそばに位置するバッテリ式のガーデンライトが、ＲＦベースのセンシングを行うために使用されてもよい。同様に、霧又は雨は、ワイヤレス信号を減衰させることが知られている。

また、デバイスの適合性は、ＲＦベースのセンシングモードが、例えば、人カウント、人位置特定(people locating)、誰もいない部屋への人入室の検出、及びセキュリティの間で切り替えられる場合に再評価されてもよい。例えば、人カウントは、タイムクリティカルな機能(time critical feature)ではない。部屋に３人の人がいると結論付けるのに例えば１０～３０秒かかることは通常完全に許容できる。ある選択基準に基づいて、照明器具１、２、３、４は、人が部屋に入る場合に即座の検出を提供するものであるため、照明制御に最適であると第１の時点で結論付けられるかもしれない。しかしながら、システムは、アプリケーションの目的が、まず（ライトをオンにするために）部屋に誰かいるかどうかを判断し、その後でのみ何人いるかをカウントするように、層構造にされることができる。

このような場合、最も簡単な方法は、システムを常に動きセンシングモードで動作させることである（これは最も低いレイテンシを招く）。部屋の中に少なくとも一人の人がいることが確実になると、システムは自動的に人カウントモードに切り替わることができる（これは、最も豊かな(richest)情報を提供する）。しかしながら、ライト１、２、３、４は、部屋の中央ではなく、入り口に近い場所にある等、人カウントに理想的なライトではない可能性がある。この場合、システムは、ＲＦベースのセンシングのために例えば、３、４、５、６、７の照明器具を選択することができる（これらの照明器具は、人カウントに最適な照明器具である）。同様のことは、照明制御モード（例えば、日中）及びセキュリティモード（夜間又は週末及び休日）間の切り替えにも当てはまる。

（コミッショニング後に実行される）ステップ１０１の第２の反復において、無線周波数信号の送信、受信及び／又は処理のための複数のデバイスの各々のさらなる適合性が決定される。ステップ１０３の第２の反復において、複数のデバイスの各々について決定されるさらなる適合性に基づいて複数のデバイスからさらなるデバイスのサブセットが選択される。ステップ１０５の第２の反復において、さらなるデバイスのサブセットのうちの少なくとも１つが、存在及び／又は位置検出のための無線周波数信号を送信、受信及び／又は処理するためのデバイスとして動作するように指示される。

図６の実施形態では、以下の基準の１つ以上が、コミッショニング後にステップ１０１において個々のデバイスの適合性を決定するために評価されてもよい。

ネットワーク到達性に関する履歴
ネットワーク到達性に関する履歴を評価することは、ネットワーク到達性の履歴が悪いランプへの、ＲＦベースのセンシングを行うタスクの割り当てを避けることを可能にする。

・ ユーザは、レガシー壁スイッチで特定のランプをオフにする、すなわち、ワイヤレスランプの給電を停止し、したがってＲＦベースのセンシングを行えなくする傾向があるかもしれない。このランプをＲＦベースのセンシングに使用しないのが良い。

・ 特定のランプは、ワイヤレス干渉に起因して（例えば、同じ２．４ＧＨｚ帯が、隣のアパートメントのオーディオストリーミングシステムによって使用される場合）到達性が悪くなることがある。

メッシュネットワークにおいて、メディアルームは、キッチンエリアに位置するランプ１及び２を介してメッシュすることによってしか到達されることができず、ランプ１が、例えばユーザがレガシー壁スイッチを頻繁に使用するため、悪い履歴的な到達性を有する場合、ランプ２がＲＦベースのセンシングのためのクリティカルなライトでない限り、コア照明制御コマンドがメディアルームに到達するためのクリティカルパスの問題を避けるために、ランプ２をＲＦベースのセンシングノードとして選択しないことが最善である。例えば、他の候補がなく、メディアルームへのメッセージがネットワークを完全に満たしていない場合、ランプ２をＲＦベースのセンシングノードとして選択することはまだ良い可能性がある。この場合、ランプ２は、ＲＦベースのセンシングデバイスとして適しているが、他のデバイスよりも少ない時間でＲＦベースのセンシングタスクに割り当てられてもよい。斯くして、ランプ２は、適していると考えられるが、他のデバイスよりも適していないと考えられ、デバイスによって実行されるＲＦベースのセンシングの程度は、その適合性の程度に依存してもよい。ランプ２によってＲＦベースのセンシングに費やされる時間は、ランプ２がオーディオ及び／又はビデオコンテンツに付随するライトコマンドのストリーミングに使用されるかどうかに依存してもよい。

動きセンサ、バッテリ式のスイッチ、又は主電源供給されるＺｉｇｂｅｅスイッチによる制御
デバイスが動きセンサ、バッテリ式のスイッチ、又は主電源供給されるワイヤレス（例えば、Ｚｉｇｂｅｅ）スイッチによって制御されるかどうかを評価することは、動きセンサ、バッテリ式のスイッチ、又は主電源供給されるＺｉｇｂｅｅスイッチのいずれかによって制御されるＲＦベースのセンシングノードしてのライトを選好することを可能にする。これらのライトは、ワイヤレスランプへの電力を途絶する、レガシー壁スイッチを使用するライトよりも、ユーザによってオフにされる可能性が低い。

リアルタイムのワイヤレス干渉に関する基準
リアルタイムのワイヤレス干渉に関する基準を評価することは、非照明デバイス及び他の照明システムによって引き起こされる（したがって、ＲＦベースのセンシングを行うランプの能力に影響を与える）ワイヤレス干渉の影響を目下受けているランプを避ける一方、同じ場所ではあっても、後の時点においては、この基準の評価の結果、これらのランプが、ＲＦベースのセンシングを行うための有効な候補と見なされることを可能にする。

・ 他の無線機を備える家電機器（例えば、テレビ又はＷｉＦｉアクセスポイント）の近くに位置する、ランプは、家電機器がオンにされる、又はＷｉＦｉでのビデオストリーミングが始まるや否や妨害を受けることになる。しかしながら、テレビがオフしている場合、テレビの近くにあるランプは干渉を受けず、したがって該ランプはＲＦベースのセンシングを行うのに適した候補である。Ｐｈｉｌｉｐｓ Ｈｕｅライトに対するテレビ等のエンターテインメントデバイスの位置は、Ｐｈｉｌｉｐｓ Ｈｕｅ Ｅｎｔｅｒｔａｉｎｍｅｎｔ機能の設定時にユーザによって提供されるマッピングに基づいて決定されてもよい。テレビのリアルタイムの状態（オン又はオフ）は、テレビのＡＰＩ又はホームオートメーションシステム（例えば、Ａｐｐｌｅ Ｈｏｍｅｋｉｔ／Ａｐｐｌｅ ＴＶ又はＧｏｏｇｌｅ Ｈｏｍｅ）のＡＰＩを介して、Ｐｈｉｌｉｐｓ Ｈｕｅシステムによって取得されてもよい。

・ さらに、干渉は他の照明システムから発生することもある。例えば、隣人のリビングルームの近くに位置するランプは、例えば、ＣｈｒｏｍｅＣａｓｔによって使用される等ＷｉＦｉを介した該隣人のテレビへのビデオストリーミングのたびたびの期間、又は同じＺｉｇｂｅｅチャネルで動作している該隣人のメッシュ照明ネットワークからのワイヤレス干渉を受ける可能性がある。

エンドユーザの使用パターンに関する基準
・ エンドユーザの使用パターンに関する基準を評価することは、１日の大半がオンしている階段にあるライト（又は常にオンしている非常用ライト）と対比して、オンとオフの間を遷移することが多いことがシステムによって分かっているランプ（例えば、ライトの瞬時のオンを必要とする、センサを備えるウォークインクローゼットライト）を選択しないことを可能にする。ＲＦセンシングにより導入されるレイテンシは、人にとって、ライトがオフからオンに遷移する場合にはるかに顕著である（例えば、ユーザが部屋に入りすぎて、暗闇の中で家具に衝突する場合がある）。

・ エンドユーザの使用パターンに関する基準を評価することは、ユーザが動的な照明シーンのために最も使用するランプ（特に、低レイテンシを必要とするシーンに参加するランプ）をＲＦベースのセンシングのために選択しないことを可能にする。

ワイヤレスネットワーク全体内の現在のフリーで利用可能なデータレート(current freely available data-rate)に関する基準
何百ものライトを含む大規模なＺｉｇｂｅｅネットワークでは、１５秒ごとにリンクステータスを送信するＺｉｇｂｅｅルータデバイスによって引き起こされるトラフィックは、すでに総Ｚｉｇｂｅｅエアタイムバジェットの１５％を消費する可能性がある。典型的には、これは直ちに、大規模なネットワークにとって、システムが通常の基本的なシステムタスクに加えて新しい一時的なタスクを実行しなければならない場合（例えば、ＯＴＡＵファームウェアアップデート、動的に調整可能な白色照明シーンの実行、高解像度のＲＦベースのセンシング、エンターテイメントのストリーミング）、帯域幅の不足を招く。したがって、大規模なネットワークでは、少ないデバイスが、ＲＦベースのセンシングの役割のために選択されてもよく、適合性の要件は、より厳しく、正確な情報に基づいて適用されることが好ましい。小規模なネットワーク（例えば、３０個のワイヤレスライトを含むネットワーク）では、より多くのエアタイムヘッドルームが、ＲＦベースのセンシング等の追加タスクを実行するライトに対して利用可能である。

Ｚｉｇｂｅｅネットワーク内の現在利用可能なフリーエアタイム(currently available free airtime)
どのランプグループがＲＦベースのセンシングに最適であるかは、通常、Ｚｉｇｂｅｅネットワーク内で現在利用可能なフリーエアタイムに依存する。ＲＦベースのセンシングへの参加は、典型的には、送信機が余分なワイヤレスメッセージ又は他の信号を送信する及び受信機がＲＳＳＩ及び他のネットワーク診断パラメータを決定し、ＲＳＳＩの分析及び保存を行うことを必要とする。例えば、ランプＡ及びランプＢの間のリンクは、最高のデータレートでのみ最良の占有検出結果を与えるかもしれない（例えば、Ｐｈｉｌｉｐｓ Ｈｕｅエンターテイメントモードが実行されている場合）。低い帯域幅しか（例えば、混雑したスペクトルに起因して）ランプ間で利用可能ではない場合、ランプＢ及びランプＣの間のリンクが、占有検出を行うのに最適であるかもしれない。

典型的には、単一の送信デバイスと複数の受信デバイスとの間のリンクが、ＲＦベースのセンシングのために評価される。典型的には、ＲＦベースのセンシンググループは、３～５個のランプがメッセージを送信すること、及び、他のランプから受信されるメッセージのＲＳＳＩを決定することを含む。ランプのうちの１つは、占有検出アルゴリズムの処理を行うように割り当てられ、他のランプは、メッセージを送信し、存在検出処理アルゴリズムを行う当該１つのランプにＲＳＳＩをレポートするだけでもよい。

Ｚｉｇｂｅｅネットワーク内の予測されるフリーエアタイム(forecasted free-airtime)
（コンテキストに基づいて）Ｚｉｇｂｅｅネットワーク内のフリーエアタイムを予測することにより、ＲＦベースのセンシングを行うランプの選択を能動的に調整することができる。多くの場合、照明システムは、（１）特定のスケジュール（例えば、午後８時にスケジュールされている動的なシーン）、（２）履歴から分かる、その後あるピーク負荷を引き起こすようなセンシングされるパラメータ（例えば、人が８時３０分にメディアルームに入ることは、該人が動的なＡｍｂｉｌｉｇｈｔサラウンド照明を用いてテレビを見ることを意味する可能性が高い）、（３）スケジュールソフトウェアアップデートサイクル（ＯＴＡＵ）等の状況に起因して追加のネットワーク負荷が発生するであろうことを事前に分かっている。これらの場合、相応にＲＦベースのセンシングを行うランプの選択を能動的に調整することが有益である。

例えば、照明システムは、メディアルームでエンターテイメント照明シーンがまもなくアクティブにされることを予測する。システムは、階段にある照明が、コントローラ／ブリッジが上階のメディアルームのエンターテイメント照明と通信するための重要なＺｉｇｂｅｅルータになるであろうことを知っている。したがって、システムは、このランプをＲＦベースのセンシングノードとして選択せず、又は、ＲＦベースのセンシングに特有の追加のＲＦ信号を送信するため及び／若しくはＲＦベースのセンシングに特有の処理を実行するためにこのランプを選択しない。

建物若しくは建物のフロアの２つのサブエリア間の又はコントローラへのネットワーク通信パスで重要な役割を果たすランプの選択も、好ましくは避けられるべきである（例えば、階段にある１つの照明は、システムが上階のメディアルームと通信するための重要なルータである）。特別な状況では、階段にある照明は、自身の照明制御に関連するメッセージから、頻繁で経時的によく分布される通信パターンをすでに決定している可能性があり、このランプは、ＲＦベースのセンシングに特有の余分なメッセージ又は信号を追加する必要なくＲＦベースのセンシングに適し得る。

パラメータを修正する又アクションを遅らせる可能性
パラメータ又はアクションが修正／遅延されることができるデバイスが好ましい。なぜなら、これは、ほぼ完璧なＲＦベースのセンシングがあることを確実にし得るからである。例えば、ライトのファームウェアのＯＴＡＵを実行する場合、照明システムは、占有検出ターゲットエリアの各々について現在必要なＲＦベースのセンシングエリアモードを実行するのに十分な帯域幅を残すようにＯＴＡＵ速度を適応させることができるのが好ましい。代替的に、消費エネルギ及び温度等の非レイテンシクリティカルなパラメータのレポートのタイミングが、ＲＦベースのセンシング性能を最大化するために修正されてもよい。

現在利用可能なフリー処理能力の量(amount of free processing power)
デバイスの現在利用可能な処理リソースを評価することは、ＲＦベースのセンシングデータ及び検出アルゴリズムの高速処理を保証するために現在利用可能なフリー処理能力の量を持つランプを選択することを可能にする。例えば、レイテンシが低い照明クラスの検出アルゴリズム、及び、検出信頼性は非常に高いがレイテンシが高い、空き家への侵入者を検出するためのセキュリティクラスのアルゴリズム等、複数の検出アルゴリズムが並行して実行されることがある。

例えば、ＲＦベースのセンシング信号の処理時間が０．２秒を超える場合、照明制御のレイテンシは、エンドユーザにとって許容できないものになる可能性がある（特に、ライトがオフにされていて、占有センシングに基づいてアクティブにされる必要がある場合）。例えば、同じエリアに位置する２つの同一のＨｕｅ電球の動作上の使用が異なる場合がある。例えば、第１のランプには１つのシーンしか保存されていなく、したがって、３０のシーンが保存されている第２のランプに比べて空きメモリが多い。ランプのシーン数は静的なパラメータではなく、システムの寿命にわたり変化する可能性がある。また、利用可能なフリー処理能力は、ランプによって異なり、例えば、マイクロ波センサを内蔵した複雑なライト効果を行うランプは、静的なランプに比べて空きＣＰＵリソースが少なくなる。

Ｐｈｉｌｉｐｓ Ｈｕｅシステムでは、一部の電球が、ＺｉｇｂｅｅエンドノードのためのＺｉｇｂｅｅ親ノードとして動作する。親ノードになると、非親ノードの電球に比べて追加のリソース（例えば、処理、データストレージ、エンドノードとの定期的な無線コンタクト）を消費する。典型的なＺｉｇｂｅｅエンドノードは、壁スイッチ及びセンサ等のバッテリ式のデバイス又はバッテリ式のライトである。Ｚｉｇｂｅｅエンドノードは、最適なワイヤレスリンクに基づいて親を動的に選択する。したがって、Ｚｉｇｂｅｅエンドノードの親デバイスは、寿命にわたり数回変わる可能性がある。したがって、Ｚｉｇｂｅｅ親デバイス及びＺｉｇｂｅｅエンドデバイスを単一のＲＦベースのセンシンググループに割り当てることは、有利ではないかもしれない。さらに、ＲＦベースのセンシングは、典型的には、追加のＲＦ信号及び／又は処理を必要とし、したがってＺｉｇｂｅｅエンドデバイスのバッテリ寿命を短くする。

ＲＦベースのセンシングが、複数のアプリケーション、例えば、セキュリティ及びライト制御に使用される場合、典型的には、複数のアルゴリズムが実行される必要がある。１つのデバイスが両方のアルゴリズムを処理できれば理想的であるが、複数のアルゴリズムのうちの１つを実行できるデバイスも適していると考えられ得る。このようにして、他の基準を鑑みて適しているすべてのデバイスが無視されないが、利用可能な処理能力の基準は、オールオアナッシングのアプローチではなく、複数のノードに分けられるように、責任が分けられてもよい。これは、アルゴリズムが「スタック」される場合に使用されてもよい。例えば、動きがあることをすぐに判断するのはアルゴリズムＡであるが、より深く見て、より高いレイテンシを犠牲にしてもはるかに高い信頼度で存在を結論付けるのはアルゴリズムＢである。アプリケーションは両方の結果を得たいと思うかもしれないが、このスタッキングに起因して、ノードは、Ａ又はＢのいずれかの実行に適しているが、両方を実行するのには適しないという状況に達する可能性がある。

ライトのオン／オフ状態
ライトのオン／オフ状態を評価することは、ＲＦベースのセンシング時の照明システムのスタンバイ電力を最適化することを可能にする。典型的には、デバイスは、（ライトがオン又はオフであるかどうかに関係なく、ルータランプデバイスのアイドル状態である）受信時よりも送信時にやや多くの電力を必要とする。したがって、ライトが「オフ」である際にＲＦベースのセンシングのための重いワイヤレストラフィックを送信することは、（ライトがオフであるため「待機電力」と見なされ得る）消費電力を増加させる可能性がある。潜在的な将来のより厳しい待機電力規制を満たすためには、現在オンである、すなわち、（可能であれば）光を発しているライトを、ＲＦベースのセンシングを行うために優先的に選択することが有利であり得る。

現在の熱安定性
ランプの現在の熱安定性を評価することにより、ＲＦベースのセンシングを行うために現在熱的に安定しているランプを選択することができる。ランプの温度は、動作状態が点灯／消灯の間で変えられる場合にドリフトする可能性がある。この結果、無線電子機器における温度ドリフトをもたらし、結果として、ワイヤレストランシーバ特性（例えば、受信感度）のドリフティングをもたらす。したがって、熱的に「安定した」ランプを選択することは、消灯と点灯との間を遷移したばかりのライトを利用するよりも無線機間のオフセットが小さくなる。より熱的に安定しないランプの場合、これらのドリフト／オフセットにより、システムは環境のダイナミックな特性が変化したと錯覚し、動きがあったと結論づける可能性がある（これはフォールスポジティブである）。

日光への曝露
日中、特定のエリアにおいて十分な自然光が得られるため、特定のライトが決してオンされないことがある。これらのライトは、ユーザによってオンされることが予想されず、したがって、ランプはオフされているにも関わらず、照明制御に低いレイテンシを必要としないので、ＲＦベースのセンシングの優れた候補である。これらのランプがオンされる場合、既に存在している日光の量が、別の以前暗かった部屋がオンに遷移する状況と比較して、潜在的なレイテンシの問題の影響を隠す助けとなるであろう。それゆえ、日光への曝露が高いランプを選択することは有益である。しかしながら、あるライトは、日中には優れたＲＦベースのセンシングノードであっても、夜間にはよくない選択(poor choice)となる可能性がある（この空間のために低レイテンシ制御が必要である等）。（例えば、窓のない廊下、又は、オフィスタイムに常に誰かがいる建物のエリアで使用される）常にオンしているライトも良い候補である。一般的には、オフからオンへの切り替えがそれほどないライトは、レイテンシが懸念される場合良い候補である。

照明コマンド送信アクティビティ
照明コマンド送信アクティビティを評価することにより、照明制御コマンドを送信するのに現在それほどアクティブではないランプを、ＲＦベースのセンシングに関連するリスニング、処理、及び保存に対処するのによりアクティブであるように割り当てることが可能である。非常にインタラクティブなランプ、例えば、（アクティブな）エンターテイメントグループのライトは、システム内のどこかに割り当てられることができるＲＦベースのセンシングのための基本的な作業を行うために割り当てられるべきではない。例えば、（オーディオ及び／又はビデオコンテンツに合わせて光をレンダリングする）エンターテイメントグループのライトは、ＲＦセンシングのために良好である、多くのトラフィックを生成（又は受信）するが、ユーザに完璧な照明体験を提供することに主に集中すべきである。一つのオプションは、ＲＦベースのセンシングを行うためにエンターテイメントグループの一部であるライトを割り当てるが、データストレージ及びＣＰＵ負荷の高いデータ分析処理をエンターテイメントグループの一部ではないライトによって行わせることである。例えば、エンターテインメントライトコマンドを送信するデバイスは、複数のＲＦベースのセンシンググループにおける送信デバイスであってもよい。これらのグループの他のデバイスは、例えば、エンターテイメントグループの内部又は外部のライトであってもよい。

現在利用可能なスペアネットワークデータレート(currently available spare network data-rate)
現在利用可能なスペアネットワークデータレートを評価することにより、十分な現在利用可能なスペアネットワークデータレートを持つデバイスを選択することが可能になる。例えば、コントローラ／ブリッジ内のＺｉｇｂｅｅ無線機が、キッチンのランプのＯＴＡＵファームウェアアップグレードを現在実行していることがある。家の中の他のライトとの通常の照明制御トラフィックと相まって、コントローラ／ブリッジ内の無線機は現在、多くのワイヤレストラフィックを処理している。したがって、コントローラ／ブリッジ内のＺｉｇｂｅｅ無線機は、すでに容量一杯である可能性があり、（キッチンライトのファームウェアアップデートが終わるまで）リビングルームのワイヤレスライトとＲＦセンシンググループを形成するのに、今は良い候補ではない可能性がある。１つのオプションは、ＲＦベースのセンシングに参加するようにコントローラ／ブリッジを割り当てるが、データストレージ及びＣＰＵ負荷の高いデータ分析処理を、ＯＴＡＵアップグレードの一部ではなく、したがって十分な空きコンピューティング能力及びメモリを持つライトによって行わせることである。

占有検出ターゲットエリアに対するＲＦ特性、例えば、ビーム形状
占有検出ターゲットエリアに対するＲＦ特性、例えば、ビーム形状を評価することにより、現在の物理的な位置が占有検出ターゲットエリアに対する適切なＲＦ特性、例えば、ビーム形状をもたらす照明器具を選択することが可能である。例えば、（Ｈｕｅ Ｇｏと同様の）キューブ形状のバッテリ式照明器具は６つの異なる面を持ち、ユーザが、キューブの向きを選択することを可能にし得る。無線チップ、例えば、ＷｉＦｉ無線チップ又は６０ＧＨｚミリ波無線チップを含む面が、その時点でターゲット検出エリアに向けられている場合、キューブ照明器具は、ＲＦベースのセンシングによく適したものとなる。無線機が床に面している場合、照明器具は、ＲＦベースのセンシングを行うにはよく適していない。

ある向きに位置付けられる照明器具の適合性は、その周囲にある他の材料にも依存する可能性がある。例えば、金属製テーブルの上にある場合、キューブが下方に向けられることは、ＲＦベースのセンシングの悪い結果をもたらすが、テーブルが薄い木でできている場合は、ＲＦベースのセンシングは、満足に行われることができる。無線チップが電球に組み込まれ、この電球が金属照明器具に配置される場合、これは、無線チップ自体、例えば、Ｚｉｇｂｅｅ無線チップのＲＦ性能が均一であっても、指向性のあるＲＦ性能となり得る。

ここ数ページで、コミッショニング時に使用するための第１の基準のセットが述べられ、コミッショニング後に使用するための第２の基準のセットが述べられている。一部の基準は両方のセットに存在する。一部の他の基準は、これらセットのうちの１つにしか存在しないが、コミッショニング中及びコミッショニング後の両方で使用可能な場合もある。ＲＦベースのセンシング（動き検出、真の存在検出(true presence detection)、又は体の姿勢若しくはジェスチャを検出することができるきめ細かなセンシング(fine-grained sensing)）に関連して述べられた基準は、ＲＦベースのアセットトラッキング（位置特定）にも使用できる可能性がある。

上記の選択基準は、図６の実施形態においてＲＦベースのセンシングを行うために特定のランプを避けるために使用されているが、上述のＲＦベースのセンシングのマイナスのシステム影響(negative system impact)を軽減するためにＲＦベースのセンシングを故意にスロットル(throttle)することも可能である。極端なケースでは、ＲＦベースのセンシングは、Ｚｉｇｂｅｅネットワーク内で送信される非センシング関連メッセージだけが使用される程度までスロットルされることができる。

ワイヤレス（例えば、メッシュ）ネットワーク内のメッセージルーティングを制御する方法の第３の実施形態が、図８に示される。図３に関連して述べたように、この方法の目的は、どのノードに、ネットワークルーティングを実行するように、すなわち、それらが受信するメッセージを転送するように指示するかを決定することである。これらの指示の結果、ネットワークルーティングが調整され、ＲＦベースのセンシング及び／又はアセットトラッキングの実行のためにワイヤレススペクトルが局所的に解放されることになり、これについては図１のブリッジ１に関連してより詳細に述べられている。

前述のように、ステップ１１１は、複数のノードの第１のサブセットを決定することを含み、この第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む。この第１のサブセットは、手動又は自動で選択されてもよい。

第１のサブセットは、すべてのノードから選択されてもよく、又は、例えば、図２及び図４に関連して述べたように、ＲＦベースの存在検出及び／又は位置特定に適していると判断されるノードから選択されてもよい。第１のサブセットのうちの１つ以上のノードが、ＲＦベースの位置特定（ＲＦベースのアセットトラッキング）を実行する必要がある場合、１つのノードを選択することで十分であり得る。第１のサブセットの１つ以上のノードが、（ＲＦベースのアセットトラッキングを行うよりも困難であり、検出されるべき物体、人、又は動物がＲＦ送信機及び／又は受信機を担持しない）ＲＦベースの存在検出（ＲＦベースのセンシング）を実行する必要がある場合、典型的には、少なくとも２つのノードの少なくとも１つのグループが必要とされ、これらのノードは、典型的には、１つ以上のターゲットセンシングエリアに基づいて選択される。

次に、ステップ１７２において、複数のノードの第２のサブセットが、第１のサブセットの１つ以上のノードの位置に基づいて選択される。第１のサブセットの１つ以上のノードは、無線周波数ベースの存在及び／又は位置検出機能のための１つ以上の無線周波数信号を送信及び／又は受信するが、第２のサブセットの１つ以上のノードはそうしない。代わりに、第２のサブセットの１つ以上のノードは、他のノードを対象とした、一部のネットワークメッセージ又はいかなるネットワークメッセージ（例えば、照明制御コマンド）を再送信しないことによって、ＲＦベースの存在及び／又は位置検出に引き起こされる干渉を制限することを試みる（この実施形態では、センシング及び／又はアセットトラッキングＲＦ信号は、インバンドで送信される）。第２のサブセットの１つ以上のノードは、ＲＦベースの存在及び／又は位置検出のためのＲＦ信号を受信するかもしれないが、それらのＲＳＳＩを記録する必要はない。第２のサブセットのノードは、それが適切な位置にない又は他のノードで既に可能なこと以上の追加情報を追加しないことに起因して、第１のサブセットではなく第２のサブセットに含まれてもよい。次に、ステップ１７３は、複数のノードの残りのノード（すなわち、第１のサブセット又は第２のサブセットの一部として選択されていないノード）から成るノードの第３のサブセットを作ることを含む。第２のサブセットの１つ以上のノードとは異なり、第３のサブセットの１つ以上のノードは、他のノードを対象としたすべてのネットワークメッセージを再送信する、すなわち、通常のルーティング機能を実行する。

図３に関連して上述したように、ステップ１１３は、ソースノードからデスティネーションノードへの複数のルートを決定することを含む。図３のステップ１１５は、サブステップ１７５を含む。ステップ１７５は、複数のルートの各々の中間ノードのうちのいくつが複数のノードの第１のサブセット又は第２のサブセットの一部であるかに基づいて複数のルートのうちの１つを選択することを含む。ステップ１１７は、ワイヤレス（例えば、メッシュ）ネットワークに選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信することを含む。これは、図１のブリッジ１に関連してより詳細に述べられている。

ステップ１１７において、これらの１つ以上のメッセージは、通常、ＲＦベースの存在検出及び／又は位置特定を行うのに使用されるプロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ）とは異なるプロトコル（例えば、Ｚｉｇｂｅｅ）を使用して送信される。図８の実施形態では、第１のサブセットの１つ以上のノード及び第２のサブセットの１つ以上のノードは、（例えば、照明制御コマンド又は通常のネットワーク「ハウスキーピング」メッセージのための）メッセージルーティングを行わないように、又はそれらが行うメッセージルーティングを制限するように指示される。さらに、第１のサブセットの１つ以上のノードは、ＲＦベースの存在及び／又は位置検出を行うように指示される。第２のサブセットのノードは、第１のサブセットのノードにできるだけ干渉しないように指示される。第３のサブセットのノードは、ネットワークルーティングを行う、すなわち、他のノードを対象とした、それらが受信するメッセージを転送するように指示される。

これらの指示の結果、ネットワークルーティングが調整され、ＲＦベースのセンシング及び／又はアセットトラッキングの実行のためにワイヤレススペクトルが局所的に解放される。第１のサブセットの１つ以上のノード及び第２のサブセットの１つ以上のノードは、（本明細書において後にモード２とも呼ばれる）機能性が低下した（例えば、Ｚｉｇｂｅｅ）ルータノードとして動作するように指示されてもよく、これは、ノードが自身に直接宛てられたメッセージのためにＺｉｇｂｅｅメッシュネットワーク上でリッスンするが、ノードは他のＺｉｇｂｅｅノードからのメッセージを転送しないことを意味する。

代替的に、第１のサブセットの１つ以上のノード及び第２のサブセットの１つ以上のノードは、（本明細書において後にモード３とも呼ばれる）（例えば、Ｚｉｇｂｅｅ）エンドノードとして動作するように指示されてもよく、これらのノードは、メッシュネットワークに全く参加せず、ある期間（例えば、０．５秒以上）ごとに、それらの親ノードによって受信され一時的に保存されるこのノード宛てのメッセージをチェックするだけである。代替的に、例えば、第１のサブセットの１つ以上のノードは、機能性が低下したルータノードとして動作するように指示され、第２のサブセットの１つ以上のノードは、エンドノードとして動作するように指示されてもよく、又はその逆であってもよい。第３のサブセットのノードは、（本明細書において後にモード１とも呼ばれる）本格的な(full-fledged)（例えば、Ｚｉｇｂｅｅ）メッシングノードとして動作し、それによってロバストな建物レベルの（例えば、メッシュ）ネットワークのためのバックボーンを提供する。

図８の実施形態又は代替的な実施形態では、ＲＦベースのセンシングのためのＲＦ信号を送信する必要がある第１のサブセットの１つ以上のノードは、ある期間の間に間断なくＲＦ信号を送信する、例えば、他のノードによって到達可能であることを気にすることなくＲＦ信号をフルブラストで送信するように指示されてもよく、ＲＦベースのセンシングのためのＲＦ信号を受信する必要がある第１のサブセットのノードは、このある期間の間に間断なくＲＦ信号を受信するように指示されてもよい。これは、「高空間解像度(high-spatial-resolution)」センシングモードと呼ばれる。第１のサブセットのこれらのノードが照明デバイスである場合、このモードは、ある期間の間選択されてもよく、又は、ある期間自体が、ライトデバイスがこのある期間の間に光出力状態が変わらないことが予想されるという予想(expectation)に依存して選択されてもよい。

ステップ１１１、１７２、１７３、１１３、１１５及び１１７がコミッショニング中に実行された後、システムの通常の動作が開始されてもよく、すなわち、ＲＦベースの存在及び／又は位置検出が、ステップ１１７で指示されたデバイスによってステップ１７６で実行されてもよい。ステップ１７７において、一定の時間が経過した及び／又は別の基準が満たされ、第１及び第２のサブセットが再選択される必要があるかどうかがチェックされる。そうでない場合は、ＲＦベースの存在及び／又は位置検出はステップ１７６で継続されてもよい。そうである場合、ステップ１１１が再び実行され、第１のサブセットの１つ以上のノード及び第２のサブセットの１つ以上のノードの新たな選択が実行されてもよい。

第１及び第２のサブセットは、ＲＦベースのセンシング（存在検出）に使用されるターゲットセンシングエリアが変わる場合に再選択される必要があってもよい。ステップ１７７は、ユーザアクティビティが変化した又は変化することが予想され、したがって存在が異なるターゲットセンシングエリアで検出される必要があるかどうかを検出することを含んでもよい。例えば、ターゲットの人が家の中の第１のエリアから第２のエリアに移動する場合、ネットワーク内のルーティングが動的に調整されてもよい。斯くして、当該人は、高強度のＲＦベースのセンシング「ハロー」(high-intensity-RF-based-sensing "halo")を伴って新しいエリアに移動する。言い換えれば、（例えば、照明）システムは、第２のエリアのＲＦベースのセンシングのためのワイヤレススペクトラムを解放する(free up)ためにルーティングを調整し、一方、第１のエリアの照明制御のための追加のスペクトラムを「リリース(release)」する。さらに、ワイヤレス信号は第１のエリアと第２のエリアの間を伝搬する可能性があるため、このアプローチは、第１のエリアと第２のエリアとが不必要に互いに干渉しないことを保証する。

ここで、図１のデバイス間で決定されるルートの２つの例が、図８の方法を説明する助けとなるように提供される。第１の例として、リビングルーム３２のテーブルランプ１５及びフロアスタンディングランプ１４が、コンテキストアウェアネスの目的で占有者の数をカウントするために高解像度のＲＦベースのセンシングスキャン(high-resolution RF-based sensing scan)を実行している。同時に、ＬＥＤストリップ１２は、（エントランスエリア３４に位置する）ブリッジ１とメディアルーム３３との間でかなりの（例えば、Ｚｉｇｂｅｅ）トラフィックを必要とする動的エンターテイメント効果を実行するためにメディアルーム３３で使用されている。エントランスエリア３４のＨｕｅブリッジ１とメディアルーム３３との間の距離は、（例えば、Ｚｉｇｂｅｅ）通信が２つの部屋の間で少なくとも１つのネットワークホップを必要とするようなものである。

テーブルランプ１５及びフロアスタンディングランプ１４が、ブリッジ１からＬＥＤストリップ１２へのエンターテイメントメッセージの転送に参加しないようにネットワーク内のルーティングを調整することにより、テーブルランプ１５及びフロアスタンディングランプ１４は、それらの処理リソース及び／又はメッセージ送信及び／又はワイヤレスコマンドのリスニング（Ｚｉｇｂｅｅデバイスは、典型的には、同時にトーク及びリッスンすることはできない）を、高解像度のＲＦベースのセンシングを実行するのに集中させることができる。テーブルランプ１５及びフロアスタンディングランプ１４は、例えば、機能性が低下したＺｉｇｂｅｅルータノード又はＺｉｇｂｅｅエンドノードになり得る。また、ＲＦベースのセンシング目的で優先的にリッスンするように割り当てられるノードのみがＺｉｇｂｅｅエンドノードとなるように割り当てられ、このノードがＺｉｇｂｅｅ親デバイスによってコンタクトされる場合にのみＲＳＳＩ統計をレポートすることも可能である。

他方、子供のベッドルーム３５のシーリングランプ１３がステップアップ(step up)し、メディアルーム３３へのエンターテイメントトラフィックのためのルーティングを提供する。さらに、通常は（例えば、Ｚｉｇｂｅｅ）エンドデバイスとして動作する、バッテリ式のＨｕｅ ｇｏ照明器具１１さえも、高解像度のＲＦベースのセンシングスキャンが実行されるリビングルーム３２からトラフィックを遠ざけるために（消費エネルギが増加するにも関わらず）ルーティングノードとして利用され得る。ブリッジ１とＬＥＤストリップ１２との間には、Ｈｕｅ ｇｏ照明器具１１及びシーリングランプ１３を経由するルートと、フロアスタンディングランプ１４を経由するルートとの２つの論理的ルートがある。フロアスタンディングランプ１４が高解像度のＲＦベースのセンシングスキャンに関与しているので、（典型的なルーティングアルゴリズムは、関与するホップが少ないためフロアスタンディングランプ１４を経由するルートを選択するかもしれないが）Ｈｕｅ ｇｏ照明器具１１及びシーリングランプ１３を経由するルートが選択される。

第２の例として、テーブルランプ１５及びＬＥＤストリップ１２が、メディアルーム３３で高解像度ＲＦベースのセンシングスキャンを行っており、ブリッジ１からＬＥＤストリップ１２へのネットワークルートが決定される必要がある。ブリッジ１とＬＥＤストリップ１２との間には９つのルート、すなわち、１－１４－１２、１－１４－１３－１２、１－１４－１５－１２、１－１１－１３－１２、１－１１－１３－１４－１２、１－１１－１３－１４－１５－１２、１－１１－１４－１２、１－１１－１４－１３－１２、１－１１－１４－１５－１２がある。照明デバイス１５が、ＲＦベースのセンシング機能を割り当てられているため、ノードの第１のサブセットに含まれる。高解像度ＲＦベースのセンシングスキャンへの干渉を防ぐために、フロアスタンディングランプ１４は、ネットワークメッセージルーティングを行わないことが好ましく、したがってノードの第２のサブセットに含まれる。テーブルランプ１５が第１のサブセットに含まれ、フロアスタンディングランプ１４が第２のサブセットに含まれるので、Ｈｕｅ ｇｏ照明器具１１及びシーリングランプ１３を経由するルート（１－１１－１３－１２）が選択される。

上記の例では、第１のサブセットの決定は、ノードがＲＦベースのセンシングエリア機能を割り当てられるかどうかのみを考慮している。第１のサブセットを決定する際に、現在必要とされているＲＦベースのセンシングスキャンの解像度（例えば、メジャーな動き検出(major motion detection)、マイナーな動き検出(minor motion detection)、真の存在検出、人カウント等）をさらに考慮することにより、選択されるルートは、現在の要件(requirement)にさらによく適合されることができる。高帯域幅のＲＦベースのセンシングが、マイナーな動きの検出に必要とされる。これにより、センシングアルゴリズムは、以前の閾値／ベースラインに対するワイヤレス通信パラメータの変動が、ワイヤレスチャネルノイズに起因するのか、又は、人がほとんど動かずにラップトップをタイピングしていることに起因するのかを信頼性(confidence)を持って判断することができる。

きめ細かなＲＦベースのセンシング(fine grained RF-based sensing)は、存在を検出するだけでなく、存在する人の数（又は、１人、数人、大勢といった相対的な人の量）を区別することもできる。きめ細かなＲＦベースのセンシングでは、毎秒送られるメッセージの量と、空間が占有されているかどうか又はそこに何人の人がいるかを信頼性を持って判断するためのレイテンシとの間にトレードオフがある。したがって、判断を行うのに必要なレイテンシと必要な信頼性との組み合わせに基づいてメッセージ量を調整することが有益である（例えば、家の所有者に警告することを含む侵入者のセキュリティクラスの検出では、信頼度(confidence level)は、ライトをオンにする場合よりもはるかに高い必要がある（後者の場合、フォールスポジティブがあっても、ライトを再度オフにすることにより容易に是正され得るので、害はない）。

真の存在検出(true presence detection)は、ＲＦベースの基本動きセンシング(RF-based basic motion sensing)のさらにきめ細かなバージョンであり、解像度が、椅子に座っている又はソファに伸びている人でも、以前に知られた誰もいない部屋の状況と比較して通信パラメータの変化を分析することによりピックアップされることができるように高められる。したがって、必要とされるセンシング解像度が高いほど、ＲＦベースのセンシングに関連するライト間の通信のデータレートが高くなり、ターゲット占有者検出エリアを囲むネットワークへの負担が大きくなる。

ＲＦベースのセンシングは、人カウントにも使用されることができる。エリア内の１０人を区別できるようにすることは、エリア毎に最大３人をカウントするよりも、より高解像度のＲＦベースのセンシングを必要とする。「多占有者カウント(counting-many-occupants)」モードが、１０～２０～３０人を区別するために最適化されてもよく、一方、「通常モード(normal-mode)」において、ＲＦベースのセンシングは、室内の１～２～３人を高い精度で区別するようにしてもよい。

前述の「高空間解像度」センシングスキャンは、人が部屋Ａにいるのか、部屋Ｂにいるのかを高い信頼性で判断するために使用されてもよい。「高空間解像度」センシングモードはまた、人の軌跡をトラッキングするために使用されてもよい。高空間解像度又は多占有者(many-occupants)のＲＦセンシングスキャンを実行している間、ライトのグループは、それらの帯域幅の１００％がＲＦベースのセンシングデータの獲得に専念される、特別な「センシングブーストモード(sensing-boost mode)」に入ってもよい。これは、ライトが一時的にＺｉｇｂｅｅネットワーク内の他のライトによって到達可能ではない、又はレイテンシがより長くなることを伴ってもよい。ネットワークルーティングは、この「高空間解像度」センシングスキャン、又は人カウント等のためのその他の高解像度スキャンを促進するために一時的に調整されてもよい。

好ましくは、前項で述べたセンシングブーストモードは、オンされている及び／又は安定モード(stable mode)にあるライトによって実行される。安定モードは、ライトが、当面の間変化のない光出力状態のままであることが予想されることを意味する。例えば、バッテリ式のセンサが最近動きを検出した場合、ライトは安定モードにある。これは、ライトが少なくともあと５分は（当該期間に動きが検出されるかどうかに関わらず）オンのままであり、４分のブーストモードの持続時間が、照明制御の観点から許容可能であろうことを意味する。

ライトが（例えば、占有されていない家で）現在オフされいてる場合、ライトは、安全上の理由から、例えば家のエントランスエリアにおいて、高解像度センシングモードの持続時間の間オンにされてもよい。オフィスにおいて、ＲＦベースのセンシングは、１５分ごとにオフィスの異常がスキャンされる、夜間のソフトセキュリティのために使用されてもよい。実際には従業員が泊りがけでオフィス内で仮眠をとっていたが、システムは、オフィスに誰もいないと誤認して、あり得る侵入者について高解像度のスキャンを開始する可能性がある。従業員が起床すると、照明システムは０．５秒以内に壁スイッチに応答しなければならない、又は代替的に、レイテンシの影響がある(latency-impacting)高解像度のセンシングスキャンが実行される間、ライトは（恐らくは安全性を確保するために低調光レベルで）オンされる必要がある。

オプションとして、システムは、（ターゲットセンシングエリアとも呼ばれる）ＲＦベースのセンシングハローが、家のあるエリアから別のエリアに移動しているユーザに追従するかどうか及びどのように（例えば、どのような遅延で）追従するかを決定するためにホームオートメーションシステム内の他のセンシングモダリティ（例えば、電子ロック、ＰＩＲセンサ、Ａｐｐｌｅ ＴＶ）を活用する。例えば、テレビを見ている人がＮｅｔｆｌｉｘを一時停止しており、トイレに行きそうであるというコンテキストを仮定すると、ＲＦベースのハローはテレビルーム内に留まり、ユーザに追従しない。しかしながら、人がキッチンに行き、スナックを用意するために冷蔵庫を３０秒以上開ける場合、ＲＦベースのセンシングハローは、キッチンへ当該人を追従する。この場合、ＲＦベースのセンシング機能のデバイスへの割り当てが再度行われてもよく、ネットワークルートが再度決定されてもよい。冷蔵庫自体が、例えば、冷蔵庫が３０秒以上開けられたことを検出できるようにしてもよい。代替的に、別のタイプの存在センシングが、当該人又は一般に人がより長い時間キッチンにいることを検出するために使用されてもよく、それによってＲＦベースのセンシングハローがキッチンに移動するようにしてもよい。

ＲＦベースのセンシングは、人を検出するためだけでなく、物体を検出ために使用されてもよい。例えば、ＲＦベースのセンシングは、冷蔵庫及びドアの開きを検出するために使用されてもよい。このコンテキスト情報は、例えば、高齢者介護に役立ち得る。これは、新たに発生する健康状態を示す可能性のあるパターンの変化を検出するために使用され得る重要なデータポイントの収集に役立つ。

Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）メッシュベースの（例えば、照明）ネットワークでは、（１）通常は照明ネットワークの一部ではないＢＬＥを備えた電子デバイスと（２）ＢＬＥライト（又はＺｉｇｂｅｅ／ＢＬＥライトを組み合わせたライト）との間のインタラクション(interaction)に基づいてＲＦベースのセンシングを行うことが可能であり得る。

Ｚｉｇｂｅｅメッシュベースの（例えば、照明）ネットワークでは、Ｚｉｇｂｅｅ／ＢＬＥを組み合わせたライトとＢＬＥ電子デバイスとの間のＲＦベースのセンシングインタラクションは、帯域外(out-of-band)通信（Ｚｉｇｂｅｅの代わりにＢＬＥ）によって行われてもよい。この場合、ＺｉｇｂｅｅスペクトラムとＢＬＥスペクトラムとの間にいくらかのオーバーラップがあっても、ＢＬＥの周波数ホッピングスペクトラム拡散送信(frequency-hopping spread spectrum transmission)がＺｉｇｂｅｅの直接スペクトラム拡散送信(direct-sequence spread spectrum transmission)に干渉しないため、照明制御に使用されるＺｉｇｂｅｅスペクトル（チャネル）は、ＲＦベースのセンシングスキャンによって影響を受けない。しかしながら、（Ｚｉｇｂｅｅ）ネットワークトラフィックは、（ＢＬＥ）ＲＦベースのセンシングスキャンに干渉しないが、ＲＦベースのセンシングスキャンを行うノードは、（ＢＬＥ）ＲＦベースのセンシングスキャンを行うために時間が必要であり、ノードがＢＬＥとＺｉｇｂｅｅネットワークとの間でタイムシェアリングを実行する単一の無線機を備える場合、この時間の間（Ｚｉｇｂｅｅ）ネットワークメッセージを受信するために利用できない可能性がある。

非照明デバイス（例えば、テレビ）によって引き起こされるワイヤレス干渉は、ＲＦベースのセンシングを行うランプの能力に影響を与える。家の第１のノイジーなエリアで信頼性の高い存在検出を行うためには、ＲＦベースのセンシングのデータレートが、通常、ワイヤレス干渉の少ない家の第２のより静かなエリアと比較して増加されるべきである。それゆえ、第１の占有検出ターゲットエリアのランプは、より多くのエアタイムをＲＦベースのセンシングに割り当て、ネットワークルーティングを行う時間（又はＣＰＵ及びメモリ等のリソース）が少なくなるか、又はゼロになる。したがって、好ましくは、ネットワークルーティングは、建物の他の部分のライトをステップアップさせ、照明メッシュネットワーキングキャノピー(lighting mesh networking canopy)により貢献するように、すなわち、どこでもカバレッジの適切なメッシュネットワークバックボーンがあることを保証する助けとなるように調整されるべきである。

本発明のネットワークメッセージを取得する方法の第２の実施形態が図９に示されている。この実施形態では、電子デバイスは、時間の第１の部分をＲＦベースのセンシングに使用し、時間の第２の部分をネットワークメッセージ、例えば、照明コマンドの送信及び受信に使用する。電子デバイスは、以下の３つのモードのいずれかで動作する。
モード１）通常のＺｉｇｂｅｅルータ（通常のメッシュモード）、ＲＦベースの存在及び／又は位置検出：なし。
モード２）機能性が低下したＺｉｇｂｅｅルータ(Zigbee router with reduced functionality)、ＲＦベースの存在及び／又は位置検出：あり。
モード３）ＺｉｇＢｅｅエンドデバイス、ＲＦベースの存在及び／又は位置検出：あり。

代替的な実施形態では、これらのモードのサブセットのみ、例えば、モード１＋２若しくはモード１＋３が使用されてもよく、及び／又は、追加のモードが使用されてもよい。このような追加モードの例は、電子デバイスが通常のＺｉｇｂｅｅルータとして動作し（通常のメッシュモード）、ＲＦベースの存在及び／又は位置検出も行うモードである。Ｂｌｕｅｔｏｏｔｈ、例えば、ＢＬＥがＲＦベースの存在及び／又は位置検出に使用される場合、これは、電子デバイスがＲＦベースの存在及び／又は位置検出を実行している間にＺｉｇｂｅｅメッセージを受信しないため、効率の低下をもたらす。

最初のステップとして、ステップ１８０が実行される。ステップ１８０は、方法を実行する電子デバイスがモード１、２又は３に設定されているかどうかを判断することを含む。図９の実施形態では、図１のブリッジ１は、電子デバイスがどのモードを使用すべきかを該電子デバイスに指示する。代替的な実施形態では、電子デバイスは、どのモードを使用するかを、例えば、自動的に、又はそのネイバー(neighbor)を伴う何らかの決定アルゴリズムを使用して、又は自身のメモリに格納されるコンフィギュレーション設定に基づいて、自身で決定する。電子デバイスがモード２又は３に設定されている場合、ステップ１８１が実行される。電子デバイスがモード１に設定されている場合、ステップ１８５が実行される。

ステップ１８１は、第１の周波数チャネルのセットを選択することを含む。第１の周波数チャネルのセットは、例えば直接スペクトラム拡散の場合、単一のチャネルを含んでもよく、又は、例えば周波数ホッピングの場合、複数のチャネルを含んでもよい。図９の実施形態では、第１のプロトコル、例えば、Ｂｌｕｅｔｏｏｔｈが、複数の期間の各々の第１の部分の間にステップ１４１においてこの第１の周波数チャネルのセットで無線周波数信号を送信及び／又は受信するために使用される。ステップ１８３は、方法を実行する電子デバイスがモード２又は３に設定されているかどうかを判断することを含む。図５のステップ１４３は、２つのサブステップ、すなわち、ステップ１８５及び１８７を含む。電子デバイスがモード２に設定されている場合、ステップ１８５が実行される。電子デバイスがモード３に設定されている場合、ステップ１８７が実行される。

ステップ１８５は、第２の周波数チャネルのセットで、第２のプロトコル、例えば、Ｚｉｇｂｅｅを使用してワイヤレスに、ネットワークメッセージ、例えば、照明制御メッセージを受信することを含む。これは、複数の期間の各々の第２の部分の間に起こる。第２の周波数チャネルのセットは、例えば直接スペクトラム拡散の場合、単一のチャネルを含んでもよく、又は、例えば周波数ホッピングの場合、複数のチャネルを含んでもよい。電子デバイスがモード１に設定されている場合、電子デバイスは、ＲＦベースの存在及び／又は位置検出のためのＲＦ信号を送信又は受信する必要がないため、ネットワークメッセージ（例えば、照明制御メッセージ）をその間中(entire time)送信及び受信することができる。

この場合、電子デバイスが（ＲＦベースの存在又は位置検出がこのデバイスによって行われないことを意味する）モード１に設定されたままである場合、ＲＦ信号、例えば、Ｂｌｕｅｔｏｏｔｈ信号がＲＦベースの存在及び位置検出のために送信及び／又は受信される第１の部分の継続時間は０秒である。電子デバイスがモード１からモード２又は３に切り替わる場合、第１の部分の持続時間は増やされ、第２の部分の持続時間は減らされる。（図９には示されていない）代替的な実施形態では、電子デバイスは、モード１（すなわち、通常の（Ｚｉｇｂｅｅ）メッシュモード（該デバイスはまた、受信したメッセージを転送する））である場合、短い時間間隔でのみ、ＲＦベースの存在及び位置検出のためのＲＦ信号、例えば、Ｂｌｕｅｔｏｏｔｈ信号を送信及び／又は受信する。

図９の実施形態では、電子デバイスがモード３に設定されている場合に実行される、ステップ１８７は、第２のプロトコルを使用してワイヤレスで送信されるネットワークメッセージを、ネットワークメッセージを代理で受信した他のデバイス（電子デバイスの親ノード）から取得することを含む。電子デバイスの親ノードから取得されるネットワークメッセージは、常に該電子デバイス自身を対象としている。ステップ１９５が、ステップ１８７の後に実行される。

ステップ１８５の後、ステップ１８９において、ステップ１８５で受信したメッセージが電子デバイス自身に宛てられているか、又は他のノードに宛てられているかがチェックされる。メッセージが電子デバイス自身に宛てられている場合、ステップ１９５が実行される。メッセージが他のノードに宛てられている場合、ステップ１９１が実行される。ステップ１９１は、電子デバイスがモード１又は２に設定されているかどうかをチェックすることを含む。モード１において、受信したメッセージはステップ１９３において転送される。モード２において、受信したメッセージは転送されず、次にステップ１８１が実行される。代替的な実施形態では、他のノードを意図した受信メッセージは、選択的に転送される、すなわち、決して転送されないのではなく、常に転送されないが、時として転送される。

ステップ１９５は、ステップ１８５又は１８７で取得したメッセージがモードコンフィグメッセージ(mode config message)であるかどうかを判断することを含む。そうである場合、電子デバイスは、ステップ１９７において、このモードコンフィグメッセージで指示されるモードに設定される。そうでない場合、取得されたメッセージはステップ１９８において通常通り処理され、ステップ１９８の後にステップ１８１が実行される。ステップ１９７の後、ステップ１９９において、新しいモードがモード１であるかどうかがチェックされる。そうである場合、次にステップ１８５が実行され、それによりステップ１８１、１４１及び１８３はスキップされる。そうでない場合、次にステップ１８１が実行される。

ステップ１８１の次の反復において、任意選択的に、ステップ１８１の前の反復とは異なる周波数チャネルのセット、例えば、第３の周波数チャネルのセットが選択されてもよい。そうである場合、第１のプロトコルが、ステップ１４１の次の反復において、この異なる、例えば、第３の周波数チャネルのセットでＲＦ信号を送信及び／又は受信するために使用される。ＲＦ信号がＲＦベースのセンシングに使用される場合、このＲＦ信号は、好ましくは、ある空間エリア内で一意である。好ましくは、ＲＦベースのセンシング専用の（例えば、Ｚｉｇｂｅｅの）帯域は、ローカルに一意であり、家又は建物のフロア内でＲＦベースのセンシングを行うデバイス、例えば、ランプの各グループごとに異なる。したがって、ＲＦベースのセンシングを行うデバイス（例えば、ランプ）の各グループは、（例えば、照明）制御ネットワーク又はＲＦベースのセンシングを行うデバイス（例えば、ランプ）の他のグループのニーズを考慮する必要なく、（例えば、Ｚｉｇｂｅｅ）メッセージストームを送信することができる。これは、最適なセンシング性能をもたらす。

複数の機能を有するＲＦ送信機及び／又は受信機、例えば、デュアル無線トランシーバが使用されてもよく、１つの機能、例えば、ＢＬＥ無線機能がステップ１４１を実行するために使用され、別の機能、例えば、Ｚｉｇｂｅｅ無線機能がステップ１４３を実行するために使用されてもよい。代替的に、複数の送信機及び／又は受信機が、それぞれステップ１４１及び１４３を実行するために使用されてもよい。

一例として、図９の方法は、家の照明システムにおいてＲＦベースのセンシングを行うために使用されてもよい。この例では、専用のＺｉｇｂｅｅチャネルがＲＦベースのセンシングに使用され、異なるＺｉｇｂｅｅチャネルが照明制御（ネットワークメッセージ）に使用される。ＲＦベースのセンシングのタスクを現在割り当てられているライトは、ほとんどの時間、ローカルに一意の、専用のワイヤレスチャネルを利用するＺｉｇｂｅｅＲＦベースのセンシングモードにおいてフルブラストで動作する（すなわち、家レベルのＺｉｇｂｅｅ照明ネットワークとの干渉はない）。ごく一部の時間、ＲＦベースのセンシングを行うライトは、Ｚｉｇｂｅｅ照明ネットワークに参加する。

照明ネットワーク内では、一般的に、このようなＲＦベースのセンシングを行うライトは、（モード３で動作する）スリーピーな(sleepy)Ｚｉｇｂｅｅエンドデバイス、又は（モード２で動作する）機能性が低下したＺｉｇｂｅｅルータとして動作してもよい。ライトがＺｉｇｂｅｅエンドデバイスとして動作する場合、ライトは、時折のみ（例えば、０．５秒以上ごとに）、自身の親ノードから、家レベルのＺｉｇｂｅｅネットワークから代理で受信された照明制御メッセージを取得する。ライトは、ＲＦベースのセンシングスキャンに入ると、（モード１で動作する）通常のメッシュノードから（モード３で動作する）エンドノードへと遷移し、それに応じてライトはＺｉｇｂｅｅ親ノードを決定してもよい。

代替的に、ライトは、ＲＦベースのセンシングスキャンに入ると、（モード１で動作する）通常のメッシュノードから（モード２で動作する）機能性が低下したＺｉｇｂｅｅルータに遷移してもよい。この場合、ライトは、メッシュからメッセージを受信するためにＺｉｇｂｅｅネットワーク上で定期的に（ただし、コンスタントではない）到達可能になる。しかしながら、ライトは、メッシュネットワーク上の他のライトからのメッセージのルーティングには貢献していない。モード１で動作するライトは、ロバストな家レベルのメッシュネットワークのバックボーンを提供している。代替的な実施形態では、ライトは、ＲＦベースのセンシングスキャンを行う場合、Ｚｉｇｂｅｅネットワーク上で公式に（一時的に）到達不能になることができてもよく、ライトは、親デバイスのメールボックスを定期的にチェックすることなく、メッシュネットワークにレポートバックするだけでもよい。

上記の例では、Ｚｉｇｂｅｅチャネルが、ＲＦベースのセンシングを行うために使用されている。また、（１）ＢＬＥ（Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ）を備えた家電機器と、（２）優勢的にＢＬＥモードで動作するデュアル無線ライトとの間の帯域外インタラクションに基づいてＲＦベースのセンシングインタラクションを行うことも可能であり、この場合、ライトはＢＬＥを介して家電機器とインターフェースし、このようにしてＢＬＥベースのＲＦセンシングペアを形成する。

ＲＦベースのセンシングに少なくとも１つの家電機器を含めることが有利である。ほとんどの照明ノードは天井に取り付けられる。しかしながら、２つのシーリングライト間のＲＦベースのセンシングは、床に近い物体（例えば、小さな子供）の検出品質を制限する。家電機器（例えば、ＴＶ、音声アシスタント）は、照明デバイスよりも低い高さに位置する。したがって、ＲＦベースのセンサの１つとして家電機器（例えば、テレビ）を含めることが有利である。この場合、ＲＦベースのセンシングによって検出されるべき人間のバイオマスが、シーリングライト及び家電機器の間にあるからである。家電機器の代わりに、天井に取り付けられていないライトデバイスが含められてもよい。

家電機器(consumer electronics device)でＲＦベースのセンシングを行う場合、ライト及びＣＥデバイスは必ずしもネットワークを形成する必要はない。例えば、ライトは、各ＣＥデバイスによって送出されるＢＬＥ広告のＲＳＳＩを（スカベンジング(scavenging)アプローチを用いて）分析してもよい。また、ライトは、故意にメッセージを送出するためにＢＬＥデバイスをトリガしてもよい。例えば、ライトは、ＢＬＥ参加要求を送信し、これは、最終的には該ライトによって許可されないが、それにもかかわらず、ＲＳＳＩが埋め込まれているので、センシングに使用されることができるレスポンスをトリガする。

家のあるエリアで低解像度のＲＦベースのセンシングスキャンを行うライトは、照明システムによって使用される標準的なＺｉｇｂｅｅ照明制御バンドでこれを行ってもよく、一方、高解像度のスキャンを行うライトは、別の専用ワイヤレスバンドを使用してもよい。好ましくは、ライトの各々の周波数チャネル選択はまた、占有検出ターゲットエリアの各々に現在必要なＲＦベースのセンシング解像度、特にメジャーな動き検出、マイナーな動き検出、真の存在検出、人カウント、体の姿勢検出、ジェスチャ検出が必要かどうかを考慮する。

高帯域幅のＲＦベースのセンシングは、マイナーな動き検出若しくは人カウントに、又は人が部屋Ａにいるのか、部屋Ｂにいるのかを高い信頼性で判断するために使用される「高空間解像度」のセンシングモードに必要とされる。したがって、必要とされるセンシング解像度が高いほど、ＲＦベースのセンシングに関連するライト間の通信のデータレートが高くなる。さらに、ＲＦベースのセンシングメッセージを経時的に拡散させる（すなわち、時間軸上でこれらを均等に分散させる）ことで、長いブラインド期間(prolonged blind period)がないため、最高の占有検出となる。通常のＲＦベースのセンシングは、デバイスごとに毎秒３メッセージであってもよく、一方、高解像度スキャンは、毎秒１０メッセージ、さらには毎秒１００メッセージを採用してもよい。

非照明デバイス（例えば、テレビ）によって引き起こされるワイヤレス干渉は、ＲＦベースのセンシングを行うランプの能力に影響を与える。家のノイジーなエリアで信頼性の高い存在検出を行うことができるためには、ＲＦベースのセンシングのデータレートが家の第２のより静かなエリアと比較して増加される必要があるか、又は、ＲＦベースのセンシングのためのワイヤレスチャネルが変更される必要がある。

家の異なるエリアは異なるワイヤレス干渉源に曝されるため、エリアの各々についてＲＦベースのセンシングのための専用の比較的「静かな」ワイヤレスチャネルを選択するのが有利である。特定のエリアについて選択される帯域外ワイヤレスチャネルは、経時的に変化してもよい。例えば、ＲＦベースのセンシングセッションごとに、チャネルが新たに決定されてもよい。これは、１つのセンシングセッション中に行われてもよい。得られるセンシング結果が期待したほど正確でない場合、帯域外チャネルが変更されてもよい。しかしながら、新しいチャネルを選択することは、新しいチャネルのためのベースラインが決定される必要があるため、いくらかのレイテンシを招く可能性がある。

システムが、１つのチャネルに決定する前に（達成されるセンシングエリア品質の評価を含む）あるアエリアについての複数の帯域外チャネルの試行を意図的に行うことも可能である。例えば、試行は、チャネルの各々に対するＲＦベースのセンシングのフォールスポジティブ又はフォールスネガティブの数を分析することを含んでもよい。オプションとして、１つの帯域外のＲＦベースのセンシングスキャン(one single out-of-band RF-based sensing scan)は、サブスキャンを融合することにより占有検出の精度を高めるために、明確に異なるワイヤレスチャネル（例えば、最低周波数８０２．１５．４のバンドと最高周波数８０２．１５．４のバンド）を利用してもよい。また、ＷｉＦｉライトの場合、最新のＷｉＦｉ無線機で利用可能な複数の指向性アンテナを利用する、ワイヤレス送信の異なる方向性が採用されてもよい。

物理的な位置が簡単に変えられることができるライト（例えば、Ｐｈｉｌｉｐｓ Ｈｕｅ Ｇｏ）の場合、帯域外チャネルの選択は、（１）直前のＲＦベースのセンシングセッションの精度と、（２）ライトが最近移動又は回転されたかどうかについてある信頼性を与えるライトのオンボードセンサとの組み合わせに基づいてもよい。

さらに、２つの異なるＲＦベースのセンシングペアのライトペアは、同じ帯域外チャネルを利用することを選択できる。例えば、ライトは、（１）関与する照明器具の物理的特性（照明器具の配置高さ、照明器具の材料）及び（２）変更され得、ＲＦベースのセンシングに影響を与え得る、関与する照明器具のパラメータ（無線送信電力、照明器具の蓋の開閉、熱安定性等）を考慮して、２つのライトのペアによって生成されるそれぞれの動きシグネチャ(motion signature)が十分に異なるため、２つのＲＦベースのセンシンググループ間の干渉にもかかわらず、信頼性のある占有検出が実行されることができることを結論付けてもよい。これは、利用可能である適切な帯域外チャネルがほとんどないエリア（例えば、２．４ＧＨｚ帯の多くが混雑しているニューヨーク市のアパート等）に関連する可能性がある。

最後の数ページの説明は、ＲＦベースのセンシング（存在検出）アプリケーションを述べているが、述べられた原理の一部は、ＲＦベースのアセットトラッキング（位置検出）アプリケーションにも適用可能であり得る。次の数ページでは、ＲＦベースのアセットトラッキングアプリケーションでネットワークメッセージを取得する方法の第３の実施形態が述べられる。しかしながら、述べられた原理の一部は、ＲＦベースのセンシングアプリケーションにも適用可能であり得る。

さらに、一部の実施形態では、同じ照明システムが、（ビーコンを持たない物体についての）ＲＦベースの動き／存在検出、及び、ＢＬＥを備えたアセットのアセットトラッキングの両方を実行してもよい。一部の実施形態では、病院のクラッシュカート又はＢＬＥビーコンを備えたバッジを持つ従業員等の同じ物体が、ＲＦベースのセンシングシステム及びＢＬＥアセットトラッキングシステムの両方によって検出され、両方のセンシングモダリティが、クラッシュカートのムーブメント(crash cart movement)に対する位置精度及び応答時間を向上させるために照明システムによってマージされてもよい。また、このシステムで述べられるビーコン送信は、アセットの温度、アセットの向き（医療用コンテナが逆さまになった場合にフラグを立てる）、医療用クールボックスのバッテリ状態等、他のセンシングデータを含んでもよい。

この第３の実施形態では、Ｌ１～Ｌ１０とラベル付けされ、図１０に示される、１０個の照明器具２０１～２１０が、異なるモードで動作する異なる照明器具グループにグループ化される。グループの構成は経時的に変化し、その結果、照明器具によって実行されるＲＦベースのアセットトラッキングの量及びメッセージ転送の量も経時的に変化する。Ｂｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（ＢＬＥ）ビーコン（例えば、ビーコン２１９）が、アセット（例えば、物体、動物及び／又は人）の位置が決定されることを可能にするために、アセットに取り付けられている。

コントローラ、例えば、図１のブリッジ１は、ビーコン受信モード（ＢＲＭ：ｂｅａｃｏｎ ｒｅｃｅｉｖｅｒ ｍｏｄｅ）の照明器具２０１～２０５（Ｌ１～Ｌ５）から成る第１のグループＧ１を割り当てる。ビーコン受信ノードは、ＢＬＥビーコンを収集し、アセットに取り付けられたＢＬＥタグから受信する信号のＲＳＳＩを決定する。同時に、これらのノードは、照明制御データ及びアセットトラッキング関連データをコントローラと交換する、並びに、照明関連コマンドのために、Ｚｉｇｂｅｅネットワークを断続的にリッスンする（例えば、ＢＲＭモードのノードは、９９％ＢＬＥをリッスンし、１％Ｚｉｇｂｅｅをリッスン及び送信してもよい）。ＢＬＥモードとＺｉｇｂｅｅモードとの間の時間配分、及び、これらのデバイスが自身の親ノードをチェックする頻度は、固定されてもよく、コントローラデバイスによって可変的にコンフィギュレーションされてもよく、又は受信したビーコン信号に基づいて動的に変化してもよい（例えば、Ｇ１デバイスが「新しい」アセットを検出する場合、Ｇ１デバイスは、すぐに自身の親（又は自身の親を介してコントローラ）に通知してもよく、一方、エリア内に静止しているアセット又はトラッキングされることがそれほど重要ではないデバイスであるアセットに関連する測定値は、ある間隔で集約されたメッセージで送信されてもよい）。残りの照明器具２０６～２１０（Ｌ６～Ｌ１０）（グループＧ２）は、自身のＢＬＥ（受信）機能性が非アクティブにされる、又は、ＢＬＥ機能性がごく短い時間割合(percentage of time)だけアクティブにされる通常のＺｉｇｂｅｅルータ（ネットワークキャノピーモード（ＮＣＭ：Ｎｅｔｗｏｒｋ Ｃａｎｏｐｙ Ｍｏｄｅ）としてコンフィギュレーションされる。

ＢＲＭデバイスは通常のＺｉｇｂｅｅルータとしてコンフィギュレーションされる一方、例えば、それらのうちの一部、例えば、Ｌ１が、（ＢＬＥビーコンをリッスンするようにコンフィギュレーションされるので）いくらか／ほとんどの時間Ｚｉｇｂｅｅネットワークをリッスンしていない場合、これは、Ｚｉｇｂｅｅネットワーク上でパフォーマンスの問題を引き起こす可能性がある。なぜなら、Ｌ１にメッセージを送信することを試みる、「通常の」デバイス、例えば、Ｌ７は、Ｌ１が（いくらか／ほとんどの時間）Ｚｉｇｂｅｅをリッスンしていないので、メッセージ配信が失敗することに典型的には気付くことになるからである。Ｚｉｇｂｅｅの基本的なメカニズムは、いくらか／ほとんどの時間利用可能ではないデバイスのために準備されていない。

したがって、Ｇ１内のすべての照明器具は、例えば、Ｚｉｇｂｅｅエンドデバイス（又は、機能性が低下したルータ）として動作するようにコンフィギュレーションされ、したがって、Ｚｉｇｂｅｅメッシュネットワークに（完全に）参加していなくてもよい。Ｇ１の照明器具の各々は、Ｚｉｇｂｅｅルータデバイスのうちの１つ（例えば、Ｌ６）を親として選択し、当該親は、（子と呼ばれる）Ｌ１デバイスとのＺｉｇｂｅｅ通信に使用される。デバイスＬ７がそのような子デバイスにメッセージを送信したい場合、Ｌ７は、親デバイスＬ６にメッセージを送信する。親デバイスは、子（例えば、Ｌ１）の代理で当該メッセージを保存する。子Ｌ１は、典型的には、保留メッセージについて自身の親Ｌ６と定期的にチェック（「ポーリング」）し、それらを取得して処理する。Ｚｉｇｂｅｅネットワーク上のいずれかのデバイスにメッセージを送信したい子Ｌ１は、自身の親Ｌ６にメッセージを送信し、親は、そのデスティネーションへのＺｉｇｂｅｅメッシュを介したメッセージのさらなる中継を担う。

Ｇ１のノードは、自身の親とＺｉｇｂｅｅで通信するために限られた期間しか必要としないため、ほとんどの時間ＢＬＥメッセージをリッスンすることができる。このアプローチは、Ｇ１デバイスがＢＬＥビーコンの高品質なアセットトラッキングを行う能力を最大限にする。また、これは、（Ｇ２ノード間のＺｉｇｂｅｅ通信は、Ｚｉｇｂｅｅで通常通り機能し、Ｇ１－Ｇ２通信は、通常のＺｉｇｂｅｅ子－親通信であるため）上述したＺｉｇｂｅｅのグループキャスト／ブロードキャストの特異性(Zigbee groupcast/broadcast peculiarity)を回避する。

Ｇ１デバイスは、アセットトラッキングデータを収集し、自身の親を介して他のデバイスに（可能であればフィルタリング及び集約(aggregation)後に）送信する。アセットトラッキングデータは、最終的にはＧ２デバイスのうちの１つ以上、又はＧ２デバイスのうちの１つ以上を介して接続されるデバイスに行く。また、すべてのデバイスは、照明ネットワークとしても機能し、中央又は分散インテリジェンスから制御されることができる。Ｇ２デバイスは、Ｚｉｇｂｅｅルータデバイスであるので、直接到達されることができる。Ｇ１デバイスは、（Ｇ２デバイスである）自身の親を介して到達されることができる。また、同じ照明Ｚｉｇｂｅｅネットワークは、Ｇ１／Ｇ２デバイス又は他のＺｉｇｂｅｅデバイスからスイッチ／センサデータを収集するために使用されることもできる。

Ｚｉｇｂｅｅ子－親通信のためのタイムスロットは、デバイスが、いつＢＬＥビーコンが典型的に到来するかを学習し、したがって自身のＺｉｇｂｅｅ通信のためにそれらのタイムスロットを避ける場合、子によってインテリジェントに選択されることができる。

Ｚｉｇｂｅｅネットワーク上の一部のデバイスが照明を制御するためにコマンドを送信する場合、これらは、ルータデバイス、例えば、Ｌ２によって直ちに受信される。これらは、子デバイス、例えば、Ｌ１のためにコマンドを保存し、子デバイスがその親をポーリングする場合にのみ、子デバイスは、保留メッセージを見つけ出し、自身の照明レベルを適合させることができる。これは、例えば、ポーリング間隔が１秒に設定されている場合、ライトＬ１は、ライトＬ６と比較して０～１秒遅れた応答を有することを意味する。特定の状況では、１秒の遅延は許容される。例えば、ライトがオンされていて、ユーザが壁スイッチを押してライトを調光又はオフにする場合、背景照明の別のソースが部屋で既にオンされている場合、エンドユーザが壁スイッチボタンを押して即座の応答を期待するのではなく、システムからのタイムスケジュール／動きセンサに基づいてライトが自動的に切り替えられる場合等である。この場合、グループＧ２の照明器具は、調光コマンドに直ちに反応する（したがって、壁スイッチボタンの押下が処理されているという視覚的なフィードバックをユーザに提供する）。

グループＧ１の照明器具は、遅れた応答を有する。Ｇ２とＧ１との間の遅延は、すべてのライトにフェードトランジション(faded transition)（例えば、オフまでに３秒のフェードタイム）を採用することにより緩和されることができる。また、Ｇ１は、Ｇ１が最終的に調光コマンドを受信するとＧ２に「追いつく(catch up)」ようにコンフィギュレーションされてもよい。Ｇ２とＧ１との間の遅延はさらに、１つ以上のルータデバイス、例えば、Ｌ６が、１つ以上の自身の子デバイスのための（タイムクリティカルな）メッセージを受信するとＢＬＥメッセージを送信し、これらの子デバイスにそれらの親をポーリングする必要があることを認識させることにより緩和されることができる。また、ＢＬＥメッセージに、タイムクリティカルなメッセージの関連する本文を含めてもよい。これは、照明デバイスについてのエンドデバイスの挙動に関連するレイテンシをなくすであろう。

Ｇ２とＧ１との間の遅延はさらに、照明制御、ライトデバイス及びセンサからのデータの収集、並びに、ＢＬＥビーコンデータの収集に必要とされる通信を可能にするために以下のメカニズムを採用することにより緩和されることができる。ライトがオフされている場合、ポーリングレートが上げられ、ゆえに、知覚されるスイッチオンのレイテンシが減らされる。ライトがオンされている場合、ライトは、典型的には、最後の人がエリアを出た後しばらくしてから（動きセンサ）又は人が退出時にエリアの周囲にある中央ライトスイッチを操作する場合にオフするため、（知覚される）スイッチオフのレイテンシはあまり気にならないので、ポーリングレートは減らされる。

ＢＬＥビーコンデータは、１つのビーコンが受信される場合、複数のビーコンがグループ化される場合、又はビーコンデータがさらに処理される場合（例えば、特定のビーコンからの複数のＲＳＳＩ値を平均して集約値にする等）、Ｌ１からＬ６に直接送信されることができる。アセットトラッキングのレイテンシと、子からその親へのビーコンデータ取得についてのＺｉｇｂｅｅ送信時間（したがって、ＢＬＥビーコンのリスニングに利用可能な時間）との間には、トレードオフがある。

好ましくは、グループＧ１及びＧ２の構成は、経時的に変化する。これは、グループＧ１及びＧ２のすべてのデバイスに対してＢＲＭとＮＣＭとの間で機能をローテーションすることにより実現されてもよい。グループＧ１、Ｇ２のすべてのデバイスに対するＢＲＭとＮＣＭとの間での機能のストレートスワップ(straight swap)は、Ｚｉｇｂｅｅネットワークがしばらくの間最適ではない状態になる、また、どのデバイスが存在するか（及びその信号強度）を知らずにＢＬＥビーコン受信が初期状態になる可能性がある。それゆえ、例えば、先ずＮＣＭノードの数を増やす、先ずＮＣＭノードの数を減らす、又は、ＢＲＭノードの数を一定に保つ等、より緩やかな変更(gradual change)が有益であり得る。

より緩やか変更のためのいくつかのオプションが図１１に示されている。照明器具Ｌ１～Ｌ１０は、それぞれ列２０１～２１０により表されている。第１のオプションとして、期間２１１～２１３において、ＮＣＭノードの数が先ず増やされる。期間２１１において、各ＢＲＭ／ＮＣＭグループは、５つのネットワークノードを含む。Ｌ１～Ｌ５は、ＢＲＭノードであり、Ｌ６～１０は、ＮＣＭノードである。期間２１２において、１つのノード（Ｌ５）が、ＢＲＭからＮＣＭに切り替えられる。ある時間後、期間２１３において、別のノード（Ｌ１０）が、元々の比率に戻すためにＮＣＭからＢＲＭに切り替えられる。

第２のオプションとして、期間２１４～２１６において、ＮＣＭノードの数が先ず減らされる。期間２１４において、各ＢＲＭ／ＮＣＭグループは、５つのネットワークノードを含む。期間２１５において、１つのノード（Ｌ１０）が、ＮＣＭからＢＲＭに切り替えられる。ある時間後、期間２１６において、別のノード（Ｌ５）が、元々の比率に戻すためにＢＲＭからＮＣＭに切り替えられる。

第３のオプションとして、期間２１７～２１８において、ダイレクトスワップが行われる。期間２１７において、各ＢＲＭ／ＮＣＭグループは、５つのネットワークノードを含む。期間２１８において、１つのノード（Ｌ５）が、ＢＲＭからＮＣＭに切り替えられ、（ほぼ）同時に別のノード（Ｌ１０）が、元々の比率を維持するためにＮＣＭからＢＲＭに切り替えられる。代替的に、他のオプションが使用されてもよい。

図１１に示されるステップの繰返し適用が、グループＧ１及びＧ２のデバイスの役割のスワップを実現するために使用されてもよい（図１２参照）。図１２の例では、第１のオプション（「先ずＮＣＭノードの数を増やす」）のステップ２１１～２１３が数回繰り返される。期間２３４において、１つの別のノード（Ｌ４）が、ＮＣＭからＢＲＭに切り替えられる。ある時間後、期間２３５において、別のノード（Ｌ９）が、元々の比率に戻すためにＢＲＭからＮＣＭに切り替えられる。期間２３６において、１つの別のノード（Ｌ３）が、ＮＣＭからＢＲＭに切り替えられる。ある時間後、期間２３７において、別のノード（Ｌ８）が、元々の比率に戻すためにＢＲＭからＮＣＭに切り替えられる。

期間２３８において、１つの別のノード（Ｌ２）が、ＮＣＭからＢＲＭに切り替えられる。ある時間後、期間２３９において、別のノード（Ｌ７）が、元々の比率に戻すためにＢＲＭからＮＣＭに切り替えられる。期間２４０において、１つの別のノード（Ｌ１）が、ＮＣＭからＢＲＭに切り替えられる。ある時間後、期間２４１において、別のノード（Ｌ６）が、元々の比率に戻すためにＢＲＭからＮＣＭに切り替えられる。

図１２の２１１から２４１までの一連のステップは、すべての関与するノードの役割を入れ替えている。このようなスワップの目的は、ある時点でＬ１～Ｌ５付近のアセットをより正確にモニタリングできるようにすること、及び、別の時点でＬ６～Ｌ１０付近のアセットを正確にモニタリングできるようにすることである。したがって、正確なアセットトラッキングがすべてのロケーションで可能である。ローテーションメカニズムが適用されなかった場合、正確なモニタリングは一部のノードの付近でのみ可能であり、他のノードの付近では可能ではなく、全体のエリアのカバレッジが不均等になる。

また、同様の変更方法は、（例えば、新しいアセットが空間に入ってきた場合にトラッキング性能を向上させるために）システム内のＧ１／Ｇ２ノードの異なる比率を動的に変更するために使用されることも可能である（図１３参照）。期間２６１において、各ＢＲＭ／ＮＣＭグループは、５つのネットワークノードを含む。期間２６２において、一部のノード（Ｌ１及びＬ５）が、ＢＲＭからＮＣＭに切り替えられ、これによりＮＣＭノード数を増やす。期間２６３において、各ＢＲＭ／ＮＣＭグループは、５つのネットワークノードを含む。期間２６４において、一部のノード（Ｌ７及びＬ１０）が、ＮＣＭからＢＲＭに切り替えられ、これによりＢＲＭノード数を増やす。

ルータＲからエンドデバイスＥＤ（又はその逆）への切り替えは、Ｚｉｇｂｅｅデバイスにとって簡単ではない。なぜなら、仕様（ここでは適用可能ではない、デバイスが、親が該デバイスのための空間がない場合、参加時にＥＤからＲに又はその逆にフォールバックすることができるという言及を除く）及び典型的な実装は、このために準備されていないからである。例えば、他のデバイスからＥＤとして知られているデバイスが黙って役割を切り替え、Ｒｏｕｔｅ Ｒｅｑｕｅｓｔ（ルートリクエスト）メッセージを送信する場合、これは、（ＥＤからのＲｏｕｔｅ Ｒｅｑｕｅｓｔを予想していないため）他のデバイスを混乱させる可能性がある。このセクションは、どのようにしてこのような切り替えが、望ましくない副作用なしにＺｉｇｂｅｅシステム内で実行することができるかを述べる。

役割変更の両方向（ＥＤ＝＞Ｒ及びＲ＝＞ＥＤ）について、デバイスは、Ｌｅａｖｅ（離脱）メッセージを送信する（ゆえに、該デバイスと直に隣接する他のデバイスは、該デバイスが最早ネットワークに存在しないことを認識する。これにより、他のデバイスは、該デバイスとその役割を「忘れる」、すなわち、このデバイスに関して保存されている永続的及び一時的な情報をすべてクリアする。）これは、ネットワーク内の他のデバイスに追加の変更を必要とすることなく、標準に準拠した方法で変更を可能にする。デバイス自身は、Ｚｉｇｂｅｅチャネル、並びに、ＰＡＮ、ＥＰＩＤ、ネットワークキー、ネットワークアップデートＩＤ、ショートアドレス、Ｔｒｕｓｔ Ｃｅｎｔｅｒ（トラストセンター）アドレス、（使用されている場合）Ｔｒｕｓｔ Ｃｅｎｔｅｒリンクキー等の他の関連するネットワーク特性を覚えている。そのため、役割を変更した後、該デバイスは、再びネットワークの一部となり、新しい役割で機能することを開始することができる。該デバイスは、保存されているネットワークパラメータ及びクレデンシャルを使用してネットワークに再び参加する。

集中セキュリティモード(centralized security mode)（すなわち、Ｔｒｕｓｔ Ｃｅｎｔｅｒ）が使用される場合、デバイスは、Ｔｒｕｓｔ Ｃｅｎｔｅｒで（新しい役割で）自身をアナウンスする必要がある。以前に送信されたＬｅａｖｅメッセージ（又は親によって結果として生成されるＵｐｄａｔｅ ｄｅｖｉｃｅ（アップデートデバイス）メッセージ）がＴＣに到達している可能性があるため、ＴＣが、デバイスが役割を切り替えることに関するすべての情報を削除すること、が防止されるべきである。役割切替(role switching)を担うオーケストレータ、例えば、図１のコントローラ１は、Ｔｒｕｓｔ Ｃｅｎｔｅｒ自身である可能性があるため、どのデバイスが役割変更(role change)に指名されたかを覚え、指名されたデバイスからステータス０ｘ０２＝デバイス離脱(ｄｅｖｉｃｅ ｌｅｆｔ)を持つＬｅａｖｅ／Ｕｐｄａｔｅ Ｄｅｖｉｃｅ（離脱／アップデートデバイス）を受信すると、Ｔｒｕｓｔ Ｃｅｎｔｅｒは、エントリを完全に削除するのではなく、このデバイスに関する何らかの情報（例えば、デバイスタイプ）を適応させることができる。

ＥＤ＝＞Ｒ：役割を変更した後、Ｒとして機能するＥＤは、メッシュ内の自身の接続性を維持するために（通常は１５秒間隔で送信される）Ｌｉｎｋ Ｓｔａｔｕｓ（リンクステータス）メッセージを定期的に送信することを開始する。１つのこのようなメッセージは、近隣の他のＲデバイスが新しいデバイスを認識できるように、ネットワークに再参加した直後に送信されることが好ましい。新しく追加されたデバイスがＬｉｎｋ Ｓｔａｔｕｓメッセージで空のネイバーリストを持つことに気付く、このような他のＲデバイスは、（通常の１５秒間隔よりも）早く自身のＬｉｎｋ Ｓｔａｔｕｓメッセージで応答してもよく、ゆえに、新しいデバイスは、自身のネイバーテーブルをセットアップするために周囲にある他のルータを知り、斯くして、メッシュを介して通信する準備をする。

役割を変更したデバイスのルーティングテーブルを迅速に構築する代替的なやり方は、Ｒに切り替える場合にこれらのテーブルを事前ポピュレート(pre-populate)することである。例えば、
－ 最後にＲであった時のテーブルで開始する（古いものである可能性があり、一部のデバイスは最早Ｒではない可能性がある）、
－ （この時点で誰がＲであるかを知っている）オーケストレータによって提案される初期ネイバーテーブルで開始する。オーケストレータ又はデバイスは、各接続の（履歴又は最近の）リンクコストを知っている可能性がある。
－ 第一近似として、Ｒに切り替わるＥＤノードは、ＥＤであった時の何らかの情報を再利用することができる。例えば、自身の親ルータを自身のＮＴに残しておき（これは、既にメッシュとの接続を与えるであろう）、Ｒの役割を続けることでＮＴを拡張することができる。

いずれの場合も、受信したメッセージに基づいてエントリ（ネイバーリスト及び関連するリンクコストの両方）を更新することは、通常とは異なるやり方で行われてもよい（例えば、異なる重みが、経時的に値を平均化するために使用されることができる、（リンクステータスメッセージだけではなく）追加のメッセージが、近隣ノードを追加するために使用されてもよい、メッセージを送信する頻度が、増加されてもよい、等）。なぜなら、事前ポピュレートされたデバイス及びリンクコストは、古いものであって、したがってライブデータよりもあまり「信用(trustworthy)」がない可能性があるからである。

（通常の「ゼロからのスタート(starting from scratch)」に勝る）これらの方法の利点は、ネイバーテーブルをポピュレートするためにデバイス間で送信するメッセージの数が少なくて済むことである。他のアプローチは、ＥＤが、ＥＤとしての動作中に、Ｚｉｇｂｅｅトラフィックをリッスンして（プロミスキャスモード(promiscuous mode)）、信号強度及びアドレス情報を含め、どのデバイスが近隣にあるかを学習し、斯くして、（Ｒに役割を変更した後に）この情報を使用してＲとしての機能を開始することである。

Ｒ＝＞ＥＤ：ＲからＥＤに役割を変更する前に、Ｒが、切替(switch)により影響される可能性のある機能を実行しているかどうか、例えば、他のＺＥＤの親であるかどうか、他のデバイスの代理でルーティングをしているかどうか、すなわち、（コンセントレータ／Ｔｒｕｓｔ Ｃｅｎｔｅｒ／オーケストレータへの多対一のルート以外の）ルーティングテーブルのエントリを持っているかどうか、及び／又は、プロキシとしてＧｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅの代理で通信を転送しているかどうか、がチェックされてもよい。もしそうであれば、切替の影響を最小限にするためのアクションが取られてもよい。例えば、切り替え（又は離脱メッセージの送信）の直前に、Ｒは、新しいルートが発見されることができるように、ルート障害のステータス(status route failure)を持つネットワークステータスメッセージを送信することができる（関連するルートディスカバリ(route discovery)が開始される際にまだ存在する場合、ルータは、ルートレコード(route record)メッセージを転送することを控えることができる）。

自身のＺＥＤの子らに対処するために、切り替わるデバイスは、（Ｒｅｊｏｉｎ＝ＴＲＵＥを持つ）Ｌｅａｖｅ Ｒｅｑｕｅｓｔ(離脱リクエスト）メッセージを送信し、斯くして、ＺＥＤの子に新しい親を探索させることができる（ＺＥＤがペアレントディスカバリ(parent discovery)を開始する時点でまだ存在する場合、切り替わるＲは、ＮＷＫ再参加要求(rejoin request)に応答することを控えることができる）。代替的に、オーケストレータ、例えば、図１のコントローラ１は、実際の切り替えの前又は後に、例えば、別のノードにＧＰＤのためのＰｒｏｘｙ Ｔａｂｌｅ（プロキシテーブル）エントリを作成する、ネットワークステータス（ルート障害）メッセージを送信する、又は、切り替えようとしているＲの子であるＺＥＤにＲｅｊｏｉｎ＝ＴＲＵＥを持つＭｇｍｔ＿Ｌｅａｖｅ＿Ｒｅｑｕｅｓｔメッセージを送信する等の切り替えの態様を担うことができる。

役割を変更した後、ＥＤとして機能するＲは、親デバイスを見つける必要がある。通常、この処理は、ＥＤがＭＡＣ Ｂｅａｃｏｎ（マックビーコン）メッセージ（又はＮＷＫ再参加(rejoin)メッセージ）を送信することを伴い、それを受信したすべてのＲ（Ｂｅａｃｏｎの場合、他のＺｉｇｂｅｅネットワークのＲも含む）の応答が後続し、返信してきたＲデバイスから潜在的な親を選択する。これは（時間的及びネットワーク負荷的に）あまり効率的ではないので、ＥＤがＲとして機能するために使用されていたネットワークのＰＡＮＩＤ及び動作チャネルにネットワーク検索(network search)を制限する等、最も明らかな改善に加えて、いくつかの追加的な改善が使用されることができる。例えば、
－ デバイスは、以前の期間で最も良い（例えば、最も低いリンクコストの）ネイバー（Ｒデバイス）をＲとして覚え、当該Ｒに（セキュアな）ＮＷＫ Ｒｅｊｏｉｎ Ｒｅｑｕｅｓｔ（ネットワーク再参加要求）を送信してもよい。
－ その役割をＲからＥＤに変更することをデバイスに指示する、オーケストレーションを行うデバイス、例えば、図１のコントローラ１から提案される親での事前コンフィギュレーション。これは、ブロードキャストメッセージとしてネットワーク全体に送信されてもよい。そのようなメッセージを送信することは、Ｌｅａｖｅメッセージの送信及び親探索(parent search)を廃れさせる。さらに、このような専用メッセージを受信することにより、受信デバイスは、切り替わるノードに関する変化しない情報、例えば、バインディング情報(binding information)を保持し、変化する情報（例えば、ＮＴエントリ及びルーティングテーブルエントリ）のみをパージ(purge)することができる。また、このメッセージは、例えば、ルートリペア(route repair)を引き起こすための専用メッセージの必要性を失くす。
－ さらに別の実装形態では、Ｌｅａｖｅメッセージを送信してから親を選択するのではなく、ＲからＥＤに切り替えようとしているノードが、役割切替に関する情報、及び、新たに選択された親（例えば、リンクコストが最も良いネイバーＲ）のアドレスの両方を含む、新しいメッセージを送信することができる。そのようなメッセージを送信することは、Ｌｅａｖｅメッセージの送信及び親探索の必要性を失くす。さらに、このような専用メッセージを受信することにより、受信デバイスは、切り替わるノードに関する変化しない情報、例えば、バインディング情報を保持し、変化する情報（例えば、ＮＴエントリ及びルーティングテーブルエントリ）のみをパージすることができる。また、このメッセージは、例えば、ルートリペアを引き起こすための専用メッセージの必要性を失くす。

デフォルトでは、ネットワークから離脱するデバイスは、バインディング、グループメンバーシップ等、以前に使用していた制御情報を忘れる（削除する）。明らかに、ライト制御は、役割変更オペレーション後も継続する必要があり、ゆえに、このような情報の損失は避けられるべきである。第１のステップとして、デバイスはこの情報を覚え、役割を変更した後に再利用することができる。いくつかの例（「スイッチ」は「センサ」と読まれることもできる）：
－ ランプはスイッチから制御され、スイッチがＬｅａｖｅメッセージを送信する。通常、スイッチは、どのランプを制御していたかを忘れてしまう。好ましい実装形態では、スイッチは、制御していたランプのリストを覚えておく。リストは、ユニキャスト又はグループキャストアドレスのリストであってもよい。
－ ランプはユニキャストでスイッチから制御され、ランプがＬｅａｖｅメッセージを送信する。スイッチは、（Ｌｅａｖｅメッセージのため）自身のバインディングテーブルからランプを削除し、ゆえに、ランプ（又はオーケストレータ、例えば、図１のコントローラ１等の別のデバイス）は、バインディングを再確立する必要がある。
－ ランプはグループキャストでスイッチから制御され、ランプがＬｅａｖｅメッセージを送信する。スイッチは、（送られるのはグループであるため）自身のバインディングテーブルからランプを削除せず、ゆえに、ランプは、自身のグループのメンバーシップ及び関連する設定を覚えておく必要がある。

（特定のコマンド機能をネーミングする）上記のメカニズムのいくつかは、現在のＺｉｇｂｅｅ規格の使用を前提としている。もちろん、Ｚｉｇｂｅｅメカニズム及びメッセージに対する拡張（例えば、「Ｉ'ｍ ｓｗｉｔｃｈｉｎｇ ｒｏｌｅ（私は役割を切り替える）」メッセージ）を定義し、（潜在的にメッセージの数を減らす、又は収束を早めることを伴う）よりスムーズな切替を実現するためにこれらをデバイスに実装してもよい。

照明器具のほんの一部がビーコン受信機として動作する密な照明器具のグリッドの場合、ＲＳＳＩビーコン受信機の機能性は、第１のライトから、第１のライトに隣接せず、むしろ離れている第２のライトに意図的にローテーションされてもよい。これは、ローテーション前及びローテーション後の期間に取得される集約されたＲＳＳＩデータを用いるアセットの適切なトリラテレーション(tri-lateration)を保証する。

Ｇ１及びＧ２の間で役割をリバース(reverse)する瞬間は、全体的なアプリケーション及びエンドユーザ体験に対して予想される混乱が最も少ないことに基づいて選択されてもよい（例えば、あるエリアのライトが現在オンされている場合、役割のリバース(role reversal)の実行に起因するいくらかの照明レイテンシを導入することは許容される、又は、システム内の一部の照明器具が高解像度のＲＦベースのセンシングスキャンを行っている場合、高解像度のＲＦベースのセンシングスキャンを尊重し、したがってそれが終了するまで待つ）。

１つ以上の中央ノードが、様々なノードからのＲＳＳＩデータを収集する。アセットからのＲＳＳＩデータは、各ノードでパートタイム(part-time)にしか収集されないため、アセットトラッキングシステムは、欠落するＲＳＳＩデータサンプル、及び、ある時間前にサンプルされたものであるという事実に対処する必要があり、ビーコンを受信する複数のネットワークノードが同時にビーコンを（アクティブに）受信し、処理しないとしても、これら複数のネットワークノードからの総合データ(combined data)を活用することもできる。

これは、改善されたアセットのトリラテレーション及び／又はそのトラッキングを有利に提供することができる。処理は、アセットが移動している可能性があることを考慮してもよく、ゆえに、「ライブ」データが、（アセットが異なる位置にあったことに起因する可能性がある）「過去」データよりも信頼性が高いと考えられることができる。また、アセットのムーブメントに関する追加データを考慮してもよい。例：部屋にモーションセンサ（ＰＩＲ又はＲＦベースのセンシング）もあり、動きが検出されない場合、アセットも移動しない可能性が高い（典型的には、アセットは、移動する場合に動きセンサによって検出される人間によって移動される）。一方、エリアの一部で動きが検出される場合、当該エリアにあるアセットは、エリア内で又はエリア外に移動する可能性がある。この場合、ＲＦベースのセンシングが動きを検出すると、ＲＦベースのセンシング及びアセットトラッキングのジョイントシステムは、優勢的にモーションセンシングを行うことから、優勢的にアセットトラッキングを行うことへ焦点を変更してもよい。これは望ましいことである。なぜなら、ライトがＢＬＥを介してアセットタグをリスニングすればするほど、Ｚｉｇｂｅｅ無線機でＲＦベースのセンシングを行うのに費やすことができる時間が少なくなるからである。

変形例(Variant)１：有向アセット探索(Directed asset search)
好ましくは、コントローラ、例えば、図１のブリッジ１は、以下を考慮しながら、（１）トラッキングノード及び非トラッキングノードとして動作する照明器具の比率、（２）それぞれの位置及び（３）ＢＬＥ対Ｚｉｇｂｅｅのデューティーサイクル（及びオプションとして「新しい」又は「価値の高い」アセット対その他のアセットのレポーティングストラテジ）を動的且つ適応的に割り当てる。
・ 照明制御システムのコンテキスト（例えば、この期間にどれだけの照明コマンドが予想されるか、照明レイテンシ要件は何か、等）
・ データ収集システムのコンテキスト（例えば、中央デバイスが多くのデバイスからデータを収集する期間があり得る、等）
・ アセットトラッキングシステムのコンテキスト、例えば、
－ 新たなアセットが入室した場合、ビーコン受信機の照明器具の数が、迅速に正確なロケーションフィックス(location fix)を取得するために一時的に増やされ得る。
－ 動いている人がトラッキングされている場合、ジョイントシステムのアセットトラッキング機能のビーコン受信強度が上げられる。
－ 履歴データに基づいて予想されるアセットのムーブメント軌跡(movement trajectory)。

アセットが移動している又は移動している可能性があるというインディケーションがある場合、システムは、トリラテレーション精度及び／又は速度を向上させるために、潜在的に移動しているアセットの近くでＢＲＭノードがアクティブであることを確実にするようにＢＲＭ／ＮＣＭ機能の配分を動的に最適化する。

第１の例として、空間の一部（特にドア付近）で動きが検出される場合、アセットはそこで空間に入る又は出る可能性があり、ゆえに、強化されたアセットトラッキング性能が、空間のこの部分で望まれる。これは、追加のＢＲＭノードを割り当てる（ある期間ＢＲＭ／ＮＣＭの比率を調整する）、又は、（ＢＲＭ／ＮＣＭの比率をおおよそ(more or less)一定に保ちながら）ＢＲＭノードの当該エリアへの「シフト」により実現されてもよい。

第２の例として、特定の価値の高いアセットが検出される場合、当該エリアのより多くのＢＲＭノードが、より速い及び／又はより精度の高いフィックスを得るために一時的にアクティブにされる。第３の例として、割り当ては、特定のアセット又はアセットのタイプに関する履歴データに基づいてもよい（清掃トロリーは、典型的には、緊急用のクラッシュカートとは別の位置にあり、典型的には、異なる速度及びパターンで移動する可能性がある）。

変形例２：ＮＣＭ及びＢＲＭ間のトランジショナルモデル(Transitional mode)
任意の所与の瞬間にＺｉｇｂｅｅネットワークの安定性を確保するために、モード間のＺｉｇｂｅｅルータ／エンドデバイス機能性のハードスワップ(hard swapping)は避けられるべきである。

したがって、この変形例は、ライトが、追加のモード、トランジショナルモード（ＴＭ）を介してビーコン受信モード（Ｂｅａｃｏｎ Ｒｅｃｅｉｖｅｒ Ｍｏｄｅ）及びネットワークキャノピーモード（Ｎｅｔｗｏｒｋ Ｃａｎｏｐｙ Ｍｏｄｅ）間で徐々に移行するメカニズムを提案する。トランジショナルモードＴＭのデバイスは、ネットワークキャノピー（ネットワークカバレッジ）のニーズを考慮しながら、プライマリＺｉｇｂｅｅ(Primary-Zigbee)（ＮＣＭ）機能性及びプライマリＢＬＥアセットトラッキングモード(primary-BLE-asset-tracking mode)（ＢＲＭ）の間を移行するプロセスにある。モードＴＭのデバイスは、例えば、ビーコン受信機として動作しながらも、ネットワークキャノピーの機能を維持するためにＺｉｇｂｅｅルータ又は機能性を低下させたＺｉｇｂｅｅルータとして動作してもよい（例えば、５０％、ビーコン受信機、及び、５０％、Ｚｉｇｂｅｅルーティングノード）。

したがって、この変形例では、デバイスは３つの可能なモードを持つ。例えば、
・ １００％の時間、Ｚｉｇｂｅｅルータ（ＮＣＭ）
・ ９９％の時間、ＢＬＥ受信機、及び、１％の時間、Ｚｉｇｂｅｅエンドデバイス（ＢＲＭ）
・ ５０％、Ｚｉｇｂｅｅルータ、及び、５０％、ＢＬＥ受信機のパートタイム（ＴＭ）

ＴＭ「デバイス」について、以下のようにすることが有利であり得る。
－ このようなノードを介してトラフィックをルーティングしない（他のルータデバイスは、一部の時間しかこれらと通信することができないため）１つのメカニズムは、Ｌｉｎｋ Ｓｔａｔｕｓ（リンクステータス）において及び／又はＲｏｕｔｅ Ｒｅｑｕｅｓｔ（ルートリクエスト）転送する場合に、Ｌｉｎｋ Ｃｏｓｔ（リンクコスト）フィールドを（高いコストを意味する）高い値に設定することにより、他のノードがＴＭノードを経由してトラフィックをルーティングすることを阻止することである。別のメカニズムは、Ｒｏｕｔｅ Ｒｅｑｕｅｓｔの転送を遅らせる、又は、Ｒｏｕｔｅ Ｒｅｑｕｅｓｔをまったく転送しないことであり、これは、ルートがＴＭノードを経由して構築されるのを防止する。
－ エンドデバイスが通信したい場合に親（ＴＭデバイス）がＺｉｇｂｅｅで利用可能ではない可能性があるため、Ｚｉｇｂｅｅエンドデバイスの親にならないようにする。

変形例３：ＢＲＭノードがメッセージを受信するが、メッセージを再ブロードキャストしない
ＢＲＭノードをＺｉｇｂｅｅエンドデバイスとして定義する代替例として、ＢＲＭデバイスは、他のノードから受信するメッセージを再ブロードキャストしないようにコミッショニングされてもよい。したがって、これらのＢＲＭノードは、ルーティング機能性を持たないルータとしてＺｉｇｂｅｅネットワーク上で動作してもよい。すなわち、ＢＲＭノードは、自身のトラフィックのためだけにＺｉｇｂｅｅルーティングデバイスのように動作するが、他のデバイスに由来するメッセージをルーティングしない（すなわち、ＢＲＭデバイスは、他のノードのルートディスカバリメッセージに応答しない）。このアプローチは、ＢＲＭノードをＺｉｇｂｅｅエンドデバイスにして、ブロードキャストを直接受信せず、親ノードによるメッセージのバッファリングを必要とする場合よりも有利であり得る。ルーティング機能性を持たないルータノードは、バッファリングを必要としない。Ｚｉｇｂｅｅエンドデバイスは、メッセージのために定期的に自身の親ノードをポーリングすることが必要とされることにより、追加のネットワークトラフィック、及びこのようなデバイスにメッセージを送信する際のレイテンシを引き起こすことに留意されたい。「再ブロードキャストしない(not rebroadcasting)」とは、例えば、（「オン」等の）より重要な照明制御メッセージは再ブロードキャストする、及び、それほど重要でないメッセージは再ブロードキャストしないことにより、選択的であってもよい。

変形例４：追加の照明器具のグループがメッセージを受信するが、メッセージを再ブロードキャストしない
通常のＺｉｇｂｅｅルータ（ＮＣＭ）としてコンフィギュレーションされるノードのグループ及びＺｉｇｂｅｅエンドデバイス（ＢＲＭ）としてコンフィギュレーションされるノードのグループに加えて、ルーティング機能性を持たないＺｉｇｂｅｅルータとしてコンフィギュレーションされる追加のノードのグループがあってもよい。図８に関連して説明されたように、ＢＲＭノードへの干渉を防ぐために、ＢＲＭノードの付近にあるノードがこのグループに入れられてもよい（図８において、このグループは「第２のサブセット」と呼ばれた）。

ノードの動作モードは、方法の第２の実施形態（図９参照）及び方法の第３の実施形態に関連して述べたように、ノードが使用されているときに変更されることが好ましい。照明器具Ｌ１が動作モードを変更する例が、図１４の列２０１に示されている。この例では、照明器具Ｌ１は、期間２８１及び２８２において（ルーティング）機能性が低下したＺｉｇｂｅｅルータ（図９の動作モード２）として動作し、期間２８３及び２８４においてＺｉｇｂｅｅエンドデバイス（図９の動作モード３）として動作し、期間２８５において通常のＺｉｇｂｅｅルータ（図９の動作モード１）として動作する。

期間の部分２９１において、照明器具Ｌ１は、ＲＦベースのアセットトラッキング（又は代替的な実施形態ではＲＦベースのセンシング）を行う。部分２９２～２９４において、照明器具Ｌ１は、ネットワークメッセージを取得する。部分２９２及び２９４において、照明器具Ｌ１は、通常のＺｉｇｂｅｅルータノードからネットワークメッセージを受信する。部分２９３において、照明器具Ｌ１は、自身の親ノードからネットワークメッセージを取得する。部分２９４において、照明器具Ｌ１はさらに、自身が受信した及び他のノードを意図したネットワークメッセージを転送する。また、照明器具Ｌ１は、部分２９２～２９４において他のＺｉｇｂｅｅデバイスに自身のネットワークメッセージ（すなわち、他のＺｉｇｂｅｅデバイスから受信していないネットワークメッセージ）を送信してもよい。

変形例５：Ｔｈｒｅａｄメッシュネットワークのためのデュアル無線照明制御／アセットトラッキング
この変形例では、Ｚｉｇｂｅｅプロトコルの代わりにＴｈｒｅａｄプロトコルが照明制御メッセージに使用される。Ｔｈｒｅａｄ規格は、ネットワークごとに最大３２個のルータ、残りのデバイスは非ルータノード（エンドデバイス）であることを認めている。Ｔｈｒｅａｄは、例えば、ネットワーク内のルータの総数、ネイバーの数、ネイバーとのリンク品質、隣接するルータのルータテーブル等の基準に基づくルータノード選択プロトコルを述べている。Ｔｈｒｅａｄにおいて、エンドデバイスのうちの１つが、自身のルータノードへの接続を失う場合、エンドデバイス自身が、別のルータの探索を開始する。また、Ｔｈｒｅａｄ規格は、エンドデバイスがルータノードになるように遷移する及びその逆のためのメカニズムを述べていて、例えば、エンドデバイスが、自身がルータになった方が良いと考える場合、ルータになることを要求(request)する。Ｔｈｒｅａｄルータノードは、ルータノードとしての動作を停止する（エンドデバイスの役割に変更する）場合、それぞれの子デバイスに、親として代替的なルータノードに切り替える必要があることを通知する。

Ｔｈｒｅａｄネットワーキング規格は、上述のＺｉｇｂｅｅベースの例と比較して、本発明の文脈に関連するいくつかの機能性を持っている。Ｔｈｒｅａｄでは、２つのデバイスタイプ及び６つのデバイスの役割があり、デバイスタイプは固定されるが、デバイスの役割は経時的に変わることができる。２つのデバイスのタイプは、以下の通りである。（ａ）（Ｌｅａｄｅｒ、Ｒｏｕｔｅｒ、ＲＥＥＤ、ＦＥＤのいずれかの役割を持つことができる）フルＴｈｒｅａｄデバイス(full Thread device)、及び、（ｂ）（ＭＥＤ及びＳＥＤの役割を持つことができる）ミニマルＴｈｒｅａｄデバイス(minimal Thread device)。

デバイスが持つことのできる６つの役割は、以下の通りである（これらの最初の３つはＲｏｕｔｅｒ（ルータ）（Ｒ）、最後の３つはＥｎｄ Ｄｅｖｉｃｅ（エンドデバイス）（ＥＤ））。
・ Ｌｅａｄｅｒ（リーダ）（選出されたルータ(elected router)、ブックキーピング(bookkeeping)、ルータのリスト）
・ Ｒｏｕｔｅｒ（ルータ）
・ ＲＥＥＤ（Ｒｏｕｔｅｒ Ｅｌｉｇｉｂｌｅ Ｅｎｄ Ｄｅｖｉｃｅ（ルータエリジブルエンドデバイス）：ルータになる可能性はあるが、現在は非アクティブ、すなわち、ＥＤとして動作している。ＲＥＥＤ＝ＦＥＤ＋、ルータになる必要があるかどうかをチェックするアルゴリズムを実行）
・ ＦＥＤ（Ｆｕｌｌ Ｅｎｄ Ｄｅｖｉｃｅ（フルエンドデバイス））：ＦＥＤ＝ＭＥＤ＋、１つの親を持ち、マルチキャストを受信するために複数のデバイスにリンクする）
・ ＭＥＤ（Ｍｉｎｉｍａｌ Ｅｎｄ Ｄｅｖｉｃｅ（ミニマルエンドデバイス）：１つの親を持ち、無線は常にオン、親はＭＥＤが起きていることを予想し、メッセージは親を介して送信され、ＭＥＤは親のメッセージが成功裏に到着しない場合に対処するメカニズムを持っていない）
－ したがって、現在のＴｈｒｅａｄ規格に述べられているＭＥＤデバイスは、ＭＥＤがコンスタントにＴｈｒｅａｄメッセージをリッスンする必要があり、ＢＬＥメッセージをリッスンする時間がないため、デュアル無線（Ｔｈｒｅａｄ＋ＢＬＥ）照明器具として直接機能するのには適していない。
・ ＳＥＤ （Ｓｌｅｅｐｙ Ｅｎｄ Ｄｅｖｉｃｅ（スリーピーエンドデバイス）：ＭＥＤのようであるが、Ｔｈｒｅａｄに関する限りスリーピーである）
－ このＳＥＤは、（Ｔｈｒｅａｄに関する限り）スリープすることができる唯一のものであるが、本発明において、デバイスは、Ｔｈｒｅａｄでリッスンしていない時間を使って別のチャネル（ＢＬＥ）をリッスンしてもよい。他は、常にＴｈｒｅａｄデバイスとしてリッスンしている。

ゆえに、デュアル無線照明器具の場合、ＢＲＭデバイスはＳＥＤの役割を使用し、ＮＣＭデバイスは「ルータ」の役割（リーダー、ルータ、ＲＥＥＤ）のいずれかを使用することになる。Ｔｈｒｅａｄの仕様では役割の変更が認められているので、ＳＥＤから他の（ルータ）モードのうちの１つに及びその逆に変更することは、Ｚｉｇｂｅｅのような問題ではないはずである（上記のＺｉｇｂｅｅの説明及び問題点の回避策を参照）。

考慮すべき１つの態様は、Ｔｈｒｅａｄネットワーク内の特定のタイプのノードの数を自動的にバランスさせることである：
－ 大規模なネットワークでは、Ｔｈｒｅａｄはデフォルトで約２３個のデバイスをＲとして、残りをＥＤとして割り当てる。
－ Ｔｈｒｅａｄでは、システム内に約２４個以上のルータがある場合、ＲがＥＤになることを志願(volunteer)する。
－ システム内に約２２個以下のルータがある場合、ＥＤがＲになることを要求(request)する。

これは、分散アルゴリズムを使用した、デバイス間のローカルなインタラクションに基づく自動割り当てである。このような自動割り当ては、照明とアセットトラッキングとを組み合わせたネットワークにとって望ましい結果にはならないであろう。なぜなら、Ｔｈｒｅａｄの自動割り当てでは、場合によっては、すべてのＴｈｒｅａｄルータが部屋の左側に、すべてのＥＤが右側に位置することがあり、これは、アセットトラッキングのためのトリラテレーションの妨げとなるからである。さらに、Ｔｈｒｅａｄでは、（トリラテレーションを向上させるために必要とされる）位置に対して役割を動的に変更するためのトリガがない。

上述したように、アセットトラッキングアプリケーションに適したデバイスの分布を得るようにルータの割り当てをオーケストレーション(orchestrate)することが望ましい。Ｔｈｒｅａｄルータの自動割り当てを防ぐために、Ｔｈｒｅａｄ規格は、セントラルポイント(central point)が、役割を変更するように（帯域外チャネルを介して）デバイスに指示することができ、デバイスは、自身の変更された役割について自身のネイバーに通知することをすでに認めている。したがって、Ｔｈｒｅａｄプロトコルは、このための上手い仕組み(nice hook)及び標準メッセージをすでに提供し、一方、上述したように、Ｚｉｇｂｅｅは斯かるメッセージを欠いている。

以下のシーケンスは、ＮＣＭのためにＴｈｒｅａｄ Ｒｏｕｔｅｒ（Ｒ）及びＢＲＭのためにＳｌｅｅｐｙ Ｅｎｄ Ｄｅｖｉｃｅ（ＳＥＤ）の役割を使用して、ＴｈｒｅａｄシステムにおけるＮＣＭ及びＢＲＭ間の役割変更(role-changing)を実装するやり方を述べている。

ＢＲＭ＝＞ＮＣＭ（ＳＥＤ＝＞Ｒ）：ＳＥＤは、先ず通常のＥＤとして帰属し、その後ルータにアップグレードし、他のＥＤをＳＥＤにダウングレードする（ＮＣＭ＝＞ＢＲＭ）。自律的な変更のために、Ｔｈｒｅａｄ規格は、安定(stabilization)のための遅延（０～１２０ｓ）を持つ。これは、アプリケーションにとって長すぎる可能性がある。このような変更が、オーケストレーションされるようになされた場合、これは、数秒以内に実行され得るであろう。変更メッセージはネットワークトラフィックのピークにつながる可能性があることに留意されたい。したがって、Ｔｈｒｅａｄは、状況が安定している場合徐々に増加するトリクルタイムメカニズム(trickle time mechanism)を適用する。役割変更のセントラルオーケストレーション(central orchestration)を適用することが好ましく、これは、変更メッセージトラフィックピークを避けるためにネットワークレベルにおいて緩やかな役割変更を可能にする。

（例えば、住宅用アプリケーションにおいて）限られた数のノードを持つまばらな(sparse)Ｔｈｒｅａｄネットワークでは、すべてのＴｈｒｅａｄデバイスは数分後にルータになる。好ましくは、このようなまばらなＴｈｒｅａｄネットワークにおいても、一部のデバイスは、アセットタグによって送信されるＢＬＥビーコン信号をリッスンするのに十分な時間を持つように、意図的にスリーピーエンドデバイスＳＥＤとしてコンフィギュレーションされる。これは、Ｔｈｒｅａｄスタックが現在のＴｈｒｅａｄ規格に準拠する場合、これらのデバイスのＴｈｒｅａｄスタックの修正(modification)を必要とする可能性がある。

変形例６：よりまばらな(sparse)ネットワーク、例えば、Ｐｈｉｌｉｐｓ Ｈｕｅネットワーク
オフィス又は病院等の業務用照明アプリケーションで使用されるネットワークは、典型的には、多くのノードを有し、ゆえに、異なる機能性を持つグループへのノードの分割は、Ｚｉｇｂｅｅネットワークの性能及び「健全性」に効果的な影響を与えることなく実現され得る可能性が高い。

家庭用照明アプリケーション等、まばらなネットワークでは、役割が、Ｚｉｇｂｅｅネットワークが完全に機能を維持すること、及び、ビーコン受信（アセットトラッキング）機能性が許容可能なトラッキング性能を持って機能を維持することの両方を確実にするように慎重に割り当て及び変更される必要があるため、これらのメカニズムを適用することはより困難になる可能性がある。一方、このような家庭環境では、Ｇ１及びＧ２間でモードスワップを繰り返しスワップすることが、Ｚｉｇｂｅｅネットワーク性能を十分に確保しつつ、位置精度を高めることができる可能性がある。

典型的なホームネットワークは、典型的な業務用照明アプリケーションネットワークよりもノード数が少ないため、Ｚｉｇｂｅｅネットワーク負荷は低く、タグ付けされたアセットの数も少ないと予想される。それゆえ、大部分のノードがＮＣＭとしてコンフィギュレーションされて機能するＺｉｇｂｅｅメッシュを維持しつつ、ＢＲＭのためにデバイスの総数のうちの数デバイスを使用してもよい。役割をローテーションすることは、アセットロケーションのより正確なカバレッジを得ることを可能にする。

さらに、ホームネットワークでは、一部のライトが、主電源電圧壁スイッチによって一時的に給電停止されることがあり、したがって一時的にアセットトラッキングシステムに貢献することができない。それゆえ、ライトの給電が停止すると、システムは、当該ライトが再びパワーアップされるまでＧ１及びＧ２間のノードの分布を再構成する。

十分なノードが、家の特定のエリアでアセットトラッキング及びＲＦベースのセンシングの両方を実行するのに利用可能ではない場合、システムは、コンテキストに依存して２つの機能性のうちの一方をディスエーブルにする。例えば、家の所有者が外出している場合、ＲＦベースのモーション／占有者検出が、あり得る侵入者について家を監視するために実行される。所有者が家にいる場合、システムは、ＲＦベースのセンシングを用いた自動照明制御をディスエーブルにし（ユーザは代わりにバッテリ式の壁スイッチを使用する必要がある）、一方、システムは、家中でＢＬＥを備えた家電機器の位置をトラッキングする。

変形例７：ＷｉＦｉ＋ＢＬＥ複合無線
将来、ライトは、例えば８０２．１１ｓ規格を用いる、ＷｉＦｉ照明制御ネットワークで制御される見込みがある。すでにＷｉＦｉチップは、一般にＢＬＥ無線も備えている。したがって、これは、ＢＬＥ無線がビーコンを受信するために使用され、ＷｉＦｉがネットワークキャノピーを提供する、時分割(time-shared)ＢＬＥ＋ＷｉＦｉコンボ無線をライトにおいて可能にする。

ＷｉＦｉ ８０２．１１ｓ規格は、ルータノードとエンドデバイスとを区別する。ＷｉＦｉソリューションでは、照明器具は、（ゲートウェイを持たないスタンドアロンネットワークでＷｉＦｉを介してユーザのスマートフォンとインターフェースする）Ｍｅｓｈ（メッシュ） ＡＰ又はＭｅｓｈ（メッシュ）ノード（照明器具にＡＰがない。スマートフォンは、中央ゲートウェイとトークする）として動作することができる。

一実施形態では、一部のＷｉＦｉライトは、ビーコン受信機として半並行的(semi-concurrently)に動作する。この実施形態では、ＷｉＦｉライトは、Ｗｉｆｉ Ｍｅｓｈ ＡＰノードとして、又はＷｉＦｉ Ｍｅｓｈ Ｎｏｄｅとして、又はＷｉＦｉ Ｍｅｓｈ ＡＰ＋Ｂｅａｃｏｎ Ｒｅｃｅｉｖｅｒノードとして、又はＷｉＦｉ Ｍｅｓｈ Ｎｏｄｅ＋Ｂｅａｃｏｎ Ｒｅｃｅｉｖｅｒノードとして動作するように割り当てられる。

拡張例(Extension)１：現在の照明レイテンシ要件を考慮する
・ ライトが、電気照明が必要とされる時間帯又は日光のない空間でオフされている場合、典型的には人は存在せず、ゆえに、アセットはこの空間／部屋内で移動し得ない。したがって、（両方とも、ライトがオンすることが必要な場合に素早く反応することを目的に）この空間内のＮＣＭノードの数を増やす及び／又は親へのＢＲＭノードのポーリングレートを上げることが可能である。さらに、システム全体のネットワークキャノピーが、占有されていないサブ空間からのより多くのＮＣＭモードを持つことにより強化される。
－ 各空間内に（直接反応する）ＮＣＭノードと（親のポーリングが必要であることに起因していくらかのレイテンシを伴って反応する）ＢＲＭノードとが混在するという事実は、エンドユーザによって知覚されるレイテンシには限定的な影響しかない。なぜなら、多くのライト（ＮＣＭノード）は直ちにオンし、一部のノード（ＢＲＭノード）の応答が遅いという事実を視覚的に隠し得るからである。（すべてのノード、特にＮＣＭノードに）遷移時間を採用することも、この事実を隠す助けになる。オプションとして、遅れて始まるにもかかわらず、ＢＲＭノードのライトフェージング処理の終点がＮＣＭデバイスの終点と一致するようにＢＲＭノードの調光遷移時間をスマートに短くすることも可能であり得る。

・ ライトがオンされている場合、典型的には人が空間に存在し、ゆえに、アセットは移動し得る。したがって、この空間でライトがオンされている場合にはアセットを正確にトラッキングできるようにＢＲＭノードの数を増やすことが有益である。照明制御のレイテンシは、ライトがオンされている場合あまり気にならない。典型的には、最後の人が部屋を出てからしばらくしてライトはオフにされる必要があるので、一部のノードに対するスイッチオフコマンドのレイテンシの影響は気付かれない可能性が高い。

拡張例２：ポーリングの巧みな(clever)瞬間
Ｚｉｇｂｅｅエンドデバイスは、（めったにではないが）ＢＬＥビーコンの短い期間を逃してしまうように自身の親とたまにトークする必要がある。ＢＬＥビーコンは規則的なパターンで送信されるので、そのエリアの既知のアセットからのＢＬＥビーコンが予想されない瞬間にＺｉｇｂｅｅの親をポーリングすることが有利であり得る。

図１５は、図２～６及び８～９を参照して述べられたような方法を実行し得る、例示的なデータ処理システムを示すブロック図を示す。

図１５に示されるように、データ処理システム３００は、システムバス３０６を介してメモリ要素３０４に結合される、少なくとも１つのプロセッサ３０２を含んでもよい。それゆえ、データ処理システムは、メモリ要素３０４内にプログラムコードを記憶してもよい。さらに、プロセッサ３０２は、システムバス３０６を介してメモリ要素３０４からアクセスされるプログラムコードを実行してもよい。一態様では、データ処理システムは、プログラムコードを記憶及び／又は実行するために好適な、コンピュータとして実装されてもよい。しかしながら、データ処理システム３００は、本明細書内で述べられる機能を実行することが可能な、プロセッサ及びメモリを含む任意のシステムの形態で実装されてもよい点を理解されたい。

メモリ要素３０４は、例えば、ローカルメモリ３０８及び１つ以上の大容量記憶デバイス３１０等の、１つ以上の物理メモリデバイスを含んでもよい。ローカルメモリとは、プログラムコードの実際の実行中に一般に使用される、ランダムアクセスメモリ又は他の非永続的メモリデバイスを指してもよい。大容量記憶デバイスは、ハードドライブ又は他の永続的データ記憶デバイスとして実装されてもよい。処理システム３００はまた、実行中に大容量記憶デバイス３１０からプログラムコードが取得されなければならない回数を低減するために、少なくとも一部のプログラムコードの一時記憶を提供する、１つ以上のキャッシュメモリ（図示せず）を含んでもよい。また、処理システム３００は、例えば、処理システム３００がクラウドコンピューティングプラットフォームの一部である場合、別の処理システムのメモリ要素を使用することができてもよい。

入力デバイス３１２及び出力デバイス３１４として示される、入出力（input/output：Ｉ／Ｏ）デバイスが、オプションとして、データ処理システムに結合されることができる。入力デバイスの例としては、限定するものではないが、キーボード、マウス等のポインティングデバイス、（例えば、ボイス及び／又はスピーチ認識のための）マイク等を挙げることができる。出力デバイスの例としては、限定するものではないが、モニタ又はディスプレイ、スピーカ等を挙げることができる。入力デバイス及び／又は出力デバイスは、直接、又は介在Ｉ／Ｏコントローラを介して、データ処理システムに結合されてもよい。

一実施形態では、入力デバイス及び出力デバイスは、（入力デバイス３１２及び出力デバイス３１４を取り囲む破線で図１５に示されるような）複合型入力／出力デバイスとして実装されてもよい。そのような複合型デバイスの一例は、「タッチスクリーンディスプレイ」又は単に「タッチスクリーン」と称される場合もある、タッチ感知ディスプレイである。そのような実施形態では、デバイスへの入力は、タッチスクリーンディスプレイ上、又はタッチスクリーンディスプレイの近くでの、例えばスタイラス又はユーザの指等の、物理的実体の移動によって提供されてもよい。

ネットワークアダプタ３１６もまた、データ処理システムに結合されて、介在する私設ネットワーク又は公衆ネットワークを介して、データ処理システムが、他のシステム、コンピュータシステム、リモートネットワークデバイス、及び／又はリモート記憶デバイスに結合されることを可能にしてもよい。ネットワークアダプタは、上述のシステム、デバイス、及び／又はネットワークによってデータ処理システム３００に送信されるデータを受信するための、データ受信機と、データ処理システム３００から上述のシステム、デバイス、及び／又はネットワークにデータを送信するための、データ送信機とを含んでもよい。モデム、ケーブルモデム、及びＥｔｈｅｒｎｅｔカードは、データ処理システム３００と共に使用されてもよい、種々のタイプのネットワークアダプタの例である。

図１５に示されるように、メモリ要素３０４は、アプリケーション３１８を記憶してもよい。様々な実施形態では、アプリケーション３１８は、ローカルメモリ３０８、１つ以上の大容量記憶デバイス３１０内に記憶されてもよく、あるいは、ローカルメモリ及び大容量記憶デバイスとは別個であってもよい。データ処理システム３００はさらに、アプリケーション３１８の実行を促すことが可能な（図１５には示されない）オペレーティングシステムを実行してもよい点を理解されたい。アプリケーション３１８は、実行可能プログラムコードの形態で実装されており、データ処理システム３００によって、例えばプロセッサ３０２によって、実行されることができる。アプリケーションの実行に応答して、データ処理システム３００は、本明細書で述べられる１つ以上の動作又は方法ステップを実行するように構成されてもよい。

本発明の様々な実施形態は、コンピュータシステムと共に使用するためのプログラムプロダクトとして実装されてもよく、このプログラムプロダクトのプログラムは、（本明細書で説明される方法を含めた）実施形態の機能を定義する。一実施形態では、このプログラムは、様々な非一時的コンピュータ可読記憶媒体上に含まれることができ、本明細書で使用されるとき、「非一時的コンピュータ可読記憶媒体」という表現は、全てのコンピュータ可読媒体を含むが、唯一の例外は一時的な伝搬信号である。別の実施形態では、このプログラムは、様々な一時的コンピュータ可読記憶媒体上に含まれることができる。例示的なコンピュータ可読記憶媒体としては、限定するものではないが、（ｉ）情報が永続的に記憶される、書き込み不可記憶媒体（例えば、ＣＤ－ＲＯＭドライブによって読み取り可能なＣＤ－ＲＯＭディスク、ＲＯＭチップ、又は任意のタイプの不揮発性固体半導体メモリ等の、コンピュータ内部の読み出し専用メモリデバイス）、及び（ｉｉ）変更可能な情報が記憶される、書き込み可能記憶媒体（例えば、フラッシュメモリ、ディスケットドライブ若しくはハードディスクドライブ内部のフロッピーディスク、又は任意のタイプのランダムアクセス固体半導体メモリ）が挙げられる。コンピュータプログラムは、本明細書で述べられるプロセッサ３０２上で実行されてもよい。

本明細書で使用される用語法は、特定の実施形態を説明することのみを目的とするものであり、本発明を限定することを意図するものではない。本明細書で使用されるとき、単数形「a」、「an」、及び「the」は、文脈がそうではないことを明確に示さない限り、複数形も含むことが意図される。本明細書で使用されるとき、用語「含む（comprises）」及び／又は「含んでいる（comprising）」は、記述された特徴、整数、ステップ、動作、要素、及び／又は構成要素の存在を指定するものであるが、１つ以上の他の特徴、整数、ステップ、動作、要素、構成要素、及び／又はそれらの群の存在若しくは追加を排除するものではない点が、更に理解されるであろう。

Claims (13)

1. 複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御するためのシステムであって、当該システムは、
   前記複数のノードの第１のサブセットを決定し、前記第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む、
   ソースノードからデスティネーションノードへの複数のルートを決定し、前記複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む、及び
   前記複数のルートの各々の前記中間ノードのうちのいくつが前記複数のノードの前記第１のサブセットの一部であるかに基づいて前記複数のルートのうちの１つを選択する、
   ように構成される少なくとも１つのプロセッサと、
   前記ワイヤレスネットワークに前記選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信する、
   ように構成される前記ワイヤレスネットワークへのインターフェースと、
   を含む、システム。
2. 前記インターフェースは、前記第１のサブセットのうちの少なくとも１つのノードに前記１つ以上のメッセージのうちの少なくとも１つのメッセージを送信するように構成され、該少なくとも１つのメッセージは、該少なくとも１つのノードにメッセージルーティングを行わないように指示する、請求項１に記載のシステム。
3. 前記インターフェースは、前記第１のサブセットのうちの少なくとも１つのノードに前記１つ以上のメッセージのうちの少なくとも１つのメッセージを送信するように構成され、該少なくとも１つのメッセージは、該少なくとも１つのノードに前記無線周波数ベースの存在及び／又は位置検出機能のための１つ以上の無線周波数信号を送信及び／又は受信するように指示する、請求項１又は２に記載のシステム。
4. 前記インターフェースは、前記第１のサブセットのうちの少なくとも１つのノードにある期間の間に間断なく前記１つ以上の無線周波数信号を送信するように指示するように構成され、前記第１のサブセットのうちの少なくとも１つの他のノードは、前記ある期間の間に間断なく前記１つ以上の無線周波数信号を受信するように指示される、請求項３に記載のシステム。
5. 前記少なくとも１つのノード及び前記少なくとも１つの他のノードは、ライトデバイスであり、前記インターフェースは、前記少なくとも１つのノードに前記ある期間の間に間断なく前記１つ以上の無線周波数信号を送信するように指示するように構成され、前記少なくとも１つの他のノードは、前記ライトデバイスが前記ある期間の間に光出力状態が変わらないことが予想されるという予想に依存して前記ある期間の間に間断なく前記１つ以上の無線周波数信号を受信するように指示される、請求項４に記載のシステム。
6. 前記少なくとも１つのプロセッサは、１つ以上のターゲットセンシングエリアの１つ以上の位置に基づいて前記第１のサブセットを決定するように構成される、請求項１又は２に記載のシステム。
7. 前記少なくとも１つのプロセッサは、前記複数のノードの第２のサブセットを決定するように構成され、前記１つ以上のメッセージのうちの少なくとも１つのメッセージは、前記第２のサブセットのうちの少なくとも１つのノードに送信され、該少なくとも１つのメッセージは、該少なくとも１つのノードにメッセージルーティングを行わないように指示する、請求項１又は２に記載のシステム。
8. 前記少なくとも１つのプロセッサは、前記第１のサブセットのうちの１つ以上のノードの１つ以上の位置に基づいて前記複数のノードの前記第２のサブセットを決定するように構成される、請求項７に記載のシステム。
9. 前記第１のサブセット及び前記第２のサブセットは、第１の時点で選択され、前記少なくとも１つのプロセッサは、第２の時点で前記第１のサブセット及び前記第２のサブセットの新たな選択を実行するように構成され、前記第１のサブセットは、前記第１の時点における１つ以上の第１のターゲットセンシングエリアの１つ以上の位置に基づいて、及び、前記第２の時点における１つ以上の第２のターゲットセンシングエリアの１つ以上の位置に基づいて選択される、請求項８に記載のシステム。
10. 前記少なくとも１つのプロセッサは、ユーザアクティビティに依存して前記第１のサブセット及び前記第２のサブセットの前記新たな選択を実行するように構成される、請求項９に記載のシステム。
11. 前記第１のサブセットのうちの１つ以上のノードは、１つ以上の無線周波数信号を送信及び／又は受信するために第１のプロトコルを使用するように構成され、前記インターフェースは、前記１つ以上のメッセージを送信するために第２のプロトコルを使用するように構成される、請求項１又は２に記載のシステム。
12. 複数のノードを含むワイヤレスネットワーク内のメッセージルーティングを制御する方法であって、
    前記複数のノードの第１のサブセットを決定することであって、前記第１のサブセットは、無線周波数ベースの存在及び／又は位置検出機能を割り当てられる１つ以上のデバイスを含む、ことと、
    ソースノードからデスティネーションノードへの複数のルートを決定することであって、前記複数のルートのうちの少なくとも１つは、１つ以上の中間ノードを含む、ことと、
    前記複数のルートの各々の前記中間ノードのうちのいくつが前記複数のノードの前記第１のサブセットの一部であるかに基づいて前記複数のルートのうちの１つを選択することと、
    前記ワイヤレスネットワークに前記選択されたルートに従ってメッセージルーティングを行わせるために１つ以上のメッセージを送信することと、
    を含む、方法。
13. 少なくとも１つのソフトウェアコード部分を含むコンピュータプログラムであって、前記ソフトウェアコード部分は、コンピュータシステムで実行されると、請求項１２に記載の方法が実行されることを可能にするように構成される、コンピュータプログラム。

Images