15Nov/1219

## COAP

In the following exercise, we are going to study the CoAP protocol (Constraint Application Protocol ) used in Wireless Sensor Network (WSN), to simplify implementation in Sensor Nodes which have very limited resources in term of memory, computing power and energy. The standard is generic and does not make any assumption on Layer 2, but in our case we will suppose that layer 1 and 2 are IEEE 802.15.4. At layer 3, the 6LoWPAN protocol compresses the 40 bytes of the IPv6 header into 20 bytes. Another characteristic of WSN, is the high error rate on the radio link which leads to frame losses.

## Basic CoAP protocol

CoAP standard states 1 :

The interaction model of CoAP is similar to the client/server model of HTTP. However, machine-to-machine interactions typically result in a CoAP implementation acting in both client and server roles (called an end-point). A CoAP request is equivalent to that of HTTP, and is sent by a client to request an action (using a method code) on a resource (identified by a URI) on a server. The server then sends a response with a response code; this response may include a resource representation.
Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport such as UDP. This is done logically using a layer of messages that supports optional reliability (with exponential back-off). CoAP defines four types of messages: Confirmable, Non-Confirmable, Acknowledgement, Reset; method codes
and response codes included in some of these messages make them carry requests or responses. The basic exchanges of the four types of messages are transparent to the request/response interactions.

Question 1 Draw the protocol stack of a Sensor Node

Request/Response Model

CoAP request and response semantics are carried in CoAP messages, which include either a method code or response code, respectively. Optional (or default) request and response information, such as the URI and payload content-type are carried as CoAP options. A Token Option is used to match responses to requests independently from the underlying messages (Section 5.3).
If the server is not able to respond immediately to a request carried in a Confirmable message, it simply responds with an empty Acknowledgement message so that the client can stop retransmitting the request. When the response is ready, the server sends it in a new Confirmable message (which then in turn needs to be acknowledged by the client). This is called a separate response, as illustrated in Figure 5.

                        Client              Server
|                  |
|   CON [0x7a10]   |
| GET /temperature |
|   (Token 0x73)   |
+----------------->|
|                  |
|   ACK [0x7a10]   |
|<-----------------+
|                  |
... Time Passes  ...
|                  |
|   CON [0x23bb]   |
|   2.05 Content   |
|   (Token 0x73)   |
|     "22.5 C"     |
|<-----------------+
|                  |
|   ACK [0x23bb]   |
+----------------->|
|                  |
Figure 5: A GET request with a separate response


Question 2 (1 point) What happens if the first CON frame is lost ?

Question 3 (1 point) Suppose that the request is “Add temperature by 1 degree” what happens if the acknowledgment of this request is lost ?

Question 4 (2 points) Define a Finite State Machine for this protocol for the sender.

The draft gives the CoAP PDU format :

CoAP messages are encoded in a simple binary format. A message consists of a fixed-sized CoAP Header followed by options in Type-Length-Value (TLV) format and a payload. The number of options is determined by the header. The payload is made up of the bytes after the options, if any; its length is calculated from the datagram length.

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T |  OC   |      Code     |          Message ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Message Format


The fields in the header are defined as follows:

Version (Ver): 2-bit unsigned integer. Indicates the CoAP version number. Implementations of this specification MUST set this field to 1. Other values are reserved for future versions.

Type (T): 2-bit unsigned integer. Indicates if this message is of type Confirmable (0), Non-Confirmable (1), Acknowledgement (2) or Reset (3).

Option Count (OC): 4-bit unsigned integer. Indicates the number of options after the header. If set to 0, there are no options and the payload (if any) immediately follows the header.

Code: 8-bit unsigned integer. Indicates if the message carries a request (1-31) or a response (64-191), or is empty (0).

Message ID: 16-bit unsigned integer. Used for the detection of message duplication, and to match messages of type Acknowledgement/Reset and messages of type Confirmable.

3.2. Option Format

Options MUST appear in order of their Option Number. A delta encoding is used between options, with the Option Number for each Option calculated as the sum of its Option Delta field and the Option Number of the preceding Option in the message, if any, or zero otherwise. Multiple options with the same Option Number can be included by using an Option Delta of zero. Following the Option Delta, each option has a Length field which specifies the length of the Option Value, in bytes.

    0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| Option Delta  |    Length     | for 0..14
