[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]