1069  LPWAN Comparison and Review

1069.1 Learning Objectives

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

  • Compare LPWAN options: Explain the trade-offs between LoRaWAN, Sigfox, NB-IoT, LTE-M, and other LPWAN choices
  • Select by requirements: Choose a technology based on range, power, payload, latency, mobility, and cost constraints
  • Validate assumptions: Spot common mismatches (e.g., downlink needs, mobility, duty cycle limits) that break deployments

1069.2 Prerequisites

Before you start, it helps to review:

1069.3 LPWAN Comparison Matrix

⏱️ ~10 min | ⭐⭐ Intermediate | 📋 P09.C04.U01

Use this as a quick “first pass” filter. Always confirm with regional regulations, operator coverage, and your device’s real duty cycle and payload profile.

Technology Strengths Typical Constraints Best Fit
LoRaWAN Private or public networks, long range, good battery life, flexible deployments Limited payload and downlink, duty cycle limits, higher latency Smart city sensing, metering, asset tracking (low update rates)
Sigfox Extremely low power, simple uplink model, long range Very limited messages/day and payload, constrained downlink Simple telemetry, alarms, low-volume metering
NB-IoT Deep indoor coverage, operator-managed, higher reliability than unlicensed LPWAN Operator dependency, higher complexity/cost, latency variability Utility metering, indoor sensors, deployments needing managed QoS
LTE-M Mobility support, higher throughput, lower latency than NB-IoT Higher power than unlicensed LPWAN, operator dependency Mobile assets, wearables, firmware updates, voice/SMS (where applicable)
Weightless (family) Multiple variants for different needs Ecosystem and availability vary by region Niche deployments where supported

1069.3.1 LPWAN Selection Decision Tree

Use this decision tree to quickly narrow down your LPWAN choice based on key requirements:

%% fig-alt: "Decision tree flowchart for selecting LPWAN technology. Starting with mobility requirement, branches to LTE-M if mobile. For stationary devices, checks downlink needs (NB-IoT for heavy downlink), then payload size (Sigfox for tiny payloads), then coverage (NB-IoT for deep indoor), and finally network preference (LoRaWAN for private, NB-IoT for carrier-managed)."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#ECF0F1'}}}%%
flowchart TD
    START([Start: Select LPWAN]) --> Q1{Device moves<br/>during operation?}

    Q1 -->|Yes, mobile| LTE[**LTE-M**<br/>Mobility + handover]
    Q1 -->|No, stationary| Q2{Frequent downlink<br/>or OTA updates?}

    Q2 -->|Yes, heavy downlink| Q3{Indoor/basement<br/>deployment?}
    Q2 -->|No, mostly uplink| Q4{Payload size?}

    Q3 -->|Deep indoor| NB1[**NB-IoT**<br/>Best indoor penetration]
    Q3 -->|Outdoor/shallow| LTE2[**LTE-M**<br/>Better throughput]

    Q4 -->|< 12 bytes, < 140 msgs/day| SIG[**Sigfox**<br/>Ultra-simple, lowest power]
    Q4 -->|Larger payloads needed| Q5{Private network<br/>preferred?}

    Q5 -->|Yes, own infrastructure| LORA[**LoRaWAN**<br/>Flexible, private/public]
    Q5 -->|No, carrier-managed| Q6{Deep indoor<br/>coverage needed?}

    Q6 -->|Yes| NB2[**NB-IoT**<br/>Carrier + indoor]
    Q6 -->|No| LORA2[**LoRaWAN**<br/>Public network]

    style LTE fill:#16A085,color:#fff
    style LTE2 fill:#16A085,color:#fff
    style NB1 fill:#E67E22,color:#fff
    style NB2 fill:#E67E22,color:#fff
    style SIG fill:#9B59B6,color:#fff
    style LORA fill:#2C3E50,color:#fff
    style LORA2 fill:#2C3E50,color:#fff

1069.3.2 LPWAN Trade-off Comparison

This diagram shows where each technology sits on the power vs. data rate spectrum:

%% fig-alt: "Quadrant diagram comparing LPWAN technologies on two axes: power consumption (vertical) and data rate (horizontal). Sigfox sits at lowest power and lowest data rate. LoRaWAN is low power with low-medium data rate. NB-IoT is medium power with medium data rate. LTE-M is highest power with highest data rate. Arrows show the trade-off progression."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22'}}}%%
flowchart LR
    subgraph Power["⚡ Power Consumption"]
        direction TB
        LOW["Lowest"]
        MED["Medium"]
        HIGH["Highest"]
    end

    subgraph Tech["LPWAN Technologies"]
        SIG["**Sigfox**<br/>100 bps<br/>~10 μA sleep"]
        LORA["**LoRaWAN**<br/>0.3-50 kbps<br/>~1 μA sleep"]
        NB["**NB-IoT**<br/>~250 kbps<br/>~3 μA PSM"]
        LTE["**LTE-M**<br/>~1 Mbps<br/>~3 μA PSM"]
    end

    subgraph Rate["📶 Data Rate"]
        direction TB
        R1["100 bps"]
        R2["50 kbps"]
        R3["1 Mbps"]
    end

    SIG --> LORA --> NB --> LTE

    style SIG fill:#9B59B6,color:#fff
    style LORA fill:#2C3E50,color:#fff
    style NB fill:#E67E22,color:#fff
    style LTE fill:#16A085,color:#fff

1069.4 Selection Checklist

⏱️ ~8 min | ⭐⭐ Intermediate | 📋 P09.C04.U02

Answer these questions before you pick a protocol:

  1. Payload + frequency: How many bytes per message, and how often (worst case)?
  2. Downlink needs: Do you need remote actuation, config, or OTA updates?
  3. Mobility: Does the device move (handover, roaming, speed)?
  4. Coverage: Indoor depth, basements, rural range, and operator footprint.
  5. Power budget: Battery size, expected lifetime, and peak current limits.
  6. Cost model: Hardware BOM, certification, SIM/subscription, gateway ownership.

1069.5 Knowledge Check

Test your understanding of LPWAN technology comparisons with these scenario-based questions.

Question 1: A smart street lighting system needs to receive dimming commands from a central controller within 2-3 seconds. Which LoRaWAN device class is most appropriate?

Explanation: Class C is correct for actuator control requiring low-latency downlinks.

LoRaWAN Device Class Comparison:

Class Downlink Latency Power Consumption Use Case
Class A Seconds to hours (waits for uplink) Lowest (battery-powered) Sensors, meters
Class B Scheduled (128ms-4s windows) Medium Periodic commands
Class C <2 seconds (always listening) Highest (mains-powered) Street lights, actuators

Why Class C for street lights: - Street lights are mains-powered (no battery constraint) - Need immediate response to dimming commands - Continuous receive window enables <2 second latency - Can receive commands anytime without sending uplink first

Why Class A fails: - Must send uplink to open receive window - If light needs dimming at 10:00 PM but last uplink was at 6:00 PM, command waits 4+ hours - Impractical for real-time control

Why Class B is suboptimal: - Better than A (scheduled windows every 128ms-4s) - But requires beacon synchronization - Class C simpler and faster for mains-powered devices

Question 2: A battery-powered soil moisture sensor transmits readings every 4 hours. What LoRaWAN class should it use to maximize battery life?

Explanation: Class A is correct for battery-powered sensors with infrequent data.

Power Consumption by Class:

