To charge Prepaid users Online, Charging Gateway (CGW) needs to integrate with Prepaid Charging System (IN). Other services/applications communicate with CGW and CGW communicates with IN. There can be different IN interfaces based on the Vendor/Type/Version of IN/Charging System. For prepaid subscribers, IN interface is required for charging. Interface will be required for the following functionalities:
The process should be fast and real-time. Connectivity with IN is generally IP based.
When user makes a call, CGW sends the Charging Request to IN Interface and IN Interface sends the request to the IN/Prepaid System.
IN/Prepaid System, using the above information, authenticates the identity of the user, calculates the user account’s remaining balance using the rating tariff table and maximum allowable duration of the call and sends this information to IN Requester and IN Requester forwards the response to CGW.
In many cases, IN Requester directly sends deduction/refund request using absolute amount and the session timings are managed by CGW.
The VAS Application then establishes the service session.
During the call, VAS Application monitors the service usage so that the user does not exceed the maximum allowable call session.
When the service session is over, the VAS Application sends the actual call usage to the CGW, which then forwards the request to IN through IN requester.
For event based charging, an absolute amount charging request is passed to IN/Prepaid System through IN requester.
Considerations for Prepaid Charging
When any request comes to CGW, CGW first identifies the subscriber whether it is from 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, it 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 Postpaid Subscribers list. CGW first checks whether the user falls in that range or not; if not, it is Prepaid user. Or some url(s) may be required to identify Postpaid Users. Normally, these logics are predefined by the Operator and based on that CGW incorporates proper logic for identifying Subscribers.
There is different vendor specific IN interfaces. Some Vendors have IN Interfaces which support DIAMETER protocol while some others use RADIUS. DIAMETER protocol based interfaces integrate with a variety of pre-paid billing systems. Many of the IN vendors provide proprietary interface to connect and charge. Some common interfaces are using MML Commands, Web Services, CORBA architecture etc.
IN Interfaces connect with CGW using a specific proprietary protocol. This is done to avoid changes in CGW due to change in IN. This enables CGW to have uniform features across all INs. The difference in IN/Prepaid Charging Interface is handled by IN Interface. CGW suit comes with multiple IN Interfaces that are already tested across popular vendors like Ericsson, NSN, Huawei etc. If a different interface is required, that particular integration is required to be done during implementation.
Session based charging is another consideration point. CGW handles full session and keeps track of start and end session. During a session, Auth, Re-Auth and End call are handled. Unique Session ID is used to make transaction with IN or Operator Charging Node.
TPS is another important factor for Prepaid Charging. Since this is online charging, how much transactions CGW can handle per second is very crucial. CGW processing capacity is highly affected by IN Requester TPS. Even if CGW has a high TPS capability but if IN Interface i.e. IN requester does not have enough capacity (TPS), IN Requester TPS will reduce the CGW TPS Capacity.
CGW generates logs/CDR other than online charging for reporting purpose.
If CGW cannot do the charging, due to some reasons, it provides a CDR file as output including the session details. This CDR is post-processed and applied to the account balance.
IN Requesters also generate separate logs that help troubleshooting IN Interface related issues.