RNTI Odd/Even: Inconsistent Throughput

[RafalArciszewski]

Hello team,
I've been using srsRAN in our solution for a long time with commit 9d5dd742a
Recently I wanted to test the newest release to keep up with all the features. (3ed363d) Unfortunately I encountered some very strange gnb behavior. Every two UE registrations the throughput maxes at ~1.3Gbps, in other cases it is ~1.1Gbps.
It looks like even RNTI are ok, and odd RNTI are bad. A few days later, the situation is reversed: odd RNTIs are good, even RNTIs are bad.

From the PDCP and RLC logs, I've figured out that in the bad situation, PDCP is dropping SDUs with the cause " RLC SDU queue is full."

I don't know why this is happening. Maybe the sheduler allocates different RBs for odd/even RNTIs?

Here is the setup:
UE Amarisoft <-cables-> RU <-- ofh---> SRSRAN <-- ng --> Open5Gs <--- iperf3 server

I attach config files for old commit and newest master. I attach also logs for bad and ok RNTIs.

Could our configuration be causing these problems? Please help me investigate this further.

Here are some screenshots (the RF setup is the same all the time, I only make UE power down/up and run iperf3 client command )

RNTI4604

RNTI4605

RNTI4606

RNTI4607

Logs and configs:

vw_metanoia_4x1_100Mhz_ellacore_old_commit.yml
vw_metanoia_4x1_100Mhz_ellacore_current_master.yml

RNTI4615_log_bad.zip

[RafalArciszewski]

Hello team,
I did some tests and found that the problem exists when UE use 5QI=9 which translates to DRB RLC Acknoledge Mode. When I changed to 5QI=7 (DRB RLC Unacknoledge Mode) I get consistient troughput regarles if RNTI is even or odd.

[alvasMan]

Can you please try using a small amount of UL throughput? Something like 1Mbps? Or try decreasing the f1-u backoff timer?
I suspect that the PDCP is not getting ACK information quickly enough and thus not allowed to transmit faster.

That could also explain why UM works better.

Something like this would decrease the F1-U backoff timer. Try maybe 1, 2 or 5 ms.

diff --git a/configs/qos.yml b/configs/qos.yml
index 04338666d2..52a5aaac4b 100644
--- a/configs/qos.yml
+++ b/configs/qos.yml
@@ -351,9 +351,9 @@ qos:
         t_reordering: 220
         out_of_order_delivery: false
     f1u_cu_up:
-      backoff_timer: 10
+      backoff_timer: 1
     f1u_du:
-      backoff_timer: 10
+      backoff_timer: 1
     rlc:
       mode: am
       am:

Also, you will have probably have some difficulty with the logs at info at such high tput. Can you collect a log with the log level at warning and the PDCP metrics enabled?

[RafalArciszewski]

Thanks @alvasMan
When I started uplink 1Mbps stream, it helped for DL traffic for "bad" RNTIs. It didn't affect "good" RNTIs.

Here I marked moment when uplink started and ended.

RNT4618

RNTI4619

I attach also the logs:

RNTI4607_good2.txt
RNTI4604_bad2.txt

I failed to configre backoff timer, it is not mentioned in configuration reference on website. I tried add it like this, but it didn't work.

cu_cp:
  inactivity_timer: 20
  amf:
    addr: 10.6.0.5
    port: 38412
    bind_addr: 10.6.0.99
    supported_tracking_areas:
      - tac: 100
        plmn_list:
          - plmn: "26024"
            tai_slice_support_list:
              - sst: 1

qos:
  f1u_cu_up:
    backoff_timer: 1
  f1u_du:
    backoff_timer: 1

ru_ofh:
  ru_bandwidth_MHz: 100                                            # RU instantaneous bandwidth.
  t1a_max_cp_dl: 535                                              # Maximum T1a on Control-Plane for Downlink in microseconds.
  t1a_min_cp_dl: 286                                              # Minimum T1a on Control-Plane for Downlink in microseconds.
  t1a_max_cp_ul: 535                                              # Maximum T1a on Control-Plane for Uplink in microseconds.
  t1a_min_cp_ul: 286                                              # Minimum T1a on Control-Plane for Uplink in microseconds.
  t1a_max_up: 350                                                 # Maximum T1a on User-Plane in microseconds.
  t1a_min_up: 80                                                  # Minimum T1a on User-Plane in microseconds.
  ta4_max: 500                                                    # Maximum Ta4 on User-Plane in microseconds.

[RafalArciszewski]

There is still a question why half of RNTIs are bad and half are good with the same gnb and RF configurations.

[robertfalkenberg]

Hi @RafalArciszewski,

Here is an example qos-tune.yml file in which I've reduced the F1-U backoff timer and doubled the size of the RLC SDU queue, both only for 5QI = 9 (which I assume you are using in your experiments):

qos-tune.yml.txt

add that to your existing config by another -c <file> param, e.g.:

./gnb -c <your old config>.yml -c qos-tune.yml

If this doesen't help, you can also play with the SR period:

cell_cfg:
  pucch:
    sr_period_ms: 20

20 is the default value, you could try smaller values if the modified qos doesen't help.

[RafalArciszewski]

@robertfalkenberg thanks for tuned qos config file. Now I am getting the same results for all RNTIs.

[robertfalkenberg]

Great to hear that. thank you.

[RafalArciszewski]

Will you change the default parametrs for 5QI=9 or should I keep this config only for my deployment?

[robertfalkenberg]

We update these default parameters in OCUDU. However, I cannot say whether the new default parameters will be backported to srsRAN_Project or not.