3GPP 23.501 v20.2.0 — the document's own text

5.32.2 Multi Access PDU Sessions

Taught in 11. Using two accesses at once (The 5G system architecture, in depth).

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 allowed for ATSSS-LL supported" capability (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.

NOTE 1: As specified in Table 5.32.8-1 and in Table 5.8.5.8-1, the ATSSS-LL functionality cannot be used together with the Redundant steering mode. When the UE indicates it is capable of supporting the ATSSS-LL functionality with any steering mode, it is implied that the UE can support the ATSSS-LL functionality with any steering mode except the Redundant steering mode.

If the UE indicates it is capable of supporting:

the "MPTCP functionality with any steering mode supported" capability and the "ATSSS-LL functionality with only the Active-Standby steering mode supported" capability (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 (a) one IP address/prefix for the MA PDU session (as defined in clause 5.8.2.2) and (b) two additional IP addresses/prefixes, called "MPTCP link-specific multipath" addresses. Further details are provided in clause 5.32.6.2.1. In addition, the network may provide to UE Measurement Assistance Information and shall provide to UE one or more ATSSS rules. The network shall provide to UE ATSSS rule(s) for non-MPTCP traffic. The ATSSS rule(s) for non-MPTCP traffic shall use the ATSSS-LL, MPQUIC-UDP and/or MPQUIC-IP steering functionality(ies) depending on what is supported and selected for the MA PDU Session.

If the network accepts to activate only ATSSS-LL functionality with only the Active-Standby steering mode, the network shall provide to the UE an ATSSS rule that uses the ATSSS-LL functionality and the Active-Standby Steering Mode, to indicate how the 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 "MPQUIC-UDP functionality with any steering mode supported" capability and the "ATSSS-LL functionality with only the Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1);

and the network accepts to activate these functionalities, then the network provides MPQUIC proxy information (for connect-udp) to UE and allocates to UE (a) one IP address/prefix for the MA PDU session (as defined in clause 5.8.2.2) and (b) two additional IP addresses/prefixes, called "MPQUIC link-specific multipath" addresses. Further details are provided in clause 5.32.6.2.2. In addition, the network may provide to UE Measurement Assistance Information and shall provide to UE one or more ATSSS rules. The network shall provide to UE an ATSSS rule(s) for non-MPQUIC-UDP traffic. The ATSSS rule(s) for non-MPQUIC-UDP traffic shall use the ATSSS-LL, MPTCP and/or MPQUIC-IP steering functionality(ies) depending on what is supported and selected for the MA PDU Session.

If the UE indicates it is capable of supporting:

the "MPQUIC-IP functionality with any steering mode supported" capability and "ATSSS-LL functionality with only Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1);

and the network accepts to activate these functionalities, then the network provides MPQUIC proxy information (for connect-ip) to UE and allocates to UE (a) one IP address/prefix for the MA PDU session (as defined in clause 5.8.2.2) and (b) two additional IP addresses/prefixes, called "MPQUIC link-specific multipath" addresses. Further details are provided in clause 5.32.6.2.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 indicates it is capable of supporting:

the "MPQUIC-E functionality with any steering mode supported" capability and "ATSSS-LL functionality with only Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1);

and the network accepts to activate MPQUIC-E functionality, then the network provides MPQUIC proxy information (for connect-ethernet) to UE and allocates to UE two IP addresses/prefixes, called "MPQUIC link-specific multipath" addresses. Further details are provided in clause 5.32.6.2.2. In addition, the network shall provide to UE one or more ATSSS rules.

If the UE indicates it is capable of supporting:

the "MPQUIC-IP functionality with any steering mode supported" capability (as specified in clause 5.32.6.1);

NOTE 2: This capability does not require the UE to support the "ATSSS-LL functionality with only Active-Standby steering mode supported" capability.

and the network accepts to activate MPQUIC-IP functionality, then the network provides MPQUIC proxy information (for connect-ip) to UE and allocates to UE (a) one IP address/prefix for the MA PDU session (as defined in clause 5.8.2.2) and (b) two additional IP addresses/prefixes, called "MPQUIC link-specific multipath" addresses. In addition, the network shall provide to UE one or more ATSSS rules.

NOTE 3: The "MPTCP link-specific multipath" addresses and the "MPQUIC link-specific multipath" addresses can be the same.

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 taking into consideration one or more of the following aspects based on the ATSSS capabilities provided by the UE and per DNN configuration on SMF:

If the UE includes in its ATSSS capabilities the "MPTCP functionality with any steering mode supported" capability and the "ATSSS-LL functionality with only Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1), then:

If the DNN configuration allows MPTCP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), including RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPTCP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink and (2) MPTCP and ATSSS-LL with Active-Standby mode in the uplink.

