Road-Based Routing in Vehicular Networks PhD Dissertation Defense by Josiane Nzouonta Advisor: Cristian Borcea
Today: Smart Vehicles Geographical Positioning System (GPS) Digital maps or navigation system On-Board Diagnostic (OBD) systems DVD player
Tomorrow: Vehicular Networks Roadside infrastructure Internet Cellular Vehicle-to-vehicle Vision vehicular networks Benefits: saving lives, time; saving gas and implicitly money Proactively for Applications Accident alerts/prevention Dynamic route planning Entertainment Communications Cellular network Vehicle to roadside Vehicle to vehicle
Vehicular Ad Hoc Networks (VANET) My focus in this research Benefits Scalability Low-cost High bandwidth Purpose of enabling communication between cars Challenges Security High mobility
VANET Characteristics High node mobility Constrained nodes movements Obstacles-heavy deployment fields, especially in cities Large network size Can applications based on multi-hop communications work in such environment? The answer lies in part with the performance of routing and forwarding protocols in VANET
Problem Statement How to design efficient routing and forwarding protocols in VANET? Do existing MANET routing protocols work well in VANET? If not, can we take advantage of VANET characteristics to obtain better performance? Are current forwarding protocols enough or can they be optimized for VANET characteristics?
Contributions Road-Based using Vehicular Traffic (RBVT) routing Use real-time vehicular traffic and road topology for routing decisions Geographical forwarding on road segments VANET distributed next-hop self-election Eliminate overhead associated with periodic “hello” messages in geographical forwarding Effect of queuing discipline on VANET applications LIFO-Frontdrop reduces end-to-end delay compared with FIFO-Taildrop RBVT path predictions Analytical models to estimate expected duration of RBVT paths
Outline Motivation RBVT routing Forwarding optimizations Conclusions Distributed next-hop election Effect of queuing disciplines on VANET performance RBVT path predictions Conclusions
Node Centric Routing Shortcomings in VANET Examples of node-centric MANET routing protocols AODV, DSR, OLSR Frequent broken paths due to high mobility Path break does not correspond to loss connectivity Performance highly dependent on relative speeds of nodes on a path S N1 D a) At time t b) At time t+Δt N2
Geographical Routing Shortcoming in VANET Examples of MANET geographical routing protocols GPSR, GOAFR Advantage over node-centric Less overhead, high scalability Subject to (virtual) dead-end problem S D Dead end road N1 N2 Uses nodes positions to perform multihop communication Neighbor closest to destination position selected as next hop Virtual dead-ends VANET-specific routing Perform geographical routing along road streets Heuristics: Use daily/hourly traffic flow data to select next road segment Use roads most frequented by buses Pros/cons: Historical data not always a good indication of current road state
RBVT Routing Main Ideas Use road layouts to compute paths based on road intersections Select only those road segments with network connectivity Use geographical routing to forward data on road segments Advantages Greater path stability Lesser sensitivity to vehicles movements I2 I1 I3 I6 I8 E car Intersection j I7 I4 I5 Ij D S A B C Source Destination Path in header: I8-I5-I4-I7-I6-I1
RBVT Protocols RBVT-R: reactive path creation Up-to-date routing paths between communicating pairs Path creation cost amortized for large data transfers Suitable for relatively few concurrent transfers RBVT-P: proactive path creation Distribute topology information to all nodes No upfront cost for given communication pair Suitable for multiple concurrent transfers
RBVT-R Route Discovery Source broadcasts route discovery (RD) packet RD packet is rebroadcast using improved flooding Intersections traversed are stored in RD header S Source I1 I2 I3 A N1 Re-broadcast from N1 B Re-broadcast from B C I4 I5 I6 E I7 I8 D car Ij Intersection j Destination
RBVT-R Route Reply Destination unicasts route reply (RR) packet back to the source Route stored in RR header RR follows route stored in the RD packet S Source I1 I2 I3 A B C I4 I5 Path in reply packet header I1 I6 I6 E I7 I8 I7 D I4 I5 I8 car Ij Destination Intersection j
RBVT-R Forwarding Data packet follows path in header Geographical forwarding is used between intersections Path in data header S Source I1 I6 I1 I2 I3 I7 I4 A I5 I8 B C I4 I5 I6 E I7 I8 D car Ij Destination Intersection j
RBVT-R Route Maintenance Dynamically update routing path Add/remove road intersections to follow end points When path breaks Route error packet sent to source Source pauses transmissions New RD generated after a couple of retries S Source I1 I2 I3 A N1 Re-broadcast from N1 B Re-broadcast from B C I4 I5 I6 E I7 I8 D car Ij Intersection j Destination
RBVT-P Topology Discovery Unicast connectivity packets (CP) to record connectivity graph Node independent topology leads to reduced overhead Lesser flooding than in MANET proactive protocols Network traversal using modified depth first search Intersections gradually added to traversal stack Status of intersections stored in CP Reachable/unreachable CP generator n n-1 I1 I2 I3 A 2 1 B 7 8 C 3 I4 I5 6 5 9 4 I6 E I7 I8 RBVT-P was co-designed in collaboration with Neeraj Rajgure, a master student in the CS dept multiple nodes generate CPs based on a simple randomized scheme to ensure that connectivity info is available even in case of network partitions car i Step i Ij Intersection j
RBVT-P Route Dissemination & Computation CP content is disseminated in network at end of traversal Each node Updates local connectivity view Computes shortest path to other road segments Reachability Intersection j I2: I1, Iv2 I4: I7, I5, Iv3 I6: I1, I7 I5: I4, I8, Iv4 I7: I6, I4 I1: I2, I6, Iv1 Iv3 Iv2 RU content I1 I2 I3 I4 I5 I6 I7 I8 Iv4 Ij Iv1
RBVT-P Forwarding and Maintenance RBVT-P performs loose source routing Path stored in every data packet header Intermediate node may update path in data packet header with newer information In case of broken path, revert to greedy geographical routing Source appends path in data header
RBVT Evaluation Perform simulations to compare against existing protocols Comparison protocols: AODV (MANET reactive) GPSR (MANET geographical) OLSR (MANET proactive) GSR (VANET) Metrics Average delivery ratio Average end-to-end delay Routing overhead
Simulation Setup Network Simulator NS-2 Map: 1500m x 1500m from Los Angeles, CA Digital map from US Tiger/Line database SUMO mobility generator Obstacles modeled using random selection of signal attenuation Range [0dB, 16dB] Shadowing propagation model
Simulation Setup (cont’d) Data rate 11Mbps
Average Delivery Ratio RBVT-R has the best delivery ratio performance RBVT-P improves in medium/dense networks The denser the network, the better the performance for road-based protocols in these simulations
Average End-to-end Delay RBVT-P performs best, consistently below 1sec in the simulations RBVT-R delay decreases as the density increases (less broken paths)
Outline Motivation RBVT routing Forwarding optimizations Conclusions Distributed next-hop election Effect of queuing disciplines on VANET performance RBVT path predictions Conclusions
The Problem with “hello” Packets “hello” packets used to advertise node positions in geographical forwarding “hello” packets need to be generated frequently in VANET High mobility leads to stalled neighbor node positions Presence of obstacles leads to incorrect neighbor presence assumptions Problems in high density VANET Increased overhead Decreased delivery ratio
Distributed Next-hop Self-election Slight modification of IEEE 802.11 RTS/CTS Backward compatible RTS specifies sender and final target positions Waiting time is computed by each receiving node using prioritization function Next-hop with shortest waiting time sends CTS first Transmission resumes as in standard IEEE 802.11 ns n4 n1 n2 n3 n5 n6 D RTS CTS (a) RTS Broadcast and Waiting Time Computation (b) CTS Broadcast (NULL) (0.115ms) (0.201ms) (0.0995ms) r Data (c) Data Frame ACK
Waiting function Function takes 3 parameters Distance sender to next-hop (dSNi) Distance next-hop to destination (di) Received power level at next-hop (pi) Weight parameters α set a-priori Value of α determines weight of corresponding parameter Adds signal quality in determination of next next-hop Leveraged previous work on MANET done at EE, NJIT to VANET environment Tmax is maximum waiting time for a next hop; value is transmission time of CTS + propagation delay
Waiting Function Results Using multi-criteria function to select next hops leads to significantly lower packet loss and overhead in VANET
Evaluation of Self-election Performance Goal: Verify and quantify if/how self-election improves performance in high congestion scenarios Metrics Average delivery ratio Average end-to-end delay Routing overhead Used own mobility generator based on Gipps car-following and lane-changing models Simulations parameters same as used for RBVT evaluation Map used in the no obstacle simulations
Delivery Ratio & Delay Distributed next-hop self election RBVT-R with source selection using “hello” packets vs. self-election Average Delivery Ratio and Average Delay comparison between two types of geographical forwarding: source selection using “hello” packets and receiver self-election using the RTS/CTS-based mechanism under the scenario without obstacles. The routing protocol is RBVT-R, and the network size is 250 nodes. Distributed next-hop self election Increases delivery ratio Decreases end-to-end delay
Outline Motivation RBVT routing Forwarding optimizations Conclusions Distributed next-hop election Effect of queuing disciplines on VANET performance RBVT path predictions Conclusions
Effect of Current Queue Discipline on Delay Current queuing discipline: FIFO with Taildrop (TD) Wireless contention increase time packets spend in queue Low percentage problem frames have significant impact on average delay Average end-to-end delay as function of percentages of frames experiencing transmission delays greater than 2 seconds.
Improving Delay through Queuing Discipline Why improve? Delay sensitive but loss tolerant applications important in VANET/MANET Applications: video streaming near an accident; search and rescue operations Analyze four queuing disciplines FIFO-Taildrop (FIFO-TD) FIFO-Frontdrop (FIFO-FD) LIFO-Taildrop (LIFO-TD) LIFO-Frontdrop (LIFO-FD) End-to-end solutions for decreasing delay have issues in ad hoc networks in general, and mobile ad hoc in particular
Single Queue Analysis Probabilities of service and failure Probabilities of service/failure given that packet arrives with system in state k And for all disciplines
Single Queue Analytical Results Low traffic rate ρ = 0.75 Expected waiting times are similar for all 4 disciplines Variance of waiting times higher for LIFO disciplines
Single Queue Analytical Results (cont’d) High traffic rate ρ = 1.5 LIFO-FD presents low expected waiting times of packets served Variance of waiting times of served packets is also lowest for LIFO-FD and highest for LIFO-TD
Network Evaluation Evaluation Assess performance in ad hoc networks, static and mobile Metrics: average end-to-end delay, end-to-end jitter, throughput Static topology
Average End-to-end Delay Static ad hoc network scenario Comparable performance for low traffic LIFO disciplines have best and worst performance in high traffic
Average Jitter Static ad hoc network scenario Low traffic: less than 40ms jitter for all 4 FIFO has lowest jitter High traffic: LIFO-FD maintains less than 1sec jitter with buffer size increase
Delay & Throughput in VANET No obstacles map with 250 nodes, RBVT-R LIFO-FD leads to lower delay (as much as 45%) Throughput not aversely affected by LIFO-FD
Outline Motivation RBVT routing Forwarding optimizations Conclusions Distributed next-hop election Effect of queuing disciplines on VANET performance RBVT path predictions Conclusions
Characterization of RBVT Paths Why? How long is the current route going to last? Does it make sense to start a route discovery? Can a 100Mb file be successfully transferred using the current route? Is it possible to estimate the duration of a path disconnection? How to estimate path characteristics (connectivity duration/probability)? Simulations are specific to geographical area Analytical models based on validated traffic models are preferred
Cellular Automata (CA) Traffic Model (a) At time t (b) At time t+1 car 2, v2=1 car 1, v1=2 car 3, v3=1 car 2, v2=2 gap1 = 4 cells gap2 = 1 cell gap3 ≥ 3 cells Lc = 7.5m gap1 = 3 cells gap3 ≥ 2 cells Update rules at vehicle i Acceleration: if vi < vmax, vi = vi + 1 Slow down (if needed): if vi > gapi, vi= gapi Randomization: vi = vi – 1 with probability p Move car: xi = xi + vi Microscopic vehicular traffic generator Validated in literature Discrete-space and discrete-time model Divide road in cells of length Lc Lc sometimes 7.5m Car length ~ 5m, safety distance 2.5m Discrete speed set {0,1, 2, …, vmax}
DTMC-CA Model Discrete-time and discrete space model Uses CA microscopic traffic model for vehicle movements Portion of road between source and destination divided in k cells of length Lc Markov chain M = (S, P, s0) State space S = {s = (c1, c2, …, ck), ci є V, i=(1,…, k)} Cell values V = {0, 1, 2, …, vmax, ∞} Interested only in stationary measures
State Reduction: Invalid States As described, |S| = |V|k Many potential states are transient states Violate updating rules Not reachable from any other state in the system Algorithm to output non-transient states Directly obtaining non-transient states needed 2 Time t 1 Time t-1 3
State Reduction: Lumpability Markov chain is lumpable w.r.t with Example Additional 80% decrease in size of space set observed when lumping the Markov chain CA Rules: Deterministic (rule 1 and 2) Stochastic (rule 3) Deterministic (rule 4) If two states x, y equal after rules 1 and 2, identical rows in transition matrix States can be lumped because they are “equivalent” Lumping preserves the stationary and transient properties of interest
Transition Matrix Generic transition probability from state of aggregated Markov chain 2 1 Road section 3 4 5 6 7 8 9 10 Cell number For cell 2: 2 = 3 2 = 0 For cell 3: 3 = 5 3 = 0 Borders: 0 = 3 10 = 9 For cell 6: 6 = 7 6 = 5
Probabilistic Measures Stationary distribution π Connected states S1 Disconnected states S2 S1US2 =S S1∩S2 =Ø Expected duration of connectivity
Probabilistic Measures (cont’d) Expected duration of disconnection Probability of connection duration
Extending Basic Model Bidirectional Traffic Each lane is divided in k cells, juxtaposed, independent Markov chain Moving endpoints and lane change Speed relative to source speed Possible cell values Moving endpoints: Value of k changes during communication, with maximum distance considered Lane change rules added to basic CA model Lc = 7.5m
Evaluation Method and Setup Simulation to validate model Simulate CA freeway model and SUMO Large ring layout Connectivity of shaded area is analyzed Complete ring affects shaded area DTMC-CA considers shaded area only Area of observation with k cells Total number of cells = 320 cells Source Destination
Expected Connectivity Duration 50 vehicles 75 vehicles DTMC-CA match well with simulation results Increase in transmission range leads to increase in connectivity duration (as expected) Stochastic nature of CA model: 11 cells out of 12 cells for connectivity leads to average of < 80 sec with 0.23 density
Expected Disconnectivity Duration 35 vehicles 50 vehicles DTMC-CA match well with simulation results Increasing connectivity range decreases expected disconnectivity duration Impact of density on expected disconnectivity duration reduced compared to impact on expected connectivity duration
Probability Connectivity Duration k = 8 cells k = 10 cells Longer uninterrupted connectivity less likely Larger k leads to smaller probabilities of connectivity duration
Incorporating Path Estimates in RBVT Road-side sensors or historical data Road segment densities and entry speeds probabilities Improving route selection Duplicate routes received at the destination Enhancing route maintenance of RBVT-R How long should the source wait when a route breaks Determining RBVT-P CP generation interval Period between CP generation based on connectivity duration Reducing overhead network traffic Likelihood of success of 100MB transmission (delay or divide in smaller chunks)
Conclusion Existing MANET routing protocols do not work well in VANET Better routing and forwarding possible by integrating VANET characteristics such as road layouts and node mobility Contributions: RBVT routing: Stable traffic-aware road-based paths Distributed VANET next-hop self-election: Significant overhead reduction in geographical forwarding Impact of queuing discipline on latency: LIFO-TD improves performance for delay sensitive applications RBVT paths predictions: Analytically compute path estimates, which can be used to improve data transfer performance
Future Work Adaptive queuing mechanism Route lifetime prediction independent of the vehicular traffic model used Apply knowledge of expected route duration in RBVT Security issues in RBVT
Thank you! Acknowledgments: This research was supported by the NSF grants CNS-0520033 and CNS-0834585
Impact of Number of Flows The data rate is fixed at 4 packets/second and the network size is 250 nodes Delivery ratio is stable in the simulations performed
Node Selection Using Waiting Function
Overhead Routing packets exchanged for each received data packet Removing “hello” packets essentially eliminates most overhead
Single Queue Analysis Interested in time elapsed from packet arrival to service Markov chain model X(t) on the state space {−1, 0, · · · ,N} If packet arrives when state (k), k < N State changes to (k + 1) New packet goes in position k+1 If a packet arrives while the system is in state (N) System remains in this state Under Taildrop, the arriving packet is dropped and all the other packets remain in their old positions Under Frontdrop, the packet in position 1 is dropped, other packets move up one position (j -> j −1), arriving packet goes to position N
TCP Throughput and Fairness 10 flows, 2MB each 6 flows, 5MB each Static ad hoc network scenario Transfers complete at comparable times for LIFO-FD and FIFO-TD LIFO-FD does not disadvantage any specific flow in those simulations
DTMC-CA: Effect of Removing Invalid States
SUMO Results
Different Traffic Models - Different Results
Connectivity Window Model Provide analytical model independent of the traffic model Uses the concept of connectivity window Count vehicles in each window