What Is Thread?

Detailed Explanation

Thread is an IPv6-based mesh networking protocol designed for low-power, battery-friendly smart home and building automation devices. It was developed by the Thread Group (founded by Nest, now part of the Connectivity Standards Alliance ecosystem) and shares its radio layer with Zigbee, but takes a different approach at the network layer: instead of a proprietary mesh routing scheme, Thread runs native IPv6 over the mesh, so every device gets a real, routable IP address. This is the property that makes Thread the preferred transport for the Matter smart-home standard. For a comparison against Zigbee, Bluetooth LE, Wi-Fi, and LoRa, see Bluetooth vs Wi-Fi vs LoRa vs Zigbee: which protocol should you use?

IEEE 802.15.4 Radio Layer

Thread's PHY and MAC layers are the same IEEE 802.15.4 radio standard used by Zigbee — 2.4 GHz, 16 channels (channels 11–26, 5 MHz spacing), O-QPSK modulation at a raw 250 kbps PHY rate. This shared radio layer is why many commercial wireless SoCs (Silicon Labs EFR32MG21, Nordic nRF52840/nRF5340, Texas Instruments CC2652R) support Zigbee and Thread on the same silicon, sometimes concurrently via a dynamic multiprotocol stack — but a Thread network and a Zigbee network are still two entirely separate networks at the software level, even when running on identical radio hardware.

IPv6 and 6LoWPAN: Native Internet Routing

The defining architectural difference between Thread and Zigbee is at the network layer. Thread runs 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) to compress standard IPv6 headers down to a size that fits efficiently in small 802.15.4 frames, then routes that traffic using standard IPv6 mesh routing. The practical result: every Thread device has a genuine, addressable IPv6 address, and can be reached directly by IP-aware software without a proprietary application-layer gateway translating between "Zigbee-speak" and "IP-speak." Zigbee, by contrast, requires a coordinator or gateway to translate its proprietary Zigbee PRO network layer into IP traffic before it can reach the internet.

Thread Network Roles

A Thread network assigns each device one of several roles, determined dynamically by the network rather than fixed at manufacture:

