Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEUE to MME3GPP TS 24.301
LTE Tracking Area Update Request
Tracking Area Update Request is the EPS NAS message the UE uses to update the network about tracking-area change, periodic presence, or related EPS mobility-context refresh.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
5.5.3, 8.2.29
Direction
UE to MME
Message Type
EMM signaling
Full message name
LTE Tracking Area Update Request
Protocol
NAS
Technology
LTE
Direction
UE to MME
Interface
N1 over LTE access / S1-MME control path
Signaling bearer / channel
NAS signaling / Commonly carried after LTE access restoration or existing dedicated NAS transport, depending on the update trigger
Typical trigger
UE enters a new tracking area, timer T3412 expires for periodic updating, or a related mobility or recovery condition requires a tracking area update.
Main purpose
Lets the UE refresh or update EPS mobility context when the tracking area changes, when periodic updating is due, or when a related mobility or recovery condition requires a tracking area update instead of a fresh attach.
Main specification
3GPP TS 24.301, 5.5.3, 8.2.29
Release added
Release 8
Procedures where used
Tracking Area Updating Procedure, Normal TA Change, Periodic Updating, Recovery-triggered Mobility Refresh
What is LTE Tracking Area Update Request in simple terms?
Tracking Area Update Request is the EPS NAS message the UE uses to update the network about tracking-area change, periodic presence, or related EPS mobility-context refresh.
Lets the UE refresh or update EPS mobility context when the tracking area changes, when periodic updating is due, or when a related mobility or recovery condition requires a tracking area update instead of a fresh attach.
Why this message matters
Tracking Area Update Request is the UE asking the LTE/EPS network to refresh or update existing EPS mobility context, usually because the tracking area changed or periodic updating is due.
Where this message appears in the call flow
Normal tracking area change update
In a normal tracking area change, the UE sends Tracking Area Update Request to refresh the mobility context it already has for the new TA.
Call flow position: UE-originated mobility-management message sent after the UE detects that it moved into a new tracking area.
Typical state: UE is already EPS-registered and is refreshing its mobility context rather than rebuilding registration from scratch.
Preconditions:
The UE has valid EPS registration context.
A tracking area change or similar TAU trigger occurred.
Next likely message: Tracking Area Update Accept, Tracking Area Update Reject, or common NAS continuation
Periodic tracking area update
When periodic updating is due, Tracking Area Update Request refreshes the UE's registered presence without rebuilding EPS context.
Call flow position: Periodic presence-refresh message sent when timer T3412 expires and the UE must confirm that its EPS registration context is still valid.
Typical state: UE is not changing registration model, but it is refreshing the stored EPS update context.
Preconditions:
The UE remains EPS-registered.
Periodic updating is due.
Next likely message: Tracking Area Update Accept or Tracking Area Update Reject
Tracking area update after recovery trigger
When the UE still has usable EPS context after a recovery-related trigger, Tracking Area Update Request preserves that context through the TAU path instead of falling back to a fresh attach.
Call flow position: Update message sent when a recovery or mobility trigger still fits the TAU branch rather than forcing a fresh attach.
Typical state: UE is trying to preserve existing EPS context by updating it through the TAU procedure.
Preconditions:
Usable EPS context still exists.
The trigger requires mobility-context refresh rather than new registration creation.
Next likely message: Tracking Area Update Accept, Tracking Area Update Reject, or common NAS continuation
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS mobility management signaling that refreshes or updates existing EPS registration context without rebuilding it from scratch
Signaling bearer: NAS signaling
Logical channel: Commonly carried after LTE access restoration or existing dedicated NAS transport, depending on the update trigger
Transport / encapsulation: EPS NAS message sent by the UE toward the MME through the eNodeB during the tracking area updating procedure
Security context: Normally sent using an existing NAS security context because the UE is already EPS-registered and is updating that stored context rather than starting a fresh attach.
Message Structure Overview
Tracking Area Update Request is an EPS mobility-management message rather than an ASN.1 LTE RRC structure.
The practical reading path starts with EPS update type, old GUTI, and the reason the UE selected the TAU branch instead of Attach Request or Service Request.
In real traces, this message is the main NAS checkpoint for TA change, periodic presence refresh, and some recovery-driven mobility updates.
ASN.1 Message Syntax for LTE Tracking Area Update Request
Tracking Area Update Request
EPS update type
old GUTI
non-current native NAS key set identifier OPTIONAL
GPRS ciphering key sequence number OPTIONAL
old P-TMSI signature OPTIONAL
additional GUTI OPTIONAL
NonceUE OPTIONAL
UE network capability OPTIONAL
last visited registered TAI OPTIONAL
DRX parameter OPTIONAL
UE radio capability information update needed OPTIONAL
EPS bearer context status OPTIONAL
MS network capability OPTIONAL
old location area identification OPTIONAL
TMSI status OPTIONAL
mobile station classmark 2 OPTIONAL
mobile station classmark 3 OPTIONAL
supported codecs OPTIONAL
additional update type OPTIONAL
voice domain preference and UE's usage setting OPTIONAL
old GUTI type OPTIONAL
device properties OPTIONAL
MS network feature support OPTIONAL
TMSI based NRI container OPTIONAL
T3324 value OPTIONAL
T3412 extended value OPTIONAL
extended DRX parameters OPTIONAL
UE additional security capability OPTIONAL
UE status OPTIONAL
additional information requested OPTIONAL
N1 UE network capability OPTIONAL
UE radio capability ID availability OPTIONAL
DRX parameter in NB-S1 mode OPTIONAL
requested WUS assistance information OPTIONAL
requested IMSI offset OPTIONAL
UE request type OPTIONAL
paging restriction OPTIONAL
unavailability information OPTIONAL
How to read this message syntax
Tracking Area Update Request is a NAS layer-3 message, not an ASN.1 LTE RRC message. Read this NAS syntax from the EPS update type first, then check whether old identity, bearer-status, and timer-related fields match the reason the UE chose the TAU path.
The first useful question is which EPS update type the UE selected and whether that choice matches the real trigger.
Old GUTI and last visited registered TAI are high-value context fields because they show what mobility state the UE believed it already had.
If the network treats the TAU path unexpectedly, compare bearer-status and timer-related fields before assuming the UE should have used attach instead.
Important Information Elements
IE
Required
Description
EPS update type
Yes
Tells the network which kind of tracking area updating procedure the UE is requesting.
Old GUTI
Yes
Carries the previously assigned EPS identity context used to continue the registered mobility state.
Non-current native NAS key set identifier
Optional
Provides older NAS security context reference information when relevant.
UE network capability
Optional
Advertises UE capabilities relevant to current EPS handling.
Last visited registered TAI
Optional
Provides the previously known tracking-area context to the network.
EPS bearer context status
Optional
Lets the UE indicate bearer-context state that may need synchronization.
Additional update type
Optional
Adds context about why the update is being requested.
T3324 value
Optional
May carry active-time context relevant to later power-saving behavior.
Tells the network which kind of tracking area updating procedure the UE is requesting.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Old GUTI
Carries the previously assigned EPS identity context used to continue the registered mobility state.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Non-current native NAS key set identifier
Provides older NAS security context reference information when relevant.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
UE network capability
Advertises UE capabilities relevant to current EPS handling.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Last visited registered TAI
Provides the previously known tracking-area context to the network.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
EPS bearer context status
Lets the UE indicate bearer-context state that may need synchronization.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Additional update type
Adds context about why the update is being requested.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
T3324 value
May carry active-time context relevant to later power-saving behavior.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
T3412 extended value
May carry extended periodic update timer context.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Confirm why the UE started the tracking area updating procedure.
Check the selected EPS update type first.
Inspect old GUTI and the last visited registered TAI.
Inspect EPS bearer context status and timer-related IEs if the resulting state looks inconsistent.
Correlate the message with Tracking Area Update Accept, Tracking Area Update Reject, or common NAS continuation.
Common Issues and Troubleshooting
The UE stays registered but repeatedly performs mobility updates.
Likely cause: The TAU trigger, selected update type, or returned TAU outcome may not match the real area or timer context.
What to inspect: Check EPS update type, last visited registered TAI, T3412-related fields, and the network response.
Next step: Treat Tracking Area Update Request as the first mobility-refresh checkpoint before assuming broader registration instability.
The UE uses TAU when it looked like attach or service restoration might happen instead.
Likely cause: Usable EPS context still existed, so the UE chose the tracking-area updating branch rather than rebuilding or only restoring service.
What to inspect: Compare the stored-context assumptions, old GUTI, and the actual trigger that started the procedure.
Next step: Decide first whether the trace is a mobility-refresh path, a restore-service path, or a rebuild path.
Periodic updating behaves differently across cells or after restart.
Likely cause: Timer-related fields, tracking-area context, or the stored registered state may differ between the compared cases.
What to inspect: Compare EPS update type, T3412-related fields, last visited registered TAI, and the later accept or reject branch.
Next step: Use Tracking Area Update Request as the main reference point for why periodic presence refresh behaved differently.
LTE / 5G / Variant Comparison
Compared with Attach Request
Tracking Area Update Request refreshes existing EPS mobility context. Attach Request creates or rebuilds EPS registration context from the start.
Compared with Service Request
Tracking Area Update Request updates mobility context. Service Request restores active service using already valid EPS context.
Compared with Tracking Area Update Reject
Tracking Area Update Request starts the TAU procedure. Tracking Area Update Reject is the network response when that update path is not accepted.
FAQ
What is Tracking Area Update Request in LTE?
It is the EPS NAS message the UE sends to refresh or update existing EPS mobility context, usually because the tracking area changed or periodic updating is due.
When is Tracking Area Update Request used instead of Attach Request?
It is used when usable EPS registration context already exists and the UE only needs to update that context rather than rebuild registration from scratch.
What should I inspect first in Tracking Area Update Request?
Start with EPS update type, then inspect old GUTI, last visited registered TAI, and any timer-related fields.
Why is Tracking Area Update Request important in troubleshooting?
Because it is the main NAS checkpoint that explains how the UE refreshed mobility context and why it selected TAU instead of attach or service request.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
