2.6.1. Simulation Scenario

In order to compare performance between the protocols in a near-real scenario, we considered a scenario based on a real city in which a source sensor node was represented as a bus traveling through the streets and avenues of an urban environment and performing air quality measurements while periodically sending the measured data to a central node (gateway). Thus, a mesh network topology was considered consisting of 25 nodes distributed among the streets and avenues of the city of João Pessoa, Brazil, as illustrated in Figure 1.

**Figure 1.** Network topology considered in the simulations.

#### 2.6.2. Simulation Settings

Each node illustrated in Figure 1 was defined with the wireless communication module LoRa SX1276 in the frequency range of 915 MHz. The node range was calculated considering antennas with a gain of 3 dBi, antenna height of 2.5 m, and transmission power of 20 dBm. In addition, the LoRa parameters are shown in Table 1.

Considering that the DVR protocol is proactive, a period of 5 min for sharing the routing tables was defined, with the first sharing being initiated at the start of the simulation. In the case of AODV protocol simulations, a period of 90 s was defined for the route maintenance mechanism (sending 'Hello' messages). Finally, a period of 30 s was used to transmit general messages and data packets from the sensors.


**Table 1.** General parameters used in the simulations.

#### 2.6.3. Evaluation Metrics

To evaluate the performance of the protocols implemented in Cupcarbon, several quantitative metrics calculated by the gateway during the reception of data packets were considered.

• Packet Delivery Rate (PDR): this metric is the ratio between the number of packets sent by a source node and the number of packets received by the destination, as provided by [9]:

$$PDR = \frac{\sum N\_{RX\_i}}{\sum N\_{TX\_i}} \times 100\% \tag{2}$$

where *NRXi* represents the number of data packets successfully received by a destination node *i* and *NTXi* is the number of packets sent to this device.

• Throughput (THR): the number of data packets successfully transmitted to their final destination on a given communication channel per unit of time [11]; THR can be calculated as follows:

$$THR = \frac{N\_{RX\_i}}{\text{Total simulation time}}.\tag{3}$$

• End-to-End Delay (E2ED): the average time required for a number of data packets to be successfully transmitted over the network from a source node to a specific destination [9]; it can be defined mathematically by

$$E2ED = \frac{\sum T\_{RX\_i} - T\_{TX\_i}}{N\_{RX\_i}} \,\prime \tag{4}$$

where *NRXi* is the number of data packets received by node *i*, *TRXi* represents the time the data packet was received, and *TTXi* is the time when the package was sent.

• Average Jitter (JIT): this represents the variation of the average end-to-end delay in the delivery of data packets in a network, which may cause a situation of non-regularity in the reception of data packets; the formula is provided by [36,37]:

$$Jitter = \frac{\sum E2ED\_{i\_k} - E2ED\_{i\_{k-1}}}{N\_{RX\_i}} \tag{5}$$

where *<sup>E</sup>*2*EDik* is the average delay of a given instant *<sup>k</sup>*, *<sup>E</sup>*2*EDik*−<sup>1</sup> is the average delay of the previous instant, and *NRXi* is the number of data packets received by node *i*.

#### *2.7. Classic Energy Consumption Model*

This is the standard energy consumption model adopted by the Cupcarbon simulator. To calculate how much battery energy a node consumes during data packet transmission, the following expression [29] can be used:

$$E\_{TX} = \left(\frac{\mathfrak{n}}{8}\right) \times E\_{TXb} \times P\_\prime \tag{6}$$

where *n* is the number of bits transmitted or received, *ETXb* is the energy consumption required to transmit one byte, and *P* is the power of the transmission expressed as a percentage.

Similarly, the energy consumption during data reception can be obtained as follows:

$$E\_{RX} = \left(\frac{n}{8}\right) \times E\_{RXb\prime} \tag{7}$$

where *n* is the number of bits transmitted or received and *ERXb* is the energy consumption required to receive one byte.

#### *2.8. Proposed Radio Power Adjustment (RPA) Routing Protocol for Energy Savings*

The proposed radio power adjustment (RPA) routing protocol is based on the DSR protocol, as DSR shows better overall performance, including the lowest energy consumption, as compared to DVR and AODV.

