--- 1/draft-ietf-ecrit-car-crash-02.txt 2015-07-06 13:15:15.471213634 -0700 +++ 2/draft-ietf-ecrit-car-crash-03.txt 2015-07-06 13:15:15.519214814 -0700 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Qualcomm Technologies, Inc Intended status: Informational B. Rosen -Expires: September 8, 2015 NeuStar, Inc. +Expires: January 3, 2016 NeuStar, Inc. H. Tschofenig - (no affiliation) - March 7, 2015 + + July 4, 2015 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-02.txt + draft-ietf-ecrit-car-crash-03.txt Abstract This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the @@ -49,21 +49,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on September 8, 2015. + This Internet-Draft will expire on January 3, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -201,24 +201,25 @@ routed to an upgraded PSAP where the vehicle data is available to assist the call taker in assessing and responding to the situation. An ACN call may be either occupant-initiated or automatically triggered. (The "A" in "ACN" does stand for "Automatic," but the term is often used to refer to the class of calls that are placed by an in-vehicle system (IVS) and that carry incident-related data as well as voice.) Automatically triggered calls indicate a car crash or some other serious incident (e.g., a fire) and carry a greater presumption of risk of injury. Manually triggered calls are often - reports of serious hazards (such as drunk drivers) and may require - different responses depending on the situation. Manually triggered - calls are also more likely to be false (e.g., accidental) calls and - may thus be subject to different handling by the PSAP. + reports of serious hazards (such as impaired drivers or roadway + debris) and may require different responses depending on the + situation. Manually triggered calls are also more likely to be false + (e.g., accidental) calls and may thus be subject to different + handling by the PSAP. This document describes how the IETF mechanisms for IP-based emergency calls, including [RFC6443] and [I-D.ietf-ecrit-additional-data], are used to provide the realization of next-generation ACN. The Association of Public-Safety Communications Officials (APCO) and the National Emergency Number Association (NENA) have jointly developed a standardized set of incident-related vehicle data for ACN use, called the Vehicle Emergency Data Set (VEDS) [VEDS]. Such data @@ -365,21 +366,21 @@ currently mandated, Europe has a mandated and standardized system for emergency calls by in-vehicle systems. This pan-European system is known as "eCall" and is the subject of a separate document, [I-D.ietf-ecrit-ecall]. Vehicles designed to operate in multiple regions may need to support eCall as well as the ACN described here. If other regions devise their own specifications or data formats, a multi-region vehicle may need to support those as well. This document adopts the call set-up and other technical aspects of [I-D.ietf-ecrit-ecall], which uses [I-D.ietf-ecrit-additional-data], which makes it easy to substitute a different data set while keeping - other technical aspects unchanges. Hence, both NG-eCall and the ACN + other technical aspects unchanged. Hence, both NG-eCall and the ACN mechanism described here are fully compatible, differing only in the specific data block that is sent (the eCall MSD in the case of NG- eCall, and the APCO/NENA VEDS used in this document). If other regions adopt their own data set, this can be similarly accomodated without changing other technical aspects. 5. Migration to Next-Generation Migration of emergency calls placed by in-vehicle systems to next- generation (all-IP) technology provides a standardized mechanism to @@ -395,21 +396,21 @@ vehicle and the TSP for both emergency and non-emergency calls. A next-generation IVS establishes an emergency call using the emergency call solution as described in [RFC6443] and [RFC6881], with the difference that the Request-URI indicates an ACN type of emergency call and a Call-Info header field indicates that vehicle crash data is attached. When an ESInet is deployed the MNO only needs to recognize the call as an emergency call and route it to an ESInet. The ESInet may recognize the call as an ACN with vehicle data and may route the call to an NG-ACN capable PSAP. Such a PSAP - would interpet the vehicle data sent with the call and make it + would interpret the vehicle data sent with the call and make it available to the call taker. Because of the need to identify and specially process Next-Generation ACN calls (as discussed above), [I-D.ietf-ecrit-ecall] registers new service URN children within the "sos" subservice. These URNs provide a mechanism by which an NG-ACN call is identified, and differentiate between manually and automatically triggered NG-ACN calls, which can be subject to different treatment, depending on policy. (The two service URNs registered in [I-D.ietf-ecrit-ecall] are: urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual.) @@ -629,37 +630,38 @@ identify the call as an ACN call and handle it appropriately. The PSAP is able to identify the crash data as well as any other additional data attached to the INVITE by examining the Call-Info header fields for 'purpose' parameters whose values start with 'EmergencyCallData.' The PSAP is able to access and the data it is capable of handling and is interested in by checking the 'purpose' parameter values. 8. Call Routing - An Emergency Services IP Network (ESInet) is a network operated by - emergency services authorities. It handles emergency call routing - and processing before delivery to a PSAP. In the NG9-1-1 - architecture adopted by NENA as well as the NG1-1-2 architecture - adopted by EENA, each PSAP is connected to one or more ESInets. Each - originating network is also connected to one or more ESInets. The - ESInets maintain policy-based routing rules which control the routing - and processing of emergency calls. The centralization of such rules - within ESInets provides for a cleaner separation between the - responsibilities of the originating network and that of the emergency - services network, and provides greater flexibility and control over - processing of emergency calls by the emergency services authorities. - This makes it easier to react quickly to unusual situations that - require changes in how emergency calls are routed or handled (e.g., a - natural disaster closes a PSAP), as well as ease in making long-term - changes that affect such routing (e.g., cooperative agreements to - specially handle calls requiring translation or relay services). + An Emergency Services IP Network (ESInet) is a network operated by or + on behalf of emergency services authorities. It handles emergency + call routing and processing before delivery to a PSAP. In the + NG9-1-1 architecture adopted by NENA as well as the NG1-1-2 + architecture adopted by EENA, each PSAP is connected to one or more + ESInets. Each originating network is also connected to one or more + ESInets. The ESInets maintain policy-based routing rules which + control the routing and processing of emergency calls. The + centralization of such rules within ESInets provides for a cleaner + separation between the responsibilities of the originating network + and that of the emergency services network, and provides greater + flexibility and control over processing of emergency calls by the + emergency services authorities. This makes it easier to react + quickly to unusual situations that require changes in how emergency + calls are routed or handled (e.g., a natural disaster closes a PSAP), + as well as ease in making long-term changes that affect such routing + (e.g., cooperative agreements to specially handle calls requiring + translation or relay services). In an environment that uses ESInets, the originating network need only detect that the service URN of an emergency call is or starts with "sos", passing all types of emergency calls to an ESInet. The ESInet is then responsible for routing such calls to an appropriate PSAP. In an environment without an ESInet, the emergency services authorities and the originating carriers would need to determine how such calls are routed. 9. Test Calls @@ -993,14 +995,13 @@ Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US Email: br@brianrosen.net Hannes Tschofenig - (no affiliation) Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at