Saturday, August 29, 2009

LTE : Tracking Area Update with SGW Change

After an hour of Metallica rock and few shots of Espresso I sat down on the saturday afternoon to understand the another handover scenario in LTE. Some time back I wrote about Tracking Area Update Procedure without SGW change. In this post I would like to explore Tracking Area Update procedure WITH SGW change. Ref : 3GPP TS 23.401

Before we dive into the post a quick note.

Tracking Area is the area/cell being tracked by an eNB. TAI change may indicate a change in eNB. Routing Area is the area/cells tracked by a SGW. So a SGW can track multiple tracking areas. The title of the post is little confusing. I say Tracking area update with SGW change and also say tracking area is taken care by eNB. Well if a eNB changes and the corresponding MME changes which may also lead to a SGW change. This is the scenario we are dealing below. The below picture should be of some help.

When UE detects that it has entered a new Cell then it begins a Tracking Area Update procedure by sending TAU request to the new eNB.
TAU Request : Tracking Area Request : TAU includes Active flags, EPS bearer status, Old GUTI, last visited TAI .. etc. EPS bearer status indicates each EPS bearer that is active in UE. Active flag is request by UE to activate radio and s1 bearer for all the active EPS bearer by the TAU procedure when UE is in ECM Idle mode. This message is sent along with other RRC parameters to eNB.
Once eNB receives this request it derives the MME from RRC parameters (which I have no idea) carrying the Old GUMMEI and indicated selected network. If this Old GUMMEI indicates the MME which eNB is not associated with, then eNB sends the TAU request to the new MME. This means that MME has changed here.
Before we dig more another very important note :
GUTI : Globally unique Temporary UE Identifier.
GUTI is an ID which uniquely identifies a UE in EPS without revealing the users permanent ID. GUTI is allocated by a MME which can be used to
  • uniquely identify the MME which allocated the GUTI
  • Uniquely identify the UE within the MME that allocated the GUTI


where GUMMEI = MCC+MNC+MME Identifier and MME Identifier = MME Group ID+MME Code

GUMMEI : Globally unique MME Identifier which is used to identify a MME uniquely.

M-TMSI : It is a ID of UE. The relation between IMSI and M-TMSI is known only to UE and MME.

Context Request : The new MME receives the TAU request from eNB. New MME uses GUTI received from UE to derive old MME and sends a context request to old MME. A context request includes old GUTI, complete TAU request, P-TMSI, MME address etc. Basically this message is sent by new MME to old MME to inquire about UE's authenticity, the bearers created if any etc.

Context Response: The old MME receives context request message and validates the UE. Upon successful verification of UE old MME responds with context response. Context response include IMSI, MEI, MSISDN, EPS bearers context, SGW address and TEID's etc. This response gives out all the UE contexts setup in old MME to new MME. The new MME receives this message and happily store the UE context in it and sends context ACK to old MME. Context ack is sent with "SGW Change indication" to indicate the old MME that SGW is going to change.

Create Session Request/Response: If there was no change in SGW there will not be this message. Now that we are dealing with a case where SGW has changed, MME sends a Create session request message to new SGW. Why? Because the new SGW has no information about UE and there is a no way that two SGW's can communicate directly (Correct ?) Create session request is sent with IMSI, bearer contexts, Protocol type on S5/S8 interface, RAT type etc. SGW reads the PGW address and TFT's from bearer context. Based on the S5/S8 interface the bearer is modified. If the S5 interface is based on PMIP we shall see a proxy binding update message and if GTP is the protocol then we shall see a modify bearer request to indicate the change in RAT type, SGW fteids etc. The PDN may contact PCRF for the other info which I have no clue. :)

Update Location : Upon successful reception of create session response, the new MME sends a location update message to HSS to indicate that UE has changed its location. HSS identifies the UE old location in its database and sends a cancel location to old MME. Old MME acknowledges the cancel location with an Ack.

Delete Session Request/Response: The old MME sends the delete session request to clear all the bearer contexts to old SGW. Old SGW acknowledges to it by sending response and deleting the UE contexts.

Finally the new MME sends a TAU accept to UE which is accepted by UE. Now UE is communicating with entirely new SGW.

There are just too many things in this procedure to cover. I just highlighted the important sections and hope I got it correct. Feel free to correct me if I am wrong and any comments are always welcome.

Note: Context Request and Response are GTPv2 messages. Two MME's communicate over S10 interface which is GTP based.


Bhavranjan said...

Hi Santosh!!

Thanks for this highly informative post,i have one query and seeking ur ans.After MME sends a location update message to HSS ,HSS sends a cancel location to old MME.Why it is required to cancel the previous location.

Santosh said...

To clear out any details on old MME and to inform old MME that UE has successfully moved to new MME.

Anonymous said...

can a TAU happen with MME change but no SGW Change ?

Santosh said...


Rauf said...

Thanks for the post. Any idea about performance requirements of TAU process in the term of time?


Santosh said...

3GPP NAS doesn't specify any processing time, it's implementation dependent, but if the entire is active and well connected, TAU should not take more than a sec.

suresh stambam said...

Hi Santosh,

Very informative blog.

I have a doubt could you please clarify?

By looking at the S1 messages TAU Req/Ack from eNB can we identify the whether it is for SGW change or not?

Thanks in advance.


Santosh Dornal said...

Look for TAI in S1AP message, MME does a DNS query using the TAI, based on what DNS returns SGW with relocated or not.