Wireless communication protocols reviewed by us so far have been around for quite a while. All of them were introduced to the market when expectations and hype surrounding the IoT and connected spaces were nowhere near as big as they are today. What’s more, certain product categories did not even exist back in the days when ZigBee, Z-Wave or Wi-Fi were designed and developed, with smart lighting being a perfect example of a segment that has come a long way from non-existence to being one of the hottest smart building automation solutions over just a couple of years. While we still cannot be sure what a smart home or smart office will look like 10 years from now, at this point we at least have a rough idea of what to expect – and we do expect a lot.

As shown in the previous episodes of the “Wireless protocols showdown”, each of those more mature m2m communication technologies has its weaknesses. This is hardly surprising if you consider the above. But quite obviously, the wireless connectivity landscape is not some sort of a dinosaur reserve. There are juvenile predators out there, and one of them has recently attracted particularly strong attention. Let us introduce you to Thread, a newcomer to the communication standards war.

The Thread Group was launched in July 2014 with a goal of creating “a simple, secure and low-power network for the home and its connected products”. Exactly one year later, technical specifications and documentation were made available to members of the organization to let them start building connected products based on Thread. From the very beginning, the protocol has been positioned as a connectivity solution designed strictly for the home automation segment. This might seem like a less ambitious approach than the one taken by e.g. the ZigBee Alliance, but it certainly makes sense. Narrowing the target market should allow the Thread Group to provide a standard that is perfectly engineered to address the needs of a very specific group of customers. And reaching these customers should not be an overwhelming task considering that the organization is backed by some of the most recognized technology firms in the world, including a bunch of the leading chip manufacturers.

On the downside, arriving to the IoT party much later than several heavyweight competitors obviously has very specific implications. Technologies like ZigBee or Z-Wave had more than a decade to establish market presence and build certain level of customer awareness. As a result, both can be found in more than 1,000 certified devices, enabling wireless connectivity for millions of products that are already in circulation. With its 1.0 specification debuting just weeks ago, there are no Thread-compliant products on the market just yet. The product certification program was supposed to start in September, and the first devices were to show up on store shelves late this year. There were no reports about how these plans are progressing until yesterday (11/11), when the Thread Group announced launching the certification program with a moderate number of approximately 30 products submitted for the first round of certification testing. The slight delay doesn’t surprise us at all, as this is what happens with similar initiatives more often than not – which really shows just how complicated and challenging this entire connected environment is. But it does mean that the first batch of Thread devices is unlikely to hit the stores this year. Time is money, though, and time is also market share with competing standards planning to introduce some *big* improvements over the coming months (Bluetooth Mesh, ZigBee 3.0, Wi-Fi 802.11ah, just to name some of them), so the Thread Group really needs to act quickly to make sure that Thread’s already late arrival is not delayed much further.

That said, with the smart home market still at the beginning of the technology adoption curve, it seems that there still might be enough space and time for a new technology to succeed – as long as it is able to effectively address the industry’s major challenges. Is Thread that kind of contender? Let’s begin with a simplified OSI model:

THREADonOSI

Let us quickly explain what is going on in here. Thread runs on top of the well-known radio standard IEEE 802.15.4, the same that forms the basis of every ZigBee network. The protocol itself defines only the network and transport layers of the OSI model, addressing such issues as routing, commissioning or security. It does not cover the application layer, as it was designed to work with a variety of different application layer protocols. Now what does this all mean in practice? Let’s break it down, starting from the bottom of the OSI model.

Being based on the 802.15.4 physical infrastructure, Thread adopts all its strengths and weaknesses that we’ve mentioned when reviewing the ZigBee standard. The former include reliable radio performance, reasonable range and support for low-power applications. As for the weaknesses, the 802.15.4 is a single-channel solution with a maximum data rate of 250 kbit/s. It is therefore not surprising that a Thread network becomes saturated when it reaches approximately 200 nodes. This has to be a bit disappointing considering that Thread made its market debut almost a year after Gartner predicted that a typical family home could accommodate more than 500 smart devices just a couple of years from now. Whether or not Gartner’s forecast will turn out accurate, 200 nodes is really unimpressive. Thread has the ambition of becoming the go-to technology for connecting and controlling a smart home with all its appliances and systems, including such applications as lighting, energy management, security, climate control, etc. If you try to count all of the nodes of such a network, you’ll quickly realize that Gartner’s predictions are not as exaggerated as they might seem at first glance. So the question remains how Thread is going to handle those extensive sensor-driven implementations. And again, we need to mention that just like the ZigBee Alliance, the Thread Group does not have any direct control over the 802.15.4 which is maintained solely by the IEEE. As for the consequences of such an arrangement, please refer to our blogpost on ZigBee.

At the same time, it should be noted that Thread’s reliance on the 802.15.4 standard is not as strong as in the case of ZigBee. Therefore, it doesn’t seem impossible to have its networking mechanisms implemented on top of a different type of radio. In certain scenarios, this could enable the Thread Group to overcome some of the current limitations of the IEEE’s 802.15.4 technology.

On top of the 802.15.4, Thread delivers a self-healing, secure, IP-based mesh networking solution that allows end users to easily bridge their devices to the Internet so that they can access a variety of cloud services. The IPv6 connectivity is enabled by 6LoWPAN, a technology for sending and receiving IPv6 packets over the 802.15.4 radio, and is one of the major advantages that Thread has over ZigBee. Thread introduces important improvements also with regard to the onboarding process, i.e. the act of adding a new device to the network. We’ve already emphasized multiple times how challenging this issue is, and how various technologies struggle with it (remember Wi-Fi switches with microUSB ports solely for configuration purposes or security holes in initial pairing key transport that were found in ZigBee implementations?). Thread standardizes this process by enforcing manufacturers to attach numeric code labels onto their products that are later used by end users during onboarding. We see this as an important move towards making the initial pairing procedure more secure and reliable, and a significant improvement over how ZigBee handles this issue.

Moving to the top of the OSI model, we finally get to the application layer. As an application layer agnostic technology, Thread leaves this space completely empty. Support for different application layers has been promised by the Thread Group, so we can expect gradual integration with certain existing solutions. The first such integration is already under development following the announcement according to which Thread will embrace the application profiles defined for ZigBee, known as ZigBee Cluster Library. This leaves us a bit confused about how Thread plans to address the problem of interoperability. Even if it adds support for multiple application frameworks, they still won’t be able to interoperate between each other, and the fact that Thread is an IP-based standard does not help much, either. By itself, IP connectivity enables seamless communication only when there is a human being on both sides of the process, selecting the right tools for specific needs. Devices cannot do this and thus they cannot talk to each other unless they are given very specific instructions on how to carry out that communication, which is what the application layer is needed for.

There is one more important thing that needs to be mentioned with regard to the topmost layer of the OSI model. Communication protocols that define the application layer also define the rules for cooperation between different companies using a particular technology. This means that a manufacturer of e.g. Bluetooth light switches does not need to enter into any kind of agreement with a manufacturer of Bluetooth bulbs in order to launch a product that controls these bulbs. By deciding to employ Bluetooth or Z-Wave, each producer automatically agrees to become part of a broad ecosystem where devices from different vendors can interoperate without any legal restrictions. Thread does not define the application layer and the rules for communication between devices, and so the legal framework for potential cross-vendor interoperability is also missing. This is a strictly business problem, and manufacturers of certain types of devices need to figure out by themselves how to deal with it.

With Thread being such an immature technology, it’s really hard to guess at this point what its future is going to look like. At first, it seemed like a natural successor of the ZigBee standard, building upon the solid foundation of the proven 802.15.4 technology, while introducing certain important improvements in such critical areas like security or commissioning. Things got even more interesting when the Thread Group announced that 802.15.4 devices already in circulation would be able to start running Thread via a simple software upgrade, which means that a part of ZigBee’s enormous installed base could theoretically switch to Thread. And while we’ve heard from chip vendors that the Thread stack is pretty heavy, and thus only the latest generation of 802.15.4 modules will be able to go through such transformation, Thread’s capability of snatching some of the ZigBee deployments does sound like a real challenge for the ZigBee ecosystem. On the other hand, as already mentioned, earlier this year the ZigBee Alliance and the Thread Group announced launching a friendly cooperation to enable the ZigBee Cluster Library to run over Thread networks, so it will be interesting to see how these two technologies compete over the much needed market share.

It seems there are multiple scenarios that could possibly unfold for Thread over the coming months, potentially determining its future position in the smart home market. We do appreciate the enhancements it introduced to make the 802.15.4 a more viable choice for manufacturers and customers alike, but at the same time we are a bit disappointed with certain limitations that apply to Thread due to its reliance on this radio technology. And we certainly are a bit concerned about interoperability issues, as Thread doesn’t bring much to the table to solve them. The market will just have to wait and see how things continue to evolve, particularly with regard to Thread’s certification program, application layer policy, and its complicated relations with the ZigBee technology. We’ll keep you updated on any important developments, while in the meantime continuing our review of wireless connectivity solutions for the IoT. Stay tuned.