Definition and Design Objectives
CoAP (Constrained Application Protocol) is an application layer protocol designed by IETF specifically for constrained IoT devices. It is based on UDP and provides HTTP-like RESTful interfaces, supporting GET/POST/PUT/DELETE, with message headers as small as 4 bytes. CoAP is suitable for devices with limited memory, computing power, and energy, such as sensors and actuators, and is often used in combination with 6LoWPAN and NB-IoT.
Core Features
Technical Features
- Based on UDP: connectionless and lightweight, suitable for low-power devices
- RESTful style: consistent with HTTP semantics, easy to migrate
- Observe mode: supports resource subscription, similar to MQTT publish/subscribe
- With HTTP proxy: can interconvert with HTTP through a proxy, enabling Web and IoT interoperability
- Optional DTLS: supports encrypted transmission
Comparison with MQTT and HTTP
| Protocol | Transmission Layer | Mode | Applicable to |
|---|---|---|---|
| CoAP | UDP | Request-Response/Observe | Constrained devices, low power |
| MQTT | TCP | Publish/Subscribe | Persistent connection, bidirectional push |
| HTTP | TCP | Request-Response | General Web, REST API |
Typical Applications
Lightweight data interaction scenarios such as smart homes, industrial sensors, NB-IoT devices, 6LoWPAN networks, etc. Suitable for resource-constrained, intermittent reporting, request-response mode scenarios.
SimtoLink's NB-IoT IoT SIM cards are often used in low-power scenarios such as smart metering and environmental monitoring. These devices mostly use CoAP or lightweight MQTT for data reporting. CoAP is based on UDP, which can reduce connection establishment overhead in NB-IoT narrowband environments, suitable for small data packets and intermittent reporting. When providing NB-IoT solutions to customers, SimtoLink offers selection recommendations in combination with the device protocol stack (CoAP/MQTT/proprietary protocols) to ensure reliable, low-power data transmission under constrained network conditions.
How message type and token work together to remove duplicates
CoAP splits reliability from request meaning. A confirmable message requires the peer to return an acknowledgement or a reset. A non-confirmable message is finished once it is sent. The identity of one request is the token, not the message ID alone. The ID matches acknowledgements and retransmissions. The token hands the response back to the matching request. If the server deduplicates only by ID, a retransmission that changes the ID opens the valve twice. If the client reuses an old token, it treats the previous response as the result of this request. Both fields have to stay unique for the life of an unfinished transaction.
A reset means the peer does not recognize this confirmation at all. That is common when a server restarts and then receives a late retransmission. The client should abandon the transaction and set up the observation or the request again, not treat the reset as an application-layer “forbidden.” Retrying a reset as a denser run of confirmable messages only amplifies useless traffic on a narrowband air interface.
The gap between confirmable retransmissions should open exponentially
After a confirmable message times out, the wait grows exponentially before the next retransmission, and there is a cap on the number of tries. If the gap is fixed and very short, loss piles the same request into a cell that is already congested. Round-trip time on a narrowband link is long to begin with. If the initial timeout is set to a few tens of milliseconds, as on a local network, the first response is still on the way when the second retransmission goes out, and the server sees a duplicate request. To tell a timeout that is too short from a packet that never arrived: if the response does arrive and it carries the original token, the timeout was too aggressive. If there are only retransmissions and no response, then check the address and the port.
A non-confirmable message has no retransmission of this kind. Use it for periodic values that may be lost, and save the air-interface cost of an acknowledgement. Use it to send a shutdown command, and nobody will know if it was lost. A critical command should be confirmable, and the application should keep an idempotent execution sequence number so a retransmission does not toggle a valve twice.
An observe relationship is easy to tear down after sleep and wake
Observe mode lets the server push a new representation when a resource changes. The client registers with the observe option. After the device enters deep sleep, the address and port mapping can go stale. The server still pushes to the old mapping, and after a few failed pushes it cancels the observation. If the device only reads a local cache when it wakes, it does not notice that the observation is gone, and the cloud no longer receives changes. The condition is: the first packets after registration are normal, and once the sleep cycle arrives only a one-shot query still works. Register again after wake, or replace the push with the device reading on its own schedule.
A SimtoLink narrowband IoT SIM card is a fit for this kind of small request, but the card’s power-saving timers change how long an address mapping is held. CoAP observe keepalives must be shorter than the address-mapping lifetime and the sleep-wake interval. Otherwise the protocol layer thinks the subscription is still there, and the network layer no longer has a return path. The platform should show “observation still registered” and “time of the latest acknowledged packet” separately, so card online status is not used in place of application subscription status.
A block number cannot stand in for the confirmation number
A larger payload is split into blocks, each with its own block number. Whether the request is reliable is still decided by the message type and the message ID. Deduplicating only by block number writes the same retransmitted block again, because the message ID changed and it looks like a new block. Deduplicating only by message ID drops different blocks as duplicates. The two numbers do different jobs. The block number assembles the payload. The message ID says whether this transmission was acknowledged. The server should not perform the write until every block has arrived, or a retransmission writes the register twice.
Block size also has to be smaller than the minimum datagram length on the path. If a narrowband network, or a link with a security header, is shorter than the block length the client assumed, the block is cut again underneath, while the CoAP layer thinks one block is already complete. Negotiate a block size that the path can pass reliably, not the maximum the protocol allows. The effective payload on a SimtoLink narrowband card is smaller still. If a firmware download uses CoAP block transfer, count block length, confirmable timeout, and the card power-saving cycle together. If the power-saving cycle wakes the device onto a new address in the middle of a block sequence, the unfinished sequence should be discarded and started again. It cannot resume from the old block number.