A vendor data sheet will tell you LoRaWAN reaches 15 km, sometimes more. That number is real, and you will almost never get it. The 15 km figure is line-of-sight, gateway on a tower, sensor in open air, nothing in the path. Drop the same hardware into a city, a warehouse, or a tree line, and the honest range falls to a few kilometers or a few hundred meters. So the planning question is not “how far can LoRaWAN go,” it is “how far will it go where I am putting it, and what does reaching that far cost me in data rate and battery life.”
That trade-off is the part most project plans miss. You can push a LoRaWAN link farther, but the radio pays for distance by slowing down, and a slower radio drains the battery faster. Get the trade-off wrong and you ship sensors that either drop offline or die in a year. Here is how to plan it before you buy.
The numbers you can actually plan around
These are typical real-world ranges, not records and not best-case spec figures. Treat them as planning starting points, then confirm with a survey.
In dense urban areas, plan for roughly 2 to 5 km between a sensor and a gateway. Tall buildings, steel, and street canyons cut into the signal, and a sensor two blocks behind a high-rise can fail when a sensor at the same distance with a clear path connects fine. Exposed gateway locations on rooftops have hit well over 10 km in urban tests, but that is the exception, not what you size a network around.
In suburban and rural areas, 10 to 20 km line-of-sight is realistic, and partly wooded semi-rural sites still reach past 20 km with a clean path. True open line-of-sight, gateway high and sensor unobstructed, can run to 30 km, and the famous balloon and over-water records sit in the hundreds of kilometers. Those records prove the radio is capable. They do not describe your parking garage.
Indoor changes the math again. LoRaWAN penetrates better than most low-power radios because it runs at low frequency with high receiver sensitivity, and it will usually reach one or two basement levels of concrete, which is why it works for water meters and underground parking sensors. But “usually” is doing real work in that sentence. Deep indoor, metal-clad rooms, and below-grade vaults are exactly where you confirm coverage instead of assuming it.
Why distance costs you data rate and battery
LoRaWAN buys range with a setting called spreading factor, often written SF7 through SF12. The plain-language version: a higher spreading factor stretches each bit of data over a longer, slower transmission, which makes the signal easier to hear far away or through obstacles. The cost is that the radio stays switched on much longer to send the same message.
That airtime is what drains the battery. Transmitting at SF12 takes on the order of 25 times longer and burns roughly 20 to 25 times more energy than the same message at SF7. A sensor that sits close to a gateway can run at SF7, finish fast, and stretch a battery for years. The same sensor pushed to the edge of coverage climbs to SF12, sends slowly, and can chew through that battery in a fraction of the time. It also moves less data per message, so high-frequency or larger payloads stop fitting in the airtime budget.
This is the tension behind the range number. The far-edge sensor that “still connects” in your test may be the one that dies first in the field and the one that cannot send data often enough to be useful. Range, data rate, and battery life are three corners of the same triangle, and you only get to pick the balance, not all three.
Plan coverage before you buy sensors
The cheapest fix for every range problem is the one you do before the purchase order.
Start with gateway placement, because it decides more than any sensor spec. Height wins: a gateway 5 to 7 meters above the rooftop with its antenna clear of surrounding obstacles will outperform a more expensive sensor fleet sitting under a badly placed gateway. Keep gateways out of basements, metal equipment rooms, and next to HVAC gear, all of which kill performance. For multi-floor buildings, mounting near the building core with the antenna oriented to push the signal vertically helps reach sensors across floors.
Then run a coverage survey before committing to the sensor count. Pull floor plans and a topographic map, mark intended gateway and sensor locations, and note the obstacles that matter: buildings, tree lines, terrain, and metal. Walk the site with a test node and confirm the weak spots connect at a spreading factor you can live with for battery life. Where a corner will not reach, the fix is a better-placed gateway, a second gateway, or a repeater for basements and dense pockets, not hoping the sensor finds a path. Antenna and terrain effects are real and local, which is why a survey beats a spec sheet every time.
When LoRaWAN is the wrong choice
Honesty matters more than loyalty to one radio. LoRaWAN is a good fit for low-power sensors sending small messages on the order of minutes or hours. It is the wrong tool in a few clear cases, and forcing it costs you more than picking the right alternative up front.
If you are in a dense urban core where you cannot place or maintain your own gateways, NB-IoT or LTE-M on a carrier network usually wins. You rent the carrier’s coverage instead of building it, and the cell footprint already exists. The same goes for sites where mounting a gateway is not practical or allowed.
If you need real data throughput, video, frequent large payloads, firmware sent over the air at any speed, LoRaWAN’s airtime budget will not carry it. Cellular is the right answer there.
For true remote with no infrastructure at all, open ocean, remote pipelines, backcountry, there is no gateway to reach and no carrier tower, so satellite IoT is the realistic option even though it costs more per message.
The pattern: if you control the gateways, the messages are small, and the sites are within survey-confirmed range, LoRaWAN is hard to beat on power and cost. Outside those conditions, name the better radio and move on.
Where TagoIO fits
TagoIO is the data platform, not the radio. It is connectivity-agnostic, so it ingests data from LoRaWAN network servers, from cellular and NB-IoT devices over MQTT, from satellite backhaul, and from more than 500 device integrations, then handles dashboards, alerts, and analysis in one place. If a site is part LoRaWAN and part cellular, which mixed deployments often are, the data still lands in one platform. TagoIO is ISO 27001 certified for teams that need that posture. The point is that you choose connectivity on engineering grounds, and the platform fits whatever you pick.
Next steps
If you are scoping a deployment, decide the radio first on coverage and power, then bring the data into one place.
- See how device data flows in: tago.io
- LoRaWAN network server and MQTT integration docs: docs.tago.io
Plan the coverage, run the survey, and let the trade-off decide the radio before the sensors ship.
