5G Mobility Registration Update Procedure Call Flow
5G Mobility Registration Update is the registration-maintenance procedure used when UE movement changes the location context enough that the network must refresh it.
It combines area-change detection, NAS registration updating, and reachability-context refresh into one mobility workflow.
Introduction
The Mobility Registration Update procedure keeps the UE registered while updating the area and mobility context used for future paging, service restoration, and movement handling.
The main nodes are the UE, gNB, and AMF. The key analysis goal is to prove that the new location context was accepted and will support later reachability.
What Is Mobility Registration Update in Simple Terms?
- What starts the procedure: The UE moves into an area that is not covered by its current registration context.
- What the UE and network want to achieve: Keep the UE registered while refreshing mobility and reachability context.
- What success looks like: The UE sends mobility Registration Request and receives Registration Accept.
- What failure means: The old context is no longer valid enough and broader registration recovery may be needed.
Why this procedure matters
Mobility registration update is the 5G registration-maintenance branch most closely tied to UE movement. If it goes wrong, the visible symptom often appears later as paging failure, service-return trouble, or unexpected fresh registration.
Quick Fact Sheet
| Procedure name | 5G Mobility Registration Update Procedure |
|---|---|
| Domain | 5G NR + 5GC mobility-registration update |
| Main trigger | UE enters a new registration area or tracking area context that requires a mobility update |
| Start state | UE is already registered but its current location context is no longer sufficient |
| End state | UE remains registered with updated mobility and reachability context |
| Main nodes | UE, gNB, AMF |
| Main protocols | RRC, NAS, NGAP |
| Main success outcome | Registration Accept refreshes the registration area and the UE remains reachable in the new area |
| Main failure outcome | The update is rejected, old context is invalid, or the UE must fall back to broader registration recovery |
| Most important messages | Registration Request (Mobility Updating), Registration Accept, Registration Complete |
| Main specs | TS 23.502, TS 24.501, TS 38.300, TS 38.331 |
Preconditions
- The UE is already registered in the 5GS.
- The UE detects a new area context that is not covered by the old registration state.
- The access side can provide a usable signaling path toward the AMF.
- The stored identity and security context are still good enough for protected NAS continuation.
Nodes and Interfaces
Nodes involved
| Node | Role in this procedure |
|---|---|
| UE | Detects that the current area context is no longer valid and starts the mobility-related registration update. |
| gNB | Provides the access path and relays the NAS update signaling toward the AMF. |
| AMF | Updates the UE location and registration-area context so the UE remains reachable after movement. |
Interfaces used
| Interface | Path | Role |
|---|---|---|
| NR-Uu | UE <-> gNB | Carries access restoration and the mobility-update NAS exchange. |
| N1 | UE <-> AMF | Carries Registration Request, Registration Accept, and Registration Complete. |
| N2 | gNB <-> AMF | Carries control-plane relay and UE context handling. |
End-to-End Call Flow
UE gNB AMF
| | |
|-- area change ---| |
|-- RRC Resume/Setup ---------------->|
|-- Registration Request ----------->|
| | |-- location refresh
|<-- Registration Accept ------------|
|-- Registration Complete ---------->|Major Phases
| Phase | What happens |
|---|---|
| 1. Area change detection | The UE detects a new tracking or registration area that is not covered by the current allowed context. |
| 2. Access restoration | The UE re-establishes enough signaling to deliver the NAS update request if it is not already active. |
| 3. Mobility update request | The UE sends Registration Request with mobility updating type. |
| 4. Location-context refresh | The AMF updates the UE mobility context and the area information used for later reachability. |
| 5. Accept and completion | The UE receives Registration Accept and confirms with Registration Complete. |
Step-by-Step Breakdown
UE detects that the old area context is no longer sufficient
Sender -> receiver: UE internal mobility logic
Message(s): Tracking area or registration area change detection
Purpose: Decide that the network location context must be refreshed while keeping the UE registered.
State or context change: UE prepares a mobility-related update instead of initial registration.
Note: The most important early check is whether the new TAI or area really sits outside the old allowed context.
UE restores access signaling
Sender -> receiver: UE -> gNB
Message(s): RRC Setup or RRC Resume path
Purpose: Create the control-plane path needed to carry the mobility update request.
State or context change: UE regains or keeps the radio-control leg toward the serving gNB.
Note: If this access leg is unstable, later mobility-update failure can be only a symptom of a radio problem.
UE sends mobility Registration Request
Sender -> receiver: UE -> gNB -> AMF
Message(s): Registration Request with mobility updating type
Purpose: Tell the AMF that the UE location context must be updated after movement.
State or context change: AMF starts the mobility update transaction using the UE’s existing registration state.
Note: Registration type, UE identity, and current area context are the first fields to inspect.
AMF updates location and area context
Sender -> receiver: AMF internal context handling
Message(s): Mobility-context update and registration-area refresh
Purpose: Keep the UE reachable and registered in the new area without forcing a fresh registration path.
State or context change: The network now associates the UE with the new location context.
Note: If movement crosses a bigger control boundary, the trace may show more than a trivial area refresh.
AMF accepts and UE completes
Sender -> receiver: AMF -> UE -> AMF
Message(s): Registration Accept, Registration Complete
Purpose: Close the mobility registration update and return the refreshed reachability context.
State or context change: UE remains registered and page-able in the new area.
Note: Returned area information often explains later paging success or paging failure after movement.
Important Messages in This Flow
| Message | Protocol | Direction | Purpose in this procedure | What to inspect briefly |
|---|---|---|---|---|
| Registration Request | NAS | UE -> AMF | Starts the mobility registration update path. | Inspect mobility updating type, UE identity, and current area context. |
| Registration Accept | NAS | AMF -> UE | Returns the refreshed registration and area context. | Check updated area list, registration result, and later reachability implications. |
| Registration Complete | NAS | UE -> AMF | Confirms that the UE applied the mobility update result. | Verify that the final uplink NAS step actually reached the AMF. |
| RRC Setup or Resume | RRC | UE <-> gNB | Provides the access-side signaling path used before the NAS update. | Check whether the radio leg was healthy before the mobility update was blamed. |
Important Parameters to Inspect
| Parameter | What it is | Where it appears | Why it matters | Common issues |
|---|---|---|---|---|
| Registration type | Shows that this branch is mobility updating. | Registration Request | Separates mobility refresh from periodic and initial registration. | Wrong branch assumption leads to wrong root-cause analysis. |
| TAI or registration area context | Area information that triggered the mobility update. | UE mobility context and Registration Accept | Explains why the UE needed this procedure now. | Old and new area lists can be confused in incomplete traces. |
| 5G-GUTI | Existing UE identity used with stored registration context. | Registration Request | Lets the AMF link the new update to the old known UE state. | Stale identity after long idle or context loss. |
| Allowed area list | Returned area context after success. | Registration Accept | Explains later paging and future update behavior. | Unexpected list can make later movement look inconsistent. |
| Security context continuity | Protected NAS state reused for the mobility update. | Registration Request and later exchange | Shows whether the UE could continue under the old trusted context. | Context loss can force broader recovery even when movement looked simple. |
Success Criteria
- The UE correctly detects that movement requires a mobility registration update.
- The request reaches the AMF using the old valid UE context.
- The AMF returns refreshed area and reachability context in Registration Accept.
- The UE confirms with Registration Complete and remains reachable in the new area.
Common Failures and Troubleshooting
| Symptom | Likely cause | Where to inspect | Relevant message(s) | Relevant interface(s) | Likely next step |
|---|---|---|---|---|---|
| Mobility Registration Update is rejected | Stored context is stale, the update type is not acceptable, or the network cannot continue with the old state. | Registration type, UE identity, and reject result. | Registration Request, Registration Reject | N1, N2 | Use the rejection outcome to decide whether the UE must re-register instead of retrying the same update. |
| Update is accepted but later paging fails | The area refresh did not match the network’s practical reachability behavior. | Returned area list, TAI context, and later paging traces. | Registration Accept, Paging | N1, N2, NR-Uu | Read the accept together with later reachability behavior, not as an isolated success. |
| Registration Complete is missing | The UE did not finish the final NAS step or the uplink transport path was lost. | Registration Accept and final uplink NAS relay. | Registration Accept, Registration Complete | N1, NR-Uu, N2 | Confirm whether the UE got the accept before blaming the completion step. |
| UE falls back to a broader registration path | The old registration state could not survive the movement event. | Follow-on registration behavior after the failed update. | Registration Reject, Registration Request | N1 | Treat this as context loss rather than a small area-update mismatch. |
What to Check in Logs and Traces
- Start with the new TAI or registration-area context that triggered the update.
- Confirm the registration type is mobility updating and not periodic updating.
- Check the UE identity and whether the AMF still had the corresponding old context.
- Inspect the updated area list returned in Registration Accept.
- Correlate later paging behavior with the mobility update result before calling the update successful.
Related Pages
Related sub-procedures
Related message reference pages
Related troubleshooting pages
Notes
Mobility update refreshes area context without rebuilding fresh registration. The most useful checks are the movement trigger, the mobility updating type, and whether the returned area list matches later reachability behavior.
FAQ
What is 5G Mobility Registration Update?
It is the registration-update procedure used when movement changes the UE location context enough to require a mobility refresh.
How is it different from Periodic Registration Update?
Periodic update is timer driven. Mobility update is triggered by area or location change.
Does it always mean the UE changed AMF?
No. Many cases are simpler area updates, but larger movement can involve wider control-context changes.
What confirms success?
Registration Accept followed by Registration Complete with updated area context is the practical success pattern.
What should I inspect first?
Start with the new area context that triggered the procedure and the mobility updating type inside Registration Request.