+---+---+---+---+---+---+---+---+
|   Option Value ...
+---+---+---+---+---+---+---+---+

Figure 8: Option Format



The fields in an option are defined as follows:

Option Delta: 4-bit unsigned integer. Indicates the difference between the Option Number of this option and the previous option (or zero for the first option). In other words, the Option Number is calculated by simply summing the Option Delta fields of this and previous options before it.

Length: Indicates the length of the Option Value, in bytes. Normally Length is a 4-bit unsigned integer allowing value lengths of 0-14 bytes. The length and format of the Option Value depends on the respective option, which MAY define variable length values.

Options defined in this document make use of the following formats for option values:
-uint: A non-negative integer which is represented in network byte order using a variable number of bytes .
-string: A Unicode string which is encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198].

Question 5 (1 point) What is the advantage of using a TLV structure ?

The individual CoAP options are summarized in Table 1 and explained below.

   +-----+----------+----------------+--------+---------+-------------+
| No. | C/E      | Name           | Format | Length  | Default     |
+-----+----------+----------------+--------+---------+-------------+
|   1 | Critical | Content-Type   | uint   | 0-2 B   | (none)      |
|   2 | Elective | Max-Age        | uint   | 0-4 B   | 60          |
|   3 | Critical | Proxy-Uri      | string | 1-270 B | (none)      |
|   4 | Elective | ETag           | opaque | 1-8 B   | (none)      |
|   5 | Critical | Uri-Host       | string | 1-270 B | (see below) |
|   6 | Elective | Location-Path  | string | 1-270 B | (none)      |
|   7 | Critical | Uri-Port       | uint   | 0-2 B   | (see below) |
|   8 | Elective | Location-Query | string | 1-270 B | (none)      |
|   9 | Critical | Uri-Path       | string | 1-270 B | (none)      |
|  11 | Critical | Token          | opaque | 1-8 B   | (empty)     |
|  12 | Elective | Accept         | uint   | 0-2 B   | (none)      |
|  13 | Critical | If-Match       | opaque | 0-8 B   | (none)      |
|  15 | Critical | Uri-Query      | string | 1-270 B | (none)      |
|  21 | Critical | If-None-Match  | (none) | 0 B     | (none)      |
+-----+----------+----------------+--------+---------+-------------+

Table 1: Options


The annex of the document gives an example of how CoAP messages are coded.

Figure 12 shows a similar example, but with the inclusion of an explicit Token Option (Delta 9 + 2 = 11, Length 1, Value 0x20) in the request and (Delta 11 + 0 = 11) in the response, increasing the sizes to 18 and 12 bytes, respectively.


