Scenario: A city deploys 10,000 LED streetlights with motion sensors that report activity every 5 minutes. Each light transmits sensor status (2 bytes), battery voltage (2 bytes), and timestamp (4 bytes) = 8 bytes payload. Battery requirement: 10+ years on 2x D-cell lithium (19,000 mAh @ 3.6V). Network uses IEEE 802.15.4 mesh (250 kbps). Initial design uses MQTT/TCP. Engineering audit questions whether this meets battery targets.
Step 1 — Calculate Current Battery Life (MQTT/TCP)
Protocol overhead calculation:
802.15.4 header: 25 bytes
IPv6 header: 40 bytes (uncompressed)
TCP header: 20 bytes
MQTT header: 2 bytes (minimum)
Payload: 8 bytes
Total: 95 bytes per message
Transmission analysis:
Messages per day: 1440 min ÷ 5 min = 288 messages
Bits per day: 95 bytes × 8 bits × 288 = 218,880 bits/day
TX time at 250 kbps: 218,880 ÷ 250,000 = 0.876 seconds/day
Power consumption:
TX current: 20 mA (802.15.4 radio)
Sleep current: 5 µA (ultra-low-power mode)
TCP keep-alive: 40 bytes every 60 seconds = 57,600 bytes/day extra
Keep-alive TX time: 57,600 × 8 ÷ 250,000 = 1.843s/day
Total active time: 0.876s (data) + 1.843s (keep-alive) = 2.719s/day
Daily energy:
TX/RX: 20 mA × 2.719s ÷ 3600 = 0.0151 mAh
Sleep: 0.005 mA × 86,397.3s ÷ 3600 = 0.120 mAh
Total: 0.135 mAh/day
Battery life: 19,000 mAh ÷ 0.135 mAh/day = 140,741 days = 385 years?
Wait — this seems too good! What’s missing?
The calculation above assumes perfect conditions. Real-world factors: 1. Processing overhead: MCU wakes to process keep-alives (add 50% overhead) 2. Retransmissions: Lossy mesh network (15% packet loss, 1.18× multiplier) 3. Temperature effects: -20°C to 40°C reduces usable capacity by 30%
Adjusted calculation:
Effective capacity: 19,000 × 0.70 = 13,300 mAh
Adjusted daily usage: 0.135 × 1.50 × 1.18 = 0.239 mAh/day
Actual battery life: 13,300 ÷ 0.239 = 55,648 days = 152 years
Still exceeds 10-year target! So why optimize?
Step 2 — The Hidden Cost: Network Congestion
With 10,000 lights:
- MQTT data: 10,000 x 95 bytes x 288 msgs/day = 273.6 MB/day network traffic
- TCP keep-alives: 10,000 x 57,600 bytes/day = 576 MB/day additional
Total: 849.6 MB/day on a constrained mesh network with shared 250 kbps bandwidth.
Step 3 — Optimized Solution with CoAP/UDP + 6LoWPAN
New protocol overhead:
802.15.4 header: 8 bytes (compressed)
6LoWPAN header: 6 bytes (context compression)
UDP header: 4 bytes (NHC compression)
CoAP header: 4 bytes
Payload: 8 bytes
Total: 30 bytes per message (68% reduction!)
New network traffic: - CoAP: 10,000 x 30 bytes x 288 msgs/day = 86.4 MB/day - No keep-alives: 0 MB/day - Total: 86.4 MB/day (90% reduction in network load)
Step 4 — Cost-Benefit Analysis
Battery life improvement:
CoAP base daily energy:
TX time: 30 bytes × 8 bits × 288 msgs ÷ 250,000 bps = 0.2765 s/day
TX energy: 20 mA × 0.2765 s ÷ 3600 = 0.00154 mAh
Sleep energy: 0.005 mA × 86,399.7 s ÷ 3600 = 0.120 mAh
Base total: 0.121 mAh/day
Adjusted: 0.121 × 1.50 × 1.18 = 0.214 mAh/day
New battery life: 13,300 ÷ 0.214 = 62,150 days = 170 years
Improvement: 1.12× longer (both far exceed 10-year target)
Real benefit – Network capacity:
- 90% traffic reduction = support 10x more devices on same infrastructure
- City saves $2M by avoiding network upgrade for 5 years
- Reduced collisions improve reliability from 85% to 96%
Key Insight: When sleep current dominates battery consumption (as in this scenario), protocol optimization provides only marginal battery improvement. The real value in dense deployments is network capacity and scalability – the 90% traffic reduction (largely due to eliminating TCP keep-alives) provides far greater economic value than marginal battery gains. The CoAP switch paid for itself through avoided infrastructure costs, not battery replacement savings.
Implementation note: CoAP’s Observe extension allows streetlights to subscribe to configuration changes, maintaining bidirectional capability without TCP connection overhead.