ICN enabling CoAP Extensions for IP based IoT devices

The Constrained Application Protocol (CoAP) and its extensions, such as observe and group communication, offer the potential for developing novel IoT applications. However, a full-fledged CoAP-based application requires delay-tolerant communication and support for multicast: since these properties cannot be easily provided by existing IP networks, developers cannot take full advantage of CoAP, preferring to use HTTP instead. In this demo we show how proxying CoAP traffic over an ICN network can unleash the full potential of CoAP, simultaneously shifting overhead and complexity from the (constrained) endpoints to the network.

READ FULL TEXT VIEW PDF

Authors

page 1

page 2

11/04/2020

VSDM: A Virtual Service Device Management Scheme for UPnP-Based IoT Networks

The ubiquitous nature of IoT devices has brought new and exciting applic...
11/22/2017

A novel JXTA-based architecture for implementing heterogenous Networks of Things

This paper presents EmbJXTAChord, a novel peer-to-peer (P2P) architectur...
06/23/2021

A Pure HTTP/3 Alternative to MQTT-over-QUIC in Resource-Constrained IoT

In this letter, we address the issue of scalable and timely disseminatio...
02/29/2020

An Experimental Study of Network Coded REST HTTP in Dynamic IoT Systems

REST HTTP is the communication protocol of choice for software developer...
03/08/2019

Enhancing REST HTTP with Random Linear Network Coding in Dynamic Edge Computing Environments

The rising number of IoT devices is accelerating the research on new sol...
11/01/2019

NFV-based IoT Security for Home Networks using MUD

A new scalable ISP level system architecture to secure and protect all I...
02/15/2022

IEC61850 Sample-Value Service Based on Reduced Application Service Data Unit for Energy IOT

With the development of 5G technology and low-power wireless communicati...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The Constrained Application Protocol (CoAP) [1] has been called the “HTTP for the Internet of Things” (IoT), as it allows CoAP clients to retrieve or set resources from CoAP servers implemented in constrained devices (the Things). In contrast to HTTP however, it is implemented over UDP and it allows for delayed responses, e.g., a CoAP client may request the value of a resource that is not yet ready; it will initially receive an acknowledgment for its request and when the resource becomes available it will receive the appropriate response. Various CoAP extensions enable novel applications, departing even further from the traditional one request-one response model. For instance, the CoAP observe [2] extension allows CoAP clients to observe resources and receive a notification everytime their state changes (i.e., very similar to the publish-subscribe communication paradigm). CoAP group communication is another CoAP extension defined in RFC 7390 [3]. This extension allows clients to retrieve or set resources from a group of servers e.g., retrieve the temperature from all sensors of a building, turn on all the lights of a factory, etc. Group names follow the structure of legacy CoAP URIs, nevertheless they can be overloaded with application specific semantics (e.g., a CoAP GET request for the group coap://floor3.building6/temperature may result in all temperature sensors in floor 3 of building 6 to send a record).

Despite its potential, CoAP is mostly used in its basic form (one request-one immediate response). The main reason for this is that a full fledged CoAP deployment is cumbersome, mostly due to the IP underlay. For example, in order to support delay-tolerant messaging or publish-subscribe communication (i.e., CoAP observe) CoAP servers should maintain extensive state. Similarly, RFC 7390 suggests that CoAP group communication could be implemented by using IP multicast, with DNS mapping group names (included in the CoAP URI requests) into the appropriate IP multicast address: with this approach CoAP servers should implement IP multicast and, for each group, a specific IP multicast address should be assigned (and configured in CoAP endpoints).

In this demo, we show how the POINT Information-Centric Networking (ICN) architecture can be leveraged, so that IP endpoints that implement only core CoAP, can benefit from CoAP and its extensions.

Fig. 1: High level overview of a POINT-enabled building management system.

I-a The POINT architecture

The POINT architecture allows standard IP traffic to be run over an ICN core network; the ICN core is typically deployed at a single network provider [4]. POINT’s core ICN network is implemented using the Publish-Subscribe Internet (PSI) ICN architecture [5], a publish-subscribe architecture, where users interested in receiving specific content subscribe to it, while content owners advertise their content and, if requested, publish it (i.e., they transfer it to the subscribers, by default through multicast). The POINT architecture provides a number of handlers for existing IP-based protocols (e.g., HTTP, CoAP, and basic IP) that map the underlying protocols onto appropriate named objects within the ICN core. Therefore, existing applications can benefit from ICN’s features by forwarding their (legacy) traffic through Network Attachment Points (NAPs), where these protocols handlers are implemented.

Figure 1 gives a high level overview of a POINT network with CoAP handlers enabled in its NAPs. NAPs connected to CoAP servers learn the URIs of the available resources and send subscription messages to the ICN core indicating their interest in receiving CoAP requests (encapsulated into POINT objects). Similarly, whenever a NAP connected to CoAP clients (possibly, via the Internet) receives a CoAP request, it encapsulates it into a POINT content item and advertises it in the ICN network. This advertisement will result in the content item being forwarded to an appropriate NAP; this NAP then will decapsulate the CoAP request and will forward it to the appropriate CoAP server. CoAP enabled NAPs can aggregate requests for the same CoAP resource, shifting this way state management from CoAP servers to NAPs.

Ii Enabling CoAP extensions over POINT

Ii-a Approach

The POINT approach for supporting the CoAP observe extension is detailed in [6]. In a nutshell, the POINT NAPs aggregate requests for the same resource, hence from the CoAP server’s perspective only a single CoAP client is visible. Moreover, update notifications are transmitted using multicast, thus conserving network resources. POINT leverages its information-centrism and its inherent support for multicast to support seamless and hassle-free group communication among CoAP endpoints. In particular, it takes advantage of PSI’s name structure in order to organise group “attributes”; then it assigns values to these attributes to construct group names, and maps these names into the appropriate PSI scopes.

In order to illustrate this concept we consider the case of a building management system (depicted in Figure 1). 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 in wings and floors; these are the possible group attributes, which are hierarchically organised as shown in the left part of Figure 1. 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 , , and the group name floor3.west.building6 is constructed. POINT NAPs are configured with values for the specified attributes, so that by using these values they can construct all possible group names e.g., a NAP located in building6, west, floor, creates the names building6, building6.west, floor3.building6, and floor3.west.building6. Then, each NAP subscribes to the ICN content identifier that corresponds to each name.

Using this scheme, a CoAP request for a group (for example, coap://floor2.building6/temperature), is encapsulated into a POINT content item and 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 ‘floor2.building6’); 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 interested CoAP clients.

Ii-B Key contributions

The benefits of POINT to CoAP in general, are highlighted in [7]. Similarly, the benefits of POINT to CoAP observe are highlighted in [6]. When it comes to CoAP group communication, our approach enables issuing requests to groups of CoAP servers that implement the standard version of the CoAP protocol (i.e., they do not support RFC 7390). As a result, CoAP servers do not have to implement IP multicast. Moreover, there is no need for modifications to DNS. CoAP servers are oblivious to group names, since names are handled by the NAPs, thus Things management becomes much easier. The ICN core makes group name administration easier: new attributes can be easily added to the namespace without affecting already deployed NAPs. Moreover, group names do not have to be mapped a priori to a lower layer network address.

Acknowledgments

This research was supported by the EU funded H2020 ICT project POINT, under contract 643990.

References

  • [1] Z. Shelby, K. Hartke, and C. Bormann, “The constrained application protocol (CoAP),” IETF, RFC 7252, 2014.
  • [2] K. Hartke, “Observing resources in the constrained application protocol (CoAP),” IETF, RFC 7641, 2015.
  • [3] A. Rahman and E. Dijk, “Group communication for the constrained application protocol (CoAP),” IETF, RFC 7390, 2014.
  • [4] D. Trossen, M. J. Reed, J. Riihijarvi, M. Georgiades, N. Fotiou, and G. Xylomenos, “IP over ICN - The better IP?” in European Conference on Networks and Communications (EuCNC),, June 2015, pp. 413–417.
  • [5] G. Xylomenos, X. Vasilakos, C. Tsilopoulos, V. Siris, and G. Polyzos, “Caching and mobility support in a publish-subscribe internet architecture,” IEEE Communications Magazine, vol. 50, no. 7, pp. 52–58, July 2012.
  • [6] H. Islam, D. Lagutin, and N. Fotiou, “Observing IoT Resources over ICN,” in 2017 1st IFIP Netowrking Workshop on Information-Centric Fog Computing (ICFC), 2017.
  • [7] N. Fotiou, H. Islam, D. Lagutin, T. Hakala, and G. Polyzos, “CoAP over ICN,” in 2016 8th IFIP International Conference on New Technologies, Mobility and Security (NTMS), Nov 2016, pp. 1–4.