Multiuser Access Control for 360° VR Video Service Systems Exploiting Proactive Caching and Mobile Edge Computing

Abstract

Mobile virtual reality (VR) is considered a killer application for future mobile broadband networks. However, for cloud VR, the long content delivery path and time-varying transmission rate from the content provider’s cloud VR server to the users make the quality-of-service (QoS) provisioning for VR users very challenging. To this end, in this paper, we design a 360° VR video service system that leverages proactive caching and mobile edge computing (MEC) technologies. Furthermore, we propose a multiuser access control algorithm tailored to the system, based on analytical results of the delay violation probability, which is derived considering the impact of both the multi-hop wired network from the cloud VR server to the MEC server and the wireless network from the MEC server-connected base station (BS) to the users. The proposed access control algorithm aims to maximize the number of served users by exploiting real-time and dynamic network resources, while ensuring that the end-to-end delay violation probability for each accessed user remains within an acceptable limit. Simulation results are presented to analyze the impact of diverse system parameters on both the user access probability and the delay violation probability of the accessed users, demonstrating the effectiveness of the proposed multiuser access control algorithm. It is observed in the simulation that increasing the computing capacity of the MEC server or the communication bandwidth of the BS is one of the most effective methods to accommodate more users for the system. In the tested scenarios, when the MEC server’s computing capacity (the BS’s bandwidth) increases from 0.8 Tbps (50 MHz) to 3.2 Tbps (150 MHz), the user access probability improves on average by 92.53% (85.49%).

1. Introduction

Mobile virtual reality (VR) technology is expected to become one of the killer applications for future mobile broadband networks. It involves to the transmission of mobile VR video and audio files from cloud servers to user terminal devices, such as head-mounted displays (HMDs), through multi-hop networks, enabling the storage and rendering of VR content by cloud or edge servers [1]. As an example, because of the COVID-19 pandemic, VR-based educational technologies have been drawing increased attention [2]. As a unique application within the broader field of VR, 360° VR allows users to freely explore and interact with their surroundings from every angle. It has received increasing attention because of its capability of providing users with an immersive experience. However, for current network technologies, delivering 360° VR videos, which require high bandwidth, low transmission latency, and substantial computational resources, is still challenging [3].

To alleviate network burden and provide a better viewing experience for VR users, researchers have conducted extensive studies on various aspects. Given the large data transmission requirements of VR, proactive caching of VR videos based on user field-of-view (FoV) prediction is regarded as a key technique to meet the service delay demands [4,5]. In addition, rendering and processing high-definition VR video frames requires substantial computing resources, while lightweight HMDs often have limited computing capacity, making mobile edge computing (MEC) a key enabling technology for mobile VR applications [6,7].

1.1. Related Work

From the perspective of an individual VR user, although user behavior can change arbitrarily over time, studies show that head movement in VR can be predicted with high accuracy within a few hundred milliseconds [8]. Therefore, FoV prediction can be used to pre-fetch the required content for the user, reducing the operational load on data transmission and image processing imposed by real-time application demands [4]. To enhance the quality of personal experience, in [5], a decentralized and personalized federated learning (DP-FL)-based caching strategy is proposed to predict the FoV of each VR user in a multi-base station (BS) wireless network. To meet the demand for low latency and high bandwidth of VR, in [9], the authors propose a cloud-edge collaborative caching strategy, where the background content is pre-cached at the edge nodes and interactive content is generated by an AI-aided cloud-edge collaborative system. To minimize the system’s long-term energy expenditure, in [10], the authors propose a cross-layer joint design scheme that integrates multi-MEC server collaborative video caching, multi-point cooperative transmission between BSs, and beamforming with reconfigurable intelligent surfaces. However, the aforementioned studies on caching strategy design for VR service focus more on improving cache hit ratio under storage constraint, thus neglecting the impact of time-varying transmission rate on either the wired network from the content server to the MEC server or the wireless network from the MEC-connected BS to the VR users.

In the literature, jointly designing proactive caching with computing offloading is an important approach to enhancing VR video services. Aiming to maximize the average tolerable delay, in [11], the authors investigate the optimal caching and computing offloading decision scheme in a single-user, single-MEC server scenario. The problem is modeled as a multi-choice multidimensional knapsack problem, and the optimal decision is obtained after transforming it into a Lagrangian relaxation problem. Similarly, in [12], the optimal caching and computing offloading decisions are studied for a single-user, single-MEC server setting, to minimize the average transmission rate of VR videos. For VR videos stored in the cloud server, an MEC-based 360° mobile VR video streaming scheme with FoV prediction is proposed in [13], which jointly considers video coding, proactive caching, computing offloading, and data transmission. Considering that the cached video still requires rendering through the MEC server’s computing offloading, in [14], content caching and computing offloading for rendering are jointly designed with a rendering-aware multi-MEC server collaborative caching optimization method. For multi-user VR scenarios, in [15], the authors study a similar problem to that in [14]. To address the challenges of QoS provisioning of VR users under partial observation in decentralized networks, in [16], the authors propose a distributed computing framework based on multi-agent deep deterministic policy gradient (MADDPG) for joint optimizing terminal-cooperative caching and offloading for VR tasks. Although the aforementioned works propose various efficient solutions to jointly utilize proactive caching and computing offloading for VR, most of them overlook the issue of how VR video data are transmitted from the data source (e.g., the cloud VR server) to the network edge, again neglecting the impact of time-varying transmission rate on the end-to-end (E2E) transmission path. On the other hand, there is no work proposing multiuser access control algorithms tailored to VR systems by exploiting both proactive caching and computing offloading, while taking into account the real-time and dynamic network resources.

