A Context-Aware Self-Healing Security Framework for WBAN Against Sybil Attacks

Complete ML Model Pipeline: 4-Stage Evaluation

Pipeline Overview

Comprehensive 4-stage machine learning pipeline for WBAN Sybil detection: (1) Baseline validation, (2) Fast model selection, (3) Accuracy benchmarking, (4) Production deployment. This section consolidates all model development, testing, and validation steps.

Pipeline Architecture

Stage 1: Data Preparation & Baseline Validation

Objectives

• Load and explore WBAN dataset
• Handle missing values and outliers
• Feature engineering and normalization
• Establish baseline with Logistic Regression

Key Metrics

Feature Engineering: 19 WBAN-Specific Features

Extracted 19 features from raw WBAN sensor data, organized by physical and behavioral dimensions:

Category	Features	Purpose
Signal Strength (RSSI)	rssi_mean, rssi_std, rssi_min, rssi_max, rssi_frame_count, rssi_missing	Detect identity inconsistency and signal anomalies
Timing (Inter-Arrival)	iat_mean, iat_std	Identify irregular transmission intervals and burst patterns
Traffic Volume	pps, udp_pkt_count	Detect abnormal traffic volume and flooding attacks
Sequence & Behavioral	seq_gap_mean, seq_gap_max, seq_reset_rate, dup_seq_rate, out_of_order_rate, boot_change_rate	Identify spoofing, duplicate packets, and sequence anomalies

Feature Importance Ranking: Separation Strength Analysis

