## 3 A Routing Protocol Based on Energy and Link Quality (REL)
### Path Selection and Load Balancing  
The limitations of node hardware and the quality variation of wireless links are a great challenge to providing high service availability [30], especially in WSN/IoT applications, where it is necessary to create mechanisms that can identify and mitigate or solve the energy hole problem. Energy holes can be caused by congestion or overuse of a route leading to the premature death of nodes. As discussed before, routing solutions must employ load balancing mechanisms that are able to divert traffic and, thus, increase QoS (less packet loss and delay rate) and reduce energy consumption. The main approach for load balancing and fault tolerance in WSNs/IoT applications is the use of multiple paths [9] to slit/control traffic along different routes. Through the use of multiple routes, nodes are able to increase reliability for data transmission and throughput by means of bandwidth aggregation, and balanced energy consumption as well. REL exploits a reactive scheme to find routes on demand, with the aim of reducing the signaling overhead and improving scalability. The route discovery process involves broadcasting RREQ and RREP messages. These messages search for available routes and assist the route selection process by collecting information about residual energy and link quality. Each received RREP represents an available route to the destination node and, according to the REL configuration, it is possible to store \(n\) possible routes to a given destination node. REL integrates/manages the values of three key metrics to find the best available routes as follows: _(i)_ quality of wireless links based on _WeakLinks_ metric; _(ii)_ residual energy; and _(iii)_ hop count to avoid long and inefficient paths. Additional fields are required in RREQ and RREP messages to report these three metrics to each possible route. The path selection process for REL relies on two thresholds to compare the possible routes. The first one is the hop count threshold \(\textit{HCdiff}_{max\_allow}\) (Hop Count Maximum Difference), which determines what is the maximum difference of hops to a given route. The second threshold is \(\textit{E}_{th}\) (Energy Threshold), which is used in two stages: route selection process and load balancing mechanism. In the case of the load balancing optimization, the \(\textit{E}_{th}\) corresponds to the monitoring of energy levels observed in each node individually. When the network starts its execution (bootstrap phase), each node has to store its own percentage of residual energy and, after each \(t\) time units, the node must compare the current energy level (\(\textit{E}_{(t)}\)) with what has been previously recorded (\(\textit{E}_{(t-1)}\)). If the difference between \(\textit{E}_{(t)}\) and \(\textit{E}_{(t-1)}\) is higher than \(\textit{E}_{th}\), it indicates an energy event of discharge or involving the need for a charge of the battery. The difference between energy levels is called \(Ind_{RADV}\) (Index RADV). The \(Ind_{RADV}\) must be compared with the \(\textit{E}_{th}\). If the value exceeds the threshold, a RADV (Route Advisor) message must notify nodes near the place where the energy event occurred. The RADV message gives information about the new value for the residual energy and informs the neighboring nodes, where they should re-assess the use of that node in their routes. RADV notifications can describe a discharge event if there is a critical point of traffic widely used for message routing. It can also present a recharge event if the node has an alternative energy source. The value assigned to \(\textit{E}_{th}\) should be aware about the overhead generated by RADV notifications. Low values of \(\textit{E}_{th}\) ensure a uniform energy consumption between the nodes, despite large numbers of notifications. Moreover, high values assigned to \(\textit{E}_{th}\) cause large differences in the energy consumption in the nodes. As result, this tradeoff can affect data traffic with delay or the network lifetime.