# Background knowledge

:::info
**Resources**
1. https://hackmd.io/AQym4FBjRvyRA8sk1d8KQw?view#Potential-Topics
2. https://5g.systemsapproach.org/ran.html
:::

Main architectural components of cellular access networks
eNB (evolved Node B) = base station (4G, gnB in 5G)
- RAN manages the radio spectrum, making sure it is used efficiently and meets the QoS requirements of every user. It corresponds to a distributed collection of base stations.
- Mobile core serves several purposes
- Provides internet connectivity for both data and voice services
- Ensures this connectivity fulfills the promised QoS requirements
- Tracks user mobility to ensure uninterrupted service
- Tracks subscriber for billing and charging. In 4G this is called the *Evolved Packet Core (EPC)* and in 5G it's called *Next Generation Core (NG-Core)*
- Backhaul network interconnects the base stations that implement the RAN with the Mobile Core. Ex: *Passive Optical Network (PON)* that implements Fiber-to-the-Home is a prime candidate for implementing the RAN backhaul.

CUPS, *Control and User Plane Separation*

## Radio Access Network
1. Each base station establishes the wireless channel for a subscriber's UE upon power-up or upon handover when the UE is active. This wireless channel is said "*to provide a bearer service*".
2. Each base station establishes "3GPP Control Plane" connectivity between the UE and the corresponding Mobile Core Control Plane component, and forwards signaling traffic (enables UE authentication, registration, and mobility tracking) between the two.
3. For each active UE, the base station establishes one or more tunnels between the corresponding Mobile Core User Plane component.
4. Base station forwards both control and user plane packets between the Mobile Core and the UE. #*Connectivity between RAN an Mobile Core is IP-based*
5. Each base station coordinates UE handovers with neighboring base stations, using direct station-to-station links.
6. Base stations coordinate wireless multi-point transmission to a UE from multiple base stations

RAN as a whole (not just a single base station) not only supports handovers, but also link aggregation and load balancing.

