Friday, September 21, 2012

Ecosystems


Last weekend I wanted to watch a movie. Not the latest in theatres but a little older one. I have an Apple IPad, Google TV (Logitech device) and Laptop running on Windows and of course a TV.  Without thinking too much I went ahead and rented the movie from Amazon Instant Video service. Here starts the trouble.

For some reason Google TV decided not connect to the Wi-Fi network. I tried fiddling (too many Wi-Fi networks around) with it but it was too much pain, so I decided not to pursue further.  I downloaded the Amazon app on IPad and I could see my rental waiting. I play the movie and it streams fine on the 10 inch table. I wanted to watch it on a big screen, so I pull out HDMI cable from Google TV and connect to IPad. And guess what I only hear sound on the TV, no Video. I tried plugging in and plugging out couple of times but no luck. However I could see/hear the video on tablet just fine. I did a Google search and it seems Amazon App on IPad doesn’t allow the video to be played on TV. You can just watch the video on tablet but not on TV. It was Amazon’s choice to not support it. Common guys, seriously.

Finally I turn to the good old laptop. But to my dismay, laptop doesn’t have an HDMI port. Well, that sucks. So I was left with gadgets which don’t allow me to watch a darn movie.  I dropped everything muddled around with Google TV and got it working. I spent 30 mins to watch a 90 min movie. Better option would have been to pick up the DVD from local store, could have been much faster. (In this technologically advance cloud era I thought DVD players were extinct, so never really bought one)

This means, I have 4 large gadget makers or rather Ecosystems builders (Google, Apple, Amazon and Windows) who doesn’t want to co-operate with each other and make consumers life miserable. So much for technology! If you own everything from Google Ecosystem things might work fine, if you have all Apple it must be great. But 1 device from Google and other from Apple doesn’t go very well. Lesson learnt!  (Learnt few more lessons after upgrading to IOS 6 , no YouTube, no Google Maps)

On an aftermath, I realized things are not very different in telecom world. One vendor makes it as difficult as possible for other vendor to inter-op.  Proprietary AVPs, out of standard IEs, driving standards in favor of their implementations is very common, leaving telecom operator in a tragedy. It’s all about power and control. Not too different Roman Empire!  

Wednesday, August 8, 2012

Mobile Packet Core – Cloud and Virtualization

Off late there has been a lot of buzz around network virtualization. Software Define networks, Openflow, Nicira acquisition by VMware, Xsigo acquisition by Oracle, Wi-Fi virtualization by AnyFi are few instances.

In the similar lines I was wondering if mobile packet core can be placed in cloud and whether EPC can run on virtual servers rather than on custom built hardware.  As far as I know there is quite some work going on in that direction in the industry. To understand better I tried a little exercise to see if the idea is remotely possible.
One of my colleagues has registered to Amazon Web Services and got an instance of Ubuntu in cloud. That means he owns a virtual machine running Ubuntu which can reached from anywhere in the world by an IP address and a set of encrypted key’s. It seems it is very easy to setup an instance of linux using Amazon web services and machine is up and running in matter of minutes. I, myself, have seen over past few years the physical linux boxes in labs were being replaced with virtual machines. So virtualization is not a new thing after all. But providing a virtually instance in cloud, dynamically, and resources (Memory, network cards, processors) being allocated based on the need is something new and interesting. So my colleagues Ubuntu instance was up and running.
I took my GTP code, SGW, that I wrote years ago and ran it on the server.  MME was running on my local machine. Couple of firewall exceptions on server and boom, my local machine and ubuntu on cloud was nicely exchanging the GTP packets. Well, it’s a client server communication you don’t need to be an Einstein to make it work; as long as IP’s are reachable everything is supposed to work. So, here it is my first GTPv2 call over the cloud onto a virtual server.
It does make me believe that mobile packet core can be pushed to cloud and onto virtual machines. There are definite challenges, but over the years it seems to be possible. Imagine bringing up more virtual instances of EPC components during the peak hours and shutting them down during the nights. If there are bunch of machines that are going to send one time information during a particular time of day, we can get the virtual instances ready to take the explosion of messages and bring down the instances once the information is exchanged. Resource can be dynamically allocated based on need.
What do you think of this? Does this seem to be a viable solution?

Friday, July 27, 2012

Few thoughts on Policy!


I have received many emails regarding dedicated bearers and mobile networks policy interface in past few months. This directly shows there is good amount of work being put in to make Gx interface work by both operators and telecom vendors. While Gx interface has been sitting for a while in UMTS networks, it dint have any interaction with mobile devices. What I mean is Gx was mainly used to enable statically configured rules, mainly DPI rules, on GGSN and was invisible to UE, except that operators had opportunity to do all sorts of weird stuff using user’s data.  Drop, police, charge differently.. Net Neutrality?
However with LTE, Gx seems to be playing significant role by establishing dedicated bearers. Policy Charging and Rule function is responsible for activating rules that lead to dedicated bearer creation, send rating group information that is used for charging, control qos etc.
Gy is cousin brother of Gx. Gy is charging interface towards OCS that is mainly (not necessarily) used for prepaid subscribers. Both Gx and Gy are Diameter based interfaces that run over TCP or SCTP. With 3GPP Release 8+ Gx was also given function of Gy, by enabling Usage Monitoring. This solution is already present in most pre release 8 gateways as proprietary solutions. So nice of 3GPP for making it a standard!
When subscriber attaches to a mobile network, GGSN sends a message (Diameter credit control request) to PCRF. This message carries quite a bit of information about UE. See 3GPP TS 29.212 for more details. Once this message is received, based on the subscription, PCRF may return new Qos, charging rules etc. Based on information, received from PCRF, PGW/GGSN may create a new dedicated bearer or modify qos etc.   Typically in UMTS networks, PCRF sends Bearer Identifies in charging rules, which tell GGSN to which bearer these rules should be applied.  In EPS PCRF just sends the rules and PGW decides to which bearer these rules need to be applied to. This means in UMTS PCRF was doing bearer binding and in LTE PGW is doing bearer binding.
We all have heard of Data plans where operators throttle user data after a certain limit. This can be nicely achieved by using the usage monitoring functionality over Gx. When a subscriber is created PCRF allocates some data volume with some qos. After that volume is reached PCRF may send new volume with downgraded qos.  This is very hard to achieve, not impossible though, using Gx and Gy interfaces as Gy doesn’t have any insight of user qos.
There are several advantages of Gx interface but that comes with additional TCP processing on the Gateways and additional cost for PCRF deployment.  Will post more!
Just when I was going to post this, I noticed an interested presentation in 3G4G blog by Zahid regarding PCC! Head on
PS - I am terribly busy with work. Couldn’t post anything for some time!  I also ignored few comments/emails. Apologies :-)

