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 earer status in the Registration Request.
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 TS 23.501, clause 5.15.7
). 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 the clause 220.127.116.11.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 18.104.22.168.2
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.
In connected mode mobility, the AMF dervices S-NSSAIs values during the handover procedure.
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 22.214.171.124
(Tracking Area Update procedure with Serving GW change) in TS 23.401
is performed with the modification captured in clause 126.96.36.199.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 PGW-C+SMF 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 PGW-C+SMF, the AMF queries the NRF in serving PLMN by issuing the Nnrf_NFDiscovery_Request
including the FQDN for the S5/S8 interface of the PGW-C+SMF, and the NRF provides the IP address or FQDN of the N11/N16 interface of the PGW-C+SMF.
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 188.8.131.52.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 184.108.40.206.
The new AMF can determine if a PDU Session is used for emergency service by checking whether the DNN matches the emergency DNN.
[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 220.127.116.11.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 18.104.22.168.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 22.214.171.124.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 126.96.36.199.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). 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 the V-SMF change is needed, the AMF performs as the case of I-SMF change defined in clause 188.8.131.52
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, 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 PDUSession_Create service operation, the V-SMF request the V-UPF to provide the CN tunnel info. 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 PGW-C+SMF. 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 PGW-C+SMF. 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. The V-SMF updates NG RAN with the S-NSSAI value for the Serving PLMN via N2 SM message. If V-SMF relocation is needed, the AMF performs V-SMF relocation as defined in clause 184.108.40.206.
In non-roaming and LBO cases and idle state mobility, AMF invokes Nsmf_PDUSession_CreateSMContext
Request (UE EPS PDN Connection) service operation of the PGW-C+SMF 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 PGW-C+SMF address/ID in the UE context the AMF received in Step 6.
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, 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 PGW-C+SMF finds the corresponding PDU Session based on the PDN Connection Context in the request. The PGW-C+SMF initiates N4 Session modification procedure to establish the CN tunnel for the PDU Session, and for Idle state mobility registration, releases the resource of the CN tunnels for EPS bearers corresponding to the PDU session as well. If the PGW-C+SMF has not yet registered for this PDU Session ID, the PGW-C+SMF 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 PGW-C+SMF. The PGW-C+SMF 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 PGW-C+SMF for this UE, an EPS bearer status, which reflects all existing EPS bearer, is generated by the AMF.
For Connected State mobility registration, the release of CN tunnels for EPS bearers and UDM registration for the session corresponding to the PDU session is performed in the handover execution phase.
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 non-IP PDN Type is originally established as Ethernet PDU Session, it means that Ethernet PDN Type is not supported in EPS.
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 PGW-C+SMFs. If the PGW-C+SMF receives the EPS Bearer Status from AMF, the PGW-C+SMF shall check whether the EPS bearer(s) has been deleted by UE but not notified to network. If yes, the PGW-C+SMF 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 reterives 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 reterived from the UDM.
Step 15 - 16a.
HSS+UDM cancels the location of the UE in the MME as defined in steps 13 - 14 from clause 220.127.116.11
(Tracking Area Update procedure with Serving GW change) in TS 23.401
. Subsequently, the steps 18 - 19 from clause 18.104.22.168
(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 22.214.171.124.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.