# Traffic Control in Low Power Wide Area Networks

Kawtar Lasri

► To cite this version:

Kawtar Lasri. Traffic Control in Low Power Wide Area Networks. Networking and Internet Architecture [cs.NI]. National Institute for Postal and Telecommunication (INPT), 2024. English. NNT: tel-04571664

HAL Id: tel-04571664

https://theses.hal.science/tel-04571664

Submitted on 8 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
<figure><img src="image_1.png" /></figure>
Abstract

Low-power, low data transmission rates, and long-range wireless networks, also known as Low Power Wide Area Networks (LPWANs), are designed to operate well with equipment that uses few resources and can be used for many years thanks to their long battery life operation. This type of network can handle traffic from nearly 1,000 nodes while maintaining a duty cycle of less than 1%. However, as node density grows, the number of collisions increases, mandating network traffic control, particularly in certain application scenarios that require a set of measurements per period. Additionally, for telecommunication companies providing LPWAN services, a lack of traffic management algorithms may lead to network congestion due to clients exceeding SLA (Service Level Agreement) data limits. Tackling these issues is imperative, as they are prone to become increasingly prevalent in LPWANs

To tackle this concern, we propose a Distributed and Probabilistic Traffic Control algorithm (DiPTC) that allows nodes to adapt their traffic in response to the application requirements (e.g., acquiring K measurements over a period of time) while being agnostic about the number of nodes or the network topology. When this requirement is not achieved, the gateway sends a feedback message to all the nodes demanding them to modify their traffic. We compare our proposed solution to LoRaWAN (a typical LPWAN protocol) and a Centralized Optimal Traffic Control solution (COTraC). Unlike LoRaWAN, our algorithm successfully proved its efficiency by achieving the objective while minimizing collisions and extending the network lifetime thrice. We also examined the influence of DiPTC parameters on the effectiveness of our approach. Our findings indicate that selecting these parameter values involves balancing the success rate and network lifetime while considering the specific requirements of the application. Our initial proposal focused on a single-gateway LPWAN setup. To adjust DiPTC to a multi-gateway context, we introduce new feedback message transmission methods called synchronous mode and round-robin mode. In synchronous mode, all gateways simultaneously send the feedback message to the nodes within their coverage areas. Conversely, in the round-robin mode, only one gateway at a time transmits the feedback message to the nodes in its coverage area. In a nutshell, compared with the LoRaWAN multi-gateway setup, both synchronous DiPTC and round-robin DiPTC successfully achieve our objectives while reducing collision risks.
<figure><img src="image_2.png" /></figure>
Résumé

Les réseaux sans fil à faible consommation d'énergie, à faible taux de transmission de données et à longue portée, également connus sous le nom de réseaux LPWANs, sont conçus pour fonctionner efficacement avec des équipements utilisant peu de ressources et pouvant être utilisés pendant de nombreuses années grâce à leur longue durée de vie de batterie. Ce type de réseau peut gérer le trafic provenant de près de 1 000 nœuds tout en maintenant un cycle de service de moins de 1%. Cependant, à mesure que la densité des nœuds augmente, le nombre de collisions augmente, ce qui rend nécessaire le contrôle du trafic réseau, en particulier dans certains scénarios d'application nécessitant un ensemble de mesures par période. De plus, pour les entreprises de télécommunications fournissant des services LPWAN, l'absence d'algorithmes de gestion du trafic peut entraîner une congestion du réseau en raison de clients dépassant les limites de données de l'accord de niveau de service (SLA). Il est impératif de résoudre ces problèmes, car ils risquent de devenir de plus en plus courants dans les LPWANs.

Pour résoudre ces problémes, nous proposons un algorithme de contrôle du trafic distribué et proba-
biliste (DiPTC) qui permet aux nœuds d'adapter leurs trafics en réponse aux exigences de l'application
(par exemple, acquérir *K* mesures sur une période de temps) tout en étant agnostique au nombre de
nœuds ou à la topologie du réseau. Lorsque cette exigence n'est pas satisfaite, la passerelle envoie un
message de rétroaction à tous les nœuds leur demandant de modifier leurs trafic. Nous comparons
notre solution proposée à LoRaWAN (un protocole LPWAN typique) et à une solution de contrôle de
trafic optimal centralisée (COTraC). Contrairement à LoRaWAN, notre algorithme a prouvé son effica-
cité en atteignant l'objectif tout en minimisant les collisions et en prolongeant la durée de vie du réseau
trois fois. Nous avons également examiné l'influence des paramètres de DiPTC sur l'efficacité de notre
approche. Nos résultats indiquent que la sélection de ces valeurs de paramètres implique un équilibre
entre le taux de réussite et la durée de vie du réseau tout en tenant compte des exigences spécifiques
de l'application. Notre proposition initiale était axée sur une configuration LPWAN à une seule passe-
relle. Pour adapter DiPTC à un contexte multi-passerelle, nous introduisons de nouvelles méthodes de
transmission de messages de rétroaction appelées mode synchrone et mode round-robin. En mode syn-
chrone, toutes les passerelles envoient simultanément le message de rétroaction aux nœuds dans leurs
zones de couverture. En revanche, dans le mode round-robin, une seule passerelle à la fois transmet le
message de rétroaction aux nœuds dans sa zone de couverture. En résumé, par rapport à la configura-
tion multi-passerelle LoRaWAN, à la fois le DiPTC synchrone et le DiPTC round-robin atteignent avec
succès nos objectifs tout en réduisant les risques de collision.
<figure><img src="image_3.png" /></figure>
Acknowledgements

I, Kawtar Lasri, conducted this thesis at the National Institute of Posts and Telecoms (INPT) in Rabat, Morocco, within the Research Laboratory in Telecommunications Systems, Networks, and Services (STRS), under the supervision of the esteemed professor Yann BEN MAISSA. I also pursued my research in the Research Laboratory of the Centre of Innovation in Telecommunications and Integration of Service (CITI) at the National Institute of Applied Sciences of Lyon (INSA de Lyon), France, under the guidance of professor Fabrice VALOIS and associate professor Oana IOVA.

I am deeply grateful to my thesis supervisor, Mr. Yann Ben Maissa, a respected professor at INPT, for introducing me to the fascinating world of computer science and telecommunications. His warm welcome to the STRS laboratory and unwavering trust in my abilities to lead and complete this work have been invaluable. Throughout these years, I have greatly benefited from his guidance, advice, and constant availability, and I sincerely appreciate everything I have learned from him.

I extend sincere appreciation to Mr. Fabrice Valois, a distinguished professor at INSA Lyon, for his positive demeanor, engaging scientific discussions, valuable guidance, and steadfast support. Without his assistance, the completion of this thesis would not have been possible.

Heartfelt thanks to Mrs. Oana Iova, an associate professor at INSA Lyon, for her unwavering support, confidence in my capabilities, and dedication throughout this endeavor. Her assistance, availability, patience, scientific guidance, and eagerness to implement enhancements have been instrumental in the successful culmination of this thesis.

I also appreciate Mrs. Loubna Echaabi, a distinguished professor at INPT, for her support in securing the PHC TOUBKAL grant and facilitating my introduction to the INSA Lyon Institute.

I express sincere thanks to all the committee members for evaluating this project. Special acknowledgment goes to Mr. Naja Najib, Professor at INPT Rabat, for assuming the role of committee president. Additionally, I am grateful to professors Hassan El Ghazi and Abdelhamid Belmekki from INPT Rabat, as well as professor Brahim Raouyane from F.S. Ain Chock, for generously agreeing to provide insights on my work.

I would like to express my sincere gratitude to Hajar El Hammouti for presenting me with the opportunity to pursue a PhD thesis at INPT. Your recommendation and support have been invaluable in enabling me to embark on this academic journey. Thank you for your belief in my potential and for opening the door to this exciting opportunity.

I must acknowledge my dear friends, the doctoral students of the team AGORA at the Inria Center of Lyon. You have been invaluable companions, unwavering supporters, and a second family to me during my time in France. Without your assistance and warm welcome, adapting to life in Lyon would not have been as smooth. I am incredibly fortunate to have you in my life, and your diverse nationalities and backgrounds continue to fascinate me every day. I have learned so much from each one of you, and your contributions to this work are immeasurable.

Deep gratitude goes to my dear friends Mahjouba Nichane, Adnane Malki, and Houda Lotfi, for their unwavering support, warm hospitality, and incredibly friendly welcome. Their invaluable assistance has facilitated my adaptation to vibrant life in Lyon, France.
I am profoundly grateful for the unwavering support and boundless enthusiasm that my family has shown me throughout this journey. My mother, Naima Ezzazouai, and father, Ahmed Lasri, have been constant sources of inspiration and motivation, encouraging me to pursue excellence in all endeavors. Their unwavering belief in my abilities has been a guiding light, propelling me forward even in the face of challenges.

I extend special thanks to my sister, Wafae Lasri, and my brother, Imad Lasri, for their steadfast support, encouragement, and understanding. Their unwavering presence and words of encouragement have been a source of strength, helping me navigate through the complexities of life with confidence and determination.

Lastly, I extend my thanks to all my friends, with whom I have shared countless moments of laughter and engaging discussions. Through their assistance and valuable suggestions, they have indirectly contributed to my well-being and the successful completion of this work. With a profound sense of accomplishment, I dedicate this thesis to my mother and father.

This research was partially supported by the CNRST & CAMPUS FRANCE (PHC TOUBKAL 2019, French-Morocco bilateral program), Grant Number: 41562UA. And the INSA Lyon Research & Development, Research Valorisation and Continuing Education subsidiary, INSAVALOR.
# Contents

Abstract iii

Résumé v

Acknowledgements vii

1 Introduction 1

1.1 An overview on Low Power Wide Area Networks (LPWANs) 1

1.1.1 LoRa Pioneering Influence 2

1.1.2 The Weightless technology 3

1.1.3 The NB-IoT technology 4

1.2 Problem statement 4

1.2.1 Constraints of Sub-Gigahertz Unlicensed Bands in LPWANs 5

1.2.2 Constraints of the medium access protocols in LPWANs 5

1.2.3 Need for traffic control in LPWANs 6

1.2.3.1 Specific applications scenario 6

1.2.3.2 Telecommunication companies scenario 7

1.3 Objective and Contributions 7

1.4 Thesis Organization 8

1.5 Publications 9

1.5.1 Journals 9

1.5.2 Conferences 9

1.5.3 Posters 10

2 State of the art 11

2.1 Introduction 11

2.2 Overview on LPWANs 12

2.2.1 NB-IoT 12

2.2.2 LTE-M 12

2.2.3 LoRa and LoRAWAN 13

2.2.4 Ingenu Random Phase Multiple Access (RPMA) 13

2.2.5 Choosing the appropriate technology 13

2.3 Background on LoRa/LoRaWAN 14

2.3.1 LoRa Physical layer 15

2.3.1.1 LoRa Parameters 16

2.3.1.2 Impact of Parameter Variation on Network Performance 16

2.3.1.3 LoRa packet structure 18

2.3.2 LoRaWAN: Mac layer 19

2.3.2.1 LoRaWAN network architecture 19

2.3.2.2 Duty cycle limitation 21

2.3.2.3 Transmission time - Time On Air (TOA) 21

2.3.2.4 Adaptive Data Rate (ADR) mechanism 22

2.3.3 Regulatory Constraints 23
<table>
  <tbody>
    <tr>
      <td>2.4</td>
      <td>Traffic control approaches in LoRaWAN</td>
      <td>24</td>
    </tr>
    <tr>
      <td>2.4.1</td>
      <td>LoRa parameters optimization</td>
      <td>24</td>
    </tr>
    <tr>
      <td>2.4.2</td>
      <td>Frequency channel optimization</td>
      <td>26</td>
    </tr>
    <tr>
      <td>2.4.3</td>
      <td>Traffic scheduling</td>
      <td>28</td>
    </tr>
    <tr>
      <td>2.5</td>
      <td>Discussion and Positioning</td>
      <td>29</td>
    </tr>
    <tr>
      <td>2.5.1</td>
      <td>Discussion</td>
      <td>29</td>
    </tr>
    <tr>
      <td>2.5.2</td>
      <td>Positioning</td>
      <td>32</td>
    </tr>
    <tr>
      <td>2.6</td>
      <td>Conclusion</td>
      <td>32</td>
    </tr>
    <tr>
      <td>3</td>
      <td>A Distributed and Probabilistic Traffic Control algorithm for LPWANs</td>
      <td>33</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Introduction</td>
      <td>33</td>
    </tr>
    <tr>
      <td>3.2</td>
      <td>Motivation</td>
      <td>34</td>
    </tr>
    <tr>
      <td>3.3</td>
      <td>DiPTC: the big picture</td>
      <td>34</td>
    </tr>
    <tr>
      <td>3.4</td>
      <td>Assumptions</td>
      <td>35</td>
    </tr>
    <tr>
      <td>3.4.1</td>
      <td>Network configuration</td>
      <td>36</td>
    </tr>
    <tr>
      <td>3.4.2</td>
      <td>Simplified binary acknowledgment in the downlink message</td>
      <td>36</td>
    </tr>
    <tr>
      <td>3.4.3</td>
      <td>Downlink Broadcasting and Multicasting Capacities</td>
      <td>37</td>
    </tr>
    <tr>
      <td>3.5</td>
      <td>DiPTC algorithm</td>
      <td>38</td>
    </tr>
    <tr>
      <td>3.6</td>
      <td>Simulation model</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.1</td>
      <td>Wireless environment</td>
      <td>40</td>
    </tr>
    <tr>
      <td>3.6.2</td>
      <td>Energy consumption</td>
      <td>41</td>
    </tr>
    <tr>
      <td>3.7</td>
      <td>Benchmark protocols</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.7.1</td>
      <td>LoRaWAN protocol</td>
      <td>42</td>
    </tr>
    <tr>
      <td>3.7.2</td>
      <td>Centralized Optimal Traffic Control protocol</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.8</td>
      <td>Overall performance evaluation</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.8.1</td>
      <td>Scenarios and network parameters</td>
      <td>43</td>
    </tr>
    <tr>
      <td>3.8.2</td>
      <td>DiPTC vs. LoRaWAN vs. COTraC</td>
      <td>44</td>
    </tr>
    <tr>
      <td>3.9</td>
      <td>Horizontal and vertical scalability evaluation</td>
      <td>45</td>
    </tr>
    <tr>
      <td>3.9.1</td>
      <td>Impact of the traffic intensity</td>
      <td>48</td>
    </tr>
    <tr>
      <td>3.9.2</td>
      <td>Impact of the nodes scalability</td>
      <td>50</td>
    </tr>
    <tr>
      <td>3.10</td>
      <td>Traffic control parameters evaluation</td>
      <td>52</td>
    </tr>
    <tr>
      <td>3.11</td>
      <td>Discussion &amp; Insights</td>
      <td>56</td>
    </tr>
    <tr>
      <td>3.12</td>
      <td>Conclusion</td>
      <td>58</td>
    </tr>
    <tr>
      <td>4</td>
      <td>DiPTC Multi-Gateway Behaviour Study</td>
      <td>59</td>
    </tr>
    <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>
  </tbody>
</table>
<table><tr><td>4.11 Conclusion</td><td>78</td></tr></table>

<table><tr><td>5</td><td>General conclusions and future works</td><td>79</td></tr></table>

<table><tr><td>5.1</td><td>Conclusions</td><td>79</td></tr></table>

<table><tr><td>5.2</td><td>Future Works</td><td>80</td></tr></table>

<table><tr><td>A</td><td></td><td>81</td></tr></table>

<table><tr><td>A.1</td><td>Simulation parameters</td><td>81</td></tr></table>
List of Figures

<table>
  <tbody>
    <tr>
      <td>1.1</td>
      <td>Low Power Wide Area Networks features [7].</td>
      <td>2</td>
    </tr>
    <tr>
      <td>1.2</td>
      <td>Power consumption versus communication range for various radios [11].</td>
      <td>3</td>
    </tr>
    <tr>
      <td>1.3</td>
      <td>NB-IoT and LoRa features comparison [19].</td>
      <td>4</td>
    </tr>
    <tr>
      <td>2.1</td>
      <td>LoRa Network Layer [59]</td>
      <td>15</td>
    </tr>
    <tr>
      <td>2.2</td>
      <td>LoRa packet format [25]. White-colored sections can be optional, while grey-colored areas must be present.</td>
      <td>18</td>
    </tr>
    <tr>
      <td>2.3</td>
      <td>LoRaWAN network topology [67]</td>
      <td>19</td>
    </tr>
    <tr>
      <td>2.4</td>
      <td>Class time diagram of LoRaWAN devices [10].</td>
      <td>20</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Example of DiPTC in LoRaWAN, where all nodes transmit data at the same rate.</td>
      <td>35</td>
    </tr>
    <tr>
      <td>3.2</td>
      <td>Diagram of the DiPTC algorithm for a node.</td>
      <td>39</td>
    </tr>
    <tr>
      <td>3.3</td>
      <td>Traffic evolution in the BASIC scenario for DiPTC (0.5, 0.5, 0.5).</td>
      <td>46</td>
    </tr>
    <tr>
      <td>3.4</td>
      <td>Traffic evolution in the BASIC scenario for DiPTC (0.5, 0.5, 0.5) and a downlink probability reception of 0.99.</td>
      <td>46</td>
    </tr>
    <tr>
      <td>3.5</td>
      <td>Traffic evolution in the BASIC scenario for LoRaWAN.</td>
      <td>47</td>
    </tr>
    <tr>
      <td>3.6</td>
      <td>Nodes traffic evolution in the BASIC scenario.</td>
      <td>47</td>
    </tr>
    <tr>
      <td>3.7</td>
      <td>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).</td>
      <td>48</td>
    </tr>
    <tr>
      <td>3.8</td>
      <td>Traffic evolution in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.06) and a downlink probability reception of 0.99.</td>
      <td>48</td>
    </tr>
    <tr>
      <td>3.9</td>
      <td>Traffic evolution in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.06) and a downlink probability reception of 0.99.</td>
      <td>49</td>
    </tr>
    <tr>
      <td>3.10</td>
      <td>Traffic evolution in the INTENSIVE scenario for DiPTC (0.5, 0.5, 0.06) and a downlink probability reception of 0.70.</td>
      <td>49</td>
    </tr>
    <tr>
      <td>3.11</td>
      <td>Traffic evolution in the INTENSIVE scenario for LoRaWAN.</td>
      <td>49</td>
    </tr>
    <tr>
      <td>3.12</td>
      <td>Nodes traffic evolution in the INTENSIVE scenario.</td>
      <td>50</td>
    </tr>
    <tr>
      <td>3.13</td>
      <td>Traffic evolution in the DENSE scenario for DiPTC (0.5, 0.5, 0.5).</td>
      <td>50</td>
    </tr>
    <tr>
      <td>3.14</td>
      <td>Traffic evolution in the DENSE scenario for LoRaWAN.</td>
      <td>51</td>
    </tr>
    <tr>
      <td>3.15</td>
      <td>Error frequency in the DENSE scenario for DiPTC (0.5, 0.5, 0.5) and LoRaWAN.</td>
      <td>51</td>
    </tr>
    <tr>
      <td>3.16</td>
      <td>Nodes traffic evolution in the DENSE scenario.</td>
      <td>52</td>
    </tr>
    <tr>
      <td>3.17</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the BASIC scenario for DiPTC when P<sub>adapt</sub>=0.5.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>3.18</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the BASIC scenario for DiPTC when P<sub>adapt</sub>=0.1.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>3.19</td>
      <td>Comparison of performance measures for different DiPTC configurations (x<sub>I</sub>, x<sub>D</sub>, P<sub>adapt</sub>) in the BASIC scenario.</td>
      <td>53</td>
    </tr>
    <tr>
      <td>3.20</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for DiPTC when P<sub>adapt</sub>=0.5.</td>
      <td>54</td>
    </tr>
    <tr>
      <td>3.21</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for DiPTC when P<sub>adapt</sub>=0.06.</td>
      <td>54</td>
    </tr>
    <tr>
      <td>3.22</td>
      <td>Comparison of performance measures of different DiPTC configurations (x<sub>I</sub>, x<sub>D</sub>, P<sub>adapt</sub>) in the INTENSIVE scenario.</td>
      <td>55</td>
    </tr>
  </tbody>
</table>
<table>
  <tbody>
    <tr>
      <td>3.23</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the DENSE scenario for DiPTC when P<sub>adapt</sub>=0.5.</td>
      <td>55</td>
    </tr>
    <tr>
      <td>3.24</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the DENSE scenario when P<sub>adapt</sub>=0.1.</td>
      <td>55</td>
    </tr>
    <tr>
      <td>3.25</td>
      <td>Comparison of performance measures of different DiPTC configurations (x<sub>I</sub>, x<sub>D</sub>, P<sub>adapt</sub>) in the DENSE scenario.</td>
      <td>56</td>
    </tr>
    <tr>
      <td>4.1</td>
      <td>Example of DiPTC mono-gateway, where all nodes transmit data at the same rate.</td>
      <td>63</td>
    </tr>
    <tr>
      <td>4.2</td>
      <td>Synchronous transmission in multi-gateway DiPTC.</td>
      <td>63</td>
    </tr>
    <tr>
      <td>4.3</td>
      <td>Round-robin transmission in multi-gateway DiPTC.</td>
      <td>64</td>
    </tr>
    <tr>
      <td>4.4</td>
      <td>Diagram of the DiPTC algorithm for a node.</td>
      <td>65</td>
    </tr>
    <tr>
      <td>4.5</td>
      <td>Spatial distribution of active nodes in the round-robin mode, 43200 min (1 month), INTENSIVE scenario - DiPTC config. (0.5, 0.5, 0.06).</td>
      <td>69</td>
    </tr>
    <tr>
      <td>4.6</td>
      <td>Traffic evolution in the INTENSIVE scenario for the synchronous mode.</td>
      <td>70</td>
    </tr>
    <tr>
      <td>4.7</td>
      <td>Zoom on the traffic evolution in the INTENSIVE scenario for DiPTC.</td>
      <td>70</td>
    </tr>
    <tr>
      <td>4.8</td>
      <td>Traffic evolution in the INTENSIVE scenario for the round-robin mode.</td>
      <td>71</td>
    </tr>
    <tr>
      <td>4.9</td>
      <td>Traffic evolution in the INTENSIVE scenario in LoRaWAN.</td>
      <td>71</td>
    </tr>
    <tr>
      <td>4.10</td>
      <td>Nodes traffic evolution in the INTENSIVE scenario for the synchronous and the round-robin modes.</td>
      <td>72</td>
    </tr>
    <tr>
      <td>4.11</td>
      <td>Nodes traffic evolution in the INTENSIVE scenario in LoRaWAN.</td>
      <td>72</td>
    </tr>
    <tr>
      <td>4.12</td>
      <td>Comparison of performance measures of DiPTC modes and LoRaWAN in the INTENSIVE scenario.</td>
      <td>72</td>
    </tr>
    <tr>
      <td>4.13</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the INTENSIVE scenario for round-robin and synchronous DiPTC and LoRaWAN.</td>
      <td>73</td>
    </tr>
    <tr>
      <td>4.14</td>
      <td>Comparison of the Network Lifetime under a different number of nodes, in the INTENSIVE scenario.</td>
      <td>73</td>
    </tr>
    <tr>
      <td>4.15</td>
      <td>Comparison of the Success Rate under a different number of nodes, in the INTENSIVE scenario.</td>
      <td>73</td>
    </tr>
    <tr>
      <td>4.16</td>
      <td>Comparison of the Packet Reception Rate under a different number of nodes, in the INTENSIVE scenario.</td>
      <td>74</td>
    </tr>
    <tr>
      <td>4.17</td>
      <td>Traffic evolution in the DENSE scenario for the synchronous mode.</td>
      <td>75</td>
    </tr>
    <tr>
      <td>4.18</td>
      <td>Traffic evolution in the DENSE scenario for the round-robin mode.</td>
      <td>75</td>
    </tr>
    <tr>
      <td>4.19</td>
      <td>Traffic evolution in the DENSE scenario for LoRaWAN.</td>
      <td>75</td>
    </tr>
    <tr>
      <td>4.20</td>
      <td>Nodes traffic evolution in the DENSE scenario for the synchronous and round-robin modes.</td>
      <td>76</td>
    </tr>
    <tr>
      <td>4.21</td>
      <td>Nodes traffic evolution in the DENSE scenario for LoRaWAN.</td>
      <td>76</td>
    </tr>
    <tr>
      <td>4.22</td>
      <td>Comparison of performance measures of DiPTC modes and LoRaWAN in the DENSE scenario.</td>
      <td>76</td>
    </tr>
    <tr>
      <td>4.23</td>
      <td>Comparison of error frequency and transient regimes duration frequencies, in the DENSE scenario for round-robin and synchronous DiPTC and LoRaWAN.</td>
      <td>77</td>
    </tr>
  </tbody>
</table>
List of Tables

<table><tbody><tr><td>2.1</td><td>Impact of Parameter Variation on LoRaWAN Performance.</td><td>17</td></tr><tr><td>2.2</td><td>Data Rate codes provided by the LoRaWAN specification [64].</td><td>17</td></tr><tr><td>2.3</td><td>Influence of Spreading Factors and Bandwidth on the bit rate [64].</td><td>22</td></tr><tr><td>2.4</td><td>Spreading factors impact on the receiver sensitivity [64].</td><td>23</td></tr><tr><td>3.1</td><td>Network parameters.</td><td>41</td></tr><tr><td>3.2</td><td>Simulation scenarios.</td><td>44</td></tr><tr><td>3.3</td><td>LoRaWAN, DiPTC and COTraC performance</td><td>45</td></tr><tr><td>3.4</td><td>DiPTC configurations.</td><td>52</td></tr><tr><td>4.1</td><td>Simulation scenarios.</td><td>68</td></tr><tr><td>4.2</td><td>Network parameters.</td><td>68</td></tr><tr><td>A.1</td><td>LoRa parameters for the BASIC and INTENSE scenarios.</td><td>81</td></tr><tr><td>A.2</td><td>LoRa parameters for the DENSE scenario.</td><td>82</td></tr></tbody></table>
List of Abbreviations

<table><tr><td>ACK</td><td>ACKnowledgement</td></tr><tr><td>ADR</td><td>Adaptive Data Rate</td></tr><tr><td>AIAD</td><td>Additive Increase Additive Decrease</td></tr><tr><td>AIMD</td><td>Additive Increase Multiplicative Decrease</td></tr><tr><td>ARIMA</td><td>AutoRegressive Integrated Moving Average</td></tr><tr><td>ARMA</td><td>AutoRegressive Moving Average</td></tr><tr><td>AS</td><td>Application Server</td></tr><tr><td>BW</td><td>BandWidth</td></tr><tr><td>CARA</td><td>Collision Avoidance Resource Allocation</td></tr><tr><td>CF</td><td>Carrier Frequency</td></tr><tr><td>CORRECT</td><td>HeuristiC FOR REsource AlloCaTion</td></tr><tr><td>COTraC</td><td>Centralized Optimal Traffic Control</td></tr><tr><td>CR</td><td>Coding Rate</td></tr><tr><td>CSI</td><td>Channel State Information</td></tr><tr><td>CRC</td><td>Cyclic Redundancy Check</td></tr><tr><td>CSS</td><td>Chirp Spread Spectrum</td></tr><tr><td>dB</td><td>decibel</td></tr><tr><td>DER</td><td>Data Extraction Rate</td></tr><tr><td>DL</td><td>Downlink</td></tr><tr><td>DiPTC</td><td>Distributed Probabilistic</td></tr><tr><td>DR</td><td>Data Rate</td></tr><tr><td>EMC</td><td>ElectroMagnetic Compatibility</td></tr><tr><td>TC</td><td>Taffic Control</td></tr><tr><td>DRF</td><td>Dynamic Region Formation</td></tr><tr><td>FADR</td><td>Fair Adaptive Data Rate</td></tr><tr><td>FEC</td><td>Forward Error correction</td></tr><tr><td>FREE</td><td>Fine Reliable Energy Efficient</td></tr><tr><td>FSK</td><td>Frequency Shift Keying</td></tr><tr><td>GL</td><td>Gain and Loss</td></tr><tr><td>IoT</td><td>Internet of Things</td></tr><tr><td>KM</td><td>K-Means</td></tr><tr><td>LBT</td><td>Listen Before Talk</td></tr><tr><td>LoRa</td><td>Long Range</td></tr><tr><td>LoRaWAN</td><td>Long Range Wide Area Network</td></tr><tr><td>LPWAN</td><td>Low Power Wide Area Network</td></tr><tr><td>LR-FHSS</td><td>Long Range Frequency Hopping Spread Spectrum</td></tr><tr><td>M2M</td><td>Machine-2(to)-Machine</td></tr><tr><td>MAB</td><td>Multi Armed Bandit</td></tr><tr><td>MAC</td><td>Medium Access Control</td></tr><tr><td>MARCO</td><td>Optimization Model Resource AlloCaTion</td></tr><tr><td>MCAA</td><td>Matching Channel Assignment Algorithm</td></tr><tr><td>McAddr</td><td>Multicast Device Address</td></tr></table>
<table>
   <tr>
    <td>MILP</td>
    <td>Mixed Integer Linear Programming</td>
   </tr>
   <tr>
    <td>MIMD</td>
    <td>Multiplicative Increase Multiplicative Decrease</td>
   </tr>
   <tr>
    <td>NB</td>
    <td>Narrow-Band</td>
   </tr>
   <tr>
    <td>NS</td>
    <td>Network Server</td>
   </tr>
   <tr>
    <td>NSSE</td>
    <td>Network Synchronization Scheduling Entity</td>
   </tr>
   <tr>
    <td>OTAA</td>
    <td>Over The Air Activation</td>
   </tr>
   <tr>
    <td>OWA</td>
    <td>Ordering Weight Average Operator</td>
   </tr>
   <tr>
    <td>PDR</td>
    <td>Packet Delivery Rate</td>
   </tr>
   <tr>
    <td>PHY</td>
    <td>PHYsical</td>
   </tr>
   <tr>
    <td>PL</td>
    <td>Play Load</td>
   </tr>
   <tr>
    <td>PLR</td>
    <td>Packet Loss Rate</td>
   </tr>
   <tr>
    <td>PN</td>
    <td>Pseudo Noise</td>
   </tr>
   <tr>
    <td>PRR</td>
    <td>Packet Reception Rate</td>
   </tr>
   <tr>
    <td>QoS</td>
    <td>Quality of Service</td>
   </tr>
   <tr>
    <td>QUIC</td>
    <td>Quick UDP Internet Connections</td>
   </tr>
   <tr>
    <td>RR</td>
    <td>Round Robin</td>
   </tr>
   <tr>
    <td>RSSI</td>
    <td>Received Signal Strength Indicator</td>
   </tr>
   <tr>
    <td>SF</td>
    <td>Spreading Factor</td>
   </tr>
   <tr>
    <td>SLA</td>
    <td>Service Level Agreement</td>
   </tr>
   <tr>
    <td>SIG</td>
    <td>Special Interest Group</td>
   </tr>
   <tr>
    <td>SINR</td>
    <td>Signal Interference Noise Ratio</td>
   </tr>
   <tr>
    <td>Sync</td>
    <td>Synchronous</td>
   </tr>
   <tr>
    <td>TC</td>
    <td>Traffic Control</td>
   </tr>
   <tr>
    <td>TCBA</td>
    <td>Traffic Channel Backoff Allocation</td>
   </tr>
   <tr>
    <td>TCP</td>
    <td>Transmission Control Protocol</td>
   </tr>
   <tr>
    <td>TP</td>
    <td>Transmission Power</td>
   </tr>
   <tr>
    <td>ToA</td>
    <td>Time on Air</td>
   </tr>
   <tr>
    <td>TS</td>
    <td>Time Symbol</td>
   </tr>
   <tr>
    <td>TVWS</td>
    <td>TV White Space</td>
   </tr>
   <tr>
    <td>UP</td>
    <td>Uplink</td>
   </tr>
   <tr>
    <td>UNB</td>
    <td>Ultra Narrow Band</td>
   </tr>
   <tr>
    <td>WSN</td>
    <td>Wireless Sensor Network</td>
   </tr>
  </table>
List of Symbols

<table><tr><td>α<sub>n</sub></td><td>Weighting coefficient for node n</td></tr><tr><td>AVG</td><td>Average sending time</td></tr><tr><td>B(p)</td><td>Bernoulli distribution</td></tr><tr><td>d</td><td>Distance (m)</td></tr><tr><td>d<sub>0</sub></td><td>Reference distance</td></tr><tr><td>ΔT</td><td>Time period (min)</td></tr><tr><td>E<sub>c</sub></td><td>Energy consumption</td></tr><tr><td>γ</td><td>Path loss exponent</td></tr><tr><td>k</td><td>Number of received measurement(s) at the network server</td></tr><tr><td>K</td><td>Number of measurement(s) required by the application</td></tr><tr><td>L<sub>pl</sub></td><td>Path loss</td></tr><tr><td>M</td><td>Number of gateways in the network</td></tr><tr><td>MaxDT</td><td>Maximum number of messages, a node can transmit w.r.t. its duty cycle</td></tr><tr><td>m<sub>n</sub></td><td>Number of messages to send by the node n</td></tr><tr><td>μ<sub>c</sub></td><td>Success rate</td></tr><tr><td>N</td><td>Number of nodes in the network</td></tr><tr><td>P<sub>adapt</sub></td><td>Adaptation probability</td></tr><tr><td>P<sub>DL</sub></td><td>Probability to receive the downlink</td></tr><tr><td>P<sub>rx</sub></td><td>Reception power</td></tr><tr><td>P<sub>tx</sub></td><td>Transmission power</td></tr><tr><td>σ<sup>2</sup></td><td>Shadowing variance</td></tr><tr><td>Simtime</td><td>Simulation time</td></tr><tr><td>τ<sub>c</sub></td><td>Collision rate</td></tr><tr><td>t<sub>l</sub></td><td>Network lifetime</td></tr><tr><td>TOA</td><td>Time on air</td></tr><tr><td>V<sub>n</sub>(t)</td><td>Stochastic variable</td></tr><tr><td>x<sub>D</sub></td><td>Decrease factor ∈ ]0, 1]</td></tr><tr><td>x<sub>I</sub></td><td>Increase factor ∈ ]0, 1]</td></tr><tr><td>X<sub>σ</sub> ~ N(0, σ<sup>2</sup>)</td><td>Normal distribution with zero mean</td></tr></table>
# Chapter 1

# Introduction

## Contents

<table><tr><td>1.1</td><td>An overview on Low Power Wide Area Networks (LPWANs)</td><td>1</td></tr><tr><td>1.1.1</td><td>LoRa Pioneering Influence</td><td>2</td></tr><tr><td>1.1.2</td><td>The Weightless technology</td><td>3</td></tr><tr><td>1.1.3</td><td>The NB-IoT technology</td><td>4</td></tr><tr><td>1.2</td><td>Problem statement</td><td>4</td></tr><tr><td>1.2.1</td><td>Constraints of Sub-Gigahertz Unlicensed Bands in LPWANs</td><td>5</td></tr><tr><td>1.2.2</td><td>Constraints of the medium access protocols in LPWANs</td><td>5</td></tr><tr><td>1.2.3</td><td>Need for traffic control in LPWANs</td><td>6</td></tr><tr><td>1.2.3.1</td><td>Specific applications scenario</td><td>6</td></tr><tr><td>1.2.3.2</td><td>Telecommunication companies scenario</td><td>7</td></tr><tr><td>1.3</td><td>Objective and Contributions</td><td>7</td></tr><tr><td>1.4</td><td>Thesis Organization</td><td>8</td></tr><tr><td>1.5</td><td>Publications</td><td>9</td></tr><tr><td>1.5.1</td><td>Journals</td><td>9</td></tr><tr><td>1.5.2</td><td>Conferences</td><td>9</td></tr><tr><td>1.5.3</td><td>Posters</td><td>10</td></tr></table>

## 1.1 An overview on Low Power Wide Area Networks (LPWANs)

The Internet of Things (IoT) revolution is still in its infancy, and Low Power Wide Area Networks (LPWANs) are one of the key milestones in this evolution. This development marks a significant milestone in connecting various objects, be it for consumer and citizen applications like Smart Homes and Smart Cities, or for industrial purposes such as Smart Metering and Smart Industries [1]-[3]. Traditionally, If we wanted to connect an object, such as a machine or a vehicle, to monitor its status and location or to interact with it, the usual approach was to equip it with a SIM card and use the GPRS/3G network provided by a telecom operator. Still, this machine-to-machine (M2M) technology also has its drawbacks [4]-[6]. The main problem with this technology is the high cost of equipment, as it is difficult to find a 3G modem for less than 20-30 euros. The high power consumption and dependence on a large battery or continuous power supply make it impractical in many circumstances. In addition, the considerable size of the device limited its viability for various applications. Finally, the connection relied on an expensive, dense radio network infrastructure (i.e. operator antennas), resulting in substantial subscription fees.

The obstacles of connecting small objects or those that do not have a direct power source proved to be challenging. On top of that, the costs associated with M2M technology could sometimes surpass the benefits of the connected item itself. Additionally, apprehensions about the health effects of long-term exposure to 3G connectivity emissions prevented widespread adoption, especially for devices intended for continuous use.
<figure><img src="image_4.png" /><figcaption>FIGURE 1.1: Low Power Wide Area Networks features [7].</figcaption></figure>

LPWANs were developed to overcome the limitations of conventional connectivity approaches. LPWAN technology aims to provide cost-effective, battery-powered sensors for low data rates (refer to Fig. 1.1). These sensors are not only affordable - they usually cost only a few euros- but also compact, measuring only a few millimeters. They are powered by batteries and have an impressive lifespan of 5 to 10 years [1]-[3]. In the following section, we discuss the main LPWAN technologies.

### 1.1.1 LoRa Pioneering Influence

Today, the LPWAN industry is dominated by LoRa [8]-[10], an open protocol based on the chipset technology of the American company SEMTECH, originally developed in France. LoRa operates within the unregulated ISM 868 MHz frequency band in both continents Africa and Europe. Notably, this frequency band enables data transmission over considerable distances, of up to 15-20 km. This differs notably from traditional GSM networks, which rely on antennas that are spaced only a few kilometers apart. Fig. 1.2, compares several different wireless technologies in terms of power consumption and communication range. LPWANs, including LoRaWAN, Weightless-P, and NB-IoT, occupy a significant position on the spectrum of radio power consumption versus communication range. This underscores their importance in the context of wireless technology. Notably, the advantage lies in the rapid and cost-effective deployment of LPWAN networks (As indicated in Fig. 1.1).

As a part of the LoRa protocol sensors transmit data packets to all the adjacent antennas. Then the network consolidates this information and delivers a single message to any dedicated data processing platform via a callback mechanism. Remarkably, this efficient communication method not only enables extended coverage but also facilitates swift and economical network expansion. As the shared use of the 868 MHz frequency band Across Africa and Europe emphasizes the interoperability of these LPWAN technologies and contributes to their widespread adoption and success in the market. While the free utilization of the ISM 868 MHz frequency band is advantageous because of its cost-effectiveness and rapid deployment, it also comes with inherent limitations. Due to regulatory restrictions, a sensor may only use 1% of the frequency band, translating to a maximum of 140 useful 12-byte messages payload that can be transferred from the sensor in the uplink direction via the LoRa network [12]. Furthermore, downlink transmission, which involves transferring data from the network to the sensor, is strictly restricted. As The duty cycle restrictions imposed by regulatory authorities determine the number of downlink messages that a device can receive within a specified time frame. Duty cycle regulations differ across regions; they are designed to prevent network congestion and ensure fair use of the shared radio spectrum. These regulations specify the maximum permissible transmission time within a specific period of time. In Africa and Europe, for example, the duty cycle for downlink messages in the 868 MHz band is typically limited to 1% per hour. This entails that a device can only
<figure><img src="image_5.png" /><figcaption>FIGURE 1.2: Power consumption versus communication range for various radios [11].</figcaption></figure>

receive downlink messages for a maximum of 36 seconds within any given hour. These restrictions apply to both uplink and downlink transmissions and are important for preventing network saturation, minimizing interference, and adhering to regulatory requirements. Correspondingly, it is important to note that the specific limits can vary based on local regulations and network configurations. The absence of these regulations also introduces the possibility of interference among users, which makes it challenging to guarantee consistent Quality of Service (QoS). This constraint has incited proponents of alternative technologies, such as NB-IoT, operating on regulated frequencies, to emphasize their potential for offering a more reliable and interference-free environment promising to ensure a robust Quality of Service.

1.1.2 The Weightless technology

Weightless [13], [14] is an open standard for LPWANs, strategically engineered for optimal network performance. Weightless is a set of three distinct protocols, Weightless-H, Weightless-W, and Weightless-P, developed by the Special Interest Group (SIG), each made to support a variety of applications and uses.

* Weightless-W operates on open technology standards, specifically designed for frequencies within the 470-790 MHz TV range, commonly known as TV white space (TVWS). With 5 km coverage zones, Weightless-W is particularly suitable for applications such as the oil and gas industries, providing robust communication solutions.

* Weightless-N, on the other hand, focuses on creating expansive coverage areas with low data rates of 500 Bits/s. This protocol enables unidirectional communication over distances of up to 10 km. Weightless-N supports a broad spectrum of ISM frequencies and is characterized by low power consumption, making it an ideal option for sensor networks engaged in tasks such as temperature measurement and reservoir level control.

* Weightless-P is a specialized technology standard designed for narrowband IoT solutions, which emphasizes high device density, extended battery life, and bidirectional communication capabilities. Noteworthy features of this technology include scalability, the ability to optimize communication in both directions, the creation of wide coverage areas (see Fig. 1.2), prolonged battery life, and robust network security measures. Weightless-P addresses the specific needs of applications requiring efficient device communication with high density and long battery life in a secure network environment. Weightless-P uses 12.5 kHz narrowband channel, which makes it possible to transmit 98 times more data than LoRa in urban conditions.
<figure><img src="image_6.png" /><figcaption>FIGURE 1.3: NB-IoT and LoRa features comparison [19].</figcaption></figure>

The current infrastructure in LPWANs makes it difficult to utilize weightless technology due to potential interoperability issues and inadequate environment. Implementation costs, regulatory compliance, and security considerations further complicate deployment and require careful evaluation, as well as taking into account specific application requirements.

### 1.1.3 The NB-IoT technology

NB-IoT, or Narrow-Band IoT [15], aligns with similar objectives, and aims to provide a connectivity solution characterized by lower throughput and exceptionally low power consumption. This standard is developed by 3GPP for cellular network devices and services. Nb-IoT offers a distinctive feature; it has a bitrate of 20 kbits per second and is, therefore, less restrictive than its alternatives such as LoRa [16]. This increased data rate allows for more versatile applications without compromising on connectivity efficiency [17]-[19]. In Fig. 1.3, LoRa and NB-IoT technologies are compared across different Iot factors. As illustrated, the improved data throughput may come at the expense of greater power consumption in comparison to other low-power alternatives such as LoRa or Weightless-P. The trade-off lies in finding the right balance between data speed and energy efficiency, as different IoT applications may prioritize one aspect over the other based on their specific requirements and use cases. NB-IoT focuses on providing a balance between data rates and power consumption, which contributes to its versatility in meeting the diverse needs of the evolving landscape of IoT applications.

## 1.2 Problem statement

LPWANs confront several constraints that shape their deployment and performance [20], [21]. These constraints include limited data rates [22], [23], as LPWANs prioritize extended range and low power consumption over high data throughput. Latency challenges arise from intermittent connectivity and the duty cycling approach adopted for energy conservation [24]. Limited scalability becomes apparent in densely populated scenarios, where channel congestion and increased contention can impact network efficiency [20], [25], [26]. LPWANs, often operate in unlicensed spectrum [27], and face interference from other devices, and require robust coexistence mechanisms. Thus, security concerns emerge as the number of connected devices grows, necessitating stringent measures to protect sensitive data [28], [29]. Variations in geographical coverage and dependency on infrastructure further influence the reliability of LPWAN deployments [26]. Additionally, the static nature of some LPWAN technologies and the challenges of global harmonization pose hurdles to adaptability across diverse applications and regions.
In this thesis, our main concerns are the utilization of Sub-Gigahertz unlicensed bands and the implementation of medium access protocols.

### 1.2.1 Constraints of Sub-Gigahertz Unlicensed Bands in LPWANs

Although utilizing unlicensed bands offers flexibility and accessibility, it also introduces challenges in terms of interference, self-interference, and regulatory restrictions. [30]-[33]. Unlicensed frequency bands provide a dynamic and shared environment where various technologies and users coexist. This shared space includes diverse wireless technologies such as IEEE 802.15.4 [31], and LoRa [34], each with its unique communication requirements and protocols. In addition, a wide range of users and devices, from IoT sensors to smart home gadgets, use these unlicensed bands for their communication needs. The coexistence of different technologies and users sharing the same frequency spectrum can cause interference; when signals from one device or technology unintentionally affect the reception or transmission of signals by another. In the context of LPWANs, this interference can result in degraded signal quality, increased packet loss, and overall reduced network performance. Moreover, the unlicensed bands that are shared also pose a challenge of self-interference within LPWANs. Self-interference occurs when a device's own transmissions disrupt its ability to receive signals. The probability of self-interference increases in an environment where LPWAN devices are densely deployed or collocated. This phenomenon can lead to conflicts between a device's own transmission and reception processes, resulting in communication disruptions and performance degradation. To address these challenges, LPWAN technologies often incorporate mechanisms such as Listen Before Talk (LBT) or adaptive frequency hopping [35], [36]. In other terms, LBT allows devices to check for channel activity before initiating transmissions and reducing the likelihood of interference with ongoing communications. Adaptive frequency hopping dynamically changes the frequency channels used for communication to minimize the impact of interference on a particular frequency. In essence, the coexistence of IEEE 802.15.4, LoRa, and various users within unlicensed bands contributes to the diversity of the wireless ecosystem. Yet, Managing and coordinating LPWANs in shared frequency environments requires careful attention to mitigate potential interference and self-interference issues to ensure efficient and reliable operation.

LPWAN technologies, including LoRaWAN and Weightless, must comply with the frequency bands designated by regulatory authorities in each geographical area. These regulations encompass not only the assignment of frequency bands but also stipulate operational parameters such as transmission power levels and duty cycles, to prevent spectrum congestion and interference. Compliance with these regulations is mandatory for the legitimate operation of LPWANs, while violations of the specified guidelines may result in legal repercussions such as fines and license revocation. In a further step, adherence to regional regulations promotes international compatibility and facilitates the seamless deployment and operation of LPWAN devices across borders. The distinct regulatory frameworks underscore the importance of a thorough understanding and meticulous adherence to compliance measures for the successful integration of LPWANs into the global wireless communication landscape.

### 1.2.2 Constraints of the medium access protocols in LPWANs

LPWANs typically employ medium access protocols such as Aloha [36], [37], which is a simple and widely used approach. The Aloha MAC (Medium Access Control) protocol is one of the earliest and simplest protocols used in wireless communication to manage access to a shared communication channel. It was first introduced in the 1970s and has since been widely employed in various networking applications. It allows devices to transmit messages at any time on a shared channel. In case of a collision, both devices will wait for a random time before re-transmitting. If two devices transmit at the same time and a collision occurs, they both wait for a random time before trying to send again. Thus, the use of Aloha in LPWANs is driven by specific considerations that are aligned with the characteristics of LPWAN applications. The decentralized operation of Aloha is perfectly suited for the dispersed nature
of LPWAN deployments, it enables devices to communicate independently without relying on central coordination. Aloha collisions may be acceptable in low-duty cycle applications where devices transmit infrequently, particularly when paired with LPWAN applications that have less stringent latency requirements. Additionally, Aloha's low implementation cost aligns well with the often large-scale and cost-sensitive nature of LPWAN deployments. Although Aloha is straightforward, it does have inherent limitations, particularly in managing collisions and network efficiency. Aloha-based protocols may experience increased collision rates, especially in scenarios where there is a high density of devices attempting to transmit data simultaneously; collisions can lead to packet loss and decreased overall network efficiency. Aloha's contention-based nature significantly limits overall network throughput and introduces the potential for congestion and inefficient use of available bandwidth.

### 1.2.3 Need for traffic control in LPWANs

While designed for specific use cases, LPWANs may face challenges in meeting the diverse and dynamic demands of various applications. As more devices are connected, available bandwidth becomes more limited and contention increases. This can lead to congestion and decreased network scalability. So for large-scale deployments that need to be able to support a lot of traffic, controlling the traffic sent is necessary. This is particularly the case for two different types of scenarios. In specific applications, such as monitoring the environment, where only a certain amount of data is required within a given time, it is inefficient to transmit too much data, as it can cause network problems and waste energy. Meanwhile, sending too little data can be problematic. Telecommunication companies, for instance, are required to provide coverage and connectivity through LPWANs on the basis of Service Level Agreements (SLAs) with customers regarding the amount of capacity they can use. In the absence of a method to control traffic, customers may send more data than is allowed, causing network congestion. At present, there is no known algorithm capable of correctly addressing network congestion or managing traffic across multiple nodes in LPWANs.

#### 1.2.3.1 Specific applications scenario

-To further elaborate on the importance of traffic control in LPWANs for specific applications, let us examine a typical example of an agricultural monitoring scenario [38]-[40]. In this context, field-deployed sensors may be required to transmit soil moisture data on an hourly basis. To demonstrate the importance of traffic control in LPWANs for specific applications, we consider a typical example of an agricultural monitoring scenario. Using this as a case study, we emphasize the importance of traffic control in securing the efficiency of data collection and fulfilling application requirements, preventing network congestion, and conserving energy in LPWANs.

**Ensuring the data collection requirements of the application.** In a situation where agricultural sensors need to transmit soil moisture information on an hourly basis, traffic should be adapted to the application requirements. Regulating traffic ensures that each sensor only submits the needed amount of data. To be more specific, excessive data transmission may lead to network congestion and resource depletion. Yet, proper traffic management ensures efficient data collection that aligns with the application objectives. To optimize understanding of environmental conditions, it is important to ensure that data is neither excessive nor insufficient. Excess data can lead to traffic congestion and wasted energy, while insufficient data can obstruct the understanding of environmental conditions.

**Preventing network congestion.** Regulating communication among multiple soil moisture sensors is important to ensure network problems. Such control helps prevent bottlenecks by ensuring that devices alternate in various ways, including the implementation of priority schemes or advanced algorithms. By adopting these measures, sensors can transmit data systematically, mitigating the risk of collisions and enhancing their ability to comprehend the environment without interference or data loss.

**Energy conservation.** In remote agriculture areas where battery-powered soil moisture sensors must transmit data at hourly intervals; the excessive transmission of data can quickly drain their
batteries. Excessive data transmission can quickly drain their batteries, and replacing batteries on a regular basis can be a challenging task, especially in rural or hard-to-access (remote) areas. Therefore, Energy conservation is only possible by controlling the frequency of data transmission. This approach allows devices to operate for extended durations on a single charge, reducing the necessity for frequent maintenance.

1.2.3.2 Telecommunication companies scenario

Traffic control in LPWANs is extremely important for telecommunications operators. In this scenario, we take the case of a telecommunications company that offers connectivity services to multiple clients to demonstrate the importance of traffic control in LPWANs. In the subsequent discussions, we will use this example to emphasize the important role of traffic control in monitoring the Service-Level Agreements (SLAs) and ensuring fair resource allocation.

**Monitoring the service-level agreements (SLAs).** In a telecommunications company that provides connectivity services to a number of clients using an LPWAN, each of them has a specific SLA that defines the maximum capacity and the traffic model. Accordingly, traffic control mechanisms help to effectively prevent unauthorized connections and enforce the conditions set out in the SLAs as they ensure the highest level of security and compliance. It is important to note that unsanctioned connections not only violate contractual agreements but also pose potential security risks. Therefore, it is necessary to implement efficient traffic control measures to ensure adherence to SLAs. Efficient traffic control ensures adherence to SLAs. As It regulates the amount of data transmitted by each client and manages the number of nodes connected to the network. Failure to control traffic as per SLAs can lead to overuse of network resources, potential breaches of contractual agreements, and service quality degradation for all users, whereas traffic control safeguards the integrity of the network and protects against potential abuse.

**Ensuring fair resource allocation.** On a shared LPWAN infrastructure, equitable resource distribution is essential. With the use of traffic control, you can prevent a single client from dominating the network and ensure a satisfactory experience for all users. Nevertheless, in the absence of such control, network dominance by certain clients can be a cause for dissatisfaction among the rest.

**1.3 Objective and Contributions**

The primary objective of this thesis is to introduce a novel traffic control approach adapted to the unique requirements of LPWANs, specifically designed to meet the demands of particular application scenarios. Throughout our research, we have focused on a specific use case within LPWAN applications that necessitates a precise amount of data transmission. To illustrate, let us consider an application that requires a fixed number of measurements, denoted as*K*, to be transmitted within a designated time interval *ΔT*. This specific scenario represents a practical and common requirement in LPWAN applications where data must be collected and transmitted at predetermined intervals. The proposed approach effectively controls and improves the traffic flow within LPWANs, and is thus able to address the unique data transmission requirements of such scenarios.

To fulfill the thesis objective, our contributions are as follows:

* A Distributed and Probabilistic Traffic Control algorithm for LPWANs. It employs an additive increase and multiplicative reduction algorithm, along with a binary feedback message from the network server. I.e., a central server operates a control loop to impose a traffic policy that complies with the application requirements. The central server uses a downlink/feedback message to inform the nodes if the target was achieved or not. Upon receiving the control message, each node uses a local algorithm to modify its traffic intensity regardless of adjacent nodes.
* An enhanced LoRaSim simulator. We implemented and evaluated our proposed approach by significantly improving LoRasim. The above-mentioned improvements included the incorporation of down-link communication features and the integration of a battery depletion model.

* The use of two benchmark algorithms to compare the performance of our approach. The first benchmark is DiPTC against the LoRaWAN algorithm, and the other is against an optimal solution called Centralized Optimal Traffic Control (COTraC). In the LoRaWAN scenario, nodes follow a Poisson distribution to transmit packets, within the constraints of the application. The COTraC solution assumes a centralized network server with complete information about end devices, so it can establish an optimal scheduler that efficiently allocates resources based on factors such as residual energy, duty cycle, and LoRa parameters.

* An investigation of DiPTC parameters impact. The purpose of the investigation is to understand how different configurations of DiPTC parameters can impact the overall performance and dynamics of the LPWAN network. In addition, we engage in a comprehensive discussion to clarify the implications of these parameter settings and emphasize their adaptability to specific application requirements. This analytical approach not only broadens our understanding of DiPTC, but also contributes valuable knowledge for adapting the algorithm to suit diverse LPWAN applications with unique operational demands and for discussing parameter settings adjusted to specific application requirements.

* An assessment of DiPTC Performance in a multi-gateway setup. We have adapted the transmission approach for the feedback message into two distinctive modes: synchronous and round-robin. In the synchronous mode, all network gateways transmit the feedback message simultaneously to all the nodes within their respective coverage areas. Conversely, round-robin mode has a single chosen gateway responsible for transmitting the feedback message, and it is received solely by nodes within its areas.

## 1.4 Thesis Organization

The subsequent chapters of this thesis are organized as follows:

* Chapter 2- State of the art

This chapter provides a detailed analysis of the relevant research on traffic control in LPWANs; it also identifies current issues, approaches, and knowledge gaps. We first set the context for a thorough investigation by introducing LPWAN technologies. Then, we dive into LoRa/LoRaWAN, touching on the adaptive data rate mechanism, packet structure, network architecture, regulatory constraints, and the LoRa physical layer. Thereafter, we focus on LoRaWAN traffic control strategies, examining how to optimize LoRa parameters, frequency channels, and traffic scheduling methods.

* Chapter 3- Distributed and Probabilistic Traffic Control in LPWANs

In this chapter, we introduce a new traffic control algorithm specially designed for LPWANs called DiPTC. This chapter clarifies the fundamental principles, features, and expected benefits of the proposed algorithms. We begin by outlining the concept of DiPTC and stressing its relevance to LPWANs. Next, the underlying assumptions of the study are described in detail to provide the basis for a comprehensive understanding of the research context. The DiPTC algorithm then takes center stage, with an extended explanation of its inner workings that demonstrates its ability to handle the complexities of traffic control in LPWANs. The simulation model is a crucial component of this research, as it defines a dynamic wireless environment and provides a realistic setting for evaluating DiPTC performance. subsequently, this simulation reflects a
dynamic wireless environment and serves as an accurate framework for a realistic assessment of DiPTC performance. As the comparative analyses of the baseline LoRaWAN and COTraC reveal the unique strengths of the algorithm, the scalability analyses explore both horizontal and vertical dimensions, investigating the effects of varying traffic intensity and node scalability. The discussion extends to an examination of traffic control parameters and their implications and concludes with a summary of the findings, which presents a comprehensive understanding of the scientific explorations.

* Chapter 4- DiPTC Multi-Gateway Behaviour Study

This chapter examines the behavior of DiPTC with multiple gateways. It first outlines the objectives and scope of the study, presents the motivation for the study, and explains the practical implications and real-world applications to understand the behavior of DiPTC in multi-gate scenarios. Followed by a transparent presentation and discussion of the underlying assumptions of this study to provide a clear foundation for subsequent analyses. The architecture of the DiPTC multi-gateway setup is described in detail, considering both the structural composition of the multiple gateways and all relevant adaptations of the DiPTC algorithm to this environment. The simulation setup is described, with a focus on key parameters that simulate real scenarios. Then, the subsequent performance evaluation delves into various aspects, including scenarios, network parameters, horizontal and vertical scalability, the influence of traffic intensity, and the effects of node scalability. A thorough discussion of the results then follows to inspect the patterns and trends observed during the study, and the section concludes with a concise summary of the key insights.

* Chapter 5: General Conclusions and Future Works

The final chapter of this thesis, general conclusions, and future works summarize the comprehensive insights achieved from the DiPTC. To be more specific, conclusions briefly summarize and emphasize the contributions of DiPTC to our understanding of distributed and probabilistic traffic control in LPWANs in both mono and multi-gateway scenarios. Furthermore, we discuss future work that can further improve our proposed DiPTC. We also outline unexplored aspects, potential enhancements to the DiPTC algorithm, and strategies for expanding the study scope to address emerging challenges in LPWANs.

## 1.5 Publications

The articles listed in the ensuing subsections are a result of this PhD thesis.

### 1.5.1 Journals

1. Lasri, K., Ben Maissa, Y., Echabbi, L., Iova, O. and Valois, F. Probabilistic and distributed traffic control in LPWANs. AdHoc Networks, 2023.

### 1.5.2 Conferences

1. Lasri, K., Ben Maissa, Y., Echabbi, L., Iova, O. and Valois, F. A new distributed and probabilistic approach for traffic control in LPWANs. AINA, 2021.

2. Lasri, K., Echabbi, L., Iova, O., Maissa, Ben Maissa, Y. and Valois, F. Contrôle du trafic dans un réseau LPWAN: approche distribuée et probabiliste. CORES, 2020.
1.5.3 Posters

1 Lasri, K., Echabbi, L., Iova, O., Maissa, Ben Maissa, Y. and Valois, F. Traffic Control in LPWANs. Poster at the non-thematic days of the GDR RSD, Janvier 2023, Lyon, France.

2 Lasri, K., Ben Maissa, Y., Echabbi, L., Iova, O. and Valois, F. Data aggregation in LPWANs. Poster at the LPWAN Thematic Days, July 2019, Lyon, France.

3 Lasri, K., Ben Maissa, Y., Echabbi, L., Iova, O. and Valois, F. Data aggregation in LPWANs. Poster at RESCOM, June 2019, Nantes, France.
# Chapter 2

# State of the art

## Contents

<table><tr><td>2.1</td><td>Introduction</td><td>11</td></tr><tr><td>2.2</td><td>Overview on LPWANs</td><td>12</td></tr><tr><td>2.2.1</td><td>NB-IoT</td><td>12</td></tr><tr><td>2.2.2</td><td>LTE-M</td><td>12</td></tr><tr><td>2.2.3</td><td>LoRa and LoRAWAN</td><td>13</td></tr><tr><td>2.2.4</td><td>Ingenu Random Phase Multiple Access (RPMA)</td><td>13</td></tr><tr><td>2.2.5</td><td>Choosing the appropriate technology</td><td>13</td></tr><tr><td>2.3</td><td>Background on LoRa/LoRaWAN</td><td>14</td></tr><tr><td>2.3.1</td><td>LoRa Physical layer</td><td>15</td></tr><tr><td>2.3.1.1</td><td>LoRa Parameters</td><td>16</td></tr><tr><td>2.3.1.2</td><td>Impact of Parameter Variation on Network Performance</td><td>16</td></tr><tr><td>2.3.1.3</td><td>LoRa packet structure</td><td>18</td></tr><tr><td>2.3.2</td><td>LoRaWAN: Mac layer</td><td>19</td></tr><tr><td>2.3.2.1</td><td>LoRaWAN network architecture</td><td>19</td></tr><tr><td>2.3.2.2</td><td>Duty cycle limitation</td><td>21</td></tr><tr><td>2.3.2.3</td><td>Transmission time - Time On Air (TOA)</td><td>21</td></tr><tr><td>2.3.2.4</td><td>Adaptive Data Rate (ADR) mechanism</td><td>22</td></tr><tr><td>2.3.3</td><td>Regulatory Constraints</td><td>23</td></tr><tr><td>2.4</td><td>Traffic control approaches in LoRaWAN</td><td>24</td></tr><tr><td>2.4.1</td><td>LoRa parameters optimization</td><td>24</td></tr><tr><td>2.4.2</td><td>Frequency channel optimization</td><td>26</td></tr><tr><td>2.4.3</td><td>Traffic scheduling</td><td>28</td></tr><tr><td>2.5</td><td>Discussion and Positioning</td><td>29</td></tr><tr><td>2.5.1</td><td>Discussion</td><td>29</td></tr><tr><td>2.5.2</td><td>Positioning</td><td>32</td></tr><tr><td>2.6</td><td>Conclusion</td><td>32</td></tr></table>

## 2.1 Introduction

In this chapter, we first present a background on LPWANs, with a focus on LoRaWANs, and then examine the current state of the art in traffic control for LoRa networks. We initially provide a general overview of LPWAN technologies in section 2.2, followed by a close scrutiny of LoraWAN technology in section 2.3. In section 2.3, we present the background of LoRa/LoRaWAN, providing insights into the physical layer of LoRa, the network architecture of LoRaWAN, and the regulatory constraints as well as the Adaptive Data Rate (ADR) mechanism. Subsequently, section 2.4 discusses the traffic control approaches deployed in LoRaWAN, as highlighted in the existing literature. Section 2.5 identifies the
limitations of the current literature approaches, establishes the basis for our approach, and situates it
within the existing literature.

## 2.2 Overview on LPWANs

The emergence of the Internet of Things (IoT) has led to the development of communication technologies that are capable of fulfilling the unique demands of extensive and diverse sensor networks. Low Power Wide Area Networks (LPWANs) are an essential component in this domain, as they enable the connectivity of countless devices using energy efficiency and cost-effectiveness [7], [41], [42]. Several LPWAN technologies have been developed and designed for specific applications [43], such as Narrowband IoT (NB-IoT), Long-Term Evolution for Machines (LTE-M), Long Range Wide Area Network (LoRaWAN), and Ingenu Random Phase Multiple Access (Ingenu RPMA).

### 2.2.1 NB-IoT

Narrowband IoT (NB-IoT) is a prominent Low Power Wide Area Network (LPWAN) technology that has evolved within the 3rd Generation Partnership Project (3GPP) Release 13 [44]. As It demonstrates adaptability in deployment utilizing a small portion of the available spectrum in the Long-Term Evolution (LTE) bands. In the licensed frequency bands of 700 MHz, 800 MHz and 900 MHz, NB-IoT cooperates harmoniously with other 3GPP technologies including Global System for Mobile Communications (GSM) and LTE.

In terms of communication, it is worth emphasising that NB-IoT provides bidirectional support by using Orthogonal Frequency Division Multiple Access (OFDMA) for downlink and Single Carrier Frequency Division Multiple Access (SC-FDMA) for uplink transmissions [42]. Each NB-IoT cell requires a bandwidth of at least 180 kHz for efficient communication and can connect up to 50,000 devices [45]. Notably, this technology is highly versatile and can enable deployment as a standalone carrier or the use of frequencies above 180 kHz in the physical resource block of LTE.

The NB-IoT design approach optimizes and minimizes LTE functionalities to accommodate specific applications with infrequent data transmissions and tight power constraints [15]. i.e, this fundamental aspect of NB-IoT supports data rates of 200 kbps for downlink and 20 kbps for uplink transmissions, allowing a maximum payload size of up to 1600 Bytes per message.

To put it succinctly, with its strategic deployment flexibility, compatibility with existing technologies, and careful optimization for low-power and intermittent data transmission, NB-IoT is an attractive option for various IoT applications ranging from smart cities [46] to industrial monitoring [47].

### 2.2.2 LTE-M

LTE-M is a 3GPP standard-based technology that operates within the licensed LTE spectrum. It is an essential link for machine-to-machine (M2M) communication and aligns seamlessly with current LTE networks. It also enables compatibility with existing LTE networks and facilitates a seamless transition from older 2G and 3G networks. Significantly, it offers enhanced coverage compared to traditional LTE networks, providing coverage for M2M applications similar to 5G networks. Thus, LTE-M is considered an evolutionary step towards 5G M2M solutions [19].

The primary objective of LTE-M is to provide adaptable data rates that can be adapted to different real-time and non-real-time applications. Specifically, this flexibility is underscored by its support for low-latency and deferred traffic applications that can operate with latencies in the multi-second time span. Specifically, this flexibility is underscored by its support for low-latency and deferred traffic applications that can operate with latencies in the multi-second time span. Among other features, LTE-M has low power requirements and can operate at low bandwidths up to 1 Mbps. And it supports
devices with a wide range of message sizes, which further enhances its applicability across a variety of IoT use cases.

LTE-M builds upon the foundation of LTE and inherits standard functionality, such as mobility. However, this applies more to typical scenarios rather than extended coverage situations [48]. Additionally, LTE-M has a significant advantage in its software upgrade-ability from LTE, ensuring adaptability to ever-evolving technological environments. It supports over 100,000 devices per base station, and is particularly advantageous for applications with very low data-throughput requirements. [43, 45]. This versatile approach positions LTE-M as a resilient and future-proof solution that addresses the connectivity needs of diverse IoT applications, while aligning with the evolution to 5G M2M solutions.

### 2.2.3 LoRa and LoRAWAN

LoRa is a physical layer technology operating in the unlicensed sub-GHz Industrial, Scientific, and Medical (ISM) band and is based on the Chirped Spread Spectrum (CSS) technique [49]. The CSS uses wideband linear frequency modulation, which causes the carrier frequency to fluctuate over a fixed period of time. Meanwhile, LoRa employs pure ALOHA principles and supports various ISM frequencies, including 868 MHz (Europe), 915 MHz (North America), and 433 MHz (Asia). In essence, LoRa's fundamental structure relies on a single-hop mechanism. Here, LoRa sensor nodes transmit messages to a central server via gateways. The speed of LoRa data transmission ranges from 300 bps to 50 kbps, as determined by the spreading factor and channel bandwidth settings.

Likewise, LoRa transmissions exhibit quasi-orthogonality with distinct spreading factors, thereby enabling multiple simultaneous transmissions at different spreading factors (SFs) [12], [50]. In order to effectively integrate LoRa into the Internet landscape, the LoRa Alliance has developed LoRaWAN [51], that covers network and upper-layer functions. In particular, LoRaWAN introduces three classes of end devices designed for the diverse requirements of a wide range of IoT applications, including latency considerations. Given LoRa's capabilities in long-range and low-power transmission, it stands out as an ideal candidate for efficient and extensive reach within the Internet of Things (IoT).

### 2.2.4 Ingenu Random Phase Multiple Access (RPMA)

Ingenu utilizes a proprietary communication technique known as Random Phase Multiple Access (RPMA), which is characterized by more flexible spectrum regulations contributing to increased throughput and capacity [52]. Ingenu is the exclusive developer and manufacturer of the associated hardware; it is based on Direct Sequence Spread Spectrum and achieves a peak data rate of up to 80 kbps. Ingenu operates within the 2.4 GHz band, and faces shorter range limitations compared to LoRa, as well as increased propagation loss caused by obstructions from water or packed soil. Moreover, this frequency band is widely shared with other personal and local area network technologies such as Wi-Fi, Bluetooth, and ZigBee, resulting in congestion and increased interference [45]. Despite these challenges, Ingenu offers advantages such as low power consumption, cost-effectiveness, robustness, and bi-directional communication. To enhance transmission reliability, the system incorporates acknowledged transmission. However, the high data rates of Ingenu contribute to increased power consumption compared to LoRa [53].

Though Ingenu was initially designed for the utility, oil, and gas sectors, it has now expanded to cover a wide range of applications, such as smart city initiatives and agricultural applications. Among these are smart city initiatives, agricultural applications, asset tracking, fleet management, and smart grid implementations.

### 2.2.5 Choosing the appropriate technology

Upon executing our performance assessment, we deliberately opted for LoRaWAN as the focal technology. Thereby, this selection is based on a meticulous validation of LoRaWAN's strengths, in
particular its remarkable adaptability, cost efficiency in infrastructure deployment and effective use of
unlicensed frequency bands [10].

LoRaWAN's adaptability is an important feature that strongly influenced our decision. With its ability to meet a wide range of communication requirements and variable data rates, it is suitable for a wide range of IoT applications [12]. LoRaWAN can therefore meet the specific requirements of our performance evaluation, and offers the requisite versatility for thorough testing and analysis. Another key strength of LoRaWAN is its reduced infrastructure costs [10]. With minimal gateway necessities and the capacity to cover vast regions with fewer infrastructure components, it provides a cost-effective option for scalable IoT implementations. This financial efficiency is aligned with our evaluation objectives, which enable us to optimize resources while maintaining a high level of performance. Ultimately, the efficient exploitation of unlicensed spectrum is key to the popularity of LoRaWAN [54]. The use of unlicensed spectrum not only reduces regulatory complexities, but also encourages an open ecosystem in which devices from various manufacturers can coherently interact. Accordingly, it is in line with our aim of establishing a scalable, interoperable IoT environment, paving the way for smooth integration and cooperation across different devices.

**LoRaWAN vs. NB-IoT** [55], [56]. LoRaWAN is unequivocally an excellent option for scenarios that require extensive coverage without high infrastructure costs; its open standards and long-range capabilities make it the most reliable and cost-effective choice available. Plus, its ability to support variable data rates means it can be adapted to a wide range of applications, thus guaranteeing optimal performance in all situations. Although NB-IoT leverages existing cellular infrastructure and supports high device density, it can face challenges in terms of infrastructure costs and limited acknowledgment capabilities. Hence, LoRaWAN's ability to support scalable and interoperable IoT solutions positions it as an appealing alternative for applications that value flexibility, cost-effectiveness and reliable long-range communications.

**LoRaWAN vs. LTE-M** [53], [57]. LoRaWAN brings an advantage in certain use cases, with an emphasis on long-distance communication and minimized infrastructure costs. LoRaWAN flexibility in handling varying data rates becomes an essential characteristic, enabling efficient communication across a range of IoT applications. LTE-M, on the other hand, while providing faster data rates, frequently comes with higher infrastructure costs. LoRaWAN open infrastructure and lower power consumption add to its appeal, especially in circumstances where extended battery life and cost efficiency are critical.

**LoRaWAN vs. Ingenu** [19], [53], [57]. LoRaWAN is notable for having a low-cost infrastructure that uses unlicensed frequency bands for long-distance communication. Whereas, Ingenu relies on proprietary technology to provide superior connection capacity, yet may have a higher cost of deployment. LoRaWAN fosters a collaborative environment with open standards and interoperable infrastructure, so devices from multiple manufacturers can easily connect. Furthermore, LoRaWAN's ability to reduce infrastructure costs through minimizing gateway requirements adds to its popularity for scalable IoT applications.

In summary, LoRaWAN is a compelling choice for scalable and cost-effective IoT deployments due to its adaptability, low infrastructure costs, and efficient use of unlicensed frequency bands. It provides a robust foundation for the evolving field of connected devices [58]. In the next section, we provide a detailed introduction to LoRaWAN.

## 2.3 Background on LoRa/LoRaWAN

LoRa technology is a low-power wide area network (LPWAN) communication system that uses RF modulation to enable long-distance communication. Because of its vast network penetration and capacity to build independent low-power wireless connections, it has piqued the interest of academia and industry. LoRaWAN, which explains the network model and connectivity procedures, and LoRa PHY, which gives information on the modulation approach, are the two components of the technology (Fig. 2.1). LoRa technology performance varies based on the environment and the presence of barriers
between transceivers. It has been utilized to optimize power usage and monitoring in a variety of applications, including smart agriculture and energy monitoring.

<figure><img src="image_7.png" /><figcaption>FIGURE 2.1: LoRa Network Layer [59]</figcaption></figure>

### 2.3.1 LoRa Physical layer

LoRa is a patented radio standard for wide-area networks developed by Cycleo, a company in Grenoble, France. Cycleo was later acquired by the semiconductor firm Semtec [60]. This approach employs a Chirp Spread Spectrum (CSS) modulation to improve noise robustness, allowing Internet-connected apps to communicate with low-power devices across long-distance wireless transmission [61], [62].

In Chirp Spread Spectrum (CSS) modulation, spreading is achieved by generating a continuously varying frequency chirp signal. The advantage of this method is that the synchronization and frequency offsets between the transmitter and the receiver are equivalent, significantly reducing receiver design complexity. This spreading enables resistance to interference and makes LoRa robust to channel noise. Maintaining these chirps within a wider spreading spectrum also reduces multi-path fading and thus improves performance in urban environments [63]. CSS modulation techniques are characterized by their low energy consumption and resistance to channel impairments.

The signal emitted by LoRa, modulated in chirp, is formed of several symbols. Each symbol is represented by ($N = 2^{SF}$) chirps, a chirp represents impulses of a spread spectrum code, such as a sequence of pseudo-noise (PN) code, and contains SF bits, meaning that if the transmission uses SF8 (SF = 8), a symbol will contain 8 bits and is represented by $2^8$ chips. Thus, the higher the value of SF, the greater the number of chips used to represent a symbol. The transmission duration of a symbol is $T_s$ seconds inversely proportional to the bandwidth BW, Equation (2.1). The symbol rate $D_s$ is therefore represented by Equation (2.2). Logically, the higher the bandwidth, the higher the symbol rate will be. As each symbol comprises SF bits, then the binary rate $D_b$ is defined by Equation (2.3).

$$T_s = \frac{2^{SF}}{BW} \qquad (2.1)$$

$$D_s = \frac{1}{T_s} \qquad (2.2)$$

$$D_b = SF * D_s \qquad (2.3)$$

This modulation technique offers a variety of data rates for various bandwidths. In LoRa networks, the data rate is chosen based on the range requirements. This capability to modulate different sampling rates gives LoRa the advantage of being able to decode many signals simultaneously. These different
sampling rates are known as spreading factors (SF). These SFs describe the extent of spectral bandwidth occupancy increase as well as the coding gain of spread spectrum systems.

Unlike traditional modulation techniques, which use fixed-frequency carriers, CSS dynamic frequency variation contributes to LoRa exceptional long-range reach. This approach allows LoRa devices to navigate through challenging environments, including urban landscapes with obstacles, by leveraging the unique propagation characteristics of chirp signals

### 2.3.1.1 LoRa Parameters

LoRa PHY layer is not only about chirp signals; it encompasses critical parameters such as transmission power (TP), carrier frequency (CF), spreading factor (SF), bandwidth (BW), and coding rate (CR) [51]. The choice of these factors affects transmission range, energy consumption, and noise resilience [12], [25], [64].

**Transmission Power (TP).** The transmission power in LoRa radio refers to the adjustable strength of the signal emitted during communication. In the realm of LoRa technology, this parameter can be fine-tuned within a range spanning from -4 dBm to 20 dBm, allowing for precise adjustments in 1 dB steps. However, practical hardware implementation constraints often lead to a more restricted operational range, typically confined to levels between 2 dBm and 20 dBm. It is noteworthy that certain hardware limitations impose further constraints on the utilization of higher power levels. Specifically, power levels exceeding 17 dBm are subject to a stringent 1% duty cycle restriction. This means that transmissions at power levels higher than 17 dBm can only occur for a maximum of 1% of the time, ensuring compliance with regulatory and hardware constraints. These nuanced considerations in transmission power management play a crucial role in optimizing the efficiency, reliability, and regulatory compliance of LoRa communication systems

**Carrier Frequency (CF).** The carrier frequency is programmable in increments of 61 Hz from 137 MHz to 1020 MHz. The specific LoRa chip used may have a frequency restriction of 860 MHz to 1020 MHz.

**Spreading Factor (SF).** The ratio of the chip rate to the symbol rate is called SF. In addition to increasing the packet duration, a higher spreading factor raises the Signal to Noise Ratio (SNR), sensitivity, and range. Chip counts per symbol are determined using the $2^{SF}$ approach. For instance, 4096 chips or symbols are employed with an SF of 12 (SF12). Every SF increases results in halves of the transmission rate, which in turn doubles the transmission period and, eventually, the energy consumption. You can choose a spreading factor between six and twelve.

**Bandwidth (BW).** The width of the frequencies in the transmission band is known as BW. Increased BW results in a larger data rate and a shorter time spent in the air, but it also reduces sensitivity due to the integration of extra noise. A lower BW results in a lower data flow but a higher sensitivity. Additionally, lower BW calls for more precise crystals (less ppm). A chip rate equivalent to the bandwidth is used to transmit data. Therefore, a chip rate of 125 kbps is equivalent to a bandwidth of 125 kHz. A common LoRa network operates at 500 kHz, 250 kHz, or 125 kHz, while the bandwidth can be set within a range of 7.8 kHz to 500 kHz. It is also necessary to use a temperature-compensated crystal oscillator (TCXO) for bandwidths smaller than 62.5 kHz.

**Coding Rate (CR).** The LoRa modem CR FEC rate, which protects against interference bursts, can be adjusted to 4/5, 4/6, 4/7, or 4/8. More protection is provided by a higher CR, but the flying duration is longer. Since the payload CR is stored in the packet header, radios with different CRs (but the same CF, SF, and BW) can still interact with one another if they utilize an explicit header.

### 2.3.1.2 Impact of Parameter Variation on Network Performance

The selection of transmission parameters significantly influences communication performance. Specifically, choosing a combination of transmission parameters directly impacts throughput (data rate) and Time on Air (ToA), transmission range, interference resilience, and energy consumption. Balancing
communication performance and energy consumption is often desirable, given that nodes are battery-powered, with the objective of maximizing the network's lifespan while ensuring the required Quality of Service (QoS). Another crucial factor affecting energy consumption is the transmission time (ToA) required to transmit a packet, which, in turn, depends on factors such as packet size and the chosen data rate (DR).

Table 2.1 illustrates the impact of different transmission parameters on various performance indicators of the LoRaWAN network. It demonstrates how variations in transmission parameters can affect key metrics such as throughput, transmission range, and energy consumption. Additionally, it underscores the importance of carefully selecting transmission configurations to achieve the desired balance between communication efficiency and energy consumption. Optimizing transmission parameters is essential for achieving efficient and reliable communication in practical deployments, especially in battery-powered networks. By considering factors such as data rate, packet size, and transmission power, network designers can adapt configurations to meet specific application requirements effectively.

<table><caption>TABLE 2.1: Impact of Parameter Variation on LoRaWAN Performance.</caption><thead><tr><td></td><td>Data Rate</td><td>Energie (TOA)</td><td>Range (RSSI)</td><td>Interferences</td></tr></thead><tbody><tr><td>SF ↑</td><td>-</td><td>+</td><td>+</td><td>+</td></tr><tr><td>BW ↑</td><td>+</td><td>-</td><td>-</td><td>-</td></tr><tr><td>TP ↑</td><td>NA</td><td>+</td><td>+</td><td>+</td></tr><tr><td>CR ↑</td><td>+</td><td>-</td><td>-</td><td>-</td></tr></tbody></table>

Increasing the Spreading Factor (SF) enhances the Received Signal Strength Indicator (RSSI) for a given distance between the node and its gateway, resulting in an extended transmission range, as it is proportionally dependent. However, this leads to an increase in the transmission time (ToA) and consequently, energy consumption. Given that the SF ranges from 7 to 12, a higher value increases the receiver's sensitivity at the expense of a lower data rate (DR). Conversely, a lower SF value increases the DR and reduces ToA (thus lowering energy consumption). For instance, Table 2.2 presents the DRs specified by the LoRaWAN standard in [64]. However, there are approximately 6720 possible combinations referring to different DRs. Furthermore, the distance from the node to the gateway also affects RSSI. The farther the node is from the gateway, the weaker the received signal, necessitating a higher SF to maintain the RSSI above the threshold for correct signal decoding.