## Mobile Core
- Main function = **provide external packet data network (Internet) connectivity to mobile subscribers**, while ensuring that they are authenticated an their observed service qualities satisfy their subscription SLAs.
- It needs to manage all subscribers' mobility by keeping track of their last whereabouts at the granularity of the serving base station.
- 5G Mobile Core is heavily influenced by the cloud's march toward a microservice-based (cloud native) architecture
- In **4G** Mobile Core -> **Evolved Packet Core (EPC)**
- In **5G** Mobile Core -> **NG-Core**, adopts a microservice-like architecture (because the level of disaggregation, it's a set of functional blocks and not an implementation)

**SECURITY ARCHITECTURE**

**DEPLOYMENT OPTIONS**
Based on 3GPP, deployment options:
- Standalone 4G/Stand-Alone 5G
- Non-Standalone (4G+5G RAN) over 4G's EPC = **NSA**
-> Involves 5G base stations being deployed alongside the existing 4G base stations in a given geography to provide a data-rate and capacity boost.
-> **Control plane traffic** between the UE and the 4G Mobile Core is forwarded through **4G Base Stations**, and the **5G Base Stations** are used only to carry user traffic.

- Non-Standalone (4G+5G RAN) over 5G's NG-Core

## RAN Internals
### Packet Processing Pipeline
Note:
Specified by 3GPP standard
Base station as a pipeline
View it as a protocol stack

### Split RAN
- How these stages can be disaggregated, distributed, and implemented.
- How the functionality outlined above is partitioned between physical elements, and hence, “split” across centralized and distributed locations.
- Partition shown in figure below being actively pursued by the **operator-led O-RAN (Open RAN) Alliance**.
- The RRC (centralized in the CU) is responsible for only near-real-time configuration and control decision making, while the Scheduler that is part of the MAC stage is responsible for all real-time scheduling decisions.
- RAN-wide configuration: a single CU running in the cloud serves multiple DUs, each of which in turn serves multiple RUs.

- Because scheduling decisions for radio transmission are made by the MAC layer in real time, a DU needs to be “near” (within 1ms) the RUs it manages.
- In 4G network, the Backhaul Network connected the base stations (eNBs) back to the Mobile Core. With the split-RAN there are multiple connections:
- RU-DU connectivity is called the Fronthaul
- DU-CU connectivity is called the Midhaul
- CU-Mobile Core connectivity is called the Backhaul
- CU encompasses RRC and PDCP which lie on the RAN’s control plane and user plane. This separation is consistent with the idea of CUPS and plays an increasingly important role into how the RAN is implemented. The two parts are typically referred to as the CU-C and CU-U, respectively.

### Software-Defined RAN
SD-RAN: RAN implemented according to SDN principles

RRC is partitioned into two-sub components
- **Control plane (forwarding)**, provides a 3GPP-compliant way for the RAN to interface to the Mobile Core’s control plane.
-> forwards control packets between the Mobile Core and the PDCP, providing a path over which the Mobile Core can communicate with the UE for control purposes
- **Near-Real Time RAN Intelligent Controller (RIC)**, opens a new programmatic API for exerting software-based control over the pipeline that implements the RAN user plane.
-> implements the core of the RRC’s control functionality
-> “Near-Real Time” qualifier indicates the RIC is part of 10-100ms control loop implemented in the CU, as opposed to the ~1ms control loop required by the MAC scheduler running in the DU.

RIC maintains a RAN Network Information Base (R-NIB)–a common set of information that can be consumed by numerous control apps. R-NIB includes time-averaged CQI values and other per-session state, while the MAC maintains the instantaneous CQI values required by the real-time scheduler

### Architect to Evolve

**First tier of disaggregation**
- Horizontal RAN splits
- From a single base station into three distinct components: CU, DU, RU
- 3GPP defines the N2 and N3 interfaces between RAN and Mobile Core

**Second tier of disaggregation**
- Vertical RAN splits
- Contol/user plane separation (CUPS) of the CU: CU-U and CU-C
- CU-U: realizes pipeline for user traffic
- CU-C: control message signaling between Mobile Core and the disaggregated RAN components

**Third tier**
- Follows the SDN paradigm by carrying vertical disaggregation further
- Separating most of RAN control (RRM functions) from the disaggregated RAN components
- Logically centralizing RAN control as apps running on SDN Controller, which corresponds to the Near-RT RIC

**INTERFACES**
- A1
- Mobile operator's management plane (the OSS/BSS) --- uses to configure the RAN
- OSS/BSS sits at the top of any Telco software stack. It's the source of all configuration settings and business logic needed to operate a network.

- E2
- The Near-RT RIC uses E2 to control the underlying RAN elements
- Able to connect the Near-RT RIC to different types of RAN elements. This range is reflected in the API, which revolves around a **Service Model** abstraction.
- The idea is that each RAN element advertises a **Service Model**, which effectively defines the set of RAN Functions the element is able to support.
- Operations against the Service Model: **Report, insert, control, policy**

A1 and E2 complete two of three major control loops of the RAN: the outer (non-real-time) loop has the Non-RT RIC as its control point and the middle (near-real-time) loop has the Near-RT RIC as its control point. The third (inner) control loop, runs inside the DU:It includes the real-time Scheduler embedded in the MAC stage of the RAN pipeline.

Two outer control loops have rough time bounds of >>1sec and >10ms, respectively, and the real-time control loop is assumed to be <1 ms.

Starting with the inner loops, not all RRM functions can be centralized. After horizontal and vertical CUPS disaggregation, the RRM functions are split between CU-C and DU. SDN-based vertical disaggregation focuses on centralizing CU-C-side RRM functions in the Near-RT RIC. Turning to the outer two control loops, the Near RT-RIC opens the possibility of introducing policy-based RAN control, whereby interrupts to operator-defined policies would signal the need for the outer loop to become involved. The Non-RT RIC would then interact with the Near-RT RIC to deliver relevant operator policies from the Management Plane to the Near RT-RIC over the A1 interface.

Why there is an O-RAN Alliance in the first place? Over time 3GPP has become a vendor-dominated organization, whereas O-RAN was created more recently by network operators. O-RAN’s goal is to catalyze a software-based implementation that breaks the vendor lock-in that dominates today’s marketplace. The E2 interface is architected around the idea of supporting different Service Models, is central to this strategy.