Usage & Rating

LogiSense has a powerful rating and mediation engine that can rate any type of usage event in real time or batch. Usage data can take the form of an event record in a usage feed. The usage data records can be supplied either via an SFTP file upload or by API. Because each record will have its own proprietary format, a mediation layer is designed for each solution to format the data into a Usage Data Record (UDR) that can be processed by the rating engine.

Once new data arrives, the mediation engine will execute configured logic to parse the data fields and assemble a UDR record.

The rating engine performs a lookup to determine if a matching Usage IDentifier (UID) exists which is a unique record assigned to a service (e.g. an IMSI, phone number, mac address, etc.) that has been added to an account which will be billed for this type of data. This UID maintains a history of which service and customer has owned the unique entity over time.

Once a valid UID is determined, the rating engine determines the matching rate group based on location, time period and other characteristics that might be set. The rate is determined from that rate group. Once a rate is determined, the rating is computed on that UDR.

Open

Usage events are classified into UDR classes. These define the type of event and units of measure. The mediation process identifies the Usage Class as well as the owner of that usage by the configurable usage ID (UID). Usage Classes can be configured to represent any measure of usage including storage, time, IO, bandwidth, transactions, and units.

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 rates.

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.

Open

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.

Rate plan inheritance is also supported, where a child account can inherit a rate plan configured at the parent level. A rate plan is defined by a name. Each rate plan configuration also defines the level of precision used by the rating engine when processing charges associated with that plan; LogiSense supports up to 11 places of precision.

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:

• Time: the time field specifies duration in days, hours, min, sec

• Data: Data in KB, MB, GB or KiB, MiB, GiB (KB = 1000 Bytes, KiB = 1024 bytes)

• Count: to specify a number of times that something happens

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 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.

When looking for a rate, the rating logic will determine the appropriate rate plan associated with that usage. As explained previously a rate plan may contain multiple rate groups based on rate group conditions the rating engine will choose a rate group that matches the given conditions. A rate group can contain one or more rates once again subject to conditions such as the class of usage (Data vs. API vs. Voice) and location groups. Once the correct rate is determined, the system will apply that rate to the usage being rated and calculate the charge.

Rates are configured and associated to GeoTree locations or patterns. The GeoTree can hold different types of locations. Some examples of location identifying patterns are:

1. Telephone Numbers

2. IP Addresses

Different types of rates are supported as shown in the table:

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.

For UDR records that are flagged for re-rating, the system reverses all charges made as a result of the initial rating process before starting rating again. Rerating returns bucketed amounts back to their respective buckets before starting rating again. Rerating of usage has high overhead requirements and should not be initiated without thinking through the performance implications. Ideally administrators should initiate configuration changes with a view to minimizing the potential for rerating usage.