# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 5 Evaluation
### Performance Evaluation on a Wireless Sensor Testbed
#### 5.2.1 Congestion Control Optimizations
The figure clearly shows the need for the delay between the requests. Without inserting the delay, the response time of the entity was about 3 s. When using a delay of 0.1 s as calculated from Equation (2), the response time drops to 550 ms and is very close to the minimum value of 390 ms that was achieved for a delay of 50 ms. In order to verify whether the same relationship exists between the delay and the response time for other group sizes, we have repeated the same set of experiments on the testbed using additional group sizes (\(g=10,20,30,40\)). At the time of experimenting with 30 members, one testbed node did not start properly, leaving only 29 group members in the experiment. Figure 8 shows the results of those experiments. Since the EM sends the requests to the members sequentially, it is expected that the response time for the complete entity gets larger as the group size gets larger. This relationship is very obvious in the figure. Regardless of this fact, one can see that graphs for all of the group sizes follow the same pattern. To further analyze the relationship between the delay and the group size, please consider Figure 9, which shows the same results as Figure 8, but this time normalized over the group size \(G\). In a star topology, such as in our case, where all members need to communicate with the root of the star (the GW), one expects that the average response time would increase as the number of neighbors increases, resulting in a higher number of collisions on the shared medium. This is indeed the case when we compare any larger group size with the group of five members. However when comparing the larger groups together, this relationship cannot be observed. The reason for this is that with the increase of the group size and the way nodes are distributed over the testbed, members become no longer directly reachable from the GW, and their traffic was routed  
Figure 7: Response time of an entity with five members as a function of the delay between individual requests, evaluated using both a simulator and the experimental testbed. via other members. Consequently, the average hop count (_h_) was also increasing from just one hop for the group of five members to 2.4 hops for the group of 40 members, while the maximum hop count increased from one to five (see Table 7). A higher hop count implies that a lower percentage of members can communicate directly with the GW. It also means that a lower percentage of nodes is in the collision domain of the GW. This makes it possible that more parallel communication can happen inside the Wireless Sensor Network (WSN) before they reach the collision domain of the GW where the bottleneck is located. Figure 8: Entity response time for different group sizes as a function of the delay between individual requests, evaluated using the testbed. Figure 9: Entity response time per member for different group sizes as a function of the delay between individual requests to members, evaluated using the testbed. Regardless of the small changes in the values for the various groups, we observe that the shape of the relationship function is very similar among all of them. The response times were always improved significantly when the delay was around the recommended range of 82 ms to 100 ms. However, as the delay between requests grows larger, it becomes the dominating factor for the total response time with a linear relationship between the two. Another indicator of the performance of any communication solution is its reliability. During the tests we conducted in this section, the reliability of the communication was always 100% for all group sizes lower than 40. This is not surprising, since we had no external interference, and the only cause for errors was internal collisions. For the group size of 40, the reliability of member replies was never 100%. It was always between 99.8% and 99.9%, regardless of the delay between requests.