Formatting review

The [Annex A](#annex-a-feasibility-study) describes the complete feasibility study done in preparation of the work.

The [Annex B](#annex-b-feasibility-study-for-openairinterface-oai) describes the feasibility study for replacing the current network simulation with OpenAirInterface (OAI) simulator.

# 2 References

## 2.1 Normative references

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

- The TC Sidecar (`go-apps/meep-tc-sidecar/`): To applies `tc netem` [\[i.2\]](#_ref_i.2) rules to pod network interfaces;

- The Network Characteristic Manager (`go-packages/meep-net-char-mgr/`): To aggregates network characteristics along network paths

- The Network Characteristic Manager (`go-packages/meep-net-char-mgr/`): To aggregates network characteristics along network paths.

Regarding the implementation, the TC Sidecar component applies the network characteristics using the following Linux command:

```

The implementation provides also dynamic modulation of the throughput based on the distance. The key points are:

- 5 concentric steps (25% increments)

- Step 0 (0-25% of radius): 100% of max throughput

- Step 1 (25-50% of radius): 75% of max throughput

##### A.2.2.2.4 Jitter calculation

The jitter is set in the scenario configuration files (netChar.latencyVariation in milliseconds and netChar.latencyDistribution). It is applied to:

- Domain level;

- Zone level;

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

The Linux `tc netem` tool [\[i.2\]](#_ref_i.2) adds random variation to delay:

- Delay Variation: Maximum jitter in milliseconds;

- Distribution: How jitter is distributed (Normal, Uniform, Pareto, Paretonormal);

- Correlation: Correlation between consecutive packet delays (0-100%).

##### A.2.2.2.5 Packet loss calculation

The packetLoss is set in the scenario configuration files (netChar.packetLoss in percentage). It is applied to:

- Domain level;

- Zone level;

- Network Location (POA) level;

#### A.2.2.3 Metrics collection

The metrics are stored in two locations via the function `MetricStore.SetCachedNetworkMetric()`:

- Redis: Real-time metrics cache (`<namespace>:metric-store:network:<src>:<dst>`)

- InfluxDB: Historical time-series data (snapshotted every 1 second)

The metrics cover the 4 following networks characteristics:

- Latency (ms);

- Jitter (ms);

- Uplink/Downlink Throughput (Mbps);

The collection method follows these 2 steps:

- TC Sidecar measures actual traffic using IFB (Intermediate Functional Block) statistics

- Metrics stored via `MetricStore.SetCachedNetworkMetric()`

##### A.2.2.3.1 Latency metrics collection

The latency metrics collection key points are:

- Measurement Method: ICMP ping packets sent periodically;

- RTT Storage: Last 50 RTT measurements stored in ring buffer';

- Latency Value: Uses last RTT measurement, no average;

##### A.2.2.3.2 Throughput metrics collection

The throughput metrics collection uses IFB (Intermediate Functional Block) statistics. The key pints are:

- Data Source: IFB interface statistics (`tc -s qdisc show`);

- Measurement: Bytes received over time period;

- Update Frequency: Periodic (based on IFB stats query interval).

The jitter is measured as the standard deviation of RTT measurements, in milliseconds.

The key points are:

- Measurement Method: Standard deviation of RTT measurements;

- Formula: = √(Σ(RTT - mean)/ n);

- Sampling: Last 50TT measurements.

##### A.2.2.3.4 Packet Loss metrics collection

The packetLoss is measured using ICMP ping loss. The key points are:

- Data Source: IFB interface statistics;

- Measurement: Dropped packets / total packets;

- Calculation: (Dropped packets / total packets) × 100;

The network characteristics are aggregated along the network path from source to destination. The path consists of multiple segments (POA, Zone, Domain...). The component meep-net-char-mgr implements the aggregation per segment mechanisms: each network characteristics is aggregated along the network paths (meep-net-char-mgr/algo-segment.go).

Each network characteristics has its own calculation rules:

- The latency aggregation is the sum of all segment latencies:

```go

#### A.2.2.5 RNIS Integration

The component meep-rnis implements the MEC 012 Radio Network Information Service. It's main functionalities are:

- Reads network characteristics from scenario model;

- Retrieves signal measurements (RSRP/RSRQ/RSSI) from GIS cache;

- Calculates UE-level metrics from traffic measurements;

### A.2.3 Conclusion:

The current architecture comes with some limitations:

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

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

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

## A.3 Simu5G/SimuLTE Description

The Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) are open-source, system-level network simulators built on the OMNeT++ [\[i.4\]](#_ref_i.4) discrete event simulation framework. They provide comprehensive simulation of 3GPP-compliant 4G (LTE/LTE-A) and 5G (NR) networks.

The key characteristics are:

- Framework: OMNeT++ 6.3.x with INET Framework 4.5.x;

- License: LGPL v2.1;

- Language: C++;

### A.3.2 SimuLTE (4G/LTE) features

Simu5G provides a full 4G/LTE/LTE-A (E‑UTRAN) data‑plane stack alongside 5GNR, including eNodeB, UE, and core gateway models that support LTE-only and LTE/NR dual-connectivity scenarios with:

- Complete LTE protocol stack (RRC, PDCP, RLC, MAC, PHY);

- EPC (Evolved Packet Core) simulation;

- Support for eNodeB and UE entities;

### A.3.3 Simu5G (5GNR) features

The Simu5G (5GNR) models the full 5GNR user‑plane stack (Rel‑16‑oriented) with gNB, UE, and UPF entities, supporting both Standalone NR and LTE–NR Dual Connectivity deployments over FDD and TDD, with heterogeneous cells and realistic PHY/channel models:

- 5GNR protocol stack (e.g. RLC);

- 5GC (5G Core) simulation;

- Support for gNB and UE entities;

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

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.

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;

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

##### A.4.1.1.2 Testing Basic Functionality

Basically, it includes:

- Studying tutorials;

- Studying NED language;

- Studying Omnet++ APIs;

##### A.4.1.1.4 Testing Basic Functionality

Basically, it includes:

- Studying tutorials;

- Verify 4G/5G simulation capabilities;

- Test MEC integration features.

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

This component is responsible to:

- Manage OMNeT++ simulation lifecycle;

- Convert scenarios to Simu5G/SimuLTE configuration;

- Control simulation execution.

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

A MEC Sandbox scenario contains the following entities:

- Operators;

- UEs;

- POAs;

##### A.4.2.2.3.3 Metrics Bridge

This component is responsible to extract the network metrics:

- Subscribe to OMNeT++ simulation signals;

- Extract RSRP, RSRQ, latency, throughput, packet loss;

- Convert to MEC Sandbox metric format;

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.

Simu5G/SimuLTE simulators use TUN (level 3) integration:

- Create TUN interfaces for each UE pod

- Route traffic through simulation

- Apply simulation delays/losses to real traffic

##### 4.2.2.3.4 Geographics Bridge

This component is responsible to extract the position of the UEs to publish them:

- Subscribe to OMNeT++ simulation signals;

- Extract UEs position;

- Publish them into Redist.

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

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

### B.2.1 Introduction

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;

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

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

Typical elements of the channel model includes:

- Path loss and shadowing;

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

- Doppler spread and time variation;

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

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;

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

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

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:

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.

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

- RNIS APIs maintain backward compatibility;

- Simulation performance meets requirements;

+:==============+:==============+:======================+

| V0.0.1        | January 2026  | Early draft available |

+---------------+---------------+-----------------------+

| V0.0.2        | March 2026    | Early draft stable    |

+---------------+---------------+-----------------------+

|<Month year>| <#>        |<Changes made>      |

+---------------+---------------+-----------------------+

|               |               |                       |