Thread Border Router and OpenThread: Mesh, 6LoWPAN, IPv6 and Matter

A battery sensor that must run for years, speak native IPv6, heal itself when a neighbour dies, and still be reachable from a phone on the home Wi-Fi sounds like a contradiction. Thread resolves it with a small stack: IEEE 802.15.4 radios, 6LoWPAN header compression, a self-organising mesh, and one or more gateways. The gateway is the thread border router, and it is the component most teams underestimate until a deployment misbehaves.

It matters now because Matter made Thread the default low-power transport for many smart-home and light-commercial devices, and the Thread 1.4 generation is changing how border routers share credentials and routes across vendors. Every Matter-over-Thread product you ship depends on a border router you often do not control.

You will leave with a working mental model of the Thread stack, the device roles and how they are promoted, what the border router actually does, how commissioning flows, a worked power estimate for sleepy devices, a debugging playbook using ot-ctl, and the failure modes that cause field tickets.

What this covers: the protocol stack, mesh roles and partitions, border router functions, OpenThread’s architecture, commissioning, addressing, power, topologies, debugging, and failure modes.

Context and Background

Thread is a low-power, IPv6-based mesh protocol maintained by the Thread Group. It runs over IEEE 802.15.4 in the 2.4 GHz band, where the raw PHY rate is 250 kbps and the maximum frame is 127 bytes. Those two numbers shape everything: IPv6 requires every link to carry at least a 1280-byte MTU, so Thread must compress and fragment packets with 6LoWPAN (RFC 4944 and RFC 6282) before they touch the air.

Thread did not invent its pieces. It composes existing standards: 802.15.4 for the radio and MAC, 6LoWPAN for adaptation, standard IPv6 and UDP for transport, CoAP (RFC 7252) for constrained request-response, and DTLS-based commissioning. What Thread adds is the glue: a mesh link establishment protocol, a distributed routing and leader model, and a security architecture with a shared network key. The goal is to make a mesh of constrained nodes look like an ordinary IPv6 subnet to applications.

The incumbent comparison most readers carry is Zigbee, which shares the 802.15.4 radio but uses its own network and application layers. If you have worked with it, the Zigbee protocol complete guide is a useful contrast: Zigbee needs an application-layer gateway to translate to IP, whereas Thread nodes are first-class IP hosts and the border router mostly routes. For publish-subscribe telemetry over constrained links, see our comparison of MQTT-SN, MQTT and CoAP for constrained sensor networks; Thread supplies the IPv6 substrate on which CoAP or UDP-based MQTT-SN can ride.

The ecosystem has three layers worth separating. The Thread specification is the protocol, maintained by the Thread Group. OpenThread is Google’s open-source implementation of it, and the code inside a large share of shipping Thread silicon SDKs and border routers. Matter is the application layer, from the Connectivity Standards Alliance, that runs over Thread, Wi-Fi and Ethernet. Confusing these three is the root of many design-review arguments. Thread is not Matter, and Matter does not require Thread; but when a Matter device is a battery sensor, Thread is usually the transport and a border router is the door out.

A note on terminology. Older Thread documentation talks about Routers, REEDs (Router-Eligible End Devices) and Leaders. The current OpenThread primer I checked for this article uses newer wording, such as “Mesh Extender” and “Extender-Capable Device”, for the same concepts. This article uses the long-established names and flags the mapping where it matters, since many SDKs, logs and CLI outputs still print router, leader and child.

For standards-level reading, the OpenThread project documents the stack at openthread.io, and the IETF specifications cited above are the authoritative source for the adaptation layer. The Thread specification itself is available from the Thread Group.

The Thread Reference Architecture

A Thread network is an IPv6 subnet built from 802.15.4 radios, in which a small set of always-on routers forms a self-healing mesh, a leader coordinates network-wide state, and one or more border routers connect the mesh to Wi-Fi or Ethernet while sleepy end devices poll their parents to save energy.

Figure 1: The Thread stack, from 2.4 GHz radio to Matter application layer.

