5G gNB CU/DU/RU Split Architecture & Interfaces

1) Introduction

The 5G NR gNB split architecture divides the base station into functional entities — Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU) — to optimize deployment flexibility, scalability, and performance. This functional split enables centralized control and distributed radio processing, allowing operators to balance latency-sensitive tasks at the edge (DU/RU) with higher-layer functions centralized (CU). The split reduces fronthaul bandwidth demands, supports multi-vendor interoperability through standardized interfaces (F1, E1, NG, and O-RAN), and simplifies network upgrades via software-defined deployments. Overall, it delivers improved efficiency, cost optimization, and network agility essential for 5G use cases like URLLC, eMBB, and massive IoT.

2) Functional Split and Roles

gNB Central Unit – Control Plane (gNB-CU-CP)

• Functions: RRC, NGAP (N2), E1AP, overall UE context & mobility control, security control, policy/QoS control signaling.

• Interfaces: NG-C (N2) to AMF, E1-C to CU-UP, F1-C to DUs, Xn-C to neighbor gNBs (for Xn HO).

gNB Central Unit – User Plane (gNB-CU-UP)

• Functions: SDAP/PDCP-U, DL/UL user-plane anchor for PDU sessions, UL/DL data path switching during handovers, DL/UL data forwarding.

• Interfaces: E1-C (control) from CU-CP, F1-U to DUs, NG-U (N3) to UPF, optional Xn-U for data forwarding.

gNB Distributed Unit (gNB-DU)

• Functions: RLC, MAC, High-PHY (Option 7.2x split puts Lower-PHY/Radio in RU), scheduling (MAC), random access, HARQ.

• Interfaces: F1-C and F1-U to CU, Open Fronthaul (O-RAN C/U/M/S-plane) to RU.

gNB Radio Unit (gNB-RU)

• Functions: Lower-PHY (FFT/iFFT, precoding), RF, beamforming.

• Interfaces: Open Fronthaul to DU (often eCPRI, O-RAN 7.2x).

Core Network

• AMF (N2 control), SMF/UPF (N3 user plane), UDM/AUSF (authentication/identity), PCF (policy).

Synchronization

• PTP (IEEE-1588v2) and/or Sync-E to meet RU/DU timing budgets (especially for TDD).

Reference Point Summary & Protocol Stacks

NG Interface (gNB-CU-CP ↔ AMF)

• NG-C (N2): SCTP/IP → NGAP → carries NAS (Registration, PDU Session mgmt via SMF relay), UE context mgmt, paging.

• NG-U (N3): GTP-U/IP between CU-UP and UPF, carries user plane PDUs (SDAP/PDCP encapsulated).

Key NGAP procedures: Initial UE Message, Downlink/Ul Uplink NAS Transport, Initial Context Setup, UE Context Release, Handover Preparation/Resource Allocation, Paging.

E1 Interface (CU-CP ↔ CU-UP)

• E1-C: SCTP/IP → E1AP.

• Purpose: Create/modify/release UE bearer contexts in CU-UP, configure DRBs/QoS flows, TEIDs & UP TNL info, data forwarding during HO, PDCP duplication/DAPS control.

Key E1AP procedures: Bearer Context Setup/Modification/Release, UE Context Release, Path Switch, Data Forwarding Control.

F1 Interface (CU ↔ DU)

• F1-C: SCTP/IP → F1AP for DU setup, UE context mgmt, paging, RRC message transfer (DL/UL).

• F1-U: GTP-U/IP for user plane between CU-UP and DU.

Key F1AP procedures: F1 Setup, UE Context Setup/Modification/Release, DL/UL RRC Message Transfer, Paging, GNB-DU Resource Coordination, Cell Group Config.

Xn Interface (gNB↔gNB)

• Xn-C (SCTP/IP → XnAP) and optionally Xn-U (GTP-U) for Xn handovers, data forwarding, load info.

O-RAN Open Fronthaul (DU↔RU)

• C/U-Plane over eCPRI (7.2x split), M-Plane with NETCONF/YANG, S-Plane for sync/clocking.

3) Identifiers & Mapping Across Planes

In 5G NR, a variety of identifiers are used to uniquely track and manage UEs, sessions, and resources across the RAN and Core Network layers. These include RNTI (for radio-level scheduling), GUTI/5G-S-TMSI (for mobility and paging), RAN UE NGAP ID and AMF UE NGAP ID (for signaling association), and QFI/DRB IDs (for QoS flow and bearer mapping). Each identifier operates within a specific protocol domain, ensuring efficient context management, mobility handling, and secure signaling separation between control and user planes. Having distinct identifiers avoids ambiguity during procedures like handovers, paging, and context transfers, while also improving scalability and enabling seamless interworking across multi-vendor and multi-layer network components.

• RAN UE NGAP ID (assigned by CU-CP) ↔ AMF UE NGAP ID (by AMF) → bind N2 sessions.

• CU UE F1AP ID and DU UE F1AP ID → bind F1-C messages per UE at CU/DU boundary.

• TEIDs & UP TNL Info (N3 and F1-U) → provided via E1AP (CU-CP→CU-UP) & F1AP (CU→DU).

• RNTI (C-RNTI) in RAN MAC/PHY scope (per cell/DU).

• FiveG-S-TMSI / 5G-GUTI for paging and registration.

• QoS Flow IDs (QFI) within PDU Session; mapped to DRB IDs and SDAP/PDCP in CU-UP.

4) Interface Bring-Up

In a 5G NR network, the F1, NG, and E1 setup procedures are essential control-plane processes that establish logical interfaces between the functional units of the gNB and the 5G Core. The F1 setup connects the gNB Central Unit (CU) and Distributed Unit (DU), enabling coordination of radio resource control and user-plane data flow. The E1 setup links the CU-Control Plane (CU-CP) and CU-User Plane (CU-UP), allowing dynamic bearer management and control signaling exchange. The NG setup establishes connectivity between the gNB-CU and the AMF in the 5G Core, enabling registration, mobility, and session management. These interfaces are typically established during gNB initialization or when new network elements are integrated, ensuring inter-node compatibility, capability exchange, and a fully operational signaling path before serving UEs.

F1 Setup (CU↔DU)

• F1AP F1 SETUP REQUEST/RESPONSE:

  • DU advertises served cells, TAC/PLMN, capabilities;

  • CU acknowledges and aligns global RAN config.

  • Optional F1 Setup Failure path.

E1 Setup (CU-CP↔CU-UP)

• E1AP E1 SETUP REQUEST/RESPONSE:

  • Exchange node identities,

  • supported features (e.g., UL/DL data split, DAPS), transport profiles.

NG Setup (CU-CP↔AMF)

• NGAP NG SETUP REQUEST/RESPONSE:

  • PLMN and TAC support, RAN Node Name, Paging DRX support; establishes N2 association over SCTP.

Stacks and Interfaces

• gNB-CU-CP (Control Plane): terminates RRC with the UE and NGAP with the AMF; talks to DU over F1-C.

• gNB-CU-UP (User Plane): terminates GTP-U (N3) to UPF and F1-U to DU.

• gNB-DU: terminates PHY/MAC/RLC on the radio side and F1 (C/U) on the backhaul side.

 Think of F1 as a “transport” of RRC and bearer control between CU and DU:

• F1-C (control): UE context setup/mod, UL/DL RRC message transfer, paging, system info delivery, cell/BWP control, RACH reports, measurements, etc.

• F1-U (user): GTP-U tunnels for DRBs between CU-UP and DU.

5) Registration (UE Initial Access)

UE registration is the foundational procedure that transitions a UE from an unregistered, unknown state to a fully authenticated, reachable entity within the 5G system. It is triggered whenever the network needs to revalidate, relocate, or refresh the UE’s identity, location, and service profile—ensuring secure, seamless, and efficient connectivity across the 5G architecture

