Aayush: weblog

Archive for the ‘S-CSCF’ Category

Scalability Planning for the IMS Charging architecture

Posted by Aayush Bhatnagar on November 4, 2009


The IP Multimedia subsystem provides a well defined and streamlined architecture for charging multimedia calls and services. The IMS network elements interface to the charging platform over the DIAMETER protocol to enable both pre-paid and post-paid charging.

Architectural Overview of IMS Charging:

The IMS charging platform is sub-divided into two major components:

1. The Charging Data Function (CDF).

2. The Online Charging System (OCS).

The CDF is responsible for receiving triggers for offline (post-paid) charging, while the OCS  is responsible for receiving pre-paid charging triggers. The CDF supports the Rf DIAMETER application, while the OCS supports the Ro DIAMETER application interface.

The Charging Detail Records (CDRs) are collected and co-related at the Charging Gateway Function (CGF). The CGF acts as a gateway to the Billing System, which performs mediation duties.

Scalability Challenges:

In the IMS architecture, the P-CSCF, S-CSCF, SIP-application servers, MRF ,MGCF,BGCF and the I-BCF all need to support the offline charging application interface (Rf interface). This means, that they all act as charging clients (CTF) in case of post-paid scenarios and send triggers to the CDF.

The S-CSCF, the MRF and SIP Application servers support the online charging interface towards the OCS. The IMS Gateway function facilitates the online charging functionality in the IMS architecture by acting as a SIP AS.

A quick look at this architectural challenge, presents us with a nearly all connected architecture for the CDF (it interfaces with almost all network elements for postpaid charging). This means, that the CDF acts as a multiplexer of incoming DIAMETER commands.


Even for a simple IMS call, the CDF will receive triggers from the P-CSCF and the S-CSCF. If there is an application server involvement (Eg: Supplementary services) in the call flow, it will receive a trigger from that AS as well. If an I-BCF is present in the network, and the call needs to be terminated in another IMS domain, the I-BCF will also send a trigger to the CDF. This is a very practical scenario, as almost all IMS customers will subscribe to at least one supplementary service and every IMS core network is expected to have border control and peering functions for security (I-BCF acting as an entry and exit point to the network).

This translates into four DIAMETER transactions for the CDF for a single IMS transaction. A single IMS call initiated by an INVITE may have multiple chargeable transactions involved (those for UPDATEs, RE-INVITEs and finally for BYE).

The OCS interfaces with only the S-CSCF, the MRFC and SIP application servers. Hence it is expected to be less loaded as compared to the CDF as shown below:


Scalability Requirements Quantified:

Let us take an example of one IMS call for the sake of calculation. A reasonable load of 100 calls per second is assumed in the calculations.

We will only consider “chargeable” transactions i.e. transactions for whom a DIAMETER trigger will be sent to the CDF. A single call can have an INVITE transaction, an UPDATE transaction, a RE-INVITE transaction (assuming there was only 1 re-invite in the call) and finally a BYE transaction. Thus, we have 4 “chargeable” transactions. For each transaction, a DIAMETER ACR/ACA exchange takes place between each network node and the CDF.

Even for a reasonable load of 100 calls per second on the IMS core, the DIAMETER transactions for the CDF will need to scale up to 1600 TPS. This provides us with a 1:16 scalability requirement for the Charging Data Function.

For the Online Charging System, only the S-CSCF (through the IMS GWF), SIP application servers (if any in the call path) and the MRFC send charging triggers.

For the sake of calculation, if we have one application server in the path of an IMS call, then a single IMS transaction will result in 2 DIAMETER transactions on the Ro interface. Taking the above assumptions, where a single call has 4 “chargeable” transactions, and a moderate load of 100 cps, the OCS requires to support 800 TPS. This provides us with a 1:8 scalability requirement for the Online Charging System.

The scalability factor requirement for both the CDF and OCS is considerable. In case of the OCS, the response time of the CCR will also affect the call setup latency, as the calls to CCR are synchronous. Unless a CCA is received, the SIP signaling is not put through.

Other considerations to plan for scalability:

In view of the above scalability requirements, we can now plan further on the nature of the deployment architecture of the CDF and the OCS.  Even though the scalability requirements for the OCS may seem to be half (800 TPS) of what is projected for the CDF (1600 TPS) , but the complexity of the OCS is much more as compared to the CDF. The online charging system has many internal modules responsible for real-time rate determination, calculation of the units to be debited and account balance management. Moreover, these modules need to be invoked for each IMS call. The OCS also needs to support time based and content based charging paradigms. This means, that the OCS node is a mission-critical and real-time charging engine. Apart from real-time traffic, non-real time traffic such as pre-paid balance inquiries, pre-paid recharging etc also need to be handled at the OCS (either through an IVR or a SMS based mechanism).

On the other hand, the CDF is responsible for creating and dumping the CDR files. There is no real time rate determination or account balance management involved. The raw CDRs are transported to the billing system (BSS) over FTP, where the itemized billing and mediation takes place.

Deployment planning and possible scenarios:

In view of these architectural discrepancies and varying levels of complexities between the CDF and the OCS, it is clear that there needs to be an architectural separation between the OCS and CDF for deployment. This means, that we have to deploy both nodes independently on dedicated machines and possibly in their own independent clusters.

Let us consider a single IMS domain. A single IMS domain will consist of its own S-CSCF, P-CSCF, SIP application servers (as needed), MRF, I-BCF(or a comparable SBC) and the charging platform (consisting of the OCS and the CDF).

For greater scalability, it is proposed to have a dedicated cluster for each charging entity. The OCS application should have its own cluster and so should the CDF. Both the OCS and CDF may share the same gateway (CGF) to interface to the Billing domain. The clusters should have a DIAMETER load balancer (for the Ro and Rf applications) installed to distribute load amongst the cluster instances.

For hardware configuration, the cluster members may reside on the same machine (for smaller deployments) and on a hardware pair (active-standby) to achieve hardware redundancy. Usually, for carrier grade deployments, hardware redundancy is a necessity.

Discussed below are certain deployment configurations of the OCS and the CDF for varying load requirements. The deployment architectural choices shown below also consider hardware redundancy.

NOTE: “Servers” may vary from case to case. You may go for a T-1000, T-2000 or a higher end SUN server. You may also go for a “cheaper” option by using HP servers (8 cores and 16 GB RAM). For large-scale carrier grade deployments, an ATCA is a must (12 blades and above).

Deployment for up to 1 million BHCA (approx 270 CPS):

270 CPS is assumed to be the call rate of SIP signaling during peak load. This is the most common deployment scenario considered in telecom and usually serves as a benchmark.

For IMS deployments for up to 270 CPS, we can have multiple options. We may go for a HP server pair configured as follows:

a) Server-1 has CDF active and OCS as stand-by.

b) Server-2 has CDF stand-by and OCS as active.

This simple deployment will provide us with software and hardware redundancy, while also providing dedicated 8 core servers for each charging application (OCS and CDF).

Software redundancy can be performed by providing 2 independent processes of the CDF and OCS on each server (active) and 2 more processes of the CDF and OCS (for stand-by). A software load balancer may be used for distributing this load amongst the OCS and CDF processes.

This is called a 1+1 active-standby configuration. Each active instance of the CDF is expected to handle up to 4320 TPS at peak load. Each active instance of the OCS is expected to handle up to 2160 TPS at peak load.

This deployment scenario is shown below. The red-arrows depict change-over in case of hardware failure. Software fault tolerance is taken care of by switching between the software instances of the OCS and the CDF by using a software load balancer.


Each server may host multiple software processes for the CDF and the OCS. Each process can be a full CDF/OCS application in its own right. The load balancer may also be deployed in an active-standby configuration similar to the CDF and the OCS. The CDF and OCS active processes may be more in number, based on the scalability requirements. Each new process of the OCS or the CDF may be instantiated using a CLI or over SNMP, when the element management systems get an alarm of possible overload or traffic peaks.

This  kind of a deployment architecture is shown below:


Other interfaces for this deployment can be a command line interface (CLI) for polling the system and performing administrative tasks. Other interfaces will be over SNMP to the northbound management systems for monitoring the system health and servicing alarms.

Other possibilities:

In case of higher loads, the system can switch to a 1+1 Active-Active configuration, where all software processes of the CDF and the OCS are accepting DIAMETER requests. The load balancer will handle the distribution of the requests amongst the processes. In case the capacity is still not sufficient, new application processes of the CDF and the OCS can be started by firing the appropriate CLI command to scale horizontally.

For deployments for over 1 million BHCA, as shown earlier, the load on the charging platform will be even higher. For catering to such traffic, a time will come when the system needs to scale out. We may require a server pair for the CDF and the OCS dedicatedly.

Another interim option is to have all active CDF processes on one machine and all active OCS process on another machine and horizontally scale by increasing the number of processes.


This post was an attempt to quantify the challenges at hand for scaling the Charging platform in the conetxt of IMS. As seen, the requirements for scalability for the charging platform is more challenging than the other core network nodes. The scalability factors increase almost exponentially as the load on the IMS core increases. Hence, a robust scalability architecture needs to be devised for catering to the same.

Posted in 3gpp, DIAMETER, DIAMETER charging, I-CSCF, post-paid, pre-paid, S-CSCF | Tagged: , , , , , , | 12 Comments »

Integrating Ericsson SDS IMS Simulator with Mobicents and then rocking the house with Eclipse.

Posted by Aayush Bhatnagar on October 17, 2009


In this post, I will explain how to integrate the Service Development Studio (SDS) which emulates the entire IMS core network, the HSS, a DNS server and BGCF etc with the Mobicents communication platform (also called JBCP).

IMS application development and testing could not get any more productive for developers using this combination.

The IMS application server used here on top of Ericsson SDS is the Presence Server deployed on Mobicents.

This post will provide step-by-step instructions to achieve this integration along with informative screenshots:

STEP-1: Download and Install Ericsson Service Development Studio in Eclipse.

I am using Eclipse Galileo for this demonstration.

You can now download the SDS in your eclipse installation by using the Software Updates mechanism (the same way we install plugins). As shown in the figure below, go to HELP and then click on “Install New Software”. Then you add this website for installation:


[I have had queries that this URL is not working when “clicked”. This URL is not supposed to be clicked, but added to the eclipse website updates and installed there]

Once you do so, you should see a list of packages for installation. However, the packages will only be visible if you un-check the option that reads: “Group Items by Category”. Once you do this, you will see the packages that need to be installed.


You will need to accept the license for this software to proceed for installation as shown below:


Once the packages are installed, re-start Eclipse for the changes to take effect. Once you restart Eclipse, you will start seeing the views associated with SDS.

STEP-2: Configure the DNS server of SDS using Eclipse:

Now configure the DNS server with the domain of the Mobicents server hosting the Presence service. For this example I have used a well defined IP address belonging to my laptop. I got this IP by virtue of connecting to the internet. Save the domain name in the DNS server as shown —> presence.mobicents.com


Step-3: Configure the SDS HSS node for service control and service provisioning:

The next step is to configure the HSS.

Go to the HSS view as shown in the figure and configure the Service Trigger Point (SPT) for the Presence Service as shown below. The SPT is for the PUBLISH method, which is used by the presentity to publish their presence status to the server. By defining this SPT, we are telling the S-CSCF to make a routing decision for this message, whenever it is received.


Now, specify the definition of the SPT in the HSS view as shown. Define an initial filter criteria for this service, the SIP application server to be contacted (Mobicents in our case) and the default handling to be undertaken by the S-CSCF, in case Mobicents is not reachable.  The default handling here is SESSION_CONTINUED.


After the initial configurations of the DNS server and the HSS, it is time we start the action.

Step-4: Start the DNS Server:

Start the DNS server by clicking on SDS—>Server—>DNS—->Start DNS as shown in the figure below:


Step-5: Start the Call Session Control Function (CSCF):

Now start the CSCF by navigating to SDS—>Server—>CSCF—>Start CSCF.


Step-6: Start the Test agent acting as an IMS UE:

Now start the test agent by navigating to SDS—>Test Tools—>Start Test Agent as shown below.


Step-7: REGISTER the test agent with the Ericssion IMS SDS core:

Now create a REGISTER request as shown in the figure and register the test agent with the IMS core network. You can provision any number of users in the HSS and register them in the IMS core network.

In the figure, you can see that we can add and remove additional SIP headers as needed by us for testing


After creating the REGISTER request, send it to the IMS core network by clicking on the button and receive the 200 OK. You can also see the call flow in Eclipse that updates itself dynamically as the SIP messaging progresses.


Step-8:  Start Mobicents (JBOSS application server) on your machine:

Here, I am using Mobicents as the application server over IMS. Use the Presence Serve binary given here and start it on your local machine by issuing a run.bat -b <ip-address> command on Windows and a run.sh -b <ip-address> on Linux.

You can download the Presence Server binary from here:


Make sure that JAVA_HOME environment variable is set properly.


Step-9: PUBLISH your presence from the test agent:

Now, using the test agent send a PUBLISH request. Do not forget to add an Event:presence header to the request.


Send the request to the IMS core network. On the basis of our earlier configurations, the PUBLISH message will reach the Presence Server as shown below and is then processed by the Presence Server.


So, you can see, how productive it can be using the right open source tools and projects for IMS service development and testing. It can save you a lot of time and effort by using the right tools.

Instead of struggling with Open IMS core, SDS can be used for IMS emulation. On top of the IMS core, you can use the Mobicents platform for rapid service creation and deployment.

All this can be achieved by JAVA developers using familiar tools (Eclipse workbench) and on the same machine !

So guys, dont wait…try it out !!

Tell me how you liked this demonstration and give me feedback. Please feel free to post here, in case you encountered any problems, or if this demo helped you in any way.

Cheers !

Posted in 3gpp, DNS, Eclipse, Ericsson, HSS, I-CSCF, IMS, Mobicents, P-CSCF, presence, S-CSCF, SDS | 22 Comments »

3GPP IMS Release-9 Highlights and Changes.

Posted by Aayush Bhatnagar on October 13, 2009

3GPP IMS Release- 9 has been around for some months now.

From the IMS core network perspective, there have been certain additions and modifications to the procedures given in TS 24.229.

This specification acts as the ‘bible’ for any vendor wishing to implement IMS. This specification also changes and updates itself very frequently and usually comes with scores of additions and modifications in its quarterly minor releases.

Some of the major highlights of Release 9 are discussed.

The current release at the time of this post is 9.1.0 which is being discussed here.

As these changes are very low-level and implementation specific, it seems that there is still heavy refactoring going on in 3GPP for aligning the procedures for IMS and coming out with a stable set of procedures (atleast for the core network entities).

Such changes can be very difficult to spot and implement from the developer’s perspective.  Some changes given below can even force you to modify some of your use cases. Personally speaking, it becomes very frustrating when the procedures change so frequently. Atleast, there should be no changes/bugs in the core procedures of the IMS nodes.

IMPORTANT NOTE: Read on at your own risk. Not for the weak at heart.

Highlights, Changes and Additions:

1. Clarification in UE procedures for sending requests on protected ports to the P-CSCF regarding subsequent registration requests.

2. Addition and clarification in UE procedures regarding the usage of the ‘outboud’ parameter in the Supported header. It also includes a check whether the ‘reg-id’ and “+sip.instance” Contact header field parameters are present in the 200 OK of the REGISTER request.

3. Elaboration on the decision making of the UE regarding the S-CSCF behavior,  if the ‘outbound’ parameter was not present in the 200 ok for the REGISTER.

4. A note providing an implementation option to the UE in case Timer F expires at the SIP Stack.

5.  Change of procedures on the number of REGISTRATION attempts by the UE and in case of failure, the procedures that follow it (exception handling).

6. Removal of procedures at the UE that needed a check for Retry-After header for re-attempts for Registration.

7. Removal of procedures at the UE (2 postulates) when it sends a SUBSCRIBE to the network.

8. Removal of a check at the UE for sending a SUBSCRIBE for the debug event package.

9.  Addition of a postulate for generic procedures except the REGISTER request handling where now the protected port has to be added by the UE in the Contact header.

10. Refactoring of the abnormal exception handling use cases at the UE when it receives 504 error response.

11. Refactoring of procedures for emergency call handling at the UE and parsing responsibilities of the 3GPP IMS XML file received from the network

12. Additional responsibility at the UE to advertize support for draft-ietf-sipcore-keep for emergency IMS sessions.

13. Major refactoring on pages 92 and 94 regarding the interpretation of certain XML elements for emergency sessions initiated by the UE when it was registered using non-emergency registration procedures.

14.  Clarification note in P-CSCF procedures regarding protected ports in section

15.  P-CSCF procedural support for draft-ietf-sip-outbound, and addition of the ‘ob’ parameter in the SIP URI.

16. P-CSCF procedural support for draft-ietf-sipcore-keep

17. Clarification on point 6 for P-CSCF registration procedures when the request needs to be sent to an I-BCF

18. Change in point 7 of P-CSCF registration procedures in case the request has to be sent to the I-CSCF

19. Clarifications in points 8 and 9 of P-CSCF registration procedures while dealing with a UE behind a NAT and alignment with draft-ietf-sipcode-keepalive.

20. P-CSCF can now not close the TCP connection with the UE in case it has been detected to be behind a NAT !

21. P-CSCF can add the “received” parameter and the “rport” parameter in case SIP Digest without TLS is being used as the security mechanism with that UE.

22. Additional check at the P-CSCF in case SIP Digest WITH TLS is being used, that the FQDN in the Contact header resolves correctly to the IP Address bound to that TLS session. Here the P-CSCF will perform a reverse DNS query !

23. P-CSCF has to check whether there is an I-BCF in the network while sending out SUBSCRIBES to reg event packages. If there is no I-BCF, do a DNS lookup and send it to the I-CSCF, else send it to the I-BCF.

24. Major refactoring of procedures for the P-CSCF for general request handling in Section

25. Inspection of the host portion of the sent-by field of the Via header received from the UE at the P-CSCF. Check whether the IP address given there differs from the source IP from where the packet was originally received. Also add the UEs protected server port over there.

26. P-CSCF abnormal cases postulate (a) asks it to add some elements of the 3GPP IM CN subsystem XML body while sending an error response.

27. P-CSCF procedures, initial request for a dialog handling procedures, Section, postulate 5C, remove any P-Preferred-Identity headers if present.

28. Clarification in postulate 6 of section

29. P-CSCF procedures, section, postulate 2A now asks to remove P-Preffered-Identity header if present

30. Clarifications for postulate 3 of section

31.  P-CSCF procedures for generic response handling now require the inspection of the rport and received parameters before sending out any responses to the UE.

32.  In section, P-CSCF now has to remove any P-Preferred-Identity header if present. This is an extra check now.

33. Postulate 3, section, P-CSCF needs to remove the “comp” SIP URI parameter from the Record-Route header.

34.  P-CSCF needs to remove the P-Preferred-Identity field in section postulate 1A.

35. Clarification that the P-CSCF needs to support draft-ietf-sip-outbound in addition to 3261 for section while deciding upon the forwarding the request to the UE.

36.  Major refactoring additions of the procedures for the P-CSCF in section postulate 1A. Some 3-4 checks have been added.

37. Refactoring of point 3 of section Point 3 has been changed to align towards draft-ietf-sipcore-keep. So this postulate needs to be re-implemented.

38. Inspection and addition of the 3GPP IMS XML schema elements in section, postulate OA, points II and IV.

39.  Major major refactoring, removal and additions in the procedures of the P-CSCF in points 1, 1A, 2 and 3 of section Almost everything has been modified here ! Reimplementation required.

40.  P-CSCF abnormal exception handling procedures aligned to the processing of the 3GPP IMS XML body.

41. S-CSCF procedures for initial registration have to inspect the P-Access-Network-Info header to decide the authentication scheme to use for the UE.

42. S-CSCF procedures for receiving an unprotected register request additions to handle the REGISTER from an MSC enhanced ICS node.

43. S-CSCF derivation of IMPI for NASS IMS bundled authentication in case  the Authorization header is missing.

44. S-CSCF inspection of the “reg-id” parameter, the “ob” parameter and the “outbound” parameter in case of IMS AKA authentication, and sending of a 439 response.

45. S-CSCF procedures section, point 11 has almost been scrapped and the earlier checks removed.

46.  Digest URI need not match the SIP URI in case a reg-await-auth timer is running and SIP Digest is the mechanism used at the S-CSCF for authentication.

47. Inspection of the Authorization header to contain the “auth-done” parameter at the S-CSCF.

48. Clarification for the <ims-3gpp> element in 3rd party registration procedures.

49. Check for P-Served-User header in S-CSCF procedures section and associated procedures if its not present.

50. Addition of the P-Asserted-Identity header in the 504 response at the S-CSCF and the <ims-3gpp> element as well in the body.

51. Section, points 10 a and 10d of S-CSCF procedures have undergone major additions and refactoring. Re-implement it.

52. Removal of authentication parameter checks in point 3 section of the S-CSCF procedures.

I hope you all enjoyed this list. What it does to the developer is, that you go in a forced fixing loop and your focus goes away from adding more features…..to fixing existing ones and aligning them to the standard !

I just hope that we do not get a list of such major changes in the procedures in the next incremental release.

Please note, that these changes only account for those in the procedures of the UE, P-CSCF and S-CSCF. I-CSCF was fortunately untouched in this 3GPP Release. There might be many more changes in the procedures of other nodes such as the BGCF, MGCF, I-BCF, E-CSCF etc…which i have not listed here.

Posted in 3gpp, 3GPP TS 24.229, I-CSCF, IMS, IMS procedures, IMS Release 9, IMS UE, P-CSCF, S-CSCF | 5 Comments »