<h1>
TEEP Week 2 : Open RAN
</h1>

<h2>
Open RAN Key Concept
</h2>

<h3> 1. Disaggregation </h3>

In traditional Radio Access Networks (RAN), components such as the Radio Unit (RU), Baseband Unit (BBU), and antennas are typically delivered as a tightly integrated solution by a single vendor. This monolithic architecture leads to vendor lock-in, limiting flexibility and innovation.

Open RAN addresses this by introducing disaggregation — the separation of RAN functions into modular, independent components:

- Radio Unit (RU) – handles analog and digital signal processing.
- Distributed Unit (DU) – performs lower-layer processing.
- Centralized Unit (CU) – manages higher-layer processing.

This modular approach allows operators to source components from different vendors, promoting interoperability, competition, and faster innovation.

<h3> 2. Virtualization </h3>

Virtualization in Open RAN means that RAN functions, which used to run on proprietary hardware, can now run on general-purpose commercial servers (COTS – Commercial Off-The-Shelf). DU and CU functions can be deployed as Virtual Network Functions (VNFs) or Cloud-Native Network Functions (CNFs).

The benefits of virtualization include:

- Cost efficiency: Reduces dependence on specialized hardware.
- Flexibility: Functions can be scaled or moved as needed based on demand.
- Scalability: Enables dynamic network expansion and supports diverse deployment scenarios (e.g., rural, urban, edge).

<h3> 3. Open Interfaces </h3>

A fundamental principle of Open RAN is the use of open and standardized interfaces. Organizations like the O-RAN Alliance define these interfaces to ensure components from different vendors can work together seamlessly.

Key examples include:

- F1 interface: connects CU and DU.
- Open Fronthaul (e.g., eCPRI): connects RU and DU.
- E2 interface: connects the RAN Intelligent Controller (RIC) with CU/DU.

By using open interfaces, operators are no longer locked into a single vendor’s ecosystem and can integrate best-of-breed solutions from multiple suppliers, reducing costs and increasing innovation potential.

<h3> 4. Intelligence and Automation </h3>

Open RAN introduces the RAN Intelligent Controller (RIC), which acts as the brain of the network and enables advanced automation and optimization. There are two types of RIC:

- Near-Real-Time RIC (near-RT RIC): Controls time-sensitive functions (10 ms to 1 s) such as radio resource management.
- Non-Real-Time RIC (non-RT RIC): Handles longer-term analytics and policy-based optimizations using AI/ML.

RICs support apps called xApps (near-RT) and rApps (non-RT), enabling use cases like traffic steering, load balancing, energy efficiency, and dynamic QoS adjustments. This intelligence layer helps operators to fine-tune the network in real time and improve overall performance with minimal human intervention.

<h2>
Open RAN Architecture
</h2>


Open RAN, or O-RAN, represents the most advanced and modern evolution of Radio Access Network (RAN) architecture. Unlike traditional RAN systems, where components are tightly integrated and usually provided by a single vendor, Open RAN disaggregates these components—meaning they are separated into distinct, interoperable elements—and allows them to run as software functions on general-purpose commercial hardware (COTS: Commercial Off-The-Shelf). The architecture is built around several core elements: the virtualized core network (vEPC or 5GC), the Centralized Unit (vCU or O-CU), the Distributed Unit (vDU or O-DU), and the Radio Unit (RU or O-RU), all of which are interconnected using open and standardized interfaces.

<h3>
1. vEPC / 5GC
</h3>

At the top of this architecture is the vEPC (virtual Evolved Packet Core) or 5GC (5G Core), which handles critical core network functions such as session management, mobility, and data transfer. vEPC is used in LTE-based systems, while 5GC is designed for native 5G deployments. From the core, data traffic flows through the Backhaul link to the vCU or O-CU, a virtualized software module responsible for higher-layer processing, including mobility management, radio resource control, and encryption (mainly Layer 3 and part of Layer 2 in the OSI model).

<h3>
2. vCU / O-CU
</h3>

The vCU (virtual Centralized Unit), also referred to as O-CU in the context of Open RAN, is a critical logical component responsible for handling the higher layers of the radio protocol stack. Specifically, it manages Layer 3 and the upper part of Layer 2. Its position in the RAN architecture is between the core network (vEPC or 5GC) and the vDU/O-DU, connected through what is known as the midhaul interface. One of the key advantages of disaggregating the CU from the DU is that it enables operators to scale and manage control plane and user plane resources independently, allowing for more efficient network operation.

<h3>
3. vDU/ O-DU
</h3>

The Centralized Unit (CU) connects to the vDU or O-DU via a Midhaul link. The DU is in charge of lower-layer processing, such as real-time scheduling, MAC, and PHY layer operations (Layer 1 and lower Layer 2). Both CU and DU are virtualized and can be deployed on cloud infrastructure or edge data centers, depending on latency requirements and deployment strategies. This separation gives operators greater flexibility to position components optimally based on user distribution, network load, and service needs.

<h3>
4. RU / O-RU
</h3>

At the network edge is the Radio Unit (RU or O-RU), the physical component that transmits and receives RF signals via antennas. The RU connects to the DU using a Fronthaul interface, commonly based on eCPRI, which is an open standard that allows seamless interoperability. One of the key strengths of Open RAN is that this radio hardware can be integrated with DUs from different vendors.

<h2>
Open RAN Callflow
</h2>

The OpenRAN Callflow describes the communication process between the different network elements in an OpenRAN infrastructure when managing user connections (UE) and data communication. Below are the key steps in the OpenRAN callflow:

<h3>User Registration (Attach)</h3>

- UE (User Equipment), such as a mobile phone, sends a signal to connect to the network. This process begins when the UE tries to connect to the RU (Radio Unit), which receives the radio signal from the UE.
- The RU forwards this request to the DU (Distributed Unit) for further processing.
- The DU performs initial processing and sends relevant information to the CU (Centralized Unit), which is responsible for managing authentication, resource allocation, and connection setup.
- The CU communicates with the AMF (Access and Mobility Management Function) in the core network to authenticate the user and ensure that the UE is authorized to access the network.
- If authentication is successful, the CU confirms the access to the UE, allowing it to connect to the network and services.

<h3> Data Communication </h3>

- After the UE is connected, if the user initiates data communication (such as browsing the internet), the UE sends a data request.
- The RU receives the signal from the UE and sends the data information to the DU, which then forwards it to the CU.
- The CU manages the network's resources and configures the data communication path, connecting the UE to the core network.
- In the core network, the CU collaborates with the SMF (Session Management Function) and UPF (User Plane Function) to manage the data session.
- The SMF configures the communication session and sets data routing parameters.
- The UPF is responsible for transferring data between the UE and external services, such as the internet.
- The data is processed and sent back to the UE through the configured path.

<h3>
Mobility Management and Handover
</h3>

- If the UE moves or transitions between network areas (for example, moving between cells or cell towers), the AMF and CU manage the handover process.
- During handover, the CU coordinates with the AMF to ensure the UE remains connected and communication continues without interruptions.
- The DU and RU are involved in maintaining the data connection, ensuring that communication remains stable as the UE moves from one area to another.

<h3> Session Termination (Detach) </h3>

- When communication is completed or the UE requests to terminate the connection (detach), the UE sends a signal to end the session.
- This signal is forwarded from the RU to the DU, and eventually to the CU, which then informs the AMF that the session has ended and network resources can be released.
- The CU and AMF confirm that the session has been terminated, and the UE is no longer connected to the network.
- Afterward, the UE is ready to initiate a new connection or move to another network area.

<h2>
RAN Intelligence Controler
</h2>


The O-RAN Alliance has introduced a disaggregated architecture for both 4G and 5G RAN systems, emphasizing several key components:

- **Lower Layer Split:** This involves dividing the physical layer so that its lower portion runs in the Radio Unit (RU), while the upper portion operates in the O-RAN Distributed Unit (O-DU).
- **Non-Real-Time RIC:** Handles control logic with a timescale longer than one second, focusing on slower, non-urgent operations.
- **Near-Real-Time RIC:** Manages low-latency control functions, operating within a timescale of 10 milliseconds to one second.
- **Service Management and Orchestration (SMO):** Oversees the management and orchestration of RAN network functions. It may also host the Non-RT RIC as a co-located component.

<h3>
Non-RT RIC
</h3>

The Non-Real-Time RAN Intelligent Controller (Non-RT RIC) is a key part of the O-RAN architecture that handles network optimization and decision-making tasks that do not require immediate response. It works on a timescale of over one second and is often integrated with the Service Management and Orchestration (SMO) system. Its main functions include managing policies, training AI/ML models using historical RAN data, performing large-scale analytics, and running long-term optimization applications called rApps. The Non-RT RIC communicates with the Near-RT RIC through the A1 interface to provide guidance and machine learning models, helping improve overall network efficiency and performance.

