Dev2Dev > Articles

---

Understanding the IMS Charging Architecture

by Stefano Gioia and Tomasz Radziszewski
07/25/2007

Abstract

Charging is an essential functionality for every service provider, including telecom operators. Therefore, any network has to contain a set of nodes dedicated to fulfilling this task. Charging can be realized as prepaid or postpaid. While prepaid solutions are gaining in popularity, postpaid ones are still in wide use. Therefore, any commercially viable telecom network must implement both of them. Moreover, the world of IT-based services is rapidly growing, and there are many more services than just telephony. A couple of examples include video telephony, wireless, and video on demand.

All of these services need a way to charge. This article describes the various IMS architectures that can be used for charging. It also describes how to implement them using BEA WebLogic SIP Server and the Diameter protocol.

IMS Charging Architecture

The IMS (IP Multimedia Subsystem) network uses architecture defined by 3GPP. The place of charging in this architecture is shown in Figure 1.

Figure 1. IMS charging architecture (click the image for a larger version)

The diagram in Figure 1 contains elements related to both prepaid and postpaid charging. These seemingly similar modes are substantially different from the network point of view. The most important difference is that when a user wants to use a prepaid service, the network has to decide whether it should be allowed, according to the user's current account balance. It has the following consequences for prepaid systems:

• Before each service usage, the charging system must be asked for permission (this is called credit authorization).
• To make this decision, the charging system must know the user's account balance in real time. It can't be achieved by collecting data about service usage and processing it at the end of the month (batch processing), as is usually done in postpaid systems. Each usage event of a prepaid service must cause immediate deduction from the account.
• There must be an efficient way of handling the condition that the charging system doesn't respond within an appropriate period of time; the user can't wait indefinitely.
• The user must be able to check the account balance.

Because of the real-time account updating required in a prepaid scenario, this is also called online charging. Postpaid is called offline charging.

Offline Charging

The framework for offline charging is shown in Figure 2.

Figure 2. Offline charging architecture (click the image for a larger version)

This type of charging consists of the following nodes:

• Charging Trigger Function (CTF) - part of the service element, responsible for monitoring service usage and generating charging events based on it.
• Charging Data Function (CDF) - responsible for generating CDRs (charging data records), based on events received from CTF, and transferring them to CGF.
• Charging Gateway Function (CGF) - responsible for persistent storage of the CDRs and some preprocessing and error checking; it also collects CDRs from many CDFs and sends them to the billing system.
• Billing System - processes the CDRs to create some final output, which can be invoices for customers, for example.

The place for BEA WebLogic SIP Server in this architecture is the service element, together with the CTF.

Online Charging

Figure 3 shows nodes used in the online charging architecture:

Figure 3. Online charging architecture (click the image for a larger version)

Here's a description of the nodes:

• Charging Trigger Function (CTF) - is similar to the one used in offline charging, but it has to be able to interrupt service when the user runs out of credits.
• Online Charging System (OCS) - realizes the Online Charging Function (OCF), which is dependent on these functions:
• • Account Balance Management Function (ABMF) - stores and updates the amount of credits on a user's account.
  • Rating Function (RF) - determines the cost of service usage according to a tariff defined by the network operator.

The place for BEA WebLogic SIP Server in this architecture is the service element, together with the CTF.

IMS Charging Correlation

Today we have many different architectures and networks; there is a clear need to provide each network entity (like SIP Proxy) the right address of the charging elements. Since 3GPP has defined two types of charging element, the CDF and the OCS, it is possible to have more than a single instance of these elements. The way to identify the right element is to add to a SIP message a header to transport the addresses.

The offline and online charging functions addresses transferred in SIP signaling are encoded in the P-Charging-Function-Addresses. The P-Charging-Function-Addresses header contains the CCF and ECF parameters. Here is an example of the header:

P-Charging-Function-Addresses: ccf=192.168.100.1; ecf=192.168.100.2

There is also a need to identify and correlate charging information. This is addressed by the IMS Charging Identifier (ICID) and is shared between IMS elements involved in the same session/transaction. The ICID parameter is transported over the network in the P-Charging-Vector header in a SIP message. This header is inserted by the P-CSCF and contains the following parameters (description as per spec):

• IMS Charging Identifier (ICID) - mandatory.
• Access network charging identifier - used to correlate the access network charging data with the IMS charging data.
• Inter Operator Identifier (IOI) - identifies both originating (orig-ioi) and terminating (term-ioi) networks involved in a session/transaction. This is inserted by the S-CSCF and will be removed by the P-CSCF when the request goes outside the network.

Here is an example of such a header:

P-Charging-Vector: icid-value="655Ayet773+7389088787e"; orig-ioi=bea.net

Reference Model

Both online and offline charging procedures can be categorized into two distinct classes: Event-based charging and session-based charging.

• Session-based charging - used when there is a need to maintain a session for all through the service. Typically, there are at least two requests to the billing system:
  • Initial request - used for signaling the beginning of the activities of charging. This request type contains the data related to the session used by the user.
  • Intermediary request - used for updating the current session (for example, adding video to a voice call). This request is, of course, optional.
  • Final request - used for closing a session.
