A Duty Cycle-Based Gateway Selection Algorithm for LoRaWAN Downlink Communication

1  Introduction

IoT has become everywhere and is currently part of our daily lives. IoT devices have been deployed in different fields in our living environments, such as the health care sector, smart home, smart city, manufacturing, and smart farming. According to the mobility report issued by Ericsson, the IoTs connections are forecasted to reach 30.2 billion connections by the end of 2027 [1]. Wireless connectivity is the main building block for IoT connectivity. It provides the essential infrastructure for IoT device communication. Short-range communication systems such as ZigBee, Bluetooth Low Energy (BLE), and Wi-Fi are the commonly used technologies for IoT. However, the rapid acceleration in the IoT services and applications led to the advent of low-power and long-range communication systems to facilitate services and application expansions.

The Low Power Wide Area Network (LPWAN) [2,3] paradigm combines long-range communication technology with low power consumption techniques to fill the gap that short-range communication systems left behind. LPWAN connects IoT devices that spread over a long geographical range while keeping power consumption at possible lower levels with battery life sustained for several years. It targets IoT applications that accept high latency communication with a low data rate. Several wireless technologies have been developed based on the LPWAN standards, including Narrowband IoT (NB-IoT) and Extended Coverage Global System for Mobile Communication (EC-GSM) by 3GPP, DASH7 Alliance Protocol (D7AP) by Dash-7 alliance, Sigfox, and LoRaWAN by LoRa alliance.

LoRaWAN has been developed to satisfy the requirements for various IoT applications [4] requiring long-range coverage with low power consumption while operating with a low data rate. It is considered one of the most promising technology in the LPWAN field [5]. In its basic form, LoRaWAN consists of end devices (IoT nodes), gateways, and a central network server managing the network. Radio spectrum is used to connect end devices to the gateways, which are connected to the network server via different technologies such as Cellular and Ethernet networks. The edge nodes send their traffic toward gateways that relay it to the network server. Such traffic is known as uplink traffic. LoRaWAN also supports downlink communication in confirmed mode, which distinguishes LoRaWAN from other existing LPWAN technologies to allow the network server to control the end device configurations. Moreover, the downlink communication is also used to provide traffic acknowledgments if needed based on the requirements of the deployed IoT application.

Even though LoRaWAN supports uplink and downlink communication, most of the work in the literature focuses on LoRaWAN assuming uplink communications only. This has made majority of LoRaWAN applications as best-effort applications since no reliable data transfer techniques are employed. Moreover, the downlink communication is not only limited to providing reliability and higher quality of services via acknowledgments but also is optimized for LoRaWAN administration procedures such as MAC commands issued by the network server, end devices activation, application notification, and firmware updates. Despite its advantages, the downlink communication feature introduces new challenges to the network performance, especially for networks operating in confirmed mode using acknowledgments and retransmission techniques. Thus, the work in this paper firstly identifies the usage and the limiting factors for downlink communication and then proposes DCGS to enhance downlink communication performance in LoRaWAN.

The main contribution of this paper is the development of a novel gateway selection algorithm for LoRaWAN named a Duty Cycle Gateway Selection algorithm (DCGS). DCGS is proposed to enhance the performance of downlink communication, which is considered one of the drawbacks of LoRaWAN. The main idea of the proposed algorithm is to avoid exhausting a gateway duty cycle with downlink traffic by distributing the downlink traffic among available gateways based on the duty cycle time off. The proposed system is then implemented in simulation tools for performance evaluation and comparison purposes. DCGS is compared to the traditional gateway selection algorithm based on the SNR value. Findings of the performance evaluation show that the proposed system exhibits an enhancement over the current algorithm in several used metrics.

The rest of the paper is organized as follows: Section 2 provides an overview of LoRa and LoRaWAN, including the architecture of LoRaWAN networks, and highlights some of its features. The motivation and importance of downlink communication are presented in Section 3. It also reviews the related works to the matter under investigation. The proposed system is then introduced in Section 4. Section 5 covers the simulation setups and describes the simulated scenarios along with the used evaluation metrics. The result is then shown and discussed in the same section. Finally, the conclusion of the work is drawn in Section 6.

2  Technology Overview

LoRa Alliance [6] has developed LoRaWAN as an open standard for low-power communication. It is based on the LoRa technology as the underlying physical layer. LoRa stands for Long-range and is a proprietary, patented solution developed by Semtech [7]. LoRa uses Chirp Spread Spectrum (CSS) modulation to enhance noise immunity, receiver sensitivity, and interference avoidance. The transmitted signal, according to the CSS modulation technique, is encoded into chirps that are spread over the spectrum and differ their frequency over time. A chirp can be an up chirp, varying from low to high, or a down chirp varying from up to down within the boundaries of the used channel.

LoRa operates in the Industrial, Scientific, and Medical (ISM) band. It is a license-free sub 1 GHz band. Any frequency under 1 GHz can be used depending on the region or country regulation for operating in the ISM band. Therefore, LoRa can work by individuals or companies without the need for a license providing that the emission regulations are respected. The used frequency bands, for example, in Europe, are EU 863-870 and EU 433 [8]. Saudi Arabia similarly uses the same bands, according to the Communication and Information Technology Commission [9,10]. Such regulation restricts the transmission power, the channel, and the duty cycle. The transmission in the LoRa protocol occurs using different Spreading Factors (SF), which affects the transmission data rate. It uses six orthogonal SF where the same SF within the channel does not allow concurrent simultaneous transmissions. A different data rate can be achieved depending on the used SF. The lowest SF allows the highest data rate but at the cost of a short transmission range and vice versa with higher SF.

