1103  LoRaWAN Review: Deployment, Regional Parameters, and Troubleshooting

1103.1 Learning Objectives

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

  • Apply Regional Parameters: Configure devices for EU868, US915, and other frequency plans
  • Plan Gateway Deployments: Calculate coverage and capacity for different environments
  • Evaluate Use Cases: Match LoRaWAN to appropriate application scenarios
  • Set Up TTN Networks: Configure devices and integrations on The Things Network
  • Troubleshoot Common Issues: Diagnose and resolve connectivity and performance problems

1103.2 Prerequisites

Required Chapters:

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.

1103.3 Regional Parameters

1103.3.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
ImportantRegulatory 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

1103.3.2 EU868 Duty Cycle Calculation

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph "EU868 Duty Cycle Example"
        AIRTIME["Message airtime:<br/>247ms (SF10)"]
        DUTY["Duty cycle limit:<br/>1%"]
        CALC["Max airtime per hour:<br/>3600s x 1% = 36s"]
        MAX["Max messages per hour:<br/>36s / 0.247s = 145"]
    end

    AIRTIME --> CALC
    DUTY --> CALC
    CALC --> MAX

    subgraph "Violation Consequences"
        EXCEED["Exceed duty cycle"]
        BLOCK["Device blocked<br/>by regulation"]
        FINE["Possible fines"]
    end

    MAX -->|If exceeded| EXCEED
    EXCEED --> BLOCK
    EXCEED --> FINE

    style AIRTIME fill:#16A085,color:#fff
    style DUTY fill:#E67E22,color:#fff
    style MAX fill:#27AE60,color:#fff
    style EXCEED fill:#E74C3C,color:#fff
    style BLOCK fill:#E74C3C,color:#fff
    style FINE fill:#E74C3C,color:#fff

Figure 1103.1: EU868 Duty Cycle Calculation and Compliance

{fig-alt=“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.”}

1103.4 Gateway Deployment Planning

1103.4.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

1103.4.2 Capacity Planning

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    START["LoRaWAN Gateway<br/>Planning"]

    START --> DEVICE["Number of Devices<br/>(e.g., 10,000)"]
    START --> FREQ["Message Frequency<br/>(e.g., 1 msg/hour)"]
    START --> SIZE["Payload Size<br/>(e.g., 50 bytes)"]

    DEVICE --> CALC["Daily Messages:<br/>10,000 x 24 = 240,000"]
    FREQ --> CALC
    SIZE --> SF["SF Distribution<br/>(ADR optimizes)"]

    SF --> SF7["SF7: 30%<br/>(72,000 msgs)"]
    SF --> SF9["SF9: 40%<br/>(96,000 msgs)"]
    SF --> SF12["SF12: 30%<br/>(72,000 msgs)"]

    SF7 --> AIRTIME7["Airtime: 41ms<br/>Total: 49 min/day"]
    SF9 --> AIRTIME9["Airtime: 144ms<br/>Total: 230 min/day"]
    SF12 --> AIRTIME12["Airtime: 988ms<br/>Total: 1,182 min/day"]

    AIRTIME7 --> TOTAL["Total gateway airtime:<br/>24.3 hours/day"]
    AIRTIME9 --> TOTAL
    AIRTIME12 --> TOTAL

    TOTAL --> RESULT{Exceeds 24h?}
    RESULT -->|Yes| MORE["Need 2+ gateways<br/>or reduce SF usage"]
    RESULT -->|No| OK["Single gateway OK<br/>Add margin for growth"]

    style START fill:#2C3E50,color:#fff
    style CALC fill:#16A085,color:#fff
    style TOTAL fill:#E67E22,color:#fff
    style RESULT fill:#2C3E50,color:#fff
    style MORE fill:#E74C3C,color:#fff
    style OK fill:#27AE60,color:#fff

Figure 1103.2: LoRaWAN Gateway Capacity Planning with SF Distribution

{fig-alt=“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.”}

1103.4.3 Deployment Best Practices

TipGateway 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

1103.5 Application Scenarios

1103.5.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

1103.5.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

1103.6 The Things Network (TTN)

1103.6.1 TTN Architecture

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TB
    subgraph "The Things Network (TTN) Architecture"
        DEVICE["End Devices<br/>(Your sensors)"]

        GW1["Community Gateway 1"]
        GW2["Community Gateway 2"]
        GW3["Your Gateway"]

        PKT["Packet Broker<br/>(Routes messages)"]

        NS["TTN Network Server<br/>(Free tier)"]

        CONSOLE["TTN Console<br/>(Web UI)"]
        MQTT["MQTT Integration"]
        HTTP["HTTP Webhooks"]
        STORAGE["Storage Integration"]

        APP["Your Application<br/>(Cloud/Local)"]
    end

    DEVICE -.->|LoRa RF| GW1
    DEVICE -.->|LoRa RF| GW2
    DEVICE -.->|LoRa RF| GW3

    GW1 -->|Internet| PKT
    GW2 -->|Internet| PKT
    GW3 -->|Internet| PKT

    PKT --> NS

    NS --> CONSOLE
    NS --> MQTT
    NS --> HTTP
    NS --> STORAGE

    MQTT --> APP
    HTTP --> APP
    STORAGE --> APP

    style DEVICE fill:#2C3E50,color:#fff
    style GW1 fill:#16A085,color:#fff
    style GW2 fill:#16A085,color:#fff
    style GW3 fill:#16A085,color:#fff
    style PKT fill:#3498DB,color:#fff
    style NS fill:#E67E22,color:#fff
    style APP fill:#9B59B6,color:#fff

Figure 1103.3: The Things Network Community LoRaWAN Infrastructure Architecture

{fig-alt=“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.”}

1103.6.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

1103.6.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

1103.7 Troubleshooting Common Issues

1103.7.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

1103.7.2 Debug Checklist

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph TD
    START{No uplinks<br/>received?}

    START --> JOINED{Device joined?}
    JOINED -->|No| KEYS["Check DevEUI/AppKey<br/>Verify OTAA vs ABP<br/>Check Join Server"]
    JOINED -->|Yes| GW

    GW{Gateway online?}
    GW -->|No| GWFIX["Check power/internet<br/>Verify backhaul<br/>Check firewall"]
    GW -->|Yes| RF

    RF{Good RF signal?}
    RF -->|Weak| RFFIX["Increase SF<br/>Move closer to gateway<br/>Check antenna<br/>Verify frequency plan"]
    RF -->|Good| FREQ

    FREQ{Correct frequency?}
    FREQ -->|Wrong| FREQFIX["Verify region (EU868/US915)<br/>Check channel mask<br/>Confirm gateway config"]
    FREQ -->|Correct| DUTY

    DUTY{Duty cycle OK?}
    DUTY -->|Exceeded| DUTYFIX["Reduce TX frequency<br/>Wait for duty cycle reset<br/>Add more gateways"]
    DUTY -->|OK| ADV

    ADV["Advanced debug:<br/>Check frame counters<br/>Verify MIC<br/>Analyze gateway logs<br/>Use packet sniffer"]

    style START fill:#2C3E50,color:#fff
    style JOINED fill:#2C3E50,color:#fff
    style GW fill:#2C3E50,color:#fff
    style RF fill:#2C3E50,color:#fff
    style FREQ fill:#2C3E50,color:#fff
    style DUTY fill:#2C3E50,color:#fff
    style KEYS fill:#E67E22,color:#fff
    style GWFIX fill:#E67E22,color:#fff
    style RFFIX fill:#E67E22,color:#fff
    style FREQFIX fill:#E67E22,color:#fff
    style DUTYFIX fill:#E67E22,color:#fff
    style ADV fill:#16A085,color:#fff

Figure 1103.4: LoRaWAN Troubleshooting Decision Tree for Missing Uplinks

{fig-alt=“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.”}

1103.8 Practice Scenarios

1103.8.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)

1103.8.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)

1103.8.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)

1103.9 Knowledge Check: Deployment

Question 1: In EU868, a device at 14 dBm has 1% duty cycle limit. Maximum transmission time per hour?

Explanation: A. 1% of 3600 seconds = 36 seconds maximum airtime per hour. At SF10 (247ms per message), this allows ~145 messages/hour. Exceeding this violates ETSI regulations.

Question 2: You’re deploying in United States. Which frequency plan and why?

Explanation: B. Frequency plans are region-specific and legally required. US devices must use 902-928 MHz (US915) per FCC regulations. Using EU868 frequencies in US is illegal and won’t work with local gateways.

Question 3: A gateway handles 500 devices at SF7, 300 at SF8, 200 at SF9. Is it approaching capacity?

Explanation: B. SF orthogonality allows simultaneous transmissions on different SFs. With 1000 total devices and distributed SFs, typical gateway handles thousands of devices if uplink rates are reasonable (e.g., hourly). Key factor is total airtime, not device count.

Question 4: Your deployment needs to cover 100 square km of flat farmland. Estimated gateways required?

Explanation: A. In rural flat terrain with line of sight, LoRaWAN range can exceed 15-20 km radius, covering ~300-1200 sq km per gateway. 100 sq km could theoretically be covered by single well-placed gateway, though 2 provides redundancy.

Question 5: Which application is POORLY suited for LoRaWAN?

Explanation: C. LoRaWAN max data rate ~50 kbps and small payloads (51-222 bytes) make video transmission impossible. Video requires Mbps throughput - use Wi-Fi, cellular, or wired. LoRaWAN excels at low-data-rate sensors, not streaming.

Question 6: When would you choose NB-IoT over LoRaWAN?

Explanation: C. NB-IoT provides operator-managed nationwide coverage with mobility support. LoRaWAN requires gateway infrastructure and ADR fails with mobile devices. For stationary sensors in private deployment, choose LoRaWAN.

Question 7: What is The Things Network’s business model?

Explanation: B. TTN is free, open, community-driven network where users contribute gateways and share access. Ideal for learning, prototyping, and community projects. For production/SLA requirements, consider private network or commercial providers.

1103.10 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

1103.11 What’s Next

Complete your LoRaWAN knowledge:

Previous Review Chapters: - Physical Layer Review - Spreading factors, modulation - Architecture & Classes Review - Network topology - Security & ADR Review - Encryption, activation

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