RPL Cross-Layer Scheme for IEEE 802.15.4 IoT Devices With Adjustable Transmit Power

We propose a novel cross-layer scheme to reduce energy consumption in wireless sensor networks composed of IEEE 802.15.4 IoT devices with adjustable transmit power. Our approach is based on the IETF’s Routing Protocol for Low power and lossy networks (RPL). Nodes discover neighbors and keep fresh link statistics for each available transmit power level. Using the product of ETX and local transmit power level as a single metric, each node selects both the parent that minimizes the energy for packet transmission along the path to the root and the optimal local transmit power to be used. We have implemented our cross-layer scheme in NG-Contiki using the Z1 mote and two transmit power levels (55mW and 31mW). Simulations of a network of 15 motes show that (on average) 66% of nodes selected the low-power setting in a 25m $\times25\text{m}$ area. As a result, we obtained an average reduction of 25% of the energy spent on transmission and reception of packets compared to the standard RPL settings where all nodes use the same transmit power level. In large scenarios (e.g., 150m $\times150\text{m}$ and 40–100 motes), our approach provides better results in dense networks where reducing the transmit power of nodes does not translate into longer paths to the root nor degraded quality of service.


I. INTRODUCTION
The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [1], [2] is the IETF standard for routing in the Internet of Things (IoT) widely used in wireless sensor networks. This routing protocol provides a baseline architecture to deal with constrained-resource nodes that communicate using short-ranged noisy links with high variability of data loss, which is a challenging endeavor [3]. Among the design requirements for RPL is to be fit for low-end battery-powered devices severely constrained in memory and processing capabilities. The need to limit battery replacement sets a lifetime goal of several years. As such, energy efficiency becomes a crucial restriction to be carefully considered [4], [5].
This work seeks to improve energy efficiency in IEEE 802.15.4 wireless sensor networks (IETF's choice for IoT), which is not new. RPL already counts with several enhancements geared toward improving energy efficiency, including load balancing [6], [7], multi-path [8], [9], and all sorts The associate editor coordinating the review of this manuscript and approving it for publication was Rakesh Matam . of combined metrics, which usually include a link-quality metric such as the Expected Transmission Count (ETX) [4], [10] plus some energy-related term (e.g., typically node's residual energy) [11], [12]. However, despite the intense research effort, improving energy efficiency persists as a challenge [3], [11], [13]. In the authors' view, two aspects contribute to the complexity of this problem. First, energy efficiency optimization is a broad term that can refer to different goals such as maximizing the overall energy consumed by the network or maximizing nodes' residual energy (i.e., network lifetime) [4], [12], and optimizing one may prevent the optimization of the other. For instance, minimizing the total energy consumed by the network may result in an optimal path in which nodes with high delivery rate drain their battery faster than the rest and, consequently, it fails to attain the maximum possible network lifetime. Second, and following the previous example, there is usually a trade-off between optimizing energy and quality of service (QoS). In order to deal with conflicting requirements in the same application, authors typically suggest the use of composite routing metrics [14]- [16]. VOLUME 9, 2021 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ In this paper, however, we do not set the focus exclusively on the routing function but also on the transmit power setting of nodes. In a typical deployment, all nodes operate with a fixed transmit power setting. This assumption is habitually made in the existing literature, even though it is not uncommon that sensor nodes can use different transmission power levels. For example, the CC2420 transceiver used by the Crossbow TelosB and Zolertia Z1 motes counts with eight different power levels ranging from −25 to 0 dBm, the TI CC1200 transceiver used by Zolertia Re-Mote counts with 31 different power levels ranging from −16 to 14 dBm (in steps of 1dBm).
Having various levels of transmit power brings up a new degree of freedom to the routing problem. The transmit power impacts node's range (i.e., ability to be seen as a neighbor) and link statistics (e.g., RSSI and ETX observed by neighbors), thereby influencing the routing topology created. We leverage this fact to propose a cross-layer mechanism that operates in three layers: network, data-link, and physical. Nodes maintain fresh link statistics for the set of neighbors discovered with each available transmit power level and self-adjust their transmit power according to the parent chosen by the routing function. We use a routing objective function that minimizes the cumulative value of the one-hop product of ETXs and transmit power of nodes along the upward route from the node to the sink. This single metric compares favorably with the default use of ETX as it encompasses both reliability and transmission energy in the path. But, as a single metric, it inherits its limitations (e.g., it does not maximize the network lifetime). Still, our cross-layer scheme could be easily adapted to other single or composite metrics, such as those suggested in [14], [17], which is left for further work.
Contribution: The contributions of this work are: • We extend RPL's parent selection procedure to the multi-level transmit power scenario.
• We propose a cross-layer approach that dynamically adapts the sensors' transmit power to reduce energy expenditure in the network without impairing QoS.
• Via simulation, we show the benefits of our scheme and analyze the circumstances in which our method is most advantageous.
Observe that our approach can also be used in heterogeneous networks (i.e., a mix of nodes that exhibit different transmit power) even though multi-level transmit power was not featured.
The remainder of this paper is as follows. Section II provides the differences between our work and other cross-layer algorithms for improving energy efficiency in our context. Section III provides a brief overview of the basics of RPL. Section IV describes our proposal, the objective function used and the cross-layer operation. Section V describes the simulation environment created to validate our contribution using Cooja. Simulation results are provided and discussed in Section VI. Section VII highlights the limitation of this work, and Section VIII concludes the paper and points to further research for continuation.

II. RELATED WORKS
Cross-layer schemes between the network and the physical layer are not novel. In the wireless network literature, some authors have proposed a joint approach to routing and data rate adaptation [18], [19] where the TX rate is adjusted to minimize energy consumption combined with routing metric. This interesting cross-layer approach addresses the trade-off between route quality and energy consumption via packet service duration. Still, rate adaptation schemes are only feasible in multi-rate wireless technologies such as IEEE 802.11, which fall out of the scope of this work. The standard IEEE 802.15.4 was originally designed for low-power low-rate WSN that produce small-sized packets and operate with a single data rate fixed at 250 kb/s in the 2.4 GHz ISM band (though variants suited to regional regulations or specific applications have been also defined [20]). And although some authors have prospectively explored dynamic link rate adaptation schemes [21], this is not supported by the IEEE 802.15.4 standard. In our work, we choose transmit power instead of data-rate as physical-layer control variable.
A network-mac cross-layer mechanism, named RPL-SCSP was proposed in [22] which combines the ETX and Queue Load to optimize both end-to-end delay and the energy, but it differs from our proposal as it is aimed at providing the network with QoS support and the transmit power of nodes is ignored. More recently, Safaei et al. have proposed ELITE [23] a cross-layer scheme that operates at the link layer and RPL by using a routing metric that accounts for information about the radio duty cycle. This scheme achieves a significant energy reduction, but it is restricted to the radio duty cycling protocol ContikiMAC and, like the previous one, it fails to consider nodes with different levels of transmit power.
Autonomous adjustment of node's transmit power has been proposed by Chipara et al. [24]. The authors proposed to dynamically adapt the sensors' transmit power to reduce delay in real-time communications. Packets that do not have an urgent deadline are transmitted with lower power to reduce energy consumption. However, this work is different from ours in the following aspects: (a) it creates a new routing protocol rather than using standard RPL, (b) the criterion used to set the node's transmit power level is related to delay and not to energy, (c) it requires to have prior knowledge of the nodes layout and the application-layer traffic pattern. Finally, in [25], Rukpakavong et al. pursued, as we do, automatic configuration of nodes' transmit power employing modifications of RPL. However, their work differs from ours in several aspects. First, they only consider link statistics for the maximum transmit power while we keep link statistics for every available transmit power level. Secondly, in their work, RPL selects the best path based solely on ETX, ignoring the transmission power of nodes. As such, the optimal path is identical to that of mf0. Once the topology is set, each node self-adjusts its transmit power using the received signal strength from the parent's DIOs messages. So it is not a cross-layer scheme as the routing objective function is independent and unaware of nodes' transmit power. In our work, however, the routing metric is aware of both ETX and the node's transmit power (which could lead to routing solutions different from that of mf0), and it is the routing function that chooses the optimal local transmit power for the node.
To the best of our knowledge, our approach is completely original as in the literature is overwhelmingly assumed that nodes operate at a fixed default transmit power level, and the few works that pursue autonomous adaptation of transmit power differ from ours in the aspects mentioned above.

III. OVERVIEW OF RPL
RPL is a routing protocol that creates a topology using a destination-oriented directed acyclic graph (DODAG) typically oriented towards a sink, border router, or simply put, root node. Although RPL supports dual traffic pattern (i.e., from the root to the devices), this work is focused on multipoint-to-point communication where sensor nodes (motes) send data packets to the root node.
RPL uses control packets called DODAG Information Objects (DIO) so that nodes discover the links that exist between them (i.e., neighbors) and select a preferred one (parent) for forwarding data packets upwards toward the root, hence creating a routing topology. The content of DIOs includes a rank that indicates the relative position of every node with respect to the root and a routing policy in the form of objective function (OF) that specifies how the rank is calculated and how a node selects its preferred parent among its neighbors. For route maintenance, DIOs are broadcasted by nodes according to the Trickle timer [26] that offers a tradeoff between reactivity to topology changes and energy efficiency. As such, DIOs are advertised more frequently when the network is unstable, and instead rebroadcast at an increasingly slow pace while the network is stable.
The RPL standard [1] requires the use of a common OF by all network nodes, but it does not include any OF definition. Thus, nodes running RPL can employ user-defined metrics to describe the properties of a link or node (e.g., link quality, residual energy) and make these metrics available for route selection in DIO messages with a Metric Container sub-option at the choice of the implementer. The IETF, however, have defined (in separate standards) two types of objective functions for use with RPL [27]: (a) Objective function zero (OF0) [28], in which a node selects the parent that provides the shortest path to the root, which is calculated by adding a positive scalar that represents link properties (typically the hop count or the ETX) to the rank received from the neighbor. OF0 is designed as default OF allowing interoperation between implementations in a broad spectrum of use cases.
(b) Minimum Rank Hysteresis OF (MRHOF) [29] that selects routes that minimize a metric but prioritizes stability by using hysteresis to reduce change the preferred parents in response to small metric changes.
In the absence of a metric in the DIO Metric Container, MRHOF defaults to using ETX to compute rank, allowing RPL to find the stable minimum-ETX paths from the nodes to the root. The separation of OF from the core protocol specification allows RPL to be adapted to meet the different optimization criteria required by the wide range of deployments, applications, and network designs. Indeed, there is a plethora of metrics and objective functions proposed in the literature to overcome the natural limitations of RPL and the interested reader is referred to [12] and [11]. Kindly note that our goal is not to compete with these metrics. Indeed, our cross-layer mechanism can be easily adapted to other metrics suggested in the literature.

A. RPL PROBING
During DODAG formation, ETX is typically initiated using the RSSI observed during packet reception. But after joining the DODAG, nodes update ETX according to retransmissions (i.e., transmission attempts until ACK is received). This implies that only the ETX with the preferred parent is refreshed, and in the absence of regular traffic, adjacencies could not be tested and repaired if broken. For this reason, some RPL implementations (such as Contiki) allow probing adjacencies by sending periodically unicast DIOs to every RPL neighbor with outdated statistics. Probing also impacts the objective function as outdated neighbors are not eligible to be preferred parent [30], [31]. The periodicity of probing is implementation-dependent, but the node is expected to invoke probing only then there is no data traffic after a certain period (e.g., between 45 and 135 secs in Contiki-NG) or there is no data-link layer feedback. In this work, probing has been enabled.

IV. DESCRIPTION OF THE PROPOSED SCHEME
The rationale behind our cross-layer scheme is based on the idea that nodes' transmit power and RPL's preferred parent election are not independent. Indeed: • The transmit power impacts the set of reachable neighbors, or equivalently, the set of eligible RPL parents. Figure 1 illustrates this fact by showing the set of neighbors discovered by node 4 as a result of its transmit power level (four neighbors with maximum power level and three neighbors with the minimum).
• The transmit power of a node may impact the ETX observed by receptors. So, indirectly, the transmit power may also impact the preferred parent selection in OFs that include link-quality metrics such as ETX. In general, low-power settings may save energy but may degrade QoS (e.g., more retransmissions, connectivity loss, longer paths), which might increase energy consumption. As such, it is not clear whether high or low transmit power will be the most beneficial as it all depends on the prevailing network conditions and nodes' layout. This trade-off between the power settings at the physical and network layers is the bolts and nuts of our proposal.

A. OVERVIEW
Our cross-layer mechanism operates in three layers: network, data-link, and physical as illustrated in Figure 2. At the physical level, we assume that nodes have a predefined set of transmit power levels i = 1, 2, 3, .., N . The physical layer provides data services using the PHY data (PD) service access point (SAP), while the management services are provided using the PHY layer management entity (PLME) SAP. The mac sublayer maintains link quality statistics for every neighbor (i.e., mac address) discovered. In our scheme, the mac sublayer will keep N values of ETX for every neighbor (i.e., ETX(i), i = 1 . . . N) since nodes have N available transmit power levels.
When a DIO is received from a neighbor n, it is handed to RPL (along with the set of ETX(i) values associated with the link). Then, we calculate the optimal transmit power level associated with the DIO sender by computing the lowest expected transmission energy expenditure for the link with node n (i.e., min i {ETX (i)·PTX (i)}, where PTX(i) is the actual transmit power for level i). Let us name this value as the best TX power level (BPTX) for neighbor n.
Then, the DIO is processed and the rank of neighbor n is updated by adding the previous lowest expected transmission energy expenditure (i.e., local link metric) to the value received in the DIO metric container (MC).
Finally, the lowest-ranked neighbor is chosen as the preferred parent. Once a preferred parent is chosen, the node's forwarding table is updated accordingly, and our cross-layer algorithm instructs the PHY layer 1 to use the BPTX level associated with the preferred parent for the transmission of upper-layer data packets. Figure 3 shows the concerned layers of the IoT protocol stack and the supporting tables maintained by each layer when only two levels of transmit power are considered: high (H) and low (L). Observe that node 1 would be elected as preferred parent and the BPTX for that node would be H.

B. MAINTAINING LINK STATISTICS FOR VARIOUS POWER LEVELS
This section expands on how link statistics are collected and maintained for every neighbor and transmit power level available. As with the previous example, and for the sake of simplicity, we will only consider two levels of transmit power for the remainder of this paper: high (H) and low (L). The extension to more levels is straightforward.

