# VNF Placement Optimization at the Edge and Cloud +
## 2 Related Work  
In this section, we review the different VNF approaches proposed in the literature and how the VNF Placement problem can be applied when both MEC and Cloud resources are available. In particular, many works address the VNF-PEC problem with the goal to minimize the deployment cost of an SC. In the traditional VNF placement problem, deployment cost is usually expressed as the computational and communication resources that an SC needs to in order to be provisioned [19]. The same objective also applied in the context of the VNF-PEC problem [20]. Nonetheless, there may be monetary costs associated with leasing the MEC and Cloud resources [21; 22], which may be different according to the ownership of the infrastructures (e.g., different pricing models followed from the MEC and Cloud providers). One other major concern during the SC deployment and VNF placement is the delay perceived in the overall communication. Up until recently, the major consideration in minimizing the overall delay was only the propagation delay [18; 23; 24; 25]. However, in the context of NFV, there are other major delay contributors that need to be taken into account. One additional delay factor that should be also minimized is the processing delay. This processing delay can be assumed as fixed [26] provided that the servers have enough capacity to execute the VNFs, or it can be proportional to the server utilization [12; 27]. Thus, both processing and propagation delays should be taken into consideration when the objective is to minimize the delay during the VNF placement [28; 29; 30]. Attention should be drawn to the fact that the processing delay also includes a queueing delay that is highly affected by the number of users/IoT devices associated with each SC and their traffic rate [1]. Apart from queuing models, state-space models combined with feedback controllers can be used to approximate the overall processing delay [31]. All of these delay factors apply in all layers of the IoT to Cloud communication and should be jointly minimized. This is particularly important in an IoT communication environment, since many IoT applications are characterized as mission critical and delay sensitive. Furthermore, within this context, the positioning of the VNFs can highly affect the overall delay [32]. Placing the VNFs in the physical devices of the infrastructure that are closer to the wireless devices can also reduce the communication delay [33]. An approach to accomplish this is to create clusters of available VNFs in the MEC layer, where the various requested SCs can be deployed [34]. Minimizing the number of clusters and appropriately positioning the VNFs can lead to a minimization of the communication delay. Another objective that is mainly arised by the requirements of the infrastructure providers (e.g., MEC/Cloud providers) is how to carefully allocate and schedule the available resources. Thus, there is a high interest in path optimization, efficient resource usage, and load balancing when solving the VNF placement problem [35]. The goal is to provide the necessary scalability by increasing the availability of the resources, increasing the number of SCs that can be concurrently deployed in the physical infrastructure, and facilitate VNF placement of future SC requests. This objective can be translated into minimizing the overall resource usage, in order to enable multiple heterogeneous SCs servicing heterogeneous IoT users co-existing in the MEC layer [36; 37] or minimizing the resource idleness of the infrastructure [38]. Load balancing can also be applied by minimizing the maximum link utilization and reducing bandwidth consumption [39]. This can be achieved by adopting appropriate queuing and Quality of Service (QoS) modeling during the optimization problem to minimize resource utilization [40]. This is particularly important for the MEC provider since applying load balancing can prevent its infrastructure from being overloaded, especially when it has to handle an intense amount of incoming traffic [41].