< draft-rosen-ecrit-ecall-05.txt		draft-rosen-ecrit-ecall-06.txt >
	ECRIT B. Rosen		ECRIT B. Rosen
	Internet-Draft NeuStar, Inc.		Internet-Draft NeuStar, Inc.
	Intended status: Informational H. Tschofenig		Intended status: Informational H. Tschofenig
	Expires: September 13, 2012 Nokia Siemens Networks		Expires: January 16, 2013 Nokia Siemens Networks
	March 12, 2012		July 15, 2012
	Internet Protocol-based In-Vehicle Emergency Call		Internet Protocol-based In-Vehicle Emergency Call
	draft-rosen-ecrit-ecall-05.txt		draft-rosen-ecrit-ecall-06.txt
	Abstract		Abstract
	This document describes how to use a subset of the IETF-based		This document describes how to use a subset of the IETF-based
	emergency call framework for accomplishing emergency calling support		emergency call framework for accomplishing emergency calling support
	in vehicles. Simplifications are possible due to the nature of the		in vehicles. Simplifications are possible due to the nature of the
	functionality that is going to be provided in vehicles with the usage		functionality that is going to be provided in vehicles with the usage
	of GPS. Additionally, further profiling needs to be done regarding		of GPS. Additionally, further profiling needs to be done regarding
	the encoding of location information.		the encoding of location information.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 13, 2012.		This Internet-Draft will expire on January 16, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	drivers often have a poor location-awareness, especially on urban		drivers often have a poor location-awareness, especially on urban
	roads (also during night) and abroad. In the most crucial cases, the		roads (also during night) and abroad. In the most crucial cases, the
	victim(s) may not be able to call because they have been injured or		victim(s) may not be able to call because they have been injured or
	trapped.		trapped.
	In Europe the European Commission has launched the eCall initiative		In Europe the European Commission has launched the eCall initiative
	that may best be described as a user initiated or automatically		that may best be described as a user initiated or automatically
	triggered system to provide notifications to Public Safety Answering		triggered system to provide notifications to Public Safety Answering
	Point's (PSAP), by means of cellular communications, that a vehicle		Point's (PSAP), by means of cellular communications, that a vehicle
	has crashed, and to provide geodetic location information and where		has crashed, and to provide geodetic location information and where
	possible a voice channel to the PSAP. The current specifications		possible a voice channel to the PSAP. At the time of writing the
	being developed to offer the eCall solution are defined to work with		suppor for eCall are focused on legacy technology. This document
	circuit switched telephony. This document details how similar or		details how emergency calls triggered by vehicles can be accomplished
	more extended functionality can be accomplished using IP-based		in an Internet Protocol-based environment.
	mechanisms.
	This document is organized as follows: Section 2 defines the		This document is organized as follows: Section 2 defines the
	terminology, Section 3 illustrates the required protocol		terminology, Section 3 illustrates the required protocol
	functionality, Section 4 indicates the required data that has to be		functionality, Section 4 indicates the required data that has to be
	transmitted within a PIDF-LO and Section 5 shows an example message		transmitted within a PIDF-LO and Section 5 shows an example message
	exchange. This document concludes with the security considerations		exchange. This document concludes with the security considerations
	in Section 6 and IANA considerations in Section 7.		in Section 6 and IANA considerations in Section 7.
	2. Terminology		2. Terminology
	skipping to change at page 5, line 11 ¶		skipping to change at page 5, line 11 ¶
	This document re-uses a lot of the terminology defined in Section 3		This document re-uses a lot of the terminology defined in Section 3
	of [9].		of [9].
	3. Protocol Profile		3. Protocol Profile
	The usage of in-vehicular emergency calls does not require the usage		The usage of in-vehicular emergency calls does not require the usage
	of a Location Configuration Protocol since GPS is used. Furthermore,		of a Location Configuration Protocol since GPS is used. Furthermore,
	since the GPS receiver is permanently turned on it can even provide		since the GPS receiver is permanently turned on it can even provide
	useful information in cases where the car entered a tunnel.		useful information in cases where the car entered a tunnel.
	Consequently, there is no need to discover any LIS.		Consequently, there is no need to discover any Location Information
			Server (LIS).
	Since the emergency call within the car is either triggered by a		Since the emergency call within the car is either triggered by a
	button or, in most cases, automatically thanks to sensors mounted in		button or, in most cases, automatically thanks to sensors mounted in
	the car there is no need to learn a dial string. This document		the car there is no need to learn a dial string. This document
	registers a separate Service URN, namely 'urn:service:ecall', used		registers a separate Service URN, namely 'urn:service:ecall', used
	specifically for emergency calls that are triggered by vehicles.		specifically for emergency calls that are triggered by vehicles.
			This URN comes with two sub-services to indicate how the emergency
			call was triggered, namely 'automatic' for cases when the emergency
			call was triggered due to a crash automatically without any user
			involvement and 'manual' for cases where a driver or a passenger
			triggered the emergency call. If the device initiating the emergency
			call does not allow to differentiate these two cases then the Service
			URN 'urn:service:ecall' is used.
	The following list provides information about the sections and		The following list provides information about the sections and
	requires of [2] that are relevant to this specification:		requires of [2] that are relevant to this specification:
	Identifying an emergency call: Emergency calls are detected at the		Identifying an emergency call: Emergency calls are detected at the
	end point, i.e., by the vehicle, and the Service URN		end point, i.e., by the vehicle, and the Service URN
	'urn:service:ecall' MUST be implemented by the end point and		'urn:service:ecall' MUST be implemented by the end point and
	recognized by the VSP. The requirements listed in Section 5 of		recognized by the VSP. The requirements listed in Section 5 of
	[2] are therefore irrelevant to this specification, as they deal		[2] are therefore irrelevant to this specification, as they deal
	with identifying an emergency call based on dial strings.		with identifying an emergency call based on dial strings.
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 20 ¶
	Signaling of emergency calls: Section 9 of [2] is applicable to this		Signaling of emergency calls: Section 9 of [2] is applicable to this
	document with the following exception: ED-60/AN-25 is not		document with the following exception: ED-60/AN-25 is not
	applicable as HELD is not used. Video and real-time text may be		applicable as HELD is not used. Video and real-time text may be
	supported by end device in the future, although currently not		supported by end device in the future, although currently not
	envisioned. The corresponding text paragraphs are relevant from		envisioned. The corresponding text paragraphs are relevant from
	Section 9 of [2] when support is being provided. Additionally,		Section 9 of [2] when support is being provided. Additionally,
	ED-62 dealing with "SIP signaling requirements for User Agents" is		ED-62 dealing with "SIP signaling requirements for User Agents" is
	simplified as follows. The initial SIP signaling method is an		simplified as follows. The initial SIP signaling method is an
	INVITE request with the following setting:		INVITE request with the following setting:
	1. The Request URI MUST be the service URN 'urn:service:ecall'.		1. The Request URI MUST be the service URN 'urn:service:ecall'
			or one of the sub-services.
	2. The To header MUST be a service URN 'urn:service:ecall'.		2. The To header MUST be a service URN
			'urn:service:ecall.automatic' or one of the sub-services.
	3. The From header MUST be present and SHOULD be the AoR of the		3. The From header MUST be present and SHOULD be the AoR of the
	caller.		caller.
	4. A Via header MUST be present.		4. A Via header MUST be present.
	5. A Contact header MUST be present which MUST be globally		5. A Contact header MUST be present which MUST be globally
	routable to permit an immediate call-back to the specific		routable to permit an immediate call-back to the specific
	device which placed the emergency call.		device which placed the emergency call.
	skipping to change at page 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	4. Data Profile		4. Data Profile
	Due to the requirement for a built-in GPS receiver only geodetic		Due to the requirement for a built-in GPS receiver only geodetic
	location information will be sent within an emergency call.		location information will be sent within an emergency call.
	Furthermore, the number of location shapes is is restricted. Hence,		Furthermore, the number of location shapes is is restricted. Hence,
	the following location shapes of [6] MUST be implemented: 2d and 3d		the following location shapes of [6] MUST be implemented: 2d and 3d
	Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]),		Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]),
	and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference		and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference
	systems (CRS) specified in [6] are also mandatory for this document.		systems (CRS) specified in [6] are also mandatory for this document.
	Furthermore, the direction of travel of the vehicle is important for		Furthermore, the direction of travel of the vehicle is important for
	dispatch and hence it MUST be included in the PIDF-LO. The <bearing>		dispatch and hence it MUST be included in the PIDF-LO. The <heading>
	element specified in [7] MUST be supported.		element specified in [7] MUST be supported.
	5. Example		5. Example
	Figure 1 shows an emergency call placed from a vehicle whereby		Figure 1 shows an emergency call placed from a vehicle whereby
	location information information is directly attached to the SIP		location information information is directly attached to the SIP
	INVITE message itself. The call is marked as an emergency call using		INVITE message itself. The call is marked as an emergency call using
	the 'urn:service:ecall' service URN and the PSAP of the VoIP provider		the 'urn:service:ecall.automatic' service URN and the PSAP of the
	determines which PSAP to contact based on the provided location		VoIP provider determines which PSAP to contact based on the provided
	information. As shown in the figure, this route determination may be		location information. As shown in the figure, this route
	based on LoST. Then, the emergency call continues towards the PSAP		determination may be based on LoST. Then, the emergency call
	and in this example it hits the ESRP, as the entry point to the PSAP		continues towards the PSAP and in this example it hits the ESRP, as
	operators emergency services network. Finally, the emergency call		the entry point to the PSAP operators emergency services network.
	will be received by a call taker and first reponders will be		Finally, the emergency call will be received by a call taker and
	dispatched.		first reponders will be dispatched.
	+--------+		+--------+
	| LoST |		| LoST |
	| Servers|		| Servers|
	+--------+		+--------+
	^ +-------+		^ +-------+
	| | PSAP2 |		| | PSAP2 |
	| +-------+		| +-------+
	v		v
	+-------+ +------+ +-------+		+-------+ +------+ +-------+
	Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker		Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
	+-------+ +------+ +-------+		+-------+ +------+ +-------+
	+-------+		+-------+
	| PSAP3 |		| PSAP3 |
	+-------+		+-------+
	Figure 1: Example of In-Vehicular Emergency Call Message Flow		Figure 1: Example of In-Vehicular Emergency Call Message Flow
	The following example, in Figure 2, shows location information		The following example, in Figure 2, shows the SIP INVITE and location
	encoded in a PIDF-LO that is being conveyed in such an emergency		information encoded in a PIDF-LO that is being conveyed in such an
	call.		emergency call.
			INVITE urn:service:ecall.automatic SIP/2.0
			To: <sip:intermediate-psap@example.com>
			From: <sip:+13145551111@example.com>;tag=9fxced76sl
			Call-ID: 3848276298220188511@atlanta.example.com
			Geolocation: <cid:target123@example.com>
			Geolocation-Routing: no
			Accept: application/sdp, application/pidf+xml
			CSeq: 31862 INVITE
			Content-Type: multipart/mixed; boundary=boundary1
			Content-Length: ...
			--boundary1
			Content-Type: application/sdp
			...Session Description Protocol (SDP) goes here
			--boundary1
			Content-Type: application/pidf+xml
			Content-ID: <target123@atlanta.example.com>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<presence xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"		<presence
	xmlns:gml="http://www.opengis.net/gml"		xmlns="urn:ietf:params:xml:ns:pidf"
	xmlns:gs="http://www.opengis.net/pidflo/1.0"		xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
	entity="pres:vehicle-identification@example.com">		xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
	<device id="123">		xmlns:dyn="urn:ietf:params:xml:ns:pidf:geopriv10:dynamic"
			xmlns:gml="http://www.opengis.net/gml"
			xmlns:gs="http://www.opengis.net/pidflo/1.0"
			entity="sip:+13145551111@example.com">
			<dm:device id="123">
	<gp:geopriv>		<gp:geopriv>
	<gp:location-info>		<gp:location-info>
	<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">		<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
	<gml:pos>42.5463 -73.2512</gml:pos>		<gml:pos>-34.407 150.883</gml:pos>
	<gs:radius uom="urn:ogc:def:uom:EPSG::9001">		</gml:Point>
	850.24		<dyn:Dynamic>
	</gs:radius>		<dyn:heading>278</dyn:heading>
	</gs:Circle>		</dyn:Dynamic>
	<gml:bearing>		</gp:location-info>
	<gml:DirectionVector>		<gp:usage-rules/>
	<gml:vector> 270.0 -60.0</gml:vector>		<method>gps</method>
	</gml:DirectionVector>
	</gml:bearing>
	</gp:location-info>
	<gp:usage-rules/>
	<method>GPS</method>
	</gp:geopriv>		</gp:geopriv>
	</device>		<timestamp>2012-04-5T10:18:29Z</timestamp>
	</presence>		<dm:deviceID>vehicle-number</dm:deviceID>
			</dm:device>
			</presence>
			--boundary1--
	Figure 2: Example of Location Payload for In-Vehicular Emergency Call		Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call
	6. Security Considerations		6. Security Considerations
	This document does not raise security considerations beyond those		This document does not raise security considerations beyond those
	described in [10]. As with emergency service systems with end host		described in [10]. As with emergency service systems with end host
	provided location information there is the possibility that that		provided location information there is the possibility that that
	location is incorrect, either intentially (in case of an a denial of		location is incorrect, either intentially (in case of an a denial of
	service attack against the emergency services infrastructure) or due		service attack against the emergency services infrastructure) or due
	to a malfunctioning devices. The reader is referred to [11] for a		to a malfunctioning devices. The reader is referred to [11] for a
	discussion of some of these vulnerabilities.		discussion of some of these vulnerabilities.
	7. IANA Considerations		7. IANA Considerations
	IANA is requested to register the URN 'urn:service:ecall' under the		IANA is requested to register the URN 'urn:service:ecall' under the
	sub-services 'sos' registry defined in Section 4.2 of [8].		sub-services 'sos' registry defined in Section 4.2 of [8].
	urn:service:ecall This service identifier reaches a public safety		This service identifier reaches a public safety answering point
	answering point (PSAP), which in turn dispatches aid appropriate		(PSAP), which in turn dispatches aid appropriate to the emergency
	to the emergency related to accidents of vehicles.		related to accidents of vehicles. Two sub-services are registered as
			well, namely
			urn:service:ecall.manual This service URN indicates that an eCall
			had been triggered based on the manual interaction of the driver
			or a passenger.
			urn:service:ecall.automatic This service URN indicates that an eCall
			had been triggered automatically, for example, due to a crash. No
			human involvement was detected.
	8. Contributors		8. Contributors
	We would like to thank Ulrich Dietz for his help with earlier		We would like to thank Ulrich Dietz for his help with earlier
	versions of the document.		versions of the document.
	9. Acknowledgements		9. Acknowledgements
	We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar		We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar
	Hellstroem for their feedback.		Hellstroem for their feedback.
	skipping to change at page 15, line 50 ¶		skipping to change at page 15, line 50 ¶
	[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
	Context Resolution with Internet Technologies", RFC 5012,		Context Resolution with Internet Technologies", RFC 5012,
	January 2008.		January 2008.
	[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,		[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
	"Security Threats and Requirements for Emergency Call Marking		"Security Threats and Requirements for Emergency Call Marking
	and Mapping", RFC 5069, January 2008.		and Mapping", RFC 5069, January 2008.
	[11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy		[11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy
	Location Information", draft-ietf-ecrit-trustworthy-location-02		Location Information", draft-ietf-ecrit-trustworthy-location-03
	(work in progress), May 2011.		(work in progress), April 2012.
	Authors' Addresses		Authors' Addresses
	Brian Rosen		Brian Rosen
	NeuStar, Inc.		NeuStar, Inc.
	470 Conrad Dr		470 Conrad Dr
	Mars, PA 16046		Mars, PA 16046
	US		US
	Phone:		Phone:
End of changes. 18 change blocks.
	53 lines changed or deleted		94 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/