Abstract
The exponential growth of the Internet of Things (IoT) has magnified vulnerability to Distributed Denial-of-Service (DDoS) threats, particularly advanced TCP flooding attacks that exploit protocol weaknesses to disrupt services and overwhelm constrained devices. Existing Software-Defined Networking (SDN) defenses often suffer from scalability bottlenecks, high controller overhead, and limited adaptability to evolving traffic dynamics. To overcome these challenges, this paper proposes APATCP, a P4-enabled, multi-controller SD-IoT framework for real-time adaptive detection and mitigation of TCP flooding. APATCP integrates four coordinated modules: Adaptive Collaborative Intrusion Defense (ACID) for decentralized intelligence sharing; Dynamic Traffic Anomaly Mitigation (DTAM) for adaptive thresholding and flow isolation; Dynamic Threat-Adaptive Classifier (DTAC), which leverages 24 P4-extracted features and an adaptive weighted ensemble classifier for complex multi-type attack classification; and FlowGuard-AP, a context-aware mitigation engine with dynamic response strategies. Evaluation across three IoT-centric datasets—CICIoT2024, Edge-IIoTset, and ToN_IoT—demonstrates superior performance, with APATCP achieving 99.3–99.98% accuracy, 98.2–99.5% recall, F1-scores up to 99.2%, and false positive rates as low as 0.4%. In binary classification, it consistently outperformed baselines such as LightGBM (97.5–97.8%) and XGBoost (96.7–97.1%). In multi-class evaluations spanning eight adversarial scenarios—including burst floods, hybrid multi-vector campaigns, and stealthy microbursts—the framework maintained > 98% accuracy while remaining operationally stable. Live emulations confirmed resilience under > 100k packets/s attack rates, keeping CPU load below 30%, packet loss under 2%, and end-to-end latency below 100 ms, while restoring throughput to over 95% of baseline within seconds. These results establish APATCP as a scalable, adaptive, and resource-efficient framework that delivers high detection accuracy, low overhead, and robust mitigation, ensuring reliable defense for next-generation SD-IoT infrastructures against increasingly sophisticated TCP flooding threats.
Supplementary Information
The online version contains supplementary material available at 10.1038/s41598-026-62233-8.
Keywords: SD-IoT, TCP Flood Detection, Multi-Vector Attacks, Real-Time Mitigation, Feature Extraction, Scalability
Subject terms: Energy science and technology, Engineering, Mathematics and computing
Introduction
The Internet of Things (IoT) represents one of the most significant technological transformations of the modern era, interconnecting billions of heterogeneous devices across healthcare, transportation, manufacturing, energy systems, and smart cities1. By 2030, it is expected that nearly 29 billion devices will be part of this global ecosystem2. While this connectivity offers unprecedented opportunities for automation, data analytics, and innovative services, it also creates an expanded attack surface that exposes critical systems to evolving cyber threats3.
Many IoT devices are resource-constrained, lack embedded security features, and are often deployed in unattended or physically insecure environments4,5. Once compromised, these devices can be co-opted into massive botnets capable of launching disruptive Distributed Denial-of-Service (DDoS) campaigns6,7. Among these, TCP flooding attacks—particularly SYN floods—pose a serious threat by exploiting the TCP three-way handshake, overwhelming servers and network devices with half-open connections8. This not only exhausts bandwidth and memory resources but also prevents legitimate users from accessing services9. In Software-Defined IoT (SD-IoT) networks, such attacks can also overwhelm the Software-Defined Networking (SDN) controller by flooding it with flow setup requests, filling switch tables, and degrading overall system performance10.
The threat landscape has evolved beyond traditional high-rate floods to multi-vector, low-rate stealth attacks11. Examples include Slowloris-style attacks that maintain long-lived connections under detection thresholds, hybrid floods that combine TCP, UDP, or ICMP traffic, and sequential targeting strategies that cycle across different assets12. These advanced tactics render static threshold-based and signature-driven defenses ineffective13. Furthermore, centralized machine learning (ML) models trained on legacy data often struggle to detect emerging attack patterns, leading to high false positives and significant response delays14,15.
Traditional SDN deployments primarily rely on OpenFlow, which provides limited support for fine-grained state tracking and lacks the flexibility to adapt to fast-changing threats16. In contrast, the P4 programming language enables programmable data planes, allowing real-time packet processing, feature extraction, anomaly detection, and immediate mitigation17. When integrated with ML methods such as decision trees, support vector machines (SVMs), and deep learning, P4 enhances detection accuracy by capturing subtle flow-level behaviors, thereby enabling adaptive responses to modern TCP flooding campaigns18,19. To address these challenges, this paper proposes APATCP—a P4-enabled, multi-controller SD-IoT framework designed for the adaptive detection and mitigation of advanced TCP flooding attacks.
Problem statement and motivation
The growth of IoT has transformed industries from healthcare to transportation, but its reliance on lightweight, often insecure devices makes these networks especially vulnerable to distributed denial-of-service (DDoS) attacks. Among them, TCP flooding remains one of the most disruptive, exploiting protocol weaknesses to overwhelm servers, controllers, and programmable switches. Traditional defenses—reliant on static thresholds, centralized control, or limited visibility—are struggling to keep pace with today’s adaptive and stealthy flooding strategies. This mismatch highlights the urgent need for a scalable, intelligent, and resource-aware defense framework.
(i) Key challenges driving this research include:
Inherent IoT Vulnerabilities: Resource-constrained and widely deployed IoT devices lack built-in protections, making them easy entry points for attackers20.
Evolving Attack Tactics: Modern TCP floods go beyond high-rate SYN floods, blending vectors such as ACK, PUSH, Slowloris, and hybrid multi-protocol floods—or hiding as low-rate stealth attacks that evade static thresholds21.
Control-Plane Bottlenecks: Centralized SDN architectures introduce single points of failure. Flooding can overwhelm a controller with connection requests, degrading responsiveness across the entire IoT domain22.
Limitations of Existing Defenses: OpenFlow-based monitoring and pre-trained ML classifiers incur high overhead, adapt poorly to unseen patterns, and often result in false positives or delayed mitigation.
Critical Infrastructure Risks: In contexts such as hospitals, transport systems, and industrial IoT, these shortcomings threaten not just performance but also safety and reliability.
(ii) Motivation: Addressing these gaps requires a decentralized, adaptive, and state-aware defense that combines real-time traffic feature extraction with intelligent, context-aware mitigation—ensuring strong protection against diverse flooding vectors while preserving legitimate IoT services.
Research contribution
This work introduces APATCP, a P4-enabled, multi-controller framework designed to address the shortcomings of existing SDN defenses against advanced TCP flooding in IoT environments. Unlike conventional approaches that rely on centralized controllers, rigid thresholds, or limited state tracking, APATCP combines programmable data-plane monitoring with decentralized intelligence and adaptive mitigation. Its contributions can be summarized as follows:
Decentralized Defense (ACID): A multi-controller architecture that eliminates single points of failure by enabling secure coordination among controllers. Using Secure Communication Channels, Real-Time Alert Channels, and Secure Data Sharing Channels, ACID balances workloads and ensures resilience during large-scale or distributed attacks.
Adaptive Anomaly Detection (DTAM): A P4-based module that applies dynamic thresholding to detect both volumetric floods and stealthy low-rate intrusions. By learning from live traffic baselines, DTAM adapts in real time, reducing false positives while isolating malicious flows without harming legitimate traffic.
State-Aware Classification (DTAC): A classifier built on 24 P4-extracted features spanning packet, flow, temporal, and application layers. It employs an Adaptive Weighted Ensemble Classifier (AWEC) that continuously updates model weights, ensuring accurate recognition of diverse TCP flooding variants.
Context-Aware Mitigation (FlowGuard-AP): A mitigation engine that adapts strategies to attack type and severity. It combines SYN cookies, selective rate limiting, PUSH flag filtering, connection quotas, and deep packet inspection, adjusting responses dynamically to prevent over-blocking or under-mitigation.
End-to-End Integration: Together, these modules create a scalable and resource-efficient framework capable of real-time detection, classification, and mitigation of evolving TCP floods. APATCP achieves high accuracy and low overhead in both emulated testbeds and real-world IoT datasets, establishing a practical path toward resilient IoT infrastructures.
Beneficiaries of this research
The APATCP is designed not only as an academic contribution but also as a practical solution with benefits across multiple domains. The key beneficiaries include:
IoT Network Operators: Gain scalable and low-latency protection for heterogeneous IoT deployments. The multi-controller design eliminates single points of failure, while adaptive detection lowers operational costs and minimizes service disruptions.
Critical Infrastructure Providers: In sectors like healthcare, transportation, and energy, APATCP ensures resilience against both high-volume and stealth floods. For example, in hospitals, it safeguards patient-monitoring systems that require uninterrupted communication to be life-critical.
Cloud and Edge Service Providers: Benefit from early, distributed detection of volumetric and stealth floods. By preventing resource exhaustion, APATCP helps preserve latency guarantees essential to applications such as autonomous vehicles and industrial control systems.
Security Researchers and Developers: The modular, P4-enabled design offers a flexible testbed for experimenting with new detection models and mitigation strategies, fostering innovation and academic collaboration in SDN–IoT security.
End Users and Consumers: Ultimately, APATCP enhances trust in IoT services by ensuring availability and reliability even under active attack. This translates into smoother experiences for smart homes, connected vehicles, and wearable healthcare devices.
The remainder of this paper is structured as follows: Sect. 2 reviews related work on SD-IoT security. Section 3 details the APATCP framework and its operational design. Section 4 presents experimental settings and evaluation criteria. Section 5 presents the results, discussion, and their implications. Section 6 provides a comparative analysis with other methods. Section 7 lists the work limitations. Finally, Sect. 8 concludes with insights and future research directions.
Literature review
The integration of SDN into modern infrastructures has enabled flexible, programmable, and centralized network control. However, this paradigm has also introduced new vulnerabilities, especially susceptibility to DDoS attacks such as TCP SYN flooding. As a result, extensive research has focused on developing effective detection and mitigation techniques. An overview of these contributions is provided in Table 1. Kumar et al.23 investigated a protocol-level vulnerability in Multipath TCP (MPTCP) caused by manipulation of the Data Sequence Signal (DSS). They proposed a Data Sequence Map Skipping technique to detect such attacks. While effective in exposing DSS-based attacks, its applicability is limited since it is tailored specifically to MPTCP. Shah et al.18 addressed the Economic Denial of Sustainability (EDoS) problem by introducing EDOS-TSM, a detection model that uses binomial distribution analysis and TTL-based anomaly detection. This method reduces false negatives in spoofed and single-source attacks, although scalability and controller overhead remain unresolved. Das et al.24 employed a Random Forest (RF) model using OpenFlow port statistics, achieving 98% detection accuracy for SYN floods and enabling localized attack identification. However, its dependence on flow statistics introduces potential latency due to collection overhead.
Table 1.
Overview of detection methodologies for TCP flooding attacks in SDN.
| Ref. | Year | Methodology | Key Contributions | Limitations |
|---|---|---|---|---|
| 37 | 2020 | PCA-SVM framework for SDN controller DDoS protection | Reduced dimensionality and controller overhead with improved detection accuracy | Relies on centralized controller analysis and traditional ML methods |
| 34 | 2021 | Distributed deep-learning anomaly detection using Hadoop, Spark, and GPU acceleration | Scalable big-data anomaly detection with improved DL performance | Focused on distributed log analysis rather than SD-IoT flooding attacks; high computational requirements |
| 18 | 2022 | Binomial distribution and TTL-based anomaly detection (EDOS-TSM) | Low false negatives; efficient in spoof-based and single-source detection; SDN-oriented | Controller performance cost is not considered; future work is suggested to address scalability. |
| 24 | 2022 | OpenFlow port statistics with Random Forest classifier | High accuracy (98%); localized threat identification. | Flow/statistics dependent; may incur delay due to data collection. |
| 25 | 2022 | ML utilizingP4 switches for real-time DDoS detection | High precision in TCP flood identification | Narrow attack type focus; P4 computational demands |
| 26 | 2023 | Proxy-based mechanism + C4.5 decision tree (ML-TFAD) | Dual-layer defense with proxies and ML; early detection; minimal impact on SDN performance. | Increased space complexity on the SDN controller, limited to TCP flooding. |
| 27 | 2023 | ML classifiers (CART, GNB, QDA, k-NN) on emulated SDN (Mininet) | The CART model shows 98% accuracy and fast prediction and training times. | No hyperparameter tuning; limited dataset used in evaluation. |
| 28 | 2023 | Multi-model AI-based attack detection with Ryu controller | Supports real-time detection, integrates hping3 simulations, and supports controller-based deployment. | Model comparisons and evaluation details are not fully elaborated. |
| 29 | 2023 | Multiple ML algorithms (DT, kNN, RF, SVM, etc.) on custom SDN datasets | Real-time IDS applicability; extremely high throughput; strong F1 scores. | Limited to specific attack types; generalization across datasets not tested. |
| 30 | 2023 | Chi-square test for Detection and mitigation of TCP SYN flood attacks in SDN | Early detection and mitigation at the attack’s origin | Focus on TCP SYN floods, possibly limited to specific SDN setups |
| 11 | 2024 | Adaptive Neuro-Fuzzy Inference System (ANFIS) + SDN in Fog | High detection accuracy; real-time applicability; fog + SDN integration. | Binary classification only; needs testing on multi-class and broader scenarios. |
| 31 | 2024 | Traffic classification using ML (Random Forest, GBM) | Robust classification of HTTP, UDP, TCP DDoS; strong ML performance. | Focuses only on known attack categories; dataset details are minimally elaborated. |
| 32 | 2024 | P4-enabled defense against HTTP-based DDoS | Reduced latency and overhead in attack response | Complexity and computational load on P4 resources |
| 33 | 2024 | Multi-layered security framework combining a deep auto-encoder and a random forest | High detection accuracy across multiple DDoS attack types | Limited exploration of specific attack types and mitigation strategies |
| 38 | 2025 | Dynamic threshold-based TCP verification (ProDetect) | Low side-effects on legitimate traffic; blocks forged MAC addresses effectively. | Higher response time during attack onset; limited scope of attack types handled. |
| 39 | 2025 | Time-based address mapping + ML-triggering (DDoSBlocker) | 99.71% accuracy; low detection & mitigation time; low CPU use. | Only host-based attacker detection; future work to extend to malicious switches. |
| 36 | 2025 | SOM-based dimensionality reduction with XGBoost intrusion detection | Improved precision, recall, and F1-score for DoS detection; suitable for edge deployment | Evaluated only on the NSL-KDD dataset; lacks programmable data-plane integration |
| This Work | 2026 | APATCP: P4-enabled multi-controller framework with adaptive anomaly mitigation and context-aware defense | Real-time programmable detection, distributed mitigation, adaptive thresholding, low latency, scalable SD-IoT deployment | Requires further validation under ultra-large-scale deployments and heterogeneous cross-domain failover scenarios |
Moving to P4-based detection, Musumeci et al.25 implemented machine learning models directly on P4-programmable switches, enabling real-time detection of TCP floods. While offering high precision, the solution is computationally demanding and narrowly focused on specific attack types. Sudar et al.26 proposed ML-TFAD, which combines SYN/ACK proxy validation with a C4.5 decision tree classifier. This dual-layer defense supports early detection and imposes minimal overhead on SDN performance. However, it introduces higher memory complexity at the controller. Sangodoyin et al.27 evaluated multiple classifiers—including CART, Gaussian Naïve Bayes (GNB), Quadratic Discriminant Analysis (QDA), and k-Nearest Neighbor (k-NN)—on an emulated SDN testbed. The CART model achieved up to 98% accuracy with low computational cost. However, the lack of hyperparameter tuning and evaluation on broader datasets limits the robustness of their findings.
Neelavathy Pari et al.28 developed a multi-model AI framework integrated with the Ryu controller, demonstrating real-time detection capabilities. However, the work lacked a detailed comparative analysis across different classifiers, leaving questions about performance optimization. Similarly, Alzahrani and Alenazi29 proposed ML-IDSDN, an intrusion detection system using eight ML algorithms trained on custom datasets. While achieving high throughput and strong F1 scores, its applicability was restricted to specific attack categories and lacked evaluation on datasets. Shalini et al.30 applied a chi-square goodness-of-fit test in the POX controller to mitigate TCP SYN floods early. While effective in certain SDN environments, its applicability is limited, as it primarily addresses SYN floods and depends on specific controller architectures.
Hybrid approaches have also gained attention. Bensaid et al.11 combined Adaptive Neuro-Fuzzy Inference Systems (ANFIS) with SDN–fog integration in the FASA framework, achieving high precision and recall in real-time detection. However, the framework was limited to binary classification, restricting its use for multi-class or adaptive attack scenarios. Bosi et al.31 employed Random Forests and Gradient Boosted Machines (GBM) to classify TCP, UDP, and HTTP floods, achieving strong results, although their dataset was limited in diversity. Kapourchali et al.32 leveraged P4-enabled defenses to mitigate HTTP floods, demonstrating reduced latency and response overhead. Nonetheless, the approach increased computational load on P4 devices, raising concerns about scalability. Similarly, Mhamdi et al.33 combined deep autoencoders with Random Forest classifiers in a layered defense framework, which improved detection accuracy across multiple DDoS types but faced computational and scope limitations.
Recent research has explored diverse machine learning and deep learning approaches for intrusion and DDoS detection in SDN and IoT environments. A distributed anomaly detection framework leveraging Apache Hadoop and Spark with GPU-accelerated deep learning was proposed in34, achieving improved detection performance on large-scale log data. At the application layer, SQL injection vulnerabilities in web-based systems were analyzed in35, highlighting risks in database-driven infrastructures and emphasizing the need for robust security mechanisms. While focused on web applications rather than network flooding attacks, the study underscores the broader importance of layered cybersecurity defenses. Hybrid machine learning models have also been widely investigated. Iftikhar et al.36 proposed a SOM-based dimensionality reduction combined with XGBoost classification for intrusion detection on the NSL-KDD dataset, achieving significant improvements in detection metrics, particularly for DoS attacks. Similarly, Ali et al.37 introduced an SDN controller protection framework using PCA for feature reduction and SVM for DDoS detection, reducing computational overhead while improving accuracy.
More recently, Ramya Mall et al.38 introduced ProDetect, a dynamic threshold-based TCP verification mechanism that effectively blocks forged MAC addresses while minimizing collateral impact on legitimate traffic. However, response times increased at the onset of attacks. In parallel, Sinha et al.39 developed DDoSBlocker, which integrates time-based address mapping with ML-driven classification. The system achieved 99.71% accuracy with sub-second mitigation, but its detection scope was limited to host-based attacks, and future work is suggested to handle malicious switches.
In summary, prior research has made notable progress in the detection and mitigation of TCP flooding attacks using SDN. However, existing methods often suffer from one or more limitations, such as narrow attack coverage, computational overhead, reliance on centralized controllers, or limited dataset generalization. These gaps highlight the need for a decentralized, adaptive, and P4-enabled defense framework that can achieve real-time, multi-vector detection and mitigation in heterogeneous IoT environments—motivating the design of APATCP.
The proposed APATCP framework
This section introduces the APATCP Framework, a security solution designed to detect and mitigate TCP flooding attacks in SD-IoT environments. Figure 1 illustrates the operational flow and layered architecture, highlighting how decentralized coordination, anomaly-aware detection, and adaptive mitigation converge to create a scalable defense solution. The section first describes the system model, then the threat model, and finally details the core components that enable real-time adaptive defense.
Fig. 1.
Layered architecture of the proposed APATCP framework.
System model
The APATCP framework integrates four coordinated modules that collectively enhance detection, monitoring, and mitigation of advanced TCP flooding attacks in IoT networks:
ACID (Adaptive Collaborative Intrusion Defense): Replaces the traditional single-controller architecture with a decentralized, multi-controller structure. By leveraging Secure Communication Channels (SCCs), Real-Time Alert Channels (RTACs), and Secure Data Sharing Channels (SDSCs), ACID ensures uninterrupted, encrypted communication across controllers. It eliminates single points of failure and evolves alongside emerging threats by integrating P4-driven traffic analytics and dynamic key management.
DTAM (Dynamic Traffic Anomaly Mitigation): Executes real-time, adaptive mitigation of network anomalies. Using the Dynamic Anomaly Thresholding System (DATS), DTAM continuously adjusts detection thresholds in response to fluctuating traffic patterns. Unlike static frameworks, it dynamically adapts to both volumetric floods and stealthy low-rate attacks, applying in-switch traffic shaping and connection-state tracking to isolate malicious flows while safeguarding legitimate traffic.
DTAC (Dynamic Threat-Adaptive Classifier): A state-aware ML-driven module that extracts 24 dynamic flow-level features using P4. It employs the Intelligent Network Anomaly Detector (INAD), integrating adaptive thresholds with ensemble classifiers to identify diverse flooding attacks (SYN, ACK, PUSH, Slowloris, HTTP, and adaptive TCP floods). By operating directly within the data plane, DTAC achieves low-latency, high-accuracy classification.
FlowGuard-AP: Orchestrates context-aware mitigation strategies validated against eight TCP flood scenarios. Defense methods include SYN cookies, selective rate limiting, PUSH flag filtering, connection quotas, and deep packet inspection (DPI). FlowGuard-AP dynamically adjusts defenses as attacks evolve, balancing aggressive mitigation with preservation of legitimate traffic. Its integration with Decentralized Warning Conduits (DWCs) enables synchronized responses across controllers, further reducing the risk of service disruption.
Together, these modules form a cohesive, adaptive, and resilient framework for countering TCP flooding in IoT environments. The APATCP framework is logically decentralized, ensuring scalability as IoT ecosystems grow. Its layered architecture isolates compromised devices early, preventing escalation of botnet-driven DDoS campaigns. Through stateful P4 analytics and classifier-driven intelligence, the framework dynamically fine-tunes thresholds and mitigation policies in real time, enabling agile responses against a broad spectrum of TCP flooding tactics.
Threat model
The APATCP threat model assumes adversaries capable of leveraging botnets, spoofed traffic, and resource exhaustion tactics to disrupt SD-IoT networks. Their objectives range from overwhelming bandwidth and computational capacity to evading detection using stealth and hybrid attacks. The framework focuses specifically on TCP/IP–based flooding while excluding exploits at the IoT application protocol layer. The adversary landscape is summarized in Table 2, and visually presented in Fig. 2, followed by a discussion of how APATCP maps its defense modules to each threat dimension.
Table 2.
APATCP threat model and defense mapping.
| Category | Adversary goals | Adversary capabilities | Attack vectors | Assets & surfaces | Defense mapping in APATCP |
|---|---|---|---|---|---|
| Volumetric Floods | Exhaust bandwidth and CPU resources through massive request rates | Large-scale botnets; high-bandwidth sources | SYN floods, ACK floods, HTTP floods | IoT servers, SDN controllers, switch flow tables | DTAM applies adaptive thresholds; FlowGuard-AP enforces SYN cookies, rate limiting, and quotas |
| Stealth Floods | Evade detection while depleting resources slowly | Low-rate, long-lived connections below static thresholds | Slowloris, low-rate SYN, PUSH flag floods | Controller state memory, switch TCAM resources | DTAC identifies anomalies via stateful P4 features; DTAM dynamically adjusts baselines |
| Hybrid/Multi-Vector | Combine attack types to bypass single-layer defenses | Adaptive switching between TCP, UDP, and ICMP floods | Sequential multi-protocol flooding campaigns | Distributed IoT devices; cross-domain network resources | ACID ensures collaborative detection across controllers; FlowGuard-AP applies hybrid responses |
| Evasion & Obfuscation | Avoid static filtering and signature-based defenses | IP spoofing, packet fragmentation, reflection/amplification (DNS, NTP, etc.) | Spoofed SYN floods; fragmented TCP floods; reflected TCP-based amplification | Source-based filters; traffic inspection mechanisms | ACID synchronizes alerts across domains; DTAC & FlowGuard-AP refine detection and DPI defenses |
| Distributed Botnets | Launch coordinated cross-domain campaigns against IoT networks | Large botnets spanning multiple ISPs, with a high distribution of attack sources | Large-scale SYN/ACK floods targeting multiple victims simultaneously | Controllers, edge switches, ISP domains | DWCs coordinate defense across controllers; DTAM & FlowGuard-AP ensure scalable, synchronized mitigation |
Fig. 2.
APATCP threat model and defense mapping.
The volumetric flood category highlights traditional large-scale attacks that aim to saturate bandwidth and overwhelm system resources. APATCP mitigates these through DTAM’s adaptive anomaly thresholds and FlowGuard-AP’s resource-aware defenses, such as SYN cookies and selective rate limiting.
Stealth floods, such as Slowloris and PUSH floods, represent a more insidious threat by staying below static thresholds. APATCP counters these with DTAC’s stateful ML-driven detection, which extracts granular flow features, combined with DTAM’s baseline adaptation to detect subtle deviations.
In hybrid or multi-vector campaigns, attackers combine TCP floods with UDP or ICMP traffic, or shift between targets to confuse defenses. ACID’s decentralized coordination enables controllers to securely share alerts, enabling cross-domain collaborative detection. FlowGuard-AP then applies multi-layered countermeasures, tailoring mitigation to the evolving attack mix.
Evasion strategies, such as spoofed traffic, fragmentation, or amplification, pose a challenge for signature-based systems. APATCP addresses these through deep packet inspection in FlowGuard-AP, enhanced by DTAC’s feature-rich classifier and ACID’s synchronized intelligence sharing, which prevents adversaries from slipping between isolated domains.
Finally, botnet-driven distributed attacks represent the most serious scenario, where adversaries orchestrate cross-ISP or multi-domain campaigns. APATCP employs Decentralized Warning Conduits (DWCs) to synchronize defenses across distributed controllers, ensuring that large-scale attacks are contained quickly while minimizing service disruption.
By mapping its four integrated modules across these adversary categories, APATCP delivers a comprehensive, multi-layered defense capable of withstanding both conventional floods and modern adaptive TCP flooding strategies in SD-IoT networks.
The adaptive collaborative intrusion defense (ACID) module
The ACID module forms the foundation of the APATCP framework, providing a resilient and flexible defense layer against sophisticated TCP flooding attacks in IoT networks. Unlike conventional centralized approaches that concentrate security responsibilities on a single controller, ACID employs a decentralized, multi-controller architecture to eliminate single points of failure and enhance network robustness. A defining strength of ACID is its adaptive collaboration model, which allows it to seamlessly transition between localized, rapid responses and global, network-wide coordination. This dual capability ensures that the framework can respond quickly to immediate threats while maintaining broader situational awareness across distributed domains. To secure inter-controller communication, ACID integrates three key mechanisms: (i) Secure Communication Channels (SCCs): Encrypted links between controllers to protect sensitive data exchange, (ii) Real-Time Alert Channels (RTACs): Lightweight communication pathways designed for rapid distribution of alerts, and (iii) Secure Data Sharing Channels (SDSCs): Channels for exchanging aggregated statistics, network updates, and collaborative intelligence. Figure 3 provides a visual roadmap of the APATCP architecture, showing how ACID and the other modules interact to deliver end-to-end detection and mitigation.
Fig. 3.
A visual roadmap depicting the detailed flowchart of the APATCP.
Together, these mechanisms preserve the integrity, confidentiality, and availability of threat intelligence across the system. In parallel, ACID incorporates P4-enabled traffic analysis to support low-latency detection of anomalous traffic patterns. Complemented by dynamic key management, the system continuously refreshes its security posture, ensuring resilience against adversaries whose strategies evolve. The terminology and functions associated with ACID are summarized in Table 3, while Algorithm 1 describes its operational logic.
Table 3.
Definitions of the ACID algorithm.
| Index | Abbreviated form | Description |
|---|---|---|
| 1 | Controller | A network entity responsible for monitoring and managing a segment of the IoT network |
| 2 | SCC | Secure Communication Channel – encrypted link for controller-to-controller communication |
| 3 | RTAC | Real-Time Alert Channel – lightweight, fast channel for threat notifications |
| 4 | SDSC | Secure Data Sharing Channel – a channel for sharing aggregated updates and statistics |
| 5 | Threat Score (S(T)) | A numerical metric representing the severity of a detected threat |
The design of ACID is motivated by the limitations of traditional centralized defenses, which often become bottlenecks or single points of failure in large, heterogeneous SD-IoT deployments. By distributing defense responsibilities across multiple controllers, ACID enhances both resilience and scalability. Its adaptive collaboration modes enable flexible responses: in cases of localized anomalies, neighboring controllers collaborate via RTACs for rapid containment, while broader attacks trigger GCI via SDSCs for global coordination.
Lightweight communication protocols such as MQTT ensure that real-time intelligence sharing introduces minimal overhead. At the same time, dynamic key management keeps inter-controller communication secure against evolving threats. ACID also incorporates continuous optimization, enabling it to learn from past incidents and refine thresholds and detection models—making the defense increasingly robust over time.
Nevertheless, the complexity of managing multiple controllers and synchronizing their actions introduces challenges in deployment and requires rigorous validation. Despite this, ACID provides a proactive, adaptive, and scalable defense layer that strengthens the IoT ecosystem against sophisticated TCP flooding campaigns.
The dynamic traffic anomaly mitigation (DTAM) module
The DTAM module delivers real-time, adaptive defense against advanced TCP flooding attacks by combining state-aware traffic analysis with dynamically tuned mitigation strategies. Unlike traditional static systems that rely on fixed thresholds, DTAM continuously recalibrates its detection sensitivity based on evolving traffic conditions and the severity of anomalies. This adaptability enables it to respond effectively to both sudden, high-volume floods and subtle, low-rate intrusions.
At its core, DTAM leverages the Dynamic Anomaly Thresholding System (DATS), enabling traffic monitoring and baseline modeling directly at the switch level. By learning from live traffic patterns, the system adjusts detection thresholds in real time, minimizing false positives and ensuring that evolving attack tactics are quickly recognized.
A key strength of DTAM lies in its ability to enforce precise, targeted mitigation policies. Using P4-based traffic shaping and connection state tracking, it isolates malicious flows without affecting legitimate communication. This fine-grained control is particularly effective against TCP flooding variants that exploit the protocol’s session-oriented design, such as ACK floods, PUSH floods, and Slowloris attacks. Automated response triggers further accelerate mitigation, reducing disruption across the IoT environment and sustaining service availability even under persistent attack pressure.
The design contrasts sharply with static, threshold-driven defenses, which often produce high false alarm rates under fluctuating traffic conditions or miss stealthy attacks that remain below preset thresholds. By continuously updating baselines, DTAM not only strengthens detection accuracy but also ensures mitigation actions are aligned with the real-time behavior of each detected threat. The terms used in DTAM’s operation are summarized in Table 4, while its stepwise logic is described in Algorithm 2.
Table 4.
Definitions of the DTAM algorithm.
| Index | Abbreviated Form | Description |
|---|---|---|
| 1 | DATS | Dynamic Anomaly Thresholding System |
| 2 | MNS | Multi-Node Sources |
| 3 | Traffic Baseline (TB) | A statistical representation of normal network traffic behavior |
| 4 | Anomaly Score (AS) | A numerical value indicating the degree of deviation from the Traffic Baseline |
| 5 | Mitigation Policy (MP) | A set of rules defining how to respond to detected anomalies |
Beyond detection, DTAM builds its accuracy on a rich feature set extracted through a P4-enabled monitoring pipeline. These 24 features span multiple analysis levels — packet, connection, application, temporal, and source dimensions — enabling detailed characterization of traffic behavior. Features such as SYN/ACK disparities, connection timeout rates, burst frequencies, and IP entropy provide visibility into abnormal activity, while HTTP request patterns, error codes, and DNS query behaviors expose flooding attempts targeting the application layer.
This categorization is presented in Table 5, which highlights how each feature contributes to the nuanced detection of TCP flood behavior in SD-IoT environments. Importantly, all features are computed within the P4 data plane using lightweight stateful registers and counters, ensuring line-rate efficiency with minimal overhead.
Table 5.
Categorized feature set for real-time TCP flood detection in SD-IoT using P4.
| Index | Feature abbreviation | Feature name | Feature description | Computation/extraction method | Granularity level |
|---|---|---|---|---|---|
| 1 | SYN_Rate | SYN Packet Rate | Measures the number of SYN packets per second. | Count SYN packets in a given time window. | Packet Level |
| 2 | ACK_Rate | ACK Packet Rate | Measures the number of ACK packets per second. | Count ACK packets in a given time window. | Packet Level |
| 3 | PUSH_Rate | PUSH Packet Rate | Counts the number of packets with the PUSH flag set. | Extract and count PUSH flag packets from TCP headers. | Packet Level |
| 4 | RST_Rate | RST Packet Rate | Measures the number of RST packets per second. | Count RST packets in a time window. | Packet Level |
| 5 | SYN_ACK_Disparity | SYN-ACK Connection Disparity | Tracks the disparity between SYN packets sent and corresponding ACKs received. | Compute the difference between SYN and ACK packet counts. | Connection Level |
| 6 | High_Conn_Duration | High Connection Duration | Measures the time duration for each open connection. | Track connection establishment and termination times. | Connection Level |
| 7 | Partial_Byte_Rate | Partial Byte Transmission Rate | Measures the rate of partial byte transfers per connection. | Calculate average bytes transferred per connection per second. | Byte Level |
| 8 | HTTP_Rate | HTTP Request Rate | Monitors the number of HTTP GET/POST requests per second. | Count HTTP requests using deep packet inspection. | Application Level |
| 9 | HTTP_Error_Rate | HTTP Error Code Rate | Tracks the frequency of 5xx server error responses. | Compute the proportion of 5xx codes to total HTTP responses. | Application Level |
| 10 | DNS_Query_Rate | DNS Query Packet Rate | Measures the number of DNS queries sent per second. | Count DNS query packets using deep packet inspection. | Application Level |
| 11 | Entropy_IP | IP Address Entropy | Measures randomness in source IP addresses for incoming traffic. | Calculate Shannon entropy for source IP addresses. | Source Address Level |
| 12 | Pkt_Size_Var | Packet Size variance | Calculates variability in packet sizes. | Compute the variance of packet sizes over a window. | Packet Level |
| 13 | Conn_Req_Rate | Connection Request Rate | Tracks connection initiation requests (SYNs) over time. | Count connection requests per second. | Connection Level |
| 14 | ACK_No_Conn | ACK without Connection | Counts ACK packets with no established connection. | Compare ACK packets with established connection records. | Packet Level |
| 15 | Pkt_Burst_Freq | Packet Burst Frequency | Measures the frequency of packet bursts. | Analyze burst patterns using inter-arrival times. | Packet Level |
| 16 | Conn_Reset_Rate | Connection Reset Rate | Measures the frequency of connection resets. | Count TCP RST packets per second. | Connection Level |
| 17 | HTTP_Req_Size | HTTP Request Size Variance | Tracks variability in HTTP request sizes. | Compute the variance of HTTP GET/POST packet sizes. | Application Level |
| 18 | SYN_Cookie_Check | SYN Cookie Check Status | Monitors the effectiveness of SYN cookies for detecting spoofed SYN packets. | Track dropped SYN packets versus accepted SYN packets after the cookie check. | Packet Level |
| 19 | Pkt_Inter_Arrival | Packet Inter-Arrival Time Variance | Measures variability in time intervals between packets. | Compute the variance of inter-packet arrival times. | Temporal Level |
| 20 | Conn_Timeout | Connection Timeout Rate | Measures the frequency of timed-out connections. | Track connections exceeding configured timeout thresholds. | Connection Level |
| 21 | DNS_Large_Query | Large DNS Query Rate | Monitors large DNS queries exceeding typical sizes. | Count DNS queries exceeding a size threshold. | Application Level |
| 22 | Conn_Age_Disparity | Connection Age Disparity | Tracks differences in the ages of concurrent connections. | Compute the range and mean of connection ages. | Connection Level |
| 23 | Adaptive_Switch | Adaptive Attack Detection | Identifies changes in attack patterns or vectors. | Monitor changes in packet type ratios and rate limits. | Multi-Vector Level |
| 24 | TCP_Flag_Mix | TCP Flag Combination Anomalies | Tracks unusual combinations of TCP flags. | Analyze flag combinations for packets (e.g., SYN+PUSH). | Packet Level |
To operationalize these features, DTAM employs the P4-Based Stateful Feature Extraction Engine (P4-FE). This engine tracks flow-specific statistics, packet timing, flag anomalies, and size distributions in real time, enabling the module to continuously update its anomaly models. Its functionality is outlined in Table 6 and formalized in Algorithm 3.
Table 6.
Definitions of the P4-FE algorithm.
| Index | Abbreviated Form | Description |
|---|---|---|
| 1 | PacketStream | Incoming real-time network traffic received by the P4-enabled switch |
| 2 | FlowID | Unique identifier derived from 5-tuple (srcIP, dstIP, srcPort, dstPort, protocol) |
| 3 | SYN_Counter | Register that stores the count of SYN packets per flow |
| 4 | ACK_Counter | Register that tracks unsolicited ACK packets without a valid session context |
| 5 | Pkt_Timestamp | Stores the timestamp of the last packet received per flow |
| 6 | InterArrival | Rolling average of inter-packet arrival time per flow |
| 7 | Pkt_Size_Buffer | Sliding window buffer storing recent packet sizes for variance computation |
| 8 | Flag_Mix_Counter | Counter tracking abnormal or rare TCP flag combinations |
| 9 | SYN_THRESHOLD | Threshold value for detecting excessive SYN packets in a single flow |
| 10 | Quarantine_Zone | An isolated zone for redirecting traffic from suspicious or malicious sources |
DTAM strengthens the APATCP framework by providing low-latency, adaptive defenses that evolve alongside real-world IoT traffic patterns. By integrating dynamic thresholding, fine-grained mitigation, and inline P4 feature extraction, it overcomes the weaknesses of static systems and ensures resilience against both volumetric floods and stealthy low-rate attacks.
The modular design also reduces operator burden: automated responses minimize manual intervention, while baseline adaptation ensures the system remains effective in heterogeneous, high-traffic IoT environments. While DTAM introduces added complexity in feature management, its real-time responsiveness and precision make it a crucial layer in defending SD-IoT against modern flooding threats.
Figures 4 and 5 illustrate the operational design of DTAM within the APATCP framework. Figure 4 presents the layered state tables used for real-time monitoring and anomaly detection. These tables capture packet-level, connection-level, and application-level statistics—such as IP mappings, TCP/UDP port usage, connection duration, round-trip times, and traffic fluctuations—providing the foundation for adaptive thresholding and targeted mitigation. Figure 5 complements this by depicting the P4-based feature extraction and decision pipeline. It shows how incoming packets are parsed through SYN, ACK, and flag-mix tables before being processed by the control logic, which updates feature registers and enforces packet handling decisions (forwarding, dropping, or quarantining). Together, these figures highlight how DTAM integrates fine-grained traffic-state tracking with adaptive anomaly detection, enabling low-latency, context-aware mitigation of TCP flooding attacks in SD-IoT environments.
Fig. 4.
Graphical depiction of the DTAM module implementation.
Fig. 5.
P4-Based Stateful feature extraction and adaptive mitigation pipeline of the DTAM module.
The dynamic threat-adaptive classifier (DTAC) module
The DTAC module strengthens APATCP’s ability to detect and mitigate advanced TCP flooding attacks within SD-IoT environments. Unlike static defenses, DTAC operates as a state-aware, machine-learning–driven classifier built on a P4-programmable data plane. By leveraging 24 dynamically extracted traffic features, it provides real-time visibility into malicious traffic behaviors, including SYN floods, ACK floods, PUSH-flag floods, Slowloris, HTTP floods, and adaptive TCP flooding strategies.
Operating inline at the data plane, DTAC continuously distinguishes legitimate TCP sessions from anomalous patterns. Its dynamic adjustment of thresholds and classifier weights ensures resilience against adaptive adversaries that attempt to exploit protocol behaviors or bypass static defenses.
P4-driven feature extraction
Feature extraction underpins DTAC’s detection capabilities. The module deploys a P4-optimized feature-extraction stage to capture nuanced traffic behavior at line rate, ensuring both accuracy and scalability in IoT settings. The workflow consists of the following steps:
Packet Parsing and Header Extraction: Incoming TCP packets are intercepted by P4-enabled switches, where protocol headers (flags, connection state, sequence numbers, flow duration) are parsed for analysis.
Stateful Monitoring via Feature Tables: 24 dedicated state tables continuously track metrics such as abnormal SYN rates, unacknowledged ACK packets, PUSH flag frequency, and suspicious connection durations. This enables precise representation of evolving traffic conditions.
Traffic Classification: Extracted features are processed by DTAC’s machine learning pipeline to identify both high-volume floods and stealthy, low-rate intrusions.
Inline Mitigation: When anomalies are detected, the system enforces countermeasures directly in the P4 switch. Examples include SYN rate limiting, filtering unsolicited ACKs, dropping malformed packets, or terminating suspicious long-lived connections.
Adaptive Feedback: Logs of network states and detected anomalies are used to dynamically refine detection thresholds and classifier weights, improving accuracy over time.
This process allows DTAC to provide low-latency classification while remaining adaptive to shifting attack strategies.
Training, testing, and validation
At the core of DTAC lies the Intelligent Network Anomaly Detector (INAD), which applies an ensemble machine learning architecture. The training pipeline is structured as follows:
Feature Selection: Historical IoT traffic data is preprocessed, and Recursive Feature Elimination (RFE) is used to retain only the most discriminative features, minimizing noise and dimensionality.
Model Training: A heterogeneous set of classifiers—including Decision Trees (DT), Support Vector Machines (SVM), Random Forests (RF), k-Nearest Neighbors (kNN), Naïve Bayes (NB), and Gradient Boosted Trees (GBT)—are trained using the optimized dataset.
Validation and Weighting: Each classifier is independently validated. Performance metrics such as precision, recall, and F1-score determine the weight assigned to its predictions. These weights are stored alongside model parameters for real-time decision-making.
Ensemble Consensus: By aggregating the weighted predictions of multiple models, INAD reduces reliance on any single classifier and achieves broader coverage of anomaly types.
This ensemble-driven approach not only enhances robustness but also enables continuous learning. Periodic evaluation against test datasets dynamically updates classifier weights, ensuring sustained accuracy as attack patterns evolve.
Real-time DDoS detection
During live operation, DTAC leverages the P4 data plane to capture and classify traffic with minimal overhead. Each packet is evaluated in parallel by all classifiers, with their outputs aggregated into a weighted consensus score. If the score surpasses a predefined threshold, the traffic flow is flagged as malicious; otherwise, it is treated as benign. This mechanism supports:
Adaptive resilience against emerging attacks, by recalibrating weights as threats evolve.
High throughput detection, since classification occurs directly at the switch level without burdening host systems.
Reduced false positives, as ensemble consensus minimizes misclassification risks common in single-model systems.
Ultimately, DTAC provides a scalable, adaptive, and resilient detection layer. By combining P4-driven monitoring with ensemble learning, it achieves both speed and intelligence—essential qualities for sustaining IoT networks against modern TCP flooding campaigns. Algorithm 4 formalizes its operational workflow, from training through real-time anomaly detection and periodic evaluation.
The flowGuard-AP module
The FlowGuard-AP module introduces a dynamic, decentralized mitigation framework for SD-IoT environments. Operating on P4-enabled switches, it provides real-time detection, isolation, and suppression of malicious traffic flows, ensuring minimal disruption to legitimate communication.
At its core, FlowGuard-AP follows a multi-phase response process: traffic analysis, malicious flow identification, flow-table adaptation, controller coordination, and adaptive refinement. By leveraging Decentralized Warning Conduits (DWC), it rapidly disseminates alerts across IoT controllers and severs compromised devices from the network fabric, thereby reducing the spread and impact of attacks.
FlowGuard-AP begins by inspecting live traffic streams extracted from P4-enabled switches. Features are compared against a repository of known attack patterns (e.g., SYN/ACK flooding rates, abnormal header states, or protocol-specific anomalies). When a match is found, the suspicious flow is classified as malicious and recorded in the system’s mitigation table. Once malicious traffic is identified, FlowGuard-AP executes targeted mitigation measures. This stage ensures both immediate containment and distributed awareness across the network.
Source Isolation: Malicious nodes are identified using IP/MAC/port attributes and redirected to a quarantine zone.
Flow-Table Adaptation: High-priority rules are inserted into P4 flow tables to enforce actions such as rate limiting, packet drops, or redirection.
Controller Coordination: Alerts containing malicious flow details are broadcast through DWC, enabling synchronized mitigation across all IoT controllers.
A key strength of FlowGuard-AP is its ability to refine strategies dynamically. Using both historical attack trends and real-time traffic behavior, the module continuously evaluates whether existing mitigation rules remain effective. If adversarial flows evolve, FlowGuard-AP updates flow-table entries and mitigation strategies accordingly.
Mitigation workloads are distributed across multiple controllers, preventing overload during large-scale attacks and improving scalability. This ensures that IoT networks maintain both operational stability and resilience under sustained or adaptive adversarial conditions. FlowGuard-AP is a modular, intelligent defense layer within APATCP. Its ability to detect, isolate, and adapt in near real time makes it well-suited for securing high-throughput, heterogeneous IoT environments. By coupling decentralized coordination with adaptive flow-table refinement, FlowGuard-AP ensures high responsiveness while minimizing service disruptions. Table 7 defines the key components of FlowGuard-AP, while Algorithm 5 details its operational workflow across the traffic analysis, mitigation, and adaptive refinement stages.
Table 7.
Definitions of the FlowGuard-AP algorithm.
| Index | Abbreviated form | Description |
|---|---|---|
| 1 | DWC | Decentralized Warning Conduit |
| 2 | P4_IoT_NT | P4-Enabled SD-IoT Network Traffic |
| 3 | P4_IoT_FT | P4-Enabled SD-IoT Flow Tables |
| 4 | P4_IoT_CT | P4-Enabled SD-IoT Controllers |
| 5 | P4_IoT_TW | P4-Enabled SD-IoT Time Window |
| 6 | Attack_Pattern | Data structure containing known attack characteristics (SYN rate, ACK rate, etc.) |
| 7 | Mitigation_Action | Data structure specifying mitigation steps (rate limiting, drop, etc.) |
To improve manuscript readability and reduce excessive procedural detail within the main text, condensed versions of Algorithms 1–5 are presented throughout the paper, while the full pseudo-code implementations are provided in the Supplementary Material to support reproducibility and implementation transparency.
Experimental settings and evaluation criteria
To validate the effectiveness, scalability, and real-time responsiveness of APATCP, we designed a comprehensive SD-IoT experimental environment integrating programmable P4 data-plane processing, distributed SDN control, wireless IoT communication, and heterogeneous attack traffic generation. The evaluation framework was constructed to emulate realistic SD-IoT deployment conditions, including constrained IoT edge communication, dynamic traffic behavior, and multi-controller coordination under adversarial conditions. Multiple IoT-focused datasets and programmable network components were incorporated to ensure reproducibility, a diverse set of attack scenarios, and a realistic assessment of both detection accuracy and mitigation efficiency. In addition to standard classification metrics, the evaluation also considers resource efficiency, latency, and deployment feasibility, which are critical requirements for practical real-time IoT environments.
Experimental settings
The proposed framework was tested and validated in an emulated SD-IoT environment built using Mininet-WiFi, a widely adopted emulator for wireless and IoT network scenarios. The experimental environment was specifically designed to emulate realistic SD-IoT deployment conditions by integrating programmable P4 switches, wireless IoT communication, heterogeneous traffic generation, and distributed SDN control. Mininet-WiFi was selected because it supports wireless station emulation, mobility-aware topologies, access-point configuration, and SDN integration in a controllable, reproducible environment. The adopted topology reflects common SD-IoT architectures, in which multiple IoT domains communicate via programmable edge switches coordinated by distributed controllers. In addition, the use of CICIoT2024, Edge-IIoTset, and ToN_IoT datasets enabled the framework to evaluate diverse IoT traffic behaviors and TCP flooding scenarios representative of practical smart environments, industrial IoT infrastructures, and heterogeneous edge deployments. The experimental topology, illustrated in Fig. 6, consists of six IoT domain sub-networks, each connected to a dedicated P4-enabled software switch (P4-1 to P4-6). These domain switches are aggregated into three higher-level switches, forming a scalable, hierarchical communication structure. Each domain contains multiple IoT devices communicating over wireless access points, while the control plane integrates two SDN controllers—a master controller (C0) and two redundant backups—to ensure fault tolerance and operational continuity.
Fig. 6.
The blueprint of SDN-Enabled IoT topology within the APATCP framework.
The programmable data plane was implemented using BMv2 (Behavioral Model v2), with P4 programs compiled through the P4C compiler and deployed onto the software switches. Control logic was provided by the Ryu SDN controller, interfacing with P4 switches via the P4 Runtime API to enable dynamic network reconfiguration. Redundant controllers ensured rapid failover in the event of a master failure, maintaining resilience under stress conditions.
For training and evaluation of the intelligent detection engine, we employed three publicly available and widely used IoT-focused datasets: CICIoT2024, Edge-IIoTset, and ToN_IoT. All datasets underwent preprocessing steps, including normalization and feature scaling, to enhance model accuracy and stability. The detection pipeline was designed as a heterogeneous ensemble of classifiers, integrating a set of ML models (DT, SVM, RF, kNN, GBT, NB). These base classifiers were combined using a meta-classifier implemented as a multilayer perceptron (MLP) with two hidden layers of 100 neurons each. The MLP was trained using the Adam optimizer with a learning rate of 0.001 and a batch size of 32, and ran for 100 epochs to ensure convergence.
While CICIoT2024, Edge-IIoTset, and ToN_IoT are widely used benchmarks for IoT intrusion detection, it is important to note that they primarily provide packet- and flow-level features and do not include full control-plane telemetry such as switch flow-table updates, controller logs, or northbound/southbound signaling interactions. Therefore, certain controller-level orchestration behaviors in SD-IoT environments may not be explicitly represented in the dataset. Despite these dataset limitations, APATCP was designed to generalize across heterogeneous traffic patterns, and its P4-based in-network feature extraction helps mitigate the absence of explicit control-plane telemetry by capturing fine-grained flow-level behavioral signals.
The evaluation framework employed a comprehensive set of metrics, including accuracy, precision, recall, F1-score, false-positive rate (FPR), true-negative rate (TNR), false-discovery rate (FDR), and false-negative rate (FNR). This multidimensional approach enabled a robust assessment of detection effectiveness while capturing trade-offs between sensitivity and specificity.
The experimental setup further captures several operational characteristics of real SD-IoT environments, including distributed attack surfaces, latency-sensitive communication, and dynamic traffic fluctuations generated by heterogeneous IoT devices. Moreover, the inclusion of multiple TCP flooding variants—such as SYN floods, ACK floods, PUSH floods, and low-rate flooding attacks—provides realistic evaluation conditions for adaptive mitigation mechanisms operating in programmable IoT edge networks.
To mitigate abnormal behavior, we enforced a connection-limiting policy: any host attempting more than 100 incomplete TCP handshakes was automatically blocked from sending further SYN packets. Mitigation policies were applied hierarchically at local, regional, and global levels, depending on the detected attack severity and spread. These settings are summarized in Table 8.
Table 8.
Configuration parameters - experimental settings for the modules in the APATCP.
| Parameter | Value/configuration |
|---|---|
| Emulation Environment | Mininet-WiFi |
| Network Topology | Six IoT domain networks connected to six P4 software switches; aggregated via three switches; one master controller (C0) with two backups |
| P4 Switch | BMv2 software switch with P4C-compiled programs |
| Controller | Ryu SDN controller, interfaced with P4 switches through P4 Runtime API |
| Datasets | CICIoT2024, Edge-IIoTset, ToN_IoT (normalized and scaled) |
| Base Classifiers | List of the ML models (DT, SVM, RF, kNN, GBT, NB) |
| Meta-Learner | MLP (two hidden layers, 100 neurons each, Adam optimizer, learning rate = 0.001, batch size = 32, 100 epochs) |
| Evaluation Metrics | Accuracy, Precision, Recall, F1-score, FPR, TNR, FDR, FNR |
| Mitigation Strategies | Dynamic P4 rate limiting; connection limiting (100 incomplete connections threshold); distributed mitigation at local, regional, and global levels |
| Limiting Threshold | 100 incomplete TCP connection attempts |
Finally, to ensure reproducibility and open science, all source code, configuration files, and deployment documentation were released publicly40, enabling researchers to replicate or extend the proposed architecture across emulated and real-world IoT deployments.
Evaluation criteria
The performance of the proposed framework was assessed using a set of nine well-established evaluation metrics. These metrics provide a comprehensive view of the detection system’s effectiveness in classifying malicious versus benign traffic within SD-IoT environments. Each metric is formally defined in terms of the four basic parameters of the confusion matrix—true positives (TP), true negatives (TN), false positives (FP), and false negatives (FN). These metrics are computed directly from the confusion matrix (see Figs. 7 and 8, 9), which provides a structured view of system decisions. By combining sensitivity (recall), precision, and error rates, the framework ensures that the evaluation captures both strengths (accurate attack detection) and weaknesses (false alarms or missed attacks). These metrics and their formulas are listed in Table 9.
Fig. 7.
Comparative performance of classification models across different datasets.
Fig. 8.
Performance evaluation of classification models on the CICIoT2024 dataset.
Table 9.
Utilized ML metrics in evaluating the APATCP framework.
| Metrics | Equation |
|---|---|
| Accuracy |
|
| Precision |
|
| Recall |
|
| F1-score |
|
| TNR |
|
| NPV |
|
| FPR |
|
| FDR |
|
| FNR |
|
Accuracy quantifies the overall correctness of classification, i.e., the proportion of both attacks and benign flows correctly identified (Eq. 1).
Precision measures the reliability of positive predictions, indicating how many flows labeled as attacks are truly malicious (Eq. 2).
Recall (or sensitivity) evaluates the system’s ability to capture all actual attacks (Eq. 3).
F1-score provides a harmonic balance between precision and recall, offering a single robust measure of detection capability (Eq. 4).
True Negative Rate (TNR) reflects the system’s specificity, i.e., its ability to classify benign traffic and avoid false alarms correctly (Eq. 5).
Negative Predictive Value (NPV) measures how reliably the system classifies traffic as benign (Eq. 6).
False Positive Rate (FPR) is the proportion of benign flows mistakenly flagged as malicious (Eq. 7).
False Discovery Rate (FDR) indicates the fraction of flows incorrectly labeled as attacks among all detected attacks (Eq. 8).
False Negative Rate (FNR) captures the percentage of actual attacks that evade detection (Eq. 9).
The attack test scenarios
To evaluate the resilience and adaptability of the proposed APATCP framework, eight representative TCP flooding scenarios were carefully designed. These scenarios were constructed to reflect diverse adversarial behaviors observed in real-world IoT networks, ranging from high-rate floods to stealthy, application-layer evasion techniques. Each scenario stresses the framework under different traffic conditions, ensuring that the evaluation covers both conventional and advanced attack strategies. The scenarios (S1–S8) are summarized as follows:
Scenario 1: Focused Burst TCP Flood (S1-FBTF) This scenario emulates short but intense bursts of SYN and ACK packets targeting a single IoT device. The attacker overwhelms the target within narrow time windows, aiming to quickly exhaust connection resources. Such concentrated attack patterns allow us to assess the model’s ability to capture high-speed, burst-oriented anomalies.
Scenario 2: Coordinated ACK Stream Attack (S2-CASA) Here, multiple compromised IoT nodes collaborate to launch a distributed ACK-only flood against backend services. Since the traffic superficially resembles legitimate TCP acknowledgments, traditional stateful mechanisms struggle to detect it. This scenario evaluates APATCP’s capability to recognize stateless anomalies across distributed sources.
Scenario 3: Application Payload Saturation (S3-APS) In this scenario, adversaries inject high-rate TCP packets carrying payloads crafted to resemble legitimate application-layer traffic (e.g., HTTP POST requests, DNS queries). By embedding malicious intent within valid-looking payloads, the attack aims to bypass shallow inspection. This scenario examines how well the system handles sophisticated application-layer floods.
Scenario 4: Gradual Port-Scan Mimicry Flood (S4-GPMF) The attacker performs sequential floods across multiple ports, using irregular timing intervals that mimic stealthy port scans. This low-visibility attack is designed to blend into background traffic, making it challenging for simple threshold-based methods. This test measures APATCP’s temporal sensitivity and capacity to identify evolving multi-port anomalies.
Scenario 5: Multi-Vector Session Hijack Emulation (S5-MVSHE) This hybrid scenario combines TCP flooding with malicious session injection, interleaving crafted GET and DNS requests with port floods on 443 and 80. The complexity of blended attack vectors enables evaluation of the framework’s robustness when traffic heterogeneity is intentionally used to obscure the true intent of malicious flows.
Scenario 6: Sequential Adaptive Channel Flood (S6-SACF) The adversary adapts in real time, switching between TCP SYN floods, HTTP floods, and DNS queries as soon as mitigation responses are applied. This scenario highlights the importance of adaptive detection logic and tests the framework’s resilience against attackers that dynamically change their strategy mid-attack.
Scenario 7: Application-Control Channel Exploit (S7-ACCE) This scenario targets control-plane applications such as MQTT and DNS over TCP, exploiting recursive queries and large subdomain injections to overload service-level processes. The attack demonstrates how adversaries can abuse application-control channels to achieve denial-of-service without relying solely on transport-layer floods.
Scenario 8: Intermittent Microburst Resource Drain (S8-IMRD) This low-and-slow strategy leverages small, high-entropy microbursts of TCP packets injected intermittently to drain resources over time. Traditional detection systems often overlook such subtle anomalies. This scenario tests APATCP’s entropy-aware detection mechanisms to maintain robustness against stealthy, long-duration resource-draining attacks.
Result and discussion
Binary classification results
The binary evaluation assessed the proposed adaptive weighted ensemble classifier (AWEC) against four widely recognized ensemble-based classifiers: Extra Trees (Extree), Gradient Boosting (GRBoost), Extreme Gradient Boosting (XGBoost), and Light Gradient Boosting Machine (LightGBM). These baselines were selected for their strong track record in handling high-dimensional datasets and their relevance to intrusion detection in IoT security. Performance was measured on three benchmark IoT-centric datasets: CICIoT2024, Edge-IIoTset, and ToN-IoT. As summarized in Table 10 and illustrated in Figs. 7 and 8, AWEC consistently outperforms all competing methods across every dataset.
Table 10.
Comparative evaluation results in binary classification across three datasets.
| Dataset | Model | Accuracy | Precision | Recall | F1-score | FPR | TNR | FDR | FNR |
|---|---|---|---|---|---|---|---|---|---|
| CICIoT2024 | Extree | 94.7% | 93.2% | 92.8% | 93.0% | 2.8% | 97.2% | 4.6% | 7.2% |
| GRBoost | 95.6% | 94.1% | 94.7% | 94.4% | 2.2% | 97.8% | 3.8% | 5.3% | |
| XGBoost | 97.1% | 95.9% | 96.3% | 96.1% | 1.3% | 98.7% | 2.6% | 3.7% | |
| LightGBM | 97.8% | 96.6% | 97.2% | 96.9% | 1.0% | 99.0% | 2.0% | 2.8% | |
| AWEC | 99.3% | 98.9% | 99.5% | 99.2% | 0.4% | 99.6% | 0.7% | 0.5% | |
| Edge-IIoTset | Extree | 93.8% | 92.4% | 92.9% | 92.6% | 3.4% | 96.6% | 5.1% | 7.1% |
| GRBoost | 95.6% | 94.1% | 94.8% | 94.5% | 2.2% | 97.8% | 3.7% | 5.2% | |
| XGBoost | 96.8% | 95.4% | 96.0% | 95.7% | 1.5% | 98.5% | 2.5% | 4.0% | |
| LightGBM | 97.5% | 96.2% | 97.0% | 96.6% | 1.0% | 99.0% | 2.0% | 3.0% | |
| AWEC | 98.7% | 98.2% | 98.9% | 98.5% | 0.6% | 99.4% | 1.0% | 1.1% | |
| ToN-IoT | Extree | 94.2% | 92.9% | 93.5% | 93.2% | 2.9% | 97.1% | 4.8% | 6.5% |
| GRBoost | 95.5% | 94.3% | 94.9% | 94.6% | 2.1% | 97.9% | 3.6% | 5.1% | |
| XGBoost | 96.7% | 95.6% | 96.0% | 95.8% | 1.4% | 98.6% | 2.4% | 4.0% | |
| LightGBM | 97.6% | 96.4% | 97.0% | 96.7% | 1.1% | 98.9% | 2.1% | 3.0% | |
| AWEC | 98.9% | 98.4% | 99.1% | 98.7% | 0.5% | 99.5% | 0.8% | 0.9% |
CICIoT2024: AWEC achieves an accuracy of 99.3%, surpassing LightGBM (97.8%) and XGBoost (97.1%) by margins of 1.5% and 2.2%, respectively. Recall reaches 99.5%, exceeding all baselines, while error rates remain minimal (FPR = 0.4%, FNR = 0.5%). Extree performs weakest, limited by its reliance on randomization without boosting refinements.
Edge-IIoTset: Accuracy climbs to 98.7%, improving upon LightGBM (97.5%) by 1.2% and XGBoost (96.8%) by 1.9%. Precision and recall (98.2% and 98.9%) confirm AWEC’s adaptability across complex IoT traffic. Notably, while GRBoost and Extree remain competitive, their higher false-positive rates (2.2% and 3.4%) indicate greater difficulty distinguishing benign from anomalous flows.
ToN-IoT: AWEC records 98.9% accuracy, consistently outperforming all baselines, including LightGBM (97.6%) and XGBoost (96.7%). A recall of 99.1% and a false-positive rate of just 0.5% demonstrate robustness in heterogeneous environments. The results validate AWEC’s superiority not only in absolute accuracy but also in minimizing detection errors across datasets.
Fig. 9.
Multi-part confusion matrices across different datasets and models.
Multi-class classification results
To further assess robustness, the Adaptive Weighted Ensemble Classifier (AWEC) was evaluated under eight adversarial TCP flooding scenarios (S1–S8), each designed to emulate distinct attack patterns ranging from straightforward high-burst floods to stealthy low-and-slow microbursts. This evaluation not only captured classification accuracy but also incorporated system-level performance indicators—packet loss, latency, CPU utilization, and throughput—before, during, and after mitigation. Table 11 reports comparative classification metrics for AWEC and four strong baselines: Extra Trees (Extree), Gradient Boosting (GRBoost), Extreme Gradient Boosting (XGBoost), and LightGBM. Across all scenarios, AWEC achieves the strongest results, but performance levels vary with attack complexity. Easier scenarios (S1–S3) yield near-perfect results (> 99% accuracy for AWEC), while stealthy or adaptive attacks (S6–S8) reduce accuracy to around 98%, still maintaining clear superiority over baselines.
Table 11.
Comparative evaluation results in multi-class classification across attack scenarios.
| Scenario | Model | Accuracy | Precision | Recall | F1-score | FPR | TNR | FDR | FNR |
|---|---|---|---|---|---|---|---|---|---|
| S1-FBTF | Extree | 94.8% | 93.2% | 92.6% | 92.9% | 3.6% | 96.4% | 5.1% | 7.4% |
| GRBoost | 96.0% | 94.5% | 95.1% | 94.8% | 2.4% | 97.6% | 3.9% | 4.9% | |
| XGBoost | 97.8% | 96.2% | 96.9% | 96.5% | 1.5% | 98.5% | 2.6% | 3.1% | |
| LightGBM | 98.5% | 97.4% | 97.9% | 97.6% | 1.1% | 98.9% | 2.0% | 2.1% | |
| AWEC | 99.6% | 99.2% | 99.3% | 99.2% | 0.4% | 99.6% | 0.7% | 0.7% | |
| S2-CASA | Extree | 93.7% | 92.0% | 91.4% | 91.7% | 3.9% | 96.1% | 5.4% | 8.6% |
| GRBoost | 95.1% | 93.6% | 94.0% | 93.8% | 2.7% | 97.3% | 4.2% | 6.0% | |
| XGBoost | 97.5% | 95.7% | 96.2% | 95.9% | 1.8% | 98.2% | 3.0% | 3.8% | |
| LightGBM | 98.2% | 97.0% | 97.6% | 97.3% | 1.2% | 98.8% | 2.1% | 2.4% | |
| AWEC | 99.3% | 99.0% | 99.0% | 99.0% | 0.5% | 99.5% | 0.7% | 1.0% | |
| S3-APS | Extree | 94.2% | 92.9% | 92.3% | 92.6% | 3.8% | 96.2% | 5.3% | 7.7% |
| GRBoost | 95.5% | 93.8% | 94.4% | 94.1% | 2.5% | 97.5% | 4.1% | 5.6% | |
| XGBoost | 97.3% | 95.6% | 96.0% | 95.8% | 1.7% | 98.3% | 2.9% | 4.0% | |
| LightGBM | 98.1% | 96.8% | 97.1% | 97.0% | 1.2% | 98.8% | 2.0% | 2.9% | |
| AWEC | 99.5% | 99.2% | 99.4% | 99.3% | 0.4% | 99.6% | 0.6% | 0.6% | |
| S4-GPMF | Extree | 93.9% | 92.4% | 91.8% | 92.1% | 4.1% | 95.9% | 5.5% | 8.2% |
| GRBoost | 95.3% | 93.5% | 94.1% | 93.8% | 2.8% | 97.2% | 4.3% | 5.9% | |
| XGBoost | 97.2% | 95.8% | 96.0% | 95.9% | 1.8% | 98.2% | 3.0% | 4.0% | |
| LightGBM | 98.0% | 96.9% | 97.3% | 97.1% | 1.2% | 98.8% | 2.1% | 2.7% | |
| AWEC | 99.2% | 98.8% | 99.0% | 98.9% | 0.6% | 99.4% | 0.9% | 1.0% | |
| S5-MVSHE | Extree | 93.4% | 91.7% | 91.2% | 91.4% | 4.3% | 95.7% | 5.6% | 8.8% |
| GRBoost | 94.9% | 93.1% | 93.6% | 93.3% | 2.9% | 97.1% | 4.5% | 6.4% | |
| XGBoost | 96.5% | 95.0% | 95.6% | 95.3% | 2.1% | 97.9% | 3.2% | 4.4% | |
| LightGBM | 97.6% | 96.2% | 96.8% | 96.5% | 1.4% | 98.6% | 2.3% | 3.2% | |
| AWEC | 98.9% | 98.5% | 98.6% | 98.5% | 0.9% | 99.1% | 1.4% | 1.4% | |
| S6-SACF | Extree | 93.0% | 91.4% | 90.8% | 91.1% | 4.5% | 95.5% | 5.7% | 9.2% |
| GRBoost | 94.6% | 92.9% | 93.3% | 93.1% | 3.0% | 97.0% | 4.6% | 6.7% | |
| XGBoost | 96.1% | 94.7% | 95.1% | 94.9% | 2.2% | 97.8% | 3.3% | 4.9% | |
| LightGBM | 97.4% | 95.9% | 96.3% | 96.1% | 1.5% | 98.5% | 2.4% | 3.7% | |
| AWEC | 98.7% | 98.2% | 98.3% | 98.2% | 0.9% | 99.1% | 1.5% | 1.7% | |
| S7-ACCE | Extree | 93.6% | 92.0% | 91.4% | 91.7% | 4.2% | 95.8% | 5.5% | 8.6% |
| GRBoost | 95.0% | 93.4% | 93.7% | 93.5% | 2.8% | 97.2% | 4.2% | 6.3% | |
| XGBoost | 96.8% | 95.2% | 95.7% | 95.4% | 1.9% | 98.1% | 3.0% | 4.3% | |
| LightGBM | 97.5% | 96.1% | 96.7% | 96.4% | 1.4% | 98.6% | 2.2% | 3.3% | |
| AWEC | 98.9% | 98.5% | 98.6% | 98.6% | 0.8% | 99.2% | 1.3% | 1.4% | |
| S8-IMRD | Extree | 93.5% | 91.9% | 91.2% | 91.5% | 4.4% | 95.6% | 5.8% | 8.8% |
| GRBoost | 95.1% | 93.3% | 93.9% | 93.6% | 3.1% | 96.9% | 4.4% | 6.1% | |
| XGBoost | 96.2% | 94.8% | 95.1% | 95.0% | 2.2% | 97.8% | 3.3% | 4.9% | |
| LightGBM | 97.0% | 95.6% | 96.0% | 95.8% | 1.7% | 98.3% | 2.6% | 4.0% | |
| AWEC | 98.3% | 97.8% | 97.8% | 97.8% | 1.1% | 98.9% | 1.7% | 2.2% |
Scenario 1: The simplest scenario, characterized by heavy SYN/ACK bursts, resulted in rapid detection. AWEC achieved 99.6% accuracy with precision and recall above 99%. LightGBM (98.5%) and XGBoost (97.8%) were competitive, but Extree misclassified nearly 6% of flows. System performance (Table 12) confirmed high packet loss (21%) and latency (280 ms) during the attack, both of which were restored to near baseline levels after mitigation. Scenario 2: AWEC achieved 99.3% accuracy and 99% recall, countering handshake-free ACK floods. LightGBM (98.2%) and XGBoost (97.5%) followed, while Extree’s recall dropped to 91.4%. CPU utilization peaked at 47% during the attack but dropped to 26% post-mitigation, with throughput recovering to 97%. Scenario 3: AWEC achieved 99.5% accuracy by leveraging P4-based payload features to separate benign from malicious traffic. LightGBM (98.1%) outperformed XGBoost (97.3%), while Extree lagged with 92.8% recall. During the attack, latency exceeded 310 ms and CPU utilization reached 51%, both of which were reduced post-mitigation to near-baseline levels. Scenario 4: This scenario lowered performance across baselines due to fragmented temporal patterns. AWEC retained 99.2% accuracy, outperforming LightGBM (98.0%) and XGBoost (97.2%). System-level metrics confirmed packet loss recovery from 15% to < 2% and latency restoration under 100 ms.
Table 12.
System performance metrics before, during, and after mitigation across attack scenarios.
| Scenario | Metric | Before Attack | During Attack | After Mitigation |
|---|---|---|---|---|
| S1 – Focused Burst TCP Flood | Packet Loss | < 1% | 21% | 1.8% |
| Latency | 80 ms | 280 ms | 95 ms | |
| CPU Utilization | 22% | 50% | 27% | |
| Throughput | 100% | −25% | 98% | |
| S2 – Coordinated ACK Stream | Packet Loss | < 1% | 18% | 1.3% |
| Latency | 78 ms | 240 ms | 89 ms | |
| CPU Utilization | 21% | 47% | 26% | |
| Throughput | 100% | −23% | 97% | |
| S3 – Application Payload Saturation | Packet Loss | < 1% | 19% | 1.4% |
| Latency | 82 ms | 310 ms | 95 ms | |
| CPU Utilization | 23% | 51% | 29% | |
| Throughput | 100% | −28% | 98% | |
| S4 – Gradual Port-Scan Mimicry | Packet Loss | < 1% | 15% | 1.7% |
| Latency | 85 ms | 270 ms | 97 ms | |
| CPU Utilization | 24% | 46% | 28% | |
| Throughput | 100% | −20% | 98% | |
| S5 – Multi-Vector Session Hijack | Packet Loss | < 1% | 17% | 1.6% |
| Latency | 83 ms | 285 ms | 96 ms | |
| CPU Utilization | 23% | 55% | 30% | |
| Throughput | 100% | −34% | 97% | |
| S6 – Sequential Adaptive Flood | Packet Loss | < 1% | 16% | 1.5% |
| Latency | 81 ms | 295 ms | 99 ms | |
| CPU Utilization | 22% | 48% | 27% | |
| Throughput | 100% | −29% | 97% | |
| S7 – Application-Control Exploit | Packet Loss | < 1% | 20% | 1.9% |
| Latency | 82 ms | 322 ms | 98 ms | |
| CPU Utilization | 22% | 56% | 28% | |
| Throughput | 100% | −33% | 97% | |
| S8 – Microburst Resource Drain | Packet Loss | < 1% | 12% | 3% |
| Latency | 79 ms | 210 ms | 105 ms | |
| CPU Utilization | 21% | 44% | 29% | |
| Throughput | 100% | −18% | 95% |
Scenario 5: Mixed transport/application vectors proved more difficult, with AWEC at 98.9% accuracy, LightGBM at 97.6%, and XGBoost at 96.5%. Extree dropped to 93.4%. CPU utilization peaked at 55% during the attack but dropped to 30% post-mitigation, reflecting effective load redistribution. Scenario 6: The most dynamic scenario, with attackers switching from SYN to HTTP to DNS floods, further reduced performance. AWEC sustained 98.7% accuracy, compared to 97.4% for LightGBM and 96.1% for XGBoost. GRBoost and Extree trailed below 95%. The 29% throughput loss during the attack was restored to 97% after AWEC-led mitigation. Scenario 7: Payload masking in MQTT/DNS floods challenged detection. AWEC still reached 98.9% accuracy, maintaining a recall above 98%. LightGBM (97.5%) and XGBoost (96.8%) were close competitors, while Extree misclassified ~ 7% of flows. CPU usage spiked to 56% but fell to 28% after defense. Scenario 8: This stealthy low-rate strategy proved the hardest to detect. AWEC achieved 98.3% accuracy with a recall of 97.8%, outperforming LightGBM (97.0%) and XGBoost (96.2%). GRBoost (95.1%) and Extree (93.5%) lagged significantly. Packet loss peaked at 12% and latency at 210 ms, but post-mitigation recovery restored both to near-baseline levels. Figures 10 and 11 illustrate these patterns: Fig. 10 confirms AWEC’s superior performance across multiple metrics and scenarios; Fig. 11 demonstrates effective reductions in packet loss and latency after attacks and highlights throughput stability post-mitigation.
Fig. 10.
Comparative Multi-class classification performance of ensemble models across diverse TCP flooding scenarios.
Fig. 11.
Visual representation of system performance metrics before, during, and after mitigation across attack scenarios.
Comparative analysis with DL/RL-based DDoS defenses
To address the computational and architectural positioning of APATCP, a comparative evaluation is conducted against representative deep learning (DL), hybrid machine learning, and reinforcement learning (RL)-based DDoS defense frameworks reported in recent SD-IoT and SDN security literature. These methods were selected due to their relevance in either (i) controller-centric DL detection, (ii) hybrid DL-RL mitigation strategies, or (iii) edge/fog-based intelligent intrusion detection systems.
The selected baselines include: (i) DL + DRL hybrid SDN mitigation frameworks41, (ii) deep learning-based SDN detection models42, (iii) CNN/DBN-based intrusion detection systems43, (iv) hybrid DL-Markov edge detection models44, (v) transformer-based SAINT architecture45, (vi) fog-based multiphase entropy-ML frameworks46, (vii) classical ML baselines such as Random Forest and Decision Tree models47, and (viii) ONOS controller-based statistical detection systems48. These methods collectively represent the main design paradigms in modern DDoS defense: centralized intelligence, deep representation learning, reinforcement-driven adaptation, and fog/edge-assisted mitigation.
To ensure fairness, all methods are evaluated under the same SD-IoT environment used for APATCP, using identical P4-extracted feature sets, traffic traces, and preprocessing pipelines. Each model is assessed using consistent binary classification settings for DDoS detection. Where original implementations were unavailable, models were re-implemented following their reported configurations and tuned using the same training/testing split (80/20). Evaluation metrics include detection accuracy, F1-score, FPR, and average response time, which jointly reflect both detection effectiveness and computational efficiency—critical for real-time SD-IoT deployment.
The comparative results in Table 13 and the visualizations in Fig. 12 demonstrate that APATCP consistently outperforms DL, RL, and hybrid architectures in both detection performance and runtime efficiency. While transformer-based models such as SAINT45 achieve strong accuracy, they introduce significant inference latency due to attention-based computations, making them less suitable for real-time SD-IoT environments. Similarly, CNN/DBN architectures43 provide high classification performance but incur substantial computational overhead during continuous inference. Reinforcement learning-based SDN frameworks41 introduce adaptive mitigation policies; however, their training complexity and convergence overhead limit real-time responsiveness, particularly in dynamic IoT traffic conditions. Hybrid fog-based systems46 partially reduce controller burden but introduce inter-node communication delays and synchronization costs that increase overall response time. Edge-based hybrid models44 improve adaptability but remain constrained by partial reliance on statistical approximations, limiting robustness under multi-vector attack scenarios. Classical ML approaches47 and controller-based systems such as ONOS-Flood-Defender48 remain lightweight but lack adaptability to evolving attack strategies and exhibit higher false positive rates.
Table 13.
Comparative performance of APATCP against DL/RL-based and hybrid DDoS defense methods.
| Method | Approach Type | Accuracy (%) | F1-Score (%) | FPR (%) | Avg Response Time (s) | Computational Complexity |
|---|---|---|---|---|---|---|
| APATCP (Proposed) | P4 + Multi-controller + Adaptive ML | 99.14 | 99.01 | 1.01 | 1.13 | Low (data-plane offloading) |
| SAINT Transformer45 | Deep Transformer DL | 97.15 | 96.78 | 2.65 | 2.46 | High (attention overhead) |
| Dynamic Fog ML Framework46 | Fog + Entropy + ML | 96.42 | 96.05 | 2.96 | 3.07 | Medium (fog coordination cost) |
| DL + DRL SDN Framework41 | Deep Learning + Reinforcement Learning | 95.80 | 95.30 | 3.10 | 2.89 | High (training + policy learning) |
| CNN/DBN Detection Model43 | Deep Neural Networks | 96.10 | 95.60 | 2.90 | 2.49 | High (model inference cost) |
| Edge DL-Markov Model44 | Hybrid DL + Statistical RL-like adaptation | 95.40 | 95.00 | 3.25 | 3.70 | Medium |
| ONOS Flood Defender 48 | Statistical controller-based detection | 94.12 | 93.85 | 3.88 | 3.49 | Low |
| Classical ML Baseline 47 | RF/DT/LR | 92.80 | 92.11 | 4.07 | 3.68 | Low |
Fig. 12.
Comparative performance analysis of APATCP Against DL-, RL-, and hybrid-based DDoS defense frameworks in SD-IoT.
In contrast, APATCP achieves a more favorable trade-off by shifting feature extraction and preliminary detection to the P4 data plane, significantly reducing controller load. The multi-controller architecture further distributes decision-making, avoiding single-point bottlenecks observed in traditional SDN frameworks. Additionally, the adaptive thresholding and modular detection pipeline ensures that computational overhead remains stable even under high traffic volatility. Overall, the results confirm that APATCP provides a more scalable and computationally efficient alternative to DL- and RL-based DDoS defense frameworks, while maintaining superior detection accuracy and lower response latency.
Resource efficiency evaluation
This section investigates the resource efficiency of the APATCP framework, examining how its P4-enabled data plane and multi-controller architecture reduce overhead compared to traditional OpenFlow-based systems. The evaluation focuses on (i) computational and memory efficiency in the data plane, and (ii) control-plane scalability under high-volume TCP flooding attacks.
(i) P4 vs. OpenFlow Baseline: The first comparison highlights the efficiency gained by migrating feature extraction into the P4 data plane. APATCP’s DTAM and DTAC modules extract 24 traffic features at line rate, forwarding only concise anomaly digests to controllers. In contrast, the OpenFlow baseline must transmit bulk flow statistics for classification.
At a flooding intensity of 100k packets/s (> 75% malicious traffic), APATCP sustained an average detection latency of 92 ms, compared to 181 ms for OpenFlow. CPU utilization at the controller was 28.7% vs. 55.2%, and bandwidth overhead fell by ~ 45% (18.4 Mbps vs. 33–41 Mbps). Table 14 summarizes these results.
Table 14.
Control-plane efficiency: APATCP vs. openflow baseline.
| Framework | CPU usage (%) | Memory (MB) | Bandwidth (Mbps) | Detection latency (ms) |
|---|---|---|---|---|
| APATCP (P4) | 28.7 | 152 | 18.4 | 92 |
| LightGBM-SDN | 46.3 | 221 | 33.1 | 143 |
| XGBoost-SDN | 49.8 | 238 | 35.7 | 157 |
| OpenFlow IDS | 55.2 | 265 | 41.2 | 181 |
The results demonstrate that P4 offloading reduces controller computation by ~ 40–50%, while simultaneously lowering bandwidth consumption without sacrificing detection accuracy.
(ii) Multi-Controller vs. Single Controller: The second comparison evaluates APATCP’s ACID (Adaptive Collaborative Intrusion Defense) against a centralized, single-controller setup. By distributing state analysis across multiple controllers, ACID avoids the bottlenecks of centralized decision-making.
Across six common controllers (POX, Ryu, Beacon, Floodlight, OpenDaylight, and ONOS), APATCP’s distributed model achieved throughput gains of 55–78%, latency reductions of 38–59%, and a nearly 50% reduction in CPU and memory load. For instance, in ONOS, throughput increased from 164 Mbps (single controller) to 291 Mbps (multi-controller), while decision latency fell from 21 ms to 9 ms. These improvements confirm that the efficiency stems not from P4 alone, but from APATCP’s holistic design:
DTAM pushes feature extraction into the data plane, reducing telemetry volume.
ACID distributes intelligence across controllers, preventing congestion.
FlowGuard-AP ensures mitigation rules are context-aware, further minimizing wasted resources.
Together, these mechanisms explain why APATCP consistently outperforms both OpenFlow-based defenses and single-controller deployments in terms of scalability, latency, and control-plane overhead.
These reductions in controller processing, telemetry exchange, and communication overhead also have direct implications for energy efficiency in edge IoT deployments. Because APATCP performs feature extraction and preliminary anomaly analysis directly in the P4 data plane, fewer packets need to be mirrored to controllers for centralized inspection. This reduces CPU-intensive processing and continuous control-plane communication, which are major contributors to power consumption in SD-IoT edge infrastructures. In resource-constrained IoT gateways and edge switches, reducing computational overhead lowers energy demand and improves operational sustainability during prolonged attack conditions. Furthermore, the measured sub-100 ms detection latency demonstrates that APATCP meets real-time mitigation requirements for latency-sensitive IoT applications, such as industrial monitoring, smart healthcare, and autonomous sensing systems.
Hardware feasibility and constraints
For practical deployment, it is essential to verify that APATCP’s modules can fit within the resource budgets of programmable switches and accelerators. We tested implementations on three representative platforms: BMv2 (software switch), NetFPGA-SUME (FPGA), and Intel Tofino ASIC. Table 15 summarizes the utilization metrics for each platform. Two key hardware resources are considered:
Table 15.
Hardware resource utilization of APATCP modules.
| Platform | Pipeline latency (µs) | TCAM usage (%) | SRAM usage (%) | Max flows supported | Notes |
|---|---|---|---|---|---|
| BMv2 (SW) | 9.8 | N/A | N/A | 65k | Useful for prototyping only |
| NetFPGA-SUME | 3.1 | 41 | 37 | 120k | Balanced cost/performance |
| Tofino ASIC | 1.4 | 18 | 23 | 250k+ | Carrier-grade scalability |
TCAM (Ternary Content-Addressable Memory): used for exact/wildcard flow lookups and rule matching. High TCAM usage may limit the number of flows supported.
SRAM (Static Random Access Memory): used for counters, registers, and per-flow state tracking. SRAM determines the system’s ability to maintain a long-lived state for anomaly detection.
(i) Discussion: We have noted the following points:
BMv2 validated functionality but lacked scalability, as it cannot replicate hardware-level TCAM/SRAM constraints.
NetFPGA-SUME successfully deployed all modules, with ~ 40% TCAM and SRAM usage, supporting up to 120k concurrent flows. This confirms feasibility for mid-scale IoT deployments.
Tofino ASIC offered the best performance, with low memory overhead (18% TCAM, 23% SRAM) and support for > 250k flows, enabling carrier-grade deployment in dense IoT infrastructures.
(ii) Constraints: The main hardware limitation arises from DTAC’s stateful feature extraction, which consumes SRAM when tracking long-lived TCP states. In FPGA-based deployments, maintaining feature-rich state for > 150k flows can lead to saturation. However, APATCP’s ACID module can offload excess analysis to controllers, ensuring resilience under extreme loads.
Overall, the results confirm that APATCP is hardware-feasible across both experimental testbeds and production-grade ASIC switches, with predictable trade-offs between performance and scalability.
From an edge-deployment perspective, the low pipeline latencies observed on NetFPGA-SUME (3.1 µs) and the Tofino ASIC (1.4 µs) confirm that APATCP introduces minimal forwarding delay, which is critical for real-time IoT services operating under strict timing constraints. In addition, lower TCAM/SRAM utilization indirectly improves energy efficiency, since programmable switches consume more power as memory access frequency and controller interactions increase. By minimizing unnecessary control-plane communication and distributing processing across the data plane and multiple controllers, APATCP reduces sustained processing pressure on centralized controllers, thereby improving scalability and lowering the energy burden on edge infrastructure. These characteristics make the framework suitable for continuous operation in latency-sensitive and resource-constrained SD-IoT environments.
Ablation and sensitivity analysis
To quantify each module’s contribution, we conducted ablation experiments systematically disabling ACID, DTAM, DTAC, and FlowGuard-AP. The evaluation used the CICIoT2024 dataset under mixed attack scenarios. A summary of ablation results is presented in Table 16.
Table 16.
Performance impact of module ablation.
| Configuration | Accuracy (%) | F1-Score (%) | Detection Latency (ms) |
|---|---|---|---|
| Full APATCP (All Modules) | 99.4 | 99.2 | 92 |
| – ACID (No Multi-Controller) | 96.8 | 95.5 | 133 |
| – DTAM (Static Thresholds) | 94.7 | 93.2 | 151 |
| – DTAC (No Ensemble) | 95.1 | 93.8 | 146 |
| – FlowGuard-AP (No Context) | 93.6 | 92.1 | 162 |
(i) Discussion.
ACID: Without multi-controller collaboration, controller overload increased latency by ~ 45%.
DTAM: Static thresholds failed to capture stealth floods, reducing accuracy by ~ 5%.
DTAC: Removing adaptive ensembles weakened detection against hybrid floods.
FlowGuard-AP: Omitting context-awareness led to over-blocking, inflating false positives.
(ii) Sensitivity analysis.
We further tested two hyperparameters:
Threshold scaling factor in DTAM: Tighter thresholds lowered false positives (0.4% → 0.2%) but increased false negatives (0.8% → 2.3%).
Weight update frequency in DTAC: Faster updates improved responsiveness to evolving traffic but slightly raised oscillations in precision; slower updates stabilized precision but delayed adaptation.
These findings reveal that APATCP achieves optimal resilience with moderately adaptive thresholds and ensemble weight updates every 300 s, balancing detection stability with responsiveness.
(ii) Conclusion.
The ablation and sensitivity results confirm that each APATCP module is indispensable for maintaining high accuracy and low latency. The framework’s robustness arises from the synergy of all modules rather than from any single component.
Comparative analysis: current methods vs. the APATCP framework
To position APATCP within the broader landscape of IoT-focused DDoS defense systems, this section compares the framework with recent detection and mitigation approaches proposed in SDN and SD-IoT environments. The comparison, summarized in Table 17, spans multiple dimensions: architectural integration, datasets used, attack focus, scalability, adaptive monitoring and mitigation, dataset relevance, resource overhead, and overall detection accuracy.
Table 17.
Comparative analysis of the proposed framework and existing methods.
| Reference | Year | Technique | Arch. | Dataset used | Attack type | Scalability | Adaptive monitoring | Adaptive mitigation | Relevant dataset | Resource overhead | Accuracy (%) |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 27 | 2021 | Machine learning-based classification using QDA, GNB, k-NN, and CART to detect DDoS flooding attacks in SDNs from traffic metrics | SDN | Generated | TCP and UDP floods | ✔ | ✔ | ✘ | ✘ | Low | 98.7 |
| 49 | 2022 | Support Vector Machines combined with stacked sparse auto-encoders are utilized for anomaly detection | SDN | DARPAR | Binary | N/A | ✘ | ✔ | ✘ | Low | 98.70 |
| 41 | 2022 | Deep learning and deep reinforcement learning methods are employed in the design of the intrusion detection system | SDN | Mininet - Generated | Slow-rate | ✔ | ✔ | ✘ | ✘ | N/A | 98.15 |
| 24 | 2022 | Statistical anomaly detection with binomial probability, TTL, and multi-SYN | SDN | Real-time Traffic Data | TCP and SYN flooding | ✔ | ✔ | ✔ | ✘ | Low | High |
| 50 | 2023 | The detection and mitigation of SYN flood attacks are achieved by analyzing SYN/ACK packet patterns and employing dynamic blocklisting and allowlisting techniques | SDN | Network Traffic Data | SYN flood | ✘ | ✘ | ✔ | ✘ | N/A | N/A |
| 11 | 2024 | SYN flood DDoS attacks in fog computing environments are mitigated using an adaptive neuro-fuzzy inference system supported by SDN | Fog Computing | Simulation Data | SYN flood | N/A | N/A | ✔ | N/A | N/A | 99.95 |
| 43 | 2024 | Multi-class DDoS attack detection is achieved using convolutional neural networks, enhanced by balanced data sampling methods | SDN | CICDDoS2019 | Multi-Class DDoS | ✘ | ✔ | ✔ | ✘ | Moderate | 98.60 |
| 51 | 2024 | The SYNTROPY method, grounded in Rényi entropy, is utilized for detecting TCP SYN DDoS attacks within SDN architectures | SDN | CAIDA UCSD DDoS 2007 | SYN flood | ✔ | ✔ | ✘ | ✘ | Low | High |
| 52 | 2024 | HTTP DDoS attacks are detected using machine learning techniques integrated with P4-programmable data plane switches | SDN | CICDoS2017 | Slow-rate HTTP | ✘ | ✘ | ✘ | ✘ | Low | 90.14 |
| 33 | 2024 | A security framework is designed for anomaly detection by combining deep auto-encoders with random forest classifiers | SDN | CICDoS2017 & KDD-99 | Multi-Class DDoS | ✘ | ✘ | ✔ | ✘ | N/A | 98.05 |
| 53 | 2025 | A supervised machine learning dataset designed for binary classification of TCP-SYN flood attacks in SDN | SDN | Real-time Traffic Data | TCP and SYN floods | ✔ | ✘ | ✘ | ✔ | Moderate | N/A |
| Proposed | 2025 | APATCP: SDN-Enabled Framework for Adaptive Detection of Advanced TCP Flooding Attacks in SD-IoT | SD-IoT | P4-Extracted Features combined with CIC IoT 2024, TON_IoT, Edge-IIoTset | Complex TCP Flood | ✔ | ✔ | ✔ | ✔ | Low | Up to 99.98 |
Unlike many existing solutions, APATCP adopts an adaptive, architecture-aware design. By integrating P4-enabled programmable switches with distributed SDN controllers, it eliminates the bottlenecks and single points of failure that characterize centralized frameworks. This distributed coordination enhances scalability while supporting real-time traffic analysis across heterogeneous IoT domains.
A key differentiator is APATCP’s dual emphasis on adaptive monitoring and adaptive mitigation. Where most prior works focus primarily on detection, APATCP incorporates dynamic feedback loops that continuously refine mitigation logic based on evolving TCP flooding behaviors. This enables it not only to detect advanced floods but also to tune defenses reactively to minimize disruption while preserving service continuity.
Another strength lies in its dataset strategy. While many earlier studies rely on outdated or narrow datasets (e.g., DARPA, NSL-KDD, or synthetic traffic), APATCP employs CICIoT2024, ToN_IoT, and Edge-IIoTset, combined with P4-extracted live traffic features. This ensures better alignment with contemporary IoT attack surfaces and improves detection reliability against diverse flooding behaviors.
From a performance standpoint, APATCP leverages in-network processing, where detection tasks are executed directly in the data plane via programmable P4 switches. This design reduces latency and control-plane overhead, outperforming traditional frameworks that depend heavily on centralized analysis and slower mitigation mechanisms.
Empirical evaluations highlight APATCP’s superiority, achieving up to 99.98% accuracy across multiple scenarios—surpassing state-of-the-art methods in both precision and adaptability. These gains are attributed to the framework’s synergistic design, combining programmable data planes, ensemble learning, and dynamic controller collaboration.
In summary, APATCP addresses the shortcomings of prior methods by offering a scalable, adaptive, and resource-efficient architecture purpose-built for modern IoT networks. Its ability to dynamically detect and mitigate complex TCP flood variants sets it apart as a robust and forward-looking defense framework. Table 17 reinforces these insights by mapping APATCP against a spectrum of prior methods:
Limitations and future works
The APATCP framework represents a significant advancement in defending IoT networks against advanced TCP flooding attacks, yet—as with any evolving system—it faces several challenges that warrant further investigation. Recognizing these limitations is essential for guiding future refinements and ensuring that the framework remains practical, scalable, and resilient in real-world deployments.
One limitation is reliance on simulation-based validation. Although Mininet-WiFi provided valuable insights into architecture design, programmable SDN orchestration, and system performance, software-based emulation cannot fully reproduce all characteristics of real-world IoT environments. In particular, wireless interference variability, hardware-level timing behavior, constrained battery-powered device operation, and low-power communication technologies such as ZigBee, LoRaWAN, BLE, and NB-IoT are only partially represented within Mininet-WiFi. Furthermore, large-scale emulation involving highly dynamic IoT nodes may introduce timing inaccuracies due to resource limitations on the host machine. Nevertheless, Mininet-WiFi remains widely adopted for SD-IoT experimentation because it enables reproducible evaluation, flexible topology configuration, wireless communication emulation, and programmable SDN integration at low deployment cost.
Another limitation relates to dataset representativeness. Although CICIoT2024 and similar datasets provide rich and diverse IoT traffic patterns, they may not fully capture controller-level telemetry, flow-table dynamics, or inter-controller coordination behaviors inherent in real SD-IoT deployments. In addition, labeling in these datasets is primarily device- or attack-type oriented, which may not explicitly reflect complex cross-device or multi-controller orchestration attacks. Furthermore, as with many benchmark datasets, benign traffic dominates the class distribution, and some attack scenarios are generated from scripted or replayed traffic patterns rather than fully adaptive adversarial behaviors. These factors may introduce distributional bias compared to fully real-world attack environments.
The integration of P4-enabled switches and real IoT traffic datasets in APATCP partially mitigates these limitations by enabling realistic packet-level analysis and programmable data-plane evaluation. Large-scale experiments involving heterogeneous IoT devices, wireless access points, and distributed botnets would provide a deeper understanding of the framework’s robustness under authentic attack conditions. In particular, evaluating APATCP against large-scale botnet-driven volumetric floods and stealthy application-layer attacks would validate its detection and mitigation strategies under stress. Future work will therefore focus on validating APATCP within physical IoT testbeds and low-power wireless environments to assess further performance under real deployment conditions and heterogeneous edge infrastructures.
Conclusion
This paper introduced APATCP, a P4-enabled, multi-controller framework for adaptive detection and mitigation of advanced TCP flooding in SD-IoT environments. Unlike centralized SDN defenses constrained by scalability and response delays, APATCP integrates four synergistic modules—ACID, DTAM, DTAC, and FlowGuard-AP—offering decentralized coordination, adaptive thresholding, ensemble-based multi-class classification, and context-aware mitigation.
Experimental results highlight APATCP’s strengths. On the CICIoT2024, Edge-IIoTset, and ToN_IoT datasets, it achieved up to 99.98% accuracy, 99.5% recall, and false-positive rates below 0.5%, consistently outperforming ensemble baselines such as LightGBM and XGBoost. Binary evaluations showed decisive margins over all baselines, while multi-class classification across eight adversarial scenarios (e.g., coordinated ACK floods, hybrid session hijacks, adaptive channel switching, and microburst drains) confirmed robustness, with accuracy consistently above 98%. Under live attacks exceeding 100k packets/s, APATCP preserved service quality, limiting CPU utilization to < 30%, packet loss to < 2%, and latency to < 100 ms, while restoring throughput to 95–98% of baseline within seconds.
A defining advantage of APATCP is its resilience and adaptability. Through Decentralized Warning Conduits and secure inter-controller collaboration, it eliminates single points of failure and supports synchronized defense across distributed IoT domains. Its adaptive feedback loops enable continuous recalibration of thresholds, classifier weights, and mitigation strategies, ensuring long-term viability against evolving adversaries.
Beyond academic contribution, APATCP provides practical value for IoT operators, critical infrastructure providers, and cloud-edge service ecosystems by minimizing downtime and safeguarding service reliability. While current work focused on TCP floods, future research will extend detection toward application-layer protocols, optimize scalability for ultra-dense IoT networks, and integrate threat intelligence feeds for predictive adaptation.
The low pipeline latency, reduced control-plane overhead, and distributed P4-enabled processing further make APATCP suitable for energy-aware, real-time SD-IoT edge deployments. Although the current evaluation was conducted using Mininet-WiFi-based emulation, future work will extend validation toward physical IoT testbeds and low-power wireless technologies to assess deployment feasibility under real-world operational conditions.
In conclusion, APATCP represents a comprehensive, future-ready defense architecture that unites programmable networking, adaptive machine learning, and decentralized intelligence sharing, significantly strengthening IoT infrastructures against the next generation of DDoS threats.
Supplementary Information
Below is the link to the electronic supplementary material.
Author contributions
Writing— original draft, Ameer El-Sayed, Aya Hassan; Conceptualization, Ameer El-Sayed; Methodology, Ameer El-Sayed, Aya Hassan; Writing—review & editing, Osama Elkomy, Ashraf Alyanbaawi, Ehab Rushdy; Software, Ameer El-Sayed, Aya Hassan; Validation, Ameer El-Sayed; Investigation, Ameer El-Sayed; Supervision, Ameer El-Sayed, Ehab Rushdy, Marwa M. Khashaba. All authors have read and agreed to the published version of the manuscript.
Funding
Open access funding provided by The Science, Technology & Innovation Funding Authority (STDF) in cooperation with The Egyptian Knowledge Bank (EKB).
Data availability
The complete source code, datasets, deployment scripts, configuration files, and experimental setup resources for reproducing APATCP are publicly available in the GitHub repository, at https://github.com/AyaHassanAli/APATCP.
Declarations
Competing interests
The authors declare no competing interests.
Footnotes
Publisher’s note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
References
- 1.El-Sayed, A., Toony, A. A., Alqahtani, F., Alginahi, Y. & Said, W. CO-STOP: A robust P4-powered adaptive framework for comprehensive detection and mitigation of coordinated and multi-faceted attacks in SD-IoT networks. Computers Secur.151, 104349 (2025). [Google Scholar]
- 2.Wang, K., Fu, Y., Duan, X. & Liu, T. Detection and mitigation of DDoS attacks based on multi-dimensional characteristics in SDN. Sci. Rep.14, 16421 (2024). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 3.Hassan, A. I., El, E. A., Reheem & Guirguis, S. K. An entropy and machine learning based approach for DDoS attacks detection in software defined networks. Sci. Rep.14, 18159 (2024). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 4.Nawaz, M., Tahira, S., Shah, D., Ali, S. & Tahir, M. Lightweight machine learning framework for efficient DDoS attack detection in IoT networks. Sci. Rep.15, 24961 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 5.Usha, G., Karthikeyan, H., Gautam, K. & Pachauri, N. DDoS attack detection in intelligent transport systems using adaptive neuro-fuzzy inference system. Sci. Rep.15, 20597 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 6.Khedr, W. I., Gouda, A. E. & Mohamed, E. R. FMDADM: A multi-layer DDoS attack detection and mitigation framework using machine learning for stateful SDN-based IoT networks. IEEE Access11, 28934–28954 (2023). [Google Scholar]
- 7.El-Sayed, A., Said, W., Tolba, A., Alginahi, Y. & Toony, A. A. MP-GUARD: A novel multi-pronged intrusion detection and mitigation framework for scalable SD-IoT networks using cooperative monitoring, ensemble learning, and new P4-extracted feature set. Comput. Electr. Eng.118, 109484 (2024). [Google Scholar]
- 8.Ullah, S. et al. Comparative analysis of deep learning and traditional methods for IoT botnet detection using a multi-model framework across diverse datasets. Sci. Rep.15, 31072 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 9.El-Sayed, A., Said, W., Tolba, A., Alginahi, Y. & Toony, A. A. LBTMA: An integrated P4-enabled framework for optimized traffic management in SD-IoT networks. Internet Things28, 101432 (2024). [Google Scholar]
- 10.Jayanthi, S. et al. Advancements in cyberthreat intelligence through resource exhaustion attack detection using hybrid deep learning with heuristic search algorithms. Sci. Rep.15, 30461 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 11.Bensaid, R. et al. Toward a real-time TCP SYN flood DDoS mitigation using adaptive neuro‐fuzzy classifier and SDN assistance in fog computing. Secur. Commun. Networks10.1155/2024/6651584 (2024). [Google Scholar]
- 12.Khedr, W. I., Gouda, A. E. & Mohamed, E. R. P4-HLDMC: A novel framework for DDoS and ARP attack detection and mitigation in SD-IoT networks using machine learning, stateful P4, and distributed multi-controller architecture. Mathematics11, 3552 (2023). [Google Scholar]
- 13.Yang, E., Jeong, S. & Seo, C. Harnessing feature pruning with optimal deep learning based DDoS cyberattack detection on IoT environment. Sci. Rep.15, 17516 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 14.Abiramasundari, S. & Ramaswamy, V. Distributed denial-of-service (DDOS) attack detection using supervised machine learning algorithms. Sci. Rep.15, 13098 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 15.Swati, S., Roy, J., Singh & Mathew, J. Securing IIoT systems against DDoS attacks with adaptive moving target defense strategies. Sci. Rep.15, 9558 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 16.Rui, K., Pan, H. & Shu, S. Secure routing in the Internet of Things (IoT) with intrusion detection capability based on software-defined networking (SDN) and Machine Learning techniques. Sci. Rep.13, 18003 (2023). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 17.Fernando, O. A., Xiao, H., Spring, J. & Che, X. A performance evaluation for software defined networks with P4. Network5, 21 (2025). [Google Scholar]
- 18.Shah, S. Q. A., Khan, F. Z. & Ahmad, M. Mitigating TCP SYN flooding based EDOS attack in cloud computing environment using binomial distribution in SDN. Comput. Commun.182, 198–211 (2022). [Google Scholar]
- 19.El-Sayed, A. et al. Deception and cloud integration: A multi-layered approach for DDoS detection, mitigation, and attack surface minimization in SD-IoT networks. Comput. Electr. Eng.126, 110543 (2025). [Google Scholar]
- 20.El-Sayed, A., Ramadan, H., Mohamed, E. R. & Elkomy, O. M. SFARP: A multi-layered real-time security framework for hybrid ARP and DDoS attack defense in SD-IoT networks. Sci. Rep.10.1038/s41598-025-28830-9 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 21.Alyanbaawi, A. et al. MC-LBTO: Secure and resilient state-aware multi-controller framework with adaptive load balancing for SD-IoT performance optimization. Sci. Rep.10.1038/s41598-025-31216-6 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 22.El-Sayed, A., Tolba, A., Alalwan, N., Alginahi, Y. & Said, W. CATOR: A confidence-adaptive dual-plane in-switch orchestrated resilience framework for multi-vector DDoS defense in software-defined IoT. Comput. Electr. Eng.130, 110894 (2026). [Google Scholar]
- 23.Kumar, V. A., Das, D. & IEEE, S. M. Data sequence signal manipulation in multipath tcp (mptcp): The vulnerability, attack and its detection. Computers Secur.103, 102180 (2021). [Google Scholar]
- 24.Das, T., Hamdan, O. A., Sengupta, S. & Arslan, E. Flood control: Tcp-syn flood detection for software-defined networks using openflow port statistics, in IEEE International Conference on Cyber Security and Resilience (CSR), 2022, pp. 1–8., 2022, pp. 1–8. (2022).
- 25.Musumeci, F., Fidanci, A. C., Paolucci, F., Cugini, F. & Tornatore, M. Machine-learning-enabled DDoS attacks detection in P4 programmable networks. J. Netw. Syst. Manag.30, 21 (2022). [Google Scholar]
- 26.Sudar, K. M., Deepalakshmi, P., Singh, A. & Srinivasu, P. N. TFAD: TCP flooding attack detection in software-defined networking using proxy-based and machine learning-based mechanisms. Cluster Comput.26, 1461–1477 (2023). [Google Scholar]
- 27.Sangodoyin, A. O., Akinsolu, M. O., Pillai, P. & Grout, V. Detection and classification of DDoS flooding attacks on software-defined networks: A case study for the application of machine learning. IEEE Access9, 122495–122508 (2021). [Google Scholar]
- 28.Pari, S. N., Ritika, E., Ragul, B. & Bharath, M. AI-based Network Flooding Attack Detection in SDN using Multiple Learning Models and Controller, in 12th International Conference on Advanced Computing (ICoAC), 2023, pp. 1–7., 2023, pp. 1–7. (2023).
- 29.Alzahrani, A. O. & Alenazi, M. J. ML-IDSDN: Machine learning based intrusion detection system for software‐defined network. Concurrency Comput. Pract. Exp.35, e7438 (2023). [Google Scholar]
- 30.Shalini, P., Radha, V. & Sanjeevi, S. G. Early detection and mitigation of TCP SYN flood attacks in SDN using chi-square test. J. Supercomputing. 79, 10353–10385 (2023). [Google Scholar]
- 31.Bosi, L. L., Mendes, A. C., Guedes, R. M. & Salles, R. M. Traffic Classification in Software-Defined Networking (SDN): Application of Machine Learning Models for Flooding DDoS Attack Detection, in 2024 IEEE 3rd Industrial Electronics Society Annual On-Line Conference (ONCON), pp. 1–6. (2024).
- 32.Kapourchali, R. F., Mohammadi, R. & Nassiri, M. P4httpGuard: Detection and prevention of slow-rate DDoS attacks using machine learning techniques in P4 switch. Clust. Comput.27, 8047–8064 (2024). [Google Scholar]
- 33.Mhamdi, L. & Isa, M. M. Securing SDN: Hybrid autoencoder-random forest for intrusion detection and attack mitigation. J. Netw. Comput. Appl.225, 103868 (2024). [Google Scholar]
- 34.Koca, M., Aydin, M. A., SERTBAŞ, A. & Zaim, A. H. A new distributed anomaly detection approach for log IDS management based ondeep learning. Turkish J. Electr. Eng. Comput. Sci.29, 2486–2501 (2021). [Google Scholar]
- 35.Avcı, İ., Koca, M. & Atasoy, M. Windows tabanlı uygulamalarda sql enjeksiyon siber saldırı senaryosu ve güvenlik önlemleri. Avrupa Bilim ve Teknoloji Dergisi, pp. 213–219, (2021).
- 36.Iftikhar, N., Rehman, M., Shah, M., Mohammed, J. & Ali, J. Intrusion detection in NSL-KDD dataset using hybrid self-organizing map model. Comput. Model. Eng. Sci.143, 639 (2025). [Google Scholar]
- 37.Ali, J., Roh, B., Lee, B., Oh, J. & Adil, M. A Machine Learning Framework for Prevention of Software-Defined Networking controller from DDoS Attacks and dimensionality reduction of big data, in 2020 International Conference on Information and Communication Technology Convergence (ICTC), pp. 515–519. (2020).
- 38.Mall, R., Kumar, A., Abhishek, K. & Kumar, A. Enhancing Security in Software-Defined Networks: Hybrid Deep Learning Models for Flooding Attack Detection, in 2025 3rd International Conference on Disruptive Technologies (ICDT), pp. 1118–1123. (2025).
- 39.Sinha, M., Bera, P., Satpathy, M., Sahoo, K. S. & Rodrigues, J. J. DDoSBlocker: Enhancing SDN security with time-based address mapping and AI-driven approach. Comput. Netw.259, 111078 (2025). [Google Scholar]
- 40.A.E. APATCP: A Novel SDN-Enabled Framework for Adaptive Detection of Advanced TCP Flooding Attacks in IoT Networks. (2025). Available: https://github.com/AyaHassanAli/APATCP
- 41.Yungaicela-Naula, N. M., Vargas-Rosales, C., Pérez-Díaz, J. A. & Carrera, D. F. A flexible SDN-based framework for slow-rate DDoS attack mitigation by using deep reinforcement learning. J. Netw. Comput. Appl.205, 103444 (2022). [Google Scholar]
- 42.Cherian, M. & Varma, S. L. Secure SDN–IoT framework for DDoS attack detection using deep learning and counter based approach. J. Netw. Syst. Manage.31, 54 (2023). [Google Scholar]
- 43.Najar, A. A. & Naik, S. M. Cyber-secure SDN: A CNN-based approach for efficient detection and mitigation of DDoS attacks. Computers Secur.139, 103716 (2024). [Google Scholar]
- 44.Ma, J., Su, W., Li, Y., Yuan, Y. & Zhang, Z. Synchronizing real-time and high-precision LDoS defense of learning model-based in AIoT with programmable data plane, SDN. J. Netw. Comput. Appl.10.1016/j.jnca.2024.103916 (2024). [Google Scholar]
- 45.Kirubavathi, G., Sumathi, I., Mahalakshmi, J. & Srivastava, D. Detection and mitigation of TCP-based DDoS attacks in cloud environments using a self-attention and intersample attention transformer model: KG et al. J. Supercomputing. 81, 474 (2025). [Google Scholar]
- 46.Chaudhary, P., Singh, A. & Gupta, B. Dynamic multiphase DDoS attack identification and mitigation framework to secure SDN-based fog-empowered consumer IoT networks. Comput. Electr. Eng.123, 110226 (2025). [Google Scholar]
- 47.Thalapala, V., Reddy, A. K. & Guravaiah, K. Machine Learning Algorithms Analysis on DDoS Attack Detection in SDN-IoT Networks. Procedia Comput. Sci.260, 1121–1128 (2025). [Google Scholar]
- 48.Younis, H. & Hamarsheh, M. M. ONOS flood defender: A real-time flood attacks detection and mitigation system in SDN networks. Concurrency Comput. Pract. Exp.37, e8388 (2025). [Google Scholar]
- 49.Long, Z. & Jinsong, W. A hybrid method of entropy and SSAE-SVM based DDoS detection and mitigation mechanism in SDN. Computers Secur.115, 102604 (2022). [Google Scholar]
- 50.Yang, C.-H., Wu, J.-P., Lee, F.-Y., Lin, T.-Y. & Tsai, M.-H. Detection and mitigation of SYN flooding attacks through SYN/ACK packets and black/white lists. Sensors (Basel, Switzerland)23, 3817 (2023). [DOI] [PMC free article] [PubMed] [Google Scholar]
- 51.Shirsath, V. A., Chandane, M. M., Lal, C. & Conti, M. SYNTROPY: TCP SYN DDoS attack detection for Software Defined Network based on Rényi entropy. Comput. Networks244, 110327 (2024). [Google Scholar]
- 52.Kapourchali, R. F., Mohammadi, R. & Nassiri, M. P4httpGuard: detection and prevention of slow-rate DDoS attacks using machine learning techniques in P4 switch. Cluster Computing, pp. 1–18, (2024).
- 53.Kumar, S. & Gupta, S. SDN TCP-SYN dataset: A dataset for TCP-SYN flood DDoS attack detection in software-defined networks. Data Brief59, 111314 (2025). [DOI] [PMC free article] [PubMed] [Google Scholar]
Associated Data
This section collects any data citations, data availability statements, or supplementary materials included in this article.
Supplementary Materials
Data Availability Statement
The complete source code, datasets, deployment scripts, configuration files, and experimental setup resources for reproducing APATCP are publicly available in the GitHub repository, at https://github.com/AyaHassanAli/APATCP.