# Utility-Centric Service Provisioning in Multi-Access Edge Computing
## 1 Introduction
Finally, a distributed computing environment like MEC can eliminate the problem of a single point of failure that the centralized cloud is facing. In MEC, if there is a failure, data can be rerouted through other multiple pathways, such that IoT devices can retain access to the services they need. Therefore, MEC ensures better resilience in the IoT network. For those unparalleled benefits, MEC is recognized as a key enabler for the development of future IoT ecosystems [12]. Inversely, IoT also energizes MEC by expanding MEC services to all types of smart objects ranging from sensors and actuators to smart vehicles. Despite the promising benefits brought by MEC, the service provisioning in MEC remains challenging. Compared to the centralized cloud, a MEC node is much more limited in computing resources, and may not always be possible to serve all service requests at the same time. Hence, there have been researching initiatives to create an open MEC environment, such that distributed MEC nodes within the same geographical region do not work independently, but collaborate to form a shared resource pool allowing service requests to be served by any appropriate MEC nodes in the system [13; 14; 15]. On the other hand, the MEC nodes are also able to cooperate with the central cloud in case of a need for higher computation power for service requests, resulting in a hierarchical computation offloading architecture combining the MEC nodes and the central cloud. It naturally raises the question of determining the appropriate computing node (i.e., local MEC, a nearby MEC, or the central cloud) for each service request originated from each MEC. Many previous studies solved this problem under the theme of computation offloading [13; 14; 15; 16; 17; 18; 19; 20]. However, most of them focused on effectively improving the use of computing resources while neglecting non-trivial amounts of data, which need to be pre-stored to enable service execution, especially for data-intensive services. For example, in an AR service, the MEC node needs to store the object database and the trained machine learning models to run image classification and object recognition tasks before returning the results to the users [21]. Meanwhile, MEC is typically limited in terms of storage capacity, and thus allows only a very small set of services to be placed at a time. Which services are placed on a MEC determines which service requests can be scheduled to that MEC, thereby significantly affecting the MEC performance. As such, the service provisioning problem in MEC should jointly consider two sub-problems: (i) _service placement_, which determines services (including server code and related libraries/databases) to place in each MEC so as to better use its available storage capacity, and (ii) _request scheduling_, which determines where to schedule each service request considering the network delay and computation limitation of MEC. In the literature, different service provisioning policies were investigated but mostly focused on the quality of service (QoS) metrics (e.g., latency, bandwidth, packet loss ratio, etc.) [22; 23]. However, it is observed that the QoS cannot always guarantee the actual service quality that is experienced by the users. Hence, Quality of Experience (QoE) emerged as an extension of the QoS by including more subjective and also service-specific measures beyond traditional technical parameters to reflect the degree of satisfaction of the end-user [24]. Over the past few years, QoE has become one of the prime importance to the service provisioning policies of infrastructure and service providers. Higher QoE promises a happier user experience, thereby enhancing user loyalty and reducing service relinquish rate [25]. In a distributed environment like MEC, services, devices, and resources may not only be spread in various locations but they are of diversified nature too.