mediation, rating and billing in an ip services environment · white paper: mediation, rating and...

White Paper:Mediation, Rating and Billing in an IP services environment -

architecture and approach

Authors: Conor Ryan, Boris Rousseau, Cathal O’ Riordan - Waterford Institute of Technology, Ireland Soren Vejgaard-Nielsen - UH Communications, Denmark

Contact: {cryan, brousseau, coriordan}@tssg.org [email protected]

Version: January 2004

ABSTRACTThe evolution of network technologies, service types and consumer demands have profoundimplications for accounting and billing. The application of traditional voice and dataaccounting methods to the contemporary IP based services of next generation networks haveproven too cumbersome and hinder rather than help the process. The notion of a ‘call’ cannoteasily be applied to the types of services that are emerging from rapidly progressing NextGeneration networks rollout. 3rd Generation type services are exhibiting new characteristicsthat are far removed from their predecessors, leading to new and challenging ways to accountfor their usage. The high level of interaction and rich user experience offered by many of theseservices places a real-time requirement on the supporting delivery and accounting systems. A30 or 45 day billing cycle will not support the demands of such services. Instead, analternative mindset is needed when considering the application of accounting principles(mediation, rating and billing) to this new evolution of services. This white paper presents areusable solution to the challenges of billing for 3G IP based services by leveraging existingstandards for usage data capture, messaging, mediation and transformation.

KEYWORDS3G, Accounting, Mediation, Billing, Rating, Network, Service, Federation

Table of Contents

ABSTRACT....................................................................................................................................................................................... 13G, Accounting, Mediation, Billing, Rating, Network, Service, Federation..........................................................................................11Introduction...........................................................................................................................................................................................4

1.1Context ..........................................................................................................................................................................................41.2Presentation of AlbatrOSS.............................................................................................................................................................41.3Document Description................................................................................................................................................................... 5

2Accounting State of the Art ................................................................................................................................................................. 52.13GPP..............................................................................................................................................................................................52.2IETF’s AAA.................................................................................................................................................................................. 52.3ITU-T.............................................................................................................................................................................................62.4IPDR NDM-U................................................................................................................................................................................62.5W3C and OASIS............................................................................................................................................................................62.6OSS through Java Initiative........................................................................................................................................................... 7

3Information Model................................................................................................................................................................................73.1Context...........................................................................................................................................................................................73.2New Shared Information and Data Billing model......................................................................................................................... 73.3Proprietary Account Record (PAR)...............................................................................................................................................93.4IPDRDoc and IPDR.....................................................................................................................................................................103.5Charging Scheme.........................................................................................................................................................................10

4Accounting Architecture.....................................................................................................................................................................114.1Requirements............................................................................................................................................................................... 114.2Service Layer............................................................................................................................................................................... 114.3Mediation Layer...........................................................................................................................................................................124.4Transport Layer........................................................................................................................................................................... 124.5Billing Layer................................................................................................................................................................................13

5Implementation................................................................................................................................................................................... 155.13G Billing sub-trial context......................................................................................................................................................... 175.2Mediation.....................................................................................................................................................................................185.3Rating...........................................................................................................................................................................................195.4Flexible customisable Billing...................................................................................................................................................... 20

6Conclusions.........................................................................................................................................................................................227References...........................................................................................................................................................................................23

Table of Figures

Figure 1 UML Class Diagram for the AlbatrOSS SID Billing Domain................................................................................................. 8Figure 2 PAR Structure...........................................................................................................................................................................9Figure 3 IPDR Document structure...................................................................................................................................................... 10Figure 4 Service Accounting Architecture............................................................................................................................................11Figure 5 SubscribeReq Primitive..........................................................................................................................................................12Figure 6 PushReq Primitive..................................................................................................................................................................13Figure 7 Spreadsheet and IPDR based Tariffing Scheme.....................................................................................................................14Figure 8 Example bill extract................................................................................................................................................................15Figure 9 Excerpt from Trial 1 storyboard.............................................................................................................................................17Figure 10 AlbatrOSS 3G Billing Sub Trial ........................................................................................................................................ 17Figure 11 IPDR functions of the Q3ADE IPDR Store component...................................................................................................... 18Figure 12 IPDR Store Management Interface...................................................................................................................................... 19Figure 13 Bill production process........................................................................................................................................................ 20Figure 14 Billing user interface............................................................................................................................................................ 21

1 Introduction

1.1 Context

Mediation, rating and billing are the most critical operational support activities conducted by a provider (network orservice) in an IP services environment. The ability to effectively and efficiently charge for the consumption ofresources represents an important competitive advantage for any telecommunications organisation. This activityensures revenue collection for services offered and is the most prominent customer-facing operation support process ofany organisation, commonly referred to as Customer Relationship Management (CRM).

The next generation of the ‘communications’ environment sees the convergence of the IT and telecommunicationsindustries. This convergence has instigated a profound growth in the number and types of services and acceleration inthe emergence of network technologies1. This evolution of the communications industry has serious impacts on billingand accounting solutions. Traditional telecommunications billing and accounting systems are proprietary to providers,services and networks and are generally rigid in nature. Accounting and billing for IT services is limited, as the vastmajority of services have been delivered free over the Internet while flat rate access fees have been charged.The industry is now witnessing a paradigm shift towards services that are composed of standard software componentsand delivered over emerging network technologies; the next generation in mobile services. Accounting for theseservices involves a revolutionary change in the approach that served the previous service generation. This has pavedthe way for open and adaptable accounting solutions that can accommodate the myriad of services that will be rolledout over the lifetime of these current technology waves.

1.2 Presentation of AlbatrOSS.

