19  LoRaWAN Architecture

In 60 Seconds

This review chapter reinforces LoRaWAN’s star-of-stars architecture (end devices to transparent gateways to network server) and the three device classes: Class A (uplink-initiated receive windows, lowest power), Class B (beacon-synchronized ping slots, predictable downlink), and Class C (continuous listening, mains-powered). Use the worked examples to practice selecting the right class and calculating downlink latency for real scenarios.

19.1 Learning Objectives

By the end of this chapter, you will be able to:

  • Explain Star-of-Stars Topology: Justify why gateways act as transparent relays and how the network server performs deduplication and routing
  • Classify Device Classes: Distinguish between Class A, B, and C based on receive window behaviour, latency, and power consumption
  • Calculate Downlink Latency: Derive expected response times for each device class given beacon intervals and ping slot schedules
  • Architect Multi-Gateway Deployments: Design redundant coverage layouts using the multi-gateway packet delivery probability formula
  • Assess Class Trade-offs: Defend device class selection decisions for specific IoT applications with quantitative battery-life and latency evidence

19.2 Prerequisites

Required Chapters:

Key Concepts

  • Device Class Selection: Choosing Class A, B, or C based on application requirements for downlink latency, power budget, and connectivity type (battery vs. mains).
  • Star-of-Stars Review: LoRaWAN two-tier topology with gateways forwarding to network server; enables redundancy, coverage diversity, and centralized intelligence.
  • Class A Operation: Default mode for all LoRaWAN devices; opens RX1 (1 second after TX) and RX2 (2 seconds after TX) receive windows; achieves lowest power consumption.
  • Class B Synchronization: Beacon-driven synchronized receive slots; devices use GPS-synchronized beacons to align ping slots with the network server schedule.
  • Class C Always-On: Continuous listening except during transmission; enables sub-second downlink latency for actuators and controllers; requires constant power supply.
  • Gateway Selection: Criteria for choosing LoRaWAN gateway hardware including coverage radius, backhaul options, power source, and management interface.
  • Architecture Review Questions: Common exam topics including topology components, device class trade-offs, activation methods, and network server functions.

Related Review Chapters:

Chapter Focus
Security & ADR Review Encryption, adaptive data rate
Deployment Review Regional parameters, TTN, troubleshooting

Estimated Time: 15 minutes

What is Star-of-Stars? Imagine a hub-and-spoke system, but with multiple hubs. Your sensor (end device) talks to multiple nearby gateways. All gateways report to a central network server.

Why This Design?

  • Reliability: If one gateway fails, others still receive your message
  • Range: Gateways can be spread across a wide area
  • Simplicity: End devices don’t need to know which gateway to use

Everyday Analogy: Think of a postal system. You can drop a letter in any mailbox (gateway), and it all goes to the central sorting facility (network server) before reaching its destination (application server).

“Let us review the LoRaWAN architecture!” Sammy the Sensor said. “The star-of-stars design means I talk to gateways, gateways talk to the network server, and the network server talks to the application. Multiple gateways can hear my signal at once, providing automatic redundancy without any extra effort from me!”

“Device classes are all about when you listen,” Lila the LED explained. “Class A only opens two tiny receive windows right after sending – maximum battery life. Class B adds scheduled beacon windows for predictable downlink timing. Class C listens all the time, which drains the battery fast but allows instant commands from the server.”

Max the Microcontroller added, “Most IoT sensors should use Class A. It provides the best battery life because the device sleeps between transmissions. Class B is for applications like street lights that need periodic commands at known times. Class C is for mains-powered devices like industrial actuators that need to respond immediately.”

“Remember: choose the simplest class that meets your downlink needs,” Bella the Battery advised. “If your sensor only sends data and rarely needs commands, Class A is perfect. The longer I can sleep between transmissions, the longer I last. That is the fundamental trade-off in LoRaWAN device design!”

19.3 Network Architecture

19.3.1 Star-of-Stars Topology

LoRaWAN star-of-stars network topology showing multiple end devices communicating with multiple gateways via LoRa RF links. Devices 1-4 send messages that are received by 1-3 gateways simultaneously (shown with dotted lines), providing redundancy. All gateways connect via IP/Ethernet to a central Network Server that performs deduplication and Adaptive Data Rate management. Network Server coordinates with Join Server for OTAA device activation and Application Server for business logic and data delivery.
Figure 19.1: LoRaWAN Star-of-Stars Network Architecture with Multi-Gateway Coverage

19.3.2 Network Components

Component Role Scalability Key Functions
End Device Sensor/actuator node 1000s per gateway Data collection, transmission
Gateway RF relay (transparent) Multiple per area Packet forwarding, no processing
Network Server Protocol management Region-wide Deduplication, ADR, routing
Application Server Business logic Application-specific Data processing, storage, APIs
Join Server Security provisioning Global OTAA, key generation

19.3.3 Gateway Role: Transparent Relay

Key Concept: Gateways Are “Dumb” Relays

Gateways do NOT: - Decrypt or read packet contents - Make routing decisions - Filter or process data - Authenticate devices

Gateways ONLY: - Receive LoRa packets - Add metadata (RSSI, SNR, timestamp) - Forward to network server over IP

This simplicity enables low-cost gateway hardware and easy scaling.

19.3.4 Network Server Functions

Network server function flow showing packet processing from gateway reception through deduplication (removes copies from multiple gateways), security verification (checks MIC, decrypts MAC layer), ADR optimization (adjusts SF and power), MAC command processing (device configuration), and routing to deliver data to the correct application server.
Figure 19.2: Network Server Core Functions in LoRaWAN Architecture

19.4 Device Classes

19.4.1 Class Comparison Diagram

LoRaWAN device class comparison showing three classes with power-latency trade-offs. Class A (green) offers lowest power with RX windows only after TX, achieving 5-10 year battery life for sensors and meters. Class B (orange) provides scheduled RX using ping slots and GPS-synced beacons, achieving 1-3 years for street lighting. Class C (red) runs continuous RX for lowest latency with days to weeks battery life, suitable for mains-powered actuators and controllers.
Figure 19.3: LoRaWAN Device Classes A, B, C: Power vs Latency Trade-offs

19.4.2 Detailed Class Comparison

Feature Class A Class B Class C
Downlink Latency High (until next uplink) Medium (ping slot schedule) Lowest (almost immediate)
Power Consumption Lowest (best for battery) Medium (periodic wake) Highest (continuous RX)
RX Windows 2 short windows after TX Scheduled ping slots + RX1/RX2 Continuous (except TX)
Beacon Required No Yes (GPS-synced) No
Typical Battery Life 5-10 years 1-3 years Days to weeks (must be powered)
Use Cases Sensors, meters, trackers Street lights, irrigation Actuators, controllers
Complexity Simplest Medium Simple
Bidirectional Yes (limited downlink) Yes (scheduled) Yes (any time)

19.4.3 Class A: Receive After Transmit

Class A timing diagram showing uplink transmission followed by two receive windows. RX1 opens 1 second after uplink on the same frequency. RX2 opens 2 seconds after uplink on a fixed frequency with SF12. After RX2 closes, the device sleeps until the next uplink, which may be hours or days later. This minimizes power consumption for battery-powered sensors.
Figure 19.4: Class A Receive Window Timing After Uplink Transmission

19.4.4 Class Selection Decision Tree

LoRaWAN device class selection decision tree starting with downlink requirement. If no downlink needed, use Class A for best battery life. If downlink needed, check latency requirements: if sub-second latency needed, must use Class C with continuous RX (requires mains power). If seconds latency acceptable, check if schedule is predictable: if yes, use Class B with beacon sync (1-3 year battery); if no and mains power available use Class C, otherwise accept delays with Class A.
Figure 19.5: LoRaWAN Device Class Selection Decision Tree

19.4.5 Class B: Beacon-Synchronized Receive

How Class B Works
  1. Gateway broadcasts GPS-synchronized beacons every 128 seconds
  2. Device wakes to receive beacon and synchronize clock
  3. Device calculates ping slot times based on DevAddr
  4. Device opens receive windows at calculated ping slots
  5. Network server queues downlinks for device’s ping slots

Advantage: Predictable downlink latency without continuous reception Disadvantage: Requires beacon coverage and slightly higher power than Class A

19.5 Knowledge Check: Architecture and Classes

19.6 Worked Example: Multi-Gateway Deployment Cost

Worked Example: Gateway Density for Urban Smart Parking

Scenario: A city deploys 2,000 parking sensors across a 4 km2 downtown area. Each sensor sends a 12-byte occupancy update every time a car arrives or departs (average 8 events/day per space). The city needs 99.5% message delivery reliability.

Step 1 – Coverage requirement:

Parameter Value Reasoning
Area 4 km2 Downtown core
Urban gateway range 1.5 km radius (SF10) Buildings, interference reduce from 5 km theoretical
Coverage per gateway pi x 1.52 = 7.07 km2 Circular coverage area
Gateways for coverage 4 / 7.07 = 1 (minimum) Single gateway could cover entire area

Step 2 – Redundancy requirement (99.5% delivery):

With a single gateway, packet delivery depends on one RF path. Urban obstructions cause ~15% packet loss per gateway. With N independent gateways hearing each uplink:

Gateways hearing each message Individual loss rate Combined loss rate Delivery rate
1 15% 15% 85%
2 15% 0.15 x 0.15 = 2.25% 97.75%
3 15% 0.153 = 0.34% 99.66%

