Section: 4.22.9.5 Registration procedures for non-3GPP access path switching
Content: 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: Figure 4.22.9.5-1: Mobility Registration procedure for non-3GPP access path switching 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. NOTE 1: The PDU Sessions that are not indicated in the List Of PDU Sessions To Be Activated by the UE are not released but deactivated during the switching procedure. The UE or network can re-activate user plane resources by triggering Service Request procedure after non-3GPP path switching is completed. 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. 2. This is the same as step 2 in Figure 4.2.2.2.2-1. 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. 4. This is the same as steps 4-16 in Figure 4.2.2.2.2-1. 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. NOTE 2: The resource in the old non-3GPP access, i.e. the old N3IWF or TNGF, will in this case be released by the AMF in step 12. - 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. 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. NOTE 3: In order to support RAT restrictions for non-3GPP access in the above procedure, it is assumed that UDM has provided restricted non-3GPP RAT types, if any, in the RAT restriction parameter in AM subscription data. In order to ensure that RAT restrictions are not violated in case the PDU Session is established in LBO roaming scenarios, the AMF in VPLMN may be configured to not indicate support for non-3GPP access path switching for inbound roaming UEs during MA PDU Session Establishment towards a SMF in VPLMN, unless it has been agreed in roaming agreements that non-3GPP access path switching can be supported for such UEs.