%% fig-alt: "LoRaWAN Class A vs Class C power consumption comparison. Class A shows long sleep periods at µA with brief TX and RX1/RX2 windows at mA, achieving 10+ year battery life with less than 1% active time. Class C shows continuous RX at mA level with 99% active time, resulting in only days to weeks of battery life."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart TB
    subgraph ClassA["Class A Power Profile"]
        direction LR
        A1["Sleep<br/>µA"] --> A2["TX<br/>mA"] --> A3["RX1<br/>mA"] --> A4["RX2<br/>mA"] --> A5["Sleep<br/>µA"]
    end
    subgraph ClassAStats["Class A Statistics"]
        AS1["Active: <1% of time"]
        AS2["Sleep current: 1-5 µA"]
        AS3["Battery life: 10+ years"]
    end

    subgraph ClassC["Class C Power Profile"]
        direction LR
        C1["RX<br/>mA"] --> C2["TX<br/>mA"] --> C3["RX<br/>mA"]
    end
    subgraph ClassCStats["Class C Statistics"]
        CS1["Active: ~99% of time"]
        CS2["RX current: 10-15 mA"]
        CS3["Battery life: Days to weeks"]
    end

    ClassA ~~~ ClassAStats
    ClassC ~~~ ClassCStats

    style ClassA fill:#16A085,stroke:#2C3E50,color:#fff
    style ClassC fill:#E67E22,stroke:#2C3E50,color:#fff
    style A1 fill:#2C3E50,stroke:#16A085,color:#fff
    style A2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A3 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A4 fill:#E67E22,stroke:#2C3E50,color:#fff
    style A5 fill:#2C3E50,stroke:#16A085,color:#fff
    style C1 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C2 fill:#E67E22,stroke:#2C3E50,color:#fff
    style C3 fill:#E67E22,stroke:#2C3E50,color:#fff

For 4-hour reporting interval: - Class A: 99.9%+ in sleep mode = 10+ year battery life - Class C: Continuous RX = weeks on battery (unsuitable)

Class A trade-off accepted: Downlink commands wait until next uplink (4 hours max) - acceptable for soil sensors that rarely need configuration changes.

Question 3: A logistics company needs to send firmware updates to 10,000 asset trackers. The trackers report location every 6 hours. What is the BEST strategy using LoRaWAN?

Explanation: Class A with fragmented updates (C) is the practical approach for battery-powered asset trackers.

Why Class C fails for battery-powered trackers:

Battery impact of Class C:
- RX current: ~15 mA continuous
- 10,000 trackers with coin cell batteries (225 mAh)
- Battery life: 225 mAh / 15 mA = 15 hours!
- Result: All trackers die within days

Class A alternative:
- Sleep current: 2 µA
- TX + RX active <1% of time
- Battery life: 5-10 years

Fragmented firmware update strategy (Class A):

Update Size: 50 KB firmware
LoRaWAN Payload: 50-222 bytes per message (SF-dependent)
Fragments: 50,000 / 50 = 1,000 downlink packets

Distribution Strategy:
1. Tracker sends uplink (location report)
2. Server responds with 1 firmware fragment
3. Tracker acknowledges + sends next uplink
4. Repeat until all fragments received
5. Time to update: 1,000 × 6 hours / 4 = ~62 days per device

Optimization:
- Increase uplink frequency during update window
- Use multicast (LoRaWAN 1.1) for common fragments
- Stagger updates across fleet (not all at once)

Why Class B is suboptimal: - Requires beacon infrastructure - More complex than needed - Class A sufficient for non-urgent updates

Why cellular (D) is overkill: - 10,000 × $24/year = $240,000/year in subscriptions - Firmware updates are infrequent (yearly) - Class A approach works, just slower

Question 1: A parking sensor needs to report occupancy changes and occasionally receive configuration updates. Daily average is 50 status changes. Is Sigfox suitable?

Explanation: Option B is correct - Sigfox constraints are satisfied.

Sigfox Message Limits:

Direction Daily Limit Payload Size Data Rate
Uplink (device → cloud) 140 messages 12 bytes 100 bps
Downlink (cloud → device) 4 messages 8 bytes 600 bps

Parking sensor analysis:

Uplink requirement:
- 50 status changes/day
- Sigfox limit: 140/day
- Usage: 50/140 = 36% ✓ (64% margin for peaks)

Downlink requirement:
- "Occasional" config updates
- Sigfox limit: 4/day
- Typical config changes: 1/week or less
- 4/day is more than enough ✓

Payload check:
- Parking status: 1 byte (occupied/vacant/reserved)
- Timestamp: 4 bytes (optional, can use server time)
- Battery: 1 byte
- Total: 2-6 bytes < 12 bytes ✓

Why other options are wrong: - A: Confuses uplink (140/day) with downlink (4/day) limits - C: Invents a “12-message” limit (doesn’t exist; 140 uplinks allowed) - D: Sigfox supports bidirectional, just heavily asymmetric (140 up vs 4 down)

Key insight: Sigfox is designed for uplink-heavy applications where sensors report frequently but rarely need commands.

Question 2: An industrial monitoring system needs to send 25-byte sensor readings every 10 minutes and receive shutdown commands within 30 seconds. Why is Sigfox NOT suitable?

Explanation: All constraints are violated (D).

Constraint Analysis:

1. Payload size exceeded:

Required: 25 bytes
Sigfox limit: 12 bytes
Shortfall: 13 bytes (cannot fit in single message)
Workaround: Split into 3 messages (9+8+8 bytes)
  → But this uses 3× daily quota per reading!

2. Message frequency exceeded:

Readings: 6/hour × 24 hours = 144 messages/day
Sigfox limit: 140 messages/day
Overage: 4 messages/day (even with 1 msg per reading)
With 3-message fragmentation: 144 × 3 = 432 messages/day
  → 3× over limit!

3. Downlink latency impossible:

30-second shutdown response requirement:
- Sigfox downlink: Only triggered by uplink
- Device must request downlink, then wait 20-25 seconds for response
- If device sends uplink every 10 minutes...
- Worst case: 10 minutes + 25 seconds = 10.4 minutes latency

Even with continuous uplink requests:
- Sigfox is NOT designed for real-time control
- 30-second guarantee is impossible

Correct technology choice: - LoRaWAN Class C: Continuous RX, <2s downlink latency - NB-IoT/LTE-M: TCP-like reliability, <1s latency - Sigfox: Wrong technology for this use case

Key lesson: Sigfox excels at simple, infrequent, small, uplink-only telemetry. Industrial control needs bidirectional, low-latency, larger payloads.

Question 3: Why does Sigfox limit downlinks to only 4 messages per day while allowing 140 uplinks?

Explanation: Power consumption (A) is the primary reason for asymmetric limits.

Power Impact of Downlinks:

%% fig-alt: "Sigfox uplink vs downlink power comparison diagram. Uplink shows TX at 50-100 mW for 2 seconds using 0.05 mWh per message and 7 mWh/day for 140 messages. Downlink shows RX at 10-15 mA for 20-25 seconds using 1 mWh per request. If 140 downlinks were attempted, energy would be 140 mWh/day, reducing battery life from 10 years to less than 1 year."
%%{init: {'theme': 'base', 'themeVariables': {'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D'}}}%%
flowchart LR
    subgraph UP["UPLINK (Device → Cloud)"]
        U1["TX: 50-100 mW<br/>for ~2 seconds"]
        U2["Energy: ~0.05 mWh<br/>per message"]
        U3["140 messages/day:<br/>~7 mWh/day"]
    end

    subgraph DOWN["DOWNLINK (Cloud → Device)"]
        D1["RX: 10-15 mA<br/>for 20-25 seconds"]
        D2["Energy: ~1 mWh<br/>per downlink"]
        D3["4 downlinks/day:<br/>~4 mWh/day"]
    end

    subgraph WARN["If Unlimited Downlinks"]
        W1["140 × 1 mWh =<br/>140 mWh/day"]
        W2["Battery life drops<br/>from 10 years<br/>to <1 year!"]
    end

    UP --> DOWN
    DOWN --> WARN

    style UP fill:#16A085,stroke:#2C3E50,color:#fff
    style DOWN fill:#E67E22,stroke:#2C3E50,color:#fff
    style WARN fill:#E74C3C,stroke:#2C3E50,color:#fff
    style U1 fill:#2C3E50,stroke:#16A085,color:#fff
    style U2 fill:#2C3E50,stroke:#16A085,color:#fff
    style U3 fill:#2C3E50,stroke:#16A085,color:#fff
    style D1 fill:#2C3E50,stroke:#E67E22,color:#fff
    style D2 fill:#2C3E50,stroke:#E67E22,color:#fff
    style D3 fill:#2C3E50,stroke:#E67E22,color:#fff
    style W1 fill:#7F8C8D,stroke:#E74C3C,color:#fff
    style W2 fill:#7F8C8D,stroke:#E74C3C,color:#fff

