Testing Cisco's Mobile Core, Data Center & Business Services
Summary: In a GGSN role, the ASR 5000 was able to maintain a total of 1 million attached subscribers. It forwarded a total of 20 Gbit/s across 380,000 of these emulated subscribers without any packet or session loss. 18,000 subscriber contexts were activated per second. The results confirm very robust scalability of the ASR 5000 in a 3G, GGSN role.
In our test, Cisco’s ASR 5000 played the roles of GGSN, SGSN, P-GW, S-GW, and MME one by one. This multi-role function should be an operational advantage to streamline requirements to size, power, management, and serviceability. At least it was in our test – when one of the ASR 5000 cards’ hardware failed, the Cisco support team could quickly pull a spare module from the joint pool. In this test the focus was on the ASR 5000’s role as a Gateway GPRS Support Node (GGSN).
The GGSN is a crucial element in the Mobile Core infrastructure. It serves as the gatekeeper to the IP world and is, in many ways, a VPN router. Managing GTP (GPRS Tunneling Protocol) tunnels to each connected mobile terminal, it sets up and tears down packet data protocol (PDP) contexts, extracts tunneled IP data arriving from the SGSN to routed IP and routes Internet traffic into the appropriate contexts on the return path. The GGSN has to manage subscribers and their IP addresses as well as enforce policies.
We started off by performing essential baseline tests, aiming to answer the questions:
The test logic had to follow the order of questions above: First users have to be authenticated and activated by the system; once they have been admitted to the mobile network and are allowed to use the data services, they can send and receive data. This meant that within one test we aimed to test both the control plane and data plane capabilities of the ASR 5000.
The test was set up such that a couple of Spirent Landslides emulated a total of four Serving Gateway Support Nodes (SGSN) on one side of the GGSN user test. (We did not use real ASR 5000 SGSNs because this would have required more SGSN hardware to scale than we had available.) Behind those SGSNs, Landslide emulated the appropriate control protocols to represent RNCs, 16 base stations, and 1,060,000 subscribers, which were split up:
The parameters were developed by EANTC based on discussions with Heavy Reading analysts and service providers. Since it is only logical that not all attached users are going to be using data services at the same time, we defined 38 percent of the users as actively sending and receiving.
On the upstream side of the GGSN, the Landslide emulated Internet servers and hosts (for example, Web servers). We started the test by activating all the 1,000,000 permanently active PDP contexts. We configured the farm of Spirent Landslides to activate a total of 18,000 PDPs per second and started the test. The ASR 5000 was able to support this rate and scale up to our configured number of users, 1 million. Once the number of expected PDP contexts was reached, the Landslide started sending data traffic for the predefined 38 percent fraction of the users.
At this stage, we started the make/break sessions with the additional pool of 60,000 users that were making new data calls and terminating them after 60 seconds. Context activations/deactivations are commonly seen in mobile networks; they increased the realism and challenge of the test.
Our active users were configured with an array of representative applications. These included HTTP and VoIP, as well as plain TCP and UDP. The total amount of data traffic that the ASR 5000 had to process was 20.086 Gbit/s. The traffic was roughly broken down to 6 Gbit/s being sent from the users and 14 Gbit/s being sent to the users. We let the traffic flow for 15 minutes while cycling through our make/break users. We also monitored the CPU utilization on the ASR 5000 and recorded at most 69 percent at any time.
Through the duration of the test we did not lose any user session. The ASR 5000 was able to maintain all user sessions while processing a total of 20 Gbit/s worth of data traffic and performing 1,000 data call activations and terminations per second.
Since GGSNs tend to be cost intensive, service providers have a vested interest in minimizing their numbers. The test results validated Cisco’s claims that the ASR 5000 is a robust and scalable GGSN.
Page 4: Results: ASR 5000 GGSN Performance With DPI
In our test, Cisco’s ASR 5000 played the roles of GGSN, SGSN, P-GW, S-GW, and MME one by one. This multi-role function should be an operational advantage to streamline requirements to size, power, management, and serviceability. At least it was in our test – when one of the ASR 5000 cards’ hardware failed, the Cisco support team could quickly pull a spare module from the joint pool. In this test the focus was on the ASR 5000’s role as a Gateway GPRS Support Node (GGSN).
The GGSN is a crucial element in the Mobile Core infrastructure. It serves as the gatekeeper to the IP world and is, in many ways, a VPN router. Managing GTP (GPRS Tunneling Protocol) tunnels to each connected mobile terminal, it sets up and tears down packet data protocol (PDP) contexts, extracts tunneled IP data arriving from the SGSN to routed IP and routes Internet traffic into the appropriate contexts on the return path. The GGSN has to manage subscribers and their IP addresses as well as enforce policies.
We started off by performing essential baseline tests, aiming to answer the questions:
- How many sessions can the GGSN activate per second? In other words, how large a cloud of active mobile broadband data users can an operator sensibly manage using a single Cisco ASR 5000?
- How many mobile users will be supported simultaneously – i.e. what is a suitable operational ceiling for the number of mobile terminals under supervision of a single GGSN?
- How much data can the GGSN process? In the high-speed packet access (HSPA) times, an operator selling multi-megabit downlink speeds to their customer base should have accountable planning numbers in their hands.
The test logic had to follow the order of questions above: First users have to be authenticated and activated by the system; once they have been admitted to the mobile network and are allowed to use the data services, they can send and receive data. This meant that within one test we aimed to test both the control plane and data plane capabilities of the ASR 5000.
The test was set up such that a couple of Spirent Landslides emulated a total of four Serving Gateway Support Nodes (SGSN) on one side of the GGSN user test. (We did not use real ASR 5000 SGSNs because this would have required more SGSN hardware to scale than we had available.) Behind those SGSNs, Landslide emulated the appropriate control protocols to represent RNCs, 16 base stations, and 1,060,000 subscribers, which were split up:
- 380,000 sessions actively sending data all the time
- 620,000 sessions attached and idle
- 60,000 sessions in a make/break scenario, set up and disconnected at a rate of 1,000 sessions per second with a lifetime of one minute each.
The parameters were developed by EANTC based on discussions with Heavy Reading analysts and service providers. Since it is only logical that not all attached users are going to be using data services at the same time, we defined 38 percent of the users as actively sending and receiving.
On the upstream side of the GGSN, the Landslide emulated Internet servers and hosts (for example, Web servers). We started the test by activating all the 1,000,000 permanently active PDP contexts. We configured the farm of Spirent Landslides to activate a total of 18,000 PDPs per second and started the test. The ASR 5000 was able to support this rate and scale up to our configured number of users, 1 million. Once the number of expected PDP contexts was reached, the Landslide started sending data traffic for the predefined 38 percent fraction of the users.
At this stage, we started the make/break sessions with the additional pool of 60,000 users that were making new data calls and terminating them after 60 seconds. Context activations/deactivations are commonly seen in mobile networks; they increased the realism and challenge of the test.
Our active users were configured with an array of representative applications. These included HTTP and VoIP, as well as plain TCP and UDP. The total amount of data traffic that the ASR 5000 had to process was 20.086 Gbit/s. The traffic was roughly broken down to 6 Gbit/s being sent from the users and 14 Gbit/s being sent to the users. We let the traffic flow for 15 minutes while cycling through our make/break users. We also monitored the CPU utilization on the ASR 5000 and recorded at most 69 percent at any time.Through the duration of the test we did not lose any user session. The ASR 5000 was able to maintain all user sessions while processing a total of 20 Gbit/s worth of data traffic and performing 1,000 data call activations and terminations per second.
Since GGSNs tend to be cost intensive, service providers have a vested interest in minimizing their numbers. The test results validated Cisco’s claims that the ASR 5000 is a robust and scalable GGSN.
Page 4: Results: ASR 5000 GGSN Performance With DPI
