# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 5 Evaluation
### Functional Evaluation
#### 5.1.2 Extended Entity Features  
Our solution is flexible and can be used to build more complex entities than we have shown so far. Since entities have URIs and behave in the same way as any other CoAP resource, entities can themselves become part of other entities to build a hierarchy. To illustrate this, consider the following scenario.  
A large cold storage building consists of several floors with several cold storage rooms in each of them. In each room, there are at least three battery-operated CoAP-enabled wireless temperature sensors. For quality assurance purposes, it is required to centrally log the average temperature of each room every hour.  
The most straightforward solution is to query all of these sensor individually and to add all of the intelligence about the distribution and the processing of the individual values in the client application. However, using our solution, this can be accomplished in a hierarchical way as follows:  
1. Per room, create a room temperature entity containing all temperature sensors. Since every room has at least three sensors and is required to get the average temperature, the entity should use the entity operation eo=avg. Since the sensors are battery operated, they are likely to have a Radio Duty Cycles (RDC) with long sleep periods. Further, as only the average is needed, the administrator can decide for each room how many values are needed to build the average and set the entity number of replies accordingly, e.g., enr=2. To reduce the communication overhead, multicast communication with the sensors can be used, i.e., ect=multicast.
2. Per floor, create a floor temperature entity containing all of the room entities of the floor, i.e., as members the URIs of the previously created room temperature entities are used. Since it is expected to have values for all rooms, this entity can be created with default behavior, which implies eo=lst, enr=\"number of entity members\" and ect=unicast.  
3. Create one building temperature entity containing all floor temperature entities in a similar way as the floor temperature entities.
4. Query the building temperature entity to get results for all of the rooms in the building. The client can decide in which media type to get the reply. Using plain text might be useful for the client to view or to include in reports. Since in this scenario the data should be logged, it is more likely to request the data in a more structured format, such as SENML5+JSON [31], so it becomes easier to extract and add the values to a database.  
The example above can be easily extended in the hierarchy (e.g., building, campus, etc.). Entities created for one reason can be reused for other purposes, e.g., the room temperature entities can be used by the respective cooling system to control the temperature in rooms. This is true even if the entity should behave in a different way than it was created. For example, to troubleshoot heat distribution inside a room, a technician can query the same room temperature entity, but requesting to get a list of all individual sensor values in order to build a room heat map. From this example, one can see that entities can be configured and combined in flexible ways to suit the clients' needs.