Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.502  Word version:  19.1.0

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.2.11…   4.2.11.5…   4.3…   4.3.2.2.2   4.3.2.2.3…   4.3.3…   4.3.3.3   4.3.4…   4.3.4.3   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1…   4.11.1.2.2   4.11.1.2.3   4.11.1.3…   4.11.1.3.3…   4.11.1.4…   4.11.1.5…   4.11.2…   4.11.3…   4.12…   4.12.6…   4.12a…   4.12b…   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.3.2.5…   4.15.4…   4.15.6…   4.15.6.7…   4.15.6.13…   4.15.6.14…   4.15.9…   4.15.9.4…   4.15.13…   4.15.13.4…   4.16…   4.16.4…   4.16.8…   4.16.11…   4.16.14…   4.16.15…   4.17…   4.17.9…   4.18…   4.19…   4.22…   4.23…   4.23.7…   4.23.7.3.3   4.23.7.3.4…   4.23.9…   4.23.9.4…   4.23.11…   4.24…   4.25…   4.25.6…   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   5.2.18…   A…   E…   F…   G   H…

 

4.22  ATSSS Procedures |R16|p. 579

4.22.1  Generalp. 579

This clause specifies the procedures that enable the support of Access Traffic Steering, Switching and Splitting (ATSSS), as defined in clause 5.32 of TS 23.501. These procedures can be applied only by ATSSS-capable UEs and 5GC networks.
The key enabler of ATSSS is the Multi Access-PDU (MA PDU) Session. As specified in clause 5.32.1 of TS 23.501, a MA PDU Session is a PDU Session associated with two independent N3/N9 tunnels between the PSA and RAN/AN and with multiple access types, i.e. with one 3GPP access and one non-3GPP access both connected to 5GC. A MA PDU Session may also be a PDU Session associated with one 3GPP access connected to EPC and one non-3GPP access connected to 5GC, or a PDU Session associated with one non-3GPP access connected to EPC and one 3GPP access connected to 5GC. The traffic of a MA PDU Session can be transferred over 3GPP access, or over non-3GPP access, or over both accesses. How the traffic is transferred over the available accesses of a MA PDU Session is governed by the applicable policy created by the 5GC network.
The UE determines whether ATSSS is supported by the network based on the MA-PDU Session Support indicator provided by the AMF during the Registration procedures, as specified in clause 4.22.9.1. If the network does not support ATSSS, the UE shall not initiate the following procedures in this network:
  • establishment of a MA-PDU Session (clause 4.22.2);
  • establishment of a PDU Session with "MA-PDU Network-Upgrade Allowed" indication (clause 4.22.3);
  • addition of user-plane resources over one access for an existing MA-PDU Session, which has been established over the other access in a different network (clause 4.22.7); or
  • PDU Session Modification with Request Type of "MA-PDU request" or with "MA-PDU Network-Upgrade Allowed" indication after moving from EPC to 5GC (clause 4.22.6.3).
Up

4.22.2  UE Requested MA PDU Session Establishmentp. 580

4.22.2.0  Overview |R17|p. 580

Clauses 4.22.2.1 and 4.22.2.2 specify the MA PDU Session establishment procedures with both 3GPP access and non-3GPP access connected to 5GC. Clause 4.22.2.3 specifies the MA PDU Session establishment procedure with 3GPP access connected to EPC and non-3GPP access connected to 5GC. Clause 4.22.2.4 specifies the MA PDU Session establishment procedure with non-3GPP access connected to EPC and 3GPP access connected to 5GC.
Up

4.22.2.1  Non-roaming and Roaming with Local Breakoutp. 580

The signalling flow for a MA-PDU Session establishment when the UE is not roaming, or when the UE is roaming and the PDU Session Anchor (PSA) is located in the VPLMN, is based on the signalling flow in Figure 4.3.2.2.1-1 with the following differences and clarifications:
  • The PDU Session Establishment Request message may be sent over the 3GPP access or over the non-3GPP access. In the steps below, it is assumed that it is sent over the 3GPP access, unless otherwise specified.
  • In step 1, the UE provides Request Type as "MA-PDU Request" in UL NAS Transport message and its ATSSS Capabilities as defined in clause 5.32.2 of TS 23.501 in PDU Session Establishment Request message.
    The "MA PDU Request" Request Type in the UL NAS Transport message indicates to the network that this PDU Session Establishment Request is to establish a new MA PDU Session and to apply one or more steering functionalities (defined in clause 5.32.6 of TS 23.501) for steering the traffic of this MA PDU session over multiple accesses.
    If the UE requests an S-NSSAI and the UE is registered over both accesses, it shall request an S-NSSAI that is allowed on both accesses.
    The UE indicates to 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).
  • In step 2, if the AMF supports MA PDU sessions, then the AMF selects an SMF, which supports MA PDU sessions. If the AMF supports non-3GPP access path switching and the UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF selects a SMF that supports non-3GPP access path switching, if such an SMF is available.
  • In step 3, the AMF informs the SMF that the request is for a MA PDU Session by including "MA PDU Request" indication and in addition, it indicates to SMF whether the UE is registered over both accesses. If the AMF determines that the UE is registered via both accesses, but the requested S-NSSAI is not allowed on both accesses, then the AMF shall reject the MA PDU session establishment. If the AMF supports non-3GPP access path switching while maintaining two N2 connections for non-3GPP access, the selected SMF supports non-3GPP path switching and UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF indicates whether the UE supports non-3GPP path switching to the SMF.
    The AMF shall reject the PDU Session Establishment request if the request is for a LADN.
  • In step 4, the SMF retrieves, via Session Management subscription data, the information whether the MA-PDU session is allowed or not.
  • In step 7, if dynamic PCC is to be used for the MA-PDU Session, the SMF sends an "MA-PDU Request" indication to the PCF in the SM Policy Control Create message and the ATSSS Capabilities of the MA-PDU session. The SMF provides the currently used Access Type(s) and RAT Type(s) to the PCF. The PCF decides whether the MA-PDU session is allowed or not based on operator policy and subscription data.
    The PCF provides PCC rules that include MA-PDU session control information, as specified in TS 23.503. From the received PCC rules, the SMF derives (a) ATSSS rules, which will be sent to UE for controlling the traffic steering, switching and splitting in the uplink direction and (b) N4 rules, which will be sent to UPF for controlling the traffic steering, switching and splitting in the downlink direction. If the UE indicates the support of "ATSSS-LL Capability", the SMF may derive the Measurement Assistance Information.
    If the SMF receives a UP Security Policy for the PDU Session with Integrity Protection set to "Required" and the MA-PDU session is being established over non-3GPP access, the SMF does not verify whether the access can satisfy the UP Security Policy.
  • In the remaining steps of Figure 4.3.2.2.1-1, the SMF establishes the user-plane resources over the 3GPP access, i.e. over the access where the PDU Session Establishment Request was sent on:
    • In step 10, the N4 rules derived by SMF for the MA PDU session are sent to UPF and two N3 UL CN tunnels info are allocated by the UPF. If the ATSSS LL functionality is supported for MA PDU Session, the SMF may instruct the UPF to initiate performance measurement for this MA PDU Session. If the MPTCP functionality and/or the MPQUIC functionality is supported for the MA PDU Session, the SMF may instruct the UPF to activate the MPTCP functionality and/or the MPQUIC functionality for this MA PDU Session. In step 10a, the UPF allocates addressing information for the Performance Measurement Function (PMF) in the UPF. If the UPF receives from the SMF a list of QoS flows over which access performance measurements may be performed, the UPF allocates different UDP ports or different MAC addresses per QoS flow per access. In step 10b, the UPF sends the addressing information for the PMF in the UPF to the SMF. If UDP ports or MAC addresses are allocated per QoS flow and per access, the UPF sends the PMF IP address information and UDP ports with the related QFI to the SMF in the case of IP PDU sessions and sends the MAC addresses with the related QFI to the SMF in the case of Ethernet PDU sessions.
      In step 10a, if the message from the SMF instructs the UPF to activate MPTCP functionality, the UPF allocates the UE "MPTCP link-specific multipath" addresses/prefixes. In step 10b, the UPF sends the "MPTCP link-specific multipath" addresses/prefixes and MPTCP proxy information to the SMF. If the message from the SMF instructs the UPF to activate MPQUIC functionality, the UPF allocates the UE "MPQUIC link-specific multipath" addresses/prefixes. In step 10b, the UPF sends the "MPQUIC link-specific multipath" addresses/prefixes and MPQUIC proxy information to the SMF. The "MPTCP link-specific multipath" addresses/prefixes and the "MPQUIC link-specific multipath" addresses/prefixes may be the same.
      In step 10a, if the message from the SMF instructs the UPF to activate MPTCP functionality, the UPF allocates the UE "link-specific multipath" addresses/prefixes. In step 10b, the UPF sends the "link-specific multipath" addresses/prefixes and MPTCP proxy information to the SMF.
    • In step 11, for the MA PDU session, the SMF includes an "MA PDU session Accepted" indication in the Namf_Communication_N1N2MessageTransfer message to the AMF and indicates to AMF that the N2 SM Information included in this message should be sent over 3GPP access. The AMF marks this PDU session as MA PDU session based on the received "MA PDU session Accepted" indication. If the AMF indicated in step 3 that non-3GPP path switching while maintaining two N2 connections for non-3GPP access is supported, the SMF indicates support of non-3GPP path switching in the PDU Session Establishment Accept message.
    • In step 13, the UE receives a PDU Session Establishment Accept message, which indicates to UE that the requested MA PDU session was successfully established. This message includes the ATSSS rules for the MA PDU session, which were derived by SMF. If the ATSSS -LL functionality is supported for the PDU Session, the SMF may include the addressing information of PMF in the UPF into the Measurement Assistance Information. If the MPTCP functionality is supported for the MA PDU Session, the SMF shall include the "MPTCP link-specific multipath" addresses/prefixes of the UE and the MPTCP proxy information. If the MPQUIC functionality is supported for the MA PDU Session, the SMF shall include the "MPQUIC link-specific multipath" addresses/prefixes of the UE and the MPQUIC proxy information.
  • After step 18 in Figure 4.3.2.2.1-1, if the SMF was informed in step 2 that the UE is registered over both accesses, then the SMF initiates the establishment of user-plane resources over non-3GPP access too. The SMF sends an Namf_Communication_N1N2MessageTransfer to the AMF including N2 SM Information and indicates to AMF that the N2 SM Information should be sent over non-3GPP access. Namf_Communication_N1N2MessageTransfer does not include an N1 SM Container for the UE because this was sent to UE in step 13. After this step, the two N3 tunnels between the PSA and RAN/AN are established.
