Vehicular Ad Hoc Networking - Overview

Transcription

1 - Overview CSI5140 Arnaud Casteigts casteig/ October 21, 2008

2 Outline Quick Overview New possibilities VANETs Technological context Architecture Standards Introduction Broadcasting (Geocasting) Routing Traffic optimization Bringing Internet into Vehicles Mobility Models and Connectivity References Arnaud Casteigts October 21, / 41

3 Quick Overview Quick Overview Arnaud Casteigts October 21, / 41

4 Quick Overview New possibilities New Wireless Communication Capabilities Arnaud Casteigts October 21, / 41

5 Quick Overview New possibilities New Wireless Communication Capabilities Vehicle-to-Vehicle (V2V) Arnaud Casteigts October 21, / 41

6 Quick Overview New possibilities New Wireless Communication Capabilities Vehicle-to-Vehicle (V2V) Vehicle-to-Infrastructure (V2I) RSU RSU Arnaud Casteigts October 21, / 41

7 Quick Overview VANETs Vehicular Ad Hoc Networks VANETs are Hybrid networks Combine V2I and V2V communications RSU Allow integration of vehicles and Intelligent Transportation Systems In a near future, they are expected to.. improve safety, route selection, geographic notifications.. allow Internet in vehicles, real-time traffic information, entertainment.. Arnaud Casteigts October 21, / 41

8 Quick Overview VANETs The vision [car-2-car.org] Arnaud Casteigts October 21, / 41

9 Technological context Architecture and Protocols Arnaud Casteigts October 21, / 41

10 Technological context Architecture Three levels architecture (note: global picture to be moved here, from a few slides later) In-Vehicle Domain On-Board Unit (OBU) Application Unit (AU) local network/bus to link the OBU with all AUs OBU responsible for all shared resources between AUs (including external communications). Arnaud Casteigts October 21, / 41

11 Technological context Architecture Three levels architecture (note: global picture to be moved here, from a few slides later) In-Vehicle Domain On-Board Unit (OBU) Application Unit (AU) local network/bus to link the OBU with all AUs OBU responsible for all shared resources between AUs (including external communications). Ad Hoc Domain Vehicles to Vehicles (OBUs to OBUs) Vehicles to Infrastructure (OBUs to RSUs) Arnaud Casteigts October 21, / 41

12 Technological context Architecture Three levels architecture (note: global picture to be moved here, from a few slides later) In-Vehicle Domain On-Board Unit (OBU) Application Unit (AU) local network/bus to link the OBU with all AUs OBU responsible for all shared resources between AUs (including external communications). Ad Hoc Domain Vehicles to Vehicles (OBUs to OBUs) Vehicles to Infrastructure (OBUs to RSUs) Infrastructure Domain RSUs to RSUs RSUs to Internet but also possibly.. vehicles using Wi-Fi Hot Spots or 3G/4G cellular networks (why not?) Arnaud Casteigts October 21, / 41

13 Technological context Standards Necessity of standards Vehicles of all categories and all brands must be able to communicate with each other Standardization bodies: ASTM, IEEE, SAE, ISO Car manufacturers, consortiums, projects..: picture from [Olariu & Abuelela, NOTICE slides] Arnaud Casteigts October 21, / 41

14 Technological context Standards Physical and Mac layers DSRC standard Dedicated Short-Range Communication 5.9GHz (U.S.), 5.8GHz (Japan, Europe) p (MAC & PHY) Wi-Fi and Others a/b/g for use of classical Hot Spots (e.g. in cities) FM, cellular (e.g. UMTS), etc. (possibility of full coverage) Arnaud Casteigts October 21, / 41

15 Technological context Standards Physical and Mac layers DSRC standard (Required) Dedicated Short-Range Communication 5.9GHz (U.S.), 5.8GHz (Japan, Europe) p (MAC & PHY) Wi-Fi and Others (Optional) a/b/g for use of classical Hot Spots (e.g. in cities) FM, cellular (e.g. UMTS), etc. (possibility of full coverage) Arnaud Casteigts October 21, / 41

16 Technological context Standards Network Layer New dedicated protocols (VANETs protocols) broadcasting (mostly geocasting..) routing on top of p Existing protocols IPv6 (+Option Mobile IPv6) on top of other radios ( a/b/g, UMTS...) or p (through encapsulation in dedicated VANETs protocols) Arnaud Casteigts October 21, / 41

17 Technological context Standards Transport Layer Still under discussion in consortiums.. dedicated transport protocols? TCP/UDP? Arnaud Casteigts October 21, / 41

18 Technological context Standards Summarization [pictures from the Car-2-Car Consortium Manifesto] Network overview A few basic scenarios Arnaud Casteigts October 21, / 41