A trade-off between power consumption and transmission reliability can be achieved based on several communication parameters which feature LoRa modulation [11]. Parameters include SF, Coding Rate (CR), and bandwidth. The SF ranges from 7 to 12; the CR can be 4/5, 4/6, 4/7, or 4/8, and the bandwidth takes one of these values; 125, 250, or 500 kHz. The CR is used to perform the Forward Error Correction (FEC) technique. The lower the value of CR, the higher the robustness of the transmission. FEC is optimized by the receiving device to restore any damaged traffic due to noise. All the mentioned parameters directly affect the traffic Time-On-Air (TOA).

LoRaWAN network is deployed as a star-of-stars topology consisting of end devices, LoRaWAN gateways, Network Server, and application server. The communication between end-devices and gateways are fulfilled using LoRa technology, whereas IP network such as Ethernet, Wi-Fi, or Cellular networks can be used for gateways-network server communication (see Fig. 1). The Network server is regarded as the brain of the LoRaWAN network. End devices send their traffic toward gateways, where traffic gets forwarded to the network server. The overall network is managed by the network server. It controls the end devices’ transmission parameters; filters duplicated traffic that may arrive through different gateways, and decide which gateways can be used for downlink and network command issued by the server.

Figure 1: LoRaWAN architecture

The direction of communication traffic depends on the purpose of the deployed applications. LoRaWAN supports confirmed and unconfirmed modes. In the confirmed mode, the network server acknowledges the receipt of traffic using the downlink directions. The acknowledgment packet is sent using only one of the available gateways. In case of no acknowledgment was received by the initiating end device, it keeps retransmitting the original packet until an acknowledgment is received or maximum retransmission is reached. However, some applications do not require acknowledgments; hence, most traffic uses the uplink direction [12]. The uplink traffic is broadcast by end devices to one or more gateways, which forward it to the network server.

LoRaWAN standard defines three different classes for end devices based on the nature of the operation: Class A, Class B, and Class C. Class A supports bidirectional communication between end devices and the gateways. However, the downlink traffic is only allowed during one of the two receive windows, which follow each uplink transmission. This class of operation provides a better battery-saving feature compared to other classes. Class B offers bidirectional communication but adds additional scheduled receive slots for frequent downlink communication. Gateways in class B are required to broadcast periodic beacon messages. The beacons are used for synchronizing end devices with the gateways. The window in-between two beacons is divided into small slots that can be allocated for end devices to be used for downlink traffic. However, it increases end device power consumption as the device must be synchronized all the time [13]. Class C, on the other hand, entitles end devices to have an almost continuous receive window where their radio interfaces are always on. They can listen continuously to incoming traffic. This class is most suitable for end devices with no concern regarding power consumption. It offers the lowest latency for downlink traffic compared to other classes.

The network server manages a LoRaWAN network by implementing the Adaptive Date Rate (ADR) mechanism. It uses ADR to assign transmission parameters for each end device by sending ADR commands. It assigns each end device the lowest available SF to enhance the communication between end devices and gateways and at the same time keeps power consumption at the minimum level. The ADR algorithm is executed by the network server when it receives a packet from an end device. The network server decides the transmission parameters (SF and transmission power) for an end device based on the collected measurements over the last 20 packets which were received from the same end device [4]. The ADR mechanism is more suitable for static and high-capacity networks. However, a blind ADR mechanism is also specified by LoRa Alliance to achieve both good coverage and minimum power consumption. Its feasibility has been studied in [14] and found to outperform the standards ADR.

3  Motivation and Related Work

3.1 Motivation

Even though LoRaWAN supports both uplink and downlink traffic, most of the work in the literature focuses on the uplink communication from the end devices to the gateways. It mainly focuses on enhancing and optimizing uplink traffic. This is due to the fact that LoRaWAN is commonly optimized for telemetry systems. As a result, the majority of the proposed IoT applications based on LoRaWAN are best-effort applications, presenting uplink direction communication with unconfirmed traffic and ignoring downlink traffic which could have been needed to provide delivery confirmation.

Allowing intermittent downlink traffic to end devices is necessary for LoRaWAN functioning. It makes downlink communication a crucial part of proper LoRaWAN applications. Moreover, there exist some IoT applications which require reliable data transfer. To meet such reliability, LoRaWAN employs acknowledgment messages and a retransmission mechanism to guarantee traffic delivery. However, the high-volume traffic of retransmissions that could drain the network has made the use of the mechanism unfavored by network operators. Therefore, enhancing the downlink communication efficiency is an essential topic within LoRaWAN.

The downlink communication is not only limited to traffic acknowledgment but is also used by LoRaWAN for different management-related functions [15]. The following list highlights the primary sources for downlink traffic:

•   Over-The-Air-Activation (OTAA): LoRaWAN offers two approaches for end devices to join the network; OTAA and activation by personalization. In the former, an end device sends a joint request message, and the network server in response replies with a join accept message using the downlink direction.

•   MAC commands: LoRaWAN uses sets of MAC commands for administration purposes. Such commands are exchanged exclusively between end devices and the network server. Examples of these commands transmitted by the network server are LinkCheckAns, LinkADRReq and DutyCycleReq; these are used to answer LinkCheckReq, requesting an end device to reset one of its parameters and setting the maximum duty cycle for an end device, respectively. For more details on the MAC commands, see [16].

•   Application notifications: IoT application servers may need to relay information to end devices, such as decisions based on result analysis or some commands to modify sampling intervals.

•   Remote firmware update: firmware updates are used to enhance the deployed IoT application in terms of security, fix bugs in the existing firmware, and add more functionalities [17]. The Firmware Update Over The Air (FUATA) [18] is one of the first proposed solutions for a remote firmware update in LoRaWAN.

LoRaWAN downlink communication comes with different limiting factors, including duty cycle saturation and using half-duplex mode by gateways which affect the overall performance of a deployed network. Gateways are susceptible to duty cycle saturation. It happens when a gateway exhausts its permitted transmission time due to complying with the region-implemented duty cycle while still having traffic to forwards towards end devices. Consequently, the gateway possibly became a bottleneck for downlink traffic. Thus, end devices may resort to packet retransmission, assuming the original packets have not been received by the network server.

Moreover, operating in half-duplex modes is also seen as a limiting factor for downlink communication. This is due to the fact that once a gateway starts to transmit downlink traffic, no end device can send its uplink traffic to the gateway during the gateway transmission time. Thus, high-volume downlink traffic in large networks will limit end devices’ ability to transmit their traffic, hence decreasing the overall network performance.

3.2 Related Work

The downlink communication topic in LoRaWAN has been studied, and several related works have been published in the literature. Different aspects of the downlink have been tackled. Some of the work focused on identifying and understanding the issue, whereas others have made efforts to solve the issue. This subsection highlights the related works.

The performance of LoRaWAN scenarios in the presence of both uplink and downlink communication has been investigated and analyzed by many researchers in the literature [17,19–22]. The works in [19–21] concluded that downlink traffic has a significant impact on the overall performance of LoRaWAN. An increasing number of gateways, changing sub-bands priority, and introducing adaptation strategies for network parameters were among the suggested solutions to decrease the impact of downlink communication on the network performance. Authors in [22] focused more on selecting the best gateway to forward the downlink traffic to enhance the overall efficiency of the network. Gateways were selected based on the Received Signal Strength Indicator (RSSI), a gateway with the lowest load and combinations of both. Best results were achieved when choosing the gateway with the lowest load strategy was used. The work in [17] investigates the impact of using multiple gateways for firmware updates over the air. They extended the FUOTAsim tool to support multiple gateways. The simulation area was then divided into multiple clusters based on the maximum communication distance between gateways and end devices. The goal was to simulate a multicast group when performing the firmware update procedure. The paper concluded that firmware update is highly affected by the number of used gateways due to reducing transmission range and reducing overall power consumption while achieving efficient update during a short time.

The acknowledgment aggregation method has been used to enhance LoRaWAN performance in the presence of downlink communication [23,24]. The proposed extension of LoRaWAN in [23], A2S2-LoRaWAN, constructed a periodic time-slotted frame and combined it with aggregated acknowledgments to improve the network efficiency. A naive aggregation is used by gateways to decrease downlink traffic. Upon receiving aggregated acknowledgment, an end device checks for its own acknowledgment within the message. If no acknowledgment was found, the end device should retransmit the original message in the following super-group iteration. The aggregated acknowledgment is also used in [24]. A network server constructs an aggregate acknowledgment named (AggACK) that contains cumulative acknowledgments for several packets. The AggACK is sent it to multiple end devices periodically. A twenty-second periodic interval for transmitting the AggACK is assumed to be the optimal waiting time to achieve better throughput. The system was evaluated in the NS-3 simulator with 200 end devices.

Three different strategies were used in [15] to solve the downlink communication issue. The first strategy was to increase the number of gateways in the network. It is claimed that uplink traffic that overlaps with the downlink traffic can be received by other free gateways. Consequently, the other free gateways cover the active gateway and forward the uplink to the network server. The second strategy was a theoretical hardware-based solution that allows parallel transmissions on different channels and other orthogonal SF on the same channel. The third proposed strategy is the balanced gateway selection algorithm. The proposed algorithm enhanced the existing one, SNR-based, to perform another attempt of transmitting the acknowledgment messages using the second-best gateway in terms of SNR. The procedure of forwarding the acknowledgment message to another gateway is assumed to be undertaken by the gateways after checking their duty cycle saturation.

The work in [25] has exploited the Wake-up Radio (WuR) technique to enhance downlink communication in LoRaWAN and achieve energy efficiency. An end device is fitted with two different communication modules. The first module is to handle LoRa and On-Off Keying (OOK) modulation. The former is used for long-range communication between end devices and gateways, whereas the latter is used for short-range communication among nodes within the same cluster. WuR is the second module that is always on and listens to the channel. The proposal is based on selecting a cluster head that forwards commands from a gateway to end devices in the same cluster. A cluster is composed of ten devices at most. However, the architecture assumed end devices to be fitted with energy harvesting devices such as a solar panel.