Design Philosophy: - Sigfox targets 10-20 year battery life - Uplink is “fire and forget” (transmit, then sleep) - Downlink requires listening (20-25 seconds of RX power) - Limiting downlinks to 4/day preserves battery budget

Why other options are incorrect: - B: Base stations can transmit more; limit is device-side - C: No such regulation; ISM band duty cycle allows more - D: Payload size doesn’t determine power; listening time does

Trade-off accepted: Sigfox sacrifices downlink capability for extreme uplink efficiency and multi-year battery life.

Question 1: A utility company deploys 100,000 smart water meters in urban and rural areas. Meters report daily readings and must work for 15+ years on battery. Which technology is most appropriate?

Explanation: NB-IoT (C) is optimal for large-scale utility metering.

Technology Comparison for Utility Metering:

Criterion LoRaWAN NB-IoT LTE-M Sigfox
Indoor/basement coverage Good Excellent (+20 dB MCL) Good Good
Battery life 10+ years 15+ years (PSM/eDRX) 10 years 10-20 years
Operator SLA No (private) Yes Yes Partial
100k+ scale Complex (1000+ gateways) Simple (carrier) Simple Simple
Reliability 95-98% 99.9% 99.9% 95-98%
Cost/device/year $0-5 (private) $6-24 $12-36 $6-12

Why NB-IoT wins:

1. Deep Indoor Coverage:

Water meters often in:
- Basements: -20 to -30 dB attenuation
- Underground pits: -30 to -40 dB attenuation
- Metal enclosures: -20 dB attenuation

NB-IoT MCL (Maximum Coupling Loss): 164 dB
LoRaWAN MCL: ~155 dB
Difference: 9 dB = 2.8× better penetration

Result: NB-IoT reaches meters LoRaWAN cannot

2. 15+ Year Battery Life:

NB-IoT Power Saving Mode (PSM):
- Device sleeps for days/weeks between transmissions
- Wake: Transmit reading → Sleep immediately
- Sleep current: <3 µA
- Daily reading: ~0.5 mWh/day
- 3600 mAh battery: 3600 mWh / 0.5 = 20 years theoretical

vs LoRaWAN:
- Similar power but no carrier QoS
- PSM equivalent requires custom implementation

3. Operator-Managed Scale:

100,000 meters:
- LoRaWAN: Deploy 1,000-2,000 gateways ($1.5-3M infrastructure)
- NB-IoT: Use existing carrier infrastructure ($0 CAPEX)

Maintenance:
- LoRaWAN: Manage gateway firmware, backhaul, failures
- NB-IoT: Carrier handles everything (SLA-backed)

Why other options are suboptimal: - LoRaWAN: Gateway deployment at scale is complex; no SLA - LTE-M: Higher power than NB-IoT; overkill for static meters - Sigfox: Coverage gaps in many countries; no SLA

Question 2: A fleet management company tracks 5,000 delivery trucks across Europe. Trucks need real-time location updates every 30 seconds while moving. Which technology should they choose?

Explanation: LTE-M (B) is designed for mobile IoT applications.

Mobility Support Comparison:

Technology Max Mobility Handover Update Rate
LTE-M 120 km/h+ Yes (cellular) Unlimited
NB-IoT Walking speed No Low
LoRaWAN Stationary No Duty-cycle limited
Sigfox Stationary No 140/day max

Why LTE-M for delivery trucks:

1. Handover Support:

Delivery truck route: Depot → Highway → City → Customer → City → Highway → Depot
Cell towers passed: 50-100 per trip

LTE-M handover:
- Seamless transition between cell towers
- Connection maintained at highway speeds (120+ km/h)
- No data loss during handover

LoRaWAN/Sigfox:
- No handover mechanism
- Device reconnects to nearest gateway/base station
- Works for slow movement, fails for vehicles

2. 30-Second Update Rate:

Updates per day: 24h × 60min × 2/min = 2,880 updates

Sigfox limit: 140/day → 2,880/140 = 20× over limit ❌
LoRaWAN duty cycle: ~1% in EU → ~864 updates max
  With SF7, 50 bytes: ~0.1s airtime → 1% allows 864/day
  Still short: 2,880 needed ❌