The last step above is not executed when the UE is registered over one access only, in which case the MA-PDU Session is established with user-plane resources over one access only. How user-plane resources can be added over an access of the MA-PDU Session is specified in clause 4.22.7.
Up

4.22.2.2  Home-routed Roamingp. 582

4.22.2.2.1  Home-routed Roaming - UE registered to the same PLMNp. 582
When the UE is registered to the same VPLMN over 3GPP access and non-3GPP access, the MA-PDU Session is established as specified in Figure 4.3.2.2.2-1 ("UE-requested PDU Session Establishment for home-routed roaming scenarios") with the differences and clarifications:
  • The PDU Session Establishment Request message may be sent over the 3GPP access or over the non-3GPP access.
  • In step 1, the UE provides Request Type as "MA PDU Request" in UL NAS Transport message and its ATSSS Capabilities, as defined in clause 5.32.2 of TS 23.501 in PDU Session Establishment Request message. The UE indicates to AMF whether it supports non-3GPP access path switching.
  • In step 2, if the AMF supports MA PDU sessions, then the AMF selects a V-SMF and an H-SMF, which supports MA PDU sessions. The V-SMF serves the UE over both accesses. If the AMF supports non-3GPP access path switching and the UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF selects a V-SMF and H-SMF supporting non-3GPP access path switching, if such a V-SMF and H-SMF are available.
  • In step 3, the AMF informs the SMF that the request is for a MA PDU Session by including an "MA PDU Request" indication and in addition, the AMF indicates to V-SMF that the UE is registered over both accesses. If the AMF supports non-3GPP access path switching while maintaining two N2 connections for non-3GPP access, the selected SMFs supports non-3GPP path switching and UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF indicates whether the UE supports non-3GPP path switching to the V-SMF.
  • In step 5, two DL N9 tunnel CN info and two UL N3 tunnel CN info are allocated by the V-SMF or by the V-UPF.
  • In step 6, the V-SMF informs the H-SMF that the request is for a MA PDU Session by including an "MA PDU Request" indication and indicates to H-SMF that the UE is registered over both accesses. The V-SMF indicates to H-SMF the relationship between the DL N9 tunnel CN info and the access type. If the single CN Tunnel is established by the H-SMF, the DL N9 tunnel info binding to the access over which the NAS message is received is to be used.
  • In step 7, the H-SMF retrieves, via Session Management subscription data, the information whether the MA-PDU session is allowed or not.
  • In step 9, if dynamic PCC is to be used for the MA-PDU Session, the H-SMF sends an "MA-PDU Request" indication to H-PCF in the SM Policy Control Create message and the ATSSS Capabilities of the MA-PDU session. The H-SMF provides the currently used list of Access Type(s) and RAT Type(s) for the MA-PDU session to the H-PCF. The H-PCF decides whether the MA-PDU session is allowed or not based on operator policy and subscription data.
    The H-PCF provides the PCC rules containing MA-PDU session control information and the H-SMF derives the ATSSS rules for the UE and the N4 rules for the H-UPF.
  • In step 12, two UL N9 tunnel CN info are allocated by the H-SMF or by the H-UPF. After this step, the two N9 tunnels between the H-UPF and V-UPF are established.
  • In step 13, the H-SMF sends "MA PDU session Accepted" indication to V-SMF in the Nsmf_PDUSession_Create Response message. The H-SMF indicates to V-SMF the relationship between the UL N9 tunnel CN info and the access type.
  • In step 14, the V-SMF sends the "MA-PDU session Accepted" indication in the Namf_Communication_N1N2MessageTransfer message to the AMF and indicates the AMF to send the N2 SM Information included in this message over the access that the UE sent the PDU Session Establishment Request. The AMF marks this PDU session as MA-PDU session based on the received "MA-PDU session Accepted" indication.
    The V-SMF indicates support of non-3GPP path switching in the PDU Session Establishment Accept message.
    If the V-SMF received two UL N9 tunnel CN info from the H-SMF, the V-SMF also initiates the establishment of user-plane resources over the other access. The V-SMF sends an N1N2 Message Transfer to AMF including N2 SM Information and the other access type to indicate to AMF that the N2 SM Information should be sent over the other access. The N1N2 Message Transfer does not include an N1 SM Container for the UE which was sent to UE over the access that the UE sent the PDU Session Establishment Request.
  • In step 16, the UE receives a PDU Session Establishment Accept message, which indicates to UE that the requested MA-PDU session was successfully established. This message includes the ATSSS rules for the MA-PDU session, which were derived by H-SMF and may include Measurement Assistance Information.
  • After step 20, if the V-SMF was informed in step 3 that the UE is registered over both accesses, then the V-SMF initiates the establishment of user-plane resources over the other access too. The V-SMF sends an N1N2 Message Transfer to the AMF including N2 SM Information and indicates to the AMF over which access the N2 SM Information should be sent. The N1N2 Message Transfer does not include an N1 SM Container for the UE because this was sent to the UE in step 14. After this step, two N9 tunnels between the H-UPF and the V-UPF as well as two N3 tunnels between the V-UPF and RAN/AN are established, or, if the H-UPF is connected to two different V-UPFs, the H-UPF has one N9 tunnel with each V-UPF.
Up
4.22.2.2.2  Home-routed Roaming - UE registered to different PLMNsp. 583
When the UE is registered to different PLMNs over 3GPP access and non-3GPP access, the MA-PDU Session is established first over one access as specified in Figure 4.3.2.2.2-1 ("UE-requested PDU Session Establishment for home-routed roaming scenarios") and then over the other access with the following differences and clarifications:
  • In step 1, the UE provides Request Type as "MA PDU Request" in UL NAS Transport message and its ATSSS Capabilities, as defined in clause 5.32.2 of TS 23.501. The UE indicates to AMF whether it supports non-3GPP access path switching. The UE also includes the PDU Session ID of the already established MA PDU Session.
  • In step 2, if the AMF supports MA PDU sessions, then the AMF selects a V-SMF, which supports MA PDU sessions. If the AMF supports non-3GPP access path switching and the UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF may select a V-SMF and H-SMF supporting non-3GPP access path switching. If the UE provides Request Type "MA PDU Request" in step 1 and the UE context in SMF data from UDM includes SMF identity information for that PDU Session ID, the AMF selects the H-SMF indicated by UDM.
  • In step 3, the AMF informs the V-SMF that the request is for a MA PDU Session (i.e. it includes an "MA PDU Request" indication). If the AMF supports non-3GPP access path switching while maintaining two N2 connections for non-3GPP access, the selected SMFs supports non-3GPP path switching and UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF indicates whether the UE supports non-3GPP path switching to the V-SMF.
  • In step 6, the V-SMF informs the H-SMF that the request is for a MA PDU Session (i.e. it includes an "MA PDU Request" indication).
  • In step 7, the H-SMF retrieves, via Session Management subscription data, the information whether the MA-PDU session is allowed or not.
  • In step 9, if dynamic PCC is to be used for the MA-PDU Session, the H-SMF sends an "MA-PDU Request" indication to PCF in the SM Policy Control Create message and the ATSSS Capabilities of the MA-PDU session. The H-SMF provides the currently used Access Type(s) and RAT Type(s) for the MA-PDU session to the PCF. The PCF decides whether the MA-PDU session is allowed or not based on operator policy and subscription data.
  • In step 14, the V-SMF indicates support of non-3GPP path switching in the PDU Session Establishment Accept message.
  • In step 16, the UE receives a PDU Session Establishment Accept message, which indicates to UE that the requested MA-PDU session was successfully established. This message includes the ATSSS rules for the MA-PDU session, which were derived by H-SMF and may include Measurement Assistance Information.
  • After the MA-PDU Session is successfully established on the first access, the UE shall initiate again the MA-PDU Session establishment procedure in Figure 4.3.2.2.2-1 over the other access with the following differences and clarifications:
    • In step 1, the UE shall send another PDU Session Establishment Request over the other access containing the same PDU Session ID that was provided over the first access. The UE also provides Request Type as "MA PDU Request" in UL NAS Transport message. The UE indicates to the AMF whether it supports non-3GPP access path switching.
    • In step 2, if the AMF supports non-3GPP access path switching while maintaining two N2 connections for non-3GPP access, the may select a V-SMF that support non-3GPP access path switching.
    • In step 3, if the AMF supports non-3GPP path switching and the UE indicated in step 1 that the UE supports non-3GPP access path switching, the AMF indicates whether the UE supports non-3GPP path switching to the V-SMF.
    • In step 12, new UL N9 tunnel CN info is allocated by the H-SMF or by the H-UPF.
    • In step 14, the V-SMF indicates support of non-3GPP path switching in the PDU Session Establishment Accept message.
    • In step 16, the UE receives another PDU Session Establishment Accept message, which may contain updated ATSSS rules for the MA-PDU session.
    • After step 20, two N9 tunnels between the H-UPF and two different V-UPFs as well as two N3 tunnels between different V-UPF and RAN/AN are established, or two N3 tunnels, one is between V-UPF and RAN/AN over 3GPP access and the other is between H-UPF and RAN/AN over non 3GPP access, as well as one N9 tunnel between H-UPF and V-UPF are established.
Up

4.22.2.3  MA PDU Session establishment with 3GPP access connected to EPC and non-3GPP access connected to 5GC |R17|p. 584

4.22.2.3.1  Generalp. 584
This clause applies to the case where, for a PDU Session, multi-access connectivity via both EPC (over 3GPP access) and 5GC (over non-3GPP access) is supported and allowed in the UE and network. In this case, multi-access connectivity using ATSSS via both 3GPP access to EPC and non-3GPP access to 5GC may be provided as described in this clause.
For this scenario, the general principles for ATSSS as described in clause 5.32 of TS 23.501 apply, with the additions provided in this clause 4.22.2.3.
A Multi-Access PDU Session may be extended with user-plane resources via an associated PDN Connection on 3GPP access in EPC. This enables a scenario where a MA-PDU Session can simultaneously be associated with user-plane resources on 3GPP access network connected to EPC and non-3GPP access connected to 5GC. Such a PDN Connection in EPS would thus be associated with multi-access capability in the UE and PGW-C+SMF.
The UE may operate in either single-registration mode or dual-registration mode in 3GPP access. Irrespective of whether the UE operates in single-registration mode or dual-registration mode in 3GPP access, it is assumed that the UE supports simultaneous registrations for non-3GPP access in 5GC and 3GPP access in EPC.
The ATSSS rules are provided from the PGW-C+SMF to the UE via SM NAS signalling over 5GC, as described in clause 5.32.2 of TS 23.501. ATSSS rules are not provided via the EPC.
When a UE establishes a MA-PDU Session in 5GS, the UE indicates whether it supports 3GPP access leg over EPC. Based on the UE capability, the SMF determines whether the non-3GPP access should be released or not when the MA-PDU Session is moved to EPS as described in clause 4.22.6.2.
After the establishment of a MA-PDU Session and setting up user-plane resources in 3GPP access in EPC and non-3GPP access in 5GC, the UE distributes the uplink traffic across the two access networks as described in clause 5.32.1 of TS 23.501. Similarly, the PDU Session Anchor UPF performs distribution of downlink traffic across the two access networks as described in clause 5.32.1 of TS 23.501.
The PMF protocol may be used via any user plane connection, i.e. via 3GPP access in EPC or non-3GPP access in 5GC.
The PCF functionality to support ATSSS, as described in clause 5.32.1 of TS 23.501 and TS 23.503 applies also in the case of interworking with EPC.
When the 3GPP access leg of a MA-PDU Session using both 3GPP and non-3GPP access connected to 5GC is transferred to EPC, the PDU Session continues to work as a MA-PDU Session using E-UTRAN/EPC and non-3GPP access connected to 5GC, as described in clause 4.22.6.
Up
4.22.2.3.2  PDN Connections and Multi Access PDU Sessionsp. 585
When the UE wants to request a new PDN Connection in EPC and wants to use this PDN Connection as user-plane resource associated with a MA-PDU Session:
  • The UE requests establishment of a new PDN Connection when the UE is registered via 3GPP access in EPS using PDN Connection Establishment procedure. The UE provides via PCO to PGW-C+SMF the following information:
    • An indication that the PDN Connection is requested to be associated with a MA-PDU Session
    • The UE's ATSSS capabilities as described in clause 5.32.2 of TS 23.501 (i.e. whether the UE is capable of supporting the ATSSS-LL functionality, the MPTCP functionality, the MPQUIC functionality, or any combination of them).
  • The MME may select a PGW-C+SMF as described in TS 23.401 and clause 4.11.0a.4.
  • The PGW-C+SMF determines based its capabilities whether the request can be accepted. The PCF decides whether the multi-access connectivity is allowed or not based on operator policy and subscription data, as described in clause 4.22.2. The PGW-C+SMF provides the following information in the PCO to the UE:
    • An indication whether the request for using the PDN Connection for MA-PDU Session is accepted or not.
    • If the UE has indicated that it is capable of supporting the MPTCP functionality and/or the MPQUIC functionality and the PGW-C+SMF accepts to activate the MPTCP functionality and/or the MPQUIC functionality, then the network provides MPTCP proxy information and/or MPQUIC proxy information to the UE, as described in clause 5.32.2 of TS 23.501.
    • UE Measurement Assistance Information (as described in clause 5.32.2 of TS 23.501).
After the PDN Connection establishment:
  • If the UE registers to 5GC and wants to add non-3GPP user-plane resources, then the UE shall send a PDU Session Establishment Request over this access containing a "MA PDU Request" indication as described in clause 5.32.2 of TS 23.501.
  • If the UE registers via non-3GPP access in EPC, the UE shall not trigger PDN Connection establishment to add non-3GPP/EPC access to the MA PDU Session.
When the UE wants to request a new MA-PDU Session in 5GC/non-3GPP access, the description in clause 5.32.2 of TS 23.501, applies. After the MA-PDU Session establishment in 5GS/non-3GPP access, the description in clause 5.32.2 of TS 23.501, applies with the following additions:
  • If the UE is registered to EPC and wants to add user-plane resources on 3GPP access over EPC, then the UE shall send a PDN Connection Establishment Request over this access containing a "handover" indication and include a "MA-PDU Request" indication in the PCO as well as the PDU Session ID of the existing MA-PDU Session on non-3GPP access over 5GC.
  • When the UE deregisters from the EPC access (but remains registered on the 5GC access), the MME will notify the PGW-C+SMF that the PDN Connection is released, as described in TS 23.401. The SMF can then notify the UPF that the access type has become unavailable.
In order to support EPS interworking when Ethernet type PDN Connection is not supported in EPS, the UE may use non-IP type PDN Connection when the UE establishes a PDN Connection in EPS as an added 3GPP access leg of an Ethernet type MA-PDU Session. In this case, the UE and SMF shall locally associate the PDN Connection as an Ethernet type PDU Session as described in TS 23.501. When Ethernet type PDN Connection is not supported in EPS, the UE does not request to establish a PDN Connection with "MA-PDU Request" indication before the UE registers to 5GS and establishes MA-PDU Session over non-3GPP access.
A UE that has an established MA-PDU session over non-3GPP access in 5GC and 3GPP access in EPS, may be able to use EN-DC for the 3GPP access leg.
Depending on the RAT types supported by the UE, the PDN connection may also be handed over to 3GPP access in 5GC. For a UE supporting both E-UTRAN/EPC access and NG-RAN/5GC access, the user plane resources for 3GPP access may be moved between E-UTRAN/EPC access and NG-RAN/5GC access as described in clause 5.17.2 of TS 23.501. The PDU Session and User Plane resources active over non-3GPP/5GC access are not affected by such inter 3GPP access RAT change.
Up
4.22.2.3.3  QoS Supportp. 586
The general principles for QoS support with ATSSS as described in clause 5.32.4 of TS 23.501, apply, with the clarifications provided in this clause.
With an MA-PDU Session associated to a PDN Connection on EPS there may be separate user-plane tunnels between the AN and the PGW-U+UPF, one associated with 3GPP access in EPC and one associated with non-3GPP access in 5GS.
As described in clause 4.11.1.1, the PGW-C+SMF maps the 5G QoS information received from PCC to EPS QoS parameters. This mapping is e.g. based on operator configuration and may result in that multiple QoS flows are mapped to a single EPS bearer. The PGW-C+SMF applies the appropriate QoS signalling in each access, e.g. to manage dedicated bearers in the access associated with EPC and QoS flows in the access associated with 5GC. The PGW-C+SMF also provides N4 rules to UPF for performing QoS enforcement and for mapping downlink traffic to appropriate GTP-U tunnels.
As described in clause 5.32.4 of TS 23.501, for a GBR QoS flow, the QoS profile is provided to a single access network at a given time. GBR QoS flows (and associated MBR, GBR) are thus only enforced in either the access associated to EPC or the access associated to 5GC. In order to maintain consistency between QoS information received via AS and NAS layers in each system, the PGW-C+SMF only provides the GBR QoS information to the UE for the access where the GBR traffic is enforced.
The UE shall treat the uplink traffic sent via EPC according to the EPS QoS information received in EPC (e.g. UL TFTs) and the uplink traffic sent via 5GC according to the 5G QoS rules received in 5GS. The UE thus need to determine what access to use (3GPP and Non-3GPP) before applying the uplink QoS treatment.
The UPF shall treat the downlink traffic according to the N4 rules (QER, etc.) received from PGW-C+SMF.
Up

4.22.2.4  MA PDU Session establishment with non-3GPP access connected to EPC and 3GPP access connected to 5GC |R18|p. 586

4.22.2.4.1  Generalp. 586
This clause applies to the case where, for a PDU Session, multi-access connectivity via both EPC (over 3GPP access) and 5GC (over non-3GPP access) is supported and allowed in the UE and network. In this case, multi-access connectivity using ATSSS via both non-3GPP access to EPC and 3GPP access to 5GC may be provided as described in this clause.
For this scenario, the general principles for ATSSS as described in clause 5.32 of TS 23.501 apply, with the additions provided in this clause 4.22.2.4.
A Multi-Access PDU Session may be extended with user-plane resources via an associated PDN Connection on non-3GPP access in EPC. This enables a scenario where a MA PDU Session can simultaneously be associated with user-plane resources on non-3GPP access network connected to EPC and 3GPP access connected to 5GC. Such a PDN Connection in EPS would thus be associated with multi-access capability in the UE and PGW-C+SMF.
The UE may operate in either single-registration mode or dual-registration mode in 3GPP access. Irrespective of whether the UE operates in single-registration mode or dual-registration mode in 3GPP access, it is assumed that the UE supports simultaneous registrations for 3GPP access in 5GC and non-3GPP access in EPC.
The ATSSS rules are provided from the PGW-C+SMF to the UE via SM NAS signalling over 5GC, as described in clause 5.32.2 of TS 23.501. ATSSS rules may be provided via the EPC.
After the establishment of a MA PDU Session and setting up user-plane resources in non-3GPP access in EPC and 3GPP access in 5GC, the UE distributes the uplink traffic across the two access networks as described in clause 5.32.1 of TS 23.501. Similarly, the PDU Session Anchor UPF performs distribution of downlink traffic across the two access networks as described in clause 5.32.1 of TS 23.501.
The PMF protocol may be used via any user plane connection, i.e. via non-3GPP access in EPC or 3GPP access in 5GC.
The PCF functionality to support ATSSS, as described in clause 5.32.1 of TS 23.501 and TS 23.503 applies also in the case of interworking with EPC.
Up
4.22.2.4.2  PDN Connections and Multi Access PDU Sessionsp. 587
When the UE wants to request a new PDN Connection in EPC and wants to use this PDN Connection as user-plane resource associated with a MA PDU Session:
  • The UE requests establishment of a new PDN Connection when the UE is registered via non-3GPP access in EPS using PDN Connection Establishment procedure. The UE provides the following ATSSS information to ePDG via IKE signalling:
    • An indication that the PDN Connection is requested to be associated with a MA PDU Session
    • The UE's ATSSS capabilities as described in clause 5.32.2 of TS 23.501 (i.e. whether the UE is capable of supporting any combination of the ATSSS-LL functionality, the MPTCP functionality and the MPQUIC functionality).
  • The ePDG may select a PGW-C+SMF as described in TS 23.402. The ePDG forwards the ATSSS information to the selected PGW-C+SMF via APCO in Create Session Request message.
  • The PGW-C+SMF determines based its capabilities whether the request can be accepted. The PCF decides whether the multi-access connectivity is allowed or not based on operator policy and subscription data, as described in clause 4.22.2. The PGW-C+SMF provides the following information via the APCO in the Create Session Response message to the ePDG:
    • An indication whether the request for using the PDN Connection for MA-PDU Session is accepted or not.
    • If the UE has indicated that it is capable of supporting the MPTCP functionality and the PGW-C+SMF accepts to activate the MPTCP functionality, then the network provides MPTCP proxy information to the UE, as described in clause 5.32.2 of TS 23.501.
    • If the UE has indicated that it is capable of supporting the MPQUIC functionality and the PGW-C+SMF accepts to activate the MPQUIC functionality, then the network provides MPQUIC proxy information to the UE, as described in clause 5.32.2 of TS 23.501.
    • UE Measurement Assistance Information (as described in clause 5.32.2 of TS 23.501).
    • ATSSS rules
  • The ePDG forwards the received above information to the UE via IKE signalling.