Occupancy-Balancing Downlink Transmission (OBDT) was proposed by [26] to enhance LoRaWAN scalability. OBDT first targets the reduction of downlink duration by decreasing the SF to a value lower than the default one. The purpose of using lower SF is to reduce time on air for downlink traffic. Hence, higher chances are available for end devices to transmit their uplink traffic. OBDT also analyses uplink traffic concentration to identify less receiving windows with minimum traffic. The downlink traffic timing is selected by the gateway based on the analysis. OBDT operates on the gateway nodes to avoid excessive power consumption at the end devices. However, decreasing SF results in higher power consumption.

A beacon mechanism alert similar to IEEE 802.11 Power Saving Mode (PSM) was utilized in [27] to support efficient LoRaWAN downlink communication. Gateways in the proposed system, TRILO, broadcast a periodic alert beacon to inform synchronized end devices of their pending downlink traffic. TRILO added a field in the LoRaWAN beacon frame to hold the backlogged end devices list similar to Traffic Indication Map (TIM) used in PSM. The proposed system opts for using a sequential polling mechanism by which end devices get their pending downlink traffic immediately when their addresses exist in the beacon frame. After receiving the downlink traffic, an end device goes to sleep mode. TRILO was implemented over available commercial devices. It was also evaluated using network simulation and compared to LoRaWAN class B.

Downlink Rate Optimization for class B (DROB) was proposed in [13] to enhance the efficiency of class B downlink operation. The proposed solution modified the existing ADR mechanism to serve downlink communication better. One of the modifications is to limit the maximum Data Rate (DR), one of the configuration parameters calculated in ADR, to DR3. The reason for avoiding higher DR, i.e., higher SF, is that with higher DR, there is a possibility of preventing communication from taking place due to changed timing parameters. Moreover, DROB also did not consider increasing power before changing DR. The proposed solution modified end devices to send the required information to calculate ADR via piggybacking regular uplink messages. Gateways also maintain a record of the packet loss ratio for each end device. Once the loss ratio for an end device reaches a predefined limit, the gateway notifies the end device of the DR for the following packets. DROB was simulated in scenarios that included other interference sources to make the simulated scenarios similar to an industrial plant.

The work in [28] proposed Cooperative Downlink Listening (CDL) to address the downlink issue in class A LoRaWAN. CDL partitioned the standard device address into the group address field and network id field to distinguish different applications and different sub-areas covered by a gateway. The process of assigning the new logical addresses is left to the network server. CDL used the RX2 window, which follows uplink data, to broadcast downlink traffic from a gateway to a particular sub-area. RX2 window is known for its flexibility to use a different channel and different data rates from those used by the initial uplink data. Therefore, the RX2 window configuration is set by the network server in CDL. CDL also defined one of the end devices as a downlink initiator. A downlink initiator is responsible for waking up all end devices to listen to the broadcast downlink. The system also proposed a procedure for circulating the role of the downlink initiator among end devices to balance power consumption.

No information has been provided by LoRaWAN specifications regarding which gateway should the network server choose to carry out the operation. However, a possible selection algorithm has been developed. It is currently used by the ChirpStack open-source LoRaWAN Network Server Stack [29], previously known as LoRaServer, and is widely used in the literature. The selection algorithm is based on the SNR value to consider the link quality with the assumption that the bidirectional channel offers the same conditions. The network server records the SNR values for each end device’s received packet along with the forwarding gateway. The gateway with the best SNR value to an end device is then selected to take the responsibility of transmitting the downlink traffic to the corresponding end device. The selection algorithm mainly depends on the SNR readings for the same duplicated packet that arrived through different gateways from a specific end device. Such a selection algorithm can be criticized that if a gateway is intensively used due to delivering traffic to the network server with the best SNR, the gateway itself becomes a bottleneck and overloaded with network server downlink traffic. Therefore, the network’s overall performance is compromised, including the uplink traffic. This results from using only the gateway with the best SNR value, and other gateways with lower SNR values are insufficiently used.

4  Proposed System

This paper proposes a Duty Cycle Gateway Selection (DCGS) algorithm to enhance downlink communication and confirmed-traffic efficiency for LoRaWAN applications. DCGS is proposed for LoRaWAN networks that contain several gateway devices. The system’s primary goal is to select the best available gateway that would be used to transmit the acknowledgment messages or downlink traffic to the desired destination.

Even though the channel quality is important, an overloaded gateway, without a doubt, will not be able to transmit the downlink traffic once it is in the time off period to comply with the duty cycle regulations. Consequently, the overloaded gateway soon reaches the duty cycle saturation leading to missing the RX windows for downloading traffic. Moreover, the uplink traffic will be missed as well, as the gateway either is busy transmitting downlink traffic or is in a duty cycle-off period resulting in a poor performance regarding uplink communication. Therefore, the duty cycle should be considered within the network server gateway selection algorithm to achieve better performance.

The proposed DCGS algorithm takes a gateway duty cycle into account in addition to the wireless link quality when selecting a gateway to transmit downlink traffic. The network server is instructed to keep track of the SNR values for received duplicated packets to guarantee channel quality is assured as with the SNR-based algorithm. However, the selection procedure mainly depends on the duty cycle as long as the selected gateway is one of the gateways that has relayed the message. Hence, it is one of the available gateways that provide a good connection to the targeted end device.

