vehicular communication systems: enabling technologies ...papadim/publications/... · plex systems...

IEEE Communications Magazine • November 200984 0163-6804/09/$25.00 © 2009 IEEE

INTRODUCTIONThe growing mobility of people and goods incurshigh societal costs: traffic congestion, fatalitiesand injuries. In the past decade, numerousefforts have sought to mitigate these problemsand produced solutions we currently use, forexample: information on traffic and hazardoussituations are broadcast via the FM radio band,temporarily interrupting the user-tuned recep-tion; variable message signs, spaced a few kilo-meters apart or at strategic points (e.g., merginghighways, tunnels, bridges) along freeways, warndrivers about changing conditions; electronic tollsystems collect fees with reduced or almost nodisruption of traffic flow.

At the same time, vehicles have increasinglyeffective driver assistance and protection mecha-nisms. Various onboard controls and informa-tion sources allow the driver to customize herdriving experience and remain up to date on thevehicle status; passive safety mechanisms protectthe passengers and the vehicle against adversedriving conditions (e.g., anti-lock braking sys-tems); navigation systems, compasses, rear andfront parking radars, and cameras are the most

common among autonomous sensor technolo-gies. They perceive the landscape, road, andvehicle location, and capture in real time thevehicle surroundings and traffic situation toappropriately warn the driver and either preventaccidents or at least reduce their effects. Beyondthese technologies, relying on heterogeneoustechnologies (e.g., roadside cameras), more com-plex systems enable fleet management and thecollection of traffic information.

Recent technological developments, notablyin mobile computing, wireless communication,and remote sensing, are now pushing intelligenttransportation systems (ITS) toward a majorleap forward. Vehicles are already sophisticatedcomputing systems, with several computers andsensors onboard, each dedicated to one part ofthe car operation. The new element is the addi-tion of new wireless communication, computingand sensing capabilities. Interconnected vehiclesnot only collect information about themselvesand their environment, but they also exchangethis information in real time with other nearby(in principle) vehicles.

To put it simply, radio-communication-basedsolutions can operate beyond the line-of-sightconstraints of radar and vision solutions, andthey can enable cooperative approaches. Vehiclesand infrastructure cooperate to perceive poten-tially dangerous situations in an extended spaceand time horizon. Appropriate vehicular commu-nication (VC) architectures are necessary to cre-ate reliable and extended driving support systemsfor road safety and transportation efficiency.

This article contributes a survey of VC sys-tems, covering the developments of the past fewyears. We cover the state of the art, and we dis-till the technical details from a wide range ofresearch and development projects. Rather thanan architectural view alone, we seek to captureconcisely and quantitatively the most up-to-dateunderstanding in industry and academia.

ABSTRACTNumerous technologies have been deployed

to assist and manage transportation. But recentconcerted efforts in academia and industry pointto a paradigm shift in intelligent transportationsystems. Vehicles will carry computing and com-munication platforms, and will have enhancedsensing capabilities. They will enable new versa-tile systems that enhance transportation safetyand efficiency and will provide infotainment.This article surveys the state-of-the-art approach-es, solutions, and technologies across a broadrange of projects for vehicular communicationsystems.

TOPICS IN AUTOMOTIVE NETWORKING

Panos Papadimitratos, EPFL

Arnaud de La Fortelle, Mines ParisTech

Knut Evenssen, Q-Free ASA

Roberto Brignolo and Stefano Cosenza, Centro Ricerche FIAT

Vehicular Communication Systems:Enabling Technologies, Applications,and Future Outlook on Intelligent Transportation

PAPADIMITRATOS LAYOUT 10/19/09 12:36 PM Page 84

We first provide an overview of VC systemsand their role in intelligent transportation sys-tems, along with a summary of the related majoractivities to date. Then we present onboardequipment, the VC wireless data link technolo-gies, the VC networking protocols, and the VC-enabled applications. We conclude with adiscussion of the next steps in the evolution ofVC systems.

OVERVIEWVehicles will be equipped with novel computing,communication, and sensing capabilities, and userinterfaces. These will support a spectrum ofapplications that enhance transportation safetyand efficiency, but also provide new or integrateexisting services for drivers and passengers. Asignificant role is envisioned for existing orupcoming wireless infrastructure (e.g., cellular),connectivity to the wireline part of the Internet,and dedicated roadside infrastructure units(RSUs). User-portable devices are also expectedto be wirelessly attached to the onboard equip-ment.

A key aspect of VC systems is to expand thetime horizon of information relevant to drivingsafety and transportation efficiency, introducenew information sources, and improve its quali-ty. The basis is a collaborative approach, witheach vehicle and RSU contributing relevantinformation, as illustrated in Fig. 1: based ontheir own sensing and on information receivedfrom nearby peers and RSUs, vehicles can antic-ipate, detect, and avoid dangerous or unwantedsituations. For example, timely notificationsabout lane changes, emergency braking, andunsafely approaching vehicles can be highly ben-eficial. The same is true for notifications aboutdangerous or heavy traffic conditions disseminat-ed by RSUs, locally or within a larger regionwith the help of other vehicles.

The development of such VC systems andrelated technologies has been the subject ofnumerous projects around the globe, as well asfor standardization working groups and industri-al consortia. We summarize the large majority ofsuch recent efforts in Table 1, with projects hav-ing complementary but often similar objectivesand approaches. The table summarizes the objec-tives of each project, consortium, or initiative,along with its duration and context.

This multitude of concerted efforts andapproaches indicates the need for coordination.Cooperative system projects in Europe, notablythose represented in the COMeSafety initiative,have converged on a common reference archi-tecture, shown in Fig. 2, with direct involve-ment from the European TelecommunicationsStandards Institute (ETSI) TC ITS and theInternational Organization for Standards (ISO)TC204 WG16 (ITS Communications). It hastherefore been adopted quite widely in Europe,and in several cases outside Europe. The archi-tecture is described in [1], and a concise surveyis given in [2].

Simply speaking, wireless transmission andmedium access technologies adapted to the VCenvironment are the primary enabling technolo-gy. Conceptually, on top of them, networking

