Mobility Registration Update¶

Learning objectives¶

After reading this page, you will be able to:

• Explain the Why (why Mobility Registration Update is needed) from the viewpoint that when a UE moves outside its Registration Area, the network loses track of where the UE is.
• Explain the trigger for Mobility Registration Update (moving into an area whose serving TA is not included in the assigned TAI list).
• Organize the differences between the Registration types (initial / mobility / periodic / emergency), and explain that this chapter corresponds to mobility registration updating.
• Explain the reassignment of the Registration Area (TAI list) and the possibility of 5G-GUTI reassignment.
• Explain the differences from Initial Registration (the point that the existing UE context and security context are reused, so identity verification and subscriber-data retrieval can be simplified).
• Contrast the correspondence between 4G (EPC)'s TAU (Tracking Area Update) and 5G's Mobility Registration Update.
• Organize the relationship and division of use between Paging / Service Request and Mobility 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 a different variant of the registration procedure. For the overall picture of registration, authentication, and security, see Initial Registration.
• Understanding the Registration Area (= the TAI list) — why it is managed per area, and why an update is required when leaving the area. → Paging (the upstream concept of the Registration Area)
• Understanding Service Request (to contrast with Mobility Registration Update) → Service Request
• N1 / N2 (the UE⇔AMF NAS and the gNB⇔AMF NGAP) → N1 / N2
• The roles of the main NFs → AMF (conditionally UDM / AUSF)

What you'll learn in this chapter¶

This chapter is limited to Mobility Registration Update. It is the procedure by which a UE updates its registration information and location with the network when it moves outside its current Registration Area (TAI list). It corresponds to 4G's TAU (Tracking Area Update). It focuses on the core viewpoint — in particular the Registration Request (Registration type = mobility registration updating) that the AMF receives, and the resulting reassignment of the Registration Area (TAI list).

The following are out of scope, or treated only at the conceptual level.

• The authentication/security details of Initial Registration — this chapter makes the point that "reusing the existing context can simplify things" its theme, and directs you to Initial Registration / the Security chapter for the details of 5G-AKA, etc. (duplication is handled by directing).
• The details of Periodic Registration Update — this is a different Registration type. This chapter only touches on it for contrast in the differences between Registration types; for the detailed procedure, see the Periodic Registration Update chapter (out of scope).
• The details of inter-AMF context transfer — the case where an AMF change (AMF re-selection) occurs is Release/configuration dependent, and is treated conceptually only (the details are to be confirmed).
• The radio (RRC/RAN) side details — RRC connection establishment and radio resource allocation are kept at the conceptual level, and the focus is on the core's involvement (radio side / implementation-dependent).
• The session handling on the SMF/UPF side — we do not go deep into the user-plane handling that accompanies a registration update, and focus on the core registration-update procedure.

Why — why Mobility Registration Update is necessary¶

Let's start from the Why (why it is needed). As long as a registered (5GMM-REGISTERED) UE moves inside its Registration Area (= its assigned TAI list), it need not report to the network each time. This is so that an idle (CM-IDLE) UE is not tracked per cell but managed at the granularity of "it should be somewhere in this area," thereby reducing registration-update signaling and saving power (this is the flip side of the Registration Area design in Paging).

However, when the UE moves outside that area, a problem arises. The UE is no longer within the range (the Registration Area) that the network believes it "should be around." Leaving this state as is causes the following inconveniences.

• Incoming calls do not arrive — Paging calls out to the range of the Registration Area (TAI list), but since the UE is outside that range, the call does not reach it.
• The location information stays stale — the network's held serving information for the UE diverges from reality.

Mobility Registration Update is the procedure by which the UE declares "I have moved; please re-register me in the new area," and the network reassigns a new Registration Area (TAI list) and updates the location information. With this, the UE can continue to receive calls, originate calls, and communicate data even at the destination.

Overview¶

Mobility Registration Update broadly occurs in the following flow.

The UE moves and detects that its serving TA (Tracking Area) is not included in the assigned TAI list → the UE sends a Registration Request (Registration type = mobility registration updating) to the AMF via the gNB (N1/N2) → the AMF checks the existing UE context (re-authentication and UDM lookup are conditional if needed) → the AMF determines a new Registration Area (TAI list) → the AMF responds with a Registration Accept, notifying the new TAI list and (if needed) a new 5G-GUTI → the UE returns a Registration Complete, and it is done.

The Registration type is a category indicating the "purpose" of the same Registration procedure. Of these, this chapter corresponds to mobility.

Basic Concept — a beginner-friendly explanation¶

To understand Mobility Registration Update, grasp three keywords.

1. The Registration Area and movement (why an update is required when you leave it)¶

The Registration Area is a list of TAIs (Tracking Area Identity) that the AMF assigns to the UE. It is notified to the UE at registration accept (Registration Accept) time (this definition is kept strictly aligned with Paging).

• As long as the UE moves inside this area, it need not update its registration each time (= reduced signaling and power saving).
• Because the network does not track the UE per cell, on an incoming call it pages the entire Registration Area with Paging.
• When the UE moves outside the area, Paging no longer reaches it. So it obtains a new area (a new TAI list) via Mobility Registration Update.

The UE side constantly checks whether or not its serving TA is included in its assigned TAI list. The moment it is no longer included is the trigger that starts Mobility Registration Update.

2. The differences between Registration types (initial / mobility / periodic)¶

Even in the same "Registration" procedure, the purpose and branching differ by Registration type.

• initial registration — the UE registers for the first time, e.g. after power-on. Identity verification (authentication) and subscriber-data retrieval are done fully. → Initial Registration
• mobility registration updating — the update when an already-registered UE moves outside its Registration Area. Because it can reuse the existing context, it can be simplified (the subject of this chapter).
• periodic registration updating — even if the UE has not moved, it periodically updates ("I am still alive") when the periodic timer expires. It plays a liveness-check role for the network to detect the UE's departure (for details, see Periodic Registration Update).

3. The differences from Initial Registration (what is skipped and what is updated)¶

Mobility Registration Update is "a different variant of the registration procedure," but it does not redo everything that Initial Registration does. This is because the UE is already registered with the network and a UE context (security context, subscriber information, 5G-GUTI, etc.) exists.

Architecture¶

The elements involved in Mobility Registration Update and the interfaces that connect them. The main actor is the AMF, and UDM / AUSF are conditional (involved only when re-authentication or a subscription-info lookup is required). The context transfer from the old AMF when an AMF change (AMF re-selection) occurs is expressed conceptually with dashed lines and annotations, because it is Release/configuration dependent.

flowchart LR
    UE(("UE
(REGISTERED)")) ---|"N1 (NAS): Registration Request
type=mobility"| AMF
    UE -. "RRC (radio side, out of scope)" .- RAN["(R)AN / gNB"]
    RAN ---|"N2 (NGAP)"| AMF["AMF
(registration-update processing
TAI-list reassignment)"]
    AMF -.->|"N12 (conditional: re-authentication)"| AUSF["AUSF
(conditional)"]
    AMF -.->|"N8 (conditional: subscription info)"| UDM["UDM
(conditional)"]
    AMF -. "On AMF change: context transfer
(Rel/config dependent, conceptual)" .- oldAMF["old AMF
(only on AMF change)"]

    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,oldAMF cond;

The role of each element is as follows.

• UE — the terminal that moved. It detects that its serving TA has fallen outside the assigned TAI list and sends a Registration Request (type = mobility registration updating). 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. It may perform AMF selection.
• AMF — the command center of the registration update. It checks the existing UE context, reassigns a new Registration Area (TAI list), reassigns the 5G-GUTI if needed, and responds with a Registration Accept.
• AUSF (conditional) — involved in authentication processing such as 5G-AKA (N12) only when re-authentication is required. It is not involved when the existing security context is reused.
• UDM (conditional) — involved (N8) only when (re-)retrieval of subscriber information or an AMF registration update is required. It may also be involved on an AMF change.
• old AMF (only on AMF change) — if AMF re-selection occurs, the new AMF may transfer the UE context from the old AMF (Rel/configuration dependent, conceptual only; the details are to be confirmed).

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 Mobility Registration Update. The gNB is on the radio-access side and is not a core NF (this table is limited to core NFs). UDM / AUSF are conditional (only when needed).

Interface / Protocol¶

The interfaces and protocols used in this procedure. N8 / N12 are conditional (only when re-authentication, a subscription-info lookup, or an AMF registration update is required).

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 Mobility 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 fine details of the section numbers are to be confirmed). It emphasizes the point that the authentication and subscriber-retrieval steps present in Initial Registration are conditional / can be simplified in this procedure.

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

    Note over UE: Serving TA outside the assigned TAI list → start registration update
    Note over UE,RAN: RRC connection establishment/resumption (radio side, outline/out of scope)
    UE->>RAN: Registration Request (NAS)
type=mobility registration updating
    Note right of UE: TS 24.501 §5.5.1. 5GS registration type=mobility (to be confirmed)
    RAN->>AMF: Put NAS onto Initial UE Message (NGAP)
    Note right of RAN: N2 / TS 38.413. May perform AMF selection

    Note over AMF: Check the existing UE context (resolved by 5G-GUTI)

    opt On AMF change (AMF re-selection, Rel/config dependent, conceptual)
        AMF->>AMF: Transfer UE context from the old AMF (to be confirmed)
    end

    opt Conditional: re-authentication (situation dependent)
        AMF->>AUSF: Nausf_UEAuthentication (re-authentication, N12)
        AMF->>UE: Authentication Request / Response (5G-AKA, details in a separate chapter)
    end

    opt Conditional: subscription-info lookup / AMF registration update (situation dependent)
        AMF->>UDM: Nudm_UECM_Registration / Nudm_SDM_Get (N8)
        UDM-->>AMF: Subscriber data (when needed)
    end

    Note over AMF: Determine the new Registration Area (TAI list)
    AMF->>UE: Registration Accept (NAS)
new TAI list / (if needed) new 5G-GUTI
    Note right of AMF: TS 24.501 §5.5.1. registration result, etc.

    opt On 5G-GUTI reassignment
        UE->>AMF: Registration Complete (NAS)
        Note right of UE: ACK on new 5G-GUTI assignment, etc.
    end
    Note over UE,AMF: Registration Area update complete while maintaining 5GMM-REGISTERED

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

1. UE→(R)AN: the UE detects that its serving TA has fallen outside the assigned TAI list, establishes/resumes an RRC connection (on the radio side) (outline / out of scope), and carries the Registration Request (NAS) with Registration type = mobility 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). At the same time it may perform AMF selection.
3. AMF's decision (context check): the AMF resolves the existing UE context from the 5G-GUTI and starts the update processing. Unlike Initial Registration, being able to reuse the existing security and subscription info here is the basic case.
4. (Conditional / on AMF change) context transfer: if AMF re-selection occurs, the new AMF may transfer the UE context from the old AMF (Rel/configuration dependent, conceptual only; the details are to be confirmed).
5. (Conditional) re-authentication: only when the existing security context cannot be reused, etc., the AMF→AUSF re-authentication (5G-AKA, N12) is performed. It can be omitted (situation dependent; the details are the subject of the Security/Authentication chapter).
6. (Conditional) subscription-info lookup / AMF registration update: only when the subscription info changed, the AMF changed, etc., the AMF→UDM (Nudm_UECM_Registration / Nudm_SDM_Get, N8) is performed. It can be omitted (situation dependent).
7. Determine the new Registration Area: the AMF determines a new Registration Area (TAI list). It assigns the group of TAs that covers the UE's current location.
8. Accept: with AMF→UE Registration Accept (NAS), it notifies the new TAI list and (if needed) a new 5G-GUTI, registration result, etc.
9. (On 5G-GUTI reassignment) complete: when a new 5G-GUTI has been assigned, etc., the UE→AMF Registration Complete (NAS) is returned. This is a completion confirmation, and the UE maintains 5GMM-REGISTERED throughout the procedure (it 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 IE names, type values, and operation names are version/implementation dependent and are marked to be confirmed.

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

State Machine¶

The viewpoint of the UE-side 5GMM state. Mobility Registration Update updates the Registration Area while maintaining 5GMM-REGISTERED (basis: TS 24.501 §5.1.3 / §5.5.1 series, section numbers to be confirmed). Unlike Initial Registration, which transitions DEREGISTERED → REGISTERED, the key point is that this procedure is an update within REGISTERED.

stateDiagram-v2
    [*] --> REGISTERED: After Initial Registration completes
    REGISTERED --> REGISTERED_UPDATE: Send Registration Request (type=mobility)
    REGISTERED_UPDATE --> REGISTERED: Receive Registration Accept (apply new TAI list)
    REGISTERED_UPDATE --> DEREGISTERED: Receive Registration Reject / procedure failure
    REGISTERED --> DEREGISTERED: De-registration / registration lapse
    DEREGISTERED --> [*]

• 5GMM-REGISTERED — registered. Movement within the Registration Area does not change the state. Leaving the area and sending a registration update moves it to the transient update state.
• 5GMM-REGISTERED (updating / transient) — the transient state after sending a Registration Request (type=mobility) and waiting for a response (illustrated as REGISTERED_UPDATE in the diagram above). It applies the new TAI list with a Registration Accept and returns to REGISTERED. On Registration Reject / procedure failure it may transition to DEREGISTERED.
• 5GMM-DEREGISTERED — not registered. It may be reached via De-registration, registration lapse, an update failure (Reject), etc.

Packet Analysis (Wireshark)¶

The key points when analyzing Mobility Registration Update with Wireshark. On the core side, the NAS Registration Request/Accept are observed nested inside NGAP (Initial UE Message, etc.).

Key Display Filters¶

Points to note when decoding (key IEs)¶

• NAS Registration Request (UE→AMF) — note the following IEs (IE names are representative notation, to be confirmed).
  • 5GS registration type — this being mobility registration updating is the decisive point of this procedure (for Initial Registration it is initial registration). The value's code is to be confirmed.
  • 5GS mobile identity — in Mobility Registration Update this is typically the 5G-GUTI (different from the SUCI of initial registration).
  • Requested NSSAI / UE security capability — the requested slices and supported algorithms.
• NAS Registration Accept (AMF→UE) — note the following IEs.
  • TAI list (new Registration Area) — the reassigned new TAI list. The main focus of this procedure.
  • 5G-GUTI (on reassignment) — a new temporary ID (when reassigned).
  • registration result, etc.

The message nesting structure (NAS nested inside NGAP)¶

The NAS of the Registration Request goes as a NAS-PDU inside an NGAP message (Initial UE Message) (the same nested structure as Initial Registration / Service Request). 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=mobility)

Configuration¶

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

Registration Area / TAI-list design (AMF side)¶

• TAI / TAC (Tracking Area) — defines the TAs the AMF serves. They must match the TA of the gNB. Without multiple TAs/gNBs, you cannot reproduce movement across areas (= Mobility Registration Update) in the first place.
• The assignment policy of the Registration Area (TAI list) — the range of the TAI list assigned to the UE. Making it wide reduces registration updates but widens the Paging range; making it narrow does the opposite (the trade-off in Basic Concept / Paging). The specific assignment algorithm is implementation-dependent.
• GUAMI / 5G-GUTI assignment — the 5G-GUTI is derived from the AMF's GUAMI. The reassignment policy is implementation-dependent.

Related to the periodic registration update timer (for contrast)¶

• The periodic registration update timer (generally the periodic registration update timer called T3512 is said to correspond) — relates to the interval at which periodic Registration Update (out of scope of this chapter) is started. 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.

Trouble Shooting¶

Isolating typical Mobility Registration Update failures (general discussion). 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: "when you cross an area, report your location and update the tracking area." 4G's TAU (Tracking Area Update) corresponds to 5G's Mobility Registration Update.

Release differences¶

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

• Rel-15 — the foundations of the basic 5GC Registration procedures (the Registration types initial / mobility / periodic / emergency, the Registration Area, 5G-GUTI reassignment) were established. This chapter is within the scope of these Rel-15 foundations.
• RRC Inactive / RAN Notification Area (RNA) — a UE state introduced in Rel-15. When the UE is in RRC_INACTIVE, on the radio side there is a separate-layer procedure — the update (RNA Update) of the RAN Notification Area (RNA). This is a different concept from the core (AMF)-initiated registration update (Registration Area update), and is out of scope of this chapter (conceptual only; the details are to be confirmed).
• Registration optimization / signaling-reduction extensions — registration-related optimizations continued in each Release. The extent to which they are specifically woven into the Mobility Registration Update procedure itself is to be confirmed.
• Rel-16 / Rel-17 / Rel-18 (5G-Advanced) — the generations in which extensions such as slicing and power saving advanced. The specific differences to the registration-update procedure itself are to be confirmed.

3GPP Specification¶

FAQ¶

Summary¶

• Mobility Registration Update is the procedure that updates the registration information and location when a UE moves outside its Registration Area (TAI list). It corresponds to 4G's TAU (Tracking Area Update).
• The trigger is "movement into an area whose serving TA is not included in the assigned TAI list." The UE sends a Registration Request (type=mobility registration updating) to the AMF.
• The main actor is the AMF (checking the existing UE context, reassigning the new Registration Area (TAI list), and sending the Registration Accept). UDM / AUSF are conditional (only when re-authentication or a subscription-info lookup is required).
• The differences from Initial Registration are the key point. The existing context can be reused, and authentication and subscriber retrieval can be simplified/omitted (conditional). It updates the area while maintaining 5GMM-REGISTERED.
• 5G-GUTI reassignment may be done but is not mandatory (situation/implementation dependent). Context transfer on AMF change is Rel/configuration dependent and conceptual only (to be confirmed).
• Its purpose differs from Service Request (U-Plane re-establishment) and Paging (incoming-call paging). Mobility Registration Update is "the update of the registration info / location."
• The basis is TS 23.502 §4.2.2.2 series / TS 24.501 §5.5.1 series and §5.1.3 / TS 23.501 §5.3 series / TS 38.413 (some section numbers, IE names, and the registration type value are to be confirmed).

Practice — comprehension check and exercises¶

Comprehension check¶

Exercises¶

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

A. The AMF determines a new Registration Area (TAI list)
B. UE → gNB: Registration Request (NAS, type=mobility) (after RRC establishment)
C. AMF → UE: Registration Accept (new TAI list / (if needed) new 5G-GUTI)
D. gNB → AMF: carry the NAS in an Initial UE Message (NGAP)
E. The AMF checks the existing UE context from the 5G-GUTI
F. (Conditional) The AMF performs re-authentication (N12) / UDM lookup (N8)
G. (On 5G-GUTI reassignment) UE → AMF: Registration Complete (NAS)

Next Step¶

The next steps to deepen your understanding.

• Prerequisite for the procedure: Initial Registration (the overall picture of registration, authentication, and security)
• Directly related: Paging (the upstream concept of the Registration Area; a missed update leads to Paging non-delivery)
• Related by contrast: Service Request (U-Plane re-establishment; a sister procedure with a different purpose)
• Sister procedure: Handover (connection switching while moving)
• Periodic Registration Update chapter (periodic registration update = a different Registration type; the trigger is time = periodic timer expiry)
• Related NFs: AMF / UDM / AUSF
• Related Interfaces: N1 / N2
• Dictionaries: Message Dictionary / Timer Dictionary / Cause Dictionary / Protocol Dictionary / NF Dictionary / Interface Dictionary