Abstract
The rapid proliferation of low-power wireless devices enables the industrial users to improve the productivity and safety of the plants as well as efficient management of the system. This can be achieved through significant increase in data collection, remote monitoring, and control of the plants and promoting the development of industrial Internet of Things (IoT) applications. However, the industrial environment is typically harsh causing high link quality variations and topology changes. The wireless devices used in this environment are also resource constrained in terms of energy, memory, and processing power. In spite of their low-power and lossy nature, these networks demand provisioning of differentiated services for various industrial applications having diverse quality of service (QoS) requirements. Considering the unique characteristics of low-power and lossy networks (LLN), routing for low-power and lossy networks (RPL) is devised which was standardized by IETF in 2012. To meet the demand of diverse traffic, RPL supports multiple instances in a single network. This paper proposes MI-RPL, a multi-instance solution of RPL for industrial low-power and lossy networks (LLNs). MI-RPL defines four instances for four distinct traffic classes of industrial monitoring applications in terms of delay and reliability. MI-RPL also introduces composite routing metrics and proposes an objective function (OF) to compute the most suitable path for each instance. The performance of MI-RPL is investigated through simulations that exhibit MI-RPL has better delay and packet delivery performance for delay- and reliability-constrained traffic along with lower energy consumption compared to the standard RPL.
1. Introduction
The recent boom in Microelectromechanical systems (MEMS) [1] and ad hoc wireless networking has paved the way for enormous opportunities of industrial IoT applications [2]. These applications necessitate a self-configuring, self-organizing, self-maintaining, and robust wireless networking solutions to meet the stringent application demands. Wireless sensor networks (WSNs) are being progressively deployed to monitor and control industrial processes. However, significant differences are evident between the requirements of general WSNs and industrial WSNs [3]. First and foremost, industrial IoT applications have diverse quality of service (QoS) requirements, particularly in terms of latency and reliability of data that require differentiated service provisioning. The resource-constrained sensor nodes usually operate in harsh industrial environmental conditions where the link quality varies greatly and network topology changes. Due to obstructions and noisy environments, the attainable capacity and link delay changes continuously which makes the QoS provisioning a challenging task. Moreover, as sensor nodes are battery powered, battery replacement is hardly possible in harsh environmental conditions and demands lower energy consumption of the nodes as well as longer battery lifetime of the network.
Considering the lossy (the term “lossy” signifies higher packet loss and high variability of packet loss due to the link quality variations and network topology changes) nature of the industrial environment, a number of standardization efforts have been made which mainly focus on designing reliable communication protocol for industrial IoT applications [4–6]. In 2008, the Internet Engineering Task Force (IETF) constituted the routing over low-power and lossy network (RoLL) working group to standardize a practical routing protocol for low-power and lossy networks (LLNs) over IPV6. In 2009, the RoLL working group presented some functional requirements for a routing protocol used in industrial LLNs [7]. Along with the industrial domain, the other targeted application domains of RoLL working groups include home and building automation [8, 9] and urban applications [10]. Finally, in 2012, RoLL finalized the standardization of RPL routing protocol, pronounced Ripple as described in RFC6550 [11].
RPL creates directed acyclic graph (DAG) representations in the physical network using routing metrics. One of the key issues in RPL is to choose a suitable objective function (OF) to find an appropriate route for the data generated by certain applications. The IETF draft in [7] proposes three broad categories and six different classes of industrial applications. Since the traffic classes are not yet standardized and different classes of traffic possess diverse QoS requirements, a single objective function to route the traffic for all traffic classes is not a viable solution. Thanks to the flexibility in the RPL standard that decouples the definition of OFs and routing metrics and allows to freely choose OFs, local policies, routing metrics, and constraints. To provide differentiated service for diverse traffic classes, RPL also provides the capability of using multiple instances in a single network. In particular, by using multi-instance support, RPL can create multiple routing topologies with different routing metrics in a single physical network. Although “multi-instance” is a key feature of RPL protocol, however, this feature has not been thoroughly studied in the literature yet. A number of solutions exist in the literature [12–15] that examine the multi-instance support of RPL in the smart grid domain exploiting two instances. Considering the unique features in the industrial environment as well as high diversities in industrial monitoring applications, no RPL compliant solutions still exist in the literature.
This paper proposes a RPL compliant solution, MI-RPL, to provide differentiated service exploiting the multi-instance support of RPL for industrial low-power and lossy Networks. In particular, our main contributions are as follows:(i)Considering higher degree of variations for industrial monitoring applications in QoS demands in terms of delay and reliability, MI-RPL categorizes industrial monitoring traffic into four classes and, hence, defines four classes of instances. So far, MI-RPL is the first attempt that investigates four different RPL instances in the industrial domain.(ii)MI-RPL defines a number of routing metrics and introduces an objective function to compute the optimal path for each instance.(iii)For a tree-based routing protocol like RPL, another essential requirement is to choose the routing metrics and their combinations in a manner that could ensure both loop freeness and optimality of the chosen routing path. MI-RPL validates both these properties of the proposed routing metrics.(iv)The objective function in MI-RPL computes the optimal path utilizing a suitable combination of the routing metrics for each instance. MI-RPL adopts both lexical and additive metric compositions for parent selection. To avoid monopoly effect on any routing metric, MI-RPL defines normalized routing metrics and utilizes the metrics in the additive composition.(v)The performance of MI-RPL is investigated through simulations, and the results show that MI-RPL attains lower end-to-end packet latency and higher packet delivery ratio while having lower energy consumption of the resource-constrained sensor nodes compared to the current RPL implementation.
The rest of the paper is organized as follows: Section 2 presents some background on RPL, Section 3 summarizes the related works, Section 4 discusses the system model and assumptions, Section 5 describes the detailed design of MI-RPL, Section 6 demonstrates the performance of MI-RPL using simulation, and finally Section 7 concludes the paper.
2. RPL Background
2.1. RPL Messages and Routing Tree Formation
RPL, standardized by the IETF ROLL working group, is mainly designed for low-power lossy wireless networks (LLN) and optimized for the routing necessities of data collection networks, where most of the traffic patterns are upstream dominant, in particular, the traffic flows from RPL nodes toward a single network aggregation point known as an LLN border router (LBR). RPL is a distance vector type routing protocol that constructs convergecast trees, referred to as DODAGs (Destination-Oriented Directed Acyclic Graphs), rooted at one or more LBR. RPL supports bidirectional IPV6 communication among nodes.
To build and maintain DODAG, nodes in RPL exchange various control messages, as a new type of ICMPv6 messages. RPL defines three types of control messages: DODAG Information Object (DIO), Destination Advertisement Object (DAO), and DODAG Information Solicitation (DIS). Figure 1 depicts the construction of a RPL DODAG and the use of different messages in RPL. The DODAG construction is initiated by the LBR through exchanging DIO messages to its neighbors. A DIO message mainly includes routing metrics and constraints, configuration parameters needed to adopt by RPL nodes, DODAG-ID, and the rank of a node. The rank of a node represents the virtual coordinates of that node in the graph hierarchy, in particular, its distance to LBR with respect to some metrics which is defined by an OF. Upon receiving the DIO message, each RPL node learns about its neighbors and their associated rank values. A node also computes its own rank value using an OF. Further, the OF specifies how to choose the preferred parent node from the parent set. The parent set is the set of neighbors having lower rank values. The preferred parent is used as a next-hop node on the upward route to LBR. Once a node joins a graph, it has a route toward LBR. If an RPL node is configured as a router, it disseminates DIO messages to its neighboring peers and continues DODAG formation. But if the node is a “leaf node,” it just joins the graph and stops propagating DIO messages further. After joining a DODAG, a node has a single routing entry toward its parent or may have multiple parents depending on OF to achieve higher reliability through multipath data delivery.
A RPL node may unicast DIS messages to proactively solicit a DIO message and probe the neighbor nodes. DAO messages are used to construct “downward” routes from LBR to leaf nodes. It is worth noting that DAO messages are propagated using the DAG structure created by the DIO message.
RPL exploits the “Trickle” algorithm to control the sending rate of DIO messages with the aim of achieving a balance between the control overhead and fast convergence. This algorithm implements a consistency check model to validate any obsolete routing information. The algorithm reduces the DIO transmission rate exponentially if no inconsistency is found. Otherwise, it readily schedules for DIO transmission to provide up-to-date information.
2.2. Multi-Instance RPL
Practically, a number of applications may generate diverse traffic types with diverse QoS requirements. In the presence of such traffic, RPL supports the creation of multiple instances in a single network. In particular, RPL can construct multiple routing topologies having diverse routing metrics in a single physical network. A unique objective function is used in each RPL instance. One or more DODAG can be constructed with the same objective function of a single RPL instance. However, a node can only join one DODAG in a single RPL instance, but it can be part of multiple DODAGs of multiple RPL instances. Both DODAG-ID and instance ID uniquely identify a DODAG. Different instances are created to support various requirements of diverse applications. Hence, a multi-instance RPL can be used for better utilization of RPL nodes through sharing of resources as well as it supports reusability of RPL nodes. A single RPL node can contribute to multiple applications depending on its functionality.
When a RPL node joins more than one RPL instances, it maintains multiple routing entries associated with each objective function. Upon receiving a packet, a node decides its corresponding instance by examining the traffic type and then forwards the packet to the appropriate parent node. Figure 2 depicts the RPL DAG structure with multiple DODAGs and multiple instances. Every instance has been created using a separate OF. As shown in this figure, node 9 belongs to three instances: instance 1, 2, and 3, where both instance 1 and 2 have the same destination, LBR-1, and the flows generated for instance 3 has a destination LBR-2. It is to note that both LBR-1 and LBR-2 have instance 1 but have different DODAGIDs. Node 3, for instance, joins instance 1 with DODAGID-2 and cannot join the same instance with DODAGID-1.
3. Related Works
Regarding the path selection, the RPL standard does not impose any specific OF or routing metrics to be used. IETF provided some directions on how the OF should be implemented [16–18] but no specification about any routing metrics to be used. RFC 6551 [19] presents some recommendations on routing metrics and constraints to be used in RPL, but still leaves the choice of metrics selection to implementations.
Currently, the most widely used metrics used in the majority of RPL implementations are HC (hop-count) used in OF0 [16] and ETX in Minimum Rank with Hysteresis Objective Function (MRHOF) [18]. HC considers the number of hops to determine the best path. ETX chooses the path that requires minimum transmission attempts to deliver data towards the destination. In [20], the authors showed how a number of routing metrics can be combined including additive and lexical combination. The authors also evaluated the performance of a number of combined metrics such as HC with remaining energy and HC with Packet forwarding Indication (PFI) metric.
QU-RPL [21] introduces queue utilization along with ETX to address the load-balancing problem in RPL. An energy and congestion-aware routing metric [22] is also proposed for the RPL implementation in a smart grid environment that takes into account both residual energy and queue utilization as a routing metric. In [23], the authors proposed an energy-based objective function considering the remaining energy as a routing metric. metric is proposed in [24] combining both ETX and residual energy. Gonizzi et al. proposed a delay efficient routing metric [25] for RPL to minimize the delay toward the DAG root. However, all these studies introduce a single routing metric for a single instance of RPL DODAG and optimize certain QoS parameters.
Although RFC6550 recommends “multi-instance” as a key feature of RPL protocol, however, this feature has not been thoroughly investigated in the literature yet. Few studies [12–15] examined this feature in different application domains. Rajalingham et al. [13] proposed RPL-M, a multi-instance solution for RPL in a smart grid environment. RPL-M creates two instances, one exploiting ETX and the other using HC. However, the solution considered 802.11b as the underlying link layer which is unworkable in the LLN environment. Using the same metrics, the authors in [14] evaluated the performance of two instances of RPL using the COOJA simulator. Recently, Nassar et al. proposed an objective function, OFQS for smart grid network [15]. This OF utilizes a multiobjective metric, mOFQS, that considers delay and link quality along with remaining energy in the battery. By varying the weight of different parameters in the metric, the solution creates two instances that emphasize a particular QoS parameter for two types of applications, critical and regular. All these existing multi-instance solutions for RPL, however, mainly considered two instances and mostly in the smart grid domain. But the industrial IoT monitoring applications have high degree of diversities in achieving QoS that requires dealing with more than two instances for different traffic classes. Moreover, the industrial wireless environment has unique features as discussed earlier in Section 1. This motivated us to design MI-RPL, a multi-instance solution of RPL for industrial LLNs.
4. System Model and Assumptions
Figure 3 depicts the system model of our proposed scheme. Following the standard as proposed in ANSI/ISA100.11a [4], we consider a set of n sensor nodes, forming a mesh topology where the formed network is regarded as a low-power lossy network due to the harsh industry environment as well as resource-constrained properties of the nodes. The network also contains one or more LBR, and the nodes route the sensed data towards LBR in a multihop manner. Routing tree is formed employing multi-instance RPL protocol, and a node can be part of more than one instance based on the relevant OF as discussed in Section 2. The LBR transmits the collected and processed data to the gateway node which then forwards the data to the plant network for further actions. However, in this paper, we mainly focus on data routing functions from sensor nodes to the LBR and the communication between the LBR to the gateway and gateway to the plant network is out of scope of this paper.
We assume every node uses fixed transmission power for communication with the neighboring nodes. Thus, the network can be modeled as , where is the set of all possible communication links. The neighbor set of , denoted as , are the nodes with which has a communication link. All the links are assumed to be symmetric, in particular, if , then . Each node is supposed to be aware of its current battery status or current energy level, .
5. MI-RPL: A Multi-Instance RPL for Industrial LLNs
In general terms, MI-RPL provides differentiated services for industrial low-power and lossy networks exploiting the multi-instance feature of RPL protocol. This section discusses the details of MI-RPL. First, we classify the instances based on the traffic type. Then, we define the routing metrics used in different instances. Finally, we present the objective function describing the procedure to compute the optimal path for different instances.
5.1. Instance Classification
As per the standard for industrial applications, ISA-SP100.11a, the ISA100 standardization committee categorizes industrial applications into safety, control, and monitoring applications. Among the three categories, safety and control applications are critical and require satisfying hard QoS in terms of both delay and reliability. Hence, these two applications have gained low interest to both the users and the vendors, compared to the monitoring applications on which most of the users and vendors () are of paramount interest according to the survey result carried out by the International Society of Automation [4]. The monitoring applications, otherwise, possess soft QoS requirements where successful data delivery is the main concern and acceptable delay requirements are in the order of seconds to minutes [26]. Hence, in this paper, our primary focus is on industrial monitoring applications.
Industrial monitoring applications are commonly periodic, for instance, periodic transmission of pressure, temperature, signal level, and so on, and one to several minutes delay can be acceptable with reasonable reliability requirements. Yet, some applications demand a higher reporting rate of the observed phenomenon in every few seconds [4]. On some occasions, the monitoring applications can be event-driven and possess strict delay and reliability requirements. Thus, based on diverse QoS demands of industrial monitoring applications in terms of delay and reliability, in this paper, we define four classes of instances for four traffic classes as follows:(i)Instance 1 []: I1 deals with the traffic that has both low-delay (i.e., one to five seconds) and high-reliability (i.e., 90 to 100%) requirements.(ii)Instance 2 []: the traffic having latency constraints (i.e., one to five seconds) but without strict reliability requirements belong to this instance. This type of traffic can tolerate some packet losses due to its monitored phenomenon which is characterized by spatial correlation.(iii)Instance 3 []: some industrial monitoring applications that need offline postprocessing to generate traffic with higher reliability demands (i.e., 90 to 100%), but allow latency for about one to several minutes belong to Instance 3.(iv)Instance 4 []: traffic that belongs to this instance has neither strict delay nor reliability constraints and is regarded as normal traffic. This type of traffic can tolerate delay for one to several minutes, and also the packet error rate can be in the range of 20–30%.
5.2. Metrics in MI-RPL
To support differentiated services using multiple instances, MI-RPL exploits a number of metrics. For each instance, a combination of metrics are utilized as a composite routing metric to provide the desired QoS for the traffic type. This section describes the metrics used in different instances of MI-RPL.
To represent the routing metrics, we use the routing algebra as mentioned in [27, 28], where a routing metric can be symbolized by the quadruplet . Here, S is the set of all paths, is the path concatenation operation, ω is a mapping function for path to weight, and is an order relation. In particular, considering two paths , denotes the concatenation of two paths p and q, denotes the weight of path p estimated using a specific metric, and the order relation denotes “path p is lighter (better) than or equal to path q.” To ensure a routing path be “loop-free” the routing algebra defines monotonicity property [28]. A routing metric is monotonic if and holds and is strictly monotonic if and . This monotonicity property also holds while computing the rank of a node. In particular, the rank of a node must monotonically increase from root to the leaves. Also, a routing metric is isotonic if and only if signifies both and and is strictly isotonic if and only if signifies both and . The isotonic property of a routing metric ensures the optimality of the routing path [28]. In [29], the authors presented two theorems stating the necessary conditions for a metric to be strictly monotonic and strictly isotonic. Theorem 1 states that any metric which is additive over the path, the path weight is positive for any link and the order relation is “less than or equal” order defined for real numbers, then this metric is strictly monotonic. Theorem 2 states that any metric which is additive over the path and the order relation is “less than or equal” order defined for real numbers, then the metric is strictly isotonic. We verify both the properties of our proposed routing metrics based on these theorems.
Hop-count is one of the widely used metric to decide the route cost that reports the number of traversed nodes along the path also defined as a default metric in RPL used by OF0 [16]. We adopt this metric in MI-RPL which is mainly used for rank calculation. Using the hop-count metric, the weight of a path p is the summation of the links that creates the path. For concatenation operation, . The weight of the LBR, , and the weight values range in positive integers. The order relation is “less than or equal” where the lowest values are better. This metric satisfies all the conditions of Theorem 1 and Theorem 2, hence is strictly monotonic and strictly isotonic.
Since delay and reliability are of primary concern for all instances, our focus is how to choose those metrics that reflect the path latency and path reliability in an efficient way. Considering the latency, the two dominant sources of delay include transmission delay and queuing delay. We can ignore the processing and propagation delay taking into account the minimal processing operation compared to the processing speed as well as shorter distance between nodes in the industrial wireless network environment.
We define the transmission delay, , at as the time interval required for successful packet transmission, including the reception of acknowledgment. It is measured from the time a packet is ready to be served at the MAC layer to the time the ACK of the packet is received. Let be the time when a packet appears at the head of the queue and ready for transmission, be the time when the ACK of the packet is received, be the length of the ACK, and R be the link capacity. Therefore, is estimated as
Exponential weighted moving averages (EWMA) is used to measure the running average of this delay as follows:where is the current observation of the transmission delay and α is the tuning parameter that satisfies .
A node includes this in the DAG metric container of the DIO message as latency object and is used as an additive metric. This metric is positive for any link, and is “less than or equal” defined for real numbers. As it satisfies all the conditions of Theorem 1 and Theorem 2, it is both strictly monotonic and isotonic, and thus possesses the “loop-freeness” and “optimality.”
Regarding reliability, again, we adopt the ETX metric as defined in RPL [19]. ETX defines the average number of transmissions including retransmissions a node expects to make to successfully forward a packet to the destination. The successful delivery is ensured through the reception of link layer acknowledgment. Let be the total number of transmissions (including retransmissions) from to and be the total number of ACK receptions by node from which in turn indicates the total number of successful transmission from to . Hence, ETX over the link () for node can be estimated as
In order to smooth estimation of , EWMA is used that makes it robust for abrupt changes in link condition. MI-RPL uses as an additive metric and is included in the DAG metric container as the ETX object. Since ETX is an additive metric, and for any link and the order relation is “less than or equal,” it satisfies all the conditions of Theorem 1 and Theorem 2, and is both strictly monotonic and isotonic.
Although ETX addresses link reliability, however, queue loss is another dominating factor that affects reliability. In [21], it is proved that the use of ETX solely cannot address the packet loss effectively, hence, the queue utilization is another metric that needs to be considered. Let be the current queue length of node and be the total queue size of node . Therefore, queue utilization, , at is estimated as
We exploit the same EWMA filter for smooth estimation of . Like the earlier metrics, is also an additive metric and needs to be minimized for the nodes along the path to LBR, i.e., the lower the utilization, the lower the packet loss. Since queuing delay is another dominating factor that influences the end-to-end delay, choosing a path with low queue utilization also has a significant impact on achieving lower end-to-end delay. Thus, the metric addresses both reliability as well as latency. Since , is monotonic but strictly isotonic and this metric is embedded in the DAG metric container as the node state attribute object. Also, to avoid the congestion situation around a node, a node advertises the value of as INFINITY when , where δ denotes the congestion threshold. This prevents a congested path not to be chosen by a node.
Furthermore, irrespective of the traffic type, remaining energy of a node is another striking metric that should be taken into consideration to address the energy efficiency in path selection. Let be the maximum initial energy at node and denote the currently available energy at node . Thus, we estimate the remaining energy, , at as
We use as additive metric i.e., the remaining energy of a path is the summation of the remaining energy of all the nodes along the path. Since and the order relation is “less than or equal” over real numbers (the lower the value of , the better the path), the metric is strictly monotonic and isotonic as it satisfies both Theorem 1 and Theorem 2. This metric is included in the DAG metric container as the node energy object.
5.3. Objective Function in MI-RPL
The objective function in MI-RPL is designed to compute the optimal path cost for different instances utilizing the metrics as discussed in Section 5.2. Since different instances possess diverse QoS requirements, a composite routing metric is created for each instance utilizing a suitable combination of the metrics.
MI-RPL utilizes only the hop-count metric for rank calculation, i.e., the rank of a node is the hop-count from the node to the LBR. For parent selection, it uses a combination of hop-count and other metrics for different instances. We adopt both lexical and additive metric compositions for parent selection. For all instances, a node determines its parent candidate set, , from its neighbor set, , as
By exploiting the lexical metric composition of both hop-count and remaining energy, equation (6) ensures that the parent candidate set includes only those neighbors whose rank is less than the node as well as the neighbors for which the remaining energy exceeds some threshold η.
To choose the best parent among the candidates, MI-RPL exploits additive composition of metrics and defines a composite metric for each instance. However, as the resulting values of different metrics are diverse in their ranges, we normalize the values of the considered metrics in the domain to eliminate the dominating effect of any particular metric.
Upon receiving the respective metrics in the DAG metric container, a node normalizes the corresponding QoS metrics of its potential parent candidates, , as follows:
Utilizing the normalized metrics, we define the composite routing metrics for different instances as follows:where , , , denote the routing metric for Instance 1, Instance 2, Instance 3, and Instance 4, respectively, and β is a coefficient to tune the weight of compared to the other metrics used and .
Following the characteristics of different instances, equation (8) addresses the delay (transmission delay and queuing delay) as well as reliability (link reliability and queue loss), equation (9) addresses delay (transmission delay and queuing delay), equation (10) addresses reliability (link reliability and queue loss), and equation (11) only addresses remaining energy metric as it has neither reliability nor delay requirements. Notably, the metric is considered along with the other QoS metrics in equations (8)–(10) to influence the remaining energy in the path selection procedure for the respective instance.
After computing the path cost using routing metrics for different instances for the nodes in the parent set, a node chooses its preferred parent for a particular instance, , among the candidate parent set as follows:
A node performs this parent selection process if either of the two conditions are met. First, any metric value of an existing neighbor including the preferred parent in the parent candidate set for a particular instance changes. Second, a new candidate neighbor of a particular instance is inserted into the parent candidate set. However, to avoid unnecessary and frequent inefficient parent changes, MI-RPL exploits the hysteresis component as in [18] and changes its parent node from the current parent, , to its best alternative parent, , for a particular instance, , ifwhere γ is a stability bound to control the parent changes.
After choosing the best parent for a particular instance, each node updates the metric value for a particular instance, , as follows:where , , , and are the updated metric values to be included in the DAG metric container of a certain instance.
6. Performance Evaluation
This section presents the performance evaluation of MI-RPL conducted through simulations.
6.1. Simulation Settings
The simulation is carried out using the Contiki 3.0 operating system through its default simulator, Cooja [30, 31]. A network of 60 Zolertia motes with one DODAG root is formed, where the motes are randomly dispersed on a area and the DODAG root is positioned at the center of the network. Figure 4 depicts the network structure. Unit Disk Graph Medium (UDGM)-Distance Loss is used as the radio model, which is the default radio model in Cooja. The transmission and interference range is set to 50 m. The transmission success ratio of is considered while the reception success ratio varies between and . Since multi-instances are not fully supported in Contiki, we adopt the implementation [32] that supports multiple instances and modified it. No downward traffic is considered. In our implementation, we consider a node probabilistically chooses its instance to join when it receives a DIO message from its neighbors. The nodes in any instance produce CBR traffic with varying data interval. UDP is used as transport protocol, and the payload size for each instance is 30 byte. The queue size is set to 10 packets. The minimum DIO interval and doubling parameters are set to default values in ContikiRPL. The Energest module in Contiki is used to estimate the battery power consumption, and different values of energy consumption for transmission, reception, idle listening, and power down are taken from the Z1 datasheet [33]. The simulation is carried for 2 hours, and the results are averaged over 10 random runs. The simulation parameters are depicted in Table 1.
6.2. Results and Analysis
This section presents the simulation results and their analysis. We evaluate MI-RPL under different performance metrics such as average end-to-end latency, packet delivery ratio, and average energy consumption and compare its performance with RPL implementation using the MRHOF objective function [18]. In all the experiments, we tend to observe the impact of traffic load as well as link quality. In the wireless industrial network environment, both these factors are crucial due to the application diversity and high link quality variation. In the evaluations that observe the traffic load impact, we consider reception ratio (Rx ratio), and in the evaluation showing the impact of link quality (varying Rx ratio), we set the traffic load to 15 packets per minute (ppm).
6.2.1. Latency Performance
Figure 5(a) illustrates the latency performance with varying traffic load from 5 ppm to 30 ppm for all the instances and compared with the RPL with MRHOF. As the figure depicts, the average end-to-end latency increases with traffic load in all cases. This is obvious since the increase in traffic load increases the link layer contention that affects transmission delay as well as node level congestion which increases the queuing delay. Moreover, the high traffic load also causes packet losses and incurs delay due to retransmissions. However, both the delay-constrained instances (I1 and I2) in MI-RPL show considerably better latency performance as compared to RPL with MRHOF. This is due to considering both transmission delay and queue utilization in their respective routing metric. However, I3 shows comparatively lower delay performance than I1 and I2 as transmission delay is ignored in its routing metric. In contrast, RPL with MRHOF only considers ETX as a routing metric and ETX does not take into account the link contention as well as queuing in the nodes as long as the packets are successfully transmitted. The instance, I4 exhibits the worst delay performance as it considers only remaining energy as a routing metric.
(a)
(b)
In Figure 5(b), the latency performance is evaluated as a function of the Rx ratio. In highly lossy environment, the average latency is significantly higher for each cases which decreases sharply with increasing Rx ratio. This is due to the higher number of retransmissions at low Rx ratio which in turn increases contention as well as congestion even though the application of traffic load is moderate. However, both I1 and I2 in MI-RPL show comparatively lower average latency than RPL with MRHOF as well as the other instances (I3 and I4) in different Rx ratios because of considering all the delay factors in their routing metric.
6.2.2. Packet Delivery Performance
The packet delivery ratio with diverse traffic loads is illustrated in Figure 6(a). Both MI-RPL and RPL with MRHOF exhibit better packet delivery performance at low traffic load (above ). As the traffic load goes high, the PDR slightly decreases for both reliability-constrained instances, I1 and I3, in MI-RPL. Yet, MI-RPL shows much better PDR (near ) as compared to RPL with MRHOF () even at the high traffic load as the routing metric of the instances considers not only link ETX but also queue utilization. Thus, MI-RPL reduces the burden on the congested nodes which in turn decreases queue loss. However, since ETX is not considered in the routing metric of I2, it shows comparatively poor PDR performance than I1 and I3. Still, I2 shows better PDR than RPL with MRHOF as it takes into account queue utilization which significantly dominates PDR. Clearly, being neither delay and reliability constrained, I4 exhibits the worst PDR.
(a)
(b)
Similar PDR performances have also been observed for MI-RPL instances and RPL with MRHOF in different Rx Ratio as depicted in Figure 6(b). However, in this experiment, we observe poor PDR for both MI-RPL and RPL in a high lossy environment while the Rx Ratio is low (20%). This is obvious since in a poor link environment the packet retransmission increases excessively which accelerates packet loss for both contention and congestion. However, with the increase in Rx ratio, the PDR increases dramatically for both MI-RPL and RPL.
6.2.3. Routing Overhead
In this experiment, we mainly investigate the control overhead of MI-RPL compared to the RPL protocol. As MI-RPL considers only upstream traffic towards LBR, we evaluate the overhead for DIO message transmission as well as the number of parent changes for upstream traffic.
Figure 7 illustrates the average DIO overhead of each node under different traffic loads over the simulation period. Being a multi-instance protocol, MI-RPL incurs extra overhead compared to RPL with a single instance. This is understandable since MI-RPL creates and maintains multiple routing trees for multiple instances through exchanging distinct DIO messages for each instance. Moreover, with the increase in traffic load, the average DIO also increases. This is because at high traffic load, the routing metric for different instances also changes frequently that causes frequent parent changes. This behavior is also depicted in Figure 8. Because of using diverse metrics for different instances, a higher number of parent changes per node are also evident in low and moderate traffic load compared to RPL with a single instance and a single routing metric. This topology changes results in higher control traffic overhead for MI-RPL. However, the frequency of unnecessary topology changes are also controlled exploiting the hysteresis component used in equation (12). Furthermore, if we take into account the lightest traffic load (5 ppm/node), a node generates 300 packets per hour or 600 packets in our simulation period, which is almost 15 times more than that of DIO traffic. In particular, the overhead is less than of the data traffic. Since MI-RPL shows considerably better PDR than RPL, the overall data transmission cost is curtailed. Moreover, the better latency performance of MI-RPL also signifies its applicability to delay-constrained applications. Therefore, this DIO overhead increase is acceptable cost to compensate for better PDR and latency performance.
6.2.4. Energy Consumption
Figures 9(a) and 9(b) portray the average energy consumption varying traffic load and Rx ratio, respectively. Here, we consider the average energy consumption for the nodes irrespective of the instances they join. Commonly, the average energy consumption increases with the increase in traffic load for both the protocols as shown in Figure 9(a). In this regard, MI-RPL outperforms RPL in all the traffic loads as it considers remaining energy of a node in the routing metric for every instance that influences the selection of a parent having higher remaining energy. This objective function not only limits the energy consumption but also increases the network lifetime by protecting nodes to be died in a short period. As a multi-instance protocol, MI-RPL incurs some routing overhead that might affect energy consumption; however, this control overhead is insignificant compared to the data traffic load as explained earlier. Similar performance for MI-RPL is also observed in different Rx ratio as depicted in Figure 9(b). However, in this case, MI-RPL shows better energy gain in the lossless environment having higher Rx ratio than the lossy environment. The reason is the significant number of packet retransmissions in lower Rx ratio that causes the energy depletion of the nodes at a higher rate. Moreover, this situation causes frequent parent changes for all the instances which increases control overhead resulting in higher energy consumption.
(a)
(b)
7. Conclusion
In this paper, we have investigated the effect of multi-instance support of RPL with the aim of differentiated service provisioning for diverse traffic classes of industrial IoT applications. In that context, we have proposed MI-RPL that introduced four RPL instances in a single network. MI-RPL defined composite routing metrics for each instance and presented objective functions specifying the procedure of computing optimal path cost for each instance. We have evaluated the performance of MI-RPL through extensive simulations that proved that our proposal attains significantly lower end-to-end delay and higher packet delivery ratio in different traffic loads and link quality for delay- and reliability-constrained traffic classes, respectively, as well as achieves lower energy consumption for all traffic classes as compared to the standard RPL with MRHOF.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.