Internet protocol conversations usually boil down to speed, reliability, or the range of functions performed. Large applications and video streams require high bandwidth, necessitating demanding hardware requirements. In the context of the Constrained Application Protocol, streaming solutions rarely work for battery-powered sensors in harsh conditions.
Things are different in the world of smaller devices, which are increasingly communicating via networks. Limited by computing power and built-in energy, these devices typically use coin cell batteries for power. These batteries highly limit their capability to work for over five years without requiring a replacement. One solution for this challenge is conducting so-called energy harvesting. It simply allows us to harvest energy from the surroundings.
Recognizing this gap, the IETF (Internet Engineering Task Force) formed the Constrained RESTful Environments (CoRE) Working Group to develop a specialized protocol that could bridge the divide between the constrained node and the wider internet. The result was the Constrained Application Protocol (CoAP), published as RFC 7252 in 2014.
What is the CoAP?
The design philosophy of Constrained Application Protocol was not to invent a completely new communication paradigm. It was to adapt the successful REST (Representational State Transfer) architecture of the web to the constraints of IoT devices. By doing so, CoAP allows constrained devices to expose their data as “resources” identified by Uniform Resource Identifiers (URIs), which can be manipulated using standard methods like GET, PUT, POST, and DELETE.
This approach facilitates the “Web of Things.” Here, a temperature sensor is not just a data endpoint but a standard web server, accessible and interactive through standard web tools, albeit optimized for minimal resource usage. It can easily connect to integrate with any cloud stack, like AWS. As an official AWS Partner, we find this integration particularly powerful for building scalable, secure cloud-to-device solutions. We often leverage this to de-risk roadmaps for our clients who require high-performance device-to-cloud connectivity.
How does CoAP work?
CoAP features two layers: a lower message layer and an upper Request/Response layer for client-server communication. The message layer handles structure, duplicate rejection, and reliability via CON and NON mechanisms. Meanwhile, the Request/Response layer manages communication using standard HTTP methods.
Constrained Application Protocol reduces transmission overhead by abandoning text-based headers in favour of bit-encoded headers. The frame header consists of:
- protocol version,
- message type (Confirmable CON, Non-confirmable NON, Acknowledgement ACK, and reset RST),
- token length,
- response code (known from HTTP),
- message ID.
This list is quite long, yet it has been compressed to only 4 bytes. The next and final element of the frame is, of course, the payload, which is separated from the rest by a marker with a binary value of 0xFF.
As mentioned earlier, one of the responsibilities of the CoAP protocol is to ensure transmission reliability. Since UDP lacks reliability, CoAP implements a custom message acknowledgement mechanism to ensure successful data delivery. CON messages require servers to notify senders of receipt, whereas NON messages ignore lost frames.
Devices use ACK messages to confirm receipt, choosing the timing and form based on specific needs. This mechanism suits embedded device limitations better than standard TCP acknowledgements for power-efficient communication. The ability to disable acknowledgements is also useful during multicast communication when queries to multiple clients could ‘clog’ the network.
What are typical use cases for the CoAP standard?
Projects that base their communication on the Constrained Application Protocol are ideal for tasks requiring energy efficiency, i.e. long battery or accumulator life. In the context of smart cities, these include devices such as water meters and gas meters. Operating in basements or technical rooms, weak signals limit bandwidth and significantly increase device energy consumption. Using CoAP, devices handshake via DTLS or OSCORE, send one CON metric, then return to sleep. In difficult conditions, it is much easier to see the relationship between communication length and energy consumption.
Another important application could be agriculture. More difficult communication conditions also mean large distances between the device and the BTS (Base transceiver station). In this case, it is also easy to lose packets, and retries (which are also uncontrolled in many protocols) will increase energy consumption just to send a packet with low priority, for example. In CoAP, the developer decides whether the system should retry transmission if any of the message packets are lost. This level of control is essential when we build systems that must remain functional for years post-deployment.
What is the difference between MQTT and CoAP?
The choice between MQTT and CoAP is a common architectural decision in IoT development. While both target constrained environments, they represent fundamentally different paradigms. MQTT decouples the producer and consumer; a temperature sensor acting as a publisher does not know which subscribers are reading its data. This decoupling is powerful for scalability but introduces a central broker as a single point of failure.
In contrast, CoAP mimics the web, where a client talks directly to a server or sensor. This allows for mesh architectures where devices control each other directly – such as a light switch sending a CoAP PUT request directly to a light bulb – without needing a central cloud broker.
While MQTT provides a reliable decoupled architecture through its central broker, its reliance on TCP (Transmission Control Protocol) introduces significant overhead for small payloads and drains battery life due to mandatory “Keep-Alive” heartbeats. Conversely, CoAP is designed for resource-constrained environments, utilizing a connectionless UDP (User Datagram Protocol) transport that allows devices to remain in “deep sleep” for long periods and transmit data instantly without a handshake. While MQTT remains highly reliable and handles large messages through transparent TCP segmentation, CoAP offers better efficiency in high-loss networks. It supports block-wise transfers, which allow devices to pause and resume large data transmissions to conserve both memory and power.
What are the benefits of using CoAP?
CoAP often does not work alone but is an integral part of advanced protocols dedicated to embedded devices. A popular CoAP-based solution is LwM2M, which standardises the exchange of information with IoT devices. LwM2M organises device data into a structured hierarchy of objects, instances and resources. This simple model enables servers to efficiently access, configure and control IoT devices. The use of this architecture for our devices will also allow for easy and seamless scaling of our system. And integration of these protocols from the hardware layer up to the cloud. In our experience, providing this level of documentation and traceability is critical for clients in regulated industries like MedTech.
In addition to that, the OCF (Open Connectivity Foundation) standard adopted CoAP as its mandatory connectivity protocol for smart home interoperability. OCF defines comprehensive data models for smart home devices (lights, thermostats) and mandates CoAP for discovery and control. This ensures that an OCF light switch from Vendor A can control an OCF bulb from Vendor B via direct CoAP messages, without needing a cloud broker.
What are the disadvantages of using CoAP?
Constrained Application Protocol also has some drawbacks, which can be eliminated. These should be kept in mind during implementation. UDP, on which the protocol is based, is treated by routers as a fairly short NAT address assignment (often around one minute), after which the address needs to be reassigned. This causes a problem if our device is to be found after the aforementioned time has elapsed, as it may then have a completely different address. A workaround is to send ‘keep-alive’ packets, but this method is not compatible with the concept of deep sleep mode. When using LwM2M, we can use queuing, so that incoming messages to the device are temporarily stored on the server until the device wakes up.
CoAP is as reliable as we make it by using it in our project. What TCP offers by default, i.e. advanced retransmission mechanisms, proves to be useful for embedded devices, albeit in a limited version. So if we want advanced connection retransmission mechanisms, we have to implement them ourselves, which will prolong the development process. However, this allows for a “pilot-first” approach where we can tune the firmware for specific environmental interference before mass production.
What is the future of CoAP?
The future of internet transport is QUIC (Quick UDP Internet Connections), the basis of HTTP/3. QUIC combines the speed of UDP with the reliability and security of TCP+TLS. The IETF is actively working on running CoAP over QUIC. This would provide the built-in security (QUIC enforces TLS 1.3), reliability without head-of-line blocking, and migration resilience (connections survive IP changes). This will likely become the standard for Class 2 devices (more powerful microcontrollers) in the next 3-5 years.
Privacy in IoT is a growing concern. Standard DNS queries are plaintext, leaking device activity patterns. DoH (DNS over HTTPS) is too heavy for sensors. DNS over CoAP (DoC) is an emerging standard to allow constrained devices to perform encrypted DNS lookups using CoAP+OSCORE, securing the metadata of the IoT. At WizzDev we are constantly monitoring these trends to ensure our clients receive future-proof technology that meets both performance and compliance standards. Our goal is always to provide a reliable handover of all IP and documentation so you remain in full control of your device’s lifecycle.
