Inferensys

Glossary

Horizontal Federated Learning

A federated learning topology where participating datasets share the same feature space but contain different sample spaces, enabling collaborative model training without centralizing raw data.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
DEFINITION

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.

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.

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.

SAMPLE ALIGNMENT

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.

01

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.
Identical Schema
Feature Alignment
02

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.
Disjoint
Sample Spaces
03

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_k for each client k.
Weighted Mean
Aggregation Operator
04

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.
Label Skew
Primary Challenge
05

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.
O-RAN Nodes
Typical Clients
06

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.
Data Locality
Privacy Guarantee
HORIZONTAL FEDERATED LEARNING

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.

Prasad Kumkar

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.