NOTE 4: 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.

If the DNN configuration allows MPTCP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), but not RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPTCP in the downlink (2) ATSSS-LL with any steering mode except Smallest Delay steering mode (i.e. any Steering Mode allowed for ATSSS-LL except Smallest Delay steering mode) in the downlink and (3) MPTCP and ATSSS-LL with Active-Standby mode in the uplink.

iii) 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.

If the DNN configuration does not allow MPTCP functionality and the DNN configuration allows ATSSS-LL functionality with at least the Active-Standby steering mode, then the MA PDU Session is capable of ATSSS-LL with only Active-Standby steering mode in the uplink and in the downlink.

If the UE includes in its ATSSS capabilities the "MPQUIC-UDP functionality with any steering mode supported" capability and the "ATSSS-LL functionality with only Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1), then:

If the DNN configuration allows MPQUIC-UDP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), including RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPQUIC-UDP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink and (2) MPQUIC-UDP and ATSSS-LL with Active-Standby mode in the uplink.

NOTE 5: 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 MPQUIC.

If the DNN configuration allows MPQUIC-UDP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), but not RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPQUIC-UDP in the downlink (2) ATSSS-LL with any steering mode except Smallest Delay steering mode (i.e. any Steering Mode allowed for ATSSS-LL except Smallest Delay steering mode) in the downlink and (3) MPQUIC-UDP and ATSSS-LL with Active-Standby mode in the uplink.

iii) If the DNN configuration allows MPQUIC-UDP with any steering mode and ATSSS-LL with only Active-Standby steering mode, the MA PDU Session is capable of MPQUIC-UDP and ATSSS-LL with Active-Standby mode in the uplink and in the downlink.

If the DNN configuration does not allow MPQUIC-UDP functionality and the DNN configuration allows ATSSS-LL functionality with at least the Active-Standby steering mode, then the MA PDU Session is capable of ATSSS-LL with only Active-Standby steering mode in the uplink and in the downlink.

If the UE includes in its ATSSS capabilities the "ATSSS-LL functionality with any steering mode allowed for ATSSS-LL supported" capability (as specified in clause 5.32.6.1) and the DNN configuration allows ATSSS-LL with any steering mode allowed for ATSSS-LL, the MA PDU Session is capable of ATSSS-LL with any steering mode allowed for ATSSS-LL in the uplink and in the downlink.
If the UE includes in its ATSSS capabilities the "MPQUIC-IP functionality with any steering mode supported" capability and the "ATSSS-LL functionality with only Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1) then:

If the DNN configuration allows MPQUIC-IP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), including RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPQUIC-IP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink and (2) MPQUIC-IP and ATSSS-LL with Active-Standby mode in the uplink.

NOTE 6: 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 MPQUIC-IP.

If the DNN configuration allows MPQUIC-IP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), but not RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPQUIC-IP in the downlink (2) ATSSS-LL with any steering mode except Smallest Delay steering mode (i.e. any Steering Mode allowed for ATSSS-LL except Smallest Delay steering mode) in the downlink and (3) MPQUIC-IP and ATSSS-LL with Active-Standby mode in the uplink.

iii) If the DNN configuration allows MPQUIC-IP with any steering mode and ATSSS-LL with only Active-Standby steering mode, the MA PDU Session is capable of MPQUIC-IP and ATSSS-LL with Active-Standby mode in the uplink and in the downlink.

If the DNN configuration does not allow MPQUIC-IP functionality and the DNN configuration allows ATSSS-LL functionality with at least the Active-Standby steering mode, then the MA PDU Session is capable of ATSSS-LL with only Active-Standby steering mode in the uplink and in the downlink.

If the UE includes in its ATSSS capabilities the "MPQUIC-E functionality with any steering mode supported" capability and the "ATSSS-LL functionality with only Active-Standby steering mode supported" capability (as specified in clause 5.32.6.1) then:

If the DNN configuration allows MPQUIC-E and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), including RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPQUIC-E and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink and (2) MPQUIC-E and ATSSS-LL with Active-Standby mode in the uplink.

NOTE 7: 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 MPQUIC-E.

If the DNN configuration allows MPQUIC-E and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), but not RTT measurement without using PMF protocol, the MA PDU Session is capable of (1) MPQUIC-E in the downlink (2) ATSSS-LL with any steering mode except Smallest Delay steering mode (i.e. any Steering Mode allowed for ATSSS-LL except Smallest Delay steering mode) in the downlink and (3) MPQUIC-E and ATSSS-LL with Active-Standby mode in the uplink.

iii) If the DNN configuration allows MPQUIC-E with any steering mode and ATSSS-LL with only Active-Standby steering mode, the MA PDU Session is capable of MPQUIC-E and ATSSS-LL with Active-Standby mode in the uplink and in the downlink.

If the DNN configuration does not allow MPQUIC-E functionality and the DNN configuration allows ATSSS-LL functionality with at least the Active-Standby steering mode, then the MA PDU Session is capable of ATSSS-LL with only Active-Standby steering mode in the uplink and in the downlink.

NOTE 8: Either ATSSS-LL or MPQUIC-E is enabled for the same MA PDU Session with PDU Session type Ethernet. If the MA PDU Session is capable of both MPQUIC-E and ATSSS-LL, the PCF (if dynamic PCC is deployed) or SMF (if dynamic PCC is not deployed) determines whether ATSSS-LL or MPQUIC-E is enabled, as described in TS 23.502 [3].

If the UE includes in its ATSSS capabilities the "MPQUIC-IP functionality with any steering mode supported" capability (as specified in clause 5.32.6.1) and the DNN configuration allows MPQUIC-IP functionality with any steering mode, the MA PDU Session is capable of MPQUIC-IP functionality with any steering mode in the uplink and in the downlink. If the DNN configuration does not allow MPQUIC-IP functionality, then the SMF rejects the MA PDU Session request.

NOTE 9: As described above, an example of how SMF determines the ATSSS capabilities of a MA PDU Session is as follows:

If the UE indicates that it supports the "MPTCP functionality with any steering mode supported" capability, the "ATSSS-LL functionality with only Active-Standby steering mode supported" capability, the "MPQUIC-UDP functionality with any steering mode supported" capability and the "MPQUIC-IP functionality with any steering mode supported" capability and the DNN configuration allows only MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode, then the MA PDU Session is capable of MPTCP and ATSSS-LL with Active-Standby mode in the uplink and in the downlink.

NOTE 10: MPQUIC-E functionality is enabled only when the type of the MA PDU Session is Ethernet. The MPTCP, MPQUIC-UDP and MPQUIC-IP functionalities are not enabled when the type of the MA PDU Session is Ethernet.

For ATSSS-LL with only Active-Standby steering mode, the UE and the UPF needs to support Access Availability/Unavailability Report as specified in clause 5.32.5.3.

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

The PCC rules provided by PCF include MA PDU Session Control information (see TS 23.503 [45]). They are used by SMF to derive ATSSS rules for the UE and N4 rules for the UPF. When dynamic PCC is not used for the MA PDU Session, the SMF shall provide ATSSS rules and N4 rules based on local configuration (e.g. based on DNN or S-NSSAI).
The UE receives ATSSS rules from SMF, which indicate how the uplink traffic should be routed across 3GPP access and non-3GPP access. Similarly, the UPF receives N4 rules from SMF, which indicate how the downlink traffic should be routed across 3GPP access and non-3GPP access.
When the SMF receives a PDU Session Establishment Request and a "MA PDU Request" indication and determines that UP security protection (see clause 5.10.3) is required for the PDU Session, the SMF shall only confirm the establishment of the MA PDU session if the 3GPP access network can enforce the required UP security protection. The SMF needs not confirm whether the non-3GPP access can enforce the required UP security protection.
The UE indicates during MA PDU Session Establishment to the AMF whether it supports non-3GPP access path switching, i.e. whether the UE can transfer the non-3GPP access path of the MA PDU Session from a source non-3GPP access (N3IWF/TNGF) to a target non-3GPP access (a different N3IWF/TNGF). If the UE has indicated support for non-3GPP access path switching and the AMF supports non-3GPP access path switching, the AMF selects an SMF that supports non-3GPP access path switching, if such an SMF is available. If the AMF supports to maintain two N2 connections for non-3GPP access during the Registration procedure and the selected SMF supports non-3GPP path switching, the AMF indicates whether the UE supports non-3GPP path switching to the SMF. The SMF indicates support for non-3GPP path switching to the UE in the PDU Session Establishment Accept message.

