Network Working Group J. Ottensmeyer Internet-Draft Siemens AG Expires: September 1, 2003 March 3, 2003 Emergency Services provided in Public Switched Telephone Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the set of emergency call services that are provided in Public Switched Telephone Networks (PSTN) today and will be in the near future. It discusses related features which are needed to provide these services. Ottensmeyer Expires September 1, 2003 [Page 1] Internet-Draft PSTN Emergency Features March 2003 1. Introduction Emergency Preparedness is an important factor for public communication networks. The IEPREP WG is currently gathering the pieces available in the Internet today into BCPs to document the required emergency services. Public Switched Telephone Networks (PSTN) have features which enable to provide several types of emergency services. And PSTN is still evolving: e.g. based on E.106 [1], a new scheme for International emergency support, methods are now being implemented in SS7 and BICC signaling to convey a calling party category on an international basis. This allows authorized users to have access to the International Telephone Service while the service is restricted due to damage, congestion and/or other faults. This document surveys the set of emergency services and related features available in PSTN today and planned for the near future. Hence, it is aimed as input to the discussion in the IEPREP working group. Ottensmeyer Expires September 1, 2003 [Page 2] Internet-Draft PSTN Emergency Features March 2003 2. Emergency Call Services available in PSTN today There are three main emergency services available. These are SOS calls, origin-dependent calls and user-dependent calls. In the following, we give an informal description of these services rather than a formal definition. 2.1 SOS Calls (911,...) The "SOS call" is the classical emergency call service (e.g. 911, or 112 in Europe). It is a "destination-dependent call service", i.e. calls are authorized by dialing a publicly, well-known emergency number(s), e.g. of the fire brigade, police, or ambulance, etc. SOS calls are routed to the nearest emergency center. Nearest is relative to the geographical location of the subscriber, which is held in the database of the local exchange. The selection of the region specific servicing center is done in the local exchange by mapping the dialed number to the routable number of this center. Emergency calls are available in all states of the networks. They can be placed from any subscriber line, even if the subscriber has a service restriction in the outgoing direction, the subscriber has selected an individual barring of outgoing calls, the credit limit of the subscriber is reached or the account of the subscriber is suspended. Emergency calls belong to the class of non-blockable calls. When it takes some time until the emergency caller gets connected with the emergency center, an announcement can be played to inform the caller that the emergency call is being processed and he should hold the line. Finally, emergency calls are non-chargeable calls. This means there need to be provisions to allow placing emergency calls from coinbox telephones without depositing coins. 2.2 Origin-dependent emergency calls The "origin-dependent call service" is used to realize emergency calls from special phones, for example calls from a police office or a fire brigade center. Authorization to use this service is granted by checking the properties of the subscriber line from which the call is originated. These properties are included in a subscriber database at the local exchange. This call service may be used during disaster recovery operations, so that these calls must be placed under all network circumstances. The call service is realized by associating a call preference with this call, which allows a preferred routing of the call throughout the Ottensmeyer Expires September 1, 2003 [Page 3] Internet-Draft PSTN Emergency Features March 2003 network. Such calls might even preempt other calls, if the called party is currently carrying out another, non-emergency call. 2.3 User-dependent or authenticated emergency calls The "user-dependent call service" is used to realize emergency calls from specially authorized users, for example calls from polices officers or fire fighters. Such call may originate form any terminal in the public communication network. Thus, users must dial a special access and authentication codes to gain access to the service. An example for a national implementation of this call service in US is GETS (the Government Emergency Telephony Service) [2]. The international version is called International Emergency Preparedness Scheme [1]. This calls must be placed under all network conditions. This call service is realized by associating a call preference with this call. This allows a preferred routing of the call throughout the network. Such calls might even preempt other calls, if the called party is currently carrying out another, non-emergency call. Ottensmeyer Expires September 1, 2003 [Page 4] Internet-Draft PSTN Emergency Features March 2003 3. Features needed to realize Emergency Call Services This section lists the features required to realize the emergency call services as described before. This includes features to enable the services itself and features to fight congestion. Several features are available at all time while others are activated during exceptional network states. Under normal operation of the network, the core idea is to enable and route these calls, even if system configuration would prevent other (normal) calls (e.g. if the subscriber account is suspended due to overdue credit limit). In case of unexpected disaster situations, such as earthquakes, storms, big fires and other types of catastrophes, networks can be immensely affected or even damaged. The idea here is to fight overload and prioritize emergency calls. The first subsection covers system-based features. The second subsection describes several other (hardware) features which are used to increase availability of the emergency call services in the case of various network failures. 3.1 System-based features o "Digit translation on the dialed number" means that the dialed number may be replaced by a new code and call preferences are added or altered. This is applied to convert a uniform emergency call number (e.g. 911) to the region specific servicing center number. o "Subscriber emergency override" means that it is possible, to override subscriber service restrictions for specific dialed numbers (e.g. emergency numbers). Thus subscribers with outgoing call restrictions can still place emergency calls. o "Disable Calling Line Identification Restriction". Originating subscribers may hide the presentation of the calling line identification on the called party's terminal. For emergency calls, it is possible to define categories for terminating subscribers (e.g. the emergency centers) to get the ability to override the presentation restriction and have the calling party's identity presented. o "Preference category during catastrophe" means that the local exchanges will impose service restrictions when a catastrophe state is activated. Then, call admission is based on the following criteria: Ottensmeyer Expires September 1, 2003 [Page 5] Internet-Draft PSTN Emergency Features March 2003 * the destination of the call. Call are classified as "regular calls" and "emergency calls" (e.g. 911 calls). * the source of the call. All subscriber lines are administratively assigned a preference category (which are held within the local exchange). There are several possible levels. Normal subscribers get preference category 0 while e.g. the "red phone of the president" gets the highest category. * the identity of the caller. By means of a specific service, the identity of the caller is verified and if eligible, the preference category of the subscriber line is increased (for the call to be placed). * the active level of service restriction in the local exchange. The administration can activate different levels of service restrictions in the local exchange; these are for example: + Level 0: Normal Operation of the Local Exchange + Level 1: Only subscribers with preference category 1 or 2 are permitted to originate calls. Subscribers without preference can place emergency calls. The terminating traffic is not restricted. + Level 2: Only subscribers with preference category 2 are permitted to originate calls. Emergency calls are accepted only if the calling subscriber has a preference category greater than zero. The terminating traffic is not restricted. o "Priority Routing" means preferential treatment to calls originating from certain subscribers and their dial preferences in order to receive special path selection. o "Automatic Repeat Attempt" means that in case of congestion, repeated set-up attempts can be made on the last-choice route for priority subscribers or emergency traffic. The feature requires that the signaling system transmits the calling category information. o "Last trunk reserved for special traffic" means that the last idle trunk within a trunk group can be reserved for special traffic, e.g. origin-dependent (priority calling category) or destination-dependent (e.g. emergency) traffic. o "Authentication and authorization" means that a caller is Ottensmeyer Expires September 1, 2003 [Page 6] Internet-Draft PSTN Emergency Features March 2003 authenticated (e.g. via an account number and a PIN) and is then authorized to receive a special service (e.g. a higher preference category). This is typically done in special service offices reached through a dialed access code (e.g. for GETS). o "Call release" means that - depending on the actual configuration - ordinary calls may be released (pre-empted) when an emergency call can not be placed due to lack of resources. o "Hard-to-Reach Control (HTRC)" is a kind of congestion control which fights overloads resulting from catastrophes. In these cases, communication from outside with subscribers inside the catastrophe area is almost impossible. The number of call attempts to reach the affected area increase rapidly and the network is severely overloaded. Many call attempts fail because the called destination is congested. Additionally, calls to other areas (not affected by the catastrophe) cannot be successfully routed to their destinations due to the propagated congestion; hence the telecommunication companies are not able to provide their service effectively. Therefore, the networks run a Hard-to-Reach Control (HTRC). HTRC is based on the following functions: 1. Automatic determination of HTR destinations 2. Automatic reduction of HTR traffic through network management controls (e.g. by means of trunk reservation) 3. Administration of destinations to be automatically detected, to be excluded from HTR determination, to be excluded from HTR reduction or even to be marked as HTR in order to benefit from HTR traffic reduction through network management controls. 3.2 Hardware-based features There are several features to increase the availability of emergency call services in case of network or other hardware failures. Those are for example: o "Provision of backup lines for emergency calls". If a remote part of the local exchange is in stand alone service (which means, all PCM-links from the remote part to the local exchange are out of service), calls to emergency numbers can be routed to subscriber ports, which are defined as emergency call ports. These emergency call ports can be connected via suitable transmission equipment to an emergency center. Ottensmeyer Expires September 1, 2003 [Page 7] Internet-Draft PSTN Emergency Features March 2003 o "Power Supply of User Terminals". The interface S0 (between customer premise equipment and the local exchange) for analog and ISDN lines include power supply of the terminal equipment in normal and emergency operation. This means that appropriate terminals can be operated even without external power supply. o "Power Supply for Network Elements". Typically, regional regulators demand 48 hours of operation without external power supply. Therefore, reliable battery backup and/or fuel based generators are provided for exchanges, transmission equipment and other essential elements. Ottensmeyer Expires September 1, 2003 [Page 8] Internet-Draft PSTN Emergency Features March 2003 4. Denial of Service Protection PSTN provides denial of service protection through statistical and other means. Thereby individual channels are supervised. There are two major features. o "noisy port supervision" provides supervision of the subscriber line by comparing the actual usage pattern against the dialing characteristics of well-behaved subscribers. This feature detects attacks or malfunctions if the subscriber requests more than a certain number of incomplete, short, or faulty calls on that line in a given period of time. o "killer trunk supervision" works the same way as noisy port supervision, it just compares against the dialing characteristics on trunk lines. Ottensmeyer Expires September 1, 2003 [Page 9] Internet-Draft PSTN Emergency Features March 2003 5. PSTN Emergency Call Services and Features In this section we give a brief listing which features are needed to provide which emergency services. The aim is to make clear that not all features are needed for each service. Service "Emergency "origin-dependent "user-dependent/ call" emergency call service" authenticated call emergency service" Feature - digit translation on x x x dialed number/ address replacement - subscriber emergency x override - preference category x x x during catastrophe - Disable calling line x identification restriction - priority x x x - automatic repeat x x attempt - last trunk reserved for x x x special traffic - call release x x x - authentication and x authorization Table 1: Mapping of Features and Emergency Services Ottensmeyer Expires September 1, 2003 [Page 10] Internet-Draft PSTN Emergency Features March 2003 6. Emergency Call Services under development for the PSTN One essential information for the Emergency Center is the spatial location of the emergency caller. The operators of fixed networks regularly provide updates of their customer data (telefon number and address) to the emergency centers. Using this information, the emergency centers can determine the location for incoming emergency calls. Unfortunately, this model is inherently impossible for mobile networks. Moreover, there are other proprietary mechanisms in place in some countries. Therefore, Standardization Bodies like ETSI [3] and ANSI are developing an interface to provide the spatial information about the caller to the emergency center. This service is called "Enhanced 112 calls". For the purpose of providing a single mechanism to the Emergency Centers, Enhanced 112 calls (E112) will be used in both, fixed and mobile networks. The interface between the network operator and the Emergency Center will be based on the Mobile Location Protocol (MLP) of the LIF (Location Interoperability Forum). There are two models under discussion for the interface: a pull and a pull model. The pull model allows the Emergency Center to retrieve the spatial location of the caller from the network operator. Using the push model, the network operators provides the spatial location information together with the emergency call to the emergency center. Ottensmeyer Expires September 1, 2003 [Page 11] Internet-Draft PSTN Emergency Features March 2003 7. Conclusions PSTN systems offer features to aid all kind of catastrophe and emergency state. This ranges from prioritization of personal emergency calls under normal network operation up to blocking of other than emergency calls during catastrophe state. Additionally, parts of the network are protected from congestion by automatic detection of hard-to-reach catastrophe areas. Thus, originating calls from different areas can still reach emergency centers within this catastrophe area. This paper summarizes a set of services that may find their way into the requirement sheets of the IEPREP working group. Of course, not all of these services may be applicable in the Internet, but further discussion is needed to select an appropriate subset of the above described features. Ottensmeyer Expires September 1, 2003 [Page 12] Internet-Draft PSTN Emergency Features March 2003 8. Security Considerations This draft is on security. Specific requirements to other security functions may be derived if further considered. Ottensmeyer Expires September 1, 2003 [Page 13] Internet-Draft PSTN Emergency Features March 2003 9. IANA Considerations Service and feature name spaces may be needed if further considered. Ottensmeyer Expires September 1, 2003 [Page 14] Internet-Draft PSTN Emergency Features March 2003 References [1] ITU-T, "International Emergency Preparedness Scheme", ITU-T E.106, March 2000. [2] Calberg, K., "Framework for Supporting IEPS in IP Telephony", Internet-Draft , January 2003, . [3] Koolen, L., "Regulatory issues for emergency communications in Europe", February 2002, . Author's Address Joerg Ottensmeyer Siemens AG Hofmannstr. 51 Muenchen 81359 Germany Phone: +49 89 722 43239 EMail: joerg.ottensmeyer@siemens.com Ottensmeyer Expires September 1, 2003 [Page 15] Internet-Draft PSTN Emergency Features March 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Ottensmeyer Expires September 1, 2003 [Page 16] Internet-Draft PSTN Emergency Features March 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ottensmeyer Expires September 1, 2003 [Page 17]