21  Quiz: Cellular & LoRaWAN Regulations

In 60 Seconds

This quiz chapter tests your understanding of regulatory compliance for LPWAN deployments. You will calculate LoRaWAN duty cycle limits (1% on EU868 allows approximately 391 packets/hour per channel at SF7), analyze spreading factor trade-offs (SF7 gives 2x capacity vs SF12 but less range), and evaluate hybrid approaches combining unlicensed LoRaWAN with licensed cellular backup for alert handling.

Key Concepts

• LTE Cat-M1 vs NB-IoT: LTE-M supports 1 Mbps and mobility; NB-IoT provides deeper penetration at 200 kbps with no mobility support
• LoRaWAN Spreading Factor (SF): Values SF7-SF12 trade data rate for range and SNR sensitivity; SF12 adds 5.4 dB over SF7 but reduces rate
• Cellular IoT Power Saving Mode (PSM): Feature allowing NB-IoT/LTE-M devices to enter deep sleep while maintaining network registration
• eDRX (Extended Discontinuous Reception): Cellular feature extending paging cycle from 2.56 seconds to 10 minutes for IoT power savings
• LoRaWAN OTAA vs ABP: Over-the-Air Activation vs Activation By Personalization; OTAA is more secure with session key derivation
• ADR (Adaptive Data Rate): LoRaWAN network server feature automatically optimizing SF and TX power based on link quality
• Cellular Roaming for IoT: Using SIM cards or eSIM with roaming agreements for global IoT deployments
• GPRS vs LTE-M Fallback: Design decision when combining modern LPWAN with legacy 2G fallback for older coverage areas

21.1 Introduction

This chapter covers regulatory compliance and spectrum selection for cellular IoT and LoRaWAN deployments. You’ll work through scenarios involving duty cycle calculations, ETSI compliance, and technology selection for campus and wide-area deployments.

Learning Objectives

By completing this chapter, you will be able to:

• Derive duty cycle budgets and time-on-air values for LoRaWAN deployments under ETSI constraints
• Contrast spreading factor trade-offs between network capacity and coverage range
• Justify licensed versus unlicensed spectrum selection for a given IoT deployment scenario
• Construct a compliant LPWAN deployment plan that satisfies ETSI EN300.220 regulations

For Beginners: Cellular and LoRaWAN Quiz

This quiz tests your understanding of cellular IoT and LoRaWAN regulations. Questions cover topics like frequency allocation, duty cycle limits, and the differences between licensed and unlicensed spectrum. These regulatory concepts are essential for deploying IoT devices that comply with local laws.

21.2 Prerequisites

Before attempting these assessments, you should have completed:

• Spectrum Licensing and Propagation: Licensed vs unlicensed spectrum
• Design Considerations and Labs: Frequency selection frameworks
• LoRaWAN Overview: LoRaWAN fundamentals (recommended)

21.3 Knowledge Check: 2.4 GHz Channel Selection

21.4 Knowledge Check: Radio Frequency Selection

## Scenario-Based Assessment: Campus LoRaWAN Deployment

Scenario-Based Understanding Check: Campus LoRaWAN Deployment

Scenario: A European university is deploying a campus-wide environmental monitoring system using LoRaWAN on the 868 MHz ISM band. The system must comply with ETSI regulations requiring 1% duty cycle on the g1 sub-band (868.0-868.6 MHz).

System Requirements:

• 500 outdoor sensors (air quality, weather, noise)
• 8 LoRaWAN gateways covering 2 km² campus
• Sensors use SF7 (fastest spreading factor) at 5.47 kbps
• Each sensor sends: 50-byte payload + 13-byte overhead = 63 bytes total
• Required reporting intervals: Environmental (every 10 min), Alerts (immediate)

Regulatory Constraints:

• ETSI EN300.220: 1% duty cycle on 868.0-868.6 MHz (g1 sub-band)
• Alternative: 10% duty cycle on 869.4-869.65 MHz (g3 sub-band, but only 3 channels)
• Violation penalties: EUR 10,000-50,000 fines, equipment confiscation

Analysis Questions:

1. Duty Cycle Calculation: For a 63-byte packet at 5.47 kbps, calculate:

   • Time-on-air per transmission
   • Maximum packets per hour (1% duty cycle)
   • Minimum interval between packets

2. Scalability Analysis: With 500 sensors sending every 10 minutes:

   • Total packets per hour across all sensors
   • Average channel utilization
   • Is the system compliant?

3. Trade-off Decision: Compare operating strategies:

   • Strategy A: Use SF7 (5.47 kbps) on 1% duty cycle g1 band
   • Strategy B: Use SF12 (250 bps, 20× longer ToA) on 10% duty cycle g3 band
   • Which provides better network capacity?

4. Alert Handling: If 10% of sensors need to send emergency alerts (30 seconds response time), how does this impact normal operation?

5. Alternative Solutions: If duty cycle limits are exceeded, evaluate:

   • Deploy private LTE-M network (licensed spectrum, no duty cycle)
   • Switch to NB-IoT (licensed, higher cost)
   • Implement adaptive sampling (reduce reporting during low activity)

Solution & Key Insights

1. Duty Cycle Calculation:

Time-on-Air (ToA) Calculation:

• Packet size: 63 bytes = 504 bits
• Data rate: 5.47 kbps = 5470 bits/second
• ToA: 504 bits / 5470 bps = 0.092 seconds = 92 milliseconds

1% Duty Cycle Limits:

• 1 hour = 3600 seconds
• 1% transmission budget: 3600 × 0.01 = 36 seconds per hour
• Maximum packets: 36 seconds / 0.092 seconds = 391 packets per hour
• Minimum interval: 3600s / 391 = 9.2 seconds between packets

Putting Numbers to It

Duty cycle math: \(\text{max packets} = (\text{total time} \times \text{duty \%}) / \text{ToA}\). Worked example: 1% of 3,600 sec = 36 sec budget. At 92 ms/packet, max = 36 / 0.092 = 391 packets/hour. Minimum interval = 3,600 / 391 = 9.2 sec. For 500 sensors × 6 pkts/hr = 3,000 pkts total, per-sensor duty = (6 × 0.092) / 3,600 = 0.015% << 1% limit (compliant).

2. Scalability Analysis:

System Load Calculation:

• 500 sensors × 6 transmissions/hour (every 10 min) = 3,000 packets/hour
• Each packet: 92 ms ToA
• Total airtime: 3000 × 0.092s = 276 seconds/hour = 7.67% utilization

Per-Sensor Compliance Check:

• Each sensor: 6 packets/hour × 92 ms = 0.552 seconds/hour
• Duty cycle: 0.552 / 3600 = 0.015% per sensor ✓ Compliant (well under 1%)

Channel Capacity:

• 3 channels available in g1 band (868.1, 868.3, 868.5 MHz)
• With 8 gateways, effective channel capacity increases
• Verdict: System is compliant but approaching saturation (7.67% vs theoretical 30% max)

3. Trade-off Analysis:

Strategy A: SF7 on 1% Duty Cycle (g1 band)

• ToA: 92 ms per packet
• Packets/hour per sensor: 391 maximum (using 6 = 1.5% of limit)
• Range: ~2 km (urban), ~5 km (rural)
• Channels: 3 available
• Network capacity: ~1,173 packets/hour (3 channels × 391)

Strategy B: SF12 on 10% Duty Cycle (g3 band)

• ToA: 2.02 seconds per packet (22× longer due to slower data rate)
• 10% duty cycle: 360 seconds/hour available
• Packets/hour per sensor: 360 / 2.02 = 178 maximum
• Range: ~10 km (urban), ~20 km (rural)
• Channels: 3 available (g3: 869.4-869.65 MHz)
• Network capacity: ~597 packets/hour (3 channels × 199)

Comparison Table:

Metric	SF7 (1% DC)	SF12 (10% DC)	Winner
Packets/hour (3 ch)	1,173	597	SF7
Range	2-5 km	10-20 km	SF12
ToA	92 ms	1.81 s	SF7
Battery life	100%	95%	SF7
Collision risk	Lower	Higher	SF7

