editorials

**DECT™**, **PLUGTESTS™**, **UMTS™** and the ETSI logo are trademarks of ETSI registered for the benefit of its Members. **3GPP™**, **LTE™** and **5G™** logo are trademarks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. **oneM2M™** logo is a trademark of ETSI registered for the benefit of its Members and of the oneM2M Partners. **GSM®** and the GSM logo are trademarks registered and owned by the GSM Association.

# Foreword

This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge Computing (MEC).

# Modal verbs terminology

In the present document "**should**", "**should not**", "**may**", "**need not**", "**will**", "**will not**", "**can**" and "**cannot**" are to be interpreted as described in clause 3.2 of the [ETSI Drafting Rules](https://portal.etsi.org/Services/editHelp/How-to-start/ETSI-Drafting-Rules) (Verbal forms for the expression of provisions).

"**must**" and "**must not**" are **NOT** allowed in ETSI deliverables except when used in direct citation.

# 1 Scope

This document covers the integration of Network Emulation Capabilities into the ETSI MEC Sandbox [\[i.1\]] replacing current Linux based network simulation.

It describes the complete work done to replace the current Linux Traffic Control (TC)-based network simulation[[\[i.2\]](#_ref_i.1)] with Simu5G/SimuLTE simulators [[\[i.3\]](#_ref_i.3)], [[\[i.4\]](#_ref_i.4)], [[\[i.5\]](#_ref_i.5)].

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

# 2 References

## 2.1 Normative references

Normative references are not applicable in the present document.

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

> NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

- <span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> [ETSI MEC Sandbox: ](https://labs.etsi.org/rep/mec/mec-sandbox-scenarios/tree/master/Software-Architecture) \"ETSI MEC Sandbox – Software Architecture\".

- <span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> [Linux Traffic Control: ](https://www.linux.org/docs/man8/tc-netem.html) \"NetEm - Network Emulator\".

- <span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> [omnet++: ](https://omnetpp.org/) \"Discrete Event Simulator\".

- <span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> [INet Framework: ](https://inet.omnetpp.org/) \"An open-source OMNeT++ model suite for wired, wireless and mobile networks\".

- <span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> [Simu5G: ](https://simu5g.org/) \"Simulator for 5G New Radio Networks\".

- <span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a> [SUMO: ](https://eclipse.dev/sumo/) \"Simulation of Urban MObility\".

- <span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> [VIENS: ](https://veins.car2x.org/) \"The open source vehicular network simulation framework\".

- <span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> [Docker: ](https://www.docker.com/) \"Docker\".

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

<span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> [ETSI MEC Sandbox: ](https://labs.etsi.org/rep/mec/mec-sandbox-scenarios/tree/master/Software-Architecture) "ETSI MEC Sandbox – Software Architecture".

<span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> [Linux Traffic Control: ](https://www.linux.org/docs/man8/tc-netem.html) "NetEm - Network Emulator".

<span id="_ref_i.3"></span><a name="_ref_i.3">[i.3]</a> [omnet++: ](https://omnetpp.org/) "Discrete Event Simulator".

<span id="_ref_i.4"></span><a name="_ref_i.4">[i.4]</a> [INet Framework: ](https://inet.omnetpp.org/) "An open-source OMNeT++ model suite for wired, wireless and mobile networks".

<span id="_ref_i.5"></span><a name="_ref_i.5">[i.5]</a> [Simu5G: ](https://simu5g.org/) "Simulator for 5G New Radio Networks".

<span id="_ref_i.6"></span><a name="_ref_i.6">[i.6]</a> [SUMO: ](https://eclipse.dev/sumo/) "Simulation of Urban MObility".

<span id="_ref_i.7"></span><a name="_ref_i.7">[i.7]</a> [VIENS: ](https://veins.car2x.org/) "The open source vehicular network simulation framework".

<span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> [Docker: ](https://www.docker.com/) "Docker".

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

# 3 Definition of terms, symbols and abbreviations

<br />

# Annex A: <br>Feasibility study

# Annex A: Feasibility study

<br />

## 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\]]. The current system uses Linux Traffic Control [\[i.2\]] to simulate network characteristics, while Simu5G/SimuLTE simulators [\[i.5\]] are OMNeT++-based discrete event simulators [\[i.3\]] that provide more realistic 3GPP-compliant network behavior.

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?

### A.2.1 Architecture Overview

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

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

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.

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

- WiFi: RSSI (32-77) calculated linearly based on distance

These calculations are done in the component meep-gis-asset-mgr/asset-mgr.go:

```go

// Example: 4G signal calculation

rsrp = minCell4gRsrp + ((maxCell4gRsrp - minCell4gRsrp) * (1 - (distance / radius)))

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\]],

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

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

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 TC Sidecar (`go-apps/meep-tc-sidecar/`): To applies `tc netem` [\[i.2\]] rules to pod network interfaces;

- 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

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

```bash

# TC Sidecar applies Linux traffic control

tc qdisc change dev ifb<id> root netem delay <latency>ms <jitter>ms loss <packetLoss>% rate <throughput>bit

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

The Linux `tc netem` tool [\[i.2\]] adds delay to packets passing through the IFB interface. The delay is applied per packet. The choice of the distribution (normal, uniform, pareto) affects delay variation.

The Linux `tc netem` tool [\[i.2\]](#_ref_i.2) adds delay to packets passing through the IFB interface. The delay is applied per packet. The choice of the distribution (normal, uniform, pareto) affects delay variation.

Regarding the implementation, the latency is managed by the component meep-tc-sidecar:

```go

// TC command applies latency

str := "tc qdisc change dev ifb" + ifbNumber + 

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

The Linux `tc netem` tool [\[i.2\]] rates limiting restricts bandwidth. It applies it as bit rate limit, converting Mbps to bits per second.

The Linux `tc netem` tool [\[i.2\]](#_ref_i.2) rates limiting restricts bandwidth. It applies it as bit rate limit, converting Mbps to bits per second.

Regarding the implementation, the throughput is managed by the component meep-tc-sidecar:

```go

if dataRate != "" && dataRate != "0" {

    str = str + " rate " + dataRate + "bit"

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

It is calculated by the function `calculateThroughput()` in the component meep-gis-engine:

```go

func calculateThroughput(radius float32, distance float32, maxUl int32, maxDl int32) (ul int32, dl int32) {

    if radius == 0 {

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

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

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

Regarding the implementation, the jitter is managed by the component meep-tc-sidecar:

```bash

tc qdisc change dev ifb0 root netem delay 50ms 10ms 50% distribution normal

```

It is calculated by the function `cmdSetIfb()` in the component meep-tc-sidecar:

```go

func cmdSetIfb(shape map[string]string) (bool, error) {

    delayVariation := shape["delayVariation"]

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

The Linux `tc netem` tool [\[i.2\]] randomly drops packets. It is applied per packet independently.

The Linux `tc netem` tool [\[i.2\]](#_ref_i.2) randomly drops packets. It is applied per packet independently.

Regarding the implementation, the jitter is managed by the component meep-tc-sidecar:

```go

str := "tc qdisc change dev ifb" + ifbNumber + 

       " handle 1:0 root netem delay " + delay + "ms " + 

```

It is calculated by the function `compute()` in the component meep-tc-sidecar:

```go

func (u *destination) compute() (st stat) {

    // Calculate packet loss from ping results

- Update Frequency: Based on ping interval (configurable).

The calculation formula is :

```

Latency (ms) = Last RTT (ns) / 1,000,000

```

 It is implemented as follow (component meep-tc-sidecar):

```go

func (u *destination) logRxTx(ifbStatsStr string, curTime time.Time) {

    // Parse IFB statistics

```

The calculation formula is:

```

Throughput (Mbps) = (Bytes_received × 8) / time_seconds / 1,000,000

```

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

The formula is:

```

Packet Loss (%) = (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

flow.ComputedLatency += segment.ConfiguredNetChar.Latency

```

- The throughput aggregation uses the bottleneck principle, i.e. the weakest link: it is the minimum of all segment throughputs:

```go

flow.ComputedThroughput = min(segment.ConfiguredNetChar.Throughput)

```

- The jitter aggregation is the sum of all segment jitters:

```go

flow.ComputedJitter += segment.ConfiguredNetChar.Jitter

```

- The packetLoss aggregation uses probability formula to avoid exceeding 100%:

```go

if flow.ComputedPacketLoss == 0 {

    flow.ComputedPacketLoss = segment.ConfiguredNetChar.PacketLoss

### A.3.1 Overview

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

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.0.x with INET Framework 4.5.x;

- License: LGPL v2.1;

#### A.3.5 Simulation modes

The Simu5G/SimuLTE simulators [\[i.5\]] provides 2 simulations:

The Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) provides 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 5G NR/LTE stack, and return to the real network.

- Performance: Discrete event simulation can be slower than simple TC-based approach

- Complexity: Requires understanding of OMNeT++ and simulation concepts;

- Integration: Need to bridge simulation with Kubernetes/Docker environment ([\[i.9\]], [\[i.8\]]);

- Integration: Need to bridge simulation with Kubernetes/Docker environment ([\[i.9\]](#_ref_i.9), [\[i.8\]](#_ref_i.8));

- Real-Time: Real-time emulation requires careful synchronization;

- WiFi: Limited WiFi support (additional modules are required, particularly ).

### A.3.7 Conclusions

Even if this study does not cover WiFi support, the replacement of the current network simulation with Simu5G/SimuLTE simulators [\[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.

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\]] provides the following advantages:

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;

>

> 1. A network scenario containing a lot of PoAs and UEs can drastically reduce the performance of the Simu5G/4G simulators. The objective of 10 simultaneous connections on the MEC Sandbox could be achieved.

>

> 2. Regarding the huge amount of work to be done to replace the current network simulation with Simu5G/SimuLTE simulators [\[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.

> 2. 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/Simu4G simulators [\[i.5\]].

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

## A.4. Replacement procedure

The purpose is to learn how Simu5G/SimuLTE simulators are working.

##### A.4.1.1.1 Install OMNeT++ 6.0.x/INet Framework 4.x

```bash

# Download the latest package [here](https://omnetpp.org/download/)

# Execute the script `install.sh`

# Install OMNeT++ 6.0.x

```

**Note**: Visit [this link](https://inet.omnetpp.org/Installation.html).

> NOTE: Visit [this link](https://inet.omnetpp.org/Installation.html).

##### A.4.1.1.2 Testing Basic Functionality

- Creating a development environment;

- Creating and simulating a basic example.

**Note**: Visit [this link](https://omnetpp.org/documentation/).

> NOTE: Visit [this link](https://omnetpp.org/documentation/).

##### A.4.1.1.3 Install Simu5G/SimuLTE:

```bash

# Install INET Framework 4.5.x

# Clone and build Simu5G

##### A.4.2.1.1 Design Components

###### A.4.2.1.1.1 Simu5G/SimuLTE Service

- New microservice: `meep-simu5g-engine`

- Runs OMNeT++ simulation in container

- Exposes REST API for scenario control

###### A.4.2.1.1.2 Simulation Adapter

- Converts MEC Sandbox scenarios to Simu5G/SimuLTE configuration

- Maps POAs to gNB/eNodeB

- Maps UEs to simulation UE entities

###### A.4.2.1.1.3 Metrics Bridge

- Extracts metrics from simulation

- Converts to MEC Sandbox format

- Publishes to Redis/InfluxDB

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

- TUN/TAP interfaces for pod connectivity

- Network namespace integration

- Traffic routing between pods and simulation

#### A.4.2.2 Architecture Diagram

```

┌──────────────────────────────────────────────────┐

│              MEC Sandbox Control Plane           │

- Control simulation execution.

Some possible endpoints are:

```go

POST   /api/v1/scenarios/{scenarioId}/start

POST   /api/v1/scenarios/{scenarioId}/stop

- Cloud.

Here are some example of conversion logic:

```go

// Convert MEC Sandbox POA to Simu5G gNB/eNodeB

func convertPOAToGNB(poa *dataModel.NetworkLocation) *Simu5GConfig {

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

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

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

|&lt;Month year>| <#>           |&lt;Changes made>      |

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

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

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

|               |               |                       |

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

|               |               |                       |