srsRAN Uplink User Plane Analysis Part 1: UE

Introduction

This article will mostly focus on the UE/RAN interaction for processing user plane data on the uplink . The core network aspects of user plane data flow will be touched on as well, but not as in depth as the RAN. Some considerations around the setup used for the data used in this article

Commercial UE
- I do have some logs for the UE from a logging application, though some messages are not decoded and not all layers are available for logging
srsRAN gNB
- srsDU
- srsCU
Open5GS
- Both srsRAN and Open5GS are being run on the same machine

Logs and Considerations

For user plane data collection and analysis, I suggest the following log configurations on the gNB DU and gNB CU.

			
## gNB DU ## 
log:
  filename: /tmp/du.log
  all_level: debug
pcap:
  mac_enable: true
  mac_type: udp
  mac_filename: /tmp/du_mac.pcap
  f1ap_enable: true
  f1ap_filename: /tmp/du_f1ap.pcap
  f1u_enable: true
  f1u_filename: /tmp/du_f1u.pcap
  rlc_enable: true
  rlc_rb_type: all
  rlc_filename: /tmp/du_rlc.pcap

		

			
## gNB CU ## 
log:
  filename: /tmp/cu.log
  all_level: debug
pcap:
  ngap_enable: true
  ngap_filename: /tmp/cu_ngap.pcap
  f1ap_enable: true
  f1ap_filename: /tmp/cu_f1ap.pcap
  n3_enable: true
  n3_filename: /tmp/cu_n3.pcap
  f1u_enable: true
  f1u_filename: /tmp/cu_f1u.pcap

		

I also set my Open5GS UPF logging to Trace level, and collect a tcpdump on all interfaces on the host machine (tcpdump -i any -w all.pcap)

In addition to the RAN and 5GC Logs I am collecting, I am using a Commercial UE (Samsung Galaxy S23) where I am able to use a commercial application to collect a variety of L2/L3 information. Though not much of the data will be of much benefit to this article, I will use some of the data.

Wireshark MAC-NR

I was looking at the du_mac.pcap and noticed that user plane data was not decoding properly, showing Measurement Reports and RRC Reconfiguration messages with decoding errors.

I decided to check out the Wireshark Protocol preferences for MAC-NR and noticed that there is a way to configure the DRB mapping table.

If you inspect one of the packets prior to making these changes you will see that instead of DRB1, that SRB4 will be displayed, as well as the RLC Sequence Number length does not match what is configured.

You can see from the RRC Reconfiguration Message that the RLC SN length associated with LCID 4 is 18 (instead of 12)

Setup the DRB table with the appropriate parameters and voila… Properly decoded UP data.

Wireshark RLC-NR

Also adjust the RLC-NR settings to match the sequence number length. By doing this, the information in the mac and rlc pcaps will show source and destination information for the appropriate packets.

Configuration

The diagram below shows the pcap collection points that can be used for user plane data, since we will be analyzing uplink data, we will go from left to right, starting with the du_mac.pcap.

gNB-DU

gNB-CU

			
nru:
  queue_size: 2048
  bind_addr: 127.0.10.2
  ext_addr: auto
f1ap:
  cu_cp_addr: 127.0.0.88
  bind_addr: 127.0.0.87
[UDP-GW  ] [D] Binding to 127.0.10.2 port 2152
[UDP-GW  ] [D] Read bind port of UDP network gateway: 127.0.10.2
[DU-F1-U ] [I] Creating DU gateway local bearer with UL GTP Tunnel={Addr=127.0.0.88 TEID=0x000001} DL GTP Tunnel={Addr=127.0.10.2 TEID=0x000001}

		

			
cu_up:
  gtpu_queue_size: 2048
upf:
  bind_addr: 127.0.0.87
  bind_interface: auto
  ext_addr: auto
  udp_max_rx_msgs: 256
[GTPU    ] [I] Tunnel added. teid=0x000000
[UDP-GW  ] [D] Binding to 127.0.0.87 port 2152
[UDP-GW  ] [D] Binding successful
[CU-UP   ] [I] CU-UP starting...
[CU-CP   ] [I] Added TNL connection to CU-UP 0

		

