An Overview on Push-Based Communication Models for Information-Centric Networking

Abstract

Information-centric networking integrates by design a pull-based model which brings in advantages in terms of control as well as of in-network caching strategies. Currently, ICN main areas of action concern content distribution and IoT, both of which are environments that often require support for periodic and even-triggered data transmission. Such environments can benefit from push-based communication to achieve faster data forwarding. This paper provides an overview on the current push-based mechanisms that can be applied to information-centric paradigms, explaining the trade-off associated with the different approaches. Moreover, the paper provides design guidelines for integrating push communications in information-centric networking, having as example the application of this networking architecture in IoT environments.

1. Introduction

Information-centric networking (ICN) is being applied with success to content distribution in large-scale environments due to its capability to address data instead of hosts, and to natively support authenticated many-to-many communication. ICN aims at overcoming the limitations of IP-based solutions, which try to build an information-centric service model over a network infrastructure designed to support host-to-host communications. Another area where ICN shows promising results is Internet-of-Things (IoT) [1]. In IoT environments the broader concept of publish/subscribe is being increasingly integrated into several IP-based messaging protocols, as publish/subscribe supports a faster deployment of many-to-many communications. Messaging protocols such as Advanced Message Queuing Protocol (AMQP) (ISO 19464) [2] or Message Queue Telemetry Transport (MQTT) protocol [3] follow a client-server approach, where an entity (broker) mediates between the different IoT devices/services, i.e., between (producers) and consumers. The abstraction supported by the use of a mediating entity (broker) is useful. However, the broker approach does not scale well in scenarios with high topological variability and high heterogeneity of devices, as occurs, for instance, in personal IoT scenarios, or in industrial IoT scenarios [4].

An advantage of the ICN publish/subscribe models is: decentralization. From a network architectural perspective, such models are promising candidates for data transmission in highly heterogeneous IoT scenarios [5]. The ICN publish/subscribe semantics support integrated security and data distribution/decentralization via in-network caching. Although the transient nature of IoT data may bring challenges related to in-network caching, new research findings corroborate that caching techniques specifically designed for small transient data can actually reduce the time-to-completion of requests [6]. Furthermore, the ICN interface abstraction model, Face, is extremely relevant in supporting the sharing of data between devices, as well as between applications and services. Such abstraction allows, for instance, to have automatic multihoming support.

Despite the aforementioned advantages, by design, the ICN publish/subscribe paradigm follows a pull-based communication approach, where consumers need to express interest to receive each data packet. Such a pull-based model may reduce performance in scenarios holding a large number of resource constrained, mobile devices, as occurs in IoT environments, due to the need to frequently broadcast Interest packets. This would require devices to be in reception mode all of the time, for instance, thus resulting in battery drain. Or, it would require a method for fine-grained synchronization, based on the rate at which individual IoT devices emit data.

Hence, the applicability of ICN in IoT environments is a relevant area of work, which requires further research into how to support both pull and push communication. In this context, the motivation for this work is two-fold: firstly, to debate on properties of different push-based communication models; secondly, to provide guidelines towards the integration of ICN pull and push communication models, particularly in the context of IoT environments, as one meaningful area of today’s internet, and of next generation internet architectures. While our work is focused on the applicability area of IoT, the proposed guidelines are applicable to other areas that have similar assumptions and requirements in particular in what concerns data transmission over highly heterogeneous and mobile scenarios. This work contributions are three-fold. Firstly, this paper debates on the need to support push-based communications, when devising ICN architectures for IoT. Secondly, the paper describes mechanisms available to achieve such purpose, and what are their advantages and disadvantages. Thirdly, the paper provides design suggestions to integrate push-based communication in ICN architectures specifically developed for IoT. For the remainder of this paper, we shall refer to the Named Data Networking (NDN) architecture as an ICN instantiation, as it is today the only ICN approach that supports all of the IoT basic requirements [7]. It should be highlighted, nevertheless, that NDN has been built upon the CCNx original network semantics and thus, the considerations presented in this paper apply to approaches that share the same network architectural semantics.

The remainder paper is organized as follows. Section 2 goes over the notion of pull and push communication models. Section 3 explains mechanisms that have been developed to support push-based communications in ICN, and in NDN in particular. Section 4 debates on guidelines for the integration of NDN push-based communication support in IoT. Section 5 describes related work, while conclusions are provided in Section 6.

2. Pull vs. Push Communication Models

In a pull-based communication model, the user issues a request for any specific information object. In contrast, in a push-based model interested parties get the information if they have previously subscribed it, and information gets distributed when it is available. Therefore, producers push information periodically or based on events to consumers.

Push-based models, which have been around for quite a while, became popular in the late 90’s with the advent of PointCast [8]. This software platform allowed users to define an interest profile and delivered data to the user based on such interest. Data delivery followed the regular IP-based communication, i.e., content was provided via a point-to-point transfer. The relevancy of push-based technology at the time was the possibility to deliver personalized data. To the end-user, data seemed to be “immediately” available, as the user did not have to explicitly request such data by clicking on a button, for instance. However, due to the fact that the underlying network layers would still operate on a unicast basis, push-based technology had a fast decline.

With the advent of wireless and cellular networks and the need to support content-based distribution in real-time or close-to-real-time to a large and varying number of users, push-based communication has been re-ignited.

In current IoT communication solutions such as RESTful HTTP or CoAP (Constrained Application Protocol) [9], communication follows a request-response strategy, where IoT devices acting as data producers transfer information to a server (e.g., gateway) or to end-user devices acting as data consumer after consumers issue a pull request.

In publish/subscribe broker-based models (rf. to Figure 1) such as the ones supported by AMQP, MQTT, or even OLE for Process Control (OPC) Foundation Open Platform Communications-Unified Architecture (OPC-UA) [10,11], producers send information to brokers (mediating entities) which then relay the information to consumers that a priori subscribed to the respective types of information. In such cases, data transmission is initiated by producers and consumers cannot “regulate” the data transfer in any way. Hence, the push-based communication can be performed between producers and broker, as well as from broker to consumers. This push-based model is, however, still based on unicast and hence, current IP-based publish/subscribe solutions mimic a 1-to-N transmission, unless an IP multicast infrastructure is set between broker and consumers. Furthermore, publish/subscribe broker models fall short as brokers cannot control data transmission by producers and consequently, they may easily be overloaded in large-scale scenarios.

