DV-CAST: A distributed vehicular broadcast protocol for vehicular ad hoc networks

IEEE Wireless Communications • April 2010 471536-1284/10/$25.00 © 2010 IEEE

1

1

1

0

Packet arri

Hfr

IDLE

MDC=?

Rebroadcast

DFig=?

t on

AC C E P T E D F R O M OP E N CALL

OZAN K. TONGUZ AND NAWAPORN WISITPONGPHAN, CARNEGIE MELLON UNIVERSITYFAN BAI, GENERAL MOTORS CORPORATION

DV-CAST: A DISTRIBUTED VEHICULAR BROADCASTPROTOCOL FOR VEHICULAR AD HOC NETWORKS

INTRODUCTIONApplications developed for vehicular ad hoc net-works (VANETs) have very specific and cleargoals such as providing intelligent and safe trans-port systems. Emergency warning for public safe-ty is one application that is highly time-criticaland requires an intelligent broadcast mechanismto distribute warning messages. In order todesign a broadcast protocol for VANETs, onemust consider two major problems:• The broadcast storm problem, which occurs

when multiple nodes attempt to transmit atthe same time, thereby causing several packetcollisions and extra delay at the mediumaccess control (MAC) layer

• The disconnected network problem, whichoccurs when the number of nodes in the areato help disseminate the broadcast message isnot sufficient.Although both problems, especially the

broadcast storm problem, are well-known in themobile ad hoc network (MANET) research com-munity, so far each problem has been treatedseparately: most of the proposed algorithmswere developed to either cope with the broad-cast storm problem or handle the disconnectednetwork problem. A good routing protocol tar-

geting safety in VANETs, however, must be ableto deal with these two extreme cases in a seam-less manner. Hence, the goal of this work is todesign a distributed broadcast protocol, that canboth mitigate the broadcast storm and maintainnetwork connectivity in disconnected networks.

In this article we present a detailed imple-mentation of the Distributed Vehicular Broad-CAST (DV-CAST) protocol. Unlike otherexisting protocols, which solve either the broad-cast storm or disconnected network problem,DV-CAST can handle both problems simultane-ously while incurring only a small amount ofadditional overhead. The proposed protocol uti-lizes local topology information (i.e., a list ofone-hop neighbors) as the main criterion todetermine how to handle the rebroadcast of themessage.

The remainder of this article is organized asfollows. The next two sections present the relat-ed work and outline different regimes of interestin VANETs that the designed broadcast proto-col should be able to handle. The designoverview of DV-CAST is then presented, whilethe detailed implementation of the protocol isdescribed in the following sections. We then pro-vide the details of the simulation environmentand the performance evaluation of the DV-CAST protocol. In the following section certaindesign issues are highlighted along with a discus-sion. Finally, we summarize our findings in thefinal section.

RELATED WORK

There are a number of routing protocols specifi-cally designed to cope with routing in sparselyconnected MANETs. Data mules are proposedto function as mobile messengers that collectdata from sensors and deliver to a virtual back-bone in sensor networks [1]. Epidemic routingrelies on mobile nodes to exchange the data theypossess whenever they encounter new neighbors[2]. Role-based multicast [3] is proposed toachieve maximum reachability in a sparsely con-nected or fragmented network by using the store-carry-forward mechanism. Single-copy [4] andmulti-copy Spray and Wait [5] are shown to beefficient alternatives for message delivery. How-ever, most of these studies focus on using ran-

ABSTRACTThe potential of infrastructureless vehicular

ad hoc networks for providing safety and non-safety applications is quite significant. The topol-ogy of VANETs in urban, suburban, and ruralareas can exhibit fully connected, fully discon-nected, or sparsely connected behavior, depend-ing on the time of day or the market penetrationrate of wireless communication devices. In thisarticle we focus on highway scenarios, and pre-sent the design and implementation of a newdistributed vehicular multihop broadcast proto-col, that can operate in all traffic regimes, includ-ing extreme scenarios such as dense and sparsetraffic regimes. DV-CAST is a distributed broad-cast protocol that relies only on local topologyinformation for handling broadcast messages inVANETs. It is shown that the performance ofthe proposed DV-CAST protocol in terms ofreliability, efficiency, and scalability is excellent.

The authors focus onhighway scenariosand present thedesign and implementation of anew distributedvehicular multihopbroadcast protocol,which can operate in all traffic regimes,including extremescenarios.

TONGUZ LAYOUT 4/8/10 3:44 PM Page 47

IEEE Wireless Communications • April 201048

dom way point (RWP) model where node mobil-ity has fewer real-world restrictions and may notbe appropriate for VANET studies, as typicalroad topology is much more constrained and hasa very well defined structure.

There are a few studies that address similarrouting issues in sparsely connected VANETs.For example, [6] focuses on exploring the feasi-bility of the store-carry-forward concept on abidirectional highway via extensive simulations.Building on this pioneering work, we have previ-ously developed a comprehensive analyticalapproach to characterize key routing parametersin intermittently connected or disconnectedVANETs by using empirical, analytical, and sim-ulation-based studies [7]. While our work in [7]only focuses on highway networks, some recentstudies have looked into a sparsely connectedVANET using a Manhattan Grid model [8]. Theproposed techniques to disseminate informationin such a scenario include disseminating thepacket in different directions when passing bythe intersections [9]. These approaches, howev-er, either rely on fixed infrastructures to providenetwork connectivity [10] or use GPS and mapinformation to determine to whom to forwardthe packet [11]. These 2D Manhattan Grid stud-ies are complementary to the problem of discon-nected VANETs in a 1D highway scenario.

