Internet of Things (IoT) – Part 4: CoAP protocol

Today we want to continue discussing topics related to IoT, or the Internet of Things. We’ll be talking about various other protocols that exist in the application layer and are associated with IoT systems. If you’re interested, we invite you to read on!

Alternatives to MQTT – COAP

In 2023, the most popular protocol for IoT devices is MQTT, which we discussed in our last blog post. However, there are alternatives used in specific scenarios where MQTT cannot be applied.

The Constrained Application Protocol (CoAP) is a protocol designed to operate on hardware that is inherently limited, such as due to small memory or computational resources. It is recommended for devices running on batteries due to its efficient use of energy resources. The CoAP standard (RFC 7252) was established in 2014, making it a relatively new solution compared to MQTT (1999). CoAP is suitable for larger-scale IoT projects and devices with limited power resources. It has several characteristic features in terms of technical aspects, including:

• Similarity to HTTP/REST – CoAP includes so-called “Verbs” (GET, POST, etc.), which are the same as those in the HTTP protocol. However, HTTP is not well-suited for devices that need to inform the client of a change in a certain state on the server (hence, HTTP is considered stateless). If a protocol does not guarantee this, like HTTP, the client is forced to continuously inquire about the server’s state, which is often suboptimal and sometimes unacceptable. To address this, CoAP introduces improvements such as the “GET + Observe” feature:
  

• GET + Observe – This allows the client to establish a real-time communication channel, enabling it to observe changes in a specific resource on the server. This mechanism is similar to subscribing to updates or changes in a resource and is particularly useful for scenarios where you want to efficiently monitor data from sensors or other dynamic information while conserving resources. The client session is identified by a token.
  
  

Figure 1: CoAP datagram in Wireshark, showing the Observe flag, source: journals.sagepub.com

• Discovery Mechanism – CCoAP offers a discovery mechanism for identifying available resources that a given device can communicate with. A CoAP client can send a multicast request (typically a GET) to a special multicast address to find available resources on the network. Devices that support these resources respond to the request, allowing the client to discover available RESTful endpoints of the device. This discovery of endpoints is called CORE Resource Discovery. It is a part of the CoAP protocol that allows the client to discover resources within a single CoAP server without having to search the entire network. Discovering resources within CORE involves using special resources called “.well-known/core,” which contain information about available resources on the server. By sending GET requests to the “.well-known/core” resource, the client can obtain a list of available resources in the form of URI addresses, allowing the application to query endpoints.
  
  
• UDP with Binding Maintenance Between Devices –  UDP is a connectionless protocol and does not provide built-in reliability features like TCP (Transmission Control Protocol). However, CoAP addresses this limitation through mechanisms embedded in the CoAP protocol itself. When a message must be delivered to a specific party, it is marked as “CON” (Confirmable) and retransmitted at intervals if it does not receive an “ACK” (Acknowledgement). Other message types include “NON” (Non-confirmable) and “RST” (Reset). While CoAP’s flags are somewhat similar to those in TCP, it’s important to note that in CoAP, communication reliability is ensured at the application layer, using UDP.

Figure 2: Example of communication confirmation from client to server in CoAP, source: RFC7252

• Easy Mapping Due to Similarity to HTTP –  Because both CoAP and HTTP are based on the REST architecture and use concepts like URI addresses for resource identification, as well as GET, POST, PUT, etc., it is easy to transition from one type of communication to the other. This is known as proxying. CoAP-HTTP proxy enables the conversion of requests and responses between CoAP and HTTP, facilitating the integration of devices and applications operating in different environments and technologies.

Figure 3 – Transition between HTTP and CoAP using a proxy, source: e2e.ti.com

• Works well on limited resources – CoAP is a lightweight protocol that efficiently uses even single bits for transmitting information. As a result, it integrates well into the network stack, whether using classic UDP/IP or UDP/6LoWPAN.
  
  

Figure 4 – Possible network stack for an IoT device using CoAP, source: ARM Youtube

6LoWPAN is a protocol below the transport layer that allows the use of IPv6 in low-power wireless networks. When combined with CoAP (the application layer), it enables efficient communication for IoT devices. This is achieved by adapting IPv6 packets to the constraints of such networks, using IPv6 addresses, header compression, fragmentation, and enabling the creation of mesh networks. CoAP, as a lightweight protocol, fits perfectly into 6LoWPAN, allowing access and resource management in resource-constrained environments.

Figure 5 – Communication scheme between devices using COAP and 6LoWPAN, source: lobaro.com

• Security – Regarding security in CoAP, for the classical CoAP using UDP, DTLS (Datagram TLS), a version of TLS for connectionless UDP, is employed. Authentication mechanisms enable CoAP servers and clients to verify their identities (e.g., through certificates), and authorization mechanisms control access to specific resources. This is a critical aspect for data protection and ensuring data security in CoAP applications.
  
  

CoAP offers many more functionalities that we cannot cover here. However, we hope this short article will provide you with a better understanding of the IoT topic as a whole.

Summary

Today we have introduced you to an alternative to MQTT – a CoAP protocol similar to HTTP, efficient on limited resources, secure with DTLS. We also encourage you to take a look at the sources. See you next week with a new topic!

Sources:

• https://www.lobaro.com/en/portfolio/coap-over-6lowpan-solutions/
• https://www.youtube.com/watch?v=4bSr5x5gKvA&t=1217s 
• https://journals.sagepub.com/doi/full/10.1177/1550147718772793 https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/495960/getting-started-with-coap-development