Tracking Area / TAI / Registration Area — How the 5GC Keeps Track of Where a UE Is¶

Learning objectives¶

After reading this chapter, you will be able to:

• Explain the difference between TAC and TAI (TAI = PLMN ID + TAC) at the format level
• Explain through which path the UE and the AMF each learn the TA (SIB1 / NG Setup / User Location Information)
• Explain what a Registration Area (TAI List) is, and why moving within the Registration Area does not necessarily require a Mobility Registration Update
• Distinguish the 5GS registration type (Initial / Mobility / Periodic, etc.) and infer from a trace "why this Registration arrived"
• Explain that the size of the Registration Area is a trade-off between Registration Update frequency and Paging load

Prerequisites¶

• NG Setup Procedure — the gNB declares its TAs to the AMF in the Supported TA List
• Registration — basics of Registration Request / Accept
• Supplementary: Paging / Mobility Registration Update / Periodic Registration Update / RRC Resume

Why — why not track location per cell?¶

If the AMF tried to always know a UE's location per cell, the UE would have to report to the network every time it moved to another cell. For an idle (CM-IDLE) UE, that wastes battery and radio resources.

Conversely, if the AMF knew nothing about a UE's location, it would have to page across the whole network for every incoming call or downlink data, and the Paging load would be enormous.

So 5GS manages the location of CM-IDLE UEs in coarse units: a Tracking Area (TA), which groups multiple cells, and a Registration Area, which further groups multiple TAs (TS 23.501 §5.3.2.3).

Analogy: A Registration Area is "the delivery district you tell the courier about." The UE only says "I am somewhere in this district" and does not call in every time it moves within the district. When a parcel (incoming call) arrives, the courier calls out across the district (Paging). Only when the UE leaves the district does it register a new district (Mobility Registration Update).

What — TA / TAC / TAI / Registration Area¶

Tracking Area¶

A Tracking Area is a set of cells used to manage the location of CM-IDLE UEs. As a baseline, a cell belongs to one TA (per PLMN) (the NTN exception is covered later).

             Tracking Area (TAC = 0x000064)
 ┌──────────────────────────────────────┐
 │  Cell A   Cell B   Cell C            │
 │  Cell D   Cell E   Cell F            │
 └──────────────────────────────────────┘

TAC and TAI — not the same thing¶

TAI
├─ PLMN ID
│   ├─ MCC   (3 digits)
│   └─ MNC   (2–3 digits)
└─ TAC       (24 bits)

A TAC alone is not unique across PLMNs. What uniquely identifies a TA, including across networks and in roaming, is the TAI. If a trace only says "TAC=100," always check which PLMN's TAC 100 it is.

How the UE learns the TA — SIB1¶

The UE learns the PLMN and TAC of a cell from PLMN-IdentityInfo (the list of PLMN IDs and the trackingAreaCode) in SIB1 broadcast by the gNB (TS 38.331 §6.2.2 / §6.3.2, to be confirmed).

gNB ──(SIB1: PLMN-IdentityInfoList)──► UE
          ├─ PLMN-Identity: 440-11
          └─ trackingAreaCode: 0x000064

The UE compares the TAI of its serving cell with the TAI List it holds, to decide whether it is inside its Registration Area.

How the AMF learns the TA — two paths¶

User Location Information (CHOICE)
└─ User Location Information NR
    ├─ NR CGI   (PLMN + NR Cell Identity 36 bits)
    ├─ TAI      (PLMN + TAC)
    └─ Time Stamp etc. (optional)

Registration Area and TAI List¶

The AMF allocates to the UE a Registration Area made up of one or more TAs, and notifies the UE of that set of TAIs over NAS as the TAI List (TS 23.501 §5.3.2.3).

Registration Area (allocated to UE-1)
┌────────┐ ┌────────┐ ┌────────┐
│ TA 100 │ │ TA 101 │ │ TA 102 │
└────────┘ └────────┘ └────────┘
          ↓ notified over NAS
TAI List = { 440-11/100, 440-11/101, 440-11/102 }

• A Registration Area is allocated per UE. Two UEs in the same cell may hold different TAI Lists. When allocating, the AMF may take into account the UE's Mobility Pattern, Allowed / Non-Allowed Area, etc. (TS 23.501 §5.3.2.3). How it uses them is AMF implementation / operation dependent.
• For non-3GPP access, the Registration Area is a single reserved N3GPP TAI (TS 23.501 §5.3.2.3, to be confirmed).

Representation on NAS — the 5GS tracking area identity list IE¶

The TAI List is carried in the 5GS tracking area identity list IE included in Registration Accept, etc. (TS 24.501 §8.2.7 / §9.11.3.9). Internally, the IE is a sequence of "partial tracking area identity lists," each encoded in one of the following three formats (TS 24.501 §9.11.3.9, to be confirmed).

Other values are reserved. Differences between Releases, such as the extension to SNPN from Rel-16 onward, are to be confirmed.

There is also an upper limit on the number of TAIs in a TAI List (16, TS 24.501 §9.11.3.9, to be confirmed).