19 A few research problems Arnaud Casteigts October 21, / 41

20 Introduction Differents areas Broadcasting Geocasting Routing towards a given vehicle towards a geographical area Traffic optimization centralized (Central server, route request) decentralized (Car to Car traffic data dissemination) Bringing Internet into Vehicles Mobile IP NEMO Protocol Mobility Models and Connectivity purposes Mobility models Connectivity metrics Arnaud Casteigts October 21, / 41

21 Introduction Minimum assumptions Arnaud Casteigts October 21, / 41

22 Introduction Minimum assumptions Assumptions commonly agreed Arnaud Casteigts October 21, / 41

23 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Arnaud Casteigts October 21, / 41

24 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Arnaud Casteigts October 21, / 41

25 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Arnaud Casteigts October 21, / 41

26 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Arnaud Casteigts October 21, / 41

27 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Arnaud Casteigts October 21, / 41

28 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Arnaud Casteigts October 21, / 41

29 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Assumptions frequently agreed Arnaud Casteigts October 21, / 41

30 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Assumptions frequently agreed All vehicles are equipped (when not the case, referred to as the market penetration problem) Arnaud Casteigts October 21, / 41

31 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Assumptions frequently agreed All vehicles are equipped (when not the case, referred to as the market penetration problem) Some geometrical properties of roads (e.g. road width neglected, city intersections form square lattices) Arnaud Casteigts October 21, / 41

32 Introduction Minimum assumptions Assumptions commonly agreed Vehicles are GPS-enabled Beaconing (or HELLO) messages: include ID, position and velocity (speed & direction) with period of 300ms (can also be adaptive, e.g. [NG07]) Assumptions frequently agreed All vehicles are equipped (when not the case, referred to as the market penetration problem) Some geometrical properties of roads (e.g. road width neglected, city intersections form square lattices) Location service is available to vehicles Arnaud Casteigts October 21, / 41

33 Broadcasting (Geocasting) Broadcasting Motivations route discovery (not treated here) safety warning accident notifications strong deceleration of traffic flow road hazards (black ice, fallen tree, etc.) Arnaud Casteigts October 21, / 41

34 Broadcasting (Geocasting) Broadcasting Motivations route discovery (not treated here) safety warning accident notifications strong deceleration of traffic flow road hazards (black ice, fallen tree, etc.) information distribution congestion (makes it possible to choose another path ahead of road) local tourism information Arnaud Casteigts October 21, / 41

35 Broadcasting (Geocasting) Broadcasting Motivations route discovery (not treated here) safety warning accident notifications strong deceleration of traffic flow road hazards (black ice, fallen tree, etc.) information distribution congestion (makes it possible to choose another path ahead of road) local tourism information relevance of information is most often geographically delimited Broadcast Geocasting Arnaud Casteigts October 21, / 41

36 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version Arnaud Casteigts October 21, / 41

37 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version b g a c e h d f Message direction: either ahead or behind (ahead in the above example) Principle: each vehicle knows the positions of its direct neighbors ID of further neighbor (toward message direction) put in the message the further neighbor retransmits Arnaud Casteigts October 21, / 41

38 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version b g a c e h d f Message direction: either ahead or behind (ahead in the above example) Principle: each vehicle knows the positions of its direct neighbors ID of further neighbor (toward message direction) put in the message the further neighbor retransmits Arnaud Casteigts October 21, / 41

39 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version b g a c e h d f Message direction: either ahead or behind (ahead in the above example) Principle: each vehicle knows the positions of its direct neighbors ID of further neighbor (toward message direction) put in the message the further neighbor retransmits Arnaud Casteigts October 21, / 41

40 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version b g a c e h d f Message direction: either ahead or behind (ahead in the above example) Principle: each vehicle knows the positions of its direct neighbors ID of further neighbor (toward message direction) put in the message the further neighbor retransmits Arnaud Casteigts October 21, / 41

41 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version b g a c e h d f Message direction: either ahead or behind (ahead in the above example) Principle: each vehicle knows the positions of its direct neighbors ID of further neighbor (toward message direction) put in the message the further neighbor retransmits A gap may exist between real and known connectivity ( = message loss) Arnaud Casteigts October 21, / 41

42 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Basic version b g a c e h d f Message direction: either ahead or behind (ahead in the above example) Principle: each vehicle knows the positions of its direct neighbors ID of further neighbor (toward message direction) put in the message the further neighbor retransmits A gap may exist between real and known connectivity ( = message loss) Arnaud Casteigts October 21, / 41

43 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Version with deferred retransmission time: Arnaud Casteigts October 21, / 41

