Before a single dashboard gets built or a single alert gets configured, your sensors need a way to talk. That choice — which connectivity technology gets between your physical assets and your application layer — determines what you can monitor, where you can deploy, how much it costs per endpoint, and whether the deployment scales or stalls.
Most IoT connectivity discussions start with Wi-Fi and cellular because they are familiar. They should not end there.
LoRaWAN — Long Range Wide Area Network — is the connectivity layer that makes large-scale industrial IoT economically viable for use cases where Wi-Fi is impractical and cellular is unaffordable at device counts above 50–100 endpoints. This is not a niche technology. It is deployed on six continents in applications ranging from grain storage to oil and gas infrastructure to urban utility metering.
Understanding it starts with understanding what the alternatives actually cost at scale.
The Connectivity Math Nobody Runs
Consider a manufacturing plant with 300 sensors: temperature monitors on refrigeration units, vibration sensors on compressors, level sensors in chemical tanks, and environmental monitors across the facility.
Wi-Fi: Each access point covers 100–150 feet indoors in an industrial environment with metal structures. You need 15–25 APs to cover a medium facility reliably. Each AP requires power, network drops, and maintenance. And Wi-Fi was designed for high-bandwidth computing, not low-power sensors — a battery-powered sensor on Wi-Fi lasts weeks, not years.
Cellular (LTE/CAT-M1/NB-IoT): Per-device airtime runs $1–$8 per month depending on carrier, data plan, and region. For 300 sensors, that is $3,600–$28,800 per year before hardware, SIM management, or network fees. At 1,000 sensors — a medium-sized agricultural operation or a multi-building campus — you are spending $36,000–$96,000 annually just on connectivity.
LoRaWAN: A single gateway covers 1–5 kilometers in dense urban/industrial environments, 10–15 kilometers in open terrain. Gateway hardware runs $200–$500. Per-device airtime on a private network: effectively zero once the gateway is deployed. Monthly device costs on public LoRaWAN networks: $0.10–$0.50 per device.
For 300 sensors on a private LoRaWAN network with 2 gateways: the connectivity cost after initial hardware is near zero. The economics are structurally different.
How LoRaWAN Works
LoRaWAN operates on sub-gigahertz ISM bands — 915 MHz in North America, 868 MHz in Europe. These frequencies have specific propagation characteristics:
Range: Sub-GHz signals travel further and penetrate building materials more effectively than 2.4 GHz (Wi-Fi) or higher frequencies. A 915 MHz signal passes through concrete walls, metal structures, and dense foliage in ways that 2.4 GHz does not.
Power: LoRa radios in sleep mode draw microamps. In active transmit mode, a burst transmission lasts 100 milliseconds to a few seconds. A Class A LoRaWAN device sending one reading per hour can run on a single AA battery for 3–7 years.
Bandwidth: LoRaWAN is a low-bandwidth technology by design. Typical payloads are 10–50 bytes. You can transmit a temperature reading, a GPS coordinate, a vibration threshold breach, or a tank level — not a video stream or a large data file. This is intentional. The bandwidth limit is what makes the range and power characteristics possible.
Spreading Factors Explained
LoRaWAN uses a parameter called “spreading factor” (SF) to trade off range, data rate, and airtime. SF7 through SF12 are the standard values.
| Spreading Factor | Data Rate | Range (open terrain) | Time on Air (10-byte payload) |
|---|---|---|---|
| SF7 | ~5.5 kbps | ~2 km | ~46 ms |
| SF9 | ~1.8 kbps | ~5 km | ~370 ms |
| SF12 | ~250 bps | ~15 km | ~2.8 sec |
Higher spreading factors reach further but transmit more slowly and use more airtime per message. In a dense deployment with gateways nearby, SF7 maximizes data rate and battery efficiency. In a remote deployment with one gateway covering a wide area, SF12 or SF11 ensures reliable delivery.
IoT SimpleLink’s Adaptive Data Rate (ADR) algorithm manages spreading factor selection automatically. Devices close to a gateway operate at SF7–SF8. Devices at range shift to higher spreading factors without manual configuration.
What LoRaWAN Is Right For
LoRaWAN excels in use cases characterized by:
- Small payloads. Sensor readings, GPS coordinates, status flags, threshold events. Not files, not streams.
- Infrequent transmission. Readings every minute, every hour, or on events. Not continuous data.
- Power-constrained endpoints. Sensors with no power access that must run on battery for years.
- Large geographic spread. Multiple buildings, outdoor terrain, underground installations, remote sites.
- High endpoint counts. Dozens to tens of thousands of sensors per network.
Industrial applications where LoRaWAN is the right choice:
- Tank level monitoring across a distributed fuel or water infrastructure — readings every 15 minutes, devices buried or inaccessible, battery-only power
- Agricultural soil and weather sensors — hundreds of sensors per farm, outdoor terrain, battery power, no power infrastructure
- Water utility meter reading — underground meters, dense urban deployment, no power, monthly or daily readings
- Cold chain temperature logging — freezer/cooler probes in retail locations, simple temperature readings, long battery life
- Building environmental monitoring — CO2, TVOC, temperature, humidity sensors throughout a multi-floor building without running Cat6 to every sensor
What LoRaWAN Is Not Right For
Cellular (LTE/CAT-M1) is better when per-device cost is acceptable and you need higher data rates or real-time control. Wi-Fi is better when devices are stationary, near power, and require higher bandwidth. Bluetooth is better for very short range, very high frequency readings, or personal area network use cases.
Protocol selection is a use-case question, not a brand question.
Private vs. Public LoRaWAN Networks
LoRaWAN devices can connect to either private networks (your gateways) or public networks (Helium, The Things Network, or carrier-operated LoRaWAN infrastructure).
Private networks are built with gateways you deploy and manage. Data stays within your infrastructure. No per-device airtime fees after hardware. No dependence on a third-party network operator. The right choice for industrial, healthcare, and government deployments where data sovereignty matters.
Public networks let you connect devices without deploying gateway hardware. Useful for sparse deployments in urban areas with existing public network coverage, or for testing and proof of concept before committing to private infrastructure.
IoT SimpleLink supports both. Devices can join private networks managed through IoT SimpleLink directly, or connect through public network integrations and forward data to IoT SimpleLink as the network management and forwarding layer.
LoRaWAN Network Design Basics
A LoRaWAN network requires at minimum one gateway per coverage zone. For industrial deployments:
Indoor factories and warehouses: Metal structures, racking systems, and dense equipment attenuate signal. Plan for 3–5 gateways per 100,000 square feet for reliable Class A coverage at SF7–SF9. Fewer gateways running SF11–SF12 can cover the same footprint with higher airtime cost per device.
Outdoor terrain: A single gateway at elevation covers several kilometers in flat open terrain. For rolling terrain, wooded areas, or deployments with dense foliage, plan coverage with a margin — test actual RSSI across the footprint before finalizing gateway placement.
Mixed indoor/outdoor: Gateways mounted at roofline or on elevated structures provide both indoor and outdoor coverage from a single installation point. A gateway on the roof of a grain elevator covers both the elevator interior and the surrounding field.
LoRaWAN in the VX-Olympus Stack
IoT SimpleLink handles the LoRaWAN network layer — device authentication, gateway management, ADR, and data forwarding. VX-Olympus receives that data through the forwarding webhook and handles everything above the network layer: device management, rule chains, dashboards, alerts, and multi-tenancy.
The two platforms are designed to work together. IoT SimpleLink manages the radio network. VX-Olympus manages the application.
This separation is intentional. The network layer evolves on its own timeline. The application layer evolves on its own timeline. Upgrading one does not require rebuilding the other.
The Outcome
LoRaWAN does not solve every IoT connectivity problem. But for large-scale deployments where power, range, and cost per endpoint are the governing constraints — which describes most industrial IoT applications — it is the right answer.
Getting Started With LoRaWAN
The fastest path to a working LoRaWAN deployment:
- Define your coverage footprint and sensor locations
- Size your gateway infrastructure (use 1 gateway per 3–5 km radius outdoors, 1 per floor in dense indoor environments as a starting point)
- Select your sensor hardware from the 200+ LoRaWAN-compatible vendors supported by IoT SimpleLink
- Provision gateways and register devices in IoT SimpleLink
- Configure the HTTPS forwarding endpoint to VX-Olympus or your application backend
From provisioned gateways to first data delivery: under 2 hours.
Talk to our team about a network design review for your specific environment.