GTP-U Support

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

5G-UPF

Applicable Platform(s)

VPC-SI

SMI

Feature Default Setting

Enabled – Always-on

Related Changes in this Release

Not Applicable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History
Revision Details Release

Optimization of UDP checksum is added in this release.

2021.02.0

First introduced

2020.02.0

Feature Description

Table 3. Feature History
Feature Name

Release Information

Description

Dual Stack Support on S1-U and N3 Interfaces

 2024.01

UPF supports both IPv4 and IPv6 transport on the S1-U and N3 interfaces.

Default Setting: Enabled – Always-on

3GPP specifies provisions for UEs capable of supporting both 5G and 4G NAS to connect to the E-UTRAN and 5G core network.

To forward data (G-PDUs and End Marker packets) during an EPS to 5GS handover, the SMF performs the following tasks:

  • Provisions one PDR per E-RAB (that supports data forwarding for at least one QoS flow).

  • Creates and associates one QER with each PDR to request the UPF to insert a GTP-U PDU Session Container extension header including the QFI. The PDR includes the QFI IE set to the QFI value of one of the QoS flows mapped to the E-RAB.

Data forwarding during handovers between 5GS and EPS is supported as follows. For reference, see 3GPP TS 38.300.

  • For 5G to 4G handover, the source NG-RAN node sends one or several end-markers including one QFI of those QoS flows mapped to the same E-RAB and sends the end-marker packets to the UPF over the PDU session tunnel. UPF removes the QFI and maps to an appropriate E-RAB tunnel toward SGW.

  • For 4G to 5G handover, the source eNB forwards the received end markers in the EPS bearer tunnel to the SGW. Then SGW forwards them to the UPF. The UPF adds one QFI among the QoS flows mapped to that E-RAB to the end-markers. Then, the UPF sends those end-markers to the target NG-RAN node in the per PDU session tunnel.


Note

UPF supports dual-stack to handle IPv4 and IPv6 connections over the S1-U and N3 GTP-U interfaces.

Error Indication and GTP-U Path Failure

The UPF notifies an Error Indication message for a GTP-U peer to the sender when a GTP-PDU is received with a TEID that doesn’t exist. This notification ensures that there are no stale sessions or bearers, and maintains consistency in the network.

Error Indication and GTP-U Path Failure between SMF and UPF nodes are supported over the N4 interface. For the neighbor nodes, it’s supported over the S1u/S5u interfaces.

Behavior variations of local-purge or signal-peer for Error Indication and GTP-U Path Failure are considered in this implementation.

  • When Error Indication is received, the UPF communicates the TEID and GTPU-peer information with the SMF to ensure deletion or modification of the GTPU-peer.

  • On receiving a GTP-U packet with nonexisting TEID, the UPF generates and sends Error Indication with TEID and GTP-U peer entries.

  • The deletion of a session or a bearer is decided based on the Path Failure detection at SMF or UPF.

  • GTP-U Path Failure is detected using GTP-U echo messages between the UPF nodes, and between the UPF and SMF nodes.

How it Works

Call Flows

Initial Attach on E-UTRAN via MME and S-GW

Initial attach on E-UTRAN/EPS follows the procedure defined in 3GPP TS 23.401, Section 5.3.2.1.

The following diagram shows the call flow derived from 3GPP reference for initial attach on E-UTRAN/EPS.

Table 4. Initial Attach on E-UTRAN via 5G Core Call Flow
Step Description

1

At Step 9, SMF+PGW-C perform a UPF selection and perform N4 Session Establishment procedure. Since this session is a 4G session connecting to SMF+PGW-C, separate CN tunnel is created for each bearer and QFI is not sent in the QER and PDR, correlation ID might be present.

2

At Step 18, SMF+PGW-C performs N4 Session Modification to update the eNodeB TEID on the data path to the UPF.

The 3GPP specifications provide mechanisms to achieve mobility of a UE from LTE to 5G NR and vice versa. This mobility is achieved in two different architectures – with and without N26 interface between AMF and MME.

5G to EPS Handover with N26 Interface

5G to EPS handover with N26 interface is defined in 3GPP TS 23.502, Section 4.11.1.2.1. The following diagram shows the detailed call flow for N26 interface.

Table 5. 5G to EPS Handover with N26 Interface Call Flow
Step Description

1

In Step 2b, the SMF+PGW-C sends the N4 Session modification to the UPF to establish the CN tunnel for each EPS bearer. The bearer mapping to the 5G QoS and PCC rules received from PCC is already present with SMF. The SMF also contains the bearer IDs obtained from the Bearer ID Allocation procedure. SMF+PGW-C creates new PDRs for the N4 session and gets TEID allocated for each bearer as required by the 4G system.

2

In Step 10b, SMF+PGW-C sends N4 Modification Request to UPF to create additional PDRs and FARs to receive the redirected DL data over the indirect tunnel from NG RAN and forward them to eNodeB. The uplink PDRs in this case has the QFI to match forwarded DL data from NG RAN and the associated QER does not have the QFI as data needs to be forwarded to eNodeB. Also, the FAR redirects the received data to eNodeB over appropriate tunnel based on the QFI.

3

At Step 11, for the QoS flows indicated in QoS Flows for Data Forwarding, NG-RAN initiates data forwarding through the UPF based on the CN Tunnel Info for Data Forwarding per PDU Session. Then the UPF maps data received from the data forwarding tunnel(s) in the 5GS to the data forwarding tunnel(s) in EPS and sends the data to the target eNodeB through the Serving GW.

4

In Step 15, the SMF sends N4 Modification Request to UPF to activate the DL data path to E-UTRAN. At this time, both the indirect tunnel and the direct DL path are activated towards eNodeB.

5

At Step 21, the SMF sends N4 Modification Request to the UPF to delete the indirect forwarding tunnel.

Other call flows related to EPS to 5G and 5G to EPS handover with N26 interface, or without N26 interface are defined in 3GPP 23.502, Section 4.11.1.2.1 and Section 4.11.2.

Error Indication Handling on UPF

UPF, on receiving Error Indication, initiates a PFCP Session Report Request with Error Indication Report that includes remote F-TEID containing TEID and GTP-U Peer address.

  • For PGW-U, Error Indication message is sent or received over S5u.

  • For SAEGW-U, Error Indication message is sent or received over S1u.

  • For SGW-U, Error Indication message is sent and received over S1u and S5u.

UPF generates Error Indication with TEID and GTP-U Peer Address towards a peer when a data packet is received with TEID for which a session or bearer doesn't exist.

GTP-U Path Failure Support at UPF

GTP-U Echo Requests is initiated and sent periodically as per the configured interval on UPF. GTP-U Echo Response is sent for the GTP-U Echo Request received from SMF over GTP-U tunnel.

If Response is not received for the GTP-U Echo Request, the UPF retries Echo Requests based on configured retransmission timeout and maximum retries. When retries are exhausted, the UPF initiates PFCP node

Report Request including (Node ID, Node Report Type, User Plane Path Failure Report including Remote GTP-U Peer).

If UPF receives PFCP Node Report Response and PFCP Session Deletion Request to delete the session, it responds to the deletion request with usage reports.

Disabling UDP Checksum

This functionality disables the UDP checksum in UDP header of the GTP-U packet. The value of the UDP checksum is set to zero.

Disabling UDP Checksum

Use the following configuration to disable the UDP checksum in UDP header of the GTP-U packet.
configure 
   context context_name 
      gtpu-service service_name 
         no udp-checksum  
         end