JP6031668B2 - ネットワーク構成方法 - Google Patents

Description

本発明は、ネットワーク構成方法、保守エンティティ（単位）、並びに保守エンティティ及び複数のノードを含む通信ネットワークに関する。

本発明は、例えば、構成される必要があるいくつかのノードが、限定的且つ予測不能な受信時間窓等の強い使用（動作）制限を有する無線ネットワークに関連する。これは、特にＺｉｇＢｅｅネットワーク内のＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅに当てはまる。

ネットワーク、特に無線ネットワークにおいては、ネットワークの各ノードの動作を正常に保つために、全てのノードを現在使用されているネットワーク構成パラメーターの値に更新しておかなければならない。実際、干渉スペクトル若しくはロケーションの変化等の予定外のイベントのため、又は暗号キー（鍵）の定期的変更等の予定されたイベントのため、保守エンティティはチャンネルＩＤ、ネットワークＩＤ、ノードＩＤ又はロール（役割）、ネットワーク内の新しいコーディネータ／保守エンティティのＩＤ、暗号鍵又は鍵シード等の新しい値を通信しなければならない場合がある。

しかし、ネットワークによってはいくつかのノードの受信機会が限定（制限）されている場合がある。例えば、ＺｉｇＢｅｅネットワークは、バッテリー（電池）を有さず、予定外の機会でしか受信を行うことができないＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ（ＺＧＰＤ）を有し得る。例えば、ＺＧＰＤは、ユーザによって起動され信号を送信した後の短時間だけ受信を行うことができる無電池スイッチであり得る。ＺＧＰＤの他の例は、例えば太陽電池等によって環境からエネルギーを得る定期報告センサである。エネルギー収支の制限のため、これらのデバイスはアクティブ探索により新しいパラメーターを発見することができない。

これらのデバイスが構成信号を常には受信できないため、制限されたデバイスの２つの受信機会間にネットワークの再構成が起こった場合、当該制限されたデバイスはパラメーター値の変化を知ることができない。デバイスはネットワークパラメーターの古いバージョンを使い続け、更新が行われた近所から知らされない可能性が高いため、デバイスがネットワークから除外される可能性が高い。制限されたデバイスがネットワークに再び組み込まれるためには、ユーザによる手動の介在を要する可能性が非常に高い特別なプロセスが必要であり、これは長時間を要し、大きな整備負担がかかる。

本発明の目的は、上記問題を軽減するネットワーク構成方法を提案することである。

本発明の他の目的は、ネットワーク内で動作可能な制限されたノードの存在及び制限を考慮したネットワーク構成方法を提案することである。

本発明の他の目的は、いくつかのノードを失うことなく、またネットワーク内の正常な動作を維持しながらネットワークの構成を許容する方法を提案することである。

特に、本発明に係る方法は、ネットワークの運用を妨害することなく全てのノードを最新の状態に保つことを意図する。

この目的のために、保守エンティティ及び複数のノードを含むネットワークにおいてネットワーク構成パラメーターを更新するための方法であって、当該方法は前記保守エンティティにおいて、
（ａ）所定の期間内にのみデータを受信可能な、少なくとも１つの制限されたノードの前記ネットワーク内の潜在的な存在を検出するステップと、
（ｂ）更新されたネットワーク構成パラメーター値が要求されるかを判定するステップであって、前記ネットワーク構成パラメーターは、前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに関して共通である、判定ステップと、
（ｃ）前記ネットワーク内の前記少なくとも１つの制限されたノードの潜在的存在の前記検出に基づき、前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新するための信号の送信を延期するステップと、
（ｄ）前記制限されたデバイスへの前記更新されたネットワーク構成パラメーター値の送信をトリガするトリガ信号を送信するステップと、
（ｅ）前記複数のノードにおいて前記更新されたネットワーク構成パラメーター値を更新する前記信号を送信するステップと
を含む、方法が提案される。

よって、保守エンティティは、ネットワーク内の１つ以上の制限されたノードの存在を考慮し、例えば全ての制限されたノードが再構成されるまで、前記制限されたノードの存在に基づいて残りのネットワークの再構成を延期することができる。これにより、必要となる結合プロセスを起こす制限されたノードを「失うこと」を回避することができる。

また、本発明は、保守エンティティ、並びに保守エンティティ及び複数のノードを含む通信ネットワークにも関連する。

本発明のこれら及び他の側面は、下記の実施形態を参照して説明され、より明らかになるであろう。

以下において、本発明を添付の図面を例として参照してより詳細に説明する。
図１Ａは、新しいＺＧＰシステム保守警告コマンドのフォーマットを示す。 図１Ｂは、新しいＺＧＰシステム保守警告コマンドのオプションフィールドのフォーマットを示す。 図２Ａは、ＺＧＰ応答コマンドのフォーマットを示す。 図２Ｂは、ＺＧＰ応答コマンドのＺＧＰＰ Ｔｘチャンネルフィールドのフォーマットを示す。 図３Ａは、改変されたＺＧＰ応答コマンドのフォーマットを示す。 図３Ｂは、改変されたＺＧＰ応答コマンドのオプションフィールドのフォーマットを示す。 図４Ａは、ＺＧＰパラメーター更新状態コマンドのフォーマットを示す。 図４Ｂは、ＺＧＰパラメーター更新状態コマンドのオプションフィールドのフォーマットを示す。

本発明は、互いに通信し合う複数のノードを含むネットワークに関する。本発明の一例示的実施形態においては、ネットワークは無線メッシュネットワークである。本発明は、ＺｉｇＢｅｅ規格において、特にＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ（ＺＧＰ）規格に関連して説明される。

ＺｉｇＢｅｅネットワークでは、エネルギーハーベスティング（環境発電）スイッチ及び無電池型センサ等のＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ（ＺＧＰＤ）が動作している。ＺｉｇＢｅｅネットワークでは、キー、チャンネル、ＰＡＮＩｄ等の構成パラメーターが変わらなければならないときがある。非常に制限されたエネルギー収支を有するＺＧＰＤは、有効化される前に更新を受信することも、変更を発見して自己調整することも保証されていない。このため、手動による再コミッショニングが必要になるが、これは長時間を要し、ＺＧＰＤの制限された通信及びユーザーインターフェース（ＵＩ）能力のために多くの手動作業を要し、また、エネルギーハーベスティングＺＧＰＤの主要な要求であるメンテナンスフリーオペレーションを無効化する。

本発明は、ＺｉｇＢｅｅネットワーク内で動作するＺＧＰＤに、変更されたネットワークパラメーターを効率的且つ確実に送達するためのソリューションを提供する。これを達成するために、ＺＧＰインフラデバイス、すなわちＺＧＰ規格に基づいてＺＧＰＤと通信可能なＺｉｇＢｅｅデバイスは、ＺＧＰＤを更新する時間を有することができるよう、担当の（責任を負う）ＺｉｇＢｅｅ保守エンティティ（例えばセキュリティセンター（Ｔｒｕｓｔ Ｃｅｎｔｒｅ）、ＺｉｇＢｅｅ ＰＡＮコーディネータ（ＺｉｇＢｅｅ ＰＡＮ Ｃｏｏｒｄｉｎａｔｏｒ）又はネットワークマネージャー（Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｒ））によって計画されたパラメーター変更についての通知を事前に受ける。更新が実行されると、ＺＧＰインフラデバイスは担当のＺｉｇＢｅｅ保守エンティティに更新状態応答を提供する。このために、新しいフレームＺＧＰフォーマット及びフレーム拡張が定義される。

ＺｉｇＢｅｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＺｉｇＢｅｅ ｄｏｃｕｍｅｎｔ ０５３４７４ｒ１９、“ＺｉｇＢｅｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ”、改訂１９版、２０１０年１０月１２日、４．６．３．４によれば、セキュリティキー更新は、２メッセージアプローチにより行われる。第１メッセージにより、キーは全てのＺｉｇＢｅｅデバイスにユニキャスト又はブロードキャストによって配信される。第２メッセージにより、デバイスは新しいキーの使用に切り替わる。

ＺｉｇＢｅｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＺｉｇＢｅｅ ｄｏｃｕｍｅｎｔ ０５３４７４ｒ１９、“ＺｉｇＢｅｅ ｓｐｅｃｉｆｉｃａｔｉｏｎ”、改訂１９版、２０１０年１０月１２日、３．１０及びＡｐｐｅｎｄｉｘ Ｅによれば、チャンネル及びＰＡＮＩｄの更新は、ネットワークマネージャー／ＺｉｇＢｅｅ ＰＡＮコーディネータデバイスから、ブロードキャストを通じて行われる。このメッセージを受信してから一定の時間経過後（ｎｗｋネットワークブロードキャスト送信時間（ｎｗｋＮｅｔｗｏｒｋＢｒｏａｄｃａｓｔＤｅｌｉｖｅｒｙＴｉｍｅ）、ＺｉｇＢｅｅ−ＰＲＯネットワークでは２〜３秒に対応）、各デバイスは新しい構成に切り替わる。

欠点として、これらの機構はＺＧＰインフラデバイスが新たなパラメーターをＺＧＰＤに送信するのに十分な時間を提供しないことがある。さらに、これらの機構は、管理を行うＺｉｇＢｅｅエンティティに対していくつの及びどのＺＧＰＤが更新されたかについてのフィードバックをなんら提供しないため、手動による再コミッショニングを含む更新後メンテナンスをさらに煩雑にする。特に、キーの更新については、全てのＺＧＰインフラデバイスによって実行される、単純なｚｇｐ共通セキュリティキー（ｚｇｐＳｈａｒｅｄＳｅｃｕｒｉｔｙＫｅｙ）属性への新しい値の書き込みだけでは、クリアなＺＧＰＤ更新制御プロセスは実現できない。

