VoLTE Online Charging – SMS

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.

VoLTE Offline Charging – Voice Call

In the last post we talked about VoLTE charging on a high level. This time we will zero-in and focus on a role of Telephony Application Server (TAS) in offline charging during a Voice/Video Call. Charging on the TAS is described in the 3GPP 32.260 and 32.275. The basic charging is fairly simple, but we also have to count with Supplementary Services, Roaming Scenarios and rainy-days scenarios.

TAS Charging, Ro, Rf

We already know that the 3GPP specification requires Network Elements like TAS to provide offline billing so that service providers can collect and correlate charging information from a variety of sources as well as to generate CDRs. An IMS system is composed of many entities that can generate charging events which need to be collated in order to generate a bill for the customer. These elements are referred in our terminology as the Charging Trigger Functions (CTF). The CTF function works in connection with TAS call processing by receiving SIP call events, translating SIP messages into Diameter messages with call parameters copied into 3GPP-defined AVP set, and sending Accounting Request (ACR) messages to the external CDF. The CDF acknowledges the receipt of ACR message by sending back an Accounting Answer (ACA) message indicating success or failure of the operation. The communication between CTF (TAS) and CDF happens over the Rf interface, which uses the Base Diameter protocol.