Whitepapers

8 Why lightweight downlinks/confirmed mode matters Improves Network Capacity: stops unnecessary retransmissions early, freeing up airtime for other devices. Reduces Battery Consumption: Avoids unnecessary RF transmissions, which are energy- expensive. Firmware-Friendly: Requires no changes on the device side; only server-side logic must be adapted. Design consideration for high SF devices This mechanism is especially valuable for high SF (SF11–12) devices, where airtime per transmission is long and NbTrans ≥ 3 can cause seconds of channel usage. A single lightweight downlink can interrupt this loop, saving both airtime and device energy. Implementation guidance for network servers To enable uplink self-termination and improve overall transmission efficiency, LoRaWAN network servers (LNS) should implement the following: Minimize downlink overhead: Use the smallest valid downlink format (e.g., no payload) to preserve airtime and battery. Schedule lightweight downlink responses (e.g., empty FRMPayload with valid MIC or FOpts-only MAC commands) during the RX1 or RX2 window after a successfully received uplink. These responses will interrupt the NbTrans loop, even if no application-layer ACK is needed. Ensure downlink timing compliance with LoRaWAN Class A specifications, so the device recognizes the downlink as valid. Use PER-based optimization: Monitor Packet Error Rate over a sliding window and send ADR command when necessary, i.e., when PER exceeds acceptable thresholds. Support high SF scenarios: Prioritize this strategy for high-Spreading Factor devices (e.g., SF11–12) where long airtimes and high NbTrans values can cause heavy congestion. A single downlink empty message can prevent multiple seconds of unnecessary airtime. 3. Spreading Factor and Airtime Optimization Optimizing Spreading Factor (SF) allocation is one of the most critical aspects of operating a LoRaWAN network. A careful use of spreading factors can reduce airtime consumption, increase system throughput, and ensure fair resource distribution across all devices. LoRa Alliance ® WHITEPAPER

• LoRaWAN® Network Capacity Optimization for Utility Applications
• Contributing Authors
• Olivier Seller, Semtech
• Rémi Demerlé, Semtech
• Miguel Luis, Semtech
• Ahmed Kasttet, Birdz
• Jarod Gillespie, Connexin
• Jonas Prapuolenis, Mainlink
• Clint Guillory, Sync Automation
• Martin Heusse, University of Grenoble Alpes
• Johan Stokking, The Things Industries B.V.
• Yaser Abdallah, Diehl Metering SAS
• Thomas Kauppert, Diehl Metering SAS
• Jason Kung, Browan Communications
• Lorenzo Vangelista, Wireless and More
• WHITEPAPER
• Executive Summary As the demand for reliable, scalable, and efficient smart metering infrastructure grows, utility providers are increasingly adopting LoRaWAN for its long-range, low-power communication capabilities, high sensitivity and robustness to
• This white paper, developed by the LoRa Alliance Network Capacity Task Force, presents three tracks of best practices:
• network deployment optimization: layers of gateways, macro-diversity, relays in dedicated spots,
• airtime optimization: balanced use of unconfirmed/confirmed uplink messages, lightweight acknowledgement, optimal use of higher spreading factors, device behaviour optimization.
• Implemented jointly by stakeholders, these best practices will optimize network capacity and improve device performance.
• Introduction LoRaWAN has emerged as a preferred LPWAN technology for utility companies seeking to deploy scalable smart metering infrastructure. Its cost-effectiveness, adaptability to various terrain and environments, and minimal energy consumption i
• All connectivity providers could face capacity and performance issues across high-density, urban, and deep-indoor environments. The hardest use case is typically the deep underground case of a water meter in a pit and below iron cover, as seen in many Eur
• WHITEPAPER
• The Problem Connectivity providers deploying LoRaWAN networks face a range of challenges that directly impact capacity and reliability:
• Environmental Constraints: Meters are often installed in difficult locations such as deep underground in pits under iron cover (like water meter), or indoor in basements in metal enclosures (like energy meter) or directly in apartments.
• Gateway Density: Sparse gateway installations result in weak coverage, leading to packet loss, and the need for retransmissions.
• Spreading Factor (SF) Distribution: Sub-optimal use of high SFs like SF11 and SF12 leads to network congestion.
• Transmission Volume and Device Density: Urban areas with a high density of end devices often experience collisions and data bottlenecks.
• Infrastructure Variation: The use of 8-channel versus 16-64 channel gateways, as well as indoor versus outdoor setups, significantly affects performance.
• Impact: These issues can lead to missed readings, SLA violations, and customer dissatisfaction, especially in high-demand utility scenarios.
• Proposed Solutions Optimizing LoRaWAN network capacity in utility metering demands a layered approach that blends architectural foresight, intelligent transmission control, and firmware-level adaptability. The Network Capacity Task Force recommends t
• 1. Gateway Deployment and Network Topology Design The way gateways are deployed directly shapes the capacity, reliability, and performance of a LoRaWAN network. A one-size-fits-all approach is not effective—deployment must reflect the physical environ
• Outdoor 16-64 channel gateways 16-64 channel gateways should form the backbone of city-wide deployments. With higher channel capacity and longer-range connectivity, benefiting from favourable propagation conditions, they are best suited for supporting
• WHITEPAPER
• Channel diversity allows these gateways to absorb high spreading factor (SF) traffic without reaching saturation, preventing congestion in dense deployments.
• Wide-area coverage reduces the number of gateways required for baseline service, making them the most cost-efficient choice for large footprints.
• Opportunistic placement of 16-64 channel gateways limits the need for coverage extension.
• In short, 16-64 channel gateways are the "heavy lifters" that establish broad and resilient coverage across the city.
• Outdoor 8-channel gateways 16-64 channel gateway coverage alone is often insufficient in high-density or challenging environments. Outdoor 8-channel gateways fill this gap by reinforcing coverage in targeted areas such as neighborhoods, industrial si
• They provide localized reinforcement, ensuring reliable connectivity where 16-64 channel gateway signals may be weak or overloaded.
• Their lower cost and simpler deployment (compared to cellular IoT) make them attractive for incremental scaling without committing to the expense of full-capacity gateways.
• By offloading local traffic, they prevent 16-64 channel gateways from becoming bottlenecks, improving overall airtime efficiency.
• Outdoor 8-channel gateways are an effective way to balance capacity and cost in a layered approach.
• Indoor 8-channel gateways Certain environments—such as basements, multi-dwelling units, or dense industrial buildings—block or severely attenuate radio signals from outdoor gateways. Indoor gateways are essential to bridge this coverage gap.
• They provide building-wide and basement-level coverage, ensuring meters or sensors buried deep inside structures can reliably connect.
• In residential and industrial deployments, they deliver last-meter reliability, overcoming penetration issues that outdoor infrastructure cannot solve.
• Their localized footprint ensures that indoor devices can use lower spreading factors, minimizing airtime and preserving their battery life.
• Indoor gateways are therefore critical for ensuring service quality in environments where outdoor penetration is limited.
• WHITEPAPER
• Additional considerations:
• Macro-diversity planning To ensure high delivery success rates and resilience to fading or interference, macro-diversity is recommended, i.e. it is recommended that each uplink be received by at least two gateways—regardless of is it indoor or outdoor
• In large-scale deployments, macro-diversity becomes crucial when aiming for higher network capacity. For small to mid-sized deployments, two-gateway coverage might only be planned for ~30% of devices, or even less, depending on density. In many typical de
• Careful assessment is needed to determine when the benefits of macro-diversity outweigh the additional infrastructure costs.
• RF modeling and site surveys Propagation modeling should be used to predict coverage and blind spot locations—especially in challenging locations like pits under iron lids (common for water meters) or deep indoor areas (as with smart electricity meter
• LoRaWAN relay When one device, or a small group of devices are not covered, deploying battery-operated LoRaWAN relays is a cost-effective solution. Since the relay is battery-operated, installation is greatly simplified, especially in some locations w
• WHITEPAPER
• Scalable growth path A well-designed LoRaWAN network is inherently scalable. Modular growth—by adding indoor or outdoor gateways based on traffic load or coverage challenges—allows for cost-effective expansion over time. Compared to cellular IoT, LoRa
• 2. Transmission Efficiency and Network Server Behavior Efficient use of the LoRaWAN air interface is a prerequisite for scaling deployments to thousands or even millions of devices. Since every uplink consumes valuable airtime, network servers must in
• On an Aloha channel, where transmissions are random, diversity is key: it is a well-established fact that more than 3 retransmissions are needed when the objective is to operate the network at a load that is of the same order of magnitude as the load for
• Confirmed vs. unconfirmed uplinks tradeoff Not all devices benefit from the same transmission strategy. The network must weigh reliability needs against airtime consumption when choosing between confirmed and unconfirmed uplinks:
• Battery-critical endpoints (such as water meters in underground pits) often operate in poor RF conditions. For these devices, confirmed uplinks with moderate NbTrans (8) are recommended. This ensures critical readings are not lost, while still limiting re
• High-frequency reporters (such as electricity meters) generate frequent data transmissions. For them, unconfirmed mode with optimized retransmission is more efficient (NbTrans (3). Occasional packet loss is acceptable because subsequent transmissions can
• By tailoring the confirmation strategy to the use case, a network operator maximizes both its network efficiency and the device longevity.
• WHITEPAPER
• Confirmed uplink vs. lightweight downlink responses In LoRaWAN networks, an efficient management of uplink retransmissions is key to balancing network capacity, energy efficiency, and delivery reliability. In this perspective, two approaches can be us
• confirmed uplinks, where the device asks for an explicit acknowledgment (ACK) from the network,
• lightweight downlink responses, where the network sends a downlink (e.g., with empty FRMPayload and valid MIC) to terminate the retransmission of uplink messages in unconfirmed mode.
• While both methods effectively break the NbTrans loop, lightweight downlinks shift control to the network server, which can optimize delivery timing and content based on global network conditions. This is particularly useful in ADR (Adaptive Data Rate) sc
• To further refine this strategy, the network server can monitor Packet Error Rate (PER) over a sliding window and issue lightweight downlinks only when truly needed—such as when PER exceeds a defined threshold. This selective intervention conserves downli
• Note: the downlink frame size is the same whether it carries an ACK or a lightweight response, and both approaches are non-intrusive to end-device firmware—they comply fully with the LoRaWAN specification.
• PER-based adaptive data rate (ADR) In presence of lightweight downlinks/Confirmed mode: For a target of 2% PER, an NbTrans=8, makes it acceptable to operate with a 61% proportion of missed receptions (due to interference, collision or fading). In this
• Blind retransmissions/unconfirmed mode devices (default mode): For the same 2% target PER, NbTrans=4 translates to a proportion of missed reception of 38%. Again, the ADR will push the nodes to use the lowest spreading factor to match this target PER, opt
• WHITEPAPER
• Why lightweight downlinks/confirmed mode matters
• Improves Network Capacity: stops unnecessary retransmissions early, freeing up airtime for other devices.
• Reduces Battery Consumption: Avoids unnecessary RF transmissions, which are energy-expensive.
• Firmware-Friendly: Requires no changes on the device side; only server-side logic must be adapted.
• Design consideration for high SF devices This mechanism is especially valuable for high SF (SF11–12) devices, where airtime per transmission is long and NbTrans ≥ 3 can cause seconds of channel usage. A single lightweight downlink can interrupt this l
• Implementation guidance for network servers To enable uplink self-termination and improve overall transmission efficiency, LoRaWAN network servers (LNS) should implement the following:
• Minimize downlink overhead: Use the smallest valid downlink format (e.g., no payload) to preserve airtime and battery.
• Schedule lightweight downlink responses (e.g., empty FRMPayload with valid MIC or FOpts-only MAC commands) during the RX1 or RX2 window after a successfully received uplink. These responses will interrupt the NbTrans loop, even if no application-layer ACK
• Ensure downlink timing compliance with LoRaWAN Class A specifications, so the device recognizes the downlink as valid.
• Use PER-based optimization: Monitor Packet Error Rate over a sliding window and send ADR command when necessary, i.e., when PER exceeds acceptable thresholds.
• Support high SF scenarios: Prioritize this strategy for high-Spreading Factor devices (e.g., SF11–12) where long airtimes and high NbTrans values can cause heavy congestion. A single downlink empty message can prevent multiple seconds of unnecessary airti
• 3. Spreading Factor and Airtime Optimization Optimizing Spreading Factor (SF) allocation is one of the most critical aspects of operating a LoRaWAN network. A careful use of spreading factors can reduce airtime consumption, increase system throughput,
• WHITEPAPER
• Balanced SF distribution For frequency plans using SF7-12, such as EU868, exceeding 10% of SF12 from total SF usage is not recommended. When too many devices operate on SF12, their transmissions occupy the channel for long durations leading to network
• For frequency plans where the lowest data rate is SF10, such as US915, exceeding 15–20% of SF10 from total SF usage is not recommended. While SF10 is used for join requests and deep coverage, its excessive use can reduce overall network capacity. Balancin
• Dynamic allocation based on real-time network conditions (e.g., congestion levels, packet error rates) is far superior to static allocation because it adapts to the actual operating environment rather than theoretical link budgets. This ensures that SF as
• Capacity-aware device provisioning It's always important to monitor usage of high SF and use network statistics to ensure effective distribution of SF. This approach accounts for both device density and existing channel utilization, avoiding overload
• Optimize for air-time, not just delivery A common misconception is that the highest spreading factors inherently guarantee the best message delivery. In practice, a small number of retransmissions at a lower level SF (e.g., SF10) often impose signific
• First increase the transmission power;
• Then increase NbTrans to 8 if there is not much macro diversity (keeping max power);
• Increase SF by one step (keeping NbTrans to 8).
• WHITEPAPER
• In this way, the airtime is kept as low as possible, which is beneficial for saving the device airtime allowance, its battery and also decreases the load at higher SF.
• 4. Firmware Design and Device Behavior End-device firmware plays a central role in how effectively a LoRaWAN network performs. Well-designed firmware not only ensures compliance with network requirements but also ensures specified device longevity. Fo
• Balanced ADR implementation If devices intentionally deviate from ADR commands (for example by limiting NbTrans to protect battery life), this behavior should be clearly documented by the manufacturer so that network operators understand the trade-of
• For example, if an end device limits SF10 retransmissions to 3 with lightweight downlinks enabled, it may occasionally exceed this value when no downlink is received, as long as the average number of transmissions does not exceed 3.
• A practical implementation method is to maintain a "transmission credit bucket" that starts at zero, gains credits whenever fewer than three transmissions are used for a frame, and loses credits for each additional retransmission beyond three. When the bu
• WHITEPAPER
• Firmware certification alignment Adhering to the LoRaWAN MAC specification is not optional—it's critical for interoperability. Firmware must undergo thorough testing to validate behaviors such as:
• Correct handling of retransmissions,
• Responsiveness to MAC commands
• Failover mechanisms that preserve battery in adverse conditions.
• Certification includes practical test cases covering these areas, ensuring that devices perform consistently under real-world network stress and align with ecosystem standards.
• LoRaWAN network capacity simulation test A single 8-channel gateway could accommodate approximately 1 million daily messages, which translates to around 300k devices transmitting three times per day, matching the performance requirement for successful
• Conclusion LoRaWAN has proven itself as a robust and scalable technology for smart utility metering, and network capacity is an important factor in ensuring reliable performance at scale. The findings of the Network Capacity Task Force highlight that
• WHITEPAPER
• By deploying tiered gateway architectures, network operators can balance coverage and cost while ensuring sufficient macro-diversity to absorb traffic peaks. At the same time, spreading factor distribution and airtime management are crucial levers: limiti
• In real-world deployments, gateways typically serve only a few thousand devices, using just a fraction of the available capacity. This provides ample room for future growth and enables multiple projects to coexist within the same coverage area without imp
• In practice, LoRaWAN is limited by coverage, not capacity. Unlike licensed LPWANs, coverage can be expanded easily by adding gateways, making large-area deployment straightforward and cost-effective. This results in greater practical coverage. Once covera
• One benefit of LoRaWAN network for smart metering is the possibility of regular transmissions, a deterministic traffic that leaves open capacity for other applications (Smart cities, buildings, agriculture, industry etc.). Operators having disciplined pla
• Already LoRaWAN has been adopted by many utilities and service providers all over the world, for deployments with expected lifetimes of 10-20 years. While it is true that some network configurations are challenging, capacity is rarely problematic; coverag
• In summary, network capacity depends on good coverage, minimizing airtime consumption while maximizing delivery efficiency. Utility providers that adopt these practices will be able to serve millions of meters with high reliability, reduced infrastructure