# A Novel Cloud Energy Consumption Heuristic Based on a Network Slicing-Ring Fencing Ratio
## 3 Materials and Methods
### Iterative Heuristic Energy-Aware Non-Convex Equation
``` Step 1: Initialize parameters Require: iterationStart, iterationEnd, zetaCC, pComputeCC, pCoolCC, pProCC, zetaRF, pStaticRF, commBandwidth, commPower, tau, taskExecutionTime, dynamicScalingFactor, alphaMax, betaMin Step 2: Create datacenters and initialize datacenter broker for each network slice \(\in\) network slices: hosts(PEs, RAM, BW, Storage with hosts) DatacenterCharacteristics \(\leftarrow\) (Architecture, OS, VMM, hostList, cost, costPerMem, costPerStorage, costPerBw) Datacenter \(\leftarrow\) (name, DatacenterCharacteristics, VmAllocationPolicySimple(hostList), storageList, schedulingInterval) for each ring fence \(\in\) slice: VMs (MIPS, RAM, BW, size, PEs, VMM); broker \(\leftarrow\) submitVmList(vmList) Step 3: Load Cloudlets from preprocessed dataset and submit Corresponding VMs and cloudlets ReadfastStorage, rnd CSVs for each row \(\in\) CSV: row \(\leftarrow\) [CPU, RAM, Disk, BW] Cloudlet\(\leftarrow\) (length, PEs, input, output); cloudletList \(\leftarrow\) cloudletList \(\cup\) newCloudlet vmList \(\rightarrow\) broker cloudletList \(\rightarrow\) broker Step 4: Simulate inter-VM communication for each (VM\({}_{i}\), VM\({}_{j}\)) \(\in\) VM\({}_{j}\): simulateCommunicationBetweenVMs(VM\({}_{i}\), VM\({}_{j}\), BW); CommEnergy \(\leftarrow\) (commPower \(\times\) BW) for each isolated VM: IdleEnergy \(\leftarrow\) IdleEnergy

### Consistent Convergence Criterion

For each algorithm, a consistent convergence criterion ensured a fair comparison of effectiveness by assessing the performance of each algorithm with environmental conditions. This single convergence threshold value \(e_{\text{step}}\) was initialised to 0.01, which in practical terms indicates that 1% of the initial total energy must be reduced iteratively. This value refines the sensitivity of each algorithmic step and can be tuned to accelerate convergence if required. The value was kept constant to be able to compare tests in a number of scenarios. The defined step ensured that the desired energy consumption stabilises over a certain threshold through gradient descent. More advanced optimisation strategies could be implemented but will likely take longer to calculate, impacting the resource allocation, which should run in real-time. ### The Iterative Heuristic Energy-Aware Non-Convex (IHEA-NC) Equation

**Step 1: Set initial convergence threshold and calculate initial total energy consumption**

* Define the initial threshold value, for instance \(e_{\text{step}}=0.01\). * Calculate the initial total energy consumption \(E^{(0)}_{\text{total}}\) based on the initial parameters. **Step 2: Determine the threshold value**

* Calculate the convergence threshold value as:

\[e_{\text{new}}=e_{\text{step}}\times E^{(0)}_{\text{total}}\]

**Step 3: Iterative calculation**

* **Iteration 1:** Update the parameters and calculate the new total energy consumption \(E^{(1)}_{\text{total}}\). * **Check Convergence:** Calculate the difference:

\[\Delta E^{(1)}_{\text{total}}=\left|E^{(1)}_{\text{total}}-E^{(0)}_{\text{total }}\right|\]

* If \(\Delta E^{(1)}_{\text{total}}<e_{\text{new}}\), the algorithm has converged. Otherwise, proceed to the next iteration. * **For**\(k=2,3,\dots\), repeat the following steps until convergence is achieved:
* **Update parameters and calculate the total energy consumption:*
* Update the parameters based on the current iteration. Calculate the total energy consumption \(E_{\text{total}}^{(k)}\). * **Check convergence:*
* Calculate the difference in a gradient descent way: \[\Delta E_{\text{total}}^{(k)}=\left|E_{\text{total}}^{(k)}-E_{\text{total}}^{(k- 1)}\right|\]
* If \(\Delta E_{\text{total}}^{(k)}<\epsilon_{\text{new}}\), the algorithm has converged. The optimal point is calculated based on input parameters. IHEA-NC does not track parameter deviations. Therefore, the solution will become sub-optimal at some stage. In other words, IHEA-NC can be recalculated upon changes in input parameters, such as CPU, memory, disk I/O or network bandwidth change.