RSU-Aided Optimal Member Replacement Scheme with Improved Mobility Prediction for Vehicular Clouds in VANETs

Abstract

The technique of vehicular clouds is considered an attractive approach in VANETs, because it provides a requester vehicle the ability to use resources of neighborhood vehicles (called cloud member vehicles) to construct a vehicular cloud to use next-generation vehicular applications during driving. Generally, member vehicles can move along different routes from the route of the requester vehicle in intersections and, as a result, leave the vehicular cloud. Then, the leaving member vehicle should be replaced by new member vehicles at intersections to reconstruct the vehicular cloud. However, identifying optimal replacement vehicles among many vehicles at intersections is a very difficult task involving minimizing the waste of resources of vehicles due to their irregular mobility. Thus, we propose an optimal member replacement scheme that finds optimal replacement vehicles through the improved mobility prediction of vehicles by borrowing the computational ability of RSUs on intersections. The proposed scheme first makes an improved mobility prediction model by combining both the trajectory prediction of vehicles using the Markov model and the location prediction of vehicles using the Gaussian distribution. Through the improved mobility prediction model, the proposed scheme then determines the leaving member vehicles and calculates their own leaving time. Next, the proposed scheme addresses the problem to find optimal replacement vehicles to minimize the waste resource and solves it through an integer linear programming. For the performance evaluation of the proposed scheme, we implement it in an NS-3 simulator, which includes the Manhattan mobility model, to reflect the mobility of vehicles on roads. Simulation results conducted in various environments verify that the proposed scheme achieves better performance than the existing scheme.

1. Introduction

Self-driving cars equipped with smart sensors and intelligent analysis tools can drive safely on their own trajectory with little or no human intervention. With the recent rapid development of self-driving cars, testing and deployment have been strengthened in a much shorter time than previously expected. Many companies, such as Tesla, Pony.ai, Waymo, Apple, Kia-Hyundai, Ford, Audi, Huawei, etc, are researching and developing autonomous vehicles with self-driving capabilities [1]. The autonomous vehicle is coming to reality with the effort of the companies. The autonomous vehicle makes it unnecessary for not only passengers but also drivers to focus on driving all the time when on the road. When full autonomation (i.e., level 5 [2]) becomes a reality, they will need to find new entertainment during driving time. Therefore, various and fresh applications are needed to meet these needs.

The advances in wireless networking technologies have innovated methods of entertainment (such as 5th generation (5G) cellular networks, Vehicular Ad-hoc NETworks (VANETs), etc). Soon, users will use the autonomous vehicle as a device for new entertainment in vehicular networks. However, due to the characteristics of vehicular networks (high speed, short communication range, dynamic topology, and limited storage and wireless resources), users may experience low-quality services from RSUs, such as long-term delays, buffering, and resolution reduction. There are many challenges to be solved to improve the quality of user experience (QoE) and reduce network backhaul traffic.

Many researchers have tried to solve this problem by using the vehicular cloud [3,4,5]. Since the vehicular cloud immediately receives resource sharing from neighboring vehicles, its delay is relatively very small compared with Internet clouds. In addition, because the vehicular cloud does not use resources of RSUs and cloud servers, network backhaul traffic can be reduced. However, member vehicles in a vehicular cloud might leave the vehicular cloud while providing a cloud service to a requester vehicle desired for resources according to the vehicle trajectory. Because the vehicular cloud is destroyed when the provision resources are less than the requested resources, it is essential to reconstruct the vehicular cloud by replacing the leaving member vehicle with new member vehicles. Since the different types of vehicular clouds have different performances, we have to consider the two types of vehicular clouds: (1) the V2V vehicular cloud and (2) the V2I vehicular cloud. First, the V2V vehicular cloud uses only vehicles to construct the vehicular cloud [3,6,7,8,9,10]. When the neighboring vehicles do not have enough resources to meet the requested demands, the requester vehicle, while driving, periodically broadcasts the request message to other neighbors until a new neighbor can provide the requested resources. When the vehicular cloud is reconstructed, the probability of finding optimal replacement vehicles is low in terms of the available resource of the candidate member vehicles and the connectivity between the requester vehicle and the candidate member vehicles because the requester vehicle with a short communication range has a small number of candidates that can be replaced. Additionally, the request messages that are periodically broadcast cause congestion of traffic in the vehicular network. In the case of the V2I vehicular cloud, the requester vehicle uses a cloud server or infrastructure such as RSUs as a member of a vehicular cloud [4,5,11,12,13,14]. In particular, RSUs have a wide range of communication and high computational capabilities [15]. If all requester vehicles want resources from an RSU, a bottleneck occurs and interferes with other services. In addition, if all requester vehicles use a cloud server, it causes a significant amount of network backhaul traffic. Fortunately, since the RSU has good capabilities, in order to find and replace the member vehicles that leave the vehicular cloud, we try to use only vehicles’ information within the communication range of the RSU and the computational capabilities of the RSU. Regarding the selection of a replacement member vehicle, because the two types of the vehicular cloud predict vehicles’ connectivity based on simple movement information (such as position and speed) of the current vehicles, the prediction accuracy of the connectivity between vehicles is very low. Accordingly, the connectivity may also be very low at the time that the vehicular cloud members are replaced [3]. As a result, while another replacement member vehicle is being researched due to the prediction failure, the requester vehicle cannot receive a cloud service, resulting in an increase in delay. In addition, by continuously finding additional replacement member vehicles, computational resources and traffic of the RSU are continuously consumed.

To solve this problem, we propose an RSU-aided optimal member replacement scheme based on the improved mobility prediction of vehicles for vehicular clouds in VANETs. First, the proposed scheme provides improved mobility prediction to enhance the accuracy of the connectivity prediction between vehicles in a vehicular cloud. The connectivity prediction accuracy is improved by appropriately predicting the leaving member vehicles and the optimal replacement member vehicles through considering both the mobility prediction based on Gaussian probability and the trajectory prediction based on a Markov model. Next, the proposed scheme addresses the problem to identify optimal replacement member vehicles to minimize the wasted resources of vehicles. The wasted resources are formulated based on the ratio of the size of the requested resource and the available resources of the vehicles that are selected as optimal replacement member vehicles in the restricted environment for the fairness of the wireless resources and energies. Then, the problem is solved through an integer linear programming (ILP) in order to minimize the wasted resource, which excludes the resource that is allocated as each replacement member vehicle from its whole resource. To evaluate the performance of the proposed scheme, we compare it with one of the latest schemes, called SERVitES [3]. Simulation results conducted in various environments demonstrate that the proposed scheme achieves better performance than SERVitES in terms of the wasted resource and the number of the cloud reconstruction.

The remainder of the paper is organized as follows. Section 2 examines the related works of this paper. Section 3 describes the network model of this paper. Then, we describe the proposed scheme in detail in Section 4. Simulation results are provided in Section 5 to evaluate the performance of the proposed scheme. Section 6 concludes the paper.

2. Related Works

Generally, the vehicular cloud is mainly categorized into V2I clouds and V2V clouds. In the V2I cloud schemes, the requester vehicle can construct a vehicular cloud with strong infrastructure support to reduce delay and improve cloud service stability. Many studies consider using roadside units (RSUs) which are deployed in urban scenarios to connect the requester vehicle and the Internet. Additionally, these RSUs have wide communication ranges and maintain connections with many requester vehicles [5,11,16,17,18,19]. In [11], the authors proposed a novel scheme that exploits the presence of RSUs to act as cloud directories that store information about mobile cloud servers called STARs. For each STAR, an RSU will store for the type of resources it offers, the attributes of each resource, and the required price per resource unit. Through this system, service discovery and service consuming delays are reduced, and the packet success ratio is improved. In [5] the author proposed a semi-Markov decision process (SMDP) model for vehicular cloud computing (VCC) resource allocation. It finds the optimal strategy of VCC resource allocation. The two additional features elaborate on the SMDP model and demonstrate different results from the original model. Its resource pool includes the RSUs provided by RSUs and the amount of RSUs of multiple vehicle types. Additionally, it considers different Poisson distributions for heterogeneous vehicle types. In [17], the authors proposed a mechanism of infotainment data distribution for vehicular networks using the RSU cloud. The system model and algorithms are suggested for vehicles, the RSU cloud, and the data center. The RSU cloud has the ability of cloud computing to solve the limitation of the traditional RSU for the efficiency of distributed infotainment messages. It can reduce the delay and throughput of vehicle communication through the RSU cloud and distribute infotainment messages. In [18], the authors proposed a vehicular cloud scenario where resources are allocated dynamically. They employed a vehicular cloud network using a roadside unit as the fixed coordinator and developed three resource allocation algorithms that aim to partially prioritize service cars, prioritize local cars, and reserve bandwidth for partially serviced cars. To allocate available resources dynamically, they consider a maximum portion of resources among all the competing vehicles and analyze the trade-off between serving a maximum number of vehicles or providing maximum quality of service.

These V2I cloud schemes have several advantages, infinite resources, stable Internet connection, and low delay. However, these schemes have constraints. The infrastructure is essential to connect to the Internet, the limited communication range of RSU, and the high cost of using cellular networks. To overcome these V2I cloud constraints, the V2V cloud schemes are proposed. In the V2V cloud schemes, vehicles search and allocate resources to each other through the information about their neighbor vehicles. The requester vehicle, which needs resources to construct its cloud for cloud service, sends a resource request to its neighbor vehicle. Neighbor vehicles cooperate to process the request and resource search. After searching for the requested resource, neighbor vehicles work together to allocate the resource to the requester vehicle. These schemes are performed among vehicles without any infrastructure [3,6,7,8,9,10]. In [6], the authors proposed a connectivity-aware service provision scheme where the service provider vehicle is selected based on several parameters such as the availability of the requested service and the mobility of the vehicles. It uses broadcasting to allow all neighbors to participate in the multi-hop resource search process to find many vehicles with enough resources. In [7], the authors proposed a peer-to-peer protocol for the search and management of resources and services in the vehicular mobile cloud without depending on any external infrastructure called SMART. SMART selects the farthest neighbor vehicle from the resource search vehicle as an intermediate search vehicle called a controller and thus performs the multi-hop resource search process to larger regions by the controller. In [8], the authors proposed a new protocol for managing resources available in the vehicles within the cloud that promotes cooperation and collaboration among vehicles. It considers the one-hop connection time and selects the neighbor vehicle with the longest one-hop connection time as an intermediate search vehicle called a superpeer. It improves the availability of resources to the vehicle, increasing the amount of resources that can be consumed in the vehicle cloud. In [3], the authors proposed a protocol to assist in the search and management of resources in a vehicular cloud without depending on the support of roadside infrastructure. The vehicles have idle resources that can be made available to other vehicles by generating a moving cloud formed by a set of vehicles. To create this mobile cloud, they use clustering techniques to form efficient groups of vehicles. The cluster moves dynamically on the road, and vehicles can leave or join the cluster according to their proximity and speed. In [10], the authors’ proposed protocol uses a multi-hop connection time-based intermediate vehicle selection scheme to perform a multi-hop resource search and find vehicles with enough resources for a multi-hop vehicular cloud. To raise the vehicular cloud service availability, the proposed protocol allocates resources of vehicles based on the number of their neighbor vehicles and cloud service time for constructing a multi-hop vehicular cloud.

These V2V cloud schemes have large scalability because they only communicate with each other and do not need any special nodes, such as RSUs, on roads. Thus, the requester vehicle can use cloud service while it is traveling to its destination. However, these schemes have several problems. First, vehicles have various mobility. This causes frequent topology changes. Second, the vehicular cloud is constructed over the multi-hop communication range. It causes weak connections among vehicles. Third, each vehicle has limited resources. For these reasons, the vehicular cloud construction is more complex, and it is repeatedly destroyed in urban scenarios, including those with many intersections. As a result, this reduces the cloud service stability.

As examined before, most studies are only focused on the vehicular cloud construction, and they restart the whole process of the vehicular cloud construction when the vehicular cloud is destroyed due to member vehicles leaving. Thus, if there are candidate vehicles to replace the leaving member vehicles, the vehicular cloud can be reconstructed rapidly. As one of the optimized vehicular cloud reconstruction methods, we only exploit the computing capability of RSUs, which have a large communication range, to overcome the limited small communication range of vehicles at a low communication cost. In this condition, the contributions of this paper are as follows.

