Predicting the Route of the Longest Lifetime and the Data Packet Delivery Time between Two Vehicles in VANET
Abstract
Among the most critical issues in VANET are the frequent failures of the route caused by the high mobility of vehicles, the increase of the network overload caused by control messages, and the increase of the data packet delivery time. Short communication route lifetime often breaks down during data packet transmission between the source and the destination vehicles, which results in a relaunch of a new route reconstruction that becomes more frequent and depletes a significant amount of network resources. To face these issues, much research has considered the route stability and the route lifetime determination between source and destination vehicles as important factors to improve the quality of service in the VANET network. However, this research did not take into account the route that has the longest lifetime as the most stable route and assumes that vehicles move at a constant speed during a direct communication between them. Furthermore, it did not model the data packet delivery time between the source and the destination vehicles. For this reason, we propose two protocols that use vehicles density to predict the data packet delivery time before sending the data and use vehicles movement information to determine the longest lifetime route, taking into account the variation of the vehicles velocity for comfort applications on highway. Our schemes are evaluated in function of vehicles density by measuring the average route lifetime, the percentage of packets delivery, the control overhead, the average end-to-end delay, the throughput, and the average number of route failures generated during the transmission of data packets.
1. Introduction
Vehicular ad hoc networks (VANETs) allow vehicles to communicate each other directly through the On Board Unit (OBU) device forming vehicle-to-vehicle communication, or with existing infrastructure via fixed equipment beside the road called Road Side Unit (RSU) forming vehicle-to-infrastructure communication [1, 2]; and they are a key component of intelligent transportation systems (ITS) [3]. VANETs support a wide range of safety applications to make accurate decisions by drivers and to help road traffic authorities for better control and mitigation of traffic congestion. Hence, the number of accidents on the roads will be reduced. Besides, they provide many nonsafety applications that supply the passengers with the capability to communicate with other passengers traveling in other vehicles, sharing multimedia content, playing online games, accessing the Internet, checking emails, etc. [4–6].
Unfortunately, intrinsic characteristics of the highly dynamic network topology cause several challenges to develop the previous applications. Among these challenges are the frequent breakages of links building the path between two vehicles because of their short lifetimes. This situation leads to a more frequent reconstruction of routes. Besides, the network fragmentation and the route rupture lead to an increase of the data packet delivery time between the source and the destination vehicles (packet wait time in queue). This issue results into a low data packet delivery ratio, an increase of end-to-end delay, an increase of control packets, and a depletion of a significant amount of network resources. To improve these metrics for achieving the sought quality of service, an efficient and reliable routing protocol is needed to provide the most stable routes for supporting the nonsafety applications exchange in VANETs.
Numerous protocols have been proposed in the literature to improve the communication efficiency between two communicating vehicles. These protocols try to find more stable routes by choosing vehicles that travel in the same direction [7], or by dividing the vehicles in groups [8], or by building stable backbones on road using connected dominating sets (CDS) [9], or by using an evolving graph from the source to the destination vehicles [10], or by dividing the moving vehicles to several clusters [11, 12]. All these protocols do not really determine the most stable route and their performance is still far from the sought level of quality of service. This research assumes that vehicles move at a constant speed during the link lifetime calculation between two vehicles in direct communication. In this case, link lifetime is not accurate due to the variation of the vehicles’ velocity during the route establishment. Hence, the accurate link lifetime is an important metric that significantly affects the stability of multihop routing protocols in VANETs. Furthermore, this research did not predict the packet delivery time which is also an important metric for decreasing the number of lost data packets and the network overload.
- (i)
To insure that the route which has the longest lifetime will be chosen during the route establishment; that is, our schemes determine the route that has the longest lifetime among all possible routes between the source and the destination vehicles during the route request.
- (ii)
To model the data packet delivery time between source and destination vehicles using a mathematical calculation. In other words, the source vehicle predicts the delivery time of the data packet to destination vehicle before sending data in order to know how many data packets to send before the route rupture.
- (iii)
To predict the link lifetime, taking into account the acceleration and deceleration of vehicles’ speed in a direct communication between two vehicles, namely, we consider the acceleration or deceleration of vehicles’ speed at the moment the calculation of the time in which two vehicles stay in direct communication.
The remainder of this paper is organized as follows: Section 2 presents related work. Section 3 presents link lifetime prediction model. Section 4 presents data packet delivery average time prediction model. Section 5 shows the most stable route construction. Section 6 presents simulation and results. Finally, we give a conclusion in Section 7.
2. Related Work
The challenges of network routing protocols in VANETs have been attracting more research efforts, and a number of routing protocols have been proposed to determine the route based on the route lifetime.
Menouar et al. [13] propose a movement-prediction-based routing (MOPR) to avoid the link rupture until the end of data transmission. MOPR predicts the future nodes’ positions in order to choose the most stable route that has enough lifetime for data transmission. The performance of the MOPR depends on the prediction accuracy and the estimation of the data transmission time that depends on various components such as network bandwidth and driver’s behavior.
To determine a more stable route, Taleb et al. [8] proposed the scheme ROMSGP that groups vehicles according to their movement directions. The most stable route is determined by selecting the path that has the longest link expiration time. The authors did not take into consideration the case where there are no vehicles traveling in the same direction of group movement.
Namboordiri and Gao [14] proposed a prediction-based routing (PBR) protocol that determines a stable route on highway giving priority to vehicles that travel in the same direction of source motion. This protocol predicts the route lifetime and preemptively determines new routes prior to old ones break. These authors assumed that vehicles travel at a constant velocity at the duration of the link.
Liu et al. [15] proposed a stable direction-based routing protocol (SDR) that combines direction broadcast and path duration prediction into AODV [16]. In SDR, vehicles are grouped based on the position, and the route selection is based on the link duration. The authors did not take into consideration the case where there are not enough vehicles in a given direction range participating in the route discovery process.
Eiza and Ni [10]proposed an evolving graph-reliable ad hoc on-demand distance vector (EG-RAODV) that allows finding the most reliable route from the source to the destination. They proposed an extended version of the evolving graph model to model and formalize the VANET communication graph (VoEG), and they developed a new evolving graph Dijkstras algorithm (EG-Dijkstra) to find the most reliable journey (MRJ) based on the journey reliability in VoEG. The problem of this protocol is that at each any given time, the source vehicle must have full knowledge of a VANET communication graph. Furthermore, the authors assumed that vehicles travel at a constant velocity along the same direction on the highway and they did not take into account the vehicles density.
In [17], authors proposed the scheme ARP-QD which is a QoS-based routing protocol in terms of hop count, link duration and connectivity so as to cope with dynamic topology and keep the balance between stability and efficiency of the algorithm. However, it is not enough to use only a global distance to reflect the overall QoS of a routing path.
Authors of [18] proposed an enhanced version of AODV protocol, named En-AODV, to deal with routes instability issues for multimedia applications requirements. En-AODV leverages cross-layer information on the link quality combined with the knowledge of the final destination of the receiver vehicle to establish the most stable path relaying the source and destination vehicles and quickly react to the occurrence of a link failure in this path and provide an alternative link of good quality. The authors did not take into consideration the case where there are no vehicles moving towards the destination region.
Authors in [12] proposed a new clustering-based reliable low-latency multipath routing scheme by employing Ant Colony Optimization technique to compute the optimal routes among the communicating vehicles in terms of reliability, end-to-end latency, throughput, and energy consumption. Although the scheme reduces the end-to-end latency and RREQ messages, it does not determine the most stable route and does not take into account the variation of velocity during a direct communication between vehicles.
Authors of [19] proposed a reliable routing protocol to establish a more reliable route between the source and the destination vehicles, known as AODV-R. They incorporate link reliability metric in the original AODV routing protocol. In this scheme, the source vehicle chooses the route based on the maximum reliability value among all received route reply messages. They assumed that vehicles will not change their velocities either by accelerating or decelerating during time period T. Also, this scheme does not determine the most stable route.
In [20], authors proposed a novel reactive routing protocol for vehicle-to-vehicle networks, named MA-DP-AODV-AHM. The latter is based on the AODV routing protocol in which the modifications made are related to the hello message and route discovery procedures, in order to establish reliable and stable routes from source to destination vehicles. In this scheme, the intermediate vehicle rebroadcasts the route request message if the speed is lower than a threshold and both forwarding and receiving vehicles are not diverging. Moreover, this scheme adapts the frequency of broadcasting the periodic “hello message” to suppress broadcasted unnecessary and redundant hello messages. Authors of this work did not take into consideration the case where there are not enough vehicles that respect the constraints (speed is lower than a threshold and vehicles are not diverging) of broadcasting the route request message. Besides, they have not determined the most stable route and have not taken into account the variation of velocity during a direct communication between vehicles.
The link lifetime of all these schemes is not accurate because these schemes assume that speed of vehicles is constant during the calculation of direct link lifetime between vehicles. Furthermore, they do not select the route that has the longest lifetime and do not take into account the data packet delivery time before sending data, except MOPR and ROMSGP. Besides, all these schemes do not model this data packet delivery time and did not take into consideration the case where there are no vehicles moving in the same direction or towards the destination, except MOPR, ARP-QD, and CRLLR. Therefore, the goal of this work is first to predict the route that has the longest lifetime whatever the direction of the vehicles on highway. And second, to model the data packet delivery average time for nonsafety applications.
Table 1 provides the comparison of the existing schemes in terms of accurate link lifetime, route lifetime, data packet delivery time, and participating vehicles during the build of route.
Scheme | Link lifetime: accurate or not accurate | The selected route has the longest lifetime: yes/no | Data packet delivery time | Participating vehicles | |
---|---|---|---|---|---|
Considered or not considered | Modeled or not modeled | ||||
MOPR [13] | Not calculated | No | Considered and not accurate | Not modeled | All vehicles |
ROMSGP [8] | Not accurate | No | Considered and not accurate | Not modeled | Just vehicles that travel in the same group |
PBR [14] | Not accurate | No | Not considered | Not modeled | Giving priority to vehicles that travel in the same direction |
SDR [15] | Not accurate | No | Not considered | Not modeled | Only vehicles that travel in the same direction |
EG-RAODV [10] | Not accurate | No | Not considered | Not modeled | All vehicles |
ARP-QD [17] | Not accurate | No | Not considered | Not modeled | All vehicles |
En-AODV [18] | Not accurate | No | Not considered | Not modeled | Only vehicles moving towards the destination region |
CRLLR [12] | Not accurate | No | Not considered | Not modeled | All vehicles |
AODV-R [19] | Not accurate | No | Not considered | Not modeled | All vehicles |
MA-DP-AODV-AHM [20] | Not calculated | No | Not considered | Not modeled | Vehicles that their speed is lower than a threshold and they are not diverging |
Our schemes | Accurate | Yes | Considered | Modeled | All vehicles |
3. Link Lifetime Prediction
Let (Xm, Ym), Vm, and Am are the position, the speed, and the acceleration of the vehicle m at moment t0, respectively. (Xn, Yn), Vn, and An are the position, the speed, and the acceleration of the vehicle n at time t0, respectively. (, ) and (, ) are positions of vehicles m and n at moment t1, respectively.
We assume that the acceleration of each vehicle is constant during a direct communication. The abscissa axis is parallel to the direction of movement of vehicles m and n to facility the calculation. The distance between vehicles m and n on the ordinate axis is negligible per report to the radius (R) of the coverage area of each vehicle (i.e., |Ym − Yn| ≈ 0).
3.1. Vehicles m and n Travel in Same Direction
- (i)
Si (Vm > Vn and Am > An) or (Vm < Vn and Am < An): the maximum time in which the vehicles m and n remain in direct communication is the time t in which the distance between these vehicles will be R (i.e., |d′| ≈ R). This time is represented by the following formula:
- (ii)
Si (Vm > Vn and Am < An) or (Vm < Vn and Am > An): in this case, there are two possibilities.
Remark: in the case where vehicles m and n travel in the negative direction of the x-axis, we change d – d′ by d′ – d and d′ – d″ by d″ – d′ in previous formulas.
3.2. Vehicles m and n Travel in Opposite Direction of Each Other
4. The Data Packet Delivery Time Prediction
To model the data packet delivery time, we, first of all, determine the number of vehicles on road. For determining this number of vehicles, each one broadcasts periodically a message of existence on the length of road; and each one receives a new message of existence and updates the number of vehicles on the road in its table which is called the vehicles density on the road (VDR). A vehicle waits two consecutive messages of existence intervals to hear from a vehicle. If no message was received, the vehicle number is decreased in VDR.
We consider the propagation time through a medium is constant between a forwarder and their neighbors whatever their positions in the forwarder’s coverage area. Because, the propagation speed is too great compared to the distance between a forwarder and their neighbors. Therefore, we consider the data packet delivery time to a neighbor i is constant, i.e., Ti = T ∀ i ∈ {1,2,3, …, n}, where n is the number of neighbors of the forwarder.
For example, if the forwarder is the first that will send a packet of data, then the waiting time is 0 s ((1 − 1) ∗T); and the wait time to be the last that will send a packet of data among n neighbors is n∗T ((n + 1 − 1) ∗T).
When the source vehicle has a data packet to send to the destination vehicle, it calculates the remaining time of route between itself and the destination vehicle. If this left time of route is less than the data packet delivery average time, the source vehicle launches a new route request; otherwise, it sends the data packet.
To verify the delivery time of the data packets of formula (19), we simulated (using NS2) the delivery time of the data packets between the source and the destination vehicles according to the density of the vehicles on highway of 5 km with 4 lanes in two opposite directions as shown in Figure 1. The speed of the vehicles varies between 0 km and 100 km. Our simulation does not take into account the waiting time of data packets in the queue at the source vehicles.

Figure 2 shows that the delivery time of the data packets of formula (19) and the simulated delivery time of the data packets are very close.

5. The Most Stable Route Construction
The network model consists of one road ended by two intersections in highway environment or in urban environment for road segments. This road has the same characteristics such as length, width, and number of lanes. Each lane has a distinctive traffic density (Figure 2). Each vehicle is equipped with a global positioning system (GPS) that provides information about its location, speed, and direction. Finally, each source vehicle knows the location of the destination by using a location service such as RLSMP [26] and ZGLS [27].
Given a directed graph G(V, E) that is defined by a finite set V = {v1, v2, v3, …, vn} of vertices, where vi is a vehicle and by finite set E = {t1, t2, t3, …, tm} of edges, where tj is the remaining time between any two vehicles to stay in direct communication with each other.
Whenever a vehicle receives a discovery message of route, it saves message’s identifier and the traveled route lifetime in a table, called Route Request Table (RRT).
We seek to determine the most stable route between the source and the destination vehicles. The route lifetime (RLT) is the minimum link lifetime (LLT) between links that build the route between source and destination vehicles. As in Figure 3, the most stable route is the one which is built by vehicles S-A-I-K-D, and the lifetime of this route is 4 s at instant t.

When the source vehicle wants to determine a new route between itself and the destination vehicle, it broadcasts a new route discovery message in the side close to destination of its communication range. Then, when the destination vehicle receives this route request message, it copies the route lifetime and the moment of calculation of this lifetime in the route reply. Next, it sends the latter to the source vehicle.
To determine this route, we propose two schemes: the first one uses beacon message and the other does not use it. These schemes are an extension of our work [28].
The idea of these schemes is that each vehicle can retransmit again the same route request message if it allows to the increase of the route lifetime.
5.1. Scheme without Beacon Message
Each source vehicle (s) knows the distance d(s, d) between itself and the destination vehicle (d) because each source vehicle knows the location of the destination vehicle by using a location service. We use this distance to determine the expiration parameter for the route request message so that it will not be rebroadcasted indefinitely on the entire network.
When the source vehicle wants to determine a new route to the destination vehicle, it adds its information (identifier, location, d(s, d), speed, direction, and RLT that is 0 s at the source vehicle) in the route request message (RRM) and broadcasts it in its communication range.
Each receiver vehicle (r), on the side close to destination vehicle of its communication range, calculates the link lifetime (LLT) and d(f, r) between itself and the previous forwarder vehicle (f). Then, it checks whether it is not the destination and d(r, d) (d(f, d)–d(f, r)) is less than or equal to zero meter. If it is, it deletes the RRM. Otherwise, it calculates the new RLT (which is the LLT if the previous forwarder is the source vehicle; otherwise, the new RLT is the minimum between the LLT and the RLT in the RRM). Next, it checks its RRT whether it has not already received the same RRM. If it has not, it saves the new RLT and RRM’s id in its RRT, and then it puts its information (id, location, d(r, d), speed, direction, and new RLT) in place of those of the previous forwarder vehicle in the RRM. Next, it broadcasts the latter in its communication range in the side close to the destination. Otherwise, it checks whether the new RLT is greater than the RLT in its RRT. If it is the case, it modifies the RLT in its RRT by the new RLT. Then, it puts its information instead of those of the previous forwarder vehicle in the RRM. Next, it broadcasts the latter in its communication range in the side close to the destination. Otherwise, it deletes it.
Each next receiving vehicle will do the same operations that have been done by the previous receiving vehicle until the route discovery message arrives to the destination or the distance between the source and the destination vehicles becomes less or equal to zero meters (Algorithm 1).
-
Algorithm 1: MSRP: most stable route prediction.
- (1)
Notations;
- (2)
SV: source vehicle; DV: destination vehicle; FV: forwarder vehicle;
- (3)
RV: Receiver Vehicle on the side close to the destination of the forwarder’s coverage area;
- (4)
RRM: Route Request Message;
- (5)
RRMID: RRM id;
- (6)
RRT: Route Request Table;
- (7)
LLT(FV, RV): Link LifeTime between forwarder vehicle and receiver vehicle;
- (8)
RLT: Route LifeTime;
- (9)
d(FV, RV): distance between forwarder vehicle and receiver vehicle;
- (10)
Information: id, location, speed, direction, RLT, d(FV, DV);
- (11)
R: communication range;
- (12)
Initialization;
- (13)
RLT = 0; d(FV, DV) = d(SV, DV);
- (14)
SV adds its information in RRM;
- (15)
SV broadcasts RRM;
- (16)
RV calculates LLT(FV, RV) and d(FV, RV);
- (17)
d(RV, DV) = d(FV, DV) − d(FV, RV);
- (18)
if d(RV, DV)≤0 andRV≠DV then
- (19)
RV deletes RRM;
- (20)
else
- (21)
if FV == SV then
- (22)
newRLT = LLT(FV, RV);
- (23)
else
- (24)
newRLT = min(LLT(FV, RV), RLT in RRM);
- (25)
end
- (26)
if RRMID is not in RRT of RV then
- (27)
RV saves newRLT and RRMID in its RRT;
- (28)
if RV == DV then
- (29)
DV replies by RRP;
- (30)
else
- (31)
RV modifies FV information in RRM by its information;
- (32)
RV broadcasts RRM;
- (33)
end
- (34)
else
- (35)
if newRLT≤RLT in RRT of RV then
- (36)
RV deletes RRM;
- (37)
else
- (38)
RV modifies RLT in its RRT by newRLT;
- (39)
if RV == DV then
- (40)
DV replies by RRP;
- (41)
else
- (42)
RV modifies FV information in RRM by its information;
- (43)
RV broadcasts RRM;
- (44)
end
- (45)
end
- (46)
end
- (47)
end
5.2. Scheme with Beacon Message
It is assumed that each vehicle periodically sends its information in beacon message (location, speed, direction of movement, identifier, and current time) to its neighbors. Then, each vehicle constructs its neighboring list by information extracted from beacon messages. Whenever a new neighbor is discovered, a new entry is added and a timer is set. A vehicle waits two consecutive beacon intervals to hear from its neighbor. If no message was received, the neighbors’ entry is deleted.
In this scheme, when the source vehicle wants to send a data packet to destination, it checks if the latter is among its neighbors. If it is, it send it the data packet. Otherwise, it adds its information (identifier, and RLT that is 0 s at the source vehicle) in the route request message (RRM) and broadcasts it in its communication range.
Then, each receiver vehicle (r), on the side close to destination vehicle of its communication range, calculates the LLT between itself and the previous forwarder vehicle (f). Then, it determines the new RLT (which is the LLT if the previous forwarder is the source vehicle; otherwise, the new RLT is the minimum between the LLT and the RLT in the RRM). Next, it checks its RRT whether it has not already received the same RRM. If it has not, it saves the new RLT and RRM’s id in its RRT and then it puts its information (identifier and new RLT) in place of those of the previous forwarder in the RRM. After that, it checks whether the destination vehicle is among its neighbors. If it is, it sends to it the RRM. Otherwise, it broadcasts the latter in its communication range on the side close to the destination. Otherwise, it checks whether the new RLT is not strictly greater than the RLT in its RRT. If it is not, it deletes it. Otherwise, it checks if there is a next receiver that remains (in direct communication with the current receiver) a time strictly greater than the RLT in its RRT. If this is not the case, it deletes the RRM. Otherwise, it modifies the RLT in its RRT by the new RLT. Then, it puts its information instead of those of the previous forwarder in the RRM. Next, it checks whether the destination is among its neighbors. If it is, it sends to it the RRM. Otherwise, it broadcasts the latter in its communication range on the side close to the destination.
Each next receiving vehicle will do the same operations that have been done by the previous receiving vehicle until the route discovery message arrives to the destination (Algorithm 2).
-
Algorithm 2: MSRP-BM: most stable route prediction using beacon message.
- (1)
Notations;
- (2)
SV: source vehicle; DV: destination vehicle; FV: forwarder vehicle;
- (3)
RV: Receiver Vehicle on the side close to destination of the communication range;
- (4)
NRV: Next RV on the side close to destination of the communication range;
- (5)
RRM: Route Request Message;
- (6)
RRMID: RRM id;
- (7)
RRT: Route Request Table;
- (8)
LLT(FV, RV): Link LifeTime between FV and RV;
- (9)
RLT: Route LifeTime;
- (10)
DPDT(SV, DV): The data packets delivery time between the SV and the DV;
- (11)
information: id, RLT;
- (12)
Initialization;
- (13)
RLT = 0; FV = SV;
- (14)
if DV is neighbor of SV and LLT(SV, DV)>DPDT(SV, DV) then
- (15)
SV sends DATA to DV;
- (16)
else
- (17)
SV adds its information in RRM;
- (18)
SV broadcasts RRM;
- (19)
RV calculates LLT(FV, RV);
- (20)
if FV == SV then
- (21)
new RLT = LLT(FV, RV);
- (22)
else
- (23)
new RLT = min(LLT(FV, RV), RLT in RRM);
- (24)
end
- (25)
if RRMID is not in RRT of RV then
- (26)
RV saves new RLT and RRMID in its table RRT;
- (27)
RV modifies FV information in RRM by its information;
- (28)
if DV is neighbor of RV then
- (29)
RV sends RRM to DV;
- (30)
else
- (31)
RV broadcasts RRM;
- (32)
end
- (33)
else
- (34)
if new RLT>RLT in RRT of RV and LLT(RV, NRV)>RLT in RRT of RV then
- (35)
RV modifies RLT in its RRT by new RLT;
- (36)
RV modifies FV information in RRM by its information;
- (37)
if DV is neighbor of RV and LLT(RV, DV)>RLT in RRT of RV then
- (38)
RV sends RRM to DV;
- (39)
else
- (40)
ifDV is neighbor of RV then
- (41)
RV deletes RRM;
- (42)
else
- (43)
RV broadcasts RRM;
- (44)
end
- (45)
end
- (46)
else
- (47)
RV deletes RRM;
- (48)
end
- (49)
end
- (50)
end
6. Simulation and Results
We have used the pattern IDM-LC which is a microscopic mobility model in the tool vehicular ad hoc networks mobility simulator (VanetMobiSim), and we have used NS2 to implement our protocols. Vehicles are deployed in a 5000 m × 80 m area. This area is a highway with four lanes bidirectional. Vehicles are able to communicate with each other using the IEEE 802.11p MAC layer. The vehicles’ speed fluctuates between 0 m/s and 27 m/s. We have considered packet size of 512 bytes, simulation time of 400 s, hello interval of 1 s, and packet rate of 4 packets per second. We setup ten multihop CBR flow vehicles over the network and start at different time instances and continue throughout the remaining time of the simulation. The transmission range is kept at 250 m. Simulation results are averaged over 20 simulation runs.
We evaluate the performance of our routing schemes MSRP-BM and MSRP against of ROMSGP which more closely resembles to the nature of our algorithms, and location-aided routing (LAR1) [29] that selects the shortest path. These schemes are evaluated for the average routes lifetime, the percentage of packets delivery, the control overhead, the average end-to-end delay, the throughput, and the average routes failures number generated during the transmission of data packets.
Simulation parameters are summarized in Table 2.
Parameter | Value |
---|---|
Simulation time | 400 s |
Simulation area | 5000 m × 80 m |
No. of vehicles | 30–90 |
Transmission range | 250 m |
Packet rate | 4 packets/s |
Packet size | 512 bytes |
Traffic type | CBR |
Mobility model | IDM-LC |
Speed | 0–100 km/h |
Figures 4 and 5 show the higher stability of MSRP and MSRP-BM compared to that of ROMSGP and LAR1 because our schemes determine the route that has the longest lifetime. Hence, it becomes more stable compared to others, where LAR1 gets the lowest route lifetime value. LAR1 chooses the shortest route that breaks quickly when the speed of vehicles and their number increase. ROMSGP chooses the shortest route among the vehicles belonging to the same group; for this reason, its route is stable compared to that of LAR1.


