idnits 2.17.00 (12 Aug 2021) /tmp/idnits34153/draft-rosen-ecrit-ecall-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 21, 2013) is 3376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '7' is defined on line 277, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 280, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 283, but no explicit reference was found in the text == Outdated reference: draft-ietf-ecrit-phonebcp has been published as RFC 6881 == Outdated reference: draft-ietf-ecrit-additional-data has been published as RFC 7852 == Outdated reference: draft-ietf-ecrit-trustworthy-location has been published as RFC 7378 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT B. Rosen 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational H. Tschofenig 5 Expires: August 25, 2013 Nokia Siemens Networks 6 February 21, 2013 8 Internet Protocol-based In-Vehicle Emergency Call 9 draft-rosen-ecrit-ecall-07.txt 11 Abstract 13 This document describes how to use a subset of the IETF-based 14 emergency call framework for accomplishing emergency calling support 15 in vehicles. Simplifications are possible due to the nature of the 16 functionality that is going to be provided in vehicles with the usage 17 of GPS. Additionally, further profiling needs to be done regarding 18 the encoding of location information. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 25, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 60 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 64 9.2. Informative references . . . . . . . . . . . . . . . . . . 12 65 Appendix A. Matching Functionality with eCall Minimum Set of 66 Data (MSD) . . . . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 69 1. Introduction 71 Emergency calls made from vehicles can assist with the objective of 72 significantly reducing road deaths and injuries. Unfortunately, 73 drivers often have a poor location-awareness, especially on urban 74 roads (also during night) and abroad. In the most crucial cases, the 75 victim(s) may not be able to call because they have been injured or 76 trapped. 78 In Europe the European Commission has launched the eCall initiative 79 that may best be described as a user initiated or automatically 80 triggered system to provide notifications to Public Safety Answering 81 Point's (PSAP), by means of cellular communications, that a vehicle 82 has crashed, and to provide geodetic location information and where 83 possible a voice channel to the PSAP. At the time of writing the 84 suppor for eCall are focused on legacy technology. This document 85 details how emergency calls triggered by vehicles can be accomplished 86 in an Internet Protocol-based environment. 88 This document is organized as follows: Section 2 defines the 89 terminology, Section 3 describes how the required functionality can 90 be accomplished by combining several already existing standards, and 91 Section 4 shows an example message exchange. This document concludes 92 with the security considerations in Section 5 and IANA considerations 93 in Section 6. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [1]. 101 This document re-uses terminology defined in Section 3 of [10]. 103 3. Profile 105 In the context of emergncy calls placed from a vehicle it is assumed 106 that the car is equipped with a built-in GPS receiver. For this 107 reason only geodetic location information will be sent within an 108 emergency call. The following location shapes MUST be implemented: 109 2d and 3d Point (see Section 5.2.1 of [2]), Circle (see Section 5.2.3 110 of [2]), and Ellipsoid (see Section 5.2.7 of [2]). The coordinate 111 reference systems (CRS) specified in [2] are also mandatory for this 112 document. The element, as defined in [3] which indicates 113 the direction of travel of the vehicle, is important for dispatch and 114 hence it MUST be included in the PIDF-LO . The element 115 specified in [3] MUST be implemented and MAY be included. 117 This specification also inherits the test call functionality from 118 Section 15 of [4]. 120 4. Example 122 Figure 1 shows an emergency call placed from a vehicle whereby 123 location information information is directly attached to the SIP 124 INVITE message itself. The call is marked as an emergency call using 125 the 'urn:service:sos.ecall.automatic' service URN and the PSAP of the 126 VoIP provider determines which PSAP to contact based on the provided 127 location information. The emergency call continues towards the PSAP 128 and in this example it hits the ESRP, as the entry point to the PSAP 129 operators emergency services network. Finally, the emergency call 130 will be received by a call taker and first reponders will be 131 dispatched. 133 +--------+ 134 | LoST | 135 | Server | 136 +--------+ 137 ^ +-------+ 138 | | PSAP2 | 139 | +-------+ 140 v 141 +-------+ +------+ +-------+ 142 Vehicle ------>| Proxy |---->| ESRP |---->| PSAP1 |-----> Call-Taker 143 +-------+ +------+ +-------+ 145 +-------+ 146 | PSAP3 | 147 +-------+ 149 Figure 1: Example of In-Vehicular Emergency Call Message Flow 151 The example, shown in Figure 2, illustrates a SIP INVITE and location 152 information encoded in a PIDF-LO that is being conveyed in such an 153 emergency call. 155 INVITE urn:service:sos.ecall.automatic SIP/2.0 156 To: urn:service:sos.ecall.automatic 157 From: ;tag=9fxced76sl 158 Call-ID: 3848276298220188511@atlanta.example.com 159 Geolocation: 160 Geolocation-Routing: no 161 Accept: application/sdp, application/pidf+xml 162 CSeq: 31862 INVITE 163 Content-Type: multipart/mixed; boundary=boundary1 164 Content-Length: ... 166 --boundary1 168 Content-Type: application/sdp 170 ...Session Description Protocol (SDP) goes here 172 --boundary1 174 Content-Type: application/pidf+xml 175 Content-ID: 176 177 185 186 187 188 189 -34.407 150.883 190 191 192 278 193 194 195 196 197 gps 198 199 2012-04-5T10:18:29Z 200 1M8GDM9A_KP042788 201 202 203 --boundary1-- 205 Figure 2: SIP INVITE indicating an In-Vehicular Emergency Call 207 5. Security Considerations 209 This document does not raise security considerations beyond those 210 described in [11]. As with emergency service systems with end host 211 provided location information there is the possibility that that 212 location is incorrect, either intentially (in case of an a denial of 213 service attack against the emergency services infrastructure) or due 214 to a malfunctioning devices. The reader is referred to [12] for a 215 discussion of some of these vulnerabilities. 217 6. IANA Considerations 219 IANA is requested to register the URN 'urn:service:sos.ecall' under 220 the sub-services 'sos' registry defined in Section 4.2 of [5]. 222 This service identifier reaches a public safety answering point 223 (PSAP), which in turn dispatches aid appropriate to the emergency 224 related to accidents of vehicles. Two sub-services are registered as 225 well, namely 227 urn:service:sos.ecall.manual 229 This service URN indicates that an eCall had been triggered based 230 on the manual interaction of the driver or a passenger. 232 urn:service:sos.ecall.automatic 234 This service URN indicates that an eCall had been triggered 235 automatically, for example, due to a crash. No human involvement 236 was detected. 238 7. Contributors 240 We would like to thank Ulrich Dietz for his help with earlier 241 versions of the document. 243 8. Acknowledgements 245 We would like to thank Michael Montag, Arnoud van Wijk, Ban Al-Bakri, 246 and Gunnar Hellstroem for their feedback. 248 9. References 250 9.1. Normative References 252 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 253 Levels", BCP 14, RFC 2119, March 1997. 255 [2] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 256 Presence Information Data Format Location Object (PIDF-LO) 257 Usage Clarification, Considerations, and Recommendations", 258 RFC 5491, March 2009. 260 [3] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, 261 "Dynamic Extensions to the Presence Information Data Format 262 Location Object (PIDF-LO)", RFC 5962, September 2010. 264 [4] Rosen, B. and J. Polk, "Best Current Practice for 265 Communications Services in support of Emergency Calling", 266 draft-ietf-ecrit-phonebcp-20 (work in progress), 267 September 2011. 269 [5] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency 270 and Other Well-Known Services", RFC 5031, January 2008. 272 [6] Rosen, B., Tschofenig, H., Marshall, R., and R. Randy, 273 "Additional Data related to an Emergency Call", 274 draft-ietf-ecrit-additional-data-06 (work in progress), 275 February 2013. 277 [7] Peterson, J., "A Presence-based GEOPRIV Location Object 278 Format", RFC 4119, December 2005. 280 [8] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for 281 the Session Initiation Protocol", RFC 6442, December 2011. 283 [9] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 284 Preferences for the Session Initiation Protocol (SIP)", 285 RFC 3841, August 2004. 287 9.2. Informative references 289 [10] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 290 Context Resolution with Internet Technologies", RFC 5012, 291 January 2008. 293 [11] Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, 294 "Security Threats and Requirements for Emergency Call Marking 295 and Mapping", RFC 5069, January 2008. 297 [12] Tschofenig, H., Schulzrinne, H., and B. Aboba, "Trustworthy 298 Location", draft-ietf-ecrit-trustworthy-location-04 (work in 299 progress), October 2012. 301 [13] CEN, "Intelligent transport systems - eSafety - eCall minimum 302 set of data (MSD), EN 15722", June 2011. 304 [14] Schulzrinne, H., "Timed Presence Extensions to the Presence 305 Information Data Format (PIDF) to Indicate Status Information 306 for Past and Future Time Intervals", RFC 4481, July 2006. 308 Appendix A. Matching Functionality with eCall Minimum Set of Data (MSD) 310 [13] outlines a number of data elements that are transmitted in an 311 emergency call triggered by a vehicle. This list compares the eCall 312 minimum set of data with the functionality provided in this document. 314 Version of the MSD Format 316 Message Identifier: Every SIP INVITE message contains a Call-ID, 317 which is a globally unique identifier for this call. 319 Vehicle Type Encoding: [Editor's Note: Description to be added.]. 321 Test Call Indication A service URN starting with "test." indicates a 322 request for an automated test. For example, 323 "urn:service:test.sos.ecall.automatic" indicates such a test 324 feature. This functionality is defined in [4]. 326 Automatic Activation Indication: This document registers new service 327 URNs, which allow the differentiation between manually and 328 automatically triggered emergency calls. The two service URNs 329 are: urn:service:sos.ecall.automatic and 330 urn:service:sos.ecall.manual 332 Vehicle Identification: The PIDF data structure contains a deviceID 333 field that holds the Vehicle Identification Number (VIN). 335 Vehicle Propulsion Storage type: These parameters identify the type 336 of vehicle energy storage(s) present. [Editor's Note: 337 Description to be added.] 339 Timestamp of Incident Event: The PIDF-LO element contains the 340 timestamp when the PIDF-LO was created, which is at the time of 341 the incident. 343 Vehicle Location: The location of the vehicle is conveyed using the 344 PIDF location objection, as described in Section 3. 346 Vehicle Direction: The direction of the vehicle is part of location 347 information, as described in Section 3. 349 Recent Vehicle Location: With this optional functionality multiple 350 location objects may be required to be transported simultaneously. 351 This can be achieved using , defined in RFC 4481 352 [14]. 354 Number of Passengers: Minimum known number of fastened seatbelts. 355 [Editor's Note: Description to be added.] 357 Additional Data: [6] provides the ability to carry additional data 358 for an emergency call. 360 Authors' Addresses 362 Brian Rosen 363 NeuStar, Inc. 364 470 Conrad Dr 365 Mars, PA 16046 366 US 368 Phone: 369 Email: br@brianrosen.net 371 Hannes Tschofenig 372 Nokia Siemens Networks 373 Linnoitustie 6 374 Espoo 02600 375 Finland 377 Phone: +358 (50) 4871445 378 Email: Hannes.Tschofenig@gmx.net 379 URI: http://www.tschofenig.priv.at