Core Concept: CoAP, MQTT, and HTTP each excel in different scenarios. CoAP = lightweight request-response. MQTT = efficient pub-sub with broker. HTTP = universal web compatibility.
Why It Matters: Wrong protocol choice can cost battery life (years vs months), bandwidth ($1000s/year for cellular), or development time (reimplementing features).
Key Takeaway: Use this heuristic: Battery-critical request-response? CoAP. Multiple subscribers? MQTT. Web integration? HTTP.
1218.3.1 Quick Decision Table
Factor
Use CoAP
Use MQTT
Use HTTP
Communication Pattern
Request-response, device queries
Publish-subscribe, multiple subscribers
Web browser access, rich media
Device Constraints
8KB RAM, 8-bit MCU
16KB+ RAM, moderate CPU
Full OS, abundant resources
Network Type
LoRaWAN, NB-IoT, 802.15.4
Wi-Fi, cellular with persistent connection
Broadband, Wi-Fi, LTE
Battery Life
Multi-year on coin cell
Months-1 year on rechargeable
Mains-powered acceptable
Message Frequency
Infrequent (hourly/daily)
Continuous streaming
On-demand
Broker Acceptable?
No (direct device-to-device)
Yes (centralized routing)
N/A
Multicast Support
Native (FF0X::FD)
Not supported
Not supported
Latency Requirements
<100ms (no setup)
<500ms (broker hop)
<1s (TCP handshake)
1218.3.2 Detailed Comparison
Metric
CoAP
MQTT
HTTP
Header Size
4 bytes
2 bytes (+ TCP overhead)
100+ bytes
Total Overhead (1 reading)
30 bytes
55 bytes (with TCP)
320 bytes
Transport
UDP
TCP
TCP
Connection Setup
None (0ms)
3-way handshake (150ms)
3-way handshake (150ms)
Energy per Message
1.5 mJ (NON), 3.0 mJ (CON)
4.5 mJ
8.0 mJ
Reliability
Optional (CON/NON)
QoS 0/1/2
TCP guarantees
Pub-Sub
Observe (1-to-many)
Native (many-to-many)
Not native
Request-Response
Native (RESTful)
Emulated (request/response topics)
Native
Resource Discovery
.well-known/core
Not standardized
Not standardized
Multicast
Yes
No
No
Broker Required
No
Yes
No
ROM Footprint
3-5 KB
15-20 KB
25-50 KB
RAM Usage
1-2 KB
3-5 KB
10-20 KB
1218.4 When to Use CoAP
Strong indicators CoAP is the right choice:
1218.4.1 1. Battery-powered sensors reporting to gateway
Example: 500 soil moisture sensors reporting to central farm controller
Why CoAP: - NON messages use 50% less energy than MQTT TCP handshakes - No connection state to maintain (sleeps fully between transmissions) - Savings: 2-year battery life vs 6-month with MQTT
1218.4.2 2. Direct device-to-device communication
Example: Smart light switch controlling smart bulb (no broker)
Why CoAP: - RESTful PUT coap://bulb.local/state {"on": true} is simpler than MQTT broker setup - Works offline, no single point of failure - Lower latency (no broker hop)
Example: Remote environmental monitoring over LoRaWAN
Why CoAP: - LoRaWAN MTU = 51-242 bytes, CoAP message fits easily - MQTT minimum header + TCP often exceeds MTU
1218.4.4 4. Multicast queries
Example: โAll temperature sensors, report current valueโ
Why CoAP: - GET coap://[FF02::FD]/temperature reaches all with 1 packet - MQTT would need N separate topics
Show code
{const container =document.getElementById('kc-coap-decision-1');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"Your smart factory has 200 temperature sensors. You need to query all sensors simultaneously for a snapshot. Which approach is MOST efficient?",options: [ {text:"Send 200 individual CoAP GET requests in parallel",correct:false,feedback:"200 individual requests = 200 packets out + 200 responses back = 400 packets total. Scales poorly."}, {text:"Use CoAP multicast GET to IPv6 address ff02::fd",correct:true,feedback:"Correct! A single multicast GET reaches all 200 sensors with 1 packet. Each responds individually (200 responses), but you've eliminated 199 request packets."}, {text:"Set up MQTT subscriptions and publish a request topic",correct:false,feedback:"MQTT requires a broker and doesn't naturally support request-response for simultaneous queries."}, {text:"Use HTTP long-polling to each sensor",correct:false,feedback:"HTTP requires 200 TCP connections and doesn't support multicast."} ],difficulty:"medium",topic:"coap-multicast" })); }}
1218.5 When to Use MQTT
MQTT is better for:
1218.5.1 1. Multiple subscribers to same data
Example: Temperature sensor data to Dashboard + Analytics + Alarm system
Why MQTT: - Single publish to topic, broker distributes to all subscribers - CoAP Observe would need subscriptions from each (3x bandwidth)
1218.5.2 2. Cloud platform integration
Example: Devices connecting to AWS IoT Core, Azure IoT Hub
# Sensor publishes oncemqtt_client.publish("factory/machine/042/vibration", {"value": 2.5, "unit": "mm/s", "alarm": true}, qos=1)# Multiple subscribers receive automatically# Dashboard: subscribes to "factory/+/vibration"# Analytics: subscribes to "factory/#"# Alarms: subscribes to "factory/+/vibration" with alarm=true filter
NoteExample 3: Fleet Tracking - Decision: MQTT
Scenario: 500 delivery trucks reporting GPS every 10 seconds to cloud dashboard viewed by 5 dispatchers.
Decision: MQTT
Reasoning: - One-to-many communication (trucks to multiple dashboards) - Each truck publishes to fleet/truck-id/gps - All 5 dispatchers subscribe to fleet/+/gps - Broker handles distribution efficiently
Why not CoAP: - CoAP Observe would require 500 x 5 = 2,500 subscriptions - MQTTโs broker-based fan-out is more scalable
Show code
{const container =document.getElementById('kc-coap-decision-2');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"You're choosing between CoAP and MQTT for a fleet of 500 delivery trucks reporting GPS every 10 seconds to a cloud dashboard viewed by 5 dispatchers. Which protocol and why?",options: [ {text:"CoAP - lower overhead for frequent messages",correct:false,feedback:"While CoAP has lower per-message overhead, this involves one-to-many communication. CoAP would require 2,500 Observe subscriptions."}, {text:"MQTT - pub/sub naturally handles one-to-many distribution",correct:true,feedback:"Correct! Each truck publishes to 'fleet/truck-id/gps', all 5 dispatchers subscribe to 'fleet/+/gps'. The broker handles distribution efficiently."}, {text:"HTTP - standard protocol for cloud services",correct:false,feedback:"HTTP's request-response model doesn't efficiently handle real-time streaming data."}, {text:"CoAP with Observe - server push to all dispatchers",correct:false,feedback:"CoAP Observe requires each dispatcher to observe each truck = 2,500 subscriptions. MQTT's fan-out is more scalable."} ],difficulty:"medium",topic:"coap-vs-mqtt" })); }}
1218.7 Multicast Advantages
Show code
{const container =document.getElementById('kc-coap-decision-3');if (container &&typeof InlineKnowledgeCheck !=='undefined') { container.innerHTML=''; container.appendChild(InlineKnowledgeCheck.create({question:"In the Smart Agriculture example, the gateway uses multicast to query all soil sensors. Why is this approach better than individual requests, and what is the main limitation?",options: [ {text:"Better: reduces network traffic; Limitation: only works on IPv6 networks",correct:false,feedback:"Multicast works on IPv4 too. The main limitation is different."}, {text:"Better: reduces latency; Limitation: responses may arrive out of order",correct:false,feedback:"Out-of-order responses are normal UDP behavior, not a fundamental multicast limitation."}, {text:"Better: single request reaches all sensors; Limitation: no acknowledgment (must use NON)",correct:true,feedback:"Correct! Multicast sends one packet to all sensors. However, multicast cannot use CON messages because there's no single peer to send ACK."}, {text:"Better: saves battery on gateway; Limitation: requires special router configuration",correct:false,feedback:"Battery savings occur on sensors, not gateway. The fundamental limitation is lack of acknowledgment."} ],difficulty:"hard",topic:"coap-multicast-tradeoffs" })); }}
Protocol selection depends on your specific requirements:
Choose CoAP when: - Battery life is critical (multi-year on coin cell) - Direct device-to-device communication (no broker) - Constrained networks (LoRaWAN, NB-IoT) - Multicast queries needed - RESTful API semantics required
Choose MQTT when: - Multiple subscribers need same data - Cloud platform integration (AWS IoT, Azure) - Persistent sessions for offline devices - Unreliable networks (TCP handles retransmission)
Choose HTTP when: - Web browser integration needed - Rich tooling required - Resources are abundant - Standard web APIs preferred