Editorial changes and clause numbering alignment before to present the document to MEC#45

<br />

# Annex A: <br>Feasibility study

# Annex A: Feasibility study

## A.1. Overview

This annex provides a feasibility study for replacing the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]] with Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5). The current system uses Linux Traffic Control [\[i.2\]](#_ref_i.2) to simulate network characteristics, while Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) are OMNeT++-based discrete event simulators [\[i.3\]](#_ref_i.3) that provide more realistic 3GPP-compliant network behavior.

This feasibility study covers the following aspects:

- Can the [Simu5G/SimuLTE]() provide more realistic network simulation?

- Can the [Simu5G/SimuLTE](#_ref_i.5) 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 clause [A.3](#a3-simu5gsimulte-description) covers the Simu5G/SimuLTE simulators [\[i.5\]] and provides the pros and cons of replacing;

- The clause [A.4](#a4-replacement-procedure) covers all the required changes in the current architecture to do the replacement.

**Note:** After the discussion with the MEC-DEC-067 Working Group, The possibility to use OpenAirInterface (OAI) simulator is considered as a potential alternative to the Simu5G/SimuLTE simulators. This is covered in [Annex B](#annex-b-feasibility-study-for-openairinterface-oai).

## A.2. Current Network Simulation Description

### A.2.1 Architecture Overview

- External Interfaces: TUN/TAP interfaces for real application integration

- Synchronization: Time synchronization with real world

#### A.3.5 Simulation modes

### A.3.5 Simulation modes

The Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) provide 2 simulations:

- The non‑emulation simulation is pure, offline discrete‑event runs where all traffic endpoints are simulated modules and time is virtual, - - - The emulation simulation runs in real time and connect the simulated 5G network to real interfaces and applications so real packets traverse the simulated RAN and core network.

- The non‑emulation simulation is pure, offline discrete‑event runs where all traffic endpoints are simulated modules and time is virtual;

- The emulation simulation runs in real time and connect the simulated 5G network to real interfaces and applications so real packets traverse the simulated RAN and core network.

This is the emulation mode that is required here. The emulation scenarios map simulated network interfaces (e.g. at UE, router...) to real host interfaces (TAP/veth, NICs), so IP packets from real processes or devices enter the simulation, traverse the 5GNR/LTE stack, and return to the real network.

#### A.3.6 Real-time emulation modes

### A.3.6 Real-time emulation modes

By the architecture, the Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) are a discrete-event simulators (see OMNeT++ manual: https://doc.omnetpp.org/omnetpp/manual/#sec:simple-modules:discrete-event-simulation). Therefore, the simulations does not match real time clock.

> **⚠️ IMPORTANT CONSIDERATIONS**

>

> The counterpart is a huge changes in the current ETSI MEC Sandbox architecture, and a higher complexity. The Simu5G simulator is implemented as a single-process, single-threaded application. As a result:

> The counterpart is a huge changes in the current ETSI MEC Sandbox architecture, and a higher complexity. The Simu5G/SimuLTE simulators are implemented as a single-process, single-threaded application. As a result:

> 1. Executing simulations that involve a large number of User Equipments (UEs) or intricate scenarios may result in diminished performance, which could potentially introduce operational challenges;

> 2. A multi-core machine can be exploited by running multiple independent simulations on different cores.

>

> In addition, two warnings shall be raised regarding performance and the objectives to achieve:

> In addition, three warnings shall be raised regarding performance and the objectives to achieve:

>

> 1. A network scenario containing a lot of PoAs and UEs could drastically reduce the performance of the Simu5G/4G simulators. The objective of 10 simultaneous connections on the MEC Sandbox could be achieved. **Note** that a paper (https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9591605) demonstrates the capacity of Simu5G to  emulate a few base stations and tens of UEs.

>

<br />

# Annex B: <br>Feasibility study for OpenAirInterface (OAI)

# Annex B: Feasibility study for OpenAirInterface (OAI)

## B.1. Overview

This annex provides a feasibility study for replacing the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]] with OpenAirInterface [\[i.10\]](#_ref_i.10). OAI [\[i.5\]](#_ref_i.5) provides a full software implementation of both LTE (4G) and NR (5G) radio access networks, and can run them either against real RF hardware or entirely in simulation/emulation mode without over‑the‑air signals:

This annex provides a feasibility study for replacing the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]] with OpenAirInterface [\[i.10\]](#_ref_i.10). The OAI [\[i.5\]](#_ref_i.5) provides a full software implementation of both LTE (4G) and NR (5G) radio access networks, and can run them either against real RF hardware or entirely in simulation/emulation mode without over‑the‑air signals:

- OAI implements the complete 4G LTE eNB/UE and 5GNR gNB/UE protocol stacks from PHY up to RRC and S1/F1 interfaces, aligned with 3GPP releases (LTE Rel‑10/12 and NR Rel‑15 in the public codebase);

- The OAI [\[i.5\]](#_ref_i.5) implements the complete 4G LTE eNB/UE and 5GNR gNB/UE protocol stacks from PHY up to RRC and S1/F1 interfaces, aligned with 3GPP releases (LTE Rel‑10/12 and NR Rel‑15 in the public codebase);

- 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:

The OAI provides two main simulation / emulation modes:

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

- For the 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 [\[i.10\]](#_ref_i.10) does not simulate WiFi. WiFi POAs is out of scope for this replacement.

**Note** The 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.2 Simulation vs. Real‑Time RF Operation

OAI distinguishes between two broad execution modes:

The OAI distinguishes between two broad execution modes:

- RF‑attached mode: The PHY is clocked by real hardware (e.g., USRP or other SDR), samples are transmitted and received over the air, and time‑critical processing is constrained by the hardware sampling rate and 1 ms (LTE) or 0.5/1 ms (NR) TTI boundaries;

- Simulation/emulation mode: The PHY produces and consumes baseband waveforms that are not transmitted over RF. Instead, waveforms are passed through software channel models or abstractions, and timing can be either real‑time or accelerated/relaxed depending on configuration.

- The instantaneous or average signal‑to‑noise ratio (SNR);

- Possibly, an externally provided channel quality indicator (CQI) or effective SINR.

Packets are then randomly marked as correctly received or erroneous according to this BLER, and HARQ and higher layers react accordingly. This preserves the interface between PHY and MAC but avoids heavy baseband processing. PHY‑abstraction is particularly suited for:

The packets are then randomly marked as correctly received or erroneous according to this BLER, and HARQ and higher layers react accordingly. This preserves the interface between PHY and MAC but avoids heavy baseband processing. PHY‑abstraction is particularly suited for:

- Large‑scale system‑level simulations with many UEs and cells;

- Long‑duration experiments where realistic radio conditions must be approximated, but exact waveform behavior is less critical;

##### B.2.2.2.1 Introduction

OAI extends the same concept to 5GNR, with a full PHY implementation that supports OFDM numerologies, flexible slot structures, new reference signals, and 5G channel coding (LDPC and Polar codes). In NR PHY emulation mode, baseband samples generated by the gNB and UE are passed through software channel models.

The OAI extends the same concept to 5GNR, with a full PHY implementation that supports OFDM numerologies, flexible slot structures, new reference signals, and 5G channel coding (LDPC and Polar codes). In NR PHY emulation mode, baseband samples generated by the gNB and UE are passed through software channel models.

These models can emulate:

- Frequency‑selective multipath fading in wideband OFDM;

#### B.2.2.3 End‑to‑End 4G/5G Emulation with Core Network

OAI includes or interoperates with software implementations of EPC (for LTE) and 5GC (for NR). In a typical end‑to‑end emulation:

The OAI includes or interoperates with software implementations of EPC (for LTE) and 5GC (for NR). In a typical end‑to‑end emulation:

- One or more eNB/gNB instances run in simulation mode, with either abstracted or full PHY;

- Multiple UE instances connect to these base stations, again using simulated channels rather than RF;

    - 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

### B.2.3 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.

> **⚠️ 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.

> On the other hand, the 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);

> - Protocol realism: the  (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).

> - Operations and production path: the OAI [\[i.10\]](#_ref_i.10) (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.

> For the MEC Sandbox specifically, the 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)).**

>

> We also propose to start the task 3 immediately after the acceptance of this feasability study.

--

## B.3. Replacement Procedure