Content for  TS 23.501  Word version:  18.5.0

In order to support highly reliable URLLC services, a UE may set up two redundant PDU Sessions over the 5G network, such that the 5GS sets up the user plane paths of the two redundant PDU Sessions to be disjoint. The user's subscription indicates if user is allowed to have redundant PDU Sessions and this indication is provided to SMF from UDM. Figure 5.33.2.1-1 illustrates an example user plane resource configuration of dual PDU Sessions when redundancy is applied. One PDU Session spans from the UE via Master RAN node to UPF1 acting as the PDU Session Anchor, and the other PDU Session spans from the UE via Secondary RAN node to UPF2 acting as the PDU Session Anchor. As described in TS 37.340, NG-RAN may realize redundant user plane resources for the two PDU Sessions with two NG-RAN nodes (i.e. Master RAN node and Secondary RAN node as shown in Figure 5.33.2.1-1) or a single NG-RAN node. In both cases, there is a single N1 interface towards AMF. Based on these two PDU Sessions, two independent user plane paths are set up. UPF1 and UPF2 connect to the same Data Network (DN), even though the traffic via UPF1 and UPF2 may be routed via different user plane nodes within the DN. In order to establish two redundant PDU Sessions and associate the duplicated traffic coming from the same application to these PDU Sessions, URSP as specified in TS 23.503 may be used, or alternatively the UE may perform this task independently from URSP. When URSP is used to establish two redundant PDU Sessions, duplicated traffic from the application, associated to the redundant PDU Sessions, is differentiated by two distinct traffic descriptors, each in a distinct URSP rule. These traffic descriptors need to have different DNNs, IP descriptors or non-IP descriptors (e.g. MAC address, VLAN ID), so that the two redundant PDU Sessions are matched to the Route Selection Descriptors of distinct URSP rules. These Route Selection Descriptors of distinct URSP rules may include corresponding RSNs and PDU Session Pair IDs. The Route Selection Descriptors share same PDU Session Pair ID, if included, to denote the two traffic are redundant with each other. How does UE determines the PDU Session Pair ID and/or RSN from the matched URSP rules is described in clause 6.6.2 of TS 23.503. When the UE performs the establishment of two redundant PDU Sessions and the duplication of traffic independently from URSP, the UE may establish two redundant PDU Sessions even when the application does not duplicate the traffic and the application does not provide two distinct traffic descriptors. In this case the UE may set the RSN and PDU Session Pair ID in the PDU Session Establishment Request message based on UE implementation. If the operator decides to allow UE to use its own mechanisms to determine PDU Session Pair ID and RSN (where such UE capability is known based on local PCF configuration based on e.g. deployment, terminal implementation or policies per group of UE(s)), then the PCF shall not include PDU Session Pair ID and RSN in URSP rule. The redundant user plane set up applies to both IP and Ethernet PDU Sessions.

Support of redundant PDU Sessions include:

• UE initiates two redundant PDU Sessions and may provide PDU Session Pair ID (optional) and the RSN (optional). Different combinations of RSN, DNN and S-NSSAI are used for each PDU Session within a given pair of redundant PDU Sessions. Different combinations of PDU Session Pair ID, DNN and S-NSSAI are used between the different pairs of redundant PDU Session.
  • The UE may include a PDU Session Pair ID and/or RSN in each of the PDU Session establishment Request when it establishes redundant PDU Sessions. UE determines the PDU Session Pair ID and/or RSN based on UE local mechanism or the matched URSP rules.
• The SMF determines whether the PDU Session is to be handled redundantly. The determination is based on the presence of the PDU Session Pair ID and/or RSN in the PDU Session Establishment Request or the determination is based on an indication that redundant PDU Session is required provided by PCF for the PDU Session, if dynamic PCC applies for the PDU Session or the combination of the S-NSSAI, DNN, user subscription and local policy configuration in the SMF if dynamic PCC is not used for the PDU Session. If the PDU session is to be handled redundantly and the PDU Session Pair ID was not included in the PDU Session Establishment request, the SMF uses S-NSSAI, DNN and local configuration to determine the PDU Session Pair ID. If the PDU session is to be handled redundantly and RSN was not included in the PDU Session Establishment request, the SMF uses S-NSSAI, DNN to determine the RSN value. The RSN differentiates the PDU Sessions that are handled redundantly and indicates redundant user plane requirements for the PDU Sessions in NG-RAN.
• The SMF shall provide the RSN and PDU Session Pair ID to the NG-RAN for a redundant PDU Session.
• Operator configuration of UPF selection ensures the appropriate UPF selection for disjoint paths.
• At establishment of the PDU Sessions or at transitions to CM-CONNECTED state, the RSN parameter indicates to NG-RAN that redundant user plane resources shall be provided for the given PDU Sessions by means of dual connectivity. The PDU Session Pair ID identifies the two redundant PDU Sessions that belong together. The value of the RSN parameter and the PDU Session Pair ID indicates redundant user plane requirements for the PDU Sessions. This request for redundant handling is made by indicating the RSN to the NG-RAN node on a per PDU Session granularity. PDU Sessions associated with different RSN values shall be realized by different, redundant UP resources. Based on the RSN, the PDU Session Pair ID and RAN configuration, the NG-RAN sets up dual connectivity as defined in TS 37.340 so that the sessions have end to end redundant paths. When there are multiple PDU Sessions with the RSN parameter set, of different values of RSN and the same PDU Session Pair ID, this indicates to NG-RAN that CN is requesting dual connectivity to be set up and the user plane shall be handled as indicated by the RSN parameter, the PDU Session Pair ID and the associated RAN configuration. If the RSN value and PDU Session Pair ID are provided to the NG-RAN, NG-RAN shall consider the RSN value and PDU Session Pair ID when it associates the PDU Sessions with NG-RAN UP.
• Using NG-RAN local configuration, NG-RAN determines whether the request to establish RAN resources for a PDU Session is fulfilled or not considering user plane requirements indicated by the RSN parameter and the PDU Session Pair ID by means of dual connectivity. If the request to establish RAN resources for PDU Session can be fulfilled by the RAN, the PDU Session is established even if the user plane requirements indicated by RSN cannot be satisfied. The decision for each PDU Session is taken independently (i.e. rejection of a PDU Session request shall not release the previously established PDU Session). The RAN shall determine whether to notify the SMF if the RAN resources indicated by the RSN parameter and the PDU Session Pair ID can no longer be maintained and SMF can use that to determine if the PDU Session should be released.
• In the case of Ethernet PDU Sessions, the SMF has the possibility to change the UPF (acting as the PSA) and select a new UPF based on the identity of the Secondary RAN node for the second PDU Session if the Secondary RAN node is modified (or added/released), using the Ethernet PDU Session Anchor Relocation procedure described in clause 4.3.5.8 of TS 23.502.
• The SMF's charging record may reflect the RSN information.
• The RSN parameter and the PDU Session Pair ID, if available, is transferred from Source NG-RAN to Target NG-RAN in the case of handover.

If the reliability of NG-RAN node, UPF and CP NFs are high enough to fulfil the reliability requirement of URLLC services served by these NFs, but the reliability of single N3 tunnel is considered not high enough, e.g. due to the deployment environment of backhaul network, the redundant transmission may be deployed between PSA UPF and NG-RAN via two independent N3 tunnels, which are associated with a single PDU Session, over different transport layer path to enhance the reliability. SMF may make use of Redundant Transmission Experience analytics provided by NWDAF, as described in clause 6.13 of TS 23.288, to determine whether redundant transmission for the PDU session of the URLLC shall be performed or (if activated) shall be stopped. To ensure the two N3 tunnels are transferred via disjointed transport layer paths, the SMF or PSA UPF should provide different routing information in the tunnel information (e.g. different IP addresses or different Network Instances), and these routing information should be mapped to disjoint transport layer paths according to network deployment configuration. The SMF indicates NG-RAN and PSA UPF that one of the two CN/AN Tunnel Info is used as the redundancy tunnel of the PDU Session accordingly. The redundant transmission using the two N3/N9 tunnels are performed at QoS Flow granularity and are sharing the same QoS Flow ID. During or after a URLLC QoS Flow establishment, if the SMF decided that redundant transmission shall be performed based on authorized 5QI, NG-RAN node capability, operator configuration and/or Redundant Transmission Experience analytics, the SMF informs the PSA UPF and NG-RAN to perform redundant transmission via N4 interface and N2 information accordingly. In this case, NG-RAN should also provide different routing information in the tunnel information (e.g. different IP addresses), and these routing information should be mapped to disjoint transport layer paths according to network deployment configuration. If duplication transmission is performed on N3/N9 interface, for each downlink packet of the QoS Flow the PSA UPF received from DN, the PSA UPF replicates the packet and assigns the same GTP-U sequence number to them for the redundant transmission. The NG-RAN eliminates the duplicated packets based on the GTP-U sequence number and then forwards the PDU to the UE. For each uplink packet of the QoS Flow the NG-RAN received from UE, the NG-RAN replicates the packet and assigns the same GTP-U sequence number to them for redundant transmission. These packets are transmitted to the PSA UPF via two N3 Tunnels separately. The PSA UPF eliminates the duplicated packet based on the GTP-U sequence number accordingly. The PSA UPF and NG-RAN may transmit packets via one or both of the tunnels per QoS Flow based on SMF instruction. During UE mobility, when the UE moves from NG-RAN supporting redundant transmission to NG-RAN not supporting redundant transmission, the SMF may release the QoS Flow which are subject to redundant transmission. Figure 5.33.2.2-1 illustrates the case that the redundant transmission is performed only on N3 interface. These packets are transmitted to the NG-RAN via two N3 Tunnels separately. The RAN node and PSA UPF shall support the packet replication and elimination function as described above.

Two Intermediate UPFs (I-UPFs) between the PSA UPF and the NG-RAN may be used to support the redundant transmission based on two N3 and N9 tunnels between a single NG-RAN node and the PSA UPF. The NG-RAN node and PSA UPF shall support the packet replication and elimination function as described above.

In Figure 5.33.2.2-2, there are two N3 and N9 tunnels between NG-RAN and PSA UPF for the URLLC QoS Flow(s) of the same PDU Session for redundant transmission established during or after a URLLC QoS Flow establishment. In the case of downlink traffic, the PSA UPF duplicates the downlink packet of the QoS Flow from the DN and assigns the same GTP-U sequence number to them. These duplicated packets are transmitted to I-UPF1 and I-UPF2 via N9 Tunnel 1 and N9 Tunnel 2 separately. Each I-UPF forwards the packet with the same GTP-U sequence number which receives from the PSA UPF to NG-RAN via N3 Tunnel 1 and N3 Tunnel 2 respectively. The NG-RAN eliminates the duplicated packet based on the GTP-U sequence number. In the case of uplink traffic, the NG-RAN duplicates the packet of the QoS Flow from the UE and assigns the same GTP-U sequence number to them. These duplicated packets are transmitted to I-UPF1 and I-UPF2 via N3 Tunnel 1 and N3 Tunnel 2 separately. Each I-UPF forwards the packet with the same GTP-U sequence number which receives from the NG-RAN to PSA UPF via N9 Tunnel 1 and N9 Tunnel 2 respectively. The PSA UPF eliminates the duplicated packets based on the GTP-U sequence number. The I-UPFs inserted on one leg of the redundant paths shall not behave in an UL CL or Branching Point role.

Redundant transmission can be supported within the 5G System without making any assumption on support for protocols such as IEEE FRER in the application layer (DN only) at the same time it can be supported without requiring redundant GTP-U tunnel over N3. The backhaul provides two disjoint transport paths between UPF and NG-RAN. The redundancy functionality within NG-RAN and UPF make use of the independent paths at transport layer. Support of redundant transmission at transport layer requires no 3GPP protocol impact. Following are the required steps:

• UE establishes the PDU session for URLLC services. Based on DNN, S-NSSAI, knowledge of supporting redundant transmission at transport layer and other factors as described in clause 6.3.3, SMF selects a UPF that supports redundant transmission at transport layer for the PDU session. One N3 GTP-U tunnel is established between UPF and NG-RAN.
  The knowledge of supporting redundant transmission at transport layer can be configured in the SMF, or be configured in UPF and then obtained by the SMF via N4 capability negotiation during N4 Association setup procedure.
• For DL data transmission, UPF sends the DL packets on N3 GTP-U tunnel. Redundant functionality in the UPF duplicates the DL data on the transport layer. Redundant functionality in the NG-RAN eliminates the received duplicated DL data and sends to NG-RAN.
• For UL data transmission, NG-RAN sends the received UL packets on N3 GTP-U tunnel, the Redundant functionality in the NG-RAN performs the redundant handling on the backhaul transport layer. The Redundant functionality in the UPF eliminates the received duplicated UL data and sends to UPF.

QoS Monitoring for packet delay can be applied based on 3rd party application request or PCF policy control or both, e.g. to assist URLLC services. The packet delay between UE and PSA UPF is a combination of the RAN part of UL/DL packet delay as defined in TS 38.314 and UL/DL packet delay between NG-RAN and PSA UPF. The NG-RAN is required to provide the QoS monitoring results on the RAN part of UL/DL packet delay measurement. The measurement of the UL/DL 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, subject to the operators' configuration. The PCF generates the authorized QoS Monitoring policy for a service data flow based on the QoS Monitoring request received from the AF (as described in clause 6.1.3.21 of TS 23.503). The PCF includes the authorized QoS Monitoring policy in the PCC rule and provides it to the SMF. When SMF receives the authorized QoS Monitoring policy for packet delay in a PCC rule from the PCF (as described in clause 6.1.3.21 of TS 23.503), SMF configures the UPF(s) and NG-RAN to perform delay measurements according to the method selected: per QoS Flow per UE QoS measurement (as described in clause 5.33.3.2) or per GTP-U Path measurement (as described in clause 5.33.3.3). The SMF configure the UPF to report the QoS monitoring results for the QoS Flow as described in clause 5.8.2.18 with parameters determined by the SMF based on the authorized QoS Monitoring policy received from the PCF and/or local configuration. The UPF reporting behaviour for QoS Monitoring for packet delay of a QoS Flow is the same when per QoS Flow per UE level measurement (described further in clause 5.33.3.2) or when per GTP-U path level measurement (described further in clause 5.33.3.3) is used.

SMF may activate the end to end UL/DL packet delay measurement between UE and PSA UPF for a QoS Flow during the PDU Session Establishment or Modification procedure. The SMF sends a QoS Monitoring request to the PSA UPF via N4 and NG-RAN via N2 signalling to request the QoS monitoring between PSA UPF and NG-RAN. The QoS Monitoring request may contain monitoring parameters determined by SMF based on the authorized QoS Monitoring policy received from the PCF and/or local configuration. The NG-RAN initiates the RAN part of UL/DL packet delay measurement based on the QoS Monitoring request from SMF. NG-RAN reports the RAN part of UL/DL packet delay result to the PSA UPF in the UL data packet or dummy UL packet. If the NG-RAN and PSA UPF are time synchronised, the one way packet delay monitoring between NG-RAN and PSA UPF is supported. If the NG-RAN and PSA UPF are not time synchronised, it is assumed that the UL packet delay and the DL packet delay between NG-RAN and PSA UPF are the same. For both time synchronised and not time synchronised between NG-RAN and PSA UPF, the PSA UPF creates and sends the monitoring packets to the RAN in a measurement frequency, decided by the PSA UPF, taking the Reporting frequency for QoS Monitoring received from the SMF into account:

• The PSA UPF encapsulates in the GTP-U header with QFI, QoS Monitoring Packet (QMP) indicator (which indicates the packet is used for UL/DL packet delay measurement) and the local time T1 when the PSA UPF sends out the DL monitoring packets.
• The NG-RAN records the local time T1 received in the GTP-U header and the local time T2 at the reception of the DL monitoring packets.
• When receiving an UL packet from UE for that QFI or when the NG-RAN sends a dummy UL packet as monitoring response (in case there is no UL service packet for UL packet delay monitoring), the NG-RAN encapsulates QMP indicator, the RAN part of UL/DL packet delay result, the time T1 received in the GTP-U header, the local time T2 at the reception of the DL monitoring packet and the local time T3 when NG-RAN sends out this monitoring response packet to the UPF via N3 interface, in the GTP-U header of the monitoring response packet.
• The PSA UPF records the local time T4 when receiving the monitoring response packets and calculates the round trip (if not time synchronized) or UL/DL packet delay (if time synchronized) between NG-RAN and anchor PSA UPF based on the time information contained in the GTP-U header of the received monitoring response packet. If the NG-RAN and PSA UPF are not time synchronised, the PSA UPF calculates the UL/DL packet delay between the NG-RAN and the PSA UPF based on the (T2-T1+T4-T3)/2. If the NG-RAN and PSA UPF are time synchronised, the PSA UPF calculates the UL packet delay and DL packet delay between the NG-RAN and the PSA UPF based on (T4-T3) and (T2-T1), respectively. The PSA UPF calculates the UL/DL packet delay between UE and PSA UPF based on the received RAN part of UL/DL packet delay result and the calculated UL/DL packet delay between RAN and PSA UPF.
• The PSA UPF reports the QoS Monitoring results as described in clause 5.8.2.18.

