Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
NASLTEMME to UE3GPP TS 24.301
LTE Tracking Area Update Accept
Tracking Area Update Accept is the EPS NAS message the MME uses to accept the tracking area updating procedure and return the updated EPS mobility context to the UE.
Message Fact Sheet
Protocol
nas
Network
lte
Spec
3GPP TS 24.301
Spec Section
5.5.3, 8.2.26
Direction
MME to UE
Message Type
EMM signaling
Full message name
LTE Tracking Area Update Accept
Protocol
NAS
Technology
LTE
Direction
MME to UE
Interface
N1 over LTE access / S1-MME control path
Signaling bearer / channel
NAS signaling / Commonly carried in downlink NAS transport after the tracking area updating procedure is accepted
Typical trigger
Sent when the network accepts Tracking Area Update Request for normal TA change, periodic updating, or a recovery-driven mobility refresh path.
Main purpose
Confirms that the TAU procedure succeeded, returns the accepted tracking-area and timer context, and lets the UE continue using refreshed EPS registration instead of rebuilding it through attach.
Main specification
3GPP TS 24.301, 5.5.3, 8.2.26
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 Accept in simple terms?
Tracking Area Update Accept is the EPS NAS message the MME uses to accept the tracking area updating procedure and return the updated EPS mobility context to the UE.
Confirms that the TAU procedure succeeded, returns the accepted tracking-area and timer context, and lets the UE continue using refreshed EPS registration instead of rebuilding it through attach.
Why this message matters
Tracking Area Update Accept is the network telling the UE that the tracking area update succeeded and returning the refreshed EPS mobility context.
Where this message appears in the call flow
Normal tracking area change acceptance
In a normal tracking area change, Tracking Area Update Accept confirms that the network refreshed the registered mobility context for the new tracking area.
Call flow position: Network acceptance message sent after the MME agrees to refresh the UE mobility context for a new tracking area.
Typical state: UE stays EPS-registered and is receiving the updated registered-area context it can use next.
Preconditions:
The UE sent Tracking Area Update Request for a TA change.
The network accepted the mobility-refresh path.
Next likely message: Tracking Area Update Complete or protected service continuation
Periodic tracking area update acceptance
When periodic updating is due, Tracking Area Update Accept returns the current periodic-update and registered-area context without forcing a fresh attach.
Call flow position: Acceptance message sent when the periodic presence refresh is successful and the network returns the current registration timers and TAI context.
Typical state: UE remains registered and refreshes its periodic mobility state without moving into a fresh attach procedure.
Preconditions:
Periodic updating was due.
The MME accepted the TAU procedure.
Next likely message: Tracking Area Update Complete or normal registered idle behavior
Tracking area update after recovery trigger
When usable EPS context still exists after a recovery-related trigger, Tracking Area Update Accept preserves that registration model and returns refreshed mobility context through the TAU path.
Call flow position: TAU acceptance used when the network can preserve the UE's registration model after a recovery-related trigger instead of forcing attach rebuild.
Typical state: UE receives refreshed EPS mobility context and continues from the preserved registration path.
Preconditions:
Usable EPS context still existed.
The network accepted the TAU branch instead of rejecting it or forcing new registration.
Next likely message: Tracking Area Update Complete or protected service continuation
Interface: N1 over LTE access / S1-MME control path
Domain: Core-side EPS mobility management signaling that updates the UE's existing registration context for continued LTE/EPS mobility and service
Signaling bearer: NAS signaling
Logical channel: Commonly carried in downlink NAS transport after the tracking area updating procedure is accepted
Transport / encapsulation: EPS NAS message sent by the MME and delivered to the UE through the eNodeB during the tracking area updating procedure
Security context: Normally sent using existing NAS security because TAU operates on already valid EPS registration context rather than a fresh registration model.
Message Structure Overview
Tracking Area Update Accept is an EPS mobility-management message rather than an ASN.1 LTE RRC structure.
The practical reading path starts with EPS update result, TAI list, T3412, and whether a new GUTI or optional returned timers changed later UE behavior.
In real traces, this is the message that shows exactly what mobility context the network accepted after TAU.
ASN.1 Message Syntax for LTE Tracking Area Update Accept
Tracking Area Update Accept
EPS update result
T3412 value
GUTI OPTIONAL
TAI list
EPS bearer context status OPTIONAL
location area identification OPTIONAL
MS identity OPTIONAL
EMM cause OPTIONAL
T3402 value OPTIONAL
T3423 value OPTIONAL
equivalent PLMNs OPTIONAL
emergency number list OPTIONAL
EPS network feature support OPTIONAL
additional update result OPTIONAL
T3412 extended value OPTIONAL
T3324 value OPTIONAL
extended DRX parameters OPTIONAL
header compression configuration status OPTIONAL
DCN-ID OPTIONAL
SMS service status OPTIONAL
non-3GPP NW provided policies OPTIONAL
T3448 value OPTIONAL
network policy OPTIONAL
How to read this message syntax
Tracking Area Update Accept is a NAS layer-3 message, not an ASN.1 LTE RRC message. Read this NAS syntax from the granted update result first, then move into returned TAI, timer, and identity context.
May be returned when control-plane user-data congestion or similar service restrictions are relevant.
Detailed field explanation
EPS update result
Tells the UE what update result the network granted for the TAU procedure.
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.
T3412 value
Returns the periodic tracking area update timer that controls later periodic updating behavior.
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.
TAI list
Provides the set of tracking areas in which the UE is considered registered after the accepted TAU procedure.
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.
GUTI
Provides updated temporary EPS identity information when the network reallocates it.
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 network synchronize bearer-state assumptions when that context matters after TAU.
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.
Location area identification
May appear when legacy mobility context also matters for the accepted mobility outcome.
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.
T3402 value
May be returned for mobility handling in context-dependent cases.
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
Provides extended periodic update timing when the network uses the extended timer encoding.
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.
T3448 value
May be returned when control-plane user-data congestion or similar service restrictions are 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.
What to check in logs and traces
Confirm the message belongs to the same TAU procedure started by Tracking Area Update Request.
Check EPS update result first.
Inspect TAI list, T3412, and any returned GUTI.
Inspect optional returned timers and bearer-status information if later behavior changes.
Correlate the message with Tracking Area Update Complete or the next protected service state.
Common Issues and Troubleshooting
TAU succeeds but later mobility behavior still looks wrong.
Likely cause: The network may have accepted the update while returning TAI or timer values that changed the UE's later behavior.
What to inspect: Check EPS update result, TAI list, T3412, and any optional timer fields.
Next step: Compare the returned TAU context against a known-good case before assuming the request itself was wrong.
The UE remains registered but periodic updating or idle behavior changes unexpectedly.
Likely cause: Returned periodic-update or active-time timer context may differ across cases.
What to inspect: Check T3412, T3412 extended value, T3324 when present, and the accepted TAI list.
Next step: Treat Tracking Area Update Accept as the mobility-state checkpoint that explains the later registered behavior.
TAU acceptance works after some events but falls back to attach in others.
Likely cause: In some cases the network can preserve EPS context and return Tracking Area Update Accept, while in other cases the context was not reusable.
What to inspect: Compare the trigger, returned identity, and timer context across the accepted TAU and fresh attach paths.
Next step: Decide first whether the trace remained a mobility-refresh path or crossed into registration rebuild.
LTE / 5G / Variant Comparison
Compared with Tracking Area Update Request
Tracking Area Update Request starts the TAU procedure. Tracking Area Update Accept is the network response when that mobility-refresh path is granted.
Compared with Tracking Area Update Reject
Tracking Area Update Accept preserves and refreshes existing EPS registration context. Tracking Area Update Reject ends that TAU path and returns the failure branch.
Compared with Attach Accept
Tracking Area Update Accept refreshes an existing EPS registration model. Attach Accept grants a fresh or rebuilt attach registration model.
FAQ
What is Tracking Area Update Accept in LTE?
It is the EPS NAS message the network sends when the tracking area updating procedure is accepted and refreshed EPS mobility context is returned to the UE.
What should I inspect first in Tracking Area Update Accept?
Start with EPS update result, then inspect TAI list, T3412, and any returned GUTI or optional timer fields.
Why is Tracking Area Update Accept important in troubleshooting?
Because it shows what mobility context and timer behavior the network actually granted after TAU, which often explains later registered behavior.
What usually comes after Tracking Area Update Accept?
The UE may send Tracking Area Update Complete when required, then continue with protected registered operation or later service behavior.
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.
