Presently the CAMEL protocol provides powerful capabilities to perform real-time credit control but due to its high

functional bonding with circuit-switched call control and GPRS session management it is not really suitable for IP
network.
But the Telecom Standard bodies made other alternative mechanism to support online content charging, one
such example was OSA/Parlay framework that supports content-based charging API (specified by 3GPP/ETSI
and Parlay Group). But the applicability of OSA/Parlay charging API is limited to services that have been built
using the OSA/Parlay framework. So this solution was not the promising solution for the telecom's Future.
So the powerful and flexible Diameter session-based application with (start, interim, stop) accounting records are
utilized for this functionality.
When the user requests a service from the service node (example: Content server to download a wallpaper) the
end user may be authenticated and authorized. Then the service node contacts the credit control server
(subscribers Balance from the billing database)in order to check whether the user has credit on his account and
reserves units from the account for service Execution.
If the credit control server accepts the service request it returns the granted units to the service node. The
reservation is valid only for certain duration. Therefore the service node should contact the credit control server
again when the reservation time expires in order to refresh the reservation or when all the granted
Units have been consumed.
When the service node contacts the credit control server it reports the units (No of wallpaper or ringtone
downloaded) used this far and may request new credit reservation from the account.At the end of service, the
service node reports the used units to the credit control server that deducts the corresponding monetary amount
from the Users account (Then the subscriber balance is debited according to the usage of service).
Credit Control Application Messages

Credit Control Request (CCR)

Sent from client to server to request authorization for a given service

Credit Control Answer (CCA)

Sent from server to client and carries the result of the corresponding authorization request

Reauthorization Request (RAR)

Sent by server to trigger a new CCR, e.g. after successful credit replenishment during a service

Reauthorization Answer (RAA)

Sent by client as an answer to RAR
There are two modes of operation supported by Credit control application
Session and Event Based
Event Based
A single CCR/CCA exchange in each session
Used when it is sure that requested service event will be successful
Session Based
Multiple CCR/CCA exchanges in a session
Required when there is a need to reserve credits before providing the service
Requires state maintenance on the server side
Server first reserves the credits and debits them after receiving the subsequent CCR

Understanding Credit Authorization Models

RFC 4006 defines two basic types of credit authorization models:

Credit authorization with unit reservation, and

Credit authorization with direct debiting