44 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Version with deferred retransmission time: b g a c e h d f Principle: each vehicle knows the positions of its direct neighbors messages are sent without including next retransmitter ID on reception, vehicles defer retransmitting for time inversely proportional to their distance from sender (the further, the sooner). when receiving a copy of the same message, cars notice neighbors that have been covered by it (based on known positions) if no neighbors remain uncovered when deferred time expires, retransmission is canceled Arnaud Casteigts October 21, / 41

45 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Version with deferred retransmission time: b g a c e h d f Principle: each vehicle knows the positions of its direct neighbors messages are sent without including next retransmitter ID on reception, vehicles defer retransmitting for time inversely proportional to their distance from sender (the further, the sooner). when receiving a copy of the same message, cars notice neighbors that have been covered by it (based on known positions) if no neighbors remain uncovered when deferred time expires, retransmission is canceled Arnaud Casteigts October 21, / 41

46 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Version with deferred retransmission time: b g a c e h d f Principle: each vehicle knows the positions of its direct neighbors messages are sent without including next retransmitter ID on reception, vehicles defer retransmitting for time inversely proportional to their distance from sender (the further, the sooner). when receiving a copy of the same message, cars notice neighbors that have been covered by it (based on known positions) if no neighbors remain uncovered when deferred time expires, retransmission is canceled Arnaud Casteigts October 21, / 41

47 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Version with deferred retransmission time: b g a c e h d f Principle: each vehicle knows the positions of its direct neighbors messages are sent without including next retransmitter ID on reception, vehicles defer retransmitting for time inversely proportional to their distance from sender (the further, the sooner). when receiving a copy of the same message, cars notice neighbors that have been covered by it (based on known positions) if no neighbors remain uncovered when deferred time expires, retransmission is canceled Arnaud Casteigts October 21, / 41

48 Broadcasting (Geocasting) Two GPS-based broadcasting algorithms, Sun et al. [SFL + 00] Version with deferred retransmission time: b g a c e h d f Principle: each vehicle knows the positions of its direct neighbors messages are sent without including next retransmitter ID on reception, vehicles defer retransmitting for time inversely proportional to their distance from sender (the further, the sooner). when receiving a copy of the same message, cars notice neighbors that have been covered by it (based on known positions) if no neighbors remain uncovered when deferred time expires, retransmission is canceled Arnaud Casteigts October 21, / 41

49 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version Arnaud Casteigts October 21, / 41

50 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Arnaud Casteigts October 21, / 41

51 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Arnaud Casteigts October 21, / 41

52 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Arnaud Casteigts October 21, / 41

53 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Arnaud Casteigts October 21, / 41

54 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Arnaud Casteigts October 21, / 41

55 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Basic version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Arnaud Casteigts October 21, / 41

56 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Arnaud Casteigts October 21, / 41

57 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Arnaud Casteigts October 21, / 41

58 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b c a Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Arnaud Casteigts October 21, / 41

59 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b f c a e Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Arnaud Casteigts October 21, / 41

60 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b f c a e Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Wait a random time before first retransmission Arnaud Casteigts October 21, / 41

61 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b f? c a e? Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Wait a random time before first retransmission Arnaud Casteigts October 21, / 41

62 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b f? c a e? Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Wait a random time before first retransmission e.g. if random f < random e, then e doesn t retransmit Arnaud Casteigts October 21, / 41

63 Broadcasting (Geocasting) Cooperative Collision Avoidance, Biswas, Tatchikou, and Dion [BTD06] Optimized version d b f c a e Principle: If an accident is detected, starts forwarding a warning message at regular intervals Blind flooding, every car retransmits all warnings Optimizations: Stop forwarding when the warning is received from behind Wait a random time before first retransmission e.g. if random f < random e, then e doesn t retransmit Arnaud Casteigts October 21, / 41

64 Broadcasting (Geocasting) Probability-based warning delivery protocol, Fracchia and Meo [FM08] limit of the danger area Principle: Every car within the danger area retransmits with probability p Several broadcasting cycles, at regular interval D. Arnaud Casteigts October 21, / 41

65 Broadcasting (Geocasting) Probability-based warning delivery protocol, Fracchia and Meo [FM08] limit of the danger area???? :retransmits with probability p x :does not retransmit Principle: Every car within the danger area retransmits with probability p Several broadcasting cycles, at regular interval D. Arnaud Casteigts October 21, / 41

66 Broadcasting (Geocasting) Probability-based warning delivery protocol, Fracchia and Meo [FM08] limit of the danger area??? :retransmits with probability p x :does not retransmit Principle: Every car within the danger area retransmits with probability p Several broadcasting cycles, at regular interval D. Arnaud Casteigts October 21, / 41

