# Dynamic Virtual Network Slicing and Orchestration for Selective MEC Services over Wide-Area SDN
## 5 A Selective MEC Service Model Based on a Multitier Architecture
### MEC Selection Scheme  
Because the MEC nodes deployed at each AP (zone\(-\)1) site are in close proximity with the corresponding UEs, the nearest MEC node is usually selected for the service efficiency and network performance, e.g., low end-to-end latency. However, the service availability of the MEC nodes at each AP site is limited and the operational cost is high. Furthermore, the closer the MEC nodes are located to the network edge and core site, the more computing and storage capacity is available, as compared with the MEC nodes at the AP site. Accordingly, the MEC nodes deployed at the network edge and core site can be a better economical option than the MEC nodes at the AP site, especially for less latency-sensitive services and/or resource-intensive services. That is, different services demand diverse requirements depending on the service type and properties. Therefore, we use a multiple-objective function for selective MEC services. The consideration factors are as follows: \(N\left(L_{E2E}^{n,i}\right)\), \(R_{A}^{n}\), \(U(n_{a},\ n)\), \(\psi_{UU}^{n}\), and \(c_{U}^{n,i}\). \(N\left(L_{E2E}^{n,i}\right)\), \(R_{A}^{n}\), and \(U(n_{a},\ n)\) can be acquired by using the latency model and MEC information mentioned in the subsections above. When MEC service request \(i\) is generated, \(L_{E2E}^{n,i}\) is calculated for each MEC candidate using the proposed latency model; then, the calculated values are normalized as follows:  
\[N\left(L_{E2E}^{n,i}\right)=\frac{Max_{n_{k}\in N_{C}^{i}}\left(L_{WL}+L_{N} ^{n_{k}}+L_{C}^{n_{k}}\cdot i\right)-\left(L_{WL}+L_{N}^{n}+L_{C}^{n_{i}} \cdot i\right)}{Max_{n_{k}\in N_{C}^{i}}\left(L_{WL}+L_{N}^{n_{k}}+L_{C}^{n_ {k}}\cdot i\right)}. \tag{6}\]  
\(U(r_{s},\ n)\) indicates network congestion in the current network state. On the other hand, \(\psi_{U}^{n}\) can be used as an index to predict possible future network congestion. The increasing number of UEs in the coverage area associated with a MEC site can typically cause many potential service requests. Here, \(\psi_{U}^{n}\) can be calculated separately for the MEC nodes in each zone because the number of UEs in the coverage area associated with each MEC site (zone\(-\)1 to zone\(-\)3) can be different according to the close proximity to the UEs. Thus, \(\psi_{U}^{n}\) as the estimation of the network congestion possibility can be expressed as  
\[\psi_{U}^{n}=\omega_{Z,k}\cdot\frac{Max_{n_{i}\in N_{Z,k}}\left(\psi_{n_{i}} \right)-\psi_{n}}{Max_{n_{i}\in N_{Z,k}}\left(\psi_{n_{i}}\right)}, \tag{7}\]  
where \(\omega_{Z,k}\) is a real positive value. Indicators of centrality are suggested to rank the importance of supporting services in the proposed hierarchical MEC service architecture. The importance has a wide number of meanings that lead to many different definitions of centrality. In this paper, we suggest a centrality measure on the basis of the average data volume generated in each MEC service type. It can vary in user experiences and properties. For example, in order to support over-the-top (OTT) services in the MEC environment, the OTT service contents can be distributed to the MEC nodes for the demands of users. Under these circumstances, if MEC node A has substantial OTT content and another node B has little, it is expected that node A is more important than node B in terms of the proposed centrality. Accordingly, a high value of centrality indicates that the UE can easily access the required data at the MEC node without exchanging the data and related signals between the MEC nodes.