# Optimal Mobility-Aware Wireless Edge Cloud Support for the Metaverse
## 3 System Model
### Latency, Energy Consumption and Quality of Perception Experience
\[z_{rj}=1-q_{rj},\ \forall j\in\mathbf{M},r\in\mathbf{R}\] (33b) \[\sum_{r\in\mathbf{R}}(x_{rj}+y_{rj})\leq\Delta_{j},\forall j\in \mathbf{M},j\
eq j_{r}\] (33c) \[\sum_{j\in\mathbf{M}}x_{rj}=1,\forall r\in\mathbf{R}\] (33d) \[\sum_{j\in\mathbf{M},j\
eq j_{r}}y_{rj}=1,\forall r\in\mathbf{R}\] (33e) \[\zeta_{rij}\leq x_{ri},\ \forall r\in\mathbf{R},i,j\in \mathbf{M},j\
eq j_{r}\] (33f) \[\tilde{\zeta}_{rij}\leq y_{rj},\ \forall r\in\mathbf{R},i,j\in \mathbf{M},j\
eq j_{r}\] (33g) \[\zeta_{rij}\geq x_{ri}+y_{rj}-1,\ \forall r\in\mathbf{R},i,j\in \mathbf{M},j\
eq j_{r}\] (33h) \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]0 (33i) \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]1 (33j) \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]2 (33k) \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]3 \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]4 \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]5 (33l) \[\eqref{eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq:eq: eq:eq  
A nominal tree-like network topology, as shown in Figure 4, was applied with 20 ECs in total, 6 ECs being activated for the current metaverse AR service and 30 requests being sent by MAR devices. The remaining available resources allocated for metaverse AR support within an EC were assumed to be CPUs with frequencies of 4 to 8 GHz, CPU-chip architecture coefficient of \(10^{-18}\) (affected by the chip's design and structure) [5], 4 to 8 cores and \([100,400]\) MBytes of cache memory [12]. Similarly, the mobiles AR devices were assumed to have a CPU with 1 GHz frequency, 4 cores and \([0,100]MBytes\) available cache memory for metaverse AR applications [17]. According to [15], the power of AR applications should not exceed 50% of the mobile device's CPU total power (2-3 W), so that other functionalities can operate efficiently. Hereafter, a nominal frame rate of 15 frames/second is assumed and the rendering takes place every other frame (\(\hat{1}33.2\) ms interval) [30; 31; 32]. Thus, the service delay of the aforementioned work flow within the above time interval could be regarded as acceptable. Each request requires a single free resource unit for each service function, such as, for example, a virtual machine (VM) [33]. Up to 14 available VMs are assumed in each EC, with equal splitting of the available CPU resources [12]. Note that different view ports lead to different models of the metaverse [9] and up to four different models can be cached. All target AROs must be integrated into the corresponding model and rendered within the frame before being streamed to the end user based on a matched result. After triggering the metaverse MAR service, pointers to identify AROs such as a name or index are usually a few bytes [34] and, hence, their transmission and processing are neglected in the following simulations. The set of available data rates is \(\{2,3,\ldots,8\}\) Mbps and its corresponding SSIM values set are \(\{0.955,0.968,\ldots,0.991\}\)[10]. We require the acceptable average SSIM above 0.97 (\(Q_{bound}\)). For a nominal 5 G base station, we assume its cell radius to be 250 m, its carrier frequency 2 GHz, its transmit power 20 dBm, the noise power \(10^{-11}\) W, the path loss exponent to be 4, its maximum resource blocks 100 and, without the loss of generality, each user can utilize only one resource block [35; 36; 37]. As mentioned earlier, we accept a predefined video coding scheme H.264 with a fixed frame resolution of 1280 \(\times\) 720 [10] in RGB (8 bits per pixel). Based on the given resolution, the size of foreground interactions after decoding and compressing can be calculated through multiplying the coefficients \(\frac{\kappa}{9}\) and \(10^{-3}\)[9]. Matlab on a personal PC with a CPU of intel i7, 6500U and 2 cores was employed for the simulation. Key simulation parameters are shown below, in \[\frac{Q}{Q_{max}}\geq Q_{bound} \tag{32}\]6  
In the following figures and discussion, the optimized scheme considering terminals is denoted as OptimT, while the other onem which does not include the terminals, is denoted as as OptimNT.