This document defines how the project moves from an implementation scaffold to a credible result. It does not prescribe an attractive demonstration; it prescribes the conditions under which a claim is allowed. A graph, MQTT message, or successful command transmission is not sufficient evidence by itself. Every reportable result must connect a frozen input manifest to a known physical setup, raw trace data, reconciled counters, analysis code or method, and one explicit terminal status.
The primary experiment investigates whether a cross-layer model improves prediction of deadline-sensitive Thread traffic relative to a network-only model, and whether the system declines to actuate when that model is not currently trustworthy. The system can only be called a closed-loop digital twin after the model-to-policy-to-physical-result return path has been verified. Before that point, use the more precise term digital shadow.
This distinction follows current network-digital-twin architectural research: two-way data/control synchronization and a full feedback cycle distinguish a digital twin from a digital model or shadow. The goal here is not to claim a universal definition, but to make the chosen behavior observable and falsifiable in a student-scale system. IRTF Network Digital Twin Architecture
The principal investigation evaluates whether incorporating internal node and MAC-layer telemetry improves prediction accuracy over network-only observables. To prevent confounding model architecture with feature availability, both candidate models share the exact same model family (
-
Naive Baseline (
$M_{\text{naive}}$ ): A historical moving-average predictor that establishes the non-parametric statistical floor. -
Network-Only Model (
$M_{\text{network}}$ ):$M_{\text{network}} = f_\theta(X_{\text{network}})$ , utilizing network-visible features including packet delivery outcome, link RSSI, and offered traffic load. -
Cross-Layer Model (
$M_{\text{cross}}$ ):$M_{\text{cross}} = f_\theta(X_{\text{network}}, X_{\text{cross}})$ , utilizing network features plus internal device telemetry: OpenThread MAC counters (mTxRetry,mTxErrCca,mTxDirectMaxRetryExpiry), endpoint EDF queue occupancy and deadline-expiry counts, parent link quality (mLinkQualityIn/mLinkQualityOut), and FreeRTOS execution traces.
The statistical comparison evaluates the relative reduction in held-out P95 prediction error:
-
Null Hypothesis (
$H_0$ ): Cross-layer features do not improve held-out prediction accuracy beyond the predeclared engineering relevance threshold of 15% ($H_0: \Delta \le 0.15$ ). -
Alternative Hypothesis (
$H_1$ ): Cross-layer features achieve a meaningful reduction in held-out relative P95 error exceeding the threshold ($H_1: \Delta > 0.15$ ). -
Decision Rule: Reject
$H_0$ if and only if the one-sided 95% lower confidence bound for$\Delta$ exceeds 0.15:
Uncertainty Estimation and Decision Outcomes: Independent physical runs (with randomized treatment order and distinct boot cycles) serve as the primary experimental unit for between-condition comparisons. Primary uncertainty is calculated from run-level summaries or a cluster bootstrap that resamples whole runs. A within-run block bootstrap (1,000 resamples, block length selected from residual autocorrelation decay) may characterize paired time-series uncertainty, but it cannot turn windows from one physical run into independent experimental replicates. The analysis distinguishes three outcomes:
-
$\text{LCB}_{0.95}(\Delta) > 0.15$ : Evidence supports held-out improvement exceeding the 15% engineering relevance threshold under the tested conditions. -
$\hat{\Delta} > 0.15$ but$\text{LCB}_{0.95}(\Delta) \le 0.15$ : The observed point improvement exceeds the threshold, but the experiment does not establish that improvement with the required 95% confidence. -
$\hat{\Delta} \le 0.15$ : The observed improvement does not reach the engineering relevance threshold.
Failing to reject
The second primary question asks whether a valid, finite policy is withdrawn when the evidence supporting it becomes stale or invalid. The initial actuator surface is deliberately narrow: reduce only the bulk stream's offered rate while preserving a protected critical stream; burst, batch, phase, and critical-stream fields remain unchanged. The stale-observation scenario pauses only the gateway-to-host observation publication path; endpoint traffic and Thread routing continue. The expected result is a recorded gate abstention and edge-local fallback, not a service outage.
The safety outcome is not a favorable performance number. Zero invalid policy applications is the acceptance criterion for the tested negative cases: stale observation, incomplete or unreconciled evidence, expired command, wrong run or coordinator identity, duplicate or older epoch, unauthenticated/corrupted payload, endpoint restart, and local-limit violation. Beyond a binary pass/fail, the gate's behavior curve is characterized over time (observation age vs. gate state, reason, calibrated-region status, hysteresis recovery windows, and Kalman covariance
After the stable baseline, reconciled recorder, and frozen shadow model exist, a controlled placement/link-context shift may test whether an explicit calibration envelope reduces false trust outside the source context. The model and all gate thresholds are frozen before target runs. This condition remains shadow-only until stale, authentication, fallback, and replay safety have already passed.
The comparison is between always trusting the prediction, the residual/freshness gate without region detection, and the same gate with calibrated-region detection. A valid success requires both fewer false-trust horizons in the held-out context and a predeclared minimum trusted-horizon fraction in-domain. Abstaining everywhere is safe but not a successful predictive gate.
The SMP comparison is an optional extension that becomes valid only after the physical baseline, recorder, and primary safety chain are stable. It pairs normal ESP-IDF SMP builds with CONFIG_FREERTOS_UNICORE builds using the same source revision, topology, workload, and measurement protocol. The intended outcome is a measured difference, or an honest lack of one, in critical-service timing, gateway queueing, and task/core behavior. ESP-IDF documents these distinct scheduler modes; the protocol must still control for all non-scheduler variation. ESP-IDF FreeRTOS SMP Guide
The power-policy experiment is deferred beyond the version-one critical path. If later admitted, it compares an always-on endpoint profile with a bounded low-power profile under matched traffic and service acceptance. The primary energy expression is energy per successfully delivered critical item, reported beside critical service rather than in isolation. No current sensor is presumed adequate: instrument resolution, calibration, sampling interval, rail boundary, and measurement overhead must first be documented. A lower energy number that follows a loss of critical service is not an improvement.
The eight manifests are not eight mandatory final results. They are a progression from correctness to physical networking, prediction, safety, and optional extensions.
| Manifest | Role In The Program | Minimum Condition Before It Becomes Reportable |
|---|---|---|
| local-rtos-baseline.json | Endpoint timer, queue, expiry, and accounting without Thread | Every released item is reconciled through a local terminal outcome |
| baseline.json | Stable physical Thread baseline without host model or remote actuation | Actual topology, role, placement, and repeated trace block are archived |
| load-step.json | Held-out prediction comparison | Calibration and held-out blocks are separated before model scoring |
| stale-observation.json | Gate abstention and local fallback | One finite action exists and stale-observation fallback is captured end to end |
| restart-replay.json | Command freshness and restart safety | Old, expired, wrong-run, and replay attempts are recorded as rejections |
| smp-comparison.json | S3 scheduler comparison | Matched SMP/unicore builds and paired physical runs exist |
| power-policy.json | Deferred comparative energy/service trade-off | A suitable instrument, power boundary, and sampler-overhead control are documented in a later phase |
| topology-shift.json | Conditional calibration-envelope response to a controlled placement/link-context change | Core shadow evidence is complete; before/after positions and actual role/link/topology state are recorded |
The required core sequence is local RTOS baseline, stable Thread baseline, held-out load-step prediction, stale-observation fallback, and restart/replay safety. Calibration-envelope/context-shift evaluation and feature ablation are conditional depth only after the frozen shadow result exists. SMP and power are deferred before any core evidence requirement is weakened.
The JSON schema deliberately distinguishes preparation from execution. A template can contain null values and detailed _todo entries. A ready manifest cannot. The host must reject a template even if its title and question look complete.
flowchart LR
A["Annotated JSONC<br/>Human planning copy"] --> B["Strict JSON template<br/>Known facts + null pilot values"]
B --> C["Pilot evidence<br/>No reportable claim"]
C --> D["Strict JSON ready manifest<br/>No nulls or TODOs"]
D --> E["Schema and cross-field validation"]
E --> F["Frozen manifest + digest + run ID"]
F --> G["Physical run and append-only evidence"]
G --> H["Complete, invalid, or interrupted terminal status"]
Strict JSON has no comment syntax. The files in experiments/ therefore remain valid JSON and can be checked against schemas/experiment.schema.json. The corresponding files in experiments/authoring/ use the JSONC extension and contain actual // comment lines beside the fields an operator must complete. Their comments and _todo prose may be more detailed than the strict templates. They are authoring aids, not runtime inputs; only the validated strict JSON file is authoritative for a physical run.
When a pilot decision is ready to freeze, copy the completed values—not the comments—into the matching strict JSON file. Set state to ready only after every ready-only field has a concrete value, _todo is empty, and the strict file passes schema validation. Keep the original ready bytes unchanged once the host creates a run directory.
Complete a manifest in a deliberate order:
- Freeze physical identity first: board labels, actual roles, channel, placement description, firmware revision, binary digests, and RCP transport. A later change to any of these begins a new calibration block.
- Use pilots to choose workload period, payload size, burst, run duration, warm-up, cooldown, and repetitions. Do not choose values from a result you intend to claim.
- Specify a single planned disturbance—load step, observation pause, restart, or placement shift—and make its time, duration, and target concrete.
- Select a treatment that is compatible with the experiment. Prediction tests have
host_model: trueandremote_actuation: false. Baselines use neither. Safety tests enable a narrow candidate action only after profile, authentication, TTL, and fallback paths exist. - Name the immutable control profile and calibration identity used by the run. Its resolved digest belongs in the evidence bundle.
- Predeclare a critical service floor, a negative case, evidence artifacts, and an invalidation rule. These decisions must exist before measurement data are inspected.
The independent variables are intentionally limited. Changing traffic shape, placement, firmware, and scheduler mode in a single run prevents a meaningful conclusion.
| Category | Variables | Rule |
|---|---|---|
| Independent | Model feature set, load step, observation pause, scheduler mode, endpoint profile, physical placement | Change one intended cause per experiment condition |
| Controlled | Board identity, firmware/hash, upstream revision, Thread channel, payload format, topology, placement, power path, run phase durations | Freeze within a calibration or paired block |
| Recorded Context | RSSI/link state, actual Thread role/parent/partition, queue high-water, task/core state, clock uncertainty, source presence/freshness, ambient/operator notes | Record rather than assume constant |
| Dependent | On-time critical delivery, deadline miss ratio, response/queue delay, prediction error, false trust, trusted-horizon fraction, gate transitions, rejected commands, energy per delivered item | Compute only from reconciled, attributable records |
The physical radio environment cannot be controlled perfectly. Instead, document it. If a person moves a node, a board changes parent, a USB hub browns out, a Wi-Fi backhaul reconnects, or a configuration value changes, capture that fact. The event either becomes a predeclared scenario or invalidates the comparison; it does not disappear into “noise.”
All metrics refer to unique logical items identified by the tuple run_id, node_id, boot_id, sequence. Retransmissions are not new logical items. Work-item trace records retain release, deadline, and event timestamps in one local monotonic domain so timing is derived from explicit evidence rather than reconstructed from aggregate counters.
| Measure | Definition | Validity Condition |
|---|---|---|
| Critical on-time delivery ratio | Number of critical items acknowledged before their deadline divided by critical items released in the measured window | Releases and terminal outcomes reconcile; the deadline clock/uncertainty rule is recorded |
| Deadline miss ratio | Number of released items that become late, expire, or finish after deadline divided by released items | The policy for expiry versus late acknowledgement is declared before the run |
| Queue delay | Time from queue admission to removal for transmission or terminal expiry | Local timestamp scope and clock source are documented |
| Queue high-water | Largest observed bounded queue occupancy during the run | Queue capacity and trace-drop count are archived |
| Prediction error | Difference between pre-event prediction and observed metric on the same horizon | Held-out horizon was not used to tune model parameters |
| Relative P95 prediction error | P95 of absolute relative prediction error over valid scored horizons | Near-zero denominators are handled by a predeclared rule |
| Prediction-interval coverage | Fraction of observations inside the model’s declared interval | Interval construction is versioned before scoring |
| Trusted-horizon fraction | Scored horizons for which the frozen gate permits trust divided by all eligible scored horizons | Eligibility and every abstention reason are retained; missing data cannot disappear from the denominator silently |
| False-trust rate | Trusted horizons whose frozen error tolerance or critical-service floor is violated divided by trusted horizons | Tolerance and service floor are selected before held-out outcomes are inspected |
| Selective prediction error | Prediction error summarized only over trusted horizons and reported beside trusted-horizon fraction | A low error obtained by abstaining almost everywhere is not reported alone |
| False-abstention rate | In-domain eligible horizons that satisfy every frozen validity/error condition but remain untrusted | Source-context label and all gate inputs are retained |
| Observation age | Host monotonic time minus time of newest accepted physical observation | Time mapping and uncertainty are available |
| Fallback latency | Time from a declared stale/invalid condition to the local fallback event | Trigger and fallback clocks are traceable or uncertainty-qualified |
| Requalification latency | Time from restored valid evidence to re-entry into TRUSTED after the complete hysteresis sequence |
Recovery start, every passing window, and any reset to ABSTAIN are recorded |
| Energy per delivered critical item (deferred) | Measured energy over the stated rail boundary divided by on-time delivered critical items | A later admitted study uses an identical service floor and calibrated measurement boundary for both conditions |
Reconciliation is intentionally two-stage. First, a sorted raw-trace audit must verify each full logical identity has exactly one release and at most one terminal outcome, with no terminal lacking a release and no unresolved item hidden at the boundary. Second, aggregate reconciliation must balance releases, terminal outcomes, and declared in-flight work per class. A run must pass both: equal totals alone can conceal a duplicated terminal for one item and a missing terminal for another. Layer-specific diagnostic counts—queue admission, MAC attempts/acknowledgements, gateway receipt, and application acceptance—are retained as typed evidence but are not forced to be numerically equal because retries, fragmentation, and observer loss change their meaning.
Do not report one-way latency without clock uncertainty beside it. Do not report a percentage unless both per-item and aggregate reconciliation pass. Do not report an energy improvement without showing the companion service result.
The project compares models rather than merely training one. A calibration block contains a stable baseline and designated pilot/load conditions used to fit parameters and choose the profile’s model-related limits. A held-out block contains a condition whose raw traces are never used to tune those parameters, select features, or decide thresholds. The load-step.json manifest is designed for this purpose.
To isolate the contribution of cross-layer telemetry, both candidate models (
The naive moving average is a mandatory benchmark but not an actuation candidate. Version one predeclares the cross-layer variant as the only model eligible to feed the fidelity gate after it passes frozen shadow acceptance criteria. The network-only model remains a matched comparator. If the cross-layer candidate fails, actuation stays disabled; the controller model is not switched after seeing which result looks best. Model variant, revision, issuance time, and exact horizon boundaries are part of every prediction and score.
After the primary three-model comparison is frozen, a feature-group ablation may evaluate network-only, network-plus-MAC, network-plus-queue, and complete cross-layer inputs on the same horizons. It is secondary analysis: it cannot be used to retrospectively choose the feature set that is then called the original primary model.
For calibration-envelope analysis, continuous pre-outcome features are normalized using calibration-only statistics, while unseen categorical role, parent, or partition identities are handled explicitly. The support rule and threshold are frozen on a calibration block distinct from the target context. Ordinary residual quantiles or robust-distance thresholds must not be labeled as formally distribution-free conformal prediction.
Temporal Availability and Target Leakage Prevention: A prediction issued at time
For every scored horizon, retain the model revision, feature-set label, prediction issuance time, prediction horizon, predicted interval, calibrated-region result, observation-integrity result, source evidence bundle, and observed outcome. Score the naive, network-only, and cross-layer models on the exact same horizons. If the feature set or code changes, start a new model revision and do not merge scores across revisions as though they were one treatment.
The fidelity gate is evaluated on completed prior horizons. It must never look at the future observed outcome of the policy it is deciding to issue. A missing, stale, contradictory, or unreconciled observation is an explicit failure input rather than a skipped horizon. A model that is frequently “trusted” but wrong is not a successful controller; a gate that abstains frequently may be correct if it is doing so for documented data-quality reasons, but usefulness must still be reported through trusted-horizon fraction.
- Label every board physically and logically. Record the gateway, RCP, router-capable endpoint, and second workload-endpoint identities; do not infer a low-power Thread role from the label.
- Build and archive the firmware, upstream dependency references, build configuration, and binary digests. Ensure the RCP and border router attach repeatedly through power cycles.
- Survey and photograph the physical placement. Record channel, orientation, power connections, UART wiring, and expected backhaul path.
- Run a local RTOS accounting pilot with Thread disabled. Verify that release, queue, expiry, and terminal records reconcile.
- Bring up the stable Thread topology without host model or remote actuation. Record actual roles, parent relationships, reachability, and normal observation cadence.
- Test the recorder with an intentionally interrupted non-reportable run. Confirm it records an interrupted terminal status rather than silently appearing complete.
- Validate the strict ready JSON file and preserve its exact bytes before booting the measurement phase.
- Resolve the selected control profile, record its ID, calibration ID, actuation-model variant, and digest, then reject the run if it does not match the manifest.
- Reserve a nonzero CSPRNG run ID in the durable global ledger and generate a nonzero coordinator boot/session ID. For actuation, bind the non-secret command-key identity; lost ledger continuity requires key rotation.
- Create a new run directory. It must not reuse an existing directory or overwrite an older run.
- Confirm board identity, firmware identity, Thread attachment, actual topology, time-sync health, and baseline counter state.
- Start warm-up. Record warm-up data but keep it outside the primary measurement calculation.
- Start the measurement window, store the monotonic start boundary, and capture every observation before updating any model.
- Introduce only the manifest’s one declared scenario at the frozen time. Record operator action and observed device acknowledgement.
- For shadow-model runs, predict and score without enabling remote actuation.
- For safety runs, allow only the named finite candidate action and retain every acceptance, rejection, expiry, and fallback trace.
- End measurement and cooldown cleanly. Request final counters from each device before finalizing evidence.
- Reconcile counters by traffic class. Mark the run invalid if reconciliation fails or a planned control condition was not reached.
- Write one terminal status and operator notes. A run may be complete, invalid, or interrupted; it is never silently discarded.
Use at least three non-reportable pilot repetitions to understand stable variance and choose the measurement duration. The final repetition count must be selected before inspecting the treatment’s final outcome. For paired comparisons such as SMP versus unicore or always-on versus low-power, alternate or randomize condition order within one stable physical block and reboot only the board whose documented build changes. Preserve the pair ID and exclusion rule.
There is no universal repetition count that magically fixes a noisy wireless experiment. The defensible approach is to state the planned number, report every valid/invalid/interrupted run, summarize distribution rather than a single best value, and explain any exclusion with raw evidence.
Use an application-level publication gate at the gateway or host adapter to pause observations after normal gated-control operation begins. Do not jam RF, disconnect endpoints, or perturb Thread routing. The pause duration must exceed the control profile’s recorded maximum observation age with a margin that lets recovery be seen. The expected evidence sequence is: newest accepted observation, stale condition, host gate abstention, finite command expiry or local fallback, endpoint acknowledgement, restored observation stream, ABSTAIN to OBSERVE transition, complete passing-window sequence, and either evidence-based return to TRUSTED or documented continued abstention.
First commission a unique run and coordinator boot identity, then prove one normal global command acceptance with valid ChaCha20-Poly1305 authentication (RFC 8439) using the active command key. Evidence must show that the endpoint durably records the commissioned authority and accepted epoch before policy publication. Then restart only the selected endpoint, record a new endpoint boot identity, and verify that it reloads the same replay record. Send old-epoch, expired, wrong-run, wrong-authority-boot, corrupted-tag, and byte-for-byte replayed commands through the normal gateway path; never bypass authentication or call private apply functions. Separately exercise a missing or corrupt replay-record fixture: the endpoint must retain its compiled safe policy and refuse remote apply until explicitly commissioned into a new unique run. Every attempt must have a logged status code and reason (CLDT_ERR_AUTHENTICATION, CLDT_ERR_EXPIRED, CLDT_ERR_OUT_OF_ORDER, CLDT_ERR_WRONG_RUN, CLDT_ERR_WRONG_AUTHORITY, or CLDT_ERR_NOT_READY). Endpoint boot_id is restart evidence, not the replay primitive. Zero invalid policy applications is the acceptance criterion for the tested replay, authentication, persistence, epoch-freshness, and state-validation cases.
Move only the endpoint named in the manifest between two pre-measured, photographed positions. Keep other boards, the channel, and workload fixed. Record actual role, RLOC16, parent, partition, RSSI/link quality, and available MAC/MLE diagnostics before and after the shift. Call the condition a topology shift only if the recorded Thread role/parent/partition/router evidence changes; otherwise report it as a placement or link-context shift. A correct result can be either documented retained fidelity or gate abstention. Selecting the favorable interpretation after seeing the graph is prohibited.
| Decision | Rule |
|---|---|
| Complete result | Ready manifest, topology evidence, required artifacts, per-item lifecycle audit, and aggregate counter reconciliation are present; the planned scenario occurred |
| Invalid result | Missing required evidence, counter mismatch, wrong firmware/profile/topology, unexpected second disturbance, or failed command-audit completeness |
| Interrupted result | Operator, power, or external condition ends the run before terminal collection; preserve partial raw evidence and reason |
| Excluded observation | Only a predeclared, documented reason may exclude it; retain it in raw data and report the count |
| Model comparison | Score naive, network-only, and cross-layer models on identical held-out horizons; do not compare separately chosen best runs |
| Energy comparison | Enforce the same critical-service acceptance condition for every compared profile |
The final report must include negative results, failed safety checks, and invalid runs. The technical reason for an invalid run is often more educational and more credible than an unexplained absence from a chart.
Each run directory contains an immutable evidence package:
- the original ready manifest and its SHA-256 digest;
versions.jsonrecording source revision, ESP-IDF/upstream revision, build configuration, binary hashes, control-profile/calibration/model identity, and tool versions;- reserved run-ledger record and, for actuation, the non-secret command-key identity;
- physical topology/placement record and required photographs;
- raw append-only event stream (
events.ndjson) and broker captures; - device final counters, trace-drop counts, queue high-water marks, and clock-uncertainty data;
- per-horizon source presence, freshness, reconciliation, calibrated-region, and gate-reason records;
- command audit containing proposal, acceptance/rejection reason, epoch, durable replay-state transitions, TTL, Poly1305 authentication tags, expiry, and fallback records;
- model revision, prediction horizons, feature-set label, and derived analysis;
- calibration and rail-boundary record for power runs; and
- terminal status plus operator notes.
host/analysis/reproduce.py is the scaffold for the planned post-hoc reproduction pipeline. At the scaffold stage it exits nonzero and produces no result. Once fully implemented, it is designed to take a completed run directory, verify the manifest digest and lifecycle event reconciliation, fit the naive, network-only, and cross-layer models on the manifest-defined calibration block, score on held-out horizons, compute run-aware confidence intervals, characterize calibration-envelope/gate behavior, and output the primary metric table.
The schedule is evidence-first and treats every non-core feature as expendable.
| Period | Gate | Output Required Before Moving Forward |
|---|---|---|
| Days 1–3 | Frozen contracts | Scope, pin map, protocol/authentication bytes, toolchain revision, and procurement boundary are fixed |
| Week 1 | Portable and upstream foundations | Host contracts build, fixed vectors begin replacing skips, and upstream RCP/border-router images build and flash |
| By Day 10 | Highest-risk physical path | Repeatable cold boot and sustained S3/RCP/one-endpoint Thread UDP; otherwise model/control depth is cut |
| Week 2 | Local and physical baseline | Endpoint accounting is correct; the second endpoint attaches only after the one-endpoint soak gate |
| Week 3 | Observation integrity | Project frames, bounded bridge, raw recorder, item audit, and aggregate reconciliation function through repeated baselines |
| Week 4 | Shadow-model validity | Naive, network-only, and cross-layer models are frozen and scored on a predeclared held-out load step |
| Week 5 | Safety closure | Observation-integrity/calibrated-region gate inputs, one finite bulk action, stale fallback/requalification, and restart/replay rejection produce complete traces |
| Week 6 | Freeze and communicate | Final repetitions, automated reproduction, limitations, and presentation; context-shift/ablation depth only if already stable |
If Week 3 is late, remove conditional depth immediately. If the shadow model is not frozen by the end of Week 4, run no physical context-shift claim and enable no remote actuation. SMP, power, passive capture, additional nodes, SPI migration, dashboards, and multi-action control are future work. A high-quality baseline plus a complete stale-fallback experiment is more valuable than several half-integrated extensions. See FUTURE_PROJECTION.md.
This protocol measures a small, specific 802.15.4 Thread topology, not the performance of Thread in general. It does not establish a production security posture, an O-RAN implementation, Wi-Fi 7 behavior, cellular performance, or a universal digital-twin architecture. A held-out placement result adds evidence about one declared context shift; it does not erase the one-family, one-stack external-validity limit. The study may show that a particular cross-layer feature set improves, matches, or fails to improve prediction under the documented conditions. Each result remains scoped to the actual hardware, radio environment, workload, firmware, model revision, and repetition set recorded in its evidence.
That limitation is not a weakness. BMW Lab’s public research spans much larger wireless and digital-twin environments; a well-executed small system demonstrates the transferable discipline of data collection, synchronized modeling, controlled experimentation, and evidence-backed control without pretending that a low-cost bench is a cellular lab. The linked TEEP page is the 2026 call and is used only as historical evidence of topic alignment; later calls may differ. BMW Lab Research 2026 TEEP Program Listing