Source-linked AI summary
Does Bidirectional Traffic Do More Harm Than Good in LoRaWAN Based LPWA Networks?
Alexandru-Ioan Pop, Usman Raza, Parag Kulkarni, Mahesh Sooriyabandara
TL;DR
The paper addresses limited evidence about realistic LoRaWAN performance and the lack of simulators supporting bidirectional MAC behavior. It presents LoRaWANSim and finds that downlink traffic and retransmissions can substantially impair network performance, with design trade-offs between energy and reliability.
Problem
Realistic LoRaWAN performance analysis is limited because existing simulators primarily support uplink-only traffic, despite downlink being required by LoRaWAN operation and applications.
Method
The paper presents LoRaWANSim, a discrete-event simulator extending LoRaSim with LoRaWAN MAC features, bidirectional traffic, retransmissions, and duty-cycle modeling.
Results
Downlink traffic and retransmission attempts reduce LoRaWAN throughput and reliability, while gateways can become overloaded by downlink traffic and ACK requests.
Takeaways & Limitations
Network size, retransmission settings, and energy-versus-reliability trade-offs should be evaluated with what-if analyses before deployment.
Takeaways & Limitations
The simulations enforce the 1% duty-cycle rule used in most European sub-bands, including a 99x time-on-air separation between consecutive transmissions.
Abstract
from arXiv · showhide
The need for low power, long range and low cost connectivity to meet the requirements of IoT applications has led to the emergence of Low Power Wide Area (LPWA) networking technologies. The promise of these technologies to wirelessly connect massive numbers of geographically dispersed devices at a low cost continues to attract a great deal of attention in the academic and commercial communities. Several rollouts are already underway even though the performance of these technologies is yet to be fully understood. In light of these developments, tools to carry out `what-if analyses' and pre-deployment studies are needed to understand the implications of choices that are made at design time. While there are several promising technologies in the LPWA space, this paper specifically focuses on the LoRa/LoRaWAN technology. In particular, we present LoRaWANSim, a simulator which extends the LoRaSim tool to add support for the LoRaWAN MAC protocol, which employs bidirectional communication. This is a salient feature not available in any other LoRa simulator. Subsequently, we provide vital insights into the performance of LoRaWAN based networks through extensive simulations. In particular, we show that the achievable network capacity reported in earlier studies is quite optimistic. The introduction of downlink traffic can have a significant impact on the uplink throughput. The number of transmit attempts recommended in the LoRaWAN specification may not always be the best choice. We also highlight the energy consumption versus reliability trade-offs associated with the choice of number of retransmission attempts.
I. INTRODUCTION
The paper addresses the need for realistic LoRaWAN analysis by presenting LoRaWANSim, which adds bidirectional MAC behavior to simulation. It uses the simulator to examine scalability, downlink effects, and retransmission trade-offs.
- LPWA technologies target massive, geographically dispersed IoT deployments requiring low cost, long range, and multiyear battery operation.
- Existing LoRa simulators lacked comprehensive support for bidirectional LoRaWAN traffic, limiting analysis of downlink-dependent behavior.
- LoRaWANSim extends LoRaSim with LoRaWAN MAC features including downlink traffic, acknowledgments, retransmissions, and data-rate adaptation under duty-cycle constraints.
- The study evaluates LoRaWAN scalability when dominant uplink traffic is accompanied by fractional downlink traffic.
- Downlink traffic and retransmission attempts reduce throughput and reliability, motivating careful choices of network size and MAC parameters.
II. AN OVERVIEW OF LORA AND LORAWAN
This section introduces LoRa as the physical layer underlying the LoRaWAN LPWA stack. It emphasizes how physical-layer parameters trade range, data rate, reliability, and airtime.
- LoRa is a proprietary physical layer using Chirp Spread Spectrum modulation to provide large link budget and processing gain.
- Higher spreading factors increase energy per bit and range but also increase time on air and reduce effective data rate.
- Bandwidth, spreading factor, and coding rate jointly determine LoRa range, energy consumption, data rate, and reliability.
B. LoRaWAN
LoRaWAN is an open MAC and networking standard built on LoRa, operating over regulated unlicensed spectrum. Its limited MAC support in earlier tools motivates LoRaWANSim's added bidirectional features.
- LoRaWAN connects end devices to gateways and backend servers over regional unlicensed Sub-GHz ISM bands.
- Its ALOHA-based access and typical 1% duty-cycle restriction constrain transmissions and communication-parameter choices in Europe.
- Class A devices receive downlink only after uplink transmission, whereas Class B receives scheduled traffic and Class C listens continuously.
- Earlier models and simulators did not capture the interaction between downlink traffic, gateway duty cycle, and MAC settings affecting reliability.
- LoRaWANSim adds downlink traffic, control messages, acknowledgments, and retransmissions to support more complete LoRaWAN MAC analysis.
B. Performance of LoRa and LoRaWAN
The paper extends LoRaSim to model LoRaWAN downlink and retransmission behavior, including Class A reception windows. This enables performance analysis beyond uplink-only LoRa simulation.
- LoRaWANSim extends LoRaSim with LoRaWAN MAC support for downlink data, ACK messages, and end-device retransmissions.
- A. LoRaSim: LoRaSim places gateways and devices in a two-dimensional space and models periodic uplink traffic with configurable radio parameters.
- A. LoRaSim: LoRaSim accounts for path loss, fading, collisions, and receiver sensitivity when determining uplink packet reception.
- Class A devices open RX1 and RX2 after transmission to receive an ACK or other downlink traffic.
B. LoRaWANSim: Additional MAC Features
LoRaWANSim adds bidirectional MAC features needed to model downlink exchanges, acknowledgments, retransmissions, and regulatory duty-cycle behavior.
- B. LoRaWANSim: Additional MAC Features: LoRaWANSim supports bidirectional communication by adding downlink traffic to an existing uplink-focused simulator.The extension addresses LoRaWAN MAC behavior that depends on downlink exchanges.
- B. LoRaWANSim: Additional MAC Features: Class A devices transmit uplink data and then open up to two reception windows for gateway acknowledgments or downlink data.The windows are RX1 and RX2, and acknowledgments may be piggybacked on downlink data.
- B. LoRaWANSim: Additional MAC Features: LoRaWANSim allows RX2 frequency, spreading factor, and bandwidth settings to be configured per end device.RX1 normally uses the preceding uplink frequency, while European RX2 defaults are specified by the protocol.
- B. LoRaWANSim: Additional MAC Features: The simulator enforces a minimum 99x time-on-air separation between consecutive transmissions to respect the 1% duty cycle.The restriction applies to gateways and end devices, including ACK transmissions.
- B. LoRaWANSim: Additional MAC Features: Downlink messages serve multiple LoRaWAN functions, as summarized in the table of bidirectional exchanges and handshakes.The table is presented as evidence of both the importance and variety of downlink functions.
3) Uplink/downlink collision model:
The collision model separates overlapping gateway and end-device transmissions, while duty-cycle limits can prevent ACK delivery and trigger retransmissions.
- 3) Uplink/downlink collision model:: LoRaWANSim models overlapping uplink and downlink transmissions as non-colliding because gateway I/Q inversion separates their reception directions.Only end devices hear the gateway and vice versa under this model.
- 3) Uplink/downlink collision model:: Duty-cycle regulations are identified as the most common cause of lost downlink packets because they restrict gateway transmissions.Collisions and lost confirmed packets are additional reasons an ACK may not reach an end device.
- 3) Uplink/downlink collision model:: The LoRaWAN specification recommends up to 8 transmissions when acknowledgments are not received.After eight consecutive failed attempts, the application should be notified.
- 3) Uplink/downlink collision model:: LoRaWANSim supports either retaining the original data rate or reducing it after unsuccessful attempts, while this study retains the original rate.The specification recommends reducing the data rate every two unsuccessful transmission attempts.
V. LORAWAN IN ACTION: PERFORMANCE UNDER BIDIRECTIONAL TRAFFIC
The study evaluates LoRaWAN under uplink traffic combined with downlink data and acknowledgments, focusing on capacity, retransmissions, delivery, energy, and ACK demand.
- V. LORAWAN IN ACTION: PERFORMANCE UNDER BIDIRECTIONAL TRAFFIC: LoRaWANSim compares system performance when downlink data and ACKs are added to the uplink traffic scenarios used in earlier work.The scenarios are designed to examine bidirectional traffic rather than uplink-only operation.
- V. LORAWAN IN ACTION: PERFORMANCE UNDER BIDIRECTIONAL TRAFFIC: The study asks how downlink traffic affects network capacity and whether the specification’s 8-attempt retransmission recommendation is necessary.These questions directly frame the performance investigation.
- V. LORAWAN IN ACTION: PERFORMANCE UNDER BIDIRECTIONAL TRAFFIC: The study examines retransmission-count trade-offs between energy cost and achieving a desired percentage of packet delivery.The analysis varies network size and traffic volume to inform application-design choices.
- V. LORAWAN IN ACTION: PERFORMANCE UNDER BIDIRECTIONAL TRAFFIC: The study evaluates how increasing the percentage of uplink traffic requiring ACKs affects network performance and energy consumption.Multiple configurations are considered for ACK demand and downlink traffic.
- V. LORAWAN IN ACTION: PERFORMANCE UNDER BIDIRECTIONAL TRAFFIC: The scenarios separately examine downlink data without ACKs, ACK-only downlink with up to 8 attempts, and a combination of both.The first scenario has no retransmissions, whereas the ACK scenario retransmits when acknowledgments are absent.
A. Simulation Setup and Performance Metrics
The simulations vary network size and node data rates in a European LoRaWAN topology, using repeated long-duration runs and goodput as the performance metric.
- A. Simulation Setup and Performance Metrics: The topology uses one gateway with 100 to 5000 randomly distributed nodes, whose distances produce different supported data rates.Nodes closer to the gateway can use higher data rates than farther nodes.
- A. Simulation Setup and Performance Metrics: Figure 2 examines how network size affects downlink reliability.The figure focuses on downlink reliability rather than uplink goodput.
- A. Simulation Setup and Performance Metrics: Figure 3 examines how bidirectional traffic affects network goodput.Its focus complements the downlink-reliability analysis by measuring network-level throughput.
- A. Simulation Setup and Performance Metrics: Each simulation runs for 57 days and is repeated 15 times, with results reported as averages.Standard deviations are omitted because they are too small to be visible in the plots.
- A. Simulation Setup and Performance Metrics: Goodput is defined as successfully received non-retransmitted packets divided by all sent packets, including retransmissions.This metric captures delivery performance while accounting for retransmission traffic.
B. Findings from this study
Bidirectional LoRaWAN traffic and retransmissions reduce reliability and goodput, especially as networks grow. Gateway duty-cycle limits make ACK delivery unreliable, while retransmission choices create energy–performance trade-offs.
- Gateway duty-cycle limitations and collisions make LoRaWAN downlink transmissions unreliable, particularly in larger networks.The gateway often cannot transmit downlink frames when regulatory airtime is exhausted.
- Retransmissions cause a large drop in network goodput, with the reduction becoming more pronounced for larger networks.Downlink data can compete with ACKs, causing ACK losses that trigger additional retransmissions.
- Lack of an ACK may reflect gateway duty-cycle exhaustion rather than poor link quality, making lower-data-rate adaptation potentially counterproductive.Lower data rates increase gateway airtime for ACKs and can further exacerbate the problem.
- The recommended retransmission count is scenario-dependent: small networks gain little after early attempts, whereas 5000-node networks improve substantially through eight attempts.For networks below 600 nodes, 90% of messages are acknowledged on the first attempt; for 5000 nodes, about 85% succeed after eight attempts.
- When ACK success improves only marginally, avoiding retransmissions may be the better strategy.This recommendation follows the observed trade-off between retransmission cost and acknowledged-packet improvement.
- Increasing retransmissions in large networks raises battery drain while reducing network goodput.The combined effects of gateway duty-cycle limits and increased contention drive more collisions.
- With 100% of packets requesting ACKs, the network operates at barely 15% of the capacity achieved without ACK requests.Increasing the ACK-request percentage severely degrades performance because the gateway frequently runs out of transmit opportunities.
VI. SUMMARY & DISCUSSION
The study finds that downlink traffic, gateway bottlenecks, and retransmission choices materially constrain LoRaWAN performance. LoRaWANSim supports predeployment what-if analysis of these trade-offs.
- Earlier reported LoRaWAN capacity is optimistic when bidirectional traffic and retransmissions are considered.
- Downlink traffic significantly reduces goodput, including when only a small proportion of traffic requests acknowledgments.This reduction affects both the number of devices a network can support and the applications for which LoRaWAN is suitable.
- Gateway capacity should be planned carefully because traffic scale and duty-cycle limits can create bottlenecks.
- Eight transmission attempts may not suit every scenario; designers should balance network scale, energy consumption, packet delivery, and application requirements.
- LoRaWANSim can support predeployment what-if analyses of network and MAC-layer design choices.
VII. CONCLUSION
LoRaWANSim models the LoRa physical layer and LoRaWAN MAC layer to examine bidirectional communication, duty-cycle limits, scalability, reliability, and energy consumption. The study finds that downlink traffic can overload gateways and that many acknowledgment requests reduce scalability.
- LoRaWANSim studies a complete network stack comprising the LoRa physical layer and LoRaWAN MAC layer.
- Duty-cycle-limited LoRaWAN gateways are easily overloaded by downlink traffic.
- LoRaWAN networks do not scale well when many end devices request acknowledgments.
- The simulator reveals trade-offs involving network scalability, reliability, and energy consumption.