1064  LPWAN Practice Quizzes and Videos

1064.1 Introduction

This chapter provides comprehensive practice quizzes and video tutorials to reinforce your understanding of LPWAN technologies. The quizzes cover technology selection, cost analysis, duty cycle compliance, and real-world deployment scenarios.

TipLearning Objectives
  • Apply LPWAN technology selection criteria to real-world scenarios
  • Perform Total Cost of Ownership (TCO) analysis for LPWAN deployments
  • Calculate duty cycle compliance for LoRaWAN devices
  • Evaluate trade-offs between LoRaWAN, Sigfox, and cellular IoT

Question 17: A logistics company tracks 50,000 shipping containers globally using Sigfox. After 3 years, Sigfox operator coverage disappears in a key region due to bankruptcy. What is their BEST mitigation strategy going forward?

💡 Explanation: Option C (NB-IoT/LTE-M) is the most pragmatic solution for global shipping logistics:

Analysis of each option:

Option A - LoRaWAN private network: - Pros: Full control, zero recurring costs after deployment - Cons: - Infeasible global coverage: 50,000 containers move globally - cannot deploy gateways at every port, warehouse, rail yard, and transit route worldwide - Mobility challenge: Containers move between ocean, rail, truck - LoRaWAN is designed for stationary sensors, not high mobility - Deployment complexity: Installing gateways in foreign countries involves permits, power, backhaul, maintenance - Cost: 1,000+ gateways × $1,500 = $1.5M upfront + ongoing maintenance - Verdict: ❌ Impractical for global mobile asset tracking

Option B - Alternative Sigfox operators: - Pros: Minimal device changes (same hardware/firmware) - Cons: - Same risk: Dependence on Sigfox ecosystem; if one operator failed, others may follow - Coverage gaps: Sigfox is unavailable or unreliable in many countries (e.g., China, Russia) - No global roaming: Sigfox roaming is limited; containers crossing regions may lose connectivity - Technology lock-in: Sigfox ecosystem is declining; betting on recovery is risky - Verdict: ⚠️ Short-term fix but doesn’t address fundamental risk

Option C - NB-IoT/LTE-M cellular: - Pros: - Global coverage: Cellular networks in 190+ countries; containers stay connected worldwide - Carrier redundancy: Multi-IMSI SIMs connect to multiple carriers; if one fails, others provide coverage - Mobility support: LTE-M designed for mobile assets with full handover at vehicular speeds - No infrastructure: Leverages existing carrier networks; no gateway deployment needed - Future-proof: 4G/5G cellular is long-term bet; carriers won’t disappear like LPWAN startups - Cons: - Higher cost: $24-120/device/year subscription (50,000 devices × $50/year = $2.5M/year) - Device replacement: Must replace 50,000 Sigfox devices with cellular modules ($20 each = $1M hardware) - Higher power: Cellular consumes more power than Sigfox (but containers have rechargeable batteries/solar) - Total cost (10 years): $1M hardware + $25M subscriptions = $26M - Verdict: ✓ Most reliable solution for global logistics

Option D - Hybrid LoRaWAN + Satellite: - Pros: - LoRaWAN for controlled environments (ports/warehouses) - Satellite IoT (Iridium, Swarm) for oceanic/remote transit - Cons: - Complexity: Managing 3 technologies (LoRaWAN, satellite, transitional) - Satellite cost: $10-50/device/month = $500,000-$2.5M/month for 50,000 devices! - Power: Satellite transmission consumes 10× cellular (drains batteries on weeks-long ocean voyages) - Latency: Satellite IoT has minutes-to-hours latency - Verdict: ⚠️ Niche use case but very expensive and complex

Decision Matrix:

Option Coverage Reliability Cost (10yr) Complexity Mobility
LoRaWAN Regional Medium $2-5M High Poor
Alt. Sigfox Spotty Low $10M Low Poor
NB-IoT/LTE-M Global High $26M Low Excellent
Hybrid Global High $50M+ Very High Excellent

Recommended strategy: 1. Immediate: Activate NB-IoT/LTE-M fallback for affected regions (if devices have dual-mode radios) 2. 6-12 months: Gradual device replacement to NB-IoT/LTE-M modules 3. Risk mitigation: Use multi-IMSI SIMs to prevent single-carrier dependency 4. Cost optimization: Negotiate fleet discount with carrier (50,000 devices = bulk pricing power)

Real-world parallel: Maersk, CMA CGM, and other shipping giants use cellular IoT (NB-IoT/LTE-M) for global container tracking because reliable global coverage is non-negotiable. The higher cost ($50/year/device) is offset by operational efficiency (reduces lost containers worth $5,000-50,000 each).

Key lesson: For mission-critical global deployments, cellular IoT’s reliability and ubiquity justify higher cost versus private LPWAN’s deployment complexity or operator LPWAN’s bankruptcy risk.

1064.2 Videos

NoteLPWAN Overview
LPWAN Overview
Lesson 4 — positioning LPWAN technologies and design trade-offs.

Question: A logistics company wants to deploy 10,000 asset trackers that report GPS location + temperature every 15 minutes (96 messages/day). Each message payload is 45 bytes. Battery life must exceed 3 years. They’re evaluating LoRaWAN vs Sigfox. Which technology should they choose and why?

💡 Explanation: This demonstrates LPWAN technology selection based on application constraints:

From the text - LoRaWAN vs Sigfox:

LoRaWAN: - Data rate: 0.3-50 kbps (adaptive) - Max Payload: 243 bytes - Messages/Day: Unlimited (duty cycle limited) - Battery Life: 5-10 years

Sigfox: - Data rate: 100 bps uplink, 600 bps downlink - Max Payload: 12 bytes (uplink) - Messages/Day: 140 uplink, 4 downlink (hard limit) - Battery Life: 10-20 years

Application Requirements vs Technology Capabilities:

Requirement          Value       LoRaWAN     Sigfox      Result
──────────────────────────────────────────────────────────────────
Messages/day         96          ✓ Unlimited ✗ Max 140   Sigfox barely OK
Payload size         45 bytes    ✓ 243 max   ✗ 12 max    Sigfox FAILS
Battery life         3+ years    ✓ 5-10 yr   ✓ 10-20 yr  Both OK
Device count         10,000      ✓ Scalable  ✓ Scalable  Both OK
Bi-directional       Yes (GPS)   ✓ A/B/C     ✗ Limited   LoRaWAN better

Critical Failure Analysis:

Sigfox Payload Constraint:

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
graph LR
    subgraph Required["Required Payload: 45 bytes"]
        R1[GPS Lat: 4 bytes]
        R2[GPS Lon: 4 bytes]
        R3[Altitude: 2 bytes]
        R4[Speed: 2 bytes]
        R5[Heading: 2 bytes]
        R6[Temperature: 2 bytes]
        R7[Battery: 1 byte]
        R8[Device ID: 4 bytes]
        R9[Timestamp: 4 bytes]
        R10[Status Flags: 2 bytes]
        R11[Checksum: 2 bytes]
    end

    subgraph Sigfox["Sigfox Limit: 12 bytes"]
        S1[Only 12 bytes<br/>available]
        S2[Cannot fit<br/>GPS + metadata]
    end

    subgraph LoRaWAN["LoRaWAN: 243 bytes"]
        L1[Fits easily<br/>45 bytes]
        L2[Room for<br/>expansion]
    end

    Required -->|45 bytes| Sigfox
    Required -->|45 bytes| LoRaWAN
    Sigfox -->|✗ FAIL| Result[Sigfox<br/>Cannot Meet<br/>Requirements]
    LoRaWAN -->|✓ OK| Result2[LoRaWAN<br/>Suitable]

    style Required fill:#7F8C8D,color:#fff
    style Sigfox fill:#E67E22,color:#fff
    style LoRaWAN fill:#2C3E50,color:#fff
    style Result fill:#E74C3C,color:#fff
    style Result2 fill:#27AE60,color:#fff

Figure 1064.1: GPS tracker payload requirements vs Sigfox and LoRaWAN limits

Even with extreme compression:

Field Bytes Compression Strategy Issue
Lat/Lon 6 Delta encoding from last position Fails on first message or gaps
Temperature 1 0.5°C resolution, offset from 0°C Low resolution unacceptable for cold chain
Battery 1 Percentage 0-100% Acceptable
Flags 1 Status bits Limited information
Sequence 1 Rolled sequence counter Acceptable
Spare 2 Future use -
Total 12 Fits Sigfox limit Data unusable for logistics

