## 4 Existing Solutions  
As mentioned, to address the group communication needs, the IETF CoRE Working Group has developed the \"Group Communication for CoAP\" Internet Draft [14]. This draft discusses fundamentals and use cases for group communication patterns with CoAP and provides guidance for how the CoAP protocol should be used in a group communication context. The draft provides an approach for using CoAP on top of non-reliable IP multicast and does not attempt to provide a reliable solution for CoAP group communication as set forward by the Working Group charter. 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, multicasts are not cache-friendly, preventing possible reduction of requests and replies by utilizing caches. Depending on the use case and network topology, the reduction of packets as a result of using a cache can be better than the reduction obtained from using multicasts. This approach exhibits the limitations of multicasts as discussed in Section 1. Also multicasts are not useful when a single user action needs to trigger different sensor requests, since one multicast request delivers the same message to all group members. Additionally, secure communication with the group members is not possible, since all communication based on this draft operates in CoAP NoSec (No Security) mode. Finally, multicast is not supported on all LLN MACprotocols, especially MAC protocols that use Radio Duty Cycles (RDC) to shut down their radios when not in use. For example Xmac does not support multicast since it shuts down its receiver to avoid overhearing. Special MAC protocols that support multicast have been proposed such as in [17]. Interestingly, this MAC protocol will send the multicast data to each receiver one by one (unicast) if the multicast data drops below a certain threshold. As mentioned, the use of multicast as a means to interact with multiple objects concurrently requires multicast support in the network. Typically IP multicast relies on topology maintenance mechanisms to discover and maintain routes to all subscribers of a multicast group. However, maintaining such topologies in LLNs may not be feasible given the available resources. As a result, special multicast protocols have been proposed for the use inside LLNs. For example, the \"Multicast Protocol for Low power and Lossy Networks (MPL)\" internet draft uses the Trickle algorithm to manage message transmissions for both control and data-plane messages and avoids the need to construct or maintain any multicast forwarding topology [18]. An alternative is the stateless multicast RPL forwarding algorithm (SMRF), which according to [19] achieves significant delay and energy efficiency improvements at the cost of a small increase in packet loss. Regardless of the used multicast protocol, all nodes on the path between the sender and receivers must be extended to support the protocol. The \"Group Communication for CoAP\" Internet Draft was the basis for the work presented in [20], in which web services based CoAP multicasts were used to access data from Building Automation Systems (BAS). It shows how using multicasts allows creating basic building control scenarios without the need of a central control unit. Certainly this approach has several advantages such as eliminating the need for a control unit, often less power consumption than using unicasts and its suitability in many non-critical use cases (due to the lack of reliability of multicasts). However this approach exhibits the limitations of multicasts as discussed in this section above. Simple unicast solutions are defined in the CoRE Interfaces draft [21]. Among other interface types, this draft defines the Batch interface type and its extension, the Linked Batch interface type. Batch interfaces are used to manipulate a collection of sub-resources at the same time.