ECRIT B. Rosen Internet-Draft NeuStar, Inc. Intended status: Informational H. Tschofenig Expires: August 25, 2013 Nokia Siemens Networks February 21, 2013 Internet Protocol-based In-Vehicle Emergency Call draft-rosen-ecrit-ecall-07.txt Abstract This document describes how to use a subset of the IETF-based emergency call framework for accomplishing emergency calling support in vehicles. Simplifications are possible due to the nature of the functionality that is going to be provided in vehicles with the usage of GPS. Additionally, further profiling needs to be done regarding the encoding of location information. 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 25, 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 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Rosen & Tschofenig Expires August 25, 2013 [Page 1] Internet-Draft IP-based In-Vehicle Emergency Call February 2013 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 & Tschofenig Expires August 25, 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 suppor for eCall are focused on legacy technology. This document details how emergency calls triggered by vehicles can be accomplished in an Internet Protocol-based environment. 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. Rosen & Tschofenig Expires August 25, 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 [10]. Rosen & Tschofenig Expires August 25, 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 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 element specified in [3] MUST be implemented and MAY be included. This specification also inherits the test call functionality from Section 15 of [4]. Rosen & Tschofenig Expires August 25, 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: ;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: Geolocation-Routing: no Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... Rosen & Tschofenig Expires August 25, 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: -34.407 150.883 278 gps 2012-04-5T10:18:29Z 1M8GDM9A_KP042788 --boundary1-- Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call Rosen & Tschofenig Expires August 25, 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 [11]. 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 [12] for a discussion of some of these vulnerabilities. Rosen & Tschofenig Expires August 25, 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 & Tschofenig Expires August 25, 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 & Tschofenig Expires August 25, 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 & Tschofenig Expires August 25, 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] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004. 9.2. Informative references [10] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008. [11] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008. Rosen & Tschofenig Expires August 25, 2013 [Page 12] Internet-Draft IP-based In-Vehicle Emergency Call February 2013 [12] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy Location", draft-ietf-ecrit-trustworthy-location-04 (work in progress), October 2012. [13] CEN, "Intelligent transport systems - eSafety - eCall minimum set of data (MSD), EN 15722", June 2011. [14] 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 & Tschofenig Expires August 25, 2013 [Page 13] Internet-Draft IP-based In-Vehicle Emergency Call February 2013 Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD) [13] outlines a number of data elements that are transmitted in an emergency call triggered by a vehicle. This 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. 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 , defined in RFC 4481 [14]. Rosen & Tschofenig Expires August 25, 2013 [Page 14] Internet-Draft IP-based In-Vehicle Emergency Call February 2013 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 & Tschofenig Expires August 25, 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 Rosen & Tschofenig Expires August 25, 2013 [Page 16]