Final Report

ns-3 simulation of propagation loss for various LoRa chirp variations of RYLR896 module

Abstract

LoRaWAN (Long Range Wireless Area Network) is a wireless communication protocol that makes use of the unlicensed spectrum. It is optimized for low-power and long-range applications as its name suggests, implementing 2 different types of nodes, gateways and end devices which are capable of communicating using a signal that sweeps multiple frequencies as it travels in time, also known as chirp. A chirp is capable of encoding information while providing resiliency to interference and therefore a long range. This study leverages ns-3 to implement a mechanism to simulate scenarios where the chirp characteristics are not fixed, just like in real-life deployed gateways and end devices, where the chirp characteristics change on a regular basis. To achieve this, a LoRaWAN module/IC (RYLR896: SX1276 chip with antenna) was selected to be modeled in the ns-3 simulation. As a result, the behavior of LoRa products that make use of that specific LoRa module can be more accurately simulated on ns-3.

Introduction

LoRa (Long Range) is a wireless communication technology designed for low-power, long-range transmissions between devices. It is a type of radio frequency (RF) modulation scheme that operates in the unlicensed Industrial, Scientific, and Medical (ISM) frequency bands, making it available for use by anyone without requiring a license. LoRa enables devices to communicate wirelessly over distances of several kilometers while using very little power. This makes it an ideal solution for applications that require long-range communication, such as IoT (Internet of Things) devices, smart cities, and environmental monitoring [13]. LoRa technology uses chirp spread spectrum (CSS) modulation, which enables a signal to be spread across a wide frequency range. This allows LoRa signals to be transmitted over long distances without requiring high power consumption. LoRaWAN (Long Range Wide Area Network) is a network protocol that operates on top of the LoRa technology. It provides a standard communication protocol for devices to connect to a LoRa network, enabling devices from different manufacturers to interoperate seamlessly.

LoRa transmits over license-free Megahertz radio frequency bands like 169 MHz, 433 MHz, 868MHz (Europe) and 915MHz (North America) [10]. We will be using the Europe frequency of 868MHz. The LoRa chirps produce a frequency vs time graph such as the one in Figure 1. The y-axis represents the frequencies and the x-axis represents the time. SF stands for “Spread Factor” which is seen on the graph as the x-axis range value for a single packet. SF values range from 7 to 12. A higher SF value results in a longer range transmission but a lower data rate. A lower SF results in a lower range transmission but higher data rate. It has been demonstrated that the effect on the range caused by changing the SF is not negligible and in fact noticeable in real-life scenarios as reflected by the paper “A Study of LoRa: Long Range & Low Power Networks for the Internet of Things”[14], where a series of field tests were carried out using the Semtech SX1276 IC outdoors and capturing packets while setting the SF to 7, 9, and 12. As expected, a higher SF value proved to be more resilient to propagation loss than lower values for multiple outdoor locations as shown in Figure 2.

LoRa Transceiver IC/Module

We are using the RYLR896 transceiver module which features the LoRa® long range modem. This enables the module to provide ultra-long range spread spectrum communication and high interference immunity whilst minimizing current consumption. The RYLR896 transceiver has frequency range of 868-1020 MHz using the Semtech SX1276 chip [9]. Transmissions in rural areas can range more than 15 KM [10]. It can achieve baud rates of between 300 and 115200 bps, depending upon the spreading factor [9].

The RYLR896 features a fixed antenna, which is directly connected to the LoRa module, as opposed to a detachable antenna. This is especially beneficial as a detachable antenna may prove less effective to use as they will affect the transmission of the packet data being sent. For our purposes we will be using a typical transmission power of 14dB at the receiver end.

Interacting with the LoRa module is done using the built-in STM microcontroller. The two components communicate with each other through a SPI (Serial Peripheral Interface) making sending commands to the LoRa module easier, abstracting away all the functionality of the SX1276 chip to AT COMMANDS, sent over UART (Universal asynchronous receiver-transmitter) protocol.

ns-3 LoRaWAN Module

