Individual Submission G. Karagiannis Internet-Draft University of Twente Intended status: Informational R. Wakikawa Expires: January 7, 2010 J. Kenney Toyota ITC July 6, 2009 Traffic safety applications requirements draft-karagiannis-traffic-safety-requirements-00.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 January 7, 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). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Karagiannis, et al. Expires January 7, 2010 [Page 1] Internet-Draft Traffic safety applications requirements July 2009 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 during the VSC (Vehicular Safety Communications) and VSC-A (VSC-Applications) projects. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of VSC and VSC-A traffic safety applications . . . . 6 4. Overview of traffic safety communication performance requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Discussion and conclusions . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 17 A.1. Normative References . . . . . . . . . . . . . . . . . . . 17 A.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Karagiannis, et al. Expires January 7, 2010 [Page 2] Internet-Draft Traffic safety applications requirements July 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-infrastracture 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 during the VSC (Vehicular Safety Communications) and VSC-A (VSC-Applications) projects. The 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. 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 Karagiannis, et al. Expires January 7, 2010 [Page 3] Internet-Draft Traffic safety applications requirements July 2009 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. Karagiannis, et al. Expires January 7, 2010 [Page 4] Internet-Draft Traffic safety applications requirements July 2009 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). Road Side Unit (RSU) equipment located along highways, at traffic intersections and other type of locations where timely communications with vehicles are needed. Each RSE 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. Karagiannis, et al. Expires January 7, 2010 [Page 5] Internet-Draft Traffic safety applications requirements July 2009 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. 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 Karagiannis, et al. Expires January 7, 2010 [Page 6] Internet-Draft Traffic safety applications requirements July 2009 have been selected for implementation in the VSC-A test bed. o Emergency Electornic Brake Light: is a traffic safety application that is the same as the Emergency Electornic 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. 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 receiveing this information the surrounding vehicle determines the relevance of the event and provides a warning to the driver, if appropriate. Karagiannis, et al. Expires January 7, 2010 [Page 7] Internet-Draft Traffic safety applications requirements July 2009 4. Overview of 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. +---------------- +----------------+----------------------+--- ---+ | | Commun. |.Trans. | Min. | | | Type | Mode | Freq. | | | | | (Hz) | +-----------------+----------------+----------------------+-------+ | Traffic Signal |* infrastructure| Periodic | ~10 | | violation | -to-vehicle | | | Karagiannis, et al. Expires January 7, 2010 [Page 8] Internet-Draft Traffic safety applications requirements July 2009 | 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 | | | | | | | | | Stop Sign |* vehicle-to- | Periodic | ~10 | | Movement | -infrastructure| | | | Assistance | and | | | | | infrastructure| | | | | -to-vehicle | | | Karagiannis, et al. Expires January 7, 2010 [Page 9] Internet-Draft Traffic safety applications requirements July 2009 | |* 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 | | | | |* Decelaration | | | | | | | | Pre-Crash | ~20 |* Vehicle type | ~50 | | Sensing | |* Position | | | | |* Velocity | | | | |* Acceleration | | | | |* Heading | | | | |* Yaw rate | | | | | | | Karagiannis, et al. Expires January 7, 2010 [Page 10] Internet-Draft Traffic safety applications requirements July 2009 | 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. 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 Karagiannis, et al. Expires January 7, 2010 [Page 11] Internet-Draft Traffic safety applications requirements July 2009 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 miliseconds is needed. o During 1 of the 8 scenarios an allowable latency of 20 miliseconds is needed. o During 1 of the 8 scenarios an allowable latency of 1 second is needed. In addition to these communication performance requiremenst 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 January 7, 2010 [Page 12] Internet-Draft Traffic safety applications requirements July 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] Karagiannis, et al. Expires January 7, 2010 [Page 13] Internet-Draft Traffic safety applications requirements July 2009 5. Discussion and conclusions This document described 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 during the VSC (Vehicular Safety Communications) and VSC-A (VSC-Applications) projects. 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. 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. 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 at least 50 more msec of latency. Karagiannis, et al. Expires January 7, 2010 [Page 14] Internet-Draft Traffic safety applications requirements July 2009 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). Karagiannis, et al. Expires January 7, 2010 [Page 15] Internet-Draft Traffic safety applications requirements July 2009 6. Security Considerations No security considerations apply to this document. Karagiannis, et al. Expires January 7, 2010 [Page 16] Internet-Draft Traffic safety applications requirements July 2009 7. IANA considerations No IANA considerations apply to this document. Appendix A. References A.1. Normative References A.2. Informative References [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. [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. [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 [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. Karagiannis, et al. Expires January 7, 2010 [Page 17] Internet-Draft Traffic safety applications requirements July 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 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 Karagiannis, et al. Expires January 7, 2010 [Page 18]