## 7 Discussion  
In this section we look again at the requirements for the IoT scenarios as presented in Section 3 and discuss how our solution addresses these requirements. We also provide the drawbacks of our solution in light of these requirements and the insights gained from experimental evaluation of our solution. 1. _Flexibility_: our CoAP group communication solution is highly flexible when compared to other solutions. Other than supporting the standard base CoAP protocol, group members do not have to support any additional extensions. Since group definition and behavior are set on the Entity Manager only, changes and extensions can be done on the Entity Manger without the need for any changes on the individual members. We support homogeneous and heterogeneous entity in terms of their CoAP resources. A group can be built from members as along as the have a shared subset of CoAP methods. Members do not have to offer the exact resource name or the same content-type, since the Entity Manger can take care of conversion when possible. Since we use IPv6 unicasts for communication between the Entity Manager and the members, the members can be located anywhere on the IPv6 Internet as long as they are reachable. 2. _Light-Weight (footprint)_: since our solution does not require any additions to standard CoAP implementation, it can run on Class 1 devices as already demonstrated in the three CoAP plugtest events. Furthermore the members do not store any information about which groups they are part of. Thus our solution scales well with the number of groups a certain member can be part of. 3. _Use of Standards_: our Solution is based on CoAP, which is expected to become the application layer standard the IoT. We rely only on the base CoAP standard and require no optional extensions to it. However, if available, the resource profile extension can be used to better  
Figure 26: Average entity validation time. understand the capabilities on the individual members in order to apply advanced features such as content type conversions. 4. _Performance_: as our solution uses only standard CoAP over unicast UDP/IPv6 it is a cache friendly solution. Caches are a powerful tool in reducing the number of messages inside LLNs and enhancing response times. However only CoAP GET method can be cached and thus no benefit of caches can be expected for the other CoAP methods (_i.e._, GET for actuator data). Nevertheless, in these cases it is often more important to reliably deliver the message even if performance is reduced as a result. 5. _Validation and Error Handling_: we support heterogeneous members that might have properties that cannot be combined. Thus whenever a group is created the Entity Manager tries to validate the group in order to make sure that the group works as intended and informs the creator about the validation results. By giving the possibility to build the reply from just a subset of the members, the group becomes tolerant in handling certain error conditions such as node or route failures. 6. _Reliability_: by using CoAP confirmable messages we rely on CoAP retransmission mechanisms to handle reliability of communication with the entity members. In addition it is possible for the EM to customize the parameters for retransmissions (number of retransmissions and time-outs) for all or certain group members based on the history of communication with these members. 7. _Ease of Group Manipulation_: if the needs of the user change with time, our solution enables changing group memberships based on these needs by just changing the entity definition on the EM. The group members are not involved in this change and do not need to be reprogrammed or reconfigured in any way. By integrating the resources of the members and the Entity Manager into a resource directory, it becomes easy to locate and combine resource into new entities. This can benefit both machine-to-machine resource discovery as well as end user using Graphical User Interfaces to browse and build new entities. 8.