Optical/IP Networks

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

Summary: Cisco’s SGSN scaled up to 1,060,000 emulated 3G subscribers at a steady attachment rate of 4,200 subscribers per second, at the same time communicating with the GGSN to activate PDP contexts at a similar rate.

A Serving GPRS Support Node (SGSN), as its name hints, functions as a bridge between the mobile and the packet world. It deals with mobility aspects such as user attachment and location management as well as logical link management, authentication, and charging. The SGSN is also tasked with the actual delivery of data to and from the users – it is the last device upstream that sees both 3G voice and broadband data traffic in parallel.

Cisco’s ASR 5000 can be configured as a SGSN or a GGSN in a UMTS context (later we discuss its role in a LTE network). For this test the ASR 5000 acted as an SGSN while the Spirent Landslide tester emulated Radio Network Controllers (RNCs) on one side of the SGSN and a GGSN on the other side.

Since the SGSN is the user’s first point of entry into the mobile core network it must also be able to validate, against a Home Location Register (HLR), user’s subscriber data such as user profile and location or serving area (see the bottom of this page for more information).

Cisco’s claim, which we were asked to validate, was that the ASR 5000 could support 4,200 attachments per second and scale up to over a million attachments. These attachments represent users that are looking to access network resources. The test logic was, therefore, to set up a constant rate of 4,200 attachments per second until 1,060,000 users attached to the network. Each successful attachment was followed by a PDP context activation.

The relationship, in the mobile core network, between SGSN and GGSN is such that a number of SGSNs all connect to a single GGSN. Hence the attachment rate that a single SGSN must support is smaller than the PDP activation rate that should be supported by the GGSN. For this reason, in this test we focused on 4,200 attachments per second while in the GGSN test we verified a higher number of PDP context activations per second.

We tested the SGSN in the mobile core environment set up earlier.

As each of the 1,060,000 emulated subscribers connected to the network, at a rate of 4,200 per second, the SGSN obtained the information necessary to authenticate them from the HLR. After a successful authentication, the SGSN informed the HLR as to the registered location of the subscriber and the HLR in turn pushed the subscriber's subscription profile to the SGSN. Cisco’s SGSN successfully supported this number of attachments per second and scale.

So what is the message to the mobile service providers? The newly minted Cisco SGSN seems to be a serious workhorse. The number of activations we were able to validate in this test show that a ratio of four SGSNs to a single GGSN could be used in network planning, allowing the SGSN to aggregate a larger than normal service area and hence reduce operating cost.

Emulating the home location register
In order to circumvent an involuntary scalability test of the HLR, Developing Solutions graciously provided the HLR emulator and supported the test, connecting the HLR to the SGSN (Gr Interface). As no network-initiated services were tested, the GGSN was not connected to the HLR (Gc Interface).

Here is a little background on the HLR’s functions in the mobile core: It is the central repository, within a subscriber’s home network, that contains the profile for every mobile subscriber authorized to use the mobile network. Included in this profile are the subscriber's unique identifiers (e.g., phone number), authentication material, types of services the subscriber subscribed to, and the current location of the subscriber. The HLR is a common point in the mobile network that determines the type of services the subscriber may access (e.g. roaming, data, or SMS) or to locate the subscriber (e.g. incoming calls for a roaming subscriber).

Page 3: Results: ASR 5000 GGSN Session Setup Rate & Capacity

Previous Page
2 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