idnits 2.17.00 (12 Aug 2021) /tmp/idnits491/draft-ietf-ecrit-ecall-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 7, 2015) is 2631 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5491' is defined on line 1486, but no explicit reference was found in the text == Unused Reference: 'RFC6442' is defined on line 1495, 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: September 8, 2015 (no affiliation) 6 March 7, 2015 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-02.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 September 8, 2015. 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 'ack' Element . . . . . . . . . . . . . . . . . . 12 83 9.1.1.1. Attributes of the 'ack' Element . . . . . . . . . 13 84 9.1.1.2. Child Elements of the 'ack' Element . . . . . . . 13 85 9.1.2. The 'capabilities' Element . . . . . . . . . . . . . 14 86 9.1.2.1. Child Elements of the 'capabilities' Element . . 14 87 9.1.3. The 'request' Element . . . . . . . . . . . . . . . . 15 88 9.1.3.1. Attributes of the 'request' Element . . . . . . . 15 89 9.1.3.2. Child Elements of the 'request' Element . . . . . 16 90 9.2. The emergencyCallData.eCall INFO package . . . . . . . . 16 91 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 93 12. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 13.1. Service URN Registrations . . . . . . . . . . . . . . . 20 96 13.2. MIME Content-type Registration for 97 'application/emergencyCallData.eCall.MSD+xml' . . . . . 21 98 13.3. MIME Content-type Registration for 99 'application/emergencyCallData.eCall.control+xml' . . . 22 100 13.4. Registration of the 'eCall.MSD' entry in the Emergency 101 Call Additional Data Blocks registry . . . . . . . . . . 24 102 13.5. Registration of the 'eCall.control' entry in the 103 Emergency Call Additional Data Blocks registry . . . . . 24 104 13.6. Registration of the emergencyCallData.eCall Info Package 24 105 13.7. URN Sub-Namespace Registration . . . . . . . . . . . . . 24 106 13.7.1. Registration for urn:ietf:params:xml:ns:eCall . . . 24 107 13.7.2. Registration for 108 urn:ietf:params:xml:ns:eCall:control . . . . . . . . 25 109 13.8. Registry creation . . . . . . . . . . . . . . . . . . . 26 110 13.8.1. eCall Control Action Registry . . . . . . . . . . . 26 111 13.8.2. eCall Static Message Registry . . . . . . . . . . . 27 112 13.8.3. eCall Reason Registry . . . . . . . . . . . . . . . 28 113 13.8.4. eCall Lamp ID Registry . . . . . . . . . . . . . . . 28 114 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 115 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 116 16. Changes from Previous Versions . . . . . . . . . . . . . . . 30 117 16.1. Changes from draft-ietf-01 to draft-ietf-02 . . . . . . 30 118 16.2. Changes from draft-ietf-00 to draft-ietf-01 . . . . . . 30 119 16.3. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 30 120 16.4. Changes from draft-gellens-02 to -03 . . . . . . . . . . 31 121 16.5. Changes from draft-gellens-01 to -02 . . . . . . . . . . 31 122 16.6. Changes from draft-gellens-00 to -01 . . . . . . . . . . 31 123 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 124 17.1. Normative References . . . . . . . . . . . . . . . . . . 31 125 17.2. Informative references . . . . . . . . . . . . . . . . . 32 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 128 1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 This document re-uses terminology defined in Section 3 of [RFC5012]. 136 Additionally, we use the following abbreviations: 138 +--------+----------------------------------------+ 139 | Term | Expansion | 140 +--------+----------------------------------------+ 141 | 3GPP | 3rd Generation Partnership Project | 142 | CEN | European Committee for Standardization | 143 | EENA | European Emergency Number Association | 144 | ESInet | Emergency Services IP network | 145 | IMS | Internet Multimedia Subsystem | 146 | IVS | In-Vehicle System | 147 | MNO | Mobile Network Operator | 148 | MSD | Minimum Set of Data | 149 | PSAP | Public Safety Answering Point | 150 +--------+----------------------------------------+ 152 2. Document Scope 154 This document is limited to the signaling, data exchange, and 155 protocol needs of next-generation eCall (NG-eCall, also referred to 156 as packet-switched eCall (PS-eCall) and all-IP eCall) within the SIP 157 framework for emergency calls, as described in [RFC6443] and 158 [RFC6881]. eCall itself is specified by 3GPP and CEN and these 159 specifications include far greater scope than is covered here. 161 The eCall service operates over cellular wireless communication, but 162 this document does not address cellular-specific details, nor client 163 domain selection (e.g., circuit-switched versus packet-switched). 164 All such aspects are the purview of their respective standards 165 bodies. The scope of this document is limited to eCall operating 166 within a SIP-based environment (e.g., 3GPP IMS Emergency Calling). 168 The technical contents of this document may be suitable for use in 169 other vehicle-initiated emergency call systems, but this is out of 170 scope for this document. 172 Vehicles designed for multiple regions may need to support eCall and 173 other Advanced Automatic Crash Notification systems, such as 174 described in [draft-ietf-ecrit-car-crash]. That system is compatible 175 with eCall, differing primarily in the specific data set that is 176 sent. 178 3. Introduction 180 Emergency calls made from vehicles (e.g., in the event of a crash) 181 assist in significantly reducing road deaths and injuries by allowing 182 emergency services to be aware of the incident, the state of the 183 vehicle, the location of the vehicle, and to have a voice channel 184 with the vehicle occupants. This enables a quick and appropriate 185 response. 187 The European Commission initiative of eCall was conceived in the late 188 1990s, and has evolved to a European Parliament decision requiring 189 the implementation of compliant in-vehicle systems (IVS) in new 190 vehicles and the deployment of eCall in the European Member States in 191 the very near future. eCall (and eCall-compatible systems) are also 192 being adopted in other regions. 194 The pan-European eCall system provides a standardized and mandated 195 mechanism for emergency calls by vehicles. eCall establishes 196 procedures for such calls to be placed by in-vehicle systems, 197 recognized and processed by the network, and routed to a specialized 198 PSAP where the vehicle data is available to assist the call taker in 199 assessing and responding to the situation. eCall provides a standard 200 set of vehicle, sensor (e.g., crash related), and location data. 202 An eCall may be either user-initiated or automatically triggered. 203 Automatically triggered eCalls indicate a car crash or some other 204 serious incident and carry a greater presumption of risk of injury. 205 Manually triggered eCalls may be reports of serious hazards and are 206 likely to require a different response than an automatically 207 triggered eCall. Manually triggered eCalls are also more likely to 208 be false (e.g., accidental) calls and may thus be subject to 209 different handling by the PSAP. 211 Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) 212 as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). Flags in 213 the call setup mark the call as an eCall, and further indicate if the 214 call was automatically or manually triggered. The call is routed to 215 an eCall-capable PSAP, a voice channel is established between the 216 vehicle and the PSAP, and an eCall in-band modem is used to carry a 217 defined set of vehicle, sensor (e.g., crash related), and location 218 data (the Minimum Set of Data or MSD) within the voice channel. The 219 same in-band mechanism is used for the PSAP to acknowledge successful 220 receipt of the MSD, and to request the vehicle to send a new MSD 221 (e.g., to check if the state of or location of the vehicle or its 222 occupants has changed). Work on next-generation eCall (NG-eCall, 223 also referred to as packet-switched eCall or PS eCall) is now in 224 process. As part of this work, the European Telecommunications 225 Standards Institute (ETSI) [SDO-ETSI] has published a Technical 226 Report titled "Mobile Standards Group (MSG); eCall for VoIP" [MSG_TR] 227 that presents findings and recommendations regarding support for 228 eCall in an all-IP environment. NG-eCall moves from circuit switched 229 to all-IP, and carries the vehicle data and other eCall-specific data 230 as additional data associated with the call. This document describes 231 how IETF mechanisms for IP-based emergency calls, including [RFC6443] 232 and [additional-data-draft] are used to provide the signaling and 233 data exchange of the next generation of pan-European eCall. 235 The [MSG_TR] recommendation for NG-eCall is to use 3GPP IMS emergency 236 calling with additional elements identifying the call as an eCall and 237 as carrying eCall data and with mechanisms for carrying the data. 238 3GPP IMS emergency services support multimedia, providing the ability 239 to carry voice, text, and video. This capability is referred to 240 within 3GPP as Multimedia Emergency Services (MMES). 242 A transition period will exist during which time the various entities 243 involved in initiating and handling an eCall might support next- 244 generation eCall, legacy eCall, or both. This transition period 245 might last several years or longer. The issue of migration/co- 246 existence during the transition period is very important but is 247 outside the scope of this document. The ETSI TR "Mobile Standards 248 Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in 249 Clause 7. 251 4. eCall Requirements 253 Overall eCall requirements are specified by CEN in [EN_16072] and by 254 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements specific to 255 vehicle data are contained in EN 15722 [msd]. For convenience, the 256 requirements most applicable to the limited scope of this document 257 are summarized very briefly below. 259 eCall requires: 261 o The call be recognized as an eCall (which is inherently an 262 emergency call) 263 o The call setup indicates if the call was manually or automatically 264 triggered 265 o A voice channel between the vehicle and the PSAP 266 o Carrying the MSD intrinsically with the call (the MSD needs to be 267 available to the same call-taker as the voice) 268 o The ability for the PSAP to acknowledge receipt of the MSD 269 o The ability for the PSAP to request that the vehicle generate and 270 transmit a new MSD 271 o The ability of the PSAP to be able to re-contact the occupants of 272 vehicle after the initial eCall is concluded 273 o The ability to perform a test call (which may be routed to a PSAP 274 but is not treated as an emergency call and not handled by a call 275 taker) 277 It is recognized that NG-eCall offers many potential enhancements, 278 although these are not required by current EU regulations. For 279 convenience, the enhancements most applicable to the limited scope of 280 this document are summarized very briefly below. 282 NG-eCall is expected to offer: 284 o The ability to carry more data (e.g., an enhanced MSD or an MSD 285 plus additional sets of data) 286 o The ability to handle video 287 o The ability to handle text 288 o The ability for the PSAP to access vehicle components (e.g., an 289 onboard camera (such as rear facing or blind-spot cameras) for a 290 visual assessment of the crash site situation) 291 o The ability for the PSAP to request the vehicle to take actions 292 (e.g., sound the horn, disable the ignition, lock/unlock doors) 293 o The ability to avoid audio muting of the voice channel (because 294 the MSD is not transferred using an in-band modem) 296 5. Vehicle Data 298 Pan-European eCall provides a standardized and mandated set of 299 vehicle related data, known as the Minimum Set of Data (MSD). The 300 European Committee for Standardization (CEN) has specified this data 301 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 302 MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding. The XML 303 encoding is better suited for use in SIP messages and is used in this 304 document. (The ASN.1 encoding is specified in Annex A of EN 15722 305 [msd], while the XML encoding is specified in Annex C.) 307 The "Additional Data related to an Emergency Call" document 308 [additional-data-draft] establishes a general mechanism for attaching 309 blocks of data to a SIP emergency call. This document makes use of 310 that mechanism to carry the eCall MSD in a SIP emergency call. 312 This document registers the 'application/ 313 emergencyCallData.eCall.MSD+xml' MIME Content-Type to enable the MSD 314 to be carried in SIP. This document also adds the 'eCall.MSD' entry 315 to the Emergency Call Additional Data Blocks registry (established by 316 [additional-data-draft]) to enable the MSD to be recognized as such 317 in a SIP-based eCall emergency call. 319 Note that if additional data sets are defined and registered (e.g., 320 in the future or in other regions) and transmitted using the same 321 mechanisms, the size and frequency of transmission during a session 322 needs to be evaluated to be sure it is appropriate to use the 323 signaling channel. 325 6. Call Setup 327 In circuit-switched eCall, the IVS places a special form of a 112 328 emergency call which carries the eCall flag (indicating that the call 329 is an eCall and also if the call was manually or automatically 330 triggered); the mobile network operator (MNO) recognizes the eCall 331 flag and routes the call to an eCall-capable PSAP; vehicle data is 332 transmitted to the PSAP via the eCall in-band modem (in the voice 333 channel). 335 ///----\\\ 112 voice call with eCall flag +------+ 336 ||| IVS |||---------------------------------------->+ PSAP | 337 \\\----/// vehicle data via eCall in-band modem +------+ 339 Figure 1: circuit-switched eCall 341 An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD 342 in accordance with [additional-data-draft] by encoding it as 343 specified (per Appendix C of EN 15722 [msd]) and attaching it to an 344 INVITE as a MIME body part. The body part is identified by its MIME 345 content-type ('application/emergencyCallData.eCall.MSD+xml') in the 346 Content-Type header field of the body part. The body part is 347 assigned a unique identifier which is listed in a Content-ID header 348 field in the body part. The INVITE is marked as containing the MSD 349 by adding (or appending to) a Call-Info header field at the top level 350 of the INVITE. This Call-Info header field contains a CID URL 351 referencing the body part's unique identifier, and a 'purpose' 352 parameter identifying the data as the eCall MSD per the registry 353 entry; the 'purpose' parameter's value is 'emergencyCallData.' and 354 the root of the MIME type (not including the 'emergencyCallData' 355 prefix and any suffix such as '+xml' (e.g., 356 'purpose=emergencyCallData.eCall.MSD'). 358 For NG-eCall, the IVS establishes an emergency call using the 3GPP 359 IMS solution with a Request-URI indicating an eCall type of emergency 360 call and with vehicle data attached; the MNO or ESInet recognizes the 361 eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP 362 interpets the vehicle data sent with the call and makes it available 363 to the call taker. 365 ///----\\\ IMS emergency call with eCall URN +------+ 366 IVS ----------------------------------------->+ PSAP | 367 \\\----/// vehicle data included in call setup +------+ 369 Figure 2: NG-eCall 371 This document registers new service URN children within the "sos" 372 subservice. These URNs provide the mechanism by which an eCall is 373 identified, and differentiate between manually and automatically 374 triggered eCalls (which may be subject to different treatment, 375 depending on policy). The two service URNs are: 376 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 378 7. Call Routing 380 The routing rules for eCalls are likely to differ from those of other 381 emergency calls because eCalls are special types of emergency calls 382 (with implications for the types of response required) and need to be 383 handled by specially designated PSAPs. In an environment that uses 384 ESInets, the originating network passes all types of emergency calls 385 to an ESInet (which have a request URI containing the "SOS" service 386 URN). The ESInet is then responsible for routing such calls to the 387 appropriate PSAP. In an environment without an ESInet, the emergency 388 services authorities and the originating network jointly determine 389 how such calls are routed. 391 7.1. ESInets 393 This section provides background information on ESInets for 394 information only. 396 An Emergency Services IP Network (ESInet) is a network operated by 397 emergency services authorities. It handles emergency call routing 398 and processing before delivery to a PSAP. In the NG1-1-2 399 architecture adopted by EENA, each PSAP is connected to one or more 400 ESInets. Each originating network is also connected to one or more 401 ESInets. The ESInets maintain policy-based routing rules which 402 control the routing and processing of emergency calls. The 403 centralization of such rules within ESInets provides for a cleaner 404 separation between the responsibilities of the originating network 405 and that of the emergency services network, and provides greater 406 flexibility and control over processing of emergency calls by the 407 emergency services authorities. This makes it easier to react 408 quickly to unusual situations that require changes in how emergency 409 calls are routed or handled (e.g., a natural disaster closes a PSAP), 410 as well as ease in making long-term changes that affect such routing 411 (e.g., cooperative agreements to specially handle calls requiring 412 translation or relay services). ESInets may support the ability to 413 interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that 414 are not IP PSAPs (similarly to the ability to interwork IP emergency 415 calls to legacy non-IP PSAPs). Note that in order to support legacy 416 eCall-capable PSAPs that are not IP PSAPs and are not attached to an 417 ESInet, an originating network may need the ability to route an eCall 418 itself (e.g., to an interworking facility with interconnection to a 419 suitable legacy eCall capable PSAP) based on the eCall and manual or 420 automatic indications. The ETSI TR "Mobile Standards Group (MSG); 421 eCall for VoIP" [MSG_TR] discusses transition issues in Clause 7. 423 8. Test Calls 425 eCall requires the ability to place test calls. These are calls that 426 are recognized and treated to some extent as eCalls but are not given 427 emergency call treatment and are not handled by call takers. The 428 test call facility allows the IVS or user to verify that an eCall can 429 be successfully established with voice communication. The IVS can 430 also verify that the MSD was successfully received. 432 A service URN starting with "test." indicates a test call. For 433 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 434 This functionality is defined in [RFC6881]. 436 This document registers "urn:service:test.sos.ecall" for eCall test 437 calls. 439 the current eCall test call facility is a non-emergency number so 440 does not get treated as an emergency call. MNOs may treat a vehicle 441 call in the "test" service URN in a way that tests as much 442 functionality as desired, but this is outside the scope of this 443 document. 445 PSAPs that have the ability to process NG-eCalls SHOULD accept test 446 calls and send an acknowledgment if the MSD was successfully 447 received, per this document. Such PSAPs MAY also play an audio clip 448 (for example, saying that the call reached a PSAP) in addition to 449 supporting media loopback per [RFC6881]. 451 9. eCall-Specific Control/Metadata 453 eCall requires the ability for the PSAP to acknowledge successful 454 receipt of an MSD sent by the IVS, and for the PSAP to request that 455 the IVS send an MSD (e.g., the call taker may initiate a request for 456 a new MSD to see if the vehicle's state or location has changed). 457 Future enhancements are desired to enable the PSAP to send other 458 requests to the vehicle, such as locking or unlocking doors, sounding 459 the horn, flashing the lights, starting a video stream from on-board 460 cameras (such as rear focus or blind-spot), etc. 462 The mechanism established in [additional-data-draft], used in 463 Section 5 of this document to carry the MSD from the IVS to the PSAP, 464 is also used to carry a block of control data from the PSAP to the 465 IVS. This eCall control block (sometimes referred to as eCall 466 metadata) is an XML structure containing eCall-specific elements. 467 When the PSAP needs to send an eCall control block that is in 468 response to the MSD or other data sent by the IVS in a SIP request, 469 the control block can be sent in the SIP response to that request 470 (e.g., the INVITE). When the PSAP needs to send an eCall control 471 block that is not an immediate response to an MSD or other data sent 472 by the IVS, the control block can be transmitted from the PSAP to the 473 IVS in a SIP INFO message within the established session. The IVS 474 can then send any requested data (such as a new MSD) in the reply to 475 the INFO message. This mechanism flexibly allows the PSAP to send 476 eCall-specific data to the IVS and the IVS to respond. If control 477 data sent in a response message requests the IVS to send a new MSD or 478 other data block, or to perform an action other than sending data, 479 the IVS can send the requested data or an acknowledgment regarding 480 the action in an INFO message within the session (it could also use 481 re-INVITE but that is unnecessary when no aspect of the session or 482 media is changing). 484 This mechanism requires 486 o An XML definition of the eCall control object 487 o An extension mechanism by which new elements can be added to the 488 control object definition (e.g., permitting additional elements to 489 be included by adding their namespace) 490 o A MIME type registration for the control object (so it can be 491 carried in SIP messages and responses) 492 o An entry in the Emergency Call Additional Data Blocks sub-registry 493 (established by [additional-data-draft]) so that the control block 494 can be recognized as emergency call specific data within the SIP 495 messages 496 o An Info-Package registration per [RFC6086] permitting the control 497 block within Info messages 499 9.1. The eCall Control Block 501 The eCall control block is an XML data structure allowing for 502 acknowledgments, requests, and capabilities information. It is 503 carried in a SIP body part with a specific MIME content type. Three 504 top-level elements are defined for use within an eCall control block: 506 ack Used in a control block sent by either side. The PSAP 507 uses this to acknowledge receipt of data set sent by 508 the IVS. The IVS uses this to acknowledge receipt of a 509 request by the PSAP when that request would not 510 otherwise be acknowledged (if the PSAP requests the 511 vehicle to send data and the vehicle does so, the data 512 serves as a success acknowledgement). 514 capabilities: Used in a control block sent from the IVS to the PSAP 515 (in the initial INVITE or subsequently if desired) to 516 inform the PSAP of the vehicle capabilities. Child 517 elements contain all actions and data types supported 518 by the vehicle . 520 request Used in a control block sent by the PSAP to the IVS, to 521 request the vehicle to perform an action. 523 Mandatory Actions (the IVS and the PSAP MUST support): 525 o Transmit data object 527 Optional Actions (the IVS and the PSAP MAY support): 529 o Play and/or display static (pre-defined) message 530 o Speak/display dynamic text (text supplied in action) 531 o Flash lights, honk horn 533 The 'ack' element indicates the object being acknowledged, and 534 reports success or failure. 536 The 'capabilities' element has child 'request' elements to indicate 537 the actions supported by the IVS. 539 The 'request' element contains attributes to indicate the request and 540 to supply any needed information, and MAY contain a 'text' child 541 element to contain the text for a dynamic message. The 'action' 542 attribute is mandatory and indicates the specific action. An IANA 543 registry is established by this document in Section 13.8.1 to contain 544 the allowed values. 546 New elements, child elements, and attributes can be defined with 547 their own sub-namespaces. IANA registries are used to specify the 548 permitted values of several elements and attributes. These 549 mechanisms allow for extension. 551 The control block does not contain a 'request' action to play dynamic 552 media (such as a pre-recorded audio message). The SIP re-INVITE 553 mechanism can be used to establish a one-way media stream for this 554 purpose. 556 9.1.1. The 'ack' Element 558 The 'ack' element is transmitted by the PSAP to acknowledge receipt 559 of an eCall data object. An 'ack' element sent by a PSAP references 560 the unique ID of the data object that was sent by the IVS, and 561 further indicates if the PSAP considers the receipt successful or 562 not. The 'ack' element is also transmitted by the IVS to the PSAP to 563 acknowledge receipt of a 'request' element that requested the IVS to 564 perform an action other than transmitting a data object (e.g., a 565 request to display a message would be acknowledged, but a request to 566 transmit a data object would not result in a separate 'ack' element 567 being sent, since the data object itself serves as acknowledgment.) 568 An 'ack' element sent by an IVS references the unique ID of the 569 request being acknowledged, and further indicates whether the request 570 was successfully performed. 572 The 'ack' element has the following attributes and child elements: 574 9.1.1.1. Attributes of the 'ack' Element 576 The 'ack' element has the following attributes: 578 Name: ref 579 Usage: Mandatory 580 Type: anyURI 581 Description: References the Content-ID of the body part that 582 contained the data object or control object being acknowledged. 583 Example: 585 Name: rec 586 Usage: Mandatory 587 Type: Boolean 588 Description: Indicates if the referenced object was successfully 589 received or not. 590 Example: 592 9.1.1.2. Child Elements of the 'ack' Element 594 The 'ack' element has the following child elements: 596 Name: ActionResult 597 Usage: Optional 598 Description: An 'ActionResult' element indicates the result of an 599 action (other than a 'send-data' action). It has the following 600 attributes: 602 Name: action 603 Usage: Mandatory 604 Type: token 605 Description: Contains the value of the 'action' attribute of the 606 'request' element 608 Name: success 609 Usage: Mandatory 610 Type: Boolean 611 Description: Indicates if the action was successfully 612 accomplished 614 Name: reason 615 Usage: Conditional 616 Type: token 617 Description: Used when 'success' is "False", this attribute 618 contains a reason code for a failure. A registry for reason 619 codes is defined in Section 13.8.3. 621 Name: details 622 Usage: optional 623 Type: string 624 Description: Contains further explanation of the circumstances of 625 a success or failure. The contents are implementation-specific 626 and human-readable. 628 Example: 630 Example: 633 9.1.2. The 'capabilities' Element 635 The 'capabilities' element is transmitted by the IVS to indicate to 636 the PSAP its capabilities. No attributes are currently defined. The 637 following child elements may be used: 639 9.1.2.1. Child Elements of the 'capabilities' Element 641 The 'capabilities' element has the following child elements: 643 Name: request 644 Usage: Mandatory 645 Description: The 'capabilities' element contains a child 646 element per action supported by the vehicle. Because support for 647 a 'send-data' action is REQUIRED, a child element with a 648 "send-data" 'action' attribute is also REQUIRED. The 'supported- 649 datatype' attribute is REQUIRED in this element and MUST 650 contain all eCall data blocks supported by the IVS. Currently, 651 only the 'eCall.MSD' datatype is defined. All other actions are 652 OPTIONAL. If the "msg-static" action is supported, a 653 child element with a "msg-static" 'action' attribute is sent, with 654 a 'msgid' attribute set to the highest supported static message 655 supported by the vehicle. 656 Examples: 658 660 661 663 9.1.3. The 'request' Element 665 A 'request' element appears one or more times on its own or as a 666 child of a 'capabilities' element. The following attributes and 667 child elements may be used: 669 9.1.3.1. Attributes of the 'request' Element 671 The 'request' element has the following attributes: 673 Name: action 674 Usage: Mandatory 675 Type: token 676 Description: Identifies the action that the vehicle is requested to 677 perform. An IANA registry is established in Section 13.8.1 to 678 contain the allowed values. 679 Example: action="send-data" 681 Name: msgid 682 Usage: Conditional 683 Type: int 684 Description: Mandatory with a "msg-static" action. Indicates the 685 identifier of the static message to be displayed and/or spoken for 686 the vehicle occupants. This document established an IANA registry 687 for messages and their IDs, in Section 13.8.2 688 Example: msgid="3" 690 Name: persistance 691 Usage: Optional 692 Type: duration 693 Description: Specifies how long to carry on the specified action, 694 for example, how long to continue honking or flashing. If absent, 695 the default is indefinitely. 696 Example: persistance="PT1H" 698 Name: datatype 699 Usage: Conditional 700 Type: token 701 Description: Mandatory with a "send-data" action. Specifies the 702 data block that the IVS is requested to transmit, using the same 703 identifier as in the 'purpose' attribute set in a Call-Info header 704 field to point to the data block. Permitted values are contained 705 in the 'Emergency Call Data Types' IANA registry established in 706 [additional-data-draft]. 707 Example: datatype="eCall.MSD" 709 Name: supported-datatype 710 Usage: Conditional 711 Type: token 712 Description: Used with a 'send-data' action in a 'request' element 713 that is a child of a 'capability' element, this attribute lists 714 all data blocks that the vehicle can transmit, using the same 715 identifier as in the 'purpose' attribute in a Call-Info header 716 field to point to the data block. Permitted values are contained 717 in the 'Emergency Call Data Types' IANA registry established in 718 [additional-data-draft]. Multiple values are separated with a 719 semicolon. 720 Example: supported-datatype="eCall.MSD; VEDS; eCall.foo" 722 Name: lamp-ID 723 Usage: Conditional 724 Type: token 725 Description: Used with a 'lamp' action, indicates which lamps the 726 action affects. This document creates a registry of lamp-ID 727 tokens, in Section 13.8.4 728 Example: lamp-ID="hazard" 730 Name: lamp-action 731 Usage: Conditional 732 Type: enumeration 733 Description: Used with a 'lamp' action, indicates if the lamp should 734 be illuminated, turned off, or flashed. Permitted values are 735 'on', 'off', and 'flash'. 736 Example: lamp-action="flash" 738 9.1.3.2. Child Elements of the 'request' Element 740 The 'request' element has the following child elements: 742 Name: text 743 Usage: Conditional 744 Type: string 745 Description: Used within a element to 746 contain the text to be displayed and/or spoken (via text-to- 747 speech) for the vehicle occupants. 748 Example: Emergency authorities are aware of your incident and 749 location. Due to a multi-vehicle incident in your area, no one is 750 able to speak with you right now. Please remain calm. We will 751 assist you soon. 753 9.2. The emergencyCallData.eCall INFO package 755 This document registers the 'emergencyCallData.eCall' INFO package. 756 Both endpoints (the IVS and the PSAP equipment) set the Recv-Info 757 header field to 'emergencyCallData.eCall' per [RFC6086] to indicate 758 ability to receive INFO messages carrying eCall data or control 759 blocks. 761 Support for the 'emergencyCallData.eCall' INFO package indicates the 762 ability to receive eCall data and control blocks, which are carried 763 in a body part whose subtype starts with 'emergencyCallData.eCall.'. 764 At present there is only one defined eCall data block, which has the 765 'application/emergencyCallData.eCall.MSD+xml' MIME type, and one 766 eCall control block, which has the 'application/ 767 emergencyCallData.eCall.control+xml' MIME type. The eCall control 768 block includes the ability for the IVS to indicate its capabilities, 769 so in the event additional eCall blocks are defined, the IVS can 770 indicate which it supports. 772 The use of INFO is based on an analysis of the requirements against 773 the intent and effects of INFO versus other approaches (such as SIP 774 MESSAGE, media plane, or non-SIP protocols). In particular, the 775 transport of eCall data and control blocks is done only during an 776 emergency session established with SIP, using the mechanism 777 established in [additional-data-draft], and is normally carried in 778 the initial INVITE and its response; the use of INFO only occurs when 779 a data block or request needs to be sent subsequently during the 780 call. While MESSAGE could be used, it is not tied to a SIP session 781 as is INFO. REINVITE could also be used, but is normally used to 782 modify the session. SUBSCRIBE/NOTIFY could be coerced into service, 783 but the semantics are not a clean fit. Hence, INFO is appropriate. 785 An INFO request message carrying an eCall data or control block has 786 an Info-Package header field set to 'emergencyCallData.eCall' per 787 [RFC6086]. The INFO request message is marked as containing the 788 eCall data or control block by a Call-Info header field containing a 789 CID URL referencing the unique identifier of the body part containing 790 the eCall data or control, and a 'purpose' parameter identifying the 791 block. Because the eCall data or control block is being carried in 792 an INFO request message, the body part also carries a Content- 793 Disposition header field set to "Info-Package". 795 Per [additional-data-draft], emergency call related additional data 796 MAY be included in any SIP request or response message that may 797 contain a body. Hence, notwithstanding Section 4.3.2. of [RFC6086], 798 INFO response messages MAY contain eCall data or control blocks, 799 provided they are included as described in this document (with a 800 Call-Info header field containing a CID URL referencing the unique 801 identifier of the body part, and a 'purpose' parameter identifying 802 the block). When eCall data or control blocks are included in an 803 INFO response message, this is done per [additional-data-draft] and 804 this document, and not under [RFC6086]; that is, they are included as 805 emergency call additional data, not as an INFO package associated 806 data. 808 10. Examples 810 Figure 3 shows an eCall. The call uses the request URI 811 'urn:service:sos.ecall.automatic' service URN and is recognized as an 812 eCall, and further as one that was invoked automatically by the IVS 813 due to a crash or other serious incident. In this example, the 814 originating network routes the call to an ESInet (as for any 815 emergency call in an environment with an ESInet). The ESInet routes 816 the call to the appropriate NG-eCall capable PSAP. The emergency 817 call is received by the ESInet's Emergency Services Routing Proxy 818 (ESRP), as the entry point into the ESInet. The ESRP routes the call 819 to a PSAP, where it is received by a call taker. In deployments 820 where there is no ESInet, the originating network routes the call 821 directly to the appropriate NG-eCall capable PSAP. 823 +------------+ +---------------------------------------+ 824 | | | +-------+ | 825 | | | | PSAP2 | | 826 | | | +-------+ | 827 | | | | 828 | | | +------+ +-------+ | 829 Vehicle-->| |--+->| ESRP |---->| PSAP1 |--> Call-Taker | 830 | | | +------+ +-------+ | 831 | | | | 832 | | | +-------+ | 833 | | | | PSAP3 | | 834 | Originating| | +-------+ | 835 | Mobile | | | 836 | Network | | ESInet | 837 +------------+ +---------------------------------------+ 839 Figure 3: Example of NG-eCall Message Flow 841 The example, shown in Figure 4, illustrates a SIP eCall INVITE that 842 contains an MSD. 844 INVITE urn:service:sos.ecall.automatic SIP/2.0 845 To: urn:service:sos.ecall.automatic 846 From: ;tag=9fxced76sl 847 Call-ID: 3848276298220188511@atlanta.example.com 848 Geolocation: 849 Geolocation-Routing: no 850 Call-Info: cid:1234567890@atlanta.example.com; 851 purpose=emergencyCallData.eCall.MSD 852 Accept: application/sdp, application/pidf+xml 853 CSeq: 31862 INVITE 854 Recv-Info: emergencyCallData.eCall 855 Content-Type: multipart/mixed; boundary=boundary1 856 Content-Length: ... 858 --boundary1 860 Content-Type: application/sdp 862 ...Session Description Protocol (SDP) goes here 864 --boundary1 866 Content-Type: application/emergencyCallData.eCall.MSD+xml 867 Content-ID: 1234567890@atlanta.example.com 869 ...eCall MSD data object goes here 871 --boundary1-- 873 Figure 4: SIP NG-eCall INVITE 875 11. Security Considerations 877 The security considerations described in [RFC5069] apply here. 879 An eCall will carry two forms of location data: the network-provided 880 location that is inherently part of IMS emergency calls (which might 881 be determined solely by the network, or in cooperation with or 882 possibly entirely by the originating device), and the IVS-supplied 883 location within the MSD. This is likely to be useful to the PSAP, 884 especially when the two locations are independently determined. Even 885 in situations where the network-supplied location is limited to the 886 cell site, this can be useful as a sanity check on the device- 887 supplied location contained in the MSD. 889 The document [I-D.ietf-ecrit-trustworthy-location] discusses trust 890 issues regarding location provided by or determined in cooperation 891 with end devices. 893 The mechanism by which the PSAP sends acknowledgments and requests to 894 the vehicle requires authenticity considerations; when the PSAP 895 request is received within a session initiated by the vehicle as an 896 eCall emergency call placed over a cellular network, there is a 897 higher degree of trust that the source is indeed a PSAP. If the PSAP 898 request is received in other situations, such as a call-back, the 899 trust issues in verifying that a call-back is indeed from a PSAP are 900 more complex (see the PSAP Callback document [RFC7090]). A further 901 safeguard (applicable regardless of which end initiated the call and 902 the means of the call) is for the PSAP or emergency service provider 903 to sign the body part using a certificate issued by a known emergency 904 services certificate authority and for which the IVS can verify the 905 root certificate. 907 12. XML Schema 909 This section defines the XML schema of the eCall control block. 911 912 917 920 922 Figure 5: eCall Control Block Schema 924 13. IANA Considerations 926 13.1. Service URN Registrations 928 IANA is requested to register the URN 'urn:service:sos.ecall' under 929 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 931 This service identifies a type of emergency call (placed by a 932 specialized in-vehicle system and a carrying standardized set of data 933 related to the vehicle and crash or incident, and is needed to direct 934 the call to a specialized public safety answering point (PSAP) with 935 technical and operational capabilities to handle such calls. Two 936 sub-services are registered as well, namely 937 urn:service:sos.ecall.manual 939 This service URN indicates that an eCall had been triggered based 940 on the manual interaction of the driver or a passenger. 942 urn:service:sos.ecall.automatic 944 This service URN indicates that an eCall had been triggered 945 automatically, for example, due to a crash or other serious 946 incident (e.g., fire). 948 IANA is also requested to register the URN 949 'urn:service:test.sos.ecall' under the sub-service 'test' registry 950 defined in Setcion 17.2 of [RFC6881]. 952 13.2. MIME Content-type Registration for 'application/ 953 emergencyCallData.eCall.MSD+xml' 955 IANA is requested to add application/emergencyCallData.eCall.MSD+xml 956 as a MIME content type, with a reference to this document, in 957 accordance to the procedures of RFC 6838 [RFC6838] and guidelines in 958 RFC 7303 [RFC7303]. 960 MIME media type name: application 962 MIME subtype name: emergencyCallData.eCall.MSD+xml 964 Mandatory parameters: none 966 Optional parameters: charset 968 Indicates the character encoding of the XML content. 970 Encoding considerations: Uses XML, which can employ 8-bit 971 characters, depending on the character encoding used. See 972 Section 3.2 of RFC 7303 [RFC7303]. 974 Security considerations: This content type is designed to carry 975 vehicle and incident-related data during an emergency call. This 976 data contains personal information including vehicle VIN, 977 location, direction, etc. Appropriate precautions need to be 978 taken to limit unauthorized access, inappropriate disclosure to 979 third parties, and eavesdropping of this information. In general, 980 it is permissible for the data to be unprotected while briefly in 981 transit within the Mobile Network Operator (MNO); the MNO is 982 trusted to not permit the data to be accessed by third parties. 983 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 984 contain more discussion. 986 Interoperability considerations: None 988 Published specification: Annex C of EN 15722 [msd] 990 Applications which use this media type: Pan-European eCall 991 compliant systems 993 Additional information: None 995 Magic Number: None 997 File Extension: .xml 999 Macintosh file type code: 'TEXT' 1001 Person and email address for further information: Hannes 1002 Tschofenig, Hannes.Tschofenig@gmx.net 1004 Intended usage: LIMITED USE 1006 Author: This specification was produced by the European Committee 1007 For Standardization (CEN). For contact information, please see 1008 . 1010 Change controller: The European Committee For Standardization 1011 (CEN) 1013 13.3. MIME Content-type Registration for 'application/ 1014 emergencyCallData.eCall.control+xml' 1016 IANA is requested to add application/ 1017 emergencyCallData.eCall.control+xml as a MIME content type, with a 1018 reference to this document, in accordance to the procedures of RFC 1019 6838 [RFC6838] and guidelines in RFC 7303 [RFC7303]. 1021 MIME media type name: application 1023 MIME subtype name: emergencyCallData.eCall.control+xml 1025 Mandatory parameters: none 1027 Optional parameters: charset 1029 Indicates the character encoding of the XML content. 1031 Encoding considerations: Uses XML, which can employ 8-bit 1032 characters, depending on the character encoding used. See 1033 Section 3.2 of RFC 7303 [RFC7303]. 1035 Security considerations: This content type carries metadata and 1036 control information and requests, primarily from a Public Safety 1037 Answering Point (PSAP) to an In-Vehicle System (IVS) during an 1038 emergency call, and also capabilities from the IVS to the PSAP. 1039 Metadata (such as an acknowledgment that data sent by the IVS to 1040 the PSAP was successfully received) has limited privacy and 1041 security implications. Control information (such as requests from 1042 the PSAP that the vehicle perform an action) has some privacy and 1043 important security implications. The privacy concern arises from 1044 the ability to request the vehicle to transmit a data set, which 1045 as described in Section 13.2, may contain personal information. 1046 The security implication is the ability to request the vehicle to 1047 perform an action. It is important that control information 1048 originate only from a PSAP or other emergency services provider, 1049 and not from an impostor. The first safeguard for this is the 1050 security of the cellular network over which the emergency call was 1051 placed. In particular, when the IVS initiates an eCall over a 1052 cellular network, the MNO routes the call to a PSAP. (Calls 1053 placed using other means, such as Wi-Fi or over-the-top services, 1054 do not carry the same degree of trust.) Calls received by the 1055 IVS, such as a call-back from a PSAP, also do not carry the same 1056 degree of trust, since the current mechanisms are not ideal for 1057 verifying that such a call is indeed from a PSAP in response to an 1058 emergency call placed by the IVS. See the discussion in 1059 Section 11 and the PSAP Callback document [RFC7090]. A further 1060 safeguard, and one applicable regardless of which end initiated 1061 the call and the means of the call, is for the PSAP or emergency 1062 service provider to sign the body part using a certificate issued 1063 by a known emergency services certificate authority and for which 1064 the IVS can verify the root certificate. Sections 7 and Section 8 1065 of [I-D.ietf-ecrit-additional-data] contain more discussion. 1067 Interoperability considerations: None 1069 Published specification: Annex C of EN 15722 [msd] 1071 Applications which use this media type: Pan-European eCall 1072 compliant systems 1074 Additional information: None 1076 Magic Number: None 1078 File Extension: .xml 1080 Macintosh file type code: 'TEXT' 1081 Person and email address for further information: Randall Gellens, 1082 rg+ietf@qti.qualcomm.com 1084 Intended usage: LIMITED USE 1086 Author: The IETF ECRIT WG. 1088 Change controller: The IETF ECRIT WG. 1090 13.4. Registration of the 'eCall.MSD' entry in the Emergency Call 1091 Additional Data Blocks registry 1093 This specification requests IANA to add the 'eCall.MSD' entry to the 1094 Emergency Call Additional Data Blocks registry (established by 1095 [additional-data-draft]), with a reference to this document. 1097 13.5. Registration of the 'eCall.control' entry in the Emergency Call 1098 Additional Data Blocks registry 1100 This specification requests IANA to add the 'eCall.control' entry to 1101 the Emergency Call Additional Data Blocks registry (established by 1102 [additional-data-draft]), with a reference to this document. 1104 13.6. Registration of the emergencyCallData.eCall Info Package 1106 IANA is requested to add emergencyCallData.eCall to the Info Packages 1107 Registry under "Session Initiation Protocol (SIP) Parameters", with a 1108 reference to this document. 1110 13.7. URN Sub-Namespace Registration 1112 13.7.1. Registration for urn:ietf:params:xml:ns:eCall 1114 This section registers a new XML namespace, as per the guidelines in 1115 RFC 3688 [RFC3688]. 1117 URI: urn:ietf:params:xml:ns:eCall 1119 Registrant Contact: IETF, ECRIT working group, , as 1120 delegated by the IESG . 1122 XML: 1124 BEGIN 1125 1126 1128 1129 1130 1132 Namespace for eCall Data 1133 1134 1135

Namespace for eCall Data 1136

1137

See [TBD: This document].

1138 1139 1140 END 1142 13.7.2. Registration for urn:ietf:params:xml:ns:eCall:control 1144 This section registers a new XML namespace, as per the guidelines in 1145 RFC 3688 [RFC3688]. 1147 URI: urn:ietf:params:xml:ns:eCall:control 1149 Registrant Contact: IETF, ECRIT working group, , as 1150 delegated by the IESG . 1152 XML: 1154 BEGIN 1155 1156 1158 1159 1160 1162 Namespace for eCall Data: 1163 Control Block 1164 1165 1166

Namespace for eCall Data 1167

1168

Control Block

1169

See [TBD: This document].

1170 1171 1172 END 1174 13.8. Registry creation 1176 This document creates a new registry called 'eCall Control Data'. 1177 The following sub-registries are created for this registry. 1179 13.8.1. eCall Control Action Registry 1181 This document creates a new sub-registry called "eCall Control Action 1182 Registry". As defined in [RFC5226], this registry operates under 1183 "Expert Review" rules. The expert should determine that the proposed 1184 action is within the purview of a vehicle, is sufficiently 1185 distinguishable from other actions, and the actions is clearly and 1186 fully described. In most cases, a published and stable document is 1187 referenced for the description of the action. 1189 The content of this registry includes: 1191 Name: The identifier to be used in the 'action' attribute of an 1192 eCall control 'request' element. 1194 Description: A description of the action. In most cases this will 1195 be a reference to a published and stable document. The 1196 description MUST specify if any attributes or child elements are 1197 optional or mandatory, and describe the action to be taken by the 1198 vehicle. 1200 The initial set of values is listed in Table 2. 1202 +-------------+------------------------------+ 1203 | Name | Description | 1204 +-------------+------------------------------+ 1205 | send-data | Section xxx of this document | 1206 | | | 1207 | msg-static | Section xxx of this document | 1208 | | | 1209 | msg-dynamic | Section xxx of this document | 1210 | | | 1211 | honk | Section xxx of this document | 1212 | | | 1213 | lamp | Section xxx of this document | 1214 +-------------+------------------------------+ 1216 Table 2: eCall Control Action Registry Initial Values 1218 13.8.2. eCall Static Message Registry 1220 This document creates a new sub-registry called "eCall Static Message 1221 Registry". Because all compliant vehicles are expected to support 1222 all static messages translated into all languages supported by the 1223 vehicle, it is important to limit the number of such messages. As 1224 defined in [RFC5226], this registry operates under "Publication 1225 Required" rules, which require a stable, public document and imply 1226 expert review of the publication. The expert should determine that 1227 the document has been published by an appropriate emergency services 1228 organization (e.g., NENA, EENA, APCO) and that the proposed message 1229 is sufficiently distinguishable from other messages. 1231 The content of this registry includes: 1233 ID: An integer identifier to be used in the 'msgid' attribute of an 1234 eCall control 'request' element. 1236 Message: The text of the message. Messages are listed in the 1237 registry in English; vehicles are expected to implement 1238 translations into languages supported by the vehicle. 1240 When new messages are added to the registry, the message text is 1241 determined by the registrant; IANA assigns the IDs. Each message is 1242 assigned a consecutive integer value as its ID. This allows an IVS 1243 to indicate by a single integer value that it supports all messages 1244 with that value or lower. 1246 The initial set of values is listed in Table 3. 1248 +----+--------------------------------------------------------------+ 1249 | ID | Message | 1250 +----+--------------------------------------------------------------+ 1251 | 1 | Emergency authorities are aware of your incident and | 1252 | | location. No one is free to speak with you right now. We | 1253 | | will help you as soon as possible. | 1254 +----+--------------------------------------------------------------+ 1256 Table 3: eCall Static Message Registry 1258 13.8.3. eCall Reason Registry 1260 This document creates a new sub-registry called "eCall Reason 1261 Registry" which contains values for the 'reason' attribute of the 1262 'ActionResult' element. As defined in [RFC5226], this registry 1263 operates under "Expert Review" rules. The expert should determine 1264 that the proposed reason is sufficiently distinguishable from other 1265 reasons and that the proposed description is understandable and 1266 correctly worded. 1268 The content of this registry includes: 1270 ID: A short string identifying the reason, for use in the 'reason' 1271 attribute of an 'ActionResult' element. 1273 Description: A description of the reason. 1275 The initial set of values is listed in Table 4. 1277 +------------------+------------------------------------------------+ 1278 | ID | Description | 1279 +------------------+------------------------------------------------+ 1280 | unsupported | The 'action' is not supported. | 1281 | | | 1282 | unable | The 'action' could not be accomplished. | 1283 | | | 1284 | data-unsupported | The data item referenced in a 'send-data' | 1285 | | request is not supported. | 1286 +------------------+------------------------------------------------+ 1288 Table 4: eCall Reason Registry 1290 13.8.4. eCall Lamp ID Registry 1292 This document creates a new sub-registry called "eCall Lamp ID 1293 Registry" to standardize the names of automotive lamps (lights). As 1294 defined in [RFC5226], this registry operates under "Expert Review" 1295 rules. The expert should determine that the proposed lamp name is 1296 clearly understandable and is sufficiently distinguishable from other 1297 lamp names. 1299 The content of this registry includes: 1301 Name: The identifier to be used in the 'lamp-ID' attribute of an 1302 eCall control 'request' element. 1304 Description: A description of the lamp (light). 1306 The initial set of values is listed in Table 5. 1308 +----------------+---------------------------------------------+ 1309 | Name | Description | 1310 +----------------+---------------------------------------------+ 1311 | head | The main lamps used to light the road ahead | 1312 | | | 1313 | interior | Interior lamp, often at the top center | 1314 | | | 1315 | fog-front | Front fog lamps | 1316 | | | 1317 | fog-rear | Rear fog lamps | 1318 | | | 1319 | brake | Brake indicator lamps | 1320 | | | 1321 | position-front | Front position/parking/standing lamps | 1322 | | | 1323 | position-rear | Rear position/parking/standing lamps | 1324 | | | 1325 | turn-left | Left turn/directional lamps | 1326 | | | 1327 | turn-right | Right turn/directional lamps | 1328 | | | 1329 | hazard | Hazard/four-way lamps | 1330 +----------------+---------------------------------------------+ 1332 Table 5: eCall Lamp ID Registry Initial Values 1334 14. Contributors 1336 Brian Rosen was a co-author of the original document upon which this 1337 document is based. 1339 15. Acknowledgements 1341 We would like to thank Bob Williams and Ban Al-Bakri for their 1342 feedback and suggestions, and Keith Drage for his review comments. 1343 We would like to thank Michael Montag, Arnoud van Wijk, Gunnar 1344 Hellstrom, and Ulrich Dietz for their help with the original document 1345 upon which this document is based. 1347 16. Changes from Previous Versions 1349 16.1. Changes from draft-ietf-01 to draft-ietf-02 1351 o Added clarifying text reinforcing that the data exchange is for 1352 small blocks of data infrequently transmitted 1353 o Clarified that dynamic media is conveyed using SIP re-INVITE to 1354 establish a one-way media stream 1355 o Clarified that the scope is the needs of eCall within the SIP 1356 emergency call environment 1357 o Added informative statement that the document may be suitable for 1358 reuse by other ACN systems 1359 o Clarified that normative language for the control block applies to 1360 both IVS and PSAP 1361 o Removed 'ref', 'supported-mime', and 'media' elements 1362 o Minor wording improvements and clarifications 1364 16.2. Changes from draft-ietf-00 to draft-ietf-01 1366 o Added further discussion of test calls 1367 o Added further clarification to the document scope 1368 o Mentioned that multi-region vehicles may need to support other 1369 crash notification specifications in addition to eCall 1370 o Added details of the eCall metadata and control functionality 1371 o Added IANA registration for the MIME content type for the eCall 1372 control object 1373 o Added IANA registries for protocol elements and tokens used in the 1374 eCall control object 1375 o Minor wording improvements and clarifications 1377 16.3. Changes from draft-gellens-03 to draft-ietf-00 1379 o Renamed from draft-gellens- to draft-ietf-. 1380 o Added mention of and reference to ETSI TR "Mobile Standards Group 1381 (MSG); eCall for VoIP" 1382 o Added text to Introduction regarding migration/co-existence being 1383 out of scope 1384 o Added mention in Security Considerations that even if the network- 1385 supplied location is just the cell site, this can be useful as a 1386 sanity check on the IVS-supplied location 1387 o Minor wording improvements and clarifications 1389 16.4. Changes from draft-gellens-02 to -03 1391 o Clarifications and editorial improvements. 1393 16.5. Changes from draft-gellens-01 to -02 1395 o Minor wording improvements 1396 o Removed ".automatic" and ".manual" from 1397 "urn:service:test.sos.ecall" registration and discussion text. 1399 16.6. Changes from draft-gellens-00 to -01 1401 o Now using 'EmergencyCallData' for purpose parameter values and 1402 MIME subtypes, in accordance with changes to 1403 [additional-data-draft] 1404 o Added reference to RFC 6443 1405 o Fixed bug that caused Figure captions to not appear 1407 17. References 1409 17.1. Normative References 1411 [EN_16072] 1412 CEN, , "Intelligent transport systems - eSafety - Pan- 1413 European eCall operating requirements", December 2011. 1415 [I-D.ietf-ecrit-additional-data] 1416 Randy, R., Rosen, B., Tschofenig, H., Marshall, R., and J. 1417 Winterbottom, "Additional Data related to an Emergency 1418 Call", draft-ietf-ecrit-additional-data-24 (work in 1419 progress), October 2014. 1421 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1422 Requirement Levels", BCP 14, RFC 2119, March 1997. 1424 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1425 January 2004. 1427 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 1428 Emergency and Other Well-Known Services", RFC 5031, 1429 January 2008. 1431 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1432 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1433 May 2008. 1435 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 1436 "Framework for Emergency Calling Using Internet 1437 Multimedia", RFC 6443, December 2011. 1439 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 1440 Specifications and Registration Procedures", BCP 13, RFC 1441 6838, January 2013. 1443 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 1444 Communications Services in Support of Emergency Calling", 1445 BCP 181, RFC 6881, March 2013. 1447 [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, 1448 July 2014. 1450 [TS22.101] 1451 3GPP, , "Technical Specification Group Services and System 1452 Aspects; Service aspects; Service principles", . 1454 [additional-data-draft] 1455 Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and 1456 J. Winterbottom, "Additional Data related to an Emergency 1457 Call", draft-ietf-ecrit-additional-data-11 (work in 1458 progress), July 2013. 1460 [msd] CEN, , "Intelligent transport systems -- eSafety -- eCall 1461 minimum set of data (MSD), EN 15722", June 2011. 1463 17.2. Informative references 1465 [CEN] "European Committee for Standardization", 1466 . 1468 [I-D.ietf-ecrit-trustworthy-location] 1469 Tschofenig, H., Schulzrinne, H., and B. Aboba, 1470 "Trustworthy Location", draft-ietf-ecrit-trustworthy- 1471 location-14 (work in progress), July 2014. 1473 [MSG_TR] ETSI, , "ETSI Mobile Standards Group (MSG); eCall for 1474 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 1475 April 2014. 1477 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 1478 Emergency Context Resolution with Internet Technologies", 1479 RFC 5012, January 2008. 1481 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 1482 Shanmugam, "Security Threats and Requirements for 1483 Emergency Call Marking and Mapping", RFC 5069, January 1484 2008. 1486 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 1487 Presence Information Data Format Location Object (PIDF-LO) 1488 Usage Clarification, Considerations, and Recommendations", 1489 RFC 5491, March 2009. 1491 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 1492 Initiation Protocol (SIP) INFO Method and Package 1493 Framework", RFC 6086, January 2011. 1495 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 1496 for the Session Initiation Protocol", RFC 6442, December 1497 2011. 1499 [RFC7090] Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 1500 Patel, "Public Safety Answering Point (PSAP) Callback", 1501 RFC 7090, April 2014. 1503 [SDO-3GPP] 1504 "3d Generation Partnership Project", 1505 . 1507 [SDO-ETSI] 1508 "European Telecommunications Standards Institute (ETSI)", 1509 . 1511 [draft-ietf-ecrit-car-crash] 1512 Gellens, R., Rosen, B., and H. Tschofenig, "Next- 1513 Generation Vehicle-Initiated Emergency Calls", draft-ietf- 1514 ecrit-car-crash (work in progress), March 2015. 1516 Authors' Addresses 1518 Randall Gellens 1519 Qualcomm Technologies, Inc. 1520 5775 Morehouse Drive 1521 San Diego 92651 1522 US 1524 Email: rg+ietf@qti.qualcomm.com 1525 Hannes Tschofenig 1526 (no affiliation) 1528 Email: Hannes.Tschofenig@gmx.net 1529 URI: http://www.tschofenig.priv.at