Monday, March 29, 2010


This is in continuation to what I wrote some time back. (here)
TAU corresponds to Tracking Area Update in LTE and RAU corresponds to Routing Area Update in GERAN/UTRAN. A TAU or RAU is initiated by UE when it detects a new tracking area or routing area. Below call flows show how a UE performs RAU in GERAN and TAU in LTE when both GERAN/UTRAN and LTE networks are converged using Gn interfaces.
LTE UE's are expected to operate in dual mode, i.e support both LTE and UTRAN and more over both the radios are expected to be turned on all the time. Below call flows are with reference to Annex D of 23.401. SGSN is considered to be Gn based and MME is expected to support GTPv1. This means no changes to the existing 3G network (SGSN) is required to support below.
LTE - Routing Area Update


Looking at the call flow we can see that GGSN is missing. It is believed that to implement above both GGSN and PGW must reside on single box. So PGW is acting as GGSN for 3G world and it remains itself for LTE. PGW shall again speak both GTPv1 and v2 and will be responsible to map the contexts and qos (of 3G and 4G).

Once UE detects that it is in 3G world it immediately triggers a Routing Area Update. We are assuming that UE is registered in LTE domain now. Once SGSN gets the RAU it looks for the old SGSN information to pull the UE context from (P-TMSI ?).To a Gn SGSN MME just acts as an another Gn SGSN. So the Gn SGSN sends SGSN context request to MME to which MME replies with the UE context. Later an Update PDP context is sent to GGSN(i.e PGW) to inform the change in the data path. At this point PGW shall map the LTE bearers to 3G PDP;s

LTE - Tracking Area Update


Similarly when UE moves from 3G to LTE it triggers a tracking area update.

Clearly the above are not handovers. Both TAU and RAU are triggered by UE which means UE is responsible for choosing the corresponding technology. Also this method might not be seamless too.

More thoughts on this?


Rakesh said...

I found that Tracking Area Update been send in following other events.

- movement to UE to the new tracking area, where UE was not registered earlier.
- on expiry of tracking area update timer.
- UE was in UTRAN PMM_Connected state (e.g. URA_PCH) when it reselects to E UTRAN;
- UE was in GPRS READY state when it reselects to E UTRAN;
- the TIN indicates "P-TMSI" when the UE reselects to E-UTRAN (e.g. due to bearer configuration modifications performed on GERAN/UTRAN);
- the RRC connection was released with release cause "load re-balancing TAU required";
- a change of the UE Core Network Capability and/or UE Specific DRX Parameters information of the UE.

Rakesh said...

Also Fully agreed with PGW speaking in both GTPv1, GTPv2 language, GGSN will just shrink into the PGW in LTE network.


Anonymous said...

My EPC strategy is to migrate to a production PGW release once it becomes commercially available from my vendor. It simplifies charging. There are also some back-end dependencies on FQDN for the APN name that need to correlate LTE NAPTR queries to the legacy 3G APN DNS. I think the real hurdle is getting the 3G to LTE hand-off....especially in a multi-vendor environment.

Vijay S said...

Hi Guys,
can someone point me the spec where I can find the exact call flow for periodic TAU?


Santosh Kumar Dornal said...

There is no call flow for periodic TAU in spec..just remove all messages except for TAU Req and Accept and you have a call flow for periodic TAU. Note that periodic TAU is an idle mode procedure.