,
Source-Code Analysis of iFogSim for Simulating Distributed IoT Architectures: Coverage, Challenges, and Enhancements Milliam Maxime Zekeng Ndadji1 1
Department of Mathematics and Computer Science, University of Dschang, Dschang, Cameroon Abstract. Simulation is an indispensable tool for validating distributed IoT architectures before physical deployment, and iFogSim has emerged as one of the most widely adopted platform in the fog and edge computing research community. Yet the experience of using iFogSim for non-canonical, application-specific architectures remains incompletely documented, leaving practitioners without guidance on when the tool is appropriate, which scientific objectives it can address, and how to manage the modelling approximations it imposes. This article helps in providing that guidance through two complementary contributions. First, we present a structured state of the art covering iFogSim and iFogSim2, a taxonomy of ten scientific objectives that motivate IoT architecture simulation, and a comparative survey of eight simulation tools assessed against those objectives. Second, we report our experience of simulating a four-tier smart emergency response system for resource-constrained urban environments, covering a 25-node synthetic road topology, four experimental configurations, and quantitative results including end-to-end alert latency (≈205 ms), FPGA-accelerated Dijkstra path computation (×10 CPU speedup), concurrent incident conflict rates (75% under dual load), and path-cache acceleration (×197). The analysis is organised around five practitioner questions: whether iFogSim fits the target architecture, which objectives it covers natively versus partially, what modelling challenges arise and how their workarounds bias reported results, what changes to the iFogSim source code would close the identified gaps, and whether tool co-simulation can provide comprehensive coverage. Seven modelling challenges are documented with source-code-grounded root causes and explicit bias assessments; finally, seven developer recommendations are proposed as an actionable improvement roadmap for the iFogSim community. Keywords: iFogSim, IoT simulation, Fog Computing, Edge Computing, Distributed Architecture Simulation
1. Introduction The proliferation of the Internet of Things (IoT) has catalysed the emergence of increasingly complex distributed cyber-physical architectures, in which thousands of heterogeneous sensing and actuation devices, geographically dispersed across urban or industrial environments, must cooperate in nearreal time with edge, fog, and cloud computing layers [24, 26]. The design of such systems poses significant challenges due to the intricate interplay among heterogeneous hardware capabilities, multihop communication latencies, competing workloads, and context-specific application requirements. This complexity renders analytical prediction of system behavior practically unfeasible. Consequently, simulation has become an indispensable tool in the IoT system engineer’s repertoire, offering a controlled, reproducible, and cost-effective means to assess architectural choices, tune resourcemanagement policies, and bound performance metrics before committing to physical deployment [10, 13]. 0000-0002-0417-5591 (M. M. Z. Ndadji) $ [email protected] (M. M. Z. Ndadji) https://zekeng-max.vercel.app (M. M. Z. Ndadji)
© Copyright for this article by its authors, published by the Academy of Cognitive and Natural Sciences. This is an Open Access article distributed under the terms of the Creative Commons License Attribution 4.0 International (CC BY 4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.
1
,
In the realm of simulators designed for IoT, fog, and edge computing environments, iFogSim [13] has emerged as a leading platform since its dissemination in 2017, gaining widespread adoption. Designed on the established CloudSim framework [5], it offers an event-driven simulation engine that models fog devices, IoT sensors, actuators, network links and application data-flow graphs. The engine also computes quantitative metrics, including latency, energy consumption, network usage, and cloud cost. Its open-source availability, active maintenance, and a growing body of published use cases that span healthcare monitoring [13], smart traffic management [17], and industrial task scheduling [16] have made it a standard reference in academic research. A second-generation extension, iFogSim2 [16], has been developed to support service migration, dynamic distributed clustering, and microservice orchestration. This extension extends the simulator’s applicability to mobile and dynamic edge scenarios. Notwithstanding the extensive implementation of iFogSim, the utilization of the software for simulating a tangible, application-specific IoT architecture remains inadequately documented in extant literature. Published articles generally present simulation results obtained with iFogSim; however, they rarely discuss the modeling difficulties encountered, the workarounds developed, or the bias those workarounds introduce into the reported results. The implicit knowledge embedded in such experiences is valuable for two distinct audiences: first, researchers planning to use the tool, and second, the simulator’s development community. More crucially, researchers who must select an available IoT simulator are confronted with the absence of a structured framework to guide their decision-making process. This framework would provide a comprehensive overview of iFogSim’s capabilities and limitations in capturing specific aspects of system behavior, as well as the complementary tools that can address its gaps. This article aims to address this gap by proposing a dual contribution, structured around five questions that practitioners should be able to answer before, during, and after an iFogSim simulation study: 1. To what extent is iFogSim suitable for simulating a given IoT architecture? Which structural conditions must be satisfied for iFogSim to constitute an appropriate modelling framework? 2. Which scientific objectives are within the evaluative scope of iFogSim, and which are not? What types of measurements are natively supported, and where do the intrinsic limitations of the simulator emerge? 3. What modelling challenges are likely to arise, how may they be addressed, and to what extent do the adopted solutions introduce bias? Which engineering adjustments are necessary for non-standard architectures, and how should their implications be explicitly reported? 4. What developments are required within iFogSim to bridge the identified gaps? Which specific modifications to the source code would mitigate the most significant limitations? 5. Can the integration of iFogSim with complementary tools ensure comprehensive evaluation? Which objectives lying beyond the native scope of iFogSim can be addressed through co-simulation strategies or post-processing techniques? To rigorously address the second question, we define ten scientific objectives that motivate the simulation of distributed IoT architectures: O1 performance and latency; O2 network reliability; O3 fault tolerance and resilience; O4 data-flow consistency; O5 scalability; O6 energy consumption; O7 security; O8 architectural trade-off analysis; O9 deployment cost; and O10 cyber-physical control loop fidelity. The extent to which iFogSim supports each of these objectives is evaluated through direct inspection of its source code, rather than relying exclusively on claims reported in the literature. The empirical basis for this analysis stems from our own experience in simulating a smart emergency response system for urban environments under resource-constrained conditions, whose architecture is detailed in [3] and evaluated by experts in [2]. The system represents a four-tier edge deployment in which IoT sensors, distributed across key urban zones, activate an Edge Server Node (ESN). This node computes shortest-path routes using a Dijkstra algorithm, optionally accelerated via FPGA hardware, dispatches emergency response units, and records coordination outcomes. The simulation incorporates a synthetic road network of 25 nodes and four experimental configurations,
2
,
yielding quantitative results: an end-to-end alert-to-coordination latency of approximately 205 ms, a ×10 speedup of FPGA-based computation relative to CPU execution, a 75% unit-conflict rate under concurrent dual-incident scenarios, and a ×197 acceleration factor due to path caching. Seven modelling challenges were identified, each associated with a specific source-code construct in iFogSim, accompanied by a documented workaround and an explicit assessment of the induced bias. Building on this experience, and complemented by a review of the existing literature on iFogSimbased evaluations, we propose a structured characterisation of the simulator’s capabilities and limitations in the context of distributed IoT architecture simulation. This analysis is further translated into recommendations targeting two audiences: prospective users likely to encounter similar modelling issues, and the developer community, for whom the identified limitations outline a concrete roadmap for improvement. The remainder of this article is organised as follows. Section 2 reviews the related work, including iFogSim’s architecture and prior evaluations, an analysis of the ten simulation objectives and their level of support, as well as a comparative overview of alternative tools. Section 3 describes the case study architecture, details the simulation process structured around the five guiding questions, and presents the corresponding results. Section 4 concludes the paper. 2. Literature Review This section provides a structured state of the art in three parts. Section 2.1 reviews the iFogSim simulator, its internal architecture, and its principal published evaluations. Section 2.2 identifies the ten scientific objectives that motivate simulation studies of distributed IoT architectures and characterises the extent to which iFogSim addresses each. Section 2.3 surveys the available simulation tools and compares their fitness-for-purpose relative to those objectives. 2.1. iFogSim: Architecture, Extensions, and Published Evaluations 2.1.1. The iFogSim Toolkit iFogSim [13] was introduced in 2017 as an open-source toolkit implemented in Java and built upon CloudSim [5]. Its design extends the virtual-machine abstraction of CloudSim to accommodate fog and IoT environments: fog devices are arranged in a strict tree-structured hierarchy, where each node is associated with a single parent (represented by the integer parentId in FogDevice.java); IoT sensors and actuators are modelled as leaf entities; and computation is encapsulated within application modules deployed across devices according to user-defined placement strategies. Data exchange is structured around the tuple, implemented in Tuple.java as an extension of the CloudSim Cloudlet enriched with iFogSim-specific routing metadata. This includes identifiers for source and destination modules, a propagation direction (UP toward the cloud, DOWN toward sensors, or ACTUATOR), a computational workload parameter cloudletLength expressed in MIPS-seconds, and transmission-related size attributes. Communication delay between a device and its parent is computed deterministically as d = fileSize/bandwidth ∫︁ + latency [12]. Energy consumption is accumulated over simulation time according to E = p(u) d t, where p denotes a pluggable PowerModel and u represents device utilisation; the default implementation relies∫︁on the linear model FogLinearPowerModel [12]. In parallel, deployment cost is computed as C = r·u·MIPS d t, where r corresponds to the per-MIPS-second rate. These three metrics—latency, energy, and cost—are collected automatically, making iFogSim particularly suitable for comparative evaluation of placement and scheduling policies. The original publication validated the toolkit through two representative applications. The first is an EEG beamforming pipeline, in which physiological signals captured by wearable sensors are processed across a multi-tier fog hierarchy. The second is a Distributed Control Network System (DCNS), modelling a large-scale industrial IoT deployment. In both scenarios, fog-based placement strategies
3
,
demonstrated reductions in end-to-end latency and energy consumption relative to cloud-only offloading, thereby providing empirical support for the effectiveness of fog computing architectures. 2.1.2. iFogSim2: Mobility, Clustering, Microservices iFogSim2 [16], published in 2022, addressed three limitations of iFogSim: the absence of device mobility support, static cluster structures, and the lack of microservice orchestration. It introduced a service migration model integrating real EUA (Edge-based User Allocation) dataset mobility traces, dynamic distributed cluster formation allowing fog nodes to self-organise across tiers, and a microservice orchestration model supporting containerised service placement and load-balancing across federated edge nodes. An empirical comparison against iFogSim, YAFS, LEAF, and EdgeCloudSim reported a 28% reduction in memory consumption and simulation time. Nevertheless, iFogSim2 inherits from its predecessor the tree-topology constraint, the MIPS-only compute abstraction, and the stateless module model. 2.1.3. Some Published Use Cases iFogSim has been applied in a wide range of IoT research domains, confirming its versatility for performance-oriented studies. In healthcare, the original EEG beamforming example and subsequent task-scheduling comparisons [1] demonstrated that priority-aware fog scheduling can reduce application loop delay by up to 30% over first-come-first-served baselines. In smart city traffic management, the iFogSUMO integration [17] co-simulated iFogSim’s resource management with the SUMO vehicle-flow simulator, providing a co-simulation pattern for application-layer complexity that exceeds iFogSim’s native modelling scope. Comparative surveys [4, 10] consistently confirm iFogSim’s dominant citation count and GitHub usage while also documenting its scalability ceiling for complex scenarios with more than approximately 20 fog nodes. 2.2. Scientific Objectives of Distributed IoT Architecture Simulation Researchers simulate distributed IoT architectures to address a wide range of scientific questions. Based on a review of recent literature, we identify ten primary objectives, each substantiated by published evidence of its relevance. For each objective, we indicate whether iFogSim provides native support (i.e., the metric is produced without additional user code), partial support (requiring substantial user-side implementation), or no support (necessitating external tool integration) (O1) Performance Evaluation and Capacity Planning. A central motivation for simulation lies in assessing system behaviour under both nominal and stress conditions, including latency distributions, throughput limits, resource utilisation, and bottleneck identification. This objective has been present since early fog computing studies [13] and remains predominant in the literature [10]. iFogSim support: native. For each application loop specified via an AppLoop object, the framework records end-to-end tuple latency, decomposed into network transmission time (fileSize/bandwidth), fixed propagation delay, and computation time (MI/MIPS), as tracked by TimeKeeper. Resource utilisation is available through CloudSim instrumentation. However, packet-level effects such as congestion-induced queueing or variable-rate traffic are not represented. (O2) Network Behaviour and Communication Reliability. IoT deployments rely on heterogeneous and often constrained communication technologies, including LPWAN, LTE/4G, Wi-Fi, and Bluetooth. Accurate simulation must therefore capture packet loss, delay variability, and intermittent connectivity effects [6]. iFogSim support: partial, with potential bias. Each link is characterised by fixed latency and bandwidth, along with a binary busy/free state; there is no modelling of packet loss, jitter, or congestion-induced variability. Examination of FogDevice.sendUpFreeLink() and sendDownFreeLink() confirms the deterministic application of delays. A possible workaround is to randomise sensor emission intervals, though this conflates source variability with network-level
4
,
phenomena. Consequently, the model is adequate for stable links (e.g., wired or reliable cellular networks) but may yield overly optimistic latency estimates in lossy wireless environments. (O3) Fault Tolerance and Resilience Analysis. Robust IoT systems must tolerate diverse failure modes, including sensor faults, gateway overloads, edge-node crashes, and network partitions. Simulation should reveal critical failure points, cascading effects, and recovery dynamics [21]. iFogSim support: not native. The simulated topology is static, with no built-in mechanisms for node or link failure injection. The FogDevice class lacks failure or recovery primitives. Failure scenarios must therefore be implemented manually at the controller level by modifying topology links and removing affected modules, with recovery requiring complementary custom logic. Such approaches bypass native placement mechanisms for post-failure adaptation. (O4) Data Flow, Consistency, and Processing Validation. Many IoT systems implement multi-stage data pipelines, where information is progressively filtered, aggregated, or transformed. Simulation is required to verify correct data propagation, detect anomalies such as duplication or staleness, and analyse latency trade-offs between edge and cloud processing [8, 16]. iFogSim support: native for latency and placement, not for consistency semantics. Application pipelines are modelled as DAGs using AppEdge objects and SelectivityModel rules; for example, FractionalSelectivity propagates a configurable fraction of tuples. However, the simulator lacks constructs for data versioning, timestamps, or consistency guarantees, preventing the modelling of stale reads, eventual consistency, or transactional semantics. (O5) Scalability and Elasticity Testing. Simulation provides a controlled environment for evaluating how performance evolves as system scale increases, by varying the number of devices, nodes, or modules [4, 10]. iFogSim support: native, with practical limitations. Topology size is parameterised through device instantiation loops, and the event-driven engine supports several hundred nodes in practice. However, empirical studies [10] indicate non-linear growth in execution time, with reduced reliability for complex scenarios exceeding approximately 20 fog nodes due to event-queue overhead in CloudSim. (O6) Energy Consumption and Device Lifetime Estimation. Energy considerations are critical in IoT systems, particularly for battery-powered devices. Simulation enables evaluation of energy consumption patterns, duty-cycling strategies, and expected device lifetime [27]. iFogSim support: native for compute nodes, partial for sensors. The method FogDevice.updateEnergyConsumption() integrates power usage over time using FogLinearPowerModel or custom implementations. However, energy modelling is restricted to fog and cloud nodes; sensors and actuators lack energy-related attributes such as battery level or transmission cost. For detailed device-level energy analysis, complementary tools such as LEAF [27] are required. (O7) Security and Attack Surface Exploration. Simulation can be used to analyse adversarial scenarios, including denial-of-service attacks, spoofing, interception, and data poisoning [19, 20]. iFogSim support: not native. The simulator provides no constructs for authentication, encryption overhead, or integrity verification. Although malicious behaviour can be approximated by injecting custom tuples from arbitrary SimEntity instances, there is no support for modelling protocol-level security mechanisms or evaluating detection strategies. Dedicated simulators (e.g., NS-3 with security extensions) are more appropriate for such studies. (O8) Architectural Trade-Off Analysis. Simulation is particularly valuable for comparing alternative architectural designs without physical deployment, such as different placement strategies or processing paradigms [13, 25]. iFogSim support: native and strong. This constitutes the primary use case of the simulator: different ModulePlacementPolicy implementations can be applied to the same application DAG, enabling direct comparison of latency, energy, and cost without modifying the underlying topology or application definition. (O9) Cost Modelling and Economic Feasibility. Economic considerations, including operational costs and scalability trade-offs, are often incorporated into simulation studies [13]. iFogSim support:
5
,
native but limited. Each FogDevice includes a ratePerMips parameter enabling computation of processing cost, aggregated in totalCost. However, other economic dimensions—such as storage, bandwidth pricing, or capital expenditure—are not represented and must be modelled externally. (O10) Validation of Control Logic and Cyber-Physical Behaviour. In cyber-physical systems, it is essential to validate control loops under realistic timing constraints, including feedback stability and actuation correctness [7]. iFogSim support: partial and structurally constrained. While open-loop pipelines (sensor → processing → actuator) are supported via AppLoop and TimeKeeper, actuators remain passive: Actuator.processTupleArrival() records latency without influencing subsequent system state. Sensors operate on fixed emission schedules independent of actuator output, precluding the simulation of true closed-loop dynamics where actuation affects future sensing. Table 1 consolidates the support assessment. Table 1 iFogSim support for the ten simulation objectives # Objective O1 Performance & capacity O2 Network behaviour & reliability O3 Fault tolerance & resilience O4 Data flow & consistency O5 Scalability & elasticity O6 Energy consumption O7 Security & attacks O8 Architectural trade-offs O9 Cost modelling O10 Control loop / cyber-physical
iFogSim support Native Partial Not native Partial Native Partial Not native Native (primary use) Partial Partial
Limiting factor No congestion model No packet loss, no jitter No failure/recovery mechanisms No consistency semantics Ceiling at ≈20 fog nodes IoT sensors have no energy budget No threat model Topology must be tree No storage or bandwidth billing Actuators are passive
2.3. Available Simulation Tools and Comparative Analysis The simulation of fog and edge computing environments is served by a heterogeneous ecosystem of tools [4, 10]. We review the principal platforms and their fitness-for-purpose relative to the ten objectives identified above. Table 2 provides a consolidated comparison. iFogSim / iFogSim2 [13, 16] cover objectives O1, O4 (partly), O5, O6 (partly), O8, and O9 natively, with partial coverage of O2, O4, O10. O3 (fault tolerance) and O7 (security) require substantial custom extensions. The tree-topology constraint is fundamental. YAFS [15] is a Python/NetworkX/SimPy simulator that supports arbitrary graph topologies. Its NetworkX backend provides native shortest-path querying, making it naturally suited to routingintensive applications. It lacks energy modelling comparable to iFogSim, and its community support is smaller. EdgeCloudSim [25] is a Java/CloudSim platform specialised for mobile edge computing with client mobility and cellular network models. Well suited for O2 (via mobility-induced handover) and O3 (with custom extensions), but less general than iFogSim for multi-tier fog hierarchies. FogNetSim++ [23] is built on OMNeT++/INET, providing packet-level network simulation including error rates and link-layer protocols. This makes it the best available tool for O2 (network reliability) and O3 (fault injection via OMNeT++ failure models), at the cost of a steeper learning curve and less developed IoT application modelling. LEAF [27] is a Python-based energy-focused simulator supporting arbitrary graph topologies. It provides the most detailed per-device power modelling of any available tool, making it the recommended complement for O6. Its computation model is simpler than iFogSim’s.
6
,
NS-3 [22], while not a fog computing simulator per se, is the reference platform for O2 (packetlevel network fidelity, including 802.11, LTE, and LPWAN models with probabilistic packet loss and channel fading) and O7 (security via protocol-level attack injection). It lacks the application-layer and resource-management modelling of iFogSim. PureEdgeSim [18] is a Java simulator for pure edge computing with a built-in GUI, supporting mobility and heterogeneous device types. It partially addresses O3 through device heterogeneity and mobility-induced disconnection. Table 2 Simulation tools vs. the ten objectives (N=Native, P=Partial, –=Not supported) Tool iFogSim [13] iFogSim2 [16] YAFS [15] EdgeCloudSim [25] FogNetSim++ [23] LEAF [27] NS-3 [22] PureEdgeSim [18]
O1 N N N N N N N N
O2 P P P P N – N P
O3 – P – P N – N P
O4 P P P – – – – –
O5 N N N N N N N N
O6 P P – – – N P P
O7 – – – – P – N –
O8 N N N N P N P N
O9 P P – – – P – –
O10 P P P – – – P –
The comparative landscape yields three recommendations for simulation study design. First, iFogSim is the strongest single tool for architectural trade-off analysis (O8), performance and latency benchmarking (O1), and cost modelling (O9) of hierarchical fog/edge deployments. Second, objectives O2 and O7 require dedicated network and security simulators: NS-3 or FogNetSim++ should be used standalone or in a hybrid co-simulation arrangement where iFogSim covers the application layer and NS-3 covers the network channel. Third, fault tolerance (O3) is best addressed through iFogSim2 extensions or FogNetSim++, depending on whether the primary concern is service placement under failure or packet-level network failure. The following section documents our first-hand experience applying these principles to a concrete IoT architecture. 3. Simulation Experience and Lessons Learned This section presents our complete experience in simulating a smart emergency response architecture using iFogSim. The discussion is structured around the five questions introduced in Section 1. Sections 3.1 to 3.4 describe the simulation context and obtained results, while Sections 3.2 to 3.8 develop the corresponding analysis and recommendations. 3.1. Architecture Under Study The architecture under consideration is a four-tier IoT/fog/edge system designed for emergency response coordination in resource-constrained urban environments, originally proposed in [3] and theoretically validated in [2]. It supports the complete lifecycle of an emergency incident over a geographically distributed infrastructure composed of heterogeneous devices: • Tier 1 – Situation Awareness Sensors (SAS): low-power sensing devices deployed across urban zones that detect incident conditions and transmit raw alerts to the zone-level processing layer via short-range communication links (5 ms latency). • Tier 2 – Context-Aware Dispatchers (CAD): edge computing units co-located with zone infrastructure that pre-process sensor data, validate alerts, and forward structured incident tuples to the central coordination node over 4G/LTE links (100 ms latency). • Tier 3 – Edge Server Node (ESN): the central coordination entity, implemented as an FPGAaugmented edge server, which executes the Dijkstra algorithm on the road network to identify and prioritise the nearest available response units, and subsequently issues dispatch instructions.
7
,
• Tier 4 – Intervention Order Processing Systems (IOPS): embedded systems within emergency response units (e.g., fire brigades, police, medical and specialised intervention teams) that receive dispatch orders and provide guidance to field operators. The ESN integrates two optimisation mechanisms. First, FPGA-based acceleration of the Dijkstra algorithm yields an estimated ×10 speedup relative to CPU execution, as reported in prior FPGA implementations of shortest-path computation [9, 11, 14]. Second, a path-caching mechanism stores computed distance maps in shared memory, enabling subsequent incidents within the same zone to reuse previously computed results and avoid full graph traversal. The combination of a multi-tier fog hierarchy, graph-based computation, hardware acceleration, distributed caching, and concurrent multi-incident handling makes this architecture substantially more complex than the canonical examples provided with iFogSim. 3.2. Q1 – Can iFogSim Be Used to Simulate This Architecture? iFogSim is structured around three core abstractions: a hierarchical device topology, where FogDevice instances are connected through parent–child relationships; an application-level data-flow graph, where AppModule nodes are linked by typed AppEdge connections; and a tuple-driven execution model, in which each processing step consumes a fixed computational workload (expressed in MI) and produces output tuples that propagate through the graph [13]. The framework further provides built-in instrumentation for latency (via TimeKeeper and AppLoop), energy consumption (via FogLinearPowerModel within FogDevice.updateEnergyConsumption()), and cloud cost (via the ratePerMips parameter). These features make iFogSim an effective baseline platform for fog and edge computing studies. The answer to Q1 is nevertheless conditional. While iFogSim enables simulation of the proposed architecture, not all of its characteristics can be faithfully represented within the native modelling framework. For the primary objectives associated with this system - namely end-to-end alert latency (O1), architectural trade-off analysis across placement strategies (O8), and cost evaluation across system layers (O9) - iFogSim offers full native support. In contrast, for objectives that are also relevant to this architecture such as fault tolerance (O3), realistic network behaviour (O2), security analysis (O7), and closed-loop control validation (O10), the simulator either requires substantial custom extensions or does not provide adequate support. Consequently, a pragmatic usage strategy emerges: iFogSim is well suited as the primary simulation tool when the study focuses on objectives O1, O4 (partially), O5, O8, and O9, and when the system topology conforms to, or can be approximated by, a tree-structured hierarchy. For objectives O2, O3, and O7, complementary specialised tools should be employed. In the case of O10, which involves genuine closed-loop control behaviour, achieving faithful simulation would require significant extensions to the underlying framework. 3.3. Simulation Methodology 3.3.1. Topology Design The simulated city was represented as a synthetic road network of 25 nodes and 41 bidirectional weighted edges, where edge weights represent road-segment distances in kilometres. The nodes comprise five strategic city zones (z1–z5, each hosting an SAS sensor and a CAD device), three fire stations (c1–c3), two police stations (p1–p2), three medical services (u1–u3), two anti-terrorism brigades (b1–b2), and ten road-relay junctions (a1–a10). Because iFogSim requires a strict tree hierarchy enforced by the single integer FogDevice.parentId field, this sparse undirected road graph was projected onto a two-level iFogSim tree: the ESN at level 1, all five CADs and eight unit IOPSs as siblings at level 2, and SAS sensors and ITGS actuators as leaves. Road-graph routing (Dijkstra on the full 25-node adjacency matrix) was executed externally as a Java pre-processing
8
,
step; the resulting distance matrix was injected as per-unit travel-time constants. This hybrid design is described in detail under Challenge C1 (Section 3.6). 3.3.2. Device Parameter Mapping Table 3 presents the iFogSim parameters assigned to each device tier, calibrated against the architectural specification in [3]. The ESN’s 10 000 MIPS rating encodes the FPGA speedup as a scalar multiplier (see C2 in Section 3.6). Table 3 iFogSim device parameters by architecture tier Device (role) ESN edge server (FPGA) Zone device (CAD) Unit device (IOPS) IoT sensor (SAS) ITGS actuator
MIPS 10 000 2 000 1 500 – –
RAM 8 192 MB 1 024 MB 512 MB – –
Network latency 50 ms (uplink to cloud) 100 ms (4G/LTE to ESN) 80 ms (WAN to ESN) 5 ms (local to CAD) 15 ms (local to IOPS)
Level 1 2 2 – –
3.3.3. Application Data-Flow Graph The application DAG was encoded using three AppModule nodes connected by directed AppEdge arcs with FractionalSelectivity models: 1. cad-module (500 MI): deployed on the zone CAD; captures the raw SAS alert tuple, validates it, and forwards a structured incident tuple to the ESN. 2. esn-coordinator (5 000 MI total: 2 000 MI for alert classification and 3 000 MI for dispatch computation): deployed on the ESN; runs the Dijkstra pre-computation, selects the eight optimal response units, and generates one dispatch tuple per unit. 3. iops-module (1 000 MI): deployed on each unit IOPS; receives the dispatch tuple, processes the guidance order, and confirms via an ITGS actuator event. Each incident generates 18 tuples in total: 2 for the alert chain (SAS → CAD → ESN) and 16 for dispatch and confirmation (2 tuples × 8 units). Network-latency variability was approximated by applying a ±2% Gaussian perturbation to sensor emission intervals, representing simplified radio-channel jitter. 3.4. Simulation Results Four experiments were designed to test orthogonal performance dimensions of the architecture. 3.4.1. Experiment 1 – System Consistency Five repeated runs of a fire incident at zone z1 showed negligible temporal variance (standard deviation <0.001 min in total intervention time). End-to-end coordination latency totalled approximately 205 ms. Dijkstra computation completed in approximately 0.027 ms on the CPU-equivalent device and approximately 0.003 ms on the FPGA-equivalent (10 000 MIPS) device. Travel times dominated total intervention time, ranging from 1.5 min for the nearest unit to 16.65 min for the most distant. The deterministic reproducibility across five runs confirms iFogSim’s reliability for consistent performance benchmarking.
9
,
3.4.2. Experiment 2 – Geographic Sensitivity A single fire incident was simulated at each of the five zones. Mean total intervention times ranged from 4.95 min (zone z4, with three units within 1.5 min) to 9.59 min (zone z1, with several units located over 10 min away). Coordination latency was identical across all zones (≈205 ms), confirming that the digital processing pipeline contributes less than 0.003 min to total response time and that the bottleneck is purely geographic. The ESN’s Dijkstra dispatch always selects the globally optimal unit but cannot compensate for asymmetric facility placement, an insight relevant to urban infrastructure planning. 3.4.3. Experiment 3 – Concurrent Incident Handling Two simultaneous fire incidents at z1 and z2 produced a unit-sharing conflict rate of 75% (6 of 8 units optimally assigned to both zones). Conflicted units incurred a +20% travel-time penalty under the greedy assignment policy. Alert-processing latency increased by approximately 5% under dual load (205 ms to 211 ms), demonstrating the ESN’s computational resilience. FPGA parallelism would allow both Dijkstra computations to execute simultaneously (≈0.002 ms each), whereas a CPU-only ESN would incur sequential execution overhead of approximately 15%. 3.4.4. Experiment 4 – Path Cache Acceleration Five consecutive incidents at z1 with the path cache persistent between runs showed that warm-cache hits reduce Dijkstra lookup time by a factor of approximately 197 (≈0.000135 ms vs. ≈0.027 ms cold start). At 25-node scale this gain is operationally negligible relative to travel time; however, it becomes architecturally significant at real-city scale (hundreds of nodes) and under high-frequency incident bursts in the same geographic zone. 3.5. Q2 – Which Aspects Can and Cannot Be Evaluated? Table 4 maps the ten simulation objectives (Section 2.2) to the coverage achieved in our simulation, based on iFogSim’s source-code capabilities and the experience of the four experiments. For each objective, we indicate whether native support was sufficient, whether a workaround was necessary, or whether the objective was not addressable. Table 4 Coverage of the ten simulation objectives in our study #
Objective
iFogSim support
Coverage achieved
O1
Performance & latency
Native
Full (Exp. 1–3)
O2
Network reliability
Partial
Minimal
O3 O4
Fault tolerance Data flow / consistency
Not native Partial
Not covered Partial (DAG flow)
O5
Scalability
Native
Partial (25 nodes)
O6
Energy consumption
Partial
Fog nodes only
O7 O8
Security Trade-off analysis
Not native Native (primary use)
Not covered Full (Exp. 1,3)
O9
Cost modelling
Partial
ESN cost only
O10 Control loop validation
Partial
Open-loop only
10
Limiting factor / workaround Sub-ms figures: JVM noise (C6) No packet loss; ±2% jitter only (C5) Static topology (C7) No consistency semantics Fixed topology; no size variation SAS sensors: no energy budget No threat model Tree constraint (C1) No bandwidth or sensor billing Passive actuators
,
The table reveals a clear pattern: the four objectives that iFogSim covers natively or well (O1, O5, O8, O9) align precisely with its original design purpose of policy comparison and performance characterisation in hierarchical fog deployments. The six remaining objectives either require workarounds that introduce modelling approximations, or fall entirely outside iFogSim’s scope. Practitioners who need comprehensive coverage of all ten objectives should not expect to achieve it with iFogSim alone. 3.6. Q3 – Challenges, Workarounds, and Bias Analysis We present in this section, the modelling challenges encountered during simulation, together with the corresponding engineering adaptations and their methodological implications. For each challenge, we systematically report: (i) its root cause in the iFogSim source-code architecture; (ii) the workaround implemented; (iii) the residual bias introduced; and (iv) a practical guideline for controlling or disclosing this bias. A consolidated view is provided in Table 5. The identified challenges fall into three categories: structural limitations of the modelling framework (C1, C7), abstractions that oversimplify computation or hardware behaviour (C2, C3, C4), and limitations of the discrete-event execution engine (C5, C6). This classification is useful because it directly informs whether a limitation can be mitigated locally, requires systematic calibration, or necessitates external validation. C1 – Non-Tree Road Topology. Root cause: The FogDevice.parentId field (an int in FogDevice.java) enforces a strict singleparent hierarchy. Routing methods such as sendUpFreeLink() and sendDownFreeLink() rely exclusively on parentId and childrenIds, with no provision for peer-to-peer or multi-parent connectivity. Workaround: The 25-node road graph was mapped onto a two-level tree (ESN as the unique parent of all CAD and IOPS nodes). Shortest-path computation was performed externally on the full graph, and resulting travel times were injected as fixed tuple latencies. Communication latency (4G/LTE, WAN) remained natively modelled by iFogSim. Bias assessment: The separation between communication latency (≈200 ms) and physical travel time (1.5–16.7 min) is semantically valid and introduces negligible distortion under static routing assumptions. However, the model omits dynamic routing effects (e.g., congestion, blockages) and multi-hop relay behaviour. Bias is therefore low for static scenarios and moderate to high for dynamic urban conditions. C2 – FPGA Hardware Acceleration. Root cause: Computational capacity is represented by a single scalar mips in FogDevice. The execution model (t = MI/MIPS in CloudletSchedulerSpaceShared) does not encode parallelism, pipeline depth, or hardware heterogeneity. Workaround: FPGA acceleration was approximated by scaling the ESN capacity to 10 000 MIPS versus ≈1 000 MIPS for CPU execution, reflecting a ×10 speedup [11]. Bias assessment: While throughput scaling is captured, parallel execution is not. Concurrent workloads are therefore serialised in the model, underestimating FPGA advantages in multi-incident scenarios. Bias is moderate: qualitative trends are preserved, but quantitative gains depend on unmodelled parallelism. External benchmarking is recommended for validation. C3 – Algorithm Complexity as MI Black Box. Root cause: Each AppModule executes a fixed cloudletLength (MI) per tuple, independent of input size or algorithmic complexity. No mechanism expresses complexity classes such as O (V log V ). Workaround: The Dijkstra workload (3 000 MI) was calibrated using JVM profiling on the 25-node graph and mapped to a MIPS-equivalent execution time. Bias assessment: Calibration is accurate for the fixed topology, yielding negligible bias for O1 and O8. However, scalability studies require re-calibration for each topology size. Without this, conclusions on performance scaling carry high bias. C4 – Persistent Path Cache.
11
,
Root cause: AppModule (extending PowerVm) is stateless across events. No persistence mechanism exists for cross-tuple state. Workaround: A static HashMap<String, double[]> was used to emulate a shared cache. Cache hits were modelled via conditional MI reduction (full MI for cold runs, ≈0.5 MI for warm runs). Bias assessment: The measured ×197 speedup is valid as an upper bound for cold-versus-warm execution. However, the model omits cache invalidation, memory constraints, and concurrent access effects. Bias is low for relative comparison, but must be explicitly reported as an optimistic estimate. C5 – Concurrent Multi-Incident Processing. Root cause: iFogSim relies on a single global event queue (CloudSim.runClockTickAndProcess()), processing events sequentially. Link flags (isNorthLinkBusy, isSouthLinkBusy) enforce directional serialisation but do not model true parallelism. Workaround: Latency overheads under concurrent incidents (+5%) and CPU execution penalties (+15%) were estimated analytically using FIFO queueing assumptions. Bias assessment: This represents one of the highest-bias approximation. True contention depends on event overlap, bandwidth, and scheduling dynamics, none of which are observable in the simulator. The reported figures are heuristic rather than simulated. Analytical queueing models or packet-level simulators (e.g., NS-3) are required for validation. C6 – Sub-Millisecond Timing Precision. Root cause: The simulation clock is a double in milliseconds. JVM effects (garbage collection, JIT warm-up) introduce variability (1–50 ms) exceeding the computation time of interest (≈0.027 ms). Workaround: Execution time was measured via an external microbenchmark (1 000 runs), and the median value used for MI calibration. Bias assessment: Absolute timing carries moderate uncertainty (±10%), but relative comparisons (e.g., ×10, ×197) are low-bias due to shared noise sources. Sub-millisecond results should always include uncertainty bounds. C7 – Static Topology Assumption. Root cause: Topology is fixed at initialisation via Controller.connectWithLatencies(), with no runtime modification. No failure or recovery mechanisms exist in FogDevice or FogEvents. Workaround: None; all experiments assume stable connectivity. Bias assessment: No workaround implies no distortion of reported metrics, but introduces a coverage limitation: objectives O2, O3, and dynamic aspects of O1 are not evaluated. This must be explicitly acknowledged. The synthesis provided in Table 5 highlights that most modelling adaptations introduce controlled and interpretable bias when handled transparently. Reliable practice requires: separating distinct latency domains (C1); validating hardware abstractions with empirical benchmarks (C2); recalibrating computation models under scaling (C3); reporting cache-based gains as upper bounds (C4); and complementing simulation with analytical or network-level models for concurrency (C5). Among all challenges, C5 presents the highest risk of misleading conclusions and constitutes a primary motivation for extending the iFogSim execution model. 3.7. Q4 – What Needs to Be Developed in iFogSim? The preceding analysis highlights a set of systematic discrepancies between the current capabilities of iFogSim and the requirements of comprehensive IoT architecture simulation. These gaps arise directly from the source-level limitations identified in Section 3.6 and the objective coverage analysis in Table 4. The following seven development directions constitute a concrete and actionable roadmap. Each recommendation is explicitly linked to the underlying modelling limitation(s) and to the scientific objectives it would enable or improve. The proposed extensions can be grouped into three categories: topology and network modelling (D1, D5), computation and execution semantics (D2, D3,
12
,
Table 5 Summary of modelling challenges, workarounds, and bias levels C#
Challenge
Workaround External Dijkstra + injected travel latency
Bias level
C1
Non-tree topology
C2
FPGA as high-MIPS device
×10 MIPS scalar multiplier
Moderate
C3
Algorithm black box
Topology-specific MI calibration Static HashMap with programmed hit/miss
Low (fixed graph); High (scalability) Low (upper bound)
C4
Stateless cache
C5
Concurrent incidents
Analytically estimated latency penalty
High
C6
Sub-ms timing noise
Microbenchmark-based MI calibration
C7
Static topology
None adopted
as
MI
Low–Moderate
Moderate (absolute); Low (ratios) N/A (coverage gap)
Scope of bias Dynamic routing; junction hops Parallel concurrency benefit underestimated Breaks O5 scalability analysis Omits eviction and contention True resource contention not simulated JVM GC and JIT variability O2, O3, dynamic O1 not evaluated
D4), and measurement fidelity and energy modelling (D6, D7). This categorisation reflects increasing levels of architectural impact, from local extensions to core engine modifications. D1 – Arbitrary graph topology (addresses C1, O2, O3, O8). Replace the current single-parent hierarchy (encoded by parentId in FogDevice) with a general adjacency-list representation supporting multiple neighbours, weighted links, and pluggable routing strategies. The existing DAG.java class in the org.fog.application package already provides a suitable abstraction for application graphs; a corresponding PhysicalGraph structure for device topology would ensure conceptual symmetry. This extension would also enable dynamic rerouting and link removal, thereby supporting fault tolerance (O3) and more realistic network behaviour (O2). D2 – Heterogeneous compute-device model (addresses C2, O1, O8). Augment FogDevice with a ComputeArchitecture enumeration (e.g., CPU, FPGA, GPU) and an explicit parallelismDegree parameter. The cloudlet scheduling logic should then account for parallel execution by scaling computation time according to the degree of parallelism for supported architectures. This would replace the current scalar MIPS approximation with a principled model of heterogeneous hardware and enable accurate representation of parallel workloads. D3 – Concurrent event processing (addresses C5, O1, O8). Introduce a ParallelEventQueue abstraction capable of processing independent event streams concurrently within a simulation timestep. Such an extension would allow multiple incidents or application instances to evolve in parallel, rather than being serialised by a global queue. As a lower-impact alternative, the framework could expose per-device queue lengths and service rates, enabling integration with external queueing models (e.g., M/M/c) for post hoc validation. D4 – Stateful module abstraction (addresses C4, O4, O10). Define a StatefulFogModule interface with lifecycle hooks such as onInit(), onTupleArrival(Tuple t), onCheckpoint(), and onRestore(). This would allow persistent state (e.g., caches, session data, control variables) to be managed within the simulator’s execution model while preserving correct event ordering. It would eliminate reliance on static variables and enable faithful modelling of data consistency and control-loop behaviour. D5 – Runtime topology events (addresses C7, O2, O3). Introduce a TopologyEvent abstraction supporting operations such as failDevice(id), recoverDevice(id), setLinkLatency(src, dst, newMs), and setLinkBandwidth(src, dst, newBps). By scheduling these events through
13
,
the standard CloudSim messaging mechanism, the simulator would support dynamic topology evolution, enabling fault injection (O3) and time-varying network conditions (O2) without requiring extensive architectural changes. D6 – High-resolution timing and uncertainty quantification (addresses C6, O1). Enhance temporal precision by replacing the millisecond-resolution event clock with a double-precision nanosecond representation. In parallel, extend TimeKeeper to compute and export statistical summaries (mean, variance, and 95% confidence intervals) for application-loop latency. This would enable rigorous reporting of sub-millisecond phenomena and reduce reliance on external microbenchmarking. D7 – IoT sensor energy model (addresses O6). Extend the Sensor class with explicit energy-related attributes, including batteryCapacityMJ and a transmission energy model (e.g., energy per tuple in mJ). The simulation engine should then track battery depletion alongside existing fog-device energy metrics, providing a unified view of energy consumption from sensing to cloud processing. This extension would enable end-to-end energy analysis across all architectural tiers. Taken together, these recommendations outline a coherent evolution path for iFogSim, transforming it from a placement-oriented simulator into a more general-purpose platform capable of supporting the full spectrum of IoT system evaluation objectives. 3.8. Q5 – Can Combining iFogSim With Other Tools Help? The limitations identified in the previous sections naturally motivate the exploration of hybrid simulation strategies. The central question is whether iFogSim can be complemented with specialised tools to achieve broader objective coverage, while preserving its strengths in performance evaluation and architectural trade-off analysis. Table 6 outlines concrete integration strategies for objectives that are only partially supported or not supported at all by iFogSim. Each strategy specifies a recommended tool and an associated integration pattern. The proposed combinations follow three distinct integration paradigms: (i) trace-driven coupling, where an external simulator produces network-level traces that are injected into iFogSim (O2, O7); (ii) co-simulation, where two simulators exchange state during execution (O10); and (iii) post-processing aggregation, where independent simulations are combined analytically (O6). These paradigms differ significantly in implementation complexity and reproducibility. Practical considerations. The feasibility of these integrations varies substantially. Trace-driven coupling with NS-3 (O2, O7) is technically demanding, as it requires designing a robust trace-replay interface between heterogeneous simulation environments; no standardised integration currently exists, and existing approaches are typically ad hoc. In contrast, the LEAF/iFogSim combination (O6) is straightforward, as it relies solely on post-processing aggregation without runtime coupling. The use of iFogSim2 for fault tolerance studies (O3) remains within a single framework but requires non-trivial Controller-level extensions. Co-simulation with Simulink or Modelica (O10) is the most complex approach and is justified only when closed-loop cyber-physical behaviour is central to the research question. Recommended strategy. A pragmatic approach, particularly under typical research constraints, is to adopt a layered methodology: iFogSim serves as the primary simulation platform for objectives O1, O4, O5, O8, and O9; NS-3 or FogNetSim++ is used in a separate experimental campaign to validate network-related aspects (O2, O7); and LEAF complements the analysis for sensor-level energy modelling (O6). This three-layer strategy enables coverage of eight out of the ten identified objectives while ensuring that each tool is used within its domain of validity. In this perspective, hybrid simulation should not be viewed as a workaround, but rather as a principled decomposition of the problem across specialised modelling layers, each addressing a distinct aspect of the overall system.
14
,
Table 6 Tool combination strategies for objectives not fully covered by iFogSim #
Objective
Recommended tool
O2
Network reliability
NS-3 [22] or FogNetSim++ [23]
O3
Fault tolerance
iFogSim2 [16] or FogNetSim++
O6
Sensor energy
LEAF [27]
O7
Security
NS-3 with security extensions
O10 Control loop
Simulink / Modelica cosimulation
Integration pattern Execute network-layer simulations (e.g., 4G/LTE, Wi-Fi) in NS-3; extract per-link delay distributions and loss rates; inject these as stochastic latency parameters in iFogSim (e.g., via sensor emission timing or modified link delays). Implement failure injection at the Controller level in iFogSim2 (e.g., using processClustering() for rebalancing). For packet-level failures, leverage FogNetSim++’s OMNeT++-based failure models. Perform independent LEAF simulations on the same topology to model sensor-level energy consumption; combine results with iFogSim fogdevice energy outputs during post-processing. Simulate adversarial scenarios (e.g., DoS, spoofing) at the network level in NS-3; replay resulting delay and loss traces within iFogSim to assess application-layer impact. Model the physical process in Simulink or Modelica; interface with iFogSim via shared memory or sockets to allow actuator outputs to influence subsequent sensor events, enabling closed-loop behaviour.
4. Conclusion This article has presented a structured assessment of iFogSim as a simulation platform for distributed IoT architectures, grounded in two complementary sources: a systematic review of the literature and a fully documented case study involving the simulation of a smart emergency response system in resource-constrained urban environments [3]. The analysis was organised around five key questions that collectively define a methodological framework for conducting and interpreting iFogSim-based studies. Q1 – Suitability of iFogSim for a given architecture. The literature review (Section 2) confirms that iFogSim and its successor iFogSim2 occupy a central position in the fog and edge computing simulation landscape, supported by the maturity of CloudSim, extensive built-in instrumentation, and sustained community adoption. However, suitability is conditional. iFogSim is most appropriate for architectures that can be expressed as a tree-structured device hierarchy, with computation abstracted via MIPS and evaluation centred on latency, energy, and placement strategies. Architectures requiring arbitrary network topologies, heterogeneous hardware abstraction, persistent module state, packetlevel network fidelity, fault injection, or security modelling extend beyond its native capabilities. Section 3.2 formalises this assessment as a decision framework. Q2 – Coverage of scientific objectives. The ten simulation objectives defined in Section 2.2 provide a structured lens for evaluating tool capabilities. Based on source-code inspection and the experimental results reported in Section 3.4, iFogSim offers full native support for performance evaluation (O1) and architectural trade-off analysis (O8); partial but usable support for scalability (O5) and cost modelling (O9); and limited or indirect support for network behaviour (O2), data consistency (O4), energy modelling at the sensor level (O6), and cyber-physical control validation (O10). Fault tolerance (O3) and security (O7) are not supported without external tools. Table 4 operationalises these distinctions for study design.
15
,
Q3 – Modelling challenges and bias. Seven modelling challenges (C1–C7) were identified and analysed in Section 3.6, each traced to a specific design choice in the iFogSim codebase. The key result is that not all workarounds are equivalent in their methodological impact. In particular, C5 (concurrent incident processing) introduces high bias, as the event-driven engine serialises execution and prevents direct modelling of contention; the 75% unit-conflict rate observed in Experiment 3 is therefore analytically derived rather than simulated. In contrast, challenges such as C1 (non-tree topology) and C4 (stateless modules) introduce low to moderate bias within the studied context. Explicitly reporting these bias levels is essential for the scientific validity and interpretability of results. Q4 – Required extensions to iFogSim. Seven development directions (D1–D7) were proposed in Section 3.7, forming a coherent roadmap grounded in observed limitations. Among these, support for arbitrary graph topologies (D1) and heterogeneous compute models (D2) would resolve the most pervasive modelling constraints. Extensions enabling concurrent event processing (D3) and stateful modules (D4) would significantly broaden applicability, particularly for cyber-physical systems. Runtime topology events (D5) would enable fault-injection studies, while high-resolution timing (D6) and sensor-level energy modelling (D7) would improve measurement fidelity. Each proposal is anchored in specific source-code structures, facilitating direct implementation. Q5 – Role of hybrid simulation. Section 3.8 demonstrates that combining iFogSim with specialised tools provides a practical path toward comprehensive coverage. NS-3 or FogNetSim++ complement iFogSim for network reliability (O2) and security (O7); LEAF provides fine-grained energy modelling for sensors (O6); iFogSim2 with custom extensions supports fault tolerance (O3); and co-simulation with Simulink enables closed-loop validation (O10). A layered strategy—iFogSim for applicationlevel evaluation, NS-3 for network validation, and LEAF for energy analysis—covers eight out of ten objectives while preserving methodological clarity. Synthesis and contribution. Beyond a conventional comparative survey, this work contributes two methodological advances. First, every limitation is grounded in explicit source-code analysis, transforming qualitative observations into verifiable claims. Second, each workaround is accompanied by an explicit bias characterisation, enabling researchers to interpret results in light of their methodological constraints. In our view, this explicit treatment of modelling bias is essential for advancing simulation-based research beyond tool-centric evaluation toward reproducible and interpretable experimentation. Future work. Three directions are envisaged. First, implementing the same emergency-response topology in YAFS will enable a quantitative comparison and an empirical assessment of the error introduced by iFogSim’s tree-topology constraint (C1). Second, the FPGA acceleration factor used in Experiment 2 will be validated experimentally on a Xilinx Zynq-7000 platform, replacing the current MIPS-based approximation (C2) with measured hardware performance. Third, recommendations D1 and D5 will be prototyped as an iFogSim extension supporting arbitrary graph routing and runtime topology evolution, with the objective of releasing an open-source module for resilience and cyber-physical simulation studies. Funding This research received no external funding. Data availability statement No new data were created or analysed during this study. Data sharing is not applicable.
16
,
Conflicts of interest The authors declare no conflict of interest. Declaration on Generative AI During the preparation of this work, the authors utilized Grammarly and Deepl in order to check grammar/spelling and to rewrite some parts of the paper. After using this tool/service, the authors reviewed and edited the content as needed and takes full responsibility for the publication’s content. References [1] Alizadeh, M.R., Khajehvand, V., Rahmani, A.M. and Akbari, E., 2020. Task scheduling approaches in fog computing: A systematic review. International journal of communication systems, 33(16), p.e4583. E4583 IJCS-19-0949.R2. https://onlinelibrary.wiley.com/doi/pdf/10.1002/dac.4583, Available from: https://doi.org/https://doi.org/10.1002/dac.4583. [2] Assoul, M.A.A., Ndadji, M.M.Z., Tsofack, B.N., Mdemaya, G.B.J., Tahir, A.M. and Mahmoud, T., 2025. Expert-based evaluation of a smart emergency response system for urban settings in resource-constrained environments. Preprints, September. Available from: https://doi.org/10. 20944/preprints202509.1016.v1. [3] Aziz Assoul, M.A., Tahir, A.M., Mahmoud, T., Jagho Mdemaya, G.B. and Zekeng Ndadji, M.M., 2024. A comprehensive system architecture using field programmable gate arrays technology, dijkstra’s algorithm, and edge computing for emergency response in smart cities. Paradigmplus, 5(2), Aug., pp.1–21. Available from: https://doi.org/10.55969/paradigmplus.v5n2a1. [4] Bendaouch, F., Zaydi, H., Merzouk, S. and Assoul, S., 2025. Benchmarking iot simulation frameworks for edge–fog–cloud architectures: A comparative and experimental study. Future internet, 17(9). Available from: https://doi.org/10.3390/fi17090382. [5] Calheiros, R.N., Ranjan, R., Beloglazov, A., De Rose, C.A.F. and Buyya, R., 2011. Cloudsim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms. Software: Practice and experience, 41(1), pp.23–50. https: //onlinelibrary.wiley.com/doi/pdf/10.1002/spe.995, Available from: https://doi.org/https: //doi.org/10.1002/spe.995. [6] D’Angelo, G., Ferretti, S. and Ghini, V., 2016. Simulation of the internet of things. 2016 international conference on high performance computing & simulation (hpcs). pp.1–8. Available from: https://doi.org/10.1109/HPCSim.2016.7568309. [7] D’Angelo, G., Ferretti, S. and Ghini, V., 2017. Modeling the internet of things: a simulation perspective. 2017 international conference on high performance computing & simulation (hpcs). pp.18–27. Available from: https://doi.org/10.1109/HPCS.2017.13. [8] Dautov, R., Distefano, S., Bruneo, D., Longo, F., Merlino, G. and Puliafito, A., 2018. Data processing in cyber-physical-social systems through edge computing. Ieee access, 6, pp.29822– 29835. Available from: https://doi.org/10.1109/ACCESS.2018.2839915. [9] Esteves, L.T.C., Oliveira, W.L.A.d. and Farias, P.C.M.d.A., 2024. Analysis and construction of hardware accelerators for calculating the shortest path in real-time robot route planning. Electronics, 13(11). Available from: https://doi.org/10.3390/electronics13112167. [10] Fahimullah, M., Philippe, G., Ahvar, S. and Trocan, M., 2023. Simulation tools for fog computing: A comparative analysis. Sensors, 23(7). Available from: https://doi.org/10.3390/s23073492. [11] Fernandez, I., Castillo, J., Pedraza, C., Sanchez, C. and Martinez, J.I., 2008. Parallel implementation of the shortest path algorithm on fpga. 2008 4th southern conference on programmable logic. pp.245–248. Available from: https://doi.org/10.1109/SPL.2008.4547768. [12] Gupta, H., Vahid Dastjerdi, A., Ghosh, S.K. and Buyya, R., 2017. iFogSim: A toolkit for
17
,
modeling and simulation of IoT, edge and fog computing environments — source code repository. https://github.com/Cloudslab/iFogSim. Accessed: March 2026. [13] Gupta, H., Vahid Dastjerdi, A., Ghosh, S.K. and Buyya, R., 2017. ifogsim: A toolkit for modeling and simulation of resource management techniques in the internet of things, edge and fog computing environments. Software: Practice and experience, 47(9), pp.1275–1296. https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.2509, Available from: https://doi.org/ https://doi.org/10.1002/spe.2509. [14] Lei, G., Dou, Y., Li, R. and Xia, F., 2016. An fpga implementation for solving the large singlesource-shortest-path problem. Ieee transactions on circuits and systems ii: Express briefs, 63(5), pp.473–477. Available from: https://doi.org/10.1109/TCSII.2015.2505998. [15] Lera, I., Guerrero, C. and Juiz, C., 2019. Yafs: A simulator for iot scenarios in fog computing. Ieee access, 7, pp.91745–91758. Available from: https://doi.org/10.1109/ACCESS.2019.2927895. [16] Mahmud, R., Pallewatta, S., Goudarzi, M. and Buyya, R., 2022. ifogsim2: An extended ifogsim simulator for mobility, clustering, and microservice management in edge and fog computing environments. Journal of systems and software, 190, p.111351. Available from: https://doi.org/https://doi.org/10.1016/j.jss.2022.111351. [17] Matange, A. and Abraham, J., 2026. ifogsumo: An integrated platform of ifogsim and sumo to enhance simulation capabilities of adaptive traffic control for smart city applications. International journal of online and biomedical engineering (ijoe), 22(02), Feb., p.pp. 38–54. Available from: https://doi.org/10.3991/ijoe.v22i02.58823. [18] Mechalikh, C., Taktak, H. and Moussa, F., 2019. Pureedgesim: A simulation toolkit for performance evaluation of cloud, fog, and pure edge computing environments. 2019 international conference on high performance computing & simulation (hpcs). pp.700–707. Available from: https://doi.org/10.1109/HPCS48598.2019.9188059. [19] Meneghello, F., Calore, M., Zucchetto, D., Polese, M. and Zanella, A., 2019. Iot: Internet of threats? a survey of practical security vulnerabilities in real iot devices. Ieee internet of things journal, 6(5), pp.8182–8201. Available from: https://doi.org/10.1109/JIOT.2019.2935189. [20] Nawir, M., Amir, A., Yaakob, N. and Lynn, O.B., 2016. Internet of things (iot): Taxonomy of security attacks. 2016 3rd international conference on electronic design (iced). pp.321–326. Available from: https://doi.org/10.1109/ICED.2016.7804660. [21] Nemati, A.M. and Mansouri, N., 2025. Resource allocation in fog computing: a survey on current state and research challenges. Knowl. inf. syst., 67(3), pp.2091–2170. Available from: https://doi.org/10.1007/S10115-024-02274-5. [22] NS-3 Consortium, 2026. NS-3: A discrete-event network simulator for internet systems. https://www.nsnam.org. Accessed: March 2026. [23] Qayyum, T., Malik, A.W., Khan Khattak, M.A., Khalid, O. and Khan, S.U., 2018. Fognetsim++: A toolkit for modeling and simulation of distributed fog environment. Ieee access, 6, pp.63570– 63583. Available from: https://doi.org/10.1109/ACCESS.2018.2877696. [24] Rejeb, A., Rejeb, K., Treiblmaier, H., Appolloni, A., Alghamdi, S., Alhasawi, Y. and Iranmanesh, M., 2023. The internet of things (iot) in healthcare: Taking stock and moving forward. Internet of things, 22, p.100721. Available from: https://doi.org/https://doi.org/10.1016/j.iot.2023. 100721. [25] Sonmez, C., Ozgovde, A. and Ersoy, C., 2018. Edgecloudsim: An environment for performance evaluation of edge computing systems. Transactions on emerging telecommunications technologies, 29(11), p.e3493. E3493 ett.3493. https://onlinelibrary.wiley.com/doi/pdf/10.1002/ett.3493, Available from: https://doi.org/https://doi.org/10.1002/ett.3493. [26] Soori, M., Arezoo, B. and Dastres, R., 2023. Internet of things for smart factories in industry 4.0, a review. Internet of things and cyber-physical systems, 3, pp.192–204. Available from: https://doi.org/https://doi.org/10.1016/j.iotcps.2023.04.006. [27] Wiesner, P. and Thamsen, L., 2021. Leaf: Simulating large energy-aware fog computing environments. 2021 ieee 5th international conference on fog and edge computing (icfec). pp.29– 36. Available from: https://doi.org/10.1109/ICFEC51620.2021.00012.
18