Cooperative Content Precaching Scheme Based on the Mobility Information of Vehicles in Intermittently Connected Vehicular Networks

Abstract

Intermittently connected vehicular networks (ICVNs) consist of vehicles moving on roads and stationary roadside units (RSUs) deployed along roads. In ICVNs, the long distances between RSUs and the large volume of vehicular content lead to long download delays to vehicles and high traffic overhead on backhaul links. Fortunately, the improved content storage size and the enhanced vehicular mobility prediction afford opportunities to ameliorate these problems by proactively caching (i.e., precaching) content. However, existing precaching schemes exploits RSUs and vehicles individually for content precaching, even though the cooperative precaching between them can reduce download delays and backhaul link traffic. Thus, this paper proposes a cooperative content precaching scheme that exploits the precaching ability of both vehicles and RSUs to enhance the performance of content downloads in ICVNs. Based on the trajectory and velocity information of vehicles, we first select the optimal relaying vehicle and the next RSUs to cache the requested content proactively and provide it to the requester vehicle optimally. Next, we calculate the optimal content precaching amount for each of the relaying vehicle and the downloading RSUs by using a mathematical model that exploits both the dwell time in an RSU and the contact time between vehicles. To compensate for the error of the mobility prediction in determining both the dwell time and the contact time, our scheme adds a guardband to the optimal content precaching amount by considering the expected reduced delay. Finally, we evaluate the proposed scheme in various simulation environments to prove the achievement of efficient content download performance by comparing with the existing schemes.

1. Introduction

With the rapid development of wireless communications and vehicular technologies, vehicular networks have become a fundamental building block for designing the architecture of intelligent transportation systems (ITS)  [1,2,3,4,5,6,7]. Considering the various communication scenarios in ITS, vehicular networks help in providing drivers and passengers safety and convenience, and furthermore introduce next-generation applications such as multimedia entertainment and social interactions [8,9,10]. Generally, vehicular networks consist of vehicles moving on roads and stationary roadside units (RSUs) deployed along roads. Vehicles can communicate with each other through vehicle-to-vehicle (V2V) communication and connect to RSUs via vehicle-to-infrastructure (V2I) communications [11,12,13,14,15,16]. RSUs, which are one of the infrastructures in vehicular networks, and play a role in providing the functions of both routers for relaying content data and access points for connecting to content servers on the Internet [17,18].

With the ever-increasing scale of vehicular content, such as multimedia content of images, music, and video clips, the communication capacity of vehicular networks might not be able to completely deliver the entire content from a single RSU to vehicles within its communication coverage for V2I communication owing to their limited bandwidth [19,20]. To overcome this issue, vehicular networks are required to provide seamless connections to vehicles from multiple continuous RSUs communicated with backhaul links. However, deploying sufficient RSUs along roads may be difficult owing to several geographic constraints and high deployment costs [18]. Vehicular networks corresponding to this characteristic are defined as intermittently connected vehicular networks (ICVNs) [21,22], because vehicles can only intermittently connect to RSUs on roads during movement. When vehicles move in the area (called the outage zone) between two neighboring RSUs, they cannot download content from the RSUs [23]. Thus, long inter-RSU distances and large vehicular contents in ICVNs lead to long download delays to vehicles and high traffic overhead on backhaul links [24].

Fortunately, the increase in content storage size and the enhancement of vehicular mobility prediction afford opportunities to alleviate these problems by proactively caching (i.e., precaching) content [25]. To this end, research on content precaching based on mobility information has recently been conducted on ICVNs [20,23,26,27]. To reduce the delay of content download and the amount of traffic on backhaul links, content precaching protocols based on the mobility information of vehicles have been proposed using two approaches: RSU precaching and vehicle precaching. RSU precaching [20,26] exploits the content precaching of the next RSU on the predicted trajectory of a requester vehicle. Consequently, the requester vehicle can instantly download content from the next RSU when it enters the coverage of the next RSU. Vehicle precaching [23,27] exploits the content precaching of a vehicle in the coverage of the current RSU where a requester vehicle is currently located. Thus, when the requester vehicle meets the precaching vehicle in the outage zone of the current RSU coverage, the precaching vehicle relays the content to the requester vehicle. However, the existing RSU precaching protocols led to heavy backhaul link traffic because they focused only on the protocol process for the operation of content precaching [20] or used only simple information such as the locations of vehicles and RSUs for the calculation of the precaching amount [26] and thus, did not provide the optimal precaching amount. Additionally, the existing vehicle precaching protocols caused less efficient content precaching owing to the exploitation of half of the RSU coverage for downloading to a precaching vehicle [23] or for selecting a secure precaching vehicle to support secure content delivery [27]. Furthermore, the existing precaching protocols only exploited RSUs and vehicles individually for content precaching, even though cooperative precaching through both RSUs and vehicles could reduce content download delays and backhaul link traffic.

Therefore, this paper proposes a cooperative content precaching scheme that enhances the performance of content downloads in ICVNs. In contrast to existing schemes, the proposed scheme cooperatively exploits the precaching ability of both vehicles and RSUs to achieve optimal content precaching between them. Based on the mobility information of vehicles, our scheme first selects both the optimal vehicle for relaying content to a requester vehicle in the outage zone and the next RSU for downloading content to the requester vehicle in the coverage of the next RSU. Next, this scheme calculates the optimal content precaching amount for each optimal relaying vehicle, and downloads the next RSU using our mathematical model. The mathematical model uses both the dwell time of vehicles in an RSU and the contact time between vehicles in the outage zone. Subsequently, the mobility prediction of vehicles is used to calculate the dwell and contact times. To compensate for the error of the mobility prediction in determining both the dwell and contact times, our scheme adds a guardband to the optimal content precaching amount to prevent the degradation of the content download while minimizing the amount of the guardband. For calculating the guardband amount, our scheme considers the expected reduced delay value that is obtained by the the theoretical delay value and the actual estimated delay value. Simulation results conducted in various environments verify that the proposed scheme achieves better performance than the existing RSU and vehicle precaching schemes in terms of content download delay, backbone traffic, precaching traffic, RSU usage, and hit ratio.

The remainder of this paper is organized as follows. Section 2 presents the network model and an overview of the proposed scheme. Section 3 describes in detail the proposed scheme related to cooperative content precaching based on the mobility information of vehicles. Section 4 addresses the guardband for handling errors in vehicle mobility prediction. Section 5 evaluates the performance of the proposed scheme by comparing it with existing schemes through simulation results. Finally, Section 7 concludes the paper.

2. Network Model and Overview

In this paper, we propose a cooperative content-precaching scheme for ICVNs. Figure 1 shows the network model of the proposed scheme. We consider a network in which a large number of vehicles travel on roads in vehicular network fields where several RSUs are deployed [12,17]. In this network, every vehicle moves along its travel route to arrive at its destination by passing several RSUs. In our scheme, whenever a vehicle enters the communication coverage of an RSU, it registers its current location and mobility information with the RSU by periodically sending a beacon message to the RSU [28,29]. Therefore, all RSUs have a table to manage information about the mobility of all vehicles within their communication coverage. In the proposed scheme, each RSU can select the optimal relaying vehicle and the next downloading RSU to provide the requested content to the requester vehicle by precaching the content based on information about the mobility of the vehicle within its own coverage. RSUs arranged at regular intervals are connected to each other and to a content server that can provide all the requested content through wired backhaul links [17]. However, because RSUs cannot be deployed to cover an entire area of roads owing to several geographic constraints and the high cost of deployment, there are bound to be outage zone between two neighboring RSUs in ICVNs [30], as shown in Figure 1. In the outage zone, the requested content cannot be provided to the requester vehicle from any RSUs. We assume that the downlink transmission rate from an RSU to each vehicle in its coverage area is the same, and each vehicle has a different velocity and travels toward its destination on the road. All vehicles can connect with RSUs through cellular communications, as well as with other vehicles through IEEE 802.11p wireless access in vehicular environments (WAVE) communications [31,32]. In general, the communication coverage from an RSU to a vehicle (I2V) is longer than that between vehicles (V2V) because the transmission power and rate of I2V is higher than that of V2V.

If a vehicle requires to download the intended content while moving in the communication coverage of the RSU where the vehicle is located, the vehicle sends an interest packet to the RSU to request the intended content. In this paper, we named a vehicle that sends an interest packet to an RSU to download the intended content as a requester vehicle. Upon receiving the packet showing interest, the RSU requests and receives the intended content to and from the corresponding content server. After receiving the intended content, the RSU determines whether it can download the entire intended content to the requester vehicle. For this purpose, the proposed scheme calculates the downloadable amount of content for a requester vehicle in the communication coverage of the RSU where the requester vehicle is located. Then, the downloadable amount of content is calculated using the mobility information of the requester vehicle and the V2I transmission rate of the RSU. If the RSU can download the entire content to the requester vehicle, it sends the content to the requester vehicle. However, if the RSU cannot download the entire content to the requester vehicle, it selects the optimal relaying vehicle among vehicles except the requester vehicle in its communication coverage to precache the intended content for the requester vehicle. In the proposed scheme, the optimal relaying vehicle is determined by calculating both the downloadable time and amount from the RSU, and the relaying time and amount between the requester vehicle and each relaying vehicle. The RSU then precaches the optimal relaying amount of the intended content to the optimal relaying vehicle. Thus, the requester vehicle downloads the intended content from the RSU up to the amount that the RSU is enabled for sending. After exiting the communication coverage of the RSU, the requester vehicle receives the optimal relaying amount of intended content from the optimal relaying vehicle in the outage zone. Although the requester vehicle cannot fully download the entire size of the intended content from both the RSU and the optimal relaying vehicle, the RSU precaches the remaining amount of the intended content to the next RSU on the predicted trajectory of the requester vehicle through backhaul links. Thus, when the requester vehicle enters the next RSU, it can immediately download the remaining amount of intended content from the next RSU. If the next RSU cannot download the remaining amount of the intended content to the requester vehicle in its communication coverage, the aforementioned process continues until the downloading of the intended content is completed. Figure 1 shows an overview of the proposed scheme to describe the cooperative content precaching process based on both the optimal relaying vehicle and the next downloading RSU. The proposed scheme is described in detail in Section 3.

3. The Selection of the Optimal Relaying Vehicle

In this section, we describe the precaching scheme by selecting the optimal relaying vehicle and next RSU to provide as much content as possible to the requester vehicle. We first explain the decision to use precaching based on the downloadable amount of content in Section 3.1. Then, we select the optimal relaying vehicle based on the connectivity prediction in Section 3.2. Finally, in Section 3.3, we explain how the next RSU precaches the content to provide it to the requester vehicle.

Table 1. Notations for selecting the optimal relaying vehicle.

Notation	Description
$RS{U}_j$	j-th roadside unit (RSU), where $j\in \{1,\cdots ,J\}$
$V_i$	i-th vehicle, where $i\in \{1,\cdots ,I\}$
$V_{req}$	The requester vehicle
$V_{rel}$	The selected optimal relaying vehicle
$t_{max\_i}$	The maximum time that Vi can relay the content to Vreq within the outage zone
$t_{D_{req}}$	The downloadable time for providing the requested content to $V_{req}$ within the coverage of $RS{U}_j$
$T_{D_i}$	The downloadable time for precaching the requested content to $V_i$ within the coverage of $RS{U}_j$
$T_{R_i}$	The relaying time of $V_i$ for providing the precached content to $V_{req}$ within the outage zone
$x_{E{X}_j}$	The coverage diameter of $RS{U}_j$
$x_{req}$	The current location of $V_{req}$
$x_i$	The current location of $V_i$
$v_{req}$	The current speed of $V_{req}$
$v_i$	The current speed of $V_i$
$R_{I2V}$	The transmission rate of the I2V
$R_{V2V}$	The transmission rate of the V2V
$C_T$	The total size of the requested content
$C_R$	The downloadable amount of the requested content for providing the requested content to $V_{req}$ within the coverage of $RS{U}_j$
$C_{D{V}_i}$	The downloadable amount of the requested content for precaching it to $V_i$ within the coverage of $RS{U}_j$
$C_{R{V}_i}$	The relaying amount of the content for providing it to $V_{req}$ within the outage zone
$C_{PD{V}_i}$	The maximum amount of the requested content for providing it from $V_i$ to $V_{req}$ within the outage zone by precaching it to from $RS{U}_j$ to $V_i$ within the coverage of $RS{U}_j$
$C_V$	The relaying amount of the precached content for providing it to $V_{req}$ within the outage zone
$r_c$	The coverage radius of the vehicles
U	The distance of the outage zone between $RS{U}_j$ and $RS{U}_{j+1}$

 shows notations for selecting the optimal relaying vehicle.

3.1. Checking the Necessity for Precaching

If a vehicle traveling on the road within the coverage area of $RS{U}_j$ wants to download the content, it sends a request message to $RS{U}_j$, where $j=\{1,\cdots ,J\}$. When $RS{U}_j$ receives the request message from the requester vehicle $V_{req}$, it calculates the downloadable time $t_{D_{req}}$ that $V_{req}$ can download the content from the $RS{U}_j$ within its coverage. $t_{D_{req}}$ can be denoted as the time at which $V_{req}$ is expected to leave $RS{U}_j$’s coverage, and it can be calculated based on the velocity and the location of $V_{req}$ as follows:

$$t_{D_{req}}=\frac{x_{{EX}_j}-x_{req}}{v_{req}},$$

(1)

where $x_{{EX}_j}$ is the communication coverage of the $RS{U}_j$, $x_{req}$ is the location of $V_{req}$, and $v_{req}$ is the velocity of $V_{req}$, respectively. Based on $t_{D_{req}}$, $RS{U}_j$ calculates the downloadable amount $C_R$ of the requested content that can be provided to the $V_{req}$ within $RS{U}_j$’s coverage by using the transmission rate of the I2V communication, as follows:

$$C_R=t_{D_{req}}\times R_{I2V},$$

(2)

where $R_{I2V}$ is the transmission rate of the I2V based on IEEE 802.11p WAVE [31].

$RS{U}_j$ then decides whether the requested content has to be precached by comparing $C_R$ with $C_T$. If $C_T\le C_R$, it denotes that $RS{U}_j$ can provide all of the requested content to $V_{req}$ before $V_{req}$ leaves the communication coverage of $RS{U}_j$, where $C_T$ is the size of the requested content by $V_{req}$. In this case, $RS{U}_j$ immediately provides the requested content to $V_{req}$. Otherwise, it denotes that $RS{U}_j$ does not have sufficient time to provide all of the requested content to $V_{req}$ at time $t_{D_{req}}$. Thus, $RS{U}_j$ should select a relaying vehicle among the vehicles within its coverage to provide the requested content to $V_{req}$ after $V_{req}$ leaves the coverage of $RS{U}_j$. The relaying vehicle, $V_{rel}$, provides the remaining amount of content to $V_{req}$ outside the communication coverage of $RS{U}_j$.

3.2. Selection of the Optimal Relaying Vehicle

In this section, we describe the selection of the optimal relaying vehicle to provide the remaining requested content to $V_{req}$. It is possible that $RS{U}_j$ and $V_{rel}$ cannot provide all the requested content to $V_{req}$ owing to the large size of the content or the short connectivity. In this case, to provide the remaining amount of content to $V_{req}$ outside the coverage, $RS{U}_j$ should select the relaying vehicle while providing as much requested content as possible to $V_{req}$ within its coverage. To determine the optimal relaying vehicle $V_{rel}$, $RS{U}_j$ calculates the amount of the content that can be relayed by each candidate vehicle that is managed by the table of $RS{U}_j$ within its coverage. Then, $RS{U}_j$ selects the optimal relaying vehicle among the candidate vehicles and the amount $C_V$ of the requested content that can be relayed by it.

For this selection through the table, $RS{U}_j$ uses the beacon messages that include the mobility information of vehicles that remain in the coverage of $RS{U}_j$. Based on the location and velocity of each candidate vehicle, $RS{U}_j$ calculates each candidate vehicle’s downloadable time and the downloadable amount of the content from $RS{U}_j$, as shown in Section 3.2.1. It also calculates the relaying time and the relaying amount of the content, which can be relayed to $V_{req}$ from each candidate vehicle, as detailed in Section 3.2.2. In Section 3.2.3, using these values, $RS{U}_j$ selects the optimal relaying vehicle as $V_{rel}$ and its relaying amount as $C_V$. Therefore, $RS{U}_j$ provides the $C_V$ of the content to $V_{rel}$ within its coverage and $V_{rel}$ relays it to $V_{req}$ when $V_{req}$ leaves $RS{U}_j$’s coverage.

3.2.1. The Downloadable Time and Amount

To determine the optimal relaying vehicle $V_{rel}$, $RS{U}_j$ first has to know the downloadable time and amount of the content of each candidate vehicle $V_i$ within $RS{U}_j$’s coverage. Similarly, to obtain $T_{D_{req}}$, the downloadable time of each candidate vehicle can be calculated based on $x_{E{X}_j}$. However, when $V_{req}$ leaves the coverage of $RS{U}_j$, the content must be relayed to $V_{req}$ from the relaying vehicle. Therefore, $RS{U}_j$ can obtain the downloadable time of each candidate vehicle from $RS{U}_j$ in order to provide it to $V_{req}$, as follows:

$$T_{D_i}=min\left(\frac{x_{{EX}_j}-x_i}{v_i},t_{D_{req}}\right),$$

(3)

where $x_i$ and $v_i$ are the position and speed of $V_i$, respectively. Then, $RS{U}_j$ calculates the downloadable amount $C_{D{V}_i}$ of the content that the $V_i$ can precache from $RS{U}_j$ during the time $T_{D_i}$ based on the transmission rate of I2V as follows:

$$C_{{DV}_i}=T_{D_i}\times R_{I2V},$$

(4)

where $R_{I2V}$ is the V2I transmission rate that is based on IEEE 802.11p WAVE [31]. Even if $V_i$ can precache the $C_{D{V}_i}$ of the content, it may not relay it to $V_{req}$ because of the short connectivity between $V_{req}$ and $V_{rel}$. Hence, the relaying time and amount of content must be calculated.

3.2.2. The Relaying Time and Amount

It is also necessary to calculate the relaying time and relaying amount of the requested content of the candidate vehicles in the outage zone to select the optimal relaying vehicle. To determine the relaying time, $RS{U}_j$ must first calculate the connection time between $V_{req}$ and each $V_i$. However, when $V_{req}$ enters the next RSU, that is, $RS{U}_{j+1}$’s coverage, the download from the $RS{U}_{j+1}$ is better than that from $V_i$, owing to the difference in the power and the transmission performances. Therefore, the relaying should be conducted within the outage zone, which is the area between the coverages of $RS{U}_j$ and $RS{U}_{j+1}$. Then, the relaying time $T_{R_i}$ of $V_i$ can be denoted based on the location and the velocity of both $V_{req}$ and $V_i$, as follows:

$$T_{R_i}=\left\{\begin{array}{cc}\frac{r_c+x_i-x_{req}}{v_{req}-v_i}-T_{D_i},\hfill & if{v}_{req}>v_i\hfill \\ \frac{r_c-x_i-x_{req}}{v_{req}-v_i}-T_{D_i},\hfill & if{v}_{req}<v_i\hfill \\ t_{max\_i},\hfill & if{v}_{req}=v_i\hfill \end{array}\right.,$$

(5)

where $r_c$ is the communication range of the vehicles, $x_i$ is the location of $V_i$, and $v_i$ is the velocity of $V_i$. $T_{D_i}$ is the downloadable time of $V_i$. $t_{max\_i}$ is the maximum time that $V_i$ can relay the content to $V_{req}$ within the outage zone. However, if the relaying time $T_{R_i}$ of $V_i$ is larger than $t_{max\_i}$, then $T_{R_i}$ is limited to $t_{max\_i}$. $t_{max\_i}$ is denoted as follows:    

$$t_{max\_i}=\frac{U}{v_{req}}-T_{D_i},$$

(6)

where U is the distance of the outage zone between the ${RSU}_j$ and ${RSU}_{(j+1)}$. This indicates that $V_{req}$ can receive the content from the selected $V_i$ within the outage zone and from $RS{U}_{j+1}$ after passing through the outage zone. Using $T_{R_i}$, $RS{U}_j$ can calculate the relaying amount $C_{{RV}_i}$ of the content that can be provided to $V_{req}$ from $V_i$ within the outage zone, as follows:

$$C_{{RV}_i}=T_{R_i}\times R_{V2V},$$

(7)

where $R_{V2V}$ is the transmission rate of the V2V communications that is based on IEEE 802.11p WAVE [31]. $RS{U}_j$ can select the optimal relaying vehicle $V_{rel}$ because it now knows the amount of the content that can be downloaded to $V_i$ from $RS{U}_j$ and can be relayed to $V_{req}$ from $V_i$.

3.2.3. Selection of the Optimal Relaying Vehicle

To select the optimal relaying vehicle, $RS{U}_j$ creates each set of $V_i$ using the downloadable amount $C_{{DV}_i}$ and the relaying amount $C_{{RV}_i}$ of the content as follows:

$$Set\left(V_i\right)=\{C_{{DV}_i},C_{{RV}_i}\}.$$

(8)

The set $Set\left(V_i\right)$ is saved in the $RS{U}_j$’s table with the mobility information of $V_i$. Based on $Set\left(V_i\right)$, $RS{U}_j$ compares the $C_{{DV}_i}$ and $C_{{RV}_i}$ of each $V_i$ and selects a smaller value. In the case of $C_{{DV}_i}>C_{{RV}_i}$, it denotes that the connection time between $V_{req}$ and $V_i$ is insufficient to relay all the precached content that $V_i$ downloads from $RS{U}_j$. Otherwise, in the case of $C_{{DV}_i}<C_{{RV}_i}$, it denotes that the downloadable time of $V_i$ is not sufficient to compare the connection time that $V_i$ can provide the content to $V_{req}$. Therefore, $RS{U}_j$ selects the minimum value between the two values as the practical delivery amount $C_{{PDV}_i}$ of the content, as follows:

$$C_{{PDV}_i}=min\{C_{{DV}_i},C_{{RV}_i}\}.$$

(9)

Thus, $C_{PD{V}_i}$ denotes that the maximum amount of the content that $V_i$ can practically provide to $V_{req}$ before $V_{req}$ reaches the coverage of $RS{U}_{j+1}$. Then, $RS{U}_j$ can determine the optimal relaying amount $C_V$ by selecting the optimal relaying vehicle that has the largest $C_{PD{V}_i}$, as follows:

$$C_V=C_{{PDV}_{rel}}=max\{C_{{PDV}_1},\cdots ,C_{{PDV}_n}\}.$$

(10)

The $C_{{PDV}_{rel}}$ of $V_{rel}$ denotes the maximum amount of the content that $V_{req}$ can receive from $V_{rel}$ within the outage zone.

When $V_{req}$ leaves the coverage of $RS{U}_j$ and enters the outage zone, $V_{rel}$ immediately provides the $C_V$ of downloaded content to $V_{req}$. For example, as shown in Figure 1, if $V{1}_{rel}$ is selected as the optimal relaying vehicle for $V{1}_{req}$, because $V{1}_{req}$ wants to download the content, $RS{U}_j$ provides the $C_R$ of the requested content to $V{1}_{req}$ and the $C_V$ of the requested content to $V_{rel}$. Then, in the case of $V{2}_{rel}$, which is selected as the optimal relaying vehicle for $V{2}_{req}$ and downloaded $C_V$ of the content, it provides the content to $V{2}_{req}$ during the outage zone.

3.3. Optimal Content Precaching to Next RSU

If the $C_R+C_V$ is smaller than $C_T$, which is the total size of the requested content, $RS{U}_j$ judges that it is not sufficient for the content that can be provided before $V_{req}$ reaches $RS{U}_{j+1}$. In this case, $RS{U}_j$ sends a message to make the next RSU, that is, $RS{U}_{j+1}$ precaches the remaining amount of the requested content. The amount $C_P$ of the content that must be precached at $RS{U}_{j+1}$ can be easily determined based on $C_T$, $C_R$, and $C_V$ as follows:

$$C_P=C_T-C_R-C_V.$$

(11)

Therefore, the message that $RS{U}_j$ sends to $RS{U}_{j+1}$ via the backhaul network includes the name and the amount $C_P$ of the requested content and the information about $V_{req}$. If there are no candidate vehicles that can relay the content to $V_{req}$, the amount $C_P$ becomes $C_T-C_R$. When the $V_{req}$ enters into $RS{U}_{j+1}$’s coverage, ${RSU}_{j+1}$ immediately provides the $C_P$ of the requested content that has already been precached. Then, $V_{req}$ receives all the requested content through all RSUs, including $RS{U}_{j+1}$. For example, as shown in Figure 1, if $V{3}_{rel}$ is selected as the optimal relaying vehicle for $V{3}_{req}$ because $V{3}_{req}$ has to receive a greater amount of the requested content, $RS{U}_j$ provides the $C_R$ of the requested content to $V{3}_{req}$ and the $C_V$ of the requested content to $V_{rel}$.

In a summary, Algorithm 1 briefly describes the cooperative content precaching of the proposed scheme. Line 1 defines $C_T$ using the information about the content c. Lines 2–5 compare $C_T$ and the downloadable size $C_R$ within the RSU j’s coverage to decide the usage of precaching, as shown in Section 3.1. Lines 6–15 select the optimal relay vehicle $V_{rel}$ to precache c to provide it to $V_{req}$ as described in Section 3.2. Lines 16–17 explain the optimal precaching to the next RSU as discussed in Section 3.3.

Algorithm 1: Cooperative Content Precaching

Input: the content c, the RSU j’s coverage $x_{E{X}_j}$, the requester vehicle $V_{req}$’s the location $x_{req}$ and the velocity $v_{req}$ Output: Action of the RSU j 1: $C_T\leftarrow ($ the size of $c)$ 2: $C_R\leftarrow C_R(x_{E{X}_j},x_{req},v_{req})$ 3: if$C_T\le C_R$then 4:     [Providing $C_T$-sized c to $V_{req}$] 5: else 6:     $max=maxID=0$ 7:     for $i\in 1,\cdots ,n$ do 8:         $C_{PDV,i}=min\{C_{D{V}_i},C_{R{V}_i}\}$ 9:         if $C_{PD{V}_i}>max$ then 10:            $max$ = $CPD{V}_i$ 11:            $maxID$ = i 12:         end if 13:         $V_{rel}\leftarrow maxID$ 14:         $C_V$ = $max$ 15:         [Providing $C_R$-sized c to $V_{req}$] 16:         [Precaching $C_V$-sized c to $V_{rel}$] 17:         if $C_T>C_R+C_V$ then 18:            [Sending ($V_{req}$, $C_R+C_V$, c) information to the RSU $j+1$] 19:         end if 20:     end for 21: end if

4. Guardband for Handling the Mobility Prediction Errors

To select the optimal relaying vehicle, the proposed scheme must calculate the downloadable time of a requester vehicle $V_{req}$ in an RSU and the relaying time between $V_{req}$ and the relaying vehicle $V_{rel}$ in the outage zone. The downloadable time is based on the dwell time of $V_{req}$ in the RSU and the relaying time is based on the contact time between $V_{req}$ and $V_{rel}$. However, accurately predicting both dwell and contact times is very difficult because vehicles change their speed irregularly. In this section, we describe a guardband to compensate for the mobility prediction error caused by the fact that accurately predicting dwell and contact times is not feasible. An error exists in predicting the connection time (the contact time between vehicles in an outage zone and the dwell time of a requester vehicle $V_{req}$ in an RSU) based on their speed. Two mobility-prediction errors arise when the connection time is inaccurate. First, due to the shorter-than-expected download time in an RSU, $V_{req}$ does not obtain the expected amount of precached content. Because the portion of the content that is not received is not precached in the next RSU, the next RSU must obtain it from the content server or the previous RSU and send it to $V_{req}$. Obtaining content from the content server causes an additional delay. Second, the relay time between $V_{req}$ and $V_{rel}$ in the outage zone may deviate from the predicted value. If it is shorter than expected, the network performance will decrease for the same reason stated earlier. If the relaying time is longer than expected, $V_{rel}$ cannot provide extra content because it has only a precached portion of the content. In this instance, the delay increases owing to the increased time, which is required to provide the requested content. Therefore, a guardband against prediction errors of the contact time between vehicles can mitigate the corresponding problem.

Table 2. Notations for the calculation of the guardband.

Notation	Description
$dela{y}_{E\_re}(G,{\epsilon }_{mob})$	The expected reduced delay value by G of guardband and ${\epsilon }_{mob}$ of mobility error ratio
$t_{theo}$	The theoretical delay value in an ideal situation
$t_{est}$	The actual estimated delay value that is obtained by the predicted situation
$m_{theo}$	The theoretical distance value in an ideal situation
$m_{est}$	The actual estimated distance value that is obtained by the predicted situation
l	The transmission rate of backhaul links
${\xi }_{req,j}\left(m\right)$	One or zero value whether $RS{U}_j$ provides the requested content to $V_{req}$ after $V_{req}$ moves a distance of m meters
${\delta }_{req,k}\left(m\right)$	One or zero value whether $V_k$ provides the precached content to $V_{req}$ after $V_{req}$ moves a distance of m meters
${\epsilon }_{mob}$	The mobility error ratio of the vehicles
$v_{req}\left(j\right)$	The expected speed based on $v_{req}$ at the coverage of $RS{U}_j$
$v_{req,av}\left(j\right)$	The average expected speed based on $v_{req}$ and ${\epsilon }_{mob}$ at the coverage of $RS{U}_j$
$v_{req,av}^{out}\left(j\right)$	The average expected speed based on $v_{req}$ and ${\epsilon }_{mob}$ at the outage zone between $RS{U}_j$ and $RS{U}_{j+1}$
$v_{i,av}^{out}\left(j\right)$	The average expected speed based on $v_i$ and ${\epsilon }_{mob}$ at the outage zone between $RS{U}_j$ and $RS{U}_{j+1}$
$R_{req,j}\left(m\right)$	One or zero value whether $RS{U}_j$ relays the requested content to $V_{req}$ after $V_{req}$ moves a distance of m meters
$P_{req,k}\left(m\right)$	One or zero value whether $V_k$ provides the precached content to $V_{req}$ after $V_{req}$ moves a distance of m meters
$con{n}_{req,j}\left(m\right)$	One or zero value whether $V_{req}$ and $RS{U}_j$ are connected after $V_{req}$ moves a distance of m meters
$ou{t}_{req,j}\left(m\right)$	One or zero value whether $V_{req}$ stays within the outage zone between $RS{U}_j$ and $RS{U}_{j+1}$ after $V_{req}$ moves a distance of m meters
$traffi{c}_{E\_re}(G,{\epsilon }_{mob})$	The expected reduced traffic by G of guardband and ${\epsilon }_{mob}$ of mobility error ratio
$traffi{c}_{theo}$	The theoretical traffic value in ideal situation
$traffi{c}_{est}$	The actual estimated traffic value that is obtained by the predicted situation

shows notations for the calculation of the guardband.

In this study, there are two situations that predict the connection time: (1) in Section 4.1, the dwell time of $V_{req}$ within the RSU communication range is calculated; (2) in Section 4.2, the contact time between $V_{req}$ and $V_{rel}$ outside the RSU range is determined. These two estimated connection times can be used to formulate the number of guardbands required, as shown in Section 4.3.

4.1. Dwell Time in an RSU

When $V_{req}$ enters the coverage area of an RSU, its dwell time can be calculated using its position, velocity, and trajectory information. The proposed scheme then determines the amount of content $V_{req}$ can download from the current RSU throughout its dwell time. Therefore, the proposed scheme allows the current RSU to precache the remaining portion of the requested content to the next RSU for $V_{req}$. The remaining content is the total amount of content minus the amount of content downloaded during dwell time. However, if $V_{req}$ increases its speed and, as a result, its dwell time decreases, the practical amount that can be downloaded is also reduced. Hence, when $V_{req}$ connects to the next RSU, it should retrieve from the content server and transmit to $V_{req}$ the portions of the content that were not received by $V_{req}$ in the previous RSU. Because the data rate at which the content is brought from the content server and delivered to $V_{req}$ is slower than the data rate at which the precached content is delivered directly to $V_{req}$, this situation causes an additional delay for the content download. Thus, the next RSU can prevent this additional delay by preparing a guardband by considering the amount of content that cannot be received by $V_{req}$ in the previous RSU.

On the contrary, if the dwell time of $V_{req}$ is increased because of its increased speed, it can download a higher amount of content from the current RSU than expected. In this situation, $V_{req}$ can download a portion of the precached content that was already sent to the next RSU from the current RSU during the dwell time. Then, when $V_{req}$ connects to the next RSU, it does not need to download a portion of the content from the next RSU. Thus, $V_{req}$ can obtain the time required to download an additional amount of content from the next RSU. In particular, because the amount of precached content to the next RSU was already determined by the previous RSU, the additional amount that can be downloaded should be taken from the content server to the next RSU and delivered from the next RSU to $V_{req}$. This process is very inefficient in terms of the data rate and results in many delays. Therefore, preparing a guardband at the next RSU to download the additional amount can reduce delays.

4.2. Contact Time with the Relaying Vehicle

The dwell time between $V_{req}$ and an RSU within the RSU coverage was calculated using the mobility prediction of $V_{req}$. The contact time between the vehicles within the outage zone was calculated using the mobility predictions of both $V_{req}$ and the candidate vehicle. Therefore, the contact time has more prediction errors, as it is more difficult to predict. Two scenarios can occur in terms of mobility prediction error. First, if the speed of $V_{req}$ decreases, the contact time between $V_{req}$ and $V_{rel}$ increases and the arrival time to the next RSU increases. However, $V_{rel}$ cannot send an additional amount of content to $V_{req}$ during the increased contact time because it has received only the precached amount of content. Hence, it results in a delay wherein $V_{req}$ does not receive the additional amount of the content after it finishes receiving the precached amount of the content from $V_{rel}$. Thus, preparing the guardband in advance for the potentially increased contact time can reduce the overall delay because the additional content in the guardband can be provided to $V_{req}$ when the contact time increases. Subsequently, if $V_{req}$ has a higher speed than the expected speed and does not receive certain portions of the content to download from the current RSU, $V_{rel}$ is not able to send the portion to $V_{req}$ because $V_{rel}$ has only the precached amount of the content. Therefore, the next RSU should provide a portion of the content to $V_{req}$ preferentially before it provides its own precached amount of content. This causes an additional delay because the next RSU must take a portion of the content from the previous RSU or the content server. Therefore, if $V_{rel}$ has a portion of the content as a guardband, it reduces the burden on the next RSU and additional delay.

Consequently, if both $V_{rel}$ and the next RSU prepare a guardband for the content to be precached, the overall burden of the RSU is reduced because it can immediately send the guardband to $V_{req}$ without using the content server or the previous RSU. In addition, the guardband can increase the hit ratio to download the content when an error occurs. Furthermore, the guardband is very efficient in reducing the time delay involved in downloading the entire content by $V_{req}$.

4.3. Calculation of the Guardband

To use the guardband of precached content, we need to determine how much it needs to be prepared. We can minimize the delay that the requester vehicle may experience when the next RSU allocates the remaining portion of the requested content as a guardband. However, this causes a significant consumption of traffic. The unused guardband is discarded as wasted traffic. Consequently, there should be a proper trade-off between traffic and delay, according to the guardband.

The delay must be calculated first because the amount of traffic consumed is calculated by the delay. In this study, the delay was calculated using the mobility information of the requester vehicle, the size of the precached content, and the size of the guardband. The expected reduced delay value $dela{y}_{E\_re}(G,{\epsilon }_{mob})$ according to the guardband can be obtained by the difference between the theoretical delay value $t_{theo}$ and the actual estimated delay value, $t_{est}$. Thus, we need to calculate both $t_{theo}$ and $t_{est}$.

First, the theoretical delay value $t_{theo}$ consumed for content download is predicted by using the current speed of the requester vehicle. To derive $t_{theo}$ based on the total size of the requested content and the transmission rate of the RSUs, the speed of $V_{req}$ and the distance that $V_{req}$ moves are used rather than the connection time. From this point of view, because the time that $V_{req}$ traveled 1 m at the speed of $v_{req}$ is $v_{req}^{-1}$, the size at which $V_{req}$ receives the requested content from an RSU is $R_{V2I}\times v_{req}^{-1}$. The first RSU, $RS{U}_1$, should receive the requested content from the content server via backhaul links before providing it to $V_{req}$. In this case, the size at which $V_{req}$ can receive content from $RS{U}_1$ is ${(R_{V2I}^{-1}+l^{-1})}^{-1}\times v_{req}^{-1}$, where l is the transmission rate of the backhaul link. However, because $t_{theo}$ is a time value, the theoretical distance value $m_{theo}$ consumed for content download should be defined first. Here, $t_{theo}$ is $m_{theo}/v_{req}$, where $v_{req}$ is the speed of $V_{req}$. Therefore, the relationship between the $C_T$ and $m_{theo}$ is defined as follows:

$$\begin{array}{cc}\hfill C_T& =\sum _{m=0}^{m_1}\left({(R_{V2I}^{-1}+l^{-1})}^{-1}·\frac{{\xi }_{req,1}\left(m\right)}{v_{req}}\right)\hfill \\ \hfill & +\sum _{j=2}^J\sum _{m=m_1}^{m_{theo}}\left(R_{V2V}·\frac{{\sum }_{k=1}^{K_{req,j-1}}{\delta }_{req,k}\left(m\right)}{v_{req}}+R_{V2I}·\frac{{\xi }_{req,j}\left(m\right)}{v_{req}}\right),\hfill \end{array}$$

(12)

where ${\xi }_{req,j}\left(m\right)$ denotes whether $RS{U}_j$ provides the requested content to $V_{req}$ after $V_{req}$ moves a distance of m m. If $RS{U}_j$ provides the requested content to $V_{req}$ after $V_{req}$ moves m m, ${\xi }_{req,j}\left(m\right)$ is one. Otherwise, ${\xi }_{req,j}\left(t\right)$ is zero. $R_{V2I}$ is the transmission rate between an RSU and a vehicle. l is the transmission rate of backhaul links. ${\delta }_{req,k}\left(m\right)$ indicates whether $V_{rel}$ communicates with $V_{req}$ after $V_{req}$ moves m m. ${\xi }_{req,j}\left(m\right)$ and ${\delta }_{req,k}\left(m\right)$ can be either zero or one. $m_1$ is the distance at which $V_{req}$ reaches the end of the $RS{U}_1$’s coverage. To calculate $t_{theo}$, ${\xi }_{req,j}\left(m\right)$ and ${\delta }_{req,k}\left(m\right)$ can be known in advance because the mobility information of the vehicles is provided to the RSUs by accessing the server that manages the mobility information. The first sum represents the size of the content that $RS{U}_1$ receives from the content server over the backhaul link and provides to $V_{req}$. The second sum represents the sizes of the content that $V_k$ and $RS{U}_j$ provide $V_{req}$. In addition, because each node does not have an overlapped connection (in other words, a node cannot connect with another vehicle during connecting one vehicle), ${\sum }_{j=1}^J{\sum }_{k=1}^{K_{req,j-1}}({\delta }_{req,k}\left(m\right)+{\xi }_{req,j}\left(m\right))\le 1,\forall m$. $K_{req,j-1}$ is the number of candidate vehicles that can become relaying vehicles within the coverage of $RS{U}_{j-1}$. In addition, because all values in sigma except ${\xi }_{req,j}\left(m\right)$ are fixed, $C_T$ is derived through the sum of values that are defined by ${\xi }_{req,j}\left(m\right)$, which can be zero or one. In addition, if the requester vehicle remains within $RS{U}_j$’s communication coverage at each m, ${\xi }_{req,j}\left(m\right)$ must be 1. The relaying vehicle selection is conducted only outside the coverage of RSUs, where only vehicles that can provide the requested content to $V_{req}$ at each m are considered candidate vehicles for the relaying vehicle. At each m, because only one vehicle is selected among the candidate relaying vehicles, ${\sum }_{k=1}^{K_{req,j-1}}{\delta }_{req,k}\left(m\right)$ cannot be greater than one. Moreover, when there are no candidate vehicles that can provide the requested content to the requester vehicle, ${\sum }_{k=1}^{K_{req,j-1}}{\delta }_{req,k}\left(m\right)$ becomes 0 Based on these constraints, the optimal ${\xi }_{req,j}\left(m\right)$ can be calculated. The difference between $t_{theo}$ and the actual estimated content download delay $t_{est}$ depends on the magnitude of the mobility prediction error with respect to speed. The mobility prediction error for speed $v_{req}$ of the requester vehicle $V_{req}$ at the time of leaving ${RSU}_j$ is as follows:

$$\mathrm{\Delta }{v}_{req}=\left|\begin{array}{c}{v}_{req}\left(j\right)·(1-{\epsilon }_{mob})\end{array}\right|,$$

(13)

where $v_{req}\left(j\right)$ is the velocity of $V_{req}$ within the coverage of $RS{U}_j$ and ${\epsilon }_{mob}$ is an error ratio for the speed of $V_{req}$. Because it has a value of $[-n,1]$, a value of one indicates that the vehicle stops. Because $V_{req}$ will have a different average speed for each interval, the actual estimated speed $v_{req,av}\left(j\right)$ of $V_{req}$ within $RS{U}_j$’s coverage based on ${\epsilon }_{mob}$ are as follows:

$$v_{req,av}\left(j\right)=\left|\begin{array}{c}{v}_{req}\left(j\right)·{\epsilon }_{mob}\end{array}\right|.$$

(14)

To calculate the actual estimated content download delay $t_{est}$, the actual estimated content download distance $m_{est}$ should first be defined because we use the distance $V_{req}$ moves. $m_{est}$ can be defined as follows:

$$\begin{array}{cc}\hfill C_T& =\sum _{m=0}^{m_1}\left({(R_{V2I}^{-1}+l^{-1})}^{-1}·\frac{R_{req,1}\left(t\right)}{v_{req,av}\left(1\right)}\right)\hfill \\ \hfill & +\sum _{j=2}^J\sum _{m=m_1}^{m_{est}}\left(G·R_{V2V}·\frac{{\sum }_{k=1}^{K_{req,j-1}}{P}_{req,k}\left(m\right)}{v_{req,av}^{out}(j-1)}\right.\hfill \\ \hfill & +G·R_{V2I}·\frac{P_{req,j}\left(t\right)}{v_{req,av}\left(m\right)}\left.+(1-G)·{(R_{V2I}^{-1}+l^{-1})}^{-1}·\frac{R_{req,j}\left(t\right)}{v_{req,av}\left(m\right)}\right),\hfill \end{array}$$

(15)

where $R_{req,j}\left(m\right)$ indicates whether ${RSU}_j$ relays the content from the content server to $V_{req}$ after $V_{req}$ moves m meters. $v_{req,av}^{out}\left(j\right)$ is the average speed when $V_{req}$ reaches ${RSU}_{j+1}$ after leaving ${RSU}_j$. G is the guardband ratio of the precached content and has a value of $[0,1]$. $P_{req,j}\left(m\right)$ indicates whether $V_{req}$ receives the precached content through a node j (that is, an RSU or a candidate relaying vehicle) after $V_{req}$ moves m m. $R_{req,j}\left(m\right)$ and $P_{req,j}\left(m\right)$ can also be known in advance because the mobility information of the vehicles is provided to the RSUs. Therefore, the actual connection time between vehicle $V_{req}$ and a candidate relaying vehicle $V_k$ after $V_{req}$ moves $m_x$ m can be estimated by $v_{i,av}^{out}(j-1)\times {\sum }_{m=0}^{m_x}(1/v_{req,av}^{out}(j-1))$ and the location of the vehicles. Based on $m_{e}st$ and $v_{req,av}\left(j\right)$, $t_{est}$ is defined as follows:

$$t_{est}=\sum _{m=0}^{m_{est}}\sum _{j=1}^J\left(\frac{con{n}_{req,j}\left(m\right)}{v_{req,av}\left(j\right)}+\frac{ou{t}_{req,j}\left(m\right)}{v_{req,av}^{out}\left(j\right)}\right),$$

(16)

where $con{n}_{req,j}\left(m\right)$ denotes the connection state between $V_{req}$ and $RS{U}_j$. At m, if $V_{req}$ enters the coverage of $RS{U}_j$, $con{n}_{req,j}\left(m\right)$ is equal to one. Otherwise, $con{n}_{req,j}\left(m\right)$ is zero. $ou{t}_{req,j}\left(m\right)$ represents the state in which $V_{req}$ is within the outage area between $RS{U}_j$ and $RS{U}_{j+1}$. At m, if $V_{req}$ remains within the outage zone between $RS{U}_j$ and $RS{U}_{j+1}$, $ou{t}_{req,j}\left(m\right)$ is one. Otherwise, $ou{t}_{req,j}\left(m\right)$ is zero. Subsequently, by recalculating the actual connection time, $P_{req,j}\left(m\right)$ can be redefined from zero to one or from one to zero. Consequently, the expected reduced delay $dela{y}_{E\_re}(G,{\epsilon }_{mob})$ according to G and ${\epsilon }_{mob}$ can be estimated by the difference between $t_{theo}$ and $t_{est}$, as follows:

$$dela{y}_{E\_re}(G,{\epsilon }_{mob})=t_{theo}-t_{est}.$$

(17)

On a similar principle to the expected reduced delay, we can also calculate the expected reduced backhaul traffic $traffi{c}_{E\_re}(G,{\epsilon }_{mob})$ according to the guardband, which is consumed by precaching the content from both the content server to the RSUs and from the RSUs to the relaying vehicles, and by sending the precached content to $V_{req}$. The $traffi{c}_{E\_re}(G,{\epsilon }_{mob})$ can be obtained from the difference between the theoretical backhaul traffic value, $traffi{c}_{theo}$, and the actual backhaul traffic value ${traffic}_{est}$. Using the current speed of $V_{req}$, the theoretical backhaul traffic was obtained by $m_{theo}$ as follows:

$$\begin{array}{cc}\hfill traffi{c}_{theo}& =\sum _{m=0}^{m_1}\left(H\left(1\right)·{(R_{V2I}^{-1}+l^{-1})}^{-1}·\frac{{\xi }_{req,1}\left(m\right)}{v_{req}}\right)\hfill \\ \hfill & +\sum _{j=2}^J\sum _{m=m_1}^{m_{theo}}\left(H\left(j\right)·R_{V2I}·\frac{{\xi }_{req,j}\left(m\right)}{v_{req}}\right.\hfill \\ \hfill & \left.+H(j-1)·R_{V2V}·\frac{{\sum }_{k=1}^{K_{req,j-1}}{\delta }_{req,k}\left(m\right)}{v_{req}}\right),\hfill \end{array}$$

(18)

where $H\left(j\right)$ is the number of hops between the content server and the ${RSU}_j$. Because it uses the resources of the links between backhaul nodes to obtain the content, the traffic consumption is proportional to the number of hops. For example, if the content needs to be delivered from ${RSU}_{(j-2)}$ to ${RSU}_j$, ${RSU}_{(j-2)}$ first passes the content to ${RSU}_{(j-1)}$ via the backhaul link and ${RSU}_{(j-1)}$ delivers the received content back to ${RSU}_j$. Thus, it consumes twice the amount of backhaul traffic.

The actual estimated traffic $traffi{c}_{est}$ is also calculated by $m_{est}$, as follows:

$$\begin{array}{cc}\hfill & traffi{c}_{est}=\sum _{m=0}^{m_1}\left(H\left(1\right)·{(R_{V2I}^{-1}+l^{-1})}^{-1}·\frac{R_{req,1}\left(t\right)}{v_{req,av}\left(1\right)}\right)\hfill \\ \hfill & +\sum _{j=2}^J\sum _{m=m_1}^{m_{est}}\left(H(j-1)·G·R_{V2V}·\frac{{\sum }_{k=1}^{K_{req,j-1}}{P}_{req,k}\left(m\right)}{v_{req,av}^{out}(j-1)}\right.\hfill \\ \hfill & +H\left(j\right)·G·R_{V2I}·\frac{P_{req,j}\left(m\right)}{v_{req,av}\left(j\right)}\left.+H\left(j\right)·(1-G)·{(R_{V2I}^{-1}+l^{-1})}^{-1}·\frac{R_{req,j}\left(m\right)}{v_{req,av}\left(j\right)}\right).\hfill \end{array}$$

(19)

As a result, by using $traffi{c}_{theo}$ and $traffi{c}_{est}$ based on $m_{theo}$ and $m_{est}$, we can formulate the expected reduced backhaul traffic ${traffic}_{E\_re}(G,{\epsilon }_{mob})$ based on G and ${\epsilon }_{mob}$ by the difference between $traffi{c}_{theo}$ and $traffi{c}_{est}$ as follows:

$${traffic}_{E\_re}(G,{\epsilon }_{mob})=traffi{c}_{theo}-traffi{c}_{est}.$$

(20)

To address guardband G, G can be added to compensate for the increased delay and backhaul traffic owing to ${\epsilon }_{mob}$. However, we cannot determine ${\epsilon }_{mob}$ for the prediction of the vehicle’s mobility in advance. The position of each RSU and the characteristics of each requester vehicle shall be applied to effectively predict ${\epsilon }_{mob}$ and appropriately adjust the size of G. Thus, we evaluated the performance of the proposed scheme by adding G through our simulations in Section 5.4. The delay in downloading the content may depend on the characteristics of the content requested by $V_{req}$. The traffic available to $V_{req}$ may also be limited according to the communication service provided by the RSUs. Because there is a trade-off between the delay and the traffic, if one of them is limited, we can find the size of G, which can optimize the other one.

5. Performance Evaluation

In this section, we compare the performance of the proposed scheme with that of the existing schemes. First, we describe the simulation model and scenario implemented in our simulations. Next, we evaluated the performance of the proposed scheme and that of the existing schemes through simulation results conducted in various environments.

5.1. Simulation Model and Scenario

We employed simulations of NS3 [33] to evaluate the performance of the proposed scheme and the existing schemes in various environmental variables. We simulated requests for video content in the Center for Brooklyn History using NS3.

Table 3. Simulation Parameters.

Parameters	Value
link latency	10 ms
radio channel rate	54 Mbps
backhaul rate	1 Gbps
distance between RSUs	[1.6, 4] km
vehicle density	[25, 250] per km${}^2$
size of the content catalog	10
exponent of content popularity	0.75
chunk size	25 kbytes
content size	[500, 3500] MB
vehicle speed	[10, 120] km/h
V2I Communication range	800 m
V2V Communication range	200 m
vehicle cache storage	512 GB
RSU cache storage	1 TB
prediction error	[0,1]
G guardband	[0,1]

lists the simulation parameters used. In the network area of 5 km × 5 km, 25 RSUs are located at the intersections, and each RSU has an 800 m-radius circle as its coverage. A total of 100 vehicles per 1 km${}^2$ are randomly distributed on the network at the beginning of the simulations, and they move on the roads of the network according to the RoutesMobilityModel [34], which provides traces of vehicles from Google Maps Platform using the API key. To improve the accuracy of our simulations, we increased the granularity to one second by linear interpolation. We also used this trace to extract the necessary mobility statistics for our model. The wireless resource includes four 10 MHz channels, and the transmission rate is obtained from the IEEE 802.11p standard [35], which is provided by default in NS3. We set content popularity according to Zipf’s law [36].

We compared the proposed scheme with three existing schemes. (1) The first scheme is the basic CCVN scheme, which did not use precaching to provide the requested content to $V_{req}$. (2) The second scheme is the only RSU scheme in which RSUs precache the content to provide it to $V_{req}$. Because the only RSU scheme did not use other vehicles as relaying vehicles, they did nothing to provide content to $V_{req}$. (3) The third scheme is a random selection scheme that provided the content to $V_{req}$ using precaching in both RSUs and relaying vehicles. However, the random selection scheme randomly selects relaying vehicles, which is different from the proposed scheme. We used four metrics to compare the performance of the proposed scheme and the three existing schemes as follows:

• The content download delay [s], the time in which $V_{req}$ receives the entire amount of the content from the RSUs and the relaying vehicles;
• The backbone traffic except precached traffic [MB]: It is the total amount of backhaul traffic consumed to provide the content to $V_{req}$ using a backbone;
• The precached traffic by the next RSUs [MB]: It is through the prediction, the total amount of traffic consumed by the next RSUs to precache the remaining amount of content that $V_{req}$ has to receive when the current RSU cannot provide the entire amount of content;
• The RSU usage ratio, $U_c\in$ [0,1]: It is the proportion of the amount of content provided from RSUs among the total amount of requested content. The time slot consumed by the RSU to provide content to $V_{req}$ cannot be used for other vehicles. Therefore, if the RSU usage ratio is small, the time slot that other vehicles can use to receive the content will increase. In addition, RSUs benefit from a storage utilization perspective because they reduce the amount of content that needs to be precached and held;
• The hit ratio ∈ [0,1]: It is the proportion of the content used by $V_{req}$ among the total amount of precached content at both RSUs and relaying vehicles. Some portion of the content that is precached at the RSUs and relaying vehicles may not be provided to $V_{req}$ because of the limited connection between $V_{req}$ and each of them. Even if they are not provided to $V_{req}$, they consume the storage of the RSUs and relaying vehicles and are eventually removed. This causes wasted backhaul traffic from the content server and wasted storage of RSUs and relaying vehicles. Therefore, a high hit ratio implies that storage and traffic are saved.

We evaluated the performance from three different perspectives to compare the proposed scheme with existing schemes. (1) The first perspective concerns the various environmental factors in the network because they can significantly influence performance. As influential environmental factors, we considered the density of vehicles and the distance between the RSUs in our performance evaluation. Vehicle density refers to the number of vehicles within the simulation area. This is implemented by adjusting the number of vehicle trajectories obtained from NS3 using the RoutesMobilityModel. A high density of vehicles is considered to represent a busy urban situation, whereas a low density of vehicles is considered to represent a rural situation. The distance between the RSUs is the distance between two neighboring RSUs. By adjusting the number of RSUs, we varied the distance between RSUs in the simulation area. If the number of RSUs decreased, the distance between the RSUs increased within the simulation area. In this study, the distance between the RSUs affected the size of the outage zone between them. (2) The second perspective concerns the characteristics related to requester vehicles because they should be supported in the view of services. We considered the size of the requested content and the speed of $V_{req}$ in our performance evaluation. The size of the requested content refers to the size of the content that requester vehicles require to download from the content servers. Usually, users in requester vehicles can request content of various sizes. To vary the size of the contents, we adjusted the number of fixed-size chunks that are consistent with the requested content. A larger size of the requested content increases the time required to complete the download. Thus, while receiving the content, requester vehicles that request larger content should pass more RSUs and outage zones. The speed of $V_{req}$ is the average speed of requester vehicles in the network. They can have variable average speeds depending on the driving style of their drivers. We varied the average speed of the requester vehicles by adjusting their speeds or by appropriately compressing their trajectories from a time perspective. If the average speed of the requester vehicles is higher, they pass faster RSUs and outage zones. (3) The third perspective is the accuracy of vehicle mobility prediction. Because the existing schemes did not consider errors in the prediction of vehicle mobility, they should request un-precached chunks because of the prediction errors, to the content server again. The un-precached chunks are inefficient in content download because they cannot be delivered directly to $V_{req}$. The probability of requesting un-precached chunks depends on the error rate of vehicle mobility prediction. The proposed scheme uses guardbands to compensate for errors in the prediction of the vehicle mobility. Therefore, we evaluated the performance according to the size of the guardband based on the error rate of vehicle mobility prediction.

5.2. Performance for Various Environmental Factors

In Figure 2, we evaluate the performance of the schemes by using the density of vehicles. Figure 2a depicts the effect of vehicle density on the time it takes for $V_{req}$ to receive all the requested content. For the proposed scheme and the random selection scheme, a higher density of vehicles increases the probability of providing additional requested content because there are many vehicle candidates to deliver the content to $V_{req}$ outside the RSU communication range. Therefore, the delay is reduced because the remaining amount of content to be received in the next RSU is reduced. Furthermore, the delay is reduced because the proposed scheme selects better candidates than the random-selection scheme. Conversely, the basic CCVN and RSU schemes were not affected by the density of the vehicles because they did not use relaying vehicles. Even though the basic CCVN scheme does not use a precache, there is a disadvantage in terms of the transmission speed, which consumes the most time.

In Figure 2b, we evaluate the effect of vehicle density on the consumed backhaul traffic, except for precached traffic. The basic CCVN scheme consumes the resources of the links between the current RSU and the content server because it takes the requested content from the content server and provides it to $V_{req}$. Therefore, the performance is severely affected by the number of hops in terms of transmission speed. Only the RSU scheme performed better than the basic CCVN scheme because it precaches the content in the next RSU. However, these two schemes are not affected by vehicle density. The random selection scheme has improved performance because more relaying vehicles are available when the density of the vehicles is high. The proposed scheme exhibits the best performance because it can select the optimized relaying vehicles. Because the area between the current and next RSU is limited, the performance of the proposed scheme converges when there is a sufficient number of candidates.

Figure 2c shows the precaching traffic according to the vehicle density. In the proposed scheme, a higher density of vehicles allows the selection of more optimal relaying vehicles, thereby reducing the size of the content that the next RSU should precache. This leads to a reduction in precaching traffic. In the random selection scheme, a lower density of vehicles increases the probability of using the worst or no candidate for the relaying vehicles; therefore, a larger amount of content should be precached at the next RSU. However, the RSU scheme is not affected by vehicle density. Furthermore, as the basic CCVN scheme does not use precaching, there is no precaching traffic.

Figure 2d shows the percentage of RSUs used to provide content according to the density of the vehicle. The basic CCVN and RSU schemes depend only on RSUs for content delivery because they do not use vehicles as relay nodes. The random selection scheme improves performance because the probability of selecting a better relaying vehicle at a higher density of vehicles increases. The proposed scheme effectively reduced the rate of dependence on RSUs because optimal relaying vehicles can be selected at a higher density of vehicles.

In Figure 3, we evaluated the performance according to the density of the RSUs by adjusting the distance between the RSUs. Figure 3a depicts the effect of the density of RSUs on the content download delay. In the basic CCVN scheme and the only RSU scheme, because vehicles are not used as relay nodes, the content download delay increases as the time that $V_{req}$ reaches the next RSU increases when the distance between RSUs is long. Additionally, because the basic CCVN scheme is inefficient in terms of the transmission rate, it has the longest delay. However, in the proposed scheme and the random selection scheme, because a sufficient number of relaying vehicles are used to provide the content for $V_{req}$ outside the RSUs’ communication range, it is less affected by the density of RSUs. Because the random selection scheme does not select the optimal relaying vehicles, $V_{req}$ must receive the remaining portion of the content from the next RSU. Hence, on average, the proposed scheme has less delay than the random-selection scheme.

Figure 3b shows the effect of the density of RSUs on traffic that relays the content directly from the content server to $V_{req}$, except for the traffic consumed by RSUs for precaching. The relayed traffic consumed by the RSU to relay content directly from the content server to $V_{req}$ has a slow transmission rate, consuming more links than the RSU directly delivering the precached content to the vehicle. Because the content cannot be precached in the first RSU, all schemes relayed traffic from the content server. In particular, the basic CCVN scheme provides the entire content by relaying it from the content server to the vehicle as it does not use precaching. In the case of the basic CCVN scheme and the only RSU scheme, the backhaul traffic generated is not related to the distance between RSUs, because the content can only be provided within the RSU communication range. However, if the next RSU is far-off, the RSU consumes less traffic to relay directly from the content server to $V_{req}$ because the proposed scheme and random selection scheme precache most of the content on the relaying vehicles. Because the proposed scheme prepares more content for optimized relaying vehicles, the relayed traffic is the least.

Figure 3c presents the traffic consumed by RSUs to precache the content according to the density of the RSUs. The basic CCVN scheme does not use precaching. The RSU scheme is not affected by the distance between the RSUs because $V_{req}$ only receives the content within the RSU communication range. However, in the proposed and random selection schemes, the traffic consumed by the precache to be borne by RSUs is reduced because $V_{req}$ receives most of the content via V2V communication, except for the first RSU. With the optimal candidate selection algorithm, the proposed scheme significantly relieves the burden of the next RSUs.

In Figure 3d, we present the proposed scheme and the random selection scheme for mitigating the burden on the RSU. Because these two schemes provide almost all of the content to $V_{req}$ via V2V communication if the distance between RSUs is large, this reduces the amount of content that the RSUs have to support. Furthermore, the proposed scheme is more effective than other schemes because it uses a larger number of available relaying vehicles.

5.3. Performance Based on Characteristics of Requester Vehicles

In Figure 4, we evaluate the performance of the proposed scheme according to various sizes of content because the user can request various types of content. Figure 4a shows that the content download delay is proportional to the size of the requested content. Because the transmission rate is limited, the delay in receiving the entire content increases in all schemes when the size of the requested content is large. In the basic CCVN scheme, because the entire requested content is relayed to $V_{req}$ from the content server, it is the most inefficient in terms of transmission rate. Therefore, this scheme has the greatest delay in downloading the content. Because only the RSU scheme receives the requested content from the RSU, additional delays are accumulated as they move outside the RSUs’ communication range. However, the proposed scheme and the random selection scheme consumed less delay because they can provide the content when $V_{req}$ is not only in the RSUs’ communication range but also out of the range. The random selection scheme, which randomly selects relaying vehicles, is inefficient compared with the proposed scheme.

In Figure 4b, we evaluate the impact of the increase in the size of the requested content on backhaul traffic. Because the backhaul link consumed increases proportionally to the number of hops between the content servers and the next RSUs, the traffic consumption is larger than the size of the requested content. All schemes, except the basic CCVN scheme, consumed the most backhaul traffic when the requested content was provided in the first RSU. In addition, in these schemes, additional traffic increases with the difference between the size of the precached content and the actual received content. Because the RSU scheme uses only the RSU, it consumes more backhaul traffic than the two schemes using relaying vehicles. On the other hand, the basic CCVN scheme receives all chunks of content from the content server through relaying. Therefore, it consumes the most relayed traffic.

Figure 4c shows the relationship between the size of the requested content and precaching traffic. To precache the content, the next RSU takes chunks of the content from the content server. Hence, the consumed traffic relies on the number of hops between the RSU and the content server. The basic CCVN scheme does not use a precache. In the case of the RSU scheme, most of the traffic is consumed because all chunks of the content, except the portion of the received content from the first RSU, are provided to $V_{req}$ by the next RSUs precaching the content. Because the other two schemes use relaying vehicles to precache the content, the traffic that RSUs are burdened with precaching the content is reduced.

Figure 4d shows the burden of RSUs according to the size of the requested content. Because the proposed scheme selects optimized relaying vehicles, the RSUs’ burden is reduced the most. In comparison, the random selection scheme that selects any relaying vehicle cannot guarantee that $V_{req}$ is served with maximum efficiency outside the RSUs’ communication range. Thus, there is a greater burden on the RSUs than in the proposed scheme. The size of the requested content that can be provided is limited because $V_{req}$ has available time owing to the mobility of the vehicle outside of the RSUs’ communication range. Therefore, a sufficient size of the requested content converges to alleviate the burden of the RSUs.

In Figure 5, we also evaluate the performance of various user characteristics. Figure 5a shows the content download delay according to the speed of the vehicle. If the speed of the vehicle is low, the next RSU and $V_{rel}$ do not have to precache the content because $V_{req}$ has sufficient dwell time to receive the entire content from the content server in the first RSU. Otherwise, if the speed of the vehicle is high, the number of content chunks not received by the first RSU increases. Therefore, the content download delay is increased because $V_{req}$ requires time to reach the next RSU to receive the rest of the content. Subsequently, the delay continues to decrease because the time remaining in the outage zone decreases with increasing speed before additional RSUs are required. Because only the RSU scheme and the basic CCVN scheme that do not use the relaying vehicles are provided with content only through the RSU to $V_{req}$, the content download delay in both schemes depends more on the time $V_{req}$ required to reach the next RSU than in the other two schemes. The faster speed of the requester vehicle can decrease the download delay because it can reduce the time within the outage zone. However, at some speed of the requester vehicle, the increased delay due to the decreased time that the requester vehicle can receive the requested content within the coverage of RSUs has more impact than the decreased delay by reduced time within the outage zone. That is why the content download delay of the two schemes significantly fluctuated. The RSU scheme has a shorter delay than the basic CCVN scheme because the next RSU precaches the content. In the random selection scheme, the delay is shorter because it is provided by the randomly selected $V_{rel}$ in the outage zone. The proposed scheme has the least delay because it selects the optimal $V_{rel}$.

Figure 5b shows the impact of backhaul traffic, excluding precaching traffic, on the speed of $V_{req}$. The backhaul traffic, except for the precaching traffic, is the backhaul traffic consumed by the RSU to relay content from the content server to $V_{req}$. Because relaying the content from the content server to $V_{req}$ is inefficient in terms of the transmission rate, small backhaul traffic indicates good performance. First, in terms of this indicator, the basic CCVN scheme is unaffected by mobility prediction error because it does not use precaching. In the RSU scheme, only the RSU precaches the content; therefore, it outperforms the basic CCVN scheme. In the case of the random selection scheme, inefficient traffic is consumed less than in the RSU scheme because $V_{rel}$ precaches the content. The proposed scheme has the smallest backhaul traffic because $V_{rel}$ precaches the maximum available content size in the outage zone.

Figure 5c shows the relationship between the speed of $V_{req}$ and the backhaul traffic consumed by the RSU for precaching. The basic CCVN scheme does not precache the content. Because the proposed scheme uses optimized $V_{rel}$, the RSU has the least traffic to precache the content. Compared with the proposed scheme, the random selection scheme performs poorly because it randomly selects $V_{rel}$. In the RSU scheme, the next RSU precaches the entire content, except for some of the content that is relayed by the first RSU from the content server to the vehicle. Thus, in this scheme, RSUs consume the most backhaul traffic to precache the content.

Figure 5d depicts the trends in the involvement of RSUs in providing content according to the speed of the vehicle. $V_{req}$ is provided by the RSU in only two schemes that do not use $V_{rel}$. Because the proposed scheme uses the optimal $V_{rel}$, it uses the least number of RSUs in terms of providing content to $V_{req}$. In the case of the random selection scheme, more RSUs are used than in the proposed scheme, because $V_{rel}$ is chosen randomly. In these two schemes using $V_{rel}$, the performance converges as the connection time with other vehicles, and the dwell time in the outage zone is reduced if $V_{req}$ is too fast.

5.4. Performance for Accuracy of Vehicle Mobility Prediction

In Figure 6, we evaluated the performance according to the size of the guard band applied to compensate for the difference between the predicted and actual mobilities of the vehicle. Figure 6a presents the content download delay caused by the prediction error when the guard band is applied. The basic CCVN scheme is not affected by prediction errors in vehicle mobility, because it does not use precaching. Only the RSU scheme has an increased size of the content taken from the former RSU or content server owing to prediction error. The two schemes using relaying vehicles take more time to download the entire content, as the size of the content provided by the relaying vehicles decreases if the prediction error of the vehicle mobility is large. However, as the size of the guard band increases, performance degradation from a delay perspective is mitigated.

Figure 6b depicts the required backhaul traffic, except for precaching, using a guard band to mitigate performance degradation owing to the mobility prediction error. In the basic CCVN scheme, because the RSU does not precache the requested content using the prediction of vehicle mobility, it provides the requested content to the vehicle from the content server via relaying. In the other schemes, if the prediction error increases, backhaul traffic is consumed as much as it differs from the prediction. Because the proposed scheme uses optimized relaying vehicles to provide content to $V_{req}$, it consumes the lowest backhaul traffic. However, because accurate prediction is impossible in a real environment, we use a guard band to cover the prediction error. This reduces the amount received using precaching. Therefore, as the size of the additional content to be received increases, so does the size of the guardband prepared to compensate for the error. In addition, if the size of the guard band is increased to cover more prediction errors, the traffic required for preparing the guard band is further increased.

Figure 6c shows the traffic for precaching owing to the use of the guard band. In all the schemes, if the prediction is perfect, the next RSU precaches the appropriate size content requested by the vehicle. The mobility prediction error is caused by predicting faster or slower than the actual speed of $V_{req}$. Because $V_{req}$, which is faster than expected, causes a smaller dwell time than the actual dwell time, $V_{req}$ is not fully provided with precached content. $V_{req}$, which was slower than the actual speed, had a longer dwell time. The RSU precaches a smaller-sized content, consuming less traffic than the actual size of the content that can be received by vehicles with longer dwell times. Thus, if the mobility prediction is incorrect, the traffic consumed by precaching decreases. Because the proposed scheme uses optimized relaying vehicles, the least amount of traffic is consumed to perform the precaching. It consumes more traffic to prepare the guard band by applying it to cope with prediction errors.

Figure 6d presents the RSU usage ratio with the adjustment of the guard band. The two schemes that did not use relaying vehicles provided content to $V_{req}$ using only the RSU. The proposed scheme uses less RSU than the random selection scheme, which randomly selects relaying vehicles. With a large mobility prediction error, the guardband can cover the error to reduce the RSU usage ratio by utilizing the guardband contained in the relaying vehicles. If the mobility prediction error exceeds the size covered by the guard band, the performance improvement converges.

In Figure 7, we evaluate the hit ratio for the precached content by adding a guard band. The basic CCVN scheme does not use precaching. If the mobility prediction error is small, the hit ratio is more affected by the connection time between $V_{req}$ and $V_{rel}$ than by the dwell time on the RSU. Therefore, the hit ratio in the RSU scheme was higher than that in random selection in that case. Otherwise, if the mobility prediction error is large, the hit rate in the RSU scheme decreases dramatically because of the large impact of the dwell time on the RSU. The proposed scheme had the highest hit ratio because of the selection of optimized relaying vehicles. Furthermore, the large size of the guard band alleviates the reduced hit ratio owing to the mobility prediction error. This indicates that most of the traffic consumed was directed to $V_{req}$.

6. Discussion

In this section, we discuss several issues related to the cooperative content precaching scheme and its viability in a practical context.

6.1. Security of Privacy

In the proposed scheme, the trajectory and mobility information of vehicles are shared with RSUs and other vehicles to achieve better precaching performance. In addition, the content that a vehicle wishes to download is cached or precached distributively to the RSUs or other vehicles. In this case, the requester vehicle’s private information, which includes the mobility and preference for the content, is disclosed to others. Because disclosed information about the requester vehicle can be used to attack or threaten the user, it must be protected. Therefore, many studies have proposed protection schemes to hide private information, while the precaching service is served to the requester vehicle using blockchain or other technologies [37,38]. Reliable precaching services can only be used when safety is guaranteed. Thus, when the proposed scheme uses the proper security protocol for precaching, it can achieve reliable service while maintaining high network performance.

6.2. Energy Consumption

In vehicular networks, saving energy is one of the most important issues to achieve a longer driving time owing to the limitation of the battery. In the proposed scheme, almost all the computing processes to precache the content are conducted at RSUs. However, the relaying vehicle spends the energy required to reach the requested content and provide it to the requester vehicle. Therefore, several studies have been conducted to reduce the energy consumed in precaching the requested content [39,40,41,42]. To save energy, it is possible to increase the delay in content download and backhaul traffic used to serve the precaching service [40]. Thus, this is a very sensitive issue for reducing the consumed energy to precache the content at RSUs or other vehicles. When a proper energy-saving method is considered in the proposed scheme, the scheme can be improved in terms of energy and other network performances.

6.3. Combination with 5G Technology

For viability in the practical context of a precaching scheme, it is necessary to consider 5G or 6G technologies. To provide precaching service to vehicles in 5G, numerous studies have been conducted [43,44]. Because many parameters and environments have become standards for 5G, these must be considered when conducting a precaching service in a real scenario. In 5G technology, many modules are provided for each purpose. These modules can be considered to improve the network performance, such as delay, traffic, or security problems in the proposed scheme.

7. Conclusions

In this study, we propose a cooperative content precaching scheme based on the mobility information of vehicles to enhance the performance of content downloads in ICVNs. In contrast to the existing schemes, our scheme cooperatively used both vehicles and RSUs for the precaching content. For content precaching based on the mobility information of vehicles, our scheme selected both the optimal vehicle for relaying content in the outage zone and the next RSU to download the content in the coverage of the RSU. Our scheme calculated the optimal content precaching amount for each optimal relaying vehicle and the next downloading RSU using a mathematical model that used both the dwell time of vehicles in an RSU and contact time between vehicles. To compensate for the error of the vehicle mobility prediction to determine both the dwell and contact times, our scheme added a guard band to the optimal content precaching amount. For mobility prediction errors, the guard band is calculated with the error rate of both the dwell and contact times, and it is adjusted in the trade-off between the expected reduced delay and backhaul traffic. We conducted simulations to compare the performance of our scheme with the performances of existing schemes from three perspectives: Various environmental factors, characteristics related to requester vehicles, and accuracy of vehicle mobility prediction. Simulation results verify that our scheme achieves better performance than existing schemes in terms of the content download delay, backbone traffic, precaching traffic, RSU usage ratio, and hit ratio. In future work, we will consider other vehicles or drones that have already cached the requested content, as providers without using additional backhaul traffic. In addition, using an additional server, we can employ a machine learning method to improve the performance of the proposed scheme.