## 6 Implementation and Evaluation
### Theoretical Calculation
#### 6.3.6 Impact of Caching  
As mentioned in Section 2.1 CoAP foresees a freshness model for responses. A CoAP server may include a Max-Age option in the reply to indicate the maximum time a response may be cached before it is considered not fresh. If this option is not included in any CoAP response, it can be assumed that the response will be fresh for 60 s and thus will not be queried again by a cache within this time frame. Max-Age values in responses should take into consideration the frequency at which the value of the corresponding resource changes. By doing so, unnecessary queries to constrained devices can be heavily reduced, especially for resources that do not change frequently. When a client makes a multicast request, the cache always makes a new request to the multicast group (since there may be new group members that joined meanwhile or ones that did not get the previous request) (see Section 8.2.1 of the CoAP draft [5]). So, the main problem is that the cache is not aware of all receivers in a multicast group. This information is needed in order to be able to verify whether a response for all receivers in the multicast group has been cached. If the cache knows this information (which is not the case for a normal cache), the cache could serve the multicast request. But even then the multicast has to propagate in the network as soon as one of the responses is missing. In order to test the behavior of both group communication approaches when caches are used, we have conducted a series of tests using our star topology in its 1-hop configuration with five members. In the tests we varied the time between requests to the group in 5 s increments and measured the number of packets transmitted inside the LLN and the response time. We sent 60 requests per experiment. The experiments were conducted without introduction of any packet loss. The average number of packets transmitted inside the LLN is shown in Figure 23. As expected when using multicasts, regardless of the frequency at which requests are sent, there was always one request and five replies from the five members resulting in an average value of 1.2, 5.2 and 7.2 packets/member for group members that are 1-, 2- and 3-hops away from the EM respectively. On the other hand, when using our unicast based solution the average number starts at 0.04, 0.07 and 0.1 packets/member and increases in steps to reach two, four and six packets/member for group members that are 1-, 2- and 3-hops away from the EM respectively. The reason for this behavior is that the initial requests are always sent to all members as the cache is still empty. Since the replies in our example did not include the Max-Age Option, the cache assumed that the replies were valid for the default value of 60s. Subsequent requests were thus served from the cache as long as the first replies were still considered fresh. Once the Max-Age value expired new requests were sent to the members again. Figure 24 shows the response times for the requests for both group communication approaches, when a cache is used for the cases in which the group members were 1- and 2-hops away from the EM. For multicast the response time is between 2 and 6 s regardless of the delay between requests. In the case of our group communication approach one can see that there are two groups of replies. The first group is between 0.20 and 0.25 s and the second group is higher than 0.3 s. The first group represents the replies that were served from the cache, while the second group represents the replies that were not fresh in the cache and thus obtained from the group members. With the increase of the time between the requests, one can observe how the number of replies served from the cache decreases. When the time between requests becomes larger than Max-Age, the number of requests served from cache becomes zero. The cache stores the individual replies from the group members. This makes it possible to benefit from the cache even when different clients request a different Entity Operation.