UE	SMF assigned UE IPv4 Address	10.45.0.2
gNB-DU	Connection from DU to CU	127.0.10.2
gNB-CU (F1-U)	F1-U Connection to DU	127.0.0.88
gNB-CU (NG-U)	NG-U Connection to UPF	127.0.0.87
GTP-U Port		2152
gNB TEID		1 (0x000001)
UPF TEID		2068 (0x000814)

PDU Session Establishment

To get a valid PDU Session between the UE and the 5GC, you should ensure that the Session Type and DNN are configured properly in the UE and the 5GC Configurations. More information on how to do this in an earlier article under “Open-Source Network Example” .

If these are misconfigured, the UE will be able to Register with the network though the network will not establish resources for a data session.

			
PDU Session Establishment Request
PDU Session ID : 1
PDU Session Type
  Value : (1) IPv4
Always-on PDU Session Requested
  APSR : (1) Always-on PDU session requested
UL NAS Transport
Payload Container Type
  Payload Container Type Value : (1) N1 SM information
PDU session ID
  PDU Session Identity 2 Value : 1
Request Type
  Request Type Value : (1) Initial request
DNN
  Access Point Name Value : apn

		

			
PDU Session Establishment Accept
PDU Session ID : 1
elected SSC mode
  Value : (1) SSC mode 1
Selected PDU session type
  Value : (1) IPv4
Authorized QoS rules
QoS rule identifier : 1
QoS flow identifier (QFI) : 1
PDU Address
PDU Session Type Value : (1) IPv4
  IPv4
    Address : 10.45.0.2
Authorized QoS flow descriptions
QFI : 1
Number of Parameters : 1
Parameters : 
Parameter ID : 1
5QI : 9
DNN
Access Point Name Value : apn

		

The PDU Session is given a Quality Flow Identifier (QFI) with an associated 5G QoS Identifier (5QI), in this example QFI:1 corresponds to 5QI: 9

5QI	Resource Type	Priority	Packet Delay Budget	Packet Error Rate	Services
9	Non Guaranteed Bit Rate	90	300ms	10^-6	Video, Browsing (HTTP, TCP, FTP, E-mail, etc)

RRC Reconfiguration

The RRC Reconfiguration message carries the PDU Session Establishment Accept message which provides the UE will DRB configuration information. Some key information regarding the protocol layers for the DRB

SDAP: Absent header for UL and DL
- If there is a 1-to-1 mapping of QFI to DRB then SDAP header is not needed
PDCP: 18 Bit Sequence Number Length for UL and DL
- Robust Header Compression (ROHC) is not configured
RLC: LCID: 4
- Acknowledged Mode (AM)
- 18 Bit Sequence Number for UL and DL

18 bit sequence numbers allow for up to 4,722,366,482,869,645,213,695 SNs (thats a lot), but it is important to allow many SNs depending on how much data is being transmitted.

    drb-ToAddModList
      DRB-ToAddModList : 
        [0 ] : 
          cnAssociation
            cnAssociation : sdap-Config
            sdap-Config
              pdu-Session : 1
              sdap-HeaderDL : absent
              sdap-HeaderUL : absent
              defaultDRB : true
              mappedQoS-FlowsToAdd
                mappedQoS-FlowsToAdd : 
                  [0 ] : 1
          drb-Identity : 1
          pdcp-Config
            drb
              discardTimer
                discardTimer : infinity
              pdcp-SN-SizeUL
                pdcp-SN-SizeUL : len18bits
              pdcp-SN-SizeDL
                pdcp-SN-SizeDL : len18bits
              headerCompression : notUsed
            t-Reordering
              t-Reordering : ms220
        rlc-BearerToAddModList
          rlc-BearerToAddModList :
             logicalChannelIdentity : 4
              servedRadioBearer
                servedRadioBearer : drb-Identity
                drb-Identity : 1
              rlc-Config
                RLC-Config : am
                ul-AM-RLC
                  sn-FieldLength : size18
                  t-PollRetransmit : ms20
                  pollPDU : p16
                  pollByte : infinity
                  maxRetxThreshold : t32
                dl-AM-RLC
                  sn-FieldLength : size18
                  t-Reassembly : ms20
                  t-StatusProhibit : ms10
              mac-LogicalChannelConfig
                ul-SpecificParameters
                  priority : 5
                  prioritisedBitRate : infinity
                  bucketSizeDuration : ms5
                  logicalChannelGroup : 2
                  schedulingRequestID : 0
                  logicalChannelSR-Mask : false
                  logicalChannelSR-DelayTimerApplied : false

