Rating: Usage scenarios

This document aims to answer the following questions:

• How does OSB determine which parties are involved in a call?
• What is the role of an involved party?
• How does a tariff system select the correct tariff?

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:

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:

• Brute force approach: Make whoever generates the CDR for each party is responisble to create the call attributes in the way expected by the tariff system. Such a specification is hardly meaningful because "whoever" would have to know and apply all configuration details.
• Provide different tariff classification systems that use the appropriate CDR attributes to determine the tariff class. Though is approach is generic, it is not user-friendly and potentially generates more configuration data than actually needed: It is quite likely, that the same rate applies for both of the above calls.
• Make tariff classification systems sensitive to the usage type, i.e., use hard coded logic such as
  if usage type = roaming then origin = msc.cgi, destination = msrn.
  At a first glance such hardcoded logic seems distrubing. On the other hand we might consider such mapping rules as part of a tariff classification system type specification and if we are able to restrict ourselves to a few usage types things still remain comprehensible.
• Make everything user configurable. This clearly is the most generic solution, still one important questions remains unanswered: Who will be responsible to evaluate the configuration.

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.

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 network¹⁾

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.

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

Rules

	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

Rated parties, origin and destination

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

• The A-party is identified by servedParty. The rated origin is servedPartyLocation, the rated destination is otherParty.normalizedNumber.
• The IC is identified by the outgoing trunk. The rated origin is the switch that generated the record, the rated destination is otherParty.normalizedNumber.

	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

^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:

• The B-party is identified by servedParty. The requirement which origin and destination should be used, are not as clear as in the case of an OUR. The origin could be originParty.normalizedNumber, the destination servedPartyLocation, the former however might not always be available.
• The IC is identified by the incoming trunk. The rated origin is either originParty.normalizedNumber or recordingSwitch. The destination is servedPartyLocation or recordingSwitch.

Roaming originated usage record

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.

• The A-party is identified by servedParty. Two different rating schemas may be applied.
  • The first, more common schema, adds a surcharge (percentage, absolute amount or a combination of both) to the charges of the partner network.
  • The second schema completely rerates the record as if the usage was done in the OSB operated network. I call this 2nd schema transparent roaming, because the rating for the subscriber does not depend in which network he actually initiated the usage. Origin and destination for this case are the same as for an OUR.

Roaming terminated usage record

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.

• The B-party is identified by servedParty. Two different rating schemas may be applied.
  • The first, more common schema, rates the usage as if the subscriber originated a call from the OSB network to the partner network. The origin therefore is the servedParty.e164Number that usually not only identifies the OSB network but also the switch where this number is registered. The destination is recordingNetwork and eventually recordingSwitch. In addition surcharges (percentage, absolute amount or a combination of both) to the charges of the partner network may be applied.
  • Transparent roaming completely rerates the record as if the usage was received in the OSB operated network. Origin and destination for this case are the same as for an TUR.

Roaming usage record

^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.

• The B-party is identified by servedParty, the MSRN can not be used for this purpose. The rated origin is recordingSwitch, the rated destination servedParty.roamingNumber.
• The incoming carrier is identified by the incoming trunk. The rated origin is either originParty.normalizedNumber or recordingSwitch. The destination can only be recordingSwitch.
• The outgoing carrier is identified by the outgoing trunk. For rating the only possible origin is recordingSwitch, the destination is servedParty.roamingNumber.

Incoming gateway record

Rated parties, origin and destination

A IGR is billed for incoming carrier.

• The incoming carrier is identified by the incoming trunk as provided in servedParty.inTrunk. The rated origin is either originParty.normalizedNumber or recordingSwitch. The destination can either be recordingSwitch.or otherParty.normalizedNumber.

Outgoing gateway record

Rated parties, origin and destination

A OGR is reconciled with the outgoing carrier.

• The outgoing carrier is identified by the outgoing trunk as provided in servedParty.outTrunk. The rated origin is either originParty.normalizedNumber or recordingSwitch, the rated destination is otherParty.normalizedNumber.

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.

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.

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

Event record

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

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:

• The first, more common schema, adds a surcharge (percentage, absolute amount or a combination of both) to the charges of the partner network.
• The second schema completely rerates the record as if the event happend in the OSB operated network. I call this 2nd schema transparent roaming, because the rating for the subscriber does not depend in which network he actually initiated the usage.

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

• Switch I where the A-party is located generates an OUR with servedParty = A, otherParty = B.
  The incoming trunk points to A, the outgoing trunk to switch II.
• Switch II and all other switches through with the call is routed, generate a TRA record with originParty = A, otherParty = B.
  Because both, the incoming and outgoing trunk point to network internal switches, this record may be suppressed.
• Switch III generates a TUR with servedParty = B, otherParty = A.
  The incoming trunk points to switch II, the outgoing trunk to B.

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

• The OUR is rated for the A-party who is identified by its resource number.
  No settlement rating is performed because neither trunk points to an external network.
• The TUR is rated for the B-party, identified by its resource number.
  No settlement rating is performed because neither trunk points to an external network.
• The TRA record are not rated at all because all incoming and outgoing trunks point to internal network elements.

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

• The gateway switch G generates an OUR with servedParty = A, otherParty = B.
  The incoming trunk points to the location of A, the outgoing trunk points to the PSTN.
• Withing the OSB network, no other usage record is generated for this scenario.
  Party analysis is responsible to generate a OGR for the interconnect carrier (i.e. the PSTN) with callingParty = A, otherParty = B.
  The trunks are the same as in the original OUR.

Usage record rating

• The OUR is rated for the A subscriber who is identified by its resource number.
• The OGR record is rated for settlement (reconciliation) with the PSTN, identified by servedParty.outTrunk.

A-party at internal switch

Generated usage records

• Switch I where subscriber A is located generates a OUR with servedParty = A, otherParty = B.
  The incoming trunk points to the location of A, the outgoing trunk points to the gateway switch.
• The gateway switch creates an OGR with servedParty = outgoing trunk, callingParty = A, otherParty = B.
  The incoming trunk points to switch I, the outgoing trunk to the PSTN.

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

• The gateway switch G generates an IGR with servedParty = incoming trunk, callingParty = A, otherParty = B.
  The incoming trunk points to the PSTN, the outgoing trunk points the terminating switch T.
• The terminating switch T generates a TUR with serverParty = B, otherParty = A.
  The incoming trunk points to the gateway switch, the outgoing trunk to the location of B.

Usage record rating

• The TUR is rated for the B subscriber who is identified by its resource number.
• The IGR is rated for settlement (billing) with the PSTN, identified by servedParty.inTrunk.

B-party at gateway switch

Generated usage records

• The gateway switch G generates an TUR with servedParty = B, otherParty = A.
  The incoming trunk points to the PSTN, the outgoing trunk to the location of B.
• Withing the OSB network, no other usage record is generated for this scenario.
  Party analysis is responsible to generate an IGR for the interconnect carrier (i.e. the PSTN) with servedParty = incoming trunk, callingParty = A, otherParty = B.
  The trunks are the same as in the original TUR.

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 gateway switch G generates a ROA record with servedParty = B, otherParty = A.
  The incoming trunk points to the PSTN, the outgoing trunk points to the VPLMN.
• Within the OSB network no other record is generated for the connection. Party analysis is responsible to generate:
  • An IGR for the PSTN with servedParty = incoming trunk, callingParty = A, otherParty = MSRN of B.
    The incoming trunk points to the PSTN. For the situation shown in diagram the outgoing trunk is not relevant and should be omitted.
  • An OGR for the VPLMN with servedParty = outgoing trunk, callingParty = A, otherParty = MSRN of B.
    The outgoing trunk points to the VPLMN. For the discussed situation the incoming trunk is not relevant and shold be omitted.

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

• The ROA record is rated for the B subscriber identified by its resource number.
• The IGR is rated for settlement (billing) with the PSTN, identified by servedParty.inTrunk.
• The OGR record is rated for settlement (reconciliation) with the PSTN, identified by servedParty.outTrunk.

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

• The gateway switch G generates a TUR with servedParty = B, originParty = A,
  the incoming trunk points to the PSTN, the outgoing trunk is not set.
• The gateway switch G generates a OUR with servedParty = B, otherParty = C,
  the incoming trunk is not set, the outgoing trunk points to the location of C.
• The switch where the C-party is located (G) generates a TUR with servedParty = C,
  the incoming must not be set (see below), the outgoing trunk points to the location of C.
• Within the HPLMN no other usage record is generated for this scenario.
  Party analysis is responisble to generate:
  • An IGR for the PSTN with servedParty = incoming trunk. The trunks are the same as in the original TUR.

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

• The TUR is rated for the B-party who is identified by its resource number.
• The IGR is rated for settlement (billing) with the PSTN, identified by servedParty.inTrunk.
• The OUR is rated for the B-party who is identified by its resource number.
• The TUR is rated for the C-party who is identified by its resource number, its incoming trunk must not point to the PSTN, else the usage would be billed twice to the PSTN.

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

• The gateway switch G generates a ROA with servedParty = B, originParty = A,
  the incoming trunk points to the PSTN, the outgoing trunk points to the VPLMN.
• For the first leg of the call no other usage record is generated. Party analysis is responsible to generate from the ROA record:
  • An IGR with servedParty = incoming trunk. The trunks are the same as in the original ROA record.
  • An OGR with servedParty = outgoing trunk, the trunks are copied from the original ROA record.
• The switches of the VPLMN will generate a TUR/OUR pair for the B subscriber. These records will also contain the information on the used forwarding service.
• The gateway switch that routes the (forwarded) call from the VPLMN to the C-party, creates a TUR with servedParty = C, originParty = B,
  the incoming trunk points to the VPLMN, the outgoing trunk to the location of C. This TUR will not contain the information that the call was forwarded by the VPLMN.

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

• The ROA record is rated for the B subscriber identified by its resource number.
• The IGR is rated for settlement (billing) with the PSTN, identified by servedParty.inTrunk.
• The OGR record is rated for settlement (reconciliation) with the PSTN, identified by servedParty.outTrunk.
• The TUR as received from the VPLMN via record exchange (TAP) will not be rated.

Second leg

• The OUR as received from the VPLMN via the TAP will be rated for the B-party, identified by its resource number.
• The TUR is rated for the C subscriber who is identified by its resource number.
• The IGR is rated for settlement (billing) with the PSTN, identified by servedParty.inTrunk.

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.