the network lifetime (Fig. 3.3). Conducting this type of analysis allows us to dissect the behavior of DiPTC and better showcase its performance.

<figure><img src="image_13.png" /></figure>

<figure><img src="image_14.png" /><figcaption>FIGURE 3.3: Traffic evolution in the BASIC scenario for DiPTC (0.5, 0.5, 0.5).</figcaption></figure>

As shown in Fig. 3.3(a), there is an alternation of transitory and stationary states, with the former only lasting for a short time due to factors such as node death or packet loss. What this suggests is that DiPTC can quickly converge to the desired number of measurements, known as *K*, despite obstacles like fluctuating environments. The transient states are generally caused by issues including node death and uplink loss, which Fig. 3.3(b) outlines in more detail. Even if a node downlink is lost, our algorithm will continue to function as the node itself keeps the same traffic intensity until it hears back from the gateway. The reason we see a lot of long stationary states is because of our mechanism which provides stability and reduces collisions. There are fewer collisions in general because there is less traffic overall (since $K=1$). Low traffic has also a positive effect on the lifetime of a node, as it reduces the battery depletion process.

<figure><img src="image_15.png" /></figure>

<figure><img src="image_16.png" /><figcaption>(A) Zoom on the traffic evolution in the BASIC scenario for (B) Error frequency in the BASIC scenario for DiPTC (0.5, 0.5, DiPTC (0.5, 0.5, 0.5)).</figcaption></figure>

<caption>FIGURE 3.4: Traffic evolution in the BASIC scenario for DiPTC (0.5, 0.5, 0.5) and a downlink probability reception of 0.99.</caption>

As shown in the zoomed-in section of Fig. 3.4(a), when node 12 dies (at time 10819.33h), it creates a new stationary state that lasts for 90 minutes, before another stationary state develops with a different active node (ID 78). Note that the downlink losses happening at 10819.66h and 10820h slightly delay this process, because feedback information is missing during those timeslots. This causes us to lose $\Delta T = 20$min, but the convergence is not affected. On uplink, however, we see more notable effects; transient regime prolonged due to extensive losses by active nodes 104, 96, 5, 84, 53.

We observe that traffic in LoRaWAN is lower than DiPTC when we compare the performance of DiPTC with that of LoRaWAN from Fig. 3.5(a). The maximum amount of received messages each period ($\Delta T = 10$min) is 9, versus 47 for DiPTC. However, the LoRaWAN fluctuations are more frequent than in our algorithm because packet generation in LoRaWAN follows a Poisson distribution with a rate of
0.0006. This implies that on average, one packet will be transmitted every 1500 minutes, resulting in fewer nodes transmitting more frequently.

<figure><img src="image_17.png" /><figcaption>FIGURE 3.5: Traffic evolution in the BASIC scenario for LoRaWAN.</figcaption></figure>

The traffic intensity in DiPTC is managed by an adaptive mechanism that adapts the nodes activity when the goal of having 1 measure per 10 minutes is not met and stabilizes it otherwise.

Because the goal of our application is to receive a specific number of messages every time period, we regard absolute error as an important performance indicator. Fig. 3.4(b) depicts application error frequency for both LoRaWAN and DiPTC. The application error for DiPTC is 0, with a few instances significantly below. LoRaWAN, on the other hand, frequently underperforms. The DiPTC allows for a significant extension of the lifetime network when compared with LoRaWAN. While an 8000 hours lifetime was possible prior to this proposal, now we can operate our network for 13000 hours.

<figure><img src="image_18.png" /><figcaption>FIGURE 3.6: Nodes traffic evolution in the BASIC scenario.</figcaption></figure>

Finally, Fig. 3.6 shows the node traffic evolution in the BASIC scenario using LoRaWAN and DiPTC. The active node traffic average corresponds to the traffic when $\alpha_n(t) > 0$, whereas the node traffic average corresponds to $m_n(t) > 0$. These figures highlight the importance of including a packet transmission control in LoRaWAN. In DiPTC, the maximum number of packets that a node can transmit is three times lower than in LoRaWAN, and the network traffic average is smoother.

In this section, we take a deep dive into the behavior of DiPTC to better understand the results that we obtained in the previous section. To be more precise, we look at the number of sent and received packets, number of collisions, dead nodes, and downlink/uplink losses throughout the whole network lifetime. We evaluate these metrics in the scenarios that put the most strain on the network, allowing us to study the impact of network densification and traffic intensification on DiPTC performance.
3.9.1 Impact of the traffic intensity

In this section, we focus on the INTENSE scenario, to test the vertical scalability of DiPTC. First, we want to ensure that using DiPTC does not damage data collection by introducing a spatial bias; for example, nodes closer to the gateway may experience better communication conditions and then be prioritized to send data than others, a problem that could be extremely detrimental to the requirements of this application. To do so, we plotted out the node activity at different times throughout the simulation in Fig. 3.7. A green-colored node indicates its activity. As we can see from these figures, messages sent to the gateway come from all over the targeted area, which shows that DiPTC can provide a form of spatial load-balancing. That is not the case in COTraC, where one or two nodes take over data transmission during a time period ΔT.

<figure><img src="image_19.png" /><figcaption>FIGURE 3.7: Spatial distribution of active nodes, 43200 min (1 month): (a) 10000 min, (b) 20000 min, (c) 10000 min, INTENSIVE scenario - DiPTC config. (0.5, 0.5, 0.06).</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>FIGURE 3.8: Traffic evolution in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.06) and a downlink probability reception of 0.99.</figcaption></figure>

Fig. 3.9 illustrates the evolution of the number of collisions, sent and received packets, dead nodes, downlink, and uplink losses, in the case of the INTENSIVE scenario for DiPTC. In the latter, the results for DiPTC show multiple alternations between long transient and short stationary states. These oscillations are caused by instabilities brought by numerous variables, including frequent and consecutive uplink and downlink losses, active node deaths, and a high collision probability. The probability is higher in this scenario since we shorten the time period ($\Delta T = 1$ min) while increasing the number of measurements required by the gateway ($K=10$).

If we look at the traffic evolution in the zoomed area (Fig. 3.9(a)) we notice that the number of packets received fluctuates at around 10 packets every minute with an error of at least three packets. These oscillations are triggered by the loss of an uplink packet from node 6 at 10175 min and two other packets belonging to nodes 6 and 96 at 10182 min. They persist for about twenty minutes, especially with the loss of downlink messages and collisions. At the end of the zoom, we can notice a 5
<figure><img src="image_21.png" /><figcaption>(A) Zoom on the traffic evolution in the INTENSIVE scenario for (B) Frequency error in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.5, 0.06) and LoRaWAN.</figcaption></figure>

<caption>FIGURE 3.9: Traffic evolution in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.06) and a downlink probability reception of 0.99.</caption>

minutes delay in the transient regime due to the downlink reliability. However, our proposal manages to converge with an acceptable level of error given the density of the network.

<figure><img src="image_22.png" /><figcaption>FIGURE 3.10: Traffic evolution in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.06) and a downlink probability reception of 0.70.</figcaption></figure>

In order to better evaluate the effects of downlink loss on DiPTC, we lower the downlink reception probability to $P_{DL} = 0.70$. As we can see in Fig. 3.10, we have the same general evolution pattern as in Fig. 3.9 where the downlink reception probability is higher $P_{DL} = 0.99$. Even though the transient state could experience some delays, the stationary state is unaffected, showing that DiPTC is resilient to downlink loss.

<figure><img src="image_23.png" /><figcaption>FIGURE 3.11: Traffic evolution in the INTENSIVE scenario for LoRaWAN.</figcaption></figure>
DiPTC performs significantly better than LoRaWAN in the INTENSIVE scenario, as shown in Fig. 3.9 and Fig. 3.11. LoRaWAN experiences a considerable number of uplink losses and collisions as a result of dead nodes and downlink losses. The convergence of our proposal depends mainly on the amount of lost uplink messages. Furthermore, in this case, the maximum absolute error is 7, which means that at worst, 17 messages are received at the gateway. With network density taken into account, this error is rather small.

Fig. 3.9(b) represents the application error over time in the case of the INTENSIVE scenario, respectively for LoRaWAN and DiPTC. The application error in DiPTC has lower values and frequencies than LoRaWAN. An application error of zero means that the application received exactly $k = 10$ measures. Note that the success rate of DiPTC is 19 times higher than LoRaWAN. This indicates that our algorithm can fulfill the demands of the application more often than LoRaWAN, even in the case of intensive traffic.

<figure><img src="image_24.png" /><figcaption>FIGURE 3.12: Nodes traffic evolution in the INTENSIVE scenario.</figcaption></figure>

Finally, Fig. 3.12 shows the nodes traffic evolution in the INTENSIVE scenario for DiPTC and LoRaWAN. In DiPTC (Fig. 3.12(a)), the traffic adaptation rate increases when the number of active node deaths increases, as expected. Unlike LoRaWAN (Fig. 3.12(b)), in DiPTC, the average network traffic increases with the nodes death accumulation. In LoRaWAN, the average network traffic is still regular after the nodes death accumulation, because of a traffic distribution generation that is fair on average.

## 3.9.2 Impact of the nodes scalability

In this section, we focus on the DENSE scenario, to test the horizontal scalability of DiPTC. We increased the number of nodes from 150 to 500 and decreased the traffic intensity compared to the INTENSIVE scenario.

<figure><img src="image_25.png" /><figcaption>FIGURE 3.13: Traffic evolution in the DENSE scenario for DiPTC (0.5, 0.5, 0.5).</figcaption></figure>
Note in Fig. 3.13(a) that there is an alternation of transient and stationary states, with the former only lasting for a short time due to factors such as node death or packet loss. What this suggests is that DiPTC can quickly converge to the desired number of measurements, known as *K*, despite fluctuating environments. As in the INTENSIVE scenario, the transient states are generally caused by issues including node death and uplink loss. Even if a node downlink is lost, our algorithm will continue to function as the node itself keeps the same traffic intensity until it hears back from the gateway. The reason we see a lot of long stationary states is that our DiPTC provides stability and reduces collisions. There are fewer collisions in general because there is less traffic overall (since $K=1$). Low traffic has also a positive effect on the lifetime of a node, as it reduces the battery depletion process. Despite the significant increase in the number of nodes, our approach can quickly converge to the target number of measurements, *K*, and maintain stability for a considerable amount of time.

<figure><img src="image_26.png" /><figcaption>FIGURE 3.14: Traffic evolution in the DENSE scenario for LoRaWAN.</figcaption></figure>

In comparison to DiPTC, we notice that the traffic in LoRaWAN appears to be lower (Fig. 3.14). The maximum number of received messages per period is only 28 ($\Delta T=10$ minutes), while in DiPTC it is 138. The LoRaWAN oscillations, on the other hand, are more frequent. This is due to the fact that LoRaWAN packet generation follows a Poisson distribution of rate 0.0002, which implies that one packet is sent every 5,000 minutes on average, causing the nodes to traffic less often but more regularly.

<figure><img src="image_27.png" /><figcaption>FIGURE 3.15: Error frequency in the DENSE scenario for DiPTC (0.5, 0.5, 0.5) and LoRaWAN.</figcaption></figure>

As illustrated in Fig. 3.15, DiPTC outperforms LoRaWAN when it comes to application error frequency. The null application error ($e = 0$) occurs three times more frequently with DiPTC than with LoRaWAN.

Finally, Fig. 3.16 shows node traffic evolution in the DENSE scenario for LoRaWAN and DiPTC. It illustrates the necessity to have a frame transmission control in LoRaWAN especially when the number of nodes is important. We notice that contrary to LoRaWAN, the maximum number of packets that a node can send in DiPTC remains significantly small (2 messages), although the number of nodes
<figure><img src="image_28.png" /><figcaption>FIGURE 3.16: Nodes traffic evolution in the DENSE scenario.</figcaption></figure>

increases in the network. The maximum number of packets that a node may send in DiPTC is 7 times lower than LoRaWAN, and the network traffic average is generally smoother.

## 3.10 Traffic control parameters evaluation

In the previous sections, DiPTC parameters ($x_I$, $x_D$, and $P_{adapt}$) were chosen and fixed according to the characteristics of the simulated network that took into account node density and traffic intensity. As a reminder, $x_I$ and $x_D$ represent how much the traffic will increase or decrease from the previous period. The larger the value of $x_I$, the faster the increase, and the greater the value of $x_D$, the slower the decrease. The last parameter, $P_{adapt}$, controls nodes adaptation traffic. This section investigates the effects of these three parameters on DiPTC performance using the previous scenarios: BASIC, INTENSIVE, and DENSE Table 3.2. We investigate the different values noted in Table 3.4.

<table><caption>TABLE 3.4: DiPTC configurations.</caption><thead><tr><th>P<sub>adapt</sub></th><th>x<sub>I</sub></th><th>x<sub>D</sub></th></tr></thead><tbody><tr><td rowspan="2">0.1</td><td>0.2</td><td>0.2</td></tr><tr><td>0.2</td><td>0.9</td></tr><tr><td rowspan="2">or<br>0.5</td><td>0.5</td><td>0.5</td></tr><tr><td>0.9</td><td>0.2</td></tr><tr><td></td><td>0.9</td><td>0.9</td></tr></tbody></table>

Fig. 3.17 compares the error and transient regimes duration frequencies, in the BASIC scenario for DiPTC, with a 0.5 adaptation probability. We can see that the four first configurations have similar results to the last one. In fact, in the configuration (0.9, 0.9, 0.5), nodes increase their traffic aggressively by $x_I = 0.9$ and decrease it slowly by $x_D = 0.9$, resulting in large errors and longer transient regimes, with important frequencies.

In Fig. 3.17(a), the best configurations with regards to receiving exactly 1 message each period of time $\Delta T = 1\text{min}$ from 150 nodes (i.e., error = 0) are in order (0.5, 0.5, 0.5), (0.2, 0.2, 0.5), (0.9, 0.2, 0.5) and finally (0.2, 0.9, 0.5). If the application admits an error of $\pm 1$, the configurations (0.2, 0.9, 0.5) and (0.2, 0.2, 0.5) are the best because weak increase configurations tend to make small errors more often. Hence they show more frequent short transient regimes (less than 3h), Fig 3.17(b).

Fig. 3.18 compares the error and transient regimes duration frequencies, in the BASIC scenario for DiPTC, with a 0.1 adaptation probability. As we can see, the decrease in the adaptation probability reduces the error and increases the duration of the transient regime. If the adaptation probability has a small value (0.1), the number of nodes allowed to adapt their traffic is small (15 nodes). Thus they make smaller errors but take a longer time to adjust their sending. Note that if the objective of the application is receiving exactly 1 message each time period $\Delta T = 10\text{min}$, then the best configurations
<figure><img src="image_29.png" /><figcaption>FIGURE 3.17: Comparison of error frequency and transient regimes duration frequencies, in the BASIC scenario for DiPTC when $P_{adapt}=0.5$.</figcaption></figure>

<figure><img src="image_30.png" /><figcaption>FIGURE 3.18: Comparison of error frequency and transient regimes duration frequencies, in the BASIC scenario for DiPTC when $P_{adapt}=0.1$.</figcaption></figure>

are, in order, (0.9, 0.2, 0.1), (0.5, 0.5, 0.1), (0.2, 0.2, 0.1), (0.2, 0.9, 0.1) and finally (0.9, 0.9, 0.1). Otherwise, if the objective is receiving $K = 1$ or $K = 2$ message(s) then the three following configurations are best: (0.5, 0.5, 0.1), (0.2, 0.2, 0.1) and (0.2, 0.9, 0.1). The choice of the probability adaptation depends on the application restrictions. If an application has sometimes bigger errors, then an average probability is suitable ($P_{adapt} = 0.5$). If not, then it must allow sometimes longer transient regimes.

