# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 2 Group Communication
### CoAP-Based Group Communication
#### 2.2.1 The Constrained Application Protocol  
Recent research on embedded web services is laying the ground for a better integration of sensor resources into the service web. Since the dominating web protocol HTTP is too complex, the IETF Constrained RESTful Environments (CoRE) working group has designed a simpler web protocol, CoAP, and defined it in Request For Comment (RFC) 7252 [6]. CoAP uses the same RESTful principles as HTTP, but it is much lighter, so that it can run on constrained devices [2; 12]. To achieve this, CoAP has a much lower header overhead and parsing complexity than HTTP. It uses a four-byte base binary header that may be followed by compact binary options and payload.  
The CoAP interaction model is similar to the client/server model of HTTP. A client can send a CoAP request, requesting an action (specified by a method code) on a resource (identified by a Uniform Resource Identifier (URI)) on a server. The CoAP server processes the request and sends back a response containing a response code and payload.  
A message that does not require reliable transmission can be sent as a Non-confirmable Message (NON). This type of messages is not acknowledged, but has a message ID for duplicate detection (see Figure 1). Unlike HTTP, CoAP deals with these interchanges asynchronously over a datagram-oriented transport, such as User Datagram Protocol (UDP), and thus, a NON might get lost without the client and the server noticing it. Multicast CoAP requests are sent using NONs.  
Since UDP does not provide reliable communication, optional reliability is supported within CoAP itself. This is done by using Confirmable Messages (CONs) to implement simple stop-and-wait retransmissions with exponential back-off. Figure 2 shows an example for a co  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Requirement** & **Description** \\ \hline Flexibility & accommodate the differences between devices and device types \\ Light-Weight & limited footprint and should scale with the number of groups \\ Use of Standards & allows the creation of groups across members from different vendors \\ Performance & little overhead, efficient in the use of resources \\ Error Handling & mechanisms for reporting and handling error conditions \\ Reliability & sometimes it is not essential to get reliable replies from all group members \\ Ease of Group Manipulation & easily adapt groups based on changes of user needs \\ Expressiveness/Control & processing individual member results and replying with aggregated results \\ Security & compromising the group means compromising all of the individual members \\ \hline \hline \end{tabular}
\end{table}
Table 2: Group communication requirements.  
Figure 1: Example of CoAP Non-confirmable Message (NON) exchange. A Message ID (MID) is needed in the header for duplicate detection.  
The Message ID (MID) must be the same in order to match Acknowledgment Messages (ACKs) with CONs and for duplicate detection. The token must be the same in order to match replies with requests. If the client does not receive an ACK for its CON within an initial back-off time, it retransmits the same CON again. By default, the initial back-off is set to a random time between 2 s and 3 s. This means that if a reply to a confirmable packet is not received within the initial back-off time, the CoAP sender will double the initial back-off time and retransmit the packet. If a reply to the first retransmission is not received, CoAP will again double the back-off time and retry the transmission until MAX_RETRANSMIT (by default, four) is reached. If no reply is received after expiry of the back-off time of the last retransmission, the client will be notified about the error condition.  
Finally, CoAP supports optional security by using Datagram Transport Layer Security (DTLS) [13].