--- 1/draft-ietf-ecrit-car-crash-20.txt 2017-01-11 01:13:10.150384383 -0800 +++ 2/draft-ietf-ecrit-car-crash-21.txt 2017-01-11 01:13:10.238386480 -0800 @@ -1,21 +1,21 @@ ECRIT R. Gellens Internet-Draft Core Technology Consulting Intended status: Standards Track B. Rosen -Expires: June 18, 2017 NeuStar, Inc. +Expires: July 15, 2017 NeuStar, Inc. H. Tschofenig Individual - December 15, 2016 + January 11, 2017 Next-Generation Vehicle-Initiated Emergency Calls - draft-ietf-ecrit-car-crash-20.txt + draft-ietf-ecrit-car-crash-21.txt Abstract This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the @@ -26,52 +26,52 @@ Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash) and a SIP INFO package to enable carrying this and related data in SIP INFO requests. An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). - However, this document specifies a different set of vehicle (crash) - data, specifically, the Vehicle Emergency Data Set (VEDS) rather than - the eCall Minimum Set of Data (MSD). This document is an extension - of the eCall document, with the primary differences being that this - document makes the MSD data set optional and VEDS mandatory, and adds - attribute values to the metadata/control object to permit greater - functionality. This document registers a new SIP INFO package - (identical to that registered for eCall but with the addition of the - VEDS MIME type). This document also describes legacy (circuit- - switched) ACN systems and their migration to next-generation + However, this document specifies use of a different set of vehicle + (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) + rather than the eCall Minimum Set of Data (MSD). This document is an + extension of the IETF eCall document, with the primary differences + being that this document makes the MSD data set optional and VEDS + mandatory, and adds attribute values to the metadata/control object + to permit greater functionality. This document registers a new SIP + INFO package (identical to that registered for eCall but with the + addition of the VEDS MIME type). This document also describes legacy + (circuit-switched) ACN systems and their migration to next-generation emergency calling, to provide background information and context. 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 June 18, 2017. + This Internet-Draft will expire on July 15, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 @@ -101,45 +101,45 @@ 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 28 14.2. Registration of the 'VEDS' entry in the Emergency Call Data Types registry . . . . . . . . . . . . . . . . . . 30 14.3. New Action Values . . . . . . . . . . . . . . . . . . . 30 14.4. Emergency Call Static Message Registry . . . . . . . . . 30 14.5. Emergency Call Vehicle Lamp ID Registry . . . . . . . . 31 14.6. Lamp State Registry . . . . . . . . . . . . . . . . . . 32 14.7. Emergency Call Vehicle Camera ID Registry . . . . . . . 33 14.8. The emergencyCallData.eCall.VEDS SIP INFO package . . . 34 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 - 16. Changes from Previous Versions . . . . . . . . . . . . . . . 37 - 16.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 37 + 16. Changes from Previous Versions . . . . . . . . . . . . . . . 38 + 16.1. Changes from draft-ietf-18 to draft-ietf-19 . . . . . . 38 16.2. Changes from draft-ietf-17 to draft-ietf-18 . . . . . . 38 16.3. Changes from draft-ietf-16 to draft-ietf-17 . . . . . . 38 16.4. Changes from draft-ietf-14 to draft-ietf-15 . . . . . . 38 16.5. Changes from draft-ietf-13 to draft-ietf-14 . . . . . . 38 16.6. Changes from draft-ietf-11 to draft-ietf-13 . . . . . . 38 16.7. Changes from draft-ietf-10 to draft-ietf-11 . . . . . . 38 16.8. Changes from draft-ietf-09 to draft-ietf-10 . . . . . . 38 16.9. Changes from draft-ietf-08 to draft-ietf-09 . . . . . . 39 16.10. Changes from draft-ietf-07 to draft-ietf-08 . . . . . . 39 16.11. Changes from draft-ietf-06 to draft-ietf-07 . . . . . . 39 16.12. Changes from draft-ietf-05 to draft-ietf-06 . . . . . . 39 16.13. Changes from draft-ietf-04 to draft-ietf-05 . . . . . . 39 16.14. Changes from draft-ietf-03 to draft-ietf-04 . . . . . . 39 - 16.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 + 16.15. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 40 16.16. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 40 16.17. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 16.18. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 40 16.19. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 16.20. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 - 17.1. Normative References . . . . . . . . . . . . . . . . . . 40 - 17.2. Informative references . . . . . . . . . . . . . . . . . 41 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 + 17.1. Normative References . . . . . . . . . . . . . . . . . . 41 + 17.2. Informative references . . . . . . . . . . . . . . . . . 42 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. 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: @@ -269,27 +269,27 @@ emergency calls are used to provide the realization of next- generation ACN. Although this specification is designed with the requirements for North America ACN in mind (and both APCO and NENA are based in the U.S.), it is specified generically such that the technology can be re-used or extended to suit requirements in other regions. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe), as described in - [I-D.ietf-ecrit-ecall]. However, this document specifies a different - set of vehicle (crash) data, specifically, the Vehicle Emergency Data - Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This - document is an extension of [I-D.ietf-ecrit-ecall], with the - differences being that this document makes the MSD data set optional - and VEDS mandatory, and adds new attribute values to the metadata/ - control object defined in that document. This document also + [I-D.ietf-ecrit-ecall]. However, this document specifies use of a + different set of vehicle (crash) data, specifically, the Vehicle + Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data + (MSD). This document is an extension of [I-D.ietf-ecrit-ecall], with + the differences being that this document makes the MSD data set + optional and VEDS mandatory, and adds new attribute values to the + metadata/control object defined in that document. This document also registers a new SIP INFO package (identical to that defined in [I-D.ietf-ecrit-ecall] with the addition of the VEDS MIME type). This document registers the 'application/EmergencyCallData.VEDS+xml' MIME media type, registers the 'VEDS' entry in the Emergency Call Data Types registry, and registers a SIP INFO package to enable carrying this and related data in SIP INFO requests. Section 6 introduces VEDS. Section 7 describes how VEDS data and metadata/control blocks are transported within NG-ACN calls. @@ -372,30 +372,30 @@ between the vehicle, the TSP, and the PSAP, allowing communication between the PSAP call taker, the TSP call taker, and the vehicle occupants (who might be unconscious). ///----\\\ proprietary +------+ 911 trunk or POTS +------+ ||| IVS |||-------------->+ TSP +------------------->+ PSAP | \\\----/// crash data +------+ location via trunk +------+ Figure 1: Legacy TSP Model. - In the paired model, the IVS uses a Bluetooth link with a previously- - paired handset to establish an emergency call with the PSAP (by - dialing a standard emergency number; 9-1-1 in North America), and - then communicates location data to the PSAP via text-to-speech; crash - data might or might not be conveyed also using text-to-speech. Some - such systems use an automated voice prompt menu for the PSAP call - taker (e.g., "this is an automatic emergency call from a vehicle; - press 1 to open a voice path to the vehicle; press 2 to hear the - location read out") to allow the call taker to request location data - via text-to-speech. + In the paired model, the IVS uses a local link (typically Bluetooth + [Bluetooth]) with a previously-paired handset to establish an + emergency call with the PSAP (by dialing a standard emergency number; + 9-1-1 in North America), and then communicates location data to the + PSAP via text-to-speech; crash data might or might not be conveyed + also using text-to-speech. Some such systems use an automated voice + prompt menu for the PSAP call taker (e.g., "this is an automatic + emergency call from a vehicle; press 1 to open a voice path to the + vehicle; press 2 to hear the location read out") to allow the call + taker to request location data via text-to-speech. +---+ ///----\\\ | H | 911/etc voice call via handset +------+ ||| IVS |||-->| S +----------------------------------->+ PSAP | \\\----/// +---+ location via text-to-speech +------+ Figure 2: Legacy Paired Model In the direct model, the IVS directly places an emergency call with the PSAP by dialing a standard emergency number (9-1-1 in North @@ -587,22 +587,22 @@ subtype starting with 'EmergencyCallData.' * If the data format is XML, then by convention the name has a suffix of '+xml' o The item is registered in the Emergency Call Data Types registry, as defined in Section 11.1.9 of [RFC7852] * For emergency-call-specific formats, the registered name is the root of the MIME media type (not including the 'EmergencyCallData' prefix and any suffix such as '+xml') as described in Section 4.1 of [RFC7852]. - o A new SIP INFO package is registered that permits carrying the the - new media type, the metadata/control object (defined in + o A new SIP INFO package is registered that permits carrying the new + media type, the metadata/control object (defined in [I-D.ietf-ecrit-ecall]), and for compatibility, the MSD and VEDS objects, in SIP INFO requests. 7. Data Transport [RFC7852] establishes a general mechanism for including blocks of data within a SIP emergency call. This document makes use of that mechanism. This document also registers a SIP INFO package (in Section 14.8) to enable NG-ACN related data blocks to be carried in SIP INFO requests (per [RFC6086], new SIP INFO method usages require @@ -829,21 +829,22 @@ rear, brake, brake-center, position-front, position-rear, turn- left, turn-right, and hazard. A registry of lamp states is defined in Section 14.6. The initial values (listed in Table 5) are "on", "off", and "flash". enable-camera adds a one-way media stream (established via SIP re- INVITE sent by the vehicle) to enable the PSAP call taker to view a feed from a camera. A registry of camera identification values is defined in Section 14.7. The initial values (listed in Table 6) are backup, left-rear, right-rear, forward, rear-wide, - lane, interior, and night-front. + lane, interior, night-front, night-rear, night-left, and night- + right. Note that there is no 'request' action to play dynamic media (such as an audio message). The PSAP can send a SIP re-INVITE to establish a one-way media stream for this purpose. 9.2. Request Example @@ -1409,23 +1410,23 @@ determined by the registrant; IANA assigns the IDs. Each message is assigned a consecutive integer value as its ID. This allows an IVS to indicate by a single integer value that it supports all messages with that value or lower. The initial set of values is listed in Table 3. +----+--------------------------------------------------------------+ | ID | Message | +----+--------------------------------------------------------------+ - | 1 | Emergency services has noted your information and location, | - | | but cannot speak with you right now. We will help you as | - | | soon as possible. | + | 1 | Emergency services has received your information and | + | | location, but cannot speak with you right now. We will get | + | | help to you as soon as possible. | +----+--------------------------------------------------------------+ Table 3: Emergency Call Static Message Registry Initial Values 14.5. Emergency Call Vehicle Lamp ID Registry This document creates a new sub-registry called "Emergency Call Vehicle Lamp ID" in the "Emergency Call Metadata/Control Data" registry established by [I-D.ietf-ecrit-ecall]. This new sub- registry uniquely identifies the names of automotive lamps (lights). @@ -1543,20 +1544,28 @@ | | collision detection systems), separate from backup | | | view | | | | | lane | Used by systems to identify road lane and/or | | | monitor vehicle's position within lane | | | | | interior | Shows the interior (e.g., driver) | | | | | night-front | Night-vision view of what is in front of the | | | vehicle | + | | | + | night-rear | Night-vision view of what is behind the vehicle | + | | | + | night-left | Night-vision view of what is to the left of the | + | | vehicle | + | | | + | night-right | Night-vision view of what is to the right of the | + | | vehicle | +-------------+-----------------------------------------------------+ Table 6: Emergency Call Vehicle Camera ID Registry Initial Values 14.8. The emergencyCallData.eCall.VEDS SIP INFO package This document registers the 'emergencyCallData.eCall.VEDS' SIP INFO package. Both endpoints (the IVS and the PSAP equipment) include @@ -1605,28 +1614,29 @@ needs to be sent mid-call. While the SIP MESSAGE method could be used, it is not tied to a SIP dialog as is the INFO method and thus might not be associated with the dialog. Both the SIP OPTIONS or re- INVITE methods could also be used, but is seen as less clean than the INFO method. The SIP SUBSCRIBE/NOTIFY method could be coerced into service, but the semantics are not a good fit, e.g., the subscribe/ notify mechanism provides one-way communication consisting of (often multiple) notifications from notifier to subscriber indicating that certain events in notifier have occurred, whereas what's needed here is two-way communication of data related to the emergency dialog. + Use of the media plane mechanisms was discounted because the number of messages needing to be exchanged in a dialog is normally zero or very few, and the size of the data is likewise very small. The overhead caused by user plane setup (e.g., to use MSRP as transport) would be disproportionately large. - Based on the the analyses, the SIP INFO method was chosen to provide - for mid-call data transport. + Based on the analyses, the SIP INFO method was chosen to provide for + mid-call data transport. 14.8.3. Info Package Name The SIP INFO package name is emergencyCallData.eCall.VEDS 14.8.4. Info Package Parameters None 14.8.5. SIP Option-Tags @@ -1694,29 +1704,31 @@ See [TBD: THIS DOCUMENT] for protocol details. 14.8.11. Examples See [TBD: THIS DOCUMENT] for protocol examples. 15. Acknowledgements We would like to thank Lena Chaponniere, Alissa Cooper, Stephen Edge, - Christer Holmberg, and Allison Mankin for their review and - suggestions; Robert Sparks and Paul Kyzivat for their help with the - SIP mechanisms; Michael Montag, Arnoud van Wijk, Ban Al-Bakri, Wes - George, Gunnar Hellstrom, and Rex Buddenberg for their feedback; and - Ulrich Dietz for his help with earlier versions of the original + Christer Holmberg, Allison Mankin, and Dan Romascanu for their review + and suggestions; Robert Sparks and Paul Kyzivat for their help with + the SIP mechanisms; Michael Montag, Arnoud van Wijk, Ban Al-Bakri, + Wes George, Gunnar Hellstrom, and Rex Buddenberg for their feedback; + and Ulrich Dietz for his help with earlier versions of the original version of this document. 16. Changes from Previous Versions + RFC Editor: Please remove this section prior to publication. + 16.1. Changes from draft-ietf-18 to draft-ietf-19 o Fixed various nits 16.2. Changes from draft-ietf-17 to draft-ietf-18 o Added additional text to "Rate of Info Requests" o Further corrected "content type" to "media type" 16.3. Changes from draft-ietf-16 to draft-ietf-17 @@ -1835,27 +1847,26 @@ [RFC7852] 16.20. Changes from draft-gellens-00 to -01 o Now using 'EmergencyCallData' for purpose parameter values and MIME subtypes, in accordance with changes to [RFC7852] o Added reference to RFC 6443 o Fixed bug that caused Figure captions to not appear 17. References - 17.1. Normative References [I-D.ietf-ecrit-ecall] Gellens, R. and H. Tschofenig, "Next-Generation Pan- - European eCall", draft-ietf-ecrit-ecall-20 (work in - progress), November 2016. + European eCall", draft-ietf-ecrit-ecall-21 (work in + progress), December 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . @@ -1885,20 +1896,25 @@ . [VEDS] Advanced Automatic Crash Notification (AACN) Joint APCO/ NENA Data Standardization Workgroup, , "Vehicular Emergency Data Set (VEDS) version 3", July 2012, . 17.2. Informative references + [Bluetooth] + Bluetooth Special Interest Group, , "Bluetooth + Specifications", . + [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, DOI 10.17487/RFC5012, January 2008, . [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, DOI 10.17487/RFC5069, January 2008, .