A Cooperative Caching and Computing-Offloading Method for 3C Trade-Off in VR Video Services

Virtual reality (VR) video services are becoming increasingly popular in Internet of Things (IoT) owing to its immersive experience. The realization of immersive experience relies on extremely large amount of data transmitted, restricting its application. To meet the transmission requirement of VR video services, this paper designs a user-centric network based on the mobile edge computing (MEC) framework, where the 2D/3D field of view (FOV) files can be cached and the projection process from 2D FOV to 3D FOV can be computed at the VR device or MEC servers collaboratively. Based on this, a cooperative caching and computing-offloading strategy is formulated as a decision matrix, and its optimal closed-form expression is obtained by minimizing the transmission requirement under the strict service time constraint to realize the trade-off between communication, caching and computing (3C trade-off). Besides, the effect of the transmission requirement on the network density is also analyzed to provide useful guidelines for network design. Simulation results demonstrate that the proposed method can achieve quasi-optimal performance compared with other contrasting schemes.


I. INTRODUCTION
Due to the immersive experience and full fidelity for user's perception, wireless virtual reality (VR) emerging as an important application of future Internet of Things (IoT) has attracted more and more attentions [1]. A market report estimates that the global multimedia data of VR devices has increased over 650% between 2017 and 2021 [2]. In addition, the immersive experience of VR video mainly depends on the delivery of massive amount of data (in Gigabyte) within an ultra-low latency, in generally, 20 ms. Thus, it requires an ultra-high transmission rate, resulting in a significant burden on the wireless backhaul link [3].
It is noted that the field of views (FOVs) for different users may be not the same when they watch the same 360 • VR video, which are decided by the trackers at VR devices. The FOV transmission schemes introduced in [4], including the Pyramid Projection transmission scheme of Facebook and the Tile Wise transmission scheme of Huawei, mainly focus on the transmission of the high-quality image in the current viewing FOV, effectively reducing the The associate editor coordinating the review of this manuscript and approving it for publication was Petros Nicopolitidis . amount of transmission data compared with the Full FOV transmission scheme where the entire panoramic video needs to be transmitted. In order to alleviate the transmission burden over the backhaul link and improve the quality of experience (QoE), we adopt the FOV transmission schemes and just consider the transmission of viewing FOV in the paper. The typical VR framework as shown in Fig. 1 of [1] is introduced. The generation process of VR video includes: 1) Stitching process obtains a spherical video by combining the video sessions captured by a multicamera array. 2) Equirectangular projection process obtains a 2D video by unfolding the spherical video. 3) Extraction process obtains the 2D FOV corresponding to the viewpoint of the tracker at VR device from the 2D video. 4) Projection process maps the 2D FOV into 3D FOV. 5) Rendering process renders the 3D FOV during the display. Due the first three pre-processing processes composite the 360 • video from a bulk of sessions or require the entire 360 • video as input, these three processes should be completed offline in cloud server (CS) with centralized computing function. Without doubt, the rendering process is completed at the VR device. Thus, where the projection process is completed is the key issue of releasing the wireless backhaul link from heavy transmission pressure of VR video.
The typical paradigm of mobile edge computing (MEC) is envisioned as one of the key enablers for VR video services, which combines wireless transmission network and computing-caching capabilities at edge network (including MEC server and VR device) [5]- [7]. On the one hand, the caching capability can be leveraged to proactively store some FOV files at edge network during off-peak times for future requests [8]. On the other hand, the ever-increasing computing capability of edge center processing unit (CPU) can be utilized to operate the projection process from 2D FOV to 3D FOV for reducing the service time [9]. Thus, in this paper, we aim to analyze the service mechanism for VR video services in a user-centric MEC network and find out how to make the best use of the caching-computing capabilities at edge network to minimize the transmission requirement while satisfying the stringent service time constraint, i.e., achieving the trade-off between communication, caching and computing (3C trade-off). Our contributions consist of three components: • We present a user-centric network based on the MEC framework for VR video services. The network allows the FOV files to be cached and the projection process to be computed at the VR device or MEC servers collaboratively, thereby obtaining the collaborative gain and significantly reducing the transmission requirement under the strict service time constraint of VR videos.
• We propose a cooperative caching and computingoffloading strategy, and formulate the strategy as a decision matrix with 27 possible values. Based on the possible values of the decision matrix, the service mechanism of VR video is analyzed, and the required minimum transmission rate (MTR) is derived. We formulate an optimization problem of the decision matrix to minimize the required MTR. By analyzing the decision properties, a closed-form expression for the optimal decision matrix is obtained based on the 3C trade-off.
• Based on the optimal decision matrix, we analyze the effect of the transmission requirement on the network density, and the expression of the ideal network density (IND) in the limited caching capability scenario is derived to provide useful guidelines for network designers.
The remainder of this paper is organized as follows. Related work is presented in Section II. We present the system model in Section III, including the user-centric network architecture, and the cooperative caching and computingoffloading strategy. The service mechanism is analyzed in Section IV. In Section V, we formulate the system problem and analyze the decision property. Simulation results are presented in Section VI and Section VII concludes the paper.

II. RELATED WORK
In the last few years, academia researchers have made great efforts in the development of the VR video services. The realization of immersive VR experience relies on the transmission and processing of extremely large amount of data. [10] studied the cache-assisted 360 • video streaming to increase the overall quality of the delivered 360 • videos to users and reduce the service cost. But the entire panoramic video needed to be transmitted in the network of [10]. Since each user only watched a viewpoint of the 360 • VR video at any given time, the requested FOV was chosen to be transmitted instead of the entire panoramic video, thereby saving transmission resource significantly [4], [11], [12]. In [13], the authors proposed a VR QoE evaluation framework based on the transmission parameters, where an improved two-step neural network model was developed by using the features of the physiological psychology and cognitive neurology. However, these works mainly focused on the VR video itself, ignoring the potentials brought by the deployment of MEC network.
The potentials in the MEC network for VR video services can be fully tapped via efficiently utilizing caching-computing capabilities of edge network, which has been studied in [1], [14]- [25]. In [14], a Device-to-Device (D2D)-assisted VR video distribution system and a pre-caching algorithm based on QoE gain were proposed. A view synthesis-based 360 • VR caching system was designed [15], where a hierarchical collaborative caching problem was formulated to minimize the transmission latency. To further improve the QoE of VR video services, [16]- [25] envisioned the joint computing-caching capabilities of edge network as the key enablers to obtain more potential gains. [16] proposed a collaborative caching allocation and computation offloading policy, where the MEC servers collaborated for executing computation tasks and data caching. An optimization framework for VR video services was formulated in a cache-enabled cooperative network and the fundamental 3C trade-off for VR services was explored [17]. A mobile VR delivery framework was presented [22], where the authors formulated a joint radio communication, caching and computing decision problem to maximize the average tolerant delay within a given transmission rate constraint. [23] proposed to minimize the long-term energy consumption of a terahertz wireless access-based MEC system for high quality immersive VR video services. [25] exploited the potential multicast opportunities by utilizing characteristics of multi-quality 360 • VR videos and computation resources only at the users' side.
It is worthy to note that all the works in [1], [14]- [25] only utilized the caching-computing capabilities of MEC servers or the VR device, ignoring the collaboration gain from both two, such as the selection between the route of caching 2D FOV at MEC servers & computing locally and the route of caching & computing 2D FOV at MEC servers in different scenarios. The authors in [26] proposed a MEC-based 360 • VR video streaming scheme, where the user's viewpoint prediction was utilized to cache video data proactively and computing tasks were partially offloaded to the MEC server. However, [26] did not consider the choice between computing at MEC servers and computing locally. In addition, the works in [16]- [26] did not analyze a specific realization of VR framework based on the MEC network. [1] proposed a typical VR framework but only focused on utilizing the caching-computing capabilities at the VR device to alleviate the communication burden. In the paper, we propose a cooperative caching and computing-offloading strategy in a user-centric network, collaboratively utilizing the caching and computing resources at both MEC servers and the VR device. In this regard, there are 27 kinds of decision, resulting in a sophisticated optimization problem. By analyzing the problem, we find the relationship between the caching-computing decision and 3C trade-off.

III. SYSTEM MODEL
In this section, we will introduce a cooperative caching and computing-offloading strategy based on the user-centric networks. A notation table for all involved parameters is shown in Table. 1.