1) ENABLERS
Some changes to the standard behavior of the following elements are required in our scheme: • IEEE 802.15.4 Mac. When receiving a packet, the mac sublayer needs to be aware of the transmit power level used by the sender. For this, we define an Information Element (IE) in the 802.15.4 header that indicates the power level used in the transmission of the frame (i.e., H or L). This is a flexible way to extend IEEE 802.15.4 in an interoperable manner. This sublayer also needs to be able to instruct the PHY layer to use a specific transmit power for data packets as a result of a new parent election.
• RPL DIO announcements. Nodes have to send DIOs at various transmit power levels so that per-level statistics can be kept. Multicast DIOs announcements are still sent according to the Tickle timer, but instead of sending a batch of consecutive DIOs at various power levels, we alternate the transmission power between H and L each time the timer timeout expires. This saves unnecessary overhead at the cost of slower reactivity to changes. In our scenario, however, nodes are static.
• RPL Probing (if active). ETX statistics are periodically refreshed by sending a unicast DIO packet to every outdated neighbor. In our scheme, the target to be refreshed will be not only the link but also the transmission power level (i.e., H and L).
For the remainder of the paper we assume that the previous enablers are in place.

2) UPDATING STATISTICS
When a new frame is received, the PHY layer generates a PD-DATA.indication primitive, which contains the ppduLinkQuality of the received frame and sends it to the MAC sublayer, which is in charge of maintaining link quality statistics for the mac address and transmit power used by the sender. This tuple (mac address, transmit power level) will be used as index in the table of statistics maintained by this sublayer.
After receiving the packet, the mac sublayer processes the IEEE 802.15.4 header and reads both the source mac address and the transmit power level used to transmit the frame (carried in the IE part of the header). Then, ETX(i) is either initialized (the first time a neighbor and power level is discovered) or updated (for existing entries) with every packet sent to that neighbor based on ACK frames (and a retransmission counter) [15]. So the mac sublayer maintains a table such as the one shown in Figure 3.

C. RPL CROSS-LAYER ALGORITHM
Our cross-layer mechanism is driven by the routing function. In this section, we describe the objective function and RPL operation required by our scheme.

1) METOF OBJECTIVE FUNCTION
The parent is elected using following objective function: where PTX j stands for the transmit power used by node j for sending data packets. Since ETX accounts for the number of expected transmissions, the physical interpretation of (1) is the transmission power expected in the upward path to the root node. Thus, the OF described in (1) will be referred to as Minimum Expected Transmission Power OF (METOF).
Since each node includes its own transmission power settings, METOF is valid for heterogeneous networks (i.e., a mix nodes with different transmit power level).

Algorithm 1 Cross-Layer Algorithm
The input of our algorithm is the DIO (that includes the MC with the rank according to METOF), the table of RPL neighbors, and the actual transmit power for levels H and L. As shown in Figure 3, the RPL neighbors table is indexed VOLUME 9, 2021 by node address, and includes a new column (BPTX) that is the optimal transmission power to be used when transmitting packets to that neighbor. We first read the link statistics corresponding to the DIO sender for all possible transmit power levels. Then, we calculate the BPTX for that neighbor (i.e., the one providing the lowest local metric ETX · PTX ). Then, we update the rank and BPTX of the corresponding entry in the RPL neighbor table. The rank is calculated as the addition of the value in the metric container plus the local link metric unless this value is less than a minimum increment per hop ( ), which in our case is set 2 to 128 · PTX (L).
After updating the corresponding entry, RPL selects the lowest-ranked neighbor as the preferred parent, updating the ipv6 forwarding table accordingly. The local optimal TX power to be used locally will be the BPTX associated with that parent. Finally, the algorithm instructs the mac layer to use this local optimal TX power for transmitting application-level data packets. Figure 4 illustrates the operation of our cross-layer scheme in a scenario where sensor nodes have two levels of transmit power: PTX(H) = 0.5 mW, and PTX(L) = 0.2 mW. Links' ETX are assumed to be 1 except for those values shown in the figure. We assume that all nodes but node 2 have already joined the DODAG and we show the local transmit power chosen by each node (PTX). In this example we analyze the operation of node 2. The ranking received in the MC was 1.7, so the rank for neighbor 3 would be 2.2. Therefore, node 3 would be chosen as preferred parent and the local TX power would be set to H (0.5).

D. EXAMPLE OF OPERATION
In our example, node 2 chooses a longer path because the cumulative expected transmission energy is smaller than in the shorter path. Obviously, this depends on both links quality (i.e., ETX) and the actual levels of transmit power used PTX(H) and PTX(L).

E. IMPLEMENTATION IN CONTIKI-NG
We have implemented our cross-layer mechanism in Contiki-NG [32]. Contiki-NG started as a major rewrite of the 2017 version of Contiki, with a focus on the most important and stable functionality. As default, Contiki-NG implements a lightweight version of RPL named RPL-lite [33] that lacks support for storing mode and removes the complexity of handling multiple instances and DODAGs.
For the sake of readability, we have moved implementation issues to Appendix A. The interested reader can find there a description of the main elements involved in Contiki's network architecture and details of the modifications made to accommodate our cross-layer scheme in RPL-Lite, ETX module, IEEE 802.15.4, and the mechanism created to control the transmit power.

V. SIMULATION SET-UP
Contiki-NG features Cooja, a java-based simulator of applications that allows one to interact with devices' code via specialized plugins. We have used Cooja to validate our cross-layer scheme and quantify its benefits versus standard RPL with default ETX metric and transmission power. 3 The following properties are common to all simulations: Node's hardware: Cooja supports the Sky and Z1 motes. Both offer multiple transmission power levels, use the radio transceiver CC2420, and are widely referenced in the literature. The power levels chosen for the Z1 mote 4 were: Terrain size and motes layout: We simulate two main scenarios. The first one has 15 client nodes (motes) located randomly over a squared area of a small-medium size (e.g., from 25 m × 25 m to 50 m × 50 m). The second one uses between 40 and 100 motes located randomly over a squared area of 150 m × 150 m. In all cases, a root node (additional to the motes) is always located at the centroid of the square.
Traffic generation: nodes run the default udp-server and udp-client example application, sending a message ('hello') to the root node periodically. In the small-medium scenario, we simulate 10 hours of operation with data transmissions produced randomly within 10 sec (a total 3 597 data packets generated by each mote). In this way, data traffic will prevail over control traffic. In the large scenario, we simulate 1 hour of operation with transmissions every 60 secs (180 data packets per mote).
Radio link model: We use the Unit Disk Graph Medium (UDGM) model with linear path loss (e.g., RSSI and error probability increase with distance). We disabled errors in TX or RX.

A. INFORMATION COLLECTED FROM MOTES
In the startup process, each mote initializes a set of specialized plugins to keep track of statistics related to QoS, energy, or RPL behavior. The following plugins have been used: • Energest plugin. This is a Contiki-NG module [15] for gauging how long hardware components are on. Some variables available off-the-shelf are CPU (in active and low-power mode 5 ), or how long the radio has been transmitting or listening (which could be either receiving or idle). We have added variables to recognize transmission power levels.
• PowerTracker plugin. This Contiki-NG plugin let us find how long the radio is on, transmitting, or receiving. We use it to complement Energest plugin and find the actual time spent in RX and idle (as Energest does not discriminate them).
• Event-count plugin. We have developed this plugin for recording events or statistics of interest. These statistics are related to RPL performance (e.g., delay to join the DODAG, number of changes of preferred parent), RPL messages sent by the node at each power level, application-level counters (e.g., application packets sent at each power level), and general traffic counters such as the number of frames sent and received, number of retransmissions, etc. The final list of indicators generated per simulation (and a brief description) is listed in Table 1.
The statistics related to energy consumption have been calculated by multiplying the time spent on each state of the hardware component (as measured by the plugins) by the corresponding values of current intensity and voltage found in the CC2420 and T1 datasheets shown in Table 2. As such, the energy of the mote is calculated as: where the time spent on each state from Equation 2 is collected from the simulator. 5 A low-power mode of CPU exists E LPM , but its contribution to the overall energy budget is negligible due to a very low current of 0.00015mA, being about the same in all scenarios and representing less than 0.1% of the overall energy.

1) SIMULATION PROCESS
We used the plugin Simulation Script Editor to automate the simulation process and collect the statistics of interest from motes via UART at the end of each simulation run. Basically, our script creates a square area of a specific size, distributes motes randomly over the area, initializes the simulation, collects the results from each mote using the plugins mentioned above, and calls a post-processing script to get the final results.
Simulations are repeated 25 times for better significance of results. On each repetition, the motes are randomly distributed over the square area. Thus, all results provided in the remainder of this paper represent the average values of these 25 simulation runs. We have also saved and reviewed the results obtained after each simulation run to validate exceptional cases such as disconnected motes.

VI. RESULTS
Using the settings described above, we have simulated the operation of our cross-layer scheme x-RPL(METOF) and standard RPL(MRHOF) with default (H) transmit power. The comparison of both will allow one to validate, gain insight and quantify the benefits of our proposal. Simulation results for the small scenario are shown in Table 3. Indicators express cumulative values (the sum of the 15 motes) except for delay-related statistics, which represent average values. Indicators ending in H or L stand for packets transmitted using the corresponding power level. Detailed (i.e., per mote) results are provided in Appendix B for the VOLUME 9, 2021 interested reader. A description and analysis of the results from Table 3 follows.

1) OBSERVED NETWORK BEHAVIOR
An area of 25 m × 25 m is likely to produce a star topology since the root is in range for all motes. Examining the traffic and QoS counters from standard RPL, it can be concluded that traffic load is low, links are stable, and the routing topology is shaped like a star. Some evidence supporting these conclusions are scarce retransmissions -affecting less than 0.07% of the packets-, no changes of preferred parent, and lack of relay operation in motes according to the number of packets forwarded (which is residual and primarily due to the initial transient period of topology formation). Furthermore, the packet delay is low (28 ms), and in Appendix B the reader can verify that it is similar in all nodes.
The behavior observed in x-RPL(METOF) is not different than in standard RPL. Scarce retransmissions (less than 1%), stable links (few changes of preferred parent), lack of relay operation, and a similar low delay are signs of a star-like routing topology in an uncongested network. The counters in x-RPL reveal that (on average) almost 66% of packets are transmitted in low-power (L), which can be interpreted as 2 of 3 nodes (on average) operate in low-power (L) in the simulated scenario. Precisely, due to this, nodes in x-RPL receive on average 23% less packets than nodes running standard RPL due to fewer neighbors in range.

