HoPP: Robust and Resilient Publish-Subscribe for an Information-Centric Internet of Things

01/11/2018 ∙ by Cenk Gündoğan, et al. ∙ Hamburg University of Applied Sciences 0

This paper revisits NDN deployment in the IoT with a special focus on the interaction of sensors and actuators. Such scenarios require high responsiveness and limited control state at the constrained nodes. We argue that the NDN request-response pattern which prevents data push is vital for IoT networks. We contribute HoP-and-Pull (HoPP), a robust publish-subscribe scheme for typical IoT scenarios that targets IoT networks consisting of hundreds of resource constrained devices at intermittent connectivity. Our approach limits the FIB tables to a minimum and naturally supports mobility, temporary network partitioning, data aggregation and near real-time reactivity. We experimentally evaluate the protocol in a real-world deployment using the IoT-Lab testbed with varying numbers of constrained devices, each wirelessly interconnected via IEEE 802.15.4 LowPANs. Implementations are built on CCN-lite with RIOT and support experiments using various single- and multi-hop scenarios.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 6

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 Internet of Things (IoT) is emerging, and billions of new networked devices are forecasted. However, no common networking technology for the IoT has been agreed upon. Despite of a maturing IETF protocol suite, dozens of incompatible industry solutions are rolled out to meet device and network constraints, as well as application specific needs.

Facing this huge world of mainly constrained devices, it seems worth rethinking its networking paradigm. A very loose coupling appears most appropriate between nodes that often run on battery with long sleep cycles and connect via lossy wireless links. Information-Centric Networking (ICN) [1, 2] decouples content provisioning from data producers in space which makes it a promising candidate. Additional decoupling in time and synchronization is desirable and attainable by a publish-subscribe layer.

Information-centric publish-subscribe networks have been proposed. PSIRP/PURSUIT [3] is an early, prominent candidate. However, its central control architecture seems more suitable for an SDN-type deployment in LANs. Publish-subscribe schemes based on NDN like Content-based pub/sub [4] and COPSS [5] violate the loose coupling principle in their use of name-based routing or forwarding. Facing the current state of the art, we explore the problem of information-centric publish-subscribe for IoT networking open.

In this paper, we take up the challenge and seek for an information-centric IoT networking solution that satisfies all challenges of real-world sensor-actuator networks and allows for an easy deployment. We base our work on NDN [6] not only because of its widespread availability and implementations on IoT operating systems, but in particular because of its clean request-response scheme that prevents unwanted traffic at the constrained end nodes. We design and evaluate HoP-and-Pull (HoPP), a lean, adaptive publish-subscribe layer that strictly adheres to the NDN communication pattern. Our experimental findings on large IoT testbeds indicate that our system complies indeed to the challenging requirements of IoT use case with promising performance. In particular, reliability and resilience of HoPP largely outperforms previously advised push notifications.

The structure of this paper continues as follows. In Section II, we outline distinctive use cases that motivate the following contributions. Section III explores the problem space and discusses related concepts and work. In Section IV, we dive into the design details of our publish-subscribe scheme, including the key aspects of network partitioning and publisher mobility. Implementation and evaluations of our system are described in Section V. Finally, we conclude with an outlook in Section VI.

Ii Deployment Considerations for IoT Use Cases

In this section, we focus on two use cases for the deployment of an information-centric IoT—the simple, well-known Lighting Control [7], and the more challenging application of an industrial Internet for Safety Control in harsh environments.

Ii-a Lighting control

Smart lighting control is essentially the task of setting the state of various lights according to preconfigured scenarios in response to triggering events. The latter may be generated by plain switches, complex controllers, or by other machinery like an elevator that is transporting people to a currently unilluminated floor. Configuring the proper light consists of turning various fixtures into selective settings.

We revisit this basic use case, because it raises two interesting aspects of networking. First, lighting control foremost follows an actuation pattern, i.e., different signals request for immediate state changes at specific groups of fixtures. The information of turning a switch must somehow propagate to distributed ensembles of lights under soft real-time constraints. Burke et al. [7] define authenticated Interests to push signalling to the actuator, thereby inverting the NDN request-response pattern. We argue for preserving the NDN communication paradigm in Section III.

Second the deployment of names is closely related to the application logic and often more involved than accessing data directly. Lighting control may switch individually located fixtures (e.g., corridor light 5), or fixture groups (e.g., room 5, front), activate functions (e.g., fading), or integrate aspects into schemes (e.g., background illumination). Smart systems most likely combine lighting control features with further sensor readings (e.g., user presence, brightness detection) to apply adaptive functions to varying device groups etc..

While authors in [7] chose to combine locations and applications within names that are preconfigured by a control manager, we argue that preconfigured application groups at the device level are too static and violate the device context: IoT devices have an identity, capabilities, and sometimes a known location. Their role in varying application contexts, though, is extrinsic and requires a coordinating function on the application level. This cannot be hard-coded in data names.

Ii-B Industrial safety networks

Industrial safety and control systems are increasingly interconnected and often operate under harsh conditions. In this use case, we consider industrial environments with a threat of hazardous contaminant (e.g., explosive gas) that need continuous monitoring by stationary, as well as mobile sensors. In case of an emergency, immediate actions are required such as issuing local alarms, activating protective shut-downs (e.g., closing valves, halting pumps), initiating a remote recording for first responders and forensic purposes.

Typical industrial plants are widespread with sparse network coverage, so that mobile workers or machines face intermittent connectivity at scattered gateways. Some sensors and actuators are infrastructure bound, others are independent, battery-powered embedded devices (e.g., body equipment). The latter aspects resemble the challenges faced in previous DTN-work such as in mines [8].

