Service oriented infrastructure (Part 2)
Systems and infrastructure for billing next-generation corporate ICT services
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
However, this is just one simple example. As discussed in
, 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
- 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.
2. Trends in the billing systems marketplace
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
3. Standards, interfaces and interoperability
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  would merge into
3GPP  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)
 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.
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
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 ). For example, operators can place
post-paid subscribers on credit control by using online charging
mechanisms (as per 3GPP specification TS23.125 ).
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.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  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 , which
provides a set of web services Application Programming
Interfaces (APIs) for the telephone network. Parlay X web
services are defined jointly by ETSI , 3GPP and the Parlay
Group . 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 |
3GPP document TS 29.199-6 
|Part 7: Account Management||Account querying, direct recharging and recharging through vouchers|
|ETSI document ES 202 504-7 |
3GPP Document TS 29.199-7 
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.
4. An example billing environment
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 , 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  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.
5. What further systems support is needed?
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
- 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
- enable real-time management of quotas and caps.
- allow service credits, rebates and discounts to be
triggered automatically by Service Level Agreement
- support enhanced billing for videoconferencing services
- support very large contracts
- support contracts involving multiple regions and/or
- support the simultaneous delivery of services to multiple
- 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 , videoconferencing
over MPLS and telepresence . 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
6. SLA management
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  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 reality1.
1 For a more a more detailed coverage of management of SLAs, refer to .
7. BT's ICT billing proof-of-concept demonstration
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
- 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
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 ).
ICT-ADQ builds on an established BT consumer
broadband ADQ service (described in BT suppliers'
information notes 427 and 450 ). 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 .)
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 .
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
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
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.
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
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) 
8. Billing as a statement of value
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.
- 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
- ETSI TISPAN, http://www.etsi.org/WebSite/AboutETSI/structure/
- 3GPP: Third Generation Partnership Project, http://www.3gpp.org/ Top
- The TeleManagement Forum, http://www.tmforum.org/ Top
- 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
- 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
- The Internet Engineering Task Force (IETF), 'Diameter base protocol',
- The Parlay Group, 'Parlay X web services', http://www.parlay.org/ Top
- The European Telecommunications Standards Institute (ETSI),
- ETSI, 'Open Service Access (OSA); Parlay X web services; part 6:
payment', Document ES 202 504-6, http://portal.etsi.org/Docbox/
- 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)',
- ETSI, 'Open Service Access (OSA); Parlay X web services; part 7:
account management (Parlay X 3)', Document ES 202 504-7,
- Glass WG, 'BT's Matrix architecture', BT Technology Journal, vol.26,
no.1, September 2008, pp.86-96 Top
- BT Billing Analyst, http://www.btbatutorial.com/ Top
- BT Conferencing, 'Video services', http://www.conferencing.bt.com/
- Digital Fuel, http://www.digitalfuel.com/ Top
- 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
- BT, 'Suppliers' Information Notes', http://www.sinet.bt.com/ Top
- 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.