5.24 Support of Ultra Reliable Low Latency Communication for 5GC

29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS

5.24.1 General

Stage 2 requirements for the support of Ultra Reliable Low Latency Communication (URLLC) are specified in clause 5.33 of 3GPP TS 23.501 [28].

NOTE 1: In this release of specification redundant transmission on N3/N9 interfaces for URLLC is not supported for PDU Sessions involving an I-SMF. See 3GPP TS 23.501 [28] clauses 5.34, 5.33.2.2 and 3GPP TS 23.502 [29] clause 4.24.

Redundant transmission is applied for supporting the highly reliable URLLC services, there are three different methods: dual connectivity based end to end redundant user plane paths, redundant transmission on N3/N9 interfaces or redundant transmission at transport layer.

NOTE 2: Dual connectivity based end to end redundant user plane paths has no impact to N4 interface.

QoS Monitoring is applied for packet delay measurement. The packet delay between UE and PSA UPF is a combination of the uplink or downlink packet delay on Uu interface and uplink or downlink packet delay between NG-RAN and PSA UPF. The QoS Monitoring on uplink or downlink packet delay between NG-RAN and PSA UPF can be performed on different levels of granularities, i.e. per QoS Flow per UE level, or per GTP-U path level.

Support of the URLLC feature is an optional for the SMF and UPF, for 5GC.

5.24.2 Redundant Transmission on N3/N9 interfaces

5.24.2.1 General

Stage 2 requirements for support of Redundant Transmission on N3/N9 interfaces for high reliability communication are specified in clause 5.33.2.2 of 3GPP TS 23.501 [28].

This requires duplicating downlink and uplink packets of QoS flows requiring redundant transmission of a PDU session via two independent N3 or N9 tunnels between the RAN and the UPF (PSA).

The following requirements shall apply for QoS flows requiring redundant transmission. Requirements in clause 5.2.2.3.3 shall also apply for traffic usage reporting.

5.24.2.2 GTP-U tunnel setup for redundant transmission

The SMF shall request the UPF (PSA) to establish two N3 or N9 tunnels for a PDU session with one or more Service Data Flows associated with QoS flow(s) requiring redundant transmission as follows:

– when provisioning an UL PDR in the UPF (PSA), the SMF shall request the UPF to assign two Local F-TEIDs for the PDR, by provisioning the PDI or the Traffic Endpoint with the Redundant Transmission Detection Parameters IE. The SMF may provide two different Network Instances for these two F-TEIDs to achieve disjoint transport layer paths;

– alternatively, the SMF may request the UPF to assign one Local F-TEID for the related Network Instance when creating the UL PDR, and later request the UPF to assign another Local F-TEID with the same or a different Network Instance when updating the PDR, if the redundant transmission tunnels are not established during the PDU session establishment;

– when provisioning DL FAR in the UPF (PSA) corresponding to QoS flows requiring redundant transmission, the SMF shall request the UPF to duplicate the downlink packets for redundant transmission and the SMF shall provide two F-TEIDs of remote GTP-U tunnel endpoints in the FAR, as described in clause 5.24.2.3;

– alternatively, the SMF may provide one remote endpoint F-TEID when creating the FAR and later provide another remote endpoint F-TEID when updating the FAR, if the redundant transmission tunnels are not established during the PDU session establishment.

NOTE: To forward downlink packets pertaining to service data flows not requiring redundant transmission, the SMF can create a separate FAR not requiring to duplicate the packets.

The PSA UPF shall assign the local F-TEID(s) for establishing the redundant tunnel and include the Local F-TEID(s) for Redundant Transmission IE in the PFCP Session Establishment Response or the PFCP Session Modification Response to the SMF if the Redundant Transmission Detection Parameters IE was received in the corresponding request message.

The SMF shall request the UPF (PSA) to remove one N3 or N9 tunnel used for redundant transmission if redundant transmission is no longer needed as follows:

– request the UPF to remove the local F-TEID for redundant transmission by updating the PDI or the Traffic Endpoint in UL PDR with a null length Redundant Transmission Detection Parameters IE;

– request the UPF to remove the F-TEID of remote GTP-U tunnel endpoint for redundant transmission by updating the FAR in DL PDR with a null length Redundant Transmission Forwarding Parameters IE;

– set the DFRT and EDRT flags to 0 in the FAR associated to the corresponding UL and DL PDRs, to stop duplicating packets and eliminating duplicate packets.

When so instructed, the PSA UPF shall remove the local F-TEID for redundant transmission and the F-TEID of remote GTP-U tunnel endpoint for redundant transmission, stop duplicating packets and stop detecting/eliminating duplicate packets accordingly.

5.24.2.3 Duplicating downlink packets for redundant transmission

If redundant transmission is required for a QoS flow, the SMF shall instruct the PSA UPF to replicate each downlink packet of the QoS Flow and to assign a sequence number to them by provisioning a FAR with the following information in a PFCP Session Establishment Request or PFCP Session Modification Request:

– the Redundant Transmission Forwarding Parameters IE including an Outer Header Creation IE set to the remote F-TEID of the redundant GTP-U tunnel, and if the GTP-U tunnel for redundant transmission uses a different network instance than the primary GTP-U tunnel, the Network Instance to be used for redundant transmission;

– the Apply Action IE with both the FORW and the DFRT flags set to "1".

When so instructed, the PSA UPF shall replicate downlink packets associated to such a FAR and construct the duplicated downlink packets using the information included in the Redundant Transmission Forwarding Parameters IE and other information included in the Forwarding Parameters IE for information that is not part of the Redundant Transmission Forwarding Parameters IE. The PSA UPF shall add the same sequence number in the PDU Session Container extension header of the downlink packet and the related duplicated downlink packets as specified in 3GPP TS 38.415 [34].

5.24.2.4 Eliminating duplicated uplink packets

For QoS flows for which redundant transmission is required, the SMF shall also instruct the PSA UPF to eliminate the duplicated uplink packets of the QoS Flow, based on their sequence numbers in the PDU Session Container extension header by setting the EDRT flag and the FORW flag in the Apply Action IE in the FAR IE to request the UPF to eliminate the duplicated uplink packets based on the sequence number, i.e. to forward the uplink packets and to drop duplicated uplink packets. When so instructed, the PSA UPF shall forward the only one copy of the uplink packets and drop duplicate uplink packets.

5.24.3 Redundant Transmission at transport layer

Stage 2 requirements for support of Redundant Transmission at transport layer for high reliability communication are specified in clause 5.33.2.3 of 3GPP TS 23.501 [28].

If it supports the redundant transmission at transport layer, the UP function shall set the RTTL feature flag in the UP Function Features IE (see clause 8.2.25). If so, during the UE requested PDU session establishment procedure, the CP function may select the UPF that supports redundant transmission at transport layer for the PDU session.

Requirements in clause 5.2.2.3.3 shall apply for traffic usage reporting.

NOTE: How the UPF perform the redundant transmission at transport layer is left up to UPF implementation.

5.24.4 Per QoS Flow Per UE QoS Monitoring

5.24.4.1 General

Stage 2 requirements for support of per QoS flow per UE QoS monitoring are specified in clause 5.33.3.2 of 3GPP TS 23.501 [28].

The UPF shall set the QFQM feature flag in the UP Function Features IE if it supports per QoS flow per UE QoS monitoring (see clause 8.2.25). If so, the SMF may request the UPF to perform the per QoS flow per UE QoS monitoring during a PFCP session establishment or a PFCP session modification procedure.

The SMF shall provision one or more QoS Monitoring per QoS flow control Information IEs to instruct the UPF to monitor the packet delay(s) of QoS flows as specified in clause 5.24.4.2. The SMF may request the UPF to stop the on-going QoS monitoring as specified in clause 5.24.4.2, when needed.

The UPF shall report the QoS monitoring result of the QoS flows to the SMF by sending QoS Monitoring Report IEs to the SMF as specified in clause 5.24.4.3, or by reporting the QoS monitoring events directly to the Local NEF or AF (see clause 5.33.5).

5.24.4.2 QoS Monitoring Control

If the per QoS Flow per UE QoS monitoring is required, the SMF may provision the following IEs included in the QoS Monitoring per QoS flow Control Information IE:

– one or more QFI IEs indicating the QoS flow(s) required for the QoS monitoring;

– a Requested QoS Monitoring IE indicating a request to monitor the downlink packet delay, uplink packet delay, and/or the round trip packet delay between the UPF (PSA) and UE;

– a Reporting Frequency IE indicating the frequency for the reporting, such as event triggered, periodic, and/or when the PDU Session is released;

– a Packet Delay Thresholds IE indicating thresholds for the downlink packet delay, uplink packet delay, and/or the round trip packet delay to generate the QoS monitoring reports to the CP function, if the Event Triggered QoS monitoring reporting is required in the reporting frequency.

– a Minimum Wait Time IE, to indicate the minimum waiting time between two consecutive reports, if the Event Triggered QoS monitoring reporting is required in the reporting frequency;

– a Measurement Period IE, indicating the period to generate periodic usage reports to the CP function if the periodic QoS monitoring reporting is required in the reporting frequency.

The SMF may require the UPF to stop the on-going QoS monitoring, by sending a PFCP Modification Request with the Remove SRR IE, or by sending a PFCP Modification Request with the Update SRR IE within which the previous QoS Monitoring per QoS flow Control IE is removed. Upon receiving such a PFCP Modification Request message, the UPF shall stop the on-going QoS monitoring.

5.24.4.3 QoS Monitoring Reporting

If the UPF is requested to perform QoS Monitoring (i.e. it receives one or more QoS Monitoring per QoS flow Control Information IEs from the SMF), the UPF shall select one or more downlink payload packets pertaining to every requested QoS flow(s) whenever available or create one or more dummy downlink GTP-U packets (i.e. G-PDU messages without a T-PDU as specified in clause 5.2.2.7 of 3GPP TS 29.281 [3]) otherwise, and insert the time stamp, and set the QoS Monitoring Packet (QMP) flag to "1" and the corresponding QoS Flow Identifer (for the requested QoS flow) into the GTP-U PDU Session Container extension header (see 3GPP TS 38.415 [34]) of these downlink packets.

When receiving the uplink packet related to the requested QoS flow(s), the UPF shall measure the packet delay(s) based on the time stamp(s) and packet delay(s) included in the GTP-U PDU Session Container extension header (see 3GPP TS 38.415 [34]) of the uplink packet, and generate a QoS monitoring report towards the SMF, if the packet delay(s) exceeds the defined Packet Delay Thresholds and Event Triggered QoS monitoring reporting is required in the reporting frequency. The UPF may send a next report only after the minimum waiting time indicated by the SMF.

NOTE: The dummy GTP-U packet(s) are not forwarded to the UE neither to the Packet Data Network, thus they are not measured for usage reporting. An Intermediate UPF between the PSA UPF and the NG-RAN forwards any received dummy GTP-U packets together with the GTP-U PDU Session Container extension header to the next GTP-U entity.

If the Periodic QoS monitoring reporting is required in the reporting frequency, the UPF shall generate QoS monitoring report based on the Measurement Period.

The UPF shall send QoS Monitoring Report IE to the SMF in PFCP Session Report Request; several QoS Monitoring Report IEs may be present to report the packet delay(s) for multiple QoS flows. The UPF shall include the delay value (Downlink, Uplink and/or Round trip) in the QoS Monitoring Measurement IE in the QoS Monitoring Report IE. See clause 5.33.5 for reporting the QoS monitoring events directly to the Local NEF or AF.

The UPF shall continue to apply all the provisioned SRR(s) and perform the related QoS monitoring measurement(s), until getting any further instruction from the CP function.

When receiving a new threshold (Packet Delay Thresholds, Minimum Wait Time and/or Measurement Period) from the SMF for a measurement that is already ongoing in the UPF, the UPF shall consider its ongoing measurements against the new threshold to determine when to send its next QoS monitoring report to the SMF or to the Local NEF or AF (if direct reporting of QoS monitoring event applies, see clause 5.33.5).

When receiving instruction from the SMF to stop the on-going QoS monitoring, the UPF shall generate a QoS monitoring report to the SMF or to the Local NEF or AF (if direct reporting of QoS monitoring event applies, see clause 5.33.5), to report the detected packet delay(s).

At the PFCP session termination, the UPF shall include a QoS Monitoring Report IE in the PFCP Session Deletion Response or the UPF shall send a QoS monitoring event directly to the Local NEF or AF (if direct reporting of QoS monitoring event applies, see clause 5.33.5), if the reporting frequency requests a report to be generated at the PFCP session termination.

If the Event Triggered QoS monitoring reporting is required in the reporting frequency, and no time stamp is received in uplink packet for a delay exceeding the Packet Delay Thresholds, the UPF shall generate a QoS monitoring report indicating a packet delay measurement failure to the SMF or to the Local NEF or AF (if direct reporting of QoS monitoring event applies, see clause 5.33.5).

If the Periodic QoS monitoring reporting is required in the reporting frequency, and no time stamp is received in uplink packet for a delay exceeding the Measurement Period, the UPF shall generate a QoS monitoring report indicating a packet delay measurement failure to the SMF or to the Local NEF or AF (if direct reporting of QoS monitoring event applies, see clause 5.33.5).

5.24.5 Per GTP-U Path QoS Monitoring

5.24.5.1 General

Stage 2 requirements for support of per GTP-U path QoS monitoring are specified in clause 5.33.3.3 of 3GPP TS 23.501 [28].

The UPF shall set the GPQM feature flag in the UP Function Features IE if it supports per GTP-U Path QoS monitoring (see clause 8.2.25).

5.24.5.2 GTP-U path monitoring

If the UPF is known to support this feature (e.g. by the UP Function Features IE), the SMF may request the UPF to measure the packet delay for transport paths towards remote GTP-U peers during a PFCP association setup or a PFCP association update procedure, by provisioning GTP-U Path QoS Control Information including:

– the identification of the GTP-U paths to be monitored, i.e.:

– the IP destination address of one or more remote GTP-U peers, and if available, the network instance used to reach each remote GTP-U peer and the DSCP value(s) to measure the packet delay; or

