LoRaWAN Range: What to Expect in Real IoT Deployments

The LoRaWANProtocolLoRaWANOpen long-range, low-power LPWANView profile range on the datasheet, those 15 kilometers, is true and almost never yours, and the gap between those two numbers gets paid for in the field.

The brochure figure is measured with clean line of sight, a gateway antenna at a good height, and the sensor out in the open. Your meter is in a pit, under a metal cover, with a six-story building in between. The real range of that link has nothing to do with the brochure, and that is where projects go wrong.

This guide covers what actually determines range, what numbers are reasonable in open country, in a city, and indoors, how to read the RSSI and SNR you see on the platform, and how to run a coverage survey before buying 500 sensors. If you need the protocol first, start with how LoRaWAN works.

What Determines LoRaWAN Range

The range of a radio link comes down to a simple sum, the link budget: what leaves the transmitter, minus what is lost on the way, has to stay above what the receiver can hear.

In LoRaWAN, that sum has four terms:

Power is capped by regulation: in the 868 MHz band, ETSI EN 300 220 sets both power and duty cycle. Nobody turns up the volume to reach further.

Sensitivity is what makes the LoRaWAN range everyone quotes possible at all. A LoRa receiver recovers signals well under the noise floor thanks to spread spectrum modulation, and the Semtech transceiver datasheets publish those thresholds per spreading factor and bandwidth. The full protocol architecture is maintained as an open standard by the LoRa Alliance.

The Spreading Factor Is the Steering Wheel

The spreading factor defines how long each symbol stretches over the air. A high SF is heard much further away, and in exchange it occupies the channel for longer, drains more battery, and carries less data.

The Things Network documentation lays out those relationships. The practical consequence matters more than the numbers: a sensor at the edge of coverage does not just perform worse, it also burns more battery and takes more airtime, at the expense of everyone else. A network full of SF12 nodes congests long before the device count suggests.

Adaptive data rate (ADR) is handled by the network server, which raises or lowers the factor based on the quality it observes. Who runs that server, and with how much control, is covered in the LoRaWAN network server guide.

Reasonable Numbers by Environment

Any figure here is indicative, because terrain decides. Still, these are the orders of magnitude worth budgeting with, assuming a well-placed gateway:

• Rural with line of sight, elevated gateway: on the order of 10 to 15 km, and considerably more in exceptional conditions.
• Suburban, low buildings and some tree cover: 2 to 5 km.
• Dense urban, closed blocks and tall buildings: 500 m to 2 km, with wide variation from one street to the next.
• Indoors from an outdoor gateway: one to three floors of penetration, driven more by facade materials than by distance.
• Basements and utility pits: a case of their own. Here you do not estimate, you measure.

There is also a shape to how coverage degrades. It is not a circle that fades evenly: it is a patchwork. One street runs clear for three kilometers because it lines up with the gateway, and the parallel street two hundred meters away drops out behind a single tall building. Planning on a radius drawn on a map produces a list of sites that mostly works and a handful that never will, and those are the ones that generate the service calls.

Two details move these numbers more than anything else. The first is gateway antenna height: going from 3 to 10 meters usually does more for coverage than any configuration change. The second is what sits right next to the sensor, not what sits halfway along the path.

Luis installed 60 level sensors across irrigation tanks spread 4 km around the gateway. Fifty-eight worked on the first try. The other two were 900 meters out, far closer than most, inside sealed metal cabinets. Distance was not the problem, the enclosure was. It was fixed with an external antenna outside the cabinet, without touching the sensor or the network.

Reading RSSI and SNR Without Fooling Yourself

When a message arrives, the platform shows two numbers, and it helps to know what each one says.

RSSI is the power the signal arrived with, in dBm, always negative. Closer to zero is better. As a field reference: above -100 dBm is a comfortable link, -100 to -115 dBm is normal, and below -120 dBm you are at the edge.

SNR is the signal-to-noise ratio, in dB. LoRa has an unintuitive property: it can demodulate signals below the noise floor, down to around -20 dB SNR at high spreading factors. A negative SNR does not mean the link is broken.

