## 3 Group Communication Requirements  
In our work we broaden the _CoAP group communication_ definition from Section 2.4: CoAP-based group communication is a _method to manipulate a group of resources on devices using CoAP as the underlying protocol_. Such a group of resources is called an _entity_ and the resources themselves are called the entity _members_. We classify two types of entities based on the entity members:  
* _Homogeneous Entity_: is an entity in which the members share a common set of properties (URI path, method, content-type, block-size, observe, _etc_). * _Heterogeneous Entity_: is an entity in which not all members share a common set of properties. Within this context, we now define the requirements and goals for CoAP group communication and motivate their importance in the context of IoT applications, constrained devices and LLNs:  
1. _Flexibility_: as it is expected that the IoT will contain a huge amount of devices, it is also expected that the amount of device types will be enormous. To interact with a subset of these devices in a group, the group communication solution should be very flexible to accommodate the differences between devices and device types. In particular the solutions should be flexible enough to offer:* Support for homogeneous and heterogeneous groups. CoAP servers may be heterogeneous in terms of their CoAP resources, even if they provide the same functionality. For example the IPSO (Internet Protocol for Smart Objects) Alliance has published an Application Framework that recommends a classification of resources based on their functionality by defining a set of Resource Types [15]. However even if a group of resources offers the same functionality (same resource type), the actual resource path of the resource on different group members might be different. In some cases one might even want to have a group of resources with different resource types and simply query it (e.g., collecting heterogeneous environmental data). Also other types of heterogeneity in the resources are possible: e.g., different payload to PUT request, different media-types, _etc_. * Support of group members that are not part of the same network. Often, it is assumed that all members in a group belong to the same network. However, group communication solutions should not be limited to this setting. In the future, it may as well be that group communication involves nodes from different sensor networks, networks that may be co-located or spread over different locations. 2. _Light-Weight (footprint)_: the group communication solution should have limited footprint on constrained devices. It is expected that a lot of the IoT devices will be of Class 1 (\(\sim\)10 KB of RAM, and \(\sim\)100 KB of ROM) [16]. Any overhead involved by a group communication solution should not prevent the solution from running on Class 1 devices. Furthermore the solution should scale with the number of groups a certain member can be part of. 3. _Use of Standards_: to allow the creation of groups across a variety of members from different vendors and domains, it is mandatory to use standard protocols that are widely supported. The focus of our work is on using CoAP as an application layer standard protocol. As mentioned in Section 2, CoAP consists of a base protocol and a set of optional extensions. It is expected that not all CoAP servers will support all CoAP extensions. Thus it becomes essential to limit the use of optional extensions in order not to exclude potential CoAP servers of becoming group members due to missing extensions. 4. _Performance_: CoAP is designed to run on resource constrained devices. In order to keep it this way, any CoAP group communication solution should have little overhead and be efficient in the use of resources of the nodes and the LLN. In particular the number and size of messages sent in the LLN should be kept to a minimum, in order to conserve valuable node energy (nodes are often battery powered, or harvest energy from the environment).