The first step of the proposed RPA routing protocol is to provide a way for Cupcarbon to compute the Radio Signal Strength Indicator (RSSI) from the distance between two nodes according to the log-distance model. This model was chosen because it is independent of the transmission frequency and antenna gain. The log-distance path loss model can be obtained by [38]:

$$
\overline{PL}(d) = \overline{PL}(d\_0) + 10n\log\left(\frac{d}{d\_0}\right),
\tag{8}
$$

where *n* corresponds to the path loss coefficient (the value of 3.3 was adopted in this work), *d* is the distance between the transmitter and the receiver, and *d*<sup>0</sup> is the reference distance.

The choice of the value of *n* was carried out by taking into account the experimental results obtained in [39]. In these experiments, two devices were used to exchange data using LoRa modulation in an urban environment while evaluating the packet delivery rate and RSSI as a function of the transmission distance. Then, the RSSI curves versus the distance were obtained and compared to the experimental data and the data from the log-distance model, with the value of *n* = 3.3 representing the best fit between the curves.

The value of *PL*(*d*0) represents the path loss for a direct line of sight with respect to the reference distance, and can be obtained by [38]:

$$\overline{PL}(d\_0) = 20\log\left(\frac{4\pi d\_0}{\lambda}\right). \tag{9}$$

In Equation (9), *d*<sup>0</sup> is the reference distance and the parameter *λ* corresponds to the carrier wavelength.

Equations (8) and (9) were programmed in CupCarbon. When any data are received, the distance between the transmitting and receiving nodes which are exchanging data is obtained through the computed RSSI function.

The second step of the proposed RPA routing protocol is the definition of an equation that relates the computed RSSI value to the minimum *PTX* necessary to maintain the communication link. To this end, simulations were performed in Cupcarbon varying the distance between two nodes.

In this way, a node *RX* was kept fixed and a node *TX* was initially moved to a distance equal to the maximum range of 1.7 km; *PTX*, that is, the transmission power of node *TX*, was set to the maximum value (20 dBm). Thus, the distance between the nodes was reduced

in 50-meter intervals until the minimum distance of 1 m was reached, with the RSSI value calculated for each distance at these intervals. At the same time as the distance was being reduced, at each new displacement point *PTX* was reduced in 5% intervals until a minimum value at which the communication link was not lost was reached.

The results of this process were then imported into Octave software and an interpolation process was performed applying the *polyfit* function. To assess which polynomial obtained a better approximation of the original data, the Root Mean Square Error (RMSE) was used as a criterion, resulting in the following mathematical expression being obtained:

$$\begin{aligned} P\_{TX}(RSSI) &= -1.161169468381691 \times 10^{-7} \cdot (RSSI)^5 \\ &- 4.870470506506291 \times 10^{-5} \cdot (RSSI)^4 \\ &- 0.008114743288230 \cdot (RSSI)^3 \\ &- 0.660852476932444 \cdot (RSSI)^2 \\ &- 25.953469491107786 \cdot RSSI \\ &- 3.829454402717133 \times 10^2 \end{aligned} \tag{10}$$

Finally, this expression was inserted into the DSR protocol code to determine the appropriate *PTX* for each RSSI value. To use the proposed RPA routing protocol, it is necessary to add a new column to the routing table that contains the value of *PTX* for each destination, this value being initialized with 100% and automatically changed as the simulation is run. A safety margin of 2% was considered as well, and was added to the value calculated by Equation (10) to provide more reliability during data packet transmission.

Figure 2 shows the process used to compute the minimum level of *PTX* needed to establish reliable communications. The first step is to identify the address of the node that sent the data and calculate the RSSI. This procedure is illustrated in Figure 2a, and the corresponding pseudocode is detailed in Algorithm 1 . This RSSI value is then used as an input parameter in Equation (10) to obtain the value of *PTX*, which is added to the safety margin value and saved in the column of the routing table that stores the level information power relative to that destination node.


When it is needed to carry out a transmission, the source node consults the power level value in its routing table, updates it, and sends the data packet. This procedure is illustrated in Figure 2b, and the corresponding pseudocode is detailed in Algorithm 2.


**Figure 2.** *PTX* Adjustment Flowcharts: (**a**) identification of the *PTX* level of a destination node and (**b**) power adjustment before data transmission.
