## 1 Introduction
The charter clearly states that the \"initial work item of the WG is to define a protocol specification for CoAP that includes... the ability to support a non-reliable multicast message to be sent to a group of Devices to manipulate a resource on all the Devices in the group.\" The charter also states that \"the working group will not develop a reliable multicast solution\" [4]. Although multicast may be used to transmit the same request to several objects, multicast communication in LLNs has some disadvantages. For instance, it is more difficult to route multicast traffic with a minimum of message duplication at the receiving hosts than in the case of unicast. Furthermore, basic multicast is not reliable in an LLN, which is problematic for requests that require guaranteed delivery. Also, the creation of multicast groups, defining which objects should be addressed when using a particular multicast address, is hard to realize inside LLNs. Additionally, the use of network wide multicast increases the footprint of the code that needs to fit on the constrained objects, and it is to be expected that this functionality will not be available in many LLNs. As an alternative, unicast-based solutions may be considered. Some unicast-based solutions (such as reliable messaging) have been introduced to alleviate some of the problems above, but these features are insufficient. The current CoRE drafts do not foresee any unicast-based way to manipulate resources that are located on multiple smart objects with a single client request. To overcome this shortcoming and be able to perform such composite requests, intelligence is typically added to the client application to make it communicate with the smart objects individually. This leads to more complex user applications, and the added intelligence and programming cannot be easily shared with other applications. Furthermore, complex user applications may be unmanageable. Any modifications to those complex user applications may require significant testing time, thus limiting the flexibility of the user applications. Additionally a large overhead of communication between the client machine and the smart objects is generated, especially when many smart objects are involved in these actions. When the communication between the client and the smart objects is done across the Internet, delays are unpredictable and a sequence of actuator commands might arrive out of order and possibly have unwanted results. Furthermore, if the communication occurs over costly links, communication between the client and the smart objects might get unnecessarily expensive. In this paper we propose a novel solution for communication with a group of resources across multiple smart objects based on CoAP unicast. The group members can be homogeneous or heterogeneous, on a single node or on multiple nodes, or another group. The group that we create is itself exposed as a RESTful CoAP resource, and thus can be accessed by any CoAP client (including other constrained devices). We include optional validation of the group at creation time; we attach a profile to the created group and thus can customize its behavior and provide fine-grained control over it. We have implemented our solution and provide a functional and performance evaluation for it. In the past, we have already presented our concept along with an initial implementation in [1]. In this expanded article, we elaborate on the concept, add more advanced features to the implementation, compare our solution with multicast and evaluate its functionality and performance. The remainder of this paper is structured as follows: first, we will briefly provide an overview of CoAP in Section 2. We then discuss CoAP group communication requirements and related work in Sections 3 and 4. Next, in Section 5, we describe our approach in detail. In Section 6, we present our implementation and evaluate the functionally and the performance of our solution. In Section 7, we discuss the results and compare them to the requirements.