The UE may include the Last visited registered TAI (TS 24.501 §8.2.6 / §9.11.3.8) in the Registration Request, from which the AMF can learn "the TA in which the UE was last registered." Note, however, that this IE is not a cleartext IE, so when a valid NAS security context exists it is carried encrypted inside the NAS message container (TS 24.501 §4.4.6, to be confirmed).

How — how location management works¶

Location granularity per CM state¶

For RRC_INACTIVE details, see RRC Resume / Small Data.

Downlink to a CM-IDLE UE — Paging within the Registration Area¶

A CM-IDLE UE has no N2/N3 connection, so downlink data cannot be delivered as is. The AMF sends Paging to the gNBs serving the TAs included in the UE's Registration Area (TS 23.502 §4.2.3.3).

sequenceDiagram
    participant DN as Internet
    participant UPF
    participant SMF
    participant AMF
    participant gNB
    participant UE
    DN->>UPF: Downlink Data
    UPF->>SMF: Data Notification (N4)
    SMF->>AMF: Namf_Communication_N1N2MessageTransfer
    Note over AMF: UE is CM-IDLE → select gNBs serving TAs in the Registration Area
    AMF->>gNB: NGAP Paging (TAI List for Paging)
    gNB->>UE: RRC Paging
    UE->>AMF: Service Request (NAS)
    Note over UE,AMF: CM-CONNECTED → re-establish the User Plane

• NGAP Paging carries the TAI List for Paging (mandatory IE), and the gNB pages over the radio in its own cells belonging to those TAs (TS 38.413 §8.5.1 / §9.2.4.1, to be confirmed).
• The AMF can decide "which gNBs to send Paging to" because it remembers the gNB⇔TA mapping from the Supported TA List in NG Setup (previous chapter).
• Paging strategies such as "page the last known cell / TA first and widen the area if there is no response" depend on operator configuration and AMF implementation (TS 23.501 §5.4.3, to be confirmed).

For details, see Paging / Service Request.

Leaving the Registration Area — Mobility Registration Updating¶

When the UE detects that it has entered a TA not included in its TAI List, it sends a Registration Request with Registration type = mobility registration updating (TS 24.501 §5.5.1.3.2).

TAI List = {100, 101, 102}

TA100 → TA101 → TA102 → TA200
 (in)    (in)    (in)    (out) ← Mobility Registration Update here

For the full procedure, see Mobility Registration Update.

Even within the same Registration Area — Periodic Registration Updating¶

Even while staying within its Registration Area, the UE sends a Registration Request with Registration type = periodic registration updating when T3512 (the periodic registration update timer) expires (TS 24.501 §5.3.7 / §5.5.1.3.2).

Registration Accept (may convey a T3512 value)
   ↓ UE enters CM-IDLE → T3512 starts
   ↓ expiry
Periodic Registration Update

Periodic Registration Update is a liveness check that tells the AMF "the UE is still in coverage and its registration is alive." For details, see Periodic Registration Update.

5GS registration type — the first IE to check in a trace¶

When you see a Registration Request, first check the 5GS registration type (TS 24.501 §9.11.3.7).

From Rel-17 onward, values such as SNPN onboarding registration have been added (to be confirmed). The same IE also contains the Follow-on request pending (FOR) bit, indicating whether the UE wants to keep the NAS signalling connection after registration.

"A Registration Request arrived" is not enough information. Whether it is Initial, Mobility or Periodic completely changes which causes you should suspect.

Forbidden Tracking Areas and Mobility Restrictions¶

The UE keeps lists of TAs it should not use (TS 24.501 §5.3.13, to be confirmed).

For the per-cause UE behavior (which list to add to, whether to search for another TA / PLMN, etc.), see the per-cause descriptions in TS 24.501 §5.5.1.2.5 (Initial) / §5.5.1.3.5 (Mobility / Periodic) (to be confirmed).

On the network side, Mobility Restrictions based on subscription (RAT Restriction, Forbidden Area, Service Area Restriction (Allowed Area / Non-Allowed Area), etc.) are applied. Of these, Forbidden Area and Service Area Restriction are expressed per TA (TS 23.501 §5.3.4.1). For UE-side handling of Service Area Restriction, see TS 24.501 §5.3.5 (to be confirmed).

Registration Area design trade-off¶

The size of the Registration Area itself is a design parameter whose value 3GPP does not fix (how it is allocated is AMF implementation / operation dependent; however, the upper limit on the number of TAIs in a TAI List is fixed by the IE format).

