# VNF Placement Optimization at the Edge and Cloud +
## 3 System Model
In this work, we assume an optimal server configuration, avoiding multiple packet copy operations between NIC, OS, and VM (e.g., by using Single Root Input/Output Virtualization for our I/O technology), providing a meticulous Non-Uniform Memory Access (NUMA) socket design, and an efficient CPU memory access [46] that can minimize the effect of those in the overall processing delay. Thus, we assume that we can fully use the total processing capacity of the server. **Queuing Delay**  
The last delay contributor is the queuing delay \(d_{q}(n)\) and is the time the packets spend in a node \(v\in V\) of the network as they traverse the SC path. Taking into consideration that, in this particular work, the users are randomly associated with an SC according to a Poisson point process, while the lifetime of each user is exponentially distributed, we model the communicating devices as M/M/1 queues, which have been argued as appropriate to be used for server queues [4]. Hence, the average time a packet spends in a queue can be expressed as \(d_{q}=\lambda/\ (1-\lambda/\ \mu)\), where \(\lambda\) is the arrival rate and \(\mu\) is the service time of the packets [47]. Figure 2: Different service chain topologies. Furthermore, there are extra delays for creating, booting up, and loading VNFs. However, since this is an extra level of latency that cannot be avoided, we do not consider this in our total delay evaluation. An example of the VNF-PEC placement is illustrated in Figure 3. In this example, we have three SCs (\(S^{1},S^{2},S^{3}\)) that represent the networking services that should be applied in three different applications and have the topological characteristics of Figure 2. The first SC consists of three sequentially interconnected VNFs (Figure 2a) that are allocated only in the Cloud infrastructure (e.g., due to location constraints, or due to limited resources in the MEC). Specifically, VNFs \(s^{1}_{1}\) and \(s^{1}_{2}\) are allocated on the Cloud site \(c_{3}\), while the third VNF is placed on the Cloud site \(c_{4}\). For the interconnection of the two first VNFs, we don't need to find any path since they are both provisioned on the same Cloud server. On the other hand, the link between the VNFs (\(s^{1}_{2},s^{1}_{3}\)) is allocated on the path \((c_{3},c_{4})\). For the second SC, we only utilize the MEC resources (e.g., for lower latency and deployment cost) in this case the bifurcated SC (Figure 2b) is allocated as follows: VNF \(s^{1}_{1}\) is allocated on the MEC device \(f_{1}\), VNFs (\(s^{2}_{2},s^{2}_{3}\)) on MEC device \(f_{2}\), while VNFs (\(s^{2}_{4},s^{2}_{5}\)) on MEC device \(f_{3}\). In this case, the flow of the second application is splitted in the first VNF and follows two branches. The first branch follows the \(\{(f_{1},q_{1}),(q_{1},f_{2})\}\) path, and the second branch the \(\{(f_{1},q_{4}),(q_{4},f_{3})\}\) path. For the last SC (Figure 2c), we utilize both MEC and Cloud resources (e.g., for traffic offloading). In particular, VNF \(s^{3}_{1}\) is placed on MEC device \(f_{4}\), \(s^{3}_{2}\) on Cloud site \(c_{5}\), \(s^{3}_{3}\) on Cloud site \(c_{7}\), and \(s^{3}_{4}\) on Cloud site \(c_{6}\). Regarding the paths that are used to interconnect the VNFs, for the first two VNFs (\(s^{3}_{1},s^{3}_{2}\)), the path is allocated on a set of routers that belong to the transport network, while the rest of the VNFs are placed on the Cloud and they are using inter-cloud links for the interconnection (e.g., \(\{(c_{5},c_{6})\}\) and \(\{(c_{7},c_{6})\}\)). There may be many placement solutions, but, in this example, we are just showing three different possible placement solutions to shed light on how the MEC and Cloud infrastructures can be utilized to facilitate the VNF placement. In the following, we explain how the appropriate available resources should be selected to optimally place the VNFs.