## 2 Constrained Application Protocol
### CoAP Definition  
From a theoretical perspective, CoAP can be regarded as a two-layer protocol [11]. A message layer is used to deal with UDP, while the other layer is used for request/response interactions using methods and response codes, as done in HTTP. In fact, in contrast to the interaction model of HTTP, CoAP exchanges messages asynchronously. Thus, by splitting CoAP in two layers, request/response interactions would be transparent to the asynchronous nature of the message layer. Figure 1 shows the conceptual layering of CoAP.  
Reliability is provided by the message layer and is activated when Confirmable (CON) messages are used. It is implemented through end-to-end stop-and-wait retransmissions of requests with exponential backoff [11]. Furthermore, CoAP is able to match requests to responses so that it can detect if a message is duplicated. This is possible because messages are labeled with an identification number generated by the client and inserted into the CoAP header. Finally, a token is used for differentiating between concurrent requests. CoAP also defines Non-confirmable (NON) messages to allow sending requests that does not require reliability. The detection of duplicated messages is available in CON as well as in NON messages.  
A server receiving a CON request must acknowledge its receipt to the client that initiated the communication. The server might send an empty ACK to indicate that the response will be deferred. In this case, the client must acknowledge the arrival of the CON response message. Should the response be immediate, the ACK will contain the response and the transaction will end with the reception of the ACK. After sending a CON request message, the client starts a timeout with exponential backoff in order to retransmit the request periodically in case it has not been acknowledged. Finally, a server might send a RST response to indicate that it is not able to process the CON request. NON messages are used when reliability is not required.  
Request methods are constrained to GET, POST, PUT and DELETE methods of HTTP. As regards the response codes, CoAP defines its own codes and also uses a small subset of the HTTP codes.  
The CoAP message is composed of a header, options and a payload; the header has a length fixed to five bytes, while the options may have a variable length. Figure 2 shows the CoAP message format.  
Figure 3 shows the architecture of a CoAP-based WSN. According to [11], a CoAP WSN node can have the function of both client and server simultaneously. The term endpoint is used to refer to a CoAP node. However, in this paper we will refer to it as a server. This allows us to give greater emphasis to the function that the CoAP node has in our experiments and thus avoid confusion. A  
Figure 1: Layering of Constrained Application Protocol (CoAP).  
Figure 2: Message format.  
CoAP proxy can be used to enable the communication between a CoAP based WSN and a HTTP external network. This proxy can work also as a gateway for connecting to other WSNs. The implementation of the proxy is out of the scope of this paper.  
CoAP is particularly suitable for applications based on machine-to-machine communications. As an example, CoAP could be applied in smart energy applications to provide end-to-end connectivity to energy providers and the equipment of consumers.