PaperlayerView exact revision on arXiv

Source-linked AI summary

IFogSim2: An Extended iFogSim Simulator for Mobility, Clustering, and Microservice Management in Edge and Fog Computing Environments

Redowan Mahmud, Samodha Pallewatta, Mohammad Goudarzi, Rajkumar Buyya

arXiv:2109.05636v2cs.DCcs.PFcs.SE

TL;DR

Edge/Fog computing is needed for latency-sensitive IoT processing, but distributed, heterogeneous infrastructures and costly real-world evaluation limit direct Cloud-based management and policy validation. The paper develops iFogSim2 by integrating modular models for service migration, distributed clustering, and microservice orchestration with iFogSim and real-world datasets. Across the reported case studies, iFogSim2 demonstrates effectiveness and a low footprint compared with related simulators.

  • Problem

    Distributed and heterogeneous Edge/Fog infrastructures complicate Cloud-based service management, while real-world evaluation is costly and existing simulators lack benchmarks, actual datasets, and advanced service-management support.

  • Method

    The paper extends iFogSim with loosely coupled models for mobility-aware service migration, distributed multi-tier clustering, and dynamically scalable microservice orchestration.

  • Results

    iFogSim2 demonstrates effectiveness across case studies and has a low footprint compared with other related simulators.

  • Takeaways & Limitations

    iFogSim2 provides modular simulation components, test scripts, and default techniques that support policy comparison and the definition of new Edge/Fog case studies.

  • Takeaways & Limitations

    Future improvements include monetary-based policies, distributed ledgers, additional sensor communication profiles, and distributed or federated machine learning.

Abstract

from arXiv · show

Internet of Things (IoT) has already proven to be the building block for next-generation Cyber-Physical Systems (CPSs). The considerable amount of data generated by the IoT devices needs latency-sensitive processing, which is not feasible by deploying the respective applications in remote Cloud datacentres. Edge/Fog computing, a promising extension of Cloud at the IoT-proximate network, can meet such requirements for smart CPSs. However, the structural and operational differences of Edge/Fog infrastructure resist employing Cloud-based service regulations directly to these environments. As a result, many research works have been recently conducted, focusing on efficient application and resource management in Edge/Fog computing environments. Scalable Edge/Fog infrastructure is a must to validate these policies, which is also challenging to accommodate in the real-world due to high cost and implementation time. Considering simulation as a key to this constraint, various software has been developed that can imitate the physical behaviour of Edge/Fog computing environments. Nevertheless, the existing simulators often fail to support advanced service management features because of their monolithic architecture, lack of actual dataset, and limited scope for a periodic update. To overcome these issues, we have developed multiple simulation models for service migration, dynamic distributed cluster formation, and microservice orchestration for Edge/Fog computing in this work and integrated with the existing iFogSim simulation toolkit for launching it as iFogSim2. The performance of iFogSim2 and its built-in policies are evaluated using three use case scenarios and compared with the contemporary simulators and benchmark policies under different settings. Results indicate that the proposed solution outperform others in service management time, network usage, ram consumption, and simulation time.

1 Introduction

Edge/Fog computing addresses latency-sensitive IoT processing near the network, but its distributed and heterogeneous infrastructure complicates direct use of Cloud-based management techniques. iFogSim2 extends simulation support with real datasets and models for mobility-aware migration, distributed clustering, and microservice orchestration.

  • Motivation: Edge/Fog nodes are distributed and heterogeneous, creating compatibility issues for centralized Cloud-based resource provisioning and application placement.Differences include resource architecture, communication standards, and operating principles.
  • Motivation: Real-world evaluation is costly and time-consuming because large-scale Edge/Fog deployments require numerous devices, nodes, data streams, and distributed applications.Researchers must often build infrastructure themselves because pay-as-you-go Edge/Fog providers are unavailable, while parameter changes are tedious.
  • Simulation gap: Existing simulators often lack benchmarks, rely on synthetic data, resist periodic updates, and cannot imitate complex mobility, resource, and computation scenarios.These limitations can bias performance evaluation and restrict support for advanced Edge/Fog capabilities.
  • Contribution: iFogSim2 integrates real-world datasets with simulation models for multi-tier service migration, dynamic distributed clustering, and microservice orchestration.The simulator is launched as an extension of iFogSim for broader benchmark adoption.
  • Contribution: The service migration model supports pathway and random-waypoint mobility, while clustering and orchestration models provide distributed cluster management and dynamic microservice scaling.These models target multi-tier Edge/Fog infrastructures and support integration of different policies.

2 Related work

Existing Edge/Fog simulators cover selected mobility, modularity, or application-management capabilities, but commonly lack integrated benchmark support for clustering, mobility-aware management, or microservices. iFogSim2 combines real-dataset evaluation, default benchmark techniques, and modular simulation components.

  • Existing simulators: EdgeCloudSim supports nomadic IoT mobility but assumes static gateway deployment and unchanged IoT-to-gateway link quality.Its mobility model therefore does not represent distance-dependent link variation in the described setting.
  • Existing simulators: MobFogSim supports mobility and migration but is limited to IoT gateways and Cloud datacentres, restricting tiered infrastructure and cluster formation.It extends iFogSim by modifying components with mobility features.
  • Existing simulators: PureEdgeSim offers a loosely coupled location manager, but its default mobility-aware policy is difficult to customize and its cluster and microservice support is limited.The described limitations concern both policy customization and service-management extensions.
  • Existing simulators: STEP-ONE supports real-world datasets but lacks default policies for mobility management, node clustering, and microservice orchestration.It primarily models simple business processes in Fog-based opportunistic networks.
  • Existing simulators: IoTNetSim is modular and models detailed IoT devices, including energy profiles and three-dimensional mobility, but lacks benchmark policies for mobility-driven management and dynamic clustering.SatEdgeSim models changing satellite topology and communication-distance effects but barely uses microservices.
  • iFogSim2: iFogSim2 integrates real datasets, default techniques for mobility, clustering, and microservice orchestration, and highly modular simulation components.These features distinguish it from the described gaps across contemporary simulators.

3 iFogSim2 components

iFogSim2 extends iFogSim with modular Mobility, Clustering, and Microservices components for modeling service migration, dynamic node coordination, and microservice orchestration across Edge/Fog infrastructures.

  • iFogSim2 adds Mobility, Clustering, and Microservices components to address application migration, logical node grouping, and loosely coupled service orchestration.
  • Mobility: Service migration identifies deployed application modules, moves them within a cluster or through an intermediate node, and updates module placement after mobility changes.The intermediate-node path is used when migration points lack a direct link.
  • Mobility: Directional mobility models fixed-speed acyclic movement, while random mobility supports faster generation using random_waypoint and random_walk models.The directional model uses sequential coordinates and tunable time intervals between movements.
  • Mobility: MobilityController combines iFogSim core classes with mobility-specific DataParser and LocationHandler classes to execute mobility-driven simulation events.DataParser reads external .csv data, including the EUA Dataset, while LocationHandler sequences movement events.
  • Clustering: Clustering enables distributed node coordination, with policies using communication range and/or latency while remaining decoupled from scheduling, mobility, and microservices.Cluster-member latency can be calculated and filtered against a latency constraint.
  • Microservices: The Microservices component models service discovery and load balancing, while SMP horizontally scales microservices within a cluster before moving toward upper-tier nodes.SMP is the default edgeward microservice placement policy in iFogSim2.

4 Performance Evaluation

The evaluation studies iFogSim2 across three Edge/Fog application scenarios and compares its built-in policies and lightweight modular architecture with existing simulators.

  • The evaluation uses Audio Translation Service, Cardiovascular Health Monitoring, and Crowd-sensed Data Collection case studies.
  • iFogSim2’s Mobility, Clustering, and Microservices combinations are evaluated for efficiency under different settings.
  • The study compares iFogSim2 with IoTSim-Edge and PureEdgeSim while measuring RAM usage and execution time.

4.1 Case study 1: Audio Translation Service (ATS)

The ATS case study models a mobility-driven, three-module audio translation application in iFogSim2 and compares migration policies under directional and random movement. Non-hierarchical migration minimizes migration delay, while cluster-based approaches reduce network and energy usage relative to Cloud-centric migration.

  • Application model: ATS is modeled as a DAG with Client, Processing, and Storage modules, placing computation near smartphones and storage in the Cloud for scalability.The Processing module performs audio analysis, while Storage supports periodic AI-model updates.
  • Simulation setup: The simulation uses 118 Fog gateways across 12 Melbourne CBD blocks, with smartphones connecting to tier-2 gateways and Cloud access through proxy servers.The experiment lasts 500 seconds and includes 140 location-change events.
  • Comparing policies: Three mobility-management policies are compared: Cloud-centric, Non-hierarchical, and built-in Intra/Inter-cluster migration.Intra/Inter-cluster migration uses upper-tier Fog nodes only when source and destination gateways belong to different clusters.
  • Results: Non-hierarchical migration provides the lowest migration delay by transferring modules directly between source and destination gateways through mesh connectivity.Intra/Inter-cluster migration reduces delay by selecting a nearby common accessible node, whereas Cloud-centric migration traverses the Cloud and intermediate nodes.
  • Results: Directional mobility produces better migration-delay outcomes than random mobility across all policies because constant speed reduces short-distance gateway variation and migration events.Random mobility increases migration events unevenly, increasing migration-related delay.
  • Results: Cloud-centric migration increases network usage and energy consumption, while Intra/Inter-cluster and Non-hierarchical migration reduce these costs by limiting Cloud and intermediate-node involvement.Random mobility increases network usage and energy consumption by generating more migration events.

4.2 Case study 2: Cardiovascular Health Monitoring (CHM)

The CHM case study models cardiovascular monitoring as a microservice application in iFogSim2 and evaluates three placement techniques. Microservice orchestration, especially with clustering, lowers control-loop delay, total energy consumption, and network usage compared with Edgeward placement.

  • Application model: CHM is modeled as four microservices—Client, Preprocessing, Emergency Diagnosis, and Prediction—connected through data dependencies.The Client runs on smartphones, while the other services support ECG cleaning, emergency analysis, and risk prediction.
  • Application model: Preprocessing and Emergency Diagnosis form the latency-critical service, whereas Prediction requires high computation and storage and is expected to run in the Cloud.Placement policies determine whether latency-critical services run in Fog or Cloud resources.
  • Simulation setup: The experiment uses seven Fog nodes, six WiFi gateways, one proxy server, a Cloud datacentre, and 25 smartphones sending ECG data.The simulation duration is 20000 seconds with 140 location-change events.
  • Placement techniques: Edgeward provides only vertical scalability, SMP-No-Clustering adds horizontal scalability and load balancing, and SMP-Clustering combines orchestration with Fog-node clustering.SMP-Clustering dynamically forms clusters among Fog nodes at the same hierarchical tier.
  • Results: SMP-No-Clustering and SMP-Clustering significantly reduce average control-loop delay compared with Edgeward, with SMP-Clustering achieving the best result.Clustering keeps horizontal scaling within the same tier before moving microservices upward, placing latency-critical services closer to the edge.
  • Results: SMP-No-Clustering and SMP-Clustering reduce total energy consumption, while SMP-Clustering also improves vertical or horizontal microservice scaling and load balancing.These techniques shift more microservices into Fog resources while reducing total consumption across all nodes.
  • Results: Edgeward incurs higher network usage than both orchestration-based techniques, while SMP-Clustering uses less network capacity than SMP-No-Clustering.The clustering mechanism adds lightweight cluster-formation traffic but supports efficient lower-tier Fog usage and load balancing over long simulations.

4.3 Case study 3: Crowd-sensed Data Collection (CDC)

The CDC case study models a hierarchical mobile crowd-sensing application and compares iFogSim2 with IoTSim-Edge and PureEdgeSim. iFogSim2 supports modular mobility, microservice, and clustering configurations while maintaining low resource and simulation overhead.

  • Application model: CDC collects vehicular sensor data for traffic analysis and urban road-network planning through microservices and cloud storage.Nginx routes and load-balances sensor data to processing services, which sanitize data, extract vehicle trajectories, and send results to a time-series database.
  • Simulation setup: The CDC simulation uses a hierarchical environment with mobile vehicles at the lowest tier, followed by gateway, proxy-server, and Cloud tiers.Experiments use pseudo-random parameter values and a 500-second duration with mobility intervals of 10–50 seconds.
  • Simulator comparison: iFogSim2 provides APIs and built-in policies for mobility, microservice, and node-clustering scenarios, whereas IoTSim-Edge lacks node-clustering abstractions and PureEdgeSim barely supports clustering and microservice management.The simulators were selected for comparison because they are recent, open source, and Java-based.
  • Resource usage: iFogSim2 supports five combinations of mobility, microservices, and clustering without a significant RAM increase.The supported configurations include Mobility, Mobility+Microservices, Mobility+Clustering, Microservices+Clustering, and Mobility+Microservices+Clustering.
  • Simulation performance: iFogSim2 outperforms IoTSim-Edge and PureEdgeSim in simulation time for the Mobility configuration through low-complexity mobility management and modular component handling.PureEdgeSim requires more time because its Fuzzy inference manages location changes, while IoTSim-Edge cannot manage mobility in a segmental manner.

5 Conclusions and Future Work

iFogSim2 extends iFogSim to address mobility, distributed clustering, and microservice orchestration in dynamic, heterogeneous Edge/Fog environments. Its loosely coupled components, integrated case studies, and test scripts support varied simulations, while the authors identify several future extensions.

  • Conclusions: iFogSim2 addresses service migration, distributed cluster formation across hierarchical tiers, and microservice orchestration for dynamic and heterogeneous Edge/Fog environments.Mobility, Clustering, and Microservices components can be used independently or integrated for complex scenarios.
  • Conclusions: Loosely coupled components, integrated case studies, and test scripts simplify defining new policies and case studies while contributing to a low footprint compared with related simulators.The conclusion reports effectiveness across different case studies and lower footprint relative to other simulators.
  • Future work: Future work includes monetary-based policies, distributed ledgers, communication profiles for LoRa and Bluetooth, and distributed or federated machine learning.These additions are identified as possible improvements to iFogSim2.
Loading 2109.05636v2…