CoAP brings the web model of HTTP to devices that are too small for HTTP. A CoAP client reads and writes resources on a server with GET, PUT, POST and DELETE, just as a browser does. But CoAP runs over UDP and uses a 4-byte binary header. This page starts from the official definition and then looks at the message format. It ends with how a request and its response travel over an unreliable network.

• What is CoAP ?
• What does a CoAP message look like ?
• How does a CoAP request and response work ?
• Reference

What is CoAP ?

CoAP stands for Constrained Application Protocol.  The official definition of CoAP is defined in RFC 7252 as stated below. The definition is dense, so read it once for the highlighted phrases. Together they give the three ideas of CoAP : constrained nodes, a request/response model, and easy mapping to HTTP.

The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.

This definition can be illustrated as follows

Figure 1. The name CoAP taken apart. Constrained describes the devices, and Application Protocol means a protocol similar to HTTP but much lighter, based on the REST model.

• Constrained Device : the left branch lists limited processing power, limited memory and a low energy source. The devices at the bottom are IoT / M2M Devices such as a coffee machine, a meter and a watch.
• Application Protocol : the right branch starts from the many application protocols already in use, shown as a browser, FTP and SIP. CoAP is the one that is similar to Http but much lighter.
• REST model : the last cloud names the design that CoAP shares with HTTP. The client acts on resources that a URI identifies.

REST is the reason CoAP maps so easily to HTTP. Both protocols use the same four methods on resources named by URIs, and both return a response code with a payload. A proxy can therefore translate an HTTP GET from the Internet into a CoAP GET toward a sensor, and translate the answer back. The difference is in the transport. HTTP runs over TCP and repeats text headers in every request. CoAP runs over UDP, on port 5683, or on port 5684 with DTLS, and it codes the same information in a few bytes.

CoAP and MQTT are often compared, but they follow different models. MQTT is publish/subscribe through a Broker. CoAP is request/response between a client and the device that holds the resource. The two can look similar when CoAP uses the Observe option, because the server then keeps sending new values of a resource to the client.

• CoAP is a compact HTTP for constrained devices : the same REST methods and response codes, in a binary form.
• CoAP runs over UDP : it adds its own light reliability instead of using TCP.
• A proxy connects CoAP to the web : the shared REST model makes the translation to HTTP simple.

What does a CoAP message look like ?

A 6LoWPAN link carries frames of about 127 bytes, so every byte of header matters. Let's see how CoAP packs a request into as little space as possible. The table below lists the fields of a CoAP message in the order they appear on the wire.

Only the first 4 bytes are fixed. Ver, T and TKL share the first byte, the Code takes the second, and the Message ID takes the last two. So the smallest CoAP message is 4 bytes, and an empty ACK is exactly that size. Compare this with an HTTP request, where the method and the headers alone are often more than 100 bytes of text.

The Code field carries both requests and responses. A class of 0 means a request, and the detail gives the method. Classes 2, 4 and 5 mean success, client error and server error, like the 2xx, 4xx and 5xx codes of HTTP. So 2.05 Content plays the role of HTTP 200 OK, and 4.04 Not Found is the CoAP form of 404.

The options replace the HTTP headers. Each option carries only the difference from the previous option number, so a short option often takes a single byte of header. The URI of the request, for example /temperature, travels as one Uri-Path option per path segment.

• The fixed header is 4 bytes : Ver, T, TKL, Code and Message ID.
• Code c.dd covers requests and responses : class 0 is a method, and classes 2, 4 and 5 follow the HTTP status classes.
• Options are delta coded : this keeps a typical request header to a few bytes.

How does a CoAP request and response work ?

UDP gives no delivery guarantee, and a lossy 6LoWPAN network drops packets often. So CoAP needs its own way to make a request reliable. It does this with the message Type, and not with a connection.

A client that needs an answer sends a Confirmable (CON) message. The receiver must answer it with an ACK that carries the same Message ID. If no ACK arrives, the client retransmits the same message. The first timeout is between 2 and 3 seconds, and it doubles after each retry, up to 4 retransmissions. A message that does not need reliability, such as a periodic sensor reading, goes as Non-confirmable (NON) and gets no ACK. The table below shows the most common case, a GET with the response carried in the ACK.

This pattern is called a piggybacked response, because the response rides in the ACK. If the server needs time to prepare the answer, it first sends an empty ACK to stop the retransmissions. Later it sends the response in a new CON message with a new Message ID. The Token lets the client match this separate response to the original request. This is why CoAP needs both a Message ID and a Token.

Two more features complete the picture. With the Observe option, defined in RFC 7641, a client registers once, and the server sends a new response each time the resource changes. With resource discovery, defined in RFC 6690, a client sends GET /.well-known/core and receives the list of resources on the device. Both work over the same message format described above.

• CON and ACK give reliability over UDP : the client retransmits with exponential backoff until the ACK arrives.
• Message ID and Token do different jobs : the Message ID pairs a CON with its ACK, and the Token pairs a request with its response.
• Observe turns a GET into a subscription : the server pushes each new value of the resource to the client.

Reference

[1] How to learn CoAP in 5 minutes #IoTFriday (YouTube)

[2] Constrained Application Protocol (CoAP) Tutorial (YouTube), Slide for this presentation

[3] Intro to REST (YouTube)

[4] HTTP vs CoAP in one slide (Tweeter)

[5] CoAP: The IETF's New Protocol for the Internet of Things (YouTube)