wdiff draft-rosen-ecrit-ecall-08.txt draft-rosen-ecrit-ecall-09.txt

ECRIT B. Rosen
Internet-Draft NeuStar, Inc.
Intended status: Standards Track Informational H. Tschofenig
Expires: August 29, 2013 January 14, 2014 Nokia Siemens Networks
R. Gellens
QUALCOMM Incorporated
February 25,
July 13, 2013

Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-08.txt
draft-rosen-ecrit-ecall-09.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 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. January 14, 2014.

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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Overview of Current Deployment Models . . . . . . . . . . 3
1.2. Migration to IP-based Models . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6
4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Service URN Registration . . . . . . . . . . . . . . . . 8
6.2. MIME Content-type Registration for
'application/emergencyCall.VEDS+xml' . . . . . . . . . . 9
6.3. Registration of the 'VEDS' entry in the Emergency Call
Additional Data registry . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10
9.2. Informative references . . . . . . . . . . . . . . . . . . 12 11
Appendix A. Matching Functionality with eCall Minimum Set of
Data (MSD) . . . . . . . . . . . . . . . . . . . . . 14 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 13

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

This document registers the time '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 writing Public-Safety Communications Officials (APCO) and
the
support 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) [15]. The MSD for circuit-switched
eCall is focused on legacy 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
technology. This document details how solution.

CEN and/or other entities may define additional sets of data in the
same functionality (and
even more) can be accomplished using Internet protocols 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 SIP. attaching it to an INVITE as a data block. The
goal block
is identified by its MIME content-type, and pointed to re-use existing specifications by a CID URL
in a Call-Info header with a 'purpose' parameter value corresponding
to the area block.

1.1. Overview of SIP-based Current Deployment Models

Current (circuit-switched or legacy) systems for placing emergency calling.

This document
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 organized as follows: Section 2 defines a three-way voice call between the
terminology, Section 3 describes how vehicle, the required functionality can
be accomplished by combining several already existing standards,
TSP, and
Section 4 shows 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 example message exchange. This document concludes emergency call with the security considerations in Section 5 PSAP and IANA considerations then
communicates location data to the PSAP via text-to-speech; crash data
is not conveyed.

++
///----\\\ || 911 voice call via handset +------+
||| IVS |||--->|+----------------------------------->+ PSAP |
\\\----/// ++ +------+

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 Section 6. Appendix A illustrates 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.

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

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 map the functionality in 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 document 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 eCall Minimum Set of Data (MSD) specified same
mechanism as for
mobile circuit switched voice. 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 [1].

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

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

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]), [3]), Circle (see Section 5.2.3
of [2]), [3]), and Ellipsoid (see Section 5.2.7 of [2]). [3]). The coordinate
reference systems (CRS) specified in [2] [3] are also mandatory for this
document. The <direction> element, as defined in [3] [6] 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] [6] MUST be implemented and MAY be included.

This specification also inherits the ability to utilize test call
functionality from Section 15 of [4].

4. Example

Figure 1 7 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.

+-------+
| PSAP3 |
+-------+

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

The example, shown in Figure 2, 8, 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: 8: SIP INVITE indicating an In-Vehicular Emergency Call

5. Security Considerations

This document does not raise security considerations beyond those
described in [10]. [12]. 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] [13] 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 [5]. [10].

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 [8] and guidelines in RFC
3023 [7].

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

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 [9] 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 with [9].

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

[3]

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

[4] Rosen, B.

[7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001.

[8] Freed, N. 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 Klensin, "Media Type Specifications and Other Well-Known Services",
Registration Procedures", RFC 5031, January 2008.

[6] 4288, December 2005.

[9] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy,
"Additional Data related to an Emergency Call",
draft-ietf-ecrit-additional-data-06 draft-
ietf-ecrit-additional-data-09 (work in progress),
February May
2013.

[7] Peterson, J.,

[10] Schulzrinne, H., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.

[8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance Uniform Resource Name (URN) for
the Session Initiation Protocol",
Emergency and Other Well-Known Services", RFC 6442, December 2011. 5031,
January 2008.

9.2. Informative references

[9]

[11] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.

[10]

[12] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069, January
2008.

[11]

[13] Tschofenig, H., Schulzrinne, H., and B. Aboba,
"Trustworthy Location", draft-ietf-ecrit-trustworthy-location-04 draft-ietf-ecrit-trustworthy-
location-05 (work in progress), October 2012.

[12] CEN, "Intelligent transport systems - eSafety - eCall minimum
set of data (MSD), EN 15722", June 2011.

[13] March 2013.

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

[15] 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)

[12]

[15] 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, 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-designed mechanisms. SIP mechanisms
standardized for emergency call handling. Any voice, video, or real-text real-
text communication will be negotiated using the Session Description
Protocol (SDP), as shown in Figure 2, 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 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 inside the additional data XML structure
[9]. 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.

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 <timed-presence>, defined in RFC 4481
[13].

Number of Passengers: Minimum known number of fastened seatbelts.
[Editor's Note: Description to be added.]
[14].

Additional Data: [6] [9] 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
the additional data structure [9] 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

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