Rating: Usage scenarios

This document describes the different scenarios of network usage and OSB expectations with respect to CDR generation in order to insure their correct rating.

This document aims to answer the following questions:

In the current version (as of Dec-01) the discussion is focussed on distance sensitive rating where the charge of connection depends on the origin and destination of call. As explained in the remainder of this document, the key issue for which we need to find a generic solution is reflected by the following statement:

It depends on the rated party and the usage type which attributes should be used as origin and destination.

The second part can be described by the example of a GSM roaming call: For the receiving B-party such a call is typically charged as a connection from the HPLMN to the VPLMN: The applicable tariff class is determined using the MSC that generated the CDR as origin and the MSRN of the B-party as destination. On the other hand, a normal international call should be rated using the A-party's CGI as origin and the B-party number as destination.

The question that might lead us to the problem solution is: Who is responsible to determine what call attributes should be used as origin and destination?

We have three choices how to determine the origin and destination of a call:

Another problem discussed in this document is the detection of all involved parties. This also includes the question how OSB recognizes that a network usage needn't rating for a potential partner. An intra-network call, e.g., doesn't need rating for a partner network. At the current status of the design I fear, that party recognition will use more CDR attributes than is actually desirable.

Recap: Rating process

Diagram shows the flow of CDR as far as this document is concerned.

Diagram Flow of CDRs from network to rating

Mediation is responsible to retrieve the raw CDRs from the network elements and to convert them into the OSB internal format.
Party analysis is responsible to generate a CDR for every party involved in the network usage.
Rating is responsible to validate the network usage for the served party and to do the actual rating of the network usage.

In real-life the module party analysis is most likely integrated into the rating. It is however important to encapsulate its functionality because this way it can easily be tailor-made to the specific needs of an OSB operator.

Terminology

For other terms and abbreviations please refer to the glossary.

OUR Originated Usage Record
TUR Terminated Usage Record
EVT GSM supplementary service EVenT
ROA ROAming usage record
ROR Roaming Originated usage Recorda)
RTR Roaming Terminated usage Recorda)
REV Roaming supplementary service EVenta)
IGR Incoming Gateway Record
OGR Outgoing Gateway Record
CFW Call ForWarding recordb)
TRA TRAnsit recordb)
MSRN Mobile Station Roaming Number
IC Interconnect carrier
 
a) These records are generated by partner networks (GSM: VPLMN) whenever a subscriber of the OSB network roams in their network and sent to the OSB operator (GSM: HPLMN).
b)

These record types are provided by some switch vendors, but not directly supported by the rating process. Instead they will be transformed into one of the other record types.

General usage scenario

With respect to end-users, network usage can be described using the diagram below:

The A-party initates a connection to the B-party, which may forward the call to C: A is the origin, B the destination and C the forwarded-to number of a connection.

Record generation

This section defines the OSB rules for CDR generation. They are derived from GSM 12.05 and should enable the OSB library rate the network usage for all involved parties.

Diagram Simplified model of a GSM network1)

In diagram the HPLMN is the GSM network operated by the OSB user. It consists of several MSCs and GMSC which connect the HPLMN with partner networks.
End-users of the HPLMN are its own subscribers and visitors from VPLMNs. HPLMN subscriber in turn use the roaming partner networks.
The charging principle is simple: All usage of the HPLMN should be charged to the respective parties and charges are due to partner networks for all traffic handed over to them. Roaming partners charge the HPLMN for the network usage by subscribers of the HPLMN, who in turn will charge the respective subscriber.

1) The diagram does not show the network elements for subscriber administration (HLR,VLR, AUC), the base stations and BSCs.

Rules

I Whenever a connection is originated in the HPLMN, the switch of the A-party generates an OUR.
II Whenever a connection terminates in the HPLMN, the switch of the B-party generates a TUR.
III

Whenever a MSC redirects a call to a B-party roaming outside the HPLMN, it creates a ROA record.
Note: This implies that roaming records are generated only for subscribers of the HPLMN.

IV Whenever a gateway switch receives an incoming connection from a foreign network and does not generate a TUR, it creates an IGR.
V Whenever a gateway switch routes an outgoing connection to a foreign network and does not generate a OUR or ROA record, it creates an OGR.
VI Whenever a MSC routes a connection and does not generate an OUR, TUR, ROA, IGR or OGR it may create a TRA record.
VII For every supplementary service action that is not recorded in any other record, an EVT record is generated.

In case of a forwarded connection, some switch vendors provide a CFW record instead of IUR and OUR for the forwarding party. Party analysis will split CFW records as generated by mediation into an TUR/OUR pair.
Some switch providers generate TRA records instead of OGRs and IGRs. Where this is the case, party analysis has to determine if the incoming or outgoing trunk points to another network and generate gateway records accordingly.

Optimizations

The generation of ROA records can be omitted, if neither the incoming nor the outgoing trunk point to an external network.

TRA records are generated only for internally routed connections and are therefore optional.

It is strongly recommanded not to suppress the generation of IGR and OGR for the sole reason the settlement with an external network is not needed.
Instead OSB should be configured not to perform settlement rating for the network partner.

Record rating

This section describes how OSB uses the generated records for rating and the necessary CDR fields.

Originated usage record

OSB Cdr content (as relevant for rating)
Field Description
usageType OUR: Originated usage record M
servedParty identifies the A-party M
  e164Number phone number (GSM: MSISDN)  
  imsi A-party IMSI (GSM only)  
otherParty identifies the B-party M
  e164Number B-party E164 number as dialled by A  
  normalizedNumber normalized B-party number a)
servedPartyLocation Location of the A-party (GSM: CGI) M
recordingSwitch identifes the switch producing the record Mb)
inTrunk incoming trunk group: points to A-party location O
outTrunk outgoing trunk group: points to B-party location Cc)
ratedOrigin Id of the connection point that best matches the origin Cd)
ratedDestination Id of the connection point that best matches the destination Cd)
 
a)

The normalized B-party number is computed during the rating process. The format is the same as used for the configuration of destinations in Tariff Administration. In the case of a E164 phone number it consists of +-CC-NDC-SN (+ being the general IAC).

b)

Format yet to define: E164 number, name (ASCII) or OSB network element id. In the latter case mediation would be responsible to set it correctly.

c)

Mandatory if the outgoing trunk points to another network, i.e. if the record was generated by a gateway switch (POI).

d) Determined during the rating process by the tariff classification system (if applicable).

Rated parties, origin and destination

An OUR is rated for the A-party and reconciled with the interconnect carrier:

We have to provide a mapping network element, incoming trunk, outgoing trunk to interconnect carrier.
For each network partner we must be able to configure if a) billing and b) reconciliation should be performed.
In a future version, OSB should provide the possiblity to identify an interconnect carrier by using the B-party number.

Terminated usage record

OSB Cdr content (as relevant for rating)
Field Description
usageType TUR: terminated usage record M
servedParty identifies the B-party M
  e164Number phone number (GSM: MSISDN)  
  roamingNumber MSRN of the B-party O
  imsi B-party IMSI (GSM only)  
originParty identifies the A-party M
  e164Number A-party E164 number  
  normalizedNumber normalized A-party number  
servedPartyLocation Location of the B-party (GSM: CGI) M
recordingSwitch identifes the switch producing the record M
inTrunk incoming trunk group: points to A-party location Ca)
outTrunk outgoing trunk group: points to B-party location O
ratedOrigin Connection point id of the origin C
ratedDestination Connection point id of the destination C

a) Mandatory if the incoming trunk points to an external network.

Rated parties, origin and destination

An TUR is rated for the B-party and billed to the interconnect carrier:

Roaming originated usage record

OSB Cdr content (as relevant for rating)
Field Description
usageType ROR: Roaming originated usage record M
servedParty identifies the A-party M
  e164Number phone number (GSM: MSISDN)  
  imsi A-party IMSI (GSM only)  
otherParty identifies the B-party M
  e164Number B-party E164 number as dialled by A  
  normalizedNumber normalized A-party number  
recordingNetwork identifies the partner network (GSM: VPLMN)  
recordingSwitch identifies the switch producing the record C
servedPartyLocation location of the A-party (GSM: CGI) C
chargeInformation Information about charges risen by the partner network: Amount, exchange rate and tax rate.  
ratedOrigin Id of the connection point that best matches the origin C
ratedDestination Id of the connection point that best matches the destination C

Rated parties, origin and destination

A ROR is rated for the A-party which is always a subscriber of the OSB operated network. Because the record is not generated by an OSB network, no billing and reconciliation with interconnect partners is needed and possible (no trunk information is available). The record is rated by the roaming partner and charged to the OSB operated network.

Roaming terminated usage record

OSB Cdr content (as relevant for rating)
Field Description
usageType RTR: Roaming terminated usage record M
servedParty identifies the B-party M
  e164Number phone number (GSM: MSISDN)  
  imsi B-party IMSI (GSM only)  
originParty identifies the A-party M
  e164Number A-party E164 number  
  normalizedNumber normalized B-party number  
recordingNetwork identifies the partner network (GSM: VPLMN)  
recordingSwitch identifies the switch producing the record C
servedPartyLocation location of the B-party (GSM: CGI) C
chargeInformation Information about charges risen by the partner network: Amount, exchange rate and tax rate.  
ratedOrigin Id of the connection point that best matches the origin C
ratedDestination Id of the connection point that best matches the destination C

Rated parties, origin and destination

A RTR is rated for the B-party which is always a subscriber of the OSB operated network. Because the record is not generated by an OSB network, no billing and reconciliation with interconnect partners is needed and possible (no trunk information is available). The record may be rated by the roaming partner and charged to the OSB operated network.

Normally either RTR or ROA records are used to charge the subscriber. The only exception to this rule is when the charges of the partner network are carried forward to the OSB subscriber while at the same time ROA records are used to compute the charges of the OSB network.

Roaming usage record

OSB Cdr content (as relevant for rating)
Field Description
usageType ROA: roaming usage record M
servedParty identifies the B-party M
  e164Number phone number (GSM: MSISDN)  
  imsi B-party IMSI (GSM only)  
  roamingNumber MSRN of the B-party M
originParty identifies the A-party M
  e164Number A-party E164 number  
  normalizedNumber normalized B-party number  
recordingSwitch identifes the switch producing the record M
inTrunk incoming trunk group: points to A-party location Ca)
outTrunk outgoing trunk group: points to B-party location Ca)
ratedOrigin Connection point id of the origin C
ratedDestination Connection point id of the destination C

a) Mandatory if the trunk points to an external network.

Rated parties, origin and destination

As previously mentionned, rating of ROA and RTR is usually done for one of the usage types only.
A ROA is rated for the B-party, billed for incoming carrier and reconciled with the outgoing carrier.

Incoming gateway record

OSB Cdr content (as relevant for rating)
Field Description
usageType IGR: incoming gateway record M
servedParty identifies the interconnect carrier M
  inTrunk incoming trunk group  
originParty identifies the A-party O
  e164Number phone number (GSM: MSISDN)  
  normalizedNumber normalized A-party number  
otherParty identifies the B-party M
  e164Number A-party E164 number  
  normalizedNumber normalized B-party number  
recordingSwitch identifes the switch producing the record M
inTrunk incoming trunk group: points to A-party location M
outTrunk outgoing trunk group: points to B-party location O
ratedOrigin Connection point id of the origin C
ratedDestination Connection point id of the destination C

Rated parties, origin and destination

A IGR is billed for incoming carrier.

Outgoing gateway record

OSB Cdr content (as relevant for rating)
Field Description
usageType OGR: outgoing gateway record M
servedParty identifies the interconnect carrier M
  outTrunk outgoing trunk group  
originParty identifies the A-party O
  e164Number phone number (GSM: MSISDN)  
  normalizedNumber normalized A-party number  
otherParty identifies the B-party M
  e164Number B-party E164 number  
  normalizedNumber normalized B-party number  
recordingSwitch identifes the switch producing the record M
inTrunk incoming trunk group: points to A-party location O
outTrunk outgoing trunk group: points to B-party location M
ratedOrigin Connection point id of the origin C
ratedDestination Connection point id of the destination C

Rated parties, origin and destination

A OGR is reconciled with the outgoing carrier.

Call forwarding records

The OSB rating does not support CFW records directly, instead it expects an TUR/OUR pair. OSB supports the CFW record for mediation, party analysis will later do the appropriate splitting.

OSB Cdr content
Field Description
usageType CFW: call forwarding record M
servedParty identifies the B-party M
  e164Number phone number (GSM: MSISDN)  
  roamingNumber MSRN of the B-party O
  imsi B-party IMSI (GSM only)  
originParty identifies the A-party O
  e164Number phone number (GSM: MSISDN)  
  normalizedNumber normalized A-party number  
otherParty identifies the C-party M
  e164Number A-party E164 number  
  normalizedNumber normalized B-party number  
recordingSwitch identifes the switch producing the record M
inTrunk incoming trunk group: points to A-party location O
outTrunk outgoing trunk group: points to C-party location O

The CFW record does not contain ratedOrigin and ratedDestination because it is not supported by the rating engine.

Transit records

OSB does not use TRA record for rating, they may used for statistics only (not yet supported by OSB). However some switch vendors provide these records instead of IGR and OGR. By defining the TRA record we make it possible for mediation to concentrate on the conversion from the switch specific format into the OSB cdr format and leave the generation of IGR or OGR records to party analysis.

OSB Cdr content
Field Description
usageType TRA: transit usage record M
originParty identifies the A-party O
  e164Number phone number (GSM: MSISDN)  
  normalizedNumber normalized A-party number  
otherParty identifies the B-party M
  e164Number A-party E164 number  
  normalizedNumber normalized B-party number  
recordingSwitch identifes the switch producing the record M
inTrunk incoming trunk group: points to A-party location O
outTrunk outgoing trunk group: points to B-party location O

Because no rating is done for TRA records, they do not contain servedParty, ratedOrigin and ratedDestination.

Event record

OSB Cdr content (as relevant for rating)
Field Description
usageType EVT: event usage record M
servedParty identifies the party for which the record applies M
  e164Number phone number (GSM: MSISDN)  
  imsi A-party IMSI (GSM only)  
servedPartyLocation Location of the served party (GSM: CGI) O
recordingSwitch identifes the switch producing the record M
eventCode service action: registration, erasure, activation, deactivation, interrogation, password change M

An EVT record is rated for the served party. Rating may depend on the suppl. service used, the eventCode and the basic services to which they apply.

Roaming event record

OSB Cdr content (as relevant for rating)
Field Description
usageType REV: roaming event usage record M
servedParty identifies the party for which the record applies M
  e164Number phone number (GSM: MSISDN)  
  imsi A-party IMSI (GSM only)  
servedPartyLocation Location of the served party (GSM: CGI) O
recordingSwitch identifes the switch producing the record M
eventCode service action: registration, erasure, activation, deactivation, interrogation, password change M
chargeInformation Information about charges risen by the partner network: Amount, exchange rate and tax rate.  

An REV record is rated for the served party which is always a subscriber of the OSB operated network. The record is rated by the roaming partner and charged to the OSB operated network. As for the roaming usage records, two different rating schemas may be applied:

Discussion of usage scenarios

Intra-network usage

In this scenario a subscriber A calls subscriber B within the same network. Both parties can be located at the same switch or at two different switches. In the latter case, the call may be routed through several other switches:

Diagram Intra-network call

Generated usage records

If A and B are located at the same switch, an OUR and a TUR record must be generated by this switch.

Usage record rating

Calls leaving the network

In this usage scenario the A-party, a subscriber of the OSB operated network, calls the B-party, which is a PSTN subscriber. Subscriber A can be located at the gateway switch as shown in diagram or at an internal switch.

A-party at gateway switch

Diagram Inter network call, A-party at gateway switch

Generated usage records

Usage record rating

A-party at internal switch

Generated usage records

Usage record rating

The rating of the usage record is the same as where the A-party is located at the gateway switch.

Incoming call

In this call scenario the B-party, a subscriber of the OSB operated network receives a call from the A-party, a PSTN subscriber. The B-subscriber may be located either at the gateway or, as shown in diagram at a network internal switch.

B-party at internal switch

Diagram Incoming call, B-party at internal switch

Generated usage records

Usage record rating

B-party at gateway switch

Generated usage records

Usage record rating

The rating of the usage record is the same as where the B-party is located at a network internal switch.

Roaming

This usage scenario applies to mobile networks. The B-party, who is subscriber of the OSB network and currently roaming in a VPLMN, receives a call from a PSTN number (A-party).

Diagram Roaming call

Generated usage records

The first leg of the call can be rated for the PSTN, the 2nd leg can be rated for B and the network that routes the call from the OSB network to the VPLMN.

Usage record rating

Forwarded call to roaming subscriber

In this usage scenario the B-party, which is a subscriber of the HPLMN (OSB network), receives a call from the PSTN subscriber A. The call is forwarded to subscriber C, located in the HPLMN.
The scenario applies to mobile networks only and the most difficult to handle, because the correct rating for all involved parties depends on the actually used call forwarding service.

Diagram Call forwarded by roaming subscriber

When the gateway switch G receives the incoming call from A, it interrogates the HLR about the current location of B. The HLR reply may contain the information that the call should be forwarded to C. This is the case if B has forwarded its calls unconditional or on not reachable, for the latter however it is not always known to the HLR if the forwarding condition is fulfilled (see below).

Call forwarding condition detected by gateway switch

Generated usage records

Both records that are generated by the gateway switch G (TUR and OUR) for the B-party may contain the information that the call was forwarded (Cdr.causeForForward), but the forwarding service should be rated only once. Mediation or party analysis are responsible to populate Cdr.usedServices accordingly, i.e., in only one of the usage records created for subscriber B.

Usage record rating

Call forwarding condition detected by VPLMN

If the B-party has activated call forward on busy or on no reply, the forwarding condition can not be determined during HLR interrogation. This is also the case if the mobile phone is not reachable and this fact was not signalled to the HLR of the HPLMN (e.g. if the battery was removed).

Generated usage records

Usage record rating

Both calls legs are rated the same way as the corresponding individual call scenarios, i.e. like a roaming and an incoming call. In addition the B subscriber will be charged for the usage of the VPLMN network.

First leg

Second leg

Everything clear?

So now you think, that now we can write down OSB requirements for CDR generation and define the rules of how OSB identifies the parties involved. Then try the following call scenario:

Diagram An easy case?

Both, A and B are subscriber of a city carrier who maintains networks in major cities and relies on partner networks to connect these isolated islands.

Question: Who should be charged for the scenario shown in diagram
Solution: It depends on who is the mother-in-law of OSB network's CEO, but OSB should provide a solution.