Like the previous, this use case relies on a fast sensor-actuator network including embedded IoT nodes. In addition, the harsh industrial environment raises the challenges of mobile, intermittently connected end nodes, and network partitioning. Still, enhanced reliability is required in the safety context. We will show in the following, how configurable data replication with dynamically generated content proxies can meet these challenges and how they combine in a lightweight system suitable for real-world deployment [9].

Iii The Problem of Information Centric IoT Networking and Related Work

Iii-a Deployment in the constrained IoT

Things in the IoT are often represented by small embedded controllers which possess orders of magnitude less resources (kBytes of memory, MHz CPU speed, mW of power) than regular Internet nodes, but still need to communicate using protocols that interoperate in a shared infrastructure.

These things are commonly sensors or actuators that speak with a remote ’cloud’ or talk with each other locally. The predominant communication for edge devices happens on wireless channels of low power lossy networks (LLNs) in the battery-powered world. Following the IEEE 802.15.4, BLE, or LWPAN standard, these nodes can exchange only small packets at very low rates and sleep frequently. Violating constraints quickly leads to successive overload, extreme packet losses, and may strongly degrade network operation or node availability. Repeated incidents have told that the mass of IoT nodes can be both highly threatened and a threat to the global Internet.

Iii-A1 ICN in the IoT

It became apparent [10, 11, 12] that ICN/NDN exhibit great potentials for the IoT. Not only allows the access of named content instead of distant nodes a much leaner and more robust implementation of a network layer, but in particular prevents the request-response pattern of NDN any overloading with data at the receiver. For a few years, it was the believe that NDN can be DoS resistant by design, until Interest- and state-based attacks were discovered [13]. Subsequent work [14, 15] elaborated the threats of Interest flooding and overloading FIB and PIT tables by user-generated names and content requests. This has proven difficult to mitigate [16] and is a particular threat to memory-constrained nodes. In the subsequent Section IV, we will show how a FIB with simple default routes can serve the IoT, and how PITs remain minimal by hop-wise content replication between nodes.

ICN deployment in the IoT has been studied with increasing intensity, touching protocol design aspects [11, 17, 18, 19, 20], architecture work [21, 22], and practical use cases [7, 23, 24, 9]. Emerging link-layer extensions for the wireless like TSCH turned out to be beneficial for the interaction of NDN communication patterns and channel management [25]. Several implementations have become available. CCN-Lite [26] runs on RIOT [27, 11] and on Contiki [28, 29], NDN has been ported to RIOT [30]. Thus, grounds seem to be prepared for opening the floor to real-world IoT applications with NDN.

Many deployments in the IoT, though, follow the communication patterns on demand, scheduled, and unscheduled. Actuators in particular rely on unscheduled control messages. Since NDN is built on the request-response scheme of data-follows-Interest, unscheduled push message are not natively supported. For the IoT, this has been identified as a major research challenge [31].

Iii-A2 Push communication

Several extensions have been proposed to enable an unsolicited push of data, among them Interest-follows-Interest [7], Interest notification [32], and a dedicated push packet [33]. All these push messages are sent immediately to a prospective consumer node, which not only conflicts with the ICN paradigm of naming content instead of hosts, but has no forwarding supported on the network layer. No push packet will reach its destination unless potential receivers are announced to the routing using a node-centric name. Unidirectional data push to named nodes, however, lacks flow as well as congestion control, and opens an attack surface to DoS. In the IoT with its constrained nodes, this must be rated a particularly severe disadvantage.

Carzaniga et al. [4] with a proposal of long-lived Interest seem to be the first in addressing the push challenge in a natural NDN fashion. Subscribers issue a persistent Interest that is not consumed at content arrival, and thereby establish a (static) data path from the producer. Unfortunately, long-lived Interests open an unrestricted data path to the recipient and thereby inherit the threats of overload as other push primitives. In addition, persistent forwarding states in PITs lead to self-reinforcing broadcast storms whenever L2 broadcasts are used [34]. Finally, frequent topology changes as characteristic for the IoT will routinely break paths. In the following, we will show how regular Interests with appropriate lifetime can serve this purpose equally well, without suffering from its drawbacks.

Iii-A3 The role of a control plane

Lessons from Internet decades have told that the networking layer should be composed of well defined and clearly separated control and data planes. NDN has primarily focused on a stateful forwarding plane. We argue that the ICN community has payed too little attention on clearly separating a control plane [35].

Current proposals of routing protocols that fill NDN FIBs mainly rely on brodcasts, and often misuse Interest messages of the forwarding plane to disseminate control information. The distance vector content routing protocol DCR

[36] and the link state content routing protocol LSCR [37] use broadcast pushs to distribute control traffic over multiple hops. This flooding is controlled by utilizing sequence numbers and anchor nodes that store copies of the content. An approach to reducing traffic overhead by scoped-flooding is outlined in Pro-Diluvian [38].

The set synchronization protocols ChronoSync [39], iSync [40] and PartialSync [41] rely on a broadcast-pull pattern, where an Interest message containing name information is distributed into a broadcast domain and served by the first node that maintains conflicting name information. NLSR [42] is a link state routing protocol that uses ChronoSync to distribute link information in the same manner.

Panini [43] explicitly defines a unicast name advertisement message (NAM) on the control plane which we will re-use when designing the publish-subscribe scheme in Section IV.

Iii-B Naming and routing

Naming content on an information-centric network layer promises a simplified access to information. Routing on names directly designs a lean network without further address mapping. It obsoletes infrastructure like the DNS and eliminates the attack surface inherent to the mapping. Both aspects are of great advantage in a constrained IoT network. However, name-based routing encounters the problems of (a) exploding routing tables, as the number of names largely exceeds common routing resources, and (b) limited aggregation potentials, as names are specific to appliances and applications, but independent of content locations. More severely and in contrast to IP, a local router cannot decide on aggregating names since the symbol space of names is not enumerable in practice [43]. Limiting the complexity of name-based routing and FIB table state is one of the major challenges in IoT networks [31].

