“Hands-On Writing of UDP Protocol Stack – DHCP Message Parsing”
3
“Hands-On Writing of UDP Protocol Stack – OTA Host”
4
“Hands-On Writing of UDP Protocol Stack – DNS Message Parsing”
5
“Hands-On Writing of UDP Protocol Stack – CoAP Message Parsing”
Background
CoAP (Constrained Application Protocol) is an application layer protocol in the network protocol stack that allows constrained devices, referred to as “nodes”, to communicate with the broader internet using similar protocols. CoAP is designed for communication between devices on the same constrained network (such as low-power, lossy networks), between devices on the Internet and general nodes, and between devices on different constrained networks connected via the Internet.
In previous articles, we described using UDP for OTA, which was limited to local OTA at that time. For IoT devices, it is impractical to perform local OTA every time an upgrade is needed, hence remote OTA is required.
CoAP
Characteristics of CoAP Protocol
The transport layer of the CoAP protocol uses UDP.
The non-encrypted CoAP protocol layer is as follows:
CoAP is based on the REST software architecture, and it is a simplified version of HTTP. The resource address of the server has a similar URL format as on the internet, and the client can use POST, GET, PUT, and DELETE methods to access the server.
CoAP protocol uses a binary format, while the HTTP protocol uses a text format, making CoAP more compact than HTTP.
CoAP is a lightweight protocol with a minimum length of only 4 bytes.
It supports reliable transmission, data retransmission, and block transfer, ensuring data reliability and asynchronous communication.
It supports IP multicast, allowing requests to be sent to multiple devices simultaneously.
It uses non-persistent connections, making it suitable for low-power IoT scenarios.
The message header (as above: the first line is the message header, fixed at 4 bytes)
Field
Size
Description
ver
2bit
Version information, must be set to 0x01
T
2bit
Message type, including CON, NON, ACK, RST, 4 types
TKL
4bit
Token length, supports 0~8 bytes, other lengths reserved for future expansion. The token is not mandatory for the message.
Code
1byte
Divided into the first 3 bits (0~7) and the last 5 bits (0~31), the first 3 bits represent type (class type), and the last 5 bits represent detail code (detail code). For convenience, it is written in c.dd structure.
Message ID
2byte
Message number, each message has an ID, and the ID of retransmitted messages remains unchanged.
Token
0~8byte
Optional, used to match responses with requests. Each request carries a client-generated token, and the server must respond to it in any result response. The token is similar to the message ID, marking the uniqueness of the message. The token is also a setting for message security, using a full 8-byte random number to prevent forged messages from passing verification.
Option
~
Both request messages and response messages can have 0 or more options. Mainly used to describe various attributes corresponding to the request or response, similar to parameters or feature descriptions, such as whether to use a proxy server, the port of the destination host, etc.
Payload
~
Actual data content, if present, preceded by the payload identifier “0xFF”. If there is no payload identifier, it indicates a payload of length 0. If a payload identifier exists but is followed by a payload of length 0, it must be treated as a message format error.
CoAP Protocol Message Types
The CoAP protocol is divided into 4 types of message types
CON: A request that requires confirmation. If a CON request is sent, the other party must respond. This method is somewhat similar to TCP, used for reliable message transmission. The model is shown in the figure below:
NON: A request that does not require confirmation. If a NON request is sent, the other party does not need to respond. This is suitable for messages that are frequently repeated, where packet loss does not affect normal operation. This method is somewhat similar to UDP, used for unreliable message transmission. The model is shown in the figure below:
Client Server
| NON[0x01a0] |
+---------------->|
| |
ACK: Response message, the response to the received CON message.
RST: Reset message, when the receiver receives a message containing an error or an unrecognized message, the receiver cannot reply with an ACK message and must respond with an RST message.
CoAP Request Codes and Response Codes
The request codes and response codes of CoAP correspond to the Code field in the CoAP protocol, similar to status codes in HTTP. Among them:
0.XX indicates a certain method of CoAP request.
2.XX, 4.XX, 5.XX indicate specific responses of CoAP.
Request Codes (0.XX)
Request Code
Description
[0.01]
GET: Used to retrieve a resource
[0.02]
POST: Used to create a resource
[0.03]
PUT: Used to update a resource
[0.04]
DELETE: Used to delete a resource
Response Codes (2.XX): Success Codes
This type of status code indicates that the request has been successfully received, understood, and accepted by the server.
Request Code
Description
[2.01]
Create: Response to POST and PUT methods, cannot be cached
[2.02]
Delete: Response to POST and DELETE methods, cannot be cached
[2.03]
Valid: Used to respond that the response specified in the request with Etag is valid, cannot contain payload
[2.04]
Changed: Response to POST and PUT methods, cannot be cached
[2.05]
Content: Response to GET method, can be cached
Response Codes (4.XX): Client Error Codes
This type of status code indicates that an error may have occurred on the client side, hindering the server’s processing.
Request Code
Description
[4.00]
Bad Request: Request error, server cannot process. Similar to HTTP 400
[4.01]
Unauthorized: No scope permission. Similar to HTTP 401
[4.02]
Bad Option: Request contains incorrect options
[4.03]
Forbidden: Server refuses the request. Similar to HTTP 403
[4.04]
Not Found: Server cannot find the resource. Similar to HTTP 404
[4.05]
Method Not Allowed: Illegal request method. Similar to HTTP 405
[4.06]
Not Acceptable: Request options and server-generated content options are inconsistent. Similar to HTTP 406
[4.12]
Precondition Failed: Insufficient request parameters. Similar to HTTP 412
[4.15]
Unsupported Content-Type: Media type in request is not supported. Similar to HTTP 415
Response Codes (5.XX): Server Error Codes
This type of status code indicates that an error or abnormal state occurred while the server was processing the request, which may also be due to the server’s hardware or software resources being unable to complete the request.
Request Code
Description
[5.00]
Internal Server Error: Internal server error. Similar to HTTP 500
[5.01]
Not Implemented: Server cannot support the request content. Similar to HTTP 501
[5.02]
Bad Gateway: Server received an erroneous response while acting as a gateway. Similar to HTTP 502
[5.03]
Service Unavailable: Server overloaded or undergoing maintenance. Similar to HTTP 503
[5.04]
Gateway Timeout: Server timed out while executing the request as a gateway. Similar to HTTP 504
[5.05]
Proxying Not Supported: Server does not support proxy functionality
CoAP Optional Fields (Option)
CoAP supports multiple options, which are described incrementally. The properties of options are as follows:
Critical Option: Options that must be understood by the receiver, or the message cannot be processed normally.
Elective Option: If the receiver does not recognize the option, it can be ignored without affecting normal message processing.
Unsafe Option: Options that cannot be forwarded by a proxy if unrecognized, not every critical option is an unsafe option.
Safe-to-Forward Option: Options that can still be forwarded by a proxy even if unrecognized.
Instances of options in the message must be stored in ascending order by number; the actual number of the option is determined by the delta value in this option + the delta value of the previous option; assuming the previous option’s number is 0, for multiple instances of the same option number, the delta value is 0.
Values 0-12 represent option delta; a value of 13 requires one byte in the option delta extension to store the actual option delta minus 13; a value of 14 requires two bytes in the extension to store the actual option delta minus 269; a value of 15 is reserved for the payload marker.
Option Length: Values 0-12 represent the number of bytes occupied by the option; a value of 13 indicates that one byte in the extension is required, and represents the option length minus 13; a value of 14 indicates that two bytes in the extension are required, and represents the option length minus 269; a value of 15 is reserved;
Option Value: The specific content of the option.
0-length character sequence
Opaque byte sequence
Unsigned integer
UTF-8 encoded Unicode string
Numbering method for CoAP options:
NO.
C
U
N
R
Name
Format
Length
Default
1
x
x
If-Match
opaque
0~8
(none)
3
x
x
–
Uri-Host
string
1~255
(see below)
4
x
ETag
opaque
0~8
(none)
5
x
If-None-Match
empty
0
(none)
7
x
x
–
Uri-Port
uint
0~2
(see below)
8
x
Location-Path
string
0~255
(none)
11
x
x
–
x
Uri-Path
string
0~255
(none)
12
Content-Format
uint
0~2
(none)
14
x
–
Max-Age
uint
0~4
60
15
x
x
–
x
Uri-Query
string
0~255
(none)
17
x
Accept
uint
0~2
(none)
20
x
Location-Query
string
0~255
(none)
35
x
x
–
Proxy-Uri
string
1~1034
(none)
39
x
x
–
Proxy-Scheme
string
1~255
(none)
60
x
Size
uint
0~4
(none)
Content-Format and Accept are used to indicate the media format of CoAP payload:
Uri-Host, Uri-Port, Uri-Path, and Uri-Query are related to the “location” and parameters of resources:
Content-Format: Specifies the media type of CoAP, described by integers; for example, application/json corresponds to integer 50, application/octet-stream corresponds to integer 40.
Accept: Specifies the media type in the response of CoAP, with the same definition as Content-Format.
Uri-Host: CoAP host name, e.g., iot.xxxx.org.
Uri-Port: CoAP port number, default 5683.
Uri-Path: Resource route or path, e.g., /temperature. Resource paths are in UTF8 string format, excluding the first “”.
Uri-Query: Access resource parameters, e.g., ?value1=1&value2=2, parameters are separated by “&”, and Uri-Query and Uri-Path are separated by “?”.
Content-Format description:
Media type
Encoding
ID
Reference
text/plain;
–
0
[RFC2026] [RFC3676]
charset=utf-8
[RFC5147]
application/link-format
–
40
[RFC6690]
application/xml
–
41
[RFC3023]
application/octet-stream
–
42
[RFC2045] [RFC2046]
application/exi
–
47
[RFC-exi-20140211]
application/json
–
50
[RFC7159]
Additionally, there is a format recognized by IANA that will also be widely used in the CoAP protocol, which is the CBOR format, understood as binary JSON format.
application/cbor: ID 60.
CoAP Example:
Example description: The CoAP client retrieves temperature data from the server using the GET method.
The CoAP request message uses a CON message, and the server must return an ACK message upon receiving the CON message.
The CoAP request uses the 0.01 GET method; if the operation is successful, the CoAP server returns a 2.05 Content.
The MID in the request and response must be identical, here it is 0x1234.
The Token field in the request response is empty.
The CoAP request includes an option, where the option type is Uri-Path, so the Option Delta value is 0+11=11.
Most IoT terminal devices are resource-constrained, with limited CPU, RAM, Flash, and network bandwidth.
Using TCP or HTTP for these devices is impractical.
Based on this consideration, the CoAP protocol was designed, applicable in NB-IOT, etc.
For devices like water meters that do not require persistent connections, using this protocol can enhance battery life and other capabilities.
Follow the WeChat public account “Rice Embedded Development Technology Sharing”, reply “WeChat” in the background to add the author’s WeChat, and note “Join Group” to be invited into the technical exchange group.
