JP6045580B2 - ノードを構成する方法 - Google Patents

Description

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

本発明は、例えば構成される必要のあるノードのうちの幾つかが、制限され、且つ予測不可能な受信時間窓しかないといった幾つかの強い動作上の制限を有するワイヤレスネットワークに適している。これは、特に、ＺｉｇＢｅｅネットワーク内のＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅについて言えることである。

ネットワーク、特にワイヤレスネットワークでは、ネットワークの各ノードの正しい動作を維持するために、すべてのノードに、ネットワーク構成パラメータの現在使用されている値を常に与えることが必要である。実際に、干渉スペクトル又は場所の変化といった予定されていない事象、又は、暗号化キーの周期的変更といった予定されている事象によって、保守エンティティが、チャンネル識別子、ネットワーク識別子、ノード識別子又はロール、ネットワーク内の新規のコーディネータ／保守エンティティの識別子、暗号化キー、キー記述子、又はキーシードといったネットワーク構成パラメータの新しい値を連絡する必要が生じることがある。

しかし、幾つかのネットワークでは、受信機会に関し制限されている幾つかのノードがあることがある。例示として、ＺｉｇＢｅｅネットワークでは、ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ（ＺＧＰＤ）があり、これらのデバイスは、それらの環境からエネルギーを収穫する、又は、非常に限られたバッテリを有し、したがって、予測不可能な受信挙動を有する。例えばＺＧＰＤは、ユーザによって作動され、且つ信号を送信した後、短い時間の間しか受信できない電気機械エネルギーハーベスタを有する、バッテリのないスイッチである。ＺＧＰＤのもう１つの例としては、例えば光電池によってその環境からエネルギーを収穫する定期報告センサが挙げられる。しかし、当該エネルギーが環境に存在することは予測可能ではなく、センサは、ある期間について報告ができなくなる場合もある。これらのデバイスは、エネルギーバジェット制限があるため、アクティブサーチを介して新しいパラメータを見つけることもできない。

これらのデバイスは、いつでも構成信号を受信できるわけではないことを考えれば、制限のあるデバイスの２つの受信機会の間にネットワークの再構成が生じると、当該制限のあるデバイスは、パラメータ値の変化に気が付かない。当該制限のあるデバイスは、ネットワークパラメータの前のバージョンを使用し続け、したがって当該制限のあるデバイスの周りの更新された通信ピアによって当該制限のあるデバイスのメッセージは受信されない、又は、受信されたとしてもドロップされる可能性があるため、当該制限のあるデバイスは、ネットワークから締め出される可能性がある。当該制限のあるデバイスが、ネットワークに再統合されるためには、ユーザから手動介入を必要とする可能性が非常に高い特別なプロセスを必要とし、時間がかかり、したがって、大きい保守負荷がかかる。

更に、動作時の受信機会の継続時間は、特に、データパケットの送信後は、非常に短い。例えばＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅは、ＲｘＡｆｔｅｒＴｘフラグを設定することによって、（ユーザ／センサ／アプリケーションのトリガ後）、当該デバイスが送信する標準フレームにおいて、受信能力を示す。この送信後、５ｍｓが経過すると、ＺＧＰＤは、最短Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ Ｆｒａｍｅに対応する少なくとも０．５７６ｍｓの間、受信のための無線通信を開く。この継続時間は、例えば新しいキーを含むパケットを受信するためには十分ではない。

本発明は、上記に示したような問題を軽減する方法を提案することを目的とする。

本発明は、制限のあるノードの保守管理状態を最新にすることを可能にする当該制限のあるノードと通信する方法を提案することをもう１つの目的とする。

本発明は、制限のあるノードを含み、幾つかのパラメータが動的に設定される必要のあるネットワークの動作を容易にする方法を提案することをもう１つの目的とする。

「制限のあるノード」とは、送信及び／又は受信に関して能力が制限されているノードを意味する。例示的な一例としては、スイッチ又はセンサといったエネルギーハーベスティングデバイスがあり、エネルギーが付与された後、短時間しか、時には予測不可能な時間の間にしか通信できない。別の例としては、アプリケーショントリガによって、例えば特定値が感知された場合にのみ、送信及び／又は受信するデバイスがある。更なる例は、発明の詳細な説明において説明される。

上記目的を達成するために、本発明の第１の態様によれば、ネットワークにおける制限のあるノードを構成する方法が提案される。当該制限のあるノードは、制限のある受信機会内でしかデータを受信できない。当該方法は、
第１のノードにおいて、
（ａ）制限のあるノードについて、ネットワーク構成パラメータ値の更新が必要であることを検出するステップと、
（ｂ）制限のあるノードの通信特性に少なくとも部分的に基づいて、制限のあるノードの挙動を、第１の挙動から変更するかどうかを決定するステップであって、挙動の変更は、制限のあるノードにおける受信機会を増加させることを含む、ステップと、
（ｃ）ステップ（ｂ）における決定に依存して、制限のあるノードの第１の受信機会の間に、制限のあるノードへの挙動変更のリクエストの配信をトリガするステップと、
（ｄ）制限のあるノードの第２の受信機会の間に、制限のあるノードへの更新されたネットワーク構成パラメータ値の配信をトリガするステップと、を含む。結果として、動作時の制限のあるノードの構成が、当該方法を介して可能となる。本発明は、当該制限のあるノードの通常動作が制限のあるノードの構成を危険にさらす又は低速化するという認識に基づいている。制限のあるノードが時間内に更新されないことによる幾つかの影響には、当該制限のあるノードがその近隣ノードによって理解されなくなるということが含まれる。これには、オペレータが当該ノードを検出し再構成するための介入が必要となる。上記自動再構成は、このような介入を回避する。

本発明の第２の態様によれば、本発明は更に、保守エンティティと複数のノードとを含むネットワークを構成する方法に関する。当該方法は、
（１ａ）保守エンティティにおいて、制限のある期間にしかデータを受信できない、少なくとも１つの制限のあるノードの、ネットワークにおける潜在的な存在を検出するステップと、
（１ｂ）保守エンティティにおいて、少なくとも１つの制限のあるノードとネットワークの複数のノードとに共通するネットワーク構成パラメータ値の更新が必要であることを決定するステップと、
（１ｄ）保守エンティティにおいて、制限のあるデバイスへの更新されたネットワーク構成パラメータ値の配信をトリガするステップと、
（１ｅ）本発明の第１の態様の方法を実行するステップと、を含む。

本発明の第３の態様によれば、ネットワークにおける制限のあるノードを構成する構成手段を含む無線ノードが提案される。当該制限のあるノードは、制限のある受信機会内でしかデータを受信できない。当該無線ノードは、
制限のあるノードについて、ネットワーク構成パラメータ値の更新が必要であることを検出する検出手段と、
制限のあるノードの通信特性に少なくとも部分的に基づいて、制限のあるノードの挙動を変更するかどうかを決定するコントローラと、
を含み、
挙動の変更は、制限のあるノードにおける受信機会を増加させることを含み、
コントローラは、制限のあるノードの挙動を変更すると決定した場合の第１の受信機会の間における制限のあるノードへの挙動変更のリクエストの配信と、制限のあるノードの後続の受信機会の間における更新されたネットワーク構成パラメータ値の配信とをトリガする。

本発明のこれらの及び他の態様は、以下に説明される実施形態を参照して明らかとなろう。

本発明は、添付図面を参照して、例として以下により詳細に説明される。

図１は、本発明の第１の実施形態が実施されるネットワークのブロック図である。 図２は、本発明の第１の実施形態に従う方法を説明するフローチャートである。 図３Ａは、本発明の一実施形態に使用される新しいコマンドフレームの提案形式を示すブロック図である。 図３Ｂは、本発明の一実施形態に使用される新しいコマンドフレームの提案形式を示すブロック図である。

本発明は、互いに通信する複数のノードを含むネットワークと、ネットワークにおいて制限のあるデバイスを構成する方法とに関する。当該制限のあるデバイスは、例えば制限のあるエネルギー供給手段を有する。当該デバイスは、他のデバイスが同様の制限を有さないネットワークにおいて使用される。本発明の例示的な実施形態では、ネットワークは、ワイヤレスメッシュネットワークである。本発明は、ＺｉｇＢｅｅ規格、より具体的にはＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ（ＺＧＰ）規格のコンテキストで説明され、当該制限のあるデバイスが、ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ（ＺＧＰＤ）である。

このようなＺＧＰＤは、例えばエネルギーハーベスティングデバイス、例えばユーザによるスイッチの作動の力学的エネルギーを電気的エネルギーに変換するスイッチである。作動後、スイッチは、限られた数のパケットを送信可能であり、残りのエネルギーを、ネットワークにおける他のノードからのデータパケットを受信するために使用する。このようなＺＧＰＤの受信機会は、ユーザによる作動とその時に収穫されたエネルギー量の直接的な結果であるため、非常に短く、動作において予測不可能である。

ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅのもう１つの種類としては、環境エネルギーを、動作のための電気的エネルギーに変換するセンサノードがある。例えば当該センサノードは、十分な光を受けた場合にのみ動作する光センサである。同様に、熱電素子によって給電される温度又は熱センサ、流れによって給電される流量センサ、電磁放射線によって給電される電力センサ、又はユーザの存在を決定する音響センサといった他のセンサも使用してよい。

ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ仕様によれば、ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅは、十分なエネルギーバジェットを有する場合、当該デバイスがメッセージを送信した直後の限られた時間の間、（選択された時間において）、メッセージを受信できる（スイッチの場合、受信及び送信の両方のためのエネルギーは、同じボタンの押下からもたらされる）。ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅは、ＲｘＡｆｔｅｒＴｘフラグを設定することによって、（ユーザ／センサ／アプリケーションのトリガ後）、当該デバイスが送信する標準フレームにおいて、受信能力を示す。この送信後、５ｍｓが経過すると、ＺＧＰＤは、少なくとも０．５７６ｍｓの間、受信のための無線通信を開く。この受信機会は、通常、あまり長く持続しない。

動作モードにあるＺＧＰＤは、パラメータ更新がいつあるかを知らないため、受信のために最低限のエネルギー量しかとっておかない。結果として、例えば（１６バイトの）セキュリティキーを担持するＺＧＰＤ Ｃｏｍｍｉｓｓｉｏｎｉｎｇ Ｒｅｐｌｙフレームである長い更新フレームを必要とする構成コマンドの場合、当該長いフレームは適宜に処理されず、例えばその全長を受信することができない、又は、不揮発性メモリに記憶されたコンテンツが提供されない。

したがって、本発明の現在の定義に従って、これらの特別な制限のあるノードを構成する方法が提案される。具体的には、このような方法は、制限のあるノードの通常動作モードを「パラメータ受信モード」に変更するために、特定のＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅコマンドが必要となる。当該パラメータ受信モードは、ＺＧＰＤが更新を受信するチャンスを向上させるために、送信及び／又は受信のために、ＺＧＰＤの特別な挙動を含む。

ＺＧＰＤのパラメータ更新が保留中である場合、更新されたネットワーク構成パラメータの優先順位、更新されたネットワーク構成パラメータフレームの長さ、制限のあるノードの受信機会の継続時間、制限のあるノードの受信機会の頻度、制限のあるノードの能力、制限のあるノードのアプリケーション機能、制限のあるノードの場所、制限のあるノードの優先順位といった基準に既存して、まず、ＺＧＰＤの「Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇ」コマンドが、送信される。当該コマンドは、非常に短く、また、受信の確率を上げるために繰り返し送信される。当該コマンドは、ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒインフラストラクチャデバイス（ＺＧＰＤと対にされた１つ／任意のＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｓｉｎｋ（ＺＧＰＳ）、又は、ＴｅｍｐＭａｓｔｅｒとして任命される任意のＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｐｒｏｘｙ（ＺＧＰＰ）、即ち、ＺＧＰＤコマンドを、標準ＺｉｇＢｅｅノードに転送するための標準ＺｉｇＢｅｅコマンドに変換するＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ対応デバイス）によって、ＺＧＰＤに保留中の更新を知らせるために、送信される。しかし、以下に詳述するように、メッセージの送信と更新進捗の追跡とは、次のデバイス／ロール：ＺｉｇＢｅｅ保守デバイス（ＺｉｇＢｅｅ Ｔｒｕｓｔ Ｃｅｎｔｅｒ、ＺｉｇＢｅｅ Ｃｏｏｒｄｉｎａｔｏｒ、Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｒ）、ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ保守デバイス、Ｃｏｍｍｉｓｓｉｏｎｉｎｇ Ｔｏｏｌ、コンセントレータ、ゲートウェイのいずれによって行われてもよい。ＺＧＰＤは、コマンドに応えて、その挙動を変更する。更に、コマンドは、挙動変更に所望の方法で影響を与えるように仕上げられている。パラメータ受信モードでは、ＺＧＰＤは、受信時にシステムにおける不必要な混乱を回避し、更に受信のためのエネルギーを節約するために、通常の「データ」フレーム以外のコマンドを送信する。よい候補は、両方のチャンネルサブフィールドがＺＧＰＤに知られている現在の動作チャンネルに設定されるＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔコマンド、又は、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンドである。

図１に示されるように、本発明の第１の実施形態は、Ｃｏｏｒｄｉｎａｔｏｒ１０１と、複数の無線ノード１１０とを含むＺｉｇＢｅｅメッシュネットワーク１００において実行される。本実施例では、ネットワーク１００は更に、ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｓｉｎｋ（ＺＧＰＳ）１０２０又はＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｐｒｏｘｙ（図示せず）と対にされたＺＧＰＤスイッチ１０００又はＺＧＰＤセンサ１００１といったＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ仕様に適合するデバイスを含む。ＺＧＰＳは、１つ以上のＺＧＰＤスイッチ１０００又はセンサ１００１によって制御されるアクチュエータデバイスであってよい。例えばＺＧＰＳはランプである。特に照明の場合、複数のＺＧＰＳが、単一のＺＧＰＤによって制御されることは一般的である。ＺＧＰＳは、通常、主電源に接続され、また、通常、予測不可能な受信機会においてしか受信できないＺＧＰＤとは対照的に、受信又は送信機会において制限がない。ＺＧＰＤ１０００又は１００１と、ＺＧＰＳ１０２０、即ち、プロキシ又はシンクとの間の通信における衝突を回避するために、ＴｅｍｐＭａｓｔｅｒ１０２１が、ＺＧＰＤと通信するように任命される。

本発明の第１の実施形態によれば、更新要件を承知しているＺＧＰＳ１０２０が、遠隔のＴｅｍｐＭａｓｔｅｒ１０２１と通信する。当該プロセスは、選択されたＴｅｍｐＭａｓｔｅｒに完全にトランスペアレントであり、当該プロセスは、単に、（ｉ）ＧＰＤＦ（Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ Ｆｒａｍｅ）を、ＺＧＰＳによって命令されるように、ＺＧＰＤに送信されるべきＴｅｍｐＭａｓｔｅｒのｚｇｐＴｘＱｕｅｕｅに記憶し、（ｉｉ）ＺＧＰＤからＧＰＤＦを受信後、ＴｅｍｐＭａｓｔｅｒのｚｇｐＴｘＱｕｅｕｅにある場合に、ＧＰＤＦを送信する。

当該方法は、図２のフローチャートを参照して説明される。

ステップＳ２０１において、ＺＧＰＤ１０００と対にされたＺＧＰＳ１０２０は、例えばＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇを受信することによって、保留中のパラメータ更新について知る。

ステップＳ２０２において、ＺＧＰＳ１０２０は、ＴｅｍｐＭａｓｔｅｒを任命するか、又は、ＴｅｍｐＭａｓｔｅｒ選出を開始する。ＴｅｍｐＭａｓｔｅｒは、それ自身と、ＺＧＰＤの無線範囲内でＺＧＰＤと通信可能である、利用可能な転送プロキシとを含む複数のＺＧＰＳから選択される。選択されたＺＧＰＳは、ＺＧＰＤ１０００のＴｅｍｐＭａｓｔｅｒの機能を果たす。

ステップＳ２０３において、ＺＧＰＳ１０２０は、構成パラメータの更新を実行するためにＺＧＰＤの動作モードを変更する必要があるか又は変更することが好ましいかを決定する。この決定は、ＺＧＰＤの現在の能力、及び、更新コマンドフレームの長さ、その優先順位といった更新コマンドに関連付けられた幾つかのパラメータに依存して行われる。ＺＧＰＤの動作モードを変更するトリガは、外部であってもよい（例えば補完的な解決策において後述されるように受信されたＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇに含まれる）。

ステップＳ２０４において、ＺＧＰＳ１０２０は、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドフレームと共に、ＴｅｍｐＭａｓｔｅｒにＺＧＰ Ｒｅｓｐｏｎｓｅを送信する。幾つかのサブオプションが適宜設定される。

例えば以下のサブオプションが示される。
・Ｅｘｔｅｎｄ Ｒｘ Ｗｉｎｄｏｗ−受信機会継続時間を増加させる。当該サブオプションは、更新フレームが、ＺＧＰ仕様によって定義される最小Ｒｘフレームよりも長い場合に設定される。一例では、このサブオプションが選択される場合、ＺＧＰＤは、通常のデータパケットを送信することを止め、所定時間後に来る受信機会を示すために短い専用メッセージ（例えば両方のチャンネルサブフィールドがＺＧＰＤに知られている現在の動作チャンネルに設定されるＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔコマンドか、又は、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンド）のみを送信する。更に、外延的に、保留更新フレームの正確な長さをバイト又は時間分で担持するフィールドは、ＺＧＰＤにより正確にどのように挙動すべきかを命令するために、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドに含まれる。したがって、ＺＧＰＤは、適宜に反応し、その受信窓を拡大する。
・Ｉｎｃｒｅａｓｅ Ｒｅｐｏｒｔｉｎｇ Ｆｒｅｑｕｅｎｃｙ−受信機会を作るためにより頻繁にされる。当該サブオプションは、（例えばＺｉｇＢｅｅ保守エンティティによって示される）更新時間が短い場合に設定される。又は、ネットワークにおける他の処理等と同時に更新されるＺＧＰＤの数／報告頻度に依存して設定される。報告頻度の増加は、例えば温度センサ又は光センサといった、より定期的にエネルギーを収穫するＺＧＰＤセンサにより適している。上述したように、ＺＧＰＤは更に、受信機会のためにエネルギーを節約するために、当該動作モードでは、完全なデータパケットを送信することを阻止し、また、来る受信機会を示すために短い専用メッセージを送信する。

