Lynne joined Award Solutions in 2011 with a diverse background in both RF engineering and network engineering. With almost 19 years in the telecom industry, her areas of specialty are IP networking and CDMA2000. As a Senior Consultant at Award, currently she teaches classes in the IP convergence curriculum that focus on the bridge between IP theory and practical application.
Lynne began her career at the Microwave Systems Group at Georgia Tech Research Institute (GTRI) where her work focused on the development of antenna measurement systems. She has experience in all types of antenna ranges including Anechoic Chambers, outdoor far-field, and indoor near-field ranges with various geometry configurations.
After leaving GTRI, she held numerous field engineering positions that provided her with a wealth of practical experience with various radio systems. In 1994, she joined Nortel as a Senior RF Engineer. She was on the first Nortel team to bring up live-air IS-95 CDMA in Vancouver, British Columbia. Based on these initial experiences with CDMA, she set up drive test data centers in CDMA PCS markets and taught market engineers how to optimize their networks based on analysis and interpretation of drive test data. Using this hands-on experience, Lynne joined a tools team in Nortel and developed the RFO (RF Optimizer) tool used universally by Nortel for network acceptance metrics.
After her stint as a tool developer, Lynne returned to school at University of Texas at Dallas with a focus on IP Networks and Telecommunication Systems. She put this education to use when she moved from RF engineering to the Advanced Technology Lab at Nortel. This lab served as a showcase for prototype networking software and hardware solutions for marketing and engineering teams. This lab work provided IP network experience, which allowed Lynne to move to Nortel product test where she was responsible to creating and maintaining the IP network used to test the Nortel PDSN (Packet Data Serving Node). As a Subject Matter Expert on the PDSN, Lynne taught classes in the Nortel Training Center to internal engineers. Based on this experience, she moved to the training department to become a full-time instructor.
In 2007, Lynne moved to Anritsu as a Business Development Manager for the American Sales Region. There she was responsible for spectrum analyzers, signal generators, and signal analyzers. While still at Anritsu, Lynne transferred into the development group as a project manager for 3G IOT test development using the Anritsu UMTS network simulator. In this role she oversaw a local team of 9 software developers and an off-shore team of 6 software developers.
Lynne is an experienced public speaker and speaks at Meet Up Groups and Toastmasters on a wide range of topics. Among her students, she has the reputation for breaking complex ideas into simple concepts that anyone can grasp. Her goal is always to be clear and easily understood, no matter what the topic.
Lynne attended Georgia Tech where she was awarded the BEE with high honors following 10 years on active duty in the United States Air Force. In her undergraduate electrical engineering program, she concentrated on electromagnetic theory and controls. Her graduate work at Georgia Tech focused on antennas and optics.
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:
In our next installment, we will examine the role of the I-CSCF, the second SIP server encountered in the IMS network.