Problems with compression: - No timestamp → cannot detect delayed messages - No device ID → cannot identify tracker - Fragile encoding → prone to data loss - Conclusion: Compression makes data unusable for logistics

Message Frequency Analysis:

Metric Sigfox LoRaWAN Result
Required messages/day 96 96 -
Daily limit 140 ~1440 (duty cycle) LoRaWAN 15× more
Margin 44 msg (31%) 1344 msg Sigfox tight
Retransmission buffer ✗ Eats into quota ✓ Ample headroom LoRaWAN better
Emergency alerts ✗ May exceed limit ✓ Always available LoRaWAN better
Future growth ✗ No room ✓ 15× headroom LoRaWAN better

Complete Technical Comparison:

Real-World Deployment Architecture:

graph TB
    TRACKERS["10,000 Asset Trackers<br/>GPS + Temperature<br/>96 messages/day<br/>45-byte payload"]

    GW["LoRaWAN Gateways<br/>~100 citywide<br/>Coverage: 5km urban"]

    NS["Network Server<br/>Message routing<br/>Deduplication"]

    APP["Application Server<br/>Geofencing<br/>Temperature alerts<br/>Route optimization"]

    DASHBOARD["Logistics Dashboard<br/>Real-time tracking<br/>Fleet management"]

    TRACKERS -->|"LoRaWAN 868/915 MHz<br/>45 bytes, SF7-SF10"| GW
    GW -->|"IP Backhaul"| NS
    NS -->|"MQTT/HTTP"| APP
    APP --> DASHBOARD

    style TRACKERS fill:#e1ffe1
    style GW fill:#e1f5ff

Cost Analysis (5-year TCO for 10,000 devices):

Cost Component LoRaWAN Sigfox Notes
Device modules €150,000 (€15/ea) €100,000 (€10/ea) Sigfox cheaper hardware
Gateways €0 (public network) €0 (operator) -
Subscriptions (5yr) €600,000 (€12/dev/yr) €500,000 (€10/dev/yr) Sigfox €100k cheaper
5-Year TCO €750,000 €600,000 Sigfox €150k savings
Decision ✓ REQUIRED ✗ FAILS Sigfox can’t support 45-byte payload

Conclusion: Despite Sigfox being €150,000 cheaper, it cannot meet requirements due to 12-byte payload limit. LoRaWAN is the only viable option.

Why other options are incorrect:

Option A (Sigfox lower power - WRONG):

While Sigfox does have excellent power consumption:
- 10-20 year battery life vs LoRaWAN 5-10 years
- Ultra-narrow band modulation = less power

HOWEVER: Power savings are irrelevant if payload won't fit!
- Cannot transmit required 45 bytes
- Application is impossible on Sigfox
- Power efficiency doesn't matter if it doesn't work

Analogy: "This car gets amazing MPG!"
         "But it can't carry my cargo"
         → Wrong vehicle regardless of efficiency

Option C (Both work equally - WRONG):

Technologies are NOT equivalent:

Sigfox limitations:
  ✗ 12-byte payload < 45-byte requirement
  ✗ 140 msg/day has only 31% margin
  ✗ 4 downlinks/day insufficient for commands
  ✗ Cannot handle retransmissions well

LoRaWAN advantages:
  ✓ 243-byte payload > 45-byte requirement (5.4× margin)
  ✓ Unlimited messages (duty cycle allows 1440/day)
  ✓ Bi-directional communication for commands
  ✓ Adaptive data rate optimizes power/range

Clear winner: LoRaWAN

Option D (Neither suitable - WRONG):

LoRaWAN is perfectly suitable:
  ✓ Payload: 45 bytes << 243 max
  ✓ Messages: 96/day << 1440 capacity
  ✓ Battery: 7 years >> 3 year requirement
  ✓ Scale: Supports 10,000 devices easily
  ✓ Cost-effective: €750k vs €2M+ for cellular

Cellular would work but is overkill:
  - Higher device cost (€25 vs €15)
  - Monthly data fees (€3 vs €1/device)
  - Shorter battery life (2-3 years vs 7)
  - 5-year TCO: €2M+ vs €750k

No need for cellular when LoRaWAN meets all requirements

Practical Implementation Configuration:

