RLC buffer

[amjed mohammed]

Hi All
I need to calculate the amount of data that enter to the RLC buffer periodically (eg, each one ms ).  the new data only, not the data that already stored in the buffer from previous time period. I am trying to find out the throughput demand of a specific user and compare it with the current user throughput.

[Dustin Maas]

Hi Amjed,

Can you share the context in which you are trying to accomplish this? E.g., what software are you using? which POWDER profile? Have you tried instrumenting the software in question to track this?

-Dustin

On 28 Jan 2024, at 9:08, amjed mohammed wrote:

Hi All
I need to calculate the amount of data that enter to the RLC buffer periodically (eg, each one ms ).  the new data only, not the data that already stored in the buffer from previous time period. I am trying to find out the throughput demand of a specific user and compare it with the current user throughput.

--
You received this message because you are subscribed to the Google Groups "Powder Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to powder-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/d94c3021-7766-4b7d-9dc7-3818950a5195n%40googlegroups.com.

[amjed mohammed]

Thanks for your reply Dustin

I am using srslte and Nexran xApp. I am running this framework ( according to the OAIC instructions ) on a powerful PC belonging to my university.

To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/1609FDF7-AC3C-40A2-A2FB-0E5F87FD81DA%40gmail.com.

--

Best Regards...

Amjed H. J. Mohammed
MSc/Communication systems engineering/University of Portsmouth/UK

[Dustin Maas]

OK. If you look at our fork of srsLTE, which we modified for the NexRAN use-case, you will see that we are exporting PDCP DL/UL bytes per radio bearer. You could potentially poll that every millisecond. If that’s not precisely what you need, you could further instrument our fork as you see fit.

To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/CAByQYkCN%3DRCfDt0W9Xc3R9NuxuPGzAhp5WENC6YdUKxh0tTh%2Bg%40mail.gmail.com.

[amjed mohammed]

Thanks alot Dustin,

Yes, I already use PDCP DL/UL bytes to monitor the current throughput

Actually I am trying to find out how much data is required to be transmitted and compare it to the current throughput. Just try to find out what the actual throughput is required to make the buffer empty always and then calculate the amount of all requested PRB to get the required throughput. As I am running Nexran slicing xApp and want to modify it by dynamically adjust the share value that required to make the buffer empty when running Ipref with a specific boundary (for example 10 M)

To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/24736384-7113-4F40-A648-36D6B178529A%40gmail.com.

[Dustin Maas]

OK. In that case I think you’ll need to update the service model and the srsRAN fork (using our work as an example) to export the metrics you want.

-Dustin

To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/CAByQYkB8YUNef56%3DGDarhY%2BoPAV3pSnsfaFeUMA2d%2BL4py5KOw%40mail.gmail.com.

[Dave Taht]

I am sometimes hopeful that some of the ideas about buffer management
from the bufferbloat project have made into more 5G research and
devices.

Key to the codel algorithm (rfc8289) is prepending a timestamp to each
packet before being buffered, and to intelligently drop them based on
the time in the queue via an invsqrt to keep the overall queue depth
under control, while still permitting bursts.

The relevant paper is here:
https://queue.acm.org/detail.cfm?id=2209336. Please see the behaviors
vis vis a fixed length fifo in red, especially.

Key to the fq_codel algorithm (rfc8290) is to divvy up buffer space
via a 5 tuple IP hash, and then apply codel. A very useful extension
of classic fair queueing in that is the "flow queuing" that it does,
where so long as the ingress rate of a flow is less than the egress
rates of all the other flows, it goes out first, otherwise are mixed
more or less evenly.

http://www.diva-portal.org/smash/record.jsf?pid=diva2%3A1251687&dswid=-6918

It was always our intent to see these algorithms applied to wireless
transports and indeed, fq_codel has become the default in linux for
most common wifi chips, and is increasingly used across other wireless
backhauls than 5G, notably in mikrotik's products. There is also
libreqos, which is a middlebox applying cake for ISPs for 20k
subscriptions or more.

Anyone here fiddling with this stuff in powder? got code?

I have seen a few papers on this kind of thing for 5g, via google
scholar "bufferbloat 5g" but no actual code, to date.

> To view this discussion on the web visit https://groups.google.com/d/msgid/powder-users/48C1A315-476F-4B18-96A1-9C8725411A1C%40gmail.com.



--
40 years of net history, a couple songs:
https://www.youtube.com/watch?v=D9RGX6QFm5E
Dave Täht CSO, LibreQos