# VNF Placement Optimization at the Edge and Cloud +
## 3 System Model  
In order to perform VNF-PEC allocation, we model our infrastructure, based on Figure 1, as a graph denoted by \(G=(V,E)\), where \(V\) represents the set of nodes and \(E\) the set of the links. Two types of nodes are identified: (i) servers \(N\subset V\) that are used to host the VNFs as VMs, and (ii) routers \(Q\subset V\) that are used only for forwarding purposes, where \(N\cup Q=V\) (e.g., \(N\) and \(Q\) sets are mutually exclusive). Moreover, servers are further divided based on their location into MEC servers \(F\subset N\) and Cloud servers \(C\subset N\), where \(F\cup C=N\). Each node \(v\in V\) is attributed with a vector of available resource capacities \(\mathbf{R}\) (e.g., CPU, Memory, etc.). Moreover, every edge \((u,v)\in E\) is associated with a bandwidth capacity \(b(u,v)\). We assume that there is a set of \(\mathbf{S}\) SCs available, representing \(I\) IoT applications. Each SC consists of a random number of \(K\) VNFs, i.e., \(S^{i}=(s^{i}_{1},s^{i}_{2},...,s^{i}_{K})\), \(i\in I\). Each VNF in the SC is characterized a vector of demands \(\mathbf{D}\) (CPU and Memory) that needs to be satisfied. Furthermore, as stated in Section 1, there may exist only a subset \(T\) of the servers \(N\) that can host a specific VNF \(s^{i}_{k}\). For example, some VNFs need to be close to the end-users (e.g., MEC servers \(T=F\)), while others are in the Cloud (e.g., Cloud servers \(T=C\)). Moreover, we assume that the end-users/IoT devices associated with an SC \(S^{i}\) are randomly entering and leaving the SC according to an i.i.d. Poisson point process. Thus, the traffic demand of each SC \(w(S^{i})\) is time varying according to the number of devices that needs to be servicedat each time. Additionally, according to the type of the VNF, the rate of the incoming traffic may differ from the rate of the outgoing traffic by a percentage \(z(s_{k}^{i})\). Furthermore, we assume that the SCs can have different topological characteristics following three different cases as shown in Figure 2. The first topology (Figure 2a) is the most common and simple case, where an SC is a line sequentially connecting VNFs. The second and third case is when we have bifurcated paths, where two branches are created after a VNF splits the traffic. This can happen when a reclassification occurs. As packets traverse an SC, reclassification may result in the selection of a new SC path, referred as branching. The new branch can later return to the original SC (Figure 2c) or not (Figure 2b). Further details and technical examples on these topological cases can be found in [2]. Finally, regarding delay, we assume that we have four different communication delays: (i) propagation delay \(d_{p}\), (ii) transmission delay \(d_{tr}\), (iii) node queuing delay \(d_{q}\), and (iv) processing delay \(d_{pr}\). **Propagation Delay**  
The propagation delay in a link \((u,v)\in E\), \(d_{p}(u,v)\) depends on the distance between the two communicating nodes. In this work, our network is comprised of the MEC and Cloud layers. Hence, a different propagation delay is considered according to the network layer in which the layer the VNFs are placed. **Transmission Delay**  
The transmission delay can be defined as the time needed to transfer the packets from a communicating device \(u\in V\) to the outgoing link \((u,v)\in E\), \(d_{tr}(u,v)\). The transmission delay depends on the average length of the packet \(L(S^{i})\) and the transmission capacity allocated to the SC \(w(S^{i})\); and it can be expressed as: \(d_{tr}(u,v)=L(S^{i})/w(S^{i})\). **Processing Delay**  
The processing delay \(d_{pr}(s_{k}^{i})\) includes the time needed by the VM hosting the VNF \(s_{k}^{i}\in S^{i}\) to apply a specific network operation on the arriving packets. Thus, the processing delay depends on the type of the VNF that is used and the resource footprint allocated to the VM.