There are multiple ns-3 modules that enable simulation of LoRaWAN networks. Some of them include a great deal of finer simulation details, but lack documentation and examples. The ns-3 module for LoRaWAN developed by a team of master students at the University of Padova, which would be later further developed by the SIGNET lab from the same university. The ns-3 module is well documented, using the same documentation framework as the original ns-3 documentation in Doxygen. In addition, the module includes multiple examples and was used to perform simulations for multiple papers on LoRaWAN networks, providing extra support and further explanation on how the model works.

This ns-3 module implementation has embedded a considerable amount of parameters that are trying to mimic the behaviour of Semtech SX1301, which means that it would be fairly easy to modify them and make the simulations have a higher degree of accuracy for a different Semtech chip, such as SX1276 and modules that make use of them such as RYLR896. Parameters such as transmission power, SF tuning, receiving sensitivity, frequency and bandwidth are all modelled in the ns-3 module from SIGNET lab.

The module's architecture includes a PHY (physical) layer model, which is connected to the channel which is used to send and receive packets, acting as the medium at the lowest level, and applies interference models as well as propagation loss models and assigns a receive power as well as if the packet was destroyed by interference or not. For a packet to be received from the channel, the receiver must be listening on the correct frequency with the correct SF. The module's architecture includes a Gateway model which implements Gateways and End Devices according to a typical LoRaWAN network architecture. Furthermore, the module also implements a MAC layer model that deals with the contents of the packet itself.

Although this ns-3 module is a powerful tool for LoRaWAN simulations, it has multiple limitations. This is mainly thanks to the LoRa specifications for different regions, which change multiple parameters such as frequency, bandwidth and behavior of gateways and end devices. Many of the previously mentioned parameters are hard coded for the EU (Europe) region in the Signet lab module since it was first developed at an Italian university. Even though modifying the code to change the previously mentioned parameters is possible, it would require a huge development effort and expertise on the inner workings of the module and the LoRa protocol on different regions. Hence, this study will build on top of the readily available features and configurations of the module and will use EU as the region for the simulations. As mentioned earlier, the LoRa channel is one of the most important abstractions that this module uses. It is the point of interest when talking about range, propagation and interference loss in the simulations. For this study, there is a strong focus on the propagation loss related to the SF and the distance between the nodes, given that the bandwidth is set to 125kHz and the frequency is set to 868MHz as per EU region spec. The channel is able to utilize propagation loss models and interference loss models from ns-3.

It is important to make the distinction from propagation loss and interference models on this module. These two models abstract a completely different source of loss for packets in the LoRa channel and hence they do not interfere with each other, instead, their behavior is aggregated by the channel to simulate the behavior of networks. This distinction means that in order to develop a model that mimics the propagation loss depending on SF and distance of nodes, we do not have to consider the interference of other devices or from the environment obstacles, since this behavior of the channel is abstracted away independently by the interference helper.

Node Hardware Architecture In order to acquire data to develop a propagation loss model that mimics the real life capabilities of the RYLR896 module, it is necessary to collect statistics of interest from nodes that make use of this module and that use different SF. Data as receiving power and packet drop rate at a distance will need to be collected for each SF and at different distances to characterize the RYLR896 module’s characteristics and to integrate them into the ns-3 LoRaWAN module to perform more accurate simulations for nodes that make use of the RYLR896.

To achieve this, we set out to develop a LoRa node that incorporates the RYLR896 as its transceiver by developing custom firmware for an ARM microcontroller to control the SX1276 IC inside the RYLR896. The microcontroller of choice was a STM32L4KC, which is ideal for this application given its small size, the availability of 2 UART peripherals with Direct Memory Access (DMA) support, an internal crystal oscillator (clock), and low power consumption. The development board for this 32-bit microcontroller provides an on-board debugger and standard breadboard pins for fast prototyping and ease of firmware flashing.

The microcontroller utilizes one of its UART peripherals to communicate with the RYLR896, for which a custom driver was developed by abstracting into a class, hence, the behavior of the IC can be independently controlled by any application. For this project, the application of interest was a simple sender that would periodically transmit a packet containing a counter, as well as a simple receiver which function would be to listen for packets and communicate them to the serial terminal of a Windows machine through a the second UART peripheral of the microcontroller and then through a USB/TTL dongle that goes to the Windows machine.

From the block diagram shown below, we can infer that both the sender and receiver nodes have the same hardware architecture, which was a main concern through the development of the firmware to ensure that any node could be flashed as a sender or as a receiver at any point of data collection if needed.

Data Collection

Data collection will be conducted as follows: our Receiver and Sender RYLR896 modules will start off at a distance of about 2 KM. The objective of the initial phase is to be far enough that no packets are received by the Receiver module.

The distance between the Receiver and Sender will be reduced by about 300m by bringing the modules closer to each other. At each distance we will be setting the SF to 7,8,9,10,11, and 12 while collecting at every SF the power at the receiver end, number of packets received at the receiver end and the distance between the Sender and Receiver. With the number of packets received we will be able to calculate the percentage of packets lost.

"SF" represents the spreading factor of the packet. "payloadLength" indicates the length of the payload being sent. "data" represents a counter which increments indefinitely. The counter helps us calculate dropped packets by observing skipped numbers. "RSSI" is the received signal indicator which helps indicate the quality of the connection. Lastly, we have "SNR" which is the signal to noise ratio indicator where a ratio higher than 1:1 (greater than 0 dB) indicates more signal than noise.

LoRa Propagation Loss Model Development

As mentioned previously in the introduction, the Spreading Factor (SF) can be tuned to achieve a wider range at the cost of lowering the data rate, which indicates that the propagation loss for each SF changes regardless of other parameters but the LoRaWAN module from SIGNET lab uses “vanilla” ns-3 propagation loss models, which are not designed for LoRaWAN and therefore are not able to account for the differences on propagation loss depending on the SF used for transmission.

Since a LoRa channel from the ns-3 module is able to utilize a propagation loss model native from ns-3, it is natural to think about extending the functionality of native propagation loss models to take into account distance and SF of sending and receiving nodes, or gateway and end device. To achieve this, a class that inherits from the native ns-3 module was developed to include a SF variable that needs to be updated with the specific SF that the channel is using, and will return the theoretical receiving power according to the propagation loss that the packet would suffer based on the datasets described in the previous section.

By using inheritance from the native ns-3 propagation loss model, we are able to use the LoRa Propagation Loss model (child class) interchangeably with the other non-LoRa native ns-3 propagation loss models without the need to make further changes for compatibility to the LoRaWAN module’s source code for the different layers, only the channel needed to be modified to be able to determine which SF is being used for each transmission before querying the propagation loss model for the receiving power (RSSI), which is calculated based on a linear interpolation of RSSI vs distance data collected from the RYLR896 IC.

Simulations for LoRaWAN Network Using Different Propagation Loss Models

To evaluate the performance of the LoRa propagation loss model developed for the RYLR896 IC, multiple simulations were carried out to compare the LoRa propagation loss model that takes into account SF to ns-3 “vanilla” propagation loss models. It is important to highlight that all simulations were done after the changes in the Physical layer to support the SX1276 IC were completed, this way simulations are based off of the same LoRa chip and can be directly compared.

The simulation scenario is comprised of multiple End Devices randomly situated around a single Gateway situated in the center of a circular area of radius 6300m. End Devices are assigned an optimal SF number based on the received power for packets from the Gateway, meaning that if an SF which does not provide a received power required at the End Device, it will be assigned a higher SF until the received power is equals or higher than the receiving sensitivity for the SX1276 chip for that specific SF. From the assigned value, it is easy to see how the data rate is affected, since it is inversely proportional to the SF, hence, the plots represent distance in the x and y axis, and represent data rate with a color scheme on the right.

Any “vanilla” propagation loss model from ns-3 can be used for such simulation scenario by creating an instance of it and assigning it to the channel. The LoRaWAN module uses LogDistancePropagationLossModel from ns-3 for all its simulation examples, which can be compared to the RandomPropagatonLossModel from ns-3 as well. It becomes evident why the authors did not pick the RandomPropagatonLossModel, which as shown on the right side of the figure below, seems to assign the lowest SF number (7) to all End Devices since it shows the data rate to be the highest (5), likely due to the random loss being so low that the extra range gained by increasing the SF was not necessary at all.