• To enhance the prediction accuracy of the connection time between vehicles in a vehicular cloud, we propose an improved mobility prediction based on Gaussian distribution considering the locations of vehicles after some time. Using the improved mobility prediction, we appropriately estimate the leaving member vehicles and the optimal replacement member vehicles by calculating the probability of the connection of vehicles in one direction.
• Furthermore, using Markov model, this probability of the connection of vehicles based on the improved prediction can be applied to multiple directions to reflect intersections on the roads. By enhancing prediction accuracy, the proposed scheme can reduce the number of vehicular cloud reconstructions needed and as a result, reduce the delay and traffic that are consumed for the reconstruction of the vehicular cloud.
• Based on this connection probability, we formulate the wasted resources to maximize the network-wide available resources for the other vehicular clouds by minimizing the wasted resources through optimization. We formulate the wasted resources as the value of consideration for the ratio of the requested resources and available resources for optimal replacement of member vehicles of a vehicular cloud in the restricted environment for the fairness of wireless resources and energy.
• Then, to optimize the wasted resource to select the replacement vehicles with stable connectivity, we solve the problem using ILP. By determining optimal replacement member vehicles, the reliability and the service availability for vehicular cloud reconstruction are improved.
• For the performance evaluation, we implement the simulation using NS3 with the enhanced Manhattan mobility model such that vehicles accelerate with the Gaussian distribution and directionally shift with the Markov Model on the road. Simulation results are conducted in various environments to compare the performance of the proposed scheme with SERVitES in terms of the wasted resource and the number of the cloud reconstruction.

3. Network Model and Scheme Overview

In this section, we present the network model of the proposed scheme for a vehicular network and its overview. As the network model, we consider that a number of vehicles move on roads according to their own traveling routes toward their own destinations. There are intersections on the roads, and as a result each vehicle will pass multiple intersections until it arrives at its destination. We assume that each intersection has an RSU to provide Internet connections to vehicles within its communication coverage, as many studies [15,20] have mentioned similarly. When every vehicle enters within the communication coverage of an RSU, it sends a beacon message with its ID, location, mobility, and resource information to the RSU periodically. In particular, the mobility information of a vehicle includes its speed and the probability of its traveling route, and the resource information of the vehicle includes its resource type and its available amount.

In the situation of the network model, when a vehicle wants to use a vehicular application requiring a large amount of resource, it constructs a vehicular cloud for supporting the application. In this paper, we call a vehicle that intends to construct a vehicular cloud a requester vehicle. To construct a vehicular cloud, a requester vehicle sends a request message with the information of the requested resource amount and a request time to borrow the resources necessary for the vehicular cloud to its neighborhood vehicles. On receiving the request message, every neighborhood vehicle sends a reply message with its ID, location, mobility, and resource information to the requester vehicle. Based on the information in all of the reply messages from neighborhood vehicles, the requester vehicle selects member vehicles among them for the vehicular cloud. As in the previous papers [3,4,10], in the proposed scheme, the member vehicles are determined to meet the conditions for constructing the vehicular cloud, including that both the expected connection time between the requester vehicle and each member vehicle is longer than the request time and the total summation of the resource from all member vehicles is larger than the requested resource amount. Then, the requester vehicle stores the information of each member vehicle in each entry of a member vehicle table for the vehicular cloud. To know the member vehicle selection, the requester vehicle sends a selection message to each of the member vehicles. Upon receiving the section message, every member vehicle recognizes itself as a member vehicle for the vehicular cloud and uses the resource for operating the vehicular cloud. By this process, if the vehicular cloud is constructed, the requester vehicle periodically asks for and receives a beacon message from all of the member vehicles to maintain the vehicular cloud until the vehicular cloud is finished completely.

While using the vehicle cloud, the requester vehicle might move along a road with its member vehicles together. Usually, they pass several intersections until they arrive at their own destinations. When the requester vehicle with its member vehicles approaches an intersection, they might move along different roads from the intersection according to their own traveling routes. As a result, some of the member vehicles could leave the vehicular cloud because their traveling routes might be different from that of the requester vehicle. Accordingly, the vehicular cloud for the requester vehicle is destroyed due to the leaving member vehicles at the intersection, because it can no longer use resources provided by them for the vehicular cloud. Thus, in an intersection, the vehicular cloud that includes the requester vehicle needs to replace the leaving member vehicles with the replacement vehicles that are selected by the RSU. The replace member vehicles will be selected from vehicles that move along the same traveling route as that of the requester vehicle from the intersection.

With regard to the member vehicle replacement, one of the most challenging issues is to find optimal replacement vehicles to replace the leaving member vehicles. To select the optimal replacement vehicles, the vehicular cloud sends the request message when it enters the communication range of the RSU, as shown in Figure 1a. Since the RSU has information about all the vehicles within a longer communication range than the vehicle, it has more candidate vehicles to select the optimal replacement vehicles. To maximize the stability of the cloud service from a vehicular cloud, replacement vehicles should have enough resources for the vehicular cloud to prevent its destruction due to a lack of resources. Then, we focus on the resource of vehicles for the optimization, because the resources of vehicles are the most important and necessary key factor to construct vehicular clouds. The waste of resources significantly affects the construction and the reconstruction of vehicular clouds. Thus, the proposed scheme achieves the minimization of wasted resources when determining optimal replacement vehicles to replace the leaving member vehicles. To decide on optimal replacement vehicles to achieve the minimization of the wasted resource, the proposed scheme exploits the resource and mobility information of vehicles. After the RSU selects the optimal replacement vehicle, it sends a selection message to each selected replacement vehicle, which includes the replacement time and information about the requester vehicle, and the replacement vehicles with the included information send a join message to the requester vehicle to join the vehicular cloud at the replacement time as shown in Figure 1b. In the next Section 4, we describe the proposed scheme to select optimal replacement vehicles based on the resource and mobility information of vehicles under our network model in detail.

Table 1. Notations used in the proposed scheme.