Result: 3 gateways providing overlapping coverage achieves 99.66% delivery, exceeding the 99.5% target.

The probability improvement from multi-gateway redundancy follows the formula \(P_{success} = 1 - (1 - p)^n\) where \(p\) is individual gateway reception probability and \(n\) is number of gateways.

With \(p = 0.85\) (85% per gateway): - 1 gateway: \(P = 1 - (0.15)^1 = 0.85 = 85\%\) - 2 gateways: \(P = 1 - (0.15)^2 = 1 - 0.0225 = 97.75\%\) - 3 gateways: \(P = 1 - (0.15)^3 = 1 - 0.0034 = 99.66\%\)

Each additional gateway provides diminishing returns. Gateway 2 adds \(+12.75\%\), gateway 3 only \(+1.91\%\). The cost-benefit analysis shows 3 gateways optimal for 99.5% target, while 4+ gateways (\(P = 99.95\%\)) would add \(<0.3\%\) improvement for 33% cost increase.

Step 3 – Capacity check:

  • Messages per day: 2,000 sensors x 8 events = 16,000 messages
  • Airtime per message (SF10, 12 bytes): 247 ms
  • Total daily airtime: 16,000 x 0.247 s = 3,952 s = 1.1 hours
  • Available airtime per gateway (8 channels): 8 x 24 h = 192 channel-hours
  • Utilization: 1.1 / 192 = 0.57% (well within capacity)

Step 4 – Cost estimate:

Item Unit cost Quantity Total
Outdoor gateway (Kerlink Wirnet) $1,200 3 $3,600
Rooftop installation $500 3 $1,500
Network server (Chirpstack, self-hosted) $50/month 12 months $600
Parking sensors (Bosch PLS) $85 2,000 $170,000
Year 1 total $175,700
Per-space cost $87.85

Design insight: The gateway infrastructure ($5,100) is less than 3% of total cost. Over-provisioning gateways for redundancy is almost always worth the marginal cost compared to sensor hardware.

19.7 Concept Relationships

Concept Relates To Relationship Type Significance
Star-of-Stars Topology Gateway Redundancy Multiple gateways per device Automatic failover without device awareness
Gateway Network Server Transparent relay relationship Gateways forward all packets without processing
Device Class A Battery Life Minimal receive windows Enables 5-10 year battery life for sensors
Device Class B Beacon Synchronization GPS-synced ping slots Predictable downlink without continuous RX
Device Class C Power Source Continuous listening Requires mains power, millisecond latency
Network Server Deduplication Processes multiple copies Selects best packet when multiple gateways hear device
ADR Device Class Best for stationary devices Mobile devices should disable ADR due to varying link conditions

19.8 See Also

Explore these related topics to deepen your understanding:

19.9 Summary

This chapter reviewed LoRaWAN network architecture and device classes:

  • Star-of-Stars Topology: End devices communicate through multiple gateways that relay to a central network server
  • Gateway Role: Transparent packet forwarding without processing, enabling low-cost scalable infrastructure
  • Network Server Functions: Deduplication, ADR optimization, MAC command processing, and routing
  • Class A: Lowest power, receive only after transmit (5-10 year battery for sensors)
  • Class B: Scheduled receive windows using GPS beacons (1-3 year battery for controllable devices)
  • Class C: Continuous receive for lowest latency (requires mains power for actuators)
  • Class Selection: Based on downlink latency requirements, power source, and predictability of communication

Common Pitfalls

Class C devices listen continuously, consuming 5–15 mA in receive mode. Running Class C from a battery results in days of operation rather than years. Only deploy Class C with permanent mains power or large-capacity industrial power supplies.

Class B synchronization requires the network server to broadcast GPS-synchronized beacons. Many LoRaWAN network servers and community networks don’t support Class B beacons. Verify Class B beacon support in both the gateway firmware and network server before designing applications around Class B timing.

Class A applications that need to send commands to devices must wait until after the device’s next uplink (potentially hours or days). If your application requires sub-minute command latency, Class A is inappropriate — consider Class B (minutes) or Class C (seconds) instead.

Adding more gateways increases redundancy and capacity but not necessarily coverage. Two gateways covering the same area with overlap provide reliability benefits. One gateway with proper placement covering the required area is better than multiple poorly-placed gateways with gaps.

19.10 What’s Next

Continue your LoRaWAN review:

Direction Chapter Focus
Next Security & ADR Review Encryption, activation methods, and adaptive optimization
Then Deployment Review Regional parameters, TTN, and troubleshooting
Deep Dive LoRaWAN Architecture Full architecture details and MAC layer
Comprehensive LoRaWAN Comprehensive Review Complete technical review
Prerequisite LoRaWAN Overview Core concepts
Prerequisite Physical Layer Review Spreading factors and modulation