## 4 Performance Evaluation of GASM Algorithms over Cloud/MEC RAN Architecture
### Planning with GASM in a Non-Reconfigurable Scenario  
Firstly, we analyze the performance of GASM in a non-reconfigurable scenario and compare it with other similar proposals. In this scenario, the algorithm receives the number of users to be served and the services that they require, and the planning algorithm performs the VNF provisioning and the construction of the SC for each service of each user. Therefore, the traffic is generated only considering an average number of users per AO using a random variable with uniform distribution. We tested diverse numbers of average users in HD-AO, from 500 to 8500 with an increment of 1000 users, and for each number of users, 100 simulations were run. All the results presented in the paper are plotted with the 95% confidence interval. Figure 3a shows the service blocking ratio, i.e., the probability of not establishing a requested service, due to the lack of network or IT resources, while Figure 3b shows the percentage of active CPU in both CO and AOs. GASM was configured to stop after creating 100 generations and its performance is compared to the MEC-First and CO-First policies [32; 33]. Results in Figure 3a show that GASM achieves the same service blocking rate as MEC-First, but GASM provides planning solutions that utilize a lower number of CPU cores (more than 80% of reduction for a low number of users) and, therefore, less energy consumption (see Figure 3b). When compared with CO-First, Figure 3b shows that GASM provides planning solutions that use the same number of resources than CO-First for an average number of users per HD-AO up to 3500, but GASM uses more computing resources for higher traffic loads. However, taking into account the service blocking ratio, the one obtained with GASM is much lower than that of CO-First: E.g., if we consider that \(10^{-3}\) is an acceptable value of service blocking ratio, the planning designed by GASM can deal with an increment over 200% in the number of users when compared with that of CO-First. Therefore, we can conclude that GASM outperforms MEC-First and CO-First in the achieved balance between service blocking rate and the CPU core usage [14]. Nevertheless, this traffic scenario cannot be considered realistic since the number of users requiring services from the network varies with time in real life. Hence, the behavior of GASM  
Figure 3: (**a**) Service Blocking Rate and (**b**) Percentage of CPU cores in use for Genetic Algorithm for Service Mapping (GASM), MEC-First and CO-First in a static scenario. was also tested in a non-reconfigurable, but dynamic, scenario in which the number of users requiring services from the network varies following Equation (2) [36],  
\[users_{i}(t)=\overline{users_{i}}\beta(t)\left[1+\phi\sin\left(\frac{2\pi t}{t_{ variation}}\right)\right], \tag{2}\]  
where \(\overline{users_{i}}\) represents the average number of users in the AO \(i\) and is a random variable generated using a uniform distribution \(U[0,\ 2\cdot\overline{HDusers}]\) for HD-AO and U[0, \(2\cdot\overline{HDusers}/10\)] for LD-AO. In the study, values of \(\overline{HDusers}\) range from 500 to 8500 users. \(\phi\) represents the traffic variability and \(t_{variation}\) represents the variation period in seconds. We chose \(t_{variation}=86,400\ s\), i.e., one day. The equation also includes \(\beta(t)\) to incorporate the bursty nature of the traffic. It is generated every time that \(\overline{users_{i}}(t)\) is evaluated and it is modeled as a random variable following a uniform distribution \(U[1-\epsilon,\ 1+\epsilon]\), where \(\epsilon\) represents the level of traffic burstiness and it is set to 0.1 (i.e., 10%) in our simulations. An alternative to devise this dynamic scenario would be to plan the VNF provisioning considering the average number of users during a day in each AO (which can be obtained through the use and analysis of traffic monitors) and using a scaling factor to over-dimension the planning and serve the users even in the rush hours.