To make the above scenario come to life requires that all support systems synchronize usage data in real time—meaning that the billing and complementary support systems can determine the exact state of usage across all services (and corresponding account balances) instantly, at any moment in time, and that this information can be instantly accessed by any support system or subscriber. (For background on real-time billing, refer to “Batch Systems for Internet Billing? Think Real-time,” by Dr. Matthew Lucas and Dave Labuda, Billing World, January 1999.)
The importance of real-time data for service providers can be understood on three levels, each of which provides a compelling and savvy business case.
Most importantly, real-time systems satisfy customers. People are used to getting real-time data in other venues. For example, when customers go to their bank on line, they see their current balance—even if they made a deposit just moments ago. Likewise, when they go to Amazon, they’ll know the exact status of their order. And when they want to check on a package that they shipped via FedEx, they will see its exact location. But what happens when they go to their service provider? Often they get dated information, information that is only updated when the service provider can.
In addition to real-time account balances, today’s customers also expect a real-time accounting of the services and operations they’ve accessed and utilized (e.g., multi-service CDR reports), when and for how long, for both themselves and every member of their account. Looking even further, customers will want on-line self-provisioning that takes effect immediately, instant fulfillment of services ordered, and on-the-spot cancellation of specified services. In the super-charged Internet environment, service providers who can give both services and service will have the advantage.
The second valuable component of real-time operations is that it can be used to enforce business rules, including for prepaid accounts, as well as prevent fraud. For example, a customer with a $100 credit limit is prohibited from making a purchase that totals $102.75—almost the defined limit. Currently, both batch and transaction-based real-time systems do not solve the problem of defined credit limits.
Finally, real-time operations can help a provider market its services. Since real time provides a powerful window into the users’ world—at this very moment—the provider can develop and promote relevant incentives and packages. The immediacy of real-time, live promotions will increase revenue and customer loyalty (a significant benefit in itself).
Where does real time come into play?
With IT systems, features come at a price. And nowhere is that more evident than in engineering systems with time-based, performance constraints. Guaranteeing instant response time is the most difficult performance requirement for any system. Therefore, expect to pay a heavy price for such a system, because it will require more computing infrastructure engineered specifically to handle peak loads.
Why would a carrier invest in a real-time system? The reality is that for services billed on a 30-day cycle, real-time billing would probably not be a requirement. For example, when was the last time you wanted to know the “up to the second” balance of your monthly long-distance telephone bill?
Various elements at the transport layer (such as voice, data and video) are steadily merging, as well as the services offered at the application layer (such as Web content, game servers, rented applications, rich media and video on demand). The result is that new business models are being developed to increase revenue via value-added content and application services. Some providers may offer free communications services while charging for value-added application and content services; others will opt to provide free content and application services while making their revenue from advertising. Vertical ISPs, free ISPs and MSOs are developing innovative business models, but they can only be enabled through usage-based billing—which requires true real-time data.
Real-time systems
Just about every billing vendor claims to deliver a real-time system today. The reality is that most of these systems provide something less. Let’s consider each class of billing system on the market today (see Figure 1)[<
First Generation—Batch-based systems. A first-generation solution is characterized by processing batches of events at predetermined intervals. The billing function in this type of system often coincides with invoicing time. Some vendors have shortened this interval to hours to gain “near” real-time functionality.
Second Generation—Transaction (session)-based systems. This type of system is characteristically event-driven, the event typically being the commencement of a session. An entire billing process is usually carried out at the end of a session.
This type of system knows, in real time, when a session begins and ends, but does not update its information while the session is in progress; it can only update that retroactively upon session completion. Therefore, its real-time capacity is quite limited, considering that sessions might continue for an extended time, during which a variety of business rules should be triggered.
When handling real-time data, first- and second-generation systems essentially provide a similar level of information resolution, which in many cases is a few hours off at best. In first-generation systems, account resolution occurs at preset intervals. In second-generation systems, the data is typically updated at the end of a session.
So, technically speaking, a transaction-based real time system does operate in real-time. As illustrated in Figure 1, because these systems cannot provide accurate data at any given moment, they are merely “near” real time.
The main advantage to using a second-generation system over a first-generation one is that it’s possible to enforce a session limit during the authorization phase and work around the session’s time limit. This workaround, though, will not work in a multi-service, multi-account environment, where business rules may be affected by simultaneous sessions of converged services, family or corporate accounts.
A New Approach…
Service providers require a billing system that (1) goes beyond the boundary of a session’s start time, reaching into the session to keep track of what actually occurs during a session—while it is happening, (2) updates the billing and customer care systems on demand, and (3) scales to large numbers of subscribers.
This next generation must be able to compile exact usage data in real time. One way to accomplish this is to develop a cluster system that can service upwards of a few million users. One solution rests in polling. It seems logical to simply poll all system elements to determine the status of each subscriber and services they are currently accessing. However, this approach may only be feasible on a small scale. And when you consider large-scale and carrier-grade providers, the feasibility drastically drops to nonexistent.
Another approach that addresses these fundamental building blocks uses a “state cluster” that maintains the state of all active services as a function of the current time. With this method, the system will always know each and every user’s status. By holding the state of the active service and their vectors, as well as a formula that calculates a required parameter (such as balance) as a function of the current time, the system is always delivering real-time data. Therefore, the system has uninterrupted access to that service parameter, without polling the system a single time. This set of formulas also needs to be dynamically updated as events that affect it occur.
This type of system stores data on customers, groups of customers, entities and aggregates of that real-time data in the state server, as well as a dynamic list of events to be triggered according to the defined business rules.
Raw real-time data is not enough, though. A mechanism that can activate a chain of events according to predetermined business rules, based on the state of a given session, is also needed. Consider this: how can a service provider disconnect a user in the middle of service the moment credit runs out, or conversely, to give a bonus—on the spot—if a subscriber used a certain service more than a set amount of time?
Such issues lead us to the next step, that of the development of business rules. The number required is great, since each rule would need to meet different, exact requirements. Each rule would then need to be run every second against all of the functions stored in the state server. This would obviously put an unbearable strain on the system.
This predicament can be overcome by making the system attempt to predict events that may occur in the future. This new, third-generation system would handle this by maintaining a table of events that is fired every second (see Figure 2)[<
A system of this complexity, which must calculate millions of services and different tiers of records and customers, requires special algorithms that make the system more efficient, both in relation to the number of records it stores and how often it updates them. If this were not done, all the benefits gained from not polling the system would be lost.
A scalable solution
The fundamental limitation of event-based, second-generation, billing systems is that they are transaction-based. In such systems, each event triggers a transaction with its corresponding overhead, thus updating the billing system and keeping all subsystems in sync. This imposes a severe scalability limit on the size of the group for which it can feasibly provide real-time information.
A traditional, commercial RDBMS, acting as the single point of authority, was not designed to carry out this kind of operation. Obviously, this limitation causes a tradeoff between how much real-time information the system can provide and its size and load capacity. Nonetheless, an RDBMS must be in place to store and retrieve data for archival, query and batch processing, but it is not suited to maintain the current system status.
In the new, true real-time approach as we define it, a “state cluster” is optimized to store and act on real-time usage data (see Figure 3).[<
Jonathan Garini is the co-founder and CEO of Extent Technologies Inc., based in Reston, Va. He can be reached at jonathan@extent.com.