To support the timely rollout of Next Generation (NG) networks and services, and to fulfil end-user expectations ofthe associated marketing hype, capable management platforms must be in place. The time to market of these serviceswill be a critical factor in their success or failure and will depend greatly on support from lower operational levels.The complex communications environments that NG networks and services will introduce, will highlight theinadequacies of current generation Operation Support Systems (OSSs). The limitations of such systems are apparent inthe areas of provisioning, billing, integration, service design and subscription management. The rapid emergence ofaccess networks (GPRS, UMTS, WLAN, Bluetooth etc.) and the evolution of services (location based, context aware,customisable) are forcing a paradigm shift in the communications industry. The convergence of the IT andtelecommunications industries represents the first step in this progression. IT engineers are focused on providingservices to the customer while telecommunications engineers are focused on the network. Hence, on the horizon ofconvergence IT people are looking up to the service level while telecommunications people are downward focused onthe network level. The key to advancement is the line of convergence. A layer needs to be built to support convergenceand seamless integration between the two industries to deliver pervasive services in ambient network environments.The primary focus of the AlbatrOSS project is the specification of a Third Generation (3G) OSS architectureframework that represents this layer. This framework will provide the essential elements required to build integratedand open OSSs required to support the service centric environment of next generation service/network operation anddelivery.The objectives of the AlbatrOSS project can be summarised as follows:

To specify an innovative 3G OSS (3G OSS) architecture framework applicable to an open 3G mobiletelecommunications environment.

To develop a set of OSS building blocks to support rapid service creation, provisioning and maintenance ofmobile Internet based services.

To validate the 3G OSS architecture framework and building blocks through the execution of a set of trialsystems.

Since the original conceptualisation of AlbatrOSS there have been shifts in the industry that have lead the projectconsortium to move its focus from 3G (UMTS) environments to include other network technologies including GPRS,

1 GSM, GPRS, UMTS, WCDMA etc.

WLAN etc. Hence, where the project refers to a 3G OSS, the term 3G also incorporates other network and servicetechnologies.In order to achieve its objectives, AlbatrOSS is carrying out the following work:

1. Capturing end-user, service provider and network provider requirements for 3G services and networks.2. Specifying an open OSS architecture for managing 3G services based on the requirements capture and on the

state of the art as reflected in the current activities of standards bodies and industrial consortia.3. Identifying and evaluating software technologies to be integrated to support the development of a 3G OSS

platform.4. Integrating and customising open network, service and application components into a 3G OSS platform.5. Validating the architecture framework through the operation of a set of sub trials based on usage scenarios

from the requirements analysis and which support adaptive end-user services on mobile devices.

1.3 Document Description.

This white paper presents a reusable solution to the challenges of accounting and billing for 3G IP based services andis structured as follows:Chapter 2 introduces the context with an accounting state of the art. It provides an overview of the relevant standardsbodies in the area of accounting and billing. Chapter 3 depicts the information models that serve as the basis for theaccounting and billing architecture. Chapter 4 details the accounting architecture as a set of reusable building blockspecifications representing important functional domains of an OSS capable of supporting present day and future 3GIP based services. Chapter 5 provides a detailed description of the trials implementation demonstrating billing for avariety of service usage and access. Chapter 6 summarises the work achieved.

2 Accounting State of the Art

2.1 3GPP

The 3rd Generation Partnership Project (3GPP) [1] is a collaboration agreement between a number oftelecommunications standards bodies referred to as “Organizational Partners”. The current Organizational Partnersare ARIB, CCSA, ETSI, T1, TTA, and TTC. The goal of the partnership is to produce Technical Specifications for a3rd Generation Mobile System based on the evolved GSM core networks and the radio access technologies that theOrganizational Partners support. The current work of the Architecture and Telecom Management sub-groups of theServices and Systems Aspects group within the 3GPP (3rd Generation Partnership Project) has produced a number ofstandards with relevance to charging and billing within an IP based service domain.

The 3GPP has also joined effort with ETSI [2] and the Parlay organisation’s [3] Content-based Charging WorkingGroup to deliver the Open Service Access (OSA) APIs specifications, which include accounting and chargingmanagement [4]. These standards provide an important reference base for all accounting related matters such as recordformat and charging.

2.2 IETF’s AAA

The IETF’s AAA (Authentication Authorisation and Accounting) Working Group is focusing on the development offunctional requirements for usage mediation, revenue generation, billing, service quality and reliability, and roaming. AAA [5] defines the system in IP-based networking to control what computer resources users have access to and tokeep track of the activity of users over a network.

Authentication is the security service of identifying the individual user of a particular service, usually basedon a username and password. Authentication is based on the idea that each individual user will have uniqueinformation that sets him or her apart from other users.

Authorisation is the process of grating or denying access to network and services resources once the user hasbeen authenticated. The amount of resources the user has access to depend on the user’s contract agreementwith the provider (network or service).

Accounting is the process of keeping track of a user's activity while accessing the network resources, includingthe amount of time spent in the network, the services accessed while there and the amount of data transferredduring the session. Accounting data is used for trend analysis, capacity planning, billing, auditing and costallocation. It requires that resource consumption be measured, mediated, rated, and communicated betweenappropriate parties.

2.3 ITU-T

The International Telecommunications Union Telecommunication Standardisation Sector (ITU-T) is one of the threesectors from the ITU carrying work on the production of high quality standards covering all fields oftelecommunications. The ITU-T [6] consists of 13 study groups. Tariff and accounting activities is mainly investigatedin Study Group 3. It develops charging and accounting/settlement mechanisms for network capabilities and servicesfeatures made available by new technologies such as IP based networks.The ITU-T is responsible for Recommendation Q.825 [7], which specifies how CDRs (Call Detail Records) areproduced and managed in a network environment. Each call produces one or more records describing events thatoccurred during the life of a call. Data may be produced in real time (single CDRs), near real-time (blocks of CDRs),or as batch files of CDRs.

2.4 IPDR NDM-U

The Internet Protocol Detail Record (IPDR) organisation Network Data Management – Usage (NDM-U) specification[8] defines standardised interface, protocols and record format to facilitate the flow of usage information betweenfrom IP network elements managers to support systems.

The NDM-U defines a high-level model including: a network and service element layer, mediation layer andbusiness support systems layer.

The network layer consists of all the network and service elements required to provide an IP-based service to aparticular customer.

The mediation layer sits between the network infrastructure and the business support systems. It provides thefacilities to collect all usage data from various services and pass it to the business support systems (BSS). TheBSS layer consists of the customer facing services deployed by a service provider to support IP businessoperation. Some examples include billing, customer care, analysis and reporting.

NDM-U also defines some schemes for encoding IP usage records known as the IPDR records. This informationmodel will be further detailed in the next section.

2.5 W3C and OASIS

The World Wide Web Consortium [9] and the Organisation for the Advancement of Structured Information Systems[10] are developing interoperable technologies capable of leading communication and commerce on the Web. WhileW3C has taken the leadership of any technical evolution on the Web taking advantage of the convergence betweencomputers, telecommunications and multimedia technologies, OASIS’ focus is on driving the development,convergence and adoption of e-business standards for industries.W3C comprises several activities that are organised into five distinct domains:

Architecture domain: develops the framework of the web. Document formats domain: defines formats and language that will present information to the user accurately. Interaction domain: works towards improvements in human-computer interaction. Technology and Society domain: develops the infrastructure to address legal, social and policy concerns. Web Accessibility Initiative: pursuing accessibility of the Web through research and development, and

production of guidelines.

The W3C is responsible for the emergence of the eXtensible Markup Language [11] and Web Services [12] that nowserves as a basis for most of the standards for information exchange.Industry members of OASIS form technical committees in the following areas:

Horizontal and e-business framework Web Services Security Public Sector Vertical industry applications

The Business Transaction Technical Committee’s [13] purpose is to develop technology for business transactions onthe Internet.

2.6 OSS through Java Initiative

The introduction of Next Generation networks and the services they will provide highlight the lack of interoperableOperation Support Systems (OSS) and Business Support Systems (BSS) required to sustain their function. The currentOSS market is fraught with proprietary systems that present costly resources to maintain and update when newnetwork and service types are introduced. The OSS through Java Initiative [14] attempts to inject a unified componentbased approach to OSS and BSS implementation using a common set of Java APIs that capture the essential functionaldomains of modern support platforms. Much work has already been accomplished by standards bodies and industrialfora in capturing requirements, business processes and architectural specifications for modern OSS and BSS systems.Drawing on the knowledge and experience of groups such as the 3rd Generation Partnership Project (3GPP), 3GPP2,Mobile Wireless Internet Forum (MWIF), TeleManagement Forum (TMF), Internet Engineering Task Force (IETF),and Internet Protocol Detail Record organisation (IPDR) the Initiative will produce a set of Java class hierarchies (andsource code) representing particular functional areas of an OSS. The OSS Solutions are based on Java 2 EnterpriseEdition technology (J2EETM). Currently APIs for six functional areas are being specified through the Java CommunityProcess [15]. They are Service Activation, Quality of Service, Trouble Ticket, Billing, Inventory and Service QualityManagement.

3 Information Model

3.1 Context

The AlbatrOSS consortium adopted the NGOSS™-based Shared Information and Data model (SID) to represent thedifferent components involved in a common information representation. The SID NGOSS principle described in [16]is the result of the application of such model to the AlbatrOSS requirements.The objectives of such model can be summarised as follows:

Define a common information and data model that all the consortium members will adhere to Promote a common conceptual view that addresses major issues in a 3G environment Provide the TM Forum SID working group with feedback.

The SID domain of interest for accounting is the billing domain. This domain provides all entities and relations thatsupport billing delivery from the mediation of usage records to the delivery of an invoice bill to the customer (end useror service provider).

The SID model mainly relies on the TM Forum SID work [17], which was a major resource used by AlbatrOSS. WhileTM Forum addresses several complex issues and representations, it does not define a general framework to deal withbilling. The Billing model is an attempt to fill this gap by bringing together models such as Service Level Agreement(SLA) and preferences as well as information models (PAR and IPDR) to represent the activities of mediation of usagerecords, charging and production of an invoice bill.3.2 New Shared Information and Data Billing model

This new Billing model attempts to cover a large set of requirements needed to capture the relevant information toproduce an invoice bill. The following simplified model focuses on those requirements:

Mediation of proprietary account records into IPDR Correlation and aggregation of those IPDRs Rating and Billing of this information based on charging schemes (derived from an SLA) Using those rated IPDR documents to produce an invoice depending on the customer and service details

provided

Figure 1 UML Class Diagram for the AlbatrOSS SID Billing Domain

PreferenceSetPreference

PARparI DparI nfo

B il lingPrefe renceBi ll ingPreferenceSet

1..*1 1..*1

Bi ll ingAddress

customerProfi le

1..*1..*

1..*1..*

CustomercustomerIDcustomerName

1

1..*

1

1..*

IPDRDocdocIDversioncreationTimeIPDRRecorderInfo

InvoiceinvoiceIDtimePeriodinvoiceInfopayeeIDreceiverID

0..* 10..* 1

1..*

1

1..*

1

IPDRIPDRCreat ionT im eseqNum

0..*

1.. *

0..*

1.. *

is mediated to

1..*

1

1..*

1

hasIPDRs

PartyRole

Agreement

AgreementDocumentNumber : VARCHAR2AgreementStatementOf Intent : VARCHAR2AgreementPeriod : VARCHAR2AgreementAuthorizationState : VARCHAR2AgreementAuthorizationDate : VARCHAR2AgreementSignatureRepresentation : NUMBER

1..*1..*

ChargingSchemeschemeIDalgorithmtariff tableschargesettlement

0..*1..* 0..*1..*

uses

1

1..*

1

1..*

derived from

3.3 Proprietary Account Record (PAR)

In the IPDR NDM-U reference model the interface between a service element and an IPDR recorder is named the A-Interface. The NDM-U specification does not attempt to constrain file naming, format, transfer protocol, sequencing orany other details of this interface, as the IPDR Recorder is expected to be able to retrieve usage data from serviceelements in any proprietary form the service element may provide.

Following the AlbatrOSS architecture concept that all OSS components are using a common communication bus (inthe AlbatrOSS trial case in the form of web-services interfaces), the project has investigated a common informationstructure for the information exchanged across this interface.

The PAR (Proprietary Accounting Record) information model is not an attempt to standardise the NDM-U A-Interfacebut merely to provide a convenient format to be used when the conditions allow it.

The PAR structure is defined as a general service usage record capable of covering the most service types. Itcategorises services in three basic types of usage records:

DurationPAR: Types of services where the charging is based on the amount of time the service has been inuse.

EventPAR: Types of services where charging is based on execution of single events, such as finding alocation, performing a search operation, etc.

VolumePAR: Types of services where charging is based on amount of service usage, such as amount of datatransported during a WLAN session.

A PAR thus contains one of these EventPAR, DurationPAR or VolumePAR elements.

-serviceProviderID-serviceID-serviceLabel-userID

PAR

-eventTime-event

EventPAR

-startTime-endTime

DurationPAR-amount-unit

VolumePAR

1

1

-sessionID-recordType

SessionInfo

1

-hasSessionInfo0..1

ElementPAR

Figure 2 PAR Structure

The serviceProvider, serviceID and serviceLabel are used to uniquely identify the service being reported. The userIDuniquely identifies the user who is making use of the service.

The sessionInfo element is optional, and may be include for the purpose of performing correlation of PAR records.Correlation of records is performed based on the sessionID attribute within the SessionInfo element. All recordspertaining to a session can be aggregated into a single IPDR Document by the mediation function before forwardingthe usage records to a rating and billing function.

3.4 IPDRDoc and IPDR

These classes capture the structure of the Internet Protocol Detail Record (IPDR) as defined by the Network DataManagement Usage for IP-Based Services version 3.1.1 [8]. This structure allows for an IPDRDoc to contain one ormany usage records (or IPDRs), which are service specific. The IPDR record is generally described as containing information about the customer, service provider, and metrics orparameters of a particular usage event. The usage represented may be measured as a discrete event, or part of anongoing session.Figure 3 graphically presents the structure of an IPDR Document

Figure 3 IPDR Document structure

The Proprietary Account Records have to be mediated using the architecture’s mediation layer (see chapter 4) to IPDRin order to be incorporated in the billing process.

3.5 Charging Scheme

Charging Schemes are spreadsheets that serve as a basis for the Service Rating function of the architecture. ACharging Scheme is the algorithmic representation of a textual SLA. It contains a set of rules applied to a rateableusage record in order to produces a rated IPDR Document.

The Service Rating is responsible for applying such charge to a usage record depending on usage parameters includingvolume, content and quality type parameters. Discounts will be applied in accordance with parameters specified in thecustomer SLA. These SLA parameters are captured in service-specific charging schemes. Several charging schemescan be used to generate a rated IPDR document, for instance a service session might be across a peak and off-peaktime, hence requiring two different charging schemes.

The Service Rating relies on the following process: Identify the applicable tariff scheme by extracting the relevant information on the customer, provider and

service type from usage records. Apply the arbitrarily complex tariffing scheme to the relevant parameters in the usage record to generate a

charge. Insert the resulting charge into the original usage record and store the rated usage record in the accounting

repository.

4 Accounting Architecture

The vision for the AlbatrOSS architecture is a set of reusable building block specifications representing importantfunctional domains of an OSS capable of supporting present day and future 3G IP based services. One of the areasinvestigated and subsequently adopted, as part of the AlbatrOSS architecture is the area of Accounting. By viewingservices (both network and interactive service) as simply capturing what level of service usage has occurred theAlbatrOSS project consortium was able to develop an accounting architecture that is independent of both network andservice allowing it to be applied to any conceivable NG accounting domain. As previously stated the complex natureof NG services introduces new challenges when applying an accounting process. Any number of services maycollaborate over multiple sessions to deliver rich content to a user device. Each resource will produce usage recordsdetailing its level of usage in the service delivery that has to be correlated with usage data from other resources toaccount and eventually produce a charge for the service. With this in mind a set of requirements for an accountingarchitecture were devised:

4.1 Requirements

Service Independent, capable of supporting any conceivable network and service type. A common accounting record format to detail service usage. Flexible charging scheme generation allowing the capture of complex and granular rating rules. Support for inter-domain settlement/clearing Flexible end-user (near real-time) bill generation supporting the need for one-stop billing through the

aggregation of service & network charges. Generic protocol and supporting interfaces between all entities in the accounting architecture (service/network

provider, mediator, rating provider, billing provider).

4.2 Service Layer

Figure 4 depicts the overall layered architecture that was developed to support the accounting of IP based services inthe set of Albatross trials scheduled to run throughout the lifetime of the project. The Service Element layerrepresents the typical resources consumed during the service/network provision activity. These entities are capable ofproducing usage data in standard or proprietary records formats and represent both hardware and software basedcomponents.

Figure 4 Service Accounting Architecture

For the architecture to be effective in serving such a wide array of service types the usage data generated from themediation layer must be captured in a predictable format. The IPDR NDM-U specification [8] defines a commonXML based usage record format to capture the intricate details of IP based services. The idea central to the IPDRinitiative is similar to that of the CDR, which is a record of system events and is widely used in the telephony world. ACDR is produced every time a user makes a call. Among other information, a CDR contains the start and end times ofcalls, and the identification of the calling and called parties. This information is then used by an accounting system tocreate charged records that support bill preparation and subsequent analysis. The IPDR is the corresponding recordformat for IP-based networks and services.

The structure and usage attributes of an IPDR are captured in a service definition XML Schema [19]. This schemaforms a contract between the producer and consumer of IPDR records and enables validation of incoming records forverification of their content. The encapsulated resource usage information may serve more than just the billingprocesses where activities like performance analysis, fraud detection, CRM etc. also benefit from the record payload.

4.3 Mediation Layer

The complexities of the data presented by the underlying Service Element layer are abstracted through the use of a setof Service Billing Adapters. These adapters are responsible for collecting and converting the Service Element usagedata into IPDR record format. The Service Billing Adapters may be stand-alone components or integrated directlyinto the Service Element, and can work in a one to one or one to many configurations with the Service Elements. TheBilling Adapters provide an abstraction of the actual type of service, which may be anything from raw networktransport to sophisticated location based services. The Billing adapters are made up of a set of sub-components: IPDRRecorder (IR), IPDR Store (IS) and IPDR Transmitter (IT) [8]. The IR acts as a mediation device and is responsiblefor producing IPDRs from the many proprietary data formats of the underlying Service Elements. The IPDR Storeprovides persistence to the generated IPDRs from the IPDR Recorder. The IS correlates the various independentservice records using a predefined algorithm and packages them into higher-level IPDR Document containers. Thedocument container represents an entire service usage and is the smallest unit of correlated data. Finally, the IPDRTransmitter provides a mechanism for the timely and reliable delivery of IPDRs to the supporting layers above.

4.4 Transport Layer

The IPDR NDM-U specification also defines a document transfer protocol. The D interface [8] defines a set ofmessages and related parameters for the negotiation of a reliable transport session between the mediation and billinglayers for the delivery of IPDRs. Using the IT Push model of delivery the Service Rating component in the abovearchitecture subscribes to a specific group of IPDRs maintained by the IPDR Transmitter in the Service BillingAdapter component. An IPDR group may be based on a service type such as Voice Over IP (VOIP) or serviceconsumer identifier or any other conceivable grouping; inevitably the nature of the service will dictate the mostappropriate grouping. When an IPDR from a subscribed group becomes available it is delivered to the Service Ratingcomponent for rating and subsequent usage bill generation by the Service Billing component.Typically the Service Rating component will advertise its willingness to accept usage records from the mediation layerduring its lifetime and this is achieved through the formation of a SubscribeReq primitive. Figure 5 below representsthe SubscribeReq structure.

Figure 5 SubscribeReq Primitive

The requestorId attribute defines the protocol specific identifier of the entity instigating the request and could map to aHTTP URL [20], SIP address [21] or any other applicable application level protocol. The groupId attribute identifiesthe particular IPDR grouping that is to be received by the requesting entity.After receipt of the SubscribeReq request the IPDR Transmitter of the serving Service Billing Adapter will initiate atransfer of available IPDRs using the PushReq primitive.

Figure 6 PushReq Primitive

This time the requestorId attribute represents the identifier of the IPDR Transmitter within the mediation domain. AnIPDR document containing IPDRs from the requested group is sent in the body of the message along with a documentand group identifier.

4.5 Billing Layer

The Service Rating component offers the functionality to support the massaging of rateable events contained in IPDRswith applicable tariffing schemes, into a final charge presented in an end user bill. The rules for rating each serviceare encapsulated in spreadsheet based charging schemes (see Figure 7) that match specific parameters within the IPDR(e.g.. startTime, bytesIncoming, operationType) with their corresponding algorithms for calculating the resultingcharge. It should be noted that the tariffing schemes exist completely independently of the rating engine that appliesthem to IPDR usage records. Hence, tariffing schemes can be updated and initiated without any recompilation of therating engine. Furthermore, the Spreadsheet nature of the schemes allows them to be manipulated by non-technicaloperatives e.g. accounts/pricing and marketing type staff without the direct intervention of technical programmers,service engineers etc.

Figure 7 Spreadsheet and IPDR based Tariffing Scheme

Flexible customisable Billing is achieved by using eXtensible Stylesheet Language Transformation (XSLT) [22]technology. After querying the Repository for the relevant (based on the user, service type, time period) IPDRdocuments a set of XSLTs perform the required transformation to produce an invoice/bill in the required format.Similarly to the tariffing schemes, XSLTs exist completely independently from the billing engine that applies them tothe resulting IPDR usage records. Hence, transformations can be updated or added (if a service provider has a newservice to offer to the customer) without any recompilation of the billing engine. The customer (end user or serviceprovider) can define its own view of billing simply by requesting particular parameters on the GUI. Hence, thecustomer can view its last charge, view the bill only for a particular service and request a bill for a time period.The example bill shown below represents the last few records (each IPDRDoc element separated by a line) displayedin HTML format. Network and Service independent style sheets have also been defined for Portable Document Format(PDF), Wireless Markup Language (WML) and for device dependant screen sizes.

Figure 8 Example bill extract

The ultimate goal of the Accounting Architecture was to demonstrate federated accounting [23] for a set of NextGeneration services under near real time conditions. The inherent latency of the delivery medium for usage recordsand the fact that billing was performed on a post-event basis restricted the usage reporting activity to a matter ofseconds after the service event had occurred. The current work of the Architecture and Telecom Management sub-groups of the Services and Systems Aspects group within the 3GPP (3rd Generation Partnership Project) has produceda number of standards with relevance to charging and billing within an IP based service domain. The concept of the IPMultimedia system has been defined across a number of working specifications [24] [25] and presents a platform tosupport the wide and varied number of IP multimedia applications being proposed and developed. Of particularinterest is the concept of online charging [26] where charging information can affect, in real-time, the service renderedand therefore directly interacts with the session/service control to grant and deny service usage, even when the servicedelivery process has already commenced. This has specific connotations for the delivery of pre and post-paid servicesover access networks where the balance of the customers account can affect (in real time) ongoing delivery of aservice. Integrating other aspects of a customers profile into the online charging process will allow more rigid controlover the types of services that can be delivered; age verification, credit check or subscription status are all validcontrols.

