Autonomous Networks and Inter-Vehicle Communication

A S U R V E Y O F PA P E R S B Y:D A R W I N M A C H

F O R :C S 7 8 8 – A U TO N O M I C C O M P U T I N GFA L L 20 17

G E O R G E M A S O N U N I V E R S I T Y

Overview• Background

• VANETs• Autonomic Properties

• Dissemination of Information

• Management

• Architecture Standardization

• Decentralization Challenge

2

Background• Networks: all about communication

• Semi-autonomous protocols almost essential to make them easier to use• Most have algorithms that try to detect the network’s state and then optimize

best way to get the data across

• Traditional networks generally static• Nodes and routes don’t change frequently

• Routing protocols built around this

3

Autonomic Computing & VANETJ A M E S J . M U LCA HY, S HI HO N G HU A N G , I M A D M A HG O U BF LO R I DA AT L A NT IC U NI VE RS ITY – 20 1 5

4

VANETs• Vehicular Ad-Hoc Networks

• Sub-classification of Mobile Ad-Hoc Networks (MANETs)

• Similar to Wireless Sensor Networks (WSNs)• But a more generic use

• Complexity, dynamic nature, resiliency requirements, and needs to self-manage for ease of use

• Node communication• Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I)

• Vehicle = On Board Unit (OBU), Infrastructure = Road Side Units (RSUs)

5

VANETs and WSNs

6

VANETs: Evolution from WSNs• WSNs have existed since 1950s

• Military used network of sensors to track Solviet submarines• Developed packet radio in 1970s

• WSNs are generally static• Weather stations

• Industrial equipment in factories and utility plants

• What about mobility? (dynamically changing nodes)

7

VANETs: Evolution from MANETs• Mobile Ad-Hoc Networks

• Ad-hoc, because the network’s composition can change

• Adapt to changing nodes• Can be as small as 2 nodes up to hundreds

• Mix of mobile peers and infrastructure nodes

• Adapt to changing geographic topologies

• Node movement highly variable but slow

• VANETs: Fast movement

8

VANETs: Autonomic Properties• Self-Configuring & Self-Healing

• Vehicles join and leave the network at any time without warning• In/out of range

• Change direction, speed

• Powered on/shut down (ex. start/stop the car)

• Car accident damages the node

• Vehicles may leave network with data that was supposed to be routed• VANET needs to detect this, reconfigure routes, and retransmit lost data

9

VANETs: Autonomic Properties• Self-Optimizing

• Can scale from as little as 1 vehicle to hundreds

• Constantly changing topology• Continually needs to calculate optimal communication routes

• Reduce overhead and increase reliability

• Many topology-based routing and geographical-based routing protocols

10

VANETs: Autonomic Properties• Self-Protecting

• Anticipate fault or failure• Ex: Route data through interior

nodes

• Must also protect against attacks• Node impersonation or spoofing

• Must detect and block them or false information can create major problems

11

Detecting Urban Road Condition and Disseminating Traffic Information by VANETsY U W E I X U, J I A N WA N G , T I N G T I N G L I U, W E N P I N G Y U, J I N G D O N G X UC O L L E G E O F C O M P U T E R A N D C O N T R O L E N G I N E E R I N G , N A N K A I U N I V E R S I T Y – 2 0 1 5

12

VANETs: Dissemination of Information• Example: Congestion information used to route traffic

• V2R Scheme vs V2V Scheme

• Use travel time to develop approach of evaluating routes

• Test the approach with both schemes using a simulator (Veins)• Test network performance AND traffic capacity

13

VANETs: Dissemination of Information• V2R Scheme

• Vehicles send their state to RSUs by periodic broadcast

• RSUs are wired together and broadcast Traffic State Messages (TSMs) in real time

• Vehicles records time it took to get from RSU1 to RSU2

• RSUs record time each vehicle passes it (broadcast with shortest distancec)

14

VANETs: Dissemination of Information

15

• V2V Scheme

• Vehicles send periodic broadcasts

• Vehicles also send TSMs• Done immediately when available

VANETs: Dissemination of Information

16

• Directional Flooding (DF)• Use received TSM to calculate

distance between sender and receiver

• If it’s closer to destination, update sender position and then re-broadcast

• Cached table of received TSMs

VANETs: Dissemination of Information

17

• Restricted Greedy Forwarding (RGF)• Based on GPSR protocol

• Limit hop distance

• Vehicles keep a list of neighbors learned from beacons

• Vehicles calculate distances between each neighbor and destination

• Select neighbor closest to destination within 1 hop

• Repeat process, but stop rebroadcasting once vehicle passes destination

VANETs: Dissemination of Information• Traffic routing

• Shortest Distance First (SDF)

• Shortest Time First (STF)

• Abbreviations• VRS = Valid Route Set

• IRS = Invalid Route Set

• RR = Route Record

18

VANETs: Dissemination of Information

19

VANETs: Dissemination of Information

20

VANETs: Dissemination of Information• Future work…

• Would using a hybrid V2R and V2V be any more effective?

• May be interesting to see varying ratios of V2R and V2V

21

