7 LoRaWAN Network Architecture
7.1 Learning Objectives
By the end of this chapter, you should be able to:
- Describe the complete LoRaWAN network architecture from device to cloud
- Explain the role of gateways as transparent packet forwarders in the star-of-stars topology
- Differentiate the three device classes (A, B, C) and justify class selection for specific use cases
- Design multi-gateway deployments for redundancy and capacity planning
- Calculate power consumption for each device class and assess battery life trade-offs
Key Concepts
- Star-of-Stars Topology: LoRaWAN deployment architecture where end devices communicate to multiple gateways (first star), which forward packets to a central network server (second star).
- Network Server: Core LoRaWAN infrastructure component handling deduplication, ADR, MAC command processing, downlink scheduling, and routing to application servers.
- Packet Forwarder: Software running on LoRaWAN gateways that receives RF packets and sends them via UDP or MQTT to the network server.
- Application Server: Backend service decrypting application payload (using AppSKey) and delivering sensor data to business applications via APIs.
- Join Server: Dedicated component managing OTAA join procedures and root key storage; often co-located with network server but can be separate for multi-tenant deployments.
- Roaming: LoRaWAN capability allowing devices registered on one network to use gateways from another network, expanding coverage through inter-operator agreements.
- Public vs. Private Networks: LoRaWAN can be deployed as shared public infrastructure (e.g., The Things Network) or private dedicated networks; trade-offs in cost, security, and control.
A LoRaWAN network has three main parts: end devices (sensors), gateways (receivers with internet connections), and a network server (the brain). Sensors broadcast their data, and any nearby gateway picks it up and forwards it to the server. This star-of-stars architecture is simple and scalable – adding more gateways extends coverage without changing existing devices.
“LoRaWAN uses a star-of-stars architecture,” Sammy the Sensor explained. “I broadcast my data, and every gateway within range picks it up. I do not aim at one specific gateway – I just shout into the air and let the network figure it out! It is like throwing a message in a bottle into the ocean, except multiple people on different beaches all find copies.”
“Gateways are the simplest part,” Lila the LED added. “They are just transparent relay stations. A gateway hears my message and forwards it straight to the network server without changing anything. One gateway can serve thousands of sensors, and if you add more gateways, coverage gets better without changing a single sensor!”
Max the Microcontroller explained, “The network server is the brain of the whole operation. When three gateways all forward the same message from Sammy, the server deduplicates it – keeping only one copy. The server also handles security, decides which spreading factor each device should use, and routes data to the right application.”
“There are three device classes,” Bella the Battery noted. “Class A sleeps most of the time and only listens briefly after sending – that is me at my most efficient! Class B wakes up at scheduled times using beacon synchronization. And Class C listens all the time, which uses the most power but allows instant downlink messages. Most IoT sensors use Class A because battery life is king.”
7.2 LoRaWAN Network Architecture: Progressive Detail
Understanding LoRaWAN architecture is easier when we build up from simple to complex. Here are three levels of detail:
7.2.1 Level 1: Simple Overview (The Big Picture)
At its core, LoRaWAN follows a simple flow: sensors send data to gateways, which forward it to the cloud:
Key Concept: Gateways are “transparent bridges” - they don’t process data, just relay it. One gateway can serve thousands of sensors.
7.2.2 Level 2: With Protocol Details (What’s Actually Transmitted)
Let’s add technical detail about what happens at each stage:
Key Insights:
Encryption at two layers: Network server sees device address but NOT payload. Only your application server can decrypt sensor data.
Data amplification: 20-byte sensor payload becomes 500-byte gateway packet (adds RSSI, SNR, GPS, timestamp).
Deduplication: If 3 gateways hear the same message, network server picks the best one.
7.2.3 Level 3: Complete Network with Multiple Devices
Real deployments have many sensors, multiple gateways, and bidirectional communication:
Key Network Behaviors:
Redundant Gateway Coverage: Sensor 2 is heard by both gateways. Network server automatically picks the best signal (highest RSSI).
Spreading Factor Adaptation: Nearby sensor (D1) uses fast SF7. Distant sensor (D3) uses slow SF12. ADR optimizes this automatically.
Class A vs C Difference: Sensors (D1-D3) sleep 99.9% of time. Actuator (D4) listens continuously for immediate commands (e.g., “turn on valve”).
Scalability: Adding 1000 more sensors? No problem - they all share the same gateways. No pairing, no configuration.
7.3 Device Classes: Communication Patterns Visualized
Different device classes have dramatically different listening behaviors:
Power Consumption Comparison (2000 mAh battery):
| Class | Listening Time | Battery Life | Use Case |
|---|---|---|---|
| Class A | 2 seconds/hour (0.06%) | 5-10 years | Sensors, meters (95% of devices) |
| Class B | 1 second every 128 seconds (0.78%) | 6-18 months | Industrial monitoring, scheduled commands |
| Class C | Continuous (100%) | 5-7 days | Mains-powered actuators, streetlights |
What’s the actual power difference between Class A and Class C?
For a sensor sending 10 messages/day at SF9 (206 ms airtime):
Class A (only RX after TX): - TX energy per day: \(E_{\text{TX}} = 10 \times 0.206\text{s} \times 120\text{ mA} = 0.247\text{ mAh}\) - RX windows (2×1s each): \(E_{\text{RX}} = 10 \times 2\text{s} \times 15\text{ mA} = 0.3\text{ mAh}\) - Sleep (23.99 h/day): \(E_{\text{sleep}} = 2\mu\text{A} \times 24\text{h} = 0.048\text{ mAh}\) - Daily total: \(E_{\text{A}} = 0.595\text{ mAh/day}\) - Battery life: \(\frac{2000\text{ mAh}}{0.595\text{ mAh/day}} = 3361\text{ days} = \mathbf{9.2\text{ years}}\)
Class C (continuous RX): - TX energy: \(E_{\text{TX}} = 0.247\text{ mAh/day}\) (same) - Continuous RX: \(E_{\text{RX}} = 15\text{ mA} \times 24\text{h} = 360\text{ mAh/day}\) - Daily total: \(E_{\text{C}} = 360.25\text{ mAh/day}\) - Battery life: \(\frac{2000\text{ mAh}}{360.25\text{ mAh/day}} = 5.55\text{ days} = \mathbf{133\text{ hours}}\)
Ratio: Class A lasts \(\frac{9.2\text{ years}}{5.55\text{ days}} = \mathbf{605×}\) longer than Class C. This is why Class C devices must use mains power in production deployments.
Decision Rule: Use Class A unless you NEED downlinks (commands from server). Even then, consider whether commands can wait until next uplink.
7.4 Class A: Lowest Power (Default for Sensors)
Class A devices are the most common and power-efficient:
Timeline:
[SLEEP 14:59] --> [TX 370ms] --> [RX1 1s] --> [RX2 1s] --> [SLEEP 15:00]Key Characteristics:
- Opens receive windows ONLY after transmitting
- Sleeps 99.9% of the time
- Downlink latency: minutes to hours (depends on uplink interval)
- Use case: Temperature sensors, water meters, parking sensors
Power Budget Example (4 messages/hour at SF10):
- Sleep: 0.001 mA continuous = 0.001 mAh/hour
- TX: 120 mA x 0.370 s x 4 msgs / 3600 = 0.049 mAh/hour
- RX: 15 mA x 2 s x 4 msgs / 3600 = 0.033 mAh/hour
- Total: ~0.083 mAh/hour = 24,000 hours (~2.7 years) on 2000 mAh battery
7.5 Class B: Scheduled Receive Windows
Class B adds beacon-synchronized receive slots for predictable downlink latency:
Timeline:
[SLEEP] --> [BEACON] --> [PING 1] --> [PING 2] --> [BEACON] --> ...
| | |
Sync Every 128s Every 128sKey Characteristics:
- Requires gateway beacon synchronization
- Opens ping slots at scheduled intervals (configurable: 1-128 seconds)
- Downlink latency: predictable (ping slot period)
- Use case: Street lights, industrial valves, scheduled control
Power Budget Example:
- Sleep + beacon + ping slots: ~0.5 mA average
- Battery life: ~4000 hours (5-6 months) on 2000 mAh battery
7.6 Class C: Continuous Receive
Class C devices listen continuously except when transmitting:
Timeline:
[RX ALWAYS] --> [TX 370ms] --> [RX ALWAYS] --> ...Key Characteristics:
- Near-instant downlink capability (<1 second latency)
- High power consumption (radio always on)
- ONLY for mains-powered devices
- Use case: Industrial controllers, powered gateways, smart plugs
Power Budget:
- Continuous RX: ~15 mA average
- Battery life: ~133 hours (5.5 days) on 2000 mAh battery
- Conclusion: Class C is NOT suitable for battery-powered devices
7.6.1 Why Gateways Are “Dumb” by Design
LoRaWAN’s decision to make gateways transparent packet forwarders – rather than intelligent routing devices – was a deliberate architectural choice with significant implications:
Scalability without coordination: Because gateways do not maintain device associations, adding a new gateway requires zero configuration changes on any existing device or gateway. The new gateway simply starts forwarding packets to the network server, which automatically incorporates the additional coverage. Semtech estimates that a single 8-channel gateway can demodulate packets from approximately 10,000 devices transmitting once per hour at SF7, or approximately 500 devices at SF12.
Automatic macro-diversity: When a device transmits, every gateway within range receives and forwards the packet independently. The network server performs selection combining, choosing the copy with the best signal quality (highest RSSI or SNR). This provides spatial diversity without any device-side complexity. In The Things Network’s Amsterdam deployment (2016-present), the median message is received by 2.3 gateways, and 94% of messages are received by at least one gateway – a reliability level achieved without retransmissions.
Failure isolation: A gateway failure does not require any device re-association or network reconfiguration. Overlapping gateways automatically absorb the coverage gap. This contrasts with Zigbee or Thread, where a router failure requires mesh re-routing and can temporarily isolate downstream devices.
Trade-off: The cost of gateway simplicity is that all intelligence (and computational load) concentrates in the network server. For very large deployments (100,000+ devices), the network server becomes the scalability bottleneck, requiring careful capacity planning and geographic distribution.
7.7 Gateway Architecture
LoRaWAN gateways are “transparent bridges” that don’t process data:
Key Gateway Facts:
- No device registration: Gateways don’t “know” which devices they serve
- Multi-channel: Typically 8 channels x 6 SFs = 48 concurrent receptions
- Metadata added: RSSI, SNR, GPS location, timestamp
- Protocol agnostic: Same gateway serves any LoRaWAN device
7.8 Network Server Role
The network server is the “brain” of LoRaWAN:
| Function | Description |
|---|---|
| Deduplication | Multiple gateways receive same packet; server keeps best one |
| MAC Commands | Sends ADR, LinkCheck, DevStatus commands to devices |
| Security | Validates MIC, manages session keys (NwkSKey) |
| Routing | Forwards decrypted payloads to correct application server |
| Device Management | Tracks frame counters, device state, activation |
Popular Network Servers:
- The Things Network (TTN): Free community network, good for prototyping
- ChirpStack: Open-source, self-hosted, full control
- AWS IoT Core for LoRaWAN: Managed, integrates with AWS services
- Actility ThingPark: Enterprise, carrier-grade
7.9 Visual Reference: Architecture Images
A semiconductor fabrication plant needs to deploy 800 LoRaWAN devices across a 50,000 m² facility for equipment monitoring, environmental sensing, and automated material handling. Different applications have different downlink requirements.
Device inventory and classification:
| Device Type | Count | Uplink Interval | Downlink Need | Power Source | Assigned Class |
|---|---|---|---|---|---|
| Temperature sensors | 400 | 10 min | None (telemetry only) | Battery | Class A |
| Humidity sensors | 200 | 15 min | None | Battery | Class A |
| Vibration monitors | 100 | 5 min | Rare (threshold updates quarterly) | Battery | Class A |
| Automated guided vehicles (AGV) | 50 | 30 sec | Frequent (route updates every 2-5 min) | Battery + charging dock | Class B |
| Emergency shutoff valves | 30 | 1 min | Critical (close command <10 sec latency) | Mains powered | Class C |
| Cleanroom door controllers | 20 | 30 sec | Frequent (access control <5 sec) | Mains powered | Class C |
Power budget analysis:
Class A sensors (700 devices):
- Average SF: SF9 (metal-rich environment)
- Airtime: 185 ms per message
- Messages per device per day: 24 hours / 10 min avg = 144 messages
- TX current: 120 mA, RX current: 15 mA, sleep: 2 µA
Daily consumption per Class A device: - TX: 120 mA × 0.185 s × 144 / 3600 = 0.89 mAh - RX windows (2× 1 sec): 15 mA × 2 s × 144 / 3600 = 1.20 mAh - Sleep (23.99 hours): 0.002 mA × 24 = 0.05 mAh - Total: 2.14 mAh/day
Battery: 3,400 mAh lithium (2× AA cells) Expected life: 3,400 × 0.8 / 2.14 = 1,271 days (~3.5 years) (multi-year replacement cycle)
Class B AGVs (50 devices):
- Ping slot period: 128 seconds
- Messages per day: 24 × 60 × 60 / 30 = 2,880 uplinks
- Ping slots per day: 24 × 60 × 60 / 128 = 675 receive opportunities
Daily consumption per Class B device: - TX (2,880 uplinks): 120 mA × 0.185 s × 2,880 / 3600 = 17.8 mAh - RX after TX (2,880 windows): 15 mA × 2 s × 2,880 / 3600 = 24.0 mAh - Ping slots (675 slots): 15 mA × 0.4 s × 675 / 3600 = 1.1 mAh - Sleep: 0.002 mA × 24 = 0.05 mAh - Total: 43.0 mAh/day
Battery: 10,000 mAh (rechargeable Li-ion) Runtime between charges: 10,000 × 0.8 / 43.0 = 186 days AGVs dock every 12 hours for charging → No battery issue
Class C valves/doors (50 devices):
- Continuous RX current: 15 mA
- TX every 60 seconds: 120 mA × 0.185 s / 3600 = 0.00617 mAh/message
Daily consumption per Class C device: - Continuous RX: 15 mA × 24 hours = 360 mAh/day - TX (1,440 messages): 0.00617 × 1,440 = 8.9 mAh - Total: 368.9 mAh/day
These devices are mains-powered (no battery concern).
Network capacity planning:
Total uplinks per hour: - Class A: 700 × (60/10) = 4,200 messages/hour - Class B: 50 × (60/0.5) = 6,000 messages/hour - Class C: 50 × 60 = 3,000 messages/hour - Total: 13,200 messages/hour
Gateway capacity (8 channels, SF7-SF12 mix, 1% duty cycle): - Average airtime with SF distribution: ~220 ms - Messages per channel: 36,000 ms / 220 ms = 163 msg/hour - Total capacity: 163 × 8 = 1,304 messages/hour per gateway
Gateways needed: 13,200 / 1,304 = 10.1 → 11 gateways minimum
With 2× redundancy for reliability: 22 gateways deployed (grid pattern across facility)
Design conclusion: The plant requires a mixed-class network with: - 700 Class A battery sensors (1-year battery life) - 50 Class B AGVs (dock charging every 12 hours) - 50 Class C mains-powered controllers (no battery concern) - 22 gateways for capacity and redundancy
| Backhaul Option | Bandwidth | Latency | Cost (5-year) | Best For | Avoid When |
|---|---|---|---|---|---|
| Ethernet (wired) | 100 Mbps - 1 Gbps | <10 ms | $0 (existing LAN) | Indoor facilities with LAN access, campus deployments | Outdoor sites without infrastructure |
| Wi-Fi (wireless LAN) | 54-600 Mbps | 10-30 ms | $0-500 (AP cost) | Buildings with Wi-Fi coverage, short-term deployments | Outdoor, long-distance sites |
| 4G/LTE cellular | 5-50 Mbps | 30-100 ms | $600-1,500 (data plan) | Remote outdoor sites, temporary deployments | Dense urban (congestion), underground |
| Fiber optic | 1-10 Gbps | <5 ms | $2,000-10,000 (installation) | Critical infrastructure, high-gateway-count sites | Budget-constrained, temporary installs |
| Satellite (LEO) | 50-200 Mbps | 20-40 ms | $1,200-2,400 (Starlink) | Remote areas (offshore, rural), no terrestrial options | Urban areas with alternatives |
| LoRa-to-LoRa relay | 0.3-50 kbps | 100-500 ms | $0 (gateway-to-gateway) | Ultra-remote, chained coverage extension | Latency-sensitive applications |
Bandwidth requirements (typical LoRaWAN gateway):
Light load (100 devices, 10 msg/hour each): - Uplink data: 1,000 msg/hour × 50 bytes avg = 50 KB/hour = 0.11 kbps - Metadata overhead (RSSI, SNR, timestamp): 3× data = 0.33 kbps - Total: <1 kbps (any backhaul option works)
Heavy load (5,000 devices, 60 msg/hour each): - Uplink data: 300,000 msg/hour × 50 bytes = 15 MB/hour = 33 kbps - Metadata: 3× = 100 kbps - Peak bursts (morning reporting): 500 kbps - Required backhaul: >1 Mbps sustained (LTE, Wi-Fi, or better)
Decision criteria:
Is site indoors with existing LAN? → Use Ethernet (cheapest, most reliable)
Is site outdoor within 4G coverage? → Use LTE with industrial modem (Robustel, Sierra Wireless)
Is site remote with no cellular coverage? → Use Satellite LEO (Starlink, Iridium Certus) or solar + LTE if marginal signal
Is deployment temporary (<6 months)? → Use Wi-Fi hotspot or LTE (avoid fiber installation costs)
Are there multiple gateways in chain formation? → Use LoRa backhaul (one gateway with LTE, others relay to it via LoRa P2P)
Reliability comparison (uptime %):
| Backhaul | Typical Uptime | Failure Modes | Mitigation |
|---|---|---|---|
| Fiber | 99.99% | Fiber cut, power outage | Dual-path routing, UPS |
| Ethernet | 99.9% | Switch failure, cable damage | Redundant switches, protected conduit |
| Wi-Fi | 99.5% | AP failure, interference | Mesh APs, backup LTE |
| LTE | 99.0% | Network congestion, signal loss | Dual-SIM, multi-carrier |
| Satellite | 98.0% | Weather (rain fade), obstruction | Link budget margin, clear sky view |
Rule of thumb: For critical applications (>99.5% uptime), use dual backhaul (primary LTE + backup Wi-Fi, or primary fiber + backup LTE).
What they did wrong: An industrial facility deployed 15 LoRaWAN gateways and expected them to automatically load-balance devices, coordinate channel allocation, and seamlessly hand off mobile devices between gateways like Wi-Fi roaming. When 800 sensors experienced 15-25% packet loss, they blamed “bad gateways.”
Why this assumption fails:
Wi-Fi access points (what they expected):
- Devices associate with a specific AP
- APs coordinate to avoid channel overlap
- APs handle roaming (handoff between APs)
- Load balancing (reject associations when overloaded)
LoRaWAN gateways (what they actually got):
- Gateways are transparent packet forwarders with NO device association
- Gateways forward every packet they receive to the network server
- Network server handles ALL intelligence (deduplication, routing, ADR)
- No coordination between gateways — they don’t know about each other
The actual problem:
All 15 gateways used the same 8 LoRaWAN channels with no frequency coordination. In the dense industrial environment with metal machinery, this created: - Gateway collision: Multiple gateways transmitting downlinks simultaneously on the same channel - Self-interference: Gateway A’s downlink blocked Gateway B from receiving uplinks - ADR confusion: Devices received conflicting ADR commands from different gateways - Capacity waste: 15× gateway capacity but network server saw 15× duplicate packets
The fix:
- Reduce gateway density in overlapping areas:
- Moved gateways 500 meters apart minimum
- Positioned gateways to minimize coverage overlap (<30% instead of 80%)
- Enable downstream transmission scheduling on network server:
- Only one gateway transmits downlink per device (best RSSI gateway selected)
- Prevents simultaneous downlink collisions
- Configure different spreading factors per area:
- Building A: Prioritize SF7-SF8 (close to gateways)
- Building B: SF9-SF10 (medium distance)
- Outdoor: SF11-SF12 (long range)
- This spatially separates traffic by orthogonal SFs
Post-fix performance:
- Packet delivery improved from 75% to 98.2%
- Network server deduplication rate dropped from 9× to 2.1× (less redundant coverage)
- Downlink success rate improved from 45% to 94%
Lesson: LoRaWAN gateways are NOT intelligent routers! They forward everything blindly. The network server provides all intelligence. Design for strategic coverage (not blanket coverage) and let the star-of-stars topology with server-side deduplication provide reliability.
7.10 Summary
This chapter covered LoRaWAN network architecture:
- Star-of-Stars Topology: Devices communicate with multiple gateways for redundancy
- Gateways as Bridges: Transparent packet forwarding, no device registration
- Network Server: Deduplication, MAC commands, security, routing
- Device Classes: Class A (lowest power), Class B (scheduled), Class C (continuous)
- Power Trade-offs: Class A for 10-year battery life, Class C for instant response
7.11 Knowledge Check
Common Pitfalls
A down network server means all devices lose connectivity even when gateways and RF links are working. Host on high-availability infrastructure with monitoring and automated failover.
Network servers must match uplink and downlink frequency plans. Wrong downlink channel configuration causes devices to retry uplinks indefinitely after not receiving ACKs, wasting battery.
Public LoRaWAN networks provide variable coverage. Never assume coverage exists in a deployment area without testing actual hardware. Gateway density varies significantly by region.
LoRaWAN 1.0.x and 1.1 devices have incompatible join procedures. Using a 1.1 device with a 1.0 network server causes join failures. Verify specification version compatibility before ordering hardware.
7.12 What’s Next
| Next Chapter | Description |
|---|---|
| ADR Optimization | Deep dive into Adaptive Data Rate algorithms and duty cycle regulations |
| LoRaWAN Architecture Deep Dive | Detailed protocol stack, join procedures, and security mechanisms |
| Common Pitfalls | Avoid common LoRaWAN deployment mistakes and misconfigurations |
| LoRaWAN Lab | Hands-on simulation exercises for gateway placement and device configuration |