Tariff System

In OSB the rating of network usage is separated from the handling of all other charges during billing. OSB uses tariff systems to define usage rates and to support the rating process. The latter handles the usage records streams and identifies the parties involved in a call, while the tariff system is responsible to determine the rate for a particular call and party.

A simplified model of how a tariff system works is as follows:

The configuration of a tariff system links a tariff to each pair tariff class - tariff period.
A tariff is a function that is able to convert the call volume(s) into money, i.e. the rate for a call.
Tariff class and tariff period are call attributes that are determined by the tariff system. Both of them are used to classify the network usage into groups for which the same tariff is valid.
The TariffPeriod describes the date and time of the call, typically "peak" or "off-peak".
The TariffClass describes which service was used and how the service was used. Prominent exemples in the GSM world are "National calls", "Sent short messages" or "High speed GPRS".
For every service that was used during a call, the tariff system determines the attributes tariff class and tariff period and delegates the rating to the tariff that is linked to this pair.

Diagram Simplified tariff system configuration

Responsibilities

Before entering the realm of tariff systems, we should briefly discuss the rating process so that we can understand the role the tariff system plays within the process:

Diagram High level view of rating process

For each usage record Rating performs the following steps:

Identify the usage scenario and every party involved in the call.
For each party: Validate the network usage and determine the tariff system that should be applied.
Forward the usage record to the tariff system, that calculates the rates for the call.

From the three above steps it should become clear, that the TariffSystem is responsible to determine the usage charges. Otherwise the rating has to identify the parties, validate the network usage by that party and to select the tariff system that should be applied for that party.

Example requirement

Before putting our focus on the classes that are neeed to construct a tariff system lets look at a sample tariff description (extracted from SwissCom's website):

Natel swiss
Mobile telephony			Rate
	Calls to Swisscom numbers		¹⁾
		Normal tariff	0.59
		Low tariff	0.40
		Night & Weekend tariff	0.20
	Calls to other national operators		¹⁾
		Normal tariff	0.79
		Low tariff	0.53
		Night & Weekend tariff	0.20
	Calls to country group 1 Germany, France, Great Britain, Italy, Kanada, Austria, USA		¹⁾
		7 days, 24 hours	0.60
	Calls to country group 2 Australia, Belgium, Finnland, Grece, Ireland, New Zeeland, ...		¹⁾
		7 days, 24 hours	0.80
	All other international calls		¹⁾
		7 days, 24 hours	4.00
WAP service			¹⁾
		7 days, 24 hours	0.20
Short Messages
	incoming		free
	outgoing, per message		0.20
Swiss Free Call (0800)			free
Business Numbers (08XY...)
	Operator charge + Surcharge per minute		0.30
Supplementary services
	call forwarding, call hold, call wait, call barring, ...		free

¹⁾ Rates are per minutes, charged in intervals of 0.10 (partial or complete).

Tariff times
Normal tariff	Mon - Fri, 07:00 - 19:00
Low tariff	Mon - Fri, 06:00 - 07:00, 19:00 - 22:00
Night & Weekend tariff	all other times incl. public holidays

Tariff system classes

Diagram provides an overview of the classes that are used to build up a tariff system. The classes are designed with the following goals in mind:

Flexible	The internal structure of a tariff system must be able to adapt to future requirements. At the beginning of this section I have already introduced the most important design decision to achieve this: A tariff system assigns a tariff to every pair <tariff class, tariff period>. This abstraction allows OSB to rate any network usage for which appropriate classification rules can be defined.
Modular	A tariff system should consist of building blocks with minimal dependencies amongst each other. This not only eases their construction and validation, but also allows to use the same blocks in several tariff systems.
Reproducible	Usage charges must not depend from the time at which the calls are actually rated: The calculated usage charges should remain the same, no matter if rating is done immediately after the call or two weeks later.
Adjustable	Adjustments in the configuration of a building block should be possible without need to change the tariff objects that depend on the changed module. Changing off-peak time, e.g., does not affect how much is charged for an off-peak call; common sense tells us that there shouldn't be a need to release a new version of all tariff systems using peak and off-peak times.

Diagram Overview tariff system

The discussion of diagram describes the tariff object classes and introduces the construction principle of tariff systems. For this I'm using a top-down approach, i.e. I assume that all building blocks are ready for use. In real life of course we'd first have to create the individual modules before using them for the construction of higher level entities.

A TariffSystem defines the charges for network usage. The services that are rateable by the tariff system are determined by the ServiceClassGroup choosen in the first configuration step of the tariff system. A service class group is a set of ServiceClass each of which contains one or more Service¹. This design allows to share service classes amongst different service class groups.
The second configuration step of a tariff system selects a tariff classification system for each service class.
TariffClassSystem has to determine the TariffClass of a usage record.
In the third configuration step the user select a tariff period group for every possible tariff class.
TariffPeriodGroup uses a call's timestamp to determine the TariffPeriod.

Design notes

We have choosen this design to achieve better maintainability: A different approach would be to add each individual service to a service class group and to specify its service class at the same time. This however would require that several service class groups must be changed if a service is added or deleted.

In the moment it not clear yet, how the rating scenario can be used within the tariff system to determine the tariff that is to be applied.
We have to avoid that any of the entities in diagram III reacts "hardcoded" to the rating scenario, because such an implementation prevents the extensibility that we want to achive.
If we want to keep the current specification that the tariff depends on the tariff class and period only, then the most suitable place to incorporate the rating scenario is in the service class.

Definitions

This section provides a definition for each class in diagram III:

class	definition
TariffSystem	A tariff system defines the tariff for the network usage. It contains a consistent set of tariff objects.
ServiceClassGroup	A group of ServiceClass.
ServiceClass	A group of one or more usage services.
Service	A kind of network usage. It describes how a network can be used or how it was used.
TariffClassSystem	A set of TariffClass and a rule (or framework of rules) that selects exactly one of its TariffClass for a given call. In the next section we'll discuss a TariffClassSystem type that is able to support distance sensitive rating.
TariffClass	A call attribute that -together with the TariffPeriod- defines which Tariff is applicable for a given call and ServiceClass.
TariffPeriodGroup	A set of TariffPeriod that completely contains the calendar year and defines a TariffPeriod for the complete 24 hour period of every day.
TariffPeriod	Describes a part of one calendar day during which the a same Tariff is applied.
SwitchTime	Defines the time from which on a Tariff is applied.
DayClass	A group of one or more SpecialDate and WeekDay. Within a TariffPeriodGroup a DayClass must be defined for every WeekDay. The DayClass, of the SpecialDate overrules the DayClass of the corresponding WeekDay.
SpecialDate	A particular (recurring) date of the year. Only one DayClass may be assigned to a given distinct date.
WeekDay	A day of the week: Sun, Mon, …, Sat.
Tariff	A set of RatingFunction that defines the rating of the network usage for a given TariffClass and TariffPeriod.
RatingFunction	A rule how to rate the volume of a call. Rating functions may be specialized to rate for a distinct unit only. This specialization is needed to handle services that can be measured in multiple units, e.g. data services in bytes and/or seconds.

Tariff class systems

This section describes the tariff class systems that are supported by OSB. The task of tariff system class is classify the usage records into classes for which the same tariff period group is used to determine the applicable tariff. In principle the classification may be based on all available call attributes, though each type of tariff class system will use a distinct, well defined set. A tariff class system that supports transmission speed sensitive rating of data services uses the call attribute Quality of Service Mean Throughput to select one of the tariff classes low transmission rate, normal transmission rate and high transmission rate.

Intentionally I did not provide any values for low, normal and high transmission rate:
A reasonably well designed tariff class system must allow to the user not only to configure the criteria but also define an arbitrary number of tariff classes.

In technical terms a TariffClassSystem is an abstract base class that defines the following functionality:

It is able to determine the TariffClass for a given usage record.
It can list the finite set of tariff classes that may result from such a classification.
It can check its correct configuration: Completeness and uniqueness.

The advantage of this abstraction is obvious: OSB can easily be extented to use any call attributes as criteria for rating. It does not matter how complex the rules and configuration for a new type of tariff class system are, as long as the type is able to come out with a TariffClass for a usage record it can be used for the construction of tariff systems.

Tariff zone groups: distance sensitive rating

Version management

In order to achieve reproducibility and to insure consistency among the blocks OSB maintains different versions of the tariff system modules.

Configuration status

The live cycle of a tariff system object is show in diagram

Diagram Status of tariff system building blocks

	Status changes: allowed transition for TS objects
	+ Reproduction time + Ranking of configuration statuses: released > testing > standby > editable
Rule 1	The status of tariff system object can be decreased only if no tariff objects that depend on the changed object with a status higher than the target status exists.
Rule 2	Try to find a global definition for "depend"!

Consistency

For a successful check of a tariff system, the following conditions must be fulfilled.

The status of all objects on which the tariff system depends on, must be freezed.
Exactly one service class group is assigned to it.
For each service class that is part to this service class group, one tariff classification system is selected.
For every tariff class, that belongs to any of these classification systems, one tariff period group is assigned.
For every pair <tariff class, tariff period> one tariff is defined.

A tariff period group is consistent if:

All tariff periods used by the group are in status freezed.
Every day of the week belongs to exactly one of the day classes used within the group.
For every day class of the group the switch-over time 00:00 is defined.
Within each day class a switch-over time only exists once.

Versions and revisions

For the following tariff system classes multiple versions are supported: TariffSystem, TariffPeriod, TariffPeriodGroup, TariffZoneGroup, TariffZone,

BELOW HERE UNDER CONSTRUCTION

The rating of a call depends on it's TariffClass and TariffPeriod. The TariffClass depends always on the ServiceClass and, for distance and routing sensitive routing, on the TariffZone.

The TariffSystem defines a tariff for every tupel <TariffClass, TariffPeriod>. The TariffClass is a set of ServiceClass or TariffZone.

The ServiceClass of a call is determined by the used service and service specific attributes, e.g. the transmission rate for a data service.

The TariffZone is obtained from the distance and routing relevant call parameters.

The TariffPeriod is reflects the date and time the call was made.

The three classes ServiceClassGroup, TariffZoneGroup and TariffPeriodGroup support the administration and the validation of a tariff system. Each of these classes defines the usage record attributes that are used to classify a call and the classes must ensure that this classification is unique and complete.

For the network service Telephony sub-service classes exist, e.g. international calls. The subclass can be determined only by evaluating additional call attributes. Tariff classification systems have this capability: We could use the tariff class to subclassify a service. Using this approach would then mean that the product item service must be changed accordingly.

Example resolution

Before we explain and define each tariff system classes let's take the SwissCom example from above and see how it maps to the OSB definition of a tariff system. The relation is given in the table below:

Class

Entity names

Comments

TariffSystem

Natel swiss

other tariff systems of SwissCom are: Natel budget, Natel business, ...

ServiceClassGroup

GSM services

ServiceClass

Telephony

WAP

SMS incoming

SMS outgoing

all suppl. services

TariffZoneGroup

Telephony

TariffZone

SwissCom

National

Country group

TariffClass

Relation to product

For a given network type a tariff system must at least cover all usage services that are available in a product:

Diagram relationship between a product and tariff systems

The sample product shown in diagram offers GSM and wireline services. For both network types a tariff system must be part of the product.