LTE-M: Unlimited ✓ (data plan based)

3. Real-Time Location:

Delivery application requirements:
- Customer ETA updates (accurate to minutes)
- Route optimization (real-time traffic)
- Proof of delivery (timestamp + GPS)

LTE-M latency: <100ms ✓
LoRaWAN latency: 1-5 seconds (acceptable)
Sigfox latency: 30-90 seconds ❌ (too slow for real-time)

Why other options fail: - LoRaWAN Class C: No handover; power-hungry for vehicles with alternator - NB-IoT: Poor mobility; designed for stationary devices - Sigfox: 140 msg/day << 2,880 required; no handover

Question 3: A startup has $50,000 to deploy 500 environmental sensors across a national park (50 km²). Sensors report temperature/humidity every hour. No cellular coverage exists. Which approach is most viable?

Explanation: Private LoRaWAN (D) is the only viable option for remote areas without cellular.

Budget Analysis ($50,000):

Option D - Private LoRaWAN:
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Gateways: 5-10 units (50 km² / 7 km radius per gateway)
         10 × $1,000 = $10,000
Sensors:  500 × $25 (module + enclosure) = $12,500
Network server: $0 (ChirpStack self-hosted) or $2,000/year
Solar power: 10 gateways × $500 = $5,000
Installation: $10,000 labor
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Total: ~$40,000 ✓ (within budget)
Ongoing: $0-2,000/year

Coverage:
- Gateway range: 10-15 km (rural line-of-sight)
- 10 gateways: 50 km² coverage achievable
- Redundancy: 2-3 gateways per sensor zone

Why other options fail:

A - NB-IoT with temporary towers:

Temporary cell tower cost: $50,000-100,000 each
Plus carrier agreement: $10,000+/year
Plus installation permits: Months of bureaucracy
Budget: $50,000 << $100,000+ required ❌

B - Sigfox “global coverage”:

Sigfox coverage reality:
- Coverage is urban-focused
- National parks: Typically NO coverage
- Cannot deploy own Sigfox base stations
- Operator won't invest in empty park

Result: Sensors transmit, nothing receives ❌

C - LTE-M with satellite backhaul:

LTE-M requires cellular coverage:
- No coverage = no LTE-M
- Satellite backhaul connects towers, not devices
- Would need cellular tower + satellite link

Satellite IoT alternative (Swarm, Iridium):
- $500/device + $5/month = $255,000/year ❌

LoRaWAN Advantages for Remote Deployment: 1. Deploy anywhere: No carrier dependency 2. Long range: 10-15 km in rural (covers park with few gateways) 3. Low power: 10+ year battery life 4. Low cost: $25-50 per sensor module 5. Self-managed: Full control over network

1069.7 Worked Examples

These worked examples demonstrate the LPWAN technology selection process for real-world deployment scenarios.

NoteWorked Example: Selecting LPWAN for Smart Water Meters

Scenario: A municipal water utility needs to deploy 50,000 smart water meters across a city. Meters must report daily readings, support remote valve shutoff commands, and operate for 15+ years without battery replacement. The city has mixed terrain with urban high-rises, suburban homes, and some basement installations.

Given: - Device count: 50,000 meters - Message frequency: 1 daily reading (small uplink) + occasional valve commands (downlink) - Payload size: 12 bytes (meter reading + battery status + tamper flag) - Required battery life: 15+ years - Coverage requirement: Indoor, including basements - Budget: Minimize total cost of ownership over 15 years

Steps:

  1. Eliminate technologies that fail requirements:
    • Sigfox: 12-byte payload fits, but 4 downlinks/day limit may constrain valve control during emergencies. Eliminate for operational flexibility.
    • LTE-M: Higher power consumption (5-10 year battery typical), higher module cost ($8-15). Overkill for stationary meters. Eliminate.
    • LoRaWAN: Excellent battery life, but requires deploying and maintaining gateway infrastructure across entire city. Calculate 200+ gateways needed.
  2. Compare LoRaWAN vs NB-IoT for this use case:
    • Indoor coverage: NB-IoT has +20 dB MCL advantage (164 dB vs 157 dB). Critical for basement meters.
    • Infrastructure: LoRaWAN requires utility to deploy/maintain gateways. NB-IoT uses existing cellular infrastructure.
    • Scale: 50,000 devices x 15 years = 750,000 device-years of management.
    • Reliability SLA: NB-IoT offers carrier-grade reliability. LoRaWAN reliability depends on utility’s network management.
  3. Calculate 15-year TCO:
    • LoRaWAN: 200 gateways x $800 = $160,000 CAPEX + $50,000/year maintenance + replacement every 7 years = $910,000 over 15 years. Per device: $18.20
    • NB-IoT: $0 infrastructure + $2/year/device subscription = 50,000 x $2 x 15 = $1,500,000. Per device: $30.00
    • Hybrid consideration: LoRaWAN is cheaper IF utility has resources to manage network infrastructure.

Result: Choose NB-IoT. Despite higher subscription cost, the utility avoids infrastructure complexity, gains carrier-grade reliability with SLA, and ensures deep indoor coverage for basement meters. The $11.80/device premium over 15 years is justified by operational simplicity and guaranteed coverage.

Key Insight: For large-scale deployments with deep indoor requirements and no existing IoT infrastructure expertise, operator-managed cellular LPWAN (NB-IoT) often wins despite higher subscription costs. The hidden costs of gateway deployment, backhaul connectivity, and 24/7 network monitoring favor cellular for utilities without IoT operations teams.

NoteWorked Example: LPWAN Selection for Remote Agricultural Sensors

Scenario: A farming cooperative wants to deploy 2,000 soil moisture sensors across 20 farms spread over 150 km² of rural farmland. No cellular coverage exists in most farm areas. Sensors transmit every 4 hours and must last 5+ years on battery.

Given: - Device count: 2,000 sensors across 20 farms - Geographic spread: 150 km² rural area with no cellular coverage - Message frequency: 6 transmissions/day (every 4 hours) - Payload size: 20 bytes (soil moisture, temperature, battery level) - Required battery life: 5+ years - Downlink needs: Occasional configuration updates (monthly) - Budget constraint: Limited capital for infrastructure

Steps:

  1. Eliminate cellular options due to coverage gap:
    • NB-IoT: No cellular coverage in rural farms. Would require carrier to deploy new towers (not feasible).
    • LTE-M: Same coverage limitation. Eliminated.
    • Satellite IoT (Swarm/Iridium): $5/month/device = 2,000 x $5 x 12 x 5 = $600,000 over 5 years. Too expensive.
  2. Evaluate LoRaWAN private network feasibility:
    • LoRaWAN rural range: 10-15 km per gateway with clear line-of-sight
    • Coverage calculation: 150 km² / (pi x 10km²) = ~5 gateways minimum, 8 for redundancy
    • Gateway cost: 8 x $1,200 (outdoor industrial grade with solar) = $9,600
    • Sensor modules: 2,000 x $15 = $30,000
    • Network server: Self-hosted ChirpStack = $0 or The Things Industries = $500/year
  3. Verify Sigfox viability:
    • Check Sigfox coverage map: Likely no coverage in rural area (operator networks concentrated in urban areas)
    • Even if coverage existed: 6 messages/day x 365 = 2,190 messages/year (within 140/day limit but no coverage)
    • Eliminated due to coverage gap
  4. Calculate LoRaWAN battery life:
    • SF10 average (rural range), 20-byte payload: 371 ms time-on-air
    • Daily TX time: 6 x 0.371s = 2.23 seconds
    • TX current: 120 mA for 2.23s = 0.074 mAh/day
    • RX windows + sleep: 0.15 mAh/day
    • Total: 0.224 mAh/day
    • 2400 mAh battery / 0.224 = 10,714 days = 29 years theoretical, 10+ years practical

Result: Deploy private LoRaWAN network with 8 solar-powered gateways. Total 5-year cost: $9,600 (gateways) + $30,000 (sensors) + $2,500 (network server) = $42,100. Per sensor: $21.05 for 5 years of operation. Zero monthly fees after deployment.

