# Optimal Proactive Caching for Multi-View Streaming Mobile Augmented Reality
## 4 Numerical Investigations
### Simulation Results and Discussion  
According to Figure 6, an increasing weight (\(\mu\)) leads to a dropping overall delay as expected. A larger weight means that the proposed Optim scheme targets a solution with less latency and is willing to sacrifice some preference for this in terms of importance. As a result, the Optim scheme tends to proactively cache fewer view streams with fewer embedded AROs, and such a decision naturally results in a reduced overall delay in transmission and computation. As shown by Table 3, it is interesting to point out that when the emphasis is placed solely in delay reduction (\(\mu=1\)) and without considering user mobility, the proposed Optim scheme closely relates to the other greedy baseline schemes. This means those schemes commonly tend to anchor view streams with embedded AROs as close as possible to the user. However, the Optim scheme is still superior to others and is around \(15.5\%\) better than the CFS scheme in this case because its service decomposition and separation of view streams enables flexible allocation and hence avoids overloading. In addition, it is worth pointing out that solutions offered from other greedy schemes sometimes provide non-feasible solutions due to constraints violations. Thus, the Optim scheme significantly outperforms other schemes especially in a high mobility scenario and/or in the cases where changes of the point of attachment take place during the service time. The observed gains between the proposed Optim scheme and other baseline schemes also increase with overall delay when continuously seeking a larger preference and caching a higher number of view streams and AROs. Because the UTIL scheme prevents further transmitted requests when the activated ECs reach the \(80\%\) occupation limit, it becomes the most sensitive scheme to the weight \(\mu\) and hence its performance is heavily affected in a congested network. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline Number of available ECs & \([4,8]\) \\ \hline Number of available VMs per EC (EC Capacity) & \([10,14]\) \\ \hline Number of requests & \([20,40]\) \\ \hline Number of view streams per user & 4 \\ \hline AR object size & \((0,20)\) MByte \\ \hline Total moving probability & \([0,1]\) \\ \hline Cell radius & \(250\)m \\ \hline Remained cache capacity per EC & \([100,400]\) MByte \\ \hline CPU frequency & \([2,4]\) GHz \\ \hline CPU cores & \([4,8]\) \\ \hline CPU portion per VM & \(0.125\)–\(0.25\) \\ \hline Computation load & \(10\) cycles/bit \\ \hline Bandwidth of access router & \(20\) MHz \\ \hline Power of access router & \(20\) dBm \\ \hline Path loss exponent & \(4\) \\ \hline Noise power & \(10^{-11}\) dBm \\ \hline Number of resource blocks & \(100\) \\ \hline Average hop’s latency & \(2\) ms \\ \hline Cache miss penalty & \(25\) ms \\ \hline Number of user route vectors/optimal decisions & \(300\) \\ \hline Initial LSTM learning rate & \(0.005\) \\ \hline Maximum number of epochs & \(160\) \\ \hline LSTM dropout probability & \(5\%\) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Simulation parameters. Figure 7 shows the relation between preference and weight (\(\mu\)) and further reveals the advantage of the proposed Optim scheme in preference. Noticing that even in the extreme case when \(\mu=1\), the proposed Optim scheme still achieves approximately 59.6% preference due to its optimized selection of the most preferred view streams with the most popular AROs set inside. This means the proposed Optim scheme minimizes the cost of weight by exploring preference when seeking to reduce service latency. According to Figure 8, the service delay increases when the network congestion levels increase due to a higher number of requests from the users. The LSTM scheme shows a 5.6%  
Figure 6: Service delay with weight \(\mu\) (6 EC, 30 requests, EC capacity is 14 and total mobility probability is 1). CFS [34]; UTIL [35].