CoAP (Constrained Application Protocol)

What is CoAP?

CoAP (Constrained Application Protocol) is a lightweight application-layer protocol designed specifically for constrained IoT devices - microcontrollers, low-power sensor nodes, and embedded RFID edge devices that cannot run full HTTP stacks. Defined in RFC 7252 by the IETF, CoAP provides a REST-like model (GET, POST, PUT, DELETE) that maps cleanly onto HTTP semantics, yet runs over UDP and uses as little as a 4-byte fixed header.

The protocol was designed for 8-bit microcontrollers with tens of kilobytes of ROM and RAM, operating on low-power lossy networks such as 6LoWPAN over IEEE 802.15.4. This makes it directly applicable to battery-powered RFID readers, sensor-tag gateways, and edge infrastructure in industrial IoT environments where network reliability and device resources are both limited.

How CoAP works

CoAP shares the REST architecture of HTTP but is fundamentally different in its transport and message model:

• 4-byte fixed header: The binary header encodes version, message type, token length, code (method or response), and a 16-bit message ID. Options (URI path, content format, etc.) follow as a compact delta-encoded list. The entire overhead is typically 10–20 bytes versus HTTP's hundreds of bytes.
• Methods: CoAP supports GET, POST, PUT, and DELETE, mirroring HTTP semantics. Response codes follow a similar 2.xx / 4.xx / 5.xx convention (e.g., 2.05 Content, 4.04 Not Found).
• Confirmable (CON) messages: The sender retransmits until it receives an ACK from the recipient. This provides reliability over UDP without requiring TCP. Suitable for important state changes on lossy links.
• Non-confirmable (NON) messages: Fire-and-forget delivery. No ACK is expected. Used for high-frequency sensor data where occasional loss is acceptable and retransmission overhead is undesirable.
• Observe pattern (RFC 7641): A client registers interest in a resource with a single GET+Observe option. The server then pushes notifications whenever the resource changes - without the client polling repeatedly. This is CoAP's equivalent of MQTT subscriptions and is well-suited to RFID read-event streams.
• Block transfers (RFC 7959): Large payloads (firmware updates, tag inventories) are fragmented into blocks. Each block is transferred and acknowledged independently, allowing reliable transfer of data that exceeds a single UDP datagram without requiring TCP.
• Multicast: Because CoAP runs over UDP, it supports IP multicast natively. A single CoAP request can be sent to an entire subnet of devices simultaneously - useful for discovering RFID readers or broadcasting configuration to a sensor cluster.

CoAP in RFID and IoT

CoAP is particularly relevant in RFID deployments where edge devices operate under strict resource constraints:

• Constrained RFID edge devices: Ultra-low-power RFID readers based on embedded MCUs (e.g., ARM Cortex-M series) can implement a full CoAP stack in a few kilobytes of ROM. These devices expose tag reads as CoAP resources, allowing backend systems to query or subscribe without the overhead of HTTP or LLRP .
• Sensor-tag gateways: Gateway devices that aggregate data from multiple passive RFID tags or NFC sensors and forward it upstream often use CoAP as the northbound protocol. The gateway converts tag reads into CoAP resource representations and either responds to polls or pushes changes via Observe.
• 6LoWPAN networks: 6LoWPAN adapts IPv6 for IEEE 802.15.4 radio networks, the same physical layer used by many low-power RFID and sensor systems. CoAP over 6LoWPAN is a natural pairing - both are designed for the same constrained environment, and the combination is standardised by the IETF for the "constrained IoT web."
• Battery-powered readers: In asset-tracking or cold-chain deployments where RFID readers run on battery power, CoAP's minimal overhead and UDP transport reduce both CPU cycles and radio-on time compared to TCP-based protocols, extending battery life significantly.
• CoAP-to-HTTP proxying: Because CoAP and HTTP share the same REST semantics and method names, cross-protocol proxies are straightforward to implement. A CoAP-HTTP proxy sits at the network edge, translating requests from IoT devices into HTTP calls to cloud APIs and back, with no semantic transformation required.

DTLS security

CoAP itself provides no security - it relies on the underlying transport for encryption and authentication. The standard security mechanism is DTLS (Datagram TLS), which is TLS adapted for UDP. CoAP over DTLS (coaps://) provides:

• Mutual authentication: Both client and server authenticate using certificates (PKI mode) or pre-shared keys (PSK mode). PSK mode is common on constrained devices because it avoids the overhead of certificate handling.
• Encryption: AES-CCM cipher suites are specified in RFC 7252 as mandatory-to-implement for CoAP+DTLS. These are hardware-accelerated on most modern IoT MCUs, keeping energy cost low.
• Replay protection: DTLS sequence numbers prevent replay attacks - a concern in RFID systems where an attacker might replay old tag-read events.
• OSCORE (RFC 8613): An alternative to transport-layer DTLS, OSCORE (Object Security for Constrained RESTful Environments) applies end-to-end encryption at the CoAP message layer, surviving through proxies and intermediaries. Useful when the CoAP-to-HTTP proxy must not see plaintext payload.

Advantages

• Tiny overhead: A 4-byte header and binary encoding keep message sizes in the tens of bytes, versus hundreds or thousands for HTTP. Critical for devices transmitting over slow, expensive radio links.
• UDP-based: No TCP handshake, no connection state, no head-of-line blocking. Devices can send a reading and sleep immediately, without maintaining a persistent connection.
• REST semantics: Shares GET/POST/PUT/DELETE with HTTP, making CoAP resources easy to proxy to HTTP APIs and familiar to developers who know REST.
• Observe pattern: Server-sent notifications without polling eliminates wasted requests on quiet resources, reducing network load and device wake cycles in RFID event-driven architectures.
• Multicast support: Native UDP multicast allows broadcast discovery of readers and bulk configuration - impractical with TCP-based protocols.
• Designed for constrained devices: The entire RFC 7252 CoAP stack can be implemented in roughly 10 KB of ROM, making it viable on the smallest RFID edge hardware.
• Standards-backed: IETF-standardised with active working group extensions (Observe, Block, Group Communication, OSCORE), providing long-term stability and interoperability.

Limitations

• UDP reliability burden: Confirmable messages provide ACK-based reliability, but retransmission logic must be implemented in the application. On highly lossy networks, CoAP's simple retransmit-and-timeout can perform worse than TCP's congestion control.
• NAT traversal: UDP-based protocols do not maintain connection state, making NAT traversal and firewall penetration more difficult than TCP. Deployments behind NAT require techniques like reverse proxies or DTLS connection IDs.
• Smaller ecosystem: Compared to HTTP and MQTT , CoAP has fewer libraries, cloud integrations, and developer tools. Many IoT platforms do not support CoAP natively and require a proxy layer.
• Less tooling: Browser-based debugging, monitoring dashboards, and logging infrastructure are all built around HTTP. CoAP traffic requires specialist tools (e.g., Copper browser plugin, Californium, libcoap) to inspect.
• DTLS session overhead: While DTLS is lighter than TLS over TCP, the DTLS handshake is still relatively expensive for very constrained devices. Session resumption mitigates this but adds implementation complexity.
• Not suited for high-throughput: CoAP is optimised for small, infrequent messages. High-volume RFID read streams (thousands of reads per second) are better served by protocols with streaming support such as WebSockets or MQTT.

Common applications

• Constrained IoT gateways: Edge gateways that aggregate RFID and sensor data from a local 6LoWPAN or Bluetooth mesh network and expose it as CoAP resources to upstream systems.
• Low-power RFID sensor networks: Battery-powered RFID reader arrays in cold-chain, agriculture, or asset-tracking where devices sleep between reads and use CoAP NON messages to report tag reads without maintaining a connection.
• Smart building / industrial IoT: RFID-enabled access panels, environmental sensors, and equipment monitors in buildings or factories where 6LoWPAN mesh networking connects hundreds of constrained nodes to a CoAP border router.
• Firmware and configuration management: CoAP Block transfers are used to push firmware updates or configuration payloads to constrained RFID readers over the air, without requiring a TCP connection.
• Edge computing: CoAP acts as the southbound protocol between an edge compute node and fleets of constrained RFID sensors, with the edge node translating CoAP to HTTP or MQTT for cloud connectivity.

CoAP vs MQTT vs HTTP

Related