When to Use the LoRaWAN Specification: A Practical Guide for MNO and Private Network Deployments

LoRaWAN, crafted by the LoRa Alliance, is the wireless protocol that governs LoRa LPWA technology from Semtech. Initially developed by IBM Research and Semtech for European mobile network operators (MNOs) operating wide‑area public networks, the specification is now maintained by the LoRa Alliance—a coalition dedicated to deploying LoRaWAN across global MNO networks. Consequently, the spec embodies assumptions tailored to MNO environments.

Several key design assumptions underpin the LoRaWAN specification, clarifying its intended use cases:

• All frequency channels are fixed.
  Because the spec was designed for a single MNO network, operating multiple uncoordinated networks in the same band can lead to Layer‑2 interference. For a deeper dive, read this blog post for more information.
• The network is completely asynchronous. Whenever a gateway is transmitting, it cannot listen for uplink traffic, and nodes remain unaware that the gateway’s receiver is offline. In large MNO deployments, the presence of multiple gateways—ideally one in “listen” mode—helps mitigate this limitation.

Other implicit assumptions, such as the security model, also make LoRaWAN suitable for MNOs, but we’ll focus on the most critical ones here.

You should adopt the LoRaWAN specification in your project if both of the following conditions are met:

1. There is a need to connect to an existing LoRaWAN MNO network. Obviously, connecting to an MNO network without using LoRaWAN is impossible.
2. The use case is low‑density, infrequently transmitting, and uplink‑centric. LoRaWAN excels when downlink traffic and acknowledgements are minimal. Automatic meter reading (AMR) is a prime example—most meters don’t require frequent reads, and the available gateway density typically provides sufficient uplink capacity. Ideally, no other LoRaWAN networks should operate nearby, as interference would degrade performance. EnerTrac/Senet’s heating‑oil and propane‑tank monitoring service demonstrates LoRaWAN’s suitability for such scenarios.

When to avoid the LoRaWAN specification:

1. High reliability is essential. LoRaWAN’s uncoordinated, asynchronous design makes it a lossy protocol. In environments with multiple LoRaWAN networks, interference increases packet‑error rates. Additionally, LoRa’s limited co‑channel dynamic range means that nodes close to a gateway can drown out those farther away without closed‑loop power control.
2. Centralized key management is required. Each node must be provisioned with a unique set of keys at the factory, which must then be transferred to the server or gateway. For small deployments this is manageable, but for thousands of devices it inflates cost and complexity. MNOs manage this complexity through SIM‑like mechanisms; private networks often find it cumbersome. For a deeper dive into LoRaWAN’s key structure and security, see this independent analysis.
3. Coverage expansion via repeaters is needed. The LoRaWAN spec offers no repeater support, so you must deploy additional internet‑connected gateways. Even low‑cost DIY gateways can be 5–10× more expensive than a simple repeater.
4. Over‑the‑air firmware updates are required. LoRaWAN’s limited downlink capacity prevents efficient multicast firmware updates. Devices would need physical upgrades or a design that eliminates firmware updates.

Link Labs addresses many of these limitations. Learn more about Symphony Link, the de‑facto standard for private LoRa networks, click here.