67 Broadcasting (Geocasting) Probability-based warning delivery protocol, Fracchia and Meo [FM08] limit of the danger area x x? :retransmits with probability p x :does not retransmit Principle: Every car within the danger area retransmits with probability p Several broadcasting cycles, at regular interval D. Arnaud Casteigts October 21, / 41

68 Broadcasting (Geocasting) Probability-based warning delivery protocol, Fracchia and Meo [FM08] limit of the danger area x x Principle: Every car within the danger area retransmits with probability p Several broadcasting cycles, at regular interval D. some questions remain unsolved (e.g. which car regularly initiates cycles, and what happens if those cars leave the danger area before others arrive?) Arnaud Casteigts October 21, / 41

69 Broadcasting (Geocasting) Probability-based warning delivery protocol, Fracchia and Meo [FM08] limit of the danger area x x Principle: Every car within the danger area retransmits with probability p Several broadcasting cycles, at regular interval D. some questions remain unsolved (e.g. which car regularly initiates cycles, and what happens if those cars leave the danger area before others arrive?) probabilities no guarantee! Arnaud Casteigts October 21, / 41

70 Broadcasting (Geocasting) Conclusion Recurrent drawbacks what if temporary partitions (i.e., DTN networks) no use of relay nodes outside the danger area to reach disconnected vehicles inside the danger area Some suggestions make use of vehicles in the opposite lane make use of infrastructure (RSUs) when available optimize broadcasting using Connected Dominating Sets [SSZ02] address the DTN nature of VANETs Arnaud Casteigts October 21, / 41

71 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Arnaud Casteigts October 21, / 41

72 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Arnaud Casteigts October 21, / 41

73 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Internet Protocol (enables IP communications) Arnaud Casteigts October 21, / 41

74 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Internet Protocol (enables IP communications) Team synchronization (e.g. firemen, policemen, medical staff) Arnaud Casteigts October 21, / 41

75 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Internet Protocol (enables IP communications) Team synchronization (e.g. firemen, policemen, medical staff) Road Assumptions: Arnaud Casteigts October 21, / 41

76 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Internet Protocol (enables IP communications) Team synchronization (e.g. firemen, policemen, medical staff) Road Assumptions: Highway (single- or multi-lane, uni or bi-directional?) Arnaud Casteigts October 21, / 41

77 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Internet Protocol (enables IP communications) Team synchronization (e.g. firemen, policemen, medical staff) Road Assumptions: Highway (single- or multi-lane, uni or bi-directional?) City (Square blocs? Roads form regular lattice?) Arnaud Casteigts October 21, / 41

78 Routing Routing (Unicast) Motivations Unicast: why addressing only one car? Car tracking (e.g. stolen car or friend car) Internet Protocol (enables IP communications) Team synchronization (e.g. firemen, policemen, medical staff) Road Assumptions: Highway (single- or multi-lane, uni or bi-directional?) City (Square blocs? Roads form regular lattice?) Other general assumptions (next slide) Arnaud Casteigts October 21, / 41

79 Routing Routing Assumptions Type of Destination / Location Service? A1-Fixed geographic location A2-Moving vehicle with known and updated location A3-Moving vehicle with unknown location Arnaud Casteigts October 21, / 41

80 Routing Routing Assumptions Type of Destination / Location Service? A1-Fixed geographic location A2-Moving vehicle with known and updated location A3-Moving vehicle with unknown location Plan of movement? B1-Known (sent to a central server or to vehicles nearby) B2-Unknown Arnaud Casteigts October 21, / 41

81 Routing Routing Assumptions Type of Destination / Location Service? A1-Fixed geographic location A2-Moving vehicle with known and updated location A3-Moving vehicle with unknown location Plan of movement? B1-Known (sent to a central server or to vehicles nearby) B2-Unknown Network connectivity? C1-Any pair (source, destination) is connected via other cars C2-Source and destination may not be instantaneously connected via other cars Arnaud Casteigts October 21, / 41

82 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Arnaud Casteigts October 21, / 41

83 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment Arnaud Casteigts October 21, / 41

84 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment Flooding for route discovery Arnaud Casteigts October 21, / 41

85 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment Flooding for route discovery Intersections recorded as anchors in the flooding message Arnaud Casteigts October 21, / 41

86 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment Flooding for route discovery Intersections recorded as anchors in the flooding message Selection of best route at destination Arnaud Casteigts October 21, / 41

87 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment Flooding for route discovery Intersections recorded as anchors in the flooding message Selection of best route at destination Route back to the source Arnaud Casteigts October 21, / 41

88 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment 2. Normal routing Geocasting toward next anchor Arnaud Casteigts October 21, / 41

89 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment 2. Normal routing Geocasting toward next anchor Until destination is reached Arnaud Casteigts October 21, / 41

