# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 5 Evaluation
### Functional Evaluation
#### 5.1.1 Multicast Entities  
The functionality for creating, validating, using and deleting multicast entities has been implemented as described above. In this subsection, we demonstrate the main functionalities of the implementation using a series of screenshots covering the life cycle of a multicast entity (Figure 5). These screenshots are taken using the CoAP++ client Graphical User Interface (GUI).  
In Figure 5a, the client initiates a request to create a multicast entity consisting of three members. The members are three temperature resources on RM090 sensors. The EM first assigns a unique IPv6  
Figure 5: Screenshots using the CoAP++ client GUI to create, query and delete a multicast entity of three members. (**a**) Creating a multicast entity mcast1; (**b**) profile of mcast1; (**c**) querying mcast1 with default properties; (**d**) querying mcast1 with entity operation avg; (**e**) using mcast1 as an anycast entity; (**f**) deleting the entity mcast1.  
multicast address (ff1e::89:1) to the group and then asks all members to join this multicast group. The entity is created successfully and is ready for use since all members have reported that they have successfully joined the multicast group.  
Next, the client checks the profile of the newly-created entity (Figure 4(b)). The profile confirms that the entity uses multicast for communication (ect: multicast). Consequently, CoAP NON messages will be used to communicate with the members (emt: NON). The profile also shows that the entity supports four entity operations: lst, avg, min and max, where lst is the default operation, as it is the first operation in the list of supported operations. It further shows that the EM will wait until it receives three replies from the members before sending the combined reply to the client (enr: 3).  
Next, the client queries the newly-created entity without specifying any URI queries, and thus, the default entity properties (entity operation, entity number of replies, etc.) are applied. Figure 4(c) shows how the client receives a reply containing all members' values.  
Now, assume the client is not interested in the individual values of all members. As part of the request, the client uses the entity operation avg as part of the URI query to obtain the average temperature of all three sensors. By doing so, the EM now calculates the average and only sends the calculated value to the client (Figure 4(d)). The disadvantages of this approach is that the EM will wait until it receives replies from all members before sending the reply to the client and that it might not get all replies since multicast communication is not reliable. Thus, the client decides to set the entity number of replies to a single reply (enr = 1). By doing so, the EM will send a reply to the client as soon as it gets a reply from any of the members (Figure 4(e)). This way, the EM emulates anycast behavior, which is not supported by RPL.  
To complete the life cycle of this multicast entity, we show how the client deletes it in Figure 4(f). As a result of deleting the entity, the EM requests that all members leave the multicast group, waits until the members confirm that they have left the group and conveys the results to the client. To avoid further confusion (e.g., bookmarked URIs containing the multicast addresses), the EM will not use the same multicast address for new groups unless it runs out of addresses.