Understanding the IMS Charging Architecture

Creating Rf Requests

Creating Rf requests is quite simple. Let's start with a session-based request. As explained before, after getting the RfApplication and RfSession, we use the RfSession object to create a new Accounting-Request. Since this is the first request, the requestType will start as a value:

ACR acr = session.createACR(RecordType.START);

For creating an Event request, the code is:

ACR acr = session.createACR(RecordType.INTERIM);

When creating a new Accounting request, the following AVPs are automatically populated:

Other AVPs can be added by calling one of the overloaded versions of the addAvp method:

Acr.addAvp(Attribute.EVENT_TIMESTAMP, new Integer(timestamp));

Creating Ro Requests

Requests for the Ro interface—for example, Credit-Control-Requests,—are created in a very similar way as creating Accounting requests. An example should clarify everything:

    CCR ccr = roSes.createCCR(RequestType.INITIAL);
    
    CCR eventCcr = roApp.createEventCCR();
     
    

In both cases, WebLogic SIP Server automatically sets the AVPs mentioned in the following table.

Other AVPs can be added by using the same method shown previously.

Diameter base attributes are available as static fields of the Attribute class. Additional, charging-related ones can be found in the classes Charging and CreditControl. WebLogic SIP Server does not limit the user to these predefined attributes. New ones can be created using one of the Attribute.define() methods. The Attribute class contains predefined constants for all base attributes. Here is an example of how to add an AVP:

public static final Attribute SUBSCRIPTION_ID_TYPE = Attribute.define(666, "Subscription-Id-Type", Type.INTEGER);

In the case of adding an AVP already defined by the container or by the user, WebLogic Sip Server throws an exception. Having added all the necessary AVPs, it is finally time to send the CCR. There are two ways to accomplish this:

    ccr.send();
    // - or -
    CCA answer = (CCA)ccr.sendAndWait();
     
    

The second method sends the CCR and blocks execution until an answer is received or a timeout occurs.

Receiving Answers

Answers can be received in two ways in the WebLogic SIP Server Diameter API. The first one is the synchronous way, based on the Request.sendAndWait() method. This method sends the request and blocks the calling thread until an answer is received or the request times out. It returns the received answer. The synchronous way of sending requests is appropriate for applications in which blocking the thread is not an issue.

The second, asynchronous way separates the actions of sending and receiving. The request is sent by calling Request.send(). This method returns immediately. When an answer is received, a listener will be notified by calling its rcvMessage() method. The listener must implement the SessionListener interface, and it must be set on the session before the answer is to be received. The example below demonstrates this:

    //This is a listener class
    class MyListener implements SessionListener {
    
    public void rcvMessage(Message message) {
    System.out.println("Received a message: " + message);
    
    if(message.getCommand().equals(CreditControl.CCA)) {
    System.out.println("The message is a Credit-Control-Answer");
    }
    }
    
    }
    
    //This code is inside some other (or the same) class, in a method
    //responsible for sending the request
    
    //Create session and listener
    RoSession roSes = roApp.createSession();
    MyListener myListener = new MyListener();
    
    //Set the listener on the session
    roSes.setListener(myListener);
    
    //Now create and send a request
    CCR ccr = roSes.createCCR(RequestType.INITIAL);
    ccr.addAvp(...);
    ccr.send();
    
    //send() returns immediately. Answer will be received in
    //myListener.rcvMessage()
     
    

The implementation with the listener also permits requests to be received that are sent by the server within the current session (for example, an Abort-Session-Request, sent when the server decides to immediately close the session). Requests are delivered to the listener's rcvMessage() the same way answers are. It is the application's responsibility to provide different behavior for requests and answers.

Error and TimeOut Handling

WebLogic SIP Server automatically detects a timeout condition when no answer is received for a request during a configured time. The default timeout value is configured in diameter.xml. It may also be specified on a per-request basis, using an argument to the send(...) or sendAndWait(...) methods.

