Hello, hello. Finally we are getting to Voice online charging! I admit it took me a long time, it be so nice to work just on posts … As a lesson learnt I’ll start to write shorter articles 🙂 And one more improvement – I’m adding quick overview video, so that you’re quickly briefed on the basics. Please let me know, if that works.
Online charging of MMTel services is based on general principles of Diameter Credit-Control Applications (Debit / Reserve Units Response) as specified in TS 32.299 and 32.260. The MMTel Charging of particular supplementary services is then further described in 3GPP 32.275.
The CTFs implementing the MMTel online charging functionality can be based on:
- Immediate Event Charging (IEC) with Debit Units Request [Event] generated, or
- Event Charging with Unit Reservation (ECUR), or Session Charging with Unit Reservation (SCUR), both with Reserve Units Request [Initial or Termination] generated.
The selection of a particular model (IEC, ECUR or SCUR), depends on the MMTel supplementary service and/or operator’s policy. The CTF uses Debit / Reserve Units Request[Initial, Update, Terminate] in procedures related to successful SIP sessions. It uses Debit Units Request[Event] or Reserve Units Request[Event or Initial, Terminate] depending on whether IEC or ECUR/SCUR applies) for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the TS 32.260.
That means that to successfully establish a multimedia call we need to implement at least SCUR – that’s what we will go through this time.
The communication between CTF (TAS) and OCS happens over the Ro interface, which uses the Base Diameter protocol. The CTF function of TAS triggers Online Charging Function (OCS) by Credit Control Request (CCR) message with CC-Request-Type AVP set to INITIAL_REQUEST. If known, the Network Element may include Requested-Service-Unit (RSU) AVP (monetary or non monetary units) in the request message.
If the service cost information is not received by the OCS, the OCS determines the price of the desired service according to the service specific information received by issuing a rating request to the Rating Function. If the cost of the service is included in the request, the OCS directly reserves the specified monetary amount. If the credit balance is sufficient, the OCS reserves the corresponding amount from the user’s account.
The OCS acknowledges the receipt of CCR message by sending back an Credit Control Answer (CCA). The CCA has the CC-Request-Type set to INITIAL_REQUEST. The main purpose of the message is to authorize the service execution through the Granted-Service-Unit AVP and possibly Cost-Information AVP indicating the cost of the service and Remaining-Balance AVP. The OCS may also return the Validity-Time (VT) AVP with value field set to a non-zero value. In case that the subscriber account balance has fallen below a predefined threshold, the OCS can indicate it in the Low-Balance-Indication AVP.
The CCR message with CC-Request-Type AVP set to UPDATE_REQUEST is sent by TAS between the INITIAL_REQUEST and TERMINATION_REQUEST either on request of the Credit-Control application within the validity time or if the validity time is elapsed.
TAS sends CCR with CC-Request-Type AVP set to TERMINATION_REQUEST to terminate the active Credit-Control session and report the used units. The OCS deducts the amount used from the account. Unused reserved units are released, if applicable. Finally the OCS acknowledges the reception of the CCR message by sending CCA message with CC-RequestType AVP indicating TERMINATION_REQUEST (possibly Cost-Information AVP indicating the cumulative cost of the service and Remaining-Balance AVP are included in the CCA message).
We could continue with more complex scenarios, but perhaps some other time. I guess this way it might be a bit easier to digest.
Real Time Communication 