A Battle of IoT Protocols: ZigBee vs Thread

Two prevalent Internet of Things protocols, ZigBee and Thread, seem to be battling for market share in the low-power, consumer, wireless sensor, and control networks space. Are they actually competing or are they trying to cooperate?

The Internet of Things is still relatively new and there are still many communications protocols competing to be the dominant players in various aspects of the Internet of Things. Two protocols which are useful in low power, consumer-oriented, wireless sensor and control applications are ZigBee and Thread. The two protocols appear to be competing for dominance, but new developments indicate they are cooperating, as well.

Communication Protocol Battles

Often when more than one communication protocol is available to fill a specific purpose, those protocols will battle it out until one becomes the dominant, if not the only, protocol used for that purpose.
Two prominent historical examples of this are Ethernet for local area networks (LANs) and 802.11 for wireless LANs (WLANs). One ongoing communication protocol competition is the battle for the short range, low power protocol space that is used by so many Internet of Things devices and two key competitors for this space are ZigBee and Thread.

ZigBee and Thread Overview

Zigbee is a fully developed protocol stack that is defined for all protocol layers from the physical layer all the way up to the application layer as can be seen in Figure 1. The physical layer and link layer use the technical standard IEEE 802.15.4, while the network, transport, and application layers are defined by the ZigBee Alliance.
It should be noted that there are a few different ZigBee defined protocols at these layers. The ZigBee Alliance has some big companies behind it including Philips, Texas Instruments, NXP, and Huawei.

Figure 1. ZigBee protocol stack

Thread is defined for all but the application layer and all of the layers are pre-existing protocols. Thread is a definition of how the layers are combined together as can be seen in Figure 2. At the physical and link layer, IEEE 802.15.4 protocol is used just like with ZigBee. At the network and transport layers, Thread uses a combination of IPv6, 6LowPAN (IPv6 over Low power Wireless Personal Area Networks), UDP (user Datagram Protocol), and DTLS (Datagram Transport Layer Security). Thread also has some big companies behind it, the most notable of which is Google (via Nest).

Figure 2. Thread protocol stack

Thread has an advantage in that it has already made itself a part of the IP world by using IPv6 (although ZigBee does have an IP version of their networking protocol). On the other hand, ZigBee is already widely adopted and includes definition of the full protocol stack which includes a mature application layer called the ZigBee Cluster Library (although it has now changed that name to dotdot).

Relationship Between ZigBee and Thread

ZigBee and Thread both occupy the same short range, low power communication space and are competing for market share. However, unlike the LAN and WLAN protocol competitions in the past, there is actually some room for cooperation between ZigBee and Thread. The competition for the LAN and WLAN space only involved competition between protocols at the lowest layers of the protocol stack (physical and link layer) and so one or the other of the competing protocols had to be chosen (e.g., Ethernet over token ring). On the other hand, ZigBee and Thread define protocol stacks, and the two even use the same physical and link layer protocol in their stacks—IEEE 802.15.4. Thread also does not have an application layer defined while ZigBee has an application layer defined for many different applications.

The seeds of a cooperation between the two groups were planted in an announcement in early 2015 when the two organizations announced that they would begin work to make the ZigBee Cluster Library compatible with the network and transport layers in Thread. Then, at the end of 2016, the ZigBee Alliance announced that they had reached the major milestone of having several members from both groups develop prototypes that use the ZigBee application layer on top of the Thread network and transport layers. A demonstration of this was on display at CES 2017.



It is interesting to see this development delivered with such enthusiasm from both groups. Thread's enthusiasm to prove that a widely adopted application layer can be used with their protocol stack to create a complete networking protocol is understandable. It's also hard to ignore the huge gains for Thread in the ZigBee/Thread cooperation. Thread gets not only a powerful application layer protocol, but also lots of credibility by partnering with ZigBee.

These are both nice additions to their Internet-ready network and transport layer protocol stack. However, for ZigBee, it seems to mean conceding that the competing network/transport layer of Thread is a legitimate replacement for ZigBee. Of course, ZigBee's position on this is that they have an application layer protocol that will allow applications to interconnect across any IoT network (not just Thread).

It will be interesting to see how this cooperation/competition develops. Will the IP-centric Thread protocol come to dominate the network and transport layers because of its integration with IPv6 leaving ZigBee to focus on the application layer? Will ZigBee's current strong position allow them to maintain a strong presence in the network and application layer while at the same time moving to own the application layer of the IoT? Will another organization such as the Open Connectivity Foundation (OCF) carve out their own share of this growing market?


It is too soon to answer these questions, and while observers sit on the side and make predictions about the future, designers such as Qorvo are being forced to hedge their bets by designing both protocols into their devices.