Notation	Description
$t_n$	n-th time slot
$\mathsf{\Delta }T$	one time slot
$\mathsf{\Delta }t$	unit time
m	the number of unit time
$v_x^{\left(k\right)}$	x-axis velocity at the k-th unit step between $t_{n-1}$ and $t_n$
$x^{\left(k\right)}$	x-axis location at the k-th unit step between $t_{n-1}$ and $t_n$
${\epsilon }_x^{\left(k\right)}$	x-axis acceleration at the k-th unit step between $t_{n-1}$ and $t_n$
${\mu }_x$	the mean of the x-axis location at $t_n$
${\sigma }_x$	the standard deviation of the x-axis location at $t_n$
${\mu }_d(\alpha ,\beta )$	the mean of the distance between $\alpha$ and $\beta$ at $t_n$
${\sigma }_d(\alpha ,\beta )$	the standard deviation of the distance between $\alpha$ and $\beta$ at $t_n$
$P{r}_{conn}^{[\alpha ,\beta ]}\left(t_n\right)$	the probability of connection between $\alpha$ and $\beta$ at $t_n$
$Pr\left[{\alpha }_n^s\left((x_n,y_n)\right)\right]$	the probability of the vehicle $\alpha$ reaching $(x_n,y_n)$ at $t_n$
${\theta }_{th}$	the threshold value of determining that two nodes are connected
$R_{need}^{req}\left(t\right)$	the expected needed resources of the vehicular cloud due to the leaving member vehicles
$R_{avail}^j$	the available resource of the j-th member vehicle
$R_{req}$	the requested resource by the requester vehicle $req$
$r_{wasted}^{req}\left(t\right)$	the percentage of the wasted resources at time t
${\xi }^{req,l}\left(t\right)$	determinant value whether the vehicle l is selected as a replacement vehicle for $req$ at t
$T_{service}^{req}$	valid time of the cloud service that is requested by $req$
${\eta }_{rel}$	weight value to focus on the stability of the cloud service
${\eta }_{wasted}$	weight value to focus on minimizing the wasted resource

shows notations used for the proposed scheme in this paper.

4. The Optimized Cloud Member Replacement Scheme

This section describes an optimized cloud member replacement scheme for determining new member vehicles to replace the leaving member vehicles in order to maximize the stability of cloud services and to minimize the wasted resources. A vehicle demands resources from neighboring vehicles that cannot be solved by itself and becomes a requester vehicle. Neighboring vehicles provide information about their available resources. The available resource information that is received from the neighbor is used to determine whether the requested resource is satisfied. If the sum of available resources of neighboring vehicles is less than the requested resources, the vehicular cloud service cannot be executed, so the requester vehicle continuously requests resources from other neighboring vehicles while moving. If the sum of available resources of neighboring vehicles is bigger than the requested resources, the requester vehicle selects neighboring vehicles to be used as vehicular cloud members according to the requested resources. A neighboring vehicle that is selected as a vehicular cloud member continuously sends the mobility information to the requester vehicle through a beacon message in order to maintain connectivity. When the requester vehicle enters the RSU’s communication range, it provides the information regarding the vehicular cloud members to the RSU. To maintain the cloud service of the requester vehicle, the RSU selects the optimal replacement vehicles and replaces the leaving member vehicle among the vehicular cloud members in terms of maximizing the stability of the cloud service and saving the wasted resources. To do this, we first formulate the connection probability between vehicles after the time t in Section 4.1. Because the RSU is deployed at each intersection, the connection probability between vehicles after time t is redefined in Section 4.2 using the Markov model and considering the trajectory probability of the vehicle at each intersection. In Section 4.3, we formulate the wasted resources using the connection probability based on resources that are insufficient due to the leaving member vehicles among the vehicular cloud members and resources that are replaced by the replacement candidate vehicles. In Section 4.4, we solve the optimization problem using ILP to maximize the cloud service stability and to minimize the wasted resources.

4.1. Probability of the Connection in One Direction

This section describes the probability of connecting the two vehicles according to $t_n$ on a one-direction road, as shown in Figure 2. In order to calculate the connection probability between vehicles after time $t_n$, the location probability of vehicles at time $t_n$ must first be calculated. Let $\mathsf{\Delta }t$ be the unit step time between time $t_{n-1}$ and time $t_n$, $\mathsf{\Delta }T=t_n-t_{n-1}=m\mathsf{\Delta }t$, and m denote the number of unit time. The speed of the vehicle is legally limited, and the acceleration of the autonomous vehicle is limited to [−5, 5] $\mathrm{m}/{\mathrm{s}}^2$ for user convenience [21,22]. The velocity of vehicles is assumed to follow a random distribution at time $t_n$. Therefore, within the limit not exceeding the speed limit, the velocity can be regarded as a uniform motion, and the acceleration can be regarded as a series of white Gaussian noise with a constant variance $\epsilon$ during unit time $\mathsf{\Delta }t$ [23]. For vehicle i at the k-th unit step between time $t_{n-1}$ and time $t_n$, the x-axis velocity component is denoted by $v_x^{\left(k\right)}$, and the x-axis location component is denoted by $x^{\left(k\right)}$:

$$\begin{array}{cc}\hfill v_x^{\left(k\right)}& =v_x^{\left(0\right)}+\sum _{i=1}^k{\epsilon }_x^{\left(i\right)}\mathsf{\Delta }t,\hfill \end{array}$$

(1)

$$\begin{array}{cc}\hfill x^{\left(k\right)}& =x^{\left(0\right)}+k\mathsf{\Delta }t{v}_x^{\left(k\right)}+\frac{1}{2}\sum _{i=1}^k(2k-2i+1){\epsilon }_x^{\left(i\right)}\mathsf{\Delta }{t}^2,\hfill \end{array}$$

(2)

where ${\epsilon }_x^{\left(k\right)}$ is the acceleration component in [24]. The arguments of Gaussian distribution at $t_n$ are achieved as:

$$\begin{array}{cc}\hfill {\mu }_x& =x_{n-1}+v_{(n-1)}^{x}m\mathsf{\Delta }t,\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill {\sigma }_x^2& =\frac{(4m^3-m)\xi \mathsf{\Delta }{t}^4}{12},\hfill \end{array}$$

(4)

where $(x_{n-1},y_{n-1})$ denotes the location at time $t_{n-1}$. The expressions of the y-axis and z-axis are similar to the results of the x-axis. Thus, based on the location $(x_{n-1},y_{n-1})$ at time $t_{n-1}$, the probability density function to arrive at $(x_n,y_n)$ is achieved as:

$$\begin{array}{c}\hfill p\left\{(x_n,y_n)\right|(x_{n-1},y_{n-1})\}=\frac{1}{2\pi {\sigma }^2}{exp}^{\left(-\frac{1}{2{\sigma }^2}\left[{(x_n-{\mu }_x)}^2+{(y_n-{\mu }_y)}^2\right]\right)}.\end{array}$$

(5)

Using this probability, the arguments of Gaussian distribution at time $t_{n-1}$ can be redefined in terms of the distance between vehicle $\alpha$ and vehicle $\beta$, as follows:

$$\begin{array}{cc}\hfill {\mu }_d(\alpha ,\beta )=& {\left({\mu }_x^{\alpha }-{\mu }_x^{\beta }\right)}^2+{\left({\mu }_y^{\alpha }-{\mu }_y^{\beta }\right)}^2,\hfill \end{array}$$

(6)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill {\sigma }_d^2(\alpha ,\beta )=& \frac{\mathsf{\Delta }{t}^4}{4}\times E\left[\sum _{i=1}^m{(2i-1)}^4\left({({\epsilon }_{\alpha ,x}^{\left(k\right)2}-{\epsilon }_{\beta ,x}^{\left(k\right)2})}^2+{({\epsilon }_{\alpha ,y}^{\left(k\right)2}-{\epsilon }_{\beta ,y}^{\left(k\right)2})}^2\right)\right],\hfill \end{array}\end{array}$$

(7)

where the arguments of Gaussian distribution of vehicle $\alpha$ are ${\mu }_x^{\alpha },{\mu }_y^{\alpha },{\epsilon }_{\alpha ,x}^{\left(k\right)},{\epsilon }_{\alpha ,y}^{\left(k\right)}$, and the arguments of Gaussian distribution of vehicle $\beta$ are ${\mu }_x^{\beta },{\mu }_y^{\beta },{\epsilon }_{\beta ,x}^{\left(k\right)},and{\epsilon }_{\beta ,y}^{\left(k\right)}$. Therefore, based on the distance $d_{n-1}$ between vehicle $\alpha$ and vehicle $\beta$ at time $t_{n-1}$, the probability density function to reach $d_{\gamma }$ is achieved as:

$$\begin{array}{c}\hfill p\{d_n(\alpha ,\beta )=d_{\gamma }|d_{n-1}(\alpha ,\beta )\}=\frac{1}{2\pi {\sigma }^2}{exp}^{\left(-\frac{1}{2{\sigma }^2}\left[{(d_n-{\mu }_d(\alpha ,\beta ))}^2\right]\right)}.\end{array}$$

(8)

The probability that the distance between the two vehicles is less than the communication range $rang{e}_{V2V}$ at time $t_n$ using an integral under $d_n$ is as follows:

$$P{r}_{conn}^{[\alpha ,\beta ]}\left(t_n\right)={\int }_0^{rang{e}_{V2V}}p\{d_n(\alpha ,\beta )=q|d_{n-1}(\alpha ,\beta )\}dq$$

(9)

Using the obtained connection probability between the two vehicles at time $t_n$, the leaving time of the vehicular cloud member and the entry time of the candidate vehicle to be replaced can be estimated.

4.2. Probability of the Connection in Multiple Directions

This section describes the probability of connecting two vehicles according to $t_n$ on a multi-direction road, as shown in Figure 3. A vehicle suffers a number of multi-direction paths within the communication range of RSUs installed at each intersection, so the connection probability between the two vehicles at time $t_n$ should be calculated in consideration of the trajectory probability of each vehicle. The trajectory probability of the vehicle can be calculated using the Markov model that estimates the trajectory based on historical data. RSUs, who receive mobility information that is sent by the vehicle, send the information to the movement management server to manage the historical data of each vehicle, thereby obtaining the trajectory probability for each vehicle. The Markov model is affected by the order number because a big order has high complexity. The trajectory probability of a 1st-order Markov model is as follows:

$$p_{i(i+1)}=Pr\left(L_{(i+1)}\right|L_i)=\frac{X(L_i,L_{(i+1)})}{Z\left(L_i\right)},$$

(10)

where $p_{i(i+1)}$ is the trajectory probability that is derived based on the number of times that the vehicle has moved to $L_{i+1}$ when it drives at $L_i$. Through this probability, it is the 2nd-order Markov model that performs the calculation once more considering the situation before $L_i$, denoted as follows:

$$\begin{array}{cc}\hfill p_{(i-1)i(i+1)}& =Pr\left(L_{(i+1)}\right|L_i,L_{(i-1)})=\frac{X(L_{(i+1)},L_i,L_{(i-1)})}{Z(L_i,L_{(i-1)})},\hfill \end{array}$$

(11)

where $p_{(i-1)i(i+1)}$ is the trajectory probability that is derived based on the number of times that the vehicle has moved to $L_{i+1}$ when it drives at $L_i$ from $L_{i-1}$. Depending on the order of the Markov model, the accuracy of the trajectory prediction increases but leads to a tremendous increase in complexity. Therefore, we predict the trajectory using the 2nd-order Markov model. In section A, we formulate the location probability according to the acceleration and velocity of the vehicle. By mixing this location probability with the trajectory probability, if the location of vehicle $\alpha$ is $(x_{n-1},y_{n-1})$ at time $t_{n-1}$, the probability of the vehicle reaching $(x_n,y_n)$ at time $t_n$ when the vehicle selects the s-th path among S paths is denoted as follows:

$$\begin{array}{c}\hfill Pr\left[{\alpha }_n^s\left((x_n,y_n)\right)\right]=p\left\{(x_n,y_n)\right|(x_{n-1},y_{n-1})\}\times p_{(n-1)n,s}^{\alpha }.\end{array}$$

(12)

Thus, the probability that the distance between vehicle $\alpha$ and vehicle $\beta$ is less than the communication range is calculated differently depending on the s-th path among S paths. The expected connection probability between the two vehicles at time $t_n$ considering the trajectory probability of each vehicle is denoted using the cumulative distribution function (CDF) as follows:

$$P{r}_{conn}^{\alpha ,\beta }\left(t_n\right)=\sum _{s=1}^S\left(p_s^{\alpha }\sum _{r=1}^S\left(p_r^{\beta }\times P{r}_{conn}^{[{\alpha }^s,{\beta }^r]}\right)\right).$$

(13)

The connection probability between the two vehicles at time t can determine whether to replace the cloud member, and replacement candidates can also be selected.