本発明は、ＺｉｇＢｅｅ保守エンティティに新たな能力、すなわち、ネットワーク内のＺＧＰＤデバイスの潜在的又は実際の存在を把握し、それに準拠してＺｉｇＢｅｅパラメータープロセスを管理する能力を定めることを提案する。これを達成するために、パラメーター変更の決断がなされ、ネットワーク内の潜在的又は実際のＺＧＰＤの存在が検出されると、ＺｉｇＢｅｅ保守エンティティはＺｉｇＢｅｅ更新を延期する。その一方で、保守エンティティはまずＺＧＰＤパラメーター更新プロセスをトリガ（開始）する。これは、ＺＧＰインフラデバイスからステータス応答を集める手段、及び、ＺＧＰＤ更新状況（進捗）を含むいくつかの基準に基づいてＺｉｇＢｅｅ更新を実行する時間を決定する手段を有する。これを達成するため、本発明は新しいＺＧＰコマンドを定義するか、既存のコマンドを拡張する。ＺＧＰにおけるデュアルキーオペレーションを可能にするために、追加のＺＧＰ属性、ｚｇｐ交代共通セキュリティキー（ＡｌｔｅｒｎａｔｅＳｈａｒｅｄＳｅｃｕｒｉｔｙＫｅｙ）を提案する。

ＺＧＰ ｓｐｅｃｉｆｉｃａｔｉｏｎ、ＺｉｇＢｅｅ Ｄｏｃｕｍｅｎｔ ０９５４９９、“Ｄｒａｆｔ ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”、バージョン０．９、改訂１６版、２０１１年５月１６日によれば、ＺＧＰＤが十分なエネルギー収支を有すれば、選択された時間（タイミング）において、メッセージを送信した直後に限られた時間（期間）の間メッセージを受信することができる。ＺＧＰＤスイッチの場合、受信及び送信のためのメッセージは、ともにユーザによって同一のロッカートグリングから来る。これらのデバイスは、エネルギー収支制限のため、アクティブ探索によって新しいパラメーターを発見することができない。ＺＧＰＤは、ユーザ、センサ、アプリケーション、時間、又はハーベスタ／エネルギー保存トリガの際に、送信するレギュラーフレーム内にＲｘＡｆｔｅｒＴｘフラグを設定することによって受信能力を指示する。この送信の５ｍｓ後、ＺＧＰＤは、受信のために無線を少なくとも０．５７６ｍｓ（通常はこれよりそれほど長くない）開く。このような厳しい時間制約的機構のため、送信機会を無駄にしないために、送信側は、搬送波感知多重アクセス／衝突回避方式（ｃａｒｒｉｅｒ−ｓｅｎｓｅ ｍｕｌｔｉｐｌｅ ａｃｃｅｓｓ ｗｉｔｈ ｃｏｌｌｉｓｉｏｎ ａｖｏｉｄａｎｃｅ（ＣＳＭＡ／ＣＡ））を使用しない。したがって、１つのデバイスだけがＺＧＰＤに送信を行っていることが重要であり、そうでない場合、多重送信は１に近い確率で衝突する。この目的のために、ＺＧＰ仕様は、発信源のＺＧＰＤ及びＺＧＰインフラデバイスのショートアドレスへの距離の基準を用いることにより、ＺＧＰＤによって制御されるシンクが、この特定のＺＧＰＤ及び自身のために送信を行っているプロキシから１つのデバイスを選択する（デバイスがＺＧＰＤの無線レンジ内にある場合）ように、ＴｅｍｐＭａｓｔｅｒ選択プロセスを定義する。しかし、この機構は同一のＺＰＧＤによって制御される複数のシンク間のＴｅｍｐＭａｓｔｅｒレゾリューション（決定）に欠け、これは特にシンクが自身をＴｅｍｐＭａｓｔｅｒとして指名する場合に当てはまる。本発明は、ＴｅｍｐＭａｓｔｅｒ選択プロセスを変更することを提案し、ＺＧＰ応答フレームをそれに適応させる。

また、現在のＴｅｍｐＭａｓｔｅｒ／ＦｉｒｓｔＴｏＦｏｒｗａｒｄプロキシ選択は、ＲｘＡｆｔｅｒＴｘサブフィールドセットを有するＺＧＰＤコマンドフレームが受信された直後に実行される。しかし、選択されたＴｅｍｐＭａｓｔｅｒのアドレス、及びＺＧＰＤの直接無線レンジ内にシンクが存在するか否かの情報のいずれも、シンクに現在保存されない。まずＴｅｍｐＭａｓｔｅｒを決定してその後ＺＧＰＤ更新フレームを準備するべく、更新フレームをＺＧＰＤの次の対話までバッファすることにより、追加の遅延が導入され、更新成功率が下がるおそれがある。したがって、ＺＧＰＤへのアドホックな（特別な）フレーム送信、例えばＺｉｇＢｅｅパラメーター更新によってトリガされる送信は実行が難しい。これに対処するため、シンク内にＴｅｍｐＭａｓｔｅｒ関連情報を記憶することが提案される。特に、シンクがさらに各（ＲｘＡｆｔｅｒＴｘ可能）ＺＧＰＤペアに関する以下の情報をさらに記憶することを提案する。
（i）ＩｎＲａｎｇｅフラグ：シンクがＺＧＰＤから直接受信することが可能だったかを示す。
（ii）ＴｅｍｐＭａｓｔｅｒフィールド：最後に選択されたＴｅｍｐＭａｓｔｅｒ、又は現在の最初に転送するプロキシを示す。
（iii）ＴｅｍｐＭａｓｔｅｒ距離フィールド：ＴｅｍｐＭａｓｔｅｒまでの距離、及びそれがシンク自身であるかを示す。これらのアイテムを、全体として又は別々に、全て又は一部のみ、強制的に又は任意（オプション）でシンクテーブル内に記憶することができる。

ＺＧＰＤ更新を実行するために、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅ仕様書によって定められる機能に加えて、以下の機能を有する。
１）ＺｉｇＢｅｅ保守エンティティはシステム／ネットワーク内のＺＧＰデバイスの潜在的な存在について知っている。
２）ＺｉｇＢｅｅ保守エンティティはＺＧＰＤに追加の更新機会を提供するためにＺｉｇＢｅｅパラメーター更新を延期するポリシーを含む。
（i）ある実施形態によれば、ＺｉｇＢｅｅ保守エンティティはＺＧＰＤのいずれかが受信可能であるか否かの知識を有する。また、ＺｉｇＢｅｅ保守エンティティは、ネットワーク内のＺＧＰＤのいくつが受信可能か、どのＺＧＰＤがこの能力を有しているかを知ることができる。
あるいは、ＺＧＰＤ受信能力に関する情報／受信能力を発見する能力を有していない場合、ＺｉｇＢｅｅ保守エンティティは、どのＺＧＰＤが更新をトライするかの判断をＺＧＰインフラデバイスに任せることができる。ＺＧＰインフラデバイスは、ＺＧＰＤのＲｘＯｎ能力（ＲｘＯｎＣａｐａｂｉｌｉｔｙ）を参照することでこれを行うことができる。この区別は、更新に伴うトラフィック及び／又は遅延を抑えるために、好ましくは更新プロセス内で可能な限り早く行われる。
（ii）ＺｉｇＢｅｅ保守エンティティがＺＧＰＤのためのＮＷＫキーの保守をできる場合、ＺｉｇＢｅｅ保守エンティティは、好ましくはＺＧＰＤ通信を保護するために用いられるキーが更新されるＺｉｇＢｅｅＮＷＫキーから得られたものであるか、したがって、ＺＧＰＤの更新及びＺｉｇＢｅｅパラメーター更新の延期が必要であるか否かを知る。あるいは、（特定のＺＧＰＤによって）使用されるＺＧＰＤセキュリティキータイプに関する情報を発見する能力を有していない場合、ＺＧＰＤ保守エンティティ／ＺＧＰインフラデバイスは、（特定のＺＧＰＤによって）使用されるセキュリティキータイプを参照することでこの判断を行う。これは、トラフィックを抑えるために更新プロセス内において可能な限り早く行われる。
（iii）ＺｉｇＢｅｅ保守エンティティがＰＡＮＩｄの保守をできる場合、ＺｉｇＢｅｅ保守エンティティは、好ましくはＺＧＰＤのいずれかがＰＡＮＩｄ値を（デフォルトのブロードキャストＰＡＮＩｄ値０ｘｆｆｆｆの代わりに）使用するか否か、したがって、ＺＧＰＤの更新及びＺｉｇＢｅｅパラメーター更新の延期が必要か否かを知る。
（iv）延期は、更新されるパラメーターの種類及びそれを更新するＺｉｇＢｅｅ方法に依存してもよい。一例においては、新しいパラメーターのＺｉｇＢｅｅノードへの送信、及び新しいパラメーターのアクティブ化の両方を延期することができる。他の例においては、新しいパラメーターのアクティブ化のみが延期可能であり、これはＺｉｇＢｅｅネットワークキー（ＺｉｇＢｅｅ Ｎｅｔｗｏｒｋ Ｋｅｙ）更新において可能である。
３）ＺＧＰＤ更新の進捗状況に応じてＺｉｇＢｅｅパラメーター更新をトリガするポリシーを有してもよい。ポリシー基準は、ＺｉｇＢｅｅ保守エンティティベンダ、それを利用するアプリケーションプロフィール、又は特定のネットワークの管理者次第であり、
（i）ＺＧＰＤに更新のための固定追加時間を与えること、
（ii）更新される所与のサブセットの全てのＺＧＰＤ（サブセットの定義は、ＺＧＰＤのいくつかのプロパティ、例えば機能性、ロケーション、能力、優先度等に基づき得る）、
（iii）更新される（サブセットの）所与のパーセントのＺＧＰＤ、
を含み得る。
４）ＺｉｇＢｅｅ保守エンティティは、
（i）ＺＧＰシステム保守警告コマンド、
（ii）及び／又は下記で提案のように改変されたＺＧＰ応答コマンド、
を送ることによってＺＧＰＤ更新をトリガする能力を有する。
５）オプションで、ＺｉｇＢｅｅ保守エンティティは各ＺＧＰＤにＴｅｍｐＭａｓｔｅｒを指名する能力を有する。
６）オプションで、ＺｉｇＢｅｅ保守エンティティは、ＺＧＰ更新状態コマンドを受信することによって進捗状況を追跡する能力を有する。更新トリガコマンド内の適切な設定により、更新確認を要求（リクエスト）／抑制することができる。
７） さらに、ＺｉｇＢｅｅ保守エンティティは、ユーザ（例えばネットワーク管理者）に更新結果を提示できてもよく、これは、例えば手動更新を必要とするＺＧＰＤのロケーションを示すサイトマップである。
８）オプションで、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅネットワーク内でパラメーター更新が有効化された後、選択されたＺＧＰＤの更新プロセスを再トリガできる。例えば、選択されたＴｅｍｐＭａｓｔｅｒにＺＧＰ応答コマンドを再送信することによるチャンネル更新の場合、このＴｅｍｐＭａｓｔｅｒに一時的に古い使用チャンネルに移動するように指示する。