A. USER-CENTRIC NETWORK ARCHITECTURE
Considering the difference between 2D FOV and 3D FOV, an FOV-based VR video library is placed in CS where there are M video viewpoints from the extraction process, and both the 2D FOV and 3D FOV can be provided to users. In the scenario with the FOV-based VR video library, such as VR live streaming of sport events, multiple users in a single-cell theater watch an identical 360 • VR video, but there are some differences between their viewpoints [1], [27]. The set of viewpoints is denoted as P = {1, 2, . . . , M }. Considering the randomness of user's head rotation, the probability that the VR device requests the viewpoint m ∈ P is denoted as q m , which characterizes how often the viewpoint m is tracked by the VR users as navigating the panoramic scene. According to [15], [28], we assume the viewpoint popularity as the uniform distribution, i.e., q m = 1 M . Besides, the sizes of 2D FOV and 3D FOV files of each viewpoint are denoted as S andS (bit), respectively. Since the projection process of each viewpoint has to be computed twice to create a stereoscopic vision, one of which is exposed to the user's left eye and the other to the right eye, the size of 3D FOV file is at least twice larger than that of the corresponding 2D FOV, i.e., ρ =S S ≥ 2 [1]. The projection computing task from 2D FOV into 3D FOV of any viewpoint can be modeled as a 3-tuple (S,S, η), where η is the number of computation cycles required to process one bit data (cycle/bit).
Considering the fact that users cannot move around and their locations are relatively fixed when they watch VR video at the devices, the content delivery network of VR video is a user-centric network, as shown in Fig. 1. There are K single-antenna access points (APs) with MEC servers and an VR device with a local server [29]. More complicated transmission schemes such as multiple-input multiple-output transmission, which require antenna arrays are beyond the scope of this paper. The APs are evenly distributed in the cell with the center of the VR device and radius R M , where R M is the propagation radius of AP. The set of APs is denoted as M . The MEC servers at APs possess caches of the same sizes Q M S (bit), while the local server at the VR device has a cache of size Q D S (bit). In generally, Q D < Q M and both are integers. When the VR device is served by a chosen AP in the user-centric network, there may be some interferences from other active APs. Since the interference imposes more negative effect than white gaussian noise, the noise in the delivery process is assumed to be ignored.

B. COOPERATIVE CACHING AND COMPUTING-OFFLOADING STRATEGY
In the caching placement phase, the MEC servers and VR device store the FOV files in the collaborative manner of 0-1 caching, i.e., each FOV file is integrally stored or not. Considering the caching rule ''largest diversity content (LDC)'' and the fact that each of the K MEC servers can serve the VR device in the user-centric network, the caching resources of all MEC servers can be considered as a whole caching space of the size KQ M S through network function virtualization (NFV) to store the FOV files as different as possible. We denote the caching decision for the 2D FOV of viewpoint m as vector c m .
where c m = [0 1 0] represents the corresponding 2D FOV can be found at the VR device locally, while c m = [0 0 1] represents the FOV can be found in at least one MEC server. Otherwise, none of the VR device and MEC servers cache the FOV. Analogously, the caching decision for the 3D FOV of viewpoint m is denoted as c m .
The computing-offloading decision for the projection process of the viewpoint m at the VR device or MEC servers is denoted as vector d m , and we have where d m = [0 1 0] indicates the projection process of the corresponding viewpoint from 2D FOV to 3D FOV can be computed at the VR device, while d m = [0 0 1] represents the projection process can be completed at one of the K MEC servers. Otherwise, none of VR device and MEC servers compute the process.
Combining the caching and computing-offloading decisions of the viewpoint m, we have a 3 × 3 decision matrix Under the caching capacity constraints of the VR device and MEC servers, we have The VR device and MEC servers run at given CPU-cycle frequencies, denoted as f D and f M (cycle/s), respectively.
In generally, f M > f D . The energy consumed for computing one cycle with frequency f D at VR device is κf D 2 , where κ is the CPU power efficiency parameter of VR device as well as MEC server [1], [30]. The VR device is assumed to be equipped with a fixed and finite energy capacity, and P D (W) is denoted as the maximum of power consumption at VR device. In order to make sure that users can experience a full VR video, a power consumption constraint is considered, and we have where τ (second) is the maximum allowed time of serving a viewpoint request under the service time constraint, which can also be the maximum time of computing a projection process. From (6), κf D 2 Sη τ is the power consumption for calculating one projection process at VR device and it's noted that Sη is the maximum number of projection processes that can be computed at the VR device, where is the floor operation. In addition, the MEC servers are assumed to be directly connected to the grid so that the power consumption for projection processes at the MEC servers is unlimited and beyond the consideration of this paper.

IV. SERVICE MECHANISM AND ANALYSIS
In order to avoid dizziness and nausea, each viewpoint request from the VR device must be satisfied within the maximum of service time τ . Given the limited transmission capacity of the wired backhaul link from CS to MEC servers, the transmission rate of the link is very small and the transmission time is a much larger value when downloading 2D/3D FOV file from CS. Thus, the transmission time over the wired backhaul link is assumed to be a constant value ς τ , where ς 1 acts as the transmission penalty factor and is mainly related to the request waiting queue. Based on the decision matrix D m with 27 possible values, the request for the viewpoint m can be served by the following seven routes, and the values of D m corresponding to each route are derived in APPENDIX A. According to the seven routes, we would derive the minimum transmission rate (MTR) from MEC server to VR device while satisfying the service time constraint.

1) Local 3D Caching (L3C)
If D m 2,2 = 1, the 3D FOV of the corresponding viewpoint can be obtained locally without the need of extra computing or transmission. In this regard, the service time is negligible and the required MTR is R L3C = 0. 2) Local Computing with Local 2D Caching (LC2C) the VR device obtains the 2D FOV of the corresponding viewpoint locally, and then projects it into 3D FOV using local CPU. The service time is Sη f D and the required MTR is R LC2C = 0. Due to the fact that the computing capability of the VR device has taken huge steps, it's assumed that Sη f D ≤ τ , i.e., the projection process computed at the VR device can be completed within the service time constraint.

4) MEC 3D Caching (M3C)
= 1, the VR device downloads the 3D FOV of the corresponding viewpoint from the closest MEC server who has stored the file. The service time is , the closest MEC server who has cached the corresponding 2D FOV file projects it into 3D FOV using MEC CPU, and then transmits the 3D FOV file to the VR device. The service time is Sη

6) MEC Computing without MEC 2D Caching (MC)
If 1 − D m 3,1 D m 1,2 D m 3,3 = 1, the closest MEC server from the VR device downloads the corresponding 2D FOV file from CS and projects it into 3D FOV using MEC CPU, and then transmits the 3D FOV file to the device. The service time is ς τ + Sη f M + S R MC . Since the latter two terms in the above formula are all nonnegative, ς τ + Sη f M + S R MC τ , i.e., the route of MC does not satisfy the service time constraint.

7) CS Downloading (SD)
If D n,m 1,2 D m 1,3 = 1, the closest MEC server from the VR device is chosen as the relay, who downloads the corresponding 3D FOV file from CS and then transmits it to the device without the need of extra computing. The service time is ς τ + S R SD , and we also have ς τ + S R SD τ , i.e., the route of SD does not satisfy the service time constraint.
There is a duplicate value between ( Considering that there is a large transmission penalty in the routes of LC-FS, MC and SD, the service times corresponding to the three routes are hugely large. We assume that the transmission rates corresponding to the three routes as R P = ς S τ for simplicity. Based on the above analysis, the 3C trade-off under the decision matrix D m when f D ≥ ρSη (ρ−1)τ is shown in Table. 2, and Table. 3 indicates the differences of 3C trade-off between f D ≥ ρSη (ρ−1)τ and f D < ρSη (ρ−1)τ .

V. PROBLEM FORMULATION AND PROPERTY ANALYSIS
In this section, a system problem is formulated based on the MTR, and we analyze the property based on the decision matrix.

A. PROBLEM FORMULATION
For any given decision matrix D m , the expression of MTR for random request of viewpoint has the following two cases.
The value of MTR is shown in the formula (7), at the bottom of the next page.
2) f D < ρSη The value of MTR is shown in the formula (8), at the bottom of the next page.  Therefore, the system problem is formulated as follows.
where the constraint (9) corresponds to the constraint of the maximum number of projection processes that can be computed at the VR device. The constraint (10) limits the values of the three column vectors in the decision matrix.

B. DECISION PROPERTY ANALYSIS AND OPTIMAL SOLUTION
We denote the number of locally cached 2D FOV files, that of the locally cached 3D FOV files, that of the 2D FOV files stored in the MEC servers, that of the 3D FOV files stored in the MEC servers and that of the locally com- It's noted that if the 3D FOV file of viewpoint m is already cached at the VR device, there is no need to store the corresponding 2D FOV at the device or to store the corresponding 2D/3D FOV file at the MEC servers, as well as to process the projection.
On the other hand, the FOV files cached at the device and MEC servers should also belong to different viewpoints.
, . . . , When the 2D FOV file of viewpoint m is stored in the local cache, the projection process should be completed using local CPU, and there is no need to store the corresponding 3D FOV file at the local cache or MEC servers and to compute at MEC servers. In addition, when the local CPU does not have enough ability to compute the projection process of viewpoint m, there is no need of caching the corresponding 2D FOV locally.
Property 4: For any viewpoint m ∈ P, D m When the 2D FOV file of viewpoint m is stored at the MEC servers, the projection process can be computed using local CPU or MEC CPU. 2 The time of computing a projection process at the VR device is less than (ρ−1)τ ρ . In this regard, we always choose the route of LC-FM.
Proof: Seen APPENDIX B. Based on the Property 4 and Property 5, the computing decision at the VR device is , the route of LC-FM is adopted. We should set the value of D L as large as possible within the range of C L ≤ D L ≤ C L + C M and D L ∈ 0, 1, . . . , P D M τ κf D 2 Sη through allocating proper local caching spaces for 2D and 3D FOV files, ensuring that each 2D FOV file cached at the VR device can be projected into 3D FOV using local CPU (the LC2C route). In this regard, the route of LC-FM is also adopted while some 2D FOV files from MEC servers can be projected into 3D FOV also using local CPU.
the route of MC2C is adopted. We should set D L = C L to ensure that each 2D FOV file only cached at the device can be projected into 3D FOV using local CPU while the 2D FOV files stored at the MEC servers are projected using MEC CPU.
Due to the unlimited computing energy supply at MEC servers, we have Based on the above analysis, Problem 1 is equivalent to Problem 2.
where MTR is shown in the formula (17), at the bottom of the next page, whether f D ≥ ρSη (ρ−1)τ or f D < ρSη (ρ−1)τ . The first term is the transmission rate in the route of LC-FS, MC and SD. The second term corresponds to the gain of L3C, which increases with the number of 3D FOV files locally cached, i.e., C L . In generally, we have C L ≤ D L , which means that all locally stored 2D FOV files can be projected into 3D FOV files using local CPU through adjusting the proportion C L C L appropriately. The third term corresponds to the gain of LC2C, which increases with the number of 2D FOV files locally cached, i.e., C L . The fourth term corresponds to the gain of LC-FM, which increases with the local remaining computing capabilities (excluding the capabilities of projecting the locally stored 2D FOV files), i.e., D L − C L . The fifth term corresponds to the gain of MC2C, which increases with the number of 2D FOV files cached in the MEC servers and excluding the portion downloaded to the VR device, i.e., C L + C M − D L . The last term corresponds to the gain of M3C, which increases with the number of 3D FOV files cached at the MEC servers, i.e, C M .
Based on Problem 2, the optimal decision matrix set D under the service time constraint can be obtained, yielding the 3C trade-off. 1)

Strategy 1:
The optimal decision matrix set D * is given as 2 The optimal decision matrix set D * is given as The Strategy 1 is mainly limited by the local computing capability, while the Strategy 2 is mainly limited by the local caching capability.
Proof: Seen APPENDIX C.

C. EFFECT OF TRANSMISSION REQUIREMENT ON NETWORK ARCHITECTURE
In the user-centric networks, the VR device receives the corresponding FOV file from the chosen AP as well as the interferences from other active APs through the wireless link. The actual Signal-to-Interference Ratio (SIR) at the device in the interference-limited network is where S 0 is the received signal from the chosen AP, I k is the interference from one of the other APs who are serving other users. Which MEC server the requested FOV file is stored in is random in the NFV process of caching resources and APs are evenly distributed in the cell, so the probability distribution functions (PDFs) of S 0 and I k are the same. In addition, considering that it is impossible that all APs are always idle and waiting to serve one user, we define β (0 ≤ β ≤ 1) as the proportion of active APs.
Considering the MTR, we have where W M is the transmission bandwidth of AP. From (34), we have K ≤

VI. PERFORMANCE EVALUATION
In this section, we evaluate the performance of the proposed network by MATLAB. The simulation setup and performance analysis are presented as follows.

A. SIMULATION SETUP
According to the references [1], [6], [8], the default parameter setting for the user-centric network is shown in Table. 4. Considering user's head motion and the fact that the 2D FOV  files are extracted from the 360 • 2D videos, each user may request different set of viewpoints during each VR experience. We consider each 360 • 2D video of 5 minutes for simplicity, and the size of 2D FOV file with the duration of 1 second is assumed to be 3 Mbit. Based on [1], each 360 • 2D image is divided into 24 viewpoints and the division of each 2D image at any time is conducted 100 times, each with a unique combination of 24 viewpoints. Hence, there are M = 24×100×5×60 = 7.2×10 5 viewpoints. Since the size of each 3D FOV file is at least twice larger than that of 2D FOV, and we choose ρ = 2 andS = 6 Mbit. The number of MEC servers K is set as 3, and the total caching capacities of the VR device and MEC servers are assumed less than the total data size of FOV files in the limited caching capability scenario.
In order to analyze the network performance, the ratio of 3D FOV size and 2D FOV size ρ is set in {2, 2.5, 3}, the caching capacity of the VR device Q D is set in the range from 0.072 × 10 5 to 1.368 × 10 5 , the MEC server number K is set in the range from 1 to 7, the CPU-cycle frequency of the VR device f D is set in the range from 2 GHz to 5 GHz, and the averaged power consumption P D is set in To analyze the performance of the cooperative caching and computing-offloading method, three schemes are presented to be compared with the proposed strategy. 1) CS Downloading: There is no caching and computing capabilities at the VR device and APs. Any requested 3D FOV file is obtained directly from CS. Hence, we have D m 1,1 = D m 1,2 = D m 1,3 = 1, ∀m ∈ P. This scheme corresponds to the route of SD.
2) Only Caching: There are only caching capabilities at the VR device and APs without computing capabilities. Due to the caching rule ''LDC'', we have D m ) and D m 1,3 = 1 (∀m ∈ P). This scheme includes the routes of L3C, M3C and SD.
3) Independent Caching and Computing (IC&C): There is no cooperation between the VR device and MEC servers. The caching capacity at the VR device is utilized for storing 3D FOV files, and the device obtains the other 3D FOV files from MEC servers or CS. The caching and computing capabilities at the MEC servers are totally utilized for storing The effect of Q D on MTR under different values of ρ and the comparison with other schemes are shown in Fig. 3. In the proposed strategy, the local caching hit probability increases with Q D , resulting in the decreasing of the probability to fetch the required FOV files from CS as well as the minishing of MTR. On the other hand, the size of 3D FOV file increases with ρ, limiting the number of the stored 3D FOV files and the number of the transmitted 3D FOV files under the service time constraint, which finally leading to the increasing of MTR. Besides, due to no caching capability in the CS downloading scheme, there is no variation of MTR with the changing Q D . The reason of the variation trends in the only caching scheme and IC&C scheme is the same as the proposed strategy. In addition, the value of MTR in the proposed strategy is obviously superior to those in other schemes. This indicates that the cooperation of the 2C resource (including caching and computing) between the device and MEC servers can put a huge gain on the remaining 1C, i.e., communication.
When the value of Q D is small, MTR in the proposed strategy closes to that in the IC&C scheme. This is because there are  few FOV files cached locally and little difference in the local caching gain. But with the increasing of Q D , the proposed strategy can obtain more gains in the route of LC2C at the cost of fewer occupied local caching resource rather than in the route of L3C, resulting in the significant reduction of MTR. Fig. 4 shows the comparison of the effect of K on MTR in the proposed strategy with other schemes. Due to the NFV process, the effect of K on MTR can be considered as the effect of the caching capability of the whole MEC servers on MTR. In the proposed strategy, the caching hit probability at the MEC servers increases with K in the range from 1 to 5, resulting in the minishing of MTR. When K > 5, all the FOV files are cached at the device or MEC servers, and so there is no variation of MTR with the changing K . However, the total data size of the 3D FOV files that can be stored in the only caching scheme is larger than those of the proposed strategy where the cached files include 2D FOV and 3D FOV, so the value of MTR of the only caching scheme decreases with K in the range of 1 ≤ K ≤ 7. Besides, the gains obtained from the routes of LC-FM and M3C close to that of MC2C, so the two curves corresponding to the proposed strategy and the IC&C scheme approach within the range of 1 ≤ K ≤ 5. Fig. 5 shows the effect of f D on MTR under different values of P D . In the proposed strategy, the local  computing capability increases with P D , which leads to the increasing of the probability of LC2C and LC-FM and the decreasing of MTR. When f D ≤ 2.4 × 10 9 , (ρ−1)τ the Strategy 2 is adopted. When f D > 2.4 × 10 9 , ρSη−(ρ−1)τ f D and the Strategy 1 is applied. This is the reason why the curves of the proposed strategy begin going down suddenly in f D = 2.4 × 10 9 . The value of MTR is mainly limited by the caching capability at the VR device when the Strategy 2 is applied in the range of 2.0 × 10 9 < f D ≤ 2.4 × 10 9 , so MTR is little affected by  f D . The local computing number decreases with f D when the Strategy 1 is applied in the range of f D > 2.4 × 10 9 , resulting in the increasing of MTR. In addition, the three contrast schemes have nothing to do with the computing capability of the VR device, so the IC&C scheme is just chosen as a benchmark. Obviously, the local computing gain from the VR device is remarkable.
In Fig. 6, the trade of between caching, computing and communication is analyzed when f D = 3 × 10 9 . From Fig. 6 (a), we can see that the value of MTR decreases at the cost of occupying more caching or computing resources in the VR device. Obviously, when there are more caching spaces in the MEC servers or more abundant computing resources in the VR device, MTR also decreases in Fig. 6 (b).
The comparison of the effect of K on the ideal network density IND in the proposed strategy with other schemes is shown in Fig. 7. The value of MTR decreases with K as shown in Fig. 4, which means a smaller actual transmission rate is sufficient to meet the transmission requirement. Thus, IND increases with K within the range of 1 ≤ K ≤ 5. In the proposed strategy, there is no variation in the curve when K > 5. This is because that all the FOV files are cached at the device or MEC servers and there is no caching gain with the increasing of K , this scenario is also called the abundant caching capability scenario. Considering the Remark 2, the optimal value of the AP number is 7 and the value of IND is 0.2228 × 10 −3 in the limited caching capability scenario. The relationship between MTR and IND under the changing K is shown in Fig. 8. Obviously, when K = 5 under the default parameter setting, the value of MTR is optimal while the actual network density of APs is less than IND in the abundant caching capability scenario.

VII. CONCLUSION
In this paper, a user-centric network based on the MEC framework was proposed to meet the transmission requirement of VR video services. The 2D and 3D FOV files could be collaboratively cached while the projection process from 2D FOV to 3D FOV could also be computed at the VR device or MEC servers. Firstly, a cooperative caching and computing-offloading strategy was formulated as a decision matrix, and the service mechanism of VR video was analyzed. Secondly, an optimization problem based on the 3C trade-off was formulated to minimize the required MTR, and we obtained the closed-form expression for the optimal decision matrix by analyzing the decision properties. Finally, we analyzed the effect of the MTR on the network density and the expression of IND in the limited caching capability scenario was derived to provide useful guidelines for network designers. The effectiveness of the proposed strategy was verified by numerical examples.

APPENDIX B
When the 2D FOV file of viewpoint m is stored at the MEC servers, whether the projection process is computed using local CPU or MEC CPU is decided by the MTRs of the routes LC-FM and MC2C.

Q D R LC−FM M
In the above formula, the first three terms are constant. In the fourth and fifth terms, R P > 0 and R LC−FM − R MC2C ≤ 0, but the order of magnitude of R P is much larger than that of R LC−FM − R MC2C . Hence, the value of C L should decrease to minimize MTR. Due to the fact that R M 3C < R MC2C , R P > 0 and R M 3C − ρR MC2C < 0 in the sixth and seventh terms, but the order of magnitude of R P is also much larger than that of R M 3C − ρR MC2C . Hence, the value of C M should decrease to minimize MTR. In the last term, due to R LC−FM − R MC2C ≤ 0, we should set D L as large as possible to minimize MTR, i.e.., D L * = min P D M τ κf D 2 Sη , M . Due to the constraints (19) and (21), a smaller C L means a larger C L , so the relationship between C M and C M is. Hence, we have