Sage Journals: Discover world-class research

Abstract

Vehicular ad hoc networks play an important role in the efficiency of road traffic by improving safety and acting as a facilitator of services for passengers, drivers, and public safety officers. Recent improvements in the routing protocols and topologies used in vehicular networks have contributed to improvements in scalability, reliability, and the quality of the information-sharing experience. Vehicles can cooperate with each other to stream videos of accidents or disasters and provide visual information of the monitored area with great precision. This article proposes a collaborative routing protocol for video streaming vehicular ad hoc networks using the service of fog storage to minimize the sharing of content. The routing table is based on an indicator that is generated by combining the speed, location, and recording angle parameters of each vehicle involved in vehicular collaboration to reduce the unnecessary exchange of video data in vehicle-to-vehicle communications. The results of the simulations show that the proposed model performs favorably when compared with other routing protocols with respect to the availability of end-to-end communication.

Keywords

Routing clustering methods vehicular ad hoc networks collaboration fog computing content sharing

Introduction

Traffic accidents pose a major problem for public safety officers. Close consideration of accidents shows that many casualties occur and severe medical conditions arise during the time that elapses between accident occurrence and the arrival of medical aid.¹ The vehicular ad hoc networks (VANETs) emerged to avoid accidents by signaling emergency situations, such as hard braking, mobility intentions, and collisions. However, context messages does not show details about the accident in order to engage proper tools for the emergency teams. Vehicles equipped with camera can stream video content to the public service authorities to reduce rescue time.² However, these video streams require quality of experience (QoE) to deliver minimum quality level on the user experience and provide a clear view of the content.³

Mobile cloud computing is a new field of research that aims to study mobile agents (people, vehicles, and robots) as they interact and collaborate to sense the environment, process the data, propagate the results, and, more generally, share resources. Nonetheless, these initiatives have not been without challenges that include mobility support, location awareness, low latency, and geo-distribution. As a result, a new term has been coined for this novel paradigm: fog computing.⁴

Fog computing adds a layer between the cloud server and the end user. Access points, base stations, routers, and mobile devices can serve as fog servers. Mobile devices can overcome their lack of adequate information technology (IT) resources by using fog computing. Moreover, it is possible to take advantage of the mobility pattern of mobile devices.

The fog presents a new architecture that “takes processing to the data” instead of “taking data to the processing” like cloud computing. Edge devices and mobile devices are interconnected within a local fog network and collaboratively carry out storage, data processing, networking, and control tasks.⁵ Moreover, fog computing can improve videos with poor QoE by quickly process-adapt forwarding decisions to nodes with better network capacities.⁶

With the emergence of ever-growing advanced vehicular applications, the challenges to meet the demands from both communication and computation are increasingly prominent. Without powerful communication and computational support, various vehicular applications and services will remain in the concept phase and cannot be put into practice in daily life.⁷

Therefore, we consider utilizing vehicles as an infrastructure for communication and computation in a framework called vehicular fog computing (VFC), which is an architecture that utilizes a collaborative multitude of end-user clients or near-user edge devices to establish communication and perform computation based on the utilization of the individual communication and computational resources of each vehicle.⁷ Considering the technical advances and economic advantages of integrated architectures and cloud computing, we conjecture that the realization of a real-time cloud, called a fog, which efficiently and flexibly provides reliable electronic services, with temporal guarantees onboard a vehicle, is the next logical step in the development of an automotive electronic architecture.⁸

In a study by Gerla et al.,⁹ an efficient means of distributing content within VANETs utilizes collaborations among access technologies. Iqbal et al.¹⁰ emphasize the challenges involved in offering the context-aware services in an Internet of vehicles (IoV) environment. The IoV is the evolution of VANETs and intelligent transportation systems focused on reaping the benefits of data generated by various sensors within these networks. The myriad amounts of data generated by the vehicles and the environment have the potential to enable diverse services. These services can benefit from both variety and velocity of the generated data. In this article, we adopt the 802.11p standard and long-term evolution (LTE). The latter infrastructure is used in vehicle-to-infrastructure (V2I) communications.

The collaborative routing protocol for video streaming in vehicular ad hoc networks (CRPV) is based on a cluster architecture; moreover, during the vehicle clustering process, some parameters are gathered to rate each vehicle when the cluster is being established. For example, to determine the time over which each vehicle remains in an LTE cell and to check the location of each vehicle of the cluster in an evolved Node B (eNB) function, vehicles that are eligible for cluster formation are identified, the cording angles of the vehicles in the cluster are checked, the region of interest is rated according to the event that has occurred, and the speed of each vehicle in the cluster is analyzed. We further analyze CRPV in terms of quality of service (QoS) and QoE.

The remainder of this article is organized as follows. Section “Related works” describes related studies and some cluster-based routing protocols. Section “Proposed routing protocol” details the proposed routing protocol; in that section, we discuss the system model and the functionality of the protocol. Section “Performance evaluation” details the performance assessment of the proposed protocol. Section “Conclusion” provides the conclusion of the article.

Related works

Fog computing, an extension of cloud computing services to the edge of the network to decrease latency and network congestion, is a relatively recent research trend.¹¹ Although both cloud and fog offer similar resources and services, the latter is characterized by low latency with a wider spread and geographically distributed nodes to support mobility and real-time interaction. Recent advances in wireless communication techniques have made it possible for vehicles to download data from a roadside communications infrastructure via V2I communication, that is, by boosting collaboration between access technologies in a VANET-based scenario.

Numerous clustering and routing algorithms have been recently proposed for VANETs. There are different types of cluster-based routing protocols used to attain efficient communication, but there are still many issues and challenges, such as clustering with respect to bidirectional traffic modeling (for when traffic approaching the roadside units (RSUs) from both directions is unspecified), data dissemination techniques, routing, QoS guarantee, and security.¹²

Latif et al.¹³ reviewed several studies and compared numerous existing multi-hop data broadcast protocols in terms of various attributes such as data-forwarding strategies, objectives, architecture types, application scenarios, assumptions, evaluation metrics, and simulation platforms. Furthermore, an original taxonomy of these protocols was introduced based on the road scenarios with critical discussions of each categorization with respect to strengths, weaknesses, and important constraints. Finally, the various perspectives, challenges, and shortcomings of the existing studies were discussed.

Bagherlou and Ghaffari¹⁴ proposed a cluster-based reliable routing algorithm for VANETs and reliable applications. In this way, simulated annealing was used for the appropriate clustering of nodes, and the parameters of node degree, coverage, and ability were considered in the proposed method.

Qureshi et al.¹⁵ proposed the cluster-based routing protocol for sparse and dense networks to handle dynamic topologies and high mobility of vehicle nodes. The protocol is responsible for setting up a route between source and destination nodes. However, because of the high mobility of vehicles and the intermittent nature of wireless channels, the volume of data downloaded by individual vehicles in V2I communications is very limited. This limitation severely restricts the quality of multimedia applications; consequently, routing protocols adapted to the characteristics of VANETs must be developed by considering that the fog computing paradigm will be the future of computing technology.

The passive clustering-aided routing (PassCAR) protocol for use in VANETs¹⁶ is a cluster-based routing protocol that aims to identify candidates for incorporation in cluster structures with stable (same direction) and reliable characteristics during the route discovery process to improve routing performance in one-way and multiple-lane highway scenarios. As specific objectives of the proposal, each eligible vehicle determines its own priority in the cluster using metrics such as node degree, expected streaming, and link lifetime. The results obtained by the authors are compared with those of the passive cluster mechanism proposed by Hashim et al.¹⁷ for use in VANETs.

According to the authors, the PassCAR protocol increases the probability of successful route discovery and selects the most appropriate nodes for participation in the created cluster. This well-defined structure significantly improves the packet delivery rate and achieves increased throughput in networks due to its preference for reliable, stable, and lasting routing paths. Routing metrics also analyze the probability of forwarding route request (RREQ) packets per hop when selecting the next routing node to build an efficient cluster structure that promotes reliable and lasting routing. This protocol presents problems that balance scalability and reliability, as it considers only vehicles going in the same direction that have stable characteristics. The system becomes compromised when one of the vehicles changes its characteristics. The forwarder smart selection protocol for the limitation of the broadcast storm problem (i.e. the selective reliable broadcast (SRB) protocol)¹⁸ is a cluster-based routing protocol whose purpose is to limit the number of packets streamed over an opportunistic choice of vehicles. The packets are retransmitted only by the selected vehicles to reduce the number of routers, thus preserving an acceptable level of QoS.

The SRB protocol uses the behavior of vehicles in an ad hoc network partition to automatically detect vehicle clusters using zones of interest. Packets are routed only to opportunistically selected vehicles, which are chosen as CHs. The authors assessed the SRB protocol in several vehicle scenarios that mainly represent realistic environments, such as urban areas and highways. The limitations posed by the streaming congestion problem in the SRB format manifests as a decrease in the number of next-hop forwarders. The authors also compared the efficacy of the SRB protocol with traditional streaming protocols and a content-based dissemination approach because of its ability to determine sets of vehicles with common characteristics.

The SRB protocol prevents the restreaming of messages (which is a limitation imposed by the broadcast problem) and detects clusters automatically and quickly. The proposed approach considers the process of message restreaming within a VANET by selecting a limited number of vehicles as potential next-hop forwarders. The SRB protocol is not a typical broadcast routing protocol; instead, it detects sets of vehicles in a quick and efficient way and chooses a CH for each detected cluster. The CH is then chosen as the next message forwarder. The SRB protocol breaks the region occupied by the vehicles into adjacent sectors; moreover, the vehicles are all assumed to be equipped with global positioning system (GPS) units and capable of estimating their own positions. Each partition freely transmits messages from the originating vehicle and is identified as part of a circle. The size of each sector varies dynamically according to the broadcast direction of each vehicle. This protocol poses problems that balance scalability and reliability, considering that it has packet restreaming limitations and limits the number of vehicles that are allowed to transmit. These characteristics compromise the system when the scenario includes few vehicles.

Applications

V2V communications previously emerged to inform context-aware informations, such as velocity, direction, and emergency braking, for cars embedded with equipment to process this kind of information. The technology evolved, and now, the cars own multiple cameras, sensors of multiple natures, such as sonar, light detection and ranging (LIDAR) sensors, and actuators for driving assistance and stability control. All data generated by these sensors can enhance the overall car mobility by maintaining real-time maps of street conditions. Moreover, public service authorities can perform better management of traffic conditions with more valuable information disseminated by the vehicles, assisting not only others common vehicles but ambulances, police, and fire trucks.

Proposed routing protocol

To successfully deliver multimedia broadcasts over VANETs, reliable content delivery, scalability, and video-stream quality must be ensured. The CRPV proposes the following method: (1) A collaborative gateway (CG) calculation is performed to rank each vehicle in a linear list according to its gateway quality indicator (GQI), (2) the routing table for each vehicle in the V2V communication cluster is defined based on the GQI values, (3) the joint collaboration of vehicles in the cluster is carried out to reduce the unnecessary exchange of video data during V2V communication. In most applications that employ multimedia VANETs, all vehicles in a cluster do not need to share the same live video feed; in such a case, redundant information would likely be transmitted, thereby affecting network performance. Therefore, the CRPV is designed to choose the best nodes to distribute video data in real time when events are detected. The video data assist public safety agents; for example, paramedics in ambulances can use these data to prepare to provide care before they even reach the scene of an accident. To achieve broad coverage in a short time, the video data are streamed to fixed users outside the VANET, such as police headquarters or other vehicles that have access to a better network interface at the time. Examples include RSUs or LTE, as shown in Figure 1.

Figure 1.

V2V and V2I communication with vehicular fog.

Figure 1 shows a sample VANET, in which vehicles v1 and v9 have both an LTE interface (V2I communications) and a Wi-Fi interface (V2V communications). Following an event in lane 2, v1, which occupies lane 1, records the moment of the event (an explosion) and shares the broadcast video with its neighbors within its coverage area (v3 and v4). Upon receiving the video, v3 and v4 also share it. Vehicle v4 forwards the video to an RSU in its vicinity, while v3 forwards it to another vehicle in the VANET, v6. Moreover, given the communication capabilities of v1, which also has an LTE interface, v1 forwards the feed to v9, which is still far from the event site and thus receives the video of the event in advance.

CGs

All vehicles that are part of a cluster represent CGs. The identification of vehicles that are eligible to be CGs starts when a cluster is formed. At that time, one vehicle sends a beacon message over a specific (emergency) frequency to find vehicles that are available to establish a cluster after an accident on a highway. The vehicles that return the message at the same frequency become part of the cluster formation. The frequency range is broken into 10-MHz channels. The messages follow the specifications for the wireless access in vehicular environment (WAVE) from the IEEE 1609 standard.¹⁹ Because security and authentication tools are not used in the algorithm-development process, they are not addressed in the remainder of this article.

The CRPV algorithm

To classify CGs, an algorithm is created to calculate the GQI of each vehicle in a cluster. The algorithm in Table 1 employs several parameters, such as the recording angles of the vehicles in the cluster, ratings of the region of interest according to the events that have happened on the road, the speed of each vehicle in the cluster (to determine the time over which each vehicle will remain in an LTE cell), and the location of each vehicle in the cluster according to the eNB.

Table 1.

Algorithm 1 logic used in the CRPV algorithm.

Start

Determine the number of vehicles in the cluster formation;

For each vehicle;

Determine each vehicle recording angle;

Rate the speed of each vehicle in a linear list;

Rate the location of each vehicle according to the eNB;

Perform the GQI calculation;

Define a routing table for each vehicle;

Calculate the best CG to broadcast the video within the V2I network;

Finish

GQI: gateway quality indicator; CG: collaborative gateway.

After the occurrence of an event detected by the vehicle camera sensor, the algorithm of the CRPV begins its execution, identifying the number of vehicles available for the formation of the cluster. During cluster formation, each vehicle should already be as its calculated GQI, since it will be used for the formation of the routing table in each CG. A dynamic routing table is constructed from the information exchanged between each vehicle during cluster formation; among the information is the GQI that is dynamically used as a parameter in the routes to reflect changes in the conditions of the network. CRPV can solve complex routing situations faster and more efficiently. The cluster where there are several alternative routes to a destination (CG with the best GQI) functions as the cluster head, and they can still switch to an alternate route when the primary route becomes unavailable and decide which route is an alternate to the destination, always considering the parameters of the GQI. Finally, the transmission of video from the CG with the best GQI (cluster head) to a V2I network is performed. Figure 2 depicts the flow of the CRPV divided into three phases.

Figure 2.

Flowchart of the CRPV algorithm.

The first phase of the algorithm involves finding the number of vehicles to form the cluster. The second phase involves the calculation of the GQI to find the CGs. Finally, the third phase involves broadcasting the video from the CG with the best GQI to an LTE network or a V2I communication system.

Cluster formation

Clusters are formed after the occurrence of an event is detected by the vehicle camera sensor. At this point, the process of exchanging short high-priority messages sent by the vehicles that recorded the event begins.

To begin finding the number of vehicles that are available to form a cluster within a given region, we consider the messages returned over a specific frequency that are forwarded by one of the CG-eligible vehicles. Table 2 shows all of the IEEE 802.11p parameters.²⁰

Table 2.

IEEE 802.11p standard physical layer specifications.

Parameter	WAVE
Frequency range	5.9 GHz
Channel width	10 MHz
Streaming rate (Mbps)	1, 2, 3, 4, 5, and 6
Modulation	Binary phase shift keying (BPSK), quadrature phase shift keying (QPSK), 16 quadrature amplitude modulation (16QAM), and 64 quadrature amplitude modulation (64QAM)
Channel coding	Convolutional coding rates of 1/2, 2/3, and 3/4

WAVE: wireless access in vehicular environment.

Through the clustering of vehicles, some parameters are collected to classify each vehicle during cluster formation. The cluster heads are classified and chosen according to their GQI, which is calculated according to the parameters collected from the recording angle, vehicle speed, and vehicle location.

According to the IEEE 802.11p standard, one channel (the control channel, CCH) will be used solely to control communications, and the other channels will be used for different categories of network services (service channels, SCHs). The CCH is reserved for the broadcasting of short, high-priority messages or management data, whereas other types of data are transmitted over the SCHs. The CCH has greater priority and streaming power than the SCHs. Table 3 shows the enhanced distributed channel access (EDCA) application categories adapted for use in vehicular networks.²¹

Table 3.

Prioritization equivalence of messages on VANETs.

Priority (EDCA traffic)	VANET message types
Priority 1 (voice traffic—access class 3)	Notification of accidents and messages from emergency vehicles (police, ambulances, firefighters, etc.)
Priority 2 (video traffic—access class 2)	Imminent accident indication messages
Priority 3 (best effort traffic—access class 1)	Messages on weather conditions, road conditions, and warning messages (e.g. school zone or speed bumps ahead)
Priority 4 (background traffic—access class 0)	Other general messages

EDCA: enhanced distributed channel access; VANET: vehicular ad hoc network.

The IEEE 802.11p standard does not include authentication or association in the MAC or physical layers because these methods take a long time under this standard; thus, this standard is unsuitable for vehicular networks.²²

Recording angle

According to Ziegler et al.,²³ there are two methods to classify the recording angles of a vehicle front-view video. These methods are as follows: (1) the vertical viewing angle method and (2) the horizontal viewing angle method. This article uses 180° as the maximum horizontal viewing angle. To map the horizontal viewing angle to regions of interest, three regions of interest are mapped according to the roadway and the horizontal viewing angle. The three mapped regions of interest are the (1) left, (2) central, and (3) right regions. Figure 3 shows the mappings of the three regions of interest.²⁴ These mappings are intended to generate a region of interest parameter that is considered when selecting a video for broadcast in V2I cooperative communications.

Figure 3.

Region of interest angle.

The generated parameter includes an identification of the region of interest based on the identification of objects on the roadway. Thus, the region of interest parameter enables the GQI to consider at which angle in the region of interest the detected object occurs in the recorded video.

Speed

According to Kakarla et al.²⁵ and Bali et al.,²⁶ cluster-broadcast and geocast-based routing protocols use environmental and application information to make their decisions. In general, they all offer the possibility of routed communication among vehicles, provided that a route exists for information traffic made up of a sequence of vehicles that are within communication range of one another. According to Karagiannis et al.,²⁷ the protocols used in VANETs use the distances between vehicles, the speeds and directions of vehicles, the conditions in the vicinities of the vehicles, communication signal capabilities, and other factors to determine the streaming modes of end-to-end messages and impart some confidence of delivery within the desired time frame. As with IEEE 802.11p, such protocols are able to ensure data streaming on nodes moving at a speed of up to 200 km/h.²⁸ Vehicle speed information is parameterized in intervals, as shown in Table 4.

Table 4.

Speed priority parameters.

Kilometers per hour	Less than 20	20 to 39	40 to 59	60 to 79	80 to 99	Greater than 100
Priority	6	5	4	3	2	1

Analysis of the priority parameters in information transfer for each vehicle based on speed shows that vehicles traveling at lower speeds receive higher priority for V2V communication and have longer dwell times in an LTE mobile network during V2I communication.

Location

According to Elazab et al.,²⁹ vehicles equipped with GPS use this information to calculate their location. The imprecision of GPS devices, however small, influences the results of routing protocols that use location information for decision-making. Vehicles sometimes receive information saying that they are on one track when they are actually on another, which has a considerable impact at the time of cluster formation and on routes in VANETs.

According to Rajesh and Gnanasekar,³⁰ the impact of positioning errors on VANETs has not been extensively explored. According to these authors, such errors increase the computational complexity of mobility protocols and models; in general, GPS errors have a direct influence on the calculations used to determine jumps between vehicles. Figure 4 shows that not all of the coverage area of an eNB is used for traffic.

Figure 4.

Coverage area of an eNB.

In this regard, when we break the coverage area of an eNB into sectors, we realize that cars travel on only one side in eNB-1; however, the cars continue to travel along only part of the highway in eNB-2. Furthermore, cars travel on both sides of the highway in eNB-3. Therefore, the hexagon shown in Figure 5 is broken into six sectors. Each vehicle will be assigned a priority identifier according to its location sector, which depends on the location of the vehicle relative to the eNB.

Figure 5.

Sectors from an eNB area.

Thus, the coverage area of an eNB is divided into six sectors based on vehicle traffic from left to right (one way) and according to the priority parameters shown in Table 5.

Table 5.

Location priority parameters by sector.

Location	Sectors 5 and 6	Sectors 1 and 4	Sectors 2 and 3
Priority	3	2	1

By analyzing the locations of vehicles by sector and assuming that all vehicles move at a constant speed, we can conclude that vehicles located in sectors 5 and 6 will take longer to leave an eNB coverage area; thus, they are in favorable locations at the time of the calculation of the GQI.

GQI calculation

To analyze the impacts of variations in cording angle, vehicle speed, and vehicle location parameters as a function of the eNB, the GQI is calculated. To define the parameters of the weights for the GQI calculation, we used benchmarking to understand how to manage the database under the variation of conditions in the vehicular network. Two main characteristics of database systems were used to analyze multimedia applications in the scenario of the summation. The first refers to a query based on the content of the recorded videos, and the second is about the data contained in the videos recorded as speed and location, since they are dependent on time, which results in the need to manage the synchronism. However, at the time of the event, the video being recorded is identified and separated from the others, and there are still other videos stored.

The values of benchmark study for each of the parameters are listed in Tables 6 –8. A total of 30 queries were defined in the benchmark that considered the processor and disk utilization rates. These queries were separated into groups according to the parameters used to calculate the GQI. After comparing the performance of several data queries in the scenario for 50, 100, and 150 vehicles, the weighted mean time of a video in 0.05023 of the velocity in 0.03165 and the location in 0.01812 was identified.

Table 6.

Benchmark study—video.

Parameters	50 vehicles	100 vehicles	150 vehicles
Query 1	0.00910	0.05400	0.08758
Query 2	0.00907	0.05398	0.08762
……	0.00911	0.05407	0.08756
Query 30	0.00909	0.05394	0.08761
Mean time video	0.05023

Table 7.

Benchmark study—speed.

Parameters	50 vehicles	100 vehicles	150 vehicles
Query 1	0.00533	0.03815	0.05147
Query 2	0.00539	0.03811	0.05142
……	0.00536	0.03818	0.05145
Query 30	0.00537	0.03817	0.05143
Mean time speed	0.03165

Table 8.

Benchmark study—location.

parameters	50 vehicles	100 vehicles	150 vehicles
Query 1	0.00387	0.01318	0.03735
Query 2	0.00381	0.01311	0.03739
……	0.00379	0.01322	0.03733
Query 30	0.00383	0.01325	0.03736
Mean time location	0.01812

The values for each of the parameters are listed in Table 9. These parameter values are based on the presented priorities, several tests performed in the simulation environment to obtain a weight for each parameter (video, speed, and location), and the main objective of this proposed method.

Table 9.

Weight of parameters.

Parameters	Video	Speed	Location
Weight	0.5	0.3	0.2

Assuming that $α$ , $β$ , and $γ$ , which represent the weight parameters for video, speed, and location, must be equal to 0.5, 0.3, and 0.2, respectively, because $α + β + γ = 1$ . The GQI can then be represented as shown in equation (1)

$GQI = α (P_{video}) + β (P_{speed}) + γ (P_{location})$ (1)

Here,

Video parameter ( $P_{video}$ or a) = (3, 2, 1)

↓ ↓ ↓

Positions along x 1 2 3

Speed parameters ( $P_{speed}$ or b) = (6, 5, 4, 3, 2, 1)

↓ ↓ ↓ ↓ ↓ ↓

Positions along y 1 2 3 4 5 6

Location parameters ( $P_{location}$ or c) = (3, 2, 1)

↓ ↓ ↓

Positions along z 1 2 3

Considering a system with three variables (a, b, and c), we can represent the solution by a linear system that assigns numbers to the variables and simultaneously satisfies all of the equations of the system, such as equation (2)

$GQI = α (\begin{matrix} a_{1} \\ a_{2} \\ a_{3} \end{matrix}) + β (\begin{matrix} b_{1} \\ b_{2} \\ b_{3} \\ b_{4} \\ b_{5} \\ b_{6} \end{matrix}) + γ (\begin{matrix} c_{1} \\ c_{2} \\ c_{3} \end{matrix})$ (2)

A system of vector equations with m linear equations and n unknowns can be represented in the general form as shown in equation (3)

$GQI = α \sum_{\overset{i = 1}{j = x}}^{3} a_{i} + β \sum_{\overset{i = 1}{j = y}}^{6} b_{i} + γ \sum_{\overset{i = 1}{j = z}}^{3} c_{i}$ (3)

To find the maximum and minimum possible values of the GQI, we apply the formula to two examples.

Maximum GQI: given $p_{video}$ = 3; $p_{speed}$ = 6; $p_{location}$ = 3, maximum GQI value is 3.9.

Minimum GQI: given $p_{video}$ = 1; $p_{speed}$ = 1; $p_{location}$ = 1, the minimum GQI value is 1.0.

After finding the maximum and minimum values of the GQI for each vehicle, we place the minimum value in a linear list to later build the routing table for each vehicle in the VANET cluster.

Performance evaluation

This section is divided into two parts. The first part illustrates the simulation scenario, the configured parameters, and the evaluation performance. In the second part, we provide the simulation results and compare the performance of the CRPV with that of other routing protocols used in VANETs.

Simulation scenario

The methodology used to assess and validate the CRPV is based on a discrete event simulator. Simulations are performed using the ns-3 network simulator.³¹ Because ns-3 does not support the generation of vehicular mobility models, we use the Simulation of Urban MObility (SUMO) software package.³² In addition, because ns-3 does not have the ability to send multimedia content, the EvalVid framework³³ is used to perform video broadcasts. From all of the network simulators we analyzed at the beginning of our research, we chose the EvalVid framework by considering that the ns simulator software is a widely used open-source network simulator that supports the IEEE 802.11p and LTE standards. The SUMO mobility simulator is chosen because it is an open-source software that can simulate actual vehicle displacements. This mobility simulator is also widely used in other papers that address vehicular networks. To properly run the analyses, we refine and finalize the source code used to produce the simulations by directly manipulating the ns-3 source files. The tools described are used together to prepare the simulations. Traffic safety situations have several applications for multimedia VANETs. In this context, we address an accident on a three-lane, one-way highway. In this situation, a video stream can provide public safety authorities (e.g. highway police) with more accurate information about the actual situation of the accident. The vehicles can also collaborate with each other to spread video data, illustrating the situation to other vehicles in the vicinity of the accident. Figure 6 represents the moment when some vehicles occupy a certain segment of the highway and an accident occurs.

Figure 6.

V2V communication scenario with vehicular fog: (a) time t1 and (b) time t2.

In Figure 6(a), v1, v9, and v3, which are equipped with dash cameras, notice the accident and begin recording it. In Figure 6(b), several vehicles have received the event video via V2V communications and want to broadcast it to the public safety officers; however, due to lack of LTE network coverage, transmission via V2I communication is not possible at that time. After some time, as shown in Figure 7, vehicles with LTE interfaces detect the signal from an eNB. At that moment, vehicles that have LTE interfaces, such as v1, v2, v3, v5, v7, and v9, and intend to stream the video to the public safety officers over the LTE interface begin the process of cluster formation to find the vehicle with the best GQI. This vehicle then becomes the CG that streams the video via V2I communications.

Figure 7.

V2I communication scenario with vehicular fog: (a) time t1 and (b) time t2.

By analyzing the situation shown in Figure 7(a), when V2I communication begins, the content is streamed by one of the CGs in the cluster over the LTE interface to eNB-1. Shortly thereafter, as shown in Figure 7(b), a federal highway police station receives the video of the accident via eNB-2. Based on this scenario and application, we have identified the problems involved in this type of streaming and present solutions using the CRPV.

If all vehicles with LTE interfaces attempt to stream the same content at the same time, system overhead results, and it cannot be guaranteed that the best video data are streamed. The vehicles travel at speeds of 10–110 km/h. The experiments are restricted to a 10-km travel distance. The vehicle density is adjusted for three simulation scenarios involving 50, 100, and 150 vehicles. Each vehicle generates 0.5-s beacon messages with packet sizes of up to 1024 bytes; the data rate can be as high as 6 Mb/s, and the streaming range is 500 m. These parameters have been suggested by several studies.³⁴ In addition, Nakagami radio propagation is used in the physical layer to calculate the characteristics of channel fading in wireless vehicle networks.³⁵ Many researchers recommend this model, given the conditions under which mobile communications occur in real-world environments.³⁶

A total of 30 simulations are performed; the execution time in each simulation is 500 s, and approximate 95% confidence intervals are employed. The simulations are performed to assess the performance of the CRPV using the IEEE 802.11p standard in multimedia VANETs. A hybrid architecture that incorporates 802.11p and LTE is used; we consider this architecture to most closely represent real conditions due to the coverage limitations of V2V communications. Because deploying RSUs on highways would have a high implementation cost, the available infrastructure provided by mobile operators is used. To enable V2V communications, LTE standard specifications are used for V2I communications.

After cluster formation, the CG that has the highest index of video will be the source of the flow, and the destination will be the CG that has the highest GQI. In Table 10, it is possible to verify that vehicle 12 has the highest index of video (15), and vehicle 1, despite having the highest GQI (3.4) among the vehicles of the cluster, does not have the LTE interface required for V2I communication. Vehicle 13 has the highest GQI (3.0) of the vehicles that have the LTE interface required for V2I communication and will be the destination in the video stream in the cluster in V2V communications.

Table 10.

Parameters used in the simulations.

Parameters	Scenario 1	Scenario 2	Scenario 3
Traffic	50 vehicles	100 vehicles	150 vehicles
Cluster formation	15 vehicles
Network simulator	ns-3
Mobility model	SUMO-MOVE
Travel distance	10 km
Lane direction	One way
Number of lanes	3
Speed of vehicles	10–110 km/h
Simulation time	500 s
Supported rate	Up to 6 Mbps
Physical and MAC layers	802.11p
Propagation model	Nakagami
Number of eNB	2
X2 interface	Yes
Physical and MAC layers	LTE
Frequency	OFDM
Streaming band	500 m
$α$ (video)	$p_{video}$
$β$ (speed)	$p_{speed}$
$γ$ (location)	$p_{location}$
Video sequence	Angle (lane 1, lane 2, lane 3)
Video encoding	MPEG-4
Format	720 × 480
Frame rate	24 fps
Picture groups	14
Number of video frames	300
Packets (1024 bytes)	353
Video source	CG with the highest $α$ (video)
Video destination	CG with the highest GQI

SUMO: Simulation Of Urban Mobility; LTE: long-term evolution; OFDM: orthogonal frequency-division multiplexing; CG: collaborative gateway; GQI: gateway quality indicator.

Three scenarios involving 50, 100, and 150 vehicles are used to analyze the scalability of the CRPV protocol and the quality of the streamed video data. The data from each scenario are shown in Figure 8(a)–(c), respectively, according to the cluster formation.

Figure 8.

Recording angles.

In this article, we use EvalVid to achieve results relevant to the streaming of video data over multimedia VANETs. The video streamed in the simulations is called (acidente_highway); it was downloaded from (source video sample). To form the cluster, the information shown in Table 11 is collected.

Table 11.

Characteristics of vehicles.

Vehicles	Dash Cam	LTE interface (4G)
v8, v9, v10, v11, v12, v13, and v15	Yes	Yes
v1, v4, v5, and v7	Yes	No
v2 and v6	No	Yes
v3 and v14	No	No

LTE: long-term evolution.

The identification of CG candidate vehicles begins when a cluster is formed after the occurrence of an event (accident) on the highway; the stored information is considered to calculate the GQI.

To maintain the consistency of the data stored in the tables, update packets are sent over the network. Each vehicle in the network cluster has a value; all vehicles can collaborate in V2V communications, but only vehicles with LTE interfaces can participate in V2I communications. As mentioned previously, all members of the cluster are CGs and can collaborate with each other so that the video data with better recording angles can be streamed by the CGs with LTE interfaces, and the entire process of selecting one of the CGs is based on the GQI values of the CGs.

Compared to other cluster-based protocols of producing routing tables, the CRPV has several advantages because it already considers all vehicles to be CGs. In contrast, other protocols necessarily forward the packets to a CH, which then directs the packets to a gateway that causes the packets to reach the destination node in some other cluster. The disadvantage of these CH-based protocols is that due to the mobility of the nodes, the CH may change constantly. This constant change causes delays in transfering packets. Considering the linkages between the vehicles shown in Figure 9, we illustrate the formation of the routing table for each vehicle in the cluster. Table 12 represents the information gathered from the vehicles, such as whether they have LTE interfaces and their recording angles, speeds, and locations.

Figure 9.

Scenario architecture with vehicular fog based on GQI values.

Table 12.

Information from vehicles in the cluster.

Vehicles	LTE	Video	Speed (km/h)	Location
v1	No	Right-side angle	<20	Sector 5
v2	Yes	No	>100	Sector 5
v3	No	No	20–39	Sector 5
v4	No	Left-side angle	80–99	Sector 5
v5	No	Left-side angle	40–59	Sector 5
v6	Yes	No	60–79	Sector 5
v7	No	Right-side angle	60–79	Sector 5
v8	Yes	Left-side angle	40–59	Sector 5
v9	Yes	Right-side angle	80–99	Sector 5
v10	Yes	Left-side angle	20–39	Sector 4
v11	Yes	Left-side angle	>100	Sector 4
v12	Yes	Center angle	80–99	Sector 4
v13	Yes	Right-side angle	<20	Sector 3
v14	No	No	40–59	Sector 3
v15	Yes	Left-side angle	60–79	Sector 3

LTE: long-term evolution.

After storing the relevant information using the CRPV algorithm, we calculate the GQI to classify each vehicle and later determine their routing tables. Table 13 shows the process of calculating the GQI.

Table 13.

GQI calculation.

Vehicle	LTE	Video	Speed	Location	GQI
v1	No	2 × 0.5 = 1.0	6 × 0.3 = 1.8	3 × 0.2 = 0.6	3.4
v2	Yes	0	1 × 0.3 = 0.3	3 × 0.2 = 0.6	0.9
v3	No	0	5 × 0.3 = 1.5	3 × 0.2 = 0.6	2.1
v4	No	1 × 0.5 = 0.5	2 × 0.3 = 0.6	3 × 0.2 = 0.6	1.7
v5	No	1 × 0.5 = 0.5	4 × 0.3 = 1.2	3 × 0.2 = 0.6	2.3
v6	Yes	0	3 × 0.3 = 0.9	3 × 0.2 = 0.6	1.5
v7	No	2 × 0.5 = 1.0	3 × 0.3 = 0.9	3 × 0.2 = 0.6	2.5
v8	Yes	1 × 0.5 = 0.5	4 × 0.3 = 1.2	3 × 0.2 = 0.6	2.3
v9	Yes	2 × 0.5 = 1.0	2 × 0.3 = 0.6	3 × 0.2 = 0.6	2.2
v10	Yes	1 × 0.5 = 0.5	5 × 0.3 = 1.5	2 × 0.2 = 0.4	2.4
v11	Yes	1 × 0.5 = 0.5	1 × 0.3 = 0.3	2 × 0.2 = 0.4	1.2
v12	Yes	3 × 0.5 = 1.5	2 × 0.3 = 0.6	2 × 0.2 = 0.4	2.5
v13	Yes	2 × 0.5 = 1.0	6 × 0.3 = 1.8	1 × 0.2 = 0.2	3.0
v14	No	0	4 × 0.3 = 1.2	1 × 0.2 = 0.2	1.4
v15	Yes	1 × 0.5 = 0.5	3 × 0.3 = 0.9	1 × 0.2 = 0.2	1.6

LTE: long-term evolution; GQI: gateway quality indicator.

After calculating the GQI for each vehicle in the cluster, we find that vehicle v13 has the best GQI value (3.0) of vehicles with an LTE interface. We present the routing table for each vehicle in the cluster in Table 14.

Table 14.

Routing table for each vehicle.

Vehicles	GQI	LTE	R1	R2	R3	R4	R5
v1	3.4	No	v7	v6	v2
v13	3.0	Yes	v12	v9	v15
v12	2.5	No	v13	v8	v9	v15	v11
v7	2.5	No	v1	v9
v10	2.4	No	v8	v5	v4	v11
v8	2.3	Yes	v12	v10	v5	v9	v6
v5	2.3	No	v10	v8	v2
v9	2.2	Yes	v13	v12	v7	v8	v6
v3	2.1	Yes	v4	v2
v4	1.7	Yes	v10	v3
v15	1.6	Yes	v13	v12	v14	v11
v6	1.5	Yes	v1	v8	v9	v2
v14	1.4	Yes	v15
v11	1.2	No	v12	v10	v15
v2	0.9	Yes	v1	v5	v3	v6

LTE: long-term evolution; GQI: gateway quality indicator.

The routes will be determined in descending order of the GQI values for each linkage between the vehicles involved. When two or more vehicles have the same GQI value, the values of the video, speed, and location parameters are considered in that order. Considering the parameters shown in Table 14, the architecture for the proposed scenario is shown in Figure 9.

In this architecture, we can find the linkages among the 15 vehicles in the cluster over a certain portion of the highway. The CRPV is a proactive protocol determined by a routing table. The protocol causes each node to keep one or more tables referring to the other vehicles in the cluster stored in memory.

Simulation results

The proposed routing protocol is assessed using several parameters. When the scenarios are modified, several situations are considered, such as the effects of density, video quality, speed, vehicle location, and the number of nodes in the cluster. We analyze the impacts and benefits of the CRPV regarding the dissemination of multimedia content in a cluster scenario along a highway. The evaluation metrics are used to measure the network QoS.

For the parameters in the simulations, there is a difference between vehicles and nodes; the nodes are vehicles that are the candidates of a cluster. The variation in the x-axis starts when vehicles that are close to an event become candidates for CG at the time of cluster formation. The first vehicle to record the event will be the first node to exchange short high-priority messages sent between vehicles to form the cluster. In Figure 10, considering that the traffic densities are low, the graphical analysis on the x-axis starts from five nodes in the cluster, exchanging information up to the limit of 50 predicted in the simulation.

Figure 10.

Delivery rate for the CRPV, SRB, and PassCAR protocols with 50 vehicles.

Traffic density analysis

The simulation results show an analysis of the traffic density that favors the CRPV when compared with other routing protocols designed for use in vehicular networks. In this simulation, the number of vehicles ranges from 50 to 150. The density was considered high when, in the region of the accident, 15 vehicles began the formation of a cluster. Figure 10 shows where the CRPV out performs the other protocols in terms of data delivery.

The simulation results show that the rate of data delivery decreases as the data traffic increases. The packet delivery rates shown in Figure 10 indicate that the CRPV performs poorly with 50 vehicles because the traffic density is low; however, it still displays better performance than the other protocols. The PassCAR protocol shows poor performance because of its mechanism for calculating the node degree and link lifetime, which considers only vehicles with stable characteristics. The SRB protocol displays better performance than the PassCAR protocol as the density increases because it considers the number of packets streamed due to its opportunistic choice of vehicle. The packets are retransmitted only by the selected vehicles to reduce the number of routers, thus preserving an acceptable QoS. When the traffic density is low, the end-to-end communication between the source node and the destination node is compromised. The CRPV displays improved performance even at relatively low traffic densities because it classifies each vehicle according to its GQI value, which is used in the routing table for each vehicle in the VANET cluster.

Figure 11 shows the packet delivery rate with 100 vehicles in the network. This chart shows a better trend for delivery than the previous one because as the number of vehicles in the network increases, the quality of the GQI improves. As the density increases, shorter paths become more common, thus improving packet delivery. With 100 vehicles, the performance of the CRPV remains superior than the SRB and PassCAR protocols simply because the CRPV finds shorter paths in the network using the routing tables of each vehicle in the cluster.

Figure 11.

Delivery rate for the CRPV, SRB, and PassCAR protocols with 100 vehicles.

The last graph, Figure 12, considers the 150-vehicle case. Again, the CRPV displays the best performance when compared with the other protocols. Its average delivery rate remains stable, even with a large amount of data, which could otherwise have compromised the network performance and caused packet loss, delays, and other congestion problems for content dissemination.

Figure 12.

Delivery rate for the CRPV, SRB, and PassCAR protocols with 150 vehicles.

Figure 13 shows the average packet loss rates associated with the CRPV, SRB and PassCAR routing protocols. The loss rate from the CRPV protocol is lower than the rates associated with the other protocols due to the smaller amounts of time required by the CRPV protocol to redirect traffic from one vehicle to another.

Figure 13.

Packet loss in the CRPV, SRB and PassCAR protocols.

Based on the tests performed here, the CRPV protocol detects vehicles entering and leaving the cluster more quickly than the PassCAR protocol or the SRB protocol, which require more time to determine when a vehicle’s linkage is broken or a new vehicle enters the cluster. The CRPV yields the best average delivery rate results for the three scenarios involving 50, 100, and 150 vehicles.

Average delay

Figure 14 shows the average delay obtained using the CRPV and compared with the other cluster-based routing protocols. The proposed routing protocol, which uses speed and location characteristics, yields a more stable V2V communication architecture by reducing the end-to-end delay. The PassCAR protocol shows considerable average delays due to the sending of messages during the route discovery process.

Figure 14.

Delay for the CRPV, SRB, and PassCAR protocols with 50 vehicles.

Figure 15 shows the average delay as a function of vehicle density based on an analysis of the performance of the CRPV and the other protocols. The average delay associated with the CRPV increases continuously due to the large number of vehicles available for cluster formation, which increases the complexity of the calculation of the GQI. The performance of the SRB protocol is superior to that of the PassCAR protocol, even given the computational complexity of route discovery, because the route is chosen opportunistically. This feature means that data are restreamed only by the selected vehicles, which does not compromise the performance of the SRB protocol strongly in this scenario.

Figure 15.

Delay for the CRPV, SRB, and PassCAR protocols with 100 vehicles.

The results associated with 150 vehicles are shown in Figure 16 and illustrate that the CRPV protocol continues to display the best performance due to the method it uses to form clusters. This method favors the CRPV protocol, as it incorporates a CG list with streaming priorities and streaming possibilities.

Figure 16.

Delay for the CRPV, SRB, and PassCAR protocols with 150 vehicles.

To better understand the performance of the CRPV, the PassCAR and SRB routing protocols are subjected to other tests. In these simulations, a user datagram protocol (UDP) data stream is generated among the 15 vehicles in the cluster at a rate of 2 Mbps with a 1024-byte packet size. The streaming lasts 60 s, and 10 repetitions of these simulations are performed in each case, with five updates in the cluster. Figure 17 shows the average delay of the protocols among the cluster members. The five peaks represent updates to cluster membership.

Figure 17.

Delay in clusters of the CRPV, SRB, and PassCAR protocols.

