Market Analysis of MEC-Assisted Beyond 5G Ecosystem

The quality-of-service (QoS)/quality-of-experience (QoE) demands of mobile services are soaring and have overwhelmed the obsolescent capability of 3G and 4G cellular networks. The emerging 5G networks will bring an unprecedented promotion in transmission data rates. However, the satisfaction of some service requirements is still in dilemma, especially the end-to-end (E2E) latency which varies in different applications. Multi-access edge computing (MEC), a promising technology in 5G cellular networks, can provide ultra-low E2E latency and reduce traffic load on mobile backhaul networks. The potential benefits of MEC for 5G and beyond services have been explored by preliminary studies. What remains is the uncertainty of revenue from the investment of MEC which will shake operators’ decisions about whether and how to deploy MEC in cellular networks. In this light, this paper designs a MEC-assisted 5G and beyond ecosystem inclusive of three players: private (local) telecom operators, backhaul, and cloud service owners. We propose a revenue maximization model for private (local) telecom operators and cloud service owners to minimize the cost from the end-user perspective while satisfying the latency requirement. The derived model indicates that two players’ revenues can be maximized by optimizing MEC resources and backhaul capacity. The game-theoretic analyses also reveal the optimized hybrid strategy of MEC and cloud for efficient mobile traffic management.


