idnits 2.17.00 (12 Aug 2021) /tmp/idnits58650/draft-ietf-ecrit-ecall-04.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 are 18 instances of too long lines in the document, the longest one being 8 characters 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 date (October 18, 2015) is 2406 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-ecrit-additional-data - is the name correct? ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 20, 2016 (Individual) 6 October 18, 2015 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-04.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 in the very 19 near future in European Union member states, and eCall (and eCall- 20 compatible systems) are also being deployed in other regions. eCall 21 provides an integrated voice path and a standardized set of vehicle, 22 sensor (e.g., crash related), and location data. An eCall is 23 recognized and handled as a specialized form of emergency call and is 24 routed to a specialized eCall-capable Public Safety Answering Point 25 (PSAP) 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 20, 2016. 54 Copyright Notice 56 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 78 7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9. eCall-Specific Control/Metadata . . . . . . . . . . . . . . . 10 81 9.1. The eCall Control Block . . . . . . . . . . . . . . . . . 11 82 9.1.1. The element . . . . . . . . . . . . . . . . . . 12 83 9.1.1.1. Attributes of the element . . . . . . . . . 13 84 9.1.1.2. Child Elements of the element . . . . . . . 13 85 9.1.1.3. Ack Examples . . . . . . . . . . . . . . . . . . 14 86 9.1.2. The element . . . . . . . . . . . . . 15 87 9.1.2.1. Child Elements of the element . . 15 88 9.1.2.2. Capabilities Example . . . . . . . . . . . . . . 16 89 9.1.3. The element . . . . . . . . . . . . . . . . 16 90 9.1.3.1. Attributes of the element . . . . . . . 17 91 9.1.3.2. Child Elements of the element . . . . . 19 92 9.1.3.3. Request Example . . . . . . . . . . . . . . . . . 19 93 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 20 94 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 26 97 13. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 99 14.1. Service URN Registrations . . . . . . . . . . . . . . . 29 100 14.2. MIME Content-type Registration for 101 'application/emergencyCallData.eCall.MSD+xml' . . . . . 30 102 14.3. MIME Content-type Registration for 103 'application/emergencyCallData.eCall.control+xml' . . . 31 104 14.4. Registration of the 'eCall.MSD' entry in the Emergency 105 Call Additional Data Blocks registry . . . . . . . . . . 33 106 14.5. Registration of the 'eCall.control' entry in the 107 Emergency Call Additional Data Blocks registry . . . . . 33 108 14.6. Registration of the emergencyCallData.eCall Info Package 33 109 14.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 33 110 14.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 33 111 14.7.2. Registration for 112 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 34 113 14.8. Registry creation . . . . . . . . . . . . . . . . . . . 35 114 14.8.1. eCall Control Action Registry . . . . . . . . . . . 35 115 14.8.2. eCall Static Message Registry . . . . . . . . . . . 36 116 14.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 37 117 14.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 37 118 14.8.5. eCall Camera ID Registry . . . . . . . . . . . . . . 38 119 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39 120 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 121 17. Changes from Previous Versions . . . . . . . . . . . . . . . 39 122 17.1. Changes from draft-ietf-02 to draft-ietf-03 . . . . . . 39 123 17.2. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 39 124 17.3. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 40 125 17.4. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 40 126 17.5. Changes from draft-gellens-02 to -03 . . . . . . . . . . 40 127 17.6. Changes from draft-gellens-01 to -02 . . . . . . . . . . 40 128 17.7. Changes from draft-gellens-00 to -01 . . . . . . . . . . 40 129 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 130 18.1. Normative References . . . . . . . . . . . . . . . . . . 41 131 18.2. Informative references . . . . . . . . . . . . . . . . . 42 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 134 1. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 This document re-uses terminology defined in Section 3 of [RFC5012]. 142 Additionally, we use the following abbreviations: 144 +--------+----------------------------------------+ 145 | Term | Expansion | 146 +--------+----------------------------------------+ 147 | 3GPP | 3rd Generation Partnership Project | 148 | CEN | European Committee for Standardization | 149 | EENA | European Emergency Number Association | 150 | ESInet | Emergency Services IP network | 151 | IMS | Internet Multimedia Subsystem | 152 | IVS | In-Vehicle System | 153 | MNO | Mobile Network Operator | 154 | MSD | Minimum Set of Data | 155 | PSAP | Public Safety Answering Point | 156 +--------+----------------------------------------+ 158 2. Document Scope 160 This document is limited to the signaling, data exchange, and 161 protocol needs of next-generation eCall (NG-eCall, also referred to 162 as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP 163 framework for emergency calls, as described in [RFC6443] and 164 [RFC6881]. eCall itself is specified by 3GPP and CEN and these 165 specifications include far greater scope than is covered here. 167 The eCall service operates over cellular wireless communication, but 168 this document does not address cellular-specific details, nor client 169 domain selection (e.g., circuit-switched versus packet-switched). 170 All such aspects are the purview of their respective standards 171 bodies. The scope of this document is limited to eCall operating 172 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 174 The technical contents of this document can be suitable for use in 175 other vehicle-initiated emergency call systems, but this is out of 176 scope for this document. 178 Vehicles designed for multiple regions might need to support eCall 179 and other Advanced Automatic Crash Notification (AACN) systems, such 180 as described in [draft-ietf-ecrit-car-crash]. That system is 181 compatible with eCall, differing primarily in the specific data set 182 that is sent. 184 3. Introduction 186 Emergency calls made from vehicles (e.g., in the event of a crash) 187 assist in significantly reducing road deaths and injuries by allowing 188 emergency services to be aware of the incident, the state of the 189 vehicle, the location of the vehicle, and to have a voice channel 190 with the vehicle occupants. This enables a quick and appropriate 191 response. 193 The European Commission initiative of eCall was conceived in the late 194 1990s, and has evolved to a European Parliament decision requiring 195 the implementation of compliant in-vehicle systems (IVS) in new 196 vehicles and the deployment of eCall in the European Member States in 197 the very near future. eCall (and eCall-compatible systems) are also 198 being adopted in other regions. 200 The pan-European eCall system provides a standardized and mandated 201 mechanism for emergency calls by vehicles. eCall establishes 202 procedures for such calls to be placed by in-vehicle systems, 203 recognized and processed by the network, and routed to a specialized 204 PSAP where the vehicle data is available to assist the call taker in 205 assessing and responding to the situation. eCall provides a standard 206 set of vehicle, sensor (e.g., crash related), and location data. 208 An eCall can be either user-initiated or automatically triggered. 209 Automatically triggered eCalls indicate a car crash or some other 210 serious incident and carry a greater presumption of risk of injury. 211 Manually triggered eCalls might be reports of serious hazards and are 212 likely to require a different response than an automatically 213 triggered eCall. Manually triggered eCalls are also more likely to 214 be false (e.g., accidental) calls and so might be subject to 215 different operational handling by the PSAP. 217 Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) 218 as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in 219 the call setup mark the call as an eCall, and further indicate if the 220 call was automatically or manually triggered. The call is routed to 221 an eCall-capable PSAP, a voice channel is established between the 222 vehicle and the PSAP, and an eCall in-band modem is used to carry a 223 defined set of vehicle, sensor (e.g., crash related), and location 224 data (the Minimum Set of Data or MSD) within the voice channel. The 225 same in-band mechanism is used for the PSAP to acknowledge successful 226 receipt of the MSD, and to request the vehicle to send a new MSD 227 (e.g., to check if the state of or location of the vehicle or its 228 occupants has changed). Work on next-generation eCall (NG-eCall, 229 also referred to as packet-switched eCall or PS eCall) is now in 230 process. As part of this work, the European Telecommunications 231 Standards Institute (ETSI) [SDO-ETSI] has published a Technical 232 Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] 233 that presents findings and recommendations regarding support for 234 eCall in an all-IP environment. NG-eCall moves from circuit switched 235 to all-IP, and carries the vehicle data and other eCall-specific data 236 as additional data associated with the call. This document describes 237 how IETF mechanisms for IP-based emergency calls, including [RFC6443] 238 and [additional-data-draft] are used to provide the signaling and 239 data exchange of the next generation of pan-European eCall. 241 The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency 242 calling with additional elements identifying the call as an eCall and 243 as carrying eCall data and with mechanisms for carrying the data. 244 3GPP IMS emergency services support multimedia, providing the ability 245 to carry voice, text, and video. This capability is referred to 246 within 3GPP as Multimedia Emergency Services (MMES). 248 A transition period will exist during which time the various entities 249 involved in initiating and handling an eCall might support next- 250 generation eCall, legacy eCall, or both. This transition period 251 might last several years or longer. The issue of migration/co- 252 existence during the transition period is very important but is 253 outside the scope of this document. The ETSI TR "Mobile Standards 254 Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in 255 Clause 7. 257 4. eCall Requirements 259 Overall eCall requirements are specified by CEN in [EN_16072] and by 260 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements specific to 261 vehicle data are contained in EN 15722 [msd]. For convenience, the 262 requirements most applicable to the limited scope of this document 263 are summarized very briefly below. 265 eCall requires: 267 o The call be recognized as an eCall (which is inherently an 268 emergency call) 269 o The call setup indicates if the call was manually or automatically 270 triggered 271 o A voice channel between the vehicle and the PSAP 272 o Carrying the MSD intrinsically with the call (the MSD needs to be 273 available to the same call-taker as the voice) 274 o The ability for the PSAP to acknowledge receipt of the MSD 275 o The ability for the PSAP to request that the vehicle generate and 276 transmit a new MSD 277 o The ability of the PSAP to be able to re-contact the occupants of 278 vehicle after the initial eCall is concluded 279 o The ability to perform a test call (which can be routed to a PSAP 280 but is not treated as an emergency call and not handled by a call 281 taker) 283 It is recognized that NG-eCall offers many potential enhancements, 284 although these are not required by current EU regulations. For 285 convenience, the enhancements most applicable to the limited scope of 286 this document are summarized very briefly below. 288 NG-eCall is expected to offer: 290 o The ability to carry more data (e.g., an enhanced MSD or an MSD 291 plus additional sets of data) 292 o The ability to handle video 293 o The ability to handle text 294 o The ability for the PSAP to access vehicle components (e.g., an 295 onboard camera (such as rear facing or blind-spot cameras) for a 296 visual assessment of the crash site situation) 297 o The ability for the PSAP to request the vehicle to take actions 298 (e.g., sound the horn, disable the ignition, lock/unlock doors) 299 o The ability to avoid audio muting of the voice channel (because 300 the MSD is not transferred using an in-band modem) 302 5. Vehicle Data 304 Pan-European eCall provides a standardized and mandated set of 305 vehicle related data, known as the Minimum Set of Data (MSD). The 306 European Committee for Standardization (CEN) has specified this data 307 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 308 MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML 309 encoding is better suited for use in SIP messages and is used in this 310 document. (The ASN.1 encoding is specified in Annex A of EN 15722 311 [msd], while the XML encoding is specified in Annex C.) 313 The "Additional Data related to an Emergency Call" document 314 [additional-data-draft] establishes a general mechanism for attaching 315 blocks of data to a SIP emergency call. This document makes use of 316 that mechanism to carry the eCall MSD in a SIP emergency call. 318 This document registers the 'application/ 319 emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD 320 to be carried in SIP. This document also adds the 'eCall.MSD' entry 321 to the Emergency Call Additional Data Blocks registry (established by 322 [additional-data-draft]) to enable the MSD to be recognized as such 323 in a SIP-based eCall emergency call. 325 Note that if additional data sets are defined and registered (e.g., 326 in the future or in other regions) and transmitted using the same 327 mechanisms, the size and frequency of transmission during a session 328 needs to be evaluated to be sure it is appropriate to use the 329 signaling channel. 331 6. Call Setup 333 In circuit-switched eCall, the IVS places a special form of a 112 334 emergency call which carries an eCall flag (indicating that the call 335 is an eCall and also if the call was manually or automatically 336 triggered); the mobile network operator (MNO) recognizes the eCall 337 flag and routes the call to an eCall-capable PSAP; vehicle data is 338 transmitted to the PSAP via the eCall in-band modem (in the voice 339 channel). 341 ///----\\\ 112 voice call with eCall flag +------+ 342 ||| IVS |||---------------------------------------->+ PSAP | 343 \\\----/// vehicle data via eCall in-band modem +------+ 345 Figure 1: circuit-switched eCall 347 An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD 348 in accordance with [additional-data-draft] by encoding it as 349 specified (per Appendix C of EN 15722 [msd]) and attaching it to an 350 INVITE as a MIME body part. The body part is identified by its MIME 351 content-type ('application/emergencyCallData.eCall.MSD+xml') in the 352 Content-Type header field of the body part. The body part is 353 assigned a unique identifier which is listed in a Content-ID header 354 field in the body part. The INVITE is marked as containing the MSD 355 by adding (or appending to) a Call-Info header field at the top level 356 of the INVITE. This Call-Info header field contains a CID URL 357 referencing the body part's unique identifier, and a 'purpose' 358 parameter identifying the data as the eCall MSD per the registry 359 entry; the 'purpose' parameter's value is 'emergencyCallData.' and 360 the root of the MIME type (not including the 'emergencyCallData' 361 prefix and any suffix such as '+xml' (e.g., 362 'purpose=emergencyCallData.eCall.MSD'). 364 For NG-eCall, the IVS establishes an emergency call using the 3GPP 365 IMS solution with a Request-URI indicating an eCall type of emergency 366 call and with vehicle data attached; the MNO or ESInet recognizes the 367 eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP 368 interpets the vehicle data sent with the call and makes it available 369 to the call taker. 371 ///----\\\ IMS emergency call with eCall URN +------+ 372 IVS ----------------------------------------->+ PSAP | 373 \\\----/// vehicle data included in call setup +------+ 375 Figure 2: NG-eCall 377 This document registers new service URN children within the "sos" 378 subservice. These URNs provide the mechanism by which an eCall is 379 identified, and differentiate between manually and automatically 380 triggered eCalls (which can be subject to different treatment, 381 depending on policy). The two service URNs are: 382 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 384 7. Call Routing 386 The routing rules for eCalls are likely to differ from those of other 387 emergency calls because eCalls are special types of emergency calls 388 (with implications for the types of response required) and need to be 389 handled by specially designated PSAPs. In an environment that uses 390 ESInets, the originating network passes all types of emergency calls 391 to an ESInet (which have a request URI containing the "SOS" service 392 URN). The ESInet is then responsible for routing such calls to the 393 appropriate PSAP. In an environment without an ESInet, the emergency 394 services authorities and the originating network jointly determine 395 how such calls are routed. 397 7.1. ESInets 399 This section provides background information on ESInets for 400 information only. 402 An Emergency Services IP Network (ESInet) is a network operated by 403 emergency services authorities. It handles emergency call routing 404 and processing before delivery to a PSAP. In the NG1-1-2 405 architecture adopted by EENA, each PSAP is connected to one or more 406 ESInets. Each originating network is also connected to one or more 407 ESInets. The ESInets maintain policy-based routing rules which 408 control the routing and processing of emergency calls. The 409 centralization of such rules within ESInets provides for a cleaner 410 separation between the responsibilities of the originating network 411 and that of the emergency services network, and provides greater 412 flexibility and control over processing of emergency calls by the 413 emergency services authorities. This makes it easier to react 414 quickly to unusual situations that require changes in how emergency 415 calls are routed or handled (e.g., a natural disaster closes a PSAP), 416 as well as ease in making long-term changes that affect such routing 417 (e.g., cooperative agreements to specially handle calls requiring 418 translation or relay services). ESInets might support the ability to 419 interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that 420 are not IP PSAPs (similarly to the ability to interwork IP emergency 421 calls to legacy non-IP PSAPs). Note that in order to support legacy 422 eCall-capable PSAPs that are not IP PSAPs and are not attached to an 423 ESInet, an originating network might need the ability to route an 424 eCall itself (e.g., to an interworking facility with interconnection 425 to a suitable legacy eCall capable PSAP) based on the eCall and 426 manual or automatic indications. The ETSI TR "Mobile Standards Group 427 (MSG); eCall for VoIP" [MSG_TR] discusses transition issues in Clause 428 7. 430 8. Test Calls 432 eCall requires the ability to place test calls. These are calls that 433 are recognized and treated to some extent as eCalls but are not given 434 emergency call treatment and are not handled by call takers. The 435 test call facility allows the IVS or user to verify that an eCall can 436 be successfully established with voice communication. The IVS can 437 also verify that the MSD was successfully received. 439 A service URN starting with "test." indicates a test call. For 440 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 441 This functionality is defined in [RFC6881]. 443 This document registers "urn:service:test.sos.ecall" for eCall test 444 calls. 446 the current eCall test call facility is a non-emergency number so 447 does not get treated as an emergency call. MNOs can treat a vehicle 448 call in the "test" service URN in a way that tests as much 449 functionality as desired, but this is outside the scope of this 450 document. 452 PSAPs that have the ability to process NG-eCalls SHOULD accept test 453 calls and send an acknowledgment if the MSD was successfully 454 received, per this document. Such PSAPs MAY also play an audio clip 455 (for example, saying that the call reached a PSAP) in addition to 456 supporting media loopback per [RFC6881]. 458 9. eCall-Specific Control/Metadata 460 eCall requires the ability for the PSAP to acknowledge successful 461 receipt of an MSD sent by the IVS, and for the PSAP to request that 462 the IVS send an MSD (e.g., the call taker can initiate a request for 463 a new MSD to see if the vehicle's state or location has changed). 464 Future enhancements are desired to enable the PSAP to send other 465 requests to the vehicle, such as locking or unlocking doors, sounding 466 the horn, flashing the lights, starting a video stream from on-board 467 cameras (such as rear focus or blind-spot), etc. 469 The mechanism established in [additional-data-draft], used in 470 Section 5 of this document to carry the MSD from the IVS to the PSAP, 471 is also used to carry a block of control data from the PSAP to the 472 IVS. This eCall control block (sometimes referred to as eCall 473 metadata) is an XML structure containing eCall-specific elements. 474 When the PSAP needs to send an eCall control block that is in 475 response to the MSD or other data sent by the IVS in a SIP request, 476 the control block can be sent in the SIP response to that request 477 (e.g., the INVITE). When the PSAP needs to send an eCall control 478 block that is not an immediate response to an MSD or other data sent 479 by the IVS, the control block can be transmitted from the PSAP to the 480 IVS in a SIP INFO message within the established session. The IVS 481 can then send any requested data (such as a new MSD) in the reply to 482 the INFO message. This mechanism flexibly allows the PSAP to send 483 eCall-specific data to the IVS and the IVS to respond. If control 484 data sent in a response message requests the IVS to send a new MSD or 485 other data block, or to perform an action other than sending data, 486 the IVS can send the requested data or an acknowledgment regarding 487 the action in an INFO message within the session (it could also use 488 re-INVITE but that is unnecessary when no aspect of the session or 489 media is changing). 491 This mechanism requires 493 o An XML definition of the eCall control object 494 o An extension mechanism by which new elements can be added to the 495 control object definition (e.g., permitting additional elements to 496 be included by adding their namespace) 497 o A MIME type registration for the control object (so it can be 498 carried in SIP messages and responses) 499 o An entry in the Emergency Call Additional Data Blocks sub-registry 500 (established by [additional-data-draft]) so that the control block 501 can be recognized as emergency call specific data within the SIP 502 messages 503 o An Info-Package registration per [RFC6086] permitting the control 504 block within Info messages 506 9.1. The eCall Control Block 508 The eCall control block is an XML data structure allowing for 509 acknowledgments, requests, and capabilities information. It is 510 carried in a SIP body part with a specific MIME content type. Three 511 top-level elements are defined for use within an eCall control block: 513 ack Used in a control block sent by either side. The PSAP 514 uses this to acknowledge receipt of data set sent by 515 the IVS. The IVS uses this to acknowledge receipt of a 516 request by the PSAP when that request would not 517 otherwise be acknowledged (if the PSAP requests the 518 vehicle to send data and the vehicle does so, the data 519 serves as a success acknowledgement). 521 capabilities: Used in a control block sent from the IVS to the PSAP 522 (e.g., in the initial INVITE) to inform the PSAP of the 523 vehicle capabilities. Child elements contain all 524 actions and data types supported by the vehicle and all 525 available lamps (lights) and cameras. 527 request Used in a control block sent by the PSAP to the IVS, to 528 request the vehicle to perform an action. 530 Mandatory Actions (the IVS and the PSAP MUST support): 532 o Transmit data object 534 Optional Actions (the IVS and the PSAP MAY support): 536 o Play and/or display static (pre-defined) message 537 o Speak/display dynamic text (text supplied in action) 538 o Flash or turn on or off a lamp (light) 539 o Honk horn 540 o Enable a camera 542 The element indicates the object being acknowledged (i.e., a 543 data object or a element), and reports success or failure. 545 The element has child elements to indicate 546 the actions supported by the IVS. 548 The element contains attributes to indicate the request and 549 to supply any needed information, and MAY contain a child 550 element to contain the text for a dynamic message. The 'action' 551 attribute is mandatory and indicates the specific action. An IANA 552 registry is created in Section 14.8.1 to contain the allowed values. 554 Extensibility: New elements, child elements, and attributes can be 555 defined in new namespaces. IANA registries are used to specify the 556 permitted values of several elements and attributes. These 557 mechanisms allow for extension. 559 There is no 'request' action to play dynamic media (such as a pre- 560 recorded audio message). The SIP re-INVITE mechanism can be used to 561 establish a one-way media stream for this purpose. 563 9.1.1. The element 565 The element is transmitted by the PSAP to acknowledge receipt 566 of an eCall data object. An element sent by a PSAP references 567 the unique ID of the data object that was sent by the IVS, and 568 further indicates if the PSAP considers the receipt successful or 569 not. The element is also transmitted by the IVS to the PSAP to 570 acknowledge receipt of a element that requested the IVS to 571 perform an action other than transmitting a data object (e.g., a 572 request to display a message would be acknowledged, but a request to 573 transmit a data object would not result in a separate element 574 being sent, since the data object itself serves as acknowledgment.) 575 An element sent by an IVS references the unique ID of the 576 request being acknowledged, indicates whether the request was 577 successfully performed, and if not, optionally includes an 578 explanation. 580 The element has the following attributes and child elements: 582 9.1.1.1. Attributes of the element 584 The element has the following attributes: 586 Name: ref 587 Usage: Mandatory 588 Type: anyURI 589 Description: References the Content-ID of the body part that 590 contained the data object or control object being acknowledged. 591 Example: 593 Name: received 594 Usage: Conditional: mandatory in an >ack< element sent by a PSAP; 595 not applicable in an >ack< element sent by an IVS 596 Type: Boolean 597 Description: Indicates if the referenced object was successfully 598 received or not 599 Example: 601 9.1.1.2. Child Elements of the element 603 The element has the following child elements: 605 Name: actionResult 606 Usage: Optional 607 Description: An element indicates the result of an 608 action (other than a 'send-data' action). It has the following 609 attributes: 611 Name: action 612 Usage: Mandatory 613 Type: token 614 Description: Contains the value of the 'action' attribute of the 615 element 617 Name: success 618 Usage: Mandatory 619 Type: Boolean 620 Description: Indicates if the action was successfully 621 accomplished 623 Name: reason 624 Usage: Conditional 625 Type: token 626 Description: Used when 'success' is "False", this attribute 627 contains a reason code for a failure. A registry for reason 628 codes is defined in Section 14.8.3. 630 Name: details 631 Usage: optional 632 Type: string 633 Description: Contains further explanation of the circumstances of 634 a success or failure. The contents are implementation-specific 635 and human-readable. 637 Example: 639 Example: 642 9.1.1.3. Ack Examples 644 645 651 653 655 Figure 3: Ack Example from PSAP to IVS 657 658 664 665 666 668 670 672 Figure 4: Ack Example from IVS to PSAP 674 9.1.2. The element 676 The element is transmitted by the IVS to indicate to 677 the PSAP its capabilities. No attributes for this element are 678 currently defined. The following child elements are defined: 680 9.1.2.1. Child Elements of the element 682 The element has the following child elements: 684 Name: request 685 Usage: Mandatory 686 Description: The element contains a child 687 element per action supported by the vehicle. 689 Because support for a 'send-data' action is REQUIRED, a 690 child element with a "send-data" 'action' attribute is also 691 REQUIRED. The 'supported-datatypes' attribute is REQUIRED in this 692 element within a element, and MUST 693 contain at a minimum the 'eCall.MSD' data block value; it SHOULD 694 contain all data blocks supported by the IVS. 696 All other actions are OPTIONAL. 698 If the "msg-static" action is supported, a child element 699 with a "msg-static" 'action' attribute is sent, with a 'msgid' 700 attribute set to the highest supported static message supported by 701 the vehicle. 703 If the "lamp" action is supported, a child element with 704 a "lamp" 'action' is sent, with a 'supported-lamps' attribute set 705 to all supported lamp IDs. 707 If the "enable-camera" action is supported, a child 708 element with an "enable-camera" 'action' is sent, with a 709 'supported-cameras' attribute set to all supported camera IDs. 711 Examples: 712 713 715 716 718 9.1.2.2. Capabilities Example 720 721 727 728 729 732 733 734 735 736 738 740 Figure 5: Capabilities Example 742 9.1.3. The element 744 A element appears one or more times on its own or as a 745 child of a element. The following attributes and 746 child elements are defined: 748 9.1.3.1. Attributes of the element 750 The element has the following attributes: 752 Name: action 753 Usage: Mandatory 754 Type: token 755 Description: Identifies the action that the vehicle is requested to 756 perform. An IANA registry is established in Section 14.8.1 to 757 contain the allowed values. 758 Example: action="send-data" 760 Name: msgid 761 Usage: Conditional 762 Type: int 763 Description: Mandatory with a "msg-static" action. Indicates the 764 identifier of the static message to be displayed and/or spoken for 765 the vehicle occupants. This document established an IANA registry 766 for messages and their IDs, in Section 14.8.2 767 Example: msgid="3" 769 Name: persistance 770 Usage: Optional 771 Type: duration 772 Description: Specifies how long to carry on the specified action, 773 for example, how long to continue honking or flashing. If absent, 774 the default is indefinitely. 775 Example: persistance="PT1H" 777 Name: datatype 778 Usage: Conditional 779 Type: token 780 Description: Mandatory with a "send-data" action. Specifies the 781 data block that the IVS is requested to transmit, using the same 782 identifier as in the 'purpose' attribute set in a Call-Info header 783 field to point to the data block. Permitted values are contained 784 in the 'Emergency Call Data Types' IANA registry established in 785 [additional-data-draft]. 786 Example: datatype="eCall.MSD" 788 Name: supported-datatypes 789 Usage: Conditional 790 Type: string 791 Description: Used with a 'send-data' action in a element 792 that is a child of a element, this attribute lists 793 all data blocks that the vehicle can transmit, using the same 794 identifier as in the 'purpose' attribute in a Call-Info header 795 field to point to the data block. Permitted values are contained 796 in the 'Emergency Call Data Types' IANA registry established in 797 [additional-data-draft]. Multiple values are separated with a 798 semicolon. 799 Example: supported-datatypes="eCall.MSD; VEDS; eCall.foo" 801 Name: lamp-action 802 Usage: Conditional 803 Type: token 804 Description: Used with a 'lamp' action, indicates if the lamp is to 805 be illuminated, turned off, or flashed. Permitted values are 806 'on', 'off', and 'flash'. 807 Example: lamp-action="flash" 809 Name: lamp-ID 810 Usage: Conditional 811 Type: token 812 Description: Used with a 'lamp' action, indicates which lamp the 813 action affects. Permitted values are contained in the registry of 814 lamp-ID tokens created in Section 14.8.4 815 Example: lamp-ID="hazard" 817 Name: supported-lamps 818 Usage: Conditional 819 Type: string 820 Description: Used with a 'lamp' action in a element that 821 is a child of a element, this attribute lists all 822 supported lamps, using values in the registry of lamp-ID tokens 823 created in Section 14.8.4. Multiple values are separated with a 824 semicolon. 825 Example: supported-lamps="head; interior; fog-front; fog-rear; 826 brake; position-front; position-rear; turn-left; turn-right; 827 hazard" 829 Name: camera-ID 830 Usage: Conditional 831 Type: token 832 Description: Used with an 'enable-camera' action, indicates which 833 camera to enable. Permitted values are contained in the registry 834 of camera-ID tokens created in Section 14.8.5. When a vehicle 835 camera is enabled, the IVS sends a re-INVITE to negotiate a one- 836 way media stream for the camera. 837 Example: camera-ID="backup" 839 Name: supported-cameras 840 Usage: Conditional 841 Type: string 842 Description: Used with an 'enable-camera' action in a 843 element that is a child of a element, this attribute 844 lists all cameras that the vehicle supports (can add as a video 845 feed in the current session), using the same identifiers as are 846 used in the 'camera-ID' attribute (contained in the camera ID 847 registry in Section 14.8.5). Multiple values are separated with a 848 semicolon. 849 Example: supported-cameras="backup; interior" 851 9.1.3.2. Child Elements of the element 853 The element has the following child elements: 855 Name: text 856 Usage: Conditional 857 Type: string 858 Description: Used within a element to 859 contain the text to be displayed and/or spoken (via text-to- 860 speech) for the vehicle occupants. 861 Example: Emergency authorities are aware of your incident and 862 location. Due to a multi-vehicle incident in your area, no one is 863 able to speak with you right now. Please remain calm. We will 864 assist you soon. 866 9.1.3.3. Request Example 868 869 875 876 878 879 880 Remain calm. Help is on the way. 881 883 885 Figure 6: Request Example 887 9.2. The emergencyCallData.eCall INFO package 889 This document registers the 'emergencyCallData.eCall' INFO package. 890 Both endpoints (the IVS and the PSAP equipment) set the Recv-Info 891 header field to 'emergencyCallData.eCall' per [RFC6086] to indicate 892 ability to receive INFO messages carrying eCall data or control 893 blocks. 895 Support for the 'emergencyCallData.eCall' INFO package indicates the 896 ability to receive eCall data and control blocks, which are carried 897 in a body part whose subtype starts with 'emergencyCallData.eCall.'. 898 At present there is only one defined eCall data block, which has the 899 'application/emergencyCallData.eCall.MSD+xml' MIME type, and one 900 eCall control block, which has the 'application/ 901 emergencyCallData.eCall.control+xml' MIME type. The eCall control 902 block includes the ability for the IVS to indicate its capabilities, 903 so in the event additional eCall blocks are defined, the IVS can 904 indicate which it supports. 906 The use of INFO is based on an analysis of the requirements against 907 the intent and effects of INFO versus other approaches (such as SIP 908 MESSAGE, media plane, or non-SIP protocols). In particular, the 909 transport of eCall data and control blocks is done only during an 910 emergency session established with SIP, using the mechanism 911 established in [additional-data-draft], and is normally carried in 912 the initial INVITE and its response; the use of INFO only occurs when 913 a data block or request needs to be sent subsequently during the 914 call. While MESSAGE could be used, it is not tied to a SIP session 915 as is INFO. REINVITE could also be used, but is normally used to 916 modify the session. SUBSCRIBE/NOTIFY could be coerced into service, 917 but the semantics are not a clean fit. Hence, INFO is appropriate. 919 An INFO request message carrying an eCall data or control block has 920 an Info-Package header field set to 'emergencyCallData.eCall' per 921 [RFC6086]. The INFO request message is marked as containing the 922 eCall data or control block by a Call-Info header field containing a 923 CID URL referencing the unique identifier of the body part containing 924 the eCall data or control, and a 'purpose' parameter identifying the 925 block. Because the eCall data or control block is being carried in 926 an INFO request message, the body part also carries a Content- 927 Disposition header field set to "Info-Package". 929 Per [additional-data-draft], emergency call related additional data 930 MAY be included in any SIP request or response message that can 931 contain a body. Hence, notwithstanding Section 4.3.2. of [RFC6086], 932 INFO response messages MAY contain eCall data or control blocks, 933 provided they are included as described in this document (with a 934 Call-Info header field containing a CID URL referencing the unique 935 identifier of the body part, and a 'purpose' parameter identifying 936 the block). When eCall data or control blocks are included in an 937 INFO response message, this is done per [additional-data-draft] and 938 this document, and not under [RFC6086]; that is, they are included as 939 emergency call additional data, not as an INFO package associated 940 data. 942 10. Examples 944 Figure 7 shows an eCall. The call uses the request URI 945 'urn:service:sos.ecall.automatic' service URN and is recognized as an 946 eCall, and further as one that was invoked automatically by the IVS 947 due to a crash or other serious incident. In this example, the 948 originating network routes the call to an ESInet (as for any 949 emergency call in an environment with an ESInet). The ESInet routes 950 the call to the appropriate NG-eCall capable PSAP. The emergency 951 call is received by the ESInet's Emergency Services Routing Proxy 952 (ESRP), as the entry point into the ESInet. The ESRP routes the call 953 to a PSAP, where it is received by a call taker. In deployments 954 where there is no ESInet, the originating network routes the call 955 directly to the appropriate NG-eCall capable PSAP. 957 +------------+ +---------------------------------------+ 958 | | | +-------+ | 959 | | | | PSAP2 | | 960 | | | +-------+ | 961 | | | | 962 | | | +------+ +-------+ | 963 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 964 | | | +------+ +-------+ | 965 | | | | 966 | | | +-------+ | 967 | | | | PSAP3 | | 968 | Originating| | +-------+ | 969 | Mobile | | | 970 | Network | | ESInet | 971 +------------+ +---------------------------------------+ 973 Figure 7: Example of NG-eCall Message Flow 975 The example, shown in Figure 8, illustrates a SIP eCall INVITE that 976 contains an MSD and an eCall control block with vehicle capabilities. 977 For simplicity, the example does not show all SIP headers, nor does 978 it show the additional data blocks added by the IVS and the 979 originating mobile network. 981 INVITE urn:service:sos.ecall.automatic SIP/2.0 982 To: urn:service:sos.ecall.automatic 983 From: ;tag=9fxced76sl 984 Call-ID: 3848276298220188511@atlanta.example.com 985 Geolocation: 986 Geolocation-Routing: no 987 Call-Info: cid:1234567890@atlanta.example.com; 988 purpose=emergencyCallData.eCall.MSD; 989 cid:2345678901@atlanta.example.com; 990 purpose=emergencyCallData.eCall.control; 991 Accept: application/sdp, application/pidf+xml, 992 application/emergencyCallData.eCall.control 993 CSeq: 31862 INVITE 994 Recv-Info: emergencyCallData.eCall 995 Content-Type: multipart/mixed; boundary=boundary1 996 Content-Length: ... 998 --boundary1 999 Content-Type: application/sdp 1001 ...Session Description Protocol (SDP) goes here... 1003 --boundary1 1004 Content-Type: application/emergencyCallData.eCall.MSD+xml 1005 Content-ID: 1234567890@atlanta.example.com 1006 Content-Disposition: by-reference;handling=optional 1008 1009 1 1011 1012 1014 1 1016 1017 1018 1019 1020 1021 1023 1024 WMI 1025 VDSVDS 1026 Y 1027 A123456 1028 1029 1030 1031 1032 1034 123456789 1036 1037 173881200 1038 41822520 1039 1041 14 1043 1044 10 1045 -10 1046 1048 1049 10 1050 -20 1051 1053 2 1055 1057 1058 1.2.125 1059 30304646 1060 1061 1062 1064 --boundary1 1065 Content-Type: application/emergencyCallData.eCall.control+xml 1066 Content-ID: 2345678901@atlanta.example.com 1067 Content-Disposition: by-reference;handling=optional 1069 1070 1076 1077 1078 1082 1083 1084 1085 1087 1089 1091 --boundary1-- 1093 Figure 8: SIP NG-eCall INVITE 1095 Continuing the example, Figure 9 illustrates a SIP 200 OK response to 1096 the INVITE of Figure 8, containing an eCall control block 1097 acknowledging successful receipt of the eCall MSD. (For simplicity, 1098 the example does not show all SIP headers.) 1099 SIP/2.0 200 OK 1100 To: ;tag=9fxced76sl 1101 From: Exemplar PSAP 1102 Call-ID: 3848276298220188511@atlanta.example.com 1103 Call-Info: cid:2345678901@atlanta.example.com; 1104 purpose=emergencyCallData.eCall.control; 1105 Accept: application/sdp, application/pidf+xml, 1106 application/emergencyCallData.eCall.control, 1107 application/emergencyCallData.eCall.MSD 1108 CSeq: 31862 INVITE 1109 Recv-Info: emergencyCallData.eCall 1110 Content-Type: multipart/mixed; boundary=boundaryX 1111 Content-Length: ... 1113 --boundaryX 1114 Content-Type: application/sdp 1116 ...Session Description Protocol (SDP) goes here... 1118 --boundaryX 1119 Content-Type: application/EmergencyCallData:eCall-control+xml 1120 Content-ID: 2345678901@atlanta.example.com 1121 Content-Disposition: by-reference;handling=optional 1123 1124 1130 1132 1134 --boundaryX-- 1136 Figure 9: 200 OK response to INVITE 1138 11. Security Considerations 1140 The security considerations described in [RFC5069] apply here. 1142 In addition to any network-provided location that is inherently 1143 permitted for IMS emergency calls (which might be determined solely 1144 by the network, or in cooperation with or possibly entirely by the 1145 originating device), an eCall carries an IVS-supplied location within 1146 the MSD. This is likely to be useful to the PSAP, especially when 1147 the two locations are independently determined. Even in situations 1148 where the network-supplied location is limited to the cell site, this 1149 can be useful as a sanity check on the device-supplied location 1150 contained in the MSD. 1152 The document [RFC7378] discusses trust issues regarding location 1153 provided by or determined in cooperation with end devices. 1155 The mechanism by which the PSAP sends acknowledgments and requests to 1156 the vehicle requires authenticity considerations; when the PSAP 1157 request is received within a session initiated by the vehicle as an 1158 eCall emergency call placed over a cellular network, there is a 1159 higher degree of trust that the source is indeed a PSAP. If the PSAP 1160 request is received in other situations, such as a call-back, the 1161 trust issues in verifying that a call-back is indeed from a PSAP are 1162 more complex (see the PSAP Callback document [RFC7090]). A further 1163 safeguard (applicable regardless of which end initiated the call and 1164 the means of the call) is for the PSAP or emergency service provider 1165 to sign the body part using a certificate issued by a known emergency 1166 services certificate authority and for which the IVS can verify the 1167 root certificate. 1169 12. Privacy Considerations 1171 Since this document builds on [additional-data-draft], the data 1172 structures specified there, and the corresponding privacy 1173 considerations discussed there, apply here as well. The MSD carries 1174 some additional identifying and personal information (mostly about 1175 the vehicle and less about the owner), as well as location 1176 information, and so needs to be protected against unauthorized 1177 disclosure. Local regulations may impose additional privacy 1178 protection requirements. The additional functionality enabled by 1179 this document, such as access to vehicle camera streams, carries a 1180 burden of protection and so implementations need to be careful that 1181 access is only provided within the context of an emergency call and 1182 to an emergency services provider, for example, within a vehicle- 1183 initiated emergency call or by verifying that the request for camera 1184 access is signed by a certificate issued by an emergency services 1185 registrar. 1187 13. XML Schema 1189 This section defines the XML schema of the eCall control block. (The 1190 schema for the MSD can be found in EN 15722 [msd].) 1192 1193 1201 1204 1207 1208 1209 1210 1211 1213 1214 1215 1218 1219 1220 1221 1222 1224 1225 1226 1227 1228 1229 1230 1233 1236 1238 1239 conditionally 1240 mandatory when @success='false" 1241 to indicate reason code for a 1242 failure 1243 1244 1245 1247 1248 1249 1250 1253 1254 1257 1259 1260 1261 1262 1264 1265 1266 1267 1268 1272 1275 1276 1277 1278 1279 1281 1282 1283 1284 1285 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1314 1316 Figure 10: eCall Control Block Schema 1318 14. IANA Considerations 1320 14.1. Service URN Registrations 1322 IANA is requested to register the URN 'urn:service:sos.ecall' under 1323 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 1325 This service identifies a type of emergency call (placed by a 1326 specialized in-vehicle system and a carrying standardized set of data 1327 related to the vehicle and crash or incident, and is needed to direct 1328 the call to a specialized public safety answering point (PSAP) with 1329 technical and operational capabilities to handle such calls. Two 1330 sub-services are registered as well, namely 1331 urn:service:sos.ecall.manual 1333 This service URN indicates that an eCall had been triggered based 1334 on the manual interaction of the driver or a passenger. 1336 urn:service:sos.ecall.automatic 1338 This service URN indicates that an eCall had been triggered 1339 automatically, for example, due to a crash or other serious 1340 incident (e.g., fire). 1342 IANA is also requested to register the URN 1343 'urn:service:test.sos.ecall' under the sub-service 'test' registry 1344 defined in Setcion 17.2 of [RFC6881]. 1346 14.2. MIME Content-type Registration for 'application/ 1347 emergencyCallData.eCall.MSD+xml' 1349 IANA is requested to add application/emergencyCallData.eCall.MSD+xml 1350 as a MIME content type, with a reference to this document, in 1351 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 1352 RFC 7303 [RFC7303]. 1354 MIME media type name: application 1356 MIME subtype name: emergencyCallData.eCall.MSD+xml 1358 Mandatory parameters: none 1360 Optional parameters: charset 1362 Indicates the character encoding of the XML content. 1364 Encoding considerations: Uses XML, which can employ 8-bit 1365 characters, depending on the character encoding used. See 1366 Section 3.2 of RFC 7303 [RFC7303]. 1368 Security considerations: This content type is designed to carry 1369 vehicle and incident-related data during an emergency call. This 1370 data contains personal information including vehicle VIN, 1371 location, direction, etc. Appropriate precautions need to be 1372 taken to limit unauthorized access, inappropriate disclosure to 1373 third parties, and eavesdropping of this information. In general, 1374 it is permissible for the data to be unprotected while briefly in 1375 transit within the Mobile Network Operator (MNO); the MNO is 1376 trusted to not permit the data to be accessed by third parties. 1377 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 1378 contain more discussion. 1380 Interoperability considerations: None 1382 Published specification: Annex C of EN 15722 [msd] 1384 Applications which use this media type: Pan-European eCall 1385 compliant systems 1387 Additional information: None 1389 Magic Number: None 1391 File Extension: .xml 1393 Macintosh file type code: 'TEXT' 1395 Person and email address for further information: Hannes 1396 Tschofenig, Hannes.Tschofenig@gmx.net 1398 Intended usage: LIMITED USE 1400 Author: This specification was produced by the European Committee 1401 For Standardization (CEN). For contact information, please see 1402 . 1404 Change controller: The European Committee For Standardization 1405 (CEN) 1407 14.3. MIME Content-type Registration for 'application/ 1408 emergencyCallData.eCall.control+xml' 1410 IANA is requested to add application/ 1411 emergencyCallData.eCall.control+xml as a MIME content type, with a 1412 reference to this document, in accordance to the procedures of RFC 1413 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1415 MIME media type name: application 1417 MIME subtype name: emergencyCallData.eCall.control+xml 1419 Mandatory parameters: none 1421 Optional parameters: charset 1423 Indicates the character encoding of the XML content. 1425 Encoding considerations: Uses XML, which can employ 8-bit 1426 characters, depending on the character encoding used. See 1427 Section 3.2 of RFC 7303 [RFC7303]. 1429 Security considerations: This content type carries metadata and 1430 control information and requests, primarily from a Public Safety 1431 Answering Point (PSAP) to an In-Vehicle System (IVS) during an 1432 emergency call, and also capabilities from the IVS to the PSAP. 1433 Metadata (such as an acknowledgment that data sent by the IVS to 1434 the PSAP was successfully received) has limited privacy and 1435 security implications. Control information (such as requests from 1436 the PSAP that the vehicle perform an action) has some privacy and 1437 important security implications. The privacy concern arises from 1438 the ability to request the vehicle to transmit a data set, which 1439 as described in Section 14.2, can contain personal information. 1440 The security implication is the ability to request the vehicle to 1441 perform an action. It is important that control information 1442 originate only from a PSAP or other emergency services provider, 1443 and not from an impostor. The first safeguard for this is the 1444 security of the cellular network over which the emergency call was 1445 placed. In particular, when the IVS initiates an eCall over a 1446 cellular network, the MNO routes the call to a PSAP. (Calls 1447 placed using other means, such as Wi-Fi or over-the-top services, 1448 do not carry the same degree of trust.) Calls received by the 1449 IVS, such as a call-back from a PSAP, also do not carry the same 1450 degree of trust, since the current mechanisms are not ideal for 1451 verifying that such a call is indeed from a PSAP in response to an 1452 emergency call placed by the IVS. See the discussion in 1453 Section 11 and the PSAP Callback document [RFC7090]. A further 1454 safeguard, and one applicable regardless of which end initiated 1455 the call and the means of the call, is for the PSAP or emergency 1456 service provider to sign the body part using a certificate issued 1457 by a known emergency services certificate authority and for which 1458 the IVS can verify the root certificate. Sections 7 and Section 8 1459 of [I-D.ietf-ecrit-additional-data] contain more discussion. 1461 Interoperability considerations: None 1463 Published specification: Annex C of EN 15722 [msd] 1465 Applications which use this media type: Pan-European eCall 1466 compliant systems 1468 Additional information: None 1470 Magic Number: None 1472 File Extension: .xml 1474 Macintosh file type code: 'TEXT' 1475 Person and email address for further information: Randall Gellens, 1476 rg+ietf@qti.qualcomm.com 1478 Intended usage: LIMITED USE 1480 Author: The IETF ECRIT WG. 1482 Change controller: The IETF ECRIT WG. 1484 14.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1485 Additional Data Blocks registry 1487 This specification requests IANA to add the 'eCall.MSD' entry to the 1488 Emergency Call Additional Data Blocks registry (established by 1489 [additional-data-draft]), with a reference to this document. 1491 14.5. Registration of the 'eCall.control' entry in the Emergency Call 1492 Additional Data Blocks registry 1494 This specification requests IANA to add the 'eCall.control' entry to 1495 the Emergency Call Additional Data Blocks registry (established by 1496 [additional-data-draft]), with a reference to this document. 1498 14.6. Registration of the emergencyCallData.eCall Info Package 1500 IANA is requested to add emergencyCallData.eCall to the Info Packages 1501 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1502 reference to this document. 1504 14.7. URN Sub-Namespace Registration 1506 14.7.1. Registration for urn:ietf:params:xml:ns:eCall 1508 This section registers a new XML namespace, as per the guidelines in 1509 RFC 3688 [RFC3688]. 1511 URI: urn:ietf:params:xml:ns:eCall 1513 Registrant Contact: IETF, ECRIT working group, , as 1514 delegated by the IESG . 1516 XML: 1518 BEGIN 1519 1520 1522 1523 1524 1526 Namespace for eCall Data 1527 1528 1529

Namespace for eCall Data

1530

See [TBD: This document].

1531 1532 1533 END 1535 14.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1537 This section registers a new XML namespace, as per the guidelines in 1538 RFC 3688 [RFC3688]. 1540 URI: urn:ietf:params:xml:ns:eCall:control 1542 Registrant Contact: IETF, ECRIT working group, , as 1543 delegated by the IESG . 1545 XML: 1547 BEGIN 1548 1549 1551 1552 1553 1555 Namespace for eCall Data: 1556 Control Block 1557 1558 1559

Namespace for eCall Data

1560

Control Block

1561

See [TBD: This document].

1562 1563 1564 END 1566 14.8. Registry creation 1568 This document creates a new registry called 'eCall Control Data'. 1569 The following sub-registries are created for this registry. 1571 14.8.1. eCall Control Action Registry 1573 This document creates a new sub-registry called "eCall Control Action 1574 Registry". As defined in [RFC5226], this registry operates under 1575 "Expert Review" rules. The expert should determine that the proposed 1576 action is within the purview of a vehicle, is sufficiently 1577 distinguishable from other actions, and the actions is clearly and 1578 fully described. In most cases, a published and stable document is 1579 referenced for the description of the action. 1581 The content of this registry includes: 1583 Name: The identifier to be used in the 'action' attribute of an 1584 eCall control element. 1586 Description: A description of the action. In most cases this will 1587 be a reference to a published and stable document. The 1588 description MUST specify if any attributes or child elements are 1589 optional or mandatory, and describe the action to be taken by the 1590 vehicle. 1592 The initial set of values is listed in Table 2. 1594 +---------------+------------------------------+ 1595 | Name | Description | 1596 +---------------+------------------------------+ 1597 | send-data | Section xxx of this document | 1598 | | | 1599 | msg-static | Section xxx of this document | 1600 | | | 1601 | msg-dynamic | Section xxx of this document | 1602 | | | 1603 | honk | Section xxx of this document | 1604 | | | 1605 | lamp | Section xxx of this document | 1606 | | | 1607 | enable-camera | Section xxx of this document | 1608 +---------------+------------------------------+ 1610 Table 2: eCall Control Action Registry Initial Values 1612 14.8.2. eCall Static Message Registry 1614 This document creates a new sub-registry called "eCall Static Message 1615 Registry". Because all compliant vehicles are expected to support 1616 all static messages translated into all languages supported by the 1617 vehicle, it is important to limit the number of such messages. As 1618 defined in [RFC5226], this registry operates under "Publication 1619 Required" rules, which require a stable, public document and imply 1620 expert review of the publication. The expert should determine that 1621 the document has been published by an appropriate emergency services 1622 organization (e.g., NENA, EENA, APCO) and that the proposed message 1623 is sufficiently distinguishable from other messages. 1625 The content of this registry includes: 1627 ID: An integer identifier to be used in the 'msgid' attribute of an 1628 eCall control element. 1630 Message: The text of the message. Messages are listed in the 1631 registry in English; vehicles are expected to implement 1632 translations into languages supported by the vehicle. 1634 When new messages are added to the registry, the message text is 1635 determined by the registrant; IANA assigns the IDs. Each message is 1636 assigned a consecutive integer value as its ID. This allows an IVS 1637 to indicate by a single integer value that it supports all messages 1638 with that value or lower. 1640 The initial set of values is listed in Table 3. 1642 +----+--------------------------------------------------------------+ 1643 | ID | Message | 1644 +----+--------------------------------------------------------------+ 1645 | 1 | Emergency authorities are aware of your incident and | 1646 | | location, but are unable to speak with you right now. We | 1647 | | will help you as soon as possible. | 1648 +----+--------------------------------------------------------------+ 1650 Table 3: eCall Static Message Registry 1652 14.8.3. eCall Reason Registry 1654 This document creates a new sub-registry called "eCall Reason 1655 Registry" which contains values for the 'reason' attribute of the 1656 element. As defined in [RFC5226], this registry 1657 operates under "Expert Review" rules. The expert should determine 1658 that the proposed reason is sufficiently distinguishable from other 1659 reasons and that the proposed description is understandable and 1660 correctly worded. 1662 The content of this registry includes: 1664 ID: A short string identifying the reason, for use in the 'reason' 1665 attribute of an element. 1667 Description: A description of the reason. 1669 The initial set of values is listed in Table 4. 1671 +------------------+------------------------------------------------+ 1672 | ID | Description | 1673 +------------------+------------------------------------------------+ 1674 | unsupported | The 'action' is not supported. | 1675 | | | 1676 | unable | The 'action' could not be accomplished. | 1677 | | | 1678 | data-unsupported | The data item referenced in a 'send-data' | 1679 | | request is not supported. | 1680 +------------------+------------------------------------------------+ 1682 Table 4: eCall Reason Registry 1684 14.8.4. eCall Lamp ID Registry 1686 This document creates a new sub-registry called "eCall Lamp ID 1687 Registry" to standardize the names of automotive lamps (lights). As 1688 defined in [RFC5226], this registry operates under "Expert Review" 1689 rules. The expert should determine that the proposed lamp name is 1690 clearly understandable and is sufficiently distinguishable from other 1691 lamp names. 1693 The content of this registry includes: 1695 Name: The identifier to be used in the 'lamp-ID' attribute of an 1696 eCall control element. 1698 Description: A description of the lamp (light). 1700 The initial set of values is listed in Table 5. 1702 +----------------+---------------------------------------------+ 1703 | Name | Description | 1704 +----------------+---------------------------------------------+ 1705 | head | The main lamps used to light the road ahead | 1706 | | | 1707 | interior | Interior lamp, often at the top center | 1708 | | | 1709 | fog-front | Front fog lamps | 1710 | | | 1711 | fog-rear | Rear fog lamps | 1712 | | | 1713 | brake | Brake indicator lamps | 1714 | | | 1715 | position-front | Front position/parking/standing lamps | 1716 | | | 1717 | position-rear | Rear position/parking/standing lamps | 1718 | | | 1719 | turn-left | Left turn/directional lamps | 1720 | | | 1721 | turn-right | Right turn/directional lamps | 1722 | | | 1723 | hazard | Hazard/four-way lamps | 1724 +----------------+---------------------------------------------+ 1726 Table 5: eCall Lamp ID Registry Initial Values 1728 14.8.5. eCall Camera ID Registry 1730 This document creates a new sub-registry called "eCall Camera ID 1731 Registry" to standardize the names of automotive camera. As defined 1732 in [RFC5226], this registry operates under "Expert Review" rules. 1733 The expert should determine that the proposed camera name is clearly 1734 understandable and is sufficiently distinguishable from other camera 1735 names. 1737 The content of this registry includes: 1739 Name: The identifier to be used in the 'camera-ID' attribute of an 1740 eCall control element. 1742 Description: A description of the camera. 1744 The initial set of values is listed in Table 6. 1746 +----------+--------------------------------------------------------+ 1747 | Name | Description | 1748 +----------+--------------------------------------------------------+ 1749 | backup | Shows what is behind the vehicle. Also known as | 1750 | | rearview, reverse, etc. | 1751 | | | 1752 | interior | Shows the interior (driver) | 1753 +----------+--------------------------------------------------------+ 1755 Table 6: eCall Camera ID Registry Initial Values 1757 15. Contributors 1759 Brian Rosen was a co-author of the original document upon which this 1760 document is based. 1762 16. Acknowledgements 1764 We would like to thank Bob Williams and Ban Al-Bakri for their 1765 feedback and suggestions, and Keith Drage for his review comments. 1766 We would like to thank Michael Montag, Arnoud van Wijk, Gunnar 1767 Hellstrom, and Ulrich Dietz for their help with the original document 1768 upon which this document is based. 1770 17. Changes from Previous Versions 1772 17.1. Changes from draft-ietf-02 to draft-ietf-03 1774 o Added request to enable cameras 1775 o Improved examples and XML schema 1776 o Clarifications and wording improvements 1778 17.2. Changes from draft-ietf-01 to draft-ietf-02 1780 o Added clarifying text reinforcing that the data exchange is for 1781 small blocks of data infrequently transmitted 1782 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1783 establish a one-way media stream 1784 o Clarified that the scope is the needs of eCall within the SIP 1785 emergency call environment 1787 o Added informative statement that the document may be suitable for 1788 reuse by other ACN systems 1789 o Clarified that normative language for the control block applies to 1790 both IVS and PSAP 1791 o Removed 'ref', 'supported-mime', and elements 1792 o Minor wording improvements and clarifications 1794 17.3. Changes from draft-ietf-00 to draft-ietf-01 1796 o Added further discussion of test calls 1797 o Added further clarification to the document scope 1798 o Mentioned that multi-region vehicles may need to support other 1799 crash notification specifications in addition to eCall 1800 o Added details of the eCall metadata and control functionality 1801 o Added IANA registration for the MIME content type for the eCall 1802 control object 1803 o Added IANA registries for protocol elements and tokens used in the 1804 eCall control object 1805 o Minor wording improvements and clarifications 1807 17.4. Changes from draft-gellens-03 to draft-ietf-00 1809 o Renamed from draft-gellens- to draft-ietf-. 1810 o Added mention of and reference to ETSI TR "Mobile Standards Group 1811 (MSG); eCall for VoIP" 1812 o Added text to Introduction regarding migration/co-existence being 1813 out of scope 1814 o Added mention in Security Considerations that even if the network- 1815 supplied location is just the cell site, this can be useful as a 1816 sanity check on the IVS-supplied location 1817 o Minor wording improvements and clarifications 1819 17.5. Changes from draft-gellens-02 to -03 1821 o Clarifications and editorial improvements. 1823 17.6. Changes from draft-gellens-01 to -02 1825 o Minor wording improvements 1826 o Removed ".automatic" and ".manual" from 1827 "urn:service:test.sos.ecall" registration and discussion text. 1829 17.7. Changes from draft-gellens-00 to -01 1831 o Now using 'EmergencyCallData' for purpose parameter values and 1832 MIME subtypes, in accordance with changes to 1833 [additional-data-draft] 1834 o Added reference to RFC 6443 1835 o Fixed bug that caused Figure captions to not appear 1837 18. References 1839 18.1. Normative References 1841 [EN_16072] 1842 CEN, , "Intelligent transport systems - eSafety - Pan- 1843 European eCall operating requirements", December 2011. 1845 [I-D.ietf-ecrit-additional-data] 1846 Gellens, R., Rosen, B., Tschofenig, H., Marshall, R., and 1847 J. Winterbottom, "Additional Data Related to an Emergency 1848 Call", draft-ietf-ecrit-additional-data-37 (work in 1849 progress), October 2015. 1851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1852 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1853 RFC2119, March 1997, 1854 . 1856 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1857 DOI 10.17487/RFC3688, January 2004, 1858 . 1860 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1861 Emergency and Other Well-Known Services", RFC 5031, DOI 1862 10.17487/RFC5031, January 2008, 1863 . 1865 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1866 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1867 DOI 10.17487/RFC5226, May 2008, 1868 . 1870 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1871 "Framework for Emergency Calling Using Internet 1872 Multimedia", RFC 6443, DOI 10.17487/RFC6443, December 1873 2011, . 1875 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1876 Specifications and Registration Procedures", BCP 13, RFC 1877 6838, DOI 10.17487/RFC6838, January 2013, 1878 . 1880 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1881 Communications Services in Support of Emergency Calling", 1882 BCP 181, RFC 6881, DOI 10.17487/RFC6881, March 2013, 1883 . 1885 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1886 DOI 10.17487/RFC7303, July 2014, 1887 . 1889 [TS22.101] 1890 3GPP, , "Technical Specification Group Services and System 1891 Aspects; Service aspects; Service principles", . 1893 [additional-data-draft] 1894 Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and 1895 J. Winterbottom, "Additional Data related to an Emergency 1896 Call", draft-ietf-ecrit-additional-data-11 (work in 1897 progress), July 2013. 1899 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1900 minimum set of data (MSD), EN 15722", June 2011. 1902 18.2. Informative references 1904 [CEN] "European Committee for Standardization", 1905 . 1907 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1908 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1909 April 2014. 1911 [RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for 1912 Emergency Context Resolution with Internet Technologies", 1913 RFC 5012, DOI 10.17487/RFC5012, January 2008, 1914 . 1916 [RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. 1917 Shanmugam, "Security Threats and Requirements for 1918 Emergency Call Marking and Mapping", RFC 5069, DOI 1919 10.17487/RFC5069, January 2008, 1920 . 1922 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1923 Initiation Protocol (SIP) INFO Method and Package 1924 Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011, 1925 . 1927 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1928 Patel, "Public Safety Answering Point (PSAP) Callback", 1929 RFC 7090, DOI 10.17487/RFC7090, April 2014, 1930 . 1932 [RFC7378] Tschofenig, H., Schulzrinne, H., and B. Aboba, Ed., 1933 "Trustworthy Location", RFC 7378, DOI 10.17487/RFC7378, 1934 December 2014, . 1936 [SDO-3GPP] 1937 "3d Generation Partnership Project", 1938 . 1940 [SDO-ETSI] 1941 "European Telecommunications Standards Institute (ETSI)", 1942 . 1944 [draft-ietf-ecrit-car-crash] 1945 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1946 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1947 ecrit-car-crash (work in progress), March 2015. 1949 Authors' Addresses 1951 Randall Gellens 1952 Qualcomm Technologies, Inc. 1953 5775 Morehouse Drive 1954 San Diego 92651 1955 US 1957 Email: rg+ietf@randy.pensive.org 1959 Hannes Tschofenig 1960 (Individual) 1962 Email: Hannes.Tschofenig@gmx.net 1963 URI: http://www.tschofenig.priv.at