After the PDN Connection establishment:
  • If the UE registers to 5GC and wants to add 3GPP user-plane resources, then the UE shall send a PDU Session Establishment Request over this access containing a "MA PDU Request" indication as described in clause 5.32.2 of TS 23.501. The AMF shall select the SMF according to the UE context in SMF data from UDM for the corresponding PDU Session ID.
  • If the UE attaches in E-UTRAN/EPC, the UE shall not trigger PDN Connection establishment to add E-UTRAN/EPC access to the MA PDU Session.
When the UE wants to request a new MA PDU Session in 5GC/3GPP access, the description in clause 5.32.2 of TS 23.501, applies. After the MA PDU Session establishment in 5GC/3GPP access, the description in clause 5.32.2 of TS 23.501, applies with the following additions:
  • If the UE is registered to EPC and wants to add user-plane resources on non-3GPP access over EPC, then the UE shall send a PDN Connection Establishment Request over this access containing the IP address of the MA PDU Session in CFG_REQUEST Configuration Payload and include a "MA PDU Request" indication and UE's ATSSS capabilities and the PDU Session ID of the existing MA PDU Session on 3GPP access over 5GC. The ePDG shall select the PGW-C/SMF corresponding to the PGW identity provided by the 3GPP AAA server as described in TS 23.402. The ePDG forwards the ATSSS information via the APCO in the Create Session Request message to the PGW-C/SMF.
  • When the UE deregisters from the EPC/non-3GPP access (but remains registered on the 5GC/3GPP access), the ePDG will notify the PGW-C+SMF that the PDN Connection is released, as described in TS 23.402. The SMF can then notify the UPF that the access type has become unavailable.
A UE that has an established MA-PDU session over 3GPP access in 5GC and non-3GPP access in EPS, may be able to use Dual Connectivity for the 3GPP access leg.
Depending on the RAT types supported by the UE, the PDU Session may also be handed over to 3GPP access in EPC. For a UE supporting both E-UTRAN/EPC access and NG-RAN/5GC access, the user plane resources for 3GPP access may be moved between E-UTRAN/EPC access and NG-RAN/5GC access as described in clause 5.17.2 of TS 23.501. For the MA PDU session over 3GPP access in 5GC and non-3GPP access in EPS, when a 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 based on operator policy. In this case, while the UE remains in EPC in 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. If the SMF+PGW-C does not release the user plane resources over one of accesses, the UE sends traffic over both accesses based on ATSSS rules.
Up
4.22.2.4.3  QoS Supportp. 588
The general principles for QoS support with ATSSS as described in clause 4.22.2.3.3 apply, with the clarifications below:
  • With an MA PDU Session associated to a PDN Connection on EPS there may be separate user-plane tunnels between the AN and the PGW-U+UPF, one associated with non-3GPP access in EPC and one associated with 3GPP access in 5GS.

4.22.3  UE Requested PDU Session Establishment with Network Modification to MA PDU Sessionp. 588

4.22.3.1  Overviewp. 588

When an ATSSS-capable UE requests to establish a single-access PDU Session, but no policy in the UE and no local restrictions mandate a single access, the 5GC network may decide to modify it to a Multi-Access PDU (MA PDU) Session. This decision may be taken when e.g. the SMF wants to offload some traffic of the requested PDU Session to non-3GPP access or when the SMF wants to apply MPTCP and/or MPQUIC to provide bandwidth aggregation for the requested PDU Session.

4.22.3.2  Non-roaming or roaming with local breakoutp. 589

In the case of non-roaming or roaming with local breakout, the procedure for establishing a MA-PDU Session when the UE requests a single-access PDU Session is the same with the procedure specified in clause 4.22.2.1, with the following clarifications and modifications:
  • In step 1, the UE sets Request Type to initial request and it may include the "MA-PDU Network-Upgrade Allowed" indication in UL NAS Transport message and its ATSSS Capabilities in PDU Session Establishment Request message, if the 5GC is ATSSS capable and no policy in the UE (e.g. no URSP rule) and no local restrictions mandate a single access for the requested PDU Session. The "MA-PDU Network-Upgrade Allowed" indication indicates that the requested single-access PDU Session may be converted to a MA-PDU Session, if the 5GC network wants to.
  • In step 2, if the AMF receives the "MA-PDU Network-Upgrade Allowed" indication, the AMF may select a SMF that supports MA-PDU sessions. The AMF does not send the "MA-PDU Request" indication to SMF, but it sends the "MA-PDU Network-Upgrade Allowed" indication, if received from the UE. If the AMF determines that the requested S-NSSAI is not allowed on both accesses, the AMF shall not forward "MA-PDU Network-Upgrade Allowed" indication to the SMF. If the AMF sends the "MA-PDU Network-Upgrade Allowed" indication to SMF, it shall also indicate to SMF whether the UE is registered over both accesses.
    If the PDU Session Establishment request is for a LADN, the AMF shall not forward "MA-PDU Network-Upgrade Allowed" indication to the SMF.
  • After step 6, if SMF receives the "MA PDU Network-Upgrade Allowed" indication, the SMF may decide, if dynamic PCC is not to be used, to convert the single-access PDU Session requested by the UE into a MA PDU Session. The SMF may take this decision based on local operator policy, subscription data indicating whether the MA PDU session is allowed or not and/or other conditions, which are not specified in the present document.
    If the SMF receives ATSSS Capabilities from the UE but does not receive "MA-PDU Network-Upgrade Allowed" indication from the AMF, the SMF shall not convert the single-access PDU Session requested by the UE into a MA-PDU Session.
    If the SMF receives a UP Security Policy for the PDU Session with Integrity Protection set to "Required" and the MA-PDU session is being established over non-3GPP access, the SMF does not verify whether the access can satisfy the UP Security Policy.
  • In step 7, if dynamic PCC is to be used for the PDU Session, the SMF indicates to PCF that the SM policy control information is requested for a MA-PDU Session via "MA-PDU Network-Upgrade Allowed" indication if the MA-PDU session is allowed based on the subscription data. The SMF provides the currently used Access Type(s) and RAT Type(s) for the MA-PDU session to the H-PCF. The SMF also provides the ATSSS Capabilities of the MA-PDU session.
  • In step 10, the N4 rules derived by SMF for the MA-PDU session are sent to UPF and two N3 UL CN tunnels info are allocated by the UPF.
  • In step 11, for the MA-PDU Session, the SMF sends an "MA-PDU session Accepted" indication in the Namf_Communication_N1N2MessageTransfer message to the AMF. The AMF marks this PDU session as MA-PDU session based on the received "MA-PDU session Accepted" indication.
  • The PDU Session Establishment Accept message includes ATSSS rules which indicate to UE that the requested PDU Session was converted by the network to a MA-PDU Session.
  • The SMF triggers the establishment of user-plane resources in both accesses, if it was informed in step 2 that the UE is registered over both accesses.
Up

4.22.3.3  Home-routed, the UE registered to the same VPLMN over both accessp. 589

In the case of home-routed roaming, when the UE is registered to the same VPLMN over 3GPP access and non-3GPP access, the procedure for establishing a MA-PDU Session when the VPLMN is ATSSS capable and the UE requests a single-access PDU Session but no policy in the UE and no local restrictions mandate a single access, is the same with the procedure specified in clause 4.22.2.2.1, with the following clarifications and modifications:
  • In step 1, the UE sets Request Type to initial request and it may include an "MA-PDU Network-Upgrade Allowed" indication in UL NAS Transport message and its ATSSS Capabilities as defined in clause 5.32.2 of TS 23.501 in PDU Session Establishment Request message.
  • In step 2, if the AMF receives the "MA-PDU Network-Upgrade Allowed" indication, the AMF may select a V-SMF and a H-SMF that support MA-PDU sessions. If the AMF determines that the requested S-NSSAI is not allowed on both accesses, the AMF shall not forward "MA-PDU Network-Upgrade Allowed" indication to the V-SMF.
  • In step 3, the AMF sends the "MA-PDU Network-Upgrade Allowed" indication, if received from the UE. If the AMF sends the "MA-PDU Network-Upgrade Allowed" indication to V-SMF, it shall also indicate to V-SMF whether the UE is registered over both accesses.
  • In step 5, two DL N9 tunnel CN info and two UL N3 tunnel CN info are allocated by the V-SMF or by the V-UPF. Additionally, the V-SMF indicates to H-SMF the relationship between the DL N9 tunnel CN info and the access type. If the single CN Tunnel is established by the H-SMF, the DL N9 tunnel CN info binding to the access over which the NAS message is received is to be used.
  • In step 6, the V-SMF provides the "MA-PDU Network-Upgrade Allowed" indication, if received from AMF, together with an indication whether the UE is registered over both accesses.
  • After step 6, if the H-SMF receives the "MA-PDU Network-Upgrade Allowed" indication, the H-SMF may decide to convert the single-access PDU Session requested by the UE into a MA-PDU Session, if dynamic PCC is not to be used. The H-SMF may take this decision based on local operator policy, subscription data indicating whether the MA-PDU session is allowed or not and/or other conditions, which are not specified in the present document.
    If the H-SMF receives ATSSS Capabilities from the UE but does not receive "MA-PDU Network-Upgrade Allowed" indication from the AMF, the H-SMF shall not convert the single-access PDU Session requested by the UE into a MA-PDU Session.
  • In step 9, if dynamic PCC is to be used for the MA-PDU Session, the H-SMF sends an "MA-PDU Network-Upgrade Allowed" indication instead of "MA-PDU Request" indication to H-PCF in the SM Policy Control Create message if the MA-PDU session is allowed based on the subscription data. The H-SMF also provides the ATSSS Capabilities of the MA-PDU session. The H-PCF decides whether the single-access PDU Session can be converted into an MA-PDU session or not based on operator policy and subscription data.
  • In step 13, the H-SMF sends "MA-PDU session Accepted" indication to V-SMF in the Nsmf_PDUSession_Create Response message.
  • In step 14, the V-SMF includes the "MA-PDU session Accepted" indication in the Namf_Communication_N1N2MessageTransfer message to the AMF. The AMF mark this PDU session as MA-PDU session based on the received "MA-PDU session Accepted" indication.
  • In step 16, the UE receives a PDU Session Establishment Accept message, which includes ATSSS rules and indicates to UE that the requested single-access PDU session was established as a MA-PDU Session.
  • After step 18, two N9 tunnels between the H-UPF and the V-UPF as well as two N3 tunnels between the V-UPF and 5G-AN are established, or, if the H-UPF is connected to two different V-UPFs, the H-UPF has one N9 tunnel with each V-UPF.
