3GLTEInfo Text-based logo for the 3GLTEInfo telecom engineering reference platform. 3GLTE INFO TELECOM ENGINEERING REFERENCE

Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.

Menu

Home / Call Flows / 5G / Periodic Registration Update

5G Periodic Registration Update Procedure Call Flow

call-flow 5G NR | 5GC | NAS | RRC | Mobility Maintenance

5G Periodic Registration Update is the timer-driven mobility-registration procedure used when the UE is already known to the 5GS and must refresh that state before it expires.

It joins access restoration, protected NAS update signaling, and registration-context validation into one maintenance workflow.

Introduction

The Periodic Registration Update procedure does not create a brand-new registration context. Instead, it keeps an existing 5GS registration alive and valid for later paging, service request, and session procedures.

The main nodes are the UE, gNB, AMF, and sometimes UDM when subscriber context must be refreshed or rechecked.

What Is Periodic Registration Update in Simple Terms?

  • What starts the procedure: A periodic registration timer expires while the UE is already registered.
  • What the UE and network want to achieve: Keep the UE registered and reachable without rebuilding the full initial registration path.
  • What success looks like: The UE sends periodic Registration Request and receives Registration Accept.
  • What failure means: The stored context is no longer acceptable and the UE may need broader recovery.

Why this procedure matters

Periodic update is the quiet maintenance branch that keeps a registered UE valid over time. If it fails, later paging and service behavior often break in ways that look unrelated unless you follow the timer-driven registration refresh itself.

Quick Fact Sheet

Procedure name 5G Periodic Registration Update Procedure
Domain 5G NR + 5GC periodic mobility-registration refresh
Main trigger Periodic registration timer expires while the UE is already registered
Start state UE already has valid 5GS registration and stored security context
End state Registration context remains valid and the periodic timer is refreshed
Main nodes UE, gNB, AMF, UDM
Main protocols RRC, NAS, NGAP, subscriber-context validation
Main success outcome Registration Accept refreshes the context and the UE completes the update
Main failure outcome Update is rejected, old context is no longer trusted, or the UE must fall back to broader recovery
Most important messages Registration Request (Periodic Updating), Registration Accept, Registration Complete
Main specs TS 23.502, TS 24.501, TS 33.501, TS 38.300, TS 38.331
5G Periodic Registration Update procedure flow across UE, gNB, AMF, and UDM
Sponsored Advertisement

Preconditions

  • The UE is already registered in the 5GS.
  • The UE still has usable identity and security context for protected NAS continuation.
  • The access side can restore enough signaling to deliver the update request.
  • The AMF can still resolve or validate the stored registration context.

Nodes and Interfaces

Nodes involved

Node Role in this procedure
UE Triggers the periodic refresh when its timer expires and confirms the returned registration result.
gNB Provides the access path needed for the UE to deliver the NAS update request.
AMF Validates that the existing registration is still usable and returns the refreshed registration context.
UDM May provide subscriber or context refresh information when the AMF needs it during the periodic update.

Interfaces used

Interface Path Role
NR-Uu UE <-> gNB Carries RRC resume or setup and the NAS update request.
N1 UE <-> AMF Carries Registration Request, Registration Accept, and Registration Complete.
N2 gNB <-> AMF Relays the control-plane exchange between access and core.
N8 AMF <-> UDM Used when subscriber or registration context must be refreshed or rechecked.

End-to-End Call Flow

UE                gNB                AMF                UDM
|                  |                  |                    |
|-- timer expiry --|                  |                    |
|-- RRC Resume/Setup ---------------->|                    |
|-- Registration Request ----------->|                    |
|                  |                  |-- context check -->|
|                  |                  |<-- subscriber data -|
|<-- Registration Accept ------------|                    |
|-- Registration Complete ---------->|                    |

Major Phases

Phase What happens
1. Timer expiry The UE reaches the periodic registration update timer and decides it must refresh its registration state.
2. Access restoration The UE re-establishes enough radio signaling to deliver the NAS update request.
3. Periodic update request The UE sends Registration Request with periodic updating type.
4. AMF validation The AMF checks the stored UE context and refreshes it if the registration is still acceptable.
5. Accept and completion The AMF returns Registration Accept and the UE confirms with Registration Complete.

Step-by-Step Breakdown

Periodic timer expires

Sender -> receiver: UE internal mobility timer

Message(s): No NAS message yet

Purpose: Trigger registration maintenance before the existing context ages out.

State or context change: UE decides it needs refresh rather than fresh initial registration.

Note: The timer value that drove this behavior is often the first useful clue in field traces.

UE restores access signaling

Sender -> receiver: UE -> gNB

Message(s): RRC Resume path or fresh access setup

Purpose: Create the signaling path needed to deliver the periodic update toward the AMF.

State or context change: The UE regains a control-plane leg without rebuilding all registration context.

Note: If access restoration fails, the problem is not yet a periodic-update failure even if the UE eventually loses registration.

UE sends periodic Registration Request

Sender -> receiver: UE -> gNB -> AMF

Message(s): Registration Request with periodic updating type

