ECRIT B. Rosen
Internet-Draft NeuStar, Inc.
Intended status: Informational H. Tschofenig
Expires: September 8, 2009 Nokia Siemens Networks
U. Dietz
Vodafone
March 7, 2009
Best Current Practice for IP-based In-Vehicle Emergency Calls
draft-rosen-ecrit-ecall-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Rosen, et al. Expires September 8, 2009 [Page 1]
Internet-Draft In-Vehicle Emergency Call March 2009
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Profile . . . . . . . . . . . . . . . . . . . . . . . 5
4. Data Profile . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . 15
10.2. Informative references . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Rosen, et al. Expires September 8, 2009 [Page 2]
Internet-Draft In-Vehicle Emergency Call March 2009
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. The current specifications
being developed to offer the eCall solution are defined to work with
circuit switched telephony. This document details how the same
functionality can be accomplished using IP-based mechanisms. Since
cellular systems are being enhanced with IP-based infrastructure this
document complements the ambiguous goal to provide widespread
availability of in-vehicular emergency services solutions.
This document is organized as follows: Section 2 defines the
terminology, Section 3 illustrates the required protocol
functionality, Section 4 indicates the required data that has to be
transmitted within a PIDF-LO and Section 5 shows an example message
exchange. This document concludes with the security considerations
in Section 6 and IANA considerations in Section 7.
Rosen, et al. Expires September 8, 2009 [Page 3]
Internet-Draft In-Vehicle Emergency Call March 2009
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 a lot of the terminology defined in Section 3
of [9].
Rosen, et al. Expires September 8, 2009 [Page 4]
Internet-Draft In-Vehicle Emergency Call March 2009
3. Protocol Profile
The usage of in-vehicular emergency calls does not require the usage
of a Location Configuration Protocol since GPS is used. Furthermore,
since the GPS receiver is permanently turned on it can even provide
useful information in cases where the car entered a tunnel.
Consequently, there is no need to discover any LIS.
Since the emergency call within the car is either triggered by a
button or, in most cases, automatically thanks to sensors mounted in
the car there is no need to learn a dial string. This document
registers a separate Service URN, namely 'urn:service:ecall', used
specifically for emergency calls that are triggered by vehicles.
The following list provides information about the sections and
requires of [2] that are relevant to this specification:
Identifying an emergency call: Emergency calls are detected at the
end point, i.e., by the vehicle, and the Service URN
'urn:service:ecall' MUST be implemented by the end point and
recognized by the VSP. The requirements listed in Section 5 of
[2] are therefore irrelevant to this specification, as they deal
with identifying an emergency call based on dial strings.
Location: The encoding of the PIDF-LO [3] is described in Section 4.
In an emergency, the end point adds the available location
information to the initial SIP INVITE emergency call message. In
special cases a location update may be provided, using the
procedure described in requirement ED-38 of Section 6.8 of [2];
all other aspects of Section 6.8 from that document are not
applicable to this specification. Section 6.2.1, 6.2.2, 6.2.4,
6.4, 6.5 and 6.6 of [2] are not applicable to this document. For
location conveyance in SIP [4] MUST be used. Further aspects that
are not relevant for this document are multiple locations (Section
6.9 of [2]), location validation (Section 6.10 of [2]), default
location (Section 6.11 of [2])
LoST: Emergency call routing support, for example utilizing LoST, is
provided by VSP. As such, the description in Section 8 of [2] is
applicable to this document, except for requirement SP-25 and
SP-26 regarding legacy devices.
Signaling of emergency calls: Section 9 of [2] is applicable to this
document with the following exception: ED-60/AN-25 is not
applicable as HELD is not used. Video and real-time text may be
supported by end device in the future, although currently not
envisioned. The corresponding text paragraphs are relevant from
Section 9 of [2] when support is being provided. Additionally,
Rosen, et al. Expires September 8, 2009 [Page 5]
Internet-Draft In-Vehicle Emergency Call March 2009
ED-62 dealing with "SIP signaling requirements for User Agents" is
simplified as follows. The initial SIP signaling method is an
INVITE request with the following setting:
1. The Request URI MUST be the service URN 'urn:service:ecall'.
2. The To header MUST be a service URN 'urn:service:ecall'.
3. The From header MUST be present and SHOULD be the AoR of the
caller.
4. A Via header MUST be present.
5. A Contact header MUST be present which MUST be globally
routable to permit an immediate call-back to the specific
device which placed the emergency call.
6. Other headers MAY be included as per normal SIP behavior.
7. A Supported header MUST be included with the 'geolocation'
option tag [4].
8. The device MUST include location by-value into the call.
9. A normal SDP offer SHOULD be included in the INVITE. If
voice is supported the offer SHOULD include the G.711 codec,
if a voice channel can be established based on the equipment
in the car.
10. If the device includes location-by-value, the UA MUST support
multipart message bodies, since SDP will likely be also in
the INVITE.
11. The UAC MUST include a "inserted-by=endpoint" header
parameter on all Geolocation headers. This informs
downstream elements which device entered the location at this
URI (either cid-URL or location-by-reference URI).
12. SIP Caller Preferences [5] MAY be used to signal how the PSAP
should handle the call. For example, a language preference
expressed in an Accept-Language header may be used as a hint
to cause the PSAP to route the call to a call taker who
speaks the requested language. SIP Caller Preferences may
also be used to indicate a need to invoke a relay service for
communication with people with disabilities in the call.
Rosen, et al. Expires September 8, 2009 [Page 6]
Internet-Draft In-Vehicle Emergency Call March 2009
Call backs: The description in Section 10 of [2] is relevant for
this document.
Mid-call behavior: The description in Section 11 of [2] is fully
applicable to this document.
Call termination: The description in Section 12 of [2] is fully
applicable to this document.
Disabling of features: The description in Section 13 of [2] is fully
applicable to this document.
Media: Real-time text and video may be supported in devices some
time in the future. If voice calls are supported then the
description in Section 14 is applicable to this document.
Testing: The description in Section 15 of [2] is fully applicable to
this document.
Rosen, et al. Expires September 8, 2009 [Page 7]
Internet-Draft In-Vehicle Emergency Call March 2009
4. Data Profile
Due to the requirement for a built-in GPS receiver only geodetic
location information will be sent within an emergency call.
Furthermore, the number of location shapes is is restricted. Hence,
the following location shapes of [6] MUST be implemented: 2d and 3d
Point (see Section 5.2.1 of [6]), Circle (see Section 5.2.3 of [6]),
and Ellipsoid (see Section 5.2.7 of [6]). The coordinate reference
systems (CRS) specified in [6] are also mandatory for this document.
Furthermore, the direction of travel of the vehicle is important for
dispatch and hence it MUST be included in the PIDF-LO. The <bearing>
element specified in [7] MUST be supported.
Rosen, et al. Expires September 8, 2009 [Page 8]
Internet-Draft In-Vehicle Emergency Call March 2009
5. 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:ecall' service URN and the PSAP of the VoIP provider
determines which PSAP to contact based on the provided location
information. As shown in the figure, this route determination may be
based on LoST. Then, 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 |
| Servers|
+--------+
^ +-------+
| | PSAP2 |
| +-------+
v
+-------+ +------+ +-------+
Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker
+-------+ +------+ +-------+
+-------+
| PSAP3 |
+-------+
Figure 1: Example of In-Vehicular Emergency Call Message Flow
The following example, in Figure 2, shows location information
encoded in a PIDF-LO that is being conveyed in such an emergency
call.
Rosen, et al. Expires September 8, 2009 [Page 9]
Internet-Draft In-Vehicle Emergency Call March 2009
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
entity="pres:vehicle-identification@example.com">
<device id="123">
<gp:geopriv>
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
<gml:bearing>
<gml:DirectionVector>
<gml:vector> 270.0 -60.0</gml:vector>
</gml:DirectionVector>
</gml:bearing>
</gp:location-info>
<gp:usage-rules/>
<method>GPS</method>
</gp:geopriv>
</device>
</presence>
Figure 2: Example of In-Vehicular Emergency Call Message Flow
Rosen, et al. Expires September 8, 2009 [Page 10]
Internet-Draft In-Vehicle Emergency Call March 2009
6. 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 September 8, 2009 [Page 11]
Internet-Draft In-Vehicle Emergency Call March 2009
7. IANA Considerations
IANA is requested to register the URN 'urn:service:ecall' under the
sub-services 'sos' registry defined in Section 4.2 of [8].
urn:service:ecall This service identifier reaches a public safety
answering point (PSAP), which in turn dispatches aid appropriate
to the emergency related to accidents of vehicles.
Rosen, et al. Expires September 8, 2009 [Page 12]
Internet-Draft In-Vehicle Emergency Call March 2009
8. Acknowledgements
We would like to thank Michael Montag for his feedback.
Rosen, et al. Expires September 8, 2009 [Page 13]
Internet-Draft In-Vehicle Emergency Call March 2009
9. Open Issues
While working on this document a few aspects where discovered that
require further discussion:
o Today's work on the eCall system does not necessarily require a
voice call to be established; a voice call may be established
whenever possible by the functionality offered by the device.
From a protocol mechanims, however, the design for establishing an
emergency call including voice and without voice support are
somewhat different. Further discussion on the design aspects are
needed to align this aspect.
o This document currently defines a new service URN to differentiate
it from ordinary calls as in-vehicular emergency calls are, in
some countries, routed to different PSAPs than regular emergency
calls. More thoughts are needed to determine whether this is the
best approach.
o The current version of the document assumes the usage of LoST at
the VSP to perform call routing of the in-vehicular emergency
call. This is useful when there are no dial strings need to be
learned nor any other service URNs need to be discovered. Further
discussion is needed whether additional service URNs might be made
available to the vehicle, for example to request roadside
assistance or similar services. In that case the option might be
provided to run LoST at the end host as well as on the VSP.
Rosen, et al. Expires September 8, 2009 [Page 14]
Internet-Draft In-Vehicle Emergency Call March 2009
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-08 (work in progress), February 2009.
[3] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[4] Polk, J. and B. Rosen, "Location Conveyance for the Session
Initiation Protocol", draft-ietf-sip-location-conveyance-12
(work in progress), November 2008.
[5] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[6] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", draft-ietf-geopriv-pdif-lo-profile-14 (work
in progress), November 2008.
[7] Vishal, S., Schulzrinne, H., and H. Tschofenig, "Dynamic
Feature Extensions to the Presence Information Data Format
Location Object (PIDF-LO)",
draft-singh-geopriv-pidf-lo-dynamic-04 (work in progress),
October 2008.
[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
10.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. and H. Schulzrinne, "Trustworthy Location
Information", draft-tschofenig-ecrit-trustworthy-location-01
Rosen, et al. Expires September 8, 2009 [Page 15]
Internet-Draft In-Vehicle Emergency Call March 2009
(work in progress), March 2009.
Rosen, et al. Expires September 8, 2009 [Page 16]
Internet-Draft In-Vehicle Emergency Call March 2009
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
Ulrich Dietz
Vodafone
Chiemgaustrasse 116
Munich 81549
Germany
Email: Ulrich.Dietz@vodafone.com
Rosen, et al. Expires September 8, 2009 [Page 17]