Rating & Charging

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 a CDR record or it can take
the form of another type of usage feed. The usage data is supplied via API, SFTP or
other outbound methods as required. 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 custom logic to parse the data
fields and assemble a UDR record. The rating engine performs a lookup to determine a
matching Unique user identifier history (UUIH). This UUIH has a history of what service
and customer has owned that unique entity over time. Once a valid UUIH 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.
Usage events are classified into UDR classes. These define the type of event and units
of measure. The mediation process identifies the UDR class as well as the owner of that
usage by a configurable unique ID we call a Unique user identifier history (UUIH). This
UUIH has a history of what service and customer has owned that unique entity over
time. UDR 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 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 bucket, a tier in
a bucket, a service or a package. The order of precedence is from highest to lowest:
bucket, service, package. Rate plan inheritance is also supported, where a sub account
can inherit a rate plan configured at the parent. 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 UDR 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 the peak vs non peak rates.
UDR Class
A UDR class identifies the type of usage that is going to be charged by the rating
engine. UDR classes must be configured prior to creating rates. A UDR 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 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 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).

Rates
The UDR 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 UDR 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 (SMS 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 the following Types of Data:

1. Telephone Numbers
2. IP Addresses

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

Rate Type Definition

Standard Rates $ value x UDR value

Fixed Rate $ regardless of UDR value

Markup $ value x cost

Fixed markup $ value + cost

Unique User Identifier History (UUIH)

The UDR User Identifier History (UUIH) is a key component in the rating process. It is
what ties an incoming UDR to a given user service. A UUIH can be created per user
service and is valid for the duration of that service. A UUIH 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.