Problem with multiple UEs

[Eduardo Camelo]

So, I was wanting to run some tests with the 5G MAC layer algorithms (specifically TDMARR and TDMAMR) using some UEs with mobility and two flows within them. In my tests, I initially started with just one UE and everything went well. However, when I needed to add more than one UE, I got giant delay spikes during the simulations.

So, I wanted to know if the error was in the way I was initializing the UEs, since everything was fine before I added another UE? Or if it might be something in the 5G module?

void

BuildApps(Ipv4InterfaceContainer& ueIpIface)

{

/*

* Traffic part. Install two kind of traffic: low-latency and voice, each

* identified by a particular source port.

*/

uint16_t dlPortLowLat = 1234;

uint16_t dlPortClassic = 1235;

/*

* Voice traffic

* remote host is the server, and the UE is the client

* hemote host (6) ----------- ue:1235 (1)

* using TCP CUBIC

*/

// configure the TCP CUBIC socket

Config::Set("NodeList/" + std::to_string(remoteHostLowLat->GetId()) +

"/$ns3::TcpL4Protocol/SocketType",

TypeIdValue(TcpPrague::GetTypeId()));

Config::Set("NodeList/" + std::to_string(remoteHostClassic->GetId()) +

"/$ns3::TcpL4Protocol/SocketType",

TypeIdValue(TcpCubic::GetTypeId()));

for (uint32_t i = 0; i < uesContainer.GetN(); ++i)

{

Config::Set("NodeList/" + std::to_string(uesContainer.Get(i)->GetId()) +

"/$ns3::TcpL4Protocol/SocketType",

TypeIdValue(TcpCubic::GetTypeId()));

PacketSinkHelper dlSinkVoice("ns3::TcpSocketFactory",

InetSocketAddress(Ipv4Address::GetAny(), dlPortClassic+i));

serverApps.Add(dlSinkVoice.Install(uesContainer.Get(i)));

BulkSendHelper dlClientVoice("ns3::TcpSocketFactory", Address());

dlClientVoice.SetAttribute("SendSize", UintegerValue(1024));

AddressValue remoteAddressVoice(InetSocketAddress(ueIpIface.GetAddress(i), dlPortClassic+ i));

dlClientVoice.SetAttribute("Remote", AddressValue(remoteAddressVoice));

clientApps.Add(dlClientVoice.Install(remoteHostClassic));

Config::Set("NodeList/" + std::to_string(uesContainer.Get(i)->GetId()) +

"/$ns3::TcpL4Protocol/SocketType",

TypeIdValue(TcpPrague::GetTypeId()));

PacketSinkHelper dlSinkLowLat("ns3::TcpSocketFactory",

InetSocketAddress(Ipv4Address::GetAny(), dlPortLowLat + i));

serverApps.Add(dlSinkLowLat.Install(uesContainer.Get(i)));

BulkSendHelper dlClientLowLat("ns3::TcpSocketFactory", Address());

dlClientLowLat.SetAttribute("SendSize", UintegerValue(1024));

AddressValue remoteAddressLowLat(InetSocketAddress(ueIpIface.GetAddress(i), dlPortLowLat+ i));

dlClientLowLat.SetAttribute("Remote", AddressValue(remoteAddressLowLat));

clientApps.Add(dlClientLowLat.Install(remoteHostLowLat));

}

// start TCP server and client apps

serverApps.Start(TcpAppStart);

clientApps.Start(TcpAppStart);

serverApps.Stop(simTime);

clientApps.Stop(simTime);

}

[Gabriel Ferreira]

Which 5G-LENA version are you using?

[Angèle Hager Hafaiedh]

You need to adjust a few things.

Comment out the unneeded Logs as a start.

ᐧ

--
You received this message because you are subscribed to the Google Groups "5G-LENA-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 5g-lena-user...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/a2a376f1-c484-446a-9ae0-5bdd2cb3a44cn%40googlegroups.com.

[Eduardo Camelo]

Hi Gabriel and Angèle!

I'm using version 3.2 and I removed all unnecessary logs before starting my tests.

[Gabriel Ferreira]

I suggest to switch to at least 4.0. We fixed a large amount of issues that were introduced in 3.2 (I was rushing upper layers porting, so missed important issues). There you should see much more regular behavior. 

[Eduardo Camelo]

Unfortunately, I can't change the 5G version because some aspects of my tests depend on the version I'm using.

[Alan Birchler]

Hi Gabriel,

What about people who are using the V2X (version 1.1) extension? Is it based on a 5G-LENA version of at least 4.0? If not, then are we going to face similar problems when scaling UEs?

Best regards,

Alan Birchler De Allende

[Gabriel Ferreira]

V2X 1.1 is based on nr-3.1, not nr-3.2, so it should work fine.
Even then, nr-4.0 and nr-4.1 brings a lot of very important fixes regarding scaling number of UEs.
e.g. if you had more UEs then symbols with a TDMA scheduler, many UEs could be resource starved, resulting in 0 throughput.
Now that should not happen, since schedulers have memory and maintain fairness across time.

Tom Henderson, the main ns-3 maintainer, is working on merging v2x with upstream code, so we don't have this issues of v2x falling behind nr.

[Alan Birchler]

Hi Gabriel,

Thanks for the prompt reply.

The scheduler that I'm using for my simulation is NrMacSchedulerOfdmaQos. Is there also this possibility that you mentioned of resource starvation with increasing UE numbers using this scheduler as well (assuming appropriate configuration throughout the simulation has been set)?

Also, is there by chance an estimate as to when we can expect the V2X extension to be merged with the latest upstream?

Best regards,

Alan Birchler De Allende

[Gabriel Ferreira]

> Is there also this possibility that you mentioned of resource starvation with increasing UE numbers using this scheduler as well (assuming appropriate configuration throughout the simulation has been set)?

Yes. If the number of active UEs in a beam is bigger than the number of RBGs, you are toast. Because it doesn't have memory, after each slot, it will assign resources to same exact UEs. If you have a very wide channel, or a low number of UEs per cell, or not using full buffer traffic, this is not a problem.

No idea on V2X timeline. Just that he will be working on it through the next year.