Client  Server
|      |
|      |
+----->|     Header: GET (T=CON, Code=1, MID=0x7d35)
| GET  |      Token: 0x20
|      |   Uri-Path: "temperature"
|      |
|      |
|<-----+     Header: 2.05 Content (T=ACK, Code=69, MID=0x7d35)
| 2.05 |      Token: 0x20
|      |

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 |   2   |     GET=1     |          MID=0x7d35           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   9   |  11   |      "temperature" (11 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   2   |   1   |     0x20      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 2 |   1   |    2.05=69    |          MID=0x7d35           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  11   |   1   |     0x20      |      "22.3 C" (6 B) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Confirmable request; piggy-backed response



Question 6 (2 points) Give the content of the four messages given in figure 5 with the Token option

Question 7 (1 point) In Figure 5, what would be the maximum payload size given that these messages are exchanged over an IEEE 802.15.4 network ?

## Block Transfert

Basic CoAP protocol is not fitted for large file transfer, for example to recover from a sensor all the measurement done during one day. To allow large file transfer, another draft draft-ietf-core-block-04 has been defined which allows blocks:

The size of the blocks is not fixed by the protocol. To keep the implementation as simple as possible, the Block options support a small range of power-of-two block sizes, from 2^4 (16) to 2^10 (1024) bytes. One of these seven values can be encoded in three bits (0 for 2^4 to 6 for 2^10 bytes), which we call the "SZX" (size exponent); the actual block size is then "1 << (SZX + 4)". (The actual size of the final block in a block-wise transfer may be less than or equal to the power-of-two block size.)

Question 8 (1 point) What are the possible block sizes when IEEE 802.15.4 data link layer is used ? What are the possible values of the SZX field ?

When a resource representation is larger than can be comfortably transferred in a single UDP datagram, a Block option can be used to indicate a block-wise transfer. The value of the option is a 1-, 2- or 3-byte integer, the four least significant bits of which indicate the size and whether the current block-wise transfer is the last block being transferred (indicated by the M or "more" bit). The option value divided by sixteen (the NUM field) is the number of the block currently being transferred, starting from zero.


0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  NUM  |M| SZX |
+-+-+-+-+-+-+-+-+

0                   1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          NUM          |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   NUM                 |M| SZX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Block option value


NUM: Block Number. The block number is a variable-size (4, 12, or
20 bit) unsigned integer. Block number 0 indicates the first block of a
representation.

M: More Flag (not last block). This flag, if unset, indicates that
this block is the last in a representation. When set it indicates
that there are one or more additional blocks available.

SZX: Block Size. The block size is a three-bit unsigned integer
indicating the size of a block to the power of two. Thus block
size = 2^(SZX + 4). The allowed values of SZX are 0 to 6, i.e.,
the minimum block size is 2^(0+4) = 16 and the maximum is 2^(6+4)
= 1024.

The Block options are used in one of three roles:

o In a request (e.g., GET), the Block Option gives the block number
requested to be returned in the response and suggests a block size
(in the case of block number 0) or echoes the block size of
previous blocks received (in the case of block numbers other than
0). In this case, the M bit has no function and MUST be set to
zero.

o A Block Option in a response (e.g., for GET), or
in a request (e.g., PUT or POST), describes what block number is
contained in the payload of this message, and whether further
blocks are required to complete the transfer of that body (M bit).
If the M bit is set, the size of the payload body in bytes MUST
indeed be the power of two given by the block size. With certain
exceptions given below, all blocks for a REST transfer MUST use
the same block size, except for the last block (M bit not set).

o In a response, the Block Option indicates what block number is
being acknowledged (e.g., for a PUT or POST request). In this
case, if the M bit is set it indicates that this response does not
carry the final response to the request; this can occur when the M
bit was set in the request and the server implements the request
atomically (i.e., acts only upon reception of the last block of
payload). Conversely, if the M bit is unset, it indicates the
block-wise request was enacted now, and the response carries the
final response to this request (and to any previous ones with the
M bit set in the response's Block1 Option in this sequence of
block-wise transfers). Finally, the block size given in such a
Block1 Option indicates the largest block size preferred by the
server for transfers toward the resource that is the same or
smaller than the one used in the initial exchange; the client
SHOULD use this block size or a smaller one in all further
requests in the transfer sequence.

and the draft gives an example:

In all these examples, a Block option is shown in a decomposed way
separating block number (NUM),
more bit (M), and block size exponent (2^(SZX+4)) by slashes. E.g.,
a Block Option value of 33 would be shown as 2/0/32), or a Block
Option value of 59 would be shown as 3/1/128.

In the example (Figure 4), the client is surprised by the need
for a blockwise transfer, and unhappy with the size chosen
unilaterally by the server. As it did not send a size proposal
initially, the negotiation only influences the size from the second
message exchange onward. Since the client already obtained both the
first and second 64-byte block in the first 128-byte exchange, it
goes on requesting the third 64-byte block ("2/0/64"). None of this
is (or needs to be) understood by the server, which simply responds
to the requests as it best can.

   CLIENT                                                     SERVER
|                                                          |
| CON [MID=1234], GET, /status                     ------> |
|                                                          |
| <------   ACK [MID=1234], 2.05 Content,   0/1/128        |
|                                                          |
| CON [MID=1235], GET, /status,   2/0/64           ------> |
|                                                          |
| <------   ACK [MID=1235], 2.05 Content,   2/1/64         |
|                                                          |
| CON [MID=1236], GET, /status,   3/0/64           ------> |
|                                                          |
| <------   ACK [MID=1236], 2.05 Content,   3/1/64         |
|                                                          |
| CON [MID=1237], GET, /status,   4/0/64           ------> |
|                                                          |
| <------   ACK [MID=1237], 2.05 Content,   4/1/64         |
|                                                          |
| CON [MID=1238], GET, /status,   5/0/64           ------> |
|                                                          |
| <------   ACK [MID=1238], 2.05 Content,   5/0/64         |

