On-Device Dataset

The most defining characteristic of an on-device dataset is that the raw data never leaves the physical device. This is the core privacy guarantee of federated learning. The data is generated, stored, and processed locally, with only encrypted mathematical updates (like gradients or weight deltas) being shared. This is critical for applications involving personal user interactions, proprietary industrial sensor readings, or regulated health data where centralization poses legal and ethical risks.

On-device data is almost never Independent and Identically Distributed (IID). Each device's dataset reflects its unique environment and user. For example:

• A fitness tracker in Sweden will have different temperature and activity data than one in Singapore.
• A keyboard on a programmer's phone will have a different word distribution than one on a journalist's phone. This non-IID data distribution is the primary challenge in federated learning, as it can cause model divergence and slow convergence, requiring specialized optimization algorithms like Federated Averaging (FedAvg) with client weighting.

On TinyML devices, datasets are bounded by severe hardware limits:

• Memory (RAM/Flash): The entire dataset must fit in the device's limited volatile and non-volatile memory, often measured in kilobytes to a few megabytes. This prohibits storing large historical archives.
• Compute: Processing the dataset for local training is constrained by the MCU's clock speed and lack of a dedicated GPU, limiting model and batch sizes.
• Energy: Reading from memory and performing computations directly drains the energy budget. Data collection and training must be scheduled to balance utility with battery life.

On-device datasets are not static; they are built from continuous sensor data streams or user interactions. This creates a temporal dimension where data distribution can drift over time (e.g., a sensor's environment changes with seasons). It enables online or continual learning paradigms where the model adapts to new patterns. However, it also introduces challenges like managing dataset size (e.g., FIFO buffers) and handling the cold-start problem where a new device has insufficient initial data for effective training.

A significant portion of on-device data is unlabeled. Manually labeling sensor streams (e.g., identifying specific sounds or motion patterns) is infeasible at scale. This drives the use of:

• Self-supervised learning techniques that generate labels from the data's structure.
• Weak supervision using heuristic rules or other sensor modalities as proxy labels.
• Federated learning with scarce labels, where only a small subset of clients may have labeled data, requiring algorithms that can leverage both labeled and unlabeled datasets across the network.

The dataset's composition is dictated by the device's sensors and its specific inference task, often combining multiple data types:

• A wake-word detection device collects audio time-series.
• An industrial predictive maintenance sensor collects vibration, temperature, and current readings.
• A smartphone may use typing patterns, accelerometer data, and app usage logs for personalization. This multi-modal nature requires on-device preprocessing pipelines to align and fuse different data streams into a format usable by the model, all within the device's resource envelope.

The most common on-device dataset type, consisting of continuous, time-series readings from embedded sensors. These are raw, unlabeled, and generated in real-time.

Examples include:

• Inertial Measurement Unit (IMU) Data: Accelerometer, gyroscope, and magnetometer readings for activity recognition (e.g., step counting, fall detection).
• Environmental Sensors: Temperature, humidity, air quality (VOC), and barometric pressure logs.
• Acoustic Data: Raw audio waveforms or Mel-frequency cepstral coefficients (MFCCs) for keyword spotting or anomaly detection.

Key Constraint: Data volume is bounded by the device's limited non-volatile storage (Flash memory), often requiring circular buffers or aggressive compression.

Datasets composed of implicit and explicit feedback from a device's primary user, enabling highly personalized model adaptation.

Examples include:

• Touchscreen Gestures & Typing Patterns: For adaptive keyboards or UI personalization.
• App Usage Statistics & Feature Preferences: Sequences of actions within a mobile or embedded application.
• Voice Command History: Successful and failed interactions with a local voice assistant.

Privacy Imperative: This data is highly sensitive and must never leave the device raw. Federated learning protocols like Secure Aggregation are designed to learn from these logs without central collection.

Data generated by the device's own systems, capturing its health, performance, and failure modes. This dataset is critical for predictive maintenance and self-healing applications.

Examples include:

• Power State Transitions: Records of sleep/wake cycles and battery voltage levels.
• Thermal Profiles: Processor temperature logs correlated with compute load.
• Wireless Link Quality: Histograms of signal strength (RSSI) and packet loss rates.
• System Exception Dumps: Context around crashes or faults.

This data is inherently non-IID (Non-Independently and Identically Distributed) across a device fleet, as each unit experiences unique environmental and usage stresses.

Artificially generated or transformed data created on-device to overcome local data scarcity. This is a key technique for on-device continual learning.

Methods include:

• Data Augmentation: Applying real-time transformations (e.g., time-warping, adding noise, scaling) to existing sensor samples to create new training examples.
• Generative Model Inference: Using a tiny, pre-loaded generative adversarial network (GAN) or diffusion model to create plausible synthetic samples that respect the local data distribution.
• Simulation via Digital Twin: If the device has a physics-based model of its environment, it can generate simulated sensor readings for rare edge cases.

This approach directly addresses the cold-start problem in federated edge learning.

The specialized data types exchanged during the federated learning process, which are derived from—but do not contain—the raw on-device dataset.

Core Artifacts:

• Model Updates (ΔW): The difference between the model parameters before and after local training. This is a mathematical summary of learning from the local dataset.
• Training Metadata: Scalars like the number of local training steps (E) and the size of the local dataset (n_k), used for weighted averaging in algorithms like Federated Averaging (FedAvg).
• Sparse Gradients: For communication efficiency, clients may send only the top-k% of gradient values by magnitude, creating a sparse update.

These artifacts are the only information about the local dataset that is transmitted to the coordinating server.

A fundamental distinction in how on-device datasets are managed, dictated by memory constraints and data relevance.

Ephemeral (In-Memory) Datasets:

• Storage: Volatile RAM only.
• Use Case: Streaming learning where the model trains on a continuous, real-time sensor feed. Data is processed in small batches and then discarded.
• Challenge: Requires extremely efficient algorithms to learn from a data window before it vanishes.

Persistent (Flash) Datasets:

• Storage: Non-volatile Flash memory.
• Use Case: Learning from rare events (e.g., a machine fault) or user habits that develop over days/weeks. Data is stored in a managed buffer.
• Challenge: Flash memory has limited write cycles (endurance), making frequent saves unsustainable. Techniques like wear leveling are essential.