Regarding the duty cycle, each forwarded data message by a gateway is re-engineered to include information about the status of duty cycle timers. A MACPayload format for a LoRaWAN frame is presented in Fig. 2. The first part, FHDR, is a frame header and does not exceed 22 octets size in total. It can be used by gateways to pass information regarding the Time Off period ( Toff ) of a gateway due to the duty cycle regulation at an instant time. The last field in the frame header, Frame Options (FOpts), is used in LoRaWAN to hold the MAC command for a maximum of 15 bytes length. A portion of this field is used in the proposed system to pass ( Toff ) value from a gateway to the central network server, as shown in Fig. 3.

Figure 2: MACPayload structure

Figure 3: Frame header structure in the proposed system

Each uplink or downlink packet carries a PHY load that includes a MAC payload. The minimum overhead for a packet is twelve bytes, excluding the FOpts field in the frame header. Ten bytes for FOpts are assumed in the proposed system, one byte for ( Toff ), and the rest is for MAC commands. The overall overhead is twenty-two bytes. The time on-air for a downlink packet (Acknowledgement message) in the proposed system along with ( Toff ) are presented in Tab. 1 for all the SF. The EU868 frequency band is used with a 1% duty cycle restriction. The ( Toff ) is calculated using Eq. (1).

Toff=ToADC−ToA (1)

When a gateway receives a downlink packet and transmits it, it starts a duty cycle timer to keep track of its own time off. The gateway then attaches its duty cycle timer value to each received uplink packet that needs to be relayed toward the network server.

The network server keeps a record of SNR values and Toff period for received duplicated uplink messages which were generated initially by the same end device, arriving through different gateways. It then prepares the acknowledgment message, which must be delivered through one of the available gateways. It selects the gateway based on the stored Toff periods. The gateway with the minimum Toff value is selected. Figs. 4 and 5 present the pseudo-code and the flowchart respectively for the gateway selection procedure in the proposed system. The DCGS selection algorithm provides two features:

•   Assure channel quality between gateways and end devices where the chosen gateway is one of the gateways that provide an acceptable SNR value with the end device.

•   Avoid overloading one gateway with most of the downlink traffic where downlink traffic is distributed among gateways based on the Toff values.

Figure 4: pseudo-code for gateway selection in DCGS

Figure 5: DCGS mechanism

5  Performance Evaluation

5.1 Simulation Setup and Performance Metrics

The proposed system was evaluated using the Framework for LoRa (FLoRa) [30]. The performance of the proposed system was compared against the selection mechanism developed by ChirpStack [29] named as SNR-Based system. FLoRa is an open-source library for simulating LoRaWAN. It is built to operate within the well-known network simulator OMNeT++. FLoRa works in combination with the INET framework to provide implementations for all the components of LoRaWAN architecture, including end devices, gateways, and the network server. The combination of the frameworks provides models to support simulating all the underlying physical layer features, including path loss with shadowing, capture effect, and collisions.

The simulation parameters are provided in Tab. 2. End devices (100–500) were randomly distributed in the simulation area. They were simulated in a two-dimensional field of 2 km × 2 km size with four gateways which were placed around the four angles of the simulation area.

Regarding path loss and traffic propagation, the log-distance path loss is used in this study. It is calculated using Eq. (2). PathLossd0 is a reference value for path loss at zero distance, n represents the impact of distance on the data rate, xg is a Gaussian random parameter with zero mean, and g is the standard deviation. The PathLossd0 , d0 , g and n take 128.95 dB, 1000 m, 0 dB, and 2.32 values, respectively. These parameters were derived in real experiments in [31].

PathLos=PathLossd0+10nlog⁡(dd0)+xg (2)

Six performance metrics are considered in the simulation experiments to evaluate the performance of the proposed gateway selection algorithm. Using these metrics, the DCGS performance is also compared to the performance of the SNR-Based selection algorithm. These performance metrics include Packet Delivery Ratio (PDR), Power Consumption, Collision, Retransmission, Dropped Packets due to duty cycle, and the number of given-up packets.

•   PDR: It is the ratio of the overall acknowledged packets to the overall generated uplink packets by end devices. It reflects the overall performance of the deployed network over the whole operation time. As in Eq. (3), PDR is calculated as the division of total received acknowledgment messages by end devices TrcvAck by the total number of sent uplink messages by end devices TsntUpln .

PDR=TrcvAckTsntUpln (3)

•   Power Consumption: This is defined as the average consumed energy per end device over the whole simulation time. It is calculated as the total consumed power by all LoRaWAN devices ∑EDtp to the number of devices in the network EDs Eq. (4).

PowerConsumption=∑EDtpEDs (4)

•   Collision: Collision is defined as the total dropped packets at a gateway or all the gateways due to being disturbed by the reception process of other arriving packets. A collision happens when the same spreading factor, non-orthogonal is being used by two transmissions simultaneously.

•   Retransmission: It denotes the average number of retransmitting a packet that an end device requires until it receives the acknowledgment from the network server. It shows the impact of implementing a selection algorithm on the needed time to receive an acknowledgment. It is computed in Eq. (5) as the total for all average re-tries per end devices ∑EDsAverageretry (Average retry) to the number of end devices in the network EDs .

Retransmission=∑EDsAverageretryEDs (5)

•   Dropped Packets due to duty cycle: This metric shows the total number of dropped packet at a gateway or all the gateways due to duty cycle saturation. It is used to reflect how much the proposed system manages to decrease the number of dropped packets at gateways due to using a gateway selection mechanism based on a gateway duty cycle time off.

•   Given up: It is the number of packets that have been retransmitted up to the maximum number of retransmissions without receiving an acknowledgment message. The metric is calculated as the average per device for the whole network (Eq. (6)). It is the total number of all the given-up messages ∑EDsgiven−up by all end devices to the number of devices EDs in the network.

Given−up=∑EDsgiven−upEDs (6)

5.2 Result and Discussion

Fig. 6 presents the delivery ratio for both systems, DCGS and traditional SNR-based systems. Both approaches yield a good performance when the network size is small. However, as the networks increasingly become crowded, i.e., a large number of end devices, the discrepancy in the performance between the two systems becomes significant. In general, both system performance decreases as the number of end devices grows. However, the deterioration in the performance for the DCSG is limited compared to the SNR-based algorithm, where it manages to maintain delivering 90% of the traffic in the confirmed mode for 500 end device networks. This is due to the consideration of gateways’ duty cycle time off when the server selects the gateway through which acknowledgment message will be forwarded towards the targeted end device. The decline in the SNR-based system performance can be accounted for the used mechanism of selecting gateways through which the acknowledgment messages will be relayed. The selection mechanism forward loads of the downlink traffic to a gateway with the highest SNR value ignoring the other gateways that can do the task. Consequently, some of the gateways ended up exhausting their available time for transmission due to duty cycle restrictions. Thus, more retransmission of the uplink traffic is generated by originators and hence, escalating the issue.

Figure 6: Packet delivery ratio

The proposed selection algorithm increases the chance of delivering the acknowledgment messages without involving a high number of retransmissions, as shown in Fig. 7, confirming the advantages and the feasibility of the proposed algorithm. The delay in delivering the acknowledgment messages results in retransmitting the original uplink messages causing more traffic in the network. Thus, the overall performance is affected, and the possibility of collisions is increased.

Figure 7: Number of retransmissions for successfully acked packets

This was experienced in the carried-out evaluation where the average number of retransmissions for each successfully acknowledged single packet reaches almost two times in the SNR-Based system compared to 1.5 times for the proposed approach in a network with 500 end devices. Another reason that can be seen for the increased average of retransmissions for successfully acknowledged packets in SNR-based system is that with a high volume of traffic, a gateway is more likely to be busy whether receiving traffic from other end devices or transmitting traffic to them. This leads to failing to undertake reception procedure for other arriving packets, and therefore an end device ended up retransmitting the packet.

The good performance of the proposed system is also reflected in the number of messages that have been retransmitted up to the allowed retransmission times and considered failed as no acknowledgments were received. Fig. 8 shows the average number of packets per device that were retransmitted up to the maximum number as a function of the network size. It is almost reduced by half in the DCGS, particularly for networks consisting of 400 devices and more. The procedure of selecting a gateway based on the duty cycle saturation enhances the efficiency of the system as less number of packets per device are experienced to reach the limit of retransmissions. Two factors can be seen as the causes for such retransmissions. The first is the inability of the selection algorithm to select the most appropriate gateway to relay the acknowledgment message to the corresponding device. A chosen gateway may have already exhausted its permitted transmission due to duty cycle limitations. Consequently, retransmission is invoked by the original generator of the message resulting in a higher number of retransmissions up to the maximum for a packet. The second reason that can be seen is that the original uplink message may be considered lost when arriving at a busy gateway, transmitting downlink traffic due to half-duplex mode operation.

Figure 8: Number of given up due to reaching maximum retransmissions

Another considered performance metric in this evaluation is energy consumption. It is seen important to investigate the power consumption to determine if the achieved success ratio in the proposed algorithm enhances the system’s efficiency in terms of power consumption. The result for both systems is plotted in Fig. 9. The difference in performance between the two systems is insignificant with small network sizes. However, when the network size increases, the gap increases notably. The main reason for such a decrease in power consumption is the ability of the proposed algorithm to satisfy uplink messages with acknowledgments before carrying out multiple retransmission procedures. Hence, fewer uplink messages are generated by an end device, i.e., fewer retransmissions, which contributes to keeping the average energy consumption per device at the lowest level. This can be observed from the figure where the proposed system is more effective in power conservation than the SNR-based approach, especially with a more extensive network size. It maintains 50% savings for each single end device.

Figure 9: Average power consumption per device in joule

The number of collisions that occur in the networks for different network capacities is depicted in Fig. 10. It can be seen that the number of collisions in the network for the proposed system is lower than those of the SNR-Based system. The differences are observed clearly for networks consisting of 300 end devices and more. The superior performance is owing to the capability of the proposed system to efficiently deliver acknowledgments to the original messages. Hence, the need for retransmissions of uplink traffic by end devices is avoided or kept at a minimum, leading to lower traffic released in the network. Thus, the probability of traffic collisions at gateways is highly reduced in the proposed system. In contrast, the selection for a gateway based on the SNR does not succeed in delivering the acknowledgments, leading to a higher number of retransmissions of uplink traffic by the end devices, as seen in Figs. 7 and 8. Consequently, higher traffic is released into the network, increasing the probability of collisions.

Figure 10: Total collisions at gateways

