PaperlayerView exact revision on arXiv

Source-linked AI summary

A Deployment-Aware Feasibility Framework for Machine Learning-Based IoT Intrusion Detection Across Edge, Fog, and Cloud Architectures

Shaker Nawasra, Munther Abualkibash

arXiv:2610.08867v1cs.CR

TL;DR

IoT device heterogeneity makes a single security system difficult, while ML intrusion-detection studies often omit deployment constraints. The paper grounds feasibility scoring in representative capability envelopes and finds lightweight models best suited to edge, ensembles to fog/gateway, and deep models to cloud.

  • Problem

    IoT devices vary in operating systems, computing power, and functions, and existing ML-based IDS research lacks a unified framework combining detection effectiveness with deployment feasibility.

    Source: §I · p. 1

  • Method

    The paper evaluates IDS deployment suitability across edge, fog/gateway, and cloud using representative capability envelopes and a normalized DFS based on compute, memory, and latency demands.

    Source: C. Cloud Layer · p. 3, A. Resource Normalization and Ordinal… · p. 3, §VII · p. 8

  • Results

    Lightweight statistical and linear models are best suited to edge, ensemble methods to fog/gateway, and deep learning models to cloud infrastructures.

    Source: §VII · p. 8

  • Takeaways & Limitations

    The DFS provides a reproducible, architecture-aware methodology for considering deployment practicality in real-world IoT security system design.

    Source: §VII · p. 8

    The reported empirical deployment performance is evaluated on a Raspberry Pi 3 Model B+ edge gateway.

    Source: §VI · p. 8

Abstract

from arXiv · show

The rapid growth and heterogeneity of Internet of Things (IoT) environments have exposed fundamental limitations in traditional rule-based and signature-based intrusion detection systems. This paper presents a quantitative deployment-aware analysis of machine learning (ML)-based intrusion detection approaches across edge, fog/gateway, and cloud architectures. Unlike prior surveys that primarily emphasize detection accuracy, this work defines representative quantitative deployment capability envelopes extracted from experimental and system-level studies and introduces a structured Deployment Feasibility Score (DFS) model. The proposed framework maps ML techniques to architectural layers based on computational demand, memory footprint, and latency sensitivity using a weighted ordinal scoring mechanism. The analysis demonstrates that lightweight statistical and linear models are most suitable for edge deployment, ensemble and clustering-based methods align with fog/gateway environments, while deep and optimization-driven models are best suited for cloud infrastructures. By formalizing deployment feasibility through quantitative grounding and structured evaluation, this work provides practical guidance for selecting intrusion detection solutions under real-world architectural constraints, supporting more informed and deployment-conscious IoT security design.

I. INTRODUCTION

IoT heterogeneity and resource constraints complicate security across devices, while existing ML intrusion-detection research lacks a unified assessment of detection effectiveness and deployment feasibility. The paper grounds its deployment analysis in representative capability envelopes for edge, fog/gateway, and cloud layers.

I. INTRODUCTION

  • Constrained hardware, simplified software, and rapid deployment leave IoT devices vulnerable, while variation in operating systems, computing power, and functions complicates a single security system.IoT devices also operate with limited compute, memory, and energy and may connect using default or preconfigured settings.Source: §I · p. 1
  • Connected IoT devices grew from approximately 15.41 billion in 2015 to nearly 75.44 billion by 2025.The paper presents this increase as evidence of the scale and acceleration of IoT adoption.Source: §I · p. 2

II. LIMITATIONS OF EXISTING ML-BASED IDS IN IOT ENVIRONMENTS

  • Prior ML-based IDS research often emphasizes detection accuracy while omitting resource use, inference latency, and architectural suitability, leaving no unified framework for deployment feasibility.IoT devices can also serve as network entry points, and communication channels may be vulnerable to interception, spoofing, and manipulation.Source: §II · p. 2

III. DEPLOYMENT CRITERIA AND ARCHITECTURE LAYERS

  • The study defines quantitative capability envelopes for edge, fog/gateway, and cloud from hardware specifications, experimental platforms, and system-level modeling reported in the literature.These ranges characterize relative constraint dominance, not universal hardware guarantees.Source: §III · p. 2

A. Edge Layer (IoT Devices)

The three architecture layers offer different resource and latency profiles: edge is highly constrained, fog/gateway provides intermediate capacity, and cloud supports intensive computation with greater communication-latency and connectivity dependence.

A. Edge Layer (IoT Devices)

  • Strong computational and memory scarcity, energy limits, and ultra-low-latency requirements make lightweight models preferable for edge deployment.Representative edge platforms include embedded devices and AI-enabled systems, but remain more constrained than centralized cloud infrastructure.Source: A. Edge Layer (IoT Devices) · p. 2

B. Fog / Gateway Layer

  • Fog environments offer moderate compute and memory while supporting moderately complex models beyond individual IoT-device capacity.Representative gateways combine multi-core CPUs and 1–16 GB RAM with varied network links and low-latency processing.Source: B. Fog / Gateway Layer · p. 2

C. Cloud Layer

  • Cloud platforms have minimal computational constraints but add communication latency and network dependence, making deep learning and optimization-driven models most suitable there.The representative capability ranges describe typical platforms, not universal hardware specifications.Source: C. Cloud Layer · p. 3

IV. DEPLOYMENT FEASIBILITY SCORING MODEL

The DFS formalizes model suitability across deployment layers using computational, memory, and latency demands. It normalizes those demands against target-platform capabilities and maps them to ordinal scores.

IV. DEPLOYMENT FEASIBILITY SCORING MODEL

  • The DFS is a lightweight ordinal scoring mechanism for evaluating ML-based IDS suitability across edge, fog/gateway, and cloud environments.It aligns model resource requirements with deployment-layer constraints.Source: §IV · p. 3

A. Resource Normalization and Ordinal Scoring

  • Computational demand, memory footprint, and inference-latency sensitivity are normalized against target-platform capability limits and mapped to a five-level ordinal scale.The defined indicators include model inference operations, runtime memory consumption, and measured inference latency.Source: A. Resource Normalization and Ordinal… · p. 3
  • The normalized ratios represent fractions of available compute, memory, and latency budget consumed by one inference; values near unity indicate near-saturation.Concurrent operating-system, networking, and sensing workloads may cause resource contention, increased response latency, or reduced stability, potentially requiring optimization or migration to fog or cloud.Source: A. Resource Normalization and Ordinal… · p. 3
  • The ceiling operator rounds fractional normalized values upward to avoid underestimating model resource demand.This is intended to conservatively reflect computational demand.Source: A. Resource Normalization and Ordinal… · p. 3

B. Deployment Feasibility Score Formulation

The DFS combines computational demand, memory footprint, and latency sensitivity using layer-specific weights, with ordinal scoring and conservative normalization to compare deployment feasibility. Its linear weighted form is intended to make comparisons transparent and consistent across heterogeneous platforms.

B. Deployment Feasibility Score Formulation

  • A scaling factor of 5 and upward ceiling round normalized resource use conservatively, while a minimum operator bounds scores to the defined ordinal range.The scaling maps normalized utilization to the five-level scale and avoids assigning a lower demand level once usage exceeds its lower bound.Source: B. Deployment Feasibility Score… · p. 3
  • DFS combines computational demand, memory footprint, and latency sensitivity using layer-specific weights whose sum is one.The component weights represent the relative importance of those constraints across deployment layers.Source: B. Deployment Feasibility Score… · p. 4
  • The linear weighted formulation is chosen for interpretability and transparency, enabling straightforward model comparisons with computational simplicity.The normalization strategy is described as supporting consistent, reproducible, platform-aware evaluation across edge, fog, and cloud environments.Source: B. Deployment Feasibility Score… · pp. 3–4
  • The three components use a 1–5 ordinal scale for increasing resource demand, with model families assigned scores according to their resource requirements.Linear and probabilistic classifiers receive lower computational-demand scores, while deep, recurrent, and optimization-driven approaches receive higher scores; memory and latency are scored similarly by demand and deployment setting.Source: B. Deployment Feasibility Score… · p. 4

