DPI, Policy and Charging

I am particularly impressed by the amount subscriber management that 3GPP has provided. Per packet flow treatment per subscriber is super cool. However the implementation on mobile gateways is quite complex and need a lot of cpu and memory cycles. In simple words we really need powerful hardware sitting in edge with a efficient software to correctly enforce the policy and perform corresponding charging actions.  

Just to point out, 3GPP allows service provider to treat each subscriber differently based on the subscription. A subscriber may be allowed to use certain traffic or block certain traffic, certain traffic may be treated with higher priority and bill him based on the application or location etc. The limit is endless. A very good business model is needed to make it happen though. So to allow or block certain traffic from a subscriber the gateways need to look deep into the packets, detect the flows, apply policies and report to the billing system. This is quite a lot of pressure on the gateways.

I was doing a study of various telecom plans available across the world. Interestingly some service providers were offering services like free Facebook or free sport channel at a flat monthly rate or free email etc. This makes me wonder why we even need these plans with LTE. These plans are efficient when there is sever crunch of radio resources and subscriber doesn't  have fancy handsets, but with LTE the spectrum has widened and fancy handsets are becoming cheaper and cheaper. Will these plans still hold well?

For e.g a plan like free facebook will need the mobile gateway to look at all the packets  flowing from subscriber, zero rate it and then inform the same to the billing system. This churns a lot of bandwidth in term of cpu and memory cycles on the gateway. More over the software on the gateways needs to be highly efficient.

But there is other side to it. A subscriber may be offered limited data over a period of time but as token of appreciation allow a service free. For e.g I would be very happy if “Google Maps” is offered free along with my monthly of say 200 meg. I mean truly free here, that is actually look at the Google Maps traffic and zero rating it. But service provider may not want to do, so he may allow another 50 meg of additional quota and call it token of appreciation.  Duh!

In a nutshell, 3GPP subscriber management is amazing and I believe the broadband forum agrees. DPI, Policy and Charging are cool features on mobile gateways from engineering stand point. There are several other issues with DPI as people really don’t want service provider to look at their data. Anyway the service is available and I will leave it to the marketing to decide :-) 

 

I would like to hear from you. Would you like certain services to be free along with your subscription or would you like service to be free for a low monthly or weekly rate or any other plans you want to see in the market?

 

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

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.