Even though ICN publish/subscribe approaches (rf. to Figure 2 consider by default pull-based communication, push-based support has been envisioned in the original design of ICN, as shall be further discussed in Section 3.

3. Push-Based Approaches in ICN

ICN pull-based communication models such as the ones supported by CCNx [12] and NDN attain a two-way delay which is disruptive for situations where devices emit data periodically (e.g., monitoring reports), or for situations where devices generate data in response to a trigger (e.g., alert on machine malfunctioning). Such cases benefit from the one-delay that push-based models attain.

To assist this reasoning, Figure 3 illustrates a generic IoT scenario where sensors (P1, P2, P3) are collecting data in the context of a Smart Home environment. Sensors P1, P2, P3 are located in different rooms of a house.

The sensed data is sent to an application in Anna’s device (C3) via an IoT gateway (C2), which Anna can use to remotely control her Smart Home environment. The data is sent as well over the cloud to registered applications which Anna’s family use for the same purpose. In this scenario, hierarchical naming can be defined to best assist data distribution. For instance, a temperature sensor data can be identified by a name prefix such as “/homenumber123/room/temperature”, and the IoT gateway or any other router in between can assist in data aggregation based on specific data categorization rules.

The different “things” (e.g., sensors) are therefore publishers, while the gateway and the different control/management applications are subscribers.

In these environments producers are usually resource-constrained devices which are often in Idle mode. Furthermore, in IoT scenarios information needs to be frequently updated (e.g., temperature may be updated every minute; in a factory environment, polling may occur within milliseconds). A publish/subscribe pull-based approach helps in getting data in a distributed and asynchronous manner, which is relevant in large-scale environments where topology is variable. However, it may overload the network with Interest packets when IoT applications generate data in shorter time periods. Network performance may also suffer from the high volume of meta-data (e.g., Interest-Data handshake) that needs to be generated to get small transient IoT data.

Such limitations lead us to investigate different ICN/NDN push-based communication models to IoT.

3.1. Push Communication via Call-Back Approach

In a call-back push-based approach, producers start the ICN transmission. This requires a special implementation, e.g., an additional protocol so that producers can emit special Interest packets that have as purpose to trigger regular Interest packets by interested consumers. Such particular Interest packet would carry a call-back Name Prefix [13]. The call-back approach may be interesting for one-time events where there is the need to quickly refresh the status of consumers. However, it adds extra overhead (three-step handshake), and results in additional in-network state to allow routers to distinguish call-back Interest packets from regular Interest packets.

3.2. Push Communication via Interest Notifications

The use of special Interest packets to implement push-based communication is the solution considered in the original design of CCN. In this case, producers start the transmission via special Interest packets, in a similar way to the call-back approach. These Interest Notification packets carry small data in association to the announced Name Prefix [13,14,15]. For instance, for the case exemplified in Figure 3.

P1 triggers an Interest Notification packet holding a Name Prefix /homenumber123/room/ temperature/valueroom = A/valuetemp = 22. Therefore, in addition to polling consumers, these packets already carry updates for consumers.

Although being simple to implement, Interest notifications do not support reliability. To ensure reliability, consumers explicitly confirm the reception of an Interest notification, e.g., with a dummy acknowledgement packet such as the (aData packet) [15]. As data is not cached in reply to these Interest notifications, routing loops may occur, since Interest Notification packets are forwarded based on information stored in the database that stores routes, i.e., the Forwarding Information Base (FIB) and not in the cache where pending interests expressed by consumers are stored, the Pending Interests Table (PIT). A way to circumvent this problem is to rely on timestamps sent with Name Prefixes [13,14].

3.3. Push Communication via Special Data Packets

Push-communication can also be implemented based on special Data packets. Such approach follows the natural communication model of ICN. An example for such an approach considers pData packets [16]. pData packets are sent by producers and forwarded by routers without checking the PIT, given that there is no prior Interest packet. pData packets are forwarded based on the implemented forwarding strategy, via the FIB stored information. Therefore, if no entry for a specific pData Name prefix is available, then pData packets are broadcasted.

The trade-off associated with a push model based on Data packets is a higher network overload, which can be controlled via, for instance, TTLs.

In large-scale, highly dense and with high mobility scenarios, such a push-based approach can be coupled with name-based routing protocols such as DABBER [17], thus avoiding broadcast strategies. Following this approach, pData packets (e.g., /homenumber123/room/temperature/pData/ valueroom = A/valuetemp = 22) are forwarded only towards consumers that have subscribed pData name prefixes (e.g., /homenumber123/room/temperature/pData).

Models under this category can be used in time-critical scenarios. An example is the need to send alerts in Industrial IoT, concerning, for instance, malfunctioning. Another example is the need to push data to surrounding devices around [16,18].

3.4. Push Communication via Long-lived Interests

Long-lived Interests are a method that has been proposed to assist in reducing the cost of supporting push-based communications in local environments [15,19]. PIT entries for Long-lived Interests are associated with a specific time interval. The goal is to allow producers to send multiple data packets to consumers during such time interval, without the need to generate additional Interest packets.

Long-lived Interests are implementable via special Interest packets that carry a Time Threshold Value (TLV) [16]. Hence, IoT consumers may use Long-lived Interests to express their willingness in receiving specific data for a certain amount of time (e.g., 3 days).

Long-lived Interests are therefore relevant in terms of reducing the PIT caching size, the network traffic, and the usage of resources by resource-constrained devices: sensors can produce and push data as soon as it is produced, without having to stored it while waiting for incoming Interest packets. This means that data producers can spend more time in Idle mode, thus sparing battery.

Although Long-lived Interests lock PIT entries for longer periods of time, this does not raise an issue, given that applications should generate Long-lived Interests only to support periodic data transmissions, and not sporadic ones. Nevertheless, ICN/NDN routers may implement a policy allowing the release of PIT entries of long-lives Interests for which no data has been forwarded during a configured period of time.

The interruption of data reception implicitly informs consumer applications about the end of the respective time period. The application resumes the regular ICN process, under the assumption that data is being generated with a frequency lower than initially expected.

4. ICN Migration Towards IoT Scenarios

IoT embraces a large set of different environments where both pull and push-based communication support is required. Devices are resource constrained, and the whole communication system needs to be engineered in a way that is battery and bandwidth efficient.

The ICN/NDN publish/subscribe pull-based model is relevant in IoT environments, as it provides secure, asynchronous support for many-to-many communication. However, its original design requires devices to only send data if an Interest packet is received, which does not scale well with an increasing number of IoT devices. Nevertheless, communication based on the plain pull-based model of NDN is applicable, for instance, in the context of the communication between a gateway or controller (e.g., IoT gateway) and the cloud. In this case cloud applications would use a pull-based approach to gather large amounts of (small) data stored in IoT gateways, and related to a large set of IoT devices.

While a pull-based model is suitable for the communication between cloud applications and IoT gateways, such model may end-up in reducing network performance if applied to the communication between IoT devices and gateways, since IoT gateways are aggregation points. Interest packets are expected to be sent with high frequency. The polling interval in some cases (e.g., industrial IoT) may be in the order of milliseconds, preventing an ICN-based architecture to adequately scale, as devices would quickly be drained out of energy while dealing with a large amount of Interest packets.

Hence, a push-based communication model needs to be supported as well, at least between IoT devices and gateways. This allows for energy saving, reduction of used network resources, and a better data management. Such a scenario corresponds to a first step in further potentiating the application of ICN in large-scale IoT environments. This would be an architecture that would suit industrial IoT scenarios as well, given that the notion of controller (gateway or broker) will always be required to assist translation into different domains, as well as to assist in reaching the required availability needs.

In scenarios holding a higher degree of mobility and/or decentralization, as occurs in vehicular networks, in personal IoT environments, the need to support push-based communication is present as well. For instance, IoT devices may be mobile and alerts may need to be sent. In such cases, push-based communications are required from an end-to-end perspective, for event-triggered communications as well as for periodic communications. Guidelines for such support are debated in the next sections.

4.1. Periodic Data Communication Support

A wide range of control and monitoring IoT applications require consumers to periodically collect information from a large set of IoT devices. An example are heat monitoring systems which require frequent updates on the temperature in different buildings and rooms. Since the standard pull operation mode of ICN/NDN is not suitable, as discussed, IoT gateways can be leveraged to implement Long-lived Interests.

To keep backward compatibility, IoT producers should keep on sending data as stipulated by their applications. As illustrated in Figure 4, it is expected that data consumers, such as IoT gateways (C), are able to adjust the frequency of Interest packets in order to gather all data produced by IoT devices (A, B), while saving network resources. This is achievable, for instance, by considering a Long-lived Interest approach. As mentioned before, IoT consumers may adjust the time period of Long-lived Interests based the analysis of the rate at which data is received.

Long-lived Interests need to be backed up by adequate forwarding strategies and/or routing protocols. Most adaptive forwarding strategies [20] are not suitable for Long-lived Interests, since metrics such as the Interest satisfaction ratio cannot be used to assess the quality of selected paths. Furthermore, intermittent connectivity is expected to occur in IoT scenarios, given that such scenarios are connected via wireless and/or cellular infrastructures. Under such conditions, a routing protocol such as DABBER can assist transmission even in the verge of intermittent connectivity. DABBER was developed to extend the reach of ICN to opportunistic wireless networks, while: i) avoid flooding the network with Interest packets, which is a major requirement of opportunistic networks; ii) selective forwarding of Interest packets based on data reachability information, and context awareness (neighborhood and node itself). This unique combination makes it highly appealing for ICN environments [21].

4.2. Event-Triggered Data Communication Support

While Long-lived Interest can be applied to support both local and wide area operation, unsolicited data communication from authorized sources to report specific events (e.g., machine malfunctioning) may only be feasible in local areas, due to the multipath, broadcast nature that is the basis of the ICN/NDN design.

Unsolicited data communications can be supported by leveraging ICN/NDN via a push-based Data packet model, such as pData, provided that data producers and consumers perform a negotiation first.

An example for this situation can be a demand/response energy control use-case where smart meters would issue pData packets to notify authorized entities about unusual peaks in energy consumption.

5. Related Work

While several ICN approaches have been developed, including CCN, NDN, NetInf [22], PURSUIT [23] there are still a number of challenges associated with ICN applicability to large-scale, resource-constrained and mobile heterogeneous scenarios, such as IoT scenarios.

To overcome such challenges, related work has proposed, for instance, overlaying ICN over the M2M ETSI standard, or identifying high-level ICN requirements for IoT [24]. Research has been focused also in developing lightweight implementations for IoT, such as CCN-Lite, which has been ported to the RIOT operating system, or NDN-RIOT, that provides additional data security support [25]. Still, most of these contributions assume the usage of the ICN standard pull-based communication model, which may bring operational and performance issues in IoT scenarios.In (IoT) environments where there is high resource variability, a pull-based model may not be sufficient to satisfy network and/or application requirements. One potential problem is producer mobility support, for instance. Another potential problem is the overhead derived from the selected per packet pull-based model [14].