How they read together:

• High RSSI and high SNR: healthy link, you can lower the spreading factor and save battery.
• Low RSSI, acceptable SNR: you are far away, but clean. It works, and battery is worth watching.
• Decent RSSI, poor SNR: there is interference nearby. Moving the sensor or the gateway a few meters usually fixes more than raising power.
• Both low: the link is marginal. With rain, with leaves on the trees, or with a van parked in front, it will stop arriving.

It is also worth not confusing link quality with deployment health. A sensor with excellent RSSI that has not reported in three days has a battery, firmware, or installation problem, not a coverage problem. And the reverse: a weak link that delivers every message on schedule is doing its job, however alarming the number looks. What you monitor is messages received against messages expected; RSSI explains why, but it is not the measure of service.

One warning about what the dashboard shows. Those values belong to the last reception and describe that moment, not the average quality of the link. Decisions need the series across several days, with times and weather, which is where you find links that work at eight in the morning and not at midday.

And an architectural detail that confuses many teams: the IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile platform sees what the network server hands it. If three gateways heard one message, the one that knows which received it best is the network server, not the application platform. Coverage tools and gateway maps live there.

Where the Gateway Goes

The decision with the most weight on coverage is not the sensor's, it is the gateway's, and it is usually made by whoever holds the key to the technical room.

Four rules that hold in almost any deployment:

• As high as the site allows. Every meter of height widens the radio horizon and lifts the signal clear of nearby obstacles. A short mast on a roof beats an expensive antenna at street level.
• Antenna vertical and in the clear. A tilted antenna loses much of its gain, and a metal mass within a meter distorts the radiation pattern. The cabinet's own sheet metal counts as an obstacle.
• Short cable, correct type. Cable loss comes straight off the link budget. Move the gateway toward the antenna rather than extending the cable, and pick low-loss cable if several meters are unavoidable.
• Away from other radios. A gateway next to a cellular antenna or a data link can be desensitized. If SNR is poor while RSSI looks reasonable, this is often the cause.

And a cost rule: in difficult areas, a second gateway is almost always cheaper than the engineering time spent trying to cover them with one. An indoor gateway costs less than two technician visits with travel.

In city installations, the site also decides the maintenance. A roof reached by a ladder and the building manager's permission is a great location right up to the day someone has to climb up and restart a unit. Weigh accessibility as heavily as coverage, because the deployment's life is measured in years.

The Coverage Survey: Measure Before You Buy

The most expensive way to discover a coverage problem is with 500 sensors already installed. The cheapest takes two days.

1. Put a test gateway where the permanent one would go, at the same height with the same antenna. If the final spot is a mast, measuring from the office window does not count.
2. Walk the real installation points with a test node that transmits periodically, and measure at the exact spot: inside the pit, inside the cabinet, at meter height. Not next to it.
3. Record RSSI, SNR, and spreading factor at each point, with its position. A sheet with twenty rows beats any simulation.
4. Repeat the doubtful points at a different time of day. What changes between two readings is the useful information.
5. Leave margin. If a point only works at SF12, that point is already marginal before anything is installed.

A test node costs very little and pays for itself on the first survey. Any LoRaWAN development board configured to send a small message every minute will do, as long as it reports the spreading factor it used. What matters is that it is the same class of hardware as the sensors you plan to buy, with a comparable antenna: a survey run with a well-equipped test rig and finished with cheaper sensors measures the wrong thing.

With that data the decisions are direct: move the gateway, raise it, add a second one, or change how the problem sensors are mounted.

Elena runs technical services at a water utility. On a project with 1,200 water meters she ran a two-day survey across 30 points chosen by district and pit type. The survey told her two things: two gateways covered 90% of the municipality, and the cast iron pits in the old town needed external antennas. Those two days cost a week of work. Finding out afterwards would have meant reopening 300 pits.

When More Range Is Not the Answer

There are situations where pushing LoRaWAN costs more than changing approach.

More gateways, not more power. When coverage fails in specific areas, the answer is nearly always to densify. One extra well-placed gateway solves what no radio setting will, and it lowers the average spreading factor across the network, improving battery life for everyone.

Repeaters, carefully. They exist, they work, and they add a failure point with its own power supply. Before adding one, rule out that relocating the gateway does the same job.

A different network. If the device moves, needs immediate response, or has to send more data than LoRaWAN carries comfortably, the honest comparison is with low-power cellular. The differences are in the NB-IoT guide.

A link that will not happen. A sensor inside a steel cold room, or in a lift pit, is not going to reach a gateway a kilometer away no matter how it is tuned. There the answer is a local gateway, a cable, or moving the measurement point.

There is one more case worth naming: the site that works today and will not in two years. A gateway aimed across an empty plot covers it well until somebody builds on the plot. If the plan depends on a clear path over land you do not own, treat that link as temporary and leave room in the budget for a second gateway. It is a cheap assumption to make early and an expensive one to discover late.

Decide this during the survey, not during installation. Changing technology with the hardware already bought is the worst conversation available with a client.

Eight Checks Before You Install

1. Gateway height. Is it as high as the site allows, and above nearby obstacles?
2. Antenna. Is it the right one, vertical, and clear of metal?
3. Cable. Is the antenna cable short and the right type? Ten meters of cheap cable eats most of what a better antenna gains.
4. Real measurement point. Was it measured inside the pit or cabinet, rather than beside it?
5. Margin. Are there points that only work at SF12? Those fail first.
6. Density. Would a second gateway solve the difficult area for less than the cost of fighting it?
7. Seasonality. Was it measured with leaves on the trees, or in January?
8. Follow-up. Will anyone watch RSSI and SNR trends after commissioning?

The last two get forgotten most, and both give months of warning. Tracking fleet health, including battery and last contact, is part of device management.

Conclusion

LoRaWAN range is not a vendor figure, it is the outcome of one specific link between two specific points. What to keep:

• The link budget rests on four things, and only two are yours: the spreading factor and, above all, the antennas and where they sit.
• In open country you count kilometers; in a city, hundreds of meters. What surrounds the sensor weighs more than distance.
• RSSI and SNR are read together, and as a time series. A single dashboard value does not describe a link.
• A two-day coverage survey saves redoing an installation that took months.
• When coverage fails, the answer is usually another gateway, not more power.
• If the case does not suit LoRaWAN, better to know before the hardware is bought.

If you are sizing a deployment and want to sanity-check the approach, talk to the team or see how other integrators work through the partner program. For the full urban case, the reference is the LoRaWAN for smart cities guide.

Frequently asked questions

What is the real range of LoRaWAN?

It depends on the environment. With a well-placed gateway, expect on the order of 10 to 15 km in rural areas with line of sight, 2 to 5 km in suburban areas, and 500 m to 2 km in dense urban areas. The figures are indicative, because terrain decides.

How far does LoRaWAN reach in a city?

In dense urban areas, with closed blocks and tall buildings, between 500 m and 2 km, with wide variation from one street to the next. Coverage is a patchwork, not a circle: one street runs clear for kilometers and the parallel one drops out behind a single tall building.

Does LoRaWAN work indoors and in basements?

From an outdoor gateway it usually penetrates one to three floors, driven more by facade materials than by distance. Basements and utility pits are a case of their own: there you measure at the exact installation point instead of estimating.

What is a good RSSI and SNR for LoRaWAN?

As a field reference, above -100 dBm is a comfortable link, -100 to -115 dBm is normal, and below -120 dBm is the edge. LoRa can demodulate down to around -20 dB SNR at high spreading factors, so a negative SNR does not mean the link is broken. Read both together and as a series over several days.

How does the spreading factor affect range?

A higher spreading factor is heard much further away. In exchange it occupies the channel for longer, drains more battery and carries less data. A point that only works at SF12 is already marginal before anything is installed.

How do you improve LoRaWAN coverage?

Raise the gateway antenna first: going from 3 to 10 meters usually does more than any configuration change. Keep the antenna vertical and clear of metal, keep the cable short, and in difficult areas add a second gateway instead of looking for more power, which regulation caps anyway.