Internet Protocol-based In-Vehicle Emergency Call
draft-rosen-ecrit-ecall-07

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 <direction> 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 <heading> 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: <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: ...

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

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 <timed-presence>, 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]