Iii-B1 Naming in context

In a typical IoT scenario, there are sensor readings that are reported to a (remote) cloud, or to a controller that operates actuators. In some cases (s. Section II), sensors are co-located with a controller that generates control information for immediate actuation—a safety alert for example after a sensor threshold was exceeded.

Names need to be shared between the sending and the receiving side so that requests can be issued. Advertising all names throughout the routing system is infeasible and will quickly explode the FIBs. However, there are ways to mitigate this. An application-specific common knowledge, or standard naming schemes for sensor data [44] and alerts may obsolete the need to distribute every name to the FIBs. More generally, named topics serve as the common link in publish-subscribe systems.

In a sense, this natural approach relates to an old discussion about accessing named information in Hypermedia. Before the invention of the Worl Wide Web, Landow [45] already pointed out that information exchange always carries two contexts, the context of departure and that of arrival. Departure and arrival translate to publish and subscribe in our discussion.

Iii-B2 Name-based routing, forwarding, and caching

Routing normally proceeds according to location information from the FIB. Names in FIBs only aggregate well if naming follows the topological hierarchy of the network. This rarely holds, since naming is application-specific, and cannot be detected without distributed knowledge. To overcome FIB explosion, several authors refer to the NDN capabilities of stateful forwarding, using the option of distributing requests to several interfaces simultaneously [46, 47]. Such Interest multicasting will lead to duplicate content deliveries if the network is densely connected. In ’Pro Diluvian’ [38], the effects of such scoped flooding are analyzed, and authors find a utility limited over very few ( 2–3) hops. Such opportunistic forwarding can also lead to loops, as was pointed out by Garcia-Luna-Aceves [48]. In any case, the excessive traffic, as well as redundant PIT states make this approach infeasible for the IoT.

COPSS [5], an earlier publish-subscribe approach inspired by PIM [49] multicast routing, selects a rendezvous point to interconnect publishers and subscribers. Such dedicated routing point naturally allows for name aggregation. Like PIM-SM (Phase 2), COPSS further establishes a dedicated forwarding infrastructure (subscription table) that establishes persistent forwarding paths from the publisher via the rendezvous point to the receivers. PANINI [50, 43] re-uses the idea of an aggregation point called Name Collector, but does not establish a (persistent) forwarding plane like COPSS. Instead, PANINI uses selective broadcasts to discover unpopular routes towards the network edge. For the IoT, we want to minimize control traffic and avoid flooding. We restrict our solution to a lean default routing, instead.

The ICN support of data replication and caching is of particular interest for the IoT, where wireless channels are lossy and nodes are often asleep. Hop-wise data transport with intermediate storage of chunks is a built-in feature of NDN which we extend to account for node heterogeneity. IoT deployments often consist of very constrained nodes at the edge with more powerful border routers, gateways, or other node infrastructure—many of them equipped with larger hardware, electrical connectivity, and network uplinks. In the following, we will make use of Content Proxy nodes, which are meant to be chosen from this kind.

Iii-B3 Mobility and network partitioning

Mobile nodes are part of many IoT deployments. While mobility is natively supported at the receiver side of NDN, publisher mobility is considered difficult to solve in a generic way [51]. Translated to IoT use cases, this means mobile sensors are hard to integrate—a particular problem for surveillance and safety sensing applications. These use cases may also experience temporary network partitioning (see Section II), which can be treated with correspondence to network mobility.

Several solutions have been built for specific applications [52, 53], but the complexity of the name-based routing system often withstands a generic mobility management. We will show in the following how prevalent default routes can naturally accommodate publisher mobility, as well as network partitioning.

Iv HoP and Pull: A Publish-Subscribe Approach to Lightweight Routing on Names

Iv-a Overview

We are now ready to describe HoP-and-Pull (HoPP), our pub-sub system for lightweight IoT deployment in detail. For a confined IoT environment, we make the common assumption that nodes form a stub network that may be connected to the outside by one or several gateways. Some global prefix is given to a gateway, but (wireless) IoT nodes can reach a gateway without global prefix changes in one or several hops unless they are temporarily disconnected. Internally, nodes may be grouped according to one or several sub-network prefixes (e.g., /lighting).

We select one or several distinguished nodes to serve as Content Proxies (CPs). CPs are typically more stable and more powerful such as gateways or other infrastructural entities. These Content Proxies take the role of data caches and persistent access points. They will be reachable throughout the network by default routes, unless temporary partitioning occurs. Note that one CP can serve several local prefixes, but a local prefix may also belong to several CPs. The latter scenario will lead to replicated caching with higher and faster data availability.

Our publish-subscribe protocol for the IoT is then composed of three core primitives:

  1. Establishing and maintaining the routing system

  2. Publishing content to the CPs

  3. Subscribing content from the CPs

Our following protocol definition strictly complies with the design principles: (a) minimal FIBs that only contain default routes, (b) no push primitive or polling, (c) no broadcast or flooding on the data plane.

Iv-B Prefix-specific default routing

Content Proxies advertise the prefix(es) they own on the control plane to all neighbors in a Prefix Advertisement Message (PAM). Observing nodes will adopt a CP as their parent and re-broadcast the PAM message with an increased distance value. Much like in the core RPL [54], all nodes will be members of a Destination-Oriented Directed Acyclic Graph (DODAG) after routing convergence. Nodes will include the selected best uplink in their FIB as default route to the announced prefix, but may add additional uplinks with lower priority.

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

PAM

PAM

PAM

PAM

PAM

Prefix

Face

//

FIB
Fig. 1: Building a routing DODAG by prefix advertisements

Figure 1 visualizes the PAM prefix distribution and the corresponding FIB entry for the sample prefix //. All nodes establish a default on shortest paths upstream. In addition, node 4 learns a backup path of equal hop distance, but lower radio quality.

