%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
subgraph "Star-of-Stars LoRaWAN Architecture"
D1["End Device 1<br/>(Sensor)"]
D2["End Device 2<br/>(Meter)"]
D3["End Device 3<br/>(Tracker)"]
D4["End Device 4<br/>(Actuator)"]
GW1["Gateway 1"]
GW2["Gateway 2"]
GW3["Gateway 3"]
NS["Network Server<br/>(ADR, Deduplication)"]
AS["Application Server<br/>(Business Logic)"]
JS["Join Server<br/>(OTAA Keys)"]
D1 -.->|LoRa RF| GW1
D1 -.->|LoRa RF| GW2
D2 -.->|LoRa RF| GW1
D2 -.->|LoRa RF| GW3
D3 -.->|LoRa RF| GW2
D3 -.->|LoRa RF| GW3
D4 -.->|LoRa RF| GW1
GW1 -->|IP/Ethernet| NS
GW2 -->|IP/Ethernet| NS
GW3 -->|IP/Ethernet| NS
NS <-->|Join Procedure| JS
NS <-->|Data Routing| AS
end
style D1 fill:#2C3E50,color:#fff
style D2 fill:#2C3E50,color:#fff
style D3 fill:#2C3E50,color:#fff
style D4 fill:#2C3E50,color:#fff
style GW1 fill:#16A085,color:#fff
style GW2 fill:#16A085,color:#fff
style GW3 fill:#16A085,color:#fff
style NS fill:#E67E22,color:#fff
style AS fill:#E67E22,color:#fff
style JS fill:#E67E22,color:#fff
1101 LoRaWAN Review: Network Architecture and Device Classes
1101.1 Learning Objectives
By the end of this chapter, you will be able to:
- Describe Star-of-Stars Topology: Explain the role of gateways, network servers, and application servers
- Compare Device Classes: Select between Class A, B, and C based on latency and power requirements
- Analyze Downlink Latency: Calculate expected response times for each device class
- Design Multi-Gateway Deployments: Plan redundant coverage with overlapping gateway ranges
- Evaluate Class Trade-offs: Make informed decisions for specific IoT applications
1101.2 Prerequisites
Required Chapters:
- LoRaWAN Overview - Core concepts
- Physical Layer Review - Spreading factors and modulation
Related Review Chapters:
| Chapter | Focus |
|---|---|
| Security & ADR Review | Encryption, adaptive data rate |
| Deployment Review | Regional parameters, TTN, troubleshooting |
Estimated Time: 15 minutes
TipFor Beginners: Star-of-Stars Networks
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).
1101.3 Network Architecture
1101.3.1 Star-of-Stars Topology
{fig-alt=“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.”}
1101.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 |
1101.3.3 Gateway Role: Transparent Relay
ImportantKey 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.
1101.3.4 Network Server Functions
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
subgraph "Network Server Core Functions"
DEDUP["Deduplication<br/>Remove duplicate packets<br/>from multiple gateways"]
ADR["Adaptive Data Rate<br/>Optimize SF and TX power<br/>based on link quality"]
ROUTE["Routing<br/>Forward to correct<br/>application server"]
MAC["MAC Commands<br/>Device configuration<br/>and management"]
SECURITY["Security<br/>Verify MIC<br/>Decrypt MAC layer"]
end
RECEIVE["Receive from<br/>Gateways"] --> DEDUP
DEDUP --> SECURITY
SECURITY --> ADR
ADR --> MAC
MAC --> ROUTE
ROUTE --> DELIVER["Deliver to<br/>Application Server"]
style RECEIVE fill:#16A085,color:#fff
style DELIVER fill:#E67E22,color:#fff
style DEDUP fill:#2C3E50,color:#fff
style ADR fill:#2C3E50,color:#fff
style ROUTE fill:#2C3E50,color:#fff
style MAC fill:#2C3E50,color:#fff
style SECURITY fill:#2C3E50,color:#fff
{fig-alt=“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.”}
1101.4 Device Classes
1101.4.1 Class Comparison Diagram
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
subgraph "LoRaWAN Device Classes"
A["Class A<br/>(Lowest Power)"]
B["Class B<br/>(Scheduled)"]
C["Class C<br/>(Continuous RX)"]
end
A1["- RX after TX only<br/>- 2 short windows<br/>- Battery: 5-10 years"]
A2["Use: Sensors, meters"]
B1["- RX on schedule<br/>- Ping slots + beacons<br/>- Battery: 1-3 years"]
B2["Use: Street lights"]
C1["- RX always on<br/>- Lowest latency<br/>- Battery: Days/weeks"]
C2["Use: Actuators"]
A --> A1
A1 --> A2
B --> B1
B1 --> B2
C --> C1
C1 --> C2
style A fill:#27AE60,color:#fff
style B fill:#F39C12,color:#fff
style C fill:#E74C3C,color:#fff
style A1 fill:#2ECC71,color:#fff
style A2 fill:#2ECC71,color:#fff
style B1 fill:#E67E22,color:#fff
style B2 fill:#E67E22,color:#fff
style C1 fill:#C0392B,color:#fff
style C2 fill:#C0392B,color:#fff
{fig-alt=“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.”}
1101.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) |
1101.4.3 Class A: Receive After Transmit
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
sequenceDiagram
participant Device as Class A Device
participant GW as Gateway
participant NS as Network Server
Note over Device: Device initiates uplink
Device->>GW: Uplink (Sensor Data)
GW->>NS: Forward Packet
Note over Device: Wait 1 second
rect rgb(39, 174, 96)
Device->>Device: RX1 Window Open (1s)
end
Note over Device: RX1: Same frequency as uplink
Note over Device: Wait 1 more second
rect rgb(39, 174, 96)
Device->>Device: RX2 Window Open (2s)
end
Note over Device: RX2: Fixed frequency (SF12)
Note over Device: Sleep until next uplink
Note over Device: (May be hours/days)
{fig-alt=“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.”}
1101.4.4 Class Selection Decision Tree
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
START{Need downlink?}
START -->|No<br/>Uplink only| A["Class A<br/>(Best battery)"]
START -->|Yes| LATENCY{Latency requirement?}
LATENCY -->|Seconds<br/>acceptable| SCHEDULE{Predictable schedule?}
LATENCY -->|< 1 second<br/>needed| C["Class C<br/>(Must be powered)"]
SCHEDULE -->|Yes<br/>e.g., hourly| B["Class B<br/>(1-3 year battery)"]
SCHEDULE -->|No<br/>unpredictable| POWERED{Powered available?}
POWERED -->|Yes| C
POWERED -->|No| A2["Class A<br/>(Accept delays)"]
style START fill:#2C3E50,color:#fff
style LATENCY fill:#2C3E50,color:#fff
style SCHEDULE fill:#2C3E50,color:#fff
style POWERED fill:#2C3E50,color:#fff
style A fill:#27AE60,color:#fff
style A2 fill:#27AE60,color:#fff
style B fill:#F39C12,color:#fff
style C fill:#E74C3C,color:#fff
{fig-alt=“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.”}
1101.4.5 Class B: Beacon-Synchronized Receive
NoteHow Class B Works
- Gateway broadcasts GPS-synchronized beacons every 128 seconds
- Device wakes to receive beacon and synchronize clock
- Device calculates ping slot times based on DevAddr
- Device opens receive windows at calculated ping slots
- 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
1101.5 Knowledge Check: Architecture and Classes
1101.6 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
1101.7 What’s Next
Continue your LoRaWAN review:
- Next: Security & ADR Review - Encryption, activation methods, and adaptive optimization
- Then: Deployment Review - Regional parameters, TTN, and troubleshooting
NoteRelated Chapters
Prerequisites: - LoRaWAN Overview - Core concepts - Physical Layer Review - Spreading factors and modulation
Deep Dives: - LoRaWAN Architecture - Full architecture details - LoRaWAN Comprehensive Review - Complete technical review