Labs Introduction
As one of the mainstream protocols in the Internet of Things (IoT) world, the CoAP protocol enables data exchange and network access for low-power constrained devices. The IETF has detailed its definition in RFC7252. This article introduces the dual-layer model and transmission characteristics of the CoAP protocol in the context of its application in the Hejiaqin (和家亲) platform.
Author: Mao Xiaojun
Organization: China Mobile Smart Home Operation Center
Hejiaqin is an intelligent connection app launched by China Mobile for smart home users, representing the practical application of IoT in home scenarios.The IoT emphasizes the connection and communication between objects, and in Hejiaqin, this object-to-object connection is realized through the Andlink protocol, which integrates various mainstream IoT protocols, including CoAP, MQTT, LwM2M, and HTTP. A simple comparison of these protocols is shown in the table below. Since multiple protocols involve CoAP, this article focuses on the dual-layer model and transmission characteristics of the CoAP protocol.
In Hejiaqin, CoAP is mainly applied in the following two scenarios:
1️⃣LPWAN networks (including NB-IoT, LoRa, SigFox, etc.), where smart devices interact with the home platform via the LwM2M protocol, which is built on the CoAP protocol using UDP/UDP+DTLS as the transport layer.
2️⃣Wi-Fi networks, where network configuration is a prerequisite for the subsequent registration, online, and control of smart devices. The configuration process involves steps such as finding smart networking terminals, sending network access requests, notifying device access information, broadcasting successful device access, and synchronizing password changes for smart networking terminals, all of which are completed through the CoAP protocol.
The CoAP protocol (Constrained Application Protocol, standard document RFC7252) is an application layer protocol that plays a role similar to HTTP in M2M communication, but it implements only a subset of REST. A key difference is that HTTP runs over TCP while CoAP operates over UDP. Because UDP establishes an unreliable connection, there is a risk of packet loss during network data transmission, whether in requests or responses. So how does the CoAP protocol ensure transmission reliability? This involves the dual-layer model of the CoAP protocol:
Logically, the CoAP protocol is divided into the Messaging Model and the Request/Response Model, where:
-
Messaging Model: Handles end-to-end data exchange and provides a retransmission mechanism for each message type to compensate for transmission unreliability. It establishes a correlation between request and response messages through the Message ID in the CoAP message header, ensuring reliable transmission.
-
Request/Response Model: Defines the rules for the client to send operation requests to server resources via URI and for server responses. It establishes the correlation between Request and Response through the Token in the CoAP message header, ensuring reliable responses.
It is important to distinguish that the Token in the Request/Response Model and the Message ID in the Messaging Model are two different fields, as shown in the following diagram[1]:
Next, we will analyze the transmission characteristics of the CoAP protocol from the perspectives of the Request/Response Model and the Messaging Model.
In the previous introduction, CoAP defines four different types of messages: CON, NON, ACK, and RST. Among them, CON messages require acknowledgment from the receiver, meaning each CON message corresponds to an ACK or RST message with the same Message ID in the header. If the requester does not receive an ACK or RST message within the specified time, the client will initiate a “retransmission mechanism.” There are two reasons why the sender might not receive the ACK/RST message:
-
CoAP Request Loss:The CoAP request has been sent but did not reach the server.
-
CoAP Response Loss:The server received the request and returned a response, but the response did not correctly reach the client.
Parameters related to the retransmission mechanism include: ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, MAX_TRANSMIT_SPAN, MAX_TRANSMIT_WAIT.
-
ACK_TIMEOUT: The timeout waiting period for a response, defaulting to 2 seconds. The initial waiting time for a CON message is a random number ranging from ACK_TIMEOUT to ACK_TIMEOUT*ACK_RANDOM_FACTOR. With each retransmission attempt, the waiting time doubles.
-
ACK_RANDOM_FACTOR: The random factor, defaulting to 1.5.
-
MAX_RETRANSMIT: The maximum number of retransmissions, fixed at 4 times.
-
MAX_TRANSMIT_SPAN: The maximum time interval from the first CON message sent to the last retransmission.
-
MAX_TRANSMIT_WAIT: The maximum time interval from the first CON message sent to the sender giving up waiting for an ACK or RST message.
To further illustrate the retransmission mechanism of the Messaging Model, let’s take the example of a device sending a network access CON request to the smart networking terminal in Hejiaqin. Suppose in this CON message transmission:
ACK_TIMEOUT=2s
ACK_RANDOM_FACTOR=1.5
The initial timeout response waiting time is t1=2.5s (2s<=t1<=2*1.5s)
Due to poor network conditions, after 4 attempts to resend without receiving an ACK or RST response message, the following interaction result can be obtained:
It is important to note that the above diagram is only to illustrate the complete process of the retransmission mechanism. As long as the device receives an ACK/RST message from the server at any time after sending the CON message, this message transmission will terminate. Through this retransmission mechanism, the CoAP protocol ensures the reliability of end-to-end message transmission.
The interaction mode of the Request/Response model is similar to the C/S model of client-server interaction in the HTTP protocol.
The Request focuses on issuing operation requests to server resources based on URI. The request types include GET, POST, PUT, and DELETE. However, unlike HTTP, it does not establish a connection first but interacts asynchronously through CoAP messages, matching Requests and Responses using the Token field in the CoAP message header.
The Response is categorized into three different types based on the differences between the Request type and the current state of the server: Piggybacked Response, Separate Response, and Non-confirmable Response:
➤ Piggybacked Response
The following diagram[1] shows an example of a server returning a piggybacked response to two GET requests, one successful and one resulting in a 4.04 (resource not found). Responding to a CON message with an ACK message is the most common type and belongs to the reliable response mode.
➤ Separate Response
If the server cannot directly provide a data response due to system overload or other reasons, it will immediately send back an empty ACK message. Once the data is ready, the server will assemble it into a new CON message (which requires the client’s ACK) for asynchronous response. The separate response also belongs to the reliable response mode. In the diagram[1], it can be seen that the Token used in both interactions is consistent, both being 0x73; however, the Message ID has changed from 0x7a10 to 0x23bb.
➤ Non-confirmable Response
If the client’s request is of the NON type, the server generally also returns a NON type message, but the server may also send a CON type message as a response. This is suitable for scenarios where reliability of response is not highly required. For example, repeated readings of temperature sensor data do not need to be successful each time. In the diagram[1], the request and response use the same Token: 0x74.
The CoAP protocol currently plays an important role in the connection and control of smart devices in both the large network and local area network of Hejiaqin. As one of the mainstream protocols of the IoT, the CoAP protocol is not only used independently but also serves as the underlying messaging protocol for LwM2M. Compared to MQTT, CoAP is lighter and has lower overhead, making it more suitable for scenarios such as device configuration in Hejiaqin. When using CoAP, it is crucial to choose the appropriate Message and Request/Response model based on the scenario to ensure transmission reliability and improve interaction efficiency between clients and servers.
👉 References
[1] Zach Shelby, Klaus Hartke, Carsten Bormann. The Constrained Application Protocol (CoAP)[EB/OL].(2023-01-19)[2023-08-02]. https://datatracker.ietf.org/doc/rfc7252/.
[5G] The Most Comprehensive Video Tutorial and Free 5G Green Book
Click below to get it now!
Master all 5G content in just 2 minutes a day! Click below to follow
