When a 5G device is first turned ON, it needs to register itself with the network before accessing the 5G services. This process is known as registration. But power on is not only the situation when this registration happens. It can be defined in four categories as
i) Initial Procedure
ii) Periodic Procedure
iii) Mobility Procedure
iv) Emergency Procedure
First, the power-ON procedure is known as the initial procedure. In addition, it also has periodic registration, this is to make sure that the device has not run out of battery or has been broken. So, the device was doing periodic registration if it is inactive somehow. Mobility registration, in which the device has to register itself if it is moving to a new location. Emergency registration is a service registration situation where the device which is like to access the emergency services like emergency call needs to register itself.
Registration Procedure Call Flows
The first step in the registration procedure is the registration request. For example, when the device is turned ON, the device sends a registration request to RAN. Now the RAN has to forward that to the core network to the appropriate AMF. But how would RAN know what is the appropriate AMF? Here there are two possibilities.
In the first scenario, if the device has already been communicating with the 5G network, it will have an identity assigned (GUTI). There is a temporary identifier as an indication of exactly which AMF the device has previously registered with. So using this to know which AMF, the device was previously communicating and through which RAN can forward the request to the corresponding AMF.
Second, if there is no previous identity available it means this is the first power-ON procedure. So the RAN looks at the registration request and the registration request as slice identifier (NSSAI). Then based on this slice identifier for this particular network slice they can see, which AMF supports the network slice and forward the registration request to this corresponding AMF.
Once that registration request is forwarded to AMF. We have context transfer as a step 2. Let us assume the registration request is because of mobility. So the device is moved to a new region and trying to do a registration update and as the result, it is trying to connect to the new AMF. But because this is the mobility triggered process, the device already has the UE context established with the old AMF. So in such a situation, in Step 2 where the AMF contact the old AMF for transferring the UE context and then the old AMF respond by communicating and transmitting the UE context to the new AMF.
Now step 3 is authentication, which is carried out using the 5G authentication and key agreement procedures. So the third step is related to authentication and security.
Step 4, previously no AMF has taken over the UEContext. In this step, the new AMF has confirmed with the old AMF that it has taken over the UE context. And that AMF is responsible for accessing and mobility from now.
In Step 5, the new AMF will register itself with the UDM, saying that I am the new AMF, so take care of my valid information. And then it speaks to the UDM to get the necessary subscription information and it will also subscribe for any further updates to the subscription information in the future. Because the new AMF controls the access and mobility, it needs to know what is the subscription status of the device that does the registration. On the other hand, when a new AMF is taking over, the old AMF has to retire. For this purpose, the UDM will notify the old AMF that needs to deregister. So the old AMF will now unsubscribe to any subscription data that it has previously subscribed to. So the transfer to the new AMF has been complete and the old AMF has successfully retired according to the UDM database.
In step 6, AMF needs to know the necessary policies related to access and mobility management. So it goes to PCF and fetches the necessary policy information corresponding to that particular device that is undergoing registration and the PCF provides the corresponding response.
In step 7, if there is already an existing PDU session, then the AMF speaks to the SMF to continue the PDU session using the update as some context message. On the other hand, if there is some kind of mismatch in the understanding of what the PDU session state is, then the previous PDU session is terminated using the release session management context message and then a new PDU session is created if necessary.
In step 8, if the registration procedure so far has gone good then the AMF will notify the device that the registration has been accepted and optionally, the device can send the confirmation saying that I have received the registration acceptance and registration complete message will be sent from the device to the AMF.
In step 9, the AMF will contact PCF for any device-specific policies. Since some policies help the device decisions. For example, the device might have to decide for a specific application if it has to create a new PDU session or not. If multiple Wi-Fi networks are supported, which one should be the device prioritised to use in support of the 5G network. This kind of policy can now be fetched from PCF.