1093  LoRaWAN Review: Real-World Scenarios Part 2

This section covers advanced deployment scenarios:

Scenario Categories: - Duty Cycle Compliance: EU868 regulatory requirements - Dense Network Collisions: SF12 bottlenecks and ADR solutions - Regional Configuration: EU868 vs US915 channel management

Key Skills Tested: - Duty cycle calculations and compliance verification - Collision probability analysis - Regional parameter configuration

1093.1 Learning Objectives

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

  • Verify Duty Cycle Compliance: Calculate airtime and regulatory compliance
  • Diagnose Collision Issues: Identify SF-related bottlenecks in dense networks
  • Configure Regional Parameters: Properly set up devices for different LoRaWAN regions
  • Troubleshoot Packet Loss: Distinguish between signal, collision, and configuration issues

1093.2 Prerequisites

Before this assessment, complete:

1093.3 Quiz 2: Advanced Scenarios

Question: A smart agriculture company deploys 500 soil moisture sensors across a 2000-hectare farm using LoRaWAN in Europe (EU868). Each sensor sends a 12-byte reading every 30 minutes using SF7 (61ms time-on-air per message). After 3 months, the network operator reports duty cycle violations. What is the cause and solution?

Explanation: This demonstrates LoRaWAN duty cycle compliance in EU868 band:

EU868 Duty Cycle Restriction: In Europe (EU868), LoRaWAN devices are legally limited to 1% duty cycle on most channels: - Device can transmit for maximum 36 seconds per hour - After sending a message, must wait 99x the transmission time - Example: 5-second transmission -> 495-second (8.25 minute) mandatory wait

Duty Cycle Calculation for Deployed Sensors:

Per-device transmission:

Time-on-air per message: 61 ms (SF7, 12-byte payload)
Messages per hour: 60 min / 30 min = 2 messages/hour
Total airtime per device per hour: 61 ms x 2 = 122 ms = 0.122 seconds

Duty cycle percentage:

Duty cycle = (airtime / hour) x 100%
Duty cycle = (0.122 sec / 3600 sec) x 100%
Duty cycle = 0.0034% << 1% limit

Analysis: - Legal limit: 36 seconds per hour (1%) - Actual usage: 0.122 seconds per hour (0.0034%) - Sensors are operating at only 0.34% of the legal limit - Compliance margin: 36 / 0.122 = 295x under the limit

Why Other Options Are Wrong:

A: “Increase interval to 60 minutes” - Current: 2 messages/hour -> 122 ms/hour -> 0.34% duty cycle (Compliant) - Unnecessary change that reduces data resolution

B: “Add more gateways” - Duty cycle is a per-device radio regulation, not a gateway limit - Each sensor has its own 1% duty cycle budget

D: “Reduce to SF5” - SF5 doesn’t exist in LoRa specification (valid range: SF7-SF12) - Even if it did, sensors are already 295x under the limit

Most Likely Causes of False “Violations”: 1. Gateway misconfiguration aggregating all devices incorrectly 2. Network server reporting bug 3. Retransmissions not visible in deployment plan

Real-World Example: Farm deployment in Netherlands reported duty cycle violations: - Root cause: Gateway was counting all 500 devices together (61s total airtime) - Solution: Gateway firmware update to track per-device duty cycle - Result: All devices compliant (0.003% average duty cycle)

A parking sensor network uses LoRaWAN in dense urban San Francisco. 5,000 sensors transmit occupancy changes using SF12 (fixed, no ADR). Network experiences 40% packet loss despite good RSSI (-90 dBm). What’s the cause and solution?

Collision Analysis:

SF12 Characteristics:
- Time-on-air: 1,318ms (51-byte payload)
- RSSI: -90 dBm (far above SF7 threshold of -123 dBm!)
- Sensitivity: -137 dBm (overkill for urban deployment)

Network Load:
- 5,000 sensors x ~10 transmissions/day = 50,000 messages/day
- SF12 airtime: 1,318ms x 50,000 = 65,900 seconds/day = 18.3 hours/day
- All on SAME spreading factor = high collision probability

Spreading Factor Orthogonality:
- SF7 and SF12 on same channel/time: Both decode successfully
- SF12 and SF12 on same channel/time: Collision - both lost

Explanation: This demonstrates LoRaWAN spreading factor collision and Adaptive Data Rate (ADR) optimization:

Problem Analysis:

Current deployment:

Sensors: 5,000 devices
Spreading factor: SF12 (all devices)
Time-on-air: ~1318 ms per message (51-byte payload)
RSSI: -90 dBm (excellent signal, well above SF7 sensitivity of -123 dBm)
Packet loss: 40%

Why Good RSSI but High Loss?

Different SFs are orthogonal - they don’t interfere with each other. BUT: Same SF on same channel = collision.

Collision scenario: - Device A transmits on SF12, channel 0 - Device B transmits on SF12, channel 0 (same time) - Result: Both packets collide and are lost

Collision Probability Calculation:

Total airtime per hour: 10,000 x 1.318 = 13,180 seconds
Network airtime: 3,600 seconds (1 hour)
Offered load: 13,180 / 3,600 = 3.66 (366% of capacity)

With 8 channels (US915 typical):
Load per channel: 3.66 / 8 = 0.458 (45.8% per channel)

Collision rate for 45.8% channel load:
P(collision) = 1 - e^(-2 x 0.458) = 60% collision rate

Solution: Enable Adaptive Data Rate (ADR)

With ADR enabled (-90 dBm RSSI):

RSSI: -90 dBm (excellent signal)
SF7 sensitivity: -123 dBm
Link margin: -90 - (-123) = 33 dB (massive margin)

Network server decision:
"Signal is 33 dB stronger than minimum required for SF7"
-> Sends MAC command: Switch to SF7
-> Device uses SF7 for all future transmissions

Result:
- Time-on-air: 1318 ms -> 61 ms (21.6x faster)
- Battery life: 1.7 years -> 10 years (5.9x longer)
- Network capacity: 0.76 msg/sec -> 16.4 msg/sec (21.6x higher)

SF distribution with ADR (estimated for urban -90 dBm average):

SF7:  70% of devices (near gateways, strong signal)
SF8:  15% of devices
SF9:  10% of devices
SF10: 3% of devices
SF11: 1% of devices
SF12: 1% of devices (far from gateway, weak signal)

Expected packet loss with ADR:

Overall packet loss: ~1.5% (vs 40% without ADR)
Success rate: 98.5% (vs 60% without ADR)

Real-world validation: - Amsterdam smart parking: 10,000+ sensors, <1% loss with ADR - Seoul waste management: 15,000+ sensors, ADR reduced loss from 35% to 2% - Barcelona smart city: 7,000+ devices, ADR improved battery life from 2 years to 9 years

A logistics company deploys 2,000 LoRaWAN GPS asset trackers on international shipping containers. Location updates every 15 minutes. After 3 months: European devices 99% success, North American devices 80% packet loss (RSSI: -85 dBm, good). Configuration error?

Regional LoRaWAN Parameters:

Region Frequency Channels Channel Hopping Duty Cycle
EU868 863-870 MHz 8 default Random selection from 8 1% mandatory
US915 902-928 MHz 64 uplink + 8 downlink Pseudo-random across 64 None

Explanation: This demonstrates LoRaWAN regional parameter configuration and frequency channel management:

Regional Differences:

Region Frequency Band Max Power Duty Cycle Channels
Europe (EU868) 863-870 MHz +14 dBm 1% 8 default
North America (US915) 902-928 MHz +20-30 dBm None 64 uplink, 8 downlink

Problem Analysis:

US915 Channel Hopping: - US915 requires channel hopping across 64 channels - Devices must use pseudo-random channel selection - Gateway listens to 8 channels simultaneously (sub-band) - Device MUST distribute across all 64 to ensure reception

The Things Network US915 Configuration:

Standard TTN US915 uses channels 8-15 (sub-band 2):

TTN Gateway (US915):
Listens to channels: 8, 9, 10, 11, 12, 13, 14, 15
Frequencies: 903.9, 904.1, 904.3, 904.5, 904.7, 904.9, 905.1, 905.3 MHz

Device (misconfigured with sub-band 1):
Transmits on channels: 0, 1, 2, 3, 4, 5, 6, 7
Frequencies: 902.3, 902.5, 902.7, 902.9, 903.1, 903.3, 903.5, 903.7 MHz

Overlap: NONE
Success rate: 0%

Why 80% Packet Loss (20% Success)?

Partial channel overlap or device using all 64 channels but gateway only listens to 8: - Probability gateway hears: 8/64 = 12.5% - Close to observed 20%

Correct US915 Configuration:

void setup() {
    os_init();
    LMIC_reset();

    #ifdef CFG_us915
        // Proper US915 channel configuration:
        LMIC_selectSubBand(1);  // Selects channels 8-15 (sub-band 2 for TTN)
    #endif

    #ifdef CFG_eu868
        // EU868 channels configured by LMIC by default
    #endif
}

Why Other Options Are Wrong:

A: Hardware frequency mismatch - RSSI -85 dBm means gateway IS receiving signal - Hardware would show no signal if frequency completely wrong

B: Time zone configuration - RX windows use relative timing (T+1s, T+2s after uplink) - No absolute time or time zone involved

D: FSK vs LoRa modulation - LoRaWAN exclusively uses LoRa CSS (Chirp Spread Spectrum) - Gateways certified for LoRaWAN are locked to LoRa CSS

Expected results after fix:

Before (EU868 config in US915 region): - Packet success rate: 20% - Data loss: 80%

After (Proper US915 config): - Packet success rate: 99% - Data loss: <1%

Real-world case study: Global asset tracking company: - Initial: Single firmware build for global deployment (EU868 config) - Problem: 75% packet loss in USA, Australia - Root cause: EU868 channel configuration hardcoded - Solution: Multi-region firmware with GPS-based auto-configuration - Result: 99% success rate globally

1093.4 Chapter Summary

LoRaWAN is a powerful LPWAN protocol that enables long-range, low-power IoT communication. Key takeaways:

  • LoRa = Physical layer modulation, LoRaWAN = MAC layer protocol
  • Star-of-stars topology with gateways relaying to network servers
  • Three device classes (A, B, C) for different latency/power requirements
  • Spreading factors (SF7-SF12) trade range for data rate
  • OTAA provides secure, scalable device activation
  • AES-128 encryption with end-to-end security
  • Ideal for battery-powered sensors in agriculture, smart cities, asset tracking
  • Compare with NB-IoT/LTE-M for cellular alternatives

Next Steps: 1. Set up a free TTN account and register your first device 2. Build a simple sensor node with Arduino or ESP32 3. Experiment with different spreading factors and observe range/battery impact 4. Deploy a multi-sensor network and analyze the data 5. Explore gateway deployment for private networks

1093.5 Summary

This section covered advanced LoRaWAN deployment scenarios:

  • Duty Cycle Compliance: Understanding EU868 1% limits and proper calculation
  • Collision Management: ADR and SF diversity for dense networks
  • Regional Configuration: EU868 vs US915 channel and sub-band management

1093.6 What’s Next

Continue to security and activation topics: