idnits 2.17.1 draft-karagiannis-traffic-safety-requirements-00.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 6, 2009) is 5400 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'VSC' on line 631 looks like a reference -- Missing reference section? 'VSC-A' on line 634 looks like a reference -- Missing reference section? 'DSRC' on line 627 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Karagiannis 3 Internet-Draft University of Twente 4 Intended status: Informational R. Wakikawa 5 Expires: January 7, 2010 J. Kenney 6 Toyota ITC 7 July 6, 2009 9 Traffic safety applications requirements 10 draft-karagiannis-traffic-safety-requirements-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document describes a number of communication performance 49 requirements that are imposed by traffic safety applications on a 50 network layer. These traffic safety applications and requirements 51 have been derived during the VSC (Vehicular Safety Communications) 52 and VSC-A (VSC-Applications) projects. The goal of this document is 53 to stimulate the discussion on judging whether these performance 54 requirements could or could not be supported (currently and in the 55 future) by IP based network solutions. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Overview of VSC and VSC-A traffic safety applications . . . . 6 65 4. Overview of traffic safety communication performance 66 requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Discussion and conclusions . . . . . . . . . . . . . . . . . . 14 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 74 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 17 75 A.1. Normative References . . . . . . . . . . . . . . . . . . . 17 76 A.2. Informative References . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 Vehicular networking can be considered as one of the most important 83 enabling technologies needed to support various types of traffic 84 applications, such as infotainment type of applications, traffic 85 efficiency & management and traffic safety applications. 87 Traffic safety applications are those that are primarily applied to 88 decrease the probability of traffic accidents and the loss of life of 89 the occupants of vehicles. Note that VSC and VSC-A projects focus on 90 vehicle-to-vehicle safety. Another project called CICAS-V 91 (Cooperative Intersection Collision Avoidance Systems - Violation) 92 discuss the traffic safety application over vehicle-to-infrastracture 93 communication. 95 Traffic efficiency & management applications are focusing on 96 improving the vehicle traffic flow, traffic coordination and traffic 97 assistance. Moreover, traffic efficiency & management applications 98 are focusing on providing updated local information, maps and in 99 general messages of relevance limited in space and/or time. 101 Infotainment types of applications are the applications that are 102 neither traffic safety applications nor traffic efficiency & 103 management applications. Such applications are supported by e.g., 104 media downloading use cases. This document describes a number of 105 communication performance requirements that are imposed by traffic 106 safety applications on a network layer. These traffic safety 107 applications and requirements have been derived during the VSC 108 (Vehicular Safety Communications) and VSC-A (VSC-Applications) 109 projects. The Vehicle Safety Communications (VSC) consortium, see 110 [VSC], is supported among others by CAMP (Crash Avoidance Metrics 111 Partnership). CAMP is a partnership that has been formed in 1995 by 112 Ford Motor Company and General Motors Corporation. The objective of 113 CAMP is to accelerate the implementation of crash avoidance 114 countermeasures to improve traffic safety by investigating and 115 developing new technologies. VSC has been realized in two phases. 116 The first phase, denoted as VSC started in 2002 and ended in 2004. 117 The second phase started in 2006 and ends in 2009. VSC focused and 118 is focusing on traffic safety related applications. In 2006, The VSC 119 2 consortium in cooperation with USDOT initiated a three-year 120 collaborative effort in the area of wireless-based safety 121 applications under the Vehicle Safety Communications - Applications 122 (VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the 123 following members; Mercedes-Benz, Ford, General Motors, Honda & 124 Toyota. The main goal of this project is to develop and test 125 communications-based vehicle safety systems to determine whether 126 vehicle positioning in combination with the DSRC at 5.9 GHz can 127 improve the autonomous vehicle-based safety systems and/or enable new 128 communication-based safety applications. 130 The WAVE Short Message Protocol [IEEE 1609.3] was designed 131 specifically to offer a more efficient (smaller size) alternative to 132 TCP or UDP over IP, for 1-hop messages that require no routing. The 133 goal of this document is to stimulate the discussion on judging 134 whether these communication performance requirements could or could 135 not be (currently and in the future) supported by IP based network 136 solutions. 138 2. Terminology 140 The following terms are used in this document : 142 On Board Unit (OBU) 144 a processing and communication feature that is located in a 145 vehicle, which provides an application runtime environment, 146 positioning, security and communications functions and interfaces 147 to other vehicles including human machine interfaces. OBU is also 148 known as OBE (On-Board Equipment). 150 Road Side Unit (RSU) 152 equipment located along highways, at traffic intersections and 153 other type of locations where timely communications with vehicles 154 are needed. Each RSE includes DSRC radio, a positioning system 155 and a router to route packets back through the infrastructure 156 network. RSU is also know as RSE (Road Side Equipment) 158 vehicle-to-vehicle (v2v) 160 (same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic 161 communication mode in which data packets are exchanged between two 162 vehicles, either directly or traversing multiple vehicles, without 163 involving any node in the infrastructure. 165 vehicle-to-infrastructure 167 generic communication mode in which data packets sent by a vehicle 168 traverse a network infrastructure. 170 infrastructure-to-vehicle 172 generic communication mode in which data packets received by a 173 vehicle traverse a network infrastructure. 175 Host vehicle 177 a vehicle that at a certain moment in time uses the traffic safety 178 application. 180 Traffic safety application 182 application that is primarily applied to decrease the probability 183 of traffic accidents and the loss of life of the occupants of 184 vehicles. 186 3. Overview of VSC and VSC-A traffic safety applications 188 In VSC, see [VSC] 34 vehicle application scenarios have been 189 identified, evaluated and ranked. From this evaluation, a subset of 190 eight significant near- and mid-term traffic safety applications have 191 been selected: (1) cooperative forward collision warning, (2) curve 192 speed warning, (3) pre-crash sensing, (4) traffic signal violation 193 warning, (5) lane-change warning, (6) emergency electronic brake 194 light, (7) left turn assistant, (8) stop sign movement assistant. A 195 brief description of these applications is given below (for more 196 details, see [VSC]): 198 o Traffic signal violation warning: it informs and warns the driver 199 to stop at a legally prescribed location in the situation that the 200 traffic signal indicates a stop and it is estimated that the 201 driver will be in violation. 203 o Curve speed warning - Rollover Warning: aids the driver in 204 negotiating speeds at appropriate speeds. 206 o Emergency Electronic Brake Lights: it is used to inform vehicles 207 that a vehicle brakes hard. In particular in this situation a 208 warning message is sent to the vehicles moving behind the vehicle 209 that brakes hard. 211 o Pre-crash sensing: it prepares the driver for an unavoidable and 212 imminent collision. 214 o Cooperative Forward Collision Warning: aids the driver in 215 mitigating or avoiding collisions with the rear-end vehicles in 216 the forward path of travel through driver notification or warnings 217 of an unavoidable collision. This application does not attempt to 218 control the vehicle to avoid an unavoidable collision. 220 o Left Turn Assistant: it informs the driver about oncoming traffic 221 in order to assist him in making a left turn at a signalized 222 intersection without a phasing left turn arrow. 224 o Lane Change Warning: it warns the driver if an intended lane 225 change may cause a crash with a nearby moving vehicle. 227 o Stop Sign Movement Assistance: it warns the driver that the 228 vehicle is nearby an intersection, which will be passed after 229 having stopped at a stop sign. 231 In the VSC-A project an additional investigation has been performed, 232 on traffic safety applications that can be used in crash immitment 233 scenarios, see [VSC-A]. The following 7 traffic safety applications 234 have been selected for implementation in the VSC-A test bed. 236 o Emergency Electornic Brake Light: is a traffic safety application 237 that is the same as the Emergency Electornic Brake Light 238 application defined in the VSC project, see above. 240 o Forward Collision warning: is a traffic safety application that is 241 the same as the Cooperative Forward Collision Warning application 242 defined in the VSC project, see above. 244 o Intersection Movement Assist: is a traffic is intended to warn the 245 driver of a vehicle when it is not safe to enter an intersection 246 due to high collision probability with other vehicles. It is 247 similar to the Stop Sign Movement Assistance application defined 248 in the VSC project, see above. 250 o Blind Spot Warning & Lane Change Warning: it is similar to the 251 Lane Change Warning application defined in the VSC project, see 252 above. In the Blind Spot Warning application the driver of a host 253 vehicle is informed that another vehicle is moving in an adjacent 254 lane and that this vehicle is positioned in a blind spot zone of 255 the host vehicle. 257 o Do Not Pass Warning: this is an application that was not 258 investigated in the VSC project. It is intended to warn the 259 driver of a host vehicle during a passing maneuver attempt when a 260 slower vehicle, ahead and in the same lane, cannot be safely 261 passed using a passing zone which is occupied by vehicles with the 262 opposite direction of travel. In addition, the application 263 provides advisory information that is intended to inform the 264 driver of the host vehicle that the passing zone is occupied when 265 a passing maneuver is not being attempted. 267 o Control Loss Warning: this is an application that was not 268 investigated in the VSC project. It is intended to enable the 269 driver of a host vehicle to generate and broadcast a control- loss 270 event to surrounding vehicles. Upon receiveing this information 271 the surrounding vehicle determines the relevance of the event and 272 provides a warning to the driver, if appropriate. 274 4. Overview of traffic safety communication performance requirements 276 The VSC consortium specified several performance communication 277 requirements derived from the traffic safety applications, see 278 Figure 1 and Figure 2 and [VSC]. The communication parameters used 279 in Figure 1 and Figure 2 where specified in [VSC]. These are: 281 o Type of Communication: considers, the (1) source-destination of 282 the transmission (infrastructure-to-vehicle, vehicle-to- 283 infrastructure, vehicle-to-vehicle), (2) direction of the 284 transmission (one-way, two-way), and DSRC (IEEE 802.11p), see 285 [DSRC], [IEEE 802.11p], communication, (3) source-reception of 286 communication (point-to-point, point-to-multipooint). Note that 287 the protocol suite that is used in the VSC and VSC-A projects is 288 the WAVE protocol suite, which is composed by the combination of 289 IEEE 1609 protocol suite, see [IEEE 1609.1], [IEEE 1609.2], [IEEE 290 1609.3], [IEEE 1609.4] and the IEEE 802.11p. 292 o Transmission Mode: Describes whether the transmission is triggered 293 by an event (event-driven) or sent automatically at regular 294 intervals (periodic) 296 o Minimum Frequency: defines the minimum rate at which a 297 transmission should be repeated (e.g., 1 Hz). 299 o Allowable latency: defines the maximum duration of time allowable 300 between when information is available for transmission (by the 301 sender) and when it is received by the receiver (e.g., 100 msec). 303 o Data to be transmitted and/or received: describes the contents of 304 the communication (e.g., vehicle location, speed and heading). 305 Design considerations include whether or not vehicles make 306 periodic broadcasts to identify their position on the roadway and 307 how privacy is best maintained. 309 o Maximum required range of communications: defines the 310 communication distance between two units (e.g., two vehicles) that 311 is required to effectively support an application. 313 +---------------- +----------------+----------------------+--- ---+ 314 | | Commun. |.Trans. | Min. | 315 | | Type | Mode | Freq. | 316 | | | | (Hz) | 317 +-----------------+----------------+----------------------+-------+ 318 | Traffic Signal |* infrastructure| Periodic | ~10 | 319 | violation | -to-vehicle | | | 320 | warning |* one-way | | | 321 | |* point-to- | | | 322 | | -multipoint | | | 323 | | | | | 324 | Curve |* infrastructure| Periodic | ~1 | 325 | Speed warning | -to-vehicle | | | 326 | |* one-way | | | 327 | |* point-to- | | | 328 | | -multipoint | | | 329 | | | | | 330 | | | | | 331 | Emergency |* vehicle-to- | Event driven | ~10 | 332 | Electronic | -vehicle | | | 333 | Brake lights |* one-way | | | 334 | |* point-to- | | | 335 | | -multipoint | | | 336 | | | | | 337 | Pre-Crash |* vehicle-to- | Event driven | ~50 | 338 | Sensing | -vehicle | | | 339 | |* Two-way | | | 340 | |* Point-to-point| | | 341 | | | | | 342 | Cooperative |* vehicle-to- | Periodic | ~10 | 343 | Forward | -vehicle | | | 344 | Collision |* One-way | | | 345 | warning |* point-to- | | | 346 | | -multipoint | | | 347 | | | | | 348 | Left Turn |* vehicle-to- | Periodic | ~10 | 349 | Assistant | -infrastructure| | | 350 | | and | | | 351 | | infrastructure| | | 352 | | -to-vehicle | | | 353 | |* One-way | | | 354 | |* point-to- | | | 355 | | -multipoint | | | 356 | | | | | 357 | Lane change |* vehicle-to- | Periodic | ~10 | 358 | warning | -vehicle | | | 359 | |* One-way | | | 360 | |* point-to- | | | 361 | | -multipoint | | | 362 | | | | | 363 | Stop Sign |* vehicle-to- | Periodic | ~10 | 364 | Movement | -infrastructure| | | 365 | Assistance | and | | | 366 | | infrastructure| | | 367 | | -to-vehicle | | | 368 | |* One-way | | | 369 | |* point-to- | | | 370 | | -multipoint | | | 371 | | | | | 372 +-----------------+----------------+----------------------+-------+ 374 Figure 1: Preliminary application scenario communication requirements 375 (part A), from [VSC] 377 +---------------- +----------------+----------------------+--- ---+ 378 | | Latency |Data to be transmitted|Max. | 379 | | (msec) |and/or received |Req'd | 380 | | | |comm.. | 381 | | | |range | 382 | | | |(m) | 383 +-----------------+----------------+----------------------+-------+ 384 | Traffic Signal | ~100 |* traffic signal | ~250 | 385 | violation | | status | | 386 | warning | |* Timing | | 387 | | |* Directionality | | 388 | | |* position of the | | 389 | | | traffic signal | | 390 | | | stopping location | | 391 | | |* Whether condition | | 392 | | | (if available) | | 393 | | |* Road surface type | | 394 | | | | | 395 | Curve | ~1000 |* Curve location | ~200 | 396 | Speed warning | |* Curve speed limits | | 397 | | |* Curvature | | 398 | | |* Bank | | 399 | | |* Road surface type | | 400 | | | | | 401 | Emergency | ~100 |* Position | ~300 | 402 | Electronic | |* Heading | | 403 | Brake lights | |* Velocity | | 404 | | |* Decelaration | | 405 | | | | | 406 | Pre-Crash | ~20 |* Vehicle type | ~50 | 407 | Sensing | |* Position | | 408 | | |* Velocity | | 409 | | |* Acceleration | | 410 | | |* Heading | | 411 | | |* Yaw rate | | 412 | | | | | 413 | Cooperative | ~100 |* Position | ~150 | 414 | Forward | |* Velocity | | 415 | Collision | |* Acceleration | | 416 | warning | |* Heading | | 417 | | |* Yaw rate | | 418 | | | | | 419 | Left Turn | ~100 |* Traffic signal | ~300 | 420 | Assistant | | status | | 421 | | |* Timing | | 422 | | |* Directionality | | 423 | | |* Road shape and | | 424 | | | intersection | | 425 | | | information | | 426 | | |* Vehicle position | | 427 | | |* Velocity | | 428 | | |* Heading | | 429 | | | | | 430 | Lane change | ~100 |* Position | ~150 | 431 | warning | |* Heading | | 432 | | |* Velocity | | 433 | | |* Acceleration | | 434 | | |* Turn Signal status | | 435 | | | | | 436 | Stop Sign | ~100 |* Vehicle position | ~300 | 437 | Movement | |* Velocity | | 438 | Assistance | |* Heading | | 439 | | |* Warning | | 440 | | | | | 441 +---------------- +----------------+----------------------+--- ---+ 443 Figure 2: Preliminary application scenario communication requirements 444 (part B), from [VSC] 446 From these requirements, the most significant ones are: 448 o Message packet size: for all 8 scenarios, a message size of 200 to 449 500 bytes is needed. 451 o Maximum required range of communication: for all 8 scenarios, a 452 maximum required range of communication of 50 to 300 meters is 453 needed. 455 o During the 7 of the 8 scenarios, one-way, point to multipoint 456 broadcast messages were used. 458 o During the 1 of the 8 scenarios, Two-way, point to point messages 459 o During the 6 or 7 of the 8 scenarios, the periodic transmission 460 mode is used. 462 o During the 1 or 2 scenarios, Event-driven transmission mode is 463 used. 465 o During 6 of the 8 scenarios an allowable latency of 100 466 miliseconds is needed. 468 o During 1 of the 8 scenarios an allowable latency of 20 miliseconds 469 is needed. 471 o During 1 of the 8 scenarios an allowable latency of 1 second is 472 needed. 474 In addition to these communication performance requiremenst the VSC 475 project derived the network constraints, depicted in Figure 3, see 476 Appendix H of [VSC]. 478 +----------------------------------+----------------------+ 479 | Constraint type |.Constraint value. | 480 +----------------------------------+----------------------+ 481 | Aggregate bandwidth | 6 Mb/s | 482 | | | 483 | Maximum received packets/sec | 4000 | 484 | | | 485 | Maximum allowable latency | 100 ms | 486 | | | 487 | Maximum network latency | 10 ms | 488 | | | 489 | Maximum packet size | 200 bytes | 490 +----------------------------------+----------------------+ 492 Figure 3: Network constraints, from appendix H of [VSC] 494 The VSC-A project, relaxed some of these network constraints. In 495 particular, the security related network constraints were derived, 496 see Figure 4 and [VSC-A_1609.2]. In addition to these network 497 security constraints, the VSC-A uses for the traffic safety 498 application Do Not Pass Warning, a Maximum required range of 499 communication, of 700 meters as a target. 501 +----------------------------------+----------------------+ 502 | Constraint type |.Constraint value. | 503 +----------------------------------+----------------------+ 504 | Certificate size | < 300bytes | 505 | | | 506 | Authentication generations | 10 | 507 | per second | | 508 | | | 509 | Authentication verifications | 1000 | 510 | per second | | 511 | | | 512 | Time delay (authentication + | < 20ms | 513 | + verification) | | 514 | | | 515 | Over-air-bandwidth overhead | 1,810 bytes/s | 516 | introduced by security | | 517 | mechanisms (including | | 518 | certificates); certificates | | 519 | with each message | | 520 +----------------------------------+----------------------+ 522 Figure 4: Network security constraints, from [VSC-A_1609.2] 524 5. Discussion and conclusions 526 This document described a number of communication performance 527 requirements that are imposed by traffic safety applications on a 528 network layer. These traffic safety applications and requirements 529 have been derived during the VSC (Vehicular Safety Communications) 530 and VSC-A (VSC-Applications) projects. The goal of this document is 531 to stimulate the discussion on judging whether these performance 532 requirements could or could not be supported (currently and in the 533 future) by IP based network solutions. 535 It is however important to note that according to the VSC-A project 536 the following points are important to be mentioned: 538 1. A general point is that the requirements of the target 539 applications are intended to be somewhat representative of the 540 expected requirements discussed in the VSC and VSC-A projects, 541 but over time it is expected that new application ideas to come 542 forward and the communication requirements may broaden as a 543 result. For example, most applications today are designed to 544 treat safety messages as self-contained such that the decision to 545 warn a driver can be made purely based on the contents of the 546 most recent message. In the future, we may see applications that 547 require correlation of data over multiple messages from a given 548 sender, or between multiple senders. 550 2. We now expect typical safety messages to be on the order of 300 551 to 400 bytes (including all layers of overhead), rather than the 552 200 bytes given as the upper limit cited in Appendix H of 553 [VSC].It is expected that the security overhead will be between 554 about 200 bytes and about 90 bytes, depending on whether a full 555 certificate or a hashed certificate digest is included (the full 556 certificate will be included at some reduced rate, probably 1 Hz 557 to 3 Hz). There is also some additional, sub-rate safety 558 information to communicate the sending vehicle's path history, 559 its predicted path, and some of its raw GPS data. The latter is 560 for purposes of computing precise relative positioning. 561 Furthermore, it is expected that in some congested-channel 562 scenarios we might expect to see more than 10 msec of network 563 latency. This is exacerbated under the current multi-channel 564 operation standard (IEEE 1609.4) [IEEE 1609.4], which calls for 565 time to be divided into 50 msec intervals, with switching between 566 a "control channel interval" and a "service channel interval", 567 and then back again. Safety messages are only sent during the 568 control channel interval. It is possible for a given message 569 that is enqueued in one control channel interval to have to wait 570 for the next one if it is still in backoff when the first 571 interval ends, thus incurring at least 50 more msec of latency. 573 That is highly undesirable however, and in any case we're hoping 574 to change the standards to avoid this channel-switching paradigm 575 for safety messages. 577 3. Furthermore, the requirement on "maximum allowable latency" is 578 difficult to be interpreted when the communication takes place 579 over an inherently unreliable medium. The fact is that the 580 applications built on DSRC (Dedicated Short Range Communications) 581 will have to be somewhat robust to lost broadcast messages. We 582 often talk about the delay between successfully delivered 583 messages, and it is expected that safety applications can 584 generally tolerate at least 300 msec of such delay (i.e. two 585 successive lost packets). 587 6. Security Considerations 589 No security considerations apply to this document. 591 7. IANA considerations 593 No IANA considerations apply to this document. 595 Appendix A. References 597 A.1. Normative References 599 A.2. Informative References 601 [draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T, 602 Festag, A., Lenardi, M., "Automotive industry requirements for NEMO 603 Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02, 604 (Work in progress), 2009. 606 [IEEE 802.11p] IEEE P802.11p/D3.0, "Draft Amendment to Standard for 607 Information Technology-Telecommunications and Information Exchange 608 Between Systems-Local and Metropolitan Area Networks- Specific 609 requirements - Part 11: Wireless LAN Medium Access Control (MAC) and 610 Physical Layer (PHY) Specifications- Amendment 7: Wireless Access in 611 Vehicular Environment", 2007. 613 [IEEE 1609.1] IEEE P1609.1, "Trial-Use Standard for Wireless Access 614 in Vehicular Environments (WAVE) - Resource Manager", 2006. 616 [IEEE 1609.2] IEEE P1609.2, "Trial-Use Standard for Wireless Access 617 in Vehicular Environments (WAVE) ― Security Services for 618 Applications and Management Messages", 2006. 620 [IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless 621 Access in Vehicular Environments (WAVE)-Networking Services", 2007. 623 [IEEE 1609.4] IEEE P1609.4, "Trial-Use Standard for Wireless Access 624 in Vehicular Environments (WAVE) ― Multi-Channel Operation", 625 2006 627 [DSRC] Dedicated Short Range Communications (DSRC), USA ITS Standards 628 advisory, http://www.standards.its.dot.gov/Documents/advisories/ 629 dsrc_advisory.htm 631 [VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810 632 591, April 2006. 634 [VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project, 635 Final Annual Report, DOT HS 811 073, January 2009. 637 [VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides 638 presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found 639 via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/ 640 VSCA-1609_080827.pdf 642 Authors' Addresses 644 Georgios Karagiannis 645 University of Twente 646 P.O. BOX 217 647 7500 AE Enschede 648 The Netherlands 650 Email: g.karagiannis@ewi.utwente.nl 652 Ryuji Wakikawa 653 TOYOTA InfoTechnology Center, U.S.A., Inc. 654 465 Bernardo Avenue 655 Mountain View, CA 94043 656 USA 658 Email: ryuji@jp.toyota-itc.com 660 John Kenney 661 TOYOTA InfoTechnology Center, U.S.A., Inc. 662 465 Bernardo Avenue 663 Mountain View, CA 94043 664 USA 666 Email: johnkenney@alumni.nd.edu