Sammy the Sensor just moved into a Thread neighborhood! Max the Microcontroller introduced everyone: “The Border Router is like the town’s post office – it connects us to the outside world through Wi-Fi. The Leader is like the mayor who keeps everything organized. Routers are the mail carriers who are always awake, delivering messages around the neighborhood.” Bella the Battery yawned: “And I am a Sleepy End Device – I only wake up once a minute to check if anyone sent me a letter, so I can last 10 years on my tiny coin battery!” Lila the LED added: “Our neighborhood can have up to 250 residents and 32 mail carriers. If a mail carrier moves away, another neighbor can step up to take their place – that is what REED means!”
By the end of this section, you will be able to:
Thread networks consist of different device types, each with specific roles:
Thread networks use a mesh architecture where devices cooperate to relay messages. Different devices play different roles: routers forward traffic, end devices sleep to save power, and border routers connect the Thread mesh to the wider internet. Understanding these roles helps you design efficient, reliable smart home networks.
The Thread network architecture enables seamless connectivity from constrained IoT devices all the way to cloud services. The Border Router bridges between the Thread mesh (802.15.4 radio) and IP infrastructure (Wi-Fi/Ethernet), translating between the compact Thread packets and standard IPv6 traffic while maintaining end-to-end addressing.
The mesh topology provides inherent reliability through path redundancy. If any router fails, the network automatically discovers alternative routes through neighboring routers, maintaining connectivity without manual intervention. This self-healing behavior is critical for smart home reliability.
Role: Connects Thread network to other IP networks (Wi-Fi, Ethernet, Internet)
Functions:
Examples:
Requirements:
Role: Manages router ID assignment and network partition merging
Functions:
Characteristics:
Important: Applications don’t need to know which device is leader
Role: Forward packets and provide routing services
Functions:
Characteristics:
Examples:
Role: End device that can be promoted to router if needed
Functions:
Characteristics:
Example Scenario:
Role: End device with full rx-on-when-idle capability
Functions:
Characteristics:
Examples:
Role: Battery-powered devices that sleep to conserve power
Functions:
Characteristics:
Polling Intervals:
Examples:
| Type | Always On | Can Route | Can Be Leader | Power | Use Case |
|---|---|---|---|---|---|
| Border Router | Yes | Yes | Yes | Mains | Gateway to internet |
| Leader | Yes | Yes | Yes | Mains | One per network (auto) |
| Router | Yes | Yes | Yes | Mains | Mesh backbone |
| REED | Yes | If promoted | If promoted | Mains | Flexible role |
| FED | Yes | No | No | Mains/Battery | Low latency |
| MED/SED | No (sleeps) | No | No | Battery | Ultra-low power |
Explore how Thread networks self-organize with different device roles. Adjust network size to see how routers form the mesh backbone, end devices attach to parents, and the leader coordinates the network. Simulate leader failure to watch automatic failover in action.
How to Use This Demo:
Key Observations:
Q1: Which Thread device role serves as the gateway between the Thread mesh network and Wi-Fi/Internet?
C) Border Router – The Border Router connects the Thread mesh (802.15.4 radio) to other IP networks (Wi-Fi or Ethernet), providing NAT64/DNS64 translation, service discovery, and firewall protection. It requires two radios: Thread and Wi-Fi/Ethernet.
Q2: What happens when a Thread Router that is parent to several SEDs loses power?
B) The SEDs automatically search for and attach to a nearby router within 1-2 minutes – When SEDs detect their parent is gone (polls fail), they enter orphan mode and scan for router advertisements (sent every ~32 seconds). They attach to the strongest available router autonomously, with no re-commissioning needed.
Thread and Zigbee both create 802.15.4 mesh networks, but their architectures differ fundamentally. Zigbee uses application-layer profiles (ZCL) with a proprietary network layer, requiring a Zigbee-specific hub. Thread uses IPv6 natively, meaning Thread devices have real IP addresses and can communicate directly with cloud services through a Border Router – no protocol translation needed. For new smart home deployments, Thread’s IP-native approach is simpler to integrate with modern cloud platforms. However, Zigbee’s 20+ years of deployed devices and mature ecosystem means many existing products remain Zigbee-only. Matter solves this by supporting both Thread and Wi-Fi as transport layers with a unified application layer. See Matter Overview for how Matter bridges these ecosystems.
Thread devices automatically determine their role in the network based on capabilities and network needs:
Role Selection Criteria (Device Join Process):
mRxOnWhenIdle = true → Can be Router/FED (receiver always on)mRxOnWhenIdle = false → Must be MED/SED (sleeps to save battery)mDeviceMode flags specify router-eligible, secure, full/minimal network dataRouter Promotion Sequence:
Step 1: Mains-powered device joins as child (End Device)
Device → MLE Parent Request
Router → MLE Parent Response (you're my child, Child ID = 0x05)
Device receives RLOC16: 0x2005 (Router 0x20, Child 0x05)Step 2: Device announces router capability
Device → MLE Child Update Request (includes router-capable flag)
Parent → Forwards to LeaderStep 3: Leader evaluates network needs
Leader checks:
- Current router count: 18/32 (slots available)
- Average hop count: 2.8 (acceptable)
- Parent router child count: 15 (high, could use more routers)
Decision: Promote device to RouterThread’s router density calculation balances area coverage with child device capacity. The minimum router count formula combines geometric coverage with the child-per-router ratio:
\[ \text{Min Routers} = \max\left(\left\lceil \frac{\text{Area}}{\pi r^2} \right\rceil, \left\lceil \frac{N_{\text{devices}}}{C_{\text{max}}} \right\rceil\right) \]
For a 200 m² home with 15m router range and 60 end devices (child capacity \(C_{\text{max}} = 8\)):
\[ \text{Coverage:} \quad \left\lceil \frac{200}{\pi \times 15^2} \right\rceil = \left\lceil \frac{200}{706.9} \right\rceil = 1 \text{ router} \] \[ \text{Capacity:} \quad \left\lceil \frac{60}{8} \right\rceil = 8 \text{ routers} \] \[ \text{Min Routers} = \max(1, 8) = 8 \text{ routers (capacity-limited)} \]
Add 2× redundancy factor for reliability: \(8 \times 2 = 16\) routers recommended. This ensures no single router failure leaves devices orphaned.
Step 4: Leader sends promotion
Leader → MLE Router Promotion (to device)
Message includes: New Router ID (0x14, available slot)Step 5: Device becomes Router
Device updates RLOC16: 0x2005 → 0x5000 (Router 0x14, now a parent not child)
Device sends MLE Advertisement (announces router status to network)
Other devices can now select this device as parentREED Holding Pattern (Router Count = 32): - Device joins as REED (Router-Eligible End Device) - Acts like End Device but monitors network health - If any Router fails/leaves → REED automatically promoted - No user intervention needed (self-healing)
Demotion (Rare): - If router has zero children and network is over-populated (>24 routers) - Leader may demote router to REED to reduce routing overhead - Router gracefully transitions children to other routers first
Scenario: You’re planning a Thread network for a 3-bedroom apartment with these devices:
Mains-Powered Devices (Always-on power source): - 12 smart light bulbs (living room, bedrooms, kitchen, bathrooms) - 6 smart plugs (TV, coffee maker, lamp, desk, fan, charger) - 1 HomePod Mini (Border Router + potential Leader)
Battery-Powered Devices:
Your Tasks:
Design Output Template:
Thread Network Plan:
├── Border Router: HomePod Mini (Leader candidate, high weighting)
├── Routers (18 devices):
│ ├── Smart Bulbs (12): Always-on mesh backbone
│ └── Smart Plugs (6): Strategic placement for coverage
├── FEDs (1 device):
│ └── Smart Lock: Always-listening for instant response
├── MEDs (4 devices):
│ └── Motion Sensors: 10-30s poll for timely automation
├── SEDs (13 devices):
│ ├── Door/Window Sensors: 60s poll + wake-on-open
│ ├── Temperature Sensors: 300s poll (low latency needs)
│ └── Leak Detectors: 120s poll + wake-on-water
└── REEDs (0 devices):
└── None (router count <32)
Network Metrics:
- Total devices: 37
- Routers: 19/32 (59% of limit, 13 slots free for expansion)
- Average hop count: 2-3 (estimated)
- Coverage: Excellent (19 routers for 1,200 sq ft)
- Battery life: SEDs 7-10 years, MEDs 1-2 years, FED 6-12 monthsWhat to Observe:
| Concept | Relationship | Connected Concept |
|---|---|---|
| Border Router | Also Acts As | Router and potential Leader (dual role) |
| Leader Election | Based On | Weighting formula (prefers Border Router for internet access) |
| REED (Router Eligible) | Promotes To | Router when vacancy occurs (automatic failover) |
| SED Poll Interval | Balances | Battery life (longer poll) vs latency (shorter poll) |
| Router Count Limit (32) | Constrains | Network topology and mesh density |
This chapter covered Thread network architecture and device roles:
::
::
| Next Topic | Description |
|---|---|
| Thread Operation and Implementation | Network formation, MLE protocol, and how devices join and maintain the mesh |
| Thread Deployment Guide | Real-world deployment examples, common pitfalls, and best practices |
| Thread Security and Matter | Secure commissioning, network credentials, and Matter integration |
| Thread Review: Topology and Roles | Detailed role selection decision tree and topology review exercises |
| Matter Overview | How Matter uses Thread as a transport layer with a unified application protocol |