# Experimental Evaluation of Unicast and Multicast CoAP Group Communication
## 3 Related Work  
As mentioned in the Introduction, the basis of our work is the newly-standardized Constrained Application Protocol (CoAP) [6] and the two main approaches to realize CoAP group communication. The first approach was published as an experimental standard for CoAP group communication [8] by the IETF CoRE working group, who was behind the standardization of CoAP itself. This standard specifies how CoAP should be used in a group communication context. It provides an approach for using CoAP on top of non-reliable IP multicast. The use of multicast is useful for many IoT scenarios, such as for service discovery. The authors of [17] proposed an alternative lightweight forwarding algorithm for efficient multicast support in LLNs targeting service discovery for duty-cycled constrained devices. Certainly, the use of multicasts allows reducing the amount of requests in the LLN, by sending one request to several destinations at the same time. However, the use of multicast has limitations, such as not being cache-friendly and not supporting secure communication (see Section 2.2.2). An alternative multicast-based group communication solution was presented in [18]. This work presented a concept of a web service-based communication stack that uses transient link-local IPv6 multicast addresses for process data exchange between nodes by binding a shared network variable to the IPv6 multicast address. By doing so, the authors were able to reduce the CoAP multicast size by eliminating the need to include the URI path to identify the group communication resource on the members. URI identifiers are text-based. As such, they can be verbose and have a severe impact on the CoAP header size, since no compression can be provided for them. Certainly, this approach has several advantages, such as eliminating the need for a control unit, offering a lower power consumption than using unicasts and its suitability in many non-critical use cases (due to the lack of reliability of multicasts). However, since this approach is based on IP multicast, it exhibits the limitations of multicasts as discussed in Section 2.2.2. In addition, to our knowledge, apart from simple performance evaluations, no larger scale evaluations of the performance of multicast solutions have been published. Consequently, at of the time of writing, clear insights into the behavior and performance of multicast operations in LLNs are missing. The second approach is to rely on unicast messages to realize CoAP group communication. In [9], we have introduced a unicast-based group communication solution that uses the notation of entities to represent groups of CoAP resources. We have evaluated it using simulations and small-scale demonstrations and showed that it complements multicast-based solutions when the reliability of the communication is desired. Another unicast-based group communication solution is called SeaHttp and was presented in [19]. The authors propose to extend CoAP with two additional methods (BRANCH and COMBINE) to allow members to join and leave groups without the need for a separate group manager. This means that members should have the intelligence to know which group they should join/leave. Constrained devices will not have this intelligence, so again, a \"manager\" will be needed to inform the devices so they can take appropriate actions. Furthermore, BRANCH and COMBINE may be able to reduce the number of messages; however, the trade-off is the need to implement a new mechanism. It is better to use an approach that can be plugged into any existing network without major modifications (or at least not a modification to every node). Finally, this approach does not have the flexibility we target, since group members have to be reprogrammed with the groups they should join each time the requirements of the user changes. To our knowledge, these are the only works that explore communication solutions for interacting with a group of CoAP-enabled constrained devices.