Emergency Calls Handling in IP Multimedia Subsystem Network

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý Emergency Calls Handling in IP Multimedia Subsystem Network MASTER THESIS 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 literature used or excerpted during elaboration of this work are properly 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 support during the work on my thesis. iii

Abstract IP Multimedia Subsystem has been developed by the 3GPP organization for the purpose of convergence of voice and multimedia services (chat, Internet, video, etc.) and it is now used by mobile operators worldwide. The development of particular IMS components is quite specific and depends rather on good communication and understanding 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 perspective 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 sufficiently informative high-level document. The goal of this thesis is to contribute to better understanding and communication during various stages of software development life-cycle of those IMS components which are related to emergency session. iv

Keywords IP, SIP, IMS, HSS, CSCF, 3GPP, Emergency, GSM, UMTS, GPRS, LTE, VoLTE v

Abbreviations: 3G 3GPP AAA ACK AuC AVP BGCF CDMA CDR CSCF DHCP DNS GGSN GPRS HSS HTTP I-CSCF ID IETF IMEI IMS IP IPsec LRR LTE MGCF MGW MRFC MRFP MSISDN NGN OSA-SCS P-CSCF PDF PLMN Third Generation Third Generation Partnership Project Authentication Authorization Accounting Acknowledgement Authentication Centre Attribute Value Pairs Breakout Gateway Control Function Code Division Multiple Access Call Data Record Call Session Control Function Dynamic Host Configuration Protocol Domain Name Server Gateway GPRS Support Node General Packet Radio Services Home Subscriber Server Hyper Text Transfer Protocol Interrogating CSCF Identifier Internet Engineering Task Force International Mobile Equipment Identity IP Multimedia Subsystem Internet Protocol IP Security Protocol Location Retrieval Function Long-Term Evolution Media Gateway Controller Function Media Gateway Media Resource Function Controler Media Resource Function Processor Mobile Subscriber Integrated Services Digital Network Number Next Generation Network Open Service Access Service Capability Server Proxy CSCF Policy Decision Function Public Land Mobile Network vi

PoC PSI PSTN QoS RSVP RTP RTR S-CSCF SCTP SIM SIP SIP-AS SLF SQN SRVLOC TCP TDMA THIG TLS TMSI UDP UE UMTS UPSF URI VoIP Push-to-talk over Cellular Public Service Identifier Public Switching Telephone Network Quality of Service ReSerVation Protocol Real-time Transport Protocol Response Time Reporter Serving CSCF Stream Control Transmission Protocol Subscriber Identity Module Session Initiation Protocol Session Initiation Protocol Application Server Subscriber Location Function Sequence Number Service Location Protocol Transmission Control Protocol Time Division Multiple Access Topology Hiding Inter-network Gateway Transport Layer Security Temporary Mobile Subscriber Identity User Datagram Protocol User Equipment/Endpoint Universal Mobile Telecommunication System User Profile Server Function Uniform Resource Identifier 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 registration.................. 44 4.5.2.3 Emergency service request with normal registration.............. 45 4.5.2.4 Emergency service request with emergency 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 current 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 communication experience will be something more than just exchanging voice. Those multimedia terminals need IP multimedia networks. Hence, the Third Generation Partnership Project (3GPP) has developed 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 emergency 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 component 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 technology. The main change is adding the support of multimedia traffic services including audio, video, text, chat, etc. using packet switching 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 architecture 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) telecommunication technologies and allows to create a peer to peer IP connection with all types of clients. There are several main characteristics[28] which make the IMS network unique: The IMS provides a flexible support for IP multimedia sessions that allow operators to differentiate their services. IP multimedia sessions are able to support a variety of different media types. IP multimedia sessions are able to support a variety of different 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 components. Possibility for a network operator to implement IP Policy Control Support of roaming 4

2. IMS ARCHITECTURE QoS of Voice shall is at least as good as that achieved by circuit-switched. The principle of access independence. A variety of access networks 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 circuitswitched 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 application 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 domain 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 applications. However, improvements in radio technologies in recent years increased 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

2. IMS ARCHITECTURE 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] elements: 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 Multimedia Service Switching Function) these are application servers allow the addition of multimedia services in IMS. MRFC/P (Media Resource Function Controller/Processor) This element is located in the home network. MRFC acts as a SIP user agent. The main function of this element is to provide support for multimedia 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 network PSTN (Public Switching Telephone Network). MGW (Media Gateway) The final element for bearer channel from 6

2. IMS ARCHITECTURE 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 offline 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 description 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 transmission 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. Hardware components such as desktops, mobile phones, PDAs, tablets 7

2. IMS ARCHITECTURE Figure 2.1: IMS architecture overview.[27] 8

2. IMS ARCHITECTURE 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 actual 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 everything 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 provides SIP endpoint registration of a device and processes SIP transmission 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

2. IMS ARCHITECTURE 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 response, etc.) as well as new applications built on the IMS architecture. 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 abstraction and makes the IMS an extremely powerful architecture allowing to rapidly deploy new services which are operated by application 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 receiving 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 preventing spoofing attacks and replay. Compression and decompression of SIP messages for the radio interface. 10

2. IMS ARCHITECTURE 2.4.2 Serving Call Session Control Function (S-CSCF) The Serving CSCF is the central node across the IMS and it is always located in the home network. It supervises the connection and registration services. When the UE casts a session, the S-CSCF maintains the session and mutually communicates with the control platform 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] include: 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 Subscriber 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 forward 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 located in the home network and home service control is an important IMS concept. 11

2. IMS ARCHITECTURE Routing and Address Translation: For a session setup originating from the served UE, the S-CSCF analyses the SIP request URI indicating the called party to determine the next SIP node where to send the request. The S-CSCF may also modify the Request URI and interact 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 information for ongoing SIP sessions. Lawful Interception Support: Offical access to private communication at the request of authorities. Privacy Support: When the S-CSCF forwards SIP messages to untrusted SIP peers, it removes protected information such as the identity 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 relating to the charges. 2.4.4 Emergency Call Session Control Function (E-CSCF) Emergency CSCF provides IMS emergency processing requirements such as, for example, a session with the police, ambulance 12