Over-the-air (DU ↔ UE), but RRC is terminated at CU

MIB → generated and broadcast by the DU (local PHY).

SIB1 & all other SIBs → content provided by CU, broadcast physically by the DU.

1. MIB- The MIB is not part of RRC or F1AP; it is handled at the PHY level (broadcast on PBCH). 38.473 does not define any F1 message for MIB — the DU generates and encodes the MIB locally, because the MIB’s content (subcarrier spacing, SSB index, half-frame timing, etc.) depends on the actual RF/PHY configuration that the DU controls.

   
   

2. SIB1- The SIB1 is treated as part of “system information” that the CU delivers to the DU using F1AP: SystemInformationDelivery.

Therefore:

The CU creates SIB1 content (PLMN list, TAC, cellAccessRelatedInfo, scheduling info for remaining SIBs).

The DU transmits it over PDSCH according to scheduling instructions. 

Some vendors allow “DU-local SIB1 generation” for stand-alone or O-RAN test setups, but per 3GPP normative behavior, SIB1 comes from CU to DU.

3. Other SIBs (SIB2–SIB9)

Exactly the same pattern applies:

• CU provides their contents and scheduling via F1AP SystemInformationDelivery.

• DU just transmits them over the air as scheduled.

4. Random Access (PRACH/Msg1–4)

   • Generated/terminated at DU (PHY/MAC level: preamble, timing advance, UL grant, contention resolution).

   • No CU involvement in the real-time exchanges—only RACH outcome is reported to CU via F1-C.

5. RRC Connection Establishment

   UE → DU: RRCConnectionRequest (UL-CCCH).

   DU → CU: F1-C Initial UL RRC Message Transfer (encapsulates the UL RRC PDU).

   CU → DU: F1-C DL RRC Message Transfer with RRCConnectionSetup.

   DU → UE: sends RRCConnectionSetup over the air.

   UE → DU: RRCConnectionSetupComplete (contains NAS Registration Request).

   DU → CU: F1-C UL RRC Message Transfer carrying the RRC PDU (and thus the NAS).

6. NAS/NG signalling

   • CU ↔ AMF (NGAP):

     • CU sends Initial UE Message (with NAS Reg Request).

     • AMF responds with Initial Context Setup Request (security/algs/NG-UE-AMBR, PDU session hints, etc.).

   • CU → UE (via DU): RRC Security Mode Command → UE’s Security Mode Complete.

   • Transport over F1-C as UL/DL RRC Message Transfers; on air, DU just transmits/receives.

7. UE Context & Bearers

   • CU-CP → DU: F1-C UE Context Setup (SRBs/DRBs, security keys for RLC/MAC, F1-U tunnel endpoints, QoS).

   • CU-UP ↔ DU: F1-U GTP-U tunnel establishment for user plane.

   • CU-CP → UE (via DU): RRCReconfiguration to activate SRBs/DRBs, meas config, etc.

   • CU ↔ AMF: NGAP Initial Context Setup Response, Registration Accept (NAS carried in RRC).

Who “owns” what here?

• DU generates/terminates: PRACH/MAC control (TA, HARQ, scheduling), on-air PHY/MAC/RLC PDUs.

• CU generates/terminates: All RRC (setup, security, reconfig), all NGAP/NAS transport, F1 UE context and bearer control.

High-Level Flow

1. Random Access at DU/RU; DU establishes C-RNTI.

2. RRC Connection Setup (DU transmits; RRC layer is CU-CP).

3. Initial UE Message (NGAP) to AMF with NAS Registration Request.

4. Authentication/Security (NAS), Initial Context Setup (NGAP) with security keys, DRB/SDAP policy.

5. E1AP Bearer Context Setup (CU-CP→CU-UP) to provision UP anchors & TEIDs.

6. F1AP UE Context Setup (CU→DU) with cell group cfg, DRBs (if PDU session established), SRB2/DRB cfg.

7. RRC Reconfiguration to UE; resume uplink -> Registration Complete (NAS).

Key IEs (selected, not exhaustive)

• Initial UE Message (NGAP): RAN UE NGAP ID, NAS-PDU (Registration Request), UE Location, RRCEstablishmentCause, 5G-S-TMSI.

• Downlink NAS Transport (NGAP): NAS Auth Request, Security Mode Command.

• Initial Context Setup Request (NGAP): AMF UE NGAP ID, RAN UE NGAP ID, Security Keys (Kgnb deriv), Allowed NSSAI, GUAMI, PDU Session Resource Setup List (if any), UE AMBR, Paging DRX.

• E1AP Bearer Context Setup: UE ID, DRB To Be Setup List, QoS Flow→DRB mapping (QFI), UL/DL UP-TNL (N3 TEIDs at CU-UP, F1-U towards DU), PDCP duplication/DAPS config flags.

• F1AP UE Context Setup: CU/DU UE F1AP IDs, SRB/DRB setup list, UL/DL F1-U TNL info (GTP-U TEIDs & IPs), Serving cell and CG-Config, TDD UL/DL pattern, Contention Resolution ID if pending.

6) Paging

In a 5G NR system, paging is a network-initiated procedure that allows the 5G Core (AMF) and the Radio Access Network (gNB) to locate and re-establish communication with a UE that is in a low-power or inactive state (RRC Idle or RRC Inactive). It enables the UE to receive downlink data or signaling without maintaining a continuous connection, thereby saving power and radio resources. Paging is fundamental for mobility management and efficient network resource utilization in 5G.

1. AMF → CU-CP: NGAP Paging.

2. CU-CP → DU(s): F1-C Paging (CU selects target DUs/cells per TA list/last seen/idle context).

3. DU → UE (air): PDCCH (P-RNTI) + PCCH/PCH paging message over SSB/BWP as configured.

Ownership

• CU: receives paging from core, decides where to page, fans out over F1-C.

• DU: executes the radio paging transmission with exact timing/beam/SFN.

Scenarios When Paging is Performed

1. Downlink Data Arrival (Idle/Inactive UE):

   When the UPF receives user data for a UE that is not currently in RRC Connected state, it notifies the SMF/AMF, which triggers paging to wake the UE.

2. Incoming Voice or IMS Call (VoNR):

   For an incoming call (e.g., SIP INVITE received in IMS), the AMF pages the UE to re-establish radio and NAS connectivity before call setup.

3. Network-Initiated NAS Signaling:

   The AMF may page the UE for NAS messages such as configuration updates, security re-keying, or de-registration procedures.

4. RRC Inactive Resume:

   If the UE was in RRC Inactive, paging is used to trigger RRC Resume instead of full re-registration, reducing latency and overhead.

5. Emergency Services or Public Warning Broadcasts:

   Paging can be triggered for ETWS/CMAS messages or high-priority emergency notifications to ensure UE wake-up for urgent alerts.

6. AMF-Initiated Context Relocation:

   During mobility or inter-AMF transitions, paging helps re-locate a UE to a new AMF or RAN node if context synchronization is lost.

Paging Flow Summary

Triggering:

The AMF decides to page the UE when it has downlink NAS signaling or data available (e.g., Service Request, call setup, or notification).

It sends an NGAP PAGING message to all relevant gNBs serving the UE’s Tracking Area List (TAL).

RAN Distribution:

The gNB-CU receives the paging request and identifies the DUs and cells within the UE’s registered tracking area.

It sends an F1AP PAGING message to those DUs.

Air Interface Transmission:

Each DU transmits the RRC Paging message over the Physical Downlink Control Channel (PDCCH) and PDSCH in the configured paging occasions.

The UE listens on these occasions using its configured Paging DRX cycle and Paging Frame calculation based on its 5G-S-TMSI.

UE Response:

Upon detecting its paging identity, the UE initiates an RRC Resume (if Inactive) or RRC Connection Request (if Idle), re-establishing a connection with the gNB.

It then sends a NAS Service Request to the AMF to continue communication.

Core→RAN path

• AMF triggers NGAP PAGING to CU-CP with UE Paging Identity (5G-S-TMSI or IMSI), TAI List, Paging DRX, optional Paging Attempt Info.

• CU-CP determines target cells & DUs -> sends F1AP PAGING to relevant DUs with Paging Identity, Paging DRX, CN UE Paging Identity (5G-S-TMSI), Paging Area.

• DU performs PDCCH/PDSCH paging according to DRX; UE responds with RRC Resume (if suspended) or RRC Setup Request.

Selected IEs

• NGAP PAGING: UE Paging Identity, TAI List, Paging DRX, CN Domain.

• F1AP PAGING: CN UE Paging Identity, Paging DRX, Paging Area, Next-Paging-Occasion (implicit via cycle).

7) RRC Suspend/Resume & Release

In the 5G NR architecture, the Radio Resource Control (RRC) protocol—managed by the gNB-CU-CP—controls UE connection states.

• RRC Suspend: Moves the UE from RRC Connected to RRC Inactive, retaining UE and session context in both the gNB and the core (AMF).

• RRC Resume: Restores the RRC connection from Inactive to Connected, reusing stored contexts to minimize signaling and latency.

• RRC Release: Terminates the UE’s radio and core context, transitioning the UE from RRC Connected or Inactive to RRC Idle (requiring full re-registration next time).

Scenarios When RRC Suspend/Resume/Release Are Performed

1. RRC Suspend

• Triggered When:

  • The network wants to reduce radio resource usage and signaling overhead for temporarily inactive UEs.

  • The UE has no ongoing data transfer but may soon resume activity (e.g., short app pauses, background data).

• Procedure Summary:

  • The gNB-CU-CP sends an RRCRelease message with a SuspendConfig to the UE.

  • The message includes parameters like I-RNTI, Resume IDs, Paging Cycle, and RRC Inactive configuration.

  • The UE releases radio resources but stores its security, mobility, and context info locally.

  • The CU-CP retains a lightweight UE context, while DUs release lower-layer resources.

2. RRC Resume

• Triggered When:

  • The UE has been paged for downlink data or signaling.

  • The user initiates uplink activity (e.g., app access, data transmission).

  • The UE is moving between cells and resumes in the same or different DU under the same CU.

• Procedure Summary:

  • The UE sends an RRCResumeRequest to the gNB via random access.

  • The DU forwards this message via F1AP UL RRC Message Transfer to the CU-CP.

  • The CU-CP validates the Resume IDs, retrieves the UE context, and may trigger E1AP Bearer Context Modification (if needed).

  • The CU-CP sends an RRCResume (or RRCReconfiguration) back to the UE through the DU, restoring full connectivity.

  • Once confirmed, user-plane paths (F1-U, E1, N3) are reactivated, and data transfer resumes seamlessly.

3. RRC Release

• CU generates RRC; DU handles on-air and keeps the minimal “suspended context” parameters like resume IDs and BWP state per CU instructions.

• Triggered When:

  • The UE becomes fully inactive for a long time or is explicitly disconnected (e.g., session end, power-off).

  • The AMF or gNB decides to release the UE due to inactivity or mobility to another PLMN/AMF region.

  • Security or subscription updates require re-registration.

• Procedure Summary:

  • The gNB-CU-CP sends an RRCRelease message without a SuspendConfig, instructing the UE to move to RRC Idle.

  • The UE deletes most stored contexts and listens for paging only.

  • The CU-CP sends F1AP UE Context Release to the DU and NGAP UE Context Release Request to the AMF.

  • The AMF acknowledges with UE Context Release Complete, finalizing cleanup of the control and user plane contexts.

RRC Release with Suspend (connected→inactive):

• CU-CP sends RRCRelease with SuspendConfig (I-RNTI/Resume IDs, Paging Cycle), may include Suspend-Indication values for fast resume.

• DU drops MAC context; UE enters RRC Inactive.

• F1AP UE Context Release toward DU (resource cleanup).

• Optional NGAP UE Context Release if releasing N2 UE context.

RRC Resume:

• UE sends RRCResumeRequest → DU forwards via F1AP UL RRC Message Transfer to CU-CP.

• CU-CP validates UE context (maps Resume IDs→UE context), may trigger F1AP UE Context Setup/Mod if path/DRBs needed, and E1AP Bearer Context Modification to re-arm UP.

• CU-CP sends RRCResume / RRCReconfiguration to finalize.

• F1AP UL RRC Message Transfer: RRCResumeRequest.

• F1AP UE Context Setup/Modification: DRB to be re-activated, F1-U TNL Info.

• E1AP Bearer Context Modification: Re-establish PDCP state (if needed), duplication config.

• NGAP: implicit only if core signaling is needed (e.g., Service Request NAS in DL/UL NAS Transport).

8) Handover Flows

Handover is the process by which an active User Equipment (UE) seamlessly transitions its radio connection from one cell or gNB to another without interrupting ongoing sessions. Handover procedures ensure service continuity, mobility support, and quality of experience (QoE) as the UE moves across coverage areas. In a gNB split architecture (CU/DU/RU), handovers are intelligently coordinated between distributed and centralized functions to maintain optimal connectivity while minimizing latency and packet loss.

Key Benefits of 5G NR Handover Mechanisms

• Seamless User Experience: Ensures ongoing calls and sessions are maintained during mobility.

• Low Latency Transitions: Optimized control/user plane split minimizes service interruption.

• Network Scalability: CU/DU split enables distributed mobility management and resource balancing.

• Interoperability: Xn and NG interfaces standardize handovers across multi-vendor environments.

• Optimized Resource Utilization: Facilitates efficient load balancing and interference mitigation.

Types of Handovers in 5G NR gNB Split Architecture

• Intra-DU (source cell → target cell on same DU): RRC-level reconfiguration (MobilityControlInfo) with minimal or no F1 context relocation; CU-CP remains same anchor; no DU change.

• Inter-DU, Intra-CU (Inter-Cell across DUs under same CU): CU-CP orchestrates F1 UE context move: releases at source DU, sets up at target DU. CU-UP remains same anchor; may switch F1-U endpoints.

• Intra-CU, Inter-gNB-DU (if different gNB-DUs but still under same CU): functionally same as Inter-DU within CU.

• Inter-CU, Intra-gNB (multi-CU deployment): context transfer between CUs via Xn or N2 HO depending on topology.

• Inter-gNB:

  • Xn-based HO (preferred when Xn available): direct gNB-to-gNB preparation via XnAP; AMF not in the prep loop (only gets Path Switch after UE arrives).

  • N2-based HO (via AMF): when no Xn or inter-PLMN; AMF mediates HandoverRequired/Command/Request sequence.

User-plane

• Make-before-break with DAPS (PDCP duplication) when supported, or data forwarding via Xn-U/F1-U tunnels.

• Path Switch after UE attaches at target: NGAP Path Switch Request/Accept toward AMF/UPF; SMF/UPF updates N3.

Intra-DU

Scope: Occurs when the UE moves between cells under the same DU (e.g., different sectors or frequencies controlled by the same DU).

Control Entity: Same CU and DU; no F1 or E1 signaling changes.

Who does what:

• CU still runs mobility: sends RRCReconfiguration (MobilityControlInfo) to UE via DU using F1-C DL RRC Transfer.

• DU applies new cell config/scheduling locally; minimal F1 context change.

• User plane stays on same F1-U endpoints; may only update radio parameters.

 Key Feature:

1.      Handled at the RRC layer (RRCReconfiguration with MobilityControlInfo).

2.      Minimal signaling; only PHY/MAC layer reconfiguration is needed.

3.      Fastest type of handover (<10 ms).

Use Case: UE moving between sectors of the same site or intra-cell frequency changes.