technologies allow for data exchange amongnearby and remote devices (vehicles, RSUs, andother servers). They, in turn, support the afore-mentioned range of applications, with the medi-ation of a range of facilities, that is, functionalitythat extracts data (mostly location- and time-stamped) from the network operation and estab-lishes sessions between two VC system entitieswhen necessary. The basic system entity is anITS station, which can be composed of a routerand a host, or be a single-box implementationthat covers all functions. One example is thetop-level architecture of the CVIS project shownin Fig. 3.

ONBOARD EQUIPMENTThe VC computing, communication, and sensingequipment and user interfaces will be, in mostcases, new with respect to the current onboardequipment. In terms of sensing and user inter-face hardware and software, VC systems willleverage on the array of equipment vehicles cur-rently carry; for example, data concerning thevehicle operation will be obtained via the corre-sponding or upgraded onboard interfaces. Ingeneral, VC technology will not be developedfrom scratch; rather, as ongoing projects show,mature and well understood components andtheir variants will be the basis. In the rest of thissection we outline the characteristics of theonboard equipment as it is currently developedand integrated.

VC computing platforms are to be dedicatedto VC functionality. Recall that cars are alreadyequipped with multiple processors and micro-controllers dedicated to tasks such as fuel injec-tion, braking, transmission, and battery charging;for easy reference, we term these car processorsand controllers. The VC computing platform(s)will be functionally independent and responsiblefor running the vehicle-to-vehicle (V2V) andvehicle-to-infrastructure (V2I) communicationprotocols and the supported applications.

The current approach is to use commercialoff-the-shelf computing technology with goodperformance and flexible interfaces. There aredifferences with existing desktop and laptop

IEEE Communications Magazine • November 2009 85

Figure 1. Illustration of VC system functionality. Safety applications leverage onvehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication,to extend the driver's horizon and offer early detection of perilous situationsand notify the driver accordingly. It is currently debated whether some auto-mated control action should be taken in future systems, for example, to ensurethe avoidance of a collision without the intervention of the driver.

Safe distance and speed

Collision mitigation Collaborative

warning

Blind spot Rear detection

Lane support

Side crash

Lane change

assistant

Infrastructure-based warningroadside equipment(local or remote)


IEEE Communications Magazine • November 200986

Project name

Project information

Period Externalfunding Brief description of objectives

AKTIV 2006–2010

Ministry ofEconomics andTechnologyGermany

Design, development, and evaluation of driver assistance sys-tems, knowledge and information technologies, efficient trafficmanagement, and V2V and V2I communication;http://www.aktiv-online.org/index.html

Car to CarCommunicationConsortium(C2C-CC)

Ongoing N/A

Development of a European industry standard for VC communi-cation systems, active safety applications prototyping anddemonstrations, harmonization of VC standards worldwide,realistic deployment strategies and business models;http://www.car-2-car.org/

CityMobil 2006–2010 European UnionIntegration of automated transport systems in the urban envi-ronment, based on real-life implementations; http://www.citymobil-project.eu/

COM2REACT 2007–2008 European UnionDistributed traffic application, based on cellular and V2V com-munication, in-car and V2V communication systems, vehicle-to-center communication; http://www.com2react-project.org/

COOPERS 2006–2010 European UnionTelematic applications for the road infrastructure, cooperativetraffic management involving vehicles and roadside infra-structure; http://www.coopers-ip.eu/

CVIS 2007–2011 European Union

Multichannel terminal capable of continuous Internet connec-tion, open communication architecture, enhanced positioning,commercial applications, toolkit (models, guidelines, and recom-mendations), and deployment roadmaps;http://www.cvisproject.org/

CyberCars2 2006–2008 European UnionCooperation between vehicles running at close range (platoon-ing) and at intersections (merging, crossing); http://www.cybercars.org

CyberMove 2001–2004 European UnionInvestigation toward new transportation systems based onCyberCars (automated vehicles) as a complement to public masstransportation; http://www.cybermove.org

ETSI TC ITS Ongoing N/AStandardization activities to support the development andimplementation of intelligent transportation systems; http://por-tal.etsi.org/Portal_Common/home.asp

EVITA 2008–2011 European UnionSecure and trustworthy intravehicular communication; architec-ture for automotive onboard networks to thwart tampering andprotect sensitive data inside a vehicle; http://evita-project.org/

GeoNet 2008–2009 European UnionSpecifying, developing and testing IPv6 geo-networking thatcan be used within a cooperative architecture (e.g., CVIS);http://www.geonet-project.eu/

HAVE-IT 2008–2011 European UnionAutomated merging, queue assistance, temporary auto-pilot,and active green driving mechanisms, integrated in six demon-strator vehicles; http://www.haveit-eu.org

Table 1 continued on next page....



Table 1. Summary information on representative VC projects, consortia, and working groups.

Project name

Project information

Period Externalfunding Brief description of objectives

IEEE P1609 Ongoing N/A

Standard for wireless access in vehicular environments (WAVE)— Resource manager, physical and medium access control,security services, networking services, multichannel operationsfor V2V and V2I communication;http://www.standards.its.dot.gov/fact_sheet.asp?f=80

ISO TC 204WG16/CALM Ongoing N/A

Standardized set of air interface protocols and parameters formedium- and long-range high-speed ITS communication, acrossseveral media, networking, and upper layer protocols;http://www.isotc204wg16.org/

NoW: Network onWheels 2004–2008

Ministry of Edu-cation andResearch Ger-many

Protocols and data security algorithms for V2V/V2I communica-tion, active safety scenario, V2I electronic payment, introductionstrategies, and business models;http://www.network-on-wheels.de/

PATH Ongoing

CaliforniaDepartment ofTransportation(CalTrans)

Multidisciplinary research program administered by the UCBerkeley Institute of Transportation Studies and CalTrans; activi-ties in four areas: policy and behavioral, transportation safety,and traffic and transit operations research;http://www.path.berkeley.edu/

SAFESPOT 2006–2010 European UnionAd hoc networking, accurate relative localization, dynamic localtraffic maps; scenario-based evaluation of safety applications;sustainable deployment strategy; http://www.safespot-eu.org/