<figure><img src="image_31.png" /><figcaption>FIGURE 3.19: Comparison of performance measures for different DiPTC configurations ($x_I, x_D, P_{adapt}$) in the BASIC scenario.</figcaption></figure>

Fig. 3.19 aims to compare the performance measures of the different DiPTC configurations in the BASIC scenario. These figures show a trade-off between the network lifetime and the success rate. Configuration (0.9, 0.9) underperforms in comparison to the others. Note that, similar to configurations (0.2, 0.2) and (0.2, 0.9), the configurations (0.9, 0.2) and (0.5, 0.5) also have similar values in all measures. Actually, in this scenario where the application desires 1 or 2 message(s) each time period $\Delta T = 10\text{min}$, configurations with a weak increasing coefficient $x_I$ traffic less and consume less energy,
thus performing better in terms of network lifetime. On the contrary, the configurations with a strong
increasing coefficient adapt their traffic more often to the desired messages and perform better with
regard to the success rate measure. Notice that the packet reception rate and the average channel
inactivity time are equal for the five configurations in both figures.

<figure><img src="image_32.png" /><figcaption>FIGURE 3.20: Comparison of error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for DiPTC when P<sub>adapt</sub>=0.5.</figcaption></figure>

Fig. 3.20 compares the error and transient regimes duration frequencies, in the INTENSIVE scenario for DiPTC, with a 0.5 adaptation probability. We notice that the five configurations have significantly different results. In this scenario, the adapting probability is set to 0.5, meaning that at least 75 nodes are capable of adapting their traffic, hence competing to send the 10 required measurements. Fig. 3.20(a) displays that the best configurations, with regards to receiving exactly 10 messages each period of time ΔT = 1min from 150 nodes i.e., (error = 0), are in order (0.2, 0.9, 0.5), (0.2, 0.2, 0.5), (0.9, 0.9, 0.5) and finally (0.9, 0.2, 0.5). Even with intensive traffic, the configurations with a low increase give the best results in terms of error frequency. A weak decreasing coefficient boosts the performance. Since nodes increase and decrease their traffic slowly, it is more likely to achieve the application requirements, i.e., receiving 10 measurements in a period of time Δ = 1min. Those configurations also show more frequent short regimes than the other ones Fig. 3.20(b).

<figure><img src="image_33.png" /><figcaption>FIGURE 3.21: Comparison of error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for DiPTC when P<sub>adapt</sub>=0.06.</figcaption></figure>

Fig. 3.21 compares the error and transient regimes duration frequencies, in the INTENSIVE scenario for DiPTC, with a 0.06 adaptation probability. As we can see, decreasing the adaptation probability increases significantly not only the frequency of sending ±10 messages per time period ΔT = 1min (i.e., error 0, 1 and −1) but also the frequency of the short transient regimes duration. In fact, in this scenario, at least 9 nodes are competing to send the ±10 messages each 1min. There are greater chances to meet the application requirements with 9 (P<sub>adapt</sub> = 0.1) nodes than with 75 nodes (P<sub>adapt</sub> = 0.5). Note that if the goal of the application is receiving exactly ±10 messages each period of time ΔT = 10min, then the best configurations are in order (0.2, 0.2, 0.06), (0.2, 0.9, 0.06), (0.5, 0.5, 0.06), (0.9, 0.2, 0.06) and
finally (0.9, 0.9, 0.06). With fewer competing nodes, the best configuration is (0.2, 0.2, 0.06). However, if the application allows an error of ±1, (0.2, 0.9, 0.06) is by far the best one.

<figure><img src="image_34.png" /><figcaption>FIGURE 3.22: Comparison of performance measures of different DiPTC configurations ($x_I, x_D, P_{adapt}$) in the INTENSIVE scenario.</figcaption></figure>

Fig. 3.22 compares the performance measures of the different DiPTC configurations in the INTENSIVE scenario. As we already notice in the previous figures, the configuration (0.2, 0.9, 0.06) performs better in comparison to the others (Fig. 3.22(a)). In this scenario (Fig. 3.22(b)) where at most 9 nodes compete to meet the application requirements (±10 message(s) at each period of time $\Delta T = 1$min), configurations with a weak increasing coefficient $x_I$ traffic and consume less energy, therefore providing longer lifetime.

<figure><img src="image_35.png" /><figcaption>FIGURE 3.23: Comparison of error frequency and transient regimes duration frequencies, in the DENSE scenario for DiPTC when $P_{adapt}=0.5$.</figcaption></figure>

<figure><img src="image_36.png" /><figcaption>FIGURE 3.24: Comparison of error frequency and transient regimes duration frequencies, in the DENSE scenario when $P_{adapt}=0.1$.</figcaption></figure>

Fig. 3.23 compares the error and transient regimes duration frequencies in the DENSE scenario for DiPTC, with a 0.5 adaptation probability. The best configurations, with regards to receiving exactly 1
message each time period $\Delta T = 10\text{min}$ from 150 nodes, (i.e., error = 0) are in order (0.2, 0.2, 0.5), (0.5, 0.5, 0.5), (0.9, 0.2, 0.5) and finally (0.2, 0.9, 0.5). If the application allows an error of $\pm 1$, the configurations (0.2, 0.9, 0.5) and (0.2, 0.2, 0.5) and (0.5, 0.5, 0.5) take the lead. We also observe an error increase and the apparition of longer transient regimes. When the number of nodes increases, the traffic increases, leading to more errors and longer transient regimes.

Fig. 3.24 compares the error and transient regimes duration frequencies, in the DENSE scenario for DiPTC, with a 0.1 adaptation probability. As we can see, the decrease in the adaptation probability decreases the errors and increases the duration of the transient regimes. If the adaptation probability has a small value $P = 0.1$, the number of nodes allowed to adapt their traffic each period of time is smaller (50 nodes), compared to when the adaptation probability is 0.5 (250 nodes). Thus they make smaller errors, but take a longer time to adjust their sending. The best configurations are characterized by small frequencies for larger errors, important frequencies when the error is 0, and finally short transient regimes duration. In the DENSE scenario and for an adaptation probability of 0.1, the best configurations are (0.2, 0.2, 0.1), (0.5, 0.5, 0.1), (0.9, 0.2, 0.1).

<figure><img src="image_37.png" /><figcaption>FIGURE 3.25: Comparison of performance measures of different DiPTC configurations ($x_I, x_D, P_{adapt}$) in the DENSE scenario.</figcaption></figure>

Fig. 3.25 contrast the performance measures of the different DiPTC configurations in the DENSE scenario. These figures display the presence of a trade-off between the network lifetime and the success rate. Actually, in this scenario where the application objective is 1 or 2 message(s) at a period of time $\Delta T = 10\text{min}$, configurations with a low increasing coefficient $x_I$ traffic less and consume less energy, therefore they perform better, in terms of network lifetime. While the configurations with a strong increasing coefficient adapt their traffic more often to the desired messages and perform better w.r.t. the success rate measure. Notice that the packet reception rate and the average channel inactivity time are equal for the five configurations in both figures.

## 3.11 Discussion & Insights

Our proposed algorithm, DiPTC, exhibits significant convergence performance across a variety of network scenarios. Its effectiveness extends beyond high-traffic networks to include those with a significant number of nodes, demonstrating the algorithm scalability and versatility in managing diverse network conditions. By incorporating control traffic management into LoRaWAN, DiPTC emerges as a powerful tool for optimizing overall network performance while ensuring strict adherence to application requirements. A notable feature of DiPTC is its ability to converge towards the desired measurement $K$ within a defined time period $\Delta T$ with a reasonable absolute error margin. This capability comes from the algorithm stability feature and adaptive nature, allowing it to navigate the complexities of LPWAN environments, such as LoRaWAN, with low collision rates and minimal overhead.

Upon detailed analysis, several key conclusions emerge regarding DiPTC behavior in different scenarios. Notably, the algorithm proves resilient to downlink unreliability, maintaining operational
integrity even in situations with a low downlink reception probability. This feature arises from the fact that, in our algorithm, nodes continue to transmit data in the same manner as they did in their previous period, even in the presence of downlink losses. Additionally, the algorithm exhibits a spatial load-balancing characteristic, differentiating it from other algorithms like COTraC, which contributes to its effectiveness in managing network resources. DiPTC probabilistic approach guarantees diversity in the collecting zone through adaptation probability and allows data collection to be distributed among various nodes. In terms of energy considerations, the impact of node battery depletion is addressed by DiPTC, introducing a short transient mode in response to an active node death. The algorithm convergence dynamics are influenced by uplink reliability, where lengthy transient states and brief stationary states are observed in the presence of less reliable uplinks.

The DiPTC algorithm capability is particularly evident in the **BASIC** scenario, where the application demands the collection of one message every 10 minutes. In this context, DiPTC utilizes its distributed and probabilistic features to effectively manage the competition among nodes. Despite the presence of 150 concurrent nodes competing for network access, DiPTC employs its adaptive probability mechanism to strategically choose the winning node. This selected node becomes the sole transmitter in the network for a specified period, either until experiences uplink losses or depletes its battery. This approach ensures that the network resources are efficiently utilized, meeting the application requirements while considering the constraints imposed by the LPWAN environment.

In the **DENSE** scenario, where we increased the network node density to evaluate the algorithm vertical scalability, DiPTC continues to achieve the application objective. Even with an expanded network composed of 500 nodes, DiPTC excels in selecting a single node to fulfill the application requirement of sending one message every 10 minutes. The probabilistic nature of DiPTC proves significant in reducing both the number of concurrent nodes and the convergence time. This highlights the algorithm ability to efficiently handle larger networks, ensuring optimal resource utilization and meeting application-specific demands in challenging LPWAN environments.

In the **INTENSIVE** scenario, where the application demands the collection of 10 messages per minute, DiPTC showcases its adaptability through height traffic. Unlike the **DENSE** and **BASIC** scenarios where DiPTC efficiently selects one node due to the lower traffic requirements, the **INTENSIVE** scenario introduces a more complex challenge. Here, DiPTC must choose multiple nodes to transmit the 10 messages each minute, contributing to longer transient states and a higher probability of collisions. The algorithm ability to converge toward the required measurements with reasonable absolute errors in the face of these challenges underscores its resilience and effectiveness in managing intensive traffic scenarios and addressing the challenges of real-world LPWAN environments.

The comparisons between DiPTC, LoRaWAN, and the centralized traffic control algorithm (COTraC) underscore DiPTC notable advantages. DiPTC excels in meeting goals within specified deadlines, keeping collision rates low, and extending the network overall lifetime. One standout feature is DiPTC spatial load-balancing capability, a characteristic absent in COTraC. This unique strength positions DiPTC as particularly effective in dynamic network environments, where the distribution of traffic across the network becomes an important factor in optimizing performance and ensuring reliability. This sets DiPTC as a promising solution for real-world LPWAN applications with diverse and evolving communication requirements.

In the DiPTC adaptation mechanism, the important parameters are the increasing coefficient $x_l$ and the decreasing coefficient $x_D$. The values chosen for these parameters play a significant role in determining network convergence. Our investigation reveals that adopting aggressive configurations, such as (0.9, 0.9), results in substantial errors and prolonged transient states, occurring frequently. Aggressively increasing traffic when insufficient data is collected or decreasing it sharply when an excess is observed leads to intensified oscillations with significant amplitude values. This, in turn, reduces the probability of achieving a stable convergence, emphasizing the delicate balance required in selecting appropriate values for these adaptation parameters. Another important parameter in DiPTC is the adaptation probability coefficient $P_{adapt}$. This parameter determines which nodes can participate in the competition for transmission. A decrease in the value of the adaptation probability
results in reduced error but an increase in the duration of the transient regime. A smaller adaptation
probability implies that only a limited number of nodes are allowed to adjust their traffic. While this
reduces errors, it also prolongs the time it takes for nodes to adapt their transmissions. Conversely, a
higher adaptation probability allows more nodes to participate, leading to potentially larger errors but
faster adjustments in transmission behavior. The selection of an appropriate adaptation probability is
essential for balancing error reduction and adjustment speed. The compromises among the three DiPTC
parameters (x<sub>I</sub>, x<sub>D</sub>, P<sub>adapt</sub>) introduce trade-offs between success rate and network lifetime. Selecting
appropriate values for these parameters is important and is closely tied to the specific constraints of
the application. For instance, if the application can tolerate receiving fewer messages more frequently,
certain parameter combinations might optimize for success rate in that context. Conversely, if the
priority is to extend the network overall lifetime by reducing the frequency of transmissions, different
parameter values might be more suitable. This flexibility allows DiPTC to adapt to diverse application
requirements and constraints, making it a versatile solution for a range of scenarios.

3.12 Conclusion

In this chapter, we present in section 3.5 our new DiPTC approach for traffic control in LPWANs.
This new approach uses the additive increase and multiplicative decrease algorithm along with a
binary feedback message to adapt the overall traffic to the application requirement (i.e., collecting K
measurements within a designated time period).

In sections 3.8 and 3.9 we illustrate and discuss our DiPTC performance evaluation. Our DiPTC,
achieves the application objective of collecting *K* measurements per period of time *ΔT*, while effectively
mitigating collision risks within acceptable delays. The algorithm also exhibits a notable threefold
increase in success rates compared to LoRaWAN, contributing significantly to network lifetime. In
comparison with the Centralized Optimal Traffic Control protocol (COTraC), DiPTC is adept at spatial
load balancing, efficiently distributing traffic across the network, a capability lacking in COTraC. The
decentralized nature of DiPTC proves advantageous in scenarios with limited network knowledge,
showcasing its adaptability and efficiency in traffic control.

In section 3.10, we investigate the impact of DiPTC traffic control parameters on network behavior and discuss the parameter settings adjustments to specific application requirements. In section 3.11, we discuss the global findings of our approach.
# Chapter 4

# DiPTC Multi-Gateway Behaviour Study

## Contents

<table><tr><td>4.1</td><td>Introduction</td><td>59</td></tr><tr><td>4.2</td><td>Multi-gateway motivation</td><td>60</td></tr><tr><td>4.3</td><td>Assumptions</td><td>60</td></tr><tr><td>4.3.1</td><td>Network configuration</td><td>61</td></tr><tr><td>4.3.2</td><td>Downlink communication</td><td>61</td></tr><tr><td>4.4</td><td>Toward a multi-gateway setup</td><td>62</td></tr><tr><td>4.4.1</td><td>Synchronous mode</td><td>62</td></tr><tr><td>4.4.2</td><td>Round-robin mode</td><td>64</td></tr><tr><td>4.5</td><td>Overview of DiPTC algorithm</td><td>64</td></tr><tr><td>4.6</td><td>Benchmark protocol: LoRaWAN</td><td>66</td></tr><tr><td>4.7</td><td>Simulation environment</td><td>67</td></tr><tr><td>4.8</td><td>Scenarios and network parameters</td><td>67</td></tr><tr><td>4.9</td><td>Horizontal and vertical scalability evaluation</td><td>68</td></tr><tr><td>4.9.1</td><td>Impact of traffic intensity</td><td>69</td></tr><tr><td>4.9.2</td><td>Impact of the nodes scalability</td><td>74</td></tr><tr><td>4.10</td><td>Discussion</td><td>77</td></tr><tr><td>4.11</td><td>Conclusion</td><td>78</td></tr></table>

## 4.1 Introduction