I. INTRODUCTION
In modern societies, mobile communication services are ubiquitous. Over recent years, mobile traffic in cellular networks has rapidly grown [1] due to mobile devices' flourishment, e.g., Internet-of-Things (IoT) devices, and these applications, e.g., multimedia streaming, social networking, and healthcare. Mobile traffic is continuously increasing at an annual average of 46% and expects to reach 77 exabytes per month by 2022 [2].
To accommodate such growth of mobile data traffic, the fifth generation (5G) mobile communication system The associate editor coordinating the review of this manuscript and approving it for publication was Yufeng Wang . adopts the millimeter-wave (mmWave) frequency band higher than 24 GHz where rich spectrum resource is available to achieve ultra-high capacity [3]- [6]. The mmWave band, however, suffers from coverage shortfall due to the large path loss. A heterogeneous deployment of small cell mmWave networks onto sub-6GHz macro cells has been proposed [7]- [9] to take its advantages in 5G fully.
By utilizing mmWave frequency bandwidth, the 5G system can support the exponential growth of mobile data traffic demand, which is arisen from the emergence of cloud services (e.g., YouTube, Netflix, Hulu) that mainly used via WiFi or wired networks [10].
The total cloud traffic will not only exert pressure on the access side but also on the backhaul side (likewise referred to as back-net or backbone or transport network) [11], [12]. Hence, the backhaul side would become a bottleneck because of the limited capacity [13]- [16]. Besides, since the small cells' coverage gets shorter at the higher frequencies, a large number of small cells and backhaul links (e.g., optical fiber) should be deployed, resulting in large capital expenditure (CAPEX). The penetration rates of optical fiber in most countries are still at deficient levels [17]. Even though the mmWave access is introduced in such a low-capacity backhaul network, the system throughput will be constrained due to the backhaul side's bottleneck. In 5G and beyond era, various services are going to be appeared such as automated driving, public safety utilizing the unmanned aerial vehicle (UAV), 4K video streaming, virtual/augmented reality (VR/AR), etc [18]- [21]. The amenity of these applications is sensitive, especially to the end-to-end (E2E) latency.
The current mobile network structure is drawn in Fig. 1. Other than the backhaul bottleneck, the E2E latency increases since the application traffic are processed at the cloud. As a result, the Quality of Service (QoS)/quality-ofexperience(QoE) requirements cannot be satisfied.
Self-driving vehicle may collide, and drones may lose control, which cause fatal accidents. To eliminate the backhaul bottleneck and reduce E2E latency, we focus on Multi-Access Edge Computing (MEC) [22]- [30] deployed at the edge of the network as shown in Fig 1(b). The application services, computing resources, and storage resources currently on the cloud side are migrated to the MEC side. It can achieve low E2E latency, reduced backhaul traffic load, high-speed cache downloading.
Various organizations are established owing to the prospect of MEC, such as Open Edge Computing Initiative [31], Open Fog Consortium [32], Automotive Edge Computing Consortium (AECC) [33], millimeter-wave Edge cloud as an enabler for 5G ecosystem (5G-MiEdge) [34], European Edge Computing Consortium (EECC) [35], Edge Computing Consortium [36], etc., to investigate further and standardize this novel technology. Although testbeds and proof-of-concepts (PoCs) have been implemented worldwide [37]- [45], the feasibility and evaluation of this technology into real products and services are still unclear, especially from the operators' perspective. Most of the state-of-the-art work in 5G and beyond only show the potential benefits of MEC in terms of technical issues [46]- [49]. However, they rarely refer to the operators' challenging decision whether and how to install MEC in cellular networks due to the uncertainty of reward from their MEC investments. The realization of killer applications running on MEC could attract its attention in a real sense.
This paper proposes a MEC-assisted 5G and beyond ecosystem to accelerate MEC deployments all over the world. The revenue of each operator in this ecosystem is evaluated. Besides, we introduce a social maximization revenue model with investment strategies of the number of MEC and backhaul capacity for private (local) telecom operators and legacy service providers/telecom operators.
Various kinds of cost and revenue are formulated more realistically by incorporating linear and nonlinear models.
The cost of end-user is minimized by choosing MEC or cloud according to the latency constraint to validate relevant investment strategies between the private (local) telecom operator and the cloud owner. We establish a computation resource allocation model using MEC or cloud to facilitate the formulation of two operators' problems with MEC and backhaul investment strategies. We can find the optimal deployment of MEC and backhaul capacity to maximize the revenue through ''the private (local) telecom operators vs. the cloud owners''. Numerical simulations are conducted to verify our analyses for two perspectives.
The rest of this paper is organized as follows. Sect. II briefly reviews related work to highlight the contribution of this paper. Sect. III presents a system model of interest; the network architecture of the ecosystem, traffic model with user mobility, and optimized computation allocation model using MEC or cloud-based on E2E cost. Section IV proposes a business model and defines the considered revenue maximization for private (local) telecom operators and cloud owners. In Sect. V, numerical analyses are presented to show the proposed optimization problem in finding the optimal number of MEC and backhaul capacity. Finally, Sect. VI concludes this paper. Table 1 summarizes related works covered in this section. Before the concept of Mobile Edge Computing was put forward in the white paper by European Telecommunications Standards Institute (ETSI) in 2014 [50], various computing paradigms had studied different computing paradigms such as cloud computing, fog computing, and IoT [51]- [53]. In 2017, the Mobile Edge Computing was renamed Multi-Access Edge Computing to support cellular networks and non-cellular networks, including fixed networks [54]. As the debates on 5G accelerate, the consideration of MEC as one of the critical technologies of 5G and beyond has attracted attention in many fields (e.g., research, development, PoC). Currently, hot research topics on MEC include, for example, data offloading, security, end-to-end (E2E) latency reduction, distributed computing, Artificial Intelligence (AI), and so on. In [25] and [55], the concepts of data offloading were involved. Besides, plenty of studies have incorporated data offloading for joint optimization such as power consumption and communication [56]- [58]. However, it is not easy to plan a strategy for the deployment of MEC from the viewpoints of private (local) telecom operators who introduce MEC. Therefore, it is necessary to show the pros and cons of MEC not only from the technical aspects but also from the business aspects.