Franklin et al. describe the initial steps for push-based communications, which lead to the subscription-driven models that are today the basis for multiple applications [8]. Their explanation assists in understanding the semantics behind push-based and pull-based communication solutions.

M. Amadeo et al. propose guidelines and a preliminary analytical evaluation based on local-area domain for reliable NDN push-based strategies to ensure reliable data pushing between consumers and producers: Interest notification; unsolicited Data; virtual Interest polling [26]. Their initial analytical evaluation shows that push-based communication for ICN can be relevant in the context of specific IoT environments.

Muralidharan et al. [27] show how an hybrid pull-push traffic model can be used for efficient data exchange in IoT applications. Research findings indicate that a hybrid approach may bring performance benefits by reducing the network load and packet dropping, while increasing packet delivery ratio.

Majeed et al. describe an NDN proactive data dissemination scheme for pushing critical content in vehicular networks [28]. Their scheme is focused on local communication (one-hop push approach), having producers first sending a beacon message with metadata to assist local routers and direct consumers in adjusting to data to be sent, without the need to emit Interest packets. Their proposal may, nonetheless, lead to undesired loops, as information is temporarily stored in PITs. Related work focused on the adaptation of ICN paradigms to vehicular networks has also been dealing with the mitigation of data broadcast storms due to frequent interest forwarding [29,30,31].

This paper contributes with an overview and guidelines to strengthen the deployment of ICN-based approaches in IoT, advocating for that purpose the inclusion of push-based models, and explaining when and how such push-based models should be deployed.

6. Conclusions

The increasing deployment of low-cost sensing devices and the proliferation on wireless technologies offer significant opportunities for the development of a next generation of Internet services. ICN publish/subscribe content-oriented architecture brings benefits for next generation Internet environments, in particular for large-scale mobile heterogeneous environments. IoT environments fall into such categories, bringing in extra challenges, such as more heterogeneity due to resource-constrained devices; massive volumes of small data; wider heterogeneity in traffic types.

This paper contributes with guidelines to raise awareness to the need to further study and develop ICN pull/push-based communication approaches, in particular in the context of IoT scenarios. While pull-based models are relevant in the context of communication between cloud applications and services and IoT gateways/brokers, the communication between IoT devices and gateways requires push-based communication support, given that pull-based models reduce the network performance due to the frequent broadcast of Interest packets. For this purpose, this paper proposes to consider the combination of Long-lived Interests and special Data packets (such as pData). Long-lived interests can support periodic data communication while at the same time assisting IoT devices in reducing resource consumption; special data packets support event-triggered communications between authorized devices. The combination of these two solutions is also relevant to achieve mitigation of data broadcast storms due to frequent interest forwarding.