上記の機能は、全て実際に担当のＺｉｇＢｅｅ保守エンティティ（セキュリティーセンター、ＺｉｇＢｅｅ ＰＡＮコーディネータ、ネットワークマネージャー）によって実行することができる。あるいは、機能１及び２のみがＺｉｇＢｅｅ保守エンティティ内に実装され、実際のＺＧＰＤ更新及び更新進捗追跡は、ＺＧＰＤについてより詳しい他のエンティティ又はＺＧＰＤ保守エンティティ（例えば、中央コントローラ又はコンセントレータ、ＺＧＰコミッショニングツール等）に委任して実行することができる。ＺＧＰＤ保守エンティティは、別のデバイス又はＺｉｇＢｅｅ保守エンティティの別のモジュール／ロールであり得る。

上記で説明したように、本発明は、ＺＧＰＤを含むＺｉｇＢｅｅネットワーク内で自動パラメーター更新を可能にするための新しいメッセージフォーマットを提案する。本発明は、新しいコマンド、ＺＧＰシステム保守警告コマンドを導入し、そのフォーマットは図１Ａ（コマンドのフォーマット）及び図１Ｂ（コマンドのオプションフィールドのフォーマット）に示される。このコマンドは、ＺｉｇＢｅｅ保守エンティティが（選択された）ＺＧＰインフラデバイスにパラメーター変更を事前に知らせることを可能にする。次にＺＧＰシステム保守警告コマンドをより詳細に説明する。ＺｉｇＢｅｅ保守デバイスの知識に応じて、コマンドはユニキャスト又はブロードキャストで送信される。プロキシがこのコマンドの受信時に動作できるようにするには、プロキシはＺＧＰＤ更新コマンド、すなわち、ＺＧＰＤチャンネル構成コマンド及びＺＧＰＤコミッショニング返答コマンドを生成できなければならない。

パラメーター存在フィールドは、コマンド内に存在する構成パラメーターを保有するフィールドを示す。パラメーター存在フィールドの意味を下表に示す。

オプションフィールドのＺＧＰＤリストサイズサブフィールドの値は、新しい構成パラメーターが送られなければならないＺＧＰＤの数に等しい。値０ｂ００００は、リストが空であることを示し、値０ｂ１１１１は、受信デバイスが知っている全てのＺＧＰＤに送信が必要であることを示す。

ＴｅｍｐＭａｓｔｅｒ選択実行（ＰｅｒｆｏｒｍＴｅｍｐＭａｓｔｅｒＥｌｅｃｔｉｏｎ）フラグの値が０ｂ０の場合、デバイスは更新を送信する（すなわち、デバイスはＮＷＫ ＭｇｒによってＴｅｍｐＭａｓｔｅｒとして選択された）。値が０ｂ１の場合、受信デバイスはまずＴｅｍｐＭａｓｔｅｒ選択を実行する。オプションフィールドのＡｃｋＲｅｑｕｅｓｔサブフィールドが値０ｂ１を有する場合、ＺｉｇＢｅｅ保守デバイスは、チャンネル更新が送信されたＺＧＰＤのＳｒｃＩＤを受信することに関心がある。サブフィールドが値０ｂ０を有する場合、ＺｉｇＢｅｅ保守デバイスはこれらのＳｒｃＩＤを受信することに関心がない。

更新時間フィールドは、ＺＧＰＤに更新を送信可能な時間（ｍｓ単位）を示す。スイッチ時間フィールドの値０ｘｆｆｆｆは、未定義を示す。この値が失効し、最新のパラメータースイッチにおいて、受信デバイスは未送信のＺＧＰＤコマンドをｚｇｐＴｘＱｕｅｕｅから除去し得る。

新しいチャンネルフィールドは、使用チャンネルのための新しい値を保有する。新しいチャンネルフィールドは、以下の値を取り得る：０ｂｘｘｘｘ００００はチャンネル１１、０ｂｘｘｘｘ０００１はチャンネル１２、…、０ｂｘｘｘｘ１１１１はチャンネル２６。

新しいキーフィールドは、ＺｉｇＢｅｅネットワークキーの新しい値を保有する。

新しいＰＡＮＩｄフィールドは、ＰＡＮＩｄパラメーターの新しい値を保有する。

ＺＧＰＤリストフィールドは、３２ビット符号なし整数のＺＧＰＤリストサイズセットからなり、各整数はＺＧＰＤのＳｒｃＩＤを表す。ＺＧＰＤリストサイズが値０ｂ１１１１を有する場合、ＺＧＰリストは欠落しており、受信デバイスが知っている全てのＺＧＰデバイスに送信がなされなければならない。

ＺＧＰシステムメンテナンス警告コマンドをいくらか拡張することができる。要求される確認のさらなる詳細を提供することができる。確認タイプをリクエストし、ＺＧＰ更新状態コマンドと合わせることができる。確認タイプは、例えば以下を含む。
・０１０：ＺＧＰＤに送信されたＺＧＰＤコマンド
・１００：受信したＺＧＰＤからの受信確認
・１１０：新しいパラメーターを使用するために見られるＺＧＰＤ
全てのＺＧＰＤを更新した後、又は所定の時間において、（例えばＺＧＰＤ毎の）確認時間をリクエストすることもできる。

さらに、追加のオプションサブフィールドを定義することができ、これは配信されるキーのタイプ（ＺｉｇＢｅｅ ＮＷＫキー、派生ＺＧＰＤグループキー、独立ＺＧＰＤグループキー又はＺＧＰ ＴＣ−ＬＫ）の特定を可能にする。

２ビットのパラメーター存在（ＰａｒａｍｅｔｅｒｓＰｒｅｓｅｎｃｅ）サブフィールドの代わりに３ビットを用いて３つのフィールドの各々の存在／不在を独立して示してもよい。

ＺＧＰＤＳｒｃＩＤのセットの形式のＺＧＰＤリストサイズサブフィールド及びＺＧＰＤリストフィールドの代わりに、ＺＧＰＤリストサイズサブフィールドをスキップして、ＺＧＰＤリストフィールドに複雑な長さ表示データ型を用いてもよい（例えば、符号なし３２ビット整数アレイ）。

本発明は、ＺＧＰ応答コマンドの拡張を提案する。現行のＺＧＰ仕様において、ＺＧＰ応答コマンドは、ＺＧＰＤに送信されるべきＺＧＰＤコマンドを、発信側のシンクから、シンクによって選択されたＴｅｍｐＭａｓｔｅｒプロキシへトンネルするために用いられる。ＺＧＰ内のＺＧＰ応答コマンドの記載を図２Ａに示す。

ＺＧＰＰ短縮アドレスフィールドは、ＺＧＰＤに応答ＧＰＤＦを送信するＺＧＰＰのアドレスを示す。

ＺＧＰＰＴｘチャンネルフィールドは、ＺＧＰＤコマンドを保有するＧｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ Ｆｒａｍｅ（ＧＰＤＦ）が送信されるチャンネルを示す。フォーマットは図２Ｂのようになる。ＺＧＰＰ短縮アドレスフィールドが０ｘｆｆｆｆに設定される場合、ＺＧＰＰＴｘチャンネルフィールドは無視されるべきである。ＺＧＰＰＴｘチャンネルフィールドの送信チャンネル（ＴｒａｎｓｍｉｔＣｈａｎｎｅｌ）サブフィールドは、使用チャンネルの値を保有できる。

ＺＧＰＤＳｒｃＩＤフィールドは、ＧＰＤＦフレームが意図するＺＧＰＤのＩＤを保有する。

ＺＧＰＤコマンドＩＤフィールド及びＺＧＰＤコマンドペイロードフィールドは、対応するＧＰＤＦフィールドのための入力を保有する。

