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
• Distinguish the UE-side Forbidden TA lists from the network-side Forbidden Area (Mobility Restriction), and isolate TAI List / T3512 / TAC configuration mismatches from a trace

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

IP Reachability
      ↓
SCTP Association
      ↓
NG Setup              ← Supported TA List (TAs served by the gNB)
      ↓
UE-associated NGAP    ← User Location Information in Initial UE Message (the TAI the UE is in now)
      ↓
Registration (NAS)    ← TAI List in Registration Accept (Registration Area allocated by the AMF)

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 Clause 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 Clause 6.2.2 / Clause 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)                      … TS 38.413 Clause 9.3.1.16 (to be confirmed)
├─ User Location Information E-UTRA   (under an ng-eNB)
├─ User Location Information NR       (under a gNB)
│   ├─ NR CGI   (M)  PLMN + NR Cell Identity 36 bits
│   ├─ TAI      (M)  PLMN + TAC
│   └─ Age of Location (Time Stamp) etc.  (O)
└─ User Location Information N3IWF    (non-3GPP access; IP address and port)

• User Location Information is a CHOICE type whose contents differ per access type. For NR, NR CGI and TAI are both mandatory; everything else (Age of Location indicating how fresh the location is, PSCell Information / NID from Rel-16 onward, etc.) is optional. From Rel-16 onward, alternatives for TNGF / TWIF / W-AGF have also been added (the presence of each IE and the Release in which it was added are to be confirmed in TS 38.413 Clause 9.3.1.16).
• In the Initial UE Message, User Location Information is a mandatory IE (TS 38.413 Clause 9.2.5.1, to be confirmed). In other words, by the time the AMF receives the UE's first NAS message, it already knows the TAI the UE is in. UE-associated messages such as Uplink NAS Transport also deliver the latest value each time.
• If the AMF wants to keep track of cell / TA changes during CM-CONNECTED, it can send Location Reporting Control to the NG-RAN and have it report via Location Report (TS 23.502 Clause 4.10 / TS 38.413 Clause 8.12, sub-clauses to be confirmed). The kinds of reporting events (report immediately, on change of serving cell, etc.) are specified by the NGAP Location Reporting Request Type (TS 38.413 Clause 9.3.1.65, to be confirmed). In which situations reporting is requested depends on requests from other NFs (SMF / PCF, etc.) and on AMF implementation / operation (TS 23.502 Clause 4.10).

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 Clause 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 Clause 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 Clause 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 Clause 8.2.7 / Clause 9.11.3.9). Internally, the IE is a sequence of "partial tracking area identity lists," and the Type of list field (bits 7–6) in the first octet of each partial list determines the format of what follows (TS 24.501 Clause 9.11.3.9).

First octet of a partial list
 bit:   8      7   6        5   4   3   2   1
      ┌─────┬──────────┬─────────────────────┐
      │spare│Type of   │ Number of elements  │
      │     │list      │ (coded as N−1)      │
      └─────┴──────────┴─────────────────────┘

• Number of elements is coded as "number of elements − 1" (00000 = 1 element … 01111 = 16 elements). Whether Wireshark displays the coded value or the element count depends on the version, so compare against the raw bits (including handling of out-of-range values, to be confirmed in TS 24.501 Clause 9.11.3.9).
• Multiple partial lists can be placed in one IE (e.g. a run of TACs in PLMN A + a single TAI in PLMN B). However, the IE as a whole can contain at most 16 TAIs (TS 24.501 Clause 9.11.3.9). The IE length is a minimum of 9 octets and a maximum of 114 octets (TS 24.501 Clause 9.11.3.9, to be confirmed).
• Because the TAC is 3 octets in 5GS (2 octets in EPS), the byte string is not identical to the EPS TAI list IE (TS 24.301 Clause 9.9.3.33).
• The handling of Type of list values other than the above, including 11, and Release-dependent differences such as those related to SNPN (Rel-16 onward) are to be confirmed.

The UE may include the Last visited registered TAI (TS 24.501 Clause 8.2.6 / Clause 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 Clause 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 Clause 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 Clause 8.5.1 / Clause 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 Clause 5.4.3, to be confirmed).

For details, see Paging / Service Request. The CM-IDLE → CM-CONNECTED transition and the Service Request IEs are covered in depth in the next chapter (CM-IDLE / CM-CONNECTED and 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 Clause 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 Clause 5.3.7 / Clause 5.5.1.3.2).

Registration Accept (may convey a T3512 value)
   ↓ NAS signalling connection released (5GMM-CONNECTED → 5GMM-IDLE) → T3512 starts
   ↓ expires while still in 5GMM-IDLE
Periodic Registration Update
   (if the UE enters 5GMM-CONNECTED in between, T3512 stops and restarts from its initial value the next time the UE returns to IDLE)

• The start / stop conditions of T3512 are in TS 24.501 Clause 5.3.7. The key point is that it only ticks while in 5GMM-IDLE: a UE that stays in CM-CONNECTED (including RRC_INACTIVE) for a long time does not send Periodic Registration Updates during that time (details of the handling during RRC_INACTIVE are to be confirmed).
• The T3512 value IE uses the GPRS timer 3 format (TS 24.501 Clause 9.11.2.5 → TS 24.008 Clause 10.5.7.4a, to be confirmed) and is expressed as "unit + value". One of the unit values indicates deactivated (timer disabled), in which case the UE does not perform Periodic Registration Update (TS 24.501 Clause 5.3.7, to be confirmed).
• UE behavior when the AMF does not include a T3512 value, and the handling of T3512 in MICO mode etc., are to be confirmed in TS 24.501 Clause 5.3.7 / Clause 5.3.6 (MICO mode). The value used in operation (how many minutes) is operator configuration / AMF implementation dependent.
• On the AMF side, if no Periodic Registration Update arrives and the Mobile reachable timer → Implicit De-registration timer expire, the AMF implicitly deregisters the UE (TS 24.501 Clause 5.3.7, to be confirmed).

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 Clause 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 Clause 5.3.13).

For the exact per-cause UE behavior (5GMM state, counters, conditions for adding to a list, etc.), see the per-cause descriptions in TS 24.501 Clause 5.5.1.2.5 (Initial) / Clause 5.5.1.3.5 (Mobility / Periodic) (to be confirmed).

The Forbidden TA lists have an operationally important property: once an entry is added, it stays for a while (TS 24.501 Clause 5.3.13; removal on receipt of a TAI List: Clause 5.5.1.2.4 / Clause 5.5.1.3.4; all to be confirmed).

• The lists are erased when the UE is switched off, when the USIM is removed, and periodically (in the range of 12 to 24 hours)
• A TAI is removed from the lists when it is received in the TAI List of a Registration Accept
• Therefore, if a network-side misconfiguration returns #12 / #13 / #15, UEs that have already added the TAI to their list may not attempt normal registration in that TA for a while, even after the configuration is fixed

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 Clause 5.3.4.1). For UE-side handling of Service Area Restriction, see TS 24.501 Clause 5.3.5 (to be confirmed).

When you see the word "Forbidden" in a trace, first distinguish whether it refers to the UE-side lists or the network-side Mobility Restriction.

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) (not an actual capture). 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 Clause 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 (coded value in the bits is N−1 = 2)

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).

Pitfalls when building the comparison table:

• Decimal vs hexadecimal confusion: whether TACs are written in decimal or hexadecimal in configuration screens and CLIs is product dependent. If TAC "1131" is decimal it is 0x00046B; if it is hexadecimal 0x1131 it is 4401 in decimal — a different TA. Normalize to the value in the trace (24 bits) before comparing.
• Number of MNC digits: "440-11" with a 2-digit MNC and "440-011" with a 3-digit MNC are different PLMNs (TS 23.003 Clause 2.2 / Clause 12.1, to be confirmed). Check which notation the configuration or log uses.
• The Last visited registered TAI in the Registration Request is not "where the UE is now": it is the TA in which the UE was last registered, and in a Mobility Registration Update it normally differs from the new TA. Check "the TAI the UE is in now" in the NGAP User Location Information (the Last visited registered TAI is a non-cleartext IE, so it may need deciphering).

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 Clause 16.14, TS 23.501 Clause 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¶

TAC (Tracking Area Code, 24 bits)
   + PLMN ID (MCC + MNC)
   ↓
TAI (Tracking Area Identity)

TAI #1 ─┐
TAI #2 ─┼──► TAI List = Registration Area (per UE, at most 16 TAIs)
TAI #3 ─┘

• 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. T3512 only runs in 5GMM-IDLE, and "deactivated" can also be signalled
• The Forbidden TA lists (UE side; added on #12 / #13 / #15 and kept for a while) and the network-side Forbidden Area (Mobility Restriction) are different things
• 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¶

• Next chapter: how a UE woken up by Paging returns to CM-CONNECTED → CM-IDLE / CM-CONNECTED and Service Request
• 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
• Timers such as T3512 → Timer Dictionary / 5GMM causes in general → Cause Dictionary