6  NB-IoT Channel & Uplink

In 60 Seconds

NB-IoT uses five physical channels (NPDSCH, NPDCCH, NPBCH, NPUSCH, NPRACH) with configurable single-tone or multi-tone uplink modes, where single-tone provides better coverage for weak-signal devices and multi-tone enables higher throughput for devices with good signal quality, combined with frequency hopping to improve reliability.

Key Concepts
  • NPRACH (Narrowband Physical Random Access Channel): NB-IoT uplink channel used for initial cell access; uses 3.75 kHz subcarrier spacing with frequency hopping; 4 repetition levels (1, 2, 4, 8)
  • NPUSCH (Narrowband Physical Uplink Shared Channel): Primary NB-IoT data uplink channel; supports 15 kHz (single-tone) and 3.75 kHz (multi-tone) subcarrier spacing
  • Single-Tone vs Multi-Tone NPUSCH: Single-tone (3.75 or 15 kHz): lower power, longer range, lower throughput; Multi-tone (3×15 kHz, 6×15 kHz, 12×15 kHz): higher throughput, requires more power
  • NPDCCH (Narrowband Physical Downlink Control Channel): Carries downlink control information (DCI) for resource scheduling; uses CSS (Common Search Space) for initial connection
  • Scheduling Request: Device-initiated request for uplink resource allocation; NB-IoT uses SR resource in NPUSCH format 2 or piggybacking on PRACH
  • HARQ (Hybrid ARQ): NB-IoT uplink uses HARQ with up to 128 retransmissions in CE Mode B; each failed transmission triggers a new HARQ round with incremental redundancy combining
  • TBS (Transport Block Size): Maximum payload size per NB-IoT transmission; varies by modulation, subcarrier count, and repetitions; maximum TBS is 680 bits (85 bytes) for single subframe
  • Coverage Enhancement Levels: CE Level 0 (0 repetitions, good coverage), CE Level 1 (2–8 repetitions), CE Level 2 (16–128 repetitions), CE Level 3 (256–2048 repetitions)

6.1 Learning Objectives

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

  • Analyze channel structure: Describe NB-IoT NPUSCH, NPDSCH, and control channel operations
  • Configure tone modes: Select optimal single-tone vs multi-tone uplink configurations
  • Evaluate frequency hopping: Explain how frequency diversity combats interference and improves uplink reliability
  • Optimize for power efficiency: Apply tone selection strategies based on signal quality and payload size

NB-IoT uses a very narrow 180 kHz radio channel to send data, compared to the 20 MHz channels used by regular LTE. This narrow channel provides excellent coverage (even deep inside buildings and underground) while keeping device complexity and power consumption very low.

“NB-IoT uses an incredibly narrow radio channel – just 180 kHz!” Sammy the Sensor said. “Compare that to regular LTE which uses 20 MHz. That is like the difference between a single-lane country road and a 100-lane superhighway. My lane is tiny, but it is all I need for sending small sensor readings!”

“The narrow channel is actually an advantage,” Lila the LED explained. “By concentrating all the radio energy into a tiny bandwidth, the signal can travel much farther and penetrate deeper into buildings. It is like focusing a flashlight into a tight beam versus spreading it wide – the focused beam reaches much farther!”

Max the Microcontroller added, “NB-IoT gives me two uplink modes. Single-tone mode uses just one frequency at a time, which is great for devices with weak signals deep inside buildings. Multi-tone mode uses multiple frequencies simultaneously for higher throughput when the signal is strong. I pick the best mode based on signal quality.”

“Frequency hopping adds another layer of cleverness,” Bella the Battery noted. “Instead of staying on one frequency, NB-IoT hops between different frequencies. If one frequency has interference – maybe from a microwave oven or other radio – the next hop will be on a clean frequency. This makes the connection much more reliable without costing me extra energy!”

6.2 Prerequisites

Before diving into this chapter, you should be familiar with:

Deep Dives:

Comparisons:

Related Topics:

Quick Reference: NB-IoT Physical Channels
  • NPDSCH (Downlink Shared Channel): User data to device.
  • NPDCCH (Downlink Control Channel): Scheduling and control information.
  • NPBCH (Broadcast Channel): Essential system information for initial access.
  • NPUSCH (Uplink Shared Channel): Uplink user data from device.
  • NPRACH (Random Access Channel): Initial access / connection requests.