SEVECOM 2006–2009 European Union

Security architecture for vehicular communication systems; iden-tity management, security and privacy-enhancing mechanismsand protocols; in-car protection; data consistency; system per-formance evaluation; demonstration; http://www.sevecom.com

SmartWay 2006–2010

Ministry of Land,Infrastructure,Transport andTourism Japan

Driving safety support systems based on vehicle–highway coop-eration; http://www.mlit.go.jp/road/ITS/

IntelliDrivePreviously knownas the VIIconsortium (VIIC)

Ongoing2005–2008

Department ofTransportationUSA

Initiative of the ITS Joint Programs Office (JPO) at the DoT’sResearch and Innovative Technology Administration (RITA) VCtechnologies and applications, V2V, V2I, mobility, and policyresearch; http://www.intellidriveusa.org/

VSC 2002–2004Department ofTransportationUSA

DSRC demonstration and safety beaconing for V2V and V2Icommunication

CAMP/VSC-2 2005–2009Department ofTransportationUSA

Cooperative Intersection Collision Avoidance System — Viola-tions (CICAS-V); Emergency Electronic Brake Lights (EEBL); Vehi-cle Safety Communications — Applications (VSC-A)


machines: Car PCs have relatively hardenedhardware and adapted packaging so that opera-tion is possible in a wider range of conditionsand according to the VC constraints. In addi-tion, car PCs have the appropriate interface tothe rest of the in-vehicle information system,which is essentially the control area network(CAN) or other technology (e.g., LIN, MOST,or Flexray) that interconnects car processorsand controllers [3].

Figure 4 illustrates one approach along theselines, as developed by the CVIS project. Ratherthan having one car PC, there are two boxes:one performing all networking operations andacting as the interface to the car processors andsensors (termed the mobile router), and onedoing all the computing for the VC applicationsand the user interface (termed the mobile host).The mobile router integrates a special-purposecard that integrates sensors and resolves, at thehardware level, time-critical tasks such as thereal-time acquisition of location and time andsynchronization. The use of two boxes appears inother projects too (e.g., the COM2REACT plat-form).

Sensing equipment is already installedonboard; thus, a CAN gateway is present toobtain data from onboard sensors, typicallyvelocity, direction, temperature, airbag status,rear and front cameras, parking assistanceradars, and so on. At the same time, global navi-gation satellite ssystems (GNSS) such as theGlobal Positioning System (GPS) can also beintegrated, along with other advanced systems,such as collision warning or advanced cruise con-trol radars.

The accuracy of location and time dependson the GPS receiver and its signal processingcapabilities. For example, small-footprintreceivers can achieve 10–15 ns synchronizationand localization errors of 6–30 m. There areother GNSS solutions, such as the Russian coun-terpart of GPS that is compatible with the U.S.-built GPS, and the upcoming European Galileosystem (currently with one operational satellitewhile the rest of the constellation is beingdeployed).

The COM2REACT project integrated a CANgateway, a GPS, a camera, and ultrasoundtransceivers. The CVIS project developed a spe-cial sensor card (mentioned above as part of the


Figure 3. System architectural view, as per the CVIS approach. Roadside and onboard equipment commu-nicate; the roadside equipment provides access to information stored in a number of databases and serversrelated to the VC system, but also to the user's home equipment through mobile IPv6 connectivity.

Homeagent

Internet

Service centre

Authority databases

Control centre

VHS

Control Sensor

Antenna

Antenna

Sensor Sensor

Control

Host network

Calm network

Control

Roadside gateway

Roadside host

Border router

Access router

Mobile router

Vehicle host

Vehicle gateway

Gateway CentralhostBorderrouter



Roadside system Central system

Vehicle system

Figure 2. Common reference architecture for cooperative vehicular communi-cation systems, as agreed primarily among European projects.

Man

agem

ent

Secu

rity

Applications

Facilities

Networkingand transport

Accesstechnologies



mobile router PC). The card provides GPS datafor accurate time and position, an inertial sensorpackage with gyroscope and accelerometers, andan interface to the vehicle CAN-bus. The provid-ed real-time processing and time stamping isimportant for the networking and applicationprotocols described later in this article. Similarefforts, in terms of extracting information safety-related sensory measurements from the in-vehi-cle system, are undertaken by SAFEPROBE, asubproject of SAFESPOT.

The communication equipment comprises aset of technologies with different characteristics(bit rates, communication range, transmissionpower, frequency bands). Basically, there isshort-range ad hoc communication to enable pri-marily V2V but also V2I communication, andlong-range infrastructure-based communicationprimarily for V2I purposes. Finally, there is theoption of integrating additional long-rangebroadband transceivers, including broadcastreceivers.

The basis of VC systems is a variant of thewidely known Wi-Fi technology, the IEEE802.11p protocol [4]. The correspondingtransceivers provide for a wireless data link, dis-cussed in the next section, as the basis of theshort-range ad hoc communication. Cellular datatransceivers provide for long-range communica-tion: typically, Global System for Mobile Com-munications (GSM)-based General Packet RadioService (GPRS) transceivers, as well as third-generation Universal Mobile Telecommunica-tions System (UMTS) transceivers. Moreover,

dedicated transceivers (e.g., for deployed tollcollection systems — dedicated short-range com-munication [DSRC]) can also be present.

The frequency allocation for this communica-tion equipment can differ from continent to con-tinent and possibly from country to country.Regarding the newly introduced 802.11p, alsoknown as the encompassing effort of WAVEand the related IEEE 1609 working group activi-ties, there are specific bands allocated for V2Vand V2I communication.

The CVIS platform (Fig. 4) has GSM andUTMS interfaces, a dedicated DSRC transceiv-er, a GSM/UMTS transceiver supporting all datamodes, and short-range 802.11p radios that aresynchronized with European DSRC toll collec-tion systems. The 802.11p radios offer communi-cation (in the European 5.9 GHz band) alongwith the previous versions of the protocol (i.e.,IEEE 802.11 a/b/g), and an implementation ofthe IEEE 1609 stack and support for parallelprotocol stacks (based on the CALM architec-ture). Similarly, SAFESPOT builds on the IEEE802.11p radios and looks into possible integra-tion of other technologies (cellular or infraredcommunication); COM2REACT used Wi-Fi802.11b with GPRS.

WIRELESS DATA LINKAs explained earlier, vehicles are envisioned tocarry multiple types of wireless transceivers; thatis, each vehicle will be able to communicateacross more than one wireless data links. Each

Figure 4. Onboard vehicular communication (VC) system equipment: computing platforms (mobile router and mobile host); communi-cation equipment, with multiple wireless data links (e.g., 802.11p, cellular) and broadcast receivers (e.g., GPS); sensors; and in-vehicleuser interface.

Mobile router Mobile host

AntennaTouch display

CVIS sensor and M5 cardGyro

Accelero-meter

20chGPS

OBD-IICAN bus

CENDSRC

FPGA: PCI, serial ports andsoftcore CPU

Realtime GPS and DSRC sync,sensor fusion/timestamp

2.5/5 GHz802.11 radiosmodified for:-Euro 802.11p-DSRC RT sync-GPS time sync

2-5 GHzantenna 1

GPSantenna

CEN DSRCantenna

2-6 GHzantenna 2

GSM/UMTSantenna



of them provides a physical layer, the implemen-tation of methods to transmit and receive data(symbols representing bit sequences) across theairwaves, and a medium access control layer,protocols that regulate how collocatedtransceivers access (i.e., transmit and receiveacross) the wireless medium, in order to reducethe chance of or avoid collisions (transmissionsoverlapping in frequency and/or time).

In Table 2, we summarize indicative values fora set of characteristics of and information on themain wireless data links currently developed andintegrated in automotive systems. Beyond opera-tional characteristics (e.g., bit rate, range, band-width), we also point out which standards pertainto each technology. Interested readers arereferred to the documentation of the correspond-ing standardization bodies for more information.

An important aspect, medium access controllatency, is not listed in the table as it dependsgreatly on the implemented system and context.Infrastructure-based communication may requiredelays on the order of seconds, including theassociation of a mobile transceiver with an infra-structure element, and the registration with thenetwork that grants access rights; this may be,for example, the case for Wi-Fi and cellular sys-tems. Nonetheless, customized implementationsof 802.11-based systems allow for very fast asso-ciation with a Wi-Fi access point, while fasthandover techniques allow cellular systems toservice nodes moving fast from one base stationto another. For transportation safety applica-tions, low-latency communication with neighbor-ing devices is critical; this favors direct V2Vcommunication through a simple medium accesscontrol protocol.

The prominent wireless data link for VC is avariant of IEEE 802.11, 802.11p. This specifiesphysical and medium access control protocolsdesigned with the highly volatile vehicular envi-ronment in mind. The operation across multiplechannels is specified in IEEE 1609.4. These twoelements, combined with a resource manager forthe onboard equipment, and specifications ofaddressing, networking, and security services, areknown collectively as the WAVE standard; for arecent tutorial, see [5].

NETWORKING PROTOCOLSBeaconing is a simple mechanism, used inscores of other networks, to periodically trans-mit short messages (i.e., a one-hop or localbroadcast). Beacons have a special role in VCsystems: they provide the identity and richinformation on the transmitting vehicle (e.g.,location, heading, and other status information)with typical size on the order of 100 bytes. Theyare transmitted at high frequencies (e.g., 10times per second) by each vehicle and in anuncoordinated manner. They are the backboneof the cooperative awareness and other trans-portation safety applications discussed in thenext section.

Beacons are transmitted across the802.11p/WAVE data link and are typicallyhandled as broadcast packets at the mediumaccess control layer. Beaconing can also beevent-driven local broadcasts, perhaps repeat-ed for a protocol-specific period (e.g., a safety-related warning triggered by an in-vehicleevent). Safety-related beacons must arrive atneighbor nodes within a specific maximum

Table 2. Summary information on representative VC wireless data links.

Indicative wireless data linkcharacteristics

Technology

802.11p WAVE Wi-Fi Cellular Infrared

Bit rate 3–27 Mb/s 6–54 Mb/s < 2 Mb/s < 1 Mb/s< 2 Mb/s

Communication range* < 1000 m < 100 m < 15 km < 100 m (CALM IR)

Transmission power formobile (maximum)

760 mW (US)2 W EIRP (EU) 100 mW

2000 mW (GSM)380 mW (UMTS) 12800 W/Sr pulse peak

Channel bandwidth 10 MHz20 MHz 1–40 MHz25 MHz (GSM)60 MHz (UMTS) N/A (optical carrier)

Allocated spectrum 75 MHz (US)30 MHz (EU)50 MHz @ 2.5 GHz300 MHz @ 5 GHz (Operator-dependent) N/A (optical carrier)

Suitability for mobility High Low High Medium

Frequency band(s) 5.86–5.92 GHz 2.4 GHz, 5.2 GHz800 MHz, 900 MHz1800 MHz1900 MHz

835–1035 nm

Standards IEEE, ISO, ETSI IEEE ETSI, 3GPP ISO

*The communication range depends on parameters such as data rate, power, bandwidth, and topography; values given in this table areestimates and may vary.



delay, and their reception should be possiblewith minimum reliability, as per the applica-tion requirements.

At this point, VC implementations do notattempt reliable broadcast, but rather take verysimple best effort approaches that rely on redun-dant transmissions. Under highly congested set-tings, with 100 vehicles within range, thereception reliability can be rather low (e.g., 60percent of transmitted beacons); however, eachvehicle transmits a beacon every 10 ms, so withina fraction of second, even after several lost bea-cons, reception is possible.

Flooding is the natural extension of beaconingacross multiple wireless hops. Packets specify atime to live (i.e., a number of hops to be relayedacross), or their type and content allow receiversto determine whether to rebroadcast them.Eventually, flooded packets are removed fromthe network after covering (approximately) theintended area. As it is the initial sender’s infor-mation that is essential, the relaying nodes ofpackets flooded in a controlled manner do notneed to modify them. This implies that their sizeas they propagate across the network would notincrease. The same would be true if nodes per-formed some sort of aggregation, with relayingnodes adding, for example, their measurementto an average or a maximum or minimum of thevalues of nodes involved in protocol execution.

GeoCast or position-based routing assumesthat every node knows its geographical position(e.g., by GPS) and maintains a location tablewith the geographical positions of other nodes assoft state. Individual nodes can be addressed

based on their geographical location, and agroup of nodes can be designated as receiverswithin a geographical region. Such functionality,also investigated in the more abstract context ofad hoc networks, fits naturally into VC systems:• Vehicles are already integrating navigation

systems (e.g., GPS), and are expected to belocation-aware.

• Many transportation safety and efficiencyapplications are location-specific.

VC is, in fact, closer to GeoCast than to theusual Internet unicast [6].

The choice of a geographic region as a desti-nation for a message is clearly independent ofthe size of the network (i.e., the number of vehi-cles present). Individual vehicle addressing,which requires sufficiently accurate knowledgeof the destination location, is expected to be asmall fraction of the overall traffic. These twoaspects indicate that appropriate GeoCast proto-cols could remain efficient as the scale of VCsystems grows.

The basic components of GeoCast are:•Beaconing, for discovery of neighbors and theirlocations•A location service, which can be queried to pro-vide the location of individual nodes•Position-based forwarding toward a given desti-nation (geographic location in general, whichcan be narrow or broad in region)

The maintenance of a neighborhood — infor-mation on the set of other vehicles and roadsideunits within range, along with position and allother relevant information — can be done invarious ways. For example, unreliable links can

Figure 5. Illustration of networking protocols for VC systems. Top: Internet connectivity via roadside andother infrastructure, and vehicle-to-infrastructure communication; bottom: vehicle-to-vehicle communica-tion, for communication with neighboring devices (directly reachable vehicles and roadside infrastructure),as well as devices across multiple hops and geographically remote.

Source (S) Destination (D)

Forwarder 2 (F2)

Forwarder 1 (F1)

Server

Beaconing/ cooperative awareness

Unicast V2V

AP1 AP2 AP3

Beacons are

transmitted across

the 802.11p/WAVE

data link and are

typically handled as

broadcast packets at

the medium access

control layer.

Beaconing can also

be event-driven local

broadcasts, perhaps

repeated for a

protocol-specific

period.



be disregarded (e.g., if a vehicle appears to moverelatively fast with respect to a sender, or thedata link reports a high number of retries), orneighbors are nodes that appear more relevant(i.e., have the same heading, e.g., are in thesame highway flow).

The goal of the location service is to resolvethe identity of a vehicle to its current position.This could be done with the help of a facility thatmaintains locations of vehicles that need to beindividually addressed. The instantiation of such afacility can be based on the infrastructure (whichcan be reached across one or more wireless hops),or done in a peer to peer manner with the loca-tions distributed across nodes. Access to such afacility or possibly to the sought vehicle can bedone with a traditional query: a packet is floodedin a controlled manner, requesting the destination,with any authorized and knowledgeable node(RSU or vehicle) responding with the requiredlocation .information. Location queries andresponses are small-size packets, at most the samesize as beacons, at on the order of 100 bytes.

Position-based forwarding relays each packetfrom its source to the destination location, basedwith individual decisions made at each relayingnode based on knowledge about the neighbor-hood. The objective is to get the packet toapproach the destination at each relaying step:the source and each relay choose the next hopthat is closest to the destination. This is the basicidea of greedy forwarding, which under somecircumstances can be ineffective: there may beno next hop closest to the destination, and inthat case a gap avoidance algorithm is invoked.Once the packet is in the destination region,nodes within the region locally broadcast thepacket. As these are data packets, their payloadcan be on the order of several hundreds of bytes.Their control overhead (i.e., their headers) doesnot need to grow with the size of the network;they only need to specify the destination, usedby all relaying nodes, and the next hop.

The Car-2-Car Communication Consortium(C2C-CC) has invested significant efforts on thespecification of car-to-car communication mech-anisms suitable for safety applications, includinggeonetworking (or GeoCast). GeoNet is a Euro-pean Union funded project that aims at ensuringconvergence between IPv6 and proprietary geo-networking protocols, particularly C2C-CC’sgeonetworking (Fig. 5).

Connectivity with the Internet is in generalrequired, and it can be achieved with the vehicleestablishing sessions with Wi-Fi access pointswhen in range and down- or uploading possiblylarge volumes of data within a short period oftime, notably during contact with (i.e., the peri-od of being in range of) an access point. Ofcourse, Internet connectivity can also beachieved via the cellular GSM/GPRS or UTMSsystems, which already have very high coverage.Internet connectivity can be infrequent to sup-port various VC-specific transactions and tasks,but it could also be established, independent oftransportation-related issues, for infotainment.

Ongoing projects such as CVIS are develop-ing a communication architecture that relies onthe maintenance of constant access to the Inter-net over IPv6. GeoNet ensures convergence

between geonetworking and IPv6. The goal ofGeoNet is to implement and formally test ageonetworking mechanism as a standalone soft-ware module that can be incorporated into coop-erative systems. GeoNet is very active instandardization and will integrate its moduleinto the CVIS platform so that future projectson cooperative systems can maintain their focuson architecture design, application development,and field trials.

APPLICATIONSVC systems will enable applications in three pri-mary directions: transportation safety, trans-portation efficiency, and user services deliveredto the vehicle. The first two categories are themain two drivers for the development of the newsystems. The third category leverages on thenewly coined and existing systems; in many casesit can naturally blend into the VC and ITS con-texts, and can act as a market driving force.

Projects, standardization bodies, and consor-tia around the globe have been working on thedesign and development of applications for VCsystems. Long lists of applications were initiallycompiled, projecting into future technologies butalso drawing on existing transportation require-ments and functionality, looking into how VCscan undertake and enhance support for those.The vast majority of applications fall largely inthe above-mentioned three categories:• The driver is assisted, in order to enhance

transportation safety.• Data, most often region-specific, about the

transportation system and traffic conditionsare made available to drivers to enhancetransportation efficiency.

• Services enhance the users’ (passengers anddrivers) comfort and ability to perform per-sonal and business transactions while in thevehicle.In Table 3 we provide a representative list of

applications from these three categories. Namesdo not exactly match those used in each andevery project, but rather they are closely compat-ible with those used by many projects and con-sortia (e.g., C2C-CC, VSC-A), standardizationefforts (e.g., ETSI, IEEE), as well as thosebroadly used (e.g., SAFESPOT, CVIS,COM2REACT, SEVECOM).

We provide a list of five pieces of informa-tion for each application:• Communication, which determines the wire-

less data link needed, with ad hoc and infra-structure-based referring earlier in thearticle

• Messaging type, which specifies whether thetransmission is periodic, event-triggered,limited over a short period, and so on

• Message period, applicable to periodic mes-saging applications

• Critical latency, the maximum delay theapplication requires from the underlyingprotocol stack to handle and transmit themessage

• Other requirements, such as the priority atthe medium access control layer, the accu-racy of positioning, maximum recommend-ed communication range, and so on

VC systems will

enable applications

in three primary

directions:

transportation safety,

transportation

efficiency, and user

services delivered to

the vehicle. The first

two categories are

the main two drivers

for the development

of the new systems.



Among hundreds of use cases, we chose here asubset of applications to illustrate differingrequirements. We do not propose values for eachapplication, but rather reflect the content of vari-ous technical reports. We refer the interestedreader to the deliverables of all the above men-tioned projects, and the technical reports issuedby the consortia and standardization workinggroups [7, 8]. As there are ongoing test site andtestbed developments for specific application sce-narios, our objective is to capture the latest under-standing in the development of those applications.

In the future rigorous validation of specific sys-tems can refine and tune these parameters.

The first eight applications in Table 3enhance transportation safety; they are mostlyad hoc based, have relatively stringent timerequirements, and are given high priority at thedata link. Practically all of them rely on coopera-tive awareness beaconing at high beacon rates:10 beacons/s or message period of 100 ms.Among them, Pre-Crash Sensing has the moststringent latency requirements. It is noteworthythat, for the time being, such latency figures are

Table 3. VC-enabled applications and their characteristics.

Application name

Application information

Communication Messaging type Messageperiod Latency Other requirements

1EmergencyElectronic BrakeLights

Ad hocV2V

Event-triggered, time-limited broadcast 100 ms 100 ms Range: 300 m, high priority

2 Slow VehicleWarningAd hocV2V

Periodic permanentbroadcast 500 ms 100 ms High priority

3 IntersectionCollision WarningAd hoc, infrastructureV2V, V2I

Periodic permanentbroadcast 100 ms 100 ms

Accurate positioning on adigital map, high priority

4 Hazardous LocationWarningAd hoc, infrastructureI2V, V2V

Event-triggeredtime-limited GeoCast 100 ms 100 ms High priority

5 Traffic SignalViolation WarningAd hoc, infrastructureI2V

Event-triggeredtime-limited broadcast 100 ms 100 ms Range: 250 m, High priority

6 Pre-Crash Sensing Ad hocV2VPeriodic broadcast,unicast 100 ms 50 ms

Range: 50 m, high/mid priorityfor beaconing/unicast

7 Lane ChangeWarningAd hocV2V Periodic broadcast 100 ms 100 ms

Relative positioning accuracy:< 2 m; range: 150 m

8CooperativeForward CollisionWarning

Ad hocV2V

Periodic, event-trig-gered broadcast,unicast

100 ms 100 ms Relative positioning accuracy:< 1 m; range: 150 m

9 IntersectionManagementInfrastructure, ad hocV2I, V2V

Periodic broadcast,unicast 1000 ms 500 ms Positioning accuracy: < 5 m

10 Limited Access andDetour Warning

Infrastructure, I2V,other broadcastnetwork

Periodic Broadcast 100 ms 500 ms Mid/low priority

11 Cooperative Adap-tive Cruise ControlAd hocV2V Unicast broadcast 500 ms 100 m Mid priority

12 Electronic TollCollectInfrastructure, ad hocV2I, cellular

Periodic broadcast,unicast 1000 ms 200 ms CEN DSRC

13 Remote Diagnosis/JIT Repair WarningInfrastructure, ad hocV2I, V2V, cellular

Unicast, broadcast,event-triggered N/A 500 ms

Internet accessService availability

14 Media DownloadInfrastructure; cellular,other broadcastnetwork

Unicast, broadcast,on-demand N/A 500 ms

Internet accessDigital rights management

15 MapDownload/Update

Infrastructure, ad hocV2I, V2V, cellular, otherbroadcast network

Unicast, broadcast,on-demand 1000 ms 500 ms

Internet accessDigital rights managementService availability

16 Ecological DriveAssistanceInfrastructure, ad hocV2I, V2V, cellular

Unicast, broadcast,on-demand 1000 ms 500 ms

Internet accessService availability



not tied to specific reliability levels. In fact, it isnecessary to specify end-to-end delays (i.e., forV2V-enabled safety applications, maximum V2Vapplication layer delays). This would include allprocessing at all layers and represent the delayafter which the given event (vehicle detection,collision hazard, etc.) is perceived by the receiv-ing vehicle. For multihop communication, thecorresponding definitions would be necessary. Itis also possible to adapt such requirementsdepending on the surrounding conditions.

From a different point of view, Pre-CrashSensing is relevant to a small communicationrange (which corresponds to small distancesbetween vehicles). Overall, the recommendedranges for each application can be beneficial tothe protocol designer in many ways, for example,in terms of handling incoming messaging such asbeacons.

Some of the transportation safety applica-tions have relatively demanding positioningrequirements: Lane Change Warning requiresrelative positioning accuracy of less than 2 m,whereas Cooperative Forward Collision Warningnecessitates relative positioning accuracy of lessthan 1 m. The Crash Avoidance Metrics Partner-ship (CAMP) Intersection Collision Avoidancesystem, with two experimental intersectionsalready deployed, requires relative positioningaccuracy of less than 0.5 m. All vehicles andRSUs are to be location-aware, but GNSS-basedor other localization schemes provide a coarser-grained level of accuracy than the above-men-tioned requirements. As a result, additionalonboard processing is necessary.