– the interface type(s) (i.e. N9 and/or N3) of the GTP-U paths;

– the values of the DSCP in the TOS/Traffic Class field to measure the packet delay, if available;

– the conditions and QoS parameters for the UPF to report measurements to the SMF, i.e. one or more of:

– immediate report;

– periodic report, with the reporting time period; and/or

– event triggered report, when the average, minimum and/or maximum packet delay on a GTP-U path exceeds corresponding thresholds.

If so instructed, the UPF shall perform an estimation of the RTT for the GTP-U paths requested to be monitored, by sending Echo Request messages (with each requested DSCP value, if any) and measuring the time that elapses between the transmission of the Echo Request message and the reception of the Echo Response message. The UPF shall compute the packet delay by adding RTT/2 and the UPF internal processing time, thus the measured delay represents an estimated elapsed time for the GTP-U path (since a user plane packet entered the UPF and its reception by the next downstreams or upstreams GTP-U peer). The UPF shall send QoS reports to the SMF by including GTP-U Path QoS Report IE(s) in a PFCP Node Report Request message.

If the GTP-U paths to be monitored are identified by their interface types (e.g. N9 and/or N3), the UPF shall monitor all GTP-U paths of all PFCP sessions established with a FAR including a matching Destination Interface Type.

For event triggered reporting, the UPF shall send a first report when a reporting threshold is exceeded and a minimum waiting time shall be applied for the subsequent report for the same type of measurement (e.g. maximum packet delay) and the same remote GTP-U peer (if the threshold is exceeded after the waiting time).

5.24.5.3 QoS monitoring of a PDU session based on GTP-U path monitoring

The SMF may request the UPF (PSA) to monitor the Uplink, Downlink or Round-Trip delay per QoS flow per UE, as specified in clause 5.24.4.2 with the following addition:

– In the QoS Monitoring per QoS flow Control Information IE, the SMF shall indicate that QoS monitoring is performed based on GTP-U path monitoring by setting the GTPUM flag to 1 in the Requested Qos Monitoring IE.

Additionally, for the UPF (PSA) and for any intermediate UPF in the path of the PDU session, the SMF (or I-SMF) shall request the UPF:

– to measure the one-way delay of the GTP-U path with the preceding uplink GTP-U entity; this corresponds to the N3 path for a UPF connected to the RAN, and to a N9 path for a UPF connected to an intermediate UPF;

– to add this delay to the "N3/N9 Delay Result" field received in the GTP-U PDU Session Container extension header (see 3GPP TS 38.415 [34]) of the uplink packet; and

– for an intermediate UPF, to send the resulting value in the "N3/N9 Delay Result" field in the GTP-U PDU Session Container extension header (see 3GPP TS 38.415 [34]) of the uplink packet it forwards (towards the PSA).

The SMF shall request the above to the UPF (PSA or I-UPF) by including the Transport Delay Reporting IE in the UL PDR(s) associated to the corresponding QoS flow to be monitored. Multiple QoS flows may be monitored for a given PDU session as specified in clause 5.24.5.4.

When so requested, each UPF shall, for UL GTP-U packets with the PDU Session Container extension header including the RAN Uplink and/or Downlink fields, add the delay of the GTP-U path with the preceding uplink GTP-U entity.

NOTE: The "N3/N9 Delay Result" field is computed by the intermediate UPF(s) and UPF (PSA). The RAN does not report the N3 path delay. The intermediate UPF connected to the RAN adds the N3 delay; the next intermediate UPF (if any) adds the N9 delay with the first intermediate UPF and the PSA adds the N9 delay of the last GTP-U path towards the PSA. If the PSA is directly connected to the RAN, the PSA measures the N3 delay.

The SMF may request the UPF to stop the on-going QoS monitoring (based on GTP-U path monitoring) for a PDU session, by sending a PFCP Modification Request with the Remove SRR IE, or by sending a PFCP Modification Request with the Update SRR IE within which the previous QoS Monitoring per QoS flow Control IE is removed. Upon receiving such a PFCP Modification Request message, the UPF shall stop the on-going QoS monitoring.

5.24.5.4 QoS Monitoring Reporting

QoS monitoring reporting by the PSA shall be performed as specified in clause 5.24.4.3, with the following modifications.

The UP function shall not insert time stamps into the GTP-U PDU Session Container extension header (see 3GPP TS 38.415 [34]) of downlink packets.

When receiving the uplink packet related to the requested QoS flow(s), the PSA shall measure the Uplink or Downlink delay by computing the sum of the end to end accumulated transport delay (computed as defined in clause 5.24.5.3) and the RAN UL or DL delay included in the GTP-U PDU Session Container extension header (see 3GPP TS 38.415 [34]) of the uplink packet.