Understanding SRVCC – Part 1 (Updated)

It’s time to set aside the voice issues and embrace LTE!

SRVCC stands for Single Radio Voice Call Continuity. This is the official 3GPP solution for voice over LTE. There is CSFB too, but it’s pretty lousy and supposed to be an intermittent solution. SRVCC is the long term solution proposed by keeping IMS network in view. It will be a perfect solution when the whole work has IMS deployed and still have 3G/2G networks running. There was a significant debate about VoLTE solution but seems like world is moving towards IMS, atleast in my little mind. :-)

SRVCC is supposed to continue, an IMS call on LTE network, seamlessly over a 3G/2G network. 3GPP TS 23.216 deals with this solution. Major requirement is NOT to have UE connect to 2 different RAT’s simultaneously. This means more battery life on handsets! 

For SRVCC to work there is a need for Sv interface between MME/SGSN and MSC. MSC needs to communicate with IMS network over ISUP interface? This means a software upgrade on MME/SGSN/MSC is needed. No special changes are need on SGW/PGW/GGSN. No additional functionality is required on EUTRAN, other than it has to detect UTRAN and GERAN. HSS needs to send couple of additional flags. PCRF is required to enforce a bearer over QCI 1, dedicated voice bearer? UE is expected to send few SRVCC IEs during attach procedure and is expected to be IMS capable. 

Assuming all the above is done and IMS network is in place, a UE will now make and receive voice calls over LTE via IMS network. While on a voice call over LTE, if EUTRAN detects that UE is moving towards a UTRAN/GERAN, it will initiate a handover procedure for UE towards the SGSN. A PS handover will be initiated for all bearers except for the one with QCI=1. MME will then initiate a PS-CS handover for QCI =1 bearer towards MSC. At this point MME is dealing with CS handover and PS handover simultaneously. Assuming everything went right, all PS bearers are successfully handed over to SGSN and CS bearer is handed over to MSC for continuation of 3G. The voice call now continues via MSC -> RAN -> UE. While in 3G if UE makes a call, the call lands on MSC then on IMS? 

This is a very brief description will post detailed call flows soon, refer to 3GPP TS 23.216 for more details.

More Links

Qualcomm Tests SRVCC
http://www.engadget.com/2012/02/02/qualcomm-chips-complete-first-successful-voip-over-lte-to-wcdma/
http://gigaom.com/broadband/qualcomm-ericsson-just-brought-mobile-calls-into-the-ip-age/

ATT and IPhone

Some time back I got hold of an IPhone from ATT and did a field test. It releived quite an interesting results and gave a blue print of ATT network. Field test application can be invoked using keypad and by typing *3001#12345#*. It shows a lot of information about cellular network including RRC, NAS and PDP context. I tried to analyze some part by taking a bus ride, from one place to another, which is apporximately 5 miles.

Routing Area and Cell id 

Cell id kept changing every quarter to half a mile. Routing area changed every mile to 2. A cell id change mean that there was a NodeB change and Routing area change indicates that RNC has changed. I hope location reporting for cell id is not enabled, otherwise there will be so many updates to the network. Imagine a bus loaded with 40 people out which atleast 20 are carrying phones by ATT network. This creates 20 cell updates at almost same point. Cell Id update is optional so I am sure the cell id update must has been turned off in the network.

But Routing area cannot be avoided. Which means the network was receiving 20 Routing Area Updates every 5 mins from the bus. So if you combine the traffic that is outside the bus, during a peak time, its is quite a load on SGSN/RNCs to process the routing area updates. Unfortunately every Routing Area needs to be reprted to SGSN, but with LTE and concept of Tracking Area List the updates can be significantly reduced. But again that will depend on how the network is designed. During attach in LTE, network may send a max of 16 tracking areas and If UE is moving across those tracking areas then there is no need for a Tracking Area Update.

PDP contexts 

The IPhone atleast opens 2 primary PDP contexts. One is for regular data and other is for visual voice mail. Now another interesting thing, for pulling an voice mail, phone always connects to a different APN, this means voice mail can be given free of charge without much of hassle. Because voice mail APN can be a plain APN withouth charging or DPI turned on.. On the other hand if voice mail is pulled from regular APN, then DPI needs to be turned on the APN and voice mail traffic should be zero rated. Its an absolute pain. So the work aroud is to make phone connect to different APN.

I was wondering, if a Phone is bought unlocked then how to make it connect to two different APNs. I know that I can trigger another primary pdp using a console connection and AT commands, but how do we do it from a phone. May be that is one of the reasons why ATT doenst unlock IPhones.

There are still some more interesting aspects to look at, but I will leave it you. Will grab an LTE phone and perform some more tests as and when time permits.

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