JP2019092197A - ノードを設定するための方法、及び設定されるノード - Google Patents

Abstract

【課題】異なるプロファイルの間のギャップを埋め、試運転プロシージャの行き詰まりを防止する無線ノード及び方法の提供。【解決手段】無線ネットワーク６００において、無線ノード６０１はコントローラ６０１０を有する。コントローラ６０１０は、近くに特定の種類の他のノード６１１〜６４１があるかどうかを検出する。コントローラ６０１０は、更に、無線ノード６０１がどんな種類のネットワーク形成機能を持つかに関する能力を決定し、無線ネットワーク６００を作成するために無線ノードを設定する。無線ノード６０１の設定は、無線ノード６０１がルータデバイス機能を持つと決定され、近くで特定の種類の他のノード６１１〜６４１が検出されない場合に、分散ネットワークを作成するように、又は、コーディネータ機能を持つと決定され、近くで特定の種類の他のノード６１１〜６４１が検出されない場合に、集中ネットワークを作成するように、設定される。【選択図】図６

Description

本発明は、ノードの試運転をし、ネットワークを作成する方法の分野、及びこのようなノードに関する。本発明は、例えば、無線センサネットワークに関連し、詳細には、複数の異なるプロトコルが存在するホーム・オートメーション・ネットワークに関連する。

ホーム・オートメーションは、無線ネットワークを利用する。過去数年にわたって、非常に多くのタイプのネットワークが、提案され、使用されている。例として、ZigBeeは、低コスト、低電力、無線メッシュネットワーク規格である。低いコストは、前記技術が、無線制御及び監視アプリケーションにおいて広く採用されることを可能にする。少ない電力使用量は、より小さなバッテリでのより長い寿命を可能にする。ZigBeeは、IEEE 802.15.4規格をベースにしている。ZigBeeデバイスは、低電力であるが、多くの場合、より遠いデバイスに到達するようデータに中間デバイスを通過させ、メッシュネットワーク、即ち、ネットワークデバイスの全てに到達することが可能な高電力送信機／受信機を持たないネットワークを作成することによって、より長い距離にわたってデータを送信する。無線アドホックネットワークの分散的性質は、それらを、中央ノードがあてにできないアプリケーションに適したものにする。

アプリケーションが試運転するためには、それらの有するデバイスは、共通のアプリケーションプロトコル（メッセージ、フォーマットなどのタイプ）を使用しなければならない。これらの規則のセットは、所謂プロファイルにグループ化される。更に、バインディング(binding)は、デバイスにおける着信又は発信データフローに関連する、所与のプロファイルのコンテキスト内でユニークな、入力及び出力クラスタ識別子のマッチングによって、決定される。バインディングテーブルは、供給源及び宛先のペアを含む。ZigBeeは、２つのフィーチャー・セットとして、ZigBee PRO及びZigBeeを利用可能であり、それらは、ZigBeeメッシュネットワークがどのように動作するか規定する。ZigBee PROは、最も広く用いられている仕様であり、低電力消費量のために、及び数千のデバイスを備える大きなネットワークをサポートするために、最適化されている。ZigBee PROは、同じエリア内で共存し得る幾つかのプロファイルを提案している。しかしながら、現在、異なるプロファイルからのノードが単一のネットワークを形成することを妨げる幾らかの非互換性がある。

ZigBee・ホーム・オートメーション（ZHA）は、消費者の快適さ、便利さ、セキュリティ及びエネルギ管理を向上させるよりスマートな家を作成する手助けをする世界標準業界規格である。更に、ZigBee・ライト・リンク（ZLL)は、相互運用可能な、非常に使い易い消費者向け照明及び制御製品のための世界標準規格を照明業界に与えている。それは、消費者が、タイマー、遠隔制御装置及びスイッチを介する、前記消費者の全てのＬＥＤ器具、電球にわたる無線制御を得ることを可能にする。象徴的なケースは、ZHAプロファイル及びZLLプロファイルデバイスによって表されている。ここで、主なギャップは、関係のあるプロファイルの異なる性質によって表されている。即ち、ZHAは、中央コーディネータのまわりに構築される一方、ZLLデバイスは、構成要素を追加すると共に、照明ネットワークを管理するためにTouchlinkメカニズムを利用する分散ネットワークにおいて動作し得る。

特定の設備のニーズを達成するためにデバイス及びネットワークを構成するタスクは、試運転として知られている。試運転は、その最も広い意味において、無線及び物理的環境の調査、デバイスの配置、パラメータの設定、アプリケーション・バインディング、ネットワーク及びデバイスパラメータの最適化、並びに適正な動作の試験及び確認を含む広範なタスクを含む。多くの場合、設置者の技術及びワークフロー慣例、デバイスの識別し易さ及びアクセスし易さ、並びに他の無線又は有線システムとの相互運用性及び共存を含む非技術的な問題及び半技術的な問題が、考慮される必要がある。試運転のための考慮は、多くの場合、設置者に焦点が当てられるが、開発及び試験並びに実地試験中にZigBeeシステムを容易に構成及び試運転する機能も、開発及び市場への製品出荷の速度を著しく上げることができる。更に、試運転し易さは、自作消費者市場のためにも重要である。

試運転プロセスは、多くのステップ、即ち、（ZigBeeにおいて検索及びバインディングと呼ばれる）ネットワークを検索し、参加する、又は作成するステップ、セキュリティアソシエーションを確立するステップ、デバイス及びサービスを発見するステップ、並びに制御関係を確立するステップを含む。

ZigBeeアライアンスにおいて、一般に、3つの異なる試運転モードが議論されている。第１の、Ａモード（自動モード）は、デバイスの自動試運転を含む。Ａモードは、一般に、最小限しか（又は全く）人間の介入を許容しない。第２の、Ｅモード（イージーモード）は、試運転中にデバイスに命令するためのデバイス上のボタン又は物理的機構の使用を含む。Ｅモードは、より簡単なエンドユーザ又はプロの設置者の試運転を可能にする。それは、通常、小さな設備（サイズ：一般的な家）をターゲットにしている。第３の、Ｓモード（システムモード）は、外部ツールの使用を含み、一般に、エキスパートの設置者によって用いられる。Ｓモードは、最も複雑な形態の試運転を表し、最も高いレベルの人間の介入を含む。それは、通常、商業施設及びハイエンド居住環境などのより大きな設備をターゲットにしている。更に、Ｓモードは、他のデバイスの試運転を実施若しくは制御する、又は他のデバイスの試運転に影響を及ぼす（中央）デバイスのための手段である集中試運転である。このタイプの試運転は、ゲートウェイ又はツール試運転とも呼ばれている。中央デバイスは、一般にグラフィカル・ユーザ・インタフェースに接続されているゲートウェイ、ホーム・コントローラ又は試運転ツールであり得る。それは、バインディング、及びネットワーク内の他のデバイスについてのレポートを構成することができる。集中試運転を実施するため、機能は、ZigBeeコーディネータであるデバイスに依存しない。実際には、それは、ZigBeeルータでもあり得る。ZHAネットワーク内のこの機能を備えるデバイスは、試運転ディレクタ（CD）と規定される。

ZHAプロファイルのための現在の仕様は、２つの異なる主な試運転モード、即ち、ＥＺモード試運転（例えば、押しボタン式試運転）と、集中試運転（例えば、別名、ゲートウェイ、ツール又はＳモード試運転）とを規定しており、ここで、ＥＺモード及び集中試運転は、相補的であり、完全互換性がある。

図１及び２は、ノードのための試運転の従来の方法を表すフローチャートを示している。ＥＺモード試運転は、とりわけ、図１に示されているようなネットワークステアリングプロシージャによって特徴づけられている。

図１によれば、ステップＳ１０１において、例えばユーザ操作によって、ＥＺモード・ネットワークステアリングが呼び出される。次いで、ステップＳ１０２において、前記ノードが、ネットワークに接続されているかどうか、又はネットワーク内で動作しているかどうかが、チェックされる。肯定の場合、ステップＳ１０３において、参加許可方法(permit join method)がイネーブルにされているかどうかが、チェックされる。これは、デバイスが前記デバイスに加わることを許可されているかどうかを決定するために用いられる参加許可フラグによって示される。参加許可がイネーブルにされている場合には、ステップＳ１０４において、他のデバイスにも参加を許可するよう命令するために、参加許可ブロードキャストサブルーチンが開始される。その後、ステップＳ１０５において、前記プロシージャがステップＳ１０８において終わるまで参加許可タイムアウトで終わる参加許可設定サブルーチンが開始される。ステップＳ１０２において、前記ノードが、ネットワークに接続されていない、又はネットワーク内で動作していないと決定される場合には、スキャン及び参加プロシージャが開始され、ステップＳ１０６において、前記プロシージャが成功したかどうかが、チェックされる。肯定の場合、前記プロシージャは、ステップＳ１０４にジャンプし、新しく追加されるデバイスを含む他のデバイスが参加することを許可するよう、参加許可プロシージャが開始される。ステップＳ１０６において、前記スキャン及び参加プロシージャの失敗が決定される場合には、オプションのネットワーク形成プロシージャが開始され、オプションとして、ステップＳ１０７において、前記ネットワーク形成プロシージャが成功したかどうかが、チェックされる。肯定の場合、前記プロシージャは、ステップＳ１０５にジャンプし、他のデバイスがこの新しく形成されたネットワークに参加することを許可するよう、前記参加許可設定サブルーチンが開始される。ステップＳ１０７において、前記ネットワーク形成プロシージャの失敗が決定される場合には、前記プロシージャは、ステップＳ１０８において終わる。それは、ステップＳ１０７のネットワーク形成が正確にはどの条件下で生じ得るのか、及び正確には何が前記結果になるのかを示さない、現在のＥＺモードプロシージャの短所である。これは、前記ネットワークにおける一貫しない挙動、及び非相互運用性をもたらすだろう。前記プロシージャはオプションであるから、或るシナリオにおいては、全くネットワーク形成をもたらさないかもしれない。