When 360° VR applications are deployed in the cloud, there is an increasing need for a holistic solution that can optimize network resource allocation dynamically over the entire network—from the content provider’s cloud VR server, through the operator’s MEC server, to the users—taking into account both multi-hop wired and single-hop wireless networks. While some existing studies do consider the multi-hop wired network between the cloud VR server and the MEC server, they typically assume a simplified transmission model; for example, with a fixed transmission rate (e.g., [4,14]). To fill this gap, this paper focuses not only on designing a 360° VR video service system that leverages proactive caching and MEC technologies, but also on proposing a multiuser access control algorithm tailored to the system by exploiting the real-time and dynamic network resources and considering the impact of the time-varying transmission rate over both the multi-hop wired network from the cloud VR server to the MEC server and the wireless network from the MEC server-connected BS to the VR users.

1.2. Motivation and Contributions

On all these counts, in this paper, we focus on solving the following challenges for 360° VR service system design:

• How to design the multiuser access control algorithm for a 360° VR video service system, considering the impact of both the multi-hop wired network from the content provider’s cloud VR server to the operator’s MEC server, and the wireless network from the MEC server-connected BS to the users?
• How to harvest the benefits of proactive caching and computing offloading from the MEC server in the multiuser access control algorithm design?

To address these challenges, this paper aims to propose a 360° VR video multiuser access control algorithm in a scenario where the cloud server, the MEC server, and multiple VR users work together. Our main contributions are summarized as follows:

• To strictly control the latency and user experience quality of 360° VR video transmissions, a 360° VR video service system based on proactive caching and mobile edge computing is designed from the perspective of comprehensively utilizing the three resources—transmission, storage, and computation—across the cloud server, the edge computing server, and the user devices.
• For the designed system, we analyze each user’s E2E delay performance, if accessed, in terms of delay violation probability. Then, we study the multiuser access control optimization problem aimed at maximizing the number of served users by exploiting real-time and dynamic network resources, subject to users’ delay violation probability threshold.
• Simulation results not only validate the effectiveness of the proposed multiuser access control algorithm in admitting users with well-controlled delay violation probabilities but also shed some light on the influence of various system parameters (e.g., the caching duration, the BS’s transmission bandwidth, the MEC server’s computational capability, and the video compression ratio) on system performance.

1.3. Paper Organization

The remainder of this paper is organized as follows: Section 2 first introduces the methodology of the work, then presents the designed 360° mobile VR video service system, and formulates the multiuser access control problem. Section 3 introduces the design of the multiuser access control algorithm. Section 4 discusses the simulation results. Section 5 concludes the paper.

2. Methodology, System Description, and Problem Formulation

2.1. Methodology

Figure 1 illustrates the methodology of this work. By utilizing proactive caching and mobile edge computing technologies, we firstly design the 360° VR video service system in Section 2.2, where we detail the workflow and latency model, video coding and FoV prediction model, and fairness-oriented transmission and computing resource allocation strategy. Based on the system design, in Section 2.3, we formulate the multiuser access control problem as a probability-constrained integer programming problem. In Section 3.1.1, we analyze the E2E delay using the diffusion process analysis method, whereby we derive the delay violation probability for the users who are granted access in the system, as presented in Section 3.1.2. Finally, by exploring the relationship between communication and computing resource consumption and the users’ delay violation probability, we design an efficient solver for the multiuser access control problem in Section 3.2.

2.2. System Description

As shown in Figure 2, the proposed 360° VR video service system consists of a cloud server, an MEC server, and multiple video users accessing the service. The cloud server provides functions such as video storage, tile encoding and selection, saliency map generation, and FoV prediction. To fully utilize the computational power of the MEC server, it is responsible for decoding, rendering, and re-encoding the proactively cached data packets that are hit by the users, and then sending them to the users. In addition to receiving data from the MEC server, each user may also need the cloud server to provide data packets that were not hit by the MEC server. For these data packets, the user needs to decode and render them independently, and ultimately combine the data obtained from both the MEC and cloud servers to construct a displayable image.

2.2.1. Workflow and Latency Model

The workflow of the proposed 360° VR video service system is illustrated in Figure 3. In the figure, we detail the operation process of period l. Each period consists of a caching stage and a computation and transmission stage:

• Caching Stage: The duration of this stage is D₁. During the caching stage, the users watch the video tiles received in the previous period. At the same time, the MEC server caches the video tiles that all users may need to watch in the next period, based on the FoV prediction results from the cloud server.
• Computation and Transmission Stage: The duration of this stage for user i is $D_{\mathrm{M},l}^{(i)}$, which starts when user i finishes watching the video tiles obtained from the previous period and ends when the user can start watching the video tiles obtained during this period. For each accessed user i, this stage includes the computation sub-stage delay $D_{2,l}^{(i)}$ at the MEC server, the transmission sub-stage delay $D_{3,l}^{(i)}$ from the MEC server to the user, the transmission sub-stage delay $D_{4,l}^{(i)}$ from the cloud server to the user, and the computation sub-stage delay $D_{5,l}^{(i)}$ at the user. Obviously, the aforementioned delay components of any user i depend on the amount of transmission and computing resources to be allocated to the user, which will be discussed in Section 2.2.3. Therefore, for accessed user i, the E2E delay in period l, which is the duration of the computation and transmission stage $D_{\mathrm{M},l}^{(i)}$, consists of four parts:

  $$D_{\mathrm{M},l}^{(i)}=D_{2,l}^{(i)}+D_{3,l}^{(i)}+D_{4,l}^{(i)}+D_{5,l}^{(i)}$$

  (1)

  Typically, when the E2E delay exceeds a certain threshold D_th, users may experience dizziness, and the quality of experience significantly decreases. Therefore, when multiple users are simultaneously receiving 360° VR video services, we need to ensure that the probability of each accessed user’s E2E delay exceeding the duration D_th, $P(D_{\mathrm{M},l}^{(i)}>D_{\mathrm{th}})$, is sufficiently small. To ensure fairness, a good 360° VR video service system should well maintain this probability for each accessed user without any priority distinction. It is also noteworthy that the E2E delay studied here excludes the impact of cache speed. That is, we assume that the cache speed is high enough so as not to affect the E2E delay.

2.2.2. Video Coding and FoV Prediction Model

The tile-based 360° VR video encoding and FoV prediction model at the cloud server is illustrated using Figure 4.

• Video Coding: First, a 360° video block l with a frame rate of f is mapped into a 2-D video plane using an equirectangular projection (ERP), covering an angular range of 180° × 360°. Then, it is divided into N × M tiles, with each tile having a data size of B bits/tile/frame. Since encoding and compression in the cloud server rely on both spatial and temporal correlations of the images, the user or MEC server needs all the video frames of a tile to decode the data packet of that tile. Different tiles are encoded and compressed separately, and even if the FoV region only covers part of a tile, the entire tile must be transmitted. If the FoV region has a size of k × k tiles, the typical video transmission request region size equals (k + 1)² tiles, with the viewpoint potentially falling on any tile in the video plane.
• FoV Prediction Model: To facilitate the MEC server in providing a unified proactive caching service for 360° VR video to all accessed users, the designed video service system lets the cloud server predict the user’s FoV based on a saliency map generated from the video. The cloud server then provides the MEC server with data caching based on the predicted probability. As shown in Figure 4, at the start of period l, the cloud server can first generate the saliency map using a convolution neural network (CNN) + long short-term memory (LSTM) + Gaussian mixture model (GMM) multilayer network, as proposed in [17]. Then, using the LSTM network proposed in [18], it generates the probability matrix $P_{\mathrm{F}}(n_l,m_l)={\left[P_{\mathrm{F}}(n_l,m_l)\right]}_{N\times M}$ for the tiles that will be viewed in the next period, based on the saliency map. Here, the element $P_{\mathrm{F}}(n_l,m_l)$ represents the probability of the tile at coordinate $(n_l,m_l)$ being viewed. Since $P_{\mathrm{F}}(n_l,m_l)$ is derived only from the saliency map, it can be pre-computed offline and is the same for any served users.

2.2.3. Fairness-Oriented Transmission and Computing Resource Allocation

In the proposed 360° VR video service system, to ensure fair service for users based on real-time and dynamic network resources, the resources for the transmissions from the MEC server-connected BS to the users, for the transmissions from the cloud server to the users, as well as the computing resources of the MEC server, should all be reasonably allocated.

• Equal-Rate Transmission Resource Allocation: Let $x=(x_1,x_2,\dots ,x_I)$ represent the user access indicator vector, where x_i = 1 indicates that user i is allowed to be admitted or accessed, and x_i = 0 indicates the opposite. Although we aim to ensure fairness in the service provided to each accessed user, when the system adopts different user access combinations x, the transmission rate received by an accessed user will change. Let R₁(t) represent the instantaneous transmission rate from the cloud server to the MEC server at time t; R_2,x(t) and R_3,x(t) represent the instantaneous transmission rates from the MEC server to any accessed user, and from the cloud server to any accessed user at time t, respectively, under equal-rate resource allocation and user access combination x. The transmission rate of the wired network can be estimated based on the transmission bandwidth; the transmission rate of the wireless network can be assessed based on the BS’s spectrum resources, transmission power, and channel information between the users and the BS. The channel information between any user and the BS can be obtained through user-reported measurements and reference signal strength. Without loss of generality, to model the impact of the network dynamics on the video packet transmissions, similar to [19], we assume that, when video packets are transmitted along each of the three paths, i.e., from the cloud server to the MEC server, from the MEC server to the user, and from the cloud server to the user, the inter-arrival times of video packets follow a given but arbitrary distribution, with mean $1/{\lambda }_1=\mathrm{E}[s/R_1(t)]$ and $1/{\lambda }_{p,x}=\mathrm{E}[s/R_{p,x}(t)]$, and variance $V_1=\mathrm{Var}[s/R_1(t)]$ and $V_{p,x}=\mathrm{Var}[s/R_{p,x}(t)]$, where p = 2, 3; s represents the video packet size; $\mathrm{E}(\cdot )$ denotes the expectation; and $\mathrm{Var}(\cdot )$ denotes the variance. Because we do not impose constraints on the packet inter-arrival time distribution, except for the measurable mean and variance, which can be re-estimated with time if the network dynamics are time-varying, network dynamic characteristics are considered in our model.
  Proportional Computing Resource Allocation: In the computation stage of the MEC server, the MEC server needs to allocate computing resources to different users to complete the task of offloading cached data. In general, the computing resource allocation strategy at the MEC server can be designed from either a user or a tile perspective. From the user’s perspective, computing resources are exclusively allocated to each user, making fewer chances to reuse computing resources among users due to the neglect of common hit tiles of different users. As such, in this work, we adopt the tile-based strategy design. Specifically, we allocate computing resources to tiles in a proportional way according to the number of users hit each tile, which is beneficial to improve user fairness specifically when the computing resources are insufficient. Specifically, let H(n, m) represent the number of users that hit the tile at coordinate (n, m) cached by the MEC server. The MEC server’s cached tiles are classified based on H(n, m): let $B_q=\left\{\left(n,m\right)|H(n,m)=q\right\}$ denote the set of tiles cached by the MEC server and hit by q users, where $\left|B_q\right|\in \left\{0,1,\dots ,{(k+1)}^2\right\}$, $q\in \{0,1,2,\dots ,I\}$. To make efficient use of the MEC server’s computing resources, the computing resource W_q allocated to B_q satisfies:

  $$W_q={\displaystyle \frac{W_{\mathrm{M}}}{{\displaystyle {\sum }_{q=1}^I\left|B_q\right|}}}\cdot |B_q|$$

  (2)

  where W_M represents the computing capacity of the MEC server, in bit/s. In the analysis in the next section, we will find that one advantage of using this computing resource allocation strategy is that the computation completion times for all B_q are the same, meaning that the computing offloading is fair for the users.

2.3. Problem Formulation

To maximize the utilization of bandwidth resources and ensure the quality of service (QoS) for all users, we aim to design an optimal multiuser access control method for the above system by exploiting the real-time and dynamic network resources. We consider a scenario in which there are I users requesting to access the system to watch the same 360° VR video. We need to find the best user access decision from the 2^I access strategies. To maximize the number of users served by the system while ensuring the QoS for each accessed user, the following probability-constrained integer programming problem can be used to decide the user access control method:

$$\underset{x}{\max }{\displaystyle \sum _{i=1}^{I}1(P_{\mathrm{out}}^{(i)}(x)\le \delta )}$$

(3)

where $1(\cdot )$ is the indicator function, satisfying that $1(Event)=1$ if “Event” is true, and $1(Event)=0$ otherwise; $P_{\mathrm{out}}^{(i)}(x)$ represents the delay violation probability of user i when the given user access indicator vector is $x$; and δ is the threshold for the delay violation probability that must be guaranteed to ensure the QoS for all admitted 360° VR video users.

The delay violation probability of user i can be defined as the average probability that the E2E delay $D_{\mathrm{M},l}^{(i)}$ in each video playback period l, from the time when user i issues a real FoV request to the time when the user can watch a new video block, exceeds the threshold D_th during the entire video playback process:

$$P_{\mathrm{out}}^{(i)}(x)={\displaystyle \frac{1}{L}}{\displaystyle \sum _{l=1}^{L}P(D_{\mathrm{M},l}^{(i)}>D_{\mathrm{th}})}$$

(4)

where L is the total number of video playback periods. We will derive the expression of the delay violation probability in the next section.

3. Algorithm Design

In this section, supposing that the users indicated by access indicator vector x are accessed in the system, we first analyze the delay distribution of each stage within each period and then derive the calculation method for the delay violation probability. Based on the analysis results, we then design the multiuser access control algorithm to solve the optimization problem (3).

3.1. Performance Analysis

3.1.1. Delay Analysis

• Caching Stage

The key to analyzing this stage is to obtain the distribution of the number of data packets k cached by the MEC server at the end of the caching duration D₁. By applying the diffusion process analysis method proposed in [13], the conditional probability density function of k can be expressed as:

$$p\left(k,D_1\left|0\right.\right)={\displaystyle \frac{1}{\sqrt{2\pi {\beta }_1{t}_1}}}\cdot \left\{\left.\exp \left[-{\displaystyle \frac{{\left(k-{\alpha }_1{D}_1\right)}^2}{2{\beta }_1{D}_1}}\right]-\exp \left[{\displaystyle \frac{2{\alpha }_1{b}_1}{{\beta }_1}}-{\displaystyle \frac{{\left(k-2b_1-{\alpha }_1{D}_1\right)}^2}{2{\beta }_1{D}_1}}\right]\right\}\right.$$

(5)

where α₁ and β₁ are the drift coefficient and diffusion coefficient for the transmission from the cloud server to the MEC server, respectively, satisfying ${\alpha }_1={\lambda }_1$ and ${\beta }_1={\alpha }_1^3{V}_1$ [13]; $b_1=D_{1}fMN⌈B{C}_{\mathrm{r}}/s⌉$ represents the maximum number of data packets that the MEC server can cache for all MN tiles during the caching duration D₁. Here, f denotes the video frame rate, B is the data size per tile per frame, and C_r is the ratio of the data size after compression to the data size before compression.

Furthermore, we can obtain the probability mass function of the number of tiles G_l cached by the MEC server at the end of the caching stage:

$$P(G_l=g)={\displaystyle {\int }_{D_{1}fg⌈B{C}_{\mathrm{r}}/s⌉}^{D_{1}f(g+1)⌈B{C}_{\mathrm{r}}/s⌉}p(k,D_1\left|0\right.)dk}$$

(6)

2.

Computation Sub-stage of the MEC Server

When the MEC server applies the proportional computing resource allocation strategy proposed in Section 2.2.3, the computing resource allocated to the tiles cached by the MEC server and hit by q users satisfies Equation (2), and the total data size for computing offloading is $M_q=\left|B_q\right|D_{1}fB$, which is determined by the number of these tiles, $\left|B_q\right|$. Therefore, the computation delay $D_{2,l}^{(i)}$ required by the MEC server can be expressed as:

$$D_{2,l}^{(i)}={\displaystyle \frac{M_q}{W_q}}={\displaystyle \frac{D_{1}fB{\displaystyle {\sum }_{q=1}^I\left|B_q\right|}}{W_{\mathrm{M}}}}$$

(7)

It is noteworthy that, similar to [20,21], the computation delay is assumed to be proportional to the size of the raw video data to be processed. As seen from Equation (7), the delay in this stage for the MEC server is independent of the users. Therefore, the conditional probability mass function of the computation sub-stage delay $D_{2,l}^{(i)}$ for the MEC server can be expressed as:

$$P(D_{2,l}^{(i)}={\displaystyle \frac{D_{1}fB{\displaystyle {\sum }_{q=1}^I\left|B_q\right|}}{W_{\mathrm{M}}}}\left|A_{c,l}\right.,A_{\mathrm{r},l})=1$$

(8)

where $A_{\mathrm{c},l}={\left[a_{\mathrm{c},l}(n,m)\right]}_{N\times M}$ is the caching matrix, with elements $a_{\mathrm{c},l}(n,m)\in \{0,1\}$ representing the caching status of the tile at coordinate (n, m) in the MEC server at the end of the caching stage of the l-th period; $A_{\mathrm{r},l}=\left\{A_{\mathrm{r},l}^{(i)}|x_i=1,i=1,2,\dots ,I\right\}$ represents the set of request matrices for all accessed users at the start of the computation sub-phase in the l-th period, with elements $A_{\mathrm{r},l}^{(i)}={\left[a_{\mathrm{r},l}^{(i)}(n,m)\right]}_{N\times M}$ being the request matrix of accessed user i, and $a_{\mathrm{r},l}^{(i)}(n,m)\in \{0,1\}$ indicating whether the tile at coordinate (n, m) is within the FoV of user i at that time.

3.

Transmission Sub-stage from the MEC Server to User i

Similarly, by applying the diffusion process analysis method proposed in [13], the probability density function of the transmission sub-stage delay $D_{3,l}^{(i)}$ from the MEC server to user i can be expressed as:

$$p_{D_{3,l}^{(i)}}(D_{3,l}^{(i)}=t_2\left|A_{\mathrm{c},l}\right.,A_{\mathrm{r},l})={\displaystyle \frac{b_{2,l}^{(i)}}{\sqrt{2\pi {\beta }_{2,x}{t}_2^3}}}\exp \left\{-{\displaystyle \frac{{(b_{2,l}^{(i)}-{\alpha }_{2,x}{t}_2)}^2}{2{\beta }_{2,x}{t}_2}}\right\}$$

(9)

where α_2,x and β_2,x are the drift coefficient and diffusion coefficient, respectively, for the transmission from the MEC server to any accessed user given the equal-rate resource allocation strategy implemented at the BS and the user access indicator vector x, satisfying ${\alpha }_{2,x}={\lambda }_{2,x}$ and ${\beta }_{2,x}={\alpha }_{2,x}^3{V}_{2,x}$ [13]; $b_{2,l}^{(i)}=⌈{\mathrm{\Gamma }}_{1,l}^{(i)}h{C}_{\mathrm{r}}/s⌉$ represents the number of data packets after computing offloading by the MEC server for user i, with ${\mathrm{\Gamma }}_{1,l}^{(i)}=Q_l^{(i)}{D}_{1}fB$ denoting the amount of data cached by the MEC server and hit by user i, $Q_l^{(i)}$ being the number of tiles hit by user i, and h representing the data size ratio between the computation output and input at the MEC server.

4.

Transmission Sub-stage from the Cloud Server to User i

The data size of the tile that the cloud server needs to retransmit to user i is equal to:

$${\mathrm{\Gamma }}_{2,l}^{(i)}=D_{1}fB(E_l^{(i)}-Q_l^{(i)})$$

(10)

where $E_l^{(i)}$ represents the number of tiles in the actual FoV of user i during the l-th period.

Similar to Equation (9), the conditional probability density function of the transmission sub-stage delay $D_{4,l}^{(i)}$ from the cloud server to user i can be calculated as:

$$p_{D_{4,l}^{(i)}}(D_{4,l}^{(i)}=t_3\left|A_{\mathrm{c},l}\right.,A_{\mathrm{r},l})={\displaystyle \frac{b_{3,l}^{(i)}}{\sqrt{2\pi {\beta }_{3,x}{t}_3^3}}}\exp \left\{-{\displaystyle \frac{{(b_{3,l}^{(i)}-{\alpha }_{3,x}{t}_3)}^2}{2{\beta }_{3,x}{t}_3}}\right\}$$

(11)

where $b_{3,l}^{(i)}=⌈{\mathrm{\Gamma }}_{2,l}^{(i)}{C}_{\mathrm{r}}/s⌉$ represents the total number of data packets that the cloud server needs to retransmit to user i; α_3,x and β_3,x are the drift coefficient and diffusion coefficient, respectively, for the transmission from the cloud server to any accessed user under equal-rate resource allocation and the user access indicator vector x, satisfying ${\alpha }_{3,x}={\lambda }_{3,x}$ and ${\beta }_{3,x}={\alpha }_{3,x}^3{V}_{3,x}$ [13].

