MEC network analysis

[ErosRibaga]

Hi, what is the best way to get latency and jitter in a MEC network simulation?

Thank you in advance.

[giovanninardini]

Hello,

I assume you are interested in application-level metrics. You need to add some timestamp to the messages transmitted by the sender application at the moment of their creation, and compute the difference at the receiver side. Take a look at the implementation of CBR and VoIP applications in Simu5G, which include a frameDelay statistic that exactly measures the end-to-end latency.

[ErosRibaga]

Thank you for your reply, but I still have some issues.

I tried calculating the time it take to a message to go from an UE to the MecHost in the SingleMecHost example, and I have some questions about it.

Q1

I worked on the WarningAlertApp and implemented this:

//client side
void UEWarningAlertApp::sendMessageToMECApp() {
  alert->setPayloadTimestamp(inet::simTime());

// server side
void MECWarningAlertApp::initialize(int stage) {
    LatencySignal_ = registerSignal("Latenza");

void MECWarningAlertApp::handleUeMessage(omnetpp::cMessage *msg) {
  double delay = (simTime() - warnPk->getPayloadTimestamp()).dbl();            
        emit(LatencySignal_, delay);
        EV << "Latenza: " <<  delay;    

//MECWarningAlertApp.ned file
simple MECWarningAlertApp like IMECApp, IApp
{
    parameters:
        @signal[Latenza];
        @statistic[Latenza](title="Latenza"; unit="s"; source="Latenza"; record=vector, stats);

The command EV << "Latency: " << delay; print the latency that is around 0.004s, but once the simulation is finished, the latency recorded values are equal to NaN. I tried to print something in the function void MECWarningAlertApp::initialize, but I couldn't see anything printed, so I think the problem is that the signal is not registered correctly. What do you think about it?

Q2

What are RequestForegroundApp and RequestBackgroundApp used for?

Q3

What are UPF e iUPF used for? And what is the difference between them?

[giovanninardini]

Hello,

Q1: I guess that it is because the omnetpp.ini sets the warmup period to 10s. In the WarningAlertApp you are considering you are trying to measure the delay of a message that is sent only once, at the beginning of the simulation. You should be able to see the values in the statistics by setting a shorter warmup period, e.g. warmup-period = 0s

Q2: RequestForeground/BackgroundApps are used to generate some traffic load to the MEC services without actually simulating the corresponing apps at the UE side. This is done to allow one to simulate heavier load on MEC services (hence, higher response times) without slowing down the simulation. You can find more detailed information in this paper (section 3.3).

Q3: we use UPF as the termination endpoint of the GTP tunneling, that is the entry/exit point of the 5G core network. iUPF (which stands for intermediate UPF) is used just as a router within the 5G core network and forwards packets between gNBs, MEC hosts and the UPF.

[ErosRibaga]

Hello,

reducing the warmup period to 0s worked. But now I am trying to get the delay for every message sent from the UE to the MecHost and vice versa.

I tried working with the WarningAlertPacket instead of the WarningAlertPacketStart, but it is instantiated as a const in the following piece of code, and I don't know how to send to the MecHost the timestamp of when the packet transmission started.

void UEWarningAlertApp::handleInfoMEWarningAlertApp(cMessage* msg)
{
    inet::Packet* packet = check_and_cast<inet::Packet*>(msg);
    auto pkt = packet->peekAtFront<WarningAlertPacket>();

Q1

Should I create another packet to get what I want?

Q2

What is a selfMessage and what is the purpose of the handleSelfMessage function?

Q3

What is the purpose of the handleMp1Message function?

[giovanninardini]

Q1

You do not need to create new packets whose only purpose is to measure the delay. In general, in order to measure the end-to-end delay, just add the timestamp (if not already present) to every message sent by the sender app, then you read the timestamp in the application that receives that packet. In this regard, maybe the WarningAlertApp is not the application you need, because it does not send packets "regularly": the UEWarningAlertApp sends one message at the beginning only, which works as a kind of "subscription" request. Then, the MECWarningAlertApp sends one message back only when the UE enters the "warning" zone.

The piece of code you mention is the function that handles the reception of the packet from the MECWarningAlertApp. There, you would need to read the timestamp possibly added by the MECWarningAlertApp. So, the packet being const should not be a problem.

Q2

A selfMessage is a message that a module sends to itself and it is usually used as a timer (e.g., the module has to execute operation X in 1 second, I schedule a selfMessage in 1 second). The handleSelfMessage is the function that is called when the selfMessage is received and performs the actions related to that message (in the example abobe, the handleSelfMessage would execute operation X)

Q3

The handleMp1Message function is the one that performs the necessary operations upon the reception of a message from the MECPlatform, e.g., a message coming from a MEC service

[ErosRibaga]

Thanks for your response.

Q1

How does the communication of the position of the car beetwen the UE and the MEC Host happen? To be more precise, how does the LocationService sends the packets between UE and MEChost?

Q2

Is it normal that in the multiMECHost simulation only the mecHost1, that is the further one, is using the WarningAlertApp? And why if I change the maxCpuSpeed of the mecHost1 the simulations returns ther following errors?

LCM proxy responded 500 -- in module (DeviceApp) 
MultiMecHost.ue[0].app[0] (id=303), at t=1.075s, event #13193

Or Finished with error when the maxCpuSpeed value of the MECHost1 is lower than the one of the MECHost2.

Q3

What is the purpose of the DeviceApp in the multiMECHost simulation ?

[giovanninardini]

Q1

The LocationService on the MEC host obtains the UEs' position simply by invoking method calls. See folder https://github.com/Unipisa/Simu5G/tree/master/src/nodes/mec/MECPlatform/MECServices/LocationService/resources/

Q2

Asking @linofex's help here, who already encountered that issue, I guess :)

Q3

The DeviceApp takes care of contacting the User App Lifecycle Managament Proxy (UALCMP) in order to request the initialization of a new MEC App. This is an element foreseen by the ETSI MEC standard.

Best regards. Giovanni