Thread's Network Role in Low-Power IoT
The Internet of Things (IoT) combines several low-power networking technologies. A smart home contains devices such as sensors, light bulbs, and door locks that need reliable communication. Zigbee and Z-Wave created low-power mesh networks, while many deployments used a hub or gateway to connect their network and application stacks to Internet Protocol (IP) networks. In such a deployment, the gateway translates between the local protocol and the IP network used by smartphones and computers. Thread places IPv6 networking inside the low-power mesh, so a device can use IP addressing within the Thread network while a Border Router handles external connectivity.
A hub can become a single point of failure when devices depend on it for control. Translation can also add processing steps to a command, and products using different local protocols need an integration path before they can exchange data. Wi-Fi carries IP but usually consumes more energy than small battery-operated devices can provide, while Bluetooth Low Energy was initially focused on short point-to-point links rather than home-wide mesh routing. The resulting design question concerned the network layer, addressing, and forwarding path, rather than a new application command language.
Thread was created to combine low-power mesh routing with IPv6 networking. The Thread Group was formed in 2014 by seven organizations: Yale Security, Silicon Labs, Samsung Electronics, Nest Labs, Freescale Semiconductor, Big Ass Fans, and ARM. Its broader membership has included companies such as Apple, Samsung, and Qualcomm. provides the network layer for IoT devices. Application standards define device behavior, while Thread supplies IPv6 connectivity inside the Thread network and uses a Border Router for connectivity with other IP networks.
IEEE 802.15.4 Radio Foundation
Thread uses the established IEEE 802.15.4 physical radio standard instead of defining a separate radio interface. IEEE 802.15.4 is also used by Zigbee and other low-power protocols, while Thread defines its own network architecture above the radio. The radio supplies the physical transmission and MAC framing, while Thread adds the network functions needed by its mesh devices.
Using IEEE 802.15.4 gives Thread several characteristics suited to low-power IoT devices:
- 2.4 GHz ISM Operation: Thread uses the 2.4 GHz ISM band, which is widely available worldwide. Regional rules still define channels, permitted power, and other operating conditions. Wi-Fi and Bluetooth use the same band, and Thread includes coexistence mechanisms, but those mechanisms do not remove interference in every installation.
- DSSS Modulation: The 2.4 GHz PHY uses DSSS (Direct Sequence Spread Spectrum), which spreads a signal across a wider frequency band. The method improves resistance to some narrowband interference in the 2.4 GHz band.
- 250 kbps Data Rate: The IEEE 802.15.4 2.4 GHz PHY provides 250 kilobits per second (kbps). IoT devices commonly send short messages such as sensor readings, status updates, and on/off commands. This rate supports those messages while the radio can use less energy than a higher-speed radio, depending on the implementation and traffic pattern. The value is the PHY bit rate, so application throughput is lower after MAC headers, security fields, acknowledgements, and retransmissions.
Thread's network behavior comes from the layers above the radio. It combines IEEE 802.15.4 with IPv6, 6LoWPAN adaptation, mesh routing, and security, while application standards remain separate from the network layer. This separation lets the same network layer carry application protocols such as Matter without changing the radio framing.
IPv6 and 6LoWPAN in Thread
Thread uses IPv6 for addressing and routing inside its mesh. Devices can have link-local and mesh-local IPv6 addresses, while a Border Router can advertise additional prefixes for external connectivity. A mesh-local address identifies a device within the Thread network and is not automatically routable across the public Internet.
The IEEE 802.15.4 Frame Size Constraint
IPv6 on small, low-power devices has a frame-size constraint. An uncompressed IPv6 header is 40 bytes, while the IEEE 802.15.4 physical frame is limited to 127 bytes and MAC and security fields reduce the available payload. IPv6 also defines a 1280-byte minimum MTU, but a packet of that size cannot fit in one 802.15.4 frame, so 6LoWPAN adaptation and fragmentation are needed on this link. The 127-byte value describes the physical-layer frame, not the application payload available to a Thread device.
6LoWPAN Adaptation Layer
Thread solves this problem by using an adaptation layer called . 6LoWPAN is an adaptation layer between IPv6 and the 802.15.4 MAC layer. RFC 4944 defines the basic frame adaptation and fragmentation procedures, while RFC 6282 defines the current header compression format. It performs two functions:
- Header Compression: 6LoWPAN uses shared link context and fields inferred from lower layers to reduce IPv6 header size. In the best case, the 40-byte header can be represented by several bytes, but the result depends on the addresses, context, and extension headers. RFC 6282 also defines compressed encoding for selected next headers, so the saved space depends on the complete datagram.
- Fragmentation and Reassembly: An IPv6 datagram that remains too large for one 802.15.4 frame is divided into smaller fragments. Fragment headers carry the information needed for the receiving device to reassemble the datagram. The receiver must collect the fragments belonging to one datagram before passing the reassembled IPv6 packet to the next layer.
6LoWPAN lets Thread devices exchange IPv6 datagrams across constrained links while handling header compression and fragmentation. The resulting addresses support end-to-end communication inside the Thread network, with external routing provided by a Border Router.
Thread Roles and Route Repair
Thread distributes forwarding and management across several device roles. This reduces dependence on one node, while the actual behavior depends on the role and network state. Every device initially attaches as an End Device and can later become a Mesh Extender when its type and network conditions permit.
Routers and Router-Eligible End Devices (REEDs)
These are often mains-powered nodes, such as smart plugs, thermostats connected to HVAC power, or light fixtures. They stay available to forward packets for other devices. A Thread network supports up to 32 active routers, while 64 router addresses allow address recycling. A Mesh Extender can support up to 511 End Devices in the OpenThread device-limit table. A device that could become a router but is not currently needed for that function can act as a REED.
Sleepy End Devices (SEDs)
These are the battery-powered devices. To conserve power, they do not route packets. They connect to a chosen "Parent" router. A SED can spend most of its time in a deep sleep state, waking up only to send data or to poll its Parent for any messages that might be waiting for it. The Parent maintains the child relationship and forwards traffic for the sleeping device.
The Leader
Unlike Zigbee's single Coordinator, a Thread partition has one dynamically elected Leader that manages router assignments and network parameters. When a device creates a new network, it becomes a Mesh Extender and elects itself Leader. Each partition has its own Leader and router identifiers. If the Leader fails, another Mesh Extender can be elected, but this election does not guarantee uninterrupted delivery of every data flow.
Border Routers
A forwards information between the Thread mesh and another IP network such as Wi-Fi or Ethernet. A home can have multiple Border Routers, and their routes and configuration can provide redundancy if one device fails. Smart speakers such as Apple's HomePod Mini or Google's Nest Hub can provide this function.
Self-Healing Mesh
Thread's routing is dynamic. MLE configures links and distributes link quality and route information, while route propagation works similarly to the distance-vector Routing Information Protocol (RIP). Routers periodically exchange link and path costs, which gives them route information for other routers in the partition. If a router fails or a communication path becomes obstructed, neighboring routers can update their routing tables and select another available path. The result depends on link quality, topology, and network state.
Thread and Matter: Separate Network and Application Layers
Thread and Matter operate at different layers of the networking stack. Thread provides IPv6 networking, while Matter defines interoperable application behavior for smart-home devices. Matter can use Ethernet, Wi-Fi, or Thread as its network transport, with the selected transport depending on the product.
Their roles can be separated by the type of information each specification carries:
- Thread provides IPv6 networking: Thread establishes links, selects paths, and forwards IPv6 packets between addresses in the Thread network. It does not define the device commands carried inside those packets.
- Matter defines the application layer: Matter standardizes device models, commands, and data so a compatible switch and light can interoperate. Matter runs above a network transport such as Thread, Wi-Fi, or Ethernet.
Matter supports Thread as one network transport for low-power devices and also supports Wi-Fi and Ethernet. A Matter device on Wi-Fi can exchange IPv6 traffic with a Matter device on Thread through a Thread Border Router, which forwards packets between IP networks without translating the Matter application model. Matter commonly uses Bluetooth Low Energy for commissioning and setup, while a Thread-based Matter device must support BLE for initial discovery and commissioning.
A product that supports both technologies can hold both certifications. Thread certification covers the radio and Thread networking stack, while Matter certification covers the Matter application protocol. A product using Wi-Fi or Ethernet for Matter can be Matter-certified without Thread certification. Matter certification also requires certification for the underlying transport when the product uses that transport.