Parameter Value Purpose
Spreading Factor Adaptive (SF7-SF10) Optimize range vs airtime
TX Power 14 dBm (25 mW) Standard EU868 limit
Frequency Plan EU868 or US915 Regional ISM band
Device Class Class A Lowest power consumption
Adaptive Data Rate Enabled Auto-optimize SF
Confirmed Uplinks Disabled Save battery (no ACKs)
Redundancy Gateway diversity Multiple gateways receive

Battery Life Calculation (SF7, 45-byte payload, 96 msg/day):

Component Value Calculation
TX current 120 mA During transmission
TX time 200 ms 45 bytes at SF7
TX per day 96 Every 15 minutes
TX energy/day 0.64 mAh (120 mA × 0.2s / 3600s) × 96
Sleep current 5 μA Deep sleep mode
Sleep energy/day 0.12 mAh (5 μA / 1000) × 24h
Total daily 0.76 mAh/day TX + Sleep
Battery capacity 2400 mAh 2× AA lithium batteries
Battery life 8.6 years 2400 / (0.76 × 365)
vs Requirement 2.9× margin Exceeds 3-year requirement

Summary - Why LoRaWAN is the only choice:

  1. Payload: 45 bytes fits in LoRaWAN (243 max) but exceeds Sigfox (12 max) - DEAL BREAKER
  2. Messages: 96/day well within LoRaWAN capacity, marginal on Sigfox
  3. Battery: Both exceed 3-year requirement
  4. Flexibility: LoRaWAN allows future expansion, Sigfox is maxed out
  5. Downlinks: LoRaWAN unlimited, Sigfox only 4/day

The payload constraint alone eliminates Sigfox, making LoRaWAN the only viable LPWAN option for this application.

Question: A water utility plans to deploy 50,000 smart water meters across a region. Each meter sends one reading per day (24 bytes). Comparing 5-year TCO: Private LoRaWAN costs €1,500/gateway × 30 gateways + €15/sensor + €300/month network server. NB-IoT costs €20/sensor + €1.50/device/month data plan. What is the approximate cost difference favoring the cheaper option?

💡 Explanation: This demonstrates LPWAN TCO analysis for large-scale deployments:

From the text - Cost Analysis Example:

The text provides a detailed cost comparison between private LoRaWAN and cellular IoT for a 50,000 device deployment over 5 years.

Complete Cost Breakdown:

Private LoRaWAN Costs:

  • Initial investment (Year 1):

    Component Calculation Cost
    Gateways 30 × €1,500 €45,000
    Sensors 50,000 × €15 €750,000
    Installation (estimate) – €100,000
    Total initial €895,000

  • Recurring costs (Years 1–5):

    Component Calculation Cost
    Network server €300/month × 12 × 5 €18,000
    Maintenance €5,000/year × 5 €25,000
    Total 5‑year recurring €43,000

5‑year total cost of ownership (TCO): €895,000 + €43,000 = €938,000.

NB‑IoT (Cellular) Costs:

  • Initial investment (Year 1):

    Component Calculation Cost
    Sensors 50,000 × €20 €1,000,000
    Installation (estimate) – €100,000
    Total initial €1,100,000

  • Recurring costs (Years 1–5):

    Component Calculation Cost
    Data plan 50,000 devices × €1.50/month × 12 × 5 €4,500,000

    €1.50/device/month is typical NB‑IoT pricing for low data usage (<1 MB/month).

5‑year total cost of ownership (TCO): €1,100,000 + €4,500,000 = €5,600,000.

Cost Comparison:

Technology 5‑year TCO Breakdown
Private LoRaWAN €938,000 €895k initial + €43k recurring
NB‑IoT cellular €5,600,000 €1.1M initial + €4.5M recurring

Difference: €5,600,000 − €938,000 = €4,662,000 → NB‑IoT costs significantly more. Rounded to the nearest €100k, this is ≈ €4.6M, so the closest multiple‑choice answer is €4.4M.

Year-by-Year Cost Analysis (Cumulative TCO):

Year LoRaWAN TCO NB-IoT TCO Difference LoRaWAN Savings
1 €903,600 €2,000,000 €1,096,400 54% cheaper
2 €912,200 €2,900,000 €1,987,800 69% cheaper
3 €920,800 €3,800,000 €2,879,200 76% cheaper
4 €929,400 €4,700,000 €3,770,600 80% cheaper
5 €938,000 €5,600,000 €4,662,000 83% cheaper

