8 LoRaWAN Topology & Components
8.1 Learning Objectives
By the end of this chapter, you will be able to:
- Contrast LoRaWAN Topology: Differentiate the star-of-stars architecture from mesh and cellular network designs
- Classify Network Components: Distinguish the roles of end devices, gateways, network servers, and application servers within the architecture
- Justify Gateway Design: Defend why gateways operate as transparent bridges that forward all messages without filtering
- Assess Network Server Functions: Evaluate the key responsibilities including deduplication, ADR, and routing and their impact on scalability
Key Concepts
- Star-of-Stars Topology: LoRaWAN network architecture where end devices connect to multiple gateways (inner star) which connect to a central network server (outer star), enabling redundancy and deduplication.
- Gateway: LoRaWAN infrastructure component that receives RF transmissions from end devices and forwards them as IP packets to the network server; transparent to device addressing.
- Network Server: Central intelligence of a LoRaWAN network handling deduplication, MAC commands, ADR decisions, join server integration, and downlink scheduling.
- Packet Deduplication: Network server function that eliminates duplicate packets received by multiple gateways for the same uplink transmission.
- Join Server: Dedicated server managing OTAA device activation, root key storage, and session key derivation; can be operated separately from the network server.
- Application Server: Endpoint that decrypts application payload and processes sensor data; communicates with network server via northbound API.
- Scalability: Network capacity considerations including channel utilization, gateway density, duty cycle compliance, and collision probability as device count increases.
The Problem: Physics works against us when designing LPWAN systems:
- Long range needs high power (inverse square law: power drops with distance squared)
- High power drains batteries quickly (a fundamental constraint)
- Cellular: Achieves 10km+ range but batteries last days, not years
- Wi-Fi: Years of battery life possible but only 100m range
Why It’s Hard:
- Shannon’s limit: \(C = B \times \log_2(1 + SNR)\) — capacity is fundamentally bounded by bandwidth and signal-to-noise ratio
- Lower bandwidth = longer symbols = more energy per bit — you can’t escape the math
- Regulatory limits: Duty cycle restrictions (1% in EU868), power limits (14-27 dBm)
- Bidirectional requirement: Sensors need to receive configuration updates and acknowledgments, not just send
What We Need:
| Requirement | Target | Why? |
|---|---|---|
| Range | 10-15 km rural, 2-5 km urban | Cover large areas with few gateways |
| Battery Life | 10+ years on AA batteries | Avoid costly maintenance visits |
| Device Cost | <$5 per radio module | Enable massive-scale deployments |
| Security | End-to-end encryption | Protect sensitive IoT data |
| Communication | Bidirectional | Remote configuration, firmware updates |
The Solution: LoRaWAN achieves this through chirp spread spectrum modulation with adaptive data rates:
- Spread spectrum: Spreads signal below noise floor, trading bandwidth for sensitivity (-137 dBm at SF12)
- Adaptive Data Rate (ADR): Dynamically optimizes spreading factor per device — devices near gateways use fast SF7, distant devices use robust SF12
- Star-of-stars topology: Simple end devices (no routing overhead), intelligent network server handles complexity
- Dual-layer encryption: NwkSKey for network, AppSKey for application — even network operators can’t read your data
This chapter explains the network topology and components that enable LoRaWAN to achieve this balance.
8.2 Prerequisites
Before diving into this chapter, you should be familiar with:
- LoRaWAN Overview: Understanding LoRa modulation and basic protocol concepts
- LPWAN Introduction: Context of low-power wide-area networks in IoT
Imagine you’re deploying 1000 soil moisture sensors across farmland. Each sensor needs to report data to a central server, but they’re spread over several square kilometers. How do you design this network?
LoRaWAN uses a clever star-of-stars architecture that’s different from mesh networks (where devices relay for each other) or cellular (expensive, power-hungry). Here’s how it works:
The Players:
- End devices (your sensors)—send data but don’t route for others
- Gateways (like cell towers)—multiple gateways receive signals from sensors
- Network server (in the cloud)—routes data and handles security
- Application server (your farm management software)—processes sensor data
The Key Insight: A sensor’s transmission can be received by multiple gateways simultaneously. Imagine shouting in a valley—multiple villages might hear you. The network server receives the same message from multiple gateways, picks the best one, removes duplicates, and forwards it to your application. This provides redundancy without complex routing at the sensor (saving power).
| Term | Simple Explanation |
|---|---|
| Star-of-Stars | Devices connect to gateways, gateways connect to network server |
| End Device | Sensor/actuator that transmits data (doesn’t route for others) |
| Gateway | Antenna that receives LoRa transmissions and forwards to network server |
| Network Server | Central brain handling routing, security, deduplication |
| Uplink | Data from device to server |
| Downlink | Commands/config from server to device |
“The star-of-stars topology is genius!” Sammy the Sensor said. “I do not need to know about other sensors or route their messages. I just send my data and let the gateways and network server handle everything. This keeps me simple and saves enormous amounts of power because I do not have to stay awake relaying other devices’ messages.”
“Gateways are wonderfully simple too,” Lila the LED added. “They do not make any decisions – they just forward everything they hear to the network server. That means a gateway can serve thousands of sensors without breaking a sweat. And if one gateway fails, the sensors do not even notice because other gateways pick up the signals!”
Max the Microcontroller explained, “The network server is where all the intelligence lives. It deduplicates messages that arrive from multiple gateways, handles security with AES-128 encryption, runs the ADR algorithm to optimize spreading factors, and routes data to the right application. Centralizing this intelligence keeps end devices cheap and power-efficient.”
“For deployment, the rule is simple,” Bella the Battery said. “More gateways equal better coverage and redundancy. Each gateway costs a few hundred dollars but serves thousands of sensors. So the cost per sensor drops dramatically as you scale up. That is why LoRaWAN is so economical for large deployments like smart cities and farms!”
8.3 LoRaWAN Network Architecture
LoRaWAN uses a star-of-stars topology where gateways relay messages between end devices and a central network server.
8.3.1 Network Components
The LoRaWAN architecture consists of four main components:
- End Devices (Nodes): Sensors and actuators that communicate wirelessly using LoRa modulation
- Gateways: Multi-channel receivers that forward messages between end devices and the network server
- Network Server: Central component that manages the network, handles security, and routes messages
- Application Server: Processes application-specific data from end devices
8.3.2 Star-of-Stars Topology
Unlike mesh networks, LoRaWAN uses a star-of-stars topology:
- First star: End devices connect to multiple gateways
- Second star: All gateways connect to the network server
Key Benefits:
| Benefit | Description |
|---|---|
| Simplicity | End devices don’t need to route messages |
| Low Power | Devices can sleep between transmissions |
| Redundancy | Multiple gateways can receive the same message |
| Scalability | Easy to add more gateways for coverage |
8.3.3 Gateway Role
Gateways in LoRaWAN are transparent bridges:
- Receive all LoRa transmissions within range
- Forward all messages to the network server (no filtering)
- Multiple gateways may receive the same message (by design)
- Network server handles deduplication
Misconception: “Multiple gateways receiving the same message wastes bandwidth, so gateways should coordinate to avoid duplicates.”
Reality: LoRaWAN gateways intentionally forward ALL messages—redundancy is a feature, not a bug.
Real-World Impact: In a 2019 city-wide deployment in Antwerp, Belgium (1,000+ parking sensors, 12 gateways), engineers initially worried about network congestion from duplicate packets. Monitoring showed:
- 72% of uplinks received by 2+ gateways (average 2.3 gateways per message)
- Gateway backhaul bandwidth: Each gateway forwarded ~500 packets/hour
- Actual bandwidth used: 500 packets × 50 bytes = 25 KB/hour = 0.056 kbps (negligible—a 4G connection handles 10,000× this)
- Benefit: When one gateway failed (power outage), 0 data loss—neighboring gateways provided seamless coverage
Why It Works: The network server deduplicates in <10ms using DevAddr + frame counter. The metadata (RSSI, SNR, timestamp) from multiple gateways enables geolocation and adaptive data rate optimization. Redundancy improves reliability (99.7% → 99.95% uptime) at essentially zero cost—backhaul bandwidth is ~1000× cheaper than deploying fewer gateways with coverage gaps.
Takeaway: Don’t fight the architecture—embrace redundancy. LoRaWAN’s star-of-stars topology turns “duplicate messages” into a reliability advantage.
For a gateway serving 1,000 devices transmitting hourly with average 2.3 gateways per message, total packets forwarded per hour:
\[P_{gateway} = \frac{N_{devices} \times f_{tx} \times R_{redundancy}}{N_{gateways}} = \frac{1000 \times 1 \times 2.3}{12} \approx 192 \text{ packets/hour}\]
With 50-byte average payload, bandwidth = \(192 \times 50 = 9,600\) bytes/hour = 0.021 kbps. This is 476× less than a single 10 kbps cellular IoT connection, proving redundancy overhead is negligible compared to reliability gains.
8.3.4 Network Server Functions
The network server is responsible for:
- Message Deduplication: Removes duplicate messages received by multiple gateways
- Security: Manages encryption keys and validates message integrity
- Adaptive Data Rate (ADR): Optimizes transmission parameters
- MAC Commands: Manages device settings and network parameters
- Routing: Directs messages to the appropriate application server
8.4 Knowledge Check
Test your understanding of LoRaWAN network topology.
8.5 Practice Exercise
8.6 Visual Reference Gallery
8.6.1 LoRaWAN Protocol Stack
Source: CP IoT System Design Guide, Chapter 4 - LPWAN Protocols
8.6.2 LoRaWAN Technology Summary
Source: CP IoT System Design Guide, Chapter 4 - LPWAN Protocols
8.7 Real-World Deployment: The Things Network Amsterdam and Gateway Densification
8.7.1 From 1 Gateway to 1,200: Amsterdam’s LoRaWAN Scaling Journey
The Things Network (TTN) launched in Amsterdam in 2015 with a single gateway covering 6 km of the city center. By 2023, the community had deployed 1,200+ gateways across the Netherlands, with Amsterdam alone hosting 380 gateways for a city of 219 km2. This organic growth revealed critical lessons about star-of-stars topology at scale.
Gateway Density vs. Network Quality
TTN published anonymized network statistics comparing performance across three density tiers:
| Metric | Sparse (<0.5 GW/km2) | Medium (0.5-2 GW/km2) | Dense (>2 GW/km2) |
|---|---|---|---|
| Avg gateways per uplink | 1.2 | 2.8 | 5.4 |
| Packet delivery ratio | 87% | 96% | 99.2% |
| Avg RSSI | -112 dBm | -98 dBm | -85 dBm |
| ADR-assigned SF | SF10-12 (slow, robust) | SF8-10 (moderate) | SF7-8 (fast, efficient) |
| Effective duty cycle capacity | 340 uplinks/GW/hour | 890 uplinks/GW/hour | 2,100 uplinks/GW/hour |
Why More Gateways Increase Capacity (Not Just Coverage)
A common misconception is that gateways only extend range. In dense Amsterdam, additional gateways dramatically improve capacity because ADR assigns lower spreading factors to nearby devices:
- SF12 transmission: 1,318 ms airtime (1% duty cycle = ~27 uplinks/hour per channel)
- SF7 transmission: 46 ms airtime (1% duty cycle = ~783 uplinks/hour per channel)
Moving devices from SF12 to SF7 through gateway densification provides a 29x capacity increase per device while also reducing device energy consumption by 96%. For Itude Mobile’s 14,000 canal boat sensors, adding 12 targeted gateways along the canal ring shifted 82% of devices from SF10-12 to SF7-8, increasing total network throughput from 890 to 8,400 uplinks/hour without any device-side changes.
The Deduplication Cost at Scale
TTN’s network server processes 180 million uplinks/day across Europe. With an average of 2.8 gateways per uplink, the server actually receives 504 million packets – a 2.8x amplification factor. Each deduplication window (500 ms) buffers incoming copies, matches on DevAddr + FCnt, selects the copy with best SNR, and discards duplicates.
At peak traffic (Monday 08:00 CET, parking and utility meters reporting simultaneously), the Amsterdam cluster processes 42,000 deduplication events per second. TTN’s 2021 architecture upgrade moved deduplication from a single Redis instance to a distributed time-windowed hash ring, reducing p99 deduplication latency from 380 ms to 12 ms and eliminating the “Monday morning duplicate storm” that previously caused 3-5% false message loss.
Cost of Coverage: Community vs. Operator Model
TTN’s community model contrasts sharply with operator-deployed networks like KPN LoRa (Netherlands) and Senet (US). A cost comparison for covering a 50 km2 urban area:
| Cost Component | TTN Community | KPN Operator | Key Difference |
|---|---|---|---|
| Gateway hardware | EUR 150-300 (indoor) | EUR 2,000-5,000 (outdoor carrier-grade) | Community uses consumer-grade |
| Backhaul | Volunteer’s existing internet | Dedicated 4G/fiber with SLA | No SLA vs 99.9% uptime |
| Gateways needed | 30-50 (indoor, lower height) | 8-12 (outdoor, 15-25m towers) | More GWs but cheaper each |
| Monthly cost/km2 | EUR 5-15 (electricity only) | EUR 80-200 (lease + backhaul + maintenance) | 10-15x cost difference |
| Packet delivery | 92-96% (variable) | 99.5%+ (SLA-backed) | Reliability trade-off |
For non-critical applications like environmental monitoring, asset tracking, and urban agriculture, TTN’s community model delivers adequate reliability at 10-15x lower cost. For utility metering and industrial monitoring requiring 99.5%+ delivery, operator networks justify the premium.
8.8 Gateway Placement Decision Framework
Placing gateways optimally is the most impactful design decision in a LoRaWAN deployment. Under-provisioning creates dead zones; over-provisioning wastes capital on redundant hardware. The framework below translates coverage requirements into concrete gateway counts and positions.
Step 1: Estimate single-gateway coverage radius
The effective radius depends on environment type, antenna height, and spreading factor:
| Environment | Antenna height | SF7 radius | SF12 radius | Typical use |
|---|---|---|---|---|
| Dense urban | 15 m (rooftop) | 0.8 km | 2.5 km | Smart parking, waste bins |
| Suburban | 20 m (tower) | 2.0 km | 5.0 km | Water meters, agriculture |
| Rural open | 30 m (tower) | 5.0 km | 15 km | Livestock tracking, weather stations |
| Indoor (same floor) | 3 m (ceiling) | 50 m | 150 m | Asset tracking, climate monitoring |
Step 2: Apply the 70% rule for overlap
For reliable coverage with gateway redundancy (at least 2 gateways hearing each device), use 70% of the coverage radius as the effective cell radius. This ensures overlapping coverage at cell boundaries.
Effective cell area = pi x (0.7 x radius)^2
Example -- dense urban (SF12, 2.5 km radius):
Effective radius = 0.7 x 2.5 = 1.75 km
Cell area = pi x 1.75^2 = 9.62 km^2
For 50 km^2 city center: 50 / 9.62 = 6 gateways minimum
With 30% margin for buildings/terrain: 8 gatewaysStep 3: Validate against capacity constraints
A single 8-channel gateway can handle approximately:
- SF7: ~440 messages per hour (shortest airtime, highest data rate)
- SF12: ~18 messages per hour (longest airtime, lowest data rate)
- Mixed SF7-12: ~110 messages per hour (realistic average)
For 1,000 devices reporting hourly on mixed SF: 1,000 / 110 = 10 gateways needed for capacity alone, even if 6 suffice for coverage. Capacity, not coverage, often determines gateway count in dense urban deployments.
Worked example – municipal waste bin monitoring (Lisbon, 2021):
Lisbon deployed LoRaWAN fill-level sensors in 2,400 waste bins across 84 km2. Each bin reports fill level 4 times per day using SF10 (average), with a 12-byte payload.
Coverage requirement: 84 km^2, suburban density
Gateway radius (SF10, 20 m antenna): 3.2 km
Effective radius (70% rule): 2.24 km
Cell area: pi x 2.24^2 = 15.8 km^2
Gateways for coverage: 84 / 15.8 = 6
Capacity requirement: 2,400 bins x 4 messages/day = 9,600 messages/day
Messages per hour (distributed): 400/hour
Gateway capacity (SF10): ~60 messages/hour per gateway
Gateways for capacity: 400 / 60 = 7
Redundancy requirement: 2-gateway minimum per device
Final count: max(6, 7) x 1.3 margin = 10 gateways
Actual deployment: 10 gateways (8 rooftop + 2 hilltop)
Cost: EUR 10 x 2,500 = EUR 25,000 (gateway hardware + installation)
Per-bin network cost: EUR 25,000 / 2,400 = EUR 10.42 per binA vineyard in California’s Napa Valley needs to monitor soil moisture across 500 hectares (1,235 acres) using 200 LoRaWAN sensors. Each sensor reports every 15 minutes using SF9 (average), with a 20-byte payload. The farm has hilly terrain with elevation differences of up to 150 meters.
Step 1: Calculate required gateway coverage
Terrain: Hilly rural environment - SF9 typical range in rural: 8-10 km - Hills reduce effective range by 30-40% → 5-7 km effective radius - Using 70% rule for overlap: 0.7 × 6 km = 4.2 km effective cell radius - Cell area: π × 4.2² = 55.4 km² - Farm area: 5 km² (500 hectares) - Gateways needed for coverage: 5 / 55.4 = 0.09 → minimum 1 gateway - For 2× redundancy: 2 gateways (place on highest hilltops)
Step 2: Validate against capacity constraints
Messages per sensor: 24 hours / 15 minutes = 96 messages/day per sensor Total daily messages: 200 sensors × 96 = 19,200 messages/day Peak hourly rate (assuming uniform distribution): 19,200 / 24 = 800 messages/hour
SF9 airtime (20-byte payload): ~185 ms EU868 duty cycle limit: 1% = 36 seconds per hour Maximum messages per hour at SF9: 36,000 ms / 185 ms = 194 messages/hour per channel With 8 channels: 194 × 8 = 1,552 messages/hour capacity
Capacity check: 800 messages/hour needed < 1,552 available → Single gateway sufficient
Step 3: Final design recommendation
Deploy 2 gateways positioned on the two highest hills for optimal line-of-sight coverage. This provides: - 100% coverage redundancy (every sensor reaches both gateways) - Network server automatically selects best gateway per message - Capacity headroom: 1,552 / 800 = 1.94× spare capacity for future expansion - If one gateway fails, 100% of sensors remain operational
Cost breakdown:
- 2× outdoor gateways @ $1,200 = $2,400
- Solar power kits @ $400 = $800
- LTE backhaul @ $25/month × 2 = $600/year
- 5-year TCO: $2,400 + $800 + ($600 × 5) = $6,200
- Per-sensor network cost: $6,200 / 200 = $31 per sensor over 5 years
When planning a multi-gateway LoRaWAN deployment, select the optimal placement approach based on your environment and priorities.
| Placement Strategy | Best For | Pros | Cons | Typical Use Case |
|---|---|---|---|---|
| Centralized (1 gateway, center) | Small sites (<1 km²), budget-constrained | Lowest cost ($300-500), simple setup | No redundancy, single point of failure | Small farm, single building campus |
| Hilltop/Elevation (2-3 gateways) | Hilly terrain, line-of-sight critical | Maximum range (10-15 km), natural coverage | Requires site access, power/backhaul challenges | Vineyards, mountainous farms, rural areas |
| Grid Pattern (4+ gateways) | Urban deployments, high reliability | Even coverage, high redundancy | Higher cost (4× gateways), complex planning | Smart city, university campus, industrial park |
| Perimeter Coverage (gateways at edges) | Long linear sites, roads, pipelines | Follows infrastructure shape | Higher gateway count, coverage gaps in center | Highway monitoring, pipeline inspection, railway |
Decision criteria weighted by priority:
If coverage reliability is #1 priority (99.5%+ uptime required): → Use grid pattern with 2-3× redundancy per area
If cost is #1 priority (minimize CapEx): → Start with centralized, add gateways only where coverage fails
If terrain is challenging (mountains, dense buildings): → Use hilltop/elevation strategy with line-of-sight planning
If capacity is high (>5,000 devices): → Use grid pattern to distribute load across multiple gateways
Rule of thumb: Every device should be heard by at least 2 gateways for reliable ADR and failover. Single-gateway designs are prototypes, not production deployments.
What they did wrong: A logistics company deployed 8 LoRaWAN gateways across a 20 km² port facility based solely on propagation modeling software that predicted 95% coverage. After deploying 1,200 asset trackers, 340 devices (28%) experienced regular message loss.
Why it failed: Coverage maps model RF propagation in idealized conditions and don’t account for: - Shipping containers stacked 8-high creating RF shadow zones (signal blocked) - Moving cranes with metal structures causing dynamic interference patterns - Saltwater environment increasing signal absorption by 15-20 dB compared to models - Daily tidal changes altering ground reflection characteristics
The modeling software assumed “suburban industrial” propagation with static obstacles. The reality was a dynamic metal environment with constantly moving obstructions and high-salinity conditions.
The correct approach:
- Site survey with test devices: Deploy 20-30 battery-powered test nodes across the actual facility for 14 days, measuring RSSI, SNR, and packet delivery ratio at different times/tidal conditions
- Heat mapping: Use collected data to generate actual coverage maps showing dead zones, not theoretical predictions
- Gateway placement adjustment: Add 4 additional gateways in identified shadow zones (12 total instead of 8)
- Validation: Re-test with full sensor deployment before declaring success
Post-fix results: After adding 4 gateways in crane paths and container stack areas, device connectivity improved to 98.2% (only 22 of 1,200 devices with issues, all in edge cases like deep ship holds). The lesson: Always pilot with real sensors in real conditions before full rollout. Software models are starting points, not gospel.
8.9 Summary
LoRaWAN’s star-of-stars topology provides:
- Simplicity: End devices don’t route messages, reducing complexity and power consumption
- Redundancy: Multiple gateways receiving the same message improves reliability
- Scalability: Adding gateways extends coverage without reconfiguring devices
- Centralized intelligence: Network server handles deduplication, security, and optimization
Common Pitfalls
Deploying with only one gateway creates a single point of failure. Even when coverage requirements are met by one gateway, add a second for redundancy. LoRaWAN’s star-of-stars topology supports multi-gateway reception at no additional protocol cost.
LoRaWAN gateways are transparent packet forwarders, not intelligent access points. They cannot authenticate devices or handle MAC commands. All network intelligence resides in the network server — gateways simply forward everything they receive.
A single network server processes deduplicated packets from all gateways. High device density with short transmission intervals can overwhelm an under-provisioned server. Plan capacity based on expected message throughput, not just device count.
Multiple gateways receiving the same uplink generate multiple copies. Without proper deduplication configuration, applications receive duplicate data. Always test deduplication behavior with a multi-gateway setup before production deployment.
8.10 What’s Next?
| Direction | Chapter | Description |
|---|---|---|
| Continue | LoRaWAN Device Classes | Class A, B, and C device communication patterns and selection criteria |
| Deep Dive | LoRaWAN Link Budget and ADR | Calculate transmission range and understand adaptive data rate optimization |
| Back | LoRaWAN Overview | LoRa modulation and basic protocol concepts |
| Related | LoRaWAN Security | OTAA and ABP activation, dual-layer encryption |