1089 LoRaWAN Quiz: Regional Deployment

1089.1 Learning Objectives

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

Configure Regional Parameters: Understand EU868 vs US915 channel differences
Diagnose Roaming Issues: Troubleshoot international deployment problems
Select Sub-bands: Choose appropriate channel configurations for different networks
Plan Global Deployments: Design firmware for multi-region operation

Prerequisites

Before attempting this quiz, you should be familiar with:

LoRaWAN Overview - Regional frequency bands
LoRaWAN Architecture - Channel and gateway configuration
LPWAN Fundamentals - Regulatory requirements

For Beginners: Quiz Navigation

This is Part 5 of 5 in the LoRaWAN Quiz Bank series.

Quiz	Focus Area
1. Fundamentals	Misconceptions, class selection
2. Battery Optimization	Battery life calculations
3. Network Scalability	Collision analysis, ADR
4. Activation & Security	OTAA vs ABP
5. Regional Deployment	EU868, US915 configuration (You are here)

Return to the Quiz Bank Index for the complete overview.

1089.2 Quiz Questions

Question 1: A logistics company deploys 2,000 LoRaWAN asset trackers (GPS + LoRa) on shipping containers traveling internationally. Trackers send location updates every 15 minutes. After 3 months, European devices work perfectly (99% success), but devices in North America show 80% packet loss despite good RSSI (-85 dBm). What is the most likely configuration error?

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

From the text - Frequency Bands and Regional Parameters:

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:

Device configuration (likely):

// Firmware configured for Europe (EU868):
void setup() {
    os_init();
    LMIC_reset();

    // EU868 channel configuration (common mistake):
    LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7));  // 868.1 MHz
    LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B)); // 868.3 MHz
    LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7));  // 868.5 MHz
    // ... channels 3-7
}

What happens in North America:

US915 Gateway Configuration:

Uplink channels (64 total):
Channel 0:  902.3 MHz
Channel 1:  902.5 MHz
Channel 2:  902.7 MHz
...
Channel 63: 914.9 MHz

Gateway listens on: 902-915 MHz (8 channels per sub-band)
Device transmits on: Wrong sub-band or wrong channels

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: ~20% (only when channels occasionally match)

Why 80% Packet Loss (20% Success)?

Channel mismatch probability:

Gateway listens: 8 channels (out of 64 US915 channels)
Device transmits: Randomly among 64 channels (or wrong 8)

If device uses wrong sub-band:
- Probability gateway hears: ~12.5-25% (some overlap possible)
- Matches observed ~20% success rate

Correct US915 Configuration:

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

    #ifdef CFG_us915
        // Disable all 72 channels (64 uplink + 8 500kHz uplink)
        for(int i=0; i<72; i++) {
            LMIC_disableChannel(i);
        }

        // Enable only channels 8-15 (TTN standard sub-band 2)
        for(int i=8; i<=15; i++) {
            LMIC_enableChannel(i);
        }
        // Also enable corresponding 500kHz channel
        LMIC_enableChannel(65);  // 903.0 MHz, 500kHz BW

        // Or simply use:
        LMIC_selectSubBand(1);  // Selects channels 8-15 (sub-band 2)
    #endif

    #ifdef CFG_eu868
        // EU868 channels are enabled by default
        // No additional configuration needed
    #endif
}

Why Other Options Are Wrong:

A: Hardware Replacement for Frequency Change

Modern LoRa radios support multiple frequency bands:

Semtech SX1276/SX1278:
- Frequency range: 137-1020 MHz
- Can operate in 433, 868, 915 MHz bands
- NO hardware change needed

Frequency configuration (software only):
// Change from EU868 to US915 (no hardware change):
void setFrequency(uint32_t freq_hz) {
    uint64_t frf = ((uint64_t)freq_hz << 19) / 32000000;
    writeRegister(RegFrfMsb, (frf >> 16) & 0xFF);
    writeRegister(RegFrfMid, (frf >> 8) & 0xFF);
    writeRegister(RegFrfLsb, frf & 0xFF);
}

Hardware replacement is NEVER needed for EU868 to US915 migration.

B: Time Zone Configuration for RX Windows

Receive window timing is relative, not absolute:

// LoRaWAN RX windows:
void transmit_uplink() {
    send_packet();  // T=0

    delay(1000);    // 1 second (RX1 delay)
    open_rx1_window();  // Listen for 1 second

    delay(1000);    // 2 seconds total (RX2 delay)
    open_rx2_window();  // Listen for 1 second
}

RX windows use relative timing, not wall-clock time: - RX1: Opens 1 second after uplink transmission - RX2: Opens 2 seconds after uplink transmission - Time zone (hours) completely irrelevant

D: FSK vs LoRa Modulation

LoRaWAN exclusively uses LoRa CSS modulation:

Physical layer: LoRa CSS (Chirp Spread Spectrum)
- NOT FSK (Frequency Shift Keying)

All LoRaWAN gateways and devices MUST use LoRa CSS
Gateway cannot be misconfigured to FSK for LoRaWAN

Multi-Region Firmware Solution:

// Auto-detect region based on GPS location:
void configure_region_from_gps() {
    float lat = gps.latitude();
    float lon = gps.longitude();

    if(lat >= 35 && lat <= 72 && lon >= -12 && lon <= 40) {
        // Europe
        configure_eu868();
    } else if(lat >= 24 && lat <= 50 && lon >= -125 && lon <= -66) {
        // North America
        configure_us915();
    } else if(lat >= -10 && lat <= 25 && lon >= 95 && lon <= 140) {
        // Asia-Pacific
        configure_as923();
    } else {
        // Default to most permissive
        configure_us915();
    }
}

Expected results after fix:

Before (EU868 config in US915 region):

Packet success rate: 20%
Channel overlap: Minimal
Data loss: 80%

After (Proper US915 config):

Packet success rate: 99%
Channel overlap: 100% (all transmissions on correct channels)
Data loss: <1%

Real-world case study:

Global asset tracking company (similar scenario): - 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 - Lesson: Always test in target region before mass deployment

Question 2: You’re deploying LoRaWAN sensors in both the EU and US. Your EU868 devices transmit every 10 minutes without issues. When you deploy identical firmware (only frequency changed) in the US, you receive warnings about “excessive transmission rate” from The Things Network. What regulatory difference explains this, and how should you adjust?

Explanation: This demonstrates the difference between regulatory limits and network policies:

Regulatory Comparison:

Parameter	EU868	US915
Duty Cycle	1% legal limit	None (FCC Part 15)
Max Power	+14 dBm (25 mW)	+30 dBm (1 W)
Channels	8 default	64 uplink

Key Insight:

EU868 has legal duty cycle limits:

1% duty cycle = max 36 seconds per hour transmission
After transmitting, must wait 99x the transmission time

Example:
- SF7, 51-byte payload: 61 ms airtime
- Post-TX wait: 61 ms x 99 = 6,039 ms (6 seconds)
- Can transmit 36,000 ms / 61 ms = 590 messages/hour

US915 has NO regulatory duty cycle limit:

FCC Part 15.247 requirements:
- Frequency hopping across 50+ channels, OR
- Digital modulation with 500 kHz bandwidth

LoRa meets digital modulation requirement
No mandated off-time between transmissions

Why TTN Warns About “Excessive Transmission”:

The Things Network Fair Use Policy:

Even though US915 has no regulatory duty cycle, TTN enforces a Fair Use Policy to prevent network abuse:

TTN Fair Use Policy:
- Max 30 seconds airtime per device per day
- Max 10 downlinks per device per day

Calculation:
- SF7, 51-byte payload: 61 ms per message
- 30,000 ms / 61 ms = 492 messages/day maximum
- 492 / 24 hours = 20.5 messages/hour

Your configuration:
- Every 10 minutes = 6 messages/hour = 144 messages/day
- Airtime: 144 x 61 ms = 8,784 ms/day (well under 30,000 ms)

Why Warning Then?

Possible causes: 1. Using higher SF than necessary (SF12 = 1318 ms, 22x more airtime) 2. Large payload (100+ bytes increases airtime) 3. Retransmissions (failed deliveries trigger retries) 4. Confirmed uplinks (each requires ACK, doubling effective airtime)

