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

: 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 trafﬁc 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


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]. 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.

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 shows notations for selecting the optimal relaying vehicle. Table 1. Notations for selecting the optimal relaying vehicle.

Notation Description
RSU j j-th roadside unit (RSU), where j ∈ {1, · · · , J} V i i-th vehicle, where i ∈ {1, · · · , I} V req The requester vehicle V rel The selected optimal relaying vehicle t max_i The maximum time that V i can relay the content to V req within the outage zone t D req The downloadable time for providing the requested content to V req within the coverage of RSU j T D i The downloadable time for precaching the requested content to V i within the coverage of RSU j T R i The relaying time of V i for providing the precached content to V req within the outage zone x EX j The coverage diameter of RSU j

Notation Description
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 RSU j C DV i The downloadable amount of the requested content for precaching it to V i within the coverage of RSU j C RV i The relaying amount of the content for providing it to V req within the outage zone 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 RSU j to V i within the coverage of RSU 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 RSU j and RSU j+1

Checking the Necessity for Precaching
If a vehicle traveling on the road within the coverage area of RSU j wants to download the content, it sends a request message to RSU j , where j = {1, · · · , J}. When RSU 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 RSU j within its coverage. t D req can be denoted as the time at which V req is expected to leave RSU j 's coverage, and it can be calculated based on the velocity and the location of V req as follows: where x EX j is the communication coverage of the RSU j , x req is the location of V req , and v req is the velocity of V req , respectively. Based on t D req , RSU j calculates the downloadable amount C R of the requested content that can be provided to the V req within RSU j 's coverage by using the transmission rate of the I2V communication, as follows: where R I2V is the transmission rate of the I2V based on IEEE 802.11p WAVE [31]. RSU j then decides whether the requested content has to be precached by comparing C R with C T . If C T ≤ C R , it denotes that RSU j can provide all of the requested content to V req before V req leaves the communication coverage of RSU j , where C T is the size of the requested content by V req . In this case, RSU j immediately provides the requested content to V req . Otherwise, it denotes that RSU j does not have sufficient time to provide all of the requested content to V req at time t D req . Thus, RSU 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 RSU j . The relaying vehicle, V rel , provides the remaining amount of content to V req outside the communication coverage of RSU j .

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 RSU 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, RSU 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 , RSU j calculates the amount of the content that can be relayed by each candidate vehicle that is managed by the table of RSU j within its coverage. Then, RSU 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, RSU j uses the beacon messages that include the mobility information of vehicles that remain in the coverage of RSU j . Based on the location and velocity of each candidate vehicle, RSU j calculates each candidate vehicle's downloadable time and the downloadable amount of the content from RSU 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, RSU j selects the optimal relaying vehicle as V rel and its relaying amount as C V . Therefore, RSU 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 RSU j 's coverage.

The Downloadable Time and Amount
To determine the optimal relaying vehicle V rel , RSU j first has to know the downloadable time and amount of the content of each candidate vehicle V i within RSU j 's coverage. Similarly, to obtain T D req , the downloadable time of each candidate vehicle can be calculated based on x EX j . However, when V req leaves the coverage of RSU j , the content must be relayed to V req from the relaying vehicle. Therefore, RSU j can obtain the downloadable time of each candidate vehicle from RSU j in order to provide it to V req , as follows: where x i and v i are the position and speed of V i , respectively. Then, RSU j calculates the downloadable amount C DV i of the content that the V i can precache from RSU j during the time T D i based on the transmission rate of I2V as follows: 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 DV 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.

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, RSU j must first calculate the connection time between V req and each V i . However, when V req enters the next RSU, that is, RSU j+1 's coverage, the download from the RSU 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 RSU j and RSU 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: 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: 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 RSU j+1 after passing through the outage zone. Using T R i , RSU 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: where R V2V is the transmission rate of the V2V communications that is based on IEEE 802.11p WAVE [31]. RSU 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 RSU j and can be relayed to V req from V i .

Selection of the Optimal Relaying Vehicle
To select the optimal relaying vehicle, RSU 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: The set Set(V i ) is saved in the RSU j 's table with the mobility information of V i . Based on Set(V i ), RSU 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 RSU 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, RSU j selects the minimum value between the two values as the practical delivery amount C PDV i of the content, as follows: Thus, C PDV 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 RSU j+1 . Then, RSU j can determine the optimal relaying amount C V by selecting the optimal relaying vehicle that has the largest C PDV i , as follows: 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 RSU 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 V1 rel is selected as the optimal relaying vehicle for V1 req , because V1 req wants to download the content, RSU j provides the C R of the requested content to V1 req and the C V of the requested content to V rel . Then, in the case of V2 rel , which is selected as the optimal relaying vehicle for V2 req and downloaded C V of the content, it provides the content to V2 req during the outage zone.

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, RSU j judges that it is not sufficient for the content that can be provided before V req reaches RSU j+1 . In this case, RSU j sends a message to make the next RSU, that is, RSU j+1 precaches the remaining amount of the requested content. The amount C P of the content that must be precached at RSU j+1 can be easily determined based on C T , C R , and C V as follows: Therefore, the message that RSU j sends to RSU 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 RSU 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 RSU j+1 . For example, as shown in Figure 1, if V3 rel is selected as the optimal relaying vehicle for V3 req because V3 req has to receive a greater amount of the requested content, RSU j provides the C R of the requested content to V3 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 EX j , the requester vehicle V req 's the location x req and the velocity v req Output: Action of the RSU j for i ∈ 1, · · · , n do 8: if C PDV i > max then 10: max = CPDV i [Providing C R -sized c to V req ] 16:

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 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. Table 2. Notations for the calculation of the guardband.

Notation
Description The expected reduced delay value by G of guardband and ε 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 ξ req,j (m) One or zero value whether RSU j provides the requested content to V req after V req moves a distance of m meters δ req,k (m) One or zero value whether V k provides the precached content to V req after V req moves a distance of m meters ε mob The mobility error ratio of the vehicles v req (j) The expected speed based on v req at the coverage of RSU j v req,av (j) The average expected speed based on v req and ε mob at the coverage of RSU j v out req,av (j) The average expected speed based on v req and ε mob at the outage zone between RSU j and RSU j+1 v out i,av (j) The average expected speed based on v i and ε mob at the outage zone between RSU j and RSU j+1 R req,j (m) One or zero value whether RSU j relays the requested content to V req after V req moves a distance of m meters P req,k (m) One or zero value whether V k provides the precached content to V req after V req moves a distance of m meters conn req,j (m) One or zero value whether V req and RSU j are connected after V req moves a distance of m meters out req,j (m) One or zero value whether V req stays within the outage zone between RSU j and RSU j+1 after V req moves a distance of m meters tra f f ic E_re (G, ε mob ) The expected reduced traffic by G of guardband and ε mob of mobility error ratio tra f f ic theo The theoretical traffic value in ideal situation tra f f ic est The actual estimated traffic value that is obtained by the predicted situation

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.

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 .

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 delay E_re (G, ε 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 −1 req , the size at which V req receives the requested content from an RSU is R V2I × v −1 req . The first RSU, RSU 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 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: where ξ req,j (m) denotes whether RSU j provides the requested content to V req after V req moves a distance of m m. If RSU j provides the requested content to V req after V req moves m m, ξ req,j (m) is one. Otherwise, ξ req,j (t) is zero. R V2I is the transmission rate between an RSU and a vehicle. l is the transmission rate of backhaul links. δ req,k (m) indicates whether V rel communicates with V req after V req moves m m. ξ req,j (m) and δ req,k (m) can be either zero or one. m 1 is the distance at which V req reaches the end of the RSU 1 's coverage. To calculate t theo , ξ req,j (m) and δ req,k (m) 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 RSU 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 RSU 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), ∑ J j=1 ∑ K req,j−1 k=1 (δ req,k (m) + ξ req,j (m)) ≤ 1, ∀m. K req,j−1 is the number of candidate vehicles that can become relaying vehicles within the coverage of RSU j−1 . In addition, because all values in sigma except ξ req,j (m) are fixed, C T is derived through the sum of values that are defined by ξ req,j (m), which can be zero or one. In addition, if the requester vehicle remains within RSU j 's communication coverage at each m, ξ req,j (m) 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, ∑ K req,j−1 k=1 δ req,k (m) cannot be greater than one. Moreover, when there are no candidate vehicles that can provide the requested content to the requester vehicle, ∑ K req,j−1 k=1 δ req,k (m) becomes 0 Based on these constraints, the optimal ξ req,j (m) 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: where v req (j) is the velocity of V req within the coverage of RSU j and ε 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 (j) of V req within RSU j 's coverage based on ε mob are as follows: 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: where R req,j (m) indicates whether RSU j relays the content from the content server to V req after V req moves m meters. v out req,av (j) 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 (m) 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 (m) and P req,j (m) 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 out i,av (j − 1) × ∑ m x m=0 (1/v out req,av (j − 1)) and the location of the vehicles. Based on m e st and v req,av (j), t est is defined as follows: where conn req,j (m) denotes the connection state between V req and RSU j . At m, if V req enters the coverage of RSU j , conn req,j (m) is equal to one. Otherwise, conn req,j (m) is zero. out req,j (m) represents the state in which V req is within the outage area between RSU j and RSU j+1 . At m, if V req remains within the outage zone between RSU j and RSU j+1 , out req,j (m) is one. Otherwise, out req,j (m) is zero. Subsequently, by recalculating the actual connection time, P req,j (m) can be redefined from zero to one or from one to zero. Consequently, the expected reduced delay delay E_re (G, ε mob ) according to G and ε mob can be estimated by the difference between t theo and t est , as follows: On a similar principle to the expected reduced delay, we can also calculate the expected reduced backhaul traffic tra f f ic E_re (G, ε 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 tra f f ic E_re (G, ε mob ) can be obtained from the difference between the theoretical backhaul traffic value, tra f f ic theo , and the actual backhaul traffic value tra f f ic est . Using the current speed of V req , the theoretical backhaul traffic was obtained by m theo as follows: where H(j) 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 tra f f ic est is also calculated by m est , as follows: As a result, by using tra f f ic theo and tra f f ic est based on m theo and m est , we can formulate the expected reduced backhaul traffic tra f f ic E_re (G, ε mob ) based on G and ε mob by the difference between tra f f ic theo and tra f f ic est as follows: To address guardband G, G can be added to compensate for the increased delay and backhaul traffic owing to ε mob . However, we cannot determine ε 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 ε 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.

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.

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 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 RoutesMobil-ityModel [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 ∈ [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.

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.

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.

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 .

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

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.

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.

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.

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.

Conflicts of Interest:
The authors declare no conflict of interest.