Transmission delay seems not like to increase with different numUEs?

[monologconnor]

Hi there! I was trying to measure the transmission delay from UE to MEC with different UE numbers. Here is my environment below:

• Windows 11
• Omnet++ 6.0 Release Version
• INET 4.3.9
• Simu5G latest code(cloned on May 11) with minor change mentioned in https://github.com/Unipisa/Simu5G/issues/44#issuecomment-1123756115 to resolve the Invalid Signal ID issue

And my simulation code is based on the given example under the directory simulations/NR/mec/singleMecHost I have modified the code in UEWarningAlertApp.cc with a function keeps sending Ping message with message creation timestamp after every defined time interval to the corresponding MECApp in MECHost, while the connection to MECApp is established:

void UEWarningAlertApp::sendPingMessageToMECApp(){

    inet::Packet* pkt = new inet::Packet("WarningPing");
    auto pingMsg = inet::makeShared<WarningPingPacket>();
    pingMsg->setType(PING_MSG);
    // ueMsgCreateTime = simTime();
    pingMsg->setUeIndex(getParentModule()->getIndex());
    pingMsg->setUeCreateTime(simTime());
    pingMsg->setChunkLength(inet::B(1000));
    pkt->insertAtBack(pingMsg);

    if (logger) {
        log_notation("sendMessageToMECApp");
        logfile << "ping Message sent to the MEC app: " << mecAppAddress_ << ":" << mecAppPort_ << endl;
    }

    socket.sendTo(pkt, mecAppAddress_ , mecAppPort_);
}

When the MECApp received the packet, it'll record the timestamp on receiving the packet and reply a new packet with both UE's creation and MEC's receiving timestamps to one or more UE's WarningAlertApp:

void MECWarningAlertApp::handleUeMessage(omnetpp::cMessage *msg)
{
    // determine its source address/port
    auto pk = check_and_cast<Packet *>(msg);
    ueAppAddress = pk->getTag<L3AddressInd>()->getSrcAddress();
    ueAppPort = pk->getTag<L4PortInd>()->getSrcPort();

    auto mecPk = pk->peekAtFront<WarningAppPacket>();

    if(strcmp(mecPk->getType(), START_WARNING) == 0)
    {
      //...
    }
    else if (strcmp(mecPk->getType(), STOP_WARNING) == 0)
    {   
      //...
    }else if (strcmp(mecPk->getType(), PING_MSG) == 0) {
        if (logger) {
            log_notation("handleUeMessage");
            logfile << "WarningPingPacket arrived from: " << ueAppAddress << endl;
        }

        auto pingPk = dynamicPtrCast<const WarningPingPacket>(mecPk);
        if (pingPk == nullptr){
            throw cRuntimeError("MECWarningAlertApp::handleUeMessage - WarningPingPacket is null");
        } 

        if (address_book.size() == 0) {
            address_filling(pingPk->getUeIndex());
        }

        for (auto iter = address_book.begin(); iter != address_book.end(); iter ++){
            if (logger) {
                log_notation("handleUeMessage");
                logfile << "Sending Boardcasting Reply: " << **iter << endl;
            }

            sendPingReply(pingPk, **iter, ueAppPort);
        }

    }else{
        throw cRuntimeError("MECWarningAlertApp::handleUeMessage - packet not recognized");
    }
}

void MECWarningAlertApp::sendPingReply(inet::IntrusivePtr<const WarningPingPacket>& pingPk,const inet::L3Address& dest_addr,const int& ueAppPort){

    inet::Packet* pkt = new inet::Packet("WarningPing");
    auto pingMsg = inet::makeShared<WarningPingPacket>();
    msgReplyTime = simTime();
    pingMsg->setType(PING_MSG);
    pingMsg->setChunkLength(inet::B(1000));
    pingMsg->setUeCreateTime(pingPk->getUeCreateTime());
    pingMsg->setMecReceiveTime(msgReceivedTime); //Assigned with simTime() in handlemessage(){...}
    pingMsg->setMecReplyTime(msgReplyTime);

    pkt->insertAtBack(pingMsg);

    if (logger) {
        log_notation("handleUeMessage");
        logfile << "WarningPingPacket analysed, sending reply to UE app: " << dest_addr << endl;
    }    

    ueSocket.sendTo(pkt, dest_addr, ueAppPort);
}

void MECWarningAlertApp::address_filling(int UeIndex){
    if (logger) {
        log_notation("address_filling");
        logfile << ("Starting filling device address") << endl;
    }

    auto curr_index = UeIndex + 1;
    for(auto i = 0; i < ping_receiver_num; i ++){
        if (curr_index >= numUes) {
            curr_index = 0;
        }
        string simbolicAppAddressStr = "ue["+to_string(curr_index)+"]";
        address_book.insert(new inet::L3Address(inet::L3AddressResolver().resolve(simbolicAppAddressStr.c_str())));

        curr_index ++;        
    }
}

After the UEApp received the replied message, the time delay on UE->MEC, MEC processing, MEC->UE will be all calculated and recorded as signals:

void UEWarningAlertApp::handleMessage(cMessage *msg)
{
    ueMsgReceivedTime = simTime();

    // Sender Side
    if (msg->isSelfMessage())
    {
       //...
    }else{
       //...
      else if(!strcmp(mePkt->getType(), PING_MSG)){
                if (logger) {
                    log_notation("handleMessage");
                    logfile << "Received reply from MEC message at " << simTime() << endl;
                }

                auto pingPk = dynamicPtrCast<const WarningPingPacket>(mePkt);
                if (pingPk == nullptr){
                    throw cRuntimeError("MECWarningAlertApp::handleUeMessage - WarningPingPacket is null");
                } 

                ueMsgCreateTime = pingPk->getUeCreateTime();
                mecMsgReceivedTime = pingPk->getMecReceiveTime();
                mecMsgReplyTime = pingPk->getMecReplyTime();

                emit(uploadTimeSignal, mecMsgReceivedTime - ueMsgCreateTime);
                emit(processTimeSignal, mecMsgReplyTime - mecMsgReceivedTime);
                emit(downloadTimeSignal, ueMsgReceivedTime - mecMsgReplyTime);

                if (logger) {
                    log_notation("handleMessage");
                    logfile << "Message Create Time is: [" << ueMsgCreateTime << "], Total Delay is [" << (ueMsgReceivedTime - ueMsgCreateTime) << "]" << endl; 
                }

                emit(totalTimeSignal, ueMsgReceivedTime - ueMsgCreateTime);
    }

I have read the article from https://ieeexplore.ieee.org/abstract/document/9591605, and expect the trending of the time delay/numUE is kind of like Figure 21 in the article (Since the delay measured in article is RTT and my measurement is from UE1->MEC->UE2 only, without the reversed path, so the expected graph's differentiation should be close to half of the Figure 21's).

However, no matter I have set the number of UEs from 3 to 450, the measurements of delay remains in a constant range, with the value keeps in between 0.0048s ~ 0.0052s, which consists of

• 0.0037s from UE to MEC
• 0.00125s from MEC to UE
• 0.00s in MEC processing

In my simulation, I have set the size of message to 1000B using pingMsg->setChunkLength(inet::B(1000));, and in omnetpp.ini, I have set the numerology to 2 and numBands to 25. The detail of the configuration is listed below:

[General]
image-path=../../../images
cmdenv-express-mode = true
cmdenv-autoflush = true

##########################################################
#            Output Format Results                       #
##########################################################
num-rngs = 3
repeat = 15
seed-set = ${repetition}
output-scalar-file = ${resultdir}/${configname}/${configname}.sca
output-vector-file = ${resultdir}/${configname}/${configname}.vec
**.routingRecorder.enabled = false
**.scalar-recording = false
**.vector-recording = false

##########################################################
#            Simulation parameters                       #
##########################################################
debug-on-errors = false
print-undisposed = true

sim-time-limit = 38s
warmup-period = 0s

*.playgroundSizeX = 1100m
*.playgroundSizeY = 800m
*.playgroundSizeZ = 50m

############### IPv4 configurator config #################
*.configurator.config = xmldoc("./demo.xml")

##########################################################
#              NR specific parameters                   #
##########################################################
*.gNodeB*.cellInfo.broadcastMessageInterval = 0.5s
**.fbPeriod = 40   # reports CQI every 40ms
**.amcType = "NRAmc"
**.pilotMode = "ROBUST_CQI" 
**.targetBler = 0.01
**.blerShift = 5  

#######################################################
#        CA and channel model configuration           # 
#######################################################
*.carrierAggregation.numComponentCarriers = 1
*.carrierAggregation.componentCarrier[0].numBands =  25 #${numBands=25}

*.carrierAggregation.componentCarrier[0].numerologyIndex = 2

*.*.cellularNic.LteChannelModelType = "NRChannelModel"
*.gNodeB1.cellularNic.numCarriers = 1
*.gNodeB1.cellularNic.channelModel[0].componentCarrierIndex = 0
*.ue[*].cellularNic.numCarriers = 1
*.ue[*].cellularNic.nrChannelModel[0].componentCarrierIndex = 0

##########################################################
#                      Mobility                          #          
##########################################################      
**.mobility.constraintAreaMinZ = 0m
**.mobility.constraintAreaMaxZ = 0m

*.ue[*].mobility.initFromDisplayString = false
*.ue[*].mobility.typename = "LinearMobility"
*.ue[*].mobility.updateInterval = 0.05s

*.gNodeB1.mobility.initFromDisplayString = true

**.numUes = 3

**.ue[*].mobility.initialX = 180m
**.ue[*].mobility.initialY = 50m
**.ue[*].mobility.initialMovementHeading = 90deg
**.ue[*].mobility.speed = 10mps

**.ue[*].masterId = 1    
**.ue[*].macCellId = 1   
**.ue[*].nrMasterId = 1
**.ue[*].nrMacCellId = 1
**.gNodeB1.macCellId = 1
**.gNodeB1.macNodeId = 1

# tcp settings
**.tcp.typename = "Tcp"
**.tcp.advertisedWindow = 65535         # in bytes, corresponds with the maximal receiver buffer capacity (Note: normally, NIC queues should be at least this size)
**.tcp.tcpAlgorithmClass = "TcpReno"    # TcpReno/TcpTahoe/TcpNewReno/TcpNoCongestionControl/DumbTcp
**.tcp.sackSupport = true               # Selective Acknowledgment (RFC 2018, 2883, 3517) support (header option) (SACK will be enabled for a connection if both endpoints support it)

**.hasRNISupport = true
##########################################################
#                    App Layer                           #
##########################################################

#########################_Car Side_#######################

#------------UEWarningAlertApp---------------
*.ue[*].numApps = 2
*.ue[*].app[0].typename = "DeviceApp"
*.ue[*].app[0].localPort = 4500
*.ue[*].app[0].UALCMPAddress = "ualcmp"
*.ue[*].app[0].UALCMPPort = 1000
*.ue[*].app[0].appPackageSource = "ApplicationDescriptors/WarningAlertApp.json"

*.ue[*].app[1].typename = "UEWarningAlertApp"
#*.ue[*].app[1].positionY = 150

*.ue[*].app[1].deviceAppAddress = "ue["+string(ancestorIndex(1))+"]"
*.ue[*].app[1].deviceAppPort = 4500
*.ue[*].app[1].startTime = 1s                                       #when sending start warning alert app                                   #period to sending messages
*.ue[*].app[1].stopTime = 30s                                       #when sending stop MEC warning alert app

#enable this for log output
*.ue[*].app[1].logger = false

#*.ue[*].app[0].requiredRam = 10MB
#*.ue[*].app[0].requiredDisk = 10MB
#*.ue[*].app[0].requiredCpu = 0.01
#----------------------------------------

######################_ME Host Side_#####################
# resources available
*.mecHost.maxMECApps = 900                                              #max ME Apps to instantiate
*.mecHost.maxRam = 32GB                                                 #max KBytes of Ram Space 
*.mecHost.maxDisk = 100TB                                               #max KBytes of Ram Space 
*.mecHost.maxCpuSpeed = 600000                                          #max percentage of CPU
#----------------------------------------

*.mecHost.eNBList = "gNodeB1"

#-------ETCI MES Services:---------------

*.mecHost.mecPlatform.numMecServices = 1
*.mecHost.mecPlatform.mecService[0].typename = "LocationService"
*.mecHost.mecPlatform.mecService[0].localAddress = "mecHost.mecPlatform" #da cambiare!!
*.mecHost.mecPlatform.mecService[0].localPort = 10020

*.mecHost.mecPlatform.mecService[0].rng-0 = 0 # request service time
*.mecHost.mecPlatform.mecService[0].rng-1 = 1 # subscription service time
*.mecHost.mecPlatform.mecService[0].requestServiceTime = 100us
*.mecHost.mecPlatform.mecService[0].subscriptionServiceTime = 11us

*.mecHost.mecPlatform.serviceRegistry.localAddress = "mecHost.mecPlatform" #da cambiare!!
*.mecHost.mecPlatform.serviceRegistry.localPort = 10021

*.mecHost.mecPlatform.serviceRegistry.rng-0 = 0 # request service time
*.mecHost.mecPlatform.serviceRegistry.rng-1 = 1 # subscription service time

# ME Host connected
**.gNodeB*.mecHost = "mecHost"
# ----------------------------------------------------------------------------- #

# ----------------------------------------------------------------------------- #

[Config Uniforward_003]
network = simu5g.simulations.NR.mec.singleMecHost.singleMecHost
*.mecHost.mecPlatformManager.mecOrchestrator = "mecOrchestrator"
**.mecOrchestrator.mecHostList = "mecHost"

**.numUes = 3

*.ue[*].app[1].**.scalar-recording = true
*.ue[*].app[1].**.vector-recording = true

**.ping_sender_num = 3
**.ping_receiver_num = 1

[Config Uniforward_030]
network = simu5g.simulations.NR.mec.singleMecHost.singleMecHost
*.mecHost.mecPlatformManager.mecOrchestrator = "mecOrchestrator"
**.mecOrchestrator.mecHostList = "mecHost"

**.numUes = 30

**.ping_sender_num = 30
**.ping_receiver_num = 1

# ----------------------------------------------------------------------------- #
#...#
# ----------------------------------------------------------------------------- #

I wonder if there is anything I got wrong in configuration or actual codes which makes the curve of the delay/numUEs so flat? I'm new to the telecommunication area so I could really not figure out where is the problem, any suggestion would be helpful to me!

Thanks for your help!

[giovanninardini]

Hello,

how many times / how frequently do you send your ping message?

The original UEWarningAlertApp is an application that sends only one packet from the UE to the MEC app, at the beginning of the simulation, and then it does not send any other packets anymore. This basically means that your traffic load (1000 bytes) would be negligible even with several thousands of UEs, hence the delay of transmissions is not affected at all. You probably may want to send the ping message periodically, instead.

[monologconnor]

Hello,

how many times / how frequently do you send your ping message?

The original UEWarningAlertApp is an application that sends only one packet from the UE to the MEC app, at the beginning of the simulation, and then it does not send any other packets anymore. This basically means that your traffic load (1000 bytes) would be negligible even with several thousands of UEs, hence the delay of transmissions is not affected at all. You probably may want to send the ping message periodically, instead.

Hi, Giovanni! Thanks for your reply!

I'm currently not with my laptop so I could not reply with detailed source code right now, I could only describe with text and I'll post related part of code if necessary tomorrow.

• For the frequency, I have scheduled the UEWarningAlertApp to send the packet every 1s, as every selfMessage arrived to trigger the ping_sending function, another schedule with the same message will be make simultaneously.

• And the output vector file shows that the UEWarningAlertApp emits the signal of delay every 1s, (totally 39 records per UE as the simulation runs 39s), I could not post the plot right now, but I'll try to upload that tomorrow.

the delay of the transmission is actually partially affected as the mean value of delay from some UEs (like 10 in 300 UEs) would raise from 4.7ms to some value like 11ms or 16ms, but the rest of UEs still remains mean value as 4.7ms, thus the mean value from all UE's delay does not really change, and even lower in some cases. That looks weird to me, shouldn't the effect will equally taken place on UEs as the NR channel getting busy?

Thanks for your help again!

[monologconnor]

Hello, how many times / how frequently do you send your ping message? The original UEWarningAlertApp is an application that sends only one packet from the UE to the MEC app, at the beginning of the simulation, and then it does not send any other packets anymore. This basically means that your traffic load (1000 bytes) would be negligible even with several thousands of UEs, hence the delay of transmissions is not affected at all. You probably may want to send the ping message periodically, instead.

Hi, Giovanni! Thanks for your reply!

I'm currently not with my laptop so I could not reply with detailed source code right now, I could only describe with text and I'll post related part of code if necessary tomorrow.

• For the frequency, I have scheduled the UEWarningAlertApp to send the packet every 1s, as every selfMessage arrived to trigger the ping_sending function, another schedule with the same message will be make simultaneously.
• And the output vector file shows that the UEWarningAlertApp emits the signal of delay every 1s, (totally 39 records per UE as the simulation runs 39s), I could not post the plot right now, but I'll try to upload that tomorrow.

the delay of the transmission is actually partially affected as the mean value of delay from some UEs (like 10 in 300 UEs) would raise from 4.7ms to some value like 11ms or 16ms, but the rest of UEs still remains mean value as 4.7ms, thus the mean value from all UE's delay does not really change, and even lower in some cases. That looks weird to me, shouldn't the effect will equally taken place on UEs as the NR channel getting busy?

Thanks for your help again!

Hi @giovanninardini ! Sorry for late update. I was self-isolating during the whole last week since there is a confirmed covid case found in my workplace, and I was not able to get my laptop.

Finally I completed the isolation today, and I'll paste my code below.

As my previously described, the UEWarningAlertApp would send the pingMessage every 1s:

        //...
        else if(!strcmp(msg->getName(), "selfPingMessageSend")){
            sendPingMessageToMECApp();
            if (pingSend){
                if (logger) {
                    log_notation("handleMessage");
                    logfile << "MEC app has not been stopped yet, schedule Ping Message again" << endl;
                }
                scheduleAt(simTime() + 1, selfPingSend_);
            }
        }
        //...

And here below is one of the recorded graph looks like:

The zip file below contains the src folder except the build libs and singleMecHost folder, in the case of need:

singleMecHost.zip

[giovanninardini]

Hello,

it might be that the channel is still far to get very busy. You can take a look at the avgServedBlocks statistics to see whether the radio resources are almost fully utilized or not (avgServedBlocks records the average number of RBs used in one TTI, hence if that number is still far from the total number of available RBs - 25 in your case - it means that the traffic load is still too low.

Also, how many (and which) UEs are affected by the channel getting busy depends from the MAC scheduler. By default, Simu5G uses the MaxC/I scheduler, which always prioritize UEs with good channel quality. This means that UEs having good channel quality will probably never be affected.

[monologconnor]

e whether the radio resources are almost fully utilized or not (avgServedBlocks records the average number of RBs used in one TTI, hence if that number is still far from the total number of available RBs - 25 in your case - it means that the traffic load is still too low.

Also, how many (and which) UEs are affected by the channel getting busy depends from the MAC scheduler. By default, Simu5G uses the MaxC/I scheduler, which always prioritize UEs with good channel quality. This means that UEs having good channel quality will probably never be affected.

Hello @giovanninardini , I just checked the statistics recorded, and found both avgServedBlocksDl and avgServedBlocksUl available. Is the total RBs occupied be the sum of them?

Here below is the graph of them

The peak of DL is around 16 and peak of UL is around 20. I'm not sure if that's close enough to the maximum capacity.

[giovanninardini]

You should look at the average value rather than at the vector. By the way, it looks like that you are still far from saturating the available resources.

[monologconnor]

You should look at the average value rather than at the vector. By the way, it looks like that you are still far from saturating the available resources.

Hi @giovanninardini ! Thanks for your advice. Actually the average value is pretty low since it is taking account both avgServedBlocksDl and avgServedBlocksUl from all the simulation time, and sometimes there is no traffic in the network and the records shows zero.

I tried to decrease the period of sending packets from 1s to 0.1s, and increase the number of UEs to 500. Now the graph of avgServedBlocksDl and avgServedBlocksUl look more intense, clearly in most of time the available resources are reaching 25, and the average value shows the value around 10.897

While this does not result a significant incrase in delay.

For the MAC scheduler, I have read the source code and tried the options like DRR and PF (I don't actually know what's their strategy on scheduling the traffic though) by modifying the config file:

*.gNodeB1.cellularNic.mac.schedulingDisciplineDl = "DRR"
*.gNodeB1.cellularNic.mac.schedulingDisciplineUl = "DRR"

However, the result still says not so much UEs would be affected, most of them record with constant delay with only few points out of the line:

I started wondering if I choosed mean value of delay as a wrong criteria to benchmarking the scalability of network...

[juansebastiani2cat]

Hello,

I was trying to follow your code but when I copied the first function I got the following error:

I copied this in my code :

void UEWarningAlertApp::sendPingMessageToMECApp(){

    inet::Packet* pkt = new inet::Packet("WarningPing");
    auto pingMsg = inet::makeShared<WarningPingPacket>();
    pingMsg->setType(PING_MSG);
    // ueMsgCreateTime = simTime();
    pingMsg->setUeIndex(getParentModule()->getIndex());
    pingMsg->setUeCreateTime(simTime());
    pingMsg->setChunkLength(inet::B(1000));
    pkt->insertAtBack(pingMsg);

    if (logger) {
        log_notation("sendMessageToMECApp");
        logfile << "ping Message sent to the MEC app: " << mecAppAddress_ << ":" << mecAppPort_ << endl;
    }

    socket.sendTo(pkt, mecAppAddress_ , mecAppPort_);
}

And I got the error

use of undeclared identifier 'WarningPingPacket' use of undeclared identifier 'PING_MSG' use of undeclared identifier 'logger'

And so on...do I need to include any additional package or include something else apart from the code that you showed ? Thanks a lot for your help.

[monologconnor]

Hello,

I was trying to follow your code but when I copied the first function I got the following error:

I copied this in my code :

void UEWarningAlertApp::sendPingMessageToMECApp(){

    inet::Packet* pkt = new inet::Packet("WarningPing");
    auto pingMsg = inet::makeShared<WarningPingPacket>();
    pingMsg->setType(PING_MSG);
    // ueMsgCreateTime = simTime();
    pingMsg->setUeIndex(getParentModule()->getIndex());
    pingMsg->setUeCreateTime(simTime());
    pingMsg->setChunkLength(inet::B(1000));
    pkt->insertAtBack(pingMsg);

    if (logger) {
        log_notation("sendMessageToMECApp");
        logfile << "ping Message sent to the MEC app: " << mecAppAddress_ << ":" << mecAppPort_ << endl;
    }

    socket.sendTo(pkt, mecAppAddress_ , mecAppPort_);
}

And I got the error

use of undeclared identifier 'WarningPingPacket' use of undeclared identifier 'PING_MSG' use of undeclared identifier 'logger'

And so on...do I need to include any additional package or include something else apart from the code that you showed ? Thanks a lot for your help.

Hi, there!

Sorry I just saw your reply. The WarningPingPacket is defined in src\apps\mec\WarningAlert\packets\WarningAlertPacket.msg, the PING_MSG is defined in src\apps\mec\WarningAlert\packets\WarningAlertPacket_Types.h, also the logger is defined as a parameter in both UEWarningAlertApp and MECWarningAlertApp.

So I recommend you to copy the whole src\apps\mec\WarningAlert\ folder into your src code.

[giovanninardini]

You should look at the average value rather than at the vector. By the way, it looks like that you are still far from saturating the available resources.

Hi @giovanninardini ! Thanks for your advice. Actually the average value is pretty low since it is taking account both avgServedBlocksDl and avgServedBlocksUl from all the simulation time, and sometimes there is no traffic in the network and the records shows zero.

I tried to decrease the period of sending packets from 1s to 0.1s, and increase the number of UEs to 500. Now the graph of avgServedBlocksDl and avgServedBlocksUl look more intense, clearly in most of time the available resources are reaching 25, and the average value shows the value around 10.897

While this does not result a significant incrase in delay.

For the MAC scheduler, I have read the source code and tried the options like DRR and PF (I don't actually know what's their strategy on scheduling the traffic though) by modifying the config file:

*.gNodeB1.cellularNic.mac.schedulingDisciplineDl = "DRR"
*.gNodeB1.cellularNic.mac.schedulingDisciplineUl = "DRR"

However, the result still says not so much UEs would be affected, most of them record with constant delay with only few points out of the line:

I started wondering if I choosed mean value of delay as a wrong criteria to benchmarking the scalability of network...

Hello @monologconnor,

sorry for my late answer. An alternative way to check the scalability of your network might be to compare the offered load against the carried load, that is the average throughput generated by the sender(s) against the average throughput received by the receiver(s). As long as such values are close to each other, the network is not at its full capacity. Instead, when the received throughput starts to be smaller than the generated one, it means that the network is not able to deliver all the traffic.

[monologconnor]

Hello @giovanninardini,

Thanks for your reply. Sorry I just checked your update today. So, is there any existing signal that could inspect such average throughput? Or I need to define my own one?

[juansebastiani2cat]

Hello, I was trying to follow your code but when I copied the first function I got the following error: I copied this in my code :

void UEWarningAlertApp::sendPingMessageToMECApp(){

    inet::Packet* pkt = new inet::Packet("WarningPing");
    auto pingMsg = inet::makeShared<WarningPingPacket>();
    pingMsg->setType(PING_MSG);
    // ueMsgCreateTime = simTime();
    pingMsg->setUeIndex(getParentModule()->getIndex());
    pingMsg->setUeCreateTime(simTime());
    pingMsg->setChunkLength(inet::B(1000));
    pkt->insertAtBack(pingMsg);

    if (logger) {
        log_notation("sendMessageToMECApp");
        logfile << "ping Message sent to the MEC app: " << mecAppAddress_ << ":" << mecAppPort_ << endl;
    }

    socket.sendTo(pkt, mecAppAddress_ , mecAppPort_);
}

And I got the error

use of undeclared identifier 'WarningPingPacket' use of undeclared identifier 'PING_MSG' use of undeclared identifier 'logger'

And so on...do I need to include any additional package or include something else apart from the code that you showed ? Thanks a lot for your help.

Hi, there!

Sorry I just saw your reply. The WarningPingPacket is defined in src\apps\mec\WarningAlert\packets\WarningAlertPacket.msg, the PING_MSG is defined in src\apps\mec\WarningAlert\packets\WarningAlertPacket_Types.h, also the logger is defined as a parameter in both UEWarningAlertApp and MECWarningAlertApp.

So I recommend you to copy the whole src\apps\mec\WarningAlert\ folder into your src code.

Thanks a lot for your answer.

[giovanninardini]

Hello @giovanninardini,

Thanks for your reply. Sorry I just checked your update today. So, is there any existing signal that could inspect such average throughput? Or I need to define my own one?

@monologconnor you probably need to define your own metrics in your application module. You can check the CBR app included within Simu5G to see an example on how to implement such metrics (in CBR app, they are called cbrGeneratedThroughput - that is the throughput at the sender - and cbrReceivedThroughput - that is the throughput at the receiver)