[TOC]

# **5G - OpenRAN**

5G is the next generation of **service-based mobile networks** that promises significantly faster data rates, much lower latency, and capabilities such as network slicing.


## Why 5G?
- Significantly faster data rates
- Much lower latency
- Guaranteed end-to-end network performance
- Supports billions of devices and IoT sensors


---

## 5G Function and Architecture


### Core Network Functions

| No. | Function | Description |
| --- | -------- | ----------- |
| 1 | UPF | Manages the data path between UE and data networks. |
| 2 | AMF | Handles user access and mobility management. |
| 3 | SMF | Manages session context and IP address allocation. |
| 4 | AUSF | Authenticates subscribers. |
| 5 | NSSF | Selects the appropriate network slice. |
| 6 | NEF | Provides APIs for external services to interact with core network. |
| 7 | NRF | Maintains NF discovery and registration database. |
| 8 | UDM | Manages user subscription and profile information. |
| 9 | UDR | Stores user data used by UDM, PCF, etc. |
| 10 | AF | Provides application-related policies and QoS support. |
| 11 | PCF | Determines and enforces QoS and access control policies. |

---

### VPLMN vs HPLMN


- **VPLMN (Visited Public Land Mobile Network)**: The network where the user is currently roaming. Handles access, session, and data locally using AMF, SMF, and UPF.
- **HPLMN (Home Public Land Mobile Network)**: The user’s home network responsible for authentication and policy using UDM, AUSF, PCF, and NEF.

**Key Communication Flow during Roaming:**
1. UE connects to the RAN.
2. AMF manages mobility and interfaces with SMF (N11).
3. SMF establishes a session and configures the UPF.
4. AMF contacts AUSF and PCF in HPLMN through vSEPP–hSEPP (N32).
5. UDM provides subscriber info to authorize the session.

---

### Communication Flow

1. **UE** initiates connection via N1 and sends ID/capability.
2. **gNB** (CU/DU) receives request, forwards it via N2 to AMF.
3. **AMF**:
- Authenticates UE via **AUSF**.
- Fetches subscriber info from **UDM**.
- Selects appropriate **SMF** and discovers NFs via **NRF**.
- May query **NSSF** for slice selection.
4. **AUSF** validates identity using UDM credentials.
5. **UDM** fetches data from **UDR** and assists AUSF/AMF.
6. **SMF**:
- Establishes session, assigns IP to UE.
- Selects appropriate **UPF** for data path.
- Coordinates with **PCF** for policy.
15. **PCF** applies QoS/access policies and collaborates with **AF** if required.
17. **NEF** provides API exposure for third-party services (if needed).
18. **UPF**:
- Forwards user traffic to DN (Internet).
- Handles routing, buffering, QoS.
10. **DN (Data Network)** gives access to external services/web.

**Summary:**
- **Control Plane**: Manages session, mobility, security (AMF, SMF, AUSF, PCF, UDM, etc.).
- **User Plane**: Transports user data (UPF → DN).

---

## 5G Network Scenario

### Evolution from 4G to 5G

In 5G deployment, there are two main architectures: **Non-Standalone (NSA)** and **Standalone (SA)**. **NSA** relies on the existing *4G LTE infrastructure* for the **control plane**, while the **user plane** is handled by the 5G base station (**gNodeB**). This allows operators to deploy 5G services quickly by leveraging current 4G networks. In NSA, **eNodeB** and **gNodeB** work together, requiring **dual connectivity**.

On the other hand, **SA** represents a full 5G implementation. Both the control and user planes are managed by **gNodeB**, and the network core is the **5G Core (5GC)**, not dependent on LTE. SA enables advanced 5G capabilities such as *network slicing*, *ultra-low latency*, and *massive IoT* support. Although it requires more investment and infrastructure, SA provides the full benefits of 5G technology.

This diagram illustrates the **evolution of mobile networks** from legacy 4G infrastructure to a full 5G Standalone (SA) architecture. The process involves three main stages:

1. **Legacy Network**: In the initial phase, the network operates solely with *eNodeB* and *EPC* (Evolved Packet Core), typical of a **pure 4G LTE** environment. The **User Equipment (UE)** connects through eNodeB to EPC without any 5G capabilities.

2. **Transit Network**: During the transition phase, **gNodeBs** are gradually introduced while **eNodeBs still operate**, forming a **4G/5G hybrid architecture**. This is often deployed under a **Non-Standalone (NSA)** setup, where eNodeB anchors control signaling, and gNodeB handles 5G data paths. This stage allows a smoother upgrade path with minimal disruption.

3. **Target Network**: In the final stage, the network evolves to **Standalone 5G** where **UE connects directly to gNodeB and 5GC** (5G Core). The reliance on eNodeB and EPC is phased out. This architecture unlocks the full capabilities of 5G, such as *network slicing*, *low latency*, and *enhanced scalability*.


This diagram presents a side-by-side comparison between the **4G Evolved Packet Core (EPC)** and the **5G Core Network (5GC)**. It highlights both functional mapping and infrastructure design principles.

In **EPC**, network functions like **MME, SGW, PGW, HSS**, and **PCRF** are deployed in a tightly coupled architecture. Each component has a fixed role , resulting in **high interdependency** and slower innovation due to rigid integration.

In contrast, the **5G Core (5GC)** adopts a **Service-Based Architecture (SBA)**, where functions like **AMF, SMF, AUSF, UPF**, and others enables more flexibility, allowing independent development, scaling, and deployment of network functions.

### 5G Core Network


---

## 5G Transport Network

### L2+L3 Architecture (Left)

In this model, traffic is forwarded from the radio access network through a **Layer 2 (Ethernet-based) aggregation network**, and then handed off to a **Layer 3 (IP-based) core transport layer**.

- The **L2** portion provides simple switching without IP-level visibility.
- Routing decisions only occur deeper in the network at the **L3 aggregation/core layer**.
- **Addressing** is limited at the edge—IP awareness starts only at the L3 layer.
- This introduces **latency**, **limited visibility**, and **centralized routing dependency**.

---

### L3-to-Edge Architecture (Right)

The **L3-to-edge** model introduces **IP routing (L3)** closer to the **radio access nodes**, enabling more intelligent traffic handling at the edge.

- **Each network node is assigned an IP address**, enabling direct routing decisions from the access layer.
- **End-to-end IP visibility** allows for:
- **Fast rerouting**
- **Better policy enforcement**
- **Granular QoS differentiation**
- Routing to the **nearest UPF** is faster, enabling **MEC** (Multi-access Edge Computing) and **low-latency** applications like URLLC (Ultra-Reliable Low-Latency Communication).

---

## 5G RAN (Radio Access Network)

In 5G:
- The antenna and radio are integrated into a single unit called **AAU (Active Antenna Unit)**.
- **AAU = AU (Antenna Unit) + RU (Radio Unit)**.
- **BBU** is still composed of **DU (Distributed Unit)** and **CU (Central Unit)**, but they are decoupled for flexibility.
- **AAU uses Massive MIMO technology** with integrated beamforming directly at the antenna, providing:
- **Higher spectral efficiency**
- **Dynamic beam steering**
- **Reduced signal loss and latency**
- The CPRI/eCPRI link still connects AAU and DU/CU but carries more dynamic, real-time beam-formed signals.

### CU/DU Split

In the Option 2 split architecture, the **Central Unit (CU)** is responsible for higher-layer processing, specifically the **Radio Resource Control (RRC)** and **Packet Data Convergence Protocol (PDCP)**. RRC manages signaling and control functions between the network and user devices, while PDCP handles tasks like data encryption, header compression, and sequence management.
The **Distributed Unit (DU)** performs lower-layer, real-time operations such as **Radio Link Control (RLC)** for segmentation and retransmission, **Medium Access Control (MAC)** for scheduling and multiplexing, and **Physical Layer (PHY)** for modulation and coding. Lastly, the **Radio Unit (RU)** takes care of the **Radio Frequency (RF)** components, including analog/digital conversion and direct transmission/reception over the air. This layered split enables centralized intelligence in the CU, time-sensitive processing in the DU, and direct radio access through the RU.

### Centralized RAN (cRAN) and Virtualization

In a **Distributed RAN**, the **BBU** is located at each cell site, along with **Remote Radio Units (RRUs)** or **Active Antenna Units (AAUs)**. Each BBU independently handles processing for its corresponding antenna, requiring separate **power**, **clock**, and **infrastructure** per site. While simple and localized, D-RAN is resource-intensive and harder to scale.

In contrast, a **Centralized RAN (C-RAN)** moves all BBUs to a **central location**, such as a **BBU hotel or cabinet**, and connects multiple radio units via a **fronthaul network**. This centralization allows for:
- **Resource pooling**, reducing hardware redundancy
- **Simplified maintenance and upgrades**
- **Support for virtualization**, where BBUs can be implemented as software instances (vBBUs)
- **Enhanced coordination**, enabling features like Coordinated Multi-Point (CoMP)

---

## Open RAN

**Traditional RAN** relies on a closed ecosystem with proprietary hardware, interfaces, and vendor lock-in. In contrast, **Open RAN** enables **interoperability** through open interfaces, disaggregated components, and a flexible, multi-vendor ecosystem—supporting innovation, cost reduction, and network agility.

---
Open RAN introduces a modular, interoperable approach for radio networks through:

1. Disaggregation of hardware and software on vendor-neutral, GPP-based platforms.
2. Open interfaces across RU, CU, DU, and RIC to enable vendor independence.
3. Multiple deployment options:
- Integrated RAN with HW and SW disaggregation.
- Split RAN with combinations of RU, DU, CU, or integrated forms.
4. Flexibility to enable multi-vendor, best-of-breed network components for 2G–5G.

### OpenRAN Architecture


**Key Components:**

- **O-RU (Open Radio Unit)**: Handles RF processing and connects directly to user equipment via the air interface. It interfaces with the DU through the **Open Fronthaul** interface.

- **O-DU (Open Distributed Unit)**: Manages real-time protocol layers such as MAC and PHY, executing latency-sensitive operations.

- **O-CU-CP (Control Plane Central Unit)** and **O-CU-UP (User Plane Central Unit)**: Separated control and user plane functions, respectively. They interact over the **E1** interface and connect to the DU via **F1-c** (control) and **F1-u** (user) interfaces.

- **O-Cloud**: Provides the cloud infrastructure layer for hosting virtualized network functions (VNFs), including the DU, CU, and other RAN components.

---
**Intelligence Layers:**

- **Near-Real-Time RAN Intelligent Controller (Near-RT RIC)**:
- Executes control decisions real time.
- Hosts **xApps**, which are pluggable applications for optimizing RAN behavior (e.g., handover, interference management).

- **Non-Real-Time RAN Intelligent Controller (Non-RT RIC)**:
- Operates on timescales above 1 second.
- Hosts **rApps** for policy guidance, ML model training, and performance analytics.

- **Service Management and Orchestration (SMO)**:
- Provides overall lifecycle management, configuration, and analytics.

### Interface
## Open RAN Interface Summary

| Interface | Connects | Type | Main Function |
|-----------|------------------------------|------------------|--------------------------------------------------------------------------------|
| **F1-C / F1-U** | Central Unit (CU) ⇄ Distributed Unit (DU) | Internal RAN | Splits control plane (F1-C) and user plane (F1-U) between CU and DU in gNodeB. |
| **O1** | SMO ⇄ O-RAN Nodes (CU/DU/NR-RIC/gNB) | Management | Performs FCAPS: Fault, Configuration, Accounting, Performance, and Security. |
| **O2** | SMO ⇄ O-Cloud (5G Infrastructure Cloud) | Infrastructure | Manages and provisions cloud-native resources (platform & network functions). |
| **A1** | Non-RT RIC ⇄ Near-RT RIC | Policy | Transfers policies, ML models, and enrichment data from Non-RT RIC to Near-RT RIC. |
| **E2** | Near-RT RIC ⇄ E2 Nodes (O-DU, O-CU) | Real-Time Control | Enables real-time control (via xApps) for mobility, interference, and traffic. |
| **R1** | Non-RT RIC ⇄ rApps | Non-Real-Time | Connects AI/analytics applications (rApps) to Non-RT RIC. |
| **NG** | gNB ⇄ 5G Core | Core Access | Includes NG-C (control) and NG-U (user data) for accessing the 5G Core Network. |
| **N2 / N3** | CU ⇄ 5G Core | Core Signaling | N2 is for signaling/control, N3 is for user data transfer. |