In this chapter, we improve DiPTC functionality, initially designed for a single gateway, for use in a multi-gateway environment. As discussed in the previous chapter, the DiPTC algorithm aims to decrease overall network traffic and respond to application requirements, such as collecting a specific number of measurements *K* within a given time period $\Delta T$. This is achieved through feedback message information.

This chapter is structured as follows, section 4.2 presents the importance and benefits of using a multi-gateway architecture in Low Power Wide Area Networks (LPWANs). Section 4.3 outlines our fundamental assumptions. Section 4.4 discusses the adaptation of DiPTC for multi-gateway situations. Section 4.5 offers a brief overview of the DiPTC algorithm. The benchmark LoRaWAN protocol, previously used for performance comparison, is revisited in section 4.6. Sections 4.7 and 4.8 explain the simulation setup and scenarios employed for DiPTC evaluation. We validate and contrast our findings with the LoRaWAN protocol in section 4.9, followed by a discussion in section 4.10 and a conclusion in section 4.11.
## 4.2 Multi-gateway motivation

A multi-gateway architecture in Low-Power Wide Area Networks (LPWANs) offers several benefits, including extended coverage, redundancy [22], load balancing [115], scalability [116], reduced latency and localization capabilities [117]. LPWANs provide long-range connectivity to low-power devices, allowing devices at different distances to communicate effectively. Multiple gateways ensure redundancy and reliability, allowing devices to connect to the network through alternative gateways in case of failure or connectivity issues. This redundancy prevents disruptions to critical data transmissions and ensures devices remain connected [118], [119].

LPWAN gateways, such as LoRaWAN, can handle a limited number of simultaneous connections due to their hardware and processing capabilities, distributing device connections across multiple gateways effectively. This balances network load, preventing congestion and optimizing overall performance [120]. As the number of LoRaWAN devices increases, a single gateway may become overwhelmed, requiring better scalability. Reduced latency is achieved by strategically placing multiple gateways, minimizing the average distance between devices and gateways, and improving network responsiveness. Localization and geolocation capabilities are also enabled by multiple gateways, allowing for accurate device location analysis, which is valuable for various applications like asset tracking, fleet management, and geospatial analytics. Overall, a multi-gateway architecture is an important component for building reliable and efficient LPWAN deployments, in particular, the deployment of LoRaWAN.

As said in the previous chapter, large-scale deployments require traffic control, even in multi-gateway architectures, for applications like environmental monitoring. Obtaining more data can cause network congestion, collisions, and energy waste while receiving less information results in inefficiency. LPWANs, such as LoRaWAN, operated by telecommunication companies, lack an algorithm for managing user traffic and node connections, causing congestion and potential connections with additional devices. In this chapter, we demonstrate that our Probabilistic and Distributed Traffic Control algorithm can also be used in a multi-gateway architecture to control the traffic in Low Power Wide Area Networks.

## 4.3 Assumptions

In our application, the main objective remains consistent with the mono-gateway scenario presented in the previous chapter, to collect a specified number *K* of packets per time period *ΔT* over a designated area. However, we now shift our focus to a more complex multi-gateway scenario, wherein there are multiple central gateways *M* surrounded by a variable number of uniformly distributed nodes *N*. To investigate and understand the behavior of our Distributed and Probabilistic Traffic Control (DiPTC) algorithm in this multi-gateway context, we establish a set of assumptions to frame our study effectively. These assumptions, outlined briefly in the following bullet points, constitute fundamental principles that will undergo in-depth discussion in the subsequent subsections.

1. **Multiple gateways configuration:** We set up the network with a multiple gateway as a base concept.

2. **Unknown number of nodes:** The exact number of nodes, *N*, connected to the network is undisclosed to reflect uncertainties in real-life LoRaWAN implementations.

3. **Known number or gateways:** The number gateways *M* is known and fixed, ensuring stability for study consistency.

4. **Dynamic nature of IoT nodes:** IoT nodes exhibit a dynamic nature, allowing for changes in node count over time due to factors such as new deployments, hardware failures, or inactive nodes resulting from drained batteries.
5. **Synchronous operations among gateways:** Assumed synchronous operation among gateways *M* for coordinated and coherent communication.

6. **Use of downlink as feedback link:** Within DiPTC, our proposed approach, downlink communication serves as a feedback link, a shift from its usual function in LoRaWAN contexts.

7. **Downlink Broadcasting and Multicasting capabilities:** The downlink is assumed to have both broadcast and multicast capabilities for simultaneous communication with multiple nodes in the LoRaWAN network.

8. **Simplified binary Acknowledgment in downlink Messages:** The content of the downlink message is envisaged as a straightforward binary acknowledgment, serving as a concise indicator of the success or failure of the application requirements.

9. **Post-downlink reception behavior:** Nodes shut receiving windows after the first downlink message for prompt action on feedback.

10. **Respect of the duty cycle constraint:** Nodes adhere to the duty cycle, contributing to energy efficiency and regulatory compliance.

**4.3.1 Network configuration**

The total number of nodes *N* associated with the network is unknown. This lack of prior knowledge reflects the dynamic nature of LPWANs, especially LoRaWANs, where node populations may change over time due to factors such as subsequent deployments, hardware failures, or depleted batteries. In contrast to the dynamic nature of the node population, the number of central gateways *M* is assumed to be known and remains fixed throughout the study period. This assumption simplifies the study by providing a stable reference point for gateway-related parameters. Changes in the gateway count could introduce additional variables and uncertainties, making it challenging to isolate the impact of other factors on the performance of DiPTC. The known and fixed number of gateways also facilitates easier scalability assessments and generalizability of the study findings. A fixed number of gateways ensures that observed effects can be more confidently attributed to the algorithm behavior rather than external changes in the network structure.

**4.3.2 Downlink communication**

Additionally, the assumption of synchronous operation among the gateways *M* complements the fixed gateway count. Synchronization ensures coordinated and coherent communication strategies among gateways, contributing to the overall efficiency of the network. This synchronicity is critical for avoiding potential conflicts and ensuring that the network operates seamlessly under the influence of the DiPTC algorithm. Reaching gateway synchronization in LoRaWAN is still an open issue [121]. The Feedback information is sourced from downlink messages, providing valuable insights for both network servers and applications. This downlink-based feedback mechanism is a key element in the control loop initiated by the central server to adjust the traffic policy based on application requirements. After receiving the first downlink message, we assume that each node shuts its receiving window. This characteristic post-downlink reception node behavior helps ensure that the feedback information is promptly acted upon, contributing to the efficiency of the traffic control process. Also, each node adheres to its duty cycle, an important consideration in LoRaWANs to prevent excessive activity that can lead to increased energy consumption. Respecting the duty cycle contributes to energy efficiency and regulatory compliance.

To deliver our feedback message, we can use the same transmission models that LoRAWAN employs to broadcast synchronously class B beacon to every node in the network. The class B mode of LoRaWAN, nodes have set times for receiving signals, known as receive windows, in addition to the
ones that open whenever they send data to the network (class A-style uplinks). To make this system work, the network regularly sends out a time-synchronized beacon through the gateways. The node needs to catch one of these beacons now and then so that it can adjust its internal clock to match the network timing. Using this beacon as a reference, the nodes can predict when to open specific time slots called ping slots. The network infrastructure can then use any of these ping slots to send a message (downlink communication) to the nodes. However, if a device is within range of multiple gateways, all broadcasting the class B beacon at the same time and using the same radio settings, it can receive a mix of these beacons, each having different signal strengths and distortions. For the device to understand and separate these mixed-up beacons with as little disruption as possible, the gateways must send their beacons at almost the same time, with very little timing difference (jitter), preferably less than one-millionth of a second. This precise timing makes the various beacons appear as a single packet, affected by radio multipath when they reach the device antenna. This way, the device can successfully interpret and understand these superposed beacons. Paper such as [121], [122] propose solutions for gateways synchronization in class B nodes.

By outlining these assumptions, we create a framework to explore and analyze the behavior of DiPTC in a multi-gateway scenario. These assumptions provide a foundation for studying the algorithm adaptability, efficiency, and overall performance in the dynamic and varied conditions of LPWANs, particularly LoRaWANs, with multiple gateways and a changing node population. The study aims to highlight how DiPTC effectively navigates the challenges posed by network uncertainties and exploits feedback mechanisms to optimize data collection.

## 4.4 Toward a multi-gateway setup

As a reminder, in DiPTC mono-gateway scenario (Fig. 4.1), each node is assigned a weighting coefficient, denoted as $\alpha_n$, governing its message transmission. At the end of a designated time period $\Delta T$, the network server compares the actual received message count ($k$) with a predefined objective ($K$). If $k$ is lower than $K$, a feedback mechanism increases the weighting coefficient for each node, allowing them to send more messages. Conversely, if $k$ exceeds $K$, the feedback instructs nodes to reduce their weighting coefficient. Nodes, following the DiPTC algorithm, locally update $\alpha_n(t)$ upon receiving feedback relayed by the gateway, influencing their transmission behavior.

In a multi-gateway scenario, the gateways need to relay the feedback message to the network nodes after its reception from the network server. The key question is how these gateways can effectively transmit this information to the nodes. In this chapter, we propose using two different modes to send the feedback message to the nodes. The first mode, called synchronous, involves the gateways broadcasting the feedback message simultaneously. It is similar to when several people speak at the same time, making sure that all nodes receive the message at once. However, in the second mode called round-robin, gateways take turns sending the feedback message. It is similar to people talking in turns, ensuring that each gateway gets a chance to transmit the message to the nodes. These two modes offer different ways to make sure the nodes get the important feedback message in a multi-gateway setup.

### 4.4.1 Synchronous mode

In the synchronous transmission mode, depicted in Fig. 4.2, the $M$ gateways send simultaneously the feedback message. Consider a scenario where a node, denoted as $n$, is allowed to transmit data, and it relies on a critical parameter called the weighting coefficient, denoted as $\alpha_n$. This coefficient plays a primordial role in deciding how many messages the node should send, as shown in Fig. 4.2, particularly in step (a). At the end of the designated time period $\Delta T$, the network server compares the actual number of received packets, denoted as $k$, with a predefined objective $K$. If $k$ is lower than $K$, the network server initiates a feedback message intended for the $M$ gateways. In response, all $M$ synchronous gateways simultaneously transmit the feedback message to the nodes within their respective coverage areas, as depicted in Fig. 4.2, step (b). The feedback message serves a primordial
<figure><img src="image_38.png" /><figcaption>FIGURE 4.1: Example of DiPTC mono-gateway, where all nodes transmit data at the same rate. (a) Network configuration with the initial weighting coefficient $\alpha_n(t_0)$ set to 0.5. (b) Feedback control is sent by the gateway to adapt the uplink traffic intensity. (c) Local computation of the new weighting coefficient $\alpha_n(t)$ and the new number of messages to send, based on the control feedback and the previous weighting coefficient $\alpha_n(t_0)$.</figcaption></figure>

purpose; to encourage an increase in the weighting coefficient for each node, consequently allowing them to transmit more messages. Conversely, if the received count exceeds the predefined objective ($k>K$), an inverse mechanism is activated. The gateways simultaneously transmit a feedback message instructing the nodes to reduce their weighting coefficient. Upon receiving the feedback message, each node, following the DiPTC algorithm, locally computes and updates its weighting coefficient $\alpha_n(t)$. This updated coefficient significantly influences the node transmission behavior, and it is then used to reevaluate the number of messages to be sent, as illustrated in Fig. 4.2, step (c).

<figure><img src="image_39.png" /><figcaption>FIGURE 4.2: Synchronous transmission in multi-gateway DiPTC. (a) Initial transmission considering the initial weighting coefficient equal $\alpha_n(t_0)$. (b) Feedback control is sent by all synchronous gateways to adapt uplink traffic intensity. (c) Closure of the downlink window occurs upon receiving the first feedback, followed by local computation of the new weighting coefficient $\alpha_n(t)$. This computation also takes into account the feedback received and the previous weighting coefficient $\alpha_n(t_0)$ to determine the number of messages to transmit.</figcaption></figure>
The simultaneous transmission raises concerns about downlink traffic efficiency and energy consumption. Receiving redundant feedback messages from all *M* gateways could be energetically costly for nodes, especially if they are within the range of multiple gateways. To address this, we assume that a node promptly closes its receiving window upon receiving its first feedback message. This ensures that each node receives only one feedback message, avoiding unnecessary energy expenditure associated with redundant receptions. This approach efficiently manages energy usage, contributing to prolonged battery life and the overall sustainability of the network.

### 4.4.2 Round-robin mode

<figure><img src="image_40.png" /><figcaption>FIGURE 4.3: Round-robin transmission in multi-gateway DiPTC. (a) Initial transmission considering the initial weighting coefficient $\alpha_n(t_0)$ equal to 0.5. (b) Feedback control is sent by only one selected round-robin gateway to its covered nodes as a means to adapt the uplink traffic intensity. (c) local computation of the new weighting coefficient $\alpha_n(t)$ and the number of messages to transmit based on the received feedback and the previous weighting coefficient $\alpha_n(t_0)$.</figcaption></figure>

In the round-robin transmission mode, depicted in Fig. 4.3, a distinct transmission approach is used. Unlike the simultaneous broadcast in the Synchronous mode, only one gateway takes its turn to transmit the feedback message. To put it simply, the feedback message reaches only the nodes covered by this specific gateway. How do we choose which gateway sends the message? We use a method called round-robin, where each time $\Delta T$ comes around, the next gateway in line gets the chance to transmit the feedback message Fig. 4.3 step (b). While there are other methods to choose from, we have opted for a straightforward approach based on equality and a logical order, without any complex criteria.

In this round-robin mode, having only one sending gateway is akin to a scenario with a single gateway. The distinction lies in the fact that only nodes within the range of the chosen gateway receive the feedback message. This provides them with the opportunity to adjust their traffic strategy by recalculating and fine-tuning their weighting factors, denoted as $\alpha_n(t)$. Subsequently, they recalculate the optimal number of messages to send, adapting to the feedback message Fig. 4.3 step (c).

## 4.5 Overview of DiPTC algorithm

This section is a reminder of the DiPTC algorithm explanation covered in the previous chapter. Our DiPTC algorithm is based on the additive increase multiplicative decrease algorithm. We use a decrease factor, $x_D$, to apply a reduction strategy when the network server receives excessive amounts of data.
On the other hand, we use an increasing policy with an increase factor, given by $x_I$, when the network server does not get enough data. This algorithm provides a prompt response by rapidly adapting the number of transmitted messages by every node, depending on the information sent by the network server through the gateway(s) in each time period $\Delta T$. To lighten the downlink message payload, which is highly constrained, the feedback message sent by the network server through the gateways is considered a binary value. In other words, the gateway(s) will either spread 0, meaning that too many packets were received, or 1 if not enough packets were sent. When the goal is met, the network server and gateway(s) send no downlink, and the nodes continue to send the same number of messages for the next time period. The traffic intensity of each node rises linearly, taking the coefficient $x_I$ into account, as long as the network server does not receive enough $K$ packets required by the application per time period $\Delta T$. Otherwise, when the network server receives more than $K$ packets, the nodes reduce their traffic intensity exponentially using the coefficient $x_D$.

As mentioned in the section above, the downlink transmission mode determines whether a feedback message is transmitted by all gateways (synchronously) or just one gateway (using a round-robin approach).

<figure><img src="image_41.png" /><figcaption>FIGURE 4.4: Diagram of the DiPTC algorithm for a node.</figcaption></figure>

