LoRa & LoRaWAN

Quick Cap

LoRa is a low-power, long-range wireless PHY layer based on Chirp Spread Spectrum (CSS) modulation — it defines how bits are transmitted over radio. LoRaWAN is the network protocol built on top of LoRa that defines device addressing, security, data rates, and the architecture connecting end devices to application servers through gateways and a network server. In embedded IoT, you almost always work with LoRaWAN, not raw LoRa — but understanding the PHY trade-offs (spreading factor, bandwidth, coding rate) is essential for optimizing range, battery life, and airtime.

Interviewers test whether you understand the LoRa vs LoRaWAN distinction, can articulate spreading factor trade-offs, know the three device classes and their power implications, and can compare LoRaWAN with other LPWAN technologies like NB-IoT and Sigfox.

Key Facts:

• LoRa = PHY layer (modulation); LoRaWAN = network protocol (MAC + security + architecture)
• Spreading Factor (SF7-SF12): Higher SF = longer range, lower data rate, more airtime, more power consumed per packet
• Range: 2-5 km urban, 10-15 km rural (line of sight), depending on SF and environment
• Data rate: 300 bps (SF12/125 kHz) to 11 kbps (SF7/250 kHz) — not for large payloads
• Device classes: A (lowest power, uplink-initiated), B (scheduled downlink windows), C (always listening, highest power)
• Duty cycle: EU868 mandates 1% or 0.1% duty cycle per sub-band — you cannot transmit continuously

Deep Dive

At a Glance

LoRa vs LoRaWAN: PHY vs Protocol Stack

This distinction is the first thing interviewers check. Getting it wrong signals a superficial understanding.

LoRa is the physical layer — the radio modulation technique. It is proprietary (owned by Semtech) and defines how a radio chip (SX1276, SX1262) converts bits into chirp signals. You can use LoRa without LoRaWAN for point-to-point links, but you lose all the network management, security, and scalability features.

LoRaWAN is the open network protocol (defined by the LoRa Alliance) that runs on top of LoRa. It provides:

• MAC layer: Channel access, duty cycle management, adaptive data rate
• Security: Two-layer AES-128 encryption (network session key + application session key)
• Network architecture: Star-of-stars topology with gateways, network server, join server
• Device management: Activation (OTAA/ABP), device classes, firmware updates (FUOTA)

End Device                Gateway           Network Server    App Server
  ┌──────────┐         ┌──────────┐         ┌──────────┐     ┌──────────┐
  │ Sensor   │  LoRa   │ Packet   │  IP     │ Routing, │ IP  │ Business │
  │ + Radio  │────────▶│ Forwarder│────────▶│ Dedup,   │────▶│ Logic    │
  │ (SX1262) │  (RF)   │ (SX1302) │ (TCP)   │ Security │     │          │
  └──────────┘         └──────────┘         └──────────┘     └──────────┘

Gateways are transparent — they do not filter or process payloads. They simply forward every LoRa packet they receive to the network server over an IP backhaul (WiFi, Ethernet, cellular). Multiple gateways may receive the same packet; the network server handles deduplication.

Spreading Factor, Bandwidth, and Coding Rate

These three parameters control the fundamental trade-off between range, data rate, airtime, and power consumption.

Spreading Factor (SF7-SF12): Each step up in SF doubles the airtime (and halves the data rate) while gaining roughly 2.5 dB of receiver sensitivity — translating to about 30-40% more range. Packets at different SFs are orthogonal, meaning SF7 and SF12 transmissions on the same channel do not interfere with each other.

Bandwidth (BW): Wider bandwidth = higher data rate but lower sensitivity (shorter range). 125 kHz is the standard for most LoRaWAN deployments. 250 kHz and 500 kHz are used for higher data rates at reduced range.

Coding Rate (CR): Forward error correction ratio — 4/5, 4/6, 4/7, or 4/8. Higher coding rates add redundancy for noisy environments but increase airtime. 4/5 is the default; 4/8 is used in harsh RF environments at the cost of nearly doubling the packet size.

LoRaWAN Device Classes

LoRaWAN defines three device classes that trade power consumption for downlink latency. This is one of the most asked LoRa interview questions.

Class A is the default and most common. The device sleeps until it has data to send, transmits an uplink, then opens two brief receive windows (RX1 after 1 second, RX2 after 2 seconds). If the server has a downlink, it must respond in one of these windows. After that, the device sleeps again — the server has no way to reach it until the next uplink.