90 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment 2. Normal routing 3. Mobility management Arnaud Casteigts October 21, / 41

91 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle guard ( ) 1. Route establishment 2. Normal routing 3. Mobility management Guards to guide messages Arnaud Casteigts October 21, / 41

92 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] guard ( ) guard ( ) Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment 2. Normal routing 3. Mobility management Guards to guide messages Arnaud Casteigts October 21, / 41

93 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment 2. Normal routing 3. Mobility management Guards to guide messages Route update at destination Arnaud Casteigts October 21, / 41

94 Routing City Scenario - Maintainance of a route, Naumov and Gross [NG07] Assumptions Moving destination, no location service (A3) No plan of movement (B2) Source and destination connected, or so. (C1) Principle 1. Route establishment 2. Normal routing 3. Mobility management Drawback This protocol requires the existence of contemporaneous end-to-end connectivity to work (no DTN) Arnaud Casteigts October 21, / 41

95 Routing City Scenario - Using plans of movements, Leontiadis and Mascolo [LM07] Using plans of movements (no picture yet) Assumptions: Destination is a fixed point whose location is known (A1) Cars exchange plans of movement with each other (B1) End-to-end connectivity is partially assumed (C1) Arnaud Casteigts October 21, / 41

96 Routing City Scenario - Using plans of movements, Leontiadis and Mascolo [LM07] Using plans of movements (no picture yet) Assumptions: Destination is a fixed point whose location is known (A1) Cars exchange plans of movement with each other (B1) End-to-end connectivity is partially assumed (C1) Principle: Neighboring cars exchange their plans of movement Based on them, the source car gives the message custody to the car for which the estimated delivery time t is minimized for each car, t is computed by finding the nearest point (NP) to the destination along the car trajectory, and then by evaluating the time to drive to NP + the time for another car to drive from NP to Destination Arnaud Casteigts October 21, / 41

97 Routing City Scenario - Using plans of movements, Leontiadis and Mascolo [LM07] Using plans of movements (no picture yet) Assumptions: Destination is a fixed point whose location is known (A1) Cars exchange plans of movement with each other (B1) End-to-end connectivity is partially assumed (C1) Principle: Neighboring cars exchange their plans of movement Based on them, the source car gives the message custody to the car for which the estimated delivery time t is minimized for each car, t is computed by finding the nearest point (NP) to the destination along the car trajectory, and then by evaluating the time to drive to NP + the time for another car to drive from NP to Destination Segment from NP to destination is unpredictable (e.g. sparse, closed, or empty roads) Arnaud Casteigts October 21, / 41

98 Routing City Scenario - Using plans of movements, Leontiadis and Mascolo [LM07] Using plans of movements (no picture yet) Assumptions: Destination is a fixed point whose location is known (A1) Cars exchange plans of movement with each other (B1) End-to-end connectivity is partially assumed (C1) Principle: Neighboring cars exchange their plans of movement Based on them, the source car gives the message custody to the car for which the estimated delivery time t is minimized for each car, t is computed by finding the nearest point (NP) to the destination along the car trajectory, and then by evaluating the time to drive to NP + the time for another car to drive from NP to Destination Segment from NP to destination is unpredictable (e.g. sparse, closed, or empty roads) Limits message speed to vehicle speeds Arnaud Casteigts October 21, / 41

99 Routing Highway Scenario - DPP protocol, Little and Agarwal [LA05] Incoming clusters to bridge connectivity gaps Arnaud Casteigts October 21, / 41

100 Routing Highway Scenario - DPP protocol, Little and Agarwal [LA05] Incoming clusters to bridge connectivity gaps Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: opportunistically, incoming clusters are used to bridge consecutive clusters in the same lane Arnaud Casteigts October 21, / 41

101 Routing Highway Scenario - DPP protocol, Little and Agarwal [LA05] Incoming clusters to bridge connectivity gaps Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: opportunistically, incoming clusters are used to bridge consecutive clusters in the same lane Arnaud Casteigts October 21, / 41

102 Routing Highway Scenario - DPP protocol, Little and Agarwal [LA05] Incoming clusters to bridge connectivity gaps Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: opportunistically, incoming clusters are used to bridge consecutive clusters in the same lane Arnaud Casteigts October 21, / 41

103 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message Arnaud Casteigts October 21, / 41

104 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message b a Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

105 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message b a Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

106 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message b a Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

107 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message b Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

108 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message b Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

109 Routing Highway Scenario - Wisitpongphan et al. [WBM + 07] Incoming clusters to carry the message b Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while No routing implicitely assumed within incoming cluster Arnaud Casteigts October 21, / 41

