27 Thread Network Architecture
Thread network architecture, Thread device roles, Thread Border Router, Thread Leader, Thread REED SED MED FED
27.1 Thread Network Architecture Evidence
Thread architecture is best reviewed as a set of roles and boundaries, not as a product diagram or a promise that every device will behave the same way. A Thread mesh contains devices that can route, devices that can become routers, devices that only communicate through a parent, and one or more Border Routers that connect the mesh to adjacent IP networks.
The architectural question is therefore evidence based: which devices carry network responsibility, which devices depend on a parent, which service boundary is being claimed, and what retest trigger would make the architecture record stale?
27.2 In 60 Seconds
- Thread uses an IPv6 mesh architecture for constrained IoT devices.
- Routers form the always-available mesh backbone and can host child devices.
- A Leader is an elected router role for network management inside a partition; it is not the same as an application controller.
- A Border Router connects the Thread mesh to another IP network, but it does not prove every cloud, Matter, dashboard, or support path.
- REED, FED, MED, and SED roles express different routing, listening, latency, and power responsibilities.
- Architecture review should record role evidence, parent-child evidence, Border Router boundary evidence, application boundary evidence, and retest triggers.
27.3 Learning Objectives
By the end of this chapter, you will be able to:
- Separate Thread Border Router, Leader, Router, REED, FED, MED, and SED responsibilities.
- Explain why parent-child evidence is different from mesh-routing evidence.
- Identify what a Border Router proves and what it does not prove.
- Build a role evidence record for a small Thread deployment.
- Catch common architecture overclaims before they become deployment assumptions.
27.4 Start With the Architecture Claim
A useful Thread architecture claim names the behavior being reviewed. It should not start with a product list, a device count, or a general phrase such as “Thread is self healing.” Start with a bounded claim.
Device responsibility
Does the device route, only communicate for itself, sleep, stay ready for promotion, or bridge to another network?
Network boundary
Is the claim mesh-local, parent-child, Border Router, local controller, Matter, dashboard, or cloud-facing?
Evidence source
Which observation proves the role, path, parent, prefix, service boundary, or recovery behavior?
Retest trigger
Which change would make the architecture record stale: moved routers, changed Border Router, new firmware, new application path, or new power state?
The same physical device may be involved in several claims. For example, a Border Router can also participate as a router inside the Thread mesh, while the external service path still needs separate evidence.
27.5 What Each Role Proves
Thread role names are useful only when they are tied to evidence. The goal is not to memorize labels; the goal is to know what each label proves about the network.
Border Router
Routes between the Thread mesh and another IP network. Evidence should show the specific boundary, service behavior, and owner of the off-mesh path.
Leader
Maintains management state for a connected Thread partition. Evidence should show that leadership is a network role, not an application controller or single permanent device.
Router
Participates in mesh forwarding and may host child devices. Evidence should show that it is awake enough to support routing responsibilities.
REED
Is eligible to become a router when the network needs and permits that role. Evidence should avoid assuming that eligible means currently routing.
FED
Is an end device that remains ready to receive without acting as a mesh router. Evidence should separate low-latency reception from routing responsibility.
MED or SED
Communicates through a parent and may trade response timing for power. Evidence should show parent choice, queued-message behavior, and whether the application can tolerate the delay.
27.6 Full and Minimal Device Boundary
The first architecture split is capability based. A Full Thread Device (FTD) keeps enough radio and protocol state active to route traffic and act as a parent. A Minimal Thread Device (MTD) is a leaf device: it attaches to a parent, communicates for itself, and does not forward traffic for neighbors.
That distinction keeps role evidence honest. A Leader is an elected router role inside a partition, Routers forward traffic and may parent children, REEDs are FTDs waiting as end devices until promotion is useful, and a Border Router adds an off-mesh IP boundary. Those labels should be tied to observed responsibility, not inferred from product names.
The role map separates mesh links, parent-child links, and off-mesh Border Router evidence so a reviewer does not approve a role claim from the wrong observation.
27.7 Knowledge Check: Full Thread Device
27.8 Router Cap and REED Promotion
Thread deliberately caps the number of active Routers at 32. That limit bounds routing state and control traffic so constrained devices do not have to maintain an unbounded mesh backbone. A network can contain many more than 32 devices, but only the active router set carries mesh-routing responsibility.
REEDs exist because capability and current role are different. A Router-Eligible End Device is an FTD acting as an end device until the network needs more routing capacity and promotion is permitted. Review evidence should therefore say whether a device is currently routing, merely eligible, or intentionally left as an end device.
| Role | Architecture evidence | Review question |
|---|---|---|
| Leader | Elected partition-management role | Is this network management evidence, not application-controller evidence? |
| Router | Active forwarding and parent responsibility | Does the device actually route and host children for this claim? |
| REED | FTD capability without current router assignment | Is the device eligible for promotion or already routing? |
| MED, SED, or SSED | Parent-dependent end-device behavior | Does polling, sleep, and latency match the application claim? |
27.9 Knowledge Check: REED Promotion
27.10 Border Router Boundary
A Border Router is the most common place where architecture claims become too broad. A mesh-local test can show that devices inside the Thread network communicate. It does not automatically prove that an off-mesh service, cloud path, Matter controller, support dashboard, or remote user workflow is correct.
Review the Border Router boundary in layers:
Mesh side
Which Thread devices can reach the Border Router inside the mesh, and which roles are involved?
Routing side
Which prefix, route, discovery, or translation behavior is needed for the off-mesh claim?
Application side
Which controller, Matter fabric, local service, dashboard, or remote endpoint is part of the claim?
Ownership side
Who owns retest when the Border Router, network policy, application service, or device role changes?
This keeps the Border Router from becoming a magic gateway in the documentation. It is an IP routing and service boundary that should be named, observed, and retested.
27.11 Knowledge Check: Border Router Evidence
27.12 Parent-Child Evidence
End devices depend on parents. That relationship is architectural, not just operational. A parent must be available for the child communication pattern, and the child must be configured for the latency and power behavior the application expects.
Child role claim: battery contact sensor reports local state without routing traffic.
Parent evidence: attached to a nearby router with an observed parent-child relationship.
Application boundary: local event delivery is accepted; immediate inbound commands are not part of the claim.
Retest trigger: parent moved, wall power changed, firmware changed, or alert latency requirement changed.
For a low-power child, the architecture record should not say “the mesh heals itself” and stop. It should say which parent-child assumption was observed, what happens if the parent is unavailable, and what application behavior is still acceptable.
27.13 RLOC16 and Mesh-Local Identity
Thread gives each device a Routing Locator (RLOC), a mesh-local IPv6 address whose lower bits contain a 16-bit RLOC16. The RLOC16 encodes the device’s current routing position: a 6-bit Router ID plus a 10-bit Child ID.
RLOC16 = [ Router ID : 6 bits ] [ Child ID : 10 bits ]
A Router's own RLOC16 has Child ID = 0.
Its children get Child IDs assigned under that Router ID.
Routing uses the Router ID to choose the next hop.Because the RLOC reflects where the device currently sits, it can change when topology changes. A child that switches to a new parent gets a new RLOC16, and a REED promoted to Router gets its own Router ID. Applications should not treat that locator as stable identity. The Mesh-Local EID (ML-EID) gives the device a stable mesh-local address that does not move with the topology.
27.14 Knowledge Check: RLOC16 and ML-EID
27.15 Role Selection Evidence
Good role selection starts with responsibility, then verifies capability. Avoid assuming that all mains-powered devices route, all battery devices sleep correctly, or all router-eligible devices are currently routers.
Power state
Can this device remain awake enough to carry the responsibility being assigned?
Routing need
Does the local area need this device to forward traffic or host children, or is it only an endpoint?
Reception need
Does the application require prompt inbound messages, or can it tolerate parent polling behavior?
Promotion assumption
Is the device currently routing, merely eligible to route, or intentionally kept as an end device?
Boundary claim
Is the claim inside the mesh, across the Border Router, or above Thread in Matter or another application layer?
Retest owner
Who checks the architecture again after role, placement, power, firmware, or service changes?
27.16 Worked Architecture Records
Use short records rather than broad slogans. Each record should name the role, the boundary, the evidence, the limit, and the retest trigger.
Record A: hallway plug as mesh support
Claim: the plug can support local mesh forwarding and child attachment in the hallway.
Evidence: observed as a router or router-capable device with stable power, local neighbors, and child capacity appropriate to the claim.
Limit: does not prove cloud access or application automation.
Retest: plug moved, unplugged, firmware changed, or nearby child devices added.
Record B: battery sensor as sleepy child
Claim: the sensor can report events while conserving power and without routing traffic.
Evidence: observed child attachment, parent relationship, event delivery path, and acceptable application delay.
Limit: does not host other devices and should not be counted as mesh backbone.
Retest: parent changes, latency requirement changes, battery profile changes, or firmware changes.
Record C: Border Router for local controller access
Claim: Thread devices can be reached by a local controller through the Border Router boundary.
Evidence: observed mesh-side reachability, Border Router service behavior, controller-side reachability, and policy ownership.
Limit: does not prove every remote cloud workflow unless that path is separately tested.
Retest: Border Router replaced, controller changed, network policy changed, or service discovery behavior changed.
27.17 Knowledge Check: Role Responsibility
27.18 Common Architecture Mistakes
Mixing Leader and controller
The Thread Leader manages network state. A Matter controller, app, or dashboard manages application behavior.
Counting every device as mesh backbone
End devices can be Thread members without forwarding traffic for others.
Treating REED as current router
Router eligible means capable of promotion, not proof that the device is currently routing.
Overclaiming Border Router success
The Border Router boundary needs evidence for the exact route, service, and policy being claimed.
Ignoring sleepy-device latency
Power-saving behavior must match the application response requirement.
Using product names as evidence
A product capability list is not the same as observing this deployment’s role and boundary behavior.
27.19 Architecture Review Checklist
Before accepting a Thread architecture claim, confirm that the record answers these questions:
- Which devices are carrying mesh-routing responsibility?
- Which devices are end devices, and which parent assumptions do they depend on?
- Which device or devices provide the Border Router boundary for this claim?
- Which parts of the claim are Thread network evidence and which are application evidence?
- Which role, route, service, placement, power, or firmware change triggers retest?
- Which chapter owns the next detail: architecture, operations, deployment, security, Matter, or comparison?
27.20 Match Thread Roles
27.21 Order a Thread Architecture Review
27.22 Summary
Thread network architecture is a role-and-boundary review. Routers, router-eligible devices, full end devices, minimal end devices, sleepy end devices, Leaders, and Border Routers each prove different things. A strong chapter record does not simply say that Thread is a mesh. It explains which devices are carrying mesh responsibility, which devices depend on parents, which Border Router boundary is being claimed, and which evidence would need retest after a change.
Keep architecture separate from operations and application behavior. Architecture explains responsibilities and boundaries; operations verifies runtime behavior; Matter or another application layer verifies user-facing behavior.
27.23 Key Takeaway
Thread Network Architecture Evidence should validate Thread topology with leader, router, end-device, border-router, partition, route, power, and deployment evidence.
27.24 Concept Relationships
Thread architecture
Connects roles, parent-child relationships, mesh routing, Border Router boundaries, and evidence ownership.
Router
Provides mesh-forwarding responsibility and may host child devices.
End device
Communicates through a parent and should not be counted as mesh backbone unless promoted to a routing role.
Border Router
Connects a Thread mesh to another IP network, with service and policy evidence reviewed separately.
Leader
Coordinates Thread network state inside a partition and can change without changing the application owner.
Architecture record
Captures claim, evidence, limits, owner, and retest trigger.
27.25 What’s Next
Next, continue from roles and boundaries into runtime behavior:
- Thread Operation and Implementation reviews how Thread behavior is introduced across the implementation chapter set.
- Thread Network Operations Evidence reviews formation, role behavior, parent-child behavior, addressing, low-power operation, and recovery evidence.
- Thread Implementation Deployment Evidence reviews Border Router, release, staging, and deployment evidence.
- Thread Protocol Comparison compares Thread with nearby IoT networking choices while keeping claims bounded.
- Matter Overview separates Thread network evidence from Matter application interoperability evidence.