Key Insight: LoRaWAN’s cost advantage grows over time due to minimal recurring costs (€8.6k/year) vs NB-IoT’s massive subscriptions (€900k/year).

Cost Per Device Analysis (50,000 devices):

Metric LoRaWAN NB-IoT Ratio
Total 5-year TCO €938,000 €5,600,000 6.0×
Cost per device (5yr) €18.76 €112.00 6.0×
Cost per device per year €3.75 €22.40 6.0×
Cost per device per month €0.31 €1.87 6.0×

Conclusion: NB-IoT costs 6× more per device due to recurring subscription fees.

Break-Even Analysis:

Component LoRaWAN NB-IoT Difference
Initial investment €895,000 €1,100,000 LoRaWAN €205k cheaper upfront
Monthly recurring €300 €75,000 LoRaWAN saves €74,700/month
Break-even point N/A N/A LoRaWAN cheaper from day 1
Infrastructure ROI 12 months - €895k investment / €74.7k monthly savings

Key Insight: LoRaWAN is cheaper both upfront AND monthly. The infrastructure investment pays for itself in just 12 months through avoided subscription fees. After year 1, all savings (€74.7k/month) are pure profit.

Sensitivity Analysis (Impact of NB-IoT Price Changes):

NB-IoT Price/Month NB-IoT 5y TCO LoRaWAN 5y TCO Savings Break-Even Price
€0.50/device €2,600,000 €938,000 €1,662,000 (64%) -
€1.00/device €4,100,000 €938,000 €3,162,000 (77%) -
€1.50/device €5,600,000 €938,000 €4,662,000 (83%) ← Current
€2.00/device €7,100,000 €938,000 €6,162,000 (87%) -
€2.50/device €8,600,000 €938,000 €7,662,000 (89%) -

Conclusion: LoRaWAN remains cost-effective even if NB-IoT pricing drops to €0.50/month. LoRaWAN would only break even with NB-IoT at ~€0.31/device/month (unrealistic).

Graphical Cost Comparison:

graph TB
    subgraph "LoRaWAN Cost Structure"
    L1["Initial: €895k<br/>(Gateways + Sensors)"]
    L2["Year 1-5: €8.6k/year<br/>(Network server + Maintenance)"]
    L3["5-Year Total: €938k"]
    L1 --> L2
    L2 --> L3
    end

    subgraph "NB-IoT Cost Structure"
    N1["Initial: €1.1M<br/>(Sensors only)"]
    N2["Year 1-5: €900k/year<br/>(Data subscriptions)"]
    N3["5-Year Total: €5.6M"]
    N1 --> N2
    N2 --> N3
    end

    RESULT["LoRaWAN saves €4.66M<br/>(83% cost reduction)"]

    L3 --> RESULT
    N3 --> RESULT

    style L3 fill:#e1ffe1
    style N3 fill:#ffe1e1
    style RESULT fill:#e1f5ff

Why other options are incorrect:

Option B: NB-IoT saves €2M (WRONG)

The calculation clearly shows NB-IoT COSTS more, not saves:
  NB-IoT TCO:    €5,600,000
  LoRaWAN TCO:   €  938,000
  Difference:    €4,662,000

NB-IoT is 6× more expensive, not cheaper!
This option reverses the winner.

Option C: Both cost the same (WRONG)

10% threshold: ±€469,000 from average

Average: (€938k + €5,600k) / 2 = €3,269k
LoRaWAN: €938k (71% below average)
NB-IoT: €5,600k (71% above average)

Difference: €4,662k = 497% of LoRaWAN cost
          = 83% of NB-IoT cost

These are NOT similar costs - they differ by nearly 5× !

Option D: LoRaWAN saves €800k (WRONG)

Actual savings: €4,662,000
Claimed savings: €800,000
Error: €3,862,000 underestimate (83% wrong)

This drastically underestimates LoRaWAN's cost advantage.
The recurring subscription fees dominate cellular TCO.

Key Insight - Why the Difference is So Large:

Cost Type LoRaWAN (5yr) NB-IoT (5yr) Difference % of Total Diff
Initial hardware €895,000 €1,100,000 €205,000 (NB-IoT more) 4%
Recurring (5yr) €43,000 €4,500,000 €4,457,000 96%
Total TCO €938,000 €5,600,000 €4,662,000 100%

Analysis: - 96% of cost difference comes from recurring subscription fees - Initial hardware difference is negligible (€205k = 4%) - NB-IoT sensors cost €5 more (50k × €5 = €250k), but LoRaWAN needs €45k in gateways - This is why scale and duration matter for LPWAN ROI - recurring costs dominate at 50,000 devices over 5 years

Real-World Implications:

Scale Effect:
At 10,000 devices: LoRaWAN saves ~€890k (10× lower scale)
At 50,000 devices: LoRaWAN saves ~€4.66M (original)
At 100,000 devices: LoRaWAN saves ~€9.32M (2× scale)

Time Effect:
After 1 year: LoRaWAN saves ~€1.1M
After 3 years: LoRaWAN saves ~€2.9M
After 5 years: LoRaWAN saves ~€4.7M (original)
After 10 years: LoRaWAN saves ~€8.7M

The larger the scale and longer the timeframe,
the more dominant LoRaWAN's cost advantage becomes.

Summary:

Private LoRaWAN saves approximately €4,400,000-€4,600,000 over 5 years compared to NB-IoT for this 50,000 device deployment. The savings come primarily from eliminating per-device subscription fees (€4.5M) while requiring only minimal recurring costs for network infrastructure (€43k). This makes LPWAN extremely cost-effective for large-scale, long-term sensor deployments with infrequent, small data transmissions.

Question: A LoRaWAN deployment in Europe (ETSI regulations) operates in the 868 MHz band with 1% duty cycle limitation. A device sends 20-byte messages at SF7 (airtime ~41ms per message). What is the maximum number of messages this device can send per hour while remaining compliant?

💡 Explanation: This demonstrates LPWAN duty cycle calculations and regulatory compliance:

From the text - Duty Cycle Limitations:

Europe (ETSI): - Typical duty cycle: 1% (36 seconds per hour) - Some sub-bands allow 10% duty cycle - Power limits: Typically +14 to +25 dBm

Duty Cycle Definition:

Duty Cycle = (Transmission Time / Total Time) × 100%

1% duty cycle means:
  - Can transmit for 1% of time
  - Must be silent for 99% of time

In one hour (3600 seconds):
  - Allowed transmission: 3600 × 0.01 = 36 seconds
  - Required silence: 3600 × 0.99 = 3564 seconds

Complete Calculation (EU868, 1% Duty Cycle, SF7, 20-byte payload):

Step Calculation Result Notes
1. Allowed airtime 3600s × 1% 36 seconds/hour ETSI 1% limit
2. Convert to ms 36s × 1000 36,000 ms/hour -
3. Message airtime SF7, 20 bytes 41 ms/message From Semtech formula
4. Max messages 36,000 ms ÷ 41 ms 878 messages/hour Floor(878.04)
5. Verify compliance 878 × 41 ms = 35,998 ms 0.9999% duty cycle ✓ Compliant
6. Optimal interval 3600s ÷ 878 4.1 seconds Even distribution

Conclusion: With 1% duty cycle and SF7, a LoRaWAN device can send 878 messages/hour (one every 4.1 seconds) while remaining compliant.

Why 878 messages/hour is correct:

Mathematical proof:
─────────────────────────────────────────────────────────
Given:
  - Duty cycle limit: 1% per hour
  - Hour duration: 3600 seconds = 3,600,000 milliseconds
  - Message airtime: 41 milliseconds
  - Payload: 20 bytes at SF7

Calculate maximum messages:
  1. Allowed airtime = 3,600,000 ms × 1%
                     = 36,000 ms

  2. Messages per hour = 36,000 ms ÷ 41 ms/message
                       = 878.04 messages

  3. Round down to integer: 878 messages ✓

  4. Remaining airtime = 36,000 - (878 × 41)
                       = 36,000 - 35,998
                       = 2 ms (insufficient for another message)

LoRa Airtime Calculation:

The airtime for a LoRa transmission depends on spreading factor, payload size, bandwidth, and coding rate. For a 20-byte payload at SF7 with 125 kHz bandwidth and coding rate 4/5:

  • Airtime ≈ 41 ms (based on Semtech AN1200.22 formula)
  • This includes preamble (8 symbols + 4.25) and payload symbols
  • Symbol duration at SF7: 1.024 ms

Message Scheduling:

With 878 messages/hour maximum capacity: - Optimal interval: 4.1 seconds between messages - Evenly distribute transmissions across the hour - Avoid burst transmission to minimize collisions - Example schedule: Message 1 at :00, Message 2 at :04, Message 3 at :08…

Spreading Factor Impact on Capacity:

SF Airtime Max Msg/Hour Interval Range
7 41 ms 878 4.1s 2km
8 72 ms 500 7.2s 3km
9 144 ms 250 14.4s 5km
10 267 ms 134 26.7s 7km
11 524 ms 68 52.4s 11km
12 1024 ms 35 102.4s 15km

Trade-off: Lower SF = more messages but shorter range; Higher SF = fewer messages but longer range

Why other options are incorrect:

Option A: 36 messages/hour (WRONG)

This confuses SECONDS of airtime with NUMBER of messages:

Correct interpretation:
  - 36 seconds of transmission allowed per hour
  - Each message takes 41 milliseconds
  - 36 seconds = 36,000 milliseconds
  - 36,000 ms ÷ 41 ms = 878 messages

Incorrect interpretation (Option A):
  - 36 seconds ÷ 1 second/message = 36 messages
  - This assumes each message takes 1 second (WRONG!)
  - Actual message time: 41 ms = 0.041 seconds

Error: Confusing airtime duration with message count

Option C: 1440 messages/hour (WRONG)

Verification:
  Messages: 1440
  Airtime per message: 41 ms
  Total airtime: 1440 × 41 ms = 59,040 ms = 59.04 seconds

Duty cycle check:
  Actual: 59.04 / 3600 = 1.64%
  Limit: 1.0%
  Result: EXCEEDS LIMIT BY 64% ✗

This would violate ETSI regulations!
Transmitter would face:
  - Automatic shutdown by device
  - Fines from regulatory authority
  - License revocation (if applicable)

1440 = 60 minutes × 24 = minutes/day
This appears to be confusion with daily message counts

Option D: 140 messages/hour (WRONG)

This is Sigfox's DAILY limit divided by 24 hours:
  - Sigfox: 140 messages per DAY
  - 140 / 24 hours = 5.83 messages per hour

But this question is about LoRaWAN, not Sigfox!

LoRaWAN limitations:
  - Based on duty cycle (1% airtime)
  - No hard message limit
  - Dependent on spreading factor and payload

Sigfox limitations:
  - Hard limit: 140 messages per day
  - Network enforced
  - Independent of airtime

These are different constraint mechanisms:
  LoRaWAN: Physics-based (airtime) → 878/hour possible
  Sigfox: Network-based (quota) → 5.8/hour average

Comparing: 878 vs 5.8 = LoRaWAN allows 151× more messages!

Practical Application - Smart Parking:

A parking sensor updating every 5 minutes demonstrates efficient duty cycle usage:

  • Update frequency: Every 5 minutes = 12 messages/hour
  • Max capacity at SF7: 878 messages/hour
  • Duty cycle used: 0.01% (12 × 41ms ÷ 3,600,000ms)
  • Utilization: Only 1.4% of available capacity
  • Headroom: Could support 73× more messages if needed

This shows how LPWAN excels at infrequent updates—the sensor transmits for only 0.5 seconds per hour while maintaining fresh parking status data.

Summary:

With 1% duty cycle (36 seconds/hour) and 41ms airtime per message: - Maximum messages = 36,000 ms ÷ 41 ms = 878 messages/hour - This is equivalent to one message every ~4.1 seconds - Actual duty cycle: 0.9999% (fully compliant) - Spreading factor trade-off: SF7 maximizes message capacity but limits range

The key insight is that duty cycle limits AIRTIME, not message count. Efficient modulation (low SF) allows more messages within the same airtime budget.

Question 13: A company evaluates LPWAN options for 10,000 remote agricultural sensors across 200 km². Each sensor reports soil data (50 bytes) twice daily for 10 years. Cellular coverage exists but is spotty. They can install infrastructure on water towers and grain silos. What is the MOST cost-effective strategy?

💡 Explanation: Private LoRaWAN (C) is most cost-effective at this scale:

Cost Analysis:

LoRaWAN (Private): - Sensors: 10,000 × $15 = $150,000 - Gateways: 200 km² ÷ 4 km² per gateway = 50 gateways × $1,500 = $75,000 - Network server: $5,000/year × 10 years = $50,000 - Total: $275,000 over 10 years