Up

4.22.3.4  Home-routed, the UE registered to different PLMNs over both accessp. 590

In the case of home-routed roaming, when the UE is registered to different PLMNs over 3GPP access and non-3GPP access, the procedure for establishing a MA-PDU Session when the UE requests a single-access PDU Session in an ATSSS capable PLMN but no policy in the UE and no local restrictions mandate a single access, is the same with the procedure specified in clause 4.22.2.2.2, with the following clarifications and modifications:
  • In step 1, the UE sets Request Type to initial request and it may include an "MA-PDU Network-Upgrade Allowed" indication in UL NAS Transport message and its ATSSS Capabilities as defined in clause 5.32.2 of TS 23.501 in PDU Session Establishment Request message.
  • In step 2, if the AMF receives the "MA-PDU Network-Upgrade Allowed" indication, the AMF may select a V-SMF that supports MA-PDU sessions.
  • In step 3, the AMF sends the "MA-PDU Network-Upgrade Allowed" indication, if received from the UE.
  • In step 6, the V-SMF provides the "MA-PDU Network-Upgrade Allowed" indication, if received from AMF.
  • After step 6, if the H-SMF receives the "MA-PDU Network-Upgrade Allowed" indication, the H-SMF may decide to convert the single-access PDU Session requested by the UE into a MA-PDU Session, if dynamic PCC is not to be used. The H-SMF may take this decision based on local operator policy, subscription data indicating whether the MA-PDU session is allowed or not and/or other conditions, which are not specified in the present document.
  • In step 9, if dynamic PCC is to be used for the MA-PDU Session, the H-SMF sends an "MA-PDU Network-Upgrade Allowed" indication to H-PCF in the SM Policy Control Create message if the MA-PDU session is allowed based on the subscription data. The H-SMF also provides the ATSSS Capabilities of the MA-PDU session.
  • In step 13, the H-SMF sends "MA-PDU session Accepted" indication to V-SMF in the Nsmf_PDUSession_Create Response message.
  • In step 14, the V-SMF includes the "MA-PDU session Accepted" indication in the Namf_Communication_N1N2MessageTransfer message to the AMF. The AMF mark this PDU session as MA-PDU session based on the received "MA-PDU session Accepted" indication.
  • In step 16, the UE receives a PDU Session Establishment Accept message, which includes ATSSS rules and indicates to UE that the requested single-access PDU session was established as a MA-PDU Session.
  • After the MA-PDU Session is established over one access, the UE shall send another PDU Session Establishment Request over the other access containing the same PDU Session ID that was provided over the first access. The UE also sets Request Type as "MA-PDU Request" in UL NAS Transport message.
Up

4.22.4  Access Network Performance Measurementsp. 591

The PMF of UE side or/and UPF side should be able to correlate the measurement packets with the corresponding access type in order to get the accurate measurement result for each access. The PMF of UE side correlates the sent measurement request and received measurement response messages via the same access type and the PMF of UPF side correlates the sent measurement request and received measurement response messages via the same N3 or N9 Tunnel. The PMF of UPF side shall record the relationship between the RTT measurement result and the N3 or N9 Tunnel.
Up

4.22.5  Reporting of Access Availabilityp. 591

After the MA PDU session is established, if Reporting of Access Availability is required by network, the UE performs detection of the unavailability and availability of an access as described in clause 5.32.5.3 of TS 23.501. To report the availability/unavailability of the access, the UE sends the PMF-Access Report to the UPF via the user plane of any available access of the MA PDU session. The UPF shall use this report to decide which access can be used to deliver the downlink packets.
Up

4.22.5A  Suspend and Resume Traffic Duplication |R18|p. 591

After the MA PDU session is established and the Redundant steering mode is active, the UPF may suspend traffic duplication by sending PMF-Suspend Duplication Request to the UE via the user plane of any available access of the MA PDU session as described in clause 5.32.5.6 of TS 23.501. The UPF may resume traffic duplication for a UE by sending PMF-Resume Duplication Request via the user plane of any available access of the MA PDU session as described in clause 5.32.5.6 of TS 23.501.
Up

4.22.6  EPS Interworkingp. 592

4.22.6.1  Generalp. 592

This clause includes mobility procedures for interworking with EPS. MA PDU Session establishment procedures with user plane resources in EPS are described in clause 4.22.2.3 and clause 4.22.2.4.

4.22.6.2  Impacts to EPS interworking proceduresp. 592

4.22.6.2.1  5GS to EPS handover using N26 interfacep. 592
Based on the signalling flow in Figure 4.11.1.2.1-1, the procedure is performed with the following differences and modifications:
  • Step 2 is also performed with all the SMF+PGW-Cs corresponding to MA-PDU Sessions with allocated EBI(s).
  • In step 12e, the AMF requests the release of the 3GPP access of the MA-PDU Session which has resources established for 3GPP access, but not expected to be transferred to EPC, i.e. no EBI(s) allocated to the MA-PDU Session by triggering Nsmf_PDUSession_UpdateSMContext service operation.
  • In step 16, if the MA PDU Session is established in both 3GPP and non-3GPP accesses and the MA PDU Session is moved to EPS and if the UE or the network does not supports MA PDU Session with 3GPP access connected to EPC, the SMF triggers the MA PDU Session Release procedure over non-3GPP access. If UE and the network support MA PDU Session with 3GPP access connected to EPC, the SMF should keep the user-plane resources over non-3GPP access in 5GC and use the PDN Connection as the 3GPP access leg of the MA PDU Session. 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 MA PDU Session is moved to EPS and if the UE and network supports MA PDU Session with non-3GPP access connected to EPC, the SMF 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 not allowed based on operator policy, the SMF+PGW-C may release the user plane resources either over 3GPP access or non-3GPP access. 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
4.22.6.2.2  5GS to EPS idle mode mobility using N26 interfacep. 592
Based on the signalling flow in Figure 4.11.1.3.2-1, the procedure is performed with the following differences and modifications:
  • Step 5a is also performed with all the SMF+PGW-Cs corresponding to the MA-PDU Sessions with allocated EBI(s).
  • In step 12, if the MA PDU Session is established in both 3GPP and non-3GPP accesses and the MA PDU Session is moved to EPS and if the UE or the network does not support MA PDU Session with 3GPP access connected to EPC, the SMF triggers the MA PDU Session Release procedure over non-3GPP access. If UE and the network support MA PDU Session with 3GPP access connected to EPC, the SMF should keep the user-plane resources over non-3GPP access in 5GC and use the PDN Connection as the 3GPP access leg of the MA PDU Session. 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 MA PDU Session is moved to EPS and if the UE and network supports MA PDU Session with non-3GPP access connected to EPC, the SMF 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 not allowed based on operator policy, the SMF+PGW-C may release the user plane resources either over 3GPP access or non-3GPP access. 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.
  • In step 15a, the AMF also requests the release of the MA-PDU Session which has resources established for 3GPP access, but not expected to be transferred to EPS, i.e. no EBI(s) allocated to the MA-PDU Session by triggering Nsmf_PDUSession_UpdateSMContext service operation.
Up
4.22.6.2.3  EPS bearer ID allocationp. 593
Based on the signalling flow in Figure 4.11.1.4.1-1, additionally for the MA-PDU Session, with the following differences and clarifications:
  • In step 1, the following procedures and relevant steps are also initiated during the UE Requested MA-PDU Session Establishment, the UE Requested PDU Session Establishment with Network Modification to MA-PDU Session and the UE or network requested MA-PDU Session Modification procedures.
  • In step 2, if the QoS Flow(s) of the MA-PDU Session is established and the MA-PDU Session is established over 3GPP access and other existing conditions satisfies EPS interworking, the SMF requests EBI allocation for the QoS Flow(s) of the MA-PDU Session.
Up
4.22.6.2.4  EPS bearer ID revocationp. 593
Based on the clause 4.11.1.4.3, additionally the following procedures are updated to revoke the EPS bearer ID(s) assigned to the QoS Flow(s) in the MA-PDU Session:
  • UE or network requested MA-PDU Session Release (non-roaming and roaming with local breakout) in clause 4.22.10.2.
  • UE or network requested MA-PDU Session Release (home-routed roaming) in clause 4.22.10.3.
  • UE or network requested MA-PDU Session Modification (non-roaming and roaming with local breakout) in clause 4.22.8.2.
  • UE or network requested MA-PDU Session Modification (home-routed roaming) in clause 4.22.8.3.
  • When the MA-PDU Session is released over 3GPP access, the UE and the SMF locally release the EBI(s) for the MA-PDU Session. The SMF notifies the AMF of the released EBI(s) by sending Nsmf_PDUSession_SMContextStatusNotify service operation if the MA-PDU Session is established in the same PLMN. If the MA-PDU Session is established in different PLMNs, the SMF notifies the release of the MA-PDU Session and as a result, the AMF removes associated EBI(s).
Up
4.22.6.2.5  5GS to EPS mobility without N26 interfacep. 593
Based on the signalling flow in Figure 4.11.2.2-1, the procedure is performed with the following differences and modifications:
  • In step 10 (and step 13 in clause 4.11.2.4.1), if the MA-PDU Session is established in both 3GPP and non-3GPP accesses and the MA-PDU Session is moved to EPS and if the UE and the network does not support MA-PDU Session with 3GPP access connected to EPC, the PGW-C + SMF triggers the MA-PDU Session Release procedure over non-3GPP access. PGW-C + SMF and UE locally release the context related to ATSSS operation, e.g. ATSSS rules and Measurement Assistance Information for the relevant session. If the UE and the network support MA-PDU Session with 3GPP access connected to EPC, the UE includes a "MA-PDU Request" indication and the PDU Session ID in the PCO, the SMF should keep the user-plane resources over non-3GPP access in 5GC and use the PDN Connection as the 3GPP access leg of the MA-PDU Session.
  • In step 13, during the additional PDN Connectivity Procedure, if the MA-PDU Session is established in both 3GPP and non-3GPP accesses and if the UE and the network support MA-PDU Session with 3GPP access connected to EPC, the UE includes a "MA-PDU Request" indication and the PDU Session ID in the PCO, the SMF should keep the user-plane resources over non-3GPP access in 5GC and use the PDN Connection as the 3GPP access leg of the MA-PDU Session. If the UE and the network does not support MA-PDU Session with 3GPP access connected to EPC and the MA-PDU Session is moved to EPS, the PGW-C + SMF triggers the MA-PDU Session Release procedure over non-3GPP access. PGW-C + SMF and UE locally release the context related to ATSSS operation, e.g. ATSSS rules and Measurement Assistance Information for the relevant session(s).
  • Step 14 is also performed for the MA-PDU session(s) transferred to EPS.
Up

4.22.6.3  Network Modification to MA PDU Session after a UE moving from EPCp. 594

Figure 4.22.6.3-1 describes procedure for Network Modification to MA-PDU Session after a UE is moving from EPS.
Reproduction of 3GPP TS 23.502, Fig. 4.22.6.3-1: Network Modification to MA-PDU Session after a UE moving from EPS
Up
Step 1.
When the network supports interworking with N26 interface, a PDN Connection can be moved from EPS to 5GS as described in clause 4.11.1.2.2 and clause 4.11.1.3.3.
Step 2.
If the UE requests 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, the UE requests PDU Session Modification over 3GPP access as described in clause 4.22.8 with following modifications:
  • In step 1a, the UE provides Request Type as "MA-PDU Request" in UL NAS Transport message, 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 provides an "MA-PDU Network-Upgrade Allowed" indication in UL NAS Transport message. The UE provides its ATSSS Capabilities, as defined in clause 5.32.2 of TS 23.501 in PDU Session Modification Request message. If the AMF receives the "MA-PDU Network-Upgrade Allowed" indication from the UE, the AMF may send it to the SMF. If the AMF determines that the UE is registered via both accesses in the same PLMN but the current S-NSSAI is not in the Allowed NSSAI for both accesses, the AMF shall reject the PDU session modification if the UE provides an "MA-PDU Request" indication, or the AMF shall not forward "MA-PDU Network-Upgrade Allowed" indication to the SMF if received from the UE.
  • In step 3a, if the SMF decides to change the PDU Session to MA-PDU Session, the SMF includes ATSSS rule(s) in the PDU Session Modification Command message. The SMF may also include Measurement Assistance Information. When the SMF sends Nsmf_PDUSession_UpdateSMContext response, the SMF includes "MA-PDU session Accepted" indication. The AMF marks the PDU Session as MA-PDU Session based on the indication. If the SMF was informed in step 1a that the UE is registered over both accesses, then the SMF initiates the establishment of user-plane resources over non-3GPP access too.
  • In step 5, if the UE receives ATSSS rule(s) in the PDU Session Modification Command message, the UE stores that the PDU Session is MA-PDU Session.
Step 3.
If the UE is registered to the different PLMN over 3GPP and non-3GPP access or the UE is not registered in non-3GPP access, the UE may trigger the UE requested PDU Session Establishment procedure as described in clause 4.22.7 over non-3GPP access to add second access to the MA-PDU Session after the UE is registered in non 3GPP access.
Up

4.22.7  Adding / Re-activating / De-activating User-Plane Resourcesp. 595

If the UE has established a MA-PDU Session but the user-plane resources over one access of the MA-PDU Session have not been established, then:
  • If the UE wants to add user-plane resources over this access, the UE shall initiate the UE Requested PDU Session Establishment procedure over this access, as specified in clause 4.3.2.2. In the UL NAS Transport message, the UE sets Request Type as "MA-PDU Request" and the same PDU Session ID of the established MA-PDU Session. If only one N9 tunnel is established for the Home Routed roaming case as described in clause 4.22.2.2, additional N9 tunnel is established during this UE Requested PDU Session Establishment procedure. For the roaming with home-routed architecture as defined in TS 23.501 Figure 4.2.10-3, an N9 tunnel or an N3 tunnel is established during this PDU Session Establishment procedure, depending on the access for which the UE is requesting user-plane resources.
  • The PDU Session Establishment Accept message received by the UE may contain updated ATSSS rules for the MA-PDU session.
  • If the SMF receives the PDU Session Establishment request message over an access and the SMF already has SM Contexts for the access, the SMF shall not release existing SM Contexts and shall re-activate user plane resources over the access while providing the PDU Session Establishment Accept message to the UE.
If the UE has established a MA-PDU Session and the user-plane resources over one access of the MA-PDU Session have been established but are currently inactive (e.g. because the UE is CM-IDLE over this access), then:
  • If the UE wants to re-activate the user-plane resources over this access, then the UE shall initiate the Registration or UE Triggered Service Request procedure over this access, as specified in clause 4.22.9.2.
  • If the network wants to re-activate the user-plane resources over 3GPP access of the MA-PDU Session, or over non-3GPP access of the MA-PDU Session, the network shall initiate the Network Triggered Service Request procedure, as specified in clause 4.22.9.4.
If the UE has established a MA-PDU Session and the user plane resources are activated over either one access or both accesses, then:
  • If the network wants to de-activate the user-plane resources over single access, then the network shall initiate the CN-initiated deactivation of UP connection procedure over this access, as specified in clause 4.3.7.
In all cases, if the UP security protection associated with this PDU session indicates that UP security is required, the SMF shall not establish resources over the 3GPP access unless the 3GPP Access Network can enforce the required UP security protection, even if resources were previously established over non-3GPP access.
Up

4.22.8  UE or network requested MA PDU Session Modificationp. 595

4.22.8.1  Generalp. 595

This procedure is triggered in the following cases:
  • QoS Flow creation / modification (including GBR QoS Flow movement).
  • Update of ATSSS rules and/or N4 rules.

4.22.8.2  UE or network requested MA PDU Session Modification (non-roaming and roaming with local breakout)p. 595

The signalling flow for a MA-PDU Session Modification when the UE is not roaming, or when the UE is roaming and the PDU Session Anchor (PSA) is located in the VPLMN, is based on the signalling flow in Figure 4.3.3.2-1 with the following differences and clarifications:
  • In step 1b, the SMF may decide to update ATSSS rules and/or N4 rules based on updated PCC rules.
  • In step 1d, if the UPF determines that it cannot send GBR traffic over the current ongoing access e.g. based on the N4 rules and access availability and unavailability report from the UE, the UPF shall send Access Availability report to the SMF. When the SMF receives the Access Availability report, the SMF may decide to move the GBR QoS Flow to the other access as described in clause 5.32.4 of TS 23.501. If the SMF decides to move the GBR QoS Flow, the SMF triggers this procedure and afterwards moves the GBR QoS Flow to the target access.
  • In step 3, if the SMF decides to move the GBR QoS Flow to the other access, the SMF sends N2 SM information to the target AN. The PDU Session Modification Command message is sent to the UE to update ATSSS rule of the UE so that the UE sends uplink GBR traffic over the target access. The SMF releases AN resources of the GBR QoS Flow in the source access.
  • In step 3, when the SMF establishes user plane resources for a QoS flows, the SMF provides QoS profile to the AN as follows:
  • for Non-GBR QoS Flow, steps 3 to 8 are performed over each access for which the user plane resources are activated.
  • for GBR QoS Flow allowed in a single access, steps 3 to 8 are performed in the allowed access.
  • for GBR QoS Flow allowed in both accesses, steps 3 to 8 are performed in the access according to the decision by the SMF (as described in clause 5.32.4 of TS 23.501).
  • In step 3, if the SMF wants to update ATSSS rules, the SMF includes updated ATSSS rules in the N1 SM container (PDU Session Modification Command). When the SMF provides N1 SM container and/or N2 SM information, the SMF includes access type in the Namf_Communication_N1N2MessageTransfer to provide routing information to the AMF.
  • In step 8, if the SMF decides to moves GBR QoS Flow to the other access, the SMF may send updated N4 rules to the UPF.
Up

4.22.8.3  UE or network requested MA PDU Session Modification (home-routed roaming)p. 596

The signalling flow for a MA-PDU Session Modification when the UE is registered to the same VPLMN over 3GPP access and non-3GPP access and the PDU Session Anchor (PSA) is located in the HPLMN, is based on the signalling flow in Figure 4.3.3.3-1 with the following differences and clarifications:
  • In step 1b, the H-SMF may decide to update ATSSS rules and/or N4 rules based on updated PCC rules.
  • In step 1d, if the H-UPF determines that it cannot send GBR traffic over the current ongoing access e.g. based on the N4 rules and access availability and unavailability report from the UE, the H-UPF shall send Access Availability report to the H-SMF. When the H-SMF receives the Access Availability report, the H-SMF may decide to move the GBR QoS Flow to the other access as described in clause 5.32.4 of TS 23.501. If the H-SMF decides to move GBR QoS Flow, the H-SMF triggers this procedure and afterwards moves the GBR QoS flow to the target access.
  • In step 3, if the H-SMF decides to move the GBR QoS Flow to the other access, the H-SMF sends updated GBR QoS Flow information contains associated access type and ATSSS rule to the V-SMF. Based on the information the V-SMF establishes AN resources for the GBR QoS Flow to the target access.
  • In step 3, when the H-SMF provides GBR QoS Flow information, the H-SMF includes associated access type in Nsmf_PDUSession_Update. When the H-SMF provides non-GBR QoS Flow information, H-SMF provides the information for both accesses in Nsmf_PDUSession_Update.
  • In step 3, if the H-SMF wants to update ATSSS rules, the H-SMF triggers Nsmf_PDUSession_Update and includes an updated ATSSS rules.
  • In step 4, if the H-SMF decides to move the GBR QoS Flow to the other access, the PDU Session Modification Command message is sent to the UE to update ATSSS rule of the UE so that the UE sends uplink GBR traffic over the target access. The V-SMF releases AN resources of the GBR QoS Flow in the source access.
  • In step 4, when the V-SMF establishes user plane resources for a QoS flows, the V-SMF provides QoS profile to the AN as follows:
    • for Non-GBR QoS Flow, steps 4 to 9 are performed over each access for which the MA-PDU Session is established.
    • for GBR QoS Flow allowed in a single access, steps 4 to 9 are performed in the allowed access.
    • for GBR QoS Flow allowed in both accesses, steps 4 to 9 are performed in the access according to the decision by the SMF (as described in clause 5.32.4 of TS 23.501).
  • In step 4, if the H-SMF provides updated ATSSS rules, the V-SMF includes the updated ATSSS rules in the N1 SM container (PDU Session Modification Command). When the V-SMF provides N1 SM container and/or N2 SM information, the V-SMF includes access type in the Namf_Communication_N1N2MessageTransfer to provide routing information to the AMF.
