Where Should Rating be Implemented?

Rating is about computing the charge amount for a given transaction. In telecom, such transactions can be as simple as a telephone call, or as complex as the use of a multiparty gaming application in which the charging components include network use, quality of service (QoS), storage, levels of play, and more.

Likewise, rating some transactions can be simple. For example, consider a messaging plan which gives the customer the first 100 SMS messages for free, and then each subsequent message is charged at 10 cents apiece. In contrast, rating can also be very complicated. For example, the game scenario above may involve charging and discounting for QoS/SLA violations, measured data transfers, measured voice, application usage (amount of time, number of players, time of day, and so on), royalties owed to the game authors and more.

But no matter the service or pricing model, the rating engine plays a vital role in the operator's OSS/BSS. This is because without the rater, operators cannot bill for their products on a usage-sensitive basis. They cannot market and sell their products or services the way they want. They cannot challenge competitors' offerings. They cannot offer individual case pricing. They cannot run their business unless they give their products away for free or by subscription.

Rating in the past

Until recently, the rating function was performed predominantly in the billing system. In fact, until recently, billing systems performed nearly every BSS function, including customer care, taxing, order entry, business intelligence and managing the product catalog. This is because legacy services are relatively simplistic, because services were limited to circuit voice and data, the predominant credit model was post-pay on a 30-day cycle, and pricing models were simple. Further, the network infrastructure was rating-friendly, because switches provided all the call data needed for billing and guiding.

Elements driving change

Today's telecommunications environment is radically different from even a year or two ago. The key elements of change include:

• Next-generation services: In the wireline industry, VoIP, IP-VPN and IP-Centrex are displacing traditional voice and ATM/Frame services. Moreover, we are seeing innovative value-added services coming to the market, such as presence management, gaming, messaging, collaboration, IP video and niche voice services (see the July 2004 Billing World editorial). The same is true in the wireline industry. Here a plethora of mobile entertainment, corporate access, mobile office and other value-added services are on the market today. These services and the corresponding pricing models look nothing like the "time and distance" paradigms of the past.
• Network upgrades: Except for transmission, it is only a matter of time before an "all-IP" network displaces the TDM network. The rater will have to understand how to deal with these usage records and metrics, which look nothing like those generated under the TDM model. Secondly, IP networks are highly distributed and involve a wide range of service elements. Therefore, the rater will have to be able to take in such usage information from multiple elements. This is in sharp contrast to the service delivery environment of the TDM network, where the switch was the key device and exclusive source of usage information.
• Real-time accounting and pre-pay: Customers are increasingly expecting online access and up-to-the-second access to billing/usage information and multiple payment models, including pre-pay and any-pay. This means that before, during and after delivery of a given service, the OSS/BSS must be able to compute how much it costs and provide an account balance that reflects any promotion or other credits that should be applied. Thirty-day posting will not meet customer expectations.
• Transaction volume: The nature and complexity of the IP infrastructure and related services can drive usage volumes up by orders of magnitude due to the scope and granularity of the services. The rater will need to scale to these volumes.
• Service bundling: Providers are increasingly bundling their service offerings into a single package. Here, the rater must be able to distinguish and manipulate each transaction type—but in the context of a bundled offering. Again, this is in sharp contrast to the single-service mode of the past, where the rater only had to understand one service type.
• Settlements: Product and service offerings increasingly consist of multiple service components, each of which may be delivered by a different supplier. However, complex revenue sharing and settlement systems may require that each service component be accounted for independently, relative to the respective value each brings to the offering. This requires that the rater "slice and dice" a given transaction such that each party is compensated according to the business arrangement.
• Credit models: Operators are increasingly adopting pre-pay, stored-value and any-pay credit models. Under these payment models, the rater must produce charging events that impact account balances before, during and after service delivery, as part of the call setup process. Post-pay raters will not support such transactions.
• Transaction setup: The days of "design and assign" are giving way to IP networks that can support just about any service on demand. The key difference of this architecture is that the network infrastructure detects when users want to invoke a given service (such as via "content switching" elements from Cisco/P-Cube, WaterCove/Alcatel and others). Unlike previous service environments, this architecture requires that a service transaction be sent to the OSS/BSS for authorization/configuration prior to delivery. The OSS/BSS must respond to the transactions, which may involve pre-rating the event in real time (in milliseconds).
• Service accounting: Many expect flat-rate pricing models to give way to usage-sensitive models, for both bearer and non-bearer services, as a way to drive ARPU and encourage development of value-added services.

Rating options today

Any one of the above issues requires modifications to post-pay, circuit-oriented raters. When each is considered by itself, one could easily argue that upgrading billing would make more sense than reengineering a separate rating solution. However, when they are considered collectively, it is natural to look at new architectures and rating solutions that are perhaps better positioned to meet the sum of these changing requirements now and over time.

Over the past few years, vendors and operators have invested considerable time and effort in engineering next-generation rating solutions. What makes this subject controversial is that each solution is remarkably different architecturally and in approach. The options include:

• Keep rating in the billing system—The first approach is to simply upgrade the rating engine that exists within the billing system. Billing vendors haven't ignored the changing environment and have made significant advances in their billing infrastructure, including upgrades to rating engines. As such, option 1 is to keep the rater within the billing system, and have operators invest in the appropriate upgrade.
• Adjunct the rater—The second option is to decouple the rating engine from the billing system, thereby creating another layer in the OSS/BSS stack. The idea here is to bolt the rater on top of the mediation package, where it retrieves usage information and integrates with the other systems that hold customer and balance information required for rating. This approach allows the rating to be done outside billing/CRM, in an adjunct manner, with a bi-directional interface to the billing system where "pre-rated" transactions are forwarded and posted to the customer's account.
• Combine rating with mediation—The third option is to combine the mediation and rating elements into the same subsystem. The idea here is similar to the adjunct rater above, but instead of creating two separate systems (mediation and rating), just create an integrated package.
• Let the network do the rating—The fourth option is to embed rating within the Intelligent Network (IN) systems found in the network today; thereby allowing network devices and supporting service control points (SCPs) to compute charging information at call (or session) setup. This approach decouples rating from the BSS layer, and implements solely within the network.
• Embed the rater in the handset—The fifth and final option is to embed rating within the CPE. The approach here is to move the rating and balance management functionality to the device itself (the handset, set-top box, gaming device or general-purpose computer). The rater, as a process that runs on the device, then performs charge calculation and admission control as needed during call setup in a manner that is loosely coupled by back-office systems. Periodically, the rater communicates with the network/back-office to synchronize charging, rate plan and balance information.

So where does the rating engine belong?

Each of the rating options above is available from vendors today. Each has been field-tested. Each has pros and cons, strengths and weaknesses. Some have shown to be a brilliant decision. Others have turned into a nightmare.

So the questions are: Which option makes the most sense for an operator? What are the key considerations behind the decision? What are the driving elements that would compel an operator to pursue such a fundamental architectural change? What happens if operators defer?

These are the questions I asked some of the leading experts in the OSS field to address, and on which to share their perspectives. Each approach represents one of the "rating options" and is implemented in a corresponding product on the market today. I asked the contributors to be opinionated and direct, and to present their arguments to defend the position. Their responses follow.

Billing Perspective—
Tal Givoly, Chief Scientist, Amdocs

When considering the location of the rating function, we must first clearly understand the current and emerging requirements for billing, rating and pricing. The margins of traditional services offered by CSPs are being threatened by declining prices, competition and the prevalence of flat-rate pricing. The CSP must therefore evolve to become a retailer of a variety of content services (such as ring-tones, pictures, games, applications, video clips, and music downloads), not just bearer services.

As CSPs become retailers, the focus is on forging stronger, more profitable customer relationships. The type of intentional shopping experience currently enjoyed in the bricks-and-mortar world needs to be recreated and managed by the CSP. Billing is the cash register. Pricing mechanisms can both encourage and deter spending. The price of a product or service at a particular time can be influenced by a number of factors, and dynamic pricing needs to be employed to avoid leaving money on the table.

Rating's location, management and execution can have a profound impact on the CSP's ability to maximize customer spending. Regardless of where you locate the rater, it must support the following requirements:

• Single administration for customers, products and services. Any segmentation of administrative functions controlling different customers, products or services will inhibit the ability of the CSP to offer products and services profitably.
• Agility to act on real-time and historical information. This is necessary in order to be able to dynamically update pricing based on a complete understanding of customer information. Past usage as well as product-specific and promotion-specific information, such as demand and break-even points, must be considered.
• Multiple methods to calculate and communicate the price to customers. This includes sophisticated real-time dialog, shopping carts, wish lists, auctions and more.
• Ability to offer customers multiple payment methods, such as pre-paid balances, post-paid balances, credit cards, loyalty points or any valid payment mechanism.
• Ability to track and aggregate both completed and aborted purchase transactions per customer, per product and per segmentation thereof.
• Ability to process events off-line, or out of network events. Many chargeable events do not originate in the network; it is not always sensible to route them to the network for rating. These include in-collect roaming, interconnects service order rating and partner settlement. Furthermore, events are increasingly pre-rated by content owners.

Analysis of these critical requirements points to a clear need for a single, coherent, administrative function for setting prices within the context of demand and past behavior. They further show that all touch points with the customer must be coherent, including offer of service, advice of charge, service consumption, customer service and the bill.

Distributing processing is rendering the distinction between housing the rating in a separate system from the billing system increasingly less relevant. However, by their very nature, solutions that introduce multiple administrative domains disrupt coherency in the OSS. They should be avoided at all costs. As such, the clear and distinct advantages of keeping rating within the domain of the billing system include:

• Unfettered access to all customer information to enable customer-specific pricing. This includes account-wide subtotals and discounts. In contrast, constantly propagating this type of information to multiple systems is both risk-prone and costly.
• Supporting intentional customer experiences. Billing is one of the few regular touch points between the CSP and the customer. Distancing the rating function from the billing system diminishes the quality of pricing information the CSP can effectively process. Not only does this introduce unnecessary administrative costs, it also diffuses control over profitability.
• Indisputable cost saving achievable through consolidation. Moving rating outside the billing system's control is contrary to current trends of consolidation. All Tier 1 CSPs are consolidating systems in order to reduce costs and gain more control across their operations. By distributing this key function, CSPs are acting contrary to best practices.

Keeping rating as an integral part of the billing system domain of control is not the only viable solution. However, it is the only option that can accommodate the critical requirements as detailed above. Most importantly, the administration function and the tracking of all customer interactions must be consolidated to allow a coherent, actionable view of customers and products. Of the options considered, housing rating within the domain of the billing system provides the most effective way to properly address these requirements.

Adjunct Rating Perspective—
Thomas Thekkethala, CEO, RateIntegration

Rating must be implemented as an adjunct process and not embedded either in the billing system or exclusively within the network. This view is driven by both technical and pragmatic considerations relating to billing and OSS capabilities/architectures in place today, as well as the direction of carrier infrastructure and future IP services.

Rating no longer belongs in billing

In the past, monolithic billing systems encompassed the entire switch-to-bill processing of usage records. More recently, mediation, bill presentment and payment, and customer management have evolved into highly diverse and specialized systems and are no longer considered a part of the core billing system.

Requirements for rating have now become highly specialized and dynamic and must be managed external to the billing system:

• New technology (VoIP, 3G, and others) and network convergence have spawned an array of new services (such as entertainment, info services and gaming) and an entirely new generation of service providers for content, m-commerce, and the like. In order to maximize the revenues from these opportunities, the rating system must enable creation and billing for services on demand and cannot be tied down to the billing system.
• The emergence of pre-paid and "now-paid" services requires real-time rating in-network that cannot be supported by an embedded rater in the back-office billing system.
• Carriers with large investments in a billing system have to consider replacing it with an off-the-shelf product, primarily because the internally embedded rating module cannot keep up with the market's evolving requirements. This can be prohibitively expensive, time-consuming and high-risk, due to the many associated interfaces and entrenched business processes. The obstacles can be avoided if rating is implemented external to the billing system while leveraging its strengths and data.
• Another alternative for carriers having billing systems with embedded rating functions is to attempt to continually modify and upgrade rating. This is also costly, time-consuming and fraught with risk, because it jeopardizes the entire revenue stream being generated by the legacy billing system. The stand-alone adjunct rating engine provides the only clear alternative that preserves the investment in the rest of the legacy system, without jeopardizing revenue flow. It is the only alternative that can be implemented rapidly and meet the carrier's time-to-market requirements. Rating does not belong in the network The carrier's rating requirements cannot be supported exclusively by implementing rating just in network/IN subsystems:
• The convergence of pre-paid and post-paid services requires rating to be done in-network in some cases and at billing time in others. An example is the case of customers who may have a post-paid relationship for telecom services, but must pay on-line in-network for content and entertainment, even within the carrier's walled garden.
• A further variation of a new generation of services requires partial rating in-network and partially at the time of billing. An example is multiple-player gaming, where in-network rating is required for authorization and usage-based accounting of play, but post service-completion billing requires other usage metrics and customer reference data for final rating. These real-time requirements cannot be supported by an embedded rater in the back-office billing system, nor can they be exclusively supported by a "charging server" resident in the network. The correct architecture is to put a rating engine between these two domains to manage the financial elements of the transactions that must be exchanged between them.
• The single biggest impediment to rapid deployment of new services is that the embedded in-network rating element and "billing system-derived" rating solutions inevitably have a specific underlying data model for rating that makes changes difficult and creates integration and data synchronization problems as well. The adjunct rater component architecture eliminates this delay, because its data and process models are independent of either system, while leveraging their data to enable rapid implementation of new services.
• The endless service scenarios and service bundles made possible by IP require a highly flexible and abstract rating rules engine. The flexible, rules-based expression of rating logic should enable 100 percent of the rating and discounting business rules and business logic for any new service to be defined external from the host system. It should then be capable of being implemented with either the billing system or the in-network charging server leveraging all reference data required from either host system.
• Rating is the function that converts a service into billable revenue. The product managers, marketing managers, pricing analysts and billing analysts need a completely intuitive user interface to model new services and dynamically and quickly launch them without any new programming effort.

An adjunct rating solution enables carriers to maximize revenue and leverage their massive investments in network technology that could otherwise be impeded and lost forever. In order to maximize the revenues from these emerging services, the product management team should have the ability to create services with complete flexibility and have them rapidly deployed in the market window, without being bogged down by the need to upgrade the billing system or in-network charging sub-system.

Mediation Perspective—
Rick Woods, VP, Product Management and Business Development, Intec Telecom Systems

Intec provides mediation systems of two forms: post-event mediation and active mediation. Depending on the product being used, the positioning of rating in the OSS is different.

Post-event mediation/rating

Post event mediation is used to collect network usage after the subscriber's network experience is finished. In this role, the mediation system is used to prepare the network usage for processing by other applications in the operator's OSS/BSS. This normally entails validating the data, transforming the data into a desired format, correlating the data with other network events, removing duplicates (physical and logical) and enriching the data so that it is in a complete form for processing by downstream BSS functions.

Intec believes that post-event rating is correctly incorporated in the billing layer of the OSS. This is because rating requires access to subscriber information, product information, market information (bundled services, promotions, etc.) and rate plans before a price can be calculated.

This information traditionally resides within other areas of the OSS. If the mediation system remotely accesses this information, not only would severe latency be introduced but also the OSS architecture would become far more complex. Additionally, the technology required to reduce latency is expensive and adds more cost to an operator's budget. If the required information is brought on-board the mediation system, the result is most likely the occurrence of redundant databases causing operational problems.

Usage aggregation is another large problem when rating is performed at the mediation layer. Unless the mediation system becomes the "database of record" for subscriber usage, how would it know when the 500th minute of usage is reached in a billing period? And if it does, how does synchronization between the billing cycle and mediation work? When does mediation clear out last month's accumulations and start a new month? How does re-rating work? What about error handling, financial auditing, generation of recurring charges and account reconciliation? What about free minute rollovers?

We have, however, provided solutions to operators where rating was performed within post-event mediation. Doing so is a compromise and the end-result is complex, but some of the reasons are:

The legacy billing system cannot perform converged rating (obsolete OSS components)

The mediation layer is the most responsive and quick to change (efficiency and flexibility)

Rating in one place and distributing the rated events to multiple downstream systems eliminates redundant functions across other applications (operational efficiency) Active mediation/rating For active mediation, the situation and Intec's recommendation is completely different. Next-generation services require that traditional billing functions move closer to the network. Before network access is granted, the operator must have a complete picture of the subscriber's account. The ability to pay must be determined before gaming, messaging, or video delivery occurs. Together these requirements mean that rating must occur within the mediation system with full visibility to rate plans and service bundling.

Unlike post-event mediation, these services require an "active mediation" system that enables bi-directional interaction between the OSS and network elements; and serves as an active participant in the subscriber's session. For reasons of reliability, availability, control and performance, it is critical that all components (service delivery, access management, rating, account management and balance management) act as an integrated whole. This entails no data hand-offs and low, millisecond latency.

Rating within active mediation supports both retail and wholesale functions. Retail rating calculates the charge for the subscriber's session, and wholesale rating provides the revenue share between the network operator and the content provider.

Intec believes that the only way to support the low-latency, bi-directional interaction with network elements as mentioned above is to provide real-time rating and balance management functions at the mediation layer, and to incorporate all of the relevant databases in this layer as well.

Active Mediation Perspective—
Joe Hogan, CTO, and Bob Machin, Product Marketing Director for Rating, Openet Telecom

Openet strongly believes that the rating function should be decoupled from billing system, and regarded as a separate component layer in the BSS/OSS stack. We further believe that subscriber rating should be embedded into an active mediation layer to minimize latency in the service delivery process.

Fundamentally, we see telecoms becoming an ever-broader retail environment, offering communications, content, services and the sale of digital and even hard goods. Retail environments require point-of-sale systems, and these typically work in real time—customers don't leave the store with goods until it's been established how they want to pay, and, more importantly, whether they are able to pay. These decisions happen "pre-delivery." Putting a price on what the customer wants to buy is a key step in that process.

Can you do this through the billing platform? Logically, there's no reason why not. But in practice the agility and responsiveness required of network edge rating is not compatible with the heavy lifting that billing systems have to do, whether in terms of high-volume batch processing or in complex account management.

Instead we believe that it's time for rating to come out of the back office and become part of a real-time point-of-sale environment. That environment works at the network edge, authorizing and enabling (or denying) service pre-delivery and updating customer accounts and balances immediately—before the next purchase request comes in.

To support this environment, a new breed of "active" mediation systems is required to support two-way communication with network equipment. Here the mediation system must authorize, authenticate and respond to requests emitting from an increasing number of intelligent elements in the network, such as probes or intelligent gateways, in real time. Often, the required authorization is financial—confirming that subscribers have the funds to pay for the service they have requested. But these service requests can also require a number of questions to be resolved, including:

• To which subscriber does the request relate?
• Which service is the subscriber trying to access?
• Does this service require pre-authorization?
• Is this service delivered by subscription?
• Does the subscriber have a currently valid subscription?
• Does the subscriber have sufficient credit to pay for the service?
• Has access to the service been prohibited by the bill payer for this user?
• Is a PIN or password required to access this service?
• Is a credit card payment required to access this service?
• Does a promotion or a loyalty point scheme relate to this service?
• How much does this service cost, for this subscriber, at this time?
• Given the calculated cost, does the subscriber still want to pay?

