REAL-TIME (ALL TBE TIME) OPERATION SUPPORT SYSTEM AND METHOD
BACKGROUND OF THE INVENTION 1. Field of the Invention
The invention relates to an operation support system (OSS) infra-structure and method for meeting the needs of various types of service providers. More specifically, the invention provides a true real-time support system and method that meets such needs as usage collection, provisioning, order entry, subscriber management, customer care and rating/billing requirements for service providers operating on an IP platform. 2. Description of Related Art
The appearance of next generation, IP-based communication services and devices has become virtually an everyday event. With the charged atmosphere of the Internet, and the subsequent creation of the new economy, companies seek to develop new services that give them the edge and, ultimately, enable them to profit from the opportunities the IP platform creates. Service providers therefore require a support system infrastructure that effectively meets their usage collection, provisioning, order entry, subscriber management, customer care and rating and billing requirements. Given the pace of the Internet, such an infrastructure should be dynamic, and enable providers to instantly deploy and modify hosted services.
To address the above needs, support systems strive to synchronize usage data in real-time — meaning that the billing and complementary support systems can determine the exact state of usage across all subscribers (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 in the service provider environment can be understood on three basic levels, each of which provides a compelling reason for the availability of real-time data.
First, 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 an on-line commerce site such as Amazon.com, they will know the exact status of their purchase order. When they want to check on a package that they shipped via FedEx, they will see its exact location. When they go to their communications service provider, however, they often receive dated information, information that is only updated when the service provider is able to update it. In addition to real-time account balance, today's customers also expect a real-time accounting of the services and operations they have 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 affect immediately, instant fulfillment of services ordered, and on-the-spot cancellation of specified services. A second valuable component of true real-time operation is that it can be used as a tool to enforce business rules, including pre-paid rules, as well as for fraud prevention. For example, a customer with a $100 credit limit will not reach a balance of $102.75 - almost the defined limit, simply because the OSS didn't know when to disconnect him.
Currently, both batch and transaction based real-time systems do not solve the problem of accurate credit limits and similar business rules.
Thirdly, true real-time operation can help a provider market its services. Since real-time provides a powerful window into the subscribers' world, the provider can develop and promote relevant incentives and packages. For example, real-time, live promotional item offers immediacy and can help increase customer loyalty and revenue- making capabilities.
In IT systems, features typically come at a price. That is particularly evident in engineering systems with time-based, performance constraints. In fact, guaranteeing instant response-time is one of the most difficult performance requirements for any system. Therefore, such solutions are expensive since they require more computing infrastructure engineered specifically to handle peak loads.
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, games 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 application and content 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 all examples of communications providers developing these business models. But these innovations can only be enabled through usage-based billing, which requires true real-time data.
There are a variety of billing systems currently in existence that claim to deliver a real-time system. These systems, however, fall short of providing an actual real-time system adequate to meet the needs of service providers and customers/users. These existing billing systems include the following. 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 functionaliry. 2. 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 only updates 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, in one sense, a transaction-based real-time system does operate in real-time. But, as illustrated in FIG. 1, since such systems do not provide accurate data at any given moment, tiiey are merely "near" real-time. Also, although in a second generation system
it is possible to enforce a session limit during the authorization phase and work around the session's time limit, this workaround is not generally effective work in a multiservice, multi-account environment, where business rules may be affected by simultaneous sessions of converged services, family or corporate accounts. As is seen, there does not currently exist a true, real-time operations support system that adequately meets the needs of service providers.
SUMMARY OF THE INVENTION
In view of the above disadvantages of currently available systems and methods, service providers require an actual real-time billing system that (1) goes beyond the boundary of a session's start time, and reaches right into the session itself, keeping 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. Such a support system and method is not currently available today and is provided in the below-described invention.
In brief summary, it is an object of the present invention to provide a next- generation billing system that compiles exact usage data in real-time. To that end, the present invention provides a method on which distributed or non-distributed operations support system and employs a server and related technology (a "state cluster") to maintain the state of all active subscribers' services as a function of time. By holding the state of the active service and their vectors, as well as a formula that calculates a required parameter as a function of the current time, the system is always delivering real-time
data, without polling network elements and/or a RDBMS that can cause serious performance degradation and scalability problems.
It is also an object of the present invention to provide a system and method that activates a chain of events according to predetermined business rules based on the state of a given subscriber session. The present invention accomplishes this by attempting to predict events that may occur in the future through maintenance of a table of events that is triggered every second. The table is dynamically updated, as newer events might affect the timing of older events in the table. This method is far more efficient than to evaluate all business rules every second, an alternate method that can also cause serious performance degradation and scalability problems.
It is further an object of the present invention to provide a billing system that is scaleable to handle large numbers of transactions and users within a network, as described below.
DESCRIPTION OF THE DRAWINGS
FIG. 1 is a graphical representation of the comparison between batch, transaction and true real-time account balance availability.
FIG. 2 is a schematic diagram of a preferred embodiment of an operations support system in accordance with the invention. FIG 3 is a flow diagram of a preferred embodiment of a method in accordance with the present invention.
DESCRIPTION OF PREFERRED EMBODIMENTS
The present invention employs a server software and related technology (collectively a "state cluster") which processes usage data in actual real-time. Namely, rather than employing a simple system that services upwards of a million users and polling all of the system elements to determine the status of each subscriber and services each is accessing, the present invention uses a "state cluster" that maintains the state of all active subscribers' services as a function of the current time. The system always knows each and every subscriber's status. By holding the state of all active subscriber's service and their vectors (e.g. pricing and rating rates and rules), as well as a formula that calculates a required parameter (such as the account balance) as a function of the current time, the system can always deliver real-time data accurate up to the moment. Therefore, the system has uninterrupted access to that service parameter, without polling other elements of the system a single time. The set of formulas is dynamically updated as events that affect it occur. The system stores data on customers, groups of customers, entities and aggregates all of that real-time data in the "state cluster", as well as a dynamic list of events to be triggered according to defined business rules.
In addition to true real-time data, the invention also provides a mechanism that activates a chain of events according to predetermined business rules based on the state of a given session. This permits, for example, a service provider's disconnecting a subscriber in the middle of service the moment their 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. The number of business rules of this type required is obviously great. Conceivably, each of those rules would need to be run every second against all of the functions stored in the state server. Such would, however, put an unbearable strain on the
system. This predicament is overcome in the present invention by the system's attempting to predict events that may occur in the future. That is accomplished by maintaining a dynamic table of events that is checked every second. When the session starts the system calculates a rule. The system predicts the time a business rule will trigger and inserts the rule into a dynamic table of events with a predicted time, that is either accurate time or may be before the accurate time dependent on the complexity of the rule. When the time comes the system tests this rule again to see if it meets the rule requirements. If yes - it executes the rule action, if not it recalculates and inserts the rule back into the table of events. The table itself is also dynamically updated, as newer events might affect the timing of older events in the table.
More specifically, FIG. 2 shows a preferred embodiment of an operation support system 200 in accordance with the present invention. Shown at 201 are various types of information inputs to the system 200 such as "Content," "Wireless Application Protocol (WAP)," "Application," "Dialup," "Broadband," "Voice," "Video," and other types of information inputs. Inputs 201 are the network transaction information or data which result from system subscribers' activities. This transaction information 201 resides in various network devices and application servers such as routers, IP switches, and web servers, among others, from which it is collected by system 200. Each of the transaction information inputs 201 represent a different transaction input. Mediation agent components 203 of system 200 collect the network transaction information 201. Each source of network transaction information 201 has its own dedicated mediation agent 203. Mediation agents 203 also perform the task of reformatting network transaction information 201 into a known format of the subsequent
system component, rating engine 209; mediation agent components 203 transmit the information 201 to rating engine 209. There are a few network resources capable of sending network transaction information 201 directly to the system via direct access component 205, which, in turn transfers the network transaction information 201 received to rating engine 209. In addition, there are others applications (e.g., (1) a payment is processed through a third party payment processing software or 2) a customer care representative credits the customer due to a dispute on a specific billing charge, or 3) legacy systems, such as accounting software, import/export data to/from the system) which are capable of accessing the system components directly. Each of the network devices and application servers (from where information 201 is forwarded to system 200) needs to be configured to support the required services for each subscriber/user. Accordingly, provisioning engine 207 is dedicated for sending commands that enable or disable a service for a specific subscriber, and is programmed to be familiar with the network devices' APIs in order to perform that task. Rating engine 209 receives the network information 201 from mediation agents
203, and calculates the amount this transaction is charged for. Rules engine 211 manages pre-defined directives for the system 200 to be triggered in a determined state (e.g.. a two hour video stream is charged for 6$ - 3$ hour). These directives are supplied by an administrator of the system, and can include, disconnection of a low credit customer if he exceeds 100$ in the current cycle. Registration services program 213 is a web based application that allows prospective subscribers to register onto the system 200 and to purchase plans and products. Customer care and Self-care components 215 are web based applications that allow existing subscribers to perform various changes or updates
to their service offering or view their real-time balance or other parameters status. All of these tasks are made on-line and executed in real-time. The customer service department of the system 200 also uses customer care application 215 (with higher permissions) in order to service user's requests. Payment authorization program 217 enables authentication and authorization of credit card payments in order to validate payments as close as possible to the time of the services ordering. Authentication services program 219 authenticates the use of a specific service for a specific user/subscriber. In addition, authentication services program 219 makes the decision whether a user has the required credit to perform a specific task or use a specific service. Enforcement services program 221 performs real-time actions against the network elements, such as disconnecting a user in case of zero credit. Although enforcement services program 221 resembles provisioning engine 207, enforcement services program 221 is executed while the user session is active.
Invoicing program 225 is responsible for the billing process which aggregates all rated transactions, periodic charges (recurring charges) and one-time charges which occurred in a specified period. The final output of the invoicing program 225 are bills to be paid by the subscribers. Accounts receivable program 227 handles payments, adjustments, refunds, transferring amounts between bills and resolving disputes. Offline reports program 229 provides the administrator of the system 200 with the opportunity to create and print periodic reports on financial data, system data, and actions which have occurred in the system.
Relational database management system (RDBMS) 232 holds the application and reference data of the system 200 for archival, query and batch processing. For example,
reference data resides in static entities which are not changed during usage processing including: customer details, pricing objects, invoicing templates, etc. On the other hand, application data is accumulated during the system usage processing and includes customer rated sessions, produced invoices, etc. Database 232 is in electronic communication with invoicing program 225, accounts receivable program 227 and offline reports program 229. Those programs provide updates to database 232 and query database 232 (at predetermined intervals) for the information required to perform the invoicing, accounts receivable and reporting functions. The engines and programs of layer 240 also provide updates to and queries of database 232 as described above. System "state cluster" 23 has two components which facilitate real-time billing, account current status component 234 and the dynamic table of events 236. Specifically, while a user has an active session, account current status component 234 holds (stores) the user's identifying parameters as well as the service rating parameters. Together with the dynamic table of events 236, described below, the state server 235 acts as the point of authority for the user data instead of the customer database 232.
Dynamic table of events 236 stores a set of selected rules for users who have a session active. Rules are added to this component, being taken from rules engine 211, based on a mathematical calculation on the rules parameters, the session characteristics, the account current status and the user rating parameters. When rule requirements are met and a rule is triggered, the current state of the session is tested to determine whether it meets the rule requirements. Specifically, if the state meets the rule requirements, the rule action will be triggered. If not, the rule will be recalculated and inserted back into
the table 236. Rules specific for a customer are deleted from the table 236 when the session ends.
FIG 3 shows the data flow performed by the state server 300. Specifically, a subscriber session starts, step 301, and triggers the action of state server 300, the state server now becoming the point of authority for the user between the session start time 301 and the session end time 315. In response to the session start 301, the state server 300 creates a current account status 303. State server 300 queries database 332 for the user details and rating parameters in order to update account current state table 334. In addition, all user's rules are fetched, step 305, and a calculation is made, step 307, for each and every rule. Rules calculation 307 predicts the rules triggering time according to the session parameters, the user's rating parameters and the rule itself. This calculation derives a record in the dynamic table of events 336 with a future predicted time to be executed.
Timer 309 represents a system event that occurs when a rule triggering time comes. When such an event occurs, the triggered rule is taken from the dynamic table of events 336 and a rule evaluation, step 311, is performed. During rule evaluation, one of two scenarios may occur. The first scenario is that the evaluated rule terms do not meet the rale requirements. In this case, the rule time is calculated again and state server 300 updates dynamic table of events 336 with the new time. The second scenario is that the rule requirements are met. Only then is the rule triggered and state server 300 sends an event, step 313, to the system in order to execute the rule. The last step in this case is that the rule is then deleted from the dynamic table of events 336.
When the session ends, step 315, the state server task is terminated for the user who made the session (unless another session is opened for this user). The session end, step 315, terminates, at step 317, the user's account current status records in table 334 and also terminates the rules, step 319, from dynamic table of events 336. This action calls off the state server from being the state of authority for the user and transfers the point of authority to database 332.
Additionally, there are cases in which a rule is added to the system, step 321, while state server 300 is the point of authority for a user status. In this case, the added rule must be calculated, step 307, and entered in the dynamic table of events 336.