idnits 2.17.1 draft-ietf-ecrit-car-crash-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6881], [I-D.ietf-ecrit-ecall], [RFC6443]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 7, 2015) is 3335 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5031' is defined on line 943, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-ecrit-additional-data-24 ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT R. Gellens 3 Internet-Draft Qualcomm Technologies, Inc 4 Intended status: Informational B. Rosen 5 Expires: September 8, 2015 NeuStar, Inc. 6 H. Tschofenig 7 (no affiliation) 8 March 7, 2015 10 Next-Generation Vehicle-Initiated Emergency Calls 11 draft-ietf-ecrit-car-crash-02.txt 13 Abstract 15 This document describes how to use IP-based emergency services 16 mechanisms to support the next generation of emergency calls placed 17 by vehicles (automatically in the event of a crash or serious 18 incident, or manually invoked by a vehicle occupant) and conveying 19 vehicle, sensor, and location data related to the crash or incident. 20 Such calls are often referred to as "Automatic Crash Notification" 21 (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the 22 case of manual trigger. The "Advanced" qualifier refers to the 23 ability to carry a richer set of data. 25 This document also registers a MIME Content Type and an Emergency 26 Call Additional Data Block for the vehicle, sensor, and location data 27 (often referred to as "crash data" even though there is not 28 necessarily a crash). An external specification for the data format, 29 contents, and structure are referenced in this document. 31 Profiling and simplifications of the general emergency call 32 mechanism, as described in [RFC6443] and [RFC6881], are possible due 33 to the nature of the functionality that is provided in vehicles such 34 as the usage of Global Satellite Navigation System (GNSS). 36 This document reuses the technical aspects of next-generation pan- 37 European eCall (a mandated and standardized system for emergency 38 calls by in-vehicle systems within Europe and other regions), as 39 described in [I-D.ietf-ecrit-ecall]. However, this document 40 specifies a different set of vehicle (crash) data, specifically, the 41 Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set 42 of Data (MSD). 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on September 8, 2015. 61 Copyright Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 3. Overview of Current Deployment Models . . . . . . . . . . . . 7 81 4. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8 82 5. Migration to Next-Generation . . . . . . . . . . . . . . . . 9 83 6. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 7. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 8. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 90 12.1. MIME Content-type Registration for 91 'application/EmergencyCall.VEDS+xml' . . . . . . . . . . 18 92 12.2. Registration of the 'VEDS' entry in the Emergency Call 93 Additional Data registry . . . . . . . . . . . . . . . . 19 94 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 95 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 96 15. Changes from Previous Versions . . . . . . . . . . . . . . . 19 97 15.1. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 19 98 15.2. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 19 99 15.3. Changes from draft-gellens-02 to draft-ietf-00 . . . . . 20 100 15.4. Changes from draft-gellens-01 to -02 . . . . . . . . . . 20 101 15.5. Changes from draft-gellens-00 to -01 . . . . . . . . . . 20 102 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 16.1. Normative References . . . . . . . . . . . . . . . . . . 20 104 16.2. Informative references . . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 This document re-uses terminology defined in Section 3 of [RFC5012]. 115 Additionally, we use the following abbreviations: 117 +--------+----------------------------------------------------------+ 118 | Term | Expansion | 119 +--------+----------------------------------------------------------+ 120 | 3GPP | 3rd Generation Partnership Project | 121 | AACN | Advanced Automatic Crash Notification | 122 | ACN | Automatic Crash Notification | 123 | APCO | Association of Public-Safety Communications Officials | 124 | EENA | European Emergency Number Association | 125 | ESInet | Emergency Services IP network | 126 | GNSS | Global Satellite Navigation System (which includes the | 127 | | various such systems including the Global Positioning | 128 | | System or GPS) | 129 | IVS | In-Vehicle System | 130 | MNO | Mobile Network Operator | 131 | NENA | National Emergency Number Association | 132 | TSP | Telematics Service Provider | 133 | VEDS | Vehicle Emergency Data Set | 134 +--------+----------------------------------------------------------+ 136 2. Introduction 138 Emergency calls made by in-vehicle systems (e.g., in the event of a 139 crash) assist in significantly reducing road deaths and injuries by 140 allowing emergency services to respond quickly and often with better 141 location. 143 Drivers often have a poor location awareness, especially outside of 144 major cities, at night and when away from home (especially abroad). 146 In the most crucial cases, the victim(s) may not be able to call 147 because they have been injured or trapped. 149 For more than a decade, some vehicles have been equipped with 150 telematics systems that, among other features, place an emergency 151 call automatically in the event of a crash or manually in response to 152 an emergency call button. Such systems generally have on-board 153 location determination systems that make use of satellite-based 154 positioning technology, inertial sensors, gyroscopes, etc., to 155 provide a fairly accurate position for the vehicle. Such built-in 156 systems can take advantage of the benefits of being integrated into a 157 vehicle, such as more reliable power, ability to have larger or 158 specialized antenna, ability to be engineered to avoid or minimise 159 degradation by vehicle glass coatings, interference from other 160 vehicle systems, etc. Thus, the PSAP can be provided with a good 161 estimate of where the vehicle is during an emergency. Vehicle 162 manufacturers are increasingly adopting such systems, both for the 163 safety benefits and for the additional features and services they 164 enable (e.g., remote engine diagnostics, remote door unlock, stolen 165 vehicle tracking and disabling, etc.). 167 The general term for such systems is Automatic Crash Notification 168 (ACN) or "Advanced Automatic Crash Notification" (AACN). "ACN" is 169 used in this document as a general term. ACN systems transmit some 170 amount of data specific to the incident, referred to generally as 171 "crash data" (the term is commonly used even though there might not 172 have been a crash). While different systems transmit different 173 amounts of crash data, standardized formats, structures, and 174 mechanisms are needed to provide interoperability among systems and 175 PSAPs. 177 Currently deployed in-vehicle telematics systems are circuit-switched 178 and lack a standards-based ability to convey crash data directly to 179 the PSAP (generally relying on either a human call taker or an 180 automated system to provide the PSAP call taker with some crash data 181 orally, or possibly a proprietary mechanism). The PSAP call taker 182 needs to first realize that the call is related to a vehicle 183 incident, and in most cases must then listen to the data and 184 transcribe it. 186 The transition to next-generation calling in general, and emergency 187 calling in particular, provides an opportunity to vastly improve the 188 scope, breadth, reliability and usefulness of crash data during an 189 emergency by allowing it to be presented alongside the call, and to 190 be automatically processed by the PSAP and made available to the call 191 taker in an integrated, automated way. In addition, vehicle 192 manufacturers are provided an opportunity to take advantage of the 193 same standardized mechanisms for data transmission for internal use 194 if they wish (such as telemetry between the vehicle and a service 195 center for both emergency and non-emergency uses, including location- 196 based services, multi-media entertainment systems, and road-side 197 assistance applications). 199 Next-generation ACN provides an opportunity for such calls to be 200 recognized and processed as such during call set-up, and optionally 201 routed to an upgraded PSAP where the vehicle data is available to 202 assist the call taker in assessing and responding to the situation. 204 An ACN call may be either occupant-initiated or automatically 205 triggered. (The "A" in "ACN" does stand for "Automatic," but the 206 term is often used to refer to the class of calls that are placed by 207 an in-vehicle system (IVS) and that carry incident-related data as 208 well as voice.) Automatically triggered calls indicate a car crash 209 or some other serious incident (e.g., a fire) and carry a greater 210 presumption of risk of injury. Manually triggered calls are often 211 reports of serious hazards (such as drunk drivers) and may require 212 different responses depending on the situation. Manually triggered 213 calls are also more likely to be false (e.g., accidental) calls and 214 may thus be subject to different handling by the PSAP. 216 This document describes how the IETF mechanisms for IP-based 217 emergency calls, including [RFC6443] and 218 [I-D.ietf-ecrit-additional-data], are used to provide the realization 219 of next-generation ACN. 221 The Association of Public-Safety Communications Officials (APCO) and 222 the National Emergency Number Association (NENA) have jointly 223 developed a standardized set of incident-related vehicle data for ACN 224 use, called the Vehicle Emergency Data Set (VEDS) [VEDS]. Such data 225 is often referred to as crash data although it is applicable in 226 incidents other than crashes. 228 VEDS provides a standard data set for the transmission, exchange, and 229 interpretation of vehicle-related data. A standard data format 230 allows the data to be generated by an IVS, and interpreted by PSAPs, 231 emergency responders, and medical facilities (including those capable 232 of providing trauma level patient care). It includes incident- 233 related information such as airbag deployment, location of the 234 vehicle, if the vehicle was involved in a rollover, various sensor 235 data that can indicate the potential severity of the crash and the 236 likelihood of severe injuries to the vehicle occupants, etc. This 237 data better informs the PSAP and emergency responders as to the type 238 of response that may be needed. This information was recently 239 included in the federal guidelines for field triage of injured 240 patients. These guidelines are designed to help responders at the 241 accident scene identify the potential existence of severe internal 242 injuries and to make critical decisions about how and where a patient 243 needs to be transported. 245 This document registers the 'application/EmergencyCallData.VEDS+xml' 246 MIME content-type, and registers the 'VEDS' entry in the Emergency 247 Call Additional Data registry. 249 VEDS is an XML structure (see [VEDS]). The 'application/ 250 EmergencyCallData.VEDS+xml' MIME content-type is used to identify it. 251 The 'VEDS' entry in the Emergency Call Additional Data registry is 252 used to construct a 'purpose' parameter value for conveying VEDS data 253 in a Call-Info header (as described in 254 [I-D.ietf-ecrit-additional-data]). 256 VEDS is a versatile structure that can accomodate varied needs. 257 However, if additional sets of data are determined to be needed 258 (e.g., in the future or in different regions), the steps to enable 259 each data block are very briefly summarized below: 261 o A standardized format and encoding (such as XML) is defined and 262 published by a Standards Development Organization (SDO). 264 o A MIME Content-Type is registered for it (typically under the 265 'Application' media type and with a sub-type starting with 266 'EmergencyCallData.'). 268 o An entry for the block is added to the Emergency Call Additional 269 Data Blocks sub-registry (established by 270 [I-D.ietf-ecrit-additional-data]); the registry entry is the root 271 of the MIME sub-type (not including the 'EmergencyCallData' prefix 272 and any suffix such as '+xml'). 274 A next-generation In-Vehicle System (IVS) transmits crash data by 275 encoding it in a standardized and registered format (such as VEDS) 276 and attaching it to an INVITE as a MIME body part. The body part is 277 identified by its MIME content-type (such as 'application/ 278 EmergencyCallData.VEDS+xml') in the Content-Type header field of the 279 body part. The body part is assigned a unique identifier which is 280 listed in a Content-ID header field in the body part. The INVITE is 281 marked as containing the crash data by adding a Call-Info header 282 field at the top level of the INVITE. This Call-Info header field 283 contains a CID URL referencing the body part's unique identifier, and 284 a 'purpose' parameter identifying the data as the crash data per the 285 registry entry; the 'purpose' parameter's value is 286 'EmergencyCallData.' and the root of the MIME type (not including the 287 'EmergencyCallData' prefix and any suffix such as '+xml' (e.g., 288 'purpose=EmergencyCallData.VEDS'). 290 The mechanisms described here are thus used to place emergency calls 291 that are identifiable as ACN calls and that carry one or more 292 standardized crash data objects in an interoperable way. 294 3. Overview of Current Deployment Models 296 Current (circuit-switched or legacy) systems for placing emergency 297 calls by in-vehicle systems, including automatic crash notification 298 systems, generally have a limited ability to convey at least location 299 and in some cases telematics data to the PSAP. Most such systems use 300 one of three architectural models, which are described here as: 301 "Telematics Service Provider" (TSP), "direct", and "paired handset". 302 These three models are illustrated below. 304 In the TSP model, both emergency and non-emergency calls are placed 305 to a Telematics Service Provider (TSP); a proprietary technique is 306 used for data transfer (such as proprietary in-band modems) to the 307 TSP. 309 In an emergency, the TSP call taker bridges in the PSAP and 310 communicates location, crash data (such as impact severity and trauma 311 prediction), and other data (such as the vehicle description) to the 312 PSAP call taker verbally. Typically, a three-way voice call is 313 established between the vehicle, the TSP, and the PSAP, allowing 314 communication between the PSAP call taker, the TSP call taker, and 315 the vehicle occupants (who might be unconscious). 317 ///----\\\ proprietary +------+ 911 trunk +------+ 318 ||| IVS |||-------------->+ TSP +------------------>+ PSAP | 319 \\\----/// crash data +------+ +------+ 321 Figure 1: Legacy TSP Model. 323 In the paired model, the IVS uses a Bluetooth link with a previously- 324 paired handset to establish an emergency call with the PSAP (by 325 dialing a standard emergency number such as 9-1-1), and then 326 communicates location data to the PSAP via text-to-speech; crash data 327 is not conveyed. Some such systems use an automated voice prompt 328 menu (e.g., "this is an automatic emergency call from a vehicle; 329 press 1 to open a voice path to the vehicle; press 2 to hear the 330 location read out") to allow the call taker to request location data 331 via text-to-speech. 333 +---+ 334 ///----\\\ | H | 911/etc voice call via handset +------+ 335 ||| IVS |||-->| S +----------------------------------->+ PSAP | 336 \\\----/// +---+ location via text-to-speech +------+ 338 Figure 2: Legacy Paired Model 340 In the direct model, the IVS directly places an emergency call with 341 the PSAP by dialing a standard emergency number such as 9-1-1. Such 342 systems might communicate location data to the PSAP via text-to- 343 speech; crash data might not be conveyed. 345 ///----\\\ 911/etc voice call via IVS +------+ 346 ||| IVS |||---------------------------------------->+ PSAP | 347 \\\----/// location via text-to-speech +------+ 349 Figure 3: Legacy Direct Model 351 4. Document Scope 353 This document is focused on the interface to the PSAP, that is, how 354 an ACN emergency call is setup and incident-related data (including 355 vehicle, sensor, and location data) is transmitted to the PSAP using 356 IETF specifications. (The goal is to re-use specifications rather 357 than to invent new.) For the direct model, this is the end-to-end 358 description (between the vehicle and the PSAP). For the TSP model, 359 this describes the right-hand side (between the TSP and the PSAP), 360 leaving the left-hand side (between the vehicle and the TSP) up to 361 the entities involved (i.e., IVS and TSP vendors) who are then free 362 to use the same mechanism as for the right-hand side (or not). 364 Note that while ACN systems in the U.S. and other regions are not 365 currently mandated, Europe has a mandated and standardized system for 366 emergency calls by in-vehicle systems. This pan-European system is 367 known as "eCall" and is the subject of a separate document, 368 [I-D.ietf-ecrit-ecall]. Vehicles designed to operate in multiple 369 regions may need to support eCall as well as the ACN described here. 370 If other regions devise their own specifications or data formats, a 371 multi-region vehicle may need to support those as well. This 372 document adopts the call set-up and other technical aspects of 373 [I-D.ietf-ecrit-ecall], which uses [I-D.ietf-ecrit-additional-data], 374 which makes it easy to substitute a different data set while keeping 375 other technical aspects unchanges. Hence, both NG-eCall and the ACN 376 mechanism described here are fully compatible, differing only in the 377 specific data block that is sent (the eCall MSD in the case of NG- 378 eCall, and the APCO/NENA VEDS used in this document). If other 379 regions adopt their own data set, this can be similarly accomodated 380 without changing other technical aspects. 382 5. Migration to Next-Generation 384 Migration of emergency calls placed by in-vehicle systems to next- 385 generation (all-IP) technology provides a standardized mechanism to 386 identify such calls and to present crash data with the call. This 387 allows ACN calls and crash data to be automatically processed by the 388 PSAP and made available to the call taker in an integrated, automated 389 way. Because the crash data is carried in the initial SIP INVITE 390 (per [I-D.ietf-ecrit-additional-data]) the PSAP can present it to the 391 call taker simultaneously with the appearance of the call. 393 Vehicle manufacturers using the TSP model may choose to take 394 advantage of the same mechanism to carry telematics data between the 395 vehicle and the TSP for both emergency and non-emergency calls. 397 A next-generation IVS establishes an emergency call using the 398 emergency call solution as described in [RFC6443] and [RFC6881], with 399 the difference that the Request-URI indicates an ACN type of 400 emergency call and a Call-Info header field indicates that vehicle 401 crash data is attached. When an ESInet is deployed the MNO only 402 needs to recognize the call as an emergency call and route it to an 403 ESInet. The ESInet may recognize the call as an ACN with vehicle 404 data and may route the call to an NG-ACN capable PSAP. Such a PSAP 405 would interpet the vehicle data sent with the call and make it 406 available to the call taker. 408 Because of the need to identify and specially process Next-Generation 409 ACN calls (as discussed above), [I-D.ietf-ecrit-ecall] registers new 410 service URN children within the "sos" subservice. These URNs provide 411 a mechanism by which an NG-ACN call is identified, and differentiate 412 between manually and automatically triggered NG-ACN calls, which can 413 be subject to different treatment, depending on policy. (The two 414 service URNs registered in [I-D.ietf-ecrit-ecall] are: 415 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual.) 417 Note that in North America, routing queries performed by clients 418 outside of an ESInet are likely to treat all sub-services of "sos" 419 identically to "sos" with no sub-service. However, the Request-URI 420 header field retains the full sub-service; route and handling 421 decisions within an ESInet or PSAP may take the sub-service into 422 account. For example, in a region with multiple cooperating PSAPs, 423 an NG-ACN call might be routed to a PSAP that is NG-ACN capable, or 424 one that specializes in vehicle-related incidents. 426 Migration of the three architectural models to next-generation (all- 427 IP) is described below. 429 In the TSP model, the IVS transmits crash and location data to the 430 TSP using either a protocol that is based on a proprietary design or 431 one that re-uses IETF specifications. In an emergency, the TSP call 432 taker bridges in the PSAP and the TSP transmits crash and other data 433 to the PSAP using IETF specifications. There is a three-way call 434 between the vehicle, the TSP, and the PSAP, allowing communication 435 between the PSAP call taker, the TSP call taker, and the vehicle 436 occupants (who might be unconscious). 438 proprietary 439 ///----\\\ or standard +------+ standard +------+ 440 ||| IVS ||| ------------------->+ TSP +------------------->+ PSAP | 441 \\\----/// crash + other data +------+ crash + other data +------+ 443 Figure 4: Next-Generation TSP Model 445 The vehicle manufacturer and the TSP may choose to use the same IETF 446 specifications to transmit crash and location data from the vehicle 447 to the TSP as is described here to transmit such data from the TSP to 448 the PSAP. 450 In the paired model, the IVS uses a Bluetooth link to a previously- 451 paired handset to establish an emergency call with the PSAP; it is 452 not clear what facilities are or will be available for transmitting 453 crash data through the Bluetooth link to the handset for inclusion in 454 an NG emergency call. 456 +---+ 457 ///----\\\ (unclear) | H | (unclear) +------+ 458 ||| IVS |||------------------>| S +------------------->+ PSAP | 459 \\\----/// (unclear) +---+ (unclear) +------+ 461 Figure 5: Next-Generation Paired Model 463 In the direct model, the IVS communicates crash data to the PSAP 464 directly using IETF specifications. 466 ///----\\\ NG emergency call +------+ 467 ||| IVS |||----------------------------------------->+ PSAP | 468 \\\----/// crash + other data +------+ 470 Figure 6: Next-Generation Model 472 If the call is routed to a PSAP that is not capable of processing the 473 vehicle data, the PSAP ignores (or does not receive) the vehicle 474 data. This is detectable by the IVS or TSP when it receives a 200 OK 475 to the INVITE that lacks an eCall control structure acknowledging 476 receipt of the data [I-D.ietf-ecrit-ecall]. The IVS or TSP then 477 proceeds as it would for a non-NG ACN call (e.g., verbal conveyance 478 of data) 480 6. Profile 482 In the context of emergncy calls placed by an in-vehicle system it is 483 assumed that the car is equipped with a built-in GNSS receiver. For 484 this reason only geodetic location information will be sent within an 485 emergency call. The following location shapes MUST be implemented: 486 2d and 3d Point (see Section 5.2.1 of [RFC5491]), Circle (see 487 Section 5.2.3 of [RFC5491]), and Ellipsoid (see Section 5.2.7 of 488 [RFC5491]). The coordinate reference systems (CRS) specified in 489 [RFC5491] are also mandatory for this document. The 490 element, as defined in [RFC5962] which indicates the direction of 491 travel of the vehicle, is important for dispatch and hence it MUST be 492 included in the PIDF-LO [RFC4119]. The element specified 493 in [RFC5962] MUST be implemented and MAY be included. 495 Calls by in-vehicle systems are placed via cellular networks, which 496 may ignore location sent by an originating device in an emergency 497 call INVITE, instead attaching their own location (often determined 498 in cooperation with the originating device). Standardized crash data 499 structures often include location as determined by the IVS. A 500 benefit of this is that it allows the PSAP to see both the location 501 as determined by the cellular network (often in cooperation with the 502 originating device) and the location as determined by the IVS. 504 This specification inherits the ability to utilize test call 505 functionality from Section 15 of [RFC6881]. 507 7. Call Setup 509 It is important that ACN calls be easily identifiable as such at all 510 stages of call handling, and that automatic versus manual triggering 511 be known. ACN calls differ from general emergency calls in several 512 aspects, including the presence of standardized crash data, the fact 513 that the call is known to be placed by an in-vehicle system (which 514 has implications for PSAP operational processes), and, especially for 515 automatic calls, information that may indicate a likelihood of severe 516 injury and hence need for trauma services. Knowledge that a call is 517 an ACN and further that it was automatically or manually invoked 518 carries a range of implications about the call, the circumstances, 519 and the vehicle occupants. Calls by in-vehicle systems may be 520 considered a specific sub-class of general emergency calls and are 521 optimally handled by a PSAP with the technical and operational 522 capabilities to serve such calls. (This is especially so in 523 environments such as the U.S. where there are many PSAPs and where 524 individual PSAPs have a range of capabilities.) Technical 525 capabilities include the ability to recognize and process 526 standardized crash data. Operational capabilities include training 527 and processes for assessing severe injury likelihood and responding 528 appropriately (e.g., dispatching trauma-capable medical responders or 529 those trained and equipped to extract occupants from crashed vehicles 530 and handle gasoline or other hazardous materials, transporting 531 victims to a trauma center, alerting the receiving facility, etc.). 533 Because ACN calls differ in significant ways from general emergency 534 calls, and because such calls should be handled by specialized PSAPs 535 (equipped technically to interpet and make use of crash data, and 536 operationally to handle emergency calls placed by in-vehicle 537 systems), [I-D.ietf-ecrit-ecall] registers SOS sub-services. Using a 538 sub-service makes it readily obvious that the call is an ACN; a 539 further child element distinguishes calls automatically placed due to 540 a crash or other serious incident (such as a fire) from those 541 manually invoked by a vehicle occupant (specifically, 542 "SOS.ecall.automatic" and "SOS.ecall.manual"). The distinction 543 between automatic and manual invocation is also significant; 544 automatically triggered calls indicate a car crash or some other 545 serious incident (e.g., a fire) and carry a greater presumption of 546 risk of injury and hence need for specific responders (such as trauma 547 or fire). Manually triggered calls are often reports of serious 548 hazards (such as drunk drivers) and may require different responses 549 depending on the situation. Manually triggered calls are also more 550 likely to be false (e.g., accidental) calls and may thus be subject 551 to different handling by the PSAP. 553 A next-generation In-Vehicle System (IVS) transmits crash data by 554 encoding it in a standardized and registered format and attaching it 555 to an INVITE as an additional data block as specified in Section 4.1 556 of [I-D.ietf-ecrit-additional-data]. As described in that document, 557 the block is identified by its MIME content-type, and pointed to by a 558 CID URL in a Call-Info header with a 'purpose' parameter value 559 corresponding to the block. 561 Specifically, the steps required during standardization are: 563 o A set of crash data is standardized by an SDO or appropriate 564 organization 566 o A MIME Content-Type for the crash data set is registered with IANA 567 * If the data is specifically for use in emergency calling, the 568 MIME type is normally under the 'application' type with a 569 subtype starting with 'EmergencyCallData.' 571 * If the data format is XML, then by convention the name has a 572 suffix of '+xml' 574 o The item is registered in the Emergency Call Additional Data 575 registry, as defined in Section 9.1.7 of 576 [I-D.ietf-ecrit-additional-data] 578 * For emergency-call-specific formats, the registered name is the 579 root of the MIME Content-Type (not including the 580 'EmergencyCallData' prefix and any suffix such as '+xml') as 581 described in Section 4.1 of [I-D.ietf-ecrit-additional-data] 583 When placing an emergency call: 585 o The crash data set is created and encoded per its specification 587 o The crash data set is attached to the emergency call INVITE as 588 specified in Section 4.1 of [I-D.ietf-ecrit-additional-data], that 589 is, as a MIME body part identified by its MIME Content-Type in the 590 body part's Content-Type header field 592 o The body part is assigned a unique identifier label in a Content- 593 ID header field of the body part 595 o A Call-Info header field at the top level of the INVITE is added 596 that references the crash data and identifies it by its MIME root 597 (as registered in the Emergency Call Additional Data registry) 599 * The crash data is referenced in the Call-Info header field by a 600 CID URL that contains the unique Content ID assigned to the 601 crash data body part 603 * The crash data is identified in the Call-Info header field by a 604 'purpose' parameter whose value is 'EmergencyCallData.' 605 concatenated with the specific crash data entry in the 606 Emergency Call Additional Data registry 608 * The Call-Info header field MAY be either solely to reference 609 the crash data (and hence have only the one URL) or may also 610 contain other URLs referencing other data 612 o Additional crash data sets MAY be included by following the same 613 steps 615 The Vehicle Emergency Data Set (VEDS) is an XML structure defined by 616 the Association of Public-Safety Communications Officials (APCO) and 617 the National Emergency Number Association (NENA) [VEDS]. The 618 'application/EmergencyCallData.VEDS+xml' MIME content-type is used to 619 identify it. The 'VEDS' entry in the Emergency Call Additional Data 620 registry is used to construct a 'purpose' parameter value for 621 conveying VEDS data in a Call-Info header. 623 The VEDS data is attached as a body part with MIME content type 624 'application/EmergencyCallData.VEDS+xml' which is pointed at by a 625 Call-Info URL of type CID with a 'purpose' parameter of 626 'EmergencyCallData.VEDS'. 628 Entities along the path between the vehicle and the PSAP are able to 629 identify the call as an ACN call and handle it appropriately. The 630 PSAP is able to identify the crash data as well as any other 631 additional data attached to the INVITE by examining the Call-Info 632 header fields for 'purpose' parameters whose values start with 633 'EmergencyCallData.' The PSAP is able to access and the data it is 634 capable of handling and is interested in by checking the 'purpose' 635 parameter values. 637 8. Call Routing 639 An Emergency Services IP Network (ESInet) is a network operated by 640 emergency services authorities. It handles emergency call routing 641 and processing before delivery to a PSAP. In the NG9-1-1 642 architecture adopted by NENA as well as the NG1-1-2 architecture 643 adopted by EENA, each PSAP is connected to one or more ESInets. Each 644 originating network is also connected to one or more ESInets. The 645 ESInets maintain policy-based routing rules which control the routing 646 and processing of emergency calls. The centralization of such rules 647 within ESInets provides for a cleaner separation between the 648 responsibilities of the originating network and that of the emergency 649 services network, and provides greater flexibility and control over 650 processing of emergency calls by the emergency services authorities. 651 This makes it easier to react quickly to unusual situations that 652 require changes in how emergency calls are routed or handled (e.g., a 653 natural disaster closes a PSAP), as well as ease in making long-term 654 changes that affect such routing (e.g., cooperative agreements to 655 specially handle calls requiring translation or relay services). 657 In an environment that uses ESInets, the originating network need 658 only detect that the service URN of an emergency call is or starts 659 with "sos", passing all types of emergency calls to an ESInet. The 660 ESInet is then responsible for routing such calls to an appropriate 661 PSAP. In an environment without an ESInet, the emergency services 662 authorities and the originating carriers would need to determine how 663 such calls are routed. 665 9. Test Calls 667 This document uses [I-D.ietf-ecrit-ecall], which inherits the ability 668 to utilize test call functionality from Section 15 of [RFC6881]. 670 A service URN starting with "test." indicates a request for an 671 automated test. Per [I-D.ietf-ecrit-ecall], 672 "urn:service:test.sos.ecall.automatic" indicates such a test feature. 673 This functionality is defined in [RFC6881]. 675 Note that since test calls are placed using "test" as the parent 676 service URN and "sos" as a child, such calls are not treated as an 677 emergency call and so some functionality will not apply (such as 678 preemption or service availability for devices lacking service ("non- 679 service-initialized" or "NSI") if those are available for emergency 680 calls); this is by design. MNOs may recognize test calls and treat 681 them in a way that tests as much functionality as desired, but this 682 is outside the scope of this document. 684 10. Example 686 Figure 7 shows an emergency call placed by a vehicle whereby location 687 information and VEDS crash data are both attached to the SIP INVITE 688 message. The INVITE has a request URI containing the 689 'urn:service:sos.ecall.automatic' service URN and is thus recognized 690 as an ACN type of emergency call, and is also recognized as a type of 691 emergency call because the request URI starts with 'urn:service:sos'. 692 The mobile network operator (MNO) routes the call to an Emergency 693 services IP Network (ESInet), as for any emergency call. The ESInet 694 processes the call as an ACN and routes the call to an appropriate 695 ACN-capable PSAP (using location information and the fact that that 696 it is an ACN). (In deployments where there is no ESInet, the MNO 697 itself needs to route directly to an appropriate ACN-capable PSAP.) 698 The call is processed by the Emergency Services Routing Proxy (ESRP), 699 as the entry point to the ESInet. The ESRP routes the call to an 700 appropriate ACN-capable PSAP, where the call is received by a call 701 taker. 703 +---------------------------------------+ 704 | | 705 +------------+ | +-------+ | 706 | | | | PSAP2 | | 707 | | | +-------+ | 708 | Originating| | | 709 | Mobile | | +------+ +-------+ | 710 Vehicle-->| Network |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 711 | | | +------+ +-------+ | 712 | | | | 713 +------------+ | +-------+ | 714 | | PSAP3 | | 715 | +-------+ | 716 | | 717 | | 718 | | 719 | ESInet | 720 +---------------------------------------+ 722 Figure 7: Example of Vehicle-Placed Emergency Call Message Flow 724 The example, shown in Figure 8, illustrates a SIP emergency call 725 INVITE that is being conveyed with location information (a PIDF-LO) 726 and crash data (as VEDS data). 728 INVITE urn:service:sos.ecall.automatic SIP/2.0 729 To: urn:service:sos.ecall.automatic 730 From: ;tag=9fxced76sl 731 Call-ID: 3848276298220188511@atlanta.example.com 732 Geolocation: 733 Geolocation-Routing: no 734 Call-Info: cid:1234567890@atlanta.example.com; 735 purpose=EmergencyCallData.VEDS 736 Accept: application/sdp, application/pidf+xml 737 CSeq: 31862 INVITE 738 Content-Type: multipart/mixed; boundary=boundary1 739 Content-Length: ... 741 --boundary1 743 Content-Type: application/sdp 745 ...Session Description Protocol (SDP) goes here 747 --boundary1 749 Content-Type: application/pidf+xml 750 Content-ID: 751 752 760 761 762 763 764 -34.407 150.883 765 766 767 278 768 769 770 771 772 gps 773 774 2012-04-5T10:18:29Z 775 1M8GDM9A_KP042788 776 777 779 --boundary1 781 Content-Type: application/EmergencyCallData.VEDS+xml 782 Content-ID: 1234567890@atlanta.example.com 784 ...VEDS data object goes here 786 --boundary1-- 788 Figure 8: SIP INVITE indicating a Vehicule-Initated Emergency Call 790 11. Security Considerations 792 This document does not raise security considerations beyond those 793 described in [RFC5069]. As with emergency service systems with end 794 host provided location information there is the possibility that that 795 location is incorrect, either intentially (in case of an a denial of 796 service attack against the emergency services infrastructure) or due 797 to a malfunctioning device. The reader is referred to 799 [I-D.ietf-ecrit-trustworthy-location] for a discussion of some of 800 these vulnerabilities. 802 12. IANA Considerations 804 12.1. MIME Content-type Registration for 'application/ 805 EmergencyCall.VEDS+xml' 807 This specification requests the registration of a new MIME type 808 according to the procedures of RFC 4288 [RFC4288] and guidelines in 809 RFC 3023 [RFC3023]. 811 MIME media type name: application 813 MIME subtype name: EmergencyCallData.VEDS+xml 815 Mandatory parameters: none 817 Optional parameters: charset 819 Indicates the character encoding of enclosed XML. 821 Encoding considerations: Uses XML, which can employ 8-bit 822 characters, depending on the character encoding used. See 823 Section 3.2 of RFC 3023 [RFC3023]. 825 Security considerations: This content type is designed to carry 826 vehicle crash data during an emergency call. This data may 827 contains personal information including vehicle VIN, location, 828 direction, etc. appropriate precautions need to be taken to limit 829 unauthorized access, inappropriate disclosure to third parties, 830 and eavesdropping of this information. Please refer to Section 7 831 and Section 8 of [I-D.ietf-ecrit-additional-data] for more 832 information. 834 Interoperability considerations: None 836 Published specification: [VEDS] 838 Applications which use this media type: Emergency Services 840 Additional information: None 842 Magic Number: None 844 File Extension: .xml 846 Macintosh file type code: 'TEXT' 847 Person and email address for further information: Hannes 848 Tschofenig, Hannes.Tschofenig@gmx.net 850 Intended usage: LIMITED USE 852 Author: This specification is a work item of the IETF ECRIT 853 working group, with mailing list address . 855 Change controller: The IESG 857 12.2. Registration of the 'VEDS' entry in the Emergency Call Additional 858 Data registry 860 This specification requests IANA to add the 'VEDS' entry to the 861 Emergency Call Additional Data registry, with a reference to this 862 document. The Emergency Call Additional Data registry has been 863 established by [I-D.ietf-ecrit-additional-data]. 865 13. Contributors 867 We would like to thank Ulrich Dietz for his help with earlier 868 versions of the original version of this document. 870 14. Acknowledgements 872 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 873 and Gunnar Hellstrom for their feedback. 875 15. Changes from Previous Versions 877 15.1. Changes from draft-ietf-01 to draft-ietf-02 879 o This document now refers to [I-D.ietf-ecrit-ecall] for technical 880 aspects including the service URN; this document no longer 881 proposes a unique service URN for non-eCall NG-ACN calls; the same 882 service URN is now used for all NG-ACN calls including NG-eCall 883 and non-eCall 884 o Added discussion of an NG-ACN call placed to a PSAP that doesn't 885 support it 886 o Minor wording improvements and clarifications 888 15.2. Changes from draft-ietf-00 to draft-ietf-01 890 o Added further discussion of test calls 891 o Added further clarification to the document scope 892 o Mentioned that multi-region vehicles may need to support other 893 crash notification specifications such as eCall 894 o Minor wording improvements and clarifications 896 15.3. Changes from draft-gellens-02 to draft-ietf-00 898 o Renamed from draft-gellens- to draft-ietf- 899 o Added text to Introduction to clarify that during a CS ACN, the 900 PSAP call taker usually needs to listen to the data and transcribe 901 it 903 15.4. Changes from draft-gellens-01 to -02 905 o Fixed case of 'EmergencyCallData', in accordance with changes to 906 [I-D.ietf-ecrit-additional-data] 908 15.5. Changes from draft-gellens-00 to -01 910 o Now using 'EmergencyCallData' for purpose parameter values and 911 MIME subtypes, in accordance with changes to 912 [I-D.ietf-ecrit-additional-data] 913 o Added reference to RFC 6443 914 o Fixed bug that caused Figure captions to not appear 916 16. References 918 16.1. Normative References 920 [I-D.ietf-ecrit-additional-data] 921 Randy, R., Rosen, B., Tschofenig, H., Marshall, R., and J. 922 Winterbottom, "Additional Data related to an Emergency 923 Call", draft-ietf-ecrit-additional-data-24 (work in 924 progress), October 2014. 926 [I-D.ietf-ecrit-ecall] 927 Gellens, R. and H. Tschofenig, "Next-Generation Pan- 928 European eCall", draft-ietf-ecrit-ecall (work in 929 progress), March 2015. 931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 932 Requirement Levels", BCP 14, RFC 2119, March 1997. 934 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 935 Types", RFC 3023, January 2001. 937 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 938 Format", RFC 4119, December 2005. 940 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 941 Registration Procedures", RFC 4288, December 2005. 943 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 944 Emergency and Other Well-Known Services", RFC 5031, 945 January 2008. 947 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 948 Presence Information Data Format Location Object (PIDF-LO) 949 Usage Clarification, Considerations, and Recommendations", 950 RFC 5491, March 2009. 952 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 953 Thomson, "Dynamic Extensions to the Presence Information 954 Data Format Location Object (PIDF-LO)", RFC 5962, 955 September 2010. 957 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 958 "Framework for Emergency Calling Using Internet 959 Multimedia", RFC 6443, December 2011. 961 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 962 Communications Services in Support of Emergency Calling", 963 BCP 181, RFC 6881, March 2013. 965 [VEDS] "Vehicular Emergency Data Set (VEDS) version 3", July 966 2012, . 969 16.2. Informative references 971 [I-D.ietf-ecrit-trustworthy-location] 972 Tschofenig, H., Schulzrinne, H., and B. Aboba, 973 "Trustworthy Location", draft-ietf-ecrit-trustworthy- 974 location-14 (work in progress), July 2014. 976 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 977 Emergency Context Resolution with Internet Technologies", 978 RFC 5012, January 2008. 980 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 981 Shanmugam, "Security Threats and Requirements for 982 Emergency Call Marking and Mapping", RFC 5069, January 983 2008. 985 Authors' Addresses 986 Randall Gellens 987 Qualcomm Technologies, Inc 988 5775 Morehouse Drive 989 San Diego 92651 990 US 992 Email: rg+ietf@qti.qualcomm.com 994 Brian Rosen 995 NeuStar, Inc. 996 470 Conrad Dr 997 Mars, PA 16046 998 US 1000 Email: br@brianrosen.net 1002 Hannes Tschofenig 1003 (no affiliation) 1005 Email: Hannes.Tschofenig@gmx.net 1006 URI: http://www.tschofenig.priv.at