110 Routing Highway Scenario - Abuelela, Olariu & Stojmenovic [AOS08] Incoming clusters to carry and route optimally the message Arnaud Casteigts October 21, / 41

111 Routing Highway Scenario - Abuelela, Olariu & Stojmenovic [AOS08] Incoming clusters to carry and route optimally the message b a Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

112 Routing Highway Scenario - Abuelela, Olariu & Stojmenovic [AOS08] Incoming clusters to carry and route optimally the message b a Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while Arnaud Casteigts October 21, / 41

113 Routing Highway Scenario - Abuelela, Olariu & Stojmenovic [AOS08] Incoming clusters to carry and route optimally the message b a Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while During carrying time, the message progresses within the cluster Arnaud Casteigts October 21, / 41

114 Routing Highway Scenario - Abuelela, Olariu & Stojmenovic [AOS08] Incoming clusters to carry and route optimally the message b Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while During carrying time, the message progresses within the cluster Optimal delivery is achieved to the next cluster Arnaud Casteigts October 21, / 41

115 Routing Highway Scenario - Abuelela, Olariu & Stojmenovic [AOS08] Incoming clusters to carry and route optimally the message b Assumption C2 (no end-to-end connectivity assumed) Destination is a moving vehicle, located ahead or behind of the source in the same lane (ahead in the above example) Principle: Incoming cluster can carry the message for a while During carrying time, the message progresses within the cluster Optimal delivery is achieved to the next cluster not used because not optimal. Arnaud Casteigts October 21, / 41

116 Traffic optimization Traffic optimization Motivations Reduce traffic congestion Arnaud Casteigts October 21, / 41

117 Traffic optimization Traffic optimization Motivations Reduce traffic congestion Centralized (with route request) Decentralized (with dissemination) Arnaud Casteigts October 21, / 41

118 Traffic optimization Traffic optimization Motivations Reduce traffic congestion Centralized (with route request) Decentralized (with dissemination) Route selection criterions (not treated here) Arnaud Casteigts October 21, / 41

119 Traffic optimization Traffic optimization Motivations Reduce traffic congestion Centralized (with route request) Decentralized (with dissemination) Route selection criterions (not treated here) Road quality, Fuel consumption, Road lighting, etc. Arnaud Casteigts October 21, / 41

120 Traffic optimization Traffic optimization Motivations Reduce traffic congestion Centralized (with route request) Decentralized (with dissemination) Route selection criterions (not treated here) Road quality, Fuel consumption, Road lighting, etc. Quality of Travel (as QoS in communication networks) Arnaud Casteigts October 21, / 41

121 Traffic optimization Decentralized Traffic Management Systems Dissemination of Traffic Information Arnaud Casteigts October 21, / 41

122 Traffic optimization Decentralized Traffic Management Systems Dissemination of Traffic Information i j Ohara, Nojima, and Ishibuchi [ONI07] Edge weight initialized with trunk lengths a b c b e f g h k l Arnaud Casteigts October 21, / 41

123 Traffic optimization Decentralized Traffic Management Systems Dissemination of Traffic Information i j a b c b edge time (i,b) 45s (b,c) 37s Ohara, Nojima, and Ishibuchi [ONI07] Edge weight initialized with trunk lengths Cars measure travel time for passed trunks edge time (e,f) 23s (f,g) 51s e f g h k l Arnaud Casteigts October 21, / 41

124 Traffic optimization Decentralized Traffic Management Systems Dissemination of Traffic Information i j a b c b edge time (i,b) 45s (b,c) 37s (e,f) 23s (f,g) 51s e f g h Ohara, Nojima, and Ishibuchi [ONI07] Edge weight initialized with trunk lengths Cars measure travel time for passed trunks Cars exchange (and confront) measured time Averages done (ponderation with freshness) Real-time traffic information available to in-car navigation devices k l Arnaud Casteigts October 21, / 41

125 Traffic optimization Decentralized Traffic Management Systems Dissemination of Traffic Information i j a b c b edge time (i,b) 45s (b,c) 37s (e,f) 23s (f,g) 51s e f g h Ohara, Nojima, and Ishibuchi [ONI07] Edge weight initialized with trunk lengths Cars measure travel time for passed trunks Cars exchange (and confront) measured time Averages done (ponderation with freshness) Real-time traffic information available to in-car navigation devices hard to avoid the flash crowd effect! k l Arnaud Casteigts October 21, / 41

126 Traffic optimization Decentralized Traffic Management Systems Dissemination of Traffic Information i j a b c b edge time (i,b) 45s (b,c) 37s (e,f) 23s (f,g) 51s e f g h Ohara, Nojima, and Ishibuchi [ONI07] Edge weight initialized with trunk lengths Cars measure travel time for passed trunks Cars exchange (and confront) measured time Averages done (ponderation with freshness) Real-time traffic information available to in-car navigation devices hard to avoid the flash crowd effect! Some other papers Similar schemes can be found in [SFUH04] and [STK + 06] k l Arnaud Casteigts October 21, / 41

