Testing Cisco's Mobile Core, Data Center & Business Services

Earlier, Light Reading published the first part of the massive independent test of Cisco Systems Inc. (Nasdaq: CSCO)’s next-generation mobile network infrastructure. (See Testing Cisco's Next-Gen Mobile Network and LR & EANTC Test Cisco’s Mobile IP Network.) Even in a one-minute video montage you can get a sense of the sheer size of this project:

This article is the second feature highlighting the results of this enormous test. Before we get to the background and test setup, here's a hyperlinked table of contents for this special feature:

Our testing team of the European Advanced Networking Test Center AG (EANTC) spent four weeks at Cisco's labs, validating the solutions presented to us. A key component we wanted to see in action is the mobile core. This is the logical data center area where the operator positions all the central packet and voice gateways, auxiliary control plane systems required to run the mobile network, plus consumer and business application servers.

At the beginning of the project late last year, we really scratched our heads when Cisco announced their willingness to join our test. How would they provide all the mobile core equipment? Of course, a search for SGSN on Cisco’s Website resulted in zero hits back then. But when Cisco bought the ASR 5000 (acquired from Starent Networks Inc.) it added a single specialized hardware platform that implements the voice and packet gateway functions both for 3G and Long Term Evolution (LTE).

UMTS voice and packet gateways have served their purpose in the industry quite well in the past years. Our test comes at a moment when things are changing rapidly. The major current challenges of mobile operators include:

  • Mobile data growth: Mobile subscribers expect multi- Mbit/s (megabits per second) throughput, through high-speed packet access (HSPA). All this traffic needs to transit the serving gateways and packet gateways. Performance requirements are much higher than before, and a large and growing fraction of subscribers has access to smartphones and other end systems capable of high-speed data. (See Cisco: Video to Drive Mobile Data Explosion.)
  • Migration to LTE, where the mobile core is called Evolved Packet Core (EPC): The drastic changes from 3G to LTE affect base stations, air interfaces, and backhaul networks. The LTE mobile core needs to grow to keep pace with the huge air interface bandwidth extensions, and it needs to support the all-IP radio access network (RAN) by providing suitable application policies, for example to differentiate operator-provided voice over IP and bulk data traffic.
  • Monetization: The mobile core is the key area where decisions are made to prioritize applications associated with revenue and to throttle bulk applications that just take away frequency spectrum and backhaul capacity (such as P2P, file sharing, etc.). The goal for mobile operators is to avoid too much precious spectrum being taken by applications that do not generate revenue.

This requires that vendors have an idea of what applications could generate revenue – certainly not a trivial question, and not to be answered unanimously across all subscriber bases worldwide. Cisco showed us some of its ideas – see the Mobile Smart Home demonstration on Page 12.

Another note on LTE: How far have implementations matured? The industry has been buzzing with success stories in press releases. But outside four city areas serviced by Telia Company , no LTE network of any scale has started production-grade services yet. Many mobile operators are testing the technology and most operators plan to deploy LTE only after 2012. We checked how well Cisco would be prepared for LTE with their mobile core offerings now. And recall that we tested its LTE backhaul design in the previous testing article. (See Testing Cisco's Next-Gen Mobile Network.)

Test setup
The test scale was phenomenal, even to previous EANTC and Light Reading standards. Our Spirent Communications plc contacts were surprised when they heard our requirement to fully emulate beyond 1 million mobile handsets for voice and data traffic. They had to bring in eleven of their fastest and largest Landslide mobile network emulators. The Landslides emulated the user equipment (UE) – like the cellphones and mobile data cards – and the data aggregation/transport aspects of the emulated base stations.

Due to emulator limitations, we agreed that Spirent would configure 16 artificially large base stations in this test, each of which emulated 62,500 subscribers. We counted only registered and attached subscribers toward this figure.

In real life, only roughly one-in-five to one-in-ten consumer phones is on a voice call at any time. Today, with still a lot of prepaid, voice-only phones around, probably even fewer subscribers are actively exchanging data traffic. A noticeable fraction of customers with a contract or prepaid card might even switch off their phones. Each of these factors would have blown up the numbers – in an artificial, unrealistic way. Therefore we abstained from any of such statistical “improvements” and counted only real, attached subscribers.

The Landslide emulators were connected – through the network set up in the previous phase – to three ASR 5000’s, taking 3G and LTE roles in turn. They were reconfigured from 3G to LTE after the first set of test cases had been completed. Since we required such a large farm of Landslides with 20x10G and 10xGE ports, we ended up using one of the Nexus 7000 switches to aggregate all the tester ports so we could reach the performance we intended to generate for the SGSN, GGSN, and EPC tests. This choice is reflected in the figure above.

For each subscriber, we emulated a range of application flows such as Voice over Internet Protocol (IP), HTTP, plain Transmission Control Protocol (TCP), and UDP data. All flows were IPv4-based in the Landslide/ASR 5000 tests. Since we required such a large farm of landslides with 20x10G and 10xGE ports, we ended up using one of the Nexus 7000 switches to aggregate all the tester ports so we could reach the performance we intended to generate for the SGSN, GGSN, and EPC tests. This choice is reflected in the figure above.

In addition, we required auxiliary mobile core functions to complete the scenario:

  • The Home Location Registrar (HLR) in the 3G world was provided by an emulator from Developing Solutions, a Texas-based specialist test vendor for mobile core component emulation.
  • The HLR’s equivalent in the LTE world, called Home Subscriber Server (HSS), was provided by Bridgewater Systems Corp. (Toronto: BWC). In addition, to ease and speed up scalability testing, we used the Developing Solutions emulator for the HSS function in parallel as well. All tests involving an HSS were carried out twice – with the emulator and the production system.
  • Finally, a Policy Charging and Rules Function (PCRF), also supplied by Bridgewater, was required to interface with the main packet gateway. The PCRF takes decisions on behalf of the packet gateway – anything that requires looking up per-subscriber rule-based behavior. A PCRF configuration can get quite advanced, and could be a competitive differentiator for a mobile operator. Since this equipment was not the major topic of the test, we kept it as trivially configured as possible. Its only purpose was to keep pace with our performance and scalability tests.

In this huge scenario, we evaluated a total of five test cases and two vendor demonstrations. Let’s see the details.

— Carsten Rossenhövel is Managing Director of the European Advanced Networking Test Center AG (EANTC) , an independent test lab in Berlin. EANTC offers vendor-neutral network test facilities for manufacturers, service providers, and enterprises. Carsten is responsible for the design of test methods and applications. He heads EANTC's manufacturer testing, certification group and interoperability test events. Carsten has over 15 years of experience in data networks and testing. His areas of expertise include Multiprotocol Label Switching (MPLS), Carrier Ethernet, Triple Play, and Mobile Backhaul.

Jambi Ganbar, EANTC, managed the project, executed the IP core and data center tests and co-authored the article.

Jonathan Morin, EANTC, created the test plan, supervised the IP RAN and mobile core tests, co-authored the article, and coordinated the internal documentation.

Page 2: Results: ASR 5000 SGSN Attachment Rate

1 of 14
Next Page
Page 1 / 2   >   >>
srikrishnak 12/5/2012 | 4:24:27 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Great continuation. Used to get much more from LR, so still waiting for PDF :)

DCITDave 12/5/2012 | 4:24:21 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

We'll have the PDFs available soon. Want to make sure all corrections and copy editing are complete with both reports first. Hang in there.

JeddChen 12/5/2012 | 4:24:21 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Informative Reports. waiting for PDF, too.

bigpicture 12/5/2012 | 4:24:17 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

I have a question about the throughput vs. the DPI tests.  In the throughput test you stated you had 60,000 make / break sessions activating at 1,000 sessions per second.  In the DPI test you stated the rate was "reduced" to 5.000 sessions per second.  

I'm not sure how you "reduced" from 1,000 to 5,000.  Is one of the numbers a typo or am I just confused?



tohhwee72 12/5/2012 | 4:24:17 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Possible to share more detail on the firewall performance, e.g.

1. The packet size used for the test, i.e. large or small packet?

2. Traffic profile, e.g. % of http, % of ftp etc

3. How is the NAT being done? i.e. how many public IP address are used to get 1 mil concurrent session?

4. What was the throughput, CPU load etc?

cross 12/5/2012 | 4:24:16 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Hi Bigpicture,

I thought I was confused, but it was only a typo :-)

Thanks for pointing out the issue.  We will fix it.  In short:

<li>GGSN test with DPI: 18,000 attachments per second</li>
<li>GGSN test without DPI: 18,000 attachments per second</li>
<li>EPC test: 5,000 attachments per second.</li>

Once all sessions were established, the make/break attachment rate was 1,000 new sessions plus 1,000 terminated sessions per second for all three tests (in a constant way, constantly making and breaking over the whole remaining test duration of 15 minutes).

Thanks, Carsten

JeddChen 12/5/2012 | 4:24:09 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Emulator is a very important and supplementary means for functionality and performance test. But real networks are quite different and much more complicated and there are a lot of potential and unpredicted factors. That a lot of emulators were used in this test solution has&nbsp; arose the worry mentioned above. so some of the results will be expected to be verified in live networks(trial office).

2skhatri 12/5/2012 | 4:24:04 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Are we to surmise that the upper limit for number of simultaneously attached users is around 1 million?&nbsp;

cross 12/5/2012 | 4:24:03 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Hi tohhwee72,

The primary focus of the ASR1000 Firewall/NAT test was the scale of the stateful network address translations. We did not mean to test the ASR1000 for throughput performance here.&nbsp; Also, the Avalanche emulator is an application-layer device; it sent HTTP requests and received responses on layer 7 - this was not a packet-layer test.&nbsp; To answer your questions:

1. The HTTP requests were for pretty short URLs so the packet sizes were in the order of 150 Bytes.&nbsp;&nbsp; Responses were sent for mid-size objects of a couple of kilobytes; MTU was set to 1470 bytes so there was an average packet size north of 1,000 bytes.&nbsp;

2. Three quarters of the traffic was HTTP, one quarter FTP.

3. The purpose of this test was to validate business security aspects of NAT.&nbsp; Enterprises typically want to hide their internal IP addresses from the Internet.&nbsp; NAT was therefore configured in a 1:1 scenario.&nbsp; 80,000 IP addresses from the network were mapped into another 80,000 IP addresses in the (supposedly public) network of

4. CPU load was not monitored. The Spirent Avalanche controller reported downstream throughput of 1.09 Gbit/s and upstream throughput of 0.154 Gbit/s. This was not a throughput test - we focused on stateful NAT mapping scalability.

Thanks Carsten

cross 12/5/2012 | 4:24:02 PM
re: Testing Cisco's Mobile Core, Data Center & Business Services

Hi JeddChen,

Network emulations and trials both have their reason for existence I believe.&nbsp; I disagree with your point that trials are better - they just answer different questions at a different time.

First and foremost, the goal of our test was to provide true, real, independent data of a vendor solution publicly.&nbsp; I have not heard of any serious operator trial where results have been made available publicly to the level of detail of this test.&nbsp; I hope our results will be helpful to gauge Cisco's solution for anybody worldwide.&nbsp; It does not take a site visit or good relationships with the trialling operator or vendor to read our article.

Second, it is dangerous to design trials to answer scalability questions. After all, customers are meant to use the trial as a service to some extent. To get to a level where one million users would simultaneously use LTE data connections, one would need to have at least a subscriber base of 10 million hyperactive data users because they are never going to use the network all at once.&nbsp; Few operators will be adventurous enough - or even able, given their customer base - to answer these scalability questions in a trial. TeliaSonera has not disclosed the number of subscribers in its production grade LTE network (not a trial!) - TeliaSonera has just said it has "thousands of subscribers" on its Swedish LTE network, and a total of around 500,000 mobile broadband subscribers nationwide for LTE and 3G together.

On the other hand, our test was unable to answer typical trial questions such as: How do subscribers perceive the service? What happens in the interaction with base stations when a large number of users are on the move, fast or slow, or do not have perfect coverage? How will charging work?&nbsp; So I definitely see the viability of trials once scalability emulations have been completed so it will be safe to deploy a trial network for real customers.

Apologies for the long post.

Thanks Carsten


Page 1 / 2   >   >>
Sign In