ＺＧＰＤコマンドペイロードフィールドは、オクテット列である。最初のオクテットは、ペイロード長を保持し、後続のオクテットはＧＰＤＦフィールドＺＧＰＤコマンドペイロードの値を保持する。値０ｘｆｆは、指定なし／ペイロードなしを示す。

本発明は、
・ＺＧＰＰ短縮アドレスフィールドをＴｅｍｐＭａｓｔｅｒ短縮アドレスフィールドに、
・ＺＧＰＰ ＴｘチャンネルフィールドをＴｅｍｐＭａｓｔｅｒ Ｔｘチャンネルに、
リネームし、
・係属の更新のプロパティ及びリクエストされたプロセスの実行方法を示すオプションフィールド、
・配信ＴｅｍｐＭａｓｔｅｒ選択の場合に品質を保証するためのＴｅｍｐＭａｓｔｅｒ距離フィールド（ＴｅｍｐＭａｓｔｅｒ距離フィールドは、ＺＧＰＤ ＳｒｃＩＤフィールド内のＳｒｃＩＤを有するＺＧＰＤとＴｅｍｐＭａｓｔｅｒ短縮アドレスフィールド内の短縮アドレスを有するデバイスとの間の（後者のデバイスによって測定された）距離（ｍ単位）を示す）、及び
・更新を送信するための時間がいくらあるかを示すＴｉｍｅＯｕｔフィールド（ＴｉｍｅＯｕｔフィールドは、経過後に未送信のＺＧＰＤコマンドがｚｇｐＴｘＱｕｅｕｅから除去できる時間（ｍｓ単位）を示す）を追加することによって、ＺＧＰ応答コマンドを図３Ａ及び３Ｂ（オプションフィールド）に示すように改変する。

オプションフィールドにおいて、オプションフィールドのＡｃｋＲｅｑｕｅｓｔサブフィールドの値０ｂ１は、ＺＧＰＤが送信されるとＺＧＰ応答コマンドの発信側が受信確認を予期することを示し、値０ｂ０は、受信確認が予期されないことを示す。

優先ＺＧＰＤコマンドサブフィールドは、０ｂ１に設定された場合、（ｚｇｐＴｘＱｕｅｕｅに保存されるべき）ＺＧＰＤコマンドが優先情報（例えばチャンネル／キー更新又はコミッショニングコマンド等）を保有し、非優先コマンドによって上書きされるべきではないことを示す。

ここで説明される追加のＺＧＰ応答コマンドフィールドは、ＺＧＰＤへの送信の他のケース、例えばコミッショニング動作又はＺＧＰＤへのデータの送信のために用いることもできる。例えば、ＴｉｍｅＯｕｔはｚｇｐＴｘＱｕｅｕｅを管理するために用いることができ、ＡｃｋＲｅｑｕｅｓｔは、ＺＧＰパラメーター更新状態コマンドとともに、ＺＧＰＤ−ＴｅｍｐＭａｓｔｅｒリンクの信頼性を評価するために用いることができる。

本発明は、改変されたＺＧＰ応答コマンドのさらなる拡張を提案する。

要求される確認に関するさらなる詳細を提供できる。例えば、以下のアイテムを含む確認タイプをリクエストすること（及びＺＧＰ更新状態コマンドと合わせること）ができる。
・０１０：ＺＧＰＤコマンドが送信された
・１００：ＺＧＰＤからの受信確認が受信された
・１１０：ＺＧＰＤの新しいパラメーターの使用が確認された
リストされた全てのＺＧＰＤの更新後、リストされた全てのＺＧＰＤを所定のパーセント更新した後、及び所定の時間において、（例えばＺＧＰＤ毎の）確認時間もリクエストすることができる。

ＴｉｍｅＯｕｔフィールドの存在は任意でもよく、オプションフィールド内の対応するフラグによって、又はＴｅｍｐＭａｓｔｅｒ短縮アドレスフィールドの適切な値（例えば、０ｘｆｆｆｆとは異なる値）によって示すことができる。

ＴｅｍｐＭａｓｔｅｒ距離フィールドの存在は任意でもよく、オプションフィールド内の対応するフラグ、又はＴｅｍｐＭａｓｔｅｒ短縮アドレスフィールドの適切な値（例えば、０ｘｆｆｆｆとは異なる値）によって示すことができる。

ＴｅｍｐＭａｓｔｅｒ選択のために用いられる追加の基準はコマンド内に含まれてもよく、例えば、ＴｅｍｐＭａｓｔｅｒ情報（すなわち、ＴｅｍｐＭａｓｔｅｒ選択に用いられたＺＧＰＤシーケンス番号／フレームカウンタ）の鮮度である。

本発明は、図４Ａ及び４Ｂに示されるような新しいＺＧＰパラメーター更新状態コマンドを提案する。

キー更新報告サブフィールド、チャンネル更新報告サブフィールド、及びＰＡＮＩｄ更新報告サブフィールドが０ｂ１に設定された場合、コマンドが対応するパラメーターの更新状態を含むことを示す。

ＺＧＰパラメーター更新状態コマンドのオプションフィールドの更新状態サブフィールドは、以下の値を取ることができる。
・０００ - 更新されていない：ＺＧＰＤ受信不可
・００１ - 更新されていない：ＺＧＰＤ受信可能
・１０１ - 更新されていない：パラメーター変更をＺＧＰＤに伝える必要がない
・０１０ - ＺＧＰＤコマンドが送信された
・１００ - ＺＧＰＤからの受信確認が受信された
・１１０ - ＺＧＰＤが新しいパラメーターを使用することが確認された
・１１１ - 更新基準達成
・その他 - 予備

オプションフィールドのＺＧＰＤリストサイズサブフィールドは、ＺＧＰＤリストフィールド内に存在するＺＧＰＤＳｒｃＩＤの数を示す。値０ｂ００００はリストが空であることを示し、値０ｂ１１１１は、発信側デバイスが全てのＺＧＰＤを知っていることを示す。ＺＧＰＤリストは、ＺＧＰシステム更新警告コマンドからのＺＧＰＤリストが受信された場合、必ずしもこれと等しくなくてもよいが、オプションサブフィールドに示される更新状態付きのＺＧＰＤデバイスを保持する。ＺＧＰＤＳｒｃＩＤのセットの形式のＺＧＰＤリストサイズサブフィールド及びＺＧＰＤリストフィールドの代わりに、ＺＧＰＤリストサイズサブフィールドをスキップし、複雑な長さ表示データ型ＺＧＰＤリストフィールドを用いることもでき、例えば符号なし３２ビット整数アレイである。

以下にＺｉｇＢｅｅチャンネル更新の異なる実施形態を提供する。以下に示す実施形態はあくまで例であり、特許請求の範囲に記載の本特許の範囲を制限するものではない。

第１実施例は、半中央（半集中）されたＴｅｍｐＭａｓｔｅｒ選択を有するチャンネル更新である。必要条件は、ＺｉｇＢｅｅ保守エンティティ（この場合、ＺｉｇＢｅｅネットワークマネージャー又はＺｉｇＢｅｅ ＰＡＮコーディネータ）がネットワークにおけるＺＧＰＤの存在について知っていることと、ＺｉｇＢｅｅ保守エンティティが、各ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤについて、そのＺＧＰＤによって制御される少なくとも１つのＺＧＰＳを知っている（例えば、コミッショニングの結果より、又は計画、グループ割り付けに基づいて、又はシンクテーブルの読み出しに基づいて）ことである。ＺｉｇＢｅｅ保守エンティティは、さらに、いつＺｉｇＢｅｅパラメーター更新を行うかのポリシー基準をいくつか有する（例えば、ＺＧＰＤＴｉｍｅＯｕｔ経過後、又は所与のＺＧＰＤのサブセットの所与のパーセントが正しく更新された）。

第１ステップでは、ＺｉｇＢｅｅ保守エンティティはＺＧＰシステム保守警告コマンドを選択されたシンクセットに送信する。ＺｉｇＢｅｅ保守エンティティは、各ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤが、ちょうど１つの送信ＺＧＰシステム保守警告コマンドのＺＧＰＤリスト内に存在するよう、シンクのセット及びこれらのシンクのためのＺＧＰＤリストを決定する。パラメーター存在サブフィールドは、新しいチャンネルフィールドが存在することを示す。新しいチャンネルフィールドは、新しい使用チャンネルの値を示す。ＴｅｍｐＭａｓｔｅｒ選択実行サブフィールドは０ｂ１に設定される。ＡｃｋＲｅｑｕｅｓｔサブフィールドは、ＺｉｇＢｅｅ保守エンティティの更新ポリシー基準に基づいて設定される。

第２ステップでは、ＺＧＰシステム保守警告コマンドを受信する各シンクが、ＴｅｍｐＭａｓｔｅｒの決定及びＺＧＰＤチャンネル構成コマンドの作成という２つのサブステップを実行する（実行の順番は関係ない）。オプションとして、各シンクはＺＧＰＤリストフィールド内の全ＺＧＰＤのＲｘＯｎ能力を調べ、真であるもののみ更新のために選択する。各シンクは、各更新されるべきＺＧＰＤのＴｅｍｐＭａｓｔｅｒを決定する。

シンクは他のシンクをＴｅｍｐＭａｓｔｅｒに選択し得ることに留意されたい。これは、最初のシンクが選択されたＴｅｍｐＭａｓｔｅｒシンク（例えばＺＧＰＣｍ）がＺＧＰＤの範囲内にあるか（また、オプションでそれとペアにされているか）を判定する手段を有する場合に可能である。

ＺＧＰシステム保守警告コマンドを受信するシンクは、各更新されるべきＺＧＰＤ毎にＺＧＰ仕様に基づいてＺＧＰＤチャンネル構成コマンドを作成し、チャンネルフィールドの使用チャンネルサブフィールドの値は、ＺＧＰシステム保守警告コマンドからの新しいチャンネルフィールドの値に設定される。選択されたＴｅｍｐＭａｓｔｅｒが他のデバイス（プロキシ又はシンク）である場合、シンクは、ＺＧＰ応答コマンドを送信する。ＺＧＰ応答コマンドのＡｃｋＲｅｑｕｅｓｔサブフィールド及び他の関連する（サブ）フィールドの値は、ＺＧＰシステム保守警告コマンド内の対応する（サブ）フィールドの値に設定される。優先ＺＧＰＤコマンドサブフィールドは、０ｂ１に設定される。ＴｉｍｅＯｕｔフィールドは、ＺＧＰシステム保守警告コマンド内の更新時間フィールドと等しい値を有する。ＺＧＰコマンドＩＤフィールド及びＺＧＰＤコマンドペイロードフィールドは、上記のようにして決定された値を有する。

第３ステップでは、各ＴｅｍｐＭａｓｔｅｒがＺＧＰＤのＺＧＰＤコマンドをｚｇｐＴｘＱｕｅｕｅ内に配置する。これは、優先度ビットに基づいて行われ、すなわち、ｚｇｐＴｘＱｕｅｕｅ内にすでにこのＳｒｃＩＤのエントリーがある場合、そのエントリーは、古いメッセージが優先度ビットセットを有するか否かに関わらず、現在のＺＧＰＤチャンネル構成コマンドと置き換えられる。シンク自身がＴｅｍｐＭａｓｔｅｒである場合、シンクは優先ＺＧＰＤコマンドサブフィールドが０ｂ１に設定されたＺＧＰ応答コマンドを受信したかのように動作する。

第４ステップでは、いくつかのＺＧＰＤにとってＴｅｍｐＭａｓｔｅｒである各ＺＧＰＰ及びＺＧＰＳが、ＺＧＰ応答コマンド／ＺＧＰシステム保守警告コマンドの受信からＴｉｍｅＯｕｔ（ｍｓ）が経過する前、機会がある時にいつでも、自身がＴｅｍｐＭａｓｔｅｒである各ＺＧＰＤにＺＧＰＤコマンドを送信する。

第５ステップでは、ＡｃｋＲｅｑｕｅｓｔサブフィールドが値０ｂ１を有する場合、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤチャンネル構成コマンドをＺＧＰＤに送信したときは常に、適切な更新状態値を有するＺＧＰパラメーター更新状態コマンドを送信することによってＺｉＢｅｅ保守エンティティに通知する。

第６ステップでは、更新のポリシー基準が満たされている場合、ＺｉｇＢｅｅ保守エンティティはＺｉｇＢｅｅパラメーター更新をトリガする。ＺＧＰインフラノードは、ＺｉｇＢｅｅロール内のＺｉｇＢｅｅプロトコルに従う。遅くとも、新しいパラメーターの使用が開始されたときには、未送信の優先エントリーがｚｇｐＴｘＱｕｅｕｅから除去され得る。

他の実施例は、分配ＴｅｍｐＭａｓｔｅｒ選択を有するチャンネル更新である。必要条件は、ＺｉｇＢｅｅ保守エンティティ（この場合はネットワークマネージャー又はＺｉｇＢｅｅ ＰＡＮコーディネータ）がネットワーク内のＺＧＰＤの存在を知っていること、及び、ＺｉｇＢｅｅ保守エンティティが要求されるパラメーター更新のためのＺＧＰシステム保守警告コマンドを送信可能であることである。また、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅパラメーター更新をいつ実行するかのポリシー基準をいくつか有する（例えば、ＺＧＰＤＴｉｍｅＯｕｔが経過した、又はＺＧＰＤの所与のサブセットの所与のパーセントが正しく更新された）。

第１ステップでは、ＺｉｇＢｅｅ保守エンティティはブロードキャストによってＺＧＰシステム保守警告コマンドを送信する。パラメーター存在サブフィールドは、新しいチャンネルフィールドが存在することを示す。ＡｃｋＲｅｑｕｅｓｔフィールドは、ＺｉｇＢｅｅ保守エンティティの更新ポリシー基準に従って設定される。ＴｅｍｐＭａｓｔｅｒ選択実行サブフィールドは、０ｂ１に設定される。ＺＧＰＤリストサイズは０ｂ１１１１に設定され、これは「全て」を示す。新しいチャンネル（ＮｅｗＣｈａｎｎｅｌ）フィールドは、新しい使用チャンネルの値を示す。

第２ステップでは、ＺＧＰシステム保守警告コマンドを受信する各シンクは、ペアを組む各ＺＧＰＤについて、以下のサブステップを行う。ＴｅｍｐＭａｓｔｅｒを決定するステップ及びＺＧＰＤチャンネル構成コマンドを作成するステップを実行する順番は無関係（任意）である。
・ＺＧＰＤのＲｘＯｎ能力を調べる。
・ＲｘＯｎ能力が真である場合、ＴｅｍｐＭａｓｔｅｒを決定する。シンクは他のシンクをＴｅｍｐＭａｓｔｅｒに選択してもよい。これは、最初のシンクが、選択されたＴｅｍｐＭａｓｔｅｒシンク（例えばＺＧＰＣｍ）がＺＧＰＤのレンジ内にあるか（また、オプションでそれとペアにされているか）を判定する手段を有する場合に可能である。
・チャンネルフィールドの使用チャンネルサブフィールドの値をＺＧＰシステム保守警告コマンドからの新しいチャンネルフィールドの値に設定し、ＺＧＰＤチャンネル構成コマンドを作成する。
・ＴｅｍｐＭａｓｔｅｒがプロキシ又はシンク自身であるか否かに関わらず、上記ＴｅｍｐＭａｓｔｅｒを知らせるために、ブロードキャストでＺＧＰ応答コマンドを送信する。ＺＧＰ応答コマンドは、ＺＧＰＤＳｒｃＩＤフィールド内に指示されたＺＧＰＤのための、ＴｅｍｐＭａｓｔｅｒ短縮アドレスフィールド内に選択されたＴｅｍｐＭａｓｔｅｒのアドレスを保有する（シンク自身がＴｅｍｐＭａｓｔｅｒであったとしても）。また、ＴｅｍｐＭａｓｔｅｒ距離フィールド内には、ＴｅｍｐＭａｓｔｅｒによって測定されたＺＧＰＤとＴｅｍｐＭａｓｔｅｒとの間の距離を保有する。ＺＧＰ応答コマンドのＡｃｋＲｅｑｕｅｓｔサブフィールドの値は、ＺＧＰシステム保守警告コマンド内の対応するサブフィールドの値に設定される。優先ＺＧＤＰコマンドサブフィールドは０ｂ１に設定される。ＴｉｍｅＯｕｔフィールドは、ＺＧＰシステム保守警告コマンド内の更新時間フィールドに等しい値を有する。ＺＧＰＤコマンドＩＤフィールド及びＺＧＰＤコマンドペイロードフィールドは上記のようにして決定された値を有する。

シンクが同じＺＧＰＤの優先更新のためのＺＧＰＤ応答を受信した場合、より良いＴｅｍｐＭａｓｔｅｒ候補がある場合、（通信量を抑えるために）自身の予定されたＺＧＰ応答送信を取り下げてもよい。

第３ステップでは、各ＴｅｍｐＭａｓｔｅｒ（プロキシ／シンク）が、優先度ビットに従ってｚｇｐＴｘＱｕｅｕｅ内にＺＧＰＤのためのＺＧＰＤコマンドを配置する。同じＺＧＰＤのＺＧＰＤ応答を後で受信するとき、より良いＴｅｍｐＭａｓｔｅｒ候補がある場合、ＺＧＰパラメーター更新状態コマンドを送信することなくｚｇｐＴｘＱｕｅｕｅからエントリーを除去する。

第４ステップでは、各ＴｅｍｐＭａｓｔｅｒは、当該ＴｅｍｐＭａｓｔｅｒのｚｇｐＴｘＱｕｅｕｅへのＺＧＰＤコマンドの配置をトリガしたコマンド（ＺＧＰ応答コマンド／ＺＧＰシステム保守警告コマンド）の受信からＴｉｍｅＯｕｔ（ｍｓ）が経過していない期間、機会があるときにいつでも、自身がＴｅｍｐＭａｓｔｅｒである各ＺＧＰＤにＺＧＰＤコマンドを送信する。

第５ステップでは、ＡｃｋＲｅｑｕｅｓｔサブフィールドが値０ｂ１を有する場合、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤチャンネル構成コマンドを送信した時にはいつも、適切な更新状態値を有するＺＧＰパラメーター更新状態コマンドを送信することによってＺｉｇＢｅｅ保守エンティティに通知を行う。

第６ステップでは、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅパラメーター更新をトリガする。ＺＧＰインフラノードは、ＺｉｇＢｅｅロール内のＺｉｇＢｅｅプロトコルに従う。遅くとも新しいパラメーターとのリブートの際には、未送信の優先エントリーがｚｇｐＴｘＱｕｅｕｅから除去され得る。

他の実施例は、中央ＴｅｍｐＭａｓｔｅｒ選択を有するチャンネル更新である。

