Routing Area Update: LAU vs RAU vs TAU Explained in Full

Three network generations. Three Routing Area update procedures. One shared purpose that most articles never fully explain.

Here’s the fast answer. LAU handles location updates in GSM. RAU handles them in UMTS. TAU handles them in LTE. All three exist so the network always knows where your device is.

That’s the surface answer. The real depth sits underneath it, in how these procedures actually behave, why TAU works so differently from its predecessors, and what happens when any of them fail.

The Basic Mapping, at a Glance

Start here before anything else.

Procedure	Full Name	Network Generation	Radio Access
LAU	Location Area Update	GSM (2G)	GERAN
RAU	Routing Area Update	UMTS (3G)	UTRAN
TAU	Tracking Area Update	LTE (4G)	EUTRAN

Each procedure triggers when a device detects it’s entered new territory. LAU triggers on a new Location Area Code. RAU triggers on a new Routing Area Identity. TAU triggers when a device leaves every Tracking Area on its assigned list.

That last part is worth sitting with. It’s the biggest structural difference in this whole comparison, and we’ll get there shortly.

Why These Procedures Exist at All

Every one of these procedures solves the same core problem. The network needs to know where your device is, so it can actually reach it.

Without a location update, an incoming call or message has nowhere to go. The network would have to search blindly across its entire coverage area, which doesn’t scale.

This matters even more for multimode devices. A phone that moves between GERAN, UTRAN, and EUTRAN networks, interconnected through a Gn interface, needs these procedures to keep working correctly as it crosses technology boundaries, not just geographic ones.

The Tracking Area List: TAU’s Real Innovation

This is where TAU genuinely breaks from LAU and RAU. Most comparisons skip this entirely.

LAU and RAU each track a device against a single area. One Location Area. One Routing Area. Cross the border, trigger an update.

TAU works differently. A device gets assigned a Tracking Area List, a set of multiple valid tracking areas at once. It only triggers a TAU when it moves somewhere outside every area on that list.

Why a List Instead of a Single Area

This wasn’t an arbitrary design choice. It solves a real signaling problem.

Picture a train full of passengers crossing a tracking area border at the same moment. If every phone used a single-area model like GSM or UMTS, all of them would trigger an update simultaneously. That’s a signaling storm hitting the network all at once.

With a Tracking Area List, different devices can be assigned different lists, even while sitting in the exact same physical location. That spreads out when each device actually needs to update, instead of forcing a synchronized flood.

GSM and UMTS never had this option. Every device in those networks shares the same location and routing area borders, with no per-device list customization.

The Connected-Mode Surprise Nobody Explains

Here’s a genuine technical distinction that even experienced engineers find surprising the first time they encounter it.

In UMTS, while a device sits in PMM-CONNECTED state, crossing a routing area border usually doesn’t trigger a RAU by itself. The trigger is different: it only fires when the serving SGSN or MSC actually changes.

When that happens, it kicks off an SRNS Relocation procedure, and a RAU happens as part of finishing that relocation. Simply moving between routing areas, without a core network element change, generally doesn’t require anything.

TAU Breaks This Pattern Completely

LTE does something different on purpose. A Tracking Area Update fires in both idle mode and connected mode, explicitly.

Why the difference? It comes down to how certain handovers work.

During an X2 handover, negotiated directly between two base stations, the Mobility Management Entity in the core network isn’t part of that negotiation in real time. It only finds out after the handover has already happened. There’s no direct signaling channel between the MME and the device during the handover itself.

Connected-mode TAU exists specifically to close that gap. It keeps the MME’s record of where the device actually is accurate, even though the MME wasn’t directly involved in the handover that just occurred.

A General Look at How These Procedures Actually Flow

Every one of these updates follows a broadly similar shape, even though the exact protocol details differ by generation and are formally defined in the underlying 3GPP specifications.

Stage	What Happens
Detection	The device notices it’s in a new area, or outside its Tracking Area List
Request	The device sends an update request, identifying itself to the network
Processing	The network updates its internal record of the device’s location
Accept	The network responds, confirming the update was accepted
Complete	The device sends a final message, concluding the procedure

