& cplSiteName &

PCRF in the Cloud

Light Reading
Series Column
Light Reading
2/5/2012
50%
50%

EXECUTIVE SUMMARY: Cisco's ASR 5000 successfully retrieved policies from the PCRF in the cloud, and throttled customer traffic accordingly.


In 2010 we conducted a comprehensive test of Cisco's mobile solution including mobile core and mobile backhaul (See Testing Cisco's Mobile Core, Data Center & Business Services and Testing Cisco's Next-Gen Mobile Network). At the time, we used a third-party Policy and Charging Rules Function (PCRF) as Cisco had not implemented its own. Now, not only did Cisco have an early version of their PCRF for us to test, but it came with a very timely message -- it was ready to be run in the cloud.

Mobile carriers need PCRF to dictate the rules their subscribers must follow when using the network. These rules could include data allowance, mobility and roaming to name but a few. The Policing and Charging function has been defined both for 3G and Long Term Evolution (LTE) scenarios by the 3rd Generation Partnership Project (3GPP) , and is typically done by a dedicated system with access to subscriber information databases, charging systems and mobile gateways.

In this sense, we think Cisco was wise to port its PCRF to its Unified Computing System, either to be run locally or in a cloud. By doing this, mobile operators could benefit from the flexibility and agility of the cloud, and Cisco has a new use for the UCS systems. With the flexibility of running the PCRF in the cloud comes questions of how many subscribers can it support and what kind of new mobile core topologies could be erected using this idea. Since the system was brand new and since such scalability tests are extremely time consuming, we focused on initial functionality proof points.

Cisco claimed that its ASR 5000-based mobile core could use the PCRF to implement throttling for different customer tiers, so we set out to test just that. Cisco’s mobile setup was in a different lab than our cloud test bed and we decided not to move it. If the PCRF can run in the cloud, then it should certainly be able to run in our cloud test bed to a remote mobile core and test setup. Ixia helped us to bring an extra XM2 tester over to the building where Cisco’s ASR 5000 was and we set up the test. Cisco configured a single ASR 5000 to do the work of the Packet Gateway (PGW) and Serving Gateway (SGW) in a Long Term Evolution (LTE) scenario.

Ixia’s IxLoad was used to emulate the Mobility Management Entity (MME) on one port connected to the ASR 5000, with the base station and clients behind it, and the emulated Web servers with content on a second port, also connected to the ASR 5000. In the cloud, the PCRF was set up with three virtual machines. One had Cisco's Inteligent Policy and Control Function (IPCF -- Cisco’s implementation of the 3GPP-defined PCRF) installed; the second ran Cisco's Subscriber Service Controller (SSC), which held the database of subscriber data, and the third virtual machine ran Cisco's Policy Provisioning Tool (PPT) and the Mobility Unified Reporting (MUR) tool.

Before we looked at throttling, as a sanity check, we ensured that we could establish both default and dedicated bearers to up to 50 subscribers. Since only data traffic was going to be used in this test we only configured default bearer per subscriber.

Throttling Mobile Subscribers
To test the throttling feature we configured three subscribers -- one bronze, one silver, one gold. Cisco’s ASR 5000 and PCRF categorized them based on IMSI ranges. Each subscriber was configured to create an HTTP session with the emulated server, attempting to reach as high a data rate as possible. Each subscriber type had a different bandwidth policy assigned: Gold subscribers received 4Mbit/s per bearer, Silver subscribers received 3Mbit/s and Bronze subscribers received 2Mbit/s. Each subscriber had two additional rules assigned. The first rule was a traffic volume limit of 50MB. Once this limit was reached, each subscriber bandwidth was throttled some more: Gold subscribers were throttled back to to 2Mbit/s, Silver to 1.5Mbit/s, and Bronze to 1Mbit/s. We cleared the volume usage on each subscriber and tested each one at a time. The graph below shows that each subscriber was throttled approximately as expected. The behavior of each line shows that the ASR 5000 would allow a burst before dropping, and Ixia’s TCP sessions slowly learning to home in on the rate it could consistently get.

Once the test was complete, Cisco mentioned it is also working on enabling dynamic policies -- the reconfiguration of how the ASR 5000 throttles traffic based on some condition. One of such conditions was when a specific Access Point Name (APN) crosses a bandwidth threshold as a percentage of how much bandwidth the ASR 5000 was seeing in total. Another dynamic policy was to limit specific protocol if traffic from this protocol exceeds a given percentage amongst the total traffic, which could be used to throttle P2P and YouTube traffic, for example.

Cisco explained that operators have asked for such features. One example we heard from Cisco was that operators would like to be able to limit peer-to-peer traffic, dynamically ensuring that it never reaches a high percentage of the total traffic in the mobile network and that it doesn't reach a high data rate. Such functions could also be performed in the mobile core firewall or DPI devices for example, but putting them directly into the mobile gateway enables mobile operators to register the offender (since the gateway has an IMSI and account association). Interesting, powerful, and potentially a can of worms, depending on how it's used.

These functions are also where the MUR and PPT come into play. Cisco explained that the MUR should normally poll live traffic statistics from the ASR 5000 and the PPT will send the new configuration to the ASR 5000 if they see the conditions met. At the time of the test, the ASR 5000 polling was not yet implemented so Cisco was using some in house scripts for their own testing to manually update the MUR with traffic statistics. In this concept demonstration, we observed that when these scripts were used in accordance with the APNs or protocols we configured with the Ixia equipment, the throttling rates indeed changed.

We validated that the PCRF worked from its installation in the data center. It controlled the mobile gateway located across campus and applied policies to subscribers both statically and dynamically. The question on mobile service provider minds is very often: "Will it scale?" This question is left unanswered at the moment since a scaling test, in the policy and control area, is a completely different beast, one that we did invite Cisco to take on. Meanwhile we also welcome Cisco's ideas for using the PCRF in the cloud -- ideas that increase the potential scalability, and optimize both agility and access to the data.


Next Page: Conclusion: Cloud Intelligent Networks
Previous Page: DHCPv6 in the Cloud


Back to the Cisco Test Main Page

(0)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Featured Video
From The Founder
Light Reading founder Steve Saunders grills Cisco's Roland Acra on how he's bringing automation to life inside the data center.
Flash Poll
Upcoming Live Events
March 20-22, 2018, Denver Marriott Tech Center
March 22, 2018, Denver, Colorado | Denver Marriott Tech Center
March 28, 2018, Kansas City Convention Center
April 4, 2018, The Westin Dallas Downtown, Dallas
April 9, 2018, Las Vegas Convention Center
May 14-16, 2018, Austin Convention Center
May 14, 2018, Brazos Hall, Austin, Texas
September 24-26, 2018, Westin Westminster, Denver
October 9, 2018, The Westin Times Square, New York
October 23, 2018, Georgia World Congress Centre, Atlanta, GA
November 8, 2018, The Montcalm by Marble Arch, London
November 15, 2018, The Westin Times Square, New York
December 4-6, 2018, Lisbon, Portugal
All Upcoming Live Events
Hot Topics
Federal Funds for Broadband? Unlikely
Mari Silbey, Senior Editor, Cable/Video, 2/12/2018
Has Europe Switched to a Fiber Diet? Not Yet...
Ray Le Maistre, Editor-in-Chief, 2/15/2018
Net Neutrality: States' Rights vs. the FCC
Mari Silbey, Senior Editor, Cable/Video, 2/13/2018
Will China React to Latest US Huawei, ZTE Slapdown?
Ray Le Maistre, Editor-in-Chief, 2/16/2018
IBM, Microsoft Duke It Out Over Chief Diversity Hire
Sarah Thomas, Director, Women in Comms, 2/15/2018
Animals with Phones
Live Digital Audio

A CSP's digital transformation involves so much more than technology. Crucial – and often most challenging – is the cultural transformation that goes along with it. As Sigma's Chief Technology Officer, Catherine Michel has extensive experience with technology as she leads the company's entire product portfolio and strategy. But she's also no stranger to merging technology and culture, having taken a company — Tribold — from inception to acquisition (by Sigma in 2013), and she continues to advise service providers on how to drive their own transformations. This impressive female leader and vocal advocate for other women in the industry will join Women in Comms for a live radio show to discuss all things digital transformation, including the cultural transformation that goes along with it.

Like Us on Facebook
Twitter Feed