## 5 Group Communication Using Unicasts
### System Overview  
We call the component that manages the entities, the Entity Manager (EM). This component, which can reside, e.g., on the Border Gateway of the LLN, is responsible for maintaining entities that are created from groups of resources residing on CoAP servers (_i.e._, sensors and actuators) inside the LLN. Clients on the Internet can interact with an EM to create new entities and/or customize how these entities should behave. Optionally the client can elect to contact a resource directory [12] in order to discover which resources are available in the network. Figure 4 shows an overview of the involved components.  
The EM functionality does not have to be put on a dedicated device. Theoretically any CoAP server can be extended to become an EM (Figure 5). The choice of the most appropriate location to put the EM functionality depends on the size and topology of the network. For example, it can reside on a smart object in the constrained network with enough resources, in the Cloud, on the client device itself, or on a gateway at the edge of the LLN. The latter case has the added benefit that security can be centrally managed besides offloading the processing from constrained devices. One can also decide to implement multiple EMs (at the same or at different locations) to avoid having a single point of failure and thus improving reliability, availability and scalability.  
Regardless of the location of the EM, it will serve as a \"proxy\" between the client and the constrained devices. Client requests will be sent to the EM, which will analyze and verify the requests and then issue the appropriate requests to the constrained devices using CoAP. Once the EM receives responses from the constrained devices, it will combine them according to the needs of the client and will send back an aggregated response to the client.  
Figure 4: Clients create entities consisting of several smart object resources on the Entity Manager. Clients can optionally query a resource directory to discover the existence of the resources.  
Figure 5: The Entity Manager functionality can be integrated into any CoAP server. The optimal location for the EM depends on the use case.  
When a client tries to create a new entity consisting of a group of resources inside LLNs, the EM performs a sanity check on the request in order to make sure that the resulting entity would make sense. For example it verifies that the resources inside the entity are valid, whether they support a certain content format and whether their data can be aggregated. Customization of the entity behavior is accomplished by creating profiles for the entities. A profile of an entity can specify for example whether to return the values of all resources in the entity, only the computed average of all values or a subset of all values. Figure 6 shows a high-level structure of the Entity Manager. It shows that the EM contains two databases:  
* _Entity Database_: in this database all entities are stored along with their profiles as defined by the user.
* _Capabilities Database_: this optional database provides rules and knowledge that can be used to match user requests with sensor capabilities. This can be as simple as translating a request for temperature in degrees Celsius while obtaining the data from a sensor that only supports Fahrenheit. It can also be more complex, e.g., converting resource representations from one content format into the other.