Saturday, June 2, 2012

IMS Dedicated bearers



Email exchange! Hope it helps!

-------------------------------------------------------------------------------------------------------------------------------------
My understanding of VoLTE bearers:
  • A default bearer is automatically created as part of UE attach (This is UE-initiated IP-CAN session initiation). 
  • It is possible to also include a dedicated bearer for signalling on UE attach but this is not compulsory (This is UE-initiated IP-CAN session modification).  
  • A UE initiates an IMS session by sending a SIP INVITE message and IMS elements (typically the P-CSCF) triggers the activation of the dedicated bearer for the session via Rx/PCRF/Gx/PGW.  
  • Similarly when a session is terminated the UE sends a SIP BYE message and the P-CSCF triggers removal of the dedicated bearer via Rx/PCRF/Gx/PGW.  (This is network initiated IP-CAN session modification for the VoLTE dedicated media bearer.)
The problem I see with this is the following scenario
  • UE terminate an IMS call and sends a SIP BYE.  Typically the dedicated bearer is removed through Rx/PCRF/Gx.  BUT if the SIP BYE is lost in the network, the dedicated bearer remains and the user is still charged even though the call is "ended".
I think it is also possible to use UE initiated IP-CAN session modification for the IMS dedicated media bearer (I had a look at 4.5.1 Request for PCC rules in 3GPP TS 29.212 where it talks about IP-CAN session modification initiated by UE) - and I think it should work as follows:
  • UE sends SIP INVITE and initiates dedicated bearer activation which goes PGW/Gx/PCRF.
  • With SIP preconditions full IMS signalling only takes place once both sides have completed UE initiated dedicated bearer activation.  (Rx is still used but differently .. not 100% sure how)
  • When the UE terminates the call it sends a SIP BYE message and activates the removal of the dedicated bearer.
  • If a SIP BYE message is lost the dedicated bearer is still removed, the PCRF is informed, and in turn the IMS elements are informed via Rx.  The session will be fully torn down and charging will be stopped.
 -------------------------------------------------------------------------------------------------------------------------------------
- Have you explored anything in IMS that can provide a solution to lost SIP Bye?
- Is it a really good idea to rely on UE to establish/teardown the SIP signalling? How do you plan to interop with tons of UEs that will available in market soon.
- To me the solution should be driven from the network, based on the UE subscription. You can establish a non GBR dedicated bearer when UE is initially attached to the network for the purpose of SIP signaling, that can just stay there as long as UE is attached. QCI - 1 is designated for this. This will be inline with further SRVCC procedure.
- If dedicated bearer creation and deletion needs to be triggered by Rx, then I am afraid there is no trivial solution to deal with lost SIP Bye, unless IMS presents us with one.
-------------------------------------------------------------------------------------------------------------------------------------
If the signalling bearer is QCI 5 then the packet loss error rate is 10^-6.  This means that 1 in 1000 000  packets are lost.  So if the BYE is lost it seems likely that the signalling bearer will be torn down.  It is possible on IMS registration to register for notifications on the status of the signalling bearer - if the signalling bearer is lost then all media bearers are removed (no more charging) and the user is unregistered.

So maybe this is not a problem after all?

-------------------------------------------------------------------------------------------------------------------------------------
Regarding the QCI: From my understanding - the network will detect if the QCI guarantees for a bearer can no longer be met (i.e. if the signalling bearer - QCI 5 - can no longer receive loss rate of 10^-6).
 If this is detected the bearer will be torn down - PCRF informed etc.  Though I've yet to see this demonstrated I am pretty sure this capability exists in standard EPC.  So I think my original concern is
actually not a problem at all - what do you think?

Friday, April 27, 2012

Wi-Fi Offload

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.

Tuesday, April 24, 2012

Fallback to older RAT for throttling

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!

Wednesday, April 18, 2012

Juniper MobileNext Platform


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!


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.

Wednesday, April 4, 2012

IMS Emergency Calls over LTE – Short description


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.

Tuesday, March 13, 2012

Simultaneous CS & PS connections


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
 

Sunday, March 4, 2012

OPNET Projects for Students


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.

A new project by one of blog readers.

4G simulation based on OMNeT++ (similar to OPNET but free).
Code @ https://github.com/4gsim/4Gsim/tree/master/src
 At the moment only a simple attach request scenario is implemented. Feel free to check it out!

Thanks, Santosh

Monday, February 13, 2012

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/

Sunday, January 29, 2012

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.

Friday, January 13, 2012

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?