ecrit B. Rosen Internet-Draft Emergicom Expires: August 19, 2005 N. Abbott Telcordia February 15, 2005 NENA Requirements for Emergency Call processing draft-rosen-nena-ecrit-requirements-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 August 19, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The National Emergency Number Association (NENA)'s mission is to foster the technological advancement, availability, and implementation of a universal emergency telephone number system in North America. NENA has an active effort to develop a new architecture for emergency call handling known as "i3" being Rosen & Abbott Expires August 19, 2005 [Page 1] Internet-Draft NENA Requirements February 2005 developed in its Long Term Definition working group. The following requirements are a subset of the requirements of the i3 work which relate to ecrit work. NENA understands the global nature of the Internet, and is eager to work with the IETF to ensure that emergency call processing meets the needs of users in North America. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Background on the North American 9-1-1 System . . . . . . . . 4 3. Functional Requirements . . . . . . . . . . . . . . . . . . . 7 3.1 Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Location . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Call Back Address . . . . . . . . . . . . . . . . . . . . 8 3.4 Additional Information . . . . . . . . . . . . . . . . . . 8 3.5 Validation of Civic Location . . . . . . . . . . . . . . . 8 3.6 Routing of Calls . . . . . . . . . . . . . . . . . . . . . 9 3.7 Connections to the Emergency Services Network . . . . . . 11 3.8 Other . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Rosen & Abbott Expires August 19, 2005 [Page 2] Internet-Draft NENA Requirements February 2005 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Rosen & Abbott Expires August 19, 2005 [Page 3] Internet-Draft NENA Requirements February 2005 2. Background on the North American 9-1-1 System The universal emergency number in nearly all of North America is 9-1-1. Wireless or wireline callers to 9-1-1 are are routed by the phone system to one of approximately 6,134 Public Safety Answering Points (PSAPs), which are agencies of local government. In North America, there was a very large effort to build what is called the "Enhanced 9-1-1" or E911 system which endeavors to inform the call taker of the location (address) of the caller automatically. Location based routing of emergency calls is handled by a special purpose tandem switch known as a Selective Router (SR). There are several hundred Selective Routers in North America. PSAPs are connected by dedicated trunks to an SR. The SR has a database that is indexed by a key provided in the signaling to determine which PSAP should recieve the call. For wireline callers, the key is the ANI (Automatic Number Identification), typically the calling party number. For wireline callers, the key may be a dynamically assigned number associated with the call. Automatic delivery of location information to the PSAP is accomplished using a database known as the ALI (Automatic Location Identification) which is also indexed by the ANI (for wireline callers) or by the dynamically assigned key for wireless callers. The ALI and contains the location associated with the telephone number of the caller (or determined by the dynamic key for wireless callers). A query to the ALI is made by the PSAP as it answers the call, and the location is displayed to the call taker. To ensure that the location information entered into the ALI conforms to the civic address space known to the PSAP, there is another database called the "Master Street Address Guide" which contains a listing of all known streets and the known address ranges within those streets. When moves adds or changes are ordered for telephone services, the carriers process service orders for entry into the ALI. Before changes are made, the address information is validated by comparing it to the MSAG. If the address matches an entry in the MSAG, it is considered a valid address, and entered into the ALI. Each PSAP has a service area, which do not overlap. Nearly all of North America is served by a PSAP, although there remain isolated areas which do not have 9-1-1 service and must rely on direct calls to police, fire or emergency medical services. The boundaries of the services areas often match the boundaries of political subdivisions such as state, county or municipality, but unfortunately, they do not always have such integral boundaries. For historical, political, and practical reasons, some PSAP boundaries are irregular. In some cases, for example, boundaries are a few townships, several unincorporated areas of a county, and a few streets of another Rosen & Abbott Expires August 19, 2005 [Page 4] Internet-Draft NENA Requirements February 2005 municipality. The boundaries, for civic address purposes, are between specific street addresses. For example, 101 North Main might be served by one PSAP, and 102 North Main may be served by another. As with other areas, sometimes streets are split down the middle, and even numbered houses are in one service area, and odd numbered streets are in another. Although the incidence of irregular boundaries is uncommon, it occurs with sufficient frequency that we must have mechanisms that cope with routing to irregular boundaries. Validation of addresses, in comparison to the current MSAG, is essential for North America. The accuracy of the location is greatly enhanced by verifying that addresses presented to the PSAP during a call are known to the responders - that is, if a responder is dispatched to 101 North Main, there is a very high probability that there is a 101 North Main. Addresses must be validated before they are used. The MSAG, like the ALI, is maintained by a designated local 9-1-1 authority, which sometimes has jurisdiction over several PSAPs. This means that there are actually several MSAGs that cover areas corresponding to one or more PSAP service boundaries. This complicates any proposed mechanisms that would maintain global equivalents of the MSAG because the maintenance of the database must devolve to the service boundaries, which, as has been explained, is irregular. An entry in the MSAG for 101 North Main may be the responsibility of one entity, while the entry that covers 102 North Main may be another entity's responsibility. In North America, there is a complication with civic addresses that arises because the Post Office does not necessarily follow the changes that evolve over time with municipal boundaries. Specifically, the "Community Name" for the post office is not necessarily the actual (legal) community name. This has been the subject of discussion in geopriv, and there is now agreement that both a postal community name and a legal community name should be carried in a location objects. Routing of emergency calls is always on the legal community name. In the North American E9-1-1 System, the Selective Router provides default routing arrangements when the specific location information for the caller is not available; this default routing is generally derived based on the local access area from which the call was originated (as identified by a trunk group). In addition, in the North American E9-1-1 System, the Selective Router supports overload routing arrangements (e.g., to an announcement) in congestion conditions, and contingency routing arrangements when a PSAP is not available to answer emergency calls. Rosen & Abbott Expires August 19, 2005 [Page 5] Internet-Draft NENA Requirements February 2005 These contingency routing arrangements (e.g., to an alternate answering point) can be invoked automatically (e.g., on a scheduled basis) or in real-time for the PSAP by a designated authority(ies). The North American E9-1-1 System also provides for congestion control mechanisms that restrict the number of emergency calls that can be offered to a PSAP at any given time. Rosen & Abbott Expires August 19, 2005 [Page 6] Internet-Draft NENA Requirements February 2005 3. Functional Requirements 3.1 Signaling 3.1-1: Tracking and Tracing Facilities for all calls must be provided. This include all routing entities as well as all signaling entities. 3.1-2: Each element in the signaling and routing paths solution shall maintain call detail records that can be accessed by management systems to develop call statistics in real time. 3.1-3: The emergency call routing system must harmonize with international specifications to permit local determination of emergency call number (i.e. 9-1-1, 1-1-2). 3.1-4: Mechanisms must be provided to route emergency calls in areas not served by E9-1-1 to an appropriate PSTN telephone number. 3.1-5: Each element of the signaling and routing paths shall provide congestion controls. 3.1-6: It shall be possible to determine the complete call chain of a call, including the identity of each signaling element in the path, and the reason it received the call (Call History). 3.1-7: Support must be provided to accept calls from end offices and MSCs via the Public Switched Telephone Network, using SS7, CAMA and ISDN interfaces. 3.1-8: Call setup time (dialing of last digit to alerting at the PSAP), under expected peak load shall be less than 2 seconds. If CAMA signaling is in the path, then an additional ? seconds is permitted. 3.2 Location 3.2-1: Calls using VoIP or subsequent methods are expected to supply location with the call. 3.2-2: PSAPs shall accept location as civic and/or geo specified. 3.2-3: All representations of location shall include the ability to carry altitude. This requirement does not imply altitude is always used or supplied. 3.2-4: The preferred coordinate system for emergency calls is WGS-84. 3.2-5: If multiple Location Objects are provided with a call, it should be possible to identify the most accurate, current, appropriate location information to be used for routing emergency calls and dispatching emergency responders. 3.2-6: No assumption shall be made that the entity presenting the call to the PSAP has any knowledge of, or control over the provider of location. The location provider may be independent of all other service providers handling the call. Rosen & Abbott Expires August 19, 2005 [Page 7] Internet-Draft NENA Requirements February 2005 3.2-7: PSAPs shall have the ability to requery for a location update. 3.2-8: PSAPs shall be able to make use of default location information when measurement based location determination mechanisms fail. Examples include tower/Access Point location, last known fix, etc. 3.2-9: PSAPs must be made aware when default location information was used to route a call. 3.3 Call Back Address 3.3-1: Calls to 9-1-1 shall supply a call back address (URI) with the call 3.4 Additional Information 3.4-1: In addition to information sent with the call, additional information may be available that is retrieved from internal or external databases using a key to the information included with the call. This key may also include information to identify/address the database. 3.4-2: Additional information may be available to the call taker based on the location of the caller. 3.4-3: Additional information may be available to the call taker based on the owner of the structure. 3.4-4: Additional information may be available to the call taker based on the tenant of the structure. 3.4-5: Where a vehicle is involved, additional information may be available. 3.4-6: Additional information may be available based on the Address of Record of the caller. In this context, AoR equates to the caller. 3.4-7: Consideration should be given to permitting users to have domain independent mechanisms to supply information related to the caller, for example, another datum related to user. 3.5 Validation of Civic Location 3.5-1: It must be possible to determine, BEFORE an emergency call is placed, if a civic address is "9-1-1 valid". 3.5-2: A ô9-1-1 Valid Address Databaseö, which contains all valid street addresses within a defined area, should be used as the basis to determine validity of a civic address. 3.5-3: A 9-1-1 valid address is defined as an address with a subset of the fields in the NENA XML address format, which when looked up in the 9-1-1 Address Validation database, yields exactly one record. Rosen & Abbott Expires August 19, 2005 [Page 8] Internet-Draft NENA Requirements February 2005 3.5-4: If it is determined that an address is invalid, an error diagnosis should be supplied if appropriate, as well as a contact URI for resolving errors in the database. 3.5-5: The 9-1-1 Valid Address Database undergoes slow changes. This must be taken into account when validating civic addresses. 3.5-6: The 9-1-1 Valid Address Database defined serving area boundaries may have the same characteristics as routing Req ? and ? below. 3.5-7: Validation information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) must be the only entities permitted to make changes to the database. 3.5-8: The fields in the 9-1-1 Address Validation database must be used as they are defined in the relevant NENA standard, including use of the Street suffix, pre and post directionals, etc. Only USPS abbreviations will be permitted in suffixes. No abbreviations are permitted in street names or community names. All fields must be populated as appropriate, including the postal community name, county name, and zipcode. 3.5-9: PSAPs must have access to the actual (MSAG) community name. 3.5-10: A postal address may be a 9-1-1 valid address if, as stated in requirement ?, a query to the 9-1-1 Address Validation Database with the postal address yields exactly one record. 3.5-11: The PSAP must have access to all of contents of the 9-1-1 address validation database. 3.5-12: The fields in the 9-1-1 Address Validation database must be used as they are defined in the relevant NENA standard, including use of the Street suffix, pre and post directionals, etc. Only USPS abbreviations will be permitted in suffixes. No abbreviations are permitted in street names or community names. All fields must be populated as appropriate, including the postal community name, legal community name, county name, state/province and zipcode. 3.5-13: PSAPs must have access to the actual (MSAG) community name. 3.5-14: A postal address may be a 9-1-1 valid address if, as stated in requirement ?, a query to the 9-1-1 Address Validation Database with the postal address yields exactly one record. 3.5-15: The PSAP must have access to all of the contents of the 9-1-1 address validation database. 3.6 Routing of Calls Rosen & Abbott Expires August 19, 2005 [Page 9] Internet-Draft NENA Requirements February 2005 3.6-1: Calls must be routed to the correct PSAP based on the location of the caller and the declared service boundary of the PSAP. 3.6-2: Routing must be possible on either civic or geo location information. 3.6-3: It must be possible to route a call based on either a civic or a geo location without requiring conversion. from one to the other. This requirement does not prohibit an implementation from converting and using the resulting conversion for routing. However, see Req ?. 3.6-4: It must be possible for a designated 9-1-1 authority for a PSAP to approve of any geo-coding database used to assist in determining routing of calls to that PSAP. Mechanisms must be provided for the designated 9-1-1 authority for the PSAP to test, and certify a geo-coding database as suitable for routing calls to the PSAP. The PSAP may choose to NOT avail itself of such a mechanism. 3.6-5: It must be possible for the designated 9-1-1 authority to supply, maintain, or approve of databases used for civic routing. Mechanisms must be provided for a designated authority for a PSAP to test and certify a civic routing database as suitable for routing calls to that PSAP. 3.6-6: It must be possible for the PSAP itself (or a contractor it nominates on its behalf) to provide geocode and reverse geocode data and/or conversion service to be used for routing determination. This implies definition of a standard interchange format for geocode data, and protocols to access it. 3.6-7: The PSAP must have a mechanism to declare its serving boundaries (in civic and geo formats) for routing purposes. 3.6-8: Boundaries for civic routing must be able to be specific to a street address range, a side of a street (even/odd street addresses), a building within a ôcampusö, or any of the location fields available. 3.6-9: It must be possible to use various combined components of the location object for determination of routing. Some areas may only require routing to a country level, others to a state/province, others to a county, or to a municipality, and so on. No assumption should be made on the granularity of routing boundaries or about the combination of components used. 3.6-10: Boundaries mechanisms for geo routing must be able to be specific to a natural political boundary, a natural physical boundary (such as a river), or the boundaries listed in Req ? above Rosen & Abbott Expires August 19, 2005 [Page 10] Internet-Draft NENA Requirements February 2005 3.6-11: Routing databases using 9-1-1 Valid Addresses or lat/lon/altitude as keys must both be available to all entities needing to route 9-1-1 calls. 3.6-12: Carriers, enterprises and other entities that route emergency calls must be able to route calls from any location to its appropriate PSAP. 3.6-13: It must be possible for a given PSAP to decide where its calls should be routed. 3.6-14: It is desirable for higher level civic authorities such as a county or state/province to be able to make common routing decisions for all PSAPs within their jurisdiction. For example, a state may wish to have all emergency calls placed within that state directed to a specific URI. This does NOT imply a single answering point; further routing may occur beyond the common URI. 3.6-15: Routing as specified in Req ? may change on short notice due to local conditions, traffic, failures, schedule, etc. 3.6-16: Information and mechanisms used to determine routing must be extremely reliable and available, which implies redundancy, protocol stability, and resiliency. 3.6-17: Routing information must be secured against unauthorized modification. PSAPs (or perhaps a higher level civic authority such as a county, state/province or national body) or their designated representative must be the only entities permitted to change routing information. 3.6-18: It must be possible to supply contingency routing information, for example, an alternate URI or an E.164 to be used when normal routing fails. 3.6-19: Multiple types of failures may have different contingency routes. 3.6-20: It must be possible to provide more than one contingency route for the same type of failure 3.6-21: A procedure must be specified to handle ôdefault routeö capability when no location is available or the location information is corrupted. 3.6-22: Location available at the time the call is routed may not be accurate. Updates to location may result in a different route and the system must accommodate this. 3.6-23: Default routes must be available when location information is not available. 3.6-24: Access Infrastructure providers must provide a location object that is as accurate as possible when location measurement or lookup mechanisms fail. 3.6-25: Entities routing emergency calls shall retain information used to choose a route for subsequent error resolution. Rosen & Abbott Expires August 19, 2005 [Page 11] Internet-Draft NENA Requirements February 2005 3.6-26: It should be possible to have updates of location (which may occur when measuring devices provider early, but imprecise ôfirst fixö location) which can change routing of calls. 3.7 Connections to the Emergency Services Network 3.7-1: If there is network connectivity between the emergency caller and the PSAP, and routing information is available, the call should be completed, even if other parts of the network are not reachable. 3.8 Other 3.8-1: There shall be no single point of failure. 3.8-2: Each subsystem in the i3 solution shall be designed such that the system survives major disruption including disaster, deliberate attack, and massive element failure. 3.8-3: Special consideration should be given to ôDistributed Denial of Serviceö attacks 3.8-4: The solution shall include mechanisms to test each element and complete call chains from caller end device to internal PSAP systems without interfering with real emergency calls. 3.8-5: Mechanisms must be provided to provide constant verification of service availability to the PSAP. 3.8-6: Mechansism must be provided to provide automatically generated misroute and location error reports. Rosen & Abbott Expires August 19, 2005 [Page 12] Internet-Draft NENA Requirements February 2005 4. Security Considerations None. 5. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Brian Rosen Emergicom 470 Conrad Dr Mars, PA 16046 US Phone: +1 724 382 1051 Email: br@brianrosen.net Nadine Abbott Telcordia One Telcordia Drive, Room 4B655 Piscataway, NJ 08854 US Phone: +1-732-699-6109 Email: nabbott@telcordia.com Rosen & Abbott Expires August 19, 2005 [Page 13] Internet-Draft NENA Requirements February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosen & Abbott Expires August 19, 2005 [Page 14]