II. RELATED WORK
Only quite a few studies have discussed business aspects of MEC from private (local) telecom operators' viewpoints. Several works investigated the use cases and the potential of private (local) telecom operators' revenue regarding MEC [59]- [64]. In [59], some use cases of MEC in 5G networks were proposed, and the potential revenue growth for only private (local) telecom operators with the deployment of MEC was mentioned. In [60], the 5G ecosystem's business model with some use cases was proposed when new technology such as MEC is initiated in an existing market. Regarding the benefit of MEC, state-of-the-art MEC deployment research was conducted in [61]. It mentions future research directions from the technical viewpoints. However, they only assumed the potential revenue growth but without open data for validation.
More specifically, only a few works on the optimization of private (local) telecom operators' revenue from MEC. We previously proposed a revenue model for MEC and analyzed the number of MEC that maximizes the revenue of private (local) telecom operators [62], [63]. However, it only focused on the operators, and thus the destination for traffic offloading was decided by simple calculations.
It is necessary to consider the backhaul owners (legacy telecom operators/service providers) associated with the private (local) telecom operators when considering the traffic offloading destination because the traffic flows to the cloud go through backhaul networks. Regarding the private (local) telecom operators' revenue, the most significant difference in this paper compared with our previous study is the examination of a data offloading model by investigating backhaul capacity. The previous work in [64] focused on the revenues of private (local) telecom operators as well as backhaul owners (legacy telecom operators/service providers), but it only solved a limited optimization problem concerning the number of MEC and backhaul capacity. This work should be extended to reveal how the optimal solution would affect cloud owners.
In view of the above, the main contribution of this paper other than our previous work [62]- [64] is to consider the impact of MEC deployment on private (local) telecom operators and cloud owners who operate traditional applications.

III. 5G AND BEYOND SYSTEM MODEL
This section describes the system model assumed in this paper, i.e., architecture, E2E latency and cost optimization in terms of traffic model, and end-users' perspective. Fig. 2 depicts the system architecture of our interest where it involves three players: private (local) telecom operators, legacy telecom operators/service providers, and cloud owners.

A. SYSTEM ARCHITECTURE
The figure also indicates the business field managed by each player.
Private (local) telecom operator does not refer to a current mobile network operator (MNO) but to a future regional-specific individual business owner (e.g., local government, airport owner, theme park owner, stadium owner, etc.).  They may deploy mobile access services based on Private LTE [65], [66] or local 5G service [67], [68] via small and macro cells. In addition to that, computing servers can be deployed to their edge to offer application services.
Legacy telecom operators/service providers site-to-site connections such as cloud, data centers, and internet lines, and holds core networks and optical fibers leased to private (local) telecom operators.
The legacy telecom operators/service providers assumed here includes MNOs (e.g., AT&T, China Mobile, Vodafone). If a private (local) telecom operator has MEC server, the application must be deployed on MEC virtualization platform.
Currently, the cloud owner offers a wide range of application services. The cloud owner's role is also clear; to quickly support MNOs to find application service providers (i.e., third parties) in a cost and time-efficient manner. They hold cloud centers such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, etc., and leases their computing resources to third party applications.
Here we describe the relevance of each player. From the ecosystem perspective, the private (local) telecom operator could rent the existing backhaul from legacy telecom operators/service providers without laying their private backhaul to save on Capital Expenditure (CAPEX) and Operating Expense (OPEX). The legacy telecom operators/service providers only need to prepare sufficient backhaul capacity. A typical service use case for the private (local) telecom operator is to support a traffic hotspot in a crowded area such as an airport, stadium, theme park, etc., as shown in Fig. 2. The mentioned application services include movie distribution (e.g., YouTube), video surveillance by drone [69], big data analysis, SNS, etc. These applications require a large amount of MEC processing resources. This paper assumes that end-users could receive large-volume services such as video distribution from MEC or cloud via small cells when they stay at hotspots, i.e., the traffic concentration areas. While the user moves to another destination, the application is assumed to be migrated to the user's next destination based on their context information such as location, required application, traffic information, etc. [70]- [72].
Focusing on the access services side provided by the private (local) telecom operator, we consider the HetNet architecture proposed in [4], [8] where mmWave small cells are overlaid onto a macro cell. The macro/small cells network architecture is compatible with 5G based on the Third Generation Partnership Project (3GPP) Radio Access Network (RAN) [73]. The small cell base station (BS) is constructed by three sector antennas, each of which has massive antenna elements to perform beamforming to the designated user.
5G New Radio (NR) supports 400 MHz bandwidth in the 28 GHz band [74]. Here, MEC server is located with a small cell. BSs are connected to the backhaul network leased by its owners.

