Enthusiasts Guide to Thread
What is Thread?
Thread is a communications protocol created by Nest, and then evolved by Google, designed to provide a secure, scalable, and resilient networks for Internet of Things devices. Thread follows in the footsteps of Z-Wave and Zigbee in this regard, but takes lessons learned from these earlier efforts in the hopes of building a new standard that can resolve ongoing issues of compatibility, security, and reliability between the various automation platforms.
Thread is overseen by a consortium of companies called the Thread Group. Membership of the group is required use the technology and commands an annual license fee. An open-source version of the stack has been released by Google called OpenThread. Devices built using OpenThread, however, are still subject to certification requirements.
History of Thread
Nest created the early form of Thread and built it into their devices from day one. The protocol evolved until Nest Labs was acquired by Google in 2014. Subsequently the Thread group was formed to oversee the development and adoption of the format including a number of semi-conductor and device brands such as Samsung, Qualcomm, ARM, and Yale. Not much more was heard about Thread until Apple joined the Thread group in 2018, bolstering hopes that it may actually see some traction.
This movement began to coalesce with the formation of the Connect Home over IP initiative in 2019, bringing together Google, Amazon, Apple, Zigbee and other major smart home players in an effort to create a new open standard for smart devices.
2011 - Nest creates Thread
2014 - Google acquires Nest Labs
2014 - Thread Group created
2015 - Yale announced as first non-Google Nest adopter
2018 - Apples joins Thread
2019 - Thread 1.2 released
2019 - Lutron joins Thread Group
2019 - Connected Home over IP project announced
2020 - Apple HomeKit begins supporting Thread devices
2020 - Nanoleaf adopts Thread
2020 - Eve Systems adopts Thread
2021 - Thread adopted as core tech in the new IoT Matter standard
2022 - Thread 1.3 release, Matter enabled
How does Thread work?
Thread is designed to provide a resilient, scalable mesh network supporting small devices and requiring very low power consumption. A key difference over other mesh network protocols is that Thread is not based around a master device that ‘owns’ the network. Instead, it allows any full Thread device to become a router, and these routers will automatically elect one of their number to be the ‘leader’. This process is dynamic, and responds to any change in the network such as the current leader being removed or unreachable for some reason.
This dynamic process means that there is no requirement for a ‘hub’ to manage the network, as any Thread device can create and manage additions to the network. Connectivity to other networks, such as a home WiFi network or the internet, still requires a specific device known as a border router. A Thread network can have multiple border routers as required, and these are distinct from the management of the Thread network itself.
Unlike other IoT protocols, Thread does not aim to be all encompassing by dictating the types of actions and messages smart devices must use. Instead Thread is designed as a network protocol which is application layer agnostic. The application layer in a protocol stack is the part that handles how the automation system talks to devices and includes things like device status messages and control commands. For smart home device, the Connected Home over IP project has been formed by major smart home brands to address this as an open standard.
Thread handles the layer below this, including security, network management, routing, mesh formation and device health checks. A key differentiator of Thread is it’s use of IPv6 for addressing, which gives it great flexibility in not only providing multiple addresses per device for different uses, but enabling internet address-ability for distributed applications. This is because Thread is not just smart home focused, but more broadly usable for all automation applications involving small low power devices, such as remote monitoring and industrial process control.
The structure of the network portion of the addressing allows for up to 32 routers, with each having 511 child devices. This gives a total network size of 16384 devices. Thread will promote and demote routers as required, and will aim to keep the number between 16 (for resilience) and 23 (to allow for additions to extend range if needed).
Thread aims to provide ‘interoperability through convergence’. This means that by using a widely adopted standard addressing standard, devices used for any application, on any platform, will be able to communicate over a common medium. To achieve this, it’s important to use a highly scalable and widely deployed means of referring to individual devices and getting traffic between them. The internet has been doing this for decides using IP addressing and routing, and Thread leverages the latest iteration of this technology, IPv6.
Thread’s key benefit is it’s highly dynamic mesh network. Thread devices can self-establish a network on their own, and allow other devices to join it. Any of those devices with full Thread capabilities can become routers on that network, and any one of those can by elected to take charge as required.
This lack of a central network owner provides for much greater resilience than typical meshes which are anchored on the original device that formed the network. Routers will be managed automatically and without any configuration required, and child devices will automatically manage their connection to a suitable router to maintain their connection.
Here Thread has benefited from lessons learned with the real world use of other protocols, and bolstered by Google’s considerable security expertise.
Thread has been designed from the ground up with security in mind. Communications are secured with AES encryption at the network link level, using Data-gram Transport Layer Security (DTLS). There is a robust commissioning process to ensure new devices are authorized to join the network, and built in protection for identifying and blocking rogue devices.
Very Low Power
Thread claims to have even lower power consumption than competing technologies, and supports small battery powered devices that can sleep until needed. This is critical for smart homes where the need for remote sensors like motion, door/window, and switch type devices is very real. These type of devices need only send a message when something happens, so they can be idle most of the time and extend the life of even small batteries for years.
Flexible Application layer
By focusing on the network management side, Thread allows other technologies to provide the application level functionality. This allows for different uses over a single thread network depending on the purpose of specific devices. An example is ZigBee, where the application layer for ZigBee devices can be used on top of a Thread network, leveraging the benefits of both.
The underlying radio protocol Thread is based on is IEEE 802.15.4, which is the same standard used by ZigBee. IP routing is generally not efficient enough to support very low powered devices, so Thread uses the 6LoWPAN (IPv6 Low-power Wireless Personal Area Network) standard to provide a very low power IPv6 implementation. 6LoWPAN is defined under IETF standard RFC 6282.
Like many consumer radio protocols, Thread runs operates in the 2.4GHz band. This band is approved globally for unlicensed use, which ensures easy access to the same frequencies anywhere. While 2.4GHz applications are known for being susceptible to interference, Thread uses spread spectrum technology to help overcome this issue.
Thread specifies a number of device types with different capabilities. Most Thread devices fall under the Full Thread Device class, but in order to support low power devices, a Minimal Thread Device class exists with reduced capabilities.
Within these are a number of sub types:
Full Thread Device (FTD)
Router Eligible End Device (REED)
Full End Device
Minimal Thread Device (MTD)
Minimal End Device
Sleepy End Device
Routers in the network are simply REEDs that have been promoted to Routers by Thread on an as-needed basis. As network conditions change, Routers will be added or removed to maintain the optimal number 16-23 where possible.
Sleepy End devices are those intended for small battery powered operation. These devices will minimize the use of their radio to conserve power and cannot forward message traffic.
Any end device can also act as a Border Router (providing they have the necessary communication hardware). These devices pass traffic between the Thread network and a non-Thread network. Typically at least one of these will be required to facilitate communication and control from outside devices such as console or smart phones. There can be more than one Border Router in the network.
Any REED can form a Thread network if there are none to join. As other devices are added to the network, additional REEDs will be promoted to routers to ensure resilience. One of these routers will be elected to be the Leader. This leader device manages network configuration information for all devices. If the Leader becomes unavailable a new one will be elected by the remaining routers.
Devices that are not routers will establish a link with one router only, based on the best options available to them. If they cannot establish a satisfactory connection to an existing router, a suitable REED will promote itself to a router for that device to connect to, if available.
This flexible self repairing capability means that a Thread network can be broken up in the event that communication between two portions of the network are disrupted. The portion without access to the leader will elect it’s own Leader and continue to function with the same security keys as the original network. These portions are called ‘partitions’. By retaining the same security credentials, the partitions can be reunited at a later point with no ill effects.
When selecting devices to become Routers, there are some rules that are followed to ensure the routers form a Connected Dominating Set (CDS). This ensures the minimum level of redundancy is maintained.
There is a Router-only path between any two Routers.
Any one Router in a Thread network can reach any other Router by staying entirely within the set of Routers.
Every End Device in a Thread network is directly connected to a Router.
It’s easy to assume Thread is a direct competitor to other IoT protocols like Z-Wave and ZigBee, but this is not really accurate. Thread has specifically avoided encroaching on the application layer where the actual automation functions work, and has focused on being the best possible network technology available for connected devices.
In this, it looks to have succeeded. Thread is the only protocol with the ability to completely self manage it’s nodes, to the point of dynamically electing the controlling entities. All other protocols are dependent on a key device as the base of the networks security infrastructure and management. This could be the WiFi router in a typical home network, or a controller hub for Z-Wave. Thread avoids this need for specific hardware and, in so doing, removes any single point of failure (unless your network has only one Full Thread Device).
Thread has also embraced its competitors to help remove obstruction to further adoption. As of Thread 1.2, Bluetooth is now an accepted radio technology, although only for the purposes of initial discovery during provisioning. Similarly, ZigBee has ported their application layer to run on top of Thread, allowing compatibility with existing ZigBee software implementations.
The presence of key players like Google, Amazon, Apple, and ZigBee in the new Connectivity Standards Alliance makes it more likely we might finally see a ubiquitous smart home interface that can work across all our devices. The Alliance has developed and released the new standard for smart home devices called Matter which is based on Wi-Fi and Thread initially.
Issues With Thread
The biggest problem facing Thread at the moment is a lack of control for end users. With more and more players now enabling Border Router functionality on their products, and all of them wanting to push their own Thread network, it’s quite possible for Thread devices to join different networks depending on how they are initially provisioned.
While under ideal conditions this isn’t technically a huge problem since all Thread devices are IP addressable through whatever Border Router is on their network, it does make troubleshooting very awkward. Without any reliable way to visualize Thread networks at the moment, and with not knowing what network a device is connected to, it can be problematic to know where to start diagnosing a problem.
The idea in the specification is for users to be able to add any Border Router to the network of their choice, but there is yet to be an agreed standard between the major players as to how to share those credentials and make that happen. There may not be much incentive for them to work this out, either, given they all want to be the primary player in your smart home. Even so, they all claim to be ‘working on it’.
If, for whatever reason, a new Border Router can’t join an existing Thread network (because the two parties haven’t worked out a way between themselves yet), it will create its own network. Any new Thread device that is added (that isn’t under the specific control of one of your networks platforms) could end up on either, and may run into trouble communicating with devices outside of that.
That shouldn’t happen, but even if traffic is able to flow without issues between Border Routers, having multiple Thread networks undermines the benefits of redundant connectivity and mesh range extension as the member devices of each aren’t talking to each other over Thread.
How to Get Thread
Thread is still relatively new in the market but has seen a significant boost from the rollout of Matter in terms of device numbers. In order to use Thread devices, you need to have a Thread compatible device acting as a Border Router which will connect your Thread network to your main network.
Some Google Nest devices support Thread, and the main way to get it to date has been through Googles Wi-Fi routers. More recently, Apple’s HomePod Mini and newer Apple TVs have Thread support, and spurred the creation of HomeKit compatible devices using the technology. Other brands are now releasing Border Routers specifically for Thread and Matter, which is creating a more diverse landscape not tied to a particular platform.
Some Border Router options include:
The smart home industry, and IoT in general, remains a fractured market, with varying protocols and technologies vying for market share. This situation makes it confusing for newcomers looking to take up smart devices, and adds expense and complexity for those already using one technology that want to broaden their options.
Thread hopes to standardize the underlying communications for all connected devices, and provide highly reliable, secure, and maintenance free access for low powered devices. Thread has learned much from the technologies that have come before it, and looks to have achieved a superior mesh network implementation that ticks all the boxes for both smart home and industrial users.
Work remains to be done to build a unified standard for smart home devices at the application layer, but the collaboration of most of the main players in this space is encouraging. Thread provides a solid foundation for that work, and removes many of the obstacles that have been challenges up to this point. Hopefully the Matter initiative yields results in the not too distant future.