< draft-rosen-ecrit-ecall-04.txt   draft-rosen-ecrit-ecall-05.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 9, 2010 Nokia Siemens Networks Expires: September 13, 2012 Nokia Siemens Networks
U. Dietz March 12, 2012
Vodafone
March 8, 2010
Best Current Practice for IP-based In-Vehicle Emergency Calls Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-04.txt draft-rosen-ecrit-ecall-05.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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on September 13, 2012.
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 September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative references . . . . . . . . . . . . . . . . . 15 10.2. Informative references . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Emergency calls made from vehicles can assist with the objective of Emergency calls made from vehicles can assist with the objective of
significantly reducing road deaths and injuries. Unfortunately, significantly reducing road deaths and injuries. Unfortunately,
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.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
+-------+ +-------+
| 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 location information
encoded in a PIDF-LO that is being conveyed in such an emergency encoded in a PIDF-LO that is being conveyed in such an emergency
call. call.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf" <presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:vehicle-identification@example.com"> entity="pres:vehicle-identification@example.com">
<device id="123"> <device id="123">
<gp:geopriv> <gp:geopriv>
<gp:location-info> <gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos> <gml:pos>42.5463 -73.2512</gml:pos>
skipping to change at page 10, line 32 skipping to change at page 10, line 32
<gml:vector> 270.0 -60.0</gml:vector> <gml:vector> 270.0 -60.0</gml:vector>
</gml:DirectionVector> </gml:DirectionVector>
</gml:bearing> </gml:bearing>
</gp:location-info> </gp:location-info>
<gp:usage-rules/> <gp:usage-rules/>
<method>GPS</method> <method>GPS</method>
</gp:geopriv> </gp:geopriv>
</device> </device>
</presence> </presence>
Figure 2: Example of In-Vehicular Emergency Call Message Flow Figure 2: Example of Location Payload for 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 urn:service:ecall This service identifier reaches a public safety
answering point (PSAP), which in turn dispatches aid appropriate answering point (PSAP), which in turn dispatches aid appropriate
to the emergency related to accidents of vehicles. to the emergency related to accidents of vehicles.
8. Acknowledgements 8. Contributors
We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar
Hellstroem for their feedback.
9. Open Issues
While working on this document a few aspects where discovered that
require further discussion:
o Today's work on the eCall system does not necessarily require a We would like to thank Ulrich Dietz for his help with earlier
voice call to be established; a voice call may be established versions of the document.
whenever possible by the functionality offered by the device.
From a protocol mechanims, however, the design for establishing an
emergency call including voice and without voice support are
somewhat different. Further discussion on the design aspects are
needed to align this aspect.
o This document currently defines a new service URN to differentiate 9. Acknowledgements
it from ordinary calls as in-vehicular emergency calls are, in
some countries, routed to different PSAPs than regular emergency
calls. More thoughts are needed to determine whether this is the
best approach.
o The current version of the document assumes the usage of LoST at We would like to thank Michael Montag, Arnoud van Wijk, and Gunnar
the VSP to perform call routing of the in-vehicular emergency Hellstroem for their feedback.
call. This is useful when there are no dial strings need to be
learned nor any other service URNs need to be discovered. Further
discussion is needed whether additional service URNs might be made
available to the vehicle, for example to request roadside
assistance or similar services. In that case the option might be
provided to run LoST at the end host as well as on the VSP.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosen, B. and J. Polk, "Best Current Practice for [2] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-14 (work in progress), January 2010. draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object [3] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[4] Polk, J. and B. Rosen, "Location Conveyance for the Session [4] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
Initiation Protocol", draft-ietf-sipcore-location-conveyance-02 the Session Initiation Protocol", RFC 6442, December 2011.
(work in progress), February 2010.
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller [5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004. RFC 3841, August 2004.
[6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. RFC 5491, March 2009.
[7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, [7] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson,
"Dynamic Extensions to the Presence Information Data Format "Dynamic Extensions to the Presence Information Data Format
Location Object (PIDF-LO)", Location Object (PIDF-LO)", RFC 5962, September 2010.
draft-singh-geopriv-pidf-lo-dynamic-08 (work in progress),
March 2010.
[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008. and Other Well-Known Services", RFC 5031, January 2008.
10.2. Informative references 10.2. Informative references
[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", Location Information", draft-ietf-ecrit-trustworthy-location-02
draft-tschofenig-ecrit-trustworthy-location-03 (work in (work in progress), May 2011.
progress), March 2010.
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:
skipping to change at page 17, line 25 skipping to change at line 392
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Ulrich Dietz
Vodafone
Chiemgaustrasse 116
Munich 81549
Germany
Email: Ulrich.Dietz@vodafone.com
 End of changes. 20 change blocks. 
63 lines changed or deleted 29 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/