The figure shows seven layers. Reading bottom to top: the PHY is 2.4 GHz 802.15.4 (250 kbps O-QPSK); the MAC adds CSMA-CA channel access and AES-CCM link-layer security; the Thread layer adds MLE and mesh routing; 6LoWPAN adapts IPv6; IPv6 and ICMPv6 handle addressing and routing; UDP and CoAP carry application payloads; and Matter defines the clusters and commands that devices expose.

The radio and MAC: small frames, hard limits

An 802.15.4 frame holds at most 127 bytes including MAC header, security overhead and payload. With link-layer AES-CCM security enabled, a frame can leave on the order of 80 or so bytes for the 6LoWPAN payload, depending on addressing mode and security level. A plain IPv6 header is 40 bytes and UDP adds 8, which would consume most of the frame without compression.

That arithmetic is why the throughput of a Thread mesh is modest. The 250 kbps PHY rate is a ceiling, not a goal; after CSMA backoff, acknowledgements, headers and multi-hop retransmission, application goodput is a small fraction of it. Thread is designed for control and sensing traffic: short commands, small reports, and occasional firmware chunks, not video or bulk telemetry. Treat any single-digit-kilobyte-per-second sustained rate as heroic for a multi-hop path.

6LoWPAN: making IPv6 fit

6LoWPAN is the adaptation layer defined in RFC 4944, with header compression in RFC 6282 (IPHC). It does three jobs.

First, header compression. IPHC elides fields that can be derived from context: the link-local prefix, addresses reconstructible from the 802.15.4 link-layer address, and well-known values for traffic class or hop limit. A fully elided link-local UDP packet can shrink an IPv6 plus UDP header combination from 48 bytes to a handful. Thread uses context-based compression for the mesh-local prefix so most in-mesh traffic compresses well; traffic to off-mesh global addresses compresses less because the full 128-bit address cannot be elided.

Second, fragmentation and reassembly. A 1280-byte IPv6 packet cannot fit one frame, so 6LoWPAN splits it into fragments with a datagram tag and offset. Losing any fragment loses the whole datagram, which makes large payloads fragile on lossy multi-hop paths. This is the quiet reason CoAP block-wise transfer and small DTLS records matter on Thread.

Third, mesh delivery. Thread forwards at the 6LoWPAN layer using its own routing tables, not IP routing, so a multi-hop path inside the mesh is invisible to IPv6 and appears as a single link.

MLE and the routing model

Mesh Link Establishment (MLE) is the Thread protocol for discovering neighbours, attaching nodes to parents, distributing network parameters, and exchanging routing data. MLE messages travel over UDP and are protected with link-layer-derived security. It is the control plane that makes the mesh self-forming.

Routing among routers is distance-vector in spirit: each router keeps a table indexed by router ID with a next hop and a path cost derived from link quality. Link quality is measured from received signal strength and translated into a small integer cost, so a poor link is avoided even if it is physically shorter. Advertisements are sent at intervals that stretch when the network is stable, which reduces overhead.

The upshot is that routing state is small and bounded. The OpenThread primer states a maximum of 32 routing nodes and 1 leader per partition, and says Thread aims to keep the router count between 16 and 23. End devices attach to a parent; the primer cites up to 511 end devices per router as an architectural bound, though practical child tables on real hardware are far smaller because RAM and radio airtime run out first.

Roles, Partitions and Leader Election

Understanding roles is the single most useful thing for debugging Thread behaviour, because nearly every field issue reduces to “who is the leader, who is routing, and which partition am I in.”

Figure 2: Device roles in a Thread mesh, including the border router and its backbone link.

The roles

Leader. One router per partition that assigns router IDs, manages network data, and decides who may become a router. It is not a single point of failure: leadership is elected, and any router can take over.
Router. Always-on, forwards packets for the mesh, accepts children, and participates in routing.
Router-eligible end device (REED). A full-function device currently attached as a child that can promote itself to a router when the mesh needs more coverage or capacity.
Full end device (FED) and minimal end devices. Attached to one parent; do not route. A Minimal Thread Device does not subscribe to the all-routers multicast address and sends everything to its parent.
Sleepy end device (SED). A minimal end device that turns off its radio between polls and asks its parent for buffered messages.
Border router. A router (or router-eligible device) that also connects to a non-Thread link.

