# Content Downloading with the Assistance of Roadside Cars for Vehicular Ad Hoc Networks

Authors: Haigang Gong; Lingfei Yu
Journal: Mobile Information Systems
 (2017)

---

## Abstract

Plenty of multimedia contents such as traffic images, music, and movies pose great challenges for content downloading due to the high mobility of vehicles and intermittent connectivity for vehicular ad hoc networks. Roadside units or APs can improve the efficiency of content downloading but with the cost of large investments. In this paper, an efficient content downloading scheme is proposed with the assistance of parking clusters, which are formed by roadside parked cars. After receiving the downloading request, the parking clusters, which the downloader will travel through according to the estimated trajectory, will make a download scheduling for the downloader. Then the downloader acquires the content chunks while it drives through the parking clusters. Simulation results show that the proposed scheme achieves better performance than intervehicle approach and RSU based approach.


---

## Body

## 1. Introduction

Vehicular ad hoc networks have been envisioned to be promising in many applications such as road safety and the intelligent transportation system (ITS). To facilitate road safety and enjoyable trip, there is a large amount of multimedia in the network, such as traffic image, surveillance video, music, and movie provided by the content provider. One of the most import requirements for VANETs is to distribute these multimedia-rich contents to the mobile vehicles.However, content downloading in VANETs poses great challenges due to the short radio communication, dynamic topology, lack of bandwidth, intermittent connectivity, and high mobility of VANET. In the early days, a vehicle can request the content from the source directly with the Internet interface, but it achieves poor performance for the narrow bandwidth. With the development of broad bandwidth technologies such as WiMax and 4G, a vehicle has sufficient bandwidth to access the Internet, but with expensive accessing fee. In vehicle to vehicle (V2V) communication [1, 2], also called intervehicle communication, the content is transferred between the two vehicle nodes when they encounter. Intervehicle communication improves a little due to the highly intermittent connectivity, especially for larger contents. Obviously, infrastructures built in VANETs such as roadside units (RSUs) or Access Points (APs) could dramatically improve the performance of content downloading with high bandwidth. Some of works [3–5] employ WIFI-based APs for content distribution and perform better than the intervehicle communication based schemes. Unfortunately, infrastructure-based methods also have some drawbacks. Firstly, static roadside infrastructure is hardly adaptive to rapid-changing traffic. Secondly, the deployment of APs influences the performance heavily. The sparser the placement of APs, the worse the performance. However, Internet APs need costly installation of power and wired network connectivity, of which the costs can be as high as 5,000 US dollars per unit [6]. Generally, though infrastructure does improve connectivity, it often requires a large amount of investment and elaborate design, especially at the city scale.Recent efforts [7–10] show that parked vehicles can play the role of the roadside unit. Since parking is a common phenomenon in most cities in our daily life, parked vehicles, especially on-street parked vehicles, are natural alternative of the roadside unit. With on-board wireless device and rechargeable battery, parked cars can communicate with any cars driving through them. With the assistance of cars parked at the roadside, we propose an efficient content downloading scheme for vehicular ad hoc networks. The roadside parked cars are grouped into parking clusters on each road. When a vehicle, called downloader, submits a downloading request to the parking cluster, the parking cluster will know the following trajectory of the downloader according to a trip history model. Then it will notify the parking clusters, which the downloader will drive through, to download a part of the content from the content provider. While the downloader travels through the parking clusters, it will get different parts of the content from the parking clusters.The remainder of this paper is organized as follows. Section2 discusses the related works. The problems are described in Section 3. In Section 4, the proposed scheme is presented in detail. Section 5 introduces simulations and discusses the results. The last section concludes the paper.


## 2. Related Works

There have been lots of research works on content sharing and delivery in mobile ad hoc networks [11–13]. Particularly, content downloading is also a hot issue in vehicular ad hoc networks. Ota et al. [14] investigate cooperative content downloading in the scenario of highway VANET. A P2P-like scheme [2] enables vehicles to exchange small content chunks when they encounter, but with poor performance.To improve the performance, some techniques are introduced. Li et al. [15] propose CodeOn, employing symbol level network coding (SLNC) to combat the lossy wireless transmissions, which is robust to transmission errors and encourages more aggressive concurrent transmissions. In [16], Wang et al. propose a cooperative approach based on coalition formation games, in which OBUs exchange their possessed pieces by broadcasting to and receiving from their neighbors. Though they achieve better performance, this depends on the performance of OBUs. In [17], Malandrino et al. outline the performance limits of such a vehicular content downloading system by modeling the downloading process as an optimization problem and maximizing the overall system throughput.Naturally, roadside infrastructure [3–5] is employed for content distribution in vehicular networks. Vehicular users can download large files from servers in the Internet through roadside Access Points (APs). Considering that vehicular content downloading via open WiFi Access Points (APs) can be challenging due to sparse AP deployment with bounded communication range and the rapid movement of traveling vehicles, Chen et al. [18] discuss joint resource allocation and scheduling problem for efficient content downloading considering channel contention and scarce AP resource utilized effectively. To get over that drawback and to improve a collaborative downloading, a P2P network [19] is constructed among the OBUs which fall out of the RSUs coverage and a new cell-based clustering scheme is proposed, which organizes the RSUs into a cluster, so as to improve delivery efficiency.In these schemes, server periodically delivers the pieces of data to other vehicles, and then vehicles that obtain chunks transport the data according to a carry-and-forward paradigm to the destination vehicle. However, the highly dynamic network topology introduces the intermittent connectivity, which causes unsuccessful downloading.Compared with the high cost of infrastructure, parked cars on the roadside can be leveraged to play the role of the RSUs. Liu et al. [6] present the idea of PVA (Parked Vehicle Assistance) firstly. They investigate that parked vehicles are natural alternative for roadside units and do not need any deployment investment.In [7], Malandrino et al. present a content downloading system in vehicular networks using parked vehicles. The goal is to share big pieces of data between vehicles and maximize content freshness and utilize the radio resources. But data exchange only involves one-hop communication. Moreover, they investigate the possibility of exploiting parked vehicles to extend the RSU service coverage. It leverages optimization models aiming at maximizing the freshness of content that downloaders retrieve, the efficiency in the utilization of radio resources, and the fairness in exploiting the energy resources of parked vehicles [20].Liu et al. propose ParkCast [8] in their following studies, which employs roadside parked vehicles to deliver content in urban VANETs. However, ParkCast does not provide a specific strategy to be tackled with the unfinished downloading, especially for the large size of content.In [9], an energy efficient data dissemination protocol with roadside parked cars’ assistance in VANETs is proposed. Similarly to ParkCast, the parked cars on the roadside are organized into several clusters, which store and distribute the media files for moving vehicles.Noticeably, the works on content downloading leveraging parked vehicles all assume that the content has been already stored in the parked cars, which is impractical.


## 3. Problem Statement

With the support of RSUs, vehicles can request content from RSUs. As in Figure1, vehicle A enters into the road and sends a downloading request to RSU1, which will get the content from the content provider, and then RSU1 transmits the content to vehicle A. If the content is too large, vehicle A will request the remainder of the content from other RSUs such as RSU2. As mentioned before, the high cost of RSUs deployments poses a heavy burden for the city government. Moreover, the optimal deployment of RSUs is also a challengeable task due to budget limits, street layout, and traffic changes. For example, if vehicle A drives into a road without RSUs, it will not get the remainder of the content until it encounters another RSU deployed in other road, leading to long transmission delay and poor experiences.Figure 1
Content downloading via RSUs.Fortunately, the parked cars on the roadside could be a natural alternative of RSUs. A survey [11] explores on-street parking in Ann Arbor and the US state of Michigan. It found that the utilization of the parking spaces is quite stable, although each parking is short and undulated. Occupancy ratio averages 93.0% one day during the peak. Even off-peak occupancy ratio averages almost 80%. For all practical purposes, the on-street parking spaces are used all of the time, for high parking demand. Consequently, the roadside parking spaces can be thought to be frequently occupied and parking lots have some “fixed” cars, as stable roadside units in communication.The roadside parked cars can be organized into clusters and play the role of RSUs. As in Figure2, vehicle A enters into the road; it submits a content downloading request to Cluster1. The cluster members will download the content from the Internet and transmit the content to vehicle A. In the meantime, Cluster1 will notify Cluster2, into which vehicle A will drive, to download the remainder of the content, so that vehicle A can get the remainder of the content quickly.Figure 2
Content downloading via roadside parked cars.There are some assumptions before we present the details of parked cars based content downloading scheme. Firstly, we assume that vehicles are equipped with GPS and electric maps, which are of low cost and popular nowadays. Based on GPS and electric maps, vehicles can get current speed, location, and moving direction. Then the trajectory of the vehicles can be recorded and saved. It is also a basic assumption for the intervehicle scheme because the cars need to know their location, by which the relay node is decided when they encounter. For RSU based approach, the GPS information can be got from the roadside unit. Secondly, we assume that the On-Board Units (OBUs) on vehicles are powered by the car battery, which could be charged while driving, for supporting the communication in parking. In [21], it is demonstrated that the energy of the car battery can power the OBUs for 80 hours or less. It is not necessary to worry about the depletion of the car battery because the average duration of street parking only lasts 6.64 hours, according to a real urban parking report [22]. Finally, we assume that some owners of the parked cars are willing to share the resources during parking. It can be motivated by some incentive mechanisms. Actually, according to the experience of P2P file systems [23], there are still 30% users who are willing to share their resources, even if there are not any incentives. That is to say, even though they cannot benefit from the sharing, some users are cooperative to contribute resources.


## 4. The Detailed Design

### 4.1. System Overview

Figure3 shows the overview of the network. In Figure 3, there are 6 intersections (Ii, Ij, Ik, Il, Im, and In) and several road segments in the map. Black vehicles are parked at the roadside and white vehicles move along the road. Vehicle A wants to download the content from the content provider. Firstly, the parked cars on the roadside are grouped into clusters. Downloader A sends its request for a specific content to Cluster1. Cluster1 estimatesA’s following trajectory according to a trip history model and knows which clusters the downloader will drive through. Considering the low bandwidth of the network, the content may not be downloaded while driving through the road segment. Assume that the content is divided into several chunks. Cluster1 will make a schedule to tell downloader A which chunks can be acquired from which clusters. At the same time, Cluster1 notifies other clusters, which the downloader will travel through, to download the specified chunks in advance, so that the chunks could be transmitted to the downloader once it enters into these clusters.Figure 3
System overview.


### 4.2. Clustering of Parked Cars

Due to the high stability and utilization of roadside parking, clustering parked vehicles on roadside is feasible in the city [24]. All parked vehicles (PV) on one road are organized into a virtual cluster, even if some of them cannot communicate with each other directly. This is viable, for the moving vehicles (MV) will travel across the road and help to maintain the connectivity of the whole virtual cluster. For supporting content downloading, the cluster head of virtual cluster needs to handle the following three tasks: (1) The first of them is cluster management, including membership management. (2) The second is content download scheduling. It decides the downloader that gets content chunks from each cluster member. If the downloader cannot finish downloading on the current road, it notifies other clusters that the mobile car will drive through to download the rest of content chunks. (3) The third is some information distributed over all the clusters, such as the average travel time on each road, which can be used to estimate how much chunks can be acquired on the road. As cluster members, there are three roles: (1) downloading the chunks from the content provider based on the scheduling of the cluster head; (2) distributing the chunks over the cluster, so that it can be a natural database to store the content; (3) transmitting the chunks to the downloading cars.The election of cluster head (CH) is simple. The parked car closest to the intersection could be the cluster head. As in Figure4, there are 3 scenarios of parked vehicles clustering. If lij is less than the communication radius of the vehicles, R, just one cluster head is needed to manage the cluster, as shown in Figure 4(a). In Figure 4(b), if lij is greater than R but it is less than 2R, there may be two cluster heads (i.e., CHi and CHj) at the two ends of road rij, so that moving vehicles could get the information of the virtual cluster as soon as possible once they enter into the road from Ii or Ij. When lij is greater than 2R, there might be some isolated parked vehicle (IPV) that cannot communicate with any cluster members directly. As in Figure 4(c), the moving vehicle MV1 would help the IPV communicate with the CHi or CHj and maintain the virtual cluster.Figure 4
Different scenario of clustering.
(a)
(b)
(c)


### 4.3. Trajectory Prediction

We use the trip history mobility model presented in our previous work [25] to predict the following trajectory of the vehicle. The idea of the mobility model is to record the trip details of vehicles every day, as shown in Table 1. The start time of the trip is separated into discrete time sets: Day (Mon., Tues., Wed., Thurs., Fri., Sat., and Sun.) and Time (<10, 10–12, 12–14, 14–16, 16–18, >18). Once a user starts his car, the start time and location are recorded as “Day,” “Time,” and “Source.” While moving, the vehicle gets position data from the GPS every several seconds. When the car stops, the last position is denoted by “Destination.” Then a decision tree can be constructed based on the trip history records to predict vehicle’s moving trajectory.Table 1
Trip history records.
Week
Day
Time
Source
Route
Destination
1
Fri.
<10
Home
r
12
→
r
23
→
r
35
→
r
57
→
⋯
→
r
79
Work place
1
Fri.
16–18
Work place
r
79
→
r
57
→
r
35
→
r
23
→
r
12
Home
1
Sat.
14–16
Home
r
12
→
r
24
→
⋯
Sports
1
Sat.
>18
Sports
⋯
Friend’s homeFigure5 depicts the decision tree according to Table 1, where the history trip records are expressed as branches and leaves. The probability of selecting a destination is given by(1)Pkq=fkqNk,where Nk is the total number of trips starting at the root node k, and fkq is the number of trips according to specific time and destination choices at the leaf node kq. Pkq represents the probability of moving toward the destination in history. Since the vehicle knows current Source, Day, and Time, it can find a Destination choice with a maximum Pkq in the tree as an initial prediction. While driving, the vehicle periodically checks whether its location is on the way to the predicted destination. If not, the vehicle needs to calculate a new destination probability by(2)Pkq=0,if  route  is  impossible,fkq∑fk,otherwise,where fk is the total number of the rest of the trips after removing the infeasible ones. Then it can find a new destination prediction with maximum Pkq. According to the model, each vehicle can predict one’s moving trajectory. If it wants to download content, it will notify the cluster head about the predicted trajectory, which can be utilized to make a downloading schedule.Figure 5
Structure of decision tree.


### 4.4. Content Downloading

A content file, assigned by a content identification (CID), is cropped into several chunks, each of which is also assigned a chunk identification (ChunkID). When downloaderA wants to download a content on the road rij, it will send the cluster head of the road rij a request, containing a 4-tuple composed of CID, LocAVecATA, and RouteA, where LocA and VecA are the current location and the velocity of vehicle A, TA is a vector of average travel time on each road in the following trajectory, and RouteA is the following trajectory predicted by vehicle A, according to the trip history model. The cluster head will know which clusters downloader A will bypass and can compute the number of the chunks that the downloader can download on each road in the following trip, as in (3)Nij=∫0tijC·dtS,where C is the MAC throughput that can be estimated in [26], and S is the amount of a chunk. The cluster head will notify downloader A about the downloading schedule that specifies which clusters and how much chunks can be downloaded on each road rij in the predicted trajectory. Meanwhile, the cluster head also notified other cluster heads on the following trajectory to download the specified chunks from the content provider.As shown in Figure3, downloader A calculates its following trajectory and sends the 4-tuple request to the cluster head of Cluster1. Based on (3) and 4-tuple, the cluster head knows the content is composed of 5 content chunks and makes a schedule where the first 2 chunks can be acquired from Cluster1, the third chunks can be got from Cluster5, and the last 2 chunks can be downloaded from Cluster6. The schedule will be transferred to the downloader and the cluster heads of Cluster5 and Cluster6. Moreover, the cluster heads will choose some cluster members to download the specified chunks from the content provider. When the downloader bypasses these cluster members, the chunks will be transmitted to the downloader.


## 4.1. System Overview

Figure3 shows the overview of the network. In Figure 3, there are 6 intersections (Ii, Ij, Ik, Il, Im, and In) and several road segments in the map. Black vehicles are parked at the roadside and white vehicles move along the road. Vehicle A wants to download the content from the content provider. Firstly, the parked cars on the roadside are grouped into clusters. Downloader A sends its request for a specific content to Cluster1. Cluster1 estimatesA’s following trajectory according to a trip history model and knows which clusters the downloader will drive through. Considering the low bandwidth of the network, the content may not be downloaded while driving through the road segment. Assume that the content is divided into several chunks. Cluster1 will make a schedule to tell downloader A which chunks can be acquired from which clusters. At the same time, Cluster1 notifies other clusters, which the downloader will travel through, to download the specified chunks in advance, so that the chunks could be transmitted to the downloader once it enters into these clusters.Figure 3
System overview.


## 4.2. Clustering of Parked Cars

Due to the high stability and utilization of roadside parking, clustering parked vehicles on roadside is feasible in the city [24]. All parked vehicles (PV) on one road are organized into a virtual cluster, even if some of them cannot communicate with each other directly. This is viable, for the moving vehicles (MV) will travel across the road and help to maintain the connectivity of the whole virtual cluster. For supporting content downloading, the cluster head of virtual cluster needs to handle the following three tasks: (1) The first of them is cluster management, including membership management. (2) The second is content download scheduling. It decides the downloader that gets content chunks from each cluster member. If the downloader cannot finish downloading on the current road, it notifies other clusters that the mobile car will drive through to download the rest of content chunks. (3) The third is some information distributed over all the clusters, such as the average travel time on each road, which can be used to estimate how much chunks can be acquired on the road. As cluster members, there are three roles: (1) downloading the chunks from the content provider based on the scheduling of the cluster head; (2) distributing the chunks over the cluster, so that it can be a natural database to store the content; (3) transmitting the chunks to the downloading cars.The election of cluster head (CH) is simple. The parked car closest to the intersection could be the cluster head. As in Figure4, there are 3 scenarios of parked vehicles clustering. If lij is less than the communication radius of the vehicles, R, just one cluster head is needed to manage the cluster, as shown in Figure 4(a). In Figure 4(b), if lij is greater than R but it is less than 2R, there may be two cluster heads (i.e., CHi and CHj) at the two ends of road rij, so that moving vehicles could get the information of the virtual cluster as soon as possible once they enter into the road from Ii or Ij. When lij is greater than 2R, there might be some isolated parked vehicle (IPV) that cannot communicate with any cluster members directly. As in Figure 4(c), the moving vehicle MV1 would help the IPV communicate with the CHi or CHj and maintain the virtual cluster.Figure 4
Different scenario of clustering.
(a)
(b)
(c)


## 4.3. Trajectory Prediction

We use the trip history mobility model presented in our previous work [25] to predict the following trajectory of the vehicle. The idea of the mobility model is to record the trip details of vehicles every day, as shown in Table 1. The start time of the trip is separated into discrete time sets: Day (Mon., Tues., Wed., Thurs., Fri., Sat., and Sun.) and Time (<10, 10–12, 12–14, 14–16, 16–18, >18). Once a user starts his car, the start time and location are recorded as “Day,” “Time,” and “Source.” While moving, the vehicle gets position data from the GPS every several seconds. When the car stops, the last position is denoted by “Destination.” Then a decision tree can be constructed based on the trip history records to predict vehicle’s moving trajectory.Table 1
Trip history records.
Week
Day
Time
Source
Route
Destination
1
Fri.
<10
Home
r
12
→
r
23
→
r
35
→
r
57
→
⋯
→
r
79
Work place
1
Fri.
16–18
Work place
r
79
→
r
57
→
r
35
→
r
23
→
r
12
Home
1
Sat.
14–16
Home
r
12
→
r
24
→
⋯
Sports
1
Sat.
>18
Sports
⋯
Friend’s homeFigure5 depicts the decision tree according to Table 1, where the history trip records are expressed as branches and leaves. The probability of selecting a destination is given by(1)Pkq=fkqNk,where Nk is the total number of trips starting at the root node k, and fkq is the number of trips according to specific time and destination choices at the leaf node kq. Pkq represents the probability of moving toward the destination in history. Since the vehicle knows current Source, Day, and Time, it can find a Destination choice with a maximum Pkq in the tree as an initial prediction. While driving, the vehicle periodically checks whether its location is on the way to the predicted destination. If not, the vehicle needs to calculate a new destination probability by(2)Pkq=0,if  route  is  impossible,fkq∑fk,otherwise,where fk is the total number of the rest of the trips after removing the infeasible ones. Then it can find a new destination prediction with maximum Pkq. According to the model, each vehicle can predict one’s moving trajectory. If it wants to download content, it will notify the cluster head about the predicted trajectory, which can be utilized to make a downloading schedule.Figure 5
Structure of decision tree.


## 4.4. Content Downloading

A content file, assigned by a content identification (CID), is cropped into several chunks, each of which is also assigned a chunk identification (ChunkID). When downloaderA wants to download a content on the road rij, it will send the cluster head of the road rij a request, containing a 4-tuple composed of CID, LocAVecATA, and RouteA, where LocA and VecA are the current location and the velocity of vehicle A, TA is a vector of average travel time on each road in the following trajectory, and RouteA is the following trajectory predicted by vehicle A, according to the trip history model. The cluster head will know which clusters downloader A will bypass and can compute the number of the chunks that the downloader can download on each road in the following trip, as in (3)Nij=∫0tijC·dtS,where C is the MAC throughput that can be estimated in [26], and S is the amount of a chunk. The cluster head will notify downloader A about the downloading schedule that specifies which clusters and how much chunks can be downloaded on each road rij in the predicted trajectory. Meanwhile, the cluster head also notified other cluster heads on the following trajectory to download the specified chunks from the content provider.As shown in Figure3, downloader A calculates its following trajectory and sends the 4-tuple request to the cluster head of Cluster1. Based on (3) and 4-tuple, the cluster head knows the content is composed of 5 content chunks and makes a schedule where the first 2 chunks can be acquired from Cluster1, the third chunks can be got from Cluster5, and the last 2 chunks can be downloaded from Cluster6. The schedule will be transferred to the downloader and the cluster heads of Cluster5 and Cluster6. Moreover, the cluster heads will choose some cluster members to download the specified chunks from the content provider. When the downloader bypasses these cluster members, the chunks will be transmitted to the downloader.


## 5. Evaluation

### 5.1. Simulation Setup

Firstly, we perform weeks’ survey on an urban area of Chengdu, a city in China. As shown in Figure6, a real street map with the range of 3600 m∗2500 m is selected, including 24 intersections and 35 bidirectional roads. Each intersection is marked by a number from 1 to 24. During the survey, we investigated the traffic and roadside parking statistics at different time during a day.Figure 6
Road topology in survey and simulation.There are three kinds of streets with different parking limits. The first kind permits free parking at roadside, asR1,2, R2,3, and so on, which results in a very high node density as 300 veh/km in average. The second one, as R1,4 and R4,9, lacks public parking spaces. These streets have a very low vehicle density as 20 veh/km, which comes from some reserved parking spaces and illegal parking. The third one has a moderate vehicle density as 98 veh/km.In simulation, VanetMobiSim-1.1 is used to generate realistic urban mobility traces, which can be directly utilized by the network simulator NS-2.33. The history trajectory records are collected from 30 volunteers who travel through the area of the map in Figure6 for 4 weeks. And each downloader will be assigned a history trajectory record, which is chosen from the 30 history trajectory records randomly. For evaluating the energy consumption, the power model in [27] is used, including the transmitting power, receiving power, and idling power, listed in Table 2. Moreover, the computing power of the OBUs and the power of the car battery are 4.0 W and 960 W, given by [21], respectively. In the simulation, parked vehicles are located on random positions of each street, following the densities collected in survey. Other simulation parameters are shown in Table 2.Table 2
Simulation parameters.
Parameters
Value
Number of vehicles
50~300
Velocity (km/h)
40~60
MAC
802.11
Data rate (bps)
2 M
Radio range (m)
250
Size of content (Mb)
5~100
Size of chunk (Mb)
2.5
Ratio of downloader
5%~25%
Transmitting power,PT (W)
1.5
Receiving power,PR (W)
0.8
Idling power,PI (W)
0.2
Computing power,PC (W)
4.0
Power of the car battery (W)
960We evaluate our scheme with intervehicle approach [2] and RSU based approach [3]. The downloaders are chosen from the moving cars randomly, and each of downloaders will be assigned a history trajectory record, according to volunteers’ travels. For RSU based approach, the number of RSUs is crucial for the performance. As in [3], the number of RSUs is set to 5, and the content files are stored in these 5 RSUs. When the downloader travels through the RSU, it can submit a content request to the RSU, which will download the content from the content provider and then transmit to the downloader. For the intervehicle approach, the downloader and its neighbors are cooperative to download the content file from the content provider. For our proposed scheme, the content file will be pieced into several chunks, and cluster members will download chunks for the downloader and transmit them to the downloader when the downloader bypasses the cluster members.


### 5.2. Simulation Results

Comparing the protocols, we choose to evaluate them according to the average downloading ratio, defined as the ratio between the number of requests that successfully download the content and the total amount of requests.We firstly evaluate the average download ratio of the three approaches under different number of mobile vehicles and the results are shown in Figure7. The size of content is set to 10 Mb. Moreover, the percentage of the downloaders that request content is set to 5%.Figure 7
Impact of the number of mobile vehicles.As shown in Figure7, for the intervehicle scheme, the more the mobile vehicles are, the more the chances to maintain connection with neighbors are, so that the downloading ratio increases rapidly. Though the average downloading ratios of the RSU based method and our proposed scheme decrease while increasing the number of mobile vehicles, the intervehicle performs poorer than that of the two approaches due to intermittent communication. Our proposed scheme performs much better than the RSU based approach, reaching 90% or so, compared with 55% of the RSU based approach when there are 150 mobile vehicles. The reason is that the number of RSUs is not enough to cover all roads, compared with the roadside parked cars almost covering each road. The more mobile vehicles means more downloaders, leading to unsuccessful downloading due to collision.Figure8 describes the impact of the content size on the average downloading ratio, while there are 150 mobile vehicles and 10 vehicles request to download the content. As in Figure 8, the average downloading ratio decreases with the increasing of the content size of all schemes quickly. For our proposed scheme, the reason is that large size of the content means that there are more chunks for the content. It needs more parking clusters to participate in transferring the chunks, which is not satisfied in the simulation map. Similarly, the RSU based approach has no enough RSUs and high bandwidth to support the transmission of large size content. However, the download ratio of our proposed scheme has still 65% much more than that of the RSU based approach. For the intervehicle approach, large size of the content file means it needs more neighbors to download the content cooperatively, which is hard to be satisfied if there are not enough mobile vehicles, leading the rapid decreasing of the downloading ratio.Figure 8
Impact of the size of content.Figure9 plots how the ratio of downloader influences the performance of all schemes with 10 M content size and 150 mobile vehicles. In Figure 9, the average downloading ratio of all schemes decreases when the number of downloaders increases. Due to the resources of roadside parking clusters, our proposed scheme achieves the highest downloading ratio, compared with the poorest performance of intervehicle based approach. Of course, the intervehicle approach performs poorest. With the increase of downloaders, they need more neighbors to collaborate to download the content. However, it is not an easy task and will introduce more collision.Figure 9
Impact of the number of downloaders.To study the potential effect on power consumption of the parked cars, the downloader will initiate a new request for another content file periodically, until the end of simulation. The energy consumption is calculated by(4)E=PTtT+PRtR+PItI+PCtC,where tT, tR, and tI are the time that the transceiver stays in the status of transmitting, receiving, and idling. And tC is the time spent on computation of the OBUs. The results have been shown in Figure 10. Obviously, the power consumption of both cluster head and cluster member increases with time elapsing. In the earlier stage of simulation, the cluster head consumes a little more energy than the cluster member. But in the latter, the cluster head consumes more energy than the cluster member. The reason is that chunks are distributed over the networks by all parked cars including the cluster head and the cluster member in the beginning. Once the chunks are stored in all parked cars, the cluster member does not distribute the chunks and only transmits the chunks to the downloader. Though the power consumption of the cluster head is more than that of the cluster member, the percentage of power consumption of the cluster head is just 8.8% of the car battery after 10 hours of parking. According to [22], the average duration of street parking only lasts 6.64 hours, meaning that the car battery can sufficiently supply the energy for communication while parking. Practically, a threshold can be set to ensure that energy of the battery can fire the engine of the car.Figure 10
The power consumption of cluster head and cluster member.


## 5.1. Simulation Setup

Firstly, we perform weeks’ survey on an urban area of Chengdu, a city in China. As shown in Figure6, a real street map with the range of 3600 m∗2500 m is selected, including 24 intersections and 35 bidirectional roads. Each intersection is marked by a number from 1 to 24. During the survey, we investigated the traffic and roadside parking statistics at different time during a day.Figure 6
Road topology in survey and simulation.There are three kinds of streets with different parking limits. The first kind permits free parking at roadside, asR1,2, R2,3, and so on, which results in a very high node density as 300 veh/km in average. The second one, as R1,4 and R4,9, lacks public parking spaces. These streets have a very low vehicle density as 20 veh/km, which comes from some reserved parking spaces and illegal parking. The third one has a moderate vehicle density as 98 veh/km.In simulation, VanetMobiSim-1.1 is used to generate realistic urban mobility traces, which can be directly utilized by the network simulator NS-2.33. The history trajectory records are collected from 30 volunteers who travel through the area of the map in Figure6 for 4 weeks. And each downloader will be assigned a history trajectory record, which is chosen from the 30 history trajectory records randomly. For evaluating the energy consumption, the power model in [27] is used, including the transmitting power, receiving power, and idling power, listed in Table 2. Moreover, the computing power of the OBUs and the power of the car battery are 4.0 W and 960 W, given by [21], respectively. In the simulation, parked vehicles are located on random positions of each street, following the densities collected in survey. Other simulation parameters are shown in Table 2.Table 2
Simulation parameters.
Parameters
Value
Number of vehicles
50~300
Velocity (km/h)
40~60
MAC
802.11
Data rate (bps)
2 M
Radio range (m)
250
Size of content (Mb)
5~100
Size of chunk (Mb)
2.5
Ratio of downloader
5%~25%
Transmitting power,PT (W)
1.5
Receiving power,PR (W)
0.8
Idling power,PI (W)
0.2
Computing power,PC (W)
4.0
Power of the car battery (W)
960We evaluate our scheme with intervehicle approach [2] and RSU based approach [3]. The downloaders are chosen from the moving cars randomly, and each of downloaders will be assigned a history trajectory record, according to volunteers’ travels. For RSU based approach, the number of RSUs is crucial for the performance. As in [3], the number of RSUs is set to 5, and the content files are stored in these 5 RSUs. When the downloader travels through the RSU, it can submit a content request to the RSU, which will download the content from the content provider and then transmit to the downloader. For the intervehicle approach, the downloader and its neighbors are cooperative to download the content file from the content provider. For our proposed scheme, the content file will be pieced into several chunks, and cluster members will download chunks for the downloader and transmit them to the downloader when the downloader bypasses the cluster members.


## 5.2. Simulation Results

Comparing the protocols, we choose to evaluate them according to the average downloading ratio, defined as the ratio between the number of requests that successfully download the content and the total amount of requests.We firstly evaluate the average download ratio of the three approaches under different number of mobile vehicles and the results are shown in Figure7. The size of content is set to 10 Mb. Moreover, the percentage of the downloaders that request content is set to 5%.Figure 7
Impact of the number of mobile vehicles.As shown in Figure7, for the intervehicle scheme, the more the mobile vehicles are, the more the chances to maintain connection with neighbors are, so that the downloading ratio increases rapidly. Though the average downloading ratios of the RSU based method and our proposed scheme decrease while increasing the number of mobile vehicles, the intervehicle performs poorer than that of the two approaches due to intermittent communication. Our proposed scheme performs much better than the RSU based approach, reaching 90% or so, compared with 55% of the RSU based approach when there are 150 mobile vehicles. The reason is that the number of RSUs is not enough to cover all roads, compared with the roadside parked cars almost covering each road. The more mobile vehicles means more downloaders, leading to unsuccessful downloading due to collision.Figure8 describes the impact of the content size on the average downloading ratio, while there are 150 mobile vehicles and 10 vehicles request to download the content. As in Figure 8, the average downloading ratio decreases with the increasing of the content size of all schemes quickly. For our proposed scheme, the reason is that large size of the content means that there are more chunks for the content. It needs more parking clusters to participate in transferring the chunks, which is not satisfied in the simulation map. Similarly, the RSU based approach has no enough RSUs and high bandwidth to support the transmission of large size content. However, the download ratio of our proposed scheme has still 65% much more than that of the RSU based approach. For the intervehicle approach, large size of the content file means it needs more neighbors to download the content cooperatively, which is hard to be satisfied if there are not enough mobile vehicles, leading the rapid decreasing of the downloading ratio.Figure 8
Impact of the size of content.Figure9 plots how the ratio of downloader influences the performance of all schemes with 10 M content size and 150 mobile vehicles. In Figure 9, the average downloading ratio of all schemes decreases when the number of downloaders increases. Due to the resources of roadside parking clusters, our proposed scheme achieves the highest downloading ratio, compared with the poorest performance of intervehicle based approach. Of course, the intervehicle approach performs poorest. With the increase of downloaders, they need more neighbors to collaborate to download the content. However, it is not an easy task and will introduce more collision.Figure 9
Impact of the number of downloaders.To study the potential effect on power consumption of the parked cars, the downloader will initiate a new request for another content file periodically, until the end of simulation. The energy consumption is calculated by(4)E=PTtT+PRtR+PItI+PCtC,where tT, tR, and tI are the time that the transceiver stays in the status of transmitting, receiving, and idling. And tC is the time spent on computation of the OBUs. The results have been shown in Figure 10. Obviously, the power consumption of both cluster head and cluster member increases with time elapsing. In the earlier stage of simulation, the cluster head consumes a little more energy than the cluster member. But in the latter, the cluster head consumes more energy than the cluster member. The reason is that chunks are distributed over the networks by all parked cars including the cluster head and the cluster member in the beginning. Once the chunks are stored in all parked cars, the cluster member does not distribute the chunks and only transmits the chunks to the downloader. Though the power consumption of the cluster head is more than that of the cluster member, the percentage of power consumption of the cluster head is just 8.8% of the car battery after 10 hours of parking. According to [22], the average duration of street parking only lasts 6.64 hours, meaning that the car battery can sufficiently supply the energy for communication while parking. Practically, a threshold can be set to ensure that energy of the battery can fire the engine of the car.Figure 10
The power consumption of cluster head and cluster member.


## 6. Conclusion

In this paper, a content downloading scheme with the assistance of roadside parked cars is proposed. The parked cars, which form a virtual cluster, play the role of RSUs, downloading the content from the content provider and transmitting it to the downloader. Clusters make a schedule to notify the downloader about how to acquire content chunks from which clusters based on the estimated trajectory of the downloader. Simulation results show that our proposed scheme achieves 65% higher average download ratio than RSU based approach.



---

*Source: 4863167-2017-09-11.xml*