Think of this as the general shape of the conversation, not a literal message-by-message specification. The exact fields, message names, and signaling details vary by procedure and generation, and those specifics live in the formal 3GPP documentation itself.

Routing Areas Live Inside Location Areas

This relationship matters more than it sounds like it should.

A Routing Area is structurally a subset of a Location Area. Every Routing Area sits entirely inside exactly one Location Area, never spanning across two.

Because of that nesting, the network can do something clever. If a device crosses only a Routing Area border, and that border is still inside the same Location Area, the network already knows the correct Location Area without needing a separate check.

The Combined RAU/LAU Optimization

This structural relationship enables a real efficiency gain: a combined update.

Instead of firing off two separate procedures, a Location Area Update and a Routing Area Update, the device performs one combined update covering both. This cuts signaling overhead in half for this specific crossing scenario.

There’s a catch, though. This optimization only works if both the device and the network explicitly support it. Without that mutual support, the two updates still happen separately.

Periodic Updates: The Ones That Happen While You’re Standing Still

Location-crossing updates aren’t the whole story. There’s a second, quieter mechanism running in parallel.

Procedure	What It’s Called	Purpose
GSM	Periodic LAU (PLAU)	Confirms the device is still reachable, even stationary
UMTS	Periodic RAU (PRAU)	Same purpose, for the packet-switched domain
LTE	Periodic TAU (PTAU)	Same purpose, governed by a specific timer

These fire on a schedule, regardless of whether the device has actually moved anywhere. A device sitting still for hours still needs to periodically confirm it’s alive and reachable.

The Timer Behind It

The network sets how often this happens. A commonly cited illustrative interval in technical documentation is around 60 minutes, though this is configurable and not a fixed universal rule across every network.

A specific standardized timer, T3412, governs periodic Tracking Area Updates specifically. Technical documentation also references a related parameter sometimes called the Subscribed-Periodic-RAU-TAU-Timer.

What Happens If a Device Misses One

This isn’t just a formality. Missing a periodic update has real consequences.

If a device fails to check in, the network eventually stops paging it after an initial timeout period. If the silence continues past a further, typically longer stretch, the network may purge the device’s registration information entirely.

At that point, the device effectively falls off the network’s radar until it re-registers from scratch.

When a Routing Area Update Gets Rejected

Most content stops at the success path. Real networks fail sometimes, and this is where the depth genuinely matters.

A RAU can be rejected outright. One real scenario: a device falls back from LTE to a 2G or 3G network, and that network’s packet-switched domain has been barred or temporarily backed off.

The Consequence Chain

Here’s what actually happens next, step by step.

If there’s no context transfer between the MME and the new SGSN in this situation, the MME doesn’t just sit there indefinitely. It eventually times out.

Once that timeout hits, the MME sends a detach indication to the VLR. After that point, the device cannot receive mobile-terminated paging at all, not until it successfully re-registers from the beginning.

A specific standardized timer, T3346, governs the back-off period tied to this kind of rejection. It’s the mechanism controlling how long the device has to wait before it can reasonably try again.

Timer	Governs	Relevant Scenario
T3412	Periodic TAU	Confirming reachability while stationary
T3346	PS back-off after rejection	Recovering from a barred PS domain during fallback

Dual-SIM Devices Complicate Things

This isn’t a niche edge case anymore. Dual-SIM phones are everywhere.

A device with multiple USIM identities may need to run LAU and RAU procedures separately for each SIM. That doubles the signaling overhead compared to a single-SIM device doing the exact same movement.

The Combined Update Fix

There’s a specific optimization built for this. A multi-SIM device can perform one combined update that covers multiple SIM identities at once, instead of running each procedure twice.

This directly reduces processing load and signaling overhead, which matters more as dual-SIM and multi-SIM devices become the norm rather than the exception.

How CS Fallback Ties Everything Together

This is where LTE and older generations genuinely have to cooperate, not just coexist.

CS Fallback, commonly shortened to CSFB, lets an LTE device temporarily drop down to a 2G or 3G network specifically to handle a voice call. Voice historically stayed on circuit-switched infrastructure even as data moved to packet-switched LTE.

The Interfaces That Make This Work

A Gs interface connects the MSC/VLR and the MME directly. An SGs association, built on top of that interface, supports the combined update procedures that CSFB depends on.

This lets a device stay reachable for circuit-switched services, like a normal phone call, while it’s camping on E-UTRAN the rest of the time.

Where ISR Fits In

Idle-mode Signaling Reduction, or ISR, is a related feature layered on top of this. When it’s active and properly supported across the relevant interfaces, it changes how combined updates behave for a device moving between GSM/UMTS and LTE.

The overall goal across all of this: keep signaling overhead down while a device bounces between network generations, without breaking its reachability for either voice or data.

Idle Mode vs. Connected Mode, Side by Side

Given how much of this comparison hinges on mode-dependent behavior, here’s a direct summary.

Procedure	Idle Mode Behavior	Connected Mode Behavior
LAU (GSM)	Triggers on new LAC	Not typically applicable in the same way
RAU (UMTS)	Triggers on new RAI	Generally only when SGSN/MSC changes, via SRNS Relocation
TAU (LTE)	Triggers when outside Tracking Area List	Also triggers explicitly, to cover MME blind spots like X2 handovers

TAU is the outlier here, and deliberately so. Its connected-mode behavior exists specifically because LTE’s handover architecture created a gap that earlier generations didn’t have in the same form.

Frequently Asked Questions

What’s the basic difference between LAU, RAU, and TAU?

LAU applies to GSM, RAU applies to UMTS, and TAU applies to LTE. All three keep the network informed of a device’s location, but they trigger and behave differently based on their generation’s architecture.

Why does TAU use a list of tracking areas instead of a single area?

It reduces signaling load. Assigning different tracking area lists to different devices, even in the same location, prevents every device from triggering an update at the exact same moment when crossing a shared boundary.

Why does TAU happen in connected mode when RAU usually doesn’t?

Because of handovers like X2, where the MME only learns about a handover after it’s already happened. Connected mode TAU keeps the MME’s location record accurate despite that gap.

What does the general message flow for a routing or tracking area update look like?

Broadly: detection of a new area, a request message from the device, processing by the network, an accept response, and a completion message. Exact protocol details vary by generation and procedure.

What is a combined RAU/LAU update, and why does it exist?

Since a Routing Area sits entirely inside a Location Area, the network can infer the Location Area from a Routing Area crossing. A combined update handles both in one procedure instead of two, if both device and network support it.

What happens when a device doesn’t send a required periodic update?

The network stops paging it after an initial timeout, and may eventually purge its registration entirely if the silence continues.

What causes a RAU to be rejected, and what happens afterward?

A common cause is falling back to a 2G or 3G network with a barred packet switched domain. Without context transfer between the MME and new SGSN, the MME times out and sends a detach indication, blocking paging until the device re-registers.

How do dual-SIM devices handle these procedures differently?

They may need to run LAU and RAU separately per SIM identity, doubling signaling overhead, unless a combined update optimization is supported to handle multiple identities in one procedure.

How does CS Fallback relate to these update procedures?

CSFB relies on the Gs interface and SGs association between the MSC/VLR and MME, using combined update mechanics to keep an LTE device reachable for voice calls on 2G or 3G.

What’s the difference between idle mode and connected mode for these purposes?

Idle mode updates happen when a device isn’t actively in a session. Connected mode updates, especially for TAU, happen during active sessions specifically to cover situations the core network wouldn’t otherwise be aware of in real time.

Quick Reference Summary

Question	Answer
Which generation uses LAU	GSM (2G)
Which generation uses RAU	UMTS (3G)
Which generation uses TAU	LTE (4G)
TAU’s key structural difference	Tracking Area List instead of a single area
Does RAU trigger in connected mode	Rarely, only on SGSN/MSC change
Does TAU trigger in connected mode	Yes, explicitly
Timer for periodic TAU	T3412
Timer for RAU rejection back-off	T3346

Also Read: TouchEn NxKey Error