Postpaid Charging Integration

Pre readings

  1. Content, Subscription and Differential Charging

What is Postpaid Charging Integration?

To charge Postpaid users Offline, Charging Gateway (CGW) generates CDR and this is later processed by Postpaid Charging System. , The charging system aggregates the usage data of Postpaid users (CDR) into files. These files can be transmitted in real-time or in batches to the billing domain for further processing.

Postpaid CDRs are often processed quite frequently (around 5-10 minute interval) to avoid credit risk and for better management of control function.

Considerations for Postpaid Charging

Identifying Prepaid and Postpaid Subscribers

When any request comes to CGW, CGW first identifies the whether the subscriber is in a Prepaid or Postpaid user group. In case of Prepaid User, CGW sends the user/call information to Prepaid Charging Interface. For Postpaid users, CGW does not send any user information to IN and just generates CDR for further billing process.

There can be different ways to identify subscribers, a number range can be defined for Prepaid Users. For Postpaid users, there can be a Postpaid Subscribers list. CGW first checks whether the user falls in that range or not, and if it does not, the user is a Prepaid user. Or some URL may need to call to identify Postpaid Users. Normally these logics are predefined from the Operator side, and based on that, CGW incorporates proper logic of identifying Subscribers.

 

Identifying Temporalily and Permanantly Deactivated subscribers

CGW identifies temporarily and permanently deactivated subscribers in coordination with some interface provided by the operator. This is often required to avoid charging subscribers who are actually not active or have left the network. The scenario mainly occurs for Subscription Based Services and at the time of renewal.

For session based charging we do not encounter this problem because the user has to be active in order to request a session. But subscription renewals are done separately and are managed by subscription renewal application. The application does not have any information regarding subscriber state unless it is provided somehow. For prepaid subscribers, the charging will fail if the subscriber is inactive and IN will reject charging). But for postpaid subscriber, renew application will generate CDR for all by default.

To avoid such scenarios, either an Interface is provided so that subscriber status can be checked, or the list of Inactive Subscribers is shared regularly.

Vendor Specific CDR Format

CDR format is vendor specific. Following information MUST be covered in CDR (it may also include other attributes according to vendor specification):

  • Calling/source number
  • Called/destination numberIncoming or Outgoing
  • CallSpecific service (e.g. Voice Portal)
  • Airtime (Session) or Event Based (Registration/Content based)
  • Airtime charging rate ID
  • Start time of the session
  • End time of the session
  • Charged amount by Charging Gateway (not MSC Charging)

If a single call has multiple rates, a final master CDR has to be provided to reconcile. Field separator and Row separator of CDR file can be defined.

Vendor specific formatted CDR is then guided to find the Postpaid user to which the call should be charged.

 

Integration with CGW

CGW generates CDR for billing according to a vendor specific format and pushes CDR to the Billing System.

Generating CDR

CGW takes data from a Database Table where Call information is kept and generates a CDR file by reading data from that Table. It can define how the CDR data is written to a file after reading from the table.

 

CDR push to the billing system

CGW pushes all the CDRs to the Postpiad Billing System using FTP or Billing System Collects CDR via FTP from the CGW Server.

Further Readings

  • Charging Gateway Product Note
twittergoogle_plusFacebooklinkedinmail

We love to hear from you