<table><caption>TABLE 2.2: Data Rate codes provided by the LoRaWAN specification [64].</caption><thead><tr><td>Code DR</td><td>Configuration</td><td>DR (bps)</td></tr></thead><tbody><tr><td>0</td><td>SF12 - 125 kHz</td><td>250</td></tr><tr><td>0</td><td>SF11 - 125 kHz</td><td>440</td></tr><tr><td>0</td><td>SF10 - 125 kHz</td><td>980</td></tr><tr><td>0</td><td>SF9 - 125 kHz</td><td>1760</td></tr><tr><td>0</td><td>SF8 - 125 kHz</td><td>3125</td></tr><tr><td>0</td><td>SF7 - 125 kHz</td><td>5470</td></tr><tr><td>0</td><td>SF7 - 250 kHz</td><td>11000</td></tr><tr><td>DR8-DR15</td><td>RFU</td><td>Not defined</td></tr></tbody></table>

In LoRaWAN networks, the Transmission Power (TP) of a data packet is adjustable according to requirements. Increasing TP consumes more energy but expands the signal range. However, a high TP value may increase the likelihood of collisions, resulting in more interference. Additionally, TP levels are regulated by Electromagnetic Compatibility (EMC) standards. Finally, setting a low Coding Rate (CR) value (e.g., 4/8) provides better protection against errors and interference, leading to slower transmission and consequently, higher energy consumption.
In summary, enhancing one performance indicator by varying transmission parameters often comes at the expense of degrading another indicator. It is desirable to choose a configuration that minimizes energy consumption while meeting the application's network performance requirements. However, determining parameters that reduce the cost of transmission energy while maintaining communication performance requirements is a challenge. Battery-powered nodes need to select appropriate transmission parameters in a LoRaWAN network. Poor choices could lead to a hundredfold reduction in node lifespan, rendering many commercial applications impractical [65].

### 2.3.1.3 LoRa packet structure

The intricacies of the LoRa packet structure play an important role in shaping the efficiency and reliability of LoRa communication. Illustrated in Fig. 2.2, a LoRa packet is meticulously organized to ensure robust transmission in the challenging environments often encountered in long-range communication [25].

<figure><img src="image_8.png" /><figcaption>FIGURE 2.2: LoRa packet format [25]. White-colored sections can be optional, while grey-colored areas must be present.</figcaption></figure>

**Preamble.** The preamble is a segment programmable in length from 6 to 65535 symbols. The radio appends an additional 4.25 symbols to this section. The preamble serves as a synchronization signal, allowing the receiving end to align itself with the incoming transmission.

**Optional Header.** The optional header provides important information about the payload. This includes details on the payload length, Forward Error Correction (FEC) rate, and an indication of the optional 16-bit Cyclic Redundancy Check (CRC) for the payload. The header is consistently transmitted with a 4/8 FEC rate, it possesses its own CRC for added integrity assurance. The optional nature of this section allows for flexibility in adapting to diverse application requirements.

**Payload.** The payload is an essential component that carries the actual data. The payload can vary in size from 1 to 255 bytes, accommodating a spectrum of application needs. This adaptability is particularly valuable in IoT scenarios where data sizes may differ significantly.

**Optional Payload (CRC).** The optional payload includes an additional 16-bit CRC. This provides an extra layer of error checking for the payload, contributing to the overall reliability of the transmitted data. The optional nature of this CRC allows for a trade-off between data integrity and overhead, enabling customization based on the specific demands of the application.

**Time on Air (ToA).** The LoRa transmission airtime is determined by the combination of SF, BW, and CR in addition to the payload size. Using the Semtech LoRa modem calculator, one may determine how long a transmission will last [66]. A data packet airtime can vary significantly based on the communication settings chosen. A 20-byte transmission, for instance, can take anything from 9 ms to 2.2 s. Therefore, the choice of communication parameters greatly affects how scalable a LoRa network may be.

The LoRa packet structure is designed to address the challenges of long-range communication. The preamble establishes synchronization, the optional header presents flexibility and information about the payload, the payload itself caters to varying data sizes, and the optional payload CRC enhances data integrity. This thoughtful organization ensures that LoRa technology delivers efficient, reliable, and customizable communication for a diverse range of applications.
### 2.3.2 LoRaWAN: Mac layer

LoRaWAN corresponds to the MAC layer of the LoRa network. Unlike the physical layer of LoRa, it is open and maintained by the group known as the LoRa Alliance [64]. The LoRa Alliance describes LoRaWAN as follows: "LoRaWAN™ is a low-power wide-area network (LPWAN) specification designed for battery-operated wireless nodes in regional, national, or international environments, or global networks. LoRaWAN targets key requirements of the Internet of Things, such as secure bidirectional communication, mobility, and localization. The LoRaWAN specification ensures seamless interoperability among smart objects without requiring complex local installations, empowering users, developers, and businesses to facilitate the deployment of the Internet of Things."

#### 2.3.2.1 LoRaWAN network architecture

LoRaWAN, a MAC (Medium Access Control) protocol proposed by the LoRa Alliance, plays a primordial role in shaping the network architecture and coordinating communication layers above the LoRa physical layer [12]. The protocol facilitates communication between end nodes, which are objects embedded with low-power communication devices, and the LoRaWAN network through gateways. This communication is achieved using an ALOHA-based protocol, where end nodes, without direct peering with a specific gateway, transmit messages to nearby gateways.

The Aloha protocol is well-known as a straightforward and widely used communication approach [36], [37]. Operating on the principles of random access and contention, this protocol empowers devices to transmit data without adhering to a synchronized time schedule. Within the Aloha protocol, nodes execute data transmissions at their discretion, free from the constraints of predefined time slots. This decentralized approach allows nodes to operate independently. However, the simultaneous transmission attempts by multiple nodes introduce the prospect of collisions, where two or more nodes transmit at the same time, resulting in data corruption and loss. Following the transmission, a node anticipates an acknowledgment (ACK) from the receiver, typically the gateway in LoRaWAN. The receipt of an ACK signifies a successful transmission, while its absence prompts the node to assume a collision. In such cases, the node may manage a re-transmission after a randomized backoff period.

<figure><img src="image_9.png" /><figcaption>FIGURE 2.3: LoRaWAN network topology [67]</figcaption></figure>

In the LoRaWAN architecture, each gateway within range receives messages from end nodes and forwards them to the connected network server. This process is illustrated in Fig. 2.3 The network server, in turn, manages message deduplication.

The fundamental components of a LoRaWAN network are outlined as follows:
**End nodes.** The end nodes are objects with low-power communication devices, typically powered by batteries. They might be sensors, actuators, or both. They use LoRa modulation for wireless access to the LoRaWAN network via gateways. They operate in Class A by default, with the possibility of implying other media access protocols by using one of the three classes A, B, or C.

Fig. 2.4 illustrates the class time difference of LoRaWAN nodes. Class A is often used for battery-powered devices, with scheduled reception windows and sleep mode achieving energy economy. Class A employs two designated reception windows after each uplink transmission. As illustrated in Fig. 2.4, only downlink transmissions are permitted at the beginning of these windows. Concerning the initial window, downlink transmissions are executed with identical channel and data rate configurations as the preceding uplink transmission. However, the subsequent window utilizes a fixed setting, specifically DR0 (SF12/125 KHz) at 869.525 MHz. Class B devices add scheduled receive windows for downlink messages to Class A devices. Although there is no prior communication from the nodes, gateways enhance their receptivity by sending synchronization beacons. The reception windows available for Class B devices exceed that of Class A; however, this increased functionality results in higher energy consumption. Following each Uplink transmission, supplementary regular reception windows are activated, supplementing the synchronized opening of dual standard windows—known as ping slots. Class C nodes perpetually maintain open reception windows, only closing them upon receiving a packet from the upper layer. This leads to increased power consumption due to Class C nodes continuously receiving, which is not compatible with Class B. Moreover, Class C supporting devices lack implementation of Class B. The choice of operational mode or class is determined by the specific application. Authors in [10] propose selecting the appropriate class by examining critters such as access method, collision, downlink latency, real time support, and energy consumption.

<figure><img src="image_10.png" /><figcaption>FIGURE 2.4: Class time diagram of LoRaWAN devices [10].</figcaption></figure>

**Gateways.** The gateways are antenna-equipped devices that receive broadcasts from end nodes and relay data back to them. Gateways registered to the LoRaWAN network send messages to the network server over a backbone IP network using a variety of communication protocols such as cellular networks, Wi-Fi, Ethernet, fiber-optic, or 2.4 GHz radio links.

**Network Server (NS).** The Network Server is a primordial component within the LoRaWAN infrastructure, responsible for managing end-to-end communication within the network. Its primary function is to direct messages from end nodes to the appropriate application server and ensure that the messages are relayed to the intended destination nodes. Additionally, the Network Server is in charge of decoding the packets that contain data and commands, managing the Adaptive Data Rate (ADR) to optimize network performance, providing Over-The-Air-Activation (OTAA) for secure device activation, and confirming the successful delivery of data messages.
**Application Server (AS).** The application server hosts the end-user application, enabling users to interact with it and transfer data to end nodes. Additionally, the application server analyzes sensor data, thereby improving the overall functionality of the LoRaWAN network.

The collaborative operation of end nodes, gateways, network servers, and application servers forms the foundation of LoRaWAN, offering a robust and efficient communication framework for IoT applications across diverse industries.

### 2.3.2.2 Duty cycle limitation

Given that the ISM frequency band is utilized by various radio technologies, collisions are a common occurrence. To address this issue, ETSI regulations (European Telecommunications Standards Institute) offer two options: either implementing a duty cycle limitation, which sets the maximum time a node can transmit or employing a transmission management technique based on channel listening known as Listen Before Talk Adaptive Frequency Agility (LBT AFA), similar to WiFi's CSMA. The current LoRaWAN specification exclusively adopts transmissions limited by duty cycle to comply with ETSI regulations[64].

In Europe and Africa, nodes operate within the open ISM band at 868 MHz and must adhere to ETSI regulations for wideband modulation. This allows LoRa nodes to operate within frequencies ranging from 863 MHz to 870 MHz, albeit with restrictions on transmission duration. The requirements for maximum Duty Cycle for spectrum access are stringent and can vary significantly across bands. According to European regional parameters for LoRa, all nodes must implement at least three channels with a bandwidth of 125 KHz, centered at 868.1 MHz, 868.3 MHz, and 868.5 MHz. Additionally, five extra channels are specified in the LoRa specification. All of these channels are subject to a Duty Cycle limit of 1%, equivalent to 36 seconds per hour.

In addition, facing interference and packet losses caused by the use of the same spreading factor (SF) on the same channel, for instance, packet retransmissions are performed to increase the chances of successful reception. However, a 1% Duty Cycle could diminish these chances and result in more losses due to the prohibition of continuing retransmissions beyond the duty cycle limitation of 36 seconds per hour.

### 2.3.2.3 Transmission time - Time On Air (TOA)

The Transmission Time (ToA) is defined as the duration elapsed from the transmission of the first bit of information to the transmission of the last bit [64]. The total ToA comprises the sum of the preamble transmission time and the payload transmission time.

$$TOA_{Frame} = T_{preamble} + T_{payload} \qquad (2.4)$$

$$T_{payload} = PL_{sym} * T_{sym} \qquad (2.5)$$

$$T_{sym} = \frac{2^{SF}}{BW} \qquad (2.6)$$

$$T_{preamble} = (n_{preamble} + 4.25) * T_{sym} \qquad (2.7)$$

$$PL_{sym} = 8 + \max(\text{ceil}(\frac{8PL - 4SF + 28 + 16 - 20H}{4(SF - 2DE)}), 0) \qquad (2.8)$$

The duration of payload transmission is then the transmission time of a symbol multiplied by the number of payload symbols ($PL_{sym}$), as defined in Equation (2.4). $T_{sym}$ represents the time required to send $2^{SF}$ chirps and is calculated using Equation (2.6), where SF is the spreading factor, and BW is the bandwidth.

Equation (2.7) defines the preamble duration, where $n_{preamble}$ is the number of preamble symbols, typically set to 8.
The number of symbols comprising the payload and packet header is given by Equation (2.8), where PL is the payload size in bytes, CR is the coding rate used (between 1 and 4), H is the header option (0 if enabled, 1 otherwise), and DE is set to 1 if low data rate optimization is enabled, otherwise 0.

Excluding the spreading factor, the values of these constants have been defaulted and provided by the firmware used. Solving Equation (2.4) with n preamble = 8, PL = 10 (for instance), CR = 1, H = 1, SF = 12, BW = 125, and DR = 0 results in a total ToA of approximately 990 ms, allowing for the transmission of multiple packets of up to 59 bytes each (according to LoRaWAN regional parameters) within a 36-second cycle [64].

### 2.3.2.4 Adaptive Data Rate (ADR) mechanism

Adaptive Data Rate (ADR) [64], [68]-[70], is a key feature in LoRa (Long Range) technology and LoRaWAN networks that dynamically adjust the communication parameters of LoRa end devices to optimize performance and efficiency. ADR plays a crucial role in enhancing the reliability, energy efficiency, and overall scalability of LoRa-based IoT deployments.

The spreading factor, or SF, is an important LoRa modulation parameter that establishes the length of each broadcast signal. A longer range is achieved at lower data rates with higher SF values. Depending on the current state of the network, ADR dynamically modifies SF to balance the requirements for range and data rate. ADR also modifies the devices transmission power, by dynamically adjusting SF and TP parameters, minimizing time in the air, and reducing collision risk. It also extends battery life for battery-operated devices by adjusting communication parameters based on distance from the gateway and signal quality, ensuring minimal energy consumption for reliable communication.

<table><caption>TABLE 2.3: Influence of Spreading Factors and Bandwidth on the bit rate [64].</caption><thead><tr><td>Spreading factor</td><td>Bandwidth</td><td>Bit rate (kbits/s)</td></tr></thead><tbody><tr><td>7</td><td>125</td><td>5.5</td></tr><tr><td>7</td><td>250</td><td>10.9</td></tr><tr><td>7</td><td>500</td><td>21.9</td></tr></tbody></table>

A lower spreading factor yields a higher bit rate for a fixed bandwidth and coding rate as opposed to a larger spreading factor. For instance, SF7 offers a bit rate that is higher than SF12. For a fixed spreading factor and coding rate, doubling the bandwidth likewise twice the bit rate. The bit rates for bandwidths of 125, 250, and 500 kHz, computed using the SF7 and Coding Rate (CR) = 1, are shown in the following table Tab. 2.3.

A signal modulated with a bigger spreading factor can be received with fewer errors and travel a longer distance than a signal modulated with a lower spreading factor because larger spreading factors equate to larger processing gains. A signal modulated with the SF12, for instance, has a greater range of propagation than a signal modulated with the SF7.

Transmitting a fixed amount of data (payload) with a greater spreading factor and a fixed bandwidth requires a longer time on air than transmitting it with a lower spreading factor. A higher receiver sensitivity is achieved with higher spreading factors. Higher spreading factors are typically used by LoRa in weak signal situations. The impact of spreading factors on the receiver sensitivity is displayed in the following Tab. 2.4.

LoRaWAN networks can adapt to changing conditions like device mobility, interference, or environmental changes, ensuring strong and reliable connections. ADR helps devices adapt to these dynamic conditions while ensuring regulatory compliance by dynamically adjusting transmission parameters within legal limits. This helps LoRaWAN networks maintain strong and reliable connections despite imposed constraints on unlicensed spectrum use.
<table><caption>TABLE 2.4: Spreading factors impact on the receiver sensitivity [64].</caption><thead><tr><td>Spreading factor</td><td>Receiver sensitivity BW=125 kHz</td></tr></thead><tbody><tr><td>SF7</td><td>-123 dBm</td></tr><tr><td>SF8</td><td>-126 dBm</td></tr><tr><td>SF9</td><td>-129 dBm</td></tr><tr><td>SF10</td><td>-132 dBm</td></tr><tr><td>SF11</td><td>-134.5 dBm</td></tr><tr><td>SF12</td><td>-137 dBm</td></tr></tbody></table>

### 2.3.3 Regulatory Constraints

LoRa (Long Range) technology operates in specific frequency bands that are regulated by authorities to ensure efficient use of the radio spectrum and prevent interference with other wireless devices. The regulatory constraints for LoRa devices vary across different regions, and compliance with these constraints is crucial for lawful and effective operation [71]. Below are detailed explanations of key regulatory constraints for LoRa devices:

**Frequency allocation.** LoRa devices typically operate in license-exempt bands, which means users do not need a specific license to operate within these frequency ranges. Frequency bands may differ by region. For instance, in Africa and Europe, the 863 MHz to 870 MHz band is commonly used for LoRa, while in the United States, the 902 MHz to 928 MHz band is often utilized.

**CEPT/ERC/REC 70-03 standard (Africa and Europe).** In Africa and Europe, the CEPT/ERC/REC 70-03 standard defines the regulatory constraints for Short Range Devices (SRD), including LoRa. The license-exempt band for LoRa is referred to as 'Annex 1 h' [71] and spans from 863 MHz to 870 MHz. This band is subdivided into seven overlapping subbands, each with specific constraints on parameters such as Effective Radiated Power (ERP), spectrum access, and channel spacing.

**ERP limitations.** Effective Radiated Power (ERP) is the power of the radio signal as it is radiated from the antenna. Regulatory bodies impose limits on ERP to prevent signal interference and ensure fair spectrum use. In many cases, the ERP limit for LoRa devices is set at 25 milliwatts (mW) or 14 decibels per milliwatt (dBm) for certain subbands.

**Spectrum access conditions.** Regulatory constraints often dictate the conditions under which LoRa devices can access the spectrum. Two common options include, 60-Duty Cycle, devices can transmit data for a limited time, often less than 0.1% of the total time. Listen Before Talk (LBT) [36], [72], [73], a transmission scheme where devices listen for ongoing transmissions before initiating their own. This is often combined with Adaptive Frequency Agility (AFA) to dynamically adapt the operating frequency based on conditions.

**Adaptive Frequency Agility (AFA).** AFA [74], is a mechanism that allows LoRa devices to adapt their operating frequency dynamically based on the specific subband or ERP requirement. This helps in avoiding interference and optimizing spectrum use.

**Regional variations.** Different regions have their regulatory authorities, and LoRa device manufacturers and operators need to be aware of and comply with the specific regulations in their operating regions.

**Impact on scalability.** Compliance with regulatory constraints is not just a legal requirement; it also impacts the scalability of LoRa deployments [75]. The limitations set by regulators influence how efficiently and effectively LoRa devices can communicate, affecting the overall performance and growth potential of LoRa networks.

In summary, LoRa devices operate within a regulatory framework to ensure fair and efficient use of the radio spectrum. Understanding and adhering to these regulatory constraints are essential for the optimal operation of LoRa networks. Compliance enables reliable and interference-free communication, contributing to the success and scalability of LoRa-based IoT deployments.
## 2.4 Traffic control approaches in LoRaWAN

In this section, we discuss the current traffic control approaches found in academic research. Traffic control in a network offers numerous advantages, playing a primordial role in enhancing overall efficiency and performance. One primary benefit is the reduction of collisions, as traffic control mechanisms help manage the flow of data and prevent conflicting transmissions. By strategically organizing data transfer, the likelihood of two or more devices attempting to transmit simultaneously, resulting in collisions, is significantly reduced.

Another advantage is the potential for decreased energy consumption. Efficient traffic control allows for better management of resources, ensuring that devices can operate in a more energy-conscious manner, leading to extended battery life in the case of battery-powered devices. Additionally, traffic control helps limit congestion within the network. By regulating the flow of data and preventing bottlenecks, the network can maintain optimal performance levels even during periods of increased activity. Despite these benefits, it is important to note that there are various approaches for implementing traffic control, ranging from simple prioritization schemes to more sophisticated algorithms. The choice of the approach depends on factors such as network architecture, the types of devices involved, and the specific goals of the network management strategy.

In this section, we categorized the traffic control approaches identified in the literature into three distinct classes. The first class revolves around approaches centered on optimizing LoRa parameters, the second involves strategies focusing on frequency channel optimization, and the third centers on techniques that emphasize traffic scheduling.

### 2.4.1 LoRa parameters optimization

Optimizing resource allocation is necessary to meet the challenges of improving scalability and minimizing collisions in the context of LoRaWAN. Factors like the spreading factor (SF) and transmission power (TP) are particularly tuned in [76]-[80]. The optimization of the carrier frequency (CF) and spreading factor (SF) is the main topic of papers [81], [82]. Others, [83]-[85], however, concentrate on optimizing parameters like spreading factor (SF) and bandwidth (BW) or spreading factor (SF) and coding rate (CR).

Cuomo et al. [79] propose resource allocation techniques named EXPLORa-SF and EXPLORa-AT to maximize LoRaWAN performance. These mechanisms configure the SF values for the end device according to the signal strength. End devices in the gateway radio range are distributed equally among the SFs by EXPLORa-SF, with the only limitations being their Received Signal Strength Indicator (RSSI) levels and applicable thresholds. Conversely, EXPLORa-AT distributes the ToA equitably among the network end nodes, giving the lower SFs priority to lessen the chance of a time collision. Because it only takes into account a certain number of end devices in each SF based on ToA, a higher signal strength correspondingly results in a lower SF for a particular end device.

The EXPLORa-AT in [79] was designed under the assumption of having all end-devices transmitting with the same message rate and payload. In [80] authors extend that approach to provide an EXPLORa solution adapted to the different applications and traffic loads that will be supported in LoRaWAN systems. To this end, they propose two innovative schemes, EXPLORa-KM (K-means) and EXPLORa-TS (Time Symbol), based on the ordered water-filling approach to optimize the allocation of Spreading Factors (SF) in LoRaWAN systems. EXPLORa-KM aims to relieve critical regions with a high collision probability by adjusting the SF allocation using K-means. On the other hand, EXPLORa-TS equalizes the traffic load among SF channels, taking into account different traffic types and transmission rates. Simulation results show that both heuristics significantly improve performance in terms of throughput and Data Extraction Rate (DER) when different traffic loads are present.

Zorbas et al. [84] focuses on improving the capacity of LoRa networks by utilizing multiple spreading factor configurations. The authors model a LoRa network consisting of nodes with different communication settings in terms of bandwidth and spreading factor. They compute the average success
probability per configuration, taking into account both intra and inter-spreading factor collisions. Every end device has a different BW and SF communication setting based on such a model. To improve the packet delivery probability for each BW and the distance between an end device and a given gateway, this work attempts to assign the majority of end devices to a given BW and SF. Additionally, they formulate and solve an optimization problem to maximize the node capacity for a given deployment area and frequency by optimizing the number of nodes with different spreading factor configurations. The results show that their approach can significantly increase the maximum number of nodes in a LoRa network compared to traditional approaches.

Khaled et al. [86] present a Fair Adaptive Data Rate allocation and power control algorithm (FADR) for LoRaWAN networks. The algorithm aims to achieve data rate fairness among nodes within a cell, regardless of their distance from the gateway, while also reducing energy consumption. The FADR algorithm consists of two parts: data rate allocation and power control. The data rate allocation aims to achieve equal collision probabilities among nodes by deriving fair distribution ratios for each transmission parameter combination. The power control algorithm balances the received signal powers from all nodes, regardless of their distances from the gateway, to ensure fair data extraction. However, even demonstrating promising results in PDR, not treating the IoT applications requirements variety can harm QoS for services that need a higher bit rate and reliability.

El-Asser et al. [83] increase LoRaWAN packet delivery success and throughput by proposing the SensitivitySF and AssignmentSF techniques. With this approach, each end device is given the optimal SF service radius based on the region of a signal in a certain SF that can be successfully demodulated by a receiver, or an SF ratio. SensitivitySF selects a Coding Rate (CR) parameter to enhance the sensitivity of the receiver while allocating the SF parameter. The same actions are carried out by the AssignmentSF mechanism in addition to load balancing inside each SF channel. Nevertheless, neither of the algorithms takes into account configurations for key radio-related parameters such as BW and TP. In this way, the algorithms are expressed as expensive mechanisms in terms of end-device energy due to the lack of a TP optimum configuration.

Ta et al. [76] have introduced innovative approaches like LoRa-MAB, a decentralized learning resource allocation approach based on the Multi-Armed-Bandit reinforcement algorithm. The simulator, LoRa-MAB is lightweight and flexible, allowing for the evaluation of various network design parameters and self-management solutions. Additionally, the authors introduce the use of the EXP3 [87] algorithm to autonomously guide the decision-making process of LoRa end devices in selecting the most suitable radio resources. Their approach surpasses the conventional Adaptive Data Rate (ADR) algorithm utilized in LoRaWAN, demonstrating improved performance in collision reduction and scalability. While the LoRa-MAB simulator provides valuable insights into resource allocation in LoRaWAN networks, it has limitations in terms of fixed radio settings, long convergence times, impractical assumptions, and overlooking important factors like capture effect and inter-SF interference. These limitations should be taken into account when interpreting the simulation results and designing real-world LoRaWAN applications.

Babaki et al. [78] suggest the Ordering Weight Average Operator (OWA) to dynamically allocate the physical parameters, SF and TP, to enhance the LoRaWAN ADR algorithm by default. By taking into account the Packet Loss Ratio (PLR) measure and the OWA decision-making feature, this work seeks to increase the network noise resilience and PDR in dense IoT scenarios. Nevertheless, this approach disregards the requirements of the network application and the BW design.

To maximize channel efficiency and increase the number of delivered packets, Mores et al. presents in [81] a novel heuristic termed CORRECT (Adaptive Resource Allocation on LoRaWAN for IoT Applications), which dynamically modifies LoRaWAN parameters to minimize interference and packet conflicts. CORRECT achieves a compromise between extending transmission range and lowering latency, energy consumption, and interference by taking into account the strength of the signal and the distance between the device and the gateway. Based on its power capacity and the sensitivity levels for each SF, the CORRECT heuristic assigns SF (Spreading Factor) and CF (Carrier Frequency) values to each Internet of Things device. Additionally, to maximize channel use and reduce accidents, it guarantees
an equitable distribution of devices among SFs and CFs. To evaluate the suggested heuristic with the best possible resource allocation solution, they also offer an optimization model known as MARCO (LoRaWAN Resource Allocation for IoT Applications). According to simulation data, as compared to the default heuristic, Adaptive Data Rate (ADR), CORRECT boosts packet delivery ratio, decreases packet collision rate by 3.153 times, and improves Data Extraction Rate (DER) by 11.8%. The suggested approach produces results that are nearly identical to the best model, with 1.124 times more collisions and only 0.6% worse DER.

Al-Gumaei et al. [85] investigate the power allocation problem for uplink communication in long-range IoT networks using game theory. It proposes a best-equal algorithm that allows LoRaWAN nodes to maximize packet delivery ratio and energy efficiency by behaving in a manner consistent with the information provided by the network server. The authors propose a BE-LoRa scheme, which is based on the assumption that the received signal strengths from all LoRa nodes are equal. This scheme considers the interference caused by the number of nodes in each spreading factor and slightly reduces the optimal signal-to-interference-plus-noise ratio (SINR) that nodes should achieve as the number of nodes increases. The results show that BE-LoRa achieves a higher delivery ratio and lower energy consumption compared to LoRaWAN ADR. The BE-LoRa scheme has a limitation in terms of SF assignment. While it decreases the number of nodes in SF7, SF11, and SF12, it increases the number of nodes in SF8, SF9, and SF10. This efficient assignment of SFs aims to reduce collisions and improve energy consumption. However, if all nodes are located equidistant from the gateway, one SF will be assigned to all nodes.

Arasu et al. [82] propose an optimized resource allocation algorithm for LoRaWAN based on MILP (Mixed Integer Linear Programming) named OMILP-LoRa. The algorithm aims to allocate radio resources efficiently by considering factors such as power and distance of the signal. It determines the best SF and CF configurations for each end device. The approach provides a tradeoff between transmission range growth and reductions in delay, energy, and impedance. While MILP-LoRa offers advantages such as extended communication range and low power consumption, it also has limitations related to energy consumption, payload size, computational complexity, gateway distance, and continuous monitoring.

### 2.4.2 Frequency channel optimization

Another crucial component of resource management is frequency channel optimization since it reduces interference and controls the traffic by allowing transmissions in distinct channels to function independently [88]-[94].

Tsakmakis et al. [88] propose a new frequency planning approach that aims to reduce the number of collisions and improve the mean packet delay. The approach involves using clusters in a multichannel Slotted ALOHA-based LoRaWAN network, where each node in a cluster belongs to a different channel. This fixed channel assignment helps eliminate collisions within clusters and improves network performance. The authors compare two different channel-sharing strategies: random channel assignment and fixed channel assignment. In random channel assignment, each node is randomly assigned a channel, which can lead to uneven channel distribution and collisions within clusters. On the other hand, fixed channel assignment assigns a predefined uplink channel to each node, with each node in a cluster belonging to a different channel. This eliminates collisions within clusters and improves network performance.

Shen et al. [89] propose an optimization strategy encompassing both channel assignment and the backoff time between consecutive transmissions. The authors present a traffic-aware channel and backoff window size allocation (TCBA) scheme to improve network capacity and latency in LoRa-based IoT networks. The TCBA aims to improve network capacity and latency by considering the fluctuation of different channel qualities and various traffic-buffer types for the optimum contention policy. The scheme takes into account factors such as channel qualities and traffic-buffer types, to optimize the
contention policy. The proposed TCBA scheme is capable of supporting massive LoRa connections and achieves the highest throughput and the lowest end-to-end latency.

Chinchilla et al. [91] suggest modifying the LoRaWAN MAC layer to incorporate CARA (Collision Avoidance Resource Allocation), which combines the optimization of spreading factors with channel allocation. One channel and one spreading factor are used by CARA to define resource blocks, which make up the wireless medium capacity. The technique takes advantage of the orthogonality of the spreading factors in LoRa to guarantee that broadcasts in distinct resource blocks do not result in collisions. It applies a cyclical assignment strategy in which nodes are cyclically assigned to various resource blocks based on their initial resource blocks. The CARA resource assignment logic handles this assignment by looking for the resource block with the lowest assignments to be used for the subsequent node while taking the available spreading factors into account. CARA tackles the drawbacks of LoRaWAN, including duty cycle restrictions and capacity decrease from collisions. It can handle a range of situations, such as indoor, outdoor, and urban settings. Although CARA achieves fairer resource sharing and improves overall network throughput, it may slightly increase the overall transmission time and energy consumption compared to the ADR[69], [70], [95] algorithm proposed in the LoRaWAN specification.

Kaburaki et al. [92] propose a centralized radio resource allocation scheme that aims to avoid packet collisions in periodic traffic in low-power wide area networks (LPWANs). In this scheme, a gateway predicts packet collisions and allocates frequency channels and transmission timing offsets to nodes to avoid these collisions. The gateway estimates the uplink packet generation cycle of each node and uses this information to allocate the appropriate frequency channel and transmission timing offset for collision avoidance. By effectively managing the allocation of resources, the proposed scheme improves the average Packet Delivery Ratio (PDR) performance compared to the ALOHA protocol. However, the proposed scheme does not apply frequency hopping, which means that there are some nodes that the gateway cannot control. This can result in packet collisions and degraded communication quality. Additionally, the proposed scheme is based on a combinatorial optimization problem, which becomes challenging as the number of nodes increases.

Qin et al. [90] formulate the resource allocation problem as a joint optimization problem of channel assignment and power allocation, aiming to guarantee throughput fairness among LoRa users with limited spectrum resources. To address the channel assignment problem, the authors propose a low-complexity matching channel assignment algorithm (MCAA) based on matching theory. This algorithm allows LoRa users to self-match with appropriate channels, considering both the channel they are assigned and other users assigned to the same channel to minimize interference and ensure transmission rate fairness. For LoRa users assigned to the same channel, the authors develop a centralized power allocation algorithm to determine the optimal transmit power. This algorithm aims to maximize the achieved minimal transmission rate in LPWA networks, improving resource efficiency and network capacity. Simulation results show that the proposed MCAA achieves near-optimal performance with significantly lower computational complexity. While the proposed solutions aim to improve resource efficiency in LPWA networks, they have limitations in terms of non-convexity, computational complexity, coupled variables, NP-hardness, and the assumption of known channel state information (CSI). These limitations need to be considered when implementing and evaluating the proposed solutions in real-world LPWA network scenarios.

Lee et al. [93] introduce a traffic-aware flexible frame adaption strategy to increase network capacity in the LoRaWAN dynamic traffic environment. The suggested approach uses a random channel access period and a reservation-based channel access period to determine which available channels are accessed during each frame. During the random channel access phase, data packets are first transferred over pure ALOHA[37] utilizing one of the available channels. If the data transmission fails, resources are assigned to retransmit the data packet during the reservation-based channel access period. With this transmission policy, to maximize the packet delivery ratio (PDR), the server determines which channels are available in two periods based on the number of data packets that are successfully transmitted in
each period. This system could enhance the network capacity by increasing the resources available for
the channel access period appropriate to the currently dominant traffic characteristics.

Aimi et al. [94] provide strategies for allocating radio resources based on input traffic and PDR requirements, taking requirements impact into account, and limiting traffic in a cluster based on assigned channels. To reduce interference in clusters, it presents two traffic control systems (duty-cycle control and access control) and defines classes of services in terms of PDR. By restricting device access to the network depending on the number of channels allotted to each cluster, the access control system manages traffic. In situations where the number of devices surrounding a gateway rises, it helps alleviate network congestion and enables more exact control over the fulfillment of requirements. Additionally, the duty-cycle control solution manages traffic by controlling the end device duty cycle, which establishes how long a device can send data in a certain length of time. Duty-cycle control reduces traffic in steps specified by the protocol primitive, making it more conservative than access control.

2.4.3 Traffic scheduling

Efforts to control the traffic and mitigate collisions in a network often involve scheduling the traffic systematically. This scheduling can take the form of a centralized approach, where a central entity assigns transmission slots to each end-node based on various parameters [77], [96], or a distributed approach, where each end node autonomously selects its transmission slot [97], [98].

Fadel et al. [77] propose Fine-grained scheduling for a Reliable and Energy Efficient data collection approach (FREE), that is independent of network topology and application type. As an alternative to delivering data instantly, FREE centrally buffers the data and uses information gathered from end devices—such as the quantity of buffered data and the actual route loss—to schedule transmissions at the gateway during particular time intervals. Channel access occurs synchronously after the schedule is determined and sent to the endpoints. While devices with distinct spreading factors broadcast simultaneously, those with the same spreading factor transmit sequentially. By eliminating collisions and grouping acknowledgments, FREE achieves almost 100% data delivery and extends the device lifetime to over 10 years, regardless of traffic type and network size. It replaces the standard random access approach used by LoRaWAN with a coordinated medium access approach, resulting in improved reliability and energy efficiency.

Haxhibeqiri et al. [96] propose a mechanism, that runs on top of the LoRaWAN MAC layer, that involves a central Network Synchronization and Scheduling Entity (NSSE) at the LoRaWAN Network Server. The NSSE schedules uplink and downlink transmissions for end nodes, who request time slots before transmitting data packets. The NSSE uses Bloom filters to encode time slot indexes, reducing synchronization packet length and allowing more information to be sent. Time slots are assigned based on traffic needs and context information, such as synchronization periodicity and clock drifts. Once synchronization is performed, a scheduling component in the end node checks if the current time slot index is part of the probabilistic data structure, allowing the end node to schedule a data transmission in the next slot. This process reduces energy consumption and processing.

Xu et al. [97] present S-MAC an adaptive distributed MAC-layer scheduler for LPWAN, which takes advantage of the periodic transmission characteristics of LPWAN applications and the collision behavior features of LoRa PHY-layer to enhance scalability. It can dynamically perceive the clock drift of end devices and use this information to adjust the scheduling strategy based on the changing clock drift of the devices. Xu et al. [99], also introduce an upgraded s-MAC that they call X-MAC that also operates at the nodes level in LoRa networks. It is a distributed scheduling scheme that allows each end device to independently detect and avoid collisions caused by interferences under different spreading factor (SF) settings. X-MAC achieves this by tracking historical transmissions and dynamically scheduling channels to prevent collisions both under the same and different SFs. This approach improves the scalability and reliability of the network by reducing packet losses and transmission delay. The goal of X-MAC dynamic channel scheduling is to maximize the network scalability, allowing for a higher
number of concurrent end devices, while maintaining a packet reception rate (PRR) requirement of over 95%.

Zorbas et al. [98] propose TS-LoRa a Time-Slotted approach that enables nodes to self-organize the time slot schedule within frames, reducing the overhead of schedule dissemination. It supports collision-free transmissions and re-transmissions in case of packet losses. TS-LoRa uses a time division mechanism where each transmission of the same Spreading Factor (SF) is accommodated in a unique slot. Multi-SF parallel transmissions can take place on different frequencies to avoid collisions. TS-LoRa can be implemented as a stand-alone protocol or integrated into the existing LoRaWAN network protocol with minimal modifications on the network server side.

However, both central and distributed approaches introduce unwanted overhead due to the dissemination of the transmission schedule, and they require high clock accuracy from end nodes, a demand that can be challenging to meet in real-world scenarios. An alternative and simpler strategy proposed by Kaburaki et al. [100] involves offsetting the transmission timings to avoid unnecessary packet collisions. In their autonomous decentralized traffic control system, Q-learning[101], [102] is employed to autonomously manage transmission times, thereby reducing the probability of packet collision and enhancing communication quality, especially in event-driven traffic scenarios. Q-learning determines the transmission time offset and probability, adapting to the network conditions. Assuming an ideal downlink, the transmission probability is automatically adjusted based on downlink acknowledgments, limiting the number of nodes transmitting event packets and subsequently decreasing the likelihood of packet collision.

## 2.5 Discussion and Positioning

In LPWANs like LoRaWAN, the joint use of Adaptive Data Rate (ADR) and Duty Cycling plays a primordial role in mitigating network congestion and ensuring equitable utilization of the shared spectrum. ADR dynamically optimizes the Spreading Factor (SF) and Transmission Power (TP) of IoT devices based on real time network conditions. This ensures energy efficiency and extends battery life by adapting SF for longer ranges or higher data rates and adjusting TP for optimal signal quality. Duty Cycling, on the other hand, enforces restrictions on when devices are allowed to transmit, preventing them from overwhelming the network with frequent transmissions. Together, ADR and Duty Cycling create an adaptive and regulated environment, reducing interference, conserving energy, and balancing the trade-off between range and data rate to optimize the overall efficiency of LoRaWAN networks. ADR and Duty cycle restrictions can effectively stop continuous transmission and lower the chance of interference, but they might not be enough to provide more fine-grained control or to meet the needs of a particular application. The duty cycle constraints are often generic and do not consider the diverse needs of different applications or the dynamic nature of network traffic.

LoRaWAN networks often do not have sophisticated uplink traffic control algorithms. These would allow network providers to optimize data traffic from end nodes to the network server. The lack of such algorithms creates difficulties in two situations. The first is when there is a need for application-driven periodic sampling, which regularly collects a certain number of samples. The second is to meet the demands of IoT telecommunication operators who may have service level agreements (SLAs) demanding a maximum sample reception rate. In the aforementioned study, a thorough examination of the existing scientific literature has been conducted to identify potential solutions for traffic control in LoRaWAN networks. We categorized these solutions into three main classes: optimizing LoRa parameters approaches, frequency channel optimization approaches, and traffic scheduling approaches.

### 2.5.1 Discussion

The discussed traffic control approaches based on resource allocation optimization in LoRaWAN networks offer promising solutions for enhancing network performance and reducing collisions. However, each approach has its set of limitations that warrant careful consideration, especially when
addressing the specific requirements of applications in LPWANs, particularly in LoRaWANs. LoRa-
MAB [76] approach faces challenges related to fixed radio settings and long convergence times. These
characteristics may limit the adaptability to dynamic changes in network conditions. In scenarios
where rapid adjustments are required, the extended convergence times could impact the real time
responsiveness of the system. Also, the impractical assumptions pose a challenge in real-world
scenarios. Overlooking factors like capture effect and inter-SF interference might hinder the practical
applicability of these approaches, especially when dealing with diverse and unpredictable network
environments. While approaches, such as Fair Adaptive Data Rate (FADR) [86], aim to achieve data
rate fairness, they may not fully account for the diverse requirements of IoT applications. Applications
demanding specific K measurements over a defined time period may not be adequately addressed by
these approaches, potentially affecting the Quality of Service (QoS) for certain services. Optimization
techniques like SensitivitySF and AssignmentSF [83] may introduce energy inefficiencies due to the
lack of an optimal configuration for key radio-related parameters. This limitation could impact
the overall energy consumption of end devices, which is critical in LPWANs, where devices often
operate on limited power resources. approaches such as the Ordering Weight Average Operator
(OWA) [78] might enhance certain aspects of LoRaWAN Adaptive Data Rate (ADR) but may disregard
specific requirements of network applications and bandwidth design. This oversight may affect the
overall performance in scenarios characterized by dense IoT deployments. Optimization algorithms
like OMILP-LoRa, relying on Mixed Integer Linear Programming (MILP), introduce complexity and
computational overhead. This can be a concern, particularly in resource-constrained devices common
in LPWANs, affecting their feasibility and practical implementation.

While these limitations exist, the discussed approaches contribute valuable insights and
advancements to the field of traffic control in LoRaWAN networks. Optimizing resource allocation
in LoRaWANs is essential for enhancing efficiency and scalability, careful consideration must be given
to the drawbacks associated with potential downlink limitations, network congestion, adaptability to
dynamic environments, QoS trade-offs, battery life concerns, algorithmic complexity, and adherence
to regulatory constraints. A balanced approach is crucial to ensuring the overall success and reliability
of LoRaWAN deployments. Their primary limitation is their focus on the network physical aspects
and they do not control the volume of traffic generated by individual nodes. Moreover, they may not
guarantee compliance with specific application constraints, like latency requirements or the need for
real time data delivery.

Frequency channel optimization approaches, as integral components of LoRaWAN traffic control,
bring valuable strategies. However, they are not without their limitations. Approaches like cluster-
based frequency planning [88], demonstrate effectiveness in collision reduction within clusters but face
challenges in dynamic environments. The fixed channel assignment may struggle to adapt swiftly to
changing network conditions, limiting its applicability in scenarios requiring rapid adjustments. This
limitation raises questions about the approach ability to effectively manage traffic in dynamic LPWAN
scenarios. Also, the centralized radio resource allocation, proposed in [92], introduces a approach to
predict and allocate resources centrally, aiming to avoid packet collisions. While this approach improves
Packet Delivery Ratio (PDR), it lacks frequency hopping, leading to challenges in controlling nodes
that the gateway cannot influence. This limitation raises concerns about the robustness in situations
where certain nodes remain beyond the gateway control, potentially jeopardizing communication
quality. The trade-off between centralized control and adaptability to varying network conditions
becomes a critical consideration. The joint optimization of channel assignment and power allocation
approach [90], faces challenges related to non-convexity and computational complexity. While striving
for throughput fairness, the approach may encounter scalability issues, impacting its suitability for
real time, dynamic LPWAN environments. The question arises whether such approaches, with their
computational demands, can efficiently manage traffic in LPWANs where devices often operate with
constrained resources. Traffic-aware flexible frame adaption [93], offers adaptability to dynamic
traffic environments but raises concerns about accurate prediction and response to varying demands.
In scenarios where traffic patterns change rapidly, the approach effectiveness in controlling and
optimizing traffic becomes crucial. The challenge lies in maintaining the balance between flexibility and accurate prediction to ensure optimal resource utilization. Radio resource allocation based on traffic control systems [94], introduces duty-cycle and access control mechanisms to manage traffic. While providing strategies for resource allocation, these approaches potentially limit the overall traffic. The trade-off between controlled traffic and maximizing resource utilization during periods of varying demand becomes a critical consideration.

Meeting the demands of IoT telecommunication operators with SLAs demanding a maximum sample reception rate introduces another layer of complexity. While these approaches contribute to reducing collisions, enhancing packet delivery, and optimizing network capacity, the challenge lies in adapting these optimizations to align with the specific requirements of SLAs. Balancing between meeting sample reception rate expectations and maintaining efficient traffic management is crucial for the success of these approaches in controlling the traffic in LPWANs, particularly in LoRaWANs. While frequency channel optimization approaches hold promise for efficient traffic control in LPWANs, their limitations emphasize the need for careful consideration of trade-offs. The ability to adapt to dynamic conditions, maintain reliable communication, and meet the stringent demands of IoT telecommunication operators SLAs requires ongoing refinement and research in the field.

The scheduling approaches discussed, whether centralized or distributed, are essential in managing traffic and mitigating collisions in LPWANs, particularly in the context of LoRaWANs. However, they come with their own set of limitations that need to be carefully considered. Centralized scheduling approaches, such as FREE [77] and NSSE-based mechanisms [96], face challenges related to synchronization overhead. The dependency on synchronized channel access intervals may limit their effectiveness in dynamic network scenarios where rapid adjustments are required. Achieving and maintaining precise synchronization can be challenging in real-world scenarios, impacting the scalability and adaptability of these approaches. The overhead introduced by the dissemination of transmission schedules is another limitation that needs to be addressed, especially as network size and traffic complexity increase. Also, distributed scheduling approaches, such as S-MAC [97], X-MAC [99], and TS-LoRa [98], demonstrate adaptability and scalability. However, accurate perception of clock drift, especially in dynamic LPWAN environments, remains a challenge. The distributed nature of these approaches necessitates a robust mechanism for nodes to autonomously detect and avoid collisions. In scenarios with varying traffic needs, ensuring effective scheduling without sacrificing energy efficiency and reliability becomes critical. These approaches may struggle to adapt rapidly to changing network conditions, impacting their ability to effectively control and manage traffic in real time.

In the context of applications requiring *K* measurements over a period of time, and meeting the demands of IoT telecommunication operators with SLAs demanding a maximum sample reception rate, the adaptability of scheduling approaches becomes crucial. While these approaches provide frameworks for organizing transmissions, they may not inherently guarantee efficient handling of applications with stringent timing requirements. The challenge lies in accurately predicting and responding to varying demands, ensuring that the scheduling mechanisms align with the specific needs of applications requiring precise measurements over specific time intervals. Additionally, meeting the demands of IoT telecommunication operators with SLAs specifying a maximum sample reception rate introduces another layer of complexity. Scheduling approaches must not only manage collisions and optimize transmissions but also ensure that the network adheres to the specified reception rate. The trade-off between maximizing network scalability, minimizing collisions, and meeting stringent SLA requirements becomes a critical consideration. In conclusion, while scheduling approaches contribute significantly to traffic control and collision mitigation in LPWANs, their limitations underscore the need for ongoing refinement and adaptation. Achieving a balance between synchronization accuracy, adaptability to dynamic network conditions, and meeting the specific requirements of applications and SLAs is essential for the successful deployment of these approaches in real-world LPWAN scenarios. The exploration of alternative strategies or combinations with traffic reduction algorithms may be necessary to address the challenges posed by stringent application requirements and operator SLAs.
### 2.5.2 Positioning

To manage the traffic in LPWANs, several approaches have been employed, such as modifying spreading factors, transmission power, coding rate, and channel allocation. Although these optimization approaches have effectively strengthened network capacity by adjusting physical layer parameters, it is crucial to recognize their restrictions as they mainly focus on the network physical dimensions and offer no control over individual node-generated traffic volume. Additionally, their efficiency in adhering to specific application constraints, like strict latency requirements or real time data delivery necessity, is still questionable.

Furthermore, our research extends to scheduling approaches within LoRaWAN, designed to mitigate collisions and enhance network performance. Although these scheduling techniques optimize transmission schedules and timings, thereby improving reliability, it is essential to acknowledge a significant limitation. These strategies, while proficient in tackling collision-associated concerns, do not adapt the overall network traffic or offer a direct approach for controlling the generated traffic volume. This consideration becomes especially relevant when the primary objective is not only the mitigation of collisions but also the control of total traffic within the network.

In response to these challenges and recognizing the need for a more comprehensive approach, we introduce the DiPTC algorithm (Distributed Probabilistic Traffic Control) for LPWANs. DiPTC aims to overcome the limitations of existing optimization and scheduling approaches by incorporating simple traffic control mechanisms. Unlike traditional techniques, DiPTC does not merely focus on physical layer parameters but digs into the dynamics of individual node-generated traffic. By dynamically adapting to the network conditions and managing traffic, DiPTC aims to optimize not only collision mitigation but also the overall traffic load, ensuring better adherence to application-specific constraints and operator service level agreements (SLAs).

In the subsequent chapters, we introduce our approach functionalities, and performance while highlighting its potential to control the traffic in LPWANs, particularly in the context of LoRaWAN.

## 2.6 Conclusion

This chapter is divided into two main parts. First, it gives an overview of Low-Power Wide-Area Networks (LPWANs), focusing on LoRaWAN. It explains the basic elements of LPWANs, specifically LoRaWANs. Then, the chapter reviews existing studies on traffic control in LoRaWANs. This includes approaches related to the LoRa parameters optimization, frequency channel optimization, and traffic scheduling. This chapter evaluates these approaches and their limitations in relation to the recognized challenges.
# Chapter 3

# A Distributed and Probabilistic Traffic Control algorithm for LPWANs

## Contents

<table><tr><td>3.1 Introduction</td><td>33</td></tr><tr><td>3.2 Motivation</td><td>34</td></tr><tr><td>3.3 DiPTC: the big picture</td><td>34</td></tr><tr><td>3.4 Assumptions</td><td>35</td></tr><tr><td>3.4.1 Network configuration</td><td>36</td></tr><tr><td>3.4.2 Simplified binary acknowledgment in the downlink message</td><td>36</td></tr><tr><td>3.4.3 Downlink Broadcasting and Multicasting Capacities</td><td>37</td></tr><tr><td>3.5 DiPTC algorithm</td><td>38</td></tr><tr><td>3.6 Simulation model</td><td>40</td></tr><tr><td>3.6.1 Wireless environment</td><td>40</td></tr><tr><td>3.6.2 Energy consumption</td><td>41</td></tr><tr><td>3.7 Benchmark protocols</td><td>42</td></tr><tr><td>3.7.1 LoRaWAN protocol</td><td>42</td></tr><tr><td>3.7.2 Centralized Optimal Traffic Control protocol</td><td>43</td></tr><tr><td>3.8 Overall performance evaluation</td><td>43</td></tr><tr><td>3.8.1 Scenarios and network parameters</td><td>43</td></tr><tr><td>3.8.2 DiPTC vs. LoRaWAN vs. COTraC</td><td>44</td></tr><tr><td>3.9 Horizontal and vertical scalability evaluation</td><td>45</td></tr><tr><td>3.9.1 Impact of the traffic intensity</td><td>48</td></tr><tr><td>3.9.2 Impact of the nodes scalability</td><td>50</td></tr><tr><td>3.10 Traffic control parameters evaluation</td><td>52</td></tr><tr><td>3.11 Discussion & Insights</td><td>56</td></tr><tr><td>3.12 Conclusion</td><td>58</td></tr></table>

## 3.1 Introduction

In this chapter, we present our Distributed Probabilistic Traffic Control algorithm (DiPTC) for LoRaWAN that enables the network server and the applications to better control data collection [103], [104]. The DiPTC algorithm automatically adjusts total network traffic to meet application requirements, such as collecting *K* data points over a time period *ΔT*.

Firstly, we discuss the need for a traffic control approach in LPWANs section 3.2, before presenting the main idea behind our new approach in section 3.3. Then, we establish the basic assumptions in section 3.4. This section involves a thorough analysis of the premises influencing our proposal, preparing for the subsequent in-depth presentation and comprehensive explanation of our new
approach in section 3.5. Within this section, we introduce the essential elements and complexities of our method, highlighting its unique contributions to the field of LoRaWAN traffic control.

Moving forward, section 3.6 presents the simulation setup and various scenarios designed to assess the performance of our proposed approach, DiPTC. Section 3.7 presents the benchmark algorithms used for a comparative evaluation. The subsequent sections, 3.8 and 3.9, engage in a comprehensive validation and comparative analysis. Sections 3.8 discuss the outcomes of DiPTC in comparison to both the LoRaWAN and the Centralized Optimal Traffic Control (COTraC) algorithms, while 3.9 evaluate the performance of our DiPTC in terms of vertical and horizontal scalability. The comparative assessment allows for a thorough assessment of the effectiveness and unique contributions of our proposed algorithm across various performance metrics. Shifting the focus to DiPTC parameters tuning, section 3.10 explores how DiPTC parameters influence traffic control within LoRaWAN scenarios. Section 3.11 synthesizes our insights, reflections, and implications, providing a discussion that places our findings within the context of traffic control in LoRaWAN. Section 3.12, concludes the chapter.

## 3.2 Motivation

Without a doubt, Low Power Wide Area Networks (LPWANs), have numerous benefits, but there are also important drawbacks to consider. Two main issues involve the frequencies used and the medium access protocols applied. LoRaWAN technology, for example, commonly functions in unlicensed frequency bands like 868 MHz in Europe and Africa and 915 MHz in the USA. While this enables flexibility and easy access, it also brings challenges related to interference and regulatory restrictions. Since unlicensed bands are shared by different technologies and users, interference problems might affect LPWANs performance and reliability. Moreover, each region has specific rules for using certain frequency bands, so compliance is essential to prevent legal or operational issues.

LPWANs often use medium access protocols like Aloha, a straightforward but popular method. Nonetheless, Aloha has inherent drawbacks, mainly related to collision handling and network efficiency. Protocols based on Aloha can face higher collision rates when numerous devices attempt to transmit data at the same time. These collisions may cause packet loss and decreased network efficiency. Additionally, the contention-based nature of Aloha can lead to idle periods and ineffective use of available bandwidth, limiting the network overall capability. The combined effects of frequency constraints and medium access protocols might result in less-than-ideal network performance in specific circumstances. LPWANs, which are designed for certain purposes, could face difficulties addressing the diverse and changing requirements of different applications. As more devices become connected, competition for limited bandwidth becomes more severe, potentially leading to congestion and reduced network scalability. This is particularly significant for specific applications, such as environmental monitoring, where a particular amount of data must be transmitted within a predetermined time period. Excessive data transmission may lead to network issues and energy waste, whereas insufficient data transmission hinders effectiveness. To our understanding, no traffic control mechanism in LPWANs can regulate the traffic produced by the nodes while ensuring compliance with the application constraints.

## 3.3 DiPTC: the big picture

The main idea behind our Distributed and Probabilistic Traffic Control approach is to adapt the overall traffic of LPWANs according to the observed network conditions and predefined application objectives. In DiPTC, the traditional approach of transmitting data following the fixed duty cycle is replaced by a more adaptive strategy. Each node, before initiating a data transmission, calculates a transmission probability. This probability serves as a crucial determinant, allowing the node to decide whether it is opportune to send data within the stipulated duty cycle constraints. This dynamic method ensures that data transmission aligns with the specific needs of the application while still respecting the imposed
<figure><img src="image_11.png" /><figcaption>FIGURE 3.1: Example of DiPTC in LoRaWAN, 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>

duty cycle limitation of 1%. In essence, DiPTC introduces a level of flexibility into data transmission within LoRaWANs, shifting from rigid adherence to duty cycle schedules to a more adaptive and application-centric approach. This innovation focuses on improving data transfer efficiency, making sure it meets the specific needs of various applications, and adhering to the necessary regulatory duty cycle restrictions.

If we consider node $n$ as being granted permission to transmit data, it utilizes a critical parameter referred to as its weighting coefficient, indicated as $\alpha_n$, to determine the number of messages it should send as demonstrated in Fig. 3.1, specifically in step (a). The network server performs an important comparison between the actual number of received packets $k$ and the predefined objective $K$ at the end of the designated time period $\Delta T$. If the received count is lower than the objective ($k < K$), the network server initiates a feedback message destined for the gateway. Subsequently, this feedback message is sent to all nodes within the network area. The primary purpose of this feedback is to prompt an increase in the weighting coefficient for each node, consequently elevating their allocated number of transmitted messages. This process is encapsulated in Fig. 3.1, step (b). Conversely, if the received count surpasses the predefined objective ($k > K$), an inverse mechanism is set into motion. The network server transmits a feedback message instructing the nodes to reduce their weighting coefficient. Upon receiving the feedback message, each node, in adherence to the DiPTC algorithm, performs a local computation to update its weighting coefficient $\alpha_n(t)$. This updated coefficient, crucially impacting the node transmission behavior, is then used to reevaluate the number of messages to be sent, as demonstrated in Fig. 3.1 step (c).

In summary, the process of DiPTC involves using a combination of weighting coefficients, feedback mechanisms, and local computations to adaptively regulate the transmission behavior of its individual nodes. This is done in accordance with the observed network conditions and predefined application objectives.

## 3.4 Assumptions

To lay the groundwork for our proposition, we developed a set of assumptions regarding downlink communication and network configuration during our analysis. These assumptions, briefly mentioned
in the following bullet points, serve as foundational principles and will be further discussed in
subsequent subsections.

1. Single gateway configuration: We set up the network with a single 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. 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.

4. 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.

5. 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.

6. Downlink broadcasting and multicasting capacities: The downlink is assumed to have both broadcast and multicast capabilities for simultaneous communication with multiple nodes in the LoRaWAN network.

**3.4.1 Network configuration**

We focus our attention on a particular case where there is just one gateway that covers a certain area. In particular, we analyze a LoRaWAN network that is set up in an urban setting with one gateway and *N* nodes uniformly distributed (Fig. 3.1(a)). This intended choice allows for more in-depth analysis and understanding of the dynamics associated with a simpler network configuration. The consideration of a single gateway provides a foundational perspective, serving as a baseline before expanding our examination to more complex multi-gateway scenarios in the subsequent chapter.

Additionally, a key assumption in our study is that the number of nodes associated with the network denoted as *N*, remains unknown. This uncertainty is inherent in many real-world LoRaWAN deployments due to the dynamic nature of IoT networks. The number of nodes may fluctuate over time due to various factors, including the introduction of new nodes through subsequent deployments, the occurrence of hardware failures, or nodes deactivating due to depleted batteries. This consideration acknowledges the dynamic and evolving nature of IoT networks, where the deployment area is subject to changes. Whether nodes are added, fail, or become inactive, the assumption of an unknown and potentially changing *N* reflects the practical challenges faced in managing and monitoring the composition of LoRaWAN networks over their operational lifetimes.

**3.4.2 Simplified binary acknowledgment in the downlink message**

In the context of LoRaWAN, the downlink communication typically serves two primary purposes: to convey control information for modifying the physical layer configuration and to acknowledge the successful reception of packets by the network server, as highlighted in existing LoRaWAN specifications [12], [64]. However, in our proposed approach, DiPTC, we introduce a novel utilization of the downlink as a valuable source of feedback information, extending its role beyond conventional acknowledgments. In DiPTC, we recommend using the downlink to report on whether the goals of the application have been met. This feedback could include important metrics, such as the number of packets that were successfully received in the previous time interval Δ*T*. The feedback may also contain information regarding the number of packets *K* that the application needs to receive in the allotted time. Alternatively, a more concise feedback approach could convey whether the number of received packets aligns with the application-defined objectives.
Examples of choices regarding the content of the feedback message are discussed in the following paragraphs. Consider an example where a LoRaWAN application deployed in a smart agriculture scenario aims to receive a certain number of sensor data packets within a specific time frame $\Delta T$. Traditionally, LoRaWAN downlink communication is utilized for acknowledging received packets, but in DiPTC, this communication channel becomes a bidirectional path for feedback. In this context, the gateway can send a downlink message indicating the number of successfully received packets during $\Delta T$. For instance, the message might convey that out of the required *K* packets for the application, 80% were successfully received. This detailed feedback enables the nodes to assess their performance and make informed decisions about their communication strategy. In another scenario, the feedback might take a more concise form, signaling whether the received packet count falls within the predefined application objective. For instance, the downlink message could convey a simple binary acknowledgment: "Objective Achieved" or "Objective Not Achieved". This simplified feedback allows for quicker decision-making by the nodes, indicating whether it needs to adjust its communication parameters or maintain the current strategy. Moreover, if we consider an industrial monitoring application where the primary goal is to ensure that critical control signals are reliably received by remote devices. In this case, the downlink feedback could include information about the successful reception of control messages and whether they were received within the required time constraints. This type of feedback is critical for applications where timely and accurate communication is important.

The adaptability of the DiPTC feedback mechanism accommodates diverse application requirements. Whether it is detailed statistics, binary acknowledgments, or specific information about the reception of critical messages, the downlink channel serves as a dynamic path for adapted communication strategies based on the specific needs and goals of each application. This flexibility guarantees that the input corresponds to the various needs of various applications that make use of the LoRaWAN infrastructure. Most importantly, the feedback loop enables every node in the LoRaWAN network to dynamically modify its traffic behavior so that it conforms to the unique needs of the application it supports. To maintain compliance with the legal frameworks controlling wireless communication, these modifications must always take into account regulatory constraints, such as duty cycle limitations.

#### 3.4.3 Downlink Broadcasting and Multicasting Capacities

In a LoRaWAN multicast group, ensuring effective communication among all nodes is essential. This is achieved through a carefully orchestrated configuration process where nodes within the multicast group share common parameters, fostering a synchronized reception of multicast transmissions. The fundamental configuration elements include utilizing the same Spreading Factor (SF), channel, bandwidth, and ping-slot periodicity. To elaborate, the Spreading Factor (SF) determines how the signal is modulated and the bandwidth it occupies. By configuring all nodes within the multicast group with the same SF, they align their reception capabilities. Additionally, nodes share the same channel and bandwidth settings, ensuring they are tuned to identical frequencies, optimizing the likelihood of successful communication. Furthermore, the configuration mandates a common multicast device address (McAddr), a unique identifier for the multicast group, and shared security keys among all nodes [105]. This comprehensive alignment guarantees that multicast transmissions are accurately received and decoded by all members of the group. In contrast to Class B unicast, Class B multicast introduces certain limitations. To mitigate collisions, the specification imposes restrictions on the use of MAC commands and acknowledgments that necessitate simultaneous responses from all nodes in a multicast group. Moreover, the specification does not provide explicit support for the creation of multicast groups or the secure distribution of keys and addresses, as outlined in [106].

Lim et al. [107] present a multicast activation scheme tailored for efficiently managing the count of nodes in LoRaWAN-based IoT applications. The scheme introduces innovative multicast MAC messages and outlines the procedure for nodes to join multicast groups. Through an energy consumption
comparison between unicast and multicast, the study establishes that multicast offers a more energy-efficient approach, particularly beneficial for configuring and managing a sizable number of nodes. This scheme serves as a practical guide for developers looking to implement MAC multicast protocols within the LoRaWAN framework. It not only provides a blueprint for designing such protocols but also offers insights for deploying LoRaWAN-based IoT applications requiring multicast communication. On the other hand, shiferaw *et al.* [108] dig into the exploration of Class B multicast in LoRaWAN, focusing on its scalability properties. The study addresses critical issues like multicast member capability, beacon blocking, and beacon collisions. Without requiring any modifications to the LoRaWAN protocol, the authors propose several mitigation approaches. These include Ping-Slot Relaying to accommodate more multicast members, a scheduling approach to determine optimal times for sending multicast packets, and the introduction of Dynamic Region Formation (DRF) to coordinate beacon transmissions across multiple gateways. These solutions offer practical ways to enhance the scalability of Class B multicast in LoRaWAN, providing valuable insights for optimizing its performance without protocol modifications.

In summary, Lim *et al.* [107] concentrate on multicast activation for efficient device management, emphasizing energy efficiency, while shiferaw *et al.* [108] focus on the scalability properties of Class B multicast, proposing solutions to overcome specific challenges without protocol modifications. Both studies contribute valuable perspectives to the enhancement of multicast functionalities within the LoRaWAN ecosystem.

This thesis does not address the broadcast or multicast integration needed to transmit feedback messages over the LoRaWAN network.

## 3.5 DiPTC algorithm

In this section, we present our Distributed Probabilistic Traffic Control algorithm, DiPTC, drawing inspiration from the Additive Increase Multiplicative Decrease algorithm (AIMD). Our approach is influenced by feedback control algorithms commonly employed to dynamically adjust sending rates based on network states, a strategy effectively used in congestion management for transport layer protocols like TCP [109] and QUIC [110]. Specifically, our algorithm incorporates principles from the well-known Additive-Increase/Multiplicative-Decrease (AIMD) [111] algorithm. AIMD combines a linear growth of transmission traffic during uncongested network conditions with an exponential reduction mechanism triggered when congestion is detected. Through DiPTC, we aim to leverage these proven concepts for effective and distributed traffic control in diverse networking environments.

In DiPTC two fundamental global parameters govern its operations. The first is the decrease factor, denoted as $x_D$, which serves as a primordial component in our strategy to implement a reduction mechanism. This factor is used when the network server encounters an influx of excessive data, facilitating an effective reduction strategy. Conversely, the second global parameter involves an increase policy, driven by the increase factor denoted as $x_I$. This factor becomes operational when the network server experiences a shortfall in data reception. In such instances, the increase factor comes into play, orchestrating a strategy to boost data reception and address the scarcity of incoming data. These global parameters within DiPTC play a crucial role in dynamically adjusting the network behavior based on the prevailing data conditions. This algorithm provides a prompt response by rapidly altering the number of transmitted messages by every node, depending on the information sent by the network server through the gateway 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 gateway is a binary value. In other words, the gateway will either spread 0, meaning that too many packets were received, or 1 if not enough packets were received. When the goal is met, the network server does not schedule any downlink, and the nodes continue to send the same number of messages for the next time period. The traffic intensity of each node increases linearly, taking the coefficient $x_I$ into account, as long as the network server does not receive enough 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$.

<figure><img src="image_12.png" /><figcaption>FIGURE 3.2: 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 that the node $n$ has to send 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 and $Max_{DT}$ the maximum number of messages that 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 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 if the number of received messages differs from the required number. This reduces downlink traffic.

To avoid an event-based synchronization between nodes that would lead to a situation where all the nodes react identically with the same number of messages to send, we introduce 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 LoRaWAN a node opens its reception window to receive the feedback
message from the gateway only if it should adapt its traffic as a result of a favorable draw ($V_n(t) = 1$). The Diagram Fig. 4.4 emphasizes this in blue.

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. 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$. Optimized scheduling of the transmission time is out of the scope of our work, and any scheduling algorithm could be applied.

## 3.6 Simulation model

While DiPTC can be used with any LPWAN technology, we focus here on applying it to LoRaWAN. To implement and test our proposal, we used LoRaSim [112], a well-known discrete event-based network simulator, as it allows us to simulate collision, capture effect, and interference in the network. We improved this simulator by adding downlink communication and a battery depletion model, as we discuss below.

### 3.6.1 Wireless environment

#### Downlink environment

In addressing a limitation of LoRaSim, which cannot initially simulate downlink communication in the context of LoRaWAN, our primary enhancement involved incorporating this missing functionality into the simulator. This enhancement aimed to provide a more comprehensive simulation environment that captures both uplink and downlink communication dynamics, mirroring the complete communication process in LoRaWAN. To further refine the simulation accuracy, we introduced a random variable following a Bernoulli distribution with a parameter denoted as $P_{DL}$. This variable was employed to model the reliability characteristics of downlink communication. The parameter $P_{DL}$ played a crucial role in defining the probability of successful downlink transmission, introducing a stochastic element that reflects the inherent variability in communication reliability observed in real-world scenarios.

#### Uplink environment

Additionally, in our simulation, we considered the insights from the work of Roedig et al. [112], particularly in describing collisions and interference on the uplink. This incorporation ensured a more realistic representation of communication challenges, contributing to the fidelity of the simulation environment. Through these enhancements, our goal was to provide a more accurate and comprehensive simulation of LoRaWAN communication scenarios. In their paper [112], Roedig et al. implement the collisions and interference on the uplink as follows:

* An uplink transmission is successfully received if the received signal power $P_{rx}$ lies above the sensitivity threshold $S_{rx}$ of the receiver. The received signal power $P_{rx}$ depends on the transmit power $P_{tx}$ and all gains and losses along the communication path.

$$P_{rx} = P_{tx} + GL - L_{pl}(d) \qquad (3.1)$$
where $P_{rx}$ is the power of the received signal, $P_{tx}$ the transmission power, $GL$ the accumulated general gains losses along the communication path, $L_{pl}(d)$ the path loss in dB at the communication distance $d$

* Several models exist to elucidate the variation in path loss under different environmental conditions such as open spaces or built-up regions. In our simulation, we leverage the long-distance path loss model, a commonly employed approach, particularly suitable for simulating deployments in densely populated and constructed areas.

$$L_{pl}(d) = \bar{L}_{pl}(d_0) + 10\gamma\log(d/d_0) + X_{\sigma} \quad (3.2)$$

$L_{pl}(d)$ the path loss in dB at the communication distance $d$, $\bar{L}_{pl}(d_0)$ the mean path loss at the reference distance $d_0$, $\gamma$ the path loss exponent, and $X_{\sigma} \sim N(0, \sigma^2)$ the normal distribution with zero mean, and $\sigma^2$ the variance to account for shadowing.

### 3.6.2 Energy consumption

No energy consumption model for the nodes is implemented by LoRaSim. We expanded the simulator by adding the one mentioned in [113]. After sending $m$ messages to each node $n$, the energy $E_c$ used depends on the time on air TOA, the power used in the reception mode $P_{wRx}$, and the power used in the transmitter mode $P_{wTx}$.

<table><caption>TABLE 3.1: 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 gateway</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>30J</td></tr></tbody></table>
$$E_c = TOA * (P_{wTx} * m + P_{wRx}) \text{ for DiPTC} \quad (3.3)$$

$$E_c = TOA * m * (P_{wTx} + P_{wRx}) \text{ for LoRaWAN} \quad (3.4)$$

The values used for the parameters in these models are presented in Table 3.1. The LoRa parameters (SF, CR, BW, Freq.) are chosen randomly at the beginning, and they do not change during the simulation. In our setup, we do not use channel hopping to be robust in case of interference and to avoid collisions, to study DiPTC behavior in the worst case (i.e., high collision probability).

## 3.7 Benchmark protocols

To our knowledge, we are the first to introduce a traffic control algorithm for LPWANs, making it challenging to compare our algorithm against existing alternatives as none currently exist. Despite this, we recognize the significance of establishing a comparison benchmark. In our evaluation, we contrast our proposal not only with the existing LoRaWAN protocol but also against an optimal benchmark called the Centralized Optimal Traffic Control protocol (COTraC). This comparative analysis provides valuable insights into the performance of our algorithm in relation to both current industry standards and an idealized optimal algorithm.

### 3.7.1 LoRaWAN protocol

Nodes in LoRaWAN transmit data according to a stochastic process that is represented by a Poisson distribution [73], [112]. This distribution describes the number of transmission attempts during a defined time frame, capturing the unpredictable and asynchronous nature of IoT device connectivity. Since nodes do not follow a set transmission schedule, the mean inter-arrival rate $1/\lambda$ in this context refers to the average rate at which nodes attempt to transmit packets, adding a degree of unpredictability. The Poisson distribution makes it possible to depict irregular communication patterns in a flexible way, which is crucial in Internet of Things scenarios where devices want to communicate data infrequently to save energy. By embracing randomness and asynchrony, LoRaWAN provides an effective framework for efficient and low-power data transmission over extended distances, catering to the diverse and dynamic nature of IoT applications.

To establish a fair and adaptive mechanism to compare with DiPTC, we suggest regulating the mean inter-arrival rate $1/\lambda$ of packet transmissions in LoRaWAN. In this context, nodes are responsible for sending packets containing measurements, and the objective is to ensure the reception of a specified number K measurements within a defined time period $\Delta T$. The rate parameter $\lambda$ is central to this regulation, and its calculation involves two key factors: the ratio of the time period to the desired number of measurements $\frac{\Delta T}{K}$, and the number of nodes in the network N.

$$\lambda = \frac{\Delta T}{K} \times N \quad (3.5)$$

$$AVG = \frac{1}{\lambda} \quad (3.6)$$

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.
The proposed formula provides a systematic and scalable approach to adjust the mean inter-arrival rate based on both the desired application constraint coefficients $\Delta T$ and $K$ and the network size $N$. This adaptive regulation helps prevent network congestion and ensures that each node can effectively contribute to achieving the specified reception goals within the given time frame. Ultimately, it supports fair and efficient communication in diverse LoRaWAN deployments.

### 3.7.2 Centralized Optimal Traffic Control protocol

The COTraC (Centralized Optimal Traffic Control) algorithm operates under the assumption that the network server serves as a central entity with comprehensive access to critical information about all nodes within the LoRaWAN network. This information includes the residual energy levels, duty cycle status, and LoRa transmission parameters for each individual node. The primary objective of the network server is to establish an optimal scheduling mechanism that adheres to the application requirements, ensuring that each node sends no more than a specified number $K$ of messages within a given time period $\Delta T$.

The scheduling strategy employed by the network server follows a round-robin approach, systematically cycling through each node in the network. During each round, a node is allowed to send its share of messages, not exceeding the predefined limit $K$ within the designated time interval $\Delta T$. If a particular node becomes incapable of sending messages due to factors such as energy depletion or adherence to duty cycle constraints, the scheduling mechanism seamlessly shifts to the next available node. This ensures that the network optimally utilizes its resources and accommodates the constraints imposed by individual nodes. This centralized approach has several advantages. Firstly, it leverages global information, enabling the network server to make informed decisions about scheduling based on the real-time conditions of each node. Secondly, the round-robin scheduling method provides a fair and equitable distribution of opportunities for message transmission among all nodes. Lastly, the adaptability of the scheduler to account for nodes that may be temporarily unavailable due to energy constraints or duty cycle limitations enhances the overall robustness of the communication system.

However, this optimal algorithm is far beyond realistic, and several potential challenges that could impact its practical implementation. Scalability is a notable concern, as managing a large number of nodes in the network may introduce latency and scalability issues for the central server. The constant communication required between nodes and the central server to update information and receive scheduling instructions may lead to increased communication overhead, affecting the overall efficiency of the system. Moreover, the heavy reliance on the central server poses a single point of failure risk, and any issues with the server could disrupt the entire network scheduling and communication. Real-time dynamics, accuracy of information, and adaptability to rapidly changing node conditions are additional challenges that need careful consideration. Lastly, optimizing for energy efficiency, a critical aspect of IoT networks requires meticulous attention to accurate energy information and sophisticated algorithms to achieve meaningful energy savings in practice.

## 3.8 Overall performance evaluation

This section covers the performance evaluation of DiPTC. We describe here the simulation scenarios, the DiPTC configurations, the LoRa [49] settings, and comparative algorithms. Then, considering several metrics (success rate, collision rate, and network lifetime), we compare the performance of DiPTC against the LoRaWAN and an optimal algorithm.

### 3.8.1 Scenarios and network parameters

We consider the case of a single central gateway 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 3.2. 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 and were chosen accordingly. We present a detailed study on how to choose these parameters in section 3.10.

<table><caption>TABLE 3.2: 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>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>1year</td></tr><tr><td colspan="4">LoRaWAN</td></tr><tr><td>AVG</td><td>1500 min</td><td>15 min</td><td>5000 min</td></tr></tbody></table>

When presenting a new approach, it is crucial to assess its performance across diverse conditions. For instance, a system that operates efficiently under regular traffic might face challenges when subjected to increased traffic loads. To test the performance of our system, we consider three different scenarios: BASIC, INTENSIVE, and DENSE. In the BASIC scenario, we evaluate our system under normal traffic conditions. 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 proposal. By testing our system under these different conditions, we can be confident that it will perform well in a variety of situations.

Table 3.1, 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]. Moreover, when a packet is lost, LoRaWAN is configured to re-transmit it a maximum of 8 times before dropping it, a value commonly used in different implementations given that the standard specifies a maximum of 15 re-transmissions. In DiPTC and in the COTraC there are no re-transmissions, as the nodes do not receive an unicast acknowledgment from the gateway like in LoRaWAN.

### 3.8.2 DiPTC vs. LoRaWAN vs. COTraC

In this section, we compare the overall performance evaluation of DiPTC against LoRaWAN and COTraC, using the following metrics:

* **Success rate $\mu_c$:** measures the number of times the base station receives exactly the K required measurements per period ΔT.

* **Collisions rate $\tau_c$:** measures the number of packet collisions in the network divided by the number of transmitted packets.

* **Network lifetime $t_i$:** measures the time the network can support the application requirements (i.e., the nodes can send the K required measurements per period ΔT before the exhaustion of their battery).

Table 3.3 summarizes the simulation results for these metrics considering the three scenarios BASIC, INTENSIVE, and DENSE.
In the BASIC scenario, DiPTC has a near-perfect success rate: three times that of LoRaWAN. As a result of DiPTC longer lifetime, the network is more durable. Despite the high traffic, DiPTC has a success rate of 58%, which is 64 times higher than LoRaWAN. Furthermore, DiPTC has a collision rate 32 times lower than LoRaWAN and a longer network lifetime. Also, in comparison to COTraC DiPTC performs as well as the COTraC protocol in terms of success rate and collision rate with a shorter network lifetime. In fact, in this scenario, one message is required by the application for each period of time 10min. This message can be sent only by one node which lowers the node competition in DiPTC and fits perfectly with the COTraC protocol where the transmission is done by one node all the time.

<table><caption>TABLE 3.3: LoRaWAN, DiPTC and COTraC performance</caption><thead><tr><th>Sc.</th><th>Measures</th><th>LoRaWAN</th><th>DiPTC</th><th>COTraC</th></tr></thead><tbody><tr><td rowspan="3">Basic</td><td>μ<sub>c</sub></td><td>29.97%</td><td>97.49%</td><td>99.1</td></tr><tr><td>τ<sub>c</sub></td><td>0.38%</td><td>0.014%</td><td>0%</td></tr><tr><td>t<sub>l</sub></td><td>8242.5h (11.29mos)</td><td>13226.5h (18.11mos)</td><td>89808.3h (123.02mos)</td></tr><tr><td rowspan="3">Intensive</td><td>μ<sub>c</sub></td><td>0.90%</td><td>58%</td><td>95.3%</td></tr><tr><td>τ<sub>c</sub></td><td>0.70%</td><td>0.074%</td><td>0%</td></tr><tr><td>t<sub>l</sub></td><td>25096min (2.48wks)</td><td>34707min (3.44wks)</td><td>54334min (5.39wks)</td></tr><tr><td rowspan="3">Dense</td><td>μ<sub>c</sub></td><td>28.99%</td><td>97.62%</td><td>98.6%</td></tr><tr><td>τ<sub>c</sub></td><td>0.085%</td><td>0.026%</td><td>0%</td></tr><tr><td>t<sub>l</sub></td><td>8912.83h (12.20mos)</td><td>13393.5h (18.34mos)</td><td>291033.33h (398.67mos)</td></tr></tbody></table>

Despite the high traffic in the INTENSIVE scenario, DiPTC has a success rate of 58%, which is 64 times higher than LoRaWAN. Furthermore, DiPTC has a collision rate 32 times lower than LoRaWAN and a longer network lifetime, thanks to our traffic control mechanism which limits the medium use.

However, the COTraC protocol outperforms DiPTC and LoRaWAN. With the overall knowledge of the network parameters and the nodes configuration in the COTraC protocol, the network server schedules the nodes traffic with respect to their energy so that the next one takes over immediately after the active node death or before the excess of its duty cycle limit without going through a transient regime. That explains the near-perfect success rate. Note that for all scenarios the success rate in the COTraC is not 100% because the uplink reliability is taken into consideration in the evaluation. The collision rate is zero in all scenarios because only one or two nodes are active simultaneously, and send the message(s) which lowers the collision probability to zero. Furthermore, in this scenario, the application requires 10 messages every minute. Those ten messages are sent by one or two nodes in COTraC. In DiPTC, however, they are sent by one, two, or even ten different nodes. As a result, reaching the application requirement in DiPTC takes more time and energy than in COTraC. Furthermore, as previously stated, COTraC does not have a transient regime, whereas DiPTC does. All these facts explain COTraC high success rate when compared to DiPTC.

In the DENSE scenario, DiPTC presents a success rate of 97%, which is three times that of LoRaWAN. This demonstrates that, despite the high number of nodes, DiPTC can meet the application requirements more often than LoRaWAN. In addition, when compared to LoRaWAN, DiPTC reduces collision rates threefold and increases network lifetime. Compared to COTraC, DiPTC performs as well as the COTraC protocol in terms of success rate and collision rate with a shorter network lifetime. In fact, in this scenario, one message is required by the application for each period of time 10min. This message can be sent only by one node which lowers the nodes competition in DiPTC and fits perfectly with the COTraC protocol where the transmission is done by one node all the time.

## 3.9 Horizontal and vertical scalability evaluation

To evaluate the performance of DiPTC in the BASIC scenario, we looked at various factors such as number of sent and received packets, collisions, dead nodes, and downlink/uplink losses throughout