IMS Notes

IMS (IP- Multimedia Subsystem):

IMS is an architectural framework for delivering IP multimedia services. IMS is a global,

access independent and standard based IP connectivity and service control architecture that enables
various type of multimedia services to end user using common internet-based protocols.

IMS used ITEF protocols wherever possible i.e. SIP (Session Initiation Protocols).

ITEF (Internet engineering taskforce) is a protocol factory for internet world. But it does not
define the ways that they are used especially in the mobile domain. 3GPP is the body that took SIP
as a control protocol for multimedia communication and 3GPP has built a finite architecture for SIP
based IP multimedia services machinery (the IMS).

LTE Architecture:

The UE
The UE is the terminal of the IMS architecture and resides with the user. In IMS, the UE
contains a Universal Integrated Circuit Card (UICC) and a
Session Initiation Protocol User Agent (SIP UA).

SIP, the protocol used for IMS messaging, is defined in the

IETF’s RFC 3261.

THE EVOLVED PACKET CORE (EPC)

The all-IP EPC used in LTE is a part of the transport block of the architecture, where
“transport” is the entity through which the overall network (e.g. the LTE Evolved Packet System
[EPS]) is accessed. The transport block includes backhaul/backbone as well as the access network.
The Public Data Network Gateway (PDN-GW or PDG)
The PDN-GW is a well-known entity in legacy digital networks, offering the UE access to
public digital networks (e.g. the Internet). In IMS there are typically separate PDN-GWs offering
access to the Internet and the IMS network.
In the case of LTE, the PDN-GW also serves as a mobility anchor point for users moving between LTE
services and non-3GPP services.

Policy and Charging Rules Function (PCRF)

The PCRF provides real-time determination of what types of traffic are allowed under what
conditions and determines how to account for this traffic (for billing purposes). Based on requests
for IMS services, the PCRF also initiates the appropriate bearers. Examples of PCRF functions might
be:

• If a multi-user game is offered and the user attempts to start the service, the PCRF will determine
whether that user is authorized for the service.
• A network operator may determine that third-party VoIP services are allowed to use Wi-Fi
connections but not cellular connections. When a VoIP application is launched, the PCRF will
determine whether the application may continue.
• If a user attempts to launch a VoLTE call (and is authorized to do so), the PCRF will initiate the
setup of the dedicated bearer.

THE IMS CORE:

Call Session Control Function (CSCF)

The CSCF is responsible for establishing, monitoring, supporting and releasing multimedia
sessions. It is comprised of three separate entities which may or may not be separate physical
entities:
Proxy CSCF (P-CSCF)
The P-CSCF is seen as the initial point of contact from any SIP User Agent. It handles all
requests from the UE and is, from the UE’s point of view, the “SIP proxy” to the entire subsystem
(via the I-CSCF and/or S-CSCF). It may include a Policy Control Function (PCF) responsible for
enforcing QoS policies on media. In terms of policy-based networking outlined in RFC 27535, the PCF
is the policy server, or Policy Decision Point (PDP). This is separate from the PCRF described earlier,
which enforces policy on the transport network. Logically, the P-CSCF is considered part of the
visited network.

SIP Compression

SIP is a client server text-based protocol used to create control and terminate the multimedia
session with two or more participants.

SIP includes message, headers, header parameters, extensions, security related information’s etc. So
it causes unexpected and unacceptable delay in setup due to which overall system performance
goes down.
So 3GPP mandate SIP compression for both UE and P-CSCF.

Sigcomp: It is a mechanism that application protocols used to compress message before sending
them across the network.
Sigcomp uses UDVM (Universal decompressor virtual machine) to decompress message.

UE Compressor P-CSCF
Dispatcher

In the first message, information will go, which P-CSCF will save by creating
state/compartment. So that for further SIP message decompression, some information can be used.
No need to share decompression information again and again.

If first 5 bits of message is 1, then it will be clear to decompressor dispatcher that message is
compressed. It will send this message to UDVM. UDVM request previously created states from state
header and use it. UDVM will send this message to application layer after decompression.

Application Layer

Compressor Decompressor
Dispatcher Dispatcher

Compressor State 1 UDVM

Transport layer
IP Sec Security:
➔ Negotiation of security mechanism between UE and P-CSCF.
➔ Established a SA during initial registration
➔ In first registration, 401 responses will transport information and negotiate mechanism
which will be uses for SA’s.
➔ SA: - Logical connection between UE and P-CSCF that allow the secure exchange of SIP
message.
➔ SA’s will be created once IK key authentication is done.

UC Respons
Request PS
e
Request
US PC
Response

In SIP security mechanism agreement 4 ports are negotiated.

➔ So CK and IK will be sent from SCSCF TO PCSCF within www authentication header in 401
responses.
➔ IK and CK are removed from header and is stored by P-CSCF (rest will send to UE).
➔ IK: - shared key fir rest of SA’s.
➔ UE calculates the IK from the challenges received in 401 response and use it as shared
key.
➔ After verification of IK is done, SA will be created. SA will have expiry (temporary
lifetime)
➔ While sending 200 OK response to UE, P-CSCF will update the lifetime of set of SA’s.
UE will also update once it gets the 200 OK response.

Re Authentication:
Means new set of SA. So now (1) Old set of SA and (2) New set of SA, are available
➔ P-CSCF has no information about new set of SA, as it does not know whether 200 Ok
response has received by UE. So, P-CSCF will use old set of SA until UE sends any request
on new set of SA.
➔ P-CSCF will send all information in old set of SA and keep both set of SA active until one
of them expires. Same applies to UE.
➔ When UE sends request on new set of SA first time, then P-CSCF will come to know that
new set of SA can be used.
*Note- Old set on SA will nor dropped immediately because response on new set of SA is
not possible for the request which is sent on old set of SA because port number for the
response is defined in Via/Contact header.

Serving CSCF (S-CSCF)

The S-CSCF is a SIP server logically seen as part of the home network and is analogous to the
Home Location Register (HLR) used in GSM. It “knows” about the user and what applications are
available to the user and is a decision point as to whether the user’s SIP messages will be forwarded
to the application servers.
The S-CSCF also stores addresses used for contacting the UE, so that it can be used in future
sessions. It is also the enforcement point of the network operator’s policies.
 ➔ S-CSCF is focal point of IMS
➔ It is responsible for registration process.
➔ Making routing decision.
➔ Stores service profile.
➔ When a UE sends a registration request it will be routed to S-CSCF. WHICH downloads
authentication data from HSS based on authentication data challenges to UE.
➔ After getting response from UE, S-CSCF accepts the registration.
➔ Based on data downloaded it decides which application server is contacted when user
send SIP request.

Interrogating CSCF (I-CSCF)

The I-CSCF is the entity that initiates the assignment of a user to an S-CSCF (by querying the
HSS) during registration. It is “seen” by the IMS core as a proxy to an individual user and is a liaison
for SIP messaging between the user (via the P-CSCF) and the S-CSCF.

Home Subscriber Server (HSS)

The HSS is a database that maintains user profile and location information and is responsible
for name/address resolution. It is also responsible for authentication and authorization, but unlike in
legacy technologies, authentication with the radio access network and the core can be different.

➔ HSS is main data storage for all subscriber and service-related data of IMS.
Data: user identities, registration information, access parameters and service triggering
information.

Subscriber Location Function (SLF)

The SLF keeps track of multiple HSS in a home network and is responsible for assigning one
to a user.

Media Gateways
For detailed descriptions of the gateway interfacing between SIP-based networks and the
legacy PSTN, see RFC 33726.
➔ IMS Media gateway provides user plane link between CS and IMS.
➔ IMS media gateway provide tones and announcement to the CS users.

Media Gateway Control Function (MGCF):

The MGCF controls media gateways (MGWs), performs transcoding (converting codecs, for
example from EVRC to WB-AMR) and the conversion of media between the Real-time Transport
Protocol (RTP) used in IMS and the Pulse-Coded Modulation (PCM) used by a circuit-switched
network. Depending on how a network equipment manufacturer decides to implement, the MGCF
may also serve as the breakout to a circuit-switched network. In that case the MGCF is also
responsible for managing the conversion of signaling messages, converting SIP messaging to the
Bearer Independent Call Control (BICC) and ISDN User Part (ISUP) protocols used in legacy systems.
Breakout Gateway Control Function (BGCF)
If an MGCF does not include the breakout to a circuit-switched network, that functionality is
performed by BGCF. When the BGCF does control this breakout, it does so by selecting an MGCF
(either in the same IMS network or another IMS network) or by selecting an MGW (on a non-IMS-
based network).

➔ For breakout SIP request is sent to BGCF from S-CSCF

CASE 1: -
If the breakout is in same network:

S-CSCF BGCF MGCF

CASE 2: -
If the breakout is in different network:

S-CSCF BGCF BGCF S-CSCF

IBCF (Interconnection border control function):

➔ Perform Interconnection between two operator domains.
➔ Enables communication between IPv6 and IPv4 IMS applications.
➔ Network topology hiding.
➔ Screening of SIP signaling information.
➔ Capability to translate between IPv4 and IPv6 address when IMS communication take
place between operators that are supporting different IP address version.
➔ IBCF is tasked to bridge these two domains by acting an ALG (application level gateway).
➔ The ALG functionality inside the IBCF controls transition gateway (TR Gateway) which is
responsible for providing IP version.

Possible deployments for Interconnection Border Control Function

MRFP AND MRFC:
Media Resource Function Processing
Media Resource Function Control

When CSCF gets INVITE message and find some incompatibility between two phones that
wants to communicate each other, it passes that information to MRFC. Then MRFC adjusts SIP
message, so that the call flow through MRFP which perform transcode from one to another codec.
Because each of the party is just using its own codec. But still can communicate with the other party,
who use different codec.
S-CSCF

UE MRFC UE
G7
11
G729

MRFP

MRFC ask MRFP to the following: -

➔ Play tone to the user. Play announcement to user (i.e. not reachable).
➔ Generate speech output from text input.
➔ Record audio or multimedia stream and store it into a file.
➔ Dialed DTMF digits (collect and report)
➔ Perform automatic speech negotiation.
➔ Transcoding of audio/video stream.

IMS Reference Point:

 IMS Architecture with Reference points

Sh Interface [Application Server <--> HSS]

This article shall give you the abstract of WHY and HOW Sh-interface works.
Sh is a DIAMETER interface; having application ID 16777217, between Application Server
(AS) and HSS. Application Server is place where services are executed e.g. Call-Forwarding services
related processing take place at Application server. Sh interface is used by AS to communicate with
HSS; Application Server uses HSS as repository, AS can put some of its transparent or Non-
transparent data, Transparent data is the information that HSS doesn't understand.
Also fetches subscriber information (such as Subscriber status, Location information etc.) from HSS.

This interface contains 4 messages.

1)User-Data-Request/Answer (AS--> HSS) [DATA Read]:
In this AS asks for subscriber related information from HSS; Subscriber related data at HSS
either provisioned by operator and/or received from network and/or earlier stored by AS itself with
the help of Profile-Update-Request/Answer.

2)Profile-Update-Request/Answer (AS-->HSS) [DATA Update]:

In this message AS stores/update its data at HSS for a particular subscriber and/or
application.

3)Subscribe-Notifications-Request/Answer (AS-->HSS) [Subscriber for Notification]:

In this message AS takes a subscription that whenever there is change data field, more
particularly for a given subscriber then I(AS) must be informed. Even some time AS can ask for
current data for a given subscriber in same Answer message.

4)Push-Notification-Request/Answer (HSS-->AS) [Notification]:

Here HSS downloads the Updated value of field at Application server, whose subscription is
earlier taking by AS; when-ever subscriber field changed either by Operator or Network.

Cx Interface [CSCF <--> HSS]

Idea of this article is to give the gist of Cx interface. Cx interface is used between CSCF(I,S)
and HSS. Before going to further details it would be better if we shall have a little idea about IMS
Architecture in respect of Cx Interface.
CSCF, HSS and AS are the 3 major entities in IMS. CSCF and HSS uses the Cx Interface to
communicate with each other. CSCF( Call Session and Control Function) has 3 entities(P,S and I) P-
CSCF (Proxy-CSCF) is used when a call enters in Network it act as Gateway of Roam domain and shall
tell which S-CSCF (Serving-CSCF) shall be used to fulfill the requirements of incoming call and
forwards the call/message to S-CSCF. S-CSCF interact with HSS to know what all facilities/services
this subscriber can use in its subscription and provide accordingly. If P-CSCF shall not have an
information about the S-CSCF that will fulfill the call, then P-CSCF takes help of I-CSCF (Interrogatory-
CSCF) to select S-CSCF. Now I-CSCF interact with HSS to get the information of best suitable S-CSCF
and tell to P-CSCF.
S-CSCF and I-CSCF interact with HSS on Cx interface with following messages have Cx
Application-Id 16777216.

1) I-CSCF and HSS

a)User-Authorization-Request/Answer (I-CSCF ---> HSS) :This message is used to check
whether an identity is allowed to roam or not.
 b)Location Info Request/Answer (I-CSCF ---> HSS) : This message is used to know the
identity(Name) of S-CSCF is used to fulfill the call.

2) S-CSCF and HSS

a) Multimedia-Auth-Request/Answer (S-CSCF ---> HSS): This message is used to
authenticate the subscriber's identity as well as the subscriber's network
b) Server-Assignment-Request/Answer (S-CSCF ---> HSS): This message is used to
download subscription profile at S-SCSCF.
c)Push-Profile-Request/Answer(HSS ---> S-CSCF): This message is used to download the
updated profile on S-CSCF if profile is changed by administrator at HSS.
d)Registration-Termination-Request/Answer (HSS ---> S-CSCF): This message is used for
administrative de-registration of a subscriber.

P-CSCF Discovery:
In order to communicate with the IMS, an item of UE must know at least one IP address of
the P-CSCF. The mechanism by which the UE retrieves these addresses is called “P-CSCF discovery”.
Two dynamic mechanisms for P-CSCF discovery have been standardized in 3GPP: the Dynamic Host
Configuration Protocol’s (DHCP) DNS procedure and the GPRS procedure.

PDP- Context Activation Method:

In the GPRS procedure, the UE includes the P-CSCF address request flag in the PDP
context activation request (or secondary PDP context activation request) and receives the IP
address(es) of the P-CSCF in the response. The mechanism the Gateway GPRS Support Node (GGSN)
used to get the IP address(es) of the P-CSCF(s) is not standardized. This mechanism does not work
with pre-Release 5 GGSNs.

GPRS specific mechanism for discovering P-CSCF

DHCP/DNS Procedure:
In the DHCP DNS procedure, the UE sends a DHCP query to the IP connectivity
access network (e.g., GPRS), which relays the request to a DHCP server. According to [RFC3319] and
[RFC3315], the UE could request either a list of the SIP server domain names of the P CSCF(s) or a list
of the SIP server IPv6 addresses of the P-CSCF(s). When domain names are returned, the UE needs to
perform a DNS query (NAPTR/SRV) to find an IP address of the P-CSCF. The DHCP DNS mechanism is
an access-independent way of discovering the P-CSCF.
 Discovering the P-CSCF via DHCP/DNS

Address of DHCP:

A generic mechanism for discovering P-CSCF

I-CSCF Discovery:

UE P-CSCF I-CSCF

IP of I-CSCF

DNS
HSS Assignment:

SLF
(Redirect to HSS 2)
LIA LIR
INVITE INVITE
I-CSCF

HSS 1 HSS 2 HSS 3

S-CSCF Assignment:
S-CSCF will be assign: -
➔ When a user registered with the network.
➔ When S-CSCF is needed to execute services on behalf of unregistered user.
➔ When a previously assigned S-CSCF is not responding.

P-CSCF I-CSCF S-CSCF

UE
S-CSCF
AVP
S-CSCF
HSS

AVP (attribute value pair) contains all capabilities of S-CSCF.

At the time of registration or for unauthorized user, AVP Contains: -
➔ A unique value for each mandatory capability and
➔ A unique value for each optional capability.
Based on these capabilities S-CSCF is assigned to user.
➔ If All mandatory and optional capabilities is matched, S-CSCF will be assigned. If not
match, then S-CSCF selection will be done by I-CSCF through best fit algorithm.
➔ In any case of deregistration like subscription is over or UE is stolen, HSS will initiate by
RTR (Registration termination request) and RTA (Registration termination answer).
➔ In SAR and SAA, S-CSCF tells HSS that it is serving to this particular UE. Now if any
request by UE (other than Register) i.e. INVITE will come then I-CSCF will get the address
of S-CSCF from HSS in LIR and LIA.

When Assigned S-CSCF is not responding: -

➔ S-CSCF reassignment will take place. Again, UAR request will go and query for all
capabilities for all S-CSCF form HSS and reassignment will take place.

In S-CSCF assignment sometimes may be user will deregister and customer requirement is,
when it will re-register, same S-CSCF should assign. When it will re-register, S-CSCF will store
its user profile (it tells HSS that user is deregistered, but I am keeping its user profile). This is
done to optimize Cx reference point.
Precondition: (Sec 12.6 page 373 in MIIKKA)
➔ It is a condition to be met before something begins.
➔ Resource reservation is mandatory before starting any session.
➔ Preconditions requires that participants reserve network resources before continuing
the session.

Why Precondition:
➔ Changes of session establishment failure are minimum.
➔ If resource reservation is not done for the session, call will not establish.
➔ To minimize ghost ringing.

SIP, SDP offer/answer and preconditions during session establishment

Attribute line status: -
INVITE: -
a=curr: qos local none
a=curr: qos remote none
a=des: qos mandatory local sendrecv
a=des: qos none remote sendrecv

183 Session in Progress: -

a=curr: qos local none
a=curr: qos remote none
a=des: qos mandatory local sendrecv
a=des: qos mandatory remote sendrecv

PRACK: -
As SDP is shared in 183, PRACK is in picture to make 183 reliable.

UPDATE: -
a=curr: qos local sendrecv
a=curr: qos remote none
a=des: qos mandatory local sendrecv
a=des: qos mandatory remote sendrecv

200 OK: -
a=curr: qos local sendrecv
a=curr: qos remote sendrecv
a=des: qos mandatory local sendrecv
a=des: qos mandatory remote sendrecv

Service Provision: -

Strictly speaking the IMS is not a service in itself; on the contrary, it is a SIP-based
architecture for enabling an advanced IP service and application on top of the PS network. IMS
provides the necessary means for invoking services; this functionality is called ‘service provision’.
IMS service provisioning contains three fundamental steps:
1. Define possible service or service sets.
2. Create user-specific service data in the format of initial filter criteria when a user
orders/modifies a subscription.
3. Pass an incoming initial request to an AS (Application Sever).

APPLICATION SERVER: -
➔ Service provisioning in the IMS is achieved by ASs, which are contacted on the basis
of initial filter criteria.
➔ UE will send SIP request to S-CSCF. Then S-CSCF will go through all IFC (Initial filter
criteria) one by one and, if one or more of them matches, they will send the request
toward the indicated AS.
➔ Filter criteria is downloaded at the time of registration from HSS to S-CSCF in SAR/SAA
message.
 Example:
we assume that there are three ASs that have set filter criteria for requests that
originate from Tobias. Tobias’s S-CSCF will check these filter criteria one by one against the
information received in the INVITE request:

Filter criterion #1 does not match, because the P-Asserted-Identity header, which is checked against
the Service Point Trigger (SPT) for the public user identity, does not include Tobias’s tel URL. Filter
criterion #2 does match, because:
➔ the INVITE request is received from the originating user – the S-CSCF knows this
from the user part it set in its Service-Route header entry and which is now returned in the Route
header.
➔ the P-Asserted-Identity is set to one of the public user identities that are
filtered(sip:tobias@[Link]).
➔ the SIP method is INVITE
Consequently, the S-CSCF now has to send the INVITE request to the AS.

Routing to an application server

When receiving the INVITE request, the AS:

➔ will remove the topmost entry in the Route header that is pointing to the AS.
➔ provide the service based on the information in the request.
➔ may modify the request in compliance with [RFC3261] (e.g., add another header).
➔ put its own address at the top of the Via list.
 ➔ decide whether it wants to receive subsequent requests within this dialog – if it wants to
then it puts its own address at the top of the Record-Route list (in this example we
assume that the AS wants to stay in the Route header).
➔ route the INVITE request based on the topmost Route header back to the S-CSCF.

Our INVITE request now looks like:

INVITE sip: theresa@[Link] SIP/2.0
Via: SIP/2.0/UDP sip: [Link]; branch=vas2tb
Via: SIP/2.0/UDP sip: [Link]; branch=9sc2as2tb
Via: SIP/2.0/UDP [Link]; branch=9pctb
Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb
Route: <sip: [Link]; lr>; dia-id=6574839201
Record-Route: <sip: [Link]; lr>
Record-Route: <sip: [Link]; lr>
Record-Route: sip:[Link];lr

When it receives the INVITE request again, the S-CSCF will then evaluate filter criterion #3;
this does not match, because the SIP method is not SUBSCRIBE (as indicated in the SPT).
Consequently, the S-CSCF will continue with its normal routing procedures, (i.e., it will send the
INVITE request to the I-CSCF of Theresa’s home network). Because service provisioning further
complicates the routing, no further attention is paid to it throughout this example; the Via, Route
and Record-Route headers added here will likewise not be shown in the rest of this example.

Creation of Filter Criteria: -

Whenever a user obtains an IMS subscription and their subscription contains some value-
added services or an operator is willing to utilize ASs as part of its IMS infrastructure, they need to
create service-specific data. These service-specific data are part of the user’s user profile. More
precisely, service-specific data are represented as initial filter criteria.
When constructing initial filter criteria an operator needs to consider these questions:
➔ What is a trigger point?
➔ What is the correct AS when the trigger point is met?
➔ What is the priority of an initial filter criterion?
➔ What should be done if the AS is not responding?
The trigger point is used to decide whether an AS is contacted. It contains one to multiple
instances of a Service Point Trigger.
The Service Point Trigger comprises the items shown in Figure:

Structure of service point trigger

Based on the above an operator could build, for example, initial filter criteria to handle
unregistered users, such as an IMS user who has not registered any of their public user identities.
The following initial filter criterion routes an incoming session to a voice mail server (sip:
vmail@[Link]) when the user is not registered. To make this happen the operator has to
set a SIP Method to match INVITE and a session case to match the value of Terminating Unregistered
(value 2). If the voice mail server cannot be contacted, then the default handling should be that the
session is terminated (value 1). Initial filter criteria are coded in XML.

Selection of AS
Initial filter criteria are downloaded to the S-CSCF on user registration or on a terminating
initial request for an unregistered user. After downloading the user profile from the HSS, the S-CSCF
assesses the filter criteria for the initial request alone, according to the following steps [3GPP TS
24.229]:
1. Check whether the public user identity is barred; if not, then proceed.
2. Check whether this request is an originating request or a terminating request.
3. Select the initial filter criteria for a session case (originating, terminating, or originating/
terminating for an unregistered end user).
4. Check whether this request matches the initial filter criterion that has the highest priority
for that user by comparing the service profile with the public user identity that was used to place
this request:
➔ if this request matches the initial filter criterion, then the S-CSCF will forward this
request to that AS, check to see whether it matches the next following filter criterion of
lower priority and apply the filter criteria on the SIP Method received from the
previously contacted AS.
➔ if this request does not match the highest priority initial filter criterion, then check to see
whether it matches the following filter criterion’s priorities until one does match.
➔ if no more (or none) of the initial filter criteria apply, then the S-CSCF will forward this
request based on the route decision.

There exists one clear difference in how the S-CSCF handles originating and terminating
initial filter criteria. When the S-CSCF realizes that an AS has changed the Request-URI in the case of
terminating initial filter criteria, it stops checking and routes the request based on the changed value
of the Request-URI. In an originating case the S-CSCF will continue to evaluate initial filter criteria
until all of them have been evaluated.
If the contacted AS does not respond, then the S-CSCF follows the default-handling
procedure associated with initial filter criteria: that is, either terminate the session or let the session
continue based on the information in the filter criteria. If the initial filter criteria do not contain
instructions to the S-CSCF regarding the failure to contact the AS, then the S-CSCF will let the call
continue as the default behavior [3GPP TS 24.229].
According to our initial filter criteria example, incoming INVITE requests will be routed to a
voice mail server, vmail@[Link], when Joe is not registered in the network. In
exceptional cases, when the voice mail server is not responding, the S-CSCF is instructed to release a
session attempt.

AS Behavior: -
After receiving the request, the AS initiates the actual service. To carry the service
out the AS may act in three different modes:
➔ Terminating User Agent (UA) – the AS acts as the UE. This mode could be used to
provide a voice mail service.
➔ Redirect server – the AS informs the originator about the user’s new location or about
alternative services that might be able to satisfy the session. This mode could be used
for redirecting the originator to a particular Web page.
 ➔ SIP proxy – the AS processes the request and then proxies the request back to the S-
CSCF. While processing, the AS may add, remove or modify the header contents
contained in the SIP request according to the proxy rules specified in [RFC3261].
➔ Third-party call control/back-to-back UA – the AS generates a new SIP request for a
different SIP dialog, which it sends to the S-CSCF.

