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.

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!

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.