127 Traffic optimization Centralized Traffic Regulation Systems Shortest path in time-varying weighted graph Traffic Center Arnaud Casteigts October 21, / 41

128 Traffic optimization Centralized Traffic Regulation Systems Shortest path in time-varying weighted graph route? Traffic Center Arnaud Casteigts October 21, / 41

129 Traffic optimization Centralized Traffic Regulation Systems Shortest path in time-varying weighted graph 5 4 Existing algorithms (static) Dijkstra algorithm ([Dij59]) (static) A algorithm ([HNR68]) (dynamic) A algorithm (Chabini & Lan [CL02]) (others, dynamic) [ZM93, CH66, Cha98] Arnaud Casteigts October 21, / 41

130 Traffic optimization Centralized Traffic Regulation Systems Shortest path in time-varying weighted graph 5 4 Existing algorithms (static) Dijkstra algorithm ([Dij59]) (static) A algorithm ([HNR68]) (dynamic) A algorithm (Chabini & Lan [CL02]) (others, dynamic) [ZM93, CH66, Cha98] 3 4 Computation of future weights Decisions influence future weights Congestion prediction (historic, events, etc.) Fine-grain time (or flash crowd effect!) Arnaud Casteigts October 21, / 41

131 Traffic optimization Centralized Traffic Regulation Systems Shortest path in time-varying weighted graph 5 4 Existing algorithms (static) Dijkstra algorithm ([Dij59]) (static) A algorithm ([HNR68]) (dynamic) A algorithm (Chabini & Lan [CL02]) (others, dynamic) [ZM93, CH66, Cha98] 3 4 Computation of future weights Decisions influence future weights Congestion prediction (historic, events, etc.) Fine-grain time (or flash crowd effect!) Complete frameworks Harvesting protocols (real-time statistics) 2 4 Routing (for route request / route answer) Central processing: algorithms, cache, forecast.. example: Traffcon (Collins & Muntean [CM08]) Arnaud Casteigts October 21, / 41

132 Bringing Internet into Vehicles Bringing Internet into Vehicles Arnaud Casteigts October 21, / 41

133 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Arnaud Casteigts October 21, / 41

134 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Arnaud Casteigts October 21, / 41

135 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Integrated phone, VoIP,.. Arnaud Casteigts October 21, / 41

136 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Integrated phone, VoIP,.. Entertainment for passengers Arnaud Casteigts October 21, / 41

137 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Integrated phone, VoIP,.. Entertainment for passengers Real-time information everywhere Arnaud Casteigts October 21, / 41

138 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Integrated phone, VoIP,.. Entertainment for passengers Real-time information everywhere Meteo alerts Arnaud Casteigts October 21, / 41

139 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Integrated phone, VoIP,.. Entertainment for passengers Real-time information everywhere Meteo alerts etc. Arnaud Casteigts October 21, / 41

140 Bringing Internet into Vehicles Bringing Internet into Vehicles Motivations Several motivations: Traffic Information Server on the web Integrated phone, VoIP,.. Entertainment for passengers Real-time information everywhere Meteo alerts etc. Active research areas IP Mobile, Network Mobility (NEMO) Nested-NEMO, route optimization for NEMO Spanning tree maintainance from RSUs to Vehicles (not treated here) Arnaud Casteigts October 21, / 41

141 Bringing Internet into Vehicles Mobile IP Without Mobile IP Corresponding Node Internet BSSID 1 BSSID 2 Arnaud Casteigts October 21, / 41

142 Bringing Internet into Vehicles Mobile IP Without Mobile IP Corresponding Node Internet BSSID 1 BSSID 2 Arnaud Casteigts October 21, / 41

143 Bringing Internet into Vehicles Mobile IP Without Mobile IP Corresponding Node Internet BSSID 1 BSSID 2 Change of IP address = disconnection with Corresponding Node Arnaud Casteigts October 21, / 41

144 Bringing Internet into Vehicles Mobile IP Using Mobile IP Corresponding Node Home Agent Internet BSSID 1 BSSID 2 Arnaud Casteigts October 21, / 41

145 Bringing Internet into Vehicles Mobile IP Using Mobile IP Corresponding Node Home Agent Internet BSSID 1 BSSID 2 Arnaud Casteigts October 21, / 41

146 Bringing Internet into Vehicles Mobile IP Using Mobile IP Corresponding Node Home Agent Internet BSSID 1 BSSID 2 Change of IP address OK, seamless for Corresponding Node Arnaud Casteigts October 21, / 41

