Section: 5.32.2 Multi Access PDU Sessions
Content: 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. 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 and the ATSSS-LL functionality with only the Active-Standby steering mode (as specified in clause 5.32.6.1); or - 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 (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. If the UE supports the ATSSS-LL functionality with only the Active-Standby steering mode, the network shall provide to UE 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 MPQUIC 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); or - the MPQUIC 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 MPQUIC 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 "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 supports the ATSSS-LL functionality with only the Active-Standby steering mode, the network shall provide to UE an ATSSS rule for non-MPQUIC traffic. The ATSSS rule for non-MPQUIC traffic shall use the ATSSS-LL functionality and the Active-Standby Steering Mode to indicate how the non-MPQUIC 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 MPQUIC 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); or - the MPTCP functionality with any steering mode, and the MPQUIC 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 and MPQUIC 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), (b) two additional IP addresses/prefixes, called "MPTCP link-specific multipath" addresses, and (c) two additional IP addresses/prefixes, called "MPQUIC link-specific multipath" addresses. Further details are provided in clause 5.32.6.2.1 and 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 supports the ATSSS-LL functionality with only the Active-Standby steering mode, the network shall provide to UE an ATSSS rule for non-MPTCP and non-MPQUIC traffic (i.e. the traffic for which neither the MPTCP nor the MPQUIC functionalities are applied). The ATSSS rule for non-MPTCP and non-MPQUIC traffic shall use the ATSSS-LL functionality and the Active-Standby Steering Mode to indicate how the non-MPTCP and non-MPQUIC traffic shall be transferred across the 3GPP access and the non-3GPP access in the uplink direction. NOTE 2: 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 based on the ATSSS capabilities provided by the UE and per DNN configuration on SMF, as follows: a) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode" (as specified in clause 5.32.6.1), then: i) 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 3: 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. ii) 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 (i.e. any Steering Mode allowed for ATSSS-LL) 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. b) If the UE includes in its ATSSS capabilities "MPQUIC functionality with any steering mode and ATSSS-LL functionality with only Active-Standby steering mode" (as specified in clause 5.32.6.1), then: i) If the DNN configuration allows MPQUIC 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 and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink, and (2) MPQUIC 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 MPQUIC. ii) If the DNN configuration allows MPQUIC 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 in the downlink (2) ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink, and (3) MPQUIC and ATSSS-LL with Active-Standby mode in the uplink. iii) If the DNN configuration allows MPQUIC with any steering mode and ATSSS-LL with only Active-Standby steering mode, the MA PDU Session is capable of MPQUIC and ATSSS-LL with Active-Standby mode in the uplink and in the downlink. c) If the UE includes in its ATSSS capabilities "MPQUIC 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 MPQUIC and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), the MA PDU Session is capable of MPQUIC and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the uplink and in the downlink. d) If the UE includes in its ATSSS capabilities "ATSSS-LL functionality with any steering mode" (as specified in clause 5.32.6.1) and the DNN configuration allows ATSSS-LL with any steering mode 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. e) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode and ATSSS-LL functionality with any steering mode" (as specified in clause 5.32.6.1), and the DNN configuration allows MPTCP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), the MA PDU Session is capable of MPTCP and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the uplink and in the downlink. f) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode, and the MPQUIC functionality with any steering mode, and the ATSSS-LL functionality with any steering mode" (as specified in clause 5.32.6.1), and the DNN configuration allows MPTCP and MPQUIC and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL), the MA PDU Session is capable of MPTCP and MPQUIC and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the uplink and in the downlink. g) If the UE includes in its ATSSS capabilities "MPTCP functionality with any steering mode, and the MPQUIC 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), then: i) If the DNN configuration allows MPTCP and MPQUIC 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 MPQUIC and ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink, and (2) MPTCP and MPQUIC 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 MPTCP or MPQUIC. ii) If the DNN configuration allows MPTCP and MPQUIC 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 and MPQUIC in the downlink (2) ATSSS-LL with any steering mode (i.e. any Steering Mode allowed for ATSSS-LL) in the downlink, and (3) MPTCP and MPQUIC and ATSSS-LL with Active-Standby mode in the uplink. iii) If the DNN configuration allows MPTCP and MPQUIC with any steering mode and ATSSS-LL with only Active-Standby steering mode, the MA PDU Session is capable of MPTCP and MPQUIC and ATSSS-LL with Active-Standby mode in the uplink and in the downlink. The SMF provides the ATSSS capabilities of the MA PDU Session to the PCF during PDU Session Establishment. - The PCC rules provided by PCF include MA PDU Session Control information (see TS 23.503[ Policy and charging control framework for the 5G System (5GS); Stage 2 ]  [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 6: 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[ Procedures for the 5G System (5GS) ]  [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[ Procedures for the 5G System (5GS) ]  [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 7: 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: a) when it is explicitly requested by an ATSSS-capable UE; or b) when an ATSSS-capable UE requests a single-access PDU Session but the network decides to establish a MA PDU Session instead. This is an optional scenario specified in clause 4.22.3 of TS 23.502[ Procedures for the 5G System (5GS) ]  [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[ Procedures for the 5G System (5GS) ]  [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[ Procedures for the 5G System (5GS) ]  [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[ Procedures for the 5G System (5GS) ]  [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[ Procedures for the 5G System (5GS) ]  [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[ Procedures for the 5G System (5GS) ]  [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 more than one PDU session 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 8: 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[ Policy and charging control framework for the 5G System (5GS); Stage 2 ]  [45]).