B. E2E LATENCY OPTIMIZATION
This paper analyzes the E2E latency which includes a computation one owed by the application server. Since it is proportional to traffic volume [71], [75], [76], we introduce a realistic traffic model based on the measurement and user deployment.

1) TRAFFIC MODEL AND USER DEPLOYMENT
First, we consider the traffic model which is dependent on user deployment. Although lots of existing work have studied E2E latency with MEC [25], [56]- [58], there is no VOLUME 9, 2021 consideration of a realistic traffic model that is increasing annually. It primarily affects the user quality of experience (QoE). Our study employs actual mobile traffic data measured in Shibuya, Tokyo, Japan in 2012 [77]. Considering its annual growth, we assume 1,000 times more traffic than the measured amount.
It is necessary to discuss the relationship between user deployment and traffic demand. The dense traffic area is defined as hotspot, and small cells are mainly deployed to cover hotspots. Other traffic demands generated outside these hotspots are aggregated by the macro cell.
Downlink traffic is preferentially assigned to the small cell users and remaining ones are supported by the macro cell users.
Hotspots are deployed in one macro cell based on uniform distribution [62]- [64]. The number of user equipment (UE) N u h per hotspot is defined as, where σ indicates the ratio of the number of hotspot UEs to the total UEs, N u is the total number of UEs, and N h is the number of hotspots in the macro cell, respectively. Small cells are deployed to cover each hotspot. The location of the k-th UE (k = 1, . . . , N u ) is determined according to (1) and UEs are uniformly distributed within the macro or small cells as plotted in Fig. 3.

2) NETWORK AND COMPUTATION LATENCY
The current mainstream services are being migrated from on-premises servers to the cloud [78] to reduce CAPEX and OPEX. In other words, most of the processing that should have been executed on the UE host side is performed on the cloud side. According to service requirements such as latency, the MEC conceptions further enable more flexible computation resource distribution other than cloud. Hence, we assume that each user's computation related to various applications should be processed at MEC or cloud to decrease E2E latency. We assume that the UE executes only simple processing of the web browser application. MEC manages other heavy tasks of applications, thus UE energy cost can be minimized.
These processing methods are defined as optimized computation allocation models with the cooperation of MEC and cloud. The data processing destination is determined to minimize the E2E latency t k as shown in Fig. 4 Here, computation task weight δ [CPU cycles/bit] is the ratio of computing tasks to bits. j-th MEC server is deployed on the i-th small cell. iii) t k,bh denotes the backhaul transmission duration required to send the bits b k to cloud via backhaul networks from i-th small cell. iv) t k,cl stands for the computation latency in the cloud and its computation resource and task are expressed as f cl and w k , respectively. From the above, the minimization of E2E latency can be formulated as, where α k = 0 indicates that cloud is selected whereas α k = 1 is the MEC server resources, computation task weight t k,x is an optimization of latency. t k,i is expressed as, where B i [Hz] is the available bandwidth for the i-th small cell, l k,i [bps/Hz] is the link capacity of k-th small cell UE based on SINR [70]. ε tr is time slot allocation queue.
When α k = 1, the computation latency in the MEC server t k,j is expressed as, where N MEC denotes the number of MEC servers decided by private (local) telecom operator's strategy and ε j is processing queue in the MEC server. When α k = 0, the bakchaul transmission time t k,bh is expressed as, where N BH denotes the backhaul capacity decided by legacy telecom operator/service provider's strategy and N u bh is the number of UEs using backhaul networks at the same time. In this case, the computation latency in cloud t k,cl is expressed as, where ε cl denotes the processing queue in the cloud. In order to solve (16), the optimum value of α k should be determined by an exhaustive search on computation task weight δt k,x . It is necessary to take into account the additional constraints as follows: (7) and (8) are constraints on private (local) telecom operator and legacy telecom operator/service provider, respectively. (9) represents the relationship between traffic volume and wireless throughput. If the generated traffic is higher than the wireless throughput, the traffic (i.e. unsent traffic) will be reassigned to the next time slot. (10) expresses the relationship between information bits and wireless throughput and (11) exhibits the relationship between executed computing task and traffic amount which is described by the computation task weight δ.

C. COST OPTIMIZATION
End-users would like to choose the cheaper computation environment which also meets the latency satisfaction. This section defines the cost models on MEC and cloud and discusses the cost optimization problem under the latency constraint. First of all, we assume that end-users must pay the communication fee. Besides, the latency constraint is determined by comparing the following status; • The initial payment status, i.e. minimum resource usage for backhaul capacity as 1 Gbps and for cloud resource as 1 CPU cycles/sec • The additional payment status for MEC resource f MEC or backhaul capacity N BH and cloud resource f cl .
The initial latency t l k and its conditions are expressed as, (12) Here, N BH is 1 Gbps and f cl is 1 CPU cycle/sec. Then, the latency condition t lc k per user is defined as, where ψ k represents user latency requirement. Two cost model cases are considered. First case is that the end-users rent the MEC resources provided by the private (local) telecom operator. Its MEC cost c MEC is expressed as, where γ (0 < γ < 1) represents the weight coefficient to control the cost increasement. Here we refer to the prospect theory [79] which reflects end-users' decision making behavior to determine the MEC cost. Output of the value function generally has concavity with the function input. Input and output are the number of MEC server N γ MEC and the MEC cost c MEC , respectively. (14) reflects the market mechanism that the MEC server unit cost becomes lower according to its installation amount. This paper observes its behavior by setting the weight coefficient γ to 0.1, 0.2, and 0.3.
In the second case, the cloud cost c cl where the end-users choose the cloud resources is expressed as, where cloud resource cost c cl is linearly increased by N cl based on the current cloud service [80]. c N BH is the backhaul leasing cost for traffic transfer In/Out of application. In addition, backhaul leasing cost c N BH is nonlinear; thresholded by N limit BH . We assumed that N cl is same as N BH in this case. From (14) and (15), the minimization of cost formula subjected to latency condition per user is defined as, where α k = 0 indicated that cloud is selected whereas α k = 1 is the MEC server resources.

IV. REVENUE MODEL OF MEC ECOSYSTEM
This paper aims to design the MEC ecosystem between private (local) telecom operator, legacy telecom operator/service provider, and cloud owner. Their relationships are drawn in Fig. 5. To analyze the proposed MEC ecosystem, we build the maximization issue for the social revenue model among the above players. Its optimization problem is resolved in terms of MEC resource or backhaul capacity investment.

A. ECOSYSTEM MODEL DEFINITION
Before explaining the ecosystem model with MEC, we will define each operator's strategy against MEC.

1) PRIVATE (LOCAL) TELECOM OPERATOR
Currently, Mobile Virtual Network Operators (MVNOs), which offer mobile internet access services without facilities, have been participating in the market where mobile carriers were monopolized until now. Furthermore, various countries focus on the local telecom services such as private LTE. For example, in USA, Citizens Broadband Radio Service (CBRS) [81] and MulteFire [82] are being introduced as private LTE systems to extend not only conventional public use cases but also general commercial use cases. Referring to these initiatives, in the 5G and beyond era, we can expect that a private (local) telecom operator who owns the fronthaul networks inclusive of MEC will appeare worldwide, especially in the regionally local 5G. Many discussions have already begun in various countries [83]- [85] to support this assumption. Besides, private telecom operators can rent existing backhaul networks (e.g., dark fiber) from legacy telecom operators/service providers without laying their private backhaul.

2) LEGACY TELECOM OPERATOR/SERVICE PROVIDER
The legacy telecom operator is defined as the existing telecom operators (e.g., AT&T, Vodafone, Orange) in addition to the current service provider (e.g., Metro, Cross River Fiber, Viatel). They decide the investment strategy of backhaul networks (mobile/core networks) to satisfy customers' demands.

3) CLOUD OWNERS
Recently, cloud services (e.g., AWS, Microsoft Azure, Google Cloud Platform) have been the mainstream globally to replace on-premises services. With the introduced MEC, each cloud owner has already released a strategy to migrate smoothly to MEC platform in the edge cloud from their cloud platform [86]- [88]. For example, in AWS strategy [86], AWS IoT Greengrass enhances seamless cooperation with edge devices and cloud. In Microsoft Azure [87], Azure IoT Edge enables easy orchestration between code and services to support seamlessly and securely between the cloud and edge. Moreover, in Google's strategy announcement [88], Global Mobile Edge cloud will deliver a portfolio and marketplace of 5G solutions built jointly with telecommunication companies to accelerate 5G services. Cloud owners could become an orchestrator for migrating between MEC and cloud by fully exploiting their knowledge cultivated in cloud operation and relationship with third-party application players.

4) THIRD PARTY APPLICATION PLAYERS
As the evolution of communication systems and equipment, there have been a plethora of applications appeared in our life. Moreover, in the 5G and beyond era, advanced technical applications are coming such as fully autonomous operation, machine learning application, etc. Adapting to future situations, a network system that meets various requirements such as network slicing is mandatory. This paper evaluates each player's revenue from two viewpoints of E2E latency requirement and cost minimization to meet user satisfaction.

B. PROBLEM FORMULATION
Here we formulate the revenue model for private (local) telecom operators to decide the investment strategy for the number of MEC servers N MEC and backhaul capacity N BH . Cloud owner's revenue should also be taken into account for private (local) telecom operator's revenues. These revenues are including legacy telecom operators/service providers' fees. The overall revenue is evaluated based on satisfaction of end-users, that is, latency requirement.
End-users can enjoy unlimited communication by paying flat-rate fees to the private (local) telecom operator. Furthermore, the end-users pay for the application service to the third parties and receives the services depending on the cost. The private (local) telecom operator purchases the MEC server from the vendor and leases MEC resources to the cloud owner.
First, the optimization problem regarding the private (local) telecom operator's revenue f 1 can be formulated as, In this case, (2) or (16) is jointly considered depending on the scenario decribed below. p a denotes the flat-rate communication fee, p lease MEC is the leasing cost of MEC resource for the cloud owner. p MEC and p run MEC denote the cost of MEC server per unit (including software licensing fee, etc.) and the MEC running cost, respectively. N u h and D k,j denote the number of UEs using MEC server computation and the demanded traffic sent from the k-th UE to the j-th MEC server, respectively. The optimization problem about the cloud owner's revenue f 2 can be formulated as, Here, cost minimization in (16) should be jointly considered.
The above optimization problem attempts to maximize the cloud owner's revenue in terms of the demanded traffic, the backhaul capacity N BH , and the number of MEC server N MEC which are included in (16). p cl denotes the cloud resource cost. p run cl is cloud running cost. The above formulae (17)- (18) represents the interests of Private (local) telecom operator versus cloud owner. Application deployment costs should be minimized to discount their payment under the latency requirement constraint from the end-users' perspective.
In this case, the application provider leases the computation resources from private (local) telecom operator or cloud owner to maximize their revenue. (16) is jointly considered to solve (17).
Each investment strategy could be decided in terms of the number of MEC servers N MEC and the backhaul capacity N BH . It should be noted that each player cannot know others' strategy which is highly confidential information. To solve the above multi-objective optimization problems, Nash equilibrium solutions are employed [89].
Players' revenue f 1 and f 2 could be maximized with the range of the number of MEC resource N MEC and backhaul capacity/cloud resource N BH ; where N * BH and N * MEC indicate Nash equibilium points, respectively.

A. SIMULATION CONDITION
The possible range of the number of MEC N MEC and backhaul capacity N BH are observed through an extensive system level simulation.
In this simulation, 12 hotspots N h and one macro cell are deployed. UE deployment follows Sect. III. The hotspot traffic demand originated from each UE is 62 Mbps on average same as [77]. Computation task weight δ is changed from 10 to 1000, and this value is the control parameter in our numerical analyses. Detailed simulation parameters are listed in Table 2. The QuaDRiGa channel model which is an extension of the 3GPP model [90] is used. To evaluate the investment strategy, the numerical calculation is performed by ''the private (local) telecom operator versus the cloud owner''. The evaluation metric is the computation allocation ratio which is defined as, where N α k =1 and N α k =0 represent the numbers for which MEC or cloud is selected by resolving the optimization problem, respectively. Fig. 6 shows the average computation allocation ratio R as the output of the overall optimization problem. Parameters are set to computation task weight δ = 100, ψ = 0.05 sec, the weight coefficient γ = 0.2. The range of the number of MEC servers N MEC is from 0 to 50 and that of backhaul capacity N BH is from 1 to 50 Gbps. Value of f cl is assumed to be same as N BH . In the region where the backhaul capacity N BH is around 15 or less, the optimized computation allocation ratio is increased with N MEC up to 20.  Advantage of MEC deployment is emphasized when the backhaul capacity is insufficient.

B. REVENUE CHARACTERISTIC
Meanwhile, in other blue region, latency requirement is satisfied even with the cloud which can offer lower cost. Superiority of MEC comes back at around N BH ≥ 10. Moreover, at N BH > 20, the traffic destination is reverted back to MEC, but CAPEX is larger than revenue of the private telecom operator. From this observation, optimizing the number of MEC N MEC and the backhaul capacity N BH are needed from both the private telecom operator and the cloud owner's viewpoints. Fig. 7 shows resultant revenue of the private telecom operator and the cloud owner, respectively. Parameters are the same as the previous evaluation. From Fig. 7(a), increasing MEC resource is profitable for the private telecom operator up to N MEC = 20 whereas exceeding this point conversely reduces the revenue. It is because that the revenue from MEC resource fee is saturated and the operation and investment costs have become more dominant than that. We can observe that, if sufficient backhaul capacity of more than 15 Gbps is available, it is necessary to cooperate with the cloud instead of utilizing all MEC.
It also implies that lowering backhaul running cost is an important issue for the spread of MEC. Fig. 7(b) shows that the cloud owner's revenue increases as the backhaul capacity is released up to N BH = 20 Gbps. Exceeding this point, the revenue becomes constant.
Comparing Fig. 6 and Fig. 7(b), when the backhaul capacity N BH is more than 20 Gbps and the number of MEC N MEC is around 5, the offload amount decreases as appeared in Fig. 6, which means that the cloud resource is being utilized. However, in Fig. 7(b), the cloud revenue doesn't increase because the revenue from cloud is relatively lower than the payment for the MEC resource utilization. Sufficient backhaul capacity is required to maximize his profit.
In this region, the revenue decreases as the number of MEC server N MEC . Although we can see the impact that the computation resource is migrated to MEC as shown in Fig. 6, the optimality of backhaul capital investment should be considered.
Therefore, there should exist optimal values for the MEC servers and the backhaul capacity. Following evaluation attempts to solve these multi-objective optimization problems  by the game theory in (19) under the constraint that each player does not know other players' strategies.

C. OPTIMAL RESOURCES
Here we analyze Nash equilibrium points with various parameters such as latency requirement, MEC cost and traffic demand.

1) LATENCY REQUIREMENT ψ
First, Nash equilibrium points are analyzed with the latency requirement ψ varied from 0.01 to 0.1 sec. Fig. 8 shows the optimized relationship between the number of MEC N MEC and backhaul capacity N BH . Here, weight coefficient for MEC cost is γ = 0.2 and computation task weight is δ = 100, respectively. The Nash equilibrium point with each ψ can be found as the intersection of optimized curves for 54004 VOLUME 9, 2021 private (local) telecom operator and cloud owner, denoted as magenta-colored circles. For example, the optimal combination can be seen as (N MEC , N BH ) = (11,18) at the latency requirement of 0.1 sec. This requirement is loose and means that it can be accommodated in the cloud and MEC. When the latency requirement is less than 0.03 sec, the more number of MEC servers and backhaul capacity tend to be required. It indicates that MEC is quite advantageous to satisfy such stringent latency requirements represented by mission critical services. Also, to perform critical service, it is necessary to use both computation resources.

2) WEIGHT FOR MEC COST OF THE WEIGHT COEFFICIENT γ
As formulated in (14), MEC cost depends on the weight coefficient γ . Fig. 9 plots its dependency on optimized resources. Here latency requirement is set to ψ = 0.05 sec. At the weight coefficient γ = 0.1, the MEC cost can be kept low even when a number of computation servers are installed at the edge side. It indicates that the benefits of installing a MEC can be preserved for high backhaul capacity; the optimal resources can be seen at around N BH = 20. When the weight coefficient γ increases to 0.2 or more, MEC costs, that is, the unit price for the MEC resource, rise and its advantage will be lost. To satisfy the latency requirement more costeffectively, more MEC should be installed. Therefore the optimum number of MEC servers N MEC is increased. On the other hand, the optimum backhaul capacity N BH remains almost the same value. The cloud owner's profitability is substantially independent of MEC cost; hence its optimized characteristics are consistent for each weight coefficient γ .
3) COMPUTATION TASK WEIGHT δ Fig. 10 presents optimized relationship of (N MEC , N BH ) in terms of the computation task weight δ which represents traffic demand to be processed at the network. δ is set to 10, 100, and 1000.
As the computation task weight δ increases, it can be seen that the optimal backhaul capacity for the cloud owner decreases. Instead, the optimal MEC resource for the private (local) telecom operator gradually rises. This tendency is quite reasonable. In the case where the traffic demand is slight as δ = 10, each player's revenue and expenditure are dominated by fixed cost; Nash equilibrium point is (N MEC , N BH ) = (13,20). The benefit of edge computing becomes to stand out as δ is increased. When heavy traffic should be processed as in the case of computation task weight δ = 1000, most of the computing resources should be migrated to MEC, i.e., (N MEC , N BH ) = (20, 16), which can better satisfy the latency requirement.
The above result validated our proposed social revenue model that designed MEC-assisted mobile communication systems to satisfy user experience in terms of end-to-end transmission latency.

VI. CONCLUSION
This paper designed a MEC-assisted mobile ecosystem to accelerate the MEC deployment in 5G and beyond cellular networks. We proposed a revenue model including two players, i.e., private (local) telecom operators and cloud owners. We then formulated a computation resource allocation problem to maximize their revenue under the constraint of satisfactory end-to-end latency as the user-side QoS/QoE. The MEC resources and backhaul capacity are key resource parameters to be optimized. A game-theoretic approach was employed to find the solution through extensive simulations based on the heterogeneous network where millimeter-wave small cells are deployed onto the macro cell. Further, its optimized characteristics can be observed with various parameters, e.g., latency requirement, MEC deployment cost, and computation task amounts. Results clarified the advantages of MEC while both edge and cloud computing resources are also essential to maximize all players' revenue and satisfy users' QoS/QoE. In particular, MEC is essential for mission-critical application services. Our proposed approach can provide useful insights in enabling MEC-assisted system design towards the 5G and beyond era.