Tracking Area Update in LTE

In LTE, mobility is one of the most critical aspects of delivering a seamless and always-connected user experience. Whether a user is commuting through multiple city zones, traveling across state boundaries, or simply moving between rooms with different base station coverage, the LTE network must track the user’s location efficiently and precisely. This capability is supported through a mechanism called Tracking Area Update (TAU).

The TAU procedure plays a key role in the EPS Mobility Management. This ensures that the UE can maintain data connectivity, be reachable for incoming calls and messages, and continue its sessions across different coverage zones.
Before we investigate the TAU procedure itself, let’s understand a few foundational elements that define how location tracking and mobility management are carried out in LTE networks.

What is a Tracking Area in LTE?

A Tracking Area is a logical grouping of cells in the LTE network. Each Tracking Area is uniquely identified by a Tracking Area Code (TAC), which is broadcasted by eNodeBs via System Information Blocks (SIBs). The network assigns each UE a list of allowed Tracking Areas called a Tracking Area List.
As the UE moves through different cells and TAs, it monitors the TAC values. When it detects that it has moved into a TA that is not part of its configured TA List, it initiates a Tracking Area Update (TAU) to notify the network of its new location.

TAI = PLMN ID + TAC
PLMN ID (Public Land Mobile Network Identifier):
MCC (Mobile Country Code): 12 bits (e.g., 404 for India)
MNC (Mobile Network Code): 8 or 12 bits (e.g., 45 for Jio, 20 for BSNL)
TAC (Tracking Area Code):16 bits – uniquely identifies a tracking area within the PLMN

The total TAI can be up to 40 bits, used by LTE to uniquely identify a UE’s location within a network for mobility and paging purposes.
 
In mobile communication networks, the concept of location management has evolved across generations. In GSM (2G) networks, the basic unit for mobility tracking is known as a Location Area (LA). Each LA consists of multiple cells, and the network tracks the user’s position based on which LA the user resides in. As networks progressed to UMTS (3G), the concept shifted slightly to a Routing Area (RA), particularly designed to better support packet-switched services in the core network. With the advent of LTE (4G), the concept further evolved into a more scalable and efficient unit called a Tracking Area (TA). While the fundamental principle remains the same—grouping multiple cells for efficient paging and location management—each generation has optimized the mechanism for the underlying network architecture and service requirements.

 
Reasons for Tracking Area Update

The UE triggers a TAU for several reasons. These are defined clearly in 3GPP TS 24.301 and are essential to understand for designing, testing, and operating LTE networks:
Movement Across Tracking Areas (TA Boundary Transition)
A primary trigger for the TAU is when the UE moves into a Tracking Area that is not listed in its current Tracking Area List.
The network assigns a TA List to the UE during attach or TAU procedures. If the UE detects a TAC that is not in this list, it assumes that the network is unaware of its new location and initiates a TAU.
Example: A user on a high-speed train moving across cities rapidly enters multiple TAs. When the next TA isn’t in the current list, a TAU is sent to keep the network updated.
 
Periodic TAU – Timer T3412 Expiry
LTE employs a timer-based mechanism to ensure UEs in idle mode remain registered and reachable.
The T3412 timer, also known as the Periodic TAU Timer, is assigned by the MME during the Attach or TAU Accept procedure. When this timer expires, the UE must initiate a Periodic TAU to inform the network it is still active, even if it hasn’t moved to a new TA.
This mechanism helps the network detect UEs that may have lost connectivity or powered off unexpectedly.
 
Inter-RAT Mobility: Registering for EPS Service After RAT Change
When a UE transitions from a legacy radio access technology (e.g., UMTS or GERAN) back to LTE, a TAU is necessary to register for EPS services again.
This inter-RAT transition could happen via idle mode reselection or active handover, depending on device behaviour and network configuration.
Use Case: A UE in a building might reselect to 3G due to weak LTE signal and then return to LTE when coverage improves.
 
Registering with CS Domain – Combined Attach for Non-EPS Services
If the UE, already attached for EPS services, now wants to access circuit-switched services (such as legacy voice over GERAN/UTRAN using CS Fallback), it must register with the CS domain.
This registration can be achieved by combining the IMSI attach within the Tracking Area Update request. This type of TAU procedure is called a Combined TAU with IMSI Attach.
 
CS Fallback Recovery – Re-Registration to LTE
In case the UE falls back to a 2G/3G system for a voice call using CS Fallback, it might later return to LTE after the call ends.
Upon this return, the UE performs a TAU to re-establish its EPS registration, ensuring that the MME is once again aware of the UE’s presence in LTE and that the UE is reachable for paging and services.
 
MME Load Balancing Trigger
Some TAUs are network-triggered indirectly. For example, if the eNodeB determines that the MME currently serving the UE is overloaded, it may release the RRC connection with a special cause code:
‘load balancing TAU required’.
Upon receiving this cause, the UE is expected to initiate a new TAU procedure, which may lead it to be assigned to a less loaded MME, improving overall network balance and quality of service.
 
 
UE-Specific DRX Cycle Modification
Discontinuous Reception (DRX) helps UEs save battery by periodically waking up to check for incoming data.
If the UE-specific DRX cycle has changed (as may be decided by the network or UE capabilities), a TAU procedure is triggered so the network and UE can renegotiate or realign their DRX settings.
 
Closed Subscriber Group (CSG) Cell Access Detection
In LTE, Closed Subscriber Group (CSG) cells provide restricted access to a group of authorized users (like a private home or enterprise femtocell).
If a UE selects a CSG cell whose CSG Identity is not listed in the UE’s allowed CSG list, it must inform the network.
This is done by triggering a TAU to indicate that it is attempting to access a restricted area, and the network can take appropriate action (e.g., deny access or redirect).
 
These diverse reasons reflect the flexibility and intelligence built into the LTE mobility framework. The TAU procedure ensures that the network has precise knowledge of UE location and service context — not only during mobility transitions but also in cases where registration states, capabilities, or access privileges change.

 
TAU Procedure Call Flow

Step 1: Trigger to Start TAU Procedure (UE)

Trigger Reason:
The UE detects a need to perform a TAU due to one of the following:

• Load balancing instruction from eNodeB
• Entry into a Tracking Area not in its current Tracking Area List (TAL)
• Expiry of periodic TAU timer (T3412)
• Change in UE capabilities (e.g., IMS support)
• Recovery from CS Fallback
• Reselection from a legacy RAT (UMTS/GSM)
• DRX configuration update

Step 2: TAU Request Message (UE → eNodeB)

Tracking Area Update Request (NAS over RRC)

The UE initiates the TAU by sending the NAS TAU Request message encapsulated in RRC signalling. It indicates the last known TAI and UE identity (e.g., GUTI). The message is integrity-protected using NAS-MAC.

Contents:

• UE Core Network Capability
• Old GUTI / Additional GUTI
• Last Visited TAI
• Active flag (whether UE has active EPS bearer)
• EPS bearer status
• P-TMSI Signature
• KSIASME (Key Set Identifier)
• NAS sequence number
• NAS-MAC (message authentication code)

Step 3: Forwarding TAU Request (eNodeB → new MME)
The eNodeB receives the TAU Request and determines the correct new MME using the RRC parameters that carry the old GUMMEI and the selected PLMN (from TAI + ECGI).

The eNodeB forwards the message to the MME with additional information:

• TAI and E-UTRAN CGI
• Selected PLMN/network identity

This enables correct routing and MME selection.

Step 4: Context Request (new MME → old MME/old SGSN)

Context Request (GTP-C)

Contents:

• Old GUTI
• Complete TAU Request message (for validation)
• P-TMSI Signature
• MME Address

The new MME uses the GUTI to derive the old MME/SGSN address and sends a Context Request to retrieve the UE context such as:

• Security parameters
• Bearer context
• UE subscription details

Step 5: Context Response (old MME/SGSN → new MME)

Context Response

The old MME sends all necessary UE session context to the new MME, including PDN GW TEIDs, PGW GRE keys, and bearer-level QoS parameters. This allows the new MME to reconstruct session continuity and bearer pathways.

Contents:

• IMSI
• ME Identity (IMEI, if available)
• MSISDN
• Unused EPS Authentication Vectors
• KSIASME
• KASME (key)
• EPS Bearer Contexts (including PGW and SGW parameters)
• SGW Signaling Address and TEIDs
• ISR support indication
• DRX Parameters
• UE Network Capability

Step 6: Authentication and Security Mode Control (MME ↔ UE)

The MME may perform security procedures, depending on whether the existing context is valid or needs refresh.

• Authentication Request/Response (based on KSIASME and authentication vectors)
• Security Mode Command / Complete
  This ensures NAS signalling is secure, and integrity protected.

Step 7: Context Acknowledge (new MME → old MME)
Once the UE context is fully accepted, the new MME sends a Context Acknowledge message to the old MME.

This confirms successful transfer and allows the old MME to mark the UE as moved and release bearer resources later.

Step 8: Create Session Request (new MME → new SGW)

Create Session Request (GTP-C)

The new MME initiates the creation of new bearer paths with the new SGW, using the parameters it received from the old MME. The goal is to set up forwarding from PGW → new SGW → eNodeB.

Contents:

• PDN Gateway address
• Bearer Context(s)
• APN, TFT, QoS
• UE IP address
• IMSI, MSISDN

Step 9: Modify Bearer Request (new SGW → PGW)

Modify Bearer Request

The PGW is informed of the new SGW’s address and TEIDs. This is required for uplink and downlink tunnelling changes.

Contents:

• EPS Bearer ID
• New SGW TEID for uplink traffic

Optional: Step 9a — PCRF may trigger a P‑CAN session modification.

Step 10: Modify Bearer Response (PGW → new SGW)

Modify Bearer Response

PGW acknowledges and finalizes session routing updates.

Contents:

• QoS, Charging ID, Flow filters, TEIDs

Step 11: Create Session Response (new SGW → new MME)

Create Session Response (GTP-C)

The new Serving Gateway (SGW) confirms the bearer creation to the new MME, providing the updated uplink/downlink TEIDs and addressing information. This message completes the bearer setup towards the eNodeB from the PGW.

Contents:

• Bearer Contexts (Bearer ID, S1-U TEIDs)
• SGW Address (user plane)
• EPS Bearer QoS
• Charging ID

Step 12: Update Location Request (new MME → HSS)

Update Location Request (Diameter – S6a Interface)

The new MME updates the HSS to indicate that the UE is now being served by it. This ensures that future paging and authentication traffic is routed to the correct MME.

Contents:

• IMSI
• MME Identity (GUMMEI)
• UE Capabilities (e.g., Voice over IMS support)

Step 13: Cancel Location Request (HSS → old MME)

Cancel Location Request
The HSS instructs the old MME to remove the UE context from its database and relinquish control of the subscriber.

Step 14: Cancel Location Acknowledge (old MME → HSS)

Cancel Location Answer

The old MME confirms that it has deleted the UE context successfully.

Step 15: Iu Release Command (new MME → RNC)

Iu Release Command

This step applies when the UE is transitioning from a legacy UTRAN (3G) network to LTE.
The new MME commands the RNC (Radio Network Controller) to release the Iu interface and clean up the radio path previously maintained under the old RAT.

Step 16: Iu Release Complete (RNC → new MME)

Iu Release Complete
The RNC responds back confirming that the Iu connection has been released. The UE is now fully managed by the LTE access network.

Step 17: Update Location Answer (HSS → new MME)

Update Location Answer

The HSS confirms the location update and provides the latest subscription information for the UE to the new MME. This ensures continued enforcement of policy and QoS settings.

Contents:

• Subscription Profile (e.g., APN list, AMBR, bearer restrictions)
• IMS voice over PS session supported
• Access restriction data

Step 18: Delete Session Request (new MME → old SGW)

Delete Session Request (GTP-C)
The new MME sends a command to the old SGW to release any residual bearer resources and tunnels previously used by the UE.

Step 19: Delete Session Response (old SGW → new MME)

Delete Session Response
The old SGW acknowledges that all bearer contexts related to the UE have been removed. This frees up user-plane resources and prevents duplicate routing paths.

Step 20: TAU Accept (new MME → UE)

Tracking Area Update Accept (NAS)

The new MME sends a successful acknowledgment to the UE confirming that the TAU procedure has been completed. This message may include a new GUTI and TAL, and updates any new configurations such as IMS support.

Contents:

• New GUTI (if reallocated)
• Updated Tracking Area List (TAL)
• Timer T3412 (Periodic TAU timer)
• IMS Voice over PS support indication

Step 21: TAU Complete (UE → new MME)

Tracking Area Update Complete (NAS)
The UE acknowledges the TAU Accept by sending the TAU Complete message. At this point, the UE is fully registered in the new tracking area and can resume services with updated network paths and context.

Reference

• 3GPP TS 23.003 – Defines TAI structure: MCC, MNC, and TAC.
• 3GPP TS 36.300 – Describes LTE architecture and mobility management.
• 3GPP TS 24.301 – Specifies TAU message flow and NAS signalling.
• Sesia et al., LTE Book – Covers LTE mobility and tracking in practical depth.