Using Open Source Tools… Part 3… PDU Sessions & Data Flow

Introduction

You can view the pcap’s shown in this article here.

In this article, we will explore using a commercial UE and srsUE to connect to our open-source 5G network and provide an end-to-end data session. For a 5G UE to receive data service from an external DN, a PDU session must be established. We will discuss how the different 5G network applications and the UE should be configured for various data services.

Commercial Network (T-Mobile) Example

The following example shows the PDU session establishment to a UE that is locked to NR only and does not have VoNR capability. When connected to the network the UE displays “Voice: Out of Service” and voice network type “not available”. There are two configured APNs on the device, one for T-Mobile fast.t-mobile.com and the other for ims.

The first PDU Session that is established is the ims session, which requires an “Always ON PDU Session” and a 5QI of 5 for IMS support. This would provide IP architecture for voice services, and if the UE was not locked to NR only, it would use LTE for VoLTE to establish voice calls. This requires IMS to ensure adequate QoS for each application, maintain PDU session and appropriate data bearers. IMS uses SUP (Session Initiated Protocol) as the signaling mechanism for IMS.

Next, the fast.t-mobile.com PDU Session is established with a 5QI of 6, which supports Video and TCP applications. This is the primary use for NR service currently deployed for networks and devices that do not yet support VoNR. Not shown is the network assigned IPv6 address for the UE.

Open-Source Network Example

A high-level over view of the open-source 5G network PDU Session is shown below. The UE and 5GC are both configured with the APN: apn, which is set to IPv4.

The PDU Session data is configured in WebUI for the Subscriber Database. Here you can see the configured 5QI/QCI for each provisioned DNN/APN.

The UE requests an IPv4 PDU Session, the network Accepts the request and assigns the UE an IPv4 address (10.45.0.2) with 5QI: 9 for sharing and progressive video under the DNN: apn.

Data flow example

Let’s say that I am camped on a 5G network, and I want to browse the internet. I want to read a blog post on medium.com.

UE sends DNS query for medium.com to the DNS server specified by the network (8.8.4.4)
The DNS server responds with medium.com’s IP address
UE initiates the three-way handshake with medium.com (SYN, SYN-ACK, ACK)
The UE sends a ‘client hello’ message to medium.com’s IP address as part of the handshake process, using TLS (HTTPS uses TLS to establish an encrypted connection with its peers)
medium.com responds with a ‘server hello’ message, ciphering information, and application data over TLS.
UE acknowledges and applies the ciphering

When you look at it as a Point A to Point B conversation, it seems relatively trivial. As with most networks, there is a lot of work done between those two points that allow the conversation to occur. Not only are their physical equipment, nodes, servers, and network functions… Each element has a logical “stack” of protocols that data must flow through to ensure data is delivered properly, in order, securely, etc. Let’s not forget that also of these elements have interfaces, some are hard wired, some are over the air interfaces.

Data flow deep dive

All packet captures for this example are either from the 5GC or the gNB and will be shown on the image where the capture is from. Though this flow originated at the UE, we are analyzing it from the perspective of the 5GC, which is responsible for relaying the DNS query to the DNS server. UPF receives data that has traversed from the UE to the gNB and into the 5GC Core. The packet has IP, UDP, GTP, IP, UDP, and DNS headers.

IP Header from the source gNB 100.122.128.173 to destination 5GC 100.122.126.173
UDP Port 2152 indicates GTP-U over the N3 Interface to the UPF
GTP-U Tunnel End-Point ID (TEID) for the Core Network (48285) with PDU Session Container associated with QoS Flow ID of 1
IP Header from the source UE 10.45.0.2 to the destination DNS server 8.8.4.4
UDP from the UE Source Port 60146 to the DNS server destination port 53
DNS query from the UE for medium.com

The DNS Server has received the query and sent the DNS response back to the 5GC.

Core network sets the IP Header with its source IP to be routed to its next destination, the gNB.
Core network sets the UDP port as 2152, associated with GTP-U over the N3 interface.
the GTP header containers the Access Network (AN) TEID: 1
The IP header from the DNS server source address 8.8.4.4 to the destination UE 10.45.0.2
The UDP port from the DNS server source port 53 to the UE destination port 60146
the DNS server response includes the IP address associated with medium.com

