Draft ETSI DES 01019 V0.2.1 (2004-09) Requirements of the NGN network to support the emergency service for communication from citizen to authority; ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N° 348 623 562 00017 - NAF 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http://portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. (c) European Telecommunications Standards Institute yyyy. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTM and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. Contents Intellectual Property Rights 4 Foreword 4 Introduction 4 1 Scope 5 2 References 5 Numbered reference format 5 Unnumbered reference format 5 3 Definitions, symbols and abbreviations 6 3.1 Definitions 6 Definition format 6 3.2 Symbols 6 Symbol format 6 3.3 Abbreviations 6 Abbreviation format 6 4 Emergency Sessions Requirements 7 4.1 General Requirements 7 4.1.1 Identification of emergency numbers 8 4.1.2 Location information derivation and handling. 8 4.1.3 Domains priority and selection for NGN Terminal attempts to emergency call 8 4.2 Requirements for an PSTN/ISDN Emulation Subsystem and Simulation services in the IMS providing Emergency calls 9 4.3 Requirements for an IMS Subsystem Emergency Sessions 9 4.4 Emergency Calls in the PS CN Domain 10 4.5 Emergency Calls when Attached via an I-WLAN 10 4.6 Architecture requirements 10 4.7 Protocol & Security requirements 10 Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This ETSI Standard (ES) has been produced by ETSI Technical Committee TISPAN WG1 NGN services, and is now submitted for the ETSI standards Membership Approval Procedure. 1 Scope The present document contains the requirements of a NGN to support emergency communications (EMTEL) from the citizen to the authority. The requirements are independent of the NGN subsystem and transport layer unless specifically referred to. 2 References [1] Directive 2002/21/EC on a common regulatory framework for electronic communications and services (the "Framework Directive"), and in particular Article 19 [2] Directive 2002/22/EC on universal service and users rights relating to electronic communications networks and services (the "Universal Service Directive") [3] Directive 2002/58/EC on a concerning the processing of personal data and the protection of privacy in the electronic communications sector (the "Directive on privacy and electronic communications") [4] SR 002 180 ETSI Special Report: EMTEL Requirements for communication of citizens with authorities/organizations in case of distress (emergency call handling) [5] TS 24.008 Digital cellular telecommunications system (Phase2+); Universal Mobile Telecommunicatios System (UMTS); Mobile radio interface Layer 3 specification; Core network protocols; [TR 23 867] 3GPP TR 23 867: " Internet Protocol (IP) based IP Multimedia Subsystem (IMS) emergency sessions; Release 7". 3 Definitions, symbols and abbreviations 3.1 Definitions 3.3 Abbreviations 3GPP 3rd Generation Partnership Project CLI Calling Line Identity DHCP Dynamic Host Configuration Protocol ECC Emergency Control Centre F-MMS Fixed line Multimedia Messaging Service IMS IP Multimedia Subsystem IP Internet Protocol ISDN Intergrated Services Digital Network ISIM IM Services Identity Module MMI Man Machine Interface NGN Next Generation Network PSAP Public Safety Answering Point PSTN Public Switch Telephone Network SDP Session Description Protocol SIP Session Initiated Protocol URI Uniform Resource Identifier VoIP Voice over IP VPN Virtual Private Network 4 Emergency Sessions Requirements The following is a list of very high level requirements for an emergency call/session between a user and the PSAP/ECC when an 112 type service is requested. * Provide a voice link, maintained throughout the call * Receive immediate priority treatment over other calls * Must not be subject to restrictive network management practices * Must be subject to normal call records, charging and accounting (even though the call is free) * Must provide a unique ID to enable a callback (eg CLI) and Network Operator ID * Originating geographic location must be automatically provided to determine - correct PSAP operator to route the call to - appropriate local emergency service centre - location to accurately despatch assistance. * Location information must be automatically available at the PSAP centre * Must be migrated to multi-party calls under the control of the PSAP operator * Shall be subject to "last party clear", or other method for handling false calls * Shall be restored with priority over normal calls. * Need IP and PSTN Emergency Call Centre solution 4.1 General Requirements It shall be possible to establish a session for an emergency speech call. These Emergency calls shall be routed to the emergency services in accordance with the national regulations of where the caller is located which may require that these calls receive a higher level of priority than a normal communication.. An emergency call may be allowed to be establish without the need to 'dial' a dedicated number to avoid a mis-connection in the nomadic case, e.g. the use of entities such as menu, by use of a 'red button' may be deployed. Emergency Calls may be supported without a dedicated authentication device or procedure being present for this session. Note: It will be left to the national authorities to decide whether the network should accept emergency calls without the dedicated authentication device or procedure being present for this session. It may be possible to initiate emergency calls to different emergency call centres, depending on the type of emergency. The following types of emergency calls shall be possible: - Police - Ambulance - Fire Brigade - Marine Guard - Mountain Rescue - Common emergency answering point - Spare, at least [three] different types The Man Machine Interface (MMI) on specific NGN Terminal may be specified by the regulatory authority in which the customer's service contract is agreed. This interface is then stored on this NGN Terminal and this shall be deployed whenever an emergency call/session is attempted. It maybe possible to tie any emergency call number, specified in the preferred emergency call MMI(s) above, to any single emergency call type or to any combination of emergency types. The association between emergency numbers and emergency call type maybe able to be programmed on the NGN Terminal by the regulatory authority where the customer's service contract is agreed. Considering the "Directive 2002/21/EC on a common regulatory framework for electronic communications and services (the "Framework Directive"), and in particular Article 19". European Law [1] requires that 112 Emergency Voice services are available across the European Union, It is noted that in some countries (e.g. Germany) this code does not translate to the Police, where as in other counties (e.g. Italy) this is always delivered to the Police who include other Emergency services. In other countries 112 is delivered to a PSAP that offer a number of services. Example: 19 Police (Albania) 100 Police and Fire Brigade (Greek cities) 100 Ambulance and Fire Brigade (Belgium) 110 Police (Germany) 112 Police and Ambulance (Italy) 112 General emergency call, all categories (Sweden) 115 Fire Brigade (Italy) 114 Ambulance (Austria) 911 Emergency Voice Access (North America) 999 Emergency Voice Service (UK/Eire) Note: if the NGN Terminal does not recognise the emergency call number but the serving network recognises the dialled number as an emergency call number used in the country. Then a normal call set up takes place and after the serving network has recognised the emergency number the call is routed as an emergency call. A user friendly MMI that specifies the type of emergency directly (e.g. via a menu) may be supported for use in any (i.e. home or visited) network to avoid the miss-connection in the nomadic case. This shall be allowed both with and without authentication procedures taken place. The serving network may download additional emergency numbers to the NGN Terminal in order to ensure that local emergency numbers are known to the NGN Terminal. The NGN Terminal shall regard these emergency numbers as valid in that country only and shall discard them when a new country is entered. 4.1.1 Identification of emergency numbers To handle nomadicity, the NGN Terminal shall be able to place calls on a locally supported Emergency number, it should be able store Emergency numbers, and in the case of a SIP Terminal, to store Emergency SIP URIs. When an Emergency call or session is required, the correct Number/URI is presented to the network on the basis of national knowledge and information made available at the Access to the network. In Europe, this shall be 112, and optionally a national possibly service specific number.) Additional the NGN Terminal may store emergency numbers that may have been downloaded by the serving network. 4.1.2 Location information derivation and handling. The location information shall [2] be derived from the known information available in the network, to the extent technically feasible. Upon initiating the emergency session any location information shall be sent with the set-up of the session. If all location information is not available at the time of the set-up of the emergency session then what is available is sent and the network may use other positioning means to obtain other location information This location information shall be identified as its to the origin, such that all the NGN Terminal derived location information is indicated to the emergency authority. The NGN Terminal provided Location Information is indicated such that the origin of the information can be verified. The location information shall be stored until the emergency authority no longer requires it. This location information is sent to appropriate emergency authority upon a request from this authority. The location information shall be treated as private information [3] and as such it is subject to the privacy regulation of data as specified by the regulatory authority where the session is initiated. This may include any authorisation and security procedures and obligations of the customer, NGN Terminal and emergency authority. 4.1.3 Domains priority and selection for NGN Terminal attempts to emergency call A PSTN/ISDN emulation subsystem and IMS subsystem capable NGN Terminal attempting an emergency call shall give priority to the PSTN/ISDN emulation subsystem domain. In case where the call attempt in the PSTN/ISDN emulation subsystem domain fails, the NGN Terminal should automatically make a second attempt in the IMS subsystem domain, where the NGN Terminal is facilitated and attached to both domains. In the case where the NGN Terminal cannot support the IMS subsystem capabilities but is able to support the PSTN/ISDN emulation subsystem and the emergency call attempt in this domain fails the call is rejected and an indication to try again given to the caller. 4.2 Requirements for an PSTN/ISDN Emulation Subsystem and Simulation services in the IMS providing Emergency calls A PSTN/ISDN emulation subsystem and simulation services in the IMS shall support the emergency communication service as defined in SR 002 180 [4]. This clause deals with Emergency Voice services as mandated [1] hence the PSAP/ECC is assumed to be either in the PSTN/ISDN network or at least inter-worked to by a Media and boarder gateways. 4.3 Requirements for an IMS Subsystem Emergency Sessions This clause deals with Evolutionary services where Emergency sessions are established from a SIP Enabled terminal to a SIP enabled Emergency Control Centre, via a SIP enabled PSAP. Where the SIP enabled PSAP is viewed as a SIP Application Server in the IMS; the PSAP may select the appropriate ECC on the bases on the service requested in the Session Request (e.g. the SDP payload in the SIP INVITE). Where the PSAP is an enhanced termination Similar-forwarding capabilities may be provided before any optimally routed streaming media is established. The solution for emergency sessions in the IMS subsystem shall fulfil the following capability requirements: 1. It should be independent from the underlying IP connectivity network in respect to the detection and routing of emergency sessions. 2. All emergency contact identifiers, (e.g. emergency numbers, SIP emergency URIs) and any special indications for emergency sessions within the SIP signalling must be supported specifically IETF proposals on addressing should be taken into consideration. 3. Emergency sessions should have priority access to resources, when the network resources are under load, over "ordinary" sessions by the network. 4. Set-up of IMS emergency sessions shall be possible for users with a barred public user identity. 5. The primary solution shall be that the NGN Terminal will detect an initiation of an emergency session (e.g. by evaluating the SIP-URI or the dialled number) by itself and then indicates the emergency session to the network. However the NGN shall also support the scenario where the NGN Terminal cannot detect an initiation of an emergency session, then the NGN shall be able to detect and indicate an emergency session in progress. 6. The NGN must be able to support the scenario where the authorisation of the NGN Terminal to the network is accomplished with the aid of an ISIM module. In this case the NGN shall be able to set-up an emergency session if this identification module is not present. 7. An Emergency Service shall not be a subscription service and will therefore be supported in a visited network and provided without interaction with a "Home" network for the nomadic case. 8. For the nomadicity scenario where an emergency session request is routed via the home network, the home network shall be able to detect that the session is for emergency service (whether indicated or not) and respond to the NGN Terminal indicating that the NGN Terminal should initiate an emergency session in the visited network. Alternatively the visited network may be able to detect that the session request is for an emergency session (whether indicated or not)and route to session to the appropriate PSAP/ECC. 9. The Location of the caller to the session establishment shall be supported according to clause 4.1.2 above in accordance with the EU Directives [2] and [3]. 10. PSAPs/Emergency control centres shall be connected to the PSTN/ISDN emulation domain, however the emergency centre may also be connected to the IMS domain or any other packet network. 11. PSAPs/Emergency control centres shall be able to call back the user, if a CLI is provided or ISIM is used to authenticate the user. In the ISIM-less Simulation Case this may not be possible. 12. The visited network shall be able to download emergency numbers to the NGN Terminal using procedures as described in TS 24.008 [5], in order to ensure that local emergency numbers are known to the NGN Terminal. 4.4 Emergency Calls in the PS CN Domain Without the IM CN subsystem, emergency calls are not supported in the PS CN domain. 4.5 Emergency Calls when Attached via an I-WLAN Any attempt to make an emergency call shall be handled as defined for a PS CN domain network in clause 4.4 above. 4.6 Architecture requirements The solution for emergency sessions shall also fulfil the following architectural requirements: 1. The architecture for Emergency Service should be driven by the specific capabilities requirements. Specification should minimise the changes to existing 3GPP IMS architecture and procedures, and re-use existing 3GPP IMS functional entities. However the specification should not be constrained by the existing functional entities. 2. The architecture should take into account that it may be possible to make emergency calls on other media than voice. It needs to take account support, for example, the deaf and hearing-impaired using a text phone that might generate information, for example, using procedures for Multimedia services or the 3GPP Instant Messaging Service based on the 3GPP IMS or the F-MMS messaging procedures. There may also be a need to work with phones that attempt the emergency call as a video telephony call. 3. The architecture should support the evolution of PSAPs/Emergency Control Centres from terminating access to the PSTN/ISDN, to direct inter-working via Media and boarder gateways, to the case where they are part of the SIP infrastructure. Allowing the case that not all PSAPs/ECC will migrate at the same time. Legacy ECC with Enhanced ISDN access only may persist for some time. 4. Service Inter-working is an important consideration if a SIP aware terminal places a multimedia, MMS or Instant message Emergency session to an PSAP/ECC that only supports ISDN voice. Rejection or fallback considerations will be serious. . 4.7 Protocol & Security requirements The following issues have been identified as requirements that need a solution for the support of VoIP Technology. It has been identified that the following possible limitations for the support of Emergency Voice Services (e.g. E112 and SOS SIP URIs must be alleviated. These issues include: * Reliability of location information * Authentication of caller id and location stored in a NGN Terminal * Monitor and validate (1) terminal syntatical behavoiur (2) and network behabiour on denial of service attacks and mitigate against the effects of aforementioned behaviour. * VPN access problem: o Globally accessible routing o Secure routing globally * Enterprise DHCP server for location information (private) * Residential DHCP issues * Overhead of organisations that provide access to public Emergency Voice Services (e.g. E112) * Global/international regulation * PSAP reconnect capability