Today we will start with Online Charging, or Ro interface in our terminology. And because Online Charging is a bit more complex than Offline Billing, we’ll split it into several posts. In this first one we will take a look at so-call Direct-Debiting, which is used mainly for charging of SMS Service.
Perhaps from our Charging Overview you remember that we can use two different approaches to the Online Charging – Session based or Event based. SMS Ro Charging is using Event based mechanism. It is easier than the Session based and we will also need it later to complement the Session based Charging for the Voice service.
The SMS Charging architecture is standardized in 3GPP 32.274, the SMS online charging then uses the Credit-Control application as specified in TS 32.299.
Ro Reference Point for SMS
The Online Charging is triggered over Ro Reference point. It is up to a Mobile Operator if they will signal charging operations from IP-SM-GW, SMSC, SMS Router or any combination of these. Typically the charging requests are sent from SMSC only. For simplicity we will refer only to the SMSC in the following text. SMSC may either directly support Ro interface, or it can use CAP (CAMEL) protocol which is then translated to Ro by an Interworking Function (IWF) as described in 3GPP 32.293.
The SMS charging may use two different models:
- Immediate Event Charging (IEC)
or
- Event Charging with Unit Reservation (ECUR)
In this post we will rather focus on IEC, as the ECUR is more complex and in my personal experience it is less common than IEC. The ECUR principle is specified in TS 32.299.
IEC directly maps to Direct Debit model described in RFC 4006. In contrast to session based charging, the credit authorization with direct debiting is a single transaction process wherein the OCS directly deducts a suitable amount of money from the subscriber’s account as soon as the credit authorization request is received. Upon receipt of a successful credit authorization answer, the credit-control client – SMSC in our case – allows service delivery to the end user. This process is accomplished with the one-time event. Charging session state is not maintained.
SMS Debit
Note, that in a multi-service environment, an end user can issue an additional service request (e.g., data service) during an ongoing service (e.g., voice call) toward the same account. Alternatively, during an active multimedia session, an additional media type is added to the session, causing a new simultaneous request toward same account. Consequently, this needs to be considered by OCS when credit resources are granted to the services.
The credit-control application also supports operations such as service price enquiry, user’s balance check, and refund of credit on the user’s account. These operations are accomplished with the one-time event. Session state is not maintained. Not all of them are always supported or implemented, but refund operation is a must.
The Refund Account procedure employs the Debit Units Request (Refund Account) request and response messages. The procedure is defined in IETF RFC 4006.
SMS Refund
3GPP 32.299 and 3GPP 32.274 specifications are adding additional AVPs that are required for Debit / Reserve Units Request and Debit / Reserve Units Response messages.
In the Credit-Control-Request message, the CC-Request-Type is set to the value EVENT_REQUEST and the Requested-Action AVP is set to DIRECT_DEBITING. The Subscription-Id AVP should be included to identify the end user in the OCS.
The Diameter credit-control client may include the monetary amount to be charged in the Requested-Service-Unit AVP, if it knows the cost of the service event. If the Diameter credit-control client does not know the cost of the service event, the Requested-Service-Unit AVP can contain the number of requested service events. The Service-Identifier AVP indicates the service concerned.
In the Service-Information AVP we can then find the SMS service specific data such a Originator / Recipient Address, Message ID, Message Size, Delivery Report Indication, SCCP addresses etc. This information is important for charging (e.g. based on it we can identify MO/MT charging) as well as for statistical and monitoring purposes.
SMS CCR
The OCS returns the Granted-Service-Unit AVP in the Credit-Control-Answer message to the SMSC. The Granted-Service-Unit AVP contains the amount of service units that the SMSC can provide to the end user. The type of the Granted-Service-Unit can be time, volume, service specific, or money, depending on the type of service event. If the OCS determines that no credit-control is needed for the service, it can include the Result-Code indicating that the credit-control is not applicable (e.g., service is free of charge). In general, the Result-Code AVP is the most imporant parameter of the CCA.
SMS CCA
In case the SMS Delivery fails (e.g. Retry Scheme is exhausted or we get a permanent failure) then SMSC has to refund the charged user. The SMSC have to set CC-Request-Type to the value EVENT_REQUEST and the Requested-Action AVP to REFUND_ACCOUNT in the Credit-Control-Request message. (Refund is applicable also to other types of services, for example, gaming services.)
SMS CCR Refund
Overall the Online Charging of SMS service is not too complicated. Also it is much easier to deal with the situation when the OCS node fails, as we don’t maintain any charging session.
OCS Failover
In case the primary OCS is not available the SMSC takes a look at Credit-Control-Failure-Handling (it can be configured locally on SMSC). It can either TERMINATE the event request, or CONTINUE and re-send the request to an alternative server. If this fails the service is granted, even if credit-control messages can’t be delivered. Finally we can do RETRY_AND_TERMINATE, which means to re-send the request to an alternative server but, the service shouldn’t be granted when the credit-control messages can’t be delivered.
Real Time Communication 