# Optimal Proactive Caching for Multi-View Streaming Mobile Augmented Reality
## 3 System Model  
### Multi-View Streaming AR  
We define with the set \(\mathbb{M}=\{1,2,\ldots,M\}\) the available edge clouds (ECs) in the wireless network. With \(r\in\mathbb{R}\), we denote the MAR service requests that are generated by mobile users that are equipped with MAR devices (each user makes a single request). As already mentioned in previous sections, a set of AROs is assumed to be embedded across the different non real-time view streams. To this end, we first define a set \(\mathbb{N}=\{1,2,\ldots,N\}\) to represent the set of available AROs. The video content available to each user has multiple streams, and we define them as a set \(\mathbb{S}_{r}=\{1,2,\ldots,S\}\). Then, the decision variable for proactively caching a view stream \(s\) at the EC \(j\in\mathbb{M}\) is denoted as \(p_{sj}\). The subset \(\mathbb{L}_{rs}\) represents the target AROs required by the user \(r\) in view stream \(s\in\mathbb{S}_{r}\) and the size of each target ARO \(l\in\mathbb{L}_{rs}\) is denoted as \(O_{l}\). Finally, the decision variable for proactively caching an ARO required by a request \(r\) is denoted as \(h_{rl}^{s}\). More specifically, \(p_{sj}\) and \(h_{rl}^{s}\) can be written as follows,  
\[p_{sj}= \begin{cases}1,\text{if view stream $s$ is cached at node $j$},\\ 0,\text{otherwise}.\end{cases}  \tag{1}\]\[h_{rl}^{s}= \begin{cases}1,\text{ if ARO }l\text{ required by request }r\text{ embedded}\\ \text{ in view stream }s\text{ is cached,}\\ 0,\text{ otherwise.}\end{cases}  \tag{2}\]  
in addition to the above, the following constraints should also be satisfied,  
\[\sum_{r\in\mathbf{R}}h_{rl}^{s}\leqslant 1,\ \forall j\in\mathbf{M},\ \forall s \in\mathbf{S_{r}},\ \forall l\in\mathbf{L_{rs}} \tag{3}\]  
\[\sum_{s\in\mathbf{S_{r}}}h_{rl}^{s}\geqslant 1,\ \forall r\in\mathbf{R} \tag{4}\]  
\[\sum_{j\in\mathbf{M}}p_{sj}\geqslant h_{rl}^{s},\ \forall r\in\mathbf{R},\ \forall s \in\mathbf{S_{r}},\ \forall l\in\mathbf{L_{rs}} \tag{5}\]  
\[h_{rl}^{s}\leqslant h_{rl}^{s}\sum_{j\in\mathbf{M}}p_{sj},\ \forall r\in\mathbf{R},\ \forall s \in\mathbf{S_{r}},\ \forall l\in\mathbf{L_{rs}} \tag{6}\]  
The constraints in (3) ensure that each ARO can be cached at most once in a view stream. The constraints in (4) ensure that at least one view stream and an ARO is required to compose a valid request. The constraints in (5) guarantee that the ARO must be allocated to a view stream first before deciding to proactively cache it, and the constraints in (6) certify that any ARO planned to be stored in this view stream should not be cached when deciding not to proactively cache a view stream at all. Constraints (5) and (6) together ensure that either the view stream or ARO cannot be handled alone during the formulation. As alluded earlier, due to the resource constraints in the network, in case of congestion episodes, an optimized subset of view streams and embedded AROs need to be proactively cached at suitable ECs. Thus, we bring in the user preference for both view streams and AROs. The preference of view streams and embedded AROs are measured by their requesting probability, which enables the proposed scheme to select the more popular ones. The probability of selecting a view stream \(s\) is denoted as \(t_{s}\) and the probability of requiring an ARO \(l\) is denoted as \(t_{l}\). Such probabilities are pre-defined and could be achieved by exploring historical data; hereafter we assume that we have access to such information. Thus, we further define \(\mathbb{T}_{1}\) and \(\mathbb{T}_{s}\), respectively to represent two descending probability vectors of AROs and view streams. The probability \(t_{l}\) and \(t_{s}\) inside can be generated through,  
\[t_{l}= \begin{cases}1,\text{ if }l=1,\\ \text{rand }(t_{l-1}),\text{ if }l>1.\end{cases}  \tag{7}\]  
\[t_{s}= \begin{cases}1,\text{ if }s=1,\\ \text{rand }(t_{s-1}),\text{ if }s>1.\end{cases}  \tag{8}\]  
where the function \(\text{rand}(x)\) generates a random number within \([0,x]\).