1.1 The Evolution to LTE

Long Term Evolution (LTE) represented a paradigm shift in mobile communications. Unlike its predecessors (GSM, UMTS), LTE was designed as an all-IP flat architecture with no circuit-switched domain. Every voice call, every text message, every data session travels as IP packets across a unified network.

The architecture consists of two major domains: the E-UTRAN (radio access network) and the EPC (core network). This separation is fundamental and carries directly into the 5G split between NG-RAN and 5GC.

1.2 E-UTRAN — The Radio Access

The LTE radio access network (E-UTRAN) is radically simpler than its UMTS predecessor. The entire intelligence of the Radio Network Controller (RNC) has been absorbed into the eNodeB, creating a flat, single-node RAN architecture. This design decision was crucial — it reduces latency by eliminating a hop, but it means every eNodeB must handle:

• Radio Resource Management (RRM): Scheduling, admission control, load balancing, and interference coordination across all cells managed by the eNodeB.
• RRC Connection Management: Establishing, maintaining, and releasing radio connections with UEs, including security and measurement configuration.
• Mobility Management: Intra-LTE handover decisions based on measurement reports, with X2 interface enabling direct eNodeB-to-eNodeB handover preparation.
• Header Compression: ROHC (Robust Header Compression) at the PDCP layer to reduce IP header overhead, especially critical for VoLTE small packets.
• Encryption & Integrity: All user plane data is encrypted and control plane signaling is both encrypted and integrity protected at PDCP.

1.3 EPC Network Elements

MME — Mobility Management Entity

The MME is the control plane brain of the EPC. It handles NAS signaling, authentication, bearer management, and paging. In EN-DC deployments, the MME must support SgNB Addition Request messages and understand NR capabilities reported by the UE.

S-GW — Serving Gateway

The Serving Gateway is the user plane anchor within the operator's network. During handover, the S-GW provides the local mobility anchor point so that the P-GW does not need to be updated for intra-operator handovers. In Option 3x, the S-GW connects directly to the SgNB for split bearer user plane.

P-GW — PDN Gateway

The PDN Gateway is the exit point to external networks. It allocates IP addresses, enforces policy rules from the PCRF, and performs traffic detection/charging. The P-GW function maps to SMF+UPF in the 5G Core.

HSS — Home Subscriber Server

The HSS contains all subscriber data — profiles, authentication vectors (KASME generation), and service subscriptions. In 5G, the HSS evolves into UDM (Unified Data Management) with AUSF (Authentication Server Function) handling the enhanced 5G-AKA authentication.

1.4 Key LTE Interfaces

1.5 The Flat Architecture Advantage

The elimination of the RNC (Radio Network Controller) from the LTE architecture was a deliberate design choice with three major benefits:

2.1 User Plane Protocol Stack

The LTE user plane carries application data from the UE to the P-GW. Each layer adds specific functionality:

2.2 Control Plane Protocol Stack

The LTE control plane carries signaling messages for connection management, mobility, and security. Two distinct signaling protocols operate in the control plane:

• RRC (Radio Resource Connection): Between UE and eNodeB. Handles measurement configuration, handover commands, security mode, radio bearer setup, and SIB broadcasting.
• NAS (Non-Access Stratum): Between UE and MME (transparent to eNodeB). Handles attach, authentication (EPS-AKA), bearer management, and tracking area updates.

2.3 Protocol Layer Deep Dive

PDCP — Packet Data Convergence Protocol

PDCP is the highest radio protocol layer and provides header compression (ROHC), ciphering (AES/SNOW3G/ZUC), and integrity protection (control plane only in LTE). In EN-DC, PDCP is the critical split point: for SCG Split Bearers, PDCP resides in the MeNB and data is split between the eNB's RLC and the gNB's RLC.

RLC — Radio Link Control

RLC operates in three modes: Transparent Mode (TM) for broadcast, Unacknowledged Mode (UM) for latency-sensitive traffic, and Acknowledged Mode (AM) for reliable transfer with ARQ retransmissions. The RLC layer handles segmentation of PDCP PDUs into transport blocks sized by the MAC scheduler.

MAC — Medium Access Control

MAC is responsible for scheduling (both uplink and downlink), HARQ (Hybrid ARQ with soft combining), random access (RACH), and multiplexing logical channels into transport channels. The MAC scheduler runs every TTI (1 ms in LTE, down to 0.125 ms with NR's shorter slots).

3.1 EPS Bearer Architecture

In LTE, all traffic flows through EPS Bearers — logical tunnels that stretch end-to-end from the UE to the P-GW. Each bearer has a specific QoS profile (QCI + ARP) that determines how traffic is treated at every node along the path.

Two types of bearers exist:

• Default Bearer: Established during attach. Always-on, provides basic connectivity. Uses a non-GBR QCI (typically QCI 9 for internet, QCI 5 for IMS signaling).
• Dedicated Bearer: Created on demand for specific traffic flows requiring different QoS. Can be GBR (guaranteed bit rate) or non-GBR. VoLTE uses a dedicated bearer with QCI 1.

3.2 QCI — QoS Class Identifier

Every EPS bearer is assigned a QCI value that maps to a standardized set of QoS characteristics. QCI is an integer (1-9 standard, extended up to 79+) that the network uses to determine packet scheduling priority, delay budget, and error rate tolerance.

3.3 Bearer to QoS Flow Transformation

The fundamental QoS model changes between LTE and 5G:

4.1 Carrier Aggregation

Carrier Aggregation (CA) was introduced in Rel-10 as the primary mechanism to increase LTE peak throughput beyond what a single 20 MHz carrier could deliver. CA allows aggregating up to 5 Component Carriers (CCs), each up to 20 MHz, for a theoretical maximum of 100 MHz bandwidth.

4.2 LTE Dual Connectivity (Rel-12)

Dual Connectivity (DC) was introduced in Rel-12 as a mechanism for a UE to simultaneously connect to two eNodeBs operating on different frequencies. This is the direct precursor to EN-DC:

4.3 Enhanced MIMO

LTE-Advanced progressively enhanced MIMO capabilities from 2x2 (Rel-8) to 4x4 (Rel-10) to 8x8 (Rel-13 FD-MIMO). Each step required new codebook designs, reference signal patterns, and UE capability categories:

4.4 Heterogeneous Networks (HetNets)

HetNets deploy small cells (pico, micro, femto) within the macro cell coverage area to boost capacity in hotspots. The interference management techniques developed for HetNets — eICIC, FeICIC, and CoMP — are directly relevant to EN-DC deployments where NR small cells operate under LTE macro coverage.

5.1 The SBA Paradigm Shift

The 5G Core abandons the point-to-point reference interface model of EPC in favor of a Service-Based Architecture. Instead of fixed interfaces between fixed nodes (S1, S11, S6a), every Network Function (NF) exposes its services via APIs on a common service bus. Any NF can discover and consume services from any other NF via the NRF.

5.2 Key Network Functions

5.3 Control/User Plane Separation (CUPS)

A key 5G Core design principle is CUPS — the complete separation of control and user plane. The SMF (control) manages the UPF (user plane) via the N4 interface using the PFCP (Packet Forwarding Control Protocol). This enables:

• Independent scaling: Deploy more UPFs at the edge without adding SMFs, or scale SMF capacity without touching the data path.
• Flexible placement: UPFs can be placed at the network edge (near cell sites) for low latency, while SMF stays centralized.
• Multi-access: A single SMF can manage UPFs serving different access types (3GPP NR, Wi-Fi via N3IWF, satellite).

6.1 NR Numerology — Flexible Subcarrier Spacing

Unlike LTE's fixed 15 kHz subcarrier spacing, NR supports multiple numerologies defined by the parameter μ (mu). Each numerology doubles the subcarrier spacing, halves the symbol duration, and suits different frequency ranges and use cases.

The remaining content of Chapters 6-20 continues with the same depth and quality — each with expert-level SVG diagrams, tables, insight boxes, and practical examples.

7.1 The Paradigm Shift: Bearer-Based to Flow-Based QoS

In LTE, QoS is enforced at the EPS bearer level. Each bearer carries a single QCI (QoS Class Identifier), and all traffic mapped to that bearer receives the same treatment. Creating a new QoS level requires establishing a new dedicated bearer — a heavyweight signaling operation involving the UE, eNB, MME, S-GW, and P-GW.

5G replaces this with a flow-based QoS model. A single PDU session can carry multiple QoS flows, each identified by a QFI (QoS Flow Identifier). Adding a new QoS level simply means creating a new QoS flow within the existing PDU session — no new GTP tunnel is needed.

7.2 5QI — The 5G QoS Identifier

The 5QI (5G QoS Identifier) is the 5G equivalent of LTE’s QCI. It defines standardized QoS characteristics including resource type, priority, packet delay budget, and packet error rate. 3GPP TS 23.501 Table 5.7.4-1 defines the standardized 5QI values.

7.3 QoS Flow Architecture

The QoS flow is the finest granularity of QoS differentiation in 5G. Each QoS flow within a PDU session is identified by a QFI (6-bit, values 0–63). The QFI is carried in the GTP-U extension header on the N3 interface (gNB ↔ UPF) and in SDAP headers on the air interface (UE ↔ gNB).

7.4 QoS Rules and QoS Profiles

The 5G QoS framework uses two complementary structures to define and enforce QoS:

7.5 Reflective QoS

Reflective QoS (RQoS) is a 5G innovation that eliminates the need for explicit downlink-triggered QoS rule installation in the UE for certain flows. Here is how it works:

• Step 1: The UPF marks a downlink packet with the RQI (Reflective QoS Indication) bit in the GTP-U extension header, along with the QFI.
• Step 2: The gNB passes this RQI indication to the UE in the SDAP header.
• Step 3: The UE creates a derived QoS rule by mirroring the downlink packet filter (swapping source/dest IP/port) and mapping uplink packets with the mirrored filter to the same QFI.
• Step 4: The UE starts a Reflective QoS timer. When the timer expires, the derived rule is deleted unless refreshed by another RQI-marked downlink packet.

7.6 PDU Session Types

Unlike LTE, which only supports IP-based PDN connections (IPv4, IPv6, or IPv4v6), 5G introduces four PDU session types:

7.7 LTE QCI vs 5G 5QI — Migration Mapping

For operators migrating from LTE to 5G, the 5QI framework provides backward compatibility. Standardized 5QI values 1–9 are intentionally aligned with QCI 1–9, ensuring that existing service definitions can be preserved during NSA/EN-DC deployments where both LTE and NR QoS must interwork.

8.1 Why Network Slicing?

A single 5G network must simultaneously serve vastly different requirements: a consumer watching 4K video needs high throughput; a remote surgery robot needs sub-millisecond latency; a smart meter needs to transmit 100 bytes once per hour with 10-year battery life. In LTE, all these users share the same network with QoS differentiation only at the bearer level. Network slicing takes this further by creating multiple logical end-to-end networks — called network slice instances — on top of a shared physical infrastructure.

Each slice is an isolated, self-contained logical network tailored for a specific service category. Slices can have their own dedicated NF instances, resource allocations, and even different network architectures (e.g., one slice could use a centralized UPF while another uses edge UPFs).

8.2 S-NSSAI Structure

Each network slice is identified by an S-NSSAI (Single Network Slice Selection Assistance Information), which consists of two components:

• SST (Slice/Service Type) — A mandatory 8-bit field (values 0–255) that identifies the expected behavior of the slice in terms of features and services.
• SD (Slice Differentiator) — An optional 24-bit field that complements the SST to differentiate among multiple slices of the same type. For example, two eMBB slices serving different enterprise tenants can share SST=1 but have different SD values.

8.3 Standard SST Values

3GPP TS 23.501 defines four standardized SST values. Values 0–127 are reserved for standardized use; 128–255 are available for operator-specific slice types.

8.4 End-to-End Slice Architecture

A network slice spans the entire path from the UE to the Data Network, consisting of three sub-slices that must be orchestrated together:

• RAN Slice: Radio resource partitioning at the gNB — dedicated PRBs, scheduling priority, BWP (Bandwidth Part) isolation, or shared scheduling with prioritization.
• Transport Slice: Backhaul/midhaul network segmentation using VLANs, MPLS LSPs, or segment routing (SR-MPLS / SRv6) to provide isolated transport paths with guaranteed bandwidth and latency.
• Core Slice: Dedicated or shared NF instances (AMF, SMF, UPF, PCF) with allocated compute, memory, and storage resources per slice. The UPF placement can vary per slice (central vs edge).

8.5 Slice Isolation Levels

Not all slices require the same degree of isolation. 3GPP and industry practice define multiple isolation levels, from soft (logical) to hard (physical), each with different cost and performance trade-offs:

8.6 NSSF — Slice Selection Function

The NSSF (Network Slice Selection Function) is the 5G Core NF responsible for determining the correct set of Network Slice Instances for a UE. It is consulted by the AMF during UE registration when the AMF cannot determine the target AMF set or the allowed NSSAI on its own.

8.7 Practical Example: Operator Deploying Three Slices

9.1 Why NSA Uses the EPC (Not 5GC)

The Non-Standalone (NSA) architecture was defined by 3GPP as a migration bridge — enabling operators to deploy 5G NR radio without replacing their entire core network. The fundamental design decision: keep the EPC as the core network and add the gNB as a secondary radio leg.

This choice was driven by three commercial realities:

• Time-to-market: Operators could launch “5G” service using existing EPC, MME, S-GW, and billing systems — no 5GC readiness required.
• Investment protection: Billions of dollars already invested in EPC infrastructure could continue generating returns while NR capacity was incrementally added.
• Device ecosystem: Early 5G chipsets (Qualcomm X50/X55) supported EN-DC before SA mode was fully validated.

In all three Option 3 variants, the control plane anchor remains the eNB (Master Node) connected to the MME via the existing S1-MME interface. The gNB (Secondary Node) has no direct control plane connection to the EPC. All NAS signaling — attach, authentication, bearer setup, paging — flows through the MeNB, exactly as in legacy LTE. What changes across the three variants is how user plane data reaches the S-GW.

9.2 Roles of MN and SN

In EN-DC, every UE connection has exactly one Master Node (MN) and optionally one Secondary Node (SN). The roles are asymmetric and strictly defined:

9.3 Option 3 — All User Plane Through MN

Option 3 is the simplest variant. The gNB provides additional radio capacity, but all user plane data flows through the eNB to reach the S-GW. The gNB sends its data to the eNB over the X2-U interface, and the eNB forwards it onward via S1-U.

In this architecture, only MCG bearers (Master Cell Group) and Split bearers with PDCP at the MN are possible. The SN cannot send data directly to the S-GW. This means the eNB’s S1-U interface and backhaul capacity must handle all traffic — both its own LTE data and the NR data relayed from the gNB.

9.4 Option 3a — SCG Bearer Direct to S-GW

Option 3a solves the backhaul bottleneck by giving the gNB its own direct S1-U connection to the S-GW. In this variant, SCG bearers (Secondary Cell Group) are established where data flows directly from the UE through the gNB to the S-GW, bypassing the eNB user plane entirely for those bearers.

The key difference from Option 3: the gNB terminates PDCP for SCG bearers. Each bearer is handled entirely by either the MN (MCG bearer over LTE) or the SN (SCG bearer over NR) — there is no splitting of a single bearer across both nodes.

9.5 Option 3x — Split Bearer (Most Common Deployment)

Option 3x combines the best of both variants. It introduces the split bearer concept: a single bearer where PDCP is anchored at the MN (eNB), but the PDCP PDUs are split across two RLC entities — one at the MN (over LTE) and one at the SN (over NR). The SN has a direct S1-U path to the S-GW, carrying its portion of the split bearer data.

This is critically important: the split happens at the PDCP layer. The MN’s PDCP decides how to distribute packets between the MCG leg (LTE) and the SCG leg (NR) based on buffer status, radio conditions, and scheduling. This is sometimes called flow control or PDCP duplication/splitting.

9.6 Why Option 3x Wins

Option 3x emerged as the overwhelmingly preferred deployment for several reinforcing reasons:

9.7 Comparison of All Three Variants

9.8 Protocol Stack Detail — Option 3x Split Bearer

Understanding the exact protocol stack is essential for troubleshooting. In an Option 3x split bearer:

The downlink flow for a split bearer works as follows:

• S-GW → MN: DL data arrives at the MN via S1-U GTP-U tunnel. The MN’s PDCP layer receives the IP packets.
• PDCP split decision: Based on buffer status reports from both MCG and SCG legs, the PDCP entity decides how to distribute packets. If the NR link has higher capacity, more packets go to the SCG leg.
• MCG leg: Packets assigned to MCG are processed through the MN’s own RLC → MAC → PHY and transmitted over LTE Uu.
• SCG leg: Packets assigned to SCG are sent as PDCP PDUs to the SN over X2-U. The SN’s RLC → MAC → PHY transmits them over NR-Uu.
• UE reassembly: The UE’s PDCP layer reorders packets from both legs using PDCP sequence numbers, delivering them in-order to the IP layer.

9.9 X2 Interface in EN-DC

The X2 interface between MN and SN is the backbone of EN-DC coordination. In NSA, it carries two distinct functions:

9.10 EPC Requirements for NSA

While the EPC is “reused” in NSA, it requires specific upgrades:

• MME: Must support the E-RAB Modification Indication procedure for SgNB bearer setup. Must understand NR UE capabilities in the UE Capability Information message. Must support secondary RAT data usage reporting.
• S-GW: Must support multiple GTP-U tunnel endpoints per bearer (for Options 3a/3x, where both MN and SN have S1-U paths). Must support indirect data forwarding for SgNB change.
• HSS: No changes required — NSA uses the same subscription data and authentication as LTE.
• PCRF/P-GW: No functional changes, but QoS policies may need updating to account for higher aggregate throughput. APN-AMBR values should be increased to not cap EN-DC speeds.

10.1 Measurement Configuration — Detecting NR Cells

Before EN-DC can be established, the UE must detect and measure NR cells. The MN (eNB) configures the UE with inter-RAT measurements specifically for NR detection. The critical measurement event is Event B1:

When Event B1 triggers, the UE sends a MeasurementReport to the MN containing the NR cell’s PCI, SS-RSRP, and SS-RSRQ. The MN then decides whether to initiate the SgNB Addition procedure based on the reported measurements and its own admission control policies.

10.2 SgNB Addition Procedure

The SgNB Addition is the most important EN-DC procedure — it establishes dual connectivity for a UE. The procedure involves signaling between three entities: the MN (eNB), the SN (gNB), and the UE. The MME is also involved for bearer path updates.

10.3 SgNB Addition — Step-by-Step Detail

10.4 SgNB Modification Procedure

After EN-DC is established, the SgNB Modification procedure handles ongoing changes. It can be initiated by either the MN or the SN:

The signaling flow mirrors the Addition procedure: the initiator sends a SgNB Modification Request (or SgNB Modification Required if SN-initiated), the peer responds with an acknowledgment, the MN sends RRC Reconfiguration to the UE, and the MN confirms completion to the SN. An EPC path update follows if transport addresses change.

10.5 SgNB Release Procedure

EN-DC can be released by either the MN or the SN. The two flows differ in their initiation but converge on the same outcome: the UE releases NR resources and returns to LTE-only operation.

10.6 Bearer Setup During SgNB Addition

During the SgNB Addition, the MN specifies which E-RABs should be set up at the SN and what bearer type to use. In an Option 3x deployment, the typical configuration is:

10.7 Timer Values and Failure Handling

Several timers govern EN-DC procedure execution. Understanding these is essential for troubleshooting addition failures:

10.8 SCG Failure Handling

A unique aspect of EN-DC is that SCG (NR) failures are non-fatal to the connection. Unlike MCG radio link failure (which triggers RRC re-establishment), SCG failures are reported to the MN, which decides the recovery action:

The SCGFailureInformation message includes a failureType IE with values such as:

• t310-Expiry — SCG radio link problem, physical layer out-of-sync detected.
• randomAccessProblem — RACH failure to SN during addition or beam recovery.
• rlc-MaxNumRetx — RLC reached maximum retransmission threshold on SCG.
• synchReconfigFailureSCG — UE failed to complete SCG reconfiguration requiring synchronization.
• scg-reconfigFailure — UE rejected the SCG configuration (invalid parameters).
• srb3-IntegrityFailure — Integrity check failure on SRB3 (if configured).

10.9 SgNB Addition Success Rate — KPI Framework

Operators track EN-DC performance using these key KPIs:

11.1 Why Bearer Architecture Matters

In a single-connectivity LTE network, the data path is straightforward: every IP packet travels through a single protocol stack at the eNodeB. In EN-DC, the UE is simultaneously connected to two nodes — the MN (Master Node, MeNB) and the SN (Secondary Node, SgNB). This creates a fundamental architectural question: where should each protocol layer terminate?

The answer to this question defines the bearer type. 3GPP TS 37.340 specifies three distinct bearer types for EN-DC, each with different protocol stack splits, data routing paths, and operational characteristics. The choice of bearer type directly impacts throughput aggregation, latency, handover behavior, and network complexity.

11.2 The Three Bearer Types

Each bearer type places the full protocol stack — PDCP, RLC, MAC, and PHY — at different nodes. Understanding the exact layer placement is essential for troubleshooting throughput issues, configuring QoS, and planning capacity.

MCG Bearer (Master Cell Group Bearer)

The MCG Bearer routes all user plane data exclusively through the Master Node (MeNB). The complete protocol stack — PDCP, RLC, MAC, and PHY — resides at the MeNB. The SgNB is not involved in this bearer's data path at all. This is functionally identical to a standard LTE bearer.

MCG Bearers are used for traffic that must remain anchored at the LTE layer:

• VoLTE bearers: Voice traffic requires the tight QoS guarantees and proven handover performance of LTE. Moving VoLTE to the NR leg adds complexity without clear benefit in NSA deployments.
• IMS signaling: SIP signaling for IMS registration, call setup, and supplementary services remains on the LTE anchor for reliability.
• Low-bandwidth IoT traffic: Devices generating minimal data do not benefit from NR aggregation and should stay on the established LTE path.

SCG Bearer (Secondary Cell Group Bearer)

The SCG Bearer routes all user plane data exclusively through the Secondary Node (SgNB). The complete stack — PDCP, RLC, MAC, and PHY — resides at the SgNB. Note that even though PDCP is at the SgNB, it uses NR PDCP (as per TS 38.323), not LTE PDCP. This is a critical detail — NR PDCP is mandatory for all EN-DC bearer types.

SCG Bearers provide the highest possible NR throughput because there is no X2-U bottleneck and no PDCP-level packet splitting overhead. They are ideal for:

• Best-effort high-bandwidth traffic: Video streaming, large file downloads, and app updates that benefit from maximum NR throughput without needing LTE aggregation.
• Deployments with limited X2 backhaul: When X2 transport capacity is constrained, avoiding the split bearer's X2-U traffic reduces backhaul load.
• Standalone NR capacity offload: When the goal is purely to offload data from LTE to NR without aggregation.

Split Bearer

The Split Bearer is the most complex and most powerful bearer type. PDCP is anchored at the MN (MeNB), while RLC/MAC/PHY layers exist at both the MN and the SN. The MN's PDCP entity splits downlink packets across the two legs — some go through the MN's own RLC (LTE air interface) and others are forwarded via X2-U to the SN's RLC (NR air interface).

This is the bearer type that delivers true throughput aggregation: the UE receives data simultaneously over LTE and NR, and the UE's PDCP reassembles packets in order before delivering them to higher layers.

11.3 Bearer Type Comparison

11.4 NR PDCP — The Mandatory Upgrade

A critical and often misunderstood aspect of EN-DC is that NR PDCP (TS 38.323) is used for all bearer types, even MCG Bearers carried entirely on the LTE air interface. The LTE PDCP (TS 36.323) is not used in EN-DC. This requires a software upgrade on the eNodeB (MeNB) to support the NR PDCP entity.

The key differences between NR PDCP and LTE PDCP that matter for EN-DC:

• 18-bit Sequence Number: NR PDCP supports 12-bit or 18-bit PDCP SN, compared to LTE PDCP's 12-bit maximum. The 18-bit SN (262,144 values) is essential for high-throughput bearers — at 1 Gbps with 1500-byte packets, a 12-bit SN wraps in ~50 ms, which is too fast for reliable reordering.
• Out-of-order delivery to RLC: NR PDCP can submit packets to the RLC layer out of order, relying on the reordering timer (t-Reordering) to reassemble. This is critical for split bearers where packets arrive from two legs with different latencies.
• PDCP duplication: NR PDCP supports duplicating each packet to both legs for ultra-reliable bearers (URLLC). While rarely used in EN-DC, the mechanism is available.
• Ethernet header compression: NR PDCP adds EHC support alongside ROHC, enabling efficient transport of Ethernet frames for industrial use cases.

11.5 Split Bearer in Detail

The split bearer mechanism deserves a deeper examination because it is the most operationally complex and the most commonly deployed bearer type for EN-DC data services. Understanding how PDCP distributes, forwards, and reorders packets is essential for troubleshooting throughput and latency issues.

PDCP Packet Distribution Algorithm

The MN's PDCP does not simply round-robin packets across the two legs. The distribution algorithm considers:

The X2 Backhaul Challenge

Split Bearers create a direct dependency on X2 transport capacity. In the downlink, every packet sent to the NR leg must traverse the X2-U interface between MeNB and SgNB. If the NR cell is delivering 800 Mbps, the X2-U link must sustain 800 Mbps of GTP-U encapsulated traffic in addition to any X2-C signaling and data forwarding for mobility.

11.6 Option 3, 3a, and 3x — The Bearer Variants

The three Option 3 variants defined in TS 37.340 differ in how the user plane is routed for split bearers. The bearer type concept applies to all variants, but the S1-U tunnel endpoint changes:

11.7 Practical Bearer Configuration

In live networks, operators typically configure a mix of bearer types per UE session:

12.1 Mobility in Dual Connectivity — The Challenge

Mobility in EN-DC is fundamentally more complex than single-connectivity LTE handover. The UE is connected to two nodes simultaneously, and either or both may need to change as the UE moves. The MeNB retains overall control of mobility decisions because it hosts the RRC connection, but the SgNB influences NR-side mobility through its own measurements and reporting.

The four mobility scenarios, in order of increasing complexity, are:

• Intra-SgNB mobility (PSCell change): The UE changes its Primary SCG Cell (PSCell) within the same SgNB. The MeNB and SgNB remain the same.
• Inter-SgNB change (SN Change): The UE moves from one SgNB to a different SgNB while the MeNB stays the same.
• MN Handover with SN change: The UE hands over to a new MeNB and simultaneously changes to a new SgNB (or releases the SN connection).
• MN Handover without SN change: The UE hands over to a new MeNB while retaining the same SgNB (requires the new MeNB to have X2 connectivity to the existing SgNB).

12.2 Measurement Events for EN-DC Mobility

EN-DC introduces new measurement events alongside the existing LTE A-series events. The most critical events for EN-DC mobility are:

12.3 Intra-SgNB Mobility (PSCell Change)

This is the simplest EN-DC mobility scenario. The UE changes its PSCell (Primary SCG Cell) within the same SgNB — analogous to an intra-eNB handover in LTE. This occurs when the UE moves within the coverage of the same gNB-DU but a different NR cell offers better signal quality.

The PSCell change is handled entirely by the SgNB. The SgNB reconfigures the UE's SCG via an RRCReconfiguration message relayed through the MeNB. No data forwarding is needed because the PDCP entity at the MN (for split bearers) or SN (for SCG bearers) is not disrupted — only the lower layers (RLC, MAC, PHY) are reconfigured.

Key characteristics of PSCell change:

• Interruption time: Minimal (typically <20 ms) — only the NR leg is briefly interrupted; the LTE leg continues unaffected.
• Data impact: For split bearers, PDCP automatically routes all traffic through the LTE leg during the NR interruption. The UE experiences a temporary throughput reduction but no connection loss.
• Signaling: SgNB sends SgNB Modification Required to MeNB, which forwards the SCG reconfiguration to the UE via RRCConnectionReconfiguration.

12.4 Inter-SgNB Change (SN Change)

When the UE moves out of coverage of the current SgNB but the MeNB coverage remains strong, an SN Change (inter-SgNB handover) is performed. The MeNB releases the connection to SgNB1 and adds SgNB2. This is the most common EN-DC mobility event in real networks.

Data Forwarding During SN Change

A critical aspect of SN Change is data forwarding. When the MeNB decides to change from SgNB1 to SgNB2, packets may still be buffered at SgNB1's RLC or in transit. These packets must be forwarded to SgNB2 to avoid data loss:

• For SCG Bearers: SgNB1 forwards buffered PDCP SDUs to SgNB2 via X2-U. SgNB2's PDCP can then retransmit any unacknowledged packets.
• For Split Bearers: The MN's PDCP handles retransmission since it is the PDCP anchor. SgNB1 only needs to forward any RLC SDUs that were in its buffer. The MN's PDCP will retransmit unacknowledged packets to SgNB2's RLC.
• Forwarding tunnel: A temporary GTP-U tunnel is established between SgNB1 and SgNB2 for data forwarding. This tunnel is torn down after the SN Change completes.

12.5 MN Handover with SN

When the UE moves to a new MeNB coverage area, the entire EN-DC context must be transferred. This is the most complex mobility scenario. Two sub-cases exist:

12.6 Mobility Scenario Comparison

12.7 MN Handover Without SN Change

This optimized scenario occurs when the target MeNB (MeNB2) has X2 connectivity to the same SgNB that the UE is currently using. Instead of releasing and re-adding the SgNB, the MeNB2 simply takes over the X2-C and X2-U connections to the existing SgNB.

The benefits are significant:

• No NR Random Access: The UE maintains its NR connection to the SgNB, so no RACH procedure is needed on the NR side. Only LTE RACH on the target MeNB2 is required.
• Minimal NR interruption: The NR leg is briefly paused during MeNB handover while X2 connections are transferred, but no full re-establishment is needed.
• No SgNB data forwarding: Since the SgNB does not change, there is no need to forward buffered data between SgNBs.
• Faster completion: Eliminating SgNB addition/release steps reduces the overall handover time by 30–50%.

12.8 Mobility Timers and Parameters

Several timers govern EN-DC mobility behavior. Incorrect timer settings are a leading cause of handover failures:

13.1 The EN-DC Troubleshooting Mindset

EN-DC troubleshooting is inherently more complex than single-connectivity LTE debugging because every issue has two possible failure domains: the LTE leg and the NR leg. A throughput problem might be caused by poor NR channel conditions, X2 backhaul congestion, PDCP split algorithm misconfiguration, or even an LTE-side scheduling issue affecting the anchor bearer.

The systematic approach follows three phases:

13.2 EN-DC Call Flow Timeline

Understanding the normal EN-DC setup timeline is essential for identifying where failures occur. Each phase has specific timers and expected durations:

13.3 Common Failure Points

EN-DC failures can occur at multiple points in the architecture. The following diagram highlights the most frequent failure locations:

13.4 EN-DC Key Performance Indicators

Effective EN-DC monitoring requires tracking a specific set of KPIs beyond standard LTE counters:

13.5 Failure Causes and Solutions

13.6 Log Analysis Techniques

EN-DC troubleshooting relies on correlated analysis of multiple log sources. No single log type provides the complete picture:

X2AP Signaling Traces

X2AP traces are the primary tool for diagnosing SgNB Addition, Modification, and Release issues. Key fields to examine:

• Cause code in SgNB Addition Failure: The cause IE reveals why the SgNB rejected the request. Common values: radioNetwork: no-radio-resources-available, radioNetwork: not-supported-QCI-value, misc: unspecified.
• SCG-ConfigInfo: Carried in the SgNB Addition Request, this contains the UE's NR measurements and capabilities. Verify the reported NR RSRP matches expectations.
• SgNB-to-MeNB Container: In the SgNB Addition Request Acknowledge, this carries the SCG-Config for the UE. Decoding this ASN.1 structure reveals the exact NR configuration the SgNB is providing.

UE-Side Logs (Drive Test / Diagnostic Mode)

UE-side logs provide the ground truth for what the UE experiences:

• B1 measurement reports: Verify that the UE is detecting NR cells and reporting them to the MeNB. If no B1 reports appear, check the measurement configuration sent in RRCConnectionReconfiguration.
• RRC Reconfiguration messages: Decode the MCG and SCG reconfiguration to verify band combinations, BWP configs, and PDCP configurations are valid for the UE.
• T304 expiry: If the UE log shows T304 expiry, it means the NR Random Access failed within the guard timer period. The UE reports SCGFailureInformationNR to the MeNB with cause t304-Expiry.
• NR PHY layer logs: Check SS-RSRP, SS-RSRQ, SS-SINR at the point of failure. Poor NR signal quality is the single most common root cause of EN-DC failures.

Network-Side OSS/PM Counters

Aggregate PM counters provide the statistical view needed to identify systemic issues:

• SgNB Addition attempt/success/failure counters: Track per-cell to identify specific NR cells with high rejection rates.
• SCG Failure counters by cause: Distinguish between t304-Expiry (RACH failure), randomAccessProblem, rlc-MaxNumRetx (RLC failure), and srb3-IntegrityFailure (security issue).
• X2-U throughput counters: Compare X2-U throughput against link capacity to detect backhaul bottlenecks.

13.7 Parameter Tuning Recommendations

13.8 Systematic Troubleshooting Workflow

When an EN-DC performance issue is reported, follow this structured workflow:

13.9 Advanced: PDCP Split Optimization

For networks using split bearers (the majority of EN-DC deployments), the PDCP split algorithm directly determines throughput performance. Two areas deserve special attention:

t-Reordering Timer Tuning

The t-Reordering timer at the UE PDCP controls how long the UE waits for out-of-order packets before delivering them to upper layers. The optimal value depends on the difference in latency between the LTE and NR legs:

• Co-located MeNB/SgNB (X2 RTT <1 ms): t-Reordering of 50–80 ms is usually sufficient. The legs have similar latency.
• Non-co-located (X2 RTT 5–15 ms): t-Reordering of 100–150 ms is needed to accommodate the X2 delay difference.
• High-speed mobility (UE >60 km/h): t-Reordering may need to increase to 150–200 ms due to scheduling jitter caused by frequent channel quality changes on both legs.

Uplink Split Configuration

By default, most operators configure uplink data to go exclusively through the MeNB (MN leg) to avoid the complexity of UL split. However, enabling UL split can improve upload speeds significantly:

14.1 Why Migration Matters

Every major mobile generation has faced the same challenge: how to transition from the old network to the new one without disrupting service for hundreds of millions of subscribers. The LTE-to-5G migration is arguably the most complex yet, because 5G introduces not just a new radio (NR) but an entirely new core network architecture (5GC) built on service-based principles. Operators must decide when to deploy each component, how to maintain interworking during the transition, and what to sunset — all while protecting revenue and subscriber experience.

3GPP anticipated this complexity by defining multiple deployment options — numbered architectures that specify which radio technologies connect to which core networks. The most critical distinction is between Non-Standalone (NSA), where NR relies on LTE and EPC for control-plane anchoring, and Standalone (SA), where NR connects directly to the 5G Core. The journey between these two endpoints defines the migration path.

14.2 Migration Timeline

Real-world operator migrations typically follow four broad phases, each spanning 12–24 months depending on market conditions, spectrum availability, and investment appetite. The following timeline captures the canonical progression:

14.3 Architecture Options

3GPP defined a family of deployment options in TR 21.917, each specifying the combination of radio access (LTE, NR) and core network (EPC, 5GC). Understanding these options is fundamental to planning migration, because each represents a distinct step on the path from pure LTE to pure 5G SA.

14.4 Migration Phase Detail

14.5 CUPS as a Migration Stepping Stone

Before deploying a full 5GC, many operators implement CUPS (Control and User Plane Separation) within their existing EPC. Standardized in 3GPP Release 14 (TS 23.214), CUPS separates the SGW and PGW into control-plane functions (SGW-C, PGW-C) and user-plane functions (SGW-U, PGW-U). This is a critical migration enabler because:

• User-plane flexibility: UPFs can be deployed at the edge while control remains centralized — mirroring 5GC UPF architecture
• Investment protection: The same user-plane hardware can later serve as 5GC UPFs with a software upgrade
• Traffic steering: Pfcp (Packet Forwarding Control Protocol) between CP and UP is architecturally similar to N4 in 5GC
• Gradual transition: Operators can evolve their EPC toward 5GC-like architecture without a disruptive cutover

14.6 N26 Interface for Interworking

The N26 interface connects the 5GC AMF to the EPC MME, enabling seamless subscriber context transfer during inter-system mobility. When a UE moves between 5GC coverage and EPC coverage, N26 transfers the mobility management context — including security keys, registration state, and PDU session information — so the subscriber experiences no service interruption.

Key N26 operations include:

14.7 Operator Migration Strategies

Global operators have adopted three broad migration philosophies, each reflecting different market conditions and investment strategies:

15.1 The Spectrum Challenge

Spectrum is the most constrained and expensive resource in mobile telecommunications. As operators deploy 5G NR alongside existing LTE networks, they face a fundamental dilemma: new NR spectrum (especially mid-band and mmWave) provides high capacity but limited coverage, while existing LTE spectrum offers excellent coverage but is already fully loaded with 4G traffic. The solution involves two complementary strategies: spectrum refarming (permanently reallocating LTE spectrum to NR) and Dynamic Spectrum Sharing (DSS) (allowing LTE and NR to share the same carrier simultaneously).

15.2 5G NR Frequency Landscape

15.3 Key NR Bands Globally

15.4 Dynamic Spectrum Sharing (DSS)

DSS allows LTE and NR to operate on the same carrier frequency simultaneously, dynamically allocating resources between the two technologies on a per-subframe (or per-slot) basis. This is a game-changer for operators who cannot immediately refarm spectrum away from LTE due to large 4G subscriber bases.

15.5 DSS Capacity Impact

While DSS provides immediate NR coverage on existing LTE spectrum without refarming, it comes with significant capacity trade-offs that operators must understand:

15.6 Refarming Strategy

Refarming involves permanently reallocating spectrum from LTE to NR. The decision of which bands to refarm first depends on traffic patterns, subscriber device mix, and coverage requirements:

15.7 Guard Band Considerations

When LTE and NR carriers are deployed on adjacent frequencies (whether through DSS or on neighboring bands), guard bands are essential to prevent inter-system interference:

• DSS (same carrier): No guard band needed — LTE and NR share the same carrier with coordinated scheduling
• Adjacent carriers, same band: Minimum guard band depends on SCS and filter design. For 15 kHz SCS: typically 100–300 kHz. For 30 kHz SCS: 300–600 kHz
• Adjacent bands: Follow 3GPP TS 38.101 co-existence requirements. Typical inter-band guard: 0–5 MHz depending on band edge filtering
• Supplemental Uplink (SUL): When NR uses SUL on an adjacent LTE band, careful guard band planning prevents uplink interference into the LTE carrier

16.1 Inter-RAT Mobility Overview

During the LTE-to-5G transition, UEs must move seamlessly between NR and LTE coverage — in both idle mode (cell selection/reselection) and connected mode (handover/redirection). This inter-RAT mobility is one of the most complex aspects of the migration, because it involves coordination between different radio technologies, potentially different core networks (EPC and 5GC), and different protocol stacks.

Three fundamental mechanisms enable inter-RAT mobility, each appropriate for different scenarios:

16.2 EPS Fallback for Voice

In early SA deployments where VoNR (Voice over NR) is not yet available, voice calls must fall back to LTE for VoLTE delivery. This procedure, known as EPS Fallback, is the most common inter-RAT mobility scenario in current 5G networks.

16.3 NR-to-LTE Handover Signaling

The connected-mode handover from NR to LTE involves coordination across the RAN and core network. The following diagram shows the detailed signaling flow:

16.4 Inter-RAT Mobility Scenarios

16.5 N26 Interface Role

The N26 interface is the linchpin of seamless inter-system mobility during the dual-core transition period. Without N26, inter-system mobility degrades to idle-mode reselection with the following consequences:

16.6 Fast Return to NR

After an EPS Fallback voice call ends, the UE should return to NR as quickly as possible to resume high-speed data services. Two Fast Return mechanisms are standardized:

17.1 The Coexistence Challenge

Running LTE and NR simultaneously — whether on the same carrier (DSS), adjacent carriers, or overlapping coverage areas — creates interference scenarios that did not exist in single-RAT deployments. LTE and NR have fundamentally different signal structures: LTE uses always-on Cell-specific Reference Signals (CRS) scattered across every subframe, while NR uses beam-based SS/PBCH Blocks (SSBs) and CSI-RS that are transmitted only when needed. This mismatch is the root cause of most coexistence challenges.

17.2 MBSFN Subframe Usage for DSS

The key enabler for DSS is the MBSFN (Multimedia Broadcast Single Frequency Network) subframe — an LTE subframe type where CRS is transmitted only in the first 1–2 OFDM symbols, leaving the remaining symbols CRS-free. By configuring subframes as MBSFN (even without actual broadcast content), the network creates "CRS-free" regions where NR PDSCH can be scheduled without CRS interference.

17.3 Cross-Carrier Scheduling

In DSS, cross-carrier scheduling allows the NR PDCCH (control channel) to be transmitted on a different carrier than the NR PDSCH (data channel). This is valuable because:

• Avoids NR PDCCH/LTE CRS collision: NR control can be placed on a dedicated NR carrier while data is scheduled on the shared DSS carrier
• Improves NR PDCCH reliability: The dedicated carrier has no CRS interference, ensuring robust control channel reception
• Enables flexible scheduling: The scheduler can dynamically decide which subframes on the DSS carrier get NR data allocation

When cross-carrier scheduling is not available, NR PDCCH must be placed in the MBSFN region of the DSS carrier, using CORESET (Control Resource Set) configurations that avoid LTE CRS positions. This is called rate-matching around CRS — NR maps its PDCCH and PDSCH around the known CRS RE positions, accepting some capacity loss.

17.4 Adjacent Channel Interference

When LTE and NR carriers are deployed on adjacent frequencies (not DSS, but neighboring channels), two interference mechanisms dominate:

The guard band required between adjacent LTE and NR carriers depends on several factors:

• Subcarrier spacing alignment: NR 15 kHz SCS aligns naturally with LTE 15 kHz, requiring minimal guard. NR 30 kHz SCS has different symbol timing, potentially requiring larger guard.
• Channel bandwidth: Wider channels have more edge PRBs affected by adjacent interference. The edge 2–4 PRBs typically see 1–3 dB SNR degradation.
• Power differential: If the NR carrier operates at significantly higher power than the adjacent LTE carrier, the leakage into LTE is proportionally worse.
• Duplex mode: TDD-FDD coexistence requires careful timing alignment to avoid cross-link interference (UL leaking into DL of the adjacent carrier).

17.5 Power Control Coordination

Coordinated power control between LTE and NR is essential for managing interference in coexistence scenarios. Three strategies are commonly deployed:

17.6 DSS Guard Band Requirements

Within a DSS carrier, there is no frequency-domain guard band — LTE and NR share the exact same channel. However, several "virtual" guard mechanisms are required:

17.7 TDD-FDD Coexistence

A particularly challenging scenario arises when TDD NR (e.g., n78 at 3.5 GHz) is deployed near FDD LTE bands. Because TDD alternates between uplink and downlink on the same frequency, timing alignment between neighboring TDD cells is critical — and cross-link interference with FDD systems requires careful management:

• CLI (Cross-Link Interference): During NR UL slot, the UE transmits. If an adjacent FDD LTE cell is receiving on a nearby frequency, the NR UE uplink can leak into the LTE receiver. This is managed by guard bands and by coordinating NR TDD frame structure with neighboring operators.
• TDD synchronization: All TDD NR cells in a geographic area should use the same frame structure (DL/UL slot pattern) to prevent one cell UL from interfering with another cell DL. Regulatory bodies in many countries mandate synchronized TDD patterns.
• Remote interference: In rare atmospheric ducting conditions, TDD signals can propagate hundreds of kilometers, causing interference to distant cells. This is mitigated by guard periods between DL and UL transitions and by remote interference management (RIM) features.

17.8 Interference Mitigation Summary

18.1 Why Standalone Matters

Non-Standalone (NSA) was always a stepping stone. It let operators launch 5G NR quickly by anchoring to the existing LTE core (EPC), but it inherits every limitation of 4G: no network slicing, no URLLC, no edge computing orchestration, and voice still falls back to VoLTE via the EPC. Standalone (SA) is the destination — a complete 5G system where the NR radio connects directly to the 5G Core (5GC), unlocking the full promise of the technology.

The transition from NSA to SA is not a simple software upgrade. It is a multi-domain transformation spanning the radio access network, core network, transport layer, device ecosystem, and service platform. Every domain must be ready simultaneously for SA to work end-to-end.

18.2 Core Migration: EPC to 5G Core

The 5G Core (5GC) is a fundamentally different architecture from the EPC. It replaces monolithic network elements with a Service-Based Architecture (SBA) where network functions communicate via HTTP/2 RESTful APIs over a common service bus. This decomposition enables cloud-native deployment, independent scaling, and rapid feature introduction.

18.3 gNB-CU/DU Split Architecture

SA deployment is the catalyst for disaggregated RAN. The gNB-CU/DU split defined in 3GPP TS 38.401 separates the gNB into a Centralized Unit (CU) and one or more Distributed Units (DU). The CU is further split into CU-CP (Control Plane) and CU-UP (User Plane), connected by the E1 interface. The DU connects to the CU via the F1 interface — F1-C for control, F1-U for user plane.

18.4 SA Deployment Prerequisites

18.5 Transport Network Requirements

The CU/DU split fundamentally changes transport network requirements. In a traditional monolithic gNB, all processing happens at the cell site and only backhaul is needed. With the split architecture, three distinct transport segments emerge:

18.6 VoNR Readiness & IMS Migration

Voice over NR (VoNR) is the SA equivalent of VoLTE. In NSA, voice traffic is handled by VoLTE on the LTE anchor. In SA, without an LTE anchor, voice must either be carried natively over the NR air interface via IMS (VoNR) or the device must fall back to LTE for voice calls (EPS Fallback).

VoNR requires the complete IMS stack to function over a 5GC PDU session. The key requirements are:

• IMS PDU Session: A dedicated PDU session with QoS Flow mapped to 5QI=1 (conversational voice, GBR, 100 ms PDB) for media and 5QI=5 (IMS signaling, non-GBR) for SIP.
• EVS Codec: Enhanced Voice Services codec is the preferred voice codec for VoNR, offering superior quality at lower bitrates compared to AMR-WB. Minimum configuration: EVS 13.2 kbps super-wideband.
• IMS Emergency Calls: Emergency registration and call routing via the 5GC must work even without a USIM (limited service). This requires AMF and IMS coordination per TS 23.167.
• SRVCC Replacement: LTE used SRVCC for handover from VoLTE to CS domain (2G/3G). In SA, if the operator still has 2G/3G, an equivalent mechanism is needed. Most operators targeting SA have already shut down 3G, making this less critical.
• EPS Fallback as Interim: Until VoNR is fully validated, EPS Fallback redirects the UE to LTE+EPC for voice calls. This adds 1–3 seconds of call setup delay but provides a reliable fallback path.

18.7 Site Planning Considerations for SA

SA deployment introduces site-level changes that RF planning teams must account for:

• SA-Only Coverage Gaps: In NSA, the LTE anchor provided a coverage safety net. In SA, if the NR cell has a coverage hole, the UE loses all service (no LTE fallback for data unless inter-RAT reselection is configured). SA coverage must be contiguous or supported by fast NR→LTE redirection.
• SSB Beam Configuration: SA requires SSB beams to be configured for initial access (cell search). The SSB beam pattern, periodicity (default 20 ms), and number of beams (up to 8 for FR1, 64 for FR2) directly impact cell coverage and acquisition time.
• Power Budget: SA cell selection uses RSRP from SSB. The SSB EPRE (Energy Per Resource Element) and beamforming gain determine the SA coverage footprint. This must match or exceed the LTE coverage layer to avoid coverage regression.
• PRACH Configuration: SA initial access requires PRACH resources for Msg1. The PRACH format, root sequence planning, and preamble allocation must be optimized for the expected cell radius and traffic load.
• Coexistence with NSA: During the transition, the same carrier may serve both NSA and SA UEs. Operators must balance SSB overhead, PDCCH resources, and scheduling between the two populations.

19.1 The KPI Framework for 5G Migration

Key Performance Indicators (KPIs) are the quantitative measures that define whether a network is meeting its design objectives. During migration, KPIs serve a dual purpose: they validate that the new 5G layer performs as expected, and they confirm that the existing LTE layer has not degraded due to the introduction of NR.

5G KPIs are organized into five fundamental categories, each reflecting a different dimension of the user experience:

19.2 EN-DC KPIs and Targets

EN-DC (E-UTRA–NR Dual Connectivity, Option 3x) introduces a unique set of KPIs that measure the effectiveness of the secondary NR leg. These KPIs are critical during the NSA phase and continue to be relevant as long as EN-DC is active in the network.

19.3 SA KPIs and Targets

19.4 Optimization Methodology

Network optimization is a continuous, iterative process. The methodology follows a closed-loop cycle where performance data drives analysis, analysis drives parameter changes, and verification confirms the impact before the cycle repeats.

19.5 Parameter Optimization Areas

The following table summarizes the key parameter domains that RF optimization engineers tune during and after migration:

19.6 Drive Test Analysis Methodology

Drive testing remains the gold standard for validating RF performance in the field. During migration, drive tests serve two critical functions: verifying 5G NR coverage and performance, and confirming that LTE has not degraded.

A systematic drive test campaign for 5G migration covers the following:

20.1 The 3GPP Release Cadence

3GPP operates on a roughly 18-month release cycle. Each release builds incrementally on the previous one, adding new features while maintaining backward compatibility. The 5G NR story began with Release 15 (the foundation) and continues to evolve through Release 19 and beyond.

20.2 Release 17 Features

Release 17, frozen in March 2022, is the bridge between initial 5G and 5G-Advanced. It extends NR into fundamentally new domains: satellite communication, reduced-capability IoT devices, and NR-based dual connectivity.

20.3 Release 18 Features — 5G-Advanced

Release 18, frozen in December 2024, is officially the first release branded as 5G-Advanced. It represents a maturation of 5G technology, with a strong focus on intelligence, efficiency, and new service types.

20.4 Release 19 Outlook

Release 19 (expected freeze: late 2025) continues the 5G-Advanced trajectory with emphasis on:

• FR3 Study (7–24 GHz): Exploration of the upper mid-band spectrum between FR1 (<7.125 GHz) and FR2 (>24.25 GHz). This "centimeter wave" range offers a balance of bandwidth (up to 400–800 MHz contiguous) and propagation characteristics better than mmWave. Target bands include 7–8 GHz and 10–15 GHz. This is a study item in Rel-19 with normative work expected in Rel-20.
• AI/ML Phase 2: Extends Rel-18 AI/ML work to mobility optimization (AI-based handover prediction), load balancing, and energy saving. Moves from UE-side inference to network-side AI with federated learning considerations.
• Ambient IoT (Normative): Moves from study item (Rel-18) to normative specification. Defines device classes, air interface, inventory/tracking use cases, and coexistence with legacy NR.
• Network Energy Saving Phase 2: Expanded sleep mode coordination, AI-driven traffic prediction for proactive energy management, and cross-cell energy optimization.
• Duplex Evolution (Normative): Moves SBFD from study to specification. Defines UE capabilities, interference management frameworks, and deployment scenarios.
• Enhanced Positioning: Sub-10 cm accuracy for industrial IoT using carrier phase positioning, sidelink-aided positioning, and AI/ML-enhanced methods.

20.5 Technology Roadmap — Paths to 6G

20.6 The Path to 6G

The ITU-R has established the framework for IMT-2030 (6G) through Recommendation ITU-R M.2160. While 6G standardization is expected to begin in 3GPP around Rel-21/22 (2028–2030), the vision is already taking shape: