Periodic Registration Update¶

Learning objectives¶

After reading this page, you will be able to:

• Explain the Why (why Periodic Registration Update is needed) from the perspective that the network cannot explicitly know when a UE has gone out of coverage or lost power, so a periodic liveness check is required.
• Explain the trigger of Periodic Registration Update (the expiry of the periodic registration update timer on the UE side).
• Explain the significance of the liveness check (maintaining reachability) and the fact that a UE for which no update arrives may be treated as subject to implicit deregistration.
• Organize and explain how, among the Registration types, this chapter corresponds to periodic registration updating.
• Explain the role of the periodic registration update timer (commonly said to be called T3512; the name and value are to be confirmed) and the fact that the AMF may assign the next timer value on Accept.
• Contrast the difference in trigger with Mobility Registration Update (the location changed vs. time has passed).
• Contrast the correspondence between 4G (EPC)'s Periodic TAU (Periodic Tracking Area Update) and 5G's Periodic Registration Update.

Prerequisites¶

It will go more smoothly if you understand the following first. If you are not there yet, start from the Curriculum.

• Understanding Initial Registration — this chapter is another variant of the registration procedure. For the overall picture of registration, authentication, and security, see Initial Registration.
• Understanding Mobility Registration Update — the closest sibling procedure, which shares the skeleton of the procedure. Reading it first goes smoothly, so you can contrast the difference in trigger (location vs. time). → Mobility Registration Update
• Understanding the Registration Area (= TAI list) and CM states — why management is done per area, and how an idle (CM-IDLE) UE is tracked. → Paging (the upstream concept of the Registration Area)
• N1 / N2 (NAS between UE⇔AMF, NGAP between gNB⇔AMF) → N1 / N2
• The role of the main NF → AMF

What you'll learn in this chapter¶

This chapter is limited to Periodic Registration Update. Even when the UE has not moved, it is the procedure of periodic registration update that, when the UE's periodic registration update timer expires, tells the network "I am still in the serving area and alive." It corresponds to 4G's Periodic TAU (Periodic Tracking Area Update). It focuses on the core viewpoint — in particular the Registration Request received by the AMF (Registration type = periodic registration updating), its essence being the liveness check of the UE (maintaining reachability), and the implicit deregistration of a UE for which no update arrives.

The following are out of scope for this chapter, or kept at the conceptual level.

• Details of Mobility Registration Update — a separate variant triggered by "the location changed." This chapter only touches on it as a contrast in difference in trigger, and directs you to Mobility Registration Update for the detailed procedure (overlap is handled by redirection).
• The authentication/security details of Initial Registration — this chapter foregrounds the point that "it can be even more lightweight by reusing an existing context," and directs you to Initial Registration / the Security chapter for the details of 5G-AKA and so on.
• Concrete values of the periodic timer — the concrete values and names of the periodic registration update timer (said to be equivalent to T3512) and the implicit-deregistration-related timers are version- and implementation-dependent, and are treated as to be confirmed without assertion (see below).
• The detailed procedure of implicit deregistration — the precise procedure of at what point and how the network implicitly detaches a UE for which no update arrives is treated as concept only (the details are to be confirmed).
• Radio (RRC/RAN) side details — RRC connection establishment and radio resource allocation are kept conceptual, and the focus is on the core's involvement (radio side / implementation-dependent).
• Session handling on the SMF/UPF side — this chapter does not delve into the user-plane handling accompanying the periodic update, and focuses on the core procedure of the liveness check.

Why — why Periodic Registration Update is necessary¶

Let's start from the Why (why it is needed). As long as a registered (5GMM-REGISTERED) UE is inside its Registration Area (= the assigned TAI list), an idle (CM-IDLE) UE is not tracked per cell, releases its dedicated radio connection, and waits with low power consumption (this is the flip side of the design of Paging / Service Request).