On the other hand, the LogDistancePropagationLossModel simulation on the right showed the importance of having a model that takes distance into account, demonstrating how the farther End Devices required an increase in their SF which lowered their data rate, this explain the fact that all data rates are present in the plot.

Now that we have established that the LogDistancePropagationLossModel makes for a compelling propagation loss model for this simulation scenario, we can directly compare our LoRa propagation loss model for the RYLR896 transceiver which we called RYLRLoraPropagationLossModel. From the figure above, we can observe that the plot for our RYLRLoraPropagationLossModel simulation on the right seems to have done a decent job at increasing the SF in order to obtain extra range at the cost of lowering the data rate, but compared to the LogDistancePropagationLossModel simulation, the range is dramatically lower than the one estimated by the authors of the LoRaWAN ns-3 module and used in their simulations, from this observation we can infer that there could be two possible reasons for this gap in the range, the first one being that their estimations do not account for any antenna attached to the SX1301 but our model for the RYLR896 implicitly accounts for the fixed antenna for the SX1276 it has inside, which would inevitably cause extra loss. The second reason would be the fact that the LogDistancePropagationLossModel only accounts for distance, but our RYLRLoraPropagationLossModel was specifically designed to account for distance and SF.

In order to exploit the compatibility benefits that our implementation of the RYLRLoraPropagationLossModel brings, we simulated the same scenario but taking it to an urban setting provided by the author of the ns-3 LoRaWAN module, which employs an urban grid with similar density to Manhattan which includes buildings with rooms and wall thickness [15]. The loss models to represent such scenario are compatible with “vanilla” ns-3 propagation loss models and hence they are also compatible with our LoRa propagation loss model.

The same scenario from previous simulations was replicated with a higher number of End Devices and a dense urban grid was added which is modeled in the simulation by the CorrelatedShadowingPropagationLossModel and the BuildingsPenetrationLoss model, both of which interact with the LogDistancePropagationLossModel plotted on the left and our RYLRLoraPropagationLossModel plotted on the right side. For both plots, it can be seen that even though some End Devices that almost overlap, they have a different data rate, which means that they also have a different SF. This likely thanks to the effect of the buildings in the simulation, where End Devices could be only a few meters apart but could be separated by a wall from a building or even could be in separate rooms despite how close they appear in the plot. Otherwise, the observations from the analysis of the previous simulation without buildings hold, where the range of both propagation loss models differ dramatically thanks to the two reasons previously mentioned involving the effect of an antenna as well as the effect of the SF in the range.

Discussion

The constraints that create a piece of code that has to integrate seamlessly with an already existent framework are reflected in the amount of time that it takes for a developer to learn the inner workings of the existing code, and build on top of it making the newly developed features compatible. This reflects a great part of the work that had to be done before even starting the development of our propagation loss model for LoRa, since we had to learn the inner workings of the ns-3 LoRaWAN module, and the existent ns-3 propagation loss models before developing our own to be compatible with the existent code.

Another challenge we faced while working on this project was learning new technologies and concepts as we go. Simple things like updating the waf and CMake build systems would become a bigger task that required research and time thanks to the lack of experience. There are multiple examples of this throughout the project, such as building up the background knowledge to understand the datasheets from Semtech SX1301 and SX1276 to be able to modify the ns-3 LoRaWAN module appropriately with the correct parameters to support SX1276.

Making the actual LoRa nodes (receiver and sender) was yet another non-trivial task we faced, that required a lot of learning and a speedy development of firmware and how to make it robust as well as coming up with ways to unit test changed to ensure that the functionality of both sender and receiver was optimal for the data collection process to go smoothly so that it only had to be done once.

Conclusion