flowchart LR
    S["Small Registration Area
(few TAIs)"] --> S1["Mobility Registration Update ↑
(more UE battery use / NAS signaling)"]
    S --> S2["Paging area ↓
(fewer gNBs paged per incoming call)"]
    L["Large Registration Area
(many TAIs)"] --> L1["Mobility Registration Update ↓"]
    L --> L2["Paging area ↑
(more radio / N2 Paging load)"]

Where to place TA boundaries (e.g. avoiding many boundaries along highways and railways) and tailoring TAI Lists per UE are also areas of operator design and implementation.

Packet Analysis (Wireshark)¶

Display Filter¶

Individual field names (e.g. registration type, TAC) differ between Wireshark versions, so this page does not assert them (to be confirmed). The reliable way is to right-click a field in the packet details and choose "Apply as Filter." Note that encrypted NAS cannot be read unless it can be deciphered.

What to look at¶

① NG Setup Request
   └─ Supported TA List          ← TAs served by the gNB (TAC + PLMN + S-NSSAI)

② Initial UE Message
   └─ User Location Information
      └─ NR CGI / TAI            ← where the UE actually is

③ Registration Request (NAS)
   ├─ 5GS registration type      ← Initial / Mobility / Periodic (cleartext IE)
   └─ Last visited registered TAI (optional, non-cleartext IE; may need deciphering)

④ Registration Accept / Reject (NAS)
   ├─ 5GS tracking area identity list  ← Registration Area allocated by the AMF
   ├─ T3512 value (optional)
   └─ 5GMM cause (for Reject)

Decode example (conceptual)¶

The following is a conceptual representation of the display structure; values are fictitious examples using the test PLMN (001-01) (capture needed). It assumes a NAS-deciphered display. The 5GS registration type is a cleartext IE, but the Last visited registered TAI is a non-cleartext IE. When a valid NAS security context exists, it is carried encrypted inside the NAS message container and cannot be seen without deciphering. When there is no valid context, the initial Registration Request contains only cleartext IEs, and the complete message is sent in the NAS message container of Security Mode Complete after NAS security is established (TS 24.501 §4.4.6, to be confirmed). In an actual display, the complete Registration request appears nested inside the NAS message container.

NGAP InitialUEMessage
 ├─ RAN-UE-NGAP-ID: 1
 ├─ NAS-PDU
 │   └─ Registration request
 │       ├─ 5GS registration type: mobility registration updating (2)
 │       └─ NAS message container (deciphered)
 │           └─ Registration request (complete)
 │               └─ Last visited registered TAI: 001-01, TAC 0x000064
 └─ UserLocationInformation
     └─ userLocationInformationNR
         ├─ nR-CGI: 001-01, NR Cell Identity 0x000000010
         └─ tAI: 001-01, TAC 0x0000c8

NAS Registration accept
 └─ 5GS tracking area identity list
     └─ Partial TAI list: type = 01 (consecutive)
         ├─ PLMN: 001-01
         ├─ TAC: 0x0000c8
         └─ Number of elements: 3   → TAC 200, 201, 202

Build a comparison table¶

For TA-related problems, lining up the values from four places makes the faulty spot easier to see.

In this example, the RAN side is consistently TAC 1131 while the AMF is configured with TAC 1132. Whether this is rejected at NG Setup, or accepted and then causes problems in Registration or Paging, is AMF implementation / configuration dependent (see the previous chapter).

Trouble Shooting¶

Tracking Areas in NTN (satellite access)¶

In satellite access (NR NTN, Rel-17 onward), cells may move over the ground as satellites move, making Tracking Area handling more complex than in terrestrial networks. For example, there are extensions such as a single cell possibly broadcasting multiple TACs per PLMN (TS 38.300 §16.14, TS 23.501 §5.4.11, sub-clauses to be confirmed). This chapter does not go into detail; just keep in mind that "the terrestrial assumption (one cell = one TA) does not apply as is."

Boundary between 3GPP specifications and vendor implementation¶

Comparison with EPC (4G)¶

The TA / TAI List concept in 5G is almost the same as in EPS. The major differences are that TAU has been folded into the Registration procedure (as a Registration type) and that the TAC has been extended to 24 bits.

3GPP Specification¶

Summary¶

• The TAC is a TA number within a PLMN (24 bits in 5GS); TAI = PLMN ID + TAC. They are not the same thing
• The UE learns the TA from SIB1; the AMF learns it from the Supported TA List (per gNB) and User Location Information (per UE)
• The AMF allocates a Registration Area (TAI List) per UE. For a CM-IDLE UE, the AMF can only guarantee presence at Registration Area granularity (the last reported TAI / cell may be kept as reference information)
• Moving outside the TAI List triggers Mobility Registration Updating. Moving between TAs within the Registration Area alone does not, though there are other triggers
• Even within the Registration Area, T3512 expiry triggers Periodic Registration Updating
• The size of the Registration Area is a trade-off between Registration Update frequency and Paging load (design is implementation / operation dependent)
• In traces, cross-check Supported TA List → User Location Information → TAI List / Cause, and in a Registration Request check the registration type first

Knowledge check¶

Next Step¶

• The N2 handshake that declares TAs → NG Setup Procedure
• The procedure triggered by moving outside the TAI List → Mobility Registration Update
• Periodic registration driven by T3512 → Periodic Registration Update
• Incoming calls to CM-IDLE UEs → Paging / Service Request
• RRC_INACTIVE and the RAN Notification Area → RRC Resume / Small Data
• NAS / NGAP messages and IEs → NAS Dictionary / NGAP Dictionary