The results show that the PassCAR protocol and the SRB protocol underperform when compared with the CRPV in all replicates. When switching from one vehicle to another, the CRPV discovers the route in a shorter time after forming the clusters when compared with the other protocols.

Throughput

To measure the streaming throughput, a continuous UDP data stream is established between the VANET linkages. The CRPV protocol is used in V2V communications, thus allowing the packets to pass through some vehicles during streaming from the sender to the receiver. For each stream, two packet sizes (1024 and 2048 bytes) and a transfer rate of 2 Mbps are used. Figures 18 and 19 show the rates obtained in the scenarios with 50 and 150 vehicles.

Figure 18.

Throughput (50 vehicles).

Figure 19.

Throughput (150 vehicles).

The values obtained in the simulations indicate that larger numbers of vehicles result in an increased chance that the vehicles will keep the data transfer active. Larger packets yield greater flow variations. The use of 1024-bytes packets results in unstable flow.

Tests in the simulator initially evaluate the throughput and performance of the CRPV collaborative routing protocol. The data transfer among the 15 vehicles in the scenario 2 cluster is evaluated to identify the maximum throughput provided by the IEEE 802.11p protocol. A UDP data stream is established between the vehicles using 1024-byte packets. The vehicles remain separated from each other by a distance of 20 m, and their speeds and trajectories do not change. The results shown in Figure 20 are obtained using 10 replicates. The data traffic lasts a total of 60 s.

Figure 20.

Maximum rates obtained using the CRPV protocol in a cluster of 150 vehicles.

In the simulations, it is possible to obtain maximum streaming rates close to 2 Mbps. Lower rates are obtained early during streaming and stabilize approximately 5 s later. This improvement is explained by the greater sensitivity of higher rates of data transfer to the oscillations produced by the displacement of vehicles and external factors. A 2 Mbps rate is set for assessing the CRPV protocol using the 802.11p standard.

The metrics of QoS analyzed were those that we considered relevant for the performance of the proposed CRPV routing protocol for video streaming with fog computing in ad hoc vehicle networks. The objective metrics structural similarity (SSIM), video quality metric (VQM), and peak signal noise reduction (PSNR) were to measure the user’s QoE when watching the received content.

SSIM

SSIM was used to evaluate QoE. Other objectives metrics such as VQM and PSRN were omitted for two reasons. VQM showed similar behavior as SSIM, and PSNR delivers worse correlation with user perception when compared to SSIM and VQM.

PassCAR, SRB, and CRPV performed better by securing the QoE of the transmitted video. This behavior was identified in the three scenarios with 50, 100, and 150 vehicles. Figure 21 shows the performance evaluation comparing the three protocols when transmitting the video stream. In the scenario with 50 vehicles/km, the CRPV presented a performance of 0.82 according to the metric SSIM. The CRPV showed a gain of up to 13% over SRB and up to 18% over PassCAR. In addition, with 100 vehicles/km, the CRPV presented a performance of 0.92 according to the metric SSIM. The CRPV showed a gain of up to 15% over SRB and up to 21% over PassCAR. Finally, with 150 vehicles/km, the CRPV presented a performance of 0.97 according to the metric SSIM. The CRPV showed a gain of up to 21% over SRB and up to 27% over PassCAR. Only PassCAR and SRB obtained SSIM nearly 0.7, which is considered as poor quality when lesser.

Figure 21.

SSIM with 50, 100, and 150 vehicles of CRPV, SRB, and PassCAR.

PassCARs performance is low because of its mechanism, which considers only vehicles with stable characteristics for calculating the node degree and link lifetime. SRB performs better than PassCAR as the density increases because it considers the number of packet transmissions through an opportunistic choice of vehicle. Packets are retransmitted only by selected vehicles to reduce the number of routers.

Conclusion

This article presented a cluster-based method using fog storage and sharing with a collaborative routing protocol (CRPV) for forwarding multimedia packets over VANETs in a highway environment. This protocol uses a combination of V2V and V2I communications to improve its routing efficiency. CRPV considers recording angle, vehicle speed, and location which are important factors in cluster formation. The proposed routing protocol is analyzed in simulations and is compared with two existing routing protocols used in VANETs, that is, the PassCAR protocol and the SRB protocol. The results demonstrate that CRPV displays better performance in terms of packet delivery rate, average packet delay, and throughput. The results obtained in terms of objective QoE metrics such as SSIM, VQM, and PSNR were also compared. The results also demonstrate better CRPV performance by preserving user QoE. CRPV provides a realistic solution for road accidents in cases requiring the use of LTE network infrastructure.

Footnotes

Handling Editor: Razi Iqbal

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research,authorship,and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research,authorship,and/or publication of this article: This work was sponsored under grants of the Brazilian Coordination of Improvement of Higher Level Personnel (CAPES).

ORCID iDs

Paulo Bezerra

Denis Rosário

References

Barba

Mateos

Soto

et al . Smart city for VANETs using warning messages, traffic statistics and intelligent traffic lights. In: Proceedings of the intelligent vehicles symposium, Alcala de Henares, 3–7 June 2012, pp.902–907. New York: IEEE.

Rezende

Mammeri

Boukerche

et al . A receiver-based video dissemination solution for vehicular networks with content transmissions decoupled from relay node selection. Ad Hoc Netw 2014; 17: 1–17.

Lobato

Rosario

Gerla

et al . Platoon-based driving protocol based on game theory for multimedia transmission over VANET. In: Proceedings of the global communications conference, Singapore, 4–8 December 2017, pp.1–6. New York: IEEE.

Basudan

Lin

Sankaranarayanan

A privacy-preserving vehicular crowdsensing-based road surface condition monitoring system using fog computing. IEEE Internet Things J 2017; 4: 772–782.

Wang

Alexander

CA.

Big data analytics and cloud computing in Internet of things. Am J Inform Sci Comput Eng 2016; 2(6): 70–78.

Rosário

Schimuneck

Camargo

et al . Service migration from cloud to multi-tier fog nodes for multimedia dissemination with QoE support. Sensors 2018; 18(2): E329.

Hou

Chen

et al . Vehicular fog computing: a viewpoint of vehicles as the infrastructures. IEEE T Veh Technol 2016; 65(6): 3860–3873.

Kopetz

Poledna

In-vehicle real-time fog computing. In: Proceedings of the 46th annual international conference on dependable systems and networks workshop, Toulouse, 28 June–1 July 2016, pp.162–167. New York: IEEE.

Gerla

Pau

et al . Content distribution in VANETs. Veh Commun 2014; 1(1): 3–12.

10.

Iqbal

Butt

Shafique

et al . Context-aware data-driven intelligent framework for fog infrastructures in Internet of vehicles. IEEE Access 2018; 6: 58182–58194.

11.

Osanaiye

Chen

Yan

et al . From cloud to fog computing: a review and a conceptual live VM migration framework. IEEE Access 2017; 5: 8284–8300.

12.

Hosmani

Mathpati

. Survey on cluster based routing protocol in VANET. In: Proceedings of the international conference on electrical, electronics, communication, computer, and optimization techniques, Mysore, India, 15–16 December 2017, pp.1–6. New York: IEEE.

13.

Latif

Mahfooz

Jan

et al . A comparative study of scenario-driven multi-hop broadcast protocols for VANETs. Veh Commun 2018; 12: 88–109.

14.

Bagherlou

Ghaffari

A routing protocol for vehicular ad hoc networks using simulated annealing algorithm and neural networks. J Supercomput 2018; 74: 2528–2552.

15.

Qureshi

Abdullah

Bashir

et al . Cluster-based data dissemination, cluster head formation under sparse, and dense traffic conditions for vehicular ad hoc networks. Int J Commun Syst 2018; 31(8): e3533.

16.

Wang

Lin

YS.

PassCAR: a passive clustering aided routing protocol for vehicular ad hoc networks. Comput Commun 2013; 36(2): 170–179.

17.

Hashim

Shariff

Fadilah

. A new hop-count and node-degree based routing protocol for vehicular ad-hoc networks (VANETs). In: Proceedings of the 11th Malaysia international conference on communications, Kuala Lumpur, Malaysia, 26–28 November 2013, pp.310–315. New York: IEEE.

18.

Vegni

Natalizio

Forwarder smart selection protocol for limitation of broadcast storm problem. J Netw Comput Appl 2015; 47: 61–71.

19.

Gräfling

Mähönen

Riihijärvi

Performance evaluation of IEEE 1609 WAVE and IEEE 802.11p for vehicular communications. In: Proceedings of the second international conference on ubiquitous and future networks, Jeju, South Korea, 16–18 June 2010, pp.344–348. New York: IEEE.

20.

. An overview of the DSRC/WAVE technology. In: Proceedings of the international conference on heterogeneous networking for quality, reliability, security and robustness. Springer, 2010, pp.544–558, https://link.springer.com/chapter/10.1007/978-3-642-29222-4_38

21.

Rawat

Yan

Popescu

et al . Dynamic adaptation of joint transmission power and contention window in VANET. In: Proceedings of the 70th vehicular technology conference fall, Anchorage, AK, 20–23 September 2009, pp.1–5. New York: IEEE.

22.

Booysen

Zeadally

Van Rooyen

GJ.

Survey of media access control protocols for vehicular ad hoc networks. IET Commun 2011; 5(11): 1619–1631.

23.

Ziegler

Bender

Schreiber

et al . Making Bertha drive—an autonomous journey on a historic route. IEEE Intell Transp Syst Mag 2014; 6(2): 8–20.

24.

Sivaraman

Trivedi

MM.

Integrated lane and vehicle detection, localization, and tracking: a synergistic approach. IEEE T Intell Transp Syst 2013; 14(2): 906–917.

25.

Kakarla

Sathya

Laxmi

et al . A survey on routing protocols and its issues in VANET. Int J Comput Appl 2011; 28(4): 38–44.

26.

Bali

Kumar

Rodrigues

JJ.

Clustering in vehicular ad hoc networks: taxonomy, challenges and solutions. Veh Commun 2014; 1(3): 134–152.

27.

Karagiannis

Altintas

Ekici

et al . Vehicular networking: a survey and tutorial on requirements, architectures, challenges, standards and solutions. IEEE Commun Surv Tut 2011; 13(4): 584–616.

28.

Reyes Muñoz

Barrado Mux

Lopez

et al . Vehicle density in VANET applications. J Amb Intell Smart Environ 2013; 6(4): 469–481.

29.

Elazab

Noureldin

Hassanein

HS.

Integrated cooperative localization for vehicular networks with partial GPS access in urban canyons. Veh Commun 2017; 9: 242–253.

30.

Rajesh

Gnanasekar

Path observation based physical routing protocol for wireless ad hoc networks. Wirel Pers Commun 2017; 97(1): 1267–1289.

31.

Riley

Henderson

TR.

The ns-3 network simulator. In: Wehrle

Günes

Gross

(eds) Modeling and tools for network simulation. Berlin, Heidelberg: Springer, 2010, pp.15–34.

32.

Krajzewicz

Erdmann

Behrisch

et al . Recent development and applications of SUMO—Simulation Of Urban MObility. Int J Adv Syst Meas 2012; 5(3 & 4), http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.671.2113&rep=rep1&type=pdf

33.

Klaue

Rathke

Wolisz

. EvalVid—a framework for video transmission and quality evaluation. In: Proceedings of the international conference on modelling techniques and tools for computer performance evaluation. Springer, 2003, pp.255–272, https://link.springer.com/chapter/10.1007/978-3-540-45232-4_16

34.

Ghafoor

Lloret

Sadiq

et al . Improved geographical routing in vehicular ad hoc networks. Wirel Pers Commun 2015; 80(2): 785–804.

35.

Martinez

Fogue

Toh

et al . Computer simulations of VANETs using realistic city topologies. Wirel Pers Commun 2013; 69(2): 639–663.

36.

Viriyasitavat

Boban

Tsai

et al . Vehicular communications: survey and challenges of channel and propagation models. IEEE Veh Technol Mag 2015; 10(2): 55–66.

Vehicles	GQI	LTE	R1	R2	R3	R4	R5
v1	3.4	No	v7	v6	v2
v13	3.0	Yes	v12	v9	v15
v12	2.5	No	v13	v8	v9	v15	v11
v7	2.5	No	v1	v9
v10	2.4	No	v8	v5	v4	v11
v8	2.3	Yes	v12	v10	v5	v9	v6
v5	2.3	No	v10	v8	v2
v9	2.2	Yes	v13	v12	v7	v8	v6
v3	2.1	Yes	v4	v2
v4	1.7	Yes	v10	v3
v15	1.6	Yes	v13	v12	v14	v11
v6	1.5	Yes	v1	v8	v9	v2
v14	1.4	Yes	v15
v11	1.2	No	v12	v10	v15
v2	0.9	Yes	v1	v5	v3	v6

Vehicles	GQI	LTE	R1	R2	R3	R4	R5
v1	3.4	No	v7	v6	v2
v13	3.0	Yes	v12	v9	v15
v12	2.5	No	v13	v8	v9	v15	v11
v7	2.5	No	v1	v9
v10	2.4	No	v8	v5	v4	v11
v8	2.3	Yes	v12	v10	v5	v9	v6
v5	2.3	No	v10	v8	v2
v9	2.2	Yes	v13	v12	v7	v8	v6
v3	2.1	Yes	v4	v2
v4	1.7	Yes	v10	v3
v15	1.6	Yes	v13	v12	v14	v11
v6	1.5	Yes	v1	v8	v9	v2
v14	1.4	Yes	v15
v11	1.2	No	v12	v10	v15
v2	0.9	Yes	v1	v5	v3	v6

Vehicles	GQI	LTE	R1	R2	R3	R4	R5
v1	3.4	No	v7	v6	v2
v13	3.0	Yes	v12	v9	v15
v12	2.5	No	v13	v8	v9	v15	v11
v7	2.5	No	v1	v9
v10	2.4	No	v8	v5	v4	v11
v8	2.3	Yes	v12	v10	v5	v9	v6
v5	2.3	No	v10	v8	v2
v9	2.2	Yes	v13	v12	v7	v8	v6
v3	2.1	Yes	v4	v2
v4	1.7	Yes	v10	v3
v15	1.6	Yes	v13	v12	v14	v11
v6	1.5	Yes	v1	v8	v9	v2
v14	1.4	Yes	v15
v11	1.2	No	v12	v10	v15
v2	0.9	Yes	v1	v5	v3	v6