• Event-based charging - used for signaling activity of one-time billing following a particular event (for example, a SIP AS acting as a Redirect Server).

In the case of offline charging, the request is transported by Rf protocol. In the case of online charging, the protocol used is Ro. Both protocols are based on Diameter. One of the differences between the two consists in the maintenance of a state of session correlated to the charging session. In the case of the model Event, there is no need to maintain a session since it deals with a single application to an event. The concept of session, according to RFC3588, is "a related progression of events devoted to a particular activity."

Offline Charging: Rf Interface

Offline charging for both events and sessions between CTF and the CDF is performed using the Rf reference point, as defined in 3GPPTS 32.240. The Rf interface is used for non-real-time operations, where the unit utilized by the user will not be scaled by the wallet's user. This is achieved by sending Diameter requests from WebLogic SIP Server, acting as CTF to the CDF.

These messages are used to report accounting information to the CCF, and following the Diameter approach (one request, one answer):

• Accounting Request (ACR)
• Accounting Answer (ACA)

Based on the previous exposed models, for session-based charging, the Accounting-Record-Type AVP can have the following values:

• START_RECORD - used to start an accounting session, typically when the application receives a SIP 200 OK acknowledging an initial SIP INVITE.
• INTERIM_RECORD - used to update a session, for example, in the case of SIP RE-INVITE and/or UPDATE in the current SIP dialog.
• STOP_RECORD - used to stop an accounting session, for example, when the application receives a SIP BYE message.

In the case of a session-based charging, WebLogic SIP Server will automatically link the Diameter session to the currently active call state. This means that the call id is encoded in the Diameter session id.

Figure 4. Offline charging: Session-based model (click the image for a larger version)

For one-time accounting event, the value of Event-Type is EVENT_RECORD.

Figure 5. Offline charging: Event-based model (click the image for a larger version)

Online Charging: Ro Interface

The purpose of online charging is to furnish charging information to the OCS in order to perform credit control before the network resource usage is permitted. To this end, a prepaid subscriber account has to exist in the OCS, against which the resource usage can be billed. Therefore, all activities to assess the requested resource usage, to determine its value in monetary or other units, and to debit these units from the subscriber account, must occur prior to or at least during the resource usage—that is, online with respect to resource usage. Depending on the circumstances, a final evaluation must occur when resource usage ends. Therefore, two cases must be distinguished:

• Direct debiting - the unit credits are immediately deducted from the user account in one single transaction.
• Unit reservation - the unit credits are reserved by the OCS from the user's account mainly because, in this situation, the OCS doesn't know how many units are needed to provide the service. Upon the service termination, the amount of used credit is deducted from the user's account, and eventually any unit reserved and not used is released and added to the user's account.

Based on the above classification, the following three scenarios can be identified with respect to OCS:

• Immediate Event Charging (IEC) (of type Event-based charging)
• Event Charging with Unit Reservation (ECUR) (of type Event-based charging)
• Session Charging with Unit Reservation (SCUR) (of type Session-based charging

The procedure of event-based charging may occur with or without reservation of units from the subscriber's account and is identified with an Event Charging with Unit Reservation (ECUR) or an Immediate Event Charging (IEC). The CC-Request-Type will have the value of EVENT REQUEST. Figure 6 shows the relative IEC call flow.

Figure 6. Online charging: Event model (IEC) (click the image for a larger version)

Figure 7 shows the call flow related to a ECUR.

Figure 7. Event-charging model (ECUR) (click the image for a larger version)

For a Session Charging with Unit Reservation (SCUR), numerous interrogations are needed, and the behavior of WebLogic SIP Server (or a generic network element such as SIP-AS) in the case of the Direct Debiting is the following: Before supplying the service, a request must be sent toward OCS. Following the positive answer of authorization, WebLogic SIP Server can finally disburse the service. As any other Diameter request, a credit control request is identified by the Command-Code field; in this case, the code is set to 272. The CC-Request-Type AVP is used to identify a type of request and must be present in all CCR messages. The CC-Request-Type can have one of the following values according to RFC4006:

• INITIAL_REQUEST - used to start a session. The triggering SIP methods are INVITE (SCUR), NOTIFY (ECUR), MESSAGE (ECUR), REGISTER (ECUR), SUBSCRIBE (ECUR), REFER (ECUR), and PUBLISH (ECUR).
• UPDATE REQUEST - used to update information for an existing session. Typically, when a SIP 200 OK acknowledges a SIP INVITE, RE-INVITE, or UPDATE, or when you have an expiration of the reserved quota, a validity time expiry or other triggers.
• TERMINATION REQUEST - used to terminate a session, when we receive a SIP final response (4xx, 5xx, 6xx), aborting SIP session and SIP BYE.
• EVENT REQUEST - used when there is no need to maintain a session.

SCUR is shown in Figure 8.

Figure 8. Session-based model (SCUR) (click the image for a larger version)

Example IMS Scenario

A sample online charging scenario in IMS network is presented in Figures 9 and 10. When user A places a call, their phone sends a SIP INVITE request to the P-CSCF, which is an entry point to the operator network. It forwards the INVITE to the S-CSCF assigned to this user. It is assumed that P-CSCF knows the address of S-CSCF, because it was retrieved from HSS during user registration (not shown in the diagrams). Then, the S-CSCF detects that this call requires online charging and forwards the INVITE to the IMS-GWF (IMS Gateway Function).

Figure 9. IMS example scenario: Call set-up (click the image for a larger version)

The IMS-GWF can be regarded as a special kind of SIP application server, whose role is to provide communication with the OCS. On receipt of the INVITE, the IMS-GWF sends a CCR of type INITIAL to the OCS, in order to reserve some amount of credits for the call. The OCS responds with a CCA, containing result code DIAMETER_SUCCESS, indicating that the call is allowed. The CCA also contains information about the number of granted "service units." These units can be seconds of call duration, for example.

Upon receipt of the CCA, the IMS-GWF forwards the previously received INVITE back to the CSCF, which passes it to the called-party side of the network (I-CSCF, S-CSCF, P-CSCF, phone of user B). The IMS-GWF also monitors the usage of the granted units, by setting up a timer.

Then the phone of user B starts ringing and responds to the INVITE with 180 Ringing. This response has been omitted on the diagrams for the sake of simplicity, as well as any 100 Tryings. When the called party answers the phone, it sends 200 OK. This OK goes through various network elements to user A's phone, as shown in the diagram. The phone sends ACK, which is forwarded to the B side. The call is now established.

Figure 10. IMS example scenario: Call tear down (click the image for a larger version)

When all granted units have been used (that is, the timer in the IMS-GWF expires), a CCR is sent to reserve another portion of units. This time, the request type is UPDATE. OCS sends CCA with result code DIAMETER_SUCCESS, giving permission to continue the call. If the granted units were the last available credits on the user's account, the OCS answer would contain Final-Unit-Indication AVP. This would indicate that the call must be disconnected (or another specific action must be taken) after using the currently granted units. However, in our example this AVP is not present.

After this, user A decides to close the call and sends BYE. The BYE is forwarded through P- and S-CSCF to the calling-party side of the network and to the IMS-GWF, which sends CCR of type TERMINATION to the charging system. This CCR includes information about used "service units" (that is, about call duration in this case). The OCS responds with CCA and releases its internal resources related to this session (for example, memory, timers). User B's phone responds to the BYE with 200 OK, which is passed back to the calling party. The call is closed.

How to Implement This in WebLogic SIP Server

BEA WebLogic SIP Server contains a simple API supporting the Diameter protocol, including the Diameter Base Accounting and Diameter Credit-Control applications. This section shows how to configure and use the Diameter functionality.

Configuration

To use the Diameter functionality, the WebLogic domain must be properly configured. The configuration procedure consists of the following steps:

• Enable the Diameter custom resource.
• Create a network channel for Diameter.
• Configure Diameter nodes and applications.

These activities are described in detail on BEA documentation pages listed in the References section.

Initialization

Before a deployed application can use diameter Rf or Ro functionality, it has to obtain the RfApplication or RoApplication object, respectively. This can be accomplished with the following code, assuming that we are in a SIP or HTTP servlet class:

ServletContext sc = getServletConfig().getServletContext();

Node node = (Node)sc.getAttribute("com.bea.wcp.diameter.Node");

if(node == null) {
    throw new ServletException("Can't get Node. Check diameter.xml");
}

RfApplication rfApp = (RfApplication)
node.getApplication(Charging.RF_APPLICATION_ID);

if(rfApp == null) {
    throw new ServletException("Can't get RfApplication. Check diameter.xml");
}

RoApplication roApp = (RoApplication)
node.getApplication(Charging.RO_APPLICATION_ID);

if(roApp == null) {
    throw new ServletException("Can't get RoApplication. Check diameter.xml");
}

Session Handling

Diameter has a concept of session. Formally, a session is "a related progression of events devoted to a particular activity," according to RFC 3588. Practically, it begins with ACR(START) or CCR(INITIAL) and ends with ACA(STOP) or CCA(TERMINATION). In the case of a one-time event, the session consists only of the request and the answer. All messages belonging to one session are correlated by common value of the Session-Id AVP.

In the WebLogic SIP Server API, diameter sessions are mapped to com.bea.wcp.diameter.Session objects. The Session class handles the Session-Id AVP. It has special subclasses for the Rf and Ro interfaces, namely RfSession and RoSession, which simplify handling of requests and answers specific for Diameter charging. The session object can be created using Rf/RoApplication:

RfApplication rfApp = ...
RfSession rfSes = rfApp.createSession();

RoApplication roApp = ...
RoSession roSes = roApp.createSession();

In addition, Diameter sessions are serializable, and you can store them as attributes in the SipApplicationSession, and vice versa. WebLogic Sip Server automatically links the session to the active call state. Upon receipt of a message, the container will automatically retrieve the call state to find the Diameter session.

Pages: 1, 2

Next Page »