外延的に、リクエストされた報告頻度を担持するフィールドが、ＺＧＰＤにより正確にどのように挙動すべきかを命令するために、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドに含まれる。これは、受信ＺＧＰＤにおいて、更に多くのインテリジェンスが必要となる。
・ＡＣＫ Ｒｅｑｕｅｓｔ−ＺＧＰＤに、受信メッセージに対し肯定応答するようにリクエストする。当該サブオプションは、更新の優先順位と、ＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇに表現される保守エンティティのリクエストとに応じて設定される。なお、幾つかの構成モードしかＺＧＰＤに伝播されなくてよいことに留意されたい。更に、受信機会のためのエネルギーを節約するために、ＺＧＰＤにおいて受信されたパケットの異常復号化の場合に、ＮＡＣＫを送信する必要がない。
・Ｅｎａｂｌｅ Ｃｈａｎｎｅｌ Ｔｏｇｇｌｉｎｇ Ｂｅｈａｖｉｏｒ−ＺＧＰＤに、後続の各送信について、サポートされるチャンネルセットからチャンネルを選択するように要求する。
・Ｅｎｔｅｒ ｃｏｍｍｉｓｓｉｏｎｉｎｇ ｍｏｄｅ−通常、初期の構成又は保守に確保されている動作モードである。
・Ｕｓｅ ｓｐｅｃｉａｌ ｃｏｍｍａｎｄ ｆｏｒ Ｔｘ−受信機会をアナウンスするために、ＺＧＰＤに、専用コマンド（例えば両方のチャンネルサブフィールドがＺＧＰＤに知られている現在の動作チャンネルに設定されるＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔコマンドか、又は、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンド）を使用することをリクエストする。
・Ｅｎｔｅｒ／Ｅｘｉｔ ｔｈｅ ｍｏｄｅ−ＺＧＰＤに、特別な挙動に切り替わるか、又は、動作モードに再び切り替わることをリクエストする。

ステップＳ２０５において、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤ Ｕｐｄａｔｅ ＰｅｎｄｉｎｇコマンドをそのｚｇｐＴｘＱｕｅｕｅに入れ、当該コマンドを、ＺＧＰＤの次の受信機会において配信することを試みる。この受信機会は、通常、このＺＧＰＤから設定されたＲｘＡｆｔｅｒＴｘを有する第１のＧＰＤＦの受信によって示される。

ステップＳ２０６において、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドを受信すると、ＺＧＰＤは、対応する場合、且つ、受信時のチェックが成功した場合、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドによってリクエストされるように、且つ、その能力に従って、更新関連の挙動を変更する。例えばＺＧＰＤは、「パラメータ受信モード」（内部変数を「パラメータ受信モード」に設定することが必要）又は「コミッショニングモード」に入り、ＡＣＫリクエストに対し、ＺＧＰＤは、新しいパラメータの受信後、古い／新しいパラメータを使用してＺＧＰＤ Ｓｕｃｃｅｓｓを送信するために、内部変数を設定する。更に、ＺＧＰＤは、ＧＰＤＦにおける再送信の回数若しくはそれ自身のデータパケット（ＧＰＤＦ）の送信間の時間を制限するか、又は、新しいパラメータの受信／分類のためにより多くのエネルギーを節約するために専用の短いＧＰＤＦを使用する。ＺＧＰＤは、報告間隔を変更してもよい。

ステップＳ２０７において、ＧＰＤＦを配信後、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤが現在更新されていることを示すために、ＺＧＰＳに確認を送信する。ＯｐｔｉｏｎｓフィールドのＧＰＤＦ Ｄｅｌｉｖｅｒｅｄサブフィールドが０ｂ１に設定されたＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎが使用される。

ステップＳ２０８において、ＴｅｍｐＭａｓｔｅｒからの確認を受信すると、ＺＧＰＳは、ＺＧＰＤ更新フレーム（ＺＧＰＤ Ｃｈａｎｎｅｌ構成／Ｃｏｍｍｉｓｓｉｏｎｉｎｇ Ｒｅｐｌｙ）を作り、それを、ＺＧＰ Ｒｅｓｐｏｎｓｅに入れてＴｅｍｐＭａｓｔｅｒに送信する。ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤコマンドを、そのｚｇｐＴｘＱｕｅｕｅに入れる。本実施形態の変形として、Ｕｐｄａｔｅ Ｆｒａｍｅは、Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドフレームと共に送信される。

ステップＳ２０９において、ＺＧＰＤの次の送信時、「パラメータ受信モード」において、ＺＧＰＤは、好適には、将来の送信のためのチャンネル番号がＣｈａｎｎｅｌトグリング挙動フィールドのサブフィールドに含まれるＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔを送信する。なお、ＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔは、ここでは、（Ｄａｔａ ＧＰＤＦでシステムを混乱させることなく）ＴｅｍｐＭａｓｔｅｒからの通信をトリガする一種の「ダミー」パケットとして使用される。更に、特に、チャンネルトグリングがリクエストされた場合、ＺＧＰＤは、ＺＧＰＤが受信する次のチャンネルを、ダミーパケットに対する応答において示すことができ、したがって、プロキシが、そのＴｘチャンネルと配信されるべきパケットとを調節することを可能にする。「ダミー」パケットに別の形式を使用してもよい。

ステップＳ２１０において、ＺＧＰＤからＧＰＤＦを受信すると、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤ更新コマンドを送信する。次に、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＳに確認（例えばＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎ）を送信する。

ステップＳ２１１において、ＡＣＫパラメータ値に依存して、ＺＧＰＳは、更新が成功裏に行われたと見なす。
ａ．ＮＯ ＡＣＫの場合：ＺＧＰＤ更新コマンドを有するＺＧＰ Ｒｅｓｐｏｎｓｅを送信時
ｂ．ＳＥＮＴの場合：ＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔを有するＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎの受信時
ｃ．ＡＣＫの場合：ＺＧＰＤがＺＧＰＤ Ｓｕｃｃｅｓｓコマンドを送信したとき
ｄ．「ＺＧＰＤ ｕｓｉｎｇ ｔｈｅ ｐａｒａｍ」ＡＣＫ（また、チャンネルが更新された）の場合、以下（Ｓ２１２〜Ｓ２１４）のとおりに続ける。
ｅ．「ＺＧＰＤ ｕｓｉｎｇ ｔｈｅ ｐａｒａｍ」ＡＣＫ（また、ＰＡＮＩｄ／キーが更新された）の場合、Ｓ２１５〜Ｓ２１８のとおりに続ける。

ステップＳ２１２において、ＺＧＰＳは、好適にはＺＧＰＤコマンドなしで、又は、専用の「ダミー」ＺＧＰＤコマンド（例えばＥｎｔｅｒ／Ｅｘｉｔサブフィールドが「Ｅｘｉｔ」に設定されたＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンド）と共に、ＺＧＰ Ｒｅｓｐｏｎｓｅを送信し、ＴｅｍｐＭａｓｔｅｒに、ＺＧＰＤからの幾つかの通信について（ＺＧＰ ＲｅｓｐｏｎｓｅコマンドのＴｅｍｐＭａｓｔｅｒＴｘチャンネルフィールド／ＺＧＰＰＴｘチャンネルフィールドに示される）ＮＥＷ動作チャンネルを聞くように命令する。

ステップＳ２１３において、このＺＧＰ Ｒｅｓｐｏｎｓｅを受信すると、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＳによって示されるチャンネルに切替え、タイマーを開始する。ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤからＧＰＤＦを受信する（また、受信時のチェックが成功する）と、古い動作チャンネルに再びすぐに切り替わり、そこでＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎを送信する。

ステップ２１４において、ＺＧＰＳは、ＺＧＰＤ Ｓｕｃｃｅｓｓを担持するＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎを受信すると、更新が成功したと見なす。

ステップ２１５において、更新されるパラメータは、ＴｅｍｐＭａｓｔｅｒ Ｐｒｏｘｙにおいて一時的に変更される必要がある。
ａ．更新されるパラメータがＰＡＮＩｄである場合、当該パラメータは、新しい値で一時的に上書きされる。又は、好適には、ＴｅｍｐＭａｓｔｅｒは、無差別モードに一時的に置かれる。
ｂ．更新されるパラメータがキーである場合、ＺＧＰＤキー属性が一時的に上書きされる。又は、好適には、新しいキーが、Ａｌｔｅｒｎａｔｅ ＺＧＰＤ Ｋｅｙ属性に記憶される。
ｃ．ＺＧＰＰに更新を行うために特別な認証情報（キー、アドレス）が必要とされる場合、ＺＧＰＳは、正しい保守エンティティに、ステップＳ２１６〜２１８が行われる前に、当該保守エンティティに更新をまず行わせることを通知する。更新は、ステップＳ２０２においてすぐに行われ、また、遅くともステップＳ２１６において行われる。

ステップＳ２１６において、ＺＧＰＳは、好適にはＺＧＰＤコマンドなしで、又は、専用の「ダミー」ＺＧＰＤコマンド（例えばＥｎｔｅｒ／Ｅｘｉｔサブフィールドが「Ｅｘｉｔ」に設定されたＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンド）と共に、ＺＧＰ Ｒｅｓｐｏｎｓｅを送信し、ＴｅｍｐＭａｓｔｅｒに、当該ＺＧＰ Ｒｅｓｐｏｎｓｅを動作チャンネルで配信するように命令する。

ステップＳ２１７において、このＺＧＰ Ｒｅｓｐｏｎｓｅを受信すると、ＴｅｍｐＭａｓｔｅｒはタイマーを開始する。ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤからＧＰＤＦを受信する（また、受信時のチェックが成功する）と、受信ＧＰＤＦと共にＺＧＰ ＮｏｔｉｆｉｃａｔｉｏｎをＺＧＰＳに送信する。

ステップＳ２１８において、ＺＧＰＳは、ＺＧＰＤ Ｓｕｃｃｅｓｓを有するＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎを受信すると、更新が成功したと見なす。

ステップＳ２１９において、更新が（必要な基準に従って）成功裏に行われると、一実施例では、ＺＧＰＳは、リクエストされた場合、且つ、リクエストされたモードにおいて、保守エンティティに確認を送信する。

本実施形態の変形では、この方法が、（ＺｉｇＢｅｅ／ＺＧＰＤ保守エンティティがプロセスをトリガする）集中型の設定においても確実に正しく機能するように、保守エンティティは、ＴｅｍｐＭａｓｔｅｒにおける次のＧＰＤＦを計画できるように、確実に確認が自身に配信されるようにする必要がある。

これは、保守エンティティが、もしあれば、ＺＧＰＤが管理するグループのメンバーに（一時的に）なる［即ち、適切なエンドポイントについて、グループをそのＡＰＳリストに追加する］ことによって、又は、ＴｅｍｐＭａｓｔｅｒにおいて、ＴｅｍｐＭａｓｔｅｒがＺＧＰ Ｎｏｔｉｆｉｃａｔｉｏｎを受信するように、その独自のアドレスにユニキャストペアリングを一時的に追加することによって行われる。更に、ＺＧＰ Ｐａｒａｍｅｔｅｒ Ｕｐｄａｔｅ Ｓｔａｔｕｓコマンドが設定される。

このようなセットアップでは、パラメータ更新をトリガするデバイス（ＺｉｇＢｅｅ／ＺＧＰＤ保守エンティティ）は更に、ＴｅｍｐＭａｓｔｅｒ／シンクにコマンドを送信することによって、又は、設定をトリガコマンド（ＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇ）に含めることによって、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドの設定を提供する。

第２の実施形態では、「スマート」ＺＧＰＰ／ＺＧＰＳ／ＺＧＰＣであるＴｅｍｐＭａｓｔｅｒにおいて、より多くの決定が行われる。

ステップ１において、ＺＧＰＤと対にされたＺＧＰＳは、（例えば補完的な解決策において後述する方法によって、即ち、ＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇを受信することによって）保留中のパラメータ更新について知る。

ステップ２において、ＺＧＰＳは、ＴｅｍｐＭａｓｔｅｒを（自身、他のシンク、及びＺＧＰＤの無線範囲内でＺＧＰＤと通信可能である、利用可能な転送プロキシから）任命する。本実施例では、ＺＧＰＳは、自分自身をＴｅｍｐＭａｓｔｅｒとして選択したと想定する。

ステップ３において、ＺＧＰＳは、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドとそのサブプオプションセットとを適宜に生成する。

例えば、
・Ｅｘｔｅｎｄ Ｒｘ Ｗｉｎｄｏｗ−更新フレームが、規格によって定義される最小Ｒｘフレームより長い場合に設定される。
・Ｉｎｃｒｅａｓｅ ｒｅｐｏｒｔｉｎｇ ｆｒｅｑｕｅｎｃｙ−（例えばＺｉｇＢｅｅ保守エンティティによって示される）更新時間が短い場合に設定される。
・ＡＣＫ−更新の優先順位と、保守エンティティのリクエストとに応じて設定される。
・Ｅｎａｂｌｅ Ｃｈａｎｎｅｌ Ｔｏｇｇｌｉｎｇ Ｂｅｈａｖｉｏｒ−ＺＧＰＤに、後続の各送信について、サポートされるチャンネルセットからチャンネルを選択するように要求する。
・Ｅｎｔｅｒ ｃｏｍｍｉｓｓｉｏｎｉｎｇ ｍｏｄｅ−通常、初期の構成又は保守用に確保されている動作モードである。
・Ｕｓｅ ｓｐｅｃｉａｌ ｃｏｍｍａｎｄ ｆｏｒ Ｔｘ−受信機会をアナウンスするために、ＺＧＰＤに、専用コマンド（例えば両方のチャンネルサブフィールドがＺＧＰＤに知られている現在の動作チャンネルに設定されるＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔコマンドか、又は、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンド）を使用することをリクエストする。
・Ｅｎｔｅｒ／Ｅｘｉｔ ｔｈｅ ｍｏｄｅ−ＺＧＰＤに、特別な挙動に切り替わるか、又は、動作モードに再び切り替わることをリクエストするする。

ステップ４において、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤ Ｕｐｄａｔｅ ＰｅｎｄｉｎｇコマンドをそのｚｇｐＴｘＱｕｅｕｅに入れ、当該コマンドを、ＺＧＰＤから設定されたＲｘＡｆｔｅｒＴｘを有する第１のＧＰＤＦの受信後、当該ＺＧＰＤに配信する。

ステップ５において、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドを受信すると、ＺＧＰＤは、対応する場合、且つ、受信時のチェックが成功した場合、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドによってリクエストされるように、且つ、その能力機能に従って、更新関連の挙動を変更する。例えばＺＧＰＤは、「パラメータ受信モード」（内部変数を「パラメータ受信モード」に設定することが必要）又は「コミッショニングモード」に入り、ＡＣＫリクエストに対し、ＺＧＰＤは、新しいパラメータの受信後、古い／新しいパラメータを使用してＺＧＰＤ Ｓｕｃｃｅｓｓを送信するために、内部変数を設定する。更に、ＺＧＰＤは、ＧＰＤＦにおける再送信の回数若しくはそれ自身のデータパケット（ＧＰＤＦ）の送信間の時間を制限するか、又は、新しいパラメータの受信／分類のためにより多くのエネルギーを節約するために専用の短いＧＰＤＦを使用する。ＺＧＰＤは、報告間隔を変更してもよい。

ステップ６において、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドを配信すると、ＴｅｍｐＭａｓｔｅｒは、ＺＧＰＤ更新フレーム（ＺＧＰＤ Ｃｈａｎｎｅｌ構成／Ｃｏｍｉｓｓｉｏｎｉｎｇ Ｒｅｐｌｙ）を作り、それを自身のｚｇｐＴｘＱｕｅｕｅに入れる。

ステップ７において、次の送信時、「パラメータ受信モード」において、ＺＧＰＤは、好適には、将来の送信のためのチャンネル番号がＣｈａｎｎｅｌトグリング挙動フィールドのサブフィールドに含まれるＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔを送信することが好適である。

ステップ８において、ＺＧＰＤからＧＰＤＦを受信すると、ＴｅｍｐＭａｓｔｅｒは、更新コマンドを送信する。

ステップ９において、第１の実施形態にあるように、ＡＣＫパラメータ値に依存する。
ａ．ＮＯ ＡＣＫ／ＳＥＮＴの場合：ＺＧＰＳは、更新が成功裏に行われたと見なす。
ｂ．ＡＣＫ（また、更新されたパラメータがチャンネルであった）の場合、ステップ１０の通りに続ける。
ｃ．ＡＣＫ（また、更新されたパラメータがＰＡＮＩＤ／キーであった）の場合、ステップ１１を続ける。

ステップ１０において、ＴｅｍｐＭａｓｔｅｒは、（ＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドによって示される）新しい動作チャンネルに移動し、タイマーを開始する。タイムアウトまでにＺＧＰＤ Ｓｕｃｃｅｓｓコマンドが受信されなければ、ＴｅｍｐＭａｓｔｅｒは、動作チャンネルに再び切り替わり、ステップ６に戻る。ＺＧＰＳは、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンドを受信すると、更新が成功したと見なす。

ステップ１１において、ＺＧＰＳは、新しいパラメータを使用して、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンドを受信できるように、自身の構成を変更する。
ａ．新しいパラメータがＰＡＮＩｄである場合、ＴｅｍｐＭａｓｔｅｒのＰＡＮＩｄは、新しい値で一時的に上書きされる。又は、好適には、ＴｅｍｐＭａｓｔｅｒは、無差別モードに一時的に置かれる。
ｂ．新しいパラメータがキーである場合、ＺＧＰＤキー属性が一時的に上書きされる。又は、好適には、新しいキーは、Ａｌｔｅｒｎａｔｅ ＺＧＰＤ Ｋｅｙ属性に記憶される。

この変更は、（例えば変更が、上述した好適なオプションのように、古い及び新しいパラメータの両方で受信できるようにする場合）ステップ２においてすぐに行われ、また、遅くともステップ１２において行われる。

ＺＧＰＳは、ＺＧＰＤ Ｓｕｃｃｅｓｓコマンドを受信すると、更新が成功したと見なす。

ステップ１２において、更新が（必要な基準に従って）成功裏に行われると、ＺＧＰＳは、リクエストされた場合、且つ、リクエストされたモードにおいて、保守エンティティに確認を送信する。

当然ながら、ＴｅｍｐＭａｓｔｅｒ ＺＧＰＳについてここで説明した挙動と同じ挙動が、ＴｅｍｐＭａｓｔｅｒ ＺＧＰＰによって行われる。しかし、ＺＧＰＰは、更新プロセスについて理解を有さなければならない（現在のＺＧＰ仕様によれば、ＺＧＰＰは、ＺＧＰＳ又は保守エンティティによって生成されたＺＧＰＤコマンドだけを送信し、ＺＧＰＤから受信されたコマンドはトンネル（tunnel）する）。

これらの実施形態の変形では、上記方法は、特別なエンティティ、即ち、ＺＧＰＤと直接又はプロキシを介して通信するＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ Ｄｅｖｉｃｅ用の保守エンティティ（ＺＧＰＤ−ＭＥ）において実行される。