To the best of our knowledge, however, thereis no prior study that can handle both the dis-connected network and broadcast storm prob-lems in a seamless manner via a distributedrouting protocol for highway VANET scenarios.Our work fills this gap by designing a fully dis-tributed new VANET broadcast protocol knownas DV-CAST. Unlike existing studies, the pro-posed DV-CAST protocol can suppress thebroadcast storm in a dense VANET environ-ment in addition to routing in a sparsely con-nected VANET. The algorithm relies only onGPS information of the one-hop neighbors anddoes not require any centralized node or maps.

DIFFERENT REGIMES FORBROADCASTING IN VANET

Our previous research has identified two extremeregimes of operation in VANETs: dense trafficand sparse traffic. In order to design a goodbroadcast routing protocol that is robust enoughto operate in any type of vehicular traffic condi-tions, it is important to understand the charac-teristics of these two regimes. In the following,we give a brief overview of these regimes basedon our previous work [7, 12].

DENSE TRAFFIC REGIMEThis scenario occurs when traffic density is abovea certain value such that the considered networkis fully connected. Because of the shared wirelessmedium, blindly broadcasting the packets maylead to frequent contention and collisions. Thisproblem is sometimes referred to as the broad-cast storm problem [13]. While multiple solutionsexist to alleviate the broadcast storm problem ina typical MANET environment [13–16], only afew solutions exist for resolving this issue in theVANET context [9, 10, 12].

SPARSE TRAFFIC REGIME

The other extreme scenario, which is very trou-blesome for conventional routing protocols, isthe case where there are very few vehicles on theroad. For instance, the traffic density might beso low at certain times of the day (e.g., late nightor early morning) that multihop relaying from asource (the car trying to broadcast) to cars com-ing from behind might not be plausible becausethe target node might be out of the source’stransmission range. To make the situation worse,there might be no cars within the transmissionrange of the source in the opposite lane either.Under such circumstances, routing and broad-casting becomes a challenging task.

While several routing techniques address thesparsely connected nature of mobile wirelessnetwork, (e.g., epidemic routing [2], single-copy[4], multi-copy Spray and Wait [5]), there areonly a few studies that considered a VANETtopology [9–11].

For both sparse and dense traffic scenarios,all vehicles operating in these two extremeregimes observe the same local topology, whichalso reflects the real global topology. However, itis possible that both of these two traffic condi-tions may coexist in the same network; for exam-ple, traffic is normally congested at a mergingsection on the highway, but flows smoothlybeyond the merging point. Hence, it is possiblethat in such cases, not every vehicle sees thesame local topology; some may have very fewneighbors while some have many neighbors. Inthis case some vehicles will have to apply thebroadcast suppression algorithm while otherswill have to store-carry-forward the message inorder to preserve the network connectivity.

In the following section, we use these funda-mental traffic scenarios as our building blocks indesigning a new VANET broadcast protocol(DV-CAST).

DV-CAST DESIGN OVERVIEW

In this section we present an overview of theDV-CAST protocol. The reported protocol is anew general-purpose vehicular broadcast frame-work that has unique features:• It is robust against different types of vehicular

traffic conditions.• It depends only on the local one-hop neighbor

information observed by each node (car) viathe use of periodic hello messages.Figure 1 illustrates, at a high level, the main

concept behind the DV-CAST protocol, whichconsists of three major components: neighbordetection, broadcast suppression, and store-carry-forward mechanisms. The neighbor detectionmechanism estimates the local topology by moni-toring periodic hello updates received from one-hop neighbors. The local topology is animportant piece of information as it is used toassist DV-CAST in determining how the packetshould be handled. More specifically, each vehi-cle has to continuously monitor its local topologyin order to determine the relevance of the broad-cast message (i.e., whether it is an intendedrecipient of the message or not) and whetherthere is any neighbor in the broadcast direction

Our research hasidentified twoextreme regimes ofoperation in VANET:dense traffic regime andsparse traffic regime.To design a goodbroadcast routingprotocol that isrobust enough tooperate in any typeof vehicular trafficconditions, it isimportant to understand the characteristics ofthese two regimes.


IEEE Wireless Communications • April 2010 49

or in the opposite direction. DV-CAST takesone of the two major courses of action accordingto the status of the vehicle. That is, a vehicle in awell connected neighborhood should immediate-ly apply one of the broadcast suppression algo-rithms previously described in [12] when itreceives the broadcast message, while it shouldresort to a store-carry-forward mechanism in asparsely connected neighborhood.

The motivation for using the local topologyinformation in our framework is to minimize theadditional network overhead and keep the com-plexity of the protocol to a minimum. In particu-lar, other safety applications such as blind spotdetection also rely on these beaconing messages;therefore, the local connectivity is already agiven piece of information, which the routingprotocol can utilize. We believe that local topol-ogy information is sufficient for proper handlingof the broadcast packet.

While the DV-CAST protocol presented inthis article mainly targets safety applications, ithas the potential to be useful for other non-safe-ty applications, such as traffic information syst-gems [18] and entertainment applications [19],as well. Further research is needed to explorethis potential.

In the following section we present the imple-mentation of DV-CAST in detail.

KEY ROUTING COMPONENTS

ASSUMPTIONS

As illustrated in Fig. 1, a key component of DV-CAST is the neighbor detection mechanism,which provides the protocol with local topologyinformation. To simplify the problem, we focuson a highway topology with traffic traveling intwo opposite directions. Let us consider a typicalscenario where a source vehicle or a roadsideunit (RSU) broadcasts a warning message toapproaching vehicles. In general, the messagewould be beneficial to vehicles following thesource vehicle or vehicles moving toward theRSU, while the message will most likely be irrel-evant to vehicles moving in the opposite direc-tion. Thus, the goal of DV-CAST is to distributethis broadcast message to a certain group ofvehicles who will benefit from that warning.

