The Registration procedure is triggered, e.g. the UE moves into NG-RAN coverage. Step 2 to 9 except step 5, 6 and 8 follow the Registration procedure in clause 4.2.2 with following enhancement.
The UE sends Registration Request with registration type set to "Mobility Registration Update".
The UE includes 5G-GUTI mapped from EPS GUTI as the old GUTI, the native 5G-GUTI (if available) as additional GUTI and indicating that the UE is moving from EPC. The UE includes the UE Policy Container containing the list of PSIs, indication of UE support for ANDSP and OSId if available.
When the Registration Request is triggered due to UE mobility from EPS to 5GS, if the UE has locally deleted the EPS bearer which has allocated 5GS parameters and the EPS bearer status has not been synchronized with the network, the UE shall include the EPS bearer status in the Registration Request. If the UE has not received mapped 5GS QoS parameters from the network for PDN connection(s), the UE locally releases those PDN connection(s).
The Additional GUTI is provided both in Idle state and Connected state, if available. The Additional 5G-GUTI enables the AMF to retrieve the UE's MM context from the old AMF (if available). The UE includes the S-NSSAIs associated with the established PDN connections in the Requested NSSAI in RRC and NAS (as described in clause 5.15.7 of TS 23.501). In the case of Configured NSSAI applicable to this PLMN or an Allowed NSSAI are not present in the UE, the associated HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS as described in clause 5.15.5.2.1 of TS 23.501.
In the case of idle mode mobility the UE additionally includes a TAU request message integrity protected using the EPS security context (for further security verification by the MME) in the Registration Request. If the UE holds a native 5G-GUTI for this PLMN then the UE also includes the GUAMI part of the native 5G-GUTI in RRC to enable the NG-RAN to route the Registration Request to the same AMF (if available) and otherwise the UE provides in RRC signalling a GUAMI mapped from the EPS GUTI and indicates it as "Mapped from EPS".
The UE integrity protects the Registration Request message using a 5G security context (if available).
Steps 2-3 of clause 4.2.2.2.2 are performed.
In the case of idle mode mobility, the AMF derives S-NSSAIs values for the Serving PLMN based on the S-NSSAIs values for the HPLMN, received in NAS Registration Request, associated with the established PDN connections, the AMF may send the S-NSSAIs values for the HPLMN to NSSF by invoking Nnssf_NSSelection_Get service operation and NSSF provides corresponding S-NSSAIs values for VPLMN to AMF.
Steps 5 and 8 are not performed when this procedure is part of EPS to 5GS handover.
[Conditional] This step is only performed for IDLE mode mobility. The AMF derives the MME address and 4G GUTI from the old 5G-GUTI and sends Context Request to MME including EPS GUTI mapped from 5G-GUTI and the TAU request message according to TS 23.401. The MME validates the TAU message.
[Conditional] If step 5a is performed, step 5 from clause 5.3.3.1 (Tracking Area Update procedure with Serving GW change) in TS 23.401 is performed with the modification captured in clause 4.11.1.5.3.
The AMF converts the received EPS MM Context into the 5GS MM Context. The received EPS UE context includes IMSI, ME Identity, UE EPS security context, UE Network Capability and EPS Bearer context(s) and may also include LTE-M Indication. The MME EPS Bearer context includes for each EPS PDN connection the IP address and FQDN for the S5/S8 interface of the SMF+PGW-C and APN. If the SCEF connection is invoked, the MME EPS Bearer context includes the SCEF+NEF ID of the PDN connection, EBI, APN, User Identity. The AMF disregards any LTE-M Indication received in the EPS UE context and instead takes into account the LTE M Indication received from NG-RAN, at step 1.
The AMF can determine the whether the UE is performing Inter-RAT mobility to or from NB-IoT based on the received "TAI of last TAU" in the EPC MM Context and the RAT Type used for the Registration Request.
If the Context Response includes the FQDN for the S5/S8 interface of the SMF+PGW-C, the AMF queries the NRF in serving PLMN by issuing the Nnrf_NFDiscovery_Request including the FQDN for the S5/S8 interface of the SMF+PGW-C and the NRF provides the IP address or FQDN of the N11/N16 interface of the SMF+PGW-C.
If the Context Response includes an SCEF+NEF ID, the AMF performs the SMF selection.
The Context Response may include new information Return Preferred. Return Preferred is an indication by the MME of a preferred return of the UE to the last used EPS PLMN at a later access change to an EPS shared network. Based on the Return Preferred indication, the AMF may store the last used EPS PLMN ID in UE Context.
If the AMF cannot retrieve the address of the corresponding SMF for a PDN connection, it will not move the PDN connection to 5GS.
Step 6 is performed only if the AMF is different from the old AMF and the old AMF is in the same PLMN as the AMF.
[Conditional] If the UE includes the 5G-GUTI as Additional GUTI in the Registration Request message, the AMF sends message to the old AMF. The old AMF validates the Registration request message.
The AMF retrieves UE's SUPI and MM Context, event subscription information by each consumer NF and the list of SM PDU Session ID/associated SMF ID for the UE using one of the following three options:
AMF may invoke the Namf_Communication_UEContextTransfer to the old AMF identified by the additional 5G-GUTI; or
if the old AMF and the AMF are in the same AMF Set and UDSF is deployed, AMF may invoke Nudsf_UnstructuredDataManagement_Query service operation for the UE identified by the additional 5G-GUTI from the UDSF; or
if the old AMF and the AMF are in the same AMF Set, AMF may use implementation specific means to share UE context.
[Conditional] If step 6a is performed, the response is performed as described in step 5 in clause 4.2.2.2.2. If a native 5G security context for 3GPP access is available in the AMF (or has been retrieved in step 6a), the AMF may continue to use this security context. Otherwise, the AMF shall either derive a mapped security context from the EPS security context obtained from the MME or initiate an authentication procedure to the UE.
If the new AMF determines that the UE has emergency PDU Session and the AMF is configured to allow emergency services for unauthenticated UE, the new AMF behaves as follows:
If the UE has only an emergency PDU Session, the AMF either skips the authentication and security procedure in step 7 or accepts that the authentication may fail and continues the Mobility Registration Update procedure; or
If the UE has both emergency and non emergency PDU Sessions and authentication fails, the AMF continues the Mobility Registration Update procedure and deactivates all the non-emergency PDU Sessions as specified in clause 4.3.4.2.
[Conditional] If the AMF determines to initiate the authentication procedure to the UE in step 6b (e.g. the AMF can not obtain the UE MM context from AMF or other reasons), steps 8-9 of clause 4.2.2.2.2 are optionally performed.
In the case of idle mode mobility, the AMF decide whether a new AMF needs to be selected. If a new AMF is to be selected, the AMF reroute the Registration request to the new AMF as described in clause 4.11.1.3.4, where the initial AMF refers to the AMF.
[Conditional] If step 5b is performed and the AMF accepts to serve the UE, the AMF sends Context Acknowledge (Serving GW change indication) to MME according to TS 23.401.
Steps 13-14e of clause 4.2.2.2.2 are performed: This includes that if an MM context is retrieved from the old AMF in step 6 (i.e. corresponding to an existing UE registration for non-3GPP access in 5GC), then the AMF indicates to the UDM that the AMF identity to be registered in the UDM applies to both 3GPP and non-3GPP accesses by sending separate/independent Nudm_UECM_Registration service operations for "3GPP Access" and "non-3GPP Access".
Step 16 of clause 4.2.2.2.2 (AM Policy Association Establishment) is optionally performed.
In the home-routed roaming case and connected state mobility, based on the S-NSSAI value for the Serving PLMN of the PDU Session(s), the AMF decides whether V-SMF change is needed or not.
If the V-SMF reallocation is not needed and if the two values (i.e. the S-NSSAI value configured in AMF for interworking and S-NSSAI value for the Serving PLMN) are different, the AMF invokes Nsmf_PDUSession_UpdateSMContext (PDU Session ID, S-NSSAI value for the Serving PLMN).
If V-UPF is not changed, the V-SMF updates 5G AN with the new S-NSSAI of VPLMN by sending a N2 SM message to 5G AN via AMF.
If V-UPF is changed, the V-SMF performs procedure as specified in clause 4.23.4.2 with the difference that I-SMF/I-UPF in clause 4.23.4.2 is replaced by V-SMF/V-UPF and with the following modification:
In step 11 of clause 4.2.3.2 referenced by clause 4.23.4.2, the V-SMF includes in N2 SM information with the new S-NSSAI of the VPLMN.
If the V-SMF change is needed, the AMF performs as the case of I-SMF change defined in clause 4.23.4.3 with the difference that I-SMF in clause 4.23.4.3 is replaced by V-SMF and with following modifications:
In step 3 of clause 4.23.4.3, the AMF sends indication of no NG-RAN change to the new V-SMF.
In step 4a of clause 4.23.4.3, when the new V-SMF retrieves SM context from the old V-SMF, the new V-SMF sends indication of no NG-RAN change as it is received in step 3.
In step 4b of clause 4.23.4.3, as the old V-SMF receives the indication of no NG-RAN change, the old V-SMF returns additional N3 tunnel information of NG-RAN.
In step 6 of clause 4.23.4.3, the new I-SMF should reuse the N3 tunnel information of NG-RAN received from old I-SMF/SMF.
In step 9 of clause 4.23.4.3, when the new V-SMF sends a Nsmf_PDUSession_CreateSMContext Response, the new V-SMF includes PDU Session Resource Modify in N2 SM information.
In the home-routed roaming case and idle state mobility, the AMF selects a default V-SMF per PDU Session and invokes Nsmf_PDUSession_CreateSMContext service operation of the V-SMF to create an association with the AMF. It includes UE EPS PDN Connection, MSISDN as a GPSI if received from MME, H-SMF ID, S-NSSAI and indicates all the PDU Session(s) to be re-activated as received in the Registration request message along with List Of PDU Sessions To Be Activated. The S-NSSAI is the S-NSSAI configured in AMF for interworking, which is associated with default V-SMF. The V-SMF creates the association and based on the received SMF ID, the V-SMF invokes Nsmf_PDUSession_Create request service operation of the H-SMF and provides the information received from the AMF. Before invoking Nsmf_PDUSession_Create service operation, the V-SMF request the V-UPF to provide the CN tunnel info.
In the home-routed roaming case and idle state mobility, the V-SMF provides the QoS constraints of the VPLMN to the H-SMF.
The subsequent handling is performed as follows:
The H-SMF finds the corresponding PDU Session based on the PDN Connection Context in the request. The H-SMF initiates N4 Session modification procedure to establish the CN tunnel for the PDU Session. The tunnel info for PDU Session is allocated by PGW-U+UPF and provided to the SMF+PGW-C. The H-SMF responds V-SMF with the PDU Session ID corresponding to the PDN Connection Context in the request, the allocated EBI(s) information, the S-NSSAI of the PDU Session, S-NSSAI of HPLMN, UE EPS PDN connection(s) and other PDU session parameters, such as PDU Session Type, Session AMBR in the Nsmf_PDUSession_Create response.
The V-SMF updates its SM contexts and returns a Nsmf_PDU_Session_CreateSMContextResponse message including the information received from the H-SMF. The V-SMF updates the V-UPF of the CN tunnel info of SMF+PGW-C. The V-SMF also includes the N2 SM Context in the response message sent to the AMF if the corresponding PDU Session is in the received List Of PDU Sessions To Be Activated. The V-SMF stores an association of the PDU Session ID and the H-SMF ID. The AMF stores the V-SMF ID and it also stores S-NSSAI and the allocated EBI(s) associated to the PDU Session ID. Based on the S-NSSAI value for the Serving PLMN of the PDU Session(s) the AMF decides whether V-SMF relocation is needed or not.
If V-SMF relocation is not needed and if the two values (i.e. the S-NSSAI value configured in AMF for interworking and S-NSSAI value for the Serving PLMN) are different, the AMF sends the S-NSSAI value for the Serving PLMN to V-SMF by invoking Nsmf_PDUSession_UpdateSMContext service operation. If V-UPF change is not needed, the V-SMF updates NG RAN with the S-NSSAI value for the Serving PLMN via N2 SM message. If V-UPF change is needed, the V-SMF performs procedure as specified in clause 4.23.4.2 with the difference that I-SMF/I-UPF is replaced with V-SMF/V-UPF and with the following modification:
In step 11 of clause 4.2.3.2 referenced by clause 4.23.4.2, the V-SMF includes in N2 SM information with the new S-NSSAI of the VPLMN.
If V-SMF relocation is needed, the AMF performs V-SMF relocation as defined in clause 4.23.4.3.
In the case of home-routed roaming scenario, the V-SMF may apply VPLMN policies as described in clause 5.17.1.3 of TS 23.501.
In non-roaming and LBO cases and idle state mobility, AMF invokes Nsmf_PDUSession_CreateSMContext Request (UE EPS PDN Connection) service operation of the SMF+PGW-C and indicates all the PDU Session(s) to be re-activated as received in the Registration request message along with List Of PDU Sessions To Be Activated. This step is performed for each PDN Connection and the corresponding SMF+PGW-C address/ID in the UE context the AMF received in Step 6.
The SMF+PGW-C finds the corresponding PDU Session based on the PDN Connection Context in the request.
If the P-GW-C+SMF (H-SMF in the case of home-routed roaming case) determines that seamless session continuity from EPS to 5GS is not supported for the PDU Session, (e.g. if PDU Session ID was not received by the SMF+PGW-C for the PDN connection or PDU Session ID was received but mapped 5GS parameters were not provided to the UE due to 5GS interworking not supported), then it does not provide SM information for the corresponding PDU Session but includes the appropriate cause code for rejecting the PDU Session transfer within the N2 SM Information. The PDN connection(s) not further transferred to 5GC are locally released at the SMF+PGW-C.
Otherwise, if session continuity from EPS to 5GS is supported for the PDU Session, the SMF+PGW-C finds the corresponding PDU Session based on the PDN Connection Context in the request. The SMF+PGW-C initiates N4 Session modification procedure to establish the CN tunnel for the PDU Session. If the SMF+PGW-C has not yet registered for this PDU Session ID, the SMF+PGW-C registers with the UDM using Nudm_UECM_Registration (SUPI, DNN, PDU Session ID) for a given PDU Session as in step 4 of PDU Session Establishment Procedure in clause 4.3.2. The tunnel info for PDU Session is allocated by PGW-U+UPF and provided to the SMF+PGW-C. The SMF+PGW-C updates its SM contexts and returns the AMF a Nsmf_PDUSession_CreateSMContext Response message including the PDU Session ID corresponding to the PDN Connection Context in the request, the allocated EBI(s) information, the S-NSSAI of the PDU Session and the N2 SM Context if the corresponding PDU Session is in the received List Of PDU Sessions To Be Activated. The AMF stores an association of the PDU Session ID and the SMF ID, S-NSSAI and the allocated EBI(s) associated to the PDU Session ID. Based on the allocated EBI(s) information received from all the related SMF+PGW-C for this UE, an EPS bearer status, which reflects all existing EPS bearer, is generated by the AMF.
If the PDN Type of a PDN Connection in EPS is non-IP and it was originally established as Ethernet PDU Session when UE was camping in 5GS (known based on local context information that was set to PDU Session Type Ethernet in UE and SMF), the PDU Session Type in 5GS shall be set to Ethernet by the SMF and UE. If the PDN type of a PDN Connection in EPS is non-IP and is locally associated in UE and SMF to PDU Session Type Unstructured, the PDU Session Type in 5GS shall be set to Unstructured by the SMF and UE.
If the AMF has received the EPS Bearer Status in the Registration Request from UE, the AMF shall send the EPS Bearer Status to all corresponding SMF+PGW-Cs. If the SMF+PGW-C receives the EPS Bearer Status from AMF, the SMF+PGW-C shall check whether the EPS bearer(s) has been deleted by UE but not notified to network. If yes, the SMF+PGW-C shall release those EPS bearer(s), the corresponding 5G QoS Rule(s) and the QoS Flow level QoS parameters locally.
If the SCEF+NEF ID is provided to the SMF, the SMF establishes the SMF-NEF connection as described in steps 2-3 from clause 4.25.2, the SMF provides the SCEF+NEF ID, EBI, APN, User Identity to the SCEF+NEF and the SCEF+NEF updates the SM contexts and returns the NEF ID, PDU Session ID, DNN and User Identity to the SMF.
If the UE is performing Inter-RAT mobility to or from NB-IoT, the (H-)SMF will maintain, reconnect, release or leave PDU Session handling to the local VPLMN policy in the case of roaming for each PDU session according to the "PDU Session continuity at inter RAT mobility" subscription information. If the (H-)SMF does not have "PDU Session continuity at inter RAT mobility" for a PDU session, the (H-)SMF retrieves it from the UDM before determining any action. The SMF may use local policy to determine the handling a PDU Session if "PDU Session continuity at inter RAT mobility" cannot be retrieved from the UDM.
After the step 14a, the SMF+PGW-C receives the SM context create request from AMF and the SMF+PGW-C awares that the UE returns back from EPS. When the SMF+PGW-C notifies the PCF for the PDU session of changing RAT from EPS to 5GS, the PCF for the PDU session checks if there exists a UE policy association in EPS for the UE and in that case, request the termination of such UE Policy Association to the PCF for the UE.
HSS+UDM cancels the location of the UE in the MME as defined in steps 13 - 14 from clause 5.3.3.1 (Tracking Area Update procedure with Serving GW change) in TS 23.401. Subsequently, the steps 18 - 19 from clause 5.3.3.1 (Tracking Area Update procedure with Serving GW change) in TS 23.401 are also executed with the following modification:
According to configuration, for the PDN connections which are anchored in a standalone PGW, the MME initiates PDN connection release procedure as specified in TS 23.401.
These steps follow the steps 21, 21b and 22 of Registration procedure in clause 4.2.2.2.2.
The Registration Accept message shall include the updated 5G-GUTI to be used by the UE in that PLMN over any access. If the active flag was included in the Registration request, The AMF may provide NG-RAN with a Mobility Restriction List taking into account the last used EPS PLMN ID and the Return preferred indication. The Mobility Restriction List contains a list of PLMN IDs as specified by TS 23.501. The Allowed NSSAI in the Registration Accept message shall contain at least the S-NSSAIs corresponding to the active PDN Connection(s) and the corresponding mapping to the HPLMN S-NSSAIs.
The AMF shall include the EPS bearer status, which is generated at step 14, in the Registration Accept message. Based on the received EPS bearer status information, the UE shall check whether there are QoS Flow(s) existing locally but no associated EPS bearer(s) in the received EPS bearer status. The UE shall locally delete the 5G QoS Rule(s) and QoS Flow level QoS parameters of the QoS Flow(s) if the associated EPS bearer(s) do not exist in the received EPS bearer status.
For Control Plane CIoT EPS Optimisation, when the DL data is buffered in old MME and the DL Data Expiration Time has not expired, the old MME shall discard the buffered DL data (as specified in step of clause 5.3.3.1A in TS 23.401).
Steps 9-18 from clause 4.11.1.3.3 with following enhancements:
In step 14a of the Figure 4.11.1.3.3-1, the AMF forwards the Buffered DL Data Waiting indication from above to (V-)SMF in Nsmf_PDUSession_CreateSMContext service operation.
If the Buffered DL Data Waiting indication is provided by AMF, the (V-)SMF and (V-)UPF shall allocate the user plane resource and include the N2 SM information (i.e. the V-CN Tunnel-Info) in the Nsmf_PDUSession_CreateSMContext Response towards the AMF in step 14d of the Figure 4.11.1.3.3-1 to trigger the user plane setup in NG-RAN.
AMF to NG-RAN: N2 message (N2 MM information, N2 SM information list).
If N2 SM information is received from SMF in step 2 above, the AMF sends a N2 request message to setup the user plane resource.
NG-RAN performs RRC connection Reconfiguration with the UE to setup the user plane resource and response to AMF with N2 response message with N2 SM information.
Steps 11-13 from clause 4.11.1.2.2.2 with the following enhancement:
Based on Buffered DL Data Waiting indication received in step 2 above, the (V-)SMF and (V-)UPF allocate data forwarding tunnel resource and provide the CN tunnel information for data forwarding from EPS (i.e. Forwarding F TEID) in Nsmf_PDUSession_UpdateSMContext Response to AMF in step 13 of Figure 4.11.1.2.2.2-1. The (V-) SMF also starts a timer for release of resources for data forwarding.
The (V-) SMF may select a different UPF from the serving (V-)UPF for data forwarding.
The (V-)SMF shall not provide Charging Enforcement Rules and QoS Enforcement Rules to the (V-)UPF for DL packets that were received via the forwarding tunnel.
Steps 14-18 from clause 5.3.3.1A in TS 23.401 with following changes.
The AMF sends the Context Acknowledge message to MME as in step 14 of Figure 5.3.3.1A-1 in TS 23.401, including the CN tunnel information (i.e. Forwarding F TEID) for data forwarding from EPS received from (V-)SMF in step 4 above.
The Serving GW forwards the buffered DL data to the (V-)UPF based on the Forwarding F-TEID received from MME. The data received by the (V-)UPF on the forwarding F-TEID is forwarded by the (V-)UPF on the (newly) established N3 tunnel to the NG-RAN.
SMF to UPF: N4 Session Termination/Modification.
At the expiration of the timer started in step 4 above, the (V-) SMF starts the release of resource established in step 4 for data forwarding and informs the (V-)UPF.
During Idle state mobility registration procedure from EPS to 5GS, the initial AMF may select a new AMF based on S-NSSAIs associated with the established PDU Session, received in NAS Registration Request.
Step 3 to 4 of clause 4.2.2.2.3 in Registration with AMF reallocation procedure is performed with the difference that before the Network Slice selection the AMF needs to derive the S-NSSAI for the serving PLMN as described in clause 5.15.5.2.1 of TS 23.501.
[Conditional] Initial AMF to MME: Context Acknowledge (failure cause) to MME according to TS 23.401.
The initial AMF decides a new AMF needs to be reselected. The initial AMF sends a Context Acknowledge message with cause code indicating that the procedure is not successful. The MME shall continue as if Context Request was never received.
After receiving the Registration Request message, the new AMF continues the registration from step 5 until step 18 of Figure 4.11.1.3.3-1 (EPS to 5GS mobility using N26 procedure), which includes the UE context retrieved from old AMF. If the 5G security context is received from the initial AMF, the new AMF continues using that one instead of the mapped 5G security context retrieved from MME.