Designing an Inter-Vehicular
Network Stack for
Car-to-Car Communication
Pravin Shankar
spravin@rutgers.edu
Department of Computer Science
Rutgers University
Outline
Motivation – Traffic Safety
 TrafficView

 Overview
of System
 Data Aggregation/Validation layer
 On-demand Traffic Query
Future work
 Conclusion

Some facts on Traffic safety

Since 1975, vehicle safety
technology has focused on
passive devices:




*
Seat belts
Air bags
Antilock Brake System
However, the number of
reported traffic accidents in
US has remained relatively
constant
based on U.S. Traffic Safety Facts Report
*
Passive Approach is not Enough
On foggy days
What’s in
front of
that bus ?
On rainy days
What’s
behind the
bend ?
TrafficView


Uses vehicle-to-vehicle ad hoc network
Enables active accident-prevention using dissemination of
safety messages
TrafficView Overview


Infrastructure-free
approach based on carto-car communication
Each vehicle has an
embedded system



short-range wireless
communication
location information from
GPS receiver
vehicle’s data from
sensors through on-board
diagnostic system (OBD-II)
How TrafficView works?
Receive data from
remote vehicle
Local data
Broadcast data
Validate
Non-validated
dataset
Validated
dataset
Display
TrafficView Prototype



Developed in Java, ported to both Windows and
Linux
User Interface developed using OpenGL
802.11b network card
 augmented



with 5dBi omni-directional antenna
Garmin eTrex GPS receiver
TIGER® road maps from U.S. Census Bureau
(publicly available)
Tested using 3 cars in real traffic conditions
TrafficView Outdoors
Too much traffic!

Vehicles transfer records:


Consider a very high-density 5-lane road





Vehicle ID (ID), position (POS), speed (SPD), broadcast time
(BT)
Distance between consecutive cars – 5m
Average size of data records – 50 bytes
Wireless transmission range of 250 m
250 vehicles compete for the same wireless medium
Total data transmitted every broadcast period = 250 MB
Beyond the capabilities of current wireless technology!
Data Aggregation

Aggregate data to see vehicles as far as
possible with “acceptable” accuracy loss
 Combine
data for vehicles that are close to
each other
 Perform
more aggregation as distance
increases
Data Aggregation

Having n records
{ID1 , POS1 , SPD1 , BT1}...{IDn , POS n , SPDn , BTn }

Calculate the aggregated record’s fields:
di  distance of vehicle i to the current node
n
POS i
POS a  
di
i 1
n
SPDi
SPDi  
di
i 1
BTa  min{ BT1...BTn }
POS and SPD are weighted averages.
Need for Data Validation

Out-of-date information
 Vehicles move and change speed
 Packets may get lost in transit
 Information received from OBD* might


Solution: Data aging
Malicious nodes can corrupt data
 Inject
incorrect data
 Refuse to forward data
 Modify data

Solution: Probabilistic validation
* On-Board Diagnostic Interface
be invalid
Push v/s Pull

Most cars are interested in information
about immediate neighboring road segment
 “Push”
mechanism is sufficient
How to get information about other roads?
 Broadcast is not scalable

 Road
segments are extensive in size
 Traffic information is dynamic in nature
There is a need for “pull” i.e. On-Demand traffic query
On-demand Traffic Query Protocol

VITP – Vehicular Information Transfer Protocol
 Location-sensitive
queries and replies between nodes
of a VANET
 VITP Peers – nodes that operate as



Clients
Intermediates
Servers
 Agnostic
of network communication layer
Location-sensitive queries
Gas Station
QuickT
im e™an
d a
F
(LZW
de
com
areTIF
ne
eded
t )osee
t hipr
spies
cst or
r e.
u
Quick Time™a nd a
TIFF ( Unco mpre ssed ) dec ompr esso r
ar e nee ded to see this pictur e.
Quick Time™a nd a
TIFF ( Unco mpre ssed ) dec ompr esso r
ar e nee ded to see this pictur e.
Quick Time™a nd a
TIFF ( Unco mpre ssed ) dec ompr esso r
ar e nee ded to see this pictur e.
Coffee
place
QuickT
im e™an
d a
F
(LZW
de
com
areTIF
ne
eded
t )osee
t hipr
spies
cst or
r e.
u
Quick Time™a nd a
TIFF ( Unco mpre ssed ) dec ompr esso r
ar e nee ded to see this pictur e.
Traffic
Server
GSM Link
Virtual Ad-Hoc Servers (VAHS)
The server that computes
the reply is a dynamic
collection of VITP peers
that:
Q

