Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/0803—Configuration setting
  • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
  • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
  • H04L41/08—Configuration management of networks or network elements
  • H04L41/085—Retrieval of network configuration; Tracking network configuration history
  • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information

Definitions

• the present invention relates to a method for configuring a network, to a maintenance entity and to a communication network comprising the maintenance entity and plurality of nodes.
• This invention is, for example, relevant for wireless networks where some of the nodes that need to be configured have some strong operational limitations, like only limited and unpredictable reception time windows. This is in particular the case for ZigBee Green Power Devices inside ZigBee networks.
• a maintenance entity needs to communicate a new value for a network configuration parameter, like a channel identifier, a network identifier, node identifier or role, identifier of a new coordinator/maintenance entity inside the network, a cryptographic key or a key seed.
• a network configuration parameter like a channel identifier, a network identifier, node identifier or role, identifier of a new coordinator/maintenance entity inside the network, a cryptographic key or a key seed.
• a ZGPD ZigBee Green Power Devices
• a ZGPD can be a battery-less switch that can only receive for a short time once it is actuated by a user and has transmitted its signal.
• a ZGPD is a periodically-reporting sensor, harvesting energy from its
• a method for updating a network configuration parameter in a network comprising a maintenance entity and a plurality of nodes, the method comprising at the maintenance entity, the steps of
• the maintenance entity is able to take into account the presence of one or more limited nodes inside the network and postpone the reconfiguration of the rest of the network based on the presence of the limited nodes, for example until all the limited nodes have been reconfigured. This avoids "losing" the limited nodes that would cause joining process to be required.
• the present invention also relates to a maintenance entity and to a
• Fig. 1 A gives the format of the new ZGP System Maintenance
• Fig. IB gives the format of the Options field of the new
• Fig. 2A gives the format of the ZGP Response command
• Fig. 2B gives the format of the ZGPP Tx Channel field of
• Fig. 3A gives the format of the modified ZGP Response command
• Fig. 3B gives the format of the Options field of the modified
• Fig. 4A gives the format of ZGP Parameter Update Status
• Fig. 4B gives the format of the Options field of the ZGP Parameter
• the present invention relates to a network comprising a plurality of nodes communicating one with another.
• the network is a wireless mesh network.
• the invention will be described in the context of the ZigBee standard and more especially the ZigBee Green Power (ZGP) standard.
• ZigBee Green Power Devices like energy-harvesting switches and batteryless sensors, are operating in ZigBee networks.
• the configuration parameters such as key, channel, PANId, etc.
• ZGPDs with their very limited energy budget are neither guaranteed to receive the update before it takes effect, nor capable to discover the change and self-adjust.
• the result is the necessity of manual re- commissioning, which is time-consuming, manually-intensive due to limited communication and User Interface (UI) capabilities of the ZGPD, and also invalidates the major claim of energy-harvesting ZGPDs: their maintenance-free operation.
• UI User Interface
• the present invention provides a solution for efficient and reliable delivery of changed network parameters to ZGPD operating in ZigBee networks.
• ZGP infrastructure devices i.e. ZigBee devices which are capable of communicating with ZGPD according to the ZGP standard, are informed about the planned parameter change in advance by the responsible ZigBee maintenance entity, e.g. Trust Centre, ZigBee PAN Coordinator or Network Manager, such that they have time to update the ZGPDs.
• the ZGP infrastructure device can provide the responsible ZigBee maintenance entity with the update status response. New frame ZGP formats and frame extensions are defined for that purpose.
• the security key update is done in a 2-message approach.
• the key is distributed to all ZigBee devices in unicast or broadcast.
• the devices shall switch to using the new key.
• the channel and PANId updates are performed via a broadcast from the Network Manager/ZigBee PAN Coordinator device. A fixed time after reception of this message
• each device switches to the new configuration.
• a drawback is that these mechanisms do not provide enough time for the ZGP infrastructure devices to forward the new parameter to the ZGPD. Furthermore, they do not allow for providing any feedback to the managing ZigBee entity as to how many and which
• the present invention proposes to define a new capability on the ZigBee maintenance entity, to be aware of the potential or actual presence of ZGPD devices in the network and to manage the ZigBee parameter process accordingly.
• the ZigBee maintenance entity postpones the ZigBee update. In the mean time, it triggers the ZGPD parameter update process first. It has the means for collecting the status responses from the ZGP infrastructure devices, and for determining the time of performing the ZigBee update based on some criteria, including the ZGPD update progress.
• the present invention defines new ZGP commands or extends existing ones.
• an additional ZGP attribute, zgpAlternateSharedSecurityKey is proposed.
• a ZGPD if it has sufficient energy budget, can, at selected times, receive a message for a limited time just after it has sent a message. In case of a ZGPD switch, the energy for both receiving and sending comes from one and the same rocker toggling by the user. Because of their energy budget limitations, those devices are also not able to discover the new parameters via an active search.
• the ZGPD indicates the reception capability in the regular frame it sends, upon user or sensor or application or time or harvester/energy storage trigger, by setting an RxAfterTx flag. Five (5) ms after this transmission, the ZGPD opens its radio for reception, for at least 0.576 ms and usually not much longer.
• the senders do not use carrier-sense multiple access with collision avoidance (CSMA/CA), in order to to not waste the transmission opportunity.
• CSMA/CA carrier-sense multiple access with collision avoidance
• the ZGP specification defines a TempMaster election procedure, such that a sink controlled by the ZGPD selects one device from the proxies forwarding on behalf of this particular ZGPD and itself, if it is in radio range of the ZGPD, by using the criteria of distance to originating ZGPD and the ZGP infrastructure device's short address.
• this mechanism lacks the TempMaster resolution between multiple sinks controlled by the same ZPGD, especially if they appoint themselves as the TempMaster.
• the present invention proposes to change the TempMaster election procedure, and the ZGP Response frame to accommodate for that.
• the current TempMaster/FirstToForward proxy election is performed immediately upon reception of ZGPD command frame with the RxAfterTx sub- field set.
• neither the address of the selected TempMaster nor the information if the sink is in direct radio range of the ZGPD is currently stored in the sink. Buffering the update frame until the next interaction with the ZGPD, to first determine the TempMaster and then prepare the ZGPD update frame introduces additional delay, and thus may lead to reduced update success rate. Therefore, an ad-hoc frame delivery to the ZGPD, e.g. like one triggered by ZigBee parameter update, is difficult to perform. To cope with this, it is proposed to store TempMaster related information in the sink. Specifically, it is proposed for the sink to store additionally the following information on each (RxAfterTx-capable) paired ZGPD:
• TempMaster Distance field indicating the distance to the TempMaster, also if it is the sink itself.
• the ZigBee maintenance entity has - in addition to the functions defined by the ZigBee specification - the following functions:
• the ZigBee maintenance entity can know how many ZGPDs in the network are capable of reception, and also which ZGPDs have this capability. .
• the ZigBee maintenance entity can leave the decision as to which ZGPD to try to update to the ZGP infrastructure devices. They can do so by checking for the RxOnCapability of this ZGPD. This differentiation is preferably is done as early as possible in the update process, to limit the traffic and/or the delay associated with the update.
• the ZigBee maintenance entity is capable of maintenance of the NWK key for ZGPD, it preferably will know if the key used to secure ZGPD communication is derived from the ZigBee NWK key being updated, and thus, if updating the ZGPD and postponing the ZigBee parameter update is required. Alternatively, if it does not have capability to disco ver/information on the ZGPD security key type used (by a particular ZGPD), the ZGPD maintenance entity/ZGP infrastructure devices make this decision, by checking for the security key type used (by a particular ZGPD). This is done as early as possible in the update process, to limit the traffic.
• the ZigBee maintenance entity is capable of maintenance of the PANId, it preferably will know, if any of the ZGPDs uses the PANId value (rather than the default broadcast PANId value of Oxffff), and thus, if updating the ZGPD and postponing the ZigBee parameter update is required.
• the postponing may be dependent on the type of parameter updated and the ZigBee method of updating it.
• both the delivery of the new parameter to the ZigBee nodes, and the activation of the new parameter can be postponed.
• only the activation of the new parameter can be postponed; that's possible for the ZigBee Network Key update.
• the policy criteria are up to the ZigBee maintenance entity vendor, the application profile using it, or the administrator of a particular network and can include:
• the subset definition may be based on some properties of the ZGPD e.g. their functionality, location, capability, priority, etc.
• the ZigBee maintenance entity has the capability of triggering a ZGPD update, by sending:
• the ZigBee maintenance entity has the capability of appointing a TempMaster for each ZGPD.
• the ZGPD update has the capability of tracking the progress of the ZGPD update, by reception of the ZGP Update Status command. It can request/suppress the update confirmation via appropriate setting in the update triggering command.
• the ZigBee maintenance entity may be able to present the update results to the user (e.g. network administrator), for example as a sitemap, indicating the location of the ZGPDs requiring manual update. 8)
• the ZigBee maintenance entity is capable of re-triggering the update process for selected ZGPDs after the parameter update became effective in the ZigBee network, e.g. in case of a channel update by re-sending ZGP Response command to a selected
• All the above-mentioned functions can be performed by the actual responsible ZigBee maintenance entity (Trust Centre, ZigBee PAN Coordinator, Network Manager). Alternatively, only functions 1 and 2 are implemented in the ZigBee maintenance entity, and the actual ZGPD update and update progress tracking can be delegated to and performed by another entity, ZGPD maintenance entity, more knowledgeable about ZGPD (e.g. central controller or concentrator, a ZGP commissioning tool, etc).
• the ZGPD maintenance entity can be a separate device or a separate module/role of the ZigBee maintenance entity.
• the present invention proposes new message formats for enabling automatic parameter update in ZigBee networks incorporating ZGPDs.
• the present invention introduces a new command, the ZGP System Maintenance Warning command, the format of which is depicted in Figs. 1 A (Format of the command) and IB (Format of the Options field of the command).
• This command allows a ZigBee maintenance entity to pre- announce a parameter change to (selected) ZGP infrastructure devices.
• the format of the ZGP System Maintenance Warning command in more details.
• the command is sent in unicast or in broadcast.
• the proxies For the proxies to be able to act upon reception of this command, they have to be able to generate the ZGPD update commands, i.e. ZGPD Channel Configuration and ZGPD Commissioning Reply command.
• the Parameters presence field indicates which fields carrying configuration parameter are present in the command.
• the meaning of the Parameters presence field is described in the following table.
• the value of the ZGPD list size sub field of the Options field equals the number of ZGPDs that the new configuration parameter must be forwarded to.
• a value of ObOOOO indicates that the list is empty; a value of Obi 111 indicates forwarding is required to all ZGPDs known to the receiving device.
• the device shall deliver the update itself (i.e. was selected as a TempMaster by the NWK Mgr); if the value equals Obi, the receiving device shall perform the TempMaster election first. If the AckRequest subfield of the Options field has value Obi, the ZigBee maintenance device is interested in receiving the SrcID of the ZGPDs to which the channel update has been forwarded. If the subfield has value ObO, the ZigBee maintenance device is not interested in receiving these SrcIDs.
• the Update time field indicates the time (in ms) available to deliver the update to the ZGPD.
• a value Oxffff for the Switch time field indicates undefined. When this value expires, and latest with the parameter switch, the receiving device may remove undelivered ZGPD commands from its zgpTxQueue.
• the New channel field carries the new value for the operational channel.
• the New Channel field can take the following values: ObxxxxOOOO is channel 11, ObxxxxOOOl is channel 12, ... , Obxxxxl 111 is channel 26.
• the New key field carries a new value for the ZigBee Network Key.
• the New PANId field carries a new value for the PANId parameter.
• the ZGPD list field consists of a ZGPD list size set of 32-bit unsigned integers, each such integer representing the SrcID of a ZGPD. If the ZGPD list size has value Obi 111, the ZGP list is absent, and forwarding must take place to all ZGP devices known to the receiving device. Some extensions to the ZGP System Maintenance Warning command are possible. More details on the required confirmation can be provided. Confirmation type can be requested and aligned with the ZGP Update Status command, e.g. including:
• Confirmation time e.g. per ZGPD, after updating all ZGPD, or at a determined time, can also be requested.
• additional Options sub-fields can be defined, allowing for specifying the type of the key being distributed: ZigBee NWK key, derivative ZGPD group key, independent ZGPD group key or ZGP TC-LK.
• the ZGPD list size subfield can be skipped and a complex, length-indicating data type can be used ZGPD list field, e.g. an array of unsigned 32-bit integer.
• the present invention proposes extensions to the ZGP Response command.
• the ZGP Response command is used in the current ZGP specification to tunnel the ZGPD command to be delivered to the ZGPD from the originating sink to the TempMaster proxy selected by the sink.
• the description of the ZGP Response command as given in ZGP is disclosed in Fig. 2A.
• the ZGPP short address field indicates the address of the ZGPP which will transmit the Response GPDF to the ZGPD.
• the ZGPPTxChannel field indicates the channel the Green Power Device Frame (GPDF) carrying the ZGPD command will be sent on. It shall be formatted as shown in Fig. 2B. When the ZGPP short address field is set to Oxffff, the ZGPPTxChannel field shall be ignored.
• the TransmitChannel sub-field of the ZGPPTxChannel field can carry the value of the operational channel.
• the ZGPD SrcID field carries the identifier of the ZGPD for which the GPDF frame is intended.
• ZGPD CommandID and ZGPD Command payload carry the input for the corresponding GPDF fields.
• the ZGPD Command Payload field is an octet string.
• the first octet contains the payload length; the following octets the value for the GPDF field ZGPD Command payload.
• the value of Oxff indicates unspecified/no payload.
• the present invention modifies the ZGP Response command as disclosed in
• the TempMaster Distance field denotes the distance (in meters) between the ZGPD with SrcID as in the ZGPD SrcID field and the device with short address as in the TempMaster short address field, as measured by the latter device.
• TimeOut field indicates the time (in ms) after which the undelivered ZGPD command can be removed from the zgpTxQueue.
• a value of Obi of the AckRequest sub field of the Options field indicates that the originator of the ZGP Response command expects an acknowledgement once the ZGPD is delivered; a value of ObO indicates that no acknowledgement is expected.
• the Priority ZGPD command subfield if set to Obi, indicates that the ZGPD command (to be stored in the zgpTxQueue) carries priority information (such as channel/key update or commissioning commands) and shall not be overwritten by non-priority commands.
• priority information such as channel/key update or commissioning commands
• the additional fields of the ZGP Response command may also be used for other instances of sending to ZGPD, e.g. for commissioning operation or for delivering data to the ZGPD.
• the TimeOut can be used to manage the zgpTxQueue; the AckRequest together with the ZGP Parameter Update Status command can be used for assessing the reliability of the ZGPD-TempMaster link.
• the present invention proposes further extensions to the modified ZGP Response command.
• Confirmation type can be requested (and aligned with the ZGP Update Status command), e.g. including:
• TimeOut field could be optional and indicated by a corresponding flag in the Options field or an appropriate value of the TempMaster short address field (e.g. one different than Oxffff).
• TempMaster short address field (e.g. one different than Oxffff).
• TempMaster election could be included in the command, e.g. freshness of the TempMaster information, i.e. the ZGPD Sequence Number/Frame Counter the TempMaster selection was based on.
• the present invention proposes a new ZGP Parameter Update Status command, as depicted in Figs. 4 A and 4B.
• the Key Update Report, Channel Update Report, PANId Update Report sub- fields, if set to Obi, indicate that the command includes update status for the respective parameter.
• the ZGPD list size sub-field of the Options field indicates the number of ZGPD SrcID present in the ZGPD list field.
• a value of ObOOOO indicates that the list is empty; a value of Obi 111 all ZGPDs known to the transmitting device.
• the ZGPD list needs not equal the ZGPD list from the ZGP System Update Warning command, if received, but it contains of the ZGPD devices with update status as indicated in the Options subfield.
• the ZGPD list size subfield can be skipped and a complex, length- indicating data type can be used ZGPD list field, e.g. an array of unsigned 32-bit integers
• a first example is a channel update with semi-centralised TempMaster election.
• the pre-requisites are that the ZigBee maintenance entity (ZigBee Network
• the Manager or ZigBee PAN Coordinator in this case is aware about the ZGPD presence in the network and that, for each RxAfterTx -capable ZGPD, at least one ZGPS controlled by that ZGPD is known to the ZigBee maintenance entity (e.g. as a result of commissioning or based on the planning, group assignment, or based on reading out sink tables). It further has some policy criteria when to perform the ZigBee parameter update (e.g. the ZGPD TimeOut elapsed, or given percentage of a given subset of ZGPD was successfully updated).
• the ZigBee parameter update e.g. the ZGPD TimeOut elapsed, or given percentage of a given subset of ZGPD was successfully updated.
• the ZigBee maintenance entity sends ZGP System Maintenance Warning commands to a selected set of sinks.
• the ZigBee maintenance entity has determined the set of sinks and the ZGPD lists for these sinks in such a way that each RxAfterTx capable ZGPD occurs in the ZGPD list of exactly one transmitted ZGP System Maintenance Warning command.
• the Parameters presence sub-field indicates that the New Channel field is present.
• the NewChannel field indicates the value of the new operational channel.
• the Perform TempMaster election sub-field is set to Obi.
• the AckRequest sub-field is set according to the update policy criteria of the ZigBee maintenance entity.
• each sink receiving a ZGP System Maintenance Warning command performs two substeps of determining the TempMasters and creating ZGPD Channel Configuration commands, whereby the order of performing them is irrelevant.
• each sink checks the RxOnCapability of every ZGPD in the ZGPDList field, and selects for update only those, for which it is TRUE.
• Each sink determines the TempMaster for each of the to be updated ZGPDs.
• a sink may select another sink to become TempMaster, if the first sink has the means of determining that the selected TempMaster sink (e.g. a ZGPCm) is in the range of the ZGPD (and optionally also paired to it).
• the selected TempMaster sink e.g. a ZGPCm
• the sink receiving the ZGP System Maintenance Warning command creates a ZGPD Channel Configuration command according to the ZGP specification with the value of the Operational Channel subfield of the Channel field set to the value of the NewChannel field from the ZGP System Maintenance Warning command.
• the sink sends a ZGP Response command.
• the value of the AckRequest subfield and other relevant (sub-)fields of the ZGP Response command are set to the value of the corresponding (sub-)field in the ZGP System Maintenance Warning command.
• the Priority ZGPD command subfield is set to Obi .
• the TimeOut field has a value equal to the Update time field in the ZGP System Maintenance Warning command.
• the ZGP Command ID and ZGPD Command Payload field have the values as determined above.
• each TempMaster places the ZGPD command for the ZGPD in its zgpTxQueue, according to the priority bit, i.e. if there is already an entry for this SrcID in the zgpTxQueue, it is replaced with the current ZGPD Channel Configuration command, irrespective of whether the old message had the priority bit set or not. If the sink itself is TempMaster, it acts as if it received a ZGP Response command with the Priority ZGPD command subfield set to Obi.
• each ZGPP and ZGPS that is the temp master for some ZGPD sends the ZGPD command to each ZGPD for which it is a temp master whenever it has an opportunity to do so and less than TimeOut ms have elapsed since reception of the ZGP Response command/ZGP System Maintenance Warning command.
• the temp master informs the ZigBee maintenance entity whenever it has sent the ZGPD Channel
• the ZigBee maintenance entity triggers the ZigBee parameter update.
• the ZGP infrastructure nodes follow the ZigBee protocol in their ZigBee roles.
• the undelivered priority entries may be removed from the zgpTxQueues.
• Another example is channel update with distributed TempMaster election.
• the pre-requisites are that ZigBee maintenance entity (Network Manager or ZigBee PAN).
• the Coordinator in this case, is aware about the ZGPD presence in the network and is capable of sending ZGP System Maintenance Warning command for the required parameter update. It further has some policy criteria when to perform the ZigBee parameter update (e.g. the ZGPD TimeOut elapsed, or given percentage of a given subset of ZGPD was successfully updated).
• the ZigBee maintenance entity sends ZGP System Maintenance Warning command in broadcast.
• the Parameters presence sub-field indicates that the New Channel field is present.
• the AckRequest field is set according to the update policy criteria of the ZigBee maintenance entity.
• the Perform TempMaster election subfield is set to Obi .
• the ZGPD list size is set to Obi 111 , indicating "all".
• the NewChannel field indicates the value of the new operational channel.
• each sink receiving a ZGP System Maintenance Warning command, for each of the ZGPDs it is paired to performs the following substeps, whereby the order of performing the steps of determining the TempMasters and creating ZGPD Channel Configuration command is irrelevant.
• a sink may select another sink to become TempMaster, if the first sink has the means of determining that the selected TempMaster sink (e.g. a ZGPCm) is in the range of the ZGPD (and optionally also paired to it).
• the selected TempMaster sink e.g. a ZGPCm
• the ZGP Response command carries in the TempMaster short address field the address of the chosen
• the value of the AckRequest subfield of the ZGP Response command is set to the value of the corresponding subfield in the ZGP System Maintenance Warning command.
• the Priority ZGDP Command subfield is set to Obi .
• the TimeOut field has a value equal to the Update time field in the ZGP System Maintenance Warning command.
• the ZGPD Command ID and ZGPD Command Payload fields have values as determined above.
• each TempMaster proxy/sink places the ZGPD command for the ZGPD in its zgpTxQueue, according to the priority bit. If it subsequently receives a ZGPD Response for the same ZGPD, with a better TempMaster candidate, it shall remove the entry from the zgpTxQueue, without sending ZGP Parameter Update Status command.
• each TempMaster sends the ZGPD command to each ZGPD for which it is a temp master whenever it has an opportunity to do so and less than TimeOut ms have elapsed since reception of the command that triggered placement of the ZGPD command into the zgpTxQueue of this TempMaster: ZGP Response command /ZGP System Maintenance Warning command.
• the temp master informs the ZigBee maintenance entity whenever it has sent a ZGPD Channel Configuration command, by sending the ZGP Parameter Update Status command with the appropriate update status value.
• the ZigBee maintenance entity triggers the ZigBee parameter update.
• the ZGP infrastructure nodes follow the ZigBee protocol in their ZigBee roles.
• the undelivered priority entries may be removed from the zgpTxQueues.
• the pre-requisites for the first variant are the following: the ZigBee maintenance entity (Network Manager or ZigBee PAN Coordinator in this case) is aware about the ZGPD presence in the network and capable of generating the ZGPD commands for the required parameter update: the ZGPD Channel Configuration command in this case. It has knowledge about a tempMaster for each RxAfterTx-capable ZGPD (e.g. as a result of commissioning or based on the network planning, or based on reading out sink/proxy tables). It further has some policy criteria when to perform the ZigBee parameter update (e.g. the ZGPD TimeOut elapsed, or given percentage of a given subset of ZGPD was successfully updated).
• the ZigBee maintenance entity Network Manager or ZigBee PAN Coordinator in this case
• the ZigBee maintenance entity has determined the set of TempMasters for the RxAfterTx capable ZGPD in such a way that for each RxAfterTx capable ZGPD, one ZGP Response command is generated.
• the ZigBee maintenance entity sends ZGP Response commands to the selected set of TempMasters (sinks or proxies), preferably in unicast.
• the ZGP Response command contains the ZGPD Channel Configuration command for the operational channel update, and the ZGPD SrcID to deliver it to.
• the Priority ZGPD Command field is set to Obi .
• the AckRequest field is set according to the update policy criteria of the ZigBee maintenance entity.
• the TempMaster checks the RxOnCapability of the ZGPD and if TRUE, places the ZGPD command in its zgpTxQueue, according to the priority bit.
• each TempMaster sends the ZGPD command to each ZGPD for which it is a temp master whenever it has an opportunity to do so and when less than UpdateTime ms have elapsed since reception of the ZGP Response command.
• the temp master informs the ZigBee maintenance entity whenever it has sent a ZGPD Channel Configuration command, by sending the Parameter Update Status Command with the appropriate update status value.
• the ZigBee maintenance entity triggers the ZigBee parameter update once the update policy criteria are fulfilled.
• the ZGP infrastructure nodes follow the ZigBee protocol in their ZigBee roles.
• the undelivered priority entries may be removed from the zgpTxQueues.
• a seventh step if some RxAfterTx capable devices were not updated, ZGP Response can be used after the channel switch has taken effect, to try to update the ZGPD (again). Then, the TempMaster Tx channel should be set to the old operational channel.
• the pre-requisites are: the ZigBee maintenance entity (Network Manager or ZigBee PAN Coordinator in this case) is aware about the ZGPD presence in the network. It has knowledge about a TempMaster for each Rx after Tx capable ZGPD (e.g. as a result of commissioning or based on the network planning, or based on reading out sink/proxy tables), but it only has the capability of generating ZGP System Maintenance command. It further has some policy criteria when to perform the ZigBee parameter update (e.g. the ZGPD TimeOut elapsed, or given percentage of a given subset of ZGPD was successfully updated). In a first step, the ZigBee maintenance entity sends ZGP System Maintenance
• Warning commands with NewChannel field present to a selected set of TempMasters (sinks or proxies), preferably in unicast.
• the ZigBee maintenance entity has determined the set of TempMasters and the ZGPD lists for these TempMasters in such a way that each RxAfterTx- capable ZGPD occurs in the ZGPD list of exactly one transmitted ZGP System Maintenance Warning command.
• the Perform TempMaster election subfield is set to ObO.
• AckRequest subfield and Update time field are set according to the update policy criteria of the ZigBee maintenance entity.
• each TempMaster checks the RxOnCapability of the ZGPD and if TRUE, it creates a ZGPD Channel Configuration command according to ZGP with the value of the Operational Channel subfield set to the value of the NewChannel field from the ZGP System Maintenance Warning command and places the ZGPD command in its zgpTxQueue, according to the priority bit. It is to be noted that, for the proxies, this requires the new capability of creating ZGPD update commands (not required by the current ZGP specifications).
• each TempMaster sends the ZGPD command to each ZGPD in the ZGPD list whenever it has an opportunity to do so and less than Update Time ms have elapsed since reception of the ZGP System Maintenance Warning command.
• the temp master informs the ZigBee maintenance entity whenever it has sent a ZGPD Channel Configuration command, by sending the Parameter Update Status Command with the appropriate update status value.
• the ZigBee maintenance entity triggers the ZigBee parameter update.
• the ZGP infrastructure nodes follow the ZigBee protocol in their ZigBee roles.
• the undelivered priority entries may be removed from the zgpTxQueues.
• the ZigBee maintenance entity Network Manager or ZigBee PAN Coordinator in this case
• the ZGPD maintenance entity has knowledge about a TempMaster for at least each RxAfterTx capable ZGPD (e.g. as a result of commissioning or based on the network planning, or based on reading out sink/proxy tables).
• the ZigBee maintenance entity sends ZGP System Maintenance Warning command to the ZGPD maintenance entity.
• the Parameters presence sub-field indicates that the New Channel field is present.
• the NewChannel field carries the value of the new operational channel.
• the Perform TempMaster election sub-field is set to Obi .
• the AckRequest sub-field is set according to the update policy criteria of the ZigBee maintenance entity; preferably, the extended requirements on the confirmation type and time are used.
• the ZGPD maintenance entity performs the following steps for each of the ZGPDs:
• the ZGP Response command carries in the TempMaster short address field the address of the chosen TempMaster for the ZGPD indicated in the ZGPD SrcID field (even if the sink itself is the temp master); and in the TempMaster distance field it carries the distance between the ZGPD and the TempMaster, as measured by the TempMaster.
• the value of the AckRequest subfield of the ZGP Response command is set to the value of the corresponding subfield in the ZGP System Maintenance Warning command.
• the Priority ZGDP Command subfield is set to Obi .
• the TimeOut field has a value equal to the Update time field in the ZGP System Maintenance Warning command.
• Command Payload fields have values as determined above.
• the TempMaster checks the RxOnCapability of the ZGPD and if TRUE, places the ZGPD command for in its zgpTxQueue, according to the priority bit.
• each TempMaster sends the ZGPD command to each ZGPD for which it is a temp master whenever it has an opportunity to do so and when less than TimeOut ms have elapsed since reception of the ZGP Response command.
• the temp master informs the ZGPD maintenance entity whenever it has sent a ZGPD Channel Configuration command, by sending the ZGP Parameter Update Status Command with the appropriate update status value.
• the ZGPD maintenance entity informs the ZigBee maintenance entity about the progress of the ZGPD parameter update.
• the ZigBee maintenance entity checks the update progress and triggers the ZigBee parameter update.
• the ZGP infrastructure nodes including ZGPD maintenance entity, follow the ZigBee protocol in their ZigBee roles.
• the undelivered priority entries may be removed from the zgpTxQueues.
• the ZGPD maintenance entity can send a ZGP Response after the channel switch has taken effect, to try to update the ZGPD (again). Then, the TempMaster Tx Channel field of the ZGP Response should be set to the old operational channel.
• the update process can be iterative: If the selected sink TempMaster does not have the capabilities requested by the update-related ZGP command targeted at it (e.g. sink proxy not supporting bidirectional communication, not paired with the ZGPD, etc., ZGPT nominated as a TempMaster, etc.), it may respond with standard ZCL response indicating the appropriate error status and a new device can be nominated. PANId updates can be performed analogously to the channel updates, with
• the PANId update may be skipped for ZGPDs without reception capabilities and ZGPDs not using the PANId (by default, ZGP specification allows to use PANId Oxffff).
• ZGPD key updates resulting from the ZigBee NWK key updates can be performed analogously to the channel updates, with ZGP System Maintenance Warning command carrying the New Key field and ZGP Response command carrying ZGPD
• the maintenance entity in the illustrative embodiments above can have different other roles in the network. For example, it is possible to have the coordinator carrying out the functions of maintenance entity. As opposed, it is possible that the maintenance entity is a different node having these particular capabilities and for example only dedicated to the maintenance in the network of ZigBee Green Power Devices, like batteryless devices.
• a proxy node in the following can be any ZGP infrastructure node, i.e. either be a ZGP proxy (ZGPP) or a ZGP sink (ZGPS), according to the nomenclature of the ZGP specification (ZigBee document 095499rl6ZB).
• ZGPP ZGP proxy
• ZGPS ZGP sink
• the term "linked" is used to describe any relationship a ZGP infrastructure device may have with a ZGPD, i.e. a Sink Table entry and/or an active Proxy Table entry.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Mobile Radio Communication Systems (AREA)

Priority Applications (4)

Applications Claiming Priority (2)

Publications (1)

Family

ID=46246119

Family Applications (1)

Country Status (5)

Cited By (2)

Families Citing this family (4)

Citations (5)

Family Cites Families (10)

• 2012
  • 2012-05-25 US US14/119,293 patent/US9860127B2/en active Active
  • 2012-05-25 WO PCT/IB2012/052635 patent/WO2012168819A1/en not_active Ceased
  • 2012-05-25 EP EP12726874.6A patent/EP2719122B1/en active Active
  • 2012-05-25 CN CN201280028152.1A patent/CN103583017B/zh active Active
  • 2012-05-25 JP JP2014514173A patent/JP6031668B2/ja active Active

Patent Citations (5)

Also Published As

Similar Documents

Legal Events