LTE Tracking Area Update vs. UMTS Location/Routing Area Update

Here's an interesting piece of technical insight I gained this week when going through 3GPP TS 23.401 concerning tracking area updates that I haven't seen when I went through the spec for my SAE review posts back in February (part 1, part 2 and part 3):

In UMTS, location area and routing area udpates are only done when the mobile is in idle state, i.e. no physical link is established on the high speed shared-, dedicated- or forward access channel. This makes sense as in these states the RNC in the access network is aware of the location anyway and can report location changes to the core network when necessary. Only once the mobile goes to idle state and the mobile makes the decision to go to another cell on its own without reporting back, routing and location area updates come into play if the new cell is outside the current area.

In LTE, the corresponding procedure is called a tracking area update. The first difference to the LAU and RAU of UMTS is that the mobile can have a list of several valid tracking areas and an update only has to be made if the new cell is in a tracking area that is not part of that list. So far so good. TS 23.401 chapter says, however, that a tracking area update is made in both idle and connected state. Quite a surprise to me so I wondered why an update is necessary in the connected state!?

The answer to that question can be found in the message sequence charts for handovers. For example: during an X2 handover, which is directly negotiated between two base stations, the Mobility Management Entity (MME) in core network is only informed of the handover after it has taken place. Also, there's no direct communication between the MME and the mobile device during the handover procedure. That means that in case the new cell is in a new tracking area, the mobile has to update its tracking area list as that information was not contained in the handover messaging.

From a logical point of view that also makes sense. Traking areas are administered by the core network (by the Non Access Stratum) while handovers are performed by the access network. Also, the signaling does not interrupt the user data transfer so there are no side effects of performing this procedure in connected mode and while transferring data.

More LTE technical tidbits this week also over at Wired n' Wireless.

5 thoughts on “LTE Tracking Area Update vs. UMTS Location/Routing Area Update”

  1. Martin,

    The routing area update is performed in UMTS in connected state too. As far as I am aware, in case of a voice call in GSM, as soon as the voice call is released, the RAU procedure occurs if RA was changed, it is just delayed as most UEs can’t do PS signalling while in a CS call. As for the TA list, yes it is new. The intention is to assign different TAs to different UEs in the same location, so as to mitigate signalling load e.g. when a train crosses a TA border.

  2. Hi David,

    in UMTS PMM-Connected state, in most cases no Routing Area Update is
    made when changing the RA unless the SGSN/MSC changes as well. In this
    case an SRNS Relocation is made which includes a Routing Area Update
    procedure at the end.

    Heres the relevant section in 3GPP TS 23.060, section

    The SRNC may provide a PMM-CONNECTED state MS with MM
    information like RAI by dedicated signalling. Typically, the SRNC should
    not provide a RAI to an MS in PMM-CONNECTED state. An exception is
    after an SRNS relocation, in which case the new SRNC shall indicate the
    RAI to the MS.

    From what I can see, this is how it is also done in practice, i.e. a
    RAU is only performed once Cell-DCH state is left.



  3. Hi Martin,

    Thanks for the explanations. Just to confirm one point: if I understood you well, if SRNS relocation occurs but the same SGSN/MSC is used, real networks don’t send the RAI information to the UE, and the RA update is delayed until the Cell_DCH state is left. Is it what you said you saw?

  4. Hi David,

    The way I read the spec it says that a rau should (not must!) be made when the serving rnc changes while being in NAS connected state.


Comments are closed.