What Is LoRaWAN?

Back to Blog

How LoRaWAN Works

LoRaWAN uses LoRa, a spread-spectrum modulation on unlicensed sub-GHz ISM bands (868 MHz in Europe, 915 MHz in North America). End-device sensors transmit short messages to any gateway in range; the gateways forward those messages to a network server over the internet, which de-duplicates them and passes the data to the application. The topology is a star-of-stars: many cheap sensors, a few gateways, one network server.

The magic is the range-versus-rate trade. By increasing the spreading factor, a sensor can reach a gateway kilometers away, but the data rate falls - LoRaWAN payloads are tiny (tens of bytes) and slow (roughly 0.3 to 50 kbps). Devices spend almost all their time asleep and wake only to send, which is how a coin-cell or small battery can last years.

Where LoRaWAN Fits in Oil and Gas

LoRaWAN suits distributed, low-value-per-reading points where running power or cellular to each one is impractical: tank levels, wellhead pressure spot checks, cathodic protection readings, temperature, leak and vibration sensors across a pad or facility. One gateway can cover a whole site, aggregating dozens of sensors and backhauling their data over cellular or wired internet.

LoRaWAN is deliberately not a fit for high-bandwidth, low-latency, or fast control needs - it cannot carry a video feed or a rapid closed-loop signal. It complements, rather than replaces, cellular and radio telemetry. Because the gateway hands data up over standard IP, sensor readings can reach a cloud SCADA such as Merobix through MQTT once they leave the LoRaWAN network server.

Device Classes and What They Mean for Downlink

LoRaWAN defines three device classes, and the class determines when a device can hear the network. A Class A device listens only during two brief receive windows after each of its own uplinks - the rest of the time its radio is off, which is where the battery life comes from. Class B devices open additional scheduled receive slots synchronized to beacons from the gateway. Class C devices listen continuously, which makes them responsive to commands but effectively ties them to line power. Every certified device supports Class A; B and C are optional additions.

The practical consequence for monitoring work: a Class A tank-level sensor cannot be commanded on demand. A downlink - a configuration change, a new reporting interval - waits in a queue at the network server until the device next transmits and opens its receive windows. That is fine for slowly changing settings and completely wrong for anything resembling control. If a point genuinely needs prompt commands, either it needs Class C and a power source, or it should not be on LoRaWAN at all - a wired I/O point or a cellular RTU is the honest answer.

Activation and Keys: OTAA vs ABP

A LoRaWAN device authenticates with keys, and there are two ways to provision them. With OTAA (over-the-air activation) the device carries root keys and performs a join procedure each time it starts, deriving fresh session keys from the exchange. With ABP (activation by personalization) the session keys are programmed in at commissioning and never change. OTAA is the default choice for fielded fleets: keys rotate at each join, a device can move between networks without reflashing, and frame counters reset cleanly through the join procedure.

Whichever you use, key hygiene decides how painful the fleet is to operate. Record each device's identifiers and keys in a controlled inventory at commissioning, because recovering them from a potted sensor on a tank two hours from town is not a realistic plan. Duplicate or mistyped keys produce the most confusing failure in LoRaWAN - the device transmits, the gateway hears it, and the network server silently discards frames that fail the integrity check. When a sensor works on the bench but not in the field, checking the key inventory comes before checking the radio.

Planning Gateways, Antennas, and Backhaul

Coverage is decided mostly by gateway antenna height and terrain, not by transmit power, which regulation caps anyway. Survey with a test device at the actual sensor positions - inside a berm, against a steel tank shell, at grade behind equipment - because those readings can differ sharply from an open-air test a few meters away. Steel tanks, berms, and buildings cast radio shadows across a facility. Mounting the gateway antenna high and central usually solves more problems than any other single change, and because the network de-duplicates uplinks natively, adding a second gateway for shadowed corners and redundancy is straightforward.

The gateway is the site's single point of failure for the whole sensor fleet, so treat it like any other communications asset: give it a line in the site's power budget worksheet, surge protection, and a watchdog. Backhaul is typically cellular or wired internet, and the choice follows the same reasoning as any telemetry link - the trade-offs in cellular vs satellite vs radio telemetry apply unchanged. From the network server, readings move north over ordinary IP integrations into the SCADA or historian layer.

Operating a Fleet: A Troubleshooting Sequence

When a sensor goes quiet, work the chain in order rather than jumping to the radio:

1. Confirm the device has joined - the network server shows a successful join and recent uplinks.
2. Check the gateway: last-seen time, backhaul link state, and power.
3. Read the uplink signal quality and spreading factor the gateway logged for the device.
4. Look for frame-counter gaps, which mean uplinks are being lost in the air rather than never sent.
5. Verify the payload decoder - a wrong decoder produces plausible-looking nonsense values, not obvious errors.
6. Check the downlink queue for stale queued commands.
7. Trend the battery voltage where the device reports it.

Two patterns deserve special attention. A device stuck at the highest spreading factors is telling you its link is marginal - adaptive data rate has already backed it off as far as it can - and the fix is antenna height, another gateway, or relocating the sensor, not more retries. And confirmed uplinks everywhere are a false comfort: every confirmation costs a downlink and extra airtime, and across a large fleet it degrades the very reliability it is meant to buy. Use unconfirmed uplinks for routine readings and reserve confirmation for the few messages that matter, the same discipline behind report by exception.

Frequently Asked Questions