5.32 Support for ATSSS

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.32.1 General

The ATSSS feature is an optional feature that may be supported by the UE and the 5GC network.

The ATSSS feature enables a multi-access PDU Connectivity Service, which can exchange PDUs between the UE and a data network by simultaneously using one 3GPP access network and one non-3GPP access network and two independent N3/N9 tunnels between the PSA and RAN/AN. The multi-access PDU Connectivity Service is realized by establishing a Multi-Access PDU (MA PDU) Session, i.e. a PDU Session that may have user-plane resources on two access networks. This assumes both 3GPP access and non-3GPP access are allowed for the S-NSSAI of the PDU Session.

The UE may request a MA PDU Session when the UE is registered via both 3GPP and non-3GPP accesses, or when the UE is registered via one access only.

After the establishment of a MA PDU Session, and when there are user-plane resources on both access networks, the UE applies network-provided policy (i.e. ATSSS rules) and considers local conditions (such as network interface availability, signal loss conditions, user preferences, etc.) for deciding how to distribute the uplink traffic across the two access networks. Similarly, the UPF anchor of the MA PDU Session applies network-provided policy (i.e. N4 rules) and feedback information received from the UE via the user-plane (such as access network Unavailability or Availability) for deciding how to distribute the downlink traffic across the two N3/N9 tunnels and two access networks. When there are user-plane resources on only one access network, the UE applies the ATSSS rules and considers local conditions for triggering the establishment or activation of the user plane resources over another access.

The type of a MA PDU Session may be one of the following types defined in clause 5.6.1: IPv4, IPv6, IPv4v6, and Ethernet. In this release of the specification, the Unstructured type is not supported. The clause 5.32.6.2.1 and the clause 5.32.6.3.1 below define what Steering Functionalities can be used for each supported type of a MA PDU Session.

The handling of 3GPP PS Data Off feature for MA PDU Session is specified in clause 5.24.

The ATSSS feature can be supported over any type of access network, including untrusted and trusted non-3GPP access networks (see clauses 4.2.8 and 5.5), wireline 5G access networks (see clause 4.2.8), etc., as long as a MA PDU Session can be established over this type of access network.

In this Release of the specification, a MA PDU Session using IPv6 multi-homing (see clause 5.6.4.3) or UL Classifier (see clause 5.6.4.2) is not specified.

In this Release of the specification, support for ATSSS assumes SMF Service Areas covering the whole PLMN or that a MA PDU Session is released over both accesses when the UE moves out of the SMF Service Area.

A MA PDU Session does not support LADN. If the AMF receives a request to establish a MA PDU Session for a LADN DNN, the AMF shall reject the request. If the AMF receives a request to establish a PDU Session for a LADN DNN with "MA PDU Network-Upgrade Allowed" indication, the AMF shall not forward "MA PDU Network-Upgrade Allowed" indication to the SMF.

If the UE, due to mobility, moves from being served by a source AMF supporting ATSSS to a target AMF not supporting ATSSS, the MA PDU Session is released as described in TS 23.502 [3].

NOTE 1: Deployment of ATSSS that is homogeneous per PLMN or network slice enables consistent behaviour. In the case of non-homogenous support of ATSSS in a PLMN/slice (i.e. some NFs in a PLMN/slice may not support ATSSS), MA PDU Sessions can be released due to UE mobility.

A Multi-Access PDU Session may for the 3GPP access use user-plane resources of an associated PDN Connection on 3GPP access in EPC instead of the 3GPP access to 5GC. This enables a scenario where a MA PDU Session can simultaneously be associated with user-plane resources on 3GPP access network connected to EPC and non-3GPP access connected to 5GC. Such use of ATSSS with EPS interworking may apply to Ethernet and IP-based PDU Session and PDN Connection types.

NOTE 2: A MA PDU Session with one 3GPP access connected to 5GC and one non-3GPP access connected to EPC is not supported.

NOTE 3: Co-existence with NBIFOM is not defined. It is assumed that NBIFOM and the multi-access connectivity described in this clause are not deployed in the same network.

NOTE 4: To the MME and SGW this is a regular PDN Connection and the support for ATSSS is transparent to MME and SGW.

For a MA PDU Session established for the Ethernet PDU Session type, if the UE has not indicated support for Ethernet PDN connection type or if the network does not support Ethernet PDN connection type, when the 3GPP access use user-plane resources of an associated PDN Connection, the following takes place:

– The SMF+PGW-C considers that the Multi-Access PDU Session is still using the Ethernet PDU Session / PDN Connection type but in a restricted mode where EPS signalling can only refer to non-IP PDN Connection type.

– MAR rules in the UPF are still used for distributing DL traffic between 3GPP access and non-3GPP access.

– For traffic on 3GPP access, the SMF may update N4 rules and QoS rules/EPS bearer contexts on the UE to take into account that no QoS differentiation is possible over 3GPP access.

This support of Multi-Access PDU Sessions using for the 3GPP access user-plane resources of an associated PDN Connection instead of the 3GPP access to 5GC is further defined in TS 23.502 [3].

The following clauses specify the functionality that enables ATSSS.

5.32.2 Multi Access PDU Sessions

A Multi-Access PDU (MA PDU) Session is managed by using the session management functionality specified in clause 5.6, with the following additions and modifications:

– When the UE wants to request a new MA PDU Session:

– If the UE is registered to the same PLMN over 3GPP and non-3GPP accesses, then the UE shall send a PDU Session Establishment Request over any of the two accesses. The UE also provides Request Type as "MA PDU Request" in the UL NAS Transport message. The AMF informs the SMF that the UE is registered over both accesses and this triggers the establishment of user-plane resources on both accesses and two N3/N9 tunnels between PSA and the RAN/AN.

– If the UE is registered to different PLMNs over 3GPP and non-3GPP accesses, then the UE shall send a PDU Session Establishment Request over one access. The UE also provides Request Type as "MA PDU Request" in the UL NAS Transport message. After this PDU Session is established with one N3/N9 tunnel between the PSA and (R)AN established, the UE shall send another PDU Session Establishment Request over the other access. The UE also provides the same PDU Session ID and Request Type as "MA PDU Request" in the UL NAS Transport message. Two N3/N9 tunnels and User-plane resources on both accesses are established.

– If the UE is registered over one access only, then the UE shall send a PDU Session Establishment Request over this access. The UE also provides Request Type as "MA PDU Request" in the UL NAS Transport message. One N3/N9 tunnel between the PSA and (R)AN and User-plane resources on this access only are established. After the UE is registered over the second access, the UE shall establish user-plane resources on the second access.

– In the PDU Session Establishment Request that is sent to request a new MA PDU Session, the UE shall provide also its ATSSS capabilities, which indicate the steering functionalities and the steering modes supported in the UE. These functionalities are defined in clause 5.32.6.

– If the UE indicates it is capable of supporting the ATSSS-LL functionality with any steering mode (as specified in clause 5.32.6.1) and the network accepts to activate this functionality, then the network may provide to UE Measurement Assistance Information (see details in clause 5.32.5) and shall provide to UE one or more ATSSS rules.

– If the UE indicates it is capable of supporting the MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the Active-Standby steering mode (as specified in clause 5.32.6.1) and the network accepts to activate these functionalities, then the network provides MPTCP proxy information to UE, and allocates to UE one IP address/prefix for the MA PDU session (as defined in clause 5.8.2.2) and two additional IP addresses/prefixes, called "link-specific multipath" addresses. Further details are provided in clause 5.32.6.2. In addition, the network may provide to UE Measurement Assistance Information and shall provide to UE one or more ATSSS rules including an ATSSS rule for non-MPTCP traffic. The ATSSS rule for non-MPTCP traffic shall use the ATSSS-LL functionality and the Active-Standby Steering Mode to indicate how the non-MPTCP traffic shall be transferred across the 3GPP access and the non-3GPP access in the uplink direction.

– If the UE indicates it is capable of supporting the MPTCP functionality with any steering mode and the ATSSS-LL functionality with any steering mode (as specified in clause 5.32.6.1) and the network accepts to activate these functionalities, then the network provides MPTCP proxy information to UE, and allocates to UE one IP address/prefix for the MA PDU session (as defined in clause 5.8.2.2) and two additional IP addresses/prefixes, called "link-specific multipath" addresses. Further details are provided in clause 5.32.6.2. In addition, the network may provide to UE Measurement Assistance Information and shall provide to UE one or more ATSSS rules.

