21  LoRaWAN Deployment

In 60 Seconds

This deployment review covers the practical aspects of launching LoRaWAN networks: configuring regional frequency plans (EU868, US915, AS923), planning gateway placement for coverage and capacity, setting up The Things Network (TTN), and troubleshooting common connectivity and performance issues. It bridges protocol knowledge with the operational skills needed for production deployments.

21.1 Learning Objectives

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

  • Configure Regional Parameters: Apply EU868, US915, and other frequency plans to devices and gateways
  • Calculate Gateway Coverage: Determine antenna placement, link budgets, and capacity for different environments
  • Evaluate Use Cases: Justify LoRaWAN selection against alternative LPWAN technologies for specific application scenarios
  • Architect TTN Integrations: Design device provisioning and backend connectivity on The Things Network
  • Diagnose Connectivity Issues: Systematically troubleshoot and resolve LoRaWAN deployment problems using debug checklists

21.2 Prerequisites

Required Chapters:

Key Concepts

  • Gateway Placement: Strategic positioning of LoRaWAN gateways considering coverage radius, terrain, building penetration, and traffic density to minimize dead zones.
  • Coverage Prediction: Using link budget calculations, terrain analysis, and propagation models (Okumura-Hata, log-distance) to estimate gateway coverage area before deployment.
  • Network Planning Tools: Software like TTN Mapper, RadioPlanner, and CloudRF used to simulate coverage, identify gaps, and optimize gateway placement.
  • Field Testing: Process of verifying coverage with walk-testing, drive-testing, or flying drones with test devices to validate coverage predictions.
  • Deployment Checklist: Structured verification process confirming gateway connectivity, device activation, coverage validation, and integration testing before production launch.
  • Backhaul Options: Connectivity from gateway to network server including Ethernet, cellular, Wi-Fi, or fiber; reliability of backhaul directly impacts network availability.
  • Maintenance Procedures: Ongoing operational tasks including firmware updates, gateway monitoring, device battery replacement scheduling, and coverage expansion.

Related Review Chapters:

Chapter Focus
Architecture & Classes Review Network topology, device classes

Estimated Time: 20 minutes

The Challenge: Different countries have different radio rules. You can’t just use any frequency anywhere!

The Solution: LoRaWAN defines regional frequency plans: - EU868: 868 MHz band for Europe (strict duty cycle limits) - US915: 915 MHz band for North America (no duty cycle, but channel hopping) - AS923: 923 MHz for Asia-Pacific (varies by country)

Simple Analogy: Think of regional parameters like driving rules. Left-side driving in UK, right-side in USA. Same car, different rules depending on where you are.

“Deploying LoRaWAN means dealing with real-world challenges!” Sammy the Sensor said. “Different countries use different frequencies – EU868 in Europe, US915 in America, AS923 in Asia. You cannot just ship the same device everywhere without configuring it for the local frequency plan!”

“Gateway placement is an art,” Lila the LED explained. “Put a gateway on a rooftop and it can cover kilometers. Put it in a basement and it barely reaches the parking lot. Height is your best friend for LoRaWAN coverage. Every meter higher the antenna goes, the coverage area grows dramatically!”

Max the Microcontroller added, “The Things Network makes it easy to get started. You register your device, configure the frequency plan, and start seeing data in minutes. For production deployments, you need to plan for redundancy – at least two gateways covering each area so that if one fails, sensors keep reporting.”

“Troubleshooting is a critical skill,” Bella the Battery said. “If messages are not arriving, check these things in order: is the device on the right frequency plan? Is the gateway online? Is the ADR causing the device to use an SF that is too low for the distance? Most LoRaWAN problems come down to radio configuration, not software bugs.”

21.3 How It Works: LoRaWAN Network Deployment

Understanding LoRaWAN deployment requires coordinating multiple technical layers:

21.3.1 Step 1: Regional Configuration

Select and configure the appropriate frequency plan for your deployment region. In Europe, configure devices for EU868 (863-870 MHz) with strict 1% duty cycle limits. In North America, use US915 (902-928 MHz) with no duty cycle but mandatory channel hopping across 64 uplink channels. Each region has specific power limits, channel assignments, and regulatory requirements that must be programmed into both devices and gateways before deployment.

21.3.2 Step 2: Coverage Planning

