# Efficient V2V Communications by Clustering-Based Collaborative Caching +
## 2 Related Work
### Collaborative Caching  
Ref. [4] studies a combination of CCN and clustering whereby a CH stores content received from a Road-Side Unit (RSU), making it possible to reply to requests from CMs even if they are outside of the transmission ranges of RSUs. However, this method does not use cache buffers at CMs at all. In the cooperative scheduling method [12], each RSU on a road divides vehicles in its transmission range into clusters in a centralized way. In each cluster, each vehicle takes turns to broadcast content according to the specified schedule. Although this helps to \begin{table}
\begin{tabular}{l l l} \hline
**Reference** & **Kind** & **Description** \\ \hline
[4] & Collaborative caching &
\begin{tabular}{l} CHs receive content from RSU; CMs receive content from both of them \\ \end{tabular} \\ \hline
[12] & Collaborative caching &
\begin{tabular}{l} Vehicles broadcast alternately \\ A vehicle preferentially requests content from \\ others moving in the same lane \\ A vehicle decides whether to cache content based \\ on the vehicle’s power, the content’s popularity, \\ the gain acquired by the content, and the distance (hop count) to the content provider \\ \end{tabular} \\
[14] & Collaborative caching &
\begin{tabular}{l} Both vehicles and RSUs construct clusters \\ Vehicles within an RSU are divided into clusters, \\ and they send requests to the RSU \\ Vehicles construct clusters and receive requested \\ content from either their CHs or RSUs; part of the \\ mathematical model is solvable as a knapsack \\ problem \\ \end{tabular} \\
[15] & Collaborative caching &
\begin{tabular}{l} Vehicles broadcast the names of cached content \\ Cache policy is determined with deep \\ reinforcement learning \\ The problem of which content to store and where \\ to store it is determined by machine learning \\ Data carrier node is selected by reinforcement \\ learning \\ \end{tabular} \\
[16] & Collaborative caching &
\begin{tabular}{l} Cache placement is treated as an MWVCP problem \\ Node \(n\) (\(n<k\)) only stores content \(c\), where \(c\) \\ mod \(k=n\) \\ Vehicles that lie in the common communication \\ area are preferentially selected \\ \end{tabular} \\ \hline \end{tabular}
\end{table} 
Table 1: _Cont._improve channel efficiency, it is not applicable to the scenario wherein vehicles request different content. Refs. [3; 7; 8] studied how to reduce the redundancy in content caching by storing received content with a probability. These methods help to reduce the chance that neighbor vehicles save duplicated content, but they cannot prevent it entirely. In [13], vehicles decide whether to cache content based on the vehicle's power, content popularity, the gain acquired by caching the content, and the hop count of the content. In [14], both vehicles and RSUs form clouds: a vehicular cloud (VC) and an RSU cloud (RC), respectively. When a vehicle requests content, it first asks its VC. If all vehicles in the cloud do not have the content, it queries its associated RSU. The RSU replies if one of its RCs has the content or fetches the content from the remote server otherwise. Some research has applied existing algorithms to V2V communications, e.g., a cuckoo search for route calculation [15], the 0-1 knapsack problem for cache decisions [16], and the Minimum Weight Vertex Cover Problem for cache placement [20]. With the emergence of AI, some studies suggest combining AI and vehicular networks: Ref. [17] calculates the cache policy with deep reinforcement learning, Ref. [18] uses machine learning to decide which content to store and where to store it, and Ref. [19] uses reinforcement learning to decide which vehicle would be the best data carrier node. To share content information, Ref. [6] suggests letting each vehicle broadcast the names of its cached content to neighbor vehicles by using periodical beacon messages. Neighbor vehicles, on receiving this message, store the information and use it to check which vehicle stores content as a cache.