147 Bringing Internet into Vehicles Mobile IP Using Mobile IP Corresponding Node Home Agent Drawbacks What if several IP devices in a car? No multihop in the Ad Hoc Domain (distance 1 needed to RSU) Internet BSSID 1 BSSID 2 Change of IP address OK, seamless for Corresponding Node Arnaud Casteigts October 21, / 41

148 Bringing Internet into Vehicles NEMO (Network Mobility) [RFC3963] Principle extension of Mobile IP nodes are networks (i.e. addresses = range of addresses) OBU manages the local network inside the car, then addresses are mapped to public and stable addresses by the Home Agent Does it solve the problems? multiple IP devices in vehicles, yes multi-hops Internet access in Ad Hoc Domain, not enough Arnaud Casteigts October 21, / 41

149 Bringing Internet into Vehicles Nested NEMO (1) Principle NEMO n attach a vehicle to another vehicle as if it was an inner IP device Dev 2 OBU Dev 1 OBU Arnaud Casteigts October 21, / 41

150 Bringing Internet into Vehicles Nested NEMO (1) Principle NEMO n attach a vehicle to another vehicle as if it was an inner IP device Dev 2 OBU Dev 1 OBU works, but may lead to sub-optimal routing paths such as Car n Car n-1...car 1 Home Agent 1... Home Agent n-1 Home Agent n CN when a car communicates with a distant node on the Internet, through n-1 other cars Arnaud Casteigts October 21, / 41

151 Bringing Internet into Vehicles Nested NEMO (2) Route optimization (VANEMO) Use NEMO in Infrastructure Domain and VANET routing protocols in Ad Hoc Domain Make it work together Work in progress.. [BFA07, BSC + 07, MED06, WMK + 05] Arnaud Casteigts October 21, / 41

152 Mobility Models and Connectivity Mobility Models and Connectivity Arnaud Casteigts October 21, / 41

153 Mobility Models and Connectivity Mobility Models and Connectivity Motivations Better understanding of VANETs deepest nature Arnaud Casteigts October 21, / 41

154 Mobility Models and Connectivity Mobility Models and Connectivity Motivations Better understanding of VANETs deepest nature Better design of protocols Arnaud Casteigts October 21, / 41

155 Mobility Models and Connectivity Mobility Models and Connectivity Motivations Better understanding of VANETs deepest nature Better design of protocols Fundamental characteristics of VANETs Highly constrained mobility Arnaud Casteigts October 21, / 41

156 Mobility Models and Connectivity Mobility Models and Connectivity Motivations Better understanding of VANETs deepest nature Better design of protocols Fundamental characteristics of VANETs Highly constrained mobility Unlimited size and population Arnaud Casteigts October 21, / 41

157 Mobility Models and Connectivity Mobility Models and Connectivity Motivations Better understanding of VANETs deepest nature Better design of protocols Fundamental characteristics of VANETs Highly constrained mobility Unlimited size and population Almost no chance to meet a node several times Arnaud Casteigts October 21, / 41

158 Mobility Models and Connectivity Mobility Models and Connectivity Motivations Better understanding of VANETs deepest nature Better design of protocols Fundamental characteristics of VANETs Highly constrained mobility Unlimited size and population Almost no chance to meet a node several times Not always connected, specific connectivity Arnaud Casteigts October 21, / 41

159 Mobility Models and Connectivity Lattice Percolation Theory (used in [SHW + 08]) Arnaud Casteigts October 21, / 41

160 Mobility Models and Connectivity Lattice Percolation Theory (used in [SHW + 08]) Question: what density d car to have the entire network connected? Arnaud Casteigts October 21, / 41

161 Mobility Models and Connectivity Lattice Percolation Theory (used in [SHW + 08]) Let p ct be the probability for one trunk to be connected Question: what density d car to have the entire network connected? Arnaud Casteigts October 21, / 41

162 Mobility Models and Connectivity Lattice Percolation Theory (used in [SHW + 08]) Let p ct be the probability for one trunk to be connected Question: what density d car to have the entire network connected? Lattice Percolation Theory says: p ct > 0.5 = v 1, v 2, p path (v 1, v 2 ) 1 Arnaud Casteigts October 21, / 41

163 Mobility Models and Connectivity Lattice Percolation Theory (used in [SHW + 08]) Let p ct be the probability for one trunk to be connected Question: what density d car to have the entire network connected? Lattice Percolation Theory says: p ct > 0.5 = v 1, v 2, p path (v 1, v 2 ) 1 Critical density: d car such that p ct > 0.5 depends on the mobility model considered.. Arnaud Casteigts October 21, / 41