# Utility-Centric Service Provisioning in Multi-Access Edge Computing
## 4 Proposed Nested-Genetic Algorithm
It is noteworthy that when the storage capacity of each MEC is large enough to store all services (\(R_{n}=900\) GB), the only problem is the optimal request scheduling or task offloading; and hence, the performance of Top-R Genetic can reach that of Nested-GA. In this case, the cloud load of both algorithms reduces to a stable value of 29% (Figure 7b) and the percentage of dissatisfied users reduces to 0% (Figure 7c). Moreover, the performance of Nested-GA is very close to the optimal solution provided by Bonmin solver. In general, as \(R_{n}\) increases, the total utility of our proposal is improved by 23.14% and 10.14% on average compared to Top-R Nearest and Top-R Genetic, respectively while it is only 1.29% smaller on average than the optimal value. Figure 8 illustrates the impact of increasing computation capacity \(F_{n},\forall n\in\mathcal{N}\) on the total utility, cloud load and percentage of dissatisfied users. Similarly, as \(F_{n}\) increases, the total utility increases (Figure 8a) while the cloud load (except in the case of Top-K Nearest) and the percentage of dissatisfied users decrease (Figure 8b,c). Taking a closer look by comparing the performance of different algorithms for the same computation capacity, Top-R Nearest still performs the worst in all cases of \(F_{n}\). When \(F_{n}\) is small (\(F_{n}=5\) GHz), the total utility of all users of Top-K Nearest is very small, and many users are dissatisfied (Figure 8c) due to the computing resource bottleneck of MEC. We also note that with fixed storage capacity (here, \(R_{n}=500\) GB), the variation of computation capacity of MEC does not affect the cloud load of Top-R Nearest (Figure 8b). Compared to Top-R Nearest, Top-R Genetic performs much better when \(F_{n}\) is small since it schedules most users to the core cloud. However, as \(F_{n}\) increases, serving users at the MEC nodes is more benefit, and thus the performance of Top-R Nearest increasesrapidly and can reach close to that of Top-R Genetic when \(F_{n}\) is large enough. In this case, it can be observed from Figure 8b and Figure 8c that the cloud load and percentage of dissatisfied users of both algorithms are kept stable at 15% and 3%, respectively. Meanwhile, the proposed Nested-GA can always get better total utility than the above two methods by performing optimal service placement and request scheduling on MEC and cloud resources. Specifically, our proposal can achieve an average improvement of 192.59% over Top-R Nearest and 8.30% over Top-R Genetic. Figure 8c also shows the percentage of dissatisfied users of our proposal is also lower and reduces to 0 as \(F_{n}\) increases. Furthermore, similar to the previous experiment, the performance of our algorithm is approximate to the optimal solution with the average difference of 2.02%. Figure 6: Convergence of the proposed algorithm. (**a**) Inner-GA; (**b**) Outer-GA.

Figure 7: (**a**) Total utility; (**b**) Cloud load; (**c**) Percentage of dissatisfied users versus storage capacity of MEC. Based on these experimental results, we can conclude that the proposed Nested-GA consistently outperforms the two baseline methods, Top-R Nearest and Top-R Genetic, in all configurations of storage capacity \(R_{n}\) and computation capacity \(F_{n}\). Moreover, the performance of Nested-GA is very close to the optimal solution provided by Bonmin solver while reducing the running time significantly. The solver takes an average of 4.6 h while only 1425 s on average is needed for Nested-GA to find near-optimal solutions. ### Discussion

From the above observations, there are many interesting research directions to extend the proposed service provisioning policy as follows. 1. The policy can handle user demand changes over time more effectively by considering migration cost. Typically, a small change in the user demand may make the current solution no longer optimal; and hence, the policy must be adapted accordingly. The adaptation of service placement requires service migration between MEC nodes or from the core cloud to a MEC node.