Low throughput

[Maria Eduarda Veras Martins]

Hello,
I'm running an ns-3 simulation with a simple 5G NR topology (1 gNB, 1 UE, and 2 remote hosts) and observing unexpectedly low throughput values (~1-1.3 Mbps).  I expected higher throughput given the relatively simple topology. Any insights would be appreciated!

Here is the FlowMonitor output:

Flow 1 (1.0.0.2:49153 -> 7.0.0.2:1234) -

Tx Packets: 18967

Rx Packets: 18322

Throughput: 1.369466 Mbps

Flow 2 (2.0.0.2:49153 -> 7.0.0.2:1235) -

Tx Packets: 16263

Rx Packets: 15383

Throughput: 1.148071 Mbps

Flow 3 (7.0.0.2:1234 -> 1.0.0.2:49153) -

Tx Packets: 11352

Rx Packets: 11348

Throughput: 0.080302 Mbps

Flow 4 (7.0.0.2:1235 -> 2.0.0.2:49153) -

Tx Packets: 13475

Rx Packets: 13458

Throughput: 0.104121 Mbps

[Mohamed Mohsen]

Hey,

Not sure if supper relevant to your case, but I am working on a custom scheduler and noticed that the moment I go over 15 UEs per gnb throughput goes down hard so maybe based on other network parameters there might always be a UE per gnb.... limit? not sure if thats the word but a point when things just fall apart.

[Maria Eduarda Veras Martins]

I understand, but my simulation has only 1 ue with two applications...
Anyway, I will keep that in mind!

[Andrey Silva]

Hello Maria, 

I noticed you put flowmon to be scheduled at every X seconds. Can it be that these metrics are just the last flowmon call? Not the aggregated one?

Regards,
Andrey.

--
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/b05bbb28-8514-4f66-a074-955488258dc2n%40googlegroups.com.

--

Andrey Silva

Engenheiro da Computação - Universidade Federal do Pará
Doutorando em Engenharia Elétrica -Núcleo de Pesquisa e Desenvolvimento em Telecomunicações, Automação e Eletrônica (LASSE) - Universidade Federal do Pará .

-

http://lasse.ufpa.br/

[Kent Huns]

Hi Maria,

It looks no problem about packet generation, scheduling and radio propagation.

because Txpackets > RxPackets >> 0  & arrival rate = RxPackets/TxPackets > 95%.

So, could you check the size of single packet?

If you don't configure it, the value may be set low implicitly.

And I'd also recommend checking that the following equation holds for all flows.

        (throughput)*(simulation time) = (RxPackets)*(bit size per packet)

[Maria Eduarda Veras Martins]

Hi Kent,

Indeed, I wasn't setting the packet size. But when I do set it (1024), there isn’t any significant change...
Regarding the equation, it doesn’t match either.
My last simulation had this flowMon log:

Flow 1 (1.0.0.2:49153 -> 7.0.0.2:1234) -

Tx Packets: 18275

Rx Packets: 16951

Throughput: 1.267239 Mbps

Flow 2 (2.0.0.2:49153 -> 7.0.0.2:1235) -

Tx Packets: 15111

Rx Packets: 14253

Throughput: 1.063565 Mbps

Flow 3 (7.0.0.2:1234 -> 1.0.0.2:49153) -

Tx Packets: 10645

Rx Packets: 10642

Throughput: 0.076848 Mbps

Flow 4 (7.0.0.2:1235 -> 2.0.0.2:49153) -

Tx Packets: 12385

Rx Packets: 12379

Throughput: 0.095858 Mbps

Where it would be (flow1):
1,267239 Mbps * 60s ≠ 16.951 packets * 1024 bits/packet
76.034.340 bits ≠ 17.357.824 bits

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/ce6d0c4b-ba39-4650-b9ea-e377d25ca178n%40googlegroups.com.

[Maria Eduarda Veras Martins]

Hi Andrey,
I'm only analyzing the flowMon in the main function. The function that runs every X seconds was just for plotting the throughput graph... (when I noticed the graph ended up with a much smaller scale than expected).

Kind regards,
Maria

[Andrey Silva]

Hello Maria, 

Did you find the reason for that? I remember that I faced issues when my application starts all at the same time. Instead of having:

clientAppsClassic.Start(Seconds(2.0));
clientAppsL4s.Start(Seconds(2.0));

Do something like:

clientAppsClassic.Start(Seconds(2.0));
clientAppsL4s.Start(Seconds(3.0));

Can you try it?

Regards,
Andrey.

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/2e39627a-c129-461e-ba5a-dc51eeb86b00n%40googlegroups.com.

[Ayush Sharma]

Hi there, i am working on my thesis for 5g strategies  in Adhoc Wireless networks.
Where can i get files to start from scratch

To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/CAKhiJubAiaBQSQ9%2BVVAt%3DG6i7qKq1CzVCUAy709RAchGeiuo1Q%40mail.gmail.com.

[Kent Huns]

Hi Maria,

I'm not familiar with Bulksendhelper, but similar discussion have taken place in the past. Please check it.

https://groups.google.com/g/5g-lena-users/c/3SZhUBHyVI8/m/gWz7jLO2AAAJ

It might be better to ask on ns-3's forum about TCP.

[Kent Huns]

PS

In the following log, "dci->m_tbSize" means the Tx data size[Bytes] carried by the radio signal for 1slot(=1ms, if you don't change).

If this value is high enough in the simulation, maybe the problem may be the measurement by the flowmonitor.

model/nr-mac-scheduler-ns3.cc

uint8_t

NrMacSchedulerNs3::DoScheduleDlData(PointInFTPlane* spoint,

                                    uint32_t symAvail,

                                    const ActiveUeMap& activeDl,

                                    SlotAllocInfo* slotAlloc) const

{

            NS_LOG_DEBUG(" UE" << dci->m_rnti << " gets DL symbols "

                               << static_cast<uint32_t>(dci->m_symStart) << "-"

                               << static_cast<uint32_t>(dci->m_symStart + dci->m_numSym) << " tbs "

                               << dci->m_tbSize << " mcs " << static_cast<uint32_t>(dci->m_mcs)

                               << " harqId " << static_cast<uint32_t>(id) << " rv "

                               << static_cast<uint32_t>(dci->m_rv));

[Gabriel Ferreira]

I don't see any antenna configuration, and the default antenna type is UPA. Since you didn't touch bearing angles, I'd assume your simulation is like this
((( > UE ((( > gNB

a.k.a. your UE is pointing to the wrong side. Try setting the bearing angle to 180 degrees to get

UE < ))) ((( > gNB

[Gabriel Ferreira]

BTW, this should stop being a problem with upcoming multipanel support by Amir. Just like in real phones, the UE will discover by itself which panel is the best one and use it until the next scan. :D

[Maria Eduarda Veras Martins]

Hi Andrey, I tried the suggestion but there was no change. I'll try adjusting the antennas as Gabriel mentioned.

Kind regards,
Maria

[Maria Eduarda Veras Martins]

Hi Gabriel,
I did configure the antennas as follows 

but it didn’t result in any noticeable change in throughput. 

I based my setup on the MIMO demo example. I’ve never deeply studied antenna implementation in ns-3, so I’m not entirely sure if what I did was sufficient. Let me know what you think!

[Maria Eduarda Veras Martins]

Hi Kent, 
Thanks for the details! I tracked the TBS and got these values:



I’m just a bit unsure about what would be considered ‘high enough’ values in this context. Could you clarify this part?
Appreciate your guidance!

[Kent Huns]

Hi Maria,

Thank you for the update.

Roughly speaking, Transport Block Size represents the data capacity that 1 radio signal can contain, and is nearly equal to the size of segmented Txpacket.

TBS = 800 means the maximum throughput of each UE's link is 800 Bytes/ms = 6.4 Mbps.

But actual throughput can be smaller due to single packet size or packet loss.

So it's important whether the single packet size has been configured larger than 800 Bytes.

In conclusion, the process of Tx side doesn't seem to be a problem. It's better to check for packet loss(Gabriel's comment) or observation by flow monitor.

Thanks