Figure 4: Blockwise GET with late negotiation


Note that in the previous example, the block number changes regarding the
block size.

For the rest of the exercise, we suppose that a Sensor Node has memorized 2 Kilo Byte of measurement, and a client downloads this information through the GET /log request.

Question 9 (1 point) When layer 2 is IEEE 802.15.4, give the maximum number of blocks needed for the transfer.

Question 10 (1 point) What will be the size of the block TLV?

Question 11 (1 point) In that case, what will be the size of the IEEE 802.15.4 frame at the physical layer ?

## Handling errors

The draft explains how errors are recovered :

In all these (and the following) cases, retransmissions are handled
by the CoAP message exchange layer, so they don't influence the block
operations (Figure 5, Figure 6).

   CLIENT                                                     SERVER
|                                                          |
| CON [MID=1234], GET, /status                     ------> |
|                                                          |
| <------   ACK [MID=1234], 2.05 Content,   0/1/128        |
|                                                          |
| CON [MID=1235], GE/////////////////////////              |
|                                                          |
| (timeout)                                                |
|                                                          |
| CON [MID=1235], GET, /status,   2/0/64           ------> |
|                                                          |
| <------   ACK [MID=1235], 2.05 Content,   2/1/64         |
:                                                          :
:                          ...                             :
:                                                          :
| CON [MID=1238], GET, /status,   5/0/64           ------> |
|                                                          |
| <------   ACK [MID=1238], 2.05 Content,   5/0/64         |

Figure 5: Blockwise GET with late negotiation and lost CON

CLIENT                                                     SERVER
|                                                          |
| CON [MID=1234], GET, /status                     ------> |
|                                                          |
| <------   ACK [MID=1234], 2.05 Content,   0/1/128        |
|                                                          |
| CON [MID=1235], GET, /status,   2/0/64           ------> |
|                                                          |
| //////////////////////////////////tent,   2/1/64         |
|                                                          |
| (timeout)                                                |
|                                                          |
| CON [MID=1235], GET, /status,   2/0/64           ------> |
|                                                          |
| <------   ACK [MID=1235], 2.05 Content,   2/1/64         |
:                                                          :
:                          ...                             :
:                                                          :
| CON [MID=1238], GET, /status,   5/0/64           ------> |
|                                                          |
| <------   ACK [MID=1238], 2.05 Content,   5/0/64         |

