Editor's note: This post was originally published in October 2015 and has been completely revamped to ensure accuracy and up-to-dateness of the presented information.

 

Being one of the leading contenders in the race for dominance among building automation connectivity standards, ZigBee has to be on the radar of every company gearing up for entering the IoT market. Let’s see what it has to offer.
 

ZigBee Protocol
 

ZigBee is one of the most widely deployed wireless communication technologies in today’s smart homes. Both of these standards have an equally long history. The development of ZigBee started in the late 90s, but it wasn’t until 2004 that its first specification was published by the ZigBee Alliance. Since then, ZigBee and Z-Wave have been competing with each other, trying to attract early adopters of smart building automation solutions. Both are low-power, low-bandwidth wireless protocols optimized for remote monitoring and control. Both use mesh network topology and target similar applications, although for a number of reasons Z-Wave has failed to reach beyond the residential market, while ZigBee did have a fair amount of success also in commercial and industrial environments. Both technologies might seem almost identical in terms of functionality, but there are certain important differences between them. As usually, the OSI model is where it all begins.
 

ZigBee’s protocol stack
 

OSI Built on top of the IEEE’s physical radio specification 802.15.4, ZigBee’s protocol stack defines the network, transport and application layers of the OSI model. The IEEE’s 802.15.4 standard is supported by multiple silicon vendors, including the biggest brands in the industry, which creates a healthy competition environment that naturally benefits their clients. In the case of Z-Wave, the market is nowhere near as competitive, since the lion’s share of these modules are supplied by a single chipmaker. Although Sigma Designs finally decided, following its multi-year monopoly, to grant a license to manufacture Z-Wave chips to another company (Mitsumi), such a drastically low number of technology vendors remains a serious risk for manufacturers. It is also the major reason why Z-Wave is still widely considered a proprietary solution. This is not the case with ZigBee, though, as the technology meets all the most important requirements to be called an open global standard.
 

Within the network/transport layer of the simplified OSI model shown above, ZigBee specifies data routing and forwarding rules that constitute the foundation of its mesh network architecture. While the protocol does support other topologies, it is the mesh networking capability that was the key to ZigBee’s market success. Contrary to Z-Wave, which employs a source-based routing scheme, ZigBee uses destination-based routing to deliver packets to individual nodes of the network. This solves some of the problems that Z-Wave keeps struggling with, making a ZigBee network way more robust, resilient and flexible. Mobile controllers frequently changing their location, burnt-out smart bulbs, or any other devices that suddenly go down for whatever reason are not a problem for ZigBee, as its self-healing network can quickly reroute data packets to ensure they reach destination should any of the nodes fail.

Another important feature of a ZigBee network is its impressive scalability. Capable of supporting up to 65,000 nodes, it can provide enormous coverage despite relatively low range of individual modules (10-20m indoors). This number dwarfs the 232-node limit that applies to Z-Wave networks, although it should be treated with a certain amount of skepticism. Implementations featuring a four-digit number of nodes have been reported to face significant problems with maintaining smooth network operation. Latency issues tend to occur even in the case of much smaller deployments, which is not that surprising considering the fact that ZigBee’s maximum data rate is 250 kbit/s. Yes, that’s significantly faster than what Z-Wave offers, and it might seem more than enough for transmitting simple commands or state-change signals typical for smart building automation. But with a huge number of data packets traveling back and forth over a larger mesh network, the entire system might eventually become clogged, especially considering ZigBee’s relatively low spectral efficiency. Things get even worse when there is a strong interference produced by other radios. Being a single-channel solution, ZigBee is not always able to effectively combat interference that is common in the crowded 2.4GHz band shared by the protocol with such ubiquitous technologies as Wi-Fi or Bluetooth.

