Wired n Wireless

Wi-Fi Offload

2012-04-27T11:53:00.000-07:00

Small cells are good way to increase coverage of mobile network and serve densely populated areas like malls, concert halls etc. A Femto cell is one solution while other seems to be Wi-Fi. Wi-Fi Offload is becoming a lucrative option to offload mobile data for service providers, as Wi-Fi is cheap; Wi-Fi is everywhere and is integrated into the most of hand held devices. But there are quite a few hurdles to pass through before offloading the data over a Wi-Fi. There is quite a lot of work going on in 3GPP standards to smoothly integrate the Wi-Fi network into 3GPP network.

You can download it from flickr.

I saw that ATT gives away connectivity to their Wi-Fi hotspots free as part of mobile data subscription. To understand Wi-Fi offload better, I picked an ATT IPhone and drove to nearest Starbucks with a Laptop running Ubuntu and tcpdump, in an attempt to capture the traces and understand protocols. To my surprise I observed that Wi-Fi network was free to everybody, with some terms and conditions to accept, and not to just ATT subscribers. Also the whole Wi-Fi network was un-encrypted. 1 minute capture lead to 8 mega bytes of data from all the users. I got back and did a Google search. It seems that ATT hotspot at Starbucks is free for everybody and is un-encrypted. Some more research showed that all premium subscriptions for Wi-Fi needed users to login into an http portal for authentication. Even the premium subscription doesn’t get you encryption over Wi-Fi RAN. ATT on their website recommends connecting to VPN when connected to publicly available Wi-Fi. With these challenges, I personally wouldn’t want to connect any publicly available Wi-Fi.

What will make a Wi-Fi offload truly a small cell solution and attract many more subscribers?

- Wi-Fi network connection should be seamless with minimum user interaction

- No web portal authentication. If I am subscribed to a premium service, let the network figure it out and award me services without my interaction.

- Encrypted Wi-Fi RAN.

- IP address preservation upon moving to a mobile network.

Requirements for one may be different from other and depends on the business model. I believe we should be able to at-least achieve these requirements to call offload a “true” offload. The technology exists and inter-connections should be laid out.

EAP-SIM exists for seamless authentication and Wi-Fi RAN encryption. Stick up a gateway in between Wi-Fi RAN and mobile network to maintain the same IP address across the networks and enforce the mobile network policy. Connect AAA/HLR to the Wi-Fi gateway for authentication/accounting. This is an immature description, will post more call-flows and adjust the network diagram soon.

Fallback to older RAT for throttling

2012-04-24T17:00:00.001-07:00

We all are, painfully, aware of service providers applying fair usage policy, beyond a certain limit of data usage, by throttling mobile data speeds. Typically this is done using a PCRF/OCS. With latest revisions of 3GPP (Release 9) we can achieve FUP just by using PCRF. However I want to put forth another way of doing this. Push the LTE subscribers to UMTS after a data threshold; similarly push UMTS subscribers to GPRS/EDGE. Don’t kill me; I am just stating another feature of 3GPP :-).

Few years back we had GPRS/EDGE widely deployed, with UMTS coming in a new network was deployed along side of GPRS/EDGE. Also LTE is going to co-exist with UTRAN/GERAN. As of now most of the devices that do data are 3G capable and are always hooked on to UMTS/HSPA. The numbers of 3G/4G capable devices are on the rise leaving the GPRS/EDGE network least used. What if we push the 3G subscribers to GPRS/EDGE after a certain limit? This way we could still utilize the GERAN.

I am not sure of limitations on radio side, but from core network it seems like a simple feature. HLR/HSS store information about subscriber and can dictate which Radio Access Technology (RAT) a UE can connect to. Refer to 3GPP TS 29.272 and look for “Access Restriction Data”. The AVP has values like “UTRAN Not Allowed”, “GAN Not Allowed”, “E-UTRAN Not Allowed” etc. Based on these values MME/SGSN will either allow or block the UE from accessing a corresponding RAT. Typically blocking a RAT will lead to an “Attach Reject” with definite “Cause” towards an UE. Assume a UE is blocked from E-UTRAN, so when that UE tries to gain E-UTRAN access, MME rejects the Attach with Cause “EPS services not allowed”. This will stop UE from connecting to E-UTRAN, until it is switched off and switched on. Similarly we can achieve this over UTRAN and make UE fallback to GERAN.

Downsides

Identify the subscribers whose data threshold are hit and re-program the HSS/HLR to block access. Once billing cycle is complete re-program the HSS/HLR again to allow access.
What happens when the coverage for the enforced RAT is not present? Assume the subscriber is pushed to GERAN and he/she is in a location where GERAN is not available.

