Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.501  Word version:  18.5.0

Top   Top   Up   Prev   Next
1…   3…   4.2.3   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.2.15…   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.15.11…   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.32.6…   5.33…   5.34…   5.35…   5.38…   5.43…   6…   6.3…   6.3.8…   7…   7.2…   8…   8.2.4   8.2.5…   8.3…   A…   D…   E…   F   G…   G.3   G.4…   H…   J   K…   M…   N…   O…   P… 
5.32.6 Support of Steering Functionalities  5.32.6.1 General  5.32.6.2 High-Layer Steering Functionalities  5.32.6.2.2.1 Supported Transport Modes  5.32.6.3 Low-Layer Steering Functionalities  5.32.7 Interworking with EPS  5.32.7.1 General  5.32.7.2 Interworking with N26 Interface  5.32.7.3 Interworking without N26 Interface  5.32.8 ATSSS Rules 
...

 

5.32.6  Support of Steering Functionalities  p. 457

5.32.6.1  General  p. 457

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, two high-layer steering functionalities are specified:
      • The first applies the MPTCP protocol (RFC 8684) 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 flows identified in the ATSSS/N4 rules. 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.
      • The second applies the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) and its multipath extensions (draft-ietf-quic-multipath [174]), and it is called "MPQUIC functionality" (see clause 5.32.6.2.2). This steering functionality can be applied to steer, switch and split the UDP traffic flows identified in the ATSSS/N4 rules. The MPQUIC functionality in the UE may communicate with an associated MPQUIC Proxy functionality in the UPF, by using the QUIC protocol and its multipath extensions 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.
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 allowed for ATSSS-LL, as 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:
    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, as 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:
    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.
  4. MPQUIC functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode.
    In this case, the UE indicates that:
    1. it is capable to steer, switch and split the MPQUIC traffic of the MA PDU Session by using the MPQUIC 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-MPQUIC 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. MPQUIC functionality with any steering mode and ATSSS-LL functionality with any steering mode.
    In this case, the UE indicates that:
    1. it is capable to steer, switch and split the MPQUIC traffic of the MA PDU Session by using the MPQUIC 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-MPQUIC traffic) of the MA PDU Session by using the ATSSS-LL functionality with any steering mode that can be used with ATSSS-LL, as specified in clause 5.32.8.
  6. MPTCP functionality with any steering mode, MPQUIC functionality with any steering mode, and ATSSS-LL functionality with only Active-Standby steering mode.
    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;
    2. it is capable to steer, switch and split the MPQUIC traffic of the MA PDU Session by using the MPQUIC functionality with any steering mode specified in clause 5.32.8; and
    3. it is capable to steer and switch all other traffic (i.e. the non-MPTCP traffic and the non-MPQUIC traffic) of the MA PDU Session by using the ATSSS-LL functionality with the Active-Standby steering mode specified in clause 5.32.8.
  7. MPTCP functionality with any steering mode, MPQUIC functionality with any steering mode, and ATSSS-LL functionality with any steering mode.
    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;
    2. it is capable to steer, switch and split the MPQUIC traffic of the MA PDU Session by using the MPQUIC functionality with any steering mode specified in clause 5.32.8; and
    3. it is capable to steer, switch and split all other traffic (i.e. the non-MPTCP traffic and the non-MPQUIC traffic) of the MA PDU Session by using the ATSSS-LL functionality with any steering mode that can be used with ATSSS-LL, as 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, the MPQUIC functionality and the ATSSS-LL functionality. The MPTCP flows and the MPQUIC flows in this Figure represent the traffic of the applications for which MPTCP can be applied and for which MPQUIC can be applied respectively. The five different IP addresses illustrated in the UE are further described in clause 5.32.6.2.1 and in clause 5.32.6.2.2. When the MPTCP functionality and the MPQUIC functionality are both applied, the addresses (IP@1, IP@2) used for MPTCP may be the same as the addresses (IP@4, IP@5) used for MPQUIC. 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.
Reproduction of 3GPP TS 23.501, Fig. 5.32.6.1-1: Steering functionalities in an example UE model
Figure 5.32.6.1-1: Steering functionalities in an example UE model
Up
Within the same MA PDU Session in the UE, it is possible to steer the MPTCP flows by using the MPTCP functionality, to steer the MPQUIC flows by using the MPQUIC 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 multiple steering functionalities, e.g. both the MPTCP functionality and the ATSSS-LL functionality, both the MPQUIC functionality and the ATSSS-LL functionality, or the MPTCP functionality, the MPQUIC 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 Functionalities  p. 460

5.32.6.2.1  MPTCP Functionality  p. 460
As mentioned in clause 5.32.6.1, the MPTCP functionality in the UE applies the MPTCP protocol (RFC 8684) 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 "MPTCP 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 "MPTCP 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 "MPTCP 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 "MPTCP 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 "MPTCP link-specific multipath" IP addresses/prefixes shall be allocated by the UPF and shall be provided to the UE via SM NAS signalling.
  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 RFC 8803.
      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 RFC 8803.
  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).
  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.2.2  MPQUIC Functionality |R18|  p. 461
The MPQUIC functionality enables steering, switching, and splitting of UDP traffic between the UE and UPF, in accordance with the ATSSS policy created by the network. The operation of the MPQUIC functionality is based on RFC 9298 "proxying UDP in HTTP", which specifies how UDP traffic can be transferred between a client (UE) and a proxy (UPF) using the RFC 9114 HTTP/3 protocol. The HTTP/3 protocol operates on top of the QUIC protocol (RFC 9000, RFC 9001 , RFC 9002), which supports simultaneous communication over multiple paths, as defined in draft-ietf-quic-multipath [174].
The MPQUIC functionality in the UE communicates with the MPQUIC Proxy functionality in the UPF (see Figure 4.2.10-1) using the user plane of the 3GPP access, or the non-3GPP access, or both.
The MPQUIC functionality may be enabled for an MA PDU Session with type IPv4, IPv6 or IPv4v6, when both the UE and the network support this functionality. The MPQUIC functionality shall not be enabled when the type of the MA PDU Session is Ethernet.
The MPQUIC functionality is composed of three components:
  1. QoS flow selection & Steering mode selection: This component in the UE initiates the establishment of one or more multipath QUIC connections, after the establishment of the MA PDU Session and, for each uplink UDP flow, it selects a QoS flow (based on the QoS rules), a steering mode and a transport mode (based on the ATSSS rules). This component in the UPF selects, for each downlink UDP flow, a QoS flow (based on the N4 rules), a steering mode and a transport mode (based on the N4 rules). The supported transport modes are defined below.
    In the UE, this component is only used in the uplink direction, while, in the UPF, this component is only used in the downlink direction.
  2. HTTP/3 layer: Supports the HTTP/3 protocol defined in RFC 9114 and the extensions defined in:
    • RFC 9298 for supporting UDP proxying over HTTP;
    • RFC 9297 for supporting HTTP datagrams; and
    • RFC 9220 for supporting Extended CONNECT.
    The HTTP/3 layer selects a multipath QUIC connection to be used for each UDP flow and allocates a new QUIC stream on this connection that is associated with the UDP flow. It also configures this QUIC stream to apply a specific steering mode.
    In the UE, the HTTP/3 layer implements an HTTP/3 client, while, in the UPF, it implements an HTTP/3 proxy.
  3. QUIC layer: Supports the QUIC protocol as defined in the applicable IETF specifications (RFC 9000, RFC 9001, RFC 9002) and the extensions defined in:
When the MPQUIC functionality is applied, the protocol stack of the user plane is depicted in Figure below.
Reproduction of 3GPP TS 23.501, Fig. 5.32.6.2.2-1: UP protocol stack when the MPQUIC functionality is applied
Figure 5.32.6.2.2-1: UP protocol stack when the MPQUIC functionality is applied
Up
If the UE indicates that it is capable of supporting the MPQUIC functionality, as described in clause 5.32.2, and the network agrees to enable the MPQUIC functionality for the MA PDU Session then:
  1. An associated MPQUIC Proxy functionality is enabled in the UPF for the MA PDU Session.
  2. The network allocates to UE one IP address/prefix for the MA PDU Session and two additional IP addresses/prefixes, called "MPQUIC 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 MPQUIC functionality. Each "MPQUIC link-specific multipath" address/prefix assigned to UE may not be routable via N6. The MPQUIC functionality in the UE and the MPQUIC Proxy functionality in the UPF shall use the "MPQUIC link-specific multipath" addresses/prefixes for transmitting UDP flows over non-3GPP access and over 3GPP access. The MPQUIC 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@4 and IP@5 correspond to the "MPQUIC link-specific multipath" 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 "MPQUIC link-specific multipath" IP addresses/prefixes shall be allocated by the UPF and shall be provided to the UE via SM NAS signalling.
  3. The network shall send MPQUIC proxy information to UE, i.e. one IP address of UPF, one UDP port number and the proxy type (e.g. "connect-udp"). This information is used by the UE for establishing multipath QUIC connections with the UPF, which implements the MPQUIC Proxy functionality.
  4. After the MA PDU Session is established, the UE determines the number of multipath QUIC connections to be established with the UPF. The UE determines to establish at least as many multipath QUIC connections as the number of QoS flows of the MA PDU Session, i.e. one multipath QUIC connection per QoS flow. Each multipath QUIC connection carries the UDP traffic mapped to a single QoS flow.
    For the downlink traffic to which the MPQUIC functionality is to be applied, the QoS rules provided to UE include downlink QoS information and the UE applies the downlink QoS information to establish multipath QUIC connections for the QoS flows used for the downlink traffic only.
  5. During a QUIC connection establishment, the UE and UPF negotiate QUIC transport parameters and indicate (a) support of QUIC Datagram frames and (b) support of multipath. They indicate support of QUIC Datagram frames by providing the "max_datagram_frame_size" transport parameter with a non-zero value (see RFC 9221) and they indicate support of multipath by providing the "enable_multipath" transport parameter (see draft-ietf-quic-multipath [174]).
    In addition, during a QUIC connection establishment the QoS flow associated with this connection is determined. The UE sends all traffic of a QUIC connection over the QoS flow associated with this QUIC connection. This enables the UPF to determine the QoS flow associated with a QUIC connection and to select a QUIC connection for sending the downlink traffic of a QoS flow.
  6. After a QUIC connection establishment, the HTTP/3 client in the UE and the HTTP/3 proxy in the UPF negotiate HTTP settings and indicate support of HTTP Datagrams (see RFC 9297) and support of Extended CONNECT (see RFC 9220). To use MPQUIC proxying for a UDP traffic flow, the UE then sends a HTTP/3 CONNECT request (see RFC 9298) to the HTTP/3 proxy in the UPF.
  7. The network may indicate to UE the list of applications for which the MPQUIC functionality should be applied. This is achieved by using the Steering Functionality component of an ATSSS rule (see clause 5.32.8).
Up
5.32.6.2.2.1  Supported Transport Modes  p. 461
The MPQUIC functionality supports the following transport modes for transmitting a UDP flow between UE and UPF. The PCF selects which of these transport modes shall be applied for a UDP flow (SDF). The selected transport mode is provided to UE and UPF within the ATSSS rules and N4/MAR rules respectively.
  • Datagram mode 2: This transport mode is the mode defined in RFC 9298. It encapsulates UDP packets within QUIC Datagram frames and provides unreliable transport with no sequence numbering and no packet reordering / deduplication.
  • Datagram mode 1: This transport mode is an extension of the mode defined in RFC 9298. It encapsulates UDP packets within QUIC Datagram frames and provides unreliable transport but with sequence numbering and with packet reordering / deduplication. It can be applied for any UDP flow. The details of the datagram mode 1, including the potential use of a Context ID (see RFC 9298), are considered in stage-3 specifications.
  • Stream mode: This transport mode is readily supported by the QUIC protocol. It encapsulates UDP packets within QUIC Stream frames and provides reliable transport with sequence numbering and with packet reordering / deduplication. It can be applied for UDP flows where it is known that the application does not perform retransmissions.
Up

5.32.6.3  Low-Layer Steering Functionalities  p. 464

5.32.6.3.1  ATSSS-LL Functionality  p. 464
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 does not support the Redundant Steering Mode.
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. In addition:
  • When the UE neither supports the MPTCP functionality nor the MPQUIC 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 and does not support the MPQUIC 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.
  • When the UE supports the MPQUIC functionality and does not support 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-MPQUIC traffic.
  • When the UE supports both the MPTCP functionality and the MPQUIC 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 and non-MPQUIC 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  p. 465

5.32.7.1  General  p. 465

Multi-access connectivity using ATSSS established 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.
Up

5.32.7.2  Interworking with N26 Interface  p. 465

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.
  • 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.
  • 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 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.
  • If the MA PDU Session is established using one 3GPP access path via 5GC and one non-3GPP access path via ePDG/EPC and the UE moves from NG-RAN/5GC to E-UTRAN/EPC, the SMF+PGW-C may keep the MA PDU Session if MA PDU Sessions with 3GPP access and non-3GPP access user plane resources both connected to EPC is allowed based on operator policy.
  • If the MA PDU Session is established using one 3GPP access path via 5GC and one non-3GPP access path via ePDG/EPC and the UE moves from NG-RAN/5GC to E-UTRAN/EPC, the SMF+PGW-C may release the user plane resources either over 3GPP access or non-3GPP access if MA PDU Sessions with 3GPP access and non-3GPP access user plane resources both connected to EPC is not allowed based on operator policy. In this case, while the UE is connected to EPC via both 3GPP access and non-3GPP access, the UE shall not trigger PDN Connection establishment to add an additional EPC access leg to the MA PDU Session.
Up

5.32.7.3  Interworking without N26 Interface  p. 466

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 and 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. 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.
  • 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.
Up

5.32.8  ATSSS Rules  p. 466

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 identifierUnique identifier to identify the ATSSS RuleMandatoryNoPDU context
Rule PrecedenceDetermines the order in which the ATSSS rule is evaluated in the UE.Mandatory (1)YesPDU context
Traffic DescriptorThis part defines the Traffic descriptor components for the ATSSS rule.Mandatory (2)
Application descriptorsOne or more application identities that identify the application(s) generating the traffic (3).OptionalYesPDU context
IP descriptors (4)One or more 5-tuples that identify the destination of IP traffic.OptionalYesPDU context
Non-IP descriptors (4)One or more descriptors that identify the destination of non-IP traffic, i.e. of Ethernet traffic.OptionalYesPDU context
Access Selection DescriptorThis part defines the Access Selection Descriptor components for the ATSSS rule.Mandatory
Steering ModeIdentifies the steering mode that should be applied for the matching traffic and associated parameters.Mandatory (8)YesPDU context
Steering Mode Indicator Indicates either autonomous load-balance operation or UE-assistance operation if steering mode is set to "Load Balancing". Optional (6)YesPDU context
Threshold Values (9)A Maximum RTT and/or a Maximum Packet Loss Rate.Optional (6)YesPDU context
Steering FunctionalityIdentifies whether the MPTCP functionality, the MPQUIC functionality, or the ATSSS-LL functionality should be applied for the matching traffic.Optional (5) (8)YesPDU context
Transport ModeIdentifies the transport mode (see clause 5.32.6.2.2.1) that should be used for the matching traffic, when the Steering Functionality is the MPQUIC functionality.Optional (7)YesPDU 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.
NOTE 7:
The Transport Mode shall be included when the Steering Functionality is the MPQUIC functionality. In all other cases, the Transport Mode shall not be included.
NOTE 8:
The Steering functionality "ATSSS-LL functionality" shall not be provided together with Steering Mode "Redundant".
NOTE 9:
If the Steering Mode is "Redundant", either a Maximum RTT or a Maximum Packet Loss Rate may be provided, but not both.
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.
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.
    • Redundant (without Threshold Values): It is used to duplicate traffic of an SDF on both accesses if both accesses are available. A Primary Access (either 3GPP access or Non-3GPP access) may be provided to the UE in the ATSSS rules and to the UPF in the N4 rules. If a Primary Access is provided, UE and UPF shall send all data packets of the SDF on the Primary Access and may duplicate data packets of the SDF on the other access. How many and which data packets are duplicated by UE and UPF on the other access is based on implementation. If the Primary Access is not provided to UE and UPF, the UE and UPF shall send all data packets of the SDF on both accesses. It can be used for GBR and 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.
  • 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). One threshold value may be provided when the Steering Mode is Redundant. 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.
    • Redundant Steering Mode: When the measured Packet Loss Rate exceeds the provided threshold value on both accesses, the UE and UPF shall duplicate the traffic of the SDF on both accesses. When the measured RTT exceeds the provided threshold value on both accesses, the UE and UPF may duplicate the traffic of the SDF on both accesses based on implementation. When the measured parameter (i.e. either RTT or Packet Loss Rate) exceeds the provided threshold value on one access only, the UE and UPF shall send the traffic of the SDF only over the other access. When the measured parameter (i.e. either RTT or Packet Loss Rate) does not exceed the provided threshold value on any access, the UE and UPF shall send the traffic of the SDF only over the Primary Access. The Primary Access (either 3GPP access or Non-3GPP access) may be provided to the UE in the ATSSS rules and to the UPF in the N4 rules. If the Primary Access is not provided to the UE and UPF, UE and UPF shall select a Primary Access based on their own implementation (e.g. using the lowest RTT access or the lowest Packet Loss Rate access). If measurement results on an access are not available for a parameter, it is considered that the measured parameter for this access has not exceeded the provided threshold value. If a threshold value is provided when the Steering Mode is Redundant, the Steering Mode can only be used for Non-GBR SDF.
  • A Steering Functionality, which identifies whether the MPTCP functionality, or the MPQUIC 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").
  • A Transport Mode, which identifies the transport mode that should be applied by the MPQUIC functionality for the matching traffic. The transport modes supported by the MPQUIC functionality are defined in clause 5.32.6.2.2.1.
As an example, the following ATSSS rules could be provided to UE:
  1. "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)".
  2. "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.
  3. "Traffic Descriptor: TCP traffic of Application-1", "Steering Mode: Load-Balancing, 3GPP=20%, non-3GPP=80%", "Steering Functionality: MPTCP":
    • This rule means "send 20% of the TCP traffic of Application-1 to 3GPP access and 80% to non-3GPP access by using the MPTCP functionality".
  4. "Traffic Descriptor: TCP traffic of 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 TCP 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 TCP traffic of Application-1 may be reduced on this access and sent via the other access".
  5. "Traffic Descriptor: UDP traffic of Application-1", "Steering Mode: Load-Balancing, 3GPP=30%, non-3GPP=70%", "Steering Functionality: MPQUIC", "Transport Mode: Datagram mode 1":
    • This rule means "send 30% of the UDP traffic of Application-1 to 3GPP access and 70% to non-3GPP access by using the MPQUIC functionality with the Datagram mode 1".
  6. "Traffic Descriptor: com.example.app0, TCP", "Steering Mode: Redundant", "Steering Functionality: MPTCP":
    • This rule means "traffic duplication is applied by the MPTCP steering functionality to the TCP traffic of application com.example.app0 and 100% of the traffic is duplicated over both accesses".
  7. "Traffic Descriptor: com.example.app1, TCP", "Steering Mode: Redundant, Primary Access=3GPP, Threshold Value for Packet Loss Rate: 0.1%", "Steering Functionality: MPTCP":
    • This rule means "traffic duplication is applied to the TCP traffic of application com.example.app1. If the measured PLR exceeds 0.1% on both accesses, all matched traffic is duplicated on both accesses. If the measured PLR exceeds 0.1% on one access only (either 3GPP or non-3GPP access), all matched traffic is sent over the other access only. If the measured PLR does not exceed 0.1% on any access, all matched traffic is sent over 3GPP access only as this is the Primary Access".
  8. "Traffic Descriptor: com.example.app2, TCP", "Steering Mode: Redundant, Threshold Value for Packet Loss Rate: 0.1%", "Steering Functionality: MPTCP".
    • This rule means "traffic duplication is applied to the TCP traffic of application com.example.app2. If the measured PLR exceeds 0.1% on both accesses, all matched traffic is duplicated and transmitted on both accesses. If the measured PLR exceeds 0.1% on one access only (either 3GPP or non-3GPP access), all matched traffic is sent over the other access only. If the measured PLR does not exceed 0.1% on any access, the UE or UPF selects the access based on their own implementation, e.g. the access with lower Packet Loss Rate to transmit all matched traffic".
Up

Up   Top   ToC