第１変形例のための必要条件を以下に示す。ＺｉｇＢｅｅ保守エンティティ（この場合はネットワークマネージャー又はＺｉｇＢｅｅＰＡＮコーディネータ）がネットワーク内のＺＧＰＤの存在を知っており、要求されるパラメーター更新のためのＺＧＰＤコマンド（この場合はＺＧＰＤチャンネル構成コマンド）を生成可能である。ＺｉｇＢｅｅ保守エンティティは、各ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤのＴｅｍｐＭａｓｔｅｒに関する知識を有している（例えば、コミッショニングの結果、又はネットワーク計画に基づいて、又はシンク／プロキシテーブルの読み出しに基づいて）。ＺｉｇＢｅｅ保守エンティティは、さらに、いつＺｉｇＢｅｅパラメーター更新を行うかのポリシー基準をいくつか有する（例えば、ＺＧＰＤＴｉｍｅＯｕｔが経過した、又はＺＧＰＤの所与のサブセットの所与のパーセントが正しく更新された）。

第１ステップでは、ＺｉｇＢｅｅ保守エンティティは、各ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤ毎に１つのＺＧＰ応答コマンドが生成されるように、ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤのＴｅｍｐＭａｓｔｅｒのセットを決定する。

第２ステップでは、ＺｉｇＢｅｅ保守エンティティは、ＺＧＰ応答コマンドを、好ましくはユニキャストによって、選択されたＴｅｍｐＭａｓｔｅｒ（シンク又はプロキシ）のセットに送信する。ＺＧＰ応答コマンドは、使用チャンネル更新及び送信先のＺＧＰＤＳｒｃＩＤのためのＺＧＰＤチャンネル構成コマンドを保持する。優先ＺＧＰＤコマンドフィールドは、０ｂ１に設定される。ＡｃｋＲｅｑｕｅｓｔフィールドは、ＺｉｇＢｅｅ保守エンティティの更新ポリシー基準に従って設定される。

第３ステップでは、受信されるＺＧＰ応答コマンド毎に、ＴｅｍｐＭａｓｔｅｒはＺＧＰＤのＲｘＯｎ能力をチェックし、真であった場合には優先度ビットに従ってＺＧＰＤコマンドをｚｇｐＴｘＱｕｅｕｅ内に配置する。

第４ステップでは、各ＴｅｍｐＭａｓｔｅｒは、ＺＧＰ応答コマンドの受信から更新時間（ｍｓ）が経過していない期間、機会がある時にはいつでも、自身がＴｅｍｐＭａｓｔｅｒである各ＺＧＰＤにＺＧＰＤコマンド送信する。

第５ステップでは、ＡｃｋＲｅｑｕｅｓｔサブフィールドが値０ｂ１を有する場合、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤチャンネル構成コマンドを送信する際には常に、適切な更新状態値を有するパラメーター更新状態コマンドを送信することによって、ＺｉｇＢｅｅ保守エンティティに通知を行う。

第６ステップでは、ＺｉｇＢｅｅ保守エンティティは、更新ポリシー基準が満たされるとＺｉｇＢｅｅパラメーター更新をトリガする。ＺＧＰインフラノードは、ＺｉｇＢｅｅロール内のＺｉｇＢｅｅプロトコルに従う。遅くとも、新しいパラメーターとのリブートの際には、ｚｇｐＴｘＱｕｅｕｅから未送信のエントリーが除去され得る。

第７ステップでは、いくつかのＲｘＡｆｔｅｒＴｘ可能デバイスが更新されなかった場合、チャンネル切り替えが有効化された後にＺＧＰ応答を用いてＺＧＰＤの更新を（再度）トライしてもよい。この場合、ＴｅｍｐＭａｓｔｅｒＴｘチャンネルは古い使用チャンネルに設定されるべきである。

同じ実施例の他の変形例は以下の通りである。必要条件は、ＺｉｇＢｅｅ保守エンティティ（この場合は、ネットワークマネージャー又はＺｉｇＢｅｅＰＡＮコーディネータ）がネットワーク内のＺＧＰＤの存在を知っており、各ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤのＴｅｍｐＭａｓｔｅｒに関する知識を有する（例えば、コミッショニングの結果、又はネットワーク計画に基づいて、又はシンク／プロキシの読み出しに基づいて）が、ＺＧＰシステム保守コマンドを生成する能力のみ有することである。ＺｉｇＢｅｅ保守エンティティは、さらに、いつＺｉｇＢｅｅパラメーター更新を実行するかのポリシー基準をいくつか有している（例えば、ＺＧＰＤＴｉｍｅＯｕｔが経過した、又は所与のＺＧＰＤのサブセットが所与のパーセント正しく更新された）。

第１ステップでは、ＺｉｇＢｅｅ保守エンティティは、新しいチャンネルフィールドを有するＺＧＰシステム保守警告コマンドを、好ましくはユニキャストによって、選択されたＴｅｍｐＭａｓｔｅｒ（シンク又はプロキシ）のセットに送信する。ＺｉｇＢｅｅ保守エンティティは、各ＲｘＡｆｔｅｒＴｘ可能ＺＧＰＤが、ちょうど１つの送信ＺＧＰシステム保守警告コマンドのＺＧＰＤリスト内に存在するように、ＴｅｍｐＭａｓｔｅｒのセット及びこれらのＴｅｍｐＭａｓｔｅｒのＺＧＰＤリストを決定する。ＴｅｍｐＭａｓｔｅｒ選択実行サブフィールドは、０ｂ０に設定される。ＡｃｋＲｅｑｕｅｓｔサブフィールド及び更新時間フィールドは、ＺｉｇＢｅｅ保守エンティティの更新ポリシー基準に従って設定される。

第２ステップでは、各ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤのＲｘＯｎ能力をチェックし、真である場合は、使用チャンネルサブフィールドの値がＺＧＰシステム保守警告コマンドからの新しいチャンネルフィールドの値に設定されるようＺＧＰに従ってＺＧＰＤチャンネル構成コマンドを作成し、優先度ビットに従ってＺＧＰＤコマンドをｚｇｐＴｘＱｕｅｕｅ内に配置する。プロキシについては、ＺＧＰＤ更新コマンドを作成する新しい能力を要求することに留意されたい（現在のＺＧＰ仕様では要求されない）。

第３ステップでは、各ＴｅｍｐＭａｓｔｅｒは、ＺＧＰシステム保守警告コマンドの受信から更新時間ｍｓが経過していない期間、機会があるときはいつでも、ＺＧＰＤコマンドをＺＧＰＤリスト内の各ＺＧＰＤに送信する。

第４ステップでは、ＡｃｋＲｅｑｕｅｓｔサブフィールドが値０ｂ１を有する場合、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤチャンネル構成コマンドを送信する際にはいつも、適切な更新状態値を有するパラメーター更新状態コマンドを送信することによって、ＺｉｇＢｅｅ保守エンティティに通知を行う。

第５ステップでは、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅパラメーター更新をトリガする。ＺＧＰインフラノードは、ＺｉｇＢｅｅロール内のＺｉｇＢｅｅプロトコルに従う。遅くとも、新しいパラメーターとのリブートの際には、ｚｇｐＴｘＱｕｅｕｅから未送信の優先エントリーが除去され得る。

ＺｉｇＢｅｅ保守エンティティとＺＧＰＤ保守エンティティとの協力を有する、チャンネル更新の他の実施例を提供する。必要条件は、ＺｉｇＢｅｅ保守エンティティ（この場合、ネットワークマネージャー又はＺｉｇＢｅｅＰＡＮコーディネータ）がネットワーク内のＺＧＰＤ保守エンティティの存在を知っていること、ＺＧＰＤ保守エンティティにＺＧＰシステム保守警告を送信できること、及び、ＺｉｇＢｅｅパラメーター更新を延期するポリシー基準を有することである。ＺＧＰＤ保守エンティティは、ＴｅｍｐＭａｓｔｅｒに関する知識を有し、少なくとも各ＲｆＡｆｔｅｒＴｘ可能ＺＧＰＤについて知っている（例えば、コミッショニングによる結果、又はネットワーク計画に基づいて、又はシンク／プロキシテーブルの読み出しに基づいて）。

第１ステップでは、ＺｉｇＢｅｅ保守エンティティはＺＧＰシステム保守警告コマンドをＺＧＰＤ保守エンティティに送信する。パラメーター存在サブフィールドは、新しいチャンネルフィールドが存在することを示す。新しいチャンネルフィールドは、新しい使用チャンネルの値を保有する。実行ＴｅｍｐＭａｓｔｅｒ選択サブフィールドは、０ｂ１に設定される。ＡｃｋＲｅｑｕｅｓｔサブフィールドは、ＺｉｇＢｅｅ保守エンティティの更新ポリシー基準に従って設定され、好ましくは、確認タイプ及び時間に関する拡張要求が使用される。

第２ステップでは、ＺＧＰＤ保守エンティティは、各ＺＧＰＤ毎に以下のステップを実行する。
・ＺＧＰＤのＲｘＯｎ能力を調べる。
・ＲｘＯｎ能力が真である場合、ＴｅｍｐＭａｓｔｅｒを決定する。
・チャンネルフィールドの使用チャンネルサブフィールドの値がＺＧＰシステム保守警告コマンドからの新しいチャンネルフィールドの値に設定されるよう、ＺＧＰＤチャンネル構成コマンドを作成する。
・ＺＧＰ応答コマンドを、好ましくはユニキャストによって、選択されたＴｅｍｐＭａｓｔｅｒに送信する。ＺＧＰ応答コマンドは、ＴｅｍｐＭａｓｔｅｒ短縮アドレスフィールド内に、ＺＧＰＤＳｒｃＩＤフィールド内に示された当該ＺＧＰＤの選択されたＴｅｍｐＭａｓｔｅｒのアドレス（当該シンク自身がＴｅｍｐＭａｓｔｅｒであったとしても）を保有し、ＴｅｍｐＭａｓｔｅｒ距離フィールド内に、ＴｅｍｐＭａｓｔｅｒによって測定されたＺＧＰＤとＴｅｍｐＭａｓｔｅｒとの間の距離を保有する。ＺＧＰ応答コマンドのＡｃｋＲｅｑｕｅｓｔサブフィールドの値は、ＺＧＰシステム保守警告コマンド内の対応するサブフィールドの値に設定される。優先ＺＧＰＤコマンドサブフィールドは０ｂ１に設定される。ＴｉｍｅＯｕｔフィールドは、ＺＧＰシステム保守警告コマンド内の更新時間フィールドと等しい値を有する。ＺＧＰＤコマンドＩＤフィールド及びＺＧＰＤコマンドペイロードフィールドは、上記のようにして決定された値を有する。

第３ステップでは、ＴｅｍｐＭａｓｔｅｒは、各受信されたＺＧＰ応答コマンドについてＺＧＰＤのＲｘＯｎ能力をチェックし、真である場合は優先度ビットに従ってｚｇｐＴｘＱｕｅｕｅ内にＺＧＰＤコマンドを配置する。

第４ステップでは、各ＴｅｍｐＭａｓｔｅｒは、ＺＧＰ応答コマンドの受信からＴｉｍｅＯｕｔ（ｍｓ）が経過していない期間、機会がある時にはいつでも、自身がＴｅｍｐＭａｓｔｅｒである各ＺＧＰＤにＺＧＰＤコマンドを送信する。

第５ステップでは、ＺＧＰ応答コマンドのＡｃｋＲｅｑｕｅｓｔサブフィールドの値が０ｂ１の場合、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤチャンネル構成コマンドを送信する際にはいつも、適切な更新状態値を有するＺＧＰパラメーター更新状態コマンドを送信することによってＺＧＰＤ保守エンティティに通知を行う。

第６ステップでは、ＺＧＰシステム保守警告コマンドによって確認がリクエストされた場合、（拡張された）確認基準が満たされると、ＺＧＰＤ保守エンティティは、ＺＧＰＤパラメーター更新の進捗をＺｉｇＢｅｅ保守エンティティに知らせる。

第７ステップでは、ＺｉｇＢｅｅ保守エンティティは更新進捗状況をチェックし、ＺｉｇＢｅｅパラメーター更新をトリガする。ＺＧＰＤ保守エンティティを含むＺＧＰインフラノードは、ＺｉｇＢｅｅロール内のＺｉｇＢｅｅプロトコルに従う。遅くとも、新しいパラメーターとのリブートの際には、ｚｇｐＴｘＱｕｅｕｅから未送信の優先エントリーが除去され得る。

第８ステップでは、いくつかのＲｘＡｆｔｅｒＴｘ可能デバイスが更新されなかった場合、ＺＧＰＤ保守エンティティは、チャンネルスイッチが有効化された後にＺＧＰ応答を送信し、ＺＧＰＤの更新を（再度）トライすることができる。その後、ＺＧＰ応答のＴｅｍｐＭａｓｔｅｒＴｘチャンネルフィールドは古い使用チャンネルに設定されるべきである。

上記実施例の組み合わせも実施可能であり、いくつかの選択されたＺＧＰＤに関しては、ペアを組むシンク／選択されたＴｅｍｐＭａｓｔｅｒにユニキャストＺＧＰシステム保守警告／ＺＧＰ応答が送信され、他のＺＧＰＤに関しては、グループキャスト／ブロードキャストＺＧＰシステム保守警告コマンドが送信されるか、又は更新リクエストが送信されない。他の更新パラメーター（例えば、確認のために必要なもの）もＺＧＰＤ毎に異なり得る。更新を行う方法は、ＺＧＰＤ能力、例えばロケーション、重要性、機能性等に依存する。

更新プロセスは繰り返されてもよい。選択されたシンク／ＴｅｍｐＭａｓｔｅｒが更新関連ＺＧＰコマンドによってリクエストされた能力を有しない場合（例えば、双方向通信をサポートしないシンク／プロキシ、ＺＧＰＤとペアにされていないシンク／プロキシ、ＴｅｍｐＭａｓｔｅｒとして指名されたＺＧＰＴ等）、選択されたシンク／ＴｅｍｐＭａｓｔｅｒは適切なエラー状態を示す標準ＺＣＬ応答で応じ、新しいデバイスを指名してもよい。

ＰＡＮＩｄ更新は、チャンネル更新と同様に実行することができる。新しいＰＡＮＩｄフィールドを保有するＺＧＰシステム保守警告コマンド、及びＺＧＰＤコミッショニング返答コマンドを保有するＺＧＰ応答コマンドを、連続してＺＧＰＤに送信する。

受信能力を持たないＺＧＰＤ及びＰＡＮＩｄを用いないＺＧＰＤに関しては、ＰＡＮＩｄ更新（トライ）をスキップしてもよい（デフォルトでは、ＺＧＰ仕様はＰＡＮＩｄ０ｘｆｆｆｆの使用を許可する）。

ＺｉｇＢｅｅＮＷＫキー更新によるＺＧＰＤキー更新は、チャンネル更新と同様にして実行できる。新しいキーフィールドを保有するＺＧＰシステム保守警告コマンド、及びＺＧＰＤコミッショニング返答コマンドを保有するＺＧＰ応答コマンドを、ＺＧＰＤに連続して送信する。

受信能力を持たないＺＧＰＤ、及び非派生キータイプを用いるＺＧＰＤに関しては、ＺｉｇＢｅｅＮＷＫキー更新によるキー更新をスキップしてもよい。

ＺＧＰ仕様に、（ｚｇｐ共有セキュリティキーと同じフォーマットを有し得る）「交代ＺＧＰキー」属性を導入することを提案する。これは、キースイッチの後にもＺＧＰＤを新しいキーに更新する機会を、完全に分配して提供する。当然ながら、チャンネルに関しては、ＺｉｇＢｅｅ保守エンティティはキースイッチの後にも特定のＴｅｍｐＭａｓｔｅｒ／シンクを指名してＺＧＰＤを更新してもよい。

一部のＺＧＰデバイスが依然として古いキーを受け入れることによるセキュリティレベルと、手動による再コミッショニングを必要とするＺＧＰＤの数の制限との間の適切なバランスが取られるよう注意しなければならない。

ＺｉｇＢｅｅネットワークキー更新によってトリガされる更新と同様に、ＺＧＰＤ通信がネットワークキーの派生物を使用する場合、他のＺＧＰセキュリティキー、例えばｚｇｐ共有セキュリティキー、すなわち（独立した）ＺＧＰグループキー、キータイプ、又はｚｇｐリンクキーの更新も同じ方法で実行できる。

上記の例示的実施形態中の保守エンティティは、ネットワーク内において異なる他のロールを有すことができる。例えば、コーディネータに保守エンティティの機能を実行させてもよい。これに対して、保守エンティティは、これらの特定の能力を有する、例えばＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅネットワーク内の保守専用の異なるノード（例えば無電池デバイス）でもよい。下記でプロキシノードとして請求されるものは、ＺＧＰ仕様書（ＺｉｇＢｅｅ ｄｏｃｕｍｅｎｔ ０９５４９９ｒ１６ＺＢ）の名称に基づき、あらゆるＺＧＰインフラノード、すなわち、ＺＧＰプロキシ（ＺＧＰＰ）又はＺＧＰシンク（ＺＧＰＳ）でもよい。同様に、下記において、用語「結合された」は、ＺＧＰインフラデバイスとＺＧＰＤとが有し得るあらゆる関係、すなわち、シンクテーブルエントリー及び／又はアクティブプロキシテーブルエントリーを表すのに用いることができる。

開示の実施形態の他の変形例は、当業者が本発明を実施するにあたり、図面、明細書、及び特許請求の範囲から理解及び実施できる。特許請求の範囲において、用語「含む（有する又は備える）」は、他の要素又はステップを除外せず、要素は複数を除外しない。単一のプロセッサ又は他のユニットにより、請求項に記載される複数のアイテムの機能を達成することができる。互いに異なる独立請求項に手段が記載されているからといって、それらの手段を好適に組み合わせて用いることができないとは限らない。

上記は本発明のいくつかの実施形態を詳細に説明する。ただし、上述の記述が文章上ではいかに詳細に説明されているように見えたとしても、本発明は多様な方法で実行することができ、開示の実施形態には限定されない。本発明の特定の特徴又は側面を説明するために特定の用語が用いられる場合、用語は、用語が関連する発明の特徴及び側面の任意の特定の特徴を含むべく制限されるよう、明細書で改めて定義されているわけではないことに留意されたい。

Claims (15)

1. 保守エンティティ及び複数のノードを含むネットワークを構成する方法であって、当該方法は、保守エンティティにおいて、
   （ａ）所定の期間内にのみデータを受信可能な、少なくとも１つの制限されたノードの前記ネットワーク内の存在を検出するステップと、
   （ｂ）更新されたネットワーク構成パラメーター値が要求されるかを判定するステップであって、前記ネットワーク構成パラメーターは、前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに関して共通である、判定ステップと、
   （ｃ）前記ネットワーク内の前記少なくとも１つの制限されたノードの存在の前記検出に基づき、前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新する信号の送信を延期するステップと、
   （ｄ）前記延期するステップの一方で、プロキシノードが前記少なくとも１つの制限されたノードに結合され、前記少なくとも１つの制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信をトリガするトリガ信号を、各前記少なくとも１つの制限されたノードのちょうど１つのプロキシノードに送信するステップと、
   （ｅ）前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新する前記信号を送信するステップと
   を含むことを特徴とする、方法。
2. 前記ステップ（ａ）は、前記保守エンティティが、制限されたノードが前記ネットワーク内において動作可能か否かを内部レジスタを参照して調べるステップをさらに含む、請求項１に記載の方法。
3. 前記ステップ（ａ）は、プロキシノードが前記少なくとも１つの制限されたノードに結合されているか否かを調べ、前記制限されたノードのための新しいプロキシノード選択を開始するか否かを決定するステップをさらに含む、請求項２に記載の方法。
4. 保守エンティティ及び複数のノードを含むネットワークを構成する方法であって、当該方法は、保守エンティティにおいて、
   （ａ）所定の期間内にのみデータを受信可能な、少なくとも１つの制限されたノードの前記ネットワーク内の存在を検出するステップと、
   （ｂ）更新されたネットワーク構成パラメーター値が要求されるかを判定するステップであって、前記ネットワーク構成パラメーターは、前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに関して共通である、判定ステップと、
   （ｃ）前記ネットワーク内の前記少なくとも１つの制限されたノードの存在の前記検出に基づき、前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新する信号の送信を延期するステップと、
   （ｄ）前記延期するステップの一方で、第１ノードのセットに、前記制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信をトリガするトリガ信号を送信するステップであって、前記第１ノードのセット内の各ノードは、制限されたノードと通信し、前記トリガ信号は、前記第１ノードのセットに、制限されたノードのセットの各制限されたノードのためのプロキシノードを指名させ、前記プロキシノードは、該当する制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信の責任を負う、当該ステップと、
   （ｅ）前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新する前記信号を送信するステップと
   を含むことを特徴とする、方法。
5. 保守エンティティ及び複数のノードを含むネットワークを構成する方法であって、当該方法は、保守エンティティにおいて、
   （ａ）所定の期間内にのみデータを受信可能な、少なくとも１つの制限されたノードの前記ネットワーク内の存在を検出するステップと、
   （ｂ）更新されたネットワーク構成パラメーター値が要求されるかを判定するステップであって、前記ネットワーク構成パラメーターは、前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに関して共通である、判定ステップと、
   （ｃ）前記ネットワーク内の前記少なくとも１つの制限されたノードの存在の前記検出に基づき、前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新する信号の送信を延期するステップと、
   （ｄ）前記延期するステップの一方で、前記制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信をトリガするトリガ信号を、プロキシ選択ノードに送信するステップであって、前記更新されたネットワーク構成パラメーター値を前記プロキシ選択ノードに送信することによって前記制限されたノードのためのプロキシノード選択を開始するサブステップと、前記プロキシ選択ノードにおいて、前記プロキシノード選択を実行し、前記選択されたプロキシノードのセットに前記更新されたネットワーク構成パラメーター値を送信するサブステップとを含み、前記送信は、前記選択されたプロキシノードに、当該プロキシノードが関連する前記制限されたノードに前記更新されたネットワーク構成パラメーター値を送信する責任を負わせる、当該ステップと、
   （ｅ）前記複数のノードにおいて前記ネットワーク構成パラメーター値を更新する前記信号を送信するステップと
   を含む、
   方法。
6. 制限されたノードの更新に関連する少なくとも１つの更新基準が満たされるまで、前記複数のノードへの前記更新されたネットワーク構成パラメーター値の送信を延期するサブステップをさらに含む、請求項１乃至５のいずれか一項に記載の方法。
7. 前記更新基準は、前記保守エンティティにおける更新確認メッセージの受信に少なくとも部分的に基づき、前記更新確認メッセージは、前記制限されたノードによる前記更新されたネットワーク構成パラメーター値の受信の成功を示す、請求項６に記載の方法。
8. 前記更新基準は、前記ステップ（ｂ）から経過した時間と、前記ステップ（ｄ）から経過した時間と、前記ネットワーク構成パラメーター更新の優先レベルと、アプリケーション機能、ロケーション、能力、又は報告挙動を含む前記制限されたノードのプロパティと、更新確認メッセージが受信された制限されたノードの数又はプロパティと、更新を示す更新確認メッセージが送信され、送信プロセスがトリガされた制限されたノードの数又はプロパティと、使用中の更新されたパラメーターを示す更新確認メッセージが受信された制限されたノードの数又はプロパティとのうち、少なくとも１つの基準に少なくとも部分的に基づく、請求項６又は７に記載の方法。
9. 前記制限されたノードは、エネルギーハーベスティング手段を含む無電池デバイスであり、前記デバイスは、ユーザによる前記エネルギーハーベスティング手段の起動後の所定の時間窓、又は環境からのエネルギーの獲得後の所定の時間窓内にのみデータメッセージを受信可能である、請求項１乃至８のいずれか一項に記載の方法。
10. 前記更新されたネットワーク構成パラメーター値は、チャンネルＩＤ、セキュリティキー、及びネットワークＩＤのうちの少なくとも１つを含む、請求項１乃至９のいずれか一項に記載の方法。
11. 前記保守エンティティは２つの部分に分割され、第１部分は第１調整エンティティ内に配置され、少なくとも前記ステップ（ａ）、（ｂ）、（ｃ）、及び（ｅ）を実行し、第２部分は制限されたノードのための第２調整エンティティ内に配置され、少なくともステップ（ｄ）を実行する、請求項１に記載の方法。
12. 複数のノードを含むネットワークを構成する保守エンティティであって、
    （ａ）所定の期間内においてのみデータを受信することが可能な少なくとも１つの制限されたノードの前記ネットワーク内の存在を検出する手段と、
    （ｂ）前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに共通する更新されたネットワーク構成パラメーター値が必要か否かを判定する手段と、
    （ｃ）前記ネットワークにおける前記少なくとも１つの制限されたノードの存在の前記検出に基づき、前記複数のノードにおいてネットワーク構成パラメーター値を更新する信号の送信を延期する手段と、
    （ｄ）前記送信を延期する一方で、プロキシノードが前記少なくとも１つの制限されたノードに結合され、前記少なくとも１つの前記制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信をトリガするためのトリガ信号を、各前記少なくとも１つの制限されたノードのちょうど１つのプロキシノードに送信する手段と、
    （ｅ）前記複数のノードにおいて、前記ネットワーク構成パラメーター値を更新する前記信号を送信する手段と
    を含むことを特徴とする、前記保守エンティティ。
13. 複数のノードを含むネットワークを構成する保守エンティティであって、
    （ａ）所定の期間内においてのみデータを受信することが可能な少なくとも１つの制限されたノードの前記ネットワーク内の存在を検出する手段と、
    （ｂ）前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに共通する更新されたネットワーク構成パラメーター値が必要か否かを判定する手段と、
    （ｃ）前記ネットワークにおける前記少なくとも１つの制限されたノードの存在の前記検出に基づき、前記複数のノードにおいてネットワーク構成パラメーター値を更新する信号の送信を延期する手段と、
    （ｄ）前記送信を延期する一方で、第１ノードのセットに、前記制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信をトリガするトリガ信号を送信する手段であって、前記第１ノードのセット内の各ノードは、制限されたノードと通信し、前記トリガ信号は、前記第１ノードのセットに、制限されたノードのセットの各制限されたノードのためのプロキシノードを指名させ、前記プロキシノードは、該当する制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信の責任を負う、当該手段と、
    （ｅ）前記複数のノードにおいて、前記ネットワーク構成パラメーター値を更新する前記信号を送信する手段と
    を含むことを特徴とする、前記保守エンティティ。
14. 複数のノードを含むネットワークを構成する保守エンティティであって、
    （ａ）所定の期間内においてのみデータを受信することが可能な少なくとも１つの制限されたノードの前記ネットワーク内の存在を検出する手段と、
    （ｂ）前記ネットワークの前記少なくとも１つの制限されたノード及び前記複数のノードに共通する更新されたネットワーク構成パラメーター値が必要か否かを判定する手段と、
    （ｃ）前記ネットワークにおける前記少なくとも１つの制限されたノードの存在の前記検出に基づき、前記複数のノードにおいてネットワーク構成パラメーター値を更新する信号の送信を延期する手段と、
    （ｄ）前記送信を延期する一方で、前記制限されたノードへの前記更新されたネットワーク構成パラメーター値の送信をトリガするトリガ信号を、プロキシ選択ノードに送信する手段であって、前記更新されたネットワーク構成パラメーター値を前記プロキシ選択ノードに送信することによって、前記プロキシ選択ノードに、前記制限されたノードのためのプロキシノード選択を開始させ、前記プロキシ選択ノードによって選択されたプロキシノードのセットに、前記更新されたネットワーク構成パラメーター値を送信させ、前記送信は、前記選択されたプロキシノードに、当該プロキシノードが関連する前記制限されたノードに前記更新されたネットワーク構成パラメーター値を送信する責任を負わせる、当該手段と、
    を含むことを特徴とする、前記保守エンティティ。
15. 請求項１２乃至１４のいずれか一項に記載の保守エンティティと、複数のノードとを含む、通信ネットワーク。