Promotion and demotion

Thread keeps the router count in a target band so it does not run a dozen routers where five suffice, nor starve a large building of coverage. As documented in the OpenThread primer, a router-capable device that attaches as a child promotes itself if the network has fewer than 16 routers, and a standby device upgrades when it is the only node within reach of a newly joining device. A router with no children can downgrade, and existing routers may begin evaluating downgrade once the count reaches 24 or more. I am relaying those thresholds from the OpenThread documentation; they are implementation defaults, and a given vendor SDK may tune related parameters, so check your stack’s configuration rather than assuming them.

The design intent is stability: the network grows routers on demand and shrinks them quietly, and the application layer never sees it. The practical consequence is that your “sensor” may silently become a router. A mains-powered device that is router-capable will route; a battery device must be built as a sleepy or minimal end device, or it will drain its cell forwarding other people’s packets.

Partitions and leader election

A partition is a set of nodes that agree on a leader and share network data. If a link between two halves of the mesh fails, each half continues operating. Each half elects its own leader, producing two partitions that share the same network name, key and PAN ID but have different partition IDs. When the halves hear each other again, they merge: the partition with higher priority (by leader weight, then by partition ID) wins, and nodes in the loser partition reattach.

Two operational implications follow. First, a partition is a degraded but functioning network: nodes inside it can still talk to each other, which is why local automation can survive an outage that cuts off the border router. Second, a partition without a border router has no off-mesh route. Devices in it lose cloud reachability until the partitions heal. In a large building, losing one router that bridges two wings is enough to cause it, and the symptom reported by users is simply “half the sensors went offline.”

Leader weight is a configurable priority. Because mains-powered border routers tend to be the most stable nodes, many deployments bias leadership toward them, though you should confirm that behaviour against your SDK’s defaults.

How a child attaches

When a device joins, it scans channels for MLE advertisements, picks a parent by link quality and capacity, sends a Child ID Request, and receives a Child ID Response with its assigned 16-bit address. A sleepy end device then sets a poll period and a timeout; if the parent hears nothing within the timeout it drops the child, and the child must reattach. The two timers must be chosen together. A child timeout shorter than a few poll periods will cause spurious detachments under interference.

The Thread Border Router in Depth

The OpenThread documentation describes a border router as the device that “connects a Thread network to other IP-based networks, such as Wi-Fi or Ethernet.” Its minimum functions, per that page, are bidirectional IP connectivity, bidirectional DNS-based service discovery (mDNS on the infrastructure link and SRP on the Thread network), Thread-over-infrastructure to merge partitions across IP links, and external commissioning, for example from a phone.

Figure 3: Inside a Thread border router built on a radio co-processor, showing the services it runs on the host.

IPv6 routing and prefixes

The mesh has a mesh-local prefix, a ULA /64 generated when the network is formed, used for traffic that never leaves the mesh. Mesh-local addresses are stable inside the partition but are not routable outside it. For off-mesh reachability, a border router advertises an off-mesh-routable (OMR) prefix into Thread Network Data. Devices then configure an OMR address in addition to their mesh-local and link-local addresses, and the border router forwards between that prefix and the infrastructure link.

The infrastructure side mirrors this with Router Advertisements so that ordinary IPv6 hosts learn how to reach the OMR prefix. Where the upstream network can delegate prefixes, the OpenThread border router can use DHCPv6 Prefix Delegation, which the project lists among its features. Where it cannot, an OMR prefix may be generated locally as a ULA. That works inside a home but gives devices no global reachability, which is fine for Matter on the same LAN and insufficient for direct internet addressing.

Because multiple border routers can coexist, Thread Network Data carries each router’s advertised prefixes and routes with preference values, and each device picks among them. This is the mechanism that gives border router redundancy without a separate failover protocol.

Service discovery: SRP and the advertising proxy

