Honey bee inspired resource allocation scheme for IoT-driven smart healthcare applications in fog-cloud paradigm

Motivational factors and contributions

Motivational factors behind this research study are the combined utilization of diverse technologies e.g., IoT, cloud and fog computing in optimal manner. These computing paradigms in modern applications are playing pivotal role particularly in the context of IoT driven applications. To harness the salient features of these technology in cost effective way for automation of smart applications in various sectors is challenging. The major reason is that different parts (AppModules) of the application need to deploy on various layers of this inter-collaborated setup in optimal manner and reliable flow of information amongst them require intelligent decision-making. So, this is where intelligent and optimal techniques come in. Some key motivational factors with respect to this study are mentioned below.

• Latency optimization: Real-time smart applications require low latency of information amongst modules so fog computing provide computation closer to the data sources devices as compared to cloud resources.

• Bandwidth constraints: Sending all information of IoT devices to cloud resources for processing consumes the high amount of bandwidth, by utilizing fog at edge filter the long retention information for cloud and remaining process at fog devices.

• Scalability: The distributed nature of fog computing provides better scalability as compared to its centralized cloud counterpart.

• Autonomy and reliability: As fog devices handle decision-making and data processing locally, which ensure the reliability even in case of bottleneck exist with cloud resources.

The following are main contributions of this article.

1. System model design and simulation-based implementation of IoT-driven healthcare applications by extending iFogSim simulation application programming interfaces (APIs).

2. Designed Honey bee inspired distributed application modules (AppModules) allocation technique to fog devices on the basis of objective function and problem formulation.

3. Presenting the comparison-based performance analysis with various baseline techniques on QoS parameters, which surpass these baseline algorithms.

The rest of the paper is organized as follows: Relevant work is discussed in ‘Relevant work’ while ‘Proposed Architectural Design’ presents the Proposed Architectural Design and related Algorithms. Simulation Experiments are discussed in ‘Simulation Experiments’ and ‘Concluding remarks’ present the Concluding Remarks.

Communication mode

All modules of application inter-collaborate with each other through exchange of messages (events) and implement the transport layer security (TLS) protocol at transport layer. This protocol ensures the secure communication amongst application modules (AppModules) through encryption from end to end. Moreover, required resources for the processing of these modules in fog network and cloud site are non-preemptive, which never interrupt the processing till completion.

Modules allocation strategy

Allocation methodology of application modules assignment is inspired from the foraging behavior of honey bees, which mimics the food searching patterns of bees in Algorithm 1 . Scout bees search randomly and forager bees harness the best source of food as our aim is also target that device, which has less mean utilization (compute and bandwidth). So that earliest response time and completion time could be observed. Pro and cons of this technique is discussed below. Algorithm 2  is used as procedure of calculating the utilization of fog nodes. The algorithm iterates over the available fog nodes and calculates the utilization of load and bandwidth then computes the least mean value of both to place the application module. This process continues until all modules of the application get placed over nodes.

 
__________________________ 
Algorithm 1 Application Modules Mapping___________________________________________________________ 
  1:  function ModuleMapping(appModulesList,fDeviceList) 
  2:       numScouts ← 15                                                      ⊳ Number of Scout Bees 
  3:       maxIterations ← 70 
  4:       numForagers ← 50                                                               ⊳ Forager Bees 
  5:       Randomrand ← createObject(Random.Class)               ⊳ Random Class Object 
  6:       for Itr = 1 to maxIterations do 
 7:            for Sct = 1 to numScout do 
 8:                  for AppModule ∈ appModuleList do 
 9:                       FogDevice  fd ← fDeviceList.get(rand.nextInt(fDeviceList.size)) 
10:                       AppModule.setFogDeviceId(fd.getId()) 
11:                  end for 
12:            end for 
13:            bestFitness ← calculateFitness(appModuleList,fDeviceList)    ⊳ Calculating 
     fitness of resources 