– If the UE requests an S-NSSAI, this S-NSSAI should be allowed on both accesses. Otherwise, the MA PDU Session shall not be established.

– The SMF determines the ATSSS capabilities supported for the MA PDU Session based on the ATSSS capabilities provided by the UE and per DNN configuration on SMF, as follows:

a) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode" (as specified in clause 5.32.6.1), the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, including RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPTCP and ATSSS-LL with any steering mode in the downlink, and (2) MPTCP and ATSSS-LL with Active-Standby mode in the uplink.

NOTE 1: In this case, it is assumed that ATSSS-LL with "Smallest Delay" steering mode is selected for the downlink only when the UPF can measure RTT without using the PMF protocol, e.g. by using other means not defined by 3GPP such as using the RTT measurements of MPTCP.

b) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode" (as specified in clause 5.32.6.1), the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, but not RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPTCP with any steering mode in the downlink (2) ATSSS-LL with any steering mode except Smallest Delay steering mode in the downlink, and (3) MPTCP and ATSSS-LL with Active-Standby mode in the uplink.

c) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode" (as specified in clause 5.32.6.1) and if the DNN configuration allows MPTCP with any steering mode and ATSSS-LL with only Active-Standby steering mode, the MA PDU Session is capable of MPTCP and ATSSS-LL with Active-Standby mode in the uplink and in the downlink.

d) If the UE includes in its ATSSS capabilities "ATSSS-LL functionality with any steering mode" (as specified in clause 5.32.6.1) and the DNN configuration allows ATSSS-LL with any steering mode, the MA PDU Session is capable of ATSSS-LL with any steering mode in the uplink and in the downlink.

e) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode" (as specified in clause 5.32.6.1), and the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, the MA PDU Session is capable of both MPTCP and ATSSS-LL with any steering mode in the uplink and in the downlink.

The SMF provides the ATSSS capabilities of the MA PDU Session to the PCF during PDU Session Establishment.

– The PCC rules provided by PCF include MA PDU Session Control information (see TS 23.503 [45]). They are used by SMF to derive ATSSS rules for the UE and N4 rules for the UPF. When dynamic PCC is not used for the MA PDU Session, the SMF shall provide ATSSS rules and N4 rules based on local configuration (e.g. based on DNN or S-NSSAI).

– The UE receives ATSSS rules from SMF, which indicate how the uplink traffic should be routed across 3GPP access and non-3GPP access. Similarly, the UPF receives N4 rules from SMF, which indicate how the downlink traffic should be routed across 3GPP access and non-3GPP access.

– When the SMF receives a PDU Session Establishment Request and a "MA PDU Request" indication and determines that UP security protection (see clause 5.10.3) is required for the PDU Session, the SMF shall only confirm the establishment of the MA PDU session if the 3GPP access network can enforce the required UP security protection. The SMF needs not confirm whether the non-3GPP access can enforce the required UP security protection.

– After the MA PDU Session establishment:

– At any given time, the MA PDU session may have user-plane resources on both 3GPP and non-3GPP accesses, or on one access only, or may have no user-plane resources on any access.

– The AMF, SMF, PCF and UPF maintain their MA PDU Session contexts, even when the UE deregisters from one access (but remains registered on the other access).

– When the UE deregisters from one access (but remains registered on the other access), the AMF informs the SMF to release the resource of this access type in the UPF for the MA PDU Session. Subsequently, the SMF notifies the UPF that the access type has become unavailable and the N3/N9 tunnel for the access type are released.

– If the UE wants to add user-plane resources on one access of the MA PDU Session, e.g. based on access network performance measurement and/or ATSSS rules, then the UE shall send a PDU Session Establishment Request over this access containing PDU Session ID of the MA PDU Session. The UE also provides Request Type as "MA PDU Request" and the same PDU Session ID in the UL NAS Transport message. If there is no N3/N9 tunnel for this access, the N3/N9 tunnel for this access is established.

– If the UE wants to re-activate user-plane resources on one access of the MA PDU Session, e.g. based on access network performance measurement and/or ATSSS rules, then the UE shall initiate the UE Triggered Service Request procedure over this access.

– If the network wants to re-activate the user-plane resources over 3GPP access or non-3GPP access of the MA PDU Session, the network shall initiate the Network Triggered Service Request procedure, as specified in clause 4.22.7 of TS 23.502 [3].

– The SMF may add, remove or update one or more individual ATSSS rules of the UE by sending new or updated ATSSS rules with the corresponding Rule IDs to the UE.

A MA PDU Session may be established either:

a) when it is explicitly requested by an ATSSS-capable UE; or

b) when an ATSSS-capable UE requests a single-access PDU Session but the network decides to establish a MA PDU Session instead. This is an optional scenario specified in clause 4.22.3 of TS 23.502 [3], which may occur when the UE requests a single-access PDU Session but no policy (e.g. no URSP rule) and no local restrictions in the UE mandate a single access for the PDU Session.

A MA PDU Session may be established during a PDU Session modification procedure when the UE moves from EPS to 5GS, as specified in clause 4.22.6.3 of TS 23.502 [3].

The AMF indicates as part of the Registration procedure whether ATSSS is supported or not. When ATSSS is not supported, the UE shall not

– request establishment of a MA PDU Session (as described in clause 4.22.2 of TS 23.502 [3]); or

– request addition of User Plane resources for an existing MA PDU Session (as described in clause 4.22.7 of TS 23.502 [3]); or

– request establishment of a PDU Session with "MA PDU Network-Upgrade Allowed" indication (as described in clause 4.22.3 of TS 23.502 [3]); or

– request PDU Session Modification with Request Type of "MA PDU request" or with "MA PDU Network-Upgrade Allowed" indication after moving from EPC to 5GC (as described in clause 4.22.6.3 of TS 23.502 [3]).

An ATSSS-capable UE may decide to request a MA PDU Session based on the provisioned URSP rules. In particular, the UE should request a MA PDU Session when the UE applies a URSP rule, which triggers the UE to establish a new PDU Session and the Access Type Preference component of the URSP rule indicates "Multi-Access" (see TS 23.503 [45]).

5.32.3 Policy for ATSSS Control

If dynamic PCC is to be used for the MA PDU Session, the PCF may take ATSSS policy decisions and create PCC rules that contain MA PDU Session Control information, (as specified in TS 23.503 [45]), which determines how the uplink and the downlink traffic of the MA PDU Session should be distributed across the 3GPP and non-3GPP accesses. If dynamic PCC is not deployed, local policy in SMF is used.

The SMF receives the PCC rules with MA PDU Session Control information and maps these rules into (a) ATSSS rules, which are sent to the UE, and (b) N4 rules, which are sent to the UPF. The ATSSS rules are provided as a prioritized list of rules (see clause 5.32.8), which are applied by the UE to enforce the ATSSS policy in the uplink direction and the N4 Rules are applied by the UPF to enforce the ATSSS policy in the downlink direction.

The ATSSS rules are sent to UE with a NAS message when the MA PDU Session is created or updated by the SMF, e.g. after receiving updated/new PCC rules from the PCF. Similarly, the N4 rules are sent to UPF when the MA PDU Session is created or updated by the SMF.

The details of the policy control related to ATSSS are specified in TS 23.503 [45].

5.32.4 QoS Support

The 5G QoS model for the Single-Access PDU Session is also applied to the MA PDU Session, i.e. the QoS Flow is the finest granularity of QoS differentiation in the MA PDU Session. One difference compared to the Single-Access PDU Session is that in a MA PDU Session there can be separate user-plane tunnels between the AN and the PSA, each one associated with a different access. However, the QoS Flow is not associated with specific access, i.e. it is access agnostic, so the same QoS is supported when the traffic is distributed over 3GPP and non-3GPP accesses. The SMF shall provide the same QFI in 3GPP and non-3GPP accesses so that the same QoS is supported in both accesses.

A QoS Flow of the MA PDU Session may be either Non-GBR or GBR depending on its QoS profile.

