Why ZigBee has failed in IoT interoperability

A few days ago Stacey Higginbotham published on Gigaom the announcement of ZigBee Remote Control 2.0, a standard for smart home remote control technology. The post discusses on why ZigBee has failed along the way to become the preferred standard for the smart home. As correctly mentioned in the post, the major failure of ZigBee is due to the lack of interoperability, the main reason being that ZigBee has always “messed with software profiles built on top of the radio”. Stacey says that “if manufacturers of products decide they want devices to interoperate, they use the same radios and software profiles, but in ZigBee’s case what happened was that other companies didn’t actually want their devices to interoperate because it might prevent customer lock-in, so they used different software profiles.”

In my opinion, vertical domain specific profiles are in principle a good idea and are not the main cause of ZigBee’s lack of interoperability.  It is true that device manufacturers do not have advantage in complying with software profiles because they would loose the lock-in advantages, but this is not the only cause. The lack of interoperability in ZigBee is due to two main reasons: the lack of an open protocol stack  and the lack of a proper certification program.

Lack of an open protocol stack

The original version of ZigBee was based on the IEEE 802.15.4 radio link layer and on a proprietary protocol stack, consisting of network, transport and application layer.  On top of the stack there was a set of domain specific profiles, each providing standard interfaces and device definitions for product interoperability in a vertical application domain, such as home automation, building automation and telecom services. In particular, the application profile related to energy services, called Smart Energy Profile (SEP), gained momentum especially in the US market. When the US smart grid market identified the need for interoperability, the ZigBee Alliance had to significantly re-design the ZigBee stack and the SEP. The network/routing layer of the new ZigBee IP stack is now based on 6LowPAN and RPL, two IETF standard for IPv6 low power networking in constrained networks, while the transport layer is based on on the widely known TCP or UDP. AS for the SEP, its 2.0 version is based on the REST architecture and requires the use of HTTP for interoperability.

With the major re-design of the stack, the ZigBee Alliance has basically admitted that defining a standard around a proprietary technology has been a failure and that open standards are necessary for interoperability, for delivering long term value and especially for avoiding vendor lock-in. However, I wonder whether it makes sense that ZigBee still exists as a standard. The new ZigBee is nothing else than a stack made of open standards with a piece of software on top (the vertical profiles). This is actually what Thread, the new standard recently announced by Nest, ARM and Samsung, is going to do. Thread is going to be based on a stack of open standards, such as 6LoWPAN and the IEEE 802.15.4 with a piece of software built on top. I wonder if it makes sense to call this approach an “IoT standard”.

The fact that major IoT players wants to define a standard based on 6LowPAN, acknowledges the importance of IP (and Web) technologies for IoT interoperability purpose. However, building pieces of software on top of open standards might anyway hinder interoperability and might not solve the vendor lock-in problem. The Internet has succeeded and is so interoperable thanks to the use of Web technologies (REST/HTTP), without any piece of magic software built on top of them. Isn’t it probably better that we follow the same path for the evolution of the IoT? Using embedded (open and standard) Web technologies such as IETF CoAP might be a better solution than adding pieces of magic software on top of open standards.

Lack of a proper certification program

ZigBee has different certification programs, one for platform compliant products and one for certified products. The former tests the compliance only up to the application layer, which excludes the software profiles. The latter certifies products up to the application profiles and provides testing for (proprietary and non-interoperable) private profiles and (interoperable) public profiles. This shows that probably ZigBee has not really messed with software profiles but it has failed in setting up a proper certification program, leaving too much freedom to device vendors. In addition, ZigBee has never tried to control the confusion done between ZigBee and IEEE 802.15.4. Lots of systems on chip or radio controllers based on the IEEE 802.15.4 have been confused with ZigBee, or have been called something like “ZigBee ready”. IEEE 802.15.4 is only the radio link layer of the ZigBee protocol stack and not the entire standard, which also included proprietary layers (in its first version) and the software profiles. Probably the fact that many IEEE 802.15.4 based products have been called “ZigBee products” has been considered an advantage for the alliance, giving the impression that the IoT world was taking the ZigBee direction (and I think that’s the reason why ZigBee has become so popular). But in the long term it created much confusion and it ended up emphasizing the interoperability problem.

I’m curious to see whether the Thread group (and the IoT world in general) is going to repeat the same mistake. Thread is going to be based on open standards such as 6LoWPAN and the IEEE 802.15.4 radio link layer. But the Thread group will have to make sure to make a hard distinction between a thread compliant product and a product which will use 6LoWPAN and IEEE 802.15.4 but which will not have the Thread piece of software built on top. There will probably be many solutions like these because open standards will evolve and will be adopted independently from Thread (and from other alliances who take open standards and personalize them). If the IoT world (especially the part without computer networking knowledge) will start confusing 6LowPAN with Thread, then the Thread group will have made the same mistake as the ZigBee Alliance.






Leave a Reply

Your email address will not be published. Required fields are marked *