5.

Computation Sub-stage of User i

After user i receives the data retransmitted by the cloud server, it still needs to complete the decoding and rendering tasks for these data. The data size that needs to be processed is ${\mathrm{\Gamma }}_{2,l}^{(i)}$, so the conditional probability mass function of the computation sub-stage delay $D_{5,l}^{(i)}$ for user i can be expressed as:

$$P(D_{5,l}^{(i)}={\displaystyle \frac{{\mathrm{\Gamma }}_{2,l}^{(i)}}{W_{\mathrm{U}}^{(i)}}}\left|A_{\mathrm{c},l}\right.,A_{\mathrm{r},l})=1$$

(12)

where $W_{\mathrm{U}}^{(i)}$ represents the computation capacity of user i, in bit/second.

3.1.2. Delay Violation Probability

To obtain the delay violation probability for any accessed user i, denoted as $P_{\mathrm{out}}^{(i)}(x)$, based on the definition in Equation (4), we need to derive the delay violation probability for user i in any given period l during video playback. We only need to determine its probability density function $p(D_{\mathrm{M},l}^{(i)}=t_l)$. Using the law of total probability, we can expand the caching status of the MEC server A_c,l and the FoV positions of all accessed users A_r,l, which can be expressed as:

$$p(D_{\mathrm{M},l}^{(i)}=t_l)={\displaystyle \sum _{A_{\mathrm{c},l}}P(A_{\mathrm{c},l})}{\displaystyle \sum _{A_{\mathrm{r},l}}P(A_{\mathrm{r},l})}{p}_{D_{\mathrm{M},l}^{(i)}}(D_{\mathrm{M},l}^{(i)}=t_l\left|A_{\mathrm{c},l},A_{\mathrm{r},l}\right.)$$

(13)

where $P(A_{\mathrm{c},l})$ and $P(A_{\mathrm{r},l})$ are the probability of A_c,l occurring and that of A_r,l occurring, respectively, satisfying:

$$P(A_{\mathrm{c},l})=P(G_l={\displaystyle \sum _{(n,m)}{a}_{\mathrm{c},l}(n,m)})$$

(14)

$$P(A_{\mathrm{r},l})={\displaystyle \sum _{\begin{array}{c}(n_l^{(1)},m_l^{(1)})\\ \mathrm{if}{x}_1=1\end{array}}{\displaystyle \sum _{\begin{array}{c}(n_l^{(2)},m_l^{(2)})\\ \mathrm{if}{x}_2=1\end{array}}\dots {\displaystyle \sum _{\begin{array}{c}(n_l^{(I)},m_l^{(I)})\\ \mathrm{if}{x}_I=1\end{array}}{\displaystyle \prod _{\begin{array}{c}i=1,2,\dots ,I\\ \mathrm{if}{x}_i=1\end{array}}{P}_{\mathrm{F}}(n_l^{(i)},m_l^{(i)})}}}}$$

(15)

Here, $P_{\mathrm{F}}(n_l^{(i)},m_l^{(i)})$ represents the probability that the viewpoint of user i falls within the tile at coordinate $(n_l^{(i)},m_l^{(i)})$ at the start of the (l + 1)-th period. As described in Section 2.2.2, since the FoV prediction is obtained by the cloud server using the video’s saliency map, $P_{\mathrm{F}}(n_l^{(i)},m_l^{(i)})=P_{\mathrm{F}}(n_l,m_l)$ holds for all users. The last term in Equation (13) is the conditional probability density function of the duration $D_{\mathrm{M},l}^{(i)}$ of the computation and transmission stage of user i in period l. Given A_c,l and A_r,l, it follows from Equations (7) and (12) that $D_{2,l}^{(i)}$ and $D_{5,l}^{(i)}$ are constants. Therefore, we have:

$$\begin{array}{ll}{p}_{D_{\mathrm{M},l}^{(i)}}(D_{\mathrm{M},l}^{(i)}=t_l\left|A_{\mathrm{c},l},A_{\mathrm{r},l}\right.)=& {\displaystyle {\int }_0^{t_l-D_{2,l}^{(i)}-D_{5,l}^{(i)}}{p}_{D_{3,l}^{(i)}}(t_2\left|A_{\mathrm{c},l},A_{\mathrm{r},l}\right.)}\hfill \\ & \cdot p_{D_{4,l}^{(i)}}(t_l-D_{2,l}^{(i)}-D_{5,l}^{(i)}-t_2\left|A_{\mathrm{c},l},A_{\mathrm{r},l}\right.)d{t}_2\hfill \end{array}$$

(16)

Substituting Equations (14)–(16) into (13), and then using the integral relationship between the probability and its density function, we can obtain $P(D_{M,l}^{(i)}>D_{\mathrm{th}})$, the delay violation probability of accessed user i, by substituting it into Equation (4).

3.2. Multiuser Access Control Algorithm

Based on the analysis results obtained in Section 3.1, we now design the access control algorithm to solve the optimization problem (3). It is noteworthy that the computational cost increases exponentially with the number of requesting users if we check all possible user access indicator vectors for the optimization problem. To reduce the computational cost while admitting as many users as possible, we adopt a heuristic strategy for the proposed algorithm. The designed access control algorithm is shown in Algorithm 1. The basic idea of the algorithm is to first consider whether the delay violation probability of a user meets the QoS requirements when serving that user individually, i.e., allocating all available transmission and computing resources to the test user (steps 1–2). If not, it indicates that even if all resources are allocated to the test user, the requirements cannot be met. Then, in steps 3–7, among all users who can be served individually, we examine the users in order of their delay violation probabilities, from the smallest to the largest: if serving a user with a smaller delay violation probability (who generally consumes fewer transmission and computing resources) allows us to then serve an additional user with a larger delay violation probability. Specifically, steps 3 and 4 are for arranging users for the access test, and step 5 is to calculate the parameters for evaluating delay violation probability for admitting the test users. It can be deduced that the proposed algorithm can admit as many users as possible for the 360° VR service system because it prioritizes access for users with lower resource usage. By calculating the number of comparisons between a requesting user‘s delay violation probability and the preset threshold in the worst case, the computational complexity of the proposed algorithm can be found as O(I²).

Algorithm 1 Multiuser Access Control Algorithm for 360° VR Video Service System

Step 1: Initialize $x_i=(0,0,\dots ,\underset{\mathrm{the}i\text{-}\mathrm{th}\mathrm{element}}{1},\dots ,0)$; Step 2: Calculate $P_{\mathrm{out}}^{(i)}(x_i)$ for i = 1, 2, …, I; Step 3: For all single-user access combinations that satisfy the condition $P_{\mathrm{out}}^{(i)}(x_i)\le \delta$, arrange the user indices xi in ascending order of $P_{\mathrm{out}}^{(i)}(x_i)$ and obtain the sequence of users that can be served individually: i1, i2,…, iI′; Step 4: Let $x=(0,0,\dots ,\underset{\mathrm{the}{i}_1\text{-}\mathrm{th}\mathrm{element}}{1},0,\dots ,\underset{\mathrm{the}{i}_2\text{-}\mathrm{th}\mathrm{element}}{1},0\dots ,0)$ denote the user access combination under consideration; Step 5: For x, calculate the mean and variance of the time interval variables for video data packets reaching any requesting user from the MEC server, $1/{\alpha }_{2,x}$ and $V_{2,x}$ , as well as the mean and variance of the time intervals for video data packets reaching any requesting user from the cloud server, $1/{\alpha }_{3,x}$ and $V_{3,x}$, by allocating bandwidth and transmission power to users to maintain the same transmission rate between different users; Step 6: Calculate $P_{\mathrm{out}}^{(i)}(x)$ for all users under consideration in x; Step 7: If $P_{\mathrm{out}}^{(i)}(x)\le \delta$ holds for all users in x, update x by adding the next user from the sequence of users that can be served individually, and proceed to step 5. Otherwise, update x by removing the last added user; Step 8: Output x.

4. Performance Evaluation

In this section, we evaluate the performance of the proposed multiuser access control algorithm for the 360° VR video service system and study the impact of system parameters.

4.1. Simulation Setup

The simulation parameters are set as shown in

Table 1. Simulation parameters.

Variable	Default Value
Tile number in the vertical and horizontal directions in a projected video plane	(8, 4)
Tile number in the vertical or horizontal direction in the FoV	2
Frame number per second of the video chunk	60 fps
UDP packet size	1460 bytes
Data size per tile per frame	20 Mbit/frame/tile
Data size processed per second by the MEC server	1.6 Tbps
Data size processed per second by the user	40 Gbps
Data size changing ratio after computing offloading	1.5
Compression ratio of the video chunk	1/600
Typical actual caching time	0.5 s
Preset E2E delay threshold	0.02 s
Delay violation probability threshold	0.02
Transmission rate from the cloud server to the MEC server	[0,160] Mbps, uniform distribution
Transmit power of the MEC server-connected BS	0.5 W
Bandwidth of the MEC server-connected BS	100 MHz
Distance between the users and the BS	[15,20] m, uniform distribution
Path loss exponent	3.5
Noise power spectrum density	−174 dBm/Hz

, generally consistent with those in [13]. For example, the number of tiles in the vertical and horizontal directions in a projected video plane is set based on [22,23], and the data size per tile per frame is set according to [24]. Interested readers can refer to [13] for more details. The test video is a 20-s video titled “BlueWorld” from YouTube. The main difference is that, in the multiuser scenario as studied in this paper, when applying equal-rate transmission resource allocation, the transmission rate R_2,x(t) from the MEC server-connected BS to each user is no longer set according to the uniform distribution given in [13], but is instead evaluated using the Shannon formula, which is based on the following: the BS’s transmission power and bandwidth resources, the distance from the user to the BS, the path loss exponent, small-scale fading generated by a Rayleigh distribution with unit mean, and the noise power. After the wireless resources are allocated using equal-rate transmission, the transmission rate is calculated. According to the max-flow min-cut theorem, the transmission rate R_3,x(t) from the cloud server to the user is the minimum value between the transmission rate from the cloud server to the MEC server and the transmission rate from the MEC server to the user. Under the premise of fair sharing of the wired and wireless networks’ resources among multiple users, we set R_3,x(t) based on the following formula:

$$R_{3,x}(t)=\min \left\{{\displaystyle \frac{R_1(t)}{{\displaystyle {\sum }_{i=1}^I{x}_i}}},R_{2,x}(t)\right\}$$

(17)

Two performance metrics, delay violation probability and user access probability, are applied for evaluation. The first metric, defined in Section 3.1.2, is used to measure the QoS for admitted 360° VR video users. The second metric reflects the resource utilization efficiency of the proposed multiuser access control algorithm, defined as the ratio of the number of admitted 360° VR video users to the total number of requesting users. To ensure statistical significance of the simulation results, for each group of requesting users, 100 different user location combinations are tested, and 1000 video plays are conducted for each user location. The simulations are implemented through a custom-developed platform built in MATLAB R2023b.

4.2. Impact of Caching Time

Figure 5 studies the impact of the proposed multiuser access control algorithm on the user access probability and the delay violation probability for the accessed users under different video caching time D₁ settings. The simulation results in the figure align with the numerical results, indicating that the performance analysis provided in the scheme design is accurate. As can be seen from the figure, when the caching time D₁ increases from 0.5 s to 0.65 s, the amount of data that need to be transmitted and computed within each period increases, leading to a slight increase in the delay violation probability. However, the proposed multiuser access control algorithm strictly ensures that the delay violation probability for the accessed users is kept within the required E2E delay threshold. Similarly, as D₁ increases, the system’s user access probability also decreases.

4.3. Impact of MEC Server’s Computing Capability

Figure 6 investigates the impact of the MEC server’s computational capability on the user access probability and the delay violation probability of the accessed users under the proposed multiuser access control algorithm. As observed from the figure, the delay violation probability for the accessed users significantly decreases as the computing capability of the MEC server increases. Moreover, if the MEC server’s computing capability is weak, the number of accessed users in the system tends to saturate quickly when the number of requesting users, I, is relatively small. For instance, when the MEC server’s computing capability is 0.8 Tbps, the delay violation probability approaches the threshold as early as I equal 4.

4.4. Impact of Transmission Rate from the MEC Server to the User

Figure 7 illustrates the relationship between the user access probability and the delay violation probability of the accessed users under the proposed multiuser access control algorithm, given different bandwidths of the MEC server-connected BS B_MEC. When the total wireless transmission bandwidth increases, the data transmission rate per user rises and the delay decreases, allowing the system to serve more users within the delay violation probability threshold. Comparing the two scenarios, B_MEC = 50 and 100 MHz, an interesting phenomenon can be observed: when wireless bandwidth resources are more abundant, the proposed algorithm is able to serve a larger number of users while still ensuring acceptable delay violation probabilities, albeit with a slight increase in the violation probability.

4.5. Impact of Compression Ratio

Figure 8 demonstrates the impact of the proposed multiuser access control algorithm on the user access probability and the delay violation probability of the accessed users as the video compression ratio changes. When the video compression efficiency decreases (e.g., C_r increases from 1/600 to 1/450), the total number of accessed users decreases. By comparing the performance gap of user access probability for C_r equal to 1/750 and 1/600, as well as 1/600 and 1/450, we observe that when communication, computation, and storage are jointly designed, there may exist a threshold for video compression efficiency. If the compression efficiency falls below this threshold, the system performance deteriorates significantly. This highlights the importance of multi-dimensional joint design for multiuser 360° VR video service systems. The delay analysis model proposed in Section 3.1 offers a way to numerically explore the involved relationship and thus fine-tune the system performance.

By comparing Figure 5, Figure 6, Figure 7 and Figure 8, we find that increasing the communication and computing resources of the system is always the most direct and effective way to enhance the number of users served by the 360° VR system. In the tested scenarios, when the MEC server’s computing capacity increases from 0.8 Tbps to 3.2 Tbps, the user access probability increases on average by 92.53%. When the BS’s bandwidth increases from 50 MHz to 150 MHz, the user access probability increases on average by 85.49%. However, the proposed multiuser access control algorithm effectively maintains the delay violation probability of the accessed users below the preset threshold under all simulation parameter settings. To further fine-tune system performance, we believe that the design of an efficient multiuser resource allocation algorithm is necessary. On the other hand, for a real system, we may need to admit all those requesting users via appropriately setting network communication and computing resources. For example, in the application of VR-based education, as considered in [2], one may need to admit all students belonging to the same course, because are expected to watch the teaching video interactively and simultaneously. The analysis and design methods proposed in this paper provide an approach to achieving this goal.

5. Conclusions

In this paper, we have designed a 360° VR video service system based on proactive caching and mobile edge computing technologies and proposed a multiuser access control algorithm for this system, considering the impact of both the multi-hop wired network from the cloud VR server to the MEC server and the wireless network from the MEC server-connected BS to the users. From an academic perspective, we have employed the diffusion model to characterize the performance of the designed 360° VR video service system in terms of the E2E delay violation probability of VR users. Furthermore, the proposed multiuser access control algorithm can be treated as a design example for maximizing the number of served users via exploiting real-time and dynamic network resources, while ensuring that the E2E delay violation probability for each accessed user remains within a controllable threshold. The simulation results demonstrate that the proposed multiuser access control algorithm can effectively manage the delay violation probability for users while admitting as many users as possible. On the other hand, from a managerial perspective, for a real system where all requesting users should be admitted, the analysis and design methods proposed in this paper provide an approach to achieving this goal by shedding some light on the relationship between communication and computing resources and system performance. In this respect, the simulation results highlight the influence of various system parameters, such as the caching duration, BS transmission bandwidth, MEC server computational capability, and video compression ratio, on both the user access probability and the delay violation probability of the accessed users. For future work, we will study 360° VR video service system design considering more practical influencing factors, such as cache speed and error concealment.