Individual Submission G. Karagiannis
Internet-Draft University of Twente
Intended status: Informational R. Wakikawa
Expires: August 25, 2010 J. Kenney
Toyota ITC
C. J. Bernardos
Universidad Carlos III de Madrid
F. Kargl
University of Twente
February 25, 2010
Traffic safety applications requirements
draft-karagiannis-traffic-safety-requirements-02.txt
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 (Vehicle 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.
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 August 25, 2010.
Karagiannis, et al. Expires August 25, 2010 [Page 1]
Internet-Draft Traffic safety applications requirements February 2010
Copyright Notice
Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Karagiannis, et al. Expires August 25, 2010 [Page 2]
Internet-Draft Traffic safety applications requirements February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of VSC and VSC-A traffic safety applications . . . . 7
4. Overview of the European Car to Car Communication Consortium
traffic safety applications . . . . . . . . . . . . . . . . . 9
5. Overview of traffic safety communication performance
requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Discussion and conclusions . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Karagiannis, et al. Expires August 25, 2010 [Page 3]
Internet-Draft Traffic safety applications requirements February 2010
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, which are
not specifically used to decrease the probability of traffic
accidents and/or the loss of life of the occupants of vehicles.
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 (Vehicle 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 August 25, 2010 [Page 4]
Internet-Draft Traffic safety applications requirements February 2010
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 August 25, 2010 [Page 5]
Internet-Draft Traffic safety applications requirements February 2010
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 August 25, 2010 [Page 6]
Internet-Draft Traffic safety applications requirements February 2010
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 and choosing appropriate curve 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 August 25, 2010 [Page 7]
Internet-Draft Traffic safety applications requirements February 2010
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.
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 August 25, 2010 [Page 8]
Internet-Draft Traffic safety applications requirements February 2010
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
host vehicle to autonomously 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 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 August 25, 2010 [Page 9]
Internet-Draft Traffic safety applications requirements February 2010
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-multipoint). 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 August 25, 2010 [Page 10]
Internet-Draft Traffic safety applications requirements February 2010
+---------------- +----------------+----------------------+--- ---+
| | 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 August 25, 2010 [Page 11]
Internet-Draft Traffic safety applications requirements February 2010
| | | | |
| 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 August 25, 2010 [Page 12]
Internet-Draft Traffic safety applications requirements February 2010
| 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, see also Section 4.6 of [VSC], 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 August 25, 2010 [Page 13]
Internet-Draft Traffic safety applications requirements February 2010
o During 7 of the 8 scenarios, one-way, point to multipoint
broadcast messages were used.
o During 1 of the 8 scenarios, Two-way, point to point messages
o During 6 or 7 of the 8 scenarios, the periodic transmission
mode is used.
o During 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 August 25, 2010 [Page 14]
Internet-Draft Traffic safety applications requirements February 2010
+----------------------------------+----------------------+
| 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 August 25, 2010 [Page 15]
Internet-Draft Traffic safety applications requirements February 2010
| | | | |
| 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 August 25, 2010 [Page 16]
Internet-Draft Traffic safety applications requirements February 2010
These traffic safety applications and requirements
have been derived by the USA VSC (Vehicle 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 August 25, 2010 [Page 17]
Internet-Draft Traffic safety applications requirements February 2010
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
As safety applications operate in dangerous situations, it is
generally accepted that secure operations of vehicular networks are
of paramount importance. Attackers must not be able to subvert
operation of applications, e.g. to trigger false warnings or easily
suppress real ones. Therefore, both US and European research
activities on vehicular networks have worked on security solutions
right from the start.
Karagiannis, et al. Expires August 25, 2010 [Page 18]
Internet-Draft Traffic safety applications requirements February 2010
IEEE 1602.2 [IEEE 1609.2] provides an early solution taking into
account many requirements. The European SeVeCom project [SEVECOM] has
also published a design for a complete security subsystem for
vehicular networks [SEVECOM-D2.1,SEVECOM-D2.1-APPA]. Furthermore, the
PRECIOSA project is focusing dedicatedly on privacy-friendly design
of Intelligent Transportation Systems, including vehicular networks
[PRECIOSA].
Analyzing security requirements in vehicular networks, one can refer
to classical security goals: confidentiality, integrity, and
availability.
Confidentiality: One can note that for all safety applications,
listed earlier, confidentiality is not a primary requirement.
Information contained in safety-related messages should be received
by all neighbors and can be considered public. So encryption of data
is not a primary concern. If so, one could analyze the applicability
of ESP headers for this purpose. However, note that there are privacy
requirements (see below).
Integrity: It is of great import to ensure correctness of
communicated data and to prevent attackers from sending forged or
modified messages that could trigger application warnings or other
reactions. One first step suggested by above mentioned solutions is
to establish an identity management system that uses digital
certificates and signatures by which receivers can verify that
messages have been sent by valid vehicles. These solutions are very
similar to AUTH headers of IPsec, however, size limitations suggest
to use suitable cryptosystems like ECDSA. Restricting communication
to valid vehicles is not sufficient, as those vehicles could still
send false information (e.g. wrong position data). Additional
mechanisms for data-consistency checking are proposed to detect and
discard such information.
Availability: protecting the vehicular network from all kind of
jamming and overloading attacks is important but beyond the scope of
this paper, as security mechanisms usually address physical and
datalink layer attacks. If multi-hop forwarding schemes like Geocast
are used, protection from Denial-of-Service attacks targeting the
network layer also need to be taken into consideration. Because of
the broadcast nature of vehicular communication, mechanisms to
protect e.g. from DDoS attacks in the Internet will likely be not
portable.
Beyond those security requirements, it is also important to protect
privacy of drivers. Foremost, it should be impossible to find the
location of a vehicle or track its itinerary based on recorded
vehicular communications. Solutions generally apply pseudonymous
identifiers to prevent a certain degree of unlinkability.
Karagiannis, et al. Expires August 25, 2010 [Page 19]
Internet-Draft Traffic safety applications requirements February 2010
To prevent tracking vehicles, those identifiers need to be changed
regularly (e.g., in each minute). This creates additional challenges
to communication layers that can e.g. be addressed using
MobileIP/NEMO technologies.
As discussed in Section 5, vehicular networks create a very
challenging environment for a security system. Due to the broadcast
and periodic nature of communication, vehicles might have to send
some dozens of packets per second while at the same time receiving up
to a few thousand packets per second from neighboring nodes. This
corresponds to some dozens of signature generations per second and
some thousands of signature (plus certificate) verifications per
second. OBU hardware is not likely able to cope with this
cryptographic load, so usage of dedicated crypto-coprocessors is
likely. [SCHOCH-EFF-2010] outlines some other strategies to reduce
cryptographic load.
Cryptographic payload in messages (signatures, certificates,
metadata) must also not overload the communication medium. Based on
information from [REF 1602.2] security payload will increase packet
size by at least 181 bytes even when using space-efficient ECDSA.
Assuming message sizes of 200 bytes, this almost doubles the size of
a message. [SCHOCH-EFF-2010] also analyzes this and proposes
mitigation strategies.
Using standard IPsec techniques (ESP/AUTH headers and X.509
certificates) would aggravate this problem. However, work on space-
efficient IPsec variants, e.g. from the Wireless Sensor Network
domain, could be considered for adoption in IP-based vehicular
networks.
Overall, if one would adopt IP as a protocol for safety-related
messages in vehicular-networks, one would need to take into account
the issues raised above. This would require at least a modification
of IPsec plus introduction of additional security mechanisms like
pseudonymous identifiers and data-consistency checking. Note that for
communication with backend infrastructures via RSUs, IPsec can be
considered a mature solution to be applied.
8. IANA considerations
No IANA considerations apply to this document.
Karagiannis, et al. Expires August 25, 2010 [Page 20]
Internet-Draft Traffic safety applications requirements February 2010
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 proj. 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 August 25, 2010 [Page 21]
Internet-Draft Traffic safety applications requirements February 2010
[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
[SEVECOM-D2.1] A. Kung (ed.), "Security Architecture and Mechanisms
for V2V / V2I", SeVeCom Deliverable 2.1 v3.0, February 2008.
[SEVECOM-D2.1-APPA] F. Kargl (ed.), "Baseline Security
Specification", SeVeCom Deliverable 2.1 Appendix A v1.2, April 2009.
[PRECIOSA] PRECIOSA EU FP7 project website,
http://www.preciosa-project.org/, (visited February 2010).
[SCHOCH-EFF-2010] E. Schoch, F. Kargl, "On the Efficiency of Secure
Beaconing in VANETs", ACM Conference on Wireless Security (WiSec
'10), 03/2010.
Karagiannis, et al. Expires August 25, 2010 [Page 22]
Internet-Draft Traffic safety applications requirements February 2010
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
Carlos Jesus Bernardos
Universidad Carlos III de Madrid.
Avda de la Universidad, 30
E-28911 Leganes (Madrid)
Spain
Email: cjbc@it.uc3m.es
Frank Kargl
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
Email: f.kargl@utwente.nl
Karagiannis, et al. Expires August 25, 2010 [Page 23]