The Diagram in Fig. 4.4 describes the DiPTC algorithm adopted by each node in the network. We define $m_n(t + \Delta T)$ as the number of messages to send by the node $n$ during the next time period $\Delta T$, $\alpha_n(t + \Delta T)$ the weighting coefficient for node $n$ which is used to compute the number of messages to
send, $Max_{DT}$ is the maximum number of messages a node can transmit during $\Delta T$ with regards to its duty cycle. Initially, the number of messages to be sent is null for all nodes: it avoids a burst of uplink messages when new end nodes are deployed in the network. The node then waits for the feedback message for the next time period $\Delta T$ before adjusting the number of messages to send. The network server only sends the feedback message via the gateway(s) if the number of received messages differs from the required number. This reduces downlink traffic.

To avoid an event-based synchronization between nodes which would lead to a situation where all the nodes react identically with the same number of messages to send, a node decides to take into account the next feedback message following a Bernoulli distribution ($B(p)$, see the stochastic variable $V_n(t)$). If the outcome of the Bernoulli distribution is positive, the node will wake up to receive the feedback message; otherwise, it will sleep and wake up to transmit its messages without adjusting its traffic intensity. Since receiving a downlink message consumes a considerable amount of energy in LPWANs, a node opens its reception window to receive the feedback message from the gateway(s) only if it should adapt its traffic as a result of a favorable draw ($V_n(t) = 1$), which saves energy.

When the feedback message is received and taken into account, each node increases or decreases its number of transmitted messages considering the weighting coefficient $\alpha_n(t)$ according to the binary value of the feedback message received from the gateway(s). On the one hand, each node increases the number of messages to transmit using $x_I, x_I \in [0, 1]$, if the value of the feedback message is equal to 1. On the other hand, it uses the multiplication factor $x_D$ to reduce the number of transmitted messages exponentially, $x_D \in [0, 1]$. The additive factor $x_I$ and the multiplicative factor $x_D$ are constant in time and identical for every node. They represent respectively, the increase or decrease in traffic compared to the last period. When the value of $x_I$ is greater, the amount of traffic at each node increases more quickly; conversely, when the value of $x_D$ is greater, the amount of traffic decreases more slowly. Next, the node schedules its $m_n(t + \Delta T)$ messages, which is the integer portion of $\alpha_n(t + \Delta T)$. A node is said to be active when $m_n(t + \Delta T) > 0$.

## 4.6 Benchmark protocol: LoRaWAN

We believe it is important to establish a comparison benchmark against the present LoRaWAN protocol. For this purpose, we adopt the same LoRaWAN benchmark algorithm as detailed in the preceding chapter. In essence, we aim to ensure a fair and meaningful comparison while adhering to the constraints imposed by the specific applications.

To elaborate on the benchmark scenario, where the goal is to receive a specified number $K$ of measurements within each designated time period $\Delta T$, the conventional LoRaWAN approach involves nodes transmitting packets following a Poisson distribution [73], [112]. To ensure fairness, the average rate parameter of this distribution is determined as follows:

$$ \lambda = \frac{\Delta T}{K} \times N \qquad (4.1) $$

$$ AVG = \frac{1}{\lambda} \qquad (4.2) $$

Where:

* $\frac{\Delta T}{K}$: The ratio of the specified time period $\Delta T$ to the desired number of measurements $K$. This factor determines the average time between consecutive packet transmissions necessary to achieve the goal of receiving $K$ measurements within $\Delta T$. A smaller value implies a higher transmission frequency.

* $N$: The total number of nodes in the LoRaWAN network. The inclusion of $N$ in the formula ensures that the mean arrival rate is scaled according to the network size.
* AVG: The mean inter arrival time.

Furthermore, in the LoRaWAN configuration, if a packet is lost during transmission, the protocol is designed to attempt re-transmission up to a maximum of 8 times before abandoning the process. This value aligns with common practices in various implementations, as the LoRaWAN standard specifies a maximum limit of 15 re-transmissions. However, it is noteworthy that in the DiPTC approach, re-transmissions are not part of the protocol. This distinction arises from the fact that nodes in DiPTC do not receive a unicast acknowledgment from the gateways, a feature present in the LoRaWAN protocol.

## 4.7 Simulation environment

In the continuation of our research, we use the same simulator as in the DiPTC mono-gateway LoRaSim [112], a widely recognized discrete event-based network simulator, to implement and assess our proposed methodologies. LoRaSim provides a versatile environment where we can deploy a specified number of nodes *N* and gateways *M* within a two-dimensional space. This simulator enables the incorporation of essential network features, such as collision handling, capture effects, and interference simulation. Building on the foundation of LoRaSim, we extended its capabilities to include enhancements that are integral to the evaluation of our approaches.

One significant enhancement is the incorporation of downlink communication simulation. While LoRaSim traditionally focused on uplink scenarios, we expanded its functionality to encompass downlink interactions. This improvement allows us to explore and evaluate the dynamics of communication in both directions, providing a more comprehensive understanding of network behavior. To accurately represent the reliability of downlink communication, we introduced a random variable following a Bernoulli distribution with a parameter *P*<sub>DL</sub>. This addition enables the modeling of the stochastic nature of downlink reliability, an important aspect in real-world LoRaWAN deployments.

Additionally, we maintained our approach to modeling collisions and interference on the uplink, exploiting equations from the previous chapter, particularly referencing equations 3.1 and 3.2. This consistency ensures a seamless integration of our proposed enhancements with the established simulation framework. Moving beyond the wireless environment, we addressed a limitation in LoRaSim related to energy consumption modeling for end nodes. By default, LoRaSim lacks an energy consumption model. To rectify this, we integrated a model derived from [113]. This energy consumption model, detailed in equations 3.4 and 3.3, introduces a more realistic representation of energy dynamics, a critical factor in evaluating the performance and sustainability of our proposed approaches in simulated scenarios.

## 4.8 Scenarios and network parameters

We consider the case of *M* central gateways surrounded by *N* randomly distributed nodes with LoRa parameters chosen at random. We evaluate and compare the performance of DiPTC with LoRaWAN using the three simulation scenarios listed in Table 4.1. Each scenario differs from the number of nodes *N* in the network, the number of measurements *K* required by the application in the time period *ΔT*, the increasing and decreasing parameters (*x*<sub>I</sub>, *x*<sub>D</sub>), the adaptation probability *P*<sub>adapt</sub>, and the simulation time *Simtime*. The adaptation parameters *x*<sub>I</sub>, *x*<sub>D</sub>, and *P*<sub>adapt</sub> depend on the number of nodes in the network and the traffic intensity. In this chapter, we use the best parameters discovered during the previous chapter analysis. These values are as follows: DiPTC (0.9, 0.2, 0.1) for the BASIC and the DENSE scenarios, and DiPTC (0.5, 0.5, 0.006) for the INTENSIVE scenario.

To evaluate the performance of DiPTC, we consider two different scenarios: BASIC, INTENSIVE and DENSE. In the BASIC scenario, we consider a normal traffic load to test our proposal. In the INTENSIVE scenario, we consider a significantly higher traffic load to test the scalability of our proposal. In the DENSE scenario, we consider a significantly larger number of nodes to test the spatial scalability of our
<table><caption>TABLE 4.1: Simulation scenarios.</caption><thead><tr><th>Scenario</th><th>BASIC</th><th>INTENSIVE</th><th>DENSE</th></tr></thead><tbody><tr><td colspan="4">DiPTC</td></tr><tr><td>N</td><td>150</td><td>150</td><td>500</td></tr><tr><td>M</td><td>3</td><td>3</td><td>3</td></tr><tr><td>K</td><td>1</td><td>10</td><td>1</td></tr><tr><td>ΔT</td><td>10 min</td><td>1 min</td><td>10 min</td></tr><tr><td>x<sub>I</sub></td><td>0.5</td><td>0.5</td><td>0.5</td></tr><tr><td>x<sub>D</sub></td><td>0.5</td><td>0.5</td><td>0.5</td></tr><tr><td>P<sub>adapt</sub></td><td>0.5</td><td>0.06</td><td>0.5</td></tr><tr><td>Simtime</td><td>1 year</td><td>1 year</td><td>1 year</td></tr><tr><td colspan="4">LoRaWAN</td></tr><tr><td>AVG</td><td>1500 min</td><td>15 min</td><td>5000</td></tr></tbody></table>

proposal. By testing DiPTC under these different scenarios, we are confident that it will perform well in a variety of situations.

<table><caption>TABLE 4.2: Network parameters.</caption><thead><tr><th>Parameters</th><th>Values</th></tr></thead><tbody><tr><td>Payload size (PL)</td><td>20 bytes</td></tr><tr><td>Header length (H)</td><td>0</td></tr><tr><td>Preamble symbols</td><td>8</td></tr><tr><td>Downlink reception probability P<sub>DL</sub></td><td>0.99</td></tr><tr><td>Transmission power P<sub>Tx</sub></td><td>14dBm</td></tr><tr><td>Gain and Loss GL</td><td>0</td></tr><tr><td>Path Loss exponent γ</td><td>2.08</td></tr><tr><td>Reference distance d<sub>0</sub></td><td>40m</td></tr><tr><td>Max. distance to the gateways</td><td>300m</td></tr><tr><td>Path Loss at the reference distance L<sub>pl</sub>(d<sub>0</sub>)</td><td>-127.41dB</td></tr><tr><td>Normal distribution X<sub>σ</sub></td><td>N(0,3.57)</td></tr><tr><td>Current drawn during the receive mode I<sub>Rx</sub></td><td>11.2mA</td></tr><tr><td>Current drawn during the Transmission mode I<sub>Tx</sub></td><td>90mA</td></tr><tr><td>Current drawn during the sleep mode I<sub>Sleep</sub></td><td>1μA</td></tr><tr><td>Supply voltage</td><td>3V</td></tr><tr><td>Battery capacity</td><td>20J</td></tr></tbody></table>

Table 4.2, summarizes the values of the different parameters used in our simulation. The values of the propagation model are determined empirically in [112], and those of the energy consumption model come from the datasheet of the Semtech SX1272 LoRa transceiver [114].

## 4.9 Horizontal and vertical scalability evaluation

In this section, we present a comprehensive performance evaluation of our proposed DiPTC algorithm within the context of a multi-gateway setup. The comparison focuses on key metrics such as the number of sent and received packets, occurrences of collisions, dead nodes, and losses in both downlink and uplink transmissions over the entire network lifetime. As in the previous chapter, we aim to evaluate DiPTC performance under scenarios that exert maximum demand on the network. By examining the system under increased network density (vertical scalability) and traffic intensity (horizontal scalability), we can better understand DiPTC effectiveness and resilience in handling rising
complexities. Analyzing these performance measures allows us to extract conclusions regarding the
adaptability and effectiveness of DiPTC in scenarios where the network experiences high demands,
providing valuable information for real-world deployment considerations.

**4.9.1 Impact of traffic intensity**

In this section, we will focus on the Intensive scenario to test DiPTC vertical scalability. First, we want to guarantee that employing DiPTC does not harm data collecting by introducing a spatial bias; a problem that might be immensely detrimental to the requirements of this application, particularly when using the round-robin transmission mode to convey the feedback message. In Fig. 4.5, we plotted the node activity at different intervals during the simulation for DiPTC round-robin mode. A green node implies that it is active. Note that each node is covered at least by two gateways. These results illustrate that messages submitted to the gateways come from all throughout the intended area, indicating that DiPTC multi-gateway can also provide a form of spatial load-balancing as in the mono-gateway scenario. We run both the round-robin and synchronous simulations using identical parameter configuration and spatial distribution. Even with synchronous DiPTC, the previous observations are still relevant. Since the prior observations for the synchronous DiPTC indicate no discernible differences, we will not be displaying its spatial distribution figures.

<figure><img src="image_42.png" /><figcaption>FIGURE 4.5: Spatial distribution of active nodes in the round-robin mode, 43200 min (1 month), INTENSIVE scenario - DiPTC config. (0.5, 0.5, 0.06).</figcaption></figure>

Fig. 4.6 illustrates the evolution of the number of collisions, sent and received packets, dead nodes, downlink, and uplink losses, in the case of the INTENSIVE scenario for the synchronous downlink transmission in multi-gateway DiPTC. In the latter, the results for DiPTC show multiple alternations between long transient and short stationary states. These oscillations are caused by instabilities brought by numerous variables, active node deaths, and collision. With an increasing number of gateways, the network benefits from improved coverage and redundancy. This expanded coverage allows nodes to have multiple gateway options for transmitting their data, reducing the probability of collisions during the uplink transmission process.
<figure><img src="image_43.png" /><figcaption>FIGURE 4.6: Traffic evolution in the INTENSIVE scenario for the synchronous mode.</figcaption></figure>

<figure><img src="image_44.png" /><figcaption>FIGURE 4.7: Zoom on the traffic evolution in the INTENSIVE scenario for DiPTC.</figcaption></figure>

In this scenario, we replicate a LoRaWAN configuration consisting of three gateways and a uniform distribution of 150 nodes across the area. With this gateway density, the chances of an end device successfully reaching at least one gateway without encountering a collision are enhanced. This reduction in collision probability contributes to a more reliable and efficient communication environment. Additionally, the presence of multiple gateways provides alternative paths for uplink transmissions, reducing the likelihood of losses due to interference, signal attenuation, or other environmental factors. Fig. 4.5 depicts how our synchronous DiPTC minimizes the probability of uplink and downlink losses, attributed to the well-distributed placement of gateways and nodes.

Fig. 4.7(a) displays a closer look at the traffic evolution in the Intensive scenario for DiPTC. In this illustration, a zoom effect has been applied to emphasize the details of the traffic changes. If we take a look at the traffic evolution in this figure, we notice that the number of packets received fluctuates at around 10 packets every minute with an error of at least one packet. The oscillation is triggered by the death of node 45 at 26350 min. Even in the presence of those fluctuations, our synchronous multi-gateway DiPTC adapts to the overall traffic of the network and converges with an acceptable margin of error, considering the high network traffic.

Fig. 4.8 illustrates the evolution of the number of collisions, sent and received packets, dead nodes, downlink, and uplink losses, in the case of the INTENSIVE scenario for the round-robin downlink transmission in multi-gateway DiPTC. As in the synchronous DiPTC, The results show multiple alternations between long transient and short stationary states. These oscillations are caused by active node deaths and collisions. As said previously the low probability of uplink losses is due to the number of gateways and their distribution. Compared to synchronous DiPTC, the number of collisions in this transmission mode is low. This is because only one gateway sends the feedback message, resulting in fewer nodes being granted permission to send messages compared to the synchronous mode where all gateways send the feedback message, allowing more nodes to compete. The other trigger of the
<figure><img src="image_45.png" /><figcaption>FIGURE 4.8: Traffic evolution in the INTENSIVE scenario for the round-robin mode.</figcaption></figure>

oscillations is the active node deaths Fig. 4.7(b). If we look at the traffic evolution in the zoomed area we notice that the number of packets received fluctuates at around 10 packets every minute with an error of at least one packet. These oscillations are triggered by the death of node 47-119-83-49 respectively at 26043-26248-26320-26370 min and the convergence is delayed by a few iterations. Nonetheless, considering the network density, our multi-gateway round-robin DiPTC converges with a tolerable degree of error.

<figure><img src="image_46.png" /><figcaption>FIGURE 4.9: Traffic evolution in the INTENSIVE scenario in LoRaWAN.</figcaption></figure>