同様に、（文献・zll・zigbee・ライト・リンク・zll・プロファイル・仕様、ZigBee文献番号11-0037に開示されているような）ZLLプロファイル仕様は、好ましい試運転メカニズムとして、Touchlink試運転を供給している。前記ZLLシステムは、簡略化された設置方法から、消費者市場にアピールするための利益を得る。この方法は、Touchlinkとして知られており、ユーザの関与を最小限にし、既製品が消費者によって素早く容易に設置されることを可能にする。Touchlinkは、ネットワーク形成及び参加プロセスにおけるZigBeeコーディネータの必要性を取り除く。前記方法は、前記ノードにおいて走らされる（ZLL試運転クラスタをベースにした）特別な試運転アプリケーションを使用する。ネットワーク形成／参加動作を開始するノードは、「イニシエータ」として知られており、このノードは、多くの場合、遠隔制御ユニットであるが、別のノード、例えば、スイッチ、センサ又はランプであってもよい。Touchlinkは、ただ、（例えば、ボタンを押すことによって）開始される試運転及びネットワークに含まれるべきノードに近づけられるイニシエータ・ノードを必要とする。イニシエータによってネットワーク形成又は参加動作を実施するようコンタクトされるノードは、「ターゲット」として知られている。

図２は、ZLL仕様書（ZigBee文献11-0037-10）に記載されているような、TouchlinkプロシージャにおいてZLLイニシエータ(ZLL-I)及びZLLターゲット (ZLL-T)によって実施されるステップをまとめている信号図を示している。

前記プロシージャは、ステップ２０１において、随意のユーザの介入又は他のトリガに応じて開始する。イニシエータが、ステップ２０２において、プライマリZLLチャネル（１１、１５、２０、２５）の各々においてスキャン要求PAN間コマンドフレームをブロードキャストし、ステップ２０２ａにおいて、次のチャネルに切り替える前に、何らかの応答を受信するために所定の期間待つ。イニシエータは、まず、第１プライマリZLLチャネル（即ち、チャネル１１）において５つの連続したスキャン要求PAN間コマンドフレームをブロードキャストし、次いで、残りのプライマリZLLチャネルの各々（即ち、各々、チャネル１５、２０及び２５）において、順々に、単一のスキャン要求PAN間コマンドフレームをブロードキャストする。各送信後、イニシエータは、何らかの応答を受信するためにaplcScanTimeBaseDurationの間待つだろう。ターゲットデバイスは、スキャン要求を受け取り次第、ステップ２０３において、受信スキャン要求のRSSIが或る所定のしきい値を上回っているかどうかをチェックする。肯定の場合、ターゲットデバイスは、ステップ２０４において、スキャン応答をユニキャストする。

イニシエータは、ステップ２０５においてデバイス情報要求をユニキャストすることによって、ターゲットの付加的なサブデバイスについての情報を要求し得る。ターゲットは、この要求を受け取り次第、ステップ２０６においてデバイス情報応答で応答する。

オプションとして、例えば、ユーザに、見つかった複数のデバイスの中から選択させるために、イニシエータは、ステップ２０７において、所定の期間に設定された識別時間フィールドを備える識別要求PAN間コマンドフレームを生成し、ターゲットデバイスに送信し得る。ターゲットは、識別要求を受け取り次第、アプリケーション特有の方法で前記ターゲット自身を識別するが、応答を全く生成しない。ステップ２０８において、イニシエータが、ターゲットに識別要求停止を送信し得る。

前記プロシージャにおける他の動作は、イニシエータがファクトリーニューなデバイス(factory new device)であるかどうかが確かめられるステップ２０９におけるチェックに依存する。

イニシエータが、ファクトリーニューである場合には、ステップ２１０において、それが、選択ターゲットにネットワーク開始要求PAN間コマンドフレームを送信し、ステップ２１０ａにおいて、それが、ターゲットデバイスが応答を送信することを可能にする所定の期間を持つ受信ウィンドウを開始する。ターゲットは、ネットワーク開始要求を受け取り次第、ステップ２１１において、それ自身が新しいネットワークを開始することを許可するかどうかを決定する。ターゲットが、新しいネットワークを開始することを決定する場合、それは、ステップ２１２において、成功を示すステータスを持つネットワーク開始応答PAN間コマンドフレームを元のイニシエータへ送信する。イニシエータは、時間ウィンドウ内にネットワーク開始応答を受け取り次第、ステップ２１３において、ターゲットが新しいネットワークを作成することを可能にする所定の期間(aplcMinStartupDelayTime)を備える新しい時間ウィンドウを開始する。ステップ２１４においては、ターゲットがファクトリーニューなデバイスであるかどうかが、決定される。否定の場合、ステップ２１６において、ターゲットが、その古いネットワークにおいて離脱要求(leave request)を実施し、新しいネットワークパラメータをそのネットワーク情報ベースにコピーし、新しいネットワークにおいて動作し始める。ステップ２１３において開始した時間ウィンドウが経過した場合、ステップ２１５において、イニシエータが、再参加プロシージャによって新しいネットワークに参加する。

ステップ２０９において、イニシエータが、ファクトリーニューなデバイスではないことが決定される場合、前記プロシージャは、イニシエータが、ターゲットのデバイスのタイプに依存して、ネットワーク参加ルータ要求PAN間コマンドフレーム、又はネットワーク参加エンドデバイス要求PAN間コマンドフレームをターゲットに送信するステップ２１８に進み、ステップ２１８ａにおいて、その受信機が、所定の期間、ターゲット応答を待つことを可能にする。ステップ２１９において、ターゲットがネットワークに参加することを決定する場合、それが、ステップ２２０において、元のイニシエータに、ネットワーク参加ルータ／エンドデバイス応答PAN間コマンドフレームを送信する。ステップ２２３においては、イニシエータが、ターゲットデバイスが新しいネットワークにおいて適切に動作し始めることを可能にするために、所定の期間（例えば、aplcMinStartupDelayTime）の間待つ。ステップ２２１においては、ターゲットデバイスがファクトリーニューであるかどうかがチェックされる。ターゲットデバイスがファクトリーニューではない場合には、それが、ステップ２２２において、その古いネットワークにおいて離脱要求を実施し、ステップ２２４において、新しいネットワークに参加する。

更に、ZLLデバイスが非ZLLネットワークに参加することを可能にするために、ZLLデバイスは、Touchlinkモダリティと相補的な、クラシックな試運転プロシージャもサポートしなければならない。

現在、これらのプロシージャは、同じパブリックアプリケーションプロファイルに属するデバイスの間ではサポートされ、シェアされているが、それらは、異なるプロファイルのデバイスの間の相互運用を許可することが可能なメカニズムの共通のセットを供給してはいない。

更に、ネットワークの作成に関するステップは、ファクトリーニューなデバイスの場合に、両者の関連ギャップを示す。ZigBee仕様において規定されている形成及び参加は、まだネットワークにおいて動作可能ではない２つのデバイスの通信を考慮に入れていない。それ故、ZLLプロシージャは、PAN間ベースコマンドを介してネットワーク開始を保証するイニシエータに頼っている一方、ZHAデバイスは、ZLLネットワークトポロジにはない中央コーディネータの存在に頼っている。この理由のため、ZLLルータがZHAエンドデバイスに接続される、又はZHAルータがZLLエンドデバイスに接続されるあらゆる状況において、特に、何か他のデバイス（例えば：ZLL電球の制御を目的とするZHAスイッチ、ZHA電球の制御を目的とするZLLスイッチ）の存在又は助けなしには、現在の試運転プロシージャは適用できない。

とりわけ、２つの主な問題は、ZHAデバイスのための現在の試運転メカニズムを制限している、ネットワークの作成のために唯一のコーディネータの存在が必要なこと、及びイニシエータがTouchlinkプロシージャを介して初期設定パラメータ（即ち、PAN ID、EPID、動作チャネル、ネットワークセキュリティキー、ネットワークアドレスなど）を供給することなしにはZLLルータデバイスがネットワークを生じさせることができないことである。

本発明の目的は、異なるプロファイルの間のギャップを埋め、それによって、試運転プロシージャの行き詰まりを防止することができる無線ノードを動作させるための方法及び装置を提供することである。

本発明の別の目的は、無線ノードのための試運転方法を、それらの相互運用性を向上させることによって、簡単にすることである。

これらの目的は、請求項１に記載されているような装置、請求項３に記載されているような方法、及び請求項１５に記載されているようなコンピュータプログラムによって、達成される。

従って、少なくとも１つの他のノードと無線通信するためにコントローラによって無線ノードを動作させることが提案されており、前記無線ノードの能力が利用可能にされ、又は前記無線ノードの機能及びステータスのうちの少なくとも１つが前記コントローラに知られ、前記コントローラがネットワークを作成するよう構成され、前記ネットワークの特性が、決定される前記無線ノードの機能及びステータスに依存する。この提案されている試運転メカニズムは、異なる公開ZigBee PROプロファイルに属するデバイスのための共通の試運転プロシージャを提示していない現在のZigBee仕様のギャップを克服することを目的とする。詳細には、提案されているメカニズムは、現在の試運転仕様において考えられていない仕様事例シナリオを解決する（即ち、ZHAデバイスを制御するZLLデバイス、ZLLデバイスを制御するZHAデバイス、付近からのZLLデバイスの試運転）。

より詳細には、提案されている試運転メカニズムは、最初の試運転ステップ、即ち、ネットワーク作成の既存の問題に焦点を当てている。

従って、ノードは、ネットワークを作成するよう設定されることができ、前記ノードは、前記ネットワークを開始するために他のノードのためのアンカーの役割を果たすだろう。実際には、前記ネットワーク形成時に前記ノード（例えば、コーディネータ）がしなければならない外部動作又は信号伝達はないだろう。それ故、前記動作は、前記ネットワークパラメータを選択する、ネットワーク形成要求によりそれらを設定すると共にイネーブルにする、及び成功確認を受信するなどの、内部動作だけであり得る。従って、前記ネットワークを形成する動作は、外部視点からは完全にサイレントであり得る。しかしながら、ネットワーク設定デバイスは、他のデバイスの参加要求をリッスンしており、前記他のデバイスの参加要求に応答する準備ができている。
これは、「ネットワークを見つける及び作成する」という冒頭に記載した問題を解決することを可能にする。実際に、ルータデバイスは、一時的な分散ネットワークを作成する機能を持ち、イニシエータ又はコーディネータの存在の必要なしに、イニシアチブをとって一時的な分散ネットワークを作成し得る。

この結果は、現在の仕様において既に分析されている仕様事例と、分散（ZLL）及び集中（ZHA）ネットワークの互換性が必要とされるより複雑な状況とをカバーすることができる試運転プロシージャのフレキシブルなフレームワークである。

第１の態様によれば、前記コントローラは、更に、前記無線ノードがネットワーク形成が可能であるよう構成されているかどうかを決定し、前記無線ノードがルータデバイスとして構成されていると決定される場合には、分散ネットワークを作成するよう適応され得る。

第２の態様によれば、前記コントローラは、更に、前記無線ノードの近くに特定の種類の少なくとも１つの他のノードがあるかどうかを検出し、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合には、ネットワークを作成するよう適応され得る。例においては、前記特定の種類の少なくとも１つの他のノードは、コーディネータノード又はイニシエータノードであり得る。従って、作成されるネットワークの種類は、前記無線ノードの近くの他のノードの機能に依存させられ得る。

上記の第１の態様と組み合わされ得る第３の態様によれば、適切なネットワークがサーチされてもよく、適切なネットワークが見つけられない場合又は所定のタイプのネットワークしか見つけられない場合に、前記コントローラによって、前記無線ノードの能力が決定されてもよく、前記適切なネットワーク又は所定のタイプのネットワークは、参加デバイスによってサポートされているチャネルのうちの１つにおいて動作可能な特性、参加を許可する特性、特定のタイプのデバイスを追加することが可能な特性、特定のネットワークプロファイルをサポートする特性、特定のネットワークタイプ（例えば、集中、分散、一時的）を表す特性、又は特定のデバイスタイプを含む特性のうちの少なくとも１つを持つネットワークである。これは、特定のタイプのネットワークしか検出されない場合又はネットワークが検出されない場合にしか、提案されている試運転プロシージャが開始されないという利点を提供する。例示的な実施例においては、デバイスが一時的なネットワークを形成する場合には、再び試運転を実施するときに、それは、別のネットワークに参加し得る、又は２つ以上のデバイスを備える一時的なネットワークにおいてTouchlinkが実施される場合には、ファクトリーニューなイニシエータは、新しいネットワークを形成するのではなく、前記一時的なネットワークに参加するよう命令され得る。上記の第１又は第２の態様と組み合わされ得る第４の態様によれば、前記作成されるネットワークの特性は、前記コントローラが、前記無線ノードが分散ネットワーク形成機能を持つと決定する場合には、前記ネットワークは分散トポロジのものであるというようなものであり得る。この場合もまた、ネットワーク作成は、前記無線ノードの機能に適応される。

上記の第１乃至第４の態様のいずれかと組み合わされ得る第５の態様によれば、前記コントローラは、更に、前記無線ノードが、ネットワーク形成機能を持つかどうか及びどんな種類のネットワーク形成機能を持つかを決定し、前記無線ノードの近くに特定の種類の少なくとも１つの他のノードがあるかどうかを検出し、前記無線ノードがルータデバイスであると決定され、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合には、分散ネットワークを作成し、又は前記無線ノードがコーディネータ機能を持つと決定され、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合には、集中ネットワークを作成するよう適応され得る。

上記の第１乃至第５の態様のいずれかと組み合わされ得る第６の態様によれば、前記コントローラは、更に、適切なネットワークをサーチし、前記無線ノードの能力を決定し、決定される前記無線ノードの能力に依存してネットワークを作成することができ、前記適切なネットワークは、参加デバイスによってサポートされているチャネルのうちの１つにおいて動作可能な特性、参加を許可する特性、特定のタイプのデバイスを追加することが可能な特性、特定のネットワークプロファイルをサポートする特性、特定のネットワークタイプ（例えば、集中、分散、一時的）を表す特性、又は特定のデバイスタイプを含む特性のうちの少なくとも１つを持つネットワークである。最初のサーチするステップは、ネットワークが既に利用可能であるかどうかが最初にチェックされることを確実にする。

上記の第１乃至第６の態様のいずれかと組み合わされ得る第７の態様によれば、前記ネットワーク作成は、前記サーチするステップにおいて利用可能なネットワークが見つけられなかった場合に、実行され得る。それによって、前記ネットワーク作成は、ネットワークがまだ利用可能ではない場合に限定され得る。

上記の第１乃至第７の態様のいずれかと組み合わされ得る第８の態様によれば、前記能力は、ルータ、コーディネータ、トラストセンターの役割、ネットワークマネージャーの役割、ゲートウェイの役割、コンセントレータの役割、集中ネットワーク作成、集中ネットワーク参加、分散ネットワーク作成及び／又は参加、一時的なネットワーク作成及び／又は参加、ターゲット及び／又はイニシエータの役割におけるＥＺモード、ターゲットの役割におけるTouchlink、並びにイニシエータの役割におけるTouchlinkのうちの少なくとも１つを含み得る。これは、前記無線ノードが少なくとも１つのタイプのネットワークを作成することができるよう適応されることを確実にする。

前記装置は、ディスクリートなハードウェアコンポーネントを備えるディスクリートなハードウェア回路、集積チップ若しくはチップモジュールの配列をベースにして、又はメモリに記憶される、コンピュータ可読媒体に書き込まれる、若しくはインターネットなどのネットワークを介してダウンロードされるソフトウェアルーチン若しくはプログラムによって制御される信号処理デバイス若しくはチップをベースにして、実施され得ることに注意されたい。

請求項１に記載の装置、請求項３に記載の方法及び請求項１５に記載のコンピュータプログラムが、詳細には従属請求項において規定されているような、同様の及び／又は同じ好ましい実施例を持つことは、理解されるだろう。

本発明の好ましい実施例は、従属請求項又は上記の実施例と各々の独立請求項の任意の組み合わせでもあり得ることは、理解されるだろう。

下記の実施例を参照して、本発明のこれら及び他の態様を説明し、明らかにする。

ノードのための試運転の従来の方法を表すフローチャートを示す。 ノードのための試運転の従来の方法を表すフローチャートを示す。 ノードの電源オンの場合のための本発明の第１実施例によるフローチャートを示す。 ターゲットルータがネットワークを切り替える場合のための本発明の第２実施例によるフローチャートを示す。 イニシエータノードがネットワークをサーチする場合のための本発明の第３実施例によるフローチャートを示す。 実施例が実施され得る第４実施例によるネットワークアーキテクチャのブロック図を示す。

ここで、無線センサネットワーク又はホーム・オートメーション・ネットワークに基づいて本発明の実施例を説明する。詳細には、下で紹介及び説明されている例は、ZigBee無線ネットワークに基づいている。このようなネットワークは、幾つかのプロファイルが、共存し、相互に作用する必要があり得るホーム・オートメーション・ネットワークに関し得る。例えば、ZigBee・ライト・リンク及びZigBee・ホーム・オートメーションのノードは、とりわけネットワークの形成において一緒に動作する必要があり得る。ZigBeeネットワークは、ここでは、例として用いられており、本発明は、家及びビルのオートメーション又は検出又は監視のための他の種類の無線ネットワークにも適用し得ることに注意されたい。

実施例及びそれらの各々の試運転プロシージャの説明を続行する前に、ZigBeeシステムのためのネットワーク開始フェーズにおいて基本的な役割を果たすだろう変数を示し、説明する。下の表は、このような変数又はパラメータをまとめており、まず、パラメータの各々の一般的な名称を列挙し、次いで、それが取り得る（１６進数での）値の範囲及びファクトリーニューなデバイスにおける（１６進数での）そのデフォルト値を含むZigBeeにおけるその実現値を列挙している。下の第１表においては、ZigBee仕様によって既に規定されているパラメータが列挙されている。

ここで、上のパラメータの機能を簡単に説明する。

・ネットワークアドレス(NA)フィールドは、長さ１６ビットであり、無線ノード／コントローラに割り当てられる短いネットワークアドレスを含むだろう。

・パーソナルエリアネットワーク(PAN)識別子フィールド(PID)は、長さ１６ビットであり、PANの識別子を含むだろう。

・拡張PAN識別子(EPID)フィールドは、長さ６４ビットであり、ネットワークの拡張PAN識別子を含むだろう。

・（「phyCurrentChannel」と呼ばれている）論理チャネルフィールド(LC)は、長さ８ビットであり、ネットワークのために用いられる無線チャネルを含むだろう。

・ネットワークアップデート識別子(NUI)フィールドは、このノードが動作しているネットワーク設定のスナップショットを識別する値を含むだろう。

・セキュリティネットワークキー(SNK)セットは、試運転アプリケーションにアクセス可能であるべきであるネットワークキーイングマテリアルを含む。

・キー識別子(SNKID)は、セキュリティネットワークキーセット内のアクティブなネットワークキーのシーケンス番号を含む。

・コーディネータ対応(CC)フィールドは、Booleanフラグであり、デバイスがネットワークにおいてコーディネータの役割を果たすことができる可能性（即ち、随意に、トラストセンター・ポイントの役割を果たすことを含む、新しいネットワークを作成する可能性）について知らせるだろう。CCフラグがtrueに設定される場合には、デバイスは、コーディネータになることが可能である。CCフラグがfalseに設定される場合には、デバイスは、ZigBeeルータ又はZigBeeエンドデバイスのタイプであり得る。このフラグは、「nwkcCoordinatorCapable」と呼ばれ、現在のZigBee仕様においては、ネットワーク情報ベース(NIB)定数として存在する。（「apsDesignatedCoordinator」と呼ばれる）第２フラグは、現在のZigBee仕様においては、APS情報ベース(AIB)定数として存在し、それは、デバイスが起動時にコーディネータになるかどうかを示す。ノード記述子のMAC(Media Access Control)機能フラグフィールドの別のPANコーディネータフラグは、現在のZigBee仕様（ZigBee文献053474r20）により「0b0」に設定される。

・論理デバイスタイプ(LDT)フィールドは、長さ8ビットであり、デバイスのタイプを示す、例えば、デバイスが、ZigBeeルータ、ZigBeeコーディネータ又はZigBeeエンドデバイスであるかどうかを示す。それは、ノード記述子の論理タイプフィールドとして実施される。

・許可期間(PD)フィールドは、長さ８ビットであり、参加許可フラグがイネーブルにされるだろう最大秒数を示す。

下の第２表には、以下の実施例の少なくとも１つによって導入又は修正されるパラメータが含まれている。パラメータの実現値（例えば、データタイプBoolean）は、例示的なものでしかなく、他のデータタイプ（例えば、８ビット列挙）を用いることによっても同じ効果が達成されることができ、付加的な条件が組み込まれてもよい。更に、パラメータは、必要に応じて、例えば、ビットフィールド又は列挙に統合され得る。

それらの値の幾つかは、暗黙的に記憶され得る、即ち、他のネットワーク設定パラメータの値及び／又はノードに記憶される情報から導き出され得る。例えば、下のTEMPフィールドにおいてコード化されるステータスは、たとえどんなアプリケーションレイヤ構造がZLL TLメカニズムによって用いられていても、NWK子及び隣接テーブルの両方のステータスを、もしあれば、チェックし、それらのテーブルが全て空である場合には、ネットワークはTEMP_HOOK状態にあると結論することにより、導き出され得る。別の例においては、TCアドレスが「0xff.ff」に設定され、且つ／又は他のネットワークパラメータの設定が非デフォルト値を持つが、設定ステータスがFNのままである（例えば、AIN=false）場合に、一時的ネットワークが決定される。

ここで、上のパラメータの機能を簡単に説明する。

・ネットワーク内アクティブ(AIN)フィールドは、Booleanフラグであり、デバイスがネットワークへのアクティブな参加をしているかどうかを示すだろう。AINフラグがtrueに設定される場合には、デバイスは、そのノーマルな動作状態にあるよう意図され、ネットワークに接続される。AINフラグがfalseに設定される場合には、デバイスは、動作ネットワークの一部ではなく、即ち、如何なるネットワークにも参加しない、又は如何なるネットワークも形成しない。

・Touchlinkサポート(TLS)フィールドは、デバイスがTouchlinkを実施する（即ち、PAN間フレームを送信／受信する）能力を持つかどうかを知らせるBooleanフラグである。この変数は、現在のZigBee仕様には存在しない。

・Touchlink成功(TS)フィールドは、Touchlinkプロシージャが成功したか否かを知らせるBooleanフラグである。この変数は、デフォルト値として「false」を持ち、Touchlinkプロシージャが実行された後に適正値をとるだろう。この変数は、プロシージャが、Touchlinkを通して又はネットワークに対するアソシエーションを通して成功したかどうかを知るためのより後のフェーズに関連する。このフラグは、現在のZigBee仕様には存在しない。

・一時的ネットワーク形成(TEMP)フィールドは、ネットワークが、（例えば、明示的なユーザ操作に応じて）永続的に形成されたのか、又は（例えば、他のネットワーク又はデバイスを全く検出しないスキャンに応じて）一時的に形成されたのかを知らせる列挙である。それは、例えば、NO_NETWORK:ネットワークが形成されていない、TEMP_HOOK：自己形成ネットワークが構築されているが、他のデバイスが参加していない、TEMP_NETWORK：自己形成ネットワークが構築されており、少なくとも１つの他のデバイスが成功のうちに参加している、PERM_NETWORK：永続的ネットワークが形成されている、という値をとり得る。

説明の容易さのために、デバイスが実施すべき試運転ステップは、デバイスのステータス及び能力に応じて、本発明の各々の第１乃至第３実施例によってカバーされる、
・試運転がファクトリーニューなデバイスによって実施される、
・試運転がターゲット（例えば、ルータ）によって実施される、
・試運転がイニシエータによって実施される、
という３つのシナリオに多様化されている。

下の実施例に関しては、イニシエータは、ターゲットノードへの最初のアクセスをトリガ又は開始している無線ノードであると理解される。イニシエータは、他のデバイス（例えば、ターゲットノード）にネットワークに参加させるよう送信されるフレームを生成することができる。

以下の試運転プロシージャの各動作は、上で挙げられているフィールドおよびフラグのうちの少なくとも１つによってとられる値に依存する。第１乃至第３実施例の以下のフローチャートは、デバイスによって実施されるステップの論理シーケンスを規定する。

図３は、ノードがまだネットワークにおいて動作可能ではない場合のための、本発明の第１実施例のフローチャートを示している。

図３のプロシージャは、デバイス（コーディネータ、ルータ、エンドデバイス）が、トリガに応じて、例えば、ファクトリーニューなデバイスの電源が、初めて入れられるとき、若しくはデバイスが試運転を実施するよう、例えば、ボタンを押すなどのユーザ操作により、タイマにより、別に命令されるとき、又は別の内部トリガに応じて、又は特定のメッセージの受信に応じて、又はそのステータスが新しいファクトリー条件に再設定された後、実施する試運転ステップを示している。その後、デバイスの能力に従って、異なる動作がトリガされる。

ステップＳ３００におけるプロシージャの開始後、デバイスのステータスがチェックされる。まず、ステップＳ３０１において、デバイスがファクトリーニューな状態にあるかどうかが、（例えば、上記のAINフラグに基づいて）チェックされる。前記デバイスがファクトリーニューである（AINフラグが「false」に設定されている）場合には、それはステップＳ３０４に進む。

ステップＳ３０１において、前記デバイスがファクトリーニューではないと決定される（例えば、AINフラグが「true」に設定されている）場合には、或る実施例においては、ステップＳ３０２において、TEMPパラメータの値がチェックされる。或る実施例においては、TEMPパラメータが、「TEMP_HOOK」(TH)に設定されている場合には、前記デバイスは、前記デバイスは、やはり、ステップＳ３０４に進み、同時に、参加を可能にするだろう（ステップＳ３０３）。TEMPパラメータが、「TEMP_NETWORK」(TN)に設定されている場合には、前記デバイスは、やはり、ステップＳ３０４に進み、同時に、参加を可能にし得る（ステップＳ３０３）。TEMPパラメータが、「PERM_NETWORK」(ＰN)に設定されている場合には、それは、直接、ステップＳ３１４にジャンプする。別の実施例においては、TEMPパラメータが、「TEMP_NETWORK」(TN)又は「PERM_NETWORK」(PN)に設定されている場合には、既にネットワークに参加しているデバイスの識別をイネーブルにし、検索及びバインディングを可能にするためにステップＳ３１５に進むだろう。第１実施例の変形例においては、それは、図５を参照して記載されているプロシージャに進み得る。別の変形例においては、プロシージャは、常に、あり得る他のデバイスの参加をイネーブルにするためにステップＳ３１４に進む。更に別の変形例においては、プロシージャは、常に、デバイスの検索及びバインディングをイネーブルにするためにステップＳ３１５に進む。

ステップＳ３０４においては、デバイスがエンドデバイスであるかどうかが、（例えば、上記の論理デバイスタイプフィールドに基づいて）チェックされる。肯定の場合、プロシージャは、第１実施例に示されているようなプロシージャが終了するステップＳ３１６にジャンプする。従って、このタイプのデバイスの電源が入れられるときは、第１実施例によるステップを全く実施する必要がない。それは、そのアプリケーションニーズに基づいて、他の動作を実施してもよく、例えば、スキャンを実施してもよく、クラシックな参加を含む別の試運転方法を実施することを試みてもよく、ユーザフィードバックを供給してもよく、又はアクティブなままであってもよく、若しくは直接、例えばユーザ操作を待つ、スリーピースリープモードに入ってもよい。

ステップＳ３０４において、デバイスが、エンドデバイスではなく、従って、ルータ又はコーディネータではないと決定される場合には、ステップＳ３０５において、アクティブスキャンが実施される。アクティブスキャン中、ビーコン要求がブロードキャストされ、これは、どのZigBee又は802.15.4 PAN識別子(PID)が現在用いられているか、どのデバイスがアクティブであるか、及び何がそれらの能力であるかを、アクティブスキャンを実施するデバイスの無線受信機の可聴範囲及びそのチャネルにわたって、決定するために用いられる。オプションとして、どのチャネルが使用中であるかを決定するためにエネルギ検出スキャンが最初に実施され得る。

ステップＳ３０６においては、ステップＳ３０５において実施したスキャンの結果が分析され、プロシージャは、分析結果に応じて分岐する。参加するための適切なネットワークが見つけられない場合には、プロシージャは、ステップＳ３０７に進む。「適切なネットワーク」は、参加デバイスによってサポートされているチャネルのうちの１つにおいて動作可能である、参加を許可する（参加許可フラグが「true」に設定されている）、特定のタイプのデバイス(ZED/ZR)を追加することが可能である、特定のネットワークプロファイル（例えば、ZHA/ZLL）をサポートする、特定のネットワークタイプ（例えば、集中／分散／一時的）をサポートする、特定のデバイスタイプ（コーディネータ、トラストセンター、試運転ツール、ゲートウェイ、 コンセントレータ、マッチングアプリケーションデバイスなど）を含む、という基準のうちの１つ以上を満たすもの（即ち、特定の範囲のデバイスタイプに属するもの）と規定され得る。

参加するための適切なネットワークが見つけられた場合には、デバイスは、ステップＳ３０７において、見つかったネットワークに参加することを試みる。ステップＳ３０７において、参加が成功したと決定される場合には、プロシージャは、第１実施例によるプロシージャが終了するステップＳ３１６にジャンプする。デバイスは、現在のZigBee仕様において規定されているような通常のZigBee動作を実施し得る。ステップＳ３０７において、参加が失敗したと決定される場合には、プロシージャは、ステップＳ３０８に進む（前記失敗は、様々な理由、例えば、ネットワーク容量、セキュリティキー・ミスマッチ、ネットワークタイプ・ミスマッチなどに起因し得る）。

次いで、ステップＳ３０８においては、デバイスがコーディネータになる能力を持つかどうかが、（例えば、上記の論理デバイスタイプフィールド又はコーディネータ対応(CC)フラグに基づいて）チェックされる。ステップＳ３０８において、デバイスがコーディネータになる能力を持つと決定される場合には、プロシージャは、ステップＳ３０９に分岐し、デバイスは、現在ZigBee仕様に記載されているような集中ネットワークを作成し、それは、ネットワーク内アクティブになる。これは、NAフィールドを「0x0000」に設定し、PIDフィールドをスキャンに基づくユニークなPIDに設定し、EPIDフィールドをスキャンに基づくユニークなEPIDに設定し（デフォルトでは、NIB属性「nwkExtendedPANId」が「0x0000000000000000」と等しい場合には、この属性は、MAC定数「macExtendedAddress」の値で、ZigBee仕様、r20、3.2.2.3.3セクタ、303ページ、22乃至25行目に示されているように、デバイス自身のIEEEアドレスに、初期化される）、LCフィールドを、スキャンから導き出される最も良いチャネルに設定し、AINフィールドを「true」に設定することによって、達成され得る。変形例においては、TEMPフィールドがTEMP_HOOKに設定された場合には、前に選択されたネットワーク設定が依然として用いられ得る。オプションとして、どのチャネルが使用中であるかを決定するために、エネルギ検出スキャンが、特にステップＳ３０５においてこれが省かれた場合に、最初に実施され得る。デバイスが、ネットワークのためのトラストセンターになる能力を持つ場合には、TCパラメータが、デバイス自身のIEEEアドレスに設定され、セキュリティ設定が生成及び設定される。変形例においては、TEMPフィールドが、明示的なユーザの要求に応じてではなく、参加するのに適したネットワークが全くないために集中ネットワークが自己形成されたことを示すTEMP_HOOKに設定される。

ステップＳ３０８において、デバイスがネットワークのコーディネータになる能力を持たないと決定される場合には、それは、ステップＳ３１０において、NAフィールドを「0x0000」又は「0xffff」と等しくないランダムな値に設定し、TCフィールドを「0xffffffffffffffff」に設定し、PIDフィールドをスキャンに基づくユニークなPIDに設定し、EPIDフィールドをスキャンに基づくユニークなEPIDに設定することによって、それ自身に分散ネットワークの作成の準備をさせる。更に、セキュリティ設定が、生成及び設定される。変形例においては、TEMPフィールドがTEMP_HOOKに設定された場合には、前に選択されたネットワーク設定が依然として用いられ得る。

ステップＳ３１１においては、試運転プロシージャは、デバイスが、Touchlinkをサポートする能力を持つか、又はこのようなサポートをするよう構成されてはいないかに関するチェック結果に依存して（例えば、上記のTLSフィールドに基づいて）、再び、２つの異なる方向に進む。

ステップＳ３１１において、デバイスが、Touchlink機能のために設定され得ると決定される場合には、ステップＳ３１２において、それは、プライマリZLLチャネル（即ち、2.4GHzにおける１６個の利用可能な802.15.4チャネルの中の１１、１５、２０、２５）のうちの１つ（例えば、スキャンから導き出される最も良いチャネル）を選択し、LCフィールドをこの値に設定し、AINフィールドを「true」に設定するだろう。オプションとして、どのチャネルが使用中であるかを決定するために、エネルギ検出スキャンが、特にステップＳ３０５においてこれが省かれた場合に、最初に実施され得る。変形例のうちの１つにおいては、TEMPフィールドが、参加するのに適したネットワークが全くないために分散ネットワークが自己形成されたことを示すTEMP_HOOKに設定される。

ステップＳ３１１において、Touchlinkがサポートされていないと決定される場合には、ステップＳ３１３において、デバイスは、2.4GHzにおける１６個の利用可能な802.15.4チャネルの中の１つ（例えば、スキャンから導き出される最も良いチャネル）を選択し、LCフィールドをこの値に設定し、AINフィールドを「true」に設定するだろう。オプションとして、どのチャネルが使用中であるかを決定するために、エネルギ検出スキャンが、特にステップＳ３０５においてこれが省かれた場合に、最初に実施され得る。変形例のうちの１つにおいては、TEMPフィールドが、参加するのに適したネットワークが全くないために分散ネットワークが自己形成されたことを示すTEMP_HOOKに設定される。

ステップＳ３１４において、それは、許可期間のための参加許可パラメータを設定することによって、参加をイネーブルにするだろう。PDフィールド値は、デバイスがネットワークに参加することができる時間ウィンドウを制御するよう適応され得る（例えば、１８０秒に対応するPD=0x64）。次いで、それは、ステップＳ３１５において、入力、例えば、他のノードの参加試みを待つだろう。実施例のうちの１つにおいては、ステップＳ３１５においていずれかのデバイスが成功のうちにネットワークに参加した場合には、TEMPフィールドは、TEMP_NETWORKに設定される。デバイスが、Touchlinkを用いて参加する場合には、TSフラグが、TRUEに設定される。更に、ステップＳ３１５の一部として、又は別のステップとして、検索及びバインディング並びに他の設定動作が実施され得る。次いで、ステップＳ３１６において、プロシージャが終了する。

図４は、ターゲットルータがネットワークをサーチしている場合のための、即ち、ネットワークを見つけるターゲットプロシージャのための、本発明の第２実施例のフローチャートを示している。従って、図４の試運転ステップは、ターゲットデバイスによって、ネットワークを発見し、参加するために実施される。

プロシージャは、ステップＳ４００において開始する。ステップＳ４０１においては、デバイスが「false」に設定されているAINフラグを持つどうかが、チェックされる。否定の場合、プロシージャは、参加許可フラグが３分間の許可期間の間「true」に設定されるステップＳ４０８にジャンプする（即ち、PDフィールドが「0x64」に設定される）。次いで、ステップＳ４１０において、検索及びバインディングプロシージャが開始し得る。

ステップＳ４０１において、AINフィールドが「false」に設定されており、従って、デバイスがネットワーク内アクティブではないと決定される場合には、図３のステップＳ３０２に対応するステップＳ４０２が実施される。次いで、ステップＳ４０３において、スキャンプロセスの間にオープンネットワークが見つけられたかどうかが、チェックされる。ステップＳ４０２におけるスキャンがオープンネットワークの存在を明らかにする場合には、プロシージャはステップＳ４０５に進み、デバイスは、NAフィールドを新しいアドレスに設定し、PIDフィールドを新しいPIDに設定し、EPIDフィールドを新しいEPIDに設定し、LCフィールドを新しいチャネルに設定し、AINフィールドを新しい「true」に設定することによって、検出されたネットワークに対して参加プロシージャを試み、アソシエートする。更に、PDフィールドは、ZigBee・ホーム・オートメーション仕様による推奨EZModeTimeと等しい値である３分に設定され得る。

次いで、ステップＳ４０７において、デバイスの、発見されたネットワークに対するMACアソシエーションが成功したかどうかが、チェックされる。肯定の場合、ステップＳ４０９において、セキュリティキー情報が交換され、ステップＳ４１０においてプロシージャが終了する前のステップＳ４１０において、検索及びバインディングプロシージャが実施され得る。

ステップＳ４０３において、ステップＳ４０２におけるスキャンプロセスは如何なるオープンネットワークの存在も明らかにしなかったと決定される場合には、ステップＳ４０４において、CCフラグが「true」に設定されているかどうか、即ち、デバイスがコーディネータ機能を持つかどうかが、チェックされる。肯定の場合、プロシージャは、ステップＳ４０６に分岐し、PIDフィールドをスキャンに基づくユニークなPIDに設定し、EPIDフィールドをスキャンに基づくユニークなEPIDに設定し、LCフィールドを、スキャンから導き出される最も良いチャネルに設定し、AINフィールドを「true」に設定することによって、ネットワークが作成される。次いで、プロシージャは、ステップＳ４０８に進み、３分間の許可期間の間、参加許可パラメータを「true」に設定することによって、参加をイネーブルにする（即ち、PDフィールドが「0x64」に設定される）。最後に、ステップＳ４１０の検索及びバインディングプロシージャが実施され、ステップＳ４１１においてプロシージャが終了する。

他方で、ステップＳ４０４において、デバイスがコーディネータの役割を果たす能力を持たない（即ち、CCフィールドが「false」に設定されている）と決定される場合には、ネットワークは作成されず、プロシージャは、直接、許可期間が３分間（即ち、１８０秒間）に設定されるステップＳ４０８に進む。ステップＳ４０７においてアソシエーションが成功していないと決定される場合には、同じ動作が実施される。

図５は、イニシエータノード又はデバイスがネットワークをサーチする場合のための、即ち、ネットワークを見つけるためのイニシエータプロシージャのための、本発明の第３実施例のフローチャートを示している。このプロシージャは、イニシエータデバイスの、そのノーマルな動作状態に入るステップを記述している。

プロシージャは、ステップＳ５００において開始する。次いで、ステップＳ５０１において、デバイスがTouchlinkをサポートするかどうかが、チェックされる。肯定の場合、デバイスは、ステップＳ５０２において、イニシエータの役割でTouchlinkプロシージャを開始することを試みる。次のステップＳ５０３において、Touchlinkプロシージャが成功したと決定される場合には、ステップＳ５０４において、TS及びAINフラグが「true」に設定される。それによって、ネットワークが作成され、前記ネットワークは分散タイプのものである。次いで、プロシージャは、ステップＳ５１４において終了する。

ステップＳ５０１において、デバイスはTouchlinkプロシージャをサポートしないと決定される場合には、又はステップＳ５０３において、Touchlinkをする試みは失敗したと決定される場合には、プロシージャは、フラグAINの値がチェックされるステップＳ５０５に進む。ステップＳ５０５において、AINフラグが「true」に設定されていると決定される場合には、プロシージャは、デバイスが、ルータの場合に、その参加許可を「true」に設定し、オプションとして、１８０秒と等しいPDパラメータを備えるプリミティブ Mgmt_permit_joiningをブロードキャストするステップＳ５１３に分岐する。次いで、ステップＳ５１２において、検索及びバインディングプロシージャが開始される。第１実施例の場合と同様に、挙動は、TEMP変数の設定に依存して、更に異なり得る。

ステップＳ５０５において、AINフラグが「false」に設定されていると決定される場合には、デバイスが、ステップＳ５０６において、アソシエートするのに適したネットワークを見つけるために、（図３のステップＳ３０２及び図４のステップＳ４０２と同様に）アクティブスキャンを実施する。

次いで、ステップＳ５０７において、適切なネットワークが見つけられたかどうかが、チェックされる。適切なネットワークの定義は、図３に関するステップＳ３０６において示されている。肯定の場合、例えば、スキャンの結果が、「true」に設定されている参加許可フラグを持つネットワークを返す場合には、デバイスは、ステップＳ５０８において、MACアソシエーションを介してネットワークに参加しようとする。

次いで、ステップＳ５０９において、デバイスの、発見されたネットワークに対するアソシエーションが成功したかどうかが、チェックされる。肯定の場合、デバイスは、アソシエーション中に得られるネットワーク設定パラメータ（例えば、チャネル、PANID、EPID）を設定し、セキュリティキー情報が交換され、AINフィールドが「true」に設定され、故に、デバイスは、ステップＳ５１１においてネットワーク内アクティブになり、ステップＳ５１４においてプロシージャが終了する前のステップＳ５１２において（例えば、識別及び／又は発見コマンドの送信をイネーブルにすることによって）、検索及びバインディングプロシージャが開始され得る。

ステップＳ５０９において、MACアソシエーションが失敗したと決定される場合、又はステップＳ５０７において、適切なネットワークが見つからなかったと決定される場合、ステップＳ５１０において、デバイスがネットワーク作成能力を持つかどうかが、（例えば、論理デバイスタイプ又はCCに基づいて）決定される。否定の場合、第３実施例のプロシージャはステップＳ５０５において終了する。デバイスは、そのアプリケーションニーズに基づいて、他の動作を実施してもよく、例えば、別の試運転方法を実施することを試みてもよく、ユーザフィードバックを供給してもよく、又はアクティブなままであってもよく、若しくは直接、例えばユーザ操作を待つ、スリーピーモードに入ってもよい。デバイスがネットワーク作成能力を持つ場合には、デバイスは、（第１実施例のステップＳ３０４乃至Ｓ３１０に記載されているように）ステップＳ５１５においてネットワークを作成するだろう。エネルギ検出スキャンがこれに先立ち得る。次いで、ステップ５１４において、第３実施例のプロシージャが終了する。

上記のプロシージャに関して、以下のことに注意されたい。

ライト・リンクデバイスのための現在の仕様は、６０秒間というネットワークに参加するための推奨最短時間を規定しているが、ＥＺモードによれば、許可期間は、１８０秒間に設定されるべきである。この現在のギャップを埋め、相互運用を可能にするために、本発明の実施例の試運転プロシージャにおいては、他のデバイスがネットワークに参加することを許可したい各デバイスがその許可期間を１８０秒間に設定することが提案されている。

同様にして、デバイスとそれらの制御アプリケーションとの間の関係の確立（即ち、バインディング）のために、デバイスは、識別クエリコマンド（識別クラスタ）をブロードキャストしてもよく、１８０秒間に等しい識別クラスタにおける識別時間属性を設定してもよい。

図６は、第４実施例による、上記の第１乃至第３実施例が実施され得るネットワークアーキテクチャのブロック図を示している。

図６に示されているように、上記の第１乃至第３実施例は、形成中である無線ネットワーク６００において動作し得る。この無線ネットワーク６００においては、ノード６０１は、ノード６０１が制御することができる別のデバイス、例えば、照明器具６０２又は他の照明デバイスに取り付けられ得る。

ノード６０１は、説明のために、図６において、詳細なように、従って、他のノードと比べて相対的に大きなサイズの描写で示されている。制御される照明器具６１２、６３２及び６４２を備える他のノード６１１、６３１及び６４１は、ノード６０１と構造的に同一であり得ることに注意されたい。

更に、図６のノードは、照明器具以外の異なる種類のデバイスにリンクされ得る。例えば、ノード６２１は、他のノードを無線制御するために用いられ得るスイッチであり得る。示されてはいないが、これらのノードは、温度制御パネル、暖房、換気及び空調(HVAC)デバイス、計器、センサ、又は任意の他の家若しくはビルのオートメーションデバイスのような他のアクチュエータであってもよい。

ノード６０１は、例えば、図３乃至５のプロシージャのうちの少なくとも１つに従うノード６０１の挙動を指定するソフトウェアを記憶し得るメモリ６０１１に結合されるコントローラ６０１０を有する。コントローラ６０１０は、照明器具６０２に対するコマンドを生成するドライバ６０１２、及び将来のネットワーク６００の残りのものとの無線通信を確実にするだろう送信機６０１３にも結合され得る。エネルギは、バッテリ（図示せず）によって若しくは電源を通して、又はエネルギ・ハーベスタ（ソーラーパネル、ユーザ駆動スイッチなど）によって、ノードに供給され得る。

他の実施例に関連して説明したように、ノード６０１のコントローラ６０１０は、考慮されるシナリオに依存して、異なる挙動をし得る。ノード６０１の電源投入時、ノード６０１のコントローラ６０１０は、エリア内のチャネルの占有状態をチェックするために、又は参加すべき近傍ネットワークが存在するかどうかをチェックするために、アクティブスキャンを開始するだろう。アクティブスキャンは、無線ノード６０１の送信機６０１３によって操作される。

他の動作は、デバイスのCC能力に依存する。コントローラ６０１０は、ノード６０１が、コーディネータ又はルータになる能力を持つかどうかを、メモリ６０１２においてチェックすることができる。他の例においては、ノード６０１は、すぐに、その能力に対応するプロシージャを走らせることができる。ノード６０１が、コーディネータになることができる場合には、コントローラ６０１０は、トポロジがこの能力の結果であるネットワークの作成を開始するだろう。ここでは、ノード６０１はコーディネータであることから、ノード６０１にネットワーク６００についての権限を与える集中ネットワークのトポロジが選択される。次いで、近傍のあらゆる参加ノードが、作成されたネットワークに参加することができ、試運転のプロセスを簡単にする。

上記の実施例によれば、デバイス又はノードは、その、ネットワークを作成する又は参加する及び近傍の任意の他のデバイスと制御関係を確立する能力によって、あらゆる可能な方法を試みることができる。それを達成するため、利用可能なネットワークが検出されない場合、ノードは、（ネットワークを作成する能力は持つが）たとえネットワークを作成するよう設定されていなかったとしても、ネットワークを作成する責任を負うだろう。その場合、作成されるネットワークは、そのイニシエータの能力の結果である特性を持つだろう。例えば、コーディネータノードは、集中ネットワークを作成するだろうが、コーディネータ機能のないルータノードは、分散ネットワークを作成するだろう。

上記の実施例によれば、コーディネータの挙動のための２つのシナリオ、即ち、前のネットワーク設定が記憶されていない場合の電源投入時に又はファクトリーニューなときに必ずネットワークを作成する、現在のZigBee仕様において意図されているようなコーディネータ、及び集中又は分散ネットワークのいずれかを検出する場合に集中又は分散ネットワークに参加する能力を備えるコーディネータが、提案されている。直接の結果として、CCフラグは、これらの２つの場合において異なる意味を持つ（又は他の例においては、第２の場合のために、（例えば、形成させるための）別のフラグが追加され得る）。

従来のコーディネータの挙動の上記の第１の場合においては、前のネットワーク設定が記憶されていない場合の電源投入時に又はファクトリーニューなときに、CCフラグが「true」に設定されている場合には、それは、デバイスにネットワークを作成させる。デバイスは、ただ、選ばれたネットワークのパラメータのユニーク性をチェックするために、スキャンを実施する。しかしながら、他のネットワークを探す又はそれらに参加する試みはない。

特別な能力を備えるコーディネータの上記の第２の場合においては、前のネットワーク設定が記憶されていない場合の電源投入時に又はファクトリーニューなときに、CCフラグが「true」に設定されている場合には（又はオプションとして、別のフラグが「false」に設定されている場合には）、デバイスは、まず、任意の適切なネットワークのためにスキャンする。「適切なネットワーク」という用語の定義は、図３のステップＳ３０６のところに示されている。何か適切なネットワークが検出される場合には、コーディネータは、ネットワークに対してアソシエートすることを試みる。「true」に設定されているCCフラグは、ネットワークが検出されなかった場合又は他のネットワークに対するアソシエーションが失敗した場合（又は別のフラグが「false」に設定されている場合）にのみ、デバイスがネットワークを作成することを可能にする。CCフラグが「false」に設定されている場合（又はオプションとして、別のフラグが「true」に設定されている場合）には、それは、デバイスにネットワークを作成させる。

ルータによって作成されたネットワークは、もう１つのデバイスが成功のうちに参加するプロシージャを実施するまで、「一時的な」ネットワークであるよう意図される。許可期間が満了する前に参加することを試みるデバイスがない場合には、ルータは、一時的なネットワークの状態のままであってもよく、又は参加するために利用可能なネットワークのために新しいスキャンを実施し、スキャンに成功したら、検出されたネットワークに参加しようとしてもよい。

更に、ファクトリーニューなデバイスの場合は、AINフラグが「true」に設定されているかどうかをチェックすることは、必要とされないかもしれない。なぜなら、そのデフォルト値は「false」と規定されているからである。あらゆる他の異なる場合には、デバイスが、既に、ネットワークに参加しているか又はネットワークを作成しているかどうかを識別するために、プロシージャの開始時にAINフラグの値をチェックすることは必要である。

更に、ファクトリーニュー／非ファクトリーニューの識別は、図４及び５の各々のフローチャートの開始時の、第２及び第３実施例のAINをチェックするステップに組み込まれ得る一方、イニシエータ又はターゲットに関する識別は、Touchlinkプロシージャをサポートするデバイスためだけに利用され得る。

更に、ファクトリーニューなデバイスは、必ず、「false」に設定されているAINフラグを持つが、NFNデバイスは、必ずしも、「true」に設定されているAINフラグを持たないかもしれないことに注意されたい。AINフラグのステータスは、ネットワークを作成すると又は認証フェーズを達成すると、変化する。しかしながら、デバイスがネットワークを離脱する又は孤立ノードになるような状況もある。それに対処するために、幾つかのソリューションが考えられる。一例として、AINフラグが、「有効なネットワーク設定を持っている」と解釈され得る。これは、現在の第１実施例と整合性が取れている。このような場合には、孤立ノードは、AINフラグのステータスを変更しないだろう。他の例においては、AINフラグが、「ネットワークにおいて通信することができる」と解釈されることができ、即ち、例えば、親の喪失／離脱時に、「false」に再設定されることができ、新しい参加／再参加が成功のうちに実施されると、最終的に「true」に再設定されることができる。このような場合には、デバイスは、AINフラグの状態だけでなく、記憶されている他のネットワークパラメータの値にも基づいて、試運転動作を決定しなければならないだろう。更に別の実施例においては、これ、例えば、「ファクトリーニュー」、「非ネットワーク接続」、「ネットワーク内アクティブ」などを示すために、AINパラメータに付加的な値が付加され得る。

その上、TEMPパラメータの値が、例えば、Touchlinkの実施時にも、デバイスの試運転の挙動に更に影響を及ぼし得る。例えば、ZLLターゲットが、TEMP_NETWORKに設定されているTEMPフィールドを持ち、ネットワークが、分散ネットワークであり、且つそれがTouchlinkを実施しているZLLイニシエータが、ファクトリーニューである場合には、ZLLターゲットは、イニシエータが新しいネットワーク設定を作成することを許可するのではなく、そのネットワークにイニシエータを引き入れることを決定し得る。これは、例えば、PAN間Touchlink交換において、ZLL試運転クラスタの走査要求／応答コマンドのZLL情報フィールドのZLLイニシエータ・サブフィールドを「0b1」に設定すると共に、ZLL試運転クラスタの走査要求コマンドのZLL情報フィールドのファクトリーニュー・サブフィールドを「0b1」に設定し、ZLL試運転クラスタのネットワーク参加エンドデバイスコマンドフレームの各々のフィールドにおける自己確立ネットワーク設定を送信することによって、又はPAN間Touchlink交換において、ZLL試運転クラスタの走査応答コマンドのZLL情報フィールドのZLLイニシエータ・サブフィールドを「0b0」に設定すると共に、ZLL試運転クラスタの走査要求コマンドのZLL情報フィールドのファクトリーニュー・サブフィールドを「0b1」に設定し、ZLL試運転クラスタのネットワーク開始応答コマンドフレームの各々のフィールドにおける自己確立ネットワーク設定を送信することによって、達成され得る。別の例においては、例えば、ZLLターゲットが、TEMP_NETWORKに設定されているTEMPフィールドを持ち、ネットワークが、分散ネットワークであり、且つそれがTouchlinkを実施しているZLLイニシエータが、ファクトリーニューではない場合には、ZLLターゲットは、デバイスのそのTEMP_NETWORKネットワークを試みた後に、イニシエータのネットワークに参加することを決定し得る。これは、例えば、自己確立ZigBeeネットワークにわたってZLL試運転クラスタのネットワークアップデート要求コマンドを送信することによって、達成され得る。

一時的な自己形成ネットワークも、802.15.4 MACビーコンのZigBeeペイロードにおいて送信されるネットワークパラメータのうちの１つ、例えば、EPIDを、所定の値に設定することによって、参加候補のものに認識可能にされ得る。（CTをベースにした試運転ネットワークを識別するのと同じメカニズムが用いられ、そこではEPID：00-50-c2-77-10-00-00-00が用いられ、この範囲（00-50-c2-77-10-00-00-01-00-ff-ff）内の他のEPID値は、他の試運転使用のために予約される。）

（ホーム）ネットワークの分散特性は、802.15.4 MACビーコンのZigBeeペイロードにおいて送信される「デバイス深度」パラメータのうちの１つを、所定の値、例えば0xfに設定することによって、参加候補のものに認識可能にされ得る。「デバイス深度」は、分散ネットワークにおいては無意味である。なぜなら、ルートとして用いられるべき中央デバイスがなく、（１５ホップを示す）この値は、集中ホームネットワークにおいては、多くの場合、見られそうにないからである。

更に、デバイスが特定のプロシージャステップ（例えば、ネットワーク形成、検索及びバインディング）に直接ジャンプすることを可能にするデバイスにおける他のトリガがあり得る。

要約すると、無線ノード及び前記無線ノードを動作させる方法であって、前記無線ノードが、前記無線ノードの能力を決定し、ネットワークを作成するよう、少なくとも１つの他の無線ノードと無線通信するよう構成されるコントローラを有し、前記ネットワークの特性が、決定される前記無線ノードの能力に依存する、無線ノード及び前記無線ノードを動作させる方法について記載されている。

様々な実施例によるネットワークシステムの構成要素の上記の動作は、コンピュータプログラムのプログラムコード手段として、及び／又は専用ハードウェアとして実施され得る。更に詳細には、図３乃至５において示されているもののような上記のプロシージャは、コンピュータプログラムのプログラムコード手段として、及び／又は専用ハードウェアとして実施され得る。コンピュータプログラムは、他のハードウェアと一緒に又は他のハードウェアの一部として供給される光記憶媒体又は固体媒体などの適切な媒体に分散及び／又は記憶されてもよいが、インターネット又は他の有線若しくは無線電気通信システムを介するなどの他の形態で配信されてもよい。

本発明を、図面において図示し、上記の説明において詳細に説明しているが、このような図及び説明は、説明的なもの又は例示的なものとみなされるべきであって、限定するものとみなされるべきではない。本発明は、負荷デバイスとしてランプ又は照明器具を備える開示されている実施例に限定されない。本発明は、あらゆるタイプの負荷、センサ、スイッチなどに関連して実施され得る。

請求項に記載の発明を実施する当業者は、図面、明細及び添付の請求項の研究から、開示されている実施例に対する他の変形を、理解し、達成し得る。請求項において、「有する」という用語は、他の要素又はステップを除外せず、単数形表記は、複数性を除外しない。請求項において列挙されている幾つかのアイテムの機能を、単一のプロセッサ又は他のユニットが実現してもよい。単に、特定の手段が、相互に異なる従属請求項において引用されているという事実は、これらの手段の組み合わせが有利になるように用いられることができないことを示すものではない。

上記の説明は、本発明の或る特定の実施例を詳述している。しかしながら、上記のものが、いかに詳細に文に示されていても、本発明は、多くの方法で実施されることができ、それ故、開示されている実施例に限定されないことは、理解されるだろう。本発明の或る特徴又は態様の説明時に特定の用語を用いていることは、前記用語が、その用語が関連する本発明の特徴又は態様の何らかの特定の特性を含むよう限定されるよう本願明細書において再定義されていることを意味すると解釈されるべきではないことに、留意されたい。

単一のユニット又は装置が、請求項に列挙されている幾つかの要素の機能を実現してもよい。単に、特定の手段が、相互に異なる従属請求項において引用されているという事実は、これらの手段の組み合わせが有利になるように用いられることができないことを示すものではない。

Claims (8)

1. 無線ノードの形態の装置であり、前記装置が、少なくとも１つの他の無線ノードと無線通信するためにコントローラを有し、前記コントローラが、前記無線ノードの近くに特定の種類の少なくとも１つの他のノードがあるかどうかを検出するよう適応される装置であって、前記コントローラが、更に、
   前記無線ノードの能力であって、前記無線ノードが、ネットワーク形成機能を持つかどうか及びどんな種類のネットワーク形成機能を持つかに関する能力を決定し、
   ネットワークを作成するために前記無線ノードを設定するよう適応され、前記ネットワークの特性が、決定される前記無線ノードの能力に依存し、前記コントローラが、
   前記無線ノードがルータデバイスであると決定され、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合に、分散ネットワークを作成するために、又は
   前記無線ノードがコーディネータ機能を持つと決定され、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合に、集中ネットワークを作成するために、前記無線ノードを設定する装置。
2. 無線ノードを動作させるための方法であって、前記方法が、
   （ａ）前記無線ノードのコントローラによって、前記無線ノードの能力であって、前記無線ノードが、ネットワーク形成機能を持つかどうか及びどんな種類のネットワーク形成機能を持つかに関する能力を決定するステップと、
   （ｂ）前記コントローラによって、前記無線ノードの近くに特定の種類の少なくとも１つの他のノードがあるかどうかを検出するステップと、
   （ｃ）前記コントローラによって、ネットワークを作成するために前記無線ノードを設定するステップとを有し、前記ネットワークの特性が、決定される前記無線ノードの能力に依存し、前記コントローラが、
   前記無線ノードがルータデバイスであると決定され、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合に、分散ネットワークを作成するために、又は
   前記無線ノードがコーディネータ機能を持つと決定され、前記無線ノードの近くで前記特定の種類の他のノードが検出されない場合に、集中ネットワークを作成するために、前記無線ノードを設定する方法。
3. 前記コントローラが、前記無線ノードが特定の試運転プロシージャに従って動作することができるかどうかを決定し、前記作成するステップにおいて、前記無線ノードが前記特定の試運転プロシージャに従って動作することができる場合には、作成される前記ネットワークが、第１プロファイルの分散ネットワークである請求項２に記載の方法。
4. 前記特定の試運転プロシージャが、Touchlinkであり、前記第１プロファイルが、ZigBee・ライト・リンクである請求項３に記載の方法。
5. 前記方法が、前記コントローラによって適切なネットワークをサーチするステップを更に有し、前記適切なネットワークが、参加デバイスによってサポートされているチャネルのうちの１つにおいて動作可能なネットワーク、参加を許可するネットワーク、特定のタイプのデバイスを追加することが可能なネットワーク、特定のネットワークプロファイルをサポートするネットワーク、特定のネットワークタイプをサポートするネットワーク、又は特定のデバイスタイプを含むネットワークである請求項３又は４に記載の方法。
6. デバイスが一時的なネットワークを形成する場合には、再び試運転を実施するときに、それが、別のネットワークに参加し得ること、又は２つ以上のデバイスから成る一時的なネットワークにおいてTouchlinkが実施される場合には、ファクトリーニューなデバイスが、新しいネットワークを形成するのではなく、前記一時的なネットワークに参加するよう命令され得ることを更に有する請求項２乃至５のいずれか一項に記載の方法。
7. 前記特定の種類の少なくとも１つの他のノードが、コーディネータノード、トラストセンターの役割、ネットワークマネージャーの役割、ゲートウェイの役割、コンセントレータの役割、特定のアプリケーションの機能を持つアプリケーションデバイス、又はZLLイニシエータノードである請求項６に記載の方法。
8. コンピュータデバイス上で走らせるときに請求項２乃至７のいずれか一項に記載のステップをもたらすためのコード手段を有するコンピュータプログラム。

Images