Horizontal Federated Learning (HFL) is a distributed training topology where all participating clients record the same types of attributes—an identical feature space—but collect data about entirely different entities or users—a disjoint sample space. This scenario commonly arises when different telecom base stations measure the same signal quality metrics for distinct subscriber populations, or when regional banks track identical transaction features for separate customer bases. The architectural alignment of features allows local models to share an identical neural network structure, making Federated Averaging (FedAvg) the standard aggregation algorithm for combining locally computed weight updates into a globally improved model without ever centralizing raw user records.
Glossary
Horizontal Federated Learning

What is Horizontal Federated Learning?
A distributed machine learning paradigm where participating datasets share the same feature space but contain different sample spaces, enabling collaborative model training across organizations with identical data schemas but non-overlapping user bases.
The primary technical challenge in HFL is statistical heterogeneity, where the underlying data distributions vary significantly across client silos despite the shared schema. A base station in a dense urban core may observe drastically different traffic patterns than one in a rural area, violating the independent and identically distributed (IID) assumption of standard optimization. To address this, frameworks like FedProx introduce a proximal term to local objective functions, stabilizing convergence by preventing local updates from diverging too far from the global model. This makes HFL a critical privacy-preserving architecture for cross-silo federated learning in regulated industries, enabling collaborative intelligence across organizational boundaries while maintaining strict data sovereignty compliance.
Key Characteristics of Horizontal Federated Learning
Horizontal Federated Learning (HFL) is defined by a shared feature space across participants who hold records for different user populations. This architectural pattern is the most common topology for cross-silo telecom deployments where base stations collect identical metrics for distinct subscribers.
Shared Feature Space
The fundamental prerequisite for HFL is that all participating clients must agree on a common data schema. Every base station or client node records the same set of features—such as Reference Signal Received Power (RSRP) , Signal-to-Interference-plus-Noise Ratio (SINR) , and throughput metrics—but for entirely different user equipment (UE) populations.
- Structural Homogeneity: The column names, data types, and semantic meanings are identical across all silos.
- Sample Heterogeneity: The row entries represent distinct, non-overlapping user groups.
- This alignment allows a global neural network architecture to be defined centrally and deployed to all clients without modification.
User-Sample Partitioning
Data is partitioned by sample ID rather than by attribute. In a telecom context, Operator A and Operator B both record the same call detail records and channel quality indicators, but Operator A's data represents subscribers in Berlin while Operator B's data represents subscribers in Munich.
- No Entity Overlap: A specific IMSI (International Mobile Subscriber Identity) appears in only one client's dataset.
- Vertical Complement: This contrasts directly with Vertical Federated Learning, where the same users are described by different attributes across organizations.
- This topology naturally fits geographically distributed RAN deployments where user mobility is tracked within a single operator's network.
Federated Averaging (FedAvg) Compatibility
HFL is the native topology for the standard Federated Averaging algorithm. Because local models share an identical architecture, the central server can perform a weighted element-wise average of the model weights received from participating clients.
- Weighted Aggregation: Updates are typically weighted by the number of local training samples to account for dataset size imbalances.
- Convergence Stability: Shared feature distributions generally lead to smoother global loss landscapes compared to non-IID label distributions.
- The aggregation step is mathematically straightforward:
w_global = Σ (n_k / n_total) * w_kfor each client k.
Non-IID Label Distributions
Despite sharing a feature space, HFL systems frequently suffer from statistical heterogeneity in label distributions. A base station in a dense urban area may experience a radically different mix of traffic classes—streaming video versus IoT telemetry—compared to a rural macrocell.
- Label Distribution Skew: The prior probability
P(y)of a specific traffic type or mobility pattern varies significantly per client. - Concept Drift: The relationship between features and labels may also shift geographically due to different interference patterns.
- Mitigation often requires advanced optimization frameworks like FedProx or SCAFFOLD to correct for client drift during local training.
Cross-Silo Telecom Deployment
In production RAN intelligence, HFL is almost exclusively deployed in a cross-silo configuration. The clients are not millions of smartphones but a manageable number of O-RAN Central Units (O-CUs) or Distributed Units (O-DUs) with reliable power and high-bandwidth backhaul.
- Stateful Clients: Each base station node is always available and can maintain state across training rounds.
- Trusted Execution: Operators often combine HFL with Trusted Execution Environments (TEEs) on RAN Intelligent Controller (RIC) hardware to protect model integrity.
- This contrasts with cross-device HFL, which is impractical for latency-sensitive radio resource management tasks.
Privacy-Preserving Model Updates
HFL protects data sovereignty by ensuring raw call traces and measurement reports never leave the base station. Only encrypted or differentially private gradient updates are transmitted to the central aggregation server.
- Secure Aggregation: A cryptographic protocol ensures the server can only compute the sum of updates, not inspect individual contributions.
- Differential Privacy: Calibrated Gaussian noise is added to gradients before transmission, bounding the influence of any single user's data.
- This architecture satisfies GDPR and telecom regulatory requirements by decoupling model training from data centralization.
Frequently Asked Questions
Clarifying the architecture, use cases, and privacy implications of the most common federated learning topology for telecom data.
Horizontal Federated Learning (HFL) is a distributed machine learning paradigm where participating datasets share the same feature space but contain different sample spaces. In a telecom context, this means multiple base stations record the same types of metrics—such as signal strength, handover success rates, and throughput—but for entirely different user populations. The process works by distributing a global model to each client, training locally on private data, and sending only encrypted model updates to a central aggregation server. The server combines these updates using algorithms like Federated Averaging (FedAvg) to produce an improved global model without ever accessing raw user data. This architecture is particularly suited for cross-silo deployments among mobile network operators who share identical network telemetry schemas but serve geographically distinct subscriber bases.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Horizontal Federated Learning is one of several topologies for distributed model training. Understanding these related architectures is critical for selecting the correct privacy-preserving strategy based on how data is partitioned across telecom base stations or organizational silos.
Vertical Federated Learning
The complementary topology to Horizontal Federated Learning where datasets share the same sample space but differ in their feature space. In a telecom context, this occurs when a mobile operator and a financial institution hold different attributes about the same set of subscribers. Training requires entity alignment to match records across silos before performing split neural network computation, often using privacy-preserving record linkage and secure multi-party computation to prevent feature leakage.
Federated Transfer Learning
A hybrid topology applied when datasets differ in both sample space and feature space, with only partial overlap. This is common when two telecom operators in different regions serve entirely distinct user bases and collect slightly different network metrics. The technique leverages transfer learning to adapt a pre-trained base model to the target domain using limited overlapping data, minimizing the need for large labeled datasets in the target silo.
Cross-Silo Federated Learning
The institutional deployment model typically used for Horizontal Federated Learning in telecom. Involves a small number of reliable participants—such as regional base station clusters or operator data centers—with stable connectivity and substantial compute resources. Unlike cross-device settings, these silos are stateful and identified, enabling synchronous aggregation rounds and stronger security guarantees through Trusted Execution Environments.
Non-IID Data Challenge
The primary statistical obstacle in Horizontal Federated Learning. When different base stations serve demographically distinct user populations, the local data distributions diverge significantly from the global distribution. This statistical heterogeneity causes local models to drift apart during training, slowing global convergence. Mitigation strategies include:
- FedProx: Adds a proximal term to local objectives
- SCAFFOLD: Corrects client-drift using control variates
- Personalized FL: Balances global and local model performance
Secure Aggregation
A cryptographic protocol essential for Horizontal Federated Learning deployments where the central server must compute the weighted average of model updates without inspecting any individual base station's gradient contributions. The server learns only the aggregated sum, protecting against gradient leakage attacks that could reconstruct user mobility patterns. Often combined with differential privacy to provide formal privacy guarantees against curious-but-honest aggregators.
Split Learning
An alternative to Horizontal Federated Learning where the neural network is partitioned between client and server. The base station processes initial layers on raw call detail records and transmits only intermediate activations (smashed data) rather than model updates. This reduces client-side computational burden and provides stronger raw data isolation, but introduces sequential training dependencies that can increase wall-clock training time compared to parallel federated averaging.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us