# Industrial Internet of Things Based Efficient and Reliable Data Dissemination Solution for Vehicular Ad Hoc Networks

Authors: Shahid Latif; Saeed Mahfooz; Naveed Ahmad; Bilal Jan; Haleem Farman; Murad Khan; Kijun Han
Journal: Wireless Communications and Mobile Computing
 (2018)

---

## Abstract

Industrial Internet of Things (IIoT) is the other name of industrial Internet. It integrates a variety of existing industrial automation technologies with computing, machine learning, and communication technologies. Vehicular ad hoc network, an application of IIoT, is a self-organized network of vehicles which tends to provide improved road safety, diminished traffic congestion, and ultimate comfort to the travellers. In VANETs, vehicles exchange data with each other directly or through roadside units (RSUs). Data dissemination in VANETs experiences numerous challenging issues including broadcast storm, network partitions, intermittent connectivity between vehicles, and limited bandwidth. In literature, various data dissemination schemes are proposed. However, most of these schemes are designed for either urban or highway VANET scenarios and evaluated under sparse or dense traffic conditions. Moreover, these schemes do not effectively overcome the aforementioned issues simultaneously. In this paper, we present a new data dissemination protocol for VANETs, which disseminates the emergency messages in different scenarios under varying traffic conditions. During dense traffic conditions, DDP4V employs the segmentation of transmission region of a vehicle in order to select the most appropriate next forwarding vehicle (NFV). Accordingly, it divides the transmission region of a vehicle in three distinct segments and selects vehicle(s) inside the highest priority segment to forward the message to all neighbour vehicles, whereas it also uses implicit acknowledgements for guaranteed message delivery during sparse traffic Conditions. Simulation results show that DDP4V protocol outperforms the other existing related protocols in terms of coverage, network overhead, collision, and end-to-end delay.


---

## Body

## 1. Introduction

The Internet of Things (IoT) is a network of miscellaneous items such as physical devices, automobiles, and home appliances. embedded with recent electronics, sensing, networking, and communication technologies in order to connect and communicate. Industrial Internet of Things (IIoT), also known as industrial Internet, put forward the IoT technologies in manufacturing [1, 2]. IIoT integrates a large set of existing industrial automation technologies with recent electronics, computing, machine learning, and communication technologies. IIoT believes that smart machines are more competent than humans in collecting and communicating data. This data facilitates the industrial and business communities in business intelligence efforts. The vehicular ad hoc network, an application of IIoT, is a large network of vehicles communicating with each other and roadside units for sharing of information [3]. These are spontaneously created networks from interconnected vehicles for particular needs. VANETs aim to provide comfort to travellers and improve the road safety and traffic congestion. In VANETs, information is exchanged wirelessly between vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communication in both highway and urban scenarios. Day by day, the increasing number of vehicles on roads raises several serious traffic problems including traffic jams and vehicle pile-ups. According to World Health Organization (WHO), 1.25 million people die every year and 50 million injuries occur due to the road accidents [4]. Likewise, [5, 6] present records and statistics on the topic of accidents, fatalities, and injuries. Therefore, safety is one of the prime objectives of VANETs. These networks are also supposed to provide automated roadways, comfort, infotainment, environment protection [7, 8], and so forth. Presently, VANETs are emerging as an important research area and grabbing the attention of the researchers from both academia and industrial communities. VANETs are decentralized networks, where every vehicle node periodically broadcasts its information such as direction, position, and speed through beacon messages to inform its neighbour vehicles. Emergency situations like accidents or traffic jams make use of this information to alert other distant vehicles in the network. VANETs present a large set of applications categorized into two groups, that is, safety and nonsafety applications. Usually, safety applications need few small (data packet) messages with high latency and high-reliability ratios, while nonsafety applications such as traffic information, convenience, and entertainment need diverse messages with high data rate capabilities [9].Data dissemination in VANETs is a data distribution process, where every vehicle transmits the message (data packet) to its neighbour vehicles inside the network. Usually, data dissemination in VANETs is broadcast-oriented. Thus the transmitting vehicle does not require the address and route information of the receiving vehicles. This leads the VANETs to eliminate the need for several complex issues such as address design and resolution, route finding, and topology management. Data dissemination in VANETs experiences many challenging issues such as broadcast storm, network partitions, intermittently connected network, and limited bandwidth. In the presence of all these issues, an efficient and robust data dissemination process turns out to be an exceptional and difficult task. Most of the automobile industries are concentrating on the efficient data dissemination in VANETs. Literature presents several data dissemination protocols designed for various VANETs scenarios to operate under diverse traffic conditions [10, 11].This paper focuses on data dissemination technique that addresses the broadcast storm, network partition, and intermittently connected network problems simultaneously. The broad picture of the paper is summarized below as major contributions of our work:(i)
At first, an efficient and reliable data dissemination protocol is developed to manage data dissemination in highway and urban VANET scenarios.(ii)
Secondly, wagon wheel model is introduced, which divides the transmission area of source vehicle into three distinct segments. This segmentation assists the proposed protocol to select the best vehicle among many to carry on the dissemination process and hence mitigate the broadcast storm problem.(iii)
Additionally, the number of redundant transmissions is controlled and reduced through careful selection of the next forwarding vehicle using NFV selection algorithm to tackle the scalability issue under dense traffic conditions.(iv)
Furthermore, in-depth review of the important characteristics of several existing data dissemination protocols in VANETs is also presented.The rest of the paper is organized as follows: Section2 presents the background knowledge, related work, and qualitative comparison of various data dissemination protocols. Section 3 focuses on the proposed DDP4V protocol. Section 4 covers the performance evaluation and corresponding results, while Section 5 concludes this work.


## 2. Related Work

In literature, a large number of protocols have been designed and proposed for data dissemination in VANETs. These protocols can be categorized into two groups on the basis of road scenarios: protocols for highway and urban VANET scenarios.


### 2.1. Data Dissemination Protocols for Highway Scenarios

Distributed Vehicular broadCAST (DV-CAST) protocol [12] and Simple and Robust Dissemination (SRD) [13] protocols were proposed to work under both sparse and dense traffic conditions. Both DV-CAST and SRD depend on solely one-hop neighbour information gathered through periodic beacon messages. These protocols work in three steps: (1) determine neighbour vehicles and concerned information through periodic beacon messages to establish local topology, (2) employ the broadcast suppression mechanism to mitigate the broadcast storm problem, and (3) use the store-carry-forward mechanism to deal with partitioned and fragmented networks. SRD improves the robustness, high delivery ratio, and low delivery delay of the DV-CAST protocols. Both protocols operate well in well-connected and intermittently connected networks. However, both were designed for highway scenario and did not perform well in high mobility scenarios as the formation of ideal beacon frequency turns out to be difficult. Likewise, DRIFT protocol [14] addresses both the broadcast storm and network fragmentation problems simultaneously.Unlike DV-CAST and SRD, DRIFT protocol does not need neighbour vehicles information to disseminate data. DRIFT protocol assigns highest forwarding priority to the vehicle(s) located inside the preference zone to disseminate data packet further and it consequently provides efficient data dissemination along with low overhead, small delay, and extended coverage. It mitigates the broadcast storm through a controlled selection of NFVs and deals with intermittently connected networks using store-carry-forward mechanism. Another such protocol that does not depend on neighbour information during data dissemination process is Speed Adaptive Broadcast (SAB): Probabilistic SAB, Slotted SAB, and Grid SAB [15]. It uses speed information of vehicles to determine the traffic conditions and select the most suitable NFV. Similarly, another beaconless approach is Simple and Efficient Adaptive Data (SEAD) dissemination protocol [16]. Herein each vehicle updates a redundancy ratio to determine its neighbour vehicles density. Subsequently, each vehicle node computes its forwarding priority and corresponding waiting time on the basis of slotted-1 persistence approach and calculated redundancy ratio.A protocol termed BROADCOMM has been proposed, which disseminates the emergency warning messages in VANETs using geographical routing [17]. It divides the highway into virtual cells, establishing a virtual infrastructure moving with vehicle’s movement. This protocol uses two-level hierarchical structure. In the first level, vehicles inside a cell communicate with each other and with vehicles of neighbour cells located inside the communication range. In the second level, vehicles closer to the geographical centre of a cell are selected for communication with other vehicles in the same as well as the neighbour cell. These vehicles are termed as Cell Reflectors (CR) and work like cluster heads (CHs). CR of each cell is selected by the vehicles of that cell through a selection process. An additional, cluster-based safety message broadcast approach is VMaSC-LTE [18] that combines cluster-based multihop 802.11p approach (Vehicular Multihop algorithm for Stable Clustering (VMaSC)) with cellular system Long-Term Evolution (LTE). It employs IEEE 802.11p to deal with the broadcast storm and intermittently connected network problems, while cellular system LTE is used due to its wide-range communication and low latency. Herein vehicles are clustered using VMaSC approach followed by cluster head (CH) selection. Elected CHs perform as dual-interface nodes to connect the VANET to LTE network.Probabilistic data dissemination protocols have been largely used for data distribution in VANETs. Irresponsible Forwarding (IF) [19] selects the NFV on the basis of (1) distance from the source vehicle and (2) density of neighbour vehicles. In IF protocol, each vehicle determines whether there is such vehicle among its neighbours, which explains comparatively high forwarding probability. If yes is the case, then the former vehicle does not retransmit the data packet “irresponsibly” and leave it for the later vehicle to retransmit. It mitigates the broadcast storm by controlling and regulating the transmission rate of data packets. Similarly, cluster-based Irresponsible Forwarding (CIF) [20], an event-driven broadcast protocol, is derived from IF. It combines the probabilistic approach of IF with the cluster-based structure to increase the reliability and performance of actual IF. Similarly, three distributed and probabilistic data dissemination protocols, weighted p-persistence, slotted 1-persistence, and slotted p-persistence [21], were designed for increased reach ability, reduced number of collisions at MAC layer, and decreased redundancy in dense traffic conditions. Accordingly, each vehicle computes its retransmission probability using information obtained from global positioning system before transmitting the received data packet.MobiCast [22] protocol is designed for some particular VANET applications that involve spatiotemporal coordination and support time-based changes in the network topology. In MobiCast, vehicles transmit data packets to their neighbours connected for real-time communication inside the zone of relevance (ZoR). It also uses another dynamic time-variant area, that is, zone of forwarding (ZoF) inside ZoR. Vehicles located inside ZoF are responsible for further retransmission of received data packet inside a network. Main complexity of this protocol is the selection of ZoR, ZoF, and vehicles inside the ZoF through a complex technique. Likewise, MobiCast-Carry-Forward (MCF) protocol [9], an improvement over actual MobiCast, was proposed for comfort applications in VANETs based on a prescribed geographical area (ZoR). The major difference between the two is the use of the carry-forward technique in MCF, which results in higher end-to-end delay (comparatively) and might not be acceptable in emergency applications. It improves the actual MobiCast protocol in terms of dissemination success rate and network overhead.Emergency-Degree-based broadCast (EDCast) [23] is designed on the basis of safety information quantity. Therefore, an emergency-degree parameter is used to evaluate the information quantity in broadcast safety messages. EDCast computes priority of each safety message to access the channel based on emergency degree. Hence it offers precise and up-to-date vehicular information to the vehicles of a network.


### 2.2. Data Dissemination Protocols for Urban Scenarios

Urban Multihop Broadcast (UMB) [24] protocol based on IEEE 802.11 standard was designed to deal with broadcast storm via multihop V2V and V2I communication. UMB protocol selects the farthest vehicle from the sender as the next data packet forwarder in the broadcast direction. It makes use of repeaters at an intersection in order to broadcast data packet in all directions within the area of interest. It is worth noticing that use of repeaters at every intersection may not be feasible in various scenarios. Conversely, Ad hoc Multihop Broadcast (AMB) protocol [25], an extension to UMB protocol, eliminates the need of infrastructure support (until obstacles block the sight line among different road segments at intersections). Comparatively, AMB protocol confirms high success rate and efficient bandwidth utilization even at high data loads. Similarly, Distance-Based Relay Selection (DBRS) protocol [26] uses distance-based forwarding strategy to control and regulate the number of forwarding vehicles. In DBRS, each vehicle retains the received data packet for a certain waiting time. The waiting time is inversely proportional to the distance between the receiving and the transmitting vehicles. Therefore, farthest vehicles have shortest waiting time and vice versa. DBRS performs well in mitigating the broadcast storm by controlling retransmissions of same data packet but may face low coverage. Also, lack of vehicles at the edges of transmission range may incur high delays.A decentralized data dissemination protocol, Adaptive approach for Information Dissemination (AID) [27], makes use of counter-based forwarding strategy to select the NFV. In AID, selection of NFV depends upon the number of the same data packets received in a specified period. It mitigates the broadcast storm as several vehicles discard the scheduled data packet received from multiple other vehicles. AID does not address the network partition and network fragmentation problems. U-Hydi [28] protocol addresses both the broadcast storm and network fragmentation problems simultaneously. It uses both sender-based and receiver-based approaches to mitigate the broadcast storm in dense urban scenarios. It makes use of store-carry-forward technique to ensure data packet delivery through fragmented networks.A geocast Data dissemination Protocol based on Map Splitting (DPMS) [29] does not require any infrastructure support. It splits the map of an urban scenario into multiple regions. Afterwards, DPMS creates a zone of relevance (ZoR) by combining multiple significant regions where the event arises. It requires a smart technique for digital map autosplitting. Similarly, Hybrid Based Election Backbone (HBEB) [30] and Network-Coding-Assisted Scheduling (NCAS) [31] protocols use backbone-based and network-coding-based forwarding strategies, respectively, to disseminate data. In HBEB, small backbones with a single originator (backbone node) are formed for the fast and efficient propagation of data inside a network. Selection of backbone nodes is accomplished through contention-based forwarding mechanism. The NCAS protocol performs both V2V and V2I communications and employs them for efficient data services. It also makes use of cache strategy that allows vehicle nodes to recall their unrequested data and hence improve data sharing and data services.


## 2.1. Data Dissemination Protocols for Highway Scenarios

Distributed Vehicular broadCAST (DV-CAST) protocol [12] and Simple and Robust Dissemination (SRD) [13] protocols were proposed to work under both sparse and dense traffic conditions. Both DV-CAST and SRD depend on solely one-hop neighbour information gathered through periodic beacon messages. These protocols work in three steps: (1) determine neighbour vehicles and concerned information through periodic beacon messages to establish local topology, (2) employ the broadcast suppression mechanism to mitigate the broadcast storm problem, and (3) use the store-carry-forward mechanism to deal with partitioned and fragmented networks. SRD improves the robustness, high delivery ratio, and low delivery delay of the DV-CAST protocols. Both protocols operate well in well-connected and intermittently connected networks. However, both were designed for highway scenario and did not perform well in high mobility scenarios as the formation of ideal beacon frequency turns out to be difficult. Likewise, DRIFT protocol [14] addresses both the broadcast storm and network fragmentation problems simultaneously.Unlike DV-CAST and SRD, DRIFT protocol does not need neighbour vehicles information to disseminate data. DRIFT protocol assigns highest forwarding priority to the vehicle(s) located inside the preference zone to disseminate data packet further and it consequently provides efficient data dissemination along with low overhead, small delay, and extended coverage. It mitigates the broadcast storm through a controlled selection of NFVs and deals with intermittently connected networks using store-carry-forward mechanism. Another such protocol that does not depend on neighbour information during data dissemination process is Speed Adaptive Broadcast (SAB): Probabilistic SAB, Slotted SAB, and Grid SAB [15]. It uses speed information of vehicles to determine the traffic conditions and select the most suitable NFV. Similarly, another beaconless approach is Simple and Efficient Adaptive Data (SEAD) dissemination protocol [16]. Herein each vehicle updates a redundancy ratio to determine its neighbour vehicles density. Subsequently, each vehicle node computes its forwarding priority and corresponding waiting time on the basis of slotted-1 persistence approach and calculated redundancy ratio.A protocol termed BROADCOMM has been proposed, which disseminates the emergency warning messages in VANETs using geographical routing [17]. It divides the highway into virtual cells, establishing a virtual infrastructure moving with vehicle’s movement. This protocol uses two-level hierarchical structure. In the first level, vehicles inside a cell communicate with each other and with vehicles of neighbour cells located inside the communication range. In the second level, vehicles closer to the geographical centre of a cell are selected for communication with other vehicles in the same as well as the neighbour cell. These vehicles are termed as Cell Reflectors (CR) and work like cluster heads (CHs). CR of each cell is selected by the vehicles of that cell through a selection process. An additional, cluster-based safety message broadcast approach is VMaSC-LTE [18] that combines cluster-based multihop 802.11p approach (Vehicular Multihop algorithm for Stable Clustering (VMaSC)) with cellular system Long-Term Evolution (LTE). It employs IEEE 802.11p to deal with the broadcast storm and intermittently connected network problems, while cellular system LTE is used due to its wide-range communication and low latency. Herein vehicles are clustered using VMaSC approach followed by cluster head (CH) selection. Elected CHs perform as dual-interface nodes to connect the VANET to LTE network.Probabilistic data dissemination protocols have been largely used for data distribution in VANETs. Irresponsible Forwarding (IF) [19] selects the NFV on the basis of (1) distance from the source vehicle and (2) density of neighbour vehicles. In IF protocol, each vehicle determines whether there is such vehicle among its neighbours, which explains comparatively high forwarding probability. If yes is the case, then the former vehicle does not retransmit the data packet “irresponsibly” and leave it for the later vehicle to retransmit. It mitigates the broadcast storm by controlling and regulating the transmission rate of data packets. Similarly, cluster-based Irresponsible Forwarding (CIF) [20], an event-driven broadcast protocol, is derived from IF. It combines the probabilistic approach of IF with the cluster-based structure to increase the reliability and performance of actual IF. Similarly, three distributed and probabilistic data dissemination protocols, weighted p-persistence, slotted 1-persistence, and slotted p-persistence [21], were designed for increased reach ability, reduced number of collisions at MAC layer, and decreased redundancy in dense traffic conditions. Accordingly, each vehicle computes its retransmission probability using information obtained from global positioning system before transmitting the received data packet.MobiCast [22] protocol is designed for some particular VANET applications that involve spatiotemporal coordination and support time-based changes in the network topology. In MobiCast, vehicles transmit data packets to their neighbours connected for real-time communication inside the zone of relevance (ZoR). It also uses another dynamic time-variant area, that is, zone of forwarding (ZoF) inside ZoR. Vehicles located inside ZoF are responsible for further retransmission of received data packet inside a network. Main complexity of this protocol is the selection of ZoR, ZoF, and vehicles inside the ZoF through a complex technique. Likewise, MobiCast-Carry-Forward (MCF) protocol [9], an improvement over actual MobiCast, was proposed for comfort applications in VANETs based on a prescribed geographical area (ZoR). The major difference between the two is the use of the carry-forward technique in MCF, which results in higher end-to-end delay (comparatively) and might not be acceptable in emergency applications. It improves the actual MobiCast protocol in terms of dissemination success rate and network overhead.Emergency-Degree-based broadCast (EDCast) [23] is designed on the basis of safety information quantity. Therefore, an emergency-degree parameter is used to evaluate the information quantity in broadcast safety messages. EDCast computes priority of each safety message to access the channel based on emergency degree. Hence it offers precise and up-to-date vehicular information to the vehicles of a network.


## 2.2. Data Dissemination Protocols for Urban Scenarios

Urban Multihop Broadcast (UMB) [24] protocol based on IEEE 802.11 standard was designed to deal with broadcast storm via multihop V2V and V2I communication. UMB protocol selects the farthest vehicle from the sender as the next data packet forwarder in the broadcast direction. It makes use of repeaters at an intersection in order to broadcast data packet in all directions within the area of interest. It is worth noticing that use of repeaters at every intersection may not be feasible in various scenarios. Conversely, Ad hoc Multihop Broadcast (AMB) protocol [25], an extension to UMB protocol, eliminates the need of infrastructure support (until obstacles block the sight line among different road segments at intersections). Comparatively, AMB protocol confirms high success rate and efficient bandwidth utilization even at high data loads. Similarly, Distance-Based Relay Selection (DBRS) protocol [26] uses distance-based forwarding strategy to control and regulate the number of forwarding vehicles. In DBRS, each vehicle retains the received data packet for a certain waiting time. The waiting time is inversely proportional to the distance between the receiving and the transmitting vehicles. Therefore, farthest vehicles have shortest waiting time and vice versa. DBRS performs well in mitigating the broadcast storm by controlling retransmissions of same data packet but may face low coverage. Also, lack of vehicles at the edges of transmission range may incur high delays.A decentralized data dissemination protocol, Adaptive approach for Information Dissemination (AID) [27], makes use of counter-based forwarding strategy to select the NFV. In AID, selection of NFV depends upon the number of the same data packets received in a specified period. It mitigates the broadcast storm as several vehicles discard the scheduled data packet received from multiple other vehicles. AID does not address the network partition and network fragmentation problems. U-Hydi [28] protocol addresses both the broadcast storm and network fragmentation problems simultaneously. It uses both sender-based and receiver-based approaches to mitigate the broadcast storm in dense urban scenarios. It makes use of store-carry-forward technique to ensure data packet delivery through fragmented networks.A geocast Data dissemination Protocol based on Map Splitting (DPMS) [29] does not require any infrastructure support. It splits the map of an urban scenario into multiple regions. Afterwards, DPMS creates a zone of relevance (ZoR) by combining multiple significant regions where the event arises. It requires a smart technique for digital map autosplitting. Similarly, Hybrid Based Election Backbone (HBEB) [30] and Network-Coding-Assisted Scheduling (NCAS) [31] protocols use backbone-based and network-coding-based forwarding strategies, respectively, to disseminate data. In HBEB, small backbones with a single originator (backbone node) are formed for the fast and efficient propagation of data inside a network. Selection of backbone nodes is accomplished through contention-based forwarding mechanism. The NCAS protocol performs both V2V and V2I communications and employs them for efficient data services. It also makes use of cache strategy that allows vehicle nodes to recall their unrequested data and hence improve data sharing and data services.


## 3. Data Dissemination Protocol for Vehicular Ad Hoc Networks (DDP4V)

To address the problems of broadcast storm, network partition, intermittently connected network, and most suitable NFV selection mentioned in the previous section, we propose an efficient data dissemination protocol for VANETs (DDP4V). The proposed protocol evenly distributes emergency messages across the network and maximizes the data dissemination inside concerned area of a network with low overhead, low collisions, and smaller delay. It operates in both highway and urban VANET scenarios under diverse traffic conditions. The proposed protocol mitigates the broadcast storm though controlled number of redundant transmissions. It provides the guaranteed distribution of data across network partitions and intermittently connected networks using vehicles outside the concerned area. DDP4V employs the segmentation of transmission region (termed as wagon wheel) of a vehicle to select the most appropriate NFV and enhance the coverage.Definition (Wagon Wheel). It presents a circular area around a vehicle where it can directly communicate with its neighbours. This area is divided into two distinct segments, that is, behind and ahead segments. Behind segment is further divided into two subsegments: ideal and normal. The segmentation of transmission region is based on the significance of vehicles to be selected as the next forwarder. Each segment has a unique packet forwarding priority such that ideal segment comprises the highest priority followed by normal and then ahead segment.Figure1 depicts the concept of a wagon wheel. Here neighbour vehicles can be located indiscriminately anywhere inside the three segments of wagon wheel. In our case, the transmission region of a vehicle is considered to be a circular area around itself ranging from 200 to 300 meters. However, shapes other than circle also work with the proposed protocol. The prime advantage of using the wagon wheel concept is to avoid the transmissions of the same data packet by the neighbour vehicles (closer to each other) located in different segments and covering similar or even less significant area, hence mitigating the broadcast storm problem. Vehicles inside the ideal segment are most appropriate and sufficient to carry on data dissemination process with reduced number of transmissions (network load).Figure 1
Wagon wheel (segmentation of transmission range).


