| ECRIT | B. Rosen |
| Internet-Draft | NeuStar, Inc. |
| Intended status: Standards Track | H. Tschofenig |
| Expires: October 13, 2013 | Nokia Siemens Networks |
| R. Gellens | |
| QUALCOMM Incorporated | |
| April 11, 2013 |
Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-08.txt
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).
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 October 13, 2013.
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 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.
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.
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 [RFC2119].
This document re-uses terminology defined in Section 3 of [RFC5012].
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 [RFC5491]), Circle (see Section 5.2.3 of [RFC5491]), and Ellipsoid (see Section 5.2.7 of [RFC5491]). The coordinate reference systems (CRS) specified in [RFC5491] are also mandatory for this document. The <direction> element, as defined in [RFC5962] 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 [RFC5962] MUST be implemented and MAY be included.
This specification also inherits the ability to utilize test call functionality from Section 15 of [I-D.ietf-ecrit-phonebcp].
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: ...
--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
This document does not raise security considerations beyond those described in [RFC5069]. 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 [I-D.ietf-ecrit-trustworthy-location] for a discussion of some of these vulnerabilities.
IANA is requested to register the URN 'urn:service:sos.ecall' under the sub-services 'sos' registry defined in Section 4.2 of [RFC5031].
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
We would like to thank Ulrich Dietz for his help with earlier versions of the document.
We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, and Gunnar Hellström for their feedback.
| [1] | Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. |
| [2] | Taylor, T., Tschofenig, H., Schulzrinne, H. and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. |
| [3] | Tschofenig, H., Schulzrinne, H. and B. Aboba, "Trustworthy Location", Internet-Draft draft-ietf-ecrit-trustworthy-location-05, March 2013. |
| [4] | 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. |
| [5] | CEN, , "Intelligent transport systems - eSafety - eCall minimum set of data (MSD), EN 15722", June 2011. |
[eCall-MSD] 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.