Distance sensitive rating
This section describes the OSB concepts and abstractions to support a flexible distance sensitive rating of the network usage. The discussion of the usage scenarios shows that it depends on the rated party and type of network usage, which CDR attributes should be used as origin and destination during rating.
One of the key concepts used in distance sensitive rating is to model a connection between two subscribers by means of connection points. The connection between subscriber A and B in diagram can be described by a sequence of the points: A party - switch 1 - switch 2 - B party.
Connection points are an abstraction for everything that one might consider as point of a connection, such as:
Each of these entities has an attribute that identifies its assigned connection point. This mapping makes it possible to base all distance sensitive rating on one generic tariff classification system, that uses pairs of connection points as origin and destination to determine the tariff class.
As shown in diagram
specialized mapping TCS identify the connection point
of the CDR attributes that should be used as origin and destination
for a give usage type and rely on the assigned generic
TCS to determine the tariff class.
This construct not only reduces the amount of needed configuration data but also ensures that new objects can be used as rating criteria without changing the core logic.
As an example, consider an outgoing call to a foreign network:
For the A subscriber the usage is rated using its location as origin, while for the PSTN the origin is the gateway switch G. For both ratings, the destination is the B-party number. Because we can assign a connection point to the A-party location and the gateway switch, the same generic tariff classification system may (but need not) be used.
|origin||=||A-party location||=||connection point 4|
|destination||=||B-party number||=||connection point 27|
|origin||=||gateway switch G||=||connection point 4|
|destination||=||B-party number||=||connection point 27|
A connection point is abstraction for everything that can be
identified as a point in a network connection. This can be real
existing objects, but also conceptual entities, e.g. the voice mail
box or the home location of a subscriber.
Connection points have a tree-like structure where, at a given moment in time, each connection point has exactly one parent and multiple children. In order to model Switzerland networks, one might set-up the following hierarchy:
There is one important requirement, that we need to consider
when designing the structure and relationship of connection points:
It must be possible to make adjustments to the hierarchy. This
mainly means that new points can be inserted into the hierarchy,
but whenever possible we should support deletion too.
At the same time we allow for changes, we have to insure that rating is reproducible. This means that the structure of the connection point tree must allow to determine a connection point's parent for a given time. The relevant members of ConnectionPt are shown in diagram
The most interesting member of ConnectionPt is getParent(DateTime ts): If at ts the status of the connection point is released, the function returns the parent that is released at ts. If the connection point is a root or if it is not released at time ts, an empty connection point id is returned.
A connection point that is root can always released for production. A non-root connection point must fulfill the following conditions:
As long the avove condition is fulfilled, connection points can be added to the hierarchy at any time. In order to delete a connection point, its status must be editable. Once a connection point is released to production, its status may be changed to standby (and subsequently to editable) only if the reproduction time has passed.
The rule(s) and procedure how a CDR attribute is mapped into a
connection point is class specific. E.g., a CGI as provided in the
CDR consists of four parts (MCC-MNC-LAC-CI); it is matched against
the list of configured Cgi's by first checking for an exact match,
and then removing part by part until a match is found. For network
elements the connection point is simply is corresponding data
The mapping into connection points has a side-effect that should be mentioned here: Connection points define the finest grid where user-defined, symbolic names can be given to real existing objects.
2) Currently OSB does not support hierarchical networks.
The mapping of connection points is not hard-coded. Specialized classes -all derived from a common base classs-, are responsible for this. Their only task is to determine the connection point for the CDR attribute they are specialied to; and they can collaborate with other tariff objects to fulfill their job:
In diagram the class Cgi2Cp implements the pure virtual function CpMapper::getCp() by extracting the CGI from the CDR and delegation to CgiList, the list of configured CGIs.
The generic distance sensitive tariff classification system determines the tariff class for a pair of connection points that represent the origin and the destination of a network connection.
GenericDistTcs consists of one or more tariff zones and assigns a tariff class to each of them. The tariff zones support the modularity of tariff systems, in order to understand how the tariff class is identified, we can assume that such a TCS assigns a tariff class to each pair of connection points that is contains. Diagram provides more details on the logical structure.
For the determination of the tariff class for the pair <mappedOrigin, mappedDestination>, GenericDistTcs gives priority to the destination. From the list of all pairs <origin, destination> that are part of the TCS, the algorithm selects the matched pair that fulfills the following conditions:
|I||The matched pair is active at the time of the usage.|
|II||The destination of the matched pair is the mappedDestination itself or its nearest ancestor.|
The origin of the matched pair is the mappedOrigin itself or its nearest ancestor.
The TCS needn't contain the catch-all entry <catch-all, catch-all>, an appropriate error is generated if no valid match could be found.
The following example for the matching rule of a generic distance sensitive TCS does not discuss the validity periods of the tariff zone configurations and the connection point hierarchy. Instead the example emphasizes how the parent-child relationship of the connection points is used to find the nearest destination and origin in its configuration.
The connection point hierarchy is given in table and the configuration entries of the generic TCS are shown in table (tariff zone omitted).
The following matches will be found:
Discussion of table
The pair<mappedOrigin, mappedDestination> is found in the configuration of the TCS.
For the mappedDestination "112" only its parent "11" is configured in the TCS. From the two related origins "1" and "11" the latter is selected because it is the nearer ancestor of the mappedOrigin "111".
For the mappedDestination "2" the TCS contains 2 pairs. Only one of the two related origins, namely "0", is an ancestor of the mappedOrigin and therefore selected.
A generic distance tariff classification system is consistent and can be released for production, if:
Mapping tariff classification systems are designed to support a flexible and extensible configuration of the usage attributes to be used during rating, i.e., for the determination of the tariff class.
The configuration of MappingDistTcs has two parts. On the left side of diagram the class selects for each usage type a CpMapper that will determine the mappedOrigin and a CpMapper that determines the mappedDestination. The right side shows the generic distance sensitive TCS to be used by the MappingDistTcs afterwards.