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

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/