# Transparent CoAP Services to IoT Endpoints through ICN Operator Networks +
## 4 Design and Implementation
### Response Processing
In this case there are CoAP servers located inside buildings and each server is attached to a NAP. Buildings are numbered with a _building_ number, and then subdivided into _wings_ and _floors_, hence these are the possible group attributes and they are hierarchically organized as shown in the left part of Figure 7. A CoAP client may send a request to a group of CoAP servers; the group name is created by assigning \"values\" to (some of) the specified attributes, e.g., by setting \(building=building6\), and \(wing=west\), and \(floor=floor3\) the group name _building6.west.floor3_ is constructed. POINT NAPs are configured with values for the specified attributes, then by using these values they construct all possible group names, e.g., a NAP located in building6, west, \(3 rd\) floor, creates the names _building6_, _building6.west_, _building6.floor3_, and _building6.west.floor3_. Then, each NAP subscribes to the ICN content identifier that corresponds to each name. A CoAP request for a group (e.g., _coap://building6.floor2/temperature_). The CoAP request is encapsulated into a POINT content item and it is advertised in the ICN network using as an identifier the FQDN of the CoAP server as specified in the request's URL (i.e., in our example 'building6.floor2'); all NAPs that have subscribed to this identifier will receive that item, will decapsulate the CoAP request and will forward it to the corresponding CoAP servers. Following a similar approach CoAP responses are encapsulated into a POINT content item and are forwarded to the appropriate NAPs and eventually to the interested CoAP clients. ### Delayed Response Grouping

In many cases, CoAP clients ask for information that is not yet available, leading to a delayed response. Indeed, the CoAP protocol specifically caters to this pattern by supporting separate acknowledgments for the request and the response. When multiple requests are made by different clients, the server needs to store the pending requests, and when the information becomes available, it needs to send it as a unicast to all the clients. However, the CoAP Handler implementation supports request aggregation transparently to the CoAP server, thus delegating the state management of pending responses to the proxy. In addition, responses to multiple clients are sent in multicast mode over the ICN network, again transparently to the CoAP clients. ### CoAP Observe

The details of supporting CoAP observe extension in the NAP of the POINT architecture is presented in [11]. In brief, CoAP requests for the same resource are aggregated in the NAP, hence only a single CoAP client is visible to the CoAP server. In addition, when the value of a resource changes, the update notifications are transmitted using ICN multicast, thus safeguarding network resources. At both ends, these optimizations (e.g., less traffic in the ICN network, less traffic to/from the CoAP server) are transparent to the CoAP clients and server. To illustrate the concept, we present an example of _message sequence diagram_ in Figure 8 for two clients and a server and discuss the benefits of ICN underlay to CoAP. First, client1 issues an _observe_ request to a CoAP server. cNAP1 receives the request and checks its observe list. If no match is found, it creates an entry for this request in the observe list. cNAP forwards it to sNAP. sNAP receives the request and checks its observe list to find a match. If no match is found, it creates an entry in the observe list. Then, sNAP forwards it to the CoAP server. If the observe relationship is possible, the CoAP server replies with an ACK which eventually creates an observe relationship between CoAP client and CoAP server through NAPs. After some time, another CoAP client (client 2) issues observe request to the same CoAP server. cNAP receives it and finds a match for this request and inserts a new entry in the observe list. Eventually, cNAP does not forward the request to sNAP. cNAP creates an observe relationship with the client 2 on behalf of the CoAP server.