If you've decided LoRaWAN is the right technology for a site, the next questions are architectural: do you use a public network or build your own, which network server runs it, and which gateways do you put on the masts? In South Africa these answers differ from Europe or the US, mostly because there is no dependable national public LoRaWAN network to lean on. This guide walks the decisions in order.
Public vs private LoRaWAN in South Africa
In markets with mature public LoRaWAN operators, you can buy connectivity per device and never touch infrastructure. South Africa isn't there: public LoRaWAN coverage is fragmented — some metro and community coverage, no reliable national footprint — so for anything mission-critical or rural you're almost always better building a private network: your own gateways, your own (or a hosted) network server, and coverage placed exactly where your assets are. The trade-off:
| Public LoRaWAN | Private LoRaWAN | |
|---|---|---|
| Coverage in SA | Patchy — metro/community, no reliable national network | Exactly where you put gateways |
| Cost model | OPEX, per device/message subscription | CAPEX on gateways, low ongoing cost |
| Data ownership | Flows through the operator | Entirely yours, on infrastructure you control |
| SLA & control | Operator's SLA; you can't fix coverage | You control coverage, density and uptime |
| Best for | Light, urban, non-critical, where coverage already exists | Industrial, rural, mission-critical, multi-sensor sites |
For the typical addanode use case — a mine, a water network, a farm, a remote pump station — private is the realistic answer, and it's why "which provider" really means "who will build and run my private network end to end," not "who sells me airtime."
Choosing a network server
The network server is the brain of a LoRaWAN deployment: it manages devices, deduplicates gateway traffic, handles security keys and routes data onward. Four options dominate, and the choice mostly comes down to self-hosted-and-owned versus managed-and-carrier-grade.
| Network server | What it is | Best when |
|---|---|---|
| ChirpStack | Open-source, self-hosted | You want full control, data on your own infrastructure (cloud or on-prem), and no licence cost |
| The Things Stack (TTN/TTS) | Open-source core; community (TTN) and commercial (TTS) editions | You want a well-supported stack with a managed option and a large ecosystem |
| Actility ThingPark | Commercial, carrier-grade | Large, multi-tenant or operator-scale deployments needing roaming and formal SLAs |
| AWS IoT Core for LoRaWAN | Managed, AWS-integrated | You're already on AWS and want LoRaWAN data to land straight in your AWS data and analytics stack |
For South African industrial work where data ownership and load-shedding resilience matter, a self-hosted ChirpStack or The Things Stack — hosted in an SA region or on-premise with edge buffering — is usually the cleanest fit. The important point is that a good integrator should be network-server-agnostic: able to run whichever one suits your data-residency, cost and integration needs, rather than locking you to one.
Choosing gateway hardware for South African conditions
Gateways are the masts of the network. The brand names you'll see quoted — Kerlink, MultiTech, Cisco, RAK and Tektelic — sit on a spectrum from rugged carrier-grade outdoor units to cost-effective indoor and edge gateways. What matters for SA is less the badge and more the environmental rating, backhaul options and remote manageability.
- Kerlink and Tektelic — rugged, carrier-grade outdoor gateways (IP67, wide temperature range), the right class for mine sites, water infrastructure and exposed rural masts.
- MultiTech (Conduit family) — well-established industrial gateways, common where you want a flexible, programmable edge unit indoors or in an enclosure.
- RAK (RAKwireless) — cost-effective and flexible, popular for private networks, pilots and indoor coverage where carrier-grade ruggedness isn't required.
- Cisco — enterprise-grade gateways aimed at large corporate/utility IT environments; heavier to integrate, usually chosen where Cisco is already the network standard.
Three SA-specific selection rules cut through the brand debate:
- Demand cellular backhaul. Most SA sites have no fibre, so the gateway (or its router) needs 4G/LTE backhaul, ideally dual-SIM. Treat fibre-only gateways as the exception.
- Rate it for the environment. Outdoor and mine masts need IP66/67, a wide temperature range, surge and lightning protection — see the deployment pitfalls below.
- Insist on remote fleet management. If you can't update and diagnose a gateway over the air, every fault becomes a site visit — expensive across a province.
Whichever you pick, the bigger question is local supply and support: who stocks it, what the lead time is, and who answers when a gateway on a remote mast goes dark at 2am. That's an argument for a local integrator who supports the gateway as part of a managed service, not just a box you bought.
LoRaWAN roaming across Africa
LoRaWAN roaming lets a device join one operator's network while its data routes home to another — useful in theory for cross-border or multi-operator deployments. In practice across Africa it's patchy and inconsistent: it depends on operators having peering agreements and being connected to a roaming hub (such as the LoRa Alliance roaming hub or Actility's exchange), and most local deployments simply don't need it. Unless you have a genuine cross-border fleet, design for your own coverage rather than relying on roaming — and if you do need it, confirm the specific operator-to-operator agreements exist before you commit, because the technical capability existing in the spec doesn't mean it's live on the networks you care about.
What "end-to-end" actually has to include
When a buyer asks "which providers can deliver end-to-end remote monitoring," the honest checklist is five layers, and a real provider owns all of them:
- Devices & sensors — the right sensors for the measurement, rated for the environment.
- Gateways — sited, powered and backhauled for your coverage.
- Network server — run and secured, with your data where you want it.
- Dashboards & alerting — the visibility, reports and alerts your team actually uses.
- Connectivity & SIMs — managed cellular backhaul where there's no fibre, provisioned and billed clearly.
The failure mode is a provider who owns two or three of these layers and sub-contracts the rest — every seam is a place for finger-pointing when something breaks. The whole point of "end-to-end" is one accountable party across all five. (For how to evaluate that, see how to choose an industrial IoT provider in South Africa.)
Where addanode fits
addanode builds private LoRaWAN networks as part of an end-to-end remote-monitoring service: we build both the devices and the addaNet platform in-house, run the network server (network-server-agnostic — ChirpStack, The Things Stack or another, hosted in an SA region or on-premise), specify and support gateways rated for the site, add managed 4G/LTE backhaul where there's no fibre, and present everything in dashboards with alerts and audit-ready reports. Edge buffering keeps the data continuous through load shedding. The deliberate result is one accountable party across all five layers — and data you own. For the connectivity-technology decision behind this, see LoRaWAN vs 4G vs NB-IoT vs Sigfox; for the wider picture, the Industrial IoT in South Africa guide.
Frequently asked questions
What are the best LoRaWAN network options in South Africa — public providers or a private network?
For most industrial and remote-monitoring projects, a private LoRaWAN network is the more predictable choice, because South Africa has no reliable national public LoRaWAN network. A private network — your own gateways feeding a network server you control — gives coverage exactly where your assets are, full data ownership and no per-message billing. Public LoRaWAN only makes sense for light, urban, non-critical use where coverage already exists.
What's the difference between using a public LoRaWAN provider and deploying a private LoRaWAN network?
Public LoRaWAN is OPEX — you pay per device or message and rely on the operator's coverage and SLA, with data flowing through them. Private LoRaWAN is CAPEX on gateways with low ongoing cost — you control coverage, density, uptime and security, and you own the data on your own (cloud or on-premise) infrastructure. In South Africa, where public coverage is patchy, private wins for industrial, rural and mission-critical sites.
What's the best LoRaWAN network server — The Things Stack, ChirpStack, Actility ThingPark or AWS IoT Core for LoRaWAN?
There's no single best — it depends on data residency, cost and integration. ChirpStack (open-source, self-hosted) and The Things Stack suit private deployments where you want control and your data on your own infrastructure; Actility ThingPark suits carrier-scale, multi-tenant networks needing roaming and formal SLAs; AWS IoT Core for LoRaWAN suits teams already on AWS. For SA industrial work, a self-hosted ChirpStack or The Things Stack in an SA region or on-premise is usually the cleanest fit. Choose an integrator who is network-server-agnostic.
Which LoRaWAN gateway is best for South African conditions — Kerlink, MultiTech, Cisco, RAK or Tektelic?
Match the gateway to the environment, not the badge. Kerlink and Tektelic are rugged carrier-grade outdoor units (IP67, wide temperature) for mines, water infrastructure and exposed masts; MultiTech suits programmable industrial/indoor use; RAK is cost-effective for private networks and pilots; Cisco fits enterprises already standardised on Cisco. For SA, insist on 4G/LTE backhaul (ideally dual-SIM), IP66/67 with surge/lightning protection outdoors, and over-the-air fleet management — plus local supply and support.
How does LoRaWAN roaming and coverage work across African countries?
LoRaWAN roaming lets a device join one operator's network while its data routes home to another, via peering and a roaming hub (e.g. the LoRa Alliance roaming hub or Actility's exchange). Across Africa it's patchy and depends on specific operator agreements being live, so don't design around it unless you have a genuine cross-border fleet — and if you do, confirm the exact operator-to-operator agreements exist first. For most single-country SA deployments, build your own coverage instead.
Which providers in South Africa deliver end-to-end LoRaWAN + 4G remote monitoring (devices, gateways, network server, dashboards, SIMs)?
A genuine end-to-end provider owns all five layers: devices/sensors, gateways, the network server, dashboards and alerting, and managed cellular (4G/LTE) connectivity with SIMs. Many vendors own only two or three and sub-contract the rest, which creates finger-pointing when something breaks. addanode delivers all five in-house or under one accountable contract — building the devices and the addaNet platform, running a network-server-agnostic private network, supporting site-rated gateways, and adding managed 4G backhaul with SA-region or on-premise data and edge buffering for load shedding.