Run on vehicles moving inside the
target-location area of Q.
 Are
willing and able to participate
Gas
Station
in Q’s resolution.
QuickT
im e™an
d a
F
(LZW
de
com
areTIF
ne
eded
t )osee
t hipr
spies
cst or
r e.
u
Quick Time™a nd a
TIFF ( Unco mpre ssed ) dec ompr esso r
ar e nee ded to see this pictur e.

QuickT
im e™an
d a
F
(LZW
de
com
areTIF
ne
eded
t )osee
t hipr
spies
cst or
r e.
u
VAHS (continued)
Established on the fly in an ad-hoc manner
 Identified with a query and its target-location
area.
 Maintains no explicit knowledge (state)
about its constituent VITP peers
 Follows a best-effort approach in serving
queries
 VAHS members maintain no information
about other members of the VAHS.

VITP transactions
Dispatch-query
VAHS-computation
phase
Dispatch-Reply
phase
Reply-delivery phase
phase
Q
VAHS
Q
R
Q1
R
Intermediary nodes
R
Q2
Q3
Q4
Q5
Q7
VITP Peer
VANET node
Q6
Return Conditions (RC)
Determine at which point in time the
resolution of a VITP request can be
considered done (VAHS computation
completes).
 RC decision depends upon:

 Query
semantics: RC must be defined explicitly
in the query specification.
 Timeout condition: either pre-set by higher-level
application semantics or default.
Other protocol features

Support for caching.

Message identifiers.

Privacy protection.

Dissemination vs. pull-based retrieval.
VITP – Message Format
METHOD <uri> VITP/<version_num>
Target: [rd_id_dest,seg_id_dest]
From: [rd_id_src,seg_id_src] with <speed>
Time: <current_time>
Expires: <expiration_time>
Cache-Control: <directive>
TTL: <time_to_live>
msgID: <unique_key>
Content-Length: <number_of_bytes>
CRLF
<message body>
VITP URI Format
/<type>/<tag>?[<rc_expr>&…]&<param_expr>&…
 type: classes of physical-world entities involved
in the request (vehicle,service).
 tag: actual information sought (traffic, alert, gas,
index).
 Example VITP requests:
GET /vehicle/traffic?[cnt=10&tout=2000ms]&tframe=3min
GET /service/gas?[cnt=4&tout=1800ms]&price<2USD
POST /vehicle/alert?[cnt=*&tout=*]&type=slippery-road
Future work

Reliable multicast – content delivery on VANETs
 Provide

support for rich multimedia on cars
Outdoor Experiments
 Perform
experiments in real traffic conditions in order
to better understand VANET characteristics




Mobility emulation
Traffic modelling
Privacy Issues
Deployment on real systems
Related Work

Car Manufacturers

GM-CMU - http://gm.web.cmu.edu/
 Daimler-Chrysler - http://www.rtna.daimlerchrysler.com/
 MIT CarTel, Berkeley PATH, PSU CITrans, etc.

Europe

Fleetnet
 Network-On-Wheels
 Car 2 Car Communication Consortium - http://www.car-2-car.org/

Japan



Toyota InfoTechnology Center - http://www.toyota-itc.com/
Tokyo University, Keio University
And many more…
Thank you!
http://discolab.rutgers.edu/traffic/
Faculty
Liviu Iftode
Graduate Students
Pravin Shankar, Stephen Smaldone, Nishkam Ravi
Collaborators
Cristian Borcea, Marios Dikaiakos, Tamer Nadeem, Yanzhi Bai, Josiane Nzouonta
Work supported in part by NSF Collaborative Research: NeTS-NBD: (ANI 0520123)
grant and NSF Information Technology Research (ANI 0121416) grant. .
E-Road Vision

To use ad-hoc vehicular networking to
improve the way we drive by supporting
 Collaborative
traffic information exchange
 Emergency/safety message dissemination
 On-demand traffic conditions monitoring
 Dynamic route planning
 Rich multimedia distribution