Purpose: Refresh the registration state using the existing UE identity and security context.

State or context change: AMF starts the periodic registration maintenance transaction.

Note: Confirm the registration type before treating the trace as mobility update or initial registration.

AMF validates stored context

Sender -> receiver: AMF and optionally UDM

Message(s): Context validation and subscriber refresh if needed

Purpose: Confirm the UE still has a usable registered context and may remain reachable in 5GS.

State or context change: The registration either stays valid or is pushed toward reject or fallback behavior.

Note: A periodic update failure often means the old context was no longer usable, not that the timer itself was wrong.

AMF accepts and UE completes

Sender -> receiver: AMF -> UE -> AMF

Message(s): Registration Accept, Registration Complete

Purpose: Close the periodic update cleanly and return refreshed timer or area information.

State or context change: UE remains registered and ready for later paging, service request, and session procedures.

Note: Returned timers and mobility context often explain later UE behavior better than the accept outcome alone.

Important Messages in This Flow

Message Protocol Direction Purpose in this procedure What to inspect briefly
Registration Request NAS UE -> AMF Starts periodic registration refresh using the already known UE context. Inspect the registration type, UE identity, and integrity protection.
Registration Accept NAS AMF -> UE Returns the refreshed registration state and timer values. Check timer refresh, returned area context, and any updated allowed NSSAI.
Registration Complete NAS UE -> AMF Confirms that the UE accepted the periodic update result. Verify that it reaches the network cleanly after the accept.
RRC Resume sequence RRC UE <-> gNB Provides the radio-control path used before the periodic NAS refresh. Check whether access restoration succeeded before blaming NAS.

Important Parameters to Inspect

Parameter What it is Where it appears Why it matters Common issues
Registration type Indicates that the UE is performing periodic updating. Registration Request Separates periodic refresh from mobility and initial registration. Misreading the branch leads to wrong troubleshooting.
T3512 or periodic timer The timer that triggered the update. Prior Registration Accept and UE timer behavior Explains why the procedure started now. Unexpected timer handling or stale timer context.
5G-GUTI Stored temporary identity used with existing registration context. Registration Request Lets the AMF resolve the already-known UE quickly. Stale identity or missing old context at the AMF.
Integrity-protected NAS state Protected signaling continuity for the update path. Registration Request and later NAS exchange Shows whether the stored security context still works. Context expired or unusable even though the UE believes it is valid.
Returned timer and area context Refreshed mobility settings after the update succeeds. Registration Accept Explain later UE refresh timing and reachability behavior. Unexpected values cause later paging or update confusion.

Success Criteria

  • The UE restores access-side signaling and delivers the periodic update request cleanly.
  • The AMF still trusts the stored registration and security context.
  • Registration Accept refreshes the timer and mobility state successfully.
  • The UE returns Registration Complete and remains registered.

Common Failures and Troubleshooting

Symptom Likely cause Where to inspect Relevant message(s) Relevant interface(s) Likely next step
Periodic update request is sent but rejected Stored context is no longer valid, policy blocks continuation, or the AMF no longer trusts the old registration state. Registration type, UE identity, and reject outcome. Registration Request, Registration Reject N1, N2 Use the rejection outcome to decide whether the UE should retry, re-register, or correct subscription context.
Registration Accept is sent but the UE never completes The final uplink NAS step was lost or the UE did not apply the returned context fully. Registration Accept contents and Registration Complete timing. Registration Accept, Registration Complete N1, NR-Uu, N2 Confirm that the UE really received and applied the accept before blaming the timer logic.
UE falls back to broader registration after periodic update attempt The old registered context could not be maintained any longer. Whether a new registration branch follows the failed periodic update. Registration Reject, Registration Request N1 Read this as context loss rather than as a normal periodic-refresh variation.
Timer behavior looks wrong after success The UE applied a different returned timer or mobility setting than expected. Returned timer values and subsequent UE behavior. Registration Accept N1 Always compare the old timer with the refreshed one returned by the AMF.

What to Check in Logs and Traces

  • Check the periodic timer that triggered the update before analyzing later failure branches.
  • Confirm the registration type is periodic updating, not mobility updating or initial registration.
  • Verify that the request was still integrity protected under a valid stored context.
  • Inspect the returned timer values and area context in Registration Accept.
  • Confirm that the UE returned Registration Complete after the accept.

Related Pages

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

Periodic updating maintains an existing registration. The most useful checks are the timer that triggered the procedure, the registration type carried in the request, and whether the AMF still trusted the old context.

Sponsored Advertisement

FAQ

What is 5G Periodic Registration Update?

It is the timer-driven procedure that keeps an already registered UE valid in the 5GS.

How is it different from Initial Registration?

Initial Registration creates fresh context. Periodic Registration Update refreshes an already valid registration.

Does it always require authentication again?

Not usually. It commonly reuses existing security context unless the network decides broader validation is needed.

What confirms success?

Registration Accept followed by Registration Complete is the practical success pattern.

What should I inspect first?

Start with the registration type, the periodic timer that triggered the refresh, and whether the old context was still valid at the AMF.