<h3>
Near-RT RIC
</h3>

The near-RT RIC is a platform that allows closed-loop control of RAN-optimization applications to be onboarded as xApps. The xApps use platform services available in the near-RT RIC to communicate with the downstream network functions through the E2 interface, where the downstream network functions can be gNB O-DU, gNB O-CU-CP, gNB O-CU-UP, or O-eNB.

<h2>
UE Simulator
</h2>

<h3>
1. My5G-RANTester
</h3>

This tool is designed to assess and explore 5G capabilities by conducting various tests and simulating both the control and data planes for the UE and gNodeB. It includes conformance testing for key procedures such as:

- UE registration
- gNodeB registration
- PDU session requests.

Overall, the framework primarily targets the 5G Core (5GC) and its integration with the access network. It does not simulate the wireless channel. As a result, the main purpose of my5G-RANTester is to enable evaluation of 5GC functions by analyzing packet flows using Wireshark, performing black-box testing, verifying compliance with 3GPP Release 15, and assessing system performance. While its focus is on 5GC, it mainly tests functions like AMF, SMF, and UPF, which directly interface with the RAN via NAS and NGAP protocols—hence, support for RAN-side applications is limited.

<h3>
2.gNBsim
</h3>

gNBsim is a tool that emulates both gNodeB and UE by generating NAS and NGAP messages to test various 5G procedures. It supports operations such as:

– UERegistration
– UEInitiated PDU Session Establishment
– UEInitiated De-registration
– ANRelease
– UEInitiated Service Request
– Network triggered PDU Session Release
– UERequested PDU Session Release
– Network triggered UE Deregistration

In addition, it can send ICMP messages over the established data plane to test connectivity. Like my5G-RANTester, its primary focus is on validating 5G Core (5GC) functionalities. The tool also allows each test to be executed either in sequence or concurrently, with the ability to configure the number of data packets sent. It includes a profile feature for test automation, enabling users to customize and chain together standard test scenarios.

<h3>
3. UERANSIM
</h3>

UERANSIM is a tool that simulates a 5G Standalone (SA) UE and RAN, supporting key protocols like NAS and NGAP, as well as procedures such as UE- and network-initiated deregistration and PDU session establishment. On the user plane, it implements the GTP protocol with support for both IPv4 and IPv6.

Unlike lower-layer radio protocol implementations, UERANSIM does not simulate layers below RRC, instead partially emulating them over UDP. However, essential RRC procedures are available. Configuration is handled via YAML files.

Compared to other tools like my5G-RANTester and gNBsim, UERANSIM is less focused on formal testing but enables richer application-level data plane use. It allows real internet access over the N3 interface using applications like ping, tcpdump, HTTP, SSH, and wget, whereas the other tools typically support only basic ICMP testing.


<h3>
4. OpenAirInterface Simulator
</h3>

OpenAirInterface (OAI) is an open-source platform that implements both the core and RAN components of a mobile communication system. It is designed for real-time operation and requires hardware like software-defined radios (SDRs), making it compatible with commercial devices.

There is also a legacy emulator, OAISim, which simulates UEs and gNodeBs using a virtualized physical channel. This environment can be customized using parameters such as channel model, antenna type, path loss, frequency, system bandwidth, and mobility models. It supports various traffic types like VoIP, M2M, and gaming, and provides layer-3 packet tracing in Wireshark. Scenarios are defined using OAI Scenario Descriptors (OSDs).

**Key Features:**
- **Real-time support** with actual SDR hardware.
- **Parallel emulation** of multiple UEs/gNodeBs on one or multiple machines.
- **Metrics dashboard** showing low-level protocol stack and application performance.
- **PHY abstraction mode** to enhance emulation speed and scalability via multi-threading.
- **Traffic emulation tools**: includes ping, iperf, and random uplink/downlink traffic generation.

**Two simulation modes:**
1. **RF Simulator**:
- Works without physical RF hardware.
- Supports "noS1" mode: traffic tunneled directly between gNB and UE (via `oaitun` interface).
- Behavior may vary based on CPU performance.
- Not fully thread-safe for UEs—multi-threading must be carefully managed.

2. **L2 nFAPI Simulator**:
- Uses the **nFAPI** standard to connect MAC and PHY layers.
- Enables efficient simulation by abstracting physical layer interactions.
- Currently supports simulation of up to 16 UEs, aiming for scalability to 255.