ECM, EMM, TAU – take 2

Posted: July 22, 2010 in technical
Tags: , , , , , , , , , , ,

The TAU – Tracking Area Update procedures are defined in TS 23.401 – section 5.3.3.

MOTO: TAU – the place of my most annoying dilemmas.

Before going any further, please refer to the nice picture below (shamelessly copy-pasted from Academic Press — SAE and the Evolved Packet Core – Driving the Mobile Broadband Revolution – Magnus Olsson(2009))


In order to better manage the UE – User Equipment, EPS – Evolved Packet System has the concept of areas (this concept is not new, it was present from 3G, but it is a bit different in 4G – we’ll see how).

To my understanding (and here comes my request to the nice inter-web readers for help and clarifications):

– a tracking area is a group of cells managed by an SGW; multiple SGWs can serve the same TA and multiple TAs can be served by the same SGW

– a tracking area can be shared by more than one eNB; one eNB can also serve more than one TA

– a registration area is a list of one or more tracking areas (TAs)

– when a UE attaches to the network, the MME gives it a list of areas where it can be tracked : Tracking Area List (or Registration Area)

– an MME can manage multiple tracking areas; the purpose of the MME here being to sent the TA list to the UE when this UE is registered to the network and also update the UE with the new TA list when this UE moves around the TAs

This has importance and impacts the following situations:

– When the UE is located at the edge of an area (registration area), it can go back and forth between 2 areas, which generates a lot of signaling, as the UE is required to update its position to the EPS. By having a list of areas where the user can move without having to constantly update the EPC about its position, the amount of signaling is low.

– When UE moves frequently between 3G and 4G, it has to update his position, de-register from 4G and register in 3G and vice-versa. By keeping being registered, it can go back and forth 3G and 4G without having to signal each time its updated status.

– The UE may be in ECM-CONNECTED state or in ECM-IDLE state. No matter its state, the UE must perform the TAU – Tracking Area Update whenever it moves outside of its Registration Area (or TAL – Tracking Area List) or when a certain TAU timer expires.

The TAU procedure is described very nicely in the picture below (shamelessly copy-pasted from Academic Press — SAE and the Evolved Packet Core – Driving the Mobile Broadband Revolution – Magnus Olsson(2009))


[I’ll get into the details later on.]

– 2 MMEs can serve an overlapping set of TAs, when both of them are connected to the same SGW
the UE receives a TAList from the SGW where it attaches and this TAList does not change, unless there happens a case of SGW relocation – when the UE receives a new TAL (this TAL may have or not some of the TAs from the former TAL; some TAs may overlap)
Just as with any usual handover, TAU as well may trigger MME relocation and/or SGW relocation:
– how/when is it possible to change MME in idle/connected states?
– how/when is it possible to change SGW in idle/connected states?

The TAU procedure is not very complicated per se, but, as we should have got used to the marvels of 3GPP Specs, the Spec only describes a scenario, preferably the most complicated one, leaving the other scenarios to the reader’s understanding. Some times simply describing the most complicated scenario won’t do the “understanding” part for the “less complicated” scenarios.

For instance, you will see below the 2 TAU scenarios: SGW relocation and no SGW relocation, but both of them have the MME relocated.

The problems are:

1. Is it possible to have a TAU procedure with no MME relocation? – the spec seems to say you can…

2. What is the actual difference in the message flows and technical design between a TAU in ECM-IDLE and a TAU in ECM-CONNECTED states?

3. [Related to item 2 above] Santosh also has a dilemma:

Spec Ambiguity
Could somebody kindly tell me if a SGW could be relocated by a TAU request in connected mode? I think not? Interested in a debate? 3GPP TS 23.401 Chapter:- 5.3.3 Cheers, Santosh
So, nice people around the inter-web, please help us here 🙂
  1. Santosh says:

    Hi Cristina

    Great to see that you started looking at TAU. Unfortunately I havent read the whole article. 🙂

    My preliminary comments:-

    – Tracking areas are related to SGW. Though MME knows the tracking area but SGW is the one that covers them. When UE attaches to the network a list of tracking areas that the SGW supporst are sent to UE. UE can freely move in those tracking areas with out sending TAU. If network has to page UE, MME shall page in the TAU list that was sent to UE.

    – TAU in ECM-Connected mode may happen only after a handover. This is because handovers are exectued in connected mode. This for the same reason why a SGW cannot be relocated during TAU in connected mode as it might have already been relocated during handover.

    – When UE is in Idle mode, its exact location is not know to the user. SO it is responsibilty of UE to inform the network about its presence. UE does this by sending TAU. Note that UE sends TAU if it moves to a new area where the TA broadcasted is not in its list that was send during the attach. So a TAU in idle mode can change eNB, MME and SGW too.

    Hope this helps.

    Cheers, Santosh

  2. @Santosh: e-hee. Yey, thanks for the comment. Look, _that’s_ what I meant by nice people of the inter-web, working with this technology. Ok, I’ll write down your comments and start re-reading the specs.

    How did you get to this conclusion? That things happen this way?

    Am I reading the wrong spec? What should I read? (besides 23.401…which does not clarify these things for me)

  3. Santosh says:

    @Cristina We need to clearly understand the NAS and AS states appreciate handovers and TAU. Kindly refer to below links for more details. Also refer to specs 24.301,36,413 and 36.300

  4. @Santosh: 🙂 I’ve visited those posts. They are on my Favorites :D. Still, I haven’t read them carefully enough (this is why I still keep them pending). I will take a closer look 🙂

  5. Dumitru says:

    Hi Christina, I want to reply to your 2nd question:
    “2. What is the actual difference in the message flows and technical design between a TAU in ECM-IDLE and a TAU in ECM-CONNECTED states?”

    I think that the signaling procedures has been optimized in EPS in such a way that if there’s no MME relocation(very important point), then there’s no need of TAU after HO.
    This is because during HO, all the needed information is already exchanged(known) between MS, E-UTRAN and EPC. There’s no point in TAU… What IE to update and where?
    This is my view on this.

  6. Sandeep says:

    Hi Christina & Santosh,

    I have a test scenario (using eNB simulator). However, I am not able to succeed.

    The Ue is attached & is in ECM_IDLE mode (with TAC=7). When it is IDLE, the UE moves to new TA (TAC=9). Now the eNB sends the TAU Req to MME. However, the MME is sending Error Indication message for TAU Req.
    What can be the issue? Am I missing S1AP messges here?


    • Badrinath says:

      I guess u hv sent the TAU request Msg over the S1-AP (uplnk NAS Msg). That’s why MME is sending this Error indication MSG. Here u need to send over INITIAL UE Msg.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s