TimeTrack: Telemetry Dataset for Cloud-Edge Forecasting
- TimeTrack is a public, high-resolution telemetry dataset collected from a physical 5G testing cluster to capture multivariate resource metrics.
- It provides foundational structural patterns to mitigate cold‐start issues by merging dense telemetry with sparse local data during Neural Architecture Search.
- TimeTrack is distinct from similarly named systems as it focuses solely on dataset provision rather than on predictive models or video tracking frameworks.
Searching arXiv for papers relevant to “TimeTrack” and closely related naming variants to ground the article. I’m going to look up arXiv entries for “TimeTrack”, “TimeTracker”, and “Time Tracker” to confirm the relevant paper identities and naming distinctions. TimeTrack is a high-resolution multivariate telemetry dataset introduced as the central “foundational” dataset in “Zero Touch Predictive Orchestration: Automating Time-Series Models for the Cloud-Edge Continuum” (Meliani et al., 8 Jun 2026). In that work, it is used to mitigate the cold-start problem for forecasting on newly discovered cloud-edge nodes by contributing dense structural temporal patterns that are then combined with sparse node-local telemetry before Neural Architecture Search (NAS). TimeTrack is a dataset rather than a forecasting model or a physical tracking system. It should be distinguished from “TimeTracker,” an event-based video frame interpolation method (Liu et al., 6 May 2025), and from “Time Tracker,” a foundation model for time-series forecasting (Shi et al., 21 May 2025).
1. Definition and intended role
TimeTrack is presented as a public, high-resolution telemetry corpus collected from a physical OpenAirInterface (OAI) Kubernetes testing cluster used for CI/CD of 5G components such as gNB, UE, and core network functions (Meliani et al., 8 Jun 2026). Its primary purpose is to serve as a structural prior for forecasting in volatile cloud-edge environments where a newly discovered node lacks enough historical data to train a reliable localized predictor.
The motivating problem is a severe cold-start generalization failure in predictive orchestration. A model trained only on generic historical traces may perform poorly on a newly discovered edge node because hardware characteristics, usage patterns, and microservice behavior differ from those of the source data. Conversely, collecting enough target-specific history to train from scratch takes too long in settings where nodes may appear, disappear, or change state rapidly. TimeTrack is introduced to bridge that gap by providing dense “foundational structural patterns,” while a smaller amount of target-local telemetry provides “node-specific contextual calibration” (Meliani et al., 8 Jun 2026).
The paper explicitly contrasts this role with coarse public traces sampled at 5-minute intervals. It argues, conceptually invoking the Shannon–Nyquist sampling theorem, that coarse telemetry can undersample meaningful high-frequency dynamics and smooth away transient bursts, microservice scaling events, and short-lived spikes. TimeTrack’s 45-second cadence is presented as a practical compromise between preserving short-term structure and limiting monitoring overhead (Meliani et al., 8 Jun 2026).
A common misconception is to treat TimeTrack itself as the predictive model. The paper does not do this. TimeTrack is the dataset inside a larger Zero Touch Predictive Orchestration pipeline composed of telemetry exposure, data mixing, and NAS-based model generation (Meliani et al., 8 Jun 2026).
2. Collection context and dataset characteristics
TimeTrack was collected from a physical OAI Kubernetes cluster rather than a virtualized environment. The paper repeatedly emphasizes that this matters because it avoids virtualization artifacts and better reflects real hardware behavior (Meliani et al., 8 Jun 2026).
| Property | Value | Source detail |
|---|---|---|
| Machines | 7 | Physical machines |
| Duration | 30 days | Continuous collection |
| Sampling interval | 45 seconds | High-resolution telemetry |
| CPU cores | 236 | Aggregate across cluster |
| RAM | 437.5 GB | Aggregate |
| SSD storage | 1800 GB | Aggregate |
| Network interfaces | 38 | Physical interfaces |
Per-node resource distribution is given explicitly. The machine core counts are 36, 48, 36, 36, 24, 36, and 20. Each machine has 62.5 GB RAM. Disk capacities range from 222.50 GB to 278.37 GB, and interfaces per node range from 4 to 6 (Meliani et al., 8 Jun 2026).
The telemetry is multivariate and operationally broad. The paper lists compute metrics such as available and used memory and read/write disk throughput at cluster and machine levels; per-core CPU utilization for all 236 cores; network latency metrics including minimum, maximum, average, and mean deviation of RTT, plus jitter; and network interface metrics including dropped packets, error rates, and transmitted and received throughput (Meliani et al., 8 Jun 2026). In the dataset comparison table, TimeTrack is classified as containing compute, network, and storage metrics with high detail level over 7 physical machines at 45-second resolution for 30 days (Meliani et al., 8 Jun 2026).
Collection reused the same Resource Exposer plugin mechanism used in the orchestration architecture, specifically interfacing with Prometheus (Meliani et al., 8 Jun 2026). The dataset is explicitly stated to be publicly available via Kaggle and Zenodo, and the paper reports approximately 700 downloads in less than a year across both platforms (Meliani et al., 8 Jun 2026).
The paper positions TimeTrack against alternatives such as Google Cluster Data, Alibaba Cluster Traces, Azure traces, and GWA Materna, all cited there as 5-minute datasets. Since $300$ seconds divided by $45$ seconds is approximately $6.67$, TimeTrack yields about more samples over the same wall-clock period (Meliani et al., 8 Jun 2026).
3. Position inside Zero Touch Predictive Orchestration
Within the larger architecture, TimeTrack is used after target telemetry has already been exposed by a lightweight Resource Exposer (RE). The RE is a plugin-based, gRPC monitoring agent deployed close to the infrastructure. It can interface with Prometheus, Nagios, Nvidia GPU exporters, and others; periodically collects telemetry; stores it in a lightweight broker such as RabbitMQ, Kafka, or Redis; and exposes the latest metrics through a northbound API. RE instances self-register via local DNS to a centralized discovery module, and the broker is automatically purged after inactivity to conserve memory on constrained edge nodes (Meliani et al., 8 Jun 2026).
After this exposure step, sparse telemetry from a newly discovered target node is merged with TimeTrack. The paper does not provide a formal mixing equation and does not specify whether the merge operator is concatenation, interleaving, domain-tagged union, or curriculum ordering. What it does state consistently is that TimeTrack contributes “foundational structural patterns,” while the local data contributes “node-specific contextual calibration” (Meliani et al., 8 Jun 2026).
The resulting mixed data are then processed by a NAS-driven training workflow implemented with Microsoft NNI. The search space spans MLP, RNN, LSTM, GRU, CNN, TCN, and Transformer architectures, with hyperparameters including units , number of layers , dropout , activation , learning rate sampled log-uniformly over , window size , batch size $45$0, epochs $45$1, kernel size $45$2, and attention heads $45$3. Search strategies include Grid Search, Random Search, TPE, Evolutionary Algorithm, and Simulated Annealing (Meliani et al., 8 Jun 2026).
The paper positions this system as solving the initialization phase of continuous learning. Existing MLOps pipelines are described as often assuming a model already exists and then focusing on retraining, whereas this framework uses TimeTrack plus sparse local telemetry to automatically produce a strong initial baseline model for a previously unseen node (Meliani et al., 8 Jun 2026).
4. Forecasting protocol and empirical performance
The main evaluation uses CPU usage forecasting, even though TimeTrack itself is multivariate. The paper states that CPU-only forecasting was chosen to keep the comparison of source datasets controlled, despite the broader availability of compute, network, and storage telemetry (Meliani et al., 8 Jun 2026). Forecasting is evaluated from 1 step ahead to 5 steps ahead, with the native cadence of TimeTrack implying that one step corresponds to 45 seconds in that dataset.
Seven data scenarios are compared: local_only, tt_only, mat_only, ali_only, local_plus_tt, local_plus_mat, and local_plus_ali (Meliani et al., 8 Jun 2026). In the controlled NAS experiments, the mixed setting uses a hard budget of 1,500 samples: 1,000 samples from a generic dataset and 500 local samples. In the sensitivity study, the local portion varies from 10 to 500 samples while the TimeTrack contribution remains 1,000 structural samples (Meliani et al., 8 Jun 2026).
The generic-only baselines show a strong difference in dataset quality. For Alibaba-only at 300 seconds of NAS search, MAPE ranges from 33.09% under Evolutionary search to 57.49% under Grid Search, with a cited poor case of $45$4. Materna-only is similarly weak, at roughly 33.67%–34.01% MAPE. By contrast, TimeTrack-only stabilizes around 22.12%–22.28% MAPE under TPE and Simulated Annealing. Local-only still slightly outperforms TimeTrack-only when enough local data are available, reaching a minimum MAPE of 22.04% and MSE of 0.000204 within 1200 seconds under Evolutionary search. The paper is explicit that TimeTrack is not claimed to surpass a well-trained local-only model with sufficient local history; its role is to rescue forecasting during sparse-data bootstrap (Meliani et al., 8 Jun 2026).
The most important result is the mixed TimeTrack setting. Under Simulated Annealing at 1800 seconds, local_plus_tt achieves the best overall performance, with MAPE = 19.04% and MAE = 0.000994. In the same setting, Random Search improves from 21.17% MAPE at 300 seconds to 19.32% at 1800 seconds, while achieving the lowest recorded variance with MSE = 0.000163 (Meliani et al., 8 Jun 2026). The paper interprets this as showing not only better absolute predictive accuracy but also a smoother NAS optimization landscape.
The coarse public mixtures improve over their standalone versions but remain weaker. The paper states that they “fail to match” local_plus_tt and “never break the 20% performance ceiling.” In the local_plus_mat setting at 1800 seconds, Simulated Annealing yields MAE = 0.01219 but MSE = 0.000240, degraded from 0.000210 at 1500 seconds, which the paper uses as an indicator of occasional large misses (Meliani et al., 8 Jun 2026).
The local-data sensitivity study is particularly strong evidence for cold-start mitigation. With only 10 local samples, local-only forecasting is poor: Grid Search gives 34.47% MAPE, and the best stochastic setting gives 24.72% MAPE. Adding 1,000 TimeTrack samples improves this sharply: with only 10 local samples, local_plus_tt reaches 23.23% MAPE under TPE and 24.38% MAPE under Random Search. The paper stresses that these results with just 10 local points match or outperform models trained on 500 local-only samples, where local-only remains around 22.06%–22.28% MAPE (Meliani et al., 8 Jun 2026).
Forecast-horizon analysis shows the same pattern. For local_only, the best MAPE rises from 22.06% at horizon 1 to 23.28% at horizon 5. For local_plus_tt, the best value is 19.04% at horizon 1, and even at horizon 5 it remains 20.45%, which the paper notes is better than what other datasets achieve even at horizon 1. Standalone mat_only rises from 23.21% to 26.16%, and ali_only from 22.21% to 26.27%, with Grid Search on ali_only reaching 58.43% MAPE (Meliani et al., 8 Jun 2026).
5. Structural properties, computational profile, and limitations
The paper attributes TimeTrack’s value to several structural properties. It is described as high resolution, public, multivariate, collected on physical infrastructure, and rich enough to capture coupled resource relationships and cyclical patterns (Meliani et al., 8 Jun 2026). It gives two concrete examples. A compute correlation matrix shows positive CPU-memory correlations, including 0.65 on machine 03 and 0.74 on machine 04. A weekly memory-usage plot shows low weekend activity and elevated weekday daytime usage. These are used as evidence that TimeTrack contains realistic multivariate coupling and operational cycles (Meliani et al., 8 Jun 2026).
A natural concern is whether 45-second telemetry is too expensive. The paper addresses this by profiling model cost under denser input volume. Even though 45-second sampling yields $45$5 more data than 5-minute sampling, an LSTM processing 38,400 TimeTrack samples requires only 49 seconds, peaks at roughly 50–55 MB RAM, and uses about 10–15% CPU. CNNs are reported as cheaper still (Meliani et al., 8 Jun 2026). This is the paper’s main argument that the computational overhead of denser telemetry is modest relative to the forecasting gains.
The limitations are also explicit. First, TimeTrack comes from a single OAI CI/CD cluster of 7 machines, so it is temporally rich but comparatively narrow in infrastructure diversity (Meliani et al., 8 Jun 2026). Second, the reported experiments are primarily CPU-centric, so evidence for generalization to network latency, energy, disk throughput, or carbon-related signals is architectural rather than directly validated. Third, automatic feature selection is not yet implemented. Fourth, the exact data-mixing procedure is not fully formalized, which limits methodological precision. Finally, because the dataset is derived from an OAI CI/CD 5G testing environment, its temporal signatures may reflect that workload mix; the paper argues that its structural value generalizes, but does not verify this across many heterogeneous target domains (Meliani et al., 8 Jun 2026).
A plausible implication is that TimeTrack is best understood as a strong structural prior rather than a universal replacement for local telemetry. That interpretation is consistent with the paper’s own statement that local-only can still slightly outperform TimeTrack-only once sufficient target history exists (Meliani et al., 8 Jun 2026).
6. Naming distinctions and relation to similarly titled arXiv work
“TimeTrack” is not a stable synonym for all similarly named systems on arXiv. In the specific usage documented here, it denotes the telemetry dataset used in Zero Touch Predictive Orchestration (Meliani et al., 8 Jun 2026). This is distinct from TimeTracker, the event-based continuous point tracking framework for video frame interpolation with non-linear motion (Liu et al., 6 May 2025), and from Time Tracker, the Mixture-of-Experts-enhanced foundation model for multivariate time-series forecasting with decoupled training pipelines (Shi et al., 21 May 2025).
These distinctions matter because the names overlap semantically but refer to different technical objects. TimeTrack is a dataset and structural prior for forecasting in the cloud-edge continuum (Meliani et al., 8 Jun 2026). TimeTracker is a continuous point tracking-based VFI framework operating on images and events (Liu et al., 6 May 2025). Time Tracker is a decoder-only Transformer forecasting model that uses sparse MoE, Any-variate Attention, and graph learning for multivariate time-series prediction (Shi et al., 21 May 2025).
In that sense, TimeTrack belongs to infrastructure telemetry and predictive orchestration rather than to computer vision tracking or to the forecasting-model architecture itself. The article’s subject is therefore the dataset-centered notion of TimeTrack: a public, 45-second, 30-day, multivariate telemetry corpus from a 7-node physical OAI Kubernetes cluster that is used to bootstrap forecasting models under cold-start conditions and to provide a robust foundation for continuous MLOps deployment (Meliani et al., 8 Jun 2026).