Synchronous DiPTC and Round-robin DiPTC perform significantly better than LoRaWAN in the INTENSIVE scenario, as shown in Fig. 4.6, Fig. 4.8 and Fig. 4.9. Due to dead nodes, uplink losses, and collisions, LoRaWAN sees a decrease in global traffic. A reduction in collision probability is observed when compared to the mono-gateway LoRaWAN discussed earlier in the previous chapter. This benefit is attributed to the multi-gateway architecture. Furthermore, in this case, the maximum absolute error is 12, which means that at worst, 22 messages are received at the gateway. With network density taken into account, this error is rather big.

Finally, Fig. 4.10 and Fig. 4.11 shows the nodes traffic evolution in the INTENSIVE scenario respectively for synchronous and round-robin DiPTC and LoRaWAN. In DiPTC (Fig. 4.10), the traffic adaptation rate increases when the number of active node deaths increases, as expected. This expectation is based on the fact that our DiPTC algorithm takes into account the network dynamics when adjusting traffic, using the information conveyed in the binary feedback messages. While the message is binary, it offers nodes a general understanding of the traffic and network dynamics. Unlike LoRaWAN (Fig. 4.11), the average network traffic in DiPTC rises as the number of nodes dying accumulates. Because of a generally fair traffic distribution generation, LoRaWAN nevertheless experiences regular average network traffic even after nodes die out.
<figure><img src="image_47.png" /><figcaption>(A) Synchronous mode</figcaption></figure>

<figure><img src="image_48.png" /><figcaption>(B) Round-robin mode</figcaption></figure>

FIGURE 4.10: Nodes traffic evolution in the INTENSIVE scenario for the synchronous and the round-robin modes.

<figure><img src="image_49.png" /><figcaption>FIGURE 4.11: Nodes traffic evolution in the INTENSIVE scenario in LoRaWAN.</figcaption></figure>

<figure><img src="image_50.png" /><figcaption>FIGURE 4.12: Comparison of performance measures of DiPTC modes and LoRaWAN in the INTENSIVE scenario.</figcaption></figure>

Fig. 4.10(a) and Fig. 4.10(b) shows the nodes traffic evolution in the INTENSIVE scenario respectively for synchronous DiPTC and round-robin DiPTC. Fig. 4.10(a) illustrates a high frequency of nodes sending less than 3 messages each. By using the parameters (0.5,0.5,0.06) in a DiPTC, nine nodes can adjust their traffic. Through the use of synchronous mode, all nine nodes get feedback messages and adjust their traffic accordingly, increasing the contribution traffic of each node. This enhances the nodes traffic average curve spike amplitude. On the other hand, the frequency of nodes transmitting fewer than two messages each is more significant in Fig. 4.10(b), where the feedback message is sent by a single gateway. In a round-robin transmission mode where one out of the three gateways sends the feedback message, less than 9 nodes receive the feedback message. This lowers the traffic contribution from each node. As a result, the spike magnitude of the nodes traffic average curve is reduced boosting the number of nodes generating traffic.

Fig. 4.13 compares the error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for the round-robin and synchronous DiPTC and LoRaWAN. Fig. 4.13(a) represents the application error over time in the case of the INTENSIVE scenario, for the round-robin and synchronous DiPTC and LoRaWAN. The application error in round-robin DiPTC and synchronous DiPTC has lower values and frequencies than LoRaWAN. An application error of zero means that the application received exactly $k = 1$ measure. This indicates that our algorithm in both transmission modes can fulfill the demands of the application more often than LoRaWAN. Fig. 4.13(b) represents the duration of the transient regimes in the case of the INTENSIVE scenario, for the round-robin
<figure><img src="image_51.png" /><figcaption>FIGURE 4.13: Comparison of error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for round-robin and synchronous DiPTC and LoRaWAN.</figcaption></figure>

and synchronous DiPTC and LoRaWAN. Unlike round-robin and synchronous DiPTC, long transient regimes are more frequent in LoRaWAN. In addition, medium-long transient regimes are more common in round-robin DiPTC than in synchronous DiPTC. Because of the gateways coverage, an active node may not receive the feedback message in round-robin mode. The active nodes downlink message losses delay convergence, extending the transient regime duration.

<figure><img src="image_52.png" /></figure>

Fig. 4.12 shows the comparison of performance measures of DiPTC modes and LoRaWAN in the INTENSIVE scenario. In terms of success rate, our synchronous DiPTC and round-robin DiPTC exceed the LoRaWAN. Because of the number of gateways in the setup as well as the spatial distribution of nodes, the packet reception rate for DiPTC and LoRaWAN is high. However, LoRaWAN displays a longer network lifetime due to its average nature. This implies fairness in averages, distributing the general traffic across many nodes (as seen in Fig. 4.11), providing the network with a longer lifespan compared to DiPTC. In DiPTC, intense competition and prolonged frequent transient states contribute to energy consumption.

Fig. 4.14 compares the Success Rate in the INTENSIVE scenario while varying the number of nodes in the network, for round-Robin and Synchronous DiPTC. As we can see, the network lifetime grows with the number of nodes in the network in both transmission modes. We can also see that DiPTC round-robin has a longer network lifetime than Synchronous DiPTC. This is because in round-robin transmission, there are nodes that cannot receive data due to the chosen gateway coverage, so they cannot adapt their traffic, and those nodes gain energy, which keeps the network alive longer than in Synchronous DiPTC, where all nodes receive the feedback message.

Fig. 4.15 compares the Success Rate in the INTENSIVE scenario while varying the number of nodes in the network, for round-robin and Synchronous DiPTC. In both transmission modes, note
that the success rate increases with the number of nodes in the network. The Synchronous DiPTC has a greater success rate than the round-robin. Synchronous transmission increases the probability of sending precisely 10 messages per minute because every node receives the feedback message and modifies its traffic accordingly.

<figure><img src="image_53.png" /><figcaption>FIGURE 4.16: Comparison of the Packet Reception Rate under a different number of nodes, in the INTENSIVE scenario.</figcaption></figure>

Fig. 4.16 compares the packet reception rate in the INTENSIVE scenario while varying the number of nodes in the network, for round-robin and Synchronous DiPTC. The packet reception rate drops as the number of nodes in the network increases for both transmission modes. The probability of a collision increases with the number of nodes, which has a detrimental impact on the packet reception rate. In the round-robin mode, nodes lose their feedback message if they are not covered by the chosen gateway. Due to this feedback message loss, round-robin DiPTC has a lower packet reception rate. In fact, the node keeps on trafficking in the same manner as it did during the prior period when it loses its feedback message, which raises the probability of a collision and therefore reduces the packet reception rate.

In the INTENSIVE scenario, compared to LoRaWAN, in Both round-robin and synchronous transmission modes, we can achieve the goal of 10 messages each period of time $\Delta T = 1$ min within reasonable deadlines while maintaining a low number of collisions. The decision between employing synchronous DiPTC versus round-robin DiPTC results in a tradeoff between network lifetime, success rate, and packet reception rate.

### 4.9.2 Impact of the nodes scalability

To assess DiPTC horizontal scalability, we concentrate on the DENSE scenario in this section. In comparison with the INTENSIVE scenario, we reduced the traffic intensity and raised the number of nodes from 150 to 500. We reduced the node energy to 1J instead of 20J to save simulation time and memory.

Fig. 4.17, Fig. 4.18 and Fig. 4.19 display the traffic evolution in the Dense scenario for synchronous and round-robin modes and LoRa. Note in Fig. 4.17 and Fig. 4.18 that there is an alternation of transient and stationary states, with the former only lasting for a short time due node death and collisions. What this suggests is that DiPTC can quickly converge to the desired number of measurements, known as *K*, despite obstacles like fluctuating environments even in a near-death setup. As in the INTENSIVE scenario, the transient states are generally caused by issues including node death and collisions. Even if a node probability to receive the downlink is not favorable, our algorithm will continue to function as the node itself keeps the same traffic intensity until it hears back from the gateway. The reason we see a lot of long stationary states is because of our algorithm which provides stability and reduces collisions. The introduction of a multi-gateway architecture further enhances the reduction in collisions. In this scenario, there are fewer collisions in general because there is less traffic overall (since $K=1$). Despite
<figure><img src="image_54.png" /><figcaption>FIGURE 4.17: Traffic evolution in the DENSE scenario for the synchronous mode.</figcaption></figure>

<figure><img src="image_55.png" /><figcaption>FIGURE 4.18: Traffic evolution in the DENSE scenario for the round-robin mode.</figcaption></figure>

<figure><img src="image_56.png" /><figcaption>FIGURE 4.19: Traffic evolution in the DENSE scenario for LoRaWAN.</figcaption></figure>

the significant increase in the number of nodes, our approach can converge to the target number of measurements, *K*, and maintain stability for a considerable amount of time.

In comparison to synchronous DiPTC Fig. 4.17, the round-robin DiPTC oscillation amplitude is lower Fig. 4.18. This is because in this scenario, where traffic is minimal, requiring just one message per $\Delta T = 10min$, not receiving a downlink/feedback helps in reducing the number of packets received at the gateways. In LoRaWAN the downlink reception is costly in terms of energy. For this same reason, the round-robin DiPTC outlasts the synchronous DiPTC.

Figure 4.19 depicts the traffic evolution in the DENSE scenario for LoRaWAN. In contrast to DiPTC, the overall traffic in LoRaWAN experiences numerous oscillations attributed to high collision probabilities, node failures, and uplink losses. The LoRaWAN protocol, with its average fairness and the significant number of nodes in the network (500 nodes), exhibits an increase in the probability of collisions and uplink loss. In comparison to our approach, the LoRaWAN protocol underperforms.
<figure><img src="image_57.png" /><figcaption>FIGURE 4.20: Nodes traffic evolution in the DENSE scenario for the synchronous and round-robin modes.</figcaption></figure>

<figure><img src="image_58.png" /></figure>

<figure><img src="image_59.png" /><figcaption>FIGURE 4.21: Nodes traffic evolution in the DENSE scenario for LoRaWAN.</figcaption></figure>

<figure><img src="image_60.png" /><figcaption>FIGURE 4.22: Comparison of performance measures of DiPTC modes and LoRaWAN in the DENSE scenario.</figcaption></figure>

Finally, Fig. 4.20 and Fig. 4.21 show node traffic evolution in the DENSE scenario for LoRaWAN and DiPTC. It illustrates the necessity to have a frame transmission control in LoRaWAN especially when the number of nodes is important. We notice that contrary to LoRaWAN, the maximum number of packets that a node can send in DiPTC remains significantly small (1 message), although the number of nodes increases in the network (500). The maximum number of packets that a node may send in DiPTC is 2 times lower than LoRaWAN, and the network traffic average is generally smoother. This maximum is expected to be higher however, the reduction in node battery capacity (i.e. from 20J to 1J) in both setups has a positive impact (bias) on the LoRaWAN performance by decreasing the number of messages sent by the nodes. This can be contrasted with the mono-gateway setup, where the amplitude of node traffic averages higher initially and converges to a similar pattern observed here as the battery depletes.

Fig. 4.22 shows the comparison of performance measures of DiPTC modes and LoRaWAN in the DENSE scenario. In terms of success rate, our synchronous DiPTC and round-robin DiPTC exceed the LoRaWAN. Because of the number of gateways in the setup as well as the spatial distribution of nodes, the packet reception rate for DiPTC and LoRaWAN is high.

Fig. 4.23 compares the error frequency and transient regimes duration frequencies, in the DENSE scenario for the round-robin and synchronous DiPTC and LoRaWAN. Fig. 4.23(a) represents the application error over time in the case of the DENSE scenario, for the round-robin and synchronous DiPTC and LoRaWAN. The application error in round-robin DiPTC and synchronous DiPTC has lower
<figure><img src="image_61.png" /><figcaption>FIGURE 4.23: Comparison of error frequency and transient regimes duration frequencies, in the DENSE scenario for round-robin and synchronous DiPTC and LoRaWAN.</figcaption></figure>

values and frequencies than LoRaWAN. An application error of zero means that the application received exactly *k* = 1 measure. This indicates that our algorithm can fulfill the demands of the application more often than LoRaWAN. Fig. 4.23(b) represents the duration of the transient regimes in the case of the DENSE scenario, for the round-robin and synchronous DiPTC and LoRaWAN. Unlike round-robin and synchronous DiPTC, long transient regimes are more frequent in LoRaWAN.

## 4.10 Discussion

The benefits of using both the round-robin and synchronous DiPTC schemes are evident in their robust convergence results, showcasing their relevance not only in networks with a high number of nodes but also in scenarios with high traffic. This demonstrates a comprehensive enhancement in LPWAN performance, emphasizing the adaptability to meet diverse application requirements within a multi-gateway setup employing control traffic management. The stability of the adaptation algorithm allows our approach to converge reliably towards the required measurements (*K*), maintaining a respectable margin of absolute error. In a multi-gateway configuration, DiPTC efficiently manages and controls LoRaWAN traffic, demonstrating its capability to operate with low overhead and collision rates. This outlines the adaptability and efficiency of DiPTC in addressing real-world challenges in LPWANs, providing a balance between network lifetime, success rate, and packet reception rate, particularly when compared to synchronous DiPTC.

The round-robin DiPTC, by increasing the number of nodes contributing to traffic, enables diversified data collection, although introducing a tradeoff by raising collision probability. Yet, this comes with the advantage of conserving network energy and extending its overall lifetime. The selection between synchronous and round-robin DiPTC involves a nuanced consideration of these factors to respond to specific network and application priorities.

In comparison to synchronous DiPTC, the round-robin DiPTC extends the number of nodes contributing to traffic within a network. This, in turn, leads to more diverse data being collected. With the round-robin technique, the predefined gateway coverage determines that not all active nodes will receive the feedback message. The inability of certain nodes to obtain these feedback messages serves a dual purpose. On one hand, it helps in conserving network energy by preventing excessive power consumption. This energy preservation contributes to an extended overall network lifetime. However, on the other hand, this also raises the probability of collisions occurring within the network. As a consequence, both the packet reception rate and success rate stand to be negatively impacted.

The choice to implement either synchronous DiPTC or round-robin DiPTC introduces a tradeoff between three key factors: prolonging network lifetime, upholding a high success rate, and maintaining an efficient packet reception rate. It is necessary to carefully weigh these considerations if using DiPTC while designing or augmenting the network to optimize performance and efficiency.
The capability of DiPTC to achieve spatial load-balancing remains a standout feature, particularly accentuated in its multi-gateway adaptation, especially in the round-robin mode. In this mode, the competing nodes dynamically change with each round-robin gateway, distributing the traffic load more evenly across the network. This spatial load-balancing characteristic is important for optimizing resource utilization and ensuring that no single node or gateway is overwhelmed, contributing to enhanced network efficiency and durability. By dynamically shifting the nodes participating in the competition across gateways, DiPTC strategically manages the network traffic distribution, preventing congestion in specific areas and promoting a more balanced utilization of resources.

The introduction of multiple gateways in DiPTC significantly enhances its capability to reduce collisions and uplink losses in LoRaWANs compared to the mono-gateway DiPTC configuration. This enhancement is anticipated because the well-distributed placement of gateways within the network facilitates more effective data transmission from nodes to the network server. The redundancy feature of the multi-gateway architecture and the utilization play a crucial role in optimizing data transmission. In scenarios where one gateway experiences congestion or interference, the presence of alternative gateways minimizes the chances of collisions and uplink losses. As a result, the multi-gateway DiPTC configuration improves data transfer reliability and overall network performance in LoRaWAN deployments.

## 4.11 Conclusion