Iv-C Publishing content

An IoT node (sensor) that has new data to publish will first select a name. It may choose either from a predefined scheme accessible by local controllers, some common standard set, or decide individually. It will advertise this content name to its upstream neighbor via a (unicast) Name Advertisement Message (NAM). It will also associate the content with one or several topic names and adds these to the content metadata.

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

Publisher

Publisher

Publisher

3

1

0

NAM

NAM

Interest

Data

Interest

Data
Fig. 2: Publishing new content: Advertising names and pulling content hop-by-hop

Under regular network conditions, the upstream neighbor is expected to retrieve the advertised content via the incoming interface of the NAM. It proceeds according to the standard NDN scheme: An Interest requests the name, the data is returned in response. Concurrently, the upstream issues a corresponding NAM to its parent, which in turn pulls the content one hop closer to the CP. This hop-wise content replication proceeds until the data arrives at the Content Proxy.

It is worth noting that the NAM content alerting is situated on the control plane using link-local unicast signaling. Neither a data path is established in the PIT, nor are FIBs modified. Hop-wise content retrieval is also more robust to changing network conditions, while experiencing little temporal overhead when executed in parallel.

The publishing mechanism is depicted in Figure 2. Publisher 3 issues a NAM to its parent 1, which requests the content and republishes the NAM to the CP in parallel. After arrival of the data, node 1 can satisfy the Interest which was received by the CP.

Under irregular network conditions, a node may not receive an Interest that matches its previous name advertisements. This may be due to broken links, failing or deep-sleeping nodes, or enduring overload. After a deployment-specific timeout, the content owner will adapt and try to publish the content on an alternate path by sending a NAM up on a backup link. In case of a complete failure, the content node can follow two strategies: Either it waits and re-advertises according to an exponential back-off, or it solicits a refresh of router advertisements for learning new, operational routes.

Iv-D Subscribing to content

A subscriber in HoPP behaves almost like any content requester in NDN. It issues a regular Interest request up the default route to the CP and awaits the response. There are two deviations from plain NDN, though. First, the subscriber cannot extract content names from its FIB, since FIBs only contain prefixes. Second, it does not expect an immediate reply, but issues Interests with extended lifetimes.

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

Publisher

Subscriber

Publisher

Subscriber

Publisher

Subscriber

Interest

Publish

Publish

Data
Fig. 3: Content subscription: Requesting name by topic with asynchronous delivery

Names are expected to follow an application-specific logic. Following up the discussion in Sections III-B1, we argue that names (of content or topics) in machine-to-machine communication must be processable in the context of the endpoint and thus known. Names of individual content items can be learned by issuing Interests on topics. The corresponding CP will then answer the request with an empty data chunk that carries available content name(s) as metadata.

Figure 3 displays the operations of a subscriber. An Interest for named content is sent up to the proper prefix owner (CP) and remains for a predefined lifetime, if the Content Proxy cannot supply the data. In case content is arriving from a publisher to the CP, data is transferred automatically down the reverse Interest path—as a regular NDN operation. We anticipate that in common sensor-actuator networks of the IoT, the application semantic will define meaningful Interest lifetimes. Otherwise, in regimes of largely fluctuating temporal behaviours or long-lasting subscriptions (e.g., alerts), the subscriber may refresh and maintain the request at its discretion.

Note that in contrast to long-lived Interests or the COPSS subscription tables (s. Sec. III), such Interests of extended lifetime are consumed by arriving content and do not open a persistent, uncontrolled data path. Subscribers continue to apply flow control and may discontinue subscriptions to unwanted content.

Iv-E Publisher mobility and network partitioning

A publishing node that moves from one point of attachment to another within the IoT domain, will experience stable routing conditions in the sense that default routes to active prefixes should exist everywhere in a connected network. Correspondingly, the mobile node (MN) can re-configure its upstream route either by wait for the next prefix advertisement (PAM), or may actively solicit an additional PAM. Note that these link-local route configurations closely resemble the autoconfiguration of IPv6 default gateways. However, in contrast to mobile IPv6, the MN in our publish-subscribe system can continue publication immediately after a link-local route is established.

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

3

3

Publisher

Publisher

Publish

Publish

Publish

Publish
Fig. 4: Publisher Mobility: Switching DODAGs

Figure 4

illustrates provider mobility. Node 3 removes from the network while trying to publish a content item and enters the radio range of node 4. It may now actively learn about network re-attachment (e.g., from link triggers), or learn from a newly arriving PAM. After the local upstream is configured, the mobile publisher can successfully complete its publishing handshake.

0

CP

1

2

3

4

5

0

CP

1

2

3

4

5

1

ICP

2

ICP

Publisher

Publisher

Publisher

Publisher

Publisher

Publisher

Publish

Publish

Publish

Publish

Publish
Fig. 5: Temporary network partitioning: Interim Content Proxies (ICPs) buffer publishing

Temporary network partitioning proceeds very similar to mobility. An intermediate node that looses upstream connectivity will explore alternate paths (cf. Sec. IV-C), but has to await a re-attachment in case of a complete failure. Such node will continue to receive publishing demands (NAMs) from the downstream, which it will satisfy in accordance with its resources. On overload, it will terminate to retrieve content from its children. Proceeding this way will establish a classic backpressure mechanism of flow control.

Operations under network partitioning are shown in Figure 5. Following an outage of the CP, nodes 1 and 2 experience a disconnect. They continue to handle publications (as well as subscriptions) until connectivity to the CP is reestablished.

V Implementation and Evaluation

V-a Implementation for CCN-lite on RIOT

HoPP

FWD

CS

PIT

FIB

GNRC

REPL

NAD

TOPMGR

NC

netapi

Data

Control
Fig. 6: IoT Publish-Subscribe Architecture

