Why is CoAP better suited for LPWAN than HTTP or MQTT?

LPWAN technologies (LoRaWAN at 0.3 to 50 kbps, NB-IoT at 20 to 250 kbps, Sigfox at 100 to 600 bps) have extremely limited bandwidth and high per-byte energy cost. HTTP is unsuitable because its text-based headers alone exceed 200 bytes, and TCP's three-way handshake requires 3 round trips before any data transfer, which is prohibitive on links with 1 to 10 second latency. MQTT is better than HTTP (binary protocol, persistent TCP connection) but still requires TCP, making it problematic on lossy radio links where TCP retransmissions and congestion control perform poorly. CoAP uses UDP, eliminating TCP overhead and allowing the application to manage reliability. Its 4-byte fixed header and compact binary options keep messages to 10 to 20 bytes. The Observe extension (RFC 7641) replaces polling with server-pushed notifications, reducing the number of transmissions by 5 to 50x for monitoring applications. CoAP also supports block-wise transfer (RFC 7959) for transmitting large payloads in multiple small datagrams, fitting within LPWAN maximum payload constraints (51 to 242 bytes for LoRaWAN).

How does CoAP compare to MQTT for IoT?

CoAP and MQTT serve different IoT architectures. CoAP follows a request-response (RESTful) pattern matching the web architecture, making it natural for resource-oriented designs where sensors expose their data as addressable resources (like /temperature, /humidity). MQTT follows a publish-subscribe pattern with a central broker, better suited for event distribution to multiple subscribers. CoAP uses UDP (lower overhead, works on lossy links, no connection state), while MQTT uses TCP (reliable but expensive to maintain on constrained devices). CoAP messages are typically 10 to 20 bytes versus MQTT's minimum of 2 bytes header plus topic name (usually 20 to 50 bytes total). CoAP supports built-in resource discovery (/.well-known/core), letting devices self-describe their capabilities, which MQTT lacks. CoAP supports multicast (one request to many devices), useful for group operations, which MQTT cannot do natively. For cellular IoT (NB-IoT, LTE-M), 3GPP has adopted CoAP as a preferred protocol due to its UDP efficiency and compatibility with the Non-IP Data Delivery (NIDD) mechanism.

Wireless Protocols

CoAP

Q: How does CoAP reliability work over UDP?

CoAP defines two message types for reliability. Confirmable (CON) messages require an acknowledgement (ACK) from the receiver within a timeout period (default 2 to 3 seconds, configurable). If no ACK is received, the sender retransmits using exponential backoff (doubling the timeout each retry, up to 4 retransmissions by default). This provides reliable delivery without the overhead and complexity of TCP's sliding window, congestion control, and connection state. Non-confirmable (NON) messages are fire-and-forget, used for periodic sensor readings where occasional loss is acceptable (e.g., temperature reports every 15 minutes where missing one reading is tolerable). CoAP also includes a message deduplication mechanism using 16-bit message IDs and token matching, preventing duplicate processing when retransmissions are received. For DTLS security (RFC 6347), CoAP adds encryption and authentication with approximately 25 bytes of overhead per datagram, compared to TLS over TCP which adds 5 to 40 bytes plus the TCP overhead.

/koh-ap/

The Constrained Application Protocol (CoAP, RFC 7252) is a lightweight RESTful protocol for resource-constrained IoT devices. Uses UDP with a compact 4-byte binary header (vs HTTP's 200+ bytes), supports GET/PUT/POST/DELETE, asynchronous Observe (RFC 7641) for event-driven updates, and block-wise transfer (RFC 7959) for LPWAN payloads. Ideal for LoRaWAN, NB-IoT, and Sigfox where each byte has significant energy cost. Messages are 10 to 20 bytes vs 500+ for HTTP.

Category: Wireless Protocols

Transport: UDP (4-byte header)

Message size: 10 to 20 bytes

Understanding CoAP

The Internet of Things connects billions of devices, many of which are severely resource-constrained: microcontrollers with 10 to 256 KB RAM, running on coin-cell batteries that must last 5 to 10 years, communicating over radio links with 0.3 to 250 kbps bandwidth and 1 to 10 second latency. Standard web protocols (HTTP over TCP/TLS) were designed for powerful computers on reliable, high-bandwidth networks and are fundamentally unsuited for these environments. CoAP was purpose-designed by the IETF CoRE working group to bring RESTful web architecture to constrained devices while respecting their limitations.

CoAP's design philosophy is "web architecture for the constrained." It maps directly to HTTP semantics (GET reads a resource, PUT updates, POST creates, DELETE removes) but replaces HTTP's verbose text headers with a compact binary format. The 4-byte fixed header contains version, message type, token length, request/response code, and message ID. Variable-length options (analogous to HTTP headers) use delta-encoding for compactness. Payloads follow a single-byte 0xFF marker. This minimalism is critical for LPWAN: on LoRaWAN at SF12 (250 bps), transmitting 500 bytes of HTTP takes 16 seconds and drains 32 mJ from the battery, while 20 bytes of CoAP takes 0.64 seconds and 1.3 mJ, a 25x energy reduction for the same application function.

CoAP Protocol Metrics

CoAP Message Size:
Size = 4 (header) + TKL + Options + 1 (marker) + Payload

Energy per Message (LPWAN):
E = P_tx × T_air = P_tx × Size / Bitrate

Observe Savings:
N_saved = (T_monitor/T_poll) - (N_changes) (messages saved)

Where TKL = token length (0 to 8 bytes), Options = 0 to ~100 bytes typically. On LoRaWAN SF10 (980 bps): 20-byte CoAP takes 163 ms airtime. P_tx = 50 mW typical, E = 8 mJ per message. At 10 messages/day: 29 mJ/day = ~10 years on 1000 mAh coin cell.

IoT Protocol Comparison

Protocol	Transport	Min Message	Pattern	Best For
CoAP	UDP	10 to 20 bytes	RESTful req/resp	LPWAN, constrained sensors
MQTT	TCP	20 to 50 bytes	Pub/sub (broker)	Wi-Fi/cellular, many subs
HTTP/2	TCP + TLS	200 to 500 bytes	RESTful req/resp	Cloud APIs, gateways
LwM2M	CoAP/UDP	15 to 30 bytes	Object/resource	Device management, NB-IoT
MQTT-SN	UDP	7 to 20 bytes	Pub/sub	ZigBee, Bluetooth Mesh

Common Questions

Frequently Asked Questions

Why is CoAP better for LPWAN than HTTP or MQTT?

HTTP text headers exceed 200 bytes; TCP handshake needs 3 round trips at 1 to 10 s latency. MQTT requires TCP (poor on lossy radio links). CoAP uses UDP (no connection overhead), 4-byte header, 10 to 20 byte messages. Observe replaces polling (5 to 50x fewer transmissions). Block-wise transfer fits within LoRaWAN 51 to 242 byte payload limits.

How does CoAP reliability work over UDP?

Confirmable (CON) messages require ACK within 2 to 3 s timeout, with exponential backoff retransmission (up to 4 retries). Non-confirmable (NON) is fire-and-forget for periodic readings. 16-bit message IDs prevent duplicate processing. DTLS adds ~25 bytes encryption overhead vs TLS+TCP's much larger footprint.

How does CoAP compare to MQTT?

CoAP: RESTful, UDP, 10 to 20 bytes, supports multicast and resource discovery (/.well-known/core), adopted by 3GPP for NB-IoT NIDD. MQTT: pub/sub, TCP, 20 to 50 bytes, needs central broker, better for many subscribers. CoAP for constrained devices; MQTT for event distribution on reliable networks.

Related Terms

← Co Simulation Emc Coax To Cpw Transition →