Vehicle-to-Vehicle Safety Messaging in DSRC
Qing Xu
*
Raja Sengupta
†
*
Department of Mechanical Engineering
†
Department of Civil and Environmental Engineering
University of California
Berkeley, CA 90720–1740
Email:
*
qingxu@me.berkeley.edu
†
raja@path.berkeley.edu
Tony Mak
Jeff Ko
California Partners of
Advanced Transits and Highways (PATH)
Richmond, CA 94804-4603
Email: {tonykm, jko}@path.berkeley.edu
Abstract— This paper studies the design of layer-2
protocols for a vehicle to send safety messages to other
vehicles. The target is to send vehicle safety messages
with high reliability and low delay. The communication
is one-to-many, local, and geo-significant. The vehicular
communication network is ad-hoc, highly mobile, and with
large numbers of contending nodes. We design several
random access protocols for medium access control. The
protocols fit in the DSRC multi-channel architecture.
Analytical bounds on performance of the addressed pro-
tocols are derived. Simulations are conducted to assess the
reception reliability and channel usage of the protocols.
The sensitivity of the protocol performance is evaluated
under various offered traffic and vehicular traffic flows.
The results show our approach is feasible for vehicle safety
messages in DSRC.
I. INTRODUCTION
Dedicated Short-Range Communications (DSRC) is
75 MHz of spectrum at 5.9 GHz allocated by the Fed-
eral Communications Commission (FCC) to “increase
traveller safety, reduce fuel consumption and pollution,
and continue to advance the nation’s economy [7].” It is
a promising development supporting vehicle to vehicle
and vehicle to infrastructure communication using a vari-
ant of the IEEE 802.11a technology [1]. DSRC would
support safety-critical communications for say collision
warnings, as well as other valuable ITS applications
such as Electronic Toll Collection (ETC), digital map
update, etc. The versatility of DSRC greatly enhances
the likelihood of its deployment by various industries
and adaptation by the consumers.
The 2004 FCC ruling [8] specifies DSRC will have six
service channels and one control channel. The control
channel is to be regularly monitored by all vehicles.
Safety messages, whether originated by vehicles or road-
side transmitters, are to have priority over non-public
safety communications. Therefore all safety messages
are to be sent in the control channel. In the meantime, a
licensed roadside unit could use the control channel to
inform approaching vehicles of its services (often non-
safety applications) and conduct the actual application in
one of the service channels. For example, a roadside unit
could announce a local digital map update in the control
channel and transfer this data to interested vehicles in a
service channel.
Table I illustrates the sort of DSRC data traffic
characteristics being used in the standards delibera-
tions [6] [12] [19]. The FCC has recognized safety
messages and “safety of life” messages. Safety of life is
to have the highest priority. The non-safety data transfers
have the lowest priority. The non-safety communications
happen for file transfers (e.g., infotainment) or transac-
tions (e.g. toll collection). Transactions may require the
exchange of two or three messages within a short time
window (e.g., 20 msec).
This paper explores the feasibility of sending safety
messages from vehicle to vehicle in the DSRC control
channel. Safety messages are time sensitive. When vehi-
cles send safety messages to each other while travelling
at high speed, can they be received with small delay
and high probability? Cellular networks achieve time
sensitive communication at high speeds. But they do
so with the aid of base stations. These are significantly
more expensive than their supposed DSRC equivalent,
i.e., 802.11 access points. Moreover, cellular handles
only infrastructure to mobile communication. Can DSRC
handle time and loss sensitive vehicle-vehicle commu-
nication? Can it do so without infrastructure, i.e., in
ad hoc setting? Will there be enough room on the
control channel for the other non-safety communications
required by DSRC, e.g., service announcements? After
all, if the announcements are crowded out the remaining