Even after enabling QOS to 1 and giving 5qi value of 2, why is GBR not getting enforced?

Q/A
#1

Hi Team,

I am using free5gc version 4.0.1 and gtp5G version 0.9.14 and i have enabled QoS to 1 with UERANSIM & NFs as docker containers in my Ubuntu 22 system. I have even tried with gtp5g version 0.9.5, but same behaviour as i have explained below.

Context:
In the free5GC webconsole i have set both uplink and downlink session AMBR values as 30mbps with default 5QI as 9. Also, in the flow rules i have set GBR uplink and downlink values as 40mbps with 5QI as 2 with precedence 128. Now when i pass traffic with iperf3 of 40mbps i am getting a loss of 27% whereas what ever traffic that i pass less than or equal to 30mbps i am not getting any loss. When i took pcap in the UPF side, i am able to see the packets with mbr gbr values as i have given in the webconsole.

My queries are that

  1. Why is this limitation happening for a GBR qos flow when GBR is supposed to give us a guaranteed flow ? Isn’t GBR qos flow not considered in traffic policer ?
  2. How exactly session AMBR or non-GBR QoS flows shaped in traffic with reference to source code ?
  3. I have seen the traffic shaping happening in gtp5g trTCM.c file but the doubt is that, is it only happenig for session ambr when pfcp establishment is done and not for rest of the pdr and qer when pfcp modification or when flow rules are set ?

Thanks in advance and appreciate if anyone could give comprehensive answers or blogs to refer for the above queries.

#2

  1. current implementation GBR parameters are parsed and stored but not used, In src/genl/genl_qer.c, the QER parameters are processed in the qer_fill function

    see info->attrs[GTP5G_QER_GBR]

    So When traffic exceeds 30Mbps (your AMBR), packets are marked Red and dropped (causing 27% loss)

2&3. The traffic policing uses a two-rate three-color marker algorithm in src/gtpu/trTCM.c: based on MBR values in TrafficPolicer* newTrafficPolicer and Color policePacket