Zigbee 3.0#

Zigbee 3.0 marks the beginning of a new chapter in the Connectivity Standards Alliance. Zigbee 3.0 unites all of the different application profiles into one common application layer. Furthermore, it introduces greater test coverage for product certification, ensuring better interoperability for Zigbee devices in the field. The Zigbee 3.0 document suite contains both revised and completely new material for the Zigbee application specification.

The Base Device Behavior Specification (BDB) is perhaps the most important new document in the Zigbee 3.0 document suite. It specifies mandatory and optional application layer behavior for any Zigbee product. These behaviors include, but are not limited to:

  • Network commissioning

  • Network security

  • ZDO command handling

  • Reporting

  • MAC data polling

  • Persistent data

See document 13-0402 for more specific information on these items. Because there is now one specification for all Zigbee applications, two different Zigbee 3.0-compliant products in different application domains can interoperate on the same network (for example, a light switch and a garage door opener can perform separate functions on the same network).

At the heart of the BDB are the commissioning methods that a Zigbee 3.0 device can use. The methods follow an order of execution, but they are all optional for a device. For example, it may only makes sense for a Zigbee End Device switch application to performing touchlink commissioning, classical joining, and then finding and binding. On the other hand, a Zigbee Coordinator gateway application may only wish to form a network. Lastly, maybe a Zigbee Router light application could perform classical joining, and then fall back to classical network formation if it does not find any networks to join. The commissioning methods, and order, are as follows.

  • Touchlink commissioning

  • Classical network joining

  • Classical network formation

  • Finding and binding

Touchlink commissioning is the first step in the Zigbee 3.0 network commissioning process. A device may choose to perform the touchlink process for an initiator to try and find a touchlink target. A typical example of this interaction may be a switch and a light. The switch may perform touchlink commissioning to establish itself on the same network as the light. See 13-0402 for a more in-depth description of touchlink commissioning.

The next step in the BDB defined process is classical joining. This means finding open networks and joining one using the original Zigbee joining process. Finding a network involves performing IEEE 802.15.4 active scans on a product-defined set of channels. Once a device has found a network that it wishes to join, it may join that network using an install code derived link key, a default link key for a centralized security network, and a default link key for a distributed security network. For more information on the security mechanisms involved in the Zigbee 3.0 application layer, see Zigbee Security.

A Zigbee 3.0 application may then choose to form a classical Zigbee network. A product may form a centralized security network as a trust center or form a distributed security network as a router. This is different from many legacy application profiles where only a Zigbee coordinator could form a network. A light may wish to form a network as a router so that it can act as a touchlink target, whereas it makes more sense for a gateway to form a centralized network as a trust center. Trust centers may choose to only allow only certain devices on the network by using install code derived link keys for joining. Again, see Zigbee Security for a thorough discussion of Zigbee 3.0 security.

Once devices are on a network, they can perform finding and binding, where devices create bindings to establish application layer links. For example, an On/Off switch may perform finding and binding to create a binding to an On/Off Light. Again, as all commissioning steps, this step is optional.

As mentioned previously, Zigbee 3.0 also introduces more stringent testing on products. This means products will go through more negative test cases and specific cluster functionality tests before they are allowed on the market. Included in the Zigbee 3.0 document suite are the new Cluster Test Specifications. These documents contain test cases for Zigbee products implementing certain clusters. For a product using a certain cluster to be Zigbee 3.0 certified, it must pass the test cases contained within this document for that specific cluster. There is an individual Zigbee document for each cluster test spec. For an example, see document 15-0310, the On/Off Cluster test specification.

Zigbee 3.0 also mandates that devices should support proxy functionality for Green Power, a networking and application-level specification designed for energy-harvesting end devices. Essentially, this means that every Zigbee 3.0 device will be able to process and forward Green Power messages to other devices with more application-layer Green Power functionality. The Green Power Basic specification and test specification are included in the Zigbee 3.0 document suite. See Silicon Labs Green Power Fundamentals for more information.

It is worth mentioning that the 6th revision of the Zigbee Cluster Library (document 15-02017) is also included in the Zigbee 3.0 document suite. See Zigbee Cluster Library for more information about this specification.