In this chapter we evaluate the performance of DiPTC (Distributed and Probabilistic Traffic Control), our proposed approach for efficiently managing traffic in LoRaWANs, especially in a multi-gateway setup. The fundamental goal of DiPTC is to achieve the convergence of application requirements, specifically in attaining a predetermined *K* number of measurements within a defined time interval. To regulate the traffic intensity, the gateways relay the feedback message sent by the network server to the nodes. Upon receiving this feedback, nodes dynamically adjust their traffic based on the information conveyed. To adapt the feedback message transmission to a multi-gateway scenario, we introduce two transmission modes: synchronous and round-robin. This adaptation allows us to explore and compare the performance of DiPTC under different transmission conditions in the context of diverse network configurations.

The performance assessment reveals that DiPTC excels in both synchronous and round-robin transmission modes, achieving the convergence of application requirements and minimizing collision risks within tolerable delays. However, the choice between these modes necessitates a careful consideration of the tradeoffs involved, including factors such as network lifetime, success rate, and packet reception rate. Each transmission mode presents a distinct set of advantages and compromises, highlighting the importance of selecting the mode that aligns with the specific objectives and constraints of the LoRaWAN application. Notably, our findings indicate that both synchronous and round-robin implementations of DiPTC outperform the conventional LoRaWAN approach. This underscores the efficacy of our proposed traffic control algorithm in enhancing the overall performance and efficiency of LoRaWANs in multi-gateway scenarios.
# Chapter 5

## General conclusions and future works

### Contents

<table><tr><td>5.1 Conclusions</td><td>79</td></tr><tr><td>5.2 Future Works</td><td>80</td></tr><tr><td>A.1 Simulation parameters</td><td>81</td></tr></table>

### 5.1 Conclusions

In this thesis, we introduced a new algorithm for traffic control in LPWANs, known as Distributed and Probabilistic Traffic Control (DiPTC). Employing an additive increase and multiplicative decrease algorithm along with a binary feedback message from gateways, DiPTC enables both network servers and applications to refine control over data collection in LPWANs. In instances where specific data requirements, such as K measurements over a designated time period, are required by an application, a central server initiates a control loop to enforce a traffic policy under these requirements. Nodes receive a downlink message from the central server, indicating whether the target was achieved or not, urging them to adjust their traffic intensity using a local algorithm without neighboring nodes knowledge.

This straightforward yet effective traffic control method yields good results. Our solution, DiPTC ensures the convergence of application requirements (K measurements per period) and mitigates collision risks within acceptable delays. Furthermore, DiPTC demonstrates a threefold increase in success rates over the Baseline LoRaWAN, offering a significant longevity advantage.

To provide a comprehensive perspective, we benchmarked DiPTC against the Centralized Optimal Traffic Control algorithm (COTraC). While COTraC exhibits superior performance due to its access to extensive network knowledge and the absence of a feedback message requirement, DiPTC outdoes in different aspects. Notably, DiPTC ensures network spatial load balancing, distributing traffic effectively across the network, a feature absent in COTraC. The decentralized nature of DiPTC enables adaptive and efficient traffic control, demonstarting its applicability in scenarios where network knowledge is limited. Our investigation also includes the study of the impact of DiPTC traffic control parameters on network behavior, accompanied by a discussion on parameter settings adjusted to specific application requirements.

We also evaluated the performance of DiPTC in a multi-gateway configuration, adapting the transmission of the feedback message to this scenario through two modes: the synchronous mode and the round-robin mode. In the synchronous mode, all network gateways simultaneously send the feedback message to the nodes within their coverage areas. On the other hand, in the round-robin mode, a single gateway exclusively transmits the feedback message, received only by nodes within its coverage. The selection of a new sending gateway occurs periodically through the round-robin method. The utilization of either mode involves a tradeoff between network lifetime, success rate, and packet reception rate. Moreover, the performance of synchronous DiPTC and round-robin DiTPC exceeds that of the Baseline LoRaWAN in both transmission modes.
## 5.2 Future Works

This work opens up various perspectives in the short-term and long-term:

**short-term.** We intend to advance the formalization of our existing model in the future by including sophisticated approaches, with a primary focus on using reinforcement learning approaches. These advanced approaches represent the next frontier in our pursuit of enhancing success rates and prolonging the network lifetime within the context of LPWANs. Reinforcement learning emerges as a pivotal element in our future work. As a subset of machine learning, reinforcement learning equips LPWAN nodes with the ability to learn and adapt based on real-time experiences. This transformative approach holds the promise of creating self-optimizing LPWANs capable of making intelligent decisions in dynamic and evolving network scenarios. By enabling nodes to learn from feedback and adjust their behaviors autonomously, reinforcement learning contributes to the overall adaptability and responsiveness of LPWANs. In our specific context, we can direct our attention to the application of reinforcement learning in optimizing the parameters of DiPTC. This optimization problem, crucial for the efficient functioning of DiPTC in LPWANs, can be formulated within the reinforcement learning framework. To tackle this challenge, we can employ algorithms such as ε-greedy [123], [124] and Upper Confidence Bound (UCB) [125], [126], which are recognized strategies for addressing exploration-exploitation trade-offs in reinforcement learning scenarios. The application of these algorithms has already yielded preliminary results, marking a significant discovery in our research attempt. These preliminary findings will undergo further in-depth investigation, and we plan to publish the comprehensive outcomes soon, bringing new perspectives to the growing environment of LPWAN traffic control approaches.

**Long-term.** A potential area for future advancement is enhancing the LoRasim [112] simulator to include downlink communication features. This development seeks to create a more extensive simulation environment that accurately represents the bidirectional communication in LoRaWAN networks. By incorporating downlink abilities into the simulator, we hope to improve its ability to mimic the full communication dynamics. This will offer us a more realistic and useful tool for evaluating our DiPTC algorithm performance. This potential enhancement aligns with our ongoing simulation methodology advancements, allowing for a more detailed examination of network behaviors and promoting a deeper understanding of DiPTC communication patterns.

In our approach, we assumed that the gateways are capable of sending the downlink feedback message in a broadcast or multicast mode. However, this assumption is an intriguing open question LoRaWAN. In addition to simulator enhancements, as part of future work, we aim to solve the complexities surrounding how downlink messages can be efficiently disseminated to multiple nodes simultaneously. Through this investigation, we aspire to develop innovative solutions that not only address the current gap in knowledge but also unlock new dimensions of scalability, efficiency, and network management within LoRaWAN.

Another future goal is to transition from simulation-based assessments to real-world deployments. The shift towards experimentation on a real platform is driven by the need to bridge the gap between theoretical simulations and practical applications, ensuring that the proposed DiPTC algorithm manifests its efficacy in realistic environments. Implementing DiPTC on a real platform will involve deploying LPWAN nodes and gateways in a physical setting, allowing us to evaluate its behavior under genuine network conditions. This transition to real-world experimentation is a crucial step in validating the robustness, adaptability, and overall effectiveness of DiPTC, paving the way for its potential integration into operational LPWAN systems and further contributing to the advancement of traffic control methodologies in Low Power Wide Area Networks.
# Appendix A

## A.1 Simulation parameters

<table><caption>TABLE A.1: LoRa parameters for the BASIC and INTENSE scenarios.</caption><thead><tr><td>(SF, BW, CR, Freq)</td><td>Number of nodes</td></tr></thead><tbody><tr><td>(9, 500, 3, 868000000)</td><td>1</td></tr><tr><td>(11, 250, 3, 868000000)</td><td>1</td></tr><tr><td>(12, 250, 3, 868000000)</td><td>4</td></tr><tr><td>(11, 125, 2, 868000000)</td><td>2</td></tr><tr><td>(6, 500, 4, 868000000)</td><td>3</td></tr><tr><td>(6, 125, 4, 868000000)</td><td>2</td></tr><tr><td>(8, 500, 1, 868000000)</td><td>2</td></tr><tr><td>(8, 125, 4, 868000000)</td><td>1</td></tr><tr><td>(10, 250, 3, 868000000)</td><td>2</td></tr><tr><td>(12, 250, 4, 868000000)</td><td>1</td></tr><tr><td>(10, 250, 2, 868000000)</td><td>2</td></tr><tr><td>(10, 500, 3, 868000000)</td><td>4</td></tr><tr><td>(11, 250, 4, 868000000)</td><td>1</td></tr><tr><td>(10, 250, 1, 868000000)</td><td>1</td></tr><tr><td>(10, 500, 2, 868000000)</td><td>2</td></tr><tr><td>(9, 500, 1, 868000000)</td><td>1</td></tr><tr><td>(10, 500, 1, 868000000)</td><td>1</td></tr><tr><td>(9, 125, 2, 868000000)</td><td>4</td></tr><tr><td>(6, 500, 1, 868000000)</td><td>1</td></tr><tr><td>(9, 500, 2, 868000000)</td><td>1</td></tr><tr><td>(11, 125, 4, 868000000)</td><td>2</td></tr><tr><td>(12, 500, 3, 868000000)</td><td>1</td></tr><tr><td>(11, 250, 1, 868000000)</td><td>1</td></tr><tr><td>(12, 125, 3, 868000000)</td><td>2</td></tr><tr><td>(9, 125, 4, 868000000)</td><td>1</td></tr><tr><td>(12, 250, 2, 868000000)</td><td>3</td></tr><tr><td>(12, 125, 2, 868000000)</td><td>3</td></tr><tr><td>(11, 500, 2, 868000000)</td><td>1</td></tr><tr><td>(9, 500, 4, 868000000)</td><td>2</td></tr><tr><td>(8, 250, 2, 868000000)</td><td>2</td></tr><tr><td>(11, 500, 3, 868000000)</td><td>4</td></tr><tr><td>(11, 250, 2, 868000000)</td><td>3</td></tr><tr><td>(9, 250, 3, 868000000)</td><td>3</td></tr><tr><td>(8, 500, 3, 868000000)</td><td>6</td></tr><tr><td>(9, 250, 4, 868000000)</td><td>3</td></tr></tbody></table>

<table><thead><tr><td>(SF, BW, CR, Freq)</td><td>Number of nodes</td></tr></thead><tbody><tr><td>(12, 125, 1, 868000000)</td><td>3</td></tr><tr><td>(7, 250, 1, 868000000)</td><td>2</td></tr><tr><td>(7, 250, 2, 868000000)</td><td>2</td></tr><tr><td>(7, 250, 3, 868000000)</td><td>2</td></tr><tr><td>(10, 125, 1, 868000000)</td><td>1</td></tr><tr><td>(10, 250, 4, 868000000)</td><td>1</td></tr><tr><td>(9, 125, 3, 868000000)</td><td>1</td></tr><tr><td>(7, 250, 4, 868000000)</td><td>1</td></tr><tr><td>(10, 125, 2, 868000000)</td><td>1</td></tr><tr><td>(9, 250, 1, 868000000)</td><td>5</td></tr><tr><td>(11, 500, 4, 868000000)</td><td>5</td></tr><tr><td>(6, 125, 2, 868000000)</td><td>1</td></tr><tr><td>(7, 500, 2, 868000000)</td><td>1</td></tr><tr><td>(7, 500, 4, 868000000)</td><td>2</td></tr><tr><td>(8, 500, 4, 868000000)</td><td>2</td></tr><tr><td>(9, 125, 1, 868000000)</td><td>2</td></tr><tr><td>(7, 125, 3, 868000000)</td><td>3</td></tr><tr><td>(8, 250, 1, 868000000)</td><td>2</td></tr><tr><td>(11, 125, 1, 868000000)</td><td>1</td></tr><tr><td>(6, 250, 4, 868000000)</td><td>1</td></tr><tr><td>(7, 500, 3, 868000000)</td><td>2</td></tr><tr><td>(7, 125, 4, 868000000)</td><td>2</td></tr><tr><td>(8, 500, 2, 868000000)</td><td>1</td></tr><tr><td>(8, 250, 3, 868000000)</td><td>2</td></tr><tr><td>(10, 500, 4, 868000000)</td><td>5</td></tr><tr><td>(8, 125, 2, 868000000)</td><td>1</td></tr><tr><td>(6, 250, 2, 868000000)</td><td>2</td></tr><tr><td>(7, 500, 1, 868000000)</td><td>3</td></tr><tr><td>(8, 125, 3, 868000000)</td><td>2</td></tr><tr><td>(12, 500, 4, 868000000)</td><td>1</td></tr><tr><td>(12, 500, 2, 868000000)</td><td>3</td></tr><tr><td>(12, 250, 1, 868000000)</td><td>3</td></tr><tr><td>(6, 500, 3, 868000000)</td><td>1</td></tr><tr><td>(6, 500, 2, 868000000)</td><td>1</td></tr><tr><td>(6, 125, 1, 868000000)</td><td>6</td></tr><tr><td>(8, 125, 1, 868000000)</td><td>2</td></tr></tbody></table>
<table><caption>TABLE A.2: LoRa parameters for the DENSE scenario.</caption><thead><tr><td>(SF, BW, CR, Freq)</td><td>Number of nodes</td></tr></thead><tbody><tr><td>(9, 500, 3, 868000000)</td><td>2</td></tr><tr><td>(11, 250, 3, 868000000)</td><td>4</td></tr><tr><td>(12, 250, 3, 868000000)</td><td>9</td></tr><tr><td>(11, 125, 2, 868000000)</td><td>4</td></tr><tr><td>(6, 500, 4, 868000000)</td><td>4</td></tr><tr><td>(6, 125, 4, 868000000)</td><td>3</td></tr><tr><td>(8, 500, 1, 868000000)</td><td>6</td></tr><tr><td>(8, 125, 4, 868000000)</td><td>2</td></tr><tr><td>(10, 125, 4, 868000000)</td><td>7</td></tr><tr><td>(10, 250, 3, 868000000)</td><td>7</td></tr><tr><td>(12, 250, 4, 868000000)</td><td>9</td></tr><tr><td>(10, 250, 2, 868000000)</td><td>5</td></tr><tr><td>(10, 500, 3, 868000000)</td><td>9</td></tr><tr><td>(11, 250, 4, 868000000)</td><td>5</td></tr><tr><td>(10, 250, 1, 868000000)</td><td>6</td></tr><tr><td>(10, 500, 2, 868000000)</td><td>9</td></tr><tr><td>(9, 500, 1, 868000000)</td><td>5</td></tr><tr><td>(10, 500, 1, 868000000)</td><td>8</td></tr><tr><td>(9, 125, 2, 868000000)</td><td>8</td></tr><tr><td>(6, 500, 1, 868000000)</td><td>3</td></tr><tr><td>(9, 500, 2, 868000000)</td><td>4</td></tr><tr><td>(11, 125, 4, 868000000)</td><td>4</td></tr><tr><td>(12, 500, 3, 868000000)</td><td>4</td></tr><tr><td>(11, 250, 1, 868000000)</td><td>11</td></tr><tr><td>(12, 125, 3, 868000000)</td><td>10</td></tr><tr><td>(9, 125, 4, 868000000)</td><td>7</td></tr><tr><td>(12, 250, 2, 868000000)</td><td>6</td></tr><tr><td>(12, 125, 2, 868000000)</td><td>6</td></tr><tr><td>(12, 500, 1, 868000000)</td><td>4</td></tr><tr><td>(11, 500, 2, 868000000)</td><td>1</td></tr><tr><td>(9, 500, 4, 868000000)</td><td>6</td></tr><tr><td>(8, 250, 2, 868000000)</td><td>3</td></tr><tr><td>(11, 500, 3, 868000000)</td><td>6</td></tr><tr><td>(11, 250, 2, 868000000)</td><td>10</td></tr><tr><td>(9, 250, 3, 868000000)</td><td>9</td></tr><tr><td>(8, 500, 3, 868000000)</td><td>10</td></tr><tr><td>(9, 250, 4, 868000000)</td><td>4</td></tr><tr><td>(12, 125, 1, 868000000)</td><td>5</td></tr><tr><td>(7, 250, 1, 868000000)</td><td>7</td></tr><tr><td>(11, 500, 1, 868000000)</td><td>5</td></tr><tr><td>(10, 125, 3, 868000000)</td><td>3</td></tr></tbody></table>

