GTP Version Fallback

I had a discussion with my colleagues about GTP fallback mechanisms. While 3G/2G allows GTP fallback from V1 to V0 over Gn interface the same is not true for S11 interface. LTE is designed all the way to speak GTPv2. However if you look at 3GPP TS 29.274 (section 7.10), there is an interesting section pointing to Fallback to GTPv1. Of course, refer to the latest revision of the spec as things have changed from older revisions.

A GTPv2 entity may fall back to GTPv1 when the other entity responds to a GTPv2 message with GTPv1 Version Not Supported message. This is a pretty much valid and straight forward case. If a UE is moving from UTRAN/GERAN to LTE using Tracking Area Update, then MME may request for UE context from SGSN over GTPv2 message if S3 interface is configured. But if SGSN doesn’t support S3 interface then it may send GTPv1 Version Not Supported to MME. MME in this case may fall back to GTPv1 and may request the context from SGSN over Gn interface.

The second scenario deals with S16 interface, about which I never ever thought of. S16 interface is between 2 SGSNs and is GTPv2 interface. If SGSN deployed is S4 SGSN then the two S4 SGSNs communicate over S16 using GTPv2. As far as I know S16 interface deployment is going to take a lot of time, but it is an interesting case. Now assume that UE is connected via S4 SGSN to a GGSN. Remember that though SGSN supports S4, the current scenario is that the UE is connected to a GGSN over GTPv1 interface. Now the UE moves to a new S4 SGSN using Routing Area Update. The new S4 SGSN may use S16 interface to fetch the UE context from old S4 SGSN. But the old S4 SGSN established the UE context over GTPv1. So the old S4 SGSN may send GTPv1 Version not supported to new S4 SGSN. The new S4 SGSN may now request the UE context over Gn using GTPv1. Thus the fallback to GTPv1.
This kind of detail in the specification is amazing and hats off to the GTP authors.

Simply Brilliant! Vodafone femto hacked!

Must read! 

http://thcorg.blogspot.com/2011/07/vodafone-hacked-root-password-published.html

MME Pool – Load Balancing and Re-balancing

Reference - 3GPP TS 23.401 Section 4.3.7

As LTE is planned for larger deployment it is time to look at the load balancing and redundancy among the various core network nodes. I would like to present how a MME load balancing and redundancy can be achieved in this post. I will follow up this post with SGW and PGW pooling.

A MME in the network is identified by MME code and Group id.  Each MME will have a weight factor configured that is conveyed to eNB during initial S1 setup.  An eNB can talk to multiple MMEs in a pool. Based the weight factor eNB will decide which MME can be loaded with calls to what level. Assume that an eNB is communicating with 2 MMEs in a pool. MME-1 has weight of 100 and MME-2 has weight of 50. This means eNB, out of 3 UE attaches, will forward 2 attaches to MME-1 and 1 attach to MME-2.  If in case MME-1 is down, then all calls will be routed to MME-2. This is one way of achieving load balancing and redundancy. 

There is another way to achieve load rebalancing. This is the case when a MME feels overloaded, it can simply move the calls to other MME in a given pool. Assume above example. MME-1 has been overloaded and cannot handle any more calls. If MME-1 wants to free up some resources, than it release the S1 connections of UE towards eNB asking UE to perform a “load balancing TAU”. This is conveyed to UE by eNB in a RRC message. Once UE gets this message it shall send a Tracking area update message which is routed to MME-2 by eNB. This way MME-1 can gracefully move calls to other MME-2.  It is assumed that MME-2 and MME-1 are connected over S10 interface as MME-2 should pull the UE context from MME-1. 

If the MME is feeling overloaded, then it may also send Overload Start message to eNB asking it not to forward any calls to it. If necessary resources are available then MME may send Overload Stop indicating that it is ready to accept new calls.

Another way of achieving load balancing is using DNS at eNB. If UE is NOT connecting for the first time then it will populate GUMMEI to eNB in one of the RRC messages. Based on the GUMMEI eNB can perform a DNS query to obtain MME information and forward the UE messages to that particular MME.  If the selected MME is not responding then eNB may forward the call to next available MME in the pool.

I believe this should help operators to plan their network.

Busy!

Dear all, I am terribly busy these days and unable to post anything in the blog. I have all your emails with questions in my follow up list. Please bare with me for some more time, I shall get back to you all with my views.

Cheers, Santosh

Wired N Wireless completes 2 years

With over 160,000 hits, this blog completes 2 years. Thank you for the support and wish you all a very happy new year.

Cheers, Santosh 

Verizon 3G to LTE Handover Delay

This is purely my thought and may not be entirely true.

I read news that users of Verizon network are experiencing a delay of 2 minutes when moving from 3G to LTE network. Users are experiencing this when they are continuously transmitting the data. I also read that in few instances subscribers are forced to unplug their dongles and plug them back to get LTE access. I was wondering what could be the reasons and below is what I think!

Frist Reason:-

Verizon network is CDMA based. LTE is GSM based. Since both technologies are entirely different it gives an impression that handovers are not going to be smooth. However 3GPP specs does provide solutions for smooth handovers. So why the delay? The places where LTE is deployed would have had 3G coverage. When a 3G network detects that UE is receiving stronger 4G signal it has to handover the UE to 4G network. But not complete 3G network would have been converged to 4G, so in few cases the 3G network would simply ignore 4G networks presence and make the UE to hook on to it. In this case users should stop transmitting data for a while so the UE may go into idle mode. Once UE is in idle mode and if it wants to send some data, it will perform cell re-selection and choose LTE network instead of 3G thus bringing subscribers back to LTE. This could be one reason why few subscribers had to plug out their dongles and place them back to get 4G access.

Second Reason:-

Next, assume that 3G network is converged to 4G. In this case moving from 3G to 4G should be smooth. But if the network elements are far away then the delay in the core network might result in higher handover time.  However movement from 4G to 3G should be smooth, because where there is 4G network, 3G network would have been present and 4G network would have had complete information about it.

The fixes could go in several places. But I am assuming that first reason is what bothering the most and network should be fixed soon. Those who are interested to know more can refer to 3GPP Spec 23.402 for detailed call flows.

Vodafone launches LTE in Germany

On Dec 1st 2010 Vodafone D2 in Germany has gone live their LTE network. The porject was towards offering high speed boradband in rural areas of Germany. Hope fully everything is going smooth for them.

Link here

Is anyone experiencing the LTE network in Germany? How is it working? Any comments.

LTE - Indirect Tunnel during Handover

LTE is a high speed network with an assumption of always on connectivity to packet data network even when UE is moving at high speeds. So during the handovers it is assumed there is no packet loss. But when UE is moving from source network to target network, there is definitely a connection break and make. While the connection is broken and again made at target network, the data to UE is buffered at the source eNB and forwarded to target eNB once the handover is complete. If there is a direct link between source and target eNB then data buffered at the source eNB will sent over it to target eNB. Else indirect tunnel will be used . Below figure shows S1 Handover with SGW Relocation when Indirect Tunnel is used.
 

 This post specifically concentrates on how the buffered data will flow in case of indirect tunnel. Cristina in her blog has very clearly written about this, but I would like to make rather simple explanation

The links in “orange” are normal links and links in “black” form a indirect tunnel. The source eNB decides whether direct tunnel is present or not. If direct tunnel is not present, source eNB SHALL NOT include “Direct Path Forwarding Availability” IE in Handover Required message. To make things a bit simple I am assuming that MME has NOT been re-located, but considered that SGW is relocated. Once MME receives the “Handover Required” message it sees that target eNB is being served by another SGW. So MME will create a new session with target SGW and sends “Handover Request” message to target eNB. Target eNB shall respond with “Handover Request Success” and includes “indirect tunnel DL TEID” that is to be used by target SGW for indirect tunnel, along with normal S1-U DL TEID.  Once MME receives this message it shall forward “indirect tunnel DL TEID” to target SGW in “Create Indirect Tunnel Request message”. Now the target SGW gets to know the TEID which it should use for sending data over indirect tunnel and also gets ready to receive the data from source SGW. In Create Indirect Tunnel Response target SGW sends the “DL TEID” that source SGW should use to send data over indirect tunnel towards target SGW. This information is conveyed to source SGW by MME in “Create Indirect tunnel Request”. Now source SGW gets to know that indirect tunnel is created, so it sends a “UL TEID” that source eNB should use to buffered data over indirect tunnel to it. This TEID is sent to source eNB in handover command. This completes the indirect tunnel.

The data flow will be:-
- Source eNB buffered packets to Source SGW over UL TEID that source SGW sent.
- Source SGW sends packets to target SGW over DL TEID that target SGW has sent to MME, which was forwarded to source SGW.
- Target SGW sends packets to target eNB over DL TEID that target eNB has been sent to MME which was sent to target SGW.
 

I know this is bit confusing, but here it is.

Policies and Rules

With LTE ready for deployment, it is becoming increasingly important for operators to provide dedicated bearers. I had a chance to look at 3G demo, here in India, by one of the operators, and I was not pleased. There was an attempt to stream live TV over 3G supported mobile and stream was pretty bad. I was just wondering how far the base station was and if there was any secondary PDP context in place for enforcing a proper quality of service. Well that’s 3G.

In LTE PCRF is responsible for charging and triggering flow rules. PCRF is an intelligent device which based on the ongoing traffic or existing configuration triggers events towards PGW. There sits PCEF on PGW which is responsible for enforcing the rules triggered by PCRF. The interface between PCRF and PCEF is Gx.  Based on the triggers PCEF can go ahead and ask PGW to create a dedicated bearer or modify an existing bearer.  UE can request for a bearer creation or modification based on its need. But final decision is with PCEF. On other note I was wondering if LTE UE manufacturers would present any piece of code to mobile application developers for requesting a dedicated bearer for their app?

LTE is supposed to be a high speed network. Will creation of dedicated really matter at such high speeds? Will streaming video all of sudden get better once a dedicated bearer is created for it? Has any operator tested this? How does the result look?

S4 SGSN

As the LTE deployments are nearing it is becoming increasingly important to bring in smooth handover support between 3G/2G and LTE networks.  The networks are on expansion and are becoming complex. In amidst of all, different solutions for same problem is making life a bit more difficult. 

While we have a initial solution in place for migrating from 3G to LTE without changing much in the existing 3G network, it has been noticed that the service providers are now thrusting for a more smoother solution. Identifying few pockets of areas service providers are now willing to upgrade their exiting 3G network to be compliant with Release 8. I pity the SGSN for the burden it has to take to not only perform the existing functions but should also start processing LTE related calls. 

If the SGSN is migrated to Rel 8, then it has to support two new interfaces. S3 and S4. S3 is between MME and SGSN analogous to Gn interface. But S4 is totally new interface to SGSN analogous to S11 interface. The question is whether a S4 interface is needed at all. When a UE moves from 4G to 3G, SGSN requests for Context Information from MME over S3 interface. If the interface is Gn then protocol would have been GTPv1 which doest create any trouble for SGSN. As S3 is GTPv2 based, SGSN should implement the new protocol. So far so good. Anyway UE is in 3G network, SGSN has pulled the UE information from MME over S3, then what is the need for S4 interface. SGSN can as well simply go and talk to GGSN. Instead of this 3GPP has decide to route the SGSN to SGW over S4 interface. This is mainly done to remove the GGSN node as such. 

We know that LTE APNs are configured in PGW.  The idea is to reach the same APN in the PGW when UE is either connected from 4G or 3G or 2G. Which means in 3G and 2G it will become the responsibility of SGSN to talk to PGW through SGW. This will simply need no GGSN at all for LTE APNs and more over everything is Rel 8 compliant. The compliance will ensure smoother handovers and continuous data flow. So when a UE directly switches on in 3G network, SGSN will contact SGW for the establishing a session. When there is a handover involved again, SGSN will contact MME over S3 and SGW over S4. Ultimately for 4G APNs there wont be a need for GGSN and PGW to co-exist. Another important thing here will be support for IPv4IPv6 PDN types. This PDN type is not supported in 3G and is a feature of LTE. To ensure that this PDN type is supported over 3G the SGSNs should be Rel 8 compliant. 

Hence, SGSNs are overloaded.