addaNet and LoRaWAN share the same physical hardware and radio frequencies, but they differ fundamentally in how they manage the wireless channel. Choosing between them is primarily a decision about network ownership and reliability at scale.
The Core Difference: Channel Access Method
LoRaWAN uses an ALOHA-based random access method. Devices transmit whenever they have data and retry if no acknowledgement is received. This works well at low network densities, but as the number of devices on the same channel grows, collisions increase and packet delivery rates fall — the network degrades.
addaNet uses a time-slot scheduling approach. The gateway assigns each device a specific transmission window, so no two devices transmit simultaneously. Collisions are structurally eliminated. As more devices join the network, throughput scales linearly rather than degrading.
Quick Comparison
| Feature | addaNet | LoRaWAN |
|---|---|---|
| Protocol type | Private / proprietary | Open standard (LoRa Alliance) |
| Channel access | Time-slot scheduling (no collisions) | ALOHA random access (collisions possible) |
| Scalability | Performance stable as network grows | Degrades when device density is high |
| Network ownership | Your own private infrastructure required | Private or public networks (TTN, etc.) |
| Hardware | Same addaN4 nodes and addaG2 gateway | Same addaN4 nodes and addaG2 gateway |
| Frequency | EU433 / EU868 | EU433 / EU868 |
| Interoperability | addanode ecosystem only | Any LoRaWAN-certified device or server |
Same Hardware, Switchable Protocol
Because both protocols run on identical addaN4 nodes and the addaG2 gateway, you are not locked into a hardware decision. A firmware configuration change switches a deployed network from LoRaWAN to addaNet mode — or back — without replacing any equipment. This matters in practice: a pilot deployed over LoRaWAN can migrate to addaNet when the site grows beyond the point where collision avoidance becomes necessary.
When to Choose addaNet
- You are deploying more than 20–30 devices in a single coverage area and need guaranteed delivery rates.
- The application is critical — process monitoring, alarm systems, or metering where missed readings have operational consequences.
- You want a fully private network with no dependency on public infrastructure or third-party servers.
- You need deterministic latency — knowing exactly when each device will report.
When to Choose LoRaWAN
- Device count is low and collision risk is negligible.
- You need interoperability with third-party LoRaWAN sensors or servers.
- The project connects to an existing public or shared LoRaWAN network.
- Standard LoRaWAN certification is a procurement or regulatory requirement.
The South African Context
South Africa has limited public LoRaWAN network coverage outside major urban centres, which means most industrial deployments run private infrastructure regardless of protocol choice. In that context, the operational advantage of addaNet’s collision-free scheduling often outweighs the interoperability benefit of LoRaWAN — particularly for mining, agriculture, and utility applications where sites are remote and device counts are high.
addanode hardware supports both protocols and can be configured for either at deployment. Contact us to discuss which approach fits your specific site and device density.
Explore related solutions
Use this documentation together with the related addanode solution pages to compare fit, plan deployment, and continue your research.