Feature importance determined by effect size (Cohen's d) measuring separation strength between normal and Sybil distributions:

Strongest Discriminators (Large Effect Size > 0.8)

Medium Discriminators (Medium Effect Size 0.5-0.8)

Weak Discriminators (Small Effect Size < 0.2)

Remaining features (rssi_missing, window_start_s, window_end_s, seq_reset_rate, rssi_max, seq_gap_mean, seq_gap_max, boot_change_rate, boot_id, iat_mean, iat_std) show minimal individual separation but contribute ensemble robustness.

Files Generated

Key Findings

Stage 2: Fast Models for Edge Deployment

Objectives

• Identify fastest model suitable for edge/mobile gateway deployment
• Achieve 99% accuracy while maintaining minimal inference latency
• Evaluate candidates: Random Forest, Logistic Regression variants
• Validate model size and memory constraints for embedded devices

Stage 2 Candidate Models Tested

Model	Accuracy	ROC-AUC	Inference (ms)	Model Size	Edge Ready
Random Forest (300 trees)	99.8%	0.9975	0.122 ms	21.33 MB	YES
Logistic Regression	87.89%	0.97	<0.001 ms	<1 MB	Yes (but insufficient accuracy)

Winner: Random Forest for Edge Deployment

Performance Comparison: Stage 1 vs Stage 2

Metric	Stage 1: Baseline (LR)	Stage 2: Fast (RF)	Improvement
Accuracy	87.89%	99.8%	+11.91%
ROC-AUC	0.97	0.9975	+0.0075
Speed Readiness	Instant (<1µs)	Very Fast (0.122 ms)	Still excellent for real-time
Edge Deployment	Yes (too simple)	Yes (optimal balance)	Recommended

Why Random Forest Wins Stage 2

Stage 2 Model Configuration

Stage 3: Find Most Accurate Model (Benchmark Best Possible)

Objectives

• Benchmark highest-accuracy models in ML literature
• Test advanced algorithms: Gradient Boosting, XGBoost, MLP Neural Network
• Determine accuracy ceiling for WBAN Sybil detection
• Compare deployment trade-offs before final selection

Stage 3: Advanced Model Accuracy Benchmark

Model	Accuracy	Recall	ROC-AUC	Architecture
Gradient Boosting	99.9917%	99.9733%	0.999994	Sequential ensemble (boosting)
XGBoost	99.9867%	99.9653%	0.999999	Optimized gradient boosting
MLP Neural Network	99.9673%	99.9025%	0.999986	3-layer fully connected network
Random Forest (Stage 2)	99.8%	99.8%	0.9975	Parallel ensemble (300 trees)

Accuracy Ceiling Finding

Detailed Model Characteristics

Stage 3 Analysis: Why Accuracy Alone Isn't Enough

Stage 4: Final Selection & Production Validation

Objectives

• Compare all candidate models on deployment metrics (FPR, latency, energy, storage)
• Rank models based on practical production requirements
• Make final selection for real-world deployment
• Validate on risk-based testing scenarios

Network Context ML Model Architecture

The Network Context Machine Learning Model is deployed at the gateway and performs real-time binary classification (legitimate vs. Sybil) using features extracted from WBAN network traffic. The model integrates signal-level, timing-level, and behavioral-level features to achieve accurate detection with minimal latency.

Stage 4: Deployment Comparison (Resource Overhead)

Model	False Positive Rate	Storage	Energy/Prediction	Inference Speed	Selection Rank
Gradient Boosting (SELECTED)	0.011983 (1.2%)	0.86 MB	0.007984 mJ	0.003992 ms	OPTIMAL BALANCE
XGBoost	0.015652 (1.57%)	0.38 MB	0.004536 mJ	0.002268 ms	Rank 2
MLP Neural Network	0.015407 (1.54%)	0.30 MB	0.003793 mJ	0.001897 ms	Rank 1 (Efficiency)
Random Forest	0.003179 (0.32%)	21.33 MB	0.243850 mJ	0.121925 ms	Rank 3 (Too Heavy)

Network ML Model Performance Benchmark

Metric	Stage 2 (Fast)	Stage 3 (Accurate)	Stage 4 (Selected)
Gradient Boosting (SELECTED)		99.9917% Accuracy	1.2% FPR (optimal balance)
Random Forest	99.8% Accuracy	Not in Stage 3 (baseline)	0.32% FPR (too resource-heavy)
XGBoost		99.9867% Accuracy	1.57% FPR (higher false alarms)
MLP Neural Network		99.9673% Accuracy	1.54% FPR (framework overhead)

Why Gradient Boosting Was Selected for Deployed Framework

Final Selection Ranking Justification

Rank	Model	Primary Strength	Critical Weakness	Verdict
1 (CHOSEN)	Gradient Boosting	Optimal Balance: 99.9917% accuracy 1.2% FPR (acceptable) 0.86 MB (deployable) 0.008 mJ (efficient)	Slightly higher FPR than RF but unavoidable for edge deployment	SELECTED FOR PRODUCTION FRAMEWORK
2 (Not Suitable)	Random Forest	Lowest FPR (0.32%)	Prohibitively high storage (21.33 MB) and energy (0.244 mJ) for edge deployment	Impractical resource overhead
3 (Not Suitable)	MLP Neural Network	Best efficiency (0.001897 ms, 0.30 MB)	High FPR (1.54%) disrupts medical monitoring, requires TensorFlow framework overhead	Accuracy marginal; FPR too high
4 (Not Selected)	MLP Neural Network	Fast (0.001897 ms)	1.54% FPR, GPU dependency, framework overhead	Over-engineered for problem size

Risk-Based Testing Results

Stage 4 Validation: Testing Models on Three Risk Profiles

Baseline Scenario (Normal Attack Patterns)

Metric	Value	Interpretation
Nodes in Network	4 nodes	Small WBAN with 2 legitimate, 2 Sybil attackers
Malicious Detected	2/2 (100%)	Both Sybil nodes identified correctly
False Quarantines	0	No legitimate nodes incorrectly blocked
Detection Latency	2 windows (10-20 sec)	Attack identified within 2 detection windows
Malicious Blocked	99.90%	Attack traffic effectively eliminated
Legitimate Blocked	0%	All legitimate traffic passes through

Harder Scenario (Stealthy Attack Patterns)

Metric	Value	Interpretation
Nodes in Network	4 nodes	Sybil attacker closely mimics legitimate behavior
Malicious Detected	1/2 (50%)	Only 1 out of 2 stealthy attackers caught
False Quarantines	0	No false positives, but misses sophisticated attacks
Detection Latency	3 windows (15-30 sec)	Stealthy attacks take longer to detect
Malicious Blocked	49.90%	Only partially effective against stealthy attacks
Legitimate Blocked	0%	No false positives on legitimate traffic

Scaled Scenario (Large Network, 8 Nodes)

Metric	Value	Interpretation
Nodes in Network	8 nodes total (4 normal, 4 Sybil)	Larger WBAN network, 50% attack rate
Malicious Detected	2/2 (100%)	Sybil detection still maintains 100% accuracy
False Quarantines	1	One legitimate node incorrectly quarantined (out of 4)
Detection Latency	2 windows (10-20 sec)	Speed maintained even with larger network
Malicious Blocked	99.90%	Attack mitigation effective
Legitimate Blocked	16.60%	One node's entire traffic blocked due to false quarantine

Stage 4 Findings

ML Model Testing & Real-World Validation

Overview

Comprehensive testing and validation of the selected Gradient Boosting model against three risk-based scenarios and real-world WBAN data. Tests validate that the model works correctly in different network conditions and attack variations.

Objectives

• Deploy Gradient Boosting model on actual WBAN testbed (ESP32 nodes)
• Validate performance metrics on live network traffic
• Confirm model works with real physiological sensor data
• Generate production deployment artifacts

Real-World Test Results

Deployment Artifacts

Validation Summary

Aspect	Status	Details
Model Accuracy		99.59% F1-Score on real data
Edge Device Ready		<1ms inference, 45MB model
Real-World Tested		Validated on WBAN sensor data
Deployment Scripts		Flask API & mobile gateway code

Mobile Gateway Deployment: Gradient Boosting Framework

Overview

Deploy the trained Gradient Boosting model on mobile phones, gateways, or edge devices for real-time Sybil detection in WBAN networks. Gradient Boosting selected for optimal balance between detection reliability (99.9917% accuracy, 1.2% FPR) and resource efficiency (0.86 MB storage, 0.008 mJ energy per prediction).

Deployment Options

Quick Start: Flask Service

API Endpoints

Endpoint	Method	Purpose	Response
/api/health	GET	Service status	{status, model_loaded}
/api/detect	POST	Single detection	{prediction, confidence}
/api/detect_batch	POST	Batch detection	{results: [...]}
/api/network_status	GET	Network statistics	{sybil_nodes, percentage}

Deployment Files

System Requirements

Auto-Start on Boot (Linux)

Create systemd service for automatic startup:

Lightweight Cryptographic Security Layer

Overview

The framework integrates ChaCha20-Poly1305 AEAD (Authenticated Encryption with Associated Data) to provide packet-level confidentiality, integrity, and node authentication. This layer operates at the communication level, filtering malicious packets before they enter the ML detection pipeline.

ChaCha20-Poly1305 AEAD Architecture

Cryptographic Verification Process

Stage	Component	Function	Time
1. Data Preparation	TLV Format	Sensor data structured as Type-Length-Value for extensibility. Allows future inclusion of additional sensor modalities without protocol modification.	<1 µs
2. Nonce Generation	Deterministic Nonce	Derived from NODE_ID + BOOT_ID + Sequence Number. Eliminates need to transmit nonce explicitly, reducing overhead.	<1 µs
3. Encryption	ChaCha20 Stream Cipher	Encrypts TLV payload using per-node symmetric key. Stream cipher provides efficient encryption for small WBAN packets (50-500 bytes).	15-20 µs
4. Authentication	Poly1305 MAC	Generates 16-byte authentication tag using packet header as Associated Authenticated Data (AAD). Enables identity verification without exposing payload.	10-15 µs
Total Encryption	ChaCha20-Poly1305 Combined		<30.5 µs

Gateway Verification Pipeline

Resource Overhead Analysis

Metric	Measured Value	Reference Range	Assessment
Code Size Overhead	<1.8%	~15% (typical)	Within range
RAM Usage	~11.2 KB	~0.52 KB	Acceptable
Encryption Latency	<30.5 µs	~50200 µs (software)	Faster (optimized)
Energy Overhead	<0.8%	~15% (literature)	Lower than expected

Attack Mitigation at Cryptographic Layer

Network Performance Impact

Condition	Packet Delivery Ratio (PDR)	Throughput Impact
Without Attack (Baseline)	81.34%	100% (reference)
With Sybil Attack (5:1 flood)	73.46%	98.2% (malicious packets filtered)
PDR Reduction	-7.88%	Attributed to RPL routing stack, not cryptography

Deployment Considerations

Autonomous Self-Healing Mechanism

Overview

Upon detection of a malicious node across multiple consecutive windows, the self-healing layer performs autonomous node isolation and dynamic network recovery. This ensures continuous data transmission even under active Sybil attacks, with recovery operating entirely at the gateway without firmware modification to sensor nodes.

Self-Healing Architecture

Detection & Isolation Pipeline

Stage	Component	Criteria	Action	Time
1. Real-Time Detection	ML Model	Sliding window (5-10 sec) classification	Output: Normal [0] or Sybil [1]	<5 ms
2. Transient Filter	Multi-Window Aggregation	Require 2 consecutive windows classified as Sybil	Reduce false positives from temporary anomalies	10-20 sec
3. Isolation Decision	Self-Healing Logic	If 2 consecutive windows = Sybil, trigger isolation	Mark node as QUARANTINED in gateway state	<1 ms
4. Packet Blocking	Gateway Enforcement	Check quarantine list before forwarding	Drop all incoming packets from quarantined node_id	<1 ms
5. Future Prevention	Identity Suppression	Maintain persistent quarantine list	Suppress traffic from same identity even if device resets	Persistent

Transient False Positive Handling

Isolation Implementation Details

Isolation Aspect	Implementation	Effect
Logical Isolation	Add node_id to gateway's quarantine_set	All future packets from this node_id are rejected before processing
Incoming Packet Blocking	if packet.source_id in quarantine_set: drop(packet)	Prevents malicious data from entering network
Outgoing Traffic Suppression	Prevent routing to quarantined node_id	No legitimate traffic wasted on attacking node
No Firmware Modification	Enforcement at gateway only	Sensor nodes unaware of isolation; no firmware update needed
Persistent State	Quarantine list survives gateway restart	Isolated nodes remain isolated even after service restart

Network Recovery Process

Timeline of Network Degradation and Recovery:

Timeline	Event	Network State	Data Flow Impact
T=0s	Sybil attack initiated (node starts spoofing IDs)	Network degrading	Packet loss begins
T=2-3s	First detection window (ML classifier flags Sybil)	Attack ongoing, detection complete	2-3 seconds of attack traffic
T=5-10s	Second detection window confirms (multi-window aggregation)	Isolation decision made	Total time to decision: 5-10 seconds
T=10s+	Quarantine enforcement (node blocked at gateway)	Network recovered	Legitimate traffic restored to baseline

Self-Healing Performance Metrics

Network Throughput Preservation

Condition	Baseline Throughput	During Attack	After Isolation	Recovery Status
Normal Conditions	100%	100%	100%	No degradation
Sybil Attack (5:1 ratio)	100%	73.35%	100%	Fully recovered
Harder Attack (stealthy)	100%	Variable	49.9%	Partial recovery (stealthy attacks harder to detect)
Scaled Network (100 devices)	100%	83.35%	83.35%	Maintains throughput

Advantages of Gateway-Only Isolation

Failure Scenarios & Handling

Failure Scenario	Detection	Handling	Outcome
False Positive (legitimate node quarantined)	Manual review or continuous revalidation	Quarantine can be cleared by administrator	Node rejoins network
Gateway Restart	Service restart detected	Quarantine list persisted to disk; reloaded on startup	Isolation continues seamlessly
Attacker Rejoins with New ID	New node_id classification by ML model	ML detects attack patterns again; new isolation issued	New identity also quarantined
Attacker Changes MAC Address	Behavioral pattern still detected by ML	New behavior-based features trigger detection	Isolation on new identity

Data Preparation & Feature Engineering

Overview

Comprehensive data preprocessing pipeline and WBAN-specific feature engineering designed to extract meaningful behavioral and signal-level characteristics for accurate Sybil detection. Features span four complementary domains: signal strength, timing, traffic volume, and sequence/behavioral patterns.

Data Preprocessing Pipeline

Stage	Operation	Purpose	Details
1. Data Cleaning	Remove incomplete records	Ensure data quality	Drop rows with NaN or missing critical fields (source_id, sequence_num, packet_size)
2. RSSI Handling	Impute missing signal values	Handle WiFi signal gaps	Use temporal interpolation or node-specific median RSSI for missing measurements
3. Normalization	Min-Max scaling to [0,1]	Scale features for ML compatibility	Each feature: X_scaled = (X - X_min) / (X_max - X_min). Fitted on training set, applied to test/production.
4. Train-Test Split	80% train / 20% test	Validation on unseen data	Stratified split maintains class balance (Normal:Sybil ratio preserved in both sets)
5. Class Balance Check	Verify balanced distribution	Detect dataset skew	Confirm both train and test sets have similar Normal/Sybil ratios

Complete Feature Set (19 Features)

Features extracted from raw WBAN packet captures and RSSI monitoring:

Category 1: Signal Strength (RSSI) Features

Feature	Description	Why Important for Sybil Detection	Normal Range
rssi_mean	Average WiFi signal strength (dBm)	Legitimate body sensors maintain stable signal due to fixed on-body placement. Sybil nodes may show inconsistent signal from different physical locations.	-50 to -70 dBm
rssi_std	Standard deviation of RSSI	Low std indicates stable location. High std suggests mobile/spoofed node.	< 5 dBm
rssi_min	Minimum signal strength observed	Detects signal fade events. Sybil nodes may drop below expected minimum.	-75 to -85 dBm
rssi_max	Maximum signal strength observed	Should not exceed typical on-body maximum. Sybil nodes may show unusually strong signals.	-45 to -60 dBm
rssi_frame_count	Number of RSSI measurements in window	Indicates radio activity frequency. Low count may indicate duty-cycled or silent Sybil.	50-200 frames/10s
rssi_missing	Count of missing RSSI samples	Legitimate nodes have continuous signal. Missing RSSI indicates communication gaps or spoofing.	< 5 gaps/10s

Category 2: Timing Features

Feature	Description	Why Important for Sybil Detection	Normal Range
iat_mean	Mean inter-arrival time between packets (ms)	Legitimate nodes have consistent transmission intervals (e.g., 100ms for 10 pps). Sybil attacks show irregular timing.	50-200 ms
iat_std	Standard deviation of inter-arrival times	Low std = predictable, legitimate. High std = bursty, suspicious. Sybil bursts show > 30ms variation.	< 20 ms

Category 3: Traffic Volume Features

Feature	Description	Why Important for Sybil Detection	Normal Range
pps	Packets per second (all protocols)	WBAN nodes operate at fixed rates (10-20 pps typical). Sybil floods may exceed 100 pps. Rate manipulation is key attack signature.	10-20 pps
udp_pkt_count	Count of UDP packets in window	WBAN typically uses UDP for speed. Unusual UDP volume indicates attack traffic.	100-200 UDP packets/10s

Category 4: Sequence & Pattern Features

Feature	Description	Why Important for Sybil Detection	Normal Range
seq_gap_mean	Mean gap between sequence numbers	Legitimate nodes increment monotonically (gap=1). Sybil cloning creates gaps or resets.	= 1 (no gaps)
seq_gap_max	Maximum sequence number jump	Normal: max_gap 1. Sybil attacks show gaps > 5.	< 2
seq_reset_rate	Frequency of sequence resets to 0	Indicates device restarts (boot events). Sybil nodes reset > 5x/hour.	< 2 resets/hour
dup_seq_rate	Percentage of duplicate sequence numbers	Legitimate nodes never duplicate sequence numbers. Sybil forgers create duplicates from cloned identities.	0% (no duplicates)
out_of_order_rate	Percentage of out-of-order sequence numbers	Legitimate: sequences arrive in order. Sybil attacks may cause reordering via network manipulation.	< 0.5%
boot_change_rate	Frequency of BOOT_ID changes	Device reboots infrequently under normal operation. Frequent BOOT_ID changes indicate Sybil activity or compromised device.	< 2 per hour

Experimental Scenarios

Scenario	Network Condition	RSSI / Spatial	Purpose
S0	Normal baseline	Stable distance, strong signal	Establish clean legitimate traffic baseline
S1	Normal with mobility	Varying distance, signal fading	Test robustness to legitimate signal variations (device movement)
S2	Sybil (steady rate)	Stable, consistent Sybil attack	Detect steady-rate identity cloning
S3	Sybil (steady) + mobility	Varying distance during attack	Robust detection despite signal variations
S4	Sybil (burst attacks)	Stable, high-rate flooding bursts	Detect burst-based Sybil flooding
S5	Sybil (burst) + mobility	Varying distance, burst flooding	Most challenging: combine mobility + bursty attacks

Feature Extraction Implementation

Sliding Window Approach (5-10 second windows):

Dataset Statistics

Metric	Value	Details
Total Samples	10,000+ packets	Collected across 6 scenarios, multiple runs
Legitimate Class	~60-70% of dataset	Normal device behavior baseline
Sybil Class	~30-40% of dataset	Simulated attack variations
Train Set	80% (stratified)	8,000 samples maintaining class ratio
Test Set	20% (stratified)	2,000 samples for validation
Feature Dimensionality	19 features per sample	19 x 10,000 matrix fed to ML models

Data Quality Assurance

Feature Importance Ranking (from Random Forest)

Rank	Feature	Importance Score	Interpretation
1	seq_reset_rate	0.32	Frequency of sequence resets (BOOT_ID changes). Most discriminative Sybil indicator.
2	dup_seq_rate	0.18	Duplicate sequence numbers indicate cloned identities.
3	pps (packet rate)	0.15	High packet rate indicates flooding or burst attacks.
4	rssi_std	0.12	High signal variation suggests mobile/spoofed node.
5	seq_gap_max	0.10	Large sequence jumps indicate packet loss or manipulation.
Remaining 14 features		0.13 (combined)	Supporting signals for ensemble voting

ML Model Testing & Real-World Validation

Overview

Comprehensive testing and validation of the selected Random Forest model against three risk-based scenarios and real-world WBAN data. Tests validate that the model works correctly in different network conditions and attack variations.

Testing Approach

Real-Time Data Validation Results

Validation Aspect	Test Condition	Result	Status
Real Sensor Nodes	ESP32 WBAN devices with actual sensors	Model works correctly on real hardware	PASSED
Live Attack Injection	Sybil attack launched during packet transmission	Attack detected in 2-3 seconds	PASSED
Physiological Data Integrity	Medical data transmitted under Sybil attack	100% legitimate data delivery after isolation	PASSED
Gateway Processing	Model inference on live traffic stream	<5ms latency maintained under load	PASSED
False Positive Rate	Extended baseline monitoring (24+ hours)	<0.5% FPR in production conditions	PASSED

WBAN-Specific Features vs Generic Network Features

Our WBAN-Specific Approach

Our Feature Category	Example Features	Why It Works for WBAN	Applicability
Signal Strength (RSSI)	rssi_mean, rssi_std, rssi_min, rssi_max	On-body sensors maintain stable signal. Sybil nodes show inconsistent RSSI from different physical locations.	DEPLOYABLE
Timing (IAT)	iat_mean, iat_std (inter-arrival times)	WBAN nodes transmit at fixed intervals (e.g., 100ms for sensor data). Sybil attacks show erratic timing.	DEPLOYABLE
Network Behavior	pps, packet_size, protocol_type	Legitimate devices follow predictable transmission patterns. Attackers show anomalous behavior.	DEPLOYABLE
Sequence Integrity	seq_gap_mean, seq_reset_rate, dup_seq_rate	Devices increment sequence numbers monotonically. Cloned identities create sequence anomalies.	DEPLOYABLE

Key Validation Metrics

Stage 5: Real-World Deployment & Validation

Objectives

• Deploy Random Forest model on actual WBAN testbed (ESP32 nodes)
• Validate performance metrics on live network traffic
• Confirm model works with real physiological sensor data
• Generate production deployment artifacts

Real-World Test Results

Deployment Artifacts

Validation Summary

Aspect	Status	Details
Model Accuracy		99.59% F1-Score on real data
Edge Device Ready		<1ms inference, 45MB model
Real-World Tested		Validated on WBAN sensor data
Deployment Scripts		Flask API & mobile gateway code

Final Model Selection & Complete Justification

<5ms per prediction 0.86ms PASS (5.8x faster) Model Size <100 MB 45 MB PASS Edge Deployment No GPU required CPU only PASS Robustness Generalizes well 300 trees, low overfit PASS Interpretability Explainable decisions Feature importance ranking PASS

Why Other Architectures Were REJECTED

Model Comparison Matrix

Model	F1-Score	Inference	Throughput	Model Size	GPU Required	Accuracy vs RF	Selected
Random Forest	99.59%	0.86ms	307k/sec	45 MB	No	BASELINE	YES
Gradient Boosting	99.7%	5-8ms	125k-200k/sec	52 MB	No	+0.11%	NO
XGBoost	99.85%	3-5ms	200k-333k/sec	50 MB	No	+0.26%	NO
MLP Neural Net	98.9%	2-4ms	250k-500k/sec	120 MB	Preferred	-0.69%	NO
Logistic Reg	97.51%	0.0012ms	833k+/sec	5 MB	No	-2.08%	NO
Ensemble Vote	99.59%	3-5ms	200k-333k/sec	225 MB	No	0% (same)	NO

Research Evidence: Why Random Forest

Layer-by-Layer Detection Architecture & Prediction Rates

Complete 3-Layer Detection System

Layer 1: ML Ensemble Prediction (Random Forest)

Component	Description	Details
Input	19 WBAN Features	Packet rate, WiFi signal strength, resets, connection patterns, protocol diversity, traffic volume, etc.
Model	Random Forest (300 trees)	max_depth=15, min_samples_leaf=5, class_weight='balanced' for balanced detection
Decision Process	Voting Ensemble	Each of 300 trees votes Normal or Sybil. Majority vote determines prediction (0-1 probability)
Output	Probability Score (0-1)	0.0 = Definitely Normal | 0.5 = Uncertain | 1.0 = Definitely Sybil
Accuracy Rate	99.9% (Training)	99.59% (Real-world Stage 5)
Inference Time	0.86ms per prediction	Capable of 307,000+ predictions per second

Layer 2: Confidence Thresholding Decision Gate

Confidence Level	Score Range	Action	Accuracy	Cases in This Range
High Confidence	0.95	DIRECT DECISION	99.8%+	~75-80% of predictions
Moderate Confidence	0.85 - 0.94	VERIFY	98.5%+	~15-20% of predictions
Low Confidence	< 0.85	ESCALATE TO LAYER 3	95-97%	~5-10% of predictions

Layer 3: Feature-Based Rule Engine (For Low-Confidence Cases)

When Layer 1 confidence is <85%, Layer 3 applies evidence-based rules:

Rule	Feature(s)	Normal Behavior	Sybil Behavior	Confidence Boost
Boot ID Resets	Boot ID changes	Rarely changes (<2x/hour)	Frequent resets (>5x/hour)	+15%
Connection Rate	Connection frequency	Stable, predictable pattern	Random, erratic connections	+12%
Protocol Usage	Protocol diversity	Uses consistent protocols	Switches protocols randomly	+10%
Signal Strength	WiFi signal RSSI	Stable signal (-50 to -70dBm)	Fluctuating signal (>20dBm swing)	+8%
Packet Timing	Inter-packet delays	Consistent timing	Irregular timing patterns	+10%

Combined Detection Architecture Accuracy

Scenario	Layer 1 Confidence	Path Taken	Additional Checks	Final Accuracy	Total Time
High-Confidence	95%	Direct Output (Layer 1)	None	99.8%+	0.86ms
Moderate Confidence	85-94%	Feature Verification (Layer 2)	1-2 feature checks	98.5%+	1.5-2.0ms
Low Confidence	< 85%	Rule Engine (Layer 3)	All 5 behavioral rules	97-99%	2.5-3.5ms
OVERALL SYSTEM	Multi-layer detection averaging across all real-world cases			99.59% F1	< 5ms avg

Real-World Prediction Distribution

Based on Stage 5 validation dataset (10,000+ real WBAN packets):

Detection Category	Percentage	Count	Processing Path	Accuracy
Layer 1 Direct (95% conf)	76.2%	~7,620 packets	Fast path (0.86ms)	99.85%
Layer 2 Verified (85-94%)	18.5%	~1,850 packets	Verify path (1.5-2.0ms)	99.20%
Layer 3 Rules (<85%)	5.3%	~530 packets	Rule path (2.5-3.5ms)	98.10%
ALL DETECTIONS	100%	10,000	Weighted average	99.59% F1

Technical Implementation: Self-Healing Sybil Mitigation Framework

The proposed self-healing Sybil attack mitigation framework was implemented as a gateway-based network monitoring and detection system, focusing on network-level and physical-layer (RSSI) contextual features. The design emphasizes practical deployment in WBAN/IoMT environments with minimal overhead and real-time responsiveness.

A. System Architecture and Technology Stack

The system follows a centralized gateway architecture, consisting of three primary layers:

B. Dataset Collection Approach

The dataset was generated through controlled real-world experiments, rather than purely synthetic simulation.

C. Sybil Attack Implementation

Sybil attacks were implemented using additional ESP32 nodes configured with malicious behavior.

These behaviors were designed to mimic realistic attackers attempting to evade detection.

D. Feature Extraction

The system extracts features from two primary domains:

Cross-Layer Integration: The combination of network and physical-layer features enables cross-layer analysis, improving detection robustness by leveraging multiple information sources.

E. Dataset Construction and Labeling

Collected data was processed into structured datasets:

• udp_packets.csv - Network-level features from gateway collector
• rssi.csv - Signal strength data from wireless sniffer

Datasets were labeled based on experimental setup:

• Legitimate nodes: normal behavior patterns
• Sybil nodes: cloned identity and anomalous behavior
• Labeling performed at node level and aligned with timestamps

F. Machine Learning Model Integration

A supervised machine learning model (Gradient Boosting) was trained using extracted features.

G. Real-Time Detection and Decision Logic

To reduce false positives and improve reliability, a temporal filtering mechanism is applied:

H. Self-Healing Enforcement Mechanism

Once a node is identified as malicious, the gateway enforces isolation autonomously:

Enforcement Action	Description	Latency
Packet Filtering	Dropping incoming packets from quarantined node	<1ms
Node Quarantine	Blocking further participation in network	<1ms
State Persistence	Maintaining enforcement over time	Continuous
Traffic Blocking	Zero recovery time from decision to blocking	<1ms

Deployment Model: Gateway-level enforcement only requires no sensor node firmware modification, enabling full backward compatibility with existing WBAN deployments.

Implementation Advantages