2) ENERGY PERFORMANCE
Examining the energy-related statistics in Table 3, it can be concluded that our cross-layer approach compares favorably with standard RPL. Not only the cumulative energy spent in packet transmission is reduced 25%, but also in reception (a 26%) due to some motes using the L transmit power level. 6 The latter is particularly important in the light of the energy breakdown shown in Figure 11 since the energy spent in reception is significantly greater than in transmission in our simulations (12.4% vs less than 1% of the total energy expenditure in standard RPL).

FIGURE 5. Energy breakdown in both schemes.
As shown in Figure 11, most of the energy is devoted to the idle radio state (over 73% in both schemes). This is why the total energy savings with our scheme are more modest (around 3%) in the absence of a radio duty cycle mechanism. Note, however, that if TSCH was in place, most of the energy spent in idle state would be eliminated.
Another result attributable to having fewer neighbors is processing fewer DIO packets which translates to less CPU usage. As such x-RPL exhibits CPU energy savings of 1% with respect to standard RPL.
So we can conclude that in the 25 m × 25 m scenario our cross-layer scheme reduces energy consumption while maintains QoS with respect to standard RPL with default transmit power H in all nodes.

B. OTHER ASPECTS IN SMALL-MEDIUM SCENARIOS
In this section, we analyze additional aspects not addressed in our previous scenario by performing additional simulations (all with 15 motes). For the sake of conciseness we only show the results relevant for the analysis provided.

1) IMPACT OF PROBING
Probing has been enabled in the simulated scenarios. Although probing improves stability and convergence speed, it also increases traffic by sending unicast DIO packets to outdated neighbors, a traffic increase of about 10% in our simulations (41 DIO packets per hour and node).
Results obtained without probing are somehow similar to that with probing. Logically, the lack of unicast DIO packets reduces the energy spent in transmission, reception, and CPU accordingly, which is shown in Figure 6. Since the traffic load simulated is low, the benefit of using probing is diluted. In more complex scenarios, or under poor network performance, however, probing should be examined in the light of cost (more traffic and energy consumption) and benefit (i.e., better adaptation to topology changes).

2) 15 MOTES IN A LARGER AREA (FROM SMALL TO MEDIUM)
In larger terrains, more nodes in x-RPL are expected to set their transmission power to H to avoid disconnection. For this reason, we have gradually increased the terrain size in our simulations up to 50 m × 50 m. Figure 7 shows the percentage of packets sent using the low-power setting and the energy savings achieved by our scheme for each size simulated.
Results in Figure 7 confirm our hypothesis. With greater sparsity, more nodes set their transmission power to H to avoid disconnection. As such, differences between our cross-layer scheme and standard RPL tend to diminish. All nodes were connected in all simulation runs, and the delay achieved was similar to that of 25m × 25m (i.e., about 28ms), suggesting tree-like topologies. This result is also due to the effect of the power levels chosen, which produces that nodes only select L if it does not add an extra hop in the path.

3) CHANGING DEFAULT TRANSMISSION POWER TO LOW
Using H as default transmit power is more cost-effective than L as it provides better coverage, most applications are not traffic-intensive, and it also improves mobility support. Nevertheless, we have explored the results that would have been obtained had the default transmit power been set to low (L). Lower transmission power is expected to produce shorter coverage, which may lead to longer paths. In the worst case, isolated nodes will not be able to send data packets (depending on the nodes' layout and area size). For this reason, we have checked the number of times that nodes are disconnected (i.e., unable to send 'hello' packets) after every simulation run for different area sizes. Figure 8 provides the rate of disconnection for every node for different area sizes.  Figure 8 show nodes disconnected in some simulation runs for all area sizes simulated. In the scenario of 25 m × 25 m two nodes were disconnected in 8% of the simulations. The number and frequency of disconnected nodes increase with node sparsity. Indeed, only 53% of nodes were always connected (i.e., over the 25 simulation runs) in a 30 × 30 m scenario. For larger areas, we could not find a single node connected through all simulations. As expected, QoS degrades with lower transmission power, which is evidenced not only by disconnected nodes but also by increased packet delay (from 28ms to 37ms on average) and increased retransmissions. So we can conclude that a default transmission power of L is not generally feasible due to the risk of unconnected nodes.

C. LARGE SCENARIO: 150 m × 150 m
Our small-medium (15 nodes in star topology) provided insight into our cross-layer approach, but it is small in size and number of nodes compared with most related works. 7 For this reason, we simulate a larger scenario of 150 m × 150 m increasing the number of nodes from 40 to 100. Recall that in this scenario we simulate one hour of operation and the 'hello' packet generation has been set to 1 packet per minute.  Table 4 shows the results obtained in x-RPL. The first group of rows shows cumulative values except for delays (which show average values). We have added the percentage of low-power packets over the total number of application-level packets sent (%APP-L), and the percentage of packets forwarded over the number of packets transmitted (% forwarded). The percentage of nodes operating at low-power ranges from 2.5% to 11%. When nodes are more sparse, only those with very close parents (notice that our L setting has a range of about 6 m) use the low-power setting. This can be better observed in a scenario taken from one of our simulations shown in Figure 9 (where the grid represents 10 m × 10 m).
As expected, traffic increases with the number of nodes, as it does the number of nearby nodes, which tends to cause longer paths. Some evidence supporting this is the increment in % of forwarding (from 30% to 36%) and packet delay (from almost 50 ms to 63 ms). The packet delivery rate is very close to 100%. Looking at the routing performance, the delay in joining the DODAG and the number of parent switching 7 Most papers use an area size between 100 m × 100 m and 200 m × 200 m, and according to [23] a study of 39 papers showed that the average number of nodes simulated was 49.4.  made by nodes (i.e., instability) grows with the number of nodes ranging from 1.83 to 3.83. Indirectly this increases the odds of nodes switching their transmit power setting.
The third group of rows shows the per-node (not cumulative) power expenditure. Logically, the energy consumption grows with the number of nodes mainly due to the energy spent in receiving and processing more packets. Table 5 shows the results obtained with RPL for comparison. The QoS performance is very similar to x-RPL for a similar number of nodes. Packet delay increases with nodes (ranging from 50.45 ms to 59.75 ms) as it does the path length according to both delay and the percentage of relay. The number of unacknowledged packets is negligible, providing almost 100% of packet delivery rate. The most notable difference is that with standard RPL the number of packets received and DIOs processed is significantly greater than with x-RPL, which translates into more energy consumption in these two components. From Tables 4 and 5 it can be concluded that QoS performance in x-RPL is similar to standard RPL in the simulated scenarios.

D. INFLUENCE OF SPARSITY
Using the simulations from the previous sections, we have calculated the sparsity of nodes for each scenario dividing the area size by the number of nodes simulated. This section studies the percentage of application-level packets sent using the low-power setting L according to node sparsity. Taking the rate of low-power packets transmitted in Figure 10 as a rough indicator of the percentage of nodes self-configured in low (L) transmit power setting, we can observe that this number lessens with sparsity in a non-lineal way. This confirms our initial judgment that our scheme provides better results in highly dense scenarios.

VII. LIMITATIONS
This work is only a first step in exploring energy efficiency through a cross-layer PHY-RPL approach. As such, some limitations prevent the excessive generalization of our results and pave the way for further research. The first and most obvious is that our scheme only makes sense in networks where nodes can operate with different transmit power levels. Other limitations include: • Our choice for H and L power levels in the Z1 mote (55mW and 31mW respectively) and our OF have resulted in nodes choosing L only if it does not add more hops to the path. As such, different power levels or a different minimum hop penalty in the calculus of the rank could have resulted in other behavior.
• Our OF considers a single metric that may not be suited for some applications. RPL counts with a good deal of enhancements [34], including single and combined metrics suggested in the literature [12]. Our cross-layer scheme could be enhanced with some of these metrics (e.g., offering a balance between network life and energy efficiency).
• Bi-level vs Multi-level. Using two levels of transmit power has produced a simple behavior where only very close nodes set to L. If multiple levels of transmission power were available (e.g., 8 or 16) the behavior would be different and there would be a cost-benefit analysis to be studied.

VIII. CONCLUSION AND FURTHER WORK
This paper has explored a novel scheme for improving energy efficiency in IEEE 802.15.4 IoT devices with adjustable transmission power levels. In our cross-layer approach, each node maintains fresh statistics for each neighbor and power level and self-adjusts its transmission power according to RPL's choice of the preferred parent. Our cross-layer scheme reduces energy consumption without impairing QoS in nodes when compared to standard RPL. This energy reduction is based on savings in transmission, but mostly in fewer packets being received and processed. The percentage of nodes configured in low-power setting strongly depends on the nodes layout, decreasing notably with nodes sparsity.
This preliminary work still has open questions that require complementary research. Some of the issues left for further work follow. An extension to multiple power levels (i.e., more than 2), including an analysis of the sensitivity of the levels to the objective function, nodes' layout, resource consumption, and network performance. Another area of interest is in the objective function. Many metrics suggested in the literature can be combined with our cross-layer approach providing enhanced performance. Another subject of interest for research purposes could be exploring the feasibility of a joint RPL approach that combined dynamic transmit power and data-rate adaptation in IEEE 802.11 WSN. Finally, mobility introduces a major challenge for RPL [35]- [37] and the applicability of our scheme should be the subject of further study in this area. Figure 11 shows the main modules involved in the netstat pile used by Contiki-NG as well as the relationship between these modules. They can be described as follows:

APPENDIX A IMPLEMENTATION OUTLINE USING CONTIKI-NG
• Network. This block is in charge of the transport-level and network-level service, excluding the routing function. It creates, sends, and receives data packets for the application. It uses a shared buffer (UIPbuff ) with the routing function. Its modules are: udp-socket. This module allows one to use UDP connections to send and receive messages between nodes. It is serviced by the ipv6 module. -icmp6. Is in charge of sending and receiving control messages for IPv6. For our purposes, it will send and receive RPL's DIO, DIS, and DAO packets interfacing with the routing module. -ipv6. This core module is responsible for the creation and processing of datagrams and the forwarding function. It also maintains a list with the network and link addresses of each neighbor and the forwarding table (assisted by the routing module). sicslowpan. It performs header compression /decompression for IPv6 packets, featuring fragmentation / reassembly if necessary. Once a packet is ready to go, it reads it from the UIPbuff buffer and places it as payload in a buffer named packetbuff accessible to the mac sublayer.
• Routing. This module is in charge of routing, including the processing of source routing headers [38]. It also generates and processes RPL control messages (DIO, DIS, and DAO) which are passed to/from the icmp6 module via the UIPbuff buffer. When a preferred parent is selected, this module instructs the ipv6 module to update its forwarding where α is 10 if link statistics are fresh and 25 if not (according to default values).
• Radio the chip radio used in this project is CC2420. It sends and receives frames to/from packetbuff and provides PHY statistics to the mac layer. Packets are transmitted using the power level indicated in a register.

A. IMPLEMENTING OUR SCHEME IN CONTIKI-NG
This section outlines the main modifications made to the original netstack.

1) MECHANISM TO HANDLE THE TRANSMIT POWER LEVEL
We have added a global variable to RPL-Lite that indicates the transmit power level to be used by the radio. The mac layer will read this variable and change the radio power register accordingly right before instructing the PHY layer to transmit a new frame that encapsulates application data, restoring it to default after the transmission. 8 2) CHANGES IN IEEE 802. 15.4 Frames that need to inform about power settings include a new Information Element (IE) header (5 bytes) that extends the IEEE 802.15.4 to indicate the transmission power level used. 9 Besides the frame, the data structure of Packetbuff buffer stores additional information such as RSSI (of a received frame) or header fields such as sequence number, etc. We take advantage of this buffer to exchange power-related information between layers by introducing two new variables that indicate whether to transmit at a specific power level or not, and the power level to be used to transmit the frame. These variables are examined for handling IE header content after a frame reception or before frame transmission.

3) ETX MODULE MODIFICATIONS
ETX has to be initiated and updated for every tuple: mac address and transmission power level. We have modified the default data structure to include a new column in the statistics table for the power transmission level. Other modifications in the ETX module are: • before calculating ETX for an outgoing packet or updating RSSI for an incoming packet, we obtain the transmission power level of such packet to update the right entry (i.e., mac address and power level) in the table. 8 Some chipsets like CC2420 perform hardware-sent ACKs using a default transmit power of H. Disabling hardware ACKs causes delay due to software processing and overload under heavy traffic, so we decided to enable the hardware ACKs and keep the radio always high except when it is required. 9 Files frame802154e-ie.h and frame802154e-ie.c show how to define and use custom IEs.
• freshness and last_tx_time are now considered for every power level possible.

4) RPL-LITE MODIFICATIONS
Changes to RPL-Lite are geared toward controlling the transmission power used for sending DIOs and adapting probing targets to the tuple address and power level.
• Controlling the power level of DIOs. DIOs are sent by the function rpl_icmp6_dio from the icmpv6 module. We have modified this function to add power as a new input parameter. Before sending the DIO, icmpv6 reads the packetbuff's power-related variables to set the desired power level. Similarly, we have modified the function that sends DIS to use always the default power level (H).
• Sending periodic multicast DIOs. DIO multicast packets are generated periodically according to the Tricke algorithm alternating the power level between H and L each time. For this, we have added a new variable to the DAG information data structure rpl_dag_t that indicates the desired transmission power level and switches after every transmission.
• Probing (unicast DIOs). Modifications in probing are geared toward considering the tuple mac address and power level as potential target instead of only the mac address. This includes the maintenance of the freshness indicator and the function in charge of selecting the next target to be polled (get-probing-target).

5) OBJECTIVE FUNCTION
The implementation of METOF is based on MRHOF and can be summarized as follows.
• Link metric implementation. Contiki-NG uses the function nbr_link_metric to calculate link metric for a neighbor. We have edited this function to calculate the best the link metric for a specific neighbor i as:  similarly to Algorithm 1. We also store the best power setting (BPTX field of the RPL neighbors table) for that neighbor in this function. This function will return 0xFFFF if the local metric cannot be calculated due to uninitialized values of ETX.
• DAG metric container update. We have modified the rpl_metric_container_t data structure to include the best link metric. After receiving a DIO from a neighbor, the metric container is updated for the DODAG instance (rpl_instance_t) according to the preferred parent.
• transmission power settings. Every time the DAG state is updated with a preferred parent, the global variable that control the transmission power level is updated.

APPENDIX B SIMULATION FOR SCENARIO 25 × 25m
This appendix provides the per-mote simulation results obtained as the average of the 25 simulation runs for the main scenario of 25 m × 25 m.