LoRaWAN in South Africa: how it works and when to use it

Who this is for

Engineers and operations managers in South Africa who keep hearing "LoRaWAN" as the answer to remote sensing and want to understand it properly — what it actually is, how a LoRaWAN network is built, what it is genuinely good and bad at, and where it earns its place on real water, agriculture and mining sites. This is the deep dive on LoRaWAN specifically; for the head-to-head against other networks, see our full connectivity comparison.

What LoRaWAN actually is

Two things share the name and it helps to separate them. LoRa is the radio modulation — a chirp-spread-spectrum technique that trades data rate for sensitivity, so a tiny transmitter can be heard several kilometres away even below the noise floor. LoRaWAN is the open networking protocol, governed by the LoRa Alliance, that sits on top of LoRa radio and defines how devices join a network, how messages are addressed and encrypted, and how gateways and servers route traffic. You can have LoRa radio without LoRaWAN, but in practice the two travel together.

Both belong to the LPWAN family — low-power wide-area networks built for the opposite of broadband. Instead of moving lots of data over short hops at high power, LPWAN moves small amounts of data over long distances at very low power. That single trade-off explains almost everything about where LoRaWAN fits and where it does not.

LoRaWAN runs in licence-exempt sub-gigahertz ISM bands, and the band differs by region. In South Africa deployments commonly use the 868 MHz (EU868) band under ICASA's licence-exempt allocation, which means no per-site spectrum licence to operate your own network. Because regional band plans and duty-cycle rules can change and overlap, operators should always confirm the current ICASA band, channel plan and duty-cycle limits for their specific deployment before fixing hardware.

How a LoRaWAN network works

A LoRaWAN network has four moving parts, and the data flows in one direction through them:

• End devices (the sensors). Battery-powered nodes — a water meter, a tank-level probe, a soil-moisture sensor — that wake up periodically, send a small reading, and go back to sleep. They broadcast; they are not paired to one gateway.
• Gateways. Always-on receivers that listen for any device in range and forward every packet they hear up to the network server over a backhaul link (usually 4G, fibre or Ethernet). A device's message can be picked up by several gateways at once; that redundancy is a feature, not waste.
• Network server. The brain. It de-duplicates packets heard by multiple gateways, checks message integrity, manages security keys, handles device joins, and tunes each device's data rate.
• Application server. Decrypts the payload and hands the actual reading to your platform — in our case addaNet — for dashboards, alerts and trends.

Device classes, ADR and joining

A few LoRaWAN concepts decide how a device behaves, and getting them right is most of the design work:

• Device classes A, B and C. Class A is the default and the most power-frugal: the device transmits, then opens two brief receive windows, then sleeps — so the network can only talk back just after the device talks first. Class B adds scheduled receive slots synced to gateway beacons, for more predictable downlinks. Class C keeps the receiver open continuously for near-instant downlink, at the cost of battery — so it suits mains-powered devices like actuators. Most field sensors are Class A.
• Adaptive Data Rate (ADR). The network nudges each device toward the best balance of range and airtime — devices close to a gateway use a faster data rate and shorter transmissions, distant ones slow down for reach. ADR is what makes battery life and capacity work at scale.
• OTAA vs ABP. Over-the-Air Activation (OTAA) has the device negotiate fresh session keys each time it joins — more secure and the recommended default. Activation By Personalisation (ABP) hard-codes the session into the device; simpler to provision but weaker, since keys never rotate. For anything beyond a quick bench test, prefer OTAA.

What LoRaWAN is good and bad at

LoRaWAN is a sharp tool with a narrow edge. Honest about both sides:

Where LoRaWAN fits in South Africa

Local conditions — wide rural distances, patchy cell coverage, sites you'd rather not run a SIM in — play directly to LoRaWAN's strengths. The use cases where we see it earn its keep:

• Water metering and non-revenue water. Bulk and zonal meters across a reticulation network, reporting consumption and flow so leaks and losses surface in hours rather than at month-end. This is core to water management and NRW reduction, where SA losses run high.
• Boreholes and reservoirs. Level, pressure and pump-status telemetry from sites that are kilometres from any building, let alone fibre — one gateway can cover a whole scheme.
• Agriculture and irrigation. Soil moisture, weather and valve telemetry across a farm, feeding automated irrigation so water and energy go only where the crop needs them.
• Environmental and remote sensing. River levels, rainfall, effluent and air-quality nodes across a catchment or a mine's footprint, where running power and cellular to every point is impractical.
• Asset tracking. Low-frequency location and presence pings for equipment and containers across a yard or site — light on data, long on battery.

Many of these sites are also off-grid or grid-unreliable, which is why LoRaWAN pairs so naturally with solar-powered remote monitoring — a few watts run a sensor for years.

Public vs private LoRaWAN networks

You can connect to LoRaWAN two ways. A public network lets you place devices and pay an operator to carry the traffic over their gateways — quick to start, no infrastructure to own, but you depend on their coverage map and pricing. A private network means you deploy your own LoRaWAN gateway (or several) and run, or rent, the network server — you own the coverage, the data path and the recurring cost.

For a single municipal scheme, a farm or a mine — a defined area you control — a private network usually wins. One gateway with a clear line of sight covers a surprising radius, you are not at the mercy of an operator's footprint reaching your remote pump station, and there is no per-message fee. The trade-off is real: that gateway is yours to site, power and keep online. On a site with grid issues, that means a small UPS or solar on the gateway and a resilient backhaul, exactly as you'd design any critical edge node.

Is LoRaWAN secure?

Security is built into the LoRaWAN specification rather than bolted on. Every payload is encrypted end to end with AES-128, and the protocol uses two separate keys derived at join time: a network session key that protects message integrity and routing between the device and the network server, and an application session key that encrypts the actual sensor payload so only your application server can read it. Because the application key is separate, even the network operator carrying your traffic cannot see your data. Using OTAA so those session keys are freshly negotiated on each join — rather than static ABP keys — and protecting the root keys during provisioning are the practical steps that keep that design honest in the field.

LoRaWAN vs NB-IoT, 4G and Sigfox — the short version

Choosing LoRaWAN is really choosing it against the alternatives, and the answer is per site, not per brochure. In brief: pick LoRaWAN when you have many low-data sensors across an area you control and want to own the network and the battery budget. Pick 4G/LTE when you have a few richer devices anywhere with signal and don't want to run a gateway. Pick NB-IoT for low-data sensors where your carrier has actually deployed it — coverage is uneven, so verify per location. LoRaWAN vs NB-IoT often comes down to one question: do you want to own the network (LoRaWAN) or rent the carrier's (NB-IoT)? Sigfox is simplest and cheapest for tiny payloads but ties you to one operator. We unpack all of this — coverage, cost, power and load-shedding resilience — in the full connectivity comparison.

LoRaWAN through load shedding

A LoRaWAN sensor sips so little power that a small battery rides out any outage without noticing. The vulnerable link is the always-on infrastructure: the gateway and its backhaul. If the gateway loses power or its 4G tower goes dark during a slot, devices keep transmitting but nothing is being heard. The fix is the same edge discipline we apply everywhere — a small UPS or solar on the gateway, and buffering so a brief gap doesn't lose data — covered in our load-shedding protection guide. Design the gateway as a critical node and LoRaWAN becomes one of the more resilient options on an unreliable grid.

LoRaWAN is not a silver bullet, and it is not "better than cellular" — it is a precise fit for a specific shape of problem that South African water, agriculture and remote-monitoring sites throw up constantly. Get the device class, activation and gateway siting right, design the gateway for outages, and a handful of low-cost sensors will report faithfully for years across ground that would defeat almost anything else.

Frequently asked questions