Recommendation for campus scenario: Use SF7 on g1 band because: - Campus is only 2 km² (SF7 range sufficient) - 2× higher capacity needed for 500 sensors - 20× faster ToA reduces collision probability - Better battery life (shorter transmissions)

4. Alert Handling:

Emergency Alert Impact:

• 10% of sensors = 50 sensors
• Alert requirement: 30-second response time
• Normal 10-minute reporting: 6 packets/hour
• Alert rate: 120 packets/hour per sensor (every 30 sec)

Duty Cycle Check:

• 120 packets × 92 ms = 11 seconds/hour = 0.3% ✓ Still compliant

Network Load During Alert:

• Normal sensors: 450 × 6 pkts = 2,700 pkts/hour
• Alert sensors: 50 × 120 pkts = 6,000 pkts/hour
• Total: 8,700 packets/hour

Channel capacity check:

• 3 channels × 391 max pkts/hour = 1,173 total capacity
• 8,700 packets EXCEEDS capacity by 7.4× System FAILS under alert load

Solution: Implement priority classes: - Normal: SF7, 10-minute intervals - Alerts: Guaranteed delivery via confirmed uplinks or licensed spectrum backup

5. Alternative Solutions:

Option A: Private LTE-M Network

• Pros: No duty cycle, guaranteed QoS, higher data rates (375 kbps)
• Cons: Requires spectrum license (EUR 50K-500K/year), infrastructure ($100K+)
• Use case: Mission-critical systems (safety, security)

Option B: NB-IoT (Cellular)

• Pros: No duty cycle, wide coverage, carrier-managed
• Cons: $2-5 per device/year subscription, 10-year cost = $25,000
• Use case: Long-term deployments without infrastructure investment

Option C: Adaptive Sampling

• Pros: Stays within duty cycle, no additional cost
• Cons: Reduced data granularity during high-activity periods
• Implementation:
  • Normal: 10-minute intervals
  • Low activity (night): 30-minute intervals
  • Alert mode: 30-second intervals for affected sensors only
• Result: Reduces baseline load to 2.5% utilization, leaving 5% headroom for alerts

Recommended Hybrid Approach:

1. Primary: LoRaWAN SF7 on g1 band (1% DC) for 95% of time
2. Backup: 10 LTE-M modems ($20 each) for critical alert beacons
3. Adaptive: Reduce sampling frequency during low-activity hours
4. Total cost: $200 for LTE-M backup vs $25K for full NB-IoT

Key Engineering Insight: Duty cycle regulations exist to prevent “tragedy of the commons” in unlicensed spectrum. The 1% limit means 100 devices can coexist per channel if all transmit continuously. Smart systems use adaptive rates, sleep cycles, and hybrid solutions to stay compliant while meeting performance requirements.

Verification Questions:

1. If packet size doubles to 126 bytes, how does this affect capacity? (Calculate new ToA and limits)
2. What spreading factor balances range and capacity for 1,000 sensors? (Hint: SF9 gives 5 km range with 500 ms ToA)
3. Could you use listen-before-talk (LBT) to exceed 1% duty cycle safely? (Research ETSI LBT exemptions)

Sensor Squad: The Duty Cycle Stopwatch!

Sammy Sensor: “Duty cycle is like a talking rule at school. In Europe, your LoRa sensor can only ‘talk’ for 36 seconds every hour (1% of the time). The rest of the time, it has to stay quiet so others can talk too!”

Lila the Light Sensor: “Spreading factor is like choosing between whispering and shouting. SF7 is a quick whisper (fast but short range). SF12 is a long, slow shout (reaches far but takes 20 times longer). Choose wisely based on how far your gateway is!”

Max the Motion Detector: “The trickiest part about LoRaWAN is emergency alerts. If 50 sensors suddenly need to send alerts every 30 seconds, the channel gets jammed. That is why smart systems have a cellular backup – like having a phone when the walkie-talkie fails!”