Figures 6 and 7 show the delay is maximal for a minimum number of vehicles, and it is linearly decreased with the increase of number of vehicles because of the reduction of the number of disconnections. The average end-to-end delay of our schemes is the lowest (notably when the vehicles number is increasing) compared to those of ROMSGP and LAR1 because of the stability of route that reduces the number of data packets in queue, and thus, the delivery delay of data packet between the source and the destination vehicles.


Figures 8 and 9 exhibit that the packet delivery ratio of all schemes increases with the increase of vehicles density on the road and that our schemes achieve a good packet delivery ratio than both ROMSGP and LAR1. This is because our schemes forward data packets on road by predicting the most stable route taking into account the velocity variation; on the contrary of ROMSGP that determines a stable route by selecting the shortest route among the vehicles belonging to the same group and LAR1 that selects the shortest path. The selection of the most stable route allows the decrease of the number of route breakage and the number of data packets in queue. The packet delivery ratio is not better because of the nonuniform distribution of vehicles in our mobility model. Moreover, we have not yet used a method which keeps the data until the destination vehicle, as in the case of the carry-and-forward mechanism [30].


In Figures 10 and 11, we consider all control packets used in the routing process, except beacon messages for our MSR-BM scheme. The control overheads of all routing protocols increase according to the increase of number of vehicles. LAR1 does not predict a stable route; hence, it generates more control overhead because of the frequent route reconstruction. ROMSGP determines a stable route by building the route by vehicles of the same group; hence, it provides less control overhead compared with LAR1. Our schemes predict the most stable route that decreases to a high extent the reconstruction of route; for this reason, they have much less control overhead than the other compared routing protocols.


In Figures 12 and 13, our schemes have better throughput than ROMSGP and LAR1. Because in MSRP and MSR-BM, the duration of the paths is longer, the number of path breaks is reduced, and also the control overhead is decreased compared with the other routing protocols. ROMSGP has the lowest throughput compared to LAR1. This is because ROMSGP determines the route by vehicles that travel in the same group (they are not enough) on the contrary of our schemes and LAR1 that do not take into account the direction of movement. When the number of vehicles increases, the ROMSGP throughput increases rapidly compared to that of LAR1. This is because ROMSGP has enough number of vehicles to select a stable route versus LAR1 that determines the shortest path.


As shown in Figures 14 and 15, the average number of route breaks (number of errors) of our protocols is lower than those of both ROMSGP and LAR1, because our schemes choose the most stable route and predict the data packet delivery time before sending data. LAR1 chooses the shortest path, regardless of whether it is reliable or not. ROMSGP outperforms LAR1 because it predicts a stable route by building it by vehicles belonging to the same group, and it creates a new alternative route before a route breakage.


As shown in Figures 16–19, according to the vehicles density, our scheme with beacon message (MSRP-BM) has the lowest packet delivery ratio and throughput. Besides, MSRP-BM has the highest normalized routing load and the highest average number of route failure compared to our scheme without beacon message (MSRP). This is explained by periodicity of beacon messages that charge the bandwidth.




7. Conclusion
Our schemes are designed to enhance the communication on highway for the comfort applications. They predict the most stable route by selecting the route that has the longest lifetime. They are based on the prediction of the link lifetime and the route lifetime taking into account the velocity variation. Moreover, our schemes predict the data packet delivery time before sending the data. They are compared to ROMSGP and LAR1 in highway environment. The results showed that our schemes have higher average route lifetime, higher percentage of packet delivery, higher throughput, lower average end-to-end delay, and lower average route failures number compared to existing schemes.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Open Research
Data Availability
No data were used to support this study.