14:            for frgBee = 1 to numForager do  ⊳ Foragers Bees Harness the best solutions 
15:                  for AppModule ∈ appModuleList do 
16:                       if rand.nextDouble() < 0.1 then 
17:                            FogDevice  fd ← fDeviceList.get(rand.nextInt(fDeviceList.size)) 
18:                            AppModule.setFogDeviceId(fd.getId()) 
19:                       end if 
20:                  end for 
21:                  newFitness ← calculateFitness(appModuleList,fDeviceList) 
22:                  if newFitness < bestFitness then 
23:  bestFitness ← newFitness 
24:                  else                                           ⊳ Revert changes if fitness is worse 
25:                       for AppModule ∈ appModuleList do 
26:                            FogDevice  fd ← fDeviceList.get(rand.nextInt(fDeviceList.size)) 
27:                            AppModule.setFogDeviceId(fd.getId()) 
28:                       end for 
29:                  end if 
30:            end for 
31:       end for 
32:  end function__________________________________________________________________________________    

 
_______________________________________________________________________________________________________ 
Algorithm 2 Calculating Fitness of Resources________________________________________________________ 
  1:  function calculateFitness(appModulesList,FDeviceList)         ⊳ Find the fitness of 
     Resources 
  2:       totalMeanUtilization ← 0 
  3:       for FDevice ∈ FDeviceList do 
 4:            meanUtilization ← 0  
  5:            for AppModule ∈ appModuleList do 
 6:                  if AppModule.getFdID() = FDevice.getID() then 
 7: 
  8:                       CpuUtilization ← FDevice.getTotalUtilizationOfCpuMips(AppModule) 
  9:                       BWUtilization ← FDevice.getTotalUtilizationOfBW(AppModule) 
10:                       meanUtilization     ←   meanUtilization  +   (CpuUtilization  + 
     BWUtilization)/2 
11:                  end if 
12:            end for 
13:            totalMeanUtilization ← Math.min(totalMeanUtilization,meanUtilization) 
14:       end for 
15:       return totalMeanUtilization 
16:  end function__________________________________________________________________________________ 

Pros

• Decentralized nature: Algorithm function in a decentralized manner as module assign across multiple devices without any centralized controller entity. This factor causes of scalability and fault-tolerance.

• Efficient utilization of resources: Allocation of resources is performed on the basis of fitness level e.g., earliest completion time, minimum utilization and energy consumption, which leads to optimal level of utilization of resources.

• Scalability factor: The technique enhances scalability factor easily with increasing numbers of tasks and resources and is suitable for distributed environment.

• Adaptive: It constantly evaluates the dynamism of the environment and adapts to changes in load at runtime before assigning modules.

• Self organizing behavior: It manages resources autonomously without external intervention as it mimic self-organizing behavior of bees.

Cons

• Communication overhead: Bees communicate the information of distributed amongst resources frequently, which creates the overhead in large scale fog devices network.

• Complexity: The honey bee inspired algorithm creates complexity due to its bees like behaviors of searching food. In order to implement this behavior multiple agents (bees) have to manage and initialize in the system.

• Dependency: Certain parameters are inevitable in these types of techniques like number of forager agents, scout bees etc. and setting of these parameters can be challenging.

• Slow convergence: In order to find optimal solution in some cases algorithm may take long time while competing for resources by many tasks.

Mathematical model

The least mean utilization in the proposed technique also helps to balance the load on devices of the fog network, which reduces the makespan and response time. The completion time of AppModule_i on device FD_j as CT_ij, so Makespan is the overall module completion time and can be calculated through the following Eq. (1). (1)${\displaystyle makespan=max\left\{CT\text{\_}ij|i\in AppModule,i=1,2,\dots .nandj\in FDj=1,2,\dots .m\right\}}$

and response time is the amount of time taken in application module submission and the first response is obtained. Let AppModules = {AppModule₁, AppModule₂....AppModule_n} and these modules will be executed on set of fog devices FD = {FD₁, FD₂....FD_n}. All AppModules processing on these devices is based on a non-preemptive pattern, which means that the execution of the module will not be interrupted. The processing time of AppModule in FD_j can be denoted as P_ij. Processing time of AppModule_i on FD_j is denoted as P_ij and processing time of all AppModules in FD_j can be defined by Eq. (2). (2)${\displaystyle P_j=\sum _{i=1}^n{P}_{ij}j=1,\dots .,m.}$

Equation (3) is obtained by reducing the value of CT_max and Eq. (4) is implied through Eq. (2) and Eq. (3). (3)${\displaystyle \sum _{i=1}^n{P}_{ij}C{T}_{max}\le j=1,\dots .,m}$ (4)${\displaystyle \Rightarrow P_{ij}\le C{T}_{max}j=1,\dots .,m.}$

The processing time of application modules (AppModules) reflects the variation from one fog device to another based on capacity. The load of fog device FD − j can be calculated based on executing millions of instructions of application module (AppModule) and the capacity of fog device is calculated through Eq. (5). (5)${\displaystyle F{D}_j=P{E}_{numj}xP{E}_{mipsj}+F{D}_{bwj}.}$

PE_numj denotes quantity of processors and PE_mipsj has been used to indicate the processing power of each processing element (PE) and FD_bwj is the bandwidth capacity of communication channel amongst other fog devices in the network. The capacity of all fog devices participating in the network can be also, calculate to know the total utilization of computational resources. (6)${\displaystyle Tota{l}_{cap}=\sum _{i=1}^{m}F{D}_j.}$

The total computational capacity of fog network can also be derived through Eq. (6) and measurement of load on fog device FD_j is calculated through Eq. (7). Application modules (AppModules) length in terms of Millions Instruction (MIs) allocated to fog device FD_j in any given time is called workload. (7)${\displaystyle Loa{d}_{FDi,t}=N\left(AppModul{e}_{MI},t\right)/S\left(F{D}_j,t\right).}$

Equation (7) states the execution of the application module’s millions of instruction (MI) by service rate S of fog device FD_j in time t is called load on single fog device. The total load of all devices is derived by Eq. (8). (8)${\displaystyle Tota{l}_{Load}=\sum _{i=1}^{m}Loa{d}_{FDi}.}$

Similarly, processing time of fog device FD is computed through Eq. (9). (9)${\displaystyle P{T}_i=Loa{d}_{FDi}/C_i.}$

The overall processing time of all fog devices FDs is PT = L/C and utilization of bandwidth by application module on fog device is calculated as in Eq. (10) (10)${\displaystyle BWUti{l}_{FDi,t}=EventByte{s}_{AppModulei}/UPLinkCapacit{y}_{FDj}.}$

Event bytes indicate the length of message, which particular application module will send to next module as output on network link at given time t. Mean utilization of fog device FD_j resource will be obtained through Eq. (11). (11)${\displaystyle Mea{n}_{Utilizatiion}=Loa{d}_{FDi,t}+BWUti{l}_{FDj,t}/2.}$

Simulation experiments

To conduct the experiments of the proposed design, the application programming interface (API)/Libraries of iFogSim have been harnessed, which are object-oriented and are written in Java programming language. Due to their object-oriented nature, these libraries are easily extensible. Researchers can extend these classes according to their desired parameters and algorithms. Simulation experiments can be performed in a repeatable manner in a controlled environment and are consider cost-effective as compared to real test beds. Mainstream classes, which researchers extend to model their proposed entities are the following. iFogSim utilizes the CloudSim simulation engine for inter-entities communication and events passing.

• SimEntity: This class is the mainstream class of CloudSim and several classes of iFogSim implement this one to send the various types of events to each other.

• FogDevice: This class is use to model the computing resources of fog network and perform the computation of application modules.

• Sensor: To simulate the hardware devices cameras and sensors, researchers use this class that originates the data in the form of tuples.

• Actuator: This class is used for any hardware that displays statistics after processing tuples received from sensors.

• ModuleMapping: It is an abstract class used for providing customized implementation of mapping of modules on fog nodes.

• AppModule: IoT application comprised of various modules, AppModule class is used to model the different modules of application.

• FogBroker: Basically, this class simulates the brokering resources of the fog network and perform the computation of application modules.

Figure 4 depicts the network topology of cloud and fog nodes in our model and both networks are connected through a proxy server/brokering component.

Figure 5 indicates the processing time with various numbers of applications through applying different application module mapping strategies. Since the proposed methodology calculates the least mean utilization of device resources and allocates the module to the least utilized resource processing time remains low comparatively to other mapping techniques. Figure 6 depicts the bandwidth utilization of devices, which application modules (AppModules) utilize while exchanging information in a fog network. Since these modules function as distributed data flow (DDF) so output of some modules is the mandatory input of other modules and persists in the inter-dependency. Figure 7 illustrates the latency variations, representing application response times for varying numbers of applications in our proposed design, compared to both the mapping (Default) and cloud-only designs. Our design outperformed both baseline designs. In our simulation setup, hierarchical topology has been configured, which is depicted in Fig. 4. In this topology configuration root indicates the cloud setup and leaves are considered edge devices like gateway and these devices are configured with different compute, bandwidth, and storage capacities. Various modules of IoT applications get executed on these devices and consume their resources. We have configured simulation parameters for the cloud data center, fog devices are shown in Table 2 and Table 3, respectively. These parameters can vary as desired requirements. The distance of a cloud data center is long compared to fog devices from data-producing sources. Fog computational devices are not as high-end as cloud resources and can keep the retention of data for a long time.

Table 4 shows gateway device parameters, and used for inter-communication between cloud and fog network. Gateway devices are configured and deployed at second level in proposed model.

Devices in the model interact through the communication of application modules deployed on them. These modules generate workload in the form of tuples (Millions of Instructions) and traverse these instructions with each other to perform certain task executions. In the upward direction (cloud & fog) these instructions are called Tuples-Up and Tuples-Down are those instructions, that traverse amongst application modules.