Principles of interconnect settlement

Interconnect Settlement bases on a mutual agreement between two partner networks that states the terms and conditions for each party to use his partner's network services. The basic principles applied by the two parties A and B of such an agreement generally are as follows:

• For traffic sent from carrier B to carrier A:
  Carrier A will charge carrier B for the network resources of his network used by traffic originated from carrier B. For this, carrier A will generate periodic invoices based on the incoming call detail records of his network and send these invoices to carrier B.
• For traffic sent from carrier A to carrier B:
  Similarly, carrier A will receive periodic invoices from carrier B for the network resources of his network used by traffic originated from carrier A. To verify these invoices, carrier A will generate reconciliation statements based on the outgoing call detail records of his own network and compare them with the invoices received from carrier B.

Diagram I: Simple interconnect scenario from PNG Telikom's point of view

Components of the OSB Settlement System

Essentially, the OSB settlement system combines OSB mediation and rating with OSB billing. The diagram below shows a simplified view of the settlement usage data flow. It doesn't show party analysis, storage, record filtering and recycling.

Diagram II: Simplified settlement usage data flow

Existing OSB concepts will be used for interconnect settlement, some of which will need to be specialized and/or extended for settlement purposes.

• Agreement between two carriers:
  • Contract
    • Invoice currency
  • Interconnect carrier: Associate
  • Contact information: Address
  • Payment terms
• Balance sheet
  • System wide balance sheet (accounting) currency
• Products and product items
  • Resource item
    • Trunk item
• Tariff system
  • Rate in billing and/or rating
  • Timezone sensitive rating
  • Tariffs
    • Cost based (Handover CGI to B-number)
    • Number based (Mapped A-number to B-number)
    • Location based (Handover CGI to B-CGI)
    • Revenue sharing (Number based with percentage)
• Networks, network elements, trunks
• UsageRecordSource, UsageRecordStream
• Summary usage records

Usage collection and Mediation

Usage collection is the process of collecting usage records from a given usage record source, e.g., a switch, and making them available in a usage record stream. In order to make the system self-sufficient in case of data loss or corruption during processing, the records should be stored in persistent storage (files) immediately after they are collected from the usage record source. The records enter the call accounting chain when they are read from these files.

Mediation can be broken down into conversion, filtering, aggregation (partial call record assembly) and (possibly) duplicate checking.

• Conversion is the process of translating usage records from any external format into the OSB internal CDR format. Each conversion needs to be defined (read: programmed) separately. Examples of external formats are: Excel CDR format, TAP3 format. The input file is parsed and checked for nonsensical data. Parser design is important since the parser is subject to change. Every new input file format will require a new parser and corresponding checks and input file formats change over time and the parser must be changed. Each output record should have a unique identifier which may be available from the network or have to be created.
• Filtering removes unnecessary and unwanted incoming records from the record stream. It should be possible to store the filtered records.
• Aggregation is the process of combining data from multiple usage records into one record, e.g., the aggregation of partial CDRs into one complete CDR. Duplicate checking on a file level is done based on unique key data taken from each file. If the filename or file contents has a file sequence number, a sequence check can be implemented to make sure that there are no gaps, i.e., missing files. Within each file, a check for duplicate records can be done. Checking for duplicate records across multiple files is out of the scope of the initial implementation. Such functionality may be added later.
  

Telikom PNG requirements

• Support Alcatel IGE (EC7) call detail records [2.2.1]
• Support assembly of partial call records [2.2.3]

Call Accounting

For each report sent to the partner carrier, it must be possible to identify the related call records. This should be a side-effect of the call accounting.

Call accounting: should also allow for a comparison between what was charged to subscribers and what external carriers asked for (margin analysis).

Telikom PNG requirements

• Requires detailed logs showing a file's progress through the system. [2.2.7]
  

Party analysis and rating

For settlement purposes, the involved parties (interconnect partners) are generally identified from the trunk information in the records. This information must be available in call records generated by the gateway switch. Special cases include a call on an outgoing trunk which must be charged instead of reconciled (and not a negative charge to be calculated). See the Rating Usage Scenarios document for a comprehensive discussion.

Interconnect rating is the rating of calls for interconnect settlement and reconciliation. For settlement, call records of incoming calls from each partner are rated and for reconciliation, call records of outgoing calls to each partner are used.

Re-rating of calls is required. In a post-paid scenario this means that calls which are rejected by the rating engine are isolated and can be recycled at a later time (multipe cycles should be possible).

Telikom PNG requirements

• "Calls must be able to be rated using flagfall, non-discountable charges, graduated banding, maximum limit, per second pro-rated, per volume or any combination of these." [2.3.3]
  "We intend to mimic our own internal customer charging for our wholesale customers (with trade discount of course). Flagfall is a once only charge on each call which can be discounted by later packages etc. Graduated banding is where the rating price of a call can change after a threshold of time or cost has been achieved. Maximum limit is where the rating of a call hits a predefined ceiling and goes no further." [Clarification from PNG]
• Rating must be done specific to a given timezone. The timezone should be assigned to the settlement agreement. [2.6.4]
• It must be possible to identify a CDR as being the billing responsibility of another carrier, either by some flag in the CDR or via the B party digits dialled (Carrier Access Code) [2.18.1]
  

Storage

In a settlement system, in contrast to a postpaid retail billing system, we typically process only very few invoices, each of which is created from (potentially) millions of callrecords.

In order to relieve the interconnect billing engine, storage creates and maintains "summary usage records" (SRs) in a dedicated table. Billing does not have to read the individual usage records, it only reads SRs. This means that the summary records need to contain enough detail info so that billing can still apply discounts on the final invoices. There should be one SR for each tupel of <agreement, rating info, etc> and a given time period (typically 1 day - this determines the finest resolution for billing).

In really big systems, it may be necessary to store usage records in different tables (even databases?) dependent on the agreement.

Extraction ("reverse storage"): It should be possible to extract callrecords from the system and convert them to ASN.1 format (e.g., CDR files to send to the partner).

Billing

It should be possible to start the billing engine for a single contract and/or contract owner (interconnect carrier). Settlement billing uses only the summary records to avoid having to process millions of records for each agreement at the end of the month.

It should be possible to generate intermediate reports for the agreements. Such intermediate statements can be generated for any time period. Typically, intermediate statements are generated every month and the invoice is created every quarter.

Invoice and reconciliation statements differ in that each summary usage record must be on exactly one invoice but reconciliation reports and intermediate statements can be created for any given time period (including multiple reports for one period, reports for overlapping time periods and gaps between reporting periods).

For certain requirements it is necessary that billing re-rates the calls. This is the case to, e.g., compute charges based on the total number of minutes accrued in the billing interval.

It should be possible to apply promotions on the summary records.

The following XML documents need to be generated:

• Intermediate statement
• Settlement invoice
• Reconciliation report

Preliminary thoughts about the modeling of a settlement agreement:

Model 1: One product containing INTRUNK resource and OUTTRUNK resource, one tariff system and relevant services. The result is a combined statement containing sections for both, settlement as well as reconciliation. This model can be used for a bilateral invoice in one direction only, with netting of traffic.

Model 2: Two products. One with INTRUNK resource, tariffsystem for invoice and relevant services and one with OUTTRUNK resource, tariffsystem for reconciliation and relevant services. Both products can be assigned to one contract or to two different contracts. If the products are assigned to the same contract, then the result is very similar to model 1. On the other hand, if the products are assigned to two different contracts then it is possible to generate settlement and reconciliation statements individually.

Telikom PNG requirements

• Each report (incoming/outgoing Product?) should contain the following information (sample): [2.11.4 - 2.11.7]
  • This party
• • Other party
  • Reporting period
  • Timezone (should this be in the TS?)
  • For each Call type (PersService?)
    • For each TC and TP
      • Total call seizures
      • Total answered calls
      • Total volume
      • Rate used for currency calculations
      • Outpayment values (duration x rate)
• It must be possible to import other carrier's reports in order to verify against Telikom's own collected data. [2.10.2]
• It must be possible to produce a daily summary of priced calls. [2.11.2] (rating? balance sheet? call accounting? or incremental bill runs?)

Agreement admin

View/create/modify/delete agreement

Network admin

Configuration of network elements (e.g., trunks).

Reporting

• XML, csv, text format, basic reporting client
• Use UsageRecord information in the database for reporting (only).
• Conversion from ASN.1 to XML for reporting.

The settlement system should be able to produce a number of standard reports. The following list describes each standard report briefly.

Carrier summary reports

• Revenue summary report for a time period
  For a given time period (at least one day), the report summarizes calls, volumes and charges for each agreement and separated into inbound and outbound traffic. The average rate is computed from the total volume and charges. If run for the current day, it will show all charges rated and updated in the database summary records so far.
• Unbilled usage and time period for all agreements
  For each agreement, this report shows the unbilled time period and unbilled usage amount. The amount only contains usage charges and does not include taxes or any other charges or discounts that may be applied by the billing engine.
• Invoices created for all agreements in a time period
  For each invoice created in the given time period, this report shows invoice date, invoice number, invoice period and invoice amount.

Account status reports

• Account summary for one agreement and a given time period
  For one agreement, a traffic direction (inbound or outbound) and a given time period (at least one day), this report shows detailed calls, volumes and charges information. One line is reported for each combination of trunk, tariff class (e.g., service usage), tariff zone (e.g., destination), tariff period and tariff.
• Account invoice history
  This report shows invoice date, invoice number, invoice period and invoice amount for one agreement and a given time period.

Operations reports

• Call accounting summary report
  Call accounting is done with respect to the original incoming file. The report shows one line for each incoming file that arrived in a given time period (resolution can be less than one day). For each file, the number of original CDRs, and the percentage of records in each status is given. The report also contains the amount for the rated records. Note: Call accounting properly handles cases where multiple incoming CDRs are assembled into one usage record and also accounts for single input CDRs, which are multiplied and stored in more than one output file (e.g., records for both, interconnect and retail billing).
• Processing error summary report
  For each incoming file that arrived in a given time period, this report shows the number of error records and the percentage of errors for each type of error. The number of columns in the report depends on the number of different errors that occurred. For detailed error analysis, the rejected records can now be retrieved and analyzed based on the information in this report. This is done on file level; the rejected usage records are not stored in the database.

Tariff system related (pricing structure) reports

• Tariff system summary report
  For one tariff system version, this report shows all combinations of tariff class and tariff period together with the associated tariff. This provides a high level overview of (especially more complex) tariff systems.
• Tariff classification system report
  This report shows all tariff classes that belong to one tariff classification system.
• Tariff period group report
  For one tariff system version, this report shows the tariff period group used for each tariff class.