@@ -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.
-<spanid="_ref_i.4"></span><aname="_ref_i.4">[i.4]</a> [INet Framework: ](https://inet.omnetpp.org/)\"An open-source OMNeT++ model suite for wired, wireless and mobile networks\".
-<spanid="_ref_i.5"></span><aname="_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:
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
ifdataRate!=""&&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: