Tracking Area Update in LTE 4G
How an idle UE keeps the MME informed of its location with periodic and mobility TAU.
An idle UE has no radio connection, yet the network must still be able to find it the instant a call or a packet arrives. The trick is granularity: rather than track every cell the UE visits, the MME only needs to know which Tracking Area it is camped in — and the UE only speaks up when that changes or when a keep-alive timer fires. The Tracking Area Update (TAU) is the procedure that keeps that location record fresh enough for paging to work, without flooding the signalling links on every cell reselection. This page is grounded in TS 24.301 (NAS/EMM) and TS 23.401 (EPS architecture and procedures).
Introduction
The Tracking Area Update is the location-management procedure of idle-mode LTE. It is a short NAS/EMM exchange between the UE and the MME whose only job is to keep the MME's record of where an idle UE is accurate enough that paging stays cheap. It is defined in TS 24.301 (the NAS protocol) and TS 23.401 (the EPS procedures around it).
It sits squarely in the EMM-REGISTERED / ECM-IDLE phase of the UE lifecycle — after attach, while the UE is camped and sleeping. The UE runs a TAU when it reselects out of its registered area (mobility), when a keep-alive timer fires (periodic), when a CS-Fallback UE must also refresh its 2G/3G location (combined), or after certain recovery and network-driven events. Each of these is the same three-message procedure with a different EPS update type.
Because a TAU is compact but can fan out into MME relocation, S-GW relocation, and optional security, its failures are localisable: they live in the request/accept exchange, in the S10 context fetch, in the gateway update, or in the timer machinery that supervises it. Walk it in order and the broken step tells you the cause.
On this page
Why the TAU is needed
In plain words: think of an idle UE as a friend who travels a lot but only texts you their city, not their exact street — and only when they cross into a new city. If you need to reach them, you call around that one city instead of the whole country. The TAU is that "I've moved cities" text, plus a periodic "still alive" check-in so you don't keep calling a number that's gone dead.
The network faces two opposing costs. Paging every cell in the PLMN to find one idle UE would swamp the air interface; forcing the UE to report every single cell change would swamp the S1 and NAS signalling links. Tracking Areas are the engineered compromise: the MME tracks the UE only to Tracking Area granularity, and the TAU keeps that coarse record fresh. It is the location-management half of idle mobility — paging finds the UE, the TAU keeps the search bounded.
A Tracking Area (TA) is a group of cells sharing one identity, the TAI (Tracking Area Identity = PLMN-ID + TAC, the Tracking Area Code broadcast in SIB1). The MME tracks an idle UE at TA granularity, never at cell granularity.
It balances two opposing costs: paging load (small TAs mean fewer cells to page per attempt) against update signalling (large or many TAs mean the UE reports its location less often). TAs let the operator dial in that trade-off.
The MME registers the UE in a TAI list — a set of TAIs. The UE stays silent as long as it camps on a cell whose TAI is in that list, and it runs a Tracking Area Update only when it moves outside all of them, or when its periodic timer expires.
Why Tracking Areas and the TAU Exist
When a UE moves to ECM-IDLE it releases the RRC connection and the eNB discards its context; only the MME still holds the UE's EPS Mobility Management (EMM) state. If downlink data or an incoming voice call arrives while the UE is idle, the MME has to page it — broadcast the UE's identity across a set of cells and wait for the UE to respond and re-establish a connection. Paging every cell in the PLMN would swamp the air interface, while forcing the UE to report every single cell change would swamp the S1 and NAS signalling links. Tracking Areas are the engineered compromise between those two costs.
The TAU is the location-management half of idle mobility: paging finds the idle UE, and the TAU keeps the MME's record accurate enough that the search stays bounded to a known, small set of cells. Everything else on this page is detail hanging off that single job.
Core idea: paging finds the idle UE; the TAU keeps the location record fresh enough for that search to stay bounded to a TAI list — without signalling on every cell reselection.
TAI, TAC and the TAI List
A TAI is built from the PLMN-ID (MCC + MNC, so the area is unambiguous across operators) plus a 16-bit TAC. Every cell advertises its TAC in SIB1, so a camped UE can always compute the TAI of its current cell and compare it against what it is registered in. If the MME registered the UE in a single TAI, a commuter sitting near the border between two TAs would ping-pong — running a TAU every time it drifted across the boundary. The TAI list solves exactly this.
Instead of one TAI, the MME hands the UE a set of them in the Tracking Area Update Accept (or Attach Accept). The UE compares the broadcast TAI of its current cell against the list: if it is present, the UE does nothing; only when the current TAI is in none of the listed areas does mobility trigger an update. This lets the MME shape each UE's "silence zone." A fast-moving UE on a motorway can be given a large TAI list to cut update frequency; a stationary fixed-wireless UE can be given a small one so paging stays cheap. Each time the UE does update, the MME issues a fresh TAI list in the accept, effectively re-centring the silence zone around the UE's new position.
Registered vs camped: a UE is registered in many TAs (its whole TAI list) while camped on exactly one cell. When a page is needed, the MME sends it to every eNB serving every TAI in the list, so the network never loses the UE anywhere inside its silence zone.
However the list is encoded — one PLMN, several PLMNs, or a compact run of consecutive TACs — the rule the UE applies is identical: membership of the current TAI means "stay quiet," absence means "run a mobility TAU."
What Triggers a TAU
A TAU is not a single event but a family of them, all carried by the same Tracking Area Update Request message with an EPS update type IE that tells the MME why the UE is updating. The three you must know cold are periodic, mobility, and combined; the rest are recovery and network-driven cases.
- Periodic TAU — a keep-alive. The
T3412timer (periodic TAU timer, whose value the MME gives the UE in the accept) counts down while the UE sits inEMM-REGISTERED/ECM-IDLE. On expiry the UE runs a periodic TAU (EPS update typeperiodic updating) to tell the MME "still here, still reachable," even though it has not moved. This is what lets the MME eventually clean up UEs that have silently vanished. - Mobility (normal) TAU — the UE reselects to a cell whose
TAIis not in its currentTAI list(EPS update typeTA updating). This is the classic "I have moved out of my registered area" case, and it is what keeps paging bounded as the UE roams. - Combined TA/LA updating — a UE configured for CS Fallback must also keep its 2G/3G Location Area registered. It sends a combined TAU so the MME, via the
SGsinterface to the MSC, updates the Location Area at the same time. - After handover into a new TA — a connected-mode handover can land the UE in a cell whose
TAIis outside the list; the UE runs a TAU once the handover completes. - Recovery / network-driven — the UE must re-establish EPS bearer context after a failure, ISR was deactivated, or MME load re-balancing pushed the UE toward a different MME. The EPS update type distinguishes these.
| TAU trigger / type | EPS update type | What causes it |
|---|---|---|
| Periodic TAU | periodic updating | T3412 expiry while idle — keep-alive proving the UE is still reachable. |
| Mobility (normal) TAU | TA updating | UE reselects a cell whose TAI is not in its TAI list — moved out of the registered area. |
| Combined TA/LA update | combined TA/LA updating | CSFB UE must also refresh its 2G/3G Location Area via the MME's SGs link to the MSC. |
| After handover | TA updating | Handover delivered the UE into a TA outside the list; TAU follows connection. |
| Bearer / context recovery | TA updating + active flag | UE must recover EPS bearer context, or wants the user-plane radio bearers re-established. |
| Load re-balancing / MME change | TA updating | Network steered the UE toward another MME; the TAU refreshes context on the new node. |
| ISR-related | TA updating | Return from UTRAN/GERAN, or (re)activation of Idle-mode Signalling Reduction. |
The Three Messages and Their IEs
The TAU is a compact NAS exchange of at most three EMM messages between the UE and the MME. The UE briefly leaves idle mode (an RRC connection is set up to carry the NAS message over S1), completes the update, and typically returns to ECM-IDLE.
Tracking Area Update Request— sent by the UE. It carries the EPS update type (why it is updating, plus the active flag), the oldGUTI(Globally Unique Temporary Identity, used instead of the permanent IMSI so the UE is not identified in clear), the last visited registeredTAI, UE network capabilities, and DRX parameters. The oldGUTIis the key routing datum: its embeddedGUMMEItells eNB and MME which MME previously served this UE.Tracking Area Update Accept— sent by the MME. It carries the EPS update result, a freshTAI list, timer values (notablyT3412, and optionallyT3402/T3423), optionally a newGUTI, and EPS bearer status so the UE and network can reconcile which bearers survive.Tracking Area Update Complete— sent by the UE, but only if the MME allocated a newGUTIin the accept. It confirms the UE has adopted the new identity. If no newGUTIwas assigned, the procedure ends at the accept.
The active flag: a bit inside the EPS update type of the request. Set to 1, it tells the MME the UE wants its user-plane radio and S1 bearers re-established as part of the TAU (it has, or expects, uplink data), so the network keeps the S1-U connection up instead of returning the UE straight to idle. Set to 0, the TAU is a pure location refresh and the UE drops back to ECM-IDLE as soon as it completes.
| Message | Direction | Key IEs |
|---|---|---|
Tracking Area Update Request | UE → MME | EPS update type (+ active flag), old GUTI, last visited TAI, UE network capability, DRX parameter, EPS bearer status. |
Tracking Area Update Accept | MME → UE | EPS update result, TAI list, T3412 (and optional T3402/T3423), optional new GUTI, EPS bearer status. |
Tracking Area Update Complete | UE → MME | (none) — sent only when a new GUTI was reallocated, to confirm adoption. |
Around these three EMM messages the MME may insert security: an authentication exchange (if it lacks a usable EPS security context) and a NAS security mode command to take the ciphering and integrity keys into use. A UE arriving with a valid context may skip both.
How the TAU is carried (channels & identity): the UE first sets up an RRC connection — a random-access run (Msg1–Msg4) followed by RRCConnectionSetup/Complete on SRB1, at which point the Tracking Area Update Request travels as the dedicatedInfoNAS payload. On S1 it becomes the NAS payload of the S1AP Initial UE Message, routed to an MME chosen from the GUMMEI carried inside the old GUTI. There is no dedicated "TAU channel" — it reuses the same RRC/S1AP transport every NAS message uses.
The Procedure Step by Step
Read the flow as: the UE wakes, sends its request over a freshly set-up RRC/S1 connection, the (possibly new) MME resolves the UE's context, the network optionally shuffles gateways, and the MME accepts. The figure shows the full case including MME relocation and S-GW relocation; strip out the grey arrows and you have the ordinary same-MME TAU.
1. Connection + Request. The UE sets up RRC and sends the Tracking Area Update Request as a NAS payload; the eNB forwards it to an MME (chosen from the old GUTI's GUMMEI) in an Initial UE Message. 2. Context fetch. If the serving MME changed, the new MME identifies the old MME from the old GUTI and fetches the UE context over the S10 interface (Context Request / Context Response / Context Acknowledge). 3. Security. The MME may run authentication and NAS security mode. 4. Gateway update. If the S-GW changes, the new MME sets up bearers on the new S-GW (Create Session) and updates the P-GW; otherwise it sends Modify Bearer to the existing S-GW. 5. Accept. The MME returns Tracking Area Update Accept with a new TAI list and T3412, optionally a new GUTI. 6. Complete. If a new GUTI was assigned, the UE replies Tracking Area Update Complete; otherwise the procedure ends and the UE returns to idle unless the active flag was set.
✅ Debugging steps
- Confirm the UE actually established RRC and that the S1AP
Initial UE Messagecarrying theTracking Area Update Requestreached an MME. - Read the EPS update type to classify the TAU (periodic / TA updating / combined) and check the active flag matches whether the UE expected the user plane back up.
- For an inter-MME case, verify the S10
Context Request/Response/Acknowledgecompleted — a missing context is the classic inter-MME TAU failure. - Check whether the MME inserted authentication / security mode, and that it completed before the accept.
- Confirm the
Tracking Area Update Acceptcarried a freshTAI listandT3412, and that aCompletefollowed only if a newGUTIwas assigned.
⚠ Common causes of failure
- S10 context fetch fails (old MME unreachable, or context purged), so the new MME rejects the TAU and forces a re-attach.
- TAU reject with a "hard" cause (e.g. implicit-detach conditions), making the UE locally deactivate bearers and re-attach.
- Security failure (authentication reject or NAS
MAC failure) inserted mid-procedure. - Accept never reaches the UE (poor DL, or connection released too early), so
T3430expires and the UE retries. - Gateway update fails (
Create Session/Modify Bearererror), so bearers cannot be re-anchored on relocation.
MME Relocation, S-GW Relocation and ISR
When a mobility TAU crosses into a TA served by a different MME pool, the MME itself changes — and the new MME does not yet hold the UE's context. This is where the old GUTI earns its keep. Its GUMMEI (Globally Unique MME Identifier = PLMN + MME Group ID + MME Code) tells the new MME exactly which old MME to ask. The new MME sends a Context Request over the S10 interface (MME-to-MME, using the GTP-C based Forward Relocation/context procedures), the old MME returns the UE's EMM and bearer context in a Context Response, and the new MME confirms with Context Acknowledge. Only after the acknowledge does the old MME consider its context transferable and eventually removable. Because the identity travelled inside the GUTI, none of this needs the permanent IMSI over the air.
S-GW relocation is the parallel move on the user plane. If the new MME decides the current S-GW no longer serves the UE optimally, it selects a new one, issues Create Session, and has it update the P-GW so downlink packets steer to the new S-GW; the old session is then torn down. If the S-GW does not change, the MME simply sends Modify Bearer to refresh the eNB/MME addressing. Either way the P-GW — the IP anchor — stays put, so the UE keeps its IP address throughout.
Why the GUTI is the pivot: old GUTI → GUMMEI → which old MME to fetch context from over S10; and the eNB also uses the GUMMEI to route the very first Initial UE Message to a sensible MME. The temporary identity is simultaneously the UE's privacy shield and the network's routing key.
ISR — Idle-mode Signalling Reduction — addresses a different waste. A UE at the boundary of E-UTRAN and UTRAN/GERAN can reselect back and forth between LTE and 2G/3G, and without ISR each crossing forces a fresh Tracking Area Update (LTE) or Routing Area Update (2G/3G), churning signalling. With ISR activated, the UE is registered in both a TA list (via the MME) and a Routing Area (via the SGSN) at once, and the S-GW knows both. The UE can then move between the two accesses without updating each time, as long as it stays within the registered TA list and RA. Paging is coordinated: the S-GW pages through both the MME and the SGSN so the UE is reachable on whichever radio it is camped on. ISR is negotiated, not assumed — the network signals whether it is activated in the TAU/RAU accept.
✅ Debugging steps
- Decode the old
GUTIto itsGUMMEIand confirm the eNB routed theInitial UE Messageto a reachable MME, and that the new MME picked the correct old MME for S10. - Trace the S10
Context Request/Response/Acknowledgetriplet — a missingAcknowledgecan leave the old MME holding stale context. - For S-GW relocation, verify
Create Sessiontoward the new S-GW and the P-GW update succeeded; for the same-S-GW case, verify theModify Bearer. - If reselection between LTE and 2G/3G churns signalling, check whether ISR was actually activated in the TAU/RAU accept — it is negotiated, not assumed.
⚠ Common causes of failure
- Old MME named by the
GUMMEIis unreachable or has purged the context, so the S10 fetch fails and the UE must re-attach withIMSI. - S10/S11 GTP-C errors during relocation, leaving bearers un-anchored on the new nodes.
- ISR assumed but never activated, so the UE keeps running a TAU/RAU on every inter-RAT reselection.
- P-GW update lost during S-GW relocation, so downlink packets keep steering to the old S-GW.
Periodic TAU, Timers and Implicit Detach
Mobility TAUs cover the UE that moves. But what about the UE that switches off in a dead spot, or whose battery dies mid-idle? Without a safeguard the MME would keep a stale context forever and waste paging attempts on a UE that is gone. The periodic TAU plus a supervising network timer solve this.
The UE runs T3412: while idle in EMM-REGISTERED it counts down, and on expiry the UE performs a periodic TAU — a heartbeat proving it is still reachable — then restarts the timer with the value the accept carried. On the network side the MME runs a longer mobile reachable timer, set a little larger than T3412, restarted on every UE contact. If the UE misses its periodic TAU and that timer expires, the MME starts T3423. If T3423 also expires with no contact, the MME performs an implicit detach: it deactivates the EPS bearers, drops the context, and stops paging — with no over-the-air signalling to the absent UE, which simply re-attaches when it returns.
| Timer | Runs on | Role |
|---|---|---|
T3412 | UE | Periodic TAU timer. On expiry the idle UE runs a periodic TAU. Value set by the MME in the accept; extended DRX/PSM negotiate much larger values. |
T3410 | UE | TAU attempt supervision — started when the request is sent, stopped on accept/reject. Its expiry means no answer. |
T3430 | UE | Guards the TAU procedure at the NAS layer while awaiting the network's response, akin to T3410 for the update transaction. |
T3402 | UE | Back-off before the next attach/TAU attempt after certain failures (default order of minutes); can be signalled by the MME. |
| Mobile reachable timer | MME | Network supervision, set a bit longer than T3412; restarted on any UE contact. Its expiry starts implicit-detach supervision. |
T3423 | MME | Implicit detach supervision. Started when the mobile reachable timer expires; if it expires too, the MME implicitly detaches the UE. |
Power-saving note: extended idle-mode DRX (eDRX) and Power Saving Mode (PSM) stretch how long an IoT UE can stay dormant. They work by negotiating a much larger T3412 (and, for PSM, an Active Time timer T3324) so the UE checks in far less often — trading reachability latency for battery life. The mobile reachable and implicit-detach timers scale up in step so the network does not prematurely detach a device that is merely sleeping.
Mental model: T3412 is the UE's heartbeat interval; the mobile reachable timer is the network's "no pulse yet" warning; T3423 is the grace period before the flatline call. A heartbeat missed past both means implicit detach, done silently.
✅ Debugging steps
- Read the
T3412value the MME gave in the accept and confirm the UE's periodic-TAU cadence matches it (allowing for eDRX/PSM stretching). - On a "UE unreachable" complaint, check whether the mobile reachable timer expired and
T3423ran — an implicit detach would explain paging that gets no response. - If TAUs are looping, look at
T3410/T3430expiries (no network answer) andT3402back-off between attempts. - For an IoT device, verify the network's supervision timers were scaled up in step with the negotiated large
T3412/T3324, or it will be detached while merely sleeping.
⚠ Common causes of failure
- Mismatched
T3412vs the MME's mobile reachable timer, so a still-present UE is implicitly detached prematurely. - Periodic TAU never sent (UE off, in a dead spot, or a wrong timer value), leading to implicit detach and missed pages.
T3402back-off after repeated failures making the UE appear "slow to recover" after a network outage.- PSM/eDRX negotiated on the UE but not honoured by the MME supervision timers, causing spurious detaches.
Reading the TAU in the logs
A TAU trace is short: an Initial UE Message carrying the request, an optional S10/security/gateway middle, and the accept (plus a complete if a new GUTI was assigned). The two fields that classify almost everything are the EPS update type (why) and the presence of a new GUTI (whether a Complete is expected). Below is a compressed MME-side view of an inter-MME mobility TAU.
Representative MME TAU trace — illustrative, values vary by vendor/build:
| Field | Meaning | Example (from log) | Check |
|---|---|---|---|
updateType | The EPS update type classifying the TAU. | TA-updating | Must match the scenario (periodic / TA / combined); a periodic type from a moved UE is suspicious. |
activeFlag | Whether the UE wants the user plane re-established. | 0 | 0 = pure location refresh (returns to idle); 1 = keep S1-U up for pending data. |
old-GUTI / GUMMEI | Presented identity and the MME that issued it. | MMEC=0x11 | The GUMMEI must point at a reachable old MME for the S10 context fetch. |
last-visited-TAI | The TA the UE last registered in. | 310-260-0x0007 | Should differ from the current TAI on a mobility TAU; equal values hint at a spurious update. |
Context Request/Response cause | S10 inter-MME context fetch outcome. | REQUEST_ACCEPTED | A failure here is the classic inter-MME TAU reject → forced re-attach. |
eKSI | Which NAS security context is in use. | 1 (reused) | A valid context lets the MME skip re-authentication; "no key" forces EPS-AKA. |
| Modify Bearer / Create Session | Gateway update on the user plane. | Modify Bearer (same S-GW) | Create Session instead means S-GW relocation; verify the P-GW was updated. |
updateResult | Outcome the MME returns in the accept. | TA-updated | A reject cause here (not an accept) tells you whether bearers survive or a re-attach is forced. |
new GUTI / TAU complete | Identity reallocation and its confirmation. | reallocated → complete | A Complete must appear only when a new GUTI was assigned; otherwise the procedure ends at the accept. |
T3412 | Periodic TAU timer handed to the UE. | 54min | Sets the next heartbeat; must be consistent with the MME's mobile reachable timer. |
Summary
The TAU is the location-management half of idle mobility: paging finds the UE, the TAU keeps that search bounded to a TAI list. To read or debug one, anchor on two fields — the EPS update type (why the UE is updating: periodic, mobility, combined, or recovery) and whether a new GUTI was reallocated (which decides if a Tracking Area Update Complete is expected) — then check the active flag to know whether the UE returns to idle or keeps the user plane up.
Walk the procedure in order and the broken step names the cause. Did the Initial UE Message reach an MME? On an inter-MME move, did the S10 Context Request/Response/Acknowledge succeed (the classic failure point)? Did optional security complete? Did the gateway update (Modify Bearer or Create Session) go through? Did the accept — and, if needed, the complete — arrive before T3410/T3430 expired? On the timer side, remember the heartbeat chain: T3412 (UE) → mobile reachable timer (MME) → T3423 (MME) → implicit detach.
Quick Q&A
Q. Why is the UE given a TAI list instead of a single TAI?
A. To cut TAU signalling. Registered in a set of TAs, the UE stays silent as long as it camps on any cell whose TAI is in the list, so it only runs a mobility TAU when it leaves all of them. This avoids ping-pong updates at TA borders and lets the MME tailor each UE's "silence zone" — large for fast movers, small for stationary UEs.
Q. What does the active flag in the Tracking Area Update Request do?
A. It is a bit in the EPS update type. Set to 1, it asks the MME to re-establish the user-plane radio and S1 bearers as part of the TAU (the UE has uplink data), keeping the connection up. Set to 0, the TAU is a pure location refresh and the UE returns to ECM-IDLE once it completes.
Q. When is a Tracking Area Update Complete actually sent?
A. Only when the MME reallocated the GUTI in the Tracking Area Update Accept. The Complete confirms the UE has adopted the new identity. If no new GUTI was assigned, the procedure ends at the accept.
Q. On an inter-MME TAU, how does the new MME get the UE's context without the IMSI?
A. From the old GUTI in the request. Its GUMMEI identifies the old MME; the new MME sends a Context Request over the S10 interface, gets the EMM and bearer context back in Context Response, and confirms with Context Acknowledge. The permanent IMSI never has to appear over the air.
Q. What happens if an idle UE never sends its periodic TAU?
A. The MME's mobile reachable timer (set a bit longer than T3412) expires, which starts T3423. If that also expires with no contact, the MME performs an implicit detach — deactivating the EPS bearers and ceasing paging — with no signalling to the missing UE, so it stops wasting resources on an unreachable device.
Q. What problem does ISR solve, and how?
A. It stops a UE at the E-UTRAN/UTRAN boundary from running a TAU or RAU on every reselection. With ISR active the UE is registered in both a TA list (MME) and a Routing Area (SGSN) simultaneously, and the S-GW pages it through both, so it can hop between LTE and 2G/3G without updating — as long as it stays within the registered TA list and RA.
Q&A — TAU Failure Handling
Q. In 4G, what happens to already-established EPS bearers if a Tracking Area Update (TAU) fails or is rejected?
A. Depends on the reject cause — some reject causes (e.g., implicit detach conditions) cause the UE to locally deactivate all bearers and re-attach from scratch, while others let bearers persist and only require retry of the TAU. It's not a uniform outcome — a "hard" reject effectively forces the UE back to a full Attach, whereas a "soft" failure (e.g., no response, congestion) usually just triggers a TAU retry with existing bearers intact.
LTE ↔ NR: the 5G equivalent of the TAU is the Mobility Registration Update (a type of the Registration procedure in TS 24.501) toward the AMF. Tracking Areas and the TAI list carry over, but the identity is the 5G-GUTI (whose GUAMI plays the routing role the GUMMEI did), inter-AMF context transfer runs over the N14 interface instead of S10, and the periodic-registration timer is T3512 rather than T3412. The same idle-mobility idea — coarse-grained location plus a heartbeat — is unchanged.
Where the TAU connects
The TAU is the location-management half of idle mobility: it keeps the record fresh so the other half — finding the UE — stays bounded, and it rides on the NAS and RRC state machinery underneath. From here, follow how the network actually reaches the UE, and the identities and states the TAU depends on.