Calculate required gateway placement using link budget analysis. Start with expected device locations and spreading factors, then work backwards to determine gateway antenna height and placement. Urban deployments typically need one gateway per 2-5 km radius at 15-30m height, while rural areas can cover 15-45 km per gateway when mounted at 20-50m with clear line of sight. Account for obstacles (buildings, trees) and interference sources (Wi-Fi, BLE) when planning coverage patterns.

21.3.3 Step 3: Capacity Calculation

For each planned gateway, calculate total airtime budget. Sum the expected message airtime across all devices (accounting for SF distribution via ADR), then verify total daily airtime stays well below 24 hours. If a single gateway shows over 20 hours of daily traffic, either add redundant gateways or optimize the SF distribution to reduce high-SF usage (SF11/SF12 consume 8-32× more airtime than SF7).

21.3.4 Step 4: Network Setup

Deploy gateway infrastructure with reliable backhaul connectivity (Ethernet preferred over cellular/Wi-Fi). Register gateways with either a community network (The Things Network) for prototyping or a private network server (ChirpStack, TTN Stack) for production. Configure gateway frequency plan, antenna type, and location metadata. Provision devices using OTAA (recommended) with unique DevEUI/AppEUI/AppKey, or ABP with pre-configured DevAddr/session keys for testing.

21.3.5 Step 5: Integration & Monitoring

Connect the network server to your application backend via MQTT, HTTP webhooks, or storage integrations. Implement monitoring dashboards tracking join success rates, packet delivery rates, gateway uptime, and ADR convergence. Set alerts for abnormal conditions: device join failures, gateway offline events, duty cycle violations, or consistent low SNR/high packet loss.

21.3.6 Step 6: Troubleshooting & Optimization

When issues arise, debug systematically: verify device join status first, then check gateway connectivity, followed by RF signal quality (SNR/RSSI), frequency plan correctness, and duty cycle compliance. Use gateway packet logs and network server events to identify root causes. After stable operation, optimize SF distribution via ADR tuning, adjust transmit power to minimize interference, and add gateway redundancy in critical coverage areas.

21.4 Regional Parameters

21.4.1 Frequency Plans by Region

Region Frequency Channels Max EIRP Duty Cycle Notes
EU868 863-870 MHz 8 default 14-27 dBm 0.1%-1% Most restrictive duty cycle
US915 902-928 MHz 64 uplink, 8 downlink 30 dBm None Channel hopping required
AU915 915-928 MHz 64 uplink, 8 downlink 30 dBm None Similar to US915
AS923 920-923 MHz 8 default 16 dBm Varies Multiple sub-regions
KR920 920-923 MHz 7 default 14 dBm Listen Before Talk LBT required
IN865 865-867 MHz 3 default 30 dBm None Limited spectrum
Regulatory Compliance

Always verify and comply with local regulations:

  • Duty Cycle: EU requires <1% (36s per hour) on most channels
  • Transmit Power: Regulated by region, typically 14-30 dBm
  • Listen Before Talk (LBT): Required in some regions (Japan, Korea)
  • Frequency Hopping: Required in US/AU regions
  • Channel Masks: Must respect regional channel assignments

21.4.2 EU868 Duty Cycle Calculation

EU868 duty cycle calculation showing 247ms message airtime at SF10, with 1% duty cycle limit allowing 36 seconds of airtime per hour. This permits maximum 145 messages per hour. Exceeding duty cycle results in device blocking and possible regulatory fines.
Figure 21.1: EU868 Duty Cycle Calculation and Compliance

EU868 duty cycle calculations use the formula: \(T_{max} = D \times T_{period}\) where \(D\) is duty cycle fraction and \(T_{period}\) is the observation window.

For 1% duty cycle: \[T_{max} = 0.01 \times 3600s = 36s \text{ per hour}\]

Maximum messages at SF10 (247ms airtime): \[N_{max} = \frac{36s}{0.247s} = 145.7 \approx 145 \text{ messages/hour}\]

At different spreading factors: - SF7 (56.6ms): \(N_{max} = 636\) msg/hr - SF12 (1,319ms): \(N_{max} = 27\) msg/hr

This 23x difference shows why ADR optimization to lower SF dramatically increases network capacity under EU regulations.

21.5 Gateway Deployment Planning

21.5.1 Gateway Placement Factors

Factor Urban Suburban Rural Indoor
Typical Range 2-5 km 5-10 km 15-45 km 50-500 m
Gateway Height 15-30 m 10-20 m 20-50 m Ceiling mount
Obstacles Buildings, trees Mixed Minimal Walls, floors
Interference High (Wi-Fi, BLE) Medium Low Very High
Coverage Pattern Sector/directional Omni Omni Omni
Gateways Needed High density Medium Sparse One per building

21.5.2 Capacity Planning

LoRaWAN gateway capacity planning flowchart showing calculation methodology. Starting with 10,000 devices sending 1 message/hour (240,000 daily messages), distributes across spreading factors via ADR: SF7 (30%, 41ms airtime), SF9 (40%, 144ms), SF12 (30%, 988ms). Calculates total gateway airtime as 24.3 hours/day. Since this exceeds 24 hours available, recommends deploying 2+ gateways or optimizing SF distribution to reduce high-SF usage.
Figure 21.2: LoRaWAN Gateway Capacity Planning with SF Distribution

21.5.3 Deployment Best Practices

Gateway Deployment Guidelines
  1. Height Matters: Each 3m of elevation roughly doubles range in urban areas
  2. Line of Sight: Clear view dramatically improves coverage
  3. Avoid Obstacles: Buildings, trees, and metal structures attenuate signals
  4. Interference: Survey Wi-Fi/BLE environment, choose clean channels
  5. Redundancy: Overlapping coverage improves reliability and ADR
  6. Backhaul: Ensure reliable internet connectivity (Ethernet preferred)
  7. Power: Use PoE or UPS for gateway reliability
  8. Testing: Always field test before final installation

21.6 Application Scenarios

21.6.1 Use Case Selection Matrix

Application Class SF Typical Uplink Frequency Power Source Payload Size
Soil Moisture A SF10-12 Hourly Battery (5-10yr) <20 bytes
Asset Tracking A SF7-10 Per movement Battery (2-5yr) 20-50 bytes
Smart Parking A SF8-10 Per occupancy change Battery (3-7yr) <10 bytes
Environmental A SF9-11 Every 15 min Solar/Battery 30-100 bytes
Street Lighting B/C SF7-9 Event-based Mains 10-50 bytes
Water Meters A SF10-12 Daily Battery (10yr+) <50 bytes
Building HVAC C SF7-8 Real-time Mains 50-200 bytes
Livestock Tracking A SF8-10 Every 30 min Battery (1-3yr) 20-40 bytes

21.6.2 LoRaWAN vs Alternatives

Requirement Best Technology Why?
10+ year battery life LoRaWAN Class A Ultra-low power, infrequent transmission
< 1 second latency NB-IoT or Wi-Fi LoRaWAN downlink latency too high
Mobile asset tracking Cellular (NB-IoT/LTE-M) ADR fails with mobility, roaming support
Private network control LoRaWAN Own gateway infrastructure
Dense urban deployment NB-IoT or LoRaWAN Both work, NB-IoT has better obstacle penetration
Remote/rural coverage LoRaWAN Private gateways, no operator dependence
High data volume Wi-Fi or Cellular LoRaWAN limited to <50 kbps
Real-time control Wi-Fi or Zigbee LoRaWAN not suitable for low latency

21.7 The Things Network (TTN)

21.7.1 TTN Architecture

The Things Network architecture showing community-driven LoRaWAN infrastructure. End devices communicate via LoRa RF with multiple community gateways (both public and privately deployed). Gateways forward packets over internet to Packet Broker for routing. TTN Network Server (free tier) processes messages and offers integration options: TTN Console for web management, MQTT for pub/sub patterns, HTTP webhooks for push notifications, and Storage Integration. All integrations deliver data to user's application backend.
Figure 21.3: The Things Network Community LoRaWAN Infrastructure Architecture

21.7.2 TTN Quick Start

Step Action Tool/Resource
1 Create TTN account console.thethingsnetwork.org
2 Register application TTN Console
3 Add device (OTAA) Generate DevEUI, AppKey
4 Configure device Flash firmware with keys
5 Test transmission Monitor console for uplinks
6 Set up integration MQTT, HTTP, or storage
7 Process data Your application backend

21.7.3 TTN vs Private Network

Feature TTN (Community) Private Network
Cost Free Gateway + server costs
Coverage Community dependent Deploy your own
SLA Best effort Controlled
Data Privacy Shared infrastructure Complete control
Scalability Fair use limits Unlimited
Best For Learning, prototyping Production

