Definition
CoAP (Constrained Application Protocol) is a lightweight application layer protocol developed by IETF, based on UDP, using a RESTful style, suitable for NB-IoT, LPWAN and other constrained devices. NB-IoT gateways often support multiple uplink protocols such as CoAP, MQTT, and HTTP, meeting the integration needs of different platforms.
Protocol Features
CoAP uses a request/response model, supports GET, POST, PUT, DELETE methods corresponding to HTTP semantics, facilitating integration with Web services. The message header is a minimum of 4 bytes, supports connectionless (UDP) and optional reliable transmission (CON messages + retransmission). The Observe mechanism can implement subscription push similar to MQTT. CoAP can be combined with DTLS for secure transmission, supporting four security modes: NoSec, PreSharedKey, RawPublicKey, and Certificate. Resource discovery is implemented via /.well-known/core, supporting resource description in Link format.
Comparison with MQTT
CoAP is based on UDP, with no connection establishment overhead, suitable for low-power scenarios like NB-IoT and LoRa; MQTT is based on TCP and requires maintaining long connections. CoAP uses a RESTful resource model and is compatible with HTTP; MQTT uses topic-based publish/subscribe. CoAP is suitable for request/response-type devices with limited resources; MQTT is suitable for many-to-many message distribution scenarios that require QoS guarantees. NB-IoT platforms often support both CoAP and MQTT, chosen according to business needs. CoAP over TCP (RFC 8323) extends the application of CoAP over TCP.
IoT Applications
NB-IoT devices can report sensor data to IoT platforms via CoAP, and the platform can respond via CoAP or HTTP. The LwM2M device management protocol is based on CoAP, enabling firmware upgrades, configuration distribution, and remote diagnostics. Low-power devices such as smart meters, environmental monitoring, and agricultural sensors commonly use CoAP as the application-layer protocol. Gateways can convert CoAP to MQTT, HTTP, etc., to achieve protocol adaptation and platform integration.
Confirmable messages and Observe
The Constrained Application Protocol treats a resource as an addressable path. GET, PUT, POST, and DELETE only name the action. Reliability is decided by the message type. A confirmable message requires a reset or acknowledgement, and after it is sent it is retransmitted with exponential back-off. A non-confirmable message is forgotten once sent, which suits periodic samples that may be lost. Observe registers interest on a GET. When the resource changes, the server sends a notification. It is not a long-lived connection, and any one notification may be confirmable or not. The token pairs a request with its response. The message ID detects retransmission. Do not fold the two into one counter. After the server restarts, the observe relationship is gone. A client that only remembers the old token will wait for notifications forever.
The condition is that both ends agree on the resource path, the content format, and the block size. A low-power device's receive window is short. If the server answers outside that window, the confirmable message retries until it gives up, even though the application may already have succeeded. Block transfer suits firmware or a long log. Every block has a number and an end flag. A missing block cannot be assembled into a complete object. A DTLS handshake costs more round trips than the application message. A pre-shared key suits a batch of identical meters. A certificate mode has to consider whether the device can store the chain and finish the handshake. Even with no security requirement, the network still has to limit who may write a resource. A short message is not a reason to skip access control.
Retransmission limits on a constrained link
The most common mistake is to set confirmable retries tighter than the radio can schedule. On a narrowband network the answer is often later than the default initial timeout. The client resends, and the server executes every PUT, so an actuator moves again and again. Set the initial timeout and the maximum retries from a measured round trip. A write should be idempotent, using a sequence number or a target state rather than "turn it on once more." Another mistake is an observe notification with no throttle. Temperature jitter makes the server push every sample, the radio fills in the reverse direction, and the battery curve is the opposite of the "power saved" design.
A NAT or a carrier gateway drops a UDP mapping that has been idle for a long time. The client thinks the observation is still alive, and the server's notification goes to the old port. If downlink is required, have the device send a very short non-confirmable message often enough to refresh the mapping, or have the device pull instead. When a proxy turns CoAP into HTTP, a timeout shorter than the device's wake interval makes the HTTP client fail first, and the later CoAP response has nowhere to go. If the content format is wrong, a number is stored as plain text. The platform accepts it and the unit is gone. When debugging, look first at whether message IDs are consecutive and tokens come in pairs, then at the resource itself.
Resource paths and content formats
The same number in a different content format may still draw a success from the server. If the client decodes it with the wrong format, a temperature becomes bytes that cannot be read. A trailing slash, or a different case, is another resource on some implementations. A write should carry an application sequence number so a repeated confirmable retry runs only once. Observe notifications need a minimum interval. Sensor jitter must not become a push on every sample.
A proxy timeout must be longer than the device's sleep interval. Otherwise the web side fails first, and the response the device sends when it wakes has no receiver. If a block is missing, discard the whole transfer. Do not fill the gap with zeros and treat it as complete firmware. A failed security handshake should stay failed and raise an alarm. It must not fall back to an unprotected port and keep reporting. Links returned by resource discovery only say what the server claims to offer. They do not say the field wiring is correct. A real reading is still needed to check the unit and the range.
A success code on a write only means the resource was accepted. It does not mean the actuator has reached the target. The client should read the status resource once more. If the value read back does not match the target, treat it as a failure. Do not take the response code as the field result. After a server restart the observe relationship disappears, and the client must register again. It cannot keep waiting for the old notification. Put the content format and the path in the point list. After a firmware change, read the discovery interface before deciding whether the old path is still there. The last block of a block transfer needs an end flag. A buffer with no end flag must not be applied. Count the token and the message ID separately. A retransmission increments only the message ID and keeps the token. Otherwise the peer treats it as a new operation and runs it again.