Class B adds time-synchronized receive windows. The device listens for periodic beacons from the gateway to synchronize its clock, then opens "ping slots" at scheduled intervals. This allows the server to send downlinks without waiting for an uplink, at the cost of keeping the receiver on during ping slots.

Class C keeps the receiver on whenever the device is not transmitting. This provides the lowest downlink latency but consumes the most power — unsuitable for battery-powered devices unless the battery is very large or the device is mains-powered.

OTAA vs ABP Activation

Every LoRaWAN device must be activated before it can communicate. There are two methods:

Adaptive Data Rate (ADR)

ADR is the network server's mechanism for optimizing each device's SF, transmit power, and number of retransmissions based on link quality. The goal is to use the lowest SF (fastest rate, least airtime) and lowest transmit power that still deliver reliable communication.

How it works:

1. The device includes an ADR bit in its uplink frames, indicating willingness to accept ADR commands
2. The network server collects SNR and RSSI from the last 20 uplinks
3. Based on the link margin (measured SNR minus required SNR for current SF), the server calculates the optimal SF and transmit power
4. The server sends a LinkADRReq MAC command telling the device to change parameters
5. The device responds with LinkADRAns to confirm

ADR works well for stationary devices with stable link conditions. For mobile devices (asset trackers, vehicles), ADR can oscillate as the device moves through different RF environments. In practice, mobile devices either disable ADR or use it with a slower adaptation rate.

Duty Cycle Restrictions

LoRa operates on unlicensed ISM bands, which are subject to duty cycle regulations — the fraction of time a device can transmit.

Duty cycle limits are per sub-band, not per channel. A device that sends a 1-second packet on the 1% sub-band must wait 99 seconds before transmitting again on any channel in that sub-band. This is the primary bottleneck for LoRaWAN throughput and dictates how often you can send data. Planning your application's uplink frequency around these limits is essential.

LoRaWAN vs NB-IoT vs Sigfox

Debugging Story: The Disappearing Uplinks

A precision agriculture deployment with 200 soil moisture sensors reported 15% packet loss at the network server. RSSI and SNR values at the gateway were good (-90 dBm, +8 dB SNR). The sensors used SF10, which should provide ample link margin. The loss was not correlated with distance — close sensors dropped packets at the same rate as far ones.

The root cause was a duty cycle violation. The sensors were configured to transmit every 5 minutes at SF10 with a 30-byte payload. Each transmission consumed approximately 370 ms of airtime. On the EU868 1% sub-band, this allowed roughly 97 transmissions per hour — just above the required 12 per hour. But the firmware also retransmitted unacknowledged packets up to 3 times, pushing actual airtime to 4x the budget. When the device exceeded its duty cycle, it silently queued packets and eventually dropped them.

The fix was threefold: (1) reduce SF from 10 to 8 (ADR should have done this but was disabled during deployment), cutting airtime by 4x; (2) reduce retransmissions from 3 to 1 since the application could tolerate occasional packet loss; (3) enable ADR so the network server would optimize each device's SF based on actual link quality.

Lesson: Always calculate worst-case airtime including retransmissions and verify compliance with regional duty cycle limits before deployment. A link-budget calculation alone is not sufficient — duty cycle is often the binding constraint.

What interviewers want to hear: You clearly distinguish LoRa (PHY) from LoRaWAN (protocol). You understand the SF/BW/CR trade-offs and can explain why higher SF means more range but more power and airtime. You know all three device classes and can recommend the right one for a given power/latency requirement. You prefer OTAA over ABP and can explain why. You understand duty cycle regulations and how they constrain application design. You can compare LoRaWAN with NB-IoT and Sigfox and recommend the right technology for a given deployment scenario.

Interview Focus

Classic Interview Questions

Q1: "What is the difference between LoRa and LoRaWAN?"

Model Answer Starter: "LoRa is the physical layer — the CSS modulation technique proprietary to Semtech that converts bits into chirp signals on ISM bands. LoRaWAN is the open network protocol defined by the LoRa Alliance that runs on top of LoRa. It provides the MAC layer (channel access, duty cycle), security (two-layer AES-128), adaptive data rate, device classes, and the star-of-stars architecture with gateways, network server, and application server. You can use LoRa without LoRaWAN for point-to-point links, but you lose all the network management and security features."

