Performance Benchmarking of IoT Edge Computing Versus Cloud Computing: A Controlled Simulation-Based Study Using Node-RED and the Intel Berkeley Sensor Dataset

The performance trade-offs between edge and cloud computing in IoT environments have attracted substantial research attention. This section organizes existing literature into four thematic clusters: (i) foundational frameworks; (ii) empirical benchmarking; (iii) simulation frameworks and reproducibility; and (iv) hybrid and emerging architectures. Table 1 provides a consolidated critical summary of all reviewed works, including their focus area, method, key finding, and primary limitation.

Table 1. Critical summary of related work on edge vs. cloud computing in Internet of Things (IoT)

Note: IoT = Internet of Things, MEC = mobile edge computing, QoS = Quality-of-Service, CV = coefficient of variation.

2.1 Foundational frameworks and conceptual models

The theoretical grounding for edge computing in IoT was established by Shi et al. [2], who articulated latency reduction, bandwidth conservation, and distributed intelligence as defining characteristics of the edge computing paradigm. While seminal, this work provides no experimental validation of the latency gains it posits. The National Institute of Standards and Technology (NIST) cloud computing reference model [15] remains the canonical baseline against which edge architectures are evaluated. Abbas et al. [4] extended this foundation to Mobile Edge Computing (MEC), demonstrating through analytical modeling that edge node deployment reduces backhaul traffic and improves real-time QoS, though under idealized network conditions without statistical variability analysis. Deng et al. [6] researched efficient workload distribution for fog-cloud systems, finding equalized task loads lower latency and energy needs, though the study preceded MQTT connectivity for sensors. Andriulo et al. [8] concluded that neither edge nor cloud computing constitutes a universally optimal solution, as the suitability of each architecture is fundamentally determined by the specific operational context, application requirements, and infrastructure constraints of the deployment environment.

2.2 Empirical and experimental benchmarking

Zhang et al. [7] conducted the most directly comparable empirical investigation, benchmarking edge and cloud for IoT-based machinery vibration monitoring on physical hardware. Their findings confirm edge superiority for latency-sensitive workloads, consistent with the present study, but the physical testbed methodology introduces hardware-specific confounders that constrain reproducibility and generalizability, and no statistical dispersion analysis is reported. Mahmud et al. [9] examined cloud-fog interoperability in healthcare IoT, demonstrating that fog and edge layers improve QoS for time-critical medical streams, but the study lacks empirical latency benchmarks from controlled experiments. Shukla et al. [16] confirmed through a systematic literature review that latency is the most consistently reported bottleneck in cloud-centric IoT and that edge offloading is the most effective mitigation — but throughput, jitter, and packet loss are treated peripherally. Ahmed [17] reported empirical packet loss measurements in medical IoT edge deployments, consistent with the present study's packet loss differentials, but jitter is not measured, and no CV analysis is performed.

2.3 Simulation frameworks and reproducibility

Almutairi et al. [12] identified the lack of standardized benchmarking protocols and inconsistent handling of jitter and packet loss as the most significant deficiencies shared across existing IoT simulators. Bendaouch et al. [11] validated Node-RED's suitability for edge-fog-cloud simulation, directly justifying the platform selection of the present study. Critically, their analysis identifies Node-RED's hardware-agnostic, flow-based architecture as a significant advantage for experimental reproducibility — a property physical testbed studies cannot offer. However, Bendaouch et al. [11] do not conduct multi-metric statistical analysis across all four QoS dimensions simultaneously. Saha et al. [18] demonstrated that MQTT protocol behavior introduces measurable QoS variability independent of network architecture; the present study addresses this confounder by maintaining a fixed Eclipse Mosquitto configuration across all scenarios.

2.4 Hybrid and emerging architectural approaches

Walker [19] recommended hybrid deployment — edge for latency-sensitive processing, cloud for scalable analytics — aligning with the conclusions of the present study, though without statistical validation or empirical QoS measurements. Pal et al. [20] provided empirical grounding for hybrid architectures, demonstrating improved response time through dynamic workload distribution, though without dispersion analysis or jitter measurement. Yu et al. [21] proposed DRL-based adaptive offloading in Industrial IoT, yielding superior latency and energy efficiency over static partitioning, but without reporting jitter or packet loss. Maleki et al. [22] confirmed that jitter remains a persistent challenge even in 5G-enabled edge environments, reinforcing its inclusion as a primary evaluation metric in the present study. Mrabet and Sliti [23] extended the discussion to security, trustworthiness, and sustainability in smart city edge deployments, while Ghaseminya et al. [24] examined FaaS integration with edge and fog layers for scalable IoT management.

2.5 Positioning of the present study

A systematic examination of the literature reveals three recurring methodological deficiencies: (i) predominant reliance on physical testbeds introducing hardware-specific confounders; (ii) absence of statistical rigor — most studies report single-run measurements without variance analysis; and (iii) consistently incomplete QoS evaluation, most frequently isolating latency while omitting jitter, packet loss, and CV. The present study addresses all three deficiencies through controlled, multi-metric, statistically validated simulation. Table 2 provides a direct methodological comparison between the present study and the six most relevant prior works, confirming the novelty of the combined four-point methodological approach.

Table 2. Methodological positioning of the present study

Note: QoS = Quality-of-Service, CV = coefficient of variation, CI = confidence interval.

4.1 Simulation platform selection

The simulation environment was selected following a systematic evaluation of candidate platforms including VMware-based virtual networks, COOJA, GNS3, and Node-RED. A VM-based approach using Oracle VirtualBox was not adopted: dual Ubuntu VMs competing for 8 GB of host RAM produced scheduling artifacts and resource contention that confounded measurements, violating the requirement for measurement isolation.

Node-RED was selected on four scientifically grounded criteria: (i) lightweight single-host execution without hardware virtualization, eliminating resource-contention confounders; (ii) native MQTT support enabling realistic publish-subscribe IoT data flows consistent with the OASIS MQTT v5.0 specification [28]; (iii) seeded stochastic delay generation enabling reproducible experimental runs; and (iv) empirical validation of suitability for edge-fog-cloud benchmarking by Bendaouch et al. [11].

It is acknowledged that both architectures execute on the same physical host, precluding true geographical separation. This is a deliberate and transparent methodological choice consistent with established practice in simulation-based IoT benchmarking [11, 12]. Architectural differences are modeled through empirically derived network delay distributions rather than hardware separation, as detailed in Section 4.3.

4.2 Hardware and execution environment

Tests were run upon a system having Intel Core i7 hardware plus 16 GB random access memory plus solid-state drive storage using Ubuntu 22.04 LTS 64 bit edition. Researchers built simulations within Node-RED v3.x atop Node.js v18.x long-term support releases. Eclipse Mosquitto v2.x acted like our MQTT broker residing on localhost port 1883. Zero background tasks occupied processing resources while performing runs. Providing such hardware specifications supports reproduction efforts plus helps analysts understand timing findings reached during each observation.

4.3 Dataset selection and traffic generation

Addressing a key limitation of prior synthetic-dataset studies [7, 9, 10], the present simulation employs the Intel Berkeley Laboratory Wireless Sensor Network Dataset [13] as the source of IoT message payloads. This publicly available dataset comprises approximately 2.3 million sensor readings from 54 Mica2Dot sensors recording temperature, humidity, light intensity, and voltage at 31-second intervals over 36 days — well-established in IoT simulation for its realistic sensor value distributions, natural missing-data patterns, sensor drift, and temporal correlation.

A total of 50,000 records were uniformly sampled from the dataset to maintain proportional representation across all 54 sensor nodes and four measurement types. Each message transmitted through Node-RED was structured as a JSON object preserving the original Berkeley Laboratory fields — timestamp, moteid, temperature, humidity, light intensity, and voltage — supplemented by simulation metadata including device identifier, run index, and injection timestamp. Messages were injected at a rate of 10 messages per second, faithfully reproducing the temporal characteristics of the original sensor log.

4.4 Network delay modelling

A fundamental redesign of the network delay model was implemented to address the concern that pre-specified asymmetric delay ranges could predetermine experimental outcomes. Both edge Local Area Network (LAN) and cloud WAN delays are modeled using lognormal distributions, which have been empirically demonstrated to accurately characterize real-world network RTT behavior [14], capturing the right-skewed nature of RTT measurements that uniform distributions cannot represent. Table 4 presents the empirically derived delay parameters used in this study, calibrated from published network measurement literature rather than specified by the experimenters.

