idnits 2.17.1 draft-karagiannis-traffic-safety-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 19) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 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 (February 25, 2010) is 5171 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 3 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: August 25, 2010 J. Kenney 5 Toyota ITC 6 C. J. Bernardos 7 Universidad Carlos III de Madrid 8 F. Kargl 9 University of Twente 10 February 25, 2010 12 Traffic safety applications requirements 13 draft-karagiannis-traffic-safety-requirements-02.txt 15 Abstract 17 This document describes a number of communication performance 18 requirements that are imposed by traffic safety applications on a 19 network layer. These traffic safety applications and requirements 20 have been derived by the USA VSC (Vehicle Safety 21 Communications)and VSC-A (VSC-Applications) projects and by the 22 European Car to Car Communication Consortium (C2C-CC) and the ETSI TC 23 ITS standardization body. The goal of this document is to stimulate 24 the discussion on judging whether these performance requirements 25 could or could not be supported (currently and in the future) by IP 26 based network solutions. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on August 25, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Overview of VSC and VSC-A traffic safety applications . . . . 7 74 4. Overview of the European Car to Car Communication Consortium 75 traffic safety applications . . . . . . . . . . . . . . . . . 9 77 5. Overview of traffic safety communication performance 78 requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6. Discussion and conclusions . . . . . . . . . . . . . . . . . . 16 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 Vehicular networking can be considered as one of the most important 93 enabling technologies needed to support various types of traffic 94 applications, such as infotainment type of applications, traffic 95 efficiency & management and traffic safety applications. 97 Traffic safety applications are those that are primarily applied to 98 decrease the probability of traffic accidents and the loss of life of 99 the occupants of vehicles. Note that VSC and VSC-A projects focus on 100 vehicle-to-vehicle safety. Another project called CICAS-V 101 (Cooperative Intersection Collision Avoidance Systems - Violation) 102 discuss the traffic safety application over vehicle-to-infrastructure 103 communication. 105 Traffic efficiency & management applications are focusing on 106 improving the vehicle traffic flow, traffic coordination and traffic 107 assistance. Moreover, traffic efficiency & management applications 108 are focusing on providing updated local information, maps and in 109 general messages of relevance limited in space and/or time, which are 110 not specifically used to decrease the probability of traffic 111 accidents and/or the loss of life of the occupants of vehicles. 113 Infotainment types of applications are the applications that are 114 neither traffic safety applications nor traffic efficiency & 115 management applications. Such applications are supported by e.g., 116 media downloading use cases. This document describes a number of 117 communication performance requirements that are imposed by traffic 118 safety applications on a network layer. 119 These traffic safety applications and requirements have been derived 120 by: 121 o the USA VSC (Vehicle Safety Communications) and VSC-A (VSC- 122 Applications) projects. 123 O the European Car-to-Car Communication Consortium (C2C-CC) 124 [C2C-CC] and the ETSI TC ITS [ETSI TC ITS], with the additional 125 support of some EU funded research projects, such as SEVECOM 126 [SEVECOM], SAFESPOT [SAFESPOT], CVIS [CVIS]. PREDRIVE-C2x 127 [PREDRIVE-C2x], GEONET [GEONET]. 129 The USA Vehicle Safety Communications (VSC) consortium, see 130 [VSC], is supported among others by CAMP (Crash Avoidance Metrics 131 Partnership). CAMP is a partnership that has been formed in 1995 by 132 Ford Motor Company and General Motors Corporation. The objective of 133 CAMP is to accelerate the implementation of crash avoidance 134 countermeasures to improve traffic safety by investigating and 135 developing new technologies. VSC has been realized in two phases. 137 The first phase, denoted as VSC started in 2002 and ended in 2004. 138 The second phase started in 2006 and ends in 2009. VSC focused and 139 is focusing on traffic safety related applications. In 2006, The VSC 140 2 consortium in cooperation with USDOT initiated a three-year 141 collaborative effort in the area of wireless-based safety 142 applications under the Vehicle Safety Communications - Applications 143 (VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the 144 following members; Mercedes-Benz, Ford, General Motors, Honda & 145 Toyota. The main goal of this project is to develop and test 146 communications-based vehicle safety systems to determine whether 147 vehicle positioning in combination with the DSRC at 5.9 GHz can 148 improve the autonomous vehicle-based safety systems and/or enable new 149 communication-based safety applications. 151 The WAVE Short Message Protocol [IEEE 1609.3] was designed 152 specifically to offer a more efficient (smaller size) alternative to 153 TCP or UDP over IP, for 1-hop messages that require no routing. The 154 goal of this document is to stimulate the discussion on judging 155 whether these communication performance requirements could or could 156 not be (currently and in the future) supported by IP based network 157 solutions. 159 The European Car-to-Car Communication Consortium (C2C-CC) is 160 an industry consortium of car manufacturers and electronics suppliers 161 that focuses on the definition of an European standard for vehicular 162 communication protocols. 164 The European Telecommunications Standards Institute (ETSI) Technical 165 Committee (TC) Intelligent Transport Systems (ITS) was established in 166 October 2007 with the goal of developing and maintaining standards, 167 specifications and other deliverables to support the development and 168 the implementation of ITS service provision. It is foreseen that ETSI 169 ITS will be the reference standardization body of the future European 170 ITS standards, and actually the C2C-CC provides recommendations to 171 the ETSI TC ITS. 173 2. Terminology 175 The following terms are used in this document : 177 On Board Unit (OBU) 179 a processing and communication feature that is located in a 180 vehicle, which provides an application runtime environment, 181 positioning, security and communications functions and interfaces 182 to other vehicles including human machine interfaces. OBU is also 183 known as OBE (On-Board Equipment). 185 Road Side Unit (RSU) 187 equipment located along highways, at traffic intersections and 188 other type of locations where timely communications with vehicles 189 are needed. Each RSU includes DSRC radio, a positioning system 190 and a router to route packets back through the infrastructure 191 network. RSU is also know as RSE (Road Side Equipment) 193 vehicle-to-vehicle (v2v) 195 (same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic 196 communication mode in which data packets are exchanged between two 197 vehicles, either directly or traversing multiple vehicles, without 198 involving any node in the infrastructure. 200 vehicle-to-infrastructure 202 generic communication mode in which data packets sent by a vehicle 203 traverse a network infrastructure. 205 infrastructure-to-vehicle 207 generic communication mode in which data packets received by a 208 vehicle traverse a network infrastructure. 210 Host vehicle 212 a vehicle that at a certain moment in time uses the traffic safety 213 application. 215 Traffic safety application 217 application that is primarily applied to decrease the probability 218 of traffic accidents and the loss of life of the occupants of 219 vehicles. 221 Geographically-scoped broadcast (or geocast), see [C2C-CC_Manifesto] 223 forwarding mechanism that is used to transport data from a single 224 node to all nodes within a geographically target area. The scope 225 is defined by the geographic region. The geographic region is 226 determined by a geometric shape, such as circle and rectangle. 228 Geographical Unicast (or geounicast) see [C2C-CC_Manifesto] 230 Forwarding mechanism that is used for unidirectional data 231 transport from a single node (source) to a single node 232 (destination) by means of direct communication or by multiple hops 233 based on C2C Communication specific addresses that include node 234 identifier, geographical position, and time information. 236 Geographically-scoped anycast (or geoanycast), see [C2C-CC_Manifesto] 238 forwarding mechanism that transports data from a single node to 239 any of the nodes within a geographically area. Compared to 240 geographically-scoped broadcast, with geographically-scoped 241 anycast a packet is not forwarded inside of the geographic area 242 when the packet has reached the area. 244 3. Overview of VSC and VSC-A traffic safety applications 246 In VSC, see [VSC] 34 vehicle application scenarios have been 247 identified, evaluated and ranked. From this evaluation, a subset of 248 eight significant near- and mid-term traffic safety applications have 249 been selected: (1) cooperative forward collision warning, (2) curve 250 speed warning, (3) pre-crash sensing, (4) traffic signal violation 251 warning, (5) lane-change warning, (6) emergency electronic brake 252 light, (7) left turn assistant, (8) stop sign movement assistant. A 253 brief description of these applications is given below (for more 254 details, see [VSC]): 256 o Traffic signal violation warning: it informs and warns the driver 257 to stop at a legally prescribed location in the situation that the 258 traffic signal indicates a stop and it is estimated that the 259 driver will be in violation. 261 o Curve speed warning - Rollover Warning: aids the driver in 262 negotiating and choosing appropriate curve speeds. 264 o Emergency Electronic Brake Lights: it is used to inform vehicles 265 that a vehicle brakes hard. In particular in this situation a 266 warning message is sent to the vehicles moving behind the vehicle 267 that brakes hard. 269 o Pre-crash sensing: it prepares the driver for an unavoidable and 270 imminent collision. 272 o Cooperative Forward Collision Warning: aids the driver in 273 mitigating or avoiding collisions with the rear-end vehicles in 274 the forward path of travel through driver notification or warnings 275 of an unavoidable collision. 277 o Left Turn Assistant: it informs the driver about oncoming traffic 278 in order to assist him in making a left turn at a signalized 279 intersection without a phasing left turn arrow. 281 o Lane Change Warning: it warns the driver if an intended lane 282 change may cause a crash with a nearby moving vehicle. 284 o Stop Sign Movement Assistance: it warns the driver that the 285 vehicle is nearby an intersection, which will be passed after 286 having stopped at a stop sign. 288 In the VSC-A project an additional investigation has been performed, 289 on traffic safety applications that can be used in crash immitment 290 scenarios, see [VSC-A]. The following 7 traffic safety applications 291 have been selected for implementation in the VSC-A test bed. 293 o Emergency Electronic Brake Light: is a traffic safety application 294 that is the same as the Emergency Electronic Brake Light 295 application defined in the VSC project, see above. 297 o Forward Collision warning: is a traffic safety application that is 298 the same as the Cooperative Forward Collision Warning application 299 defined in the VSC project, see above. 301 o Intersection Movement Assist: is a traffic is intended to warn the 302 driver of a vehicle when it is not safe to enter an intersection 303 due to high collision probability with other vehicles. It is 304 similar to the Stop Sign Movement Assistance application defined 305 in the VSC project, see above. 307 o Blind Spot Warning & Lane Change Warning: it is similar to the 308 Lane Change Warning application defined in the VSC project, see 309 above. In the Blind Spot Warning application the driver of a host 310 vehicle is informed that another vehicle is moving in an adjacent 311 lane and that this vehicle is positioned in a blind spot zone of 312 the host vehicle. 314 o Do Not Pass Warning: this is an application that was not 315 investigated in the VSC project. It is intended to warn the 316 driver of a host vehicle during a passing maneuver attempt when a 317 slower vehicle, ahead and in the same lane, cannot be safely 318 passed using a passing zone which is occupied by vehicles with the 319 opposite direction of travel. 321 In addition, the application provides advisory information that is 322 intended to inform the driver of the host vehicle that the passing 323 zone is occupied when a passing maneuver is not being attempted. 325 o Control Loss Warning: this is an application that was not 326 investigated in the VSC project. It is intended to enable the 327 host vehicle to autonomously generate and broadcast a control- 328 loss event to surrounding vehicles. Upon receiving this 329 information the surrounding vehicle determines the relevance of 330 the event and provides a warning to the driver, if appropriate. 332 4. Overview of the European Car to Car Communication Consortium 333 traffic safety applications 335 The Car to Car Communication Consortium specified a number of traffic 336 safety use cases. The following three are considered as being the 337 main traffic safety use cases, see [C2C-CC_Manifesto]: 339 o Cooperative Forward Collision Warning: this use case tries to 340 provide assistance to the driver. Vehicles share information such 341 as position, speed and direction. This enables the prediction of 342 an imminent rear-end collision, by each vehicle monitoring the 343 behavior of its own driver and the information of neighboring 344 vehicles. If a potential risk is detected, the vehicle warns the 345 driver. This use case requires: the ability for all vehicles to 346 share Information with each other over a distance of about 20 to 347 200 meters, accurate relative positioning of the vehicles, trust 348 relationships among the vehicles and a reasonable market 349 penetration (at least 10%). 351 o Pre-Crash Sensing/Warning: this use case is similar to the 352 previous one, but in this case the collision is identified as 353 unavoidable, and then the involved vehicles exchange more precise 354 information to optimize the usage of actuators such as airbags, 355 seat belt pre-tensors, etc... 356 This use case requires basically the same abilities that the 357 previous one, restricting the needed communication range to 20 to 358 100 meters, and adding the requirement of a fast and reliable 359 connection between the involved cars. 361 o Hazardous Location V2V Notification: this use case is based on 362 the share of information that relates to dangerous locations on 363 the road, among vehicles, and also among vehicles and the road 364 infrastructure. On one hand, vehicles may detect the dangerous 365 locations from sensors in the vehicle or from events such as the 366 actuation of the ESP (Electronic Stability Program). 368 On the other hand, recipients of this information may use it to 369 properly configure active safety systems and/or warn the driver. 370 This use case requires: vehicles to trust other vehicles and 371 roadside units, reasonable market penetration, the ability of 372 vehicles to share information about a specific geographic 373 location over multiple-hops and the ability to validate 374 information propagated through multiple hops. 376 5. Overview of traffic safety communication performance requirements 378 5.1 VSC and VSCA Traffic safety communication performance requirements 380 The VSC consortium specified several performance communication 381 requirements derived from the traffic safety applications, see 382 Figure 1 and Figure 2 and [VSC]. The communication parameters used 383 in Figure 1 and Figure 2 where specified in [VSC]. These are: 385 o Type of Communication: considers the (1) source-destination of 386 the transmission (infrastructure-to-vehicle, vehicle-to- 387 infrastructure, vehicle-to-vehicle), (2) direction of the 388 transmission (one-way, two-way), and DSRC (IEEE 802.11p), see 389 [DSRC], [IEEE 802.11p], communication, (3) source-reception of 390 communication (point-to-point, point-to-multipoint). Note that 391 the protocol suite that is used in the VSC and VSC-A projects is 392 the WAVE protocol suite, which is composed by the combination of 393 IEEE 1609 protocol suite, see [IEEE 1609.1], [IEEE 1609.2], [IEEE 394 1609.3], [IEEE 1609.4] and the IEEE 802.11p. 396 o Transmission Mode: Describes whether the transmission is triggered 397 by an event (event-driven) or sent automatically at regular 398 intervals (periodic) 400 o Minimum Frequency: defines the minimum rate at which a 401 transmission should be repeated (e.g., 1 Hz). 403 o Allowable latency: defines the maximum duration of time allowable 404 between when information is available for transmission (by the 405 sender) and when it is received by the receiver (e.g., 100 msec). 407 o Data to be transmitted and/or received: describes the contents of 408 the communication (e.g., vehicle location, speed and heading). 409 Design considerations include whether or not vehicles make 410 periodic broadcasts to identify their position on the roadway and 411 how privacy is best maintained. 413 o Maximum required range of communications: defines the 414 communication distance between two units (e.g., two vehicles) that 415 is required to effectively support an application. 417 +---------------- +----------------+----------------------+--- ---+ 418 | | Commun. |.Trans. | Min. | 419 | | Type | Mode | Freq. | 420 | | | | (Hz) | 421 +-----------------+----------------+----------------------+-------+ 422 | Traffic Signal |* infrastructure| Periodic | ~10 | 423 | violation | -to-vehicle | | | 424 | warning |* one-way | | | 425 | |* point-to- | | | 426 | | -multipoint | | | 427 | | | | | 428 | Curve |* infrastructure| Periodic | ~1 | 429 | Speed warning | -to-vehicle | | | 430 | |* one-way | | | 431 | |* point-to- | | | 432 | | -multipoint | | | 433 | | | | | 434 | | | | | 435 | Emergency |* vehicle-to- | Event driven | ~10 | 436 | Electronic | -vehicle | | | 437 | Brake lights |* one-way | | | 438 | |* point-to- | | | 439 | | -multipoint | | | 440 | | | | | 441 | Pre-Crash |* vehicle-to- | Event driven | ~50 | 442 | Sensing | -vehicle | | | 443 | |* Two-way | | | 444 | |* Point-to-point| | | 445 | | | | | 446 | Cooperative |* vehicle-to- | Periodic | ~10 | 447 | Forward | -vehicle | | | 448 | Collision |* One-way | | | 449 | warning |* point-to- | | | 450 | | -multipoint | | | 451 | | | | | 452 | Left Turn |* vehicle-to- | Periodic | ~10 | 453 | Assistant | -infrastructure| | | 454 | | and | | | 455 | | infrastructure| | | 456 | | -to-vehicle | | | 457 | |* One-way | | | 458 | |* point-to- | | | 459 | | -multipoint | | | 460 | | | | | 461 | Lane change |* vehicle-to- | Periodic | ~10 | 462 | warning | -vehicle | | | 463 | |* One-way | | | 464 | |* point-to- | | | 465 | | -multipoint | | | 466 | | | | | 467 | Stop Sign |* vehicle-to- | Periodic | ~10 | 468 | Movement | -infrastructure| | | 469 | Assistance | and | | | 470 | | infrastructure| | | 471 | | -to-vehicle | | | 472 | |* One-way | | | 473 | |* point-to- | | | 474 | | -multipoint | | | 475 | | | | | 476 +-----------------+----------------+----------------------+-------+ 478 Figure 1: Preliminary application scenario communication requirements 479 (part A), from [VSC] 481 +---------------- +----------------+----------------------+--- ---+ 482 | | Latency |Data to be transmitted|Max. | 483 | | (msec) |and/or received |Req'd | 484 | | | |comm.. | 485 | | | |range | 486 | | | |(m) | 487 +-----------------+----------------+----------------------+-------+ 488 | Traffic Signal | ~100 |* traffic signal | ~250 | 489 | violation | | status | | 490 | warning | |* Timing | | 491 | | |* Directionality | | 492 | | |* position of the | | 493 | | | traffic signal | | 494 | | | stopping location | | 495 | | |* Whether condition | | 496 | | | (if available) | | 497 | | |* Road surface type | | 498 | | | | | 499 | Curve | ~1000 |* Curve location | ~200 | 500 | Speed warning | |* Curve speed limits | | 501 | | |* Curvature | | 502 | | |* Bank | | 503 | | |* Road surface type | | 504 | | | | | 505 | Emergency | ~100 |* Position | ~300 | 506 | Electronic | |* Heading | | 507 | Brake lights | |* Velocity | | 508 | | |* Deceleration | | 509 | | | | | 510 | Pre-Crash | ~20 |* Vehicle type | ~50 | 511 | Sensing | |* Position | | 512 | | |* Velocity | | 513 | | |* Acceleration | | 514 | | |* Heading | | 515 | | |* Yaw rate | | 516 | | | | | 517 | Cooperative | ~100 |* Position | ~150 | 518 | Forward | |* Velocity | | 519 | Collision | |* Acceleration | | 520 | warning | |* Heading | | 521 | | |* Yaw rate | | 522 | | | | | 523 | Left Turn | ~100 |* Traffic signal | ~300 | 524 | Assistant | | status | | 525 | | |* Timing | | 526 | | |* Directionality | | 527 | | |* Road shape and | | 528 | | | intersection | | 529 | | | information | | 530 | | |* Vehicle position | | 531 | | |* Velocity | | 532 | | |* Heading | | 533 | | | | | 534 | Lane change | ~100 |* Position | ~150 | 535 | warning | |* Heading | | 536 | | |* Velocity | | 537 | | |* Acceleration | | 538 | | |* Turn Signal status | | 539 | | | | | 540 | Stop Sign | ~100 |* Vehicle position | ~300 | 541 | Movement | |* Velocity | | 542 | Assistance | |* Heading | | 543 | | |* Warning | | 544 | | | | | 545 +---------------- +----------------+----------------------+--- ---+ 547 Figure 2: Preliminary application scenario communication requirements 548 (part B), from [VSC] 550 From these requirements, see also Section 4.6 of [VSC], the most 551 significant ones are: 553 o Message packet size: for all 8 scenarios, a message size of 200 to 554 500 bytes is needed. 556 o Maximum required range of communication: for all 8 scenarios, a 557 maximum required range of communication of 50 to 300 meters is 558 needed. 560 o During 7 of the 8 scenarios, one-way, point to multipoint 561 broadcast messages were used. 563 o During 1 of the 8 scenarios, Two-way, point to point messages 565 o During 6 or 7 of the 8 scenarios, the periodic transmission 566 mode is used. 568 o During 1 or 2 scenarios, Event-driven transmission mode is 569 used. 571 o During 6 of the 8 scenarios an allowable latency of 100 572 milliseconds is needed. 574 o During 1 of the 8 scenarios an allowable latency of 20 milliseconds 575 is needed. 577 o During 1 of the 8 scenarios an allowable latency of 1 second is 578 needed. 580 In addition to these communication performance requirements the VSC 581 project derived the network constraints, depicted in Figure 3, see 582 Appendix H of [VSC]. 584 +----------------------------------+----------------------+ 585 | Constraint type |.Constraint value | 586 +----------------------------------+----------------------+ 587 | Aggregate bandwidth | 6 Mb/s | 588 | | | 589 | Maximum received packets/sec | 4000 | 590 | | | 591 | Maximum allowable latency | 100 ms | 592 | | | 593 | Maximum network latency | 10 ms | 594 | | | 595 | Maximum packet size | 200 bytes | 596 +----------------------------------+----------------------+ 598 Figure 3: Network constraints, from appendix H of [VSC] 600 The VSC-A project, relaxed some of these network constraints. In 601 particular, the security related network constraints were derived, 602 see Figure 4 and [VSC-A_1609.2]. In addition to these network 603 security constraints, the VSC-A uses for the traffic safety 604 application Do Not Pass Warning, a Maximum required range of 605 communication, of 700 meters as a target. 607 +----------------------------------+----------------------+ 608 | Constraint type |.Constraint value | 609 +----------------------------------+----------------------+ 610 | Certificate size | < 300bytes | 611 | | | 612 | Authentication generations | 10 | 613 | per second | | 614 | | | 615 | Authentication verifications | 1000 | 616 | per second | | 617 | | | 618 | Time delay (authentication + | < 20ms | 619 | + verification) | | 620 | | | 621 | Over-air-bandwidth overhead | 1,810 bytes/s | 622 | introduced by security | | 623 | mechanisms (including | | 624 | certificates); certificates | | 625 | with each message | | 626 +----------------------------------+----------------------+ 628 Figure 4: Network security constraints, from [VSC-A_1609.2] 630 5.2 C2C-CC and ETSI TC ITS traffic safety communication performance 631 requirements 633 The performance requirements associated with the C2C-CC traffic 634 safety applications are listed in the [ETSITR102638] ETSI 635 specification. 636 These performance requirements are listed in Figures 5 and 6. 638 +---------------- +----------------+----------------------+--- ---+ 639 | | Commun. |.Trans. | Min. | 640 | | Type | Mode | Freq. | 641 | | | | (Hz) | 642 +-----------------+----------------+----------------------+-------+ 643 | Cooperative |* vehicle-to- | Periodic | ~10 | 644 | Forward | -vehicle | | | 645 | Collision |* Broadcast | | | 646 | warning |* Geocast | | | 647 | | | | | 648 | | | | | 649 | Pre-Crash |* vehicle-to- | Periodic | ~10 | 650 | Sensing | -vehicle | | | 651 | |* Unicast | | | 652 | |* | | | 653 | | | | | 654 | Hazardous |* vehicle-to- | Time limited | ~10 | 655 | location | -vehicle | Periodic | | 656 | notification |* Broadcast | | | 657 | |* Geocast | | | 658 | |* | | | 659 +-----------------+----------------+----------------------+-------+ 661 Figure 5: Preliminary application scenario communication requirements 662 (part A), from [ETSITR102638] 664 +---------------- +----------------+----------------------+--- ---+ 665 | | Latency |Data to be transmitted|Max. | 666 | | (msec) |and/or received |Req'd | 667 | | | |comm.. | 668 | | | |range | 669 | | | |(m) | 670 +-----------------+----------------+----------------------+-------+ 671 | Cooperative | ~100 |* Position | 20 to | 672 | Forward | |* Velocity | 200 | 673 | Collision | |* Acceleration | | 674 | warning | |* Heading | | 675 | | |* Yaw rate | | 676 | | | | | 677 | Pre-Crash | ~100 |* Vehicle type | 20 to | 678 | Sensing | |* Position | 100 | 679 | | |* Velocity | | 680 | | |* Acceleration | | 681 | | |* Heading | | 682 | | |* Yaw rate | | 683 | | | | | 684 | Hazardous | |* events and |300 to | 685 | location | |* characteristics | 20000 | 686 | notification | |* of road | | 687 +---------------- +----------------+----------------------+--- ---+ 689 Figure 6: Preliminary application scenario communication requirements 690 (part B), from [ETSITR102638] 692 6. Discussion and conclusions 694 This document described a number of communication performance 695 requirements that are imposed by traffic safety applications on a 696 network layer. 698 These traffic safety applications and requirements 699 have been derived by the USA VSC (Vehicle Safety 700 Communications)and VSC-A (VSC-Applications) projects and by the 701 European Car to Car Communication Consortium (C2C-CC) and the ETSI TC 702 ITS standardization body. The goal of this document is 703 to stimulate the discussion on judging whether these performance 704 requirements could or could not be supported (currently and in the 705 future) by IP based network solutions. 707 Comparing the traffic safety applications derived by European and by 708 USA projects and consortia the following conclusions can be derived: 710 o the traffic safety applications and the use cases derived by 711 European and USA projects and consortia are quite identical. 713 o the performance requirements derived by European and USA projects 714 and consortia are similar. The main difference between 715 the requirements derived by European projects and consortia and 716 the ones derived by USA projects and consortia is that the 717 European derived traffic safety applications consider multi-hop 718 communication, i.e., geocasting forwarding, while the USA derived 719 ones use only single hop broadcast solutions. The multi-hop 720 communication requires geocast related forwarding mechanisms, 721 such as: geographical unicast, geographically-scoped broadcast 722 (also referred to as geo-broadcast) and geographically-scoped 723 anycast (also known as geo-anycast). The C2C-CC currently assumes 724 that IP is not suitable for safety and traffic efficiency 725 applications (too much overhead, lack of geocast forwarding 726 features, etc.). There are however initiatives, like the GeoNet 727 project [GEONET] working on the design of mechanisms to integrate 728 IP on top of the C2C-CC architecture. 730 It is however important to note that according to the VSC-A project 731 the following points are important to be mentioned: 733 1. A general point is that the requirements of the target 734 applications are intended to be somewhat representative of the 735 expected requirements discussed in the VSC and VSC-A projects, 736 but over time it is expected that new application ideas to come 737 forward and the communication requirements may broaden as a 738 result. For example, most applications today are designed to 739 treat safety messages as self-contained such that the decision to 740 warn a driver can be made purely based on the contents of the 741 most recent message. In the future, we may see applications that 742 require correlation of data over multiple messages from a given 743 sender, or between multiple senders. 745 2. We now expect typical safety messages to be on the order of 300 746 to 400 bytes (including all layers of overhead), rather than the 747 200 bytes given as the upper limit cited in Appendix H of 748 [VSC].It is expected that the security overhead will be between 749 about 200 bytes and about 90 bytes, depending on whether a full 750 certificate or a hashed certificate digest is included (the full 751 certificate will be included at some reduced rate, probably 1 Hz 752 to 3 Hz). There is also some additional, sub-rate safety 753 information to communicate the sending vehicle's path history, 754 its predicted path, and some of its raw GPS data. The latter is 755 for purposes of computing precise relative positioning. 756 Furthermore, it is expected that in some congested-channel 757 scenarios we might expect to see more than 10 msec of network 758 latency. This is exacerbated under the current multi-channel 759 operation standard (IEEE 1609.4) [IEEE 1609.4], which calls for 760 time to be divided into 50 msec intervals, with switching between 761 a "control channel interval" and a "service channel interval", 762 and then back again. Safety messages are only sent during the 763 control channel interval. It is possible for a given message 764 that is enqueued in one control channel interval to have to wait 765 for the next one if it is still in backoff when the first 766 interval ends, thus incurring up to 50 more msec of latency. 768 That is highly undesirable however, and in any case we're hoping 769 to change the standards to avoid this channel-switching paradigm 770 for safety messages. 772 3. Furthermore, the requirement on "maximum allowable latency" is 773 difficult to be interpreted when the communication takes place 774 over an inherently unreliable medium. The fact is that the 775 applications built on DSRC (Dedicated Short Range Communications) 776 will have to be somewhat robust to lost broadcast messages. We 777 often talk about the delay between successfully delivered 778 messages, and it is expected that safety applications can 779 generally tolerate at least 300 msec of such delay (i.e. two 780 successive lost packets). 782 7. Security Considerations 784 As safety applications operate in dangerous situations, it is 785 generally accepted that secure operations of vehicular networks are 786 of paramount importance. Attackers must not be able to subvert 787 operation of applications, e.g. to trigger false warnings or easily 788 suppress real ones. Therefore, both US and European research 789 activities on vehicular networks have worked on security solutions 790 right from the start. 792 IEEE 1602.2 [IEEE 1609.2] provides an early solution taking into 793 account many requirements. The European SeVeCom project [SEVECOM] has 794 also published a design for a complete security subsystem for 795 vehicular networks [SEVECOM-D2.1,SEVECOM-D2.1-APPA]. Furthermore, the 796 PRECIOSA project is focusing dedicatedly on privacy-friendly design 797 of Intelligent Transportation Systems, including vehicular networks 798 [PRECIOSA]. 800 Analyzing security requirements in vehicular networks, one can refer 801 to classical security goals: confidentiality, integrity, and 802 availability. 804 Confidentiality: One can note that for all safety applications, 805 listed earlier, confidentiality is not a primary requirement. 806 Information contained in safety-related messages should be received 807 by all neighbors and can be considered public. So encryption of data 808 is not a primary concern. If so, one could analyze the applicability 809 of ESP headers for this purpose. However, note that there are privacy 810 requirements (see below). 812 Integrity: It is of great import to ensure correctness of 813 communicated data and to prevent attackers from sending forged or 814 modified messages that could trigger application warnings or other 815 reactions. One first step suggested by above mentioned solutions is 816 to establish an identity management system that uses digital 817 certificates and signatures by which receivers can verify that 818 messages have been sent by valid vehicles. These solutions are very 819 similar to AUTH headers of IPsec, however, size limitations suggest 820 to use suitable cryptosystems like ECDSA. Restricting communication 821 to valid vehicles is not sufficient, as those vehicles could still 822 send false information (e.g. wrong position data). Additional 823 mechanisms for data-consistency checking are proposed to detect and 824 discard such information. 826 Availability: protecting the vehicular network from all kind of 827 jamming and overloading attacks is important but beyond the scope of 828 this paper, as security mechanisms usually address physical and 829 datalink layer attacks. If multi-hop forwarding schemes like Geocast 830 are used, protection from Denial-of-Service attacks targeting the 831 network layer also need to be taken into consideration. Because of 832 the broadcast nature of vehicular communication, mechanisms to 833 protect e.g. from DDoS attacks in the Internet will likely be not 834 portable. 836 Beyond those security requirements, it is also important to protect 837 privacy of drivers. Foremost, it should be impossible to find the 838 location of a vehicle or track its itinerary based on recorded 839 vehicular communications. Solutions generally apply pseudonymous 840 identifiers to prevent a certain degree of unlinkability. 842 To prevent tracking vehicles, those identifiers need to be changed 843 regularly (e.g., in each minute). This creates additional challenges 844 to communication layers that can e.g. be addressed using 845 MobileIP/NEMO technologies. 847 As discussed in Section 5, vehicular networks create a very 848 challenging environment for a security system. Due to the broadcast 849 and periodic nature of communication, vehicles might have to send 850 some dozens of packets per second while at the same time receiving up 851 to a few thousand packets per second from neighboring nodes. This 852 corresponds to some dozens of signature generations per second and 853 some thousands of signature (plus certificate) verifications per 854 second. OBU hardware is not likely able to cope with this 855 cryptographic load, so usage of dedicated crypto-coprocessors is 856 likely. [SCHOCH-EFF-2010] outlines some other strategies to reduce 857 cryptographic load. 859 Cryptographic payload in messages (signatures, certificates, 860 metadata) must also not overload the communication medium. Based on 861 information from [REF 1602.2] security payload will increase packet 862 size by at least 181 bytes even when using space-efficient ECDSA. 863 Assuming message sizes of 200 bytes, this almost doubles the size of 864 a message. [SCHOCH-EFF-2010] also analyzes this and proposes 865 mitigation strategies. 867 Using standard IPsec techniques (ESP/AUTH headers and X.509 868 certificates) would aggravate this problem. However, work on space- 869 efficient IPsec variants, e.g. from the Wireless Sensor Network 870 domain, could be considered for adoption in IP-based vehicular 871 networks. 873 Overall, if one would adopt IP as a protocol for safety-related 874 messages in vehicular-networks, one would need to take into account 875 the issues raised above. This would require at least a modification 876 of IPsec plus introduction of additional security mechanisms like 877 pseudonymous identifiers and data-consistency checking. Note that for 878 communication with backend infrastructures via RSUs, IPsec can be 879 considered a mature solution to be applied. 881 8. IANA considerations 883 No IANA considerations apply to this document. 885 9. References 887 9.1. Normative References 889 9.2. Informative References 891 [C2C-CC] C2C-CC official website, http://www.car-2-car.org/, 892 (visited in October 2009). 894 [C2C-CC_MANIFESTO] Car to Car Communication Consortium, "Car to Car 895 Communication Consortium Manifesto: Overview of the C2C-CC System", 896 C2C-CC, version 1.1, 2007. 898 [CVIS] CVIS EU FP6 project website, http://www.cvisproject.org/, 899 (visited in October 2009). 901 [draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T, 902 Festag, A., Lenardi, M., "Automotive industry requirements for NEMO 903 Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02, 904 (Work in progress), 2009. 906 [ETSI TC ITS] ETSI official website, http://www.etsi.org/, (visited 907 in October 2009). 909 [ETSITR102638] ETSI TR 102 638, "Intelligent 910 Transport System (ITS); Vehicular Communications; Basic Set of 911 Applications; Definition, ETSI specification TR 102 638, v.1.0.5, 912 2009 914 [GEONET] GeoNet EU FP7 proj. website, http://www.geonet-project.eu/, 915 (visited in October 2009). 917 [IEEE 802.11p] IEEE P802.11p/D3.0, "Draft Amendment to Standard for 918 Information Technology-Telecommunications and Information Exchange 919 Between Systems-Local and Metropolitan Area Networks- Specific 920 requirements - Part 11: Wireless LAN Medium Access Control (MAC) and 921 Physical Layer (PHY) Specifications- Amendment 7: Wireless Access in 922 Vehicular Environment", 2007. 924 [IEEE 1609.1] IEEE P1609.1, "Trial-Use Standard for Wireless Access 925 in Vehicular Environments (WAVE) - Resource Manager", 2006. 927 [IEEE 1609.2] IEEE P1609.2, "Trial-Use Standard for Wireless Access 928 in Vehicular Environments (WAVE) Security Services for 929 Applications and Management Messages", 2006. 931 [IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless 932 Access in Vehicular Environments (WAVE) - Networking Services", 2007. 934 [IEEE 1609.4] IEEE P1609.4, "Trial-Use Standard for Wireless Access 935 in Vehicular Environments (WAVE) - Multi-Channel Operation", 936 2006 938 [DSRC] Dedicated Short Range Communications (DSRC), USA ITS Standards 939 advisory, http://www.standards.its.dot.gov/Documents/advisories/ 940 dsrc_advisory.htm 942 [PREDRIVE-C2x] Pre-Drive C2X EU FP7 project website, 943 http://www.pre-drive-c2x.eu/, (visited in October 2009). 945 [SAFESPOT] SAFESPOT EU FP6 project website, 946 http://www.safespot-eu.org/, (visited in October 2009). 948 [SEVECOM] SEVECOM EU FP6 project website, http://www.sevecom.org/, 949 (visited in October 2009). 951 [VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810 952 591, April 2006. 954 [VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project, 955 Final Annual Report, DOT HS 811 073, January 2009. 957 [VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides 958 presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found 959 via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/ 960 VSCA-1609_080827.pdf 962 [SEVECOM-D2.1] A. Kung (ed.), "Security Architecture and Mechanisms 963 for V2V / V2I", SeVeCom Deliverable 2.1 v3.0, February 2008. 965 [SEVECOM-D2.1-APPA] F. Kargl (ed.), "Baseline Security 966 Specification", SeVeCom Deliverable 2.1 Appendix A v1.2, April 2009. 968 [PRECIOSA] PRECIOSA EU FP7 project website, 969 http://www.preciosa-project.org/, (visited February 2010). 971 [SCHOCH-EFF-2010] E. Schoch, F. Kargl, "On the Efficiency of Secure 972 Beaconing in VANETs", ACM Conference on Wireless Security (WiSec 973 '10), 03/2010. 975 Authors' Addresses 977 Georgios Karagiannis 978 University of Twente 979 P.O. BOX 217 980 7500 AE Enschede 981 The Netherlands 983 Email: g.karagiannis@ewi.utwente.nl 985 Ryuji Wakikawa 986 TOYOTA InfoTechnology Center, U.S.A., Inc. 987 465 Bernardo Avenue 988 Mountain View, CA 94043 989 USA 991 Email: ryuji@jp.toyota-itc.com 993 John Kenney 994 TOYOTA InfoTechnology Center, U.S.A., Inc. 995 465 Bernardo Avenue 996 Mountain View, CA 94043 997 USA 999 Email: johnkenney@alumni.nd.edu 1001 Carlos Jesus Bernardos 1002 Universidad Carlos III de Madrid. 1003 Avda de la Universidad, 30 1004 E-28911 Leganes (Madrid) 1005 Spain 1007 Email: cjbc@it.uc3m.es 1009 Frank Kargl 1010 University of Twente 1011 P.O. BOX 217 1012 7500 AE Enschede 1013 The Netherlands 1015 Email: f.kargl@utwente.nl