# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 5 Evaluation
### Performance Evaluation on a Wireless Sensor Testbed
#### 5.2.1 Congestion Control Optimizations  
Congestion control is an important aspect of group communication, especially in LLN, where resources are limited and network congestion can lead to extended response times and significant energy consumption due to frequent retransmissions of packets. CoAP provides basic congestion control by using the exponential back-off mechanism (Section 2.2.1) and by limiting the number of open requests from a client to any server to one request by default. Furthermore, CoAP specifies that, when using multicasts, a certain random delay should be inserted before replying to multicast requests. In CoAP terms, this delay is called leisure. The server could either use a default value for leisure or compute a value for it. If the server has a group size estimate \(G\), a target data transfer rate \(R\) and an estimated response size \(S\), a rough lower bound for leisure can then be computed as:  
\[Leisure_{lowerbound}=\frac{S\times G}{R} \tag{1}\]  
In our experiments, \(G\) was between five and 40, \(S\) equals approximately 80 bytes and the target rate \(R\) can be set to a conservative 8 kbit/s = 1 kB/s. The resulting lower bound for the leisure is then between 0.4 s and 3.2 s. However, since CoAP servers will often not be able to compute the leisure, we elected to use the default leisure value of 5 s, as recommended by [6], in all of our multicast experiments. For a more complete discussion of the leisure period and its estimation, we refer to Section 8.2 of [6]. CoAP does not specify a congestion control mechanism when a single client is communicating with many servers using unicasts, as is the case in our group communication solution. However, our experience shows that this can quickly lead to congestion. A simple solution for avoiding network congestion when using unicasts is to limit the rate at which requests are sent. This way, the group members will get the requests spread over a period of time, and thus, there replies will also be spread over a period of time in a similar way to leisure. In order to get the replies spread over a period _Leisure_, the EM should insert a delay between requests \(D\) that equals _Leisure_ divided by \(G-1\), e.g.,  
\[D_{lowerbound}=\frac{Leisure_{lowerbound}}{G-1}=\frac{S\times G}{R(G-1)} \tag{2}\] \begin{table}
\begin{tabular}{c c c} \hline \hline
**Node Type** & **Rmoni RM090** \\ \hline Contiki version & GitHub master branch: snapshot 2 July 2014 \\ Radio Duty Cycling (RDC) & Null-RDC \\ Media Access Control (MAC) & Carrier Sense Multiple Access (CSMA) \\ \hline Routing & Protocol: & RPL \\  & Mode: & Storing \\  & Max neighbors: & 50 \\  & Max routes: & 60 \\ \hline Multicast & Engine: & SMRF \\  & Max multicast addresses: & 6 \\ \hline Radio Frequency (RF) & GW1: & IEEE 802.15.4 channel 26 \\  & GW2: & IEEE 802.15.4 channel 25 \\  & Wi-Fi 1 and 2: & Wi-Fi Channel 13 \\ \hline CoAP & Version: & Draft-18 \\  & Leisure: & 5 s \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Evaluation experiments settings. For our experiments, we get \(D_{lowerbound}=100\) ms and \(D_{lowerbound}=82\) ms for \(G=5\) and \(G=40\), respectively. In order to verify the effect of the delay length, we conducted a series of experiments on the testbed to query an entity of five members and measure the response time, which is expressed as the time between the moment the client issues the request to the EM until it gets back the response. We repeated the same experiment for different delays between the requests sent from the EM to the members. We repeated the experiment 50 times for each setting and computed the averages. During these experiments, all Wi-Fi devices were turned off, and thus, no noticeable external interference was present. In [9], we have done the same experiments, but using the Cooja network simulator. Figure 7 shows the results of the experiments on the testbed and in Cooja. In general, there is a very good match between the results of the simulation and the results on the testbed.