Finalyze document structure, still some TODOs

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

`gNB     gNodeB (5G base station)`

`GIS     Geographic Information System`

`IP      Inyernet Protocol`

`K8S     Kubernetes`

`LTE     Long Term Evolution`

`MEC     Multi-access Edge Computing`

`POA     Point of Access`

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;

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

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

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

- The TC Sidecar (`go-apps/meep-tc-sidecar/`): To applies `tc netem` [\[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:

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

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

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

- 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\]] randomly drops packets. It is applied per packet independently.

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

```go

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

- Data Source: IFB interface statistics;

- Measurement: Dropped ckets / total packets;

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

- Measurement: Dropped packets / total packets;

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

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

The formula is:

<mark>To explain what is NED?</mark>

#### A.3.5.3 Behaviour implementation (C++ classes)

#### A.3.5.3 Behavior implementation (C++ classes)

<mark>To explain behaviour implementation using C++ classes?</mark>

<mark>To explain behavior implementation using C++ classes?</mark>

#### A.3.5.4 Probes

### A.3.7 Limitations of Simu5G/Simu4G simulators

- 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

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

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

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

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

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

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

### A.3.7 Conclusions

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

***

<mark>

The counterpart is a huge changes in the current ETSI MEC Sandbox architecture, and a higher complexity. To support 10 simultaneous connections to the new ETSI MEC Sandbox, a very higher hardware requirements are necessary (CPUs, GPUs & memories).

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

1. A network scenarion containing a lot of PoAs and UEs can drastically reduces the performance of the Simu5G/4G simulators. The objective of 10 simulatanneous conections 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 ?) 

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

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

</mark>

***

**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**: Visit [this link](https://inet.omnetpp.org/Installation.html).

##### A.4.1.1.2 Testing Basic Functionality

- Run example scenarios

- Verify 4G/5G simulation capabilities

- Test MEC integration features

Basically, it includes:

- Studying tutorials;

- Studying NED language;

- Studying Omnet++ APIs;

- Studying simulation;

- Creating a development environment;

- Creating and simulating a basic example.

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

   ```

##### A.4.1.1.4 Testing Basic Functionality

- Run example scenarios

- Verify 4G/5G simulation capabilities

- Test MEC integration features

Basically, it includes:

- Studying tutorials;

- Verify 4G/5G simulation capabilities;

- Test MEC integration features.

### A.4.2 Phase 2: Architecture Design

#### A.4.2.2 Architecture Diagram

```

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

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

│              MEC Sandbox Control Plane           │

│  ┌──────────┐  ┌──────────┐  ┌──────────┐        │

│  │GIS Engine│  │TC Engine │  │RNIS      │        │

│  └────┬─────┘  └────┬─────┘  └────┬──────┘           │

└───────┼─────────────┼─────────────┼──────────────────┘

│  └────┬─────┘  └────┬─────┘  └────┬─────┘        │

└───────┼─────────────┼─────────────┼──────────────┘

        │             │             │

        └─────────────┴─────────────┘

                      │

                      │

        ┌─────────────▼─────────────┐

        │   Metrics Bridge          │

        │   Geographics Bridge      │

        │   (Extract & Publish)     │

        └─────────────┬─────────────┘

                      │

#### 4.2.2.3 Components Design

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

Some possible endpoints are:

```go

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

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

GET    /api/v1/scenarios/{scenarioId}/status

GET    /api/v1/scenarios/{scenarioId}/metrics

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

```

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

- Operators;

- UEs;

- POAs;

- Zones;

- Cloud.

Here are some example of conversion logic:

```go

// Convert MEC Sandbox POA to Simu5G gNB/eNodeB

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

    config := &Simu5GConfig{

        Type: poa.Type_, // POA4G -> eNodeB, POA5G -> gNB

        CellId: getCellId(poa),

        Position: poa.GeoData.Location,

        CarrierFrequency: getFrequency(poa.Type_),

        Bandwidth: getBandwidth(poa.Type_),

    }

    return config

}

// Convert UE to Simu5G UE

func convertUEToSimuUE(ue *dataModel.PhysicalLocation) *Simu5GUE {

    return &Simu5GUE{

        Name: ue.Name,

        Position: ue.GeoData.Location,

        Velocity: ue.GeoData.Velocity,

        Applications: convertApps(ue.Processes),

    }

}

```

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

- Publish the network metrics into Redist and InfluxDB.

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

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

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

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

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

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

### A.4.3 Phase 3: Implementation

#### A.4.3.1 Introduction

All the development steps come with test units, documentation and partial validation.

#### A.4.3.1 Create Simu5G Engine Service

<mark>TODO</mark>

#### A.4.3.2 Create network scenario converter

<mark>TODO</mark>

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

<mark>TODO</mark>

#### 4.3.3 Modify signal strength calculation to use Simu5G

<mark>TODO</mark>

#### 4.3.4 Update RNIS

<mark>TODO</mark>

#### 4.3.5 Docker Integration

<mark>TODO</mark>

### 4.4 Phase 4: Testing and Integration

<mark>TODO</mark>

# Annex B: <br>Title of annex

## B.1 First clause of the annex

## B.1.1 First subdivided clause of the annex

### 4.5 Phase 5: Deployment

<mark>TODO</mark>

<br />