How Many Smart Meters Fit on One LoRaWAN Gateway?

A single eight-channel LoRaWAN gateway can serve up to 300,000 smart meters, according to a LoRa Alliance simulation, if each device transmits three times a day. A new whitepaper from the responsible task force provides concrete architecture and parameter recommendations for this — and concludes that radio coverage, not capacity, is the real bottleneck.

How Much Capacity Does a LoRaWAN Gateway Really Have?

LoRaWAN (Long Range Wide Area Network) is a radio standard for battery-powered IoT devices, offering long range and minimal energy consumption, managed by the LoRa Alliance. For utility companies, the technology has long been a standard tool for smart metering rollouts — the digital connection of water, electricity, and heat meters. The central planning question: how many meters can a single gateway — the base station between end devices and the network server — reliably serve?

The whitepaper “LoRaWAN Network Capacity Optimization for Utility Applications”, published in June 2026 by the LoRa Alliance Network Capacity Task Force, provides a simulation: an eight-channel gateway — meaning eight receive channels usable in parallel — can reportedly process around one million messages per day. At three transmissions per device per day, that corresponds, in the simulation, to roughly 300,000 devices at a target of 98 percent meter reading rate.

This figure rests on several assumptions: a device density of 20,000 devices per square kilometer, a packet size of 52 bytes, an additional 15 dB of attenuation to simulate indoor conditions, and a retransmission rate (NbTrans) of 3. 20,000 devices per square kilometer works out to roughly one device per 50 square meters — plausible for a densely built urban district with multiple meters per household, but towards the upper end of realistic scenarios. Adding gateways that can receive the same signal — what the task force calls gateway diversity — can increase capacity by a further 60 percent or so.

As a second, independently cited lever, the whitepaper points to the move to the new, faster SF5 and SF6 data rates introduced by the RP2-1.0.5 specification published in November 2025: under suitable conditions, this can more than double the baseline capacity of an eight-channel gateway, according to the whitepaper — the section on spreading factor distribution below explains how.

Important context: in real-world deployments, a gateway typically serves only a few thousand devices, according to the whitepaper — a fraction of its theoretical capacity. So there is headroom well before a single gateway approaches its limits.

How Should a Gateway Network for Smart Metering Be Designed?

The capacity figures apply per gateway — but whether they are reached depends heavily on location and network architecture. The whitepaper therefore recommends a three-tier model.

Large outdoor gateways with 16 to 64 channels form the backbone of a citywide network, covering large areas from comparatively few sites. Where this coverage is insufficient — in densely built-up areas, industrial zones, or underground utility zones — smaller eight-channel outdoor gateways add local coverage and take load off the larger gateways.

For buildings, basements, or multi-dwelling units where walls and ceilings heavily attenuate outdoor signals, the model also calls for indoor eight-channel gateways. The task force additionally recommends so-called macro-diversity: ideally, more than one gateway receives each transmission, which improves redundancy and reliability — but also adds to capital and operating costs.

For small to medium deployments, this dual coverage is therefore often planned for only part of the device fleet — around 30 percent or less, depending on device density. As a service-quality target, the whitepaper cites a packet collection rate of 95 to 99 percent, as required by many utility service contracts. For individual hard-to-reach devices or small groups, the paper also proposes battery-powered LoRaWAN relays: devices that forward signals without needing a local power supply. A single relay can serve up to 16 end devices, according to the whitepaper — a comparatively low-cost solution for isolated coverage gaps that avoids installing an additional gateway.

How Can Transmissions Per Device Be Optimized?

Beyond infrastructure, the behavior of individual end devices plays a central role in network capacity, since every transmission consumes airtime — the whitepaper’s term for transmission time. LoRaWAN distinguishes between unconfirmed uplinks, where the end device expects no acknowledgment from the network, and confirmed uplinks, where it requests an acknowledgment and retransmits if needed. How often a device retransmits is controlled by the NbTrans parameter.

The whitepaper recommends different strategies depending on the use case: for battery-critical devices in difficult radio conditions, such as water meters in underground pits, it recommends confirmed uplinks with a moderate NbTrans of 8, to ensure that critical readings are not lost.

For devices with frequent transmissions, such as electricity meters, it instead recommends unconfirmed uplinks with NbTrans 3, since occasional packet loss can be compensated for by subsequent readings, and forgoing acknowledgments frees up airtime for other devices.

As an additional option, the paper describes so-called lightweight downlinks: instead of sending a full acknowledgment, the network server sends a minimal response to end retransmission loops early — without requiring any change to device firmware. Combined with Adaptive Data Rate (ADR), a mechanism that automatically adjusts data rate and transmit power to radio conditions, this allows the Packet Error Rate (PER) to be controlled in a targeted way, according to the whitepaper.

What Role Does Spreading Factor Distribution Play?

In LoRaWAN, the spreading factor (SF) determines the trade-off between range and transmission speed: higher SF values reach greater distances and penetrate obstacles better, but require significantly more airtime per message.

According to the whitepaper, airtime at SF12 is roughly four times that of SF10 in the European EU868 band — meaning a device on SF12 occupies the channel correspondingly longer, blocking other devices. The task force therefore recommends clear ceilings: in EU868, no more than 10 percent of total traffic should run on SF12, since SF12 is, among other things, used for the rare but critical join requests of new devices.

In the North American US915 band, a ceiling of 15 to 20 percent applies to SF10, which provides the lowest available data rate there. A key finding of the paper is that several retransmissions at a lower SF often consume less airtime and energy than a single long transmission at the highest SF. Network operators should therefore not reflexively optimize for maximum range, but for minimum total airtime.

This is where the RP2-1.0.5 specification published in November 2025 comes in: it introduces the new, faster SF5 and SF6 data rates — 15.6 and 9.4 kilobits per second respectively, up to three times and 1.5 times faster than previous maximum rates. For devices able to use these rates, the required airtime drops accordingly, which, under suitable conditions, can more than double the baseline capacity of an eight-channel gateway, according to the whitepaper.

Capacity or Coverage — What Does the Research Say?

The whitepaper’s central thesis is this: in practice, LoRaWAN is limited more by radio coverage than by capacity. Coverage, it argues, can be extended comparatively easily by adding gateways, while per-gateway capacity — as the simulation figures show — still leaves considerable headroom in typical deployments.

One question arising from the whitepaper itself remains unanswered: what spreading factor distribution underlies the capacity simulation of roughly one million messages per day cited at the outset — and does it itself comply with the 10 percent SF12 ceiling for EU868 recommended elsewhere in the same paper? A less favorable SF distribution could noticeably change the stated capacity, and the whitepaper offers no details on this point.

Academic work on LoRaWAN scalability paints a more nuanced picture, though mostly predating RP2-1.0.5 and this whitepaper. A survey on LoRaWAN scalability for massive IoT describes signal interference and concurrent transmission collisions as central challenges in very densely populated networks — framing this very much as a capacity question, not only a coverage question.

Another paper on collision avoidance resource allocation for LoRaWAN identifies the use of acknowledgments — as recommended in the new whitepaper for water meters with NbTrans 8 — as a potential scalability risk, since these are further constrained by regulatory airtime limits known as the duty cycle.

Notably, the term duty cycle does not appear anywhere in the new whitepaper. In EU868, duty cycle rules limit a device’s transmit time in most sub-bands to around one percent per hour — regardless of how much theoretical gateway capacity is available.

For devices with frequent transmissions and high NbTrans values, this regulatory framework could become more relevant than the raw capacity figures suggest.

Conclusion

The whitepaper gives network planners concrete figures and levers that, until now, have mostly lived inside individual vendors’ simulation models: tiered gateway architectures, device-class-specific retransmission rates, and the impact of the new SF5/SF6 data rates on overall capacity. For planning smart metering projects, these are useful reference points — with the caveat that the underlying assumptions should be stated clearly, and the source recognized for what it is: an industry task force with a well-founded, but not neutral, interest in the message “capacity is solved, build more gateways.”

Anyone planning a concrete project should treat the figures cited here as a starting point for their own measurements and site analyses — not as a guarantee.

How many smart meters can a LoRaWAN gateway serve?

According to a LoRa Alliance simulation, an eight-channel gateway can process around one million messages per day. At three transmissions per device per day, this corresponds in the simulation to roughly 300,000 devices at a target of 98 percent meter reading rate. In practice, gateways typically serve only a few thousand devices, using just a fraction of this capacity.

What is the difference between confirmed and unconfirmed uplinks in LoRaWAN?

With unconfirmed uplinks, a device transmits without expecting an acknowledgment from the network. With confirmed uplinks, the device requests an acknowledgment and retransmits if needed, controlled by the NbTrans parameter. Confirmed uplinks increase reliability but consume more airtime and energy.

What does macro-diversity mean in LoRaWAN networks?

Macro-diversity describes a transmission being received by more than one gateway at the same time. This increases a network’s reliability and resilience but adds infrastructure costs. In small to medium deployments, dual coverage is therefore often planned for only part of the device fleet.

When does a LoRaWAN relay make sense?

A LoRaWAN relay is a battery-powered device that forwards signals between end devices and gateways without needing a local power supply. It is suitable for individual devices or small groups outside regular coverage and can serve up to 16 end devices, according to the whitepaper. For larger coverage gaps, an additional gateway is usually the better solution.

How does the spreading factor affect network capacity?

Higher spreading factor values increase range and penetration but significantly extend airtime per message. In EU868, airtime at SF12 is roughly four times that of SF10, according to the whitepaper. Heavy use of a high SF blocks the radio channel for longer, reducing overall capacity for all devices.

Is LoRaWAN limited by radio coverage or by network capacity?

In its current whitepaper, the LoRa Alliance views radio coverage as the main limiting factor, since per-gateway capacity in practice usually proves sufficient. Scientific work on LoRaWAN scalability, however, points out that collisions and regulatory airtime limits can also become relevant in very dense networks. For specific projects, it is therefore advisable to assess both factors based on the actual device density and radio conditions.