A routing strategy for vehicular ad hoc networks in city environments

Routing of data in a vehicular ad hoc network is a challenging task due to the high dynamics of such a network. Recently, it was shown for the case of highway traffic that position-based routing approaches can very well deal with the high mobility of
of 6
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A Routing Strategy for Vehicular Ad Hoc Networks in CityEnvironments 1 Christian Lochert Hannes Hartenstein Jing Tian Network Laboratories Network Laboratories Distributed Systems DepartmentNEC Europe Ltd. NEC Europe Ltd. University of StuttgartHeidelberg, Germany Heidelberg, Germany Stuttgart, Holger Füßler Dagmar Hermann Martin Mauve Department of Computer Science Traffic Assistance Systems Department of Computer ScienceUniversity of Mannheim DaimlerChrysler AG University of MannheimMannheim, Germany Stuttgart, Germany Mannheim, Abstract  Routing of data in a vehicular ad hoc network is a chal-lenging task due to the high dynamics of such a network. Recently, it was shown for the case of highway trafficthat position-based routing approaches can very well dealwith the high mobility of network nodes. However, base-line position-based routing has difficulties to handle two-dimensional scenarios with obstacles (buildings) and voidsas it is the case for city scenarios. In this paper we an-alyze a position-based routing approach that makes use of the navigational systems of vehicles. By means of simula-tion we compare this approach with non-position-based ad hoc routing strategies (Dynamic Source Routing and Ad- Hoc On-Demand Distance Vector Routing). The simula-tion makes use of highly realistic vehicle movement pat-terns derived from DaimlerChrysler’s Videlio traffic simu-lator. While DSR’s performance is limited due to problemswith scalability and handling mobility, both AODV and the position-based approach show good performances with the position-based approach outperforming AODV. 1 Introduction Communication between vehicles by means of wirelesstechnology has a large potential to improve traffic safetyand travel comfort of drivers and passengers. Current ad-vances in the field of wireless ad hoc networks show thatinter-vehicle communication based on vehicular ad hoc net-worksisafeasibleapproachthathasacompetitiveedgeovercellular network-based telematics with respect to several as-pects: low data transport times for emergency warnings, ro-bustness due to the network’s mesh structure, and low costsfor usage due to the use of unlicensed frequency bands. The 1 This work has been carried out within the framework of the ‘FleetNet’project as part of BMBF contract no. 01AK025D. J. Tian acknowledgessupport from EU IST Project CarTalk 2000 (IST-2000-28185). FleetNet project is currently developing a communicationplatform for inter-vehicle communication following the adhoc networking paradigm [6].Several potential applications in the area of inter-vehiclecommunications require data routing algorithms for the un-derlying ad hoc network: when communication endpointsare not within their respective radio transmission range,  uni-cast routing  is required to establish communication betweentwo vehicles or between a vehicle and a fixed gateway.Communication partners are either selected based on theiridentity, e.g., IP address, or based on their geographic po-sition. The latter case refers to applications where a personin a vehicle requests some information, e.g., on traffic flowor road conditions, from a specific geographic region. Tosupport such application,  geocast routing  [7] should also beprovided by the underlying routing protocol.Traditionaladhocroutingprotocolshavedifficultiesindeal-ing with the high mobility specific to vehicular ad hoc net-works. In a recent paper [5] we have shown for highwayscenarios that routing approaches using position informa-tion, e.g., obtained from on-board GPS receivers, can verywell deal with the mobility of the nodes. A general surveyon position-based routing approaches is presented in [12].Related to our work with its focus on vehicular networksis the work described in [14] that proposes to add geocastabilities to the Ad Hoc On-demand Distance Vector proto-col (AODV).In this paper we discuss aspects of position-based routingfor the case of vehicular ad hoc networks in a city envi-ronment. In contrast to highway scenarios, we now haveto deal with problems associated to a truly two-dimensionalsystem area as well as with problems like radio obstaclesdue to buildings. We present a simulation study that com-pares a position-based routing approach with classical adhoc routing methods (Dynamic Source Routing and Ad HocOn-Demand Distance Vector). To the best of our knowl-  edge, our study is the first one that evaluates ad hoc routingprotocols over a realistic vehicle movement pattern for a cityscenario. The vehicular traffic simulation was done using asimulation tool of DaimlerChrysler and is based on actualtraffic measurements taken in the city of Berlin, Germany.The paper is structured as follows: In Section 2 we first dis-cuss the challenges of position-based routing in a city sce-nario, show the shortcomings of existing approaches andthen outline our algorithm that is based on ideas from theTerminodes project [2] and on a proposal presented in [15]. Section 4 gives details on the generation of the vehiclemovement patterns used in our simulation study. The re-sults of the routing protocol simulations are presented anddiscussed in Section 5. Section 6 summarizes our analysis and outlines open issues. 2 Challenges of Position-Based Routing in a CityEnvironment Position-based routing bases forwarding decisions on posi-tion information. Thus, there are several requirements onthe availability of position information: first of all, position-based routing requires position-awareness of all participat-ing nodes, e.g., through a GPS receiver on each node. Fur-thermore, it is assumed that each node is aware of the po-sitions of its direct neighbors: each node periodically sendsout beacon messages that indicate the current position of the node 1 . In order to send a packet to a destination node,a sending node also requires information on the current ge-ographic position of the destination in order to include it inthe packet header and to make the routing decision. This in-formation is gained via a so-called location service. Whileseveral proposals for location services have recently beenmade in the literature [12], in this paper we make use of a very simple reactive location service (RLS) described inSection 3.With the above-mentioned information at hand a node for-wards the packet to the direct neighbor that is closest tothe destination position. This strategy is called ‘greedyposition-basedrouting’. Sincethisisapurelylocaldecision,no route setup or maintenance is required. Instead, forward-ing hops are determined ‘on the fly’. Greedy forwarding,however, can fail when there is no neighbor available that iscloser to the destination than the current forwarding hop. Insuchacase, positioninformationpointsintherightdirectionbut is not correlated with available paths to the destination.Several recovery strategies like  Perimeter Mode  in GreedyPerimeter Stateless Routing (GPSR) [9] or face-2 [3] were proposed in the literature. For the remainder of this paper,we stick to the notations and definitions of  [9]. 1 The beacon messages are not forwarded, they are only intended to in-form the direct neighbors. The perimeter mode of GPSR consists of two elements:  i)  adistributed planarization algorithm and  ii)  an online routingalgorithm for planar graphs. The planarization algorithmtransfers (locally) the connectivity graph into a planar graphby eliminating ‘redundant’ edges. The elimination criteriaused for the perimeter mode approach are illustrated in Fig-ure 1. The online routing algorithm then forwards a packetalong the faces 2 of the planar graph towards the destina-tion. Intuitively, as depicted in Figure 4(a) the packet willbe routed according to the ‘Right Hand Rule’ from node  u where perimeter mode is entered via  v ,  w ,  x , and  y  to desti-nation node  D . In case the packet traverses an inner faceand the destination is not part of the this face, the algo-rithm switches towards the face closer to the destinationnode whenever it encounters an edge that crosses the imag-inary line from the perimeter mode starting point (here:  u )to the destination node  D . By referring the reader to [9] fordetails on this algorithm, we now study the deficiencies of the perimeter mode approach for the case of city scenarios. u vw (a) GG u vw (b) RNG Figure 1:  Gabriel Graph and Relative Neighborhood Graph crite-ria for planarization: the edge between  u  and  v  is elim-inated when there is another node in the grey-shadedregion. Network disconnection.  City scenarios – with almost allarea between streets covered with buildings – significantlylimit the applicability of purely greedy position-based rout-ing and of corresponding recovery strategies. Due to these obstacles , nodes that would have ‘seen’ each other in a free-space model might not be aware of each other anymore.Since the planarization methods outlined above assume thatthe connectivity between nodes only depends on the nodedistances, planarization of the neighborhood in the presenceof obstacles can lead to network disconnection as illustratedin Figure 2. Both criteria, GG and RNG, would lead to elim-ination of the edge between  u  and  v  under the misconceptionthat nodes  w 1  and  w 2  can reach node  v . Too many hops.  A planarized connectivity graph for vehi-cles along a single street essentially leads to a graph wherea vehicle no longer sends packts to the neighbor with thelargest forward progress (Fig. 3). Thus, compared to  greedyrouting , many more nodes have to be traversed when routedin perimeter mode. This leads to increased delays and, fre-quently, to elapsed hop counts. 2 A planar graph partitions the plane in an unbounded  outer   face andseveral bounded  inner   faces.  uw_1w_2v Figure 2:  Planarization problems.(a) traversing a pla-nar graph    ✁      ✁   ✂✁✂✂✁✂✄✁✄✄✁✄☎✁☎☎✁☎✆✁✆✆✁✆✝✁✝✝✁✝✞✁✞✞✁✞✟✁✟✟✁✟ (b) greedy routing Figure 3:  Traversing a planar graph versus greedy routing. Routing Loops.  As indicated in [9, 8] mobility can inducerouting-loops for packets being routed in perimeter mode.Figure 4 sketches a corresponding scenario. Node  S   wantsto send a packet to node  D . In node  u , greedy forwardingfails because there is reachable node closer to the destina-tion node. So the forwarding mode is switched to  perimeter-mode . The initial face will be set to  uv . In a static network,the packet would reach  D  according to the ‘Right HandRule’ as expected, but with movement of node  x  reachingnode  v ’s radio range while  v  already has sent the packet,a routing loop is created between  vwx  by the ‘Right HandRule’. The traversal of the initial face would be used to de-termine a face-loop but since it is never traversed again, thepacket is circled until the max hop count is reached. Wrong Direction.  As one can see in Fig. 4(a) the perimetermode following the ‘Right Hand Rule’ is biased towards aspecific direction when selecting a next hop. When there ex-ist more than one routing alternative this can lead to routeslonger than necessary. These long routes lead again to theproblem of ‘Too many hops’ and also is prone to error be-cause of mobility. 3 Geographic Source Routing As a strategy to deal with the high mobility of nodes on theone hand and with the specific topological structure of a cityon the other hand, we have chosen a position-based routing Suvwx ybaD (a) WorkingPerimeterMode SuvwyxbaD (b) Routing Loop Figure 4:  Problems while Routing in Perimeter Mode.methodthatissupportedbyamapofthecity. Itiscalled Ge-ographic Source Routing  (GSR). The presence of a map is avalid assumption, e.g., when vehicles are equipped with on-board navigation systems. As outlined in the introduction toposition-based routing above, we make use of our ‘reactivelocation service’ in order to learn the current position of adesired communication partner.RLS is a direct translation of the route discovery procedureused in reactive non-position-based ad hoc routing protocolsto the position discovery of position-based routing. Essen-tially, the querying node floods the network with a ‘posi-tion request’ for some specific node identifier. When thenode that corresponds to the requested identifier receivesthe position request, it sends a ‘position reply’ back to thequerying node. In order to avoid extensive flooding as wellas the well-known ‘broadcast storm problem’, several opti-mizations have been implemented for RLS. An extensiveanalysis of RLS is given in [11].With this information, the sending node can compute a pathto the destination by using the underlying map of the streets.In other words, the sender computes a sequence of junctionsthe packet has to traverse in order to reach the destination.The sequence of junctions can either be put into the packetheader – as it would be done in a geographic source routingapproach [2] – or it can be computed by each forwardingnode. Clearly, there is a trade-off between bandwidth con-sumptionandrequiredprocessingperformancewhenchoos-ing between these two options. But one can see that thereare only differences in the result if a node uses informa-tion about its neighborhood, i.e., to look for connectivitybreaks of a route which was chosen before and thereforerecomputes another route to the destination. Forwarding apacket between two successive junctions is done on the ba-sis of greedy forwarding since here no ‘obstacles’ shouldblock the way. In the current implementation for our sim-ulations, the path between source and destination is deter-mined by a Dijkstra shortest path calculation based on thestreet map. Since we do not take into account whether there  are enough vehicles on a street to provide connectivity be-tween the two involved junctions, there is a large potentialto improve our results by other path-finding strategies. Sim-ulations results for the outlined methods in comparison tonon-position-based routing strategies are given in Section 5.The following section provides some insight into the mod-eling of the vehicles in a city environment. 4 City Traffic Simulations City traffic simulation itself is a complex challenge becausethe traffic flow in conurbation deeply depends on rules atits intersections and on the capacity of the roads and inter-sections. The traffic flow simulator Videlio [10], developedby DaimlerChrysler AG, is based on microscopic simulationusing time depending srcin destination matrices. Core el-ements are the Optimal Velocity Model [1], a special lanechanging model [10] and the C-logit model [16] to calculate the traffic assignments. Videlio uses a detailed descriptionof the road network with information about, e.g., lane num-bers, traffic regulations, and time tables of the traffic lights.For the vehicular movement pattern generation, a small part(6.25 km × 3.45 km) of the city of Berlin was modeled as agraph of streets with 28 vertices and 67 edges as depicted inFigures 5 and 6. In total, movements of 955 vehicles have been simulated. Figure 5:  Part of the city of Berlin modeled for our simulation. 5 Simulations and Results The simulation study presented in this section comparesthe map-based geographic source routing approach (GSR)with Dynamic Source Routing (DSR) and Ad Hoc On-Demand Distance Vector Routing (AODV), two ‘classical’non-position-based ad hoc routing strategies. Simulationswere done with the network simulator NS-2 [13] in its ver-sion ns-2.1b8a (with some bug fixes from ns-2.1b9a) with time: 2.00245 Figure 6:  Graph of streets of our vehicular movement simula-tions. the CMU-extensions [4]. The simulator wasextended withabasic form of   obstacle modeling : spaces between streets areassumed to be buildings and, therefore, radio waves cannotpropagate through them. Thus, two nodes can only com-municate directly with each other when they are in theirrespective transmission ranges and also obey the ‘line-of-sight’ criterion.We assume that nodes transmit according to the IEEE802.11 wireless LAN standard (2 Mbps). The transmissionrange was srcinally set to 250 m but an analysis of the con-nectivity graph of the network shows that with this rangetoo often there is no connectivity along the street betweentwo junctions. Real-world tests with vehicles equippedwith IEEE 802.11b cards also have shown that transmissionranges in the order of 500 to 800 meters are feasible withexternal antennas. We thus have set the transmission rangein our simulations to 500 m.We selected several pairs of nodes randomly; the reactivelocation service is used to determine the current positionof the communication partner. Then, each pair of nodesexchanges 20 packets over 5 seconds. We measured theachieved packet delivery rate (Fig. 7) versus the distancebetween the two communication partners (at the beginningof the communication) as well as the associated bandwidthconsumption (Fig. 8), latency for the first packet (Fig. 9) and number of hops (Fig. 10). Each point in the above men-tioned graphs is based on at least 10000 packets exchanged.The study on achievable packet delivery rate (Fig. 7) showsgood results for the position-based approach compared toDSR that shows some performance problems. In compari-son to AODV there is still some advantage for the position-based approach. A detailed analysis of the causes for notdelivering packets indicates that the position-based routingapproach fails when the connectivity on a street selected bythe path-finding algorithm is broken. This is also confirmedby Fig. 11 that shows the effect of reducing the transmissionrange from 500 m to 250 m. Thus, with improved and moreadaptive path selection procedures one can expect to im-prove the obtained results for the position-based approach.   p  a  c   k  e   t   d  e   l   i  v  e  r  y  r  a   t  e distance [m]Avg. Delivery RateGSR 500AODV 500DSR 500 Figure 7:  Packet delivery ratio versus distance of communicationpartners. 32641282565121024204840968192163845001000150020002500300035004000    b  a  n   d  w   i   d   t   h   [   k   b  p  s   ] distance [m]Avg. Total BandwidthAODV 500GSR 500DSR 500 Figure 8:  Average Total Bandwidth consumption per second. The main problem of DSR appears to be the network loadit generates with its ‘signaling traffic’ (Fig. 8). A study onthe performance of DSR that makes use of an ‘ideal’ MACscheme with (almost) unlimited bandwidth available showssignificantly better results for DSR. The achieved packet de-livery rate grows significantly, e.g., for communication part-ners with a distance up to 4 km from about 20 % up to therange of 60 % to 70 % (Fig. 12). But still DSR creates largepackets because of the source route inscribed in the headers,especially during route discovery phase, which leads to asignificant bandwidth overload. The second cause of failurefor DSR is mobility causing frequent route breaks. But thisis less dramatic than for highway scenarios since mobilityrate of city scenarios is much lower than of highway sce-narios. On the positive side DSR has less problems when agiven street does not provide connectivity, since it can verywell find other ‘non-direct’ routes.In contrast to the significant bandwidth consumption of DSR, simulations of AODV show delivery rates similar toGSR. By extending the communication distances band-width consumption of AODV is increasing up to the regionsof GSR because AODV uses an  expanding ring search -technique for route discovery. With the position-based ap-    t   i  m  e   [  s  e  c   ] distance [m]Avg. Latency of First Delivered PacketAODV 500GSR 500DSR 500 Figure 9:  Latency of first packet per ‘connection’. 1248165001000150020002500300035004000    #    h  o  p  s distance [m]Avg. Number of HopsGSR 500AODV 500DSR 500 Figure 10:  Average number of hops depending on distance. proach, the packets flooded during the reactive location re-quest period are of constant size.The observed latency Fig. 9 for the first packet of a ‘connec-tion’ is similar for DSR and GSR approaches with a smalladvantage for DSR. This was to be expected since the routeestablishmentinDSRandthelocationdiscoveryinposition-based routing are very similar. The usage of expanding ringsearch technique of AODV is responsible for the higher la-tency since it is a trade-off between bandwidth consumptionand latency.In contrast to DSR where a node drops a packet when routebreaks occur GSR uses some recovery strategies (fall back on greedy mode) to by-pass this particular node. As can beseen in Fig. 10 this strategy implies a slightly longer route tothe destination node. AODV using routing tables instead of source routes shows similar results to GSR. One can assumethat DSR is much more aggressive in routing to a destina-tion, i.e., uses the node with the largest progress which alsocould go out of radio range shortly. This would lead to moreroute breaks involving more packet drops which we haveseen in our simulations.
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks