Energy efficient service placement in fog computing

Architecture of fog computing

Fog computing is a type of computing that takes place between the end node and the cloud data centre. The cloud, fog, and IoT sensors are the three layers of fog architecture. Sensors capture and emit the data but do not have the computation or storage capability. Along with sensors, we have actuators to control the system and react to the changes in the environment as detected by sensors.

Fog nodes are devices with little computing capability and network-connected devices such as smart gateway and terminal devices. This layer collect data from sensors and perform data processing before sending it to the upper layers. Fog computing is suitable for low-latency applications. As shown in Fig. 1, we extend the basic framework of fog computing in Bonomi et al. (2014) and Gupta et al. (2017) by allowing service/module placement in both the fog and cloud. For this, we introduce two levels of control: (i) cloud-fog controller and (ii) fog orchestration controller(FOC). Cloud-fog controller controls all fog nodes. Fog orchestration controllers are a special kind of fog node used to run the IoT applications without any involvement of the cloud. A fog orchestration controller is responsible for all the nodes connected to it, called a fog colony. Our fog architecture supports a hierarchy with the cloud-fog controller, fog orchestration controller, fog nodes, and the sensor/IoT devices at the bottom layer.

The controller nodes need to be provided with the information to analyze the IoT application and place the respective modules onto virtualized resources. For example, the fog orchestration controller is provided with complete details about its fog colony and the state of neighbourhood colonies. With this information, the scheduler develops a service placement plan and accordingly places the application modules on particular fog resources.

Fog landscape consist of set of fog nodes (f₁, f₂, …..., f_n). These fog nodes are split into colonies, with a FOC node in charge of each colony. Each Fog node f_j is equipped with sensors and actuators. Each fog node f_j can be indicated with a tuple <id, R_j, S_j, Cu_j > where id is the unique identifier, R_j is the RAM capacity, S_j is the storage capacity and Cu_j is the CPU capacity of the fog node. FOC node controls all the communication within a colony. We define a non-negligible delay d_j between the FOC node and each fog node f_j in that colony.

IoT applications and services

Let W denote a set of different IoT apps. The Distributed Data Flow (DDF) deployment approach is used for the IoT application, as stated in Giang et al. (2015). Each of these applications (W_k) is made up of several modules, where each module m_j ∈ W_k is to be executed on the fog/cloud resources. All the modules that belong to an application (W_k) need to be deployed before W_k starts execution. Once the application executes, modules will communicate with each other, and data flows between modules. The application response time r_A is calculated as shown in Eq. (1). (1)${\displaystyle r_A=makespan\left(W_k\right)+deployment\left(W_k\right)}$ where makespan(W_k) is the sum of the makespan duration of each module m_j ∈ W_k and the execution delays. The makespan(m_j) is the total time spent by the module from start to its completion. deployment(W_k) is the sum of the current deployment time $deploymen{t}_{W_k}^t$ and the additional time for propagation of the module to the closest neighbour colony. We assume that the application’s deployment time includes administrative tasks such as module placement. Each module m_j is defined by a tuple <CPU_mj, R_mj, S_mj, Type > where these are the demands of CPU, main memory, and storage. The service type indicates specific kinds of computing resources for a module m_j. Our goal is to utilize the fog landscape to the maximum extent, and the placement of modules must reduce the total energy consumption of the fog landscape. This issue is referred to as Module Placement Problem (MPP) in fog landscape. The controllers monitor all the fog nodes. Each fog node f_i has fixed processing power CPU_i and memory R_i. Let m₁, m₂, m₃....., m_p be the modules that need to be placed on to the set of fog nodes (f₁, f₂, …..., f_n). This work addresses the MPP to reduce the delay in application processing and the total energy consumption of the fog landscape. A levy-based JAYA (LJAYA) algorithm for mapping modules and fog nodes has been developed. In the proposed approach, each solution is modelled by an array. This array consists of integer numbers (unique identifiers of fog nodes) corresponding to the fog node on which the modules m₁, m₂, m₃....., m_p will be placed. ${\displaystyle Solutio{n}_i=\left(f_3,f_9,\dots .f_i,\dots ,f_6\right).}$ This solution places the m₁ onto f₃, m₂ onto f₉ etc.

Energy consumption model

An efficient placement strategy can optimize fog resources and minimize energy consumption. Most of the previous placement algorithms have focused on enhancing the performance of the fog landscape while ignoring the energy consumption. The energy consumption by a fog node/controller can be accurately described as a linear relationship of CPU utilization (Reddy et al., 2021; Beloglazov & Buyya, 2012). We define energy consumption of a computing node (P_i) considering idle energy consumption and CPU utilization (u), given in Eq. (2): (2)${\displaystyle P_i\left(u\right)=k\ast P_{max}+\left(1-k\right)\ast P_{max}\ast u}$ P_max is the energy consumption of a host running with full capacity (100% utilization), k represents the percentage of power drawn by an idle host. The total energy consumption of fog landscape with n nodes can be determined using Eq. (3) (Lee & Zomaya, 2012). (3)${\displaystyle E=\sum _{i=1}^n{P}_i\left(u\right).}$

Module placement using Levy based JAYA algorithm

The wide spectrum of bio-inspired algorithms, emphasizing evolutionary computation & swarm intelligence, are probabilistic. An important aspect of obtaining high performance using the above algorithms depends highly on fine-tuning algorithm-specific parameters. Rao (2016) implemented the JAYA algorithm with few algorithm-specific parameters to tackle this disadvantage. JAYA algorithm updates each candidate using the global best and worst solutions and moves towards the best by avoiding the worst particle. This algorithm updates the solution according to Eq. (4). We have to update the population until the optimal solution is found or maximum iterations are reached. (4)${\displaystyle Solutio{n}_{i+1}=Solutio{n}_i+r_1\ast \left(B_i-Solutio{n}_i\right)-r_2\ast \left(W_i-Solutio{n}_i\right)}$

where Solution_i is the value at ith iteration, and Solution_i+1 is the updated value. r₁, r₂ are random numbers and W_i, B_i are the worst and best according to the fitness value.

We modified the JAYA algorithm by introducing a new operator that searches the vicinity of each solution using a Levy flight (LF). Levy flight produces a random walk following heavy-tailed probability distribution. Levy flight steps are distributed according to Levy distribution with several small steps, and some rare steps are very long. These long jumps help the algorithm’s global search capability (Exploration). Meanwhile, the small steps improve the local search capabilities (Exploitation). The updating in our approach is as follows: (5)${\displaystyle Solutio{n}_{i+1}=Solutio{n}_i+LF\left(Solutio{n}_i\right)+r_1\ast \left(B_i-Solutio{n}_i\right)-r_2\ast \left(W_i-Solutio{n}_i\right)}$ where (6)${\displaystyle LF\left(Solutio{n}_i\right)=0.01\ast \frac{u}{v^{1/\beta }}\ast \left(Solutio{n}_i-B_i\right)}$

where u and v are two numbers drawn from normal distributions, B_i is the best solution and 0 < β < 2 is an index.

Figure 2 shows the steps involved in the improved JAYA algorithm for module/service placement and are described as follows:

If the condition is true the input for next level is the updated particle, which we got after applying Eqs. (6) and (7) to the original particle. But if the condition is false then the input for next level is the original particle.

Step 1: Initial solution

Each solution/candidate is a randomized list where each entry specifies the fog node that satisfies the requirement of a given module. For example, the second module request will be placed on the fog node given as the second element of the list. Then the fitness for each solution is calculated as shown in Eq. (3).

Step 2: Updation

Calculate the fitness of each candidate and select the solutions that lead to higher and lower fitness (energy consumption in our case) values as the worst and best candidates. The movement of all the candidates is revised using the global best and worst according to Eq. (4). This equation changes the candidate’s direction to move towards better solution areas.

Step 3: Spatial dispersion

To improve the exploration and exploitation of the particles we add the Levy distribution to the updated particles, as shown in Eq. (5). We keep Solution_i+1, if it is the promising solution than the Solution_i. In the next iteration, we apply these operations to the updated population. During this process, all candidates move towards optimal solutions keeping away from the worst candidate.

Step 4: Final selection

All the particles are updated until the global optimum is found or the number of iterations is over. Finally, the solution with the highest fitness value is selected, and modules are placed on the respective fog nodes.

Results and Discussion

This section presents the results of the proposed module placement algorithm for the ISDCN application and compares them with state-of-the-art approaches in terms of energy, latency, and network utilization. We compared the proposed module placement approach with the approaches like EPSO (Potu, Jatoth & Parvataneni, 2021), PSO (Mseddi et al., 2019), JAYA (Rao, 2016), and Cloud Only (Gupta et al., 2017). To compare the performance of these approaches, we perform several experiments using the same physical topology of the ISDCN application and varying the number of areas.

The proposed approach is evaluated on ISDCN application by varying the number of areas with four cameras. All the cameras are connected to the cloud via a router in a cloud-only approach.

Energy consumption analysis

Figure 4 shows the superior performance of the proposed LJAYA algorithm in terms of the energy consumption for all the configurations measured in Kilo Joules (kJ) A lot of energy is consumed by the cameras to detect the objects’ motion in frames. Total energy consumption was significantly less in the LJAYA method than in JAYA, EPSO, PSO, and Cloud Only. For instance, the total energy consumption with EPSO, JAYA, PSO and Cloud Only is 509.12 kJ, 523.39 kJ, 689.48 kJ, and 1915.10 kJ. In comparison, the LJAYA method was 480.10 kJ for ten areas. When the number of areas is increased, the total energy consumption also increases with all the approaches. The proposed approach can find the optimal solution in all the cases. The analysis of the energy consumption for various configurations demonstrated that the proposed LJAYA approach reduces energy consumption up to 31% on average compared to modern methods.

Execution time analysis

Figure 5 shows the execution time (in milliseconds) of various topologies and input workloads. From Fig. 5, it is clear that the proposed LJAYA approach can complete the execution faster than the other approaches. On average, the proposed approach reduced the execution time up to 7%, 15%, 22%, and 53% over EPSO, JAYA, PSO, and Cloud Only approach, respectively.