## Intelligent Controller (RIC)

The **RAN Intelligent Controller (RIC)** is a central component of the Open RAN architecture, designed to bring intelligence, programmability, and automation to the Radio Access Network. It allows network operators to optimize and customize RAN behavior through a data-driven control plane.

### Key Role in O-RAN
The primary goal of the RIC is to enable network optimization through fine-grained data collection and control actions. It effectively disaggregates the control and management functions from the RAN hardware, creating an open platform for innovation.

### Dual-Component Architecture
The RIC platform is fundamentally split into two main components that operate on different time scales, enabling a hierarchical control system. They are both logically part of the **Service Management and Orchestration (SMO)** framework.

- **Non-Real-Time RIC (Non-RT RIC)**: For control loops > 1 second. It handles tasks like policy management and trains AI/ML models for RAN optimization.
- **Near-Real-Time RIC (Near-RT RIC)**: For control loops < 1 second (typically 10ms to 1s). It makes real-time decisions to optimize network performance.

## Near-Real-Time RIC: The Tactical Brain

The **Near-Real-Time RIC (Near-RT RIC)** is a software-defined platform responsible for near-real-time control and optimization of RAN resources. It hosts specialized microservices known as **xApps** that execute fast control loop functions.

### Internal Architecture

The Near-RT RIC platform consists of several key functional components that enable xApps to monitor and control the network in near-real-time.

| Function | Description |
| --- | -------- |
| **xApp Manager** | Manages the full lifecycle of xApps, including secure deployment, health monitoring, and termination. |
| **Shared Data Layer (SDL)** | A high-performance, low-latency database (e.g., Redis) that stores RAN state information. It allows xApps to share data and maintain a consistent, near-real-time view of the network. Also known as the R-NIB (Radio-Network Information Base). |
| **Messaging Infrastructure** | Provides a low-latency, high-throughput message bus (**RIC Message Router - RMR**) for seamless communication between xApps and other RIC platform components. |
| **Interface Controllers** | Manages the external interfaces, translating messages from the E2, A1, and O1 interfaces into the internal message bus. |
| **Security Function** | Provides authentication and authorization for xApps and external connections to ensure secure operation. |

### Key Interfaces

| Interface | Connects To | Protocol | Primary Function |
| --- | -------- | ----------- | ----------- |
| **A1** | Non-RT RIC | REST-based APIs | Receives policies and ML model updates from the Non-RT RIC to guide xApp behavior. |
| **E2** | E2 Nodes (gNB, eNB) | E2AP (E2 Application Protocol) over SCTP | This is the primary southbound interface. It collects RAN data and sends control instructions to the RAN nodes. Its capabilities are defined by **E2 Service Models (E2SM)**, such as E2SM-KPM (Key Performance Monitor) and E2SM-RC (RAN Control). |
| **O1** | Service Management & Orchestration (SMO) | NETCONF/YANG | Handles Operations, Administration, and Maintenance (OAM) for the Near-RT RIC platform itself. |

---

## 4. The Role of xApps (eXtensible Applications)

**xApps** are the core functional logic of the Near-RT RIC. They are independent microservices that can be deployed by an operator to add specific RAN optimization capabilities to the network.

**Key Characteristics:**
- They run on the Near-RT RIC platform.
- They use the platform's SDL and messaging services.
- They communicate with the RAN via the E2 interface.
- They receive guidance from the Non-RT RIC via the A1 interface.

---

## 5. End-to-End Control Loop Workflow

The true power of the RIC lies in the synergy between its two hierarchical control loops.

1. **The Near-RT Control Loop (< 1s):** This is the fast, tactical loop.
- **Sense**: An xApp subscribes to data from a gNB using the **E2** interface (e.g., cell load).
- **Decide**: The xApp analyzes the data, often using policies from the **A1** interface, and decides on an action.
- **Act**: The xApp sends a control message back to the gNB via the **E2** interface to execute the action (e.g., handover a user).

---
## xApp Exploration

### OpenAirInterface (OAI) – FlexRIC
**Platform**: OAI FlexRIC

**Provided xApps / Functions:**
- **RAN Slicing xApp**
Allocates radio resources per slice and maps UEs to slices. Uses a custom E2 service model (e.g., RAN Function ID 145).
- **Custom MAC/PHY Control xApps**
Enables fine-grained control over lower-layer protocol behavior (MAC/RLC/PHY).

