Keywords

1 Introduction

Internet of Things (IoT) is a significant breakthrough in the area of Information and Communication Technology (ICT). It is the concept of connecting any devices or objects embedded with sensors (“things”) to the global Internet platform, which combines data from these and use it to address specific needs. IoT has the following components—Sensors, Networks, Data Processing, and User Interface (Refer Fig. 1). Network is an essential component in IoT that connects the “things”/sensors. IoT networks are often referred as Low Power Lossy Networks (LLNs) which consist of nodes that are constrained in terms of memory, power, and processing capability. Such a resource constrained nature coupled with the ever growing demands of the IoT paradigm makes routing in LLNs an extremely challenging task. Similar to the case of other advanced networks, the Internet Engineering Task Force (IETF) has developed base protocols for LLN routing.

Fig. 1
figure 1

Internet of Things (IoT)

Full size image

IPv6 Routing Protocol for Low power Lossy Networks (RPL) is the first protocol developed for LLNs by the Routing over Low Power and Lossy Networks (RoLL) [1] working group, and is defined to be the standard protocol for LLNs by the IETF. RPL works by constructing a Destination Oriented Directed Acyclic Graph (DODAG) directed toward the sink/root. Often considered as the de facto IoT routing protocol, RPL has been subject to a lot of advancements ever since its inception. Further details regarding RPL has been provided in Sect. 2. Majority of the research in RPL comes under the consideration of issues like mobility and scalability. Even though these are issues of importance, LLNs being a part of IoT pose even more challenges. One among such challenges is the handling of multiple RPL instances running concurrently.

A characteristic that distinguishes IoT networks (such as LLNs) from other wireless networks is the fact that IoT is heavily application oriented. Consequently networks taking part in the IoT environment have to serve a wide range of applications. LLNs, which are connected to the Internet through IoT gateways, will have to serve applications corresponding to each of these gateways. Even worse is the fact that these applications may coexist in the same network. As a result multiple DODAGs, each serving unique applications, need to be handled by an efficient routing protocol. Still, the amount of work carried out to tackle this challenge is surprisingly less. In this paper, we propose an RPL variant which addresses this issue.

We have designed an Objective Function (OF) which takes into account different traffic types so as to indicate the different requirements of various applications (or multiple instances). The rest of this paper is organized as follows: Sect. 2 provides a walkthrough on related works in the area, Sect. 3 explains the new routing metric proposed, Sect. 4 provides the results and discussion, and finally Sect. 5 concludes the paper.

2 Related Work

As mentioned in Sect. 1, routing in LLN has attracted research interest which has led to the development of a variety of routing protocols. These routing protocols cover different categories like proactive, on-demand, opportunistic, and cognitive routing. The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) and Lightweight On-demand Ad hoc Distance vector routing—next generation (LOADng) [2] form the two basic protocols in LLN routing. The former belongs to the class of proactive routing whereas the latter belongs to on-demand routing. In order to keep up with the scope of this paper, we provide a brief review of RPL-variants in this paper.

Ever since its inception in 2012 by RoLL working group of the Internet Engineering Task Force (IETF), it has maintained its tag as the core IoT routing protocol. RPL is a Distance Vector routing protocol that operates by constructing a DODAG. The DODAG is maintained by using control messages like DODAG Information Object (DIO), DODAG Information Solicitation (DIS), and Destination Advertisement Object (DAO). Out of these control messages, DIO plays the most important role in constructing a DODAG. DIO messages consist of Objective Function (OF) information which is used for calculating the rank of a node. There are two standard Objective functions used in RPL—OF0 and Minimum Rank Hysteresis Objective Function (MRHOF). OF0 uses the hop count metric, whereas MRHOF is based on the metric container concept specified in RFC6551 [3]. See [4] for a detailed study of various Objective Functions. The node with minimum rank value is always chosen as the preferred parent. In this manner, each and every node present in the DODAG is always a part of some route toward the destination (i.e., root). DIS and DAO messages handle the function of providing connection/re-connection to new/disconnected nodes, and setting downward routes respectively. In order to meet the increasing demands of IoT paradigm, several enhancements have been made in the years following its inception.

RPL was basically designed for static networks, but things have changed over time with the introduction of paradigms like Industrial IoT (IIoT) where mobility is of utmost importance. Further, the number of applications currently being supported by the IoT is huge compared to the scenario during its inception. Hence, there is a need for further advancements in RPL to meet the new requirements. Even though a lot of works and studies are progressing to meet the challenges of a changing network, most of them are concentrated on the mobility aspect of IoT. On one hand, the protocols like [5,6,7] focus on incorporating mobility in RPL. [8, 9], on the other hand, focus on resource efficiency and mode switching (storing and non-storing modes) respectively. Comparatively, only minimal researches has been done on LLN routing with multiple RPL Instances.

In [10], the authors have proposed the usage of two different Objective Functions (OFs) to handle multiple instances. The metrics in consideration were Hop count (HC) and Expected Transmission Count (ETX). But, these two metrics alone do not guarantee to meet the requirements of diverse IoT applications. Nguyen et al. in [11] put forwards another RPL variant which handles only two RPL instances. Nassar et al. [12] developed a unique Objective Function (OF) which considered multiple traffic scenarios. In this work, we have chosen [12] as the base paper and made further enhancements in the Objective Function. The proposed Objective Function is explained in Sect. 3.

3 MEHOF

