BH Telecom Sarajevo, Bosnia
Received date: June 02, 2014; Accepted date: July 21, 2014; Published date: July 28, 2014
Citation: Sarajlic A (2014) A Proposal for Advanced Flow based Charging in PCC Architecture. J Telecommun Syst Manage 3:112. doi: 10.4172/2167-0919.1000112
Copyright: © 2014 Sarajlic A. This is an open-access article distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.
Visit for more related articles at Journal of Telecommunications System & Management
This work depicts a proposal of possible and feasible method for reduction of prepaid credit control and update requests in real time, within the ‘Policy and Charging Control’ (PCC) architecture. Consideration is relating to IMS (IP Multimedia Subsystem) environment, on condition where QoS can be dynamic changed and different feasible service configurations affect the charging process.
IMS-IP multimedia subsystem; EAS-External application server; OCS-On-line charging system; PCC-Policy control and charging; PCRF-Policy and charging rule function; PCEF-Policy and charging enforcement function
Here will be using the known concept of Application Server in IMS architecture, in terms of introducing new functionalities and applications on proposed External Application Server. This will be used for improvement of On-line prepaid charging process in terms of: Computation of time intervals for credit control and update; reduction of credit control check numbers; setting of subscribers consumptions limits; automatic notification and refill of the prepaid account.
For this purpose the main IMS idea and principle are used: 3GPP specified IMS architecture to allow for services and applications at the higher level to use service building blocks on the lower level, as reusing functions and service enablers On this way is achieved decreased signaling traffic through to lower number of control messages and also is decreased the workload of application and charging support nodes.
The solution is based on:
1. using of subscribers information about resource consumption. This information in form of ‘Policy Counter Status’ is carried over Diameter based Sy interface, from OCS (On-line Charging System) to PCRF (Policy and Charging Rules Function)
2. Introduction of the new functional block relating to existing PCC Architecture: External Application Server (EAS). This new node will be able to communicate with PCRF, and through this
• calculation of a time interval to the next prepaid credit check and update
• carry out an automatic prepaid credit recharging
3. Modification and addition of configuration attributes and parameters in some reference points.
The purpose of On-line prepaid charging is to implement credit control before a requested service would be allowed to use. All charging process has taken place in real time, where is necessarily continually to check the prepaid credit balance during to service usage, in order to prevent overuse of credit and unexpected service breakdown. The problem of increased amounts of signaling about increased credit check requests is more conspicuous, particularly at the interface of the IN (Intelligent Network) node. In terms of increased workload and weighted working, this can multiply problems with the speed of processing of all requests.
According to 3GPP TS 23.203, PCC is an architecture and process for creation and implementation of operator’s policies and charging rules. In this specification, PCC architecture contains: Application Function (AF); the main function for charging rules creation and control-Policy and Charging Rules Function (PCRF); a gateway in the access network for charging rules implementation-Policy and Charging Enforcements Function (PCEF).
PCRF manages and coordinates with the other nodes in the network depending on the operator’s policies. PCRF uses information from AF function and additional nodes for charging parameter definition and authorized QoS determination, which will be incorporated into the charging rule. PCRF generates set of charging rules for every media component and deliver it, over Diameter based Gx interface, to the PCEF gateway.
PCEF gateway provides to PCRF with corresponding bearer session information, and requests appropriate charging rule and policy. Equally, PCRF can contact the Subscribers Profile Repository (SPR), over SIP interface, to obtain more information for charging rule definition. Based on received and installed charging rules, PCEF establishes IP packet filters in according to these rules, in order to pass specific service data flows through GGSN.
A Charging rule, among the others, includes:
• Charging rule name;
• Charging rule priority (higher number-lower priority);
• Rating group (charging key);
• Measurement method (time, volume, number of events);
• Charging type (on-line; off-line);
• Service identifier;
• Codec type for bandwidth;
• QoS class;
• Service Data Flow filter (source and destination IP address; port numbers; protocol);
• Gate status
In the Figure 1 is presented a position of the new additional External Application Server (EAS) with its applications and connections, in relation to existing PCC architecture.
In relation to the defined standard procedure for defining and creating the charging rules and authorized QoS for the services and corresponding IP bearers, here are introduced transversal connections from the main control module PCRF to the OCS and to EAS. Connection to the OCS is on purpose to get information about user’s prepaid credit balance and policy counter status about user’s resource consumption, while connection to the EAS is in the purpose of calculation of time interval between credit control checks, and reach of others new functionalities for credit limit and automatic credit recharging.
After the request is sent and answers are received from these nodes, PCRF supplements and completes charging rules by inserting received information into the new attributes (Attribute Value Pair -AVP) in the charging rules. On this way, PCRF makes decisions about service and charging policy that is: creates and establishes charging rules and authorized QoS. PCRF sends rules over Gy Diameter interface toward PCEF gateway, where charging rules and policies will be operationally implemented and supervised.
Diameter in PCC
3GPP has adopted Diameter as primary signaling protocol for AAA and Mobility Management in the IMS. Diameter message contains a header with 20 octets and number AVPs (Attribute Value Pair) with data. Diameter based reference points Rx, Gx, Gy, Sy are used in this work. Diameter application at Gx reference point is expanded with additional AVPs in order to be able transfer and use additional information for charging rules creation. These information included data about subscriber’s resource consumption and corresponding time intervals for credit control and update.
The Diameter has defined a mechanism for specific Vendor ID AVPs with Private-Enterprise-Number (different from zero). Companies and institutions can apply to IANA by the next link https:// www.iana.org/assignments/enterprise-numbers for registration and obtaining of this identifier: Private-Enterprise-Number. In this way, ‘BH Telecom’ company, in which testing lab is done the tests, has obtained the number: 26628.
Testing is done on the Ericsson’s ‘Service Aware Policy Controller’ (SAPC)  (i.e. PCRF) (vendor’s release 14.b and, 3GPP release 12) in completely real environment only a dedicated instance is created and specified for less and limited number of users.
On the SAPC, introducing the new additional AVPs is done by the admin interface and ‘Domain Management/Diameter AVP/ AVP Definitions/New AVP Definitions/Attributes’. On this way, on the Gx reference point, a new BHT-Time-Interval AVP is introduced, which has format ‘Unsigned32’ and code 100. This will be used together with the Vendor-Id AVP (value 26628) in order to be uniquely identified on the Diameter stack.
Soap connection and computation function
After receiving information about user’s consumption in the form of Policy Counter Status reports, in order to complete the charging rules and authorized QoS, PCRF sends a SOAP request to the EAS for the credit control time interval computation. In this request, in the SOAP body, identifier values and policy counter status are specified, as input data for computing function on the EAS.
SOAP request to the EAS:
INFO - 15 Nov 2013 10:44:32.249 (p: thread-pool- 1;w:324):MSG>>CLS SoapPrintHelper, MTD soapPrintout:: (msg TimeIntervalRequest)
SAPCExterntcalcService - REQUEST (client (TimeIntervalRequest() method))
(from 172.30.9.80) (to 192.168.129.153)
<?xml version=”1.0” encoding=”UTF-8”?>
<S:Envelope xmlns:S=”https://schemas.xmlsoap.org/soap/envelop e/”>
< TimeIntervalRequestMessage xmlns=”https://www.bhtelecom. ba/bhmobile/sapc/tc alc”>
Computing function transforms and reduces subscriber’s consumption information (service session duration; the volume of KByte; number of the message, etc.) to the ‘time’, that is ‘time interval’ in which these resources are consumed. Computation algorithm is depicted in Figure 2.
If the resulting time is over a predefined minimum value, the calculated time interval is returned to PCRF and communicated to the PCEF gateway, which approves the service using. If the calculated time interval is less than a predefined minimum value tmin (which is usually the minimum accounting unit) - that means the current state of the user’s prepaid credit is so little that some or all services become disabled for the user.
If the calculated time interval is greater than a predefined maximal value tmax (which is usually a lower value between the average duration of the service session and the highest accounting units) for calculated time interval is taken tmax.
After processing, computing function on the EAS returns calculated time interval to the next credit control check, in SOAP answer to the PCRF.
SOAP answer to the EAS;
INFO-15 Nov 2013 10:45:09.030 (httpSSLWorkerThread- 9080-3):MSG>>CLS SoapPrintHelper, MTD soapPrintout:: (msgTimeIntervalResponse)
SAPCExterntcalcService - REQUEST (client (TimeIntervalResponse() method))
(from 192.168.129.153) (to 172.30.9.80)
<?xml version=”1.0” encoding=”UTF-8”?>
<S:Envelope xmlns:S=”https://schemas.xmlsoap.org/soap/envelop e/”>
In the PCRF control module, this calculated time interval is mapped to the new introduced BHT Time-Interval AVP, into the Charging-Rule-Install AVP. On this way, charging rule is completed and needs to be delivered over Gx reference point to the PCEF gateway for implementation.
Credit check time intervals
The proposed upgrading flow based charging uses PCC concept and the possibility of the PCRF module to create dynamic charging rules and manage the whole charging process. PCRF using Sy reference points obtains from the OCS system information about the subscriber’s resource consumption and forwards this information as input to an External Application Server (EAS). Its computation function obtains the time interval until the next credit and update control. Feedback on the calculated time from the EAS, the PCRF module inserts within the added AVP, completes dynamic charging rule and forwards to the PCEF gateway. This node applies such rules and authorized QoS. On this way, the time interval that is calculated and monitored, must be communicated through charging rules to PCEF, or in the other words - PCRF must generate and complete the charging rule and then instruct the PCEF on implementation.
PCEF gateway monitors the time interval for the entire group activated services, and after its expiry signals to OCS to send new updated information about the Policy Counter Status of individual resource consumption to PCRF module. After receiving this information, PCRF initiates the calculation of a new time interval next credit control on the EAS, and dynamic creation of new charging rules, which will be delivered to the PCEF.
The principle of calculating the time between successive credit checks is known from earlier [2,3], but was not applied to the flow based charging, and especially not in the PCC architecture, whereby creating dynamic charging rules and their implementation and supervision performs overall charging control. In an earlier concept, information about resources consumption is measured and collected by charging manager system, while in this paper, in a unique way through Sy reference point, information about the status of counters for resource consumption are conveyed from OCS to the PCRF control module.
In [2,3] is used for the usual method of communication and message exchanging: the network gateway (client) contacts the OCS (server) for time interval computation. In this work, the proposed concept is based on a different information flow, and the processing side is not on the OCS (which is in the telecom world always a descendant of the major vendors), but newly introduced External Application Server (EAS). On this way, a dedicated application is established, without requiring costly modifications to the OCS manufacturer, and OCS workload is mitigated, because the time interval processing is done on the other location.
In addition, on the EAS there is an automatic recharging function, which is complementary to the time interval computation function and interacts with it when needed that is when prepaid credit fall down to some predefine value (explained in ).
For evaluating scenario, the two most using services are selected: s1 VoIP service, Figure 3a and s2 Web Internet service, Figure 3b, because of the marketing strategy in prepaid dominant operator’s network, these services are the most represented [5-10].
Traffic for service s1 is with constant bit rate, generated on the testing production VoIP platform and recorded by professional measuring device EXFO AXS-200 in a time of 8 minutes
Web service s2 is the mobile Internet surfing. Traffic for s2 service is the ‘best effort’ and uses ‘background’ QoS traffic class. This is the burst TCP traffic, recorded in real time.
Comparison of proposed advance flow based charging and existing on-line charging
The aim of evaluation is to compare performances of proposed enhanced prepaid charging solution and existing on-line prepaid charging mechanism.
For tariff functions for charging of: VoIP service s1 is taken 0.12 EUR per minute, and Mobile Internet service s2 is taken 0.34 EUR per 200 kB of traffic (included downstream and upstream).
On thus, for VoIP service we have the next tariff function:
m.u. - monetary unit
t.u. – time unit
and corresponding charging for achieved VoIP consumption:
x1- session time
For Mobile Internet service we have tariff function:
v.u. – volume unit
and corresponding charging for achieved Mob. Internet consumption
x2 [kB] - data volume
On-line prepaid charging settings: In real time on-line charging, prepaid credit balance checking is carried out after the service usage quota is exhausted or predefined checking time is expired. OCS grants and assigns the quota, which can be given in service units (seconds of service session duration; kBytes of the data;) or monetary units. In this case, quota setting as triggers to address to OCS is given in Table 1.
|Settings||s1 time||s2 volume|
|Chg Q||10 s||100 KB|
Table 1: Service quotas for credit checks.
Proposed advanced flow base charging settings: Variables x1 and x2 from (1) and (2) represent service resources consumption, e.g. seconds of voice session or kBytes of the mobile Internet session. In order to express variables x1 and x2 in function of time, respectively, on the end of considered time interval, we can write, according to the relations (1) and (2) and Figures 3a and 3b.
In the actual implementation of the algorithm for the proposed solution enhanced prepaid charging, which is based on the computation of time intervals until the next credit control and update check, the unknown variable “t” (i.e. time interval) is calculated by an iterative procedure in the program. It starts from t = 0, then the loop adds a small increment Δt valued, until it reaches the actual credit value, which is used for the computation. At this moment, the sum of charging for all individual services is exactly equal to the actual credit value, which is used for the calculation.
Credit control analysis
During the testing, Voice of 8 minutes and mobile Internet services are taken. Initial credit was 10 EUR and the next three use cases are studied: low, moderate and high internet using and consumption. Tests were performed until a predefined minimum value of the user’s prepaid credit is reached, which gives the equivalent calculated time less than one voice accounting unit.
For the purpose of comparing the credit control, update and allocation numbers between the proposed enhanced solution for flowbased prepaid charging and existing on-line charging solutions, there were done 10 experiments, and in each case the initial position on the traffic sample was randomly selected from a uniform distribution. Then he passed through the traffic patterns in order to simulate the Web and VoIP session. This corresponds to the resource consumption of selected service, so that includes appropriate charging for services. Such made charging is then continuously subtracted from the initial prepaid credit during of the service usage. After assigned service quota is reached, credit control and assignment are done. This procedure is repeated until the initial credit has been spent. Then, the same procedure is repeated for all of the second, third, etc. experiment. In the next tables and figures are shown the results of testing:
The session lasted 442 seconds until the lower limit of the user’s credit is reached, when notification to the user is activated and push message to launch Top Up application for automatic credit recharging [11-14]. During the session, there were 78 credit checks by the standard on-line procedure and for the same session, 16 credit checks of the improved procedure, which uses the computation of time intervals on the EAS.
The results are shown in the horizontal diagram as a frequency of credit checks for the standard on-line and improved flow based charging, with low consumption of service resources.
After that, the same procedure was repeated at medium and low consumption of resources, and a comparative view of the results is given in following Table 3.
|10.00||58||M.Int. = 480 [kB]||M.Int. = 0.816|
|Voice = 58 [sec]||Voice = 0.116|
|9.06||52||M.Int. = 415 [kB]||M.Int. = 0.705|
|Voice = 52 [sec]||Voice = 0.104|
|8.25||47||M.Int. = 330 [kB]||M.Int. = 0.56|
|Voice = 47 [sec]||Voice = 0.094|
|7.60||44||M.Int. = 518 [kB]||M.Int. = 0.90|
|Voice = 44 [sec]||Voice = 0.09|
|6.70||38||M.Int. = 426 [kB]||M.Int. = 0.73|
|Voice = 38 [sec]||Voice = 0.076|
|5.90||34||M.Int. = 375 [kB]||M.Int. = 0.64|
|Voice = 34 [sec]||Voice = 0.07|
|5.19||30||M.Int. = 315 [kB]||M.Int. = 0.54|
|Voice = 30 [sec]||Voice = 0.06|
|4.59||26||M.Int. = 280 [kB]||M.Int. = 0.476|
|Voice = 26 [sec]||Voice = 0.052|
|4.06||23||M.Int. = 225 [kB]||M.Int. = 0.385|
|Voice = 23 [sec]||Voice = 0.05|
|3.67||21||M.Int. = 190 [kB]||M.Int. = 0.323|
|Voice = 21 [sec]||Voice = 0.042|
|3.30||19||M.Int. = 250 [kB]||M.Int. = 0.425|
|Voice = 19 [sec]||Voice = 0.038|
|2.83||16||M.Int. = 237 [kB]||M.Int. = 0.40|
|Voice = 16 [sec]||Voice = 0.032|
|2.40||13||M.Int. = 182 [kB]||M.Int. = 0.31|
|Voice = 13 [sec]||Voice = 0.026|
|2.05||11||M.Int. = 140 [kB]||M.Int. = 0.24|
|Voice = 11 [sec]||Voice = 0.022|
|1.79||10+||M.Int. = 164 [kB]||M.Int. = 0.28|
|Voice = 10+ [sec]||Voice = 0.02|
Table 2: Test with initial credit of 10 eur in the low internet consumption.
|Low Resource Consumption- Number of Credit check and update|
|Standard Charging||Advanced FBC|
|Middle Resource Consumption-Number of Credit check and update|
|Standard Charging||Advanced FBC|
|High Resource Consumption-Number of Credit check and update|
|Standard Charging||Advanced FBC|
Table 3: Comparative view of the testing results.
Comparing the results it is clear that applying of the enhanced solution for flow based prepaid charging, based on the computation of time intervals for the prepaid credit checks, there is achieved considerably decreased number of credit checks and updates compared to existing on-line prepaid charging solutions based on defined volume and time quotas. The Table 3 shows that the relationship was even more accentuated in favor of improved flow-based charging, when resource consumption was faster, and credit checks were increased in the case of the standard charging.
The same test procedure was repeated for the same sample of the signal, but now with the initial credit value of 5 EUR: The session lasted 149 seconds until the lower limit of the user’s credit is reached, when notification to the user is activated and push message to launch Top Up application for automatic credit recharging. During the session, there were 31 credit checks by the standard on-line procedure and for the same session 9 credit checks of the improved procedure. We can see now that the ratio of credit check at enhanced flow-based charging vs. standard charging is no longer so accentuated in favor of improved FBC, as was the case in Table 2 and Figure 4.
All this demonstrates that the proposed solution for advanced flow-based prepaid charging has a much less number of prepaid credit checks in relation to the existing on-line charging solution, with different quota settings for credit checking and updating.
This paper has shown that it is possible in the PCC architecture, using the proposed additions and modifications: - introducing a new external application server (EAS) with the dedicated application and the corresponding computation functions; using Sy reference point and its Diameter application and adding new AVPs to the Gx reference point - to calculate and monitor the time between successive prepaid credit checks and updates, in order to reduce signaling in charging process and relieve some nodes. Access Gateway; on-line charging function and Central IN prepaid node in the network of the operator.
Using experiments in laboratory conditions, which are in functional terms very similar to the real system, because they use the same functional components and modules (SAPC-Service Aware Policy Controller - as the main control module PCRF and EPG - Ericsson Enhancement Packet Gateway-as PCEF) but only reduced the number of subscribers, it has been shown that the proposed model is set up correctly. Evaluation of the results was performed by a group of two commonly used services: VoIP IP service and mobile Internet, over 3G/4G and WLAN networks. The comparison is done for the existing on-line charging system and the proposed innovative system, based on the computation and the monitoring of time intervals. The results have really shown that it is possible significantly reduce the number of address to the OCS, i.e. the number of credit checks and updates during the service session with properly defined time for the following prepaid credit check.
Make the best use of Scientific Research and information from our 700 + peer reviewed, Open Access Journals