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 P-CSCF, 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, let’s 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 I-CSCF 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 carrier’s 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. Let’s 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 subscriber’s profile. The profile contains the user’s 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 UE’s 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 UE’s home network. The P-CSCF forwards the Registration request to the I-CSCF, and ultimately it reaches the S-CSCF. 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 subscriber’s 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 user’s 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 subscriber’s 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 P-CSCF, 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 user’s 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 user’s 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 UE’s 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.


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.