idnits 2.17.00 (12 Aug 2021) /tmp/idnits33972/draft-rosen-ecrit-ecall-09.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2013) is 3234 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 454, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 466, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (ref. '8') (Obsoleted by RFC 6838) == Outdated reference: draft-ietf-ecrit-additional-data has been published as RFC 7852 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational H. Tschofenig 5 Expires: January 14, 2014 Nokia Siemens Networks 6 R. Gellens 7 QUALCOMM Incorporated 8 July 13, 2013 10 Internet Protocol-based In-Vehicle Emergency Call 11 draft-rosen-ecrit-ecall-09.txt 13 Abstract 15 This document describes how to re-use the emergency services 16 mechanisms specified for the Session Initiation Protocol (SIP) to 17 accomplishing emergency calling support in vehicles. Profiling and 18 simplifications are possible due to the nature of the functionality 19 that is going to be provided in vehicles with the usage of Global 20 Positioning System (GPS). 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 14, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Overview of Current Deployment Models . . . . . . . . . . 3 58 1.2. Migration to IP-based Models . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6.1. Service URN Registration . . . . . . . . . . . . . . . . 8 65 6.2. MIME Content-type Registration for 66 'application/emergencyCall.VEDS+xml' . . . . . . . . . . 9 67 6.3. Registration of the 'VEDS' entry in the Emergency Call 68 Additional Data registry . . . . . . . . . . . . . . . . 10 69 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 73 9.2. Informative references . . . . . . . . . . . . . . . . . 11 74 Appendix A. Matching Functionality with eCall Minimum Set of 75 Data (MSD) . . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Emergency calls made from vehicles can assist with the objective of 81 significantly reducing road deaths and injuries. Unfortunately, 82 drivers often have a poor location-awareness, especially on urban 83 roads (also during night) and abroad. In the most crucial cases, the 84 victim(s) may not be able to call because they have been injured or 85 trapped. 87 In Europe the European Commission has launched the 'eCall' initiative 88 that may best be described as a user-initiated or automatically 89 triggered system to provide notifications to Public Safety Answering 90 Point's (PSAP), by means of cellular communications, that a vehicle 91 has crashed, and to provide geodetic location information and where 92 possible a voice channel to the PSAP. 94 This document registers the 'application/emergencyCall.VEDS+xml' MIME 95 content-type, and registers the 'VEDS' entry in the Emergency Call 96 Additional Data registry. 98 The Vehicle Emergency Data Set (VEDS) is an XML structure defined by 99 the Association of Public-Safety Communications Officials (APCO) and 100 the National Emergency Number Association (NENA). The 'application/ 101 emergencyCall.VEDS+xml' MIME content-type is used to identify it. 102 The 'VEDS' entry in the Emergency Call Additional Data registry is 103 used to construct a 'purpose' parameter value for conveying VEDS data 104 in a Call-Info header. 106 Circuit-switched eCall systems transmit crash data as a defined set, 107 the Minimum Set of Data (MSD) [15]. The MSD for circuit-switched 108 eCall is a binary format defined by CEN, the European Committee for 109 Standardization. It is expected that CEN will choose to define the 110 XML schema for the eCall MSD for use in next-generation systems. 111 Once this done, a MIME content-type (e.g., 'application/ 112 emergencyCall.eCall.MSD+xml') and Emergency Call Additional Data 113 entry (e.g., 'eCall.MSD') need to be registered for the MSD. Note 114 that Appendix A explains how the functionality available in IETF 115 specifications maps to the functionality required for the MSD of the 116 mobile circuit switched voice solution. 118 CEN and/or other entities may define additional sets of data in the 119 same manor: a standardized format, such as XML, is defined, and a 120 MIME content-type and Emergency Call Additional Data entry 121 registered. 123 An In-Vehicle System (IVS) transmits crash data by encoding it in one 124 of the standardized and registered formats (such as VEDS or 125 eCall.MSD) and attaching it to an INVITE as a data block. The block 126 is identified by its MIME content-type, and pointed to by a CID URL 127 in a Call-Info header with a 'purpose' parameter value corresponding 128 to the block. 130 1.1. Overview of Current Deployment Models 132 Current (circuit-switched or legacy) systems for placing emergency 133 calls from vehicles, including automatic crash notification system, 134 generally use one of three architectural models: Telematics Service 135 Provider (TSP), direct, and paired handset. These three models are 136 illustrated below. 138 In the TSP model the IVS transmits crash data to the TSP using 139 proprietary means. The TSP operator bridges in the PSAP and 140 communicates location, crash, and other data to the call taker 141 verbally (there is a three-way voice call between the vehicle, the 142 TSP, and the PSAP). 144 ///----\\\ proprietary +------+ 911 trunk +------+ 145 ||| IVS |||-------------->+ TSP +------------------>+ PSAP | 146 \\\----/// crash data +------+ +------+ 148 Figure 1: TSP Model. 150 In the paired model the IVS uses a Bluetooth link to a previously- 151 paired handset to establish an emergency call with the PSAP and then 152 communicates location data to the PSAP via text-to-speech; crash data 153 is not conveyed. 155 ++ 156 ///----\\\ || 911 voice call via handset +------+ 157 ||| IVS |||--->|+----------------------------------->+ PSAP | 158 \\\----/// ++ +------+ 160 Figure 2: Paired Model 162 In the direct model the IVS communicates crash data to the PSAP via 163 the eCall in-band modem (in the voice call). 165 ///----\\\ 112/911 voice call via IVS +------+ 166 ||| IVS |||---------------------------------------->+ PSAP | 167 \\\----/// crash data via eCall in-band modem +------+ 169 Figure 3: Direct Model 171 1.2. Migration to IP-based Models 173 The migration to next-generation (all-IP) would then look like as 174 follows. 176 In the TSP model The IVS transmits crash data to the TSP using either 177 proprietary or standard means. The TSP bridges in the PSAP and 178 transmits crash and other data to the PSAP using IETF specifications. 179 There is a three-way call between the vehicle, the TSP, and the PSAP. 181 proprietary 182 ///----\\\ or standard +------+ standard +------+ 183 IVS ------------->+ TSP +------------------->+ PSAP | 184 \\\----/// crash data +------+ crash + other data +------+ 186 Figure 4: TSP Model 188 In the paired model, the IVS uses a Bluetooth link to a previously- 189 paired handset to establish an emergency call with the PSAP; it is 190 not clear what facilities are or will be available for transmitting 191 crash data. 193 ++ 194 ///----\\\ || IP-based Emergency Call +------+ 195 IVS --->|+----------------------------------->+ PSAP | 196 \\\----/// ++ +------+ 198 Figure 5: Paired Model 200 In the direct model the IVS communicates crash data to PSAP using 201 Internet protocols. 203 ///----\\\ IP-based Emergency Call via IVS +------+ 204 IVS ----------------------------------------->+ PSAP | 205 \\\----/// +------+ 207 Figure 6: Direct Model 209 This document is focused on the interface to the PSAP, that is, how 210 an emergency call (including location and crash data) is setup and 211 data is transmitted to the PSAP using existing IETF specifications. 212 The goal is to re-use existing specifications rather than to invent 213 new. For the direct model (such as the European eCall), this is the 214 end-to-end description. For the TSP model, this describes the right- 215 hand side, leaving the left-hand side up to the entities involved 216 (e.g., IVS and TSP vendors) who are then free to use the same 217 mechanism as for the right-hand side or not. 219 2. Terminology 221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 223 document are to be interpreted as described in [1]. 225 This document re-uses terminology defined in Section 3 of [11]. 227 Additionally, we use the following abbreviations: 229 IVS: In-Vehicle System 231 TSP: Telematics Service Provider 233 MSD: Minimum Set of Data 235 VEDS: Vehicle Emergency Data Set 237 NENA: National Emergency Number Association 239 APCO: Association of Public-Safety Communications Officials 240 CEN: European Committee for Standardization 242 3. Profile 244 In the context of emergncy calls placed from a vehicle it is assumed 245 that the car is equipped with a built-in GPS receiver. For this 246 reason only geodetic location information will be sent within an 247 emergency call. The following location shapes MUST be implemented: 248 2d and 3d Point (see Section 5.2.1 of [3]), Circle (see Section 5.2.3 249 of [3]), and Ellipsoid (see Section 5.2.7 of [3]). The coordinate 250 reference systems (CRS) specified in [3] are also mandatory for this 251 document. The element, as defined in [6] which indicates 252 the direction of travel of the vehicle, is important for dispatch and 253 hence it MUST be included in the PIDF-LO . The element 254 specified in [6] MUST be implemented and MAY be included. 256 This specification also inherits the ability to utilize test call 257 functionality from Section 15 of [4]. 259 4. Example 261 Figure 7 shows an emergency call placed from a vehicle whereby 262 location information information is directly attached to the SIP 263 INVITE message itself. The call is marked as an emergency call using 264 the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the 265 VoIP provider determines which PSAP to contact based on the provided 266 location information. The emergency call continues towards the PSAP 267 and in this example it hits the ESRP, as the entry point to the PSAP 268 operators emergency services network. Finally, the emergency call 269 will be received by a call taker and first reponders will be 270 dispatched. 272 +--------+ 273 | LoST | 274 | Server | 275 +--------+ 276 ^ +-------+ 277 | | PSAP2 | 278 | +-------+ 279 v 280 +-------+ +------+ +-------+ 281 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 282 +-------+ +------+ +-------+ 284 +-------+ 285 | PSAP3 | 286 +-------+ 288 Figure 7: Example of In-Vehicular Emergency Call Message Flow 290 The example, shown in Figure 8, illustrates a SIP INVITE and location 291 information encoded in a PIDF-LO that is being conveyed in such an 292 emergency call. 294 INVITE urn:service:sos.ecall.automatic SIP/2.0 295 To: urn:service:sos.ecall.automatic 296 From: ;tag=9fxced76sl 297 Call-ID: 3848276298220188511@atlanta.example.com 298 Geolocation: 299 Geolocation-Routing: no 300 Accept: application/sdp, application/pidf+xml 301 CSeq: 31862 INVITE 302 Content-Type: multipart/mixed; boundary=boundary1 303 Content-Length: ... 305 --boundary1 307 Content-Type: application/sdp 309 ...Session Description Protocol (SDP) goes here 311 --boundary1 313 Content-Type: application/pidf+xml 314 Content-ID: 315 316 324 325 326 327 328 -34.407 150.883 329 330 331 278 332 333 334 335 336 gps 337 338 2012-04-5T10:18:29Z 339 1M8GDM9A_KP042788 340 341 342 --boundary1-- 344 Figure 8: SIP INVITE indicating an In-Vehicular Emergency Call 346 5. Security Considerations 348 This document does not raise security considerations beyond those 349 described in [12]. As with emergency service systems with end host 350 provided location information there is the possibility that that 351 location is incorrect, either intentially (in case of an a denial of 352 service attack against the emergency services infrastructure) or due 353 to a malfunctioning devices. The reader is referred to [13] for a 354 discussion of some of these vulnerabilities. 356 6. IANA Considerations 358 6.1. Service URN Registration 360 IANA is requested to register the URN 'urn:service:sos.ecall' under 361 the sub-services 'sos' registry defined in Section 4.2 of [10]. 363 This service identifier reaches a public safety answering point 364 (PSAP), which in turn dispatches aid appropriate to the emergency 365 related to accidents of vehicles. Two sub-services are registered as 366 well, namely 367 urn:service:sos.ecall.manual 369 This service URN indicates that an eCall had been triggered based 370 on the manual interaction of the driver or a passenger. 372 urn:service:sos.ecall.automatic 374 This service URN indicates that an eCall had been triggered 375 automatically, for example, due to a crash. No human involvement 376 was detected. 378 6.2. MIME Content-type Registration for 'application/ 379 emergencyCall.VEDS+xml' 381 This specification requests the registration of a new MIME type 382 according to the procedures of RFC 4288 [8] and guidelines in RFC 383 3023 [7]. 385 MIME media type name: application 387 MIME subtype name: emergencyCall.VEDS+xml 389 Mandatory parameters: none 391 Optional parameters: charset Indicates the character encoding of 392 enclosed XML. 394 Encoding considerations: Uses XML, which can employ 8-bit 395 characters, depending on the character encoding used. See 396 Section 3.2 of RFC 3023 [7]. 398 Security considerations: This content type is designed to carry 399 vehicle crash data during an emergency call. This data may 400 contains personal information including vehicle VIN, location, 401 direction, etc. appropriate precautions need to be taken to limit 402 unauthorized access, inappropriate disclosure to third parties, 403 and eavesdropping of this information. Please refer to Section 7 404 and Section 8 of [9] for more information. 406 Interoperability considerations: None 408 Published specification: [TBD: This specification] 410 Applications which use this media type: Emergency Services 412 Additional information: None 414 Magic Number: None 415 File Extension: .xml 417 Macintosh file type code: 'TEXT' 419 Person and email address for further information: Hannes 420 Tschofenig, Hannes.Tschofenig@gmx.net 422 Intended usage: LIMITED USE 424 Author: This specification is a work item of the IETF ECRIT 425 working group, with mailing list address . 427 Change controller: The IESG 429 6.3. Registration of the 'VEDS' entry in the Emergency Call Additional 430 Data registry 432 This specification requests IANA to add the 'VEDS' entry to the 433 Emergency Call Additional Data registry, with a reference to this 434 document. The Emergency Call Additional Data registry has been 435 established with [9]. 437 7. Contributors 439 We would like to thank Ulrich Dietz for his help with earlier 440 versions of the document. 442 8. Acknowledgements 444 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 445 and Gunnar Hellstroem for their feedback. 447 9. References 449 9.1. Normative References 451 [1] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", BCP 14, RFC 2119, March 1997. 454 [2] Peterson, J., "A Presence-based GEOPRIV Location Object 455 Format", RFC 4119, December 2005. 457 [3] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 458 Presence Information Data Format Location Object (PIDF-LO) 459 Usage Clarification, Considerations, and Recommendations", 460 RFC 5491, March 2009. 462 [4] Rosen, B. and J. Polk, "Best Current Practice for 463 Communications Services in Support of Emergency Calling", 464 BCP 181, RFC 6881, March 2013. 466 [5] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 467 for the Session Initiation Protocol", RFC 6442, December 468 2011. 470 [6] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 471 Thomson, "Dynamic Extensions to the Presence Information 472 Data Format Location Object (PIDF-LO)", RFC 5962, 473 September 2010. 475 [7] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 476 Types", RFC 3023, January 2001. 478 [8] Freed, N. and J. Klensin, "Media Type Specifications and 479 Registration Procedures", RFC 4288, December 2005. 481 [9] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy, 482 "Additional Data related to an Emergency Call", draft- 483 ietf-ecrit-additional-data-09 (work in progress), May 484 2013. 486 [10] Schulzrinne, H., "A Uniform Resource Name (URN) for 487 Emergency and Other Well-Known Services", RFC 5031, 488 January 2008. 490 9.2. Informative references 492 [11] Schulzrinne, H. and R. Marshall, "Requirements for 493 Emergency Context Resolution with Internet Technologies", 494 RFC 5012, January 2008. 496 [12] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 497 Shanmugam, "Security Threats and Requirements for 498 Emergency Call Marking and Mapping", RFC 5069, January 499 2008. 501 [13] Tschofenig, H., Schulzrinne, H., and B. Aboba, 502 "Trustworthy Location", draft-ietf-ecrit-trustworthy- 503 location-05 (work in progress), March 2013. 505 [14] Schulzrinne, H., "Timed Presence Extensions to the 506 Presence Information Data Format (PIDF) to Indicate Status 507 Information for Past and Future Time Intervals", RFC 4481, 508 July 2006. 510 [15] CEN, ., "Intelligent transport systems - eSafety - eCall 511 minimum set of data (MSD), EN 15722", June 2011. 513 Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD) 515 [15] outlines a number of data elements that are transmitted in an 516 emergency call triggered by a vehicle. Note that the work on eCall 517 for mobile circuit switched voice is constrained in a number of ways 518 since legacy eCall uses an inband voice modem for backwards 519 compatibility with the already deployed cellular infrastructure to 520 transmit data from a vehicle to a PSAP. Since the functionality in 521 this document is based on the Session Initiation Protocol (SIP) these 522 limitations do not exist. As such, it is not useful to transmit the 523 MSD inband in the voice channel but to rather use the SIP mechanisms 524 standardized for emergency call handling. Any voice, video, or real- 525 text communication will be negotiated using the Session Description 526 Protocol (SDP), as shown in Figure 8, and the actual media stream 527 will then take place in RTP packets. For transmitting location 528 information an XML-based data structure had been defined, the so- 529 called Presence Information Data Format Location Object (PIDF-LO). 531 The following list compares the eCall minimum set of data with the 532 functionality provided in this document. 534 Version of the MSD Format: Conveying information in a SIP-based 535 emergency call is accomplished by using XML payloads and XML 536 provides namespace declarations that allow a receipient of that 537 information to distinguish different versions and additional 538 extensions. For example, if additional data about a vehicle is 539 defined and can be transmitted by vehicle then a respective 540 extension can be defined inside the additional data XML structure 541 [9]. Selecting the appropriate extension point depends on the 542 type of extension envisioned. 544 Message Identifier: Every SIP INVITE message contains a Call-ID, 545 which is a globally unique identifier for this call. 547 Test Call Indication A service URN starting with "test." indicates a 548 request for an automated test. For example, 549 "urn:service:test.sos.ecall.automatic" indicates such a test 550 feature. This functionality is defined in [4]. 552 Automatic Activation Indication: This document registers new service 553 URNs, which allow the differentiation between manually and 554 automatically triggered emergency calls. The two service URNs 555 are: urn:service:sos.ecall.automatic and 556 urn:service:sos.ecall.manual 558 Vehicle Identification: The PIDF data structure contains a deviceID 559 field that holds the Vehicle Identification Number (VIN). 561 Timestamp of Incident Event: The PIDF-LO element contains the 562 timestamp when the PIDF-LO was created, which is at the time of 563 the incident. 565 Vehicle Location: The location of the vehicle is conveyed using the 566 PIDF location objection, as described in Section 3. 568 Vehicle Direction: The direction of the vehicle is part of location 569 information, as described in Section 3. 571 Recent Vehicle Location: With this optional functionality multiple 572 location objects may be required to be transported simultaneously. 573 This can be achieved using , defined in RFC 4481 574 [14]. 576 Additional Data: [9] provides the ability to carry additional data 577 for an emergency call. 579 While most fields have an equivalent already in the corresponding SIP 580 emergency signaling payloads there are currently no fields defined in 581 the additional data structure [9] that allow information about the 582 "Vehicle Type Encoding", "Number of Passengers", and "Vehicle 583 Propulsion Storage type" to be conveyed. Extensions for those fields 584 will have to be defined. 586 Authors' Addresses 588 Brian Rosen 589 NeuStar, Inc. 590 470 Conrad Dr 591 Mars, PA 16046 592 US 594 Email: br@brianrosen.net 596 Hannes Tschofenig 597 Nokia Siemens Networks 598 Linnoitustie 6 599 Espoo 02600 600 Finland 602 Phone: +358 (50) 4871445 603 Email: Hannes.Tschofenig@gmx.net 604 URI: http://www.tschofenig.priv.at 605 Randall Gellens 606 QUALCOMM Incorporated 607 5775 Morehouse Drive 608 San Diego 92651 609 US 611 Email: rg+ietf@qualcomm.com