2015 IEEE International Conference on Computer and Information Technology; Ubiquitous Computing and Communications; Dependable, Autonomic and Secure Computing; Pervasive Intelligence and Computing
Equalizing Energy Distribution in Sensor Nodes through Optimization of RPL Juuso Nurmio∗ , Ethiopia Nigussie∗ and Christian Poellabauer†
∗ Department
of Information Technology, University of Turku, Finland Science and Engineering, University of Notre Dame, USA email:{jjjnur, ethnig}@utu.fi,
[email protected]
† Computer
Abstract—We present a nodes’ remaining energy-aware objective function in order to equalize the energy distribution among the nodes with the ultimate goal of extending the lifetime of the network. Routing Protocol for Low Power and Lossy Networks (RPL) is the routing standard for the Internet of Things. It chooses the optimal routes from a source to a destination node based on specific metrics. Since the nodes in such networks have limited energy resource, the dying of a node may result in the loss of part of the network or the entire network depending on the topology. The designed objective function uses both expected transmission count (ETX) and remaining energy of parent nodes to determine the preferred parent. Simulations are carried out using Contiki OS and its Cooja emulator. The simulation results reveal that the proposed objective function increases the lifetime of the first node to die in the network compared to Minimum Rank with Hysteresis Objective Function (MRHOF). It is also observed that the nodes’ energy depletion rate in the network, which uses the proposed nodes’ energy-aware objective function, is closer to each other than the one using MRHOF.
Rank with Hysteresis Objective Function (MRHOF). OF0 [8] uses hop count as routing metric meaning that the path with the least number of hops is used and parents are selected to satisfy this goal. MRHOF [9] utilizes the expected number of transmissions (ETX) in its routing metric; parents are selected so that the expected number of required transmissions will be the smallest possible. The use of other metrics or their combinations is left to designers. Due to resource constraints and reliability concerns, a routing metric that takes into account the quality of the links, while balancing the energy consumption for all flows is beneficial. ETX may take into account the link reliability to construct only energy-efficient routes. However, the use of ETX alone cannot optimize the network lifetime, since a small number of nodes with a high ETX and close to the border routers may have to forward most of the traffic. This leads to fast energy depletion and ultimately death of these nodes. In order to equalize the energy consumption rate, nodes with a large residual energy should be used as a next hop router instead of a lower energy one. In this work, two objective functions are developed. Both functions are formulated based on the ETX and remaining energy metrics of parent nodes. The difference between the two is the first one considers only one-hop parent nodes’ remaining energy whereas the second one takes into account the remaining energy of all nodes along the path to the sink. Thresholds of ETX and remaining energy difference between parents are defined. The threshold values are adaptive and designers can choose the optimal ones by considering appropriate parameters. A change in preferred parent is carried out if the difference is more than the threshold. The value of ETX is more influential for the parent selection process than remaining energy since transmission using bad/average links incurs transmission failure and retransmission costs which cause additional energy consumption.
I. I NTRODUCTION Internet-of-Things (IoT), where intelligent ”things” are interconnected to monitor and exchange information, has many applications. Most of its applications facilitate our daily activities, such as healthcare [1], [2], smart home and cities [3], [4], [5], and intelligent transport systems [6]. IoT can be envisioned as the interconnection of a wide range of application customized networks and wireless sensor network (WSN) is one of them. In WSN, wireless nodes exchange the sensed information with a base station, which collects and analyzes the received data. These nodes are mostly battery powered and have limited memory and computational capacity. Due to this, WSN protocols should be efficient in resource usage and management. Energy is a scarce resource in most WSN applications since charging of batteries is either inconvenient or even impossible and thus efficient usage is necessary to extend the lifetime of the network. Ideally, each node should consume the same (minimal) quantity of energy to improve the network lifetime. The RPL protocol is designed with the purpose of separating the packet processing and forwarding from the routing optimization goal. This enables formulation of different optimization techniques depending on the desired goal. A number of metrics can be incorporated in the Objective Function (OF) of the RPL protocol during the network topology formation phase [7]. The Internet Engineering Task Force (IETF) specified two kinds of OFs: Objective Function Zero (OF0) and Minimum 978-1-5090-0154-5/15 $31.00 © 2015 IEEE DOI 10.1109/CIT/IUCC/DASC/PICOM.2015.1
The paper is organized as follows. In Section II related RPL optimization works are presented. General introduction of RPL protocol and RPL implementation in ContikiOS (ContikiRPL) are discussed in Section III. The proposed OFs implementation details are presented in Section IV. The simulation environments and evaluation of simulation results of the proposed OFs along with MRHOF are discussed in Section VI and VII, respectively. Finally, conclusions are presented. 83
II. R ELATED W ORK
a node does not receive a DIO message within a certain time interval, it will send a DODAG Information Solicitation (DIS) message to solicit DIOs from neighboring nodes. After this, neighboring nodes send their DIO messages, thus allowing a node to join the DODAG. In somewhat dense networks a node can have more than one possible parent towards the root. The preferred parent selection process is governed by the objective function (OF). OF determines the best parent node based on routing metrics, links, node metrics, and other relevant information and which metrics to be used by the OF are customized by the designer. ContikiRPL implements the RPL protocol and two objective functions: OF0 and the MRHOF [18] in Contiki OS. The ContikiRPL implementation separates protocol logic, message construction and parsing, and objective functions into different modules. The protocol logic module manages DODAG information, maintains a set of candidate parents and their associated information, communicates with objective function modules, and validates RPL messages at a logical level according to the RPL specification. The message construction and parsing module translates between RPLs ICMPv6 message format and ContikiRPLs own abstract data structures. Finally, the objective function modules implement an objective function API. To facilitate simple replacement of and experimentation with objective functions, their internal operation is opaque to ContikiRPL. An external neighbor information module provides link cost estimation updates through a callback function. Within one second of such an update, ContikiRPL recomputes the path cost to the sink via the updated link, and checks with the selected objective function whether to switch the preferred parent. The link cost reflects the per-neighbor ETX metric, which is calculated using an exponentially-weighted moving average function over the number of link-layer transmissions with α = 0.2. The ETX is used to compute the rank for the MRHOF objective function and in parent selection for the OF0 objective function.
RPL chooses the optimal routes from a source to a destination node, based on specific metrics incorporated in the objective function. Various RPL optimizations using different metrics have been proposed with the goal of increasing network lifetime [10], [11], delay minimization [12], and improving packet delivery ratio [13]. In [10], remaining energy of a node has been used as a routing metric to select the next hop. Since the radio link quality is not included in the metric, a node with higher remaining energy but a bad link can be selected. This may cause more energy consumption and incur additional latency due to retransmissions. Selection of the preferred parent using first the hop count and then forwarding parent with the best link quality has been proposed by Hong and Choi [14]. But this approach may burden some nodes if these nodes have to forward most of the traffic, leading to faster energy depletion of the nodes. A routing metric that combines the residual energy and the ETX linearly has been presented in [15]. However, the weighting of the two metrics is not directly related to the real lifetime of a node, which leads to suboptimal solutions. Kamgueu et al. [16] proposed a metric by using a fuzzy inference system to combine the expected transmission count, delay, and remaining energy of the nodes. This optimization performs well for heavy traffic networks only, limiting the applicability of the approach. The objective function presented in this work uses both ETX and remaining energy of the nodes to choose the preferred parent. First the ETXs of the parents are compared. If the difference between the ETXs are below the threshold then the remaining energy of the parent nodes are checked and the one with higher energy reserve will be selected as the next hop. III. OVERVIEW OF RPL P ROTOCOL AND C ONTIKI RPL RPL [17] is an IPv6 routing protocol designed specifically for low power and lossy networks. It does not require any foreknowledge about the network topology except a root node has to be set up in advance. After initial start-up the root begins to probe the network and form a Destination-Oriented Directed Acyclic Graph (DODAG). DODAG is a tree-like structure that is rooted at the root node and every node except the root has at least one parent which acts as a relay towards the root. The DODAG root node often acts as a border router providing connection outwards from the WSN. DODAG maintains the topology information with available paths needed to route packets from leaves to root node. The DODAG tree is constructed so that no cycles exist and all edges are oriented towards the single root node. DODAG Information Object (DIO) is sent link-locally downwards from parents to possible child nodes and contains information about the DODAG, parents rank, and other relevant data so that a node can select its parent and join a DODAG. After initialization, DIOs are sent periodically to maintain the DODAG. Destination Advertisement Object (DAO) is sent upwards and contain information about destinations that are reachable via the node that sent a DAO message. This way a parent knows what nodes are located in the subtree rooted at the parent. If
IV. I MPLEMENTATION OF N ODES ’ E NERGY- AWARE RPL The main motivation for this work is to maximize the network’s lifetime by balancing the energy distribution among the nodes. The route decision is carried out by considering both ETX and the remaining energy of parents. The objective function of the RPL is optimized to include these two metrics with the aim of equalizing the energy distribution among the nodes. In this section, the design of the proposed objective function along with relevant issues are presented. A. Parent Energy Objective Function (PEOF) OF defines the routing metric to be used and how it is applied for rank calculation and preferred parent selection. The selection of a parent governs how DODAG is constructed, so OF plays a vital role in what kind of DODAG is formed. OF is separated from the RPL core standard so that different objective functions can be used more easily to adapt to different scenarios.
84
Fig. 1: Parent selection process in PEOF used to adjust which metric governs parent selection more, energy or ETX. By increasing mindif f of the ETX, energy becomes the more decisive factor in choosing the preferred parent whereas decreasing it allows ETX to be the key metric.
Unlike MRHOF, the designed objective function, PEOF, takes into account both ETX and remaining energy of parents. At times the first node to exhaust its battery may be a center routing node and its disappearance can render the remaining network ineffective and even practically useless. PEOF aims to delay this event by routing traffic via nodes with higher remaining energy. The first task is to design an algorithm that allows accurate estimation of the remaining energy in a node. Next this remaining energy estimation is inserted in the OF metric container. Finally the energy based parent selection is utilized in the objective function in a way that merges both remaining energy and ETX and then selects the preferred parent in a combination of these two metrics. In this work, two parent’s energy-aware OFs are developed: PEOF and PEOF2. Both OFs consider ETX and the remaining energy of parents. The difference is that PEOF considers only the remaining energy of one-hop parents while PEOF2 takes into account the remaining energy of all parents along the route up to the root before the preferred parent at each hop. In MRHOF, to change the preferred parent, the ETX of a new preferred parent has to differ significantly from the current one. The use of threshold, mindif f , prevents unnecessary continuous changes when ETXs of two candidate parents are close to each other. The same hysteresis is also used in the ETX part of PEOF. In addition, a similar threshold approach is used for the remaining energy part. The remaining energy levels of two parent nodes have to differ considerably before those nodes are considered different energy-wise. Even though PEOF uses both ETX and remaining energy as its metrics, ETX is emphasized. Preferred parent selection process happens by comparing two candidate parents and selecting the best one to continue to next pair comparison. When two nodes are compared the logic goes as follows. If both ETXs and energies are within their threshold, PEOF keeps the current preferred parent to prevent erratic oscillations. If this is not the case, the one with lower ETX is selected. If ETXs are within threshold but energy levels are not, the one with greater remaining energy gets selected. If ETXs are outside threshold, the node with lower ETX is always preferred regardless of remaining energies. Figure 1 visualizes this process. The mindif f of ETX part is one parameter which can be
B. Calculating Rank and Routing Metric As mentioned earlier, parent selection in PEOF uses both remaining energy and ETX. The ETX part of PEOF is identical to MRHOF, which incorporates ETX in rank. Because the remaining energy is carried separately in DIO metric container the rank calculation includes no remaining energy factors at all and therefore comes directly from MRHOF. Rank is an important part of RPL as it is used in maintaining the DODAG, for instance in loop detection. Its calculation method is discussed briefly here. In all its simplicity, rank of node i in MRHOF and consequently in PEOF is calculated as Ranki = Rankparent + ET Xparent , where ET Xparent represents the current ETX to the sink via current parent. A specific function neighbor_link_callback() in RPL objective function API receives link-layer neighbor information and updates ET Xparent as packets are sent based on successful and unsuccessful deliveries. As the network traffic situation changes and successful packet delivery ratio reflects this fluctuation, ET Xparent varies and thereby Ranki is constantly updated. In RPL, metric container of outgoing DIOs is updated periodically. Every time the function update_metric_container() in OF implementation is invoked, the remaining energy Eremaining is updated to the container so that it can be used in DIOs. The metric container in PEOF uses the Node Energy Object (NEO) to carry the remaining energy. The use of this metric container object type allows inclusion of Eremaining with ease in the estimated energy field. According to the standard [7], this field carries an 8 − bit unsigned integer representing the estimated energy of the DIO sender. NEO also has another interesting field called node type. This field reveals the energy type of a node. RF C6551 gives three energy source options: mains-powered, battery-powered, and scavenger. In the implementation of PEOF it is assumed that the sink is mains-powered and all other nodes as battery operated.
85
C. Potential Limitations
expressed in ampere-hours. Also, durations in different states and current consumptions in those states are easily obtainable from Energest and data sheets, respectively. Second, using ampere-hours does not require knowledge of voltages which may be difficult to obtain. Normally the equation for electrical energy would be E = U It, where U is supply voltage, I is current and t is time. Voltage U can be difficult to determine because it likely varies from device to device and it also drops as batteries are being used. However, assuming that in wireless sensor networks most nodes are identical with identical operating voltages, we can omit the voltage from equations and calculate energy as the product of current and time. This way calculations become simpler, but at the expense of not being able to compare true energy levels of two nodes of different voltages. By taking the above into account and by eliminating voltage, the mathematical formula for calculating used energy for each state is
One might assume that by smoothing differences in energies, the network should stay operational longer, but this may not be the case. Although the remaining energy distribution in nodes should stay more even than in MRHOF, there are two possible problems in PEOF: greedy energy optimization and not minimizing total power consumption. If a node tries to minimize its energy usage locally, this possibly causes extra power consumption in other parts of the network. Since PEOF take into account only the remaining energy of onehop parent, there is a possibility of burdening other nodes as a result of the local greedy decisions. In PEOF2 this problem is addressed because it considers the remaining energy of all parent nodes along the path (up to sink) and choose the route which maximizes the energy saving. The other consideration and possible drawback in the proposed OFs is the fact that while it evens energy consumption among nodes it may cause additional consumption at the same time. This happens due to choosing a longer route in order to avoid low energy nodes. V. N ODE ’ S E NERGY E STIMATION
Estate = Istate * tstate
In order to use the remaining energy of a node in the proposed OFs first a method for calculating the residual energy of a node has to be formulated. One simple method could be to make use of battery voltage to estimate state of charge. However, this is not an accurate enough method especially with modern Lithium-ion batteries which keep voltage roughly constant until the battery is empty. Another way to estimate remaining charge is to monitor current consumption over time and calculate the consumed energy E = U It where E is total energy used and U , I and t are voltage, current and time, respectively. If voltage or current are not kept constant under load, which is quite often the case with discharging batteries and varying power consumption integration is needed. Instead of estimating remaining charge, if instantaneous power P is known, energy can be calculated as E = P t. This method is employed for estimation of the remaining energy in the proposed OFs. In Contiki, a module called Energest (energy estimation) can be used to get information about how long a system has been in different states. Energest has many other states also, but the ones that are interesting for this work are transmit, listen, CPU, and LPM. Transmit and listen refer to radio transmitting and receiving, CPU when radio is off but system is otherwise active, and LPM stands for low power mode, which basically signifies sleep mode. In PEOF, remaining energy calculation is handled in a separate function which is scheduled to run automatically once every specific period. The function computes current residual energy and stores it in a global variable so that the energy is available to all other functions that need it. To be exact, using the term energy in PEOF is incorrect. In practice, the remaining energy is actually remaining electric charge and it is not measured in watt-seconds or joules, but in ampere-hours. This is mainly for two reasons. First, it brings simplicity to calculations since battery capacities are often
(1)
where I and t refer to current drawn and time spent in a particular state. Currents can be obtained from the data sheet of the nodes. It has to be remembered that currents in data sheets are nominal and they are not constant in practice but on average they should give accurate enough results. Energest module does not return state times directly in seconds but in timer ticks. To derive state times in seconds to be used in the above equation, ticks have to be divided by a constant RTIMER SECOND. This is a platform dependent constant and represents the amount of ticks per second on a specific platform. Times returned by Energest become quite large in relatively short amount of time because of the use of timer ticks. To prevent possible overflows due to limited number of bits in resource-constrained nodes, energy is calculated per every half an hour and added to a global variable as follows. Eused = EusedOld +EtransmitP +ElistenP +ECP U P +ELP M P (2) Metric container in ContikiRPL requires remaining energy to be 8 − bit in the scale of 0 − 255. For this the final remaining energy value which is stored in the global variable, is calculated as Eremaining = 255 − 255 ·
Eused BatteryCapacity
(3)
Capacity of the battery as well as current consumptions have to be included in the code before compiling using C definitions. There are a few issues with this kind of battery energy estimation. The limitation in this battery model is that it does not take into account the battery recovery effect. In batteries there are two phenomena happening: rate capacity effect and recovery effect [19]. The former occurs during
86
normal constant load when energy is used and the latter when load is non-existent or minimal. Because of battery chemistry, batteries recover some energy when they are not under load, thus increasing the battery lifetime. Not including the recovery effect will cause some error in remaining energy estimation. Another issue is nodes with different size of batteries. Nodes advertise their remaining energy proportional to their battery size in the scale of 0 − 255 and nodes select their preferred parent to be the one with the greatest advertised energy. Because of this, a node with lower absolute residual energy may be selected if its relative residual energy is higher than others. One implementation specific problem is the fact that Energest module is reset every time a node is reset. In other words, if a node is rebooted, state times returned by Energest are zeroed and so remaining energy will be calculated wrong as if the battery was suddenly full, even though some energy is already consumed. A possible solution for this could be to periodically write the consumed energy, Eused , to EEPROM. This way, it would be possible to read from EEPROM the already consumed energy before the last boot and add that to the used energy during the current boot. However, not all platforms have non-volatile memory such as EEPROM, so this solution would only work on some systems. Another implementation issue is that current consumptions and battery capacity have to be written directly to code before compilation and flashing to motes. From a practical point of view this may be laborious, but again, assuming that all or at least most motes are identical, this is acceptable. Also with numerous motes and different technical specifications, it might be difficult to include specifications of every possible mote to code. Even if this was a viable option, one would need an accurate way to identify on which platform the system is running to apply correct values. Especially battery specifications (mainly battery capacity) can be difficult or in some cases impossible to obtain at runtime. Some Lithium-ion batteries may be able to report their capacity, but for example with ordinary AA Alkaline batteries, the only way to have information about capacity is to manually include it in code.
Fig. 2: Dense symmetric network
loss. Simulations were run under these identical conditions using the same random seed and employing PEOF, PEOF2, and MRHOF as the RPL objective function. Simulations were run in Instant Contiki [20], a ready-made virtual machine consisting of a complete Contiki development environment using Contiki version 2.7. Cooja was set to emulate Tmote Sky nodes which use UDP over IP v6 in network communication. Outgoing IP v6 packets flow from the uIP v6 layer to the 6LoW P AN layer for header compression and fragmentation. The 6LoW P AN layer sends outgoing packets to the MAC layer. ContikiMAC with 8 Hz channel check rate is employed. ContikiMAC layer is a CSMA/CA mechanism that places outgoing packets in a queue. Packets from the queue are transmitted in order through the radio duty cycling (RDC) layer. The RDC layer in turn transmits the packets through the radio link layer. The MAC layer will retransmit packets until it sees a linklayer acknowledgment from the receiver. If a collision occurs, the MAC layer does a linear back-off and retransmits the packet. Outgoing packets have a configurable threshold for the maximum number of transmissions.
VI. S IMULATION To test the performance of PEOF and PEOF2, two simulation environments, shown in Figures 2 and 3 were created in Cooja. One of the networks, shown in Figure 2, is a dense symmetric network consisting of 56 sensor nodes and a sink node (number 1 in the figure). The other network (Figure 3) is asymmetric and is made up of one sink and 34 sensor nodes. The reason for simulating two types of networks is to check the performance of the developed OFs in symmetric and asymmetric networks. In the dense symmetric network, the nodes were positioned 40 meters apart in a plane grid. The transmit and interference ranges of all nodes in this network were set to 75 and 95 meters, respectively. In the asymmetric network 75 and 85 meters were set for transmit and interference ranges, respectively. The simulated radio medium was Unit Disk Graph Medium (UDGM) with distance
The nodes in both dense symmetric and asymmetric networks started with 40mAh batteries. These battery capacity is far too low capacity for any real WSN deployment, but this is chosen to speed up simulations. Since normal MRHOF implementation does not include remaining energy monitoring and to make the results of the two simulations comparable, the exact same energy estimation method as in PEOF and PEOF2 was added to MRHOF. Otherwise the MRHOF used in this experiment was identical to the objective function in standard ContikiRPL. Payload traffic consisted of periodic hello packets sent by all nodes to sink. Client nodes print the number of sent packets and server nodes print the total number of received packets to the mote output.
87
70
MRHOF PEOF
60
PEOF2
Remaining energy (%)
50
40
30
20
10
0 2
4
6
8
10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56
Nodes
Fig. 4: Remaining energy of nodes at 23.5 hours in the high data rate dense symmetric network among the nodes. The threshold used in PEOF and PEOF2 to determine how much the energy levels of the two candidate parents have to differ in order to consider either one better energy-wise is 5 (scale 0-255). This threshold, together with the dense topology may cause nodes to switch parents quickly enough so that energy levels remain similar and depletion curves, like the ones in the Figure 5, show no significant changes in slopes. All one-hop neighbors run-out of energy after 35.5, 33 and 32.5 hours for MRHOF, PEOF and PEOF2, respectively. As we discussed in Section V, the use of the proposed two OFs does not save the overall network energy, but enable more equalized use of energy. So if we delay the death of the first node in the group of one-hop neighbors, we advance the death of the last node in this same group. Which one is better depends on the application requirement. In the dense and symmetric topology, loss of one node probably does not cause major problems for the operation of the network. However, in cases where there are vital bridge nodes, which route traffic of a network segment, loss of these nodes may render parts of the network unreachable completely. Therefore prolonging the lifetime of these nodes is critical for network as a whole. In WSNs, reliability is as important as energy saving, so the packet delivery ratio was also studied. Since MRHOF tries to minimize the amount of transmissions by using routes with fewer hops and with better delivery rate links, its delivery ratio should be good. After all, the smaller the number of transmissions over unreliable links, the lower the chance of packets getting lost. Though MRHOF provided a slightly longer network lifetime than PEOF and PEOF2, its average packet delivery ratio is not higher than the developed OFs. The average packet delivery ratio in the network using MRHOF was 98.2%, while the ratio of PEOF and PEOF2 was the same 97.5% and 97.7%, respectively. The average packet delivery ratio of the developed OFs are slightly less than MRHOF. However, the differences are practically insignificant and in the sense of packet delivery reliability in this network all OFs perform equal. 2) Low Data Rate Transmission: The performance of the OFs are also analyzed for a low data rate of 0.5 packets per minute in the dense symmetric network. The first node to
Fig. 3: Sparse asymmetric network VII. S IMULATION R ESULTS A NALYSIS Initially simulations were run until one of the nodes exhausted its battery in any of the OFs (MRHOF, PEOF or PEOF2) and relevant results are compared. Since Cooja does not actually simulate batteries, in simulations the nodes would continue to run indefinitely even if they are out of battery. To tackle this issue, a code is included that switch of node’s radio automatically when a node exhaust its energy. Once its radio is off, a node neither able to transmit nor receive. This allows to emulate real world scenario. A. Dense Symmetric Network To evaluate the performance of PEOF and PEOF2 in dense symmetric network for both high and low data rate transmissions, simulations were run for 6 and 0.5 packets per minute transmissions. The results are analyzed for both cases as follows. 1) High Data Rate Transmission: The packet rate was set to 6 packets per minute in the simulation. The simulation of dense symmetric network results revealed that PEOF and PEOF2 extended the lifetime of the first node to run out of energy in the network. These results are shown in Figure 4, where the percentage of the remaining energy levels of each node are visualized. In MRHOF node 4 and 6 were the first nodes to deplete their battery after 23.5 hours. At this time in PEOF and PEOF2 the lowest remaining energy node is node 6 and had 14.9% and 22.7% remaining energy, respectively. The first eight nodes (node IDs 2-9) deserve special attention as they are the one-hop neighbors of the sink. These nodes route traffic of the whole network segments and loss of these nodes may cause parts of the network to be unreachable. At the very least, losing one of these nodes shifts a lot of traffic to other one-hop neighbors of the sink, causing additional burden to them. Energy depletion rates of one-hop nodes are plotted in Figure 5. In case of PEOF2, energy depletion happens quite evenly for almost all one-hop nodes evidenced by the linear slope of the curves. Whereas in MRHOF, the rate among nodes varies considerably, showing the unevenly energy consumption
88
3
80
4 60
5 6
40
7 8
20
9 0
5
10
15
20
25
30
3 4
60
5 6
40
7 8
20
9
0
0
35
0
5
10
15
Time (h)
20
25
100
2
PEOF, nodes 2-9
80
30
35
Remaining energy (%)
100
2
MRHOF, nodes 2-9
Remaining energy (%)
Remaining energy (%)
100
2
PEOF2, nodes 2-9
3
80
4 5
60
6 40
7
8
20
9
0
0
5
10
15
20
25
30
35
Time (h)
Time (h)
Fig. 5: Energy depletion rate of one-hop neighbor nodes to the sink in high data rate dense symmetric network 35
80
MRHOF PEOF 30
70
PEOF2
PEOF PEOF2
60
Remaining energy (%)
25
Remaining energy (%)
MRHOF
20
15
50 40 30
10
20 5
10
0 2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
32
34
36
38
40
42
44
46
48
50
52
54
0
56
Node
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
Node
Fig. 6: Remaining energy of nodes at 61 hours in the low data rate dense symmetric network
Fig. 8: Remaining energy of nodes at 15.5 hours in a high data rate sparse asymmetric network
exhaust its battery is node 2 in MRHOF after 61 hours. The remaining energy of the nodes at 61 hours (when the first node dies in MRHOF) is shown in Figure 6. In PEOF and PEOF2, the first node to run out of energy are 2 and 23 after 64 and 67 hours, respectively. The last one-hop neighbor of the sink to run out of energy is node 3 in MRHOF. Whereas in PEOF nodes 3 and 7 are the ones that die at last after 76.5 hours of service. In PEOF2 node 9 is the longest serving one-hop neighbor of the sink. The energy depletion rates of the onehop neighbors to sink is shown in Figure 7. The depletion rates (slope of the graph) are more similar in PEOF2 than in MRHOF showing the energy equalizing capacity of PEOF. In another note, the energy depletion rate of the one-hop neighbors of the sink is more linear than in the high traffic case. This is due to the fact that the DODAG maintenance traffic is comparable with the low data traffic.
first node to run out of energy in the network. These results are shown in Figure 8, where the percentage of the remaining energy levels of each node are presented. Node 2 was the first node in MRHOF to deplete its battery after 15.5 hours. At this time. in PEOF and PEOF2, node 27 is the one with the lowest remaining energy and had 9.4% and 11.8% percent remaining energy, respectively. The four one-hop neighbors of the sink node (2, 3, 4, and 27) deserve special attention. Since they are one hop away from the sink they route traffic of whole network segments and loss of these nodes may cause parts of the network to become unreachable. For example, if node 27 or 2 run out of battery (since 27 can reach the sink only via node 2), the data sensed by nodes 28 − 35 cannot be reached by the sink. In other cases, the loss of these nodes burdens the other one-hop neighbor due to the increase in rerouted traffic. As in dense symmetric network, the energy depletion rate of one-hop nodes of sparse asymmetric network are also analyzed. The rates of energy usage of one-hop to sink nodes are plotted in Figure 9. PEOF and PEOF2 energy depletion happens quite evenly compared to MRHOF for all one-hop nodes, except node 4 as can be seen from the linearity and closeness of the curves. The first node to run out of energy in PEOF and PEOF2 is node 27 and this happens at 17.5 hours where as in MRHOF it is node 2 which dies at 15.5 hours. The last node to die in all OFs is node 4. The analysis of packet delivery ratio showed that PEOF2 extended the lifetime of the separate cluster of nodes 27 − 35.
B. Sparse Asymmetric Network In order to check the performance of PEOF and PEOF2 in high and low data rate transmissions, simulations were run for 6 and 0.5 packets per minute transmissions. The results are analyzed for both cases as follows. 1) High Data Rate Transmission: The simulation results discussed here are for 6 packets per minute data transmission rate in the asymmetric network. The three OFs (MRHOF, PEOF and PEOF2) are employed and simulated in an asymmetric network (shown in Figure 3). The simulation results revealed that PEOF and PEOF2 extended the lifetime of the
89
2
80
3 4
60
5 6
40
7
8
20
9
100
PEOF, nodes 2-9
2
80
Remaining energy (%)
100
MRHOF, nodes 2-9
Remaining energy (%)
Remaining energy (%)
100
3 4
60
5 6
40
7 8
20
9
0
0 0
10
20
30
40
50
60
70
0
80
10
20
30
40
50
60
70
3 4
60
5 6
40
7 8
20
9
0
80
0
10
20
30
Time (h)
Time (h)
2
PEOF2, nodes 2-9 80
40
50
60
70
80
Time (h)
Fig. 7: Depletion rates of one-hop neighbors to the sink in low data rate dense symmetric network
2 3 4 27
2
4
6
8
10 12 14 16 18 20 22 24
100 90 80 70 60 50 40 30 20 10 0
2 3 4 27
0
2
4
6
8 10 12 14 16 18 20 22 24
Time (h)
Remaining energy (%)
100 90 80 70 60 50 40 30 20 10 0 0
PEOF2, nodes (2, 3, 4, 27)
PEOF, nodes (2, 3, 4, 27)
Remaining energy (%)
Remaining energy (%)
MRHOF, nodes (2, 3, 4, 27)
100 90 80 70 60 50 40 30 20 10 0
2
3 4 27
0
2
4
6
8
10 12 14 16 18 20 22 24 Time (h)
Time (h)
Fig. 9: Energy depletion rates of one-hop neighbors to the sink in a high data rate sparse asymmetric network
MRHOF
PEOF
90
PEOF
30
PEOF2
80
PEOF2
70
25
Remaining energy (%)
Delivery ratio (%)
35
MRHOF
100
60 50
40 30 20
20
15
10
10 5
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
9
8
10
7
6
5
4
3
2
1
0
0
Time (h) 0 2
Fig. 10: Packet delivery ratio in a high data rate sparse asymmetric network
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
Node
Fig. 11: Remaining energy of nodes at 61 hours in low data rate sparse asymmetric network
Due to this, the network as a whole dies faster. MRHOF, on the other hand, drops the cluster sooner, but other parts of the network stay reachable longer. The packet delivery ratios of MRHOF, PEOF and PEOF2 are shown in Figure 10. The delivery ratio of MRHOF dropped from 97.6 at 16 hours to 69.9% at 16.5 hours. It sustains around 70% delivery ratio until 21 hours and after this period the network is not functional. Both PEOF and PEOF2 maintains above 97.5% packet delivery ratio until 17.5 hours. Although node 4 was technically within the communication range of the sink, it did not route as many packets as the other one-hop neighbors. In all cases, when nodes 2 and 3 exhausted their energy, the packet delivery ratio dropped practically to zero. 2) Low Data Rate Transmission: The performance of the OFs are also analyzed for a data rate of 0.5 packets per minute in the asymmetric network. The first node to exhaust its battery is node 2 in MRHOF after 61 hours and node 27 in both PEOF
and PEOF2 after 61.5 and 63.5 hours, respectively. The last one-hop neighbor of the sink to run out of energy is node 4 in MRHOF and node 3 in both PEOF and PEOF2 as can be seen in Figure 12. It happens at 69, 68, and 47.5 hours for MRHOF, PEOF, and PEOF2, respectively. The energy depletion rate of the one-hop neighbors of the sink is more linear than in the high traffic case. This is due to the fact that the DODAG maintenance traffic is more pronounced than the low data traffic. VIII. D ISCUSSION For the developed OFs, PEOF and PEOF2, performance has been evaluated in dense symmetric and sparse asymmetric networks using both high and low data rate transmissions. The simulation results revealed that these two OFs increased the
90
4 27
5 10 15 20 25 30 35 40 45 50 55 60 65 Time (h)
100 90 80 70 60 50 40 30 20 10 0
2 3 4 27
0
5 10 15 20 25 30 35 40 45 50 55 60 65
Remaining energy (%)
3
Remaining energy (%)
Remaining energy (%)
2
0
PEOF2, nodes (2, 3, 4, 27)
PEOF, nodes (2, 3, 4, 27)
MRHOF, nodes (2, 3, 4, 27) 100 90 80 70 60 50 40 30 20 10 0
100 90 80 70 60 50 40 30 20 10 0
2 3 4 27
0
5
10 15 20 25 30 35 40 45 50 55 60 65 Time (h)
Time (h)
Fig. 12: Energy depletion rates of one-hop neighbor nodes to the sink in a low data rate sparse asymmetric network lifetime of the first node to die in the network compared to MRHOF in all cases. In majority of cases, PEOF2 achieved a couple of hours longer lifetime than PEOF. The reason for this is that PEOF2 takes into account the energy of all parent nodes along the path up to the sink before choosing the preferred parent at each hop. In addition, PEOF and especially PEOF2 equalized the energy consumption rate among the nodes as can be seen from the energy depletion rate curves. These two OFs do not save energy instead equalize the energy distribution among nodes and due to this the whole network dies faster when using PEOF/PEOF2 than using MRHOF. In PEOF/PEOF2, network starts to die later, but when it starts to die, it shuts down faster but in MRHOF the process is opposite. The depletion curves in low data rate are more linear than in high data rates for both type of networks. The reason for this is that the DODAG maintenance traffic dominates compared to the data packet traffic and this evens out the difference. As a side note, in real implementation cases, a more accurate energy estimation method has to be employed.
[2] [3] [4] [5] [6] [7] [8] [9] [10]
IX. C ONCLUSION We have developed two objective functions (PEOF and PEOF2) for RPL, which take into account ETX and remaining energy of the parent nodes in order to decide the preferred parent. The difference is that PEOF2 considers the remaining energy of all parents along the path up to the sink and ETX to decide the preferred parent at each hop. Whereas in PEOF only one-hop parent nodes energy and ETX are compared. PEOF and PEOF2 extended the lifetime of the first node to die in both dense symmetric and sparse asymmetric networks for 0.5 and 6 packets per minute data transmissions compared to MRHOF. In dense symmetric network with 6 packets per minute transmission, PEOF2 provided 11% and 30% more lifetime for the first node to die than PEOF and MRHOF, respectively. In addition, PEOF and PEOF2 equalized the energy consumption rate among the nodes, especially for the one-hop neighbors of the sink. This enables the collection of data from all parts of the network for longer periods of time. The packet delivery ratio when using PEOF and PEOF2 was equivalent to MRHOF for all cases. Therefore, PEOF2 is a potential candidate for applications that require keeping most of the nodes alive for a longer period.
[11] [12]
[13]
[14] [15]
[16] [17] [18]
[19]
R EFERENCES
[20]
[1] V. M. Rohokale, N. R. Prasad, and R. Prasad, “A cooperative internet of things (iot) for rural healthcare monitoring and control,” in Wire-
91
less Communication, Vehicular Technology, Information Theory and Aerospace & Electronic Systems Technology (Wireless VITAE), 2011 2nd International Conference on. IEEE, 2011, pp. 1–6. Y. J. Fan, Y. H. Yin, L. Da Xu, Y. Zeng, and F. Wu, “Iot-based smart rehabilitation system,” Industrial Informatics, IEEE Transactions on, vol. 10, no. 2, pp. 1568–1577, 2014. B. Li and J. Yu, “Research and application on the smart home based on component technologies and internet of things,” Procedia Engineering, vol. 15, pp. 2087–2092, 2011. S. D. T. Kelly, N. K. Suryadevara, and S. C. Mukhopadhyay, “Towards the implementation of iot for environmental condition monitoring in homes,” Sensors Journal, IEEE, vol. 13, no. 10, pp. 3846–3853, 2013. A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi, “Internet of things for smart cities,” Internet of Things Journal, IEEE, vol. 1, no. 1, pp. 22–32, 2014. Z. Yang, X. Wang, and H. Sun, “Study on urban its architecture based on the internet of things,” in LTLGB 2012. Springer, 2013, pp. 139–143. J.-P. Vasseur, M. Kim, K. Pister, N. Dejean, and D. Barthel, “Routing metrics used for path calculation in low-power and lossy networks,” Tech. Rep., 2012. P. Thubert, “Objective function zero for the routing protocol for lowpower and lossy networks (rpl),” 2012. O. Gnawali, “The minimum rank with hysteresis objective function,” 2012. P. O. Kamgueu, E. Nataf, T. D. Ndi´e, and O. Festor, “Energy-based routing metric for rpl,” Research Report RR-8208, INRIA, 2013. O. Iova, F. Theoleyre, and T. Noel, “Using multiparent routing in rpl to increase the stability and the lifetime of the network,” Ad Hoc Networks, vol. 29, pp. 45–62, 2015. P. Gonizzi, R. Monica, and G. Ferrari, “Design and evaluation of a delayefficient rpl routing metric,” in Wireless Communications and Mobile Computing Conference (IWCMC), 2013 9th International. IEEE, 2013, pp. 1573–1577. W. Xiao, J. Liu, N. Jiang, and H. Shi, “An optimization of the object function for routing protocol of low-power and lossy networks,” in Systems and Informatics (ICSAI), 2014 2nd International Conference on. IEEE, 2014, pp. 515–519. K.-S. Hong and L. Choi, “Dag-based multipath routing for mobile sensor networks,” in ICT Convergence (ICTC), 2011 International Conference on. IEEE, 2011, pp. 261–266. L.-H. Chang, T.-H. Lee, S.-J. Chen, and C.-Y. Liao, “Energy-efficient oriented routing algorithm in wireless sensor networks,” in Systems, Man, and Cybernetics (SMC), 2013 IEEE International Conference on. IEEE, 2013, pp. 3813–3818. P. O. Kamgueu, E. Nataf, T. Djotio, and O. Festor, “Fuzzy-based routing metrics combination for rpl,” Doctoral Consortium Sensornets, INRIA, 2014. T. Winter, “Rpl: Ipv6 routing protocol for low-power and lossy networks,” 2012. N. Tsiftes, J. Eriksson, and A. Dunkels, “Low-power wireless ipv6 routing with contikirpl,” in Proceedings of the 9th ACM/IEEE International Conference on Information Processing in Sensor Networks. ACM, 2010, pp. 406–407. E. Nataf and O. Festor, “Accurate online estimation of battery lifetime for wireless sensors network,” in SENSORNETS-2nd International conference on sensor networks. SCITEPRESS, 2013. Contiki: The open source operating system for the internet of things. [Online]. Available: http://www.contiki-os.org/
