# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 4 Implementation
### Multicast Group Management Using CoAP  
By default, Contiki nodes join four multicast groups when multicast is enabled on them. All of these groups have link-local scope, and thus, the IPv6 multicast addresses of all of them start with ff02: (Table 3). The first three addresses are the same for all nodes, since these are generic addresses representing all nodes, all routers and all RPL-enabled nodes on the local network segment. The last address is unique for each node and depends on the node ID. This address is called the solicited-node multicast address and is created by taking the last 24 bits of the nodes unicast address and appending this to the prefix ff02::1:ff00:0/104 [28]. The solicited-node multicast address is used in neighbor discovery for obtaining the Layer 2 link-layer addresses of other nodes [29].  
In addition to the four default multicast groups that the nodes join automatically, the Contiki multicast implementation allows specifying other multicast groups to join as needed. However, the maximum number of groups to join is set at compile time. By default, a node can join only one group in addition to the groups listed in Table 3. This maximum number of groups that a node can join can be changed at compile time. For each additional multicast address, the node requires 18 bytes  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Group IPv6 Address** & **Description** \\ \hline ff02::1 & All nodes on the local network segment \\ ff02::2 & All routers on the local network segment \\ ff02::1a & All RPL nodes on the local network segment \\ ff02::1:ff00:xx & Solicited-node multicast address. xx: node ID \\ \hline \hline \end{tabular}
\end{table}
Table 3: When multicast is enabled on Contiki nodes, they automatically join four link-local groups. RPL, IPv6 Routing Protocol for Low-Power and Lossy Networks.  
of RAM. When using the nodes in a static setting, the multicast address(es) can be hard coded when the node is programmed. However, since many group communication scenarios require frequent group membership changes, it is essential to have a solution that allows changing a node's group membership on the fly without the need to reprogram it. We have provided such a solution using the same technology that we use to communicate with nodes, i.e., using CoAP. By using CoAP for this task, as well, we eliminate the need for a dedicated group management protocol and can keep the solution lightweight.  
In order to offer a RESTful interface for multicast group membership on the constrained devices, we extended the Erbium implementation on these devices with a new CoAP resource: /mc. This resource can be used to list the multicast addresses of the groups that a node has joined, to join a new group and to leave a group. Table 4 documents the interface to the group membership management resource.  
The footprint of the multicast group membership resource is small. It requires only 1408 bytes of ROM and 28 bytes of RAM when compiled with gcc 4.6 for the RM090 nodes. In Table 5, we provide resource availability for the nodes that we used in our tests along with the resource requirements of the two available multicast implementations and our multicast membership management resource.