Only when the context for the request has been fully established can the necessary steps be taken to assure payment (if necessary) and the authorization (or denial) be returned to the network. And we need to do this in 50 milliseconds or less and perhaps many thousand times per second in peak traffic hours so that the customer does not detect a delay.

Although the above steps only summarize the process, they indicate how important rating is to next-generation service processing. Only when we know the value of a service can we determine whether the subscriber has the funds and the willingness to pay.

In Openet's experience, the single biggest contributor to delay in authorizing an on-line transaction for a subscriber is the rating engine, as it attempts to calculate the rate for a particular service for a particular subscriber. Should rating slow the transaction to perceptible levels, the subscriber will perceive network and service response to be lethargic and will look for alternatives.

It is therefore Openet's contention that in the world of active mediation, the rating logic required to support real-time content delivery needs to be embedded within the mediation layer, not in an adjunct platform or the billing system. Only embedding rating within mediation delivers the performance, scalability and low latency requirements which next-generation service delivery will increasingly demand.

Stand-alone Rating at the Mediation Layer—
Jarkko Leppalahti, Product Manager and Kari Pulkkinen VP, Product Business, Comptel Corporation

A key driver for rating is the trend toward a unified service offering of the operator, where subscribers are able to use all services regardless of the payment method they have chosen (prepaid, postpaid). Another visible trend is that operators want to offer a single view of the bill regardless of the network (wireless, wireline or broadband). A unified service offering requires a unified rating engine. Comptel strongly believes that our architectural approach—introducing rating as a stand-alone application in the mediation layer—provides the most value to operators and end users alike.

The key requirements in the rating and charging of wireless data services, such as SMS, MMS or WAP, are:

• Computing the service costs in real time before service delivery. Real-time rating is essential for generating an advice of charge, which is becoming increasingly important to customers.
• Determining account balance in real time. Account balance must be determined during rating and recalculated before or during service delivery. This is especially true for prepaid subscribers.
• Building a response from the OSS/BSS into the setup of the transaction.
• Bundling/unbundling offered services.

An online (prepaid) or offline (real-time/batch postpaid) mediation solution provides an adaptable charging interface layer with a configurable transaction flow between different elements in the network and OSS/BSS. By placing the rating engine in the mediation layer as a stand-alone application, operators may utilize the strength of mediation solutions (interfacing to network elements, managing charging business logic, and manipulating charging events and parameters). A stand-alone rating engine computes how much a service costs by responding in real time to queries from the mediation solution. Rating is triggered using either

• Control nodes that identify and control the chargeable data and service flows in different networks, producing charging events for the mediation solution to process; or
• Event records collected from various network elements that provide the service.

An undeniable benefit of this approach is the faster, more flexible configuration of advanced rule-based rate plans, volume discounts and product bundling due to independence from the network and the billing system. Additionally, by leveraging the granularity of data being managed by the mediation system, this approach enables access to any chargeable parameter available in the network and applying it to a specific charging model.

As an example, in the case of download services in wireless networks, the charging may be based on fixed or per-download fee, which also contains the data access charge. Another example is an MMS tariff class based on the size of the MMS message in GPRS volume. In these charging scenarios, mediation provides the business logic for implementing the proper charging models and for avoiding double charging of the access volume. Rating functionality can be enriched by the mediation business logic.

A stand-alone rating application at the mediation layer also enables rating of postpaid services. Here the mediation solution and the rating engine may operate either in real time or batch mode. The logic of whether the rating engine is accessed for charging online (prepaid) or offline (real-time/batch postpaid) is configured in the mediation solution.

A stand-alone rating solution in the mediation layer also:

• Enables revenue sharing calculations on the basis of mediation's processing of different transactions from the operator's own network and third-party content providers
• Supports highly usage-sensitive charging models, like 95-percentile billing, due to the fact that network usage data is visible at the mediation layer.
• Provides a more efficient charging architecture by drastically reducing the volume of usage data that succeeding OSS/BSS applications need to process.

Finally, a stand-alone rating engine at the mediation layer enables operators to launch new services with their existing billing and CRM systems, which reduces the total cost of ownership. Implementation of the rating functionality at the mediation layer is less costly and less risky than, for example, the enhancement or replacement of a large billing system. During implementation of the stand-alone rating application, the charging components of the billing system need not be touched.

Comptel emphasizes that even though our architectural approach includes rating at the mediation layer, it relies on keeping rating as a separate application, independent of the operator's network elements and of its upstream billing platforms. We believe this approach provides the most flexible, functional and cost-effective solution for operators to deploy true unified rating.

IN Perspective—
Dr. Steve Menear, Associate Vice President, Comverse Inc., IN Division

In his introduction, Dr. Lucas provides important insight into the future of telecom services and the importance of correct rating engine placement. A major theme of his vision of the future, and that of other industry experts, is real-time billing. Obviously, some aspects of the billing process will always remain offline, but others—including service authorization, rating, charging, and balance management—must become real-time.

Real-time billing (which includes real-time rating) is the only practical solution to the increasing problem of risk management. Customer self-care, and the significant savings it brings to the customer care budget, demands up-to-date account information. Further, the information flowing through a real-time billing element is valuable marketing intelligence and can be put to good use in other ways—for example, to enable interactive marketing, targeted and preemptive promotions, and dynamic CRM capabilities.

A real-time billing solution must meet exacting standards:

• It must update account information in milliseconds. The banks learned decades ago to approve credit card transactions and to enforce credit limits for all customers in real-time. The same level of financial discipline is required in the telecom industry when approving service requests. Just imagine how little time it will take an end-user to incur large debts with some of the new data services appearing on the horizon. Quite frankly, batch-oriented billing—and even near real-time billing—is no longer acceptable.
• It must process huge call volumes while maintaining switch-like levels of availability. Some of our larger systems in the field today process thousands of real-time billing transactions (for voice, SMS, data, and other services) every second. Our customers know that a proven network-level technology is needed to perform this task reliably.
• It must be centralized in order to maintain strict data security. The typical operator is generating tens of millions of dollars in revenue each month and, in most cases, is responsible for large amounts of prepaid credit. On the other hand, handsets are becoming increasingly like miniature computers with the potential to penetrate the billing process. A centralized approach to rating and account management is crucial.

These strict demands can best be met by a network-based solution to real-time billing—one that makes use of proven Intelligent Network (IN) technology.

The original premise of the Intelligent Network was to relieve the switch from heavy service-level processing loads for which it was not designed. Service logic runs on a separate network element and interacts with the switch using open, standard protocols. The latest IN-based solutions have embraced advanced technologies, such as OSA/Parlay, to deliver real-time support for an increasingly diverse array of data services.

Today, an IN-based rating engine not only offloads service-level processing from the switch, but it also performs billing-level processing. As a profitable side benefit, operators avoid the often-leaky CDR-based billing cycle by migrating to an IN-based rating solution.

So, why should the rating engine be network-based and built using IN technology? High transaction rates, real-time processing, optimal availability, centralized security and system flexibility—these are the things that matter most. Few technologies can process millions of hourly transactions in real time. Few technologies can support flexible, value-based rating for emerging services. No other rating technology has such a long track record of delivering high-availability, scalable solutions. These facts make the argument for network-based rating truly compelling.

Handset Perspective—
Chandler Tedholm, Director of Technical Communications, Telemac Corporation

If the service you are billing is hard-wired to a single network, billed a month after the fact for a simple timed connection, then the location of the rating engine has little impact on the performance of the network. If, on the other hand, you are billing for today's wireless services, including prepaid or real-time charging, the only logical place to put the rating engine is in the mobile device. Here's why:

