LoRaWAN Gateway Capacity: How Many Sensors Can One Carry?
TL;DR: A LoRaWAN gateway is almost never limited by how many devices it can hold. It is limited by airtime. European regulation caps most sub-bands at a 1% duty cycle, which is 36 seconds of transmission per hour, and a sensor at the far end of a site uses that allowance far faster than one next to the gateway. So the honest answer to “how many sensors” is a range, not a number. The practical consequence is better than it sounds: once a gateway is up, adding a different kind of sensor usually costs nothing but the sensor.
Last updated: 29 July 2026
On this page
Key takeaways
- Device count is the wrong question. A LoRaWAN gateway is constrained by airtime, not by a device list.
- The same LoRaWAN gateway can carry hundreds of devices or struggle with fifty, depending entirely on where they sit.
- ETSI EN 300 220-2 sets the sub-band duty cycles: 0.1%, 1% or 10% depending on frequency. Most traffic sits on 1% sub-bands.
- A 1% duty cycle is 36 seconds of transmission per hour on that sub-band.
- LoRaWAN in Europe runs at 250 bit/s to 11 kbit/s depending on spreading factor, so a distant sensor occupies the air far longer per message.
- The Things Stack Sandbox fair use policy allows 30 seconds of uplink airtime and 10 downlinks per node per day.
- The gateway’s own downlink transmissions are duty cycle limited too, which is why confirmed uplinks scale badly.
What actually limits a LoRaWAN gateway
Vendors quote LoRaWAN gateway device counts because buyers ask for them, but the number is close to meaningless on its own. A LoRaWAN gateway does not maintain sessions with devices. It listens, and it demodulates whatever it can hear on the channels and spreading factors it is watching. Nothing is registered to it and nothing is reserved.
What that means in practice is that LoRaWAN gateway capacity is a function of how much air your sensors collectively occupy, not how many of them exist. A hundred devices reporting once a day is a trivial load. Fifty devices reporting every two minutes from the far corner of a site can be a problem. Same gateway, same catalogue, completely different outcome.
Two things consume that air: the regulatory duty cycle, which is a hard legal limit, and the spreading factor, which decides how long each message takes. Get both right and a single LoRaWAN gateway covers an industrial site comfortably. Get either wrong and you will be told the network is unreliable when the real problem is arithmetic.
The duty cycle rules that bind
In Europe the 868 MHz band is governed by ETSI EN 300 220-2, which divides it into sub-bands with different duty cycle allowances. The duty cycle is the fraction of time a transmitter is permitted to occupy a sub-band, and it applies to every device including the LoRaWAN gateway itself.
| Sub-band | Frequency | Duty cycle |
|---|---|---|
| K | 863 to 865 MHz | 0.1% |
| L | 865 to 868 MHz | 1% |
| M | 868 to 868.6 MHz | 1% |
| N | 868.7 to 869.2 MHz | 0.1% |
| P | 869.4 to 869.65 MHz | 10% |
| Q | 869.7 to 870 MHz | 1% |
A 1% duty cycle means 36 seconds of transmission per hour on that sub-band, then silence until the off-time has elapsed. This is not a policy you can negotiate with a supplier. It is a condition of using licence-exempt spectrum, and a compliant device will simply refuse to transmit rather than break it.
The half of this that catches people out is the downlink. Your LoRaWAN gateway is a transmitter too, and when it acknowledges a message it spends its own duty cycle allowance. A network built on confirmed uplinks therefore hits a ceiling far earlier than an equivalent one using unconfirmed messages, because the gateway runs out of permission to answer.
Spreading factor is the real variable
Spreading factor is how LoRa trades speed for range, and it is the single biggest influence on how much a LoRaWAN gateway can carry. A low spreading factor sends quickly and does not travel far. A high one is slow, and reaches much further through obstruction. In Europe that spread runs from about 250 bit/s to 11 kbit/s, which is a difference of more than an order of magnitude in how long an identical payload sits on the air.
This is why a device’s position matters more than its specification. Move a sensor from a clear line of sight into a plant room and its spreading factor rises, its message takes longer, and it consumes a bigger share of both its own duty cycle and the airtime the site collectively has available. Nothing about the sensor changed. Its cost to the network multiplied.
Public network fair use policies make the same point in a different currency. The Things Stack Sandbox allows 30 seconds of uplink airtime per node per day, and 10 downlink messages. Thirty seconds buys a great many short transmissions near the gateway and comparatively few slow ones from the edge of coverage. The Things Network’s own guidance is blunt about the consequence: intervals between messages should be in the range of several minutes, and LoRaWAN is not suitable for real-time data.
Why water sensors are the hard case
Almost every difficult radio position for a LoRaWAN gateway is a water position. Meters live in below-ground chambers under metal covers. Level instruments sit inside tanks. Leak detection sits on plant room floors behind machinery. Flow meters clamp onto pipework in ducts and risers. None of those are places a radio designer would choose.
That has a direct consequence for planning. A LoRaWAN gateway that comfortably serves office sensors on the floor above may deliver a marginal link to a meter pit fifty metres away, and a marginal link means a high spreading factor, long airtime and a much lower sustainable reporting rate. The honest design answer is usually not a second network. It is a gateway sited for the worst position rather than the easiest one, or an external antenna, or a chamber-friendly sensor with an external aerial.
The good news is that water data is naturally tolerant of this. Level, flow, pressure and water quality parameters do not need second-by-second resolution to be useful, and a fifteen minute interval on a radar level instrument or a clamp-on flow meter will catch everything a monthly manual reading misses. We covered the connectivity trade-offs more broadly in our LoRaWAN versus cellular guide.
What else can share the same gateway
Here is the part worth planning for. The expensive, disruptive part of a LoRaWAN deployment is the LoRaWAN gateway itself: the survey, the mounting position, the power, the backhaul and the permission to drill. Once that exists, the marginal cost of a different kind of sensor is the sensor, provided the airtime budget has room.
That is an argument for thinking about the whole estate at survey time rather than the water alone. If a site is going to want occupancy data, indoor air quality, energy sub-metering, temperature and humidity or door monitoring within two years, those sensors want the same infrastructure, and it is far cheaper to place the gateway once with all of them in mind.
We should be open about a commercial connection here: Indiott, an industrial IoT specialist, stocks AQUAIOT water instruments in its catalogue alongside its own range, so the two sit naturally together. Its gateway range and its wider LoRaWAN sensor catalogue cover the building and industrial side that water monitoring does not touch, including energy metering and people counting. If you are already planning a water deployment, it is worth asking what else the same radio can carry before the survey rather than after it.
The caveat is the airtime arithmetic above. Sharing a LoRaWAN gateway is free in hardware terms and not free in capacity terms, so a mixed estate needs its budget worked out rather than assumed. A dense occupancy deployment reporting every few minutes is a very different load from twenty water instruments reporting quarter-hourly.
Five checks before you add sensors
- Survey for the worst position, not the easiest. If a meter chamber is in scope, LoRaWAN gateway placement should be decided by that chamber.
- Work out the airtime budget, not the device count. Multiply expected message length by frequency by device, and check it against what the sub-bands allow.
- Avoid confirmed uplinks unless you need them. Every acknowledgement spends the gateway’s own duty cycle, and that is the ceiling most estates hit first.
- Set reporting intervals to the physics, not the dashboard. Tank level does not change in ten seconds, and a slower interval buys reliability everywhere else.
- Ask what else the site will want. Adding a sensor type later is cheap. Moving a LoRaWAN gateway later is not.
Frequently asked questions
How many sensors can one LoRaWAN gateway support?
There is no fixed number, because the limit is airtime rather than device count. A LoRaWAN gateway serving sensors that report a small payload once or twice an hour at a low spreading factor can carry hundreds. The same gateway serving devices at the edge of coverage, transmitting frequently, will support far fewer.
What is the LoRaWAN duty cycle in the UK?
It depends on the sub-band. Under ETSI EN 300 220-2 the 868 MHz band is split into sub-bands allowing 0.1%, 1% or 10%. Most LoRaWAN traffic uses 1% sub-bands, which permits 36 seconds of transmission per hour. The limit applies to the gateway as well as to devices.
Does a water sensor in a chamber need its own gateway?
Usually not. A below-ground chamber under a metal cover is a difficult radio position, but the normal fixes are LoRaWAN gateway placement, an external antenna on the sensor, or a lower reporting frequency to live within the higher spreading factor. A second gateway is a legitimate answer for a large or spread out site, not a default one.
Can building sensors and water sensors share a LoRaWAN gateway?
Yes. A LoRaWAN gateway is sensor agnostic and demodulates whatever it can hear, so occupancy, air quality, energy and water devices can all use the same infrastructure. The constraint is the shared airtime budget, so a mixed deployment should have its reporting intervals planned together rather than device by device.
How often can a LoRaWAN sensor send data?
The Things Network’s guidance is that intervals should be in the range of several minutes, and it states plainly that LoRaWAN is not suitable for real-time data. On the public Sandbox the fair use policy is 30 seconds of uplink airtime and 10 downlinks per node per day, which is a useful sanity check even on a private network.
Plan the radio once
The mistake that costs money is not choosing the wrong LoRaWAN gateway. It is siting the right one for the sensors you are buying this month, then discovering that the meter chamber, the tank farm and next year’s occupancy project all needed to be in the same conversation.
Water is a good forcing function for that survey, because water positions are the hardest ones on most sites. Solve for the chamber and the rest of the estate tends to fall out for free. For more on the water side see our LoRaWAN leak sensor guide, the LoRaWAN versus NB-IoT comparison, and our note on why a building management system is not a water monitoring layer.
Planning a water deployment and not sure what the radio will carry? Talk to AQUAIOT about gateway placement, chamber positions and reporting intervals before anything is specified.