# Transparent CoAP Services to IoT Endpoints through ICN Operator Networks +
## 1 Introduction
Therefore, the design principle of this architecture allows for providing transparent CoAP services to IoT devices through an ICN core network, while shifting both complexity and communication overhead from the CoAP endpoints to the ICN core network. Furthermore, in this work, we have not assumed that the two technologies are similar. Nevertheless, both ICN and CoAP has some shared principles in their design (e.g., Pub/Sub based CoAP observe [6]). Section 5.3 highlights the outcome of our design in terms of computation complexity and communication overhead through inherent ICN multicast. In addition, the key benefit is that the CoAP server does not need to implement IP multicast and any modification to the Domain Name System (DNS) is not required. In summary, the design and implementation of the for the POINT architecture (Figure 1) which enable the legacy CoAP and CoAP extension to IoT devices through the ICN operator network. Through our approach, the IP endpoints implementing only the core CoAP can benefit from the CoAP and its extensions by leveraging the multicast capabilities of the POINT architecture. CoAP protocol has various extensions, such as CoAP observe [6] and group communication [7], that provides the potential for developing novel IoT applications. Despite its potential, a full-fledged CoAP deployment on the resource-constrained devices poses great challenges [8]. For example, in order to support delay-tolerant messaging or publish-subscribe communication (i.e., CoAP observe), CoAP serversshould maintain extensive state for CoAP clients and require significantly higher processing capabilities. In addition, CoAP group communication could be implemented by using IP multicast [9], with DNS mapping of group names (included in the CoAP UR requests) onto the appropriate IP multicast address. To support group communication, CoAP servers should implement IP multicast and, for each group, a specific IP multicast address should be assigned. Therefore, the resource-constrained IoT devices need to allocate more resources for a DNS client implementation. In order to tackle these challenges, the inherent features of ICN have a great potential of deploying IP based CoAP in resource-constrained IoT devices. Therefore, the main goal of this paper is to improve the IP-based CoAP service offering of the ICN operator network without any adaptations to the CoAP endpoint. In addition, the CoAP endpoint must be oblivious to ICN. In this paper, we present the design and implementation of the CoAP handler for the POINT architecture which enable the legacy CoAP and CoAP extension to IoT devices through the ICN operator network so that the IP endpoints implementing only the core CoAP can benefit from the CoAP and its extensions by leveraging the multicast capabilities of the POINT architecture. The summary of the key contributions is as follows:  
* Enabling CoAP group communication without IP multicast support and any modification to the DNS. * Enabling CoAP observe extension support transparently, i.e., CoAP requests for the same IoT resource are aggregated in the NAP, hence only a single CoAP client is visible to the CoAP server. * Enabling delayed response in the case that the resource is not available or the CoAP server is in the sleep mode. Our earlier efforts [10; 11] present the potential of the ICN architecture to improve the performance of IoT endpoints which run CoAP and illustrates how various CoAP-specific communication scenarios could benefit from an ICN network. Based on the analysis of [10], we present the preliminary design, implementation, and qualitative evaluation (e.g., communication overhead, state management of IoT devices) of the CoAP Observe extension over ICN in [11]. The CoAP observe extension has been  
Figure 1: POINT architecture. implemented in a proxy which is connected to the NAP of the POINT architecture. Moreover, CoAP group communication is demonstrated in [12].