Example with SF12:

SF12, 51-byte payload: 1318 ms per message
144 messages/day x 1318 ms = 189,792 ms = 190 seconds/day
TTN limit: 30 seconds/day
Violation: 6.3x over Fair Use Policy

Solution: Enable ADR and Optimize

void setup() {
    // Enable ADR for automatic SF optimization
    LMIC_setAdrMode(1);

    // Don't force high SF
    // Let network optimize based on signal quality

    // Consider longer interval if not time-critical
    TX_INTERVAL = 900;  // 15 minutes instead of 10
}

Why Other Options Are Wrong:

A: “US915 has stricter power limits”

Actually opposite - US915 allows MORE power:

EU868: +14 dBm (25 mW) EIRP maximum
US915: +30 dBm (1 W) for frequency hopping, +21 dBm for LoRa

US915 power advantage: 16 dB higher potential

C: “Requires FHSS across 64 channels”

LoRa uses digital modulation, not FHSS:

FCC Part 15.247 options:
1. Frequency Hopping Spread Spectrum (FHSS): 50+ hop channels
2. Digital Modulation: >500 kHz bandwidth

LoRa uses:
- Chirp Spread Spectrum (digital modulation)
- 125 kHz or 500 kHz bandwidth
- Meets digital modulation requirement
- Does NOT require hopping across all 64 channels

D: “Different packet format requiring longer preambles”

LoRaWAN packet format is identical across regions:

Same format worldwide:
[Preamble | PHDR | PHDR_CRC | PHYPayload | CRC]

Regional differences affect:
- Frequency (channels)
- Power limits
- Duty cycle
- NOT packet format

Best Practices for Multi-Region Deployment:

#if defined(CFG_eu868)
    #define TX_INTERVAL 600    // 10 minutes (duty cycle limited)
    #define USE_ADR 1
#elif defined(CFG_us915)
    #define TX_INTERVAL 900    // 15 minutes (Fair Use Policy)
    #define USE_ADR 1          // Critical for airtime reduction
#endif

void setup() {
    LMIC_setAdrMode(USE_ADR);

    // For US915: Select TTN sub-band
    #ifdef CFG_us915
        LMIC_selectSubBand(1);  // Channels 8-15
    #endif
}

TTN Fair Use Compliance Checklist:

Check	Target	Your Config
Daily airtime	< 30 seconds	Calculate: msgs x ToA
Downlinks	< 10 per day	Use unconfirmed uplinks
ADR enabled	Yes	Reduces SF, saves airtime
Payload optimized	< 51 bytes	Remove unnecessary data

1089.3 Visual Reference Gallery

Visual: Sigfox vs LoRaWAN Comparison

Sigfox vs LoRaWAN comparison diagram showing differences in bandwidth, data rate, message limits, deployment models, and coverage characteristics.

Sigfox LoRaWAN Comparison

Technology comparison for LPWAN selection questions, highlighting regional deployment differences.

1089.4 Summary

This chapter covered regional deployment concepts for LoRaWAN networks:

Regional Parameters: EU868 vs US915 channel configuration differences
Duty Cycle vs Fair Use: Regulatory limits vs network policies
Multi-Region Firmware: GPS-based automatic region detection
Sub-band Selection: Configuring devices for specific network operators

1089.5 What’s Next

You have completed the LoRaWAN Quiz Bank! Return to the Quiz Bank Index for the overview, or continue to related topics:

LPWAN Alternatives: Continue to Sigfox Review to learn about ultra-narrowband LPWAN technology
Protocol Comparison: Review LPWAN Comparison for side-by-side analysis of LoRaWAN, Sigfox, and NB-IoT
Network Layer: Advance to 6LoWPAN for IPv6 over low-power wireless networks

Review other quiz chapters: - Fundamentals Quiz - Misconceptions and class selection - Battery Optimization Quiz - Battery life calculations - Network Scalability Quiz - Collision analysis and ADR - Activation & Security Quiz - OTAA vs ABP