Systems and infrastructure for billing next-generation corporate ICT services

Service oriented infrastructure (Part 2)   » Log in

Systems and infrastructure for billing next-generation corporate ICT services

J McDonald

E-mail a friend

E-mail the author

Thank you!

The next generation of information and communications technology services places new demands on service provider billing systems. While service providers typically bill business customers at the end of a period (usually monthly), the more dynamic nature of services associated with service-oriented infrastructures require a real-time approach to billing functions such as mediation and charge rating. Moreover, these functions need to operate in real time across ecosystems of customers and service providers - that is, across both regional and business boundaries. This paper examines the emerging challenges in this area of billing and outlines developments underway to address them. The prototypes BT has developed to explore how its own billing systems could be enhanced to accommodate service-oriented infrastructures are described.

As organisations focus ever more strongly on their core business competencies, it is becoming commonplace for them to outsource the supply and operation of the IT systems and network infrastructure they need to service providers such as BT. Contracts can involve the provision of complex combinations of applications and network services at widely-dispersed locations, but nonetheless the bills that are presented must be clear, accurate and complete. Now, with the advent of serviceoriented infrastructures (SOIs), the seemingly-straightforward task of charging for services is becoming even more challenging and complex. Such infrastructures are far more flexible than their predecessors. Customers can vary the range and 'volume' of the services they use on demand, relying on their service provider to keep end-to-end performance within contracted levels. As a result, the charging functions associated with applications and services must track both demand and performance as well as be able to account for situations in which components of services are bought in from an ecosystem of other service providers.

Consider, for example, an international videoconferencing service. A user in Buenos Aires wants to set up a videoconference at 14:00 hours GMT with participants in New York, London and Paris. Having determined that the request can be accepted, the service provider must configure its systems and network to provide connections between the participants of a quality sufficient to enable them to have a productive meeting. Several components may be involved in the provision of the service, including a web server, a scheduling system, a video server, a wide-area IP or MPLS network and local networks at the four locations. In addition, the service provider must be able to bill for the service. Not only must the cost of providing the service be calculated and presented clearly as a component of the customer's overall bill, it may be necessary for an estimate to be provided at the time the service was booked and for this to be checked against either the organisation's or end user's approval policy. The charge for the service may be a 'make or break' factor in the user's decision as to whether or not to proceed with the conference as planned or to consider an alternative such as a lower-quality service.

However, this is just one simple example. As discussed in [1], BT's SOI will be able to deliver a wide range of services on demand to meet the evolving needs of corporate customers. The charging models that could be applied to such services are similarly varied, and could include:

- a base contract for the provision of a standard set of services or resource levels at an associated monthly rental;
- the base contract plus an amount to cover an agreed quota of additional usage;
- the base contract plus premium charges for additional usage subject to an upper limit or cap set by the customer to limit the amount it spends;
- the base contract plus premium charges with no cap;
- no base contract and 100 per cent usage-based charging; and
- variations or combinations of the above.

Such models are familiar today in the consumer domain - for example, in connection with mobile phone services. As SOIs are deployed, we expect them to be extended across a wide range of business products and services and multiple types of service provider.

To meet these new requirements, service providers like BT whose billing systems are based on commercial software products must select suppliers who are flexible and prepared to support their increasingly complex requirements. Within the telecoms billing industry, convergence has been happening on a grand scale. Mergers and consolidation have created a small number of highly-integrated suppliers that can support the entire billing process, from mediation through to billing. For example, CSG and Kenan have now merged to form Comverse, and Oracle has bought both MetaSolv and Portal to add both service fulfilment and billing capabilities to its product portfolio. At the time of writing, such companies were still in the process of integrating their products portfolios. Billing systems companies that previously defined themselves as either pre-pay or post-pay were disappearing and new converged companies were being formed that offer an entire range of billing capabilities. The general direction in the industry is towards converged platforms, including both online and offline billing capabilities as described in section 3.

Thus far, industry consolidation has resulted in there being between 10 and 15 key suppliers, most of which now offer products that meet both pre- and post-pay requirements. Their software generally runs on standard server platforms - hardware from Sun or HP, for example, running either the UNIX or Linux operating system. However, a few manufacture their own server blades, largely in order to meet specific environmental constraints. Support for IP Multimedia Subsystem (IMS) standards is another key theme, as discussed in the following section. BT's strategic supplier for mediation is among those that are closely following the 3rd Generation Partnership Project (3GPP) approach.

A major concern for service providers like BT is to be able to get their new products and services to market as quickly as possible. In the past, billing systems hindered this. Significant amounts of time and effort were required to configure them to support each new product or service.

The development of standards has helped bring timescales down. However, as is common within the telecoms industry, the biggest problem has not necessarily been a lack of standards, but the need to choose from a plethora of competing - but often incomplete - standards. Fortunately, both standards-setting organisations and their standards have begun to converge. Early in 2007, for instance, it was announced that parts of ETSI TISPAN [2] would merge into 3GPP [3] to create a single body to develop the standards for IMS. This helps to ensure that IMS is defined once by one set of standards that includes charging mechanisms. Later in the same year, the merger of the Global Billing Association (GBA), IPDR (IP Detail Record organisation) and TMF (TeleManagement Forum) [4] was announced, bringing responsibility for the development and promotion of interoperability standards for billing systems under a single umbrella organisation. As a result, the development of billing standards now involves only two organisations: the 3GPP and TMF.

3.1 The GBA Map
Figure 1 shows the 'GBA Map' - a scheme developed to show the overall framework for billing systems now being developed within the wider TeleManagement Forum enhanced Telecom Operations Map (eTOM) initiative. The map shows how billing systems can be integrated with the rest of a service provider's systems stack. Component 4 of the architecture - the online charging module - is the key to the delivery of flexible tailored ICT services. Its parts are described in more detail below. A software vendor's online charging system product suite will provide most, if not all, the capabilities shown.

3.1.1 Service delivery
The delivery of a service to the end user can be influenced by the online charging system. For example, a particular service may only be delivered to the end user if he or she has not yet reached a pre-specified credit limit. Alternatively, the cost to the end user may vary depending how much he or she uses the service.

3.1.2 Mediation
This component provides the capability to convert network usage and charging data from multiple supplier-specific formats into one common format, suitable for interpretation by the back-end billing system (component 5). The data required would typically be collected from a range of different types of network equipment supplied by different vendors. BT's UK public voice network uses Marconi and Ericsson voice switches, for example, while in its 21st Century Network (21CN) , voice call records are generated by call server equipment provided by Ericsson among other suppliers. For ICT services, the source of charging data could also include policy management systems and specific applications. A process known as 'enrichment' may also be implemented at the mediation stage, where additional static 'pre-rating' information from various databases is applied to the call records before they are supplied to billing systems. Real-time (online) mediation is carried out at the time of service delivery, while standard (offline) mediation is carried out at some time afterwards.

        Figure 1. GBA Map, version 2

3.1.3 Rating
This component assigns monetary values to usage data, using predefined unit costs to determine the total costs to users. Real-time (online) rating must be carried out concurrently with service delivery, so the rates calculated can be used to drive end user behaviour. Standard (offline) rating is carried out at some time after service delivery.

3.1.4 Balance management
As part of the suite of online charging capabilities, balance management provides the capability to track usage of particular applications and can also allow usage limits to be set - for example, where users have chosen pre-pay services and are required to remain within their credit limits.

3.2 3GPP Policy Charging Control architecture The Policy Charging Control (PCC) architecture has been defined by 3GPP to support flow-based charging as well as provide policy control over 3GPP IP Connectivity Access Networks (IP-CAN) such as General Packet Radio Service (GPRS) and Interworked Wireless Local-Area Networks (IWLANs). Various charging models are supported, including:

- volume-based charging;
- time-based charging;
- volume- and time-based charging;
- event-based charging; and
- no charging.

The body also defines four domains in which charging mechanisms are applied:

- circuit switched;
- packet switched;
- Application Services (AS); and
- IP Multimedia Services (IMS).

In 3GPP, charging mechanisms are also split into online and offline charging. Offline charging has no impact on the real-time delivery of a service, and is carried out after the service has been delivered, whereas online services can be rated in real-time and and when customers request them. Online charging therefore permits the decision as to whether to provide a service to be influenced by the customer's account balance, whereas offline charging does not.

It is important to note that online and offline are not the same as pre-paid and post-paid (as described in 3GPP specification TS 32.240 [5]). For example, operators can place post-paid subscribers on credit control by using online charging mechanisms (as per 3GPP specification TS23.125 [6]). As shown in figure 2, the key functional components within the 3GPP PCC architecture are:

- the Policy and Charging Rules Function (PCRF); and
- the Online Charging System (OCS).

The role of the PCRF is to manage the various policies that apply to each user's service and any charging rules that apply. For example, a PCRF may be aware both which charging model should be applied and whether a service is chargeable or not. A PCRF can be pre-provisioned with specific rules, or can perform a look-up as and when required.

        Figure 2. The 3GPP PCC architecture

A simple example of a service that could be offered using the architecture of figure 3 might be a video calling service that allows a customer to purchase up to �50 worth of credit in advance – credit that will be stored within the account management function until the service is used. Charging event messages are sent to the Online Charging Function (OCF) over the Ro or Gy interface. The OCF then sends a message via the Re interface to the account management function to determine the remaining balance on the account. Assuming there is sufficient credit, the cost of the service will be calculated by consulting the rating function via the Re interface. Once the call is complete, records will be sent periodically from the OCF to the billing domain via the Bo interface. A video call might use the session charging function, where both start and end times are needed to calculate the overall cost, whereas a one-off event might use the event charging function.

        Figure 3. The 3GPP online charging system

In most, if not all, cases, the 3GPP approach will need to be tailored to the business environment in which the service provider is operating. For example, BT operates its access, wholesale and retail divisions as separate businesses, which may make implementation of the 3GPP architecture a more challenging proposition. Because 3GPP was originally developed specifically for consumer mobile services, its scope needs to be increased to encompass multi-site converged services provided to corporate customers. Further standards development is therefore required to fully support the needs of corporate ICT customers.

3.3 Interfaces
3.3.1 The Diameter protocol
There is broad agreement within the industry that a version of the Diameter AAA (Authentication, Authorisation and Accounting) protocol, as described in IETF RFC3588 [7] will be used to provide an interface for supporting real-time requirements between network equipment and online charging systems. This is most likely to be based around the work done not only in IETF but also in 3GPP, which has defined the specific Diameter 'applications' that will be required. Diameter will be used where an immediate response is required to an application charging request, so that the charging information can be supplied from the OCS without delay. Specific Diameter applications are used for interfaces Rx, Gx and Gy in figure 2, and Gy, Ro, Rc and Re in figure 3. However, note that Bo is implemented using a flat file and file transfer methods, as this does not need to be transferred in real-time and that the internal interfaces within a vendor's OCS product may not necessarily support the Rc and Re specifications, since these might not be exposed externally.

3.3.2 Web services
For interactions between a user and service provider - for example, checking the account balance or recent charges - a web services approach may be used based on the Simple Object Access Protocol (SOAP) and Web Service Modelling Language (WSML) techniques. One such technique is Parlay X [8], which provides a set of web services Application Programming Interfaces (APIs) for the telephone network. Parlay X web services are defined jointly by ETSI [9], 3GPP and the Parlay Group [8]. The Parlay X 3.0 specifications are divided into 20 parts, of which those relevant to billing are shown in table 1.

Parlay X 3.0 specification	Available functionality
Part 6: Payment	Payment reservations, pre-paid payments, and post-paid payments
	ETSI document ES 202 504-6 [10] 3GPP document TS 29.199-6 [11]
Part 7: Account Management	Account querying, direct recharging and recharging through vouchers
	ETSI document ES 202 504-7 [12] 3GPP Document TS 29.199-7 [11]

Table 1. Parlay X Specifications relevant to billing

Each document specifies a situation in which a user interacts with a self-service web portal or an interactive voice response system. As an example, the account management API specifies various operations such as 'getBalance', which comprises the input message 'getBalanceRequest' specifying the user's account and authorisation credentials and the output message 'getBalanceResponse', which includes the set of balance records with balance type and amount. The payment API specifies operations including 'chargeAmount' (which directly charges the end user) and 'refundAmount' (which refunds an amount to the user's account). Whilst these APIs provide only relatively basic capabilities suitable for consumer services (such as a pre-pay mobile service), extensions to these methods could be envisaged to include the necessary additional features to support corporate ICT services.

Within BT, a division called BT Global Services supplies products and services to larger corporate customers worldwide. This division is progressively deploying a modern strategic billing system to replace the systems and methods it has used before. Often, these involved a mixture of manual and automated activity. In the worst case, line items were collated manually in spreadsheets, after which custom scripts were used to upload the data into one or other of the organisation's billing systems. However, higher levels of automation are now being introduced. For example, socalled 'inventory based billing' allows the static items that appear month-by-month on bills to be populated directly from BT Global Services' inventory management systems, and billing data provided by subcontractors can be fed directly into billing databases via translation tools. By reducing the amounts of manual work involved, such initiatives have improved the accuracy of the organisation's bills, enhanced customer satisfaction and reduced the numbers of billing queries received.

A further legacy of running a wide range of different products and services in different regions - including some that originated within BT and others acquired through mergers and acquisitions - was a wide range of separate billing systems. Work in progress will replace an original base of around 50 billing or billing-related systems with a much smaller number of strategic systems. Each system that remains will be built from a common set of standards-based software and hardware components, and both products and services are being defined in ways that minimise the amount of bespoke configuration required. The focus on rationalisation and standardisation will make it more straightforward to develop billing systems to support new converged ICT requirements. And because less time and effort will be expended developing and maintaining multiple billing systems, more can be focussed on the one or two key systems that remain.

        Figure 4. BT's Matrix architecture

But BT's focus on streamlining billing systems isn't just about driving costs down and customer satisfaction up. It is also an essential precursor to the introduction of a much wider and much more flexible range of products and services based on BT's SOI. For such an expansion of BT Global Services' portfolio to be an economic possibility, a common billing platform that holds all the rating and tariffing tables and algorithms required is an absolute essential. Within BT, systems developers are guided by an architecture called the Matrix [13], which is illustrated in figure 4. The architecture's billing and payments platform specifies which vendor products will be used to support which specific billing requirements. At the time of writing, BT has relationships with Openet Telecom (Mediation and ActiveCharge), Convergys (Infinys IRB2.2), Oracle (BRM and Siebel eBilling) and Amdocs (bill formatting software). Each new product or service development is required use the strategic platform created from these components.

Figure 5 shows two ways in which the selected BT billing and payments systems can be configured to align with the 3GPP architecture. The second, which allows rating functionality to be contained within the bill production system, is preferred. In addition to the core Matrix systems, a software tool called BT Billing Analyst [14] is offered to enterprise customers to allow them to view specific breakdowns of their charges on a product and cost centre basis. This tool is described in section 7.4.

To accommodate the requirements of a range of new ondemand ICT services, a mixture of real-time and non-real-time billing techniques is needed. To allow higher value services to be offered to enterprise customers on an on-demand basis, an online charging capability is needed to enable balance management within a basic customer contract. This would give customers the option to pay on whatever basis suits them - for example, chosen from the options listed in section 1.
To enable such choice, BT Global Services' new billing systems will:

- facilitate retariffing of existing products and services
- allow multiple BT products to be handled within a single contract, using automated tariffing mechanisms to combine multiple products
- produce near-real-time (pre-invoice) breakdowns of charges by customer site or other cost centre, where each may use a range of BT products and services
- enable real-time account management
- enable real-time rating and charging for temporary services upgrade
- enable real-time management of quotas and caps.
- allow service credits, rebates and discounts to be triggered automatically by Service Level Agreement (SLA) breaches
- support enhanced billing for videoconferencing services
- support very large contracts
- support contracts involving multiple regions and/or currencies
- support the simultaneous delivery of services to multiple countries
- allow billing for any external supplier capabilities bundled with BT services
- support 'chargeback', which includes sub-charging to other suppliers and capabilities to allow the customer to internally sub-charge to different parts of their own organisation.

Such features will support both the bundling of ranges of existing BT products (such as corporate VoIP and audioconferencing) and new developments such as applicationlevel SLAs, total ICT orchestration [1], videoconferencing over MPLS and telepresence [15]. In addition, they will allow BT to offer billing as a service delivered by its SOI. Here, BT would accept billing records from one or more third parties, compiling them into a single statement of account.

        Figure 5. Two options for the use of BT's strategic 'Matrix' systems within a 3GPP architectural framework

A new type of IT system known as a service level agreement manager has begun to emerge that monitors a service provider's performance against SLAs. Examples of such systems are offered by companies including DigitalFuel and Oblicore. For SLAs to be meaningful, they must include financial incentives for suppliers to comply. Amounts may be taken off bills if service falls short of agreed levels or added if 'stretch' performance levels are achieved.

To make this possible, the systems that police SLAs must be integrated with suppliers' billing platforms. This raises the question of what the role of the SLA manager should be relative to that of the mediation platform. A clear split of responsibility between these systems is essential and, within BT's Matrix architecture, this has been achieved by establishing the clear principle that actual monetary values are handled only within the billing and payments platform. The SLA manager is therefore restricted to handling unrated events and determining the levels of severity of SLA breach that are subsequently presented to the mediation solution for rating. These principles are developed further in the scenario described in the following section and in figure 8, which shows how an SLA manager might be deployed. Traditionally, the mediation platform carries out standard processing operations on its input and enrichment data, and has no knowledge of any specific SLAs that must be met. As a result, the financial analysis and reporting aspects of SLA monitoring may be more difficult to achieve. However, an alternative approach exists in which the costs related to particular contracts are monitored within the SLA management product suite. BT uses DigitalFuel's ServiceFlow SLM (Service Level Management) product to achieve this, for example. An add-on product known as ServiceFlow Finance [16] automatically generates the billing and chargeback statements both service providers and customers need to review the details behind each charge. The benefits of using such a tool are that it allows spending to be compared to budget, which in turn allows users to identify and resolve situations in which the use of services has been unusually high. It also allows projections to be based on current trends, so that corrective action can be taken at the earliest opportunity. By pinpointing the root-cause of any budget variance by service offering, business unit, geography or department, the system makes it easy for consumption and spending behaviour to be adjusted in a targeted fashion.

In the longer term, the conflicts between the various systems' roles may be resolved by combining policy management, SLA management and mediation functions within the same component, though this is probably a long way from becoming reality¹.

---

¹ For a more a more detailed coverage of management of SLAs, refer to [1].

BT has developed a proof-of-concept platform which is used to address and demonstrate solutions to the range of emerging SOI billing requirements. The platform is based on an integration of BT's strategic billing and payments platforms. By way of example, we now examine four of the scenarios implemented by the demonstration system:

- real-time provisioning of network resources – policy manager driven
- application-level SLAs – service credits – SLA manager driven (not real-time)
- total ICT orchestration – dynamic ICT (allocation of virtualised network and IT resources)
- chargeback within the customers own organisations.

7.1 Real-time provisioning of network resources
The first scenario is based on ICT Application-Driven Quality of Service (ICT-ADQ), a prototype service that adapts the bandwidth and Quality of Service (QoS) marking of provider edge routers within an MPLS network in real-time as customers request changes to the bandwidth available to them or the QoS configuration of their network (e.g., as described in [17]).

ICT-ADQ builds on an established BT consumer broadband ADQ service (described in BT suppliers' information notes 427 and 450 [18]). Its charging solution is designed to encourage responsible use of BT's network resources and allow the company to recoup the costs of providing its resources.

The whole system is driven from a portal through which customers can request permanent or temporary upgrades to the bandwidth or class of service parameters of their IP-VPN. Requests from the portal are initially directed to a policy manager, which checks which actions can be requested by whom, at what time, for what service and on which routers. Once approved by the policy manager, a price for the proposed configuration change (also known as an 'advice of charge') can be obtained. This is calculated by Openet ActiveCharge using an Openet online rating component called ActiveRate, and then returned to the user via the policy manager and portal. The policy manager's behaviour may vary depending on the level of charge. If users decide they wish to go ahead with the change based on the costs quoted, they can action them by pressing a 'submit' button in the portal window. The policy manager will then go ahead and reconfigure the provider edge routers as appropriate, and request that the appropriate charge be raised within ActiveCharge. If for any reason the router reconfiguration is not implemented by the policy manager, no charge is raised. In the demonstration, the interfaces between the policy manager and ActiveCharge are implemented using XML-RPC methods. In a production system, however, Diameter (for real-time requests) and web services would be used as discussed in section 3.

The backend billing process is provided by an Infinys Rating and Billing system, which produces the customer's monthly invoices. The charges are fed from ActiveCharge to Infinys on a daily update basis, while an online portal gives an up-to-the-minute view of the real-time charges. The full architecture is shown in figure 6, which also shows how customers can check previously raised on-demand charges from using the portal's 'get charges' function.

        Figure 6. Online charging for real-time provisioning of network resources

        Figure 7. An advanced user portal screen that allows the scheduling of temporary changes to network configuration

A further version of this demonstration allows users to specify time periods during which temporary upgrades are required after which the network configuration should revert to its previous state. In this version, multiple network links could be reconfigured simultaneously, changes could be driven by a particular application (e.g., a videoconference) and charging could be varied to reflect the application that was requesting the change.

Figure 7 shows the user portal screen developed for this more advanced version of the demonstration. A further enhancement is envisaged that would hide the details on the portal from the end user, but instead allow the videoconference scheduling system (or other application) to interact directly with the policy manager to request the appropriate network resources.

7.2 Application-level SLA - service credits
The second scenario shows how a new, more comprehensive type of SLA, which we call an application-level SLA, can be offered that guarantees the end-to-end performance of a particular application rather than of the network and computing infrastructure over which it runs. The service shown can be considered to be an enhancement of BT's existing Application Assured Infrastructure (AAI) and Application Optimisation Service (AOS) products. Software monitors the application's performance, calculating whether and, if so, for how long performance fell below the target specified in the SLA. (A moredetailed description of application-level SLAs is included in [13].) In the demonstration, application-level SLAs are provided as a value-added option. Figure 8 illustrates how the various components involved in the demonstration are connected. Application performance is monitored using Ipanema. The Openet and Infinys platforms are used to allocate service credits to customers as and when agreed performance thresholds are breached. Openet collects the events from an application-level SLA component, correlating and formatting the information for onward supply to the Infinys platform. Because there is no requirement for real-time information to be provided to customers, the Openet Fusionworks Mediation product could be used. However, we chose to reuse the higher-performance Openet ActiveCharge platform in our demonstration.

In the demonstration, performance remains outside specification for one hour. Events are generated, but the Openet platform does not need to respond immediately. It simply collects the event data and passes it to Infinys in the form of a periodic (say, daily) update. Figure 9 illustrates the invoice Infinys might generate as a result. It records the monthly rental charges for the basic MPLS service and the value-added application-level SLA service. A qualifying fault event has been logged, so a rebate has been applied. The mock-up invoice shows the discount applied to the MPLS service.

        Figure 8. Components of the application-level SLA demonstration

7.3 Total ICT orchestration
The third demonstration scenario centres on BT's ability to offer packages of virtualised network and IT resources to corporate clients on demand. It builds on the first two demonstrations, showing both real-time provisioning of network resources and the application of service credits in cases in which SLAs aren't met. In addition, the demonstration shows how virtualised computing and storage resources can be added - and charged for - in real-time as customer needs change. A full description of the service is provided in [1]. Figure 10 shows the overall service concept and how charging works at different layers in the model. Charges for the overall service are based on per-component charges for each virtualised component offered to the customer. Quotas or charging caps can be implemented to allow customers to control the amounts they spend on particular applications, such as SAP and Oracle. Finally, SLAs are offered that trigger compensatory payments should service levels drop below agreed thresholds.

Figure 11 shows a typical message flow when the service is activated. Checks are made on the customer's account to see how much credit remains and real-time quotations are supplied as appropriate. Charges are raised only once the required virtualised resources are in place.

        Figure 9. An example invoice

        Figure 10. Charging layers in the 'Total ICT Orchestration' demonstration

        Figure 11. Message flow for a typical service request

In this scenario, the Openet ActiveCharge and Infinys platforms are used again, with Openet handling the collection of all real-time events from the network and Infinys handling the back-end billing processes, including invoice generation.
The decision management system plays a similar role to the policy manager in scenario 1, but expands its responsibility to manage IT (storage and compute) resources as well as network elements. The policy manager and decision management system implement aspects of both the 3GPP PCRF and AF (Application Function). While they are most closely aligned with the PCRF, the PCRF does not have a direct link with the OCS (implemented by ActiveCharge). The mapping between these functions and the 3GPP architecture is therefore close but indirect. To support such services, a modification of the 3GPP PCC architecture is required to support an interface between PCRF and OCS. Such an enhancement is the subject of a pending BT patent application.

7.4 Chargeback
A future scenario envisages a situation where enterprise customers can receive breakdowns of the charges incurred by different parts of their organisational structures. This allows them to 'chargeback' services to cost centres within their businesses.

If it is to be provided, chargeback should ideally work across the full range of services that an SOI delivers and across the full range of service providers. Currently, however, BT only offers the service in selected areas of its portfolio, through products including:

- BT Billing Analyst;
- Siebel eBilling from Oracle; and
- ServiceFlow Finance from DigitalFuel.

BT business customers that use BT OneBillPlus can register for BT Billing Analyst, for example. This powerful PCbased program allows customers to explore the billing data they receive by CDROM through BT OneBillPlus.

One of BT Billing Analyst's key features is the capability to monitor spend by cost centre. Customers can specify up to five levels of organisational hierarchy within their OneBill account. Once the framework has been set up, they can view bills by both cost centre and account. BT Billing Analyst allows customers to track trends and budgets, to determine whether their spending is within budget and to compare their latest and previous bills. A growing range of BT products and services is supported.

        Figure 12. BT Billing Analyst screen (Version 2.04) [19]

In our view, bills in the future must be more like statements of the value delivered than statements of cost. The difference is significant, especially where the flexibility of the service offered is one of its key features, as it is for SOI. If additional server resources cannot be provided quickly and flexibly, for example, applications may become overloaded and start to fail, causing the organisations involved to lose business or incur extra costs. Bills for SOI services therefore need to show how service providers have actively supported their customers. Even if the provisioning of extra resources is part of a 'free quota' built into a service contract, bills should show how much those resources would have cost, and therefore how much the customer has saved.

Clarity is vital. Charges should be presented in ways that customers find easy to understand and manipulate - for example, so they can allocate them to internal cost centres. Ideally, information should be available in real time through web sites and so on, so that decisions about future spending can be based on the latest information. The overall aim is to give customers a high degree of control over the services they receive and the amounts they pay.

BT has assembled a range of demonstrators to show how state-of-the-art billing systems can be applied to SOI services. All have been built by integrating best-of-breed commercial software products based around standards being developed by 3GPP and the TMF, adjusted as appropriate to meet the needs of the multi-site corporate customers BT Global Services serves. At the time of writing, for example, 3GPP does not support on-demand rating and charging for multi-sited corporate customer applications that involve both network and IT resources. The demonstrations have helped us identify SOI's billing automation requirements. Not all can be met using current software billing products - even those that are state of the art - but most can.

The author acknowledges the role played by Openet and Convergys in providing the applications to support BT's demonstration ICT billing platform. Maria Cuevas, Clive Rich and John Wittgreffe, all of whom work for BT, are thanked for information on the 3GPP PCC architecture, on IRB2.2 and RTRCC, and for overall project direction and guidance with this paper, respectively. Thanks are due to Dave Alley, Russell Barton, Jon Clark, Nigel Edwards and Jonathan Jensen for their reviews of drafts of this paper.

1. Wittgreffe J and Khan K, 'Orchestrating end-to-end network and IT resources according to application level service level agreements', BT Technology Journal, vol.26, no.1, September 2008, pp.46-57 Top
2. ETSI TISPAN, http://www.etsi.org/WebSite/AboutETSI/structure/ technicalbodies.aspx Top  
3. 3GPP: Third Generation Partnership Project, http://www.3gpp.org/ Top  
4. The TeleManagement Forum, http://www.tmforum.org/ Top
5. The Third Generation Partnership Project (3GPP), 'Telecommunication management; charging management; charging architecture and principles', http://www.3gpp.org/ftp/Specs/html-info/32240.htm Top
6. The Third Generation Partnership Project (3GPP), 'Overall high level functionality and architecture impacts of flow based charging; stage 2', http://www.3gpp.org/ftp/Specs/html-info/23125.htm Top
7. The Internet Engineering Task Force (IETF), 'Diameter base protocol', http://www.rfc-editor.org/rfc/rfc3588.txt Top
8. The Parlay Group, 'Parlay X web services', http://www.parlay.org/ Top
9. The European Telecommunications Standards Institute (ETSI), http://www.etsi.org Top
10. ETSI, 'Open Service Access (OSA); Parlay X web services; part 6: payment', Document ES 202 504-6, http://portal.etsi.org/Docbox/ TISPAN/Open/OSA/OMA_Handover/ES%20202%20504%20Parlay% 20X%203.0%20Published/20250406/es_20250406v010101p.pdf Top
11. The Third Generation Partnership Project (3GPP), 'Technical specification group core network and terminals; Open Service Access (OSA); Parlay X web services; part 6: payment (release 7)', http://www.3gpp.org/ftp/specs/archive/29_series/29.199- 06/29199-06-722.zip Top
12. ETSI, 'Open Service Access (OSA); Parlay X web services; part 7: account management (Parlay X 3)', Document ES 202 504-7, http://portal.etsi.org/Docbox/TISPAN/Open/OSA/OMA_Handover/ES %20202%20504%20Parlay%20X%203.0%20Published/20250407/ es_20250407v010101p.pdf Top
13. Glass WG, 'BT's Matrix architecture', BT Technology Journal, vol.26, no.1, September 2008, pp.86-96 Top
14. BT Billing Analyst, http://www.btbatutorial.com/ Top
15. BT Conferencing, 'Video services', http://www.conferencing.bt.com/ product_services/videoservices/index.jsp Top
16. Digital Fuel, http://www.digitalfuel.com/ Top
17. Dames MP, Fisher MA and Wittgreffe JP, 'Use of policy management to achieve flexibility in the delivery of network-centric ICT solutions', BT Technology Journal, vol.23, no.3, July 2005 Top
18. BT, 'Suppliers' Information Notes', http://www.sinet.bt.com/ Top
19. BT, 'BT Billing Analyst', http://www.btbatutorial.com/ Top

James McDonald gained his MEng in electrical and electronic engineering from Loughborough University. He joined BT in 1999, initially to work in its broadband network services and control research group on the development of advanced broadband services. Later, he was involved in the design of bandwidth management systems and the development of a test bed to demonstrate policy management and real-time rating concepts as components of future ICT services. James is now a senior solution designer at BT Design with end-to-end design responsibility for its capacity management solution. He continues to be involved in development of prototypes to demonstrate advanced admission control techniques. James is a Cisco Certified Network Associate and a member of the IET.

« Previous

|

|

Next »