# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 4 Implementation
### EM Multicast Extensions  
We have extended our unicast-based solution to support communicating with the group members using IPv6 multicasts. We have also extended the existing features of our solution to support this new communication type. More specifically, we have defined a new profile field ect to specify the entity communication type. This field can take two possible values, namely ect = ''unicast'' or ect = ''multicast''.  
When a multicast entity is created, the EM assigns a new multicast group address to the entity and adds another field to the entity profile with the name mcastURI. This field specifies the URI to which a multicast address can be sent, when it is desired to communicate to the multicast group without going through the entity resource on the EM. This URI contains the IPv6 multicast address of the group and the resource name on the individual members, e.g., coap://[ffie::89:1]/s/t. Since the resource name has to be the same across all group members, the EM adds this check to the validation process of multicast entities. In our implementation, we used the following IPv6 multicast addresses ffie::89:xx  
\begin{table}
\begin{tabular}{c c c c} \hline \hline
**Method** & **URI Query** & **Request Payload** & **Description** \\ \hline GET & – & – & Show membership \\ POST & act = add & IPv6 address (array of bytes) & Join group \\ POST & act = del & IPv6 address (array of bytes) & Leave group \\ \hline \hline \end{tabular}
\end{table}
Table 4: The group membership management resource /mc interface.  
\begin{table}
\begin{tabular}{c c c} \hline \hline  & **ROM (Bytes)** & **RAM (Bytes)** \\ \hline Class 1 device & \(\approx\)100 \(k\) & \(\approx\)10 \(k\) \\ Zolertia Z1 & 92 \(k\) & 8 \(k\) \\ Rmoni RM090 & 256 \(k\) & 16 \(k\) \\ \hline TM (with one user defined multicast address) & 4176 & 1802 \\ SMRF (with one user defined multicast address) & 1516 & 322 \\ Additional multicast address & – & 18 \\ \hline Multicast group management resource & 1408 & 28 \\ \hline \hline \end{tabular}
\end{table}
Table 5: Resource availability and requirements. The available resources on sample devices and the requirements for various system components. TM, Trickle Multicast; SMRF, Stateless Multicast RPL Forwarding.  
where the first 16 bits of the address (ffle) indicate that the address is a non-permanently-assigned (\"transient\" or \"dynamically\" assigned) multicast address with global scope, and the xx is a 16-bit sequential number.  
The EM then uses the group membership management resource on the nodes to let them join the newly-assigned multicast address. The communication with the entity management resource on the constrained devices is done via unicast CON messages to ensure reliability. The group creation is considered successful only if all required members successfully join the group. In any case, the group creator is informed about the results of the multicast group join requests. Similarly, when a multicast group is deleted, all members are sent a unicast request to leave the multicast group, and the deleter of the group is informed about the results.  
An example of the creation and usage of a multicast entity is shown in Figure 4, where the client requested the creation of a multicast entity with two members. Consequently, the EM assigned a multicast address to the group and sent two unicast messages to the members asking them to join that multicast address. Once the EM received replies from all members that they joined the multicast group successfully, the EM notified the client about the address of the multicast group. Later, when the client queried the EM about the multicast group, the EM sent a multicast request to the group's multicast address, received two replies and sent back a combined reply back to the client.