## 5 Computational Experiments and Numerical Results  
### Methodology and Experimental Environments  
Some experiment scenarios are designed for an orchestrator for network operation to evaluate the performance based on communication and computational perspectives. We then explain how the experimental cases lead to a real-life situation and discuss how the results changed due to various using cases. The experimental environment is initialized for resource access control, scheduling, and migration models embedded into an orchestrator in C-RAN. The algorithms are constructed and implemented to analyze the heuristics' quality for conducting performance evaluations in several simulation cases. Our experiments are developed in C++ and implemented in a personal computer with a quad-core processor, 8 GB RAM, and Ubuntu operating system version 14.04. The experimental parameters are listed in Table 4. The given amount of task traffic loads and arrival time slots are randomly generated and fixed for each evaluation case. The solution to the dual problem is denoted as \(Z_{D}\). The \(Z_{D}\) values are the lower bounds of the primal solutions. The dual solutions are not feasible for the primal problem because some constraints are relaxed. Therefore, the primal objective value is not always lower than the \(Z_{D}\) value, referred to as the lower bound. However, a primary research goal is to obtain a feasible solution. For example, Figure 5 presents an experimental case. The green curve represents the process of obtaining the primal feasible solutions iteratively. The objective is to identify the minimum value of the primal problem (min PFS). Then, the values of \(Z_{D}\) are determined using the subgradient method to iteratively obtain the tightest LB (max \(Z_{D}\)), represented by the purple line. The first step is to identify the initial solutions determined by the \(FF\) algorithm [35]. The second step is to determine the primal feasible solutions of the proposed strategies by \(UP\), \(OI\), \(CP\), and \(SP\). The performance metric, the gap, is used to evaluate the solution quality which is defined as gap \(=\frac{|\text{PFS}-Z_{D}|}{|Z_{D}|}\times 100\%\), where \(PFS\) is the primal feasible solution of proposed strategy.  
Subsequently, several scenarios are designed for performance evaluation based on different communication and computational perspectives. The experimental results are used to analyze the objective values that influence decisions in strategies.  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Given Parameter** & **Value** \\ \hline Number of time slots (\(|T|\)) & 100 \\ \hline Number of tasks (\(|I|\)) & 400 \\ \hline Number of servers (\(|S|\)) & 4 \\ \hline Processing capability (\(P_{s}C_{s}\)) (GHz) & \((1+s/8)\times 250\), for \(s=0,1,2,3\) \\ \hline RAM capacity (\(M_{s}\)) (GBytes) & \((1+s/8)\times 250\), for \(s=0,1,2,3\) \\ \hline Setup cost rate (\(A_{s}\)) & \((P_{s}C_{s}+M_{s})\times 0.2\) \\ \hline Reopen cost (\(E_{s}\)) & \(A_{s}\times 1.5\) \\ \hline Migration cost (\(F_{i}\)) & 100 \\ \hline Reward rate (\(V_{i}\)) & \(V_{i}\sim U(1,100)\) \\ \hline CPU processing capability (\(D_{i}\)) (GHz) & \(D_{i}\sim U(1,50)\) \\ \hline Total required RAM (\(R_{i}\)) (GBytes) & \(R_{i}\sim U(1,50)\) \\ \hline The system time that the task \(i\) is arrived (\(\delta_{i}\)) (sec.) & \(\delta_{i}\sim U(1,|T|-1)\) \\ \hline Allowed waiting time (\(\epsilon\)) (sec.) & 10 \\ \hline \hline \end{tabular}
\end{table}
Table 4: Parameters for computational experiments.