Add OpenAirInterface feasability study

---

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

### A.3.8 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 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:

## A.4. Replacement procedure

### 4.1 Introduction

### A.4.1 Introduction

This part of the study propose a list of milestone to implement the replacement of the network simulation step by step.

### 4.2 Phase 1: Preparation and Analysis

### A.4.2 Phase 1: Preparation and Analysis

#### A.4.1.1 Learning phase

        └───────────────────────────┘

```

#### 4.2.2.3 Components Design

#### A.4.2.2.3 Components Design

##### 4.2.2.3.1 Simu5G Engine Service (`meep-simu5g-engine`)

##### A.4.2.2.3.1 Simu5G Engine Service (`meep-simu5g-engine`)

This component is responsible to:

- Manage OMNeT++ simulation lifecycle;

POST   /api/v1/scenarios/{scenarioId}/ue/{ueId}/move

```

##### 4.2.2.3.2 Network scenario converter

##### A.4.2.2.3.2 Network scenario converter

The objective is to convert a MEC Sandbox network scenario into an OMNET++ NED description.

A MEC Sandbox scenario contains the following entities:

}

```

##### 4.2.2.3.3 Metrics Bridge

##### A.4.2.2.3.3 Metrics Bridge

This component is responsible to extract the network metrics:

- Subscribe to OMNeT++ simulation signals;

The HTTP REST API mechanism is too slow to be used. The proposal is to use a TCP connection to retrieve the network metrics.

##### 4.2.2.3.4 Real-Time Emulation Bridge

##### A.4.2.2.3.4 Real-Time Emulation Bridge

The Real-Time Emulation Bridge enables real applications to connect to the Simu5G/SimuLTE simulations, allowing them to send and receive packets through the simulated network as if connected to a real 5G/4G radio access network.

The MEC Sandbox GUI will reflects the current positions of the UEs/

##### 4.2.2.3.5 Dockerization

##### A.4.2.2.3.5 Dockerization

This component is responsible to build a dockerzed version of the components describes above [\[i.8\]].

<mark>**To be refined**</mark>

##### 4.2.2.3.6 Kubernetes support

##### A.4.2.2.3.6 Kubernetes support

This component is responsible to automate the creation of a Kubernetes pods [\[i.9\]] to execute the components  described above, including network routing.

<mark>TODO</mark>

#### 4.3.2 Replace TC-based simulation with Simu5G calls

#### A.4.3.2 Replace TC-based simulation with Simu5G calls

<mark>TODO</mark>

<mark>TODO</mark>

#### 4.3.4 Update RNIS

#### A.4.3.4 Update RNIS

<mark>TODO</mark>

#### A.4.3.5 Docker Integration

<mark>TODO</mark>

### A.4.4 Phase 4: Testing and Integration

<mark>TODO</mark>

#### 4.3.5 Docker Integration

### A.4.5 Phase 5: Deployment

<mark>TODO</mark>

### 4.4 Phase 4: Testing and Integration

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

![Figure B.2.2.1.2. OAI Simulation Deployment - Single Cell, Multi-UE](media/B.2.2.1.2.PHY‑Abstraction Mode.png)

#### 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.2.4 real‑time emulators

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

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

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.

<mark>TODO</mark>

### 4.5 Phase 5: Deployment

## B.3. Replacement Procedure

<mark>TODO</mark>

@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