(57)【特許請求の範囲】
【請求項１】
少なくとも１つの第１の互換性のあるコミッショニングプロセスを定義する第１のアプリケーションプロファイルの参加ノードを、前記第１のコミッショニングプロセスとは異なる第２のコミッショニングプロセスを定義する第２のアプリケーションプロファイルに従って動作する他のノードを含むネットワーク内で動作するよう構成するためのコミッショニング装置であって、前記コミッショニング装置は、前記第１のプロファイルに対応する前記第１のコミッショニングプロセスをエミュレートし、前記コミッショニング装置は、ZigBee（登録商標） Light Link（ＺＬＬ）デバイスがタッチリンクコミッショニングプロセスに従って参加することを許容し、前記コミッショニング装置は、イニシエータとして動作し、集中型ネットワークパラメータをコピーして、ＺＬＬコミッショニングクラスタコマンド内でそれらを再翻訳し、前記コミッショニング装置は、さらに、前記集中型ネットワークパラメータ又はネットワークキーを送信する前にトラストセンターデバイスの承認を求めるための、前記参加ノードについて前記トラストセンターデバイスと通信するための送信機を含む、コミッショニング装置。
【請求項２】
前記第１のプロファイルは、ユーザー選択、検出、前記コミッショニング装置によって発見された前記参加ノードの能力のうちの少なくとも１つに基づき選択される、請求項１に記載のコミッショニング装置。
【請求項３】
前記コミッショニング装置は、サポートされる複数のコミッショニング方法を所定の順番で試みる、請求項１又は２に記載のコミッショニング装置。
【請求項４】
前記コミッショニング装置は、ZigBee（登録商標） Light Linkタッチリンク通信を、従来のZigBee（登録商標）コミッショニング通信に変換する、請求項１に記載のコミッショニング装置。
【請求項５】
前記参加ノードのリクエスト若しくはレスポンスを、前記第１のプロファイルのプロトコルから前記第２のプロファイルのプロトコルに変換するための、又は、前に取得された情報に基づきリクエスト若しくはレスポンスを生成するためのプロセッサをさらに含む、請求項１乃至４のいずれか一項に記載のコミッショニング装置。
【請求項６】
前記コミッショニング装置は、前記第１のプロファイルのデバイスに対して第１の機能を、前記第２のプロファイルのデバイスに対して第２の機能を提供し、前記コミッショニング装置は、前記参加ノードの能力を決定し、当該決定の結果に基づき適切なコミッショニング方法を選択する、請求項１乃至５のいずれか一項に記載のコミッショニング装置。
【請求項７】
前記コミッショニング装置は、分散型ネットワーク上で動作する場合、集中型ネットワーク上のコーディネータのふりをし、従来のZigBee（登録商標）デバイスによって期待される方法で保護されたネットワークキーを供給する、請求項１乃至６のいずれか一項に記載のコミッショニング装置。
【請求項８】
前記コミッショニング装置は、前記決定の結果に基づきセキュリティキーを決定する、請求項６に記載のコミッショニング装置。
【請求項９】
前記コミッショニング装置は、前記参加ノードへの返信を止めることにより、前記ネットワークに参加又は再参加するようルーターデバイスに指示する、請求項１乃至８のいずれか一項に記載のコミッショニング装置。
【請求項１０】
前記コミッショニング装置は、前記ネットワークのデバイスに関する情報を集め、内部データ構造内に保存する、請求項１乃至９のいずれか一項に記載のコミッショニング装置。
【請求項１１】
前記コミッショニング装置は、単純記述子リクエストＺＤＯコマンドをユニキャストすること、ローカルデバイスから単純記述子リクエストコマンドを受信した際、他のデバイスの発見情報を供給すること、識別クエリコマンドをブロードキャストすること、エンドポイントからの識別クエリレスポンスを処理すること、新規デバイスの参加成功について前記ネットワーク内の他のノードに通知すること、タッチリンクコミッショニングによって前記ネットワークに参加したデバイスの情報能力について前記ネットワーク内のトラストセンターに通知すること、前記ネットワークへの接続が失われたデバイスの再関連付けを可能にするために、再参加リクエストコマンドを処理し、再参加レスポンスコマンドを発すること、コミッショニング動作の成否についてユーザーに通知すること、及び接続が失われた場合のより容易な再参加プロセスを可能にするために、デバイスをコミッショニングするのに使用された方式を記録し、この情報を保持することのうちの少なくとも１つを実行する、請求項１乃至１０のいずれか一項に記載のコミッショニング装置。
【請求項１２】
第１の互換性のあるコミッショニングプロセスを定義する第１のアプリケーションプロファイルの参加ノードを、前記第１のコミッショニングプロセスとは異なる第２のコミッショニングプロセスを定義する第２のプロファイルに従って動作する他のノードを含むネットワーク内で動作するよう構成するためのコミッショニング方法であって、前記方法は、前記ネットワーク内にコミッショニング機能を提供するステップと、前記コミッショニング機能を使用して、前記第１のプロファイルに対応する前記第１のコミッショニングプロセスをエミュレートするステップとを含み、前記コミッショニング機能は、ZigBee（登録商標） Light Link（ＺＬＬ）デバイスがタッチリンクコミッショニングプロセスに従って参加することを許容し、前記コミッショニング機能は、イニシエータとして動作し、集中型ネットワークパラメータをコピーして、ＺＬＬコミッショニングクラスタコマンド内でそれらを再翻訳し、前記コミッショニング機能は、前記集中型ネットワークパラメータ又はネットワークキーを送信する前にトラストセンターデバイスの承認を求めるために、前記参加ノードについて前記トラストセンターデバイスと通信する、コミッショニング方法。
【請求項１３】
請求項１乃至１１のいずれか一項に記載のコミッショニング装置を含む、ネットワークデバイス。
【請求項１４】
コンピュータデバイス上で実行されたとき、請求項１２のステップを発生させるためのコード手段を含む、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コミッショニング方法、ネットワーク内のノードをコミッショニングするための装置、及びかかる装置を含むネットワークの分野に関する。特に、かかる装置は、それぞれが対応するコミッショニング方式を要求する異なるプロトコルプロファイルを使用するノードをコミッショニング可能であり得る。例えば、（集中型／分散型）ネットワークのトポロジーは、ノードのプロトコルプロファイルに依存するため、コミッショニングをプロトコルプロファイルの違いに適合させる必要がある。
【背景技術】
【０００２】
ホームオートメーション及びビルオートメーションは、無線ネットワークを利用する。過去数年間、様々な種類のネットワークが提案及び使用されてきた。一例として、ZigBee（登録商標）は、低コストかつ低電力な無線メッシュネットワーク規格である。低コストは、当該技術が無線制御及び監視アプリケーションに幅広く展開されることを可能にする。低消費電力は、より小さい電池でのより長い寿命を可能にする。ZigBee（登録商標）は、IEEE 802.15.4規格に基づく。低電力ではあるものの、より遠くのデバイスに到達するために、ZigBee（登録商標）デバイスはしばしば中間デバイスを介してデータを伝達することによってデータを長距離送信し、メッシュネットワーク（すなわち、全てのネットワークデバイスにアクセス可能な高電力送信機／受信機が存在しないネットワーク）を作成する。かかる無線アドホックネットワークは、その分散性のため、中央ノードに依存することができないアプリケーションに適している。
【０００３】
アプリケーション同士が通信するには、同じネットワークに参加可能でなければならず、すなわち、例えばネットワークＩＤ、動作チャネル、セキュリティキー等のネットワーク動作パラメータによって構成されなければならない。コミッショニング（プロセス）とも呼ばれる、これらのパラメータの交換の強制的な又は任意の方法は、いわゆるアプリケーションプロファイル内に定義される。さらに、バインディング、すなわち、あるデバイスに、制御データが他のデバイスに送信されるべきこと及び／又は制御データを他のデバイスから受信すべきことを伝えるアプリケーションレベル制御関係は、デバイスの入出力データフローに関連付けられた入出力クラスタＩＤをマッチングすることによって決定される。バインディングテーブルは、ソース／ディストネーションのペアを含む。ZigBee（登録商標）は、ZigBee（登録商標） PRO及びZigBee（登録商標）の２つのフィーチャセットとして入手可能であり、これらは、ZigBee（登録商標）メッシュネットワークの動作方法を定める。最も広く使用されている仕様であるZigBee（登録商標） PROは、低消費電力、及び数千のデバイスを有する大規模ネットワークのサポートのために最適化されている。ZigBee（登録商標） PROは、同じエリア内に共存可能なアプリケーションプロファイルをいくつか提案する。しかしながら、現時点では、異なるプロファイルからのノードが単一のネットワークを形成することを阻害するいくつかの不適合性が存在する。
【０００４】
本明細書では、これらは同じ市場空間、すなわち消費者市場で競合するので、複数のZigBee（登録商標）パブリックアプリケーションプロファイルのうちの２つについてより詳細に述べる。ZigBee（登録商標） Home Automation（ＺＨＡ）は、消費者の快適さ、利便性、セキュリティ、及びエネルギー管理を向上させる、よりスマートな家を構築することを助ける国際工業規格である。また、ZigBee（登録商標） Light Link（ＺＬＬ）は、相互運用可能で、非常に使いやすい消費者照明及び制御製品のための国際標準を照明産業に与える。ＺＬＬは、消費者がタイマー、リモコン、及びスイッチを使用して全てのＬＥＤ照明器具、電球を無線制御することを可能にする。ＺＨＡプロファイルデバイス及びＺＬＬプロファイルデバイスによって、象徴的な相互運用性の無いケースが提示される。ここでの主な相違点は、関与するプロファイルの性質の違いである。つまり、ＺＨＡは、ネットワーク参加プロセスを集中管理する中央コーディネータを中心に構築される一方、ＺＬＬデバイスは、いわゆる「タッチリンク」機構を利用して、ローカルに構成要素を追加し及び照明ネットワークを管理する分散型ネットワークとして動作することができる。
【０００５】
特定の据え付けの要求を満たすようデバイス及びネットワークを構成するタスクは、コミッショニングとして知られている。最も広義の意味では、コミッショニングは、無線及び物理的環境の調査、デバイスの配置、パラメータの構成、アプリケーションバインディング、ネットワーク及びデバイスパラメータの最適化、並びに正常運転の試験及び確認を含む、様々なタスクを包含する。しばしば、設置者の技術及びワークフロー実践、デバイスの識別容易性及びアクセサビリティ、並びに他の無線又は有線システムとの相互運用性及び共存等、非技術的及び準技術的問題を考慮する必要がある。多くの場合、コミッショニングに関する考慮事項は設置者に向けられるが、開発及び試験、並びに実地試験中にZigBee（登録商標）システムを容易に構成及びコミッショニング可能であることも、開発及び市場への製品供給を大きく加速させ得る。また、コミッショニングの容易さは、ＤＩＹ消費者市場にとっても重要である。
【０００６】
より具体的には、コミッショニングプロセスは、ネットワーク作成、参加／アクティブネットワークの発見、アドレス割り当て、セキュリティキー交換、デバイス間での発見及びバインディング、並びに（例えば、報告間隔等の）アプリケーション層構成を含む、様々なステップを含み得る。
【０００７】
ZigBee（登録商標）Allianceでは、３つの異なるコミッショニングモードが一般的に論じられている。第１のＡモード（自動モード）は、デバイスの自動コミッショニングを含む。Ａモードは、一般的に、最小の人間による介入を（又は人間による介入が無いことを）可能にする。第２のＥモード（イージーモード）は、ボタン又はデバイス上の他の物理的機構を使用して、コミッショニング中にデバイスに指示を出すことを含む。Ｅモードは、エンドユーザー又は専門の設置者による単純なコミッショニングを可能にする。Ｅモードは、通常、小さい設備（サイズ：典型的な家）を対象とする。第３のＳモード（システムモード）は、外部ツールの使用を含み、通常、専門の設置者によって使用される。Ｓモードは、最も複雑なコミッショニング形態であり、最も高度な人間による介入を有する。Ｓモードは、通常、商業施設、及びハイエンド居住環境等、より大きな設備を対象とする。また、Ｓモードは、（中央）デバイスが他のデバイスのコミッショニングを実行し、制御し、又はこれに関与するための手段である集中型コミッショニングである。この種のコミッショニングは、ゲートウェイ又はツールコミッショニングとも呼ばれる。中央デバイスは、典型的にはグラフィカルユーザーインターフェイスに接続されたゲートウェイ、ホームコントローラ、又はコミッショニングツールであり得る。ネットワーク内の他のデバイス上でバインディング及びレポートを構成することも可能である。中央デバイスは、ZigBee（登録商標）コーディネータの役割を果たす必要はない。実際には、ZigBee（登録商標）ルーターであってもよい。この機能を有するＺＨＡネットワーク内のデバイスは、コミッショニングディレクター（ＣＤ）として定義される。
【０００８】
ＺＨＡプロファイルの現在の仕様は、２つの異なる主要コミッショニングモード、すなわち、ＥＺモードコミッショニング（例えば、プッシュボタンコミッショニング）、及び集中型コミッショニング（例えば、ゲートウェイ、ツール、又はＳモードコミッショニングとも知られる）を定め、ＥＺモード及び集中型コミッショニングは相補的であり、完全互換性を有する。
【０００９】
同様に、ＺＬＬプロファイルの仕様（docs-zll-ZigBee（登録商標）-light-link-zll-profile-specification, ZigBee（登録商標） document number 11-0037参照）は、好適なコミッショニング機構として、タッチリンク（ＴＬ）コミッショニングを提供する。ＺＬＬシステムは、消費者市場へのアピールとして、単純化された据え付け方法の利益を享受する。タッチリンクは、ユーザー関与を最小化し、消費者が既製製品を素早く及び容易に据え付けることを可能にする。タッチリンクのセキュリティモデルは、デバイスを互いにタッチリンクさせ、ネットワーク発見及び選択を援助するのに、デバイス間の物理的接近を要求する。ＺＬＬのターゲットは、（近傍での）無線通信以外の手段によってタッチリンクがトリガーされることを要求されないため、（物理的な）ユーザーインターフェイス（ＵＩ）手段が非常に限定された、又はＵＩを持たないデバイスにとっても最適である。タッチリンクは、ネットワーク形成及び参加プロセスにおけるZigBee（登録商標）コーディネータの必要性を排除する。当該方法は、ノード上で実行され、Inter-PAN（Inter Personal Area Network）フレームを使用する特殊なコミッショニングアプリケーション（ＺＬＬコミッショニングクラスタに基づく）を使用し、まだ同じネットワーク上で動作することができないデバイス間での情報交換を可能にする。ネットワーク形成／参加動作を始動するノードは「イニシエータ」として知られ、このノードは多くの場合、リモートコントロールユニットであるが、例えばスイッチ、センサ、又は場合によっては照明等の他のノードであってもよい。タッチリンクは、単純に、ネットワークに含まれるべきノードにイニシエータノードが近づけられ、（例えば、ボタンを押すことによって）コミッショニングが開始されることを要求する。ネットワーク形成又は参加動作を実行するためにイニシエータによって接触されるノードは、「ターゲット」として知られている。
【００１０】
現在のZigBee（登録商標）仕様書は、パブリックアプリケーションプロファイルごとに、未接続デバイスが通常の動作状態に至るまで必要な詳細なステップを開示する。コミッショニングフェーズに一般的に含まれるタスクの数及び複雑性を考慮すれば、異なるZigBee（登録商標）パブリックアプリケーションプロファイルに属するデバイスをセットアップする単一のコミッショニングツールの価値は容易に見出される。
【００１１】
各ZigBee（登録商標）パブリックアプリケーションプロファイルは、異なるニーズ及びシナリオに向けて考えられたものであるため、対応する既存のコミッショニングプロセスは、異なるプロファイルに属するデバイスが互いに通信することを妨げる差異を有する。
【００１２】
今日、ネットワーク作成に関連するステップは、工場新規デバイスの場合、両プロファイルについて関連する問題を提示する。ＺＬＬターゲットデバイスは、Inter-PANベースコマンドを介して分散型ネットワーク開始を請け合うイニシエータと通信する必要があるが、一方、ＺＨＡデバイスは、同じタスクのために、ＺＬＬネットワークトポロジーには存在しない、中央コーディネータの存在に依存する。これらの理由のため、現在のコミッショニングプロセスは、特に両デバイスがまだ接続されておらず、ネットワークが存在しない場合、ＺＬＬルーターがＺＨＡエンドデバイスを制御することを望んでおり、又はその反対の状況に適用することができない。
【００１３】
これらのギャップの主な帰結は、現在市販されているコミッショニングツールが、全てのデバイスが同じZigBee（登録商標）パブリックプロファイルに属するシステムのセットアップにしか使用できないことである。
【００１４】
ZigBee（登録商標）ビルオートメーション・アプリケーション・プロファイルの仕様には、独自の一時的コミッショニングネットワークを作成し、参加者をそれに引き込み、参加者にその後他のネットワークに参加するよう指示する機能を有し得るコミッショニングツールが定められている。しかしながら、これらの機能はいずれも、参加者がＺＣＬコミッショニングクラスタを実装することを要求する。
【発明の概要】
【発明が解決しようとする課題】
【００１５】
本発明の一課題は、異なるプロファイル、及びプロファイルによって指定される異なるコミッショニングプロセスを有する異なるノードのコミッショニングを可能にし、よって、これらのプロファイルに従って実装されたレガシーデバイスに十分に対処することを可能にするコミッショニング方法及びデバイスを提案することである。
【課題を解決するための手段】
【００１６】
上記課題は、請求項１に係る装置、請求項１３に係る方法、請求項１４に係るネットワークデバイス、及び請求項１５に係るコンピュータプログラム製品によって達成される。
【００１７】
したがって、参加ノードのプロファイルに対応するネットワークタイプをエミュレートすることができるよう、ネットワーク内に新規なコミッショニング装置（例えば、コミッショニングツール又はコミッショニングデバイスとして提供される）又は機能が提供される。このアプローチは、カスタマーが、異なるアプリケーションプロファイル（例えば、ＺＨＡ又はＺＬＬ）に属するデバイスを素早くセットアップ及び制御することを可能にし、よって、デバイスは共通のコミッショニングプロセスをサポートする必要がない。これにより、提案されるコミッショニングツール又は機能は、ＺＬＬコミッショニング（例えば、タッチリンク）とＺＨＡコミッショニング（例えば、ＥＺモード）との間の変換又はブリッジを提供するため、ＺＨＡデバイスがＺＬＬデバイスを制御し又はＺＬＬデバイスがＺＨＡデバイスを制御することができる。
【００１８】
提案されるコミッショニング装置又は機能は、ネットワークが実際には異なるタイプのものであったとしても、参加者又は参加ノードに対して特定のネットワークタイプとして動作することができる。例えば、コミッショニング装置は、ＺＬＬネットワークに参加しようとしているレガシーＺＨＡ参加者に対して、集中型ネットワークのふりをすることができる。言い換えれば、コミッショニング装置又は機能は、現在のネットワークタイプが参加ノードのプロファイルに対応しない場合、ネットワークタイプをエミュレートする。
【００１９】
コミッショニング装置又は機能を単純なデバイス（例えば、リモートコントローラ（ＲＣ）等）として又は単純なデバイス内に実装又は具現化できることは有利であるが、本発明はかかる具現化に限定されず、携帯式のリッチユーザーインターフェイスデバイス、及びブリッジ又はゲートウェイのようなデバイスを含み得る。ゲートウェイは、コミッショニングされるネットワークと他の種類のネットワーク、例えばローカルエリアネットワーク（ＬＡＮ）又は無線ＬＡＮ（ＷＬＡＮ）との間のブリッジとして動作し得る。
【００２０】
具現化に応じて、コミッショニング装置又は機能は本明細書に記載される機能の全て又は一部を実行することができる。また、ユーザーモデルは変化し、例えば、タッチリンク交換のために、ＲＣタイプコミッショニング装置又は機能を参加者のところに持って行く代わりに、参加者をゲートウェイ／ブリッジタイプコミッショニング装置又は機能の近傍に持って行かなければならない可能性がある。特に明示されない限り、以下の実施形態の説明において、コミッショニングツールを表す略称「ＣＴ」は、これらの具現化のうちの任意のものを指すために使用される。
【００２１】
２つのZigBee（登録商標）プロファイル（ＺＨＡ及びＺＬＬ）についてのみ明示的に言及されているが、装置又は機能は、さらに、ＺＨＡ、ＺＬＬ、ＺＢＡ、ＺＲＳ、ＺＴＳ、ＺＨＣ、及びＺＳＥを含む任意のZigBee（登録商標）プロファイルのデバイスに対応し得る。
【００２２】
提案されるソリューションの目的は、現在、異なるネットワークプロファイル（例えば、ZigBee（登録商標）プロファイル）のデバイス間の通信を妨げる上記差異を克服することが可能なユニークなコミッショニングツールを提供することである。ＺＬＬ及びＺＨＡデバイスの両方から構成され得るコンシューマネットワークの具体例については、コミッショニング装置又は機能は、２つのタスクに取り組むコミッショニング・タイム・ブリッジ・デバイス（仲介者）として見ることができる。すなわち、コミッショニング装置は、コーディネータ又は親デバイスの存在に依存する全てのデバイス（例えば、ＺＨＡ）に対してコーディネータ又は親デバイスの役割を模倣し、同時に、タッチリンクコミッショニングが意図され及び／又はタッチリンクコミッショニングを使用するデバイス間でInter-PAN通信を行うことができる。
【００２３】
第１のオプションによれば、第１のプロファイルは、ユーザー選択、検出、コミッショニング装置によって発見された参加ノードの能力のうちの少なくとも１つに基づき選択され得る。これは、所望のユーザーアプリケーションに従うコミッショニング装置又は機能のフレキシブルな実装を可能にする。
【００２４】
第１のオプションと組み合わせることができる第２のオプションによれば、コミッショニング装置は、サポートされる複数のコミッショニング方法を所定の順番で試みるよう構成され得る。この手段は、全ての利用可能なコミッショニングオプションが試されることを保証し、また、優先順位を付けることができる。
【００２５】
第１又は第２のオプションと組み合わせることができる第３のオプションによれば、コミッショニング装置は、ZigBee（登録商標）Light Link（ＺＬＬ）デバイスがタッチリンクコミッショニングプロセスに従って参加することを許容し、また、コミッショニング装置は、イニシエータとして動作し、集中型ネットワーク上で動作する場合、集中型ネットワークパラメータをコピーして、ＺＬＬコミッショニングクラスタコマンド内でそれらを再翻訳し、コミッショニング装置は、さらに、集中型ネットワークパラメータ又はネットワークキーを参加者に送信する前にトラストセンターデバイスの承認を求めるための、参加デバイスに関する情報をトラストセンターデバイスに送信するための送信機を含み得る。これにより、コミッショニング装置は、集中型ネットワークプロファイルと分散型ネットワークプロファイルとの間のブリッジ又は仲介者として動作する。
【００２６】
第１乃至第３のオプションのいずれとも組み合わせることができる第４のオプションによれば、コミッショニング装置は、ZigBee（登録商標）Light Linkタッチリンク通信を、従来のZigBee（登録商標）コミッショニング通信に変換し得る。ここで、コミッショニング装置は、ＺＬＬデバイスとＺＨＡデバイスとの間の通信を可能にする単純な変換機能を提供する。
【００２７】
第１乃至第４のオプションのいずれとも組み合わせることができる第５のオプションによれば、コミッショニング装置は、分散型ネットワーク上で動作する場合、集中型ネットワーク上のコーディネータのふりをし、従来のZigBee（登録商標）デバイスによって期待される方法で保護されたネットワークキーを供給し得る。このオプションは、レガシーＺＨＡデバイスの分散型ＺＨＡネットワークへの参加を可能にする。
【００２８】
第１乃至第５のオプションのいずれとも組み合わせることができる第６のオプションによれば、コミッショニング装置は、参加ノードのリクエスト若しくはレスポンスを、第１のプロファイルのプロトコルから第２のプロファイルのプロトコルに変換するための、又は前に取得された情報に基づきリクエスト若しくはレスポンスを生成するためのプロセッサをさらに含み得る。プロセッサは、コミッショニング装置のフレキシブルなプログラミングを可能にして多目的コミッショニングツールを提供し、また、ツールがオンザフライでイベントを処理し、応答することを可能にする。
【００２９】
第１乃至第６のオプションのいずれとも組み合わせることができる第７のオプションによれば、コミッショニング装置は、第１のプロファイルのデバイスに対して、イニシエータとして第１の機能を提供し、第２のプロファイルのデバイスに対して、コーディネータとして第２の機能を提供するよう構成され得る。この手段は、集中型ネットワークプロファイルと非集中型ネットワークプロファイルとの間での適合を可能にする。
【００３０】
第１乃至第７のオプションのいずれとも組み合わせることができる第８のオプションによれば、コミッショニング装置は、参加ノードの能力を決定し、当該決定の結果に基づき適切なコミッショニング方法を選択し得る。これにより、参加ノードとコミッショニング装置との間の情報交換が最小化され得るため、ネットワーク負荷を減らすことができる。ある具体例では、装置は、決定の結果に基づきセキュリティキーを決定し得る。したがって、ネットワーク／ツール及び参加者によってサポートされる最も安全なコミッショニングプロセス及び設定を選択することにより、ネットワークセキュリティが最大化され得る。
【００３１】
第１乃至第８のオプションのいずれとも組み合わせることができる第９のオプションによれば、コミッショニング装置は、参加ノードへの返信を止めることにより、ネットワークに参加又は再参加するようルーターデバイスに指示し得る。これにより、ネットワークの親デバイスを変更するよう参加ノードをトリガーすることができる。
【００３２】
第１乃至第９のオプションのいずれとも組み合わせることができる第１０のオプションによれば、コミッショニング装置は、ネットワークのデバイスに関する情報を集め、オプションで内部データ構造内に保存し得る。この手段は、デバイスが常に通信可能でない場合、又はタッチリンクデバイスがタッチリンク近傍の範囲外に出る場合に有益である。保存は、コミッショニングプロセスの全体に又は特定のステップに厳密なタイムアウトが存在し、リアルタイム発見のために時間を使うことができない場合に特に有益である。
【００３３】
第１乃至第１０のオプションのいずれとも組み合わせることができる第１１のオプションによれば、コミッショニング装置は、単純記述子リクエストＺＤＯコマンドをユニキャストする、ローカルデバイスから単純記述子リクエストコマンドを受信した際、他のデバイスの発見情報を供給する、識別クエリコマンドをブロードキャストする、エンドポイントからの識別クエリレスポンスを処理する、新規デバイスの参加成功についてネットワーク内の他のノードに通知する、タッチリンクコミッショニングによってネットワークに参加したデバイスの情報能力についてネットワーク内のトラストセンターに通知する、ネットワークへの接続が失われたデバイスの再関連付けを可能にするために、又はネットワークパラメータによって構成された後の最初のネットワークへの参加を可能にするために、再参加リクエストコマンドを処理し、再参加レスポンスコマンドを発する、コミッショニング動作の成否についてユーザーに通知する、及び接続が失われた又はネットパラメータが変化した場合のより容易な再参加プロセスを可能にするために、デバイスをコミッショニングするのに使用された方式を記録し、この情報を保持することのうちの少なくとも１つを実行し得る。これらの能力は、参加ノードプロファイルに対応するネットワークタイプの効率的なエミュレーションを可能にする。
【００３４】
コミッショニング装置は、個別のハードウェア部品を有するディスクリートハードウェア回路、集積チップ、又はチップモジュールの配列に基づき実装されてもよく、又は、メモリ内に保存され、コンピュータ可読媒体上に書き込まれ、又はインターネット等のネットワークからダウンロードされたソフトウェアルーチン又はプログラムによって制御される信号処理装置又はチップに基づき実装されてもよいことに留意されたい。
【００３５】
請求項１の装置、請求項１３の方法、請求項１４のデバイス、及び請求項１５のコンピュータプログラムは、同様及び／又は同一の好適な実施形態、特に、従属請求項に記載されるような実施形態を有することを理解されたい。
【００３６】
また、本発明の好適な実施形態は、従属請求項又は上記実施形態の対応する独立請求項との任意の組み合わせであり得ることを理解されたい。
【００３７】
本発明の上記及び他の側面は、以下に説明される実施形態を参照して説明され、明らかになるであろう。
【図面の簡単な説明】
【００３８】
【図１】図１は、本発明が実装され得るコミッショニングデバイスの概略ブロック図を示す。
【図２】図２は、リモートコントローラとしてのコミッショニングデバイスの可能な具現化の例を概略的に示す。
【図３】図３は、既存のネットワークが検出されず、コミッショニングツールがコーディネータとしてネットワークを作成し、新たなデバイスがネットワークに参加することを望んでいる、第１の実施形態に係るコミッショニングプロセスのフロー図を示す。
【図４】図４は、コミッショニングツールが集中型ネットワーク内で動作し、新たなデバイスが当該ネットワークに参加することを望んでいる、第２の実施形態に係るコミッショニングプロセスのフロー図を示す。
【図５】図５は、コミッショニングツールがコミッショニングタイムゲートウェイとして動作する、第３の実施形態に係るコミッショニングプロセスの通信図を示す。
【図６】図６は、コミッショニングツールが分散型ネットワーク内で動作し、新たなデバイスがネットワークに参加することを望んでいる、第４の実施形態に係るコミッショニングプロセスのフロー図を示す。
【図７】図７は、異なるネットワークデバイス間のプロキシ機能を備えた様々な実施形態に係るコミッショニングデバイスの概略ブロック図を示す。
【図８】図８は、異なるプロファイルを有するデバイスのための第５の実施形態に係るバインディングプロセスの通信図を示す。
【図９】図９は、コミッショニングツールがプロファイルＩＤを変換する、異なるプロファイルを有するデバイスのための第６の実施形態に係るバインディングプロセスの通信図を示す。
【図１０】図１０は、コミッショニングツールがバインディングを作成する、異なるプロファイルを有するデバイスのための第７の実施形態に係るバインディングプロセスの通信図を示す。
【図１１】図１１は、異なるプロファイルを有するデバイスのための第８の実施形態に係るバインディングプロセスの通信図を示す。
【発明を実施するための形態】
【００３９】
以下、無線センサネットワーク、又はホーム若しくはビルオートメーションネットワークのためのコミッショニングツールに基づき、本発明の実施形態を説明する。具体的には、以下で紹介及び説明される例は、ZigBee（登録商標）無線ネットワークに基づく。かかるネットワークは、複数のプロファイルが併存し、インタラクトすることが必要な可能性があるホーム又はビルオートメーションネットワークに関し得る。例えば、ZigBee（登録商標） Light Link（ＺＬＬ）及びZigBee（登録商標） Home Automation（ＺＨＡ）ノードは、特にネットワークの形成において、一緒に動作しなければならない可能性がある。ここでは、例としてZigBee（登録商標）ネットワークが使用されるが、本発明は、ホーム及びビルオートメーション、又はセンシング若しくはモニタリング用の他の種類の無線ネットワークに適用され得ることに留意されたい。
【００４０】
実施形態、及びそれらのコミッショニングプロセスの説明に進む前に、ZigBee（登録商標）システムのネットワーク開始フェーズにおいて重要な役割を果たす変数を提示及び説明する。下表は、ZigBee（登録商標）仕様によって既に定義されている変数又はパラメータをまとめたものであり、まず各パラメータの一般名称が列挙され、その後に、パラメータがとり得る値域（１６進法）、及び工場新規デバイスにおけるデフォルト値（１６進法）を含む、ZigBee（登録商標）システムでの具現化が列挙されている。
【００４１】
【表１】
0006502330.tif 000002
【００４２】
次に、上記パラメータの役割を簡潔に説明する。
【００４３】
ネットワークアドレス（ＮＡ）フィールドは、１６ビット長であり、無線ノード／コントローラに割り当てられたショートネットワークアドレスを含む。
【００４４】
パーソナルエリアネットワーク（ＰＡＮ）ＩＤフィールド（ＰＩＤ）は、１６ビット長であり、ＰＡＮのＩＤを含む。
【００４５】
拡張ＰＡＮ  ＩＤ（ＥＰＩＤ）フィールドは、６４ビット長であり、ネットワークの拡張ＰＡＮ  ＩＤを含む。
【００４６】
論理チャネルフィールド（ＬＣ）（“phyCurrentChannel”と称される）は、８ビット長であり、ネットワークで使用される無線チャネルを含む。
【００４７】
ネットワーク更新ＩＤ（ＮＵＩ）フィールドは、当該ノードが使用しているネットワーク設定のスナップショットを特定する値を含む。
【００４８】
セキュリティネットワークキー（ＳＮＫ）セットは、コミッショニングアプリケーションによってアクセス可能なネットワークキー材料を含む。
【００４９】
キーＩＤ（ＳＮＫＩＤ）は、セキュリティネットワークキーセット内のアクティブネットワークキーのシーケンス番号を含む。
【００５０】
コーディネータ能力（ＣＣ）フィールドは、ブーリアンフラグであり、ネットワーク内でデバイスがコーディネータの役割を果たす能力（すなわち、新たなネットワークを作成することができるか、オプションで、トラストセンターポイントとして動作することを含む）に関する情報を知らせる。ＣＣフラグが真に設定される場合、デバイスはコーディネータになることができる。ＣＣフラグが偽に設定される場合、デバイスは、ZigBee（登録商標）ルーター又はZigBee（登録商標）エンドデバイスタイプであり得る。このフラグは、“nwkcCoordinatorCapable”と称され、ネットワーク情報ベース（ＮＩＢ）定数としてZigBee（登録商標）仕様に現存する。第２のフラグ（“apsDesignatedCoordinator”と称される）は、ＡＰＳ情報ベース（ＡＩＢ）定数としてZigBee（登録商標）仕様に現存する。ノード記述子のＭＡＣ（Media Access Control）能力フラグフィールドの代理ＰＡＮコーディネータフラグは、現在のZigBee（登録商標）仕様（r20）では“0b0”に設定される。
【００５１】
論理デバイスタイプ（ＬＤＴ）フィールドは、８ビット長であり、デバイスのタイプを指定し、例えば、デバイスがZigBee（登録商標）ルーターであるか、ZigBee（登録商標）コーディネータ、又はZigBee（登録商標）エンドデバイスであるかを指定する。ＬＤＴフィールドは、ノード記述子の論理タイプフィールドとして実装される。
【００５２】
次に、提案されるコミッショニングツール（ＣＴ）が採用し得るハードウェアコンポーネントについて説明する。
【００５３】
図１は、様々な実施形態に係るＣＴ１０の概略ブロック図を示す。ＣＴ１０は、アンテナ１０２を介して、ネットワークと無線で情報を送受信するための送受信機１０３を含む。さらに、後述される実施形態に係るコミッショニングプロセスを実装するために要求される情報を保存及び処理するために、メモリ１０４及びコントローラ１０５が提供される。第１のユーザーインターフェイス１０６（例えば、ブザー、発光素子、又はスクリーン等）を介してユーザーに信号が出力され、第２のユーザーインターフェイス１０７（例えば、ボタン又はタッチスクリーン等）を介してユーザーが情報を入力し得る。
【００５４】
図２は、リモートコントロール機能を備えたハンドヘルドデバイスとしてのコミッショニングデバイスの可能な具現化の概略的な例を示す。ＯＮ／ＯＦＦボタン２０１は、デバイスの電源をＯＮ又はＯＦＦにする役割を果たす。さらに、タッチリンクプロセスをサポートするコミッショニングデバイスのためにタッチリンクボタン２０２と、ＺＨＡデバイスのコミッショニングのためにＥＺモードボタン２０３とが設けられ得る。発光ダイオード（ＬＥＤ）２０４若しくは他の発光素子又はブザー２０６が、出力ユーザーインターフェイス（ＵＩ）素子として設けられる。デバイスは、バッテリースロット２０５に挿入された電池によって給電され得る。ボタン２０２、２０３はまとめられてもよい。ＬＥＤ２０４及びブザー２０６は出力ＵＩ手段の例であり、同様にまとめられてもよく、又はディスプレイ等の他の出力手段によって置き換えられてもよい。
【００５５】
提案されるコミッショニングツールが実装し得る様々な実施形態に係るコミッショニングプロセスの詳細な説明を提供するために、４つの主な小区分、すなわち、ネットワークの作成／参加／発見／選択（スタートアッププロセス）、セキュリティキー交換、新規デバイスの参加許可、並びに発見及びバインディングを取り扱う。
【００５６】
ネットワークの作成／参加／発見／選択（スタートアッププロセス）は、工場新規ＣＴの電源投入フェーズ直後のプロセスであり、どのようなステップを経て、デバイスが既存のネットワークの一員となり得るか、又はネットワークが検出されなった場合、新たなネットワークを作成し得るかを表す。
【００５７】
後の電源投入のためのＣＴにおけるデータ保持に関して、異なる可能な哲学が存在し得ることに留意されたい。家のようなＣＴでは、後の電源投入時、ＣＴは既にネットワーク内にいる可能性がある（常に同じホームネットワークを構成するために使用される可能性が高いので）。したがって、ＣＴは自身のメモリ内にデータを保持し得る。対照的に、専門的なＣＴ等では、ＣＴは異なるネットワークを構成するのに使用され得るため、電源投入時にはまだ参加しておらず、必要なネットワークに参加／ネットワークを作成し得る（又は、例えばメモリから多数の構成のうちの１つをダウンロードする）。
【００５８】
したがって、様々な実施形態に係る以下のコミッショニングプロセスは、工場新規ＣＴ、又は（他の）ネットワークに（再）参加するＣＴに適用可能であり得る。
【００５９】
ＣＴが電源投入される（例えば、電池が挿入され、デバイスのスイッチがＯＮにされ、又はコミッショニングアプレット若しくはアプリケーション等が起動される）。ユーザーインタラクションに応じて（又は自動的に）、ＣＴは、要求される任意の方法（サポートされる従来、参加、ＥＺモード、タッチリンク、又は任意の他の参加方法）を使用して、ネットワーク発見、及びその後の参加（及び／又は形成）に必要なアクションを実行する。
【００６０】
ＣＴが参加に適したネットワークを検出すると、ＣＴは、集中型ネットワーク又は分散型ネットワークに参加し得る。参加に適したネットワークは、ＣＴの何らかの実装固有基準、例えば、参加が自由であり（PermitJoin-TRUE）、特定のタイプのデバイスを受け入れ可能であり、特定のプロファイルに基づいて動作し、特定のコミッショニング方法を実行し、特定の種類のセキュリティ証明書を要求し、特定のセキュリティ設定に基づいて動作し、特定のデバイスタイプ（例えば、ゲートウェイ）を含み、特定の信号品質を有すること等を含む基準を満たすネットワークである。
【００６１】
従来の参加又はＥＺモードの場合、ネットワークタイプ（集中型又は分散型）は、参加後に（トランスポートキーコマンド内の）セキュリティキーを受信した際、分散型ネットワークの場合は“0xff..ff”を含み、コーディネータを有する集中型ネットワークの場合は、コーディネータは通常トラストセンター（ＴＣ）機能もホストするため、固有アドレス（“0xff..ff”でも“0x00..00”でもない） を含む、ＴＣアドレスフィールドを解析することによって決定され得る。
【００６２】
参加が成功した場合、ＣＴはネットワークの一員であり、他のデバイスのコミッショニング、及びネットワークへの参加許可のために使用され得る。
【００６３】
上記したように、オプションで、ＣＴはメモリからネットワークパラメータを呼び出し、ＮＷＫ再参加又はサイレント再参加を実行してもよい。
【００６４】
適切なネットワークが検出されなかった場合、コミッショニングツールは、ネットワークの初期パラメータとしてPAN ID、拡張PAN ID、ネットワークアドレス0x0000、及びセキュリティ設定（TC address !=”0xff..ff”）を設定し、コーディネータとしてネットワークを作成する。他の実施形態では、ネットワークが検出されなかった場合、ＣＴは分散型ネットワークを形成し得る。他の実施形態では、適切なネットワークが検出されなかった場合、コミッショニングツールは、（例えば、ユーザー入力又は参加者の能力に基づく）ネットワークタイプの決定を待ち、実際のコミッショニングプロセスを実行し得る。
【００６５】
ＣＴがネットワーク内でアクティブになった後、又は（コーディネータとして）ネットワークを作成した後、ＣＴはついにコミッショニングを行い、及び他のデバイスがネットワークに参加することを許容する能力を持つ。
【００６６】
以下の実施形態では、図３〜図６に基づき、異なるスタートアップケースのための異なるコミッショニングプロセスが説明される。
【００６７】
図３は、適切なネットワークが検出されず、ＣＴがコーディネータとしてネットワークを作成し、新たなデバイスがネットワークに参加することを望んでいる、第１の実施形態に係るコミッショニングプロセスのフロー図を示す。
【００６８】
ここで、ＣＴは、ＺＬＬデバイスのためのイニシエータ、並びにＺＨＡデバイスのためのZigBee（登録商標） PANコーディネータ（ＺＣ）及び／又はトラストセンター（ＴＣ）という２つの役割を担う。（複数の可能なオプションのうちの１つだけを表す）図３に示される第１の実施形態は、ＺＬＬイニシエータとしてのＣＴに関する。この具体例においてタッチリンクプロセスをトリガーするには、ユーザーインタラクションが必要である。
【００６９】
プロセスはステップＳ３００において開始する。ステップＳ３０１において、ＣＴはコーディネータとしてネットワークを作成し、ステップＳ３０２において、（ユーザー）入力を待つ。このステップの時点で、ネットワークは、ＣＴにおいて又は他の任意のコミッショニング方法を介して先に参加した他のデバイスを既に含み得ることに留意されたい。また、ＣＴネットワーク内の他のデバイスのいずれかがＺＣ／ＴＣの役割を担うことができる場合、ＣＴはその役割をそのデバイスに譲り、後述される図４のケースに効果的に移行し得る。Ｓ３０２において、ＣＴはネットワーク上の任意の交信に携わり、例えば、他のデバイスを制御し、制御コマンドを受信し、メンテナンスデータを送受信する等し得る。
【００７０】
ステップＳ３０３において、コミッショニングを可能にするためのトリガー（例えば、ユーザーアクション）の後、コミッショニングのための所定のタイムウィンドウが開かれ、ＣＴは参加デバイスをチェックする（例えば、ＦＮ  ＺＬＬターゲットが存在することが要求されるＺＬＬプライマリチャネル上でアクティブスキャンすることによって）。ネットワークに参加を試みるデバイスが無くタイムウィンドウが経過した場合、プロセスは、ステップＳ３１３における終点にジャンプする。（例えば、前述した図２に示されるように、リモートコントローラ内に具現化され得る）一実施形態では、ユーザーは、例えば２つの異なるユーザーインタラクション、例えば２つのボタン又は２つのプッシュシーケンス（例えば、短いプッシュ対長いプッシュ、一度のプッシュ対二度のプッシュ等）を使用して、例えば従来の参加／ＥＺモードコミッショニングではなくタッチリンクコミッショニング等の特定の種類のコミッショニングを実行するよう、ＣＴを明示的にトリガーし得る。他の実施形態では、ＣＴには単一のユーザートリガーしか存在せず、ＣＴが、サポートされるコミッショニング方法の両方を特定の順番で試行するようプログラミングされてもよく、例えば、まずＺＬＬイニシエータとして動作し、（工場新規）ターゲットを探すためにプライマリチャネルをスキャンし、（タッチリンクが要求する近傍に）ターゲットが発見されなかった場合、動作チャネルに戻ってPermitJoinを開き、又はこの反対を行ってもよく、又は、両プロセスの選択されたステップを交互に行ってもよい。他の実施形態では、ＣＴは、参加者の能力を特定可能であり（例えば、参加者とネットワークとの間で能力情報を交換することによって）、単一のユーザートリガーにも関わらず、適切な方法を直接開始可能であり得る。
【００７１】
ステップＳ３０４において、ＣＴは、タッチリンクリクエストをチェックする。タッチリンクリクエストが検出された場合、プロセスはステップＳ３１０に進み、ＣＴは、初期パラメータの送信、及びＺＬＬキーによって保護されたネットワークキーの交換を含むタッチリンクコミッショニングを実行する。オプションのステップＳ３１１において、ＣＴは、バインディングを可能にするために、タッチリンクプロセス中に交換された関連情報をメモリ内に保存する。ステップＳ３１２において、参加者は、取得されたパラメータを使用して、関連付け又はＮＷＫ再参加を実行し得る。このＳ３１０〜Ｓ３１２のブランチに代えて、ＣＴは、ＺＬＬプリインストール認証リンクキーによってネットワークキーを保護し、ＺＬＬデバイスが従来の参加を使用して参加することを許容し得る。
【００７２】
ステップＳ３０４においてタッチリンクリクエストが検出されず、従来の参加リクエストが受信された場合、ＣＴは、ステップＳ３０５において、ＭＡＣ関連付けを許容する。ＣＴは、PermitJoin=TRUE状態になければならない可能性があることに留意されたい。ＣＴのネットワーク内に他の（ルーター）デバイスが存在する場合、ＣＴは、ステップＳ３０６において参加許可リクエストをブロードキャストし、他の親デバイスにおける参加を可能にしてもよい。この場合でも、ＣＴはトラストセンター（ＴＣ）としてコミッショニング交換に関与し得る。
【００７３】
ステップＳ３０７において、デフォルトＴＣリンクキーによって保護されたネットワークキーの交換が実行される。オプションのステップＳ３０８において、ＣＴは、バインディングのための情報を引き出して保存するために、新規デバイスに単純記述子リクエスト（Simple_desc_req）をユニキャストし得る。
【００７４】
最後に、ステップＳ３０９において、参加者はネットワーク内でアクティブであり、プロセスはステップＳ３１３において終了する。
【００７５】
図４は、コミッショニングツールが集中型ネットワーク内で動作し、新たなデバイスが当該ネットワークに参加することを望んでいる、第２の実施形態に係るコミッショニングプロセスのフロー図を示す。
【００７６】
ここで、コミッショニングツールは、ZigBee（登録商標） Light Linkデバイスがタッチリンク方式に従って参加することを許容する。これにより、ＣＴはＺＬＬイニシエータとして機能し、集中型ネットワークパラメータをコピーして、Inter-PANコマンド内でそれらを再翻訳する。ＣＴは、ネットワークに参加した新規デバイスについてＴＣに通知する。
【００７７】
図４では、プロセスはステップＳ４００において開始し、ステップＳ４０１における、ＣＴが一員である集中型ネットワークの存在から始まる。ステップＳ４０２において、ＣＴは（ユーザー）入力を待つ。このステップの時点で、ネットワークは、ＣＴにおいて又は他の任意のコミッショニング方法を介して先に参加した他のデバイスを既に含み得る。また、ＣＴは、ネットワーク上の任意の交信に携わり、例えば、他のデバイスを制御し、制御コマンドを受信し、メンテナンスデータを送受信等し得る。ステップＳ４０３において、上記した図３の場合と同様に、コミッショニングを可能にするためのトリガー（例えば、ユーザーアクション）の後、コミッショニングのための所定のタイムウィンドウが開かれ、ＣＴは参加デバイスをチェックする（例えば、ＦＮ  ＺＬＬターゲットが存在することが要求されるＺＬＬプライマリチャネル上でアクティブスキャンすることによって）。ネットワークに参加を試みるデバイスが無くタイムウィンドウが経過した場合、プロセスは、ステップＳ４１３において終了する。（例えば、前述した図２に示されるように、リモートコントローラ内に具現化され得る）一実施形態では、ユーザーは、例えば２つの異なるユーザーインタラクション、例えば２つのボタン又は２つのプッシュシーケンス（例えば、短いプッシュ対長いプッシュ、一度のプッシュ対二度のプッシュ等）を使用して、例えば従来の参加／ＥＺモードコミッショニングではなくタッチリンクコミッショニング等の特定の種類のコミッショニングを実行するようＣＴを明示的にトリガーし得る。他の実施形態では、ＣＴには単一のユーザートリガーしか存在せず、ＣＴが、サポートされるコミッショニング方法の両方を特定の順番で試行するようプログラミングされてもよく、例えば、まずＺＬＬイニシエータとして動作し、（工場新規）ターゲットを探すためにプライマリチャネルをスキャンし、（タッチリンクが要求する近傍に）ターゲットが発見されなかった場合、動作チャネルに戻ってPermitJoinを開き、又はこの反対を行ってもよく、又は、両プロセスの選択されたステップを交互に行ってもよい。他の実施形態では、ＣＴは、参加者の能力を特定可能であり（例えば、参加者とネットワークとの間で能力情報を交換することによって）、単一のユーザートリガーにも関わらず、適切な方法を直接開始可能であり得る。
【００７８】
次のステップＳ４０４でタッチリンクリクエストが検出された場合、ＣＴは、ステップＳ４０６においてタッチリンクコミッショニングを実行し、現在のネットワークパラメータ（ＴＣによって選択され、ＺＬＬマスターキーによって保護されるネットワークキー等）をコピーし、それらをタッチリンクを介して新規デバイスに送信する（例えば、タッチリンクネットワーク参加ルーターリクエスト／ネットワーク参加エンドデバイスリクエストコマンド）。ステップＳ４０７において、関連付け又はネットワーク再参加が実行される。
【００７９】
ステップＳ４０８において、ネットワークにおける新規デバイスの追加についてＴＣに通知される。一実施形態では、これはＣＴによって実行される。ＣＴは、単に新規デバイスについてＺＣ／ＴＣに通知するだけでもよく（例えば、Update_device又はDevice_annce等のコマンドを使用して）、また、新規デバイスに代わり参加プロセスを完全にエミュレートし、もってＺＣ／ＴＣが参加者へのセキュリティキーの供給を許容し又は防ぐことを効果的に可能にしてもよい。他の実施形態では、参加デバイスは、ネットワークへの参加に成功した後、これを自ら実行する。これらの実施形態のいずれについても、新規デバイスを受け入れるには、ＺＣ／ＴＣがコミッショニングモードにあることが要求され、これは、例えばＳ４０３の処理の一部として、ステップＳ４０６の一部として、ステップＳ４０８の処理の一部として、例えばＣＴがＺＣ／ＴＣデバイスにブロードキャスト又はユニキャストでPermitJoin=TRUEを送信することによって達成され得る。
【００８０】
さらに、参加者は、ＴＣの真のＩＤによって構成され得る（タッチリンクプロセスによって示唆されたデフォルトＴＣアドレス“0xff..ff”を置き換えて）。これは、従来の参加を使用しなければならない可能性があり、参加デバイスが将来親デバイスとなり得る場合、すなわち、参加デバイスがZigBee（登録商標）ルーターで、ユーザーが異なるコミッショニング方式を使用する場合、例えば、あるときはＣＴによるコミッショニングを実行し、あるときは中央デバイス、例えばＺＣ／ＴＣ又はゲートウェイからのコミッショニングを可能にする場合に重要であり得る。一実施形態では、ステップＳ４０６において交換されるタッチリンクコマンドが拡張され、ＴＣアドレスを含んでもよい。他の実施形態では、例えばトランスポートキーコマンドを使用して、又はapsTrustCenterAddressパラメータ内に直接書き込むことにより、ＣＴ又はＴＣ／ＺＣによって、参加後にＴＣアドレスが送信されてもよい。
【００８１】
オプションのステップＳ４０９において、ＣＴは、バインディングを可能にするために、タッチリンクプロセス中に交換された関連情報をメモリ内に保存する。
【００８２】
ステップＳ４１２において、参加者はネットワーク内でアクティブであり、プロセスはステップＳ４１３において終了する。
【００８３】
ステップＳ４０４においてタッチリンクリクエストが検出されない場合、参加デバイスはＺＨＡデバイスであって、次のステップＳ４０５において、現在のZigBee（登録商標）仕様に従って参加を実行する可能性が高い。このため、ＣＴは、例えばＳ４０５の一部として、局所的に又はネットワーク全体で、PermitJoinをイネーブルしなければならない可能性がある。次のステップＳ４１０において、参加者は、（デフォルトＴＣリンクキーによって保護された）ネットワークキーを受信し、ＴＣによって認証される。
【００８４】
オプションのステップＳ４１１において、ＣＴは、バインディングのための情報を引き出して保存するために、単純記述子リクエスト（Simple_desc_req）を新規デバイスにユニキャストする。
【００８５】
上記と同様に、ステップＳ４１２において、参加者はネットワーク内でアクティブであり、プロセスは終了する。
【００８６】
図５は、ＣＴがコミッショニングタイムゲートウェイとして動作する、第３の実施形態に係るコミッショニングプロセスの通信図を示す。これを達成するために、ＣＴは、ステップＳ５０１においてコミッショニングを可能にする異なるプロファイル間のリンクを提供するよう構成されたZigBee（登録商標）（ＺＢ）機能３０及びＺＬＬ機能４０を提供する。好ましくは、ＺＬＬタッチリンクを介して参加デバイス５０にパラメータ、特にネットワークキーを送信する前に、ＣＴは、ＺＣ／ＴＣ２０に承認を求めることができる。ステップＳ５０２において、ＣＴ  ＺＢ機能３０は、ＺＣ／ＴＣ２０にPermitJoin=TRUE情報を送信し、ステップＳ５０５において、ＺＣ／ＴＣ２０はコミッショニングを可能にする。ステップＳ５０３において、ＣＴタッチリンク機能４０は、ＺＬＬ参加者（ＺＬＬ−Ｊ）５０にタッチリンク・スキャン・リクエストを送信し、ステップＳ５０４において、タッチリンク・スキャン・レスポンスを受信する。次に、ＣＴ  ＺＢ機能３０は、ステップＳ５０６においてＺＣ／ＴＣ２０にビーコンリクエストを送信し、ステップＳ５０７において、ＺＣ／ＴＣ２０からビーコンを受信する。
【００８７】
オプションで、ＣＴ  ＺＢ機能３０は、ステップＳ５０８において、参加者のためのＭＡＣ関連付けリクエストをＺＣ／ＴＣ２０に送信し、ステップＳ５０９において、ＭＡＣ関連付けレスポンスを受信し、デバイス能力のための入力は、ＴＬスキャン交換に基づく。
【００８８】
その後、ＣＴ  ＺＢ機能３０は、ステップＳ５１０において、参加者のための更新デバイスリクエストをＺＣ／ＴＣ２０に送信し、ステップＳ５１１において、参加者のためのトランスポートキーを受信し得る。このトランスポートキーに基づき、ＣＴ  ＺＬＬ機能４０は、ステップＳ５１２において、ＺＬＬネットワーク参加リクエストをＺＬＬ参加者５０に送信し得る。最後に、ステップＳ５１３において、ＺＬＬ参加者は、ＺＨＡドメインに向けてＮＷＫ再参加リクエストを送信し得る。
【００８９】
ＺＨＡデバイスについては、ＣＴは、従来のコミッショニングを促進し、例えば、PermitJoin送信を可能にし得る。
【００９０】
ＣＴが集中型ネットワーク内で動作し（すなわち、既にコーディネータが存在する）、新たなタッチリンク有効デバイスがネットワークに参加することを望んでいる場合、ＣＴは、参加者を受け入れる前にＺＣ／ＴＣと相談し得る。ＴＣによって管理される集中型ネットワークでは、ＣＴは媒介として機能し、すなわち、ＴＣが、参加者が通常のＺＨＡデバイスであると「考え」、参加者が、通常のＺＬＬ交換に参加していると「考える」よう、ＺＬＬタッチリンク通信を、ＺＨＡ（従来の参加／ＥＺモード）コミッショニング通信に変換する。両方のセッションを生かしたままにするには、ＣＴは両プロトコルのタイミングを知らなければならない。特に、このようにして、ＣＴは、ネットワークキーを参加者に送信する前にＺＣ／ＴＣと相談することができ、よって、ユーザーのためのＺＬＬ交換の単純さを保ちつつ、ＺＣ／ＴＣは、ネットワーク拡張のための中央制御ポイントであり続けることができる。
【００９１】
また、ＣＴは（特に、一時的に給電されるデバイス、特にＺＥＤ、例えばＲＣとして具現化される場合）、タッチリンクネットワーク参加ルーター／エンドデバイスリクエスト内の、すなわち、ZigBee（登録商標）関連付け／参加フェーズのためのネットワークパラメータを参加者に供給した後、参加者への返信を止めることによってネットワークに（再）参加するようルーターに指示することができる。この挙動は、ネットワーク内の他のデバイスを親として選択することを参加者に強いる。参加者がＮＷＫ再参加手続きを使用する場合、これは、他の親においてPermitJoin信号送信をイネーブルすることさえなく実行され得る。
【００９２】
図６は、ＣＴが分散型ネットワーク内で動作し、新たなデバイスが当該ネットワークに参加することを望んでいる、第４の実施形態に係るコミッショニングプロセスのフロー図を示す。
【００９３】
ここで、ＣＴは、ＺＨＡデバイスの親として動作し、ＴＣアドレスとしてそのアドレスを供給し、また、ＺＬＬデバイスに対してＺＬＬイニシエータとして動作する。これは、あるデバイスは分散型ネットワークに存在すると「信じ」、他のデバイスは集中型ネットワークに存在すると「信じ」、それらのネットワーク設定が保存されたＴＣアドレスによって（それぞれ、“0xff..ff”に等しい又は等しくない）、及び、ネットワークキーの供給方法によって異なっている（それぞれ、親／ＴＣによって、及びネットワークキー保護のために使用されるキーの種類）、混合ネットワーク構成をもたらし得る。この場合、新規デバイスをネットワークに追加する必要がある度に、ＣＴが起動され、ネットワーク内で動作可能にされなければならない。しかしながら、（ＴＣの存在を要する）参加者が（“0xff..ff”以外の）ＴＣアドレスによって構成されたデバイスのうちの１つにおいて参加可能な場合、ＣＴ自身が親である必要はない。また、ＣＴは、ネットワークパラメータ供給の時間、参加者の親となり、その後任意のルーターにおいて再参加させ得る（好ましくは、保護されたＮＷＫ再参加を使用して）。
【００９４】
図６のプロセスは、Ｓ６００において開始し、ステップＳ６０１において、分散型ネットワークが存在する。ステップＳ６０２〜ステップＳ６０４にかけて、プロセスは、図３及び図４に関して説明されたステップと同じステップを呼び出す。
【００９５】
ステップＳ６０５において、ステップＳ６０４でタッチリンクリクエストが検出されなかった場合、従来の参加／ＥＺモード（関連付け）プロセスの一部として、ＴＣは現在のネットワークパラメータ（例えば、ＥＰＩＤ、ＰＩＤ、及びネットワークアドレス）を送信する。
【００９６】
ステップＳ６０６において、ＴＣアドレスとしてＣＴ自身のアドレスも含むトランスポートキーコマンドの一部として、ＴＣデフォルトキーによって保護されたネットワークキーが参加者に送信される。
【００９７】
オプションのステップＳ６０７において、ＣＴは、単純記述子リクエスト（Simple_desc_req）を新規デバイスにユニキャストし、引き出された情報をメモリ内に保存する。
【００９８】
あるいは、ステップＳ６０４においてタッチリンクリクエストが検出された場合、プロセスはステップＳ６０８に分岐し、参加者は、ZLL ZigBee（登録商標）仕様書に示されるように、タッチリンクプロセスを実行する。これにより、参加者はＺＬＬキーによって保護されたネットワークキーを受信する。
【００９９】
オプションのステップＳ６０９において、ＣＴは、タッチリンクプロセス中に交換された情報を自身のメモリ内に保存する。ステップＳ６１０において、参加者は、取得されたパラメータを使用して関連付け又はＮＷＫ再参加を実行し得る。
【０１００】
最後に、ステップＳ６１１において、参加デバイスはネットワーク内でアクティブかつ動作可能であり、プロセスは終了する。
【０１０１】
以下、セキュリティキー交換についてより詳細に説明する。
【０１０２】
ＣＴがＺＬＬデバイス及びＺＨＡデバイスの両方をコミッショニングする能力は、各プロファイル仕様に応じて認証を実行し及びネットワークキーを供給するために、ＣＴが適切なセキュリティキーを有することを要求する。
【０１０３】
具体的には、ＣＴは、３つの異なる鍵、すなわち、ＺＬＬマスターキー、良く知られたデフォルトＴＣリンクキー、及びＺＬＬプリインストール証明リンクキーを有する。さらなるオプションとして、ＣＴは他の種類のキー、例えば、設置コード（installation code）に由来する個別のＴＣリンクキーを含み得る。ＺＬＬキーは、全ての認証されたＺＬＬデバイスによって共有される秘密である。ＺＬＬキーは認証された製造者にのみ分配され、秘密保持契約による制約を受ける。したがって、コミッショニングツールはＺＬＬデバイスとして認証されていなければならず、ZigBee（登録商標） Light Linkに対応するデバイスにのみ、ＺＬＬキーによって保護されたネットワークキー（ＮＷＫ）を供給するよう意図される。
【０１０４】
ＺＬＬプリインストールキーは本発明のいずれの開示の実施形態にも含まれていないが、ＣＴがＺＬＬ対応デバイスであり、ＺＬＬ認証される資格を有することを保証するには必要なキーであると考えられる。ＺＬＬプリインストールキーは、従来のコミッショニングを使用してタッチリンク可能デバイスにネットワークキーを供給するために使用され得る。
【０１０５】
全てのＺＨＡデバイス、及びプリインストールキーをサポートしない他のZigBee（登録商標） Proデバイスにとって、ＺＬＬキーの存在はトランスペアレントである。
【０１０６】
一実施形態では、ユーザーは、各ZigBee（登録商標）認証を受けたデバイス上のZigBee（登録商標）アプリケーションプロファイルロゴの存在により、コミッショニングされなければならないデバイスの能力を知ることができ（すなわち、ＺＨＡ、ＺＬＬ）、それに従ってＣＴに指示する（例えば、ＣＴ上のボタンを押す）。デバイスが属するプロファイルを示すことにより、ＣＴは、ネットワークキーを安全に送信するのに使用されるセキュリティキーを知ることができる。
【０１０７】
他の実施形態では、使用されるキーの種類は、参加者の能力発見に基づき決定され、例えば、参加者が使用するコミッショニング方法に基づき決定される（ＥＺモード対ＺＬＬタッチリンク）。
【０１０８】
ＺＬＬネットワーク及びＺＨＡネットワークと同様に、ＣＴは、他のセキュリティ方式間、例えばＩＣ可能参加者とＩＣ不能ネットワークとの間をブリッジし得る。
【０１０９】
現在、ＺＨＡとＺＬＬとの間の適切な通信を阻害する他の相違点は、デバイスが他のデバイスがネットワークに参加することを許容し得る期間の違い、及び、ＺＬＬデバイスが許可期間フラグをイネーブルするために管理許可参加リクエスト（Mgmt-Permit-Join request）をブロードキャストできないことである。
【０１１０】
データの整合性を保持し、及び異なるプロファイルからのデバイスがネットワークに参加することを可能にするために、コミッショニングツールは、許可期間パラメータをZigBee（登録商標）コーディネータ又はルーターが関連付けを許容する秒単位の期間（通常、１８０ｓ）に設定して、コマンドMgmt_Permit_Joinをユニキャスト／ブロードキャストする能力を有する。ネットワーク内のデバイスがMgmt_Permit_Joinリクエストコマンドを受信すると、当該デバイスはこのコマンドを処理し、ＣＴのMgmt_Permit_Joinリクエスト内で供給された許可期間の値と同じ値を使用して、NLME_Permit_Joinリクエストを送信することができる。
【０１１１】
追加の特徴として、ＣＴは、新たなデバイスがネットワークに参加し、又は接続を失ったデバイスが再参加手続きに成功したことを他のZigBee（登録商標）デバイスに通知するために、Device_annceコマンドをブロードキャストする能力を有し得る。
【０１１２】
デバイスがネットワークに参加した場合、制御アプリケーション、及び／又はデバイスが制御するアプリケーションと関係を確立しなければならない。異なるデバイス内に位置する２つのエンドポイント間の論理関係を構築するために使用されるプロセスは、ZigBee（登録商標）ではバインディングと呼ばれ（例えば、照明を制御するスイッチがその照明に結び付けられる）、制御グループの形成を含み、発見部分は、マッチする機能を有する場合によっては多数のデバイスから結合するデバイスを選択することを指す。バインディングテーブル内のエントリーは、基本的には、バインディングリンクにおいて使用されるソースアドレス、ソースエンドポイントＩＤ、宛先アドレス、宛先エンドポイントＩＤ、及びクラスタＩＤの間の関連付けからなるペアである。バインディングテーブルは、従来のコミッショニング／ＥＺモードをサポートするソースデバイスによって保存され、外部から（Mgmt_Bind_reqを介して）可読であり、（Bind_req/Unbind_reqを介して）構成可能である。ＺＬＬはアプリケーションレベルに同様な構造を有するが、外部からアクセスすることができない。
【０１１３】
この目的のために、ＣＴは、ネットワーク内のデバイスのバインディングにおいてブリッジ機能を有し、特に、バインディングの他の側として動作することができる。
【０１１４】
様々な実施形態において、ＣＴは、リアルタイムで両コミッショニング方式にわたりデバイス及びサービス発見を実行し、ＣＴがプロキシとなる実際の参加者のアプリケーション機能とマッチするデバイスを探すことができる。ＣＴは、参加者のリクエスト／レスポンスを翻訳し得る（例えば、ＺＨＡ参加者のMatch記述子リクエスト；異なるZigBee（登録商標）デバイス及びサービス発見サービスの間の翻訳を含み、一部しかサポートされない場合、例えば、ZigBee（登録商標）単純記述子リクエスト（Simple _Desc_req）に基づき、マッチする記述子リクエスト（Match_Desc_req）に応答し、又は、（例えば、ＺＬＬ参加者のタッチリンクスキャン応答メッセージ内で）以前に取得された情報に基づき、リクエスト／レスポンスを生成する）。また、ＣＴは、リクエスタによって期待されるプロファイルにマッチするよう、デバイス及びサービス発見メッセージ内のプロファイルＩＤを適合させ得る。このために、ＣＴは、適切なプロファイルＩＤを使用してリクエスト及び／又はレスポンスを生成又は再送し得る。したがって、ＣＴは、デバイスがそれら自身のアプリケーション層制御関係（例えば、バインディング）を自ら作成するためにデバイス間を仲介し、又はかかる関係を明示的に構成し得る（例えば、ZigBee（登録商標）のバインディングリクエストコマンドを使用して）。これは、Inter-PANではなく、（保護された）ZigBee（登録商標）ネットワークを介してＺＬＬコミッショニングクラスタコマンド（例えば、デバイス情報リクエスト又はスキャンリクエスト）を送信することを要求し得ることに留意されたい。
【０１１５】
他の実施形態では、ＣＴがネットワーク内でアクティブになると、ＣＴは、ネットワーク内に既に存在するデバイスに関連する情報を集める。これは、例えばデバイスがネットワーク上に常にいない場合、又は、例えばＺＬＬデバイスがＣＴのタッチリンク近傍範囲から出て、後の送信を妨げる場合に有益であり得る。これを達成するために、ＣＴは、まず、（ZigBee（登録商標）又はInter-PANを介して）ＺＬＬコミッショニングクラスタのデバイス情報リクエストコマンド、並びに／又は、ZigBee（登録商標）デバイス及びサービス発見コマンドを送信して、ＺＬＬ及びＺＨＡデバイスの両方から情報を引き出す。ＣＴは、実際には、ＥＺモード及びタッチリンク（Inter-PANメッセージング）の両方をサポートし、ネットワーク内のデバイスに関する情報を保存可能な内部データ構造を実装する。同様に、新規デバイスがネットワークに参加する場合、セキュリティキーの交換後、ＣＴは、新規デバイスに関連する情報を集めて自身のメモリ内に保存する。保存される情報のフォーマットは、コミッショニングに関与するデバイスの種類に依存し得る。具体的には、タッチリンクを介してＺＬＬデバイスがコミッショニングされる場合、ＣＴは、以下のフォーマットで関連情報をデバイス情報テーブル内に記録し得る。
【０１１６】
【表２】
0006502330.tif 000003
【０１１７】
ＥＺモード又は従来のコミッショニングを介してＺＨＡデバイスがコミッショニングされる場合、保存される情報は、以下のフォーマットを有する単純記述子のフィールドからなる。
【０１１８】
【表３】
0006502330.tif 000004
【０１１９】
この情報は、コミッショニングフェーズ全体の間だけ、メモリ内に保持される。新規デバイスがネットワーク内に入り、通常動作状態に至った後、ＣＴはメモリ内に保存される情報をリフレッシュ又はドロップすることができる。
【０１２０】
一実施形態では、バインディングプロセスを開始するために、トリガーに応じて（すなわち、ユーザーがソース・エンドポイント・デバイス上に取り付けられたバインディングボタンを押し、又はデバイスの参加後自動的に）、ソース・エンドポイント・デバイスはデバイス及びサービス発見をトリガーし、これにより、ＣＴがトリガーされ、ソース・エンドポイント・デバイスのデバイス能力に関する情報が引き出される。上記されたように、この引き出しは、ＣＴの前の発見に基づきローカルメモリからでもよく、又は、遠隔デバイス自体（又は他のキャッシュ）からリアルタイムでもよい。さらに、ローカルメモリからのアプリケーション情報の引き出しが、ユーザーによってコミッショニングのために現在選択されたデバイスのリアルタイムチェック、例えば識別ステータスのチェックによって補完されてもよい。
【０１２１】
（デバイスのZigBee（登録商標）プロファイルに応じてＥＺモード又はタッチリンク方式を使用して）ソース及び宛先の両方からデバイス能力を受信した後、ＣＴはそれらのサポートされるクラスタＩＤを比較し、マッチする場合、バインディングリクエストを有効と認め、バインディングに関する全情報が内部バインディングテーブル内に保存される。サポートされるクラスタＩＤを比較するステップは、（例えば、ＺＬＬコミッショニング・クラスタ・スキャン・リクエスト／応答コマンドのデバイスＩＤ及びバージョンフィールドによって符号化された）ＺＬＬ機能を翻訳することを要し得ることに留意されたい。このために、ＺＬＬ仕様に定義された必須デバイス機能が使用されてもよい。
【０１２２】
下表は、ＺＬＬ調光可能照明デバイスのための定義の例を示す。
【０１２３】
【表４】
0006502330.tif 000005
【０１２４】
図７は、異なるネットワークデバイス間のプロキシ機能を備えた、様々な実施形態に係るＣＴの概略ブロック図を示す。図７によれば、ＣＴ８０は、まず、第１のデバイス７０（例えば、サーバデバイス）のソースエンドポイント７２と通信し、そのデバイス能力及び情報７３を取得する。その後、ＣＴ８０は、第２のデバイス９０（例えば、クライアントデバイス）の宛先エンドポイント９２と通信し、そのデバイス能力及び情報９３を取得する。ＣＴ８０は、その後、バインディング基準８２に従ってマッチングを行う。マッチングが正しい場合、両デバイスによってサポートされる方式に従って両デバイスに構成コマンドが送信され、中央デバイスとしてのＣＴ８０のバインディングテーブル８３内に新たなバインディングエントリーが保存される。
【０１２５】
バインディングプロセスについては、２つの異なるユースケースに着目することが重要である。第１に、ＺＬＬ電球を制御することを望むＺＨＡコントローラ（例えば、センサ、スイッチ等）である。第２に、ＺＨＡ電球を制御することを望むＺＬＬコントローラ（例えば、センサ、スイッチ等）である。
【０１２６】
図８は、上記第１のユースケースに関する、異なるプロファイルを有するデバイスのための第５の実施形態に係るバインディングプロセスの通信図を示す。ＺＬＬ電球（ＺＬＬ−Ｂ）１５０を制御するＺＨＡコントローラ（ＺＨＡ−ＳＷ）１２０の第１のケースに関する第５の実施形態について、ＺＬＬ電球１５０デバイス及びＺＨＡスイッチ１２０デバイスが同じネットワーク上で正常に動作している場合（ネットワークの作成／参加／発見の第１章において説明されたように、ＣＴがネットワークを作成し、又は既存のネットワークにデバイスが参加することを許容したために）、バインディングプロセスは、ＥＺモード機能１３０及びＺＬＬ機能１４０によるＣＴの使用を含まない（含む必要が無い）可能性がある。この場合、ＺＨＡスイッチがバインディングを実行するために必要な情報は、ＺＬＬ電球１５０に単純記述子リクエスト（Simple_Desc_req）又はマッチング記述子リクエスト（Match_Desc_req）をユニキャストすることによって直接引き出すことができる。
【０１２７】
図８の通信図は、例えば、ＺＬＬデバイスによって供給されるレスポンス内に正しいプロファイルＩＤ、すなわち、プロファイルＩＤ  Ｙ（例えば、“0xc05e）ではなくプロファイルＩＤ  Ｘ（例えば、“0x0104”）を入れるために、ＣＴが依然として必要とされ得る場合に関する。ステップＳ８０１において、ＺＬＬ電球１５０を識別モードにするアクションが開始される（例えば、ユーザー又は他のトリガーによって）。ステップＳ８０２において、ＥＺモードをイネーブルするようＺＨＡスイッチ１２０が制御される。ステップＳ８０３において、ＺＨＡスイッチ１２０は、識別クエリコマンドをブロードキャストし、ステップＳ８０４において、ＺＬＬ電球１５０は、識別クエリレスポンスをブロードキャストする。その後、ステップＳ８０５において、ＺＨＡスイッチ１２０は、自身のプロファイルＩＤ  Ｘとともに単純記述子リクエスト（又は、エンドポイント情報若しくはマッチする記述子を引き出すための他の試行）をＺＬＬ電球１５０に送信する。これに応じて、ステップＳ８０６において、ＺＬＬ電球１５０は、自身のプロファイルＩＤ  Ｙとともにレスポンスを発するが、これは、マッチしないプロファイルＩＤのため紛失される。次にステップＳ８０７において、ＣＴは、ＺＬＬ機能１４０とＥＺ機能１３０との間の翻訳機能を提供し、ＺＬＬ電球１５０から受信されたプロファイルＩＤ  Ｙを、ＺＨＡスイッチ１２０の正しいプロファイルＩＤ  Ｘに翻訳する。その後、ステップＳ８０８において、ＥＺ機能１３０は、翻訳されたプロファイルＩＤとともにレスポンスをＺＨＡスイッチ１２０に転送する。正しいプロファイルＩＤ  Ｘを受信すると、ＺＨＡスイッチ１２０は、ステップＳ８０９においてローカルバインディング作成を開始する。オプションで、ＣＴのＺＬＬ機能１４０は、ステップＳ８１０において、ＺＬＬ電球１５０に識別停止コマンドを送信し得る。
【０１２８】
図９は、コミッショニングツールが、異なるコミッショニング方法に係る異なるデバイス及びサービス発見方法間で翻訳を行う上記第１のユースケースに関する、異なるプロファイルを有するデバイスのための第６の実施形態に係るバインディングプロセスの通信図を示す。
【０１２９】
ここで、ＣＴは、ＺＬＬ電球１５０からタッチリンク機構を介して取得された情報を、ＺＨＡスイッチ１２０によって使用されるZigBee（登録商標）デバイス及びサービスプリミティブに翻訳し得る。後者は、例えば、ＺＬＬ電球１５０が一時的にアクセス不能な場合、例えば依然として再参加している場合等に要求され得る。
【０１３０】
図９の通信図において、ステップＳ９０１〜Ｓ９０４は、図８のステップＳ８０１〜Ｓ８０４に対応する。その後、ステップＳ９０５において、ＺＨＡスイッチ１２０は、紛失される単純記述子リクエスト（又はエンドポイント情報又はマッチする記述子を引き出すための他の試行）をＺＬＬ電球１５０に送信する。次に、ステップＳ９０６において、ＣＴのＺＬＬ機能１４０は、オプションのInter-PANデバイス情報リクエストをＺＬＬ電球１５０に送信し、ステップＳ９０７において、ＺＬＬ電球１５０は、Inter-PANデバイス情報レスポンスによって応答する。ステップＳ９０６及びＳ９０７の代わりに、ＣＴは、先に取得されたＺＬＬ電球に関するデバイス情報をローカルメモリから引き出すことができる。その後、ステップＳ９０８において、ＣＴ内で電球情報が翻訳され、ＥＺ機能１３０によって、翻訳された電球情報を有する単純識別子レスポンスによってＺＨＡスイッチ１２０に転送される。翻訳された電球情報を受信すると、ＺＨＡスイッチ１２０は、ステップＳ９１０において、ローカルバインディング作成を開始する。オプションで、ＣＴのＺＬＬ機能１４０は、ステップＳ９１１において、識別停止コマンドをＺＬＬ電球１５０に送信してもよい。
【０１３１】
図１０は、コミッショニングツールがバインディングを作成する上記第１のユースケースに関する、異なるプロファイルを有するデバイスのための第７の実施形態に係るバインディングプロセスの通信図を示す。
【０１３２】
ＺＨＡスイッチ１２０とペアリングするＺＬＬデバイスを知るために、ＣＴは、それらの識別ステータスを問い合わせ（及び／又は保存し）、参加後の経過時間を監視等することが必要であり得る。第７の実施形態では、ＣＴは、リクエスト／レスポンスを翻訳せずに、両デバイスのアプリケーション能力をローカルに比較し、例えばバインディングリクエストを使用して、ＺＨＡスイッチ１２０上で直接バインディングを構成し得る。これがＥＺモードコミッショニングプロセスの有効な結果であること、すなわち、バインディングが既に構成されているにも関わらず、発見応答が無いためにステートマシンがプロセスをハング／失敗しないよう注意すべきである。
【０１３３】
初期ステップＳ１００１〜Ｓ１００５、Ｓ１００７及びＳ１００８は、図９のステップＳ９０１〜９０７に対応し、ここでは繰り返し説明しない。しかしながら、第６の実施形態とは異なり、ＣＴのＥＺ側又は機能１３０は、ステップＳ１００６において、さらに単純記述子リクエストをＺＨＡスイッチ１２０に送信する。ステップＳ１００９において、ＺＬＬ電球１５０から受信された電球情報が、ＣＴにおいて保存される。さらに、ステップＳ１０１０において、ＣＴのＥＺ機能１３０は、ＺＨＡスイッチ１２０からスイッチ情報を受信する。このスイッチ情報は、ステップＳ１０１１においてＣＴに保存される。その後、ステップＳ１０１２において、保存された電球情報が保存されたスイッチ情報と比較され、マッチが特定される。ステップＳ１０１３において、比較結果に基づき、ＣＴのＥＺ機能１３０は、ＺＨＡスイッチ１２０にZigBee（登録商標） APS（Application Support Sub-Layer）バインディングリクエストを送信する。オプションで、ステップＳ１０１４において、ＣＴのＺＬＬ機能１４０は、ＺＬＬ電球１５０に識別停止コマンドを送信してもよい。
【０１３４】
図８〜図１０の上記第１のユースケースとは異なり、ＺＨＡ電球を制御するＺＬＬスイッチの第２のユースケースは、ＣＴが、ＺＬＬコントローラにおけるソースバインディングの欠落、及びＺＨＡ電球におけるＺＬＬコミッショニング・クラスタ・サポートの欠落を克服することを要求する。
【０１３５】
図１１は、上記第２のユースケースに関する、異なるプロファイルを有するデバイスのための第８の実施形態に係るバインディングプロセスの通信図を示す。
【０１３６】
図１１の通信図は、デバイスのバインディングを成功させるために、ＺＬＬコントローラ（スイッチ）１２２、ＣＴ（説明の目的上、図８〜図１０に示されるように、２つのサブエンティティＣＴ−ＺＬＬ１４０及びＣＴ−ＥＺ１３０に区分される）、及びＺＨＡ電球１５２の間で無線で交換されるメッセージを示す。
【０１３７】
ＺＬＬスイッチ１２２、ＣＴ、及びＺＨＡ電球１５２は、同じネットワークに参加することに成功し、現在同じネットワーク内で動作可能であると仮定する。ステップＳ１１０１において、例えば、ＺＬＬスイッチ１２２又はＺＨＡ電球１５２のネットワークへの参加プロセスの成功、又は（例えば、入力ユーザーインターフェイスによる）ＣＴへの明示的なユーザーアクションによって、ＣＴ−ＺＬＬ側又は機能１４０におけるバインディング・イネーブル・ステップがトリガーされ得る。あるいは、ZigBee（登録商標）及び／又はInter-PANを介する特定のデバイス又はサービス発見メッセージの受信がトリガーであってもよい。
【０１３８】
プロセスは、さらに、例えばデバイスの識別モードをイネーブルすることによりバインディングされるデバイスをユーザーが選択するオプションのステップ（図示無し）を含み得る。この選択は、暗示的で、参加成功の後に自動的に続いてもよく、デバイスとのユーザーインタラクション（例えば、ボタンを押す）を要してもよく、又は例えば選択されるデバイスの近傍にいるとき（Inter-PANを使用して）、若しくは例えば単に全ての保存／発見されたデバイスをトグルする、ＣＴからのコマンドによってトリガーされ得る。
【０１３９】
ＣＴは、参加フェーズにおいて、ＺＬＬスイッチ１２２及び／又はＺＨＡ電球１５２に関連する情報を既に引き出していてもよい。したがって、当該情報は、メモリ内で既に利用可能であってもよい。
【０１４０】
図１１において、デバイス情報リクエストを送信し、デバイス情報レスポンスを受信することによる、ＺＬＬスイッチへの情報リクエストに関するオプションのステップＳ１１０２及びＳ１１０３が実行され得る。受信されたスイッチ情報は、さらなるオプションのステップＳ１１０４において保存され得る。また、ステップＳ１１０５において、ＣＴからＺＨＡ電球１５２及びＺＬＬスイッチ１２２に、識別クエリコマンドがブロードキャストされ得る。それぞれステップＳ１１０６及びＳ１１０７において、両者はＩＤクエリレスポンスによって応答し得る。次に、ステップＳ１１０８において、ＺＨＡ電球１５２に単純記述子又はマッチング記述子リクエストがユニキャストされる。ステップＳ１１０９において、ＺＨＡ電球１５２は、電球情報を含むユニキャスト単純記述子又はマッチング記述子レスポンスによって応答する。次に、ステップＳ１１１０において、ＣＴは、受信された電球情報とスイッチ情報を比較し、ステップＳ１１１１において、比較結果に基づき情報を翻訳し得る。次に、ステップＳ１１１２において、ＣＴのＺＬＬ機能１４０は、ＺＬＬスイッチ１２２にコミッショニングクラスタコマンドを送信する。オプションで、ＺＬＬスイッチ１２２は、その後ペアリングプロセスを開始し、ＺＬＬ機能１４０は、ペアリング情報を保存し得る。
【０１４１】
ＣＴが関連デバイスから情報を集める正確なタイミング、及び処理をトリガーするアクションは、実装特有であってもよい。マッチングのための情報比較のステップＳ１１１０がスキップされてもよく、ＺＨＡ電球１５２の翻訳されたＺＨＡ能力情報がＺＬＬスイッチ１２２に送信され、ＺＬＬスイッチ１２２がマッチングを実行してもよい。
【０１４２】
デバイスにおけるバインディングエントリーの作成を補助する代わりに、ＣＴは、バインディングテーブルを持つ能力がなく、ソースバインディングをサポートしない、又はバインディング構造にリモートアクセスすることができない全てのデバイスのためにも、この情報を保持及び維持するタスクを実行し得る。しかしながら、この設計は、バインディングされたデバイス間の通信が行わるときは常にＣＴが動作可能でなければならないことを示唆する。また、ソースデバイスが（宛先のローカルストレージがないために黙ってドロップするのではなく）メッセージをＣＴに転送することを知らなければならないことに留意されたい。メリットとしては、この設計は、他のプロファイルのデバイスにコマンドを転送する際、特定のパラメータを修正すること、例えばプロファイルＩＤを置き換え（合致しないプロファイルＩＤが使用されている場合）、及び／又は例えばサポートされないコマンドをサポートされる同等なコマンドによって（例えば、enhanced add sceneコマンドをregular add sceneコマンドによって、又は例えばエフェクト付きOffコマンドを通常Offコマンドによって）置き換えることができるという利点を有する。
【０１４３】
ＣＴが他のデバイス（例えば、ＺＬＬ参加者、ＣＴ等）に代わってメッセージを送信するふりをしている場合、ＣＴは、このデバイスのアドレスを必要なフィールド、例えばＮＷＫソースアドレスフィールド内に入れなければならない可能性があることに留意されたい。また、例えばキー、セキュリティフレームカウンタ等、当該他のデバイスに関する他のパラメータを使用しなければならない可能性もある。
【０１４４】
上記実施形態では、ＣＴは、指定されたエンドポイント上の遠隔デバイスの単純記述子を問い合わせるために単純記述子リクエストZigBee（登録商標） Device Object （ＺＤＯ）コマンドをユニキャストする能力、ネットワーク内の遠隔デバイスであって、その情報がコミッショニングツールメモリ（すなわち、ZigBee（登録商標）キャッシュ機能）内に保存された遠隔デバイスの情報を問い合わせることを望んでいるローカルデバイスから単純記述子リクエストコマンドを受信した際、他のデバイスの発見情報を供給する能力、識別クエリコマンドをブロードキャストする能力、エンドポイントからの識別クエリレスポンスを取り扱う能力、ネットワーク内の他のノードに新規デバイスの参加成功を通知する能力（例えば、update device及び／又はdevice_annceコマンドによって）、コミッショニングツール自身とのタッチリンクによってネットワークに参加したデバイスの情報能力についてネットワーク内のＴＣに通知する能力（例えば、update device及び／又はdevice_annceコマンドによって）、ネットワークへの接続を失ったデバイスの再関連付けを可能にするために再参加リクエストコマンドを処理し及び再参加レスポンスコマンドを送信する能力、コミッショニング動作の成否についてユーザーに通知する能力（例えば、ブザー及び／又は点滅ＬＥＤを介して）、及び接続が失われた場合により容易な再参加プロセスを可能にするために、デバイスのコミッショニングに使用された方式を記録し、この情報を保持する能力のうちの少なくとも１つを有する。実際の具現化に応じて、ＣＴはＺＣ、ＺＲ、又はＺＥＤとして実装され得ることに留意されたい。ＺＥＤ又はＺＲとして実装された場合、ＺＨＡ（レガシー）参加者に対してのみＺＣのふりをし得る。
【０１４５】
要約すると、第１のプロファイルの参加ノードを、第２のプロファイルに従うネットワーク内で動作するよう構成するためのコミッショニング装置及び方法が説明された。コミッショニング装置は、第１のプロファイルに対応するコミッショニングプロセスをエミュレートする。
【０１４６】
様々な実施形態に係るネットワークシステムの構成要素の上記動作は、コンピュータプログラムのプログラムコード手段として及び／又は専用ハードウェアとして実装され得る。より具体的には、上記プロセスは、コンピュータプログラムのプログラムコード手段として及び／又は専用ハードウェアとして実装され得る。コンピュータプログラムは、他のハードウェアとともに又はその一部として供給される光学記憶媒体又はソリッドステート媒体等の適切な媒体上で保存及び／又は供給されてもよいが、他の形態で、例えばインターネット又は他の有線若しくは無線テレコミュニケーションシステムを介して等、他の形態で供給されてもよい。
【０１４７】
図面及び上記において本発明を詳細に図示及び記載してきたが、かかる図面及び記載は、制限的では無く、説明的又は例示的であると考えられたい。本発明は、負荷デバイスとして電球を有する開示の実施形態に限定されない。本発明は、任意の種類の負荷、センサ、及びスイッチ等に関して実装され得る。
【０１４８】
図面、開示、及び添付の特許請求の範囲を分析することにより、当業者は、開示の実施形態の変形例を理解及び実施することができる。請求項中、「含む」等の用語は他の要素又はステップを除外せず、要素は複数を除外しない。単一のプロセッサ又は他のユニットが、請求項中に記載される複数のアイテムの機能を果たし得る。単にいくつかの手段が互いに異なる従属請求項に記載されているからといって、これらの手段の組み合わせを好適に使用することができないとは限らない。
【０１４９】
本明細書は、本発明の特定の実施形態を詳細に記述する。しかしながら、記載が如何に文章上詳細に表現されていたとしても、本発明は多様な方法で実施可能であり、よって、開示の実施形態に限定されない。本発明の特徴又は側面を説明するために特定の用語が使用される場合、用語が本明細書で再定義され、用語が関連付けられた本発明の特徴又は側面の具体的特性を含むよう制限されることを示唆するものと解されるべきではないことに留意されたい。
【０１５０】
単一のユニット又はデバイスが請求項に記載されたいくつかのアイテムの機能を果たし得る。単にいくつかの手段が互いに異なる従属請求項に記載されているからといって、これらの手段の組み合わせを好適に使用することができないとは限らない。
【図１】
0006502330.tif 000006
【図２】
0006502330.tif 000007
【図３】
0006502330.tif 000008
【図４】
0006502330.tif 000009
【図５】
0006502330.tif 000010
【図６】
0006502330.tif 000011
【図７】
0006502330.tif 000012
【図８】
0006502330.tif 000013
【図９】
0006502330.tif 000014
【図１０】
0006502330.tif 000015
【図１１】
0006502330.tif 000016