Here there is a fundamental problem. The network does not explicitly know whether an idle UE "is still there." A UE can disappear from the network without saying anything, in ways such as the following.

• It went out of coverage — it moved to a place where radio does not reach (underground, mountainous areas, aboard an aircraft).
• It lost power — battery depletion or power-off. It may disappear without being able to send a De-registration (an explicit deregistration).

Because an idle UE sends nothing to the network, these cannot be detected if left unattended. The network keeps believing "this UE is in the serving area" and holds its context indefinitely, keeps throwing Paging at an unreachable party on an incoming call, and needlessly holds resources (UE context, paging targets).

Periodic Registration Update is the procedure by which the UE, even without having moved, periodically reports in to the network: "I am still alive; I am in the serving area." As long as this periodic report keeps arriving, the network regards the UE as in the serving area; when it stops arriving, it judges "it seems to have left" and proceeds to implicit deregistration, releasing the context and rightsizing resources.

Overview¶

Periodic Registration Update occurs in the following broad flow.

The UE's periodic registration update timer expires → the UE sends a Registration Request (Registration type = periodic registration updating) to the AMF via the gNB (N1/N2) → the AMF checks the existing UE context and updates the liveness record (that the UE is in the serving area) (usually without authentication or UDM query = lightweight) → the AMF responds with a Registration Accept and, if necessary, notifies the next periodic timer value → the UE returns (if necessary) a Registration Complete, and the UE restarts the periodic timer, and it is done.

The Registration type is the kind that indicates the "purpose" of the same Registration procedure. This chapter corresponds to the periodic among these.

Let's organize the difference in trigger (in contrast with mobility). The skeleton of the procedure is common, but why it fires differs.

Basic Concept — a beginner-friendly explanation¶

To understand Periodic Registration Update, grasp three keywords.

