Performance Investigation of RPL Routing in Pipeline Monitoring WSNs

In this paper, the adoption of WSN and IEEE 802.15.4 standard for the linear WSN networks were considered. The interconnection of WSNs with the Internet is possible by assigning IPv6 addresses to low-power devices. The 6LoWPAN adaption layer enables the IPv6 addresses assignment with low levels of overhead. To facilitate maximum efficiency of WSN, integrated with IoT, the routing protocol RPL was developed to be compatible with 6LoWPAN networks. The main contribution of this paper is on identifying problems at the level of routing in WSN, and a study of specific metrics used to calculate the forwarding cost between nodes in a Multi Segment Linear Pipeline Monitoring WSNs. The RPL protocol was implemented on OMNeT++ simulator with the objective of analysing the behaviors of ETX, HOP-COUNT and RSSI routing metrics. ETX achieved the best results, while RSSI has shown poor results. However, HOP-COUNT, has shown good results in terms of routing stability with fast convergence and lower delay.


INTRODUCTION
The advent of the Wireless Sensor Network (WSN) has resulted in a vast number of both current and potential applications for this network technology. In fact, it may be argued that in this case it is the applications inherent in the use of WSNs driving the developments in this technology. In this regard, when applying the use of WSNs to situations where the sensors must be lined up rather than spread over an area, a subset of WSNs is created. Namely, a Linear Sensor Network (LSN). The need for LSNs arises when use of sensor networks are required in areas such as the monitoring of roads and bridges, but perhaps most pertinently, in pipelines [1][2] [3]. There are many benefits to be gained by utilising sensors in the monitoring of pipelines, with many of these dependent on the purpose of the particular pipeline. This could involve oil, gas or possibly water. Sensors can gather information on the pipeline itself in regard to temperature and the flow of water or oil and the pressure extended on the pipeline [1]. The environment in which the pipeline is located may also be monitored via sensors in order to detect leakages or fire, with the possibility of also relaying camera images via sensors. The use of wireless sensors in these situations also improves upon cabled networks in that they are less prone to failure. With security, also a concern in some areas, wireless sensors remove the possibility of deliberate damage being inflicted to cabling [1].
The obvious benefits in the application of LSNs has driven the need for research in this area. However, related work is sparse which may be due to the difficulties inherent in improving data delivery in LSNs. Whilst the lack of complexity in physical layout of a LSN over other WSNs may at first give the impression of a simple implementation, the opposite is commonly the case. This is due to the lack of 'wiggle room' when seeking to make improvements in network performance. Whereas in more complex network structures the opportunity will exist to develop combinations of Layer 3 metrics and algorithms to ensure an optimal combination of efficient data delivery and energy consumption, this is not generally possible in a LSN.

RPL OVERVIEW
When considering routing with 6LoWPAN within a Lowpower and Lossy Network (LLN), due regard must be given to the environment and particular requirements compared to those associated with more traditional routing protocols. When routing occurs over a reasonably reliable infrastructure, nodes will be considerably more powerful than those found in an LLN and routing protocols have been developed with this in mind. Routing protocols such as Open Shortest-Path First (OSPF) [6], a link-state protocol, the assumption is that the topology will rarely change and a router will only update its topology in the event of a major change. Such as a new router being added or a link going down. This approach is clearly unworkable in LLNs where firstly, nodes have limited memory and therefore would not have the capabilities to store extremely large topology maps and routing tables. Reference must also be made to links going down, which in an LLN can happen regularly, especially considering the extreme environments that some LLNs may be located in. The lossy nature of an LLN means that links can go down and then come back up quite regularly therefore it would be highly inefficient to send messages with this information on every occurrence. There would also be consideration of the lowpower nature of Wireless Sensors, where various energy saving techniques can be utilised such as sensors going to sleep until required, in order to conserve valuable battery power.
With it firmly established that no existing protocol provided the solution to these issues, in 2008 the IETF ROLL working group [7] was established with the purpose of creating a standardised routing solution for LLNs. This resulted in the standardisation in 2012 of the IPv6 Routing Protocol for Lowpower and Lossy Networks (RPL) [8], a distance-vector routing protocol.
MP2P is important in applications where many leaf nodes collect data, such as in a sensor network. This results in traffic mainly being sent from these nodes to a central point for data collection, or a sink as it is commonly referred to. This also produces a requirement for P2MP traffic flow in the event of the sink sending requests to the leaf nodes in the network [9]. For P2P, traffic difficulties would arise due to many nodes within a WSN not actually having routing capabilities (RFDs). RPL network structures (DODAGs, to be covered later) provide for P2Ps if not in the complex way that more traditional routing protocols would [8]. Consideration must also be given to the varying sizes of these networks which can vary from just a few nodes to some applications which host millions of nodes.
Flexibility of routing is of paramount concern when considering RPL. This is reflected in how the use of a network topology within RPL was approached. RFC 6550 [8] specifies building a destination oriented directed acyclic graph (DODAG). A DODAG is a logical topology placed over a physical network of which there can be several and of which a node can be a member of multiple occurrences. The characteristics of a DODAG will reflect Quality of Service (QoS), or constrained-based routing requirements, in such that each DODAG 'instance' has a particular role to provide, regarding routing across the physical network. A DODAG is built according to an Objective Function [10]. It can be stated that "The Objective Function (OF) defines how RPL nodes select and optimize routes within a RPL Instance" [8].
A node can be in multiple instances of DODAGs and can be a DODAG root in one without having to perform the same role in another. Reference to the direction of routes is made in regard to the DODAG root. 'Up' refers to travelling from leaf nodes towards the DODAG root whereas 'down' refers to travelling from the root towards leaf nodes. A node's rank is also given in respect to the DODAG root, with the value increasing in the 'Down' direction and decreasing in the 'Up' direction. Rank is computed depending upon the OF of the DODAG and is significant with regard to building and maintaining a DODAG, with one of its main purposes being the selection of a DODAG parent for a node. In order for a node to become part of a DODAG it must have a valid parent, that being a one-hop destination with a lower rank (therefore 'upward' destination). This is also important in P2P traffic flow, ensuring any destination can be reached by sending a packet 'upwards' until it reaches a node which is part of the ancestral tree of the destination, and can therefore proceed to move 'downwards' towards it [8] [9].
Much as with other routing protocols RPL uses the exchange of ICMP messages to build a topology. In the case of RPL the messages are ICMPv6 and the three message types used are: • DODAG Information Object (DIO). Used for DODAG discovery, sent to advertise a DODAG in the 'Down' direction to build 'upward' routes to the DODAG root. Advertises routing metrics and constraints [11]. • Destination Advertisement Object (DAO). Used to establish 'downward' routes therefore sent in the 'Up' direction. Can optionally be acknowledged by the destination node with a Destination Advertisement Acknowledgement (DAO-ACK) message. RPL specifies two kinds of nodes for downward routing. Storing nodes effectively use their own routing tables to determine the next-hop for a packet whereas nonstoring nodes do not have routing tables for downward routes, the route the packet must take is populated in the packet by the DODAG root. Within RFC6550 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [8] there is no scope stated to specify DODAGs with both storing and non-storing nodes. Due to the complexity involved, RPL networks are only expected to be either nonstoring and therefore have no 'downward' routes, or storing. This would appear to be a topic for future investigation [8] [9]. • DODAG Information Solicitation (DIS). Used to solicit DIO messages from nodes, much like a router solicitation message in a traditional network [8] [9]. The structure of a DODAG is built by the sending of DIO messages 'Down' from nodes. The size of the transmission window for sending these messages is decided using the Trickle Algorithm [12]. This allows for a dynamic window depending on various factors. For example, in the event of a DODAG inconsistency (a change in parameters such as DODAGID) being found, the frequency of messages would increase. This would also be the case if a loop was detected, or if there is movement of a node in the current DODAG or to join a new DODAG. If an inconsistency is detected a node shall reset its Trickle timer to zero in order to increase the frequency of DIO messages. There are options on start-up of a node which may remain inactive until it receives a DIO message or alternatively it may send a DIS message in order to solicit DIO messages. It may also decide to exchange DIO messages with the aim of creating a floating DODAG, which can be used in the event of there being no grounded DODAG root and can maintain internal connectivity between a set of nodes [8].
The most important consideration is of Rank when a node considers what to do when receiving a DIO message. Firstly, an invalid DIO would simply be discarded. Otherwise, the node firstly determines whether the DIO message was sent by a candidate neighbour. A candidate neighbour set is defined as thus "the candidate neighbor set is a subset of the nodes that can be reached via linklocal multicast" [8]. If this requirement is met the node must now look at whether the DIO is being sent in relation to a DODAG that the node is currently a member of. The first rule to be observed is what is referred to as the max_depth rule [9].

A. RPL Routing Metrics and the Objective Function
The construction of a DODAG is performed in accordance with an Objective Function (OF). While an OF can be the sole driver in this construction, such as in "RFC6552: Objective Function Zero" for RPL [10], generally the OF uses metrics and constraints to build the DODAG and the routes within. As is the case with The Minimum Rank with Hysteresis Objective Function (MRHOF) [13].
As has been previously stated, constraint-based routing account for restrictions on nodes such as energy-saving, CPU levels and memory capacity [9]. As such an OF may include or exclude routes depending on these requirements. A metric is more relevant to the cost of the path in regard to a routing destination. For example RIP uses hop-count as metric, the pathcost being the number of hops to a destination [14]. In the case of RPL the use of constraints and metrics is combined into a routing object. For example, the routing object could specify a constraint such that the OF should prune any paths with nodes below a certain memory capacity or could specify a metric such as hop-count. The values, however, are not exclusive and can be used as either constraint or metric in that a hop-count could also be used as a constraint to only use paths above or below a certain number of hops [9] [11].

B. Objective Function Zero
The Objective Function Zero (OF0) [10] is a default OF for RPL which does not, in fact use a metric. Instead, OF0 uses Rank to decide upon the preferred next hop. OF0 also utilises a 'feasible successor' in the event on the preferred successor not being available. In most installations of RPL, this will produce similar results as if the 'Hop-count' metric was being used. Therefore, it is recommended that actual dynamic metrics such as Link Quality Level Reliability or ETX are used [10].

C. The Minimum Rank with Hysteresis Objective Function
The Minimum Rank with Hysteresis Objective Function (MRHOF) [13] again seeks to reduce the distance to a destination. However, unlike OF0, MRHOF utilises metrics in this regard. As has been stated previously, the OF itself is not an algorithm. In the case of MRHOF it determines the shortest path using the metrics or constraints carried within the metric container advertised in the DAG container option in DIO messages [8]. If no metric is advertised in the DIO messages then MRHOF will default to the ETX metric [13]. However, MRHOF can use any of the metrics defined in "RFC6551: Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks" [11] such as Hop Count, Link Latency, ETX, RSSI, Node Energy, Throughput.
Due to the constant change in the characteristics of both nodes and links within LLNs due to interference, other environmental issues or simply loss of energy, routing metrics must be dynamic. RPL must also manage these dynamic metrics in such a way as to avoid variances in routing.

D. Routing Metrics
Three metrics are proposed and described to calculate the cost of RPL referrals. The cost is calculated through an objective function, composed of one or several metrics. Some objective functions are proposed according to the metrics presented below.

Minimum Hop Count (Minimum Hop Count)
Initially, when the routing protocols in low-power wireless networks and high restrictions began to be studied, the most used metric to create paths was hop-count counting between sender and receiver, included in the Class protocol distance-vector. Specifically, the DSDV and AODV protocols assume that all connections between nodes are either 100% reliable or do not work at all. An unrealistic approach in WSNs. Due to the dynamic nature of the channels, especially in networks of reduced power and performance in terms of binary output, the communications undergo variations related to interference and concrete characteristics of each application such as line-of-sight factors. The hop-count metric also undergoes network-level performance failures, especially in dense networks. Minimizing the number of hops increases the distance of each jump, minimizing RSSI and the loss rate. And even if the best routing is the one that keeps the fewest jumps, there may be other possible routing, with better performance and better quality of service. Therefore, the choice of routing with the least number of hops will not always be the best routing possible [11] [17].

Expected Transmission (ETX)
The solution proposed in [17] for creating paths is the Expected Transmission (ETX) metric [13]. Through the ETX, the routing is created in the connections where it is expected to have the minimum of transmissions and retransmits of a package until arriving at the destination. Because the resulting ETX assigns a cost to bidirectional connections by the rate of losses they have on downlinks and upstream links, the choice of routers with high bit rate is forced. The basic calculation of this quotient can simply be inferred by the number of transmissions, t of p data packets successfully delivered between the node x and the node y [18] (1.0).
g(x , y) = t/p (1) The ETX makes an indirect count of the number of hops. For example, if the connection between two nodes (one-hop only) has a success rate of 50%, the ETX will equal 2. However, if the same connection has an intermediate node, relying on packet delivery in two hops, and if both links have a success rate of 10%, the ETX will also be equal to 2.

Received Signal Strength Indicator (RSSI)
Whilst the use of hop-count and ETX are common approaches in the utilisation of the RPL routing protocol, the use of RSSI is less so. In the most basic terms, RSSI is the measurement of the strength of a signal at the point of reception. As such, a higher RSSI indicates a stronger and more powerful signal transmission. In the case of routing, this involves utlising this measurement in order to determine the best path to a destination based on signal strength. In this regard RSSI is therefore used as a pure routing protocol, as is the case within this paper. However, other studies have utilised RSSI as a threshold [19]. As the standardisation of RPL allows for the use of routing constraints as well as metrics [5], this raises the possibility of future work where RSSI is used in this way. In the case of this particular study, the evaluation of the performance of RPL with RSSI used as a routing metric is seen as a novel approach. This is aided by the implementation of RPL on the Omnet++ simulator [20].

PERFORMANCE EVALUATION AND DISCUSSION
In this section, a simulation approach is considered to analyze three routing metrics discussed previously ETX, HOP-COUNT and RSSI. The simulations were performed through the OMNeT ++ simulator [20]. The focus of the simulations and analysis performed is the creation and maintenance of downstream routing from the data-generating nodes to aggregator node, the sink node. Thus, only the strategy for the sharing of the DODAG Information Object (DIO) packets and the calculation of the descending rank is described and analyzed.
The simulations and subsequent studies are based on the acquisition of reference metric values to understand the level of quality and efficiency of the networks in question, such as energy consumption, packet delivery ratio, end-to-end delay and throughput. A second objective of the simulations is to provide a link quality assessment of the metrics within the scope of convergence time and the number of preferred parents. For the simulation, a hierarchical multi segment LSN is considered that consists of 9 segments as shown in Fig.1. Each segment contains number of sensor nodes placed uniformly and evenly at equal distance of 10 meters in a linear sequential manner along the segments. The sink is positioned at the edge of the pipeline. The nodes communicate in multi-hop fashion with a transmission range of 100m.

A. Increasing The Packet Size
In the first scenario, the default RPL parameters are used as shown in Table I. The performance is measured by varying the UDP packet size, starting at 40 byte and increased by 20 to a maximum 140 byte. To generate accurate results an average value of 10 runs with different seed values.  As shown in Fig. 2, RPL with RSSI metric has the worst performance in terms of power consumption while the ETX metric has least power consumption rate. The superiority of ETX can be attributed to the metric capacity in finding optimal routes towards the DODAG root thus lessen the number of retransmission needed to transmit a specific packet. In turn, this has resulted in less amount of energy expenditure. The same justification is applicable for the superiority of ETX in terms of PDR and throughput as depicted in Fig. 3 and Fig. 4 respectively. Fig. 5 shows that the hop-count metric has the best performance in terms average end-to-end delay. This can be explained by the fact that hop-count metric tends to select the path with fewer hops toward the root compared to RSSI and ETX. This resulted in packets being transmitted over shorter paths leading to minimizing the average delay. It is unsurprising that ETX gives the best overall results in terms of power consumption, PDR and throughput. However, this comes at the cost of increased delay due to the probing packets required to calculate the ETX metric.

B. DIO Minimum Interval
In the second scenario, the performance of the three routing metrics is evaluated against DIO Minimum interval. This is the minimum possible interval value in the original Trickle algorithm. The first set of comparison simulations involved varying the value of DIO Minimum value from 9 to 15.
These values determine the minimum interval length using, 2 Milliseconds (2) Where x is the chosen DIO Minimum value.  This scenario runs for 600s sending 60 byte of packets from source nodes to the sink.
Figs. 6, 7, 8 and 9 present comparisons between the Hop-Count, ETX and RSSI in terms of the average power consumption, End-to-End delay, average preferred parent change and convergence time in Seconds respectively as a function of the DIO minimum interval. It is clear from the figures that there is an inverse relationship between the minimum DIO interval and the power consumption while there is a direct relationship with the delay and the convergence time (i.e. the time at which the protocol has finished building the topology or restructured it). Indeed, the lesser is the minimum DIO interval, the higher is the energy consumption. This is due to that the protocol makes more DIO transmissions per time unit as the DIO interval gets smaller. More control overhead in the form of more DIOs transmissions will surly results in higher energy consumption rates. On the other hand, when the minimum DIO interval gets bigger, the time needed to constructed the topology and responding to topology changes is minimized and hence the low average delay and the faster convergence time. In general, a small DIO minimum interval results in a higher energy consumption but a lower delay/convergence time and vice versa. Therefore, there is a need to balance between both cases unless the particular context requires one or the other. For example, in the case of application that detects the problem in a pipeline, which may be essential to avoid some kind of disaster like a crack in the infrastructure. In such a case, the energy consumption is of less concern than the speed of the delivery. Thus, the application should opt to set the minimum DIO interval to the least possible value. Fig. 8 shows the average churn of the network with varying the minimum DIO interval between 9 and 15. The figure shows that, in general, the churn is not affected by the value of minim interval.

CONCLUSIONS AND FUTURE WORK
In this paper, the behaviors and performances of three routing metric for calculating the cost of downstream routing for the RPL protocol in a multi segment pipeline were evaluated. The study is conducted after the implementation of the RPL protocol in the OMNeT ++ simulator Framework. For the ETX, HOP-COUNT and RSSI metrics, two scenarios have been created by varying the size of packet in the network and the DIO minimum interval. The performance evaluation shows that the ETX metric, has the best performance in terms, of energy consumptions, PDR and throughput in both scenarios. It can be concluded that the ETX is the appropriate metric for applications that need high rates of success in delivering data packets, high reliability and low power. HOP-COUNT has shown adequate performance in most of the results obtained. It outperformed both ETX and RSSI in terms of delay showing significant delay reduction and faster convergence, and thus routing stability is provided. RSSI metric reveals poor results at all levels.