This IP Multimedia Subsystem or IMS tutorial explains the charging models and architecture for IMS based services with the help of examples.

IMS tutorial for Charging Types

The IMS  (IP Multimedia Subsystem) architecture supports both online and offline charging capabilities.

Online charging quick tutorial

Online charging is a charging process in which the charging information can affect an IMS subscribers balance while the services are being rendered. This type of charging requires direct interaction with session/service control. In practice, an operator could check the IMS subscriber’s account before allowing the subscriber to engage in a session and also to stop a session when balance is depleted. Prepaid services are applications that need online charging capabilities.

Offline charging quick tutorial

Offline charging on other hand does not require any interaction with session control or even checking the subscriber’s balance before allowing an IMS service. The charging information is not required to be sent in real time and therefore user balances are not updated in real time.

IMS tutorial for Charging models

The IMS architecture allows different charging models to be used. For example a service provider could charge only the calling party or it could charge both the calling party and the called party based on IMS resources used by each party (A single IMS session may include multiple media components such as audio and video and any party adding a new media could be charged for it). It is also possible for a provider to use different charging schemes at the transport layer versus an IMS layer.To provide this differential charging, an operator need correlation of the charging information generated at transport and IMS (service and content) charging levels. This capability is provided by a policy control reference point. [See 3GPP TS 22.101, TR 23.815 for more details].

ims tutorial example architecture

IMS tutorial on entities involved with online charging systems

ims tutorial example interfaces

S-CSCF (Serving – Call Session Control function) 

S-CSCF is an IMS component responsible for handling registration processes, making routing decisions, maintaining session states and storing the service profile(s).

S-CSCF interacts with OCS (Online Charging System) when using SCUR (Session Charging with Unit Reservation).

An example of S-CSCF in IMS Architecture would be charging for use time or duration for conference calling.

 

AS (Application Servers)

AS or Application Servers interacts with OCS for IEC (Immediate Event Charging) and ECUR (Event charging with Unit Reservation) in an IMS architecture.

An example of Application Server in IMS architecture would include charging for using a messaging service.

 

MRFC (Media Resource Function Controller) in MRF (Media Resource Function)

MRF provides media related functions such as media manipulation (For example voice stream mixing) and playing of tones and announcements. The MRF is split into Multimedia Resource Function Controller (MRFC) and Multimedia Resource Function Processor (MRFP). MRFC component may be included in the AS  component

Tasks of the MRFC  in an IMS charging architecture:

– Control the media stream resources in the MRFP

– Interpret information coming from an AS and S‑CSCF (e.g. session identifier) and control MRFP accordingly

– Generation of CDRs

– Advanced control of conferences (e.g. floor control)

Tasks of the MRFP in an IMS charging architecture:

– Control of the bearer on the Mb reference point

– Provide resources to be controlled by the MRFC

– Mixing of incoming media streams (For Example for multiple parties).

– Media stream source (For Example for multimedia announcements).

– Media stream processing (Examples include audio transcoding, media analysis).

– Manage access rights to shared resources in a conferencing environment (For example floor control).

Note: The Mp reference point allows an MRFC to control media stream resources provided by an MRFP.

 

P-CSCF (Proxy – Call Session Control function) – PCRF (Policy Control Resource Function) over Rx interface

The Rx reference point enables transport of information (For example dynamic media stream information) from the application function(AF) / P-CSCF to the PCRF. An example of this would be filtered information to identify an IMS session and its connection parameters (e.g. end points, media description).

This component helps with charging for a service flow (flow based charging) using an IMS service (examples include browsing, FTP etc)

An IMS Example

Here is an example to help understand the interaction of various components in an IMS architecture:

ims tutorial exampleUser starts an application to stream super bowl on existing data connection. This IMS based service is free with advertisement but there are charges when service is made ad free (one time charge of $30 for using IMS Service + any data charges).

Steps involved in the example:

· User starts his Super bowl streaming application which uses an IMS based streaming video service.

· The AF (Application Function) sends session information to PCRF over Rx.

· PCRF decides that this is a sponsored streaming session and there are no charges associated therefore it allows the game to be streamed (by responding to AF over Rx interface).

· User decides that since his home team is winning he does not want any advertisement interruption and selects a no ad version from his app (Information sent from device to AF over SDP).

· Application function sends session information to PCRF over Rx.

· The PCRF looks at the SDP parameters passed in the Rx message and communicates with PCEF to check balance information from OCS.

· Assuming user has enough balance, PCRF adjusts the rules in PCEF (over Gx) to ensure the QoS for this type of session.

(PUSH procedure (Unsolicited provisioning): The PCRF may decide to provision PCC rules without obtaining a request from the PCEF, e.g. in response to information provided to the PCRF via the Rx reference point, or in response to an internal trigger within the PCRF. To provision PCC rules without a request from the PCEF, the PCRF shall include these PCC rules in an RA-Request message. No CCR/CCA messages are triggered by this RA-Request)

User is charged for video via Ro interface as a onetime charge and for data via Gy interface. (Gy is a subset of Ro and is used for flow based charging.)