Q2: "Explain the trade-off between spreading factors in LoRa."

Model Answer Starter: "Each step up in SF (7 to 12) doubles the airtime and halves the data rate, while gaining about 2.5 dB of receiver sensitivity — roughly 30-40% more range. SF7 gives 5.5 kbps and 36 ms airtime for a small packet; SF12 gives 250 bps and over 1 second airtime. The power cost is proportional to airtime, so SF12 uses 32x the energy of SF7 per packet. This is why ADR is important — it automatically selects the lowest SF that provides a reliable link, minimizing airtime and power consumption."

Q3: "What are the three LoRaWAN device classes and when would you use each?"

Model Answer Starter: "Class A is the default — lowest power, but the server can only send downlinks in two brief windows after each uplink. This is ideal for battery-powered sensors that rarely need downlink commands. Class B adds beacon-synchronized ping slots for scheduled downlinks — useful for actuators that need periodic commands but are still battery-powered. Class C keeps the receiver always on for minimum downlink latency — required for mains-powered devices like street lights or gateways that need to accept commands at any time."

Q4: "What is ADR and why might you disable it?"

Model Answer Starter: "ADR (Adaptive Data Rate) is the network server's mechanism for optimizing each device's spreading factor and transmit power based on measured link quality. It uses the SNR margin from the last 20 uplinks to determine if the device can use a lower SF (saving airtime and power) or needs a higher SF (improving reliability). I would disable ADR for mobile devices like asset trackers because the link quality changes constantly as the device moves — ADR would oscillate between parameters and cause packet loss during transitions."

Q5: "Why is OTAA preferred over ABP for LoRaWAN production deployments?"

Model Answer Starter: "OTAA generates fresh session keys with every join, providing forward secrecy — if a key is compromised, only the current session is exposed. ABP uses static keys programmed at manufacturing, so a single key compromise exposes all past and future data. OTAA also supports roaming (the device can join different networks) and makes key management scalable — you do not need to manually provision session keys for thousands of devices. ABP is simpler for lab testing but should never be used in production deployments."

Trap Alerts

• Don't say: "LoRa and LoRaWAN are the same thing" — LoRa is the PHY, LoRaWAN is the protocol stack. Conflating them signals a superficial understanding.
• Don't forget: Duty cycle constraints — they often limit application throughput more than the data rate itself, especially with retransmissions on the EU868 band.
• Don't ignore: The 222-byte payload limit — LoRaWAN is for small, infrequent telemetry, not file transfers or streaming. If the interviewer's scenario needs high throughput, recommend NB-IoT or cellular instead.

Follow-up Questions

• "How would you calculate battery life for a LoRaWAN Class A sensor sending data every 15 minutes?"
• "What happens when a LoRaWAN device exceeds its duty cycle budget?"
• "How does LoRaWAN handle packet deduplication when multiple gateways receive the same uplink?"
• "What is FUOTA (Firmware Update Over The Air) in LoRaWAN and what are its limitations?"

Practice

Real-World Tie-In

Precision Agriculture -- A vineyard deployed 300 LoRaWAN soil moisture sensors across 50 hectares with 3 gateways. Sensors used Class A at SF8 with ADR enabled, transmitting 12-byte readings every 30 minutes. Battery life exceeded 4 years on a single AA lithium cell. The key design decision was choosing LoRaWAN over cellular — no SIM cards, no subscriptions, and the private gateway infrastructure gave the vineyard complete data ownership.

Urban Asset Tracking -- A logistics company tracked 5,000 shipping containers across a port using LoRaWAN with GPS. Class A devices reported position every 15 minutes. The challenge was mobility — ADR struggled because containers moved between clear-sky docks and steel-walled warehouses. The solution was disabling ADR and fixing SF10 as a compromise between reliability and airtime, with 2 retransmissions for critical position reports.

Smart Building Metering -- A commercial building used LoRaWAN to read 400 water and electricity sub-meters. Class A devices sent 20-byte readings every hour through 2 indoor gateways. The 1% duty cycle was never a concern — hourly 20-byte packets at SF7 consumed less than 0.01% of the budget. The real challenge was indoor penetration through concrete floors, solved by placing gateways on every third floor rather than trying to cover the entire building from the roof.