The next four applications (9–12 in Table 3)are related to transportation efficiency enabledby ad hoc communication with the infrastructure(RSUs, generic or specialized such as the tollcollection units). The assigned priority is lowerthan that of safety applications, beaconing ratesare five to ten times lower, and the requiredlatencies are up to five times higher. The com-munication is based on V2V protocols too. But adistinctive feature, compared to safety applica-tions that rely on broadcast, is that there is uni-cast V2V communication; in some cases, cellularcommunication could be involved.

The final four applications (13–16) offer ser-vices to users (passengers and drivers); they relymostly on infrastructure-based communicationrather than V2V data exchange and mandateInternet access. In other words, the vehicle hasto be an IP addressable host, and the corre-sponding servers online and accessible either inan ad hoc V2I manner (when the vehicle is with-in range of an access point) or via cellular orother networks. Latency requirements are amongthe lowest, and cooperative awareness becomessecondary if not irrelevant. Nevertheless, otherissues that are not VC-specific arise, such as dig-ital rights management (i.e., mechanisms andpolicies that specify and enforce access controlto the obtained content).

From the above discussion, we see a relationbetween communication and networking proto-cols and applications. Nonetheless, this is a jointdevelopment effort, and thus there are stillaspects to be defined and fine-tuned. Severalprojects take for granted that there will be V2V

and V2I communication in the future, includingthe forms discussed in the previous sections.They consider an open VC architecture thatmakes data exchange possible, but they do notnecessarily rely yet on advanced data exchange.This agnostic approach is interesting in the sensethat one could develop an application without,or with little, VC now. In this vain, the HighlyAutomated Vehicles for Intelligent Transport(HAVE-IT) anticipates the availability of VC.The project is developing a co-pilot that opti-mizes task repartition between driver and co-driving system, with a redundant and fail-safeelectronic architecture. The perception is cur-rently local, but HAVE-IT prepares an architec-ture for cooperative data fusion in the future.

FUTURE OUTLOOKThe surveyed recent concerted efforts haveyielded significant results and momentum forfurther developments. In this article we providea concise survey of the state of the art, capturingqualitatively and quantitatively the technicalapproaches under development.

Nonetheless, several challenges lie aheadbefore VC systems can be deployed. Continuingfield tests, such as those undertaken by projectssuch as SAFESPOT and VSC-A, is paramount.Building large-scale field experimentation is fur-ther necessary for thorough testing and valida-tion of the system dependability. This includesnot only the data link and networking technolo-gies but also the applications themselves, notablythose with the most stringent requirements.Ensuring efficient and effective operation evenin challenging situations, even if unlikely tooccur in practice, is necessary (e.g., as the size ofVC networks scales up).

Meanwhile, the integration of strong and effi-cient security mechanisms should not be neglect-ed, especially as an architecture and protocolsfor secure VC along with privacy enhancingtechnologies are developed [9]. With the appro-priate design, secure VC systems can be as effec-tive as non-secure ones. Thus, with the currentand growing awareness of the importance ofsecurity, trustworthy VC systems could bedeployed.

Additional aspects to consider include finan-cial, legal, and organizational issues. For exam-ple, what will be the cost of deployment, andhow will it be covered? Will the deploymentleverage on existing systems and user-portabledevices, such as smart phones? What will be thefirst set of applications deployed? How willauthorities and services be instantiated in a het-erogeneous environment that is subject to legis-lation not necessarily or even far fromharmonized?

Innovation is necessary, of course, in terms ofmarket introduction. Without deep penetrationof the solution (in vehicles and/or the infra-structure), benefits for the final user (the driver)will be very limited. No one would agree to payfor something that will be useful only at sometime in the future. It is crucial to understandhow VC can realistically be deployed. Responsi-bilities, legal implications, and liability issuesshould be clearly specified.

Continuing field

tests, as those

undertaken by

projects such as

SAFESPOT and

VSC-A, is

paramount. Building

large-scale filed

experimentation is

further necessary for

thorough testing and

validation of the

system dependability.



Another essential step toward deployment isstandardization, with contributions from pro-jects, industrial consortia, and standardizationcommittees and working groups.

