1. Introduction
Over the years Long-Range Wide Area Networking (LoRaWAN) has grown to become one of the leading Media Access Control (MAC) layer protocols in the Low Power Wide Area Networking (LPWAN) space [
1]. The LoRaWAN protocol typically runs on top of the LoRa physical layer developed by Semtec. The modulation technique used in the LoRa physical layer is a derivative of the Chirp Spread Spectrum (CSS) modulation and allows technologies such as LoRaWAN to achieve robust multi-kilometre communications while consuming minimal amounts of energy [
2]. The popularity of LoRaWAN is owed to its simplicity, openness and cost-effectiveness. Because of the CSS modulation technique which allows for robust long-distance wide-area wireless communications, LoRaWAN is deployed following a simple star topology which keeps it both simple and cost-effective. At the centre of the network is a high capacity gateway surrounded by and serving up to thousands of end devices. The end devices are typically battery-powered sensors and actuators that spend most of their time sleeping except when they have data to transmit to the gateway. This makes the end devices energy-efficient and ensures that they can survive on batteries for years [
3]. The gateway is connected, through a non LoRaWAN backhaul, to a centralized network server which performs all the complex operations of the network such as filtering duplicate data and performing data rate optimization for the end devices [
3].
Despite presenting itself as one of the most desirable network technologies in the LPWAN space, one of LoRaWAN’s biggest limitations is that it operates in the freely available Industrial, Scientific and Medical (ISM) bands [
4], which it has to share with other technologies while at the same time adhering to duty cycle regulations in those bands. Furthermore, LoRaWAN networks are often deployed in very challenging networking conditions. Therefore, LoRaWAN must have a network management mechanism to handle these network constraints. Furthermore, the responsibility of this mechanism must go beyond network management, it must also include the intelligence to manage the end devices’ transmission parameters to handle these network constraints, as well as improve network reliability and efficiency [
1]. LoRaWAN already has one such mechanism, the Adaptive Data Rate (ADR) algorithm. The ADR is an algorithm used by LoRaWAN’s network server to optimize the end devices’ transmission powers and data rates. When the algorithm is enabled, it ensures that the end devices use the highest data rates and the lowest transmission powers possible, thus enforcing network reliability and energy efficiency and improving network capacity [
5].
Although the ADR was introduced into LoRaWAN as a solution towards improving the efficiency of the end devices’ transmissions, studies have shown that the algorithm leads to increases in traffic collisions, especially in large networks [
6,
7,
8]. These findings have received significant attention from academia: numerous studies and proposals have been produced as potential solutions to this problem. These solutions have been critically studied and summarized by the authors in [
4]. The authors showed that these solutions have constantly brought improvements to the ADR. However, the authors also have argued that these improvements are still not adequate and that arriving at an ideal implementation of the ADR remains an open research area. Therefore, in this paper, the researchers used the knowledge gained from studying the findings in [
4] to design an enhanced version of the ADR that uses congestion statuses of spreading factors to determine optimized data rates for end devices. The proposed algorithm was then evaluated in a series of simulated experiments and its performance was compared against four other algorithms with the same characteristics from the papers [
7,
8,
9] in terms of data extraction rate (DER) and energy consumption (EC) [
4]. The evaluation results show that the proposed algorithm achieves at least 40 per cent better DER performance and at least 100 per cent better EC performance over the other four algorithms. The process of evaluating the proposed algorithm was guided by the following research objectives:
- (i)
To modify the Adaptive Data Rate algorithm to consider congestion statuses of data rates during the data rate optimization process to improve the collision probabilities of end devices’ traffic in Long-Range Wide Area Networks.
- (ii)
To use simulations to evaluate the effectiveness of the proposed modifications to the Adaptive Data Rate algorithm in mitigating the occurrence of traffic collisions in Long-Range Wide Area Networks.
The rest of this paper is organized as follows:
Section 2 discusses the ADR and related algorithms proposed by other researchers.
Section 3 presents the proposed algorithm.
Section 4 presents the experimental design that guided this research.
Section 5 and
Section 6 present the results and their discussion, respectively, while
Section 7 concludes the paper and provides insight for future work.
3. Spreading Factor Congestion-Aware ADR
In this section, the researchers present the proposed algorithm. The algorithm was named spreading factor congestion-aware ADR approach and is specified in Algorithm 1. The name of the algorithm came from the fact that it uses the congestion statuses of each spreading factor in the network to determine the best one for the end device that requested the ADR. The development of this algorithm was performed to answer the question: how can a modified Adaptive Data Rate algorithm be developed to efficiently manage and reduce signal interferences in LoRaWAN? And to carry out the defined research objective (i). The proposed algorithm has seven main global variables (i.e., snrList, sfList, uplinkCnt, optimizedSF, defaultMargin, snrLimit, sfUsageIndex). These variables are explained as follows:
Algorithm 1: Spreading Factor Congestion-Aware Adr Approach |
Inp.: Outp.: Steps: 1: | Signal-to-noise ratio and spreading factor values of the uplink messages. An optimized spreading factor value for the end device that requested ADR. snrList ← 0 |
2: | sfList ← 0 |
3: | uplinkCnt ← 0 |
4: | optimizedSF ← 12 |
5: | defaultMargin ← 10 |
6: | snrLimit ← [7: −7.5, 8: −10, 9: −12.5, 10: −15, 11: 17.5, 12: −20] |
7: | sfUsageIndex ← associative array of spreading factors and their usage indexes |
8: | |
9: | function optimizeDataRate(uplinkSNR, uplinkSF) |
10: | | snrList[uplinkCnt] ← uplinkSNR |
11: | | sfList[uplinkCnt] ← uplinkSF |
12: | | uplinkCnt ← uplinkCnt + 1 |
13: | | if uplinkCnt = 20 then |
14: | | | maxSNR ← max(snrList) |
15: | | | maxSF ← sfList[indexOf(maxSNR)] |
16: | | | minSF ← minSpreadingFactor(maxSNR, maxSF) |
17: | | | optimizedSF ← optimizeSpreadingFactor(minSF, maxSF) |
18: | | | uplinkCnt ← 0 |
19: | | else |
20: | | | exit |
21: | | end if |
22: | | return optimizedSF |
23: | end function |
24: | |
25: | function minSpreadingFactor(maximumSNR, maximumSF) |
26: | | margin ← maximumSNR − snrLimit[maximumSF] − defaultMargin |
27: | | steps ← round (margin / 3) |
28: | | SF ← maximumSF |
29: | | while steps > 0 and SF > sfMin do |
30: | | | SF ← SF − 1 |
31: | | | Steps ← steps − 1 |
32: | | end while |
33: | | return SF |
34: | end function |
35: | |
36: | function optimizeSpreadingFactor(minimumSF, maximumSF) |
37: | | optSF ← minimumSF |
38: | | counterSF ← minimumSF |
39: | | while counterSF <= maximumSF do |
40: | | | if sfUsageIndex[optSF] > sfUsageIndex[counterSF] then |
41: | | | | optSF ← counterSF |
42: | | | end if |
43: | | | counterSF ← counterSF + 1 |
44: | | end while |
45: | | sfUsageIndex[optSF] = sfUsageIndex[optSF] + 1 |
46: | | return optSF |
47: | end function. |
snrList: a list of SNR values to be used in determining the best data rate. The list is initially empty and is updated each time the end device sends an uplink to the network server.
sfList: a list of SFs that corresponds to the collected SNR values. The list is also initially empty and is updated each time the end device sends an uplink to the network server.
uplinkCnt: a counter to keep track of the number of uplinks that the end device has sent to the network server since the ADR was requested.
optimizedSF: the SF that will represent the optimized data rate. This variable stores the value that the algorithm will calculate once enough data has been collected.
defaultMargin: the device-specific margin. This value is given in the devices’ datasheets. A value of 10 is used in this experiment as it is generally the value for most devices.
snrLimit: a list of limits required for each SF for the receiver to be able to demodulate the received signal. These values are used in determining the margin required for optimizing the data rate.
sfUsageIndex: a list of stored values representing the number of devices using each SF. The values will be used to determine the SF with the fewest devices using it. This list is one of the most important pieces required by the algorithm.
As it can be seen from the pseudocode in Algorithm 1, the algorithm is split into three functions that perform specific tasks. All the functions are vital to the operation of the algorithm:
optimizeDataRate function: The optimizeDataRate function is the main entry point to the algorithm. It accepts the uplink SNR value as well as the uplink SF, stores them in their respective lists, and then updates the counter. Just like in the native ADR, once the counter has reached 20 uplink messages, the algorithm starts to calculate the optimized data rate. In the optimizeDataRate function, the maximum SNR value and the maximum SF are computed. The results are then passed in as parameters to the minSpreadingFactor function.
minSpreadingFactor function: As the name suggests, this function is used to determine the lowest value of the SF that the end device can support while being able to reach the gateway. This SF is what will represent the optimized data rate. To compute this value, the function first calculates the margin and the number of steps the algorithm needs to run from the passed in parameters and the default margin using Equations (3) and (4) respectively:
where snrLimit[maximumSF] is the SNR limit from the SNR limit list that corresponds with the value stored in the maximumSF variable and the defaultMargin is the device-specific margin given in the device datasheet. And the “round” in Equation (4) represents the integer part of the resulting calculated value. From here, the function then loops from the calculated value of steps until the value reaches zero and tries to minimize the value of the SF to its possible optimal value. Once the loop exits, the remaining value of the SF is considered as the lowest value that the end devices can support. This value is returned to the main function and stored in the minSF variable. Once the mainFunction has the value of the minimum SF, the optimized SF can be computed. To do this, the optimizeSpreadingFunction function is called by passing in the minimum SF and the maximum SF values to it as parameters.
optimizeSpreadingFunction function: Using these values (i.e., minimum SF and the maximum SF), the function runs a loop from the minimum SF to the maximum SF and tries to find the least utilized SF value using the SF usage indexes stored in the sfUsageIndex list. If the least utilized SF is found, it’s returned. If not, the minimum SF value is returned instead. This ensures that the returned value is optimized even when the least utilized SF is not found. The optimized SF is then returned to the main function and stored in optimizedSF variable, and the counter is then reset. The value stored in the optimizedSF variable is then sent down as part of the response to the end device the next time the device sends an uplink.
4. Evaluation Setup
The goal of this research experiment was to empirically evaluate the spreading factor congestion-aware ADR algorithm and to study its performance in terms of reliability and energy efficiency against that of the traditional ADR algorithm and the related algorithms presented in
Section 2.2. Data was collected using network simulations via LoRaSim, “a discrete-event simulator based on SimPy for simulating collisions in LoRa networks and to analyse scalability” [
12]. The end devices in the network setup were varied in steps of 100 from 100 to 2000. This was done to represent an increase in network size and allowed the researchers to study the performance implications of the algorithm in varying network sizes. The European ISM band was chosen for the network simulation setup. This ISM band was chosen as currently, it is the only band that is supported by all existing implementations of the ADR. The parameters used for the simulations are shown in
Table 2 and are specific to the chosen ISM band except for the coding rate. A coding rate of 4/5 was chosen as it is the lowest coding rate available in LoRaSim and it the researchers wanted to ensure that it is kept constant so that it had little to no effect on the achieved evaluation results. In the simulations, the end devices chose transmission parameters: TP and SF based on the algorithms’ specifications. In the scenario without the ADR algorithm, the transmission parameters were chosen randomly by the end devices. The simulation scenarios were set up such that all end devices could reach the gateway with their selected transmission parameters. This was done to ensure that each end devices traffic was accounted for in the overall evaluation results. The simulation network setup consisted of a single gateway at the centre of the network with the end devices randomly scattered around it, as illustrated by the simplified topology in
Figure 1. In the topology, the end devices were connected to the gateway through a LoRa network with LoRaWAN as the communication protocol, while the gateway, the network server and the application server were connected through an internet protocol backhaul.
The chosen simulation scenario represented a simple sensing application where end devices sense and transmit data to the gateway at 1-h intervals. This type of application was relevant enough for the researchers to use to collect performance data about the different algorithms. In this research experiment, this application involved the end devices sending 20-byte packets to the gateways every 1 h. The end devices and the gateway adhered to the 1% duty cycle required by applications operating in the European ISM band [
14]. All simulation scenarios mentioned lasted for one week and were executed ten times as in [
8]. The results were reported as averages from the iterations and visualized using graphs. The evaluated parameters from the results were the Data Extraction Rate (DER) and Energy Consumption (EC).
5. Results
This section presents the results of the simulated experimental study performed to carry out the objectives presented in the introduction and to answer the following research questions:
- (1)
How can a modified Adaptive Data Rate algorithm be developed to efficiently manage and reduce signal interferences in Long-Range Wide Area Networks?
- (2)
How effective are the proposed modifications to the Adaptive Data Rate algorithm in reducing signal interferences in Long-Range Wide Area Networks?
DER is the ratio of traffic sent by end devices to the traffic received by the gateway. The value ranges from 0 to 1 and the closer the value is to 1, the better the DER. At 100 end devices in the network, the results obtained for the proposed algorithm are closely matched with those of the other algorithms presented in
Section 2.2. At this point, the proposed algorithm’s performance displays a slight superiority over the rest of the algorithms, achieving a DER of 0.97, a value that is 0.02 units higher than that of the closest competition from ADR-Dense. Overall, the performance relationship displayed by the results is an inverse proportionality relationship. The performance of the proposed algorithm starts high when the network size is small and exponentially degrades as the network size increases. Throughout all network sizes, the proposed algorithm has shown superior performance over the rest of the other algorithms including the native ADR and network with no ADR. As the network size continues to increase, the performance of the proposed algorithm starts to pull away from the rest, degrading less and less compared to the rest of the algorithm. ADR-Dense and FADR, which are the closest competitors to the proposed algorithm, begin to achieve DER results below 0.5 at about 1200 end devices. At this point, the proposed algorithm still achieved an ADR value of over 0.6. What is significant from the results presented in
Figure 2 is that throughout all the network sizes studied, the proposed algorithm managed to achieve a DER of over 0.5. At the maximum number of end devices, the DER achieved by the proposed algorithm stands at about 0.52. Surprisingly, the closest result to this is that of a network with no ADR algorithm employed and is at 0.36. That means at 2000 end devices, the proposed algorithm achieves a 44% better performance over its closest competitor. Overall, the proposed algorithm has shown superior performance over the discussed algorithms in
Section 2.2, the ADR and the network with no ADR.
As can be seen from
Figure 3, the proposed algorithm’s energy consumption is directly proportional to the size of the network. As the number of end devices in the network increases so does the network’s overall energy consumption. At a hundred end devices, the proposed algorithm’s energy consumption is very low and closely matched with that of both the ADR and the algorithms presented in
Section 2.2. From the results, EXPLoRa-SF and EXPLoRa-AT were the worst performing algorithms from the experiment, achieving the highest energy consumption in the network. At 2000 end devices, both algorithms had energy consumptions 700 and 450 per cent higher than that of the native ADR and the proposed algorithm, respectively. The algorithms whose performances were the closest to those of the native ADR and the proposed algorithm were FADR and ADR-Dense. However, at 2000 end devices, both algorithms still managed to consume energies that were 200 and 100 per cent higher than those of the native ADR and the proposed algorithm, respectively. Although the proposed algorithm had lower energy consumptions as compared to the other algorithms across all network sizes, overall, the EC performance of the algorithm was still inferior to that of the native ADR, which had the lowest energy consumptions across all network sizes as compared to the rest of the algorithm. However, the proposed algorithms energy consumptions were not too high. In fact, at 2000 end devices, the algorithm’s energy consumption was a little over 40 per cent higher than that of the ADR.
6. Discussion
6.1. Data Extraction Rate
The goal of the proposed algorithm was to reduce collisions in LoRaWAN by using SF congestion statuses to determine the optimized data rates for end devices with ADR enabled. It is important to note that in a network like LoRaWAN it is impossible to eliminate collisions, even with network management mechanisms such as the ADR or any versions thereof, especially in dense networks. That is because LoRaWAN has a limited number of transmission parameters that these mechanisms can manipulate to give network traffic the best chances of successful transmission. And as network sizes increase, the number of potential colliders with every transmission also increases. Therefore, how well an algorithm performs in terms of DER is judged based on the extent to which the algorithm reduces the number of collisions when it is employed in a LoRaWAN network. The DER results presented in
Section 4 indicate that the proposed algorithm has an overall superior performance over both the native ADR and the related algorithms presented in
Section 2.2.
This helped the authors to answer research question 2: the proposed algorithm has proven to be highly effective in mitigating the occurrence of collisions in LoRaWAN, achieving the highest DER of all the algorithms that were under investigation in all networks sizes. In small network sizes, the proposed algorithm performed closely with the other algorithms. However, as the network size continued to grow, the performance of the proposed algorithm became more and more superior. When the DERs of the other algorithms had dropped below 0.5, that of the proposed algorithm was above 0.7. That is a 40 per cent or better performance than the other algorithms. This shows the significant performance boost the proposed algorithm can bring to LoRaWAN.
Surprisingly, at the largest network size (of 2000 end devices) the proposed algorithm managed to achieve a DER above 0.5 and still maintain a 40% superior performance over the rest of the algorithms. This appealing performance of the proposed algorithm in dense network settings is owed to how it performs data rate optimization. The algorithm keeps track of the congestion statuses of each SF. And when optimizing the data rate for an end device, it uses the congestion statuses to find out which of the computed optimized data rates uses the SF with the lowest congestion status. This ensures that the end device’s traffic experiences the lowest collision probability possible. And while the data rate may not be the most efficient at times, this is compensated by better transmission reliability.
6.2. Energy Consumption
Low energy consumption is essential in LoRaWAN as most of the end devices are battery powered and are expected to survive on those batteries for years. As such, even though the focus of the proposed algorithm was on DER, it was still essential that the authors measure its EC performance to evaluate and study its implications on the overall LoRaWANs EC and end devices’ battery lives. The overall EC results indicate that the proposed algorithm has a superior performance over the algorithms discussed in
Section 2.2. Despite this, the results also indicate that the algorithm is still outperformed by the native ADR. The inferior performance against the native ADR is however expected as the proposed algorithm was not designed to improve EC but rather DER.
As it can be seen from
Figure 3, the relationship displayed by the results is a directly proportional one. As the network size increases, the overall network EC also increases. This behaviour is expected as more end devices in the network lead to more contributors to the overall network EC. Also, an increase in network EC cannot be eliminated as end device transmissions depend on energy consumptions. Furthermore, higher energy usages are essential for achieving long-distance transmissions without corrupting the transmitted traffic. Lastly, end devices depend on increasing transmission powers to try and regain connectivity to the network server.
Even though the native ADR outperformed all the algorithms it was compared with, the proposed algorithm still managed to achieve reasonable EC performances closest to those of the native ADR. For small network sizes, the EC performance differences between the proposed algorithm and the native ADR were barely noticeable. From the experimental results, it is evident that the performance differences become most noticeable at 2000 end devices in the network. At this network size, the proposed algorithm consumed 70 joules more energy than the native ADR. The extra energy consumption by the proposed algorithm was to be expected as, in addition to computing optimized data rates for end devices, it also must go a step further and ensure that the data rates provide the end devices’ traffic with optimized collision probabilities. Therefore, considering this reason, it can be argued that the proposed algorithm performed desirably. Especially because the algorithm was only built to improve DER.
7. Conclusions
ADR, which is the resource allocation mechanism currently being employed in the LoRaWAN, has proven to be quite immature and poor performing, especially in dense network scenarios. This paper proposes a modified version of ADR and presents an empirical analysis of its performance in terms of DER and EC. The evaluation was performed using simulations to study and critically analyze the proposed algorithm’s performance implications on LoRaWAN as network sizes increase and how well the algorithm performed against the native ADR and four other related algorithms proposed by different researchers. The results have shown that when network sizes are small, the proposed algorithm and the algorithms considered in this paper perform fairly well and close to each other. Only when the network sizes get too large that the proposed algorithm’s superiority starts to be most noticeable. That is, when the network sizes gradually increase, the proposed algorithm completely outperforms the rest of the algorithms, including the native ADR. At around 1000 end devices in the network, all the other algorithms were achieving DERs that were below 0.5 while the proposed algorithm managed to achieve a DER of about 0.7. That is over 40% better performance compared to all the algorithms that were considered in the experiment. The proposed algorithm continued to maintain this superiority across all network sizes and at 2000 end devices in the network it still managed to achieve a DER that was above 0.5. For EC, the ADR still has superior performance over the proposed algorithm and the other related algorithms that were considered in this research. Of course, that is to be expected as the algorithms are mostly targeted towards improving the DER. Based on the results discussed and arguments made here, the authors can further argue that the ADR performs poorly under dense networks and that although attempts have been made to improve it, these attempts still need to be supplemented. And conclude that the proposed algorithm builds on the existing algorithms and the ADR and significantly improves them in terms of DER and EC (excluding the native ADR), which is a significant step towards an ideal implementation of LoRaWAN’s ADR.
In the future, the authors plan to build the algorithm’s support for other ISM bands as opposed to just the European ISM band as it is the only band that is currently supported by ADR algorithms. Furthermore, the authors plan to improve the proposed algorithm to consider EC during transmission parameter optimizations. This could improve the algorithm’s overall performance and nudge it closer to the ideal implementation of a network management mechanism.