Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-08
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Brian Rosen , Hannes Tschofenig , Randall Gellens | ||
| Last updated | 2013-02-24 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rosen-ecrit-ecall-08
ECRIT B. Rosen
Internet-Draft NeuStar, Inc.
Intended status: Standards Track H. Tschofenig
Expires: August 29, 2013 Nokia Siemens Networks
R. Gellens
QUALCOMM Incorporated
February 25, 2013
Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-08.txt
Abstract
This document describes how to re-use the emergency services
mechanisms specified for the Session Initiation Protocol (SIP) to
accomplishing emergency calling support in vehicles. Profiling and
simplifications are possible due to the nature of the functionality
that is going to be provided in vehicles with the usage of Global
Positioning System (GPS).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 August 29, 2013.
Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect
Rosen, et al. Expires August 29, 2013 [Page 1]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative references . . . . . . . . . . . . . . . . . . 12
Appendix A. Matching Functionality with eCall Minimum Set of
Data (MSD) . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Rosen, et al. Expires August 29, 2013 [Page 2]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
1. Introduction
Emergency calls made from vehicles can assist with the objective of
significantly reducing road deaths and injuries. Unfortunately,
drivers often have a poor location-awareness, especially on urban
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
trapped.
In Europe the European Commission has launched the 'eCall' initiative
that may best be described as a user initiated or automatically
triggered system to provide notifications to Public Safety Answering
Point's (PSAP), by means of cellular communications, that a vehicle
has crashed, and to provide geodetic location information and where
possible a voice channel to the PSAP. At the time of writing the
support for eCall is focused on legacy mobile circuit switched voice
technology. This document details how the same functionality (and
even more) can be accomplished using Internet protocols and SIP. The
goal is to re-use existing specifications in the area of SIP-based
emergency calling.
This document is organized as follows: Section 2 defines the
terminology, Section 3 describes how the required functionality can
be accomplished by combining several already existing standards, and
Section 4 shows an example message exchange. This document concludes
with the security considerations in Section 5 and IANA considerations
in Section 6. Appendix A illustrates how to map the functionality in
this document to the eCall Minimum Set of Data (MSD) specified for
mobile circuit switched voice.
Rosen, et al. Expires August 29, 2013 [Page 3]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1].
This document re-uses terminology defined in Section 3 of [9].
Rosen, et al. Expires August 29, 2013 [Page 4]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
3. Profile
In the context of emergncy calls placed from a vehicle it is assumed
that the car is equipped with a built-in GPS receiver. For this
reason only geodetic location information will be sent within an
emergency call. The following location shapes MUST be implemented:
2d and 3d Point (see Section 5.2.1 of [2]), Circle (see Section 5.2.3
of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate
reference systems (CRS) specified in [2] are also mandatory for this
document. The <direction> element, as defined in [3] which indicates
the direction of travel of the vehicle, is important for dispatch and
hence it MUST be included in the PIDF-LO . The <heading> element
specified in [3] MUST be implemented and MAY be included.
This specification also inherits the ability to utilize test call
functionality from Section 15 of [4].
Rosen, et al. Expires August 29, 2013 [Page 5]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
4. Example
Figure 1 shows an emergency call placed from a vehicle whereby
location information information is directly attached to the SIP
INVITE message itself. The call is marked as an emergency call using
the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the
VoIP provider determines which PSAP to contact based on the provided
location information. The emergency call continues towards the PSAP
and in this example it hits the ESRP, as the entry point to the PSAP
operators emergency services network. Finally, the emergency call
will be received by a call taker and first reponders will be
dispatched.
+--------+
| LoST |
| Server |
+--------+
^ +-------+
| | PSAP2 |
| +-------+
v
+-------+ +------+ +-------+
Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
Figure 1: Example of In-Vehicular Emergency Call Message Flow
The example, shown in Figure 2, illustrates a SIP INVITE and location
information encoded in a PIDF-LO that is being conveyed in such an
emergency call.
INVITE urn:service:sos.ecall.automatic SIP/2.0
To: urn:service:sos.ecall.automatic
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: ...
Rosen, et al. Expires August 29, 2013 [Page 6]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
--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"?>
<presence
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
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:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>-34.407 150.883</gml:pos>
</gml:Point>
<dyn:Dynamic>
<dyn:heading>278</dyn:heading>
<dyn:direction><dyn:direction>
</dyn:Dynamic>
</gp:location-info>
<gp:usage-rules/>
<method>gps</method>
</gp:geopriv>
<timestamp>2012-04-5T10:18:29Z</timestamp>
<dm:deviceID>1M8GDM9A_KP042788</dm:deviceID>
</dm:device>
</presence>
--boundary1--
Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call
Rosen, et al. Expires August 29, 2013 [Page 7]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
5. Security Considerations
This document does not raise security considerations beyond those
described in [10]. As with emergency service systems with end host
provided location information there is the possibility that that
location is incorrect, either intentially (in case of an a denial of
service attack against the emergency services infrastructure) or due
to a malfunctioning devices. The reader is referred to [11] for a
discussion of some of these vulnerabilities.
Rosen, et al. Expires August 29, 2013 [Page 8]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
6. IANA Considerations
IANA is requested to register the URN 'urn:service:sos.ecall' under
the sub-services 'sos' registry defined in Section 4.2 of [5].
This service identifier reaches a public safety answering point
(PSAP), which in turn dispatches aid appropriate to the emergency
related to accidents of vehicles. Two sub-services are registered as
well, namely
urn:service:sos.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:sos.ecall.automatic
This service URN indicates that an eCall had been triggered
automatically, for example, due to a crash. No human involvement
was detected.
Rosen, et al. Expires August 29, 2013 [Page 9]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
7. Contributors
We would like to thank Ulrich Dietz for his help with earlier
versions of the document.
Rosen, et al. Expires August 29, 2013 [Page 10]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
8. Acknowledgements
We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri,
and Gunnar Hellstroem for their feedback.
Rosen, et al. Expires August 29, 2013 [Page 11]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[3] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson,
"Dynamic Extensions to the Presence Information Data Format
Location Object (PIDF-LO)", RFC 5962, September 2010.
[4] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-20 (work in progress),
September 2011.
[5] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
[6] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy,
"Additional Data related to an Emergency Call",
draft-ietf-ecrit-additional-data-06 (work in progress),
February 2013.
[7] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for
the Session Initiation Protocol", RFC 6442, December 2011.
9.2. Informative references
[9] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012,
January 2008.
[10] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008.
[11] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy
Location", draft-ietf-ecrit-trustworthy-location-04 (work in
progress), October 2012.
Rosen, et al. Expires August 29, 2013 [Page 12]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
[12] CEN, "Intelligent transport systems - eSafety - eCall minimum
set of data (MSD), EN 15722", June 2011.
[13] Schulzrinne, H., "Timed Presence Extensions to the Presence
Information Data Format (PIDF) to Indicate Status Information
for Past and Future Time Intervals", RFC 4481, July 2006.
Rosen, et al. Expires August 29, 2013 [Page 13]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD)
[12] outlines a number of data elements that are transmitted in an
emergency call triggered by a vehicle. Note that the work on eCall
for mobile circuit switched voice is constrained in a number of ways.
For example, eCall uses an inband voice modem to transmit data from a
vehicle to a PSAP. Since the functionality in this document is based
on the Session Initiation Protocol these limitations do not exist.
As such, it is not useful to transmit the MSD inband in the voice
channel but to rather use the SIP-designed mechanisms. Any voice,
video, or real-text communication will be negotiated using the
Session Description Protocol (SDP), as shown in Figure 2, and the
actual media stream will then take place in RTP packets.
The following list compares the eCall minimum set of data with the
functionality provided in this document.
Version of the MSD Format
Message Identifier: Every SIP INVITE message contains a Call-ID,
which is a globally unique identifier for this call.
Vehicle Type Encoding: [Editor's Note: Description to be added.].
Test Call Indication A service URN starting with "test." indicates a
request for an automated test. For example,
"urn:service:test.sos.ecall.automatic" indicates such a test
feature. This functionality is defined in [4].
Automatic Activation Indication: This document registers new service
URNs, which allow the differentiation between manually and
automatically triggered emergency calls. The two service URNs
are: urn:service:sos.ecall.automatic and
urn:service:sos.ecall.manual
Vehicle Identification: The PIDF data structure contains a deviceID
field that holds the Vehicle Identification Number (VIN).
Vehicle Propulsion Storage type: These parameters identify the type
of vehicle energy storage(s) present. [Editor's Note:
Description to be added.]
Timestamp of Incident Event: The PIDF-LO element contains the
timestamp when the PIDF-LO was created, which is at the time of
the incident.
Rosen, et al. Expires August 29, 2013 [Page 14]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
Vehicle Location: The location of the vehicle is conveyed using the
PIDF location objection, as described in Section 3.
Vehicle Direction: The direction of the vehicle is part of location
information, as described in Section 3.
Recent Vehicle Location: With this optional functionality multiple
location objects may be required to be transported simultaneously.
This can be achieved using <timed-presence>, defined in RFC 4481
[13].
Number of Passengers: Minimum known number of fastened seatbelts.
[Editor's Note: Description to be added.]
Additional Data: [6] provides the ability to carry additional data
for an emergency call.
Rosen, et al. Expires August 29, 2013 [Page 15]
Internet-Draft IP-based In-Vehicle Emergency Call February 2013
Authors' Addresses
Brian Rosen
NeuStar, Inc.
470 Conrad Dr
Mars, PA 16046
US
Phone:
Email: br@brianrosen.net
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego 92651
US
Email: rg+ietf@qualcomm.com
Rosen, et al. Expires August 29, 2013 [Page 16]