A 5G UE can be operating normally, with radio coverage intact and even an active PDU Session, when the AMF suddenly sends it a network-initiated Deregistration Request. The UE has not powered off and has not sent a Deregistration Request of its own.
There is nothing contradictory about this behavior. A 5GC registration relationship does not have to be terminated by the UE. Operations and maintenance actions, prolonged UE unreachability, internal AMF state handling, or withdrawal of the subscriber's 5G subscription in the UDM can all cause the network to terminate an existing registration. When analyzing traces, the most important questions are not simply whether UPF resources were eventually deleted, but who made the deregistration decision first, whether the UE can still receive the notification, whether the network requires re-registration, and which signaling messages may legitimately never appear.
Who Can Decide That a Registered UE Should Leave the 5GS?
Network-initiated deregistration first requires a distinction between "initiating" and "triggering." The procedure is ultimately initiated and executed by the AMF, but the reason for doing so does not always originate inside the AMF.
One category begins at the AMF. An operator may explicitly deregister a user for maintenance, user migration or another network-management purpose, forcing a UE that is currently RM-REGISTERED to leave its existing registration. Another category is implicit deregistration. If the network can no longer confirm that the UE is reachable and the relevant timer conditions are met, the AMF can begin cleaning up the context without waiting for the UE to initiate anything.
A third path starts in the UDM. For example, if the operator withdraws the subscriber's 5G service subscription, the UDM knows that the subscription state has changed. The UDM does not send NAS signaling directly to the UE. Instead, it notifies the AMF currently serving that UE, and the AMF then turns that core-network decision into a network-initiated deregistration procedure.
From an NF relationship perspective, the main sources can therefore be summarized as:
AMF explicit initiation: operations and maintenance actions, user migration or other network-management purposes;
AMF implicit deregistration: deregistration timer or reachability conditions are met and the UE can no longer be considered normally registered;
UDM-triggered deregistration: for example, the user's subscription is withdrawn and the UDM instructs the AMF to deregister the UE.
Regardless of the original cause, the final objective is the same: the previous 5GS registration is no longer valid and the UE transitions from RM-REGISTERED to RM-DEREGISTERED.
Why Do Explicit and Implicit Deregistration Look So Different in a Trace?
Both procedures ultimately remove the UE from the registered state, but their signaling can look very different.
During explicit deregistration, the network can usually still communicate with the UE. The AMF can send a NAS Deregistration Request informing the UE that its current registration is being terminated. If the UE remains reachable, it can return a Deregistration Accept, after which the network continues releasing the remaining context and access-side signaling connection.
Implicit deregistration starts from a different condition. It normally occurs after the UE has failed to reappear or respond for long enough that the network can no longer confirm reachability. At that stage, sending another Deregistration Request may be pointless because the UE may already be powered off, outside coverage or otherwise disconnected.
As a result, implicit deregistration may appear simply as network-side context cleanup without a complete Deregistration Request → Deregistration Accept exchange.
This leads to a useful trace-analysis rule: the absence of a network-to-UE Deregistration Request does not prove that network-initiated deregistration did not occur. In an implicit scenario, the network may be cleaning up precisely because the UE is no longer available for signaling.
How Does the UDM Pass a Subscription Withdrawal Decision to the AMF?
A change in subscriber entitlement is one of the clearest examples of network-initiated deregistration. Suppose a UE is already registered in a visited network and has established service, but the home network subsequently withdraws the user's 5G subscription. The UDM sees that subscription change first, not the gNB or the UE.
The UDM can send a Deregistration Notification to the serving AMF through the callback URI previously registered by that AMF. In a typical case, the notification can indicate a reason such as SUBSCRIPTION_WITHDRAWN and identify the relevant Access Type, for example 3GPP_ACCESS.
Only after receiving this notification does the AMF move into the UE-facing network deregistration procedure. The AMF can then send a NAS Deregistration Request to the UE through the gNB. In addition to UE identity and Access Type, one particularly important field is re-registration required.
This field indicates whether the network expects the UE to perform a new Registration after deregistration. It should not be interpreted as meaning that every network-initiated deregistration always forces a successful re-registration. In some scenarios, the network may only want the UE to leave the current AMF or rebuild its registration context. If the subscriber has actually lost 5G service entitlement, whether a later Registration succeeds is a separate decision.
After the UDM-to-AMF notification is processed, the AMF returns the corresponding acknowledgment to the UDM. At this point, the control chain has moved from "subscription state changed" to "the serving AMF is now executing deregistration."
How Are Backend Resources Cleaned Up After the Network Decides to Deregister the UE?
From this point onward, some of the resource-release steps overlap with UE-initiated deregistration. There is little value in repeating every N4, PCF and UDM message again. The more important point is why these cleanup actions are still required in a network-initiated procedure.
The UE may already have one or more active PDU Sessions. Once the AMF decides to terminate the registration, it needs to instruct the relevant SMFs to release those sessions. The SMF then handles user-plane resources and N3 paths on the UPF side and terminates SM Policy relationships that no longer have a valid service context. UDM subscriptions or registrations can also be removed according to the remaining session state.
The AMF itself may also need to release access and mobility policy relationships, including an AM Policy Association and any applicable UE Policy Association. Otherwise, the network could end up in an inconsistent state where the UE is no longer registered but the PCF, SMF or UDM still retains relationships suggesting that active service continues.
The difficult part is not "delete as much as possible." The network must understand the current Access Type and any remaining valid service state. If the UE remains registered through another access or some context is still used by another session, deleting every piece of UE state would be incorrect.
Therefore, after seeing a network-initiated Deregistration Request, troubleshooting should not focus on whether an identical 14-message sequence appears. Instead, verify whether PDU Sessions that should be released are actually released, whether obsolete policy relationships are terminated, and whether context that should remain valid has been preserved.
What Is the Difference Between an AMF Explicit Kick and UDM Subscription Withdrawal?
The later stages of these two procedures can look very similar because both ultimately rely on the AMF to deregister the UE and may enter the same PDU Session and policy cleanup logic. Their starting points, however, are different.
If an operator explicitly removes the UE from the AMF, the first important action comes directly from the AMF. There is no prior Deregistration Notification from the UDM. The AMF already has the operational reason for deregistration and can send the Deregistration Request directly to the UE.
If the subscriber's 5G service has been withdrawn, the starting point is the UDM. Before the AMF acts, it normally receives a deregistration notification from the UDM. In multi-NF packet captures, this difference is extremely useful because it shows who first decided that the existing registration should be terminated, rather than treating all later cleanup signaling as the same scenario.
During AMF migration or redistribution of users within an AMF pool, the re-registration requirement in the Deregistration Request should also be examined together with whether the UE subsequently enters a new Registration procedure. In such a case, deregistration may be one step in moving the UE to another serving AMF rather than a permanent termination of the subscriber's 5G service.
Subscription Withdrawal is different in nature because it reflects a change in subscriber entitlement. Even if the NAS procedure allows the UE to attempt Registration again, the core network will still evaluate that attempt against the updated subscription state.
In a Trace, Start with Who Sent the First Message
Network-initiated deregistration is easier to analyze when divided into four stages: origin → notification → resource cleanup → UE response.
First, identify the origin. If the earliest relevant message is a Deregistration Notification from the UDM to the AMF, the procedure was triggered by a UDM-side event. If the AMF sends the Deregistration Request directly to the UE, it is more likely an explicit AMF-initiated case. If neither appears but the network begins removing UE context, consider implicit deregistration.
Second, check the NAS direction. In network-initiated deregistration, the Deregistration Request flows AMF → UE. This is the opposite direction from UE-initiated deregistration. The message name may be identical, so direction matters.
Third, check whether the UE returns Deregistration Accept. During explicit deregistration, if the UE remains reachable, a response is normally visible. In implicit deregistration, the UE may already be unreachable, so this step may be absent.
Fourth, verify backend resources. If the UE previously had PDU Sessions, check whether the corresponding SMF and UPF resources were released. If the procedure originated from the UDM or involved policy state, verify the UDM and PCF relationships as well.
A practical analysis sequence is:
Identify which NF initiated or triggered the procedure;
Confirm the Deregistration Request direction and Access Type;
Check whether re-registration required matches the scenario;
Determine whether the UE returns Deregistration Accept;
Verify release of existing PDU Sessions and user-plane resources;
Finally, confirm that the UE registration state has left RM-REGISTERED.
This is closer to real troubleshooting than mechanically comparing whether one HTTP/2 message is missing from a numbered reference flow. Network-initiated deregistration has multiple possible causes, so different scenarios can look different from the very first message.
FAQ
Does Network-Initiated Deregistration Always Send a Deregistration Request to the UE?
No. During explicit deregistration, if the UE is reachable, the AMF normally sends a Deregistration Request. Implicit deregistration often occurs after the UE has remained unreachable for an extended period, so the network may directly clean up registration context without a NAS Deregistration Request appearing in the trace.
Can the UDM Directly Deregister the UE?
The UDM is primarily responsible for subscriber and subscription data. Events such as subscription withdrawal can trigger deregistration, but the serving AMF is still the NF that performs the network-initiated Deregistration Request toward the UE. Trace analysis should distinguish between UDM-triggered and AMF-initiated deregistration.
If re-registration required Is Set to 1, Does That Mean the UE Will Definitely Register Again Successfully?
No. The field indicates that the network requires the UE to perform Registration again, but whether the new Registration is accepted depends on subscriber entitlement, access restrictions, network policy and the reason for the original deregistration. If the subscription has been withdrawn, a new Registration attempt does not guarantee that the 5GC will accept the UE.
Are the Resource-Release Steps Completely Different from UE-Initiated Deregistration?
No. The trigger direction is different, but once the network decides to terminate the registration, cleanup of existing PDU Sessions, UPF resources and policy relationships can overlap significantly with UE-initiated deregistration. The more useful distinctions are who started the procedure, the NAS message direction, whether UE confirmation is expected and whether re-registration is required.