4.3. Calculation of the Wasted Resources

When allocating the replacement vehicle to replace the vehicle that leaves the vehicular cloud at time t, the replacement vehicle consumes energy and resources to provide the cloud service. In the case of a vehicle that has many available resources, many vehicles around will use the vehicle’s resources. The vehicle consumes a lot of energy and wireless resources (time slot, bandwidth, and channel) to share resources with many requester vehicles. Therefore, for fairness to the usage of energy and radio resources, we assume that a vehicle that shares its available resources in one vehicular cloud does not share the remaining available resources in the other vehicular cloud.

When a vehicle is expected to leave the vehicular cloud, the RSU allocates an optimal replacement vehicle to the requester vehicle in order to maintain the cloud service based on the mobility and resource information of vehicles within the RSU’s communication range. The amount of resources that are insufficient due to the leaving member vehicles reduces the total provided resources of the vehicular cloud. The vehicular cloud cannot be maintained when the total provided resources of the vehicular cloud are less than the requested resources by the requester vehicle $req$. The expected needed resources $R_{need}\left(t\right)$, which are insufficient due to the leaving member vehicles, are denoted as follows:

$$\begin{array}{cc}\hfill R_{need}^{req}\left(t\right)=& \sum _{j=1}^J\left(\delta (P{r}_{conn}^{req,j}\left(t\right)<{\theta }_{th})\times R_{avail}^j\right)-\left(\sum _{j=1}^J\left(R_{avail}^j\right)-R_{req}\right),\hfill \end{array}$$

(14)

where J is the total number of member vehicles in the vehicular cloud, $R_{avail}^j$ is the available resources of the j-th member vehicle, and $R_{req}$ is the requested resources by the requester vehicle $req$. ${\theta }_{th}$ is derived from the optimization equation as a determinant. When the probability that the j-th member vehicle leaves the vehicular cloud is greater than ${\theta }_{th}$, $\delta (P{r}_{conn}^{req,j}\left(t\right)<{\theta }_{th})$ considers the member as the leaving member vehicle and has a value of 1. Otherwise, it has a value of 0.

To maintain the vehicular cloud, the sum of the available resources $R_{avail}^l$ of the vehicle that is allocated as the l-th replacement vehicle must be greater than $R_{need}\left(t\right)$ at every time t. However, when a vehicle with too many available resources is allocated as a replacement vehicle, the resources that remain after being provided to the requester vehicle cannot be shared to other vehicular clouds and are wasted. If the ratio of $R_{need}\left(t\right)$ to the sum of the available resources of the allocated replacement vehicle is close to 1, the wasted resources can be minimized. The percentage $r_{wasted}\left(t\right)$ of the wasted resources at time t is denoted as follows:

$$\frac{1}{r_{wasted}^{req}\left(t\right)}=\frac{R_{need}^{req}\left(t\right)}{{\sum }_{l=1}^L\left({\xi }^{req,l}\left(t\right)\times R_{avail}^l\right)},$$

(15)

where ${\xi }^{req,l}\left(t\right)$ is a determinant and is 1 when the candidate vehicle l is selected as a replacement vehicle for $req$ at time t. Otherwise, it has a value of zero. $\frac{1}{r_{wasted}^{req}\left(t\right)}$ has a value of 1 or less because the sum of the available resources of the replacement vehicle must be greater than or equal to $R_{need}^{req}\left(t\right)$.

4.4. The Optimization of the Wasted Resources

In order to stabilize the cloud services, the vehicle with the highest connection probability is selected as a replacement vehicle, and to minimize the wasted resources, the objective function is denoted as follows:

$$\begin{array}{cc}\hfill \underset{req}{U}=& \sum _{t=0}^{T_{service}^{req}}\left[{\eta }_{rel}\left(\sum _{l=1}^L{\xi }^{req,l}\left(t\right)\times P{r}_{conn}^{req,l}\left(t\right)\right)+{\eta }_{wasted}\left(\frac{R_{need}^{req}\left(t\right)}{{\sum }_{l=1}^L\left({\xi }^{req,l}\left(t\right)\times R_{avail}^l\right)}\right)\right],\hfill \end{array}$$

(16)

where $T_{service}^{req}$ is the valid time of the cloud service that is requested by $req$. ${\eta }_{rel}$ and ${\eta }_{wasted}$ are weight variables, and ${\eta }_{rel}+{\eta }_{wasted}=1$. The increased ${\eta }_{rel}$ denotes that the focus is on the stability of the cloud service, and the increased ${\eta }_{wasted}$ denotes that minimizing the wasted resources is concentrated.

$$\begin{array}{cc}\hfill \underset{{\xi }^{i,l}\left(t\right),{\theta }_{th}}{max}& \sum _I^{i=1}\underset{i}{U}\hfill \end{array}$$

(17)

$$\begin{array}{cc}\hfill s.t.& {\xi }^{i,l}\left(t\right)=\{0,1\},\nabla t\hfill \end{array}$$

(18)

$$\begin{array}{cc}\hfill & 0<{\theta }_{th}<1\hfill \end{array}$$

(19)

$$\begin{array}{cc}\hfill & \sum _{i=1}^I{\xi }^{i,l}\left(t\right)\le 1,\nabla t\hfill \end{array}$$

(20)

$$\begin{array}{c}\hfill \begin{array}{cc}\hfill & \left(\sum _{j=1}^J{R}_{avail}^j+\sum _{l=1}^L\left({\xi }^{i,l}\left(t\right)R_{avail}^l\right)-\sum _{j=1}^J\left(\delta (P{r}_{conn}^{i,j}\left(t\right)<{\theta }_{th})\times R_{avail}^j\right)\right)>R_i\hfill \end{array}\end{array}$$

(21)

The performance of the case that optimizes only one vehicular cloud can affect the performance of other vehicular clouds. Therefore, in order to optimize cloud service stability and waste resources of all requester vehicles i, the objective function is denoted as shown in Equation (17). Equations (18) and (19) are constraints that reflect the characteristics of ${\xi }^{req,l}\left(t\right)$ and ${\theta }_{th}$. For fairness in energy and wireless resources, it is limited as in Equation (20) to prevent the provision of the available resources to other clouds at the same time. In order to maintain the cloud services of each vehicular cloud, Equation (21) limits that the total provided resources by the vehicular cloud are greater than the requested resources by the requester vehicle i at every time t.

