ETSI MEC model in Simu5G

Simu5G includes a model of ETSI Multi-Access Edge Computing (MEC). Our MEC model aims to provide MEC developers a tool for rapid prototyping of MEC apps, which can exploit MEC services made available by Simu5G. Application endpoints (e.g. Mp1 and Mx2 interfaces) and MEC service communication are implemented according to ETSI specifications. Since Simu5G can run as a real-time network emulator, one can also interface real MEC apps with it. This way, one can test MEC apps in a computation/communication framework that includes 5G transport, a MEC infrastructure, and the MEC services provided by the former to the latter.

MEC system-level modelling

At the system level, we model the UALCMP and the MEC orchestrator. The UALCMP is a compound module including the TCP/IP stack and one application module that provides the RESTful API consumed by the Device app (either internal or external to the simulator, through an INET external interface) to trigger instantiation and termination of MEC apps via the Mx2 reference point. The MEC orchestrator is a simple module connected to the UALCMP via gates. In scenarios with multiple MEC systems, the MEC orchestrator manages a subset of the MEC hosts in the simulation, specified through the mecHostsList parameter, which is a space-separated string specifying the names of the MEC hosts under its control. Upon receiving a MEC app instantiation request from the UALCMP (which in turn receives the request by a Device app), the MEC orchestrator selects the most suitable MEC host among those associated with its MEC system, according to the MEC app requirements. The latter are specified in the so-called AppDescriptor JSON file and can include a list of required MEC services and/or computing resources (RAM, CPU and disk), which are checked against the available resources of the MEC hosts.

Once the MEC host has been identified, the MEC orchestrator triggers the MEC app instantiation, by dynamically creating the OMNeT++ module running the application logic and marking the required MEC host resources as allocated. The Device app is usually embedded in the UE client. However, its functions are quite standard, i.e., managing instantiation/termination of MEC apps by interfacing with the LCM proxy. For this reason, our MEC model includes a basic Device app able to query the LCM proxy via the RESTful API and communicating with the UE app over an UDP socket by means of a simple interface including messages for creation, termination and related acknowledgments regarding a MEC app. This way, a user only needs to code the data-plane colloquium between the UE app and the MEC app, as well as their logic.

MEC host-level modelling

The MEC host module models the MEC host level of the MEC architecture. It is configurable (via NED/INI files) with a maximum amount of resources, i.e. RAM, storage and CPU, that can be allocated to MEC apps. Its main components are the Virtualisation Infrastructure Manager (VIM) and the MEC platform modules. Communications with the MEC platform can also involve real MEC apps when Simu5G runs as an emulator. For this reason, all the entities, i.e. MEC service and Service Registry, implement a RESTful HTTP server as a TCP application running on top of the TCP/IP protocol stack of the MEC platform. Our model provides a module called MecServiceBase, which implements all the non-functional requirements needed for running an HTTP server (e.g. queueing, TCP connection management, gNB connections etc.). This allows the user to rapidly deploy an ETSI-compliant MEC service by only implementing the HTTP methods (e.g. GET, POST) according to the service behavior.

Two ETSI MEC services are currently implemented: Radio Network Information service (RNIS), that allows users to gather up-to-date information regarding radio network condition and the UEs connected to the base station associated to the MEC host, and the Location service, that provides accurate information about UEs and/or base station locations, enabling active device location tracking and location-based service recommendations. The ServiceRegistry module implements the REST resources – and HTTP methods – needed to allow MEC apps to discover MEC services via the Mp1 reference point. MEC apps are deployed as applications over TCP and UDP transport-layer protocols of the Virtualization Infrastructure compound module. Allocated resources are used by the VIM to compute the delay used to model processing time: the CPU constraint is expressed in terms of instructions per second, so that we can model the processing time of a MEC app, i.e. the time required by the MEC app to execute a set of instructions, based on the MEC host processing speed and load. A MEC host also has a GTP module that allows it to be placed anywhere in the CN of the 5G network. This is useful, for example, to test different MEC host deployments.

Deployment scenarios

As already mentioned, Simu5G can run in both simulated and emulated mode. So, the user can develop and test MEC-related applications in either mode, according to her needs. For instance, it could be the case that only a real MEC app should be tested, leaving the UE application as a stub method inside the simulator, possibly because its behavior is not needed or it is not yet available. We report below the configurations required to run some MEC scenarios in both Simu5G execution modes.

Running a fully simulated system

The simulated MEC system contains a UALCMP, a MEC orchestrator and two MEC hosts, namely mecHost1 and mecHost2, that are associated to a gNB. Car is a vector of UEs, each of them running an application called UEWarningAlertApp. The latter instantiates a MEC app named MECWarningAlertApp, which is supposed to be onboarded in the MEC system during network initialization and to send alert messages to cars when they enter a danger zone. Cars also run the Device app responsible for requesting the MEC app instantiation to the UALCMP on behalf the UEs. Besides the module implementing the logic of the MECWarningAlertApp, an AppDescriptor is also required:

{
 "appID" : "WAMECAPP",
 "appName" : "MECWarningAlertApp",
 "appProvider" : "simu5g.apps.mec.WarningAlert.MECWarningAlertApp",
 "virtualComputeDescriptor" :{
 	"virtualDisk" : 10,
	"virtualCpu" : 1500,
	"virtualMemory" : 10
	},
 "appServiceRequired" : [{
	"ServiceDependency" :{
		"serName" : "LocationService",
		"version" : "v2",
		"serCategory" : "Location"
	}
 }],
}

The MEC app requires 10 MB of RAM, 10 MB of storage, 1500 instructions per second of CPU and it consumes the Location Service. Next, it is necessary to configure both the car[*] modules and the MEC entities.

#------------UEWarningAlertApp---------------
*.car[*].numApps = 2

# app[0] is the Device App
*.car[*].app[0].typename = "DeviceApp"
*.car[*].app[0].localPort = 4500
*.car[*].app[0].UALCMPAddress = "ualcmp"
*.car[*].app[0].UALCMPPort = 1000

# app[1] is the UE App
*.car[*].app[1].typename = "UEWarningAlertApp"

# Device App address and port
*.car[*].app[1].destAddress = "car["+string(ancestorIndex(1))+"]"
*.car[*].app[1].destPort = 4500

Both the MEC hosts have the same computational capacity, but only mecHost2 has a Location Service running on its MEC platform, hence it will be the one chosen by the MEC orchestrator to deploy the MEC app.

If the user wanted to request the onboarding of the appDescriptor file from the Device app, instead of it being loaded at initialization time, it has to insert the path to the file in the appPackageSource parameter of the Device app and remove the appDescriptor file name from the list of the MEC orchestrator mecApplicationPackageList parameter.

Running an emulated system

We now describe the configuration required to run a MEC system in emulation mode within Simu5G. More in detail, the following operations will be highlighted: routing rules, in both the simulator and the host running the real applications, and the configuration to instruct the MEC orchestrator to manage the instantiation of a real MEC app. In our test, both the UE app and the MEC app are real applications running on the same host where Simu5G runs. The real applications replicate the behavior described above in a network scenario including one car and one MEC host. The Device app runs inside the UE and communicates with the real UE app through the serialization and deserialization of the messages of the interface mentioned earlier.

The interaction with the real world occurs via two INET’s ExtLowerEthernetInterface modules included into the car and mecHost modules. Such interfaces can receive real packets by network interface cards attached to them. In our case, such network interfaces are created as Virtual Ethernets (veth). Data packets directed to the simulator are routed to the relative veth attached to the ExtLowerEthernetInterface modules. Since all the applications run in the same host, a natRouter module must be used to bypass the host operating system and steer the traffic towards the simulator. This way, both real applications send packet to the IP addresses of the natRouter, which in turn performs Network Address Translation by changing the destination addresses to the proper real application’s addresses. The INI configuration for the natRouter router is:

############## natRouter configuration ##############
*.natRouter.ipv4.natTable.config =
	xml("<config> \
		<entry type='prerouting' \
		packetDataFilter='*Ipv4Header and destAddress=~10.0.2.1' \
		srcAddress='10.0.3.2' destAddress='192.168.2.2'/> \
		<entry type='prerouting' \
		packetDataFilter='*Ipv4Header and destAddress=~10.0.3.2' \
		srcAddress='10.0.2.1' destAddress='192.168.3.2'/> \
		</config>)

IP addresses 10.0.2.1 and 10.0.3.2 are the addresses of the left and right natRouter interfaces, respectively.

To conclude the Simu5G network setup, the configuration of the routing tables of all the network devices in the simulated network is needed to enable the forwarding for packets destined to the real applications.

Finally, the INI configuration of the ExtLowerEthernetInterface modules to allow the communication with the real world is:

############## Ext Interface configuration ##############
*.mecHost1.virtualisationInfrastructure.numExtEthInterfaces = 1
*.mecHost1.virtualisationInfrastructure.extEth[0].typename = "ExtLowerEthernetInterface"
*.mecHost1.virtualisationInfrastructure.extEth[0].device = "veth2"
*.mecHost1.virtualisationInfrastructure.ipv4.forwarding = true

*.car.numEthInterfaces = 1
*.car.eth[0].typename = "ExtLowerEthernetInterface"
*.car.eth[0].device = "veth0"
*.car.extHostAddress = "192.168.3.2"
*.car.ipv4.forwarding = true

As far as the MEC system is concerned, to allow the instantation of a real MEC app in the appDescriptor file related to a real MEC app, a field called emulatedMecApplication must be inserted. The latter contains the ipAddress and port sub-fields identifying the real MEC app endpoint. This way, the MEC orchestrator is made aware that the MEC app to instantiate is running outside Simu5G and it does not need to request the creation of the MEC app module inside the simulator. Then, the MEC orchestrator communicates to the Device app the IP-port pair the UE app will need to use to communicate with the MEC app, i.e. the address of the natRouter interface in this case, although real hosts’ addresses are also allowed. Once the Simu5G environment is configured, the OS of the host running all the applications must be configured too. The following commands refers to a host equipped with Linux Ubuntu 18.04 OS. veth interfaces are created through the command:

ip link add veth0 type veth peer name veth1

After the interfaces have been created, we assign an IP address to them and enable them by:

ip addr add 192.168.3.2 dev veth1 

ip link set veth0 up 

Finally, routes to forward the packets within the simulator and its modules have to be added. In particular, packets must reach the Device app, the natRouter and the MEC platform modules:

# UE's eth interface is 192.168.4.1, route for Device app
sudo route add -net 192.168.4.0 netmask 255.255.255.0 dev veth1
# natRouter left interface address is 10.0.2.1
sudo route add -net 10.0.2.0 netmask 255.255.255.0 dev veth1
# natRouter right interface address is 10.0.3.2
sudo route add -net 10.0.3.0 netmask 255.255.255.0 dev veth3
# mecPlatform interface address is 10.0.5.2 (for MEC services)
sudo route add -net 10.0.5.0 netmask 255.255.255.0 dev veth3)

Back to Guides