Abiding Geocast: Time-stable Geocast for Ad Hoc Networks

1. Abiding Geocast: Time-stable Geocast for Ad Hoc Networks Christian Maihöfer, Tim Leinmüller and Elmar Schoch VANET 2005 September 2, 2005

2. Overview • Motivation for geocast and abiding geocast in vanets • Background of geocast • Abiding Geocast Semantics • Design Space • Abiding Geocast Approaches • Server Approach • Election Approach • Neighbor Approach • Evalution • Analytical and simulation Results • Related Work • Summary

3. Area of sight Our Motivation in a Vehicular Ad Hoc Network • Motivation for this work: • Realize virtual traffic signs with geocast: • Virtual traffic signs increase the driver’s area of sight • Accident warning, wrong-way driver warning, icy road warning, ... • Fast adaptation to current traffic situation

4. Our Motivation in a Vehicular Ad Hoc Network Area of sight • Motivation for this work: • Realize virtual traffic signs with geocast: • Virtual traffic signs increase the driver’s area of sight • Accident warning, wrong-way driver warning, icy road warning, ... • Fast adaptation to current traffic situation

5. Background of Geocast • Def. Geocast: Transmission of a message to some or all nodes within a geographical area. • Geocast makes sense only in position-aware networks, since definition makes position-awareness necessary • If the network is position-aware anyway, we use a position-aware routing protocol! • Prominent example for a location-based (unicast) routing protocol: greedy parameter stateless routing (GPSR)

6. Background of Abiding Geocast For the introduced applications, in many cases all (anonymous) devices (e.g. vehicles) in an area are addressed (and not a single vehicle by its fixed and known address) • Therefore, Geocast seems to be the natural approach • Def. Geocast: Transmission of a message to some or all nodes within a geographical area Using or setting up an infrastructure-based network (like GPRS, UMTS, …) has disadvantages (costs, message delivery delay, availability) • Therefore, an ad hoc network seams to be the natural approach Abiding Geocast • Current Geocast approaches for ad hoc networks deliver a message only once • We need a periodically or on-demand Geocast every time a mobile node enters the geocast’s destination region • Def. Abiding Geocast: A time stable geocast, which is delivered to some or all nodes that are inside a destination region within a certain period of time

7. Abiding Geocast Design Space Geocast protocol infrastructure-based infrastructure-less • Design space dimensions/building blocks: • 1) The underlying geocast routing protocol • Necessary for the initial delivery and • Possibly, necessary for the subsequent deliveries, too • 2) The storage of geocasts within their lifetime • Infrastructure-based on a central server or • Infrastructure-less, i.e. distributed on some or all nodes of the network • 3) The hand over of stored geocast messages to other nodes • Hand over is required, when the node used for message storage is no longer a good candidate (e.g. if the storing node is no longer near the destination region) • Can be triggered when a new node enters the destination region or • When the storing node leaves the destination region • 4) The delivery of geocast messages to their intended destination nodes • Blind periodical resending to reach new nodes or • On demand when a new node enters the destination region Message storage on entry Message hand over on leave Message delivery periodically notification

8. Geocast server geocast unicast Geocast destination region sender Stored Geocast: Server Approach • Overview: • A server is used to store Geocast messages • Not necessarily close to the destination region • May be central to the whole network or an arbitrary node • Message delivery is done periodically or by notification • Details of message delivery: • Sender unicasts the message to the geocast server • Server uses a geocast routing protocol to deliver the message to the destination • Deliveries can be done periodically or by notification from moving nodes

9. Elected node Geocast destination region sender Stored Geocast: Election Approach • Overview • A node in the geocast destination region is elected to store geocast messages • Hand over of messages is done when this node leaves the destination region • Message delivery is done periodically or by notification • Details of message delivery • Each node in the destination region is a candidate for election but it is desirable to choose one which stays as long as possible inside the destination region • The initial sender of a geocast message uses a regular geocast routing protocol • Inside the destination region, all nodes receive the geocast and start the election process • The elected node stores the message and delivers it periodically or on notification • If the elected node leaves the destination region, a new election round is started and the message is handed over to the new elected node • Note: Most simple election strategy is that the first node inside the destination region (which switches from unicast to flooding)is the elected nodes

10. geocast sender Geocast destination region Stored Geocast: Neighbor Approach • Overview • Each node stores all geocast messages destined for its location • If a node within a geocast destination region detects a new neighbor, it delivers the geo-cast message to it, i.e. hand over is done on entry, message delivery is done by notification • Details of message delivery • The initial sender of a geocast message uses a regular geocast routing protocol • Each node maintains a neighbortable, with their locations • After the first delivery, geocast information is exchanged between neighbors inside the destination region (achieved by simply extending the location-based unicast protocol) to decide whether all neighbors have received all relevant geocasts • E.g., the most simple approach is to store the neighbor ids. If a new id is detected, then the geocast is delivered and the id is stored. • Note: After the initial delivery,subsequent deliveries are done without a geocast routing protocol

11. Evaluation • Evaluation done by probabilistic analysis and verification of results by comparison with simulations • Motivation for a probabilistic model: • Simulations are quite “expensive” • Runtime of the simulations  Several weeks for the results presented here • Not possible to simulate large networks (more than 5000 nodes hardly possible) • We want to examine the influence of all parameters on the results (network size, velocities, retransmission rates, …) which is hardly possibly with the long simulation runtimes Assumptions of the probabilistic model: • Random waypoint model • Square network size area • Unicast greedy routing without perimeter mode

