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:

NOTE: The value should be in milliseconds.

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:

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

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.

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 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):

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

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.