2009 International Conference on Advanced Information Networking and Applications Workshops

Towards a Policy and Charging Control Architecture for Online Charging

Frank Bormann, André Braun, Stephan Flake, Jürgen Tacken

Research and Development
Orga Systems GmbH
33104 Paderborn, Germany
e-mail: {fbormann,abraun,sflake,jtacken}@orga-systems.com

Abstract—Consistent and flexible policy and charging control
is one key factor for effective access control and efficient
resource management in IP-based multimedia communication
networks. One approach to deal with this challenge is to put
more decision logic into the so-called mediation layer which is
residing between the operators’ core network and the charging
system. This article describes our research study to extend the
mediation layer with more capabilities for online charging
control. The presented prototype implements and extends
parts of the 3GPP Policy and Charging Control Architecture
using the open source JAIN SLEE framework Mobicents.
Keywords-Policy and Charging Control; Active Mediation;
Online Charging; JAIN SLEE
I. INTRODUCTION
The IP Multimedia Subsystem (IMS) [1] allows
operators to deliver multimedia services based on IP and
Session Initiation Protocol (SIP). IMS aims at fixed-mobile
convergence through an all-IP network that offers internet
applications like presence, buddy lists and peer-to-peer
communication also via telecommunication networks. IMS
decouples voice and data services from the underlying
network access technologies like GPRS, WLAN and fixed
line. It was originally designed by the 3rd Generation
Partnership Project (3GPP), but other bodies like 3GPP2 and
TISPAN are now also involved.
When using the network and services, a corresponding
authentication, authorization, and monetary rating and
charging based on events, time, and/or resource usage has to
be performed. Network nodes are collecting corresponding
parameters while inspecting the network traffic and are then
reporting them to a charging and billing system. Charging is
performed either offline, i.e., at some later time after service
usage, or online, i.e., in real time during service usage. The
latter case is the more challenging one due to real-time
requirements on round-trip times for charging requests and
corresponding decisions, i.e., to allow or prohibit the service
data flow. Typically, a response time of less than 1 sec is
expected. In the remainder of this article, we therefore
consider the case of online charging.
The term mediation in the area of telecommunication
networks refers to the process of collecting and aggregating
usage records from multiple sources that can be used for
charging and billing. Active mediation (or: online mediation)
even allows credit control w.r.t. a user balance during service
usage and – if not sufficient credit is available – the
interruption of the running session. An active mediation
device is the controller software that performs active
mediation. Fig. 1 shows the architecture of an Online
Charging System (OCS) compliant with the 3GPP OCS
internal architecture [2]: a mediation layer with services for
(mobile) voice and data flow charging is residing in front of
the actual online rating and charging components.

Figure 1. Online Charging System overview

978-0-7695-3639-2/09 $25.00 © 2009 IEEE 524

DOI 10.1109/WAINA.2009.25
 The main purpose of the active mediation layer is to