Charging: - (Sec 3.11 page 75 MIIKKA)

(1) ONLINE CHARGING

(2) OFFLINE CHARGING

Charging Architecture:

OFFLINE CHARGING ONLINE CHARGING

IMS charging architecture

OFFLINE CHARGING:

➔ Diameter request will come from each I

entity to CDF (Charging data function). M
➔ According to the information it CGF CDF
S
generates CDR (Charging data record) and passes to E
CGF (Charging gateway function) via Ga Interface. N
➔ CGF may receive more than one CDR. CDR are then transferred TI
to billing system through Bx interface.
TY
 ACR Rf
CTF CDF
ACA

ACA: Accounting Request

ACA: Accounting Answer
Interface used: Rf

➔ Each IMS entity having its own CTF (Charging trigger function)
➔ CTF is capable to take decision when it needs to be triggered.
EX: Session Initiation, Session Modification, Session Termination, sending message,
Subscribe to an event.

➔ CTF will contact CDF when triggered condition will met.

➔ There is n number of CDF. Let suppose users are at different location then all CDR will
console at CGF.
➔ CGF will validate, Consolidate, preprocess the incoming CDR and will do correction
between different CDR and passes to the billing system.

ONLINE CHARGING: -
Direct debiting
Unit reservation.

Direct Debiting: -
➔ IMS contact OCS and ask permission to grant its resources/Services.
➔ OCS use internal rating function to find appropriate tariff and the price.
➔ OCS checks whether user has enough credit in the account. If so, OCS deducts suitable
amount of money from user account and grant its permission to use IMS network.
➔ It is used when IMS entity knows it could deliver the request/services to the user.

Unit Reservation: -
➔ OCS receives a credit control request from IMS entity.
➔ OCS use internal rating function to find the price of the services.
➔ OCS reserve the resources including (time and money) according to services.
➔ When request complete, IMS entity informs OCS the number of resources consumes and
OCS deducts the amounts.
➔ IT is used when IMS entity is usable to determine whether the services could be
delivered or when the required number of resources are not known prior to the use of
specific services.
Charging Reference Point: -

Rf Interface:

Ro Interface: -
Rx Reference Point: -

P-CSCF PCRF
Rx

➔ P-CSCF AND PCRF passes charging identifire to each other through Rx Interface.
➔ Some events (trffic plane events)
Ex: Bearer release, Bearer lost and Bearer recovered.
PCRF will receive them from [Link] and send to P-CSCF.
➔ P-CSCF will perform additional operations from IMS charging entitires through Rf and Ro
interfaces.

Gx Reference Point: -

PCRF Access Gateway

Gx

➔ Charging index will go to PCRF from access gateway through Gx interface.

➔ Activation of online and offline charging gateway (enable and disable).
➔ Enable the metering method to be applied in access gateway.
➔ Rating group information.(i.e 0.1 per minute)
➔ desired reporting level in access gateway (based on given service or based on
givenservice and rating-group.

DIAMETER PROTOCOL:
Here we have noted some of the major points in DIAMETER protocol that would help you to
walk through the whole protocol in just few minutes.

1) Diameter is a AAA (Authorization, Authentication and Accounting ) protocol works at

application layer in OSI model, over TCP/SCTP or TLS/DTLS(for security) protocol. Diameter is
successor of RADIUS (Remote Remote Authentication Dial In User Service) protocol that run
over UDP.

2) Diameter Default port is 3868 for TCP/SCTP and 5868 for TLS/DTLS.

3) Diameter is a message based protocol,where information is exchanged on the basis of

Request and Answer message. Each message contains Header and Data sections. Header
section contains following fields
a) Version - Diameter version, Remain set to 1.
b) Command Code - To uniquely identify a message in application
c) Command Flags - R(Request),P (Proxiable), E (Error Response),T(Re-Transmission of
Request)
d) Application Id - To uniquely identify and Application
e) Hop-by-Hop Id - To uniquely identify a message between two nodes and to map
response with request.
f) End-to-End Id - To detect duplicate message.
h) Length - Header length + Data length
Data field contains AVPs, AVPs are likely in field-value format.
Command Code and Application Ids are decided by a governing bodies such as IANA, 3gpp etc.