5  NB-IoT Architecture

Cellular IoT Network Architecture and Components

In 60 Seconds

NB-IoT extends the LTE Evolved Packet Core (EPC) with IoT-specific optimizations, using components like eNodeB, MME, SCEF, S-GW, and P-GW to create two data paths – Control Plane optimization for small data piggybacked on signaling and User Plane optimization for larger transfers – dramatically reducing power consumption and signaling overhead for constrained devices.

Key Concepts
  • NB-IoT Deployment Modes: In-Band (within existing LTE carrier), Guard-Band (in LTE guard frequencies), Standalone (dedicated 200 kHz, e.g., repurposed GSM spectrum)
  • NB-IoT Physical Channels: NPDCCH (downlink control), NPDSCH (downlink shared), NPUSCH (uplink shared), NPBCH (broadcast channel), NPRACH (random access)
  • MME (Mobility Management Entity): Core network node managing device registration, authentication, and session control; for NB-IoT, handles non-IP data delivery
  • SCEF (Service Capability Exposure Function): NB-IoT-specific 3GPP core function enabling non-IP data delivery and API access for application servers without IP stack
  • Non-IP Data Delivery (NIDD): NB-IoT feature for sending small application payloads (<512 bytes) through the cellular core without IP encapsulation, reducing overhead for tiny data
  • NB-IoT eNB (eNodeB): LTE base station serving NB-IoT devices; may serve NB-IoT in a narrow carrier alongside full-bandwidth LTE traffic
  • Anchor Carrier: The NB-IoT carrier used for initial cell access, system information broadcast, and paging; device must camp on anchor carrier first before data communication
  • NRS (Narrowband Reference Signal): NB-IoT pilot signal used for channel estimation and RSRP measurement; occupies fixed subcarriers within the NB-IoT carrier

Prerequisites: NB-IoT Technical Specifications | Cellular IoT Fundamentals

This enables: NB-IoT Power Optimization | NB-IoT Applications

5.1 Learning Objectives

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

  • Describe the CIoT architecture: Explain the components and their roles in NB-IoT networks
  • Differentiate data paths: Compare Control Plane and User Plane optimization trade-offs for small data transmission
  • Classify key components: Categorize the functions of eNodeB, MME, SCEF, S-GW, and P-GW within the NB-IoT architecture
  • Trace the attach procedure: Outline the sequence of steps an NB-IoT device follows to register with the network

NB-IoT piggybacks on existing cellular infrastructure, reusing the same cell towers and core network as your smartphone. Devices connect to a base station, which routes data through the cellular core to the internet and ultimately to your IoT platform. This chapter explains each component in the NB-IoT network architecture.

“Let me show you how my data travels!” Sammy the Sensor began. “When I send a temperature reading, it first goes to the nearest cell tower – called an eNodeB. From there, it travels through the cellular core network, passing through components with fancy names like MME, S-GW, and P-GW, until it reaches the internet and arrives at your IoT dashboard!”

“Think of it like the postal system,” Lila the LED suggested. “Sammy’s sensor reading is a letter. The cell tower is the local post office. The core network components are the sorting centers and delivery routes. And the IoT application server is the recipient’s mailbox. Each step along the way knows exactly where to send the letter next.”

Max the Microcontroller explained, “NB-IoT has two clever paths for sending data. The Control Plane path piggybacks small data onto signaling messages – it is like writing a quick note on the envelope itself instead of putting a letter inside. For tiny sensor readings, this is faster and uses less power. The User Plane path is for bigger transfers, like firmware updates.”

“The beautiful thing about NB-IoT architecture,” Bella the Battery said, “is that it reuses existing LTE infrastructure. Cell tower operators do not need to build new towers – they just update the software. That means NB-IoT coverage can roll out quickly and cheaply, which keeps the cost low for IoT devices like us!”

5.2 Cellular IoT Architecture Overview

The Cellular IoT (CIoT) architecture extends the traditional LTE Evolved Packet Core (EPC) with optimizations specifically designed for IoT applications. NB-IoT introduces new components and procedures that dramatically reduce power consumption and signaling overhead for devices that send small, infrequent data.

Cellular IoT architecture for NB-IoT showing device connecting to eNodeB, MME via S1-MME, S-GW via S1-U, SCEF for IoT API exposure, HSS for authentication, and P-GW for internet connectivity.

CIoT Architecture Overview
Figure 5.1