In this project, we succeeded at developing a propagation loss model that accurately reflects the behavior for the RYLR896. This was achieved by modifying the ns-3 LoRaWAN module from SIGNET lab from the University of Padova [11] to support the SX1276 instead of the SX1301 since the SX1276 is used in the RYLR896. After doing so, we went ahead and created nodes that used the RYLR896 as its transceiver to collect real-life data for different SF, then this data was used to create a propagation loss model that took into account distance and SF and that was fully compatible with the existing functionality of the ns-3 module. Hence, once this work was completed, we were able to perform simulations to determine the differences between the propagation loss model that the authors of the LoRaWAN ns-3 module used and our own LoRa propagation loss model. After analyzing the simulation results, it was determined that the differences in range observed could be attributed to two main reasons: first, the fact that our model did account for the SF being used, and second because of the antenna effect that the fixed antenna that the RYLR896 has which causes extra loss as seen from the SX1276 from inside it. Some potential work to extend the functionality of the LoRaWAN ns-3 module by SIGNET lab are to abstract all the constants inherent to a chip, which would make it easier to go from the original SX1301, to the SX1276 and to any other one. Another possible contribution that would help to understand differences in range seen between chips could be to create an abstraction for them so that its loss can be modelled as an independent source of loss, unrelated to the propagation loss itself.

References

• [1] U. Raza, P. Kulkarni and M. Sooriyabandara, "Low power wide area networks: An overview", IEEE Commun. Surveys Tuts., vol. 19, no. 2, pp. 855-873, 2017.
• [2] D. Magrin, M. Centenaro and L. Vangelista, "Performance evaluation of LoRa networks in a smart city scenario," 2017 IEEE International Conference on Communications (ICC), Paris, France, 2017, pp. 1-7, doi: 10.1109/ICC.2017.7996384.
• [3] F. Van den Abeele, J. Haxhibeqiri, I. Moerman and J. Hoebeke, "Scalability Analysis of Large-Scale LoRaWAN Networks in ns-3," IEEE Internet of Things Journal, vol. 4, no. 6, pp. 2186-2198, Dec. 2017, doi: 10.1109/JIOT.2017.2768498.
• [4] Semtech, “SX1276 Product Details”. [Online]. Available: https://www.semtech.com/products/wireless-rf/lora-connect/sx1276/
• [5] Reyax Technology, “RYLR896 Specification”. [Online]. Available: https://reyax.com/products/rylr896/
• [6] A. Gutiérrez-Gómez et al., “A Propagation Study of LoRa P2P Links for IoT Applications: The Case of Near-Surface Measurements over Semitropical Rivers,” Sensors, vol. 21, no. 20, p. 6872, Oct. 2021, doi: 10.3390/s21206872. [Online]. Available: http://dx.doi.org/10.3390/s21206872
• [7] G. Codeluppi, A. Cilfone, L. Davoli, and G. Ferrari. “LoRaFarM: A LoRaWAN-Based Smart Farming Modular IoT Architecture,” Sensors, vol. 20, no. 7, p. 2028, Apr. 2020, doi: 10.3390/s20072028. [Online]. Available: http://dx.doi.org/10.3390/s20072028
• [8] V. Talla, M. Hessar,B. Kellogg, A. Najafi, J. Smith and S. Gollakota. “LoRa Backscatter: Enabling The Vision of Ubiquitous Connectivity”. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies. May 2017, doi: 10.1145/3130970. [Online]. Available: https://doi.org/10.1145/3130970
• [9] Rylr896｜Reyax Technology (no date) RYLR896｜REYAX TECHNOLOGY. Available at: https://reyax.com/products/rylr896/" (Accessed: March 12, 2023).
• [10] Meaney, D. (2023) Lora and Lorawan timing, ECS Inc. [Online]. Available: https://ecsxtal.com/lora-lorawan-timing/" (Accessed: March 12, 2023).
• [11] Ns-3 LoRaWAN Module Documentation. Signet Lab. [Online]. Available: https://signetlabdei.github.io/lorawan-docs/models/build/html/lorawan.html
• [12] D. Magrin. “LoRaWAN Simulations Using ns-3”, Department of Information Engineering, University of Padova, Italy. [Online]. Available: https://www.nsnam.org/tutorials/consortium19/wns3-lorawan.pdf
• [13] What is Lora®? (no date) Semtech. Available at: https://www.semtech.com/lora/what-is-lora (Accessed: March 12, 2023).