(57)【特許請求の範囲】
【請求項１】
標準無線ネットワークZigBeeプロトコルの使用を適応させる方法であって、それによって、前記プロトコルにより、イニシエータノードが、前記プロトコルの無線ネットワークにまだ参加していない新しいノードであるときに、前記イニシエータノードが、前記イニシエータノードと第２ノードとの間の標準化されたメッセージの交換を含むリンク動作を開始するときには、前記リンク動作は、前記第２ノードが参加する前記イニシエータノードの新しい無線ネットワークを作成することが規定されており、前記方法が、前記リンク動作の完全なインスタンスを用いる代わりに、
適応メッセージを形成するよう、前記メッセージのうちの１つにおけるフィールドであって、前記標準プロトコルがアプリケーション特有の目的のために変更されることを許容するフィールドであるフィールドを適応させ、前記適応メッセージが、実際には、前記イニシエータノードの、前記第２ノードが既に参加している前記プロトコルの既存の無線ネットワークへの参加の要求であることを指示するために、前記適応メッセージを前記イニシエータノードから前記第２ノードに送信するステップを有し、
前記適応メッセージに対する応答において、前記イニシエータノードが、前記既存のネットワークに参加するよう前記イニシエータノードを招待する招待メッセージを受信し、
前記招待メッセージに対する応答において、前記イニシエータノードが、前記既存のネットワークに参加する方法。
【請求項２】
前記第２ノードが、環境を照明するための照明デバイスである請求項１に記載の方法。
【請求項３】
前記イニシエータノードが、センサデバイスである請求項１又は２に記載の方法。
【請求項４】
前記招待メッセージが、前記イニシエータノードによって第３ノードから受信され、前記要求が、前記第２ノードから前記第３ノードに転送されている請求項１に記載の方法。
【請求項５】
前記適応メッセージが前記第２ノードによって受信されるのに応じて、前記イニシエータノードは、前記適応メッセージの受信を確認する応答メッセージを前記第２ノードから受信し、
前記応答メッセージに対する応答において、前記イニシエータノードが、標準化された前記リンク動作を停止し、その代わりに、前記招待メッセージの受信を待つ請求項４に記載の方法。
【請求項６】
前記第３ノードが、照明制御ブリッジである請求項４又は５に記載の方法。
【請求項７】
前記無線ネットワークプロトコルが、ZigBee Light Linkであり、前記動作が、Touchlink動作である請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記適応メッセージが、前記ZigBeeプロトコルのデバイス情報要求である請求項１乃至７のいずれか一項に記載の方法。
【請求項９】
前記フィールドが、デバイス情報のテーブルにおける開始インデックスを指定する、前記ZigBeeプロトコルの開始インデックスフィールドである請求項8に記載の方法。
【請求項１０】
前記応答メッセージが、前記ZigBeeプロトコルのデバイス情報応答である請求項５に従属する請求項６乃至９のいずれかに記載の方法。
【請求項１１】
前記フィールドが、前記標準プロトコルによって規定されている目的を持ち、前記適応メッセージが、前記イニシエータノードの、前記既存の無線ネットワークへの参加の要求であることを示す前記指示が、前記目的のために前記第２ノードによって認識される範囲外の値を前記フィールドに含めることによって示される請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
標準ZigBeeネットワークプロトコルに従って動作するよう適応されるコントローラを有するデバイスであって、それによって、前記プロトコルにより、イニシエータノードが、前記プロトコルの無線ネットワークにまだ参加していない新しいノードであるときに、前記イニシエータノードが、前記イニシエータノードと第２ノードとの間の標準化されたメッセージの交換を含むリンク動作を開始するときには、前記リンク動作は、前記第２ノードが参加する前記イニシエータノードの新しい無線ネットワークを作成することが規定されており、
前記デバイスは、前記デバイスが、前記プロトコルの無線ネットワークにまだ参加していないように構成されている新しいノードであるかどうかを決定し、前記デバイスが新しいノードであると決定すると、前記リンク動作の完全なインスタンスを用いる代わりに、適応メッセージを形成するよう前記メッセージのうちの１つにおけるフィールドを適応させるよう適応されるコントローラを有し、
前記デバイスは、
前記適応メッセージが、実際には、イニシエータノードである前記デバイスの、前記第２ノードが既に参加している前記プロトコルの既存の無線ネットワークへの参加の要求であることを指示するために、前記適応メッセージを前記第２ノードに送信するための送信機と、
前記適応メッセージに対する応答において、前記既存のネットワークに参加するよう前記イニシエータノードを招待する招待メッセージを受信するための受信機とを更に有し、
前記招待メッセージに対する応答において、前記イニシエータノードである前記デバイスが、前記既存のネットワークに参加し、前記フィールドが、前記標準プロトコルがアプリケーション特有の目的のために変更されることを許容するフィールドであるデバイス。
【請求項１３】
請求項１２に記載のデバイスを有し、前記第２ノード及び前記第３ノードを更に有するシステムであって、請求項４若しくは５、又は請求項４若しくは５に従属する任意の他の請求項に記載の方法を実施するよう構成されるシステム。
【請求項１４】
処理装置において実行するときに、請求項１乃至１０のいずれか一項に記載の方法を実施するように構成される、コンピュータ可読記憶媒体において具現化されるコードを有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、ZigBeeネットワーク内の照明器具とペア(pair)にされるセンサデバイスを試運転する(commission)ような、無線ネットワークに参加するための無線通信対応デバイスの試運転に関する。
【背景技術】
【０００２】
ZLL（ZigBee Light Link）は、LED照明の無線制御のために設計されたオープンスタンダードである。ZLLを使用して構築されるLED照明器具、センサ、タイマ、リモコン及びスイッチは、連係するために特別なデバイスを必要とすることなくワイヤレスホームネットワークに接続することができる。例えば、Philips Hueは、ブリッジコントローラと、各々がネットワークのノードである多くの照明デバイス（例えば、LED「電球」）を含むZLLをベースにした照明システムである。ブリッジは、ユーザがユーザデバイスにおいて実行するアプリケーション（「アプリ」）からの照明を無線で制御することを可能にするために、Wi-Fiなどの別の無線技術を介して、ネットワークと、スマートフォン、タブレット、ラップトップなどのユーザデバイスとの間のインターフェースを供給する。
【０００３】
消費者が、前記消費者の家庭用照明ネットワークに追加のデバイスを容易に設置及び追加することができることを確実にするために、ZLLは、消費者にとって簡単であり、コーディネータの必要がない試運転メカニズムを開発した。このメカニズムは、Touchlinkとして知られている。
【０００４】
Touchlinkは、新しいZLLネットワークの基本的な試運転、又は既存のZLLネットワークへの新しいノードの追加のために用いられる。Philips Hueシステムを例にとると、ブリッジコントローラ及び複数の電球をZLLネットワークに接続するには、ユーザは、２つのタイプのTouchlink動作を行う必要がある。
【０００５】
図１は、ZLLネットワークを作成するプロセスを図示している。ZigBeeは、メッシュネットワークを形成するためのプロトコルである。メッシュネットワークにおいては、ネットワークの幾つかのノードは、ネットワーク内の他のノードにメッセージを中継する役割と、ネットワーク内で送信されるメッセージの消費者及び／又は発信元であるという役割との両方の二重の役割を持ち得るのに対して、メッシュネットワークの幾つかの他のノードは、メッセージの発信元及び／又は消費者でしかないかもしれない。ZigBeeは、前者をルータと呼び、後者をエンドデバイスと呼ぶ。ZigBeeは、Factory New（FN）として知られている状態も定義する。これは、デバイスが、現在、どのネットワークのメンバーでもなく、この事実を知らせるためにデバイスがブロードキャストするスキャン要求においてFNフラグが設定されるという点において、デバイスが試運転されていないことを意味する（注意：デバイスは、実際に工場から来たばかりである又は「箱から出したばかりである」である際のFactory New状態にあり得るが、この状態にリセットされることもできる）。定義は、2012年4月5日のZigBee文書11-0037-10に記載されている（例えば、section 3参照）。
【０００６】
図１を参照すると、ZLLネットワークが、Factory-New（FN）イニシエータノード２及びルータノード４ａから形成されている（通常、イニシエータは、エンドデバイスである）。例えばHueシステムにおいては、ブリッジが、イニシエータ２であり、電球が、ルータ４ａである。LED電球の場合には、これは、厳密には、フィラメント電球という意味における電球ではなく、もっと正確に言えば、本明細書においては、「電球」という用語は、照明器具に組み込まれ得るモジュール式照明素子（即ち、ランプ）の省略表現として用いられていることに注意されたい。例えば、これは、例えば同じねじ込み又はバヨネット継ぎ手を備える、後付け可能な、従来のフィラメント電球に代わるものであり得る。
【０００７】
ユーザは、ブリッジ２に接続されたスマートフォンアプリ（又は同様のもの）を通して「新しいデバイスを発見する」という選択項目を選択することによって、Touchlinkネットワーク作成動作を呼び出すことができる。図１において図示されているように、Touchlink動作は、以下のステップを有する。
【０００８】
ステップ１００においては、イニシエータ（この例においてはHueブリッジ）２が、その近傍の電球にスキャン要求をブロードキャストする。近傍の範囲は、アプリケーションによって異なる。
【０００９】
ステップ１１０においては、任意の受信電球４が、スキャン応答を送信することによって、スキャン要求に応答する（図１は、単に説明のために１つの電球４ａを示している）。ZLLによれば、デバイス（この場合には電球）は、デバイスがスキャン要求を受信したRSSI（Received Signal Strength Indication）が或る特定のアプリケーション特有のしきい値を上回る場合にしか、受信したスキャン要求に応答しないだろう。通常、ZLLは、イニシエータ２とルータ４ａとを物理的に互いの近くに置くことを要求する。Hueブリッジ２と電球４とを非常に近づけることは、事実上、実施可能ではない又は便利ではないことから、Hueシステムは、より低いRSSIしきい値を設定することによって、ブリッジ２と電球４との間のより大きな距離を可能にしている。RSSIしきい値によって設定される前記近傍の範囲外にある電球４は、前記要求に応答せず、それ故、イニシエータ２によって発見されることができない。その場合には、ユーザは、Touchlink動作を完了するために電球４を一時的に近傍の範囲内に移動させ、次いで、前記電球４をその設置場所に戻す必要がある。
【００１０】
イニシエータ２が複数の電球４からスキャン応答を受信する場合には、アプリケーションは、後続の処理のために１つの電球４ａを選択するだろう。通常、最も高いRSSIを有するものが選択される。Hueシステムにおいては、ユーザが、スマートフォンアプリにおいて電球を選択する。ステップ１２０においては、イニシエータ２は、前記選択をする前にデバイス情報要求を送信することによって関心のある電球４ａに関するより多くの情報を得てもよい（具体的には、どんなサブデバイスがサポートされているかに関する情報、電球４ａのような所与のデバイスは、より多くのアプリケーションエンドポイント、例えば、２つの独立した光出力を持つ場合、サブデバイスに分けられ得る（例えば、ZigBee文書11-0037-10のsection 7.1.2.3.2参照））。これに応じて、ステップ１３０においては、電球４ａが、デバイス情報応答メッセージにおける情報で応答する。ステップ１４０においては、イニシエータ２が、正しい物理ノードが試運転されていることを確認するために、新しいネットワークの第１ルータとして選択されている電球４ａに識別要求を送信してもよい。
【００１１】
ステップ１５０においては、イニシエータが、ネットワークを作成及び開始するために、選択されたルータ（電球）４ａにネットワーク開始要求を送信する。
【００１２】
ステップ１６０においては、ルータ４ａが、新しいネットワークを作成して開始し、ネットワーク開始応答を送信することによりネットワーク開始要求に応答する。ルータが、Factory-Newではない場合には、ルータは、新しいネットワークを作成する前に前記ルータの古いネットワークから抜けるだろう。
【００１３】
次いで、イニシエータ２が、ネットワークに参加する。
【００１４】
（イニシエータ２及び１つのルータ４ａから成る）ネットワークが立ち上がったら、ネットワーク拡張タイプのTouchlink動作を行うことによって、追加の電球４が追加され得る。
【００１５】
図２は、既存のZLLネットワークにノード４ｂを追加するプロセスを図示している。ブリッジ２は、ユーザによって（例えば、「新しいデバイスを発見する」という選択項目をもう一度選択することによって）そうするよう要求されるとき、追加の電球４を追加することができる。図２において示されているように、Touchlink動作のこの変形例に含まれるステップは、ネットワーク作成シナリオと同様であり、各々ステップ１００乃至１４０と同じである（即ち、識別要求を含み、識別要求までの）ステップ２００乃至２４０を備える。しかしながら、ステップ２５０においては、ブリッジ２は、選択された電球４ａにネットワーク開始要求を送信する代わりに、選択された電球４ｂにネットワーク参加要求を送信し、ステップ２６０においては、電球４ｂは、次いで、ブリッジ２にネットワーク参加応答で応答する（必要に応じて、まず、前記電球４ｂの古いネットワークから抜ける）ことによって、ネットワークに参加する。ルータだけでなく、エンドデバイスも、この動作を用いて既存のネットワークに追加され得る。
【００１６】
WO 2015/078778 A1は、ZLL（Zigbee Light Link）ネットワークにおける試運転について記載している。提案されているソリューションは、ZLLネットワークに含まれる１つ１つの照明デバイスとTouchlinkする必要なしに、コントローラデバイスがZLLネットワークに参加することを可能にするために、既存のTouchlinkプロシージャを利用している。
【００１７】
US 2010/150063 A1は、新しいノードがアドホックネットワークに参加する方法について記載している。この方法は２つの基本機能を含む。新しいノードがネットワークに参加することを許可されるとき、参加されているノードの指示デバイスが指示を生成する。新しいノードがネットワークに参加するとき、新しいノードの指示デバイスもまた指示を生成する。
【発明の概要】
【発明が解決しようとする課題】
【００１８】
現在のTouchlinkをベースにした試運転プロセスは、存在センサなどのセンサを、所与の照明器具の１つ以上の電球に付随するよう既存のZLLネットワークに追加するために、ZLLセンサのために用いられることもできる。しかしながら、これは、ユーザの多くの関与を必要とする。
【００１９】
例えば、現在、ユーザは、新しい電球の場合と同様に、スマートフォン又はタブレット上のアプリからブリッジ２を介してセンサの追加を開始しなければならない。しかしながら、これは、必然的に必要とするよりも多くのユーザ関与であることが本明細書において明らかにされる。更に、電球は、アプリにおいて画面上で選択される電球が、実際に、ネットワークに追加される電球であることをユーザに対して視覚的に示すために点滅又は明滅することができる一方で、センサは、通常、このような目に見える手段を持たない（又は少なくとも顕著に目に見える手段を持たない）。これは、センサの試運転を、ユーザにとって電球の場合より厄介にする。
【００２０】
よりユーザフレンドリである自動試運転機能を備える「プラグアンドプレイ」ZLLセンサを提供することは望ましいだろう。特に、ユーザが、所与の照明器具の１つ又は複数の電球に付随するようその照明器具の中又は傍らにセンサを設置し、既存のネットワークへの前記センサの追加を、スマートフォンアプリを用いるのではなく、センサユニットの外側にあるボタンを押すことなどによって、前記センサそれ自体から開始することができる場合には、望ましいだろう。
【００２１】
しかしながら、ZigBee規格によれば、Factory Newのイニシエータが常にそれ自身の新しいネットワークを開始するだろうことから、この目的は簡単ではない。このことは、従来のTouchlinkプロセスのみに基づいて、センサの追加を前記センサから開始することを不可能にする。即ち、前記ユーザが、従来のようにして前記ブリッジを介するのではなく、前記センサからリンクすることを開始した場合には、Touchlinkプロセスの適応が全くなければ、これは、前記電球及びブリッジが既にメンバーである既存のネットワークへの前記センサの参加ではなく、前記センサとランプとの間で新しいネットワークが開始されることをもたらすだろう。
【００２２】
原理上は、新しい専用プロトコルを設計することはできる又は既存の規格への変更を要求することはできるが、それはあまり現実的ではない。
【００２３】
それ故、その代わりに、本開示は、既存のZLL規格のルールの範囲内で、即ち、前記規格の既存のメッセージタイプを用いるが、前記規格のルールを破ることなく、規格によって規定されているものの範囲を超えるこのようなメッセージの交換を見つけて、プロセスを改変する方法を提供する。このようにしてZLL規格のTouchlinkメッセージを再利用することによって、試運転プロセスは、ユーザの関与が最小限であるユーザフレンドリにされ得る。前記センサは、そのターゲットデバイス（例えば、照明デバイス）のそばに設置された後には、前記ユーザが前記試運転をトリガした後に、自動的に、前記ターゲットデバイスが動作するZLLネットワークに参加し、前記ターゲットデバイスとバインドする。
【００２４】
より広くは、それは、任意のタイプの（まだ試運転されていないので）新しいイニシエータノードが、他の第２ノードの既存のネットワークに、前記イニシエータ及び第２ノードが、センサ及び照明デバイスであるか、又は他のタイプのノードであるかにかかわらず、且つ前記ネットワークが、ZLL（ZigBee Light Link）ネットワークであるか、別のタイプのZigBeeネットワークであるか、イニシエータ及び参加に関して同様のルールを持つZigBee以外のプロトコルであるかどうかにかかわらず、参加することを可能にするのに望ましいだろう。即ち、本発明の原理は、任意の標準無線ネットワークプロトコルに関連して適用されることができ、それによって、前記プロトコルにより、イニシエータノードが、前記プロトコルの無線ネットワークにまだ参加していない新しいノードであるときに、前記イニシエータノードが、前記イニシエータノードと第２ノードとの間の標準化されたメッセージ交換を含むリンク動作を開始するときには、前記リンク動作は、前記第２ノードが参加する前記イニシエータノードの新しい無線ネットワークを作成することが規定されている。
【課題を解決するための手段】
【００２５】
本明細書において開示される或る態様によれば、このようなプロトコルの使用を適応させる方法が提供される。前記方法は、（フルの標準化されたメッセージの交換を含む）前記リンク動作の完全なインスタンスを用いる代わりに、適応メッセージを形成するよう、前記メッセージのうちの１つにおけるフィールドであって、前記標準プロトコルがアプリケーション特有の目的のために変更されることを許容するフィールドであるフィールドを適応させ、前記適応メッセージが、実際には、前記イニシエータノードの、前記第２ノードが既に参加している前記プロトコルの既存の無線ネットワークへの参加の要求であることを指示するために、前記適応メッセージを前記イニシエータノードから前記第２ノードに送信するステップを有する。前記適応メッセージに対する応答において、前記イニシエータノードが、前記既存のネットワークに参加するよう前記イニシエータノードを招待する招待メッセージを受信し、前記招待メッセージに対する応答において、前記イニシエータノードが、前記既存のネットワークに参加する。前記適応メッセージは、例えば、ZigBeeプロトコルのデバイス情報要求であり得る。
【００２６】
従って、前記方法は、正規にシステム設計者のドメイン内にある前記メッセージのうちの１つにおけるフィールドを、これを用いて前記第２ノードへの新しい信号を埋め込むよう設定するために利用することを含む。この信号は、前記第２ノードに、前記イニシエータノードによって開始された現在のリンク動作から抜け出させ、その代わりに、前記ネットワークの別の既存のノードによって開始された標準化されたリンク動作の別のインスタンスを開始させる。
【００２７】
実施例においては、前記招待メッセージは、前記イニシエータノードによって第３ノードから受信され、前記要求は、前記第２ノードから前記第３ノードに転送されていることに留意されたい。好ましくは、前記適応メッセージが前記第２ノードによって受信されるのに応じて、前記イニシエータノードは、前記適応メッセージの受信を確認する応答メッセージを前記第２ノードから受信し、前記応答メッセージに対する応答において、前記イニシエータノードが、標準化された前記リンク動作を停止し、その代わりに、前記第３ノードからの前記招待メッセージの受信を待つ。例えば、前記応答メッセージは、前記ZigBeeプロトコルのデバイス情報応答であってもよい。
【００２８】
利用される前記フィールドは、アプリケーション特有の使用のために完全にフリーであるフィールドである必要はない。もっと正確に言えば、前記フィールドには、規定されている名目上の用途があってもよいが、それでも、前記値は、アプリケーションに依存して設定可能である。例えば、前記フィールドは、問題の規格において特定の目的を持つものとして規定されていてもよく、前記適応メッセージが、前記イニシエータノードの、前記既存の無線ネットワークへの参加の要求であることを示す前記指示は、前記目的のために前記第２ノードによって認識される範囲外の値を前記フィールドに含めることによって示されてもよい。前記フィールドが、前記デバイス情報要求コマンドの前記開始インデックスフィールドである場合における特定の例は、前記第２ノードの利用可能なサブデバイスの数を超える値が設定されるものである。
【００２９】
実施例においては、前記イニシエータノードは、存在センサ又は周囲光センサなどのセンサデバイスの形態をとり得る。（時として、占有センサとも呼ばれる）存在センサは、動き又は熱などの検出される特性に基づいて、或る特定の空間内の人の存在を感知するためのデバイスである。例えば、人の動きを検出するために、前記存在センサは、能動的超音波センサを有してもよく、又は人によって生成される熱を検出するために、前記センサは、受動的赤外線センサを有してもよい。
【００３０】
試運転されると、前記センサは、前記照明器具又はランプであって、前記センサが、現在、前記照明器具又はランプと共に前記ネットワークに参加している前記照明器具又はランプを制御する、又は少なくとも前記照明器具又はランプの制御に影響を与えるように構成され得る。例えば、前記照明は、人の存在を感知することに応答して、オンにされてもよく、若しくは増光されてもよく、又は人の不在を感知することに応答して、オフにされてもよく、若しくは減光されてもよく、あるいは、前記照明は、周囲光（例えば、日光）の減少を感知することに応答して、オンにされてもよく、若しくは増光されてもよく、又は周囲光の増加を感知することに応答して、オフにされてもよく、若しくは減光されてもよい。
【００３１】
実施例においては、前記第２ノードは、環境を照明するための照明デバイスの形態をとり得る。これは、照明器具であってもよく、又は照明器具に挿入するための個別のランプであってもよい。前記ランプは、例えば、後付け可能な、フィラメント電球に代わるものであり得る。
【００３２】
実施例においては、前記第３ノードは、照明制御ブリッジの形態をとり得る。前記照明制御ブリッジは、例えば、前記無線ネットワークと、照明制御アプリケーションを実行するユーザ端末のような遠隔制御デバイスとの間のインターフェースを供給することができ、それによって、前記ユーザが前記遠隔制御デバイスを用いて前記第２ノード及び／又はイニシエータノードを制御することを可能にする。
【００３３】
実施例においては、前記第２ノードは、メッシュネットワークのルータ、例えば、ZigBeeネットワークによるルータである。他の例においては、前記第２ノードは、単なる、メッシュネットワークのエンドデバイス、例えば、ZigBeeネットワークのエンドデバイスであってもよい。
【００３４】
実施例においては、前記方法は、前記イニシエータノード及び第２ノードを、前記既存のネットワーク内の総ノード数のサブセットであるノードのグループにグループ化し、前記グループの前記ノードがグループとしてアドレス指定されることを可能にするグループアドレスを割り当てるステップを更に有し得る。
【００３５】
実施例においては、前記イニシエータノードは、それが試運転のために選択されたことをユーザに信号伝達する目に見える手段を持たなくてもよい。
【００３６】
実施例においては、前記イニシエータノードは、前記イニシエータデバイスの外部ハウジングに含まれる手動制御装置（例えば、機械式ボタン）をユーザが作動させることによって前記リンク動作を開始するようトリガされる。
【００３７】
本明細書において開示される別の態様によれば、上で又は本明細書の他の場所で開示されている実施例のいずれかによる方法を実施するよう構成されるデバイスが提供される。
【００３８】
本発明の別の態様によれば、
標準化されたネットワーク化に従って動作するよう適応されるコントローラを有するデバイスであって、それによって、前記プロトコルにより、イニシエータノードが、前記プロトコルの無線ネットワークにまだ参加していない新しいノードであるときに、前記イニシエータノードが、前記イニシエータノードと第２ノードとの間の標準化されたメッセージの交換を含むリンク動作を開始するときには、前記リンク動作は、前記第２ノードが参加する前記イニシエータノードの新しい無線ネットワークを作成することが規定されており、
前記デバイスは、前記デバイスが、前記プロトコルの無線ネットワークにまだ参加していないように構成されている新しいノードであるかどうかを決定し、前記デバイスが新しいノードであると決定すると、前記リンク動作の完全なインスタンスを用いる代わりに、適応メッセージを形成するよう前記メッセージのうちの１つにおけるフィールドを適応させるよう適応されるコントローラを有し、
前記デバイスは、
前記適応メッセージが、実際には、イニシエータノードである前記デバイスの、前記第２ノードが既に参加している前記プロトコルの既存の無線ネットワークへの参加の要求であることを指示するために、前記適応メッセージを前記第２ノードに送信するための送信機と、
前記適応メッセージに対する応答において、前記既存のネットワークに参加するよう前記イニシエータノードを招待する招待メッセージを受信するための受信機とを更に有し、
前記招待メッセージに対する応答において、前記イニシエータノードである前記デバイスが、前記既存のネットワークに参加し、前記フィールドが、前記標準プロトコルがアプリケーション特有の目的のために変更されることを許容するフィールドであるデバイスが提供される。
【００３９】
本開示の別の態様によれば、前記イニシエータノードと、第２ノードと、第３ノードとを有するシステムが提供される。
【００４０】
本明細書において開示される別の態様によれば、処理装置において実行するときに、上で又は本明細書の他の場所で開示されている実施例のいずれかによる方法を実施するように構成される、コンピュータ可読記憶媒体において具現化されるコードを有するコンピュータプログラムが提供される。
【図面の簡単な説明】
【００４１】
本開示の理解を助け、実施例がどのように実施され得るかを示すために、例として添付の図面に対する参照がなされる。
【図１】新しいネットワークを開始するためのZLL Touchlink動作を示す信号図である。
【図２】新しいノードを既存のネットワークに参加させるためのZLL Touchlink動作を示す信号図である。
【図３】無線ネットワークを示すブロック図である。
【図４】新しいノードを既存のネットワークに参加させるための修正されたプロセスを示す信号図である。
【発明を実施するための形態】
【００４２】
図３は、本開示の実施例によるシナリオのネットワーク構成を図示している。前記システムは、ZLLネットワーク６において接続された照明制御ブリッジ２及び複数の照明ノード４を有する。照明ノード４の各々は、照明器具又は個々のランプ、例えば、LEDをベースにした「電球」の形態の照明デバイスである（照明器具は、１つ以上のランプと、任意の関連するハウジング、ソケット又は支持物とを有する照明ユニットを指す一方で、ランプは、LEDのストリング若しくはアレイを有するLEDをベースにしたランプ、又は蛍光灯若しくはフィラメント電球のような、照明器具内の照明素子を指す）。或る好ましい実施例においては、照明ノードは、各々、従来のフィラメント電球又は蛍光灯の後付け可能な代替品の形態をとる。
【００４３】
照明制御ブリッジ２は、ZLLネットワークと、ユーザが照明ノード４によって発せられる照明を制御することを可能にする遠隔制御デバイス（図示せず）との間のインターフェースを供給する。好ましくは、遠隔制御デバイスは、ラップトップ、タブレット、スマートフォン又はスマートウォッチのようなモバイルユーザ端末の形態をとり、それによるブリッジとの接続は、ユーザが、ユーザ端末において実行する照明制御アプリケーション（「アプリ」）を介して照明を制御することを可能にする。しかしながら、他の例においては、遠隔制御デバイスは、専用の遠隔制御ユニットであってもよい。遠隔制御デバイスは、同じネットワークに接続される必要はなく、例えば、遠隔制御デバイスは、Wi-Fi又はBluetoothなどの別の無線アクセス技術を介してブリッジ２に接続する。ブリッジ２は、この無線アクセス技術を介して遠隔制御デバイスから受信した照明制御コマンドを受け取り、次いで、それらを、それらが向けられている関連する照明ノード４にZLLネットワークを介して転送する。
【００４４】
ここで、例えば、ユーザが、占有センサ又は日光センサなどの新しいZLLをベースにしたセンサ８を購入しており、それを用いて、例えば廊下のLEDをベースにした電球のような照明ノード４ａを制御することを望んでいる場合を想像されたい。センサを、照明ノード４ａのそばに設置し、オンにした後、ユーザは、占有に基づく制御を実現するために、センサを試運転する必要がある、即ち、照明ノード４ａが動作している既存のZLLネットワーク６にセンサを追加し、照明ノード４ａと、センサ８をバインドする必要がある。
【００４５】
センサ８の試運転は、２つの主なフェーズを含む。第１フェーズは、センサ８をZLLネットワーク６に追加するフェーズである。これを行うために、ユーザは、スマートフォンアプリにおいて「新しいデバイスを発見する」という選択項目を選択する。従来は、これに応じて、ブリッジ２が、ネットワーク拡張Touchlink動作を開始する。同様に、センサの設置場所が、ブリッジ２の近傍の範囲外にある場合には、ユーザは、Touchlink動作を完了させるためにセンサ８をブリッジに近づける必要がある。複数の新しいセンサが前記近傍の範囲内にある場合には、ユーザは、ネットワークに追加する適切なセンサを選択する必要がある。特定の照明効果（例えば、点滅）を示すことによって照明ノード４自体を識別することができる照明ノード４とは異なり、センサには、通常、自己識別のための手段がない。このことは、更なる困難をもたらし得る。
【００４６】
第２フェーズは、センサ８を照明ノード４ａとバインドする（又は「ペアにする」）フェーズである。ユーザは、スマートフォンアプリにおいて「新しいグループを作成する」という選択項目を選択し、グループID（例えば、ZigBeeグループアドレス）の下で新しいグループにセンサ及び照明ポイント４ａを追加する。
【００４７】
ユーザの関与がより少ない、よりユーザフレンドリな方法は、試運転が、センサ８において開始される（例えば、ユーザによりセンサ上のボタンを押すことによってトリガされる）ものであり、次いで、センサは、自動的に、ZLLネットワーク6に参加し、照明ノード４ａとペアになる。しかしながら、図１において図示されているような現在のTouchlinkプロセスによれば、Factory-Newエンドデバイス（即ち、この場合にはセンサ）が、ルータ（この場合には照明ノード４ａ）とTouch Linkする場合、これは、センサ９及び照明ノード４ａを含む新しいZLLネットワークを形成し、ここで望まれているようにセンサ８を既存のネットワーク６につなぐことはないだろう。
【００４８】
これに対処するため、以下のものは、プラグアンドプレイZLLセンサ８に自動試運転機能を与える。これは、ZLL規格のTouchlink動作を再利用することによって実現される。センサ８は、そのターゲットデバイス（例えば、センサ８がメッセージを送信する照明ノード４ａ）のそばに設置された後には、ユーザが試運転をトリガした後に、自動的に、ターゲットデバイス４ａが既に動作しているZLLネットワーク６に参加し、ターゲットデバイス４ａとバインドするだろう。
【００４９】
例として、図３の構成、即ち、照明ノード４ａがセンサのターゲットデバイスである構成を更に参照すると、自動試運転プロセスの主なステップは、以下の通りである。
(i)  センサ８が、Factory-Newデバイスが、実際には、照明ノード４ａが現在動作している既存のZLLネットワーク６に参加することを要求していることを、Touchlinkコマンドのうちの１つにおけるパラメータ設定を介して示す、照明ノード４ａとの「特別な」Touchlink動作を開始する。
(ii)  照明ノード４ａが、同じTouchlink動作内で前記要求に対して応答し、センサ８に、Touchlink動作を停止すると共にブリッジ２からのネットワーク参加要求を待つよう要求する（応答コマンドにおいてブリッジ２に関する情報も供給される）。
（iii）  センサ８は、Touchlink動作を停止すると共にブリッジからの要求を待ち、照明ノード４ａは、前記要求をブリッジ２に転送する。
（iv）  ブリッジ２は、（今回は、センサ８ではなくブリッジ２から開始される）センサ８との別のタッチリンク動作を介してセンサ８にネットワーク参加要求を送信する。
（v）  センサ８は、まず、要求を検証し、次いで、ZLLネットワーク６に参加する要求を受け入れる。
（vi）  ブリッジ２は、グループID（例えば、ZigBeeグループアドレス）を持つ新しいグループを作成し、次いで、このグループIDの下でグループにセンサ８及び照明ノード４ａを追加する。あるいは、照明ノード４ａが既にグループのメンバーである（例えば、照明ノード４ａが個別のランプであり、グループがこの同じ照明器具内のランプである）場合には、幾つかの実施例においては、ブリッジ２は、この既存のグループにセンサを追加し得る。
【００５０】
グループは、ネットワーク６内の全ノードのサブセットである。グループIDは、例えば、ネットワーク6を介してグループとしてセンサ６及び照明ノード４ａを制御するために、又はユーザデバイス（図示せず）において実行する照明制御アプリのユーザインタフェースにおいてグループとしてそれらを提示するために、センサ６及び照明ノード４ａをネットワーク６内のグループとして識別又はアドレス指定することを可能にする。このグループ化は、本明細書の他の場所では「バインドする」又は「ペアにする」とも呼ばれ得る（但し、グループに含まれる他のノード、例えば、全ても存在し得ることは除外されていないことに留意されたい）。
【００５１】
図４は、本発明の或る実施例による自動センサ試運転プロセスのメッセージフローを示している。
【００５２】
最初の「特別な」Touchlink動作は、以下のコマンドを含む。
ステップ４００においては、センサが、その近傍のあらゆるZLLデバイスにスキャン要求コマンドをブロードキャストする。このコマンドフレームの内容は、通常のスキャン要求コマンドと同じである。センサ８は、以下のフィールドを設定することによって、Factory-NewのZigBeeエンドデバイスであることをターゲットデバイスに知らせる。
・  トランザクション識別子フィールド：現在のトランザクション（即ち、Touchlink動作）を識別するために用いられる３２ビットの非ゼロ乱数。このパラメータはブリッジ２転送される。
・  ZigBeeデバイス情報フィールド：イニシエータ８がZigBeeエンドデバイスであることを示すよう論理型サブフィールドを設定する。
・  ZLL情報フィールド：イニシエータがFactory-Newであることを示すようFactory Newサブフィールドを設定する。
【００５３】
ステップ４１０においては、照明ノード４ａが、スキャン応答コマンドをセンサ８に送り返す。このコマンドフレームの内容は、通常のスキャン要求コマンドと同じである。２つ以上のデバイスがセンサ８にこのコマンドを送信することはあり得るが、照明ノード４ａから送信されたコマンドが、センサ８によって受信された全てのコマンドの中で最も高いRSSIを有するコマンドである。センサ８は、後で使用するために照明ノード４ａから送信されたコマンドの以下のフィールドを記録する。
・  PAN識別子フィールド：照明ノード４ａが動作するPAN（即ち、ZLLネットワーク６）を指定する。
・  論理チャネルフィールド：照明ノード４ａが動作しているZLLチャネルを指定する。
・  サブデバイス数フィールド（オプション）：デバイス４ａによってサポートされるサブデバイス（エンドポイント）の数を指定します。前記規格によれば、１つのデバイスは、２４０個のエンドポイントまでサポートすることができる。
【００５４】
ZigBeeの用語においては、エンドデバイス（又はルータ）は、ZigBeeモジュールを備えるデバイスである。サブデバイスは、エンドデバイス内の機能モジュールである。例えば、ZigBeeエンドデバイスは、占有、日光、温度などの複数のセンサモジュールを含み得る。（エンドデバイスとは異なる）エンドポイントは、サブデバイスのための別の用語である。
【００５５】
ステップ４２０においては、センサ８が、スキャン応答に対する応答において、照明ノード４ａに、即ち、デバイスであって、前記デバイスから受信されたスキャン応答が最も高いRSSIを持つデバイスに、デバイス情報要求コマンドを送信する。コマンドフレームの開始インデックスフィールドは、これが「特別な」Touchlink動作であることを示すために用いられる。
・  開始インデックスフィールド：これは、従来は、ZLL規格に従って、デバイス４ａ（サブデバイス又はエンドポイント）のテーブルにおいて、前記テーブルからデバイス情報を取得するために、（０から開始する）開始インデックスを指定する。所与の受信ノードの場合は、このフィールドの有効値の範囲は、０から（「サブデバイスの数」−１）までであり、ここで、「サブデバイスの数」は、受信ノード（この例においては照明ノード４ａ）のサブデバイスの数である。
【００５６】
開始インデックスフィールドが、その通常の目的のために用いられた場合には、センサ８は、照明ノード４ａにおいて記憶されているテーブルにおいて幾つかの開始インデックスＸのところで記憶されている情報を折り返し報告するよう照明ノード４ａに要求するだろう。
【００５７】
しかしながら、本開示の実施例によれば、前記フィールドの「通常の」範囲を超える値、例えば、0xff又は「サブデバイスの数」を設定することによって、センサ８及び照明ノード４ａは、「特別な」Touchlink動作を実施することができる。即ち、この（必須ではない）フィールドの使用可能範囲外の数値を含めることによって、センサ８は、センサ８が実際には照明ノード４ａの既存のZLLネットワーク６に参加することを望んでいることを照明ノード４ａに知らせる別の目的のために、このフィールドを再利用する。前記数値は、ZigBee規格の仕様の観点からは依然として有効な範囲（即ち、０乃至２５５）内にあるが、特定の受信ノード（この例においては照明ノード４ａ）の観点からは範囲外であることに注意されたい。例えば、電球４ａは、5つのサブデバイスを含む一方で、センサは、第６サブデバイス又は第２５６サブデバイス（インデックス255 = １６進数の0xFF）の情報を要求している。
【００５８】
ステップ４３０においては、照明ノード４ａが、デバイス情報要求に対する応答において、デバイス情報応答コマンドをセンサ８に送信する。照明ノード４ａは、修正されたデバイス情報要求に基づいて、Factory-NewのZigBeeデバイスが、照明ノード４ａが動作しているZLLネットワーク６に参加することを要求していることを知ると、コマンドフレームのデバイス情報記録フィールドのIEEEアドレスサブフィールドをブリッジ２のIEEEアドレスとして設定する。
【００５９】
センサ８は、デバイス情報応答を受信すると、IEEEアドレスサブフィールドの値が送信元（即ち、照明ノード４ａ）のIEEEアドレスと同じであるかどうかをチェックする。異なる場合には、センサは、照明ノード４ａがその要求を受け入れたことを知る。その場合、ステップ４４０において、センサ８は、現在のTouchlink動作を停止すると共に、論理チャネルフィールドによって指定されたチャネルにおいて、デバイスであって、前記デバイスのIEEEアドレスがIEEEアドレスサブフィールドによって指定されているデバイスからのネットワーク参加要求（エンドデバイス要求）コマンドを待つ。
【００６０】
「特別な」Touchlink動作の停止後、試運転プロセスは、以下の動作を続ける。ステップ４５０においては、照明ノード４ａが、
・  特別なTouchlink動作のトランザクション識別子、
・  センサ８のIEEEアドレス、及び
・  センサ８、即ち、エンドデバイスの論理タイプ
といった情報を含む通常のZigBeeメッセージをブリッジ２に送信することによって、センサ８の要求をブリッジ２に転送する。
【００６１】
ステップ４６０においては、これに応じて、ブリッジ２が、デバイスであって、前記デバイスのIEEEアドレスが転送要求メッセージにおいて指定されているデバイス（即ち、センサ８）にネットワーク参加（エンドデバイス）要求を直接送信することによって、新しいTouchlinkネットワーク拡張動作を開始する。デバイスタイプはエンドデバイスであることから、ネットワーク参加（エンドデバイス）要求が用いられる。コマンドフレームのトランザクション識別子フィールドの値は、特別なTouchlink動作のトランザクション識別子として設定される。
【００６２】
ステップ４７０においては、センサが、ネットワーク参加（エンドデバイス）要求を検証する。即ち、センサ８は、ネットワーク参加要求を受信すると、送信元２のトランザクション識別子フィールド、PAN識別子フィールド及びIEEEアドレスを、記録されている値と比較することによって検証する。
【００６３】
ステップ４８０においては、センサ８が、ネットワーク参加（エンドデバイス）要求に応じて、ネットワーク６に参加し、ネットワーク参加（エンドデバイス）応答をブリッジ２に返送する。コマンドフレームの内容は、通常のものと同じである。
【００６４】
最後に、ステップ４９０においては、ブリッジ２が、センサ８を、照明ノード４と同じグループに追加する。センサ８は、照明ノード４ａ（ステップ４８０）及びセンサ８（ステップ４９０）にグループ追加（Add Group）コマンドの各々のインスタンスを送信して、それらの両方を同じグループに追加する。
【００６５】
ユーザ対話の観点から、試運転のためにセンサ８をそのターゲットデバイス４ａに近づけることは、非常にユーザフレンドリである。ほとんどの用途では、センサ８は、そのターゲットデバイス４ａのそばに設置される。センサ８が、そのターゲットデバイス４ａから離して設置される場合に、センサ８をそのターゲットデバイスのそばで試運転することは、実用的であるだけでなく（無線センサは、通常、バッテリ駆動である）、ユーザにとって直感的でもある。
【００６６】
上記の実施例はほんの一例として記載されていることは理解されるだろう。
【００６７】
例えば、本発明の背後にあるコンセプトは、ZLL又はZigBeeに限定されず、より広くは、プロトコルが、（ネットワークにまだ参加していない）新しいノードが、そのノードをネットワーク内の別のノードとつなぐためのリンク動作を開始するときに、この目的のために、イニシエータが他のノードの既存のネットワークに参加するのではなく、新しいネットワークが作成されることを規定しているあらゆる標準無線ネットワークプロトコルに関連して適用され得る。標準プロトコルは、２つ以上の独立した組織による使用のために公開されており、対応する標準化団体によって規定されているあらゆるプロトコルと考えられ得るイニシエータノードは、前記目的のために他のノードと連絡を取る最初のノードである。
【００６８】
更に、イニシエータ８が実際には既存のネットワークに参加することを望んでいることを示す指示は、デバイス情報要求において信号伝達されることに限定されず、より広くは、標準プロトコルのリンク動作に関わる任意の他のメッセージの任意のフリーフィールド又は必須ではないフィールド、例えば、スキャン要求（又はスキャン要求）に含められ得る。
【００６９】
用いられるフィールドは、設計者が望む如何なるアプリケーション特有の目的のためにも用いることができるよう空いたままになっている完全にフリーなフィールドであり得る。他の例においては、用いられるフィールドは、（開始インデックスフィールドのような）規格により規定されている目的を持つが、それでも、システム設計者が、幾らか自由に、アプリケーションに応じてその値を変更することができるフィールドであり得る。例えば、後者の場合には、前記指示は、開始インデックスフィールドに、サブデバイスの意味のある範囲外の値、即ち、受信ノード４ａにおいて実際に利用可能な数以外の値を含める前記実施例のように、問題のフィールドに、（第２ノードによってサポートされている範囲外の）無効な値を含めることによって、送信され得る。
【００７０】
更に、開示されている技術は、他のタイプのデバイスに関連して用いられてもよく、即ち、イニシエータ８は、センサ以外のデバイスであってもよく、第２デバイス４ａ（ルータ又はエンドポイント）は光源４ａ以外のデバイスであってもよく、第３デバイス２は、照明制御ブリッジ以外のデバイスであってもよい。例えば、イニシエータノード８、第２ノード４ａ又は第３ノード２の各々は、ランプ、照明器具、照明制御ブリッジ、存在センサ、周囲光センサ、セキュリティカメラ、バッテリパック、煙検出器、一酸化炭素（CO）検出器、空調ユニット、暖房ユニット、無線壁パネル若しくは壁スイッチ、又はビル制御装置のいずれかであってもよく、イニシエータノード８、第２ノード４ａ及び第３ノード２は、これら及び／又は他のものの任意の組み合わせであり得る。例えば、イニシエータノード８は、ビル制御ネットワークに追加されている煙検出器、CO検出器、防犯カメラ、空調ユニット、暖房ユニット、壁パネル又は壁スイッチであってもよく、第２ノード４ａは、別のこのようなデバイスであり、第３ノード２は、無線ビル制御ネットワークのコントローラである。
【００７１】
請求項において、「有する」という用語は、他の要素又はステップを除外せず、単数形表記は、複数の存在を除外しない。請求項において列挙されている幾つかのアイテムの機能を、単一のプロセッサ又は他のユニットが実現してもよい。単に、特定の手段が、相互に異なる従属請求項において引用されているという事実は、これらの手段の組み合わせが有利になるように用いられることができないことを示すものではない。コンピュータプログラムは、他のハードウェアと共に又はそれの一部として供給される光記憶媒体又は固体媒体などの適切な媒体に記憶／分散されてもよいが、インターネット又は他の有線若しくは無線電気通信システムなどを介して、他の形態で分散されてもよい。請求項における如何なる参照符号も、範囲を限定するものとして解釈されるべきではない。
【要約】
標準プロトコルは、イニシエータノードが、無線ネットワークにまだ参加しておらず、前記イニシエータノードと第２ノードとの間のリンク動作を開始するときには、このことは、新しい無線ネットワークを作成することを規定している。本開示によれば、標準化されたメッセージのうちの１つにおけるフィールドが適応され、適応メッセージが、実際には、前記イニシエータノードの、前記第２ノードが既に参加している既存の無線ネットワークへの参加の要求であることを指示するために、前記適応メッセージが前記イニシエータノードから前記第２ノードに送信される。問題のフィールドは、前記標準プロトコルがアプリケーション特有の目的のために変更されることを許容するフィールドである。前記適応メッセージに対する応答において、前記イニシエータノードが、前記既存のネットワークに参加するよう前記イニシエータノードを招待する招待メッセージを受信し、前記招待メッセージに対する応答において、前記イニシエータノードが、前記既存のネットワークに参加する。【図１】
0006430069.tif 000002
【図２】
0006430069.tif 000003
【図３】
0006430069.tif 000004
【図４】
0006430069.tif 000005