Uplink Data Flow

UE User Plane

So, what we know about the UE at this point is that it has has conducted the following…

RRC Setup Connection (SRB1 establishment for Control Plane)
Registration (Authentication, Control/User Plane Security Setup)
PDU Session Establishment (1 PDU Session with type IPv4, using DNN: “apn”, and QFI: 1 with 5QI: 9)
RRC Reconfiguration (DRB1 establishment for User Plane)
UE user wants to surf the web – the UE is in RRC Connected mode (which implies RM-Connected and CM-Connected)

There is a seemingly constant stream of data between the UE and gNB when conducting user plane data transfer. To simplify the understanding of the data flow, I will only focus on the first couple transmissions. Some of the higher layer UE procedures will be assumptions based on the data that is collected at the gNB.

Application, TCP/UDP, IP Layers

The Application layer generates the data. Multiple protocols are used for most transactions such as DNS, TLS, HTTP, etc. The Application layer protocols will then proceed to the next layer where TCP or UDP is used. Protocols like DNS use UDP and HTTP and TLS use TCP. In any instance that TCP or UDP is used, a source and destination port are addressed. Where the source port is where the data is generated from at the UE, and the destination port depends on the protocol in use.

DNS = UDP Port 53
DNS over TLS/QUIC = TCP/UDP port 853
HTTP = TCP Port 80
HTTPS/TLS = TCP/UDP port 443

The Application Layer data with TCP/UDP header is then passed to the IP layer where the source and destination IP Addresses are added. The UE IP Address of 10.45.0.2 is the source address and the Application Server address of 8.8.4.4 and 8.8.8.8 are the destination addresses.

Currently there are three streams of Application Layer data

SDAP, PDCP, RLC

The SDAP layer receives the data and simply maps QoS Flows to a DRB. Since there is a 1-to-1 mapping of the QoS Flow (QFI: 1) and DRB (DRB: 1), the SDAP layer does not need to add a header. The data is sent on DRB1 to the PDCP layer.

The PDCP layer adds sequence numbers to each packet of data that will be used to re-order packets at the receiving PDCP entities reception buffer. The PDCP layer also adds integrity protection and encryption to the data that will be used between the UE and the gNB CU, where the gNB CU PDCP will verify the integrity of the data and decipher it.

			
PDCP-NR (SN=0     )
    [Configuration: UEId=  1   DRB-1  (direction=Uplink, plane=User)]
        [Direction: Uplink (0)]
        [Plane: User (2)]
        [UE: 1]
        [Bearer type: DCCH (1)]
        [Bearer Id: 1]
        [Seqnum length: 18]
        [MAC-I Present: False]
        [SDAP header: Not Present]
        [ROHC Compression: False]
    [UE Security (ciphering=NEA0 (NULL), integrity=NIA2 (AES))]
        [Configuration frame: 16]
        [Ciphering Algorithm: NEA0 (NULL) (0)]
        [Integrity Algorithm: NIA2 (AES) (2)]
        [BEARER: 0]
        [DIRECTION: Uplink (0)]
        [COUNT: 0]
    1... .... = PDU Type: Data PDU
    .000 00.. = Reserved: 0x00
    .... ..00 0000 0000 0000 0000 = Seq Num: 0
    [Sequence Analysis - OK]
        [OK: True
PDCP-NR (SN=1     )
    [Configuration: UEId=  1   DRB-1  (direction=Uplink, plane=User)]
        [Direction: Uplink (0)]
        [Plane: User (2)]
        [UE: 1]
        [Bearer type: DCCH (1)]
        [Bearer Id: 1]
        [Seqnum length: 18]
        [MAC-I Present: False]
        [SDAP header: Not Present]
        [ROHC Compression: False]
    [UE Security (ciphering=NEA0 (NULL), integrity=NIA2 (AES))]
        [Configuration frame: 16]
        [Ciphering Algorithm: NEA0 (NULL) (0)]
        [Integrity Algorithm: NIA2 (AES) (2)]
        [BEARER: 0]
        [DIRECTION: Uplink (0)]
        [COUNT: 1]
    1... .... = PDU Type: Data PDU
    .000 00.. = Reserved: 0x00
    .... ..00 0000 0000 0000 0001 = Seq Num: 1
    [Sequence Analysis - OK]
        Previous frame for Bearer: 31
        [OK: True]

		

PDCP transfers the data to the RLC layer AM entities. The data enters the RLC transmission buffer. Based on the Transport Block Size for the Uplink Grant, the RLC layer will determine data segmentation. In this instance, PDCP SN: 2 is too large to fit the TBS of the given UL Grant so SN: 2 is segmented, where the first segment will be sent in the initial PUSCH transmission, and the second segment will be sent in the subsequent PUSCH transmission. Each packet, regardless whether segmentation is applied or not, will be given a Segment Indication (SI).

Segment Indication
- Full
- First
- Last
- Not first or last (Mid)

Data that has an SI of Last or Mid, will contain a Segment Offset (SO) that indicates how many bytes offset the data is from the previous segment. In the captures below, observe that the “Last” segment has an SO=389, meaning that 842 bytes of segment 2, start 389 bytes after segment 1 with a total length of 1231 bytes.

			
RLC-NR   UEId=1 [UL] [AM] DRB:1  [DATA]     SN=2               [389-bytes..
    [Context]
        [Direction: Uplink (0)]
        [RLC Mode: Acknowledged Mode (4)]
        [UEId: 1]
        [Bearer Type: DRB (5)]
        [Bearer Id: 1]
        [PDU Length: 392]
        [Sequence Number length: 18]
    AM Header SN=2             
        1... .... = Data/Control: Data PDU
        .0.. .... = Polling Bit: Status report not requested
        ..01 .... = Segmentation Info: Data field contains the first segment of an RLC SDU (0x1)
        .... 00.. = Reserved: 0x00
        .... ..00 0000 0000 0000 0010 = Sequence Number: 2
    [Reassembled RLC-NR in frame: 32]
    AM Data […]: 

		

			
RLC-NR   UEId=1 [UL] [AM] DRB:1  [DATA] (P) SN=2      SO=389   ..842-bytes]
    [Context]
        [Direction: Uplink (0)]
        [RLC Mode: Acknowledged Mode (4)]
        [UEId: 1]
        [Bearer Type: DRB (5)]
        [Bearer Id: 1]
        [PDU Length: 847]
        [Sequence Number length: 18]
    AM Header  (P) SN=2      SO=389 
        1... .... = Data/Control: Data PDU
        .1.. .... = Polling Bit: Status report is requested
        ..10 .... = Segmentation Info: Data field contains the last segment of an RLC SDU (0x2)
        .... 00.. = Reserved: 0x00
        .... ..00 0000 0000 0000 0010 = Sequence Number: 2
        Segment Offset: 389
    [2 RLC-NR fragments (1231 bytes): #31(389), #32(842)]
        [Frame: 31, payload: 0-388 (389 bytes)]
        [Frame: 32, payload: 389-1230 (842 bytes)]
        [Fragment count: 2]
        [Reassembled RLC-NR length: 1231]
        [Reassembled payload […]: 

		

MAC & PHY

The MAC layer adds MAC subheaders to the data that is either an 8 bit or 16 bit subheader depending on the size of the payload. Each payload is assigned LCID 4 as per RRC Reconfiguration. Additional MAC Control Elements are also included in the transmission, and must be considered in the UL Grant TBS. The MAC layer also adds padding for when the TBS is larger than the amount of data being sent. As you can see below for Transmission 2, the UL Grant is 1089 bytes, though the amount of data built to be sent is only 855 bytes, thus 233 bytes of padding is added to meet the TBS.

Transmission 1

MAC CE’s

Short BSR
Power Headroom

Transmission 2