How Many Devices Can One LoRaWAN Gateway Really Handle?

The Question Every Buyer Asks

How many sensors can one gateway support? It comes up in the first meeting of every deployment, the answer determines the infrastructure budget, and the number in the brochure is somewhere between optimistic and meaningless.

It is not that vendors are lying. A gateway genuinely can serve tens of thousands of devices under some set of assumptions. It is that the assumptions do all the work and nobody states them, so the same hardware honestly supports 700 devices in one deployment and 20,000 in another. The difference is not the gateway. It is mostly your coverage.

That is worth understanding before you buy anything, because it means gateway capacity is something you design rather than something you purchase.

What Is Actually Inside

A gateway's radio is a concentrator, and the concentrator's architecture explains most of what follows. The current generation, Semtech's SX1302 and the SX1301 before it, provides eight parallel multi-spreading-factor demodulation paths across the eight 125 kHz channels it is configured for, plus a dedicated higher-bandwidth LoRa demodulator and an FSK one.

Two things follow. The first is that those eight paths are shared across the channels rather than assigned one each, so a gateway can decode several overlapping transmissions at once, on different channels or even different spreading factors on the same channel. The second is that eight is not a large number. Concurrency is finite, and when a ninth packet arrives while eight are in flight, it is simply lost.

In practice, though, the demodulator count is rarely what limits a real deployment. Airtime runs out first.

The Collision Limit Nobody Mentions

LoRaWAN devices transmit whenever they have something to say. There is no scheduling, no channel reservation, and no listening before transmitting in most regions. That makes the uplink an ALOHA channel, and ALOHA channels have a well-known and unpleasant property.

Throughput rises with offered traffic up to about 18 percent channel utilisation, and then it falls. Not levels off: falls. Past the peak, more transmissions produce fewer successful receptions, because collisions destroy packets that then get retried, which causes more collisions. A network at 15 percent utilisation is healthy. The same network at 40 percent may deliver less data than it did at 15.

LoRaWAN does not degrade gracefully at capacity. It works, and then it collapses, and the collapse looks like devices failing rather than a network being full. Size for the knee, not for the cliff.

LoRa softens this a little through the capture effect: when two packets collide on the same channel and spreading factor, the receiver can often still decode the stronger one if it arrives about 6 dB above the other. That helps real networks beat the textbook model, and it is also why a well-planned network with devices at varied distances performs better than the arithmetic suggests. It does not change the shape of the curve.

The Variable That Decides Everything

Here is the number that makes gateway capacity a coverage question. These are real airtimes for a 20 byte payload on a 125 kHz channel:

Data rate	Airtime	Relative cost
SF7	72 ms	1x
SF8	134 ms	1.9x
SF9	247 ms	3.4x
SF10	453 ms	6.3x
SF11	987 ms	13.7x
SF12	1810 ms	25x

One device at SF12 consumes as much of the network as twenty-five devices at SF7. Sending the identical message. The only difference is how far away it is, or how bad the link is.

That is why spreading factor distribution, not device count, is the real capacity metric, and why it connects directly to everything else. Devices sit on high spreading factors because coverage is marginal, which is a gateway placement problem addressed by range assessment, or because the gateway's noise floor has risen and pushed the effective coverage inward, which is the interference problem. Fixing either one increases the capacity of hardware you already own, at no cost.

Doing the Arithmetic

With those two pieces, the estimate becomes straightforward. Take EU868 with eight channels: that is 28,800 channel-seconds of airtime in an hour. Apply the ALOHA ceiling and roughly 5,300 seconds of that is usable. Divide by what each device consumes per hour.

Device profile (20 byte payload)	Devices per gateway
SF7, one uplink per 15 min	~18,000
SF9, one uplink per 15 min	~5,400
SF10, one uplink per 15 min	~2,900
SF12, one uplink per 15 min	~700
SF9, one uplink per hour	~21,000
SF12, one uplink per hour	~2,900

This is the honest version of the vendor's number, and notice that the brochure figure is not wrong: with hourly reporting at good data rates you really can put tens of thousands of devices on one gateway. Move the same fleet to the edge of coverage with a 15 minute interval and the same hardware supports a few hundred.

Treat these as an upper bound rather than a plan. They ignore retries, join traffic, other people's devices sharing the band, and the constraint that actually bites first.

Downlink Is the Real Ceiling

Everything above concerns uplink. Downlink is scarcer by an order of magnitude, and it is where most networks actually hit the wall.

A gateway is half duplex. While transmitting it is deaf, so every downlink costs uplink capacity as well as its own airtime. On top of that, in duty-cycle regions the gateway is subject to the same transmission limits as any other device, so its ability to talk is capped by regulation, not just by hardware. The duty cycle and airtime article works through that accounting in detail.

Then look at what wants a downlink. Every join accept is one. Every confirmed uplink demands an acknowledgement. Every ADR adjustment, every MAC command, every configuration change and every firmware update is downlink traffic. A fleet that uses confirmed uplinks by default has quietly made the gateway transmit once for every message it receives, and that is the single most common self-inflicted capacity problem in LoRaWAN.

The practical rule: use confirmed uplinks only where a lost message genuinely matters, which for periodic sensor telemetry is almost never, since the next reading is along in fifteen minutes anyway.

Join storms are the same constraint arriving all at once. After a site power cut, every device tries to rejoin simultaneously, each join needs a downlink, the gateway can send one at a time and must respect its duty cycle while doing it, and a five minute outage turns into an hour of recovery. Firmware that randomises its rejoin backoff avoids this entirely, which makes it worth asking about before you buy a fleet rather than after.

Why More Gateways Is Not Always More Capacity

There is a natural assumption that two gateways double capacity. They do not, and the reason is worth knowing.

Every gateway that hears a transmission forwards it, and the network server discards the duplicates. That redundancy is genuinely valuable for coverage and reliability, but each of those gateways spent a demodulator path and a slice of its own capacity receiving a packet that was going to be delivered anyway. Two gateways covering the same area give you resilience and better link margin. They do not give you two networks' worth of airtime, because the airtime is in the radio spectrum, which they share.

Capacity scales with geographic separation, not gateway count. Two gateways covering two areas roughly double the fleet you can serve. Two gateways covering one area mostly buy insurance.

The exception is channel count. In 64-channel plans like US915 and AU915 you can run gateways on different sub-bands, and a 16-channel gateway with two concentrators genuinely doubles the parallel paths and the channel budget. In EU868 the band is small enough that this does not apply in the same way.

And you never own the whole channel. Other LoRaWAN networks, other operators, and every other unlicensed device in the band are consuming the same airtime, which does not appear in any calculation you perform on your own fleet. In a busy urban area this can be a large fraction of the total. It is measurable, and worth measuring before committing.

Design the Capacity, Don't Buy It

Almost everything that increases capacity is free, and none of it involves a bigger gateway.

Improving coverage moves devices down the spreading factor table, and every step down roughly halves their cost to the network. Removing an interference source does the same thing by restoring the sensitivity you paid for. Lengthening reporting intervals is the bluntest tool and often the most effective, since the difference between a 15 minute and a 60 minute interval is a factor of four in capacity and, in most applications, no operational difference whatsoever. Trimming payloads helps. Turning off confirmed uplinks helps a lot. Staggering device transmission times so a fleet does not report in lockstep on the hour helps more than people expect.

When you genuinely need more, add gateways where the devices are rather than where the existing gateway is, and let coverage do the work.

Measure Instead of Modelling

Every number in this article is a planning estimate. The real answer for your deployment is measurable, and the measurement is not difficult.

What you want to know is your channel utilisation and your spreading factor distribution, both of which your network server or an independent traffic analyzer can show you, including the traffic from networks you do not operate. If your utilisation is in the low single digits, capacity is not your problem and you should stop thinking about it. If it is approaching double digits, you are closer to the knee than the device count suggests, and the fix is usually spreading factors rather than hardware.

Sizing this correctly is also what keeps a pilot from becoming an embarrassment at scale, which is the pattern the pilot to production article is about: everything works with twenty devices, because twenty devices cannot fill a channel no matter what they do.

What I Provide

Capacity planning is where a deployment budget is decided, and getting it wrong is expensive in both directions: too few gateways and the network collapses under its own retries at exactly the moment it goes into production, too many and you have bought infrastructure that duplicates coverage you already had.

I size LoRaWAN networks against the numbers above rather than against a datasheet, working from your actual payload sizes, reporting intervals, and measured coverage, and I measure existing networks to find out where their real utilisation sits and what is driving it. That usually turns into recommendations that cost nothing: spreading factor distribution to fix, confirmed uplinks to switch off, intervals to stagger, and one gateway to move rather than three to buy.

Where new infrastructure is genuinely needed, I plan placement, configure the network server, and hand over the measurement tooling so your team can watch utilisation as the fleet grows. Everything comes with source code and documentation, and there are no recurring fees.