Federated predictive load balancing for adaptive resource management in fog computing
While the advantages of fog computing in delivering low-latency Internet of Things (IoT) applications are well understood, efficient load balancing remains a constant challenge due to the diversity of node capabilities and the uncertainty of workloads. Current scheduling methods are typically reactive and only take action once they detect congestion, and require gathering data centrally, which can be privacy and bandwidth sensitive. In this paper, a Federated Predictive Load Balancing (FPLB) framework is proposed to combine Long Short-Term Memory (LSTM) workload forecasting with federated learning, which does not require fog nodes to share their operational data. Predicted workloads feed a normalized load index for proactive task assignment, while a differential-privacy mechanism with a Rényi accountant protects model updates during federated aggregation. All experiments are reported from a self-contained simulator. Across eight independent seeds under a moderate-to-high load, FPLB attains the lowest average task latency (149.2 ms), significantly below Deep Q-Network (DQN) scheduling (1.6% reduction; p < 0.01, Wilcoxon signed-rank) and a federated-DQN control, and well below reactive heuristics (24.3% below round-robin). The margin widens with load, reaching 2.9% over DQN at 10 tasks/s, and FPLB’s latency variance is consistently the lowest, indicating more predictable scheduling. An ablation confirms that workload prediction is the primary driver of the improvement and that federation lowers prediction error. Federated communication overhead is 0.4% of network traffic at 50 nodes, rising to only 3.7% at 500 nodes, and performance is robust to 30% per-round node dropout. This paper further characterizes the privacy-utility envelope as the budget tightens from \documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$\:\epsilon\:$$\end{document} = 3.2 to 0.5. At low load, where congestion is rare, DQN is comparable, so the framework is most valuable for deployments that regularly experience dynamic or peak-heavy demand.