Context-aware Trust-based Management of Vehicular Ad-hoc Networks (VANETs)VA N G A L UR A L AG A R , K A I Y U WA NCO N CO R DI A U N I VER SI TY – 20 1 5

22

VANETs: Management• VANETs are nice & useful but… how do we manage it securely?

• Several types• Newcomer

• Register as “new” to the VANET; erase negative history

• Sybil• Create/use multiple identities

• Betrayal & Inconsistency• Earn trust, then use it for misbehavior

23

VANETs: Management• VANETs are nice & useful but… how do we manage it securely?

• Proposed architecture’s components• Government Transportation Authority (GTA)

• Certification Authority (CA)• May include many Trusted Authorities (TAs)

• Agents (Vehicles & Drivers)

• Enriched RSUs (ERSUs)• Context-aware & reactive• Controller + arbiter

24

VANETs: Management• Proposed architecture takes

both context and trust into account

• Context = situation• Valid actions in one context might

be invalid in another

• Used to create traffic control policies (TCPs), stored in databases owned by GTA

• Trust similar to human trust system• “Driving record”

• Positive/beneficial actions increase trust

• Negative/harmful actions decrease trust

• Issued by GTA and CA

• VANET agent identified by (driver, vehicle) tuple

25

VANETs: Management

26

VANETs: Management• ERSU accesses TCP database from GTA

• Also gets weather & road status info

• Vehicle enters VANET• Credentials: (driver, vehicle) tuple used to obtain ID and trust level from GTA

• ERSU sends profile to agent (identity, coverage zone, trust level in context)

• Agent can accept or reject profile

• ERSU tells everyone not to communicate with agent if it rejects profile, trust levelbelow threshold, or invalid credentials

• ERSU also monitors all communication and punishes otherwise trusted agents who talk to untrusted ones

• Paper says attack by replay of ERSU profile is difficult because its’ trust is dynamic and can change at anytime but that’s really “security by obscurity”

27

VANETs: Management• Several types of attacks discussed

• Newcomer• Register as “new” to the VANET; erase negative history• Mitigated by requiring driver & vehicle identification, can’t authenticate without• If driver is required to use Smart Card + biometric, even harder to attack

• Sybil• Create/use multiple identities

• Maybe legitimate: 1 driver multiple cars• Probably illegitimate: multiple driver identities belonging to the same person

• Paper doesn’t offer a proper solution (suggests creating equivalence class, but how would you know beforehand?)

• Betrayal & Inconsistency• Earn trust, then use it for misbehavior• ERSU has to monitor all communications – can have privacy concerns

28

VANETs: Management• Other attacks

• Denial of Service

• Signal jamming

• Physical damage & modification

• List goes on…

29

Self-corrective Dynamic Networks via Decentralized Reverse ComputationsE VA N G ELO S P O U R NA R A S A ND J OVA N N I KO L I´ CE T H Z U R I CH – 20 17

30

Decentralization Challenge• Let’s not rely on central infrastructure

• Because it’s not always available, costly, hard to make ubiquitous, etc

• VANETs share concepts with IoT

• Many nodes on network can work together• Monitoring and providing traffic assistance (as we’ve reviewed)

• How about assisting autonomous (self-driving) vehicles?• Distributed machine learning?

• Challenge: complexity, low computing power (per node), links are dynamic

31

Decentralization Challenge• Reverse computations proposed

• Computational “roll-back” when nodes leave the network

• Self-corrective model (no central servers, proxies, checkpoint storage, etc)

• Agent-based (2 of them)• Status: publishes node’s status

information• Corrective: migrates to other nodes

to monitor the parent• If parent fails or goes missing, remote

corrective agent coordinates roll-back

32

Decentralization Challenge• Let’s not rely on central infrastructure

• Because it’s not always available, costly, hard to make ubiquitous, etc

• VANETs share concepts with IoT

• Many nodes on network can work together• Monitoring and providing traffic assistance (as we’ve reviewed)

• How about assisting autonomous (self-driving) vehicles?

• Challenge: complexity, low computing power (per node), links are dynamic

33

Decentralization Challenge• Test this approach using DIAS

(Dynamic Intelligent Aggregation Service)

• DIAS is a distributedaggregation system• SUMMATION

• AVERAGE

• MAXIMUM

• MINIMUM

34

Decentralization Challenge• Experiment: Feed DIAS + self-corrective model with real data from

Electricity Customer Behavior Trial (electricity consumption)

• Each node represents a smart meter that was in the real data• Each have disseminator and aggregator

• Test scenarios• UP DOWN (node leaves), DOWN UP (node rejoins)

• Lightweight (max 20% at a time) and Heavyweight (50% at a time)

• Varying departure speeds and periods

• Measure: Accuracy, total messages, rate of migration success

35

Decentralization Challenge• Summarized Results

• Varying departure speeds and periods doesn’t play a big role in accuracy, number of messages, nor rate of migration success

• Corrective network reduces errors in both lightweight and heavyweight scenarios

• Future work• More models? No other ones of this

scale yet• Expand scope to other areas

• Author mentions malware• Could be applied to VANETs!

36