21.8 Troubleshooting Common Issues

21.8.1 Deployment Issues and Solutions

Problem Possible Cause Solution
No uplinks received Device not joined, gateway offline Check join status, gateway backhaul, frequency plan
Join requests fail Wrong keys, network coverage Verify DevEUI/AppKey, check gateway proximity
Intermittent connectivity Duty cycle limits, interference Reduce uplink frequency, analyze RF environment
High packet loss Poor SNR, collisions Increase SF, add gateways, reduce device density
Downlinks not received Wrong RX windows, Class A timing Check RX1/RX2 timing, verify device class
Battery drains quickly High SF, frequent transmissions Enable ADR, optimize uplink interval
Gateway saturation Too many devices, high SF usage Add gateways, optimize SF distribution

21.8.2 Debug Checklist

LoRaWAN troubleshooting decision tree for no uplinks received. Starts by checking if device joined network (verify DevEUI/AppKey/OTAA config). If joined, checks gateway status (power/internet/backhaul). Next verifies RF signal strength (may need higher SF or better antenna placement). Confirms correct frequency plan for region (EU868/US915/etc). Checks duty cycle compliance (may need to reduce transmission frequency). Finally provides advanced debugging steps including frame counter verification, MIC validation, gateway log analysis, and packet sniffing.
Figure 21.4: LoRaWAN Troubleshooting Decision Tree for Missing Uplinks

21.9 Practice Scenarios

21.9.1 Scenario 1: Smart Agriculture

Context: You’re deploying 200 soil moisture sensors across 25 square km vineyard. Sensors measure moisture every 2 hours and send 15-byte readings.

Questions:

  1. Which device class? Answer: Class A (battery powered, no downlink urgency)
  2. Recommended spreading factor? Answer: SF9-10 (balance range and battery)
  3. Estimated battery life? Answer: 5-8 years (very low duty cycle)
  4. Minimum gateways needed? Answer: 2-3 (coverage + redundancy)
  5. Public (TTN) or private network? Answer: Private (production reliability)

21.9.2 Scenario 2: Urban Smart Parking

Context: 500 parking sensors in dense urban downtown (2 km x 2 km). Sensors detect occupancy changes and update within 30 seconds.

Questions:

  1. Challenge: High interference from Wi-Fi/BLE? Answer: Yes (use lower SF, more gateways)
  2. Recommended device class? Answer: Class A (uplink-driven updates)
  3. How many gateways? Answer: 10-15 (urban obstacles, redundancy)
  4. Security concerns? Answer: OTAA mandatory (scalable, secure)
  5. SF distribution strategy? Answer: SF7-9 mostly (urban, short range)

21.9.3 Scenario 3: Asset Tracking

Context: Track 100 shipping containers nationwide using solar-powered LoRaWAN trackers with GPS. Report location every hour.

Questions:

  1. Will ADR work well? Answer: No (mobile devices, disable ADR)
  2. Coverage challenge? Answer: Yes (requires dense gateway network or hybrid with cellular)
  3. Better alternative? Answer: Cellular NB-IoT/LTE-M (mobility, nationwide coverage)
  4. If using LoRaWAN, which SF? Answer: SF10-12 (manual config, maximize range)
  5. Integration approach? Answer: TTN regions, fallback cellular (hybrid solution)

21.10 Knowledge Check: Deployment

21.11 Worked Example: EU868 Message Budget Planning

Worked Example: How Duty Cycle Limits Your Application Design

Scenario: A water utility in Germany wants LoRaWAN-connected smart meters that report consumption every 15 minutes. Each report is 24 bytes. Is this feasible under EU868 duty cycle regulations?

Step 1 – Calculate airtime per message:

Using the LoRa airtime calculator for EU868 with 125 kHz bandwidth:

Spreading Factor Airtime (24 bytes) Messages/hour at 1% duty cycle
SF7 56.6 ms 636
SF8 102.9 ms 349
SF9 185.3 ms 194
SF10 370.7 ms 97
SF11 659.5 ms 54
SF12 1,319 ms 27

1% duty cycle = 36,000 ms per hour

Step 2 – Check feasibility at target interval:

  • Target: 4 messages per hour (every 15 minutes)
  • At SF10: 4 x 370.7 ms = 1,483 ms per hour = 0.041% duty cycle (well within 1%)
  • At SF12: 4 x 1,319 ms = 5,276 ms per hour = 0.147% duty cycle (still fine)

