Understanding Charging in the IP-Multimedia-Subsystem (IMS)

Before each service usage, the charging system must be asked for permission (credit authorization). The charging server must make a decision: Either authorize or deny the session.

For postpaid scenarios this is fairly easy: The charging-server only needs to collect the usage data for processing it at the end of the month. As no realtime account updating is needed, this is often called „offline-charging“.

For prepaid scenarios the charging server needs to know the user’s account balance and it will need to update the account in real-time. This is often referred to as „online-charging“.

Question: What is the double of the Radius?

Answer: It’s the Diameter!

As quite often, we use the Diameter-Protocol to do the Charging in the IMS. And as quite often, IMS uses a huge bunch of acronyms to describe the different interfaces: We call the diameter-interface for offline-charging the „Rf“-interface and the interface for online charging the „Ro“-interface.

Each system, that needs this credit authorization, have to be equipped with a proper charging trigger, a so-called charging-trigger-function (CTF) in order to communicate with the charging-server (also called charging-function):

Chraging Functions on Diamter


Offline Charging (Rf)

For the offlinc charging (Rf), we have the following two diameter-messages:

  • ACR – Accounting Request
  • ACA – Accounting Answer

Each request can have the following Accounting-Record-Type:

  • 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.
  • EVENT_RECORD – used for event-based accounting, e.g. a short message or similar

Online Charging (Ro)

For online charging (Ro), this get’s a little bit more complicated. The charging function needs to perform credit control before allowing resource usage. The prepaid subscriber needs to exist in the charging-server and all activities must be monitored by the charging-server. We must distinguish between the following two cases:

  • Direct debiting – the amount is immediately deducted from the user’s account in one single transaction. This could be for example a SMS or the ordering of a movie in case of Video-on-Demand.
  • Unit reservation – an amount is reserved by the charging-server. This is done, because the charging-server does not know yet, how many units are needed to provide the service. During the session, the used amount may be deducted and more units can be requested; at the end of the session the used sessions are reported in the final request. These sessions could be typically a voice- or video-call or a Pay-TV session, if you pay per usage.

As a result, we have the following three scenarios:

  • Immediate Event Charging (IEC) – used for simple 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

Session-/Event based Charging with Unit Reservation (ECUR/SCUR) – a practical example

But how does it look in reality? Let us make a more practical example:

Let us assume we have a subscriber, who has sufficient credit for 75 seconds of talking. The subscriber initiates a call; as we do not know, how long the call will take, we start with requesting credit for 30 seconds (CCR-Request, we could request any duration, e.g. 2 hours, but it would probably block other calls if we reserve all the required credit).

The call proceeds, so after 30 seconds we send another CCR-Request with the indication that we used the reserved 30 seconds and that we request another 30 seconds. We reduce the account of the subscriber by 30 seconds, so he has a credit of 45 seconds. Since 45 seconds is more than the requested 30 seconds, this second request can also easily be accepted and another 30 seconds can be granted. After this request, the account is at 45 seconds and we still (or again) have 30 seconds reserved.

Meanwhile the subscriber initiates a second call. We try to request again 30 seconds from the charging-server, but as our account is at 45 seconds of speaking time and since we reserved another 30 seconds for the first call, we can only grant 15 seconds for the second call. The last 15 seconds are now reserved for this subscriber; we have 45 seconds on the account of which 45 seconds are reserved.

Now the first call gets terminated: We only used 20 seconds from the granted 30 seconds. So we decrease the account of the subscriber by 20 seconds and we reduce the amount of reserved units by 30. We have 25 seconds in the account and we have still reserved 15 seconds for the second call.

As the second call is still proceeding, we will try to request another 30 seconds and we indicate, that we used the granted 15 seconds. The account is deducted by 15 seconds (the used units) and we can grant another 10 seconds for the second call, as this is the remains on the account.

After 10 seconds, no more units can be granted, so the call is teared down.

The following diagram is a graphical representation of the above example:

A detailed example


More news…

Why this topic? Because we are working on it 🙂

Carlos, our new crew member is working together with the Mobicents team on creating a charging-server, running on Java and Jboss. Meanwhile, I am working on the network part.

For a project in east-asia, where we integrate Kamailio into the largest mobile network of that country, we will integrate Kamailio into a Nokia-Siemens-Networks (NSN) infrastructure. Kamailio registers towards a Nokia VoIP Server (NVS) and it will do charging (based on Diameter/Ro) towards an IN System also provided by NSN.

Meanwhile, we are also busy with our german projects. Apart from providing state-of-the art voice-services, we will also provide operation and management for other core-network services such as RADIUS, DNS and DHCP in the very near future. The customer will use an QSC-Interconnect for reaching other networks, so we need to add an integration for number provisioning, too. I’d would have loved sending the traffic to my former employer Telefonica, but they failed miserably providing an API and compared to QSC they were simply too expensive for a similar service. Sorry folks, but our money (and the money of our customers) does not grow on trees!

If that was not enough to keep us busy, we are making huge steps towards the launch of our own integrated Class5 switch (the ng-voice TelcoSuite), which will be purely IMS based and will be deployed at the german carrier mentioned above.

We are having a great time!

To be able to tackle all these tasks, I am very pleased to announce that Carlos joined our team in the beginning of the month. He approached me several weeks ago if I would now anyone, who hire a freelance developer in Paraguay. Well, I did not know anyone, but he does fit perfectly in our team. He has a strong background on VoIP and IMS + he has some experience with the PHP and the ZendFramework, on which our provisioning and web-interfaces are based. I’ve personally met Carlos during our IMS-workshop in Asuncion, Paraguay last year, so I knew we could work very well together with him.

However, there a way more topics, I could tell you about; but that’ll have to wait, until it’s official.


So stay tuned, more to come,

Kind regards,


Share This Post:

Carsten Bock