In the previous episode of our series, it turned out that riding the Z-Wave might not get you too far if you are a customer or manufacturer looking for a totally predictable wireless communication technology that can be relied upon 24/7. Such a ride can be fun, for sure, but sometimes you just need a rock-solid solution for your applications. The initial excitement that usually accompanies early building automation experiences eventually fades, and what matters in the end is reliability and a flawless UX. Today we’ll take a look at a machine-to-machine wireless communication protocol that comes pretty close to delivering just that. 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 marketplace. Let’s see what it has to offer.

Along with Z-Wave, ZigBee is one of the most widely deployed wireless communication technologies in today’s smart homes. Both of these standards have equally long history. The works on ZigBee were launched 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 the mesh network topology and target similar applications, although for a number of reasons Z-Wave failed to reach beyond the residential market, while ZigBee did have a fair amount of success also in the 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_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 an 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 enormous scale of connected environments is something that smart manufacturers should start preparing for today. Even in the resource-challenged IoT space, data rates higher than 250 kbit/s are possible and eventually will be needed. Bluetooth Smart, for example, already offers a rate of 1 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 for months or years.

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.

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. ZigBee’s limit of 9 multicast messages per a 9-second period can therefore be hit very quickly, making the dimmer completely useless for the next couple of seconds. Explaining 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 light 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 just a couple of weeks ago 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 during joining to 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. As already mentioned in our previous post, balancing security and ease of use is a common challenge in the technology industry, and 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 in one of the next episodes 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. It certainly is a powerful and mature technology, a one that can be called professional and is suitable for professional applications. And we would totally agree with its market slogan, “Wireless control that simply works”, if not for one little detail – ZigBee devices way too often 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 certification program run by the Alliance 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 between 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 a protocol that can’t ensure interoperability within its own ecosystem is supposed to make every thing connected in our homes and offices?