Individual Submission G. Karagiannis Internet-Draft University of Twente Intended status: Informational R. Wakikawa Expires: April 26, 2010 J. Kenney Toyota ITC C. J. Bernardos Universidad Carlos III de Madrid October 26, 2009 Traffic safety applications requirements draft-karagiannis-traffic-safety-requirements-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Karagiannis, et al. Expires April 26, 2010 [Page 1] Internet-Draft Traffic safety applications requirements October 2009 Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a number of communication performance requirements that are imposed by traffic safety applications on a network layer. These traffic safety applications and requirements have been derived by the USA VSC (Vehicular Safety Communications)and VSC-A (VSC-Applications) projects and by the European Car to Car Communication Consortium (C2C-CC) and the ETSI TC ITS standardization body. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network solutions. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of VSC and VSC-A traffic safety applications . . . . 6 4. Overview of the European Car to Car Communication Consortium traffic safety applications . . . . . . . . . . . . . . . . . 8 5. Overview of traffic safety communication performance requirements . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Discussion and conclusions . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Karagiannis, et al. Expires April 26, 2010 [Page 2] Internet-Draft Traffic safety applications requirements October 2009 1. Introduction Vehicular networking can be considered as one of the most important enabling technologies needed to support various types of traffic applications, such as infotainment type of applications, traffic efficiency & management and traffic safety applications. Traffic safety applications are those that are primarily applied to decrease the probability of traffic accidents and the loss of life of the occupants of vehicles. Note that VSC and VSC-A projects focus on vehicle-to-vehicle safety. Another project called CICAS-V (Cooperative Intersection Collision Avoidance Systems - Violation) discuss the traffic safety application over vehicle-to-infrastructure communication. Traffic efficiency & management applications are focusing on improving the vehicle traffic flow, traffic coordination and traffic assistance. Moreover, traffic efficiency & management applications are focusing on providing updated local information, maps and in general messages of relevance limited in space and/or time. Infotainment types of applications are the applications that are neither traffic safety applications nor traffic efficiency & management applications. Such applications are supported by e.g., media downloading use cases. This document describes a number of communication performance requirements that are imposed by traffic safety applications on a network layer. These traffic safety applications and requirements have been derived by: o the USA VSC (Vehicular Safety Communications) and VSC-A (VSC- Applications) projects. O the European Car-to-Car Communication Consortium (C2C-CC) [C2C-CC] and the ETSI TC ITS [ETSI TC ITS], with the additional support of some EU funded research projects, such as SEVECOM [SEVECOM], SAFESPOT [SAFESPOT], CVIS [CVIS]. PREDRIVE-C2x [PREDRIVE-C2x], GEONET [GEONET]. The USA Vehicle Safety Communications (VSC) consortium, see [VSC], is supported among others by CAMP (Crash Avoidance Metrics Partnership). CAMP is a partnership that has been formed in 1995 by Ford Motor Company and General Motors Corporation. The objective of CAMP is to accelerate the implementation of crash avoidance countermeasures to improve traffic safety by investigating and developing new technologies. VSC has been realized in two phases. Karagiannis, et al. Expires April 26, 2010 [Page 3] Internet-Draft Traffic safety applications requirements October 2009 The first phase, denoted as VSC started in 2002 and ended in 2004. The second phase started in 2006 and ends in 2009. VSC focused and is focusing on traffic safety related applications. In 2006, The VSC 2 consortium in cooperation with USDOT initiated a three-year collaborative effort in the area of wireless-based safety applications under the Vehicle Safety Communications - Applications (VSC-A) project, see [VSC-A]. The VSC2 consortium consists of the following members; Mercedes-Benz, Ford, General Motors, Honda & Toyota. The main goal of this project is to develop and test communications-based vehicle safety systems to determine whether vehicle positioning in combination with the DSRC at 5.9 GHz can improve the autonomous vehicle-based safety systems and/or enable new communication-based safety applications. The WAVE Short Message Protocol [IEEE 1609.3] was designed specifically to offer a more efficient (smaller size) alternative to TCP or UDP over IP, for 1-hop messages that require no routing. The goal of this document is to stimulate the discussion on judging whether these communication performance requirements could or could not be (currently and in the future) supported by IP based network solutions. The European Car-to-Car Communication Consortium (C2C-CC) is an industry consortium of car manufacturers and electronics suppliers that focuses on the definition of an European standard for vehicular communication protocols. The European Telecommunications Standards Institute (ETSI) Technical Committee (TC) Intelligent Transport Systems (ITS) was established in October 2007 with the goal of developing and maintaining standards, specifications and other deliverables to support the development and the implementation of ITS service provision. It is foreseen that ETSI ITS will be the reference standardization body of the future European ITS standards, and actually the C2C-CC provides recommendations to the ETSI TC ITS. 2. Terminology The following terms are used in this document : On Board Unit (OBU) a processing and communication feature that is located in a vehicle, which provides an application runtime environment, positioning, security and communications functions and interfaces to other vehicles including human machine interfaces. OBU is also known as OBE (On-Board Equipment). Karagiannis, et al. Expires April 26, 2010 [Page 4] Internet-Draft Traffic safety applications requirements October 2009 Road Side Unit (RSU) equipment located along highways, at traffic intersections and other type of locations where timely communications with vehicles are needed. Each RSU includes DSRC radio, a positioning system and a router to route packets back through the infrastructure network. RSU is also know as RSE (Road Side Equipment) vehicle-to-vehicle (v2v) (same as in [draft-ietf-mext-nemo-ro-automotive-req]): a generic communication mode in which data packets are exchanged between two vehicles, either directly or traversing multiple vehicles, without involving any node in the infrastructure. vehicle-to-infrastructure generic communication mode in which data packets sent by a vehicle traverse a network infrastructure. infrastructure-to-vehicle generic communication mode in which data packets received by a vehicle traverse a network infrastructure. Host vehicle a vehicle that at a certain moment in time uses the traffic safety application. Traffic safety application application that is primarily applied to decrease the probability of traffic accidents and the loss of life of the occupants of vehicles. Geographically-scoped broadcast (or geocast), see [C2C-CC_Manifesto] forwarding mechanism that is used to transport data from a single node to all nodes within a geographically target area. The scope is defined by the geographic region. The geographic region is determined by a geometric shape, such as circle and rectangle. Karagiannis, et al. Expires April 26, 2010 [Page 5] Internet-Draft Traffic safety applications requirements October 2009 Geographical Unicast (or geounicast) see [C2C-CC_Manifesto] Forwarding mechanism that is used for unidirectional data transport from a single node (source) to a single node (destination) by means of direct communication or by multiple hops based on C2C Communication specific addresses that include node identifier, geographical position, and time information. Geographically-scoped anycast (or geoanycast), see [C2C-CC_Manifesto] forwarding mechanism that transports data from a single node to any of the nodes within a geographically area. Compared to geographically-scoped broadcast, with geographically-scoped anycast a packet is not forwarded inside of the geographic area when the packet has reached the area. 3. Overview of VSC and VSC-A traffic safety applications In VSC, see [VSC] 34 vehicle application scenarios have been identified, evaluated and ranked. From this evaluation, a subset of eight significant near- and mid-term traffic safety applications have been selected: (1) cooperative forward collision warning, (2) curve speed warning, (3) pre-crash sensing, (4) traffic signal violation warning, (5) lane-change warning, (6) emergency electronic brake light, (7) left turn assistant, (8) stop sign movement assistant. A brief description of these applications is given below (for more details, see [VSC]): o Traffic signal violation warning: it informs and warns the driver to stop at a legally prescribed location in the situation that the traffic signal indicates a stop and it is estimated that the driver will be in violation. o Curve speed warning - Rollover Warning: aids the driver in negotiating speeds at appropriate speeds. o Emergency Electronic Brake Lights: it is used to inform vehicles that a vehicle brakes hard. In particular in this situation a warning message is sent to the vehicles moving behind the vehicle that brakes hard. o Pre-crash sensing: it prepares the driver for an unavoidable and imminent collision. Karagiannis, et al. Expires April 26, 2010 [Page 6] Internet-Draft Traffic safety applications requirements October 2009 o Cooperative Forward Collision Warning: aids the driver in mitigating or avoiding collisions with the rear-end vehicles in the forward path of travel through driver notification or warnings of an unavoidable collision. This application does not attempt to control the vehicle to avoid an unavoidable collision. o Left Turn Assistant: it informs the driver about oncoming traffic in order to assist him in making a left turn at a signalized intersection without a phasing left turn arrow. o Lane Change Warning: it warns the driver if an intended lane change may cause a crash with a nearby moving vehicle. o Stop Sign Movement Assistance: it warns the driver that the vehicle is nearby an intersection, which will be passed after having stopped at a stop sign. In the VSC-A project an additional investigation has been performed, on traffic safety applications that can be used in crash immitment scenarios, see [VSC-A]. The following 7 traffic safety applications have been selected for implementation in the VSC-A test bed. o Emergency Electronic Brake Light: is a traffic safety application that is the same as the Emergency Electronic Brake Light application defined in the VSC project, see above. o Forward Collision warning: is a traffic safety application that is the same as the Cooperative Forward Collision Warning application defined in the VSC project, see above. o Intersection Movement Assist: is a traffic is intended to warn the driver of a vehicle when it is not safe to enter an intersection due to high collision probability with other vehicles. It is similar to the Stop Sign Movement Assistance application defined in the VSC project, see above. o Blind Spot Warning & Lane Change Warning: it is similar to the Lane Change Warning application defined in the VSC project, see above. In the Blind Spot Warning application the driver of a host vehicle is informed that another vehicle is moving in an adjacent lane and that this vehicle is positioned in a blind spot zone of the host vehicle. o Do Not Pass Warning: this is an application that was not investigated in the VSC project. It is intended to warn the driver of a host vehicle during a passing maneuver attempt when a slower vehicle, ahead and in the same lane, cannot be safely passed using a passing zone which is occupied by vehicles with the opposite direction of travel. Karagiannis, et al. Expires April 26, 2010 [Page 7] Internet-Draft Traffic safety applications requirements October 2009 In addition, the application provides advisory information that is intended to inform the driver of the host vehicle that the passing zone is occupied when a passing maneuver is not being attempted. o Control Loss Warning: this is an application that was not investigated in the VSC project. It is intended to enable the driver of a host vehicle to generate and broadcast a control- loss event to surrounding vehicles. Upon receiving this information the surrounding vehicle determines the relevance of the event and provides a warning to the driver, if appropriate. 4. Overview of the European Car to Car Communication Consortium traffic safety applications The Car to Car Communication Consortium specified a number of traffic safety use cases. The following three are considered as being the main traffic safety use cases, see [C2C-CC_Manifesto]: o Cooperative Forward Collision Warning: this use case tries to provide assistance to the driver. Vehicles share (anonymously) information such as position, speed and direction. This enables the prediction of an imminent rear-end collision, by each vehicle monitoring the behavior of its own driver and the information of neighboring vehicles. If a potential risk is detected, the vehicle warns the driver. This use case requires: the ability for all vehicles to share Information with each other over a distance of about 20 to 200 meters, accurate relative positioning of the vehicles, trust relationships among the vehicles and a reasonable market penetration (at least 10%). o Pre-Crash Sensing/Warning: this use case is similar to the previous one, but in this case the collision is identified as unavoidable, and then the involved vehicles exchange more precise information to optimize the usage of actuators such as airbags, seat belt pre-tensors, etc... This use case requires basically the same abilities that the previous one, restricting the needed communication range to 20 to 100 meters, and adding the requirement of a fast and reliable connection between the involved cars. o Hazardous Location V2V Notification: this use case is based on the share of information that relates to dangerous locations on the road, among vehicles, and also among vehicles and the road infrastructure. On one hand, vehicles may detect the dangerous locations from sensors in the vehicle or from events such as the actuation of the ESP (Electronic Stability Program). Karagiannis, et al. Expires April 26, 2010 [Page 8] Internet-Draft Traffic safety applications requirements October 2009 On the other hand, recipients of this information may use it to properly configure active safety systems and/or warn the driver. This use case requires: vehicles to trust other vehicles and roadside units, reasonable market penetration, the ability of vehicles to share information about a specific geographic location over multiple-hops and the ability to validate information propagated through multiple hops. 5. Overview of traffic safety communication performance requirements 5.1 VSC and VSCA Traffic safety communication performance requirements The VSC consortium specified several performance communication requirements derived from the traffic safety applications, see Figure 1 and Figure 2 and [VSC]. The communication parameters used in Figure 1 and Figure 2 where specified in [VSC]. These are: o Type of Communication: considers, the (1) source-destination of the transmission (infrastructure-to-vehicle, vehicle-to- infrastructure, vehicle-to-vehicle), (2) direction of the transmission (one-way, two-way), and DSRC (IEEE 802.11p), see [DSRC], [IEEE 802.11p], communication, (3) source-reception of communication (point-to-point, point-to-multipooint). Note that the protocol suite that is used in the VSC and VSC-A projects is the WAVE protocol suite, which is composed by the combination of IEEE 1609 protocol suite, see [IEEE 1609.1], [IEEE 1609.2], [IEEE 1609.3], [IEEE 1609.4] and the IEEE 802.11p. o Transmission Mode: Describes whether the transmission is triggered by an event (event-driven) or sent automatically at regular intervals (periodic) o Minimum Frequency: defines the minimum rate at which a transmission should be repeated (e.g., 1 Hz). o Allowable latency: defines the maximum duration of time allowable between when information is available for transmission (by the sender) and when it is received by the receiver (e.g., 100 msec). o Data to be transmitted and/or received: describes the contents of the communication (e.g., vehicle location, speed and heading). Design considerations include whether or not vehicles make periodic broadcasts to identify their position on the roadway and how privacy is best maintained. o Maximum required range of communications: defines the communication distance between two units (e.g., two vehicles) that is required to effectively support an application. Karagiannis, et al. Expires April 26, 2010 [Page 9] Internet-Draft Traffic safety applications requirements October 2009 +---------------- +----------------+----------------------+--- ---+ | | Commun. |.Trans. | Min. | | | Type | Mode | Freq. | | | | | (Hz) | +-----------------+----------------+----------------------+-------+ | Traffic Signal |* infrastructure| Periodic | ~10 | | violation | -to-vehicle | | | | warning |* one-way | | | | |* point-to- | | | | | -multipoint | | | | | | | | | Curve |* infrastructure| Periodic | ~1 | | Speed warning | -to-vehicle | | | | |* one-way | | | | |* point-to- | | | | | -multipoint | | | | | | | | | | | | | | Emergency |* vehicle-to- | Event driven | ~10 | | Electronic | -vehicle | | | | Brake lights |* one-way | | | | |* point-to- | | | | | -multipoint | | | | | | | | | Pre-Crash |* vehicle-to- | Event driven | ~50 | | Sensing | -vehicle | | | | |* Two-way | | | | |* Point-to-point| | | | | | | | | Cooperative |* vehicle-to- | Periodic | ~10 | | Forward | -vehicle | | | | Collision |* One-way | | | | warning |* point-to- | | | | | -multipoint | | | | | | | | | Left Turn |* vehicle-to- | Periodic | ~10 | | Assistant | -infrastructure| | | | | and | | | | | infrastructure| | | | | -to-vehicle | | | | |* One-way | | | | |* point-to- | | | | | -multipoint | | | | | | | | | Lane change |* vehicle-to- | Periodic | ~10 | | warning | -vehicle | | | | |* One-way | | | | |* point-to- | | | | | -multipoint | | | Karagiannis, et al. Expires April 26, 2010 [Page 10] Internet-Draft Traffic safety applications requirements October 2009 | | | | | | Stop Sign |* vehicle-to- | Periodic | ~10 | | Movement | -infrastructure| | | | Assistance | and | | | | | infrastructure| | | | | -to-vehicle | | | | |* One-way | | | | |* point-to- | | | | | -multipoint | | | | | | | | +-----------------+----------------+----------------------+-------+ Figure 1: Preliminary application scenario communication requirements (part A), from [VSC] +---------------- +----------------+----------------------+--- ---+ | | Latency |Data to be transmitted|Max. | | | (msec) |and/or received |Req'd | | | | |comm.. | | | | |range | | | | |(m) | +-----------------+----------------+----------------------+-------+ | Traffic Signal | ~100 |* traffic signal | ~250 | | violation | | status | | | warning | |* Timing | | | | |* Directionality | | | | |* position of the | | | | | traffic signal | | | | | stopping location | | | | |* Whether condition | | | | | (if available) | | | | |* Road surface type | | | | | | | | Curve | ~1000 |* Curve location | ~200 | | Speed warning | |* Curve speed limits | | | | |* Curvature | | | | |* Bank | | | | |* Road surface type | | | | | | | | Emergency | ~100 |* Position | ~300 | | Electronic | |* Heading | | | Brake lights | |* Velocity | | | | |* Deceleration | | | | | | | Karagiannis, et al. Expires April 26, 2010 [Page 11] Internet-Draft Traffic safety applications requirements October 2009 | Pre-Crash | ~20 |* Vehicle type | ~50 | | Sensing | |* Position | | | | |* Velocity | | | | |* Acceleration | | | | |* Heading | | | | |* Yaw rate | | | | | | | | Cooperative | ~100 |* Position | ~150 | | Forward | |* Velocity | | | Collision | |* Acceleration | | | warning | |* Heading | | | | |* Yaw rate | | | | | | | | Left Turn | ~100 |* Traffic signal | ~300 | | Assistant | | status | | | | |* Timing | | | | |* Directionality | | | | |* Road shape and | | | | | intersection | | | | | information | | | | |* Vehicle position | | | | |* Velocity | | | | |* Heading | | | | | | | | Lane change | ~100 |* Position | ~150 | | warning | |* Heading | | | | |* Velocity | | | | |* Acceleration | | | | |* Turn Signal status | | | | | | | | Stop Sign | ~100 |* Vehicle position | ~300 | | Movement | |* Velocity | | | Assistance | |* Heading | | | | |* Warning | | | | | | | +---------------- +----------------+----------------------+--- ---+ Figure 2: Preliminary application scenario communication requirements (part B), from [VSC] From these requirements, the most significant ones are: o Message packet size: for all 8 scenarios, a message size of 200 to 500 bytes is needed. o Maximum required range of communication: for all 8 scenarios, a maximum required range of communication of 50 to 300 meters is needed. Karagiannis, et al. Expires April 26, 2010 [Page 12] Internet-Draft Traffic safety applications requirements October 2009 o During the 7 of the 8 scenarios, one-way, point to multipoint broadcast messages were used. o During the 1 of the 8 scenarios, Two-way, point to point messages o During the 6 or 7 of the 8 scenarios, the periodic transmission mode is used. o During the 1 or 2 scenarios, Event-driven transmission mode is used. o During 6 of the 8 scenarios an allowable latency of 100 milliseconds is needed. o During 1 of the 8 scenarios an allowable latency of 20 milliseconds is needed. o During 1 of the 8 scenarios an allowable latency of 1 second is needed. In addition to these communication performance requirements the VSC project derived the network constraints, depicted in Figure 3, see Appendix H of [VSC]. +----------------------------------+----------------------+ | Constraint type |.Constraint value. | +----------------------------------+----------------------+ | Aggregate bandwidth | 6 Mb/s | | | | | Maximum received packets/sec | 4000 | | | | | Maximum allowable latency | 100 ms | | | | | Maximum network latency | 10 ms | | | | | Maximum packet size | 200 bytes | +----------------------------------+----------------------+ Figure 3: Network constraints, from appendix H of [VSC] The VSC-A project, relaxed some of these network constraints. In particular, the security related network constraints were derived, see Figure 4 and [VSC-A_1609.2]. In addition to these network security constraints, the VSC-A uses for the traffic safety application Do Not Pass Warning, a Maximum required range of communication, of 700 meters as a target. Karagiannis, et al. Expires April 26, 2010 [Page 13] Internet-Draft Traffic safety applications requirements October 2009 +----------------------------------+----------------------+ | Constraint type |.Constraint value. | +----------------------------------+----------------------+ | Certificate size | < 300bytes | | | | | Authentication generations | 10 | | per second | | | | | | Authentication verifications | 1000 | | per second | | | | | | Time delay (authentication + | < 20ms | | + verification) | | | | | | Over-air-bandwidth overhead | 1,810 bytes/s | | introduced by security | | | mechanisms (including | | | certificates); certificates | | | with each message | | +----------------------------------+----------------------+ Figure 4: Network security constraints, from [VSC-A_1609.2] 5.2 C2C-CC and ETSI TC ITS traffic safety communication performance requirements The performance requirements associated with the C2C-CC traffic safety applications are listed in the [ETSITR102638] ETSI specification. These performance requirements are listed in Figures 5 and 6. +---------------- +----------------+----------------------+--- ---+ | | Commun. |.Trans. | Min. | | | Type | Mode | Freq. | | | | | (Hz) | +-----------------+----------------+----------------------+-------+ | Cooperative |* vehicle-to- | Periodic | ~10 | | Forward | -vehicle | | | | Collision |* Broadcast | | | | warning |* Geocast | | | | | | | | | | | | | | Pre-Crash |* vehicle-to- | Periodic | ~10 | | Sensing | -vehicle | | | | |* Unicast | | | | |* | | | Karagiannis, et al. Expires April 26, 2010 [Page 14] Internet-Draft Traffic safety applications requirements October 2009 | | | | | | Hazardous |* vehicle-to- | Time limited | ~10 | | location | -vehicle | Periodic | | | notification |* Broadcast | | | | |* Geocast | | | | |* | | | +-----------------+----------------+----------------------+-------+ Figure 5: Preliminary application scenario communication requirements (part A), from [ETSITR102638] +---------------- +----------------+----------------------+--- ---+ | | Latency |Data to be transmitted|Max. | | | (msec) |and/or received |Req'd | | | | |comm.. | | | | |range | | | | |(m) | +-----------------+----------------+----------------------+-------+ | Cooperative | ~100 |* Position | 20 to | | Forward | |* Velocity | 200 | | Collision | |* Acceleration | | | warning | |* Heading | | | | |* Yaw rate | | | | | | | | Pre-Crash | ~100 |* Vehicle type | 20 to | | Sensing | |* Position | 100 | | | |* Velocity | | | | |* Acceleration | | | | |* Heading | | | | |* Yaw rate | | | | | | | | Hazardous | |* events and |300 to | | location | |* characteristics | 20000 | | notification | |* of road | | +---------------- +----------------+----------------------+--- ---+ Figure 6: Preliminary application scenario communication requirements (part B), from [ETSITR102638] 6. Discussion and conclusions This document described a number of communication performance requirements that are imposed by traffic safety applications on a network layer. Karagiannis, et al. Expires April 26, 2010 [Page 15] Internet-Draft Traffic safety applications requirements October 2009 These traffic safety applications and requirements have been derived by the USA VSC (Vehicular Safety Communications)and VSC-A (VSC-Applications) projects and by the European Car to Car Communication Consortium (C2C-CC) and the ETSI TC ITS standardization body. The goal of this document is to stimulate the discussion on judging whether these performance requirements could or could not be supported (currently and in the future) by IP based network solutions. Comparing the traffic safety applications derived by European and by USA projects and consortia the following conclusions can be derived: o the traffic safety applications and the use cases derived by European and USA projects and consortia are quite identical. o the performance requirements derived by European and USA projects and consortia are similar. The main difference between the requirements derived by European projects and consortia and the ones derived by USA projects and consortia is that the European derived traffic safety applications consider multi-hop communication, i.e., geocasting forwarding, while the USA derived ones use only single hop broadcast solutions. The multi-hop communication requires geocast related forwarding mechanisms, such as: geographical unicast, geographically-scoped broadcast (also referred to as geo-broadcast) and geographically-scoped anycast (also known as geo-anycast). The C2C-CC currently assumes that IP is not suitable for safety and traffic efficiency applications (too much overhead, lack of geocast forwarding features, etc.). There are however initiatives, like the GeoNet project [GEONET] working on the design of mechanisms to integrate IP on top of the C2C-CC architecture. It is however important to note that according to the VSC-A project the following points are important to be mentioned: 1. A general point is that the requirements of the target applications are intended to be somewhat representative of the expected requirements discussed in the VSC and VSC-A projects, but over time it is expected that new application ideas to come forward and the communication requirements may broaden as a result. For example, most applications today are designed to treat safety messages as self-contained such that the decision to warn a driver can be made purely based on the contents of the most recent message. In the future, we may see applications that require correlation of data over multiple messages from a given sender, or between multiple senders. Karagiannis, et al. Expires April 26, 2010 [Page 16] Internet-Draft Traffic safety applications requirements October 2009 2. We now expect typical safety messages to be on the order of 300 to 400 bytes (including all layers of overhead), rather than the 200 bytes given as the upper limit cited in Appendix H of [VSC].It is expected that the security overhead will be between about 200 bytes and about 90 bytes, depending on whether a full certificate or a hashed certificate digest is included (the full certificate will be included at some reduced rate, probably 1 Hz to 3 Hz). There is also some additional, sub-rate safety information to communicate the sending vehicle's path history, its predicted path, and some of its raw GPS data. The latter is for purposes of computing precise relative positioning. Furthermore, it is expected that in some congested-channel scenarios we might expect to see more than 10 msec of network latency. This is exacerbated under the current multi-channel operation standard (IEEE 1609.4) [IEEE 1609.4], which calls for time to be divided into 50 msec intervals, with switching between a "control channel interval" and a "service channel interval", and then back again. Safety messages are only sent during the control channel interval. It is possible for a given message that is enqueued in one control channel interval to have to wait for the next one if it is still in backoff when the first interval ends, thus incurring up to 50 more msec of latency. That is highly undesirable however, and in any case we're hoping to change the standards to avoid this channel-switching paradigm for safety messages. 3. Furthermore, the requirement on "maximum allowable latency" is difficult to be interpreted when the communication takes place over an inherently unreliable medium. The fact is that the applications built on DSRC (Dedicated Short Range Communications) will have to be somewhat robust to lost broadcast messages. We often talk about the delay between successfully delivered messages, and it is expected that safety applications can generally tolerate at least 300 msec of such delay (i.e. two successive lost packets). 7. Security Considerations Security is a critical issue in vehicular networks. If IP networking solutions will be used to support vehicular traffic safety applications then the impact on the security considerations have to be analyzed. 8. IANA considerations No IANA considerations apply to this document. Karagiannis, et al. Expires April 26, 2010 [Page 17] Internet-Draft Traffic safety applications requirements October 2009 9. References 9.1. Normative References 9.2. Informative References [C2C-CC] C2C-CC official website, http://www.car-2-car.org/, (visited in October 2009). [C2C-CC_MANIFESTO] Car to Car Communication Consortium, "Car to Car Communication Consortium Manifesto: Overview of the C2C-CC System", C2C-CC, version 1.1, 2007. [CVIS] CVIS EU FP6 project website, http://www.cvisproject.org, (visited in October 2009). [draft-ietf-mext-nemo-ro-automotive-req] Baldessari, R., Ernst, T, Festag, A., Lenardi, M., "Automotive industry requirements for NEMO Route Optimmization", draft-ietf-mext-nemo-ro-automotive-req-02, (Work in progress), 2009. [ETSI TC ITS] ETSI official website, http://www.etsi.org/, (visited in October 2009). [ETSITR102638] ETSI TR 102 638, "Intelligent Transport System (ITS); Vehicular Communications; Basic Set of Applications; Definition, ETSI specification TR 102 638, v.1.0.5, 2009 [GEONET] GeoNet EU FP7 project website, http://www.geonet-project.eu, (visited in October 2009). [IEEE 802.11p] IEEE P802.11p/D3.0, "Draft Amendment to Standard for Information Technology-Telecommunications and Information Exchange Between Systems-Local and Metropolitan Area Networks- Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications- Amendment 7: Wireless Access in Vehicular Environment", 2007. [IEEE 1609.1] IEEE P1609.1, "Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) - Resource Manager", 2006. [IEEE 1609.2] IEEE P1609.2, "Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) ― Security Services for Applications and Management Messages", 2006. Karagiannis, et al. Expires April 26, 2010 [Page 18] Internet-Draft Traffic safety applications requirements October 2009 [IEEE 1609.3] IEEE Std P1609.3, "IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE)-Networking Services", 2007. [IEEE 1609.4] IEEE P1609.4, "Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) ― Multi-Channel Operation", 2006 [DSRC] Dedicated Short Range Communications (DSRC), USA ITS Standards advisory, http://www.standards.its.dot.gov/Documents/advisories/ dsrc_advisory.htm [PREDRIVE-C2x] Pre-Drive C2X EU FP7 project website, http://www.pre-drive-c2x.eu, (visited in October 2009). [SAFESPOT] SAFESPOT EU FP6 project website, http://www.safespot-eu.org, (visited in October 2009). [SEVECOM] SEVECOM EU FP6 project website, http://www.sevecom.org, (visited in October 2009). [VSC] Vehicle Safety Communications Project, Final Report, DOT HS 810 591, April 2006. [VSC-A] Vehicle Safety Communications - Applications (VSC-A) Project, Final Annual Report, DOT HS 811 073, January 2009. [VSC-A_1609.2] VSC-A presentation, "Security in VSC-A", slides presented at IEEE 1609 meeting on August 26 - 28, 2008, to be found via: http://vii.path.berkeley.edu/1609_wave/aug08/presentations/ VSCA-1609_080827.pdf Authors' Addresses Georgios Karagiannis University of Twente P.O. BOX 217 7500 AE Enschede The Netherlands Email: g.karagiannis@ewi.utwente.nl Karagiannis, et al. Expires April 26, 2010 [Page 19] Internet-Draft Traffic safety applications requirements October 2009 Ryuji Wakikawa TOYOTA InfoTechnology Center, U.S.A., Inc. 465 Bernardo Avenue Mountain View, CA 94043 USA Email: ryuji@jp.toyota-itc.com John Kenney TOYOTA InfoTechnology Center, U.S.A., Inc. 465 Bernardo Avenue Mountain View, CA 94043 USA Email: johnkenney@alumni.nd.edu Carlos Jesus Bernardos Universidad Carlos III de Madrid. Avda de la Universidad, 30 E-28911 Leganes (Madrid) Spain Email: cjbc@it.uc3m.es Karagiannis, et al. Expires April 26, 2010 [Page 20]