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:
What about DPI? was that enabled to on GGSN/PGW or its separate entity?
Cheers
Naresh
Hi Naresh
DPI was not enabled on the box and was not part of tests.
Regards, Santosh
Cisco GGSN can do the DPI too on the same box....This is mandatory
I agree!
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 :)
Sorry, I am not aware of such data.
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.
Post a Comment