Showing posts with label TAU. Show all posts
Showing posts with label TAU. Show all posts

Wednesday, April 21, 2010

EMM, ECM, RRC States, TAU and Handovers

Its very interesting to observe the connection between 5 terms mentioned in the subject line.

Refer here and here for details on EMM, ECM and RRC states.

EMM has two states:- EMM Registered and EMM De-registered. When a UE is connected to the network it moves from EMM De-registered to EMM Registered. Also the ECM state moves to ECM connected from ECM idle. Before these two happening the RRC state in UE is moved from RRC idle to RRC connected. So when UE is actively connected to the network the states in UE/network are RRC Connected, ECM Connected and EMM Registered.

When UE moves to Idle mode first the RRC connection is released. That is RRC state moves from RRC connected to idle. Then ECM state moves to ECM idle from connected. This mean eNB has released the RRC connection and network has released the UE bearer context information but EMM state is Registered. This is termed as S1 release in 3GPP TS 23.401. It would be interesting to know that ECM idle state is valid only on S1 and S11 interface. The UE information is actively maintained in PGW but is released in eNB and MME. Also the behavior of network in ECM idle mode is different in different cases. (future posts). The basic idea of idle mode is UE is not know to the network and in connected mode UE is known to the network. The term "known" refers to UE location, bearer information etc.

TAU - Tracking Area Update. A tracking area is a group of cells that are being tracked by a SGW. When UE is connected to the network, a list of tracking areas are sent to it. When a UE moves to new tracking area it will trigger a tracking area update procedure as defined in 3GPP TS 23.401. A TAU can be triggered when UE is in idle mode or connected mode.

Now at any given point of time UE can be in idle or connected mode. If UE is in connected mode and moving from one place to other then handovers take place. Note that handovers are transparent to UE except that UE now camps on to a new eNB. Also handovers are network initiated. This means a handover can happen when the UE is known to the network, i.e when UE is in connected state. Also after the handover if UE finds that it is present in new tracking area then it can initiate a tracking area update.

But a UE need not be in a connected state all the time. What happens when a UE is in idle mode and is moving from one place to other? When UE is in idle mode, MME will have the UE's last know location. So if some data arrives to UE, while it is in idle mode, MME will initiate paging process to find UE. Now if UE has moved from the last know location how will the MME know the UE's new location. This is where TAU becomes extremely important. In this case it is the responsibility of UE to inform about its location to network. This is done by sending TAU. As I said when UE is attached to the network MME sends a list of tracking areas. So if MME wants to find UE i.e is in idle mode, it will simply send paging message to the eNB and eNB will page for the UE. But if UE is in new tracking area, that is not in the list received during initial attach, it will initiate a TAU. Once network receives TAU it will store the UE's location info.

To initiate a TAU UE should have a RRC connection. First thing it does is it camps on to a nearest eNB by doing cell re-selection process. After RRC connection is established UE may send TAU to network. Note that ECM state in network is still idle for that UE. But TAU may move the ECM state in network from idle to connected. (future post)

Thus if we look at overall picture a handover can happen when UE is in EMM Registered, ECM connected and RRC connected state. A TAU may be initiated by UE when it is in EMM Registered, ECM idle and RRC idle state. Both the procedures help UE in its movement from one place to other.

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 5.3.3.1.

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.

LTE_TAU.jpg
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

GUTI = GUMMEI + M-TMSI

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.