<table><thead><tr><td>(SF, BW, CR, Freq)</td><td>Number of nodes</td></tr></thead><tbody><tr><td>(7, 125, 2, 868000000)</td><td>5</td></tr><tr><td>(7, 250, 2, 868000000)</td><td>6</td></tr><tr><td>(9, 250, 2, 868000000)</td><td>6</td></tr><tr><td>(7, 125, 1, 868000000)</td><td>5</td></tr><tr><td>(7, 250, 3, 868000000)</td><td>3</td></tr><tr><td>(10, 125, 1, 868000000)</td><td>3</td></tr><tr><td>(10, 250, 4, 868000000)</td><td>13</td></tr><tr><td>(9, 125, 3, 868000000)</td><td>6</td></tr><tr><td>(7, 250, 4, 868000000)</td><td>4</td></tr><tr><td>(12, 125, 4, 868000000)</td><td>7</td></tr><tr><td>(10, 125, 2, 868000000)</td><td>5</td></tr><tr><td>(11, 125, 3, 868000000)</td><td>10</td></tr><tr><td>(9, 250, 1, 868000000)</td><td>9</td></tr><tr><td>(6, 125, 3, 868000000)</td><td>10</td></tr><tr><td>(11, 500, 4, 868000000)</td><td>7</td></tr><tr><td>(6, 125, 2, 868000000)</td><td>5</td></tr><tr><td>(7, 500, 2, 868000000)</td><td>11</td></tr><tr><td>(7, 500, 4, 868000000)</td><td>5</td></tr><tr><td>(8, 500, 4, 868000000)</td><td>6</td></tr><tr><td>(6, 250, 1, 868000000)</td><td>4</td></tr><tr><td>(9, 125, 1, 868000000)</td><td>6</td></tr><tr><td>(7, 125, 3, 868000000)</td><td>7</td></tr><tr><td>(8, 250, 1, 868000000)</td><td>5</td></tr><tr><td>(11, 125, 1, 868000000)</td><td>6</td></tr><tr><td>(6, 250, 4, 868000000)</td><td>6</td></tr><tr><td>(7, 500, 3, 868000000)</td><td>12</td></tr><tr><td>(7, 125, 4, 868000000)</td><td>6</td></tr><tr><td>(6, 250, 3, 868000000)</td><td>3</td></tr><tr><td>(8, 500, 2, 868000000)</td><td>3</td></tr><tr><td>(8, 250, 3, 868000000)</td><td>6</td></tr><tr><td>(10, 500, 4, 868000000)</td><td>7</td></tr><tr><td>(8, 125, 2, 868000000)</td><td>3</td></tr><tr><td>(6, 250, 2, 868000000)</td><td>10</td></tr><tr><td>(7, 500, 1, 868000000)</td><td>6</td></tr><tr><td>(8, 125, 3, 868000000)</td><td>6</td></tr><tr><td>(12, 500, 4, 868000000)</td><td>2</td></tr><tr><td>(12, 500, 2, 868000000)</td><td>5</td></tr><tr><td>(12, 250, 1, 868000000)</td><td>8</td></tr><tr><td>(6, 500, 3, 868000000)</td><td>3</td></tr><tr><td>(6, 500, 2, 868000000)</td><td>2</td></tr><tr><td>(6, 125, 1, 868000000)</td><td>11</td></tr><tr><td>(8, 250, 4, 868000000)</td><td>3</td></tr><tr><td>(8, 125, 1, 868000000)</td><td>4</td></tr></tbody></table>
Bibliographie

[1] A. A. LAGHARI, K. WU, R. A. LAGHARI, M. ALI & A. A. KHAN, ?A review and state of art of Internet of Things (IoT),? *Archives of Computational Methods in Engineering*, Springer, 2021.

[2] Y. B. ZIKRIA, R. ALI, M. K. AFZAL & S. W. KIM, ?Next-generation internet of things (iot): Opportunities, challenges, and solutions,? *Sensors*, 2021.

[3] S. BALAJI, K. NATHANI & R. SANTHAKUMAR, ?IoT technology, applications and challenges: a contemporary survey,? *Wireless personal communications*, Springer, 2019.

[4] F. MONTORI, L. BEDOGNI, M. DI FELICE & L. BONONI, ?Machine-to-machine wireless communication technologies for the Internet of Things: Taxonomy, comparison and open issues,? *Pervasive and Mobile Computing*, Elsevier, 2018.

[5] H. WANG & A. O. FAPOJUWO, ?A survey of enabling technologies of low power and long-range machine-to-machine communications,? *Communications Surveys & Tutorials*, IEEE, 2017.

[6] A. ALI, G. A. SHAH, M. O. FAROOQ & U. GHANI, ?Technologies and challenges in developing machine-to-machine applications: A survey,? *Journal of Network and Computer Applications*, Elsevier, 2017.

[7] LPWANs Vs other technologies, https://www.molukas.com/tecnologias/.

[8] P. SPADACCINO, F. G. CRINÓ & F. CUOMO, ?LoRaWAN Behaviour Analysis through Dataset Traffic Investigation,? *Sensors*, MDPI, 2022.

[9] M. JOUHARI, N. SAEED, M.-S. ALOUINI & E. M. AMHOUD, ?A survey on scalable LoRaWAN for massive IoT: Recent advances, potentials, and challenges,? *Communications Surveys & Tutorials*, IEEE, 2023.

[10] M. A. ALMUHAYA, W. A. JABBAR, N. SULAIMAN & S. ABDULMALEK, ?A survey on Lorawan technology: Recent trends, opportunities, simulation tools, and future directions,? *Electronics*, MDPI, 2022.

[11] C. GU, L. JIANG & R. TAN, ?Lora-based localization: Opportunities and challenges,? *ArXiv Preprint ArXiv:1812.11481*, 2018.

[12] Lora alliance homepage, https://lora-alliance.org/.

[13] Weightless alliance, https://www weightless-alliance org/.

[14] W. WEBB, 'Understanding weightless: technology, equipment, and network deployment for M2M communications in white space,' Cambridge University Press, 2012.

[15] G. A. AKPAKWU, B. J. SILVA, G. P. HANCKE & A. M. ABU-MAHFOUZ, ?A survey on 5G networks for the Internet of Things: Communication technologies and challenges,? *Access*, IEEE, 2017.

[16] S.-Y. WANG, J.-E. CHANG, H. FAN & Y.-H. SUN, ?Performance comparisons of NB-IoT, LTE Cat-M1, Sigfox, and LoRa moving at high speeds in the air,? *Symposium on Computers and Communications (ISCC)*, IEEE, 2020.

[17] M. IQBAL, A. Y. M. ABDULLAH & F. SHABNAM, ?An application-based comparative study of LPWAN technologies for IoT environment,? *Region 10 Symposium (TENSYMP)*, IEEE, 2020.

[18] A. IKPEHAI, B. ADEBISI, K. M. RABIE et al., ?Low-power wide area network technologies for Internet-of-Things: A comparative review,? *Internet of Things Journal*, IEEE, 2018.
[19] K. MEKKI, F. BAJIC E.and Chaxel & F. MEYER, ?A comparative study of LPWAN technologies for large-scale IoT deployment,? *ICT express*, 2019.

[20] D. ISMAIL, M. RAHMAN & A. SAIFULLAH, ?Low-power wide-area networks: opportunities, challenges, and directions,? *Proceedings of the Workshop Program of the Int Conf on Distributed Computing and Networking (ICDCN)*, Springer, 2018.

[21] S. LI, U. RAZA & A. KHAN, ?How agile is the adaptive data rate mechanism of LoRaWAN?? *Global Communications Conference (GLOBECOM)*, IEEE, 2018.

[22] U. RAZA, P. KULKARNI & M. SOORIYABANDARA, ?Low power wide area networks: An overview,? *Communications Surveys & Tutorials*, IEEE, 2017.

[23] A. PETRONI, F. CUOMO, L. SCHEPIS, M. BIAGI, M. LISTANTI & G. SCARANO, ?Adaptive data synchronization algorithm for iot-oriented low-power wide-area networks,? *Sensors*, MDPI, 2018.

[24] V. P. MODEKURTHY, D. ISMAIL, M. RAHMAN & A. SAIFULLAH, ?Low-latency in-band integration of multiple low-power wide-area networks,? *Real-Time and Embedded Technology and Applications Symposium (RTAS)*, IEEE, 2021.

[25] O. GEORGIOU & U. RAZA, ?Low power wide area network analysis: Can LoRa scale?? *Wireless Communications Letters*, IEEE, 2017.

[26] M. RAHMAN & P. B. GOALA, ?Enabling Massive Scalability in Low-Power Wide-Area Networks,? *Int Conf on High Performance Computing & Communications; Int Conf on Data Science & Systems; Int Conf on Smart City; Int Conf on Dependability in Sensor, Cloud & Big Data Systems & Application (HPCC/DSS/SmartCity/DependSys)*, IEEE, 2022.

[27] J. FADEYI & M. ELISHA, ?Spectrum Optimization of Low Power Wide Area Network Utilization in Smart Cities,? *Int Conf on Intelligent and Innovative Computing Applications (Iconic)*, Springer, 2022.

[28] G. PATHAK, J. GUTIERREZ & S. U. REHMAN, ?Security in low powered wide area networks: Opportunities for software-defined network-supported solutions,? *Electronics*, MDPI, 2020.

[29] D. BASU, T. GU & P. MOHapatra, ?Security issues of low power wide area networks in the context of LoRa networks,? *arXiv preprint arXiv:2006.16554*, 2020.

[30] K. SUN, Z. YIN, W. CHEN, S. WANG, Z. ZHANG & T. HE, ?Partial symbol recovery for interference resilience in low-power wide area networks,? *Int Conf on Network Protocols (ICNP)*, IEEE, 2021.

[31] J. ROBERT, S. RAUH, H. LIESKE & A. HEUBERGER, ?IEEE 802.15 low power wide area network (LPWAN) PHY interference model,? *Int Conf on Communications (ICC)*, IEEE, 2018.

[32] C. PHAM, A. BOUNCEUR, L. CLAVIER, U. NOREEN & M. EHSAN, ?Radio channel access challenges in LoRa low-power wide-area networks,? *LPWAN Technologies for IoT and M2M Applications*, Elsevier, 2020.

[33] H. ABOLMAGD, R. SUBBARAMAN, O. ESMAEELI et al., ?A Hierarchical Self-Interference Canceller for Full-Duplex LPWAN Applications Achieving 52–70-dB RF Cancellation,? *Journal of Solid-State Circuits*, IEEE, 2022.

[34] E. DE POORTER, J. HOEBEKE, M. STROBBE et al., ?Sub-GHz LPWAN network coexistence, management and virtualization: an overview and open research challenges,? *Wireless Personal Communications*, Springer, 2017.

[35] J. ORTÍN, M. CESANA & A. REDONDI, ?Augmenting LoRaWAN performance with listen before talk,? *Transactions on Wireless Communications*, IEEE, 2019.

[36] L. LEONARDI, L. LO BELLO, F. BATTAGLIA & G. PATTI, ?Comparative assessment of the LoRaWAN medium access control protocols for IoT: Does listen before talk perform better than ALOHA?,? *Electronics*, MDPI, 2020.
[37] N. ABRAMSON, ?The aloha system: another alternative for computer communications,? *AFIPS*, 1970.

[38] Z. CHANG, F. ZHANG, J. XIONG, J. MA, B. JIN & D. ZHANG, ?Sensor-free soil moisture sensing using lora signals,? *Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies*, ACM, 2022.

[39] D. KIV, G. ALLABADI, B. KAPLAN & R. KRAVETS, ?smol: Sensing soil moisture using lora,? *Proceedings of the 1st ACM Workshop on No Power and Low Power Internet-of-Things*, ACM, 2022.

[40] J. LLORET, S. SENDRA, L. GARCIA & J. M. JIMENEZ, ?A wireless sensor network deployment for soil moisture monitoring in precision agriculture,? *Sensors*, MDPI, 2021.

[41] M. LIYA & D. ARJUN, ?A survey of LPWAN technology in agricultural field,? *Int Conf IoT in Social, Mobile, Analytics and Cloud (I-SMAC)*, 2020.

[42] A. HOGLUND, X. LIN, O. LIBERG et al., ?Overview of 3GPP release 14 enhanced NB-IoT,? *Network, IEEE*, 2017.

[43] B. S. CHAUDHARI & M. ZENNARO, *LPWAN Technologies for IoT and M2M Applications*. Academic Press, 2020.

[44] R. RATASUK, B. VEJLGAARD, N. MANGALVEDHE & A. GHOSH, ?NB-IoT system for M2M communication,? *wireless communications and networking conference (WCNC)*, IEEE, 2016.

[45] B. S. CHAUDHARI, M. ZENNARO & S. BORKAR, ?LPWAN technologies: Emerging application characteristics, requirements, and design considerations,? *Future Internet*, MDPI, 2020.

[46] M. EL SOUSSI, P. ZAND, F. PASVEER & G. DOLMANS, ?Evaluating the performance of eMTC and NB-IoT for smart city applications,? *Int Conf on Communications (ICC)*, IEEE, 2018.

[47] M. DANGANA, S. ANSARI, Q. H. ABBASI, S. HUSSAIN & M. A. IMRAN, ?Suitability of NB-IoT for indoor industrial environment: A survey and insights,? *Sensors*, MDPI, 2021.

[48] S. K. SHARMA & X. WANG, ?Toward massive machine type communications in ultra-dense cellular IoT networks: Current issues and machine learning-assisted solutions,? *Communications Surveys & Tutorials*, IEEE, 2019.

[49] A. J. WIXTED, P. KINNAIRD, H. LARIJANI, A. TAIT, A. AHMADINIA & N. STRACHAN, ?Evaluation of LoRa and LoRaWAN for wireless sensor networks,? *SENSORS*, IEEE, 2016.

[50] D. CROCE, M. GUCCIARDO, S. MANGIONE, G. SANTAROMITA & I. TINNIRELLO, ?Impact of LoRa imperfect orthogonality: Analysis of link-level performance,? *Communications Letters*, IEEE, 2018.

[51] N. SORNIN, E. L. M., T. KRAMP & O. HERSENT, ?LoRaWAN specification,? *LoRa Alliance*, 2015.

[52] INGENU, *How Rpma Works the Making of RPMA 2016*. https://www.ingenu.com/portfolio/how-rpma-works-the-making-of-rpma/doing WP cron=1704327558.5411989688873291015625.

[53] J. P. QUERALTA, T. N. GIA, Z. ZOU, H. TENHUNEN & T. WESTERLUND, ?Comparative study of LPWAN technologies on unlicensed bands for M2M communication in the IoT: Beyond LoRa and LoRaWAN,? *Procedia Computer Science*, Elsevier, 2019.

[54] P. MASEK, E. YOUNESIAN, M. BAHNA et al., ?Performance Analysis of Different LoRaWAN Frequency Bands for mMTC Scenarios,? *Int Conf on Telecommunications and Signal Processing (TSP)*, IEEE, 2022.

[55] M. BALLERINI, T. POLONELLI, D. BRUNELLI, M. MAGNO & L. BENINI, ?NB-IoT versus LoRaWAN: An experimental evaluation for industrial applications,? *Transactions on Industrial Informatics*, IEEE, 2020.
[56] A. LOMBARDO, S. PARRINO, G. PERUZZI & A. POZZEBON, ?LoRaWAN versus NB-IoT: Transmission performance analysis within critical environments,? *Internet of Things Journal*, IEEE, 2021.

[57] K. MEKKI, E. BAJIC, F. CHAXEL & F. MEYER, ?Overview of cellular LPWAN technologies for IoT deployment: Sigfox, LoRaWAN, and NB IoT,? *Int Conf on pervasive computing and communications workshops (percom workshops)*, IEEE, 2018.

[58] C. MILAROKOSTAS, D. TSOLKAS, N. PASSAS & L. MERAKOS, ?A comprehensive study on LPWANs with a focus on the potential of LoRa/LoRaWAN systems,? *Communications Surveys & Tutorials, IEEE*, 2022.

[59] N. JEFTENIĆ, M. SIMIĆ & Z. STAMENKOVIĆ, ?Impact of Environmental Parameters on SNR and RSS in LoRaWAN,? *Int Conf on Electrical, Communication, and Computer Engineering (ICECCE)*, IEEE, 2020.

[60] U. NOREEN, A. BOUNCEUR & L. CLAVIER, ?A study of LoRa low power and wide area network technology,? *Int Conf on Advanced Technologies for Signal and Image Processing (ATSIP)*, IEEE, 2017.

[61] P. MASEK, M. STUSEK, E. SVERTOKA et al., ?Measurements of LoRaWAN technology in urban scenarios: A data descriptor,? *Data, MDPI*, 2021.

[62] SEMTECH, ?LoRaTM Modulation Basics,? *Application Note AN1200.22*, 2015.

[63] K. MIKHAYLOV, J. PETAEJAEJAERVI & T. HAENNINEN, ?Analysis of capacity and scalability of the LoRa low power wide area network technology,? VDE, 2016.

[64] L. ALLIANCE, *LoRaWAN Regional Parameters, Technical Specification RP002-1.0.3*, 2021.

[65] M. BOR & U. ROEDIG, ?LoRa transmission parameter selection,? *International Conference on Distributed Computing in Sensor Systems (DCOSS)*, 2017.

[66] *Lora Calculator*, https://www.semtech.com/design-support/lora-calculator.

[67] A. YEGIN, T. KRAMP, P. DUFOUR et al., ?LoRaWAN protocol: specifications, security, and capabilities,? *LPWAN Technologies for IoT and M2M applications*, Elsevier, 2020.

[68] V. HAUSER & T. HÉGR, ?Proposal of adaptive data rate algorithm for LoRaWAN-based infrastructure,? *Int Conf on Future Internet of Things and Cloud (FiCloud)*, IEEE, 2017.

[69] J. FINNEGAN, R. FARRELL & S. BROWN, ?Analysis and enhancement of the LoRaWAN adaptive data rate scheme,? *IEEE Internet of Things Journal*, IEEE, 2020.

[70] R. KUFAKUNESU, G. P. HANCKE & A. M. ABU-MAHFOUZ, ?A survey on adaptive data rate optimization in lorawan: Recent solutions and major challenges,? *Sensors*, MDPI, 2020.

[71] E. RECOMMENDATION, ?ERC Recommendation 70-03 Relating to the Use of Short Range Devices (SRD),? *ERC/REC*, 2009.

[72] J. ORTÍN, M. CESANA & A. REDONDI, ?How do ALOHA and listen before talk coexist in LoRaWAN?? *International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC)*, IEEE, 2018.

[73] N. MATNI, J. MORAES, H. OLIVEIRA, D. ROSÁRIO & E. CERQUEIRA, ?LoRaWAN gateway placement model for dynamic Internet of Things scenarios,? *Sensors*, MDPI, 2020.

[74] L. LEONARDI, L. LO BELLO, G. PATTI, A. PIRRI & M. PIRRI, ?Simulative Assessment of the Listen before Talk Adaptive Frequency Agility Medium Access Control Protocol for LoRaWAN Networks in IoT Scenarios,? *Applied System Innovation*, MDPI, 2023.

[75] D. CASTELLS-RUFAS, A. GALIN-PONS & J. CARRABINA, ?The regulation of unlicensed sub-GHz bands: Are stronger restrictions required for LPWAN-based IoT success,? *arXiv preprint arXiv:1812.00031*, 2018.
[76] K. TA D. T. & AL, ?LoRa-MAB: a flexible simulator for decentralized learning resource allocation in IoT networks,? *Wireless and Mobile Networking Conference (WMNC), IEEE*, 2019.

[77] K. Q. ABDELFADEEL, D. ZORBAS, V. CIONCA & D. PESCH, ?Free-fine-grained scheduling for reliable and energy-efficient data collection in LoRaWAN,? *Internet of Things Journal*, IEEE, 2020.

[78] J. BABAKI, M. RASTI & R. ASLANI, ?Dynamic spreading factor and power allocation of LoRa networks for dense IoT deployments,? *International symposium on personal, indoor and mobile radio communications (PIMRC)*, IEEE, 2020.

[79] F. CUOMO, M. CAMPO, A. CAPONI, G. BIANCHI, G. ROSSINI & P. PISANI, ?EXPLORa: Extending the performance of LoRa by suitable spreading factor allocations,? *13th Int Conf on Wireless and Mobile Computing, Networking and Communications (WiMob)*, IEEE, 2017.

[80] F. CUOMO, J. C. C. GÁMEZ, A. MAURIZIO et al., ?Towards traffic-oriented spreading factor allocations in LoRaWAN systems,? *17th annual mediterranean ad hoc networking workshop (Med-Hoc-Net)*, IEEE, 2018.

[81] J. MORAES, N. MATNI, A. RIKER et al., ?An efficient heuristic LoRaWAN adaptive resource allocation for IoT applications,? *Symposium on Computers and Communications (ISCC)*, IEEE, 2020.

[82] M. I. ARASU, S. S. RANI & G. R. GEOFFERY, ?Efficient Heuristic for Optimal MILP-LoRa Adaptive Resource Allocation for Aquaculture.,? *Intelligent Automation & Soft Computing, Taylor and Francis Ltd*, 2022.

[83] M. EL-AASSER, T. ELSHABRAWY & M. ASHOUR, ?Joint spreading factor and coding rate assignment in LoRaWAN networks,? *Global conference on internet of things (GCIoT)*, IEEE, 2018.

[84] D. ZORBAS, G. Z. PAPADOPOULOS, P. MAILLE, N. MONTAVONT & C. DOULIGERIS, ?Improving LoRa network capacity using multiple spreading factor configurations,? *25th Int Conf on Telecommunications (ICT)*, IEEE, 2018.

[85] Y. A. AL-GUMAEI, N. ASLAM, X. CHEN, M. RAZA & R. I. ANSARI, ?Optimizing power allocation in LoRaWAN IoT applications,? *Internet of Things Journal*, IEEE, 2021.

[86] K. Q. ABDELFADEEL, V. CIONCA & D. PESCH, ?Fair adaptive data rate allocation and power control in LoRaWAN,? *International Symposium on, A World of Wireless, Mobile and Multimedia Networks (WoWMoM)*, IEEE, 2018.

[87] Y. SELDIN, C. SZEPESVÁRI, P. AUER & Y. ABBASI-YADKORI, ?Evaluation and analysis of the performance of the EXP3 algorithm in stochastic environments,? *European Workshop on Reinforcement Learning*, PLMR, 2013.

[88] A. TSAKMAKIS, A. VALKANIS, G. BELETSIOTI, K. KANTELIS, P. NICOPOLITIDIS & G. PAPADIMITRIOU, ?Efficient Frequency Planning for LoRaWAN networks with urgent traffic,? *Int Conf on Computer, Information and Telecommunication Systems (CITS)*, IEEE, 2021.

[89] L.-H. SHEN, C.-H. WU, W.-C. SU & K.-T. FENG, ?Analysis and implementation for traffic-aware channel assignment and contention scheme in LoRa-based IoT networks,? *Internet of Things Journal*, IEEE, 2021.

[90] Z. QIN & J. A. McCANN, ?Resource efficiency in low-power wide-area networks for IoT applications,? *Global Communications Conference (GLOBECOM)*, IEEE, 2017.

[91] N. CHINCHILLA-ROMERO, J. NAVARRO-ORTIZ, P. MUÑOZ & P. AMEIGEIRAS, ?Collision avoidance resource allocation for LoRaWAN,? *Sensors*, IEEE, 2021.

[92] A. KABURAKI, K. ADACHI, O. TAKYU, M. OHTA & T. FUJII, ?Resource Allocation for Periodic Traffic in Wireless Sensor Network,? *Wireless Communications and Networking Conference (WCNC)*, IEEE, 2023.
[93] J. LEE & J.-S. SUNG, ?A Traffic-Aware Dynamic Frame Adaptation Scheme for LoRaWAN Networks,? 13th Int Conf on Information and Communication Technology Convergence (ICTC), IEEE, 2022.

[94] A. AIMI, F. GUILLEMIN, S. ROVEDAKIS & S. SECCI, ?International Symposium on Modeling and Optimization in Mobile, Ad hoc, and Wireless Networks (WiOpt),? IEEE, 2022.

[95] L. COMMITTEE, LoRaWAN™ Specification v1. 1, 2017.

[96] J. HAXHIBEQIRI, I. MOERMAN & J. HOEBEKE, ?Low overhead scheduling of LoRa transmissions for improved scalability,? Internet of Things Journal, IEEE, 2019.

[97] Z. XU, J. LUO, Z. YIN, T. HE & F. DONG, ?SMAC: achieving high scalability via adaptive scheduling in LPWAN,? Conference on Computer Communications(INFOCOM), IEEE, 2020.

[98] D. ZORBAS, K. ABDELFADEEL, P. KOTZANIKOLAOU & D. PESCH, ?TS-LoRa: time-slotted LoRaWAN for the industrial Internet of Things,? Computer Communications, Elsevier, 2020.

[99] Z. XU, J. LUO, Z. YIN et al., ?X-MAC: Achieving High Scalability via Imperfect-Orthogonality Aware Scheduling in LPWAN,? Int Conf on Network Protocols (ICNP), IEEE, 2022.

[100] A. KABURAKI, K. ADACHI, O. TAKYU, M. OHTA & T. FUJII, ?Autonomous decentralized traffic control using Q-learning in LPWAN,? Access, IEEE, 2021.

[101] C. J. WATKINS & P. DAYAN, ?Q-learning,? Machine learning, Springer, 1992.

[102] J. CLIFTON & E. LABER, ?Q-learning: Theory and applications,? Annual Review of Statistics and Its Application, Annual Reviews, 2020.

[103] K. LASRI, Y. BEN MAISSA, L. ECHABBI, O. IOVA & F. VALOIS, ?A new distributed and probabilistic approach for traffic control in LPWANs,? Int Conf on Advanced Information Networking and Applications (AINA), Springer, 2021.

[104] K. LASRI, Y. BEN MAISSA, L. ECHABBI, O. IOVA & F. VALOIS, ?Probabilistic and distributed traffic control in LPWANs,? Ad Hoc Networks, Elsevier, 2023.

[105] L. ALLIANCE, Lorawan remote multicast setup specification v1. 0.0, 2018.

[106] L. ALLIANCE, LoRaWAN 1.1 Specification. 2017.

[107] S. H. LIM & K. B. LEE, ?Multicast activation scheme based on LoRaWAN for multicast MAC transmission,? Proceedings of the Advanced Int Conf on Telecommunications, IEEE, 2018.

[108] Y. SHIFERAW, A. ARORA & F. KUIPERS, ?LoRaWAN class B multicast scalability,? International Federation for Information Processing Networking Conference (IFIP), IEEE, 2020.

[109] U. O. S. C. INFORMATION SCIENCES INSTITUTE, ?RFC 793: transmission control protocol, darpa internet program protocol specification,? IETF, 1981.

[110] J. IYENGAR & M. THOMSON, ?RFC 9000: quic: a UDP-based multiplexed and secure transport,? IETF, 2021.

[111] D. CHIU & R. JAIN, ?Analysis of the increase/decrease algorithms for congestion avoidance in computer networks,? Computer Networks and ISDN Systems, Elsevier, 1989.

[112] M. C. BOR, U. ROEDIG, T. VOIGT & J. M. ALONSO, ?Do LoRa low-power wide-area networks scale?? Int Conf on Modeling, Analysis and Simulation of Wireless and Mobile System(MSWiM), IEEE, 2016.

[113] M. SLABICKI, G. PREMSANKAR & M. DI FRANCESCO, ?Adaptive configuration of LoRa networks for dense IoT deployments,? Network Operations and Management Symposium (NOMS), IEEE/IFIP, 2018.

[114] SX1272/73, ?Semtech datasheet - 860 MHz to 1020 MHz low power long range transceiver, rev. 4,? 2019.
[115] D. GARLISI, I. TINNIRELLO, G. BIANCHI & F. CUOMO, ?Capture aware sequential waterfilling for LoRaWAN adaptive data rate,? *Transactions on Wireless Communications*, IEEE, 2020.

[116] D. ANDREOLETTI, S. GIORDANO, G. VERTICALE & M. TORNATORE, ?Discovering the Geographic Distribution of Live Videos' Users: A Privacy-Preserving Approach,? *Global Communications Conference (GLOBECOM)*, IEEE, 2018.

[117] K. MIKHAYLOV & M. STUSEK, ?On the performance of multi-gateway LoRaWAN deployments: An experimental study,? *Wireless Communications and Networking Conference (WCNC)*, IEEE, 2020.

[118] M. NI, M. JAFARIZADEH & R. ZHENG, ?On the effect of multi-packet reception on redundant gateways in LoRaWANs,? *Int Conf on Communications (ICC)*, IEEE, 2019.

[119] M. CENTENARO, L. VANGELISTA, A. ZANELLA & M. ZORZI, ?Long-range communications in unlicensed bands: The rising stars in the IoT and smart city scenarios,? *Wireless Communications*, IEEE, 2016.

[120] C. A. GOMEZ, SHAMI & AL, ?Machine learning aided scheme for load balancing in dense IoT networks,? *Sensors*, MDPI, 2018.

[121] M. LALAM & T. LESTABLE, *Method for synchronizing a gateway in a LoRa network*, US Patent 10,470,146, nov. 2019.

[122] C. EL FEHRI, M. KASSAB, N. BACCOUR, S. ABDELLATIF, P. BERTHOU & I. KAMMOUN, ?An uplink synchronization scheme for LoRaWAN class B,? *Int Conf on Wireless and Mobile Computing, Networking and Communications (WiMob)*, IEEE, 2019.

[123] P. PAAVAI ANAND, ?A brief study of deep reinforcement learning with epsilon-greedy exploration,? *International Journal Of Computing and Digital System(IJCDS)*, University of Bahrain, 2021.

[124] V. KULESHOV & D. PRECUP, ?Algorithms for multi-armed bandit problems,? *arXiv preprint arXiv:1402.6028*, arXiv, 2014.

[125] B. HAO, Y. ABBASI YADKORI, Z. WEN & G. CHENG, ?Bootstrapping upper confidence bound,? *Advances in neural information processing systems (NeurIPS)*, Mit Pr, 2019.

[126] E. KAUFMANN, O. CAPPÉ & A. GARIVIER, ?On Bayesian upper confidence bounds for bandit problems,? *Artificial intelligence and statistics*, PMLR, 2012.