The total number of dropped packets at all four gateways due to the duty cycle saturation for both systems is presented in Fig. 11. The figure shows a similar trend to the collisions as in Fig. 10. However, the lost packets because of the duty cycle saturation are remarkably high compared to the lost traffic due to collisions. It justifies the critical role that a gateway duty cycle limitation plays in the overall performance of downlink-supported networks. As shown in Fig. 11, the best performance is achieved with the proposed algorithms. The selection of the gateways based on the duty cycle time off leads to directing downlink traffic (acknowledgments) by the network server to less-congested gateways, i.e., gateways with a minimum value of T off. Therefore, fewer packets in the DCGS are susceptible to being dropped than the SNR-based system because of the duty cycle threshold. In particular, DCGS manages to save almost 50%, in the scenarios with 200 and more end devices, of the acknowledgment traffic from being destroyed due to the duty cycle.

Figure 11: Number of dropped packets due to duty cycle saturation

To justify the advantages for the DCGS over the SNR-based selection algorithm, Fig. 12 plots the distribution of dropped traffic due to duty cycle saturation over the used gateways for both systems in scenarios consisting of 300 end devices. It can be seen that most of the downlink dropped traffic for the SNR-based algorithm is dropped at two gateways; gateways 1 and 3. These gateways have been selected because they provide good SNR value for most end devices. This, however, is the main reason for the degraded performance in the SNR-based system since the selection of particular gateways repeatedly results in exhausting the duty cycle limitation. The figure also shows the uniform spread of the downlink dropped traffic over three of the available gateways for the DCGS. It is clear that choosing the gateway based on the duty cycle threshold enhances the fair distribution of traffic, which eventually increases the overall efficiency of the system. One thing to note is that the fourth gateway is observed to drop the least amount of traffic in both systems. This can be justified for its coverage since both systems select only gateways that provide good SNR to destinations.

Figure 12: Distribution of dropped packets due to duty cycle per gateway for 300 end devices network

6  Conclusion

LoRaWAN is considered one of the most promising technology for long-range and low-power communication in the LPWAN field. The work in this paper has focused on the downlink communication side for such technology to enhance LoRaWAN quality of services. The paper shows that Implementing reliability through acknowledging uplink traffic using downlink techniques, provided in the current LoRaWAN, makes downlink traffic susceptible to loss. This is mainly due to the duty cycle saturation at LoRaWAN gateways because of the implemented gateway selection algorithm. The current selection is based on the SNR values between the gateways and the target devices.

This research proposes an efficient gateway selection algorithm that realizes communication reliability by optimizing gateways’ duty cycle time off values when selecting a gateway by the network server. The proposed system is named DCGS. It improves the efficiency of the overall LoRaWAN network, where it manages to deliver a higher amount of downlink traffic to end devices. The proposed system is implemented in a network simulator, using FLoRa, and INET frameworks on OMNeT++. Its performance is evaluated and compared to the performance of the legacy one. Results show that DCGS succeeded in reducing the amount of lost downlink traffic at LoRaWAN gateways and, therefore, increasing the efficiency of the network. It achieves a better packet delivery ratio with a lower number of retransmissions. The proposed system can be applied to various IoT applications to provide reliable data transfer.

Funding Statement: The author would like to thank the Deanship of Scientific Research at Umm Al-Qura University for supporting this work by Grant Code: (22UQU4331076DSR01).

Conflicts of Interest: The author declares that he has no conflicts of interest to report regarding the present study.

References

 1.  Ericson, Ericsson Mobility Report, 2021. [Online]. Available: https://www.ericsson.com/en/reports-and-papers/mobility-report/reports/november-2021. (Accessed: 27-April-2022). [Google Scholar]

 2.  S. Farrell, “Low-power wide area network (LPWAN) overview,” Internet Engineering Task Force, vol. rfc8376, pp. 1–43, 2018. [Google Scholar]

 3.  U. Raza, P. Kulkarni, M. Sooriyabandara and S. Member, “Low power wide area networks: An overview,” IEEE Communications Surveys & Tutorials, vol. 19, no. 2, pp. 855–873, 2017. [Google Scholar]

 4.  M. Al Mojamed, “On the use of LoRaWAN for mobile Internet of Things: The impact of mobility,” Applied System Innovation, vol. 5, no. 5, 1–12, 2022. [Google Scholar]

 5.  R. Marini, W. Cerroni and C. Buratti, “A novel collision-aware adaptive data rate algorithm for LoRaWAN networks,” IEEE Internet of Things Journal, vol. 8, no. 4, pp. 2670–2680, 2021. [Google Scholar]

 6.  LoRa Alliance, [Online]. Available: https://lora-alliance.org/. (Accessed: 28-May-2022). [Google Scholar]

 7.  Semtech, What Is LoRa, 2022. [Online]. Available: https://www.semtech.com/lora/what-is-lora. (Accessed: 25-May-2022). [Google Scholar]

 8.  The Things Network, 2022. [Online]. Available: https://www.thethingsnetwork.org/docs/lorawan/frequencies-by-country.html. (Accessed: 30-May-2022). [Google Scholar]

 9.  Communication and Information Technology Commission, 2021. [Online]. Available: https://www.citc.gov.sa/en/Pages/default.aspx. (Accessed: 19-Jan-2021). [Google Scholar]

10. M. Al Mojamed, “Smart mina: Lorawan technology for smart fire detection application for hajj pilgrimage,” Computer Systems Science and Engineering, vol. 40, no. 1, pp. 259–272, 2022. [Google Scholar]

11. A. Lombardo, S. Parrino, G. Peruzzi and A. Pozzebon, “LoRaWAN vs NB-IoT: Transmission performance analysis within critical environments,” IEEE Internet of Things Journal, vol. 14, no. 8, 1068–1081, 2021. [Google Scholar]

12. J. M. Marais, A. M. Abu-Mahfouz, G. P. Hancke, “A survey on the viability of confirmed traffic in a LoRaWAN,” IEEE Access, vol. 8, pp. 9296–9311, 2020. [Google Scholar]

13. D. Todoli-ferrandis, J. Silvestre-blanes and V. Sempere-payá, “Robust downlink mechanism for industrial Internet of Things using lorawan networks,” Electronics, vol. 10, no. 2122, 1–17, 2021. [Google Scholar]

14. A. Farhad, D. H. Kim, J. S. Yoon and J. Y. Pyun, “Feasibility study of the LoRaWAN blind adaptive data rate,” in Proc. ICUFN, Jeju Island, Korea, pp. 67–69, 2021. [Google Scholar]

15. V. Di Vincenzo, M. Heusse and B. Tourancheau, “Improving downlink scalability in LoRaWAN,” in ICC, Shanghai, China, pp. 1–7, 2019. [Google Scholar]

16. LoRa Alliance, LoRaWAN® L2 1.0.4 Specification, 2020. [Online]. Available: https://lora-alliance.org/resource_hub/lorawan-104-specification-package/. [Google Scholar]

17. C. Charilaou, S. Lavdas, A. Khalifeh, V. Vassiliou and Z. Zinonos, “Firmware update using multiple gateways in lorawan networks,” Sensors, vol. 21, no. 19, pp. 1–19, 2021. [Google Scholar]

18. LoRa Alliance, FUOTA process summary technical recommendation TR002 v1.0.0, 2019. [Online]. Available: https://lora-alliance.org/resource_hub/fuota-process-summary-technical-recommendation-tr002-v1-0-0/. [Google Scholar]

19. A. I. Pop, U. Raza, P. Kulkarni and M. Sooriyabandara, “Does bidirectional traffic do more harm than good in LoRaWAN based LPWA networks?,” in GLOBECOM, Singapore, pp. 1–6, 2017. [Google Scholar]

20. M. Capuzzo, D. Magrin and A. Zanella, “Confirmed traffic in LoRaWAN: Pitfalls and countermeasures,” in Med-Hoc-Net, Capri, Italy, pp. 1–7, 2018. [Google Scholar]

21. F. Van Den Abeele, J. Haxhibeqiri, I. Moerman, J. Hoebeke, “Scalability analysis of large-scale LoRaWAN networks in ns-3,” IEEE Internet of Things Journal, vol. 4, no. 6, pp. 2186–2198, 2017. [Google Scholar]

22. S. Abboud, N. El Rachkidy, A. Guitton and H. Safa, “Gateway selection for downlink communication in LoRaWAN,” in WCNC, Marrakesh, Morocco, pp. 1–6, 2019. [Google Scholar]

23. G. Yapar, T. Tugcu and O. Ermis, “Time-slotted ALOHA-based LoRaWAN scheduling with aggregated acknowledgement approach,” in FRUCT, Helsinki, Finland, pp. 383–390, 2019. [Google Scholar]

24. Y. Hasegawa and K. Suzuki, “A multi-user ACK-aggregation method for large-scale reliable LoRaWAN service,” in ICC, Shanghai, China, pp. 1–7, 2019. [Google Scholar]

25. N. Djidi, M. Gautier, A. Courtay, O. Berder and M. Magno, “How can wake-up radio reduce lora downlink latency for energy harvesting sensor nodes?,” Sensors, vol. 21, no. 3, pp. 1–16, 2021. [Google Scholar]

26. C. Kim, J. Kim, J. Kwak, K. Kim and W. Seok, “Occupancy-balancing downlink transmission for enhancing scalability of LoRa networks,” International Journal of Distributed Sensor Networks, vol. 16, no. 12, pp. 155014772097927, 2020. [Google Scholar]

27. Y. Oh, J. Lee and C. K. Kim, “TRILO: A traffic indication-based downlink communication protocol for LoRaWAN,” Wireless Communications and Mobile Computing, vol. 2018, pp. 1–14, 2018. [Google Scholar]

28. B. Kim and K. Il Hwang, “Cooperative downlink listening for low-power long-range wide-area network,” Sustainability, vol. 9, no. 4, pp. 627, 2017. [Google Scholar]

29. ChirpStack, Open-source LoRaWAN® network server stack, [Online]. Available: https://www.chirpstack.io/. (Accessed: 04-March-2022). [Google Scholar]

30. M. Slabicki, G. Premsankar and M. Di Francesco, “Adaptive configuration of LoRa networks for dense IoT deployments,” in IEEE/IFIP NOMS, Taipei, Taiwan, pp. 1–9, 2018. [Google Scholar]

31. J. Petäjäjärvi, K. Mikhaylov, A. Roivainen, T. Hänninen and M. Pettissalo, “On the coverageof LPWANs: Range evaluation and channel attenuation model for LoRa technology,” in ITST, Copenhagen, Denmark, pp. 55–59, 2015. [Google Scholar]