• Leader — exactly one active Leader per Thread network partition. Elected automatically among eligible Routers; responsible for managing the Router ID assignment pool and network configuration. If the Leader goes offline, the remaining Routers elect a new one — there is no single point of failure the way Zigbee's Coordinator can be.
• Router (R) — mains-powered or otherwise unconstrained devices that forward traffic for the mesh, provide address assignment for children, and are eligible for Leader election. Thread supports up to 32 active Routers per network in the current specification.
• REED (Router-Eligible End Device) — a device capable of becoming a Router but currently operating as an end device (e.g. because the Router pool is not full or its aggregate link cost doesn't yet warrant promotion). Thread can promote a REED to a full Router automatically as network topology requires.
• MED (Minimal End Device) — an always-on end device that stays associated with a single parent Router and does not relay traffic for others.
• SED (Sleepy End Device) — a battery-powered end device that sleeps between transmissions and polls its parent for buffered data, directly analogous to a Zigbee End Device.

Thread Border Router

A Thread Border Router is the gateway device that connects a Thread mesh to the wider IPv6 network (and, via NAT64 or a dual-stack path, to the IPv4 internet). It provides three functions: routing IPv6 traffic between the Thread mesh and the local network, hosting the commissioning service that authenticates new devices onto the network, and typically running mDNS/SRP service discovery so Thread devices are visible to other devices on the local network. In consumer deployments, the Border Router role is almost always embedded in third-party hub hardware — an Apple HomePod mini, Google Nest Hub, Amazon Echo (4th gen or later), or a dedicated device like the Nordic nRF52840 Dongle running OpenThread Border Router (OTBR) — rather than something every product needs to implement itself.

Commissioning: Commissioner and Joiner

Adding a new device to a Thread network uses a two-role commissioning protocol (MeshCoP): the Commissioner (typically software running on a phone app or the Border Router) authenticates and authorises new devices, and the Joiner (the new device) proves it holds the correct credentials — usually a pre-shared passphrase or QR-code-encoded key — before receiving the network's operational credentials (network key, PAN ID, channel). This is conceptually similar to Zigbee's Trust Center join process, but Thread's commissioning is standardised as part of the base specification rather than left to vendor-specific implementations.

OpenThread

OpenThread is Google's open-source (BSD-3-licensed) reference implementation of the Thread protocol stack, originally developed for Nest products. Rather than each silicon vendor writing an independent Thread stack from scratch, most commercial Thread products are built on OpenThread ports to vendor SoCs (Nordic nRF Connect SDK, Silicon Labs Simplicity SDK, Texas Instruments SimpleLink), which significantly lowers the barrier to Thread certification and interoperability testing compared to a fully proprietary stack.

Thread vs Zigbee vs Matter

Thread and Matter are frequently deployed together but solve different problems: Thread is a transport (how bytes move across the mesh and reach the internet), while Matter is an application-layer standard (what a "light" or "lock" looks like to any controller, regardless of vendor). A product can use Thread without Matter (e.g. a proprietary Thread-based sensor network), but a Matter product using Thread as its transport gets both native IP routing and cross-vendor interoperability.

Typical Hardware and Module Selection

Because Thread shares its radio layer with Zigbee, most Thread-capable silicon supports both protocols on the same chip:

• Nordic nRF52840 / nRF5340 — widely used for Thread and Matter-over-Thread products; the nRF5340's dual-core architecture (application core + dedicated network core) is a common reference design for Matter accessories built on the nRF Connect SDK.
• Silicon Labs EFR32MG21/EFR32MG24 — multiprotocol Zigbee/Thread/BLE SoCs used in both consumer smart-home devices and commercial building automation.
• Texas Instruments CC2652R/CC2652P7 — supports Zigbee, Thread, and BLE concurrently via TI's dynamic multiprotocol stack; commonly used in Thread Border Router reference designs alongside a Wi-Fi or Ethernet-connected host.

For product designs requiring Thread or Matter hardware integration, firmware development on OpenThread/nRF Connect SDK, or Border Router and gateway architecture, Zeus Design's electronics design team covers the full stack from radio selection through to production.

Design Considerations

• A Thread network needs at least one Border Router, but your product may not need to provide it. Before designing a Border Router into a product, confirm whether the target deployment already has one (a smart speaker, existing hub) — building your own Border Router adds cost and certification scope that may not be necessary.
• REED-to-Router promotion is automatic and should not be fought. Thread's topology self-manages which devices act as Routers based on network conditions. Designing firmware that assumes a fixed device role (rather than querying the current role at runtime) will break as the network reorganises around failures or new devices joining.
• Sleepy End Device poll interval is a battery-vs-responsiveness trade-off, the same as in Zigbee — a longer poll interval saves battery but increases the worst-case latency for a command to reach a sleeping device.
• Plan for Matter from the start if targeting Apple Home, Google Home, or Amazon Alexa. A Thread-only device without Matter certification will not appear natively in these ecosystems; Matter certification and Thread network membership are separate processes.
• Thread is one of three Matter transport options, not the only one. See Matter over Thread vs Matter over Wi-Fi for the full decision framework, including when Wi-Fi or Ethernet is the better fit.

Common Mistakes

• Assuming Thread and Zigbee devices can join the same network because they share a radio. They use the same IEEE 802.15.4 PHY but are incompatible network stacks — a Thread radio cannot join a Zigbee network's mesh, and vice versa, without an application-layer bridge.
• Building a custom Border Router when a commercial one already covers the deployment. Unless the product specifically needs local network infrastructure, relying on an existing consumer or commercial Border Router avoids duplicating certification and maintenance effort.
• Conflating Thread with Matter. Thread is a transport; Matter is an application layer. A product can be Thread-based without being Matter-certified, and Matter can run over Wi-Fi or Ethernet without Thread at all.
• Ignoring 2.4 GHz coexistence with Wi-Fi and BLE. Thread shares the 2.4 GHz ISM band with Wi-Fi, BLE, and Zigbee. Products combining Thread with a Wi-Fi or BLE radio on the same board need the same coexistence planning (channel selection, PTA/TDM arbitration) as any other 2.4 GHz multi-radio design.
• Underestimating OpenThread certification requirements. Using OpenThread as a reference implementation does not automatically grant Thread certification — formal Thread Certified Component and Thread Certified Product testing is still required before a product can use the Thread trademark and be listed as certified.

For MCU and radio platform selection guidance across Thread, Zigbee, BLE, and other wireless protocols, see how to choose a microcontroller for your project. For battery life estimation on Sleepy End Devices with periodic polling, see how to calculate battery life for an embedded device.