Dirk Kutscher

Abstract

Connecting low-power long-range wireless networks, such as LoRa, to the Internet imposes significant challenges because of the vastly longer round-trip-times (RTTs) in these constrained networks. In our newly published paper on "Delay-Tolerant ICN and Its Application to LoRa" at ACM ICN-2022, we present an Information-Centric Networking (ICN) protocol framework that enables robust and efficient delay-tolerant communication to edge networks, including but not limited to LoRa. Our approach provides ICN-idiomatic communication between networks with vastly different RTTs for different use cases. We applied this framework to LoRa, enabling end-to-end consumer-to-LoRa-producer interaction over an ICN-Internet and asynchronous ("push") data production in the LoRa edge. Instead of using LoRaWAN, we implemented an IEEE 802.15.4e DSME MAC layer on top of the LoRa PHY layer and ICN protocol mechanisms in the RIOT operating system. For our experiments, we connected constrained LoRa nodes and gateways on IoT hardware platforms to a regular, emulated ICN network and performed a series of measurements that demonstrate robustness and efficiency improvements compared to standard ICN.

Challenging Bi-Directional LoRa Communication

LoRaWAN provides a vertically integrated network architecture for connecting LoRa networks and its constrained devices to the Internet that is designed to offload power-constrained gateways relay communication between the wireless link and network servers (often co-located with additional application server infrastructure) that manage the intricate energy-conservation regime of connected LoRa devices.

The energy conservation objectives lead to a MAC layer design that incurs dramatically higher latency and round trip times (RTTs) of several seconds, compared to what connection-oriented Internet transport protocols are typically designed to support. As a result, LoRaWAN supports message-oriented transport through gateways and dedicated network servers only, without a notion of end-to-end communication from the Internet to LoRa nodes. While it is theoretically possible to run bidirectional IP-based communication on top of LoRaWAN, the resulting systems inherit latency challenges of LoRaWAN for bi-directional communication that would impact transport layer performance and applicability.

Delay-Tolerant Information-Centric Networking

Information-Centric Networking (ICN) has demonstrated benefits for improving data availability and communication performance in constrained IoT networks.

In a newly published paper on "Delay-Tolerant ICN and Its Application to LoRa" at ACM ICN-2022, Peter Kietzmann, José Alamos, Thomas Schmidt, Matthias Wählisch and myself argue that ICN is also a suitable network layer for connecting such challenged edge networks to a more regular Internet, by leveraging hop-by-hop transport functions, ICN caching and minimal application-agnostic extensions.

In earlier work, we have described a design of an improved, IEEE 802.15.4e DSME-based MAC layer for LoRa that supports packet-based communication, specifically ICN-style Interest/Data communication. Yet, RTTs can still be on the order of seconds due to the underlying power saving regime. Leveraging their work, we take an ICN-enabled LoRa subnet as a basis which is attached via an ICN forwarder on a gateway device. We developed a delay-tolerant ICN communication framework that allows connecting these LoRa sub-networks to a "regular" ICN Internet, with the following design goals:

1. supporting IoT sensor data transmission;
2. supporting arbitrary orders of delays, without specific assumptions of typical RTTs on other nodes on the ICN Internet;
3. not requiring application awareness on gateway nodes;
4. utilizing ICN-idiomatic communication to benefit from ICN principles such as accessing named data, Interest/Data semantics, caches, flow balance, etc.

We have developed interactions for IoT communication use cases that leverage bespoke (but application-agnostic) capabilities on gateway-based forwarders and the Reflexive Forwarding extensions for ICN that Dave Oran and I developed for Remote Method Invocation, RESTful communication, and IoT push data scenarios.

Our LoRa systems features two interaction patterns. First, IoT sensor data retrieval from an Internet-based consumer using Interest/Data interactions; and second, asynchronously "pushing'' data from an IoT sensor to an Internet-based consumer with pub/sub semantics.

Results

The contributions of out work are the following:

1. The design of delay-tolerant ICN-interactions and node behavior for this constrained environment.
2. A complete implementation of the DSME MAC layer for LoRa and our ICN protocol extensions on RIOT, serving common LoRa sensors and RIOT-based gateways.
3. An experiment-based evaluation of the interactions on constrained IoT hardware, connected to an emulated ICN-Internet, and a comparison with vanilla ICN approaches.

In conjunction with the OS-level implementation of ICN (and extensions), DSME, and LoRa, our two protocol mechanisms for Internet consumer-initiated and LoRa producer-initiated communication exhibit high reliability and targeted completion time (compared to Vanilla ICN) when applied to the delay-prone regime.

Despite an additional round trip, our evaluations in the paper exhibit low overhead of these approaches by overcoming redundant polling. We leveraged recently proposed gateway behavior (such as RICE) and ICN protocol extensions (reflexive forwarding), the latter of which serves many other use cases beyond phoning home and could be considered a useful standard ICN feature.

References

• ACM ICN-2022 Conference
• Pre-print of our paper
• Presentation video
• Previous work on the DSME and ICN network design
• Reflexing Forwarding Framework
• RIOT Operating System

I presented GreenICN work on Scalable Content Exchange in Challenged ICNs at CCNxCon-2015 this week.

Download: ccnxcon2015-kutscher.pdf

Abstract:
The principles of Information­Centric Networking (ICN), accessing data objects by name (not by location address), securing data objects (not connections), in­network caching (for sharing, repair, rate adaptation) make ICN attractive for a wide range of application scenarios beyond traditional data center or telco access network scenarios. In fact, one of the first instantiation of ICN had been developed based on Delay­Tolerant Networking (DTN) technologies.

Currently, ICN/DTN is considered a promising approach for enabling/enhancing communication in disaster scenarios. In such scenarios, so­called ICN data mules (that carry and disseminate data times) may move randomly, and each time data mules encounter one another exchange data items. We envision that in such a scenario where there is no connectivity, data mules (e.g. vehicles or drones) can move around randomly. So these mobile routers interact with end users, working base stations and other data mules to fetch and deliver the data and queries. Thus, we do not consider adhoc networks where you can build a path to the destination reactively or proactively, rather a DTN like scenario.

Consider a large scale disaster scenario like the earthquake in Japan in 2011 , where people in different parts of the city are stranded without the internet connectivity. But there are some zones, where base stations are still working and providing connectivity. Essentially, the scenario is such that ICN data mule move randomly across a geographic area, and when meeting end­users receive interests from them and also forward corresponding data items to end­users (if present in the content store / cache of the data mule). At the same time, when data mules encounter each other, they forward to each other certain end­user interest and/or data items (according to a predefined rule set and algorithm), such that interests and data items can be forwarded in a hop­by­hop DTN fashion. One research problem in such a scenario is how to optimize such data exchanges among data mules for optimal data dissemination (e.g. optimizing how many desired messages reach their recipients within a given timeframe with a given forwarding strategy, assuming that data mules only have limited time at each encounter to exchange
messages).