...
Once new data arrives, the mediation engine will execute configured logic to parse the data fields and assemble a UDR record.
...
After rating, applicable taxes are computed on the amount. Finally bucketing is performed to account for any special promotions, free usage or discounting that might apply.
Rating Engine Configuration
In order to perform rating, a rate plan needs to be created. The rate plan itself doesn’t define the rates. All it does is define the container for rate groups. Rate groups are what define the rates. A rate plan can contain multiple rate groups, each with their own rate plan.
Furthermore, conditions can be imposed on the rate group for assigning different rates based on conditions: as an example it is common to charge a higher rate for peak hour service and a lower rate for off peak times. The actual rate is encapsulated in a UDR rate structure. The figure below illustrates the relationship between a rate plan, rate groups, conditions and UDR rates.
...
Rate Plans
The rate plan is basically the plan that the customer signs up for. It is essentially a container for one or more rate groups. A rate plan can be assigned to a service, a package an account or an owner. The order of precedence is from the lowest to highest level: service, package, account, owner.
...
One or more rate groups can be associated with a rate plan as shown in the figure above. When viewing rate plan summary information, LogiSense will display references to the rate groups associated with that plan.
Rate Groups
A Rate Group defines the umbrella under which a rate applies. For example, in the telecom and UCaaS scenarios, different rates are applied to domestic vs. international calls. In such a scenario, a provider can define two rate groups: one for domestic and one for international. Furthermore, a provider may desire to charge a different rate for each group based on time period - for example, data usage during peak hours may be charged a higher rate than non-peak usage. Rate group conditions can be attached to each rate group to accommodate peak vs. non peak rates or other conditions that you wish to configure.
Usage Class
A Usage class identifies the type of usage that is going to be charged by the rating engine. Usage classes must be configured prior to creating rates. A Usage Class can have one of the following types:
...
Along with the data type, the class configuration also defines whether the rating is class based or GeoTree based. The major use of the GeoTree is for location or zone based service rating (i.e. telecom calls). Unlike most systems which have you simply enter a calling pattern (i.e. 1212) and associated rate, without any real understanding of where it is entered or structured, LogiSense allows you to get as granular as you like within a structured tree. For instance, you can define what actually makes up the calling patterns within a state, deploy rates based on zones, set top level rates (one price for the Continental US instead of having to define each individual pattern), setup rates by regions, types or operators (allowing you to specify a different rate based on which mobile operator's network the user is on).
Usage Rates
The Usage Rate defines the actual charge (amount) associated with a given class of usage that meets the conditions set within the rate group. The default behavior is that only one rate can apply to a given event record.
...
Rate Type | Definition |
|---|---|
Standard Rates | ($ value) x (event record value) |
Fixed Rate | $ regardless of event record value |
Markup | ($ value) x cost |
Fixed Markup | ($ value) + cost |
Usage Identifier
The event record Usage Identifier (UID) is a key component in the rating process. It is what ties an incoming event record to a given account service. A UID can be created per account service and is valid for the duration of that service. A UID must be unique for each instance of the service; when adding bulk quantities of a given service, distinct identifiers must be specified for each item to uniquely identify each usage based service.
Rerating
There are scenarios in which an administrator may wish to go back in time and recalculate the usage that occurred based on new parameters. This typically occurs in cases where there may have been a misconfiguration; for instance, a usage service should have been effective on the 5th day of the month as opposed to the 2nd day of the month. Bucketing effective day changes initiated after usage can been consumed can also require the admin to initiate a rerate mechanism.
...