Bella the Button: “Always calculate your time-on-air BEFORE deploying. It is like making sure you have enough fuel before a road trip. Running out of duty cycle budget is just as bad as running out of gas!”

Worked Example: Calculating LoRaWAN Capacity for a Smart Campus

Scenario: A European university campus deploys 500 environmental sensors using LoRaWAN on the EU868 ISM band (g1 sub-band, 1% duty cycle limit). Each sensor sends 50 bytes every 10 minutes. Determine if the system complies with ETSI regulations and calculate remaining capacity.

Given Parameters:

• Sensors: 500 devices
• Payload: 50 bytes + 13 bytes LoRaWAN overhead = 63 bytes total
• Reporting interval: Every 10 minutes
• Spreading Factor: SF7 (data rate 5.47 kbps, fastest LoRa setting)
• Frequency band: EU868 g1 (868.0-868.6 MHz)
• Duty cycle limit: 1% per device per hour (ETSI EN300.220)
• Available channels: 3 channels in g1 band

Step 1: Calculate Time-on-Air (ToA) per Transmission

Using the simplified LoRa ToA estimate for SF7 (consistent with the scenario above):

Packet size: 63 bytes = 504 bits
Data rate at SF7: 5.47 kbps = 5,470 bps
ToA = 504 / 5470 = 0.092 seconds ≈ 92 milliseconds per packet

Note: Actual LoRa ToA includes preamble, header, and coding rate overhead. For SF7/BW125/CR4/5, a 63-byte payload yields approximately 100-120 ms. We use 92 ms as a conservative lower bound.

Step 2: Calculate Per-Sensor Duty Cycle

Each sensor sends 6 packets per hour (every 10 minutes):

Airtime per hour = 6 packets × 0.092 seconds = 0.552 seconds/hour
Duty cycle = (0.552 / 3600) × 100% = 0.015%

Compliance check: 0.015% < 1% limit – Each sensor is compliant (well under the limit).

Step 3: Calculate Total Network Load

For 500 sensors:

Total packets per hour = 500 sensors × 6 = 3,000 packets/hour
Total airtime = 3,000 × 0.092 sec = 276 seconds/hour
Channel utilization = 276 / 3600 = 7.67% of ONE channel

Step 4: Distribute Load Across 3 Channels

LoRaWAN uses frequency hopping across 3 channels:

Per-channel utilization = 276 sec / (3 channels × 3600 sec)
                        = 276 / 10,800
                        = 2.56% per channel

Result: Network uses 2.56% of available airtime per channel.

Step 5: Calculate Remaining Capacity

Maximum packets per hour (1% duty cycle budget across 3 channels):

1% budget per channel = 3600 × 0.01 = 36 seconds/channel/hour
Max packets per channel = 36 / 0.092 = 391 packets/hour
For 3 channels = 391 × 3 = 1,173 packets/hour (duty-cycle limited)

Current load: 3,000 packets/hour across all sensors, but each sensor only uses 0.015% duty cycle.

At 30% utilization (conservative collision threshold), max load per channel:

Max packets/hour/channel = (3600 × 0.30) / 0.092 = 11,739 packets
For 3 channels = 11,739 × 3 = 35,217 packets/hour
Current load = 3,000 packets/hour
Remaining = 35,217 - 3,000 = 32,217 packets/hour
Additional sensors = 32,217 / 6 = ~5,370 more sensors (collision-limited)

Key Findings:

Metric	Value	Status
Per-sensor duty cycle	0.015%	Compliant (well under 1%)
Channel utilization	2.56%	Healthy (well under 30% threshold)
Duty-cycle capacity	1,173 pkts/hr (3 ch)	Per-device limit, not system limit
Collision-limited capacity	~5,370 add’l sensors	At 30% utilization threshold
Current deployment	500 sensors	Room to grow significantly

Recommendations:

1. Current system is compliant and healthy (20.6% utilization leaves 40% headroom before quality degrades).

2. Can safely add 200+ sensors without major issues.

3. For expansion beyond 700 sensors:

• Deploy second gateway on different channels (g2 or g3 sub-bands)
• Use adaptive data rate (ADR) to optimize close sensors to higher SF (shorter ToA)
• Implement confirmed uplinks only for critical alerts (reduces retransmissions)

4. Emergency alert handling:

• Current system has NO capacity for alert storms (e.g., 50 sensors sending emergency alerts every 30 seconds)
• For alerts: use Class C (downlink-initiated) or hybrid LoRaWAN + cellular backup

Cost Comparison for Expansion (229 sensors):

Technology	Hardware Cost	Subscription (10yr)	Total 10yr Cost
LoRaWAN	229 × $8 = $1,832	$0 (no fees)	$1,832
NB-IoT	229 × $10 = $2,290	229 × $3 × 10 = $6,870	$9,160

Savings with LoRaWAN: $7,328 (80%) over 10 years, plus no carrier lock-in.

Key Insight: The 1% duty cycle limit is per-device, not per-channel. With proper channel hopping, 500 sensors use only 20% of channel capacity. The real limit is collision probability (packets overlapping in time/frequency), which becomes noticeable above 30% utilization. Always calculate BOTH duty cycle compliance AND channel saturation to determine true network capacity.

21.5 Interactive: LoRaWAN Duty Cycle Calculator

viewof dc_payload = Inputs.range([10, 200], {label: "Payload (bytes)", step: 1, value: 63})
viewof dc_sf = Inputs.select([7, 8, 9, 10, 11, 12], {label: "Spreading Factor", value: 7})
viewof dc_sensors = Inputs.range([10, 2000], {label: "Number of sensors", step: 10, value: 500})
viewof dc_interval = Inputs.range([1, 60], {label: "Reporting interval (min)", step: 1, value: 10})

{
  const dataRates = {7: 5470, 8: 3125, 9: 1760, 10: 980, 11: 440, 12: 250};
  const dr = dataRates[dc_sf];
  const bits = dc_payload * 8;
  const toa = bits / dr;
  const pktsPerHour = 60 / dc_interval;
  const airtimePerSensor = pktsPerHour * toa;
  const dutyCycle = (airtimePerSensor / 3600) * 100;
  const totalPkts = dc_sensors * pktsPerHour;
  const totalAirtime = totalPkts * toa;
  const perChannelUtil = (totalAirtime / (3 * 3600)) * 100;
  const compliant = dutyCycle < 1;
  const healthy = perChannelUtil < 30;

  return html`<div style="background: #f8f9fa; border-left: 4px solid ${compliant ? '#16A085' : '#E74C3C'}; padding: 12px 16px; border-radius: 4px; font-family: Arial, sans-serif;">
    <div style="display: grid; grid-template-columns: 1fr 1fr; gap: 8px; font-size: 14px;">
      <div><strong>Data rate (SF${dc_sf}):</strong> ${(dr/1000).toFixed(2)} kbps</div>
      <div><strong>Time-on-air:</strong> ${(toa * 1000).toFixed(1)} ms</div>
      <div><strong>Per-sensor duty cycle:</strong> ${dutyCycle.toFixed(4)}%</div>
      <div><strong>Packets/hour (all sensors):</strong> ${totalPkts.toLocaleString()}</div>
      <div><strong>Channel utilization (3 ch):</strong> ${perChannelUtil.toFixed(2)}%</div>
      <div><strong>Total airtime/hour:</strong> ${totalAirtime.toFixed(1)} sec</div>
    </div>
    <div style="margin-top: 10px; font-size: 14px;">
      <span style="color: ${compliant ? '#16A085' : '#E74C3C'}; font-weight: bold;">${compliant ? 'Per-device: COMPLIANT' : 'Per-device: EXCEEDS 1%'}</span> |
      <span style="color: ${healthy ? '#16A085' : '#E74C3C'}; font-weight: bold;">${healthy ? 'Channel: HEALTHY' : 'Channel: SATURATED'}</span>
    </div>
  </div>`;
}

21.6 Knowledge Check: Duty Cycle Compliance

21.7 Concept Relationships

