idnits 2.17.00 (12 Aug 2021) /tmp/idnits46251/draft-ietf-ecrit-ecall-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2014) is 2763 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5491' is defined on line 1546, but no explicit reference was found in the text == Unused Reference: 'RFC6442' is defined on line 1555, but no explicit reference was found in the text -- No information found for draft-ietf-ecrit-additional-data - is the name correct? ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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 H. Tschofenig 5 Expires: April 29, 2015 (no affiliation) 6 October 26, 2014 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-01.txt 11 Abstract 13 This document describes how to use IP-based emergency services 14 mechanisms to support the next generation of the Pan European in- 15 vehicle emergency call service defined under the eSafety initiative 16 of the European Commission (generally referred to as "eCall"). eCall 17 is a standardized and mandated system for a special form of emergency 18 calls placed by vehicles. eCall deployment is required by 2015 in 19 European Union member states, and eCall (and eCall-compatible 20 systems) are also being deployed in other regions. eCall provides an 21 integrated voice path and a standardized set of vehicle, sensor 22 (e.g., crash related), and location data. An eCall is recognized and 23 handled as a specialized form of emergency call and is routed to a 24 specialized eCall-capable Public Safety Answering Point (PSAP) 25 capable of processing the vehicle data and trained in handling 26 emergency calls from vehicles. 28 Currently, eCall functions over circuit-switched cellular telephony; 29 work on next-generation eCall (NG-eCall, sometimes called packet- 30 switched eCall or PS-eCall) is now in process, and this document 31 assists in that work by describing how to support eCall within the 32 IP-based emergency services infrastructure. 34 This document also registers a MIME Content Type and an Emergency 35 Call Additional Data Block for the eCall vehicle data. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 29, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 6 75 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 7 76 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10 81 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11 82 9.1.1. The 'ack' Element . . . . . . . . . . . . . . . . . . 12 83 9.1.1.1. Attributes of the 'ack' Element . . . . . . . . . 12 84 9.1.1.2. Child Elements of the 'ack' Element . . . . . . . 13 85 9.1.2. The 'capabilities' Element . . . . . . . . . . . . . 13 86 9.1.2.1. Child Elements of the 'capabilities' Element . . 14 87 9.1.3. The 'request' Element . . . . . . . . . . . . . . . . 14 88 9.1.3.1. Attributes of the 'request' Element . . . . . . . 14 89 9.1.3.2. Child Elements of the 'request' Element . . . . . 16 90 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 17 91 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 95 13.1. Service URN Registrations . . . . . . . . . . . . . . . 22 96 13.2. MIME Content-type Registration for 97 'application/emergencyCallData.eCall.MSD+xml' . . . . . 22 98 13.3. MIME Content-type Registration for 99 'application/emergencyCallData.eCall.control+xml' . . . 24 100 13.4. Registration of the 'eCall.MSD' entry in the Emergency 101 Call Additional Data Blocks registry . . . . . . . . . . 25 102 13.5. Registration of the 'eCall.control' entry in the 103 Emergency Call Additional Data Blocks registry . . . . . 25 104 13.6. Registration of the emergencyCallData.eCall Info Package 26 105 13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 26 106 13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 26 107 13.7.2. Registration for 108 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 26 109 13.8. Registry creation . . . . . . . . . . . . . . . . . . . 27 110 13.8.1. eCall Control Action Registry . . . . . . . . . . . 27 111 13.8.2. eCall Static Message Registry . . . . . . . . . . . 28 112 13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 29 113 13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 30 114 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 115 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 116 16. Changes from Previous Versions . . . . . . . . . . . . . . . 31 117 16.1. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 31 118 16.2. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 32 119 16.3. Changes from draft-gellens-02 to -03 . . . . . . . . . . 32 120 16.4. Changes from draft-gellens-01 to -02 . . . . . . . . . . 32 121 16.5. Changes from draft-gellens-00 to -01 . . . . . . . . . . 32 122 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 123 17.1. Normative References . . . . . . . . . . . . . . . . . . 33 124 17.2. Informative references . . . . . . . . . . . . . . . . . 34 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 127 1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 This document re-uses terminology defined in Section 3 of [RFC5012]. 135 Additionally, we use the following abbreviations: 137 3GPP: 3rd Generation Partnership Project 138 CEN: European Committee for Standardization 139 EENA: European Emergency Number Association 140 ESInet: Emergency Services IP network 141 IMS: Internet Multimedia Subsystem 142 IVS: In-Vehicle System 143 MNO: Mobile Network Operator 144 MSD: Minimum Set of Data 145 PSAP: Public Safety Answering Point 147 2. Document Scope 149 This document is limited to the signaling, data exchange, and 150 protocol needs of next-generation eCall (NG-eCall, also referred to 151 as packet-switched eCall (PS-eCall) and all-IP eCall). eCall itself 152 is specified by 3GPP and CEN and these specifications include far 153 greater scope than is covered here. 155 The eCall service operates over cellular wireless communication, but 156 this document does not address cellular-specific details, nor client 157 domain selection (e.g., circuit-switched versus packet-switched). 158 All such aspects are the purview of their respective standards 159 bodies. The scope of this document is limited to eCall operating 160 within a SIP-based environment, such as 3GPP IMS Emergency Calling. 162 Vehicles designed for multiple regions may need to support eCall and 163 other Advanced Automatic Crash Notification systems, such as 164 described in [draft-ietf-ecrit-car-crash]. That system is compatible 165 with eCall in most respects, differing primarily in the Request-URI 166 and the specific data block that is sent. 168 3. Introduction 170 Emergency calls made from vehicles (e.g., in the event of a crash) 171 assist in significantly reducing road deaths and injuries by allowing 172 emergency services to be aware of the incident, the state of the 173 vehicle, the location of the vehicle, and to have a voice channel 174 with the vehicle occupants. This enables a quick and appropriate 175 response. 177 The European Commission initiative of eCall was conceived in the late 178 1990s, and has evolved to a European Parliament decision requiring 179 the implementation of compliant in-vehicle systems (IVS) in new 180 vehicles and the deployment of eCall in the European Member States in 181 2015. eCall (and eCall-compatible systems) are also being adopted in 182 other regions. 184 The pan-European eCall system provides a standardized and mandated 185 mechanism for emergency calls by vehicles. eCall establishes 186 procedures for such calls to be placed by in-vehicle systems, 187 recognized and processed by the network, and routed to a specialized 188 PSAP where the vehicle data is available to assist the call taker in 189 assessing and responding to the situation. eCall provides a standard 190 set of vehicle, sensor (e.g., crash related), and location data. 192 An eCall may be either user-initiated or automatically triggered. 193 Automatically triggered eCalls indicate a car crash or some other 194 serious incident (e.g., a fire) and carry a greater presumption of 195 risk of injury. Manually triggered eCalls may be reports of serious 196 hazards and are likely to require a different response than an 197 automatically triggered eCall. Manually triggered eCalls are also 198 more likely to be false (e.g., accidental) calls and may thus be 199 subject to different handling by the PSAP. 201 Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) 202 as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in 203 the call setup mark the call as an eCall, and further indicate if the 204 call was automatically or manually triggered. The call is routed to 205 an eCall-capable PSAP, a voice channel is established between the 206 vehicle and the PSAP, and an eCall in-band modem is used to carry a 207 defined set of vehicle, sensor (e.g., crash related), and location 208 data (the Minimum Set of Data or MSD) within the voice channel. The 209 same in-band mechanism is used for the PSAP to acknowledge successful 210 receipt of the MSD, and to request the vehicle to send a new MSD 211 (e.g., to check if the state of or location of the vehicle or its 212 occupants has changed). Work on next-generation eCall (NG-eCall, 213 also referred to as packet-switched eCall or PS eCall) is now in 214 process. As part of this work, the European Telecommunications 215 Standards Institute (ETSI) [SDO-ETSI] has published a Technical 216 Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] 217 that presents findings and recommendations regarding support for 218 eCall in an all-IP environment. NG-eCall moves from circuit switched 219 to all-IP, and carries the vehicle data and other eCall-specific data 220 as additional data associated with the call. This document describes 221 how IETF mechanisms for IP-based emergency calls, including [RFC6443] 222 and [additional-data-draft] are used to provide the signaling and 223 data exchange of the next generation of pan-European eCall. 225 NG-eCall is a 3GPP IMS emergency call with additional elements 226 identifying the call as an eCall and as carrying eCall data and with 227 mechanisms for carrying the data. 3GPP IMS emergency services 228 support multimedia, providing the ability to carry voice, text, and 229 video. This capability is referred to within 3GPP as Multimedia 230 Emergency Services (MMES). 232 A transition period will exist during which time the various entities 233 involved in initiating and handling an eCall might support next- 234 generation eCall, legacy eCall, or both. This transition period 235 might last several years or longer. The issue of migration/co- 236 existence during the transition period is very important but is 237 outside the scope of this document. The ETSI TR "Mobile Standards 238 Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in 239 Clause 7. 241 4. eCall Requirements 243 Overall eCall requirements are specified by by by CEN in [EN_16072] 244 and by 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements 245 specific to vehicle data are contained in EN 15722 [msd]. For 246 convenience, the requirements most applicable to the limited scope of 247 this document are summarized very briefly below. 249 eCall requires: 251 o The call be recognized as an eCall (which is inherently an 252 emergency call) 253 o The call setup indicates if the call was manually or automatically 254 triggered 255 o A voice channel between the vehicle and the PSAP 256 o Carrying the MSD intrinsically with the call (the MSD needs to be 257 available to the same call-taker as the voice) 258 o The ability for the PSAP to acknowledge receipt of the MSD 259 o The ability for the PSAP to request that the vehicle generate and 260 transmit a new MSD 261 o The ability of the PSAP to be able to re-contact the occupants of 262 vehicle after the initial eCall is concluded 263 o The ability to perform a test call (which may be routed to a PSAP 264 but is not treated as an emergency call and not handled by a call 265 taker) 267 It is recognized that NG-eCall offers many potential enhancements, 268 although these are not required by current EU regulations. For 269 convenience, the enhancements most applicable to the limited scope of 270 this document are summarized very briefly below. 272 NG-eCall is expected to offer: 274 o The ability to carry more data (e.g., an enhanced MSD or an MSD 275 plus additional sets of data) 276 o The ability to handle video 277 o The ability to handle text 278 o The ability for the PSAP to access vehicle components (e.g., an 279 onboard camera (such as rear facing or blind-spot cameras) for a 280 visual assessment of the crash site situation) 281 o The ability for the PSAP to request the vehicle to take actions 282 (e.g., sound the horn, disable the ignition, lock/unlock doors) 283 o The ability to avoid audio muting of the voice channel (because 284 the MSD is not transferred using an in-band modem) 286 5. Vehicle Data 288 Pan-European eCall provides a standardized and mandated set of 289 vehicle related data, known as the Minimum Set of Data (MSD). The 290 European Committee for Standardization (CEN) has specified this data 291 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 292 MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML 293 encoding is better suited for use in SIP messages and is used in this 294 document. (The ASN.1 encoding is specified in Annex A of EN 15722 295 [msd], while the XML encoding is specified in Annex C.) 297 The "Additional Data related to an Emergency Call" document 298 [additional-data-draft] establishes a general mechanism for attaching 299 blocks of data to a SIP emergency call. This document makes use of 300 that mechanism to carry the eCall MSD in a SIP emergency call. 302 This document registers the 'application/ 303 emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD 304 to be carried in SIP. This document also adds the 'eCall.MSD' entry 305 to the Emergency Call Additional Data Blocks registry (established by 306 [additional-data-draft]) to enable the MSD to be recognized as such 307 in a SIP-based eCall emergency call. 309 6. Call Setup 311 In circuit-switched eCall, the IVS places a special form of a 112 312 emergency call which carries the eCall flag (indicating that the call 313 is an eCall and also if the call was manually or automatically 314 triggered); the mobile network operator (MNO) recognizes the eCall 315 flag and routes the call to an eCall-capable PSAP; vehicle data is 316 transmitted to the PSAP via the eCall in-band modem (in the voice 317 channel). 319 ///----\\\ 112 voice call with eCall flag +------+ 320 ||| IVS |||---------------------------------------->+ PSAP | 321 \\\----/// vehicle data via eCall in-band modem +------+ 323 Figure 1: circuit-switched eCall 325 An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD 326 in accordance with [additional-data-draft] by encoding it as 327 specified (per Appendix C of EN 15722 [msd]) and attaching it to an 328 INVITE as a MIME body part. The body part is identified by its MIME 329 content-type ('application/emergencyCallData.eCall.MSD+xml') in the 330 Content-Type header field of the body part. The body part is 331 assigned a unique identifier which is listed in a Content-ID header 332 field in the body part. The INVITE is marked as containing the MSD 333 by adding (or appending to) a Call-Info header field at the top level 334 of the INVITE. This Call-Info header field contains a CID URL 335 referencing the body part's unique identifier, and a 'purpose' 336 parameter identifying the data as the eCall MSD per the registry 337 entry; the 'purpose' parameter's value is 'emergencyCallData.' and 338 the root of the MIME type (not including the 'emergencyCallData' 339 prefix and any suffix such as '+xml' (e.g., 340 'purpose=emergencyCallData.eCall.MSD'). 342 For NG-eCall, the IVS establishes an emergency call using the 3GPP 343 IMS solution with a Request-URI indicating an eCall type of emergency 344 call and with vehicle data attached; the MNO or ESInet recognizes the 345 eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP 346 interpets the vehicle data sent with the call and makes it available 347 to the call taker. 349 ///----\\\ IMS emergency call with eCall URN +------+ 350 IVS ----------------------------------------->+ PSAP | 351 \\\----/// vehicle data included in call setup +------+ 353 Figure 2: NG-eCall 355 This document registers new service URN children within the "sos" 356 subservice. These URNs provide the mechanism by which an eCall is 357 identified, and differentiate between manually and automatically 358 triggered eCalls (which may be subject to different treatment, 359 depending on policy). The two service URNs are: 360 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 362 7. Call Routing 364 The routing rules for eCalls are likely to differ from those of other 365 emergency calls because eCalls are special types of emergency calls 366 (with implications for the types of response required) and need to be 367 handled by specially designated PSAPs. In an environment that uses 368 ESInets, the originating network passes all types of emergency calls 369 to an ESInet (which have a request URI containing the "SOS" service 370 URN). The ESInet is then responsible for routing such calls to the 371 appropriate PSAP. In an environment without an ESInet, the emergency 372 services authorities and the originating network jointly determine 373 how such calls are routed. 375 7.1. ESInets 377 This section provides background information on ESInets for 378 information only. 380 An Emergency Services IP Network (ESInet) is a network operated by 381 emergency services authorities. It handles emergency call routing 382 and processing before delivery to a PSAP. In the NG1-1-2 383 architecture adopted by EENA, each PSAP is connected to one or more 384 ESInets. Each originating network is also connected to one or more 385 ESInets. The ESInets maintain policy-based routing rules which 386 control the routing and processing of emergency calls. The 387 centralization of such rules within ESInets provides for a cleaner 388 separation between the responsibilities of the originating network 389 and that of the emergency services network, and provides greater 390 flexibility and control over processing of emergency calls by the 391 emergency services authorities. This makes it easier to react 392 quickly to unusual situations that require changes in how emergency 393 calls are routed or handled (e.g., a natural disaster closes a PSAP), 394 as well as ease in making long-term changes that affect such routing 395 (e.g., cooperative agreements to specially handle calls requiring 396 translation or relay services). ESInets may support the ability to 397 interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that 398 are not IP PSAPs (similarly to the ability to interwork IP emergency 399 calls to legacy non-IP PSAPs). Note that in order to support legacy 400 eCall-capable PSAPs that are not IP PSAPs and are not attached to an 401 ESInet, an originating network may need the ability to route an eCall 402 itself (e.g., to an interworking facility with interconnection to a 403 suitable legacy eCall capable PSAP) based on the eCall and manual or 404 automatic indications. The ETSI TR "Mobile Standards Group (MSG); 405 eCall for VoIP" [MSG_TR] discusses transition issues in Clause 7. 407 8. Test Calls 409 eCall requires the ability to place test calls. These are calls that 410 are recognized and treated to some extent as eCalls but are not given 411 emergency call treatment and are not handled by call takers. The 412 test call facility allows the IVS or user to verify that an eCall can 413 be successfully established with voice communication. The IVS can 414 also verify that the MSD was successfully received. 416 A service URN starting with "test." indicates a test call. For 417 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 418 This functionality is defined in [RFC6881]. 420 This document registers "urn:service:test.sos.ecall" for eCall test 421 calls. 423 the current eCall test call facility is a non-emergency number so 424 does not get treated as an emergency call. MNOs may treat a vehicle 425 call in the "test" service URN in a way that tests as much 426 functionality as desired, but this is outside the scope of this 427 document. 429 PSAPs that have the ability to process NG-eCalls SHOULD accept test 430 calls and send an acknowledgment if the MSD was successfully 431 received, per this document. Such PSAPs MAY also play an audio clip 432 (for example, saying that the call reached a PSAP) in addition to 433 supporting media loopback per [RFC6881]. 435 9. eCall-Specific Control/Metadata 437 eCall requires the ability for the PSAP to acknowledge successful 438 receipt of an MSD sent by the IVS, and for the PSAP to request that 439 the IVS send an MSD (e.g., the call taker may initiate a request for 440 a new MSD to see if the vehicle's state or location has changed). 441 Future enhancements are desired to enable the PSAP to send other 442 requests to the vehicle, such as locking or unlocking doors, sounding 443 the horn, flashing the lights, starting a video stream from on-board 444 cameras (such as rear focus or blind-spot), etc. 446 The mechanism established in [additional-data-draft], used in 447 Section 5 of this document to carry the MSD from the IVS to the PSAP, 448 is also used to carry a block of control data from the PSAP to the 449 IVS. This eCall control block (sometimes referred to as eCall 450 metadata) is an XML structure containing eCall-specific elements. 451 When the PSAP needs to send an eCall control block that is in 452 response to the MSD or other data sent by the IVS in a SIP request, 453 the control block can be sent in the SIP response to that request 454 (e.g., the INVITE). When the PSAP needs to send an eCall control 455 block that is not an immediate response to an MSD or other data sent 456 by the IVS, the control block can be transmitted from the PSAP to the 457 IVS in a SIP INFO message within the established session. The IVS 458 can then send any requested data (such as a new MSD) in the reply to 459 the INFO message. This mechanism flexibly allows the PSAP to send 460 eCall-specific data to the IVS and the IVS to respond. If control 461 data sent in a response message requests the IVS to send a new MSD or 462 other data block, the IVS can do so in an INFO message within the 463 session (it could also use re-INVITE but that is unnecessary when no 464 aspect of the session or media is changing). 466 This mechanism requires 468 o An XML definition of the eCall control object 469 o An extension mechanism by which new elements can be added to the 470 control object definition (e.g., permitting additional elements to 471 be included by adding their namespace) 472 o A MIME type registration for the control object (so it can be 473 carried in SIP messages and responses) 474 o An entry in the Emergency Call Additional Data Blocks sub-registry 475 (established by [additional-data-draft]) so that the control block 476 can be recognized as emergency call specific data within the SIP 477 messages 478 o An Info-Package registration per [RFC6086] permitting the control 479 block within Info messages 481 9.1. The eCall Control Block 483 The eCall control block is an XML data structure allowing for 484 acknowledgments, requests, and capabilities information. It is 485 carried in a SIP body part with a specific MIME content type. Three 486 top-level elements are defined for use within an eCall control block: 488 ack Used in a control block sent by either side. The PSAP 489 uses this to acknowledge receipt of data set sent by 490 the IVS. The IVS uses this to acknowledge receipt of a 491 request by the PSAP when that request would not 492 otherwise be acknowledged (if the PSAP requests the 493 vehicle to send data and the vehicle does so, the data 494 serves as a success acknowledgement). 496 capabilities: Used in a control block sent from the IVS to the PSAP 497 (in the initial INVITE or subsequently if desired) to 498 inform the PSAP of the vehicle capabilities. Child 499 elements contain all actions and data types supported 500 by the vehicle . 502 request Used in a control block sent by the PSAP to the IVS, to 503 request the vehicle to perform an action. 505 Mandatory Actions (the IVS MUST support): 507 o Transmit data object 509 Optional Actions (the IVS MAY support): 511 o Play and/or display static (pre-defined) message 512 o Speak/display dynamic text (text supplied in action) 513 o Play dynamic audio (media supplied in SIP body part or in action) 514 o Flash lights, honk horn 516 The 'ack' element indicates the object being acknowledged, and 517 reports success or failure. 519 The 'capabilities' element has child 'request' elements to indicate 520 the actions supported by the IVS. 522 The 'request' element contains attributes to indicate the request and 523 to supply any needed information and MAY contain child elements 524 'text' and 'media' to contain the text or media for a dynamic 525 message. The 'action' attribute is mandatory and indicates the 526 specific action. An IANA registry is established by this document in 527 Section 13.8.1 to contain the allowed values. 529 New elements, child elements, and attributes can be defined with 530 their own sub-namespaces. IANA registries are used to specify the 531 permitted values of several elements and attributes. These 532 mechanisms allow for extension. 534 9.1.1. The 'ack' Element 536 The 'ack' element is transmitted by the PSAP to acknowledge receipt 537 of an eCall data object. An 'ack' element sent by a PSAP references 538 the unique ID of the data object that was sent by the IVS, and 539 further indicates if the PSAP considers the receipt successful or 540 not. The 'ack' element is also transmitted by the IVS to the PSAP to 541 acknowledge receipt of a 'request' element that requested the IVS to 542 perform an action other than transmitting a data object (e.g., a 543 request to display a message would be acknowledged, but a request to 544 transmit a data object would not result in a separate 'ack' element 545 being sent, since the data object itself serves as acknowledgment.) 546 An 'ack' element sent by an IVS references the unique ID of the 547 request being acknowledged, and further indicates whether the request 548 was successfully performed. 550 The 'ack' element has the following attributes and child elements: 552 9.1.1.1. Attributes of the 'ack' Element 554 The 'ack' element has the following attributes: 556 Name: ref 557 Usage: Mandatory 558 Type: anyURI 559 Description: References the Content-ID of the body part that 560 contained the data object or control object being acknowledged. 561 Example: 563 Name: rec 564 Usage: Mandatory 565 Type: Boolean 566 Description: Indicates if the referenced object was successfully 567 received or not. 568 Example: 570 9.1.1.2. Child Elements of the 'ack' Element 572 The 'ack' element has the following child elements: 574 Name: ActionResult 575 Usage: Optional 576 Description: An 'ActionResult' element indicates the result of an 577 action (other than a 'send-data' action). It has the following 578 attributes: 580 Name: action 581 Usage: Mandatory 582 Type: token 583 Description: Contains the value of the 'action' attribute of the 584 'request' element 586 Name: success 587 Usage: Mandatory 588 Type: Boolean 589 Description: Indicates if the action was successfully 590 accomplished 592 Name: reason 593 Usage: Conditional 594 Type: token 595 Description: Used when 'success' is "False", this attribute 596 contains a reason code for a failure. A registry for reason 597 codes is defined in Section 13.8.3. 599 Name: details 600 Usage: optional 601 Type: string 602 Description: Contains further explanation of the circumstances of 603 a success or failure. The contents are implementation-specific 604 and human-readable. 606 Example: 608 Example: 611 9.1.2. The 'capabilities' Element 613 The 'capabilities' element is transmitted by the IVS to indicate to 614 the PSAP its capabilities. No attributes are currently defined. The 615 following child elements may be used: 617 9.1.2.1. Child Elements of the 'capabilities' Element 619 The 'capabilities' element has the following child elements: 621 Name: request 622 Usage: Mandatory 623 Description: The 'capabilities' element contains a child 624 element per action supported by the vehicle. Because support for 625 a 'send-data' action is REQUIRED, a child element with a 626 "send-data" 'action' attribute is also REQUIRED. The 'supported- 627 datatype' attribute is REQUIRED in this element and MUST 628 contain all eCall data blocks supported by the IVS. Currently, 629 only the 'eCall.MSD' datatype is defined. All other actions are 630 OPTIONAL. If the "play-audio" action is supported, a 631 child element with a "play-audio" 'action' attribute is sent, with 632 a 'supported-mime' attribute set to all MIME content types 633 supported by the vehicle. If the "msg-static" action is 634 supported, a child element with a "msg-static" 'action' 635 attribute is sent, with a 'msgid' attribute set to the highest 636 supported static message supported by the vehicle. 637 Examples: 639 640 642 643 645 9.1.3. The 'request' Element 647 A 'request' element appears one or more times on its own or as a 648 child of a 'capabilities' element. The following attributes and 649 child elements may be used: 651 9.1.3.1. Attributes of the 'request' Element 653 The 'request' element has the following attributes: 655 Name: action 656 Usage: Mandatory 657 Type: token 658 Description: Identifies the action that the vehicle is requested to 659 perform. An IANA registry is established in Section 13.8.1 to 660 contain the allowed values. 661 Example: action="send-data" 663 Name: msgid 664 Usage: Conditional 665 Type: int 666 Description: Mandatory with a "msg-static" action. Indicates the 667 identifier of the static message to be displayed and/or spoken for 668 the vehicle occupants. This document established an IANA registry 669 for messages and their IDs, in Section 13.8.2 670 Example: msgid="3" 672 Name: persistance 673 Usage: Optional 674 Type: duration 675 Description: Specifies how long to carry on the specified action, 676 for example, how long to continue honking or flashing. If absent, 677 the default is indefinitely. 678 Example: persistance="PT1H" 680 Name: datatype 681 Usage: Conditional 682 Type: token 683 Description: Mandatory with a "send-data" action. Specifies the 684 data block that the IVS is requested to transmit, using the same 685 identifier as in the 'purpose' attribute set in a Call-Info header 686 field to point to the data block. Permitted values are contained 687 in the 'Emergency Call Data Types' IANA registry established in 688 [additional-data-draft]. 689 Example: datatype="eCall.MSD" 691 Name: ref 692 Usage: Conditional 693 Type: URI 694 Description: Mandatory with a "play-audio" action. References the 695 audio media to be played. A CID is used to reference an audio 696 body part contained in the same SIP message. An external URL 697 (e.g., HTTP) is used to reference external content. Note that 698 external references might not be accessible by the vehicle due to 699 a variety of transient or permanent conditions. 700 Example: ref="cid:5432154321@example.gov" 702 Name: supported-mime 703 Usage: Conditional 704 Type: token 705 Description: Used with a 'play-audio' action in a 'request' element 706 that is a child of a 'capability' element, this attribute lists 707 all MIME content types/subtypes that the vehicle can render. 708 Multiple values are separated with a semicolon. 709 Example: supported-mime="audio/3gpp; audio/3gpp2; audio/amr; audio/ 710 evrc" 712 Name: supported-datatype 713 Usage: Conditional 714 Type: token 715 Description: Used with a 'send-data' action in a 'request' element 716 that is a child of a 'capability' element, this attribute lists 717 all data blocks that the vehicle can transmit, using the same 718 identifier as in the 'purpose' attribute in a Call-Info header 719 field to point to the data block. Permitted values are contained 720 in the 'Emergency Call Data Types' IANA registry established in 721 [additional-data-draft]. Multiple values are separated with a 722 semicolon. 723 Example: supported-datatype="eCall.MSD; VEDS; eCall.foo" 725 Name: lamp-ID 726 Usage: Conditional 727 Type: token 728 Description: Used with a 'lamp' action, indicates which lamps the 729 action affects. This document creates a registry of lamp-ID 730 tokens, in Section 13.8.4 731 Example: lamp-ID="hazard" 733 Name: lamp-action 734 Usage: Conditional 735 Type: enumeration 736 Description: Used with a 'lamp' action, indicates if the lamp should 737 be illuminated, turned off, or flashed. Permitted values are 738 'on', 'off', and 'flash'. 739 Example: lamp-action="flash" 741 9.1.3.2. Child Elements of the 'request' Element 743 The 'request' element has the following child elements: 745 Name: text 746 Usage: Conditional 747 Type: string 748 Description: Used within a element to 749 contain the text to be displayed and/or spoken (via text-to- 750 speech) for the vehicle occupants. 751 Example: Emergency authorities are aware of your incident and 752 location. Due to a multi-vehicle incident in your area, no one is 753 able to speak with you right now. Please remain calm. We will 754 assist you soon. 756 Name: media 757 Usage: Optional 758 Type: base64Binary 759 Attribute: xmime:contentType (mandatory; contains the MIME content 760 type of the media) 762 Description: MAY be used within a 763 element to contain the media to be rendered for the vehicle 764 occupants. (The media may also be located in its own body part 765 and referenced by a CID URL, or may be external and referenced 766 with an external URL.) 767 Example: Rk9STQAABeZBSUZGQ09NTQAAABIAAgAAAW4AEEANrEQAAAAAAABT 768 U05EAAAFwAAA 769 AAAAAAAAAAAAABHqEeoiISIhL1ovWjiPOI89Gz0bPK48rjdmN2YtxC3EIJ0gnRET 770 ERMAagBq7/3v/eEd4R3U7dTtzGTMZMghyCHIaMhozSPNI9XY1djh0uHS8ALwAv88 771 /zwOSQ5JG/Yb9icwJzAvFC8UMxkzGTLxMvEuuS65JtEm0RvtG+0O/g7+AQoBCvND 772 80PmtOa03F3cXdUL1QvRR9FH0VbRVtUa1RrcQ9xD5ifmJ/H48fj+uv66C10LXRbi 773 FuIgayBrJzAnMCq4KrgqwirCJ2MnYyDpIOkX5hfmDSENIQF4AXj15fXl60zrTOKG 774 4obcQ9xD2PPY89jV2NXb1dvV4bThtOno6ejzvPO8/mT+ZAj9CP0SuRK5Gs4aziCY 775 IJgjsyOzI+Uj5SE0ITQb4xvjFHMUcwt1C3UBugG6+AT4BO8Q7xDnoeeh4kXiRd9e 776 317fId8h4YbhhuZU5lTtGu0a9Un1Sf4y/jIHGwcbD08PTxYnFicbHxsfHdUd1R4a 777 Hhob+xv7F6EXoRF4EXgKAgoCAdgB2Pmz+bPyK/Ir697r3udG50bkvuS+5G3kbeZP 778 5k/qQepB79rv2vap9qn+Hv4eBZIFkgyADIASTxJPFowWjBjsGOwZQhlCF5IXkhQE 779 FAQO6g7qCLcItwHnAef7DvsO9Lf0t+9c71zrb+tv6TfpN+jd6N3qX+pf7ZPtk/I6 780 8jr34Pfg/h7+HgRgBGAKNAo0Dx0PHRK+Er4U0hTSFTIVMhPcE9wQ9RD1DL0MvQeT 781 B5MB4gHi/Cj8KPbL9svyRPJE7uju6Oz87Pzsl+yX7crtyvBn8Gf0P/Q/+PT49P4o 782 /igDZQNlCE0ITQx7DHsPlA+UEWQRZBHCEcIQuBC4DlgOWArfCt8GkwaTAc4Bzv0E 783 /QT4gfiB9Kj0qPHL8cvwIPAg77vvu/Cn8Kfyy/LL9fn1+fnh+eH+PP48AqICogbG 784 BsYKTQpNDPQM9A6BDoEO5Q7lDhIOEgwmDCYJRAlEBbEFsQG6Abr9r/2v+eb55vap 785 9qn0NfQ18rvyu/Jd8l3zFvMW9NX01fdx93H6tPq0/lX+VQIFAgUFfgV+CH8IfwrB 786 CsEMGwwbDHsMewvaC9oKQwpDB+MH4wTtBO0BnAGc/jz+PPsI+wj4SvhK9jX2NfTu 787 9O70lfSV9SH1IfaQ9pD4ufi5+237bf5z/nMBiAGIBHoEegcCBwII7gjuChsKGwp2 788 CnYJ+An4CK0IrQa7BrsEQgRCAX0Bff6r/qv7+vv6+aT5pPfg9+D2xvbG9m32bfba 789 9tr4BPgE+cz5zPwJ/An+kv6SASgBKAOhA6EFxQXFB2oHaghwCHAIwQjBCGEIYQdW 790 B1YFuwW7A6sDqwFfAV/+//7//L/8v/rD+sP5P/k/+E/4T/f59/n4T/hP+T/5P/q5 791 +rn8lvyW/rX+tQDeAN4C8gLyBMAEwAYkBiQHBwcHB1YHVgcMBwwGNAY0BN4E3gMt 792 Ay0BPAE8/0H/Qf1Z/Vn7tPu0+mn6afmV+ZX5SvlK+Yv5i/pK+kr7gfuB/Q79Dv7T 793 /tMAoQChAmACYAPoA+gFGwUbBd4F3gYkBiQF7QXtBT0FPQQkBCQCuwK7AR4BHv94 794 /3j93P3c/HP8c/tZ+1n6pfql+mT6ZPqR+pH7Mfsx/C38Lf14/Xj+8f7xAHQAdAHs 795 AewDNwM3BDgEOATjBOMFJQUlBP0E/QRwBHADgwODAlsCWwEBAQH/oP+g/kb+Rv0Y 796 /Rj8KPwo+4v7i/tK+0r7bftt+/D78PzE/MT90v3S/wn/CQBRAFEBjQGNAqcCpwOD 797 A4MEFQQVBEwETAQuBC4DugO6AwEDAQIFAgUA6ADo/7//v/6c/pz9m/2b/M78zvxL 798 /Ev8DvwO/Cj8KPyR/JH9O/07/iP+I/8n/ycAMgAyATwBPAIuAi4C6ALoA2UDZQOc 799 A5wDgwODAygDKAKNAo0BugG6AM4Azv/Y/9j+4v7i 801 9.2. The emergencyCallData.eCall INFO package 803 This document registers the 'emergencyCallData.eCall' INFO package. 804 Both endpoints (the IVS and the PSAP equipment) set the Recv-Info 805 header field to 'emergencyCallData.eCall' per [RFC6086] to indicate 806 ability to receive INFO messages carrying eCall data or control 807 blocks. 809 Support for the 'emergencyCallData.eCall' INFO package indicates the 810 ability to receive eCall data and control blocks, which are carried 811 in a body part whose subtype starts with 'emergencyCallData.eCall.'. 812 At present there is only one defined eCall data block, which has the 813 'application/emergencyCallData.eCall.MSD+xml' MIME type, and one 814 eCall control block, which has the 'application/ 815 emergencyCallData.eCall.control+xml' MIME type. The eCall control 816 block includes the ability for the IVS to indicate its capabilities, 817 so in the event additional eCall blocks are defined, the IVS can 818 indicate which it supports. 820 The use of INFO is based on an analysis of the requirements against 821 the intent and effects of INFO versus other approaches (such as SIP 822 MESSAGE, media plane, or non-SIP protocols). In particular, the 823 transport of eCall data and control blocks is done only during an 824 emergency session established with SIP, using the mechanism 825 established in [additional-data-draft], and is normally carried in 826 the initial INVITE and its response; the use of INFO only occurs when 827 a data block or request needs to be sent subsequently during the 828 call. While MESSAGE could be used, it is not tied to a SIP session 829 as is INFO. REINVITE could also be used, but is normally used to 830 modify the session. SUBSCRIBE/NOTIFY could be coerced into service, 831 but the semantics are not a clean fit. Hence, INFO is appropriate. 833 An INFO request message carrying an eCall data or control block has 834 an Info-Package header field set to 'emergencyCallData.eCall' per 835 [RFC6086]. The INFO request message is marked as containing the 836 eCall data or control block by a Call-Info header field containing a 837 CID URL referencing the unique identifier of the body part containing 838 the eCall data or control, and a 'purpose' parameter identifying the 839 block. Because the eCall data or control block is being carried in 840 an INFO request message, the body part also carries a Content- 841 Disposition header field set to "Info-Package". 843 Per [additional-data-draft], emergency call related additional data 844 MAY be included in any SIP message. Hence, notwithstanding 845 Section 4.3.2. of [RFC6086], INFO response messages MAY contain eCall 846 data or control blocks, provided they are included as described in 847 this document (with a Call-Info header field containing a CID URL 848 referencing the unique identifier of the body part, and a 'purpose' 849 parameter identifying the block). When eCall data or control blocks 850 are included in an INFO response message, this is done per 851 [additional-data-draft] and this document, and not under [RFC6086]; 852 that is, they are included as emergency call additional data, not as 853 an INFO package associated data. 855 10. Examples 857 Figure 3 shows an eCall. The call uses the request URI 858 'urn:service:sos.ecall.automatic' service URN and is recognized as an 859 eCall, and further as one that was invoked automatically by the IVS 860 due to a crash or other serious incident. In this example, the 861 originating network routes the call to an ESInet (as for any 862 emergency call in an environment with an ESInet). The ESInet routes 863 the call to the appropriate NG-eCall capable PSAP. The emergency 864 call is received by the ESInet's Emergency Services Routing Proxy 865 (ESRP), as the entry point into the ESInet. The ESRP routes the call 866 to a PSAP, where it is received by a call taker. In deployments 867 where there is no ESInet, the originating network routes the call 868 directly to the appropriate NG-eCall capable PSAP. 870 +------------+ +---------------------------------------+ 871 | | | +-------+ | 872 | | | | PSAP2 | | 873 | | | +-------+ | 874 | | | | 875 | | | +------+ +-------+ | 876 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 877 | | | +------+ +-------+ | 878 | | | | 879 | | | +-------+ | 880 | | | | PSAP3 | | 881 | Originating| | +-------+ | 882 | Mobile | | | 883 | Network | | ESInet | 884 +------------+ +---------------------------------------+ 886 Figure 3: Example of NG-eCall Message Flow 888 The example, shown in Figure 4, illustrates a SIP eCall INVITE that 889 contains an MSD. 891 INVITE urn:service:sos.ecall.automatic SIP/2.0 892 To: urn:service:sos.ecall.automatic 893 From: ;tag=9fxced76sl 894 Call-ID: 3848276298220188511@atlanta.example.com 895 Geolocation: 896 Geolocation-Routing: no 897 Call-Info: cid:1234567890@atlanta.example.com; 898 purpose=emergencyCallData.eCall.MSD 899 Accept: application/sdp, application/pidf+xml 900 CSeq: 31862 INVITE 901 Recv-Info: emergencyCallData.eCall 902 Content-Type: multipart/mixed; boundary=boundary1 903 Content-Length: ... 905 --boundary1 907 Content-Type: application/sdp 909 ...Session Description Protocol (SDP) goes here 911 --boundary1 913 Content-Type: application/emergencyCallData.eCall.MSD+xml 914 Content-ID: 1234567890@atlanta.example.com 916 ...eCall MSD data object goes here 918 --boundary1-- 920 Figure 4: SIP NG-eCall INVITE 922 11. Security Considerations 924 The security considerations described in [RFC5069] apply here. 926 An eCall will carry two forms of location data: the network-provided 927 location that is inherently part of IMS emergency calls (which might 928 be determined solely by the network, or in cooperation with or 929 possibly entirely by the originating device), and the IVS-supplied 930 location within the MSD. This is likely to be useful to the PSAP, 931 especially when the two locations are independently determined. Even 932 in situations where the network-supplied location is limited to the 933 cell site, this can be useful as a sanity check on the device- 934 supplied location contained in the MSD. 936 The document [I-D.ietf-ecrit-trustworthy-location] discusses trust 937 issues regarding location provided by or determined in cooperation 938 with end devices. 940 The mechanism by which the PSAP sends acknowledgments and requests to 941 the vehicle requires authenticity considerations; when the PSAP 942 request is received within a session initiated by the vehicle as an 943 eCall emergency call placed over a cellular network, there is a 944 higher degree of trust that the source is indeed a PSAP. If the PSAP 945 request is received in other situations, such as a call-back, the 946 trust issues in verifying that a call-back is indeed from a PSAP are 947 more complex (see the PSAP Callback document [RFC7090]). A further 948 safeguard (applicable regardless of which end initiated the call and 949 the means of the call) is for the PSAP or emergency service provider 950 to sign the body part using a certificate issued by a known emergency 951 services certificate authority and for which the IVS can verify the 952 root certificate. 954 12. XML Schema 956 This section defines the XML schema of the eCall control block. 958 959 964 967 970 971 972 973 974 976 977 978 979 981 983 Figure 5: eCall Control Block Schema 985 13. IANA Considerations 987 13.1. Service URN Registrations 989 IANA is requested to register the URN 'urn:service:sos.ecall' under 990 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 992 This service identifies a type of emergency call (placed by a 993 specialized in-vehicle system and a carrying standardized set of data 994 related to the vehicle and crash or incident, and is needed to direct 995 the call to a specialized public safety answering point (PSAP) with 996 technical and operational capabilities to handle such calls. Two 997 sub-services are registered as well, namely 999 urn:service:sos.ecall.manual 1001 This service URN indicates that an eCall had been triggered based 1002 on the manual interaction of the driver or a passenger. 1004 urn:service:sos.ecall.automatic 1006 This service URN indicates that an eCall had been triggered 1007 automatically, for example, due to a crash or other serious 1008 incident (e.g., fire). 1010 IANA is also requested to register the URN 1011 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1012 defined in Setcion 17.2 of [RFC6881]. 1014 13.2. MIME Content-type Registration for 'application/ 1015 emergencyCallData.eCall.MSD+xml' 1017 IANA is requested to add application/emergencyCallData.eCall.MSD+xml 1018 as a MIME content type, with a reference to this document, in 1019 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1020 RFC 7303 [RFC7303]. 1022 MIME media type name: application 1024 MIME subtype name: emergencyCallData.eCall.MSD+xml 1026 Mandatory parameters: none 1028 Optional parameters: charset 1030 Indicates the character encoding of the XML content. 1032 Encoding considerations: Uses XML, which can employ 8-bit 1033 characters, depending on the character encoding used. See 1034 Section 3.2 of RFC 7303 [RFC7303]. 1036 Security considerations: This content type is designed to carry 1037 vehicle and incident-related data during an emergency call. This 1038 data contains personal information including vehicle VIN, 1039 location, direction, etc. Appropriate precautions need to be 1040 taken to limit unauthorized access, inappropriate disclosure to 1041 third parties, and eavesdropping of this information. In general, 1042 it is permissible for the data to be unprotected while briefly in 1043 transit within the Mobile Network Operator (MNO); the MNO is 1044 trusted to not permit the data to be accessed by third parties. 1045 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1046 contain more discussion. 1048 Interoperability considerations: None 1050 Published specification: Annex C of EN 15722 [msd] 1052 Applications which use this media type: Pan-European eCall 1053 compliant systems 1055 Additional information: None 1057 Magic Number: None 1059 File Extension: .xml 1061 Macintosh file type code: 'TEXT' 1063 Person and email address for further information: Hannes 1064 Tschofenig, Hannes.Tschofenig@gmx.net 1066 Intended usage: LIMITED USE 1068 Author: This specification was produced by the European Committee 1069 For Standardization (CEN). For contact information, please see 1070 . 1072 Change controller: The European Committee For Standardization 1073 (CEN) 1075 13.3. MIME Content-type Registration for 'application/ 1076 emergencyCallData.eCall.control+xml' 1078 IANA is requested to add application/ 1079 emergencyCallData.eCall.control+xml as a MIME content type, with a 1080 reference to this document, in accordance to the procedures of RFC 1081 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1083 MIME media type name: application 1085 MIME subtype name: emergencyCallData.eCall.control+xml 1087 Mandatory parameters: none 1089 Optional parameters: charset 1091 Indicates the character encoding of the XML content. 1093 Encoding considerations: Uses XML, which can employ 8-bit 1094 characters, depending on the character encoding used. See 1095 Section 3.2 of RFC 7303 [RFC7303]. 1097 Security considerations: This content type carries metadata and 1098 control information and requests, primarily from a Public Safety 1099 Answering Point (PSAP) to an In-Vehicle System (IVS) during an 1100 emergency call, and also capabilities from the IVS to the PSAP. 1101 Metadata (such as an acknowledgment that data sent by the IVS to 1102 the PSAP was successfully received) has limited privacy and 1103 security implications. Control information (such as requests from 1104 the PSAP that the vehicle perform an action) has some privacy and 1105 important security implications. The privacy concern arises from 1106 the ability to request the vehicle to transmit a data set, which 1107 as described in Section 13.2, may contain personal information. 1108 The security implication is the ability to request the vehicle to 1109 perform an action. It is important that control information 1110 originate only from a PSAP or other emergency services provider, 1111 and not from an impostor. The first safeguard for this is the 1112 security of the cellular network over which the emergency call was 1113 placed. In particular, when the IVS initiates an eCall over a 1114 cellular network, the MNO routes the call to a PSAP. (Calls 1115 placed using other means, such as Wi-Fi or over-the-top services, 1116 do not carry the same degree of trust.) Calls received by the 1117 IVS, such as a call-back from a PSAP, also do not carry the same 1118 degree of trust, since the current mechanisms are not ideal for 1119 verifying that such a call is indeed from a PSAP in response to an 1120 emergency call placed by the IVS. See the discussion in 1121 Section 11 and the PSAP Callback document [RFC7090]. A further 1122 safeguard, and one applicable regardless of which end initiated 1123 the call and the means of the call, is for the PSAP or emergency 1124 service provider to sign the body part using a certificate issued 1125 by a known emergency services certificate authority and for which 1126 the IVS can verify the root certificate. Sections 7 and Section 8 1127 of [I-D.ietf-ecrit-additional-data] contain more discussion. 1129 Interoperability considerations: None 1131 Published specification: Annex C of EN 15722 [msd] 1133 Applications which use this media type: Pan-European eCall 1134 compliant systems 1136 Additional information: None 1138 Magic Number: None 1140 File Extension: .xml 1142 Macintosh file type code: 'TEXT' 1144 Person and email address for further information: Randall Gellens, 1145 rg+ietf@qti.qualcomm.com 1147 Intended usage: LIMITED USE 1149 Author: The IETF ECRIT WG. 1151 Change controller: The IETF ECRIT WG. 1153 13.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1154 Additional Data Blocks registry 1156 This specification requests IANA to add the 'eCall.MSD' entry to the 1157 Emergency Call Additional Data Blocks registry (established by 1158 [additional-data-draft]), with a reference to this document. 1160 13.5. Registration of the 'eCall.control' entry in the Emergency Call 1161 Additional Data Blocks registry 1163 This specification requests IANA to add the 'eCall.control' entry to 1164 the Emergency Call Additional Data Blocks registry (established by 1165 [additional-data-draft]), with a reference to this document. 1167 13.6. Registration of the emergencyCallData.eCall Info Package 1169 IANA is requested to add emergencyCallData.eCall to the Info Packages 1170 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1171 reference to this document. 1173 13.7. URN Sub-Namespace Registration 1175 13.7.1. Registration for urn:ietf:params:xml:ns:eCall 1177 This section registers a new XML namespace, as per the guidelines in 1178 RFC 3688 [RFC3688]. 1180 URI: urn:ietf:params:xml:ns:eCall 1182 Registrant Contact: IETF, ECRIT working group, , as 1183 delegated by the IESG . 1185 XML: 1187 BEGIN 1188 1189 1191 1192 1193 1195 Namespace for eCall Data 1196 1197 1198