We implemented the HoPP extensions on the CCN-lite version ported to RIOT and deploy NDN. It is noteworthy that this software stack supports both, the NDN core protocol as well as CCNx. On RIOT, CCN-lite implements the netdev interface and runs as a dedicated single-threaded network stack.

The architecture of the extended CCN-lite is depicted in Figure 6. It mainly adds a new control protocol block that handles exchange and processing of the two new packet types (PAM, NAM) on the control plane. This extends the forwarder module of CCN-lite. The forwarder allows extensions for the packet parsing by the use of user-defined callback functions on a suite basis. Considering this loose coupling, the actual topology maintenance was implemented separately from the CCN-lite core. The topology manager handles PAM scheduling and parent selection to form and maintain the routing topology (DODAG). Resulting forwarding states are reflected in the FIB with the help of the CCN-lite API. The Name Advertisement Daemon (NAD) module handles parsing and scheduling of NAM messages. A NAM Cache (NC) is used to intermittently track the hop-wise propagation and to reschedule NAM transmissions in case of network disruptions. For each entry in the NC, the NAD triggers the replicator to invoke a hop-wise content replication on the data plane via pull-driven Interest-Data. To ensure hop-wise replication of published content, a caching strategy was added to CCN-lite that hinders replicated content to be cached out during publishing. After a successful Interest-Data exchange, the replicator notifies the NAD module and the appropriate NC entry is freed for removal.

Fig. 7: Success rate of content delivery to one consumer as a function of hop count

V-B Basic Testbed Setup

All experiments are conducted in the FIT IoT-LAB testbed [55] to reflect common IoT properties. The testbed consists of several hundreds of class 2 devices equipped with an ARM Cortex-M3 MCU, 64 kB of RAM and 512 kB of ROM, and an IEEE 802.15.4 radio (Atmel AT86RF231). The radio card provides basic MAC layer functions implemented in hardware, such as ACK handling, retransmissions, and CSMA/CA (Carrier sense multiple access/Collision avoidance). The software platform is based on RIOT [27] and the CCN-lite network stack [26], including the protocol extensions described above.

The performance of the HoPP publish-subscribe IoT system is evaluated on the three different topologies:

is a densely connected topology of 69 nodes all within radio reach.

is formed of a closed rectangle with two double-stacked edges. 178 nodes form a heterogeneously meshed network with a maximal hop distance of four.

consists of about 350 nodes, where half of them is situated on the rectangle, the other half forms linear extensions leading outwards. This network organizes in complex, fluctuating topologies with a node distance up to 9 hops.

V-C Performance evaluation

The first evaluation inspects the reliability of HoPP as compared to plain Interest notification. We investigate the content reception rate on a given consumer in the Grenoble ring multi-hop topology using a converge cast traffic pattern, where each device generates sensor readings every  seconds. While HoPP is able to build and maintain the topology, static forwarding states were installed on the devices for the Interest Notification approach using the same routing information as HoPP.

Figure 7 compares the reliability of HoPP with the common Interest Notification approach in relation to the hop distance of the consumer. For HoPP, we observe a steady high content delivery rate above for all hop distances in the topology. NDN Interest Notification admits significantly lower reliability and shows a decline in transmission with increasing hop distance. While a hop count of yields packet arrivals, success ratio decreases to for hop distances of and larger. Next, we investigate performance metrics that relate to the temporal behaviour of the protocol. Since deficits of the core protocol, but also different failures of networked elements (radio/link layer, CCN-layer, pub-sub, and node layer) translate into delays due to retransmissions and re-arrangements, times to completion are a key performance indicators. In detail, we study (i) routing convergence, (ii) times to publish content items, (iii) times to publish under network partitioning, and (iv) times to issue alerts (from publisher to the subscribers).

Fig. 8: Routing convergence time for the testbed topologies
(a) Paris topology
(b) Grenoble (ring) topology
(c) Grenoble topology
Fig. 9: Time to content publishing

Routing convergence times in the three testbeds are displayed in Figure 8. Clearly visible is the dependence on hop counts, each counting for an average delay of ms—the PAM timer. While Paris is single-hop network and exhibits a single step in distribution, multiple steps represent hop count multiplicities in the multi-hop cases. No exceptional delays become visible. This is due to the moderate timing of the routing protocol which causes a low network utilization.

For the evaluation of the times needed to publish a content item, we iterate the following scenario. For each topology, a Content Proxy is positioned in the center of the network, while randomly chosen nodes publish a single, individually named chunk to the network. Publication is initiated every second and depending on the nodes position in the tree, one to several data packets might traverse the same sub-paths within this time frame.

Results for the single-hop network (Paris) are displayed in Figure 9(a). Observing round-trip ping values of  ms, the NAM timer () of  ms, and the CCN-lite processing, a mean time to publish of about ms would be expected. Small fluctuations at indicate additional delays that result from network disturbances and node congestion leading to paths of hop count two.

Similar results become visible from the Grenoble experiments in Figs. 9(b) and 9(c). Clearly pronounced are the first four routing hops, higher hop counts in Fig. 9(c) blur according to increasing fluctuations. These results clearly show the fragility of the lossy wireless regime, but also confirm a majority of these challenging transmissions did complete on the expected time scale.

We analyzed a scenario of network partitioning on the Grenoble ring topology. To quantify the effects of a major network disruption, we disabled all nodes of rank two every 60 s for an off-time interval of 60 s. This isolated the Content Proxy periodically. Content publishing proceeded randomly with a frequency of one per second.

Fig. 10: Time to content publishing at network partitioning

Results in Figure 10 highlight a smooth content transition to the CP with a timing almost linearly stretched over the 60 s off-period. No unexpected content delays become visible, which indicates the protocol robustness on this macroscopic time scale.

Finally, the end-to-end delay from the publisher to the subscriber was examined. This corresponds to the use case of issuing alerts between nodes from the local IoT network. The scenarios correspond to the previous measurements of the publishing time, i.e., publishing and subscription requests are issued randomly scattered within the topology at intervals of one second.

(a) Paris topology
(b) Grenoble (ring) topology
(c) Grenoble topology
Fig. 11: Time to issue alerts

The experimental output for the three topologies are displayed in Figs. 11(a), 11(b), and 11(c) respectively. As we might expect, blurring fluctuations have enhanced with only a few pronounced signatures of hops and the means increased slightly by the extended paths towards the subscribers. Notably, the single-hop testbed from Paris performed best under the extended communication load, whereas the full Grenoble testbed clearly runs at its limit. The latter can be easily explained by the many hop transitions required at Grenoble, each of which requires an additional packet exchange which potentially impacts on neighbors within radio range.

Low power lossy networks that connect heavily constrained IoT nodes are known to be infeasible for such heavy load. We consider it therefore a success that a notable fraction of the content arrived at its receivers on within about 500 ms – a timescale which is considered normal in multi-hop WPANs. To a certain degree, we account this for the robustness of our hopwise content publishing and replication protocol.

Vi Conclusions and Outlook

Future IoT networking is one of the most challenging use cases of the Internet today and a potential deployment regime of ICN. In this work, we revisited Information-Centric Networking in the IoT from a variety of perspectives and concluded that (a) publish-subscribe with named topics largely facilitates to manage the complexity of naming data, and (b) NDN without a push option for data has striking advantages for security and resilience in constrained environments. We propose HoPP, a lightweight publish-subscribe system that was implemented on RIOT and CCN-lite and experimentally evaluated on large, realistic testbeds. Our findings confirmed that constrained lossy networks can admit largely unforeseeable behaviour. Nevertheless, our approach turned out robust and resilient while performing well in the majority of experiments.

In future work, we will enhance our implementation and work towards prototypic deployment in more intricate use cases. Prior to that, we will study mobility and disruption tolerance in closer detail using multi-proxy set-ups and content redundancy. Adding an analytic model that complements our understanding of the different protocol control loops will be valuable for optimizing parameters and the overall performance.

References

  • [1] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman, “A Survey of Information-Centric Networking,” IEEE Communications Magazine, vol. 50, no. 7, pp. 26–36, July 2012.
  • [2] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, C. Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. C. Polyzos, “A Survey of Information-Centric Networking Research,” IEEE Communications Surveys and Tutorials, vol. 16, no. 2, pp. 1024–1049, 2014.
  • [3] D. Lagutin, K. Visala, and S. Tarkoma, “Publish/Subscribe for Internet: PSIRP Perspective,” Future internet assembly, vol. 84, 2010.
  • [4] A. Carzaniga, M. Papalini, and A. L. Wolf, “Content-based Publish/Subscribe Networking and Information-centric Networking,” in Proc. of the ACM SIGCOMM WS on Information-centric Networking (ICN ’11).   New York, NY, USA: ACM, 2011, pp. 56–61.
  • [5] J. Chen, M. Arumaithurai, L. Jiao, X. Fu, and K. Ramakrishnan, “COPSS: An Efficient Content Oriented Publish/Subscribe System,” in ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS’11).   Los Alamitos, CA, USA: IEEE Computer Society, Oct. 2011, pp. 99–110.
  • [6] V. Jacobson, D. K. Smetters, J. D. Thornton, and M. F. Plass, “Networking Named Content,” in 5th Int. Conf. on emerging Networking Experiments and Technologies (ACM CoNEXT’09).   New York, NY, USA: ACM, Dec. 2009, pp. 1–12.
  • [7] J. Burke, P. Gasti, N. Nathan, and G. Tsudik, “Securing Instrumented Environments over Content-Centric Networking: the Case of Lighting Control and NDN,” in Computer Communications Workshops (INFOCOM WKSHPS), 2013 IEEE Conference on.   IEEE, 2013, pp. 394–398.
  • [8] P. Ginzboorg, T. Kärkkäinen, A. Ruotsalainen, M. Andersson, and J. Ott, “DTN Communication in a Mine,” in 2nd Extreme Workshop on Communications.   ACM, Sept. 2010.
  • [9] C. Gündogan, P. Kietzmann, T. C. Schmidt, M. Lenders, H. Petersen, M. Wählisch, M. Frey, and F. Shzu-Juraschek, “Information-Centric Networking for the Industrial IoT,” in Proc. of 4th ACM Conference on Information-Centric Networking (ICN), Demo Session.   New York, NY, USA: ACM, September 2017, pp. 214–215.
  • [10] S. Y. Oh, D. Lau, and M. Gerla, “Content Centric Networking in tactical and emergency MANETs,” in 2010 IFIP Wireless Days.   IEEE, Oct 2010, pp. 1–5.
  • [11] E. Baccelli, C. Mehlis, O. Hahm, T. C. Schmidt, and M. Wählisch, “Information Centric Networking in the IoT: Experiments with NDN in the Wild,” in Proc. of 1st ACM Conf. on Information-Centric Networking (ICN-2014).   New York: ACM, September 2014, pp. 77–86. [Online]. Available: http://dx.doi.org/10.1145/2660129.2660144
  • [12] K. Pentikousis, B. Ohlman, D. Corujo, G. Boggia, G. Tyson, E. Davies, A. Molinaro, and S. Eum, “Information-Centric Networking: Baseline Scenarios,” IETF, RFC 7476, March 2015.
  • [13] M. Wählisch, T. C. Schmidt, and M. Vahlenkamp, “Bulk of Interest: Performance Measurement of Content-Centric Routing,” in Proc. of ACM SIGCOMM, Poster Session.   New York: ACM, August 2012, pp. 99–100. [Online]. Available: http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p99.pdf
  • [14] P. Gasti, G. Tsudik, E. Uzun, and L. Zhang, “DoS and DDoS in Named Data Networking,” in Proc. of ICCCN.   IEEE, 2013, pp. 1–7.
  • [15] M. Wählisch, T. C. Schmidt, and M. Vahlenkamp, “Backscatter from the Data Plane – Threats to Stability and Security in Information-Centric Network Infrastructure,” Computer Networks, vol. 57, no. 16, pp. 3192–3206, Nov. 2013. [Online]. Available: http://dx.doi.org/10.1016/j.comnet.2013.07.009
  • [16] S. Al-Sheikh, M. Wählisch, and T. C. Schmidt, “Revisiting Countermeasures Against NDN Interest Flooding,” in 2nd ACM Conference on Information-Centric Networking, Poster Session, ser. ICN 2015.   New York: ACM, Oct. 2015, pp. 195–196.
  • [17] G. C. Polyzos and N. Fotiou, “Building a reliable Internet of Things using Information-Centric Networking,” Journal of Reliable Intelligent Environments, vol. 1, no. 1, pp. 47–58, 2015.
  • [18] J. Suarez, J. Quevedo, I. Vidal, D. Corujo, J. Garcia-Reinoso, and R. L. Aguiar, “A secure IoT management architecture based on Information-Centric Networking,” Journal of Network and Computer Applications, vol. 63, pp. 190 – 204, 2016.
  • [19] M. Amadeo, O. Briante, C. Campolo, A. Molinaro, and G. Ruggeri, “Information-centric networking for M2M communications: Design and deployment,” Computer Communications, vol. 89–90, pp. 105 – 116, 2016.
  • [20] B. Mathieu, C. Westphal, and P. Truong, “Towards the usage of ccn for iot networks,” in Internet of Things (IoT) in 5G Mobile Technologies.   Springer, 2016, pp. 3–24.
  • [21] J. J. Garcia-Luna-Aceves, “ADN: An Information-Centric Networking Architecture for the Internet of Things,” in Proc. of the 2nd International Conference on Internet-of-Things Design and Implementation, ser. IoTDI ’17.   ACM, 2017, pp. 27–36.
  • [22] E. M. Schooler, D. Zage, J. Sedayao, H. Moustafa, A. Brown, and M. Ambrosin, “An Architectural Vision for a Data-Centric IoT: Rethinking Things, Trust and Clouds,” in IEEE 37th Intern. Conference on Distributed Computing Systems (ICDCS).   IEEE, June 2017, pp. 1717–1728.
  • [23] M. Amadeo, C. Campolo, A. Iera, and A. Molinaro, “Information Centric Networking in IoT scenarios: The case of a smart home,” in 2015 IEEE International Conference on Communications (ICC), June 2015, pp. 648–653.
  • [24] D. Saxena, V. Raychoudhury, and N. SriMahathi, “SmartHealth-NDNoT: Named Data Network of Things for Healthcare Services,” in MobileHealth@MobiHoc.   IEEE, 2015, pp. 45–50.
  • [25] O. Hahm, C. Adjih, E. Baccelli, T. C. Schmidt, and M. Wählisch, “ICN over TSCH: Potentials for Link-Layer Adaptation in the IoT,” in Proc. of 3rd ACM Conf. on Information-Centric Networking (ICN 2016), Poster Session.   ACM, September 2016, pp. 195—196, best Poster Award. [Online]. Available: http://dx.doi.org/10.1145/2984356.2985226
  • [26] “CCN Lite: Lightweight implementation of the Content Centric Networking protocol,” 2014. [Online]. Available: http://ccn-lite.net
  • [27] E. Baccelli, O. Hahm, M. Günes, M. Wählisch, and T. C. Schmidt, “RIOT OS: Towards an OS for the Internet of Things,” in Proc. of the 32nd IEEE INFOCOM. Poster.   Piscataway, NJ, USA: IEEE Press, 2013.
  • [28] A. Dunkels, B. Gronvall, and T. Voigt, “Contiki—a lightweight and flexible operating system for tiny networked sensors,” in Local Computer Networks, 2004. 29th Annual IEEE International Conference on.   IEEE, 2004, pp. 455–462.
  • [29] B. Ahlgren, A. Lindgren, and Y. Wu, “Demo: Experimental Feasibility Study of CCN-lite on Contiki Motes for IoT Data Streams,” in Proceedings of the 2016 conference on 3rd ACM Conference on Information-Centric Networking.   ACM, 2016, pp. 221–222.
  • [30] W. Shang, A. Afanasyev, and L. Zhang, “The Design and Implementation of the NDN Protocol Stack for RIOT-OS,” in Proc. of IEEE GLOBECOM 2016.   Washington, DC, USA: IEEE, 2016, pp. 1–6.
  • [31] D. Kutscher, S. Eum, K. Pentikousis, I. Psaras, D. Corujo, D. Saucez, T. Schmidt, and M. Waehlisch, “Information-Centric Networking (ICN) Research Challenges,” IETF, RFC 7927, July 2016.
  • [32] M. Amadeo, C. Campolo, A. Iera, and A. Molinaro, “Named data networking for IoT: An architectural perspective,” in 2014 European Conference on Networks and Communications (EuCNC).   IEEE, June 2014, pp. 1–5.
  • [33] R. Ravindran, A. Chakraborti, S. Amin, and J. Chen, “Support for Notifications in CCN,” IETF, Internet-Draft – work in progress 01, July 2017.
  • [34] P. Kietzmann, C. Gündogan, T. C. Schmidt, O. Hahm, and M. Wählisch, “The Need for a Name to MAC Address Mapping in NDN: Towards Quantifying the Resource Gain,” in Proc. of 4th ACM Conference on Information-Centric Networking (ICN).   New York, NY, USA: ACM, September 2017, pp. 36–42.
  • [35] M. Wählisch, T. C. Schmidt, and M. Vahlenkamp, “Lessons from the Past: Why Data-driven States Harm Future Information-Centric Networking,” in Proc. of IFIP Networking.   Piscataway, NJ, USA: IEEE Press, 2013.
  • [36] J. Garcia-Luna-Aceves, “Name-based Content Routing in Information Centric Networks Using Distance Information,” in 1st ACM Conference on Information-Centric Networking, ser. ACM-ICN ’14.   ACM, 2014, pp. 7–16.
  • [37] E. Hemmati and J. Garcia-Luna-Aceves, “A New Approach to Name-Based Link-State Routing for Information-Centric Networks,” in 2Nd ACM Conference on Information-Centric Networking, ser. ACM-ICN ’15.   ACM, 2015, pp. 29–38.
  • [38] L. Wang, S. Bayhan, J. Ott, J. Kangasharju, A. Sathiaseelan, and J. Crowcroft, “Pro-Diluvian: Understanding Scoped-Flooding for Content Discovery in Information-Centric Networking,” in 2Nd ACM Conference on Information-Centric Networking, ser. ACM-ICN ’15.   New York, NY, USA: ACM, 2015, pp. 9–18.
  • [39] Z. Zhu and A. Afanasyev, “Let’s ChronoSync: Decentralized Dataset State Synchronization in Named Data Networking,” in Proc. of the 21st IEEE International Conference on Network Protocols (ICNP 2013), 2013.
  • [40] W. Fu, H. Ben Abraham, and P. Crowley, “Synchronizing Namespaces with Invertible Bloom Filters,” in 11th ACM/IEEE Symposium on Architectures for Networking and Communications Systems, ser. ANCS ’15.   IEEE Computer Society, 2015, pp. 123–134.
  • [41] M. Zhang, V. Lehman, and L. Wang, “PartialSync: Efficient Synchronization of a Partial Namespace in NDN,” no. NDN-0039-1, Jun. 2016. [Online]. Available: https://named-data.net/wp-content/uploads/2016/06/ndn-0039-1-partial-sync.pdf
  • [42] M. Hoque, S. O. Amin, A. Alyyan, B. Zhang, L. Zhang, and L. Wang, “NLSR: Named-data Link State Routing Protocol,” in 3rd ACM SIGCOMM Workshop on Information-centric Networking, ser. ICN ’13.   New York, NY, USA: ACM, 2013, pp. 15–20.
  • [43] T. C. Schmidt, S. Wölke, N. Berg, and M. Wählisch, “Let’s Collect Names: How PANINI Limits FIB Tables in Name Based Routing,” in Proc. of 15th IFIP Networking Conference.   Piscataway, NJ, USA: IEEE Press, May 2016, pp. 458–466.
  • [44] C. Jennings, Z. Shelby, J. Arkko, A. Keranen, and C. Bormann, “Media Types for Sensor Measurement Lists (SenML),” IETF, Internet-Draft – work in progress 10, July 2017.
  • [45] G. P. Landow, “The rhetoric of hypermedia: Some rules for authors,” Journ. of Comp. in Higher Education, vol. 1, no. 1, pp. 39–64, 1989.
  • [46] C. Yi, A. Afanasyev, I. Moiseenko, L. Wang, B. Zhang, and L. Zhang, “A Case for Stateful Forwarding Plane,” PARC, Tech. Rep. NDN-0002, July 2012.
  • [47] C. Yi, J. Abraham, A. Afanasyev, L. Wang, B. Zhang, and L. Zhang, “On the Role of Routing in Named Data Networking,” in Proceedings of the 1st ACM Conference on Information-Centric Networking, ser. ACM-ICN ’14.   New York, NY, USA: ACM, 2014, pp. 27–36.
  • [48] J. J. Garcia-Luna-Aceves and M. Mirzazad-Barijough, “A light-weight forwarding plane for content-centric networks,” in 2016 International Conference on Computing, Networking and Communications (ICNC).   IEEE, Feb 2016, pp. 1–7.
  • [49] B. Fenner, M. Handley, H. Holbrook, and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” IETF, RFC 4601, August 2006.
  • [50] T. C. Schmidt, S. Wölke, N. Berg, and M. Wählisch, “Partial Adaptive Name Information in ICN: PANINI Routing Limits FIB Table Sizes,” in 2nd ACM Conference on Information-Centric Networking, Poster Session, ser. ICN 2015.   New York: ACM, Oct. 2015, pp. 193–194.
  • [51] G. Tyson, N. Sastry, R. Cuevas, I. Rimac, and A. Mauthe, “A Survey of Mobility in Information-centric Networks,” Commun. ACM, vol. 56, no. 12, pp. 90–98, Dec. 2013.
  • [52] L. Wang, A. Afanasyev, R. Kuntz, R. Vuyyuru, R. Wakikawa, and L. Zhang, “Rapid Traffic Information Dissemination Using Named Data,” in Proc. of 1st ACM Workshop on Emerging Name-Oriented Mobile Networking Design - Architecture, Algorithms, and Applications (NoM).   New York, NY, USA: ACM, 2012, pp. 7–12.
  • [53] G. Grassi, D. Pesavento, L. Wang, G. Pau, R. Vuyyuru, R. Wakikawa, and L. Zhang, “ACM HotMobile 2013 Poster: Vehicular Inter-networking via Named Data,” SIGMOBILE Mob. Comput. Commun. Rev., vol. 17, no. 3, pp. 23–24, November 2013.
  • [54] T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, J. Vasseur, and R. Alexander, “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks,” IETF, RFC 6550, March 2012.
  • [55] “IoT-LAB: a very large scale open testbed,” https//www.iot-lab.info/, 2015.