5 Implementation

The implementation and validation of the AlbatrOSS Accounting architecture was performed through a set of trial sub-systems [27]. These systems were based on pre-conceived storyboards depicting typical 3G service usage scenariosfeaturing the relevant stakeholders or actors involved in the 3G service market place [28]. Devising these scenarioshighlighted potential requirements of a 3G OSS and were an important step in identifying what functions theAlbatrOSS OSS building blocks should posses. Using this as a vehicle to specify how the customer, service providerand service interoperate several systems were assembled from the AlbatrOSS OSS components.

Before Jill leaves for the tennis court, she wants to check if everything is okay at home. With her laptop, she logs into her Smart Home service (through the hotel WLAN hotspot) to use her HomeCam to check on her kids. She also uses several other Smart Home services including the TV Automation service to switch off the T.V. in her kid’s room. Finally she determines the cost of using the services by accessing the account information page from her service portal.

Before Jill leaves for the tennis court, she wants to check if everything is okay at home. With her laptop, she logs into herSmart Home service (through the hotel WLAN hotspot) to use her HomeCam to check on her kids. She also uses severalother Smart Home services including the TV Automation service to switch off the T.V. in her kid’s room. Finally shedetermines the cost of using the services by accessing the account information page from her service portal.



Figure 9 Excerpt from Trial 1 storyboard

5.1 3G Billing sub-trial context

One of the trial sub-systems conceived for the first phase of the AlbatrOSS project trials was concerned withdemonstrating billing for Smart Home service usage and access. This was achieved through the integration ofcomponents that comprised of Waterford Institute of Technology’s Rating Bureau Service [29] and Billing Service,UH Communications’ Mediation Service, Telefonica I+D’s Smart Home Services and LAKE Communications’WLAN product (see Figure 10). Telefonica's Smart Home is comprised of an apartment containing multiple types ofintelligent white appliances, home cameras, electronic blinds, security and safety alarms etc. These devices and alarmscan be accessed and controlled through a web portal that connects through an Asymmetric Digital Subscriber Line(ADSL) gateway to the apartment. The apartment owners can access their Smart Home from anywhere in the world byusing the Smart Home web portal. The usage scenario (see Figure 9 above) focuses on federated accounting for 3GServices, whereby access to services can be performed under roaming conditions. Federated accounting is achievedby aggregating the cost of Smart Home Service usage with the cost of accessing the service through a WLAN Hotspot.

Figure 10 AlbatrOSS 3G Billing Sub Trial

The following sections describe some of the components that featured in the 3G Billing trial sub-system and discussesthe technologies used to implement them.






5.2 Mediation

The Q3ADE IPDR Store implements a billing adaptor component for the AlbatrOSS architecture. The IDPR Store iscapable of collecting and aggregating network and service usage data from a wide range of underlying sources,including CORBA, SNMP, TL1, CMIP and SOAP/HTTP enabled network entities or services.

Figure 11 IPDR functions of the Q3ADE IPDR Store component

In relation to the IPDR NDM-U reference model the Q3ADE IPDR Store implements the functions IPDR Recorder,IPDR Store and IPDR Transmitter.In the AlbatrOSS project, where all components are loosely interconnected using a common communications bus(HTTP based SOAP), the Q3ADE IPDR Store offers the usage data mediation as web-services. At one end theQ3ADE IPDR Store offers web-services interface for recording proprietary accounting records from service elementsand transform records into IPDR records. At the other end the IPDR Store offers a push service for forwarding IPDRDocuments to the rating function.

Inhaling Network and Service Usage DataIn the AlbatrOSS project the network and service usage data is inhaled as XML structured data over a HTTP basedSOAP interface. Almost all services in AlbatrOSS used the general PAR structure for the usage records, but someservices use a proprietary XML structure.

Correlating Usage DataIn the first phase of the AlbatrOSS project the Q3ADE IPDR Store performed correlation of usage records acrossservices, based on user ID and time stamps in order to aggregate IPDR Records into single IPDR Documents beforeforwarding the usage information to the rating functions. This correlation scheme proved difficult to accomplish forcomplex services consisting of multiple aggregated service components.

In the second phase of the AlbatrOSS project the time based correlation concept was abandoned as it was consideredtoo complex for a realistic service scenario. Instead the concept of session information was introduced allowingcorrelation of usage records within a user session. The correlation scheme that was implemented correlate only theusage records pertaining to a user session within each service. This correlation scheme proved simple to implementand maintain. Additionally this also allows processing of usage records from services that do not support a usersession concept, as correlation is only performed on services that include session information. Usage records fromservices that do not include session information are pushed as separate IPDR Documents to the Rating Bureau Service.

Storing and Streaming XML dataIn the Q3ADE IPDR Store, multiple information types potentially need to be handled. Currently the IPDR Storehandles SOAP requests and BER encoded files, but is ready to be configured for retrieving usage information fromnetwork elements or service elements using SNMP, TL1 or CMIP. This extension of course would be done byutilizing the ready-to-use Q3ADE Technology Gateway Components.

Having such a diversity of information sources and formats, the choice of a data storage mechanism has been that ofan ODBC enabled relational database. Upon reception of usage records the XML data is transformed into table rowsin the relational database forming the backend of the Q3ADE IPDR Store.

Formal Information Models and Scripting FunctionalityThe Q3ADE IPDR Store uses a formal information model to describe the usage data to be retrieved from the serviceelements, and the IPDR records to be sent to the rating function. The information model is described in GDMO/ASN.1and compiled into the Q3ADE agent maintaining the Q3ADE IPDR Store.

