# Transparent CoAP Services to IoT Endpoints through ICN Operator Networks +
## 4 Design and Implementation
### Response Processing
```
request_pkt \(\leftarrow\)[ICN_message] \(ICN\_ID\leftarrow\)[ICN_message] SToken \(\leftarrow\)ICN_ID_To_SToken[ICN_ID] ifSToken = = NULL then SToken \(\leftarrow\)generateNewToken() \(ICN\_ID\_To_SToken[ICN_ID]\)\(\leftarrow\)SToken request_pkt \(\leftarrow\)SToken else request_pkt \(\leftarrow\)SToken endif SToken_To_ICN_ID_list[SToken] \(\leftarrow\)ICN_ID resource_URI \(\leftarrow\)[request_pkt] coap_server_list \(\leftarrow\) lookup(resource_URI) / \(*\) group communication if list \(>\) 1*/ forcoap_server_list do  coap_server \(\leftarrow\)\(\mathit{enque}(\mathit{coap\_server\_list})\) / \(*\) suppress similar request from \(\mathit{different\ cNAP*/}\) if pending_res_list(res_ICN_ID,coap_server).size ==1 then  send request_pkt to coap_server endif endfor
```
**Algorithm 2** CoAP Request in sNAP  
Algorithms 3 and 4 present the process of handling the CoAP response in a sNAP and cNAP. Upon reception of a CoAP response, sNAP looks up its state table to find a list of cNAP(s) interested in this response. If multiple cNAPs are found, sNAP utilizes the ICN multicast to forward a single copy of this response to those cNAPs. Afterwards, sNAP removes the entry from the state table except the case of the response packet containing the CoAP observe option. Finally, cNAP forwards the response to the appropriate client(s). ```
**Algorithm 3** CoAP Response in sNAP
```
\(token\leftarrow[coap\_response]\) \(ICN\_ID\leftarrow token\_To\_ICN\_ID[token]\) \(response\_type\leftarrow[coap\_response]\) ifresponse_type = = \(Confirmable\)then  send empty ACK to server \(c\_{op\_response}\leftarrow setResponseType(Non-confirmable)\) endif \(cNAP\_list\leftarrow pending\_response(ICN\_ID,server)\) // coincidental multicast if\(cNAP\_list\) size \(>1\) send coap_response to \(cNAP\_list\)
```
**Algorithm 4** CoAP Response in cNAP
```
\(ICN\_ID\leftarrow[ICN\_message]\) \(coap\_response\leftarrow[ICN\_message]\) \(token\_list\gets lookup(ICN\_ID)\) isObserveOption \(\leftarrow[coap\_response]\) ifisObserveOption = \(true\)then \(observer\_list\gets lookup\_observer(token\_list)\) send response to observer_list else \(client\_list\gets ICN\_ID\_to\_ clients\_token\_list\) send response to client_list endif
```

**Algorithm 5** CoAP Response in cNAP

### Implementation

We have implemented CoAP Handler in C/C++. The libcoap library is widely used in IoT. The implementation of the CoAP Handler follows the semantics of RFC 7252 and RFC 7641. Initially, the most challenging task was the CoAP observe extension which has been implemented in the NAP of the POINT architecture. The group communication is implemented exploiting the inherent multicast support of the ICN architecture. Originally, the group communication of the CoAP Handler is based on the software solution, named Blackadder, which has been implemented in the European Union (EU) FP7 project PURSUIT and EU H2020 POINT Project [4]. The POINT architecture allows standard IP traffic to be run over an ICN core network, deployed typically at a single network provider [4]. POINT's core ICN network is implemented using the Publish-Subscribe Internet (PSI) ICN architecture, a publish-subscribe architecture, where users interested in receiving specific content subscribe to it, while content owners advertise their content and if requested they publish it (i.e., they transfer it to the subscribers by default through multicast). ## 5 Experiment

### Experiment Setup

We have constructed an IoT testbed (Figure 4) which is connected to the existing POINT testbed through a Network Attachment POINT (NAP). The IoT testbed consists of several sites. The generic composition of each site consists of the CoAP Handler of the NAP, an Edge Controller, and the embedded Leaf Nodes. As an example, these form a house automation system controlling lights, heating and cooling systems.The Edge Controller runs a control algorithm and provides user interface.