transform each request coming from the different network
nodes and then forward it to the corresponding subsequent
rating engine. Thus, all incoming requests are ultimately
handled in the online rating and charging components, i.e.,
the mediation layer does not apply any logic to filter out
illegitimate online charging requests (unless they are syntac-
tically incorrect). E.g., a request to start a GPRS connection
is currently handled in the rating engine, even if the request-
ing user is not even subscribed to the GPRS service. How-
ever, we think that service subscriptions and service-specific
modalities could already be checked in the mediation layer,
such that such kind of illegitimate requests could be denied
without requesting the rating engine.
Thus, we propose to provide the mediation layer with
additional capabilities concerning service-specific parame-
ters in order to be able to
(a) filter out illegitimate requests already in the
mediation layer (and thus offloading the OCS),
(b) flexibly re-configure service-specific parameters for
online charging at a central location (and thus away
from the distributed network nodes to assure
consistency), and
(c) add applicable service-related charging parameters
to incoming charging requests prior to forwarding
them to the online rating engine.
A related standard for such an approach is the Policy and
Charging Control (PCC) Architecture [3] proposed by the
3GPP. In Section II, we provide an overview of the
Figure 2. 3GPP PCC architecture
525
components and protocols relevant for the scope of this
article. For the prototypical implementation of a correspond-
ing mediation device, we make use of JAIN SLEE [4], which
is the Java standard for high throughput, low latency event
processing application environments. In Section III, this
technology is briefly described. In Section IV, our research
study for the design and prototypical implementation of parts
of the PCC Architecture in order to put more logic into the
mediation layer is presented. For this study, we consider
three use cases concerning service authorization, configura-
ble service-specific parameters and QoS-dependent online
charging. Section V summarizes the results and provides an
outlook on future research.
II. 3GPP PCC ARCHITECTURE
The 3GPP PCC Architecture provides an abstract model
and logical reference architecture for policy control and flow
based charging control [3]. It comprises a number of
components and interfaces (called reference points) as shown
in Fig. 2.
The PCC supports charging models for volume-based
and time-based charging (and combinations of both) as well
as event-based charging. Charging features are – among
others – the possibility of applying different rates based on
the current location of the user and changing the rate based
on the daytime.
IP access to the network is controlled through the
Gateway node, where the Policy and Charging Enforcement
Function is residing.
A. Components and Reference Points
We here only give a short description of the main
components of the PCC Architecture. The Application
Function and the Offline Charging System are not in the
scope of this work and are therefore not explained any
further.
The Policy and Charging Enforcement Function (PCEF)
is located at the gateway(s) in the core network. Each
gateway monitors and controls the traffic flow, e.g., as a
Gateway GPRS Support Node. It provides – among others –
service data flow detection, QoS handling, and charging
interactions. The PCEF only allows a service data flow to
pass through if there is a corresponding active PCC rule and
the Online Charging System has determined sufficient credit.
The Policy and Charging Rules Function (PCRF)
provides PCC decisions based on predefined rules and infor-
mation received from PCEF and the Subscription Profile
Repository (SPR). The SPR contains all subscriber infor-
mation needed for evaluating policies (i.e., policies related to
end users) and bearer level PCC rules (i.e., rules related to
the traffic plane). The SPR may be combined with or distri-
buted across other databases in the operator network.
The designated protocols of the reference points between
the considered components are all based on the Diameter
protocol. Diameter is a bit-oriented, extensible protocol with
fail-over mechanism and transmission-level security. The
Diameter Base Protocol is defined in [5]; messages consist of
header information and a set of attribute-value pairs. Several
Diameter extensions (called applications) have been defined
to cover authentication, authorization and accounting as well
as charging and billing, the latter of which are important in
the scope of this work.
Via the Gx reference point which makes use of the
Diameter Gx Protocol [6], the PCEF sends requests con-
cerning PCC decisions to the PCRF. In turn, the PCRF is
provisioning PCC decisions to the PCEF. Such a decision
consists of applying one or more PCC rules and attributes
related to the traffic plane.
The Gy reference point between Gateway and Online
Charging System supports online credit control for charging
based on the service data flow. It uses the protocol defined
by the Diameter Credit-Control Application [7].
The Sp reference point allows the PCRF to request
subscription information from the SPR. In turn, the SPR can
also actively notify the PCRF when subscription information
has been changed. The standard does not define which
protocol to use for Sp. However, for the scope of this work,
parts of the Diameter-based Sh reference point [8] can be
used, which is the interface of the Home Subscriber Server in
the IMS.
A slightly different approach is the Gx over Gy
application, which can be used in the case that PCRF and
Online Charging System are co-located [9]. This approach
leads to signaling savings by combining charging rule
provisioning (cf. Gx) and online credit control (cf. Gy) in a
single message exchange, i.e., one Credit Control Request
and a corresponding Credit Control Answer.
526
B. PCC Rules
The information exchanged between PCEF and PCRF is
composed of PCC rules. A PCC rule is a set of information
required for detection, policy control and proper charging of
a service data flow. Correspondingly, the information in a
PCC rule consists of three parts: (a) service data flow
detection, (b) policy control, and (c) charging control (cf.
Section 6.3.1 of [3]).
To detect the packets belonging to a service data flow,
each PCC rule contains a service data flow template, each of
which has a number of filters. A filter may, e.g., be a pattern
for matching the IP 5 tuple. In case a packet cannot be
matched by any of the templates, it is silently discarded. The
policy control part of a PCC rule consists of attributes like
gate status, QoS class identifier and other related infor-
mation. The charging control part contains information like
service identifier, charging method, etc.
There are two different types of PCC rules: Dynamic
PCC rules are provisioned by the PCRF to the PCEF (i.e.,
the PCRF can enforce installation, modification, and
removal), whereas predefined rules are directly stored in the
PCEF and can only be activated or deactivated by the PCRF.
III. JAIN AND JAIN SLEE
The Java APIs for Integrated Networks (JAIN) is an
activity within the Java Community Process specifying APIs
for the creation of voice and data telephony services1. JAIN
is part of a general trend to open up service creation in the
telephony network to gain a growing number of participants
creating services and in turn creating more demand and more
targeted services.
A major goal of the JAIN APIs is to abstract from the
underlying network protocols, such that services can be
developed independently of the utilized network technology.
One of JAIN’s major activities is to define a suitable
execution environment for such services called JAIN Service
Logic Execution Environment (JAIN SLEE or JSLEE),
which defines a component and container model [4].
In contrast to the Java Enterprise Edition (JEE), JSLEE is
a framework which has especially been developed for asyn-
chronous, fine-grained and high-frequent event processing.
This kind of processing is especially suitable for telecommu-
nication networks. A good comparison of JAIN SLEE with
JEE can be found in [10]. The most popular JSLEE plat-
forms in the market are jNetX Convergent Service Platform2,
Opencloud’s Rhino Application Server3, and Redhat’s JBoss
Communications Platform4 that builds upon the open source
Mobicents5 platform.
Service Building Blocks. JSLEE components are called
Service Building Blocks (SBBs). The main idea is that
containers work as execution environments for these compo-
nents. The containers are fitted to the requirements of the
1
http://jcp.org/en/jsr/detail?id=22
2
http://www.jnetx.com
3
http://www.opencloud.com
4
https://www.redhat.com/solutions/telco
5
http://www.mobicents.org
SBBs and accomplish non-functional requirements (e.g.,
availability, scalability, robustness). Hence, component
developers have to pay attention only to the concrete service
logic. An example is a CallBlocking SBB that implements a
service that determines whether an incoming telephony call
is on a ‘black list’ and should be blocked.
In addition to the SBB logic, a specification of the events
which the SBB reacts on and the methods which are
activated thereby has to be given. SBBs can communicate
through a shared Activity Context, i.e., SBBs publish data
that they want to share in the activity context, where it can be
accessed by other SBBs.
Resource Adaptors. JSLEE hides the specifics of the
underlying networks. A service can be implemented with
SBBs independently from incoming and outgoing network
protocols, as the protocols are handled separately by so-
called Resource Adaptors (RAs).
Resources in terms of JSLEE are external entities such as
network devices, protocol stacks, directories, and databases.
An RA typically receives messages from an external system
via a network protocol and submits them as events to the
SLEE, more concretely to a so-called Activity Context.
Activity Context. An Activity Context dispatches each
received event to all SBBs that have registered for this kind
of event. This allows utilizing the same SBBs for different
incoming messages of different protocols.
Management and Framework. The management in
JSLEE is defined through Managed Beans (MBeans) as
specified by the Java Management Extensions (JMX)
specification6, similar to the Java Enterprise Edition. More-
over, the JSLEE framework contains a number of elements
building a basis for the service logic, e.g., alarms, timers and
profiles. Profiles can be thought of as a JSLEE internal
database residing in runtime memory.
Figure 3. eXtensible Control Point (XCP) prototype and test environment
6 8
http://jcp.org/en/jsr/detail?id=3
527
IV. CONCEPT AND IMPLEMENTATION
The concept and implementation of the PCC research
study is built upon a prototypical software called eXtensible
Control Point (XCP), which has been developed at Orga
Systems’ R&D department.
A. eXtensible Control Point
The main goal of the prototypical XCP was to come up
with an architecture that better separates between service
logic and charging logic compared to an existing Online
Charging System, while at the same time keeping the main
feature of fast and scalable handling of Diameter charging
requests. As a development basis, JSLEE was chosen due to
the concept of SBBs to encapsulate the programming logic in
Java and the configuration possibilities via profiles. The
open source Mobicents implementation serves as the SLEE
for this prototype.
An overview of the XCP is given in Fig. 3. It shows the
involved RAs, SBBs, and events for start reservations – note
that we primarily consider session-based charging with unit
reservation in this prototype. Corresponding subsequent
events w.r.t. extending and finalizing reservations are pro-
cessed similarly.
The prototype has two RAs which act as interfaces to the
systems outside: The RA Diameter receives and parses
incoming Diameter Credit Control Requests (CCRs). The
messages are then transformed into events for further
processing in the SLEE. The RA OPSC creates proprietary
messages out of SLEE events and sends them to the Rating
Engine.
Note here that the prototype is running in a simulation
environment with (a) a Seagull traffic generator 7 on a
separate machine and (b) a simulator of the convergent
charging and billing system OPSC® Gold 8 that simply
7
http://gull.sourceforge.net
http://www.orga-systems.com
checks for correct message syntax and replies to each For user A just the volume is counted. For user B
incoming request with an acknowledge message. also the value of the available bandwidth is
There are three SBBs: SBB Diameter, SBB SL (SL is measured and part of the charging requests. User B
short for service logic), and SBB OPSC. The SBBs is charged depending on the volume and available
communicate indirectly via the activity context. RAs and bandwidth. The idea here is to charge users less
SBBs make use of fireEvent() methods to fire events named money when the available bandwidth turns out to be
Event in the SLEE, e.g., SBB SL uses the method fireStart_ low.
Reservation_Request(). With corresponding onEvent() The overview of the new architecture is shown in Fig. 4
methods, SBBs receive events and execute their service on the next page. Forks with two dashed arrows denote an
logic. ‘exclusive or’ of firing events, that means that each time only
In contrast to SBBs, RAs cannot directly receive events one of the alternative events, e.g., E2 or E4 (and E3 or E7,
from inside the SLEE. This is why a dedicated SBB is respectively), is fired to the activity context.
necessary for each RA to provide response messages (e.g., Three SBBs and two profile tables are replacing the
SBB Diameter for RA Diameter); RAs and SBBs can previous single SBB SL:
directly communicate via the methods defined in the (a) SBB SA is a ‘preprocessing’ decision point
ResourceAdaptor-Sbb-Interface. Thus SBB Diameter and concerning service authorization. It is making use of
SBB OPSC receive the appropriate reply events and forward the profile table ServiceProfiles that keeps service-
them to RA Diameter and RA OPSC, respectively, using the related information to be able to decide whether a
send() method of the ResourceAdaptor-Sbb-Interface. subscriber needs to be authorized to access the
Note that the XCP is primarily intended to evaluate service or not (cf. Table I for some example entries).
JSLEE and its throughput performance compared to an (b) SBB CRF is acting as PCRF, providing PCC rules
existing implementation of a Diameter mediation device. and decisions upon incoming requests.
The XCP is therefore working as a simple protocol converter (c) SBB SPR is acting as SPR, using the profile table
from Diameter to OPSC Gold-compliant messages without UserProfiles with subscriber-specific information as
applying complex service logic yet. explained below.
B. PCC Case Study
This section describes our research study to extend the TABLE I. PROFILE TABLE SERVICEPROFILES
XCP prototype towards active mediation software compliant Service
with the 3GPP PCC Architecture. The prototypical Name Service
Authorization
implementation takes over the approach of the ‘Gx over Gy wlan-profile wlan@orga-systems.com required
application’, where PCRF and Online Charging System are voice-profile voice@orga-systems.com no
co-located [9]. content-profile content@orga-systems.com required
For our study, we consider three use cases for two users
… … …
A and B, assuming that these users are already registered and
authenticated in the system:
1. Service Authorization: Some services require
authorization (e.g., GPRS, WLAN), while others do When a Gx_over_Gy_Start_Reservation_Request event
not (e.g., SMS can always be used by all is received, SBB SA extracts the service context identifier,
subscribers) – assume user A is subscribed to a data e.g., wlan@orga-systems.com, and checks the ServicePro-
service (e.g., WLAN) and user B is not. The system files table to determine whether service authorization is
checks whether service authorization is required and required. If not, SBB SA behaves like SBB SL in the XCP,
if yes, it performs the authorization already at the i.e., it fires a Start_Reservation_Request event for SBB
mediation layer. The goal is that requests initiated by OPSC. Otherwise, a Gx_Request is fired and the additional
users not subscribed to a service (here: user B for SBBs CRF and SPR are performing further charging control.
WLAN usage) must be rejected without affecting the The SPR makes use of the profile table UserProfiles (see
OCS. Table II for some example entries).
2. Configurable Service-specific Parameters: User A
is subscribed to a multimedia service with a time- TABLE II. PROFILE TABLE USERPROFILES
based tariff and user B with a volume-based tariff.
When using the service, users are charged differently Metering
QoS-
according to the charging rules that apply for their Name UserID Service Infor-
Method
mation
subscribed tariffs. The system must be able to
profile1 123456 wlan@orga-systems.com volume 20%
flexibly manage subscriptions and charging policies
already at the mediation layer and add the profile2 654321 voice@orga-systems.com time
corresponding information to the request before it is profile3 500123 internet@orga-systems.com volume 100%
forwarded to the OCS. … … … … …
3. QoS-dependent Charging: Users A and B are
subscribed to a service with a volume-based tariff.