For this work, we assume that the broadcastapplication can specify the Region of Interest(ROI) or the broadcast region where the intendedrecipients of the message are located. This ROIinformation will be tagged along with the routingmessage and will also be used along with the one-hop neighbor information in order to determinehow the message should be handled. In particular,each vehicle should be able to determine the threepieces of information that are the main inputparameters to the DV-CAST protocol:• Destination flag (DFlg), which determines

whether a car is the intended recipient of themessage

• Message direction connectivity (MDC), whichdetermines whether a car is the last vehicle inthe group/cluster (or whether there is anynext-hop neighbor moving in the same direc-tion who will be responsible for reforwardingthe message)

• Opposite direction connectivity (ODC), whichdetermines whether a car is connected to atleast one vehicle in the opposite directionAlthough additional information such as a

neighbor’s local topology might also help toimprove the performance of the protocol, obtain-ing such information also implies an increase innetwork overhead. Hence, we claim that thesethree flags provide the necessary knowledgeabout the local topology information, which issufficient for DV-CAST to determine how tohandle the broadcast packets and achieve accept-able performance.

LOCAL TOPOLOGY UPDATES VIA PERIODIC HELLOIn order to determine the value for the flagsdescribed earlier, each vehicle must have themost up-to-date local topology information (i.e.,who is in its one-hop neighborhood and whereeach neighbor is located relative to its currentposition). To achieve this, each vehicle isrequired to periodically broadcast its GPS infor-mation <latitude, longitude, head-ing>, which can easily be done by adding anextra field in the hello packet and data packetheaders. In the current protocol design, the hellobroadcast frequency is set to 1 Hz, and the hellopacket content is kept at a minimum. Note thatthe periodic hello beaconing is also a require-ment in many other VANET safety applications.Hence, DV-CAST can also work with existingVANET applications without any changerequired.

NEIGHBOR DETECTION MECHANISMPerhaps the most essential module in DV-CASTis the neighbor detection mechanism, as therouting action taken by the protocol dependsmainly on the local connectivity information.Upon receiving the hello or data packet fromthe neighbor, each vehicle has to compare itsGPS information against the neighbor’s GPSinformation and determine whether the neigh-bor is moving in the same direction or in theopposite direction. In addition, neighbors mov-ing in the same direction must also be furthercategorized into leading vehicle or following

Figure 1. High-level concept of DV-CAST protocol.

IDLE

Connected Disconnected

Packet arrival

Broadcastsuppression

Store-carry-forward

Neighbor detection



vehicle. For this purpose, DV-CAST maintainsthree separate neighbor tables, NB_FRONT ,NB_BACK, and NB_OPPOSITE, which containsthe list of neighbors who are leading, following,or moving in the opposite direction, respectively.Each table is a priority queue, in which up to aMAXNB number of neighbors are orderedaccording to the time of the neighbors’ mostrecent GPS updates.

These neighbor tables along with the infor-mation from the broadcast packet header can beused to determine the three binary flagsdescribed earlier. Hence, MAXNB does not needto be a large value since DV-CAST makes itsdecision based on these binary flags only. We setMAXNB to 5 in our implementation.

BROADCAST SUPPRESSIONA mobile node performs a broadcast suppressionwhen it is in a dense traffic regime with at leastone neighbor in the broadcast direction. In [12]we explore how serious the broadcast storm is inVANETs using a case study for a four-lane high-way scenario and propose three lightweightbroadcast techniques (i.e., weighted p-persis-tence, slotted 1-persistence, and slotted p-persis-tence), which can provide 100 percentreachability in a well connected network and upto approximately 70 percent reduction in thebroadcast redundancy and packet loss ratio in awell connected vehicular network. The proposedschemes are distributed and rely on GPS infor-mation, but do not require any other prior knowl-edge about network topology. In this article wepropose to use the weighted p-persistence schemeintroduced in [12] in the final design of the pro-tocol to handle the broadcast storm problem.

STORE-CARRY-FORWARDIn a sparse network we propose to cope withsuch an extreme situation via the so-called store-

carry-forward mechanism [3]. Our previousresults show that depending on the sparsity ofvehicles or the market penetration rate of carsusing dedicated short range communication(DSRC) technology [17], the network delayincurred in delivering messages between discon-nected vehicles via the store-carry-forwardmechanism can vary from a few seconds to sev-eral minutes. This suggests that a new ad hocrouting protocol will be needed as conventionalad hoc routing protocols such as Dynamic SourceRouting (DSR) or Ad Hoc On-Demand Dis-tance Vector Routing (AODV) will not workwith such long re-healing times. This articleaddresses the detailed implementation of thedistributed store-carry-forward mechanism, while[3] introduces only the concept of the mecha-nism.

In the following section we describe in detailthe implementation of DV-CAST, which consistsof these key routing components.

ROUTING RULES

Figure 2 illustrates the detailed implementationof DV-CAST. In order to handle the broadcastmessage properly, we propose that each vehiclefollow two basic routing rules:• If DFlg is set to 1, the vehicle should ignore

any duplicate broadcast or follow the diagramin Fig. 2 if the message is received for the firsttime.

• If DFlg is set to 0, the vehicle is a relay nodeand should follow the routing diagram shownin Fig. 2. This is because in a very sparse net-work environment, a certain relay vehicle mayhave to help store-carry-forward the samemessage more than once.Depending on the level of local connectivity

the vehicle experiences, we propose three differ-ent courses of action the vehicle should follow inorder to properly handle the broadcast packet.

CASE I: WELL CONNECTED NEIGHBORHOODA vehicle is said to be in a well connected neigh-borhood if it has at least one neighbor in themessage forwarding direction (MDC = 1). Asillustrated in Fig. 2, upon receiving the broadcastmessage, a vehicle in this regime should applyone of the broadcast suppression techniques pre-viously presented in [12]. For example, if theslotted 1-persistence scheme is employed, eachvehicle in this neighborhood will use the relativedistance information calculated by using thesource’s information available in the packetheader to determine the necessary backoff time,which is typically less than 100 ms. If the vehicledoes not hear any rebroadcast of the same pack-et during this backoff period, it should rebroad-cast the packet when this backoff timer expires.However, if it overhears the rebroadcast from itsneighbor, it should cancel the pending rebroad-cast and go back to the IDLE state. Observethat information regarding neighboring vehiclesin the opposite direction is not relevant in thiscase. In particular, vehicles that are in a wellconnected neighborhood assume that they areoperating in a dense traffic regime, regardless ofthe actual global traffic condition. That is, avehicle whose MDC flag is 1 will behave as if it

Figure 2. Decision tree for DV-CAST protocol (ODN; opposite direction neigh-bor).

1

1

1 0

0

0

Packet arrival

Pkt timer expires

Hello Pkt arrives from ODN/ ODC=1 or MDC=1

Hello Pkt arrives from new ODN

Pkt arrival <HOP=N+2> or Pkt Timer Expires

IDLE

MDC=?

Rebroadcast

DFig=?

Rebroadcast

WAIT I

WAIT II

ODC=? Broadcast suppression



is in a dense traffic regime, and it will apply thebroadcast suppression algorithm regardless ofthe global traffic condition, which may be denseor sparse. It is expected that all vehicles will bein a well connected neighborhood during rushhours, while only a fraction of vehicles will be ina well connected neighborhood under normal orlight traffic conditions.

According to Fig. 3a, each vehicle in Group1, except for A which is the last vehicle in thegroup/cluster (MDC = 0), upon receiving thebroadcast message from S, will have the follow-ing flags <MDC = 1, ODC = 1/0, DFlg =1> (ODC can either be 1 or 0). Vehicles ingroup 3 except for B will also have similar flags,<MDC = 1, ODC = 1/0, DFlg = 0> .Each vehicle from both groups except for A andB will apply the broadcast suppression algorithmpresented in [12].

CASE II: SPARSELY CONNECTED NEIGHBORHOODA vehicle is operating in a sparse traffic regime ifit is the last node in a cluster. Furthermore, avehicle in this regime is said to be in a sparselyconnected neighborhood if there is at least oneneighbor in the opposite direction as in the caseof vehicles A and B in Fig. 3b and 3c. The param-eters for these vehicles should be set to <MDC =0, ODC = 1, DFlg = 0/1>. Upon receiv-ing the broadcast message, these vehicles canimmediately rebroadcast. However, if the vehicleis moving in the same direction as the source, asin the case of vehicle A whose DFlg is set to 1, itcan go back to an IDLE state after the rebroad-cast. On the other hand, a vehicle whose DFlg is0, as in the case of vehicle B, has to make a tran-sition to the WAIT II state where it waits untilthe packet timer expires or it can rebroadcast thepacket back in the original message forwardingdirection. Similar to the previous case, vehicles ina sparsely connected neighborhood assume thatthey are operating in a sparse traffic regimeregardless of the actual global traffic condition.

In order to get a better understanding of howto handle the broadcast packet in this case,below we use the two scenarios shown in Fig. 3band 3c as an example.

Scenario 2.1 — A and B are neighbors, and may

receive the broadcast from S at the same or dif-ferent times. Since A is aware of the presence ofB, it will simply rebroadcast and make a transi-tion to the IDLE state. On the other hand, thestatus of B will be <MDC = 0, ODC = 1,DFlg = 0> , so it will have to immediatelyrebroadcast since it cannot distinguish whether itis in scenario 2.1 or 2.2. After the rebroadcast, ittransits to the WAIT-II state and holds on to themessage until it detects a new neighbor vehiclein the opposite direction or the packet timerexpires. The packet expiration time is a veryimportant parameter for a relay node whoseDFlg is set to 0, as it is the maximum time arelay node has to hold on to the message. Thevalue used for this parameter depends on manyfactors, such as the maximum time the relaynode is willing to store the packet, the messagelifetime, or the expected time the vehicle remainsin the region of interest. Hence, the packet expi-ration time is typically on the order of severalseconds to a few minutes.

After the rebroadcast, if B comes into contactwith vehicles in Group 2, B will rebroadcast andgo into the WAIT II state again. This time, how-ever, B will have to wait for an implicit acknowl-edgment that this is the rebroadcast of themessage with greater hop count and go into theIDLE state.1 However, if the gap between group1 and group 2 is very large, B will likely be outof the broadcast region (ROI) and drop thepacket before it reaches group 2.

Scenario 2.2 — Vehicles A and B would behave inthe same way as in scenario 2.1. That is, they willrebroadcast and go into the WAIT II state. Sincegroup 3 is connected to both group 1 & 2, bothA and B will hear a rebroadcast with greater hopcount and will make a transition into the IDLEstate.

CASE III: TOTALLY DISCONNECTED NEIGHBORHOODA vehicle operating in a sparse traffic regime issaid to be in a totally disconnected neighbor-hood if it has no neighbor in the message for-warding direction and is not connected toanybody in the opposite direction (i.e., MDC =ODC = 0). In this case the disconnected vehicle,vehicle A in Fig. 3d, should hold on to the broad-

Figure 3. The three different scenarios: a) Scenario 1: A's flag is <MDC = 1, ODC = 1, DFlg = 1>; b) Scenario 2.1: A's flag is <MDC= 0, ODC = 1, DFlg = 1>; c) Scenario 2.2: A's flag is <MDC = 0, ODC = 1, DFlg = 1>; d) Scenario 3: A's flag is <MDC = 0,ODC = 0, DFlg = 1>.

Source

Source

Group 1

Group 1

Group 2

Group 2

Group 1

Group 1

Group 2

Group 2

Group 3

Group 3

Source

Source

A

A

B

B

Group 3

Group 3

A

A

B

(a) (b)

(c) (d)

B

1 Note that although theprotocol can force B to gointo the IDLE stateimmediately after it hasrebroadcast to vehicles ingroup 2 by keeping extrarouting parameters suchas the number of rebroad-casts, we propose to useonly three routing param-eters (MDC, ODC, andDFlg) so the number ofstates are optimized forthree parameters.



cast message until it can delegate the broadcastresponsibility to a vehicle in the opposite direc-tion or to a more suitable vehicle moving in thesame direction, but no longer than the packetexpiration time.

According to Fig. 3d, A is disconnected fromgroup 3 and group 2. The flags should be set to<MDC = 0, ODC = 0, DFlg = 1>. Forthis scenario, A will have to go to the WAIT Istate and wait for the hello packet from vehiclesin group 3 or a vehicle in group 2 who may havecaught up with group 1 while A is in the WAIT Istate. Once B moves into A’s range, the ODCflag of A will be changed to 1, and A will imme-diately rebroadcast. Vehicle B, according to Fig.3d, may or may not have heard the broadcastmessage when it receives the rebroadcast from A.However, since DFlg of B is 0, it will always helpto relay the message. Therefore, when B receivesthe broadcast message from A it will have thefollowing flags; <MDC = 0, ODC = 1, DFlg= 0>. This is the same setting as in scenario 2.1.

Note that it is likely that vehicles in a densetraffic regime will only be in a well connectedneighborhood, and every vehicle will have to usethe broadcast suppression mechanism. On theother hand, most vehicles in a sparse trafficregime will be in either a sparsely connected ortotally disconnected neighborhoods, so they willhave to resort to the store-carry-forward mecha-nism. Table 1 presents the summary of actionstaken by DV-CAST.

NETWORK PERFORMANCE AND ANALYSIS

In this section we present the network perfor-mance of the novel DV-CAST protocol undervarious traffic conditions (i.e., heavy vehicle traf-fic condition, representing a well connected net-work, and a light vehicle traffic condition, whichcorresponds to the disconnected network case)previously discussed in [7]. The protocol isimplemented on an ns-2 (version 2.29.1) plat-form and tested against a realistic highwaymobility pattern with a Ricean fading propaga-tion model with K factor equal to 1 and the802.11a MAC protocol.

TEST SCENARIOSDue to the limited capability of the NS-2 simula-tion platform, which cannot simulate an opensystem, we have resorted to the use of a circular

highway, which allows one to mimic an open sys-tem, where vehicles can leave or enter the con-sidered road section at any point in time using aclosed circular highway system with a fixed num-ber of vehicles. Hence, the network topologyconsidered in this study is a four-lane circularhighway with a radius R, where two lanes of traf-fic are moving clockwise and two are movingcounter-clockwise. To mimic an open system, wefocus only on a certain section of the highway:the ROI. More specifically, vehicles leaving theROI drop any network activities, while vehiclesre-entering the ROI are treated as new vehicles.At the beginning of the simulation, initial place-ment of vehicles follows an exponential distribu-tion, which is derived from the real trafficpattern observed on I-80 [7]. Each vehicle firstmoves along the highway at a random speed uni-formly chosen from [Vmin,Vmax], where the mini-mum vehicle speed (Vmin) and maximum speed(Vmax) considered in the simulations are 24 m/sand 30 m/s, respectively. Afterward, each vehiclegradually updates its speed at every second usingthe following equation:

Vt = k × Vt–1, (1)

where the factor k ∈ [0.8 – 1.2].We consider five traffic densities with 432,

864, 1188, 1728, and 2995 vehicles per hour (vph),which corresponds to the average road-level inter-vehicle spacing (E[S]) of 210 m, 125 m, 90 m, 63m, and 37 m, respectively; or to the probability ofbeing in a sparsely connected neighborhood (Pd)of 36 percent, 13 percent, 6 percent, 1 percent,and 0 percent, respectively [7]. These networkdensities cover a range from low (normal or nighttime) to high vehicular traffic density (rush hour).The ROI is set to be approximately 5 km, mea-sured from the accident scene and extending 5km in length along the highway, and is located atthe first quadrant of the highway, as shown in Fig.4. Assume that an accident occurs at the upperpart of the circular highway, so the fixed RSU orthe crashed vehicle is put in place to periodicallybroadcast the traffic alert message to theapproaching vehicles. As previously discussed in[7], traffic with a certain percentage of marketpenetration can be characterized by the sametraffic model with different densities. Therefore,we assume that all vehicles are equipped withwireless communication devices.

Table 1. Summary of DV-CAST operations.

MDC ODC DFlg Scenario Actions taken by DV-CAST Protocol

1 0/1 1 Well connected Broadcast suppression

1 0/1 0 Well connected Help relay the packet by doing broadcast suppression

0 1 1 Sparsely connected Rebroadcast and assume that the ODN will help relay or rebroadcast

0 1 0 Sparsely connected Rebroadcast, and help carry and forward the packet to the first new neighbor inthe opposite direction or in the message direction encountered

0 0 0/1 Totally disconnected Wait and forward the packet to the first neighbor in the opposite direction or inthe message direction encountered



We collected statistics of 1000 broadcastpackets from each scenario and compared withthe benchmark performance, which is the con-trolled broadcast protocol without the store-carry-forward mechanism [12]. The suppressiontechnique used in the current implementation ofDV-CAST is slotted 1-persistence with threetime slots. Note that the controlled broadcastresults obtained in this article should be similarto results obtained from other broadcast sup-pression mechanisms [13–16] as none of themhas a feature to solve the disconnected networkproblem. On the other hand, most protocolsdeveloped for delay-tolerant networks (DTNs)rely on infrastructure or maps and are developedmainly for urban environments; hence, we can-not compare our results to their results as theunderlying assumptions about network topologyand vehicle knowledge are different.

PERFORMANCE METRICSDV-CAST is designed to achieve robustnessagainst extreme traffic conditions; hence, thethree main performance metrics of interest arereliability, efficiency, and scalability. To testwhether the protocol is reliable, efficient, andscalable, we use the following quantitative mea-surements, respectively:• Broadcast success rate: Percentage of time the

protocol can successfully deliver the packet tothe nodes in the target region (reliability)

• Network reachability: Maximum packet pene-tration distance measured as a function oftime (efficiency)

• Network overhead: Number of duplicate pack-ets received at the network layer (scalability)

DV-CAST PERFORMANCE RESULTS

BROADCAST SUCCESS RATE

For the scenario considered with approximately 5km ROI, the packet is said to be successfullydelivered if the maximum packet delivery dis-tance reached is 5 km or the packet reaches allthe vehicles in the ROI. Obviously, as the net-work density increases, the success rate alsoincreases. In particular, as the network densityincreases from 432 to 1728 vph, the observed suc-cess rates corresponding to each network densityare 53.3 percent, 78.8 percent, 89.5 percent, and95.5 percent, as shown in Fig. 5a. As the networkdensity increases to 2995 vph, which also corre-sponds to the well connected case, the successrate is 100 percent. In contrast, without the store-carry-forward feature introduced by DV-CAST,the success rate will be less than 20 percent in asparsely connected case. While we expect DV-CAST to achieve a 100 percent success rate, weobserve that not all the broadcast packets reachthe end of the ROI zone at low network densi-ties. This is due to the fact that either the discon-nected relay nodes move out of the ROI beforeencountering a new relay node, or there is simplynobody within the transmission range of the RSUat the time of the broadcast.

NETWORK REACHABILITYFigure 5b shows the average packet penetrationdistance as a function of time (i.e., how fast the

DV-CAST can deliver a packet). The faster thepacket delivery, the more efficient the protocol.In particular, the protocol is said to be efficientif it can deliver the message to the target desti-nation within an acceptable time, which is speci-fied by the application. Ideally, it is expectedthat as time increases, the packet penetrationdistance increases up to the end of the ROI.However, if there is nobody within the transmis-sion range of the RSU at the time of the broad-cast, or the disconnected node moves out of theROI before encountering a relay node, the pen-etration distance observed in such scenarios evenlong after the initial broadcast time will notreach the end of ROI (5000 m). Despite this dis-crepancy, DV-CAST offers a much better net-work reachability than controlled broadcast orblind flooding.

NETWORK OVERHEADFigure 5c shows the average network overheadfor a single broadcast as observed by each node.The network overhead seems to scale very well,especially in heavy traffic conditions where abroadcast storm is likely to occur. In particular,the amount of overhead is about three times lessthan that of the blind flooding (1-persistence)case. Observe that as the traffic density increasesbeyond 2000 vph, DV-CAST behaves similar tothe controlled broadcast protocol. For the inter-mediate cases, each node observes only a fewadditional overhead packets as DV-CAST relieson these extra overhead packets to maintain net-work connectivity. Despite the small amount ofextra overhead introduced by DV-CAST in orderto maintain network connectivity and achievebetter success rate and reachability, the DV-

Figure 4. Circular highway scenario used for simulations.

R

ROI Hazard



CAST protocol appears to be very scalable,especially in a dense traffic scenario.

DESIGN ISSUES AND DISCUSSION

DV-CAST has many design parameters thatneed to be tuned appropriately in order to opti-mize the performance. Due to limited space, webriefly discuss the impact of each parameter inthis section.

HELLO UPDATE FREQUENCYIntuitively, if each vehicle periodically updatesits location at a high frequency, the wirelesschannel may become congested; consequently,this leads to long MAC delay and high packetloss rate. For a typical VANET environment,where topology does not change much in a mil-lisecond or even a second, the majority of helloupdates received may be useless. On the otherhand, if the hello frequency is too small, thelocal topology information provided by theneighbor detection mechanism may not be accu-rate, subsequently causing the protocol to fail.For example, a mobile node may choose to dobroadcast suppression instead of store-carry-for-ward the message, which would then lead to lownetwork reachability.

We have simulated the scenarios with hellofrequencies of 0.2 Hz, 1 Hz, and 4 Hz. Surpris-ingly, regardless of the update frequency, DV-CAST behaves similarly in terms of these threedifferent measurements. This could be partlydue to the fact that topology as seen by eachvehicle does not change rapidly over time, espe-cially when considering vehicles moving in thesame direction. This is because the maximumrelative velocity of vehicles moving in the samedirection considered in our model is only 6 m/s.Therefore, the hello update does not have to beas frequent as the current setting of 1 Hz in theconsidered scenario since the local topologydoes not change much during the two consecu-tive hello updates.

GPS DRIFTThe accuracy of GPS is also another importantfactor that may cause the neighbor detectionmechanism to fail. This problem is more severethan using a low hello update frequency becausea mobile node can completely fail to estimatethe local topology if the neighbor vehicles reportincorrect GPS information. GPS drift is aninevitable problem for several reasons:• Different GPS receivers, especially from dif-

ferent vendors, may have different perfor-mance.

• Bad GPS reception due to obstruction is acommon problem, which could also lead toGPS drift

• Performance of the GPS antenna could deteri-orate over time.We have investigated GPS drift on ns-2 by

adding some random skewed factors to the GPSupdate function so that the reported GPS loca-tion is 0–25 m away from the correct position inany direction. The impact of GPS drift on thebroadcast success rate, network reachability, andnetwork overhead in a sparsely connected net-work with 1188 vph is shown in Fig. 6. Our

Figure 5. DV-CAST performance at various traffic densities: a) broadcast suc-cess rate; b) network reachability; c) average network overhead.

Distance [m]

(a)

10000

0.2

0

Broa

dcas

t su

cces

s ra

te

0.4

0.6

0.8

1

1.2

1.4

1.6

2000 3000 4000 5000

DV-CASTBroadcast

432 vph (Pd=36%)864 vph (Pd=13%)1188 vph (Pd=6%)1728 vph (Pd=1%)2995 vph (Pd=0%)

(b)

(c)

Traffic volume (vph)500

2

0

Ave

rage

ove

rhea

d (p

kt)

4

6

8

10

12

14

1000 1500 2000 2500 3000

DV-CASTBroadcast with suppressionBlind flooding

Time [s]50

1000

0

Ave

rage

max

imum

dis

tanc

e re

ache

d [m

]

2000

3000

4000

5000

6000

7000

8000

9000

100 150 200 250 300

DV-CASTBroadcast

432 vph (Pd=36%)864 vph (Pd=13%)1188 vph (Pd=6%)1728 vph (Pd=1%)2995 vph (Pd=0%)



results show that the performance in all threemetrics remains relatively unchanged in a sparsenetwork, but slightly deteriorates when the traf-fic volume exceeds 1000 vph. However, theresults are still much better than the blind flood-ing or controlled broadcast results.

CONCLUSION

In this article we present the performance interms of reliability, efficiency, and scalability ofthe DV-CAST protocol on highways under multi-ple traffic conditions. Since the protocol isdesigned to address how to deal with extremeconditions such as heavy traffic during rush hours,very light traffic during certain hours of the day(e.g., midnight to 4 a.m. in the morning), and lowmarket penetration rate of cars using DSRC tech-nology, the simulation results show that the DV-CAST performs well in every aspect consideredand is robust against various extreme traffic con-ditions. For future work, it would be interestingto see how much of the underlying design princi-ples of DV-CAST would also be applicable tourban areas. At a high level, it seems clear thatlarge cities might have a very different and muchricher topology (e.g., Manhattan Street type oftopologies) than highways. In this sense, onecould consider DV-CAST as an instance (or asubset) of designing a distributed vehicular broad-casting protocol that would work anywhere(urban, suburban, and rural areas). Our currentresearch efforts are focused on extending vehicu-lar broadcasting to urban areas.

REFERENCES[1] R. C. Shah et al., “Data MULEs: Modeling and Analysis

of a Three-tier Architecture for Sparse Sensor Net-works,” Elsevier Ad Hoc Net. J., vol. 1/2–3, Sept. 2003,pp. 215–333.

[2] A. Vahdat and D. Becker, “Epidemic Routing for Partial-ly Connected Ad Hoc Networks,” tech. rep. no. cS-200006, Duke University, Apr. 2000.

[3] L. Briesemeister and G. Hommel, “Role-Based Multicastin Highly Mobile but Sparsely Connected Ad Hoc Net-works,” Proc. ACM MobiHoc, Boston, MA, Aug. 2000,pp. 45–50

[4] T. Spyropoulos, K. Psounis, and C. S. Raghavendra,“Single-Copy Routing in Intermittently ConnectedMobile Networks,” 1st IEEE SECON ‘04, Oct. 2004, pp.235–44.

[5] T. Spyropoulos, K. Psounis, and C. S. Raghavendra,“Spray and Wait: An Efficient Routing Scheme for Inter-mittently Connected Mobile Networks,” Proc. 2005ACM SIGCOMM Wksp. Delay-Tolerant Net., Philadel-phia, PA, Aug. 2005, pp. 252–59.

[6] Z. D. Chen, H. T. Kung, and D. Vlah, “Ad Hoc RelayWireless Networks over Moving Vehicles on Highways,”Proc. ACM MobiHoc, Long Beach, CA, Oct. 2001, pp.247–50.

[7] N. Wisitpongphan et al., “Routing in Sparse VehicularAd Hoc Wireless Networks,” IEEE JSAC, vol. 25, no. 8,Oct. 2007, pp. 1538–56.

[8] O.K. Tonguz, W. Viriyasitavat, and F. Bai, “ModelingUrban Traffic: A Cellular Automata Approach,” IEEECommun. Mag., vol. 47, no. 5, May 2009.

[9] G. Korkmaz, E. Ekici, and F. Ozguner, “An Efficient FullyAd-Hoc multihop Broadcast Protocol for Inter-VehicularCommunication Systems,” Proc. IEEE ICC, Istanbul,Turkey, June 2006, pp. 423–28.

[10] G. Korkmaz et al., “Urban multihop Broadcast Protocolfor Inter-Vehicle Communication Systems,” Proc. ACMVANET, Philadelphia, PA, Oct. 2004.

[11] J. Zhao and G. Cao, “VADD: Vehicle-Assisted DataDelivery in Vehicular Ad Hoc Networks,” Proc. IEEEINFOCOM, Apr. 2006, pp. 1–12.

[12] N. Wisitpongphan et al., “Broadcast Storm MitigationTechniques in Vehicular Ad Hoc Networks,” IEEE Wire-

Figure 6. Impact of GPS drift on: a) broadcast success rate; b) network reacha-bility; c) network overhead.

Distance [m](a)

10000

0.1

0

Broa

dcas

t su

cces

s ra

te

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

2000 3000 4000 5000

GPS driftNormal

Time [s](b)

500

500

0

Ave

rage

max

imum

dis

tanc

e re

ache

d [m

]

1000

1500

2000

2500

3000

3500

4000

4500

100 150 200 300250

GPS driftNormal

Traffic volume [vph](c)

1000400

1

0

Ave

rage

ove

rhea

d [p

kt]

2

3

4

5

6

800600 1200 1400 1600 1800

GPS driftNormal


less Commun., vol. 14, no. 6, Dec. 2007, pp. 84–94.[13] S. Ni et al., “The Broadcast Storm Problem in a Mobile

Ad Hoc Network,” Proc. ACM MobiCom, Seattle, WA,1999, pp. 151–62.

[14] S. Ni, Y. Tseng, and E. Y. Shih, “Adaptive Approachesto Relieving Broadcast Storms in a Wireless MultihopMobile Ad Hoc Network,” Proc. IEEE 21st ICDSC, 2000,pp. 481–88.

[15] C. Hu, Y. Hong, and J. Hou, “On Mitigating the Broad-cast Storm Problem with Directional Antennas,” Proc.IEEE ICC, vol. 1, Seattle, WA, May 2003, pp. 104–10.

[16] A. Laouiti, A. Qayyum, and L. Viennot, “MultipointRelaying: An Efficient Technique for Flooding in MobileWireless Networks,” IEEE 35th Annual Hawaii Int’l.Conf. Sys. Sci., 2001, pp. 3866–75.

[17] ASTM Std E2213-03, “Standard Specification forTelecommunications and Information ExchangeBetween Roadside and Vehicle Systems — 5 GHz BandDedicated Short Range Communications (DSRC) Medi-um Access Control (MAC) and Physical Layer (PHY)Specifications”; http://www.standards.its.dot.gov/Docu-ments/advisories/dsrc_advisory.htm

[18] O. K. Tonguz, F. Bai, and C. U. Saraydar, “VehicularNetworks,” Guest Editorial, Elsevier Ad Hoc NetworksJ., Special Issue on Vehicular Networks, vol. 8, no. 5,July 2010, pp. 457–61.

[19] O. K. Tonguz and M. Boban, “Multiplayer Games overVehicular Ad Hoc Networks: A New Application,” Elsevi-er Ad Hoc Networks J., Special Issue on Vehicular Net-works, vol. 8, no. 5, July 2010, pp. 531–43.

BIOGRAPHIESOZAN K. TONGUZ ([email protected]) is a tenured fullprofessor in the Electrical and Computer EngineeringDepartment of Carnegie Mellon University (CMU), Pitts-burgh, PA. He currently leads substantial research efforts at

CMU in the broad areas of telecommunications and net-working. He has published about 300 papers in IEEE jour-nals and conference proceedings in the areas of wirelessnetworking, optical communications, and computer net-works. He is the author (with G. Ferrari) of the book AdHoc Wireless Networks: A Communication-Theoretic Per-spective (Wiley, 2006). His current research interestsinclude vehicular ad hoc networks, wireless ad hoc andsensor networks, self-organizing networks, bioinformatics,and security. He currently serves or has served as a consul-tant or expert for several companies, major law firms, andgovernment agencies in the United States, Europe, andAsia.

NAWAPORN WISITPONGPHAN is a lecturer in the Faculty ofInformation Technology and the Computer EducationDepartment at King Mongkut’s University of TechnologyNorth Bangkok (KMUTNB), Thailand. She received her B.S.,M.S., and Ph.D. degrees in electrical and computer engi-neering from CMU in 2000, 2002, and 2008, respectively.From 2003 to 2009 she was also a research associate inthe Electrical and Control Integration Laboratory, GeneralMotors Corporation. Her research interests include trafficmodeling, chaos in the Internet, and cross-layer networkprotocol design for wireless networks.

FAN BAI is a senior researcher in the Electrical and ControlIntegration Laboratory, General Motors Corporation, sinceSeptember 2005. Before joining General Motors, hereceived his B.S. degree in automation engineering fromTsinghua University, Beijing, China, in 1999, and hisM.S.E.E. and Ph.D. degrees in electrical engineering fromthe University of Southern California, Los Angeles, in 2005.His current research is focused on the discovery of funda-mental principles, and the analysis and design of proto-cols/systems for next-generation vehicular ad hoc networks.

56 IEEE Wireless Communications • April 2010




DV-CAST: A distributed vehicular broadcast protocol for vehicular ad hoc networks

Documents