Commit 95223ed0 authored by Yann Garcia's avatar Yann Garcia
Browse files

Start current architecture analysis

parent 7a12198c
Loading
Loading
Loading
Loading
+227 −26
Original line number Diff line number Diff line
@@ -27,7 +27,7 @@ The present document may include trademarks and/or tradenames which are asserted
**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 <long ISGname> (<short ISGname>).
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Multi-access Edge Computing (MEC).


# Modal verbs terminology
@@ -36,19 +36,12 @@ In the present document "**should**", "**should not**", "**may**", "**need not**
"**must**" and "**must not**" are **NOT** allowed in ETSI deliverables except when used in direct citation.


# Executive summary



# Introduction


<br />


# 1 Scope
The present document ...

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

# 2 References

@@ -63,7 +56,12 @@ References are either specific (identified by date of publication and/or edition

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


# 3 Definition of terms, symbols and abbreviations

@@ -83,7 +81,23 @@ For the purposes of the present document, the [following] symbols [given in ...

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:


`5GC     5G Core`
`API     Application Programming Interface`
`eNodeB  Evolved NodeB (4G base station)`
`EPC     Evolved Packet Core`
`gNB     gNodeB (5G base station)`
`GIS     Geographic Information System`
`MEC     Multi-access Edge Computing`
`POA     Point of Access`
`POC     Proof of Concept`
`REST    Representational State Transfer`
`RNIS    Radio Network Information Service`
`RSRP    Reference Signal Received Power`
`RSRQ    Reference Signal Received Quality`
`RSSI    Received Signal Strength Indicator`
`TC      Traffic Control`
`TUN/TAP Network Tunneling Interfaces`
`UE      User Equipment`

# 4 User defined clause(s) from here onwards

@@ -92,11 +106,198 @@ For the purposes of the present document, the [following] abbreviations [given i
<br />


# Annex A: <br>Title of annex
# Annex A: <br>Feasbility 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 are OMNeT++-based discrete event simulators [\[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?
- 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

## A.2. Current Network Simulation Description

### A.2.1 Architecture Overview

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;
2. Network Characteristic Manager: To aggregates netwo: To cracteristics along paths;
3. Traffic Control (TC) Engine: To clies network characteristics to Kubernetes pods;
4. TC Sidecar: To measures actual netwo: To crics from traffic.

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

#### A.2.2.1 The Radio Simulation

The current architecture supports three types of POA:
- POA4G: For 4G/LTE radio access
- POA5G: For 5G NR radio access
- POAWIFI: For WiFi radio access

The Signal Strength Calculation is done as described below:
- 4G: RSRP (40-70) and RSRQ (-2 to 28) calculated linearly based on distance
- 5G: RSRP (42-92) and RSRQ (47-77) calculated linearly based on distance  
- 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)))
```

#### A.2.2.2 Network Characteristics Application

#### A.2.2.2.1 Introduction

The current architecture provides three network characteristics:
- Latency: Configured per segment, aggregated additively;
- Packet Loss: Configured per segment, aggregated using cumulative formula;
- Jitter: Standard deviation of RTT measurements;
- Throughput: Modulated based on distance from POA (5 concentric steps).

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\]],
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: 
- 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 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
```
This command requires:
- The network interface (ifb);
- The calculated latency;
- The calculated throughput;
- The calculated jitter.

##### A.2.2.2.2 Latency calculation

The latency is set in the scenario configuration files (netChar.latency in milliseconds). It is applied to:
- Domain level;
- Zone level;
- Network Location (POA) 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.

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 + 
       " handle 1:0 root netem delay " + delay + "ms " + 
       delayVariation + "ms " + delayCorrelation + "% " + 
       distributionStr + " loss " + loss + "%"
```

##### A.2.2.2.3 Throughput calculation

The throughput is set in the scenario configuration files (netChar.throughputDl and netChar.throughputUl in Mbps). It is applied to:
- Domain level;
- Zone level;
- Network Location (POA) 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.

Regarding the implementation, the throughput is managed by the component meep-tc-sidecar:
```go
if dataRate != "" && dataRate != "0" {
    str = str + " rate " + dataRate + "bit"
}
```

The implementation provides also daynamic 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
- Step 2 (50-75% of radius): 50% 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:
```go
func calculateThroughput(radius float32, distance float32, maxUl int32, maxDl int32) (ul int32, dl int32) {
    if radius == 0 {
        ul = maxUl
        dl = maxDl
    } else if distance < radius {
        // Split into 5 concentric steps (25% increments)
        stepNum := math.Floor(float64(distance) / (float64(radius) * 0.25))
        throughputFraction := 1 - (0.25 * stepNum)
        ul = int32(float64(maxUl) * throughputFraction)
        dl = int32(float64(maxDl) * throughputFraction)
        
        // 0 Mbps not supported
        if ul == 0 {
            ul = 1
        }
        if dl == 0 {
            dl = 1
        }
    }
    return ul, dl
}
```

##### 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 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 caculated by the function `cmdSetIfb()` in the component meep-tc-sidecar:
```go
func cmdSetIfb(shape map[string]string) (bool, error) {
    delayVariation := shape["delayVariation"]
    distribution := shape["distribution"]
    
    distributionStr := ""
    if delayVariation != "0" {
        if distribution != "" {
            if distribution != "uniform" {
                distributionStr = "distribution " + distribution
            }
        } else {
            distributionStr = "distribution normal"
            distribution = "normal"
        }
    }
    
    // TC command with jitter
    str := "tc qdisc change dev ifb" + ifbNumber + 
           " handle 1:0 root netem delay " + delay + "ms " + 
           delayVariation + "ms " + delayCorrelation + "% " + 
           distributionStr + " loss " + loss + "%"
}
```

##### A.2.2.2.5 Packet loss calculation


# Annex B: <br>Title of annex
## B.1 First clause of the annex
@@ -127,14 +328,14 @@ For the purposes of the present document, the [following] abbreviations [given i

# History

+-------------------------------------------------+
+-------------------------------------------------------+
|Document History                                       |
+:==============+:==============+:================+
| Version       | Date          | Milestone       |
+---------------+---------------+-----------------+
+:==============+:==============+:======================+
| V0.0.1        | January 2026  | Early draft available |
+---------------+---------------+-----------------------+
|&lt;Month year>| <#>           |&lt;Changes made>      |
+---------------+---------------+-----------------+
+---------------+---------------+---------------- ------+
|               |               |                       |
+---------------+---------------+-----------------+
+---------------+---------------+-----------------------+
|               |               |                       |
+---------------+---------------+-----------------+
+---------------+---------------+-----------------------+