Rating Overview

Introduction

The OCS implements a rating engine framework that uses policies to calculate and apply the correct cost(s) for events when the engine is triggered through the engine API. The engine itself performs minimal rating functions, preferring to defer many decisions to pluggable policies that self select based on the criteria of the rating request.

The following high level processing is performed by the OCS rating engine for each rating request:

1. A rating request is received by the rating engine.
2. The rating request is validated.
3. The wallet for the rating request is retrieved.
4. The wallet’s policies, and all global policies, are identified.
5. All identified policies are triggered with the rating request information. Each policy identifies whether it wants to be involved in this rating request, and for what follow-on actions.
6. For all policies still involved, the OCS engine requests the rating details for the call. The policies are called in an order based on a policy order configured, and each policy accepts the previous policy data and may modify it. At this step each policy also gets to define/modify which buckets should be included in the rating from the wallet being rated.
7. Once the rating rule is selected, and the buckets to rate have been identified the OCS engine applies the necessary rating. Note that this step doesn’t call out to the policies.
8. Finally, if the necessary rating can be applied using any available buckets, the rating request has succeeded and the wallet is updated. If not, the wallet is left unchanged and the rating request fails.

Multi-Policy Processing

During a rating request multiple policies may apply to the call. This approach to rating allows the OCS engine to focus on a well-defined core processing flow while deferring rating decisions based on the context within which rating is occurring to pluggable modules of logic called policies.

Most rating will be performed by a key rating policy called the Location Based Rating Policy. This policy is responsible for the most frequent source -> destination rating usually applied to rating of usage in calls or data sessions.

Policy Order

As multiple policies may wish to apply their own logic to rate an event, the OCS engine must know the order in which policies are called. This policy order is configurable by defining a policy order value to each policy. The OCS engine then uses this for each group of policies it uses in rating.

Rating Process

Validation

Validation is performed by the HTTP API when a rating request is received.

Policy Selection

The OCS engine may have one or more global policies and each OCS wallet may have one or more policies associated with it.

To identify the policies to use for a rating request, each policy is in turn asked whether the policy may apply to the request.

Each policy then responds to the OCS engine with information on what processing steps it needs to be involved in.

The policy may also respond with an “end rating” indicator, allowing any policy to end rating immediately regardless of whether other policies would otherwise be able to rate the event.

This can be useful for fraud checks and similar global screening.

Example

A wallet may belong to a standard prepaid policy, and the system may have two other system-wide policies configured providing Friends & Family and Closed User Group - Business services.

A wallet may make a phone call to one of their family members listed in their Friends and Family policy details. Each policy will then determine whether the policy is appropriate for the event:

1. The Closed User Group policy identifies that the destination number is not in the group, and so does not request to be involved in the rating.
2. The Friends & Family policy identifies the destination number as a number that is in the wallet’s F&F list, and requests to be involved in the rating.
3. The Standard Prepaid policy identifies the source and destination number exists in the rating rules, and requests to be involved in the rating.

The OCS engine then calls out to both the F&F and standard prepaid policies at each processing step they agreed to be involved in.

Rating Rule Selection

For each policy still involved, the policy is called to retrieve the rating details to use. Rating details define:

• The conversions between units to allow/support for this rating request.
• The buckets to use.
• The order that buckets are to be used (via Groups and unit types)
• Discounts that may be applied when rated.

Policies chain, and so the input to one policy will be the output from the previous policy. This allows policies to adjust details as required.

This also means that as a general rule the order of policies run is from most general to most specific.

Buckets Selected

In most cases the buckets provided to the rating engine will come direct from the wallet, however policies may create buckets specific to this rating event.

This is useful for example in allowing a debit event to succeed even if the wallet does not have enough funds. See the Allow Overdraft policy.

Example

Continuing the previous example, the general rating policy is called first and returns:

1. The set of buckets that can be used based on its bucket cascade details associated with the source/destination number.
2. The bucket cascade.
3. A time to $ conversion ratio.

This information is fed into the F&F policy which then:

1. Adds in the F&F bucket group to the bucket list.
2. Alters the bucket cascade to set the F&F group as the first bucket group to rate with.
3. Adds a discount definition to discount all rated units by 10%.

Rating Calculation

The rating calculation is performed by debiting one or more of the wallet buckets listed by enough of the bucket value to cover the amount that the rating request requires.

This is done based on the rating conversions and discounts listed. The order buckets are debited from is based on the order provided by the policies.

Example

As an example, a rating request may attempt to charge 500Mb of usage, and a wallet may have these three buckets:

1. 40 minutes of time.
2. 250Mb of data.
3. $10

The 40 minutes of time is excluded as translation between time and Mb is not allowed by the rating policy.

The 250Mb of data accounts for half of the necessary units.

In this example the policy includes a rule that charges 1Mb at 1c and so in rating, the 250Mb not covered by the data bucket is covered by $2.50 from the dollar bucket.

After rating the wallet’s buckets are then:

1. 40 minutes of time.
2. $7.50

Rating Conclusion

The OCS will either find that all rating can be applied, or it cannot. It will update the subscriber wallet if it can, otherwise it will reject the rating request.

Each policy involved in the rating of the event will be called with details of the final rating outcome. The policies will then be able to perform any final data manipulation that they required.

Default Rating

The OCS may be deployed and used for simple rating scenarios with the minimum of configuration. The OCS does not require location hierarchies, services, subscriptions or ratesheets to function as a simple event charging system.

When running simple rating scenarios, the following rules apply:

1. The engine selects the buckets of the subscriber to rate against. When doing this, the OCS does not select any bucket with the “flag” unit type. The OCS also excludes any bucket with a “name” annotation. This default cascade may be overridden by ratesheets (if any are applied).

2. The OCS engine does not apply any unit conversions. Unit conversion may be applied by ratesheets, or by the rating request itself.

3. Without any policies in the system, no policy will be selected, and all buckets (that match the above rules) will be considered during rating. However, due to no inbuilt unit conversion existing, rating is likely to apply only against buckets where unit conversion is not required to rate.

Session Rating

The rating engine, as described previously, is used in the same manner for session based rating. However, unlike event based rating (or direct debiting), reservations made against wallets for each session are stored in the wallet and used to decrease the wallet’s balance for all other sessions. Once a session is complete, the wallet reservation is committed (up to the amount required by the session’s final confirmed units) and the session and reservation details are cleaned up.