Vehicular Networking: A Survey and Tutorial On Requirements, Architectures, Challenges, Standards and Solutions
Vehicular Networking: A Survey and Tutorial On Requirements, Architectures, Challenges, Standards and Solutions
Vehicular Networking: A Survey and Tutorial On Requirements, Architectures, Challenges, Standards and Solutions
I.
INTRODUCTION
B. Requirements
Vehicular networking requirements are derived by studying
the needs of the vehicular networking applications and use
cases [12], [13], [15], [16], [19]. In this paper we use the
requirements classification given in [13]. In the following,
Section II.B.1 discusses these requirements classes, Section
II.B.2, based on [13], presents a number of system performance
requirements derived from the use cases given in Section II.A.
1) Classification of requirements
Vehicular network requirements can be grouped into the
following classes:
a) Strategic requirements
These requirements are related to: (1) the level of vehicular
network deployment, e.g., minimum penetration threshold and
(2) strategies defined by governments and commissions.
b) Economical requirements
These requirements are related to economical factors, such
as business value once the minimum penetration value is
reached, perceived customer value of the use case, purchase
cost and ongoing cost and time needed for the global return of
the invested financial resources.
c) System capabilities requirements
These requirements are related to the system capabilities,
which are:
a) Speed management
Speed management applications aim to assist the driver to
manage the speed of his/her vehicle for smooth driving and to
avoid unnecessary stopping. Regulatory/contextual speed limit
notification and green light optimal speed advisory are two
examples of this type.
b) Co-operative navigation
This type of applications is used to increase the traffic
efficiency by managing the navigation of vehicles through
cooperation among vehicles and through cooperation between
vehicles and road side units. Some examples of this type are
traffic information and recommended itinerary provisioning,
co-operative adaptive cruise control and platooning.
3) Infotainment Applications
Communication
mode
Minimum
transmission
frequency
Critical
latency
Intersection
collision
warning
Lane change
assistance
Periodic message
broadcasting
Minimum
frequency: 10 Hz
Less than
100 ms
Co-operation
awareness between
vehicles
Broadcast of
overtaking state
Minimum
frequency: 10 Hz
Less than
100 ms
Minimum
frequency: 10 Hz
Less than
100 ms
Broadcasting
messages
Minimum
frequency: 10 Hz
Less than
100 ms
Co-operation
awareness between
vehicles associated to
unicast
Periodic permanent
message broadcasting
Minimum
frequency: 10 Hz
Less than
100 ms
Minimum
frequency: 10 Hz
Less than
100 ms
Co-operation
awareness between
vehicles associated to
unicast
Time limited periodic
messages on event
Minimum
frequency: 10 Hz
Less than
100 ms
Minimum
frequency: 10 Hz
Less than
100 ms
Overtaking
vehicle
warning
Head on
collision
warning
Co-operative
forward
collision
warning
Emergency
vehicle
warning
Co-operative
merging
assistance
Collision
risk warning
Use case
Communication
mode
Minimum
transmission
frequency
Critical
latency
Regulatory
contextual
speed limit
notification
Periodic, permanent
broadcasting
of
messages
Minimum
frequency: 1 Hz to
10 Hz depending on
technology
Not
relevant
Green light
optimal
speed
advisory
Periodic, permanent
broadcasting
of
messages
Minimum
frequency: 10 Hz
Less than
100 ms
Communication
mode
Minimum
transmission
frequency
Critical
latency
Minimum
frequency:
Hz
Less than
200 ms
Co-operative
adaptive cruise
control
Cooperation
awareness
Minimum
frequency:
2
Hz
(some
systems require
25 Hz [71])
Less than
100 ms
Co-operative
vehicle-highway
automatic system
(platoon)
Cooperation
awareness
Minimum
frequency:
Hz
Less than
100 ms
Electronic
collection
toll
Communication
mode
Minimum
transmission
frequency
Critical
latency
Point of interest
notification
Periodic, permanent
broadcasting
of
messages
Minimum
frequency: 1 Hz
Less than
500 ms
ITS
electronic
commerce
Minimum
frequency: 1 Hz
Less than
500 ms
Minimum
frequency: 1 Hz
Less than
500 ms
local
Media
downloading
Communication
mode
Minimum
transmission
frequency
Critical
latency
Insurance
and
financial services
Access to internet
Minimum
frequency: 1 Hz
Less than
500 ms
Fleet management
Access to internet
Minimum
frequency: 1 Hz
Less than
500 ms
Communication
mode
Minimum
transmission
frequency
Critical
latency
Vehicle
software/data
provisioning and
update
Access to internet
Minimum
frequency: 1 Hz
Less than
500 ms
III.
Start /
End
years
Goals
Intellidrive / VII
(Vehicle
Infrastructure
Integration) [30]
2004 /
2009
Vehicle Safety
Communications
(VSC) [17]
2002 /
2004
Vehicle Safety
Communications
(VSC-A) [18]
2006 /
2009
CICAS
(Cooperative
Intersection
Collision
Avoidance
System) [34]
2004 /
2009
SafeTrip21
(Safe
and
Efficient Travel
through
Innovation and
Partnership for
the 21st century)
[35]
2008
ongoing
Accomplish
operational
tests
and
demonstration in order to accelerate the
deployment
of
near-market-ready
ITS
technologies that have the ability and the
potential to deliver safety and mobility
benefits.
PATH
(California
Partners
for
Advanced
Transit
and
Highways) [36]
1986 ongoing
V2V
communication
for safety [38]
2009
ongoing
This ITS plan has been based on the Basic Guidelines for the
Promotion of an advanced Information and telecommunication
Society, which was determined by the Advanced Information
and Telecommunication Society Promotion Headquarters in
February 1996. The five government bodies listed above,
recognized the need to develop a design that could respond to
changes in social needs and development in technology in the
future. In August 1999, these five government bodies jointly
released a first draft of the System Architecture for ITS. The
draft was released so as to collect opinions from the industrial
and academic sectors and to actively address the information
worldwide. In November 1999, the System Architecture for
ITS has been finalized.
Currently, the main public and private organizations that
influence the initialization, research, realization, and
standardization of ITS in Japan are the following organizations:
Start /
End
years
Goals
ETC
(Electronic Toll
Collection)
[44], [45], [46],
[47]
1993
ongoing
VICS (Vehicle
Information
and
Communication
System) [48],
[49]
1995 2003
Support
vehicle
to
infrastructure
communications using the communication radio
at 2.5. GHz frequency range.
Provide advances in navigation systems.
Assistance for safe driving.
Indirectly increasing
management.
efficiency
in
road
19972003
Smartway [52],
[51]
2004 /
2006
ASV
(Advanced
Safety Vehicle)
programme
[53], [54]
1991
on
going
ITS-Safety
2010: PublicPrivate
Cooperations
program [43]
2006
ongoing
Upper layer
PDU
Service
primitives +
NCP-SDU
Network control NCP-PDU
protocol
Extended link
protocol
ASL-PDU
Upper layer
protocol
Service
primitives +
NCP-SDU
Network control
protocol
Extended link
protocol
ARIB STD-T88
Service
primitives +
ASDU
DSRC layer 7
APDU
Service
primitives +
ASDU
DSRC layer 7
LPDU
DSRC layer 2
DSRC layer 1
MPDU
PHYPD
DSRC layer 2
DSRC layer 1
ARIB STD-T75
Start
/ End
years
Goals
NoW (Network
on Wheels) [69]
2004 2008
Start
/ End
years
Goals
Communications
for
eSafety
(COMeSafety)
[65]
2006 2010
SEVECOM
(Secure
Vehicular
Communication)
[70]
C & D (Connect
& Drive) [71]
2008 2011
COOPERS
(COOPerative
SystEMS
for
Intelligent Road
Safety) [72]
2006 2010
GeoNET [73]
2008 2012
SAFESPOT [66]
2006 2010
AIDE (Adaptive
Integrated
DrivervEhicle
interface)
2004 2008
APROSYS
(Advanced
protection
systems)
2004 2009
CVIS
(Cooperative
VehicleInfrastructure
Systems) [67]
2006 2010
HIDENETS
(Highly
dependable ipbased Networks
and
services)
[68]
2006 2008
2001 2004
Start
/ End
years
Goals
E-FRAME [75]
2008 2011
PRE-DRIVE
C2X
(Preparation for
driving
implementation
and evaluation
of
C2X
communication
technology) [76]
2008 2010
ROSATTE
(Road
Safety
attributes
exchange
infrastructure in
Europe) [77]
2008 2011
PRECIOSA
(Privacy enabled
capability in cooperative
systems
and
safety
applications)
[78]
2008 2010
Defines a privacy aware architecture for cooperative systems, involving suitable trust
models and ontologies, a V2V privacy
verifiable architecture and a V2I privacy
verifiable architecture.
API
A-SAP
Application layers
OSI layer 5, 6, 7
T-SAP
CALM
Management
N-SAP
Network layers
OSI layer 3, 4
C-SAP
M-SAP
D. Conclusions
The ITS vehicular networking standardization and research
activities in USA, Europe and Japan are severely progressing,
but they cannot be considered as completed. In Japan however,
the ETC infrastructure is deployed and the rollout of the
infrastructure for vehicle safety communications is ongoing.
These standardization and research activities are strongly
supported by the US states and European and Japanese national
governments, as well as the US federal administration and the
European Commission.
CALM
Networking
Layer
CALM Service
A-SAP
T-SAP
Radar
view
Congestion
control
manager
Fast
Networking
Georouting
ITSMUX
IR
congestion
node
MM
congestion
node
IPv6
Networking
N-SAP
M5
congestion
node
Other
congestion
node
C-SAP
M-SAP
CALM
M5
CALM
IR
CALM
MM
Other
media
CALM CI Layer
IV.
G. Delay constraints
Data packets sent by vehicular networking applications
usually have time and location significance. Primary challenge
in designing vehicular communication protocols is to provide
good delay performance under the constraints of vehicular
speeds, unreliable connectivity, and fast topological changes.
H. Prioritization of data packets and congestion control
Data packets carrying traffic safety and traffic efficiency
information usually have higher significance and therefore
should be forwarded faster than other packets. Majority of
the research activities have focused on how to provide the
highest priority to the emergency type of data packets. When
an emergency occurs, the channel utilization is likely to
degrade due to massive broadcast of emergency messages.
I.
4) Conclusions
Three geographical addressing families can be identified:
Application layer, GPS-multicast and Unicast IP routing
extended to deal with GPS addresses. The most promising, but
also the most complex one is the family that extends IP routing
3) Conclusions
The data centric trust and verification solutions can be
categorized in proactive and reactive. The proactive security
concept has been researched extensively. However, the tamperresistance-hardware used in a vehicle to e.g., detect
unnecessary accident warnings, needs to be further researched.
The reactive security concepts have been studied in a smaller
scale. More work is needed in the area of context verification,
where a vehicle is able to realize an intrusion detection system
by comparing received information on parameters associated
with status and environment with its own available
information.
D. Anonymity, privacy and liability
1) Anonymity and privacy
Pseudonyms should ensure that cryptographically protected
messages should not allow for their sender to be identified.
Furthermore, it should be difficult that two or more messages
generated by the same node should be linked together.
a) Linkability between pseudonyms
A possible issue associated with pseudonyms could be a
subject to a movement tracking attack.
However, if the lifetime of a public key is several minutes and
different vehicles update their public keys at different times,
then situations can be observed where consecutive messages
can be connected and thus the whole movement of a vehicle
can be traced. Two solutions can be identified that reduce the
movement tracking attack:
Silent period: of [120], is proposed to reduce the
linkability between the pseudonyms, or to create
groups and guarantee that the vehicles in a group
cannot listen to messages sent by vehicles from
another group.
been
proposed
for
secure
waiting for a fixed time period. The receiver nodes select the
waiting times based on the received signal power level.
Another protocol that was proposed in [173] is Advanced
Greedy Forwarding (AGF). It is an incremental improvement
of GPSR that considers speed and direction along with the
location information while discovering the neighbor nodes.
3) MAC Layer
The effectiveness of IEEE 802.11p amendment for traffic
safety applications which requires low delay, reliable, and real
time communication are analyzed in [174]. It has been
observed that CSMA/CA mechanism of 802.11p does not
guarantee channel access before a finite deadline, and
therefore, it gives poor performance. The authors of [174]
proposed a method known as self-organizing time division
multiple access (STDMA). STDMA is a decentralized system
where each vehicle determines its own slot assignment based
on its positions and neighbor's information. Such a technique
helps in predicting the channel access delay, making it suitable
for real-time ad-hoc vehicular networks.
Some researchers have explored the use of multiple
directional antennas for fast delivery of packets. For example,
RPB-MAC protocol [175] reduces the control message
overhead and guarantees minimum channel access delays by
making use of multiple antennas. A directional antenna with a
communication channel pair is dedicated for set of neighboring
vehicles depending on their positions relative to the source
vehicle. Since vehicles in different directions communicate
using different antennas, the number of channel collisions is
reduced. Furthermore, the transmission power is adaptively
adjusted to maintain the communication with its neighbors.
4) Physical Layer
The Incident Warning System (IWS) [176] utilizes direct
wireless communication to transfer a variety of packets
including traffic incidence reports, text messages, JPEG images
etc. They divided applications into three different categories
and identified specific requirements posed by applications in
each category. These requirements are handled by using two
different frequencies: long range frequency to reserve the
channel; and short range frequency to transmit the packets.
Power adaptation is another technique which researchers
have exploited to realize small end-to-end delays. Transmitting
power adaptation are discussed in several papers, see e.g.,
[177], [178], [179], [180], [181]. Only a subset of these
solutions will be discussed in this article. In [182], a vehicle
can monitor the radio channel conditions by calculating the
overhead sequence numbers. The receiving vehicle records the
successful packet deliveries sent by neighboring nodes which
uses the same radio channel and which are located within the
transmission and reception range of the receiving vehicle. By
identifying and counting the successfully received packets, the
receiving vehicle can detect failed packets and determine the
network condition, i.e., the average reception rate and the rate
of packets that were not successfully delivered. From this
analysis the receiver node can also calculate the minimum
number of nodes that are using the same radio channel. The
same vehicle can then use the calculated radio channel
conditions to adapt its transmission power accordingly. The
beaconing load adaptation mechanism described in [182] does
[3]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
[43]
[44]
[45]
[46] Akira Fujimoto, Koichi Sakai, Michiya Ogawa, Seiya Hamada, Satoru
Handa, Manabu Matsumoto, Kenji Takahashi, "Toward Realisation of
SMARTWAY In Japan", 15th World Congress on Intelligent
Transportation Systems (ITS WC08), 2008.
[47] Hideo Tsuji, ETC and Smartway in Japan, slides presented during the
2nd Thailand ITS Seminar 2007, 02 April 2007.
[48] Official web site of Vehicle Information and Communication System
(VICS)
Japan:
(website
visited
in
July
2010),
http://www.vics.or.jp/english/vics/index.html
[49] H. Amano, Intelligent Transport Systems for sustainable mobility:
Achievements in the past 10 years and integration for the future, slides
located at the website of the EU FP7 COJAK project, (website visited in
July
2010),
http://www.eurojapanict.org/ppts_forum_march/HajimeAmano.pdf
[50] Official website of the Advanced Cruise Assist Highway Systems
Research Association (AHSRA): (website visited in July 2010),
http://www.ahsra.or.jp/eng/index_e.htm
[51] M. Schultze, "International Initiatives Europe in Comparison to USA
and Japan", slides presented during the ESafety Workshop on Spectrum
Requirements for Road Safety, 28 February 2006 (visited in July 2010),
http://www.esafetysupport.org/download/european_events/2006/11_spe
ctrum_workshop_060228.pdf
[52] Website of the Smartway Project Advisory Committee: (website visited
in
July
2010),
http://www.mlit.go.jp/road/ITS/topindex/topindex_smartway.html
[53] Y. Furukawa, Overview of R&D on Active Safety in Japan, slides
presented in 2006 by Y. Furukawa: (website visited in July 2010),
http://www7.informatik.uni-erlangen.de/~dulz/fkom/06/Material/9/C2CCC_presentation_6_Furukawa.pdf
[54] I. Paromtchik, C. Laugier, The Advanced Safety Vehicle Programme,
Scientific Commons paper, 2007; (website visited in July 2010),
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.5579&rep
=rep1&type=pdf
[55] The Smartway project, slides that are introducing the SMARTWAY
project;
(website
visited
in
July
2010),
http://www.nilim.go.jp/japanese/its/3paper/pdf/051201wc_ss26.pdf
[56] ARIB standard, "DEDICATED SHORT-RANGE COMMUNICATION
SYSTEM", Version 1.0, ARIB STD - T75 (English translation),
Association of Radio Industries and Businesses (ARIB), Japan,
September 2001.
[57] ARIB standard, "DSRC APPLICATION SUB-LAYER", Version 1.0,
ARIB STD - T88 (English translation), Association of Radio Industries
and Businesses (ARIB), Japan, May 2004.
[58] COMeSafety deliverable D06, "D06 Standardization overview", Version
1.0, EU FP6 COMeSafety project (FP6-027377), deliverable D06, 10
August 2006.
[59] ERTICO website, http://www.ertico.com, (visited in July 2010).
[60] High Tech Automotive Systems (HTAS) website, http://www.htas.nl/,
(website visited in July 2010).
[61] European Council for Automotive R&D (EUCAR) website,
http://www.eucar.be, (website visited in July 2010)
[62] European
Safety
(eSafety)
website,
http://ec.europa.eu/information_society/activities/esafety/index_en.htm,
(visited in July 2010).
[63] CORDIS website, http://cordis.europa.eu/home_en.html, (visited in July
2010)
[64] Communication for eSafety (COMeSafety) EU FP6 project,
http://www.comesafety.org, (visited in July 2010).
[65] COMeSafety deliverable D31,"D31 European ITS Communication
Architecture Overall Framework Proof of Concept Implementation", EU
FP6 COMeSafety project (FP6-027377), deliverable D31, 22 October
2008.
[66] SAFESPOT EU FP6 project website, http://www.safespot-eu.org,
(visited in July 2010).
[67] CVIS EU FP6 project website, http://www.cvisproject.org, (visited in
July 2010).