RALs is a standalone subsystem within CGRateS designed to handle two major tasks: Rating and Accounting. It is accessed via CGRateS RPC APIs.
Rating is the process responsible to attach costs to events.
The costs are calculated based on the input data defined within TariffPlans in the following sections:
Binds the event via a fixed number of fields to a predefined RatingPlan. Configured via the following parameters:
- The tenant on the platform (one can see the tenant as partition ID). Matched from event or inherited from JSON configuration.
- Freeform field used to “categorize” the event. Matched from event or inherited from JSON configuration.
- Rating subject matched from the event. In most of the cases this equals with the Account using the service.
- Date and time when the profile becomes active. There is no match before this date.
- Identifier of the RatingPlan assigned to the event.
- List of rating subjects which will be searched in order in case of missing rates in case of defined RatingPlan. This list is only considered at first level of iteration (not considering FallbackSubjects within interations).
One RatingProfile entry is composed out of a unique combination of Tenant + Category + Subject.
Groups together rates per destination and relates them to event timing. Configured via the following parameters:
- The tag uniquely idenfying each RatingPlan. There can be multiple entries grouped by the same ID.
- The identifier of the DestinationRate set.
- The itentifier of the Timing profile.
- Priority of matching rule (DestinationRatesID*+*TimingID). Higher value equals higher priority.
Groups together destination with rate profiles and assigns them some properties used in the rating process. Configured via the following parameters:
- The tag uniquely idenfying each DestinationRate profile. There can be multiple entries grouped by the same ID.
- The identifier of the Destination profile.
- The identifier of the Rate profile.
Method used to round during float operations. Possible values:
- Upsize towards next integer value (ie: 0.11 -> 0.2)
- Round at middle towards next integer value (ie: 0.11 -> 0.1, 0.16 -> 0.2)
- Downsize towards next integer (ie: 0.19 -> 0.1).
- Number of decimals after the comma to use when rounding floats.
- Maximum cost threshold for an event or session.
The strategy used once the maximum cost is reached. Can be one of following options:
- Anything above MaxCost is not charged
- The session is disconnected forcefully.
Groups list of prefixes under one Destination profile. Configured via the following parameters:
- The tag uniquely idenfying each Destination profile. There can be multiple entries grouped by the same ID.
- One prefix entry (can be also full destination string).
A Rate profile will contain all the individual rates applied for a matching event/session on a time interval. Configured via the following parameters:
- The tag uniquely idenfying each Rate profile. There can be multiple entries grouped by the same ID.
- One time charge applying when the session is opened.
- The rate applied for one rating increment.
- The unit raported to the usage received.
- Splits the usage received into smaller increments.
- Activates the rate at specific usage within the event.
A Timing profile is giving time awarness to an event. Configured via the following parameters:
- The tag uniquely idenfying each Timing profile.
- List of years to match within the event. Defaults to the catch-all meta: *any.
- List of months to match within the event. Defaults to the catch-all meta: *any.
- List of month days to match within the event. Defaults to the catch-all meta: *any.
- List of week days to match within the event as integer values. Special case for Sunday which matches for both 0 and 7.
- The exact time to match (mostly as time start). Defined in the format: hh:mm:ss
Due to optimization, CGRateS encapsulates and stores the rating information into just three objects: Destinations, RatingProfiles and RatingPlan (composed out of RatingPlan, DestinationRate, Rate and Timing objects).
Accounting is the process of charging an Account on it’s Balances. The amount of charges is decided by either internal configuration of each Balance or calculated by Rating.
Is the central unit of the Accounting. It contains the following fields:
- The tenant to whom the account belogs.
- The Account identifier which should be unique within a tenant. This should match with the event’s Account field.
- The pool of Balances indexed by type.
- Usage counters which are set out of thresholds defined in ActionTriggers
- Allows authorization independent on credit available.
- Set on each update in DataDB.
- Marks the account as disabled, making it invisible to charging.
Is the unit container (wallet/bundle) of the Account. There can be unlimited number of Balances within one Account, groupped by their type.
The following BalanceTypes are supported:
- Coupled with voice calls, represents nanosecond units.
- Coupled with data sessions, represents units of data (virtual units).
- Coupled with SMS events, represents number of SMS units.
- Coupled with MMS events, represents number of MMS units.
- Matching all types of events after specific ones, represents generic units (ie: for each x *voice minutes, y *sms units, z *data units will have )
- Matching all types of events after specific ones, represents monetary units (can be interpreted as virtual currency).
A Balance is made of the following fields:
- Unique identifier within the system (unique hash generated for each Balance).
- Idendificator configurable by the administrator. It is unique within an Account.
- The Balance’s value.
- The expiration time of this Balance
- Used to prioritize matching balances for an event. The higher the Weight, the more priority for the Balance.
- List of Destination profiles this Balance will match for, considering event’s Destination field.
The rating subject this balance will use when calculating the cost.
This will match within RatingProfile. If the rating profile starts with character *, special cost will apply, without interogating Rating for it. The following metas are available:
- A *zero followed by a duration will be the equivalent of 0 cost, charged in increments of x duration (ie: *zero1m.
- Points out to default (same as undefined). Defaults are set to *zero1s for voice and *zero1ns for everything else.
- List of event Category fields this Balance will match for.
- Pointing towards a shared balance ID.
- List of Timing profiles this Balance will match for, considering event’s AnswerTime field.
- Makes the Balance invisible to charging.
- Used in case of of *generic BalanceType to specify the conversion factors for different type of events.
- A blocking Balance will prevent processing further matching balances when empty.
Is a mechanism to monitor Balance values during live operation and react on changes based on configured thresholds and actions.
An ActionTrigger is made of the following attributes:
- Identifier given by the administrator
- Per threshold identifier
Type of threshold configured. The following types are available:
- Matches when the Balance value is smaller.
- Matches when the Balance value is higher.
- Matches if Balance is expired.
- Consider smaller aggregated values within event based on filters.
- Consider higher aggregated values within event based on filters.
- Consider smaller Balance aggregated value based on filters.
- Consider higher Balance aggregated value based on filters.
- The value of the threshold to match.
- Execute ActionTrigger multiple times.
- Sleep in between executes.
- Time when the ActionTrigger will expire.
- Only consider the ActionTrigger starting with this time.
- Filters selecting the balance/-s to monitor.
- Priority in the chain. Higher values have more priority.
- Action profile to call on match.
- Avoid false positives if the number of items hit is smaller than this.
- Marks the ActionTrigger as executed.
- Time when the ActionTrigger was executed last.
Actions are routines executed on demand (ie. by one of the three subsystems: SchedulerS, ThresholdS or ActionTriggers) or called by API by external scripts.
An *Action has the following parameters:
- ActionSet identifier.
The type of action to execute. Can be one of the following:
- Creates an entry in the log (either syslog or stdout).
- Reset the matching ActionTriggers
- Creates a CDR entry (used for example when automatically charging DIDs). The content of the generated CDR entry can be customized within a special template which can be passed in ExtraParameters of the Action.
- Set the recurrent flag on the matching ActionTriggers.
- Unset the recurrent flag on the matching ActionTriggers.
- Set the AllowNegative flag on the Balance.
- Unset the AllowNegative flag on the Balance.
- Re-init the Account by setting all of it’s Balance’s Value to 0 and re-initialize counters and ActionTriggers.
- Reset the Balance matching the filters to 0 and add the top-up value to it.
- Add the value to the Balance matching the filters.
- Reset the Balance matching the filters to 0 and debit the value from it.
- Debit the value from the Balance matching the filters.
- Reset the Balance counters (used by ActionTriggers).
- Unset the Account Disabled flag.
- Set the Account Disabled flag.
- Post data over HTTP protocol to configured HTTP URL.
- Post data over HTTP protocol to configured HTTP URL without waiting for the feedback of the remote server.
- Send data to configured email address in extra parameters.
- Update list of prefixes for destination ID starting with: *ddc out of StatS. Used in scenarios like autodiscovery of homezone prefixes.
- Removes the matching account from the system.
- Removes the matching Balances out of the Account.
- Set the matching balances.
- Transfer the value of the matching balances into the *default one.
- Call a CGRateS API over RPC connection. The API call will be defined as template within the ExtraParameters.
- Set the the matching balances to topup value if they are negative.
- Set the ExpirationDate for the matching balances.
- Publish the Account and each individual Balance to the ThresholdS.
- Publish the matching Balances to the ThresholdS.
- Removes entries from the StorDB.session_costs table. Additional filters can be specified within the ExtraParameters.
- Removes expired balances of type matching the filter.
- Creates the account out of last CDR saved in StorDB matching the account details in the filter. The CDR should contain AccountSummary within it’s CostDetails.
The RALs is configured within rals section from JSON configuration via the following parameters:
- Will enable starting of the service. Possible values: <true|false>.
- Connections towards ThresholdS component, used for Account notifications.
- Connections towards StatS component, used for Account ralated metrics.
- Connections towards CacheS used for data reloads.
- Enabling prefix matching for rating Subject field.
- Enable automatic removal of expired Balances.
- Prevent usage rating calculations per type of records to avoid memory overload.
- The maximum number of increments generated as part of rating calculations.
- Default rating subject for balances, per balance type.
- Classic rater calculating costs for events using Rating.
- Account bundles for fixed and mobile networks (xG) using Accounting.
- Volume discounts in real-time using Accounting.
- Fraud detection with automatic mitigation using ActionTriggers.