This is pretty lousy solution to implement, but achievable. Nice way to implement is rate limit the subscriber using PCRF. We could still use this feature to block certain users from accessing a RAT all-together, which is reasonable.

This shows the amount of control a mobile network can have over a subscriber!

Juniper MobileNext Platform

2012-04-18T12:04:00.002-07:00

The number of subscribers using mobile network is on the rise day by day. It’s just not humans any more, its also machines. Machine-to-machine communication is expected to explode in the very near future. To support millions of subscribers and machines, there is serious need to build scalable networks right from the RAN all the way through to the core. It’s just not enough to build a scalable network, but also ensure the quality of experience. With machines the critical data is expected to make it to the servers on the other end of the mobile network without any loss. Imagine ATMs running on mobile networks!

Image Source

In this regards Juniper Networks has released a performance report for the MobileNext Broadband Gateway which seems very impressive. Juniper MobileNext GGSN/PGW was independently validated, for performance & scalability, by EANTC using Spirent tools.

European Advanced Networking Test Center (EANTC) is internationally recognized as an objective test center. They provide vendor-neutral network performance test facilities for manufacturers, service providers and enterprise customers.

MobileNext is truly a distributed platform with clear control and data plane separation; enabling the GGSN/PGW to host millions of subscribers and simultaneously pump huge amounts of data traffic. The numbers are clear in the below chart. Juniper claims that the MobileNext Broadband Gateway can host 8 Million Subscribers; transfer 434 Gbps of traffic with zero loss along with an activation rate of 48,000 sessions per second (168,000 transactions per second), all being done concurrently in a completely redundant system.

Without redundancy MobileNext Broadband Gateway can host up to 12 Million Subscribers; transfer 551 Gbps of traffic with zero loss and handle 72K activations per second.

Do we really need such a powerful device in the mobile core? Yes we do. Let’s take the direct tunnel case in 3G. If subscriber goes to idle mode, the direct tunnel is taken down by SGSN and when subscriber becomes active again a direct tunnel is created by SGSN. A Direct Tunnel create and delete leads to 2 transactions on GGSN. If there is charging trigger enabled for direct tunnel creation and deletion, count another 2 transactions. Now multiply that by the number of SGSNs/RNCs and subscribers. The number of transactions is quite significant, especially for a large operator. Older generation hardware needs a gateway to be added every time there is an increase in transaction rate or data rate.

Another reason for need of high performance is machine to machine communication. Assume that smart meters are hooked on to the mobile network and are programmed to update the server at 6 in the morning in a location X. So at 6 in the morning there will be a bulk of create pdps followed by data transfer followed by delete pdp’s from location X. If we allocate different time slots for smart meters in different locations to update, there is constant pressure on the GGSN/PGWs to handle the high rate of transactions and data transfers throughout the day. Loss of data becomes a very critical, as a meter reading might be lost.

Small/Hybrid Cells and wifi offload is going to bring in many more subscribers and stress on the network. Not to forget the new devices and fancy applications that are melting the networks every day. Considering these aspects, the need for high performing and reliable mobile core is needed today and I believe we need these kind of platforms to build a scalable networks and ensure quality of experience.

IMS Emergency Calls over LTE – Short description

2012-04-04T14:34:00.000-07:00

As operators are moving towards LTE, the need for emergency calls support over LTE is high, as they have to comply with local authorities. 3GPP has defined a nice procedure for emergency calls in Release 9(?). The support for emergency calls is required across the network and UE. Below is how the procedure works.

First thing to consider is any UE can make an emergency call, provided network supports it. This means there is no subscription for that UE in HSS. This also means there is need for an emergency APN to be defined! I will avoid eNBs here as RRC always goes above my thinking capabilities.

When UE wants to perform emergency attach, it will send an attach request with attach type as Emergency Attach. Upon receiving this attach MME may or may not contact HSS for Authentication. If MME supports, then call may proceed even if Authentication fails if at all HSS was contacted. If authentication fails then MME may not contact HSS for Update location request. In a nut shell, when Emergency Attach is received Auth/Security procedure becomes optional.

This brings the next point. APN. This is where 3GPP defines the magic term “MME Emergency Configuration Data” that is needed on MME, where Emergency APN is stored. Optionally QoS parameters and static PDN gateway address can be stored. So upon receiving an emergency attach MME knows where to send the Create Session Request.

Another thing to note is a UE may not send IMSI in the attach request, if it doesn’t have one. Well, I should be able to make an emergency call even if I don’t have a SIM card. In this case IMEI is required. Basically mobile network is doomed without IMSI or IMEI. This needs SGW/PGW to be prepared for receiving Create Session requests without IMSIs or IMEIs. Another software modification! The QoS values, like ARP can be statically configured on MME or if Dynamic PCC is deployed then PCRF may provide these details. The PDN created for emergency service cannot be per-empted, so proper ARP values should be used. It is also expected that Emergency APN supports IPv4v6 PDN type just to be on safer side.

Once everything is set, MME may send Create Session Request to SGW/PGW and based the Response the attach procedure may be completed. A UE may make an emergency call now. Once the call is complete UE need not detach. As soon as UE goes to idle mode, MME may go ahead and release the call.

There are several nuts and bolts described in 3GPP TS 23.401, 24.301 and 29.274 if you want to look at the procedure in detail.

Simultaneous CS & PS connections

2012-03-13T13:36:00.001-07:00

Ever seen ATTs “Only AT&T's network lets your iPhone talk and surf at the same time” ad? If not here is the youtube link.

Ever wondered why so much emphasis on network rather than phone? Well, this is a new feature on network . Not new exactly; this feature has been there since Release 5. Good to see that it is actually rolled out to production; otherwise it seemed very stupid to own a smart phone.

Ok! Here is how this is made possible. When a phone is switched on, it goes and attaches to the network. If phone is data capable, the phone does PS attach towards SGSN and CS attach towards MSC. Basically there are two separate radio control channels for data and voice and a phone can be hooked on to either one of it at a give time (not an expert on radio though). So if you are browsing, and MSC is paging the phone for a voice call, phone has to disconnect the GPRS session and receive CS paging over CS signalling channel which does make a smartphone look stupid.

For this sake 3GPP has done enhancements on network side. On the network side they introduced a new interface between MSC and SGSN, the Gs interface. This interface has been upgraded to SGs and further to Sv for CS Fallback and SRVCC features respectively. The additional Gs interface made phone to connect to both CS and PS service with one attach towards PS, which is referred to as combined attach. When a phone is powered on it looks for PS network and sends PS Attach Request with CS parameters towards SGSN. Based on the attach request, SGSN figures out the location area from routing area, finds out the MSC based on location area and sends location update towards it for CS attach. So with single attach UE is connected to both CS and PS services.

All is good. Now assume a case where phone is using PS services and has an incoming call. MSC sees the incoming voice call and sends a CS Page request to SGSN, because that is where the location update request came from, instead of UE directly. Upon receiving the CS page, SGSN sends paging request towards MS over PS channel with CS indicator. Since the paging request has CS indication the phone prepares of a CS call. Phone responds to the paging and MSC pushes the phone call toward RNC via CS voice channels. But the best part is phone can still have its PS connection continued while still having a CS connection. The trick is to not make phone listen on both CS and PS channels instead use one signaling channel on radio side and make SGSN and MSC communicate for CS services. I tried to capture the same in above call flow. This is a brief overview, there are many more procedures inside this for feature to work flawlessly. Also the network mapping between location area and routing area needs to done correctly. It’s all easy for a green field operator, but networks like ATT does need a lot of time and money. Hence the ad :-)

For more details, refer to 3GPP TS 23.060

OPNET Projects for Students

2012-03-04T11:05:00.000-08:00

I should have done this long back, but never too late. I have had several requests from students across the globe regarding projects on LTE. Most of the requests were related to OPNET. Unfortunately I don’t have enough experience of the tool and neither have time to explore.

This post is for the students who wish to share their experience/scripts/anything related to LTE for the benefit of other students. Please share your work under this post, also you can email me I will push it to the post. Students can use this blog as a platform to share their knowledge/Questions/experience with any tools/scripts. I will link this post to the right under “Projects for Students” section. Even students can get in touch with each other and share their work if they want to. Possibilities are limited to your discretion.

Thanks, Santosh

Understanding SRVCC – Part 1 (Updated)

2012-02-13T17:59:00.000-08:00

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

2012-01-29T13:34:00.000-08:00

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

2012-01-13T11:10:00.001-08:00

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

2011-12-25T11:20:00.000-08:00

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!

2011-09-08T17:37:00.000-07:00

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

2011-08-03T11:25:00.003-07:00

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

2011-08-03T11:10:00.000-07:00

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!

2011-07-14T10:30:00.002-07:00

Must read!

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

MME Pool – Load Balancing and Re-balancing

2011-02-23T06:36:00.003-08:00

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!

2011-01-31T01:28:00.000-08:00

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

2010-12-31T05:54:00.000-08:00

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

2010-12-14T07:45:00.000-08:00

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

2010-12-01T20:05:00.000-08:00

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

2010-11-28T02:11:00.000-08:00

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

2010-11-21T01:55:00.000-08:00

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

2010-10-10T01:37:00.001-07:00

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.

SDF, QCI and Dedicated bearers

2010-09-17T03:02:00.000-07:00

I had an interesting discussion with one of my friends regarding the dedicated bearers and QCI and thought of posting the same.

SDF- Service Data Flow- An aggregate set of packet flows that matches a set of filters.
QCI – QoS Class Identifier – A parameter that is typically associated to packet forwarding/scheduling etc treatments.

QCI values can be from 1 to 9. Since QCI is an 8 bit field it can have 255 values. Values 10 to 255 are operator specific. A bearer is always associated with a QCI. A UE can have a max of 11 bearers but QCI are from 1 to 9. Which means the QCI can be repeated for the bearers.

Each bearer is also associated with TFT. Yes, even the default bearer can be assigned a TFT after the recent spec changes. TFT can have multiple packet filters resulting in multiple SDFs. Now the confusion is with this statement - “Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI).”

Since two dedicated bearers can have same QCI the above statement leads to confusion. Reading the statement again makes sense. A bearer is associated with QCI and set of packet filters that will lead to multiple SDF’s. This means multiple SDF’s can be treated with same type of service but one SDF cannot be given multiple treatments. This also means that you cannot assign same packet filter to two dedicated bearers. Hence the above statement!

Roaming trouble

2010-08-25T21:07:00.000-07:00

What makes cellular communication standout from other wireless technologies is its roaming ability. No matter in which country you are just dial the number and talk. This makes mobile communication truly mobile. But the technology behind is not that simple.

I was wondering how difficult will it get for an operator to maintain so many roaming agreements. A given operator may have to maintain like, say, 100 roaming agreements. Well considering LTE a given MME will have to talk to 100 different HSSs and SGW will have to communicate to 100 different PGWs. Whoa!

There is a nice way to maintain the list of PGWs based on the various APNs. MME informs the SGW which PGW it has to contact for which IMSI. The S8 interface is UDP based and DNS maintains detailed records of APN to PGW mappings. So its relatively easy to fetch a PGW and establish a tunnel for the user. But for HSS its little complicated. Now that HSS runs on diameter, there are several solutions proposed to reach home hss from visiting network. Also diameter runs on tcp or sctp which means there is always a connection established. This is quite difficult as the MME has to reach several HSS across the world. Looking forward to some interesting solutions here. Diameter relays, proxies ?

CS Fallback - A Study

2010-08-17T21:33:00.002-07:00

We know that LTE doesn’t have basic voice and SMS support. To mitigate this 3GPP proposes fall back to CS network for voice and SMS. Though the industry pundits frown, I believe CS fallback has to be launched by operators deploying LTE, at-least for initial stages. Let’s look at how this works. In EPS a new interface is required to connect to the CS network. It’s called SGs, based on Gs interface, and runs SGsAP protocol. This interface is between MME and MSC Server. Next requirement is overlapping networks. It is expected to have a GERAN/UTRAN network along with EUTRAN for UE to fallback to CS. The concept is simple. UE will attach to the network through EUTRAN, MME will ask MSC to update UE location in its database, when a call is made or received UE is simply asked to fall back to CS network to answer/make the call. However note that sending and receiving SMS doesn’t need UE to fall back to CS network.

Few more details! When UE is attaching to EUTRAN, UE will perform a combined attached. That is a new IE, mobile class mark, will be sent in Attach Request asking MME to perform a combined attach. Once Attach request is received, MME will send a location update request informing MSC of UE’s location. This way UE is now known to LTE as well as CS network. When a UE has to make a call, it will simply send an extended service request to MME. MME will inform eNB that UE has to now move to GERAN/UTRAN network. If inter RAT handovers are supported, UE will be handed-over to GERAN/UTRAN network else UE’s EUTRAN connection is released and is asked to connect to GERAN/UTRAN. Because of this LTE services on UE will be disrupted.

UE attaching to EUTRAN & CS Networks

SMS is delivered over signaling channel. This means there will be no data path established to deliver or receive SMS. SMS will be sent over a signaling message. Exactly for this reason, SMS delivery or reception doesn’t need UE to fall back to CS network. Once the UE is attached to both MSC and EUTRAN and if MSC wants to deliver a SMS to UE, it will simply send a downlink unit data to MME with SMS content. MME will dump this message in NAS message and send it to UE. In the same way if UE wants to send a SMS it will dump the message in NAS message and send it to MME. MME will extract SMS content and send it to MSC over Sgs interface. This operation doesn’t need UE to fall back to CS network thus ensuring smooth delivery of SMS.

Mobile Orginated SMS delivery in Idle mode

One important thing to note here is that MME should keep a proper mapping of Tracking Area and Location Area. This is because MME needs to know to which MSC the UE should be connected to, based on the tracking area received in attach request. MME will map the tracking area to the corresponding location area and will pick the MSC based on the location area. All the details regarding CS Fallback are present in 3GPP TS 23.272. Refer to same for all the call flows.