N4 Interface Compliance with 3GPP Specification

This chapter covers the following topics:

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

Support is added for Outer Header Removal IE.

2021.04.0

In this release, PFCP library is upgraded to support the latest version of Outer Header IE.

2020.02.5

First introduced.

2020.02.0

Feature Description

In compliance with 3GPP TS 29.244, the User Plane Function (UPF) supports the following IEs:

  • Averaging Window

  • Paging Policy Indicator (PPI)

  • Outer Header Creation

  • Outer Header Removal

Averaging Window

Averaging window IE contains the duration over which the GBR and MBR is calculated. It is sent from SMF to UPF with Create QER or Update QER parent IE, if the default pre-configured value under UPF needs to be overridden.

The following format is used for encoding and decoding of the IE:

Bits
Octets 8 7 6 5 4 3 2 1
1 to 2 Type = 157 (decimal)
3 to 4 Length = n
5 to 8 Averaging Window
9 to (n+4) These octet(s) is/are present only if explicitly specified

NOTE: The value should be in milliseconds.

Paging Policy Indicator

The SMF sends PPI value in Create QER or Update QER, if UPF requires to set Paging Policy Indicator in outgoing packets.

In the case of Network Triggered Service Request and UPF buffering downlink data packet, the UPF includes the DSCP in ToS (IPv4) / TC (IPv6) value from the IP header of the downlink data packet. It also sends an indication of the corresponding QoS Flow in the data notification message to the SMF. When PPD applies, the SMF determines the Paging Policy Indicator (PPI) based on the DSCP received from the UPF.

In the case of Network Triggered Service Request and SMF buffering downlink data packet, when PPD applies, the SMF determines the PPI based on the DSCP in ToS (IPv4) / TC (IPv6) value from the IP header of the received downlink data packet and identifies the corresponding QoS Flow from the QFI of the received downlink data packet.

The following format is used for encoding and decoding of the IE:

Bits
Octets 8 7 6 5 4 3 2 1
1 to 2 Type = 158 (decimal)
3 to 4 Length = n
5 Spare PPI value
6 to (n+4) These octet(s) is/are present only if explicitly specified

NOTE: The PPI should be encoded as a 3-bit value from 0 through 7.

Outer Header Creation

Per 3GPP TS 29.244 v16.4.0, the Outer Header Creation Description field, when present, is encoded as specified in following table. It takes the form of a bitmask where each bit indicates the outer header to be created in the outgoing packet. Spare bits are ignored by the receiver.

Octet / Bit Outer Header Created in the Outgoing Packet
5/1 GTP-U/UDP/IPv4
5/2 GTP-U/UDP/IPv6
5/3 UDP/IPv4
5/4 UDP/IPv6
5/5 IPv4
5/6 IPv6
5/7 C-TAG
5/8 S-TAG
6/1 N19 Indication
6/2 N6 Indication
6/3 TCP/IPv4
6/4 TCP/IPv6

NOTE:

  • Currently, the UP/UPF doesn't support the following values of Outer Header Creation Description:

    • IPv4

    • IPv6

    • C-TAG

    • S-TAG

    • N19 Indication

    • N6 Indication

  • Third and fourth bits of sixth Octet (that is, 6/3 and 6/4) are spare bits (that is, not part of 3GPP TS) used for LI over TCP.

  • When the Outer Header Creation IE is received with the Outer Header Creation description field set to both GTP-U/UDP/IPv4 and GTP-U/UDP/IPv6, then the length of the Outer Header Creation IE, which is 26 bytes, is validated. If the length is not 26 bytes, then the Sx message is responded with the PFCP_CAUSE_MANDATORY_IE_INCORRECT with Offending IE: OUTER_HDR_CREATION cause code.


Important


If SMF/CP uses older version for Outer Header Creation, then undefined behavior (including crashes) can be seen.


Outer Header Removal

Outer Header Removal feature is used to remove the GPRS Tunneling Protocol User Plane (GTP-U) header from the uplink GTP-U packets.

The following format is used for encoding Outer Header Removal Information Element (IE):

Bits
Octets 8 7 6 5 4 3 2 1
1–2 Type = 95 (decimal)
3–4 Length = n
5 Outer Header Removal Description

6

GTP-U Extension Header Deletion

7 to (n+4) These octets are present only if explicitly specified

Per 3GPP TS 29.244, the Outer Header Removal Description field, when present, is encoded as specified in the following table.

Table 3. Outer Header Removal Description
Outer Header to be Removed from the Incoming Packet Value (Decimal)
GTP-U/UDP/IPv4 (See Notes 1, 2), 0
GTP-U/UDP/IPv6 (See Notes 1, 2) 1
UDP/IPv4 (See Notes 3, 6) 2
UDP/IPv6 (See Notes 3, 6) 3
IPv4 (See Note 6) 4
IPv6 (See Note 6) 5
GTP-U/UDP/IP (See Note 4) 6
VLAN S-TAG (See Note 5) 7
S-TAG and C-TAG (See Note 5) 8
For future use. Not sent. If received, it’s interpreted as the value "1". 9–255

NOTES:

  • The SGW-U/I-UPF stores GTP-U extension headers. These headers are forwarded for the packets that aren’t requested to be deleted by the GTP-U Extension Header Deletion field.

  • The SGW-U/I-UPF stores the GTP-U message type for a GTP-U signaling message, which must be forwarded. For example, an End Marker message

  • This value applies to DL packets received by a PGW-U for non-IP PDN connections. These connections use SGi tunneling based on UDP/IP encapsulation.

  • The CP function uses this value for instructing the UP function to remove the GTP-U/UDP/IP header regardless of the IP version (IPv4 or IPv6).

  • This value applies to DL packets received by a UPF over N6 for Ethernet PDU sessions.

  • This value applies to DL packets received by a UPF (PDU Session Anchor) over N6, when explicit N6 traffic routing information is provided to the SMF.

  • The Local F-TEID in the Created PDR or Traffic Endpoint IE is populated with the local GTP-U endpoint. This endpoint is allocated based on the configuration irrespective of the Outer Header Removal received in the Created PDR IE. For example, if the GTP-U service configuration supports both the IPv4 and IPv6 addresses, then both these addresses are allocated and advertised in the Created PDR and Traffic Endpoint IEs.

    In addition to the Local F-TEID allocation process, the User Plane advertises the allocated F-TEID to the Control Plane through the Created PDR or Traffic Endpoint IE with the following scenarios:

    • The Outer Header Removal that is received in the Create PDR IE is also considered while populating the Created PDR or Traffic Endpoint IE.

    • If Outer Header Removal is received as GTP-U, UDP, or IP, then the local GTP-U endpoint is advertised as allocated, which implies that if both the IPv4 and IPv6 addresses are configured in the GTP-U service, then both these addresses are allocated and advertised. If an IPv4 or IPv6 address is configured, then only the required address is allocated and advertised through the Created PDR or Traffic Endpoint IE.

    • If Outer Header Removal is received as GTP-U, UDP, or IPv4, then only the IPv4 address is advertised even if both these addresses are configured.

    • If Outer Header Removal is received as GTP-U, UDP, or IPv6, then only the IPv6 address is advertised even if both these addresses are configured.

Software Requirements

The software requirements are as follows:

  • The feature requires UPF support to identify, encode, and decode the wildcard tunnel type "GTP-U/UDP/IP-6" on the N4 interface.

  • If IPv4 and IPv6 addresses are received as part of Outer Header Creation (OHC), priority is given to the IPv6 endpoint, and hence the IPv6 Outer Header Removal (OHR) endpoint is retained by the UPF.

  • GTP-U/UDP/IP-6 on the N4 interface, can be received over Sx Establishment or Sx Modification request messages. UPF must support type-6 on both cases.

  • In Handoff scenarios, for all the PDRs with OHR value- 6, uplink packets are buffered until an appropriate OHC IE is received for PDRs corresponding to the downlink FAR.

  • The uplink packets are forwarded only after the appropriate OHR type is set at UPF.

Limitations

  • When the Outer Header Removal value as 6 is received for uplink PDR, the UPF maintains only IPv6 Outer Header Removal IE for uplink PDR. The UPF maintains it until an appropriate Outer Header Creation IE is received for downlink FAR.

  • This feature is applicable to the N4 interface only.