Key Insight: When cellular coverage is unavailable, LoRaWAN’s ability to deploy private infrastructure becomes a decisive advantage. Rural deployments with line-of-sight can achieve 10-15 km ranges, meaning a few well-placed gateways can cover vast agricultural areas at minimal cost.

1069.8 Engineering Tradeoffs

WarningTradeoff: Unlicensed Spectrum (LoRaWAN/Sigfox) vs Licensed Spectrum (NB-IoT/LTE-M)

Option A (Unlicensed - LoRaWAN/Sigfox): Free spectrum access with no recurring spectrum fees. Deploy your own infrastructure (LoRaWAN) or use operator network (Sigfox). Subject to duty cycle limits: EU868 allows 1% duty cycle (~36 seconds/hour airtime). Interference from other users in crowded areas possible. LoRaWAN gateway: $500-1,500, Sigfox subscription: $1-2/device/year.

Option B (Licensed - NB-IoT/LTE-M): Carrier-managed spectrum with guaranteed interference-free operation. No duty cycle limits - transmit whenever needed. Operator SLA with 99.9%+ availability guarantees. Deep indoor coverage (+20 dB MCL for NB-IoT). Subscription required: $2-5/device/year NB-IoT, $3-8/device/year LTE-M. No infrastructure deployment needed.

Decision Factors: Choose unlicensed when operating in areas with low ISM band congestion, deploying private infrastructure is acceptable, or minimizing recurring costs is priority. Choose licensed when mission-critical reliability is required, deployments are in dense urban areas with ISM interference, or deep indoor/basement coverage is needed. Key metric: In EU, duty cycle limits mean LoRaWAN Class A sensor sending 50-byte payload at SF12 can transmit max ~30 messages/hour. If you need more, consider NB-IoT.

WarningTradeoff: Sigfox Simplicity vs LoRaWAN Flexibility

Option A (Sigfox): Ultra-simple device design with smallest power footprint. Global roaming with single subscription across 70+ countries. 100 bps uplink, 600 bps downlink - forces efficient data encoding. Strict limits: 140 uplinks/day (12 bytes each), 4 downlinks/day (8 bytes each). Operator-managed network - zero infrastructure. Module cost: $10-15. Best for: Simple, infrequent telemetry (alarms, daily readings).

Option B (LoRaWAN): Flexible data rates from 0.3-50 kbps depending on spreading factor. No hard message limits (duty cycle is soft limit). Larger payloads: 51-222 bytes depending on region and data rate. Bidirectional communication with Class A/B/C options. Private or public network options. Gateway cost: $500-1,500. Module cost: $8-15. Best for: Applications needing configuration updates, firmware OTA, or variable reporting rates.

Decision Factors: Choose Sigfox when your application truly needs minimal data (<12 bytes, <140 messages/day), global coverage matters, and you want zero infrastructure responsibility. Choose LoRaWAN when you need firmware updates, variable reporting rates, larger payloads, or private network control. Critical question: Can your use case survive with only 4 downlink messages per day? If yes, Sigfox simplifies everything. If no, LoRaWAN is required.

1069.9 Summary

This chapter covered LPWAN technology selection and comparison:

  • LoRaWAN Classes: Class A (lowest power, uplink-triggered downlinks), Class B (scheduled beacon windows), Class C (continuous receive for actuators) - choose based on downlink latency vs power trade-off
  • Sigfox Asymmetry: 140 uplink vs 4 downlink messages per day reflects power-optimized design for sensor telemetry, not bidirectional control
  • Payload Constraints: Sigfox 12 bytes vs LoRaWAN 51-222 bytes determines data encoding complexity
  • Mobility Requirements: LTE-M supports vehicular handover; NB-IoT/LoRaWAN/Sigfox are stationary-focused
  • Coverage Dependency: Sigfox/NB-IoT require operator infrastructure; LoRaWAN enables private deployment in remote areas
  • Scale Economics: Sigfox/NB-IoT subscriptions compound ($X/device/year); LoRaWAN gateway investment amortizes across all devices
  • Indoor Penetration: NB-IoT +20 dB advantage for basement/underground deployments
  • Battery Life: All technologies support 10+ years with proper class/PSM configuration

1069.10 What’s Next