IMS Protocol Reference Guide
IMS Protocol Reference Guide
IMS Protocol Reference Guide
com
Reference Guide
The LTE User Equipment Perspective
IMS Procedures and Protocols
www.spirent.com | 1 SPIRENT REFERENCE GUIDE
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
TABLE OF CONTENTS
1. EXECUTIVE SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. IMS PROCEDURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. PDN Connectivity (NAS Signaling) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Bearer Setup and EPS Attach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. P-CSCF Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. SIP Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6. Event Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. VoLTE Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IMS PROTOCOLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. SIP requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Session Description Protocol (SDP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. SIP Responses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.5. SigComp (Signaling Compression) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6. The Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) . . . . . . . . . . . . 13
5. IMS CLIENT-RELATED SECURITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Security association between the User Agent and a P-CSCF . . . . . . . . . . . . . . . . . . 14
5.2. Security association between the ISIM and the HSS. . . . . . . . . . . . . . . . . . . . . . . 14
6. SAMPLE SIP CALL FLOWS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Event Subscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.3. VoLTE Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.4. SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. APPENDIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. SIP Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.2. SIP Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. ACRONYMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
2 | www.spirent.com
SPIRENT REFERENCE GUIDE
1. EXECUTIVE SUMMARY
This reference guide presents an overview of the procedures and
protocols used in IMS-based LTE systems, from the perspective of
the UE. To illustrate the concepts being discussed, several sample
protocol exchanges, captured from a live network, are broken down
and described in more detail.
2. INTRODUCTION
IMS represents a substantial challenge to those charged with
developing LTE UEs. For one thing, the flexibility allowed in offer/
answer SIP messaging represents a double-edged sword. While the
advantages of flexibility are obvious, one resulting challenge is a
large number of equally valid protocol flows. Unless both the intuitive
intent and details of the protocols are understood, developers can be
tempted to design for specific known cases rather than for all valid
cases.
Todays UE developers must deal with increased complexity on a variety of fronts. The deployment of LTE
introduces a multitude of inter-RAT (Radio Access Technology) mobility scenarios, new antenna techniques such
as MIMO and Quality of Service (QoS) challenges with next-generation services such as Voice over LTE (VoLTE).
With IMS and its associated Session Initiation Protocol (SIP) being essential in deploying LTE services, UE
developers and wireless operators continue to focus on IMS functional and SIP signaling conformance testing.
Most discussions of IMS protocols are general overviews containing a small minority of content of interest to
the UE developer. This paper is an attempt to provide an intuitive introduction to IMS procedures and protocols,
focusing on those concepts most relevant to the UE designer in deploying LTE services such as VoLTE.
CORRESPONDING LITERATURE
WHITE PAPER
IMS Architecture:
The LTE User Equipment Perspective
WHITE PAPER
VoLTE Deployment and The Radio
Access Network:
The LTE User Equipment Perspective
POSTERS
IMS/VoLTE Reference Guide
LTE and the Mobile Internet
www.spirent.com | 3 SPIRENT REFERENCE GUIDE
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
3. IMS PROCEDURES
Any discussion of IMS protocols must start with a dialogue
describing the procedures being implemented. It is important
to note that there is no one size fits all procedural flow;
IMS in LTE offers a lot of flexibility to both network equipment
manufacturers and network operators. Note that the processes
described here are strictly from the UEs point of view, without
discussion of the many intra-network procedures required to
make the system work.
The processes involved in a Voice over LTE (VoLTE) call can
provide a meaningful background and a fairly typical scenario.
From the UEs point of view the initial step is to listen for
system information in the form of Master Information Blocks
(MIBs) and System Information Blocks (SIBs). Once that
information has been processed the UE can initiate its own
processes. These processes are outlined in the next section.
The graphical depiction in Figure 1 is not meant to distinguish
between multiple protocol layers; it is merely an intuitive
impression of the required processes.
PDN
Connectivity
Request contains
Protocol
Conguration
Options IE with
request for
P-CSCF address
IMS PDN and
P-CSCF IP
addresses are
provided
UE has
completed
initial IMS
registration
UE has
completed
subscription to
the registration
event package
VoLTE Call is
Established
RRC Connection Request UE
EPC &
IMS
RTP Voice Trafc
EPS Attach & P-CSCF Discovery
RRC Connection Setup
RRC Connection Setup Complete
(Attach Request PDN Connectivity)
Downlink Transfer
(Authentication Request)
Uplink Transfer
(Authentication Response)
Downlink Transfer
(Security Mode Command)
Uplink Transfer
(Security Mode Complete)
Downlink Transfer
(ESM Information request)
Uplink Transfer
(ESM Information Response)
RRC Connection Reconguration
(Attach Accept Activate EPS Bearer Context)
Uplink Transfer
(Attach Complete Activate EPS Bearer Accept)
RRC Connection Reconguration Complete
REGISTER
401 UNAUTHORIZED
200 OK
200 OK
200 OK
180 Ringing
200 OK
ACK
REGISTER
SUBSCRIBE
NOTIFY
Invite SDP
PRACK
200 OK (SDP Answer)
100 Trying
Figure 1 - Multi-layer procedural flow required for a VoLTE call
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
4 | www.spirent.com
SPIRENT REFERENCE GUIDE
3.1. PDN Connectivity (NAS Signaling)
As in legacy 3GPP technologies, the UE starts connection by issuing a Radio Resource Control (RRC) Connection
Request. Note that while either the UE or the network can trigger the connection request, it is always initiated
by the UE. This request includes both the UE identity information and the call establishment cause (i.e.
Mobile Originating Signaling or Emergency). Assuming there are no issues, the network responds with an RRC
Connection Setup message.
The procedure thus far has established a signaling bearer and a Dedicated Control Channel (DCCH). Once in
RRC Connected mode, the UE responds by sending an RRC Connection Setup Complete message which includes
the Attach request for PDN connectivity. While this part of the connection is familiar to those versed in 3G
technologies, it is worth noting that at this point, unlike in a legacy UMTS system, the initial NAS message has
already been delivered to the Mobility Management Entity (MME). In the case of a VoLTE call this message would
be an Attach Request.
3.2. Authentication
Now that NAS signaling is established, the network initiates an Authentication Request or challenge. Once the
UEs Authentication Response is deemed valid, the network sends a NAS Security Mode Command. Note that
while neither the Authentication Request nor the Authentication Response is integrity-protected, the Security
Mode Command is protected. The UE then sends a Security Mode Complete message, establishing protected NAS
signaling.
In order to protect EPS Session Management (ESM) information, the network now sends an ESM Information
Request; the UE reacts with an ESM Information response describing the now-protected protocol configuration
options.
RRC Connection Request
RRC Connection Setup
RRC Connection Setup Complete
(Attach Request PDN Connectivity)
UE
EPC &
IMS
Downlink Transfer
(Authentication Request)
Uplink Transfer
(Authentication Response)
Downlink Transfer
(Security Mode Command)
Uplink Transfer
(Security Mode Complete)
Downlink Transfer
(ESM Information request)
Uplink Transfer
(ESM Information Response)
UE
EPC &
IMS
www.spirent.com | 5 SPIRENT REFERENCE GUIDE
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
3.3. Bearer Setup and EPS Attach
At this point, additional radio bearers must be set up. The network sends an RRC Connection Reconfiguration
to activate the EPS bearer. The UE confirms successful completion with an RRC Connection Reconfiguration
Complete message and then finalizes the Attach procedure and accepts the activation of the EPS bearer.
It should be noted that the way a default PDN is associated to an IMS device varies per the network operator. In
some networks, powering on a device will cause it to attempt to establish a connection with an Internet PDN. In
this case the device will only establish IMS connectivity when an IMS application needs to be serviced. A device
used on another network will, on powering up, attempt to establish a connection with an IMS PDN, and display a
No Service message if the connection is not made.
3.4. P-CSCF Discovery
Before sending any Session Initiation Protocol (SIP) requests, the UE must perform P-CSCF Discovery, the
process of identifying (by address) the correct Proxy-Call Session Control Function (P-CSCF). The P-CSCF address
may be discovered in one of three different ways:
1. It may be stored in the IP Multimedia Services Identity Module (ISIM).
2. The UE may request it as part of the PDN connectivity request during the Attach process.
3. The UE may request an IP address and Fully Qualified Domain Name (FQDN) from a DHCP server and then
perform a DNS query on the returned IP address and FQDN.
The next part of the procedural flow includes IMS Registration, Event Subscription and Call Connection and
utilizes key IMS protocols. For a detailed explanation of these protocols, please refer to the IMS Protocols and
Sample Call Flows sections in this document.
RRC Connection Reconguration
(Attach Accept Activate EPS Bearer Context)
Uplink Transfer
(Attach Complete Activate EPS Bearer Accept)
RRC Connection Reconguration Complete
UE
EPC &
IMS
UE
EPC &
IMS
EPS Attach & P-CSCF Discovery
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
6 | www.spirent.com
SPIRENT REFERENCE GUIDE
3.5. SIP Registration
After Authentication, Security and UE Capability requests, the network accepts the Attach request and activates
the EPS bearer context. Once that has happened and the UE has also established a PDP context, a typical IMS SIP
client registration (Figure 4) begins:
1. The IMS client attempts to register by sending a REGISTER request to the P-CSCF.
2. The P-CSCF forwards the REGISTER request to the I-CSCF.
3. The I-CSCF polls the HSS for data used to decide which S-CSCF should manage the REGISTER request. The
I-CSCF then makes that decision.
4. The I-CSCF forwards the REGISTER request to the appropriate S-CSCF.
5. The S-CSCF typically sends the P-CSCF a 401 (UNAUTHORIZED) response as well as a challenge string in the
form of a number used once or nonce.
6. The P-CSCF forwards the 401 UNAUTHORIZED response to the UE.
7. Both the UE and the network have stored some Shared Secret Data (SSD), the UE in its ISIM or USIM and the
network on the HSS. The UE uses an algorithm per
RFC 3310
1
(e.g. AKAv2-MD5) to hash the SSD and the nonce.
8. The UE sends a REGISTER request to the P-CSCF. This time the request includes the result of the hashed
nonce and SSD.
9. The P-CSCF forwards the new REGISTER request to the I-CSCF.
10. The I-CSCF forwards the new REGISTER request to the S-CSCF.
11. The S-CSCF polls the HSS (via the I-CSCF) for the SSD, hashes it against the nonce and determines whether
the UE should be allowed to register. Assuming the hashed values match, the S-CSCF sends 200 OK
response to the P-CSCF. At this point an IPSec security association is established by the P-CSCF.
12. The P-CSCF forwards the 200 OK response to the UE.
401 UNAUTHORIZED
200 OK
REGISTER
REGISTER
UE
EPC &
IMS
1 Internet Engineering Task Force (IETF) RFC 3310: Hypertext Transfer Protocol (HTTP) Digest Authentication. Using Authentication and Key
Agreement (AKA)
www.spirent.com | 7 SPIRENT REFERENCE GUIDE
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
Figure 2 - SIP Client Registration
Each element described therefore has a unique set of roles in this arrangement:
The UE initiates the registration sequence, attaches to the LTE network and activates the PDP context. It
discovers which P-CSCF to use, then makes a deliberately unauthenticated registration attempt. It waits for the
expected 401 response, extracts the nonce from the response and hashes it with the SSD before including the
result in a second REGISTER request.
The P-CSCF, typically resident in the visited network, acts as the UEs gateway into the UEs home network. It
identifies the home IMS network, routes traffic to and from the home IMS network and establishes the IPSec
security association.
The I-CSCF, typically resident in the home network, acts as the front-end of the home IMS. It interfaces with the
P-CSCF in the visited network and selects the S-CSCF (by querying the HSS).
The S-CSCF, typically resident in the home network, handles the registration request from the I-CSCF, pulls
authentication vectors from the HSS and passes them to the P-CSCF (via the I-CSCF), and authenticates the
user in the second registration attempt.
Select S-CSCF
(based on data from HSS)
Hash
(SSD with nonce)
REGISTER
(with hashed
SSD & nonce)
REGISTER
(with hashed
SSD & nonce)
REGISTER
REGISTER
401 -
UNAUTHORIZED
(with nonce)
401 -
UNAUTHORIZED
(with nonce)
REGISTER
(with hashed
SSD & nonce)
6
1
8
3
2
9
5
7
10
11
12
REGISTER 4
S-CSCF
I-CSCF
P-CSCF
200 - OK
200 - OK
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
8 | www.spirent.com
SPIRENT REFERENCE GUIDE
3.6. Event Subscription
Suppose the UE now intends to monitor a specific registration event. In this context an event may be a callback
(to provide audio for a shared web event, for example) or an update to a buddy list or a message waiting
indicator. In general, this means that the UE is asking to be notified any time there is a change in registration
status and it requires cooperation between two end nodes. It is an essential part of IMS since it enables the
concept of subscriber presence.
The UE will begin the transaction using the SUBSCRIBE method. This method, defined in RFC 3265, is one of the
many SIP extensions used in IMS. This is basically a request to be notified (for a specified period of time) of a
change in resource state. As is shown in the call flow section later in this document, the eventual response is a
NOTIFY method indicating that there has been a change in status.
3.7. VoLTE Call
The initial stages of setting up a VoLTE call are the processes of the initial attach, P-CSCF discovery and creating
the default bearer for SIP signaling (by registering with the IMS network and subscribing to a registration event
package).
The first step in a VoLTE call setup is a SIP INVITE request initiated by the calling UE. Following this step,
agreement is made on the media-specific parameters such as codecs (e.g. AMR or WB-AMR). After some
RINGING, TRYING and OK messaging, the calling UE may respond with a Provisional ACK (PRACK) method as
shown in the flow diagram above and as defined in RFC 3551. The PRACK method is used because ACK cannot
safely traverse proxy servers that comply with RFC 3261. The PRACK is also forwarded to the called UE. When the
called subscriber answers the call, the called UE will respond with a 200 OK before the RTP (media) messaging
begins.
200 OK
200 OK
SUBSCRIBE
NOTIFY
UE
EPC &
IMS
180 Ringing
100 Trying
200 OK
ACK
Invite SDP
PRACK
200 OK (SDP Answer)
UE
EPC &
IMS
www.spirent.com | 9 SPIRENT REFERENCE GUIDE
SPIRENT IMS Procedures and Protocols | The LTE User Equipment Perspective
In a VoLTE call, the bearer is associated with a QoS Class Identifier (QCI) of 1. QCI values from the 3GPPs TS
23.203
2
are shown in Table 1. Each is generally targeted to a specific service type based on delay and packet
loss requirements. For example, a video telephony call might add a second dedicated bearer for video traffic,
assigning a QCI of 6 to that bearer.
QCI
Resource
Type Priority
Packet Delay
Budget (ms)
Packet Error
Loss Rate Example Services
1 GBR 2 100 10
-2
Conversational Voice
2 GBR 4 150 10
-3
Conversational Video (live streaming)
3 GBR 5 300 10
-6
Non-conversational video (buffered streaming)
4 GBR 3 50 10
-3
Real-time gaming
5 Non-GBR 1 100 10
-6
IMS Signaling
6 Non-GBR 7 100 10
-3
Voice, Video (live streaming), interactive gaming
7 Non-GBR 6 300 10
-6
Video (buffered streaming)
8 Non-GBR 8 300 10
-6
TCP-based (WWW, email, FTP); privileged subscriber
9 Non-GBR 9 300 10
-6
TCP-based (WWW, email, FTP); non-privileged subscriber
Table 1 - QCI Values for Bearers
4. IMS PROTOCOLS
From the UEs point of view of the IMS subsystem, the critical protocols are the Session Initiation Protocol (SIP),
SigComp, Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP) and IP Security (IPSec). While there are
other key IMS protocols (e.g. Diameter) often mentioned in the same breath as those listed here, these are the
ones impacted by the UE or having direct impact on UE operation.
4.1. SIP
SIP is a protocol used to create, modify and terminate multimedia sessions, essentially negotiating a media
session between two users. As a text-based client/server protocol, SIP is completely independent of underlying
protocols, (e.g. TCP/IP vs. UDP or IPv4 vs. IPv6). SIP is not a transport protocol and does not actually deliver
media, leaving that task to RTP/RTCP.
While SIP itself is defined in the IETFs RFC 3261
3
, SIP as used for IMS includes multiple extensions. This is not
without precedent in telephony; one popular implementation of Push-to-talk over Cellular (PoC) used a heavily-
extended version of SIP as well. As a matter of fact, some better-known cellular SIP methods (e.g. MESSAGE,
SUBSCRIBE) are actually defined in extensions beyond RFC 3261, and their usage in cellular IMS is defined in the
3GPPs TS 23.228
4
.
One popular misconception is that SIP is specific to IMS. In fact, it is used in media services deployed via Internet
PDN as well. Skype and FaceTime