2 Split Charging and Voucher Domains

This chapter explains how the DCD components handle split charging and voucher redemption when wallets and vouchers are hosted by different billing domains.

Wallets and Vouchers Split Recharging

CCS supports charging services for redeeming vouchers and updating wallets when they reside on the same billing domain. The DCD product provides functionality that allows the Prepaid Charging product to extend this support to separate voucher and wallet domains in CCS.

DCD can be configured to support a CCS-based convergent billing solution where separate billing systems are used to host:

  • Vouchers and redemption functions.

    Example: Oracle VWS-Voucher Management

  • Wallets and charging functions.

    Example: A third-party billing system.

In order to achieve this, DCD can be extended using ccsConcepts required to support voucher redemption.

Key Components

The key components that enable this split-domain architecture with DCD are as follows:

Table 2-1 Key Components Enabling Split-Domain Architecture with DCD

Component Description Further Information
ACS voucherDelegator Configures the diamActions which support different billing domains for recharges. voucherDelegator
ccsConcepts Support voucher redemption variables. Voucher details

voucherDelegator

The voucherDelegator is a slee_acs process which implements the following diamActions enabling split domain recharging over DCD:

Table 2-2 voucherDelegator diamActions

Action Expected Response Description
Bad PIN
  • CCR named BadPINRequest, and
  • CCA named BadPINResponse
Sends a CCR to the BE, notifying that a given MSISDN has failed to redeem a voucher.
CreateEDR
  • CCR named CreateEDRRequest, and
  • CCA named CreateEDRResponse
Sends a list of tags and values as AVPs to the third-party BE which will be added to the BE EDR.
WalletRecharge
  • CCR named WalletRechargeRequest, and
  • CCA named WalletRechargeResponse
Sends a CCR to the third-party BE with a wallet rechage request, and expects a CCA with a wallet recharge response.

Diagram

Here is an example of the split-domain wallet and voucher recharging process. Note that the third-party billing engine server is also the Diameter Server in this example.

Figure 2-1 Split Domain Wallet and Voucher Recharge Flow

Here is an example of the split-domain wallet and voucher recharging process. Note that the third-party billing engine server is also the Diameter Server in this example.

Split Recharging Process

This table describes the stages involved in redeeming a voucher using VWS-Voucher Management and recharging a wallet on a third-party domain.

Table 2-3 Stages of Voucher Redemption and Third-Party Wallet Recharge

Stage Description
1

Voucher redemption is triggered using any of the following methods:

  • IVR feature nodes in a control plan
  • Interaction with a customer services representative (who uses the Voucher Management screen)
  • (If MM is installed) Short Messages sent from the subscriber's handset, and
  • (If USSD GW is installed) menus and fast access.

The information from the request initiator is passed to the voucherDelegator, which sends a message to the relevant BeClientIF process to reserve the voucher.
2 The BeClientIF sends a Voucher Reserve (VR_Req) request to VWS-Voucher Management.
3

VWS-Voucher Management checks whether:

  • This VWS holds the details for the requested voucher
  • The voucher PIN number is correct
  • If the voucher can be redeemed

If the voucher can be redeemed, VWS-Voucher Management reserves the voucher and passes a Voucher Reserve acknowledgment (VR_Ack) back to the voucherDelegator.
4 The voucherDelegator processes the message and sends a Wallet Recharge request to the dcdBeClientIF in an attempt to recharge the wallet on the Diameter Server (in this case the third-party BE).
5 The dcdBeClientIF constructs a CCR with a WalletRecharge action and interrogates the Diameter Server for wallet recharge.
6

The Diameter Server checks whether:

  • The details for the requested wallet
  • Whether the wallet state allows it to be updated

If the wallet can be recharged, the Diameter Server sends a CCA response back to the dcdBeClientIF with a Wallet Recharge acknowledgment, which is reported back to the voucherDelegator.
7

The voucherDelegator then sends a Commit Voucher Redeem (CVR_Req) request to the BeClientIF which is sent to VWS-Voucher Management for redeeming the voucher.

If the voucher redeem succeeds, VWS-Voucher Management responds with a Commit Voucher Redeem acknowledgement (CVR_Ack) to the BeClientIF which is reported back to the voucherDelegator.
8 The voucherDelegator processes the message and informs the request initiator of the successful voucher redemption wallet recharge.
9 The voucherDelegator then initiates the createEDR action for the relevant EDRs to be produced on the Diameter Server.
10 If either the voucher redemption or the wallet recharge failed, appropriate Not Acknowledgment (Nack) messages at each stage and this is recorded in the final set of EDRs generated.

Bad PIN

The ACS voucherDelegator also handles Bad PIN processing and notifies the BE that controls wallet recharging if a subscriber (MSISDN) has failed to redeem a voucher.

Diagram

Here is an example of Bad PIN processing on a split-domain wallet and voucher network. Note that the third-party billing engine server is also the Diameter Server in this example.

Figure 2-2 Bad PIN Processing in Split-Domain Network

Here is an example of Bad PIN processing on a split-domain wallet and voucher network. Note that the third-party billing engine server is also the Diameter Server in this example.

Checking Voucher Bad PIN

This table describes an unsuccessful voucher redemption due to a Bad PIN.

Table 2-4 Unsuccessful Voucher Redemption Due to Bad PIN

Stage Description
1

When VWS-Voucher Management receives a Voucher Reserve (VR_Req) request, it checks whether:

  • The VWS holds the details for the requested voucher
  • The voucher PIN number is correct
  • If the voucher can be redeemed

If the voucher PIN is incorrect, VWS-Voucher Management updates the bad PIN counter and returns a Bad PIN Increase (BPIN) count to the BeClientIF which informs the voucherDelegator.
2 On successive Bad PIN attempts, the voucherDelegator cancels the voucher redemption and sends a Revoke Voucher Redeem (RVR) request to the BeClientIF which is passed onto VWS-Voucher Management.
3 VWS-Voucher Management responds with a Revoke Voucher Redeem (RVR_Ack) acknowledgement which means that the voucher redemption request stands cancelled.
4 The voucherDelegator then sends a Bad PIN request to the dcdBeClientIF in an attempt to cease any transactions on the wallet domain.
5 The dcdBeClientIF constructs a CCR with a BadPINRequest action and notifies the Diameter Server.
6 The Diameter Server confirms and sends a CCA back to the dcdBeClientIF with a BadPINResponse, which is reported to the voucherDelegator.
7 The voucherDelegator processes the message and informs the request initiator that the voucher redemption was unsuccessful.
8 The voucherDelegator then initiates the createEDR action for the relevant EDRs to be produced on the Diameter Server.