Sigfox (Operator): - Sensors: 10,000 × $10 = $100,000 - Subscription: 10,000 × $6/year × 10 years = $600,000 - Total: $700,000 (2.5× more than LoRaWAN)

NB-IoT (Cellular): - Sensors: 10,000 × $20 = $200,000 - Subscription: 10,000 × $24/year × 10 years = $2,400,000 - Total: $2,600,000 (9.5× more than LoRaWAN!)

Why LoRaWAN wins: 1. Infrastructure control - Company owns water towers and grain silos (perfect gateway locations) 2. Zero recurring costs - No subscriptions after initial deployment 3. Scale economics - At 10,000 devices, gateway cost ($75k) amortizes to $7.50/device 4. Coverage - 200 km² rural area well-suited for LoRa’s 15km range 5. 10-year lifespan - Private network costs are upfront; cellular costs compound annually

Hybrid approach (D) would cost more than pure LoRaWAN while adding complexity. Since they can install gateways on existing structures, achieving 100% LoRaWAN coverage is feasible.

ROI calculation: LoRaWAN saves $425k-$2.3M over alternatives. Payback period: Immediate (no recurring costs vs. $60k-$240k/year for alternatives).

Question 15: A university deploys 500 environmental sensors across campus (2 km²) using LoRaWAN. After 2 years, they want to add building energy monitoring (1,500 sensors) requiring 10-second update intervals. What challenge will they face?

💡 Explanation: Option D is correct - Duty cycle is the critical constraint:

EU868 Duty Cycle Calculation:

Regulation: 1% duty cycle in 868 MHz ISM band = 36 seconds of transmission per hour per device.

Current deployment (environmental sensors): - Assume hourly updates: 24 messages/day - Airtime per message (SF7, 50 bytes): ~100 ms - Daily airtime: 24 × 0.1 sec = 2.4 seconds - Hourly airtime: 2.4 / 24 = 0.1 seconds - Duty cycle: 0.1 / 3600 = 0.0028% ✓ (well under 1%)

Proposed energy monitoring (10-second updates): - Messages per day: 86,400 sec/day ÷ 10 sec = 8,640 messages/day - Messages per hour: 360 messages/hour - Airtime per message: 100 ms (SF7, assume 20-byte payload) - Hourly airtime: 360 × 0.1 = 36 seconds - Duty cycle: 36 / 3600 = 1.0% (exactly at limit!)

Problem: This assumes perfect conditions (SF7, minimum payload). Reality: - Varying SF (SF8-SF10 for indoor sensors): 200-400 ms airtime - With SF9 (200 ms): 360 × 0.2 = 72 seconds/hour = 2% duty cycle ✗ VIOLATION - Penalties: €10,000-100,000 fines, equipment confiscation, network shutdown

Solutions: 1. Reduce update rate: 60-second updates instead of 10-second 2. Use NB-IoT: Licensed spectrum has no duty cycle restrictions 3. Deploy Wi-Fi/Ethernet: Higher bandwidth, no duty cycle limits 4. Aggregate data: Send batched readings every 60 seconds

Why other options are wrong:

A - Capacity limit: LoRaWAN gateways support 10,000-100,000 devices; 2,000 is not a limit. The issue is duty cycle, not device count.

B - Battery life: While true that 10-second updates reduce battery life (from 10 years to 1-2 years), LoRaWAN can still support this. Building energy monitors are typically mains-powered anyway.

C - Range: LoRaWAN excels at indoor penetration (10-20 dB advantage). Indoor sensors easily reach outdoor gateways in a 2 km² campus.

Key lesson: LPWAN is optimized for infrequent updates (minutes to hours). Sub-minute intervals violate regulatory duty cycles and battery/spectrum efficiency assumptions.

1064.3 Summary

In this chapter, you practiced LPWAN technology selection and analysis through comprehensive quizzes covering:

  • Technology Selection: Choosing between LoRaWAN, Sigfox, and cellular IoT based on payload size, message frequency, and mobility requirements
  • TCO Analysis: Calculating 5-year and 10-year total cost of ownership for different deployment scales
  • Duty Cycle Compliance: Understanding EU868 regulatory limits and calculating maximum message rates
  • Real-World Scenarios: Agricultural sensors, shipping containers, water meters, and campus deployments

1064.4 What’s Next

Continue your LPWAN learning journey with: