SWAY034 April 2021 CC1312R7 , CC1352P , CC1352P7 , CC1352R , CC1354P10 , CC1354R10 , CC2642R , CC2642R-Q1 , CC2652P , CC2652P7 , CC2652PSIP , CC2652R , CC2652R7 , CC2652RB , CC2652RSIP
While Zigbee and Thread both look similar, there are slight differences in how each protocol establishes and maintains the network.
Zigbee supports a centralized and distributed (touchlink) coordination scheme. In the centralized approach, Zigbee uses a statically allocated coordinator within the network to manage operations. In contrast, a leader device, elected from one of the network’s routers, handles networkwide decisions in the Thread network.
Devices statically configured as routers handle the forwarding and routing of messages within a Zigbee network. Thread elects devices that route within its network from an existing pool of router-eligible devices.
Zigbee offers many ways to add new devices onto the network. Thread adds new devices with a standardized commissioning protocol, which requires human intervention to complete.
Zigbee enables defined and administrated networks, which tends to entice corporate entities and homeowner hobbyists. Thread enables a self-forming and self-healing mesh network geared toward an autonomously administered ecosystem of devices.
The differences become more pronounced as you move up the networking stack. Zigbee defines an application framework for device-to-device communication. Application interactions between devices are defined and certified with the Zigbee cluster library. Thread offers its application layer protocols as an option to be reused by the business logic of the end product, but does not mandate their usage. This could be the User Datagram Protocol for efficient transmission of messages and the Constrained Application Protocol for reliable interactions. However, a Thread application may use Transmission Control Protocol, Hypertext Transfer Protocol, Message Queuing Telemetry Transport or any other protocol to transport messages.
Zigbee offers both reliable network operation and application interactions. Thread only ensures reliable network operation, but offers the ability to define the application protocol best suited for the device requirements.
Interoperability does not end at the boundaries of the mesh. Thread offers native IP routing and a natural device-to-cloud connection. Zigbee requires a specialized hub and translation to interoperate with cloud services.
More than 100 million products have included the Zigbee Pro networking layer, alongside the Zigbee cluster library, with several revisions of the standards for both the core mesh networking functionality and application layers. The Thread protocol is a relatively newer offering and does not have the same market penetration. Since both technologies use the same radio MAC/PHY protocol, it is easy to pivot between both with the SimpleLink wireless MCU.
Table 9-1 lists the differences between the two core mesh networking standards and the implications for technology adopters.
Functionality | Zigbee | Thread |
---|---|---|
Authentication at joining | Centralized through the trust center with optional out-of-band device-based installation code, or distributed with proximity pairing | Smartphone-based, with device-specific quick response (QR) code scanning |
Security |
Advanced Encryption Standard (AES)-128 network-level, with a key transported from joiner to joining device Optional application-level key |
AES-128 MAC level derived from an elliptic curve cryptography-based password juggling scheme and DTLS session establishment |
Device bootstrapping and commissioning | Button-press easy mode or proximity-based (touchlink) | Smartphone-based, with device-specific QR code scanning |
Network and mesh management | Centralized coordinator; may be distributed in touchlink network | Dynamic leadership |
Self-healing | Native router and mesh self-healing | Routers and leader self-election and self-healing |
Cloud integration | Zigbee gateway with a purpose built translation | Thread border router with native IPv6 |
Power performance for application packets | Optimum | Very good |
Latency performance for application packets | Best | Very good |
IP native integration | No | Yes |
Standard longevity | First revision in 2005 | First revision in 2015 |
Industry participation | Approximately 400 member companies | Approximately 270 member companies |