# Efficient V2V Communications by Clustering-Based Collaborative Caching +
## 4 Simulation Evaluation
### Simulation Results  
First, we evaluated the impact of popularity in the proposed method. Figures 10-13 compare C-CoCach without popularity inference and C-CoCach-Pop with popularity inference using Scenario 2 with 200 vehicles. By inferring content popularity and storing content with high popularity in a cluster, the in-cluster cache hit ratio is improved (Figure 13), and thus, the median latency for retrieving content is decreased (Figure 10). By shortening content delivery paths, the number of failures in content delivery is also decreased (Figure 11). Note that the overall cache hit ratio of C-CoCach-Pop is less than that of C-CoCach (Figure 12). The cache policy of C-CoCach is LRU, for which content popularity is irrelevant. Hence, vehicles store  
Figure 8: Median latency for retrieving the requested content with respect to cluster radius (Scenario 2). Figure 9: Success ratio of retrieving requested content with respect to cluster radius (Scenario 2). both popular and unpopular content in C-CoCach, which increases content variety, resulting in a higher cache-hit ratio. But this increases the probability that some popular content is replaced by non-popular content that must be fetched again later. These results confirm the effect of using popularity inference in the proposed method. In the following, we consider that all methods use popularity inference and evaluate their performance using Scenario 1 at first. Figure 11: Success ratio of retrieving requested content with respect to cache buffer size (Scenario 2). Figure 10: Median latency for retrieving the requested content with respect to cache buffer size (Scenario 2). Figure 14 and 15 show the median latency and the successful content reception ratio with respect to cache buffer size, respectively. Generally, a large cache buffer size enables the caching of more content, leading to small latency and a high success ratio in all methods. Compared with BCCN-Pop, the latency may be degraded a little in C-CoCach-Pop because almost all content goes through the CH, which increases the hop count. Compared with C-BCCN-Pop, which also uses clusters, the proposed C-CoCach-Pop method reduces the latency and increases the successful reception ratio in all ranges. This is because, with collaborative caching, more content can be fetched from local cache buffers, which reduces the hop count and also increases the successful reception ratio, as illustrated in Figure 15.  
Figure 12: Cache hit ratio with respect to cache buffer size (Scenario 2). Figure 13: In-cluster cache hit ratio with respect to cache buffer size (Scenario 2). Figures 16 and 17 show the cache hit ratio and in-cluster cache hit ratio, respectively, with respect to the cache buffer size. Both increase with the cache buffer size. The in-cluster cache hit ratio indicates the percentage of content that is retrieved in one hop within a cluster, and it is effectively improved by C-CoCach-Pop. This is also confirmed in Figure 18, which illustrates the distribution of hop counts required to retrieve content. Figure 14: Median latency for retrieving the requested content with respect to cache buffer size. (Scenario 1). Figure 15: Success ratio of retrieving requested content with respect to cache buffer size (Scenario 1). Figure 19 shows the average channel usage when the buffer size is 100. BCCN-Pop has the lowest channel usage, and implementing collaborative caching increases the overhead. When considering the methods using clustering, C-CoCach-Pop may cause more overhead in cache management. But actually, the results show that C-CoCach-Pop has less channel usage than C-BCCN-Pop, which indicates that the reduction in channel usage by collaborative caching is greater than that caused by the management overhead. Figure 16: Cache hit ratio with respect to cache buffer size (Scenario 1). Figure 9:0 In-cluster cache hit ratio with respect to cache buffer size (Scenario 1). Next, we investigated the impact of vehicle density.