Result: Feasible at all spreading factors for 15-minute intervals.

Step 3 – Find the duty cycle limit:

What is the maximum reporting frequency at each SF?

SF Max messages/hour Max reporting interval
SF7 636 Every 5.7 seconds
SF10 97 Every 37 seconds
SF12 27 Every 2.2 minutes

Design decision: At SF12 (worst case for range), the meter can report no faster than every 2.2 minutes. The 15-minute target has a 6.8x safety margin even at SF12 – leaving headroom for confirmed uplinks (which require ACK downlinks) and occasional retransmissions.

Step 4 – Multi-channel advantage:

EU868 provides 8 default channels across 3 sub-bands with different duty cycle limits:

Sub-band Channels Duty Cycle Effective airtime/hour
g (867.1-867.9 MHz) 5 channels 1% 36 s x 5 = 180 s
g1 (868.0-868.6 MHz) 3 channels 1% 36 s x 3 = 108 s
Total 8 channels 288 s/hour

With 8-channel devices and a compliant gateway, the effective throughput is 8x higher than single-channel calculations suggest. The smart meter application has abundant capacity.

Real-world deployment note: Kamstrup (Danish utility meter manufacturer) deploys LoRaWAN water meters across European cities at 15-minute intervals with SF10, achieving 99.2% delivery rates using 2-3 redundant gateways per km2.

21.12 Concept Relationships

Concept Builds On Enables Contrasts With
Regional Parameters Radio regulations, ISM bands Legal device operation, spectrum compliance Wi-Fi (global 2.4/5 GHz), Cellular (licensed spectrum)
Duty Cycle Limits EU ETSI regulations, airtime calculation Fair spectrum sharing, interference reduction US915 (no duty cycle), NB-IoT (operator-managed)
Gateway Placement Link budget analysis, Fresnel zones Coverage area, multi-gateway redundancy Cellular towers (operator-controlled), Wi-Fi APs (short range)
Capacity Planning Spreading factor orthogonality, airtime Scalable deployments, collision avoidance NB-IoT (operator capacity management), Sigfox (ultra-narrowband)
ADR Optimization Link margin, SNR monitoring Battery life extension, network capacity Fixed SF (manual config), Sigfox (no ADR)
OTAA vs ABP Join procedure, key derivation Secure activation, frame counter reset resilience Wi-Fi WPA handshake (per-connection), Zigbee commissioning
TTN Community Public gateway sharing, fair use Free prototyping, learning platform Private networks (full control), NB-IoT (operator SLA)

21.13 See Also

LoRaWAN Core Concepts:

Alternative LPWAN Technologies:

Hands-On Learning:

21.14 Try It Yourself: Gateway Coverage Planner

Objective: Plan a LoRaWAN gateway deployment for a real-world scenario and validate coverage.

Scenario: You’re deploying a smart city parking sensor network in a 3 km × 2 km urban downtown area. The area has 1,200 parking spaces (average spacing 50m), medium-rise buildings (10-20 stories), and moderate Wi-Fi/BLE interference.

21.14.1 Exercise Steps

  1. Define Requirements

    • Device type: Parking sensors (occupancy detection)
    • Update frequency: Every occupancy state change (typically 2-10 per day)
    • Payload size: 12 bytes (DevAddr, timestamp, occupancy flag, battery voltage)
    • Battery life target: 5+ years
    • Deployment region: EU868

  2. Calculate Link Budget

    TX Power: 14 dBm (EU868 limit)
TX Antenna Gain: 0 dBi (sensor embedded antenna)
RX Antenna Gain: 3 dBi (gateway omni antenna)
RX Sensitivity: -137 dBm (SF12), -123 dBm (SF7)
Path Loss Budget: 14 + 0 + 3 - (-137) = 154 dB (SF12)

Urban path loss model (Okumura-Hata):
PL = 69.55 + 26.16×log10(868) - 13.82×log10(hb) - a(hm) + (44.9 - 6.55×log10(hb))×log10(d)

