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:
| Strengths | Honest limits |
|---|---|
| Long range — several kilometres from one gateway, more in open terrain | Low data rate — small payloads, infrequent; no streaming |
| Multi-year battery — Class A sensors run for years on a single cell | Not for rich or high-frequency data — no video, no high-rate vibration waveforms |
| Low cost per device — no SIM, no per-message carrier fee on a private network | Duty-cycle limits — licence-exempt bands cap how much airtime each device may use |
| Private network you own — your gateway, your data, your coverage map | Penetration limits — deep indoor, underground or heavily shielded sites still need careful gateway placement |
| Open standard — multi-vendor devices and servers, no single-operator lock-in | You run the infrastructure — the gateway is yours to power, site and maintain |
The shape that fits LoRaWAN: many cheap sensors, spread over an area you control, each sending a small reading every few minutes to hours, that must run for years untouched. Tank levels, flow pulses, soil moisture, pressure, temperature, valve states, GPS-light asset pings. If your data is large, fast or continuous, LoRaWAN is the wrong tool — reach for cellular or wired instead.