Any other functionality of the Q3ADE IPDR Store, from XML parsing/generation, to transformation of proprietaryusage records into IPDR records and correlation schemes, is entirely implemented by means of LHP scripting. TheLHP script is specific to the Q3ADE platform and similar to Pearl scripts. The scripting approach used inimplementing the transformation functionality allows rapid adaptation of changes, and allows the IPDR Storefunctionality to be modified and updated while the service is running.

Web Based Management InterfaceBy using the active-service-page like functionality of the LHP scripting, the Q3ADE IPDR Store also includes a web-based management interface. This web front-end allows monitoring of the relational database contents,presentation/tracking of stored and transmitted IPDR records and IPDR Documents, subscriptions, IPDR groups, etc.

Figure 12 IPDR Store Management Interface

5.3 Rating

The Rating Bureau Service (RBS) implements the Service Rating component of the AlbatrOSS architecture. The RBSconsists of two distinct parts, a rating engine and several service specific charging schemes. The rating enginemanages the incoming usage data (supplied by the IPDR Store) and applies it to charging schemes that match theservice provider and service type identifiers contained in the usage data payload. The charging scheme is a simplespreadsheet encapsulation [30] of the rules and tariffs that define how a service is rated. A spreadsheet is made up ofone or more worksheets which in turn are comprised of cells organised into a row and column formation. The cellsthemselves are containers for data and can be assigned optional name references. Complex charging processes can beconstructed using the existing functions of spreadsheet applications. For example the following spreadsheet formulaewhen applied to the cell representing the overall charge ensures that at least the minimum charge is applied to eachservice instance and revenue assurance is guaranteed:

=IF(subTotal<minCharge,minCharge,subTotal)

During the rating process the element data of an incoming IPDR usage record is simply mapped to its correspondingcell in the charging scheme. Only certain elements in a usage record constitute rateable data therefore only a subset ofthe incoming data needs to be represented in a charging scheme. Finally the cells containing the resulting charge forthe service usage are extracted from the spreadsheet and instated as new element data to the usage record.

While its business logic is based on COM/COM+, the RBS offers service usage rating as a web service. At one end theRating offers a push service for gathering unrated IPDR Documents from the Q3ADE IPDR Store. At the other end,the Rating stores the rated IPDR Documents into a native XML database for future processing e.g. billing, fraudmanagement etc.

Applying tariffing schemes to Usage DataThe RBS allows for two possible avenues:

1. A new service requires registration before documents are rated2. Apply tariffing schemes to the available Usage Data

In the first case scenario, the service provider has to formulate its new tariffing scheme. This new tariffing scheme willnow be available to charge occurrences of this service, without any recompilation of the rating engine.In the second case scenario, usage records are extracted from the Accounting Repository and rated as explained inFigure 7. This process involves applying the tariffing scheme relevant to the service type to generate charge andsettlement amounts to be recorded into a charge element (CE) section of the IPDR Document. Basically a rated IPDRdocument comprises an unrated one with the addition of a charge element.

Storage of rated IPDR DocumentsThe storage of rated IPDR Documents is the last step in the rating process. It involves storing the final IPDRDocuments onto a collection in the Xindice database [31] for billing. The flexibility of the rating allows its integrationin any OSS, IPDR documents could be returned upon rating, or sent to any analysis or reporting systems.

5.4 Flexible customisable Billing

The flexible, customisable billing components implement the Service Billing function of the AlbatrOSS architecture.The Billing Engine produces a detailed record of billable usage activity for a particular customer in a convenientcustomer invoice.Figure 13 shows that the Billing is a customer-facing service capable of, from a set of user-defined parameters,querying and collecting relevant IPDR Documents from the Accounting Repository. Those IPDR Documents areretrieved to the Billing Engine and then transformed using XSLT into an invoice/bill in the required format.

Figure 13 Bill production process

In the first phase of the AlbatrOSS project, the Billing service generated invoice bills based on the last usage recordsstored in the accounting repository (get last charge in Figure 14). Each service produced a clear table representing thecustomer’s aggregated network and service consumption.

Native XMLDatabase

IPDRDocuments

query

response

Biling Engine

HTML

XSLTs

Bill in requiredformat

In the second phase of the AlbatrOSS project, a different approach was adopted. Customer parameters such as servicetype and date period were used to query for the relevant record (user defined charge in Figure 14). Also, due to newrequirements both customer bills and 3PSP settlement invoice can now be produced.

The Billing is a customer-facing service implemented as a web service with extensions for Formatting ObjectProcessing [32]. At one end, the Billing gathers the relevant rated IPDR Documents based on user constraints(particular service, date period, last charge, etc) from Xindice native XML database using HTTP over XML-RPC andthe XML:DB standard API. At the other end, the user is presented with an invoice bill in HTML, PDF, RTF, etc thatcould be sent via email for future records.

Billing user interfaceIn the AlbatrOSS project the Billing is customer-facing service. As such the user should have access to an interface inorder to specify billing parameters. Figure 14 below is the Billing web front end that allows the user to define hisparticular requirements (format, service type, dates) for a bill.

Figure 14 Billing user interface

Querying the Accounting RepositoryBased on the user actions, two possible events can occur:

Get the last charges: this event fires a query to retrieve the user’s last usage records stored in the AccountingRepository.

Get the user defined charges: this event queries the Accounting Repository based on the service selectedand/or the date period.

The query is generated in XPath and has the following general structure://ipd:IPDR[ipd:userID ='" + userID +"']The result of such a query is stored in an XML object that will be transformed to produce the bill.

Bill generationFor Bill generation, the transformation function uses the IPDR structure as a basis to generate the invoice bill. Theresulting collection of records is then transformed using standard XSL transformations [22] into the required format(e.g. HTML or PDF) and presented to the user in the form of an invoice detailing service usage.A bill extract example can be found in Figure 8.

6 Conclusions