With hb=20m (gateway), hm=1m (sensor), solve for d:
d ≈ 2.8 km (SF12), 0.9 km (SF7)

  3. Plan Gateway Placement

    • Coverage area: 3 km × 2 km = 6 km²
    • SF9 (balance between SF7/SF12): estimated range ~1.5 km radius in urban
    • Circular coverage: π × 1.5² ≈ 7 km² per gateway
    • Initial estimate: 1 gateway might suffice, but urban obstacles and redundancy suggest 2-3 gateways

  4. Capacity Check

    • 1,200 devices × 5 messages/day average = 6,000 messages/day
    • Airtime per message at SF9 (12 bytes): ~185 ms
    • Daily airtime: 6,000 × 0.185s = 1,110 seconds = 18.5 minutes/day
    • Well within capacity (single gateway can handle ~23 hours/day)

  5. Duty Cycle Compliance

    • Each device: 5 msg/day × 185ms = 0.925s/day = 0.0011% duty cycle
    • Well within 1% limit (allows up to 864s/day per device)

  6. Final Deployment Plan

    • Gateway count: 3 (redundancy + obstacle mitigation)
    • Placement: Rooftop installations at 20-25m height, distributed for overlapping coverage
    • Expected SF distribution: 40% SF7, 35% SF8, 20% SF9, 5% SF10-12 (ADR optimized)
    • Network type: Private (ChirpStack) for production SLA guarantees

21.14.2 What to Observe

Success criteria:

  • Join success rate >98% (all sensors successfully join network within 24 hours)
  • Packet delivery rate >95% (accounting for temporary RF blockage)
  • ADR convergence <48 hours (sensors stabilize at optimal SF)
  • Battery life projection >5 years (based on SF distribution and message frequency)

Common issues to troubleshoot:

  • Dead zones behind large metal buildings → Add gateway or adjust antenna orientation
  • Interference from nearby Wi-Fi → Switch to cleaner EU868 channels (867.1-867.9 MHz)
  • High SF concentration (>30% at SF10+) → Verify gateway antenna height and line of sight

21.14.3 Extension Challenge

Use the TTN Mapper tool to visualize real-world LoRaWAN coverage in your city, then compare predicted vs. actual gateway ranges. Identify factors (terrain, building density, interference) that caused deviations from theoretical link budget calculations.

21.15 Summary

This chapter reviewed LoRaWAN deployment considerations:

  • Regional Parameters: EU868, US915, AS923 have different frequency, power, and duty cycle requirements
  • Duty Cycle Compliance: EU requires <1% airtime (36 seconds/hour), violating regulations causes blocking
  • Gateway Planning: Urban deployments need high density (10-15 per km2), rural needs only 1-2 per 100 km2
  • Capacity Calculation: Total airtime determines gateway load; SF distribution significantly impacts capacity
  • Use Case Matching: LoRaWAN excels at battery-powered sensors; avoid for video, real-time control, or mobile tracking
  • TTN: Free community network for learning/prototyping; use private network for production
  • Troubleshooting: Systematic debug from join status through gateway, RF, frequency plan, to duty cycle

Common Pitfalls

Link budget models predict coverage but ignore local terrain, buildings, vegetation, and RF environment. Plan with models then validate with walk-testing. Allocate 10–15 dB additional margin for real-world conditions beyond theoretical line-of-sight calculations.

A gateway in perfect RF position is useless without reliable backhaul to the network server. Plan backhaul options (Ethernet, cellular, fiber) as part of gateway placement decisions, not as an afterthought.

Confirming device activation (join accept received) is not sufficient for production readiness. Verify the complete chain: uplink received by gateway → network server processes → application server receives decoded payload → callback confirmed. Test each link separately.

Deploying gateways with exactly calculated non-overlapping coverage leaves edge zones with poor reliability. Design for 20–30% coverage overlap between gateways to ensure reliable reception at boundaries and provide path diversity for edge devices.

21.16 What’s Next

Complete your LoRaWAN knowledge:

Direction Chapter Focus
Test Yourself LoRaWAN Quiz Bank Comprehensive practice questions
Deep Dive LoRaWAN Comprehensive Review Full technical reference
Compare LPWAN Comparison LoRaWAN vs NB-IoT vs Sigfox
Hands-On LoRaWAN Simulation Lab Browser-based ESP32 LoRaWAN simulator

Previous Review Chapters:

Comparisons:

  • Sigfox - Operator-managed LPWAN alternative
  • NB-IoT - Cellular LPWAN comparison
  • Weightless - Open-standard LPWAN alternative