Charging

The following sections describe WebLogic Network Gatekeeper charging functionality:

Overview

The WebLogic Network Gatekeeper makes it possible to tailor the type of charging to be used for each application using service capabilities through the WebLogic Network Gatekeeper. An application can use one or more of the following charging alternatives:

Charging based on time period or used amount (CDR based charging)
Charging based on the content or value of the used service

The CDR data can be stored in the WebLogic Network Gatekeeper's internal charging database or retrieved in real-time by billing and post processing systems through a billing gateway. Both pre-paid and post-paid accounts are supported.

CDR based charging

CDRs are used for charging based on time period or used amount. Charging based on time period is typically used to charge for calls. Amount can be used, for example to charge for a positioning service.

Data generation

Charging data is generated every time an application uses service capabilities through a service capability module. The charging data is recorded by the service capability module while the application interacts with the network. When the interaction is closed, the service capability module stores the charging data as a CDR in the database. One storage of data in the database represents a charging transaction. (If integrated with a billing gateway, the charging data is sent directly to the billing gateway.)

In the database, all CDRs are stored in the same table. Different service capability modules produce different kinds of charging data. Therefore, some of the fields in the charging table are optional and others may contain different types of data depending on the service capability module. General descriptions of the fields in the charging table are provided in Table 8-1 on page 3. The service capability module specific charging data descriptions are provided in Charging Data.

The CDRs can also be used to create extensive service usage statistics.

Table 8-1 CDR Contents

Field	Description
transaction_id	A unique ID for the transaction. Automatically provided.
session_id	An ID connecting related transactions within a service capability module. For example, a call containing three call-legs will produce three separate transactions within the same session.
service_name	The service capability module that has created the CDR.
user_id	The application that used network services through the service capability module.
start_of_usage	The date and time the service capability module started to use services in the network.
connect_time	The date and time the destination party responded. Used for call control only.
end_of_usage	The date and time the service capability module stopped to use services in the network.
duration_of_usage	The total time the service capability module used the network services.
amount_of_usage	The used amount. Used when the charging is not time dependent. For example, flat rate services.
originating_party	The originating party's address.
destination_party	The destination party's address.
transaction_part_number	If the transaction is divided into sub-transactions (transaction parts), the part number indicates number of the sub-transaction. If sub-transactions are not used, transaction part number is equal to 1.
completion_status	Indicates the completion status of the transaction. 0 - failed 1 - completed 2 - partial Partial is only used if the transaction is divided into sub-transactions. 3 - completed but result delivery to application failed
additional_info	Any additional charging data specified by the service capability module. The data is tagged for XML processing.
service_provider	The ID of the service provider that hosts the application.
revenue_share_ percentage	A percentage to be used for revenue sharing. Added by the application or by the policy service.
party_to_charge	The ID of the party that initiated the request that resulted in the transaction.
charging_info	Service code added by the application or by the policy service.
slee_instance	The SLEE instance hosting the service capability module that generated the CDR.

Content based charging and accounting

Content or value based charging makes it is possible to charge a user or subscriber based on the value of a used service rather than the amount or time used. This can be used, for example when down loading music video clips or in m-commerce applications. Both pre-paid and post-paid end-user accounts are supported.

Revenue sharing

Revenue sharing means that part of the revenues generated by an application can be shunted back to the service provider. The actual percentage is specified in the CDR.

For pre-paid accounts, settlement can be handled in real-time by the charging service or near real-time through a billing gateway.

For post-paid accounts, settlement is handled by CDRs and post processing systems.

Billing system integration

CDR database

Integration through the CDR database is suitable when the applications connected to an WebLogic Network Gatekeeper use post-paid accounts.

charging.html

When integrating through the CDR database, a CDR batch retrieval tool retrieves the CDRs from the database and stores them in a file format. The CDR file is processed by a rating system that transforms the CDR to billing information and stores it in a post-paid accounts database. The flow is shown in Figure 8-1, Billing integration through CDR database, on page 8-5.

Billing gateway and other similar

Integration through a billing gateway supports real-time settlement of pre-paid account as well as storing billing information in a post-paid database.

charging.html

When integrating through a billing gateway, the billing gateway retrieves the CDRs in real-time through a CORBA based charging listener. Rating, rating management, billing information storage, and pre-paid accounts settlement are handled by the billing gateway. The flow is shown in Figure 8-2, Billing integration through billing gateway, on page 8-6.

Charging plug-in

Applications using the charging service capability module need to have a connection with an accounts database. The integration between the charging service capability module and the database is made through a customized plug-in. The plug-in is developed to fit the characteristics of the accounts database. With this solution, both pre-paid and post-paid accounts can be handled. For example, it can be verified before a call is set up that there is money are on a pre-paid account.

The flow is shown in Figure 8-3, Billing integration through a charging plug-in, on page 8-7.

charging.html