In the future, solutions departing significant-ly from the current paradigm could emerge.Advanced driver assistance systems and newsensing technologies can be highly beneficial,along with a large body of work on automatedvehicles. Eventually, the most advanced cooper-ative systems would probably be fully automat-ed; examples are the CyberCars and CityMobilprojects and the DARPA Challenge(http://www.darpa.mil) for autonomous groundvehicles. Of course, very high levels of confi-dence would be necessary to gain broad useracceptance for vehicular communication sys-tems, which could benefit personal and com-mercial mobility, contributing to theirsustainability.

REFERENCES[1] R. Bossom et al., “European ITS Communication Archi-

tecture: Overall Framework, Proof of Concept, Imple-mentation, v.2.0,” Information Society Technologies,Specific Support Action, COMeSafety, Mar. 2009.

[2] T. Kosch et al., “Communication Architecture for Coop-erative Systems in Europe,” IEEE Commun. Mag., May2009.

[3] D. Paret and R. Riesco, “Multiplexed Networks forEmbedded Systems: CAN, LIN, FlexRay, Safe-by-Wire,”SAE Int’l., 2007.

[4] IEEE P802.11p/D3.0, “Draft Amendment to Standard forInformation Technology-Telecommunications and Infor-mation Exchange Between Systems-Local andMetropolitan Area Networks Specific Requirements —Part 11: Wireless LAN Medium Access Control (MAC)and Physical Layer (PHY) Specifications — Amendment7: Wireless Access in Vehicular Environments,” 2007.

[5] R. A. Uzcátegui and G. Acosta-Marum, “WAVE: A Tuto-rial,” IEEE Commun. Mag., May 2009.

[6] A. de La Fortelle, P. Muhlethaler, and A. Laouiti,“GeoNet: Geo-Networking for ITS Applications,” 15thITS World Congress, 2008.

[7] Vehicle Safety Communications Applications (VSC-A)Project, “Final Annual Report,” DOT HS 811 073, Jan.2009.

[8] ETSI TR 102 638, “Intelligent Transport Systems (ITS),Vehicular Communications (VC), Basic Set of Applica-tions, Definitions,” v. 1.1, June 2009.

[9] P. Papadimitratos et al., “Secure Vehicular Communica-tions: Design and Architecture,” IEEE Commun. Mag.,vol. 46, no. 11, Nov. 2008.

BIOGRAPHIESPANOS PAPADIMITRATOS ([email protected]) earnedhis Ph.D. degree from Cornell University in 2005. After aresearch associate position at Virginia Tech, he is currently asenior researcher at EPFL. His research is concerned withsecurity, networking protocols, and wireless and mobile sys-tems. He has authored more than 65 technical publicationson these topics, delivered several tutorials, including ones atACM Mobicom ‘07 and ACM CCS ‘09, and served on theprogram committees of ACM MobiHoc, WiSec, ASIACCS,VANET, and IEEE INFOCOM, among other venues.

ARNAUD DE LA FORTELLE ([email protected]) isa civil servant at the French Transports Ministry and is cur-rently director of Centre for Robotics at Ecole des Mines(CAOR) and director of the Joint Research Unit LaRA. Hehas managed several French and European projects(Puvame, Prevent/Intersafe, REACT), and is coordinator ofthe French project AROS and the European FP7 STREPGeoNet. He was previously a researcher in the field ofstochastic systems. He has a Ph.D. in applied mathematicsand engineer degrees from the French Ecole Polytechniqueand Ecole des Ponts et Chaussées.

KNUT EVENSEN ([email protected]) earned his M.Sc.degree in telematics from the Norwegian Institute of Tech-nology in 1982, and his current position is chief technolo-gist at Q-Free, Norway. He has more than 20 years’background in global ITS standardization and ITS R&D pro-jects under the EU framework programs. Today, he is theconvener and editor of various CEN, ISO, and ETSI stan-dardization groups, and Chief Architect on the CVIS Inte-grated Project.

ROBERTO BRIGNOLO ([email protected]) received hiselectrical engineering degree (cum laude) in 1979 from thePolitecnico di Torino. After working as a junior researcherat CSELT, he joined SO.FI.HA as project leader in 1982. In1989 he joined Magneti Marelli (FIAT Group) as designerresponsible for the racing application team (Rally and For-mula 1), and was project manager for the development ofinnovative engine and vehicle electronic control units formass production. In 2002 he joined CRF, where is currentlyproject manager in the telematics area. He has participatedin several EC funded projects (he coordinated SAFE TUNNEand now SAFESPOT), and large EUREKA projects (EAST-EEA,SYSNET, SSAE, ATEMAES).

STEFANO COSENZA ([email protected]) earned his degreein physics from Turin University in 1996 with his thesiswork conducted at the FIAT research center (CRF). Hejoined CRF in 1998 as a researcher and he has sinceworked in different fields: fluid dynamic simulations, auto-motive sensors development and characterization, andinfrastructure and automotive systems for safety applica-tions. Since 2003 he has focused his activity on themesrelated to telematics, in particular architectural and securityaspects.

In the future,

solutions departing

significantly from the

current paradigm

could emerge.

Advanced Driver

Assistance Systems

and new sensing

technologies can be

highly beneficial,

along with a large

body of work on

automated vehicles.


/ColorImageDict > /JPEG2000ColorACSImageDict > /JPEG2000ColorImageDict > /AntiAliasGrayImages false /CropGrayImages true /GrayImageMinResolution 300 /GrayImageMinResolutionPolicy /OK /DownsampleGrayImages false /GrayImageDownsampleType /Average /GrayImageResolution 300 /GrayImageDepth -1 /GrayImageMinDownsampleDepth 2 /GrayImageDownsampleThreshold 1.50000 /EncodeGrayImages true /GrayImageFilter /DCTEncode /AutoFilterGrayImages true /GrayImageAutoFilterStrategy /JPEG /GrayACSImageDict > /GrayImageDict > /JPEG2000GrayACSImageDict > /JPEG2000GrayImageDict > /AntiAliasMonoImages false /CropMonoImages true /MonoImageMinResolution 1200 /MonoImageMinResolutionPolicy /OK /DownsampleMonoImages false /MonoImageDownsampleType /Average /MonoImageResolution 1200 /MonoImageDepth -1 /MonoImageDownsampleThreshold 1.50000 /EncodeMonoImages true /MonoImageFilter /CCITTFaxEncode /MonoImageDict > /AllowPSXObjects false /CheckCompliance [ /None ] /PDFX1aCheck false /PDFX3Check false /PDFXCompliantPDFOnly false /PDFXNoTrimBoxError true /PDFXTrimBoxToMediaBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXSetBleedBoxToMediaBox true /PDFXBleedBoxToTrimBoxOffset [ 0.00000 0.00000 0.00000 0.00000 ] /PDFXOutputIntentProfile (None) /PDFXOutputConditionIdentifier () /PDFXOutputCondition () /PDFXRegistryName () /PDFXTrapped /False

/CreateJDFFile false /Description > /Namespace [ (Adobe) (Common) (1.0) ] /OtherNamespaces [ > /FormElements false /GenerateStructure false /IncludeBookmarks false /IncludeHyperlinks false /IncludeInteractive false /IncludeLayers false /IncludeProfiles false /MultimediaHandling /UseObjectSettings /Namespace [ (Adobe) (CreativeSuite) (2.0) ] /PDFXOutputIntentProfileSelector /DocumentCMYK /PreserveEditing true /UntaggedCMYKHandling /LeaveUntagged /UntaggedRGBHandling /UseDocumentProfile /UseDocumentBleed false >> ]>> setdistillerparams> setpagedevice

vehicular communication systems: enabling technologies ...papadim/publications/... · plex systems...

Documents