Finalyse current architecture analysis

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

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

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) describes the complete feasability study done in preparation of the work.

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

# 2 References

# 2 References

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.

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 Sanbox: ](https://labs.etsi.org/rep/mec/mec-sandbox-scenarios/tree/master/Software-Architecture) \"ETSI MEC Sandbox – Software Architecture\".

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

<br />

<br />

# Annex A: <br>Feasbility study

# Annex A: <br>Feasibility study

<br />

<br />

## A.1. Overview

## 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 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\]]. 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 feasibility study covers the following aspects:

This feasibility study covers the following aspects:

- Can the Simu5G/SimuLTE provide more realistic network simulation?

- Can the [Simu5G/SimuLTE]() provide more realistic network simulation?

- Are the impacts on the existing architecture significant?

- Are the impacts on the existing architecture significant?

- What are the benefits?

- What are the benefits?

- Which strategy to conduct the developments needed to replace the current network simulation approach

- 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 conclusion of this study;

- The clause [A.3](#a3-simu5gsimulte-description) covers the Simu5G/SimuLTE simulators [\[i.5\]] and provides the pros and cons of replacing;

- The clause [A.4](#a4-replacement-procedure) covers all the required changes in the current architecture to do the replacement.

## A.2. Current Network Simulation Description

## A.2. Current Network Simulation Description

### A.2.1 Architecture Overview

### 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\]] combines:

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

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

2. Network Characteristic Manager: To aggregates netwo: To cracteristics along paths;

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

3. Traffic Control (TC) Engine: To clies network characteristics to Kubernetes pods;

3. Traffic Control (TC) Engine: To apply network characteristics to Kubernetes pods;

4. TC Sidecar: To measures actual netwo: To crics from traffic.

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

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

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

The current architecture provides three network characteristics:

The current architecture provides three network characteristics:

- Latency: Configured per segment, aggregated additively;

- Latency: Configured per segment, aggregated additively;

- Packet Loss: Configured per segment, aggregated using cumulative formula;

- Jitter: Standard deviation of RTT measurements;

- Jitter: Standard deviation of RTT measurements;

- Throughput: Modulated based on distance from POA (5 concentric steps).

- Throughput: Modulated based on distance from POA (5 concentric steps);

- Packet Loss: Configured per segment, aggregated using cumulative formula.

These network characteristics are calculated and applied at different stages:

These network characteristics are calculated and applied at different stages:

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

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

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

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

4. Aggregation Stage: Characteristics are aggregated along network paths

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\]]. Several components are involved in the simulation: 

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

- 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` rules to pod network interfaces;

- 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

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

- Network Location (POA) level;

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

- Physical Location (UE/Edge) level.

The linux `tc netem` tool 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:

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

```go

```go

- Network Location (POA) level;

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

- Physical Location (UE/Edge) level.

The linux `tc netem` tool 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:

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

```go

```go

}

}

```

```

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

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

- 5 concentric steps (25% increments)

- 5 concentric steps (25% increments)

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

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

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

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

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

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

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

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

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

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

```go

```go

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

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

    if radius == 0 {

    if radius == 0 {

- Network Location (POA) level;

- Network Location (POA) level;

- Physical Location (UE/Edge) level.

- Physical Location (UE/Edge) level.

The linux `tc netem` tool adds random variation to delay:

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

- Delay Variation: Maximum jitter in milliseconds;

- Delay Variation: Maximum jitter in milliseconds;

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

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

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

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

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

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

```

```

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

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

```go

```go

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

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

    delayVariation := shape["delayVariation"]

    delayVariation := shape["delayVariation"]

##### A.2.2.2.5 Packet loss calculation

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

- Physical Location (UE/Edge) level.

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

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

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

       delayVariation + "ms " + delayCorrelation + "% " + 

       distributionStr + " loss " + loss + "%"

```

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

    if (s.received + s.lost) > 0 {

        st.pktLoss = float64(s.lost) / float64(s.received+s.lost)

    } else {

        st.pktLoss = 0

    }

}

```

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

- Uplink/Downlink Packet Loss (%).

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;

- Unit Conversion: Nanoseconds → Milliseconds;

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

The calculation formula is :

```

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

```

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

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

```go

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

    // Parse IFB statistics

    ifbStats := strings.Split(ifbStatsStr, " ")

    curRxBytes, _ = strconv.Atoi(ifbStats[len(ifbStats)-11])

    // Calculate throughput in Mbps

    var tput float64

    rxBytes := curRxBytes - u.prevRxLog.rxBytes

    if rxBytes != 0 {

        timeDiff := curTime.Sub(u.prevRxLog.time).Seconds()

        tput = (8 * float64(rxBytes) / timeDiff) / 1000000

    }

    // Store metric

    metric.UlTput = tput

}

```

The calculation formula is:

```

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

```

##### A.2.2.3.3 Jitter metrics collection

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 ckets / total packets;

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

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

The formula is:

```

Packet Loss (%) = (Dropped Packets / Total Packets) × 100

```

#### A.2.2.4 Aggregation per segment

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

} else if segment.ConfiguredNetChar.PacketLoss != 0 {

    flow.ComputedPacketLoss += (segment.ConfiguredNetChar.PacketLoss * 

                               ((100 - flow.ComputedPacketLoss) / 100))

}

```

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

- Exposes ETSI MEC RNIS APIs.

Some of the network information are calculated (RSRP, RSRQ and RSSI), the other are get from the GIS cache (rssi, rsrp, rsrq and distance). It is implemented in the function `GetAllPoaMeasurements()`.

### A.2.3 Conclusion:

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

# Annex B: <br>Title of annex

# Annex B: <br>Title of annex

## B.1 First clause of the annex

## B.1 First clause of the annex