< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/