idnits 2.17.00 (12 Aug 2021) /tmp/idnits59801/draft-ietf-ecrit-ecall-00.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 2 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 04, 2014) is 2877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4119' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC5491' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC5962' is defined on line 697, but no explicit reference was found in the text == Unused Reference: 'RFC6442' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'RFC4481' is defined on line 747, 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 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) == Outdated reference: draft-ietf-ecrit-psap-callback has been published as RFC 7090 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 3 errors (**), 0 flaws (~~), 9 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: January 5, 2015 (no affiliation) 6 July 04, 2014 8 Next-Generation Pan-European eCall 9 draft-ietf-ecrit-ecall-00.txt 11 Abstract 13 This document describes how to use IP-based emergency services 14 mechanisms to support the next generation of the Pan European in- 15 vehicle emergency call service defined under the eSafety initiative 16 of the European Commission (generally referred to as "eCall"). eCall 17 is a standardized and mandated system for a special form of emergency 18 calls placed by vehicles. eCall deployment is required by 2015 in 19 European Union member states, and eCall (and eCall-compatible 20 systems) are also being deployed in other regions. eCall provides an 21 integrated voice path and a standardized set of vehicle, sensor 22 (e.g., crash related), and location data. An eCall is recognized and 23 handled as a specialized form of emergency call and is routed to a 24 specialized eCall-capable Public Safety Answering Point (PSAP) 25 capable of processing the vehicle data and trained in handling 26 emergency calls from vehicles. 28 Currently, eCall functions over circuit-switched cellular telephony; 29 work on next-generation eCall (NG-eCall, sometimes called packet- 30 switched eCall or PS-eCall) is now in process, and this document 31 assists in that work by describing how to support eCall within the 32 IP-based emergency services infrastructure. 34 This document also registers a MIME Content Type and an Emergency 35 Call Additional Data Block for the eCall vehicle data. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 5, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 4. eCall Requirements . . . . . . . . . . . . . . . . . . . . . 5 75 5. Vehicle Data . . . . . . . . . . . . . . . . . . . . . . . . 6 76 6. Call Setup . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7. Call Routing . . . . . . . . . . . . . . . . . . . . . . . . 7 78 7.1. ESInets . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8. Test Calls . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 9. eCall-Specific Data from PSAP to IVS . . . . . . . . . . . . 8 81 10. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 12.1. Service URN Registration . . . . . . . . . . . . . . . . 12 85 12.2. MIME Content-type Registration for 86 'application/emergencyCallData.eCall.MSD+xml' . . . . . 12 87 12.3. Registration of the 'eCall.MSD' entry in the Emergency 88 Call Additional Data Blocks registry . . . . . . . . . . 13 89 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 90 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 91 15. Changes from Previous Versions . . . . . . . . . . . . . . . 14 92 15.1. Changes from draft-gellens-03 to draft-ietf-00 . . . . . 14 93 15.2. Changes from draft-gellens-02 to -03 . . . . . . . . . . 14 94 15.3. Changes from draft-gellens-01 to -02 . . . . . . . . . . 14 95 15.4. Changes from draft-gellens-00 to -01 . . . . . . . . . . 14 96 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 16.1. Normative References . . . . . . . . . . . . . . . . . . 15 98 16.2. Informative references . . . . . . . . . . . . . . . . . 16 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 101 1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 This document re-uses terminology defined in Section 3 of [RFC5012]. 109 Additionally, we use the following abbreviations: 111 3GPP: 3rd Generation Partnership Project 112 CEN: European Committee for Standardization 113 EENA: European Emergency Number Association 114 ESInet: Emergency Services IP network 115 IVS: In-Vehicle System 116 MNO: Mobile Network Operator 117 MSD: Minimum Set of Data 118 PSAP: Public Safety Answering Point 120 2. Document Scope 122 This document is limited to the signaling, data exchange, and 123 protocol needs of next-generation eCall (NG-eCall, also referred to 124 as packet-switched eCall (PS-eCall) and all-IP eCall). eCall itself 125 is specified by 3GPP and CEN and these specifications include far 126 greater scope than is covered here. 128 3. Introduction 130 Emergency calls made from vehicles (e.g., in the event of a crash) 131 assist in significantly reducing road deaths and injuries by allowing 132 emergency services to be aware of the incident, the state of the 133 vehicle, the location of the vehicle, and to have a voice channel 134 with the vehicle occupants. This enables a quick and appropriate 135 response. 137 The European Commission initiative of eCall was conceived in the late 138 1990s, and has evolved to a European Parliament decision requiring 139 the implementation of compliant in-vehicle systems (IVS) in new 140 vehicles and the deployment of eCall in the European Member States in 141 2015. eCall (and eCall-compatible systems) are also being adopted in 142 other regions. 144 The pan-European eCall system provides a standardized and mandated 145 mechanism for emergency calls by vehicles. eCall establishes 146 procedures for such calls to be placed by in-vehicle systems, 147 recognized and processed by the network, and routed to a specialized 148 PSAP where the vehicle data is available to assist the call taker in 149 assessing and responding to the situation. eCall provides a standard 150 set of vehicle, sensor (e.g., crash related), and location data. 152 An eCall may be either user-initiated or automatically triggered. 153 Automatically triggered eCalls indicate a car crash or some other 154 serious incident (e.g., a fire) and carry a greater presumption of 155 risk of injury. Manually triggered eCalls may be reports of serious 156 hazards and are likely to require a different response than an 157 automatically triggered eCall. Manually triggered eCalls are also 158 more likely to be false (e.g., accidental) calls and may thus be 159 subject to different handling by the PSAP. 161 Currently, eCall is standardized (by 3GPP [SDO-3GPP] and CEN [CEN]) 162 as a 3GPP circuit-switched call over GSM (2G) or UMTS (3G). An eCall 163 flag in the call setup marks the call as an eCall, and further 164 indicates if the call was automatically or manually triggered. The 165 call is routed to an eCall-capable PSAP, a voice channel is 166 established between the vehicle and the PSAP, and an eCall in-band 167 modem is used to carry a defined set of vehicle, sensor (e.g., crash 168 related), and location data (the Minimum Set of Data or MSD) within 169 the voice channel. The same in-band mechanism is used for the PSAP 170 to acknowledge successful receipt of the MSD, and optionally to 171 request the vehicle to send a new MSD (e.g., to check if the state of 172 or location of the vehicle or its occupants has changed). Work on 173 next-generation eCall (NG-eCall, also referred to as packet-switched 174 eCall or PS eCall) is now in process. As part of this work, the 175 European Telecommunications Standards Institute (ETSI) [SDO-ETSI] has 176 published a Technical Report titled "Mobile Standards Group (MSG); 177 eCall for VoIP" [MSG_TR] that presents findings and recommendations 178 regarding support for eCall in an all-IP environment. NG-eCall moves 179 from circuit switched to all-IP, and carries the vehicle data and 180 other eCall-specific data as additional data associated with the 181 call. This document describes how IETF mechanisms for IP-based 182 emergency calls, including [RFC6443] and [additional-data-draft] are 183 used to provide the signaling and data exchange of the next 184 generation of pan-European eCall. 186 A transition period will exist during which time the various entities 187 involved in initiating and handling an eCall might support next- 188 generation eCall, legacy eCall, or both. This transition period 189 might last several years or longer. The issue of migration/co- 190 existence during the transition period is very important but is 191 outside the scope of this document. The ETSI TR "Mobile Standards 192 Group (MSG); eCall for VoIP" [MSG_TR] discusses these issues in 193 Clause 7. 195 4. eCall Requirements 197 Overall eCall requirements are specified by by by CEN in [EN_16072] 198 and by 3GPP in [TS22.101] clauses 10.7 and A.27. Requirements 199 specific to vehicle data are contained in EN 15722 [msd]. For 200 convenience, the requirements most applicable to the limited scope of 201 this document are summarized very briefly below. 203 eCall requires: 205 o The call be recognized as an eCall (which is inherently an 206 emergency call) 207 o The call setup indicates if the call was manually or automatically 208 triggered 209 o A voice channel between the vehicle and the PSAP 210 o Carrying the MSD intrinsically with the call (the MSD needs to be 211 available to the same call-taker as the voice) 212 o The ability for the PSAP to acknowledge receipt of the MSD 213 o The ability for the PSAP to request that the vehicle generate and 214 transmit a new MSD 215 o The ability of the PSAP to be able to re-contact the occupants of 216 vehicle after the initial eCall is concluded 217 o The ability to perform a test call (which may be routed to a PSAP 218 but is not treated as an emergency call and not handled by a call 219 taker) 221 It is recognized that NG-eCall offers many potential enhancements, 222 although these are not required by current EU regulations. For 223 convenience, the enhancements most applicable to the limited scope of 224 this document are summarized very briefly below. 226 NG-eCall is expected to offer: 228 o The ability to carry more data (e.g., an enhanced MSD or an MSD 229 plus additional sets of data) 230 o The ability to handle video 231 o The ability to handle text 232 o The ability for the PSAP to access vehicle components (e.g., an 233 onboard camera (such as rear facing or blind-spot cameras) for a 234 visual assessment of the crash site situation) 235 o The ability for the PSAP to request the vehicle to take actions 236 (e.g., sound the horn, disable the ignition, lock/unlock doors) 237 o The ability to avoid audio muting of the voice channel (because 238 the MSD is not transferred using an in-band modem) 240 5. Vehicle Data 242 Pan-European eCall provides a standardized and mandated set of 243 vehicle related data, known as the Minimum Set of Data (MSD). The 244 European Committee for Standardization (CEN) has specified this data 245 in EN 15722 [msd], along with both ASN.1 and XML encodings for the 246 MSD [msd]. Circuit-switched eCall uses the ASN.1 encoding (due to 247 its more compact size). The XML encoding is better suited for use in 248 SIP messages and is used in this document. (The ASN.1 encoding is 249 specified in Annex A of EN 15722 [msd], while the XML encoding is 250 specified in Annex C.) 252 The "Additional Data related to an Emergency Call" document 253 [additional-data-draft] establishes a general mechanism for attaching 254 blocks of data to a SIP emergency call. This document makes use of 255 that mechanism to carry the eCall MSD in a SIP emergency call. 257 This document registers the 'application/ 258 emergencyCallData.eCall.MSD+xml') MIME Content-Type to enable the MSD 259 to be carried in SIP. This document also adds the 'eCall.MSD' entry 260 to the Emergency Call Additional Data Blocks registry (established by 261 [additional-data-draft]) to enable the MSD to be recognized as such 262 in a SIP-based eCall emergency call. 264 6. Call Setup 266 In circuit-switched eCall, the IVS places a special form of a 112 267 emergency call which carries the eCall flag (indicating that the call 268 is an eCall and also if the call was manually or automatically 269 triggered); the mobile network operator (MNO) recognizes the eCall 270 flag and routes the call to an eCall-capable PSAP; vehicle data is 271 transmitted to the PSAP via the eCall in-band modem (in the voice 272 channel). 274 ///----\\\ 112 voice call with eCall flag +------+ 275 ||| IVS |||---------------------------------------->+ PSAP | 276 \\\----/// vehicle data via eCall in-band modem +------+ 278 Figure 1: circuit-switched eCall 280 An In-Vehicle System (IVS) which supports NG-eCall transmits the MSD 281 in accordance with [additional-data-draft] by encoding it as 282 specified (per Appendix C of EN 15722 [msd]) and attaching it to an 283 INVITE as a MIME body part. The body part is identified by its MIME 284 content-type 'application/emergencyCallData.eCall.MSD+xml') in the 285 Content-Type header field of the body part. The body part is 286 assigned a unique identifier which is listed in a Content-ID header 287 field in the body part. The INVITE is marked as containing the MSD 288 by adding (or appending to) a Call-Info header field at the top level 289 of the INVITE. This Call-Info header field contains a CID URL 290 referencing the body part's unique identifier, and a 'purpose' 291 parameter identifying the data as the eCall MSD per the registry 292 entry; the 'purpose' parameter's value is 'emergencyCallData.' and 293 the root of the MIME type (not including the 'emergencyCallData' 294 prefix and any suffix such as '+xml' (e.g., 295 'purpose=emergencyCallData.eCall.MSD'). 297 For NG-eCall, the IVS establishes an emergency call using the 3GPP 298 IMS solution with a Request-URI indicating an eCall type of emergency 299 call and with vehicle data attached; the MNO or ESInet recognizes the 300 eCall URN and routes the call to a NG-eCall capable PSAP; the PSAP 301 interpets the vehicle data sent with the call and makes it available 302 to the call taker. 304 ///----\\\ IMS emergency call with eCall URN +------+ 305 IVS ----------------------------------------->+ PSAP | 306 \\\----/// vehicle data included in call setup +------+ 308 Figure 2: NG-eCall 310 This document registers new service URN children within the "sos" 311 subservice. These URNs provide the mechanism by which an eCall is 312 identified, and differentiate between manually and automatically 313 triggered eCalls (which may be subject to different treatment, 314 depending on policy). The two service URNs are: 315 urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual 317 7. Call Routing 319 The routing rules for eCalls are likely to differ from those of other 320 emergency calls because eCalls are special types of emergency calls 321 (with implications for the types of response required) and need to be 322 handled by specially designated PSAPs. In an environment that uses 323 ESInets, the originating network passes all types of emergency calls 324 to an ESInet (which have a request URI containing the "SOS" service 325 URN). The ESInet is then responsible for routing such calls to the 326 appropriate PSAP. In an environment without an ESInet, the emergency 327 services authorities and the originating network jointly determine 328 how such calls are routed. 330 7.1. ESInets 332 This section provides background information on ESInets for 333 information only. 335 An Emergency Services IP Network (ESInet) is a network operated by 336 emergency services authorities. It handles emergency call routing 337 and processing before delivery to a PSAP. In the NG1-1-2 338 architecture adopted by EENA, each PSAP is connected to one or more 339 ESInets. Each originating network is also connected to one or more 340 ESInets. The ESInets maintain policy-based routing rules which 341 control the routing and processing of emergency calls. The 342 centralization of such rules within ESInets provides for a cleaner 343 separation between the responsibilities of the originating network 344 and that of the emergency services network, and provides greater 345 flexibility and control over processing of emergency calls by the 346 emergency services authorities. This makes it easier to react 347 quickly to unusual situations that require changes in how emergency 348 calls are routed or handled (e.g., a natural disaster closes a PSAP), 349 as well as ease in making long-term changes that affect such routing 350 (e.g., cooperative agreements to specially handle calls requiring 351 translation or relay services). ESInets may support the ability to 352 interwork NG-eCall to legacy eCall to handle eCall-capable PSAPs that 353 are not IP PSAPs (similarly to the ability to interwork IP emergency 354 calls to legacy non-IP PSAPs). Note that in order to support legacy 355 eCall-capable PSAPs that are not IP PSAPs and are not attached to an 356 ESInet, an originating network may need the ability to route an eCall 357 itself (e.g., to an interworking facility with interconnection to a 358 suitable legacy eCall capable PSAP) based on the eCall and manual or 359 automatic indications. The ETSI TR "Mobile Standards Group (MSG); 360 eCall for VoIP" [MSG_TR] discusses transition issues in Clause 7. 362 8. Test Calls 364 eCall requires the ability to place test calls. These are calls that 365 are recognized and treated as eCalls but are not given emergency call 366 treatment and are not handled by call takers. 368 A service URN starting with "test." indicates a test call. For 369 eCall, "urn:service:test.sos.ecall" indicates such a test feature. 370 This functionality is defined in [RFC6881]. 372 This document registers "urn:service:test.sos.ecall" for eCall test 373 calls. 375 9. eCall-Specific Data from PSAP to IVS 376 eCall requires the ability for the PSAP to acknowledge successful 377 receipt of the MSD, and for the PSAP to optionally request that the 378 IVS send a new MSD (e.g., if the call taker wishes to see if the 379 vehicle's state or location has changed). Future enhancements are 380 desired, for example, to enable the PSAP to send other requests to 381 the vehicle, such as starting a video stream from on-board cameras 382 (such as rear focus or blind-spot), locking or unlocking doors, 383 sounding the horn, flashing the lights, etc. 385 The same mechanism established in [additional-data-draft], used in 386 this document to carry the MSD from the IVS to the PSAP, can be 387 additionally used to carry a control data block from the PSAP to the 388 IVS. This eCall control block (also referred to as eCall metadata) 389 is an XML structure containing eCall-specific elements. When the 390 PSAP needs to send an eCall control block that is in response to the 391 MSD or other data sent by the IVS in a SIP request, the control block 392 can be sent in the SIP response to the message that contained the MSD 393 or other data (e.g., the INVITE). When the PSAP needs to send an 394 eCall control block that is not an immediate response to an MSD or 395 other data sent by the IVS, the control block can be transmitted from 396 the PSAP to the IVS in a SIP INFO message within the established 397 session. The IVS can then send any requested data (such as a new 398 MSD) in the reply to the INFO message. This creates a framework 399 mechanism by which the PSAP can send eCall-specific data to the IVS 400 and the IVS can respond with data if requested. If control data sent 401 in a response message requests the IVS to send a new MSD or other 402 data block, the IVS can do so in an INFO message within the session 403 (it could also use re-INVITE but that is unnecessary when no aspect 404 of the session or media is changing). 406 This mechanism requires 408 o An XML definition of the eCall control object 409 o An extension mechanism by which new elements can be added to the 410 control object definition (which may be as simple as permitting 411 additional elements to be included by adding their namespace) 412 o A MIME type registration for the control object (so it can be 413 carried in SIP messages and responses) 414 o An entry in the Emergency Call Additional Data Blocks sub-registry 415 (established by [additional-data-draft]) so that the control block 416 can be recognized as emergency call specific data within the SIP 417 messages 418 o An Info-Package registration per [RFC6086] permitting the control 419 block within Info messages 421 10. Example 422 Figure 3 shows an eCall. The call uses the request URI 423 'urn:service:sos.ecall.automatic' service URN and is recognized as an 424 eCall, and further as one that was invoked automatically by the IVS 425 due to a crash or other serious incident. In this example, the 426 originating network routes the call to an ESInet (as for any 427 emergency call in an environment with an ESInet). The ESInet routes 428 the call to the appropriate NG-eCall capable PSAP. (In deployments 429 where there is no ESInet, the originating network routes the call 430 directly to the appropriate NG-eCall capable PSAP.) The emergency 431 call is received by the ESInet's Emergency Services Routing Proxy 432 (ESRP), as the entry point to the ESInet. The ESRP routes the call 433 to a PSAP, where it is received by a call taker. 435 +------------+ +-----------------------------------------+ 436 | | | | 437 | | | +-------+ | 438 | | | | PSAP2 | | 439 | | | +-------+ | 440 | | | | 441 | | | +------+ +-------+ | 442 Vehicle-->| |--+->| ESRP |---->| PSAP1 |---> Call-Taker | 443 | | | +------+ +-------+ | 444 | | | | 445 | | | +-------+ | 446 | | | | PSAP3 | | 447 | | | +-------+ | 448 | | | | 449 | Originating| | | 450 | Mobile | | | 451 | Network | | ESInet | 452 +------------+ +-----------------------------------------+ 454 Figure 3: Example of NG-eCall Message Flow 456 The example, shown in Figure 4, illustrates a SIP eCall INVITE that 457 contains an MSD. 459 INVITE urn:service:sos.ecall.automatic SIP/2.0 460 To: urn:service:sos.ecall.automatic 461 From: ;tag=9fxced76sl 462 Call-ID: 3848276298220188511@atlanta.example.com 463 Geolocation: 464 Geolocation-Routing: no 465 Call-Info: cid:1234567890@atlanta.example.com; 466 purpose=emergencyCallData.eCall.MSD 467 Accept: application/sdp, application/pidf+xml 468 CSeq: 31862 INVITE 469 Content-Type: multipart/mixed; boundary=boundary1 470 Content-Length: ... 472 --boundary1 474 Content-Type: application/sdp 476 ...Session Description Protocol (SDP) goes here 478 --boundary1 480 Content-Type: application/emergencyCallData.eCall.MSD+xml 481 Content-ID: 1234567890@atlanta.example.com 483 ...eCall MSD data object goes here 485 --boundary1-- 487 Figure 4: SIP NG-eCall INVITE 489 11. Security Considerations 491 The security considerations described in [RFC5069] apply here. 493 An eCall will carry two forms of location data: the network-provided 494 location that is inherently part of IMS emergency calls (which might 495 be determined solely by the network, or in cooperation with or 496 possibly entirely by the originating device), and the IVS-supplied 497 location within the MSD. This is likely to be useful to the PSAP, 498 especially when the two locations are independently determined. Even 499 in situations where the network-supplied location is limited to the 500 cell site, this can be useful as a sanity check on the device- 501 supplied location contained in the MSD. 503 The document [I-D.ietf-ecrit-trustworthy-location] discusses trust 504 issues regarding location provided by or determined in cooperation 505 with end devices. 507 The mechanism by which the PSAP sends acknowledgment and optional 508 requests to the vehicle requires authenticity considerations; when 509 the PSAP request is received within an established session initiated 510 by the vehicle as an eCall emergency call, there is a higher degree 511 of trust that the source is indeed a PSAP. If the PSAP request is 512 received in other situations, such as a call-back, the trust issues 513 in verifying that a call-back is indeed from a PSAP are more complex 514 (see the PSAP Callback document [I-D.ietf-ecrit-psap-callback]). 516 12. IANA Considerations 518 12.1. Service URN Registration 520 IANA is requested to register the URN 'urn:service:sos.ecall' under 521 the sub-services 'sos' registry defined in Section 4.2 of [RFC5031]. 523 This service identifies a type of emergency call (placed by a 524 specialized in-vehicle system and carrying standardized set of data 525 related to the vehicle and crash or incident, and is needed to direct 526 the call to a specialized public safety answering point (PSAP) with 527 technical and operational capabilities to handle such calls. Two 528 sub-services are registered as well, namely 530 urn:service:sos.ecall.manual 532 This service URN indicates that an eCall had been triggered based 533 on the manual interaction of the driver or a passenger. 535 urn:service:sos.ecall.automatic 537 This service URN indicates that an eCall had been triggered 538 automatically, for example, due to a crash or other serious 539 incident (e.g., fire). 541 IANA is also requested to register the URN 542 'urn:service:test.sos.ecall' under the sub-service 'test' registry 543 defined in Setcion 17.2 of [RFC6881]. 545 12.2. MIME Content-type Registration for 'application/ 546 emergencyCallData.eCall.MSD+xml' 548 This specification requests the registration of a new MIME type 549 according to the procedures of RFC 4288 [RFC4288] and guidelines in 550 RFC 3023 [RFC3023]. 552 MIME media type name: application 554 MIME subtype name: emergencyCallData.eCall.MSD+xml 556 Mandatory parameters: none 558 Optional parameters: charset 560 Indicates the character encoding of the XML content. 562 Encoding considerations: Uses XML, which can employ 8-bit 563 characters, depending on the character encoding used. See 564 Section 3.2 of RFC 3023 [RFC3023]. 566 Security considerations: This content type is designed to carry 567 vehicle and incident-related data during an emergency call. This 568 data contains personal information including vehicle VIN, 569 location, direction, etc. Appropriate precautions need to be 570 taken to limit unauthorized access, inappropriate disclosure to 571 third parties, and eavesdropping of this information. In general, 572 it is permissible for the data to be unprotected while briefly in 573 transit within the Mobile Network Operator (MNO); the MNO is 574 trusted to not permit the data to be accessed by third parties. 575 Sections 7 and Section 8 of [I-D.ietf-ecrit-additional-data] 576 contain more discussion. 578 Interoperability considerations: None 580 Published specification: Annex C of EN 15722 [msd] 582 Applications which use this media type: Pan-European eCall 583 compliant systems 585 Additional information: None 587 Magic Number: None 589 File Extension: .xml 591 Macintosh file type code: 'TEXT' 593 Person and email address for further information: Hannes 594 Tschofenig, Hannes.Tschofenig@gmx.net 596 Intended usage: LIMITED USE 598 Author: This specification was produced by the European Committee 599 For Standardization (CEN). For contact information, please see 600 . 602 Change controller: The European Committee For Standardization 603 (CEN) 605 12.3. Registration of the 'eCall.MSD' entry in the Emergency Call 606 Additional Data Blocks registry 608 This specification requests IANA to add the 'eCall.MSD' entry to the 609 Emergency Call Additional Data Blocks registry (established by 610 [additional-data-draft]), with a reference to this document. 612 13. Contributors 614 Brian Rosen was a co-author of the original document upon which this 615 document is based. 617 14. Acknowledgements 619 We would like to thank Bob Williams and Ban Al-Bakri for their 620 feedback and suggestions. We would like to thank Michael Montag, 621 Arnoud van Wijk, Gunnar Hellstrom, and Ulrich Dietz for their help 622 with the original document upon which this document is based. 624 15. Changes from Previous Versions 626 15.1. Changes from draft-gellens-03 to draft-ietf-00 628 o Renamed from draft-gellens- to draft-ietf-. 630 o Added mention of and reference to ETSI TR "Mobile Standards Group 631 (MSG); eCall for VoIP" 633 o Added text to Introduction regarding migration/co-existence being 634 out of scope 636 o Added mention in Security Considerations that even if the network- 637 supplied location is just the cell site, this can be useful as a 638 sanity check on the IVS-supplied location 640 o Minor wording improvements and clarifications 642 15.2. Changes from draft-gellens-02 to -03 644 o Clarifications and editorial improvements. 646 15.3. Changes from draft-gellens-01 to -02 648 o Minor wording improvements 650 o Removed ".automatic" and ".manual" from 651 "urn:service:test.sos.ecall" registration and discussion text. 653 15.4. Changes from draft-gellens-00 to -01 654 o Now using 'EmergencyCallData' for purpose parameter values and 655 MIME subtypes, in accordance with changes to 656 [additional-data-draft] 658 o Added reference to RFC 6443 660 o Fixed bug that caused Figure captions to not appear 662 16. References 664 16.1. Normative References 666 [EN_16072] 667 CEN, ., "Intelligent transport systems - eSafety - Pan- 668 European eCall operating requirements", December 2011. 670 [I-D.ietf-ecrit-additional-data] 671 Rosen, B., Tschofenig, H., Marshall, R., Randy, R., and J. 672 Winterbottom, "Additional Data related to an Emergency 673 Call", draft-ietf-ecrit-additional-data-15 (work in 674 progress), November 2013. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 680 Types", RFC 3023, January 2001. 682 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object 683 Format", RFC 4119, December 2005. 685 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 686 Registration Procedures", RFC 4288, December 2005. 688 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 689 Emergency and Other Well-Known Services", RFC 5031, 690 January 2008. 692 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 693 Presence Information Data Format Location Object (PIDF-LO) 694 Usage Clarification, Considerations, and Recommendations", 695 RFC 5491, March 2009. 697 [RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. 698 Thomson, "Dynamic Extensions to the Presence Information 699 Data Format Location Object (PIDF-LO)", RFC 5962, 700 September 2010. 702 [RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 703 for the Session Initiation Protocol", RFC 6442, December 704 2011. 706 [RFC6443] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, 707 "Framework for Emergency Calling Using Internet 708 Multimedia", RFC 6443, December 2011. 710 [RFC6881] Rosen, B. and J. Polk, "Best Current Practice for 711 Communications Services in Support of Emergency Calling", 712 BCP 181, RFC 6881, March 2013. 714 [TS22.101] 715 3GPP, ., "Technical Specification Group Services and 716 System Aspects; Service aspects; Service principles", . 718 [additional-data-draft] 719 Rosen, B., Tschofenig, H., Marshall, R., Gellens, R., and 720 J. Winterbottom, "Additional Data related to an Emergency 721 Call", draft-ietf-ecrit-additional-data-11 (work in 722 progress), July 2013. 724 [msd] CEN, ., "Intelligent transport systems - eSafety - eCall 725 minimum set of data (MSD), EN 15722", June 2011. 727 16.2. Informative references 729 [CEN] , "European Committee for Standardization", 730 . 732 [I-D.ietf-ecrit-psap-callback] 733 Schulzrinne, H., Tschofenig, H., Holmberg, C., and M. 734 Patel, "Public Safety Answering Point (PSAP) Callback", 735 draft-ietf-ecrit-psap-callback-13 (work in progress), 736 October 2013. 738 [I-D.ietf-ecrit-trustworthy-location] 739 Tschofenig, H., Schulzrinne, H., and B. Aboba, 740 "Trustworthy Location", draft-ietf-ecrit-trustworthy- 741 location-07 (work in progress), July 2013. 743 [MSG_TR] ETSI, ., "ETSI Mobile Standards Group (MSG); eCall for 744 VoIP", ETSI Technical Report TR 103 140 V1.1.1 (2014-04), 745 April 2014. 747 [RFC4481] Schulzrinne, H., "Timed Presence Extensions to the 748 Presence Information Data Format (PIDF) to Indicate Status 749 Information for Past and Future Time Intervals", RFC 4481, 750 July 2006. 752 [RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for 753 Emergency Context Resolution with Internet Technologies", 754 RFC 5012, January 2008. 756 [RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. 757 Shanmugam, "Security Threats and Requirements for 758 Emergency Call Marking and Mapping", RFC 5069, January 759 2008. 761 [RFC6086] Holmberg, C., Burger, E., and H. Kaplan, "Session 762 Initiation Protocol (SIP) INFO Method and Package 763 Framework", RFC 6086, January 2011. 765 [SDO-3GPP] 766 , "3d Generation Partnership Project", 767 . 769 [SDO-ETSI] 770 , "European Telecommunications Standards Institute 771 (ETSI)", . 773 Authors' Addresses 775 Randall Gellens 776 Qualcomm Technologies, Inc. 777 5775 Morehouse Drive 778 San Diego 92651 779 US 781 Email: rg+ietf@qti.qualcomm.com 783 Hannes Tschofenig 784 (no affiliation) 786 Email: Hannes.Tschofenig@gmx.net 787 URI: http://www.tschofenig.priv.at