Thread’s physical layer is based on IEEE 802.15.4, which is a low-power and low-speed network protocol. Therefore, low power consumption and low transmission speed are the two main characteristics of Thread.
The general readers may not understand the technical details behind the network, and it is not easy to understand the technical details behind Thread directly, so this time we intend to start from the characteristics of smart home and push back the advantages behind Thread.
First of all, in many scenarios of smart home, the biggest requirement is to maintain low power consumption. From small sensors to large control switches, they cannot rely on utility power, otherwise the deployment scenario will be greatly limited; and the frequent need to replace batteries will also reduce the reliability of sensors and control switches. So devices using Thread can be kept at a lower power level, but low power consumption does not mean that they can only be deployed in battery-powered devices. Many of our readers and friends may already have HomePod mini, Apple TV 4k (2021) and eero router with Thread built in, about which we will expand in the second half of the article.
Secondly, the amount of data exchanged in the smart home is not very large, and the vast majority of data exchange is passing data from a few attributes to the device, so it is more important to have faster, more stable and more targeted transfers than to be able to pass larger packets.
But before Thread, we actually have other low-power protocols, the two most representative and relatively successful ones are: Bluetooth mesh and Zigbee.
All three protocols can be simply divided into three layers: the application layer, the network layer and the RF layer (physical layer). In order to facilitate the correct understanding of these three layers for those readers who do not have a basic understanding of networking, we can continue using the example of sending a courier from the previous article.
The physical layer, defines how the courier is delivered. A parcel may be delivered by bicycle or car, or by plane or train.
And the network layer, the courier company responsible for transporting the parcel, different companies are different for the handling of express mail and the way to send different sizes of parcels in efficiency. Other courier companies also do not know how this courier company’s courier bill number is handled, but different courier companies can also use the same delivery method (physical layer), such as the above figure of Zigbee and Thread physical layer is the same.
The application layer is the language used to wrap the letters, and the different languages need to be readable by the appropriate users.
In contrast to Bluetooth Mesh and Zigbee, Thread does not define its own application layer; to put it another way, Thread is more free, allowing developers to transmit their own application protocols through Thread, of which matter is one.
Moreover, Thread is not limited to matter as an application layer; others such as HomeKit or Google Home are now using Thread to deliver their own application layers. In contrast, Zigbee and Bluetooth Mesh define the application layer, simplifying the development process but limiting its use.
However, it is important to note that the Thread network protocol has an IP protocol, which means that many Ethernet-based applications can easily run on the Thread network, but this section will not be discussed in this article.
When a Thread device is added to a home, it automatically forms a Thread network with other Thread-enabled devices in the home.
Like other Mesh networks, Thread networks are self-healing; these self-healing networks will ensure the connectivity of other nodes even if one node drops out.
In the past, Bluetooth mesh and Zigbee-based protocols required gateways for the corresponding protocols, and once the gateway was down, the devices in the network would also be down.
Thread, however, thanks to its excellent node management mechanism, can maintain the accessibility and robustness of the entire network after any key device goes offline.
Devices are broadly classified into two categories, Router and End Device, based on their characteristics and the tasks they can undertake when they are connected to a Thread network.
Routing is responsible for building the main Thread network and forwarding messages in the Thread network. Similar to the routers we see in our daily lives, the data generated by a device will be routed to the corresponding device to choose the most efficient and appropriate path.
Node devices are connected to only one router at a time, and node devices will only send or receive messages through the route they are connected to.
Thread can ensure that the entire network can be used normally after any key device goes down because a certain class of Thread devices can switch between routing or node device identities, which are called FTD (Full Thread Device) in Thread networks. FTDs also tend to use utility power, so they can be upgraded to routing status when needed, and can be downgraded to node device status when not needed; those devices that can only be powered by battery, that is, can only play the role of node device status, in the Thread network is called MTD (Minimal Thread Device). FTD and MTD can be further divided into more sub-device categories.
FTD can be subdivided into three types.
Routing: responsible for building Thread main network and forwarding information, can be downgraded to a node device.
Route-eligible node device (REED, Router Eligible End Device): can be upgraded to a route, but exists as a node device in the Thread network.
FED (Full End Device): A node device that cannot be upgraded to a routing device and is generally rare.
MTDs can be subdivided into two types.
Minimal End Device (MED, Minimal End Device): a node device that will always turn on its own transceiver, without polling messages from the router.
Sleepy End Device (SED): A node device that normally turns off its own transceiver (i.e. sleeps) and occasionally turns on its transceiver (wakes up) to poll for messages from the router.
In a Thread network, there are two other special types of routes: the Leader Router and the Border Router.
The Leader Router is responsible for managing all the routers in the Thread network. In order to improve fault tolerance, Thread dynamically selects a router as the Leader Router, which is responsible for aggregating and distributing network-wide configuration information. It can be simply understood as the Leader Router of a Mesh router, which manages all Mesh nodes.
However, the Leader Router in a Thread network is not fixed, and the same Thread network will change the Leader Router from time to time to increase fault tolerance. Any Thread device that can act as a route may be elected as the Leader Router.
An Border Router is a device that forwards information between a Thread network and other networks, such as Wi-Fi and BLE. As mentioned earlier, different “courier companies” do not communicate with each other, so a “third party company” is needed to synchronize courier data from one side to the other, and this “third party company” is the edge router.
There can be multiple Border Routers in a Thread network, and even if one or more of them fail, the accessibility of all remaining Thread devices can be guaranteed. An Border Router will not only support Thread protocol, but also often support other communication capabilities such as Wi-Fi and BLE, so that even if there is a problem with Wi-Fi in the home, it can still be accessed through BLE.
To ensure optimal performance, the number of device types supported by a single Thread network is limited, and the number of Router in a Thread network is dynamically adjusted based on the network size to achieve maximum coverage and fastest message forwarding speed.
In a Thread network, the Thread tries to keep the number of Router between 16 and 23. If a REED joins as an End Device and the number of Router in the network is below 16, it will be automatically upgraded to a Router to increase the coverage and path diversity of the Thread network.
In addition to its careful node classification and sophisticated network management mechanisms, Thread uses IPv6 as its communication foundation. IPv6 is the next-generation network protocol for the Internet, designed to replace the current network, IPv4. In order to communicate over the Internet, computers and other devices must have sender and receiver addresses. These digital addresses are called Internet Protocol addresses. IPv6 has a large number of addresses and is therefore more suitable for IoT devices than IPv4, in addition to the many other benefits that IPv6 offers.
End-to-end routing and addressability: Two IPv6 devices, whether on the same Thread grid, across networks or around the world, can communicate end-to-end via straightforward and easy-to-understand Internet routing, without the need for gateway translation.
Easy to manage: Unlike IPv4 networks, IPv6 networks are inherently auto-configured, eliminating the need for users and system administrators to worry about address assignments, DHCP servers, etc.
Mature and stable: IP networks are mature enough that developers can quickly get up and running with Thread’s application layer.
Flexible: Multiple upper layer protocols are supported, including TCP/UDP and other classic network protocols.
In matter, all matter devices will use IPv6 to communicate, so the concept of “gateway” in the previous smart home system will be gradually faded out, and the communication between Thread and other IP networks will only need Border Router to forward. Another invisible advantage of using IP communication is that Thread can use the debug method of traditional IP network to troubleshoot compared with the protocol of non-IP network, and developers can directly confirm the situation of Thread network on their own PC/Mac.
After understanding the mechanism of Thread network, we can look at the comparison of actual Thread network and the mainstream low-power network protocols on the market now.
When describing the transmission methods of the three protocols, two new terms appeared above, Flooding and Routing. both Thread and Zigbee use routing to forward information. Packets are routed through a routing table recorded in the Router to send them to the sub-device in the shortest path.
In contrast, Bluetooth Mesh uses flooding, which is different from routing in that a packet is broadcast out cascade by cascade, and the device receiving the packet finds that it is not the recipient of the packet and continues to broadcast until it is communicated to the target device. Of course Bluetooth Mesh also provides a limited routing method, but it needs to be set by the user, which is more tedious and will not be discussed in this section.
Simply put, flooding is like all people with a loud speaker. From the source of the message with the loudspeaker to tell the nearby people what they need to do, the nearby people hear the message and find that it is not for themselves, they pick up the loudspeaker again to tell their nearby people, and so on until the target of the message is told.
Routing, on the other hand, is a bit more efficient, and the information source remembers the location of all devices and the shortest path to deliver the message from the beginning. When a command is issued, it will only tell the fastest person who can deliver the message, and the same goes for the remaining devices inside the network, each message has a fixed delivery path.
Careful readers may have noticed that routing is much more efficient than flooding, but the performance of Zigbee and Thread, which are responsible for routing, is correspondingly higher, not only to record the routing table in storage, but also to calculate the best path; while the performance requirements of Bluetooth Mesh are much lower.
Both are far more efficient than flooding in terms of efficiency, latency, overhead, and bandwidth compared to routing. Flooding also does not allow complete synchronization between devices because the path is not fixed and the timing of message delivery to the device cannot be accurately controlled. However, the chip performance required by Routing is much higher than Flooding, which corresponds to the increase in cost and price.
Here’s a report from SiliconLab comparing the three protocols, and Thread far outperforms Zigbee and Bluetooth Mesh in real-world testing.
As mentioned earlier, the amount of data exchanged in a smart home is not large, but it is sensitive to latency and synchronization rates. Typically, after operating a smart home, if the response time of the device is within 200ms, it is a very difficult latency to perceive. Of course this latency is not only the transmission delay of low-power protocol, but also includes the time of LAN, WAN, and information processing.
This data set shows the latency of the three protocols for different packet sizes after four hops (i.e., four times the packet is forwarded). You can see that when the packet size reaches 130 bytes, which is typically the data returned by a temperature and humidity sensor, Thread has a latency of less than 100ms, while Bluetooth Mesh, in contrast, has a latency of up to 800ms and is not able to transmit larger packets in the application layer setting.
In a small network with 50 bytes of packets, Thread has low latency and is concentrated, while ZigBee has good concentration but slightly higher latency, and better concentration means better synchronization. The latency of Bluetooth Mesh is distributed in various intervals, which is likely to be the case in the figure below.
The most intuitive feeling brought by the latency distribution is the synchronization of multi-device control, Thread’s latency distribution is more concentrated, giving the user the perception that the devices are completely synchronized with each other. In contrast, Bluetooth Mesh is more likely to show the experience of turning on devices one by one.
Put into a very large network, Thread also maintains the above advantages, and still maintains a low latency and concentrated latency distribution. At this point, the latency and distribution of Bluetooth Mesh has reached the point of unavailability.
Summary
In this article, we have introduced the Thread protocol, briefly described its operation mechanism and performance advantages, and analyzed the countermeasures under various conditions. Compared with the past low-power device addition process, devices using Thread protocol do not even need to purchase a gateway specifically for them, users only need to follow matter’s device addition process to add devices using Thread communication protocol to enjoy all the convenience Thread brings to users.
At this point in time, Thread has also released its version 1.3 to announce support for matter, so Thread devices from different manufacturers such as HomePod mini, eero 6 series routers, and Nest Hub can now work together in the same Thread network. As the first communication protocol of matter protocol, the popularization of Thread will undoubtedly make the current smart home experience greatly improved. In the next article, we will focus on the operation and security mechanism of matter, the wrapper of Thread transmission.
Published by YooCare Editor & last updated on February 2, 2023 1:05 pm