6.5 Deep Dive: Single-Tone vs Multi-Tone Optimization

NB-IoT Uplink Tone Configurations:

NB-IoT uplink tone configuration options showing 12-tone, 3-tone, single-tone 15 kHz, and single-tone 3.75 kHz modes with their respective bandwidth, data rate, and coverage characteristics.
Figure 6.3: NB-IoT uplink multi-tone and single-tone options

Power Concentration Principle:

When using fewer tones, transmit power is concentrated in narrower bandwidth:

12-tone configuration:
├─ Total TX power: 200 mW (23 dBm)
├─ Bandwidth: 180 kHz (12 tones × 15 kHz)
├─ Power spectral density: 200 mW / 180 kHz = 1.11 mW/kHz
└─ Power per tone: 200 mW / 12 = 16.7 mW per tone

1-tone @ 15 kHz configuration:
├─ Total TX power: 150 mW (22 dBm)
├─ Bandwidth: 15 kHz (single tone)
├─ Power spectral density: 150 mW / 15 kHz = 10 mW/kHz
└─ Power concentrated: 150 mW in ONE tone

Link budget comparison:
- 12-tone: 16.7 mW per tone = 12.2 dBm per tone
- 1-tone: 150 mW in one tone = 21.8 dBm
→ Single-tone has +9.6 dB advantage per tone!

This +9.6 dB translates to:
- 2× better range in same coverage class
- OR half the repetitions needed for same reliability

Detailed Performance Comparison:

Configuration Bandwidth Data Rate TX Power Coverage Repetitions (RSRP = -115 dBm) Battery Impact
12 tones @ 15 kHz 180 kHz 160 kbps 200 mA Normal 16-32× High (packet loss)
3 tones @ 15 kHz 45 kHz 40 kbps 180 mA Extended 8-16× Medium
1 tone @ 15 kHz 15 kHz 16 kbps 150 mA Extended+ 4-8× Low
1 tone @ 3.75 kHz 3.75 kHz 5 kbps 120 mA Extreme 1-4× Lowest

Choosing the Right Configuration:

Decision flowchart for selecting NB-IoT uplink tone configuration based on RSRP signal quality, showing 12-tone for excellent signal, 3-tone for good signal, 1-tone 15 kHz for extended coverage, and 1-tone 3.75 kHz for extreme coverage.
Figure 6.4: Tone configuration selection based on signal quality

Battery Life Calculation Example:

Scenario: 100-byte message, 4 transmissions per day, RSRP = -115 dBm

Configuration comparison:

12-tone @ 15 kHz:
├─ Data rate: 160 kbps
├─ Base transmission time: (100 × 8 bits) / 160 kbps = 5 ms
├─ Repetitions needed: 32× (poor link budget at -115 dBm)
├─ Total TX time: 5 ms × 32 = 160 ms
├─ Retransmissions (30% packet loss): 3 attempts
├─ Effective time: 160 ms × 3 = 480 ms
├─ TX power: 200 mA
├─ Daily energy: 4 × 0.48s × 200mA = 0.384 mAh/day
└─ Battery life: 10,000 mAh / (0.384 + 0.12 PSM) = 19,841 days = 54 years
   BUT: High packet loss (30%) = unreliable ❌

1-tone @ 15 kHz:
├─ Data rate: 16 kbps
├─ Base transmission time: (100 × 8) / 16 kbps = 50 ms
├─ Repetitions needed: 8× (better link budget from power concentration)
├─ Total TX time: 50 ms × 8 = 400 ms
├─ Retransmissions: Minimal (99% delivery)
├─ Effective time: 400 ms × 1.01 = 404 ms
├─ TX power: 150 mA
├─ Daily energy: 4 × 0.404s × 150mA = 0.242 mAh/day
└─ Battery life: 10,000 / (0.242 + 0.12) = 27,624 days = **75 years** ✅

Key insight:
- 12-tone seems faster (160 kbps vs 16 kbps)
- But needs 4× more repetitions due to weaker per-tone power
- 1-tone uses less total energy AND more reliable!

Design Recommendation:

For battery-powered NB-IoT devices with <500 byte payloads:

  1. Good signal (> -108 dBm): Use 3-tone @ 15 kHz
    • Balanced speed and power
    • Battery life: 12-18 years
  2. Extended coverage (-108 to -125 dBm): Use 1-tone @ 15 kHz
    • Optimal power efficiency
    • Battery life: 10-15 years
    • 99%+ reliability
  3. Extreme coverage (< -125 dBm): Use 1-tone @ 3.75 kHz
    • Maximum coverage
    • Battery life: 8-12 years
    • Last resort option

Avoid 12-tone mode for battery-powered devices unless: - Excellent signal (> -100 dBm) AND - Large payloads (> 500 bytes) AND - Battery life < 5 years acceptable

6.6 Knowledge Check

Test your understanding of NB-IoT channel access:

Question 1: Single-Tone vs Multi-Tone Uplink

You’re optimizing an NB-IoT sensor deployment for long battery life and reliable delivery. Each sensor sends 50-byte messages every 6 hours. Your carrier’s NB-IoT network supports multiple uplink tone configurations.

Signal quality at the sensor location: RSRP ≈ -115 dBm (extended coverage)

Answer & Detailed Explanation

Correct Answer: C) 1 tone @ 15 kHz (best balance for -115 dBm signal)

6.6.2 Battery Life Calculation

Scenario: 50-byte payload, 4 transmissions per day, RSRP = -115 dBm (extended coverage)

Option C: 1 tone @ 15 kHz (15 kHz bandwidth) ✅

Data rate: 16 kbps
Transmission time: 400 bits / 16,000 bps × 15 (overhead) = 0.375 seconds

Coverage enhancement (8 repetitions needed - single tone has better link budget):
- Total: 0.375s × 8 = 3 seconds

TX power (1 tone): 150 mA (lower power for single carrier)
Daily energy:
- 4 × 3s × 150mA = 12s × 150mA = 0.5 mAh/day
- PSM sleep: 0.12 mAh/day
Total: 0.62 mAh/day

Battery life: 10,000 ÷ 0.62 = 16,129 days = **44.2 years** ✅

Reliability: Excellent (99%+ delivery) ✅

Why this is optimal:
- Single tone concentrates power → better coverage per repetition
- Needs HALF the repetitions vs 12-tone mode (8× vs 16×)
- Lower TX power (150mA vs 200mA)
- Best reliability at -115 dBm signal level

Option D: 1 tone @ 3.75 kHz (3.75 kHz bandwidth)

Data rate: 5 kbps
Transmission time: 400 bits / 5,000 bps × 15 (overhead) = 1.2 seconds

Coverage enhancement (only 2 repetitions needed - extreme coverage capability):
- Total: 1.2s × 2 = 2.4 seconds

TX power (1 tone narrow): 120 mA (lowest power)
Daily energy:
- 4 × 2.4s × 120mA = 9.6s × 120mA = 0.32 mAh/day
- PSM sleep: 0.12 mAh/day
Total: 0.44 mAh/day

Battery life: 10,000 ÷ 0.44 = 22,727 days = **62.3 years** ✅✅

Wait, this seems best! Why not choose D?

Problem: 3.75 kHz mode is ONLY for extreme coverage (< -125 dBm)
- Your signal: -115 dBm (extended coverage, not extreme)
- Using 3.75 kHz wastes time (1.2s vs 0.375s per transmission)
- Longer transmission = more vulnerable to interference
- Should reserve 3.75 kHz for basement/underground devices

Verdict: Overkill for -115 dBm signal

6.6.3 Tone Configuration Decision Matrix

Signal Quality (RSRP) → Optimal Tone Configuration

Excellent (-85 to -100 dBm):
├─ Large payloads (>500 bytes): 12 tones @ 15 kHz
├─ Medium payloads (100-500 bytes): 3 tones @ 15 kHz
└─ Small payloads (<100 bytes): 3 tones @ 15 kHz

Good (-100 to -108 dBm):
├─ Large payloads: 3 tones @ 15 kHz
└─ Small payloads: 1 tone @ 15 kHz

Extended (-108 to -125 dBm):
└─ All payloads: **1 tone @ 15 kHz** ✅ (your scenario!)

Extreme (< -125 dBm):
└─ All payloads: 1 tone @ 3.75 kHz (maximum coverage)

Your sensor location: -115 dBm → 1 tone @ 15 kHz is perfect match

Question 2: Frequency Hopping in Single-Tone Mode

You’re deploying NB-IoT sensors in an industrial area where there is intermittent narrowband interference in parts of the uplink band. Your devices use single-tone NPUSCH for coverage.

Answer & Detailed Explanation

Correct Answer: C) Frequency diversity against interference/fading

6.6.4 Why hopping helps (even with one tone)

In single-tone mode, the uplink uses one narrow subcarrier at a time. If the device stayed on the same tone, two common real-world problems can break the link:

  • Narrowband interference: A jammer or industrial emitter might occupy only a small slice of the band.
  • Frequency-selective fading: Due to multipath, some frequencies can be in a deep fade while nearby frequencies are not.

By hopping the tone index across symbol groups/subframes, NB-IoT spreads the transmission across different frequencies over time. This provides frequency diversity, which improves decoding probability and can reduce the need for retransmissions.

6.6.5 What hopping does not do

  • It does not raise transmit power above regulatory/radio limits (TX power is unchanged).
  • It does not replace coverage-enhancement repetitions; it complements them.
  • It does not change PSM/eDRX sleep current; those are power-mode behaviors.

6.7 Adaptive Tone Configuration

Some NB-IoT implementations support dynamic tone selection:

// Device-side adaptive configuration (pseudo-code)

float rsrp = measure_rsrp();
int payload_size = get_message_size();

if (rsrp >= -100 && payload_size > 200) {
    // Excellent signal + large payload → use multi-tone for speed
    configure_npusch(12_TONES, 15_KHZ);
}
else if (rsrp >= -108) {
    // Good signal → 3-tone balance
    configure_npusch(3_TONES, 15_KHZ);
}
else if (rsrp >= -125) {
    // Extended coverage → single-tone @ 15 kHz
    configure_npusch(1_TONE, 15_KHZ);
}
else {
    // Extreme coverage → single-tone @ 3.75 kHz
    configure_npusch(1_TONE, 3_75_KHZ);
}

// Transmit message
send_npusch_message(payload);

// Log performance for analysis
log_transmission(rsrp, tone_config, repetitions, success);

Illustrative Optimization Example (Hypothetical):

Large rural sensor deployment:

Initial configuration (suboptimal):
├─ Default: 3 tones @ 15 kHz (carrier default)
├─ Coverage: many devices have RSRP < -108 dBm (extended coverage)
└─ Issue: retries and reduced battery life in marginal signal

Optimization:
├─ Segment devices by RSRP (good vs extended coverage)
├─ Reconfigure: switch to 1 tone @ 15 kHz for RSRP < -108 dBm
├─ Results:
│   ├─ Fewer retries and more reliable delivery
│   └─ Longer battery life in extended coverage

Key lesson:
Carrier default configurations are optimized for average case,
not worst-case coverage. Request single-tone mode for extended
coverage deployments to maximize battery life.

6.8 Why Single-Tone is More Power-Efficient in Extended Coverage

Power concentration principle:

12-tone transmission (180 kHz bandwidth):
- Total TX power: 200 mA
- Power per tone: 200mA / 12 = 16.7 mA per 15 kHz tone
- Energy per bit: 200mA / 160 kbps = 1.25 mA per kbps

1-tone transmission (15 kHz bandwidth):
- Total TX power: 150 mA
- Power for single tone: 150 mA (all power concentrated!)
- Energy per bit: 150mA / 16 kbps = 9.4 mA per kbps

Link budget comparison:
- 12-tone: Power spread across 180 kHz → -10 dB per tone
- 1-tone: Power concentrated in 15 kHz → 0 dB (reference)
→ Single tone has +10 dB advantage per tone!

Result:
- 1-tone mode needs 8 repetitions for -115 dBm
- 12-tone mode needs 16 repetitions for -115 dBm
→ Single tone is 2× more efficient in marginal coverage

Let’s quantify the link budget advantage of single-tone versus multi-tone. The power spectral density (PSD) determines signal strength per Hz of bandwidth:

\(\text{PSD} = \frac{P_{\text{TX}}}{\text{Bandwidth}}\)

12-tone configuration (180 kHz): \(\text{PSD}_{12} = \frac{200 \text{ mW}}{180 \text{ kHz}} = 1.11 \text{ mW/kHz}\)

Per-tone power (each tone is 15 kHz): \(P_{\text{tone}} = 1.11 \times 15 = 16.67 \text{ mW} = 12.2 \text{ dBm}\)

1-tone configuration (15 kHz): \(\text{PSD}_{1} = \frac{150 \text{ mW}}{15 \text{ kHz}} = 10 \text{ mW/kHz}\)

Single tone power: \(P_{\text{tone}} = 10 \times 15 = 150 \text{ mW} = 21.8 \text{ dBm}\)

Link budget advantage: \(\text{Gain} = 21.8 - 12.2 = 9.6 \text{ dB}\)

This 9.6 dB gain translates directly to coverage extension. Using the Friis equation, path loss scales as \(20\log_{10}(d)\) where \(d\) is distance. A 9.6 dB improvement means:

\(20\log_{10}\left(\frac{d_2}{d_1}\right) = 9.6\) \(d_2 = d_1 \times 10^{9.6/20} = d_1 \times 3.0\)

Single-tone mode achieves 3× the range of 12-tone mode at the same repetition count, or equivalently, needs half the repetitions for the same coverage. For a device at -115 dBm requiring 16 repetitions in 12-tone mode, single-tone needs only 8 repetitions — cutting airtime and energy consumption by 50%.

6.9 Common Carrier Configuration Mistakes

When deploying NB-IoT at scale, the default carrier configuration is rarely optimal for your specific use case. Understanding these common mistakes saves months of debugging.

Mistake 1: Accepting carrier default tone configuration. Most carriers default to 3-tone or 12-tone uplink because it maximizes network capacity (more devices per cell). But for battery-powered devices in extended coverage, single-tone mode reduces energy consumption by 30-50%. You must explicitly request tone configuration changes from your carrier or use AT commands to override on the device.

Mistake 2: Not requesting extended coverage mode. NB-IoT supports three coverage enhancement levels (CE Level 0, 1, 2). Many carriers only enable CE Level 0 by default. If your devices are in basements or rural areas, you need CE Level 1 or 2, which requires carrier-side configuration. Deploying without proper CE level means devices repeatedly fail to connect and drain batteries on failed attempts.

Mistake 3: Using default eDRX/PSM timers. Carriers typically set conservative PSM timers (T3412 = 1 hour) to avoid stale registrations. For devices reporting once per day, a 24-hour PSM timer saves significant power. Negotiate longer timers with your carrier before deployment, and test that the carrier actually honors the requested timer values – some carriers silently cap timers at shorter intervals.

Scenario: Smart city deploys 5,000 NB-IoT parking sensors across downtown (dense urban environment with buildings, metal structures). Sensors report occupancy changes (vehicle arrival/departure) with 20-byte payload.

Signal Quality Survey Results:

  • Zone A (street level, open): 2,500 sensors, RSRP = -95 dBm (good signal)
  • Zone B (underground parking): 1,800 sensors, RSRP = -118 dBm (extended coverage)
  • Zone C (basement garages): 700 sensors, RSRP = -128 dBm (extreme coverage)

Tone Configuration Strategy:

Zone A (RSRP -95 dBm): 3-tone @ 15 kHz

  • Bandwidth: 45 kHz (3 tones × 15 kHz)
  • Data rate: ~40 kbps
  • Airtime for 20-byte payload: ~50 ms
  • Repetitions needed: 2× (good signal = minimal retries)
  • Total TX time: 50 ms × 2 = 100 ms
  • TX power: 180 mA
  • Energy per message: 180 mA × 0.1 s = 18 mAs = 0.005 mAh
  • Battery life (4 events/day, 2,000 mAh): 2,000 / (0.02 + 0.12 PSM) = 14,286 days = 39 years

Zone B (RSRP -118 dBm): 1-tone @ 15 kHz

  • Bandwidth: 15 kHz (single tone)
  • Data rate: ~16 kbps
  • Airtime for 20-byte payload: ~150 ms
  • Repetitions needed: 8× (power concentration improves link budget)
  • Total TX time: 150 ms × 8 = 1,200 ms
  • TX power: 150 mA (lower due to single carrier)
  • Energy per message: 150 mA × 1.2 s = 180 mAs = 0.05 mAh
  • Battery life: 2,000 / (0.20 + 0.12) = 6,250 days = 17 years

Zone C (RSRP -128 dBm): 1-tone @ 3.75 kHz

  • Bandwidth: 3.75 kHz (ultra-narrow single tone)
  • Data rate: ~5 kbps
  • Airtime for 20-byte payload: ~400 ms
  • Repetitions needed: 4× (extreme coverage mode)
  • Total TX time: 400 ms × 4 = 1,600 ms
  • TX power: 120 mA (lowest power, maximum concentration)
  • Energy per message: 120 mA × 1.6 s = 192 mAs = 0.053 mAh
  • Battery life: 2,000 / (0.21 + 0.12) = 6,061 days = 16.6 years

Result Summary:

  • Zone A (3-tone): 100 ms airtime, 39-year battery life
  • Zone B (1-tone 15 kHz): 1,200 ms airtime, 17-year battery life
  • Zone C (1-tone 3.75 kHz): 1,600 ms airtime, 16.6-year battery life

Key Insight: Single-tone modes use 12-16x MORE airtime but achieve 99%+ delivery reliability in extended/extreme coverage. The longer transmission is offset by fewer retries and lower power per transmission.

RSRP Signal Level Recommended Tone Config Data Rate Typical Use Case Battery Impact
> -100 dBm (Excellent) 12-tone @ 15 kHz 160 kbps Outdoor sensors, good coverage 1× (baseline)
-100 to -108 dBm (Good) 3-tone @ 15 kHz 40 kbps Urban sensors, normal coverage 2.5×
-108 to -125 dBm (Extended) 1-tone @ 15 kHz 16 kbps Indoor/basement, extended coverage 6×
< -125 dBm (Extreme) 1-tone @ 3.75 kHz 5 kbps Deep indoor/underground, last resort 8×

Step-by-Step Configuration Process:

Step 1: Measure actual RSRP at deployment location

  • Use NB-IoT module AT command: AT+QRSRP (Quectel) or AT+CESQ (u-blox)
  • Take 10 measurements over 1 hour to account for variability
  • Use worst-case RSRP (minimum value) for configuration

Step 2: Select tone configuration based on RSRP

if (rsrp_dBm > -100) {
    tone_config = "3-tone @ 15 kHz";  // Good signal, prioritize speed
} else if (rsrp_dBm > -108) {
    tone_config = "1-tone @ 15 kHz";  // Moderate signal, balance
} else if (rsrp_dBm > -125) {
    tone_config = "1-tone @ 15 kHz";  // Extended coverage
} else {
    tone_config = "1-tone @ 3.75 kHz";  // Extreme coverage only
}

Step 3: Validate with field test

  • Deploy 10-20 test devices with selected configuration
  • Monitor packet delivery ratio (PDR) for 7 days
  • Target: PDR > 95% for acceptable performance
  • If PDR < 95%, increase tone concentration (e.g., 3-tone → 1-tone)

Step 4: Optimize for capacity vs coverage trade-off

  • Capacity-constrained network (many devices per cell): Use multi-tone modes to minimize airtime per device
  • Coverage-limited deployment (few devices, deep indoor): Use single-tone modes with higher CE levels for maximum reliability

Real-World Example (Vodafone Germany Water Meters, 2021):

  • Initial deployment: All meters on 12-tone @ 15 kHz (fastest)
  • Problem: 18% of basement meters had PDR < 90%
  • Fix: Basement meters switched to 1-tone @ 15 kHz
  • Result: PDR improved to 98.2%, battery life reduced from projected 18 years to 12 years (still acceptable for 15-year meter lifespan)
Common Mistake: Not Requesting Extended Coverage Mode from Carrier

The Error: A logistics company deployed 8,000 NB-IoT asset trackers in shipping containers (metal boxes). They used carrier default configuration: 3-tone @ 15 kHz without verifying coverage class. Devices worked fine during outdoor testing but failed when placed inside metal containers.

What Went Wrong:

  1. Default carrier profile: CE Level 0 (normal coverage, 0-4 repetitions)
  2. Metal container attenuation: Additional 15-20 dB path loss
  3. Result: RSRP inside container = -122 dBm (extended coverage needed)
  4. Outcome: 42% of transmissions failed, tracker appeared offline

Why Devices Didn’t Auto-Adapt:

  • CE Level is operator-configured, not device-selected
  • Device can request higher CE level, but many carriers ignore the request unless explicitly enabled on their side
  • Carrier must enable CE Level 1 (8-16 repetitions) or CE Level 2 (32-64 repetitions) in network configuration

The Fix:

  1. Before deployment: Contact carrier to enable CE Level 2 (maximum coverage)
  2. Configure device: Set AT+NCONFIG="CELL_RESELECTION","LTEonly" and AT+NCONFIG="AUTOCONNECT","TRUE"
  3. Force extended coverage: Use AT+QNBIOTRAI=1 (Quectel) to request CE Level 2
  4. Verify: Check actual CE level with AT+QENG="servingcell" - confirm “CE Level 2” in response

Result After Fix:

  • CE Level 2 enabled: 32-64 repetitions per transmission
  • Packet Delivery Ratio: Improved from 58% to 97.8%
  • Trade-off: Airtime increased 8-12x, battery life reduced from 5 years to 3.2 years (still within product lifecycle)

Lesson: Never assume carrier default configuration supports your deployment environment. For metal enclosures, basements, or underground installations, explicitly request CE Level 1 or 2 from your carrier during network provisioning. Test with the actual coverage class enabled, not just outdoor open-air conditions.

6.10 Summary

6.11 Concept Relationships

NB-IoT channel access mechanisms connect to: NB-IoT Architecture NPUSCH/NPDSCH uplink/downlink channels, Coverage Enhancement repetition coding improving link budget, and Power Optimization tone configuration impacting energy consumption. Single-tone vs multi-tone selection relates to NB-IoT Applications deployment scenarios (basement vs outdoor).

6.12 See Also

Common Pitfalls

NB-IoT devices in high-density deployments may fail to receive NPUSCH resource grants due to cell congestion. Firmware that assumes every NPRACH attempt will be followed by resource grant will hang waiting for a NPDCCH DCI. Implement a backoff algorithm: if no resource grant within T3 timer (default 6.8 s), retry NPRACH with exponential backoff up to 5 minutes, then enter eDRX for cell load relief. Log access attempts and failures for network optimization.

NB-IoT maximum TBS (Transport Block Size) is 85 bytes per transmission, but IP + UDP + application headers consume 28–40 bytes, leaving only 45–57 bytes for application payload per radio block. Sending 200-byte sensor readings requires 4–5 radio blocks with associated retransmission overhead. Design application protocol to: pack multiple sensor readings into a single optimally-sized payload, use binary encoding (CBOR, protobuf) instead of JSON, and stay under 100 bytes total IP payload for single-block transmission.

NB-IoT devices self-select coverage enhancement level based on measured signal quality. In good coverage (RSRP > -100 dBm), CE Level 0 uses minimal energy. In poor coverage (RSRP < -120 dBm), CE Level 3 with 2048 repetitions consumes 100–1000× more energy per transmission than CE Level 0. A power budget calculated only for good-coverage conditions drastically underestimates energy consumption for basement-installed devices. Model energy distribution across CE levels using the deployment site survey signal quality distribution.

NB-IoT supports both 3.75 kHz (single-tone, non-standard) and 15 kHz (LTE-compatible) subcarrier spacing. The 3.75 kHz single-tone mode provides longer range and lower power at the cost of lower throughput. Some NB-IoT modules default to 15 kHz in all modes; others can be configured. Verify subcarrier spacing configuration matches the target application’s range vs. throughput requirements, and confirm the operator network supports the configured spacing for in-band deployment.

6.13 What’s Next

Chapter Focus Why Read Next
NB-IoT Coverage Enhancement Repetition mechanisms See how CE levels interact with tone configuration to achieve 164 dB MCL
NB-IoT PSM and eDRX Power saving modes Combine channel optimization with sleep timers for maximum battery life
NB-IoT Labs and Implementation AT command exercises Apply tone configuration and channel settings in hands-on lab exercises
Cellular IoT Comprehensive Review NB-IoT vs LTE-M Compare NB-IoT channel access with LTE-M approaches