CoAP protocol
This article is sourced from:
https://academy.nordicsemi.com/courses/cellular-iot-fundamentals/lessons/lesson-5-cellular-fundamentals/topic/lesson-5-coap-protocol/
CoAP is like a simplified version of the HTTP protocol, specifically designed for constrained IoT and its devices. Similar to HTTP, it is based on a client-server architecture—clients make requests, and servers return responses, which is known as the REST (REpresentational State Transfer) model.
01
The REST model defines a uniform interface for communication between clients and servers through a series of strict constraints. The most important aspect of the REST model is the resource (the representation of data), which is an abstraction of all types of information.You can use commands like GET, POST, PUT, and DELETE, similar to HTTP, to read, write, and manipulate that resource.Each resource has a Uniform Resource Identifier (URI).
02
The following diagram illustrates the format of CoAP messages.
-
Version Ver— Currently 1, other values are reserved for future versions.
-
Type Type— Indicates whether the message is “confirmable,” “non-confirmable,” “acknowledgment,” or “reset.”.
-
Token Length— Represents the length of the “variable-length token” field.
-
Code Code— Divided into two parts, the first 0-7 bits for classification and 8-31 bits for details. Classification includes: “request,” “successful response,” or “error response,” with details providing additional information for the classification.
-
Message ID— The sequential ID of the network message, used to detect duplicates or ensure reliability.
Types of Messages
CoAP messages use UDP for transmission, so packets may arrive out of order, be duplicated, or lost. Therefore, reliability is achieved by marking the message in the CoAP header as “confirmable.” The receiver must confirm or reject the message using the original Message ID (rejected messages are of the reset type).
Code Field
The Code field in the CoAP message header specifies the message category.
-
GET— Retrieve information corresponding to the resource specified in the CoAP request.
-
POST— Request the server to process the information contained in the request and update the target resource or create a new resource using that information (if the target resource does not already exist).
-
PUT— Similar to a POST request, but the server may choose to create the resource if it does not exist.
-
DELETE— Request to delete the specified resource.
Token Field
All CoAP requests also carry a token, which is a sequence of 0-8 bytes that the server echoes in any response. The token is generated by the client and should be unique and random when generated.
Unlike the Message ID, the token is an important random string used to prevent spoofing and can also serve as a local identifier for the client. The Message ID is assigned sequentially, while the token is random.
Option Field
CoAP defines many options that can be included in CoAP messages (requests and responses). For a complete list of options, refer to section 5.4 of RFC 7252.
For example, a GET request for a resource should include an option specifying the URI of that resource.
Security
Since CoAP uses UDP as its transport protocol, “Datagram Transport Layer Security (DTLS)” can be used to protect communications.
DTLS provides the same functionality as TLS (confidentiality, integrity, and authenticity) while adding the capability to handle the connectionless characteristics of UDP.
Differences Between MQTT and CoAP
MQTT is another widely used IoT communication protocol, and the choice between the two depends on various factors.
These two protocols have very different network architectures, as shown in the following diagram:
MQTT adopts a “publish/subscribe” method, while CoAP uses a “request/response” method.MQTT uses a central broker for communication, whereas CoAP is a one-to-one architecture without intermediaries.CoAP uses UDP, which is less reliable than the TCP-based connections used by MQTT.However, MQTT has higher power consumption because it must maintain the connection between the client and the broker.CoAP is a one-to-one model, while MQTT supports simultaneous connections from multiple nodes.
Unlike TCP-based protocols, CoAP has the advantage of being connectionless, meaning you can communicate between two endpoints without prior arrangement.
MQTT is well-suited for “event-driven” systems, where changes in the status of IoT sensor devices drive subsequent reactions. CoAP, on the other hand, is more suitable for centralized monitoring systems where higher-level information systems query the status of IoT devices as needed.
03
In advanced metering infrastructure, smart meters need to send data to the metering master station system at fixed intervals. This process generally uses the DLMS protocol (Device Language Message Specification) defined by IEC 62056. The “Metering Device Language” based on IPv4 network transmission is defined in IEC 62056-47:2006.
DLMS can be based on TCP connections for websockets transmission or based on UDP for data interaction.
From the perspective of smart meter data properties, the primary application scenario is the uploading of meter data to the collection system, so MQTT would be more suitable for this application scenario in constrained networks.
However, the meter data management system also needs to send requests to the meter for “on-demand reading,” “remote disconnect/reconnect,” “synchronization,” and “sending or querying rates,” making CoAP more effective in these situations.
This is similar to past smart meter data collection master station systems, where we more often used a client-server architecture (C/S architecture); now it is gradually shifting to a browser-server architecture (B/S architecture). This transition process does not change the essence of data collection and control, but to meet customer demands for “thin clients,” today’s product research and development is more based on web applications.
Clearly, in the underlying communication process, whether to use CoAP or directly transmit DLMS requests based on UDP does not make a fundamental difference. CoAP makes future smart meters look more like specific nodes in the ocean of the IoT, no longer cold IP addresses and obscure DLMS service ports, but a unique network address identifier URI. If developed properly, the GET method can be used more, simplifying program development on the master station side.
MQTT and CoAP are not contradictory; they serve different application scenarios. From the application itself, CoAP is not a mandatory option. However, the historical development of the Internet seems to suggest that CoAP will become a trend in the larger IoT world.∎