That said, ZigBee’s data rate still looks absolutely reasonable in the vast majority of building automation applications, at least the ones we can think of today. The future is a different story, though. Analysts predict there will be a myriad of smart devices all around us within a couple of years, and that an enormous scale of connected environments is something that smart manufacturers should start preparing for today. Even in the resource-scarce IoT space, data rates higher than 250 kbit/s are possible and eventually will be needed. Bluetooth, for example, is already capable of providing a rate of 2 Mbit/s while being even more energy-efficient than ZigBee, so significantly faster solutions are available even for those manufacturers who want to have their simple smart devices running on coin cells or not requiring any power supply due to energy-harvesting capabilities.

At some point, ZigBee’s throughput limit might become a serious barrier for further development of its ecosystem. The IEEE’s 802.15.4 standard, which defines the physical layer of the ZigBee protocol stack, restricts the data rate to 250 kbit/s, and only the IEEE can introduce any adjustments in this regard. Should higher data rates become a necessity, the ZigBee Alliance will have to enter into lengthy negotiations with the Institute of Electrical and Electronics Engineers. The outcome of these talks cannot be predicted, as the IEEE has its own interests and goals. This is where the bodies overseeing protocols like Bluetooth or Z-Wave are in a much more comfortable position. Both of these communication technologies define every single layer of the OSI model, and thus all decisions regarding any aspect of communication are in the hands of a single organization.

Wireless protocols

In addition to mesh networking, ZigBee also supports multicasting, which means that messages can be distributed to a specified group of network nodes in a single transmission. However, the technology has been optimized primarily for unicast communications, and there are some important limitations as to how it manages multicasting. To prevent latency issues, a maximum of 9 multicast messages can be broadcast over a 9-second period. There are applications where this is clearly insufficient, and smart lighting is a perfect example. Smooth dimming is one of the must-have features for manufacturers of lighting controls. Whenever a smart dimmer is being used, it keeps sending relevant commands to a certain group of lamps so that they can instantly respond by adjusting their brightness to its current position. From the network operation perspective, this is nothing but constant multicasting where just a slight dimmer movement requires multiple multicast transmissions. Zig-Bee’s limit of 9 multicast messages per a 9-second period can therefore be reached very quickly, making the dimmer completely useless for the next couple of seconds. Explaining to customers why they can’t dim their lights the way they always used to might be quite a challenge for the manufacturers of ZigBee-powered lighting controls. In terms of security, ZigBee provides a wide range of advanced measures to ensure that the data exchanged between smart devices is protected well enough. With a 128-bit AES algorithm used for data encryption and authentication, and three types of keys used to manage security, end users should have not much to worry about. However, every now and then we can hear some disturbing news about security issues found in ZigBee-enabled devices. This is what happened in mid-2015 when Cognosec demonstrated at the Black Hat USA conference how certain vulnerabilities in ZigBee products can be exploited. They related mainly to unsecure initial pairing key transport used when a new device joins the network.

In the statement issued by the ZigBee Alliance, the organization admits that the hack described by Cognosec is an old one that exists for any system using an open key exchange when joining the network, adding that it affects many different technologies, not just ZigBee-based devices. One might wonder why this vulnerability still exists if it has been known for a long time, and this is how the ZigBee Alliance explains it: Security has to fit the application, and schemes are dictated by the resources at hand. It is very hard to enter a 16-digit passphrase into a light bulb when there is no keyboard or monitor. If a scheme is too expensive, too difficult to install, or too time-consuming – consumers won’t apply it. We wouldn’t dare to argue with that. We’ve already mentioned that balancing security and ease of use is a common challenge in the technology industry, and that the process of adding new smart devices to an existing network is something that almost all of the leading wireless connectivity solutions struggle with. Bluetooth is in a particularly comfortable situation here, and soon we’ll explain why.

The majority of security problems with ZigBee networks have nothing to do with the protocol itself. Despite being able to exploit certain vulnerabilities, even Cognosec admits in its report that the features provided by the ZigBee standard can be considered as very strong and robust. The problem is that manufacturers are not obliged to implement all of them in their products. The ZigBee Alliance does not require device makers to adopt the entire specification. Instead, they are given the freedom to choose those mechanisms that are needed for their applications. As a result, they often implement only a minimum set of security features required to pass the certification procedure, and such poor implementations is where vulnerabilities usually can be found.

