5.20 Support of Access Traffic Steering, Switching and Splitting for 5GC

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

5.20.1 General

The Access Traffic Steering, Switching and Splitting (ATSSS) feature enables the support of Multi-Access (MA) PDU sessions, using one 3GPP access network or one non-3GPP access network at a time, or simultaneously using one 3GPP access network and one non-3GPP access network as defined in clauses 4.2.10 and 5.32 of 3GPP TS 23.501 [28].

A Multi-Access (MA) PDU session may support:

– both 3GPP access and non-3GPP access connected to 5GC, as specified in clause 4.22.2.1 and 4.22.2.2 of 3GPP TS 23.502 [29];

– 3GPP access connected to EPC while non-3GPP access is connected to 5GC, as specified in clause 4.22.2.3 of 3GPP TS 23.502 [29], subject to corresponding support by the UE.

The non-3GPP access network may be an untrusted non-3GPP access network, a trusted non-3GPP access network or a wireline 5G access network. The support of the ATSSS feature is optional for the SMF and the UPF.

When establishing a PFCP session for an MA PDU session, the SMF (H-SMF for a HR PDU session) shall select a PSA (UPF) supporting ATSSS (see MPTCP and ATSSS-LL flags in UP Function Features, Table 8.2.25-1), i.e. ATSSS-LL, MPTCP or both, and it shall provision in the PSA one Multi-Access Rule (MAR) for every downlink PDR matching non-GBR traffic sent towards the UE. See clause 5.2.7 for the handling of an MAR.

Distinct N3/N9 tunnels shall be established for each access network of the MA PDU session if the UE is registered to both 3GPP and non 3GPP access by:

– providing two UL PDRs to the PSA UPF in PFCP Session Establishment Request or PFCP Session Modification Request message, e.g. PDR-1 for UL data from 3GPP access and PDR-2 for UL data from non-3GPP access, to trigger the PSA UPF to allocate two N3/N9 UL CN tunnels as specified in clause 4.22.2.1 and clause 4.22.3.2 of 3GPP TS 23.502 [29];

– providing two FARs in one MAR associated to the DL PDR to the PSA UPF in PFCP Session Establishment Request or PFCP Session Modification Request message, e.g. FAR-1 for DL data forwarding to 3GPP access and FAR-2 for DL data forwarding to non-3GPP access.

5.20.2 MPTCP functionality

5.20.2.1 General

The SMF shall instruct the UPF(PSA) to activate MPTCP steering functionality for a given MA-PDU session if MPTCP needs to be used for TCP traffic flows.

The UPF(PSA) shall allocate resources for MPTCP steering functionality (e.g. MPTCP Proxy address, UE link-specific multipath IP addresses, etc.), and perform traffic steering, switching and splitting according to the instructions from the SMF.

5.20.2.2 Activate MPTCP functionality and Exchange MPTCP Parameters

If MPTCP steering functionality is required for a Multi-Access PDU session, the SMF shall send MPTCP Control Information to the UPF in PFCP Session Establishement Request, to instruct the UPF to activate the MPTCP functionality for this PFCP session. The SMF may also request to activate the PMF functionality for this PFCP session by sending PMF Control Information to the UPF. As a result, the UPF(PSA) shall allocate necessary resources for MPTCP and PMF and return the corresponding MPTCP and PMF Parameters (e.g. MPTCP IP address and port, UE link-specific multipath IP addresses, PMF IP address and port, etc.) to the SMF in PFCP Session Establishement Response.

The SMF may send MPTCP Control Information and/or PMF Control Information to the UPF in PFCP Session Modification Request, with updated value, e.g. if the SMF receives updated ATSSS rules from the PCF.

NOTE 1: Such MPTCP Parameters received by the SMF are sent to the UE together with the ATSSS rules, as specified in 3GPP TS 24.193 [59].

When provisioning an UL PDR for user plane traffic for which MPTCP is applicable, the SMF shall include an MPTCP Applicable Indication IE in the Create PDR IE.

NOTE 2: This indication can be used by the UPF to prepare itself for the reception of MPTCP traffic for the PDU session.

5.20.2.3 Control of Multipath TCP Connection Establishment by MPTCP Proxy

When MPTCP steering functionality is utilized, TCP connection establishment and data exchange between an UE and a remote host shall be proxide by the MPTCP Proxy in the UPF (PSA), using the mechanism specified in IETF RFC 8684 [62] and IETF RFC 8803 [60].

Once Multipath TCP connection is set up, the MPTCP Proxy shall store the MPTCP session entry which includes the following information:

– UE link-specific multipath IP addresses and its TCP port;

– UE’s MA-PDU session IP address and its TCP port, if the MA-PDU session IP address is used by the MPTCP Proxy for IP translation;

