Not every IoT embedded device is capable of maintaining a persistent TCP connection to an MQTT broker or handling the overhead of an HTTP/2 session. The most constrained IoT devices - sensor nodes powered by coin cells, microcontrollers with 4 KB to 32 KB of RAM, devices communicating over 6LoWPAN or Zigbee mesh networks - need a protocol designed explicitly for resource-constrained environments. The Constrained Application Protocol (CoAP), standardised in RFC 7252, provides exactly this: a REST-like request-response protocol operating over UDP, with binary encoding and a sub-kilobyte protocol overhead that makes it practical on the most limited embedded platforms.
CoAP Architecture and Message Model
CoAP uses a four-message-type model operating over UDP. Confirmable (CON) messages require acknowledgement - the sender retransmits until an ACK or RST is received, providing reliable delivery despite UDP's unreliable nature. Non-Confirmable (NON) messages are fire-and-forget, appropriate for high-frequency sensor readings where occasional loss is acceptable. Acknowledgement (ACK) messages confirm receipt of a CON message. Reset (RST) messages indicate that a CON message was received but cannot be processed. This model provides reliability semantics similar to TCP for critical messages while allowing efficient unacknowledged operation for high-frequency data.
| Dimension | CoAP | MQTT |
|---|---|---|
| Transport | UDP | TCP |
| Protocol model | Request-response (RESTful) | Publish-subscribe |
| Broker required | No - direct device communication | Yes - broker required |
| Header overhead | 4 bytes minimum | 2 bytes minimum |
| Suitable for sub-32KB RAM | Yes | Marginal |
| Observe (push notifications) | Yes - built in | Yes - via subscriptions |
| Security | DTLS (UDP-based TLS) | TLS (TCP-based) |
CoAP Observe: Event-Driven Push Notifications
A key CoAP feature for IoT applications is Observe, defined in RFC 7641. Observe allows a client to register interest in a CoAP resource - a temperature sensor reading, a device status flag - and receive push notifications whenever the resource's value changes, without polling. The server sends a notification for each state change as a CoAP response carrying the new value and an incrementing observe sequence number. The client acknowledges periodically to maintain the observation relationship. CoAP Observe provides the event-driven data delivery that MQTT's pub-sub model provides, but without requiring a broker — the device communicates directly with its client.
DTLS Security for CoAP
CoAP over plain UDP is insecure. DTLS - Datagram Transport Layer Security - provides the equivalent of TLS for UDP-based protocols and is the standard security layer for CoAP in production deployments. DTLS provides mutual authentication, data encryption, and replay attack protection. Implementing DTLS on constrained embedded devices requires a lightweight DTLS library - tinydtls, mbed TLS in DTLS mode, or wolfSSL with DTLS support - chosen based on the device's RAM and flash constraints. Key management for DTLS on constrained devices is often simplified through Pre-Shared Keys rather than certificate-based authentication, trading some security assurance for the elimination of certificate management overhead on the most constrained hardware.
CoAP vs MQTT: Choosing Between Them
CoAP and MQTT address overlapping but distinct IoT communication needs. CoAP is preferable when the device is too constrained for TCP - sub-32 KB RAM devices on battery power, communicating over lossy wireless mesh networks. CoAP's direct device-to-device communication model eliminates broker dependency and simplifies network topology for small deployments. MQTT is preferable when broker-mediated fan-out to many consumers is needed, when the device can support persistent TCP connections, or when QoS 2 exactly-once delivery is required. Both can coexist in a system - CoAP for direct device-to-edge communication, MQTT for edge-to-cloud upward transport.
Implementing CoAP with RAPIDSEA
RAPIDSEA's IoT protocol stack includes a CoAP implementation covering confirmable and non-confirmable message handling, the Observe extension for push notifications, resource directory integration, DTLS security layer integration for production-secure deployments, and a resource handler API that maps CoAP GET, PUT, POST, and DELETE operations to device application functions. The implementation operates without a RTOS, supports 8-bit through 32-bit MCU architectures, and is delivered in MISRA-C compliant ANSI C source under royalty-free per-MCU licensing.
Conclusion
CoAP brings the REST architectural model to the most constrained IoT embedded devices - providing reliable request-response communication, event-driven push notifications via Observe, and DTLS-based security over UDP transport with a fraction of the resource overhead required by TCP-based protocols. For embedded teams building battery-powered sensor nodes, mesh-networked devices, or ultra-constrained microcontroller applications, CoAP is the right protocol where MQTT and HTTP/2 are not viable options. RAPIDSEA's CoAP implementation provides a validated, cross-platform embedded stack for these deployment contexts.
Ready to optimize communication for constrained devices? Contact our team to request an evaluation build or book a technical demo.