21 LPWAN Knowledge Checks

In 60 Seconds

These knowledge checks test LPWAN deployment decision-making through real-world scenarios: operator bankruptcy risk mitigation for global logistics, private vs. public network selection for agriculture, reliability requirements for smart city parking (99.9% needs NB-IoT), and link budget calculations including building penetration loss and fade margins that can turn a theoretical 10 km link into a failed deployment.

21.1 Knowledge Check

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

Quiz 1: Real-World LPWAN Scenarios

{#fig-mermaid-lpwan-fundamentals-3-3f6984}

LoRaWAN private network vs Sigfox operator model comparison

{fig-alt=“Comparison of LoRaWAN private network model (you own gateways and network server, full control, no subscription fees) versus Sigfox operator model (operator-owned base stations and backend, subscription-based, limited control via HTTP callbacks). Highlights infrastructure ownership and cost structure differences for agricultural IoT deployment.”}

Why Private Network Matters for Agriculture:

Cost Comparison (1,000 sensors, 10 years):

LoRaWAN (Private):
- Sensors: 1,000 x €15 = €15,000
- Gateways: 5 x €500 = €2,500
- Network server: €0 (ChirpStack free)
- 10-year cost: €17,500 (€1.75/sensor/year)

Sigfox:
- Sensors: 1,000 x €10 = €10,000
- Subscription: 1,000 x €1.50 x 10 = €15,000
- 10-year cost: €25,000 (€2.50/sensor/year)

LoRaWAN becomes cheaper after year 3!

Additional LoRaWAN Advantages for Agriculture:

1. No coverage dependency:
   - Rural farms often have no Sigfox coverage
   - Deploy your own gateways where needed

2. Control and privacy:
   - Soil data stays on your servers
   - No third-party access to farm data

3. Flexibility:
   - Adjust SF/BW for range vs battery
   - Add gateways as farm expands

Why Other Options Are Wrong:

A - Signal penetration: - Both use sub-GHz frequencies with similar penetration - LoRa CSS and Sigfox UNB have comparable link budgets (~150 dB) - Not a differentiator

C - Data rates: - LoRaWAN: 0.3-50 kbps (varies by SF) - Sigfox: 100-600 bps - LoRaWAN is faster, but 20-byte hourly readings work on either - FUOTA is possible but rarely used in agriculture

D - Licensed spectrum: - BOTH use unlicensed ISM bands (868 MHz EU, 915 MHz US) - Neither uses licensed spectrum - This statement is factually incorrect

viewof kc_lpwan_1 = InlineKnowledgeCheck({ id: "kc-lpwan-1", question: html`Question 1: You deploy LoRaWAN sensors across a farm with SF7 (Spreading Factor 7) achieving 5 km range. The farm expands, requiring 12 km coverage. You increase to SF12, which provides -137 dBm sensitivity vs SF7's -123 dBm. What is the PRIMARY trade-off of this change?`, answers: [ "Increased range comes at the cost of significantly reduced data rate (SF12 is ~50x slower than SF7) and longer airtime", "Higher spreading factor increases power consumption by 6x due to longer transmission time", "SF12 requires more expensive hardware modules with enhanced signal processing capabilities", "Using SF12 violates EU868 duty cycle regulations, limiting messages to 30 per day" ], correct: 0, explanation: html`Explanation: Increasing spreading factor from SF7 to SF12 dramatically reduces data rate and increases airtime: SF7 vs SF12 Trade-offs: <pre> Parameter SF7 SF12 Change ------------------------------------------------------ Data rate 5,470 bps 250 bps ~22x slower Time on air (20B) 41 ms 1,482 ms ~36x longer Sensitivity -123 dBm -137 dBm 14 dB better Range (typical) 2-5 km 8-15 km ~3x farther Network capacity High Very low Many fewer devices </pre> Why this matters: <ul> <li>Longer airtime = fewer messages: With 36x longer transmission, you can send 36x fewer messages before hitting duty cycle limits</li> <li>Network capacity: SF12 devices occupy the channel much longer, reducing concurrent device capacity</li> <li>Battery impact: While transmit power stays same, longer airtime means more energy per message</li> </ul> Why other answers are wrong: <ul> <li>Option B (6x power): Transmit power (Tx) stays constant (e.g., 14 dBm). Energy consumption increases proportional to airtime (~36x), not 6x</li> <li>Option C (expensive hardware): Same LoRa chip supports all spreading factors; no hardware upgrade needed</li> <li>Option D (duty cycle violation): SF12 increases airtime, making duty cycle MORE restrictive, but doesn't inherently violate regulations</li> </ul> Best practice: Use lowest SF that achieves required range (Adaptive Data Rate - ADR) to maximize network capacity and battery life.` })

viewof kc_lpwan_2 = InlineKnowledgeCheck({ id: "kc-lpwan-2", question: html`Question 2: A LoRaWAN gateway receives a packet at -130 dBm. The gateway's sensitivity is -137 dBm. What is the link margin, and why does it matter?`, answers: [ "Link margin is 7 dB, providing buffer against fading, interference, and obstacles-ensuring reliable communication even in non-ideal conditions", "Link margin is -267 dBm (sum of received power and sensitivity), indicating strong signal strength", "Link margin of 7 dB means the signal is too weak and will result in 50% packet loss", "Link margin is irrelevant for LPWAN because spread spectrum modulation eliminates fading effects" ], correct: 0, explanation: html`Explanation: Link margin measures how much "headroom" exists above minimum sensitivity: Link Margin Calculation: <pre> Link Margin = Received Power - Sensitivity = -130 dBm - (-137 dBm) = 7 dB </pre> What 7 dB margin provides: <ul> <li>Fading tolerance: Multipath fading can cause 10-20 dB signal drops; 7 dB helps absorb some variation</li> <li>Interference buffer: Other RF sources may degrade SNR; margin compensates</li> <li>Obstacle penetration: Buildings, trees, weather add attenuation; margin ensures packets get through</li> <li>Device movement: Even "stationary" sensors experience signal variation over time</li> </ul> Link Margin Guidelines: <pre> Margin Reliability Use Case ---------------------------------------- 0-3 dB Poor (~50%) Insufficient for production 3-6 dB Fair (~85%) Marginal, risky 6-10 dB Good (~95%) Acceptable for most deployments 10-15 dB Excellent Ideal for critical applications >15 dB Excessive Over-engineered (reduce Tx power) </pre> Why other answers are wrong: <ul> <li>Option B (-267 dBm): Link margin is a difference (subtraction), not sum. -267 dBm would be impossibly weak</li> <li>Option C (50% loss): 7 dB margin is positive, indicating signal is 7 dB above minimum-this gives ~95% reliability, not 50%</li> <li>Option D (no fading): Spread spectrum improves interference resistance but does NOT eliminate fading. Margin is crucial for all RF systems</li> </ul> Real-world application: Link budget calculators (like the one in this chapter) help ensure adequate margin during deployment planning.` })

viewof kc_lpwan_3 = InlineKnowledgeCheck({ id: "kc-lpwan-3", question: html`Question 3: You're calculating a LoRa link budget for a 10 km deployment. Transmit power is 14 dBm, receiver sensitivity is -137 dBm, giving a maximum path loss budget of 151 dB. Using the Friis equation, path loss at 10 km (868 MHz) is approximately 131 dB. However, you must account for additional losses. Which losses are MOST critical to include?`, answers: [ "Antenna cable loss (1-2 dB), building penetration loss (10-20 dB), and fade margin (6-10 dB)-real-world attenuation significantly exceeds free-space path loss", "Atmospheric absorption (30-40 dB) and rain attenuation (15-20 dB) dominate at sub-GHz frequencies", "Doppler shift loss (5-10 dB) due to device movement and multipath delay spread (10-15 dB)", "Only free-space path loss matters; LoRa's spread spectrum modulation compensates for all other losses" ], correct: 0, explanation: html`Explanation: Real-world RF links experience multiple loss mechanisms beyond free-space propagation: Complete Link Budget Breakdown (10 km, 868 MHz): <pre> Component Value Notes --------------------------------------------------- Tx Power +14 dBm LoRa module typical Tx Cable Loss -1 dB Gateway antenna cable Tx Antenna Gain +2 dBi Omnidirectional -> EIRP +15 dBm Free-Space Path Loss -131 dB Friis equation @ 10 km Building Penetration -15 dB Sensor inside structure Fade Margin -8 dB Rayleigh fading buffer -> Total Path Loss -154 dB Rx Antenna Gain +2 dBi Gateway omnidirectional Rx Cable Loss -1 dB Gateway feeder line -> Effective Received Power -138 dBm Receiver Sensitivity -137 dBm SF12 sensitivity -> Link Margin -1 dB INSUFFICIENT! </pre> Critical losses often forgotten: <ul> <li>Building penetration: 10-20 dB (brick/concrete), 5-10 dB (wood). Sensors inside buildings lose significant signal</li> <li>Fade margin: 6-10 dB needed for Rayleigh fading (urban multipath). Without this, PER spikes above 10%</li> <li>Cable/connector loss: 1-3 dB total. Long antenna cables or multiple connectors add up</li> <li>Antenna mismatch: 1-2 dB if antenna doesn't match 868 MHz exactly or has poor VSWR</li> </ul> Correcting the link budget: <pre> To achieve 10 dB margin at 10 km with building penetration: - Increase Tx power to 20 dBm (+6 dB) OR - Use directional gateway antenna (+6-9 dBi) OR - Deploy additional gateway at 7 km (+4 dB from reduced distance) OR - Reduce requirement to outdoor sensors only (save 15 dB) </pre> Why other answers are wrong: <ul> <li>Option B (atmospheric/rain): At 868 MHz, atmospheric absorption is <0.1 dB/km-negligible. Rain attenuation matters at >10 GHz (mmWave), not sub-GHz LPWAN</li> <li>Option C (Doppler/delay spread): LoRa CSS modulation is highly robust to Doppler (works on moving vehicles). Delay spread is managed by symbol time; not a "loss" in link budget</li> <li>Option D (no other losses): Spread spectrum improves SNR and interference rejection but cannot bypass physical attenuation (walls, fading). All RF systems need fade margin</li> </ul> Lesson: Always include practical margins (15-25 dB total) beyond free-space path loss for production deployments.` })

viewof kc_lpwan_4 = InlineKnowledgeCheck({ id: "kc-lpwan-4", question: html`Question 1: A utility company plans to deploy 50,000 smart water meters across a metropolitan area. Meters send 12-byte readings once per day. They evaluate four options: (1) LoRaWAN private network with 100 gateways, (2) Sigfox operator network, (3) NB-IoT, and (4) LTE-M. Given a 10-year deployment, which factor should MOST influence their decision?`, answers: [ "Total cost of ownership (TCO) including upfront gateway costs, subscription fees, and long-term vendor/operator viability risk", "Data rate capability-meters may need firmware updates requiring megabit speeds", "Latency requirements-billing systems need sub-second meter readings for real-time pricing", "Device mobility-water meters move frequently between locations requiring handoff support" ], correct: 0, explanation: html`Explanation: For large-scale utility deployments, TCO analysis over the entire lifecycle is paramount: 10-Year TCO Comparison (50,000 meters): <pre> Option Upfront Cost Annual Cost 10-Year Total --------------------------------------------------------------------- LoRaWAN Private - Devices (50k x €18) €900,000 - Gateways (100 x €800) €80,000 - Network server €10,000 - Annual ops/maintenance - €20,000 €200,000 -> Total €990,000 €20,000 €1,190,000 <- LOWEST Sigfox Operator - Devices (50k x €12) €600,000 - Subscription (€1.50/yr) - €75,000 €750,000 -> Total €600,000 €75,000 €1,350,000 NB-IoT - Devices (50k x €20) €1,000,000 - Subscription (€3/yr) - €150,000 €1,500,000 -> Total €1,000,000 €150,000 €2,500,000 LTE-M - Devices (50k x €25) €1,250,000 - Subscription (€5/yr) - €250,000 €2,500,000 -> Total €1,250,000 €250,000 €3,750,000 <- HIGHEST </pre> Additional TCO considerations: <ul> <li>Vendor risk: Sigfox bankruptcy (2022-2023) left customers stranded. LoRaWAN is open standard; NB-IoT/LTE-M backed by global carriers-lower obsolescence risk</li> <li>Scalability: Utility can start with 10k devices and add 5k/year without renegotiating contracts (LoRaWAN) vs subscription lock-in</li> <li>Data sovereignty: Water consumption data is sensitive; private LoRaWAN keeps data on utility servers vs operator-managed networks</li> <li>Coverage control: Utility adds gateways as needed (e.g., underground basements) vs depending on operator coverage maps</li> </ul> Why other factors are less critical: <ul> <li>Option B (data rate): 12 bytes/day works on any LPWAN (even Sigfox's 100 bps). Firmware updates are rare (1-2 times over 10 years) and can be done via technician visit if needed</li> <li>Option C (latency): Daily readings are for billing/consumption monitoring, not real-time pricing. Sub-minute latency unnecessary; hourly is sufficient</li> <li>Option D (mobility): Water meters are fixed infrastructure-never move. Mobility/handoff is irrelevant; this favors LoRaWAN (optimized for stationary sensors) over LTE-M</li> </ul> Real-world precedent: <ul> <li>Suez (France): Deployed LoRaWAN for 2M+ water meters-private network provided best TCO and data control</li> <li>Thames Water (UK): Uses NB-IoT for dense urban areas (existing cellular coverage) + LoRaWAN for rural regions (no cellular)</li> <li>Smart meters (EU): 80%+ use LoRaWAN or wM-Bus (dedicated utility LPWAN) due to cost advantages over cellular</li> </ul> Decision framework: For large-scale, stationary, low-bandwidth IoT deployments, LoRaWAN private networks offer lowest TCO and maximum control. Cellular LPWAN makes sense for mobility, global coverage, or existing carrier relationships.` })

viewof kc_lpwan_5 = InlineKnowledgeCheck({ id: "kc-lpwan-5", question: html`Question 2: An agricultural IoT startup develops soil sensors for vineyards. They target Europe (15 countries) and must decide between LoRaWAN public network (TTN), LoRaWAN private gateways, and Sigfox. Vineyards are 20-500 hectares, often in remote hills. Data privacy (farming practices) is critical. What is the BEST deployment strategy?`, answers: [ "Hybrid model: Provide customers with 1-3 private LoRaWAN gateways per vineyard for guaranteed coverage and data privacy, with cloud-based network server for remote management", "Rely on The Things Network (public LoRaWAN)-free connectivity eliminates gateway costs and complexity", "Sigfox operator network-widest rural coverage across Europe without customer-installed infrastructure", "NB-IoT with e-SIM roaming-cellular coverage in all 15 countries via single subscription" ], correct: 0, explanation: html`Explanation: Agriculture IoT requires reliable coverage in remote areas with data ownership control: Vineyard LPWAN Requirements Analysis: <pre> Requirement Weight LoRaWAN Private TTN Public Sigfox NB-IoT -------------------------------------------------------------------------------- Remote coverage HIGH ***** ** *** ** Data privacy HIGH ***** ** * ** Reliability HIGH ***** *** *** **** Cost (100 sensors/farm) MEDIUM **** ***** *** * Setup complexity MEDIUM *** ***** ***** **** -------------------------------------------------------------------------------- BEST FIT Yes No No No </pre> Why hybrid private LoRaWAN wins: <ol> <li>Guaranteed coverage: Vineyards in Tuscan hills or Bordeaux valleys have no public infrastructure. Customer installs 1-3 gateways (€1,500-3,000) for complete coverage</li> <li>Data sovereignty: Soil moisture, irrigation timing, pest treatment data is proprietary. Private network = data never leaves vineyard servers. Critical for competitive advantage</li> <li>Reliability SLA: No dependency on community-run TTN or operator uptime. Winery controls uptime, troubleshooting, and maintenance</li> <li>Scalability: Start with 50 sensors, expand to 500 as vineyard adopts system-no subscription fees per device</li> <li>Value proposition: Sensor company offers "turnkey system": sensors + gateways + cloud platform. Winery pays upfront (€5k-15k) for 10-year system</li> </ol> Successful business model (private LoRaWAN): <pre> Vineyard Package (100 sensors): - 100x soil sensors @ €80 each = €8,000 - 2x LoRaWAN gateways @ €800 each = €1,600 - Cloud subscription @ €50/month = €600/year - Installation & training = €2,000 -> Total Year 1 = €12,200 -> Annual renewal (cloud) = €600 -> 10-year TCO = €17,600 Compare to NB-IoT: €8,000 (sensors) + €60,000 (subscriptions) = €68,000 over 10 years! </pre> Real-world examples: <ul> <li>Semios: Agriculture IoT platform using private LoRaWAN gateways for orchards and vineyards (750k+ devices deployed)</li> <li>FarmBot: Precision agriculture with customer-owned gateways ensures coverage in remote fields</li> <li>Weenat: French agritech provides weather stations + gateways to farmers for total control</li> </ul> Key lesson: Agriculture IoT must prioritize coverage assurance and data sovereignty over lowest upfront cost. Private LoRaWAN gateways (1-3 per farm) provide both at compelling TCO.` })

viewof kc_lpwan_6 = InlineKnowledgeCheck({ id: "kc-lpwan-6", question: html`Question 3: A smart building deploys 1,000 LoRaWAN sensors (temperature, occupancy, air quality) across a 20-story office tower. After deployment, 30% of sensors experience >10% packet loss. Network analysis shows gateway receives 200+ messages/minute during business hours. What is the MOST likely root cause and solution?`, answers: [ "Network capacity saturation due to collision-implement Adaptive Data Rate (ADR) to shift devices to lower spreading factors, reducing airtime and increasing channel efficiency", "Insufficient gateway receive power-upgrade to 8-channel gateway or add second gateway for antenna diversity", "EU868 duty cycle violation-reduce sensor transmission frequency from once per minute to once per 10 minutes", "Building material attenuation-replace sensors with higher transmit power modules (increase from 14 dBm to 20 dBm)" ], correct: 0, explanation: html`Explanation: Dense deployments suffer from collision when too many devices transmit simultaneously on same channel/SF: Collision Analysis for 1,000 Sensors: <pre> Scenario: 1,000 sensors, SF12 (worst case), 1 message/10 min ------------------------------------------------------------- Time on air per message (20 bytes, SF12, BW125): 1,482 ms Messages per hour: 60,000 messages (1000 sensors x 6 msgs/hr) Airtime per hour: 89 seconds total 3 channels (EU868): 29.7 sec/channel/hour Duty cycle per sensor: 0.247% (well under 1% limit) But wait-do messages collide? ------------------------------------------------------------- Random transmission times: Poisson distribution Collision probability (1000 devices, SF12): ~35% when 200+ msgs/min! </pre> Why collisions occur: <ol> <li>Same spreading factor: All sensors likely shipped with default SF12. When two SF12 messages overlap on same channel -> both lost</li> <li>Narrow time window: Office hours (9am-5pm) = 8 hours. Sensors with synchronized timing (e.g., hourly on the hour) create traffic spikes</li> <li>Limited channels: EU868 has 3 default uplink channels. 200 messages/min / 3 channels = 67 msgs/min/channel. With 1.5 sec airtime (SF12), collision probability is high</li> </ol> Adaptive Data Rate (ADR) solution: <pre> ADR automatically adjusts SF based on link quality: Before ADR (all SF12): - 200 msg/min x 1.5 sec airtime = 300 sec total airtime/min - Spread across 3 channels = 100 sec/channel/min = 167% channel occupancy -> COLLISIONS! After ADR optimization: - 80% devices -> SF7 (41 ms airtime) = 656 ms/channel/min - 15% devices -> SF9 (205 ms airtime) = 51 ms/channel/min - 5% devices -> SF12 (1482 ms) = 123 ms/channel/min -> Total: 830 ms/channel/min = 1.4% occupancy -> NO COLLISIONS </pre> Expected results post-ADR: <pre> Metric Before ADR After ADR Improvement ------------------------------------------------------------- Packet loss 30% 2-5% ~85% reduction Network capacity 200 devices 2,000+ devices 10x increase Avg. battery life 5 years 8 years 60% longer Gateway load High (95%) Low (15%) Better headroom </pre> Key lesson: Dense LoRaWAN deployments require ADR to optimize spreading factors. Using SF12 for all devices is a common deployment mistake that causes unnecessary collisions and poor battery life.` })

21.2 Summary

This chapter tested your LPWAN knowledge across multiple scenarios:

Technology selection: Matching LPWAN technologies to use case requirements

Cost analysis: Understanding total cost of ownership over deployment lifetime

Reliability requirements: Choosing technologies based on delivery guarantees

Link budget concepts: Understanding range, sensitivity, and margins

Network capacity: Recognizing collision and duty cycle constraints

21.3 What’s Next

Continue to LPWAN Technology Selection for a detailed decision framework and interactive selector tool, or explore LPWAN Link Budget for range calculation tools.

Related Chapters

LPWAN Fundamentals Series: - LPWAN Overview - Introduction and basics - LPWAN Technology Selection - Decision framework - LPWAN Link Budget - Range calculations - LPWAN Pitfalls - Common mistakes to avoid