For a Non-GBR QoS Flow, the SMF provides a QoS profile 5G-AN(s) during MA PDU Session Establishment or MA PDU Session Modification procedure:

– During MA PDU Session Establishment procedure, the QoS profile to both ANs if the UE is registered over both accesses.

– During MA PDU Session Modification procedure, the QoS profile is provided to the 5G-AN(s) over which the user plane resources are activated.

For a GBR QoS Flow, the SMF shall provide a QoS profile to a single access network as follows:

– If the PCC rule allows a GBR QoS Flow in a single access, the SMF provides the QoS profile for the GBR QoS Flow to the access network allowed by the PCC rule.

– If the PCC rule allows a GBR QoS Flow in both accesses, the SMF decides to which access network to provide the QoS profile for the GBR QoS Flow based on its local policy (e.g. the access where the traffic is ongoing according to the Multi Access Routing rules).

For a GBR QoS Flow, traffic splitting is not supported because the QoS profile is provided to a single access network at a given time. If the UPF determines that it cannot send GBR traffic over the current ongoing access e.g. based on the N4 rules and access availability and unavailability report from the UE as described in clause 5.32.5.3, the UPF shall send an Access Availability report to the SMF. Based on the report, the SMF decides whether to move GBR QoS Flows to the other access:

– if the PCC rule allows the GBR QoS Flows only on this access, the SMF shall release the resources for the GBR QoS Flow and report to the PCF about the removal of the PCC rule.

– if the corresponding PCC rule allows the GBR QoS Flow on both accesses and the other access is not available, the SMF shall release the resources for the GBR QoS Flow and report to the PCF about the removal of the PCC rule.

– if the PCC rule allows the GBR QoS Flow on both accesses and the other access is available, the SMF shall try to move the GBR QoS Flow to the other access. The SMF may trigger a PDU session modification procedure to provide the QoS profile to the other access and release the resources for the GBR QoS Flow in the current access.

– If Notification Control parameter is not included in the PCC rule for the GBR QoS Flow and the other access does not accept the QoS profile, the SMF shall release the resources for the GBR QoS Flow and report to the PCF about the removal of the PCC rule.

– if the Notification Control parameter is included in the PCC rule, the SMF shall notify the PCF that GFBR can no longer be guaranteed. After the other access accepts the QoS profile, the SMF shall notify the PCF that GFBR can again be guaranteed. If the other access does not accept the QoS profile, the SMF shall delete the GBR QoS Flow and report to the PCF about the removal of the PCC rule.

NOTE 1: The ATSSS rule for GBR QoS Flow only allows the UE to steer traffic over a single access so that network knows in which access the UE sends GBR traffic. If the network wants to move GBR QoS Flow to the other access, the network needs to update ATSSS rule of the UE.

When the MA PDU Session is established or when the MA PDU Session is modified, the SMF may provide QoS rule(s) to the UE via one access, which are applied by the UE as specified in clause 5.7.1.4. The QoS rule(s) provided by SMF via one access are commonly used for both 3GPP access and non-3GPP access, so the QoS classification is independent of ATSSS rules.

The derived QoS rule generated by Reflective QoS is applied independently of the access on which the RQI was received. When the MPTCP functionality is used in the UE, the UE shall use the IP address/prefix of the MA PDU Session and the final destination address to generate the derived QoS rule.

When MPTCP functionality is enabled for the MA PDU Session:

– any QoS rules or PDRs that apply to the MA PDU Session IP address/prefix and port also apply to the "link-specific multipath" addresses/prefixes and ports used by the UE to establish MPTCP subflows over 3GPP and non-3GPP accesses; and

– any QoS rules or PDRs that apply to the IP address/prefix and port of the final destination server in DN also apply to the IP address and port of the MPTCP proxy for corresponding MPTCP subflows that are terminated at the proxy.

NOTE 2: How these associations are made is left up to the UE and UPF implementations.

5.32.5 Access Network Performance Measurements

5.32.5.1 General principles

When an MA PDU Session is established, the network may provide the UE with Measurement Assistance Information. This information assists the UE in determining which measurements shall be performed over both accesses, as well as whether measurement reports need to be sent to the network.

Measurement Assistance Information shall include the addressing information of a Performance Measurement Function (PMF) in the UPF, the UE can send PMF protocol messages to:

– For a PDU Session of IP type, Measurement Assistance Information contains one IP address for the PMF, one UDP port associated with 3GPP access and another UDP port associated with non-3GPP access. PMF messages sent by UE to one of these UDP ports, shall be transmitted to UPF via the QoS Flow associated with the default QoS rule.

– For a PDU Session of Ethernet type, Measurement Assistance Information contains one MAC address associated with 3GPP access and another MAC address associated with non-3GPP access. PMF messages sent by UE to one of these MAC addresses, shall be transmitted to UPF via the QoS Flow associated with the default QoS rule.

NOTE 1: To protect the PMF in the UPF (e.g. to block DDOS to the PMF), the IP addresses of the PMF are only accessible from the UE IP address via the N3/N9 interface.

NOTE 2: After the MA PDU Session is released, the same UE IP address/prefix is not allocated to another UE for MA PDU Session in a short time.

If the SMF determines that access performance measurements per QoS Flow shall be applied for the MA PDU Session, then the Measurement Assistance Information shall also include a list of QoS Flows on which access performance measurements may be performed. For each QoS Flow in this list, the following information is included:

– The QFI of the associated QoS Flow.

– For a PDU Session of IP type, one UDP port associated with 3GPP access and another UDP port associated with non-3GPP access. PMF messages sent by UE to one of these UDP ports, shall be transmitted to UPF via the associated QoS Flow.

– For a PDU Session of Ethernet type, one MAC address associated with 3GPP access and another MAC address associated with non-3GPP access. PMF messages sent by UE to one of these MAC addresses, shall be transmitted to UPF via the associated QoS Flow.

The QoS rules and the N4 rules provided by SMF to UE and to UPF respectively shall include information (e.g. packet filters containing the UDP port or the MAC address associated with a QoS Flow), which enables the UE and UPF to route a PMF message to a specific QoS Flow.

The UE and the UPF may need to perform access performance measurements in order to estimate the Round-Trip Time (RTT) and/or the Packet Loss Rate (PLR) that an SDF is expected to experience when transmitted on a certain access type. Based on these measurements and the provisioned ATSSS rules in the UE and MAR rules in the UPF, the UE and the UPF decide how to distribute the traffic of an SDF across the two accesses.

If the UE and the UPF decide to initiate access performance measurements to estimate the RTT and/or the PLR for an SDF, the access performance measurements shall be performed either

(a) using the QoS Flow associated with the default QoS rule; or

(b) using the target QoS Flow, which is the QoS Flow that the SDF traffic is transmitted on.

When the access performance measurements are using the target QoS Flow, it is termed that "access performance measurements per QoS Flow" are applied for the MA PDU Session.

The UE shall indicate in its ATSSS capabilities that it supports access performance measurements per QoS Flow. Based on this UE capability and other information (such as local policy), the SMF determines whether access performance measurements per QoS Flow shall be applied for the MA PDU Session or not. If the SMF determines that access performance measurements per QoS Flow shall be applied for the MA PDU Session, then:

– The SMF determines a list of QoS Flows over which access performance measurements may be performed and provides this list to the UE (within the Measurement Assistance Information) and to the UPF.

– The UE and the UPF may initiate access performance measurements on one or more of the QoS Flows included in this list. The UE and the UPF shall be able to receive and respond to PMF messages sent on any QoS Flow included in this list.

– The SMF may update the list of QoS Flows over which access performance measurements may be performed during the lifetime of a MA PDU Session, e.g. when a new PCC rule that could benefit from PMF access performance measurements is bound to a QoS Flow.

NOTE 3: The SMF can e.g. add a QoS Flow into the list when at least one PCC Rule is bound to that QoS Flow that is using one of the Steering Modes where performance measurements via PMF are applicable, such as Lowest Delay Steering Mode or a Steering Mode where threshold values have been provided.

The UE shall perform access performance measurements per QoS Flow only when this is explicitly indicated in the Measurement Assistance Information, i.e. only when the UE receives the list of QoS Flows over which access performance measurements may be performed. Otherwise, the UE shall perform access performance measurements based on the QoS Flow associated with the default QoS rule. The UPF shall perform access performance measurements per QoS Flow only when this is explicitly indicated by SMF, i.e. only when the UPF receives the list of QoS Flows over which access performance measurements may be performed. Otherwise, the UPF shall perform access performance measurements based on the QoS Flow associated with the default QoS rule. In this case the UPF learns what QoS Flow to use as described in TS 29.244 [65].

The UE and the UPF may decide not to initiate access performance measurements using PMF over a certain target QoS Flow, when they already have access performance measurements for another target QoS Flow which they determine can be reused.

NOTE 4: How the UE and UPF determine that the performance measurements using a certain target QoS Flow apply to another target QoS Flow is based on implementation, e.g. AN resource to QoS Flow mapping in the UE or getting similar access measurements results with other QoS Flow.

When access performance measurements for an SDF are performed based on the target QoS Flow, the UE needs to be able to determine the QoS Flow a downlink packet arrives on. In order to enable this, the SMF shall include downlink Packet Filter information in the QoS rule provided to UE matching this SDF, unless Reflective QoS is used for the SDF.

NOTE 5: For example, if a QoS Flow requires to activate Reflective QoS, the SMF does not need to provide downlink QoS Flow information for the QoS Flow to minimize usage of packet filters. When a data packet is received over a QoS Flow, the UE can decide whether to check the downlink QoS Flow information based on the existence of SDAP header for the QoS Flow.

The addressing information of the PMF in the UPF is retrieved by the SMF from the UPF during N4 session establishment. If the UPF receives from the SMF, during N4 session establishment or modification procedure, a list of QoS Flows over which access performance measurements may be performed, the UPF allocates different UDP ports per QoS Flow per access for IP PDU sessions, or allocates different MAC addresses per QoS Flow per access for Ethernet PDU sessions. For IP PDU sessions, the UPF sends the PMF IP addressing information and the UDP ports with the QFI of the associated QoS Flow to the SMF. For Ethernet PDU sessions, the UPF sends the MAC addresses with the QFI of the associated QoS Flow to the SMF.

The following PMF protocol messages can be exchanged between the UE and the PMF:

– Messages to allow for Round Trip Time (RTT) measurements, i.e. when the "Smallest Delay" steering mode is used or when either "Priority-based" or "Load-Balancing" steering mode is used with RTT threshold value being applied;

– Messages to allow for Packet Loss Rate (PLR) measurements, i.e. when steering mode is used either "Priority-based" or "Load-Balancing" steering mode is used with PLR threshold value being applied;

– Messages for reporting Access availability/unavailability by the UE to the UPF.

– Messages for sending UE-assistance data to UPF. Such messages may be sent from the UE to UPF only when the UE receives the UE-assistance indicator in an ATSSS rule, as specified in clause 5.32.8. Further details are provided in clause 5.32.5.5.

Since steering modes can be different in up-link and down-link, the UE needs to be able to handle PMF protocol messages for RTT and PLR measurements received from UPF even if it is not using one of the steering modes associated with the RTT and PLR measurements (and vice versa).

The PMF protocol is specified in TS 24.193 [109].

The PMF protocol messages used for access availability/unavailability reports shall be sent on the QoS Flow associated with the default QoS rule. The PMF protocol messages used for access performance measurements shall be sent either on the QoS Flow associated with the default QoS rule, or on the target QoS Flow, as specified above.

The QoS Flow associated with the default QoS rule for MA PDU Session is Non-GBR QoS Flow.

The UE shall not apply the ATSSS rules and the UPF shall not apply the MAR rules for the PMF protocol messages.

When the UE requests a MA PDU session and indicates it is capable to support the MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the Active-Standby steering mode (as specified in clause 5.32.6.1), the network may send Measurement Assistance Information for the UE to send Access availability/unavailability reports to the UPF. In this case, the UE and UPF shall not perform RTT and PLR measurements using PMF as the UE and UPF can use measurements available at the MPTCP layer.

5.32.5.1a Address of PMF messages

As described in clause 5.32.5.2, 5.32.5.2a and 5.32.5.3, a UE and UPF may exchange PMF messages to measure access performance and report access availability/unavailability. When the UE and UPF exchanges PMF message, source and destination address of the PMF messages shall be assigned as follows:

1. In the case of a MA PDU Session of IP type:

– If access performance measurements are performed only over the QoS Flow associated with the default QoS rule, the PMF in the UE sends PMF messages to the PMF in the UPF over UDP/IP. The destination IP address is the IP address contained in the Measurement Assistance Information and the destination UDP port is one of the two UDP ports contained in the Measurement Assistance Information. One UDP port is used for sending PMF messages to UPF over 3GPP access and the other UDP port is used for sending PMF messages to UPF over non-3GPP access. The source IP address is the IP address assigned to UE for the MA PDU Session and the source UDP port is a UDP port that is dynamically allocated by the UE for PMF communication. This source UDP port in the UE remains the same for the entire lifetime of the MA PDU Session.

If access performance measurements per QoS Flow is performed, the Measurement Assistance Information contains UDP ports, one for each QoS Flow and access combination. When the UE sends PMF message over a QoS Flow of an access, the UE shall set the destination UDP port as the UDP port for the QoS Flow and the access in Measurement Assistance information.

– If access performance measurements are performed only over the QoS Flow associated with the default QoS rule, the PMF in the UPF sends PMF messages to the PMF in the UE over UDP/IP. The source IP address is the same IP address as the one provided in the Measurement Assistance Information and the source UDP port is one of the two UDP ports as provided in the Measurement Assistance Information. One UDP port is used for sending PMF messages to UE over 3GPP access and the other UDP port is used for sending PMF messages to UE over the non-3GPP access. The destination IPv4 address is the IPv4 address assigned to UE for the MA PDU Session (if any) and the destination IPv6 address is an IPv6 address selected by the UE from the IPv6 prefix assigned for the MA PDU Session (if any). The destination UDP port is the dynamically allocated UDP port in the UE, which is contained in all PMF messages received from the UE.

If access performance measurements per QoS Flow is performed, when the UPF sends PMF message over a QoS Flow of an access, the UPF shall set the source UDP port with the UDP port for the QoS Flow and the access as the one for the QoS Flow and the access provided in Measurement Assistance information.

– If the UE receives Measurement Assistance Information, the UE shall inform the network via the user plane about the UE’s dynamically allocated UDP port, and the IPv6 address if IPv6 is used for PMF messages, so that it is possible for the UPF to know the UE’s IPv6 address (if applicable) and dynamically allocated UDP port as soon as the MA PDU Session has been established.

NOTE 1: Regardless of whether access performance measurements per QoS Flow is applied or not, the UE only allocates a single UDP port for PMF messages.

2. In the case of a MA PDU Session of Ethernet type:

– The PMF in the UE sends PMF messages to the PMF in the UPF over Ethernet. The Ethertype is the Ethertype contained in the Measurement Assistance Information. If access performance measurements are performed only over the QoS Flow associated with the default QoS rule, the destination MAC address is one of the two MAC addresses contained in the Measurement Assistance Information. One MAC address is used for sending PMF messages to UPF over 3GPP access and the other MAC address is used for sending PMF messages to UPF over non-3GPP access. The source MAC address is a MAC address of the UE, which remains the same for the entire lifetime of the MA PDU Session.

If access performance measurements per QoS Flow is performed, Measurement Assistance Information contains MAC addresses for each QoS Flow and each access. When the UE sends PMF message over a QoS Flow of an access, the UE shall set the destination MAC address as the MAC address for the QoS Flow and the access in Measurement Assistance information.

– The PMF in the UPF sends PMF messages to the PMF in the UE over Ethernet. The Ethertype is the same Ethertype as the one provided in the Measurement Assistance Information. If access performance measurements are performed only over the QoS Flow associated with the default QoS rule, the source MAC address is one of the two MAC addresses as provided in the Measurement Assistance Information. One MAC address is used for sending PMF messages to UE over 3GPP access and the other MAC address is used for sending PMF messages to UE over non-3GPP access. The destination MAC address is the MAC address of the UE, which is contained in all PMF messages received from the UE.

