53 Thread Topology Review
Sammy the Sensor asked: “How do I know what role to play in the Thread neighborhood?” Max the Microcontroller created a decision tree: “First question: are you plugged into the wall? If yes, you can be a Router (always awake, delivering messages). If no, second question: how fast do you need to respond?” Bella the Battery said: “I am a door sensor on a coin battery. I only need to report when someone opens the door, so I am a Sleepy End Device – I check my mailbox every 60 seconds and last 10 years!” Lila the LED added: “I am always plugged in as a smart bulb, so I am a Router – I help deliver messages for my neighbors while providing light. And if we need more Routers, a REED device can automatically step up to become one!”
53.1 Learning Objectives
By the end of this chapter, you will be able to:
- Differentiate Thread’s Device Roles: Distinguish the responsibilities and relationships among Border Routers, Leaders, Routers, and End Devices within Thread’s hierarchical mesh
- Select Appropriate Device Roles: Determine the correct Router, REED, SED, MED, or FED role for a given device based on its power source and response requirements
- Evaluate Device Type Trade-offs: Analyze decision trees to justify optimal device type choices for specific IoT deployment scenarios
- Design Network Capacity Plans: Calculate device distributions and router placement within Thread’s 32-router and 250-device limits for real-world deployments
Thread networks organize devices into specific roles based on their power source and functionality. Think of it like a postal delivery system:
- Border Router = Post office (connects the neighborhood to the outside world)
- Leader = Postmaster (manages operations)
- Routers = Mail carriers (always working, delivering messages)
- End Devices = Mailboxes (receive messages but don’t deliver them)
This chapter explains how to choose the right role for each device in your network.
53.2 Prerequisites
Required Reading:
- Thread Overview - Core Thread concepts
- Thread Operation - Network formation
- 802.15.4 Fundamentals - Physical layer
Technical Background:
- Mesh networking concepts
- IPv6 addressing basics
- Power consumption considerations for IoT devices
Estimated Time: 25 minutes
53.3 Thread Network Topology Overview
Thread’s hierarchical mesh architecture optimizes battery life and network reliability. The architecture balances three key requirements:
- Reliability: Self-healing mesh with no single point of failure
- Low Power: Battery-powered devices can sleep for extended periods
- IP Connectivity: Native IPv6 addressing for internet integration
53.3.1 Core Architecture Components
A Thread network consists of several device types working together:
| Component | Function | Power Source | Typical Examples |
|---|---|---|---|
| Border Router | IPv6 gateway to internet | Mains (always-on) | Smart hubs, Wi-Fi routers |
| Leader | Network manager | Mains (always-on) | Any router (elected) |
| Router | Mesh backbone | Mains (always-on) | Light bulbs, switches, plugs |
| REED | Router-eligible device | Either | Smart plugs, sensors |
| SED | Sleepy End Device | Battery | Door sensors, temp sensors |
| MED | Minimal End Device | Battery | Leak detectors |
| FED | Full End Device | Mains | Smoke alarms |
53.3.2 Network Hierarchy
The Thread network hierarchy operates as follows:
Internet/Cloud Layer:
- Cloud platforms (Matter Controller, mobile apps)
- Connectivity via Wi-Fi or Ethernet
Thread Mesh (fdxx:xxxx:xxxx:xxxx::/64 Mesh-Local ULA):
- Border Router: Gateway providing Thread to IP translation
- Leader: Network manager with partition ID assignment
- Routers: Mesh backbone forwarding packets (20-40 mA)
- End Devices: Children attached to parent routers
Network Limits:
- Maximum 32 routers per network
- Maximum 250 total devices per network
53.4 Device Type Selection
Choosing the correct device type is critical for network performance and battery life. The selection depends primarily on power source and response time requirements.
53.4.1 Decision Process
Use this decision process to select the appropriate Thread device type:
Step 1: Determine Power Source
- Battery-powered: Consider SED, MED, or REED
- Mains/USB-powered: Consider Router, REED, or FED
Step 2: Evaluate Response Requirements
- Minutes acceptable: SED (best battery life)
- Seconds needed: MED (balanced)
- Instant required: FED or Router
Step 3: Consider Routing Capability
- Should route traffic: Router or REED
- End device only: SED, MED, or FED
53.4.2 Detailed Device Type Characteristics
Sleepy End Device (SED):
- Sleeps 99%+ of time to conserve power
- Wakes periodically to poll parent for messages
- Poll intervals: 60 seconds to 5 minutes typical
- Battery life: 7-10+ years on coin cell
- Best for: Door sensors, window sensors, temperature sensors
- Trade-off: High latency for incoming messages
Minimal End Device (MED):
- Sleeps but polls more frequently than SED
- Poll intervals: 5-30 seconds typical
- Battery life: 1-5 years depending on poll rate
- Best for: Leak detectors, motion sensors needing faster response
- Trade-off: Shorter battery life than SED
Full End Device (FED):
- Always listening (radio always on)
- Zero latency for incoming messages
- Requires mains power (battery depletes in days/weeks)
- Best for: Smoke alarms, security sensors
- Trade-off: Cannot use battery power
Router-Eligible End Device (REED):
- Starts as end device
- Can promote to router if network needs more routing capacity
- Useful for devices with larger batteries or occasional mains power
- Best for: Smart plugs, devices that may be plugged in
- Trade-off: Uncertain power consumption (depends on promotion)
Router:
- Always on, always forwarding
- Forms the mesh backbone
- Requires mains power (20-40 mA continuous)
- Best for: Light bulbs, switches, plugs, smart appliances
- Trade-off: Highest power consumption
53.5 End Device Configuration
End devices attach to routers as children and depend on their parent router for network connectivity.
53.5.1 End Device Comparison
| Device Type | Example | Poll Interval | Battery Life | Power Source |
|---|---|---|---|---|
| REED | Router-eligible | N/A (can promote) | Varies | Mains/Battery |
| SED | Door/Window Sensor | 60s | 10 years | Battery |
| MED | Leak Detector | 5s | 2 years | Battery |
| FED | Smoke Alarm | Always listening | N/A | Mains |
53.5.2 Poll Interval Selection
The poll interval dramatically affects battery life:
| Poll Interval | Use Case | Approximate Battery Life (CR2032) |
|---|---|---|
| 5 minutes | Temperature, humidity | 15+ years |
| 60 seconds | Door, window, motion | 10-12 years |
| 10 seconds | Leak detector | 3-5 years |
| 5 seconds | Fast-response sensor | 1-2 years |
| Always on | Critical sensors | Days-weeks (use mains) |
53.5.3 Parent-Child Relationship
End devices maintain a parent-child relationship with routers:
- Attachment: End device discovers and attaches to a parent router
- Message Queuing: Parent queues messages for sleeping children
- Polling: Child wakes, polls parent for queued messages
- Reattachment: If parent fails, child finds new parent automatically
53.6 Network Capacity Planning
Thread networks have specific limits that affect deployment planning.
53.6.1 Hard Limits
- 32 routers maximum: Protocol-defined limit enforced in the RLOC16 addressing scheme
- 250 devices maximum: Protocol design limit per network
- Multiple networks: Required for deployments exceeding 250 devices
53.6.2 Router Placement Guidelines
Optimal router placement ensures good mesh coverage:
| Deployment Size | Routers Needed | Coverage Notes |
|---|---|---|
| Small home (<1,000 sq ft) | 8-12 | 1 router per 80-125 sq ft |
| Medium home (1,000-2,500 sq ft) | 16-20 | 1 router per 50-150 sq ft |
| Large home (2,500+ sq ft) | 24-28 | Consider multiple networks |
53.6.3 Device Distribution Example
For a 150-device deployment:
| Role | Count | Percentage | Function |
|---|---|---|---|
| Border Router | 1 | 0.7% | Internet gateway |
| Leader | 1 (from routers) | N/A | Network management |
| Routers | 20 | 13% | Mesh backbone |
| REEDs | 10 | 7% | Backup routing |
| SEDs | 100 | 67% | Battery sensors |
| MEDs | 15 | 10% | Fast-response sensors |
| FEDs | 4 | 2.6% | Critical sensors |
53.6.4 Capacity Planning Formula
Use this formula for initial router estimation:
Recommended Routers = max(16, ceil(Total_Devices / 8))For example:
- 50 devices: max(16, ceil(50/8)) = max(16, 7) = 16 routers
- 200 devices: max(16, ceil(200/8)) = max(16, 25) = 25 routers
The 8:1 device-to-router ratio provides mesh redundancy while limiting router density. For a 150-device smart building: \(R = \max(16, \lceil 150/8 \rceil) = \max(16, 19) = 19\) routers. Worked example: With 19 routers covering 5,000 sq ft, each router covers ~263 sq ft. At 15m (50 ft) range, one router covers \(\pi \times (15m)^2 = 707\) sq m (7,600 sq ft), giving ~29× theoretical coverage redundancy. In practice, walls and interference reduce this to ~3-5× effective redundancy, which enables reliable self-healing when any single router fails.
53.7 Knowledge Check
In a Thread network with 200 devices, what is the maximum number that can be routers (always-on devices that forward packets)?
Options:
- 16
- 32
- 64
- 200 (all devices can be routers)
Correct: B) 32
Thread Network Limits:
- Maximum devices: 250 per network
- Maximum routers: 32 per network (fixed limit)
- Minimum routers: 16 (recommended for good mesh coverage)
Why 32 Routers Maximum?
Router ID Space: Thread uses 5-bit router ID (part of RLOC addressing). 5 bits = 2^5 = 32 possible values (IDs 0-31).
Mesh Scalability: Each router must maintain routing table. 32 routers = manageable routing complexity.
Design Philosophy: 16-32 always-on routers form stable backbone; 218-234 sleepy end devices attach to routers.
Automatic Router Management: If you try to add 33rd router, it stays as REED (Router-Eligible End Device). If a router fails, REED automatically promotes to router.
Thread supports “software upgrade” to existing IEEE 802.15.4 hardware (Zigbee chips). What makes this possible, and what are the limitations?
Options:
- Same PHY/MAC layer (802.15.4); requires firmware update for IPv6 stack and Thread protocols; can’t run Zigbee and Thread simultaneously
- Thread uses software-defined radio to emulate 802.15.4; any 2.4 GHz radio can run Thread via firmware
- Thread and Zigbee are interoperable protocols; devices can communicate across both networks after upgrade
- Only Thread-certified hardware with dual-mode radios can switch; standard 802.15.4 chips cannot be upgraded
Correct: A) Same PHY/MAC layer (802.15.4); requires firmware update for IPv6 stack and Thread protocols; can’t run Zigbee and Thread simultaneously
Thread and Zigbee share the same physical foundation:
What’s shared (no hardware change needed):
- IEEE 802.15.4 PHY: 2.4 GHz radio, 250 kbps, DSSS modulation
- IEEE 802.15.4 MAC: CSMA/CA, frame format, addressing
What’s different (firmware change required):
- Network Layer: Thread uses IPv6/6LoWPAN; Zigbee uses proprietary network layer
- Routing: Thread uses MLE (Mesh Link Establishment) with distance-vector routing; Zigbee uses AODV/tree routing
- Application Layer: Thread uses Matter/CoAP; Zigbee uses ZCL (Zigbee Cluster Library)
- Security: Thread uses DTLS + MAC; Zigbee uses different key management
Upgrade process:
- Flash new firmware with Thread stack (replacing Zigbee stack)
- Commission device to Thread network
- Device now operates as Thread, not Zigbee
Limitations:
- Not simultaneous: Device runs Thread OR Zigbee, not both (single radio, conflicting network stacks)
- No interoperability: Thread devices can’t communicate with Zigbee devices (different protocols above MAC)
- Memory requirements: Thread needs ~100-200 KB flash, ~20-50 KB RAM for IPv6 stack - some minimal Zigbee chips lack sufficient memory
Real-world: Many vendors offer dual-firmware chips (selectable at manufacturing or via OTA).
Scenario: You are designing a Thread network for a 10,000 sq ft commercial office building with 180 devices across 3 floors. Calculate the optimal router placement and device distribution.
Given:
- Building: 3 floors, 10,000 sq ft (3,333 sq ft per floor)
- Devices: 180 total (60 per floor)
- 24 smart light fixtures (mains-powered, ceiling)
- 12 HVAC sensors (USB-powered from thermostats)
- 120 occupancy sensors (battery-powered)
- 12 door locks (large battery, occasional USB charging)
- 12 window sensors (coin cell battery)
- Router range: 15m (50 ft) indoor
- Thread limits: 250 devices max, 32 routers max
Step 1: Calculate Coverage Requirements
Floor area: 3,333 sq ft per floor
Router coverage: π × (50 ft)² = 7,850 sq ft per router
Minimum routers per floor: 3,333 / 7,850 = 0.42 routers
With 2x redundancy: 0.42 × 2 = 0.84 → round to 1 router per floor (minimum)
Recommended for mesh resilience: 6-8 routers per floorStep 2: Classify Device Roles by Power Source
Mains-Powered (potential routers):
- 24 light fixtures (always on, ceiling-mounted)
- 12 HVAC sensors (USB-powered, always on)
Total: 36 devices can be routers
Battery-Powered (end devices only):
- 120 occupancy sensors (SED, 60s poll)
- 12 window sensors (SED, 300s poll)
Total: 132 end devices
Hybrid (REED - can promote to router if needed):
- 12 door locks (large battery, occasional USB power)Step 3: Design Router Topology
Floor 1 (ground floor, high traffic):
- 10 light fixtures as routers
- 4 HVAC sensors as routers
- 1 Border Router (Google Nest Hub in reception)
Total: 15 routers
Floor 2-3 (office floors):
- 7 light fixtures as routers per floor
- 4 HVAC sensors as routers per floor
Total: 11 routers per floor = 22 routers
Grand Total: 15 + 22 = 37 potential routers
Thread Limit: 32 routers maximum
Solution: Use 32 routers (15 on Floor 1, 8-9 per other floor)
Remaining 5 devices: Configure as REEDs (backup routing)Step 4: Verify Network Capacity
Device Distribution:
- 1 Border Router
- 31 Routers (light fixtures + HVAC sensors)
- 5 REEDs (door locks configured as backup)
- 132 SEDs (occupancy + window sensors)
- 11 MEDs (door locks not configured as REED)
Total: 180 devices (within 250 limit)
End Devices per Router: 143 end devices / 32 routers = 4.5 children per router (excellent balance)Step 5: Calculate Worst-Case Path Length
Building dimensions: ~115 ft × 87 ft (approximation for 3,333 sq ft)
Router spacing: 50 ft coverage, place every ~35 ft for overlap
Worst-case path:
- Corner device to Border Router
- Maximum hops: 4 (corner → router1 → router2 → router3 → BR)
- Latency: 10-20ms per hop = 40-80ms total (acceptable)Result: Optimal configuration uses 32 routers distributed across 3 floors (15/9/8), with 5 REEDs as backup and 143 end devices. Each router serves an average of 4.5 children, well within capacity limits. Mesh provides 2x coverage redundancy on each floor, enabling self-healing if any router fails. Maximum 4-hop path length keeps latency under 100ms for all devices.
Key Insight: Commercial Thread networks require careful router density planning. While 32 routers is the maximum, this building needs exactly 32 to achieve reliable coverage across 10,000 sq ft with 2x redundancy. Smaller deployments (under 5,000 sq ft) typically need only 16-24 routers. Always calculate coverage first (area / router range), then add redundancy factor (2x recommended), then verify against the 32-router limit.
53.8 Key Concepts
- Thread Hierarchy: Border Router > Leader > Routers > End Devices (REED/SED/MED/FED)
- 32-Router Limit: Enforced by 5-bit router ID space in RLOC addressing
- 250-Device Limit: Maximum devices per Thread network partition
- Device Role Selection: Based on power source, response requirements, and routing needs
- Poll Interval Trade-off: Longer intervals = better battery life but higher latency
- REED Promotion: Router-eligible devices automatically promote when network needs more routers
- Mesh Backbone: Mains-powered routers form always-on network infrastructure
Common Pitfalls
Thread device roles (Leader, Router, End Device) are network-layer roles assigned dynamically by the Thread stack — they are independent of what the device does at the application layer. A temperature sensor can be a Thread Router.
Sleepy End Devices (SEDs) poll their parent periodically, introducing latency equal to the poll interval (typically 3–10 seconds). If near-real-time responsiveness is needed, use a Full End Device or Router that keeps its radio on.
Networks with too few routers create deep hierarchies with excessive hop counts. Plan at least 1 router per 8–10 devices and ensure physical distribution of routers to prevent topology bottlenecks.
53.9 Summary
This chapter covered Thread network topology and device roles:
Network Architecture:
- Thread uses hierarchical mesh with Border Router, Leader, Routers, and End Devices
- Border Router provides IPv6 gateway to internet (Wi-Fi/Ethernet)
- Leader manages network operations (elected from routers)
- 16-32 routers form mesh backbone (mains-powered)
Device Types:
- Router: Always-on, forwards packets, mains-powered
- REED: Can promote to router if needed, backup routing
- FED: Always listening, instant response, mains-powered
- MED: Polls frequently (5-30s), 1-5 year battery
- SED: Polls infrequently (60s-5min), 7-10+ year battery
Capacity Planning:
- Maximum 32 routers per network (5-bit router ID)
- Maximum 250 devices per network
- Recommended 1 router per 6-8 end devices
- Multiple networks for deployments >250 devices
Device Selection:
- Power source determines if device can be router
- Response requirements determine SED vs MED vs FED
- Poll interval directly affects battery life
53.10 Knowledge Check
::
::
53.11 What’s Next
| Chapter | Focus |
|---|---|
| Thread Review: Protocol Stack and Comparison | How Thread’s protocol layers work and how Thread compares to Zigbee |
| Thread Review: Planning and Optimization | Network planning strategies and performance optimization techniques |
| Thread Security and Matter Integration | Thread’s DTLS security model and Matter application layer |
| Thread Deployment Guide | Practical deployment considerations for real-world Thread networks |
| Matter Overview | The application-layer standard that runs over Thread for smart home interoperability |