C. Layer-Specific Weight Selection

Layer-specific weights reflect which resource constraints dominate typical edge, fog, and cloud deployments. The selected weights are policy-driven rather than empirically optimized.

C. Layer-Specific Weight Selection

  • At the edge, computational and memory scarcity dominate feasibility, while latency is strict but comparatively uniform across deployed models.These layer-specific constraints motivate different weight assignments across architectures.Source: C. Layer-Specific Weight Selection · p. 4
  • Fog environments balance computational availability with latency sensitivity because they support aggregation and intermediate analytics.Fog nodes occupy a near-real-time role between edge devices and cloud infrastructure.Source: C. Layer-Specific Weight Selection · p. 4
  • Cloud platforms offer elastic compute and memory, so latency and architectural placement dominate deployment considerations.Across layers, weights reflect the relative constraint dominance associated with typical resource limitations.Source: C. Layer-Specific Weight Selection · pp. 4–5
  • The layer weights are policy-driven choices based on typical resource limitations, not values derived through empirical optimization.They encode the relative importance assigned to computational, memory, and latency constraints at each layer.Source: C. Layer-Specific Weight Selection · p. 5

D. Feasibility Classification

The resulting DFS is translated into qualitative feasibility categories, with lower DFS values indicating stronger suitability within the evaluated layer.

D. Feasibility Classification

E. Example Application

The example applies DFS to representative intrusion-detection model families using illustrative ordinal demand scores. It shows moderate edge feasibility for Random Forest and lower edge feasibility for CNNs, with CNN feasibility improving slightly in cloud environments.

E. Example Application

  • Random Forest receives DFS 3.0 under edge-layer weights, corresponding to moderate edge feasibility.The example uses representative ordinal scores rather than measurements for a specific deployment.Source: E. Example Application · p. 5, Table IV · p. 5
  • CNNs show lower edge feasibility because of higher computational and memory requirements, with feasibility improving slightly in cloud environments.Their overall DFS remains relatively high compared with lightweight statistical or tree-based models.Source: E. Example Application · p. 5

F. Sensitivity Analysis

The sensitivity analysis finds that moderate changes to edge-layer weights do not alter the representative models’ relative feasibility ranking. The modeling design uses ordinal scores and a transparent weighted aggregation as a screening mechanism rather than detailed multicriteria optimization.

F. Sensitivity Analysis

  • The sensitivity analysis varies layer-specific weights while preserving wc + wm + wl = 1, including alternative edge configurations.The baseline edge weights are (0.40, 0.35, 0.25), and one alternative is (0.45, 0.30, 0.25).Source: F. Sensitivity Analysis · p. 5
  • Under moderate weight changes, Naïve Bayes remains highly feasible at the edge, Random Forest moderately feasible, and CNN less suitable for resource-constrained environments.The relative ranking remains unchanged despite minor numerical variation in absolute DFS values.Source: F. Sensitivity Analysis · p. 5, Table V · p. 5, Figure 3 · p. 5

G. Formal Justification of the Modeling Design

  • A 1–5 ordinal scale compares models’ relative computational, memory, and latency demands instead of relying on exact hardware measurements.The rationale is that IoT, fog, and cloud hardware varies and evolves, so fixed benchmarks may not apply across platforms.Source: G. Formal Justification of the… · p. 6
  • A linear weighted aggregation combines the factors into an interpretable screening mechanism, not a detailed multicriteria optimization.The formulation is also described as easy to apply and adaptable through policy-driven weights.Source: G. Formal Justification of the… · p. 6

H. Comparison With Existing Surveys and Positioning of This Work

Prior surveys cover IoT IDS methods and operational concerns, but the paper identifies a lack of unified quantitative evaluation of deployment feasibility across architectural layers. Its DFS-based analysis relates model demands to layer constraints and finds that suitability can vary by architecture even when detection performance is similar.

H. Comparison With Existing Surveys and Positioning of This Work

  • Prior IoT IDS surveys review techniques, datasets, attacks, metrics, and operational concerns, but primarily assess approaches from detection-centric perspectives.Examples include reviews of IoT IDS strategies, ML algorithms [10], deep reinforcement learning, broader IoT security, IDS classifications, and operational challenges.Source: H. Comparison With Existing Surveys… · p. 6
  • The paper identifies no unified quantitative method in prior surveys for connecting model resource demands to edge, fog, and cloud constraints.It notes that models with high research-setting accuracy may not suit real-world IoT deployment.Source: H. Comparison With Existing Surveys… · p. 6
  • The proposed lightweight DFS framework complements detection effectiveness with structured, layer-aware feasibility comparisons across edge, fog/gateway, and cloud environments.Table VI is described as summarizing distinctions between prior surveys and the proposed framework.Source: H. Comparison With Existing Surveys… · p. 6

A. DFS-Based Evaluation of Representative IDS Models

  • Model suitability varies across edge, fog/gateway, and cloud contexts even when detection performance is similar.The evaluation incorporates computational complexity, memory requirements, and latency sensitivity within layer-specific constraints.Source: A. DFS-Based Evaluation of… · p. 6

B. Empirical Benchmark Validation Using Published Deployments

Published Raspberry Pi deployment results [8] show a detection-performance and deployment-cost tradeoff across model families, while the observed hardware characteristics align with DFS feasibility trends. The discussion qualifies this alignment: the scoring and evaluation are representative rather than detailed, large-scale empirical benchmarking.

B. Empirical Benchmark Validation Using Published Deployments

  • The prior deployment study evaluated models on a Raspberry Pi 3 Model B+ with the Edge-IIoTset benchmark, assessing accuracy, memory, complexity, and on-device inference [8].The Raspberry Pi platform has a quad-core 1.4 GHz processor and 1 GB RAM.Source: B. Empirical Benchmark Validation… · pp. 6–7
  • Tree-based models offer efficient edge detection, whereas deep models bring higher computational overhead and latency, matching DFS's predicted feasibility trends.The reported hardware characteristics associate low-demand, low-footprint models with stronger edge feasibility and higher-complexity deep models with greater deployment cost.Source: B. Empirical Benchmark Validation… · p. 7

VI. LIMITATIONS AND DISCUSSION

  • The 1–5 ordinal DFS scale supports consistent comparison but does not capture runtime differences across specific hardware platforms or optimization techniques.The approach is intended to avoid false numerical precision.Source: §VI · p. 7
  • Layer weights are policy-driven and representative rather than universal; processor type, acceleration, compression, and distributed inference can affect real-world feasibility.Source: §VI · p. 7
  • The evaluation uses representative ML models rather than large-scale empirical benchmarking, and its goal is framework formalization rather than optimizing accuracy or F1-score.The authors identify controlled runtime measurements as future validation.Source: §VI · p. 7
  • The framework links model resource demands to architectural constraints to support informed decisions across heterogeneous IoT infrastructures.The authors describe it as a reproducible and adaptable feasibility modeling approach.Source: §VI · pp. 7–8

B. Empirical Benchmark Validation Using Published Deployments

VII. CONCLUSION

The paper presents DFS as a deployment-aware way to compare ML-based intrusion detection under architectural constraints. Its results map lightweight statistical and linear models to edge, ensemble methods to fog/gateway, and deep learning to cloud infrastructures.

VII. CONCLUSION

  • Lightweight statistical and linear models best suit resource-limited edge devices, ensemble methods fog/gateway environments, and deep learning cloud infrastructures.Source: §VII · p. 8
  • DFS compares ML models under realistic architectural constraints using a simple, normalized scoring method.Source: §VII · p. 8
  • The framework offers a reproducible, architecture-aware evaluation mechanism connecting detection performance with deployment practicality for IoT security design.Source: §VII · p. 8
Loading 2610.08867v1…