5. Performance Evaluation

In this section, we evaluate the performance of the proposed scheme through simulation results. The proposed scheme minimizes the wasted resource and the number of the cloud reconstruction by selecting the optimal replacement vehicles through our improved mobility prediction by using the powerful processing resource of RSUs. For the performance evaluation, we compare the proposed scheme with SERVitES [3], which does not consider the processing resource of RSUs. The process of constructing a vehicular cloud by the requester vehicle is the same as the proposed scheme. Since SERVitES does not use RSUs, only vehicles within the communication range of the requester vehicle can be considered as replacement candidate vehicles. In addition, the vehicle with the most resources is selected as the member vehicle of the vehicular cloud due to not considering the wasted resource and the connectivity between vehicles. We first present the environments for our simulations in Section 5.1. The performance of our three schemes is explained through simulation results in Section 5.2.

5.1. Simulation Environments

To evaluate the performances of SERVitES and the proposed scheme, we implemented them in an Network Simulator-3 (NS-3) version 3.34. To apply the mobility of vehicles in city areas, we included an enhanced Manhattan mobility model in the NS-3. Intersections existed at 1 km intervals, and RSUs were deployed for each intersection. The RSUs had a communication range of up to 800 m and a communication speed of up to 54 Mbps according to 802.11p. The vehicles basically had a density of 100 km⁻² and traveled at an average speed of 40 km/h on a two-lane road. The speed of the vehicle was determined by the acceleration value according to the Gaussian distribution limited to [−5, 5] m/s² every second [21,22]. The probability of selecting the direction in each intersection of each vehicle followed the 2nd Markov Model. Additionally, the vehicles had a communication range of up to 200 m and a communication speed of up to 54 Mbps. The list of simulation parameters is given in

Table 2. Parameter settings of the proposed scheme.

Parameter	Value
Network size	2 km × 2 km
Simulation total time	1000 s
Vehicle density	[50, 250] /km2
Average vehicle speed	[20, 60] km/h
V2I communication range	up to 1000 m
V2V communication range	up to 200 m
V2I transmission rate	up to 54 Mbps
V2V transmission rate	up to 54 Mbps
Vehicle cache storage	512 GB
RSU cache storage	1 TB
Distance between RSUs	1 km
Mobility model	enhanced Manhattan Model
The normalized sized of the requested resources	[1, 7]

.

To evaluate the performance of the proposed scheme and SERVitES, we compared two performance values of these schemes according to three environment values. The three environment values are the normalized size of the requested resources, the density of vehicles, and the average speed of the vehicles. The normalized size of the requested resources is the ratio of the requested resource size to the average available resource size of one vehicle. It denotes that the normalized size is 1 if the requested resource size is the same as the average available resource size of one vehicle. When the requested resource is large, the vehicular cloud is easily destroyed and reconstructed frequently by the unstable connectivity between vehicles. Accordingly, the total provision resource of the vehicular cloud is constructed closer to the requested resource due to continuous reconstruction. The density of vehicles is the number of vehicles in the 1 km × 1 km network area. If the density of vehicles is high, it denotes that there are enough candidate vehicles to reconstruct the vehicular cloud. In the dense vehicle case of the proposed scheme, the vehicular cloud can select the optimal candidate vehicle as a replacement vehicle in terms of saving the wasted resources and stabilizing the connectivity between vehicles. The average speed of vehicles is the average of the vehicle’s speed based on the determined acceleration by the Gaussian distribution every second from the start of the simulation in the entire network area. Since it directly affects the connectivity between vehicles, the vehicular cloud frequently requests reconstruction when vehicles are fast. In a not-dense vehicle environment, the frequent reconstruction of the vehicular cloud reduces the quality of service because there are not enough candidate vehicles to select the optimal replacement vehicle, and vehicles have unstable connectivity.

5.2. Simulation Results

The performances of the proposed scheme and SERVitES are estimated in terms of the wasted resource and the number of the cloud reconstructions in Section 5.2.1 and Section 5.2.2, respectively. As mentioned earlier, for fairness to the usage of energy and radio resources, a vehicle that shares its available resources in one vehicular cloud does not share the remaining available resources in the other vehicular cloud. When the wasted resources of the vehicular cloud member vehicles in the network area are large, a new requester vehicle can not have enough candidate vehicles to construct a vehicular cloud. Therefore, it affects the success probability of constructing a new vehicular cloud. The number of the cloud reconstructions is the number of reconstructing vehicular clouds by the requester vehicles during the simulation time in the entire network area. If the scheme selects optimal member vehicles of the vehicular cloud considering the connectivity between vehicles, member vehicles hardly leave the vehicular cloud. This decreases the number of the cloud reconstructions. Since an excessive amount of reconstruction causes a lot of packets in the entire network area, we evaluate this metric.

5.2.1. The Wasted Resource

Figure 4 shows the wasted resource according to the normalized size of the requested resources by the requester vehicles. If the requester vehicle wants a large amount of resources, the vehicular cloud needs more member vehicles. This leads to constructing a vehicular cloud with available resources closer to the size of the requested resource. Therefore, larger sizes of the requested resources have less wasted resources. In the case of SERVitES, because the requested resource is met by the vehicles that have the largest amounts of available resource, the wasted resources are bigger than the proposed scheme. In the proposed scheme, the vehicular cloud can consider more vehicles as candidate vehicles because the proposed scheme uses the communication range of the RSU. Additionally, since it minimizes the wasted resources to construct or to reconstruct the vehicular cloud, it has wastes fewer resources than SERVitES.

Figure 5 shows the wasted resources according to the density of vehicles. When the density of vehicles is high, the requester vehicle and the RSU can use more vehicles to construct or to reconstruct the vehicular cloud. If the vehicles that can be member vehicles are adequate, the vehicular cloud can select better member vehicles. SERVitES only considers the largest size of the available resource and the connectivity between vehicles. In SERVitES, if the vehicles are dense, there is a high probability of finding a few member vehicles with large amounts of resources instead of many member vehicles with small amounts of resources. This has unintentionally led to the saving of the wasted resource. In the proposed scheme, if the vehicles are dense, there are more candidate vehicles to be used to construct or to reconstruct the vehicular cloud by optimizing the wasted resources. Therefore, more optimal candidate vehicles can be chosen as member vehicles of the vehicular cloud. That is the reason that the proposed scheme has less wasted resource than SERVitES.

