Our team in Yota is involved in development of PCRF, useful and important component of the operator network. Policy and Charging Rules Function (PCRF) is an advanced policy management solution enabling the operator to dynamically control network elements and apply real-time policies based on services, subscriber info and usage context. One of it’s key features we are really proud of is a flexible script-based policy decision maker. And here we would like to share our experience about this magical component.

Let’s take our thoughts away from PCRF, operators and clients for a while. Think about a high-performance and high-reliable system with some storage inside with a functionality like:

• store & backup the information
• reply HTTP requests as soon as possible
• configure replies in a very flexible way so that it can be changed on fly

From our past experience and research and from the common practices the simple architecture that serves well for such kind of tasks is: storage (db commonly or some other standalone storage implementation) + nginx + script to configure the replies. And all that is left is just to select the proper scripting language. Because we have a C/C++ application the first we talked about was Lua. If to think more accurately you can find out that it’s really a very convenient solution. What does Lua language mean for most of the developers?

• it’s simple and light-weighted – so easy to build into your application
• it’s a skeleton – build as many your own Lua or C functions as you wish, use them in a script
• it’s easy (both – scripts readability and expandability) for those who are not programmers from top to bottom, for example the maintenance team that you want to allow to tune up the logic on a production system in real-time
• it’s really quick for high-performance application

And now let us come back to PCRF and show how we used it and what we’ve reached. PCRF stores all the subscriber’s information in the Subscription Profile Repository (SPR) stored in Data Base.  Also it aggregates all the user session’s information and also stores it in DB. There are lots of systems that would like to use this information and to make some decisions based on it.

1. The first and the major use case for PCRF is of course PCEF for which we should make a real-time policy selection for user based on services, subscriber info, usage context, location, operator special conditions and etc. So there should be a way to configure PCRF diameter handlers logic.

2. Other systems also may use the information stored in PCRF SPR – end-user network devices clients, operator notification services, contact centers, web services, mobile applications and so on. For example, a very popular use case is to provide a policy for turbo button service which will show if this turbo button is available for the user at the moment. This solution should be made very quickly and depends on user profile, location, network resources availability and many other parameters that can be found in PCRF data storage.

All this client-systems may use there own heuristics and logic that filter the stored information and give the specific output. There is no way of course for hard-coding or standardization for this output. It should be changed easily on fly from inside logic to output format for each application separately and independently.

That’s why the described scheme was used. We have nginx server and a Lua-based scripting functionality. And we provide the outer system with the library of Lua functions (more than one hundred) that has access to all data stored in PCRF so that outer system can just load a Lua-script into the PCRF and run it.

If talking about the performance let us just show the numbers that will speak for themselves.

1. First case is used primary for PCEF purposes as we talked before. The diameter messages handlers in PCRF just call the loaded Lua script by name. The script itself can be managed by the maintenance team easily and loaded on fly to the PCRF server. The performance was measured for the script that accesses the Data Base and makes the policy decision based on this info. And so here we have 50 000 calls/sec.

The interesting key point here is that of course maintenance team wants to test the scripts they made. So we’ve created a validation tool with the db-read-only mode that can calculate all the data and provide the resulted policy. Also there is a possibility in our PCRF to load a new Lua script for the limited users percent (for example 10%) and check how it solves the task on this amount of subscribers while others will be served by the previously loaded and tested script. If it goes ok just call commit and use the new script for full 100%.

2. For all other systems we called it Generic Request API (GRAPI) method. The idea is so simple – just load your own Lua script with main function and call HTTP request (smth. like http://pcrf_server.com/grapi/run?script=grapi_test&subscriber_id=250110000002606) and you’ll get the reply from PCRF. This is our way for the turbo button implementation and many other similar systems.

Apache benchmark started for 100000 requests with concurrency 100 and HTTP keep alive feature gave us more than 30 000 requests/sec on quite a complicated script with multiple Data Base searches inside, detailed logging and logic branching.

If you are interested in how we did it in PCRF and want to try it and test you can visit http://freepcrf.com. Policy Engine and Generic Request API docs will help you to learn it in details and try on our free image. Any questions you have you can write here or post on our forum (http://freepcrf.com/forum). We will be happy to answer any of them.

Kind regards,
Yota PCRF team