The description of signalling flow for a MA-PDU Session Modification when the UE is registered to different PLMNs over 3GPP access and non-3GPP access and the PDU Session Anchor (PSA) is located in the HPLMN, is based on above procedure with the following differences and clarifications:
  • The description of (V-)SMF providing QoS profile to the AN is not applicable and instead the regular procedures for QoS profile provisioning from (V-)SMF to (R)AN applies.
Up

4.22.9  Connection, Registration and Mobility Management proceduresp. 597

4.22.9.1  Registration proceduresp. 597

Support for using the Registration procedures for non-3GPP access path switching is described in clause 4.22.9.5.
The signalling flow for a Registration is based on the signalling flow in Figure 4.2.2.2.2-1 with the following differences and clarifications:
  • In step 1, if the UE wants to re-activate the user plane of the MA-PDU Session(s) over the access the Registration message is sent to, the UE indicates PDU Session ID(s) of the MA-PDU Session(s) in the List Of PDU Sessions To Be Activated.
    If the UE locally releases the MA-PDU Session(s) in both accesses, the UE indicates it in the PDU Session Status. If the AMF receives the PDU Session Status and finds mismatch, regardless of roaming mode of the MA-PDU Session(s) (i.e. non-roaming, local breakout roaming, home routed roaming in the same PLMN or home routed roaming in different PLMNs), the AMF invokes Nsmf_PDUSession_ReleaseSMContext service towards the SMF(s) in order to release any network resources related to the MA-PDU Session(s).
  • In step 4, the old AMF determines whether the new AMF support ATSSS or not based on the supported features provided by the new AMF.
  • In step 5, if the old AMF determined in step 4 that the new AMF does not support ATSSS, the old AMF does not include the PDU Session context of the MA-PDU Session(s) in the UE context transferred to the new AMF.
  • If the old AMF has not included MA-PDU Session(s) in the UE context in step 5, the old AMF informs the corresponding SMF(s) to release the MA-PDU Session(s) by invoking the Nsmf_PDUSession_ReleaseSMContext service operation as described in clause 4.22.10.
  • In step 21, the AMF provides an MA-PDU Session Support indicator in Registration Accept message to inform the UE whether ATSSS is supported or not. The UE uses this indicator to determine whether an MA-PDU session related procedure can be initiated or not, as described in clause 4.22.1.
    In step 17, if the UE indicated to re-activate MA-PDU Session(s) in the List Of PDU Sessions To Be Activated the AMF includes access type which the Registration Request message is received on when the AMF triggers Nsmf_PDUSession_UpdateSMContext service operation. The SMF only re-activates user plane resources of the access type the Registration Request message is received on.
  • In step 21, the AMF indicates to the UE whether it supports non-3GPP access path switching.
  • In step 22, if the AMF indicates that the PDU Session(s) has been released in the PDU Session Status to the UE in Registration Accept message, the UE removes locally any internal resources related to the MA-PDU Session(s) that are not marked as established.
Up

4.22.9.2  UE Triggered Service Requestp. 598

The signalling flow for a UE Triggered Service Request is based on the signalling flow in Figure 4.2.3.2-1 with the following differences and clarifications:
  • In step 1, if the UE wants to re-activate the user plane of the MA-PDU Session(s) over the access the Service Request message is sent to, the UE indicates PDU Session ID(s) of the MA-PDU Session(s) in the List Of PDU Sessions To Be Activated.
    If the UE locally releases the MA-PDU Session(s), the UE indicates it in the PDU Session Status. If the AMF receives the PDU Session Status and finds mismatch, regardless of roaming mode of the MA-PDU Session (i.e. non-roaming, local breakout roaming, home routed roaming in the same PLMN or home routed roaming in different PLMNs), the AMF invokes Nsmf_PDUSession_ReleaseSMContext service towards the SMF(s) in order to release any network resources related to the MA-PDU Session(s).
    In step 4, if the UE indicated to re-activate MA-PDU Session(s) in the List Of PDU Sessions To Be Activated the AMF includes access type which the Service Request message is received on when the AMF triggers Nsmf_PDUSession_UpdateSMContext service operation. The SMF only re-activates user plane resources of the access type the Service Request message is received on.
  • In step 12, if the AMF indicates that the PDU Session(s) has been released in the PDU Session Status to the UE in Service Accept message, the UE removes locally any internal resources related to the MA-PDU Session(s) that are not marked as established.
Up

4.22.9.3  N2 based handoverp. 598

Inter NG-RAN node N2 based handover, as described in clauses 4.9.1.3.2 and 4.9.1.3.3, is supported for the 3GPP access with the differences and clarifications described below.
  • In step 2 of clause 4.9.1.3.2, the S-AMF determines whether or not the T-AMF supports ATSSS based on the supported features of the T-AMF provided by NRF or based on local configuration.
  • In step 3 of clause 4.9.1.3.2, if the S-AMF determined in step 2 that the T-AMF does not support ATSSS, the S-AMF does not include the PDU Session context of the MA-PDU Session(s) in the UE context transferred to the T-AMF.
  • After step 6a of clause 4.9.1.3.3, if the S-AMF has not included MA-PDU Session(s) in the UE context in step 3 of clause 4.9.1.3.2, the S-AMF informs the corresponding SMF(s) to release the MA-PDU Session(s) by invoking the Nsmf_PDUSession_ReleaseSMContext service operation as described in clause 4.22.10.
Up

4.22.9.4  Network Triggered Service Requestp. 598

The signalling flow for a Network Triggered Service Request is based on the signalling flow in Figure 4.2.3.3-1 with the following differences and clarifications:
  • In step 2a, the SMF determines over which access (3GPP access or non-3GPP access or both accesses) the user plane resources need to be activated for the MA PDU Session. The SMF may consider Steering Mode to determine the target access.
  • In step 3a, the SMF indicates to the AMF the access type (3GPP access or non-3GPP access) over which the user plane resources are to be activated for the MA-PDU Session.
    In the case of DN-AAA or SMF initiated Secondary re-authentication procedure, when the SMF invokes the Namf_Communication_N1N2MessageTransfer service operation, SMF may indicate the target access type of sending N1 NAS message to the UE.
  • In step 4, the AMF considers the MA-PDU Session is associated with the access type the SMF has indicated in step 3a.
    The AMF determines the access type of which to send the N1 NAS message to the UE based on the target access type value if received from the SMF in step 3a. If the AMF does not receive a target access type value and the UE is CM-CONNECTED in both accesses, the AMF determines the target access type.
  • In step 5, if the SMF requested to re-activate user-plane resources over 3GPP access and the AMF has determined the UE is unreachable over 3GPP access (e.g. the AMF receives no response from the UE to the Paging), the AMF shall notify that the UE is unreachable. The (H-) SMF shall indicate the Anchor UPF that the user-plane resources on 3GPP access is unavailable by triggering N4 Session Modification procedure. Further action by the UPF is implementation dependent.
    If the SMF requested to re-activate the user-plane resources over non-3GPP access and the AMF has determined the UE is unreachable over non-3GPP access (e.g. the UE is in CM-IDLE on non-3GPP access), the AMF shall reject the request from the SMF. The (H-) SMF shall indicate the Anchor UPF that the user-plane resources on non-3GPP access is unavailable by triggering N4 Session Modification procedure. Further action by the UPF is implementation dependent.
    If this procedure is triggered for Secondary Re-authentication and UE and SMF+PGW-C supports for DN authentication and authorization over EPC as described in clause 5.4.4b clause 5.4.4b of TS 23.501, SMF+PGW-C selects one access type from non-3GPP access connected to 5GC or 3GPP access connected to EPC in step 3a. If the SMF+PGW-C receives failure indication from the AMF or MME that UE is unreachable then SMF+PGW-C retries by sending it to the other access type. Only when the failure is received from both AMF and MME, then SMF+PGW-C informs the DN-AAA Server that UE is not reachable for re-authentication according to clauses 4.3.2.3 and H.2.1.
Up

4.22.9.5  Registration procedures for non-3GPP access path switching |R18|p. 599

If the UE supports non-3GPP access path switching and the AMF indicates that the network supports non-3GPP access path switching as described in clause 4.22.2, the UE may trigger a Mobility Registration Update via a new non-3GPP access to switch traffic from an old non-3GPP access (i.e. TNGF or N3IWF) to the new non-3GPP access (i.e. TNGF or N3IWF) if the PLMN of the selected new non-3GPP access is the same PLMN of the old non-3GPP access.
The UE may trigger non-3GPP path switching if the AMF indicated support during registration as described in clause 4.22.9.1, even if the SMF did not indicate support to the UE during the MA PDU Session Establishment.
In this case the Registration procedure described in clause 4.22.9.1 applies with the differences and clarifications described in this clause:
Reproduction of 3GPP TS 23.502, Fig. 4.22.9.5-1: Mobility Registration procedure for non-3GPP access path switching
Up
Step 1.
This is the same as step 1 in clause 4.22.9.1, with the following additions:
  • If the UE wants to switch the user plane from an old non-3GPP access to a new non-3GPP access where the Mobility Registration Update is sent, the UE indicates PDU Session ID(s) of the PDU Session(s) in the List Of PDU Sessions To Be Activated. This may include both PDU Session ID(s) corresponding to MA PDU Sessions and single access PDU Sessions.
    The UE may also provide an ("Non-3GPP access path switching while using old AN resources") indication in the Registration Request to indicate that the UP connection(s) via the old non-3GPP access can still be used for the MA PDU Session(s) during the Registration procedure. If the UP connection(s) via the old non-3GPP access cannot be used by the UE during the Registration procedure, the UE shall not provide a "Non-3GPP access path switching while using old AN resources" indication.
    The UE shall not perform non-3GPP access path switching if the PLMN of the selected new non-3GPP access is different from the PLMN of the old non-3GPP access.
Step 2.
This is the same as step 2 in Figure 4.2.2.2.2-1.
Step 3.
This is the same as step 3 in Figure 4.2.2.2.2-1 with the following additions:
  • If the UE provided an ("Non-3GPP access path switching while using old AN resources") indication in step 1 and the AMF supports to maintain two N2 connections for non-3GPP access during the Registration procedure and the SMF supports non-3GPP access path switching, the AMF delays the release of the old N2 connection until the UP connection via the new non-3GPP access is established. Otherwise, the AMF may trigger AN release towards the old non-3GPP access before proceeding with the Registration procedure in the new non-3GPP access, as described in clause 4.12.4.2 for untrusted non-3GPP access and clause 4.12a.4.2 for trusted non-3GPP access with the following clarifications:
  • During the AN release procedure, the AMF should notify the SMF to release the UP resources for the activated PDU Sessions before sending the N2 UE Context Release Command to the old non-3GPP access.
  • Due to pending downlink data in the UPF, the SMF may requests to establish user plane resources before non-3GPP path switching is finished. In this case, the AMF may reject the request with an indication that the Namf_Communication_N1N2MessageTransfer has been temporarily rejected. Upon reception of an Namf_Communication_N1N2MessageTransfer response with an indication that its request has been temporarily rejected, the SMF shall start a locally configured guard timer and wait for any message to come from an AMF. Upon reception of a message from an AMF, the SMF shall re-invoke the Namf_Communication_N1N2MessageTransfer (with N2 SM info and/or N1 SM info) to the AMF.
Step 4.
This is the same as steps 4-16 in Figure 4.2.2.2.2-1.
Step 5-11.
These steps are the same as step 17 in clause 4.22.9.1, with the following additions:
  • If the Registration procedure is triggered to switch traffic from the old non-3GPP access to the new non-3GPP access and the UE provided an ("Non-3GPP access path switching while using old AN resources") indication in step 1, the AMF, if it supports maintaining two N2 connections for non-3GPP access, forwards this indication to the SMF in case the PDU Session is a MA PDU Session. If the SMF receives this indication, the SMF does not trigger release of the UP connection in the old non-3GPP access towards the old N3IWF or TNGF (if any).
  • In step 7 and 8, the CN Tunnel Info is sent from SMF to the new non-3GPP AN via AMF. The IPSec child SA(s) between UE and the new non-3GPP AN are established.
  • In step 10, the SMF updates the N4 rules by replacing the AN Tunnel Info of the old non-3GPP AN with the AN Tunnel Info of the new non-3GPP AN to instruct the UPF to switch traffic from the old non-3GPP access path to the new non-3GPP access path.
  • After the UP connection via the new non-3GPP access is established, the UE and UPF start to send traffic via the new non-3GPP access.
Step 12.
After the UP connection has been established in new non-3GPP access, the AMF also triggers AN release towards the old non-3GPP access (i.e. old N3IWF or TNGF), unless done previously with following clarifications:
  • For the PDU Sessions indicated by the old non-3GPP access in the "List of PDU Session ID(s) with active N3 user plane" but not in the List Of PDU Sessions To Be Activated sent by the UE in step 1, the AMF requests the SMF to deactivate the PDU Session(s). For other PDU Sessions, the AMF shall not request the SMF to deactivate the PDU Session(s).
  • When the UE receives Registration Accept over the new non-3GPP access, the UE considers that the UE is deregistered from the old non-3GPP access.
Up

4.22.10  MA PDU Session Releasep. 601

4.22.10.1  Generalp. 601

The MA-PDU Session Release procedure is used to release the MA-PDU Session, or release the MA-PDU Session over a single access. The MA-PDU Session Release over a single access may be triggered by the network due to e.g. when the UE is deregistered over an access or when the S-NSSAI of the MA-PDU Session is no longer in the Allowed NSSAI over an access.

4.22.10.2  UE or network requested MA PDU Session Release (non-roaming and roaming with local breakout)p. 602

The signalling flow for a MA-PDU Session Release when the UE is not roaming, or when the UE is roaming and the PDU Session Anchor (PSA) is located in the VPLMN, is based on the signalling flow in Figure 4.3.4.2-1 with the following differences and clarifications:
  • In step 1, if the AMF needs to release the MA-PDU Session over a single access, the AMF invokes the Nsmf_PDUSession_UpdateSMContext service operation to request the release of the MA-PDU Session over a single access. In this case, the AMF includes in which access the MA-PDU Session should be released.
  • In step 1, if the AMF needs to release the MA-PDU Session (e.g. locally released when the UE is CM-IDLE), the AMF invokes the Nsmf_PDUSession_ReleaseSMContext service operation to request the release of the MA-PDU Session.
  • In step 2a, if the SMF releases the MA-PDU Session over a single access, the SMF sends an N4 Session Modification Request (N4 Session ID) message instead of N4 Session Release message to the UPF(s) of the MA-PDU session.
  • In step 2b, the UPF acknowledges the N4 Session Modification Request by the transmission of an N4 Session Modification Response (N4 Session ID) message to the SMF.
  • In step 3, the SMF sends the PDU Session Release Command message to release the MA-PDU session over a single access (either 3GPP access or non-3GPP access) or both accesses.
  • In step 3, if the SMF releases the MA-PDU Session over a single access, the SMF shall not include "skip indicator" in the Namf_Communication_N1N2MessageTransfer service.
  • In step 3, if the SMF releases the MA-PDU Session over both accesses and user plane resources are established in both accesses, the SMF includes both N1 SM container (PDU Session Release Command) and N2 SM Resource Release request together in the Nsmf_PDUSession_UpdateSMContext or Namf_Communication_N1N2MessageTransfer service so that the UE does not request to activate user plane resources. The SMF releases user plane resources of the other access by including N2 SM Resource Release only in Namf_Communication_N1N2MessageTransfer service.
  • In step 3, when the SMF provides N1 SM container and/or N2 SM information, the SMF includes access type in the Namf_Communication_N1N2MessageTransfer to provide routing information to the AMF.
  • In step 11, the SMF triggers Nsmf_PDUSession_SMContextStatusNotify service only when the MA-PDU Session is released in both accesses.
Up

4.22.10.3  UE or network requested MA PDU Session Release (home-routed roaming)p. 602

The signalling flow for a MA-PDU Session Release when the UE is registered to the same VPLMN over 3GPP access and non-3GPP access and the PDU Session Anchor (PSA) is located in the HPLMN, is based on the signalling flow in Figure 4.3.4.3-1 with the following differences and clarifications:
  • In step 1, if the V-AMF needs to release the MA-PDU Session over a single access, the V-AMF may invoke the Nsmf_PDUSession_UpdateSMContext service operation to request the release of the MA-PDU Session over a single access. In this case, the AMF shall include in which access the MA-PDU Session should be released. The V-SMF invokes Nsmf_PDUSession_Update service operation to request the release of the MA-PDU Session over a single access. The V-SMF shall include in which access the MA-PDU Session should be released.
  • In step 1, if the V-AMF needs to release the MA-PDU Session (e.g. locally released when the UE is CM-IDLE), the AMF invokes the Nsmf_PDUSession_ReleaseSMContext service operation to request the release of the MA-PDU Session. The V-SMF invokes Nsmf_PDUSession_Release service operation to request the release of the MA-PDU Session.
  • In steps 2a-2b, if the SMF releases the MA-PDU Session over a single access, these steps are the same as steps 2a-2b in clause 4.22.10.2.
  • In step 3a, the H-SMF invokes Nsmf_PDUSession_Update service operation towards the V-SMF to release the MA-PDU session over a single access (either 3GPP access or non-3GPP access) or both accesses.
  • In step 5, the V-SMF sends the PDU Session Release Command message to release the MA-PDU session over a single access (either 3GPP access or non-3GPP access) or both accesses.
  • In step 5, if the V-SMF releases the MA-PDU Session over a single Access Network, the V-SMF shall not include "skip indicator" in the Namf_Communication_N1N2MessageTransfer service.
  • In step 5, if the V-SMF releases the MA-PDU Session over both accesses and user plane resources are established in both accesses, the V-SMF includes both N1 SM container (PDU Session Release Command) and N2 SM Resource Release request together in the Nsmf_PDUSession_UpdateSMContext or Namf_Communication_N1N2MessageTransfer service so that the UE does not request to activate user plane resources. The V-SMF releases user plane resources of the other access by including N2 SM Resource Release only in Namf_Communication_N1N2MessageTransfer service.
  • In step 5, when the V-SMF provides N1 SM container and/or N2 SM information, the V-SMF includes access type in the Namf_Communication_N1N2MessageTransfer to provide routing information to the V-AMF.
  • In step 16, the H-SMF triggers Nsmf_PDUSession_StatusNotify service only when the MA-PDU Session is released in both accesses. The V-SMF triggers Nsmf_PDUSession_SMContextStatusNotify service only when the MA-PDU Session is released in both accesses.
The signalling flow for a MA-PDU Session Release when the UE is registered to the different PLMNs over 3GPP access and non-3GPP access and the PDU Session Anchor (PSA) is located in the HPLMN, is based on the above procedure with the following differences and clarifications:
  • In step 1a, the (V-)AMF can trigger the MA-PDU session release over a single access or over both accesses as described in step 1 of clause 4.22.10.2.
  • In step 3a, the H-SMF invokes Nsmf_PDUSession_Update service operation towards the V-SMF to release the MA-PDU Session over a single access (either 3GPP access or non-3GPP access) or both accesses.
    If the UE is registered to the HPLMN via an access and the H-SMF releases MA-PDU Session over the access, the H-SMF invokes Namf_Communication_N1N2MessageTransfer.
  • In step 5, the V-SMF releases the MA-PDU Session over the access the H-SMF indicated in step 3a.
Up

Up   Top   ToC