**Pros:**
- Full SDK for building custom xApps (C/C++/Python)
- Very flexible and research-friendly
- Direct integration with OAI RAN stack

**Cons:**
- Requires tight integration with compatible gNBs
- Some models not aligned with standardized O-RAN E2SM

---

### O-RAN Software Community (OSC)
**Platform**: OSC Near-RT RIC

**Provided xApps / Functions:**
- **KPIMON xApp**
Collects real-time RAN KPIs via E2SM-KPM.
- **TS xApp (Traffic Steering)**
Balances load by guiding UE handover using A1 Policy and KPM inputs.
- **QoE Predictor xApp**
Predicts user-perceived quality based on metrics.
- **Anomaly Detection xApp**
Detects traffic/performance anomalies in near-real-time.
- **Bouncer xApp**
Measures E2 latency for system diagnostics.

**Pros:**
- Community-backed and well-documented
- Good starting point for xApp developers
- Supports standardized service models

**Cons:**
- Mostly demo-grade xApps
- Requires customization for operator-grade use
- QoE/Anomaly apps may lack maturity

---

### ONF SD-RAN (µONOS RIC)
**Platform**: ONF SD-RAN

**Provided xApps / Functions:**
- **MHO xApp (Mobility Handover)**
Performs handover decisions using Event A3 RSRP measurements.
- **MLB xApp (Mobility Load Balancer)**
Dynamically adjusts handover offsets to balance UE load.
- **RSM xApp (RAN Slice Manager)**
Creates and manages slices; assigns UEs to slices with specific QoS profiles.
- **AI xApp (Intel)**
Uses DRL and GNN to optimize UE-cell association and resource scheduling.

**Pros:**
- Robust and production-grade RIC framework
- Strong support for slicing, mobility, and AI integration
- Fully modular (microservices)

**Cons:**
- Higher learning curve (µONOS-based)
- Integration required with ONF-compatible RAN stacks

---

### NexRAN (University of Utah – POWDER)
**Platform**: Standalone xApp (compatible with OSC)

**Provided xApps / Functions:**
- **NexRAN xApp**
Implements closed-loop RAN slicing with UE policy enforcement and PRB allocation.


**Pros:**
- Open-source and research-ready
- Flexible policy-based slicing framework
- Demonstrated on real testbeds (POWDER)

**Cons:**
- Academic prototype (not production-grade)
- May lack scalability for large networks

---

## NexRAN
**NexRAN** is a software-based solution in the 5G ecosystem that functions as an **xApp**, which is an application that runs on top of the RAN Intelligent Controller (**RIC**) in the O-RAN architecture. NexRAN xApp enables the implementation of **network slicing** at the **RAN level** in a closed-loop manner. This enables dynamic allocation of radio resources to different services or customer requirements.


### RAN Slicing Manager
The RAN Slicing Manager is an application module (typically a RESTful API, administered through the NexRAN xApp) that allows administrators to create, manage, and monitor key objects in the RAN slicing system: eNodeB, Slice, and User Equipment (UE).
The RAN Slicing Manager acts as the top-level controller of the system, translating administrative operations into concrete instructions to the physical nodes of the RAN, linking service requirements to radio infrastructure settings in an automated and policy-driven manner.

### E2AP (E2 Application Protocol)
E2AP is a standard O-RAN communication protocol used between the RAN Intelligent Controller (RIC) and radio access nodes. Its function is to provide a messaging mechanism to dynamically control and monitor RAN elements. Support the transport of messages related to slice settings, KPIs (Key Performance Indicators), and xApp-based policy execution. Allow the E2 agent to export RAN metrics and receive command control from the RIC/xApp, thereby supporting intelligent and automated functions in the O-RAN network.

### srsRAN
It is an open-source software stack for radio access networks (e.g. eNodeB/gNodeB, UE, Core Network) that is used as the main testbed in NexRAN simulation.

### E2 Agent
A module on the srsRAN that implements the E2 Application Protocol (E2AP) to connect the NodeB with the RAN Intelligent Controller (RIC).
Its function is to pass control commands, resource utilisation policies, and performance metrics between the RIC/xApp and the radio device (NodeB). Supports O-RAN service models such as Key Performance Measurement (KPM) and RAN slicing controversy.

