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

Content for  TS 23.502  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2.2   4.3.2.2.3…   4.3.3…   4.3.4…   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.2.2…   4.11.1.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.7…   4.15.7…   4.16…   4.16.4…   4.16.8…   4.16.11…   4.17…   4.17.9…   4.18…   4.19…   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.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.19 Network Data Analytics  4.20 UE Parameters Update via UDM Control Plane Procedure  4.21 Secondary RAT Usage Data Reporting Procedure  4.22 ATSSS Procedures  4.22.1 General  4.22.2 UE Requested MA PDU Session Establishment  4.22.3 UE Requested PDU Session Establishment with Network Modification to MA PDU Session  4.22.4 Access Network Performance Measurements  4.22.5 Reporting of Access Availability  4.22.6 EPS Interworking  4.22.7 Adding / Re-activating / De-activating User-Plane Resources  4.22.8 UE or network requested MA PDU Session Modification  4.22.9 Connection, Registration and Mobility Management procedures  4.22.10 MA PDU Session Release 
...

 

4.19  Network Data Analytics  p. 463

The system procedures for Network Data Analytics are defined in clause 6 of TS 23.288.

4.19.1  Void

4.19.2  Void

4.20  UE Parameters Update via UDM Control Plane Procedure  p. 463

4.20.1  General  p. 463

The purpose of the control plane solution for update of UE parameters is to allow the HPLMN, SNPN, or CH to update the UE with a specific set of parameters, generated and stored in the UDM, by delivering protected UDM Update Data via NAS signalling. The HPLMN, SNPN, or CH updates such parameters based on the operator policies.
The UDM Update Data that the UDM delivers to the UE may contain:
  • one or more UE parameters including:
    • the updated Default Configured NSSAI (final consumer of the parameter is the ME);
    • the updated Routing Indicator Data (final consumer of the parameter is the USIM when the related credential is stored in the USIM, i.e. for PLMN or SNPN credentials; or final consumer of the parameter is the ME when the related credential is stored in the ME, i.e. for SNPN credentials);
    • indication of whether disaster roaming is enabled in the UE if UE MINT support indicator is received or UE is registered for Disaster Roaming service currently; and
    • indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN' if UE MINT support indicator is received or UE is registered for Disaster Roaming service currently.
  • a "UE acknowledgement requested" indication.
  • a "re-registration requested" indication.
Up

4.20.2  UE Parameters Update via UDM Control Plane Procedure  p. 464

Reproduction of 3GPP TS 23.502, Fig. 4.20.2-1: UE Parameters Update via UDM Control Plane Procedure
Figure 4.20.2-1: UE Parameters Update via UDM Control Plane Procedure
Up
Step 1.
UDM decides to perform UE parameter update.
Step 2.
From UDM to the AMF: The UDM notifies the changes of the information related to the UE to the affected AMF by the means of invoking Nudm_SDM_Notification service operation. The Nudm_SDM_Notification service operation contains the UDM Update Data that needs to be delivered transparently to the UE over NAS within the Access and Mobility Subscription data. The UDM Update Data includes:
  • The updated parameters to be delivered to the UE (see clause 4.20.1 for parameters possible to deliver).
  • whether the UE needs to send an ack to the UDM.
  • whether the UE needs to re-register after updating the data.
If the UE parameter update is performed due to "Routing Indicator update data" and the updated Routing Indicator value is not supported by the UDM where the AMF is currently registered, the UDM shall request the UE to re-register after updating the data.
Step 3.
From AMF to UDM: If AMF determines that the UE is not reachable, then AMF invokes the Nudm_SDM_Info service operation to UDM indicating that the transmission of UE Parameters Update data is not successful. The UDM considers the procedure as UE Parameters Update procedure as pending and subsequent steps from 4-7 are skipped.
Step 4.
From AMF to the UE: the AMF sends a DL NAS TRANSPORT message to the served UE. The AMF includes in the DL NAS TRANSPORT message the transparent container received from the UDM.
The UE verifies based on mechanisms defined in TS 33.501 that the UDM Update Data is provided by HPLMN, SNPN, or CH; and:
  • If the security check on the UDM Update Data is successful, as defined in TS 33.501 the UE either stores the information and uses those parameters from that point onwards, or forwards the information to the USIM; and
  • If the security check on the UDM Update Data fails, the UE discards the contents of the UDM Update Data.
Step 5.
The UE to the AMF: If the UE has verified that the UDM Update Data is provided by HPLMN, SNPN, or CH and the UDM has requested the UE to send an ack to the UDM, the UE sends an UL NAS TRANSPORT message to the serving AMF with a transparent container including the UE acknowledgement.
Step 6.
The AMF to the UDM: If the AMF receives an UL NAS TRANSPORT message with a transparent container carrying a UE acknowledgement from the UE, the AMF sends a Nudm_SDM_Info request message including the transparent container to the UDM.
Step 6a.
If the UE parameter update is performed due to "Routing Indicator update data", the updated Routing Indicator value is also supported by the UDM where the AMF is currently registered and the UDM requests the UE to send an ack but does not request the UE to re-register, then upon reception of the transparent container indicating the acknowledgement of successful reception, the UDM shall trigger a Nudm_SDM_Notification service operation to update the UE Context in the AMF with the updated Routing Indicator Data (e.g. to avoid transmitting an outdated Routing Indicator on UE context transfer to another AMF).
The UDM shall also notify other NFs registered in UDM (i.e. SMF and SMSF) about the update of the Routing Indicator value assigned to the SUPI using the Nudm_SDM_Notification service operation.
Step 7.
If the UDM has requested the UE to re-register, the UE waits until it goes back to RRC idle and initiates a Registration procedure as defined in TS 24.501.
Up

4.20.3  Void

4.21  Secondary RAT Usage Data Reporting Procedure  p. 465

The procedure in Figure 4.21-1 may be used to report Secondary RAT Usage Data from NG-RAN node to the AMF. It is executed by the NG-RAN node to report the Secondary RAT Usage Data information towards AMF which is then reported towards SMF.
The procedure in Figure 4.21-2 may be used to report the Secondary RAT Usage Data from AMF towards the SMF. Optionally, it is used to report the Secondary RAT Usage Data from V-SMF to the H-SMF when the reporting to H-SMF is activated.
Reproduction of 3GPP TS 23.502, Fig. 4.21-1: RAN Secondary RAT Usage Data Reporting procedure
Figure 4.21-1: RAN Secondary RAT Usage Data Reporting procedure
Up
Step 1.
The NG-RAN, if it supports Dual Connectivity with Secondary RAT (using NR radio, E-UTRA radio, or unlicensed spectrum using NR or E-UTRA radio) and it is configured to report Secondary RAT Usage Data for the UE, depending on certain conditions documented in this specification, it shall send a RAN Usage Data Report message to the AMF including the Secondary RAT Usage Data for the UE. The NG-RAN node will send only one RAN Usage Report for a UE when the UE is subject to handover by RAN. The RAN Usage Data Report includes a Handover Flag to indicate when the message is sent triggered by a handover.
Reproduction of 3GPP TS 23.502, Fig. 4.21-2: SMF Secondary RAT Usage Data Reporting procedure
Figure 4.21-2: SMF Secondary RAT Usage Data Reporting procedure
Up
The NG-RAN, if it supports Dual Connectivity with Secondary RAT (using NR radio, E-UTRA radio, or unlicensed spectrum using NR or E-UTRA radio) and it is configured to report Secondary RAT usage data for the UE, it shall include the Secondary RAT usage data for the UE to the AMF in certain messages depending on certain conditions documented elsewhere in this TS.
Step 1.
The AMF forwards the N2 SM Information (Secondary RAT Usage Data) to the SMF in a Nsmf_PDUSession_UpdateSMContext Request.
Step 2.
The V-SMF sends the Nsmf_PDUSession_Update (Secondary RAT Usage Data) message to the H-SMF.
Step 3.
The H-SMF acknowledges receiving the Secondary RAT Usage data for the UE.
Step 4.
The V-SMF acknowledges receiving the Secondary RAT Usage data back to the AMF.
Up

4.22  ATSSS Procedures |R16|  p. 466

4.22.1  General  p. 466

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. 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.
A MA-PDU Session with one 3GPP access connected to 5GC and one non-3GPP access connected to EPC is not supported in this release.
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 Establishment  p. 467

4.22.2.0  Overview |R17|  p. 467

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

4.22.2.1  Non-roaming and Roaming with Local Breakout  p. 467

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 indicate to the network that this PDU Session Establishment Request is to establish a new MA-PDU Session and to apply the ATSSS-LL functionality, or the MPTCP functionality, or both functionalities, for steering the traffic of this MA-PDU session.
    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.
  • In step 2, if the AMF supports MA-PDU sessions, then the AMF selects an SMF, which supports MA-PDU sessions. 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.
    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 is supported for the MA-PDU Session, the SMF may instruct the UPF to activate MPTCP 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 "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.
    • 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 "link-specific multipath" addresses/prefixes of the UE and the MPTCP 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 Roaming  p. 468

4.22.2.2.1  Home-routed Roaming - UE registered to the same PLMN  p. 468
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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
    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 PLMNs  p. 469
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.
  • In step 2, if the AMF supports MA-PDU sessions, then the AMF selects a V-SMF, which supports MA-PDU sessions.
  • 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).
  • 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 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.
    • In step 12, new UL N9 tunnel CN info is allocated by the H-SMF or by the H-UPF.
    • 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. 470

4.22.2.3.1  General  p. 470
This clause applies to the case where, for a PDU Session, multi-access connectivity via both EPC and 5GC 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 Sessions  p. 471
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, or the MPTCP functionality, or both).
  • 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 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.
    • 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.
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 access are not affected by such inter 3GPP access RAT change.
Up
4.22.2.3.3  QoS Support  p. 472
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.3  UE Requested PDU Session Establishment with Network Modification to MA PDU Session  p. 472

4.22.3.1  Overview  p. 472

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 to provide bandwidth aggregation for the requested PDU Session.

4.22.3.2  Non-roaming or roaming with local breakout  p. 473

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 access  p. 473

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 access  p. 474

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 Measurements  p. 475

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 Availability  p. 475

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 based on implementation. 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.

4.22.6  EPS Interworking  p. 475

4.22.6.1  General  p. 475

This clause includes procedures for interworking with EPS.

4.22.6.2  Impacts to EPS interworking procedures  p. 475

4.22.6.2.1  5GS to EPS handover using N26 interface  p. 475
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.
Up
4.22.6.2.2  5GS to EPS idle mode mobility using N26 interface  p. 476
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.
  • 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 allocation  p. 476
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 revocation  p. 476
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 interface  p. 477
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 EPC  p. 477

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
Figure 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 Resources  p. 478

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 Modification  p. 479

4.22.8.1  General  p. 479

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

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

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 procedures  p. 480

4.22.9.1  Registration procedures  p. 480

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 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 Request  p. 481

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 handover  p. 481

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 Request  p. 482

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

4.22.10  MA PDU Session Release  p. 482

4.22.10.1  General  p. 482

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

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

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