idnits 2.17.1 draft-karagiannis-traffic-safety-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission G. Karagiannis 2 Internet-Draft University of Twente 3 Intended status: Informational R. Wakikawa 4 Expires: April 26, 2010 J. Kenney 5 Toyota ITC 6 C. J. Bernardos 7 Universidad Carlos III de Madrid 8 October 26, 2009 10 Traffic safety applications requirements 11 draft-karagiannis-traffic-safety-requirements-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 26, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes a number of communication performance 50 requirements that are imposed by traffic safety applications on a 51 network layer. These traffic safety applications and requirements 52 have been derived by the USA VSC (Vehicular Safety 53 Communications)and VSC-A (VSC-Applications) projects and by the 54 European Car to Car Communication Consortium (C2C-CC) and the ETSI TC 55 ITS standardization body. The goal of this document is to stimulate 56 the discussion on judging whether these performance requirements 57 could or could not be supported (currently and in the future) by IP 58 based network solutions. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Overview of VSC and VSC-A traffic safety applications . . . . 6 68 4. Overview of the European Car to Car Communication Consortium 69 traffic safety applications . . . . . . . . . . . . . . . . . 8 71 5. Overview of traffic safety communication performance 72 requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Discussion and conclusions . . . . . . . . . . . . . . . . . . 15 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 78 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 Vehicular networking can be considered as one of the most important 87 enabling technologies needed to support various types of traffic 88 applications, such as infotainment type of applications, traffic 89 efficiency & management and traffic safety applications. 91 Traffic safety applications are those that are primarily applied to 92 decrease the probability of traffic accidents and the loss of life of 93 the occupants of vehicles. Note that VSC and VSC-A projects focus on 94 vehicle-to-vehicle safety. Another project called CICAS-V 95 (Cooperative Intersection Collision Avoidance Systems - Violation) 96 discuss the traffic safety application over vehicle-to-infrastructure 97 communication. 99 Traffic efficiency & management applications are focusing on 100 improving the vehicle traffic flow, traffic coordination and traffic 101 assistance. Moreover, traffic efficiency & management applications 102 are focusing on providing updated local information, maps and in 103 general messages of relevance limited in space and/or time. 105 Infotainment types of applications are the applications that are 106 neither traffic safety applications nor traffic efficiency & 107 management applications. Such applications are supported by e.g., 108 media downloading use cases. This document describes a number of 109 communication performance requirements that are imposed by traffic 110 safety applications on a network layer. 111 These traffic safety applications and requirements have been derived 112 by: 113 o the USA VSC (Vehicular Safety Communications) and VSC-A (VSC- 114 Applications) projects. 115 O the European Car-to-Car Communication Consortium (C2C-CC) 116 [C2C-CC] and the ETSI TC ITS [ETSI TC ITS], with the additional 117 support of some EU funded research projects, such as SEVECOM 118 [SEVECOM], SAFESPOT [SAFESPOT], CVIS [CVIS]. PREDRIVE-C2x 119 [PREDRIVE-C2x], GEONET [GEONET]. 121 The USA Vehicle Safety Communications (VSC) consortium, see 122 [VSC], is supported among others by CAMP (Crash Avoidance Metrics 123 Partnership). CAMP is a partnership that has been formed in 1995 by 124 Ford Motor Company and General Motors Corporation. The objective of 125 CAMP is to accelerate the implementation of crash avoidance 126 countermeasures to improve traffic safety by investigating and 127 developing new technologies. VSC has been realized in two phases. 129 The first phase, denoted as VSC started in 2002 and ended in 2004. 130 The second phase started in 2006 and ends in 2009. VSC focused and 131 is focusing on traffic safety related applications. In 2006, The VSC 132 2 consortium in cooperation with USDOT initiated a three-year 133 collaborative effort in the area of wireless-based safety 134 applications under the Vehicle Safety Communications - Applications 135 (VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the 136 following members; Mercedes-Benz, Ford, General Motors, Honda & 137 Toyota. The main goal of this project is to develop and test 138 communications-based vehicle safety systems to determine whether 139 vehicle positioning in combination with the DSRC at 5.9 GHz can 140 improve the autonomous vehicle-based safety systems and/or enable new 141 communication-based safety applications. 143 The WAVE Short Message Protocol [IEEE 1609.3] was designed 144 specifically to offer a more efficient (smaller size) alternative to 145 TCP or UDP over IP, for 1-hop messages that require no routing. The 146 goal of this document is to stimulate the discussion on judging 147 whether these communication performance requirements could or could 148 not be (currently and in the future) supported by IP based network 149 solutions. 151 The European Car-to-Car Communication Consortium (C2C-CC) is 152 an industry consortium of car manufacturers and electronics suppliers 153 that focuses on the definition of an European standard for vehicular 154 communication protocols. 156 The European Telecommunications Standards Institute (ETSI) Technical 157 Committee (TC) Intelligent Transport Systems (ITS) was established in 158 October 2007 with the goal of developing and maintaining standards, 159 specifications and other deliverables to support the development and 160 the implementation of ITS service provision. It is foreseen that ETSI 161 ITS will be the reference standardization body of the future European 162 ITS standards, and actually the C2C-CC provides recommendations to 163 the ETSI TC ITS. 165 2. Terminology 167 The following terms are used in this document : 169 On Board Unit (OBU) 171 a processing and communication feature that is located in a 172 vehicle, which provides an application runtime environment, 173 positioning, security and communications functions and interfaces 174 to other vehicles including human machine interfaces. OBU is also 175 known as OBE (On-Board Equipment). 177 Road Side Unit (RSU) 179 equipment located along highways, at traffic intersections and 180 other type of locations where timely communications with vehicles 181 are needed. Each RSU includes DSRC radio, a positioning system 182 and a router to route packets back through the infrastructure 183 network. RSU is also know as RSE (Road Side Equipment) 185 vehicle-to-vehicle (v2v) 187 (same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic 188 communication mode in which data packets are exchanged between two 189 vehicles, either directly or traversing multiple vehicles, without 190 involving any node in the infrastructure. 192 vehicle-to-infrastructure 194 generic communication mode in which data packets sent by a vehicle 195 traverse a network infrastructure. 197 infrastructure-to-vehicle 199 generic communication mode in which data packets received by a 200 vehicle traverse a network infrastructure. 202 Host vehicle 204 a vehicle that at a certain moment in time uses the traffic safety 205 application. 207 Traffic safety application 209 application that is primarily applied to decrease the probability 210 of traffic accidents and the loss of life of the occupants of 211 vehicles. 213 Geographically-scoped broadcast (or geocast), see [C2C-CC_Manifesto] 215 forwarding mechanism that is used to transport data from a single 216 node to all nodes within a geographically target area. The scope 217 is defined by the geographic region. The geographic region is 218 determined by a geometric shape, such as circle and rectangle. 220 Geographical Unicast (or geounicast) see [C2C-CC_Manifesto] 222 Forwarding mechanism that is used for unidirectional data 223 transport from a single node (source) to a single node 224 (destination) by means of direct communication or by multiple hops 225 based on C2C Communication specific addresses that include node 226 identifier, geographical position, and time information. 228 Geographically-scoped anycast (or geoanycast), see [C2C-CC_Manifesto] 230 forwarding mechanism that transports data from a single node to 231 any of the nodes within a geographically area. Compared to 232 geographically-scoped broadcast, with geographically-scoped 233 anycast a packet is not forwarded inside of the geographic area 234 when the packet has reached the area. 236 3. Overview of VSC and VSC-A traffic safety applications 238 In VSC, see [VSC] 34 vehicle application scenarios have been 239 identified, evaluated and ranked. From this evaluation, a subset of 240 eight significant near- and mid-term traffic safety applications have 241 been selected: (1) cooperative forward collision warning, (2) curve 242 speed warning, (3) pre-crash sensing, (4) traffic signal violation 243 warning, (5) lane-change warning, (6) emergency electronic brake 244 light, (7) left turn assistant, (8) stop sign movement assistant. A 245 brief description of these applications is given below (for more 246 details, see [VSC]): 248 o Traffic signal violation warning: it informs and warns the driver 249 to stop at a legally prescribed location in the situation that the 250 traffic signal indicates a stop and it is estimated that the 251 driver will be in violation. 253 o Curve speed warning - Rollover Warning: aids the driver in 254 negotiating speeds at appropriate speeds. 256 o Emergency Electronic Brake Lights: it is used to inform vehicles 257 that a vehicle brakes hard. In particular in this situation a 258 warning message is sent to the vehicles moving behind the vehicle 259 that brakes hard. 261 o Pre-crash sensing: it prepares the driver for an unavoidable and 262 imminent collision. 264 o Cooperative Forward Collision Warning: aids the driver in 265 mitigating or avoiding collisions with the rear-end vehicles in 266 the forward path of travel through driver notification or warnings 267 of an unavoidable collision. This application does not attempt to 268 control the vehicle to avoid an unavoidable collision. 270 o Left Turn Assistant: it informs the driver about oncoming traffic 271 in order to assist him in making a left turn at a signalized 272 intersection without a phasing left turn arrow. 274 o Lane Change Warning: it warns the driver if an intended lane 275 change may cause a crash with a nearby moving vehicle. 277 o Stop Sign Movement Assistance: it warns the driver that the 278 vehicle is nearby an intersection, which will be passed after 279 having stopped at a stop sign. 281 In the VSC-A project an additional investigation has been performed, 282 on traffic safety applications that can be used in crash immitment 283 scenarios, see [VSC-A]. The following 7 traffic safety applications 284 have been selected for implementation in the VSC-A test bed. 286 o Emergency Electronic Brake Light: is a traffic safety application 287 that is the same as the Emergency Electronic Brake Light 288 application defined in the VSC project, see above. 290 o Forward Collision warning: is a traffic safety application that is 291 the same as the Cooperative Forward Collision Warning application 292 defined in the VSC project, see above. 294 o Intersection Movement Assist: is a traffic is intended to warn the 295 driver of a vehicle when it is not safe to enter an intersection 296 due to high collision probability with other vehicles. It is 297 similar to the Stop Sign Movement Assistance application defined 298 in the VSC project, see above. 300 o Blind Spot Warning & Lane Change Warning: it is similar to the 301 Lane Change Warning application defined in the VSC project, see 302 above. In the Blind Spot Warning application the driver of a host 303 vehicle is informed that another vehicle is moving in an adjacent 304 lane and that this vehicle is positioned in a blind spot zone of 305 the host vehicle. 307 o Do Not Pass Warning: this is an application that was not 308 investigated in the VSC project. It is intended to warn the 309 driver of a host vehicle during a passing maneuver attempt when a 310 slower vehicle, ahead and in the same lane, cannot be safely 311 passed using a passing zone which is occupied by vehicles with the 312 opposite direction of travel. 314 In addition, the application provides advisory information that is 315 intended to inform the driver of the host vehicle that the passing 316 zone is occupied when a passing maneuver is not being attempted. 318 o Control Loss Warning: this is an application that was not 319 investigated in the VSC project. It is intended to enable the 320 driver of a host vehicle to generate and broadcast a control- loss 321 event to surrounding vehicles. Upon receiving this information 322 the surrounding vehicle determines the relevance of the event and 323 provides a warning to the driver, if appropriate. 325 4. Overview of the European Car to Car Communication Consortium 326 traffic safety applications 328 The Car to Car Communication Consortium specified a number of traffic 329 safety use cases. The following three are considered as being the 330 main traffic safety use cases, see [C2C-CC_Manifesto]: 332 o Cooperative Forward Collision Warning: this use case tries to 333 provide assistance to the driver. Vehicles share (anonymously) 334 information such as position, speed and direction. This enables 335 the prediction of an imminent rear-end collision, by each vehicle 336 monitoring the behavior of its own driver and the information of 337 neighboring vehicles. If a potential risk is detected, the 338 vehicle warns the driver. 339 This use case requires: the ability for all vehicles to share 340 Information with each other over a distance of about 20 to 200 341 meters, accurate relative positioning of the vehicles, trust 342 relationships among the vehicles and a reasonable market 343 penetration (at least 10%). 345 o Pre-Crash Sensing/Warning: this use case is similar to the 346 previous one, but in this case the collision is identified as 347 unavoidable, and then the involved vehicles exchange more precise 348 information to optimize the usage of actuators such as airbags, 349 seat belt pre-tensors, etc... 350 This use case requires basically the same abilities that the 351 previous one, restricting the needed communication range to 20 to 352 100 meters, and adding the requirement of a fast and reliable 353 connection between the involved cars. 355 o Hazardous Location V2V Notification: this use case is based on 356 the share of information that relates to dangerous locations on 357 the road, among vehicles, and also among vehicles and the road 358 infrastructure. On one hand, vehicles may detect the dangerous 359 locations from sensors in the vehicle or from events such as the 360 actuation of the ESP (Electronic Stability Program). 362 On the other hand, recipients of this information may use it to 363 properly configure active safety systems and/or warn the driver. 364 This use case requires: vehicles to trust other vehicles and 365 roadside units, reasonable market penetration, the ability of 366 vehicles to share information about a specific geographic 367 location over multiple-hops and the ability to validate 368 information propagated through multiple hops. 370 5. Overview of traffic safety communication performance requirements 372 5.1 VSC and VSCA Traffic safety communication performance requirements 374 The VSC consortium specified several performance communication 375 requirements derived from the traffic safety applications, see 376 Figure 1 and Figure 2 and [VSC]. The communication parameters used 377 in Figure 1 and Figure 2 where specified in [VSC]. These are: 379 o Type of Communication: considers, the (1) source-destination of 380 the transmission (infrastructure-to-vehicle, vehicle-to- 381 infrastructure, vehicle-to-vehicle), (2) direction of the 382 transmission (one-way, two-way), and DSRC (IEEE 802.11p), see 383 [DSRC], [IEEE 802.11p], communication, (3) source-reception of 384 communication (point-to-point, point-to-multipooint). Note that 385 the protocol suite that is used in the VSC and VSC-A projects is 386 the WAVE protocol suite, which is composed by the combination of 387 IEEE 1609 protocol suite, see [IEEE 1609.1], [IEEE 1609.2], [IEEE 388 1609.3], [IEEE 1609.4] and the IEEE 802.11p. 390 o Transmission Mode: Describes whether the transmission is triggered 391 by an event (event-driven) or sent automatically at regular 392 intervals (periodic) 394 o Minimum Frequency: defines the minimum rate at which a 395 transmission should be repeated (e.g., 1 Hz). 397 o Allowable latency: defines the maximum duration of time allowable 398 between when information is available for transmission (by the 399 sender) and when it is received by the receiver (e.g., 100 msec). 401 o Data to be transmitted and/or received: describes the contents of 402 the communication (e.g., vehicle location, speed and heading). 403 Design considerations include whether or not vehicles make 404 periodic broadcasts to identify their position on the roadway and 405 how privacy is best maintained. 407 o Maximum required range of communications: defines the 408 communication distance between two units (e.g., two vehicles) that 409 is required to effectively support an application. 411 +---------------- +----------------+----------------------+--- ---+ 412 | | Commun. |.Trans. | Min. | 413 | | Type | Mode | Freq. | 414 | | | | (Hz) | 415 +-----------------+----------------+----------------------+-------+ 416 | Traffic Signal |* infrastructure| Periodic | ~10 | 417 | violation | -to-vehicle | | | 418 | warning |* one-way | | | 419 | |* point-to- | | | 420 | | -multipoint | | | 421 | | | | | 422 | Curve |* infrastructure| Periodic | ~1 | 423 | Speed warning | -to-vehicle | | | 424 | |* one-way | | | 425 | |* point-to- | | | 426 | | -multipoint | | | 427 | | | | | 428 | | | | | 429 | Emergency |* vehicle-to- | Event driven | ~10 | 430 | Electronic | -vehicle | | | 431 | Brake lights |* one-way | | | 432 | |* point-to- | | | 433 | | -multipoint | | | 434 | | | | | 435 | Pre-Crash |* vehicle-to- | Event driven | ~50 | 436 | Sensing | -vehicle | | | 437 | |* Two-way | | | 438 | |* Point-to-point| | | 439 | | | | | 440 | Cooperative |* vehicle-to- | Periodic | ~10 | 441 | Forward | -vehicle | | | 442 | Collision |* One-way | | | 443 | warning |* point-to- | | | 444 | | -multipoint | | | 445 | | | | | 446 | Left Turn |* vehicle-to- | Periodic | ~10 | 447 | Assistant | -infrastructure| | | 448 | | and | | | 449 | | infrastructure| | | 450 | | -to-vehicle | | | 451 | |* One-way | | | 452 | |* point-to- | | | 453 | | -multipoint | | | 454 | | | | | 455 | Lane change |* vehicle-to- | Periodic | ~10 | 456 | warning | -vehicle | | | 457 | |* One-way | | | 458 | |* point-to- | | | 459 | | -multipoint | | | 460 | | | | | 461 | Stop Sign |* vehicle-to- | Periodic | ~10 | 462 | Movement | -infrastructure| | | 463 | Assistance | and | | | 464 | | infrastructure| | | 465 | | -to-vehicle | | | 466 | |* One-way | | | 467 | |* point-to- | | | 468 | | -multipoint | | | 469 | | | | | 470 +-----------------+----------------+----------------------+-------+ 472 Figure 1: Preliminary application scenario communication requirements 473 (part A), from [VSC] 475 +---------------- +----------------+----------------------+--- ---+ 476 | | Latency |Data to be transmitted|Max. | 477 | | (msec) |and/or received |Req'd | 478 | | | |comm.. | 479 | | | |range | 480 | | | |(m) | 481 +-----------------+----------------+----------------------+-------+ 482 | Traffic Signal | ~100 |* traffic signal | ~250 | 483 | violation | | status | | 484 | warning | |* Timing | | 485 | | |* Directionality | | 486 | | |* position of the | | 487 | | | traffic signal | | 488 | | | stopping location | | 489 | | |* Whether condition | | 490 | | | (if available) | | 491 | | |* Road surface type | | 492 | | | | | 493 | Curve | ~1000 |* Curve location | ~200 | 494 | Speed warning | |* Curve speed limits | | 495 | | |* Curvature | | 496 | | |* Bank | | 497 | | |* Road surface type | | 498 | | | | | 499 | Emergency | ~100 |* Position | ~300 | 500 | Electronic | |* Heading | | 501 | Brake lights | |* Velocity | | 502 | | |* Deceleration | | 503 | | | | | 504 | Pre-Crash | ~20 |* Vehicle type | ~50 | 505 | Sensing | |* Position | | 506 | | |* Velocity | | 507 | | |* Acceleration | | 508 | | |* Heading | | 509 | | |* Yaw rate | | 510 | | | | | 511 | Cooperative | ~100 |* Position | ~150 | 512 | Forward | |* Velocity | | 513 | Collision | |* Acceleration | | 514 | warning | |* Heading | | 515 | | |* Yaw rate | | 516 | | | | | 517 | Left Turn | ~100 |* Traffic signal | ~300 | 518 | Assistant | | status | | 519 | | |* Timing | | 520 | | |* Directionality | | 521 | | |* Road shape and | | 522 | | | intersection | | 523 | | | information | | 524 | | |* Vehicle position | | 525 | | |* Velocity | | 526 | | |* Heading | | 527 | | | | | 528 | Lane change | ~100 |* Position | ~150 | 529 | warning | |* Heading | | 530 | | |* Velocity | | 531 | | |* Acceleration | | 532 | | |* Turn Signal status | | 533 | | | | | 534 | Stop Sign | ~100 |* Vehicle position | ~300 | 535 | Movement | |* Velocity | | 536 | Assistance | |* Heading | | 537 | | |* Warning | | 538 | | | | | 539 +---------------- +----------------+----------------------+--- ---+ 541 Figure 2: Preliminary application scenario communication requirements 542 (part B), from [VSC] 544 From these requirements, the most significant ones are: 546 o Message packet size: for all 8 scenarios, a message size of 200 to 547 500 bytes is needed. 549 o Maximum required range of communication: for all 8 scenarios, a 550 maximum required range of communication of 50 to 300 meters is 551 needed. 553 o During the 7 of the 8 scenarios, one-way, point to multipoint 554 broadcast messages were used. 556 o During the 1 of the 8 scenarios, Two-way, point to point messages 558 o During the 6 or 7 of the 8 scenarios, the periodic transmission 559 mode is used. 561 o During the 1 or 2 scenarios, Event-driven transmission mode is 562 used. 564 o During 6 of the 8 scenarios an allowable latency of 100 565 milliseconds is needed. 567 o During 1 of the 8 scenarios an allowable latency of 20 milliseconds 568 is needed. 570 o During 1 of the 8 scenarios an allowable latency of 1 second is 571 needed. 573 In addition to these communication performance requirements the VSC 574 project derived the network constraints, depicted in Figure 3, see 575 Appendix H of [VSC]. 577 +----------------------------------+----------------------+ 578 | Constraint type |.Constraint value. | 579 +----------------------------------+----------------------+ 580 | Aggregate bandwidth | 6 Mb/s | 581 | | | 582 | Maximum received packets/sec | 4000 | 583 | | | 584 | Maximum allowable latency | 100 ms | 585 | | | 586 | Maximum network latency | 10 ms | 587 | | | 588 | Maximum packet size | 200 bytes | 589 +----------------------------------+----------------------+ 591 Figure 3: Network constraints, from appendix H of [VSC] 593 The VSC-A project, relaxed some of these network constraints. In 594 particular, the security related network constraints were derived, 595 see Figure 4 and [VSC-A_1609.2]. In addition to these network 596 security constraints, the VSC-A uses for the traffic safety 597 application Do Not Pass Warning, a Maximum required range of 598 communication, of 700 meters as a target. 600 +----------------------------------+----------------------+ 601 | Constraint type |.Constraint value. | 602 +----------------------------------+----------------------+ 603 | Certificate size | < 300bytes | 604 | | | 605 | Authentication generations | 10 | 606 | per second | | 607 | | | 608 | Authentication verifications | 1000 | 609 | per second | | 610 | | | 611 | Time delay (authentication + | < 20ms | 612 | + verification) | | 613 | | | 614 | Over-air-bandwidth overhead | 1,810 bytes/s | 615 | introduced by security | | 616 | mechanisms (including | | 617 | certificates); certificates | | 618 | with each message | | 619 +----------------------------------+----------------------+ 621 Figure 4: Network security constraints, from [VSC-A_1609.2] 623 5.2 C2C-CC and ETSI TC ITS traffic safety communication performance 624 requirements 626 The performance requirements associated with the C2C-CC traffic 627 safety applications are listed in the [ETSITR102638] ETSI 628 specification. 629 These performance requirements are listed in Figures 5 and 6. 631 +---------------- +----------------+----------------------+--- ---+ 632 | | Commun. |.Trans. | Min. | 633 | | Type | Mode | Freq. | 634 | | | | (Hz) | 635 +-----------------+----------------+----------------------+-------+ 636 | Cooperative |* vehicle-to- | Periodic | ~10 | 637 | Forward | -vehicle | | | 638 | Collision |* Broadcast | | | 639 | warning |* Geocast | | | 640 | | | | | 641 | | | | | 642 | Pre-Crash |* vehicle-to- | Periodic | ~10 | 643 | Sensing | -vehicle | | | 644 | |* Unicast | | | 645 | |* | | | 646 | | | | | 647 | Hazardous |* vehicle-to- | Time limited | ~10 | 648 | location | -vehicle | Periodic | | 649 | notification |* Broadcast | | | 650 | |* Geocast | | | 651 | |* | | | 652 +-----------------+----------------+----------------------+-------+ 654 Figure 5: Preliminary application scenario communication requirements 655 (part A), from [ETSITR102638] 657 +---------------- +----------------+----------------------+--- ---+ 658 | | Latency |Data to be transmitted|Max. | 659 | | (msec) |and/or received |Req'd | 660 | | | |comm.. | 661 | | | |range | 662 | | | |(m) | 663 +-----------------+----------------+----------------------+-------+ 664 | Cooperative | ~100 |* Position | 20 to | 665 | Forward | |* Velocity | 200 | 666 | Collision | |* Acceleration | | 667 | warning | |* Heading | | 668 | | |* Yaw rate | | 669 | | | | | 670 | Pre-Crash | ~100 |* Vehicle type | 20 to | 671 | Sensing | |* Position | 100 | 672 | | |* Velocity | | 673 | | |* Acceleration | | 674 | | |* Heading | | 675 | | |* Yaw rate | | 676 | | | | | 677 | Hazardous | |* events and |300 to | 678 | location | |* characteristics | 20000 | 679 | notification | |* of road | | 680 +---------------- +----------------+----------------------+--- ---+ 682 Figure 6: Preliminary application scenario communication requirements 683 (part B), from [ETSITR102638] 685 6. Discussion and conclusions 687 This document described a number of communication performance 688 requirements that are imposed by traffic safety applications on a 689 network layer. 691 These traffic safety applications and requirements 692 have been derived by the USA VSC (Vehicular Safety 693 Communications)and VSC-A (VSC-Applications) projects and by the 694 European Car to Car Communication Consortium (C2C-CC) and the ETSI TC 695 ITS standardization body. The goal of this document is 696 to stimulate the discussion on judging whether these performance 697 requirements could or could not be supported (currently and in the 698 future) by IP based network solutions. 700 Comparing the traffic safety applications derived by European and by 701 USA projects and consortia the following conclusions can be derived: 703 o the traffic safety applications and the use cases derived by 704 European and USA projects and consortia are quite identical. 706 o the performance requirements derived by European and USA projects 707 and consortia are similar. The main difference between 708 the requirements derived by European projects and consortia and 709 the ones derived by USA projects and consortia is that the 710 European derived traffic safety applications consider multi-hop 711 communication, i.e., geocasting forwarding, while the USA derived 712 ones use only single hop broadcast solutions. The multi-hop 713 communication requires geocast related forwarding mechanisms, 714 such as: geographical unicast, geographically-scoped broadcast 715 (also referred to as geo-broadcast) and geographically-scoped 716 anycast (also known as geo-anycast). The C2C-CC currently assumes 717 that IP is not suitable for safety and traffic efficiency 718 applications (too much overhead, lack of geocast forwarding 719 features, etc.). There are however initiatives, like the GeoNet 720 project [GEONET] working on the design of mechanisms to integrate 721 IP on top of the C2C-CC architecture. 723 It is however important to note that according to the VSC-A project 724 the following points are important to be mentioned: 726 1. A general point is that the requirements of the target 727 applications are intended to be somewhat representative of the 728 expected requirements discussed in the VSC and VSC-A projects, 729 but over time it is expected that new application ideas to come 730 forward and the communication requirements may broaden as a 731 result. For example, most applications today are designed to 732 treat safety messages as self-contained such that the decision to 733 warn a driver can be made purely based on the contents of the 734 most recent message. In the future, we may see applications that 735 require correlation of data over multiple messages from a given 736 sender, or between multiple senders. 738 2. We now expect typical safety messages to be on the order of 300 739 to 400 bytes (including all layers of overhead), rather than the 740 200 bytes given as the upper limit cited in Appendix H of 741 [VSC].It is expected that the security overhead will be between 742 about 200 bytes and about 90 bytes, depending on whether a full 743 certificate or a hashed certificate digest is included (the full 744 certificate will be included at some reduced rate, probably 1 Hz 745 to 3 Hz). There is also some additional, sub-rate safety 746 information to communicate the sending vehicle's path history, 747 its predicted path, and some of its raw GPS data. The latter is 748 for purposes of computing precise relative positioning. 749 Furthermore, it is expected that in some congested-channel 750 scenarios we might expect to see more than 10 msec of network 751 latency. This is exacerbated under the current multi-channel 752 operation standard (IEEE 1609.4) [IEEE 1609.4], which calls for 753 time to be divided into 50 msec intervals, with switching between 754 a "control channel interval" and a "service channel interval", 755 and then back again. Safety messages are only sent during the 756 control channel interval. It is possible for a given message 757 that is enqueued in one control channel interval to have to wait 758 for the next one if it is still in backoff when the first 759 interval ends, thus incurring up to 50 more msec of latency. 761 That is highly undesirable however, and in any case we're hoping 762 to change the standards to avoid this channel-switching paradigm 763 for safety messages. 765 3. Furthermore, the requirement on "maximum allowable latency" is 766 difficult to be interpreted when the communication takes place 767 over an inherently unreliable medium. The fact is that the 768 applications built on DSRC (Dedicated Short Range Communications) 769 will have to be somewhat robust to lost broadcast messages. We 770 often talk about the delay between successfully delivered 771 messages, and it is expected that safety applications can 772 generally tolerate at least 300 msec of such delay (i.e. two 773 successive lost packets). 775 7. Security Considerations 777 Security is a critical issue in vehicular networks. If IP networking 778 solutions will be used to support vehicular traffic safety 779 applications then the impact on the security considerations have to 780 be analyzed. 782 8. IANA considerations 784 No IANA considerations apply to this document. 786 9. References 788 9.1. Normative References 790 9.2. Informative References 792 [C2C-CC] C2C-CC official website, http://www.car-2-car.org/, 793 (visited in October 2009). 795 [C2C-CC_MANIFESTO] Car to Car Communication Consortium, "Car to Car 796 Communication Consortium Manifesto: Overview of the C2C-CC System", 797 C2C-CC, version 1.1, 2007. 799 [CVIS] CVIS EU FP6 project website, http://www.cvisproject.org, 800 (visited in October 2009). 802 [draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T, 803 Festag, A., Lenardi, M., "Automotive industry requirements for NEMO 804 Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02, 805 (Work in progress), 2009. 807 [ETSI TC ITS] ETSI official website, http://www.etsi.org/, (visited 808 in October 2009). 810 [ETSITR102638] ETSI TR 102 638, "Intelligent 811 Transport System (ITS); Vehicular Communications; Basic Set of 812 Applications; Definition, ETSI specification TR 102 638, v.1.0.5, 813 2009 815 [GEONET] GeoNet EU FP7 project website, http://www.geonet-project.eu, 816 (visited in October 2009). 818 [IEEE 802.11p] IEEE P802.11p/D3.0, "Draft Amendment to Standard for 819 Information Technology-Telecommunications and Information Exchange 820 Between Systems-Local and Metropolitan Area Networks- Specific 821 requirements - Part 11: Wireless LAN Medium Access Control (MAC) and 822 Physical Layer (PHY) Specifications- Amendment 7: Wireless Access in 823 Vehicular Environment", 2007. 825 [IEEE 1609.1] IEEE P1609.1, "Trial-Use Standard for Wireless Access 826 in Vehicular Environments (WAVE) - Resource Manager", 2006. 828 [IEEE 1609.2] IEEE P1609.2, "Trial-Use Standard for Wireless Access 829 in Vehicular Environments (WAVE) ― Security Services for 830 Applications and Management Messages", 2006. 832 [IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless 833 Access in Vehicular Environments (WAVE)-Networking Services", 2007. 835 [IEEE 1609.4] IEEE P1609.4, "Trial-Use Standard for Wireless Access 836 in Vehicular Environments (WAVE) ― Multi-Channel Operation", 837 2006 839 [DSRC] Dedicated Short Range Communications (DSRC), USA ITS Standards 840 advisory, http://www.standards.its.dot.gov/Documents/advisories/ 841 dsrc_advisory.htm 843 [PREDRIVE-C2x] Pre-Drive C2X EU FP7 project website, 844 http://www.pre-drive-c2x.eu, (visited in October 2009). 846 [SAFESPOT] SAFESPOT EU FP6 project website, 847 http://www.safespot-eu.org, (visited in October 2009). 849 [SEVECOM] SEVECOM EU FP6 project website, http://www.sevecom.org, 850 (visited in October 2009). 852 [VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810 853 591, April 2006. 855 [VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project, 856 Final Annual Report, DOT HS 811 073, January 2009. 858 [VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides 859 presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found 860 via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/ 861 VSCA-1609_080827.pdf 863 Authors' Addresses 865 Georgios Karagiannis 866 University of Twente 867 P.O. BOX 217 868 7500 AE Enschede 869 The Netherlands 871 Email: g.karagiannis@ewi.utwente.nl 872 Ryuji Wakikawa 873 TOYOTA InfoTechnology Center, U.S.A., Inc. 874 465 Bernardo Avenue 875 Mountain View, CA 94043 876 USA 878 Email: ryuji@jp.toyota-itc.com 880 John Kenney 881 TOYOTA InfoTechnology Center, U.S.A., Inc. 882 465 Bernardo Avenue 883 Mountain View, CA 94043 884 USA 886 Email: johnkenney@alumni.nd.edu 888 Carlos Jesus Bernardos 889 Universidad Carlos III de Madrid. 890 Avda de la Universidad, 30 891 E-28911 Leganes (Madrid) 892 Spain 894 Email: cjbc@it.uc3m.es