Patent Application
20100312677
The invention relates to communication networks providing subscriber services, and specifically to a rating and charging engine for such networks.
A rating and charging engine determines how much a service (e.g. a phone call) costs, and deducts that cost from a subscriber's account. A high-performance real-time engine implements those operations before the service is delivered to the subscriber. If there are insufficient resources in the account then the service delivery does not occur, thus preventing revenue loss.
FIG. A shows the typical prior art architecture. Such a rating and charging engine repetitively executes steps such as the following:
From consideration of the examples given below, it will be apparent to someone skilled in the art that the problems arising from this structure are:
Even very simple requirements can lead to either unacceptable real-time performance due to large-scale provisioning operations, or alternatively to surprisingly complex rules.
For example, presume there are one million subscribers, and a subscriber is allowed to download three free ringtones on Saturday. Every subscriber's account contains a “free ringtone” resource that is stored in a persistent database. Changing its value imposes a system load equivalent to one service event, and takes 1 ms; provisioning operations have the same priority as service events. This can be achieved by either:
A major problem with approach (a) is that the rules are complex and so there is an unacceptably excessive elapsed time between the requirements specification and provisioning of the rules. A major problem with approach (b) is that there is an unacceptable delay with provisioning of the accounts because it is not possible to re-provision simultaneously all of the accounts at the desired point in time.
Another example is a simplified version of one network operator's unusual specific requirements, which illustrates how a combinatorial explosion can begin. Presume that network operator X is currently using standard rating and charging rules. Network operator Y requires the same rules but also has their own rules for valued subscribers:
Adding network operator Y:
That reasoning can be repeated each time a new network operator's requirements are defined, demonstrating that the rules' complexity is proportional to the number of network operators.
In another example, we illustrate how adding new service types can begin a combinatorial explosion. Consider adding a new type of service type, such as the ability to pay for ringtones. In general this will require:
That can be repeated each time a new service type is defined, demonstrating that the system complexity is proportional to the number of service types.
From the above examples it can be inferred that adding a new resource in general requires new rules for each network operator and each service type. Hence, complexity is also proportional to the number of resources. Thus, the overall system complexity is proportional to the product of service types, resources, and network operators.
The invention is therefore directed towards providing an improved rating and charging engine.
According to the invention, there is provided a communication network rating and charging engine comprising:
In one embodiment, each pot is an instance of a pot type. Preferably, each pot type is associated with a set of rating and charging rules. Also, each pot is preferably associated with a set of one or more resources defined by the pot's associated pot type.
In one embodiment, each resource is an instance of a resource type.
In one embodiment, the engine core is adapted to recognise service types, and each pot type contains separate rating and charging rules for each <service type, resource type> pair. In one embodiment, the engine core is adapted to generate a pot list in a priority order when performing a pot traversal operation, and for attempting to use the pots in the priority order.
In one embodiment, the engine core is adapted to receive a parameter value in real time. Preferably, the engine core is adapted to extract a parameter value from a service event.
In one embodiment, the engine core is adapted to retrieve a parameter value from a pot. A parameter value may be an attribute of a resource such as quantity. In one embodiment, the engine core is adapted to extract from a service event a value of a service type parameter. In one embodiment, the engine core is adapted to extract from a service event a value of a parameter representing service quantity. In another embodiment, the engine core is adapted to extract from a service event a value of a parameter representing service event time.
In one embodiment, the engine core is adapted to extract from a service event a value of a parameter representing source or destination address.
In one embodiment, the engine core is adapted to initially use a parameter value to exclude pots that it can determine cannot fulfil the service event, and to pass the service event or a parameter to non-excluded pots, and the pots are adapted to determine autonomously whether they can fulfil the service event and to inform the engine core accordingly.
In one embodiment, at least some pots include at least one parameter value indicating its suitability for particular, service types, and the engine core is adapted to use said parameter values during pot traversal.
In one embodiment, at least some pots include at least one parameter value for use by the engine core in determining a pot priority order.
In one embodiment, the rating and charging rules associated with at least two pot types are of different processing techniques. In one embodiment, the processing techniques include one or a combination of decision trees, look-up tables, polynomial equations, blackboard systems, forward chaining production systems, and backward chaining inference engines.
In one embodiment, at least some pots are remote routing pots adapted to automatically and autonomously forward a service event to an external rating and charging entity. Preferably, said pots include rating and charging rules that are sufficient to decide whether or not to forward a service event to an external rating and charging entity.
In one embodiment, the engine core is adapted to delay retrieval of pots with their resources and associated rules from the database until they are required.
In one embodiment, the engine core is adapted to, when a service event for an account is received, retrieve from the database to memory all of the account's pots with their resources and associated rules, if this account's pots are not already in memory.
In one embodiment, the provisioning system is adapted to provision accounts, pots, resources, or rules in real time when they are first required in performance of network services or at any convenient time in advance of it being possible for them to be used in performance of network services.
In another embodiment, the provisioning system is adapted to send a notification to the engine core when a change to the persistent database has been made.
In one embodiment, the provisioning system is adapted to delete pots in real time when it is first apparent that they can no longer be used in performance of network services or at any convenient time after they can no longer be used in performance of network services.
In one embodiment, the engine core is adapted to retrieve all of the rules to memory at initialization or whenever the rules are re-provisioned.
In another aspect, the invention provides a computer readable medium comprising software code for performing operations of an engine defined above when executing on a digital processor.
The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:—
Referring to
The provisioning system 4 creates, changes, and deletes accounts, pots, resources, and rules stored in the persistent database 3. The service supply entities 10 originate service events requesting authorisation to deliver services as specified by parameters in the service event. Henceforth, the term “service event” is used to mean any event or request which is received from the service supply entity 10. The rating and charging engine 1 processes the service events by performing rating and charging calculations, changing the state of the accounts, pots, and resources, and sending a service response specifying whether the delivery is authorised or denied.
A network interface of the core 2 interfaces to external service supply entities. In one example it uses the DIAMETER protocol to receive service events, and it unpacks and forwards the information contained in them to processing functions of the core 2. Some of the information in the service events are parameters used by the core 2 for real time rating and charging as described below. The core generates responses which are packaged by the network interface and it uses in this example the DIAMETER protocol to send the responses to the service supply entities. The persistent database 3 stores subscriber accounts, each account containing one or more pots, each pot containing one or more resources consumed during performance of a service by the network, and also stores rating and charging rules associated with the pots. The provisioning system 4 provisions the accounts, pots, resources, and rules in the persistent database 3. The engine core 2 generates the service responses by:
Operation of the engine 1 is illustrated in flow diagram form in
Examples of service supply entities, resources, events and parameters are given below.
In this specification the term “service types”, has its normal meaning in this art, examples including voice call, SMS delivery, parking ticket processing, ringtone download, and road toll processing.
There are one or more “service supply entities”. Examples of service supply entities in a telecommunications network include IN Service Control Points, SMSCs, MMSCs, and application servers. Other service supply entities could include road toll systems, parking ticket dispensers, or anything that can benefit from pre-delivery verification that sufficient funds are available.
The service supply entities generate both session-based and isolated “service events” and receive the corresponding service responses.
Examples of session-based service events are:
For example, a long voice call might therefore consist of an initial service request followed by more service requests to extend the call, followed by a service capture and a service release that completes the call.
The isolated non-session-based service events include “service debit”, requesting permission to deliver a quantity of a service type with no possibility of subsequently releasing part of the requested quantity. This is a higher-performance variant of a service request followed by a service capture.
There are one or more “accounts” per subscriber such as an individual child's account and a shared family account. Also there can be one or more subscribers per account such as a corporate account or a shared family account.
“Resources” are consumed in response to service events. Each resource has a specific type, such as financial currency, time, volume, number of messages, external currency (for promotions), ammunition (for a game), or a simple integer counter. The term “resource” includes resources which do not have an upper limit in the extent to which they are consumed, for example unlimited free SMS messages for a subscriber during a weekend, in which the resource is not consumed and may indeed have a zero value.
Also, the term “pot type” is used in this specification, meaning an object-oriented class which is instantiated to provide “pots”. A pot type defines for instances of its pot:
There are one or more “pots” per account, each pot being of a single pot type
Accounts, pots, resources and rules are stored in the persistent database 3. A pot's “charging rule” defines when and how resources are loaded from and stored into the persistent database 3. The rules are loaded into the rating and charging engine core 2 from the database 3 when the rating and charging engine 1 is initialised. Also, whenever a rule, an account, a pot, or a resource is changed by the provisioning system 4 a notification is sent to the core 2, triggering a re-load of some or all of these items.
Given a request for a quantity of a service type, a “rating rule” calculates the corresponding cost in terms of quantity of one or more resources. For each rating rule there is a corresponding “reverse-rating rule” which calculates the maximum quantity of a service that could be purchased for a given quantity of a resource.
“Remote routing pots” are specialised and simplified pots that only contain rating and charging rules sufficient to enable the system to delegate service events to external rating and charging entities.
The rating and charging engine 1 of the invention differs primarily from the prior art by having an advantageous architecture for management of the rules and resources. It significantly simplifies both the rules and the rule execution by:
The rating and charging engine 1 overcomes the “combinatorial explosion” limitation by reducing the complexity to the sum of service types plus network operators plus pots (including their associated resources). It simplifies provisioning operations by relaxing constraints on what is allowable. Most of the rating and charging rules are stored in the persistent database 3 with associations to the pot types, and hence each pot has it own set of rules. The core 2 merely executes pot traversal rules to efficiently determine which pots cannot fulfil a service event, thus immediately narrowing down the rule base to execute. This is very important for real-time performance, where there may be in excess of tens of thousands of service events per second arriving at the core 2.
This ensures many hitherto difficult requirements can be simply and rapidly implemented and provisioned, including arbitrary combinations of: cross-service bundles, single-purpose bundles, time and volume limited bundles, time and volume dependent costing (including loyalty scheme bonuses), external rating and/or charging (sometimes called a rating/charging router), individual network operator's unusual custom requirements. In addition, it enables implementation and provisioning of such features that are only defined after the first version of the product has been deployed.
Referring to
The remaining rules in the engine core 2 are common to all pot types. Service events (e.g. request, capture, release, debit etc) cause the ordered traversal of all pots in the account by a pot traverser until the event is either completely satisfied or cannot be satisfied. As part of that process, reservations are created, accounts are debited or reservations are deleted as appropriate.
An account may contain pots that cannot use their resources to fulfil a service event. As described below, individual pots calculate whether or not they can fulfil individual service events, but the complexity of that calculation can result in unacceptable loss of real time performance. The pot traverser initially quickly excludes pots that it can determine cannot fulfil the service event, based at least on:
For the non-excluded pots only, the pot traverser passes the service event to those pots and they determine whether they can fulfil the service event. This avoids unnecessary real-time performance loss arising from unnecessary calculations.
The invention makes it very easy to provision new pot types embodying complex network operator-specific requirements.
An account can contain one or more pot instances, each with an arbitrary pot type. Each pot type is an object oriented class containing methods specifying the rating and charging rules for that pot type. Each pot type contains separate rules for each <service type, resource type> pair. This ensures:
There is no restriction on the techniques used to define and implement the rating and charging rules, nor is there any requirement that all pot types use the same technique. Thus, different pot types might use:
A backward chaining inference engine starts with goals and hypotheses, and uses inference rules to determine if there are sufficient facts and data available to completely support the goals and hypotheses.
A forward chaining production system starts with the available facts and data, and uses production rules to determine the objectives and inferences that can be derived from the facts and data.
A blackboard system consists of an area of shared memory (the blackboard) that contains data and multiple independent pattern matching rules. Whenever new data is added to the blackboard, the rules are invoked to determine which patterns match the data. When matches occur, the rule signals a match and can add new data to the blackboard.
Each pot type specifies the number and type of resources contained by instances of such pots. Typically (but not necessarily) there is one resource per pot.
Each individual pot defines whether or not it can be used to fulfil a service event. The decision can be based on any relevant parameter or combination of parameters including (but not limited to):
If a pot can fulfil a service event, then the rules can take account of any relevant parameter or combination of parameters.
At least some of these parameter values can be included in received service events, and pot traversal may involve matching of these parameter values.
A pot can be a “remote routing pot” which forwards the service event to an external rating and charging entity containing the rating and/or charging rules. To avoid loss of performance, such pots may optionally include a subset of the total rating and charging rules. That subset is required to be sufficient to determine that the external entity will not take any part in fulfilling the service event, and hence there is no need to forward the service event.
A service event can be fulfilled by resources in one or more pots; each service event causing an ordered traversal of pots until the event has been fulfilled or there are no more pots (in which case the event is denied). In either case the service supply entity which originated the service event is informed of the result by sending a service response to the service supply entity.
The pot traversal order:
Once it is determined that a service event can be fulfilled, the relevant pots' resources can either be:
Regarding interaction with the persistent database 3, when an initial service event for an account is received, the engine core 2 typically retrieves all the account's pots and associated resources from the database 3. If, however, that would be too inefficient, then the engine core can choose to delay retrieving some of the pots/resources until they are required. Such “lazy loading” does not change the behaviour of the rating and charging engine, only its performance. Examples of lazily-loaded pots could be “remote routing pots”, or pots that are not valid at the time of the initial service event. At the end of a sequence of related service events such as a phone call, the engine core 2 stores the changed pots/resources back in the database.
Provisioning operations add pot instances to account instances and add or replace rules, for example in any of the following circumstances:
Such addition of pots can be either eager (i.e. before the pot becomes valid), or lazy (i.e. at the first time at which a pot could be used). A typical “eager addition” policy would be to schedule addition when the system is lightly loaded e.g. in the middle of the night. This flexibility considerably simplifies provisioning operations.
Provisioning operations may remove pot instances from an account for example in any/all of these circumstances:
Such removal can occur either eagerly (at the earliest possible time) or lazily (by marking the pot as “removable” and then removing it whenever convenient) without altering the system's operation. A typical “lazy removal” policy would be to schedule removal when the system is lightly loaded, e.g. in the middle of the night. This flexibility considerably simplifies provisioning operations.
Referring again to the flow diagram form in
Scenarios outlined below illustrate some examples of operation of the rating and charging engine of the invention.
This illustrates:
Consider a “StandardPrepaid” Pot Type with these rating and charging rules:
Consider a subscriber's account that contains a single StandardPrepaid Pot:
At a later date, after the rating and charging engine has been implemented and installed, the operator wants to stimulate usage of ringtones, and therefore introduces a new “RingtonePromotion” pot type with these rating and charging rules:
The existing “StandardPrepaid” pot type is unchanged, and existing “StandardPrepaid” pot instances are unchanged.
At any convenient time before the promotion starts the provisioning system 4 eagerly adds several instances of the “RingtonePromotion” pot to the account. Typically this would be scheduled to occur when the system load is low (e.g. early hours of a weekday), and the rate at which pots are added can be reduced sufficiently that real-time operation is not adversely affected. The account now contains pots
On Friday 4th at 10 am, a voice call starts, which causes the service supply entity to send a service request to the engine 1. The service type is “VoiceCall”, and the quantity is 60 s. The engine core 2 retrieves the account's pots from the persistent database 4 and using an “earliest expiry date first” pot traversal rule creates this ordered list of pots: [pot-1005, pot-8006, pot-9999, pot-10000, pot-456], and then iterates through the list:
Since the service request has been completely fulfilled, the engine core 2:
After 30 s the call ends, which causes the service supply entity to send a service capture to the engine 1. The service type is “VoiceCall”, and the quantity is 30 s. The engine core 2 traverses the ordered list and causes the reservation to be removed, pot-456's Pot Type's rating and charging rules to be invoked to discover that the cost was £0.05 and its balance resource to be set to £5.62. The engine core 2
On Sunday 6th, a Ringtone download is requested so the service supply equipment sends a service debit to the engine 1, with service type “Ringtone” and quantity 1. The engine core 2 creates the same ordered list and iterates through it:
The engine core 2:
On Sunday 6th, a second Ringtone download is requested so the service supply equipment sends a service debit to the engine 1, with service type “Ringtone” and quantity 1. The only difference is that pot-8006's balance resource is now reduced to 0, and pot-8006 and its balance resource are “eagerly” deleted.
On Sunday 6th, a third Ringtone download is requested so the service supply equipment sends a service debit to the engine 1, with service type “Ringtone” and quantity 1. The engine core creates the ordered list containing the remaining pots [pot-1005, pot-9999, pot-10000, pot-456], and iterates through it:
The engine core 2
During a convenient quiet period on the 10th, the provisioning system 4 scans some or all of the accounts and pots and discovers that pot-1005 still exists even though it is no longer valid. The provisioning system then “lazily” deletes the pot and its balance resource.
This illustrates how a remote routing pot interacts with an external rating and charging entity.
Consider a “BusinessPostpaid” pot type that is used to route relevant service events to an external postpaid billing and charging entity. The rating and charging rule is:
Consider an account containing:
An SMS is requested, so the service supply equipment sends a service debit to the engine 1, with service type “SMS”, destination 987601179017896, and quantity 1. The engine core 2 retrieves the account's pots from the database and using a “BusinessPostpaid pots have higher priority” pot traversal rule, creates this ordered list of pots: [pot-23, pot-456], and then iterates through the list:
The service debit has been completely fulfilled, so pot-456 is skipped and the engine core:
That sequence is illustrated in
In contrast, if the destination MSISDN had been 01179017896 then the above sequence would have been the same except that:
The invention is not limited to the embodiments described but may be varied in construction and detail. For example, the invention may be applied to networks other than mobile networks, for example fixed telephony or IP networks. For example, the service may be time of use of a WiFi network or number of bytes downloaded in an IP network. The service events may relate to services other than communication services, for example processing a parking ticket. Also, the invention is applicable to both pre-paid and also post-paid rating and charging systems and services.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IE2008/000096 | 10/6/2008 | WO | 00 | 8/12/2010 |
| Number | Date | Country | |
|---|---|---|---|
| 60960608 | Oct 2007 | US |
