# Utility-Centric Service Provisioning in Multi-Access Edge Computing
## 3 System Model and Problem Formulation  
### Scenario Description  
As illustrated in Figure 1, the MEC system consists of IoT devices, multiple computing nodes (MEC servers and the core cloud), and networks connecting them. Several services can be deployed and executed in different computing nodes, where the infrastructure and service providers define the placement locations of these services. In our proposal, each MEC server is attached to a base station or Wifi access point covering a local area to provide services to the registered IoT devices or users. Moreover, all MEC nodes are connected by backhaul links to form a resource pool (a.k.a, collaboration space) that serves users collaboratively. At a time slot, users send their diverse types of service requests to the MEC system. We assume that each user is directly associated with only one MEC node (non-overlapping), referred to as its connected MEC. The connected MEC of a user can admit its request into the system, but any MEC in the collaboration space can be chosen as the processing node of the request provided that the requested service is already placed on that MEC and the service performance is guaranteed. Two types of MEC resource constraints are considered: (i) the storage constraint restricts the number of services each MEC can offer, and (ii) the computation constraint restricts the number of requests each MEC can effectively process. Within these resource constraints, the service provisioning problem consists of _service placement_, deciding which services to place at each MEC, and _request scheduling_, deciding where to schedule users' requests. Please note that requests not scheduled to any MEC node will be \"dropped\" (e.g., the yellow request in Figure 1). \"Dropping\" a request only implies not processing it from the MEC, the dropped request can be processed by the core cloud, which is assumed to host all services. Accessing the core cloud, however, may cause high network latency, and thus should be avoided. In order to enable the service placement and request scheduling among the MEC nodes, we assume that all MEC nodes in the collaboration space are managed by a _SDN-based MEC controller_, in which the major components are described as follows. _MEC Resource and Service Monitoring Database_ module maintains a MEC resource table, service information table, and service map table. The MEC resource table includes the available  
Figure 1: System model, where colored rectangles and circles represent different types of services and their user requests, respectively. resources (e.g., storage and computation) of each MEC in the collaboration space. The service information table includes the demand of the services to be placed, such as the amount of storage of required libraries and databases, amount of processing to get a response to a request of a service, and QoS parameters (e.g., tolerable delay) of each service. The service map table is used to keep/store the list of currently processed services and their placement location. _Traffic Monitor_ module, such as that of a Software Defined Networking (SDN) controller, is responsible for collecting and managing the service requests from IoT devices to each MEC node. Commercial SDN controller, such as OpenDaylight, supports OpenFlow protocol to enable communication between the SDN controller and the network devices for monitoring the service-level traffic [40]. All scheduling rules are calculated at the SDN controller and applied to the request flow tables of each MEC node in the system. The action sets in a flow table can be forward, drop, and so on, to control the behaviors of request flows. Based on the profiles of MEC nodes, services and requests from users provided by the above modules, the _Provision Planner_ module will solve the problem of service provisioning in MEC periodically. The main objective is to maximize the total utility of all users within the resource constraints.