NOTE 11: If the AMF selects an SMF not supporting non-3GPP access path switching, the non-3GPP access path switching can still be performed with the AMF triggering release of the old user plane resources before new user plane resources are established.

After the MA PDU Session establishment:

At any given time, the MA PDU session may have user-plane resources on both 3GPP and non-3GPP accesses, or on one access only, or may have no user-plane resources on any access.
The AMF, SMF, PCF and UPF maintain their MA PDU Session contexts, even when the UE deregisters from one access (but remains registered on the other access).
When the UE deregisters from one access (but remains registered on the other access), the AMF informs the SMF to release the resource of this access type in the UPF for the MA PDU Session. Subsequently, the SMF notifies the UPF that the access type has become unavailable and the N3/N9 tunnel for the access type are released.
If the UE wants to add user-plane resources on one access of the MA PDU Session, e.g. based on access network performance measurement and/or ATSSS rules, then the UE shall send a PDU Session Establishment Request over this access containing PDU Session ID of the MA PDU Session. The UE also provides Request Type as "MA PDU Request" and the same PDU Session ID in the UL NAS Transport message. If there is no N3/N9 tunnel for this access, the N3/N9 tunnel for this access is established.
If the UE wants to re-activate user-plane resources on one access of the MA PDU Session, e.g. based on access network performance measurement and/or ATSSS rules, then the UE shall initiate the UE Triggered Service Request procedure over this access.
If the network wants to re-activate the user-plane resources over 3GPP access or non-3GPP access of the MA PDU Session, the network shall initiate the Network Triggered Service Request procedure, as specified in clause 4.22.7 of TS 23.502 [3].
If the UE wants to move the non-3GPP user-plane resources of the MA PDU Session from a source non-3GPP access (e.g. source N3IWF or TNGF) to a target non-3GPP access (e.g. target N3IWF or TNGF), the UE initiates a Mobility Registration Update via the target non-3GPP access as described in TS 23.502 [3], clause 4.22.9.5. This procedure may also be used to move the non-3GPP user-plane resources of single access PDU Session(s).

NOTE 12: The UE can request activation of single access PDU Session(s) over the target non-3GPP access while performing Mobility Registration Update procedure according to the existing procedure.

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

A MA PDU Session may be established either:

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

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

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

request establishment of a MA PDU Session (as described in clause 4.22.2 of TS 23.502 [3]); or
request addition of User Plane resources for an existing MA PDU Session (as described in clause 4.22.7 of TS 23.502 [3]); or
request establishment of a PDU Session with "MA PDU Network-Upgrade Allowed" indication (as described in clause 4.22.3 of TS 23.502 [3]); or
request PDU Session Modification with Request Type of "MA PDU request" or with "MA PDU Network-Upgrade Allowed" indication after moving from EPC to 5GC (as described in clause 4.22.6.3 of TS 23.502 [3]).

The AMF indicates as part of the Registration procedure whether it supports non-3GPP access path switching. When the AMF does not indicate support of non-3GPP access path switching, the UE shall not perform the Mobility Registration Update procedure for non-3GPP access path switching, i.e. to switch traffic from a source non-3GPP access to a target non-3GPP access. The SMF indicates as part of the PDU Session Establishment procedure whether it supports non-3GPP access path switching. If the UE has one or more PDU sessions and at least one serving SMF for the PDU Sessions supports non-3GPP access path switching, the UE may include ("Non-3GPP path switching while using old AN resources") indication when the UE performs the Mobility Registration Update procedure for non-3GPP access path switching. If the UE is registered to different PLMNs over 3GPP and non-3GPP accesses, the UE shall use the capability received over non-3GPP access to determine whether to perform the Mobility Registration Update procedure for non-3GPP path switching and whether to include ("Non-3GPP access path switching while using old AN resources") indication.

NOTE 13: If the AMF receives ("Non-3GPP path switching while using old AN resources") indication from Mobility Registration Update procedure and the serving SMF(s) for PDU Session(s) is not supporting non-3GPP access path switching, the non-3GPP access path switching can still be performed with the AMF triggering for each PDU Session the release of the old user plane resources before new user plane resources are established.

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