上記実施形態のすべてにおいて、ＺＧＰＤは、特別モード（ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドによってリクエストされ、ＺＧＰＤによってサポートされるパラメータ受信モード又はコミッショニングモード）から、更新が完了する（新しいパラメータを受信し、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドによってリクエストされ、ＺＧＰＤによってサポートされる場合に、任意選択的に、肯定応答を提供する）と、又は、Ｅｎｔｅｒ／Ｅｘｉｔ ｍｏｄｅサブフィールドが０ｂ０に設定されたＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドを受信すると、自動的に出る。後者の場合、当該コマンドは、更新をトリガ／実行しているデバイス（保守エンティティ、シンク、ＴｅｍｐＭａｓｔｅｒ）によって、ＺＧＰＤに送信される必要がある。Ｅｎｔｅｒ／Ｅｘｉｔ ｍｏｄｅサブフィールドが０ｂ０に設定されたＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドは、ＺＧＰＤに動作モードに戻るように命令するために、他の時間においても送信される。

図３Ａ及び図３Ｂに、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドフレーム形式の一例が示される。

ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドは、その長さを制限するために、ペイロードレスコマンドである。当該コマンドを受信すると、ＺＧＰＤは、変更可能であるため、その挙動を変更する。

外延的に、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドは、ＺＧＰＤの挙動を、上記第１及び第２の実施形態にて説明されたように特定の方法で変更するために、図３Ａに示されるように、幾つかのサブフィールド／フラグを有するフィールドを含む。当該コマンドを受信すると、ＺＧＰＤは、変更可能であるため、その挙動を、コマンド中の値を考慮して変更する。

Ｅｎｔｅｒ／Ｅｘｉｔ ｍｏｄｅは、０ｂ１に設定される場合、ＺＧＰＤは、対応する場合、動作モードを離れ、サポートされている場合にはパラメータ受信モード、又は、サポートされている場合（Ｅｎｔｅｒ Ｃｏｍｍｉｓｓｉｏｎｉｎｇ Ｍｏｄｅサブフィールドが設定されている場合）にはコミッショニングモードである特別更新モードに入ることを示す。０ｂ０に設定される場合、Ｅｎｔｅｒ／Ｅｘｉｔ ｍｏｄｅは、ＺＧＰＤが動作モードに再び切り替わることを示す。

Ｅｘｔｅｎｄ Ｒｘ Ｗｉｎｄｏｗは、０ｂ１に設定される場合、ＺＧＰＤは、対応する場合、次のＺＧＰＤ送信後、規格によって定義されるＺＧＰＤの最小継続時間を超えて受信窓の継続時間を延長すべきであることを示す。このことは、ＺＧＰＤに送信されるより長いフレームに対応でき、及び／又は、ＴｅｍｐＭａｓｔｅｒが（最初の送信が部分的に破損している場合でも信頼性の高い受信を可能にするように）２回以上、ＺＧＰＤにフレームを送信できるようにする。これに対応するために、ＺＧＰＤは、そのエネルギーバジェット及び能力に依存して、送信を短くする／リトライの回数を制限する、又は、短いフレームを送信する必要がある。

Ｉｎｃｒｅａｓｅ Ｒｅｐｏｒｔｉｎｇ Ｆｒｅｑｕｅｎｃｙは、０ｂ１に設定される場合、ＺＧＰＤは、対応する場合、その報告頻度を一時的に増加させるべきであることを示す。これに対応するために、ＺＧＰＤは、そのエネルギーバジェット及び能力に依存して、送信を短くする／リトライの回数を制限する必要がある。

ＡＣＫ Ｒｅｑｕｅｓｔは、ＴｅｍｐＭａｓｔｅｒが、ＺＧＰＤに、新しいパラメータの受信の確認をリクエストするかどうかを示す。ＡＣＫ Ｒｅｑｕｅｓｔは、次の値を取ることができる。
００−ＡＣＫ不要
０１−ＡＣＫは、古いパラメータを使用してＺＧＰＤ Ｓｕｃｃｅｓｓコマンドを送信する（パラメータスイッチングは延期されている）
１０‐ＡＣＫは、新しいパラメータを使用してＺＧＰＤ Ｓｕｃｃｅｓｓコマンドを送信する（パラメータスイッチングは即時に行われる）
１１‐保留。

これらの値は、ＺＧＰＤの更新プロセスを制御するデバイス（シンク／ＴｅｍｐＭａｓｔｅｒ／保守エンティティ）によって定義されるか、又は、パラメータ更新プロセスをトリガするコマンド（例えばＺＧＰ Ｒｅｓｐｏｎｓｅ又はＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドからの拡張ＡＣＫ Ｒｅｑｕｅｓｔ）から導出される。

Ｅｎａｂｌｅ Ｃｈａｎｎｅｌ Ｔｏｇｇｌｉｎｇ Ｂｅｈａｖｉｏｒは、０ｂ１に設定される場合、ＺＧＰＤは、対応する場合、後続の各送信について、サポートされているチャンネルセットからチャンネルを選択すべきであることを示す。

Ｅｎｔｅｒ Ｃｏｍｍｉｓｓｉｏｎｉｎｇ Ｍｏｄｅは、０ｂ１に設定される場合、ＺＧＰＤは、対応する場合、コミッショニングモードに切り替わるべきであることを示す。

Ｕｓｅ Ｓｐｅｃｉａｌ Ｃｏｍｍａｎｄ Ｆｏｒ Ｔｘは、０ｂ１に設定される場合、ＺＧＰＤは、対応する場合、特別モードにおける追加の受信機会を示すために専用コマンド（例えばＺＧＰＤ Ｃｈａｎｎｅｌ Ｒｅｑｕｅｓｔコマンド又はＺＧＰＤ Ｓｕｃｃｅｓｓコマンド）を使用すべきであることを示す。この特別なコマンドは、好適には１回送信されるが、標準的なＧＰＤＦについて定義されるようにリトライされてもよい。

外延的に、ＺＧＰＤ Ｕｐｄａｔｅ Ｐｅｎｄｉｎｇコマンドは、例えばリクエストされた受信窓の正確な継続時間又は正確な受信頻度／受信機会間の時間間隔である追加情報を有する追加フィールドを含み、特別なＺＧＰＤコマンドの識別子が、追加の受信機会をアナウンスするために使用される。これらのフィールドの存在は、好適には、０ｂ１に設定されるＯｐｔｉｏｎｓフィールドの対応するサブフィールドに示される。

さらに、上記実施形態は、ネットワーク全体の構成に関し、幾つか他の態様と組み合わされてもよいことに留意されたい。実際に、上記実施形態では、制限のあるデバイスの構成について重点を置いたが、当該構成は、ＺＧＰＤだけでなく、ネットワークのノードのすべてにも関連することがある。

実際に、ＺｉｇＢｅｅネットワークでは、キー、チャンネル、ＰＡＮＩｄ等といった構成パラメータは、完全なネットワークのためには変更する必要がある。非常に制限されたエネルギーバジェットを有するＺＧＰＤは、変更が行われる前に更新を受信する保証もなければ、変更を見出すことも自己調整することもできない。ＺＧＰＤが時間内に更新されなければ、手動によるリコミッショニングが必要となり、これは、ＺＧＰＤの通信及びユーザインターフェース（ＵＩ）能力が限られていることから、時間がかかり、手作業集約型であり、また、エネルギーハーベスティングＺＧＰＤの主要な権利である、保守フリーの動作を無効にする。

先の実施形態と組み合わせることが可能である補完的な解決策は、ＺｉｇＢｅｅネットワークで動作するＺＧＰＤに、変更されたネットワークパラメータを効率的に且つ信頼度高く配信する。このために、ＺＧＰインフラストラクチャデバイス、即ち、ＺＧＰ規格に従ってＺＧＰＤと通信可能なＺｉｇＢｅｅデバイスは、当該デバイスにＺＧＰＤを更新する時間があるように、担当のＺｉｇＢｅｅ保守エンティティ（例えばＴｒｕｓｔ Ｃｅｎｔｒｅ、ＺｉｇＢｅｅ ＰＡＮ Ｃｏｏｒｄｉｎａｔｏｒ又はＮｅｔｗｏｒｋ Ｍａｎａｇｅｒ）によって、事前に、予定されているパラメータ変更について知らされる。更新が行われると、ＺＧＰインフラストラクチャデバイスは、担当のＺｉｇＢｅｅ保守エンティティに、更新ステータス応答を提供する。このために、新しいフレームのＺＧＰフォーマット及びフレーム拡張が定義される。

ＺｉｇＢｅｅ仕様、ＺｉｇＢｅｅ文書０５３４７４ｒ１９、「ＺｉｇＢｅｅ仕様」、改定第９版、２０１０年１０月１２日、第４．６．３．４章によれば、セキュリティキー更新は、２メッセージアプローチで行われる。第１のメッセージでは、キーは、すべてのＺｉｇＢｅｅデバイスにユニキャスト又はブロードキャストで分散される。第２のメッセージでは、デバイスは、新しいキーの使用に切り替わるべきである。

ＺｉｇＢｅｅ仕様、ＺｉｇＢｅｅ文書０５３４７４ｒ１９、「ＺｉｇＢｅｅ仕様」、改定第９版、２０１０年１０月１２日、第３．１０章及び付録Ｅによれば、チャンネル及びＰＡＮＩｄ更新は、ネットワークマネジャ／ＺｉｇＢｅｅ ＰＡＮ Ｃｏｏｒｄｉｎａｔｏｒデバイスからブロードキャストを介して行われる。当該メッセージの受信後の定時（ｎｗｋＮｅｔｗｏｒｋＢｒｏａｄｃａｓｔＤｅｌｉｖｅｒｙＴｉｍｅ−ＺｉｇＢｅｅ ＰＲＯネットワークにおける数秒間に対応する）において、各デバイスは、新しい構成に切り替わる。

これらのメカニズムは、ＺＧＰインフラストラクチャデバイスが新しいパラメータをＺＧＰＤに転送するために十分な時間を提供しない点が欠点である。更に、これらのメカニズムは、更新されたＺＧＰＤの数及びどのＺＧＰＤが更新されたのかに関して、管理するＺｉｇＢｅｅエンティティに、フィードバックを提供することができず、したがって、手動リコミッショニングを含む更新後の保守を更に面倒にする。特に、キー更新について、すべてのＺＧＰインフラストラクチャデバイスが実施するｚｇｐＳｈａｒｅｄＳｅｃｕｒｉｔｙＫｅｙ属性に新しい値を書き込みするだけでは、明確なＺＧＰＤ更新制御プロセスを可能にしない。

本解決策は、ネットワークにおけるＺＧＰＤデバイスの存在を認識し、ＺｉｇＢｅｅパラメータプロセスを適宜管理できるように、ＺｉｇＢｅｅ保守エンティティに新しい能力を定義することを提案する。このために、パラメータ変更について決定がなされ、ネットワークにおけるＺＧＰＤデバイスの存在が検出されると、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅ更新を延期する。代わりに、ＺｉｇＢｅｅ保守エンティティは、まず、ＺＧＰＤパラメータ更新プロセスをトリガする。ＺｉｇＢｅｅ保守エンティティは、ＺＧＰインフラストラクチャデバイスからステータス応答を収集し、ＺＧＰＤ更新の進捗状況を含む幾つかの基準に基づいてＺｉｇＢｅｅ更新を行う時間を決定する手段を有する。このために、本解決策は、新しいＺＧＰコマンドを定義するか、又は、既存のＺＧＰコマンドを拡張する。ＺＧＰでのデュアルキー動作を可能とするために、追加のＡｌｔｅｒｎａｔｅＫｅｙ ＺＧＰ属性が提案される。

ＺｉｇＢｅｅ文書０９５４９９、「ＺｉｇＢｅｅ Ｇｒｅｅｎ Ｐｏｗｅｒ仕様（案）」、第０．９版、改定第１６版、２０１１年５月１６日に定義されるＺＧＰ仕様によれば、ＺＧＰＤは、十分なエネルギーバジェットがある場合、メッセージを送信した直後の限られた時間の間、選択された時間において、メッセージを受信できる。ＺＧＰＤスイッチの場合、受信及び送信の両方のためのエネルギーは、ユーザによる同じロッカーのトグリングからもたらされる。これらのデバイスは、エネルギーバジェット制限があるため、アクティブサーチを介して新しいパラメータを見つけることもできない。ＺＧＰＤは、ＲｘＡｆｔｅｒＴｘフラグを設定することによって、ユーザ、センサ、アプリケーション、若しくは時間又はハーベスタ／エネルギーストレージのトリガ後、当該ＺＧＰＤが送信する標準フレームにおいて、受信能力を示す。この送信後、５ｍｓが経過すると、ＺＧＰＤは、少なくとも０．５７６ｍｓの間、受信のための無線通信を開き、通常、この時間はそれ以上長くはない。この非常に時間的に制約のあるメカニズムのため、送信者は、送信機会を無駄にしないために、搬送波感知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用しない。したがって、１つのデバイスだけが、ＺＧＰＤに送信していることが非常に重要である。そうでなければ、複数の送信が、１に近い確率で衝突する。そのために、ＺＧＰ仕様は、送信元のＺＧＰＤまでの距離とＺＧＰインフラストラクチャデバイスの短いアドレスとである基準を使用して、ＺＧＰＤによって制御されるシンクが、この特定のＺＧＰＤの代わりに転送するプロキシと（ＺＧＰＤの無線範囲内にある場合は）それ自身とのうちから１つのデバイスを選択するようにＴｅｍｐＭａｓｔｅｒ選出手順を定義する。しかし、このメカニズムは、特に複数のシンクが自身をＴｅｍｐＭａｓｔｅｒとして任命した場合、同じＺＧＰＤによって制御される当該複数のシンク間のＴｅｍｐＭａｓｔｅｒを決定することができない。本解決策は、ＴｅｍｐＭａｓｔｅｒ選出手順を変更し、それに対応するためのＺＧＰ Ｒｅｓｐｏｎｓｅフレームを提案する。

更に、現在のＴｅｍｐＭａｓｔｅｒ／ＦｉｒｓｔＴｏＦｏｒｗａｒｄプロキシ選出は、ＲｘＡｆｔｅｒＴｘサブフィールドが設定されたＺＧＰＤコマンドフレームの受信後すぐに行われる。しかし、選択されたＴｅｍｐＭａｓｔｅｒのアドレスも、シンクがＺＧＰＤの直接の無線範囲内であるかどうかの情報も、シンクに現在記憶されていない。まずＴｅｍｐＭａｓｔｅｒを決定し、次にＺＧＰＤ更新フレームを準備するために、ＺＧＰＤとの次のインタラクションまで更新フレームをバッファリングすることは、追加の遅延をもたらし、したがって、更新の成功率の低下につながる。したがって、例えばＺｉｇＢｅｅパラメータ更新によってトリガされるような、ＺＧＰＤへのアドホックフレーム配信は、実行することが困難である。これに対処するために、ＴｅｍｐＭａｓｔｅｒに関連する情報をシンクに記憶することが提案される。特に、シンクが、各対にされた（ＲｘＡｆｔｅｒＴｘ対応）ＺＧＰＤに関する次の情報を追加的に記憶することが提案される。
（ｉ）ＩｎＲａｎｇｅフラグ−シンクが、ＺＧＰＤから直接受信可能であったかどうかを示す
（ｉｉ）ＴｅｍｐＭａｓｔｅｒフィールド−最後に選択されたＴｅｍｐＭａｓｔｅｒ又は現在のファースト・ツー・フォワードプロキシを示す
（ｉｉｉ）ＴｅｍｐＭａｓｔｅｒ Ｄｉｓｔａｎｃｅフィールド−ＴｅｍｐＭａｓｔｅｒへの距離、また、当該ＴｅｍｐＭａｓｔｅｒがシンク自身であるかどうかを示す。これらのアイテムは、すべてが又はこれらのうちの幾つかのみが、必須アイテム又は任意選択アイテムとして、Ｓｉｎｋ Ｔａｂｌｅエントリに、又は、別個に記憶される。