Multicast DNS is a poor fit for sleepy 802.15.4 devices: multicast over a mesh is expensive, and sleepy nodes miss it. Thread’s answer is the Service Registration Protocol (SRP), an IETF-defined unicast mechanism in which a device registers its host and service records directly with an SRP server. The OpenThread border router runs that server. A companion advertising proxy then publishes the registered services onto the infrastructure link using mDNS so that phones and hubs can find them with standard DNS-SD tooling.

The result: a Thread device registers once with a unicast message, and the border router speaks multicast on its behalf. Registrations carry leases, so devices must renew; a device that goes silent eventually vanishes from the directory. I could not confirm from the OpenThread border router page I read that the SRP server and advertising proxy are named as discrete components there; the page describes the function (SRP on Thread, mDNS on the LAN). Treat the component naming in Figure 3 as an architectural description rather than a source-code module map.

NAT64 and IPv4 reachability

Thread devices are IPv6-only. Reaching an IPv4-only cloud endpoint or a legacy local service requires translation. The OpenThread documentation lists NAT64 as a border router feature for connecting to IPv4 networks. Paired with a DNS64-style resolution path, it lets a constrained device use an IPv6 address synthesised from the IPv4 destination. If your border router lacks NAT64 and your backend is IPv4-only, devices will resolve names fine and then fail to connect, which is a confusing symptom.

Multicast across the boundary

Multicast is where the mesh and the LAN differ most. Inside Thread, multicast is forwarded with a controlled scope using MPL (Multicast Protocol for Low-Power and Lossy Networks, RFC 7731), which trades reliability for bounded flooding by repeating messages. Across the boundary, a border router may forward multicast according to its configuration and the subscription state of devices. Operationally, prefer unicast for commands to individual devices and reserve multicast for group addressing such as lighting scenes. Reliability of group commands on a busy mesh is lower than unicast, and that is by design.

The Thread 1.4 additions

According to an NXP summary of the Thread 1.4 feature set, the headline items are credential sharing, a standard path to the internet for border routers, Thread over infrastructure, enhanced network diagnostics, and secure remote commissioning at scale for professional installations. In practice this addresses the long-standing “Thread island” problem, where a house with an Apple speaker, a Google display and a vendor hub ended up with three separate Thread networks that did not share routers. With standardised credential sharing, border routers from different vendors can join one mesh, so devices see more routers and more redundant paths.

I am citing these from a vendor summary of the specification and the public announcements, not from the specification text, which sits with the Thread Group. Two cautions apply. Features in a specification arrive in products on vendor timelines, so a 1.4-capable border router and a 1.4-capable device are two separate firmware events. And “one larger mesh” still obeys the router-count ceiling noted earlier, so unlimited joint meshes are not implied.

OpenThread: Platform Abstraction, RCP and NCP

OpenThread is the open-source implementation of the Thread protocol. Its design principle is a narrow, well-defined platform abstraction layer (PAL): the core stack is portable C++ that calls out to a small set of platform APIs for the radio, alarm timers, random numbers, non-volatile settings storage, logging and the serial link. Porting OpenThread to a new SoC means implementing that layer, not rewriting the protocol. That is why silicon vendors ship it in their SDKs; release notes from Silicon Labs, for example, track OpenThread updates inside their SDK versions.

System-on-chip, RCP and NCP

There are three common deployment shapes.

SoC (single-chip): the whole stack, application included, runs on one 802.15.4 microcontroller. This is how most battery end devices are built, and it is the cheapest and lowest-power option.
Network Co-Processor (NCP): the full Thread stack runs on the radio chip, and a host talks to it over a serial protocol (Spinel is the OpenThread host-controller protocol). The host sees a network interface and issues high-level commands. It offloads work from the host but ties your stack version to the radio firmware.
Radio Co-Processor (RCP): the radio chip runs only the 802.15.4 PHY and MAC essentials. The Thread stack, IPv6 stack and application run on the host and talk to the radio over Spinel.

