Introduction
The Internet of Things (IoT) refers to the “internet of everything connected,” which is an extension and expansion of the internet, forming a huge network by combining various information sensing devices with the network, enabling connectivity among people, machines, and objects anytime and anywhere. However, many IoT terminals are resource-constrained, with limited storage space and computing power. The Constrained Application Protocol (CoAP) is designed for constrained communication applications, primarily addressing the limitations of terminals, especially NB-IoT devices, which have limited computing capacity and small ROM & RAM.
Application Scenarios
Nowadays, smart meters are installed in most residential communities, where meter terminals deploy small sensors to report meter data. Homeowners can obtain real-time electricity usage via their smartphones and complete bill payments without leaving home. Many alarm sensors use NB-IoT, which is based on the CoAP protocol for transmission. For instance, in smart agriculture scenarios, various sensors deployed on farms transmit sensed data to the cloud primarily using the CoAP protocol.
Before understanding CoAP, it’s helpful to have some knowledge of MQTT, which can be referenced in the detailed explanation of the MQTT protocol within the IoT technology system. In terms of IoT communication, MQTT is an application layer protocol, with TCP as its transport layer, meaning MQTT establishes a reliable connection through a three-way handshake, maintaining a long connection and periodically sending heartbeat packets, as shown in the protocol stack in Figure 1. Devices maintain a long connection with the server, requiring continuous power supply to stay connected. This led to the idea of using UDP for transmission, resulting in the birth of the CoAP protocol (which is based on UDP). While UDP is unreliable, the CoAP protocol transforms this unreliable transport layer into a reliable application layer, which is why when searching for CoAP online, you may find it described as a reliable connection; this will be clarified in the subsequent analysis of message formats.
Figure 1 Protocol Stack
As seen, devices using MQTT require larger battery capacities; many wireless controllers have multiple battery groups to maintain long connections. In contrast, devices using the CoAP protocol do not need such large batteries; they can enter sleep mode after sending data, achieving energy savings. Thus, the CoAP protocol is more suitable for data collection scenarios. Another critical feature of CoAP, based on UDP, is its usability in extremely resource-constrained situations, such as NB-IoT chips that support UDP for data exchange using the CoAP protocol. The reason for sharing this relatively less popular protocol today is that the IoT is penetrating various industries. For instance, when collecting environmental information, using the MQTT protocol would waste resources. To address such issues, the IoT will develop simpler, easy-to-operate chips specifically for environmental data collection, which only need to report data without issuing control commands to devices.
Message Format
The CoAP protocol uses a 4-byte message header, usually followed by some Option fields, and then the message payload. Both request and response messages follow this structure, as shown in Figure 2.
Figure 2 Message Format
The meanings of the fields are shown in Table 2.
Table 2 Field Meanings
Usage Types
Messages sent from the sender to the receiver are classified as reliable messages (CON type) and unreliable messages (NON type). NON messages do not require the receiver to reply with an ACK message; once sent, they are complete. CON type messages require the receiver to reply with an ACK message for confirmation. The ACK message can not only indicate that the receiver has received the message from the sender but can also carry response content, as shown in Figure 3.
Figure 3 CON Message Request and Response
In Figure 3(a), the sender sends a CON (Type=0) message with MessageID 0x0001, corresponding to the GET method (Code=0.01), accessing the resource URI (/temperature for temperature data), Token=0x71. The receiver replies with an ACK (Type=2) message carrying response content. The MessageID of this message matches that of the CON message, indicating a response to the CON message, while Code=2.05 indicates the specific data content, with the Token matching the CON message Token, and 23.1℃ as the message payload, indicating the current temperature is 23.1 degrees.
Figure 3(b) shows another response method where the receiver separates the ACK message from the response message. This usually occurs because the receiver needs some time to respond to the request. The receiver first replies with an ACK message to inform the sender that the CON message has been received, and then sends the response content once it is ready. As in step ③, the MessageID of the response to the CON message differs from that in step ①, but their Tokens are the same, indicating that the step ③ CON message is a response to the step ① CON message, while steps ② and ④ represent ACK messages confirming receipt of the CON message.
The URI of CoAP messages (coap://host:port/path) is similar to that of HTTP protocol, adopting a request-response working mode, where coap:// indicates that this is a CoAP protocol URI, host indicates the host address, and if the host address is expressed using a hostname, a DNS server is needed to resolve the hostname to an IP address. The port indicates the accessed UDP port, defaulting to port 5864, and /path indicates the resources available on the host, using multiple slashes to represent resource hierarchy. For CoAP messages using security mechanisms, the URI follows a similar format but starts with coaps://.
Conclusion
By now, we should understand the message format, communication modes, and URI methods of the CoAP protocol. The design intent of CoAP is to solve communication issues in constrained environments, thus implementing special handling, resulting in smaller data packets, flexible transmission, and simplicity, akin to a simplified version of the HTTP protocol, providing a solid foundation for the integration of IoT and the internet.
Author | Shuwen Zhang
Visual | Pengyu Wang
Coordination | Deguang Zu