Inter-DU, Intra-CU

Scope: UE moves between two different DUs under the same CU.

Control Entity: Single CU-CP manages both DUs via F1 interface.

Who does what:

CU-CP orchestrates:

• F1-C UE Context Setup to target DU (security, DRBs, F1-U TEIDs), potential UE Context Modification on source DU.

• RRCReconfiguration (with mobility command) to UE via source DU; UE switches to target cell.

• Data forwarding (optional short buffering) handled by CU-UP, F1-U paths switch to target DU.

• Release at source DU: F1-C UE Context Release.

Procedure:

1. Source DU reports measurement reports to CU-CP.

2. CU-CP prepares the target DU via F1AP UE Context Setup Request.

3. UE receives RRCReconfiguration (Handover Command) from CU-CP through the source DU.

4. After synchronization with the target cell, the target DU confirms handover completion.

5. CU-CP releases source DU context using F1AP UE Context Release.

6. CU-UP may update F1-U TNL Info if user-plane endpoints change.

Benefits:

• No NG signaling with AMF required (local handover within same CU).

• Very low latency and resource-efficient.

• F1AP UE Context Release (source DU) and UE Context Setup (target DU).

• E1AP Bearer Context Modification if F1-U endpoints change.

• RRCReconfiguration with security continuity/PDCP re-estab if needed.

Inter-CU (Xn-based)

Scope: UE moves between two different gNBs connected via the Xn interface.

Control Entity: Different CUs; coordinated directly via XnAP signaling.

Who does what:

Preferred Xn HO (CU↔CU):

• Source CU → Target CU: XnAP Handover Request / Ack, data forwarding via Xn-U.

• UE gets RRCReconfiguration (source side) to move; completes on target.

• Core (AMF) is mostly informed (Path Switch NGAP) after UE attaches to target CU-UP. 

Procedure:

1.      Source CU triggers XnAP Handover Request to Target CU.

2.      Target CU prepares the target DU and responds with XnAP Handover Request Acknowledge.

3.      Source CU sends RRCReconfiguration (HO Command) to UE.

4.      UE synchronizes with target cell and sends HO Confirm.

5.      Path Switch occurs at AMF via NGAP Path Switch Request/Response to update N3 tunnel between UPF and new CU-UP.

Benefits:

• Fast inter-gNB handover without involving the AMF during preparation.

• Reduces core signaling load (localized mobility management).

• Enables vendor-independent interoperability.

• XnAP Handover Preparation (Handover Request/ACK) carrying UE context, security, DRB QoS, UP-TNL info for forwarding.

• Handover Command to UE (RRC).

• UE synchronizes to target; NGAP Path Switch Request/Accept after arrival.

Inter-gNB (N2-based)

Scope: Occurs when Xn connectivity between source and target gNBs is unavailable or they belong to different PLMNs.

Control Entity: The AMF manages coordination via NGAP signaling.

Who does what:

• N2 HO (via AMF) if Xn unavailable:

• Source CU ↔ AMF ↔ Target CU using NGAP HandoverRequired / HandoverRequest / HandoverCommand, then Path Switch.

Procedure:

1. Source gNB sends NGAP Handover Required to AMF.

2. AMF forwards Handover Request to target gNB.

3. Target gNB prepares resources and responds with Handover Request Ack.

4. AMF sends Handover Command to source gNB to trigger RRC HO command.

5. After successful handover, NGAP Path Switch Request/Accept updates the N3 tunnel to the new CU-UP.

 Benefits:

• Provides inter-PLMN mobility (roaming, inter-operator transitions).

• Ensures mobility when Xn interface isn’t deployed.

• NGAP Handover Required (source→AMF) → Handover Request (AMF→target) → Handover Command (source→UE).

• After UE accesses target, NGAP Path Switch Request (target→AMF) to update UPF N3.

Key IEs (selected)

• Handover Required/Request: Cause, Target ID (global gNB/TAI/Cell ID), UE Security Caps, EPS/5GS Interworking info, DRB-to-Setup-List with QFI mapping, UP-TNL info.

• Path Switch Request: UE NGAP IDs, PDU Session Resource to be switched list with new N3 tunnel info.

Summary on who does what:

Control-plane messages (selection)

Message / Procedure	Over-the-air?	F1-C involved?	Terminates at	Notes
PRACH Msg1–4	Yes	RACH report to CU	DU (PHY/MAC)	Time-critical access
RRCConnectionRequest/Setup/Complete	Yes	UL/DL RRC Msg Transfer	CU-CP	DU just transports RRC
Security Mode Command/Complete	Yes	UL/DL RRC Msg Transfer	CU-CP	Keys provisioned to DU for RLC/MAC
RRCReconfiguration (SRB/DRB, mobility)	Yes	UL/DL RRC Msg Transfer	CU-CP	DU applies radio config parts
NGAP Initial UE Msg / ICS / Path Switch	No	—	CU-CP ↔ AMF	Core signalling
Paging	Air (PCCH/PCH)	F1-C Paging	CU (decision), DU (tx)	CU selects DUs, DU transmits
UE Context Setup/Mod/Release	No	F1-C	CU controls, DU applies	Bearer & security context on DU
System Information Delivery	Air	F1-C SI Delivery	CU provides; DU broadcasts	SIB scheduling/timing at DU

User-plane

Plane	Tunnel	Endpoints	Notes
F1-U	GTP-U	CU-UP ↔ DU	Per-DRB tunnels; switch on HO
N3	GTP-U	CU-UP ↔ UPF	Path switch on HO
Xn-U (inter-CU HO)	GTP-U	Source CU-UP ↔ Target CU-UP	Temporary forwarding during

9) Summary

The 5G NR gNB split architecture divides the base station into Central Unit (CU), Distributed Unit (DU), and Radio Unit (RU) to achieve flexibility, scalability, and efficient resource utilization. This functional decomposition separates higher-layer control and user-plane functions from lower-layer radio processing, enabling distributed deployments, cloud-native RAN evolution, and multi-vendor interoperability.

The architecture relies on well-defined interfaces:

• E1 (between CU-CP and CU-UP) for bearer and user-plane context control,

• F1 (between CU and DU) for RRC and PDCP-to-MAC coordination, and

• NG (between CU and 5GC) for N2/N3 signaling to the AMF and UPF.

These interfaces are established during node setup and form the foundation for core RAN procedures such as UE Registration, Paging, RRC Suspend/Resume/Release, and Handover (Intra-DU, Inter-DU, Inter-CU, Inter-gNB). Each procedure uses standardized signaling (NGAP, E1AP, F1AP, XnAP, and RRC) and specific information elements to ensure secure context management, low-latency mobility, and efficient data routing.

Overall, the gNB split architecture enhances operational flexibility, reduces fronthaul bandwidth demand, supports network slicing and dynamic scaling, and is a cornerstone of open and cloud-native 5G RAN evolution.

10) References

Spec Number	Title / Description
3GPP TS 38.300	NR Overall Description	gNB architecture, CU/DU split, mobility overview
3GPP TS 38.401	NG-RAN Architecture Description	Functional split, F1/E1/Xn/NG interface definitions
3GPP TS 38.463	NG-RAN; F1 Application Protocol (F1AP)	F1 setup, UE context mgmt, handover signaling between CU and DU
3GPP TS 38.462	NG-RAN; E1 Application Protocol (E1AP)	E1 setup, bearer context modification, inter-CU coordination
3GPP TS 38.423	NG-RAN; Xn Application Protocol (XnAP)	Xn-based inter-gNB handover procedures
3GPP TS 38.413	NG-RAN; NG Application Protocol (NGAP)	NG setup, N2-based inter-gNB handover, UE context handling
3GPP TS 38.331	NR; Radio Resource Control (RRC) Protocol	RRC Release, Suspend, Resume, and Handover control messages