What Is LoRaWAN? A Technical Deep Dive

If you’re evaluating LoRaWAN for your IoT deployment, understanding its strengths and limitations is essential. Lately, the protocol has gained traction—see the machineQ case study—which proves it works well for simple applications on public networks. However, for private, industrial, or enterprise deployments, several critical constraints arise that can hinder performance.

See example LoRaWAN Gateway for developers.

In this article, we’ll examine:

• The Difference Between LoRa & LoRaWAN
• How LoRaWAN Works
• LoRaWAN Classes A, B, & C
• Chirp Rate, Processing Gain, & Orthogonality
• Barriers to Building Private Networks With LoRaWAN
• An Alternative Solution: Symphony Link

The Difference Between LoRa & LoRaWAN

Many people conflate LoRa and LoRaWAN, but they serve distinct purposes. LoRa is a proprietary physical‑layer modulation created by Semtech. It is a chirped, multi‑symbol scheme that converts radio signals into bits without requiring developers to write low‑level radio code. LoRa is a flexible technology that can be embedded in a wide range of devices beyond LPWAN.

LoRaWAN is a point‑to‑multipoint networking stack built on top of LoRa. It defines how gateways and end nodes exchange encrypted, authenticated messages, manage duty cycles, and connect to a cloud backend. While LoRaWAN is popular on public networks, its design is not optimized for private industrial deployments.

Another open‑source alternative to LoRaWAN exists that may better suit your needs. Download the white paper for a detailed comparison.

How LoRaWAN Works

At its core, LoRaWAN follows a star topology: gateways act as central receivers and uplink transmitters, while end nodes broadcast to any gateway that can hear them. Imagine a classroom where the professor (gateway) speaks to the entire class (nodes), but students can only answer when the professor calls on them. The network is asymmetric; most traffic flows from nodes to gateways.

See example LoRaWAN Gateway for developers.

In practice, a node transmits a message on a pre‑determined frequency band. Any gateway that captures the packet forwards it to the cloud. Multiple gateways may receive the same message, which improves reliability because even if one link is weak, another may succeed. However, LoRaWAN does not acknowledge every packet. Nodes can request an ACK, and if more than one gateway hears the transmission, the cloud chooses one gateway to reply after a short, fixed delay. During this reply, the gateway stops listening, which can lead to lost downstream traffic if acknowledgements are frequent.

The diagram shows gateway activity: orange bars represent transmission periods, while blue bars indicate listening periods. LoRaWAN supports up to eight simultaneous receive channels, allowing nodes to send across multiple frequencies.

LoRaWAN Classes A, B, & C

LoRaWAN defines three device classes that balance power consumption, latency, and bandwidth:

• Class A – Purely asynchronous (Aloha). Nodes transmit whenever data is available and open two short receive windows after each uplink. Ideal for low‑power, battery‑operated devices with infrequent communication.
• Class B – Beacon‑driven. Every 128 s, gateways broadcast a beacon, synchronizing all Class B nodes. Nodes are assigned specific time slots for downlink, enabling scheduled communication while keeping power usage low.
• Class C – Continuous listening. Nodes keep the receiver on most of the time, allowing immediate downlink but consuming more power. Suited for mains‑powered devices that need near‑real‑time control.

Chirp Rate, Processing Gain, & Orthogonality

In LoRa, the spreading factor (SF) defines the chirp rate—the rate at which the carrier frequency sweeps across the band. A higher SF results in a slower chirp, which yields higher processing gain and longer range but lower data rate. Different SFs can coexist in the same frequency channel because they are orthogonal: the receiver can distinguish them without interference. This orthogonality underpins LoRa’s ability to support many devices on a single channel.

Barriers to Building Private Networks With LoRaWAN

LoRaWAN excels on public networks, but its architecture imposes challenges for private, enterprise deployments:

• Shared spectrum leads to interference. All gateways, regardless of ownership, operate on the same channels, creating potential collisions. While the LoRa Alliance can designate exclusive channels, the practical coexistence of many networks in a region remains problematic.
• Unreliable delivery. LoRaWAN’s Aloha‑based MAC can suffer packet error rates above 50 % in congested environments. Industrial applications that demand 0 % PER find this unacceptable.
• Fragmented ecosystem. LoRaWAN covers only the MAC layer; vendors must integrate chips, gateways, backends, and application layers themselves. This increases development time and complexity.
• Duty‑cycle restrictions. In Europe’s 868 MHz band, gateways are limited to a 1 % duty cycle, capping uplink traffic. The U.S. ISM band has no such limit, but the constraint remains a consideration for multi‑country deployments.
• Variable MTU. The payload size depends on the SF assigned by the network, which can change based on distance and channel conditions. Nodes must adapt to unpredictable MTU limits, often defaulting to the smallest possible size (<12 bytes). This fragmentation inflates the number of transmissions required for larger payloads.

LoRaWAN is suitable for low‑density, low‑latency public networks. When scaling to thousands of devices with demanding reliability or latency requirements, the aforementioned constraints become significant bottlenecks.

An Alternative Solution: Symphony Link

Symphony Link is a proprietary LoRa‑based stack developed by Link Labs, engineered to address LoRaWAN’s shortcomings. Key advantages include:

• Bidirectional, guaranteed delivery. ACKs are mandatory, ensuring 100 % message receipt in both uplink and downlink.
• Dynamic channel masking. The gateway controls channel allocation, allowing up to 48 gateways to coexist with minimal collision.
• No duty‑cycle limits. By operating in the 900 MHz band (Europe), Symphony Link removes the 1 % duty‑cycle restriction.
• Fixed 256‑byte MTU. This consistent payload size eliminates fragmentation overhead and simplifies firmware design.
• End‑to‑end solution. From chips to gateways to cloud, the stack is ready out of the box, reducing integration effort and time to market.

Learn more on our website or schedule a free demo to see how Symphony Link can meet your specific LPWA requirements—gateway setup, dev kit integration, power budgeting, and range performance are all covered.