ECRIT B. Rosen
Internet-Draft NeuStar, Inc.
Intended status: Informational H. Tschofenig
Expires: January 15, 2014 Nokia Siemens Networks
R. Gellens
QUALCOMM Incorporated
July 14, 2013

Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-10.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 January 15, 2014.

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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

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 Points (PSAPs), 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.

The general term for such systems is Automatic Crash Notification (ACN). ACN systems transmit some amount of data specific to the incident, referred to generally as "crash data." While different systems transmit different amounts of crash data, standardized formats, structures, and mechanisms are needed to provide interoperability among systems and PSAPs.

This document describes how existing IETF mechanisms are used to provide the realization of next-generation ACN in general, including European eCall.

This document registers the 'application/emergencyCall.VEDS+xml' MIME content-type, and registers the 'VEDS' entry in the Emergency Call Additional Data registry.

The Vehicle Emergency Data Set (VEDS) is an XML structure defined by the Association of Public-Safety Communications Officials (APCO) and the National Emergency Number Association (NENA). The 'application/emergencyCall.VEDS+xml' MIME content-type is used to identify it. The 'VEDS' entry in the Emergency Call Additional Data registry is used to construct a 'purpose' parameter value for conveying VEDS data in a Call-Info header.

Circuit-switched eCall systems transmit crash data as a defined set, the Minimum Set of Data (MSD) [eCall-MSD].The MSD for circuit-switched eCall is a binary format defined by CEN, the European Committee for Standardization. It is expected that CEN will choose to define the XML schema for the eCall MSD for use in next-generation systems. Once this done, a MIME content-type (e.g., 'application/emergencyCall.eCall.MSD+xml') and Emergency Call Additional Data entry (e.g., 'eCall.MSD') need to be registered for the MSD. Note that Appendix A explains how the functionality available in IETF specifications maps to the functionality required for the MSD of the mobile circuit switched voice solution.

CEN and/or other entities may define additional sets of data in the same manor: a standardized format, such as XML, is defined, and a MIME content-type and Emergency Call Additional Data entry registered.

An In-Vehicle System (IVS) transmits crash data by encoding it in one of the standardized and registered formats (such as VEDS or eCall.MSD) and attaching it to an INVITE as a data block. The block is identified by its MIME content-type, and pointed to by a CID URL in a Call-Info header with a 'purpose' parameter value corresponding to the block.

The mechanisms described here can be used to deploy ACN systems in general including eCall by providing for emergency calls that are identifiable as ACN calls or specifically eCall calls and that carry one or more defined crash data objects.

1.1. Overview of Current Deployment Models

Current (circuit-switched or legacy) systems for placing emergency calls from vehicles, including automatic crash notification system, generally use one of three architectural models: Telematics Service Provider (TSP), direct, and paired handset. These three models are illustrated below.

In the TSP model the IVS transmits crash data to the TSP using proprietary means. The TSP operator bridges in the PSAP and communicates location, crash, and other data to the call taker verbally (there is a three-way voice call between the vehicle, the TSP, and the PSAP).

   ///----\\\  proprietary  +------+    911 trunk      +------+
  ||| IVS |||-------------->+ TSP  +------------------>+ PSAP |
   \\\----///  crash data   +------+                   +------+

Figure 1: TSP Model.

In the paired model the IVS uses a Bluetooth link to a previously-paired handset to establish an emergency call with the PSAP and then communicates location data to the PSAP via text-to-speech; crash data is not conveyed.

                 ++
   ///----\\\    ||    911 voice call via handset      +------+
  ||| IVS |||--->|+----------------------------------->+ PSAP |
   \\\----///    ++   location via text-to-speech      +------+

Figure 2: Paired Model

In the direct model the IVS communicates crash data to the PSAP via the eCall in-band modem (in the voice call).

   ///----\\\      112/911 voice call via IVS          +------+
  ||| IVS  |||---------------------------------------->+ PSAP |
   \\\----///   crash data via eCall in-band modem     +------+

Figure 3: Direct Model

1.2. Migration to IP-based Models

The migration to next-generation (all-IP) would then look like as follows.

In the TSP model The IVS transmits crash data to the TSP using either proprietary or standard means. The TSP bridges in the PSAP and transmits crash and other data to the PSAP using IETF specifications. There is a three-way call between the vehicle, the TSP, and the PSAP.

               proprietary
   ///----\\\  or standard  +------+     standard       +------+
      IVS     ------------->+ TSP  +------------------->+ PSAP |
   \\\----///  crash data   +------+ crash + other data +------+

Figure 4: TSP Model

In the paired model, the IVS uses a Bluetooth link to a previously-paired handset to establish an emergency call with the PSAP; it is not clear what facilities are or will be available for transmitting crash data.

                 ++
   ///----\\\    ||  IP-based Emergency Call           +------+
      IVS    --->|+----------------------------------->+ PSAP |
   \\\----///    ++                                    +------+

Figure 5: Paired Model

In the direct model the IVS communicates crash data to PSAP using Internet protocols.

  ///----\\\          NG1-1-2/NG9-1-1 call            +------+
     IVS    ----------------------------------------->+ PSAP |
  \\\----///               crash data                 +------+

Figure 6: Direct Model

This document is focused on the interface to the PSAP, that is, how an emergency call (including location and crash data) is setup and data is transmitted to the PSAP using existing IETF specifications. The goal is to re-use existing specifications rather than to invent new. For the direct model (such as the European eCall), this is the end-to-end description. For the TSP model, this describes the right-hand side, leaving the left-hand side up to the entities involved (e.g., IVS and TSP vendors) who are then free to use the same mechanism as for the right-hand side or not.

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 [RFC2119].

This document re-uses terminology defined in Section 3 of [RFC5012].

Additionally, we use the following abbreviations:

IVS:
In-Vehicle System
TSP:
Telematics Service Provider
MSD:
Minimum Set of Data
VEDS:
Vehicle Emergency Data Set
NENA:
National Emergency Number Association
APCO:
Association of Public-Safety Communications Officials
CEN:
European Committee for Standardization
ESInet:
Emergency Services IP network

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 [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 [RFC6881].

4. Example

Figure 7 shows an emergency call placed from a vehicle whereby location information information is directly attached to the SIP INVITE message itself. The call uses the request URI 'urn:service:sos.ecall.automatic' service URN and is recognized as an emergency call because the request URI starts with 'urn:service:sos'. The VoIP provider routes the call to an Emergency services IP Network (ESInet), as for any emergency call. The ESInet routes the call to an appropriate PSAP using location information and the fact that that it is an eCall carrying crash data. (In deployments where there is no ESInet, the VoIP provider may route directly to an appropriate PSAP.) The emergency call continues towards the PSAP and in this example it hits the ESRP, as the entry point to the ESInet. 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 |              |
                            |                  +-------+              |
                            |                                         |
                            |                                         |
                            |                                         |
                            |                ESInet                   |
                            +-----------------------------------------+
            

Figure 7: Example of In-Vehicular Emergency Call Message Flow

The example, shown in Figure 8, illustrates a SIP emergency call eCall INVITE that is being conveyed with location information encoded in a PIDF-LO and VEDS data.

   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
   Call-Info: cid:1234567890@atlanta.example.com;
              purpose=emergencyCallData.VEDS
   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

Content-Type: application/emergencyCall.VEDS+xml
Content-ID: 1234567890@atlanta.example.com

...eCall VEDS data object goes here

    --boundary1--

Figure 8: SIP INVITE indicating an In-Vehicular Emergency Call

5. Security Considerations

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.

6. IANA Considerations

6.1. Service URN Registration

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

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.

6.2. MIME Content-type Registration for 'application/emergencyCall.VEDS+xml'

This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].

  • MIME media type name: application
  • MIME subtype name: emergencyCall.VEDS+xml
  • Mandatory parameters: none
  • Optional parameters: charset
  • Indicates the character encoding of enclosed XML.
  • Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See Section 3.2 of RFC 3023 [RFC3023].
  • Security considerations: This content type is designed to carry vehicle crash data during an emergency call. This data may contains personal information including vehicle VIN, location, direction, etc. appropriate precautions need to be taken to limit unauthorized access, inappropriate disclosure to third parties, and eavesdropping of this information. Please refer to Section 7 and Section 8 of [I-D.ietf-ecrit-additional-data] for more information.
  • Interoperability considerations: None
  • Published specification: [TBD: This specification]
  • Applications which use this media type: Emergency Services
  • Additional information: None
  • Magic Number: None
  • File Extension: .xml
  • Macintosh file type code: 'TEXT'
  • Person and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@gmx.net
  • Intended usage: LIMITED USE
  • Author: This specification is a work item of the IETF ECRIT working group, with mailing list address <ecrit@ietf.org>.
  • Change controller: The IESG <ietf@ietf.org>

6.3. Registration of the 'VEDS' entry in the Emergency Call Additional Data registry

This specification requests IANA to add the 'VEDS' entry to the Emergency Call Additional Data registry, with a reference to this document. The Emergency Call Additional Data registry has been established by [I-D.ietf-ecrit-additional-data].

7. Contributors

We would like to thank Ulrich Dietz for his help with earlier versions of the document.

8. Acknowledgements

We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, and Gunnar Hellström for their feedback.

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] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[3] 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.
[4] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in Support of Emergency Calling", BCP 181, RFC 6881, March 2013.
[5] Polk, J., Rosen, B. and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[6] 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.
[7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", RFC 4288, December 2005.
[9] Rosen, B., Tschofenig, H., Marshall, R. and R. Randy, "Additional Data related to an Emergency Call", Internet-Draft draft-ietf-ecrit-additional-data-07, February 2013.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008.

9.2. Informative references

[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.

Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD)

[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 since legacy eCall uses an inband voice modem for backwards compatibility with the already deployed cellular infrastructure to transmit data from a vehicle to a PSAP. Since the functionality in this document is based on the Session Initiation Protocol (SIP) 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 mechanisms standardized for emergency call handling. Any voice, video, or real-text communication will be negotiated using the Session Description Protocol (SDP), as shown in Figure 8, and the actual media stream will then take place in RTP packets. For transmitting location information an XML-based data structure had been defined, the so-called Presence Information Data Format Location Object (PIDF-LO).

The following list compares the eCall minimum set of data with the functionality provided in this document.

Version of the MSD Format:
Conveying information in a SIP-based emergency call is accomplished by using XML payloads and XML provides namespace declarations that allow a receipient of that information to distinguish different versions and additional extensions. For example, if additional data about a vehicle is defined and can be transmitted by vehicle then a respective extension can be defined for use inside a previously-defined XML structure. One or more top-level structures can be transmitted using the mechanism defined in [I-D.ietf-ecrit-additional-data]. Selecting the appropriate extension point depends on the type of extension envisioned.
Message Identifier:
Every SIP INVITE message contains a Call-ID, which is a globally unique identifier for this call.
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 [RFC6881].
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).
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 object, 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 [RFC4481].
Additional Data:
[I-D.ietf-ecrit-additional-data] provides the ability to carry additional data for an emergency call.

While most fields have an equivalent already in the corresponding SIP emergency signaling payloads there are currently no fields defined in [I-D.ietf-ecrit-additional-data] that allow information about the "Vehicle Type Encoding", "Number of Passengers", and "Vehicle Propulsion Storage type" to be conveyed. Extensions for those fields will have to be defined.

Authors' Addresses

Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US 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