Towards a Policy and Charging Control Architecture for Online Charging

4 downloads 915 Views 295KB Size Report
mediation layer with more capabilities for online charging control. The presented ..... the diploma thesis [11] is a guideline how to set up and manage profiles in ...
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

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 syntactically incorrect). E.g., a request to start a GPRS connection is currently handled in the rating engine, even if the requesting user is not even subscribed to the GPRS service. However, 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 parameters 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

components and protocols relevant for the scope of this article. For the prototypical implementation of a corresponding 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, configurable 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.

Figure 2. 3GPP PCC architecture

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 information received from PCEF and the Subscription Profile Repository (SPR). The SPR contains all subscriber information 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 distributed 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 concerning 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.

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 information. 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 asynchronous, fine-grained and high-frequent event processing. This kind of processing is especially suitable for telecommunication networks. A good comparison of JAIN SLEE with JEE can be found in [10]. The most popular JSLEE platforms 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 components. The containers are fitted to the requirements of the 1

http://jcp.org/en/jsr/detail?id=22 http://www.jnetx.com 3 http://www.opencloud.com 4 https://www.redhat.com/solutions/telco 5 http://www.mobicents.org 2

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 socalled 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. Moreover, 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.

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 processed 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

Figure 3. eXtensible Control Point (XCP) prototype and test environment

7 6

http://jcp.org/en/jsr/detail?id=3

8

http://gull.sourceforge.net http://www.orga-systems.com

checks for correct message syntax and replies to each incoming request with an acknowledge message. There are three SBBs: SBB Diameter, SBB SL (SL is short for service logic), and SBB OPSC. The SBBs communicate indirectly via the activity context. RAs and SBBs make use of fireEvent() methods to fire events named Event in the SLEE, e.g., SBB SL uses the method fireStart_ Reservation_Request(). With corresponding onEvent() methods, SBBs receive events and execute their service logic. In contrast to SBBs, RAs cannot directly receive events from inside the SLEE. This is why a dedicated SBB is necessary for each RA to provide response messages (e.g., SBB Diameter for RA Diameter); RAs and SBBs can directly communicate via the methods defined in the ResourceAdaptor-Sbb-Interface. Thus SBB Diameter and SBB OPSC receive the appropriate reply events and forward them to RA Diameter and RA OPSC, respectively, using the send() method of the ResourceAdaptor-Sbb-Interface. Note that the XCP is primarily intended to evaluate JSLEE and its throughput performance compared to an existing implementation of a Diameter mediation device. The XCP is therefore working as a simple protocol converter from Diameter to OPSC Gold-compliant messages without applying complex service logic yet. B. PCC Case Study This section describes our research study to extend the XCP prototype towards active mediation software compliant with the 3GPP PCC Architecture. The prototypical implementation takes over the approach of the ‘Gx over Gy application’, where PCRF and Online Charging System are co-located [9]. 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 not (e.g., SMS can always be used by all subscribers) – assume user A is subscribed to a data service (e.g., WLAN) and user B is not. The system checks whether service authorization is required and if yes, it performs the authorization already at the mediation layer. The goal is that requests initiated by users not subscribed to a service (here: user B for WLAN usage) must be rejected without affecting the OCS. 2. Configurable Service-specific Parameters: User A is subscribed to a multimedia service with a timebased tariff and user B with a volume-based tariff. When using the service, users are charged differently according to the charging rules that apply for their subscribed tariffs. The system must be able to flexibly manage subscriptions and charging policies already at the mediation layer and add the corresponding information to the request before it is forwarded to the OCS. 3. QoS-dependent Charging: Users A and B are subscribed to a service with a volume-based tariff.

For user A just the volume is counted. For user B also the value of the available bandwidth is measured and part of the charging requests. User B is charged depending on the volume and available bandwidth. The idea here is to charge users less money when the available bandwidth turns out to be low. The overview of the new architecture is shown in Fig. 4 on the next page. Forks with two dashed arrows denote an ‘exclusive or’ of firing events, that means that each time only one of the alternative events, e.g., E2 or E4 (and E3 or E7, respectively), is fired to the activity context. Three SBBs and two profile tables are replacing the previous single SBB SL: (a) SBB SA is a ‘preprocessing’ decision point concerning service authorization. It is making use of the profile table ServiceProfiles that keeps servicerelated information to be able to decide whether a subscriber needs to be authorized to access the service or not (cf. Table I for some example entries). (b) SBB CRF is acting as PCRF, providing PCC rules and decisions upon incoming requests. (c) SBB SPR is acting as SPR, using the profile table UserProfiles with subscriber-specific information as explained below. TABLE I.

PROFILE TABLE SERVICEPROFILES

Name

Service

Service Authorization required

wlan-profile

[email protected]

voice-profile

[email protected]

no

content-profile

[email protected]

required







When a Gx_over_Gy_Start_Reservation_Request event is received, SBB SA extracts the service context identifier, e.g., [email protected], and checks the ServiceProfiles table to determine whether service authorization is required. If not, SBB SA behaves like SBB SL in the XCP, i.e., it fires a Start_Reservation_Request event for SBB OPSC. Otherwise, a Gx_Request is fired and the additional SBBs CRF and SPR are performing further charging control. The SPR makes use of the profile table UserProfiles (see Table II for some example entries). TABLE II. Name

UserID

PROFILE TABLE USERPROFILES Service

Metering Method

QoSInformation 20%

profile1 123456

[email protected]

volume

profile2 654321

[email protected]

time

profile3 500123

[email protected]

volume

100%











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 GuaranteedBitrate. • Some AVPs not present in the Diameter CreditControl 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 necessary 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 Architecture does not define a concrete protocol for Sp. • The integration of JSLEE profiles was a cumbersome 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

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 prototype implementation running on Mobicents was extended to realize these three use cases, while at the same time respecting the principles and protocols of the 3GPP PCC Architecture. Experiences. As JAIN SLEE is a rather complex execution 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-performance 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.

[4] [5] [6]

[7] [8]

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.

[9]

[10]

[11]

[12]

REFERENCES [1] [2]

[3]

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 3GPP. TS23.296: Online Charging System (OCS): Applications and interfaces, V8.2.0, June 2008. http://www.3gpp.org/ftp/Specs/htmlinfo/32296.htm 3GPP. TS 23.203: Policy and charging control architecture, V8.3.1, August 2008. http://www.3gpp.org/ftp/Specs/html-info/23203.htm

[13] [14]

D. Ferry et al. JSR 240: JAIN SLEE (JSLEE) v1.1, Final Release, July 2008. http://jcp.org/en/jsr/detail?id=240 P. Calhoun et al. Diameter Base Protocol, IETF RFC 3588, September 2003. http://tools.ietf.org/html/rfc3588 3GPP. TS 29.212: Policy and Charging Control over Gx reference point, V8.1.0, September 2008. http://www.3gpp.org/ftp/Specs/htmlinfo/29212.htm H. Hakala et al. Diameter Credit-Control Application. IETF RFC 4006, August 2005. http://tools.ietf.org/html/rfc4006 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 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 M. Maretzke. “Java Telecommunication Application Server Technology Comparison”, July 2008. http://www.maretzke.de/pub/whitepapers/telcoappserver_2008/ A. Braun. “Policy and Charging Control for Online Charging”, Diploma Thesis, Paderborn University, Paderborn, Germany, August 2008. 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 Environments (SOCNE 2007), Niagara Falls, Ontario, Canada, May 2007. 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. 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.