If access performance measurements per QoS Flow is performed, when the UPF sends PMF message over a QoS Flow of an access, the UPF shall set the source MAC address with the MAC address for the QoS Flow and the access as the one for the QoS Flow and the access provided in Measurement Assistance information.

– If the UE receives Measurement Assistance Information, the UE shall inform the network via the user plane about the UE’s MAC address so that it is possible for the UPF to know the UE’s MAC address as soon as the MA PDU Session has been established.

NOTE 2: Regardless of whether access performance measurements per QoS Flow is applied or not, the UE only use a single MAC address.

5.32.5.2 Round Trip Time Measurements

RTT measurements can be conducted by the UE and UPF independently. There is no measurement reporting from one side to the other. RTT measurements are defined to support the "Smallest Delay", "Priority-based" or "Load Balancing" steering mode (i.e. when RTT threshold value is applied).

The estimation of the RTT by the UE and by the UPF is based on the following mechanism:

1. The PMF in the UE sends over the user plane PMF-Echo Request messages to the PMF in the UPF, and the PMF in the UPF responds to each one with a PMF-Echo Response message. Similarly, the PMF in the UPF sends over the user plane PMF-Echo Request messages to the PMF in the UE, and the PMF in the UE responds to each one with a PMF-Echo Response message.

2. When the UP connection of the MA PDU session is deactivated on an access, no PMF-Echo Request messages are sent on this access. The PMF in the UPF shall not send PMF-Echo Request on this access if the UP connection is not available or after it receives notification from the (H-)SMF to stop sending the PMF-Echo Request on this access.

3. The UE and the UPF derive an estimation of the average RTT over an access type and QoS Flow by averaging the RTT measurements obtained over this access type and QoS Flow.

5.32.5.2a Packet Loss Rate Measurements

The UE and the UPF may decide to estimate the Packet Loss Rate (PLR) for an SDF over both accesses. For example, the UE may take this decision when an ATSSS rule in the UE requires the traffic of an SDF to be steered in accordance with a PLR-based threshold condition (e.g. PLR < 2%).

The UE and the UPF calculate the PLR for an SDF by exchanging PMF-PLR Report messages, as specified below. A PMF-PLR Report message is sent over 3GPP access or over non-3GPP access, using either the QoS Flow associated with the default QoS rule or a "target" QoS Flow, as specified in clause 5.32.5.1.

The calculation of the PLR by the UE and by the UPF is based on the following mechanism. It is assumed that the PLR should be calculated for a target QoS Flow, however, the same mechanism applies when the PLR should be calculated for the QoS Flow associated with the default QoS rule.

– The UE requests from UPF to start counting the number of received UL packets by sending a PMF-PLR Count Request message over the target QoS Flow. The UPF starts counting of the received UL packets over the target QoS Flow and over the access network which the PMF-PLR Count Request message was received from. The UE starts counting the transmitted UL packets over the target QoS Flow and access network when it sends a PMF-PLR Count Request message to UPF.

– The UE stops the counting and requests from UPF to report the number of counted UL packets by sending a PMF-PLR Report Request message over the target QoS Flow. The UPF stops the counting and sends a PMF-PLR Report Response message over the QoS Flow including the number of UL packets counted since it received the last PMF-PLR Count Request message.

NOTE 1: A PMF-PLR Report Request message can also indicate to UPF to start counting packets if the UE wants to measure the Packet Loss Rate again.

– The UE calculates the UL packet loss ratio based on the local counting result of the number of transmitted UL packets and reported number of received UL packets in the UPF.

– The UPF applies the same procedure for calculating the DL PLR, i.e. it sends to UE a PMF-PLR Count Request message on a target QoS Flow to request from UE to start counting the number of DL packets received on this target QoS Flow. As defined in clause 5.32.5.1, the UE determines which DL packets are received on the target QoS Flow by checking the QFI included in the header of DL packets (e.g. in the SDAP header). If no QFI is included in the header of a DL packet, the UE determines the QFI for this DL packet by applying the Packet Filters for downlink in the QoS Rules received from SMF.

– When the UP connection of the MA PDU session is deactivated on an access, no PMF-PLR messages are sent on this access. The PMF in the UPF shall not send PMF-PLR message on this access if the UP connection is not available or after it receives notification from the (H-)SMF to stop sending the PMF-PLR message on this access.

– The UE and the UPF derive an estimation of the average PLR per QoS Flow over an access type by averaging the PLR measurements obtained over this access.

NOTE 2: The details of the packet loss measurements, including error cases and mechanisms for improving the measurement accuracy, are considered in the Stage 3 specifications.

5.32.5.3 Access Availability/Unavailability Report

If required by the network in the Measurement Assistance Information, the UE shall provide access availability/unavailability reports to the network. How the UE detects the unavailability and the availability of an access is based on implementation. When the UE detects the unavailability/availability of an access, it shall:

– build a PMF-Access Report containing the access type and an indication of availability/unavailability of this access;

– send the PMF-Access Report to the UPF via the user plane.

The UPF shall acknowledge the PMF-Access Report received from the UE.

5.32.5.4 Protocol stack for user plane measurements and measurement reports

Figure 5.32.5.4-1: UE/UPF measurements related protocol stack for 3GPP access and for an MA PDU Session with type IP

In the case of an MA PDU Session with type Ethernet, the protocol stack over 3GPP access is that same as the one in the above figure, but the PMF protocol operates on top of Ethernet, instead of UDP/IP.

Figure 5.32.5.4-2: UE/UPF measurements related protocol stack for Untrusted non-3GPP access and for an MA PDU Session with type IP

In the case of an MA PDU Session with type Ethernet, the protocol stack over Untrusted non-3GPP access is the same as the one in the above figure, but the PMF protocol operates on top of Ethernet, instead of UDP/IP.

Figure 5.32.5.4-3: UE/UPF measurements related protocol stack for Trusted non-3GPP access and for an MA PDU Session with type IP

In the case of an MA PDU Session with type Ethernet, the protocol stack over Trusted non-3GPP access is the same as the one in the above figure, but the PMF protocol operates on top of Ethernet, instead of UDP/IP.

5.32.5.5 UE Assistance Operation

When UE-assistance operation is authorized by the PCF in the PCC Rule, the SMF provides an indication for UE-assistance in the ATSSS Rule to the UE, as described in clause 5.32.8, and in the MAR to the UPF, as described in clause 5.8.2.11.8.

If the UE receives the UE-assistance indicator in an ATSSS rule (as specified in clause 5.32.8) and the UE decides to apply a different UL traffic distribution for an SDF than the default UL traffic distribution indicated in the Steering Mode component of the ATSSS rule (e.g. because the UE is running out of battery), then the following applies:

– The UE may apply any split percentages for the UL traffic distribution of an SDF, based on implementation specific criteria.

– The UE may send a PMF-UAD (UE Assistance Data) message to UPF that contains the split percentages that may be used by UPF for all DL traffic that the UE-assistance operation applies. The UPF acknowledges the reception of the PMF-UAD message by sending a PMF-UAD complete message to the UE.

NOTE: If the UE has multiple ATSSS rules that allow UE-assistance operation, and the UE decides to use different UL split percentages for their respective SDFs, then the split percentages included in the PMF-UAD message are selected by the UE based on implementation specific criteria.

– The UPF may apply the information in a received PMF-UAD message to align the DL traffic distribution for traffic that is allowed to use UE-assistance operation, i.e. traffic where the MAR contains a Steering Mode Indicator set to UE-assistance operation.

– If the UE decides to terminate the UE assistance operation, the UE may send a PMF-UAT (UE Assistance Termination) message to the UPF indicating that the UE assistance operation is terminated and the UE performs the UL traffic distribution according to the split percentages in the ATSSS rule received from the network. If the UPF receives the PMF-UAT message, the UPF acknowledges the reception by sending a PMF-UAT complete message and performs DL traffic distribution by applying the split percentages included in the MAR.

5.32.6 Support of Steering Functionalities

5.32.6.1 General

The functionality in an ATSSS-capable UE that can steer, switch and split the MA PDU Session traffic across 3GPP access and non-3GPP access, is called a "steering functionality". An ATSSS-capable UE may support one or more of the following types of steering functionalities:

– High-layer steering functionalities, which operate above the IP layer:

– In this release of the specification, only one high-layer steering functionality is specified, which applies the MPTCP protocol (IETF RFC 8684 [81]) and is called "MPTCP functionality" (see clause 5.32.6.2.1). This steering functionality can be applied to steer, switch and split the TCP traffic of applications allowed to use MPTCP. The MPTCP functionality in the UE may communicate with an associated MPTCP Proxy functionality in the UPF, by using the MPTCP protocol over the 3GPP and/or the non-3GPP user plane.

– Low-layer steering functionalities, which operate below the IP layer:

– One type of low-layer steering functionality defined in the present document is called "ATSSS Low-Layer functionality", or ATSSS-LL functionality (see clause 5.32.6.3.1). This steering functionality can be applied to steer, switch and split all types of traffic, including TCP traffic, UDP traffic, Ethernet traffic, etc. ATSSS-LL functionality is mandatory for MA PDU Session of type Ethernet. In the network, there shall be in the data path of the MA PDU session one UPF supporting ATSSS-LL.

NOTE: Filters used in ATSSS rules related with a MA PDU Session of type Ethernet can refer to IP level parameters such as IP addresses and TCP/UDP ports.

The UE indicates to the network its supported steering functionalities and steering modes by including in the UE ATSSS Capability one of the following:

1) ATSSS-LL functionality with any steering mode.

In this case, the UE indicates that it is capable to steer, switch and split all traffic of the MA PDU Session by using the ATSSS-LL functionality with any steering mode specified in clause 5.32.8.

2) MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode.

In this case, the UE indicates that:

a) it is capable to steer, switch and split the MPTCP traffic of the MA PDU Session by using the MPTCP functionality with any steering mode specified in clause 5.32.8; and

b) it is capable to steer and switch all other traffic (i.e. the non-MPTCP traffic) of the MA PDU Session by using the ATSSS-LL functionality with the Active-Standby steering mode specified in clause 5.32.8.

3) MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode.

In this case, the UE indicates that:

a) it is capable to steer, switch and split the MPTCP traffic of the MA PDU Session by using the MPTCP functionality with any steering mode specified in clause 5.32.8; and

b) it is capable to steer, switch and split all other traffic (i.e. the non-MPTCP traffic) of the MA PDU Session by using the ATSSS-LL functionality with any steering mode specified in clause 5.32.8.

The above steering functionalities are schematically illustrated in the Figure 5.32.6.1-1, which shows an example model for an ATSSS-capable UE supporting the MPTCP functionality and the ATSSS-LL functionality. The MPTCP flows in this figure represent the traffic of the applications for which MPTCP can be applied. The three different IP addresses illustrated in the UE are further described in clause 5.32.6.2.1. The "Low-Layer" in this figure contains functionality that operates below the IP layer (e.g. different network interfaces in the UE), while the "High-Layer" contains functionality that operates above the IP layer.

Figure 5.32.6.1-1: Steering functionalities in an example UE model

Within the same MA PDU Session in the UE, it is possible to steer the MPTCP flows by using the MPTCP functionality and, simultaneously, to steer all other flows by using the ATSSS-LL functionality. For the same packet flow, only one steering functionality shall be used.

All steering functionalities in the UE shall take ATSSS decisions (i.e. decide how to steer, switch and split the traffic) by using the same set of ATSSS rules. Similarly, all ATSSS decisions in the UPF shall be taken by applying the same set of N4 rules, which support ATSSS. The ATSSS rules and the N4 rules supporting ATSSS are provisioned in the UE and in the UPF respectively, when the MA PDU Session is established.

If the UE supports both the MPTCP functionality and the ATSSS-LL functionality, it shall use the provisioned ATSSS rules (see TS 23.503 [45]) to decide which steering functionality to apply for a specific packet flow.

5.32.6.2 High-Layer Steering Functionalities

5.32.6.2.1 MPTCP Functionality

As mentioned in clause 5.32.6.1, the MPTCP functionality in the UE applies the MPTCP protocol (IETF RFC 8684 [81]) and the provisioned ATSSS rules for performing access traffic steering, switching and splitting. The MPTCP functionality in the UE may communicate with the MPTCP Proxy functionality in the UPF using the user plane of the 3GPP access, or the non-3GPP access, or both.

The MPTCP functionality may be enabled in the UE when the UE provides an "MPTCP capability" during PDU Session Establishment procedure.

The network shall not enable the MPTCP functionality when the type of the MA PDU Session is Ethernet.

If the UE indicates it is capable of supporting the MPTCP functionality, as described in clause 5.32.2, and the network agrees to enable the MPTCP functionality for the MA PDU Session then:

i) An associated MPTCP Proxy functionality is enabled in the UPF for the MA PDU Session by MPTCP functionality indication received in the Multi-Access Rules (MAR).

ii) The network allocates to UE one IP address/prefix for the MA PDU Session and two additional IP addresses/prefixes, called "link-specific multipath" addresses/prefixes; one associated with 3GPP access and another associated with the non-3GPP access. In the UE, these two IP addresses/prefixes are used only by the MPTCP functionality. Each "link-specific multipath" address/prefix assigned to UE may not be routable via N6. The MPTCP functionality in the UE and the MPTCP Proxy functionality in the UPF shall use the "link-specific multipath" addresses/prefixes for subflows over non-3GPP access and over 3GPP access and MPTCP Proxy functionality shall use the IP address/prefix of the MA PDU session for the communication with the final destination. In Figure 5.32.6.1-1, the IP@3 corresponds to the IP address of the MA PDU Session and the IP@1 and IP@2 correspond to the "link-specific multipath" IP addresses. The following UE IP address management applies:

– The MA PDU IP address/prefix shall be provided to the UE via mechanisms defined in clause 5.8.2.2.

– The "link-specific multipath" IP addresses/prefixes shall be allocated by the UPF and shall be provided to the UE via SM NAS signalling.

NOTE 1: After the MA PDU Session is released, the same UE IP addresses/prefixes is not allocated to another UE for MA PDU Session in a short time.

NOTE 2: The act of the UPF performing translation on traffic associated with the "link-specific multipath" addresses to/from the MA PDU session IP address can lead to TCP port collision and exhaustion. The port collision can potentially occur because the UE also uses the MA PDU session IP address for non-MPTCP traffic, and this causes the port namespace of such address to be owned simultaneously by the UE and UPF. In addition, the port exhaustion can potentially occur when the UE creates a large number of flows, because multiple IP addresses used by the UE are mapped to a single MA PDU session IP address on the UPF. The UPF needs to consider these problems based on the UPF implementation, and avoid them by, for example, using additional N6-routable IP addresses for traffic associated to the link-specific multipath addresses/prefixes. How this is done is left to the implementation.

iii) The network shall send MPTCP proxy information to UE, i.e. the IP address, a port number and the type of the MPTCP proxy. The following type of MPTCP proxy shall be supported in this release:

– Type 1: Transport Converter, as defined in IETF RFC 8803 [82].

The MPTCP proxy information is retrieved by the SMF from the UPF during N4 session establishment.

The UE shall support the client extensions specified in IETF RFC 8803 [82].

iv) The network may indicate to UE the list of applications for which the MPTCP functionality should be applied. This is achieved by using the Steering Functionality component of an ATSSS rule (see clause 5.32.8).

NOTE 3: To protect the MPTCP proxy function (e.g. to block DDOS to the MPTCP proxy function), the IP addresses of the MPTCP Proxy Function are only accessible from the two "link-specific multipath" IP addresses of the UE via the N3/N9 interface.

v) When the UE indicates it is capable of supporting the MPTCP functionality with any steering mode and the ATSSS-LL functionality with only the Active-Standby steering mode (as specified in clause 5.32.6.1) and these functionalities are enabled for the MA PDU Session, then the UE shall route via the MA PDU Session the TCP traffic of applications for which the MPTCP functionality should be applied (i.e. the MPTCP traffic), as defined in bullet iv. The UE may route all other traffic (i.e. the non-MPTCP traffic) via the MA PDU Session, but this type of traffic shall be routed on one of 3GPP access or non-3GPP access, based on the received ATSSS rule for non-MPTCP traffic (see clause 5.32.2). The UPF shall route all other traffic (i.e. non-MPTCP traffic) based on the N4 rules provided by the SMF. This may include N4 rules for ATSSS-LL, using any steering mode as instructed by the N4 rules.