Concept	Relationship	Key Insight
Duty Cycle ↔︎ Capacity	1% limit = 36 sec/hour airtime	EU868 allows ~391 SF7 packets/hour per channel
Spreading Factor ↔︎ Range	SF12 = 5× range, 20× ToA vs SF7	Trade capacity for coverage
Licensed ↔︎ Guaranteed QoS	LTE-M/NB-IoT = no duty cycle limits	$3/device/year vs free LoRaWAN
Alert Storms ↔︎ Compliance	50 sensors × 120 pkt/hr = 6,000 pkt/hr	Exceeds 1,173 pkt/hr capacity by 5×

Common Pitfalls

1. Using LoRaWAN for Latency-Critical Applications

LoRaWAN is an asynchronous uplink-heavy protocol. Downlink messages can only be sent in two short receive windows after an uplink. End-to-end latency from network server to device is typically 1-2 seconds minimum. It is unsuitable for applications requiring sub-second command response times.

2. Fixing LoRaWAN Spreading Factor Instead of Using ADR

Hardcoding SF12 for maximum range wastes airtime for devices close to gateways. Enabling Adaptive Data Rate (ADR) allows the network to use SF7 for nearby devices, reducing transmission time by 16x and leaving more airtime for distant devices. Always enable ADR for network capacity optimization.

3. Not Planning for LoRaWAN Duty Cycle in Dense Deployments

LoRaWAN channels have 1% duty cycle limits. At SF12, one uplink takes ~2.5 seconds, meaning devices can only transmit ~36 seconds per hour per channel. Dense deployments where many devices transmit frequently can exhaust gateway capacity. Plan gateway density for actual traffic load.

4. Assuming Cellular PSM Eliminates All Power During Sleep

Power Saving Mode keeps the device registered with the network but periodic tracking area updates still occur. The actual sleep current depends on TAU timer settings. Devices with 1-hour TAU intervals still consume power for periodic keep-alive messages not reflected in PSM sleep current specs.

🏷️ Label the Diagram

💻 Code Challenge

21.8 Summary

This quiz covered regulatory compliance and spectrum selection for LPWAN:

1. Duty Cycle Compliance: 1% duty cycle limits LoRaWAN to ~391 packets/hour per channel on EU868 g1 band
2. Spreading Factor Trade-offs: SF7 provides 2× capacity vs SF12, but SF12 offers 5× range
3. Alert Handling: Emergency alerts can easily exceed duty cycle limits; hybrid solutions are often necessary
4. Licensed vs Unlicensed: Licensed spectrum (LTE-M, NB-IoT) avoids duty cycle limits but increases cost

Key Takeaways:

• Always calculate time-on-air before deploying LPWAN systems
• Per-sensor duty cycle compliance doesn’t guarantee system-wide compliance
• Hybrid approaches (LoRaWAN + cellular backup) often provide best cost/performance balance
• ETSI regulations carry significant penalties for non-compliance

21.9 Match the LPWAN Concept

21.10 Order the LoRaWAN Deployment Steps

21.11 See Also

• Spectrum Licensing and Propagation - Licensed vs unlicensed spectrum trade-offs
• Design Considerations and Labs - Frequency selection frameworks
• LoRaWAN Overview - Complete LoRaWAN protocol coverage

21.12 What’s Next

Chapter	Focus	Why Read It Next
Quiz: Smart City & Multi-Technology	Multi-technology deployment decisions with TCO analysis	Apply the duty cycle and spectrum knowledge from this quiz to a complex smart city scenario
LoRaWAN Overview	LoRaWAN protocol architecture, classes A/B/C, and join procedures	Deepen your understanding of the LoRaWAN stack that underpins the duty cycle calculations covered here
Cellular IoT Fundamentals	LTE-M and NB-IoT architecture, power saving modes, and coverage classes	Compare the licensed-spectrum cellular alternatives evaluated in the hybrid deployment scenario
Spectrum Licensing and Propagation	ISM bands, regulatory bodies, and propagation models	Revisit the regulatory foundations that determine which frequencies and duty cycles apply
Design Considerations and Labs	Frequency selection frameworks and hands-on wireless labs	Practise applying the selection criteria used in the campus deployment scenario