Emergency Calls Handling in IP Multimedia Subsystem Network

Transcription

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý Emergency Calls Handling in IP Multimedia Subsystem Network MASTER THESIS Martin Tomeš Brno, 2014

2 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

3 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

4 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

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

6 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

7 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

8 Contents 1 Introduction IMS Architecture History IMS Components IMS Layers Device Layer Transport Layer Control Layer Service Layer IMS Core Components Proxy Call Session Control Function (P-CSCF) Serving Call Session Control Function (S-CSCF) Interrogating Call Session Control Function (I- CSCF) Emergency Call Session Control Function (E- CSCF) Home Subscriber Server (HSS) Signaling SIP Architecture User Agents Servers SIP Messagging Message Header SIP Requests SIP Responses SDP Protocol Supported Mobile Technologies in IMS GSM (2G) GPRS (2,5G) UMTS (3G) LTE IMS Emergency Sessions State of the Arts History of Changes in 3GPP Standard Emergency calls - General Introduction

9 4.4 IMS Emergency Architecture User Equipment Proxy-CSCF Emergency CSCF Location Retrieval Function Serving-CSCF Emergency Access Transfer Function (EATF) Interrogation-CSCF Application Server HSS Establishing of IMS Emergency Session IMS Emergency Registration Emergency Service Request Non UE detectable emergency service request Emergency service request without registration Emergency service request with normal registration Emergency service request with emergency registration Emergency session in LTE Summary

10 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

11 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

12 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 LTE no 5

13 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

14 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] 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

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

16 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] 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] 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

17 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] Service Layer The service layer is where all of the services are operated. This includes voice services (for instance voic , 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 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

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

19 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 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 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

20 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] 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

21 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 address, except that the method is not mailto: but sip: or sips: in case of secure connection. For instance: 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: 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

22 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 SIP Architecture 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] 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

23 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 SIP Messagging 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

24 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 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: @atlanta.example.com CSeq: 1 INVITE Contact: <sip:alice@starfleet.gov;transport=tcp> Content-Type: application/sdp Content-Length: 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

25 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] 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