When Thread, the low power communication protocol for the smart home led by Nest, was announced last year, there was a general feeling that it would accelerate the end of ZigBee. A few days ago the Thread group and the ZigBee alliance announced a collaboration for running the ZigBee Cluster Library over Thread networks. The announcement says that “by working together, ZigBee and Thread can jointly provide an interoperable solution to help streamline product development and ultimately improve the consumer’s experience in the connected home”.
It may seem that this is a strategic move for ZigBee to stay alive, while somebody might wonder why Thread has decided to “save” ZigBee from its inevitable exit from the smart home marketplace. My personal conclusions are that ZigBee has officially shut down any further development on its stack and that from now on will only concentrate on the application layer. And the collaboration also shows that this was a strategy designed even before the creation of the Thread group. Let’s see why.
The original and most deployed version of ZigBee was based on the IEEE 802.15.4 radio link layer and on a proprietary network and transport protocol stack. On the application layer ZigBee has a set of domain specific profiles, each providing standard interfaces and device definitions for product interoperability in vertical application domains. The development of the profiles is facilitated by a set of commands called ZigBee Cluster Library. I find the idea of the vertical profiles quite interesting and powerful. However, ZigBee has clearly failed in IoT interoperability. The main reason being the lack of an open protocol stack and of a proper certification program. The problem of interoperability forced the ZigBee Alliance to re-think the protocol stack and to re-design it based on open standards. They came up with the new ZigBee IP stack, based on 6LowPAN, an IETF standard for IPv6 low power networking in constrained networks. The work that ZigBee has done in the use of IP technologies, however, has mainly targeted utilities. In fact, the re-design of the stack was mainly driven by the US smart grid market and was indeed originally only thought for the Smart Energy Profile (SEP). It seems that the ZigBee Alliance wasn’t so much interested in doing further development on 6LoWPAN and in porting the ZigBee IP stack also to other application domains.
Thread, instead, is an IPv6-centric protocol since its inception. It relies on the IEEE 802.15.4 radio link layer (same as ZigBee) and on 6LoWPAN as networking technology (same as ZigBee IP). Thread does not address any issue related to the application layer. It is supposed to be application agnostic and to work with several application protocols and platforms out there. The collaboration between ZigBee and Thread basically means that the ZigBee Cluster Library, and consequently the ZigBee application profiles, can work on top of the 6LoWPAN based Thread stack. To me, this looks rather similar to ZigBee IP, which allows ZigBee application profiles running on top of the new ZigBee IP stack based on 6LoWPAN. This shows how the ZigBee alliance was anyway heading towards that direction.
Besides the technical issues of the protocols, we should also consider that the vice presidency of Thread belongs to Silicon Labs, one of the world largest chip manufacturer and provider of ZigBee chips. Two years ago Silicon Labs acquired Ember, another chip manufacturer who was a ZigBee founder and main driver of the ZigBee stack development. Freescale, another ZigBee chip giant is also one of the founding members of Thread. It is clear that it’s not convenient for these companies to invest in the development of two protocol stacks, both based on the same radio and networking standards and both designed for smart home applications. After establishing the agreement with ZigBee, Thread’s strategy becomes much more clear: Zigbee has failed in terms of interoperability and the effort to move to IPv6 technology could not produce the expected results on a short term basis (namely could not quickly revamp ZigBee as they had originally planned). In addition, there is a huge amount of ZigBee chips (based on the ZigBee Pro stack) deployed on the market which would not be compatible with the new ZigBee IP stack and consequently ZigBee cannot be suddenly euthanized, as it was suggested by Nick Hunn when Thread was announced.
The creation of the Thread group would allow to continue the development of a 6LoWPAN based stack started by ZigBee, without doing any work on the application layer because at some point the work done by the ZigBee alliance on the application layer development would be reused. And that’s indeed what the Thread-ZigBee agreement sounds like: first, ZigBee stops any development on it’s ZigBee IP stack (why would they continue this if they can work on the Thread stack); second, the application profiles (which I think are the only interesting building block developed by ZigBee) will continue to exist and would get a good piece of the marketplace if Thread will be successful; third, the ZigBee chip manufacturers can continue (I don’t know for how long though) shipping traditional ZigBee chips to their existing customers.
It sounds an interesting strategy from the ZigBee perspective. Although ZigBee will continue to exist only as application layer, it will stand on the shoulders of giants such as Google, ARM, Samsung and will probably get a big piece of the smart home market. But what does the collaboration mean for Thread? Thread claims to be application agnostic and bets on interoperability at the network layer. However, by allowing the ZigBee Cluster Library to run on top of its stack, Thread becomes an end-to-end solution non-transparent to the application layer. And this might create even more confusion than what there is now in the smart home protocol space, especially from an interoperability perspective. In fact, it is not yet clear how the products will be branded. Will they have the ZigBee or the Thread logo? Or both? Also, once I have a ZigBee over Thread solution deployed in my home, and I buy another Thread enabled device which implements a different application layer, how will it be interoperable with my already deployed solution?
Although the smart home protocol space has become hot and has been shaken by the launch of Thread and by the announcement of the ZigBee-Thread collaboration, the future is still quite unclear. It’s not yet sure whether Thread will work only with ZigBee (I seriously don’t hope so) or it will establish partnerships with other alliances which are standardizing other application layers and platform, such as the AllSeen Alliance and the Open Interconnect Consortium. If such partnerships are established, how complicated and fragmented will the smart home market be? Less fragmented (and less confusing) solutions like Bluetooth, with its recently announced mesh functionality, or Apple’s HomeKit will probably be the ones to benefit from this confusion.