http://lteuniversity.

com/get_trained/expert_opinion1/b/lpatterson/archive/2013/06/1
2/cscf-in-volte-the-p-cscf-part-1-of-4.aspx
uname: naveen_s_cs
passwd: makeApp@12

CSCF in VoLTE The P-CSCF (Part 1 of 4)

As VoLTE rolls into telecom networks across the world, understanding the IP Multimedia
Subsystem (IMS) is critical for many telecom engineers. 3GPP Release 5 in 2002
introduced IMS, which for years has been a solution looking for a killer application. With
the introduction of Voice over LTE (VoLTE), IMS has the opportunity to prove its
potential as the mechanism that supports IP convergence in the telecom space.
The IMS network divides into three distinct layers: the Transport layer, the Session and
Control Layer, and the Applications and Services layer. In this four part series, we focus
on the SIP (Session Initiation Protocol) servers that operate in the Session and Control
Layer. These SIP servers implement the IMS call session control function (CSCF). The
CSCF divides into three distinct roles: the Proxy CSCF (P-CSCF), the Interrogating
CSCF (I-CSCF), and the Serving CSCF (S-CSCF). These servers use the SIP protocol
to communicate with each other and Application Servers. They use the DIAMETER
protocol to communicate with the Home Subscriber Server (HSS) and/or the Policy and
Charging Rules Function (PCRF). In this series, Part 1 examines the role of the PCSCF, part 2 examines the role of the I-CSCF, part 3 examines the role of the S-CSCF,
and in part 4, we look at their interaction with each other and the other nodes in the
network as they facilitate a VoLTE call.

As an introduction to the roles of the CSCF servers, lets start with an overview of how
they interact with each other. The P-CSCF is the first IMS node encountered when a UE
(User Equipment) is trying to establish a VoLTE call. The P-CSCF must locate an ICSCF for the user and the I-CSCF must locate an S-CSCF for the user. This division of
labor ensures that the IMS system will scale as demand increases and sets the stage
for IMS roaming. The P-CSCF, as the initial point-of-contact, may be in the home or
visited network. After just a few messages, the I-CSCF, having located the S-CSCF,
bows out of the transaction. The S-CSCF does the heavy lifting for a VoLTE call by
determining the resources needed to handle a call successfully. If the call terminates at

another VoLTE UE in the same network, the S-CSCF locates a P-GW to reach the
targeted UE. If the call terminates at a VoLTE UE in another carriers network or at a
landline in the PSTN, the S-CSCF locates the appropriate gateways to reach the
requested destinations.
In order to set up a VoLTE call, the UE must have a default bearer in place. Lets quickly
review the steps required for the UE to reach this state. Attachment to the network is the
first order of business and, at power on, the UE sends an ATTACH REQUEST to the
Mobility Management Entity (MME). The MME queries the Home Subscriber Server
(HSS) to retrieve the subscribers profile. The profile contains the users default Access
Point Name (APN), which for VoLTE calls is IMS. The MME determines the appropriate
Serving Gateway (S-GW) and Packet Data Network Gateway (P-GW) for the call. The
eNodeB, the S-GW and the P-GW establish a default bearer and the P-GW supplies the
UE with an IP address. In addition to the UEs IP address, the P-GW also provides the
P-CSCF IP address. When the attach procedure is complete, the default bearer is
established, the UE has an IP address for itself and the IP address of the P-CSCF.
(Note: It is true that there are other ways of getting the IP of the P-CSCF as designated
in 3GPP TS 24.229 version 11.5.0 Annex L Section L.2.2.1 EPS bearer context
activation and P-CSCF discovery. Receiving the P-CSCF IP address from the P-GW
will be the method of choice during initial rollout of VoLTE.)
Once attached to the LTE network, the UE initiates the VoLTE call by requesting SIP
registration. The UE forwards the SIP Registration message to the P-CSCF. The
message contains the home domain of the UE and using this information; the P-CSCF
consults a DNS server and identifies an I-CSCF in the UEs home network. The PCSCF forwards the Registration request to the I-CSCF, and ultimately it reaches the SCSCF. Part 4 addresses this message flow.
Every SIP message associated with a call passes through the P-CSCF. Besides acting
as the gateway to the IMS network for the UE, the P-CSCF has several other roles that
include:
1)

Establishing the IPSec Security Association (AS) with the UE

2)

Compressing and decompressing the SIP messages on the air interface

3)

Providing information for billing and policy control

4)

Identifying emergency calls

Establishing the IPSec Security Association (SA) with the UE

The IMS standard requires an IPSec Security Association (SA) between the UE and the
P-CSCF. The P-CSCF establishes the SA during the SIP registration procedure. The
registration procedure is a two-step process. The UE sends the Register message

twice. The first Register message allows the I-CSCF and the S-CSCF to authenticate
the user by accessing the subscribers profile in the HSS. Then the S-CSCF returns a
401 Unauthorized message that includes a security challenge. The UE uses the
challenge information to produce a second REGISTER message that contains the
users credentials based on the security challenge. Information in the Unauthorized
message provides the data to set up the IPSec SA between the UE and the P-CSCF.
The SAs between the UE and the P-CSCF protect the subscribers privacy and prevent
spoofing.
Compressing and Decompressing the SIP Messages on the Air Interface
SIP messages are easily readable because they use the ASCII character set. These
text messages may be easy to read and debug, but they are also large. The interface
between the UE and the P-CSCF includes the air interface, which is a bandwidth-limited
resource. Compression improves performance on the air interface by reducing the size
of the messages. RFC 3320 defines and RFC 4896 updates SigComp, the
compression protocol used. The Gm interface, the interface between the UE and the PCSCF, is the only IMS interface that implements signal compression.
Providing Information for Billing and Policy Control
The P-CSCF gets involved in billing and policy control for the VoLTE call. Consider that
the IMS network has no view of the users data flow and that the P-GW has no view of
the signaling performed by the IMS nodes on behalf of the user. The IMS system and
the LTE nodes produce Charging Data Records (CDRs), and deliver them to the billing
system. With records coming from multiple sources, some reporting signaling and
others reporting data usage, the control CDRs and the data CDRs need a method for
reconciliation. This reconciliation is satisfied with the introduction of two identifiers: the
GPRS Charging Identifier (GCID) created by the P-GW and the IMS Charging Identifier
(ICID) created by the P-CSCF. The P-CSCF passes the ICID to the PCRF, which in turn
passes it to the P-GW. The P-GW passes the GCID to the PCRF, which passes it to the
P-CSCF, which passes it to the remaining IMS nodes involved in billing. With both
identifiers in hand, nodes that produce billing records place both IDs in the CDRs for the
call.
The P-CSCF also delivers information to the PCRF that allows the PCRF to create the
appropriate policy rules for the call. The P-CSCF extracts information from the SIP
messages and sends it to the PCRF on the Rx interface using the DIAMETER protocol.
This information allows the PCRF to determine the appropriate data rate, bearer type,
QoS (Quality of Service) requirement, and gating control (packets allowed or
disallowed) for the call. When the P-GW is setting up the voice data path for the call, it
queries the PCRF for the users policy rules and sets the call rules appropriately.
Identifying emergency calls

As IMS developed, emergency services have evolved. The P-CSCF, as the initial point
of contact with the IMS network, must identify emergency calls and route them correctly.
Normally, the goal of the P-CSCF is to get the call connected with an S-CSCF in the
UEs home network. In an emergency, when the UE is not in the home network, this
would not be the appropriate action. Instead, when the P-CSCF identifies an emergency
call, it sends it to an Emergency CSCF (E-CSCF). 3GPP introduced the E-CSCF and
enhancements to emergency calls appeared in Releases 8-10. Currently, the plan is to
allow the P-CSCF to identify emergency calls and forward them along with location data
to the E-CSCF. The E-CSCF, using location data from multiple sources, routes the call
to the local Public Safety Access Point (PSAP), more commonly known as a 911 Center.
Location services are critical for successful handling of E911 calls and the IMS standard
specifies location services for this purpose.
Summary
The P-CSCF is the first IMS SIP server encountered in a VoLTE call. Besides
forwarding SIP messages to the other IMS nodes and to the UE, it serves in several
other roles. In summary, the functions of the P-CSCF are to:

Interact with the PCRF for billing and policy rules purposes.

Maintain a Security Association with the UE.

Compress and decompress SIP messages that use the air interface.

Identify and forward emergency calls to the local E-CSCF

In our next installment, we will examine the role of the I-CSCF, the second SIP server
encountered in the IMS network.
CSCF in VoLTE The I-CSCF (Part 2 of 4)

In Part 1 of this series, we looked at the P-CSCF and the roles it plays in the IMS
network. Now we turn our attention to the next SIP server in the signaling path, the
Interrogating Call Session Control Function (I-CSCF).
The I-CSCFs main function is to locate an S-CSCF for the VoLTE call. While the PCSCF might be in the home or visited network, the I-CSCF is in the home network of
the VoLTE user. The I-CSCF must find an S-CSCF in two instances. 1) A P-CSCF
forwards a SIP Registration message to the I-CSCF based on the home domain of the
user. 2) An S-CSCF forwards a SIP Invite message to the I-CSCF based on the domain
of the called party. In both cases, the CSCF node extracts the home domain of the

originating or terminating endpoint and consults a DNS server to determine the IP

address of the I-CSCF.
When the I-CSCF receives the SIP Registration message from the P-CSCF or when it
receives the SIP Invite message from an S-CSCF, the I-CSCF consults the HSS using
DIAMETER to locate an S-CSCF for the call. The HSS returns a list of available SCSCFs with their capabilities. The I-CSCF matches the requirements of the call to the
capabilities and chooses the appropriate S-CSCF.
Recall that when a user initiates a VoLTE call, all SIP messages pass through the PCSCF. In the originating network, the I-CSCF receives the SIP Registration message
from the P-CSCF and forwards it to the appropriate S-CSCF. With the selection of the
S-CSCF, the I-CSCF steps out of the signaling path and takes no additional actions on
behalf of the UE.
When the I-CSCF is in the terminating network, it is actively involved in session
establishment following the SIP Invite message. With respect to the terminating
network, the I-CSCF acts as the IMS gateway for messages coming from the originating
S-CSCF. The Invite request and the progress messages route through the terminating
networks I-CSCF.
When there is more than one I-CSCF in a network, each session may use different ICSCF. Remember, nodes that need to contact the I-CSCF learn the IP address of the ICSCF based on the domain name. Each DNS query may return the address of a
different I-CSCF when there are several to choose from. As different I-CSCFs may
handle subsequent calls, the I-CSCF does not maintain state information mapping the
UE to a particular S-CSCF. In cases where the UE already has an established session
with a particular S-CSCF, the HSS returns IP address of the currently serving S-CSCF
instead of a list of available S-CSCFs when the I-CSCF queries for an S-CSCF.
Because of its role as the S-CSCF selector, as the number of S-CSCFs grows, the ICSCF can function as a load balancer with respect to the S-CSCFs
If you study the I-CSCF more closely, you may find information describing the I-CSCF
as a Topology Hiding Internetworking Gateway (THIG). Beginning in 3GPP Release 7,
this function moved from the I-CSCF to the Interconnection Border Control Function
(IBCF). The IBCF is a gateway to external networks and provides functions not
associated with the I-CSCF such as NAT (Network Address Translation) and firewall
functionality.

In summary, we can say that the I-CSCF ensures that the correct S-CSCF is chosen
and none of the S-CSCFs are overloaded. This selection and load-balancing process
ensures that the IMS network scales as demand grows.
In our next installment, we will examine the role of the S-CSCF, the third SIP server
encountered in the IMS network.