### 3.1. Proposed Protocol

The proposed protocol for data dissemination is divided into various phases as shown in Figure2. The whole process is divided into the following six phases.Figure 2
The proposed protocol for data dissemination in VANETs.


#### 3.1.1. Emergency Detection Phase

In this phase, an emergency is detected or experienced by the source vehicle (also called the originating vehicle). The emergency is produced by an arbitrary vehicle that stops abruptly at road describing an accident. We assume some basic information of 1-hop neighbour vehicles such as vehicle ID, position, moving direction, and distance concerning the source. Information about vehicles is collected through the position-aware system such as global positioning systems. These vehicles share this information with source as well as other vehicles of the network to establish the network topology accordingly. This information is later used by the source vehicle to determine the forwarding priorities of vehicles and the best NFV.


#### 3.1.2. Emergency Message Broadcast Phase

The source vehicle initiates the data dissemination process by broadcasting data packet containing an emergency message. The data packet is disseminated in the opposite direction to inform the drivers approaching the place of emergency. One of the aims of proposed method is to distribute a data packet through multihop communication in order to be aware of maximum number of vehicles from this communication. It is worth noticing that DDP4V protocol does not require maintaining and updating neighbour information table, which turns out to be difficult during dense traffic conditions.


#### 3.1.3. Positioning Phase

The proposed protocol requires an appropriate classification of neighbour vehicles to select the best option for further retransmissions and continue data dissemination in VANETs. In this phase, at first, the information collected from neighbouring vehicles is used to determine the number of receiving vehicles inside the transmission region. Afterwards, the source vehicle divides its transmission region into different segments, where each segment represents an area identified by a unique label, as shown in Figure1. Once the segmentation is completed, source determines the position of each receiving vehicle (denoted by R) inside these segments and categorizes them into three groups; ideal, normal, and ahead vehicles. Hence, farthest vehicles inside the ideal segment moving towards source vehicle are the best option to be the next forwarder of the data packet. Using this approach, a single farthest vehicle inside the ideal segment is enough to retransmit the data packet with the lowest delay and cancel the redundant retransmissions as well. In case no vehicle exists inside the ideal segment, the farthest vehicle(s) from normal segment will forward the data packet to carry on the dissemination process. Similarly, if no vehicle exists inside both the ideal and normal segments, then the farthest vehicle(s) from ahead segment will forward the data packet further. Herein, vehicles inside the high priority segments are supposed to deliver the data packet to a maximum number of neighbour vehicles directly not accessible to the source vehicle. Algorithm 1 presents the process whether the receiving vehicle (R) is positioned in ideal, normal, or ahead segment of the wagon wheel.Algorithm 1:Verifies whether the receiving vehicle (R) is positioned in ideal, normal, or ahead segment of the wagon wheel. It also computes the corresponding waiting time (P1/P2/P3) for Ri vehicles to schedule the transmission of received data packet.
(1)ProcedureNext Forwarder Vehicle (NFV) Selection (2) Input:N// all vehicles within Concern Area (3)Source// vehicle (S) that initiate the data dissemination process (4) (Tx, Ty)// x and y coordinates of transmitter vehicle (Tj) during 2nd and onward hops (5) (Rx, Ry)// x and y coordinates of receiver vehicle (Ri) (6)Output: number of vehicle(s) to carry on data dissemination process// NFV(s) (7)ifthe message is received for first timethen (8)Direction Ri to Tj=∠T′T→,R′R→≤θfor some threshold value ofθ// Ri  & Tj same/opposite direction (9)Position Ri to Tj=angle=atan2(Ty-Ry,Tx-Rx) // two argument function atan2 (arctangent function) (10)Distance Ri to Tj=(Tx-Rx)2+(Ty-Ry)2// distance between Ri and Tj (11)Defaultdelay = 0.01 ×distanceRtoS/communicationRadius// default delay of Ri (12)ifRi inside the behind segment i.e. (angle ≥ 181° and angle ≤ 360°) then//waiting time for priority 1 & 2 (13)ifRi inside the ideal segment i.e. (angle ≥ 226° and angle ≤ 324°) then (14)Delay=defaultdelay+random(0,0.01); //set waiting time for priority 1 (15)end (16)else//set the waiting time for and priority 2 (17)Delay=defaultdelay+random(0.02,0.04); (18)end (19)end (20)else// if inside the ahead segment, set waiting time for priority 3 (21)Delay=defaultdelay+random(0.05,0.07); (22)end (23)Ri.ScheduleMessage(Delay); // Ri has to schedule the transmission (24)end (25)else (26)if Scheduled message then// if already scheduled, cancel scheduling and discard (27)ifDist(Ri,S)>Dist(Tj,S)then// calculate the distance (28)Discards the received message; (29)end (30)end (31)Cancel message scheduled; (32)end (33)end Procedure


#### 3.1.4. Next Forwarder Vehicle Selection Phase

Next forwarder vehicle is responsible for further retransmission of received data packets to neighbours inside the concerned area of a network. The overall performance of a protocol strictly depends on the selection of NFV. Thus, the NFV selection process is very critical for any efficient data dissemination protocol and requires some criteria before selection.NFV Selection Criteria. It is important to select the best vehicle as NFV among all participating vehicles of a network. In the proposed protocol, NFV selection depends on three different parameters; (1) position, (2) distance, and (3) direction concerning source vehicle. Selection decision based on these three parameters ensures routing the data packet effectively towards the target. These parameters are represented by POS, DIST, and DIR, respectively, and aggregated to come up withcumulative value(CV) for each receiving vehicleRi as follows: (1)CVRi=aggregatePOSi+DISTi+DIRi.Position parameter defines the location of a vehicle inside the transmission region. The position ofRi vehicle inside the ideal segment increases its chances to become the NFV. Similarly, distance parameter represents the maximum distance of a vehicle from source vehicle. FarthestRi vehicle from source has more chances to become the NFV. Likewise, the direction parameter describes the direction of a vehicle concerning source. In proposed protocol,Ri vehicles moving towards the source vehicle will directly participate in data dissemination process during dense traffic conditions. Vehicles moving away from source vehicle will participate in data dissemination process during sparse traffic conditions to deal with network partition and/or intermittently connected network problems.NFV Selection. Once the NFV selection criteria are set, the next forwarder vehicle is selected for data packet transmission in its first hop. As discussed earlier, a vehicle with maximum cumulative value will be selected as the NFV for the first hop. In DDP4V protocol, vehicles do not need to maintain the neighbor information table containing the cumulative value of all vehicles in a network. The reselection process of NFV for forthcoming hops (2nd, 3rd, and so on) is decentralized, which does not require the involvement of source vehicle.


#### 3.1.5. Emergency Message Rebroadcast Phase

After aggregating the cumulative value, calculated by source vehicle, eachRi vehicle is assigned a specified waiting time before the retransmission of received data packet. A vehicle with highest cumulative value is designated with shortest waiting time. The computation and assignment of waiting time, that is, P1, P2, or P3, to eachRi vehicle are shown in Algorithm 1. Once the waiting times are set, eachRi vehicle schedules the data packet retransmission. A vehicle with shortest waiting time immediately retransmits the data packet after completing its waiting time in order to carry on the dissemination process.


#### 3.1.6. Reselection Phase

In this phase, our focus is to avoid the reselection of such vehicles, as the NFV, which were previously involved in the dissemination process. By reconsidering such vehicles, the proposed protocol incurs the increased number of retransmissions and network overhead. Therefore, for such purpose, the proposed protocol DDP4V adopts the cancellation strategy of already scheduled data packets. Accordingly, on receiving the data packet again during coming hops, vehicles cancel the retransmission of already scheduled data packet and discards. The same procedure (3rd to 5th phase) will be repeated for the reselection of NFV in the next hops (2nd, 3rd,… and so on) during data dissemination process.


### 3.2. Data Dissemination in Urban VANET Scenarios

The data dissemination in urban VANET scenario is performed using two different scenarios:(1) data dissemination with no network partitions and (2) data dissemination across network partitions.


#### 3.2.1. Data Dissemination with No Network Partitions

In DDP4V, once an emergency is detected by a vehicle, it immediately starts the data dissemination by flooding an emergency data packet (denoted byM) within the concerned area. As discussed earlier, vehicles located inside the ideal segment are the best options to be the NFV(s) to continue the dissemination process and mitigate the broadcast storm problem, explained in Figure 4. By receiving the data packet, each vehicle (Ri) verifies whether it is inside the concerned area or not. If yes, then allowRi to participate in the data dissemination process (Figure 4, point A); otherwise, it can be used in network partitions. IfRi lies inside the concerned area, then it checks whether it is within the transmission range of the transmitting vehicle (Figure 4, point B). If not,Ri simply discards the received data packet. Otherwise, it verifies whether the data packet is received for the first time (Figure 4, point C). If not,Ri verifies whether the received data packet is already scheduled (Figure 4, point D). If the data packet is already scheduled, it cancels the scheduled data packet and then discards it. Otherwise, it directly discards the received data packet. In caseRi receives the data packet for the first time, it verifies whether it is inside the ideal segment of wagon wheel (Figure 4, point E). If so,Ri computes its waiting time (P1). Otherwise, it checks whether it is inside the normal segment (Figure 4, point F). If so,Ri computes its waiting time (P2). Otherwise, it sets its waiting time (P3), respectively, as shown in Algorithm 1. Hence,Ri continues the data dissemination process by flooding the received data packet inside the concerned area.


#### 3.2.2. Data Dissemination across Network Partitions

An urban scenario with network partitions discontinues the data dissemination process as shown in Figure3. As data packet carrying information about the event does not propagate within concerned area of a network, whenever a source vehicle detects network partition(s), it makes use of the vehicle(s) outside the concerned area to disseminate data packet in a network. The main advantage of using vehicles outside the concerned area is to perform data dissemination among vehicles within concerned area separated by network partitions. Upon receiving the data packetM, eachRi vehicle outside the concerned area verifies whether network partition(s) exists or not (Figure 4, point G). If no, thenRi simply discards the received data packet. Otherwise, it checks if the data packet is received for the first time (Figure 4, point H). If no, thenRi verifies whether the received data packet is already scheduled (Figure 4, the point I). If the data packet is already scheduled, it first cancels the already scheduled data packet and then discards it; otherwise, it directly discards the received data packet. In caseRi receives the data packet for the first time, it calculates the waiting time and schedules the transmission of a data packet for calculated time. The computation process of waiting time for vehicles outside the concerned area is presented in Algorithm 2.Algorithm 2:Computes the waiting time for R vehicle positioned outside the concerned area to schedule transmission of received data packet (M) across network partitions.
( 1 ) ProcedureWaiting Time for R during Network Partitions //target is the center of partitioned area inside CA ( 2 )  Input: M//all vehicles outside the Concern Area (CA) ( 3 )  (SPosx, SPosy) //position of source vehicle (S) that initiate the data dissemination process (4) (RPosx, RPosy) //position of receiving vehicle (R) (5) (holeGeometryx, holeGeometryy) // partitioning the concern area (6)Output: Waiting Time //calculated waiting time for R to schedule the transmission of data packet (M) (7)if RPosx> holeGeopmetryx1 then (8)Partitioned Vx = SPosx − CA/2; (9)end if (10)else (11)Partitioned Vx = SPosx + CA/2; (12)end else (13)Partitioned Vy = (holeGeometryy2  − holeGeometryy1)/2; (14)DistParitioned V = RPosx-partitionedVx2+RPosy-partitionedVy2 (15)Delay = 0.07 × (distParitioned V/CA/2); (16)end ProcedureFigure 3
An urban scenario with network partitions.Figure 4
Data dissemination process of DDP4V.


