Refine clauses 5.3.x

`RSRP    Reference Signal Received Power`

`RSRQ    Reference Signal Received Quality`

`RSSI    Received Signal Strength Indicator`

`RTT     Round Trip Time`

`TC      Traffic Control`

`TUN/TAP Network Tunneling Interfaces`

`UE      User Equipment`

###### 5.3.2.3.2.1 Focused on real network emulation 

The purpose of this clause is to focus on real network emulation. A real UE is connected to a real server. The emulated 5G network includes a variable number of background cells. The client (at the UE side) pings the server to measure the RTT of the communication.

The purpose is to focus on real network emulation. A real UE is connected to a real server. The emulated 5G network includes a variable number of background cells. The client (at the UE side) pings the server to measure the RTT of the communication.

![Figure 5.3.2.3.2.1: Focused on real network emulation](media/5.3.2.3.2.1.RealNnetworkEmulation.png)

To measure the RTT of the communication, the following command can be used:

- On the server side:

```bash

$ sudo ip netns exec ns2 iperf3 --debug --server --json

```

- On the client side:

```bash

$ sudo ip netns exec ns1 iperf3 --client 192.168.4.2 --udp --bandwidth 10M --time 60 --interval 1 --json

```

To measure the RTT, the following command can be used:

```bash

$ sudo ip netns exec ns1 ping -c 10 192.168.4.1

```

The output looks like this:

```bash

$ sudo ip netns exec ns1 ping -c 10 192.168.4.1

PING 192.168.4.1 (192.168.4.1) 56(84) bytes of data.

64 bytes from 192.168.4.1: icmp_seq=1 ttl=31 time=13.7 ms

64 bytes from 192.168.4.1: icmp_seq=2 ttl=31 time=15.2 ms

64 bytes from 192.168.4.1: icmp_seq=3 ttl=31 time=17.8 ms

64 bytes from 192.168.4.1: icmp_seq=4 ttl=31 time=20.7 ms

64 bytes from 192.168.4.1: icmp_seq=5 ttl=31 time=21.8 ms

64 bytes from 192.168.4.1: icmp_seq=6 ttl=31 time=20.1 ms

64 bytes from 192.168.4.1: icmp_seq=7 ttl=31 time=23.7 ms

64 bytes from 192.168.4.1: icmp_seq=8 ttl=31 time=100 ms

64 bytes from 192.168.4.1: icmp_seq=9 ttl=31 time=24.1 ms

64 bytes from 192.168.4.1: icmp_seq=10 ttl=31 time=23.4 ms

```

The RTT shall be between 10 to 20 milliseconds. when the trafficnis going through the emulated network.

###### 5.3.2.3.2.2 Focused on mixing Simu5G/SimuLTE 

The purpose of this clause is to focus on mixing 4G and 5G PoA combined with network emulation in a single scenario. A single UE is moving between the two PoAs. This example is based on <mark>the E-UTRA/NR Dual Connectivity sample in the Simu5G/SimuLTE repository.</mark> 

The purpose is to focus on mixing 4G and 5G PoA combined with network emulation in a single scenario. A single UE is moving between the two PoAs. This example is based on <mark>the E-UTRA/NR Dual Connectivity sample in the Simu5G/SimuLTE repository.</mark> 

![Figure 5.3.2.3.2.2: Focused on mixing Simu5G/SimuLTE](media/5.3.2.3.2.2.FocusedOnMixingSimu5GSimuLTE.png)

The purpose of this project named 5g-4g-macro is to create a reproducible testbed where a real client application can traverse an emulated access network that includes LTE macro coverage, 5G NR capacity, and real-time packet exchange with external systems.

![Figure 5.3.2.3.2.2.1 Project architecture overview](media/5.3.2.3.2.2.1.ProjectArchitectureOverview.png)

####### 5.3.2.3.2.2.2 Project skeleton

The project skeleton is the following:

![Figure 5.3.2.4.1: SUMO architecture overview](media/5.3.2.4.1.SUMOArchitectureOverview.png)

The SUMO framework provides a Traffic Control Interface giving access to a running road traffic simulation. It allows to retrieve values of simulated objects and to manipulate their behavior on-line. This Traffic Control Interface is a C++ library.

##### 5.3.2.4.2 Focused on vehicular mobility at Monaco

The SUMO framework provides several tools and scripts to import OpenStreetMap (OSM) data and generate a road network. The following tools are available:

The SUMO framework provides one tool to import OpenStreetMap (OSM) data and generate a road network (see [SUMO tutorials](https://sumo.dlr.de/docs/Tutorials/)):

- OSMWebWizard: A web-based tool that offers an easy solutions to start modeling traffic scenarios with SUMO.

**Note:** the link [https://www.openstreetmap.org/export](https://www.openstreetmap.org/export) can also be used to import OSM data.

The SUMO framework provides several tools to generate a road network and manipulate it. The following tools are available:

- `netconvert`: Converts OSM data to a road network.

- `netgenerate`: Generates a road network from a road network file.

- `netedit`: Edits a road network.

- `netconvert`: Converts OSM data to a road network.

- `netgenerate`: Generates a road network from a road network file.

- `netedit`: Edits a road network.

**Note:** the link [https://www.openstreetmap.org/export](https://www.openstreetmap.org/export) can also be used to import OSM data.

The script below creates a sumo road network from the given osm file:

The script creates a sumo road network from the given osm file is osmGet.py:

```bash

$ python3 osmBuild.py --osm-file <osm-file> --vehicle-classes all --pedestrian

$ netconvert --osm-files ./osm/monaco-harbor.osm -o monaco-harbor.net.xml

```

The SUMO road network scenario looks like the following:

The SUMO road network scenario looks like the following (netedit -c osm.netccfg):

![Figure 5.3.2.4.2-1: Monaco Harbor Network scenario](media/monaco-harbor-1.jpg)

The OSM Web Wizard script is a web-based tool that offers an easy solutions to start modeling traffic scenarios with SUMO. The user can specify the area to model graphically through an openstreetmap map excerpt, and configure a randomized traffic demand and run and visualize the scenario in the sumo-gui. To run this tool, the following command must be run:

The OSM Web Wizard script is a web-based tool that offers an easy solutions to start modeling traffic scenarios with SUMO. The user can specify the area to model graphically through an openstreetmap map excerpt, and configure a randomized traffic demand and run and visualize the scenario in the sumo-gui. To run this tool:

![Figure 5.3.2.4.2-2: OSM Web Wizard sript output](media/monaco-harbor-2.jpg)

```bash 

$ python3 $SUMO_ROOT/tools/osmBuild.py --osm-file ./osm/monaco-harbor.osm --vehicle-classes all --pedestrians 

```

##### 5.3.2.4.2.1 Round0: Describe the project

The result is shown below:

##### 5.3.2.4.2.1.1 The network topology

![Figure 5.3.2.4.2-2: OSM Web Wizard sript output](media/monaco-harbor-2.jpg)

The objectives is to create a squeleton of simulation of one vehicular mobility at Monaco harbor.

**Note:** This is the tool used to import the OSM data for the [Monaco Harbor project](https://www.openstreetmap.org/export#map=17/43.734678/7.422370).

The network topology is the following:

###### 5.3.2.4.2.1 Round0: Describe the project

The purpose of this project is to create manually a skeleton of the 4g-5g-macro-v2x MEC sandbox scenario including the following features:

- One POA4G (4G macro cell);

- One POA5G (5G small cell);

- One WiFi access point;

- One high velocity UE (vehicle).

- One low velocity UE (pedestrian).

- One low velocity UE (pedestrian)

- One static UE (e.g. a road-side unit).

For the vehicular mobility, the following is considered:

- There is a handover from the 4G macro cell to the 5G small cell;

- The UEs are moving from the 4G macro cell to the 5G small cell;

- Simu5G/SimuLTE is using the emulation mode to connect the simulated network to the real network;

- iperf3 is used as real application on the UE side and the server side and also to measure network characteristics such as the throughput and the latency (see [Annex A](#annex-a-feasibility-study-for-replacing-the-current-network-simulation-with-simu5gsimulte-simulators)).

The figure below shows the network topology.

**TODO**: To be done

##### 5.3.2.4.2.1.2 The SUMO road network scenario

In addintion of the road network, the SUMO framework requires the "demand modelling" to be defined. The demand modelling describes the car and the pedestrian traffic flow.

**TODO**: To be refined

##### 5.3.2.4.2.1.3 Geospatial coordinates conversions

The geospatial coordinates conversions are the following:

- From the SUMO road network scenario to the Simu5G/SimuLTE simulation;

- From the Simu5G/SimuLTE simulation to the SUMO road network scenario;

- From the SUMO road network scenario to geo-coordinates;

- From the geo-coordinates to the SUMO road network scenario.

**TODO**: To be refined

##### 5.3.2.4.2.2 Round1: Create the project skeleton

###### 5.3.2.4.2.2 Round1: Create the project skeleton

The project skeleton is the following:

```bash

monaco-harbor/

├── docs

├── headers

├── Makefile

├── ned

├── omnetpp.ini

├── README.md

├── routing_files

├── scripts

├── simulations

├── src

├── stats

└── sumo

├── README.md                          Project overview & expected flow

├── omnetpp.ini                        OMNeT++ simulation config (future Simu5G step)

├── Makefile                           Build rules

├── ned/                               NED topology files

├── sumo/

│   ├── README.md                      ← Full SUMO usage guide

│   ├── monaco-harbor.sumocfg          SUMO configuration

│   ├── monaco-harbor.net.xml          Real OSM network (1 796 edges)

│   ├── osm/

│   │   └── monaco-harbor.osm          OSM source data (45 k nodes)

│   ├── demand/

│   │   ├── car.rou.xml                Car route (Ave Kennedy, ~2.5 km)

│   │   ├── pedestrian.rou.xml         Pedestrian walk (harbour promenade)

│   │   └── rsu.add.xml                RSU fixed POI

│   ├── output/

│   │   ├── positions.csv              3 287 rows of TraCI position data

│   │   ├── fcd.xml                    Floating Car Data

│   │   ├── tripinfo.xml               Trip statistics

│   │   └── summary.xml                Network summary

│   └── scripts/

│       ├── generate_routes.py         Demand file generator (sumolib)

│       └── run_simulation.py          TraCI runner + position logger

└── scripts/                           Shell scripts (veth, launch, SUMO start)

```

It assume that OmNet++/INET, Simu5G/SimuLTE and SUMO frameworks are already installed and configured.

To build the project, the following command can be used:

```bash

console #1$ # Run the project

console #1$ clear && make clean && make && make run

```

console #2: Run the iperf3 server on UE-side sim-veth1

console #2$ iperf3 -d -s -B 192.168.a.b -p 5201

###### 5.3.2.4.2.3 Round2: Setup the NED file and the omnetpp.ini file

console #3: Run the iperf3 client on client-side sim-veth2

console #3$ iperf3 -c 192.168.c.d -u -b 10M -t 60 -i 1

```

####### 5.3.2.4.2.3.1 Introduction

The objectives is to setup the NED file and the omnetpp.ini file for the simulation of one vehicular mobility at Monaco harbor.

####### 5.3.2.4.2.3.2 Network topology (NED file)

The network topology is the following:

- One POA5G (5G small cell);

- One WiFi access point;

- One high velocity UE (vehicle).

- One low velocity UE (pedestrian)

- One static UE (e.g. a road-side unit).

For the vehicular mobility, the following is considered:

##### 5.3.2.4.2.3 Round2: Setup the NED file and the omnetpp.ini file

- There is a handover from the 4G macro cell to the 5G small cell;

- The UEs are moving from the 4G macro cell to the 5G small cell;

- Simu5G/SimuLTE is using the emulation mode to connect the simulated network to the real network;

- iperf3 is used as real application on the UE side and the server side and also to measure network characteristics such as the throughput and the latency (see [Annex A](#annex-a-feasibility-study-for-replacing-the-current-network-simulation-with-simu5gsimulte-simulators)).

The NED file that models the network topology is the following:

The NED file models the network topology:

- One LTE eNB;

- One 5G gNB;

- One NAT router;

- One external router/server side for emulation.

The packets go through ExtLowerEthernetInterface, veth pairs, and a NAT router that rewrites addresses so external applications can talk through the simulated network.

The packets go through ExtLowerEthernetInterface, veth pairs, and a NAT router that rewrites addresses so external applications can talk through the simulated network. Here are the different parts of the complete MonacoHarbor.ned file that models the network topology:

1. The Imports sections from INET and Simu5G frameworks and the network declaration;

2. The Simu5G bookkeeping and the 5G infrastructure;

3. The 5G UEs and the WiFi infrastructure.

The figure below shows the network topology described by the NED file. The different network elements are the following:

- In blue: 5G NR User Equipment (ue_car, ue_ped);

- In dark blue: gNodeB (RAN);

- In yellow: 5G Core (UPF, Router);

- In green: WiFi infrastructure (AP, RSU, wifi_srv);

- In purple: Linux namespaces – iperf3 clients;

- In steel blue: Linux namespaces – iperf3 servers;

- In yellow notes: Subnet table / MRT / emulation setup.

The IP plane is the following:

| Subnet | Mask | Role | Nodes |

|--------|------|------|-------|

| 10.0.0.0/24 | 255.255.255.0 | 5G Core backhaul + UE cellular | gNB .3, UPF .4, ue_car .1, ue_ped .2 |

| 10.0.1.0/24 | 255.255.255.0 | UPF ↔ Router (N9) | UPF .1, Router .2 |

| 10.2.0.0/16 | 255.255.0.0 | WiFi internal | RSU .1, wifi_srv .2 |

| 192.168.10.0/24 | 255.255.255.0 | veth car | sim-veth-car .1 ↔ veth-car .2 |

| 192.168.11.0/24 | 255.255.255.0 | veth pedestrian | sim-veth-ped .1 ↔ veth-ped .2 |

| 192.168.20.0/24 | 255.255.255.0 | veth 5G server | router ↔ ns_srv |

| 192.168.21.0/24 | 255.255.255.0 | veth WiFi server | wifi_srv ↔ ns_wifi |

| 192.168.30.0/24 | 255.255.255.0 | veth RSU | rsu ↔ ns_rsu |

The network path is the following:

- 5G/LTE path: ue_car + ue_ped  ──  NR  ──  gnb ── ppp ── upf ── ppp ── router

- WiFi path:      rsu (STA)     ── 802.11──  ap  ── 802.11 ──  wifi_srv (STA)

![Figure 5.3.2.4.2.3-1: Monaco Harbour – Telecom Network Architecture](media/5.3.2.4.2.3-1.NetworkTopology.png)

####### 5.3.2.4.2.3.3 The configuration file (omnetpp.ini file)

The omnetpp.ini file is structured as described below:

- A General section:

  - Network declaration (monaco_harbor.MonacoHarbor, sim-time-limit = 300s);

  - Real-time scheduler (inet::RealTimeScheduler);

  - Statistics output paths (.sca/.vec);

  - The geographic coordinate system block with sceneLatitude = 43.734042deg / sceneLongitude = 7.416587deg, followed by the start of the OSM canvas visualizer configuration;

- A Visualizer section:

  - Mobility trail visualizer flags;

  - Radio medium display (transmissions/receptions);

  - Network route arrows;

  - Data link labels;

  - Ipv4NetworkConfigurator binding to routing/demo.xml with all auto-route additions disabled;

  - Constraint area (0–1017 m × 0–638 m);

  - PHY/AMC parameters (NrAmc, ROBUST_CQI, targetBler = 0.01);

  - The start of 5G NR carrier aggregation (band n78, numerologyIndex = 1, numBands = 25);

- A UE section:

  - UE channel models;

  - Node GPS positions;

  - Per-UE carrier module assignment;

  - ServingNodeId/nrServingNodeId = 1 for both UEs;

  - The GPS→XY conversion formula comment block;

  - The gNodeB stationary GPS placement (43.7310°N 7.4228°E, altitude 30 m);

  - The ue_car's LinearMobility starting at XY (73.4, 227.3) at 14 m/s heading 89°;

  - The start of ue_ped placement;

- A WiFi section:

  - Remaining node positions;

  - WiFi PHY ue_ped mobility (XY 137.8, 539.0 at 1.4 m/s, heading 79°);

  - WiFi AccessPoint stationary GPS (43.7304°N 7.4219°E);

  - RSU stationary GPS (same quay, altitude 1.5 m);

  - wifi_srv stationary GPS;

  - Full WiFi 802.11n PHY parameters for AccessPoint (SSID MonacoHarbor-WiFi, channel 5.18 GHz, TX power 100 mW, sensitivity −90 dBm) and RSU STA (Ieee80211MgmtSta, 20 mW, −85 dBm).

###### 5.3.2.4.2.4 Round3: Describe the SUMO road scenario

The Monaco’s map built in [clause 5.3.2.4.2](#53242-focused-on-vehicular-mobility-at-monaco) contains features that can confuse traffic simulation if imported blindly:

- Very short roads and tiny junctions;

- Tunnels or service roads;

- Pedestrian-only paths or steps;

- Complex port access roads.

Because our goal is to demonstrate Simu5G/SUMO mobility around Monaco harbor, we do not need the whole principality at first. let's start with a small, well-shaped harbor network, verify mobility and handovers. To do so, the following procedure applies:

1. Crop Monaco OSM to Port Hercule and nearby roads;

2. Import with netconvert;

3. Open in netedit and simplify the road graph;

4. Export monaco_harbor.net.xml;

5. Generate routes on the resulting network.

![Figure 5.3.2.4.2.3: NED file](media/5.3.2.4.2.3.NEDFile.png)

```bash

netconvert --osm-files osm/monaco-harbor.osm --output-file monaco-harbor.net.xml --geometry.remove --roundabouts.guess --tls.guess-signals --tls.discard-simple --tls.join --no-turnarounds --remove-edges.isolated --osm.sidewalks --ignore-errors

```

The INI file sets the simulation parameters:

- One SUMO-driven UE;

- Dual connectivity between LTE and 5G;

- Real-time emulation through veth/NAT;

- Room for handover testing.

The result is shown below (netedit monaco-harbor.net.xml):

##### 5.3.2.4.2.4 Round3: Describe the SUMO road scenario

![Figure 5.3.2.4.2.1.2: OSM Web Wizard sript output](media/monaco-harbor-3.jpg)

The purpose is to define the road graph so vehicles circulate around the port basin and along the quay roads, with a loop that repeatedly crosses the LTE/5G overlap area. That is ideal for handover testing because the UE alternates between stronger LTE and stronger 5G zones.

###### 5.3.2.4.2.5 Round4: Execute and debug the first simulation

**TODO**: To be refined

The figure below describes the current project architecture overview:

##### 5.3.2.4.2.5 Round4: Execute and debug the first simulation

![Figure 5.3.2.4.2.5-1: Project architecture overview](media/5.3.2.4.2.5-1.ProjectArchitectureOverview.png)

The purpose of this clause is to execute and debug the first simulation.

The first step is to start the simulation manually:

The purpose is to execute and debug the first simulation.

The steps to follow are:

1. Setup the veth;

2. Start the the SUMO simulation;

3. ???

4. Start the iperf3 server on UE-side sim-veth1;

5. Start the iperf3 client on client-side sim-veth2;

6. Verify that the traffic is flowing through the simulated network;

7. Terminate the simulation;

8. Delete the veth.

The second step is to start the simulation using the Makefile:

2. Start the simulation;

3. Start the iperf3 server on UE-side sim-veth1;

4. Start the iperf3 client on client-side sim-veth2;

5. Verify that the traffic is flowing through the simulated network;

6. Terminate the simulation;

7. Delete the veth.

The command to start the simulation using the Makefile is the following:

```bash

$ source ./scripts/setenv-simu5g.sh

$ clear && make clean && make && make run

```

**Note:** The traffic simulation is generated in separated consoles.

To verify the traffic simulation the following procedures can be used:

1. Verify that the traffic is flowing through the simulated network;

2. Verify that the RTT is between 10 to 20 milliseconds;

3. Verify that the throughput is between 10 to 20 Mbps;

4. Verify that the packet loss is 0%;

5. Verify that the jitter is 0%.

<mark>

Currently, we are blocked her with the following error:

```bash

<!> Error: Failed to find address prefix (using 10.2.0.0 with specified bits 255.255.255.0) and netmask (length from 24 bits to 24 bits) for interface MonacoHarbor.rsu.eth0 and 0 other interface(s). Please refine your parameters and try again! -- in module (inet::Ipv4NetworkConfigurator) MonacoHarbor.configurator (id=5), during network initialization

terminate called after throwing an instance of 'omnetpp::cRuntimeError'

  what():  No such gate or gate vector: 'upperLayerOut'

Stack trace (most recent call last):

#22   Object "", at 0xffffffffffffffff, in 

#21   Object "", at 0x648f24f097f4, in 

#20   Object "", at 0x7648b4429e3f, in 

#19   Object "", at 0x7648b4429d8f, in 

#18   Object "", at 0x7648b59ba582, in 

#17   Object "", at 0x7648b59b9377, in 

#16   Object "", at 0x7648b59bf2d0, in 

#15   Object "", at 0x7648b59c1d62, in 

#14   Object "", at 0x7648b5a30bc6, in 

#13   Object "", at 0x7648b52d2f15, in 

#12   Object "", at 0x7648b52991fb, in 

#11   Object "", at 0x7648b5299469, in 

#10   Object "", at 0x7648b52991fb, in 

#9    Object "", at 0x7648b529998b, in 

#8    Object "", at 0x7648adbb0dbd, in 

#7    Object "", at 0x7648adbb0d80, in 

#6    Object "", at 0x7648ada284ea, in 

#5    Object "", at 0x7648b48ae276, in 

#4    Object "", at 0x7648b48ae20b, in 

#3    Object "", at 0x7648b48a2b9d, in 

#2    Object "", at 0x7648b44287f2, in 

#1    Object "", at 0x7648b4442475, in 

#0    Object "", at 0x7648b44969fc, in 

Aborted (Signal sent by tkill() 323438 1000)

scripts/run_omnetpp.sh: line 65: 323438 Aborted                 (core dumped) opp_run -l "$INET_LIB/INET" -l "$SIMU5G_LIB/simu5g" -u "$(echo "$UI" | awk '{print toupper(substr($0,1,1)) tolower(substr($0,2))}')" --record-eventlog=true --sim-time-limit=1200s -c General -n "$NED_PATH" omnetpp.ini

make: *** [Makefile:59: run] Error 134

```

</mark>

###### 5.3.2.4.2.6 Round5: Adding LTE POA into the project

The purpose is to add the LTE POA into the project.

##### 5.3.2.4.2.6 Round5: Conclusion

**TODO**: To be refined

###### 5.3.2.4.2.7 Round6: Conclusion

Getting this simulation working and the traffic flowing through the simulated network is a major milestone. It validates the feasibility of the new network simulation approach to replace the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1).

**Note 2:** Do not forget to add SUMO environment variables to the shell profile.

**Note 3:** <mark>The geospatial coordinates conversions are the following:

- From the SUMO road network scenario to the Simu5G/SimuLTE simulation;

- From the Simu5G/SimuLTE simulation to the SUMO road network scenario;

- From the SUMO road network scenario to geo-coordinates;

- From the geo-coordinates to the SUMO road network scenario.

</mark>

**TODO**: To be refined

#### 5.3.2.5 Veins learning

#### 5.3.2.5.1 Veins architecture overview

#### 5.3.2.5.2 Enhance monaco-harbor project with Veins

The purpose of this clause is to enhance the monaco-harbor project with Veins.

The purpose is to enhance the monaco-harbor project with Veins.

**TODO**

#### 5.3.2.6 Gathering network information

The purpose of this clause is to gather the network information from the simulation. The network information element are the one described by the ETSI MEC 012 [\[i.5\]](#_ref_i.5) and ETSI MEC 013 [\[i.6\]](#_ref_i.6):

The purpose is to gather the network information from the simulation. The network information element are the one described by the ETSI MEC 012 [\[i.5\]](#_ref_i.5) and ETSI MEC 013 [\[i.6\]](#_ref_i.6):

- S1 bearer information;

- RAB information;

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

|               |               |                       |

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

//

// Monaco Harbour – Joint Simu5G / INET emulation network

//

// Topology

// ────────

//   5G/LTE path  : ue_car + ue_ped  ──NR──  gnb ──ppp── upf ──ppp── router

//   WiFi path    : rsu (STA)  ──802.11──  ap  ──802.11──  wifi_srv (STA)

//

// Emulation (real applications via veth pairs)

// ─────────────────────────────────────────────

//   sim-veth-car  ↔  ue_car.eth[0]   (ExtLowerEthernetInterface)

//   sim-veth-ped  ↔  ue_ped.eth[0]   (ExtLowerEthernetInterface)

//   sim-veth-rsu  ↔  rsu.eth[0]      (ExtLowerEthernetInterface)

//   sim-veth-srv  ↔  router.eth[0]   (ExtLowerEthernetInterface)  5G server side

//   sim-veth-wifi ↔  wifi_srv.eth[0] (ExtLowerEthernetInterface)  WiFi server side

//

// IP addressing

// ─────────────

//   10.0.x.x  – internal 5G core  (gnb, upf, router ppp links)

//   10.2.0.x  – WiFi network       (rsu.wlan=10.2.0.1, wifi_srv.wlan=10.2.0.2)

//   10.0.0.x  – UE cellular IPs   (managed by Simu5G binder)

//   192.168.10.x – car ext subnet

//   192.168.11.x – ped ext subnet

//   192.168.20.x – 5G server subnet

//   192.168.21.x – WiFi server subnet

//   192.168.30.x – RSU ext subnet

//