ＺＧＰＤ更新を行うために、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅ仕様によって定義される機能に加えて、次の機能を有する。
１）ＺｉｇＢｅｅ保守エンティティは、システム内で、ＺＧＰデバイスが使用されているかどうかを知っている。
２）ＺｉｇＢｅｅ保守エンティティは、ＺＧＰＤに追加の更新機会を提供するためにＺｉｇＢｅｅパラメータ更新を延期するポリシーを含む。
（ｉ）一実施形態によれば、ＺｉｇＢｅｅ保守エンティティは、どのＺＧＰＤが、受信が可能か又は不可能かについての知識を有する。更に、ＺｉｇＢｅｅ保守エンティティは、ネットワークにおいて受信可能であるＺＧＰＤの数と、どのＺＧＰＤがこの能力を有するのかについて知っている。
或いは、ＺＧＰＤの受信能力を見つける能力がない、又は、ＺＧＰＤの受信能力に関する情報がない場合、ＺｉｇＢｅｅ保守エンティティは、どのＺＧＰＤが、ＺＧＰインフラストラクチャデバイスの更新を試みるかに関しての決定を置いておく。ＺｉｇＢｅｅ保守エンティティは、当該ＺＧＰＤのＲｘＯｎＣａｐａｂｉｌｉｔｙをチェックすることによってそのようにできる。この区別は、好適には、更新に付随するトラフィック及び／又は遅延を制限するために、更新プロセスのできるだけ早期に行われる。
（ｉｉ）ＺｉｇＢｅｅ保守エンティティは、ＺＧＰＤのＮＷＫキーの保守が可能である場合、ＺＧＰＤ通信を安全にするために使用されたキーが、更新されるＺｉｇＢｅｅ ＮＷＫキーから導出されたものかどうか、したがって、ＺＧＰＤの更新とＺｉｇＢｅｅパラメータ更新の延期とが必要とされるかどうかを知っていることが好適である。或いは、ＺｉｇＢｅｅ保守エンティティが、（特定のＺＧＰＤによって）使用されるＺＧＰＤセキュリティキータイプを見つける能力がない／当該ＺＧＰＤセキュリティキータイプに関する情報がない場合、ＺＧＰＤ保守エンティティ／ＺＧＰインフラストラクチャデバイスは、特定のＺＧＰＤによって）使用されるＺＧＰＤセキュリティキータイプをチェックすることによって、この決定を行う。これは、トラフィックを制限するために、更新プロセスのできるだけ早期に行われる。
（ｉｉｉ）ＺｉｇＢｅｅ保守エンティティは、ＰＡＮＩｄの保守が可能である場合、ＺＧＰＤのどれかが、（０ｘｆｆｆｆのデフォルトのブロードキャストＰＡＮＩｄではなくて）ＰＡＮＩｄ値を使用するかどうか、したがって、ＺＧＰＤの更新及びＺｉｇＢｅｅパラメータ更新を延期することが必要であるかどうかを知っていることが好適である。
（ｉｖ）延期は、更新されるパラメータのタイプと、それを更新するＺｉｇＢｅｅ方法とに依存する。一例では、ＺｉｇＢｅｅノードへの新しいパラメータの配信と、新しいパラメータの作動との両方が延期される。別の例では、新しいパラメータの作動のみが延期される。これは、ＺｉｇＢｅｅ Ｎｅｔｗｏｒｋ Ｋｅｙ更新について可能である。
３）ＺｉｇＢｅｅ保守エンティティは、ＺＧＰＤ更新の進捗状況に依存してＺｉｇＢｅｅパラメータ更新をトリガするポリシーを有する。このポリシー基準は、ＺｉｇＢｅｅ保守エンティティのベンダ、ポリシー基準を使用するアプリケーションプロファイル、又は特定ネットワークのアドミニストレータ次第であり、次を含む。
（ｉ）ＺＧＰＤに、更新のための一定の追加時間を与える。
（ｉｉ）所与のサブセットのすべてのＺＧＰＤが、例えばそれらの機能、場所、能力に基づいて更新される。
（ｉｉｉ）ＺＧＰＤの（サブセット）の所与の割合が更新される。
４）ＺｉｇＢｅｅ保守エンティティは、次を送信することによって、ＺＧＰＤ更新をトリガする能力を有する。
（ｉ）ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンド、及び／又は、
（ｉｉ）ＺＧＰ Ｒｅｓｐｏｎｓｅコマンド‐以下に提案するように変更される。
５）任意選択的に、ＺｉｇＢｅｅ保守エンティティは、ＺＧＰＤに対しＴｅｍｐＭａｓｔｅｒを任命する能力を有する。
６）任意選択的に、ＺｉｇＢｅｅ保守エンティティは、ＺＧＰ Ｕｐｄａｔｅ Ｓｔａｔｕｓコマンドの受信によって、ＺＧＰＤ更新の進捗状況を追跡する能力を有する。ＺｉｇＢｅｅ保守エンティティは、更新トリガコマンドにおける適切な設定を介して、更新確認をリクエスト／抑制できる。
７）更に、ＺｉｇＢｅｅ保守エンティティは、例えば手動更新を必要とするＺＧＰＤの場所を示すサイトマップとして、ユーザ（例えばネットワークアドミニストレータ）に、更新結果を提示できる。
８）任意選択的に、ＺｉｇＢｅｅ保守エンティティは、ＺｉｇＢｅｅネットワークにおいてパラメータ更新が有効となった後、選択されたＺＧＰＤに対して、更新プロセスを再トリガすることが可能である。例えばチャンネル更新の場合、選択されたＴｅｍｐＭａｓｔｅｒに、一時的に古い動作チャンネルに移動するように命令するＺＧＰ Ｒｅｓｐｏｎｓｅコマンドを再送信して、更新プロセスを再トリガすることが可能である。

上記機能はすべて、実際の担当ＺｉｇＢｅｅ保守エンティティ（Ｔｒｕｓｔ Ｃｅｎｔｒｅ、ＺｉｇＢｅｅ ＰＡＮ Ｃｏｏｒｄｉｎａｔｏｒ、Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｒ）によって行われる。或いは、機能１及び２のみ、ＺｉｇＢｅｅ保守エンティティに実装され、実際のＺＧＰＤ更新及び更新進捗状況追跡は、ＺＧＰＤの知識をより多く持つ別のエンティティ、即ち、別のＺＧＰＤ保守エンティティ（例えば中央コントローラ又はコンセントレータ、ＺＧＰコミッショニングツール）に委託されて行われる。ＺＧＰＤ保守エンティティは、ＺｉｇＢｅｅ保守エンティティとは別個のデバイス又は別個のモジュール／ロールであってよい。

この解決策の第１の例は、半集中型のＴｅｍｐＭａｓｔｅｒ選出を伴うチャンネル更新である。ＺｉｇＢｅｅ保守エンティティ（この場合では、ＺｉｇＢｅｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｒ又はＺｉｇＢｅｅ ＰＡＮ Ｃｏｏｒｄｉｎａｔｏｒ）が、ネットワークにおけるＺＧＰＤの存在を知っていること、また、各ＲｘＡｆｔｅｒＴｘ対応ＺＧＰＤについて、当該ＺＧＰＤによって制御される少なくとも１つのＺＧＰＳが、（例えばコミッショニングの結果として、又は、計画、グループ割り当てに基づき、若しくは、シンクテーブルの読出しに基づき）ＺｉｇＢｅｅ保守エンティティに知られていることとが前提条件である。ＺｉｇＢｅｅ保守エンティティは更に、ＺｉｇＢｅｅパラメータ更新をいつ行うかに関して幾つかのポリシー基準（例えばＺＧＰＤ ＴｉｍｅＯｕｔが経過した、又は、ＺＧＰＤの所与のサブセットの所与の割合が成功裏に更新された）を有する。

第１のステップにおいて、ＺｉｇＢｅｅ保守エンティティは、ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドを、シンクの選択されたセットに送信する。ＺｉｇＢｅｅ保守エンティティは、当該シンクのセットを決定し、ＺＧＰＤは、各ＲｘＡｆｔｅｒＴｘ対応ＺＧＰＤが、厳密に１つの送信されたＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ ＷａｒｎｉｎｇコマンドとしてＺＧＰＤリストにおいて生じるように、これらのシンクをリストアップする。Ｐａｒａｍｅｔｅｒｓ ｐｒｅｓｅｎｃｅサブフィールドは、Ｎｅｗ Ｃｈａｎｎｅｌフィールドがあることを示す。ＮｅｗＣｈａｎｎｅｌフィールドは、新しい動作チャンネルの値を示す。Ｐｅｒｆｏｒｍ ＴｅｍｐＭａｓｔｅｒ ｅｌｅｃｔｉｏｎサブフィールドは、０ｂ１に設定される。ＡｃｋＲｅｑｕｅｓｔサブフィールドは、ＺｉｇＢｅｅ保守エンティティの更新ポリシー基準に従って設定される。

第２のステップにおいて、ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドを受信する各シンクが、ＴｅｍｐＭａｓｔｅｒを決定するサブステップと、ＺＧＰＤ Ｃｈａｎｎｅｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎコマンドを作成するサブステップとの２つのサブステップを実行するが、これらを実行する順序は重要ではない。任意選択的に、各シンクは、ＺＧＰＤＬｉｓｔフィールドにおける各ＺＧＰＤのＲｘＯｎＣａｐａｂｉｌｉｔｙをチェックし、ＴＲＵＥであるＺＧＰＤのみに更新を選択する。各シンクは、更新されるべきＺＧＰＤのそれぞれについて、ＴｅｍｐＭａｓｔｅｒを決定する。

なお、シンクは、第１のシンクが、選択されたＴｅｍｐＭａｓｔｅｒシンクはＺＧＰＤの範囲内である（また、任意選択的にそれと対にされている）ことを決定する手段を有する場合、別のシンクを、ＴｅｍｐＭａｓｔｅｒとなるように選択してもよいことに留意されたい。

更新されるべきＺＧＰＤのそれぞれについて、ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドを受信するシンクは、ＺＧＰ仕様に従ってＺＧＰＤ Ｃｈａｎｎｅｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎコマンドを作成し、ＣｈａｎｎｅｌフィールドのＯｐｅｒａｔｉｏｎａｌ Ｃｈａｎｎｅｌサブフィールドの値が、ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ ＷａｒｎｉｎｇコマンドからのＮｅｗＣｈａｎｎｅｌフィールドの値に設定される。選択されたＴｅｍｐＭａｓｔｅｒが、別のデバイス（プロキシ又はシンク）である場合、シンクは、ＺＧＰ Ｒｅｓｐｏｎｓｅコマンドを送信する。Ａｃｋ Ｒｅｑｕｅｓｔサブフィールド及びＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドの他の関連の（サブ）フィールドの値は、ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドの対応する（サブ）フィールドの値に設定される。Ｐｒｉｏｒｉｔｙ ＺＧＰＤコマンドサブフィールドは、０ｂ１に設定される。ＴｉｍｅＯｕｔフィールドは、ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ ＷａｒｎｉｎｇコマンドにおけるＵｐｄａｔｅ ｔｉｍｅフィールドに等しい値を有する。ＺＧＰ Ｃｏｍｍａｎｄ ＩＤ及びＺＧＰＤ Ｃｏｍｍａｎｄ Ｐａｙｌｏａｄフィールドは、上記決定された値を有する。

第３のステップにおいて、各ＴｅｍｐＭａｓｔｅｒは、優先順位ビットに応じて、ＺＧＰＤ用のＺＧＰＤコマンドを、そのｚｇｐＴｘＱｕｅｕｅに入れる。即ち、ｚｇｐＴｘＱｕｅｕｅにおいてこのＳｒｃＩＤのエントリが既にある場合、当該エントリは、古いメッセージの優先順位ビットが設定されていたか否かに関わらず、現在のＺＧＰＤ Ｃｈａｎｎｅｌ Ｃｏｎｆｉｇｕｒａｔｉｏｎコマンドによって置き換えられる。シンク自身が、ＴｅｍｐＭａｓｔｅｒである場合、シンクは、Ｐｒｉｏｒｉｔｙ ＺＧＰＤコマンドサブフィールドが０ｂ１に設定されたＺＧＰ Ｒｅｓｐｏｎｓｅコマンドを受信したかのように作動する。

第４のステップにおいて、ＺＧＰＰと、幾つかのＺＧＰＤの暫定マスタ（temp master）であるＺＧＰＳとは、ぞれぞれ、機会があればいつでも、且つ、ＺＧＰ Ｒｅｓｐｏｎｓｅコマンド／ＺＧＰ Ｓｙｓｔｅｍ Ｍａｉｎｔｅｎａｎｃｅ Ｗａｒｎｉｎｇコマンドを受信してから、ＴｉｍｅＯｕｔ未満の時間（ミリ秒）が経過した後、自身が暫定マスタである各ＺＧＰＤに、ＺＧＰＤコマンドを送信する。

第５のステップにおいて、Ａｃｋ Ｒｅｑｕｅｓｔサブフィールドが、値０ｂ１を有する場合、暫定マスタは、ＺｉｇＢｅｅ保守エンティティに、暫定マスタが、ＺＧＰＤ Ｃｈａｎｎｅｌ ＣｏｎｆｉｇｕｒａｔｉｏｎコマンドをＺＧＰＤに送信したかどうかを、適切な更新ステータス値を有するＺＧＰ Ｐａｒａｍｅｔｅｒ Ｕｐｄａｔｅ Ｓｔａｔｕｓコマンドを送信することによって伝える。

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

集中型のプロキシ選出プロセス（Ｃｏｏｒｄｉｎａｔｏｒ又は保守エンティティが選出の管理をする）、又は、分散型プロキシ選出プロセス（ＺＧＰＤに関連するシンクがプロキシを自動的に選択する）を伴う本実施例の他の変形も可能である。

これらの実施例のすべてにおいて、本発明の実施形態によれば、制限のあるノードにおいて、パラメータ更新動作モードを介して挙動変更をリクエストすることが提案される。

開示された実施形態への他の変更は、図面、開示内容及び添付の特許請求の範囲の検討から、クレームされた発明を実施する際に、当業者によって理解、且つ実現される。特許請求の範囲において、「含む」との用語は、他の要素又はステップを排除するものではなく、また、不定冠詞「ａ」又は「ａｎ」は複数形を排除するものではない。単一のプロセッサ又は他のユニットが、特許請求の範囲に記載される幾つかのアイテムの機能を発揮する。特定の手段が相互に異なる従属項に記載されるからと言って、それらの手段の組み合わせを有利に使用することができないことを示すものではない。上記説明は、本発明の特定の実施形態を詳述するものである。しかし、当然ながら、上記説明が、文章上、如何に詳述されているようであっても、本発明は多くの方法で実施されてよいため、開示された実施形態に限定されない。なお、本発明の特定の特徴及び態様を説明する際に使用される特定の用語は、本明細書において、当該用語が関連付けられた本発明の特徴又は態様の任意の特定の特性を含むと制限されて再定義されていることを示唆するものと解釈されるべきではないことに留意されたい。

Claims (18)

1. ネットワークにおいて、制限のある受信機会内でしかデータを受信できない制限のあるノードを構成する方法であって、
   第１のノードにおいて、
   （ａ）前記制限のあるノードについて、ネットワーク構成パラメータ値の更新が必要であることを検出するステップと、
   （ｂ）前記制限のあるノードの通信特性に少なくとも部分的に基づいて、前記制限のあるノードの挙動を、第１の挙動から変更するかどうかを決定するステップであって、前記挙動の変更は、前記制限のあるノードにおける受信機会を増加させることを含む、ステップと、
   （ｃ）ステップ（ｂ）における決定に依存して、前記制限のあるノードの第１の受信機会の間に、前記制限のあるノードへの挙動変更のリクエストの配信をトリガするステップと、
   （ｄ）前記第１の受信機会に受信した前記挙動変更のリクエストにより、受信機会を増加させる前記挙動の変更を行った前記制限のあるノードの第２の受信機会の間に、前記制限のあるノードへの更新された前記ネットワーク構成パラメータ値の配信をトリガするステップと、
   を含む、方法。
2. 前記挙動の変更は、前記制限のあるノードの受信機会の継続時間の増加を含む、請求項１に記載の方法。
3. ステップ（ｄ）は、更新された前記ネットワーク構成パラメータ値を構成フレームで送信するステップを含み、ステップ（ｂ）の前記挙動変更のリクエストは、前記構成フレームの長さに基づく継続時間の指示を含む、請求項２に記載の方法。
4. 前記挙動の変更は、前記制限のあるノードによって前記受信機会を示すように送信されるフレームの変更を含む、請求項１乃至３の何れか一項に記載の方法。
5. 前記挙動の変更は、前記制限のあるノードが、データパケットを正常に受信すると、肯定応答を送信し始めることを含む、請求項１乃至４の何れか一項に記載の方法。
6. 前記挙動の変更は、前記制限のあるノードが、前記受信機会を示すためにサポートされているチャンネルセットからの複数のチャンネルで送信することを含む、請求項１乃至５の何れか一項に記載の方法。
7. ステップ（ｂ）における前記決定は更に、次の基準：更新された前記ネットワーク構成パラメータの優先順位、更新されたネットワーク構成パラメータフレームの長さ、前記制限のあるノードの受信機会の継続時間、前記制限のあるノードの受信機会の頻度、前記制限のあるノードの能力、前記制限のあるノードのアプリケーション機能、前記制限のあるノードの場所、及び、前記制限のあるノードの優先順位のうちの少なくとも１つに基づく、請求項１乃至６の何れか一項に記載の方法。
8. 前記ネットワーク構成パラメータ値は、チャンネル識別子、セキュリティキー、セキュリティキータイプ、ネットワーク識別子、ノード識別子、報告間隔、動作モード、及び、保守エンティティ識別子のうちの少なくとも１つを含む、請求項１乃至７の何れか一項に記載の方法。
9. （ｅ）前記制限のあるノードの前記挙動を、前記第１の挙動に戻すように変更するために、前記制限のあるノードに、挙動変更のリクエストを送信するステップを更に含む、請求項１乃至８の何れか一項に記載の方法。
10. （ｇ）前記制限のあるノードが、前記制限のあるノードの構成が成功裏に完了した後に、前記制限のあるノードの前記挙動を前記第１の挙動に戻すように変更するステップを更に含む、請求項１乃至９の何れか一項に記載の方法。
11. （ｆ）前記制限のあるノードの構成が成功したことを、保守エンティティに信号伝達するステップと更に含む、請求項１乃至１０の何れか一項に記載の方法。
12. 保守エンティティと複数のノードとを含むネットワークを構成する方法であって、
    （１ａ）前記保守エンティティにおいて、制限のある期間にしかデータを受信できない、少なくとも１つの制限のあるノードの、前記ネットワークにおける潜在的な存在を検出するステップと、
    （１ｂ）前記保守エンティティにおいて、前記少なくとも１つの制限のあるノードと前記ネットワークの前記複数のノードとに共通するネットワーク構成パラメータ値の更新が必要であることを決定するステップと、
    （１ｄ）前記保守エンティティにおいて、前記制限のあるノードへの更新された前記ネットワーク構成パラメータ値の配信をトリガするステップと、
    （１ｅ）請求項１乃至１１の何れか一項に記載の方法を実行するステップと、
    を含む、方法。
13. ステップ（１ｂ）後、前記保守エンティティにおいて、前記ネットワークにおける前記少なくとも１つの制限のあるノードの前記潜在的な存在の検出に基づいて、前記複数のノードにおいて前記ネットワーク構成パラメータ値を更新するための信号の送信を延期するステップ（１ｃ）を更に含む、請求項１２に記載の方法。
14. ステップ（１ｅ）後、前記保守エンティティにおいて、前記複数のノードにおいて前記ネットワーク構成パラメータ値を更新するための信号を送信するステップ（１ｆ）を更に含む、請求項１２又は１３に記載の方法。
15. ステップ（１ｅ）は、請求項１１のステップ（ｆ）を含み、ステップ（１ｆ）は、前記保守エンティティにおける請求項１１のステップ（ｆ）の前記信号伝達の受信後に実行される、請求項１４に記載の方法。
16. ステップ（１ｅ）は、前記保守エンティティによって実行される、請求項１２乃至１４の何れか一項に記載の方法。
17. ステップ（１ｅ）は、前記保守エンティティとは異なる第１のノードによって実行される、請求項１２乃至１５の何れか一項に記載の方法。
18. ネットワークにおける、制限のある受信機会内でしかデータを受信できない制限のあるノードを構成する構成手段を含む無線ノードであって、
    前記制限のあるノードについて、ネットワーク構成パラメータ値の更新が必要であることを検出する検出手段と、
    前記制限のあるノードの通信特性に少なくとも部分的に基づいて、前記制限のあるノードの挙動を変更するかどうかを決定するコントローラと、
    を含み、
    前記挙動の変更は、前記制限のあるノードにおける受信機会を増加させることを含み、
    前記コントローラは、前記制限のあるノードの前記挙動を変更すると決定した場合の第１の受信機会の間における前記制限のあるノードへの挙動変更のリクエストの配信と、前記第１の受信機会に受信した前記挙動変更のリクエストにより、受信機会を増加させる前記挙動の変更を行った前記制限のあるノードの後続の受信機会の間における更新された前記ネットワーク構成パラメータ値の配信とをトリガする、無線ノード。