### 3.3. Data Dissemination in Highway VANET Scenarios

In the proposed protocol, the dissemination of received data packet in the highway scenarios is the same as in urban scenarios. The main difference is that, in highway scenarios, before cancelling a scheduled data packet (M),Ri determines its distance from S vehicle as shown in Algorithm 1. IfRi is closer to S thanTj, then scheduling is cancelled; otherwise, the received data packet is discarded as its transmission is not required anymore.


## 3.1. Proposed Protocol

The proposed protocol for data dissemination is divided into various phases as shown in Figure2. The whole process is divided into the following six phases.Figure 2
The proposed protocol for data dissemination in VANETs.


### 3.1.1. Emergency Detection Phase

In this phase, an emergency is detected or experienced by the source vehicle (also called the originating vehicle). The emergency is produced by an arbitrary vehicle that stops abruptly at road describing an accident. We assume some basic information of 1-hop neighbour vehicles such as vehicle ID, position, moving direction, and distance concerning the source. Information about vehicles is collected through the position-aware system such as global positioning systems. These vehicles share this information with source as well as other vehicles of the network to establish the network topology accordingly. This information is later used by the source vehicle to determine the forwarding priorities of vehicles and the best NFV.


### 3.1.2. Emergency Message Broadcast Phase

The source vehicle initiates the data dissemination process by broadcasting data packet containing an emergency message. The data packet is disseminated in the opposite direction to inform the drivers approaching the place of emergency. One of the aims of proposed method is to distribute a data packet through multihop communication in order to be aware of maximum number of vehicles from this communication. It is worth noticing that DDP4V protocol does not require maintaining and updating neighbour information table, which turns out to be difficult during dense traffic conditions.


### 3.1.3. Positioning Phase

The proposed protocol requires an appropriate classification of neighbour vehicles to select the best option for further retransmissions and continue data dissemination in VANETs. In this phase, at first, the information collected from neighbouring vehicles is used to determine the number of receiving vehicles inside the transmission region. Afterwards, the source vehicle divides its transmission region into different segments, where each segment represents an area identified by a unique label, as shown in Figure1. Once the segmentation is completed, source determines the position of each receiving vehicle (denoted by R) inside these segments and categorizes them into three groups; ideal, normal, and ahead vehicles. Hence, farthest vehicles inside the ideal segment moving towards source vehicle are the best option to be the next forwarder of the data packet. Using this approach, a single farthest vehicle inside the ideal segment is enough to retransmit the data packet with the lowest delay and cancel the redundant retransmissions as well. In case no vehicle exists inside the ideal segment, the farthest vehicle(s) from normal segment will forward the data packet to carry on the dissemination process. Similarly, if no vehicle exists inside both the ideal and normal segments, then the farthest vehicle(s) from ahead segment will forward the data packet further. Herein, vehicles inside the high priority segments are supposed to deliver the data packet to a maximum number of neighbour vehicles directly not accessible to the source vehicle. Algorithm 1 presents the process whether the receiving vehicle (R) is positioned in ideal, normal, or ahead segment of the wagon wheel.Algorithm 1:Verifies whether the receiving vehicle (R) is positioned in ideal, normal, or ahead segment of the wagon wheel. It also computes the corresponding waiting time (P1/P2/P3) for Ri vehicles to schedule the transmission of received data packet.
(1)ProcedureNext Forwarder Vehicle (NFV) Selection (2) Input:N// all vehicles within Concern Area (3)Source// vehicle (S) that initiate the data dissemination process (4) (Tx, Ty)// x and y coordinates of transmitter vehicle (Tj) during 2nd and onward hops (5) (Rx, Ry)// x and y coordinates of receiver vehicle (Ri) (6)Output: number of vehicle(s) to carry on data dissemination process// NFV(s) (7)ifthe message is received for first timethen (8)Direction Ri to Tj=∠T′T→,R′R→≤θfor some threshold value ofθ// Ri  & Tj same/opposite direction (9)Position Ri to Tj=angle=atan2(Ty-Ry,Tx-Rx) // two argument function atan2 (arctangent function) (10)Distance Ri to Tj=(Tx-Rx)2+(Ty-Ry)2// distance between Ri and Tj (11)Defaultdelay = 0.01 ×distanceRtoS/communicationRadius// default delay of Ri (12)ifRi inside the behind segment i.e. (angle ≥ 181° and angle ≤ 360°) then//waiting time for priority 1 & 2 (13)ifRi inside the ideal segment i.e. (angle ≥ 226° and angle ≤ 324°) then (14)Delay=defaultdelay+random(0,0.01); //set waiting time for priority 1 (15)end (16)else//set the waiting time for and priority 2 (17)Delay=defaultdelay+random(0.02,0.04); (18)end (19)end (20)else// if inside the ahead segment, set waiting time for priority 3 (21)Delay=defaultdelay+random(0.05,0.07); (22)end (23)Ri.ScheduleMessage(Delay); // Ri has to schedule the transmission (24)end (25)else (26)if Scheduled message then// if already scheduled, cancel scheduling and discard (27)ifDist(Ri,S)>Dist(Tj,S)then// calculate the distance (28)Discards the received message; (29)end (30)end (31)Cancel message scheduled; (32)end (33)end Procedure


### 3.1.4. Next Forwarder Vehicle Selection Phase

Next forwarder vehicle is responsible for further retransmission of received data packets to neighbours inside the concerned area of a network. The overall performance of a protocol strictly depends on the selection of NFV. Thus, the NFV selection process is very critical for any efficient data dissemination protocol and requires some criteria before selection.NFV Selection Criteria. It is important to select the best vehicle as NFV among all participating vehicles of a network. In the proposed protocol, NFV selection depends on three different parameters; (1) position, (2) distance, and (3) direction concerning source vehicle. Selection decision based on these three parameters ensures routing the data packet effectively towards the target. These parameters are represented by POS, DIST, and DIR, respectively, and aggregated to come up withcumulative value(CV) for each receiving vehicleRi as follows: (1)CVRi=aggregatePOSi+DISTi+DIRi.Position parameter defines the location of a vehicle inside the transmission region. The position ofRi vehicle inside the ideal segment increases its chances to become the NFV. Similarly, distance parameter represents the maximum distance of a vehicle from source vehicle. FarthestRi vehicle from source has more chances to become the NFV. Likewise, the direction parameter describes the direction of a vehicle concerning source. In proposed protocol,Ri vehicles moving towards the source vehicle will directly participate in data dissemination process during dense traffic conditions. Vehicles moving away from source vehicle will participate in data dissemination process during sparse traffic conditions to deal with network partition and/or intermittently connected network problems.NFV Selection. Once the NFV selection criteria are set, the next forwarder vehicle is selected for data packet transmission in its first hop. As discussed earlier, a vehicle with maximum cumulative value will be selected as the NFV for the first hop. In DDP4V protocol, vehicles do not need to maintain the neighbor information table containing the cumulative value of all vehicles in a network. The reselection process of NFV for forthcoming hops (2nd, 3rd, and so on) is decentralized, which does not require the involvement of source vehicle.


### 3.1.5. Emergency Message Rebroadcast Phase

After aggregating the cumulative value, calculated by source vehicle, eachRi vehicle is assigned a specified waiting time before the retransmission of received data packet. A vehicle with highest cumulative value is designated with shortest waiting time. The computation and assignment of waiting time, that is, P1, P2, or P3, to eachRi vehicle are shown in Algorithm 1. Once the waiting times are set, eachRi vehicle schedules the data packet retransmission. A vehicle with shortest waiting time immediately retransmits the data packet after completing its waiting time in order to carry on the dissemination process.


### 3.1.6. Reselection Phase

In this phase, our focus is to avoid the reselection of such vehicles, as the NFV, which were previously involved in the dissemination process. By reconsidering such vehicles, the proposed protocol incurs the increased number of retransmissions and network overhead. Therefore, for such purpose, the proposed protocol DDP4V adopts the cancellation strategy of already scheduled data packets. Accordingly, on receiving the data packet again during coming hops, vehicles cancel the retransmission of already scheduled data packet and discards. The same procedure (3rd to 5th phase) will be repeated for the reselection of NFV in the next hops (2nd, 3rd,… and so on) during data dissemination process.


## 3.1.1. Emergency Detection Phase

In this phase, an emergency is detected or experienced by the source vehicle (also called the originating vehicle). The emergency is produced by an arbitrary vehicle that stops abruptly at road describing an accident. We assume some basic information of 1-hop neighbour vehicles such as vehicle ID, position, moving direction, and distance concerning the source. Information about vehicles is collected through the position-aware system such as global positioning systems. These vehicles share this information with source as well as other vehicles of the network to establish the network topology accordingly. This information is later used by the source vehicle to determine the forwarding priorities of vehicles and the best NFV.


## 3.1.2. Emergency Message Broadcast Phase

The source vehicle initiates the data dissemination process by broadcasting data packet containing an emergency message. The data packet is disseminated in the opposite direction to inform the drivers approaching the place of emergency. One of the aims of proposed method is to distribute a data packet through multihop communication in order to be aware of maximum number of vehicles from this communication. It is worth noticing that DDP4V protocol does not require maintaining and updating neighbour information table, which turns out to be difficult during dense traffic conditions.


## 3.1.3. Positioning Phase

The proposed protocol requires an appropriate classification of neighbour vehicles to select the best option for further retransmissions and continue data dissemination in VANETs. In this phase, at first, the information collected from neighbouring vehicles is used to determine the number of receiving vehicles inside the transmission region. Afterwards, the source vehicle divides its transmission region into different segments, where each segment represents an area identified by a unique label, as shown in Figure1. Once the segmentation is completed, source determines the position of each receiving vehicle (denoted by R) inside these segments and categorizes them into three groups; ideal, normal, and ahead vehicles. Hence, farthest vehicles inside the ideal segment moving towards source vehicle are the best option to be the next forwarder of the data packet. Using this approach, a single farthest vehicle inside the ideal segment is enough to retransmit the data packet with the lowest delay and cancel the redundant retransmissions as well. In case no vehicle exists inside the ideal segment, the farthest vehicle(s) from normal segment will forward the data packet to carry on the dissemination process. Similarly, if no vehicle exists inside both the ideal and normal segments, then the farthest vehicle(s) from ahead segment will forward the data packet further. Herein, vehicles inside the high priority segments are supposed to deliver the data packet to a maximum number of neighbour vehicles directly not accessible to the source vehicle. Algorithm 1 presents the process whether the receiving vehicle (R) is positioned in ideal, normal, or ahead segment of the wagon wheel.Algorithm 1:Verifies whether the receiving vehicle (R) is positioned in ideal, normal, or ahead segment of the wagon wheel. It also computes the corresponding waiting time (P1/P2/P3) for Ri vehicles to schedule the transmission of received data packet.
(1)ProcedureNext Forwarder Vehicle (NFV) Selection (2) Input:N// all vehicles within Concern Area (3)Source// vehicle (S) that initiate the data dissemination process (4) (Tx, Ty)// x and y coordinates of transmitter vehicle (Tj) during 2nd and onward hops (5) (Rx, Ry)// x and y coordinates of receiver vehicle (Ri) (6)Output: number of vehicle(s) to carry on data dissemination process// NFV(s) (7)ifthe message is received for first timethen (8)Direction Ri to Tj=∠T′T→,R′R→≤θfor some threshold value ofθ// Ri  & Tj same/opposite direction (9)Position Ri to Tj=angle=atan2(Ty-Ry,Tx-Rx) // two argument function atan2 (arctangent function) (10)Distance Ri to Tj=(Tx-Rx)2+(Ty-Ry)2// distance between Ri and Tj (11)Defaultdelay = 0.01 ×distanceRtoS/communicationRadius// default delay of Ri (12)ifRi inside the behind segment i.e. (angle ≥ 181° and angle ≤ 360°) then//waiting time for priority 1 & 2 (13)ifRi inside the ideal segment i.e. (angle ≥ 226° and angle ≤ 324°) then (14)Delay=defaultdelay+random(0,0.01); //set waiting time for priority 1 (15)end (16)else//set the waiting time for and priority 2 (17)Delay=defaultdelay+random(0.02,0.04); (18)end (19)end (20)else// if inside the ahead segment, set waiting time for priority 3 (21)Delay=defaultdelay+random(0.05,0.07); (22)end (23)Ri.ScheduleMessage(Delay); // Ri has to schedule the transmission (24)end (25)else (26)if Scheduled message then// if already scheduled, cancel scheduling and discard (27)ifDist(Ri,S)>Dist(Tj,S)then// calculate the distance (28)Discards the received message; (29)end (30)end (31)Cancel message scheduled; (32)end (33)end Procedure


## 3.1.4. Next Forwarder Vehicle Selection Phase

Next forwarder vehicle is responsible for further retransmission of received data packets to neighbours inside the concerned area of a network. The overall performance of a protocol strictly depends on the selection of NFV. Thus, the NFV selection process is very critical for any efficient data dissemination protocol and requires some criteria before selection.NFV Selection Criteria. It is important to select the best vehicle as NFV among all participating vehicles of a network. In the proposed protocol, NFV selection depends on three different parameters; (1) position, (2) distance, and (3) direction concerning source vehicle. Selection decision based on these three parameters ensures routing the data packet effectively towards the target. These parameters are represented by POS, DIST, and DIR, respectively, and aggregated to come up withcumulative value(CV) for each receiving vehicleRi as follows: (1)CVRi=aggregatePOSi+DISTi+DIRi.Position parameter defines the location of a vehicle inside the transmission region. The position ofRi vehicle inside the ideal segment increases its chances to become the NFV. Similarly, distance parameter represents the maximum distance of a vehicle from source vehicle. FarthestRi vehicle from source has more chances to become the NFV. Likewise, the direction parameter describes the direction of a vehicle concerning source. In proposed protocol,Ri vehicles moving towards the source vehicle will directly participate in data dissemination process during dense traffic conditions. Vehicles moving away from source vehicle will participate in data dissemination process during sparse traffic conditions to deal with network partition and/or intermittently connected network problems.NFV Selection. Once the NFV selection criteria are set, the next forwarder vehicle is selected for data packet transmission in its first hop. As discussed earlier, a vehicle with maximum cumulative value will be selected as the NFV for the first hop. In DDP4V protocol, vehicles do not need to maintain the neighbor information table containing the cumulative value of all vehicles in a network. The reselection process of NFV for forthcoming hops (2nd, 3rd, and so on) is decentralized, which does not require the involvement of source vehicle.


## 3.1.5. Emergency Message Rebroadcast Phase

After aggregating the cumulative value, calculated by source vehicle, eachRi vehicle is assigned a specified waiting time before the retransmission of received data packet. A vehicle with highest cumulative value is designated with shortest waiting time. The computation and assignment of waiting time, that is, P1, P2, or P3, to eachRi vehicle are shown in Algorithm 1. Once the waiting times are set, eachRi vehicle schedules the data packet retransmission. A vehicle with shortest waiting time immediately retransmits the data packet after completing its waiting time in order to carry on the dissemination process.


## 3.1.6. Reselection Phase

In this phase, our focus is to avoid the reselection of such vehicles, as the NFV, which were previously involved in the dissemination process. By reconsidering such vehicles, the proposed protocol incurs the increased number of retransmissions and network overhead. Therefore, for such purpose, the proposed protocol DDP4V adopts the cancellation strategy of already scheduled data packets. Accordingly, on receiving the data packet again during coming hops, vehicles cancel the retransmission of already scheduled data packet and discards. The same procedure (3rd to 5th phase) will be repeated for the reselection of NFV in the next hops (2nd, 3rd,… and so on) during data dissemination process.


## 3.2. Data Dissemination in Urban VANET Scenarios

The data dissemination in urban VANET scenario is performed using two different scenarios:(1) data dissemination with no network partitions and (2) data dissemination across network partitions.


### 3.2.1. Data Dissemination with No Network Partitions

In DDP4V, once an emergency is detected by a vehicle, it immediately starts the data dissemination by flooding an emergency data packet (denoted byM) within the concerned area. As discussed earlier, vehicles located inside the ideal segment are the best options to be the NFV(s) to continue the dissemination process and mitigate the broadcast storm problem, explained in Figure 4. By receiving the data packet, each vehicle (Ri) verifies whether it is inside the concerned area or not. If yes, then allowRi to participate in the data dissemination process (Figure 4, point A); otherwise, it can be used in network partitions. IfRi lies inside the concerned area, then it checks whether it is within the transmission range of the transmitting vehicle (Figure 4, point B). If not,Ri simply discards the received data packet. Otherwise, it verifies whether the data packet is received for the first time (Figure 4, point C). If not,Ri verifies whether the received data packet is already scheduled (Figure 4, point D). If the data packet is already scheduled, it cancels the scheduled data packet and then discards it. Otherwise, it directly discards the received data packet. In caseRi receives the data packet for the first time, it verifies whether it is inside the ideal segment of wagon wheel (Figure 4, point E). If so,Ri computes its waiting time (P1). Otherwise, it checks whether it is inside the normal segment (Figure 4, point F). If so,Ri computes its waiting time (P2). Otherwise, it sets its waiting time (P3), respectively, as shown in Algorithm 1. Hence,Ri continues the data dissemination process by flooding the received data packet inside the concerned area.


### 3.2.2. Data Dissemination across Network Partitions

An urban scenario with network partitions discontinues the data dissemination process as shown in Figure3. As data packet carrying information about the event does not propagate within concerned area of a network, whenever a source vehicle detects network partition(s), it makes use of the vehicle(s) outside the concerned area to disseminate data packet in a network. The main advantage of using vehicles outside the concerned area is to perform data dissemination among vehicles within concerned area separated by network partitions. Upon receiving the data packetM, eachRi vehicle outside the concerned area verifies whether network partition(s) exists or not (Figure 4, point G). If no, thenRi simply discards the received data packet. Otherwise, it checks if the data packet is received for the first time (Figure 4, point H). If no, thenRi verifies whether the received data packet is already scheduled (Figure 4, the point I). If the data packet is already scheduled, it first cancels the already scheduled data packet and then discards it; otherwise, it directly discards the received data packet. In caseRi receives the data packet for the first time, it calculates the waiting time and schedules the transmission of a data packet for calculated time. The computation process of waiting time for vehicles outside the concerned area is presented in Algorithm 2.Algorithm 2:Computes the waiting time for R vehicle positioned outside the concerned area to schedule transmission of received data packet (M) across network partitions.
( 1 ) ProcedureWaiting Time for R during Network Partitions //target is the center of partitioned area inside CA ( 2 )  Input: M//all vehicles outside the Concern Area (CA) ( 3 )  (SPosx, SPosy) //position of source vehicle (S) that initiate the data dissemination process (4) (RPosx, RPosy) //position of receiving vehicle (R) (5) (holeGeometryx, holeGeometryy) // partitioning the concern area (6)Output: Waiting Time //calculated waiting time for R to schedule the transmission of data packet (M) (7)if RPosx> holeGeopmetryx1 then (8)Partitioned Vx = SPosx − CA/2; (9)end if (10)else (11)Partitioned Vx = SPosx + CA/2; (12)end else (13)Partitioned Vy = (holeGeometryy2  − holeGeometryy1)/2; (14)DistParitioned V = RPosx-partitionedVx2+RPosy-partitionedVy2 (15)Delay = 0.07 × (distParitioned V/CA/2); (16)end ProcedureFigure 3
An urban scenario with network partitions.Figure 4
Data dissemination process of DDP4V.


## 3.2.1. Data Dissemination with No Network Partitions

In DDP4V, once an emergency is detected by a vehicle, it immediately starts the data dissemination by flooding an emergency data packet (denoted byM) within the concerned area. As discussed earlier, vehicles located inside the ideal segment are the best options to be the NFV(s) to continue the dissemination process and mitigate the broadcast storm problem, explained in Figure 4. By receiving the data packet, each vehicle (Ri) verifies whether it is inside the concerned area or not. If yes, then allowRi to participate in the data dissemination process (Figure 4, point A); otherwise, it can be used in network partitions. IfRi lies inside the concerned area, then it checks whether it is within the transmission range of the transmitting vehicle (Figure 4, point B). If not,Ri simply discards the received data packet. Otherwise, it verifies whether the data packet is received for the first time (Figure 4, point C). If not,Ri verifies whether the received data packet is already scheduled (Figure 4, point D). If the data packet is already scheduled, it cancels the scheduled data packet and then discards it. Otherwise, it directly discards the received data packet. In caseRi receives the data packet for the first time, it verifies whether it is inside the ideal segment of wagon wheel (Figure 4, point E). If so,Ri computes its waiting time (P1). Otherwise, it checks whether it is inside the normal segment (Figure 4, point F). If so,Ri computes its waiting time (P2). Otherwise, it sets its waiting time (P3), respectively, as shown in Algorithm 1. Hence,Ri continues the data dissemination process by flooding the received data packet inside the concerned area.


## 3.2.2. Data Dissemination across Network Partitions

An urban scenario with network partitions discontinues the data dissemination process as shown in Figure3. As data packet carrying information about the event does not propagate within concerned area of a network, whenever a source vehicle detects network partition(s), it makes use of the vehicle(s) outside the concerned area to disseminate data packet in a network. The main advantage of using vehicles outside the concerned area is to perform data dissemination among vehicles within concerned area separated by network partitions. Upon receiving the data packetM, eachRi vehicle outside the concerned area verifies whether network partition(s) exists or not (Figure 4, point G). If no, thenRi simply discards the received data packet. Otherwise, it checks if the data packet is received for the first time (Figure 4, point H). If no, thenRi verifies whether the received data packet is already scheduled (Figure 4, the point I). If the data packet is already scheduled, it first cancels the already scheduled data packet and then discards it; otherwise, it directly discards the received data packet. In caseRi receives the data packet for the first time, it calculates the waiting time and schedules the transmission of a data packet for calculated time. The computation process of waiting time for vehicles outside the concerned area is presented in Algorithm 2.Algorithm 2:Computes the waiting time for R vehicle positioned outside the concerned area to schedule transmission of received data packet (M) across network partitions.
( 1 ) ProcedureWaiting Time for R during Network Partitions //target is the center of partitioned area inside CA ( 2 )  Input: M//all vehicles outside the Concern Area (CA) ( 3 )  (SPosx, SPosy) //position of source vehicle (S) that initiate the data dissemination process (4) (RPosx, RPosy) //position of receiving vehicle (R) (5) (holeGeometryx, holeGeometryy) // partitioning the concern area (6)Output: Waiting Time //calculated waiting time for R to schedule the transmission of data packet (M) (7)if RPosx> holeGeopmetryx1 then (8)Partitioned Vx = SPosx − CA/2; (9)end if (10)else (11)Partitioned Vx = SPosx + CA/2; (12)end else (13)Partitioned Vy = (holeGeometryy2  − holeGeometryy1)/2; (14)DistParitioned V = RPosx-partitionedVx2+RPosy-partitionedVy2 (15)Delay = 0.07 × (distParitioned V/CA/2); (16)end ProcedureFigure 3
An urban scenario with network partitions.Figure 4
Data dissemination process of DDP4V.


## 3.3. Data Dissemination in Highway VANET Scenarios

In the proposed protocol, the dissemination of received data packet in the highway scenarios is the same as in urban scenarios. The main difference is that, in highway scenarios, before cancelling a scheduled data packet (M),Ri determines its distance from S vehicle as shown in Algorithm 1. IfRi is closer to S thanTj, then scheduling is cancelled; otherwise, the received data packet is discarded as its transmission is not required anymore.


## 4. Results and Discussions

The performance of the proposed method is evaluated using the network simulator OMNET++ [32], the Vehicular Network Simulation framework Veins [33], and the Simulator for Urban MObility (SUMO) [34]. Moreover, the proposed method is compared with existing well-known data dissemination protocols including Simple Flooding, AID [27], DBRS [26], and DV-CAST [12]. The proposed DDP4V approach is evaluated in terms of coverage, a number of data packets transmitted, delay, and number of collisions.


### 4.1. Evaluation Metrics

To evaluate the performance of the proposed DDP4V protocol against existing data dissemination protocols, the following evaluation metrics were considered:(i)
Coverage: it presents the number of vehicles (in percentage) inside the concerned area which is truly receiving the data packets. In other words, it describes the relation between the total vehicles inside the concerned area and those vehicles that received the data packets. More coverage (approaching 100%) specifies the more reliable solution for data dissemination in VANETs(ii)
A number of data packets transmitted: it corresponds to the total number of data packets transmitted by all vehicles in a network during dissemination process. The high transmission rate of data packets can be due to redundant packets which might lead to broadcast storm(iii)
Delay: it is the amount of time elapsed by disseminated data packets to pass through the entire network, that is, from source to the target vehicles within the concerned area. Low delay is an essential parameter of dissemination protocol especially in applications having time constraints such as emergency messages distribution(iv)
Number of collisions: it describes the average number of data packets’ collisions at MAC layer for all vehicles inside the concerned area. High collision rate during dense traffic conditions may lead the network to face the broadcast storm problem. Thus a minimum number of collisions (packet loss ratio) are required for efficient and reliable transmission


### 4.2. Highway VANET Scenario

The proposed DDP4V protocol operates in diverse VANET scenarios with diverse traffic conditions. Initially, we considered a 10-kilometer-long and straight three-lane highway scenario, where vehicles can move in two opposite directions, that is, from east to west and from west to east. At each opposite edge of the highway, vehicle flow production is established generating and inserting vehicles into the network with a constant rate of 800, 1000, 1200, 1400, 1600, 1800, and 2000 vehicles/hour. In this scenario, the overtaking of vehicles is also ensured and achieved by inserting three types of vehicles: high, moderate, and slow speed vehicles in the network using vehicle production flows. Among these three types, vehicles are capable of reaching a maximum speed of 33 meters/sec, 26 meters/sec, and 20 meters/sec, respectively. Therefore, a scenario with three types of vehicles having different attributes may be considered as a dynamic vehicular network. Number of these vehicles is set different during the simulation process. Each simulation has vehicles with a ratio of 2 : 1 : 1 (i.e., 50% of high, 25% of moderate, and 25% of low speed) of the total vehicles.Once the simulation gets stable, after certain period, an arbitrary vehicle stops abruptly at highway describing an accident. It generates a data packet of 2048 bytes and initiates data dissemination process within the concerned area of 5 km length. At this point, the data packet is an emergency awareness message having information regarding the accident. It has to be disseminated in the opposite direction of the highway in order to inform the drivers approaching the place of the accident. Thus, our intention is to distribute the emergency awareness message through multihop communication within the specified time in the west direction of the highway to alert a maximum number of vehicles moving towards the east side of highway (place of accident). Furthermore, the bit rate is set to 18 Mbits/sec (at MAC layer) along with the transmission power of 1.6 mW, resulting in a transmission range of approx. 250 meters for each vehicle under a two-ray ground propagation model [35]. Every point of the results (shown in Figure 5) represents an average of more than 50 iterations. Table 1 covers the summary of key simulation parameters used in the highway scenario.Table 1
Simulation parameters for highway scenario.
Parameter Value Network simulator Transmission power 1.6 mW Transmission range 250 m Bit rate 18 Mbit/s Concern area 5 Km Data message size 2048 bytes Number of runs/iterations 50+ Mobility simulator Speed (max.), 1st type 33 m/sec Speed (max.), 2nd type 26 m/sec Speed (max.), 3rd type 20 m/sec Acceleration 0.8 m/sec Deceleration 4.5 m/sec Road direction/lanes Two-way/3Figure 5
Simulation results for highway scenario.
(a)
Coverage (b)
Number of data packets transmitted (c)
Delay (d)
Number of collisionsIn Figure5, the results for DDP4V and other protocols at highway scenario with diverse traffic conditions are illustrated. Accordingly, Figure 5(a) presents the coverage results for DDP4V and all other protocols in terms of successful data dissemination at highway scenario under various traffic flows. It can be noticed that only two protocols, that is, DDP4V and Flooding protocol, acquire maximum possible coverage inside the concerned area. Among all the compared protocols, DDP4V presents the best performance in terms of coverage at all traffic circumstances and simulation intervals, that is, at an average of 96%. DDP4V produces closer results as the Flooding protocol does; however, Flooding protocol suffers from a high number of transmissions, which leads the network towards the broadcast storm.Figure5(b) presents a total number of transmitted data packets within the concerned area for all protocols during dissemination process at highway scenario under various traffic flows. It evaluates the efficiency of data dissemination protocol in terms of minimizing the broadcast storm under dense traffic situations. Thus, less number of transmissions confirms better performance in terms of mitigating the broadcast storm. Flooding protocol generates the highest transmission rate as it does not use any broadcast suppression mechanism. On one hand, AID, DBRS, and DV-CAST generate less transmission rate as compared to the DDP4V protocol, but, on the other hand, they present less coverage area inside the concerned area (Figure 5(a)). DDP4V protocol presents high coverage with acceptable low overhead. DBRS is the protocol with the lowest overhead due to its low data packet delivery to all other vehicles within concerned area. Among the group of protocols that provide 100% coverage, DDP4V shows lower overhead than Flooding protocol by approximately 55%.Delivery delay evaluates the performance of data dissemination protocol in terms of average amount of time it requires to deliver a data packet from source to the target vehicle inside the concerned area. Figure5(c) shows the average delay for all protocols and illustrates that AID protocol suffers from the highest delay. In fact, AID waits for data packet receptions from other vehicles (discussed in Section 3.2), and on the basis of these receptions, each vehicle decides whether to forward the data packet or leave it for any other vehicle. In DDP4V, delivery delay is inversely proportional to vehicles density inside the transmission range of a vehicle. Thus a large number of vehicles present minimum delivery delay as vehicles inside the ideal segment retransmit the data packet with shortest waiting time. When compared to DDP4V protocol, the DV-CAST and DBRS protocols show smaller delays but also present low coverage and small propagation distance. Similarly, Flooding protocol confirms the lowest delay with a maximum risk of broadcast storm problem when traffic density increases the concerned area. Although DDP4V protocol presents little extra delay when compared to some protocols during data packet dissemination, still its overall delay decreases significantly with the presence of vehicles inside the ideal segment.The number of collisions represents an average number of data packets’ collisions during the dissemination process. This parameter plays a fundamental role in the performance evaluation of data dissemination protocol, especially in dense traffic conditions. Figure5(d) shows all results for data packet collisions. Accordingly, Flooding protocol, among all the analyzed protocols, presents highest number of collisions that gradually increases with increase in traffic density. This happens because of lack of coordination among vehicles in data packet forwarding process; that is, several vehicles blindly retransmit and try to access the limited available bandwidth simultaneously. The residual protocols along with DDP4V present approximately similar behaviour in terms of collisions, that is, on average 1 collision/vehicle. The DDP4V protocol uses effective broadcast suppression technique to mitigate the broadcast storm in highway scenario and deliver data packet to all vehicles inside the concerned area along with acceptable delay and network overhead.


### 4.3. Urban VANET Scenario without Network Partition

The proposed protocol is evaluated using urban scenario without network partition. We consider a Manhattan-grid scenario composed of ten-by-ten equally spaced two-lane roads covering an area of 1 Km2. For more realistic simulation environment, we set 80 m × 80 m obstacles in each grid using Veins framework representing high-rise buildings to attenuate the signal [36]. Unlike the highway scenario, herein, the bit rate is set to 18 Mbits/sec (at MAC layer) along with the transmission power of 0.98 mW, resulting in a transmission range of approx. 200 meters for each vehicle [35].Once the simulation gets stable, a vehicle (source) located at the centre of the grid initiates the dissemination process by generating and transmitting a data packet of 2048 bytes to all neighbour vehicles of a network. Again, every point of the results is the average of approximately 50 iterations. Since DV-CAST protocol is exclusively designed to operate in highway scenarios, we do not evaluate this protocol over here. Moreover, the evaluation metrics used to assess the DDP4V and other protocols in highway scenario are considered the same to evaluate these protocols in urban scenario. Table2 covers the summary of key simulation parameters used in the urban scenario. At this end, no signal attenuation due to the high-rise building in urban environments is considered.Table 2
Simulation parameters for urban scenario.
Parameter Value Transmission power 0.98 mW Transmission range 200 m Bit rate 18 Mbit/s Concern area 1 Km2 Grid numbers 20/10 (with/without partitions) Grid length 2000/1000 m (with/without partitions) Number of lanes 2 Data message size 2048 bytes Number of iterations 50Results for all protocols at urban scenario without network partition are summarized in Figure6. Accordingly, Figure 6(a) presents the coverage (%) against diverse traffic densities. Flooding protocol declares maximum delivery ratio particularly at high traffic densities and delivers the data packet to almost all vehicles in the concerned area. In fact, Flooding protocol retransmits the data packet for all intended vehicles and thus raises the chance of achieving 100% coverage. At low traffic densities, that is, ≤250 vehicles/Km2, Flooding protocol does not deliver the data packet to all intended vehicles. The rest of the protocols explain similar performance in terms of coverage. Preliminarily, at traffic densities of 200–250 vehicles/Km2, all protocols deliver the data packet to approximately 80% of the intended vehicles. Finally, at high traffic density, that is, 400 vehicles/Km2 and above, these protocols achieve 100% coverage. In DDP4V, we believe that vehicles located inside the ideal segment suppress the further transmission of the data packet by other vehicles located inside other segments. Thus, a small part of the coverage area may become uncovered at low traffic densities.Figure 6
Simulation results for the urban scenario without network partition.
(a)
Coverage (b)
Number of data packets transmitted (c)
Delay (d)
Number of collisionsFigure6(b) shows the total number of transmitted data packets during the dissemination process. Likewise, in highway scenario, Flooding protocol offers the highest overhead due to the simultaneous transmission of the same data packet by all vehicles, resulting in redundant retransmissions. Broadcast suppression mechanism of DDP4V protocol enables it to reduce the number of transmitted data packets, that is, approximately 60%, when compared to Flooding protocol. Also, DDP4V shows less number of disseminated data packets than AID and almost the same as DBRS. Thus DDP4V improves the network performance by avoiding the unnecessary retransmissions and efficient utilization of available bandwidth.Figure6(c) presents the average delay to deliver a data packet to all intended vehicles. Notice that Flooding protocol presents an almost constant delay at diverse traffic densities when compared to other protocols. At low traffic densities, 200–300 vehicles/Km2, DDP4V results in higher delay than Flooding protocol. Conversely, with growing traffic density, DDP4V requires less time for data packets delivery to all intended vehicles. Relatively, DDP4V takes approximately 25% less time to deliver a data packet than AID and DBRS protocols. This confirms that DDP4V is the best solution for such VANET applications, where data packet delivery with strict time requirements is important without incurring in high network load, for example, emergency warning messages. It can be noticed that, in DDP4V protocol, delivery delay decreases with increase in traffic density. This can be explained as follows: whenever traffic density increases in a network, the chances of more vehicles inside the ideal segment also increase. Consequently, vehicles inside the ideal segment transmit the data packet with lowest waiting time, thus decreasing the overall delay during data packet dissemination.Figure6(d) shows the average collisions at the MAC layer during the data packet dissemination process. As can be noticed, Flooding protocol experiences the highest number of collisions, continuously increasing with the growing traffic density. Thus, Flooding protocol cannot handle the broadcast storm problem, particularly in dense traffic conditions. Remaining protocols show almost the same performance in terms of a number of collisions. In DDP4V protocol, the controlled number of redundant retransmissions reduces the packet collisions as vehicles do not require competing for accessing the channel. These results reveal that DDP4V mitigates the broadcast storm along with data packet delivery to the intended vehicles with acceptable delay.