– the N6 routable IP address and its TCP port, if N6 routable IP address is used by the MPTCP Proxy for IP translation;

– the remote host IP address and its TCP port.

The stored MPTCP session entry is used by MPTCP Proxy for subsequent IP translation when receiving uplink or downlink MPTCP traffic.

An UPF implementation may use N6 routable IP address instead of UE’s MA-PDU session IP address for IP translation.

NOTE: The DL PDR from the SMF for MPTCP traffic carries the UE’s MA-PDU session IP address. If the UPF uses a different N6 routable IP address, it is UPF implementation specific how to match DL PDRs for MPTCP traffic with downlink MPTCP traffic received with the destination address set to the N6 routable IP address.

5.20.2.4 Traffic Steering and IP Translation by MPTCP Proxy

Once traffic for which MPTCP is applicable is detected by the UPF, the UPF shall internally forward this traffic to the MPTCP Proxy for IP translation. The MPTCP Proxy shall use the stored information in MPTCP session entry to perform IP translation to the detected MPTCP IP packets, e.g. replace the source IP address+port and/or destination IP address+port accordingly.

The UPF may detect the uplink IP packets for which MPTCP is applicable by checking whether the UL PDR matching the user plane traffic is set with an MPTCP Applicable Indication, or (UPF implementation choice) by checking whether the source or destination IP address of the user plane packets (after removing the GTP-U header) correspond to UE link-specific multipath IP address(es) and the MPTCP proxy IP address.

The UPF may detect the downlink IP packets for which MPTCP is applicable, by checking the information in the associated MAR (e.g. checking if the steering functionality is set to MPTCP) or by checking the destination IP address.

5.20.3 ATSSS-LL functionality

5.20.3.1 Activate ATSSS-LL functionality and Exchange ATSSS-LL Parameters

If ATSSS-LL steering functionality is required for a Multi-Access PDU session, the SMF shall send ATSSS-LL Control Information to the UPF in PFCP Session Establishment Request, to instruct the UPF to activate the ATSSS-LL functionality for this PFCP session. The SMF may also request to activate the PMF functionality for this PFCP session by sending PMF Control Information to the UPF.

If PMF functionality is required to be activated for this MA PDU session, the SMF shall set the PMFI flag to 1 in the PMF Control Information IE, regardless whether per QoS flow access performance measurement is required. In addition, if the SMF determines that per QoS flow access performance measurements shall be applied for the MA PDU session, e.g. the threshold value(s) are received from PCF for the UL and/or DL traffic of the QoS flow, the SMF shall set the PQPM flag to 1 together with a list of QFI values for the QoS flows for which access performance measurements may be performed in the PMF Control Information IE.

Upon receiving the request from the SMF with indicating ATSSS-LL Control Information IE and PMF Control Information IE, the UPF(PSA) shall allocate necessary resources for ATSSS-LL and PMF and return the corresponding ATSSS-LL and PMF Parameters (e.g. PMF IP address and port, etc) to the SMF in PFCP Session Establishment Response:

– If per access performance measurements are required, i.e. PMFI flag set to 1 in the PMF Control Information IE, the UPF(PSA) shall allocate a default pair of access specific UDP ports (i.e. for IP PDU sessions) or MAC addresses (i.e. for Ethernet PDU sessions) and report them to the SMF in the PMF Address Information IE of a PMF Parameters IE not including the QoS flow identifier IE.

– If per QoS flow access performance measurements are required, i.e. PQPM flag is set to 1 in addition and a list of QFIs are indicated in the PMF Control Information IE, the UPF(PSA) shall allocate access specific UDP ports (i.e. for IP PDU sessions) or MAC addresses (i.e. for Ethernet PDU sessions) for each QoS flow indicated in the PMF Control Information and, for each QoS flow, report them to the SMF in the PMF Address Information IE of a PMF Parameters IE including the QoS flow identifier IE set to the corresponding QFI.

If the SMF provisions the UPF to apply ATSSS-LL in downlink with "Smallest Delay" steering mode, the UE does not support PMF RTT measurements (see clause 5.32.2 of 3GPP TS 23.501 [28]) and the UPF supports RTT measurements without PMF, the SMF should instruct the UPF to not use PMF RTT measurements by setting the DRTTI flag to "1" in the PMF Control Information.

NOTE 1: The UPF can measure RTT without using the PMF protocol by using other means not defined by 3GPP such as using the RTT measurements of MPTCP if there is an MPTCP connection established between the UE and UPF.

The SMF may send ATSSS-LL Control Information and/or PMF Control Information to the UPF in PFCP Session Modification Request, with updated value, e.g. if the SMF receives updated ATSSS rules from the PCF.

NOTE 2: Such ATSSS-LL Parameters received by the SMF are sent to the UE together with the ATSSS rules, as specified in 3GPP TS 24.193 [59].

5.20.4 Handling of GBR traffic of a MA PDU session

5.20.4.1 General

Traffic splitting of a GBR traffic is not supported (see clause 5.32.4 of 3GPP TS 23.501 [28]). Besides, switching GBR traffic from one access to another access requires the SMF to send N1/N2 messages to the UE and AN.

DL PDRs corresponding to GBR traffic shall be associated with DL FARs (i.e. no MAR).

5.20.4.2 Access Availability Reporting

For an MA PDU session using the ATSSS Low Layer (ATSSS-LL) or MPTCP steering functionality, the SMF may request the UPF to report when it cannot send downlink GBR traffic over its on-going access, e.g. based on access availability and unavailability report from the UE, by provisioning an SRR with an Access Availability Control Information IE requesting the UPF to report when an access (3GPP or non-3GPP access) becomes available or unavailable.

If so instructed, when detecting a change in an access availability, the UPF shall send an Access Availability Report to the SMF, indicating the access type and whether the access has become available or unavailable.

5.20.5 Access type of an MA PDU session becoming (un)available

The access type of an MA PDU session may become unavailable permanently (e.g. when the UE de-registers from one access) or transiently (e.g. when the UE has lost coverage of the 3GPP access or non-3GPP access).

When an access type of an MA PDU session becomes permanently unavailable, the SMF shall send a PFCP Session Modification Request with an Update MAR IE removing the Access Forwarding Information IE corresponding to the unavailable access. As a result, the UPF shall not send any more traffic on this access type.

Reversely, when a new access type becomes available for an MA PDU session, e.g. when the UE registers on another access and requests to establish user plane resources for that access, the SMF shall send a PFCP Session Modification Request with an Update MAR IE adding the Access Forwarding Information IE corresponding to the new available access type.

When an access type of an MA PDU session becomes transiently unavailable, the SMF shall notify the UPF that the access type has become unavailable by sending a PFCP Session Modification Request with the Access Availability Information IE indicating so. The SMF should then also notify the UPF when the access type becomes available again.

When being notified by the SMF that an access type has become transiently unavalaible, the UPF should stop sending DL traffic on this access until it receives the indication that the access becomes available again from the UE (i.e. PMF access available report) or the SMF.

5.20.6 PMFP message handling in UPF

The access performance measurement supports the following procedures, as specified in clause 5.32.5.1 of 3GPP TS 23.501 [28]:

– RTT measurement procedure initiated by the UE, or the UPF;

– Packet Loss Rate measurement procedure initiated by the UE, or the UPF;

– Access available/unavailable report procedure from the UE to the UPF;

– UE Assistance Data provisioning procedure from the UE to the UPF.

The per QoS flow access performance measurement procedure includes the RTT measurement and the Packet Loss Rate measurement, which may be initiated by the UE or the UPF(PSA).

PMFP messages are used by the PMF functionality in the UE and the PMF functionality in the UPF (PSA) to perform the access performance measurement procedures, as specified in 3GPP TS 24.193 [59].

PMFP messages shall be exchanged between the UE and the UPF via the default QoS flow or a dedicated QoS flow, as specified in 3GPP TS 23.501 [28]. To support this, the UPF shall learn the QFI identifying the QoS flow on which PMFP messages from the UE are transmitted, and shall send downlink PMFP messages on that QoS flow when needed.

Once an uplink PMFP message is detected, the UPF shall internally forward the PMFP message to the PMF functionality in the UPF, for subsequent handling.

The PMF functionality in the UPF shall learn the UE’s address information for PMFP from the received PMFP message, e.g. to detect the IP address and UDP port of the PMF in the UE (for IP PDU sessions) or the MAC address of the PMF in the UE (for Ethernet PDU sessions), and set the source and destination addresses of PMFP messages sent to the UE accordingly, as specified in clause 5.32.5.1A of 3GPP TS 23.501 [28].

If the Steering mode is set to Load-Balancing and the UE Assistance Indicator is set, when the UPF receives a PMF message with UE Assistance Data (i.e. PMF-UAD message) from the UE, the UPF may apply the split percentages in the UE Assistance Data to all DL traffic for which the SMF has enabled the UE assistance operation. Meanwhile, the UPF shall store the original split percentage (i.e. the weight included in 3GPP/Non-3GPP Access Forwarding Action Information IE in the MAR) provisioned by the SMF, and apply these when the UE assistance mode is terminated, i.e. when the UPF receives a PMF message indicating the termination of UE assistance mode (i.e. PMF-UAT message).