The OpenThread border router documentation highlights RCP and lists its benefits: more host resources available, lower cost, easier debugging, more stable 802.15.4 SoC firmware, and easier integration with the host IPv6 stack. The last point is the important one for border routers. A border router is, at heart, a Linux machine routing between two interfaces; having the Thread stack on the same host makes forwarding, firewalling and service discovery ordinary host networking rather than a vendor-specific bridge. The trade-off is host dependency: if the host application crashes or reboots, the Thread radio has no autonomous behaviour, which is worth knowing when you plan reboots.

OTBR: the border router software

The OpenThread Border Router (OTBR) project packages the stack with the border router functions: infrastructure-link integration, the SRP server, the mDNS publisher, NAT64, DHCPv6 prefix delegation, a PSKc generator, an ingress firewall built from iptables and ipset, and a REST/web interface for diagnostics. Commercial hubs may reimplement or fork parts of this, but the architecture is a good reference even if you never run OTBR itself.

Commissioning: MeshCoP, BLE and Matter

Commissioning is the process of getting a new device onto the network with the right credentials. It has two layers that people routinely conflate: Thread commissioning gives the device network credentials, and Matter commissioning gives it fabric credentials and operational certificates.

Figure 4: Matter over Thread commissioning, from QR code scan to an operational CASE session.

Thread’s native approach: MeshCoP

Mesh Commissioning Protocol (MeshCoP) is Thread’s native, in-band joining method. A commissioner authenticates to the network, usually via a border router, using the network’s PSKc (a pre-shared key derived from the network name, extended PAN ID and a passphrase). The commissioner then opens a joiner session: the new device presents its Joiner Credential, a DTLS handshake runs through a relay (the Joiner Router), and on success the commissioner hands the device the network credentials. The scheme is designed so the device never needs to hold the network key before it is authorised.

Matter’s approach: BLE then Thread

In the Matter flow, the device is usually not reachable over Thread yet. The commissioner, typically a phone app, reads the QR code or setup code, connects to the device over Bluetooth LE, performs a secure session setup (PASE, passcode-authenticated session establishment), and sends the Thread operational dataset: network name, channel, PAN ID, extended PAN ID, network key and related parameters. The device uses that dataset to attach to the mesh through any router, including the border router. Once attached, it registers its service via SRP, the border router advertises it over mDNS, and the commissioner reconnects over IPv6, now completing commissioning with operational certificates and fabric membership over a CASE-secured session (certificate-authenticated session establishment).

The ordering explains a frequent failure: if the phone cannot read or generate the Thread dataset because it has no access to a border router, the device never gets onto the mesh. Many “commissioning failed” reports are really “no suitable Thread network” problems.

Credentials and what 1.4 changes

Historically each ecosystem maintained its own Thread dataset, so adding a device through one ecosystem placed it on that ecosystem’s network. Thread 1.4’s credential sharing is aimed at letting ecosystems offer a shared dataset to the user, so a new device lands on one mesh. Again, I rely on public feature summaries; whether a particular phone, hub or app does this depends on firmware, not just the spec revision. Secure remote commissioning for professional installs, also in the 1.4 summary, extends the idea to commercial scenarios where certificates are exchanged over BLE before the device is installed out of reach.

Addressing Deep Dive

Every Thread interface typically holds several IPv6 addresses, and knowing which to use removes a lot of confusion.

Address type	Scope	Purpose	Routable off-mesh
Link-local (fe80::/10)	One hop	MLE, neighbour traffic	No
Mesh-local EID	Whole partition	Stable identifier inside the mesh	No
Routing locator RLOC	Whole partition	Topology-based, changes when a node reattaches	No
Off-mesh routable (OMR)	Border router link and beyond	Reachability from LAN and internet	Yes
Realm-local multicast ff03::1 and ff03::fc	Partition	All nodes and MPL forwarding	No

Two of these deserve emphasis. The RLOC encodes where in the topology a node sits, which makes routing lookups cheap but means the address changes if the node moves to a different parent. Applications should never store RLOCs. The mesh-local EID stays constant for the life of the node in the partition and is what in-mesh applications bind to. The OMR address is what a phone or cloud client uses.

One more subtlety is that Thread resolves addresses lazily. A router needs a mapping from a destination EID to a RLOC, learned through an address query; if a device is unreachable, that query wait shows up as latency on first contact. Warm paths are fast, cold paths are slow, and a flaky first message after long idle is expected behaviour rather than a bug.