WebLogic SIP Server handles the timeout by creating a response with result code DIAMETER_UNABLE_TO_DELIVER. The response is never actually sent over the network, but it is passed to the application that sent the request. This way of handling timeouts is analogous to the one used in SIP.

Also, WebLogic SIP Server can throw one of the following exceptions:

• MessageException is thrown for protocol errors, like an invalid message format.
• AvpException is thrown for invalid and/or missing AVP.

Debugging Application

WebLogic SIP Server has logging facilities that can be used to trace incoming and outgoing messages. You can configure the message debugging using the console. In addition, you can set the message debugging with the option -Ddiameter.Debug=true in the script file (sh file if you're running on a Unix-like machine, or cmd on the Windows platform). Debug messages are sent directly to the console.

Besides the debug settings in WebLogic SIP Server, it is also helpful to use a network sniffer. This type of program shows packets as they travel through the network. Probably the most popular one is Wireshark (formerly called Ethereal), which is free.

Sample Application

A simple demonstration application for the Ro and Rf interface can be downloaded. It provides Diameter Ro/Rf charging for a SIP session. On receipt of an INVITE, charging is started by sending a CCR of type INITIAL. Then, after all granted credits are used, it requests new credits by sending an UPDATE CCR. When a BYE is received, the charging session is closed by sending a TERMINATION CCR.

The session can also be finished by the application in case of end of credits. If a Final-Unit-Indication AVP is received in a CCA, and then all granted units are used, the application disconnects the SIP session by sending BYE. It also sends a TERMINATION CCR to close the Diameter session.

BEA Simulators and Rf Interface

BEA WebLogic Sip Server provides an easy way to test your own application using a standalone simulator for the Rf interface. The simulator that can be run as a standalone application from the simulator for offline charging interface is com.bea.wcp.diameter.charging.RfSimulator.

In addition, BEA provides an HSS simulator to store service-related data that can be run using the same approach. Note that this simulator is for testing purposes and supports only RepositoryData and PSI. The simulator for the HSS is com.bea.wcp.diameter.sh.HSSSimulator.

Command-line options for both simulators are:

• -r, -real Node real name
• -h, -host The host identity
• -a, -address Node listen address
• -p, -port Node listen port
• -d, -debug Enable debug
• -m, -mdebug Enable message debug

Here is an example of how to run a standalone BEA Rf simulator:

    java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator -r bea.com -h simulator -p 3900 -d -m
     
    

You can also run multiple simulators, like the HSS Simulator, using the following script:

    java com.bea.wcp.diameter.util.Launcher -apps com.bea.wcp.diameter.charging.RfSimulator,com.bea.wcp.diameter.sh.HssSimulator -h simulator -r bea.com -p 3900 -d -m
     
    

Remember to first run the setWLSEnv script that can be found in the \sipserver30\server\bin\ directory.

Proven Interoperability

Ericpol Telecom has successfully integrated its IMS Prepaid solution running on BEA WebLogic SIP Server 3.0 with Amdocs IMS Charging Solution. IMS Prepaid offers components that integrate and interoperate to provide a feature-rich, IMS-compliant, IN-interoperable, carrier-grade, prepaid solution. In this integration scenario, IMS Prepaid communicates with the Amdocs Charging Solution over the Rf and Ro interfaces. The network structure is shown below.

Figure 11. Architecture of network for BEA-Ericpol-Amdocs IOT (click the image for a larger version)

The interoperability testing (IOT) between BEA-Ericpol IMS Prepaid and Amdocs Charging consisted of two phases: offline and online charging. The message flows for each scenario are attached at the end of the article.

The IOT has proven that the Diameter implementation in WebLogic SIP Server conforms to the protocol specification. It has also shown that full programmatic control over the Java API makes the Diameter implementation very flexible. Small changes were needed a few times during the PoC. The implementation of these changes was quick and easy.

The Amdocs IMS Charging Solution utilized in the IOT was based on the Amdocs Online Charging system. In accordance with the 3GPP standards, this online charging functionality interacts with core IMS network elements via the Diameter interface (Diameter reference point Ro for Online Charging System interface). In addition, two key components of the Amdocs IMS Online Charging Solution are Amdocs Rating and Amdocs Balance Manager. To interact with the IMS call session control function for offline charging, the 3GPP standard for IMS defines two components: the charging data function (CDF) and the charging gateway function (CGF). These functions construct, correlate, format, and transfer the information about charging events to the billing system. Amdocs Service Mediation Manager, a part of the Amdocs IMS Charging Solution, was enhanced to comply with 3GPP standards and to inherently provide CDF and CGF capabilities.

As service providers race to implement IMS architectures and deliver more sophisticated offerings, they face questions of profitability and pricing, return on invested capital, quality of service, and more. Amdocs addresses those questions by employing a holistic approach to IMS charging with a horizontal, unified charging suite of modular IMS-ready products. As demonstrated in the successful IOT with Ericpol and BEA, the Amdocs Charging Solution presents the following benefits:

• True, real-time convergence across any line of business
• Rapid time to market for complex IMS offerings and products
• Flexibility for innovation and multiplay offerings
• Converged mediation
• Strict compliance to IMS standards

Conclusion

Diameter has proven successful in overcoming the limitations of RADIUS. It is now part of the IMS standard. Development of new IP- and telephony-based services is gaining momentum, and every service requires charging. Therefore, rapid growth in the usage of Diameter-based charging can be expected.

Having read this article, you should now be familiar with the basics of the Ro and Rf interfaces and how they can be handled using BEA WebLogic SIP Server. Now you have a good starting point to develop your own application.

Acknowledgments

The authors would like to thank Rafi Kretchmer, Product Marketing Manager, Revenue Management Product & Solutions Marketing, Amdocs. Rafi is responsible for defining the IMS business strategy for Amdocs' revenue management products, including the industry-leading Amdocs Billing portfolio.

References

• 3GPP TS 32.240 - charging architecture and principles
• 3GPP TS 32.260 - IMS charging
• RFC 3588 - diameter base protocol
• RFC 4006 - Diameter Credit-Control application
• Wireshark - open-source network protocol analyzer

Glossary

1. 3GPP - 3rd Generation Partnership Project
2. AAA - Authentication, Authorization, and Accounting
3. ABMF - Account Balance Management Function
4. ACA - Accounting Answer
5. ACR - Accounting Request
6. API - Application Programming Interface
7. AS - Application Server
8. AVP - Attribute-Value Pair
9. BGCF - Breakout Gateway Control Function
10. CCA - Credit-Control Answer
11. CCR - Credit-Control Request
12. CDF - Charging Data Function
13. CDR - Charging Data Record
14. CGF - Charging Gateway Function
15. CSCF - Call Session Control Function
16. CTF - Charging Trigger Function
17. DCC - Diameter Credit-Control application
18. GGSN - Gateway GPRS Support Node
19. GPRS - General Packet Radio Service
20. HSS - Home Subscriber Server
21. HTTP - HyperText Transfer Protocol
22. ICID - IMS Charging Identifier
23. I-CSCF - Interrogating-CSCF
24. IMS - IP Multimedia Subsystem
25. IMS-GWF - IMS Gateway Function
26. MGCF - Media Gateway Control Function
27. MRFC - Media Resource Function Controller
28. OCF - Online Charging Function
29. OCS - Online Charging System
30. P-CSCF - Proxy-CSCF
31. RF - Rating Function
32. RFC - Request For Comments
33. S-CSCF - Serving-CSCF
34. SGSN - Serving GPRS Support Node
35. SIP - Session Initiation Protocol
36. WLSS - BEA WebLogic SIP Server

Stefano Gioia is the WebLogic Sip Server Technology Specialist for BEA in EMEA. Focused on IMS opportunities with both operators and partners across Europe, the Middle East,and Africa

Tomasz Radziszewski is a Software Engineer at Research and Development in Ericpol Telecom.