528
 Figure 4. PCC research study with JAIN SLEE
The result of the PCC logic performed by SBB CRF is
either (a) a Start_Reservation_Response (E3) in the case that
PCC failed and the associated service data flow is not
allowed to get through or (b) a Gx_Response event (E7) in
the case that PCC succeeded and rating has to be performed
next. The latter event is handled by SBB OPSC and RA
OPSC by converting the Attribute-Value Pairs (AVPs) of the
Gx_Response into the proprietary message format of the
charging system OPSC Gold.
W.r.t. the considered use cases and their implementation,
the following technical issues came up and had to be solved.
More details can be found in [11].
• Some AVPs that are optional in the Gx protocol had
to be made mandatory, e.g., Subscription-Id,
Metering-Method, QoS-Information and Guaranteed-
Bitrate.
• Some AVPs not present in the Diameter Credit-
Control Application are necessary to build
appropriate events. For example, Metering-Method is
necessary for use case 2 (and could be taken over
from Gx) or QoS-Discount together with its elements
Guaranteed-Bitrate and Metered-Bitrate are necessa-
ry for use case 3 (the latter three AVPs had to be
newly defined).
• For the Sp reference point, we reused parts of the Sh
standard interface [8], as the 3GPP PCC Architec-
ture does not define a concrete protocol for Sp.
• The integration of JSLEE profiles was a cumber-
some task, as there were no detailed documentations
or examples available. Therefore one of the assets of
the diploma thesis [11] is a guideline how to set up
and manage profiles in JSLEE.
• We started with the JSLEE v1.0 implementation of
Mobicents, in which profiles could only be modified
manually via the management console, i.e., SBBs
529
only had read access to profiles. While this was
sufficient for realizing the use cases, it is important
to note that SBBs and RAs now also have write
access in JSLEE v1.1. However, some developers
also recommend using the Java Persistence API9 or a
dedicated Persistence RA instead of JSLEE profiles.
V. CONCLUSION AND OUTLOOK
The work presented in this article describes a research
study to apply configurable service logic for policy and
online charging control at the mediation layer. The primary
goal was to be able to clearly distinguish between service
and charging logic by bringing more decision logic into the
mediation layer.
This objective has been investigated by realizing three
use cases concerning service authorization, configurable
service logic and QoS-dependent charging control. A proto-
type implementation running on Mobicents was extended to
realize these three use cases, while at the same time respect-
ing the principles and protocols of the 3GPP PCC Architec-
ture.
Experiences. As JAIN SLEE is a rather complex execu-
tion environment and only limited literature is available, we
found the learning curve quite steep; in particular, it was a lot
of effort to get JSLEE profiles running and finding out how
to connect to external systems like an Online Charging
System. Our experiences therefore confirm the general
statement of [10] by means of a concrete research study.
First performance tests have indicated that Mobicents
profiles are not well scalable. We are therefore going to
investigate different approaches, e.g., using a high-perfor-
mance database like Orga Systems’ InCore® shared memory
database.
9
http://java.sun.com/javaee/technologies/persistence.jsp
 Outlook. Based on our previous work [12], we currently
extend the system by RAs that comply with the Parlay X
standards for charging [13] and account management [14].
Concerning PCC, future work is to extend the research
study to cover additional use cases in the area of online
charging for digital media services (IP TV, Internet TV). It is
also a matter of further research whether it is necessary to
distribute PCC components like PCRF and SPR, e.g., for
load balancing purposes.
ACKNOWLEDGMENTS
This work is based on the prototypical eXtensible
Control Point and test environment. We would like to thank
all members of Orga Systems’ R&D department for their
implementation efforts to make this work possible. We
would also like to thank the product management department
for providing important ideas and continuous support.
Special thanks go to Adnan Yaqub and Swen Osterkamp for
their valuable ideas and constructive comments concerning
the use cases and the final version of this article.
REFERENCES
[1] 3GPP. TS 23.228: IP Multimedia Subsystem (IMS), Stage 2, V8.6.0,
September 2008. http://www.3gpp.org/ftp/Specs/html-info/23228.htm
[2] 3GPP. TS23.296: Online Charging System (OCS): Applications and
interfaces, V8.2.0, June 2008. http://www.3gpp.org/ftp/Specs/html-
info/32296.htm
[3] 3GPP. TS 23.203: Policy and charging control architecture, V8.3.1,
August 2008. http://www.3gpp.org/ftp/Specs/html-info/23203.htm
530
[4] D. Ferry et al. JSR 240: JAIN SLEE (JSLEE) v1.1, Final Release,
July 2008. http://jcp.org/en/jsr/detail?id=240
[5] P. Calhoun et al. Diameter Base Protocol, IETF RFC 3588,
September 2003. http://tools.ietf.org/html/rfc3588
[6] 3GPP. TS 29.212: Policy and Charging Control over Gx reference
point, V8.1.0, September 2008. http://www.3gpp.org/ftp/Specs/html-
info/29212.htm
[7] H. Hakala et al. Diameter Credit-Control Application. IETF RFC
4006, August 2005. http://tools.ietf.org/html/rfc4006
[8] 3GPP. TS 29.329: Sh interface based on the Diameter protocol;
Protocol details, V8.1.0, June 2008. http://www.3gpp.org/ftp/Specs/
html-info/29329.htm
[9] 3GPP. TS 29.210: Charging rule provisioning over Gx interface,
V6.7.0, December 2006. http://www.3gpp.org/ftp/Specs/html-info/
29210.htm
[10] M. Maretzke. “Java Telecommunication Application Server Techno-
logy Comparison”, July 2008. http://www.maretzke.de/pub/whitepa-
pers/telcoappserver_2008/
[11] A. Braun. “Policy and Charging Control for Online Charging”,
Diploma Thesis, Paderborn University, Paderborn, Germany, August
2008.
[12] F. Bormann, S. Flake, and J. Tacken. “Convergent online charging for
context-aware mobile services”. Proc. 2nd Int. IEEE Workshop on
Service Oriented Architectures in Converging Networked Environ-
ments (SOCNE 2007), Niagara Falls, Ontario, Canada, May 2007.
[13] ETSI. Open Service Access (OSA), Parlay X Web Services, Part 6:
Payment (Parlay X 3). Draft ETSI ES 202 504-6 v0.0.4, June 2007.
[14] ETSI. Open Service Access (OSA), Parlay X Web Services, Part 7:
Account Management (Parlay X 3). Draft ETSI ES 202 504-7 v0.0.4,
June 2007.