The UE now knows the IP address that it should use to initiate the three-way handshake. Once that process is accomplished, the UE must initiate the ‘Client Hello’ procedure, which allows the domain associated with medium.com to set up appropriate security and ciphering sessions with the UE to protect application data.

The process is fairly self-explanatory if you have followed the last two data flows. The UE uses TCP to interact with the domain HTTPS port 443 and queries directly to the medium.com domain IP. The ‘Client Hello’ message is sent over TLS.

The medium.com domain receives the ‘Client Hello’ message and responds with the ‘Server Hello’ message, which indicates the UE should adjust its Ciphering for the domain and send TLS encrypted Application Data. The following flow is captured at gNB once the GTP-U header has been added. The GTP-U header is removed at the gNB’s RLC layer.

5GC Server Hello packet from 5GC before GTP-U header has been added.

Still, it is not entirely different from what we have been seeing. There are a lot of changes happening in the “stack” of each node that the data passes through. I will cover that in the next section.

UE Analysis

Looking at pcap data from the UE, we can observe the originating requests and responses. These are sent to the gNB, which will then add the GTP-U header with TEID for the 5GC.

T-Mobile

T-Mobile assigns IPv6 PDU Sessions. There are both IPv4 and IPv6 DNS queries for A and AAAA records. The UE uses the IPv6 addresses to retrieve the web page from the web server.

Open-Source 5G Network

Open5GS is configured for IPv4 PDU Sessions. The example below indicates that the DNS query procedure has already occurred and the UE is using the domain IPv4 address to retrieve the web page from the web server.

Downlink data flow overview

Let’s begin by assuming that the UE has sent application data and the Application Server has received that data.

Application Server

The server begins downloading the content to the UE using the appropriate protocol (TCP).

TCP layer

Adds the TCP header with source and destination ports (443 to 44728)
Includes a sequence number for re-ordering packets at the receiving node

IP Layer

Adds IP header with the source and destination IP addresses
Indicates the IP version that is being used (IPv4)
Defines the protocol being used (TCP)

L1/L2

routes and transports packets across the IP network to the UPF

UPF

UPF is the point of entry to the 5G network.

IP/UP

Receives packets from lower layers
TCP/IP packets are inspected, and specific header fields are examined
Headers compared against Service Data Flow (SDF) templates to Identify PDU session and QoS flow
Maps TCP/IP packets to appropriate QoS flow

GTP-U

GTP-U Tunnel forwards data to the gNB
GTP-U Tunnel established per PDU Session and assigned TEID per PDU session
PDU Session Container added to GTP-U header
- Identifies QoS flow
- PDU Type 0 indicates downlink data

UDP

Source and destination port 2152 for transfer over N3 interface to gNB GTP-U UDP port

Source and destination IP address from the UPF to the gNB (Outer IP header)
There are now two IP headers in the packet (inner and outer)
GTP-U IP headers are removed at the gNB

L1/L2

Transmits the packet over the N3 interface

gNB CU

the gNB receives the packet at the Centralized Unit, which uses GTP-U header to identify PDU session and QoS flow for the packet.

CU SDAP

Maps packet to Data Radio Bearer (DRB) and passes to PDCP layer over assigned DRB

CU PDCP

Integrity protects and Ciphers packet
MAC-I field appended to the packet containing an Authentication code used by the receiver to verify packet integrity
Adds PDCP sequence number used for re-ordering at the receiver
PDCP PDU is forwarded to the gnb DU over the F1 interface using a GTP-U tunnel

gNB DU

Packets are mapped per DRB rather than PDU session, and the GTP-U header is modified to include the NR RAN container instead of the PDU session container.

RLC

Removes GTP-U/UDP/IP headers belonging to the GTP-U tunnel and then processes the packet
RLC SDUs for the application may be too large and need to be segmented at the gNB DU RLC layer
RLC PDU for each DRB is mapped to a logical channel and transferred to the MAC layer

MAC

RLC PDU becomes MAC SDU
Prioritized logical channels and potentially multiplexes MAC SDU to multiple logical channels
provides reliable data transfer using Hybrid Automatic Repeat Request (HARQ)
Can include control elements (CE) within the MAC PDU – Timing Advance, DRX command, etc.
MAC subheader for each MAC SDU, which may be multiplexed within the MAC PDU – includes Logical Channel ID (LCID)
MAC PDU is mapped onto a transport channel and transferred to the Physical layer.
MAC PDU becomes a transport block which is processed by the physical layer before being sent over the air interface