In an effort to deliver on the promise of exciting NG services, communications providers are discovering that theyneed to establish intimate working relationships. Collective service arrangements provide a means for achieving inter-provider relationships that lead to increasing growth in partnerships, alliances and collaborations amongstcommunications providers. To survive in this rapidly expanding and changing services market, communicationsproviders need to develop new and dynamic accounting solutions. In the current environment, the exchange ofaccounting management information retains significant manual elements or involves proprietary, low-levelinteractions. The emerging services market demands the definition of common accounting specifications andagreements to allow providers, their customers, and their suppliers to work together more effectively than is currentlypossible.

Through the accounting work in the AlbatrOSS project, the relevant partners have designed and implemented aninnovative accounting architecture and have demonstrated its use through a series of trial demonstrations. Thenetworks and services charged for include WLAN, GPRS, UMTS, SmartHome, Location Based Restaurant Services,Location Based Flight Booking services etc. The solution developed has been validated for billing for composedservices through aggregated charging in a federated accounting environment, and represents a critical part of theoverall AlbatrOSS 3G OSS Architecture.

The major challenges spawning from the new communications environment were met through the delivery of flexible,standards compliant solutions. Common information models and new technologies including webservices make itpossible to build accounting and billing solutions to cater for new networks and services, while supporting roaming,aggregation, composition and new ways of charging. It can be concluded from this work that OSSs will need to evolvefrom in-house, proprietary, rigid solutions to more open bureau service type solutions. That is, the OSS solutions willreside on platforms outside the operator/provider domains and hence will be reusable by multiple operators, makingthe whole process far more cost efficient.

The accounting and billing work achieved in the AlbatrOSS project will be carried forward into new funded researchprojects including: DAIDALOS (www.ist-daidalos.org), DBE (http://www.nachira.net/de/refs/ref_dbe.html) andOPIUM (www.ist-opium.org).

7 References

[1] Third Generation Partnership Project, http://www.3gpp.org/[2] European Telecommunications Standards Institute, http://www.etsi.org/[3] Parlay Group, http://www.parlay.org/[4] Open Service Access (OSA); Application Programming Interface (API); Part 12: Charging SCF, ETSI ES 202 915-12 V1.1.1, 2002-11.[5] Aboba, B., Arkko, J., Harrington, D., Introduction to Accounting Management, IETF RFC 2975, October 2000.[6] International Telecommunications Union, http://www.itu.int/[7] Specification of TMN applications at the Q3 interface: Call detail recording, ITU-T Recommendation Q.825,1998.[8] Network Data Management – Usage (NDM-U) For IP-Based Service, Version 3.1.1, October 9 2002, IPDROrganisation (www.ipdr.org)[9] World Wide Web Consortium, http://www.w3c.org/[10] Organisation for the Advancement of Structured Information Systems, http://www.oasis-open.org/[11] W3C eXtensible Markup Language, http://www.w3.org/XML/[12] W3C Web Services Activity, http://www.w3.org/2002/ws/[13] OASIS Business Transaction Technical Committee, http://www.oasis-open.org/committees/business-transactions/[14] OSS through Java Initiative, http://java.sun.com/products/oss/ [15] Java Community Process, http://www.jcp.org/[16] names, NGOSS Principles used in AlbatrOSS, AlbatrOSS White Paper, January 2004, http://www.ist-albatross.org/Papers.php[17] Shared Information/Data Model (SID). Concepts, Principles, and Domains, GB922 Member Evaluation Version2.0, TeleManagement Forum, Morristown, New Jersey, December 2002[18] Most recent version of the Master IPDR Schema Document available at:http://www.ipdr.org/namespaces/ipdr/IPDRDoc3.1.xsd[19] XML Schema 1.0, W3C, May 2001, http://www.w3c.org/XML/Schema[20] Fielding R. [et al.] (1999), Hypertext Transfer Protocol -- HTTP/1.1, Internet Engineering Task Force, [availablefrom http://www.ietf.org/rfc/rfc2616.txt, last accessed 12th August 2003][21] Rosenborg J. [et al.] (2002), SIP: Session Initiation Protocol, Internet Engineering Task Force, [available fromhttp://www.ietf.org/rfc/rfc3261.txt, last accessed 6th August 2003][22] Extensible Stylesheet Language Transformations (XSLT) 1.0, W3C, November 1999, http://www.w3.org/TR/xslt[23] Bhushan B., Tschichholz., Leray E., Donnelly W., “Federated Accounting: Service Charging and Billing in aBusiness-to-Business Environment”, proceedings of IFIP/IEEE Integrated Management Symposium, Seattle, USA,May 2001.[24] Technical Specification Group Services and System Aspects; Service requirements for the IP Multimedia CoreNetwork Subsystem (Stage 1) (Release 5), 3GPP TS 22.228 version 5.6.0 (2002-06).[25] Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS);Stage 2 (Release 5), 3GPP TS 23.228 version 5.9.0 (2003-06).[26] Technical Specification Group Services and System Aspects; Charging implications of IMS architecture (Release5), 3GPP TR 23.815 version 5.0.0 (2002-03).[27] System Version 1 ready for Trial , IST-2001-34780 AlbatrOSS Project Deliverable 5, January 2003. [28] Requirements, Business Model and Scenarios definition, IST-2001-34780 AlbatrOSS Project Deliverable 2, July2002.[29] Ryan C., Brazil J., de Leastar E., Cloney J., A Rating Bureau Service for Next Generation IP Services,proceedings of IT&T Tecnet Conference, October 2002, Waterford, Ireland.[30] Ryan C., Brazil J., de Leastar E., Ó Foghlú M., Workbook approach to Algorithm Design and ServiceAccounting in a Component Oriented Environment, proceedings of IEEE Workshop on IP Operations andManagement, October 2002, Dallas, Texas.

[31] Apache Xindice Project, http://xml.apache.org/xindice/[32] Apache Project Formatting Objects Processor, http://xml.apache.org/fop/