When it comes to connectivity options for IoT devices, there’s no shortage. For long-range there’s LTE, there’s NB-IoT, for short-range there’s Bluetooth, there’s Bluetooth low energy if battery life is a concern. And for high bandwidth short range, there’s WiFi. Thread is a relatively new and unheard-of entry into this mix and attempts to overcome the drawbacks of some of these protocols.
Thread is a mesh networking protocol developed mainly for smart home devices. The main goal of Thread is to overcome the interoperability concerns for smart home devices from different OEMs. Having very similar goals, it is no surprise that Matter(the yet-to-be-launched smart home standard) will use Thread along with WiFi for connectivity. Another development goal was to reduce smart devices’ power consumption and remove a single point of failure associated with other networking protocols. And so far, Thread has achieved these goals.
History of Thread protocol
Google acquired Nest Labs in January 2014, and soon after in July, they announced the Thread Group alliance. The group initially had seven members; Yale Security, Silicon Labs, Samsung Electronics, Nest Labs, Freescale® Semiconductor, Big Ass Fans and ARM.
As of now, the group comprises more than 350 corporate members including Apple and Amazon. Apple joined the alliance in 2018. Soon after Apple released its first Thread product, the HomePod mini.
Plenty of Thread enabled devices available in the market as of now. Eve and Nanoleaf have launched a range of products with Thread, and so have Google. The Connected Home over IP alliance, now called Matter, was launched in 2019 to develop a unified standard for smart home applications. More Thread products are expected to hit the market with the arrival of Matter. Matter will use Thread for low bandwidth and low power applications. The final specification along with the initial batch of Matter certified devices will hit the market later this year or early 2022.
How does a Thread network work?
To understand how Thread works, it is important to first understand why it is designed the way it is, and what the Thread development goals were.
Development goals of Thread
A major problem with smart home devices or IoT devices, in general, is that they can’t communicate with each other easily. Different devices have different protocols, and none of them communicates with each other directly. They’re all connected to the individual clouds and communicate with each other through other services, which is messy for both the user and the developer. The existing standards also make the devices centred around a hub.
For example, even if all the devices connect to each over WiFi, they send all the messages through the router, and not directly to each other. So if the router goes down, so does the entire network.
Another concern is the battery life. Most of the network protocols aren’t battery friendly, even for low bandwidth applications. Sending data with low latency consumes a lot of battery. If you have used Bluetooth low energy devices you must have noticed that there’s often a noticeable lag.
These are the three main challenges Thread was/is aiming to solve: interoperability, single-point-of-failure, and battery life.
Layers of Thread (some call it Architecture of Thread)
The Thread protocol is application agnostic. It can support any and multiple application layers over the network. To give an analogy, the Thread network simply passes on the messages from one device to another. It doesn’t dictate what language they talk to each other, it simply creates a channel to pass on the messages.
This means that even if devices from different devices use different languages(application layers) to talk to each other, they can still maintain the network and be a part of it. Even if a specific device doesn’t know what to do with the message it got from another one, they can still pass it onto a device in the network that knows(what to do with it).
Thread uses 6LoWPAN, which is not as scary as the acronym may suggest. It stands for IPv6 over Low Power Wireless Personal Area Network. Guessing that doesn’t simplify things so here goes. A Wireless Personal Area Network is a wireless network of devices over a small(well….) area. Low Power, is well, low power devices. IPv6 is the Internet Protocol version, meaning that devices in a Thread network have IP addresses. IPv6 has a couple of advantages when used for IoT.
This is one of the key selling points of Thread, that it works over IP. IP is well known, tried, tested, and proven to work. This makes it easy to secure networks easily, and essentially simplifies things.
The 6LoWPAN defines how messages are packaged to be sent over IPv6.
IEEE 802.15.4
The 6LowPAN in turn uses the IEEE 802.15.4 standard for physical layer and media access control. You may find cute names like IEEE 802.15.4 PHY(physical layer) and IEEE 802.15.4 MAC(Media Access Control) if you research a bit about it. Same thing.
The physical layer essentially defines the radio frequencies used for communication. And the MAC layer defines access to the layer, how different messages get access to use the frequencies at specific times to avoid collision and make the network reliable. The frequency used is 2.4GHz at 250kbps.
An interesting fact about this standard is that Zigbee also uses this very same one. Zigbee uses the same radio frequencies and chips as Thread. This means that Zigbee devices can be updated to Thread through an OTA update. Once Matter is launched, OEMs can update their existing Zigbee devices to Thread and to Matter.
Layers of Thread, but explained with a simple analogy.
Picture a couple of robots ready to receive instructions from each other standing in a room, the robots being the devices in this example. The robots connect to each other through pipes to send the boxes containing the instructions. Each of the robots has unique names (the IP addresses). The pipe here is the physical layer, the frequency of 2.4GHz.
The robots can’t open the messages or handle them unless they have a very specific packaging. 6LoWPAN defines this packaging And the MAC layer acts like a security guard over the pipe, making sure the robots get time-slots to send over the messages without causing collisions across the pipe.
In case it wasn’t already clear, this is a massive over-simplification.
Network topology of Thread
To make it easier to understand network topology, let’s have a look at the different types of devices in a thread network. Depending on the capabilities and functionality, there are many types of devices in a Thread network. Keep in mind that these are not additional devices required to maintain a thread network. These capabilities and functionalities are within smart home devices like a smart bulb, or a smart speaker.
Types of devices in a Thread network
All the devices in a Thread network can be classified into Routing and non-routing devices. And Thread devices with regard to their capabilities are classified in general into Full Thread Devices (FTD) and Minimal Thread Devices (MTD)
Routing and non-routing devices
First, let’s try to understand what “routing” is. If you already do, feel free to skip ahead.
Routing is a simple concept, it’s just passing on messages, or in more technical terms, forwarding the packets. If a device capable of routing gets a message not intended for it, it passes on the message to the intended device, or to the next routing device.
And yes, routing devices are capable of well, routing, and non-routing devices, well, aren’t.
Routing devices or routers are referred to as Parent devices. Non-routing devices are referred to as end devices or Child devices and are connected only to a single routing device in the network.
This could have been a single-point-of-failure in case the routing device goes down. But the end device will automatically connect to a new parent device without user intervention.
Full Thread Devices and Minimal Thread Devices
According to the Thread specifications, a device can be a Full Thread Device(FTD) or a Minimal Thread Device(MTD). As the name suggests, an FTD has all the capabilities of thread and can take up any role in the thread network.Devices constrained by memory, processing power, or battery will use the MTD specification. Their roles are limited in a thread network.
Full Thread Devices are capable of routing(even if they don’t do the role in the network), while a Minimal Thread Device always needs to connect to a router. Another key difference is that an FTD will always have their radio on, listening to messages from other devices. An MTD may or may not have their radio on always.
An interesting difference between the two is when it comes to multicast. Multicast is used to communicate the same message to multiple devices at the same time. There are two different options in thread for multicast: Send messages to all devices, or send messages to just the FTDs. So FTDs are subscribed to all multicast messages while MTDs get only some of these messages.
Full Thread Devices (FTD)
- Has all Thread capabilities and can take up any role in the network
- Capable of routing
- Always have their radio on
- Subscribed to all multicast messages
Minimal Thread Devices (MTD)
- Has minimal thread capabilities.
- Not capable of routing
- Some devices may have their radios on always, but not necessarily
- Not subscribed to all multicast messages
Network roles
While forming a thread network, different devices assume different roles. This is on top of their respective roles as a sensor or actuator or controller in the IoT network as a whole.
Most common device role in a thread network: router
As mentioned above, only FTD can act as a router. These devices can forward data packets between each other and other devices on the network. They also provide security to the network. There can be up to 32 routers in a network.
Leader
The leader is a role assumed by one of the routers on the network. If the leader device goes down, one of the other routers in the network assumes this role as all the other routers in the network has the relevant data on them. The whole thing happens without any user intervention, and the user won’t notice anything.
As you’ll see in the next sections, some devices in the network can be upgraded to take on more responsibilities. The leader of the network makes the decisions regarding this.
Router Eligible End Devices (REED)
These are devices in the network that can become a router but are not. If one of the routers goes down, or if there’s a change in the network, the REED device will become a router as decided by the leader. This happens usually when a new end device added to the network is within the reach of only that specific REED. It can also happen when the number of routers in a thread network is less than 16.
When a router doesn’t have any end devices connected to it, it becomes a REED.
Full End Devices
These are Full Thread Devices that cannot become a router. As you’ll see in the network topology, they’re at the end(not a technical term) of the network, connecting to a parent device (a router) for communication/connection to the network.
Minimal End Device(MED)
As the name implies, a Minimal End Device is an MTD. It has no routing capabilities and it always stays connected to a parent device for communication.
Sleepy End Device (SED)
A sleepy end device is an MTD that doesn’t have its radio on at all times. It comes online at regular intervals, maybe every 5 seconds or so to send and receive messages. As you can imagine, this is for devices where battery life is a huge concern.
Synchronized Sleepy End Device (SSED)
And this is for devices where battery life is an even more big deal. Instead of coming online at regular intervals, it comes online at a scheduled time and gets the messages from the router.
Border router
This is probably the most common device role you’ll read about when you read about thread networks. One can picture the border router being at the edge of the network. All the other devices connect to each other through Thread, but none of them connects to the wider internet or to another network. Devices can connect to each other, but can’t communicate with a device on the other side of the world.
That’s where the border router comes in. This device acts like a bridge between the thread network and other networks, like WiFi, or ethernet. A thread network can have single or multiple border routers. And a border router can be any of these device types; it can be an end device or a router.
If you recall, one of the main developmental goals of thread was to not have a single-point-of-failure. But in the case of a single border router, this doesn’t really work out well. If there are multiple border routers, and one of them goes down, the devices can connect to one of the others. For a single border router situation, the bridge goes down. The devices can still communicate with each other, but not with other networks or to the wider internet.
Network topology
Fairly certain that the network topology is apparent from the different device types above.
Routers in the network form a mesh with each other. And the end devices connect to a router. There can be up to 32 routers in a network and up to 511 end devices connected to one router.
All the routers have routing information with them, as in details on how to forward messages to other devices on the network. This is configured during network formation as well as when a new device joins. The network periodically updates this routing information between the routers.
Discovering the message routing and self-healing
The process by which the network comes up with the most efficient routing is very interesting.
Picture this, when there are multiple routers and end devices on a network, you want messages to travel the shortest distance and within the least amount of time. If two devices are connected directly, sending the message directly(in a single hop) will be the most efficient. If two are not connected directly, the message has to be routed through multiple routers. And for efficiency, it has to go through the least number of routers.
Since this is a wireless network, signal strength is also a factor.
The next is a teeny tiny bit of math, but it’ll be fun.
Thread network uses path cost to determine the best route between two routers. Path cost is (in very simple terms) the difficulty or difficulty rating of a path a message takes to travel from one router to another. When multiple paths are available, the network chooses the path with the smallest path cost.
To compute the path cost another factor called link cost comes to play. The link cost is the difficulty or the difficulty rating for a message to travel from one router to another adjacent to it in the network. Here’s where the signal strength comes into the equation. If the signal strength is low, a high link cost is attached to the link.
The path cost is the sum of all link costs that comes in between two routers.
In this manner, the network chooses the most efficient path between the two routers.
Thread network compute these costs and update them regularly, so even if a device goes offline the network is stable without any user intervention. And the network heals itself.
Device commissioning or adding a device to the network
Irrespective of whether a device is capable of routing or not, it joins the network as an end device. And later depending on the capabilities as well as the requirement they may or may not be upgraded to a router.
A device is commissioned through a mobile or tablet or a web app.
But before this, the device has to find a network and connect to a router. For this, the device will send what’s called a “Parent Request”. It’s a message to all the routers and REEDs, all though the device can limit this to just the routers. The message also contains information about the device itself.
Once the routers get this message, they all send a “Parent Response”. This contains information such as the version of thread protocol on the routers, signal strength info, leader info, etc.
Once the device gets this information from all the routers, it chooses a router and sends a “Child ID Request”.
And the router in response confirms the Child-Parent link through a “Child ID Response”.
After this, the device commissioning process begins. The joining device is authenticated through the app and once authenticated the parent router shares the network credentials to the device and it joins the network.
Matter and Thread
Matter, as mentioned above, is a new application layer standard for smart home devices and IoT in general. Along with WiFi, Matter uses Thread as a network protocol. BLE is also involved but only for device commissioning.
Matter will use WiFi for high bandwidth applications without any battery constraints. Thread will be useful when the battery is a problem and the device doesn’t have to send huge amounts of data.
The popularity of Thread will increase once Matter launches by the end of the year. The low latency reliable communication that thread offers along with its interoperability and application-agnostic properties make it ideal for Matter.
Advantages and disadvantages of Thread.
The advantages of thread is that it is interoperable with devices from other vendors, there are no single points of failure, and the battery consumption is very low. It plays well with others and has very low latency.
The disadvantage is that the bandwidth is low and is not ideal for devices with high data transfer requirements.
Advantages
- Interoperability
- Low power requirements
- Low latency
- No single point of failure
Disadvantages
- Low bandwidth
- Limited range