1. Why a liveness check is needed (the problem that the NW cannot detect a UE's departure)¶

An idle (CM-IDLE) UE waits with low power, sending nothing to the network. This is efficient, but conversely it becomes a weak point: the network cannot actively know that the UE has departed (out of coverage / lost power).

• When the UE deregisters normally, it can send a De-registration (an explicit deregistration).
• However, out of coverage / battery depletion, the UE disappears without being able to send anything.

What solves this problem of "being unable to distinguish whether silence is normal or abnormal" is a periodic liveness report. If the UE keeps periodically sending "I am in the serving area," the network can judge "a report arrives = in the serving area" and "the report stops = suspected departure."

2. The mechanism of the periodic timer (fires on expiry, assigns the next value on Accept)¶

Periodic Registration Update fires when the UE's periodic registration update timer expires.

• When the UE's previous registration/update succeeds, it starts the periodic registration update timer.
• When the timer expires, the UE sends a Registration Request (type=periodic).
• The AMF responds with a Registration Accept and, if necessary, may notify the UE of the next periodic timer value (the value is decided by the network side's operation).
• The UE restarts the timer and waits for the next expiry again.

In other words, the value of the periodic timer determines the interval of the liveness report. Making it shorter lets you detect departure earlier but increases update signaling; making it longer saves signaling but delays departure detection — a trade-off.

3. implicit deregistration (the handling of a UE for which no update arrives)¶

When the periodic report from the UE does not arrive at the expected time, the network infers "this UE seems to have departed." The network also holds a related timer on its own side (a supervision timer corresponding to the periodic timer plus a margin), and if no contact arrives from the UE even after it expires, it treats the UE as deregistered without any explicit exchange. This is implicit deregistration (implicit detach / implicit deregistration).

• implicit = deregistering by the network side's judgment alone, without exchanging messages with the UE.
• The purpose is the rightsizing of resources (UE context, paging targets). So as not to keep holding resources for an unreachable party.
• After implicit detach, when the UE returns to a place where radio reaches, or is powered on again, the UE will redo registration from scratch (Initial Registration, etc.), rather than a periodic update.

Architecture¶

The elements involved in Periodic Registration Update and the interfaces that connect them. The main actor is the AMF, which handles the update of the liveness record, timer management, and the implicit-detach judgment. Unlike Mobility Registration Update, TAI list reassignment is usually unnecessary, and UDM / AUSF involvement is usually slight (conditional), so they are represented with dashed lines and notes.

flowchart LR
    UE(("UE
(REGISTERED)
periodic timer expiry")) ---|"N1 (NAS): Registration Request
type=periodic"| AMF
    UE -. "RRC (radio side, out of scope)" .- RAN["(R)AN / gNB"]
    RAN ---|"N2 (NGAP)"| AMF["AMF
(liveness record update
timer mgmt / implicit-detach judgment)"]
    AMF -.->|"N12 (usually unnecessary: only on re-authentication)"| AUSF["AUSF
(usually slight involvement)"]
    AMF -.->|"N8 (usually unnecessary: only on subscription change)"| UDM["UDM
(usually slight involvement)"]
    AMF -. "no update arrives → implicit deregistration
(concept / to be confirmed)" .- IMPL["implicit-detach judgment"]

    classDef core fill:#efe,stroke:#3a3,stroke-width:2px;
    classDef cond fill:#eef,stroke:#66a,stroke-width:1px,stroke-dasharray:4 2;
    class AMF core;
    class AUSF,UDM,IMPL cond;

The role of each element is as follows.

• UE — the terminal whose periodic registration update timer has expired. It need not have moved. It sends a Registration Request (type=periodic registration updating) and, after the response, restarts the timer. The radio-side RRC is out of scope.
• (R)AN / gNB — the radio access. It puts the UE's NAS onto NGAP and carries it to the AMF.
• AMF — the entity that accepts the periodic update. It checks the existing UE context, updates the UE's liveness record (that it is in the serving area), assigns (if necessary) the next periodic timer value, and responds with a Registration Accept. It judges the implicit deregistration of a UE for which no periodic report arrives.
• AUSF (usually slight involvement) — may be involved only in the exceptional case where re-authentication is needed (N12). It usually does not occur in a periodic update.
• UDM (usually slight involvement) — may be involved only in the exceptional case of a change in subscription information, etc. (N8). It usually does not occur in a periodic update.

For the details of the interfaces, see the Interface Dictionary.

Network Function (the NFs that appear)¶

The roles of the core-side NFs that appear in Periodic Registration Update. The gNB is on the radio-access side and is not a core NF (this table is limited to core NFs). In a periodic update, the AMF being able to complete the processing on its own is the base case, and the UDM / AUSF usually do not get involved (conditional = only in exceptional cases).

Interface / Protocol¶

The interfaces and protocols used in this procedure. A periodic update basically completes with N1 / N2 only, and N8 / N12 are usually unnecessary (only in exceptional cases).

For the details of protocols, see the Protocol Dictionary; for the list of interfaces, see the Interface Dictionary.

Procedure — Call Flow¶

This is the heart of this page. The main steps of Periodic Registration Update are shown in a Mermaid sequenceDiagram. The basis is 3GPP TS 23.502 §4.2.2.2 series (Registration procedures), TS 24.501 §5.5.1 series (NAS Registration procedure), and TS 38.413 (NGAP) (the details of the section numbers are to be confirmed). The skeleton is common with Mobility Registration Update, but we emphasize that authentication, subscriber retrieval, and TAI list reassignment usually do not occur, making it more lightweight.

sequenceDiagram
    autonumber
    participant UE as UE (REGISTERED)
    participant RAN as (R)AN / gNB
    participant AMF
    participant UDM

    Note over UE: Periodic registration update timer expiry (no movement needed)
    Note over UE,RAN: RRC connection establishment/resume (radio side, outline / out of scope)
    UE->>RAN: Registration Request (NAS)
type=periodic registration updating
    Note right of UE: TS 24.501 §5.5.1. 5GS registration type=periodic (to be confirmed)
    RAN->>AMF: Put NAS onto Initial UE Message (NGAP)
    Note right of RAN: N2 / TS 38.413

    Note over AMF: Check the existing UE context (resolved by 5G-GUTI)
    Note over AMF: Update the UE's liveness record (regard as in the serving area)

    opt Only in exceptional cases: re-authentication / subscription query (usually does not occur)
        AMF->>UDM: Nudm_* (on subscription change, etc., N8)
        UDM-->>AMF: Subscriber data (only in exceptional cases)
    end

    AMF->>UE: Registration Accept (NAS)
(if necessary) next periodic timer value
    Note right of AMF: TS 24.501 §5.5.1. Usually no TAI list reassignment

    opt When necessary (on next timer value / 5G-GUTI reassignment, etc.)
        UE->>AMF: Registration Complete (NAS)
    end
    Note over UE,AMF: The UE restarts the periodic timer. It maintains 5GMM-REGISTERED

Step-by-step explanation (numbers correspond to the diagram above)¶

1. UE→(R)AN: triggered by the expiry of the periodic registration update timer, the UE establishes/resumes an RRC connection (on the radio side) (outline / out of scope) and carries the Registration Request (NAS) with Registration type = periodic registration updating. Typically a valid 5G-GUTI is placed in the 5GS mobile identity (the IE name / type value are to be confirmed). Reference: TS 24.501 §5.5.1 (section number to be confirmed).
2. (R)AN→AMF: the gNB puts the NAS onto an Initial UE Message (NGAP) and sends it to the AMF (N2 / TS 38.413).
3. The AMF's judgment (context check): the AMF resolves the existing UE context from the 5G-GUTI. In a periodic update the base case is that the existing security and subscription information can be reused, making it even more lightweight than Mobility.
4. Liveness record update: the AMF records that the UE is in the serving area (maintaining reachability) and updates the periodic timer supervision. This is the essence of this procedure.
5. (Only in exceptional cases) re-authentication / subscription query: only in the exceptional case where re-authentication is needed or the subscription information has changed, etc., the AMF may perform AMF→AUSF (N12) / AMF→UDM (N8). In a periodic update it usually does not occur (situation dependent).
6. Accept: the AMF responds with AMF→UE Registration Accept (NAS). Usually there is no TAI list reassignment (within the same area). If necessary, it may notify the next periodic timer value, the registration result, etc. (the IE name / handling are to be confirmed).
7. (When necessary) Complete: when there is application of the next timer value or a 5G-GUTI reassignment, etc., the UE returns UE→AMF Registration Complete (NAS). The UE restarts the periodic timer and maintains 5GMM-REGISTERED (this is not a new transition from DEREGISTERED).

Reference: TS 23.502 §4.2.2.2 series (Registration procedures, section number to be confirmed), TS 24.501 §5.5.1 series (the NAS-side Registration procedure), TS 38.413 (NGAP).

Signal Flow¶

The key Messages/service operations organized in a table. The IEs are made consistent with the Message Dictionary. Some of the IE names / type values / operation names are version- and implementation-dependent and are treated as to be confirmed.

For the detailed IEs and reference specs of each Message, see the Message Dictionary. Some of the IE names / type values are implementation- and version-dependent and are treated as to be confirmed.

State Machine¶

The viewpoint of the UE-side 5GMM state. Periodic Registration Update performs the liveness check while maintaining 5GMM-REGISTERED, and restarts the periodic timer (basis: TS 24.501 §5.1.3 / §5.5.1 series, section number to be confirmed). What matters is the branch: as long as updates keep arriving REGISTERED is maintained, and if updates do not arrive, by the network's judgment it may reach implicit deregistration → DEREGISTERED.

stateDiagram-v2
    [*] --> REGISTERED: After Initial Registration completes (periodic timer starts)
    REGISTERED --> REGISTERED_UPDATE: Periodic timer expiry → send Registration Request (type=periodic)
    REGISTERED_UPDATE --> REGISTERED: Receive Registration Accept (periodic timer restart)
    REGISTERED --> DEREGISTERED: No periodic update arrives → implicit deregistration (NW judgment / concept)
    REGISTERED --> DEREGISTERED: De-registration / registration lapse
    DEREGISTERED --> [*]

• 5GMM-REGISTERED — registered. It does not change state while the periodic timer is running. Sending a periodic update on timer expiry moves it into the transient state of the update.
• 5GMM-REGISTERED (updating / transient) — the transient state after sending a Registration Request (type=periodic) and awaiting a response (illustrated in the diagram above as REGISTERED_UPDATE). On receiving a Registration Accept, it restarts the periodic timer and returns to REGISTERED.
• 5GMM-DEREGISTERED — not registered. If a periodic update does not arrive at the expected time and the network judges implicit deregistration, it may reach this state without any explicit exchange (NW-side judgment / concept; the precise timing is to be confirmed). It may also transition here on De-registration or registration lapse.

Packet Analysis (Wireshark)¶

The key points when analyzing Periodic Registration Update with Wireshark. On the core side, the NAS Registration Request/Accept is observed nested inside NGAP (Initial UE Message, etc.). The decisive difference from Mobility is the value of the 5GS registration type.

Key Display Filters¶

Points to note when decoding (key IEs)¶

• NAS Registration Request (UE→AMF) — note the following IEs (the IE names are representative notation, to be confirmed).
  • 5GS registration type — this being periodic registration updating is the decisive marker of this procedure (in Initial it is initial registration, in Mobility it is mobility registration updating). The code of the value is to be confirmed.
  • 5GS mobile identity — in Periodic Registration Update, typically the 5G-GUTI (different from the SUCI of the first registration).
• NAS Registration Accept (AMF→UE) — note the following IEs.
  • registration result, etc. In a periodic update there is usually no TAI list reassignment (same area), but it can occur (to be confirmed).
  • The next periodic timer value (when the AMF notifies it) — the concrete IE name / handling are to be confirmed.

The nesting structure of the message (NAS nested inside NGAP)¶

The NAS of the Registration Request goes into the NGAP message (Initial UE Message) as a NAS-PDU (the same nesting structure as Initial Registration / Mobility Registration Update). In the packet detail pane it is displayed hierarchically as follows (the notation is conceptual; the actual names are dissector-dependent = to be confirmed).

NGAP-PDU
 └─ InitialUEMessage
     └─ NAS-PDU
         └─ 5GS NAS Message
             └─ Registration Request (5GS registration type=periodic)

Configuration¶

The structural-level key points of the configuration for making Periodic Registration Update work. Specific values and vendor-specific details (Cisco, etc.) are implementation-dependent, and no fictitious values are written here.

Periodic-registration-update-timer-related (AMF side)¶

• Periodic registration update timer (said to correspond to the periodic registration update timer commonly called T3512) — determines the interval at which the UE fires periodic updates. The AMF may notify the UE of the value on Accept. The name, value, and configuration key have version- and implementation-dependent aspects and are to be confirmed. Check the configurable range and key names in Open5GS / free5GC in each implementation's documentation.
• Implicit-deregistration-related timer (a supervision timer by which the network side judges "no update arrives"; said to correspond to the periodic timer plus a margin) — the name, value, and key name are version- and implementation-dependent and are to be confirmed. Its relationship with the periodic timer is also implementation-dependent.

Trouble Shooting¶

Isolating typical Periodic-Registration-Update-related issues (in general terms). For the details of Cause values, see the Cause Dictionary.

Comparison with EPC¶

A comparison so that those experienced with 4G (EPC) can bridge to 5G. The basic idea is common to 4G and 5G: "even without having moved, periodically report in your liveness, and if it does not come, deregister implicitly." 4G's Periodic TAU (Periodic Tracking Area Update) corresponds to 5G's Periodic Registration Update.

Release differences¶

The main topics related to Periodic Registration Update. Uncertain items are marked to be confirmed and not asserted.

• Rel-15 — the basic 5GC Registration procedures (the initial / mobility / periodic / emergency Registration types, the periodic registration update timer, the basics of implicit deregistration) were established. This chapter is within the scope of these Rel-15 fundamentals.
• MICO mode (Mobile Initiated Connection Only) — a power-saving mode in which the UE does not receive network-initiated reachability (Paging). It is a concept related to periodic update and reachability management, but it is out of scope for this chapter and touched on conceptually only. The handling of periodic update and reachability when MICO is enabled is version- and configuration-dependent, and the details are to be confirmed (see FAQ).
• RRC Inactive / RAN Notification Area (RNA) — a UE state introduced in Rel-15. On the radio side there is a separate-layer procedure called RNA Update, which is a different concept from the core (AMF)-initiated periodic registration update (radio side / concept only).
• Power-saving / reachability extensions (Rel-16 onward) — the generation in which extensions to power saving and reachability management advanced. The concrete differences to the periodic registration update procedure itself are to be confirmed.

3GPP Specification¶

FAQ¶

Summary¶

• Periodic Registration Update is a periodic registration update in which, even without having moved, the UE reports in to the network that it "is still in the serving area and alive," triggered by the expiry of the periodic registration update timer. It corresponds to 4G's Periodic TAU.
• The core of the Why is that "the network cannot explicitly know the out-of-coverage / power loss of an idle UE." If the periodic liveness check keeps arriving it is in the serving area; if it stops, resources are rightsized with implicit deregistration (implicit detach).
• The trigger is the expiry of the periodic registration update timer on the UE side (commonly said to be T3512, but the name and value are to be confirmed). The UE sends a Registration Request (type=periodic registration updating) to the AMF.
• The main actor is the AMF (checking the existing UE context, updating the liveness record, timer management, implicit-detach judgment, issuing the Registration Accept). The UDM / AUSF usually do not get involved (only in exceptional cases).
• The skeleton is common with Mobility Registration Update, but the trigger is "time," and usually TAI list reassignment, authentication, and UDM query do not occur, making it more lightweight (situation dependent). It maintains 5GMM-REGISTERED, and the UE restarts the periodic timer.
• The basis is TS 23.502 §4.2.2.2 series / TS 24.501 §5.5.1 series and §5.1.3 and §10.2 / TS 23.501 §5.3 series and §5.4 series / TS 38.413 (some of the section numbers / IE names / registration type value / periodic timer name/value / implicit-deregistration timer are to be confirmed).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

Problem: Reorder the following main Periodic Registration Update steps into the correct order.

A. The AMF updates the UE's liveness record (regards it as in the serving area)
B. UE → gNB: Registration Request (NAS, type=periodic) (after RRC establishment)
C. AMF → UE: Registration Accept ((if necessary) next periodic timer value)
D. gNB → AMF: carry the NAS on an Initial UE Message (NGAP)
E. The AMF checks the existing UE context from the 5G-GUTI
F. The UE's periodic registration update timer expires
G. The UE restarts the periodic timer (maintains 5GMM-REGISTERED)

Next Step¶

The next steps to deepen your understanding.

• Prerequisite of the procedure: Initial Registration (the overall picture of registration, authentication, and security)
• The closest sibling procedure: Mobility Registration Update (another variant of the same Registration; the trigger is "location")
• Related: Paging (the upstream concept of the Registration Area; the flip side of reachability)
• Related for contrast: Service Request (U-Plane re-establishment; the details of CM states)
• Sibling procedure: Handover (connection switching while moving)
• Related NFs: AMF / UDM / AUSF
• Related Interfaces: N1 / N2
• Dictionaries: Message Dictionary / Timer Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary