Chit Sheet Ims

M ASARYKOVA UNIVERZITA
FAKULTA INFORMATIKY
} w
A|
y
<
5
4
23
1
0
/
-.
,
)+
(
%&'
$
#
!"

Æ

Emergency Calls Handling in

IP Multimedia Subsystem
Network
M ASTER T HESIS
Martin Tomeš
Brno, 2014
Declaration
Hereby I declare, that this paper is my original authorial work,
which I have worked out by my own. All sources, references and lit-
erature used or excerpted during elaboration of this work are prop-
erly cited and listed in complete reference to the due source.
Martin Tomeš
Advisor: doc. RNDr. Eva Hladká, Ph.D.
ii
Acknowledgement
I would like to thank to my supervisor doc. RNDr. Eva Hladká,
Ph.D., for help and encouragement throughout the work. I would
also like to thank my wife Alena for proofreading and linguistic sup-
port during the work on my thesis.
iii
Abstract
IP Multimedia Subsystem has been developed by the 3GPP or-
ganization for the purpose of convergence of voice and multimedia
services (chat, Internet, video, etc.) and it is now used by mobile op-
erators worldwide. The development of particular IMS components
is quite specific and depends rather on good communication and un-
derstanding between IMS architects and developers. This work is an
attempt to contribute to the improvement of this communication by
presenting a high-level developer manual, so called “white paper”,
on IMS emergency calls. This “white paper” is written from the per-
spective of an IMS architect who knows the 3GPP standard in detail.
The manual is primarily intended for developers, who do not need
to have such knowledge about 3GPP, but they can appreciate a suffi-
ciently informative high-level document. The goal of this thesis is to
contribute to better understanding and communication during var-
ious stages of software development life-cycle of those IMS compo-
nents which are related to emergency session.
iv
Keywords
IP, SIP, IMS, HSS, CSCF, 3GPP, Emergency, GSM, UMTS, GPRS,
LTE, VoLTE
v
Abbreviations:
3G Third Generation
3GPP Third Generation Partnership Project
AAA Authentication Authorization Accounting
ACK Acknowledgement
AuC Authentication Centre
AVP Attribute Value Pairs
BGCF Breakout Gateway Control Function
CDMA Code Division Multiple Access
CDR Call Data Record
CSCF Call Session Control Function
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Server
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Services
HSS Home Subscriber Server
HTTP Hyper Text Transfer Protocol
I-CSCF Interrogating CSCF
ID Identifier
IETF Internet Engineering Task Force
IMEI International Mobile Equipment Identity
IMS IP Multimedia Subsystem
IP Internet Protocol
IPsec IP Security Protocol
LRR Location Retrieval Function
LTE Long-Term Evolution
MGCF Media Gateway Controller Function
MGW Media Gateway
MRFC Media Resource Function Controler
MRFP Media Resource Function Processor
MSISDN Mobile Subscriber Integrated Services Digital Network Number
NGN Next Generation Network
OSA-SCS Open Service Access Service Capability Server
P-CSCF Proxy CSCF
PDF Policy Decision Function
PLMN Public Land Mobile Network
vi
PoC Push-to-talk over Cellular
PSI Public Service Identifier
PSTN Public Switching Telephone Network
QoS Quality of Service
RSVP ReSerVation Protocol
RTP Real-time Transport Protocol
RTR Response Time Reporter
S-CSCF Serving CSCF
SCTP Stream Control Transmission Protocol
SIM Subscriber Identity Module
SIP Session Initiation Protocol
SIP-AS Session Initiation Protocol Application Server
SLF Subscriber Location Function
SQN Sequence Number
SRVLOC Service Location Protocol
TCP Transmission Control Protocol
TDMA Time Division Multiple Access
THIG Topology Hiding Inter-network Gateway
TLS Transport Layer Security
TMSI Temporary Mobile Subscriber Identity
UDP User Datagram Protocol
UE User Equipment/Endpoint
UMTS Universal Mobile Telecommunication System
UPSF User Profile Server Function
URI Uniform Resource Identifier
VoIP Voice over IP
vii
Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 IMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 IMS Components . . . . . . . . . . . . . . . . . . . . . . 6
2.3 IMS Layers . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Device Layer . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Transport Layer . . . . . . . . . . . . . . . . . . 9
2.3.3 Control Layer . . . . . . . . . . . . . . . . . . . . 9
2.3.4 Service Layer . . . . . . . . . . . . . . . . . . . . 10
2.4 IMS Core Components . . . . . . . . . . . . . . . . . . . 10
2.4.1 Proxy Call Session Control Function (P-CSCF) . 10
2.4.2 Serving Call Session Control Function (S-CSCF) 11
2.4.3 Interrogating Call Session Control Function (I-
CSCF) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.4 Emergency Call Session Control Function (E-
CSCF) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.5 Home Subscriber Server (HSS) . . . . . . . . . . 13
2.5 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.1 SIP Architecture . . . . . . . . . . . . . . . . . . 15
2.5.1.1 User Agents . . . . . . . . . . . . . . . 15
2.5.1.2 Servers . . . . . . . . . . . . . . . . . . 15
2.5.2 SIP Messagging . . . . . . . . . . . . . . . . . . 16
2.5.2.1 Message Header . . . . . . . . . . . . . 16
2.5.2.2 SIP Requests . . . . . . . . . . . . . . . 17
2.5.2.3 SIP Responses . . . . . . . . . . . . . . 18
2.5.3 SDP Protocol . . . . . . . . . . . . . . . . . . . . 21
3 Supported Mobile Technologies in IMS . . . . . . . . . . . 23
3.1 GSM (2G) . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 GPRS (2,5G) . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 UMTS (3G) . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 IMS Emergency Sessions . . . . . . . . . . . . . . . . . . . . 30
4.1 State of the Arts . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 History of Changes in 3GPP Standard . . . . . . . . . . 31
4.3 Emergency calls - General Introduction . . . . . . . . . 33
1
4.4 IMS Emergency Architecture . . . . . . . . . . . . . . . 35
4.4.1 User Equipment . . . . . . . . . . . . . . . . . . 36
4.4.2 Proxy-CSCF . . . . . . . . . . . . . . . . . . . . . 36
4.4.3 Emergency CSCF . . . . . . . . . . . . . . . . . . 37
4.4.4 Location Retrieval Function . . . . . . . . . . . 38
4.4.5 Serving-CSCF . . . . . . . . . . . . . . . . . . . . 38
4.4.6 Emergency Access Transfer Function (EATF) . . 40
4.4.7 Interrogation-CSCF . . . . . . . . . . . . . . . . 40
4.4.8 Application Server . . . . . . . . . . . . . . . . . 40
4.4.9 HSS . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.5 Establishing of IMS Emergency Session . . . . . . . . . 41
4.5.1 IMS Emergency Registration . . . . . . . . . . . 41
4.5.2 Emergency Service Request . . . . . . . . . . . . 42
4.5.2.1 Non UE detectable emergency service
request . . . . . . . . . . . . . . . . . . . 42
4.5.2.2 Emergency service request without reg-
istration . . . . . . . . . . . . . . . . . . 44
4.5.2.3 Emergency service request with nor-
mal registration . . . . . . . . . . . . . . 45
4.5.2.4 Emergency service request with emer-
gency registration . . . . . . . . . . . . 45
4.6 Emergency session in LTE . . . . . . . . . . . . . . . . . 45
5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2
1 Introduction
We have telephony to talk to each other, messaging to dispatch
mail or instant messages, browsing to read published content and
search engines to locate content sites. Mobile telephony with the cur-
rent technology has been hugely successful and shows that there is
an immense value in communicating with peers while being mobile.
With increasingly available smarter multimedia terminals the com-

munication experience will be something more than just exchanging
voice. Those multimedia terminals need IP multimedia networks.
Hence, the Third Generation Partnership Project (3GPP) has devel-
oped a standard for SIP based IP multimedia service machinery known
as ’The IMS (IP Multimedia Subsystem)’.
During the development of the IMS architecture, support of emer-

gency calls was gradually standardized and defined in the 3GPP IMS
architecture for GPRS and LTE technologies. Functionalities for each
technology are currently described and defined in many documents
and so far there has not been any complex description of how the
whole service works within the IMS.
The absence of an overall analysis of the emergency calls component

makes the work very unpleasant for operators during specification
of requirements for new IMS features as well as for IMS technology
vendors.
The result of my thesis will be an abstraction of this emergency com-

ponent and a description of its individual functions. This should be
usable for IMS developers and system engineers as a white paper.
3
2 IMS Architecture
IP Multimedia Subsystem is a technology framework that allows
delivering IP multimedia services in the telecommunication area. IMS
architecture has evolved from the currently out-dated GSM technol-
ogy. The main change is adding the support of multimedia traffic –
services including audio, video, text, chat, etc. – using packet switch-
ing technology. It is a network based on a wide range of protocols
defined primarily by the IETF (Internet Engineering Task Force). The
main protocol is SIP (Session Initiation Protocol) defined by IETF,
which is used to provide secure signaling. The main goal of this ar-
chitecture is to converge cable and mobile networks.[19]
IMS architecture is based on an internet protocol cooperating with

existing wired (PSTN, ISDN) and mobile (GSM, CDMA) telecommu-
nication technologies and allows to create a peer to peer IP connec-
tion with all types of clients.
There are several main characteristics[28] which make the IMS net-
work unique:
• The IMS provides a flexible support for IP multimedia ses-

sions that allow operators to differentiate their services.
• IP multimedia sessions are able to support a variety of differ-
ent media types.
• IP multimedia sessions are able to support a variety of differ-
ent media types.
• It is possible to support session-related internet applications
that have been developed outside the 3GPP community.
• Support of negotiable QoS for sessions and/or media compo-
nents.
• Possibility for a network operator to implement IP Policy Con-
trol
• Support of roaming
4
2. IMS A RCHITECTURE
• QoS of Voice shall is at least as good as that achieved by

circuit-switched.
• The principle of access independence. A variety of access net-

works types is supported.
• Interconnection of IMS networks is supported.
• Support of inter-working with circuit switched networks (PSTN

or PLMN).
2.1 History
IMS was originally standardized in 2003 by the 3GPP as part of
Release 5 specification as a new layer on the top of 3G IP networks.
In Release 6 released in 2005, cooperation with existing IMS circuit-
switched and IP networks was defined. The following specifications
Release 7 include a reduction in delays, which brings improvement
for real-time applications such as VoIP. [19]
Although IMS was designed to support VoIP as an important ap-

plication from the very beginning, adaptation of VoIP and IMS in
mobile networks was slow because these networks featured a highly
optimized support for traditional voice in the circuit switched do-
main and radio interface. Fixed network IMS deployments providing
voice thus became commercial reality before mobile deployments.
Early mobile deployments were mainly focused on non-voice appli-
cations.
However, improvements in radio technologies in recent years in-

creased the available bandwidth tremendously. As another trend,
various sorts of IP traffic consume a constantly rising percentage of
this bandwidth compared to voice traffic. Modern radio networks
are consequently no longer optimized for voice but rather designed
to transport a wide range of IP applications.
Long Term Evolution (LTE) is the latest generation of the 3GPP radio
technology and it was introduced in Release 8 around 2008. LTE no
5
longer features optimized radio bearers to support circuit switched

voice, but rather assumes voice over IP. 3GPP standards describe
Voice over IMS as the only voice solution over the LTE radio interface.[28]
2.2 IMS Components

IMS architecture is composed of many mutually connected[6] el-
ements:
CSCF (Call Session Control Function) – This is the root node of the
IMS architecture, which cares primarily about signaling. Four types
of CSCF can be distinguished: Proxy-CSCF, Interrogating-CSCF, Serving-
CSCF and Emergency-CSCF.
HSS (Home Subscriber Server) – This element is similar to the home

location register HLR (Home Location Register) in GSM technology.
It contains all the necessary information about users.
AS-SIP (Session Initiation Protocol Application Server ), OSA-SCS

(Open Service Access Service Capability Server) and IM-SSF (IP Mul-
timedia Service Switching Function) – these are application servers
allow the addition of multimedia services in IMS.
MRFC/P (Media Resource Function Controller/Processor) – This el-

ement is located in the home network. MRFC acts as a SIP user agent.
The main function of this element is to provide support for multime-
dia conferencing.
SLF (Subscriber Location Function) – This element is used only in

case there are more than one HSS and is used to assign the correct
HSS to the user.
MGCF (Media Gateway Controller Function) – This component is

necessary to connect the IMS network with the public telephone net-
work PSTN (Public Switching Telephone Network).
MGW (Media Gateway) – The final element for bearer channel from
6
circuit-switched networks and media streams from IP networks. Its

main functions are conversion, trans-coding and signaling.
BGCF (Breakout Gateway Control Function) – The main function of

this element is to act as a SIP proxy processing requests for routing
from an S-CSCF in case the session cannot be routed using DNS or
ENUM/DNS.
CF (Charging Function) – Charging function is an important element

of the IMS architecture and an integral function of IMS customer
care functionality. Charging for services is divided into two ways:
online (is intended for users who pay the bills periodically) and of-
fline charging (which a customer must prepay).[28]
2.3 IMS Layers

IMS architecture supports a wide range of services based on SIP.
These services allow IMS user access across different devices, both
via IP network or traditional telephone system. The IMS architecture
can be divided into a logical four-layer model. This dividing is based
on 3GPP specification.
Specifications and IMS standards described in the 3GPP project are a

summary of services and 3GPP specifically describes the functional
elements and how these elements are linked together with the de-
scription of used protocols.
The 3GPP allows to place more services on a single node or vice

versa. Therefore the technologies used must be unified (meaning that
they are configured to cooperate together) and work with the trans-
mission of information regardless of the type of information.[28, 11,
13]
2.3.1 Device Layer

A wide range of end-point devices can be used in the IMS. Hard-
ware components such as desktops, mobile phones, PDAs, tablets
7
Figure 2.1: IMS architecture overview.[27]
8
or digital phones are connected into the IMS infrastructure via an

IP network. Other types of devices, such as classical analog phones,
can not be connected directly to the IP network. Instead, they must
be connected through the PSTN gate specially established for this
purpose.[19, 28]
2.3.2 Transport Layer

The transport layer is responsible for the abstraction of the ac-
tual access networks (fixed-line, packet-switched radio, and so on)
and establishing or terminating sessions. This layer also provides the
conversion of data transferred between analog or digital formats and
packet format used in IP networks.[11]
The layer acts as an intersection point between the access layers and
the IP network above it. It is responsible for initial IP provisioning
(assigning an IP address and a default gateway via DHCP) as well as
facilitating the connection of devices to the higher layers.
This layer also enables an IMS device to create and make calls to the
PSTN network or to other circuit-switched (CS) networks through
the PSTN gateway . The main characteristic of this layer is that every-
thing above this layer is IP-based, while the access networks below
it need not be strictly IP-based. [29]
2.3.3 Control Layer

The main purpose of the layer is to control the authentication,
routing, and distribution of IMS traffic between the transport layer
and the service layer. Most of the traffic here is based on the Session
Initiation Protocol (SIP). This is why it is the control layer where the
core IMS components (CSCF and HSS) are deployed. The CSCF pro-
vides SIP endpoint registration of a device and processes SIP trans-
mission of signals relevant to the application server at the application
layer. The HSS (Home Subscribe Server) serves as a database of data
and profiles of each end user.[19]
The control layer also serves as an interface with services such as
9
a pay-per-download service, which enables users, for instance, to

buy ringtones or video. This layer ensures delivering the purchases
to interact with billing services, authentication services and quality
of service (QoS) needed for appropriate handling of the purchased
content.[29]
2.3.4 Service Layer

The service layer is where all of the services are operated. This
includes voice services (for instance voicemail, interactive voice re-
sponse, etc.) as well as new applications built on the IMS architec-
ture. Unlike the second generation (2G) networks, these services do
not need to completely replicate all aspects of the network (HSS,
routing or session control). The service layer is the final level of ab-
straction and makes the IMS an extremely powerful architecture al-
lowing to rapidly deploy new services which are operated by ap-
plication servers (one application server can host multiple services,
which provides the flexibility and comfort for operators).[29]
2.4 IMS Core Components

2.4.1 Proxy Call Session Control Function (P-CSCF)
The Proxy CSFC is the first contact point with IMS core network.
All SIP signaling must be routed through this component. After re-
ceiving a SIP request, the Proxy CSCF ensures that it is forwarded to
the proper destination. The responses from IMS are then forwarded
back to the user. This entity may be located in the home network or
in the visited network/networks.[28] Main functions that are used
are:[13]
• Protection of the integrity of SIP signaling based on IPsec.
• Protection of the connection between the UE and P-CSCF pre-

venting spoofing attacks and replay.
• Compression and decompression of SIP messages for the ra-

dio interface.
10
2.4.2 Serving Call Session Control Function (S-CSCF)
The Serving CSCF is the central node across the IMS and it is al-
ways located in the home network. It supervises the connection and
registration services. When the UE casts a session, the S-CSCF main-
tains the session and mutually communicates with the control plat-
form and the Charging function according to the requirements of the
network operator. The S-CSCF can have many[19] functions based
on the configuration by the network operator, the main ones[28] in-
clude:
SIP Registrar: User equipment (UE) registers within the IMS when
it is switched on. At this point in time the S-SCCF is assigned to that
UE, it loads the corresponding IMS user profile from the Home Sub-
scriber Server (HSS), and stores information related to the UE, such
as the SIP signaling path towards that UE. UE registered at the S-
CSCF is called "served UE".
IMS User Authentication: During the SIP registration the S-SCCF

interacts with served UE to authenticate the user.
Storing IMS User Profiles: As long as a user is registered, the S-CSCF

stores information related to that user.
Session Control: Each SIP session setup establishes media flows from
or to served UE, which will be routed through the S-CSCF assigned
to that UE. The S-CSCF controls whether the user is entitled for the
desired session according to the policies of the operator, as described
in the user profile. The S-CSCF may also adjust the session according
to this policy.
Service Control: Special handling related to a particular service can

be performed on an Application Server (AS). The S-SCCF can for-
ward a SIP session setup to an application server for such service
specific treatment. The S-SCF is well suited for this task as it is lo-
cated in the home network and home service control is an important
IMS concept.
11
Routing and Address Translation: For a session setup originating

from the served UE, the S-CSCF analyses the SIP request URI indi-
cating the called party to determine the next SIP node where to send
the request. The S-CSCF may also modify the Request URI and inter-
act with external databases (such as enum, see IETF RFC 3761 [123])
for that purpose. For a terminating SIP session setup towards the
served UE, the S-CSCF inserts stored routing information about the
SIP signaling path towards the served UE.
Charging Records: The S-CSCF collects charging-related informa-

tion for ongoing SIP sessions.
Lawful Interception Support: Offical access to private communica-

tion at the request of authorities.
Privacy Support: When the S-CSCF forwards SIP messages to un-

trusted SIP peers, it removes protected information such as the iden-
tity of the calling party.
2.4.3 Interrogating Call Session Control Function (I-CSCF)

This CSCF serves as a focal point of the network operator and it is
most often located in the home network. Its IP address is published
in the DNS domain, therefore remote servers can be used as a contact
points for SIP packets destined to that domain. The network operator
can handle several I-CSCF’s. The main functions[6] are:
• Contacting HSS to obtain the names of the particular S-CSCF’s
for handling a user. The assigning of a S-CSCF is based on
data on the capacity and characteristics sent from the HSS.
• Forwarding SIP requests and responses from the S-CSCF.
• Forwarding CCF (Charging Collection Function) data relat-
ing to the charges.
2.4.4 Emergency Call Session Control Function (E-CSCF)

Emergency CSCF provides IMS emergency processing require-
ments such as, for example, a session with the police, ambulance
12
or fire brigade. The main task of the E-CSCF is searching a loca-

tion information about the callee from the Location Retrieval Func-
tion (LRF) and forwards the call to a Public Safety Answering Point
(PSAP) or an emergency center.[28]
2.4.5 Home Subscriber Server (HSS)

he HSS is a database which stores all user profiles. Based on re-
quests from the I-CSCF the HSS allocates different users to different
S-CSCF’s. This database also includes security information used for
authentication and authorization of users and it can also provide in-
formation on their current location information.[6, 28]
The HSS provides support to call control servers for:
• Authentication and authorization.
• Routing and roaming procedures by solving naming/addressing

resolution, and providing location information.
• Provisioning of subscription related information.
2.5 Signaling
The IMS communication is based on SIP signaling. The SIP is
a protocol developed within the IETF standardization organization
and described in RFC 2543 document.
The purpose of the SIP is to provide session management among

more than one participant so that services such as voice, video, mul-
timedia, or gaming can be provided. It is a text-based protocol based
on HTTP and SMTP protocols. The SIP adopted the HTTP request-
response scheme. In this scheme, method, URI and the protocol ver-
sion are specified on the first line of the request. The responses con-
tain a release, a return code and its verbal description. The SIP has
adopted the division of a message into the head and body from the
SMTP.[31]
13
The format of the message body is described using MIME (Multi-

purpose Internet Mail Extensions).[31] Addressing of users is solved
by so-called SIP URI, which is similar to an e-mail address, except
that the method is not “mailto:” but “sip:” or “sips:” in case of secure
connection. For instance:
sip:kirk@starfleet.gov
sips:spock@starfleet.gov
SIP URI contains domain names, and is interconnected with the DNS
(Domain Name System). Where the SIP network is connected to a
public telephony network, the standard telephone numbers can be
used as a telephone URI:
tel:555486325
Despite the fact a telephone URI does not contain a domain name
it can be mapped to a particular domain using the ENUM (E.164
Number Mapping), which is a DNS extension enabling to search a
given domain for a given telephone URI.[4]
A message of another protocol that specifies the encoding used for

multimedia data, parameters and port numbers on which the data
is to be sent or received can be encapsulated within a SIP message.
It mostly operates on the UDP (User DatagramProtocol). The SIP
less often uses the TCP (Transmission Control Protocol) or the SCTP
(Stream Control Transmission Protocol). The SIP is assigned to port
5060 or port 5061 for secure SIP. [21]
The SIP serves as a signaling protocol providing the following[31]

services:
• Finding a participant – ensures that the call reaches the in-
tended participant and there will be mapping between the
address and the actual location (IP address).
• Availability – ensures that the caller will be informed whether
the callee is willing to accept the session.
• Ensuring of capacity – exchanging of information on sup-
ported media, formats and codecs between the parties.
14
• Establishing a connection – dialing the called party, the adop-

tion of trade and the establishment of voice and, if necessary,
other data channels.
• Management of changes – handling of changes in session pa-

rameters during the session and managing the termination of
the session.
2.5.1 SIP Architecture

2.5.1.1 User Agents
In the SIP network the SIP User Agent (UA) is and endpoint de-
vice whose function is to establish connections with another UA.
The User Agent Client (UAC) and the User Agent Server (UAS) can
be distinguished. The UAC is responsible for initializing the con-
nection whereas the UAS responds to incoming requests and sends
responses.[21]
2.5.1.2 Servers
Servers in the SIP architecture are devices that are used to medi-
ate contact among User Agents. Three types of servers can be distin-
guished: Proxy, Redirect and Registrar servers[31].
Proxy server
The proxy server accepts a request from another proxy or UA server

and routes towards the destination, or to directly target UA. The
proxy server can also run authentication and control administrative
policies.
Proxy servers are divided into stateless ones forwarding each mes-
sage they receive, and state ones which starts a transaction state ma-
chine for each message and ensures that the message is successfully
delivered.
Redirect server
15
The redirect server is also used to route requests to the target but
it does not send a message forward. It transmits information about
how to route the request to the target and the US must send the new
request to the changed address.
Registrar server
This is a registration server which accepts registration requests from

the UA and stores information from the request into a database of lo-
cation service for a given domain. This database is read by other SIP
servers which serve their own domains. This enables to transform a
SIP URI to an IP address.
2.5.2 SIP Messagging
2.5.2.1 Message Header
As mentioned before, the SIP is a text-based protocol. The for-

matting of SIP messages is based on the syntax of HTTP. A message
header is an important part of a SIP message and it consists of sev-
eral fields.[21] The most important[21] header fields are:
To: Identification of the callee.
From: This field identifies the caller.
Call-ID: Unique identification of the connection.
Via: This field contains the version of the SIP protocol, the version
of the transport protocol used and the IP address of the originator of
the message. Each server that sends the message forward inserts a
new VIA record with its IP address into the header.
CSeq: An ID that identifies the particular SIP transaction.
Content-type: This field describes the media type of the message

body.
16
Content-length: The length of the message body in octets. If this field

is set to zero 0, it indicates that there is no message.
The message body in an SIP message is separated from the header

by an empty line. SIP messages can contain multiple types of bodies.
Each body uses the MIME (Multipurpose Internet Mail Extension)
coding. The MIME format allows sending an email message that
contains attachments in various formats such as JPEG, MPEG, etc.
The message header contains information about the message body. It
may be, for example, the length, format, and the method of transfer.[21]
An example[3] of a SIP Header:
INVITE sip:bob@biloxi.example.com SIP/2.0

Via: SIP/2.0/TCP client.atlanta.example.com:5060
Max-Forwards: 70
Route: <sip:ss1.atlanta.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:alice@starfleet.gov;transport=tcp>
Content-Type: application/sdp
Content-Length: 151
2.5.2.2 SIP Requests

The SIP has 6 requests[17, 1] (also called methods):
REGISTER – This method is used to register the SIP endpoint on

the registrar server.
INVITE – This is a request to establish a call (a session). It also al-

lows to change addresses and ports, adding or canceling data flows.
An example:[17]
ACK – The ACK request is used to confirm that the endpoint has
17
received the final response in a transaction. Typically, after the called

party accepts a call, the caller confirms the receipt of the accepting
response (200 OK) using the ACK method.
CANCEL – This method is used to stop an INVITE that is in progress

(that is, the call has not been established yet).
BYE – The BYE method is used to end an established call (compare

with CANCEL, which is used to stop a session before it has been es-
tablished).
OPTIONS – This request is used to ask the other party for the list
of SIP methods it supports. The response may also contain the set of
capabilities (i.e. audio/video codecs) of the responding party.[21]
2.5.2.3 SIP Responses

Responses in the SIP are determined by numeric codes, which are
three-digit decimal numbers divided into six[21] categories.
In category 1xx there are provisional answers. They inform the sender
of the request that the message has been received and it is being pro-
cessed by the server. They are sent mostly when the INVITE method
is used. For instance, code 100 confirms the receipt of a request, code
180 indicates ringing:
100 Trying
180 Ringing
181 Call forwarded
182 Queued
183 Session progress
Replies 2xx indicate success and are used to validate successfully

completed requests. Mostly, the answer 200 OK is used.
The 3xx class indicates redirection for further action. They are used
by redirect servers to route requests to the target:
18
300 Multiple Choices

301 Moved Permanently
302 Moved Temporarily
380 Alternative Service
Category 4xx serves to inform about client errors. It is the largest

group of return codes:
400 Bad Requests

401 Unauthorised
403 Forbidden
404 Not Found
405 Method Not Allowed
415 Unsupported media Type
420 Bad Extensions
486 Busy Here
The class 5xx is a group of server errors:
500 Server Error

501 Not Implemented
503 Service Unavailable
504 Timeout
505 SIP Version Not Supported
Class 6xx indicates a global failure:
600 Busy Everywhere

603 Decline
604 Doesn’t Exist
606 Not Acceptable
19
Figure 2.2: An example of establishing a SIP call.
20
2.5.3 SDP Protocol
The SDP is a protocol used to describe multimedia sessions and it

is defined in RFC 4566. In signaling context, the SDP describes end-
points of session – IP addresses, ports and agreement about a codec
format. The SIP protocol needs the SDP SIP to successfully establish
a call.[12]
The SDP message (with a list of supported formats/codecs) is trans-

ported together with a SIP message both in requests and responses.
The initiator of a SIP session attaches SDP fields into a SIP INVITE
request. The receiving side then attaches an SDP message (indicating
which formats/codecs the receiving side is willing to support) into
SIP 200 OK answer. If one of the sides does not understand some
of the available format/codec, then 488 Not Acceptable Here
is sent instead of 200 OK.
Fields in SDP messages have the format <field code>=<value>.

The field code is always a single letter. The example below demon-
strates the SIP message consisting of mandatory fields:
v=0
o=alice 2890844526 2890844526 IN IP4 starfleet.gov
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
The meaning of the fields is as follows:
v – protocol version.
o – session owner and identifier (o=<username> <session id>
<version> <network type> <address type> <address>)
s – session name.
t – time the session is active (t=<start time> <stop time>) m – media
type, format, and transport address (m=<media> <port> <transport>
<format list>).
21
The <media> field is either "audio" or "video" (if the call contained
both audio and video, there would be two "m=" lines). The <port>
should always be even (the even port is used by RTP and the next
odd port by RTCP).
The <transport> field is usually "RTP/AVP", denoting the RTP

protocol with the profile for "Audio and Video Conferences with
Minimal Control".[2].
22
3 Supported Mobile Technologies in IMS
3GPP IMS currently supports all available mobile technologies,
even the old 2G Circuit Switched ones. Despite being outdated nowa-
days, these technologies are still currently in use worldwide.
3.1 GSM (2G)

2G second generation solutions are based on digital technology
and multiple access.1 There are several 2G systems: Global System
for Mobile Communication (GSM), Personal Access Communication
System (PACS) and Digital European Cordless Telephone (DECT).
GSM became the most used 2G technology in the world.[26]
Global System for Mobile Communication (GSM)
GSM, originally developed as an European standard, was introduced

in 1991 and very quickly become a worldwide standard. Main[26]
GSM characteristics are:
• a wide range of voice and data communications services.
• compatibility with a fixed line (e.g. ISDN).
• support of automatic roaming session.
GSM is theoretically capable of a speed of 22.8 kbps, but the actual

speed is reduced to only 9.6 kbps. The very slow data transfer rate is
therefore the main disadvantage of this technology. Another disad-
vantage is that the GSM uses transmission based on circuit switch-
ing, which means that the user pays for the time spent, not for the
amount of transferred data. These deficiencies have resulted in high
costs for users and discourage the use of data services offered.[23]
1. For example: Time Division Multiple Access (TDMA) or Code Division Mul-
tiple Access(CDMA).
23
3. S UPPORTED M OBILE T ECHNOLOGIES IN IMS
3.2 GPRS (2,5G)

General Packet Radio Service was defined by the European Telecom-
munications Standard Institute (ETSI) as a packet switched oriented
service over GSM networks. Its main goal is to increase physical re-
source utilization. GPRS is a service enabling data transfer and con-
nectivity to the Internet (or other networks) for users of GSM mobile
phones.
Using of packet switching (including both connectionless and connection-

oriented means of transmission) is positively reflected in the pay-
ment by the amount of data or time instead of paying for connection
time. The GPRS is referred to as "2.5G" technology between the sec-
ond (2G) and third (3G) generations of mobile phones. GPRS was
first included in the standard GSM Release 97.[18]
GPRS dynamically uses available channels (time slots) so that they

can be shared by multiple users. The advantage of GPRS is a bet-
ter use of available resources, the disadvantage is the inability or
difficulty of securing a guaranteed bandwidth or speed. For web
browsing, sending and receiving e-mails and chatting a guaranteed
minimum bandwidth is not required, as opposed to transmission of
streaming video or audio (internet TV and radio). The GPRS specifi-
cation includes support for protocols IP, PPP, X.25 and OSPIH.[18]
GPRS offered the following advantages:[26]
Speed: GPRS can theoretically reach speeds of up to 115.2 kbps, which

is two times faster than ISDN and ten times faster than other GSM
standards using transmissions based on circuit switching.
Immediacy: GPRS mobile devices can always be connected to the

network (if the area is covered by the network). The user does not
need to dial connection to obtain information.
Innovative services: GPRS started offering services that until then

had not been possible due to low transmission rates, such as Inter-
net, e-mail, music and office applications.
24
Price: A customer pays for the amount of data transferred and not
for time spent on the line.
GPRS also has its disadvantages:[26]
Low actual transfer rate: Theoretically possible speed can never be

reached. The actual speed of data transfer via GPRS is 14 kbps for
uplink speed and from 28 to 64 kbps for downlink speed.
Priority of voice traffic: GPRS exists along with GSM networks and
it is used only as a secondary network channel for data transmission.
Voice transmission always has a higher priority.
Three classes[18] of GPRS network can be distinguished:
Class A – allows simultaneous use of voice and GPRS data. This fea-
ture is known as Dual Transfer Mode.
Class B – supporting a call or data. Depending on network support it

is possible, for example, during a GPRS connection, to accept the call
and stop GPRS or vice versa. All currently marketed GPRS mobile
devices belong to Class B.
Class C – allows data traffic only from devices that can not make
phone calls (PCMCIA data cards, special industrial modules).
Implementing of GPRS has required non-trivial changes in the GSM

network. The major change was extending the GSM network by two
new types of nodes:
SGSN (serving GPRS support node)
GGSN (gateway GPRS support node)
SGSN nodes
SGSN nodes are responsible for delivering data to/from mobile sta-
25
tions within a radius of their geographical scope. SGSN nodes are

connected to the base station (BTS) through the base station control
(BSC) through which provide their own data.
It must always be able to find out where the relevant terminal is lo-
cated, verify its identity, ensure proper billing for services, etc. There-
fore the SGSN node has access to some registers (for example HLR –
a subscriber database).[30]
Main functions are:

• Detunnel GTP packets from GGSN (downlink).
• Tunnel IP packets toward GGSN (uplink).
• Carry out mobility management as Standby mode mobile moves
from one Routing Area to another Routing Area
• Billing user data
GGSN Nodes
GGSN node is the main component of the GPRS architecture. It acts

as a gateway between the GPRS network and external packet switched
networks (Internet, X.25), by providing interconnection of both net-
works and mediating a data transfer from one network to another.[30]
Quality of Service
GPRS offers different levels of QoS[18] in the following areas:
Priority – three priority levels are defined: high, medium and low.
Reliability – there are three reliability classes that define the prob-
ability of packet loss.
Delay – four classes are defined relative to the average delay.
Throughput - is defined as the maximum (peak) and mean trans-

mission speed.
26
3.3 UMTS (3G)

In 3G Universal Mobile Telephone Standard Technology, voice
services are no longer prioritized over other services. UMTS is de-
signed primarily to support data services while using CDMA fre-
quency division instead of TDMA.[32]
The main characteristics[30] for third-generation networks are:
• Support of high-speed communication services and asymmet-

rical data transmission.
• Support of discontinuous (IP transmission) and continuous

(video-conferencing) data transfers.
• New billing models (data versus time).
• Higher network capacity.
• Support of simultaneous voice and data transmissions (for

example, the user is able to use the Internet and the phone
simultaneously).
3G networks are focused on the principle of packet transmissions

rather than connection-oriented. With third-generation mobile net-
works is it possible to achieve significantly higher data speeds be-
cause of significantly wider frequency band than with the second
network generation. For example, GSM networks operate with fre-
quency channels of a width of 200 kHz, whereas the third genera-
tion operates with width of 5 MHz which are allocated in the 2 GHz
band.[30]
3.4 LTE
LTE technology is a 3GPP mobile system of 3rd generation im-
proving the current data-transmitting system (e.g. GPRS) and all com-
munication takes place only via packets. The LTE technology theo-
retically enables 100 Mbps of wireless transmission downlink speed
and 50 Mbps for uplink. In comparison with the previous systems,
27
the communication response has been significantly reduced to 10

ms.[20]
LTE consists of two basic parts - EPC (Evolved Packet Core) and
E-UTRAN (Evolved Universal Terrestrial Radio Access Network).
E-UTRAN is the concentration of the individual base stations eNB
(evolved Node Bs) that forms a gateway between the radio interface
and backbone network. The radio interface between the UE (User
Equipment) and the eNB is called the Uu interface.[24]
LTE is a network based on an orthogonal frequency division multi-

plexing OFDM (Orthogonal Frequency Division Multiplexing), which
is more beneficial for broadband applications than W-CDMA, which
is used by current UMTS systems and CDMA2000.
LTE supports QoS focusing on achieving a higher quality of "end-to-

end" services than earlier systems. Special scheduling strategy lim-
iting the interference from neighboring cells (inter-cell interference
coordination) is applied.[22]
LTE Architecture
LTE system architecture or SAE (System Architecture Evolution) is

based on pure packet access and does not support circuit switching.
LTE system uses the architecture which was introduced under Re-
lease 7 for HSPA+.[16]
LTE system consists of a radio access network E-UTRAN (Evolved-

UTRAN), which is used to communicate with users of the system,
and a packet network EPC (Evolved Packet Core), which corresponds
to the Core Network (CN) in UMTS system.
E–UTRAN
E-UTRAN radio access network ensures the connection between the

UE and EPC. It contains only base station eNB. Each eNB provides
radio coverage area of the E-UTRAN radio signal and assigns in-
dividual radio channels according to established priorities and the
28
required QoS. An UE is always linked to one MME (Mobility Man-

agement Entity) and S-GW (Serving Gateway). An important func-
tion of E-UTRAN is mobility management - tracking of motion in the
network.[16]
EPC
The EPC consists of several parts - MME, SAE-GW (System Archi-

tecture Evolution-Gateway), PCRF (Policy and Charging Rules Func-
tion) and HSS.
The main control element in LTE is MME, which can support sev-
eral UE, eNB and S-GW. Its main features include identity verifica-
tion and assigning temporary identification to each UE called GUTI
(Globally Unique Temporary Identity).[16]
All user data go through the SAE-GW gateway, which consists of

Service Gateway S-GW and the Packet data network gateway P-GW.
S-GW controls the flow of user data and control data and is associ-
ated with Gateway P-GW. P-GW is sometimes referred to as PDN-
GW (Packet Data Network Gateway ) and it is a router between the
EPS and external packet networks (e.g. IMS domain, Internet).
P-GW cooperates the DHCP server and assigns an IP address to a

user terminal. It is also connected to the PCRF, which is a network
element responsible for PCC (Policy and Charging Control) services.
It monitors the flow of services and checks whether QoS corresponds
to the user profile. PCRF is also responsible for billing.[16]
29
4 IMS Emergency Sessions
4.1 State of the Arts
There are two areas of problems which this thesis touches upon:
Communication between an architect and developer and lack of high-
level information about IMS emergency emergency call.
The general purpose of this thesis is to outline the problem of com-

munication between an IMS architect and developer. An architect is
supposed to have expert knowledge of 3GPP standard and must be
familiar with a large amount of documentation. A developer, on the
other hand, is a technological expert who is a highly trained C++
software engineer able to produce a good quality source code but
without having a high-level view of the IMS architecture.
A developer is supposed to deliver what is required by the architect,

and the requirements and his understanding is very often a stum-
bling block in the development process of an IMS feature. Therefore,
it seems that it would be very useful to provide a high-level white
paper of a particular part of IMS architecture so that the developers
are not confused. I believe this will prevent many questions and save
a lot of time spent in meetings.
Providing a high-level overview, as described above, requires scruti-

nizing a big amount of 3GPP documentation and carefully selecting
only information helpful for developers. But this raises a problem:
what to select from the documentation and what to leave out? In
other words, there is a need to find a method of selecting informa-
tion. For the purpose of this thesis the solution will be my own expe-
rience – more that one and a half years of professional experience as
an IMS architect.
I have often faced situations which could have been easily avoided
if there had been a high-level overview of a part of IMS architecture.
But there was not such white paper, which often caused lots of un-
necessary questions, mail-chains and meetings. Because of this expe-
30
4. IMS E MERGENCY S ESSIONS
rience I gained perspective of what information would help develop-

ers to better understand my design without being provided needless
information.
This chapter is an attempt to provide a high-level white paper par-

ticularly focused on IMS emergency calls. As described above, my
method of selecting proper information is based on my own work-
ing experience. The reason I choose this particular topic also reflects
my job experience – there is a lack of comprehensive high-level in-
formation of how emergency sessions work in 3GPP IMS.
I have tried to carry out information research into IMS emergency

calls based on the most influential IMS publications but I have found,
for example, hardly any information about emergency session in the
famous The IMS: IP Multimedia Concepts and Services,[28] which
is one of IMS must-reads. Hardly any mention of emergency calls
can be found in IMS Application Developer’s Handbook: Creat-
ing and Deploying Innovative IMS Applications.[25] There is a
small chapter describing how IMS emergency works in The 3G IP
Multimedia Subsystem (IMS): Merging the Internet and the Cellu-
lar Worlds,[14] however, not providing all information a developer
would need.
This chapter is an attempt to fulfill an information gap regarding

IMS emergency calls. It tracks the history of changes in IMS emer-
gency sessions, describes different behaviors of IMS architecture and
provides an abstraction of the most important emergency processes.
Some of them are modeled as UML diagrams. Main sources of in-
formation are 3GPP Technical Specifications 23.167, 23.228, 23.401,
23.869, 24.301 and 29.274.[5, 6, 8, 9, 7, 10]
4.2 History of Changes in 3GPP Standard

Release-8
For emergency service request without registration, the E-CSCF adds

a non-dialable call back number as the UE’s identity into the request,
31
if required by local regulations.
Release-9
The EATF is introduced to support emergency SR-VCC.
The major change is the introduction of emergency support in UTRAN

and E-UTRAN accesses.
Mandatory priority for CS emergency calls has been canceled. If a UE

is connected to a domain in which it is possible to request emergency
service, then the UE should use that domain to make an emergency
call. However, operator’s policy and/or local regulations may still
require attempting of emergency calls on a specific domain first.
A standardized Ml interface between E-CSCF and LRF based on SIP

has been specified.
Release-10
Supporting "eCall" as specified in 3GPP TS 22.101. The eCall is a

manually or automatically initiated emergency call (TS12) from a ve-
hicle, supplemented with a minimum set of emergency related data
(MSD), as defined under the EU Commission’s eSafety initiative.
Release-11
Special requirements exist to avoid unexpected supplementary ser-

vice interactions for emergency call back sessions.
3GPP SA1 has studied Non-Voice Emergency Service in 3GPP TR

22.871, but this work has triggered no implementation changes so
far.
32
4.3 Emergency calls - General Introduction

Emergency services are independent from the IP-CAN with re-
gard to the detection and routing of emergency sessions. The emer-
gency services are provided through mobile access network, fixed
broadband access, access to I-WLAN and a nomadic access.
When an emergency call is about to be generated, the user can be

in one of the following situations:
• The user is not roaming and has already performed a non-

emergency registration peviously. In this case an emergency
call cen be directly initiated.
• The user is not registered. In this case, irrespective of the state

of roaming, an emergency registration must be performed be-
fore generating the emergency call.
• Having performed a non-emergency registration before, the

user is roaming. Despite being already registered, the UE must
perform an emergency registration and then initiate an emer-
gency call.
• The user does not have enough credentials for authentication.

Then an anonymous emergency call s initiated.
Any emergency numbers and Emergency SIP and TEL URI as

specified in TS 22.101 are supported by special indication for an emer-
gency session in the SIP signaling. URI permitted to resolve the emer-
gency services may be subject to local laws in the serving network.
Emergency session is given priority over non-emergency session by

the IMS network. Establishment of emergency IMS session is possi-
ble for the users with a barred public user identity.
Emergency session establishment is based on ability of an UE to de-

tect an emergency session by evaluating the SIP URI or a dialed
emergency number. It is expected that an UE has sufficient creden-
tials to authenticate with the IMS network and is already registered
33
Figure 4.1: Overal Emergency Architecture
34
in an IMS network.
If an UE does not have sufficient credentials to authenticate IMS, it is

possible to establish a session without the existing security associa-
tion between the UE and the P-CSCF. Therefore, in case the UE does
not reach the necessary requirements, the IMS can support authen-
tication and registration if required by local regulations. However, if
required, the IMS can be configured to reject the emergency requests
from an UE which does not have sufficient credentials.[5]
Local regulatory requirements can mandate the following func-

tions:
• Provide precedence for emergency service requests over any
other services the UE may be engaged in.
• Define the identities (SIP and TEL URIs) that can be used for
emergency services.
• Allow/reject emergency service requests from an unauthen-
ticated UE.
• Support emergency centres and PSAPs to request a PSAP call
back session to a UE with which the emergency centre or
PSAP had an emergency session, if the UE is registered. These
calls are treated as normal calls in the network.
• Provide the caller’s location information. Location informa-
tion can be used in the IMS network to determine which PSAP
serves the area where the UE is currently located.
• Allow users to request privacy even for emergency calls.
4.4 IMS Emergency Architecture

For the purpose of this thesis it is necessary to describe the be-
haviour of emergency-related IMS components whose functionali-
ties and behaviour during emergency sessions differs from the stan-
dard situations.
35
4.4.1 User Equipment

If the UE Detects a request for establishing an emergency session,
it initiates a request in which the location information1 and TEL-URI
associated with a public user identifier are included to establish the
session.
The UE is able to establish an emergency session without being regis-

tered in IMS. In this case the UE is supposed to request an emergency
registration first. If registered in IMS, no emergency registration is re-
quired and the session can be established immediately.
During emergency session initiation, an UE must include in the re-

quest its own identifier in case the caller does not have sufficient IMS
registration credentials. The UE must be able to process a 380 SIP re-
sponse (Alternative Service) having set the TYPE to “emergency”.
When initiating an emergency session, an UE includes an emergency

service indication (and equipment identifier in case the caller is a per-
son who does not have sufficient credential for IMS registration) in
the request. An UE also handles a 380 (Alternative Service) response
with the type set to "emergency".
4.4.2 Proxy-CSCF
The IMS P-CSCF detects the emergency session requests from an
UE even if the UE is roaming and a user dials an emergency number
specific for the visiting network. The Proxy-CSCF, if located in home
network, is able to recognize an emergency request whether it is in-
dicated by the UE or not. After accepting an emergency request,2 the
Proxy-CSCF forwards the request to an Emergency-CSCF.
1. “Location information in emergency sessions is needed to enable the IMS net-

work to determine which PSAP serves the area where the UE is currently located,
so that the IMS can route emergency session to the correct PSAP and PSAP can get
more accurate or updated location information. (...) The location information may
consist of network location information, that is the Location Identifier, and/or the
Geographical location information.”[5]
2. Not in case it is an emergency registration request.
36
When processing an emergency registration request, the Proxy-CSCF

handles these requests like any other IMS registration requests. The
only difference compared with normal behavior is that if emergency
registration is not supported by IM CN subsystem which Proxy-CSCF
belongs to, the request might be rejected.3 If not, the Proxy-CSCF for-
wards the emergency request to Emergency-CSCF.
Anonymous or unmarked emergency session requests can also be

rejected during establishing an emergency session. In the same time,
the Proxy-CSCF overhauls the request to forestall associating non-
emergency requests with emergency ones.
If instructed by operator’s policy or local regulations,4 the Proxy-

CSCF can forward the emergency session to a Serving-CSCF in case
of non-roaming users.
4.4.3 Emergency CSCF

The Emergency-CSCF is a main node of the entire emergency pro-
cess. It serves for retrieving geographical location information form
the LRF in case the location info is not included in the emergency re-
quest. Based on the location information and/or any other additional
information,5 the emergency session establishment request is routed
by Emergency-CSCF to the proper PSAP or BGCF. The Emergency-
CSCF can also send a request for validation of the location informa-
tion to the LRF and ask for proper routing information.
The Emergency-CSCF also handles emergency establishment requests

delivered from a Proxy-CSCF or an Serving-CSCF and routes them to
the proper destination. The routing is based on information included
in an emergency request, such as the type of emergency, current lo-
cation of the User Equipment or a default PSAP/BGCF/emergency
centre.
3. This happens, for instance, because of operator’s policy.

4. This can happen, for example, in case the P-CSCF recognizes that an emer-
gency session was not received via a security associations for a UE previously au-
thenticated with digest type proxy authentication.
5. For instance the type of emergency service.
37
In case the UE does not have sufficient credentials, the Emergency-

CSCF generates a non-dialable callback number if this is required
by the operator’s policy or local regulations. Also, if required, the
Emergency-CSCF can route the emergency call to ECS for further call
processing.
4.4.4 Location Retrieval Function

The Location Retrieval Function (LRF) serves as a provider of lo-
cation information of an User Equipment which initiated the emer-
gency session establishment request. The information transmitted to
an Emergency-CSCF includes routing details and other information
necessary to establish a reliable emergency session. The number and
type of the additional information differs depending on local regula-
tions or operator’s policy.6
The information provided by the LRF to the Emergency-CSCF in-

cludes correlation information identifying both the LRF and the emer-
gency session record in the LRF. This correlation information is dis-
tributed to the PSAP when establishing a session (typically in a SIP
INVITE).
4.4.5 Serving-CSCF
The Serving CSCF handles emergency registration requests re-
ceived from the Proxy CSCF. After receiving a request it determines
the duration of the registration by checking the value of the Expires
header in the received REGISTER request.7
The Serving CSCF downloads a proper default user profile (corre-

sponding to local or operator’s policy) from HSS in case the user is
not normally registered (meaning there is a standard IMS registra-
tion but no emergency registration). After creating a new IMS sub-
6. For example, this information may include the ESQK, ESRN, LRO in North
America, location number in EU usually contains PSAP, SIP-URI or TEL-URI.
7. The value of the emergency registration time is subject to local regulations and
can be subject to roaming agreements.
38
Figure 4.2: IMS Emergency session establishing.
39
scription the Serving CSCF check that the user status in HSS is set to
UNREGISTERED.
In case the user is normally registered the Serving CSCF ensures

that the registration status is unchanged. If the status is changed, the
Serving CSCF might de-register the user from the HSS or keep the
registration status of the user unchanged in the HSS.
If there is already an emergency registration for the user, the S-CSCF

ensures that the HSS keeps S-CSCF name allocated to this subscriber
and the registration status is set to UNREGISTERED.
If there is an emergency session initiation by a non-roaming sub-

scriber, the S-CSCF authenticates the caller the same way as for any
other sessions and if needed, it routes the request to AS and to an
Emergency CSCF.8
4.4.6 Emergency Access Transfer Function (EATF)

EATF provides IMS emergency session continuity, which is spec-
ified in TS 23.237.
4.4.7 Interrogation-CSCF
I-CSCF supports IMS emergency session continuity, which is spec-
ified in TS 23.237.
4.4.8 Application Server

An AS can be involved in emergency session handling (e.g. for
emergency made via hosted enterprise services or for AS initiated
session).
The AS provides the following emergency functions:

• Detecting an emergency session establishment request.
8. The AS can initiate an emergency request on behalf of a non-roaming user, can

convert private network traffic to public network traffic, or can interpret a number
in a private numbering plan and detect that the request is for emergency session.[5]
40
• Verifying that the UE is not roaming.
• Obtaining location information if needed.
• Prioritizing the emergency session.
• Inserting the TEL URI associated with the public user identity
into the session request.
• Checking the validity of the caller TEL URI if provided by the

UE.
• Marking the request as an emergency session request.
4.4.9 HSS
In the course of an emergency registration, the HSS does not ap-
ply any barring condition and/or roaming restriction associated with
the Public User Identity received in the emergency registration request.[5]
4.5 Establishing of IMS Emergency Session

4.5.1 IMS Emergency Registration
Emergency registration results in an independent contact for emer-
gency services and they also ensure that the contact is registered
through a local P-CSCF. The emergency registration follows "normal"
IMS registration procedure with the following additions:
1.An sos SIP URI parameter as defined in 3GPP TS 24.229 is added

into the Contact header field indicating that this is an emergency reg-
istration. This indication may be used to inform the home network
that roaming restrictions are applied.
2. No subscriptions to registration event packages, no UE initiated

nor network initiated de-registration, registration timer are subject
to national regulations and possible roaming agreements.
3. The emergency registration is independent from all other users’
41
registrations.
The UE shall initiate an IMS emergency registration when all of

the following conditions are met:
• either the UE is not already IMS registered or the UE is IMS
registered but is roaming outside its home network.
• the UE has sufficient credentials to authenticate with the IMS

network.
• the UE is able to detect an emergency session.

The UE initiates an IMS emergency registration after receiving
an "IMS emergency registration required" response as a result of the
emergency session request.
After initiating an IMS emergency registration, the UE first start emer-

gency access to the IP-CAN and to PSAPs requesting a PSAP call
back session.
The user’s home network ignores roaming restrictions for emergency

registration requests.
P-CSCF handles registration requests with emergency indications like

any other registration request. The S-CSCF in the home network may
modify the received registration expiration value from the request
according to local regulations or operator’s policy in the serving system.[5]
4.5.2 Emergency Service Request

4.5.2.1 Non UE detectable emergency service request
If the UE does not recognize the dialed number as an emergency
number, it sends a normal service request to the network. After rec-
ognizing an emergency service request, the P-CSCF (in the visited
network or the P-CSCF in the home network for a non-roaming UE)
may allow the service request to continue. The P-CSCF inserts an ex-
plicit emergency indication into the request and forward the request
42
Figure 4.3: Emergency service requests procedures
43
to an E-CSCF. The E-CSCF informs the UE that the service request

has been marked as an emergency service request.
If the P-CSCF detects an emergency session establishment request,

based upon operator’s policy the P-CSCF may reject the session ini-
tiation request. After rejecting, if a dialed number is available, the UE
can attempt to initiate a call to the dialed number in the CS domain.
Alternatively, the P-CSCF in the visited PLMN or the P-CSCF in the

home PLMN for a non-roaming UE may allow the session initiation
request to continue by inserting an explicit emergency indication in
the session request.
After this, in the visited PLMN request, the request is forwarded to

an Emergency CSCF in the same network. In the home PLMN for
a non-roaming UE the request is sent to a Serving CSCF or to an
Emergency CSCF in the same network (based on local regulations or
operator’s policy).
Then the E-CSCF sends to the UE information about marking the

session as emergency so that the UE can start emergency session
initiation.[5]
4.5.2.2 Emergency service request without registration
After initiating emergency session without being registered in

IMS, the UE includes both the "anonymous user" and "emergency
service" indications in the establishment request.
If required by local regulations, the P-CSCF rejects "anonymous user"

requests with the appropriate error code. Otherwise the P-CSCF ac-
cepts the "anonymous user" emergency request and sends it to the
respective E-CSCF. If required, the E-CSCF generates a non-dialable
callback number as an identification of the UE.[5]
44
4.5.2.3 Emergency service request with normal registration

The UE inserts an emergency service indication into the request.
Unlike in the "Non UE detectable emergency service request" proce-
dure, P-CSCFs outside the home network must always reject such re-
quest (mandating either emergency registration or CS domain usage).[5]
4.5.2.4 Emergency service request with emergency registration

The UE sends an emergency service request after emergency reg-
istration. Normally the P-CSCF accepts such request, but it is possi-
ble that due to local policy the P-CSCF does not support all types of
emergency service requests in the geographical location where the
UE is located or the IP-CAN which the UE is attached to.[5]
4.6 Emergency session in LTE

There are some specifics in LTE when establishing an emergency
call. There is, for example, no HSS subscription for an UE (HSS au-
thentication is optional). A special default emergency APN (Access
Point Name) must be stored in MME (defining for example QoS pa-
rameters or a static PDN gateway address) for the case an UE does
not send its own APN.
For emergency attach a n E-UTRAN initial procedure is used after

which an UE is in a limited service state and an emergency bearer
is established. The limited service state is used to describe specific
situation when UE can not obtain normal services. For example: UE
enters in the limited service state when it is without a SIM, or UE
enters in the limited service when there is no cell available like in
roaming situations.[15]
When performing an emergency attach, an UE sends an attach re-

quest (with TYPE set to „Emergency“) to MME. The MME can ask
HSS for authentication if required. After receiving an emergency at-
tach, MME sends the Create Session Request to SGW/PGW based on
the address already defined APN. Based on the response the attach
procedure may be completed and the UE can make an emergency
45
Figure 4.4: LTE emergency session establishing
46
call. After finishing the call, the UE does not detach – MME releases
the call.
UE can also request establishing an emergency session even after

normal attach by sending PDN connectivity request with TYPE set
to „Emergency“.[8]
47
5 Summary
The aim of this thesis was to provide a high-level overview of
IMS emergency session handling detailed enough to be usable for
IMS developers. The purpose of this challenge is to overcome a gap
in communication between an IMS architect and IMS developer.
In the first part of my thesis I summarized the most important facts

about 3GPP IMS and SIP protocol, and provided an overview of the
most commonly used mobile technologies. This created a basis to un-
derstand the principles of IMS.
In the second part of my thesis I had to deeply scrutinize 3GPP doc-

umentation relevant to emergency sessions. Based on my working
experience as an IMS architect I attempted to compose a logically
structured white paper with all information necessary to understand
the behavior of the IMS emergency process without a necessity to ex-
amine a large amount of documentation.
To abstract the most important emergency processes, I have also cre-

ated UML diagrams to provide high-level models of the pre-initiation
process, the session initiation process and the LTE emergency attach
procedure.
This thesis can be used by IMS developers to get a general overview

of emergency sessions handling detailed enough so that they can un-
derstand the principles behind their programming. This thesis is in-
tended to be distributed in my company as a white paper and also in
main Internet forums focused on 3GPP IMS or Open IMS Core.
Regarding emergency sessions, an improvement of this thesis would

be the exploring of non-voice emergency session support already de-
fined in 3GPP but not fully implemented yet. As a next step in solv-
ing the problem of communication and the lack of general under-
standing of IMS architecture would be creating a register of IMS core
white papers providing high-level decsriptions and models of the
entire IMS. This would reflect the current need for having an under-
48
5. S UMMARY
standable general overview of IMS core components which would

not be so detailed as 3GPP standard.
49
Bibliography
[1] Ip multimedia subsystem. In Wikipedia : the free ency-
clopedia. [online] http://en.wikipedia.org/wiki/IP_
Multimedia_Subsystem. Accessed: 2014-04-03.
[2] Rfc: 3551. rtp profile for audio and video conferences with
minimal control. [online] http://www.ietf.org/rfc/
rfc3551.txt. Accessed: 2014-04-09.
[3] Rfc: 3665. session initiation protocol (sip) basic call flow exam-
ples. [online] https://tools.ietf.org/html/rfc3665.
Accessed: 2014-04-03.
[4] Telephone number mapping. In Wikipedia : the free

encyclopedia. [online] http://en.wikipedia.org/wiki/
Telephone_number_mapping. Accessed: 2014-04-03.
[5] 23.167, G. T. Ip multimedia subsystem (ims) emergency ses-

sions, June. 2013.
[6] 23.228, G. T. Ip multimedia subsystem (ims); stage 2; release

11, June 2012.
[7] 23.401, G. T. Gprs and e-utran access, June 2013.
[8] 23.869, G. T. Emergency calls over general packet radio service

(gprs) and evolved packet service (eps), June 2012.
[9] 24.301, G. T. Nas protocol for eps, June 2013.
[10] 29.274, G. T. Gprs and eps tunnelling protocol, June 2013.
[11] BENDÍ ČEK, M. Ip multimedia subsystem. Master’s thesis,

Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a
komunikačních technologií, 2008.
[12] BETLACH, M. Ip multimedia subsystem a jeho využití pro za-

jištění kvality služeb. Master’s thesis, Brno: Vysoké učení tech-
nické v Brně, Fakulta elektrotechniky a komunikačních tech-
nologií, Brno, 2008.
50
5. S UMMARY
[13] BOŽEK, M. Open ims core a ip multimedia subsystem. Mas-

ter’s thesis, Brno: Vysoké učení technické v Brně, Fakulta elek-
trotechniky a komunikačních technologií, 2011.
[14] C AMARILLO , G. The 3G IP Multimedia Subsystem (IMS): Merg-
ing the Internet and the Cellular Worlds. Willey, 2008.
[15] D ORNAL , S. Ims emergency calls over lte. [on-
line]http://wired-n-wireless.blogspot.co.at/
2012/04/ims-emergency-calls-over-lte-short.
htmlAccessed:2014-05-18.
[16] E RIK D AHLMAN , S TEFAN PARKVALL , J. S. 4G: LTE/LTE-
Advanced for Mobile Broadband, 1 ed. Academic Press, 2011.
[17] G ROUP, N. W. Rfc: 3665. session initiation protocol (sip) ba-
sic call flow examples. [online] https://tools.ietf.org/
html/rfc3665, 2003.
[18] H EINE , G. GPRS: Gateway to Third Generation Mobile Net-
works, 1 ed. Artech House, 2003.
[19] JEANTTI, J. IMS version 9 implementation guide. A techni-
cal overview, 1 ed. San Jose, CA: IBM, International Technical
Support Organization, 2004.
[20] J OHNSON , C. Long Term Evolution in Bullets, 2 ed. CreateSpace
Independent Publishing Platform, 2012.
[21] JOHNSTON, A. SIP: Understanding the Session Initiation Pro-
tocol. Artech House, 2009.
[22] M ATYÁŠ , J. Možnosti potenciálu nově dostupných služeb v
sítích long term evolution. Master’s thesis, Univerzita Tomáše
Bati ve Zlíně, Fakulta aplikované informatiky, 2010.
[23] M OULY, M. The GSM System for Mobile Communications. Tele-
com Publishing, 1992.
[24] N AVRÁTIL , P. Modely systému lte. Master’s thesis, Vysoké
učení technické v Brně, Fakulta elektrotechniky a komu-
nikačních technologií, 2013.
51
5. S UMMARY
[25] N OLDUS , R. IMS Application Developer’s Handbook: Creating

and Deploying Innovative IMS Applications. Academic Press,
2011.
[26] O PRŠALOVÁ , S. Mobile commerce - porovnání situace v

Čr a v zahraničí. Master’s thesis, Masarykova univerzita
Brno, Ekonomicko-správní fakulta, Katedra podnikového
hospodářství, 2007.
[27] O RACLE. An ims application example based on

sip servlets and voicexml. [online] http://www.
oracle.com/technetwork/articles/entarch/
ims-sip-voicexml-086509.html.
[28] POIKSELKA, M. The IMS: IP Multimedia Concepts and Ser-

vices. England: WILEY, 2009.
[29] SALCHOW, K. Introduction to the ip multimedia

subsystem (ims): Ims basic concepts and terminology.
[online]https://www.f5.com/pdf/white-papers/
ims-introduction-wp.pdf. Accessed: 2014-04-03.
[30] V ELICKÝ, T. Datové přenosy po gsm sísítí, technologie hscsd,

gprs a umts. Master’s thesis, Jihočeská Univerzita, Pedagogická
fakulta, Katedra informatiky, 2002.
[31] VONDRA, T. Měření propustnosti voip sítí. Master’s thesis,

České vysoké učení technické v Praze, Fakulta elektrotechnická,
Katedra počítačů, 2011.
[32] WALKE , B. UMTS: The Fundamentals. Wiley, 2003.
52

Chit Sheet Ims

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Chit Sheet Ims

Diunggah oleh

Hak Cipta:

Format Tersedia

M ASARYKOVA UNIVERZITA

Emergency Calls Handling in

Advisor: doc. RNDr. Eva Hladká, Ph.D.

With increasingly available smarter multimedia terminals the com-

During the development of the IMS architecture, support of emer-

The absence of an overall analysis of the emergency calls component

The result of my thesis will be an abstraction of this emergency com-

IMS architecture is based on an internet protocol cooperating with

• The IMS provides a flexible support for IP multimedia ses-

• QoS of Voice shall is at least as good as that achieved by

• The principle of access independence. A variety of access net-

• Interconnection of IMS networks is supported.

• Support of inter-working with circuit switched networks (PSTN

Although IMS was designed to support VoIP as an important ap-

However, improvements in radio technologies in recent years in-

longer features optimized radio bearers to support circuit switched

2.2 IMS Components

HSS (Home Subscriber Server) – This element is similar to the home

AS-SIP (Session Initiation Protocol Application Server ), OSA-SCS

MRFC/P (Media Resource Function Controller/Processor) – This el-

SLF (Subscriber Location Function) – This element is used only in

MGCF (Media Gateway Controller Function) – This component is

circuit-switched networks and media streams from IP networks. Its

BGCF (Breakout Gateway Control Function) – The main function of

CF (Charging Function) – Charging function is an important element

2.3 IMS Layers

Specifications and IMS standards described in the 3GPP project are a

The 3GPP allows to place more services on a single node or vice

2.3.1 Device Layer

Figure 2.1: IMS architecture overview.[27]

or digital phones are connected into the IMS infrastructure via an

2.3.2 Transport Layer

2.3.3 Control Layer

The control layer also serves as an interface with services such as

a pay-per-download service, which enables users, for instance, to

2.3.4 Service Layer

2.4 IMS Core Components

• Protection of the integrity of SIP signaling based on IPsec.

• Protection of the connection between the UE and P-CSCF pre-

• Compression and decompression of SIP messages for the ra-

2.4.2 Serving Call Session Control Function (S-CSCF)

IMS User Authentication: During the SIP registration the S-SCCF

Storing IMS User Profiles: As long as a user is registered, the S-CSCF

Service Control: Special handling related to a particular service can

Routing and Address Translation: For a session setup originating

Charging Records: The S-CSCF collects charging-related informa-

Lawful Interception Support: Offical access to private communica-

Privacy Support: When the S-CSCF forwards SIP messages to un-

2.4.3 Interrogating Call Session Control Function (I-CSCF)

2.4.4 Emergency Call Session Control Function (E-CSCF)

or fire brigade. The main task of the E-CSCF is searching a loca-

2.4.5 Home Subscriber Server (HSS)

The HSS provides support to call control servers for:

• Authentication and authorization.

• Routing and roaming procedures by solving naming/addressing

• Provisioning of subscription related information.

The purpose of the SIP is to provide session management among

The format of the message body is described using MIME (Multi-

A message of another protocol that specifies the encoding used for

The SIP serves as a signaling protocol providing the following[31]

• Establishing a connection – dialing the called party, the adop-

• Management of changes – handling of changes in session pa-

2.5.1 SIP Architecture

The proxy server accepts a request from another proxy or UA server