Learning Simu5G/SimuLTE

<span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a>[OpenAirInterface: ](https://www.openairinterface.org/) "OpenAirInterface".

<span id="_ref_i.11"></span><a name="_ref_i.11">[i.11]</a>[PlantUML: ](https://plantuml.com/) "PlantUML".

<span id="_ref_i.12"></span><a name="_ref_i.12">[i.12]</a>[iperf3: ](https://iperf.fr/) "iperf3 client/server".

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

`TC      Traffic Control`

`TUN/TAP Network Tunneling Interfaces`

`UE      User Equipment`

`UML     Unified Modeling Language`

# 4 Feasibility study conclusions

The [Annex A](#annex-a-feasibility-study-for-replacing-the-current-network-simulation-with-simu5gsimulte-simulators) presents the feasibility of replacing the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1) with Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5).

The [Annex B](#annex-b-feasibility-study-for-replacing-the-current-network-simulation-with-openairinterface-oai-simulator) feasibility study presents the feasibility of replacing the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1) with OpenAirInterface (OAI) simulator [\[i.10\]](#_ref_i.10).

During the ISG MEC meeting #45, the feasibility studies where introduced to the group. The group concludes that the Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5) are a good alternative to the current network simulation approach in the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1).

# 5 Development plan

## 5.1 Introduction

The network simulation approach and the UE mobility in the ETSI MEC Sandbox [\[i.1\]](#_ref_i.1) is based on Simu5G/SimuLTE [\[i.5\]](#_ref_i.5), Veins  [\[i.7\]](#_ref_i.7) for radio/core and vehicular mobility, SUMO [\[i.6\]](#_ref_i.6) for traffic.

## 5.2 Development methodology

### 5.2.1 Principles

The development plan proposed in this document is inspired by Agile methodology. The development will be conducted in rounds of developments. Each round will be focused on a specific feature or functionality. The rounds will be conducted in the following order:

- Round 0: Learning the Simu5G/SimuLTE and Veins/SUMO;

- Round 1: Architecture and Spikes. The objective is to validate the feasibility, and to create the skeletons;

- Round 2: Simu5G/SimuLTE + Veins + SUMO integration. The objective is to build a reliable vehicular and cellular scenario that represents what the MEC Sandbox scenario used to do. This;

- Round 3: Simulation Adapter (Go/Python <-> OMNeT++). The objective is to expose the new simulator as a clean “MEC Simulation Service” usable by the MEC platform and MEC applications;

- Round 4: MEC integration and parity with old Sandbox. the objective is to replicate the observable behavior that MEC Location/RNIS/AMS/etc. saw from the old Monaco simulator;

- Round 5: Network characteristcs measurements. The objective is to measure the network characteristics and to compare them with the expected measurements;

- Round 6: Use demo1/demo2 based of iperf3 to verify the network characteristcs measurements and the values exposed by MEC RNIS and Location services;

- Round 7: Verify that all demo applications and tutorials are working with the new network simulator.

**Note 1:** Rounds can be divided in several sub-rounds to facilitate the tasks distribution between developers.

**Note 3:** A round is achieved when all the sub-rounds are completed successfully.	

**Note 2:** No round will be conducted if the previous round is not completed successfully.

**Note 4:** The development plan is not exhaustive and can be updated during the development proces.

### 5.2.2 Documentation rules

The documentation follows the standards in this area: 

- Code: Doxygen comments in C++ (OMNeT++/Simu5G), Go, and Python;

- UML Diagrams: Use of PlantUML language [\[i.11\]](#_ref_i.11);

- Design & Development Documentation: Use of Markdown language [\[i.12\]](#_ref_i.12).

The documentation is maintained during the whole development process.

### 5.2.3 Testing rules

The testing will be conducted using the following principles:

- Use of unit tests;

- Use of integration tests;

- Use of system tests;

- Use of performance tests;

- Use of stress tests;

- Use of load tests;

- Use of scalability tests;

The test campaigns are conducted at the end of each round or sub-rounds of development. Test reports will be part of the development documentation.

### 5.2.4 Deployment

The deployment will be conducted using the following principles:

**TODO**

## 5.3 Round 0: Learning the Simu5G/SimuLTE and Veins/SUMO frameworks

### 5.3.1 Introduction

The purpose of this round is to learn the Simu5G/SimuLTE and Veins/SUMO. It is a prerequisite to prepare the next round.

### 5.3.2 Local development environment

The local development environment is based on the following:

- OMNeT++ [\[i.3\]](#_ref_i.3): The current version is omnetpp-6.3.0-linux-x86_64.tgz. 

- INet Framework: [\[i.4\]](#_ref_i.4): The current version is net-6.3.0-linux-x86_64.tgz.

- Simu5G/SimuLTE: [\[i.5\]](#_ref_i.5): The current version is simu5g-1.4.3-src.tgz

- Veins: [\[i.7\]](#_ref_i.7): The current version is **TODO**

- SUMO: [\[i.6\]](#_ref_i.6): The current version is **TODO**

#### 5.3.2.1 OMNeT++ learning

##### 5.3.2.1.1 OMNeT++ Core Architecture Overview

The figure below shows the OMNeT++ 6.x - Core Architecture Overview.

![Figure 5.3.2.1.1: OMNeT++ 6.x - Core Architecture Overview](media/55.3.2.1.1.Introduction.png)

##### 5.3.2.1.2 NED language

The NED language is the language used to describe the network topology and the modules.

The figure below shows the NED language.

![Figure 5.3.2.1.2: NED language](media/5.3.2.1.2.NED.png)

##### 5.3.2.1.3 Installation

The procedure to install OMNeT++ is the following:

```bash

$ tar xvjf omnetpp-6.3.0-linux-x86_64.tgz

$ cd omnetpp-6.3.0

$ ./install.sh

$ source ./setenv

```

##### 5.3.2.1.4 Notes

**Note 1:** Use OMNeT++ online documentation to learn the basics of OMNeT++.

**Note 2:** Use 'install.sh' script to install OMNeT++ and compile the samples.

**Note 3:** Do not forget to add OMNeT++ environment variables to the shell profile.

**Note 4:** Using aloha sample in command line:

```bash

$ cd omnetpp-6.3.0/samples/aloha

$ ./aloha -u Cmdenv -f ./omnetpp.ini --Aloha.numHosts=2 --Aloha.host[0].iaTime=1s --Aloha.host[1].iaTime=1s

$ opp_scavetool export -F csv results/*.vec -o aloha_results.csv

```

**Note 5:** The file .oppfeatures contains some project features that can be added or removed to optimize the building project time. Modifying this file required a rebuild of OMNeT++ (see [Installation](#53213-installation) clause).

#### 5.3.2.2 INET Framework

##### 5.3.2.2.1 INET Framework architecture

The figure below shows the INET Framework architecture.

![Figure 5.3.2.2.1: INET Framework architecture](media/5.3.2.2.1.INETFramework.png)

##### 5.3.2.2.2 Focus on a real application in a simulated network node

The INET Framework includes several emulation examples that bridge simulated networks with real systems. These demonstrate real packet I/O, TCP/UDP bridging, and live traffic integration for realistic testing of protocols/applications.

This clause is focused on the sender host (VLC player) and the receiver host (VLC receiver). The figure below shows the example architecture. The example <inet>/examples/emulation/videostreaming demonstrates a real application in a simulated network node. In this example, a camera (VLC player) is connected to a simulated network (Wi-Fi AP + wired backbone) and a video stream is streamed to a real display, a VLC receiver. The figure below shows the example architecture.

![Figure 5.3.2.2.2: INET Framework emulation example](media/5.3.2.2.2.INETFrameworkEmulationExample.png)

##### 5.3.2.2.3 Installation

The procedure to install INET Framework is the following:

```bash

$ sudo apt-get install libavcodec-dev libavformat-dev libavresample-dev libavutil-dev

$ source <omnetpp-6.3.0>/setenv

$ tar xvjf inet-4.6.0-src.tgz

$ cd inet4.6

$ make

```

##### 5.3.2.2.3 Notes

# 4 User defined clause(s) from here onwards

**Note 1:** Use INet Framework online documentation to learn the basics of INet Framework.

**Note 2:** Building INET and samples take a lot of time.

**Note 3:** Do not forget to add INET Framework environment variables to the shell profile.

**Note 4:** Using aloha sample in command line:

```bash

$ cd inet4.6/examples/wireless/wiredandwirelesshostswithap

$ inet -u Cmdenv -n .:../../../src/inet ./omnetpp.ini

$ opp_scavetool export -F csv results/*.vec -o wiredandwirelesshostswithap_results.csv

```

**Note 5:** The file .oppfeatures contains some project features that can be added or removed to optimize the building project time. Modifying this file required a rebuild of INET Framework (see [Installation](#53223-installation) clause).

```bash

$ opp_featuretool list | grep NetworkEmulationSupport

$ opp_featuretool enable NetworkEmulationSupport

$ opp_featuretool list | grep NetworkEmulationSupport

$ make clean && make

```

#### 5.3.2.3 Simu5G/SimuLTE learning

##### 5.3.2.3.1 Simu5G/SimuLTE Architecture Overview

The figure below shows the Simu5G/SimuLTE architecture overview.

![Figure 5.3.2.3.1: Simu5G/SimuLTE architecture overview](media/5.3.2.3.1.Simu5GSimuLTEArchitectureOverview.png)

##### 5.3.2.3.2 Focuseds on Simu5G/SimuLTE 

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

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

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

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

####### 5.3.2.3.2.2.1 Project architecture overview

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:

```bash

./5g-4g-macro/

├── bin

├── docs

├── headers

│   └── macro_controller.hh

├── Makefile

├── ned

│   ├── FiveG4GMacroEndc.ned

│   └── package.ned

├── omnetpp.ini

├── README.md

├── results

├── scripts

│   ├── build.sh

│   ├── run.sh

│   └── setup-emulation.sh

└── src

    ├── app.cc

    └── macro_controller.cc

```

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

```bash	

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

```

The content of the .ned file is the following:

####### 5.3.2.3.2.2.3 Adding real network emulation

Console #1: Run the project

```bash

$ make run

```

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

```bash

$ iperf3 -d -s -B 192.168.3.1 -p 5201

```	

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

```bash	

$ iperf3 -c 192.168.3.1 -u -b 10M -t 60 -i 1

```

##### 5.3.2.3.4 Installation

The procedure to build Simu5G/SimuLTE is the following:

```bash	

$ # First, source onmet++ and inet frameworks environment variables

$ tar xvzf ~/dev/simu5g-1.4.3-src.tgz 

$ cd Simu5G-1.4.3/

$ make makefiles

$ make

```

##### 5.3.2.3.5 Notes

**Note 1:** Use Simu5G/SimuLTE online documentation to learn the basics of Simu5G/SimuLTE.

**Note 2:** Set executable rights on setenv file.

**Note 3:** Do not forget to add OMNeT++ environment variables to the shell profile.

**Note 4:** Using tutorial sample in command line:

```bash

$ cd Simu5G-1.4.3/tutorials/tutorial

$ clear && simu5g --record-eventlog=true --sim-time-limit=20s -u Cmdenv -c Single-UE -f ./omnetpp.ini

$ opp_scavetool export -F csv results/Single-UE/*.vec -o tutorial_results.csv

```

**Note 5:** The file .oppfeatures contains some project features that can be added or removed to optimize the building project time. Modifying this file required a rebuild of Simu5G/SimuLTE Framework (see [Installation](#53234-installation) clause).

#### 5.3.2.4 SUMO learning

##### 5.3.2.4.1 SUMO Architecture Overview

The figure below shows the SUMO architecture overview.

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

##### 5.3.2.4.4 Installation

The procedure to install SUMO is the following:

```bash

$ tar xvzf ~/dev/sumo-src-1.25.0.tar.gz

$ cd sumo-src-1.25.0

$ ./configure

$ make

$ make install

```

##### 5.3.2.4.5 Notes

**Note 1:** Use SUMO online documentation to learn the basics of SUMO.

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

**Note 3:** Using tutorial sample in command line:

```bash

$ cd sumo-src-1.25.0/tutorials/tutorial

$ sumo-gui

```

#### 5.3.2.5 Viens learning

## 5.4 Round 1: Architecture and Spikes

### 5.4.1 Introduction

The purpose of this round is:

1. To create a reproducible environment to validate the feasibility of the new network simulation approach;

2. To create the skeletons of the new network simulation approach;

### 5.4.2 Local development environment

**TODO**

## 5.5 Round 2: Simu5G/SimuLTE + Veins + SUMO integration

**TODO**

## 5.6 Round 3: Simulation Adapter (Go/Python <-> OMNeT++)

**TODO**

## 5.7 Round 4: MEC integration and parity with old Sandbox

**TODO**

## 5.8 Round 5: Network characteristcs measurements

**TODO**

## 5.9 Round 6: Use demo1/demo2 based of iperf3 to verify the network characteristcs measurements and the values exposed by MEC RNIS and Location services

**TODO**

## 5.10 Round 7: Verify that all demo applications and tutorials are working with the new network simulator

**TODO**

## 4.1 User defined subdivisions of clause(s) from here onwards

<br />

<mark>To explain how to use the probes?</mark>

#### A.3.7.5 ETS MEC Support in Simu5G

<mark>To explain ETS MEC support in Simu5G?</mark>

#### A.3.7.6 Why do we choose the Probes solution?

<mark>To explain why do we choose Probes mechanism isnstead of Simu5G MEC RNI?</mark>

#### A.3.7.5 How to develop a UE application in Simu5G environment

<mark>Not sure this clause is useful at this stage</mark>

### A.3.8 Advantages of Simu5G/SimuLTE simulators

- Realistic Protocol Simulation: Complete 3GPP protocol stack

> NOTE: In addition, a phase of learning is mandatory before to start the replacement of the current network similation by Simu5G/SimuLTE simulators [\[i.5\]](#_ref_i.5).

## A.4. Replacement procedure

### A.4.1 Introduction

This part of the study propose a list of milestone to implement the replacement of the network simulation step by step.

### A.4.2 Phase 1: Preparation and Analysis

#### A.4.1.1 Learning phase

The purpose is to learn how Simu5G/SimuLTE simulators are working.

##### A.4.1.1.1 Install OMNeT++ 6.0.x/INet Framework 4.x

```bash

# Download the latest package [here](https://omnetpp.org/download/)

# Execute the script `install.sh`

# Execute `source setenv`

# Run the IDE `omnetpp`

# Install OMNeT++ 6.0.x

```

> NOTE: Visit [this link](https://inet.omnetpp.org/Installation.html).

##### A.4.1.1.2 Testing Basic Functionality

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.3 Install Simu5G/SimuLTE:

```bash

# Install INET Framework 4.5.x

# Clone and build Simu5G

git clone https://github.com/Unipisa/Simu5G.git

cd Simu5G

make

```

##### A.4.1.1.4 Testing Basic Functionality

Basically, it includes:

- Studying tutorials;

- Verify 4G/5G simulation capabilities;

- Test MEC integration features.

### A.4.2 Phase 2: Architecture Design

#### A.4.2.1 Integration Architecture

##### A.4.2.1.1 Design Components

###### A.4.2.1.1.1 Simu5G/SimuLTE Service

- New microservice: `meep-simu5g-engine`

- Runs OMNeT++ simulation in container

- Exposes REST API for scenario control

###### A.4.2.1.1.2 Simulation Adapter

- Converts MEC Sandbox scenarios to Simu5G/SimuLTE configuration

- Maps POAs to gNB/eNodeB

- Maps UEs to simulation UE entities

###### A.4.2.1.1.3 Metrics Bridge

- Extracts metrics from simulation

- Converts to MEC Sandbox format

- Publishes to Redis/InfluxDB

###### A.4.2.1.1.4 Real-Time Emulation Bridge

- TUN/TAP interfaces for pod connectivity

- Network namespace integration

- Traffic routing between pods and simulation

#### A.4.2.2 Architecture Diagram

```

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

│              MEC Sandbox Control Plane           │

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

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

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

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

        │             │             │

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

                      │

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

        │   Simulation Adapter      │

        │  (Scenario Converter)     │

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

                      │

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

        │   Simu5G/SimuLTE Engine   │

        │   (OMNeT++ Simulation)    │

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

                      │

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

        │   Metrics Bridge          │

        │   Geographics Bridge      │

        │   (Extract & Publish)     │

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

                      │

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

        │   Redis / InfluxDB        │

        └───────────────────────────┘

```

#### A.4.2.2.3 Components Design

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

```

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

    }

}

```

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

##### A.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/SimuLTE 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/

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

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

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

#### A.4.3.4 Update RNIS

<mark>TODO</mark>

#### A.4.3.5 Docker Integration

<mark>TODO</mark>

### A.4.4 Phase 4: Testing and Integration

<mark>TODO</mark>

### A.4.5 Phase 5: Deployment

<mark>TODO</mark>

<br />

# Annex B: Feasibility study for replacing the current network simulation with OpenAirInterface (OAI) simulator

## B.1. Overview

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

--

## B.3. Replacement Procedure

<mark>TODO</mark>

<br />

@startuml "5.3.2.1.1.Introduction.png"

!include etsi-style.iuml

!pragma teoz true

title "Figure 5.3.2.1.1: OMNeT++ 6.x - Core Architecture Overview"

package "OMNeT++ Simulation Kernel" {

  class cSimulation {

    +run()

    +getModuleByPath(path)

    +getSystemModule() : cModule

  }

  class cModule {

    +initialize()

    +handleMessage(cMessage*)

    +finish()

    +scheduleAt(simtime_t, cMessage*)

  }

  class cSimpleModule extends cModule {

    +handleMessage(cMessage*)

    +initialize(int stage)

  }

  class cChannel {

    +getDelay() : simtime_t

    +getDatarate() : double

  }

  class cMessage {

    +getKind() : int

    +getArrivalTime() : simtime_t

  }

  class cGate {

    +connectTo(cGate*)

    +getChannel() : cChannel*

  }

  class cScheduler {

    +selectNextEvent() : cEvent*

  }

  class cEventQueue {

    +insert(cEvent*)

    +remove(cEvent*)

    +peekFirst() : cEvent*

  }

}

cSimulation -> cScheduler : use

cSimulation -> cEventQueue : use

cModule "1" o-- "*" cGate

cGate "0..1" o-- "1" cChannel

cSimpleModule --|> cModule

cMessage --|> cEventQueue

@enduml

@startuml "5.3.2.1.2.NED.png"

!include etsi-style.iuml

!pragma teoz true

title "Figure 5.3.2.1.2: NED language"

package "omnetpp-6.x Project" {

  package ned {

    class NetworkNed <<NED>>

    class RouterNed <<NED>>

    class HostNed <<NED>>

  }

  package src {

    class Router <<C++>>

    class Host <<C++>>

    class App  <<C++>>

  }

  class "omnetpp.ini"

}

RouterNed --> Router : @class

HostNed --> Host : @class

@enduml