2. IMS ARCHITECTURE or fire brigade. The main task of the E-CSCF is searching a location information about the callee from the Location Retrieval Function (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 requests 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 information 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, multimedia, or gaming can be provided. It is a text-based protocol based on HTTP and SMTP protocols. The SIP adopted the HTTP requestresponse scheme. In this scheme, method, URI and the protocol version are specified on the first line of the request. The responses contain 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

2. IMS ARCHITECTURE The format of the message body is described using MIME (Multipurpose 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 intended 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 supported media, formats and codecs between the parties. 14

2. IMS ARCHITECTURE Establishing a connection dialing the called party, the adoption of trade and the establishment of voice and, if necessary, other data channels. Management of changes handling of changes in session parameters 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 device 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 connection 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 mediate contact among User Agents. Three types of servers can be distinguished: 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 message they receive, and state ones which starts a transaction state machine for each message and ensures that the message is successfully delivered. Redirect server 15

2. IMS ARCHITECTURE 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 location 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 formatting 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 several 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

2. IMS ARCHITECTURE 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 allows 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

2. IMS ARCHITECTURE 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 established). 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 processed 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

2. IMS ARCHITECTURE 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

2. IMS ARCHITECTURE Figure 2.2: An example of establishing a SIP call. 20

2. IMS ARCHITECTURE 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 endpoints 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 transported 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 demonstrates 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

2. IMS ARCHITECTURE 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 nowadays, 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 disadvantage is that the GSM uses transmission based on circuit switching, 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 Multiple Access(CDMA). 23

3.2 GPRS (2,5G) 3. SUPPORTED MOBILE TECHNOLOGIES IN IMS General Packet Radio Service was defined by the European Telecommunications Standard Institute (ETSI) as a packet switched oriented service over GSM networks. Its main goal is to increase physical resource utilization. GPRS is a service enabling data transfer and connectivity to the Internet (or other networks) for users of GSM mobile phones. Using of packet switching (including both connectionless and connectionoriented means of transmission) is positively reflected in the payment by the amount of data or time instead of paying for connection time. The GPRS is referred to as "2.5G" technology between the second (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 better 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 specification 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 Internet, e-mail, music and office applications. 24

3. SUPPORTED MOBILE TECHNOLOGIES IN IMS 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 feature 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

3. SUPPORTED MOBILE TECHNOLOGIES IN IMS 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 located, verify its identity, ensure proper billing for services, etc. Therefore 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 networks 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 probability of packet loss. Delay four classes are defined relative to the average delay. Throughput - is defined as the maximum (peak) and mean transmission speed. 26

3.3 UMTS (3G) 3. SUPPORTED MOBILE TECHNOLOGIES IN IMS In 3G Universal Mobile Telephone Standard Technology, voice services are no longer prioritized over other services. UMTS is designed primarily to support data services while using CDMA frequency division instead of TDMA.[32] The main characteristics[30] for third-generation networks are: Support of high-speed communication services and asymmetrical 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 networks is it possible to achieve significantly higher data speeds because of significantly wider frequency band than with the second network generation. For example, GSM networks operate with frequency channels of a width of 200 khz, whereas the third generation 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 improving the current data-transmitting system (e.g. GPRS) and all communication takes place only via packets. The LTE technology theoretically enables 100 Mbps of wireless transmission downlink speed and 50 Mbps for uplink. In comparison with the previous systems, 27

3. SUPPORTED MOBILE TECHNOLOGIES IN IMS 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 multiplexing 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-toend" services than earlier systems. Special scheduling strategy limiting 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 Release 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 individual radio channels according to established priorities and the 28

3. SUPPORTED MOBILE TECHNOLOGIES IN IMS required QoS. An UE is always linked to one MME (Mobility Management Entity) and S-GW (Serving Gateway). An important function of E-UTRAN is mobility management - tracking of motion in the network.[16] EPC The EPC consists of several parts - MME, SAE-GW (System Architecture Evolution-Gateway), PCRF (Policy and Charging Rules Function) and HSS. The main control element in LTE is MME, which can support several UE, enb and S-GW. Its main features include identity verification 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 associated 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 highlevel information about IMS emergency emergency call. The general purpose of this thesis is to outline the problem of communication 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 stumbling 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 scrutinizing 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 information. For the purpose of this thesis the solution will be my own experience 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 unnecessary questions, mail-chains and meetings. Because of this expe- 30

4. IMS EMERGENCY SESSIONS rience I gained perspective of what information would help developers to better understand my design without being provided needless information. This chapter is an attempt to provide a high-level white paper particularly focused on IMS emergency calls. As described above, my method of selecting proper information is based on my own working experience. The reason I choose this particular topic also reflects my job experience there is a lack of comprehensive high-level information 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: Creating 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 Cellular 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 emergency 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 information 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

4. IMS EMERGENCY SESSIONS 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 vehicle, 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 service 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. IMS EMERGENCY SESSIONS 4.3 Emergency calls - General Introduction Emergency services are independent from the IP-CAN with regard to the detection and routing of emergency sessions. The emergency 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 nonemergency 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 before 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 emergency 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 emergency session in the SIP signaling. URI permitted to resolve the emergency 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 possible for the users with a barred public user identity. Emergency session establishment is based on ability of an UE to detect an emergency session by evaluating the SIP URI or a dialed emergency number. It is expected that an UE has sufficient credentials to authenticate with the IMS network and is already registered 33

4. IMS EMERGENCY SESSIONS Figure 4.1: Overal Emergency Architecture 34

4. IMS EMERGENCY SESSIONS 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 association between the UE and the P-CSCF. Therefore, in case the UE does not reach the necessary requirements, the IMS can support authentication 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 functions: 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 unauthenticated 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 information 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 behaviour of emergency-related IMS components whose functionalities and behaviour during emergency sessions differs from the standard situations. 35

4. IMS EMERGENCY SESSIONS 4.4.1 User Equipment If the UE Detects a request for establishing an emergency session, it initiates a request in which the location information 1 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 registered in IMS. In this case the UE is supposed to request an emergency registration first. If registered in IMS, no emergency registration is required and the session can be established immediately. During emergency session initiation, an UE must include in the request its own identifier in case the caller does not have sufficient IMS registration credentials. The UE must be able to process a 380 SIP response (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 person 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 indicated 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 network 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

4. IMS EMERGENCY SESSIONS 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 forwards 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 nonemergency 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 process. It serves for retrieving geographical location information form the LRF in case the location info is not included in the emergency request. 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 information 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 location 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 emergency session was not received via a security associations for a UE previously authenticated with digest type proxy authentication. 5. For instance the type of emergency service. 37

4. IMS EMERGENCY SESSIONS 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 location information of an User Equipment which initiated the emergency 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 regulations or operator s policy. 6 The information provided by the LRF to the Emergency-CSCF includes correlation information identifying both the LRF and the emergency session record in the LRF. This correlation information is distributed to the PSAP when establishing a session (typically in a SIP INVITE). 4.4.5 Serving-CSCF The Serving CSCF handles emergency registration requests received 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 (corresponding to local or operator s policy) from HSS in case the user is not normally registered (meaning there is a standard IMS registration 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

4. IMS EMERGENCY SESSIONS Figure 4.2: IMS Emergency session establishing. 39

4. IMS EMERGENCY SESSIONS 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 subscriber, 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 specified in TS 23.237. 4.4.7 Interrogation-CSCF I-CSCF supports IMS emergency session continuity, which is specified 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. 4. IMS EMERGENCY SESSIONS 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 apply 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 emergency 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 registration. 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

4. IMS EMERGENCY SESSIONS 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 emergency 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 recognizing 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 explicit emergency indication into the request and forward the request 42

4. IMS EMERGENCY SESSIONS Figure 4.3: Emergency service requests procedures 43

4. IMS EMERGENCY SESSIONS 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 initiation 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 accepts 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. IMS EMERGENCY SESSIONS 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" procedure, P-CSCFs outside the home network must always reject such request (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 registration. Normally the P-CSCF accepts such request, but it is possible 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 authentication is optional). A special default emergency APN (Access Point Name) must be stored in MME (defining for example QoS parameters 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 request (with TYPE set to Emergency ) to MME. The MME can ask HSS for authentication if required. After receiving an emergency attach, 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

4. IMS EMERGENCY SESSIONS Figure 4.4: LTE emergency session establishing 46

4. IMS EMERGENCY SESSIONS 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 understand the principles of IMS. In the second part of my thesis I had to deeply scrutinize 3GPP documentation 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 examine a large amount of documentation. To abstract the most important emergency processes, I have also created 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 understand the principles behind their programming. This thesis is intended 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 defined in 3GPP but not fully implemented yet. As a next step in solving the problem of communication and the lack of general understanding 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. SUMMARY 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 encyclopedia. [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 examples. [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 sessions, 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ÍČEK, M. Ip multimedia subsystem. Master s thesis, Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2008. [12] BETLACH, M. Ip multimedia subsystem a jeho využití pro zajištění kvality služeb. Master s thesis, Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, Brno, 2008. 50

5. SUMMARY [13] BOŽEK, M. Open ims core a ip multimedia subsystem. Master s thesis, Brno: Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2011. [14] CAMARILLO, G. The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds. Willey, 2008. [15] DORNAL, S. Ims emergency calls over lte. [online]http://wired-n-wireless.blogspot.co.at/ 2012/04/ims-emergency-calls-over-lte-short. htmlaccessed:2014-05-18. [16] ERIK DAHLMAN, STEFAN PARKVALL, J. S. 4G: LTE/LTE- Advanced for Mobile Broadband, 1 ed. Academic Press, 2011. [17] GROUP, N. W. Rfc: 3665. session initiation protocol (sip) basic call flow examples. [online] https://tools.ietf.org/ html/rfc3665, 2003. [18] HEINE, G. GPRS: Gateway to Third Generation Mobile Networks, 1 ed. Artech House, 2003. [19] JEANTTI, J. IMS version 9 implementation guide. A technical overview, 1 ed. San Jose, CA: IBM, International Technical Support Organization, 2004. [20] JOHNSON, C. Long Term Evolution in Bullets, 2 ed. CreateSpace Independent Publishing Platform, 2012. [21] JOHNSTON, A. SIP: Understanding the Session Initiation Protocol. Artech House, 2009. [22] MATYÁŠ, J. Možnosti potenciálu nově dostupných služeb v sítích long term evolution. Master s thesis, Univerzita Tomáše Bati ve Zlíně, Fakulta aplikované informatiky, 2010. [23] MOULY, M. The GSM System for Mobile Communications. Telecom Publishing, 1992. [24] NAVRÁTIL, P. Modely systému lte. Master s thesis, Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií, 2013. 51

5. SUMMARY [25] NOLDUS, R. IMS Application Developer s Handbook: Creating and Deploying Innovative IMS Applications. Academic Press, 2011. [26] OPRŠALOVÁ, S. Mobile commerce - porovnání situace v Čr a v zahraničí. Master s thesis, Masarykova univerzita Brno, Ekonomicko-správní fakulta, Katedra podnikového hospodářství, 2007. [27] ORACLE. 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 Services. 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] VELICKÝ, T. Datové přenosy po gsm sísítí, technologie hscsd, gprs a umts. Master s thesis, Jihočeská Univerzita, Pedagogická fakulta, Katedra informatiky, 2002. [31] VONDRA, T. Měření propustnosti voip sítí. Master s thesis, České vysoké učení technické v Praze, Fakulta elektrotechnická, Katedra počítačů, 2011. [32] WALKE, B. UMTS: The Fundamentals. Wiley, 2003. 52