Namespace for eCall Data 1199

1200

See [TBD: This document].

1201 1202 1203 END 1205 13.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1207 This section registers a new XML namespace, as per the guidelines in 1208 RFC 3688 [RFC3688]. 1210 URI: urn:ietf:params:xml:ns:eCall:control 1211 Registrant Contact: IETF, ECRIT working group, , as 1212 delegated by the IESG . 1214 XML: 1216 BEGIN 1217 1218 1220 1221 1222 1224 Namespace for eCall Data: 1225 Control Block 1226 1227 1228

Namespace for eCall Data 1229

1230

Control Block

1231

See [TBD: This document].

1232 1233 1234 END 1236 13.8. Registry creation 1238 This document creates a new registry called 'eCall Control Data'. 1239 The following sub-registries are created for this registry. 1241 13.8.1. eCall Control Action Registry 1243 This document creates a new sub-registry called "eCall Control Action 1244 Registry". As defined in [RFC5226], this registry operates under 1245 "Expert Review" rules. The expert should determine that the proposed 1246 action is within the purview of a vehicle, is sufficiently 1247 distinguishable from other actions, and the actions is clearly and 1248 fully described. In most cases, a published and stable document is 1249 referenced for the description of the action. 1251 The content of this registry includes: 1253 Name: The identifier to be used in the 'action' attribute of an 1254 eCall control 'request' element. 1256 Description: A description of the action. In most cases this will 1257 be a reference to a published and stable document. The 1258 description MUST specify if any attributes or child elements are 1259 optional or mandatory, and describe the action to be taken by the 1260 vehicle. 1262 The initial set of values is listed in Table 1. 1264 +-------------+------------------------------+ 1265 | Name | Description | 1266 +-------------+------------------------------+ 1267 | send-data | Section xxx of this document | 1268 | | | 1269 | msg-static | Section xxx of this document | 1270 | | | 1271 | msg-dynamic | Section xxx of this document | 1272 | | | 1273 | play-audio | Section xxx of this document | 1274 | | | 1275 | honk | Section xxx of this document | 1276 | | | 1277 | lamp | Section xxx of this document | 1278 +-------------+------------------------------+ 1280 Table 1: eCall Control Action Registry Initial Values 1282 13.8.2. eCall Static Message Registry 1284 This document creates a new sub-registry called "eCall Static Message 1285 Registry". Because all compliant vehicles are expected to support 1286 all static messages translated into all languages supported by the 1287 vehicle, it is important to limit the number of such messages. As 1288 defined in [RFC5226], this registry operates under "Publication 1289 Required" rules, which require a stable, public document and imply 1290 expert review of the publication. The expert should determine that 1291 the document has been published by an appropriate emergency services 1292 organization (e.g., NENA, EENA, APCO) and that the proposed message 1293 is sufficiently distinguishable from other messages. 1295 The content of this registry includes: 1297 ID: An integer identifier to be used in the 'msgid' attribute of an 1298 eCall control 'request' element. 1300 Message: The text of the message. Messages are listed in the 1301 registry in English; vehicles are expected to implement 1302 translations into languages supported by the vehicle. 1304 When new messages are added to the registry, the message text is 1305 determined by the registrant; IANA assigns the IDs. Each message is 1306 assigned a consecutive integer value as its ID. This allows an IVS 1307 to indicate by a single integer value that it supports all messages 1308 with that value or lower. 1310 The initial set of values is listed in Table 2. 1312 +----+--------------------------------------------------------------+ 1313 | ID | Message | 1314 +----+--------------------------------------------------------------+ 1315 | 1 | Emergency authorities are aware of your incident and | 1316 | | location. No one is free to speak with you right now. We | 1317 | | will help you as soon as possible. | 1318 +----+--------------------------------------------------------------+ 1320 Table 2: eCall Static Message Registry 1322 13.8.3. eCall Reason Registry 1324 This document creates a new sub-registry called "eCall Reason 1325 Registry" which contains values for the 'reason' attribute of the 1326 'ActionResult' element. As defined in [RFC5226], this registry 1327 operates under "Expert Review" rules. The expert should determine 1328 that the proposed reason is sufficiently distinguishable from other 1329 reasons and that the proposed description is understandable and 1330 correctly worded. 1332 The content of this registry includes: 1334 ID: A short string identifying the reason, for use in the 'reason' 1335 attribute of an 'ActionResult' element. 1337 Description: A description of the reason. 1339 The initial set of values is listed in Table 3. 1341 +------------------+------------------------------------------------+ 1342 | ID | Description | 1343 +------------------+------------------------------------------------+ 1344 | unsupported | The 'action' is not supported. | 1345 | | | 1346 | unable | The 'action' could not be accomplished. | 1347 | | | 1348 | data-unsupported | The data item referenced in a 'send-data' | 1349 | | request is not supported. | 1350 +------------------+------------------------------------------------+ 1352 Table 3: eCall Reason Registry 1354 13.8.4. eCall Lamp ID Registry 1356 This document creates a new sub-registry called "eCall Lamp ID 1357 Registry" to standardize the names of automotive lamps (lights). As 1358 defined in [RFC5226], this registry operates under "Expert Review" 1359 rules. The expert should determine that the proposed lamp name is 1360 clearly understandable and is sufficiently distinguishable from other 1361 lamp names. 1363 The content of this registry includes: 1365 Name: The identifier to be used in the 'lamp-ID' attribute of an 1366 eCall control 'request' element. 1368 Description: A description of the lamp (light). 1370 The initial set of values is listed in Table 4. 1372 +----------------+---------------------------------------------+ 1373 | Name | Description | 1374 +----------------+---------------------------------------------+ 1375 | head | The main lamps used to light the road ahead | 1376 | | | 1377 | interior | Interior lamp, often at the top center | 1378 | | | 1379 | fog-front | Front fog lamps | 1380 | | | 1381 | fog-rear | Rear fog lamps | 1382 | | | 1383 | brake | Brake indicator lamps | 1384 | | | 1385 | position-front | Front position/parking/standing lamps | 1386 | | | 1387 | position-rear | Rear position/parking/standing lamps | 1388 | | | 1389 | turn-left | Left turn/directional lamps | 1390 | | | 1391 | turn-right | Right turn/directional lamps | 1392 | | | 1393 | hazard | Hazard/four-way lamps | 1394 +----------------+---------------------------------------------+ 1396 Table 4: eCall Lamp ID Registry Initial Values 1398 14. Contributors 1400 Brian Rosen was a co-author of the original document upon which this 1401 document is based. 1403 15. Acknowledgements 1405 We would like to thank Bob Williams and Ban Al-Bakri for their 1406 feedback and suggestions, and Keith Drage for his review comments. 1407 We would like to thank Michael Montag, Arnoud van Wijk, Gunnar 1408 Hellstrom, and Ulrich Dietz for their help with the original document 1409 upon which this document is based. 1411 16. Changes from Previous Versions 1413 16.1. Changes from draft-ietf-00 to draft-ietf-01 1415 o Added further discussion of test calls 1417 o Added further clarification to the document scope 1418 o Mentioned that multi-region vehicles may need to support other 1419 crash notification specifications in addition to eCall 1421 o Added details of the eCall metadata and control functionality 1423 o Added IANA registration for the MIME content type for the eCall 1424 control object 1426 o Added IANA registries for protocol elements and tokens used in the 1427 eCall control object 1429 o Minor wording improvements and clarifications 1431 16.2. Changes from draft-gellens-03 to draft-ietf-00 1433 o Renamed from draft-gellens- to draft-ietf-. 1435 o Added mention of and reference to ETSI TR "Mobile Standards Group 1436 (MSG); eCall for VoIP" 1438 o Added text to Introduction regarding migration/co-existence being 1439 out of scope 1441 o Added mention in Security Considerations that even if the network- 1442 supplied location is just the cell site, this can be useful as a 1443 sanity check on the IVS-supplied location 1445 o Minor wording improvements and clarifications 1447 16.3. Changes from draft-gellens-02 to -03 1449 o Clarifications and editorial improvements. 1451 16.4. Changes from draft-gellens-01 to -02 1453 o Minor wording improvements 1455 o Removed ".automatic" and ".manual" from 1456 "urn:service:test.sos.ecall" registration and discussion text. 1458 16.5. Changes from draft-gellens-00 to -01 1460 o Now using 'EmergencyCallData' for purpose parameter values and 1461 MIME subtypes, in accordance with changes to 1462 [additional-data-draft] 1464 o Added reference to RFC 6443 1465 o Fixed bug that caused Figure captions to not appear 1467 17. References 1469 17.1. Normative References 1471 [EN_16072] 1472 CEN, , "Intelligent transport systems - eSafety - Pan- 1473 European eCall operating requirements", December 2011. 1475 [I-D.ietf-ecrit-additional-data] 1476 Randy, R., Rosen, B., Tschofenig, H., Marshall, R., and J. 1477 Winterbottom, "Additional Data related to an Emergency 1478 Call", draft-ietf-ecrit-additional-data-24 (work in 1479 progress), October 2014. 1481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1482 Requirement Levels", BCP 14, RFC 2119, March 1997. 1484 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1485 January 2004. 1487 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1488 Emergency and Other Well-Known Services", RFC 5031, 1489 January 2008. 1491 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1492 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1493 May 2008. 1495 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1496 "Framework for Emergency Calling Using Internet 1497 Multimedia", RFC 6443, December 2011. 1499 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1500 Specifications and Registration Procedures", BCP 13, RFC 1501 6838, January 2013. 1503 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1504 Communications Services in Support of Emergency Calling", 1505 BCP 181, RFC 6881, March 2013. 1507 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1508 July 2014. 1510 [TS22.101] 1511 3GPP, , "Technical Specification Group Services and System 1512 Aspects; Service aspects; Service principles", . 1514 [additional-data-draft] 1515 Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and 1516 J. Winterbottom, "Additional Data related to an Emergency 1517 Call", draft-ietf-ecrit-additional-data-11 (work in 1518 progress), July 2013. 1520 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1521 minimum set of data (MSD), EN 15722", June 2011. 1523 17.2. Informative references 1525 [CEN] "European Committee for Standardization", 1526 . 1528 [I-D.ietf-ecrit-trustworthy-location] 1529 Tschofenig, H., Schulzrinne, H., and B. Aboba, 1530 "Trustworthy Location", draft-ietf-ecrit-trustworthy- 1531 location-14 (work in progress), July 2014. 1533 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1534 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1535 April 2014. 1537 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1538 Emergency Context Resolution with Internet Technologies", 1539 RFC 5012, January 2008. 1541 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1542 Shanmugam, "Security Threats and Requirements for 1543 Emergency Call Marking and Mapping", RFC 5069, January 1544 2008. 1546 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1547 Presence Information Data Format Location Object (PIDF-LO) 1548 Usage Clarification, Considerations, and Recommendations", 1549 RFC 5491, March 2009. 1551 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1552 Initiation Protocol (SIP) INFO Method and Package 1553 Framework", RFC 6086, January 2011. 1555 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1556 for the Session Initiation Protocol", RFC 6442, December 1557 2011. 1559 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1560 Patel, "Public Safety Answering Point (PSAP) Callback", 1561 RFC 7090, April 2014. 1563 [SDO-3GPP] 1564 "3d Generation Partnership Project", 1565 . 1567 [SDO-ETSI] 1568 "European Telecommunications Standards Institute (ETSI)", 1569 . 1571 [draft-ietf-ecrit-car-crash] 1572 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1573 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1574 ecrit-car-crash (work in progress), October 2014. 1576 Authors' Addresses 1578 Randall Gellens 1579 Qualcomm Technologies, Inc. 1580 5775 Morehouse Drive 1581 San Diego 92651 1582 US 1584 Email: rg+ietf@qti.qualcomm.com 1586 Hannes Tschofenig 1587 (no affiliation) 1589 Email: Hannes.Tschofenig@gmx.net 1590 URI: http://www.tschofenig.priv.at