# 📘 Weekly Notes – TEEP 2026

---

## 📑 Weeks Overview
- [Week 1: Foundation of 5G Core (5GC)](#week-1)
- [Week 2: Deep Dive into User Plane Protocols](#week-2)
- [Week 3: Practical Simulation with UERANSIM](#week-3)
- [Week 4: Control Plane Mechanics (NAS & RRC)](#week-4)
- [Week 5: O-RAN Architecture & Disaggregation](#week-5)
- [Week 6: OAI Split-Mode Deployment (CU/DU)](#week-6)
- [Week 7: End-to-End Integration & OAI UE](#week-7)
- [Week 8: SMO & Network Slicing](#week-8)
- [Week 9: Final Validation & Optimization](#week-9)

---

<a id="week-1"></a>
## 📅 Week 1: Foundation of 5G Core (5GC)

## 2026/04/20 - 2026/04/27

🔹 **Summary:** Studied 5G Core SBA architecture and successfully deployed Free5GC using Docker.

<details>
<summary> View detailed report</summary>

### Objective
The objective of this week was to understand the architecture of the 5G Core network, particularly the Service-Based Architecture (SBA), and to deploy a functional 5G Core using the open-source platform Free5GC.

### Theoretical Study
A study of the 3GPP specification TS 23.501 was conducted to understand the overall 5G system architecture.

The 5G Core is based on a Service-Based Architecture (SBA), where Network Functions (NFs) communicate with each other using APIs over HTTP/2 and exchange data in JSON format.

The main Network Functions studied include:

- **AMF (Access and Mobility Management Function):** handles user registration and mobility
- **SMF (Session Management Function):** manages PDU sessions
- **UPF (User Plane Function):** responsible for data forwarding
- **UDM (Unified Data Management):** manages subscriber information
- **NRF (Network Repository Function):** enables service discovery between NFs

Another important concept is the Control and User Plane Separation (CUPS), where control functions (AMF, SMF) are separated from the user plane (UPF).

### Implementation
- Created a virtualized environment using VirtualBox with Ubuntu 22.04
- Installed Docker and Docker Compose for containerized deployment

### Deployment
The Free5GC core network was deployed using the official Docker Compose configuration.

Steps included:
- Cloning the Free5GC Docker repository
- Configuring the network interface
- Launching all Network Functions as Docker containers

### Verification and Results

**a) Running Network Functions**
*Figure 1: Running Free5GC containers (AMF, SMF, UPF, NRF, UDM, etc.)*

**b) NRF Registration**
*Figure 2: NRF logs showing NF registration*

**c) AMF Interaction**
*Figure 3: AMF logs showing interaction with other NFs*

### Conclusion
A functional 5G Core network was successfully deployed using Free5GC in a containerized environment.

</details>
### Objective
The objective of this week was to understand the architecture of the 5G Core network, particularly the Service-Based Architecture (SBA), and to deploy a functional 5G Core using the open-source platform Free5GC.

---

<a id="week-2"></a>
## 📅 Week 2: Deep Dive into User Plane Protocols

## 2026/04/27 - 2026/05/03

🔹 **Summary:** This week focused on the technical architecture of the 5G NR User Plane, specifically the data-processing path from the application layer to the physical radio interface. By analyzing the SDAP, PDCP, RLC, and MAC sublayers, I studied the transition from flow-based QoS in the core network to radio-optimized data bearers.

<details>
<summary> User Plane Protocol Stack (SDAP, PDCP, RLC, MAC)</summary>

The protocol stack defines how data packets are transformed through various sublayers before being transmitted over the air. Each layer adds its own header and performs specific functions.

- **SDAP (Service Data Adaptation Protocol)**
acts as the interface between the core network's Quality of Service (QoS) framework and the radio access network. Its primary responsibility is the mapping of individual QoS flows to specific Data Radio Bearers (DRBs). By marking packets with a QoS Flow ID (QFI), SDAP ensures that the network handles different types of traffic—such as high-priority voice data versus standard background web traffic—according to their specific requirements for latency and reliability.

- **PDCP (Packet Data Convergence Protocol)**
serves as the security and efficiency hub of the stack. Before data is transmitted, PDCP performs header compression using Robust Header Compression (ROHC) to reduce the overhead of IP packets, which is critical for saving radio bandwidth. More importantly, it handles the encryption (ciphering) and integrity protection of user data to ensure privacy. On the receiving end, PDCP is responsible for reordering packets that may have arrived out of sequence and removing any duplicate packets created during handover.

- **RLC (Radio Link Control)**
focuses on the reliable delivery and formatting of data units. It operates in three modes (Transparent, Unacknowledged, and Acknowledged) depending on the needs of the application. The RLC layer performs segmentation and reassembly, breaking down large data units from higher layers into smaller segments that fit the size requirements of the current radio channel conditions. It also provides an Automatic Repeat Request (ARQ) mechanism to recover any lost packets that were not caught by the lower layers.

- **MAC (Medium Access Control)**
is the "engine room" that manages access to the physical radio medium. It is responsible for multiplexing data from various RLC logical channels into transport blocks that are sent to the Physical (PHY) layer. The MAC layer handles the Hybrid ARQ (HARQ) process, which is a high-speed error correction method, and performs the vital task of scheduling, deciding which users get to transmit data at any given millisecond based on signal quality and buffer status.

Figure 1: User Plane Protocol Stack

</details>

<details>
<summary> QoS Mapping in 5G NR</summary>

In 5G, Quality of Service (QoS) is managed at the Flow level rather than the Bearer level used in 4G LTE. This transition allows for much finer control over data priority. The mapping process is essentially a two-step translation that happens as data travels from the 5G Core (5GC) through the base station (gNB) and finally to the User Equipment (UE).

1. PDU Session to QoS Flows:
The process begins in the 5G Core. When data enters the network, the User Plane Function (UPF) inspects the incoming packets and classifies them into specific QoS Flows based on "QoS Rules." Each flow is assigned a QoS Flow ID (QFI). This ID is linked to specific performance characteristics, such as the 5QI (5G QoS Identifier), which defines the priority level, packet delay budget, and acceptable error rate for that specific stream of data.

2. QoS Flows to Data Radio Bearers (DRB):
Once the packets reach the gNB (the cell tower), the SDAP layer takes over. The gNB must decide how to send these various QoS flows over the air. Since it is inefficient to create a separate radio connection for every single flow, the SDAP layer maps one or more QoS flows into a single Data Radio Bearer (DRB). For example, several flows with similar latency requirements might be bundled into the same DRB to optimize radio resources.

* Reflective Mapping (The "Uplink" Secret):
One of the most efficient features of 5G QoS is Reflective Mapping. Instead of the network constantly sending complex instructions to the phone on how to handle upload data, the UE can "observe" the QFI in the downlink packets it receives. The UE then automatically applies the same mapping for its uplink (upload) traffic. This reduces signaling overhead and ensures that the priority remains consistent in both directions without the need for constant reconfiguration.

The following figure illustrates this end-to-end mapping process from the 5G Core to the User Equipment

Figure 2: 5G NR QoS Mapping: From Service Data Flows (SDF) to Data Radio Bearers (DRB).

</details>

<details>
<summary> User Plane Packet Encapsulation</summary>

The Encapsulation Flow

1. IP Layer to SDAP:
The process begins with an IP Packet (the Payload). When it hits the SDAP layer, a 1-byte header is typically added. This header contains the QFI (QoS Flow ID), which tells the base station exactly what priority this specific packet needs.

2. SDAP to PDCP:
The SDAP PDU becomes the "Data" for the PDCP layer. PDCP adds a header containing a Sequence Number (SN). This is also where Header Compression (ROHC) occurs; the bulky IP header is compressed to save space, and the entire packet is encrypted (ciphered).

3. PDCP to RLC:
The PDCP PDU is passed to the RLC layer. RLC adds its own header to manage Segmentation. If the packet is too large for the current radio conditions, RLC chops it into smaller pieces and adds information to the header so the receiving side knows how to put them back together.

4. RLC to MAC:
The RLC PDU(s) are passed to the MAC layer. The MAC header is complex; it includes the LCID (Logical Channel ID) to identify which data stream it belongs to and handles the HARQ (Hybrid ARQ) process for rapid error correction.

5. MAC to PHY:
Finally, the MAC layer bundles everything into a Transport Block. This is the final "package" that the Physical (PHY) layer converts into radio waves to be sent over the air.

The following diagram illustrates the encapsulation process of an IP packet (using a Modbus PDU as the example application data). As the data descends the 5G stack:

* Each layer treats the data from above as a Service Data Unit (SDU).

* The layer adds its own protocol information as a Header (H).

* The combined unit becomes a Protocol Data Unit (PDU), which is then passed to the layer below.
Figure 3: 5G NR User Plane Data Encapsulation and Decapsulation Process

</details>

<details>
<summary> LTE vs 5G NR PDCP Comparison</summary>

1. Introduction of the SDAP Layer:
In LTE, PDCP communicated directly with the IP layer. There was no dedicated sublayer for Quality of Service (QoS) mapping between the core network and the radio. In NR, the new SDAP (Service Data Adaptation Protocol) layer sits above PDCP. This means NR PDCP receives pre-classified QoS flows, allowing it to handle security and compression for specific types of traffic much more efficiently than LTE could.

2. Support for Out-of-Order Delivery:
In LTE, PDCP was strictly required to deliver packets to the upper layers in the exact order they were sent. If one packet was lost, everything behind it was held up (a problem called "Head-of-Line Blocking"). NR PDCP introduces a more flexible out-of-order delivery option. This is crucial for 5G’s low-latency goals; if the application can handle it (like some video streaming or voice protocols), PDCP can pass packets up as soon as they arrive, even if they are out of sequence.

3. Integrity Protection for User Plane Data:
In LTE, integrity protection (the mechanism that prevents someone from tampering with the data packets) was generally only applied to Control Plane (signaling) messages. For the User Plane, it relied mostly on ciphering (encryption). In NR, PDCP supports Integrity Protection for the User Plane as well. This was added to meet the higher security standards of 5G, particularly for mission-critical services like remote surgery or autonomous vehicles where a tampered packet could be dangerous.
Figure 4: Functional comparison between NR PDCP and LTE PDCP architectures.

</details>

---

<a id="week-3"></a>
## Week 3: Practical Simulation with UERANSIM

## 1. Deployment of UERANSIM

### 1.1 Introduction

To simulate the Radio Access Network (RAN) part of the 5G architecture, the open-source platform UERANSIM was deployed. UERANSIM emulates both the User Equipment (UE) and the gNodeB (gNB), enabling interaction with the Free5GC Core Network without requiring physical radio hardware.

The deployment process consisted of preparing the Ubuntu environment, installing the required dependencies, downloading the UERANSIM source code, and compiling the project to generate the UE and gNB executables.

### 1.2 Environment Preparation

The deployment was performed on Ubuntu 22.04 LTS. Before installing UERANSIM, the operating system packages were updated to ensure compatibility and stability of the environment.

### Updating the System

sudo apt update && sudo apt upgrade -y

### 1.3 Installing Required Dependencies

UERANSIM requires several development tools and networking libraries for successful compilation and execution. The following packages were installed:

sudo apt install git make gcc g++ libsctp-dev lksctp-tools iproute2 -y

### 1.4 Installing CMake

UERANSIM requires CMake version 3.17 or later for compilation. The following command was used to install CMake:

sudo snap install cmake --classic

Verifying CMake Installation
cmake --version

### 1.5 Cloning UERANSIM Source Code

The UERANSIM repository was downloaded from GitHub using the following command:

git clone https://github.com/aligungr/UERANSIM

After cloning, the project directory was accessed using:

cd UERANSIM

### 1.6 Building UERANSIM from Source

The project was compiled using the make command:

make

During this process, the source files were compiled and the UE and gNB executables were generated successfully.

### 1.7 Verification of Installation

After compilation, the generated executables were verified inside the build directory:

ls build

### 2. Configuration of UERANSIM and Free5GC Integration

### 3. UE Registration and PDU Session Establishment

<a id="week-4"></a>
## 📅 Week 4: Control Plane Mechanics (NAS & RRC)
### 🎯 Purposes
-

### Objectives
-

### Keypoints
-

### Tasks
-

---

<a id="week-5"></a>
## 📅 Week 5: O-RAN Architecture & Disaggregation
### 🎯 Purposes
-

### Objectives
-

### Keypoints
-

### Tasks
-

---

<a id="week-6"></a>
## 📅 Week 6: OAI Split-Mode Deployment (CU/DU)
### 🎯 Purposes
-

### Objectives
-

### Keypoints
-

### Tasks
-

---

<a id="week-7"></a>
## 📅 Week 7: End-to-End Integration & OAI UE
### 🎯 Purposes
-

### Objectives
-

### Keypoints
-

### Tasks
-

---

<a id="week-8"></a>
## 📅 Week 8: SMO & Network Slicing
### 🎯 Purposes
-

### Objectives
-

### Keypoints
-

### Tasks
-

---

<a id="week-9"></a>
## 📅 Week 9: Final Validation & Optimization
### 🎯 Purposes
-

### Objectives
-

### Keypoints
-

### Tasks
-