Create document skeleton

---

Title: Multi-access Edge Computing (MEC); EdgeNative-X; Integration of Network Emulation Capabilities

Spec Number: MEC-DEC 067

Version: v0.0.1

Date: 2026-01

Version: v0.0.2

Date: 2026-03

Release: 1

Work Item: DGR/MEC-DEC067EdgeNativeX-emul

keywords: MEC, CAPIF, EDGEAPP

<span id="_ref_i.9"></span><a name="_ref_i.9">[i.9]</a> [Kubernetes: ](https://kubernetes.io/) "Kubernetes".

<span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a> [OpenAirInterface: ](https://www.openairinterface.org/) "OpenAirInterface".

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

`MEC     Multi-access Edge Computing`

`POA     Point of Access`

`POC     Proof of Concept`

`OAI     OpenAirInterface`

`REST    Representational State Transfer`

`RNIS    Radio Network Information Service`

`RSRP    Reference Signal Received Power`

<br />

# Annex A: Feasibility study

<br />

# Annex A: <br>Feasibility study

## A.1. Overview

The current network simulation in the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1) combines:

1. Geographic Information System (GIS) Engine: To calculates UE-to-POA distances and signal strength;

2. Network Characteristic Manager: To aggregate network characteristics along paths;

3. Traffic Control (TC) Engine: To apply network characteristics to Kubernetes pods [\[i.9\]](#_ref_i.9);

4. TC Sidecar: To measure actual network characteristics from the traffic.

1. Network Characteristic Manager: To aggregate network characteristics along paths;

1. Traffic Control (TC) Engine: To apply network characteristics to Kubernetes pods [\[i.9\]](#_ref_i.9);

1. TC Sidecar: To measure actual network characteristics from the traffic.

### A.2.2 Components involved in the network simulation

These network characteristics are calculated and applied at different stages:

1. Configuration Stage: Characteristics are configured per network segment (POA, Zone, Domain)

2. Application Stage: Characteristics are applied using Linux Traffic Control [\[i.2\]](#_ref_i.2),

3. Measurement Stage: Actual characteristics are measured from network traffic

4. Aggregation Stage: Characteristics are aggregated along network paths

1. Application Stage: Characteristics are applied using Linux Traffic Control [\[i.2\]](#_ref_i.2),

1. Measurement Stage: Actual characteristics are measured from network traffic

1. Aggregation Stage: Characteristics are aggregated along network paths

Too reflect the Signal Strength calculation in the UE network traffic, the current architecture uses a Linux tool name `tc netem` [\[i.2\]](#_ref_i.2). Several components are involved in the simulation:

- The TC Engine (`go-apps/meep-tc-engine/`): To calculates network characteristics per flow;

The current architecture comes with some limitations:

1. Simplified Radio Model: Linear distance-based signal strength, no realistic fading/shadowing

2. No Protocol Stack: No actual 3GPP protocol simulation (RRC, PDCP, RLC, MAC, PHY)

3. Limited Mobility: Basic distance calculations, no handover procedures

4. Static Characteristics: Network characteristics are configured, not dynamically calculated from radio conditions

5. No Core Network: No EPC/5GC simulation, only access network characteristics

1. No Protocol Stack: No actual 3GPP protocol simulation (RRC, PDCP, RLC, MAC, PHY)

1. Limited Mobility: Basic distance calculations, no handover procedures

1. Static Characteristics: Network characteristics are configured, not dynamically calculated from radio conditions

1. No Core Network: No EPC/5GC simulation, only access network characteristics

## A.3 Simu5G/SimuLTE Description

<br />

# Annex B: <br>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:

- OAI implements the complete 4G LTE eNB/UE and 5G NR 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:

- For LTE, OAI 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.

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

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

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

### B.2.2 Simulation vs. Real‑Time RF Operation

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.

In simulation mode, the remaining protocol stack, from MAC up to RRC and S1/NG interfaces, is unchanged. This preserves fidelity with respect to signaling, procedures, and buffering behavior, while offering full control over the radio environment and reduced dependency on hardware.

#### B.2.2.1 LTE (4G) Simulation Modes

##### B.2.2.1.1 Introduction

In full PHY emulation, the LTE PHY pipeline (modulation, coding, MIMO mapping, etc.) remains intact. The eNB and UE generate time‑domain baseband samples, which are then processed by a software channel model instead of being sent to a radio front‑end.

- Typical elements of the channel model include:

- Path loss and shadowing;

- Multipath fading (e.g., tapped delay line models);

- Doppler spread and time variation;

- Additive white Gaussian noise (AWGN).

The main drawback is computational complexity: simulating large networks or long time intervals with a full waveform‑level PHY can be expensive, particularly for high bandwidth and MIMO configurations.

![Figure B.2.2.1.1. OAI Simulation Deployment - Single Cell, Multi-UE](media/B.2.2.1.1.Introduction.png)

##### B.2.2.1.2 PHY‑Abstraction Mode

To address scalability, OAI also supports a PHY‑abstraction mode, where the details of waveform generation and decoding are replaced by a statistical error model. Instead of explicitly encoding and decoding each transport block, the emulator derives the block error rate (BLER) based on:

- The selected modulation and coding scheme (MCS);

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

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

- Rapid exploration of scheduling and resource allocation algorithms under varying load and channel conditions.

The trade‑off is that some implementation details are not captured, especially those related to synchronization, channel estimation errors, and non‑idealities in the RF chain.

#### B.2.2.2 NR (5G) Simulation Modes

##### B.2.2.2.1 Introduction

OAI extends the same concept to 5G NR, 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;

- Mobility scenarios with Doppler and time‑varying channels;

- Multi‑antenna configurations for MIMO and beamforming studies.

As with LTE, the NR stack above PHY remains unchanged, so RLC, PDCP, RRC, and NGAP procedures operate as they would in a real deployment. This mode is suitable for:

- Studying NR‑specific features such as flexible TDD patterns, mini‑slots, or numerology selection;

- Evaluating beam management, initial access, and mobility under controlled propagation conditions;

- Testing end‑to‑end NR performance, including 5GC integration, without RF hardware.

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

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

- EPC/5GC entities (MME/AMF, SGW‑U/UPF, PGW‑U, SMF, etc.) run as separate processes or containers;

- Traffic generators produce application flows (e.g., UDP, TCP, HTTP) to exercise user plane paths.

### B.2.x Conclusions

Even if this study does not cover WiFi support, the replacement of the current network simulation with Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) 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 Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) provides the following advantages:

- Accuracy & Realism with:

    - Realistic channel models;

    - Realistic metrics for MEC applications;

- Protocol-Level Simulation with:

    - Complete 3GPP stack (Dynamic, realistic network behavior);

    - Handovers, connection management, and resource allocation work as in real networks;

- Standards Compliance:

    - 3GPP-compliant;

    - Enhanced credibility, interoperability, and future-proofing;

- Advanced Features with:

    - Full 5G NR features → Network slicing, URLLC, eMBB, mMTC;

    - Support for cutting-edge 5G use cases and future requirements;

- Maintainability with

    - Community-supported (Shared maintenance, continuous improvements);

    - Faster feature development;

- Research Value with:

    - Research-grade platform;

    - Enable advanced research, academic collaborations, innovation;

- Business Value with:

    - Industry-standard → Enhanced market position;

    - Competitive advantage, better customer confidence, strategic positioning.

The replacement will be considered successful if:

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

- RNIS APIs maintain backward compatibility;

- Simulation performance meets requirements;

- Real-time emulation works for applications;

- System is stable and production-ready.

---

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

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

>

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

>

> 2. If the network scenario is to complex, the real-time emulation mode cannot be apply and the simulation will not match with real-tme clock.

>

> 3. Regarding the huge amount of work to be done to replace the current network simulation with Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5), the objective of the Task#3 as defined in the STF 707 ToR, could be partially covered. An extension of this STF may be required (or a split with a future STF ?). A list of development steps is proposed in [clause A.4.3](#a43-phase-3-implementation). The 3 first steps are the ones to be achieve during this STF.

>

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

---

> NOTE: In addition, a phase of learning is mandatory before to start the replacement of the current network similation by Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5).

<mark>TODO</mark>

## B.3. Replacement Procedure

<mark>TODO</mark>

<br />

# Annex: Bibliography

@startuml "B.2.1.Introduction.png"

!include etsi-style.iuml

!pragma teoz true

title "Figure B.2.1. OAI 4G/5G Simulation Mode - High-level Components"

package "OAI Simulation Environment" {

  package "RAN Node (eNB/gNB)" as RAN {

    component "L3\n(RRC, NGAP/S1AP)" as RAN_L3

    component "L2\n(PDCP, RLC, MAC)" as RAN_L2

    component "PHY\n(LTE/NR)" as RAN_PHY

  }

  package "UE Node(s)" as UE_SIDE {

    component "UE L3\n(RRC, NAS)" as UE_L3

    component "UE L2\n(PDCP, RLC, MAC)" as UE_L2

    component "UE PHY\n(LTE/NR)" as UE_PHY

  }

  package "RF Simulator / Channel" as RF_SIM {

    component "rfsimulator\n(RF front-end emulator)" as RF_SIMU

    component "Channel Model\n(full PHY / abstraction)" as CH_MODEL

  }

  package "Core Network (optional)" as CORE {

    component "EPC\n(MME, SGW, PGW)" as EPC

    component "5GC\n(AMF, SMF, UPF)" as FIVEGC

  }

  package "Host OS / Runtime" as HOST {

    component "Scheduler / Threads\n(RTAI/RT-POSIX/Std Linux)" as RUNTIME

    component "Config & Scenario\n(XML/CFG, CLI)" as CONFIG

    component "Logging & Tracing\n(pcap, logs, KPIs)" as LOG

  }

}

RAN_L3 --> RAN_L2

RAN_L2 --> RAN_PHY

UE_L3 --> UE_L2

UE_L2 --> UE_PHY

RAN_PHY --> RF_SIMU

UE_PHY --> RF_SIMU

RF_SIMU --> CH_MODEL

RAN_L3 --> EPC : S1-AP\n(4G)

RAN_L2 --> EPC : GTP-U\n(4G)

RAN_L3 --> FIVEGC : NGAP\n(5G)

RAN_L2 --> FIVEGC : GTP-U\n(N3)

RUNTIME .. RAN

RUNTIME .. UE_SIDE

RUNTIME .. RF_SIM

CONFIG .. RAN

CONFIG .. UE_SIDE

LOG .. RAN

LOG .. UE_SIDE

LOG .. RF_SIM

@enduml