Add conclusion for OAI

- It also includes EPC/5GC core network components (MME, SPGW‑U, AMF, SMF, UPF, etc.) in separate projects that can be combined with the RAN for end‑to‑end 4G/5G experiments.

OAI provides two main simulation / emulation modes:

- For LTE, OAI originally introduced two main emulation modes:

- For LTE, OAI [\[i.10\]](#_ref_i.10) originally introduced two main emulation modes:

    - A PHY‑abstraction mode, where a high‑level error model replaces detailed PHY processing and injects decoder errors based on SNR/channel models to speed up large‑scale simulations;

    - A full PHY mode, where the real PHY signal is convolved with an emulated channel in real time, providing high‑fidelity link behavior at higher computational cost.

​- These modes allow controlled, repeatable evaluations with emulated wireless links, while keeping the rest of the stack identical to real deployments.

​

**Note** OAI does not simulate WiFi. WiFi POAs is out of scope for this replacement.

This feasibility study covers the following aspects:

- Can the OAI [\[i.10\]](#_ref_i.10) provide more realistic network simulation?

- Are the impacts on the existing architecture significant?

- What are the benefits?

- Which strategy to conduct the developments needed to replace the current network simulation approach

The feasibility study is organized as follow:

- The clause [A.2](#a2-current-network-simulation-description) covers the analyze of the current architecture and provides the pros and cons of replacing;

- The clause [B.2](#b2-openairinterface-description) covers the OpenAirInterface [\[i.10\]](#_ref_i.10) and provides the pros and cons of replacing;

- The clause [B.3](#b3-conclusion) covers all the required changes in the current architecture to do the replacement.

**Note** OAI [\[i.10\]](#_ref_i.10) does not simulate WiFi. WiFi POAs is out of scope for this replacement.

## B.2. OpenAirInterface Description

### B.2.1 Introduction

The OAI codebase is organized as a modular software stack that mirrors the layered structure of 3GPP systems:

The OAI [\[i.10\]](#_ref_i.10) codebase is organized as a modular software stack that mirrors the layered structure of 3GPP systems:

- Physical (PHY) layer for LTE and NR (OFDM, channel coding, MIMO processing, reference signals, synchronization);

- Data link layers including MAC, RLC, and PDCP;

- Control plane layers such as RRC and NAS termination points;

- S1/F1/NG control and user plane interfaces used to connect the RAN to EPC/5GC components.

Separate trees are dedicated to LTE and NR, but higher layers share common infrastructure where possible. A set of “targets” and test harnesses wraps these libraries into executable entities, such as eNB, gNB, UE, and emulation binaries. This structure allows the same protocol implementation to be used in (i) pure software simulations, (ii) real‑time SDR‑based experiments, and (iii) hybrid setups where some parts run over RF while others remain emulated.

Separate source code trees are dedicated to LTE and 5GNR, but higher layers share common infrastructure where possible. A set of “targets” and test harnesses wraps these libraries into executable entities, such as eNB, gNB, UE, and emulation binaries. This structure allows the same protocol implementation to be used in (i) pure software simulations, (ii) real‑time SDR‑based experiments, and (iii) hybrid setups where some parts run over RF while others remain emulated.

![Figure B.2.1. OAI 4G/5G Simulation Mode - High-level Components](media/B.2.1.Introduction.png)

The real-time emulator is used when you need applications/protocols to experience realistic wireless timing effects. The counter part is a limited scale compared to pure non-real-time simulation.

The real‑time emulators runs under an RTOS (historically RTAI/Linux RT) with strict layer‑2 timing (e.g., subframe/TTI deadlines are enforced against wall‑clock time). It is designed to emulate wireless behavior while running actual real‑time applications (ping, VoIP, video streaming) over the emulated link, so end‑to‑end latency and jitter reflect realistic radio timing

### B.2.2.5 Conclusions

#### B.2.2.5 real‑time emulators

Even if this study does not cover WiFi support, the replacement of the current network simulation with OAI [\[i.10\]](#_ref_i.10) represents a strategic upgrade that will transform the ETSI MEC Sandbox from a basic network emulator into a research-grade, 3GPP-compliant simulation platform.

The OAI [\[i.10\]](#_ref_i.10) does not simulate UE movement or radio propagation: the NR-UE and gNB exchange I/Q samples over TCP, and there is no built-in notion of position or handover. UE mobility must therefore be managed outside OAI

The use of Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) provides the following advantages:

- Real 3GPP stack – Actual RAN (and optionally CN) implementation; same code path as with real RF.	No built-in mobility – RF simulator is static; mobility would need external logic or real RF.

- RF simulator mode – Test full stack without hardware (e.g. --rfsim); good for protocol/feature testing.	One gNB/eNB process per cell – Multi-cell = many processes and ports; handover/multi-cell is more operational work.

- Production alignment – Same binaries can run with USRP/other RF; easier path from “sim” to “real” deployment.	Real-time and CPU bound – RF sim is not a discrete-event sim; scaling many cells/UEs is heavier.

- Real UEs and traffic – Can attach real UEs (COTS or OAI UE) and run real IP traffic through the stack.	V2X – Not a standard part of OAI RF sim; would need 3GPP V2X support or custom work.

- Open, documented – OAI Wiki, tutorials, CI (e.g. 5g_rfsimulator).

To reflect logical mobility in the OAI RAN, we have to add an OAI mobility adapter that:

- Subscribes to the MEC Sandbox mobility events;

- Maps each POA to an OAI cell (gNB or eNB) and maps each UE to an OAI NR-UE (or LTE UE) process/container;

- When the serving POA changes, the adapter triggers one of:

    - Handover (if supported by your OAI deployment): the UE is handed over from the old gNB to the new gNB via 3GPP procedures. OAI has [handover support](https://gitlab.eurecom.fr/oai/openairinterface5g/-/blob/v2.2.0/doc/handover-tutorial.md) and, in some branches, [inter-gNB-DU handover with the RF simulator](https://gitlab.eurecom.fr/oai/openairinterface5g/-/tree/inter-gNB-DU-handover/radio/rfsimulator) (multiple gNB-DUs, one gNB-CU, measurement reports, context transfer).

    - Reattach: Stop the NR-UE (or LTE UE) connected to the old gNB and start a new instance (or reconfigure the same one) so that it attaches to the new gNB (different `rfsimulator.serveraddr`/port). The UE gets a new IP from 5GC (or keeps it if the 5GC maintains the session); the MEC app may need to use the same UE identity (e.g. IMSI) to correlate.

###£ B.2.2.6 Conclusions

Even if WiFi and UE mobility are not supported, the replacement of the current network simulation with OAI [\[i.10\]](#_ref_i.10) represents a strategic upgrade that will transform the ETSI MEC Sandbox from a basic network emulator into a research-grade, 3GPP-compliant simulation platform.

The use of OAI [\[i.10\]](#_ref_i.10) provides the following advantages:

- Real 3GPP stack: Real signalling, scheduling, and PHY/MAC instead of TC + formulas.

- Realistic MEC and RNI: Real user plane and identities; RNI from real RAN KPIs via an adapter.

- No RF hardware: RF simulator mode for full-stack testing without radios.

- Ecosystem: Open source, documented, containers/Compose; upstream evolution and fixes.

- Multi-cell and handover: One gNB per cell; handover possible when supported.

The replacement will be considered successful if:

- All current scenarios can be simulated in Simu5G/SimuLTE;

- Real-time emulation works for applications;

- System is stable and production-ready.

<mark>TODO</mark>

> **⚠️ IMPORTANT CONSIDERATIONS**

>

> To summurize, Simu5G/SimuLTE [\[i.5\]](#_ref_i.5) are based on OMNeT++ [\[i.3\]](#_ref_i.3), a discrete-event simulator; modelling 4G/5G with SUMO/Veins mobility, simulated time and many cells/UEs in one run.

> On the other hand, OAI [\[i.10\]](#_ref_i.10) is a real 3GPP RAN (and optional 5GC), with a RF simulator mode; no built-in mobility; real time; one process per cell.

> Comparison by criterion:

> - Protocol realism: OAI (real stack) vs Simu5G (modelled);

> - Mobility / V2X: Simu5G (SUMO/Veins) vs OAI (GIS + optional adapter);

> - Scale and simulated time: Simu5G (many nodes, simulated time) vs OAI (real time, one cell per process);

> - MEC apps and RNI: OAI (real user plane, N6, RNI adapter) vs Simu5G (bridge + export). Both provides a basic implementation of ETSI MEC;

> - Operations and production path: OAI (same stack as real RF) vs Simu5G (separate simulator + bridge).

>

> For the MEC Sandbox specifically, OAI is the better fit when replacing TC emulation with a real stack and supporting real MEC apps with minimal new pieces; Simu5G is the better fit when the focus is large-scale simulation and rich mobility/V2X with a simulator + bridge. In addition, ETSI and FSCOM have good connection with EURECOM, the main contributor to OAI. This can help to get the support of OAI from EURECOM.

>

> **In all cases, a phase of learning is mandatory before to start the replacement of the current network similation and a need for an extension for several months of the STF 707 will be required ([\[i.5\]](#_ref_i.5)).**

--

## B.3. Replacement Procedure