Real-time processing efficiency: Prepaid services must be rated and debited in real time, or the wireless operator leaves itself open to revenue leakage. Real-time processing capacity is typically the single most constrained resource in the network. Network-based prepaid calls can require eight to 10 times as much processing power as a call rated within the mobile device. This additional network processing capacity significantly increases the required investment in network elements for a given number of subscribers.

Transmission efficiency: Ideally, processing should be performed as close as possible to the point where it is needed. If an operator has to backhaul rating information to a centralized processor, the operator is wasting transmission resources that can otherwise be used for revenue-generating traffic.

Scalability: The inexorable rise in traffic and processing demands makes it increasingly difficult to perform all processing in a central server. If an operator can distribute the rating calculations among numerous processors, it increases overall capacity. The limitation of the rating engine is no longer tied to the number of subscribers.

Granularity: Subscribers are conditioned to believe it is fair to pay in proportion to the amount of service they use. However, the difficulty and expense of centralized rating has forced network operators to resort to flat charges or all-you-can-eat schemes. If an operator can rate inexpensively through distributed processing, the operator can bill for small increments of usage (such as per second or per kilobyte), using a rich set of rating rules contained in the mobile station. The rules are administered by infrequent dialogs between the mobile station and the BSS.

Portability: Subscribers need the ability to access service through roaming partners. Connecting networks such that they can rate roaming traffic in real time is extremely complex and expensive. As a result, many operators limit roaming permission to only the wealthiest subscribers. If the subscriber carries the rating engine in the mobile station, operators can rate and bill prepaid roaming traffic in real time with no more overhead than post-paid traffic.

Commonality: The world of m-commerce creates the possibility of endless permutations of networks, merchants and financial institutions. The only common denominators among these combinations are the subscriber, the mobile equipment, and the SIM card. Therefore, the mobile station is the most logical place for the rating engine and, in most networks, the SIM/USIM, where subscriber identity is securely maintained for AAA and which can move from handset to handset.

Conclusions: There are compelling reasons to place the rating engine within the mobile station—within the OS of the phone (ME) or, preferably, in a dialog between the ME and the SIM where rating rules and values are securely stored in the SIM. When a billable event is requested from the network (MT or MO) the request can be detected, rating rules applied, and value assigned from the appropriate account (minutes, units, dollars, bytes, etc.), without requiring any additional dialog with the network. A fraction of the mobile station's processing power can be harnessed for frequent computational tasks, while account administration remains within the network and billing system. Other proposed locations for the rating engine are all variations on a theme that fail to address the fundamental engineering issues caused by centralized processing. Rating is a prime example of the kind of process that can and should be distributed to the network edge.

Conclusion

I would like to thank all the contributors for their time and expertise. I believe they presented a fair view of rating from each respective approach. However, buyers beware! Although the authors did a great job discussing the pros, each approach has some very tricky pitfalls for implementation, integration and functionality. I encourage the readers to follow up with the authors (and other leading vendors in the area) to discuss the tradeoffs and implementation-specifics in detail.

The authors can be reached by e-mail at:

Tal Givoly, Amdocs—tal.givoly@amdocs.com
Thomas Thekkethala, RateIntegration —thomas@rateintegration.com
Rick Woods, Intec—rick.woods@intec.us
Joe Hogan and Bob Machin, Openet—joe.hogan@openet-telecom.com, robert.machin@openet-telecom.com
Dr. Steve Menear, Comverse—Steve.Menear@comverse.com
Chandler Tedholm, Telemac—chandler.tedholm@telemac.com
Jarkko Leppalahti and Kari Pulkkinen, Comptel—jarkko.leppalahti@comptel.com, kari.pulkkinen@comptel.com

Dr. Matthew Lucas is Vice President of TeleStrategies, and focuses on the OSS/BSS industry. He founded RateIntegration in 1999 and served as the firm's President/CEO through 2002. He co-founded IPDR.org and served as President through 2001. He holds a doctorate in computer science from the University of Virginia and can be reached by e-mail at: mlucas@telestrategies.com.