All in all, despite these few shortcomings mentioned above, we must admit we do like how ZigBee handles network communication. With its reliable mesh architecture, it certainly is a powerful and mature technology, one that can support certain professional applications - although its limited scalability eliminates more complex deployments. Still, we would totally agree with its market slogan, Wireless control that simply works, if not for one little detail – way too often, ZigBee devices do NOT work with each other. How is that possible?

If you look at our simplified OSI model again, you’ll notice a question mark in the upper right corner of ZigBee’s protocol stack. This is because of some serious confusion that is happening at the application layer of this particular communication technology. In order to make it easier for manufacturers to implement ZigBee into their products, and to lay the foundation for cross-vendor interoperability, the ZigBee Alliance has established a number of standardized application profiles, such as the Home Automation profile or the Light Link profile. Each of them precisely specifies the pattern of communication between smart devices representing a particular category of products. The Alliance’s certification program verifies whether a given product is fully compliant with the relevant profile, ensuring that devices sharing the same profile can talk to each other even if they were manufactured by different vendors. At first glance, this seems like a reasonable idea. But similarly as in the case of certain security mechanisms, device makers were given the freedom to choose whether or not to adopt these pre-developed profiles. And for various reasons, many of them exercised this freedom by building their own proprietary solutions. This is where the ZigBee ecosystem turned into the Wild West of connectivity, with a bunch of application profiles that are not compatible with each other, and a sea of products that are not compatible with almost anything else.

So if you pick two random ZigBee devices off the shelf, chances are they won’t be able to talk to each other. One of them might be employing the certified Light Link profile, and the other one could be using the Home Automation profile. Or one of them could be a proprietary solution capable of communicating only with other devices under the same brand. Interoperability was Z-Wave’s major strength, but this is clearly where ZigBee’s biggest weakness lies. As much as we like ZigBee’s network architecture, the ZigBee Alliance completely failed to address the problem of technological fragmentation. With interoperability being the single most important challenge faced today by the IoT, how is a protocol that can’t ensure interoperability within its own ecosystem supposed to make every thing connected in our homes and offices?

Aware of how significant the problem of interoperability is for the ZigBee ecosystem, in late 2015 the ZigBee Alliance announced ratification of ZigBee 3.0, which builds on and unifies the application profiles that had previously been developed, such as Light Link or Home Automation. This was followed by the introduction, in January 2017, of Dotdot. It is a rebrand and expansion of the Zigbee Cluster Library which was previously the foundation of ZigBee’s application layer. Dotdot is a transport layer agnostic solution so it can potentially be used with different types of radio technologies. The ZigBee Alliance has some ambitious plans regarding Dotdot, calling it the universal language for the IoT. For now it seems more like a universal language for ZigBee devices, which is already quite an achievement considering all interoperability problems ZigBee has been facing throughout its lifetime. With multiple ZigBee-based proprietary solutions already in the market, standardization of the protocol’s application layer won’t produce instant benefits for confused consumers, but in a long run this should improve the overall interoperability within the ZigBee ecosystem.

The decision to launch Dotdot as a separate brand might have other interesting consequences. If it proves successful as an application layer solution, Dotdot could potentially outlive the ZigBee protocol itself. We’ll return to this at the end of the next chapter, after we get familiar with another wireless technology that has recently been navigating towards Dotdot. As for the ZigBee & Dotdot setup, with the former technology being responsible for data transfer issues and the latter handling tasks within the application layer, it seems a step forward from where ZigBee previously was. However, this duo still remains a solution that is based on the 802.15.4 physical infrastructure with its single-channel transmission, hub-dependent topology and not-so-impressive data rate. If you ask us, we believe this is simply not enough for ambitious IoT applications of the future.