Closed monologconnor closed 1 year ago
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.
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!
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 everyselfMessage
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:
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.
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.
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.
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,
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.
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.
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
andavgServedBlocksUl
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
andavgServedBlocksUl
look more intense, clearly in most of time the available resources are reaching25
, and the average value shows the value around10.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
andPF
(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.
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?
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 insrc\apps\mec\WarningAlert\packets\WarningAlertPacket.msg
, thePING_MSG
is defined insrc\apps\mec\WarningAlert\packets\WarningAlertPacket_Types.h
, also thelogger
is defined as a parameter in bothUEWarningAlertApp
andMECWarningAlertApp
.So I recommend you to copy the whole
src\apps\mec\WarningAlert\
folder into your src code.
Thanks a lot for your answer.
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)
Hi there! I was trying to measure the transmission delay from UE to MEC with different UE numbers. Here is my environment below:
Invalid Signal ID
issueAnd my simulation code is based on the given example under the directory
simulations/NR/mec/singleMecHost
I have modified the code inUEWarningAlertApp.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: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:
After the UEApp received the replied message, the time delay on
UE->MEC
,MEC processing
,MEC->UE
will be all calculated and recorded assignals
: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 likeFigure 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 theFigure 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 of0.0037s
fromUE to MEC
0.00125s
fromMEC to UE
0.00s
inMEC processing
In my simulation, I have set the size of message to
1000B
usingpingMsg->setChunkLength(inet::B(1000));
, and inomnetpp.ini
, I have set thenumerology
to2
andnumBands
to25
. The detail of the configuration is listed below: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!