PCRF in the Cloud
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