Federated Device Registry

This is the immutable hardware and software fingerprint of a device, stored upon enrollment. It defines the absolute constraints for local training.

Key attributes include:

• Processor Architecture: CPU type, core count, presence of NPU/GPU.
• Memory Hierarchy: Total RAM, persistent storage capacity.
• Operating System & Framework Support: e.g., Android, Linux, TensorFlow Lite Micro.
• Power Source: Battery-powered, mains-powered, or energy-harvesting.

This profile determines if a device is eligible for specific model architectures or training tasks.

A real-time view of a device's transient conditions, which dictate its immediate availability and capacity for a training round.

Monitored metrics include:

• Compute Load: Current CPU/GPU/NPU utilization.
• Memory Pressure: Available RAM and storage.
• Power Status: Battery percentage and charging state.
• Network Connectivity: Bandwidth, latency, and data cost.
• Thermal State: Device temperature to predict throttling.

This state is polled or pushed by an on-device agent and is critical for resource-aware scheduling.

A chronological record of a device's participation, used for predictive scheduling and anomaly detection. This ledger builds a reliability score.

Tracked history includes:

• Task Completion Rate: Success/failure of assigned training rounds.
• Update Quality: Magnitude and staleness of submitted gradients.
• Resource Consumption: Historical compute time and energy used per task.
• Latency Profiles: Typical time to complete a round of local epochs.

This data allows the orchestrator to prefer reliable, efficient clients and identify potentially malicious or faulty devices.

The rule engine that applies system-wide and per-device policies to ensure operational integrity and compliance.

It governs:

• Participation Windows: Only allowing training during user-defined idle periods.
• Resource Caps: Enforcing limits on CPU usage, data uploads, or energy drain per day.
• Data Sovereignty Rules: Ensuring device data and updates never cross specified geographic boundaries.
• Regulatory Compliance: Logging for audits under frameworks like GDPR or the EU AI Act.

This component acts as the gatekeeper, preventing the system from violating user trust or legal constraints.

The API layer that allows the Federated Learning Orchestrator to query and command the device pool. It translates high-level training goals into actionable device assignments.

Core functions include:

• Client Selection Queries: Finding devices matching specific capability and state filters (e.g., SELECT devices WHERE battery > 30% AND has_NPU = TRUE).
• Task Dispatch: Assigning model download URLs, training hyperparameters, and deadlines.
• Update Collection: Receiving and validating model updates or failure notifications.
• Health Checks: Initiating pings to refresh dynamic state for idle devices.

This is the primary integration point between the registry and the training logic.

Manages the cryptographic identity and secure lifecycle of each device in the federation. This is foundational for trust in a decentralized system.

Its responsibilities are:

• Device Attestation: Verifying the hardware's genuine identity during enrollment using hardware roots of trust.
• Credential Management: Issuing and rotating authentication tokens for secure communication with the aggregation server.
• Integrity Verification: Ensuring the device's local training environment has not been tampered with before accepting its updates.
• Secure De-registration: Revoking credentials and removing device profiles when they leave the network or are compromised.

This module prevents Sybil attacks and ensures updates originate from authenticated, legitimate clients.

The foundational process of measuring and cataloging the static and dynamic attributes of an edge device for the registry. This creates the detailed profile the registry stores.

• Static Attributes: CPU/GPU/NPU type, total RAM, storage, OS version.
• Dynamic Attributes: Available memory, battery level (%), network bandwidth, thermal state, current CPU load.
• Purpose: Informs every downstream decision, from client selection to model partitioning, by providing a real-time snapshot of device readiness.

The orchestration strategy that uses data from the device registry to intelligently assign training tasks. It matches workload demands to device capabilities in real-time.

• Key Input: Profiles from the Federated Device Registry.
• Decision Logic: Avoids assigning large models to memory-constrained devices; prioritizes well-charged, cool devices for intensive rounds.
• Outcome: Maximizes round completion rates and system efficiency by preventing out-of-memory errors and excessive latency.

A client selection method that uses registry data to ensure a statistically representative mix of device types participates in each training round.

• Problem: Random selection can bias the global model towards the capabilities of the most powerful, frequently available devices.
• Solution: The sampler queries the registry to select clients from pre-defined strata (e.g., 'high-end mobile', 'mid-tier IoT', 'constrained sensor').
• Benefit: Produces models that are robust and fair across the entire heterogeneous population, not just the premium tier.

A communication protocol that decouples client progress from synchronized rounds, directly leveraging device availability and capability data from the registry.

• How it works: Clients train and send updates whenever they finish. The server aggregates updates immediately upon receipt using techniques like weighted averaging based on staleness.
• Registry Role: The server uses the registry to understand why an update is stale (e.g., device was offline, computationally slow) and adjust aggregation weights accordingly.
• Advantage: Accommodates devices with highly variable training times and intermittent connectivity, improving overall resource utilization.

A set of standards that enables reliable training on devices with unstable networks, with state managed in coordination with the device registry.

• Core Functions: Update caching, training session checkpoint/resume, and efficient differential synchronization.
• Registry Integration: The device's profile in the registry would flag it with a connectivity_quality: low tag. The protocol uses this to:
  • Pre-fetch models during high-bandwidth windows.
  • Compress updates more aggressively before transmission.
  • Maintain a longer update cache on the device.
• Result: Devices with poor or expensive cellular links can still participate effectively without wasting bandwidth or dropping out.

The lightweight client-side agent that generates the dynamic data populating the Federated Device Registry. It is the source of truth for real-time device state.

• Metrics Tracked:
  • Compute: CPU/GPU/NPU utilization (%)
  • Memory: Available RAM (MB)
  • Power: Battery level (%), charging status
  • Thermal: SoC temperature (°C)
  • Network: Current bandwidth (Mbps), latency (ms)
• Data Flow: Continuously samples metrics → packages them into a heartbeat or status update → transmits to server for registry ingestion.
• Critical Role: Enables proactive management (e.g., pausing training on an overheating device) before a failure occurs.