Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.501  Word version:   16.4.0

Top   Up   Prev   Next
1…   3…   4…   4.2.4   4.2.5…   4.2.8…   4.2.8.2.2   4.2.8.2.3…   4.2.8.4…   4.2.9…   4.3…   4.3.3   4.3.4   4.3.5   4.4…   4.4.6…   4.4.8   5…   5.3…   5.3.3…   5.4…   5.5…   5.6…   5.6.7…   5.7…   5.7.2…   5.7.3…   5.7.4   5.7.5…   5.8…   5.8.2.11…   5.9…   5.10…   5.11…   5.15…   5.16…   5.17…   5.18…   5.19…   5.21…   5.22…   5.27…   5.28…   5.29…   5.30…   5.31…   5.32…   5.33…   5.34…   5.35…   6…   6.3…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   J…

 

5.32  Support for ATSSS [R16]Word-p. 300
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.
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.
The following clauses specify the functionality that enables ATSSS.
Up
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 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:
      1. 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 the DNN configuration allows both MPTCP and ATSSS-LL with any steering mode, 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.
      2. 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.
      3. 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.
      4. 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 ATSSS control information (see TS 23.503). 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 TS 23.502, clause 4.22.7.
A MA PDU Session may be established either:
  1. when it is explicitly requested by an ATSSS-capable UE; or
  2. 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 TS 23.502, clause 4.22.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 TS 23.502, clause 4.22.6.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
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).
Up
5.32.3  Policy for ATSSS ControlWord-p. 303
As specified in 23.503 [45], during the establishment of a MA PDU session and 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 ATSSS policy control information, 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 ATSSS policy control information and maps these rules into (a) ATSSS rules, which are sent to UE, and (b) N4 rules, which are sent to UPF. The ATSSS rules is 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 when they are updated by the SMF, e.g. after receiving updated/new PCC rules from the PCF. Similarly, the N4 are sent to UPF when the MA PDU Session is created or when they are updated by SMF.
The details of the policy related to ATSSS control are specified in TS 23.503.
Up
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.
Up
5.32.5  Access Network Performance MeasurementsWord-p. 304
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;
  • 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.
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.
The addressing information of the PMF in the UPF is retrieved by the SMF from the UPF during N4 session establishment.
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;
  • Messages for reporting Access availability/unavailability by the UE to the UPF.
The PMF protocol is specified in TS 24.193 [109].
The PMF protocol messages exchanged between the UE and UPF shall use the QoS Flow associated with default QoS rule over the available access(es).
The QoS Flow associated with 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 measurements using PMF as the UE and UPF can use measurements available at the MPTCP layer.
Up
5.32.5.2  Round Trip Time MeasurementsWord-p. 305
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" steering mode.
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. In the case of a MA PDU Session of IP type:
    • 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.
    • 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 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.
  3. 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 and 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.
    • 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 and 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 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.
  4. 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.
  5. The UE and the UPF derive an estimation of the average RTT over an access type by averaging the RTT measurements obtained over this access.
Up
5.32.5.3  Access Availability/Unavailability ReportWord-p. 306
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.
Up
5.32.5.4  Protocol stack for user plane measurements and measurement reports
Up
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.
Up
In the case of an MA PDU Session with type Ethernet, the protocol stack over non-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.
5.32.6  Support of Steering FunctionalitiesWord-p. 307
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 [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.
  2. 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.
  3. MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode.
  4. In this case, the UE indicates that:
    1. 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
    2. 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.
  5. MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode.
  6. In this case, the UE indicates that:
    1. 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
    2. 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.
Up
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) to decide which steering functionality to apply for a specific packet flow.
Up
5.32.6.2  High-Layer Steering FunctionalitiesWord-p. 309
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 [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:
  1. 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).
  2. 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.
  3. 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 draft-ietf-tcpm-converters-14 [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 draft-ietf-tcpm-converters-14 [82].
  4. 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.
  5. 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.
Up
5.32.6.3  Low-Layer Steering FunctionalitiesWord-p. 310
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).
Up
5.32.7  Interworking with EPS
5.32.7.1  General
Multi-access connectivity using ATSSS via EPC only is not supported. Multi-access connectivity using ATSSS via both EPC and 5GC may be supported as defined in TS 23.316 for the scenario with 5G-RG.
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 PGW-C+SMF support the ATSSS feature.
Up
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 TS 23.502, clause 4.11.1.4.3.
  • The SMF does not request EBI allocation for GBR QoS Flow if the GBR QoS Flow is only allowed over non-3GPP access.
  • 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 in TS 23.502 to provide the ATSSS Capability to PGW-C+SMF. The PGW-C+SMF may determine whether to modify this PDU Session to a MA PDU Session in 5GS, e.g. based on PGW-C+SMF 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.
Up
5.32.7.3  Interworking without N26 InterfaceWord-p. 311
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 sends a PDN Connectivity Request with "handover" indication to transfer the MA PDU Session to EPS. Then PGW-C+SMF 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. 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, 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.
Up
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.
Information name
Description
Category
SMF permitted to modify in a PDU context
Scope

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.
Mandatory
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.

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:
  • 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, if allowed by the PCC rules (as specified in clause 5.32.4).
    • 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 QoS flow. 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.
  • 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 2:
    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".
Up

Up   Top   ToC