### Evolved Packet Core (EPC)
The part of srsRAN that provides function 5G for User Equipment (UE). In the simulated ecosystem, the EPC is configured and run to provide network services, so that registered UEs can access test traffic and perform real slicing.

### Workflow
1. The administrator registers the base station (NodeB/eNodeB) to the system with the REST API provided by NexRAN xApp. The technologies involved are NexRAN xApp (running on RAN Intelligent Controller/O-RAN RIC) and srsRAN as base station software.
1. The administrator creates several network slices through the NexRAN xApp REST API. Each slice is assigned a resource allocation policy proportionally (e.g. with a certain ratio of subframes or resource blocks). NexRAN xApp stores this configuration and applies it later on the corresponding base station.
1. Slices are connected to registered NodeBs so that each NodeB is aware of the slice policy that it has to execute. The NexRAN xApp sends these setup instructions to the base station via the O-RAN E2AP protocol, intermediated by the E2 Agent running on the NodeB/eNodeB.
1. User Equipment (UE) is registered and assigned to a specific slice according to the service scenario. This association is also configured via the NexRAN xApp API, and an external administrator or automation engine can select which IMSI UEs belong to a particular slice according to service requirements.
1. The scheduler on the NodeB divides the radio resources (subframe/resource block) following the set slice policy. srsRAN's slice-aware scheduler performs proportional scheduling and ensures that each slice and UE is allocated according to the inter-slice and intra-slice (between UEs within a slice) scheduling policies.
1. Reading the current state of RAN elements (using the standard O-RAN key performance measurements (KPM) service model) from the base station through the E2 Agent. The data collected includes: number of PRBs used, user data rate, throughput per slice, and number of active UEs.
1. NexRAN xApp monitors slice performance using data from KPM. If there is an imbalance, overload, or change in demand based on KPM-for example, one slice dominates bandwidth or there is a decrease in other slices-NexRAN xApp automatically adapts the resource allocation policy (dynamic adjustment).
1. The NexRAN xApp changes the configuration of resource allocation proportions (through extensions such as balanced throughput or slice throttling) and sends control messages (containing resource allocation change commands) to the NodeB via the O-RAN E2AP protocol implemented by the E2 Agent at the NodeB.
1. The NodeB updates the resource allocation between slices following the latest instructions from the NexRAN xApp via E2AP, and the slice-aware scheduler will improve both fairness and SLA on the network automatically, based on feedback loop closed-loop control.
1. Administrators/researchers can monitor the effects of slicing and policy changes through traffic measurement tools such as iperf, or through a monitoring dashboard that displays slice performance metrics in real time.

:::info
## **References:**
1. [The 5G System Architecture – IEEE](https://ieeexplore.ieee.org/document/8826541)
2. [Huawei 5G course](https://)
3. [OpenRAN - TIP](https://telecominfraproject.com/openran/)
4. [OpenRAN - AT&T](https://www.business.att.com/learn/articles/open-ran-a-modern-approach-to-mobile-networks.html)
5. [OpenRAN - Ericsson](https://www.ericsson.com/en/openness-innovation/open-ran-explained?gad_source=1&gad_campaignid=22627804780&gbraid=0AAAAADHBq_VdM1cTwvnM5IyeM3bKa2It4&gclid=CjwKCAjwvO7CBhAqEiwA9q2YJWv5jB8yIzDKzkBCpEEs6gJduw9V8gAKrmqfoajQ7LuM9wV7sEgAfRoCsC0QAvD_BwE&gclsrc=aw.ds)
6. [Polese, M., D'Oro, S., Bonati, L., et al. (2023). *Understanding O-RAN: Architecture, Interfaces, Algorithms, Security, and Research Challenges* – IEEE Communications Surveys & Tutorials](https://arxiv.org/abs/2202.01032)
7. [Wadud, M.A., Aviles, M., et al. (2023). *Conflict Management in the Near-RT-RIC of Open RAN: A Game Theoretic Approach* – IEEE CPSCom](https://ieeexplore.ieee.org/document/10280129)
8. [NexRAN](https://openaicellular.github.io/oaic/nexran1.html)
:::