OSB: Object-oriented Scalable Billing
|
Deregulation and advanced technologies have prompted telecommunication companies to compete for market-share with innovative product offerings and rapidly changing price plans and promotions. In this competitive dynamic environment, billing became a sophisticated tool for service providers to communicate with their customers and in turn, billing also grew into a challenging operational task.
OSB supports communication companies, such as mobile and fixed line network operators, service resellers and Internet service providers, in addressing these billing challenges and provide leading edge services to their customers. OSB was designed with the sophisticated requirements of large multi-million subscriber telcos in mind.
OSB is an object oriented CC&B framework, based on modern technologies and industry standards. The OSB class library offers all functionality of a billing system. Modular applications use OSB objects as the building blocks to provide processing logic to user interfaces and business rules. The OSB architecture defines clear interfaces to interact with other systems and allows comprehensive access to all its objects for application programmers.
Recognizing that billing systems today are constantly upgraded to meet ever-changing requirements, one major design goal of OSB was to build a robust architecture that supports frequent incremental upgrades to add new functionality instead of costly and risky “big-bang” migrations. As the OSB library evolves over time, such seamless upgrades will provide bug fixes and features.
The OSB billing engine creates XML invoices in one step. This results in an extremely fast process and reduces the risk for operational errors. XML invoices follow a well-defined schema and can easily be transformed to a variety of formats to publish invoices in several media, from traditional printed statements to emails as well as over the Internet.
Products offered by communication companies bundle different services together into attractive packages. OSB models this product concept: An OSB product consists of product items, such as goods (e.g., a mobile phone), resources (like a telephone number), network services, value added services, tariff systems, charges, promotions, etc. This straightforward concept is key to a host of more intuitive advanced billing functionality.
OSB supports all kinds of communication networks, is ready to rate all usage records and bill any services. The OSB product concept provides a network independent layer that embraces all services. Multiple personalized products can be billed on the same invoice: The combination of these features makes OSB a genuinely convergent billing system.
Telcos are facing major challenges integrating their various OSS and operating in and maintaining the resulting heterogeneous environment. We spent a considerable effort to make sure that the OSB framework supports different strategies to integrate OSB applications with other systems as tightly as required.
Compiling a phone bill was a relatively simple matter when voice was the only service offered by the telecom industry. In recent years, this has changed dramatically: Driven by deregulation and the possibilities offered by advanced technologies, network operators today offer an increasing number of services to their customers. Service providers compete for market-share with creative and differentiated products based on voice and data services and various promotions and incentives. At the same time, service providers also face more and more challenges, some of which are:
As a result, what once was a simple invoice for just a voice telephony service turned into an important tool for service providers to:
Naturally, with the increasing number of requirements, billing became a challenging task, tightly related to other areas:
OSB was developed to help communication companies address these billing challenges. Such companies include mobile and fixed line network operators, service resellers and Internet service providers, including large multi-million subscriber telcos. OSB was designed with large and sophisticated carrier’s performance, scalability, and operability requirements in mind:
The OSB framework bases on object oriented technologies and industry standards: UML, C++, CORBA, XML and an object-relational database. It runs in client-server environments with UNIX servers and any clients that are able to run a web browser.
Technically speaking, OSB is a fully object oriented, modular and scaleable customer care and billing system framework. The basis of OSB is a class library that offers all functionality of a billing system. This class library provides the building blocks for all OSB applications. Its functionality is well documented and OSB has clearly defined interfaces and can therefore easily interact with other systems.
CORBA and XML are the principal industry-standard interfaces through which OSB interacts with the outside world. In addition, carriers and system integrators can exploit the full power of the object oriented OSB object library by directly using OSB objects in their applications.
All OSB applications are based on the OSB object library or its CORBA interface. Applications use OSB objects as the building blocks to implement specific user interfaces, business rules and processing logic. Standard OSB applications can be used as a starting point for such customization. Furthermore, object oriented technology makes it possible that OSB core objects can be extended and completely new objects added without changing the core OSB library itself.
Client applications like CRM systems must reflect the specific business workflow of the operator and possibly integrate different OSS like accounting and credit rating. The OSB framework separates functional aspects from the business workflow and layout of the GUI and thus supports robust and extensible overall system architecture. Both, the object-oriented approach and the use of CORBA interfaces promote the implementation of distributed applications and central services. CORBA offers various programming language bindings (including C++ and Java), which means that OSB applications can be written in the best-suited programming language. On the other hand, performance critical server based applications written in C++ can bind library objects directly.
Billing systems must meet various and ever-changing requirements over their lifetime, most of which are not known when the system is installed. Time to market for new features is critical. Therefore, new features should ideally be added to the system with minimal changes.
The most common way software attempts to meet this challenge is through configuration: Features are kept generic so that different configurations can meet related requirements in one area. For billing systems, this applies typically in areas such as promotions and discounts, price plans, taxes, rounding rules, etc.
Let’s look at taxes as one relatively simple example: The basic OSB “standard tax” rule calculates one tax as a linear function of the net amount1). Through configuration of the tax percentage and a constant tax amount, this tax function can cover all linear tax calculation requirements. A majority of tax calculation requirements fall into this category. There are, however, tax requirements, which do not fall into this category. For example, the linear tax function cannot calculate a tax, which depends on the net amount (e.g., “stamp fee” in Italy).
In other words, the configurable tax function can meet many different requirements but it also has clear limitations. How can we address these limitations?
The “rule-based” approach is one attempt to overcome such problems. For example, a rule-based tax calculation system would offer a certain set of mathematical functions and control statements and let the user define the tax calculation function itself. OSB does not implement the rule-based approach for two reasons: Firstly, this only defers rather than really removes the limitations and secondly, it is likely to cause performance problems.
The extensibility of OSB goes one step further: Experience proves that sooner or later there will be a requirement for which neither the available configuration nor a particular set of rules is sufficient and the software needs to be changed. OSB was designed to accommodate changes: As a result of the library-based architecture, we can tailor OSB applications to customer specific business processes and still base it on the core library. What’s more, we can extend the building blocks themselves: Object oriented techniques (such as inheritance and polymorphism) allow existing library functionality to be modified and new logic to be added.
So, to add support for a new tax category to OSB, we derive from the abstract class tax and implement its interface in C++. The new tax becomes a part of the existing framework. In fact, also the OSB “standard tax” is implemented in exactly this way. Adding the new tax does not require any change to the existing OSB library, which means that the resulting efforts for regression testing and upgrading are minimal.
With new functionality being generalized and added to the core library, the OSB library will evolve over time. There will be no need for costly and risky “big-bang” migrations from one version of OSB to the next. Seamless upgrades will contain bug fixes and new features. It will even be possible to reuse existing customer specific specializations with newer versions of the core library or parts thereof.
Major savings will be possible over time, because OSB is designed in a way that allows for frequent small incremental upgrades and does not require major migration projects to benefit from new functionality.
| 1) | In this simple example we are not concerned about how many taxes are calculated for one amount or how the taxable amount and the applicable taxes are determined. |
Today, many communication companies need to publish invoices through several
media, for example on paper, on the web and through email.
Traditional billing systems typically create invoices in a proprietary format
and a number of similarly specialized post-processing steps are needed to produce
the final invoice. The time needed for the end-to-end invoice creation process
depends largely on the number of steps involved and so does the likelihood for
errors in the process.
OSB billing creates XML invoices in one step. There is no proprietary intermediate invoice format. XML is a versatile industry standard and actively supports transformations into other formats, like, e.g., HTML or PDF. A large number of commercial applications exist that can process XML documents and third party support is abundant. XML can be directly published on the Internet. A style-sheet (XSL) defines how it is transformed to HTML and the translation is delayed until the invoice is requested. Depending on the web browser used, the transformation could even be delegated to the machine of the client to preserve server-side resources.
Advanced features such as individual layout for different customers or interactive
display of content, e.g., different sorting order, drill-down functionality,
etc., become very feasible.
Eventually, business partners such as large corporate customers or e-billing
providers may even wish to receive just the XML invoice for their own postprocessing.
In accordance with the overall OSB architecture, also the OSB XML writer is easily extensible. All the writing functionality of the OSB billing library is collected in one object and XML writer functions can be (selectively) overwritten and extended to create customer specific output.
Products offered by communication companies bundle different services together into attractive packages. For example, let’s assume a local mobile network operator offers five different products, one of which is “Silver Plan 100”:
| Silver Plan 100 | |
|---|---|
| Monthly Subscription | $24 |
| Monthly Free Talk-time | 100 min |
| Peak Hour Call Charges Off-Peak Hour Call Charges |
$0.21/min $0.12/min |
| Free Value Added Services | Voice Mail Caller ID 100 free SMS |
| Special Promotion | Premium Number |
Once we decide for “Silver Plan 100”, we are offered to choose our new (premium) telephone number. Let’s further assume that we also subscribe to a detailed invoice (which costs an extra $3 per month) and the roaming service (which requires us to pay an extra $200 deposit).
OSB models exactly this product concept: The CSR chooses “Silver Plan 100” and personalizes the product with our SIM serial number and the telephone number we picked. Then she ticks “detailed invoice” and “roaming service” which are optional product items of this product. That’s it.
This is possible because of the unique OSB product engine: A OSB product consists of product items. Possible product items are: goods (e.g., the mobile phone itself), resources (like a telephone number), network services, value added services, tariff systems, charges, promotions, etc.
A product item may itself be made up of other product items. A GSM subscription,
for example, needs a least a SIM card, the telephony service and a MSISDN (telephone
number). Cascading item lists provide a mechanism to structure a product. Furthermore,
restrictions can be defined on the product items, e.g., “exactly one of
the items must be selected” and the “mandatory” attribute defines
whether a product item is necessary, i.e., an integral part of the product or
not.
Price lists are defined and attached to products
and product items and provide all information about relevant charges (amount,
charging rule, taxation and accounting criteria, etc).
All defined products are listed in the product catalogue. When the CSR assigned the “Silver Plan 100” product to our contract, a new personalized product was generated to link the “Silver Plan 100” to our contract and subscriber entries and to keep track of its history: When was the product sold, what is the minimum duration of the subscription, etc. The personalization, e.g., the telephone number and the fact that we subscribed to the “detailed invoice” service are stored in personalized product items.
A personalized product is associated with a user and billed as part of the contract it belongs to. Products can provide services of different networks. Multiple personalized products can be assigned to one contract, i.e., billed on the same invoice: Convergent billing becomes a straightforward task!
For a subscriber, the evident value of convergence is the possibility to receive
one single invoice for all used services.
For a network operator, convergence means a much greater benefit:
OSB supports all kinds of communication networks, is ready to rate all usage records and bill any service you want to offer to your customers. The OSB product concept provides a network independent layer that embraces all services.
The combination of these features makes OSB a genuinely convergent billing system.
A billing system is never an isolated piece of software. Today, no established telco company can simply replace their existing legacy billing system. Instead, new functionality must add value and at the same time protect existing investments. Communication companies face major challenges integrating software systems from different vendors and operating in and maintaining the resulting heterogeneous environment. The OSB framework was designed with the integration challenge in mind.
This section elaborates how OSB billing can integrate with a legacy system. We consider different levels of integration, as each environment will have its own set of requirements.
The figure 2 above shows the collaboration of the OSB billing module with other systems, using CC&B as an example: Existing CC&B applications like Customer Care and Rating produce data that is stored in the database CCB. Billing collects the data generated by other modules and uses the billing functions of the OSB library to create the invoices. No OSB database is shown in the diagram: depending on the integration approach, it may not be needed at all.
The three principal integration strategies are:
In this approach, existing applications of the target system are changed to read and write OSB database objects where billing relevant data is involved. In terms of OSB, such data comprises objects like taxation keys, products, product items, etc.
This strategy allows unrestricted use of all available billing functionality at the cost of the implementation effort in the applications of the CC&B system.
It is not always possible to change applications of an existing CC&B system at will. This means that OSB billing on the one hand must use the foreign data while on the other hand OSB objects are needed to access the billing functions. In order to fulfill this requirement we can extend the I/O functions of the OSB library to create OSB objects from database objects of the target system and vice-versa as shown in the figure below.
Replacing OSB I/O functions is only possible if their interface remains unchanged. Additional I/O functions may be provided in the interface of the CCB I/O library if necessary. Additional OSB specific configuration data is needed. It may either be stored in a separate OSB database as indicated in the diagram or directly within the database of the CC&B system.
This method has the advantage that no particular changes are needed in the billing application; at the cost that certain OSB billing features may not be usable, simply because necessary data is not maintained by the legacy CC&B.
In this approach the data stored in the CC&B database (master) is translated and stored in the OSB database (slave). The billing application uses solely the OSB database to generate the invoices and to store the results. In a subsequent step the results are translated back and made available to the CC&B database. The synchronization between the CC&B and OSB database can be obtained by several means:
The master - slave model allows complete separation of billing from other applications. The main problem is how to guarantee the accuracy of the synchronization between the databases.
It should be noted that the real time mode is quite similar to working directly against OSB database objects, and that on-demand more or less corresponds to the replacement of the I/O functions. The main difference is that data are stored twice, once in CC&B and a second time the OSB database.
OSB is an object oriented CC&B framework built using modern technologies and industry standards. The OSB architecture consists of a class library, which provides building blocks and defines clear interfaces for applications and other OSS.
The OSB billing engine features functionality that meets international standards in areas such as multi currency support, taxation, subscription and rounding rules. OSB billing creates genuinely convergent XML invoices, ready to be published in different formats.
The OSB framework is designed to help communication companies tackle billing challenges from various angles:
Abbreviation Stands for CC&B Customer Care and Billing CORBA Common Object Request Broker Architecture CRM Customer Relationship Management CSR Customer Service Representative GUI Graphical User Interface GSM Global System for Mobile communication HTML Hyper Tag Markup Language I/O Input / Output ISDN Integrated Services Digital Network MSISDN Mobile Subscriber ISDN number (GSM) OSB Object-oriented Scalable Billing OSS Operation Support Systems Portable Document Format SIM Subscriber Identity Module (GSM) UML Unified Modeling Language XML Extensible Markup Language XSL Extensible Style-sheet Language