Guide to Zigbee 3.0

If you are new to Zigbee 3.0, read the guide below to get more information on the key changes to the Zigbee standard.

Do you already have a RapidHA (HA1.2) solution? Migrating to our Zigbee 3.0 compliant RapidConnect solution is fast and easy.

See our guide to Building a Zigbee 3.0 Compliant Device with RapidConnect.

What Is Zigbee 3.0?

Zigbee 3.0 is the latest version of the Zigbee standard. The most significant change from previous versions is that Zigbee 3.0 consolidates all of the previous Zigbee "Profiles" such as Home Automation, Light Link, Building Automation, etc. into one, interoperable application layer standard. 

Zigbee 3.0 also adds some security enhancements while importantly maintaining backward compatibility with the original Profiles.

MMB's RapidConnect, and our product line based around RapidConnect offer support for Zigbee 3.0 (as well as legacy support for older products).

A note on Smart Energy: Due to its unique security features and use cases, Smart Energy has not to date been merged into Zigbee 3.0 - it remains the only separate Profile, but is still actively maintained by the alliance. It is now being marketed as "Smart Energy by Zigbee Alliance" to reflect this change.


The answers to some common questions related to Zigbee 3.0 are captured here.

Zigbee 3.0 incorporates over 10 years of experience from over 400 member companies and it is an exciting step toward streamlining IoT standards!

MMB has been actively involved in the development of the Zigbee 3.0 specification and we created this page to share some helpful information with our partners and customers.

If you would like to gain access to the Zigbee specifications, you can download them by registering at this link: 

You can also join the Zigbee Alliance via this link:

What do I need to know?

Key Terms

Node vs Device

"A node defines a single instance of the Zigbee PRO stack with a single IEEE address on a single network."

A node is made up of one or more devices, each residing on an endpoint.

Simple Device vs Dynamic Device

"A simple device is an application implementation of an application specific endpoint that has mandatory application clusters."

"A dynamic device is an application implementation of an endpoint that has no specific set of application clusters."

Finding & binding (EZ-Mode) is mandatory for simple devices and optional for dynamic devices.

Application Cluster vs Utility Cluster

"A utility cluster is a cluster whose function is not part of the persistent functional operation of the product. Function examples: commissioning, configuration, discovery, etc."

"An application cluster is a cluster that generates persistent functional transactions." Examples: Basic, Identify, Temperature Measurement, On/Off.

An application (or functional) transaction "is a cluster command, and possible response, that is generated to perform the device's persistent function, such as attribute reporting or actuation commands. An application transaction is not a ZDO transaction, one-time transaction, or commissioning transaction."

Initiator vs Target Cluster

"An initiator cluster is an application cluster that initiates cluster transactions."

"A target cluster is an application cluster that receives the initiated messages from an initiator cluster and could potentially respond to the initiator."

Network Steering

Defined by EZ-Mode:
"For a node that is not already joined to a network, EZ-Mode network steering is the action of searching for and joining an open network. For a node that has joined a network, EZ-Mode network steering is the action of opening the network to allow new nodes to join."

On This Page

In This Chapter

Related Content

Filter by label

There are no items with the selected labels at this time.


All nodes shall support network steering (EZ-Mode). 

Commissioning Director: a node in a network that is able to directly edit bindings and reporting configurations on any node in the network. 


Centralized vs Distributed Security

A coordinator shall form a centralized security network. Non-coordinators cannot form a centralized security network.

A router may form a distributed security network if it cannot find an existing centralized or distributed security network to join.

All non-coordinator nodes shall be able to join a network that uses either centralized or distributed security.

A joining node can determine whether it just joined a centralized or distributed security network by examining which link key is used to encrypt the Transport Key message.

Joining a Distributed Security Network

All nodes that want join to a network where distributed trust center mode is in use will have to have support for that mode.

Normally when a joining device completes MAC association successfully it will wait to receive an APS transport key message containing the network key and EUI64 of the trust center.  In the case of distributed trust center mode the joining device will receive an APS transport key directly from its router parent with source address (EUI64) of all F’s.  When that occurs the joining device will record the wildcard value in the apsTrustCenterAddress of its AIB noting that it too is operating in distributed trust center mode, and then start operating on the network. 

It is important to note that a device need only have support for distributed trust center mode.  It does not need prior knowledge that the network it is attempting to join is operating in this mode.  If the APS transport key message contained a valid EUI64 (not all F’s and not all 0’s) then it would record this and begin operating in the normal, centralized trust center mode.  

Link Keys

Each node SHALL contain the following link keys:

  • Default global TC link key (widely known by Zigbee Alliance members)
  • Distributed security global link key
    • Test value (0xd0, 0xd1, 0xd2, ...., 0xdf)
    • Production value is given after a company certifies successfully
  • Install code derived preconfigured link key
    • All nodes in ZB3 shall support install code
  • After joining, must exchange the preconfigured link key with an updated TC link key
    • If SE security, use CBKE
    • If not, use APS Request Key to request a new key from TC
    • If the node supports touchlink commissioning then it will also contain the touchlink preconfigured link key

Binding, Reporting, Groups

The following changes to Binding,Reporting and Groups can be found in the ZigBee PRO 2015 (R21) Specification

  • "A node shall implement a binding table whose number of available entries is greater than or equal to the sum of the cluster instances, ,supported on each device of the node, that are initiators of application transactions."
  • "A node shall have a default report configuration for every implemented attribute that is specified as mandatory and reportable."
  • "A node that can be a target of an application transaction shall support group addressing and at least 8 memberships in the group table."

Sleepy Poll Recommendation

There are two polling rates: fast rate and slow rate

  • Fast rate: once every 3 seconds if actively waiting for a response like APS Ack, or a ZCL response. Otherwise, to retrieve an expected message, it should poll at least once per 7.5 seconds.
  • Slow rate: up to the application (e.g. once every hour), to ensure it is still connected to the parent while not actively waiting for a message.

    During commissioning, devices should poll at fast rate

Trust Center Policies

A set of policies that a Trust Center can configure for the network

  • Whether to Use Install Code.
    • All non-coordinator nodes in Zigbee 3.0 have install codes.
    • In a centralized security network, it's up to the Trust Center to decide whether to use the install code.
  • Whether to Require Key Exchange.
    • If required, a joining node must exchange its link key after joining, otherwise, coordinator will remove the joining node from the network.
    • All Zigbee 3.0 joining nodes are required to go through the link key exchange procedure. So it seems like the purpose of this policy is to allow a Trust Center to support legacy nodes that don't support key exchange.

Legal Notices

Copyright © 2020 MMB Networks, Inc. All rights reserved.
Confidential materials prepared and delivered by MMB Networks for receipt and review only by any partner subject to a valid and enforceable MMB Networks confidentiality agreement. Any receipt, review, or misuse of any of the content exchanged hereunder by any party not a party to this confidential exchange shall be subject to any and all rights available under the law. All rights, title and interest to the materials shall remain with MMB Networks.
Any suggestions provided to MMB Networks with respect to MMB Networks' products or services shall be collectively deemed “Feedback.” You, on behalf of yourself, or if you are providing Feedback on behalf of your employer or another entity, represent and warrant that you have full legal authority to bind such entity to these terms, agree to grant and hereby grant to MMB Networks a nonexclusive, perpetual, irrevocable, royalty free, worldwide license to use and otherwise exploit such Feedback within any MMB Networks products and services.