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.
VoLTE-VoLTE Call
For offline charging using Rf interface, the TAS implements the accounting state machine as described in the RFC 3588. The CDF acts as a server and assumes a role of the accounting state machine “SERVER, STATELESS, ACCOUNTING”. That means that there is no order in which the server expects to receive the accounting information. TAS generates ACRs during various stages of a call, to distinguish them, the ACR is using following types:
- START session accounting data.
- INTERIM session accounting data.
- STOP session accounting data.
- EVENT accounting data.
We recognize two ways of offline charging:
- Event based charging
- Session based charging
ACR types START, INTERIM and STOP are used for accounting data related to successful sessions.
In contrast, EVENT accounting data is unrelated to sessions, and is used e.g. for a simple registration or interrogation and successful service event triggered by a network element. In addition, EVENT accounting data is also used for unsuccessful session establishment attempts.
VoLTE Call – Rf Interface
Mandatory ACR Start and Stop messages are firstly sent when a SIP session is initiated and sent again when the SIP session ends. Additional ACR Interim messages are sent mid-session to signify that the session is still active. ACR Event messages are sent on receipt of non-session-related SIP messages, such as REGISTER, SUBSCRIBE and NOTIFY, and when a SIP session fails to initiate.
The content of ACR/ACA messages is defined in the 3GPP 23.299.
ACR Example
Basically within the ACR we can carry any information which might be used for charging as well as for traffic monitoring purposes. The most important AVPs are IMS-Information(876) and MMTel-Information(2030). Often we can also see an Operator’s specific data carried in ACR.
The response ACA mainly confirms, that CDF has received the request. It may also contain Acct-Interim-Interval AVP (AII), which indicates the desired intermediate charging interval.
ACA Example
In case a network element does not receive an ACA in response to an ACR, it may retransmit the ACR message. When the maximum number of retransmissions is reached and still no ACA reply has been received, then TAS buffers the generated accounting data in persistent memory (e.g. on disk). Once the CDF connection is working again, all accounting messages stored in the buffer are sent to the CDF, in the order they were stored in the buffer.
Other scenarios
The application of Offline Mechanism to Error scenarios or Supplementary Services is not too difficult. Mostly it is enough to remember, that ACR is sent only when we are clear about what we are doing. That usually means, when we get 200 OK for the related SIP Request.
For example if we want to update an ongoing call. e.g. to apply Communication Hold (HOLD)
Communication HOLD – Rf interface
Or if we want to perform Call Diversion
Call Forwarding user NOT Reachable – Rf interface
Probably the most complex flows are those related to SCC AS, where we have to create a record for each call leg. Anyways the general logic remains the same, just we can see twice that many ACR/ACA messages. For more details please refer to 3GPP 32.260.
Real Time Communication 