If the redundant transmission on N3/N9 interfaces is activated, the UPF and NG-RAN performs QoS monitoring for both UP paths. The UPF reports the packet delays of the two UP paths independently to the SMF.

The SMF can request to activate QoS monitoring for the GTP-U path(s) between all UPF(s) and the (R)AN based on locally configured policies. Alternatively, when a QoS monitoring policy is received in a PCC rule and the QoS monitoring is not yet active for the DSCP corresponding to the 5QI in the PCC rule, the SMF activates QoS Monitoring for all UPFs currently in use for this PDU Session and the (R)AN. In this case, the SMF performs the QoS Flow Binding without taking the QoS Monitoring Policy within the PCC rule into account. The SMF sends the QoS monitoring policy to each involved UPF and the (R)AN via N4 interface and via N2 interface respectively. A GTP-U sender performs an estimation of RTT to a GTP-U receiver on a GTP-U path by sending Echo messages and measuring time that elapses between the transmission of Request message and the reception of Response message. A GTP-U sender computes an accumulated packet delay by adding RTT/2, the processing time and, if available, an accumulated packet delay from an upstream GTP-U sender (i.e. an immediately preceding GTP-U sender in user plane path) thus the measured accumulated packet delay represents an estimated elapsed time since a user plane packet entered 3GPP domain. It is expected that a GTP-U sender determines RTT periodically in order to detect changes in transport delays. QoS monitoring is performed by a GTP-U end-point (UP function) that receives, stores and executes the QoS monitoring policy as described below for a QoS Flow. QoS monitoring is performed by comparing a measured accumulated packet delay with the stored parameters. If the GTP-U end-point (the PSA UPF, in the case of accumulated packet delay reporting) determines that the packet delay exceeds the value of a stored parameter, then the node triggers QoS monitoring alert signalling to the relevant SMF or to the OA&M function as further described in TS 29.244. When QoS Monitoring is used to measure the packet delay for a QoS Flow, the following applies:

• Packet delay measurement is performed by using GTP-U Echo Request/Response as defined in the TS 28.552, in the corresponding user plane transport path(s), independent of the corresponding PDU Session and the 5QI for a given QoS Flow.
• RAN measures and provides the RAN part of UL/DL packet delay towards UPF (in the GTP-U header of the respective QoS Flow via N3).
• The UPF calculates the UL/DL packet delay by combining the received measurements of RAN part with the measurements of N3/N9 interface (N9 is applicable when I-UPF exists).
• The UPF reports the QoS Monitoring results as described in clause 5.8.2.18.

QoS Monitoring can also be used to measure the packet delay for transport paths to influence the mapping of QoS Flows to appropriate network instances, DSCP values as follows:

• SMF activates QoS monitoring for the GTP-U path(s) between all UPF(s) and all (R)AN nodes based on locally configured policies.
• UPF does measurement of network hop delay per transport resources that it will use towards a peer network node identified by an IP destination address (the hop between these two nodes) and port. The network hop measured delay is computed by sending an Echo Request over such transport resource (Ti) and measuring RTT/2 when Echo Response is received.
• UPF maps {network instance, DSCP} into Transport Resource and measures delay per IP destination address and port. Thus, for each IP destination address, the measured delay per (network instance, DSCP) entry is determined.
• The UPF performing the QoS monitoring can provide the corresponding {Network instance, DSCP} along with the measured accumulated packet delay for the corresponding transport path to the SMF. The UPF reports the measurement results to the SMF based on some specific conditions e.g. first time, periodic, event triggered, when thresholds for reporting towards SMF (via N4) are reached.
• Based on this, SMF can determine QoS Flow mapping to the appropriate {Network instance, DSCP} considering {5QI, QoS characteristics, ARP} for the given QoS Flow.