As mentioned in Sects. 1 and 2, the new objective function Multiple instances ETX-Hop count Objective Function (MEHOF) aims at providing efficient routing in a Low power lossy Network with multiple instances running concurrently. This has been performed by adjusting the values of α and β according to the criticality of the application (see Table 1 for symbols used). Based on the criticality of applications we can tune α and β to meet the network requirements efficiently as in the paper [12] by Nassar et al. (as shown in Table 2):

Table 1 Table of symbols in MEHOF
Full size table
Table 2 Instance classification and values of α, β
Full size table

  • α = 0.9 and β = 0.1 for critical traffic with a reliability of > 99.5% and a delay ranging between 1 and 30 s.

  • α = 0.1 and β = 0.9 for non-critical traffic with a reliability of > 98% and a delay of a few days.

  • α = 0.3 and β = 0.7 for periodic traffic with a reliability of > 98% packets and an authorized delay ranging between 5 min and 4 h.

MEHOF comprises of Expected Transmission Count (ETX), Hop Count (HC), Energy Consumed (EC), and the number of instances in which a node is part of (m). In a low power lossy network with multiple RPL Instances, each RPL Instances denote different applications requiring different reliability, latency, and criticality. These differences have been handled using the tunable parameters α and β where α = 1 − β, 0 < α < 1 and 0 < β < 1. MEHOF has been formulated as follows:

$$ {\text{MEHOF}} = (ax\,{\text{ETX}} + bx\;{\text{HC}}) + {\text{EC}} + m $$
(1)

As compared to ETX, Hop Count gives faster convergence as we can observe from N. Pradeska et al. [13] assessed performance of standard Objective function OF0 and MRHOF, and observed that OF0 based on Hop Count is suitable for networks with faster convergence (Convergence Time of RPL: Amount of time needed by all reachable nodes in the network to join a DAG) and lower power consumption. They also observed that OF0 based on Hop Count acts better in mobile environment than MRHOF based on ETX. These observations served as the motivation for us to design MEHOF. Algorithm 1 and Algorithm 2 provide the detailed procedure for calculating MEHOF. Algorithm 1 calculates the rank value of a node based on the MEHOF value returned by Algorithm 2. After the calculation, node with minimum rank value is chosen as the preferred parent. MAX_PATH_COST, RPL_DAG_MC_ETX_DIVISOR, RPL_DAG_MC, RPL_DAG_MC_ETX and RPL_DAG_MC_ENERGY are standard parameters specified in MRHOF [14].

Algorithm 1

figure a

Algorithm 2

figure b

4 Results and Discussion

4.1 Simulation

The proposed Objective Function (OF) has been simulated and tested in Contiki. It is an open-source operating system for memory-constrained, low power devices released under BSD license. We have used the COOJA network simulator present in Contiki for simulating the protocol with new Objective Function.

Nodes are taken to be static and organized randomly. Simulations have been carried out for Tmote Sky mote, Wismote, Z1 mote, etc. The number of nodes used for simulation ranges from 10 to 50. Table 3 shows the simulation parameters and their values.

Table 3 Network simulation environment
Full size table

4.2 Observation

The proposed Objective Function, MEHOF, has been compared with MRHOF and OF0. Since MEHOF has been designed to consider critical, non-critical, and periodic traffic patterns, we have considered the same while performing the simulation. We have considered important network parameters like packet delivery ratio, control overhead, average inter-packet time, and average power consumption of nodes for making the comparison.

  • Packet Delivery Ratio—The packet delivery ratio finds its definition as the ratio of packets successfully received out of the total packets sent. Results indicate a better performance of MEHOF compared to the other two when it comes to packet delivery ratio (Fig. 2).

    Fig. 2
    figure 2

    Packet delivery ratio versus number of nodes

    Full size image

  • Control Overhead—Control overhead is an indication regarding the number of control messages that are needed to be sent for the successful transmission of a packet. The simulation results indicate a significant reduction in terms of control overhead for MEHOF, as shown in Fig. 3.

    Fig. 3
    figure 3

    Control overhead versus number of nodes

    Full size image

  • Average Inter-packet time—It provides the measure of the times between packets arriving at a host over a period. As shown in Fig. 4, MEHOF outperforms the other two in all cases.

    Fig. 4
    figure 4

    Average Inter-packet time versus number of nodes

    Full size image

  • Average Power Consumption—An extensive simulation (results shown in Fig. 5) asserts that the average power consumption of nodes in MEHOF is comparable with that of MRHOF and OF0.

    Fig. 5
    figure 5

    Average power consumption versus number of nodes

    Full size image

From the above results, we can conclude that MEHOF provides better values for packet delivery ratio, control overhead, and inter-packet time, while providing comparable values for average power consumption.

5 Conclusion and Future Work

In this paper, we have presented an RPL variant which uses a novel Objective Function named Multiple instance ETX-Hop count Objective Function (MEHOF) so as to consider multiple routing instances running concurrently in the same network. We have considered different traffic patterns namely, critical, non-critical, and periodic, in order to test the protocol. Simulation results have shown a better performance, and thereby increased efficiency, for our proposed protocol.

Considering the fact that IoT is application oriented, scenarios involving multiple instances (each serving unique applications) need to be given due consideration. As part of future work, we aim to make the protocol more accurate by making the nodes to identify the number of instances in which it is a part of, rather than entering it manually. The same scenario can be extended to include mobile nodes also.