Figure 6 shows the wasted resources according to the average speed of vehicles. Since fast vehicles suffer more intersections and may leave the vehicular cloud, their vehicular clouds need to be reconstructed more due to the low connectivity between vehicles. To reconstruct the vehicular cloud, it is necessary to find another member vehicle instead of the leaving member vehicle that was optimally chosen. This causes an increase in wasted resources because it may cause all the best members to get out and the worst members to be picked. In SERVitES, more reconstruction of the vehicular cloud has a high probability that the vehicular cloud chooses a vehicle with more available resources as a member vehicle. When frequently changing the member vehicles of the vehicular cloud, the vehicular cloud selects the vehicle with more available resources as a member vehicle, and thus, the wasted resources will be increased. In the proposed scheme, the RSU selects the vehicle that best minimizes the wasted resources as a member vehicle. When vehicles are slow, the optimally selected member vehicle of the vehicular cloud maintains its cloud longer. Thus, the proposed scheme has fewer wasted resources than SERVitES.

5.2.2. The Number of Cloud Reconstructions

Figure 7 shows the number of cloud reconstructions according to the normalized size of the requested resources. When the size of the requested resource is large, the vehicular cloud needs more member vehicles to maintain itself. If the vehicular cloud includes many member vehicles, the probability that one member vehicle leaves the vehicular cloud is increased. In that case, since the vehicular cloud is destroyed by leaving member vehicles, the vehicular cloud needs to be reconstructed. Thus, if the size of the requested resource is large, the reconstruction of the vehicular cloud frequently occurs due to the high probability of leaving member vehicles. In SERVitES, the vehicle with the largest amount of available resources is selected as the member vehicle of the vehicular cloud based on the current speed of the vehicle. The connectivity between vehicles is very unstable because the vehicles can change their speed and direction in the network area. This leads to an increased number of reconstructions necessary for the vehicular cloud. In the proposed scheme, the prediction of the connection between the member vehicles is more accurate than SERVitES because the RSU considers the connectivity between vehicles. Therefore, the proposed scheme has a more stable connection compared with SERVitES.

Figure 8 shows the number of the cloud reconstructions according to the density of vehicles. If the density of vehicles is high, the vehicular cloud can choose the best member vehicles to construct the vehicular cloud in terms of connectivity because there are more candidate vehicles that can be member vehicles. Thus, when vehicles are dense, the member vehicles hardly leave the vehicular cloud because of enough candidate vehicles. In SERVitES, the requester vehicle considers the connectivity between itself and the candidate vehicles to receive the largest amount of resources. The number of the cloud reconstructions is reduced because the requester can select the vehicles that have good connectivity to the requester vehicle and large available resources when vehicles are dense. In the proposed scheme, using a more accurate prediction of vehicle mobility, the RSU can allocate the replacement vehicle with the optimized connectivity to the requester vehicle to reconstruct the vehicular cloud. Accordingly, the proposed scheme has fewer requests for the reconstruction of vehicular clouds than SERVitES.

Figure 9 shows the number of the cloud reconstructions according to the average speed of vehicles. When vehicles are fast, the connection time between vehicles is reduced due to suffering more intersections and leaving the vehicular cloud quickly. The vehicular cloud needs time to maintain the connection among member vehicles to provide the available resources to the requester vehicle. During the needed time, the vehicular cloud needs more reconstruction to maintain it due to the increased disconnection between vehicles. In SERVitES, the requester vehicle tries to maintain the vehicular cloud by searching for a replacement vehicle in the V2V communication range. Due to the relatively short range of communication, the number of candidate vehicles is not adequate to select the best member vehicles in terms of the connectivity. In the proposed scheme, the vehicular cloud can replace its leaving member vehicles with the replacement vehicles using the V2I communication range. Due to the relatively long range of communication, the number of candidate vehicles is adequate to select the optimized member vehicles in terms of connectivity and saving wasted resources. For this reason, the proposed scheme has fewer instances of cloud reconstruction according to the average speed of vehicles.

6. Conclusions and Future Work

6.1. Conclusions

In this paper, we address the issue of replacing the leaving member vehicles of vehicular clouds with new member vehicles to reconstruct vehicular clouds at intersections in VANETs. To do this, we propose an RSU-aided optimal member replacement scheme for the reconstruction of vehicular clouds in VANETs in order to reduce the number of cloud reconstructions and wasted resources. The proposed scheme does not include RSUs as members of vehicular clouds, but only exploits their computational and coverage ability in order to determine optimal new members to replace the leaving member vehicles on intersections. With the ability of RSUs, the proposed scheme first provides an improved mobility prediction model to enhance the connectivity prediction accuracy of vehicles in vehicular clouds. Our improved mobility prediction model considers both the mobility prediction based on Gaussian probability and the trajectory prediction based on a Markov model and calculates the probability of the connection of vehicles in one and multiple directions. Next, the proposed scheme presents the problem of identifying optimal replacement member vehicles to minimize the wasted resources of vehicles, which is formulated by the ratio of the size of the requested resource and the available resources of the vehicles. Then, the problem is solved through integer linear programming (ILP) in order to achieve minimization of the wasted resources. To evaluate the performance of the proposed scheme, we implement a simulation using NS3 with the enhanced Manhattan mobility model, wherein vehicles accelerate with a Gaussian distribution and conduct directional shifts with the Markov model on the road. Simulation results verified that the proposed scheme achieves smaller numbers of cloud reconstruction and fewer wasted resources compared with SERVitES.

6.2. Future Work

The proposed scheme selects the optimal replacement member vehicles to minimize wasted resources with the stable connectivity of a vehicular cloud in a restricted environment for the fairness of wireless resources and energies. However, it has a limitation regarding the prediction failure due to unexpected situations such as accidents, changes in the driver’s mind, etc. After detecting the failure of the mobility prediction, we can solve that problem by using other optimization models or machine learning. Additionally, the mobility prediction of vehicles can be improved by using machine learning in real scenarios. Therefore, we will handle the prediction failure due to unexpected situations and improve the accuracy of the vehicle mobility prediction to enhance the performance of the proposed scheme in real scenarios.