Merry Christmas & Happy New Year

Ian still around and answering emails for the 3rd year. Still plenty to come in new year as mobile networks evolve. Wish you all a very happy Christmas and new year. Thanks & Regards, Santosh

Location Reporting!

There was one interesting feature in Release 7 that dint make it to LTE in Release 8, however it has introduced as part of Release 9. I am talking about Location Reporting feature.

A PGW/GGSN needs to know the exact location of UE/MS so that it can do location based charging. Other reason why PGW/GGSN needs the exact UE location could be for lawful intercept. Any more reasons? 

Anyway the UE location is propagated by MME/SGSN to PGW/GGSN over ULI IE (User Location Information). Whenever a UE changes a cell or routing area or tracking area MME/SGSN may inform the PGW/GGSN about the same using location change reporting feature. In pre-release 7 if the UE moves from one routing area to other that is under same SGSN then there is no message over Gn interface towards GGSN. So how will SGSN send the User location information IE with new RAI to GGSN? There is a GTPv1 message called “MS Info Change Notification Request” that SGSN may send to GGSN indicating the UE location. GGSN, based on this, can do location based charging. 

This feature is missing in Release 8. Oh shoot! We completely forgot about it. Lets put in Release 9. 

In LTE the location reporting may be achieved in following way. First if MME/PGW supports location reporting then MME will ask eNB to report UE location. So, as and when UE moves from one TAI to other or from one cell to cell eNB will send Location Update message to MME. But how to propagate this info all the way to PGW? According to release 8, there is now way to do it. MME has to wait for the next available GTP message to send this information to SGW/PGW. Which means a cell change may never be reported to PGW or you need to have a eNB with just one cell under it and that is just covering one TAI, so that when UE moves from once cell to other there can be a handover and MME can send Modify bearer request to SGW with the ULI. This is little too much. So 3GPP Release 9  brought back the support for “Change Notification Request”. If UE moves from one cell to cell, MME may now send Change Notification Request that can be propagated all the way to PGW and PGW may further send UE location to PCRF or charging server. Thus bringing back location based charging. 

Refer to 3GPP TS 23.401 v 9.9.0 Section 5.9.2 which was missing in Release 8.

Release 7 equivalent is in 3GPP TS 23.060 Section 15.1.3.

Understanding ISR

Very detailed post from 3G and 4G blog.

http://3g4g.blogspot.com/2011/08/look-at-idle-state-signalling-reduction.html

Link to a old post in this blog.

http://wired-n-wireless.blogspot.com/2010/06/idle-mode-signaling-reduction.html

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