Figure 6: Blockwise GET with late negotiation and lost ACK
`

Question 12 (1 point) What information is used to notify the sender that the information is correctly received by the destination ?Give its size.

Question 13 (1 point) In the previous scenario (Figure 6), do we have an anticipation protocol ?

Suppose that the binary error rate is noted $\rho$ (i.e. bit error probability). We note, in Bytes, $B$ the block size and $O$ the overhead introduced by all encapsulations down to layer 1. $A$ will be the size of an acknowledgment frame at layer 1. We will call $T_{RTT}$ the round trip time (e.g. the time it takes to send a packet and receive an acknowledgment). Let $T_{Timer}$ be the value of the retransmission timer, if no acknowledgment is received after $T_{Timer}$ the PDU is sent again.

~

For this exercise, we will suppose that $T_{Timer} = 2.T_{RTT}$. We will neglect propagation delays and transmission speed will be 250 kbit/s.

Question 14 (1 point) What is the probability for a data frame to be received correctly ? What is the probability for an Ack frame to be received correctly ? What is the probability $P_{success}$ to have a correct exchange.

Question 15 (2 points) Compute the mean time to send correctly the log file.

Question 16 (2 points) When the binary error rate $\rho =0.05$, what is the best block size to send the file ?

Question 17 (1 point) Can you explain the results ? what should happen if the binary error rate goes higher ?

# Annex A: IEEE 802.15.4 Frame Format

Figure 1 gives the format of a IEEE 802.15.4 data frame. At the physical level, the frame start with a 4 byte preamble to allow clock synchronization, followed by Start Frame Delimiter (SFD) on 1 byte. The next byte contained (coded on 7 bits) the frame length (in bytes). At the MAC layer, the Frame Header contains a Frame Control field on two bytes giving the nature of the frame (Data, Acknowledgment, Control,...). The sequence number (on 1 byte) is a unique value issue by a sender that should match with the acknowledgment frame sent by the destination, the address field contains the layer addresses of the sender and the receiver. In our case we will consider that this field is 20 byte long. The Frame Check Sequence is on two bytes.

This content is published under the Attribution-Noncommercial-No Derivative Works 3.0 Unported license.

Tags: , , , ,

### 19 Responses to “COAP”

Question 1 Draw the protocol stack of a Sensor Node

• shahid says:

Hello Professor,Are layere 5,6 done by CoAP?

Hi,

Don’t focus on the layer numbers, but you are right 🙂 The layer just give you the layer functionality.  In that case, we can state that CoAP covers synchronization and data representation. For instance data will be structured as XML or  JSON to allow any device to process it. The content-type TLV  represents the nature of data.

Question 2 (1 point) What happens if the first CON frame is lost ?

If a CON is lost, the sender will not receive acknowledgement and so will send again the frame when the timer will expire

Question 3 (1 point) Suppose that the request is “Add temperature by 1 degree” what happens if the acknowledgment of this request is lost ?

In this example, either the Token or the Message-ID can be used to detect duplicate requests. In case of duplicate requests, the request will be ignored and just acknowledged.

Question 4 (2 points) Define a Finite State Machine for this protocol for the sender.

• jigyasa says:

Bonjour sirIn rennes when we solved this question instead of wait data you wrote wait ack in bottom circle.please tell me which one is correct or i made some mistake in copeing……..

You are right. Otherwise will have have twice the same state. Thanks. I will correct it.

• Gildas says:

Dear Professor,Do we need stop timer on “Received CON” ?We only start on “Data Request” and stop on “ACK” or “ACK + data” => no timer started on this state, right ?

Question 5 (1 point) What is the advantage of using a TLV structure ?

TLV allows to create new structures even when the protocol has been already deployed. In fact, if a receiver receiving a TLV with an unknown value, can discard this TLV knowing the length of the structure.

Question 6 (2 points) Give the content of the four messages given in figure 5 with the Token option

C->S

Header: ver=1, T = 0 (CON), OC=2, Code = 2 (GET) Msg-ID = 0X1234

TLV: T=9 (Uri-Path) L=11 V=temperature

TLV:T=2(9+2=Token) L=1 V=0x73

S->C

Header: ver=1, T=2 (Ack), OC=0, Code=0 (Ok) Msg-Id=0x1234

S->C

Header ver=1, T=0 (CON), OC=1 Code 2.02 (Ok) Msg-Id 0x54321

TLV:T=11 (Token) L=1 V=0x73

Data=”22.5 C”

C->S

Header: ver=1, T=2 (Ack), OC=0, Code=0 (Ok) Msg-Id=0x54321

Question 7 (1 point) In Figure 5, what would be the maximum payload size given that these messages are exchanged over an IEEE 802.15.4 network ?

At Layer 2, a Frame contains 127 bytes, but header and CRC are 25 bytes long, so 102 Bytes are remaining for IPv6 packets.

At layer 3, IPv6 header with 6LoWPAN compression is 20 byes long, so 82 Bytes are remaining.

At layer 4, UDP hedaer is 8 Bytes long, so 74 Bytes are remaining.

At CoAP level, the previous exchange shows that header is 7 Bytes long (4 Bytes for x header and 3 bytes for Token TLV), so 67 bytes remains for  data.

Question 8 (1 point) What are the possible block sizes when IEEE 802.15.4 data link layer is used ? What are the possible values of the SZX field ?

Even if we took a Block TLV of 3 Bytes, the possible block values are 16, 32 and 64 Bytes, so SZX varies between 0 and 2.

Question 9 (1 point) When layer 2 is IEEE 802.15.4, give the maximum number of blocks needed for the transfer.

We have to send 2 KB of information, the maximum number of bock will be obtain if we use the smallest possible block (16 Bytes), so we have 2*1024/16 = 128 messages

Question 10 (1 point) What will be the size of the block TLV?

to code 128 values, we need at least 8 bits, so a TLV on two bytes will be enough

Question 11 (1 point) In that case, what will be the size of the IEEE 802.15.4 frame at the physical layer ?

Question 12 (1 point) What information is used to notify the sender that the information is correctly received by the destination ?Give its size.

It is a ACK message, the size of an Ack message is 25+20+8+(1)= 54 Bytes