Intelligent popularity-aware content caching and retrieving in highway vehicular networks

We make an overview of the content retrieval process with ICN schemes. In the server, contents are pre-processed as the streaming and each streaming is divided into a lot of chunks, which are the basic elements in ICN. An identified name is distributed to the relative chunk via the naming process. After that, each vehicle can request the wanted streaming chunk by the chunk name directly, rather than the IP address. Broadcasting interest packets issue a chunk request that contain the chunk name. Due to certain relevance of these chunks, this information-centric content cache and retrieval process can support the related requests, not just the separated request. Then vehicles which cache this chunk will respond to an originator. The requesting vehicle can get several answers and choose the “best” one. A playback buffer is adopted to cache the received chunks, which are queued to be “played”. Every vehicle, which transfers requested chunks, will cache chunks locally for the same requests later. The overview of ICN-based content retrieval is shown in Fig. 2.

It should be noted that caching the chunk locally will lead to unnecessary content caching redundancy, but can bring impressive effects, such as shorter RTT and less interest packets. Compared with saving the storage space, alleviating the burden of Internet is more meaningful and significant in highway VANETs. With many characteristics, which are featured in ICN and VANETs, some more considerations should be given to the model in our full analysis particularly.

In VANETs, many vehicles autonomously construct a temporal network to communicate with each other. Different from general MANETs, VANETs have several special attributes. For example, in VANETs, the vehicles’ mobility patterns are highly relying on the road structures.

In VANETs, the locations of vehicles vary with the time. In this paper, we choose a linear topology to analyze in order to make the model simple. We assume the vehicular scenario is in the highway, so all vehicles can be distributed as some lines and can move along the lines in both directions. Vehicles may be parted on the highway, forming platoons. However, vehicles in different platoons can be bridged by the cars coming from the opposing directions (Fig. 3). In this theory, we model the linear topology by separating it into different sub-regions, which represent the location coordinate.

Let R = [0, C] represent a linear highway scenario. R = [0, C] is further parted into M cells with the same size, which can be calculated by Δx = C/M. Let R _i  = [a _i−1, a _i ), i = 1, ⋯, M denote a small cell, where a _i  > a _i−1 with a ₀ = 0, a _M  = C. In each location cell R _i , a lot of vehicles locate. In other words, a mobile vehicle can occupy one of R _i at any moment. We will focus on the mobility, which begins with a cell and ends up in another cell.

In our model, each content (e.g., video) is composed with one or many chunks. The content is divided into multiple equal-sized chunks, which is the smallest unit in the transfer model. Multiple chunks can be grouped into a segment in each vehicle. Different contents can contain different number of chunks, each of which owns a chunk identifier. Based on this, content retrieval can be disposed by using of a sequence of chunk identifier or segment identifier.

Let δ express the average size (the number of chunks) of content. According to Carofiglio et al. [39], a group of content items Q are averagely divided in K classes based on their popularity. Assume that the popularity in Q follow a Zipf-like distribution. Let q _k express the requesting probability of class k content items, k = 1, ⋯, K; thus we have q _k  = c/k ^α , with parameter α > 1.

Based on the above descriptions, the relationship among contents, vehicles, and locations can be summarized in our models. Many vehicles can share one content at the same time; a vehicle moves among the location cell; and one or more vehicles can be carried by one location cell at any time.

We proposed a methodology to connect the relationship among contents, vehicles, and locations, as shown in Fig. 4. It outlines the whole structure of this paper and our considerations in content cache and retrieval in ICN-based VANETs. In the methodology, we are concerned about the three processes: vehicle location distribution [40], content retrieval, caching and correlation study [39]. At the bottom, highway is chosen as the application scenarios, and transition probability theory is adopted to represent vehicles’ movement. In the top, we build the content retrieval model and derive the evaluation metrics. Besides, switching retrieval modes is to optimize the QoE. In the center, we analyze four points: actively caching mechanism, caching in-networking features, generalized mobility model, and natures of wireless environment. The vehicle is the key role, which is the bridge to link locations and contents. This is the core thought in our proposal.

Each vehicle has a cache with a size of x chunks in the network. These chunks are cached and replaced in accordance with the popularity ω, which significantly impacts the retrieval’s efficiency. In general, the more popular the content is, the more duplicate vehicles. What is more, the popularity keeps changing with the varying of time and space.

Due to the features of ICN, we consider the processes of content caching and retrieving are all chunk-level. However, the chunks, which belong to one content object, have a certain back-and-forth relevance. Therefore, the popularity should be related with each other. In fact, some chunks are more popular than the whole content objects. In another words, some chunks in the content are what people really want. Each chunk is interconnected, so the full content should be taken into account when calculating the popularity. To get a reasonable popularity, we redesign the definition of the popularity. We believe that the popularity of each chunk depends on two parts: the reference frequency of the object (the chunk belongs to) and the reference frequency of the chunk.

Assuming one content object C contains a sequence of streaming chunks c ₁, c ₂, c ₃. We define the reference frequency of C is σ and the reference frequency of chunk c _i is σ _i , and the content weight value is v. Then the popularity of this c _i follows:

To make sure that each vehicle in networks can get the popularity of requested chunk, we establish a novel mechanism for calculating the popularity (Algorithm 1), which is setup in a special entity, named as resource popularity manager (RPM). RPMs can be distributed in the network and connected with RSUs. Each vehicle is available to access RPMs to query the popularity when it is needed.

RPM keeps listening on the well-known port which receives requests for contents. If a request for c _i is received, RPMs will firstly retrieve the resource name which c _i belongs to. For example, c _i belongs to C. Both c _i and C have their records indicating their reference frequency numbers. RPMs update both the records by adding each record with one. Then, RPMs calculate the popularity value of c _i through a specific math formula (1), and respond to the request with it.

Vehicular wireless technologies, for example, Wireless Access in the Vehicular Environment (WAVE) (IEEE 802.11p) enable data delivery via V2V and V2I communication. In V2I, vehicles should maintain connection to the RSUs during the driving period to support the continuous content retrieval. We observe that both of them have their advantages and disadvantages in the process of content streaming retrieval. According to the cache replacement policy, the more popular the content is, the more copies it has.

For the popular content, V2V represents a high efficiency and reliability. It is more efficient to obtain contents from the surrounding vehicles. Due to the mobility of vehicles, if the contents are acquired from the fixed device, it may need to be repeatedly switched among the RSUs. It will be wasting time and poor qualification.

However, if a requested content has a low popularity, which means this content is stored in a handful of vehicles, content’s discovery in vehicles will be a time-consuming duration. What is more, this process may disseminate a lot of interest packets, which will result in the waste of the vehicular resources. However, RSUs’ position is fixed, and the storage space is large enough, they can even access the contents of the request directly from the server, so V2I communication is more likely to be successful to access the content via RSUs. Based on this consideration, we propose a popularity-aware-based retrieval strategy to optimize the information-centric content retrieval process (Algorithm 2). This strategy can adjust the content retrieval mode (V2V or V2I) with the knowledge of the popularity value of the requested content.

There are two retrieval modes that can be used to obtain a resource: V2I communication mode and V2V communication mode. Assuming the content of c _i is requested, the requesting vehicle V firstly gets the popularity value of c _i from the roadside station (RPM). If the value ω is lower than the threshold popularity value Ω, it means c _i is unpopular. In this case, V will try to get the content in V2I mode. V sends requests for connection to RSU and retrieves the content from the RSU. Otherwise, if ω is in excess of Ω, V will try to get the content in V2V mode. V disseminates requests of c _i on the radio to find out how many vehicles nearby holds c _i and records them, then makes connections with the best vehicle to retrieve the content. By now, if c _i was still not obtained, V will connect the nearby roadside unit RSUs. RSUs can connect to the Internet to request the content directly, which can prove the probability of success.

When the IIR of the requested content θ is more than the threshold Θ, the vehicles will trigger the actively caching mechanism to inform other vehicles to cache the content. In most cases, some content will suddenly become a hot spot. In order to cope with the peak of this kind of sudden, we designed the actively caching mechanism. Through the forecast judgment algorithm, the vehicle automatically sends the content to surrounding vehicles before the peak appears. Therefore, when the peak is coming, the request vehicles can achieve the content in the vicinity, which can reduce the RTT and improve the QoE of the passengers.

The interest increasing rate follows:

Based on this consideration, we propose an actively caching mechanism (Algorithm 3). Because all of requesting packets will be sent to the well-known port, RPM can calculate IIR. If θ _ci is in excess of Θ, the actively caching mechanism will be triggered that the vehicle automatically sends the content to surrounding vehicles to cache the content.

To evaluate the superiority of switching retrieval modes, it is compared with the random caching strategy (R-Caching) in terms of RTT and the number of interest packets. In this experiment, we set 50, 100, and 150 vehicles moving in a 10-km highway.

Firstly, we observe the RTT according to the content popularity ω. Experimental results are given in Figs. 6, 7, and 8. In this experiment, three cases with different number of vehicles are chosen and compared. By comparing these figures, we can see RTT based on P-CCR has an obvious decreasing trend, compared with the R-Caching strategy. That is because different popularity contents will bring different distribution according to P-CCR. The more popular one content is, the smaller miss probability it is in every region cell. Based on R-Caching, however, the RTT do not change with the increase of the popularity. For example, when the popularity is 14, the RTT based on P-CCR is less about 10 ms than R-Caching. It is significant for the highway passengers to reduce the waiting time of 10 ms.

Besides, we can see the number of vehicles affects the property of content retrieval in VANETs. The delay of content retrieval reduces with the rising of vehicle density to a certain extent. It is because vehicles retrieve the content from the near vehicular peers, which can provide the requested contents. Each vehicle can cache the content and can be seen as a casual content provider. For a certain requested content, the higher the density vehicles is, the more potential providers nearby there are. Thus, it has a smaller miss probability in each location region. Better yet, it is observed that three sets of lines have the same consistent trend in these three figures, which strongly validates the reliability of our model to some extent.

Secondly, the number of interest packets is analyzed according to the number of vehicles. Figure 9 shows the experimental results. In this figure, the popularity is fixed as 10. The blue one represents the R-Caching scheme and the red shows the P-CCR solution. We know that the number of interest packages will naturally grow as vehicles grow. But the quantity of interest messages can significantly reduce by switching retrieval modes intelligently compared with R-Caching. According to P-CCR, requesting vehicles can choose the best retrieval mode (V2V or V2I) based on the popularity, which is derived from the cache possibility of the requested content. The content is more popular, and it will be searched successfully more possibly in vehicles. Therefore, retrieving the content in vehicles will decrease the number of interest packets by adopting P-CCR. Similarly, the requested content with low popularity will reduce interest packets if it is searched in the RSUs. For example, we fix the number of vehicles at 150. The R-Caching strategy need to broadcast almost 3000 interest packets. However, it is just required 2400 packets for the P-CCR scheme. It can lighten greatly network loads and avoid efficiently wasting resources, which is significant for VANETs in highway.

Based on this experiment, we assess the performance improvement of the proposed actively caching mechanism by comparing with the R-Caching without the actively caching mechanism. The experiments are conducted in different cases with varying increasing rates of interest packets. We fix the number of vehicle as 100, and RTT is adopted to measure the flexibility of actively caching mechanism.

As shown in Fig. 10, we fix the threshold of IIR at 0.5. According to R-Caching, the RTT increase sharply with the growing of IIR, which will waste the wireless resource. Compared with R-Caching, P-CCR with an actively caching mechanism can obviously limit the RTT. When the popularity is 10 and the increasing rate is 0.5, the RTT is decreased by 10 ms compared with the random caching. At the same time, we compare different popularity by P-CCR with actively caching mechanism. The larger the popularity is, the less the RTT is. In Fig. 11, we fix the popularity at 10. We further evaluate the RTT according to different threshold of IIR. We find that different threshold will affect the performance of the actively caching mechanism. The greater the growth rate is, the more obvious the change is. So setting proper IIR is crucial to achieve the best performance. We can set different threshold values according to different kinds of contents. For example, we can set a larger threshold for the content with low real-time requirement (e.g., web services), and set a lower threshold for the content with high real-time requirement (e.g., video).

We found that the greater the popularity is, the more significant the effect is. When the rate of requested chunks exceeds the pre-setup threshold of IIR, the RTT with P-CCR has a sharp change and remains in a steady state. That is because when the rate is higher than the threshold, the actively caching mechanism will be triggered and the content will be cached in more vehicles. The P-CCR solution limits the amount of variation of the lines and guarantees a smaller RTT value, which represents an acceptable QoE.