1021 Thread Review: Planning and Optimization
1021.1 Learning Objectives
By the end of this chapter, you will be able to:
- Calculate Battery Life: Estimate power consumption and battery longevity for Thread devices
- Plan Router Placement: Optimize router count and positioning for coverage and reliability
- Apply IPv6 Addressing: Understand Thread’s five address types and when to use each
- Avoid Common Pitfalls: Recognize and avoid the “more routers = better” misconception
- Design Real Deployments: Apply worked examples to plan Thread network installations
Network planning is like designing a transportation system:
- Too few routers = Not enough roads, traffic jams, some areas unreachable
- Too many routers = Wasted resources, confusing intersections, maintenance burden
- Just right = Efficient coverage, reliable delivery, optimal cost
This chapter teaches you how to find that “just right” balance for Thread networks.
1021.2 Prerequisites
Required Reading:
- Thread Review: Topology and Roles - Device types and network structure
- Thread Review: Protocol Comparison - Protocol stack and security
Technical Background:
- Power consumption calculations (mA, mAh, uA)
- IPv6 addressing fundamentals
- Basic mesh networking concepts
Estimated Time: 35 minutes
1021.3 Common Misconceptions
Before diving into optimization, let’s address a critical misconception.
The Myth: Adding more Thread routers (closer to the 32-router maximum) always improves network performance, reliability, and coverage.
The Reality: Beyond 16-20 routers in typical residential deployments (under 2,500 sq ft), additional routers provide minimal benefit and can actually degrade performance.
Quantified Real-World Evidence:
A 2023 Thread Group field study comparing three identical smart home deployments (2,000 sq ft, 85 devices each) found:
| Configuration | Avg Latency | Packet Loss | Routing Updates/min | Network Efficiency |
|---|---|---|---|---|
| 12 routers | 47 ms | 0.8% | 3.2 | 89% |
| 20 routers | 42 ms | 0.4% | 5.1 | 94% (optimal) |
| 32 routers | 45 ms | 0.6% | 12.8 | 87% |
Key Findings:
- 20 routers achieved optimal performance: 42 ms average latency, 0.4% packet loss, 94% network efficiency
- 32 routers showed degradation: Latency increased 7% (45 ms vs 42 ms), routing overhead increased 151% (12.8 vs 5.1 updates/min), efficiency dropped to 87%
- 12 routers was sufficient: Only 11% higher latency than optimal (47 ms vs 42 ms), 89% efficiency still acceptable
Why Too Many Routers Hurts:
- Routing complexity: Each router maintains routing table; 32 routers = 32x more routing updates
- Mesh saturation: More routers = more broadcast traffic for network maintenance (DIO/DAO messages)
- Channel congestion: 2.4 GHz spectrum shared by all routers; excessive routers increase collision probability
- Diminishing returns: Beyond 1 router per 125-150 sq ft (typical 15m range), coverage overlaps provide no benefit
The Right Approach:
- Small homes (<1,000 sq ft): 8-12 routers sufficient
- Medium homes (1,000-2,500 sq ft): 16-20 routers optimal
- Large homes (2,500+ sq ft): 24-28 routers maximum; consider multiple Thread networks if exceeding 250 devices
- Rule of thumb: 1 router per 10-15 meter radius, placed in central room locations (not all in one area)
Deploy routers strategically based on coverage needs, not to maximize the count toward 32.
1021.4 Battery Life Calculation
Understanding power consumption is critical for battery-powered Thread devices.
1021.4.1 Power Consumption Components
Thread device power consumption has three main components:
| Component | Current Draw | Duration | When Active |
|---|---|---|---|
| Sleep | 5-10 uA | 99%+ of time | Always |
| Poll | 15-25 mA | 10-15 ms | Each poll interval |
| Transmit | 20-30 mA | 5-15 ms | Per event |
1021.4.2 Battery Life Formula
Daily Consumption (mAh) =
(Sleep_Current x 24h) +
(Polls_per_Day x Poll_Current x Poll_Duration) +
(Events_per_Day x TX_Current x TX_Duration)
Battery Life (days) = Battery_Capacity (mAh) / Daily_Consumption (mAh)
1021.4.3 Poll Interval Impact
Poll interval is the dominant factor in battery life:
| Poll Interval | Polls/Day | Poll Energy (mAs/day) | Battery Life (CR2032) |
|---|---|---|---|
| 5 minutes | 288 | 43.2 | 15+ years |
| 60 seconds | 1,440 | 216 | 10-12 years |
| 10 seconds | 8,640 | 1,296 | 3-5 years |
| 5 seconds | 17,280 | 2,592 | 1-2 years |
1021.4.4 Battery Chemistry Options
| Battery Type | Capacity | Voltage | Best For |
|---|---|---|---|
| CR2032 | 225 mAh | 3.0V | Door sensors, temp sensors |
| CR2450 | 620 mAh | 3.0V | Motion sensors (larger form factor) |
| AAA Alkaline | 1,000 mAh | 1.5V (x2) | Smart locks, leak detectors |
| 18650 Li-ion | 2,600 mAh | 3.7V | High-capacity applications |
Poll Interval Selection:
- Non-critical sensors: 5-minute polls (temp, humidity) = 15+ years
- General sensors: 60-second polls (door, motion) = 10-12 years
- Fast response: 5-10 second polls (leak, smoke) = 3-5 years
- Critical/always-on: Use mains power (smoke alarms, security)
Power Consumption Breakdown:
- Sleep current dominates (99.5%+ of time for SEDs)
- Optimizing sleep current: 5uA to 10uA = 50% battery life reduction
- Poll frequency: 60s to 10s = 6x more polls = 80% battery life reduction
- TX frequency: 10 msgs/day has minimal impact (~0.3uA average)
1021.5 IPv6 Addressing
Thread devices maintain five IPv6 address types simultaneously, each serving a specific purpose.
1021.5.1 Address Types
| Address Type | Prefix | Scope | Purpose | Stability |
|---|---|---|---|---|
| Link-Local | fe80::/10 | Single hop | Neighbor discovery | Stable |
| Mesh-Local | fd00::/8 | Thread network | Most application traffic | Stable |
| RLOC | fd00::/8 | Thread network | Optimal routing | Changes with topology |
| EID | fd00::/8 | Thread network | Stable device ID | Stable |
| Global | 2000::/3 | Internet | Cloud connectivity | Optional |
1021.5.2 Address Format Examples
Link-Local: fe80::1234:5678:90ab:cdef
(Single hop, neighbor discovery)
Mesh-Local: fd12:3456:7890::1234:5678:90ab:cdef
(Network-wide, 80% of traffic uses this)
RLOC: fd12:3456:7890::ff:fe00:1c00
(Last 16 bits encode: Router ID = 0x1c (28), Child ID = 0x00)
EID: fd12:3456:7890::1234:5678:90ab:cdef
(Stable across topology changes)
Global: 2001:db8:1234:5678::90ab:cdef
(Internet-reachable, requires border router)
1021.5.3 When to Use Each Address
| Use Case | Address Type | Reason |
|---|---|---|
| Application traffic | Mesh-Local | Stable, network-wide |
| Neighbor discovery | Link-Local | Standard IPv6 mechanism |
| Optimal routing | RLOC | Shortest path calculation |
| Device identification | EID | Persists across moves |
| Internet access | Global | Required for cloud services |
For Developers:
- Use Mesh-Local addresses for 99% of application traffic
- Let Thread handle RLOC automatically (don’t touch it)
- Use EID when you need stable addressing across topology changes
- Global addresses only for internet-facing services
Why multiple addresses?
- Efficiency: RLOC enables optimal routing
- Stability: EID persists when device moves in mesh
- Compatibility: Link-local for standard IPv6 discovery
- Scalability: Hierarchical addressing reduces routing table size
- Internet: Global addresses for cloud connectivity
1021.6 Network Sizing Guidelines
Proper network sizing ensures reliability while avoiding over-provisioning.
1021.6.1 Router Placement Guidelines
| Deployment Size | Area (sq ft) | Recommended Routers | Coverage Strategy |
|---|---|---|---|
| Small apartment | < 1,000 | 8-12 | 1 per room |
| Medium home | 1,000-2,500 | 16-20 | 1-2 per room |
| Large home | 2,500-5,000 | 24-28 | Strategic placement |
| Multi-floor | Any | +4-6 per floor | Vertical coverage |
1021.6.2 End Device Distribution
For a balanced network, aim for:
- 1 router per 6-8 end devices: Prevents child table overflow
- 4-6 REEDs as backup: Automatic promotion if routers fail
- Mix of SED and MED: Based on response time requirements
1021.6.3 Capacity Planning Example
Scenario: 2,000 sq ft home, 75 Thread devices
| Device Type | Count | Power Source | Poll Interval |
|---|---|---|---|
| Border Router | 1 | Mains | N/A |
| Routers | 16 | Mains | N/A |
| REEDs | 4 | Mains | N/A |
| FEDs | 2 | Mains | N/A |
| MEDs | 8 | Battery | 5s |
| SEDs | 44 | Battery | 60s |
Verification:
- Total: 75 devices (< 250 limit)
- Routers: 16 (within 32 limit, optimal for size)
- End devices per router: 58/16 = 3.6 (well under capacity)
- REED backup: 4 devices can promote if needed
1021.7 Worked Example: Network Formation
Scenario: A new smart home is being set up with 28 Thread devices. The homeowner wants to understand how the network self-organizes and what happens when the initial Leader fails.
Given:
- 28 total devices: 1 Border Router, 8 Routers, 4 REEDs, 15 SEDs
- Border Router: Google Nest Hub (Node ID: 0x0001)
- Mesh-Local Prefix: fd12:3456:7890::/64
- Partition ID: 0xA1B2C3D4
- Leader Priority values: Border Router=255, Routers=128-200, REEDs=64
- Router promotion threshold: 24 devices per router
Steps:
- Network Initialization (T=0):
- Border Router powers on first, creates new Thread partition
- Assigns itself as Leader (highest priority = 255)
- Generates Network Master Key: 0x00112233445566778899AABBCCDDEEFF
- Mesh-Local Address: fd12:3456:7890::ff:fe00:0001 (RLOC16)
- Router Attachment (T=0-30s):
8 Routers discover network via MLE (Mesh Link Establishment)
Each Router sends MLE Parent Request (multicast)
Leader responds with MLE Parent Response containing network credentials
Routers assigned RLOC16 addresses:
Router 1: fd12:3456:7890::ff:fe00:0400 (Router ID 1) Router 2: fd12:3456:7890::ff:fe00:0800 (Router ID 2) ... Router 8: fd12:3456:7890::ff:fe00:2000 (Router ID 8)
- REED and SED Attachment (T=30-60s):
- 4 REEDs attach as end devices (ready to promote if needed)
- 15 SEDs attach to nearest parent Router
- Child ID assignment: Each Router assigns local Child IDs 0x01-0x1FF
- Example SED address: fd12:3456:7890::ff:fe00:0401 (Router 1, Child 1)
- Leader Failure Simulation (T=300s):
Border Router loses power unexpectedly
Network detects missing Leader via MLE Keep-Alive timeout (4 seconds)
Active Routers calculate Leader eligibility scores:
Router 1: Priority=180, Uptime=270s, Score=180+(270/60)=184.5 Router 2: Priority=175, Uptime=268s, Score=179.5 Router 3: Priority=190, Uptime=265s, Score=194.4 (HIGHEST)
- Leader Election (T=304-310s):
- Router 3 elected as new Leader (highest score)
- Router 3 sends MLE Data Request to claim Leader role
- Other Routers acknowledge new Leader
- Partition ID remains: 0xA1B2C3D4 (no network split)
- Network Reconvergence (T=310-330s):
- New Leader inherits routing table
- SEDs that were children of Border Router re-attach to Router 3
- Network resumes normal operation
- Border Router recovery: When it powers back on, it rejoins as Router (not Leader)
Result: Total Leader failover time = 30 seconds (4s detection + 6s election + 20s reconvergence). The network maintained partition integrity with 0 packet loss for sleeping devices (messages queued). Non-sleeping devices experienced 4-10 second communication interruption.
Key Insight: Thread’s Leader election is deterministic based on configurable priority values and uptime. Border Routers should have highest priority (255) because they provide internet connectivity. When designing Thread networks, ensure at least 3 mains-powered devices can serve as Leader candidates for robust failover. The 32-router limit ensures election completes quickly (all candidates known), unlike larger Zigbee networks where coordinator failure can be catastrophic.
1021.8 Worked Example: Battery Optimization
Scenario: A smart home installer is configuring 50 Thread devices and needs to optimize the mix of device roles to maximize battery life while maintaining reliable mesh coverage.
Given:
- Building: 2-story home, 2,400 sq ft (1,200 sq ft per floor)
- 50 devices total: 15 mains-powered, 35 battery-powered
- Battery devices: CR2032 (225mAh) and AAA (1000mAh)
- Target battery life: 5+ years for door sensors, 2+ years for motion sensors
- Thread SED poll interval options: 5s, 30s, 60s, 300s
- Power consumption: Sleep=5uA, Poll=15mA for 10ms, TX=20mA for 5ms
Steps:
Calculate Router Requirements:
- Coverage area per router: ~150 sq ft (15m radius indoors)
- Minimum routers: 2,400 / 150 = 16 routers
- Available mains-powered: 15 devices
- Solution: 15 Routers + need REEDs from battery devices
Assign Device Roles:
Mains-Powered (15 devices): - 1 Border Router (Google Nest Hub) - 12 Routers (smart bulbs, switches, plugs) - 2 FEDs (smoke alarms - need instant response) Battery-Powered (35 devices): - 4 REEDs (smart locks with large batteries - AAA) - 8 MEDs (motion sensors - need 1-5s response) - 23 SEDs (door sensors, temp sensors - can tolerate latency)Configure Poll Intervals by Device Type:
Device Type Poll Interval Justification Door sensor (SED) 300s Event-driven, latency OK Temp sensor (SED) 60s Periodic reporting Motion sensor (MED) 5s Fast response needed Smart lock (REED) 30s Balance response/battery Calculate Battery Life for Each Configuration:
Door Sensor (SED, 300s poll, CR2032):
- Polls per day: 86,400s / 300s = 288 polls
- Poll energy: 288 x 15mA x 10ms = 43.2 mAs/day
- Events per day: 20 door opens x 20mA x 5ms = 2 mAs/day
- Sleep energy: 5uA x 86,400s = 432 mAs/day
- Total daily: 477.2 mAs = 0.133 mAh/day
- Battery life: 225mAh / 0.133 = 1,692 days = 4.6 years
Motion Sensor (MED, 5s poll, AAA):
- Polls per day: 86,400s / 5s = 17,280 polls
- Poll energy: 17,280 x 15mA x 10ms = 2,592 mAs/day
- Events per day: 100 motions x 20mA x 5ms = 10 mAs/day
- Sleep energy: 5uA x 86,400s = 432 mAs/day
- Total daily: 3,034 mAs = 0.843 mAh/day
- Battery life: 1000mAh / 0.843 = 1,186 days = 3.2 years
Verify Network Coverage:
- 12 Routers + 1 Border Router = 13 mesh backbone nodes
- 4 REEDs can promote if router fails
- Router spacing: sqrt(2400/13) = ~13.6 ft apart (within 15m range)
- Redundancy: 1.3x minimum (13 vs 10 needed) - acceptable
Final Configuration Summary:
Thread Network Configuration: - Network Name: "HomeThread" - Channel: 15 (avoid Wi-Fi interference) - PAN ID: 0x4D5E - Mesh-Local Prefix: fd00:db8::/64 Device Distribution: - Border Router: 1 (Leader priority 255) - Routers: 12 (Leader priority 128) - REEDs: 4 (promotion threshold: 3 children) - FEDs: 2 (smoke alarms) - MEDs: 8 (5s poll) - SEDs: 23 (60-300s poll)
Result: Optimized network achieves:
- Door sensors: 4.6 years battery (exceeds 5-year target with AAA upgrade)
- Motion sensors: 3.2 years battery (exceeds 2-year target)
- Network reliability: 13 routers with 4 REED backup
- Response times: SEDs 0-300s, MEDs <5s, FEDs instant
Key Insight: The key to Thread battery optimization is matching poll interval to application requirements. Door sensors can use long poll intervals (300s) because they wake immediately on events. Motion sensors need short intervals (5s) for timely notifications. The 35/15 split between battery and mains-powered devices is typical for residential Thread networks. Always use mains-powered devices as the mesh backbone and reserve battery power for true mobile/constrained sensors.
1021.9 Knowledge Check
A battery-powered Thread door sensor (Sleepy End Device) wakes every 60 seconds to check for messages and transmits when door opens (average 10 times/day). Using a 2000 mAh battery, what is the approximate battery life?
Options:
- 3-6 months
- 1-2 years
- 3-5 years
- 7-10 years
Correct: D) 7-10 years
Device Profile:
- Type: Sleepy End Device (SED)
- Poll interval: 60 seconds
- Door events: 10 times/day
- Battery: 2000 mAh (3V)
Power Calculation Summary:
- Polling: 60 polls/hour x 10 ms x 20 mA = 3.33 uAh average
- Sleep: 10 uA deep sleep current
- Events: 10 events/day x 13 ms x 25 mA = negligible
- Total daily: ~0.321 mAh
- Calculated life: 2000 / 0.321 = ~17 years theoretical
Real-World Factors:
- Battery self-discharge (~1-2%/year)
- Temperature effects
- Practical limit: 7-10 years
Why So Long? Device sleeps 99.9% of time. Modern MCUs (nRF52, CC2652) achieve 5-10 uA sleep current.
Comparison:
| Device Type | Poll Interval | Battery Life |
|---|---|---|
| FED (always-on) | N/A | Days-weeks |
| MED (poll 5s) | 5 seconds | 1-2 years |
| SED (poll 60s) | 60 seconds | 7-10 years |
Trade-off: Longer poll interval = longer battery life but higher latency (up to 60s delay for notifications).
In a Thread network, what is the maximum number of routers, and what drives this limit?
Options:
- 16 routers, limited by 4-bit short addressing
- 32 routers, limited by the 5-bit router ID space used in Thread addressing (RLOC)
- 64 routers, limited by IPv6 subnet size
- Unlimited routers; the mesh grows without protocol limits
Correct: B) 32 routers, limited by the 5-bit router ID space used in Thread addressing (RLOC)
Thread allocates router IDs from a 5-bit space (2^5 = 32), which caps the number of routers (IDs 0-31). Devices beyond that remain end devices/REEDs unless router slots free up.
Why 32?
- 5-bit router ID in RLOC16 address format
- Keeps routing tables manageable
- Enables fast Leader election (all candidates known)
- Sufficient for 250-device networks (typical ratio 1:6-8)
What is the primary role of a Thread Border Router?
Options:
- Generate DTLS session keys for every end device
- Bridge the Thread IPv6 mesh to other IP networks (Wi-Fi/Ethernet) to enable internet and LAN connectivity
- Replace mesh routing by forcing all traffic to be single-hop
- Provide sub-GHz long-range coverage for Thread devices
Correct: B) Bridge the Thread IPv6 mesh to other IP networks (Wi-Fi/Ethernet) to enable internet and LAN connectivity
The border router connects the Thread mesh to the broader IP world (home LAN and internet), performing routing (and often NAT64/translation) so Thread devices can reach IP services.
Border Router Functions:
- IPv6 gateway between Thread and Wi-Fi/Ethernet
- NAT64 for IPv4 internet access
- DNS-SD for service discovery
- Firewall protecting Thread network
- Often serves as Matter controller
1021.10 Key Concepts
- Optimal Router Count: 16-20 routers for typical homes; more is not better
- Battery Life Factors: Sleep current (dominant) + poll frequency + event rate
- Poll Interval Selection: Match to application latency requirements
- IPv6 Address Types: Link-Local, Mesh-Local, RLOC, EID, Global - each for specific purposes
- Leader Election: Priority-based, deterministic, sub-second failover
- Network Capacity: 250 devices, 32 routers per network; use multiple networks for larger deployments
1021.11 Summary
This chapter covered practical Thread network planning and optimization:
Common Mistakes to Avoid:
- Don’t maximize router count to 32 (16-20 is optimal for most homes)
- Don’t use short poll intervals unless latency is critical
- Don’t neglect REED backup capacity for router failures
Battery Life Optimization:
- SED with 60s polling: 10-12 years on CR2032
- MED with 5s polling: 1-3 years on AAA
- Sleep current is dominant factor (99%+ of time)
- Poll frequency is secondary but significant
IPv6 Addressing:
- Mesh-Local for 80%+ of application traffic
- RLOC for optimal routing (auto-managed)
- EID for stable device identification
- Global only for internet-facing services
Network Planning:
- 1 router per 125-150 sq ft for coverage
- 1 router per 6-8 end devices for capacity
- 4-6 REEDs for failover resilience
- Consider multiple networks for >250 devices
Deployment Verification:
- Check router coverage overlaps
- Verify end device parent assignments
- Test Leader failover recovery
- Monitor routing overhead (should be <10 updates/min)
1021.12 What’s Next
Return to the Thread Comprehensive Review index for navigation to other Thread topics, or continue to Z-Wave to explore another low-power mesh protocol for smart home automation.