Scenario: A hospital deploys 200 wireless patient monitors tracking heart rate, SpO2, and blood pressure. Each monitor transmits 20-byte vital sign packets every 10 seconds. Monitors are battery-powered (rechargeable daily) and must operate for 16-hour shifts. Network covers 5 floors (200m × 100m per floor) with existing Wi-Fi infrastructure. Data must reach nursing station dashboards within 2 seconds. Regulatory requirement: 99.9% delivery reliability.
Step 1 — Requirements Analysis
| Devices |
200 monitors |
Scalability needed |
| Payload |
20 bytes every 10s |
17,280 messages/day per device |
| Range |
200m × 100m per floor |
Building-scale coverage |
| Power |
Battery (16-hour shift) |
Must optimize for daily charging, not years |
| Latency |
< 2 seconds |
Real-time monitoring |
| Reliability |
99.9% delivery |
Cannot lose critical vital signs |
| Network |
Existing Wi-Fi |
Leverage infrastructure |
Step 2 — Evaluate Protocol Options
Option A: CoAP/UDP/Wi-Fi
Overhead: 4 (CoAP) + 8 (UDP) + 40 (IPv6) + 36 (Wi-Fi) = 88 bytes
Total packet: 108 bytes
Efficiency: 18.5%
Latency: < 50ms (UDP immediate send)
Reliability: UDP unreliable by default; CON messages add retry
Option B: MQTT/TCP/Wi-Fi
Overhead: 2 (MQTT) + 20 (TCP) + 40 (IPv6) + 36 (Wi-Fi) = 98 bytes
Total packet: 118 bytes
Efficiency: 16.9%
Latency: < 100ms (TCP handshake once, then fast)
Reliability: TCP guarantees delivery + MQTT QoS levels
Option C: HTTP/TCP/Wi-Fi (for comparison)
Overhead: 100 (HTTP min) + 20 (TCP) + 40 (IPv6) + 36 (Wi-Fi) = 196 bytes
Total packet: 216 bytes
Efficiency: 9.3%
Latency: 100-300ms (connection overhead)
Reliability: TCP guarantees delivery
Step 3 — Decision Matrix
| Efficiency |
18.5% |
16.9% |
9.3% |
CoAP |
| Latency |
< 50ms ✓ |
< 100ms ✓ |
100-300ms |
CoAP |
| Reliability |
Needs CON |
Native ✓ |
Native ✓ |
MQTT |
| Scalability |
Per-device |
Broker ✓ |
Per-device |
MQTT |
| Dashboard integration |
Custom |
Native ✓ |
Native ✓ |
MQTT |
| Battery life |
Best |
Good |
Poor |
CoAP |
Step 4 — Battery Life Calculation
CoAP/UDP (per device per 16-hour shift):
Messages: 16 hours × 360/hour = 5,760 messages
TX time: 108 bytes × 8 bits ÷ 54 Mbps = 16 µs per message
Total TX time: 5,760 × 16 µs = 92 ms
Wi-Fi active power: 200 mW
Wi-Fi sleep power: 10 mW (idle listening)
Energy consumption:
TX: 200 mW × 0.092s = 18.4 mJ = 0.005 mAh
Sleep: 10 mW × 57,599.9s = 576 J = 160 mAh
Total: 160 mAh per shift (well within 2000 mAh battery)
MQTT/TCP (per device per 16-hour shift):
Messages: 5,760 (same)
TX time: 118 bytes × 8 bits ÷ 54 Mbps = 17.5 µs per message
TCP keep-alive: 40 bytes every 60s = 960 messages × 17.5 µs = 16.8 ms
Total TX time: 92 + 16.8 = 109 ms
Energy consumption:
TX: 200 mW × 0.109s = 21.8 mJ = 0.006 mAh
Sleep: 10 mW × 57,599.9s = 576 J = 160 mAh
Total: 160 mAh per shift (negligible difference from CoAP for this power budget)
Analysis: For rechargeable-daily devices on Wi-Fi, battery efficiency difference between CoAP and MQTT is negligible (both ~8% of battery capacity per shift). The dominant factor is Wi-Fi idle listening power.
Step 5 — Final Recommendation
Choice: MQTT/TCP over Wi-Fi with QoS 1
Rationale:
- Reliability: TCP + MQTT QoS 1 guarantees delivery, meeting 99.9% regulatory requirement without application-layer retry logic
- Scalability: MQTT broker efficiently handles 200 devices publishing to 50+ nursing station dashboards
- Dashboard integration: Native MQTT support in hospital monitoring systems (Grafana, InfluxDB)
- Latency: 100ms average meets < 2s requirement with margin
- Battery impact: Negligible difference from CoAP for daily-rechargeable devices on Wi-Fi
- Operational simplicity: Hospital IT staff familiar with MQTT brokers, less custom code needed
Implementation:
- MQTT topics:
hospital/floor3/room315/monitor/vitals
- QoS 1 for vital signs (acknowledged delivery)
- Retained messages for last-known values (new dashboards get immediate state)
- Last Will Testament for disconnect alerts (monitor battery dead or patient removed device)
Why NOT CoAP: While CoAP is more efficient, MQTT’s pub-sub architecture naturally fits the one-to-many (monitor to multiple dashboards) pattern. CoAP would require custom routing logic or multiple transmissions. The efficiency gain doesn’t justify the development complexity when battery life is already adequate.
Cost comparison over 5 years:
- Development: MQTT saves ~$50K in custom code vs CoAP routing
- Infrastructure: MQTT broker ~$5K (existing server), CoAP would need gateway routing logic
- Maintenance: MQTT ecosystem support saves ~$10K/year
- Total: MQTT saves ~$100K despite slightly higher per-packet overhead
Key lesson: For applications where battery life is adequate, protocol efficiency is less important than ecosystem fit, reliability guarantees, and operational simplicity. CoAP’s technical superiority doesn’t always translate to better total cost of ownership.