Power Model for Sleepy End Devices: A Worked Estimate

A sleepy end device spends nearly all its life with the radio off. It wakes on a poll period to send a data request to its parent, receives any buffered frames, and sleeps again. Average current is dominated by three terms: sleep current, the poll cost repeated every period, and the application’s own events such as a sensor report.

The numbers below are illustrative assumptions for a generic 802.15.4 SoC, not vendor measurements. Replace them with figures from your chip’s datasheet and your own bench capture.

Parameter	Assumed value
Sleep current	2 µA
Poll event: wake, CSMA, data request, ack, listen	about 5 ms at 8 mA average
Poll period	10 s
Report event: sensor read plus 1 transmit with ack	about 15 ms at 10 mA
Report interval	60 s
Battery	CR2032, 220 mAh nominal, derated to 150 mAh usable

Poll cost. Charge per poll is 8 mA × 5 ms = 40 µC (microcoulombs). At one poll per 10 s, the average is 40 µC / 10 s = 4 µA.

Report cost. Charge per report is 10 mA × 15 ms = 150 µC. At one per 60 s, the average is 2.5 µA.

Total average. 2 µA (sleep) + 4 µA (polls) + 2.5 µA (reports) = 8.5 µA.

Lifetime. 150 mAh / 0.0085 mA is roughly 17,600 hours, or about 2 years, before derating for temperature, pulse-current limits of a coin cell, and retransmissions.

Now see what the poll period does. Changing it from 10 s to 60 s reduces the poll term from 4 µA to about 0.67 µA, giving a total near 5.2 µA and a lifetime near 3.3 years. Going the other way to a 1 s poll period raises the poll term to 40 µA and collapses lifetime to a few months. The lesson is that poll period is the primary battery lever, and it is also the downlink latency: with a 60 s poll, a command from the phone can wait up to a minute to reach the device.

The design tension is clear. Sensors that only report upward can poll rarely, while actuators such as locks need low downlink latency and either a short poll or a different power class. Some Thread and Matter stacks support mechanisms to reduce this penalty for specific cases, but I have not verified specifics for current releases, so evaluate your SDK. Coin cells also cannot deliver sustained high peaks, so the 10 mA pulses above are plausible only with a capacitor or a cell chosen for it.

Finally, remember the parent. Each child’s pending messages are buffered by its parent. A parent with many sleepy children consumes RAM and airtime for them, and if the parent resets, children detect the loss only at their next poll failure and reattach. Battery life figures that ignore reattachment storms after a power outage are optimistic.

Deployment Topologies

Topology choices determine whether a mesh survives real buildings.

Single border router, single mesh. The simplest case. One point of failure for off-mesh traffic: if the border router reboots, every device loses cloud reachability, though local in-mesh communication continues. Acceptable for a hobby setup, risky for anything with an SLA.

Multiple border routers, one mesh. The recommended pattern. Each border router advertises prefixes and routes in Thread Network Data and devices pick the preferred one. When one fails, routes expire and traffic shifts. The cost is more infrastructure traffic and the need for the border routers to keep consistent state about prefixes. The merging of partitions through infrastructure links, a minimum border router function in the OpenThread documentation, lets two physically distant clusters of routers act as one network.

Multi-vendor shared mesh (Thread 1.4 direction). Border routers from different ecosystems share credentials and join the same mesh. This is operationally appealing because it multiplies router density for free, but it also couples your device’s reliability to routers you do not manage. A smart speaker that gets unplugged is now a router removed from your mesh.

Large buildings. Plan for router placement, not just border router count. A mesh needs mains-powered routers spaced so each node sees at least two routers with good link quality. Concrete cores, elevator shafts, and 2.4 GHz Wi-Fi congestion are the common obstacles. Because Thread and Wi-Fi share the 2.4 GHz band, and 802.15.4 channels 15, 20, 25 and 26 are commonly cited as less overlapped with the most-used Wi-Fi channels 1, 6 and 11, check your channel plan against the actual Wi-Fi survey rather than relying on a rule of thumb.

Industrial and commercial. These settings add pressure on diagnostics, certificate-based commissioning and long lifetimes, which is where Thread 1.4’s diagnostics and remote commissioning items are aimed. Backhaul considerations resemble those in our guide to MQTT store-and-forward at the edge gateway: if the border router loses its uplink, something must buffer and reconcile on reconnect. A Thread border router routes packets; it does not buffer your telemetry. Put a durable queue behind it.

Debugging with ot-ctl

OpenThread exposes a command-line interface. On an OTBR host, ot-ctl connects to the running daemon; on a device you may use the serial CLI. The commands below are common OpenThread CLI commands; syntax can vary slightly between builds, so confirm against your version’s CLI reference.

# Who am I and what is my role?
sudo ot-ctl state            # leader, router, child, detached, disabled
sudo ot-ctl networkname
sudo ot-ctl channel
sudo ot-ctl panid
sudo ot-ctl extpanid

# Mesh health
sudo ot-ctl leaderdata       # partition ID, weight, leader router ID
sudo ot-ctl router table     # next hops, link quality, cost
sudo ot-ctl child table      # attached children, timeouts, modes
sudo ot-ctl neighbor table   # one-hop neighbours with RSSI

# Addresses and prefixes
sudo ot-ctl ipaddr
sudo ot-ctl netdata show     # prefixes and routes advertised by border routers

# Reachability
sudo ot-ctl ping <mesh-local-or-omr-address>
sudo ot-ctl counters mac     # tx/rx, retries, CCA failures

Reading the output

state tells you the first fact: detached means the node cannot find or keep a parent, which is a radio or credential problem; child on a device you expected to route means it has not promoted, which may be normal; leader on two devices at once means a partition split.

leaderdata is the partition check. Compare partition IDs across nodes. If two nodes report different IDs but the same network name, you have a split. If border routers disagree, only the ones in the partition with your device matter for that device.

router table exposes link quality and path cost. A router with a single neighbour at poor quality is a candidate for a coverage gap. netdata show shows which border routers currently advertise an OMR prefix and a default route, and with what preference; an empty entry explains a lack of off-mesh connectivity without further tracing.

counters mac is how you detect interference. A high ratio of CCA (clear channel assessment) failures or retries to successful transmissions points to a noisy channel, often Wi-Fi. Before changing channel, collect counters over a meaningful window since transient spikes mislead.

A debugging sequence that works

Is the device attached (state)? If not, check dataset and channel.
Is it in the expected partition (leaderdata)? If not, find the split.
Does it have a route (router table, netdata show)? If not, check border router advertisement.
Can it resolve and reach the target (ping, then application)? If ping works but the app fails, you have left the Thread layer.
Do MAC counters show congestion? If so, address RF before software.

Trade-offs, Gotchas, and What Goes Wrong

The border router is a dependency you often do not own. A Matter-over-Thread product commonly relies on whatever border router the customer already has. Behaviour of prefix handling, SRP lease durations, NAT64 availability and firmware versions varies. Test against several vendors’ border routers and record the matrix; do not assume the open-source reference behaviour holds in a consumer speaker.

Single border router, single point of failure. In-mesh communication survives, but cloud reachability and commissioning do not. Deploy two or more where uptime matters, and verify failover by pulling power rather than trusting the diagram.

Partitions are quiet. Nothing alarms when a mesh splits; you only notice because a subset of devices goes dark. Monitor partition ID and router count from the border router and alert on change. This is a good fit for an observability pipeline; see how collector changes affect that kind of telemetry in our note on OpenTelemetry specification 1.61 collector changes.

Interference. Wi-Fi, Bluetooth, microwave ovens and USB 3 noise all live at or near 2.4 GHz. Thread’s channel agility and retransmission hide a lot of it until they do not. Symptoms are rising retries and growing latency before outright disconnects.

Router churn and battery drain. Misconfigured router eligibility can turn a battery device into a router, and an overly sparse mesh forces sleepy devices to attach to distant parents with poor links, raising retry energy. Decide each product’s role at design time.

Sleepy latency surprises. As the power model showed, poll period equals worst-case downlink latency. Users who expect a lock to respond in under a second will not accept a 10 s poll.

Mismatched timers. Child timeout shorter than a few poll periods causes spurious detach and reattach loops. Reattachment is expensive in energy and airtime.

Throughput expectations. Firmware updates over a multi-hop Thread mesh are slow and fragile because of 6LoWPAN fragmentation. Budget hours, not minutes, and use block transfer with resumption.

Security assumptions. The network key is shared by every device in the mesh. A compromised joined device reveals it. Commissioning protections limit who can join, but they do not isolate devices from each other within the mesh, so application-layer security (Matter’s own session security) still matters.

Practical Recommendations

Treat the border router as part of your product, even when the customer owns it. Specify minimum behaviours you depend on (SRP, an OMR prefix, mDNS, NAT64 if your backend is IPv4), and test against at least three border router implementations.

For battery devices, choose the sleepy end device role, then pick the poll period from the latency requirement first and battery second. Run the power arithmetic with your measured numbers, and include a reattachment storm in your battery model.

For deployments, plan at least two border routers, place mains-powered routers so every node has two good parents, and survey 2.4 GHz before choosing a channel. Put a durable queue and a reconciliation path behind the border router for telemetry.

Instrument the mesh. Export role, partition ID, router count, child count and MAC counters from each border router, and alert on partition changes and retry-rate trends.

Checklist

[ ] Role chosen per device class (router, full end device, sleepy end device)
[ ] Poll period and child timeout set together
[ ] Two or more border routers where uptime matters
[ ] Border router behaviours tested across vendors
[ ] NAT64 verified if the backend is IPv4-only
[ ] Channel selected from a real RF survey
[ ] Partition ID and router count monitored
[ ] OTA update budget calculated for multi-hop paths
[ ] Thread 1.4 feature support checked per product, not assumed

Frequently Asked Questions

What is a Thread border router?

A Thread border router is a device that connects a Thread 802.15.4 mesh to an IP network such as Wi-Fi or Ethernet. It forwards IPv6 traffic, runs service discovery (SRP on the mesh, mDNS on the LAN), can provide NAT64 for IPv4 access, and supports external commissioning from a phone. Many smart speakers, hubs and routers include one, and a network can have several.

Is OpenThread the same as Thread?

No. Thread is the protocol specification maintained by the Thread Group. OpenThread is a widely used open-source implementation of it that runs on many chips and powers the OpenThread Border Router. Other implementations exist, and certified products must conform to the specification regardless of the codebase. Matter is a separate application layer that can run over Thread.

Does Matter require Thread?

No. Matter runs over Wi-Fi, Ethernet and Thread. Thread is typically chosen for low-power battery devices, since Wi-Fi radios consume far more energy. A Matter-over-Thread device needs a Thread border router on the home network so that controllers on Wi-Fi or Ethernet can reach it. Mains-powered devices frequently use Wi-Fi or Ethernet instead.

How many devices can a Thread network support?

The OpenThread primer states limits of one leader and 32 routers per partition, with up to 511 end devices per router as an architectural bound. Practical limits are lower and depend on RAM, child table sizes and airtime. Real deployments are usually limited by RF conditions and traffic patterns rather than the protocol ceiling, so test at your expected density.

What happens when the border router goes offline?

Devices inside the mesh keep communicating locally, because routing is distributed and the leader role is elected. What breaks is anything that crosses the boundary: cloud connectivity, phone control over the LAN, and new commissioning. A second border router on the same mesh removes this single point of failure, with routes shifting after the first one’s advertisements expire.

What does 6LoWPAN do in Thread?

6LoWPAN adapts IPv6 to 802.15.4. It compresses headers (RFC 6282), fragments 1280-byte IPv6 packets into small frames (RFC 4944), and supports forwarding across the mesh. Compression is most effective for in-mesh traffic using the mesh-local prefix, while off-mesh global addresses compress less. Loss of a single fragment loses the whole datagram, so keep payloads small.