Table 4. Empirically derived network delay parameters

Note: Both distributions use lognormal models (LAN: μ = 3.58, σ = 0.45; WAN: μ = 4.61, σ = 0.55), reflecting empirically observed right-skewed RTT distributions. Parameters derived from published network measurement literature [28].

Table 5. Revised simulation configuration parameters

Jitter is derived as the standard deviation of the lognormal delay distribution, ensuring internal consistency with the latency model. Packet loss rates were derived from ITU-T G.1010 [26] baseline figures for LAN (0.1%) and WAN (1.0%) environments — substantially more conservative than rates used in prior studies — reducing the risk that loss differentials are artificially amplified. Table 5 presents the complete simulation configuration parameters used across all experimental runs.

4.5 Architecture models

Edge Computing Model: Berkeley dataset records injected at 10 Hz, transmitted via Eclipse Mosquitto broker, subjected to lognormal LAN delay (mean ~40 ms, P95 ~80 ms). Path: Sensor → LAN → Local Edge Node → Processing → Response. Cloud Computing Model: Identical Berkeley dataset records routed through lognormal WAN delay (mean ~120 ms, P95 ~220 ms). Path: Sensor → WAN → Remote Cloud Server → Processing → Response. The primary experimental variable is solely the empirically derived network delay distribution. Figure 1 presents the complete experimental workflow diagram illustrating the full pipeline from dataset ingestion through both architecture paths to the statistical analysis output stage.

tu_pian_1.png

Figure 1. Experimental workflow: from dataset to statistical output

4.6 Repeated experimentation and statistical framework

Thirty independent experimental runs were executed for each architecture and each metric — 30 runs following established practice for computer systems performance evaluation [29] and enabling parametric CI construction under the Central Limit Theorem. Each run was assigned a fixed seed: seed = run_index × 42, ensuring full reproducibility and non-overlapping pseudo-random sequences.

Table 6 defines the complete statistical analysis framework applied to the results of all 30 runs per architecture per metric.

Table 6. Statistical analysis framework

4.7 Measurement validity and threat mitigation

Threat 1 — Predetermined outcomes: Mitigated by replacing experimenter-specified asymmetric delay ranges with empirically derived lognormal distributions calibrated to published network measurement data [14].

Threat 2 — Synthetic dataset bias: Mitigated by replacing artificial sensor values with the Intel Berkeley Laboratory real sensor dataset [13], introducing empirically realistic payload characteristics.

Threat 3 — Single-machine execution: Acknowledged as a controlled methodological choice consistent with established simulation practice [11, 12]. Mitigated by transparent reporting of this limitation in Section 6.5 and by empirically derived lognormal delay parameters calibrated from published physical network measurement data [14], providing grounding absent in purely synthetic simulation studies.

Threat 4 — Limited statistical replication: Mitigated by executing 30 independent experimental runs per architecture per metric, each assigned a fixed random seed to ensure full reproducibility. Statistical rigor is ensured through 95% CI construction, Welch's t-test significance testing, and inter-run variance reporting across all four QoS metrics.

Justification of Welch's t-test: Per-run mean latency and jitter values are computed as means of 50,000 lognormally distributed samples per run. By the Central Limit Theorem, these per-run means are approximately normally distributed for n = 50,000, satisfying the normality assumption required for parametric testing. Welch's t-test was chosen over Student's t-test because it does not assume equal variance between edge and cloud distributions — appropriate given the substantially different lognormal parameters (LAN: μ = 3.58, σ = 0.45 vs. WAN: μ = 4.61, σ = 0.55). For packet loss, the normal approximation to the binomial holds robustly at n = 50,000 (np >> 5 satisfied in all cases). With n = 30 independent runs per architecture, the large-sample approximation holds, following Jain [29].

4.8 Sensitivity analysis of delay parameters

To address the concern that the selected delay parameters may predetermine experimental outcomes, Table 7 presents a systematic sensitivity analysis showing the latency improvement factor under six parameter perturbation scenarios. The results confirm that the directional conclusion — edge computing achieves lower latency than cloud computing under the simulated conditions — holds across all tested perturbations. Even in the most conservative scenario (edge delay increased by 20%, cloud delay reduced by 20%), the improvement factor remains 2.02×, confirming robustness to parameter uncertainty.

Table 7. Sensitivity analysis: latency improvement factor under parameter perturbations

Note: Both distributions use lognormal models (LAN: μ = 3.58, σ = 0.45; WAN: μ = 4.61, σ = 0.55), reflecting empirically observed right-skewed RTT distributions. Parameters derived from published network measurement literature [28].

6.1 Interpretation of results and statistical robustness

All four QoS metrics demonstrate statistically significant differences between edge and cloud architectures (p < 0.001, Welch's t-test), with non-overlapping 95% CI confirming genuine architectural separation across all 30 independent runs. The extremely low CV values for latency (edge: 0.17%; cloud: 0.22%) and jitter (edge: 0.54%; cloud: 0.60%) indicate that the grand mean values are exceptionally stable and reproducible — a direct consequence of the 30-run repeated experimentation protocol and empirically grounded lognormal delay modeling. Figure 10 provides a unified all-metrics performance summary comparing edge and cloud grand means with 95% CI.

tu_pian_10.png

Figure 10. All-metrics performance summary: edge vs. cloud (grand means ±95% Confidence Interval (CI))

The most impactful finding from a system design perspective is the near-order-of-magnitude packet loss differential (IF = 9.90×): edge computing loses 0.101% versus 1.002% for cloud. In a continuous IoT monitoring deployment transmitting at 10 messages/second over a 24-hour period (864,000 messages), this differential implies approximately 8,640 lost messages for cloud versus approximately 864 for edge — a difference of nearly 7,800 unrecoverable sensor events per day under QoS 0, with direct implications for data completeness, regulatory compliance in healthcare monitoring, and safety-critical industrial control.

The 2.94× latency improvement factor carries direct practical significance for IoT system design. Edge mean latency of 39.69 ms satisfies the ITU-T G.1010 interactive application threshold of 100 ms [26], while the cloud mean of 116.87 ms exceeds it. Critically, the edge P95 latency of 75.17 ms confirms that 95% of all transmitted messages complete within the real-time threshold, demonstrating stable sub-100 ms performance across the full range of simulated lognormal delay conditions. In contrast, the cloud P95 latency of 248.19 ms implies that approximately 2,500 out of every 50,000 messages — 5% of total transmissions — exceed this threshold, rendering cloud-exclusive architectures unsuitable for closed-loop control systems where latency deadline violations directly compromise operational integrity.

The jitter improvement factor of 3.57× (mean) and 3.73× (P95) is particularly consequential for streaming and control applications. Cloud P95 jitter of 201.82 ms implies that 5% of consecutive packet pairs exhibit inter-arrival timing differences exceeding 200 ms — a level that would cause visible artifacts in real-time video, audible distortion in voice over IP, and control loop instability in industrial automation. Edge P95 jitter of 54.17 ms, while not trivial, is well within the tolerances of most real-time IoT applications.

The throughput result (IF = 1.01×) deserves explicit discussion to prevent misinterpretation. The negligible throughput differential reflects the design of the experiment: fixed injection rate, fixed payload size, and a wall-clock-time denominator that equalizes both architectures. The 0.014 KB/s throughput advantage of edge over cloud is entirely attributable to the 10× packet loss differential. This is not a finding that edge and cloud computing offer equal bandwidth — in real deployments, WAN bandwidth is considerably more constrained than LAN bandwidth. Rather, it demonstrates that under the controlled conditions of this study, packet loss is the dominant driver of throughput differential, and that the lognormal latency model does not itself directly reduce delivered throughput when injection rate is held constant.

6.2 Comparison with prior literature

The latency improvement factor of 2.94× reported in this study is somewhat lower than the 3.5× figure reported by Zhang et al. [7] on physical hardware for machinery vibration monitoring. This difference is expected and methodologically appropriate: physical testbed studies reflect specific hardware configurations and ambient network conditions, while the present study's lognormal delay model is calibrated to representative published network measurements [14] and intentionally avoids artificially large delay differentials. The conservative design of the present study — using ITU-T G.1010 packet loss baselines rather than experimenter-specified rates, and lognormal rather than uniform delay distributions — means that the reported improvement factors represent architecturally conservative lower bounds on the true performance differential between well-maintained LAN and WAN deployments.

The packet loss improvement factor of 9.90× is consistent with Ahmed [17], who reported substantial packet loss reductions in medical IoT edge deployments, and aligns with the 10:1 ITU-T G.1010 ratio between WAN and LAN baseline packet loss rates on which the simulation parameters are grounded. This cross-validation through independent empirical evidence and standards-body benchmarks strengthens confidence in the ecological validity of the simulation findings.

6.3 Hybrid architecture recommendation

Based on the experimental evidence, we propose a three-tier hybrid architecture as a candidate deployment pattern for modern IoT systems. Current QoS performance drives these design decisions but necessitates thorough field tests, hardware deployments, workload profiling, and stress checks prior to final system production approval.

1. Tier 1: Edge Layer executes incoming streams, runs pre-analysis, identifies outliers, plus manages urgent actions. These operations follow ITU-T G.1010 [26] protocols, keeping latency below 100 ms, processing most raw data locally, while sending summarized info toward core systems.
2. Tier 2: Fog Layer collects grouped edge outputs across districts, simplifying local intelligence without excessive reliance on distant network connections.
3. Tier 3: Cloud Layer provides expansive storage, training cycles, batch reporting, plus corporate strategy guidance. Received traffic includes narrowed data chunks, lightening backbone bandwidth pressure, allowing infrastructure performance during less time-sensitive background computing chores effectively for improved network-wide efficiency throughout enterprise global setups everywhere today.

This three-tier model is motivated by the demonstrated QoS differentials: edge's 2.94× latency advantage, 3.57× jitter advantage, and 9.90× packet loss advantage indicate consistently superior performance under the simulated LAN conditions for the real-time processing tier, while cloud infrastructure's scalability and storage capacity complement edge processing for the analytics tier.

6.4 Application domain implications

Smart Healthcare: Wearable ECG/SpO₂ anomaly detection requires sub-100 ms response times. Edge mean latency of 39.69 ms satisfies this; cloud mean of 116.87 ms does not. The 9.90× packet loss reduction translates to approximately 7,800 fewer lost sensor events per day in a continuous monitoring session, with direct implications for patient safety and regulatory compliance.

Industrial Automation: Edge P95 latency of 75.17 ms and P95 jitter of 54.17 ms are consistent with soft real-time monitoring requirements. Cloud P95 jitter of 201.82 ms is inconsistent with any real-time industrial monitoring application. Fast response loops below ten milliseconds need specialized Ethernet protocols like EtherCAT or PROFINET across any computing setup. Urban management functions, such as signal adjustment plus pedestrian observation, perform best with edge computing while removing internet connection delay plus data variability. The 9.90× packet loss reduction preserves data continuity for sensor fusion applications where missing data points degrade algorithm performance.

Autonomous Vehicles (V2X): Cloud mean latency of 116.87 ms and P95 of 248.19 ms categorically exclude cloud-based V2X from collision avoidance applications requiring sub-10 ms end-to-end latency. Edge nodes co-located with roadside units remain essential, with cloud infrastructure limited to non-safety-critical analytics and map updates.

6.5 Limitations and threats to external validity

Single-machine simulation: Both architectures execute on the same host. Real-world WAN measurements exhibit BGP routing changes, CDN effects, and ISP throttling not captured in the lognormal model. However, the lognormal parameters are calibrated from published physical measurement data [14], providing empirical grounding absent in purely synthetic simulation studies.

Fixed injection rate: The 10 messages/second injection rate reflects dense IoT deployments but does not model burst traffic or variable-rate sensors. Throughput results are specific to this injection model.

Security overhead not evaluated: TLS 1.3 encryption and certificate-based authentication introduce latency overhead not captured in QoS 0 measurements. Future work should quantify the security-performance trade-off for each architecture.

Single broker configuration: Results reflect Eclipse Mosquitto v2.x configured on localhost. Alternative configurations for brokers like AWS IoT Core or Azure IoT Hub plus clustered setups affect QoS results; scholars must assess these options in later research.