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!

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

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

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

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

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