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.

7 comments:

Naresh Rao said...

What about DPI? was that enabled to on GGSN/PGW or its separate entity?

Cheers
Naresh

Santosh Dornal said...

Hi Naresh

DPI was not enabled on the box and was not part of tests.

Regards, Santosh

shivlu jain said...

Cisco GGSN can do the DPI too on the same box....This is mandatory

Santosh Dornal said...

I agree!

Anonymous said...

Santosh, do you know what is the Cisco GGSN forwarding performance with DPI (and without DPI, for comparison)?

And by DPI I mean real layer 7 DPI such as URL matching, and not the ACL/filters Cisco did in the lightreading/EANTC test :)

Santosh Dornal said...

Sorry, I am not aware of such data.

Santosh Dornal said...

Few more thoughts on DPI front ..

Different DPI use cases can have vastly different performance characteristics therefore it is hard to benchmark. Not all deployments need DPI for example M2M & enterprise. The results without DPI were marker defining.