A Registration Request has already reached an AMF, so why would the serving AMF still need to change while registration is in progress? Does this mean the gNB selected the wrong AMF? If the UE does not include a Requested NSSAI in the Registration Request, at what point can the network determine which network slice the UE actually needs? These questions point to a special branch of 5GC Initial Registration: AMF re-allocation. In engineering discussions this is often described as "AMF reselection," while in the 3GPP procedure it is more accurately treated as a re-allocation of the AMF during registration.
The key difference between AMF re-allocation and a normal Initial Registration is not an additional authentication procedure or a load-balancing-driven AMF change. Instead, the Initial AMF obtains more complete subscription and slice information, determines that it cannot serve the S-NSSAI ultimately required by the UE, invokes the NSSF to identify an appropriate AMF service scope, and then transfers the registration procedure to a Target AMF.
The most useful way to understand this signaling flow is not to memorize the step number at which the AMF changes. Instead, follow three successive decision points: what information the gNB has when it makes the first AMF selection, what additional information the Initial AMF learns during registration, and what criteria the NSSF ultimately uses to steer the UE toward a new serving AMF.
When Is AMF Re-allocation Triggered?
Initial Registration with AMF re-allocation is not the default path for every 5GC registration. Its trigger conditions are specific: Network Slicing is deployed, and the AMF that initially receives the Registration Request cannot serve the network slice ultimately required by the UE.
In a normal registration scenario, the Initial AMF selected by the gNB already supports the required S-NSSAI. Identity handling, authentication, subscription-data retrieval and Registration Accept can therefore remain on the same AMF throughout the procedure.
Re-allocation becomes necessary only when information obtained later in the procedure shows that the current AMF does not match the slice the UE is allowed to use or is expected to use by default. The logic can be summarized as:
Registration Request reaches the Initial AMF
→ Initial AMF performs the required registration processing
→ Complete UE subscription and slice information is obtained
→ Initial AMF determines that it cannot serve the target S-NSSAI
→ NSSF is invoked to determine the appropriate service scope
→ Registration is transferred to the Target AMF
One common misunderstanding should be avoided: the appearance of two AMFs in the same registration trace does not automatically mean that the original AMF failed or that AMF Pool load balancing occurred. In this procedure, the actual trigger is a mismatch between the current AMF's Slice Serving Capability and the network slice ultimately required by the UE.
Why Can the gNB Initially Select an Unsuitable AMF?
When first examining AMF re-allocation, it is easy to assume that the gNB made a mistake. If different AMFs serve different slices, why does the RAN not send the UE directly to the correct AMF from the beginning?
The main reason is that the gNB may not have enough information when it performs the initial AMF selection. Consider a connected vehicle powering on for the first time with a 5G USIM subscribed to two network slices:
eMBB slice (S-NSSAI1): used for in-vehicle infotainment and general data services;
V2X slice (S-NSSAI3): used for vehicle-to-everything and automated-driving-related services.
Assume the subscriber's Default S-NSSAI is the V2X slice, but the UE is entering the 5GS for the first time, has no valid 5G-GUTI, and does not include a Requested NSSAI in the Registration Request. At this point, the gNB has no direct basis for knowing that the UE should ultimately be served by the AMF associated with the V2X slice.
Under normal conditions, the gNB can use information such as the GUAMI, the S-NSSAI requested by the UE and its local AMF configuration when selecting an AMF. In this scenario, however, both the GUAMI and Requested NSSAI are unavailable, so the gNB can only select an Initial AMF using the information it currently has and its local default selection policy.
If the gNB initially selects AMF1, which serves the eMBB slice, the Registration Request is carried to AMF1 in an NGAP Initial UE Message.
The fact that this AMF does not match the UE's final slice requirement does not necessarily indicate a gNB configuration error. A more accurate interpretation is: when the first AMF selection occurs, the RAN does not yet have enough information to determine the UE's final Slice-specific AMF.
How Does the Initial AMF Detect the Slice Mismatch?
When the Registration Request reaches the Initial AMF, the AMF does not immediately query the NSSF. At this point it still lacks enough subscriber information to determine whether it is the correct final serving AMF.
The AMF first follows the normal Initial Registration logic and performs the required procedures, including UE identity handling, AUSF selection, 5G-AKA Authentication and the related NAS security procedures.
A key result of this stage is that the AMF confirms the UE identity and obtains the SUPI. With the SUPI available, the Initial AMF can locate the appropriate UDM and retrieve the UE's Access and Mobility Subscription Data.
At this stage, the network has substantially more information than it had when the Registration Request first arrived. The subscription data returned by the UDM can include the subscriber's Subscribed NSSAI and Default S-NSSAI.
Continuing the connected-vehicle example, the Initial AMF belongs to the eMBB service domain, but the subscription data shows that the UE is subscribed to both eMBB and V2X, with the Default S-NSSAI pointing to V2X, or S-NSSAI3.
The Initial AMF can now reach a conclusion that the gNB could not make earlier: although it was able to receive and begin processing the Initial Registration, it is not the appropriate AMF to provide ongoing service for the UE's default V2X slice. This determination becomes the trigger point for AMF re-allocation.
gNB stage: only limited access information is available
→ Initial AMF stage: UE identity is confirmed
→ UDM stage: actual subscribed NSSAI information is obtained
→ Current AMF is found to be incompatible with the target slice
AMF re-allocation is therefore not an arbitrary change of decision halfway through registration. It occurs because the core network can make a more accurate serving-AMF decision once the subscriber identity and slice information become complete.
How Does the NSSF Identify the New Serving AMF?
Once the Initial AMF determines that it cannot serve the target slice, it does not simply choose another AMF on its own. Instead, it invokes the Network Slice Selection Function, or NSSF.
The Initial AMF uses the Nnssf_NSSelection service to request Network Slice Selection. Inputs can include the UE's subscribed S-NSSAI, information about the current AMF and the UE's current TAI. The purpose is to determine which slices are authorized in the current registration area and which AMF set should provide service.
The Authorized Network Slice Information returned by the NSSF may include:
Allowed NSSAI: the network slices the UE is authorized to use under the current conditions;
Configured NSSAI: slice configuration that may be provided to the UE when required;
Target AMF Set: the set of AMFs capable of serving the relevant network slice;
Rejected NSSAI: slices that cannot be accepted under the current TA or related conditions.
It is important to distinguish between a Target AMF Set and a Target AMF. The NSSF's first responsibility is to determine which AMF set is appropriate, narrowing the candidate scope according to slice and location conditions rather than simply returning the address of one specific AMF.
After obtaining the Target AMF Set, the Initial AMF can use NF instance information registered in the NRF to retrieve the addresses, capabilities, weights and operational status of AMFs within that set. It can then determine which specific Target AMF should take over the Registration.
The relationship can be summarized as:
UDM: provides the UE's slice subscription information
→ Initial AMF: determines that its own serving capability does not match
→ NSSF: determines the authorized slices and Target AMF Set
→ NRF: provides available AMF instance information within the set
→ Initial AMF: selects the Target AMF
The role of the NSSF in this procedure is not conventional load balancing. It maps a Slice Requirement to an AMF service scope capable of supporting that requirement.
How Is the Registration Request Transferred to the Target AMF?
After the Target AMF has been determined, the UE does not need to send a completely new Registration Request. The network only needs to transfer the registration procedure already in progress, together with the required context, so that the new AMF can continue processing it.
Two forwarding mechanisms are available: indirect forwarding through the gNB, or direct forwarding between the Initial AMF and Target AMF.
Indirect Forwarding Through the gNB
With indirect forwarding, the Initial AMF sends an NGAP Reroute NAS Request to the gNB. The message carries information associated with the original Initial UE Message as well as the Target AMF Set ID, instructing the NG-RAN to reroute the current NAS Registration message.
The gNB then sends a new Initial UE Message to the Target AMF containing the original Registration Request NAS-PDU. The control-plane path can be represented as:
UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF
The UE does not need to perform RRC access again. The NG-RAN simply reroutes the existing Registration NAS message to the appropriate AMF.
Direct Forwarding Between AMFs
With direct forwarding, the Initial AMF does not send the message back through the gNB. Instead, it transfers the N1 message and Registration Context directly to the Target AMF through the 5GC service-based interface.
The Initial AMF invokes Namf_Communication_N1MessageNotify and sends the complete Registration Request together with the Registration Context Container to the Target AMF.
The transferred information is not limited to a single NAS message. The Registration Context can also include UE Context, Access Type, gNB information, User Location, Allowed NSSAI, Configured NSSAI, Rejected NSSAI and other information needed to continue registration processing.
UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF
The signaling paths are different, but the objective is the same: the Target AMF receives the NAS message and context needed to continue Registration without restarting the entire Initial Registration procedure.
After taking over, the Target AMF completes the remaining registration processing and returns a Registration Accept to the UE. The response reflects the results of slice selection and AMF re-allocation and may include Allowed NSSAI, Configured NSSAI, Rejected NSSAI and a newly assigned 5G-GUTI.
From the UE's perspective, the important result is that registration succeeds and the network provides the slices available in the current area together with the new 5GS mobility context. The internal change of serving AMF remains transparent to the UE.
How Can You Verify AMF Re-allocation in a Signaling Trace?
Initial Registration with AMF re-allocation can easily be mistaken for abnormal registration routing or a failed first AMF selection. A more effective troubleshooting method is not to compare message numbers one by one, but to follow two main threads: slice determination and context transfer.
A normal signaling sequence should allow the engineer to answer the following questions:
Why did the Registration Request first reach this Initial AMF?
→ Where did the Initial AMF obtain the UE's Subscribed / Default NSSAI?
→ What caused the AMF to determine that it could not continue serving the UE?
→ Which Target AMF Set did the NSSF return?
→ Which specific Target AMF was ultimately selected?
→ Which path was used to transfer the Registration Context?
If the Initial AMF has already obtained the slice subscription information and determined that it cannot serve the UE, but no NSSF selection procedure follows, the investigation should focus on NSSF discovery, the Nnssf_NSSelection request and the related Slice configuration.
If the NSSF returns a Target AMF Set but no specific Target AMF can be identified, the next checks should include the AMF Set configuration, NF Profiles in the NRF, AMF instance status and capability information.
If an NGAP Reroute NAS Request is present but the Target AMF never receives the new Initial UE Message, the troubleshooting focus should shift from slice selection to NAS rerouting at the gNB and N2 reachability toward the Target AMF.
If direct forwarding is used, the trace should be checked for Namf_Communication_N1MessageNotify and the Registration Context rather than waiting for a Reroute NAS Request that will not appear in that path.
Looking at the full procedure, AMF re-allocation solves a specific problem: the information available during the first AMF selection is incomplete, and the core network later corrects the serving-AMF decision after obtaining complete subscriber identity and slice-subscription information.
When the UE first enters the network, the gNB may only have limited GUAMI information, Requested NSSAI information or its default AMF configuration. After authentication and subscription retrieval, the 5GC can finally determine which slices the subscriber is authorized to use. The NSSF then converts the Slice Requirement into a Target AMF Set, while the NRF helps identify the actual AMF instance that can continue the Registration.
The most useful question when analyzing this signaling flow is therefore not "Why did the AMF change halfway through registration?" but rather: At what point did the network finally obtain enough information to determine which AMF should continue serving the UE?
FAQ
Is AMF Re-allocation the Same as Load Balancing in an AMF Pool?
No. AMF Pool load balancing generally focuses on capacity, weighting and high-availability distribution among multiple AMF instances. In this procedure, AMF re-allocation is driven by the fact that the Initial AMF cannot serve the network slice ultimately required by the UE. Both mechanisms may result in a different serving AMF, but the trigger conditions and signaling logic are fundamentally different.
Does Every Network Slicing Deployment Require NSSF Selection and AMF Re-allocation?
No. Even when Network Slicing is deployed, AMF re-allocation is unnecessary if the AMF initially selected by the gNB can already serve the slice ultimately required by the UE. Re-allocation is a conditional branch of registration, not a mandatory step for every sliced network.
Can the UE Directly Detect That the AMF Changed During Registration?
From the UE's perspective, the main concern is whether Registration succeeds and which Allowed NSSAI, Configured NSSAI, Rejected NSSAI and 5G-GUTI values are returned by the network. AMF re-allocation and Registration Context transfer are internal 5GC control procedures and are largely transparent to the UE.
Is Indirect or Direct Forwarding Always More Common?
No universal conclusion can be drawn from the procedure definition alone. The mechanism used depends on the 5GC deployment architecture, vendor implementation, service-based communication capabilities between AMFs, and RAN and core-network configuration. Actual troubleshooting should follow the signaling path observed in the live network.