12. Example for analysis of the server approach • The message overhead encompasses the following three phases: • initial unicast forwarding from sender to server with bandwidth requirements (i.e. network load) Bi • unicast forwarding from server to geocast destination region with bandwidth requirements Bs • flooding inside geocast destination region with bandwidth requirements Bf • The total bandwidth requirement is then • B = Bi + (Bs + Bf) *  * , • with …retransmission rate, …geocast life time No mathematical details in this presentation  please consult the paper for that

13. Simulation Implementation • Implemented in the NS-2 simulation environment with CMU wireless extensions: • Server approach (with periodic sending scheme, 1s interval time) • Election approach (with periodic sending scheme, 1s interval time) • Neighbor approach (with list of delivered geocast messages maintained at each node) Simulation configuration: • 802.11 MAC layer, 250m wireless transmission range, RTS/CTS and ACK scheme for unicast • Ad hoc network: • 100 nodes in networks with different network area sizes • Random walk with maximum velocity 50m/s • Geocast routing protocol is implemented as follows: • Unicast greedy forwarding until destination region is reached • Inside destination region flooding is used • 60s simulation time

14. Evaluation (I) • Delivery ratio shows the success rate, i.e. the ratio of how many geocasts are received at nodes which should have received them • numerical (analytical) result simulation result • Analytical results and simulation results are pretty similar  verifies the analytical model • All 3 approaches show reasonable delivery ratios in dense networks (# of nodes constant) • In sparse networks, all approaches are not good enough for safety-related v2v applications

15. Evaluation (II) • Load is the number of sent geocast packets at forwarding or destination nodes • numerical (analytical) result simulation result • In sparse networks, approaches with local message storage and delivery are superior • In very dense networks, the neighbor unicast approach scales worse than the others  probably because neighbors change too often then (adapting the strategy could help) nevertheless, local storage should be considered as superior

16. Evaluation (III) Load is the number of sent geocast packets at forwarding or destination nodes numerical (analytical) result simulation result • The neighbor unicast approach is superior because of its on-demand delivery

17. Evaluation (IV) Load is the number of sent geocast packets at forwarding or destination nodes numerical (analytical) result simulation result • Only with very low periodic retransmission rates, the approaches with periodic delivery causes less network load but then, delivery ratio is really poor, e.g. with rate 0,1/s, neighbor unicast has delivery success > 95% while server approaches have delivery success < 50%

18. Related Work • Geocast routing protocols: • Directed flooding: GeoGRID, LBMDefine a forwaring zone as subset of the network nodes including at least sender node and destination region • Explicit route setup: GeoTORA, GeoNodeEither infrastructure based or in case of GeoTORA, based on maintaining a graph, which is, however, created with flooding • Survey on geocast routing protocols published in IEEE Communication Surveys and Tutorials (online) Regarding Stored Geocast: • Only GeoNode allows to store messages for periodical redelivery which is similar to our server approach • However, GeoNode is not designed for ad hoc networks • Assumption is that the network has a fixed cellular structure with a GeoNode assigned to each cell • Routing is done in two steps, the first between sender and GeoNode and the second between GeoNode and destination region • GeoNodes are able to store the packets they receive for periodical redelivery • Own previous work presented at KiVS 2003. However no simulation and probabilistic results.

19. Summary • This is the first work on a probabilistic model for a time stable geocast in ad hoc networks • We have motivated our work with the idea of virtual warning signs. We expect abiding geocast to be useful especially in vehicular ad hoc networks. • We have presented three reasonable implementation approaches • We have introduced the corresponding probabilistic models • Simulation results and probabilistic model show that: • All approaches achieve a good delivery ratio with respect to the chosen scenario if the network is reasonably dense • In many cases, local storage and on-demand delivery is superior to other approaches • Note: Virtual warning signs can be realized even in sparse networks as geocasts are delivered to the vicinity of the sender. Therefore, message loss is less likely to occur than in our simulated (worst case) scenarios.

20. Appendix

21. increased destination region i . d i . d - 2 s . d Stored Geocast: Server Approach • Some implications for periodic delivery: • Minimum message delivery frequency:f c / v , 0<cs.d • For example, v = 55m/s (200km/h), c = 1000m periodic interval = 18 s • If c is very small or even 0, the frequency would be infinite • define an increased destination region, that is larger than the actual intended destination region • the minimum crossing distance c is then increased by the difference of the two diametersf (i.d - s.d + c) / v , i.d>s.d, 0  cs.d Implication for notification scheme: • Notification after moving the distance d:d c or d  (i.d - s.d + c) • For example, vØ = 17m/s (60km/h), c = 1000m periodic interval = 60 s • f...Message delivery frequencyc...minimum crossing distancev...maximum velocitys.d...diameter of the destination region actual destination s . region d

22. elected node s . d stored geocast n . destination region d location notification location notification elected node stored geocast destination region d . n d d Stored Geocast: Election Approach • For periodic delivery, see the observations from the server approach • Implications for notification scheme: • A location notification report has to be sent as a geocast message to a destination region with the node’s actual destination as the center. • The diameter of the location notification geocast n.d has to be no smaller than the doubled diameter of the geocast messagesn.d 2*max(s  {stored geocasts}: s.d) • Location notification after moving the distance d:d c ord  (i.d - s.d + c)