Comprehensive NB-IoT network architecture diagram showing the complete signal path from IoT devices (sensors, meters, trackers) through the radio access network (eNodeB base stations), evolved packet core (MME, SGW, PGW), to application servers and cloud platforms, illustrating how NB-IoT integrates with existing LTE infrastructure.

NB-IoT Architecture

Sequence diagram of NB-IoT device attach procedure showing the signaling exchange between UE (device), eNodeB, MME, and HSS including RRC connection establishment, authentication, security mode command, and bearer setup to complete network attachment.

NB-IoT Attach Procedure
Figure 5.2: NB-IoT network architecture and device attachment procedure

5.3 Key Architecture Components

5.3.1 1. Radio Access Network (RAN)

eNodeB (Evolved Node B):

The eNodeB is the LTE base station that handles radio communication with NB-IoT devices.

Functions:

  • Manages radio resource scheduling for NB-IoT and LTE traffic
  • Handles NB-IoT physical layer (NPSS, NSSS, NPBCH, NPDCCH, NPDSCH, NPUSCH)
  • Performs Coverage Enhancement (CE) mode selection
  • Manages RRC (Radio Resource Control) connection states

NB-IoT Physical Channels:

Channel Direction Purpose
NPSS DL Narrowband Primary Synchronization Signal
NSSS DL Narrowband Secondary Synchronization Signal
NPBCH DL Narrowband Physical Broadcast Channel
NPDCCH DL Narrowband Physical Downlink Control Channel
NPDSCH DL Narrowband Physical Downlink Shared Channel
NPRACH UL Narrowband Physical Random Access Channel
NPUSCH UL Narrowband Physical Uplink Shared Channel

5.3.2 2. Mobility Management Entity (MME)

The MME is the control plane component that manages device registration, authentication, and mobility.

Functions:

  • Authentication and security: EPS-AKA (Authentication and Key Agreement) with SIM/USIM
  • Mobility management: Tracking Area Updates (TAU), handover coordination
  • Session management: EPS bearer context establishment and modification
  • Control plane signaling: NAS (Non-Access Stratum) message handling
  • PSM/eDRX timer negotiation: Configures power-saving parameters with devices

5.3.3 3. Service Capability Exposure Function (SCEF)

The SCEF is a new component introduced specifically for IoT in 3GPP Release 13. It provides APIs for IoT applications and enables efficient small data delivery.

Functions:

  • APIs for IoT applications: RESTful interfaces for device management
  • Non-IP data delivery: Optimized path for small payloads without IP overhead
  • Event monitoring: Connectivity status, location, reachability reporting
  • Device triggering: Wake up devices in PSM mode
  • Group messaging: Multicast/broadcast to device groups
Why SCEF Matters

For small IoT payloads (10-100 bytes), traditional IP overhead (40+ bytes for headers) represents 40-400% overhead. SCEF enables Non-IP Data Delivery (NIDD) where raw application data travels through the control plane without IP encapsulation, dramatically improving efficiency for sensor readings and status updates.

Let’s calculate the overhead savings when using Control Plane (SCEF) versus User Plane (IP) for a 50-byte smart meter reading. The efficiency ratio is:

\(\text{Efficiency} = \frac{\text{Payload}}{\text{Payload} + \text{Overhead}}\)

User Plane (IP Stack):

  • IPv6 header: 40 bytes
  • UDP header: 8 bytes
  • Application payload: 50 bytes
  • Total transmitted: 98 bytes

\(\text{Efficiency}_{\text{UP}} = \frac{50}{98} = 51\%\)

Control Plane (DoNAS via SCEF):

  • NAS message header: 6 bytes
  • Application payload: 50 bytes
  • Total transmitted: 56 bytes

\(\text{Efficiency}_{\text{CP}} = \frac{50}{56} = 89\%\)

The overhead reduction is: \(98 - 56 = 42 \text{ bytes}\) saved per message. For a meter sending 1 message/day over 10 years, this saves \(42 \times 365 \times 10 = 153,300 \text{ bytes} \approx 150 \text{ KB}\) of transmitted data. With NB-IoT practical data rates of 20-60 kbps, this 42-byte reduction saves approximately 0.007 seconds of airtime per transmission at 50 kbps (\(42 \times 8 / 50{,}000 = 0.0067 \text{ s}\)). However, the real savings come from avoiding the User Plane bearer setup (3+ seconds of signaling), making Control Plane 30-50% more energy-efficient per small message.