### 4.4. Urban VANET Scenario with Network Partitions

The proposed protocol is further evaluated by considering an urban scenario with a network partition inside the concerned area. Hence, we prepare a Manhattan-grid scenario composed of twenty-by-twenty equally spaced two-lane roads covering an area of 4 Km2. For a network partition inside the concerned area, we insert a large sized obstacle (200 m × 1000 m) aside the source vehicle splitting the concerned area into two horizontal regions. So the vehicles in one region cannot directly communicate with the vehicles in another region. Like the previous scenario, for signal attenuation, obstacles representing high-rise buildings are considered in each grid. Also, the bit rate is set to 18 Mbits/sec with the transmission power of 0.98 mW, resulting in a transmission range of approx. 200 meters for each vehicle.As stated previously, once the simulation becomes stable, a vehicle (source) located at the centre of the grid initiates the dissemination process by generating and transmitting a data packet of 2048 bytes to its neighbours in a network. However, the data packet is disseminated only in one horizontal region of concerned area around the source vehicle due to the network partition. Thus a data packet disseminated in one region of concerned area must be routed through vehicles located outside the concerned area to reach the target vehicles in the other region.Results for all protocols at the urban scenario with network partitions are summarized in Figure7. Accordingly, Figure 7(a) presents the coverage (%) for all protocols against diverse traffic densities. At low traffic densities (≤200 vehicles/Km2), all protocols deliver the data packet to approximately 35–40% of the intended vehicles inside the concerned area. Therefore, it is obvious that, for all protocols, only vehicles located on the same side of the source vehicle (source region) are receiving the transmitted data packets, hence reducing their coverage performance. However, with increasing traffic density, the coverage performance of DDP4V increases as it begins the use of vehicles located outside the concerned area in order to route the data packets from the source region to the partitioned region. At high traffic density, that is, 400 vehicles/Km2, DDP4V achieves more than 90% coverage, about 30% higher than Flooding protocol and other protocols.Figure 7
Simulation results for urban scenario with network partition.
(a)
Coverage (b)
Number of data packets transmitted (c)
Delay (d)
Number of collisionsFigure7(b) shows the total number of transmitted data packets during the dissemination process. It is worth noticing that DDP4V protocol presents the highest overhead which gradually increases with increasing traffic density. In fact, additional data packets are required for message delivery through the network partitions, which directs the DDP4V to face such high overhead. Despite the high overhead of DDP4V, it still does not let the network meet the broadcast storm problem.Figure7(c) illustrates average delay to deliver data packets to all intended vehicles. DDP4V presents the highest delivery delay during data dissemination across network partitions. Higher delay for DDP4V is explained by the use of vehicle outside the concerned area, which requires additional time to route data packet across the partitioned regions of a network. Delivery delay of DDP4V varies from 300 to 400 ms under diverse traffic densities which are acceptable in the majority of the VANETs applications. As in the previous scenario, data delivery delay decreases as traffic density increases. This can be explained as follows: whenever traffic density increases in a network, the chances of more vehicles inside the ideal segment also increase. Thus vehicles inside the ideal segment transmit the data packet with lowest waiting time, decreasing the overall delay.Finally, an average number of collisions at the MAC layer during the data dissemination process are shown in Figure7(d). Despite the fact that DDP4V shows almost the same performance in terms of packet collisions (little higher) as AID and DBRS, it is still much lower (about half in number) than Flooding protocol. Controlled number of redundant retransmissions in DDP4V reduces packet collisions and enables mitigating the broadcast storm problem along with acceptable delivery delay. Thus, DDP4V is the most appropriate option to disseminate emergency messages in an urban scenario with or without network partitions inside the concerned area.


## 4.1. Evaluation Metrics

To evaluate the performance of the proposed DDP4V protocol against existing data dissemination protocols, the following evaluation metrics were considered:(i)
Coverage: it presents the number of vehicles (in percentage) inside the concerned area which is truly receiving the data packets. In other words, it describes the relation between the total vehicles inside the concerned area and those vehicles that received the data packets. More coverage (approaching 100%) specifies the more reliable solution for data dissemination in VANETs(ii)
A number of data packets transmitted: it corresponds to the total number of data packets transmitted by all vehicles in a network during dissemination process. The high transmission rate of data packets can be due to redundant packets which might lead to broadcast storm(iii)
Delay: it is the amount of time elapsed by disseminated data packets to pass through the entire network, that is, from source to the target vehicles within the concerned area. Low delay is an essential parameter of dissemination protocol especially in applications having time constraints such as emergency messages distribution(iv)
Number of collisions: it describes the average number of data packets’ collisions at MAC layer for all vehicles inside the concerned area. High collision rate during dense traffic conditions may lead the network to face the broadcast storm problem. Thus a minimum number of collisions (packet loss ratio) are required for efficient and reliable transmission


## 4.2. Highway VANET Scenario

The proposed DDP4V protocol operates in diverse VANET scenarios with diverse traffic conditions. Initially, we considered a 10-kilometer-long and straight three-lane highway scenario, where vehicles can move in two opposite directions, that is, from east to west and from west to east. At each opposite edge of the highway, vehicle flow production is established generating and inserting vehicles into the network with a constant rate of 800, 1000, 1200, 1400, 1600, 1800, and 2000 vehicles/hour. In this scenario, the overtaking of vehicles is also ensured and achieved by inserting three types of vehicles: high, moderate, and slow speed vehicles in the network using vehicle production flows. Among these three types, vehicles are capable of reaching a maximum speed of 33 meters/sec, 26 meters/sec, and 20 meters/sec, respectively. Therefore, a scenario with three types of vehicles having different attributes may be considered as a dynamic vehicular network. Number of these vehicles is set different during the simulation process. Each simulation has vehicles with a ratio of 2 : 1 : 1 (i.e., 50% of high, 25% of moderate, and 25% of low speed) of the total vehicles.Once the simulation gets stable, after certain period, an arbitrary vehicle stops abruptly at highway describing an accident. It generates a data packet of 2048 bytes and initiates data dissemination process within the concerned area of 5 km length. At this point, the data packet is an emergency awareness message having information regarding the accident. It has to be disseminated in the opposite direction of the highway in order to inform the drivers approaching the place of the accident. Thus, our intention is to distribute the emergency awareness message through multihop communication within the specified time in the west direction of the highway to alert a maximum number of vehicles moving towards the east side of highway (place of accident). Furthermore, the bit rate is set to 18 Mbits/sec (at MAC layer) along with the transmission power of 1.6 mW, resulting in a transmission range of approx. 250 meters for each vehicle under a two-ray ground propagation model [35]. Every point of the results (shown in Figure 5) represents an average of more than 50 iterations. Table 1 covers the summary of key simulation parameters used in the highway scenario.Table 1
Simulation parameters for highway scenario.
Parameter Value Network simulator Transmission power 1.6 mW Transmission range 250 m Bit rate 18 Mbit/s Concern area 5 Km Data message size 2048 bytes Number of runs/iterations 50+ Mobility simulator Speed (max.), 1st type 33 m/sec Speed (max.), 2nd type 26 m/sec Speed (max.), 3rd type 20 m/sec Acceleration 0.8 m/sec Deceleration 4.5 m/sec Road direction/lanes Two-way/3Figure 5
Simulation results for highway scenario.
(a)
Coverage (b)
Number of data packets transmitted (c)
Delay (d)
Number of collisionsIn Figure5, the results for DDP4V and other protocols at highway scenario with diverse traffic conditions are illustrated. Accordingly, Figure 5(a) presents the coverage results for DDP4V and all other protocols in terms of successful data dissemination at highway scenario under various traffic flows. It can be noticed that only two protocols, that is, DDP4V and Flooding protocol, acquire maximum possible coverage inside the concerned area. Among all the compared protocols, DDP4V presents the best performance in terms of coverage at all traffic circumstances and simulation intervals, that is, at an average of 96%. DDP4V produces closer results as the Flooding protocol does; however, Flooding protocol suffers from a high number of transmissions, which leads the network towards the broadcast storm.Figure5(b) presents a total number of transmitted data packets within the concerned area for all protocols during dissemination process at highway scenario under various traffic flows. It evaluates the efficiency of data dissemination protocol in terms of minimizing the broadcast storm under dense traffic situations. Thus, less number of transmissions confirms better performance in terms of mitigating the broadcast storm. Flooding protocol generates the highest transmission rate as it does not use any broadcast suppression mechanism. On one hand, AID, DBRS, and DV-CAST generate less transmission rate as compared to the DDP4V protocol, but, on the other hand, they present less coverage area inside the concerned area (Figure 5(a)). DDP4V protocol presents high coverage with acceptable low overhead. DBRS is the protocol with the lowest overhead due to its low data packet delivery to all other vehicles within concerned area. Among the group of protocols that provide 100% coverage, DDP4V shows lower overhead than Flooding protocol by approximately 55%.Delivery delay evaluates the performance of data dissemination protocol in terms of average amount of time it requires to deliver a data packet from source to the target vehicle inside the concerned area. Figure5(c) shows the average delay for all protocols and illustrates that AID protocol suffers from the highest delay. In fact, AID waits for data packet receptions from other vehicles (discussed in Section 3.2), and on the basis of these receptions, each vehicle decides whether to forward the data packet or leave it for any other vehicle. In DDP4V, delivery delay is inversely proportional to vehicles density inside the transmission range of a vehicle. Thus a large number of vehicles present minimum delivery delay as vehicles inside the ideal segment retransmit the data packet with shortest waiting time. When compared to DDP4V protocol, the DV-CAST and DBRS protocols show smaller delays but also present low coverage and small propagation distance. Similarly, Flooding protocol confirms the lowest delay with a maximum risk of broadcast storm problem when traffic density increases the concerned area. Although DDP4V protocol presents little extra delay when compared to some protocols during data packet dissemination, still its overall delay decreases significantly with the presence of vehicles inside the ideal segment.The number of collisions represents an average number of data packets’ collisions during the dissemination process. This parameter plays a fundamental role in the performance evaluation of data dissemination protocol, especially in dense traffic conditions. Figure5(d) shows all results for data packet collisions. Accordingly, Flooding protocol, among all the analyzed protocols, presents highest number of collisions that gradually increases with increase in traffic density. This happens because of lack of coordination among vehicles in data packet forwarding process; that is, several vehicles blindly retransmit and try to access the limited available bandwidth simultaneously. The residual protocols along with DDP4V present approximately similar behaviour in terms of collisions, that is, on average 1 collision/vehicle. The DDP4V protocol uses effective broadcast suppression technique to mitigate the broadcast storm in highway scenario and deliver data packet to all vehicles inside the concerned area along with acceptable delay and network overhead.


## 4.3. Urban VANET Scenario without Network Partition

The proposed protocol is evaluated using urban scenario without network partition. We consider a Manhattan-grid scenario composed of ten-by-ten equally spaced two-lane roads covering an area of 1 Km2. For more realistic simulation environment, we set 80 m × 80 m obstacles in each grid using Veins framework representing high-rise buildings to attenuate the signal [36]. Unlike the highway scenario, herein, the bit rate is set to 18 Mbits/sec (at MAC layer) along with the transmission power of 0.98 mW, resulting in a transmission range of approx. 200 meters for each vehicle [35].Once the simulation gets stable, a vehicle (source) located at the centre of the grid initiates the dissemination process by generating and transmitting a data packet of 2048 bytes to all neighbour vehicles of a network. Again, every point of the results is the average of approximately 50 iterations. Since DV-CAST protocol is exclusively designed to operate in highway scenarios, we do not evaluate this protocol over here. Moreover, the evaluation metrics used to assess the DDP4V and other protocols in highway scenario are considered the same to evaluate these protocols in urban scenario. Table2 covers the summary of key simulation parameters used in the urban scenario. At this end, no signal attenuation due to the high-rise building in urban environments is considered.Table 2
Simulation parameters for urban scenario.
Parameter Value Transmission power 0.98 mW Transmission range 200 m Bit rate 18 Mbit/s Concern area 1 Km2 Grid numbers 20/10 (with/without partitions) Grid length 2000/1000 m (with/without partitions) Number of lanes 2 Data message size 2048 bytes Number of iterations 50Results for all protocols at urban scenario without network partition are summarized in Figure6. Accordingly, Figure 6(a) presents the coverage (%) against diverse traffic densities. Flooding protocol declares maximum delivery ratio particularly at high traffic densities and delivers the data packet to almost all vehicles in the concerned area. In fact, Flooding protocol retransmits the data packet for all intended vehicles and thus raises the chance of achieving 100% coverage. At low traffic densities, that is, ≤250 vehicles/Km2, Flooding protocol does not deliver the data packet to all intended vehicles. The rest of the protocols explain similar performance in terms of coverage. Preliminarily, at traffic densities of 200–250 vehicles/Km2, all protocols deliver the data packet to approximately 80% of the intended vehicles. Finally, at high traffic density, that is, 400 vehicles/Km2 and above, these protocols achieve 100% coverage. In DDP4V, we believe that vehicles located inside the ideal segment suppress the further transmission of the data packet by other vehicles located inside other segments. Thus, a small part of the coverage area may become uncovered at low traffic densities.Figure 6
Simulation results for the urban scenario without network partition.
(a)
Coverage (b)
Number of data packets transmitted (c)
Delay (d)
Number of collisionsFigure6(b) shows the total number of transmitted data packets during the dissemination process. Likewise, in highway scenario, Flooding protocol offers the highest overhead due to the simultaneous transmission of the same data packet by all vehicles, resulting in redundant retransmissions. Broadcast suppression mechanism of DDP4V protocol enables it to reduce the number of transmitted data packets, that is, approximately 60%, when compared to Flooding protocol. Also, DDP4V shows less number of disseminated data packets than AID and almost the same as DBRS. Thus DDP4V improves the network performance by avoiding the unnecessary retransmissions and efficient utilization of available bandwidth.Figure6(c) presents the average delay to deliver a data packet to all intended vehicles. Notice that Flooding protocol presents an almost constant delay at diverse traffic densities when compared to other protocols. At low traffic densities, 200–300 vehicles/Km2, DDP4V results in higher delay than Flooding protocol. Conversely, with growing traffic density, DDP4V requires less time for data packets delivery to all intended vehicles. Relatively, DDP4V takes approximately 25% less time to deliver a data packet than AID and DBRS protocols. This confirms that DDP4V is the best solution for such VANET applications, where data packet delivery with strict time requirements is important without incurring in high network load, for example, emergency warning messages. It can be noticed that, in DDP4V protocol, delivery delay decreases with increase in traffic density. This can be explained as follows: whenever traffic density increases in a network, the chances of more vehicles inside the ideal segment also increase. Consequently, vehicles inside the ideal segment transmit the data packet with lowest waiting time, thus decreasing the overall delay during data packet dissemination.Figure6(d) shows the average collisions at the MAC layer during the data packet dissemination process. As can be noticed, Flooding protocol experiences the highest number of collisions, continuously increasing with the growing traffic density. Thus, Flooding protocol cannot handle the broadcast storm problem, particularly in dense traffic conditions. Remaining protocols show almost the same performance in terms of a number of collisions. In DDP4V protocol, the controlled number of redundant retransmissions reduces the packet collisions as vehicles do not require competing for accessing the channel. These results reveal that DDP4V mitigates the broadcast storm along with data packet delivery to the intended vehicles with acceptable delay.


## 4.4. Urban VANET Scenario with Network Partitions

The proposed protocol is further evaluated by considering an urban scenario with a network partition inside the concerned area. Hence, we prepare a Manhattan-grid scenario composed of twenty-by-twenty equally spaced two-lane roads covering an area of 4 Km2. For a network partition inside the concerned area, we insert a large sized obstacle (200 m × 1000 m) aside the source vehicle splitting the concerned area into two horizontal regions. So the vehicles in one region cannot directly communicate with the vehicles in another region. Like the previous scenario, for signal attenuation, obstacles representing high-rise buildings are considered in each grid. Also, the bit rate is set to 18 Mbits/sec with the transmission power of 0.98 mW, resulting in a transmission range of approx. 200 meters for each vehicle.As stated previously, once the simulation becomes stable, a vehicle (source) located at the centre of the grid initiates the dissemination process by generating and transmitting a data packet of 2048 bytes to its neighbours in a network. However, the data packet is disseminated only in one horizontal region of concerned area around the source vehicle due to the network partition. Thus a data packet disseminated in one region of concerned area must be routed through vehicles located outside the concerned area to reach the target vehicles in the other region.Results for all protocols at the urban scenario with network partitions are summarized in Figure7. Accordingly, Figure 7(a) presents the coverage (%) for all protocols against diverse traffic densities. At low traffic densities (≤200 vehicles/Km2), all protocols deliver the data packet to approximately 35–40% of the intended vehicles inside the concerned area. Therefore, it is obvious that, for all protocols, only vehicles located on the same side of the source vehicle (source region) are receiving the transmitted data packets, hence reducing their coverage performance. However, with increasing traffic density, the coverage performance of DDP4V increases as it begins the use of vehicles located outside the concerned area in order to route the data packets from the source region to the partitioned region. At high traffic density, that is, 400 vehicles/Km2, DDP4V achieves more than 90% coverage, about 30% higher than Flooding protocol and other protocols.Figure 7
Simulation results for urban scenario with network partition.
(a)
Coverage (b)
Number of data packets transmitted (c)
Delay (d)
Number of collisionsFigure7(b) shows the total number of transmitted data packets during the dissemination process. It is worth noticing that DDP4V protocol presents the highest overhead which gradually increases with increasing traffic density. In fact, additional data packets are required for message delivery through the network partitions, which directs the DDP4V to face such high overhead. Despite the high overhead of DDP4V, it still does not let the network meet the broadcast storm problem.Figure7(c) illustrates average delay to deliver data packets to all intended vehicles. DDP4V presents the highest delivery delay during data dissemination across network partitions. Higher delay for DDP4V is explained by the use of vehicle outside the concerned area, which requires additional time to route data packet across the partitioned regions of a network. Delivery delay of DDP4V varies from 300 to 400 ms under diverse traffic densities which are acceptable in the majority of the VANETs applications. As in the previous scenario, data delivery delay decreases as traffic density increases. This can be explained as follows: whenever traffic density increases in a network, the chances of more vehicles inside the ideal segment also increase. Thus vehicles inside the ideal segment transmit the data packet with lowest waiting time, decreasing the overall delay.Finally, an average number of collisions at the MAC layer during the data dissemination process are shown in Figure7(d). Despite the fact that DDP4V shows almost the same performance in terms of packet collisions (little higher) as AID and DBRS, it is still much lower (about half in number) than Flooding protocol. Controlled number of redundant retransmissions in DDP4V reduces packet collisions and enables mitigating the broadcast storm problem along with acceptable delivery delay. Thus, DDP4V is the most appropriate option to disseminate emergency messages in an urban scenario with or without network partitions inside the concerned area.


## 5. Conclusion and Future Work

In this paper, we proposed a new data dissemination protocol, DDP4V, to overcome the challenging broadcast storm, network partition, intermittently connected network, and optimum next forwarding vehicles (NFVs) selection problems. The proposed protocol shows the potential to provide an efficient data dissemination in diverse VANET scenarios with varying traffic conditions. It presents reasonable performance in three distinct evaluation scenarios: highway scenario and two urban scenarios with and without network partition.Under dense traffic scenario, DDP4V prefers the vehicle(s) inside the ideal segment of transmission region to retransmit the data packet. It decreases the data packet delivery delay with growing traffic densities in all evaluated VANET scenarios as vehicles inside the ideal segment transmit the data packet with shortest waiting time. Wagon wheel concept assists the DDP4V protocol in selecting the best vehicle as next forwarding vehicle to carry on the dissemination process and mitigate the broadcast storm. DDP4V protocol minimizes the number of redundant transmissions through careful selection of the NFV.DDP4V presents the best performance in terms of coverage at each simulation scenario under all traffic conditions. It outperforms the other competing protocols and achieves approximately 100% delivery ratio in highway scenario under dense traffic conditions. Even in the partitioned urban scenario, it presents more coverage by 30% when compared to other evaluated protocols. It makes use of vehicles outside the concerned area to guarantee the successful data dissemination through intermittently connected and partitioned network with extended coverage when compared to other evaluated protocols. It also makes use of a timer-based mechanism to decide when the selected vehicle(s) should actually retransmit the data packet. Accordingly, on receiving a new data packet, each vehicle stores and carries this data packet until its time-to-live expires or the vehicle leaves the concerned area, thus increasing the robustness of the protocol.We build a simulation model and perform a comprehensive performance evaluation of DDP4V protocol in highway and urban VANET scenarios. Simulation results show that it outperforms other related protocols including AID, DBRS, DV-CAST, and Flooding in terms of data packet delivery to all intended vehicles with minimum delay and low overhead. As future work, we are aiming to improve the performance of DDP4V protocol in terms of other important parameters such as the number of duplicate packets, packet propagation, and the number of hops. Moreover, we aim to evaluate our proposed protocol in real city scenarios. Thus, DDP4V is an efficient and reliable option to disseminate emergency messages in highway and urban scenarios with or without network partitions inside the concerned area.



---

*Source: 1857202-2018-04-08.xml*