5.32.6.3 Low-Layer Steering Functionalities

5.32.6.3.1 ATSSS-LL Functionality

The ATSSS-LL functionality in the UE does not apply a specific protocol. It is a data switching function, which decides how to steer, switch and split the uplink traffic across 3GPP and non-3GPP accesses, based on the provisioned ATSSS rules and local conditions (e.g. signal loss conditions). The ATSSS-LL functionality in the UE may be applied to steer, switch and split all types of traffic, including TCP traffic, UDP traffic, Ethernet traffic, etc.

The ATSSS-LL functionality may be enabled in the UE when the UE provides an "ATSSS-LL capability" during the PDU Session Establishment procedure.

The ATSSS-LL functionality is mandatory in the UE for MA PDU Session of type Ethernet. When the UE does not support the MPTCP functionality, the ATSSS-LL functionality is mandatory in the UE for an MA PDU Session of type IP. When the UE supports the MPTCP functionality, the ATSSS-LL functionality with Active-Standby Steering Mode is mandatory in the UE for an MA PDU Session of type IP to support non-MPTCP traffic.

The network shall also support the ATSSS-LL functionality as defined for the UE. The ATSSS-LL functionality in the UPF is enabled for a MA PDU Session by ATSSS-LL functionality indication received in the Multi-Access Rules (MAR).

5.32.7 Interworking with EPS

5.32.7.1 General

Multi-access connectivity using ATSSS via EPC only is not supported.

Interworking for MA PDU Session, if allowed by the network, is based on the interworking functionality specified in clause 5.17.2, with the differences and clarifications described in the following clauses.

A PDN Connection in EPS may be modified into a MA PDU Session when transferred to 5GS if the UE and the SMF+PGW-C support the ATSSS feature.

5.32.7.2 Interworking with N26 Interface

Interworking with N26 interface is based on clause 5.17.2.2, with the following differences and clarifications:

– When the UE is registered to the same PLMN over 3GPP and non-3GPP accesses, and the UE request a new MA PDU Session via non-3GPP access, the AMF also includes the indication of interworking with N26 to SMF.

– The SMF does not request EBI allocation when MA PDU Session is established only over non-3GPP access. If MA PDU Session is released over 3GPP access, the allocated EBI(s) for the MA PDU Session is revoked by the SMF as described in clause 4.11.1.4.3 of TS 23.502 [3].

– The SMF does not request EBI allocation for GBR QoS Flow if the GBR QoS Flow is only allowed over non-3GPP access.

– If the UE and the network support MA PDU Sessions with 3GPP access connected to EPC, the MA PDU Session may be simultaneously associated with user-plane resources on 3GPP access network connected to EPC and with non-3GPP access network connected to 5GC. This case is further described in clause 5.32.1 and in clause 4.22.2.3 of TS 23.502 [3].

– If the UE or the network does not support MA PDU Session with 3GPP access connected to EPC, the MA PDU Session is handled as follows:

– When UE moves from 5GS to EPS, for both idle mode and connected mode mobility, if the MA PDU Session is moved to EPS as a PDN connection, the SMF triggers PDU Session Release procedure to release the MA PDU Session over Non-3GPP access in 5GS. UE and SMF remove ATSSS related contexts e.g. ATSSS rules, Measurement Assistance Information.

– When UE moves from 5GS to EPS, for both idle mode and connected mode mobility, if the MA PDU Session is not moved to EPS as a PDN connection, the 3GPP access of this MA PDU session becomes unavailable and the AMF notifies the SMF. In turn, the SMF may decide to move the traffic to Non-3GPP access of the MA PDU session, if it is available. When UE moves back from EPS to 5GS, after the UE is registered over the 3GPP, the UE may add user-plane resources over the 3GPP access to the MA PDU session by triggering PDU Session Establishment procedure as specified in clause 5.32.2.

– After UE moves from EPS to 5GS, for both idle mode and connected mode mobility, if the UE requires MA PDU session, or if no policy in the UE (e.g. no URSP rule) and no local restrictions mandate a single access for the PDU Session, UE triggers the PDU Session Modification procedure as described in clause 4.22.6.3 of TS 23.502 [3] to provide the ATSSS Capability to SMF+PGW-C. The SMF+PGW-C may determine whether to modify this PDU Session to a MA PDU Session in 5GS, e.g. based on SMF+PGW-C and UE’s ATSSS Capability, subscription data and local policy. If dynamic PCC is to be used for the MA PDU Session, the PCF decides whether the MA PDU session is allowed or not based on operator policy and subscription data. If the MA PDU Session is allowed, the SMF provides ATSSS rule(s) and Measurement Assistance Information to the UE. If the UE receives ATSSS rules and is not registered to non-3GPP access, the UE establishes the second user-plane over non-3GPP access after the UE is registered to non-3GPP access. If UE was registered to non-3GPP access in 5GS, the UP resources over non-3GPP access are also established by the SMF using the PDU Session Modification procedure.

5.32.7.3 Interworking without N26 Interface

Interworking without N26 interface is based on clause 5.17.2.3, with the following differences and clarifications:

– After UE moves from 5GS to EPS, UE may send a PDN Connectivity Request with "handover" indication to transfer the MA PDU Session to EPS. Then, if the UE or the network does not support MA PDU Session with 3GPP access connected to EPC, the SMF+PGW-C triggers to release MA PDU in 5GS. If UE does not transfer the MA PDU Session to EPS, UE keeps the MA PDU Session in 5GS. If the UE and the network support MA PDU Session with 3GPP access connected to EPC, the UE includes a "handover" indication and a "MA PDU Request" indication as well as the PDU Session ID in the PCO and the SMF+PGW-C keeps the user-plane resources over non-3GPP access in 5GC as described in clause 4.22.6.2.5 of TS 23.502 [3]. In this case, UE may report to UPF that 3GPP access is unavailable, all MA PDU Session traffic is transported over N3GPP access. Later, if UE returns to 5GS, UE may report the 3GPP access availability to UPF.

– After UE moves from EPS to 5GS, UE may trigger PDU Session Establishment procedure to transfer the PDN Connection to 5GS. During the PDU Session Establishment procedure, if the PDN Connection was not used as the 3GPP access leg of the MA PDU Session, the UE may request to establish a MA PDU Session by including "MA PDU Request" or, if no policy in the UE (e.g. no URSP rule) and no local restrictions mandate a single access for the PDU Session, the UE may include the "MA PDU Network-Upgrade Allowed" indication.

5.32.8 ATSSS Rules

As specified in clause 5.32.3, after the establishment of a MA PDU Session, the UE receives a prioritized list of ATSSS rules from the SMF. The structure of an ATSSS rule is specified in Table 5.32.8-1.

Table 5.32.8-1: Structure of ATSSS Rule

Information name	Description	Category	SMF permitted to modify in a PDU context	Scope
Rule identifier	Unique identifier to identify the ATSSS Rule	Mandatory	No	PDU context
Rule Precedence	Determines the order in which the ATSSS rule is evaluated in the UE.	Mandatory (NOTE 1)	Yes	PDU context
Traffic Descriptor	This part defines the Traffic descriptor components for the ATSSS rule.	Mandatory (NOTE 2)
Application descriptors	One or more application identities that identify the application(s) generating the traffic (NOTE 3).	Optional	Yes	PDU context
IP descriptors (NOTE 4)	One or more 5-tuples that identify the destination of IP traffic.	Optional	Yes	PDU context
Non-IP descriptors (NOTE 4)	One or more descriptors that identify the destination of non-IP traffic, i.e. of Ethernet traffic.	Optional	Yes	PDU context
Access Selection Descriptor	This part defines the Access Selection Descriptor components for the ATSSS rule.	Mandatory
Steering Mode	Identifies the steering mode that should be applied for the matching traffic and associated parameters.	Mandatory	Yes	PDU context
Steering Mode Indicator	Indicates either autonomous load-balance operation or UE-assistance operation if steering mode is set to "Load Balancing".	Optional (NOTE 6)	Yes	PDU context
Threshold Values	A Maximum RTT and/or a Maximum Packet Loss Rate.	Optional (NOTE 6)	Yes	PDU context
Steering Functionality	Identifies whether the MPTCP functionality or the ATSSS-LL functionality should be applied for the matching traffic.	Optional (NOTE 5)	Yes	PDU context
NOTE 1: Each ATSSS rule has a different precedence value from the other ATSSS rules. NOTE 2: At least one of the Traffic Descriptor components is present. NOTE 3: An application identity consists of an OSId and an OSAppId. NOTE 4: An ATSSS rule cannot contain both IP descriptors and Non-IP descriptors. NOTE 5: If the UE supports only one Steering Functionality, this component is omitted. NOTE 6: The Steering Mode Indicator and the Threshold Values shall not be provided together.

The UE evaluates the ATSSS rules in priority order.

Each ATSSS rule contains a Traffic Descriptor (containing one or more components described in Table 5.32.8-1) that determines when the rule is applicable. An ATSSS rule is determined to be applicable when every component in the Traffic Descriptor matches the considered service data flow (SDF).

Depending on the type of the MA PDU Session, the Traffic Descriptor may contain the following components (the details of the Traffic Descriptor generation are described in clause 5.32.3):

– For IPv4, or IPv6, or IPv4v6 type: Application descriptors and/or IP descriptors.

– For Ethernet type: Application descriptors and/or Non-IP descriptors.

One ATSSS rule with a "match all" Traffic Descriptor may be provided, which matches all SDFs. When provided, it shall have the least Rule Precedence value, so it shall be the last one evaluated by the UE.

NOTE 1: The format of the "match all" Traffic descriptor of an ATSSS rule is defined in stage-3.

Each ATSSS rule contains an Access Selection Descriptor that contains the following components:

– A Steering Mode, which determines how the traffic of the matching SDF should be distributed across 3GPP and non-3GPP accesses. The following Steering Modes are supported:

– Active-Standby: It is used to steer a SDF on one access (the Active access), when this access is available, and to switch the SDF to the available other access (the Standby access), when Active access becomes unavailable. When the Active access becomes available again, the SDF is switched back to this access. If the Standby access is not defined, then the SDF is only allowed on the Active access and cannot be transferred on another access.

– Smallest Delay: It is used to steer a SDF to the access that is determined to have the smallest Round-Trip Time (RTT). As defined in clause 5.32.5, measurements may be obtained by the UE and UPF to determine the RTT over 3GPP access and over non-3GPP access. In addition, if one access becomes unavailable, all SDF traffic is switched to the other available access. It can only be used for the Non-GBR SDF.

– Load-Balancing: It is used to split a SDF across both accesses if both accesses are available. It contains the percentage of the SDF traffic that should be sent over 3GPP access and over non-3GPP access. Load-Balancing is only applicable to Non-GBR SDF. In addition, if one access becomes unavailable, all SDF traffic is switched to the other available access, as if the percentage of the SDF traffic transported via the available access was 100%.

– Priority-based: It is used to steer all the traffic of an SDF to the high priority access, until this access is determined to be congested. In this case, the traffic of the SDF is sent also to the low priority access, i.e. the SDF traffic is split over the two accesses. In addition, when the high priority access becomes unavailable, all SDF traffic is switched to the low priority access. How UE and UPF determine when a congestion occurs on an access is implementation dependent. It can only be used for the Non-GBR SDF.

– A Steering Mode Indicator, which indicates that the UE may change the default steering parameters provided in the Steering Mode component and may adjust the traffic steering based on its own decisions. Only one of the following Steering Mode Indicators may be provided:

– Autonomous load-balance indicator: This indicator may be provided only when the Steering Mode is Load-Balancing. When provided, the UE may ignore the percentages in the Steering Mode component (i.e. the default percentages provided by the network) and may autonomously determine its own percentages for traffic splitting, in a way that maximizes the aggregated bandwidth in the uplink direction. The UE is expected to determine its own percentages for traffic splitting by performing measurements across the two accesses. The UPF may apply a similar behaviour when the autonomous load-balance indicator is included in an N4 rule.

– UE-assistance indicator: This indicator may be provided only when the Steering Mode is Load-Balancing. When provided by the network, it indicates that (a) the UE may decide how to distribute the UL traffic of the matching SDF based on the UE’s internal state (e.g. when the UE is in the special internal state, e.g. lower battery level), and that (b) the UE may inform the UPF how it decided to distribute the UL traffic of the matching SDF. In the normal cases, although with this indicator provided, the UE shall distribute the UL traffic as indicated by the network.

NOTE 2: Typically, the UE-assistance indicator can be provided for SDFs for which the network has no strong steering requirements. For example, when the network has no strong steering requirements for the default traffic of an MA PDU Session, the network can indicate (i) that this traffic must be steered with Load-Balancing steering mode using 50% – 50% split percentages, and (ii) that the UE is allowed to use other split percentages, such as 0% – 100%, if this is needed by the UE to optimize its operation (e.g. to minimize its battery consumption).

– Threshold Values: One or more threshold values may be provided when the Steering Mode is Priority-based or when the Steering Mode is Load-Balancing with fixed split percentages (i.e. without the Autonomous load-balance indicator or UE assistance indicator). A threshold value may be either a value for RTT or a value for Packet Loss Rate. The threshold values are applicable to both accesses and are applied by the UE and UPF as follows:

– Load-Balancing Steering Mode with fixed split percentages (i.e. without the Autonomous load-balance indicator or UE assistance indicator): When at least one measured parameter (i.e. RTT or Packet Loss Rate) on one access exceeds the provided threshold value, the UE and UPF may stop sending traffic on this access, or may continue sending traffic on this access but should reduce the traffic on this access by an implementation specific amount and shall send the amount of reduced traffic on the other access. When all measured parameters (i.e. RTT and Packet Loss Rate) for both accesses do not exceed the provided threshold values, the UE and UPF shall apply the fixed split percentages.

– Priority-based Steering Mode: When one or more threshold values are provided for the Priority-based Steering Mode, these threshold values should be considered by UE and UPF to determine when an access becomes congested. For example, when a measured parameter (i.e. RTT or Packet Loss Rate) on one access exceeds the provided threshold value, the UE and UPF may consider this access as congested and send the traffic also to the low priority access.

– A Steering Functionality, which identifies whether the MPTCP functionality or the ATSSS-LL functionality should be used to steer the traffic of the matching SDF. This is used when the UE supports multiple functionalities for ATSSS, as specified in clause 5.32.6 ("Support of Steering Functions").

NOTE 3: There is no need to update the ATSSS rules when one access becomes unavailable or available.

As an example, the following ATSSS rules could be provided to UE:

a) "Traffic Descriptor: UDP, DestAddr 1.2.3.4", "Steering Mode: Active-Standby, Active=3GPP, Standby=non-3GPP":

– This rule means "steer UDP traffic with destination IP address 1.2.3.4 to the active access (3GPP), if available. If the active access is not available, use the standby access (non-3GPP)".

b) "Traffic Descriptor: TCP, DestPort 8080", "Steering Mode: Smallest Delay":

– This rule means "steer TCP traffic with destination port 8080 to the access with the smallest delay". The UE needs to measure the RTT over both accesses, in order to determine which access has the smallest delay.

c) "Traffic Descriptor: Application-1", "Steering Mode: Load-Balancing, 3GPP=20%, non-3GPP=80%", "Steering Functionality: MPTCP":

– This rule means "send 20% of the traffic of Application-1 to 3GPP access and 80% to non-3GPP access by using the MPTCP functionality".

d) "Traffic Descriptor: Application-1", "Steering Mode: Load-Balancing, 3GPP=20%, non-3GPP=80%, "Threshold Value for Packet Loss Rate: 1%", "Steering Functionality: MPTCP":

– This rule means "send 20% of the traffic of Application-1 to 3GPP access and 80% to non-3GPP access as long as the Packet Loss Rate does not exceed 1% on both accesses, by using the MPTCP functionality. If the measured Packet Loss Rate of an access exceeds 1%, then the traffic of Application-1 may be reduced on this access and sent via the other access".