Quick Check: SCEF and Non-IP Data Delivery

5.3.4 4. Serving Gateway (S-GW) / Packet Gateway (P-GW)

S-GW Functions:

  • User plane traffic routing within the EPC
  • Mobility anchor for handover between eNodeBs
  • Downlink data buffering when device is in idle mode

P-GW Functions:

  • IP address assignment (IPv4 or IPv6)
  • Connection to external networks (internet, private networks)
  • Policy enforcement (QoS, charging)
  • Deep packet inspection (optional)

5.3.5 5. Home Subscriber Server (HSS)

The HSS is the central database for subscriber information and authentication.

Functions:

  • Subscriber database: IMSI, service profiles, QoS parameters
  • Authentication data: Keys for EPS-AKA authentication
  • Location information: Current MME serving the device
  • Subscription management: Data limits, roaming permissions

5.4 Control Plane vs User Plane Optimization

NB-IoT introduces Control Plane CIoT EPS Optimization for efficient small data transmission. This is one of the most important architectural innovations for IoT.

Comparison of NB-IoT Control Plane optimization (small data piggybacked on NAS signaling through MME and SCEF) versus User Plane path (traditional IP bearer through S-GW and P-GW), showing reduced signaling overhead and power consumption for Control Plane.

Control Plane vs User Plane Data Paths
Figure 5.3

5.4.1 Control Plane CIoT Optimization (DoNAS)

Data over NAS (DoNAS) sends user data piggy-backed on NAS signaling messages through the control plane.

Benefits:

  • Reduced signaling overhead: No user plane bearer establishment needed
  • Lower latency for small messages: Data travels with attach/TAU messages
  • Lower power consumption: Fewer radio transmissions required
  • Optimized for small payloads: Best for < 1600 bytes

Data Path:

Device -> eNodeB -> MME -> SCEF -> Application Server
                    (NAS)   (T6a)    (API)

5.4.2 User Plane Optimization

Traditional data path through the user plane, suitable for larger data transfers.

Benefits:

  • Higher throughput: Better for bulk data (firmware updates)
  • Established protocols: Standard IP networking
  • Multiple bearer support: Different QoS classes

Data Path:

Device -> eNodeB -> S-GW -> P-GW -> Internet -> Application Server
           (RRC)    (GTP)   (GTP)    (IP)

5.4.3 When to Use Each Path

Scenario Recommended Path Reason
Sensor reading (< 100 bytes) Control Plane Minimal overhead
Status update (100-500 bytes) Control Plane Fast delivery
Firmware update (> 10 KB) User Plane Higher throughput
Frequent small messages Control Plane Power efficiency
Bidirectional session User Plane Session state

5.5 NB-IoT Attach Procedure

Understanding the attach procedure helps explain the power consumption and latency characteristics of NB-IoT devices.

5.5.1 Attach Procedure Steps

Step 1: Cell Search and Selection

  1. Device scans for NB-IoT cells using synchronization signals (NPSS/NSSS)
  2. Reads Master Information Block (MIB-NB) for system parameters
  3. Reads System Information Blocks (SIB1-NB, SIB2-NB) for access configuration
  4. Evaluates cell suitability based on signal quality (RSRP, RSRQ)
  5. Selects Coverage Enhancement (CE) level based on path loss

Step 2: Random Access (NPRACH)

  1. Device transmits preamble on NPRACH (Narrowband Physical Random Access Channel)
  2. Number of repetitions determined by CE level
  3. eNodeB responds with Random Access Response (RAR)
  4. Device sends RRC Connection Request (Msg3)
  5. eNodeB sends RRC Connection Setup (Msg4)

Step 3: Authentication (EPS-AKA)

  1. MME retrieves authentication vectors from HSS
  2. Authentication Request sent to device (RAND, AUTN)
  3. Device verifies network authenticity using USIM
  4. Device calculates and sends RES (Response)
  5. Keys derived: K_ASME, K_NASenc, K_NASint

Step 4: Security Mode Establishment

  1. MME sends NAS Security Mode Command (selected algorithms)
  2. Device activates NAS security (encryption + integrity)
  3. Device sends NAS Security Mode Complete

Step 5: Attach Accept

  1. MME sends Attach Accept with:
    • T3412 value (TAU timer - extended periodic tracking area update)
    • T3324 value (Active timer - time before entering PSM)
    • eDRX parameters (if requested and supported)
    • PDN connection parameters
  2. Device sends Attach Complete
  3. Device is now EMM-REGISTERED

5.5.2 Timing Considerations

Procedure Phase Typical Duration Notes
Cell search 1-5 seconds Depends on signal strength
Random access 0.5-2 seconds Longer with CE repetitions
Authentication 1-2 seconds Network latency dependent
Security mode 0.5-1 second
Attach complete 0.5-1 second
Total 3-10 seconds First attach; subsequent faster

5.6 Architecture for Smart Metering Example

To illustrate the architecture in practice, consider a smart water meter deployment:

Smart Water Meter
       |
       | (NB-IoT Radio - 180 kHz)
       v
   eNodeB (City Cell Tower)
       |
       | (S1 Interface)
       v
   MME (Carrier Core Network)
       |
       +---> HSS (Subscriber Database)
       |
       +---> SCEF (IoT API Gateway)
                  |
                  | (T6a Interface)
                  v
          Utility Company Cloud
          - Billing System
          - Leak Detection AI
          - Customer Portal

Data Flow for Daily Meter Reading:

  1. Meter wakes from PSM at scheduled time
  2. Resumes RRC connection (faster than full attach)
  3. Sends reading via Control Plane (NAS message)
  4. MME forwards to SCEF via T6a interface
  5. SCEF delivers to utility company via REST API
  6. Meter receives ACK, restarts T3324 timer
  7. After T3324 expires, enters PSM again

Key Architectural Benefits:

  • No IP overhead: Meter reading travels as raw bytes through SCEF
  • Carrier SLA: Guaranteed delivery to utility company
  • Centralized management: SCEF provides fleet management APIs
  • Security: End-to-end encryption via 3GPP security

5.7 Knowledge Check

5.8 Architecture Selection Guide: When to Use Control Plane vs User Plane

The choice between Control Plane (CP) and User Plane (UP) optimization is one of the most consequential NB-IoT architecture decisions. Selecting the wrong path can increase device power consumption by 3–5x or add unnecessary cost per message. The table below provides a decision framework based on real operator deployment data.

Decision matrix:

Criterion Control Plane (DoNAS) User Plane (IP) Why
Payload size <512 bytes >512 bytes CP overhead is fixed (~300 bytes NAS signaling); for small payloads, this is efficient. For large payloads, UP’s IP headers become proportionally insignificant
Message frequency <12 per day >12 per day CP re-establishes the signaling path each time. UP can maintain a PDN connection and reuse it, amortizing setup cost
Latency tolerance >5 seconds OK <2 seconds needed CP routes through MME (control plane), adding 2–5 seconds. UP sends directly through S-GW/P-GW
Server integration REST APIs via SCEF Standard IP/UDP/TCP CP requires operator SCEF access. UP works with any IP endpoint
Firmware updates Not suitable Required OTA updates (50–200 KB) need reliable IP transport with segmentation
Bidirectional control Limited Full support CP downlink requires device triggering via SCEF; UP allows direct IP push

Real-world comparison from Vodafone NB-IoT network (2022 deployment data):

A European water utility deployed 28,000 smart meters across two regions – 14,000 using CP and 14,000 using UP – to compare operational characteristics over 12 months.

Metric Control Plane User Plane
Average current per message 42 mA for 1.8 s 48 mA for 0.6 s + 120 mA for 3.2 s (bearer setup)
Energy per 64-byte reading 0.076 mJ 0.41 mJ
Energy per 2 KB firmware chunk 0.52 mJ 0.19 mJ
Projected 5-year battery life 11.2 years (2x daily readings) 6.8 years (2x daily readings)
Monthly SCEF API cost per device EUR 0.02 EUR 0 (direct IP)
Message success rate 99.1% 99.7%

The counterintuitive finding: CP was 5.4x more energy-efficient for small meter readings, but UP was 2.7x more efficient for firmware updates because the IP bearer setup cost was amortized across the larger payload. The utility’s final architecture uses CP for daily readings and temporarily switches to UP mode for quarterly firmware updates – a hybrid approach that maximized battery life while maintaining updateability.

Scenario: Thames Water deploys 500,000 NB-IoT smart water meters across London. Each meter sends a 64-byte daily consumption reading at 2:00 AM (randomized ±2 hours to avoid network congestion).

Architecture Flow:

  1. Device Layer (NB-IoT Water Meter)
    • Wakes from PSM at scheduled time (T3324 = 20 seconds active time)
    • Sends 64-byte reading via Control Plane (DoNAS) to minimize signaling
    • Meter includes: consumption (4 bytes), leak flag (1 byte), battery voltage (2 bytes), timestamp offset (2 bytes)
  2. Radio Access Network (eNodeB)
    • Cell tower receives uplink on NPUSCH (single-tone 15 kHz for extended coverage)
    • CE Level 1 (8 repetitions) for basements: 64 bytes × 8 = 512 bytes transmitted
    • Airtime: ~4 seconds (vs 45 seconds at SF12 LoRaWAN equivalent)
  3. Core Network (MME + SCEF)
    • MME receives NAS message with meter reading piggybacked
    • SCEF extracts application data and forwards via T6a interface to utility cloud
    • No IP bearer setup required (Control Plane optimization saves ~2 seconds and 0.15 mAh battery per transmission)
  4. Application Server (Thames Water Billing System)
    • REST API receives JSON payload: {"meterId": "TW-47291", "consumption_m3": 1.247, "leak": false, "batteryV": 3.6}
    • Leak detection AI processes reading
    • Billing system updated

Energy Budget (Control Plane):

  • PSM sleep: 15 µA × 86,380 seconds = 0.36 mAh
  • TX (4 seconds at 120 mA): 0.13 mAh
  • RX (minimal, Control Plane ACK): 0.02 mAh Daily total: 0.51 mAh → 19 Ah battery lasts 37,255 days = 102 years (actual: 15 years due to self-discharge)

Compare to User Plane:

  • Bearer setup overhead: +3 seconds TX, +0.4 mAh
  • Daily total: 0.91 mAh → battery lasts only 57 years (actual: 8-10 years)

Result: Control Plane saves 44% energy, doubling practical battery life from 8 to 15 years.

Criterion Control Plane (DoNAS) User Plane (IP) When to Choose
Payload Size ≤1,600 bytes (practical: <512) Unlimited CP if <512 bytes; UP if >1 KB
Latency Requirement 2-8 seconds <2 seconds UP if time-critical (<2s)
Message Frequency <20 per day >20 per day UP if frequent (bearer reuse)
Energy Budget 0.076 mJ per 64-byte msg 0.41 mJ per 64-byte msg CP for battery devices
Integration Requires SCEF API access Standard IP/UDP/TCP UP if no SCEF available
Bidirectional Limited downlink Full duplex UP for rich bidirectional

Step-by-Step Decision:

Step 1: Measure your payload

  • Meter reading: 64 bytes → Control Plane candidate
  • Firmware update chunk: 2 KB → User Plane required

Step 2: Count daily messages

  • 1-4 messages/day → Control Plane optimal (no bearer setup overhead)
  • 48+ messages/day → User Plane better (amortize bearer cost)

Step 3: Check latency needs

  • Utility billing (24-hour tolerance) → Control Plane fine
  • Alarm system (must respond in <10s) → User Plane needed

Step 4: Verify server integration

  • SCEF API available from operator → Control Plane ready
  • No SCEF access / direct IP needed → User Plane mandatory

Real-World Example Decision Matrix:

Application Payload Frequency Latency Choice Reasoning
Water meter 64 B 1/day 1 hour OK CP Small, infrequent, battery-critical
Parking sensor 12 B 2/hour 5 sec OK CP Tiny payload, moderate frequency
Security camera 500 B 1/min 2 sec needed UP Frequent, latency-sensitive
Industrial sensor 200 B 4/day 30 sec OK CP Infrequent, battery life priority
Asset tracker (moving) 80 B 10/hour 10 sec OK UP Frequent position updates
Common Mistake: Using User Plane for All NB-IoT Devices “For Simplicity”

The Error: A municipal street lighting deployment used User Plane (IP-based) for all 12,000 NB-IoT-enabled lights because “IP is easier to integrate with our existing systems.” Each light sends a 48-byte status update (on/off, dimming level, energy consumption) every hour.

What Happened:

  • Control Plane alternative would use: 0.076 mJ per message
  • User Plane actually used: 0.41 mJ per message (5.4x MORE energy)
  • Impact: Battery backup systems (for power outage reporting) depleted in 6.8 years instead of projected 11.2 years

Why User Plane Wasted Energy:

  1. PDN connection setup overhead: Every uplink required IP bearer establishment (S-GW, P-GW signaling)
  2. IP header overhead: 40 bytes (IPv6) + 8 bytes (UDP) = 48 bytes of overhead for 48 bytes of actual data (100% waste!)
  3. Longer active time: Device stayed awake for full IP handshake (3.2 seconds vs 1.8 seconds for Control Plane)

The Fix (Retrospective Analysis): If they had used Control Plane (DoNAS) via SCEF: - Payload: 48 bytes raw data (no IP header) - Transmission time: 1.8 seconds - Energy: 0.076 mJ - Projected battery life: 11.2 years (actual target met)

Cost Impact:

  • 12,000 lights × $180 early battery replacement = $2,160,000
  • SCEF integration effort: 40 engineering hours = $8,000
  • Net loss from wrong choice: $2,152,000

Lesson: User Plane is NOT “simpler” when you account for total cost of ownership. For small, infrequent payloads (<512 bytes, <12/day), Control Plane via SCEF provides 5-6x better energy efficiency. The SCEF API integration (1-2 weeks) pays for itself immediately in battery life extension.

When User Plane IS Correct:

  • Large payloads (>1 KB): firmware updates, image thumbnails
  • High frequency (>20 messages/day): IP bearer setup cost amortized
  • Existing IP infrastructure: no SCEF access available from operator

5.9 Summary

  • CIoT architecture extends LTE EPC with IoT-specific components (SCEF) and optimizations
  • Key components: eNodeB (radio), MME (control), SCEF (IoT APIs), S-GW/P-GW (user plane), HSS (subscriber database)
  • Control Plane optimization (DoNAS) sends small data through signaling path for maximum efficiency
  • User Plane optimization provides higher throughput for larger data transfers
  • SCEF enables Non-IP Data Delivery, device triggering, and event monitoring APIs
  • Attach procedure takes 3-10 seconds for initial connection; subsequent wakeups are faster

5.10 Concept Relationships

NB-IoT architecture extends: LTE EPC fundamentals from Cellular IoT Overview with IoT-specific SCEF component, Control Plane vs User Plane optimization impacts Power Optimization energy consumption, and attach procedure timing connects to NB-IoT Channel Access NPRACH random access. Architecture decisions (CP vs UP) relate to NB-IoT Applications deployment scenarios.

5.11 See Also

Common Pitfalls

NB-IoT Standalone deployment (on dedicated 200 kHz) reuses LTE core network infrastructure — the S-GW, MME, and PGW are still LTE core components. The “standalone” refers only to the radio (no LTE carrier needed for NB-IoT radio), not an independent core network. Operators must still maintain and upgrade their LTE core to serve NB-IoT standalone devices. This means NB-IoT standalone cannot exist without LTE core, and LTE core changes affect NB-IoT devices.

NIDD bypasses the IP stack and routes data directly through the SCEF to the application server API. While NIDD eliminates IP overhead (~40 bytes per packet) and simplifies the firmware (no TCP/UDP stack), it requires the application server to have a direct SCEF API integration with the operator. This creates strong operator lock-in — switching operators requires application server re-integration. Use NIDD only when IP overhead is genuinely prohibitive (payloads <20 bytes) and you have long-term commitment to a single operator.

NB-IoT can deploy on various LTE bands: Band 8 (900 MHz) penetrates buildings far better than Band 3 (1800 MHz) due to the 6 dB lower free-space path loss at lower frequency. Deploying NB-IoT on Band 3 for basement meter applications reduces link budget by ~6 dB vs Band 8, potentially requiring 4× more coverage enhancement repetitions and increasing energy per transmission. Always check which bands operators deploy for NB-IoT in the target region and prefer sub-GHz bands for deep indoor use.

Guard-band NB-IoT deployment places the NB-IoT carrier in the LTE guard band, which is adjacent to the LTE data carriers. Poor NB-IoT transmitter spectral compliance can cause adjacent channel interference to LTE UEs, reducing LTE capacity in densely loaded cells. Device certification and network operator testing should include adjacent channel leakage ratio (ACLR) measurements for guard-band deployments. This is primarily an operator concern but affects device certification requirements.

5.12 What’s Next

Chapter Focus Why Read Next
NB-IoT Power Optimization PSM and eDRX configuration Apply architectural knowledge to achieve 10+ year battery life
NB-IoT Channel Access Physical channels and tone modes Understand the radio layer that carries Control Plane and User Plane data
NB-IoT Applications Smart metering, asset tracking See how CP vs UP architecture decisions shape real deployments
NB-IoT Practical Guide Deployment pitfalls Avoid common mistakes when implementing NB-IoT architectures