Not all connected devices are engineered to be equal. While some are technologically advanced and robust, others are simple sensors and home automation systems with limited memory, energy, bandwidth, and computational power. Bringing the web to resource-constrained and low-power devices and enabling them to communicate efficiently requires developers to implement a particular type of IoT protocol. That is where Constrained Application Protocol or CoAP enters the picture.

What Is CoAP?

Introduced in 2014, CoAP is a lightweight RESTful protocol designed by CoRE (Constrained Resource Environments) Internet Engineering Task Force (IETF). It is generally used for Machine-to-Machine (M2M) apps such as smart energy and building automation devices.

CoAP is an efficient communication protocol for low-power IoT devices within the IoT networks. It allows resource-inhibited sensor nodes, home automation tools, and other connected objects that require less bandwidth or computational power to communicate through the internet.

CoAP is an excellent protocol for creating and managing devices, publishing/subscribing data, multicasting data among multiple clients, and providing device descriptions when requested by the client.

It also has mechanisms to detect the power state of a device. Additionally, since there are infrastructural similarities with HTTP REST operations, designers can leverage their understanding of RESTful patterns into IoT application development they undertake using CoAP.

CoAP Protocols at a Glance

The IoT ecosystem is a rapidly evolving space, making it easy for even the most brilliant designers and developers to be outpaced in their knowledge and management of M2M protocol patches, vulnerabilities, third-party library bugs, and implementation flaws.

Therefore, it is not surprising that IoT devices use popular CoAP protocols to keep cyberattacks at bay in M2M applications. They enable asynchronous message exchange, deliver URI and content-type support, leverage proxy and caching capabilities, and are simple to parse. But before we dive deep into the CoAP protocol, it is essential to gain an understanding of its structure, which typically consists of the following entities:

• “Sender” – the entity that sends a message.
• “Recipient” – the receiver or destination of the message.
• “Client” – the origin of a request and the destination of the response.
• “Endpoint” – an entity that participates in the CoAP protocol and is usually identified with a host.
• “Server” – the link between the Client and Recipient. It receives a request from a client and transmits back a response to the client.

A typical CoAP protocol may seem similar to an HTTP protocol because CoAP deploys the User Datagram Protocol (UDP) as the underlying network protocol. The UDP, in turn, helps the client place a request, and the server transmits a response — exactly as it happens in HTTP.

Two Layers Make CoAP Stand Out

The request/response layer handles request/response interaction based on the request/response messages.
The messages layer deals with asynchronous messages and User Datagram Protocol (UDP).

As you can see, CoAP protocols are not just compressed versions of HTTP protocols and are specifically designed for IoT. There are four types of message that CoAP supports, including:

• Reset (RST)
• Confirmable (CON)
• Non-confirmable (NON)
• Acknowledgment (ACK)

The primary exchanges of these messages are transparent to the request/response interactions. CoAP is a single protocol, with request/response and messages as features of the CoAP header.

How CoAP Typically Functions

CoAP is mainly used for restricted devices, enabling actuators and sensors to communicate efficiently within the IoT ecosystem. These applications are controlled by contributing their data as a part of a system. The protocol can deliver exceptional performance in high congestion and low bandwidth scenarios via low network overhead and low power consumption. CoAP also supports networks with many nodes. It can continue to work even where MQTT, a TCP-based protocol, fails to exchange information between devices and communicate effectively.

In addition, the CoAP protocol allows devices to operate in poor signal quality and transmit data reliably. This property also enables satellites to maintain distant communication conveniently. This is how it happens in M2M development services.

The Construct of the CoAP Message Model

This is the lowest-layer element of the protocol, as it handles the UDP transmitting messages between endpoints. Each CoAP message has a unique ID, which comes in handy for detecting message duplicates. On average, a CoAP message model is comprised of three parts, two of which are optional:

• A binary header
• A set of compact options (optional)
• A payload (optional)

The CoAP Protocol Specifies Two Types of Messages:

Confirmable

These messages, transmitted between two endpoints, are reliable. This means the client is assured that the message will arrive at the server. In CoAP, a dedicated message is obtained using a Confirmable (CON) message-type code. A Confirmable message is sent repeatedly until the other party (i.e., the server) sends an Acknowledge (ACK) message, which contains the same ID as the Confirmable message but with an ACK response code.

Non-confirmable

These messages do not require an acknowledgment from the client and instead always carry either a request or a response between two endpoints. Non-confirmable (NON) messages are indefinitely repeated for application requirements — for instance, repeated readings from a sensor where eventual arrival is enough. Such a message must contain a payload.

Uncovering the “Request and Response” Model

This is the second layer of the protocol. The request is sent using a CON or NON message. If the request is sent using a CON message, the server’s response depends on whether or not the server can respond immediately to the client’s request:

• If the server can respond promptly, the server sends an ACK message back to the client comprised of either the error code or response, along with a Token field mirroring the Token field in the request. A Token is different from the Message-ID and it is used to match the request and response between the two endpoints.
• If the server cannot answer the request received from the client promptly, on the other hand, it sends an ACK message with an empty message field. As soon as the response is available, the server sends a CON message to the client sharing the status.

If the request coming from the client carries a Non-confirmable message, then the server answers using that type of message only.

What is a Message Format?

CoAP messages are encoded in a binary form. A CoAP message is comprised of a fixed-size CoAP Header, complemented by a payload and options specified in Type-Length-Value (TLV) format.

While the header specifies these options, the payload consists of the bytes after the length of the options is calculated from the datagram length. A CoAP message occupies the data section of a UDP datagram to avoid fragmentation.

Since CoAP conserves energy and simplifies the communication between devices, for this reason, using compact messages. The mandatory fields of a CoAP header are:

• Version (the 2-bit version of the CoAP message format; sometimes abbreviated as “VER”)
• Type (a 2-bit unsigned integer that corresponds to a message type of RST, CON, NON, or ACK)
• Token Length (a 4-bit field specifying the length in bytes of the “token” field; sometimes abbreviated to “TKL”)
• Code (an 8-bit field that provides more information about the request or response)
• Message-ID (the unique ID associated with the message, expressed with a 16-bit value)

Taking CoAP Security Into Account

Security is a massive concern in the IoT ecosystem, and for a good reason: devices are connected over the internet, exchanging all kinds of information between them. Whether the IoT device in question is intended for personal use or commercial purposes, data security has to be paramount.

CoAP applies UDP for transport information and relies on it further for information protection. The smallest possible CoAP message is 4 bytes in length and uses two message types (responses and requests) using a simple binary base header format.

The latter is followed by options in an optimized TLV format, providing a high level of communications security. Any bytes in the header left in the packet are classified as the message body, which is implied by the datagram length.

Over to You

In M2M applications, the generic Internet media types such as application/XML, application/octet-stream, or text/plain have not proven helpful for real-world applications in the long run. For instance, a Smart Energy application payload might request a more specific type like application/se+exi because it is carried as XML.

That is why there is a need for a far more advanced IoT protocol. CoAP has been critical in reducing the cost of cloud-device connections that enable IoT devices to cost-effectively and securely send data over a larger network while consuming less power.

As the IoT environment grows, so does the need for critical protocols to enable data transmission across devices cost-effectively and securely. There is no doubt that CoAP is a smart solution that enables M2M applications. Let us hope that its use also evolves to other, different aspects of IoT in the future because of its varied offering.

PlatoAi. Web3 Reimagined. Data Intelligence Amplified.
Click here to access.

Source: https://www.iotforall.com/coap-a-smart-solution-enabling-m2m-applications