# LAPO Dataset: LLM-Assisted Parameter Optimization of Low-Power Wireless Protocols

This record contains the experimental data underlying the paper:

> M. H. M. Hydher, M. Schuß, O. Saukh, K. Römer, C. A. Boano:
> "LLM-Assisted Parameter Optimization for Low-Power Wireless Protocols",
> Proceedings of the 23rd International Conference on Embedded Wireless Systems and Networks (EWSN 2026), Dresden, Germany, September 2026.
> DOI: 10.3217/f19q-hk91

DOI of this dataset: 10.3217/pk9q4-9a455
Companion software record (LAPO pipeline, MIT licensed): 10.3217/xx8ab-xjm17
Development repository: https://github.com/LENS-TUGraz/LAPO (also reachable as http://iti.tugraz.at/LAPO)
The testbed traces used by the emulator come from the APEX dataset: 10.3217/3dhx0-2k125

Funding: This research was funded in whole, or in part, by the Austrian Science Fund (FWF) [10.55776/DFH5].

License: Creative Commons Attribution 4.0 International (CC BY 4.0).

## Contents

| File | Description |
|---|---|
| `run_results.zip` | One JSON file per optimization run: the parameter sets tested, the measured outcomes, and the final answer. 1,010 runs. |
| `reasoning_traces.zip` | One JSON file per run with the optimizer's proposals and rationales. Same 1,010 runs, same folder layout. |
| `ground_truth.zip` | The recorded D-Cube testbed traces the emulator replays (Crystal: 16 settings x 6 trials, RPL: 36 settings x 6 trials), their anonymized versions, and the per-setting medians. |
| `prompts_and_example_summaries.zip` | The prompt specifications as the runs used them, and three example protocol summaries produced by the repository analyzer for Crystal. |

## Experiments covered

Folder layout inside `run_results/` and `reasoning_traces/`:
`<Protocol>/<Variant>/<goal_constraint>/`, with Protocol in {Crystal, RPL}, Variant in
{LAPO_minimal, LAPO_median, LAPO_median_anon} and the goal-constraint folder named after the
application requirement, for example `e_1_r_0.96` for "minimize energy subject to PRR >= 96%".

| Application requirement | Protocol | Goal | Constraint | Folder |
|---|---|---|---|---|
| AR1 | Crystal | minimize energy | PRR >= 65% | `e_1_r_0.65` |
| AR2 | Crystal | minimize energy | PRR >= 96% | `e_1_r_0.96` |
| AR3 | RPL | minimize energy | PRR >= 65.5% | `e_1_r_0.655` |
| AR4 | RPL | minimize energy | PRR >= 93% | `e_1_r_0.93` |

Variants: `LAPO_minimal` uses the minimal prompt specification, `LAPO_median` the
median-informed specification with protocol context, `LAPO_median_anon` the median-informed
specification without protocol context (LAPO-A: the protocol and its parameters are anonymized).

| Variant | Requirements | Models | Runs per model and requirement |
|---|---|---|---|
| LAPO_minimal | AR1, AR2 | GPT-5, Claude Sonnet 4.5, Gemini 2.5 Pro | 8 |
| LAPO_median | AR1, AR2, AR3, AR4 | GPT-5, Claude Sonnet 4.5, Gemini 2.5 Pro | 8 |
| LAPO_median | AR1, AR2, AR3, AR4 | Gemma 3 12B, Gemma 3 27B, Llama 3.1 8B, Llama 3.1 70B, Llama 3.1 70B AWQ | 40 |
| LAPO_median_anon | AR2, AR4 | GPT-5, Claude Sonnet 4.5, Gemini 2.5 Pro | 8 |

Live runs on the D-Cube testbed (Crystal, AR1, Gemini 2.5 Pro, median-informed specification)
are under `Crystal/LAPO_median/e_1_r_0.65/live_run/<layout>/<interference>/`:

| Folder | Scenario | Runs |
|---|---|---|
| `live_run/1/0` | D-Cube layout 1, no added interference | 6 |
| `live_run/4/0` | D-Cube layout 4, no added interference | 6 |
| `live_run/1/HH02` | D-Cube layout 1, Wi-Fi interference generated with JamLab-NG | 6 |

File names carry the model and the start time of the run, for example
`results_gpt-5_median_T_20251120_110726.json`. The open-weight models appear with the
name of their vLLM checkpoint, for example `-work-models-google-gemma-3-27b-it`.

## Results files

Each `results_*.json` holds one run:

```
{
  "configuration": {
    "model": {"provider": "open-ai", "full_name": "gpt-5"},
    "optimization": {"goal": "energy", "constraints": {"reliability": ">= 0.96"},
                     "param_ranges": {"tx_power": [19, 23, 27, 31], "n_tx_max": [1, 2, 3, 4]}}
  },
  "runs": [
    {"iteration": 0,
     "params_clear": {"tx_power": 31, "n_tx_max": 2},        parameter set the optimizer asked for
     "params_executed_anon": {"n_tx_max": 2, "tx_power": 31},  the set that was executed
     "results": {"reliability": 0.950806, "latency": 600.147, "energy": 176.155},
     "ts": "2025-11-20T09:36:34+00:00"},
    ...
  ],
  "by_param_set": { "<executed parameter set>": [ {reliability, latency, energy}, ... ] },
  "early_exit_attempts": [ {"iteration": 3, "suggested_best_parameter_set": {...}} ],
  "optimization_goals": "...",
  "returned_best_parameter_set": {"tx_power": 31, "n_tx_max": 2},
  "max_iterations_reached": false,
  "final_iteration_count": 33
}
```

`early_exit_attempts` appears when the optimizer proposed a final answer before the minimum
number of trials. Runs that ended before a final answer have `runs` and `by_param_set` and
none of the four closing fields from `optimization_goals` on.

`runs` is the sequence of executed trials. In the emulated experiments each trial outcome is
one of the six recorded testbed trials of that parameter set, drawn at random and used at most
once per run; in the live experiments it is the measured outcome of a D-Cube job. Parameter
values are the raw firmware values (see the ground truth section for the mapping to the paper's
notation). Reliability is the packet reception ratio as a fraction, energy is in J, and latency
is the value reported by the testbed.

In the anonymized runs (`LAPO_median_anon`) the optimizer saw the parameters as `param_1`,
`param_2`, ... with index values; the files carry both views: `params_clear` with the anonymized
names and indices the optimizer used, and `params_executed_real` with the real names and values.
Their `by_param_set` keys use the anonymized names. The live-run files also carry the D-Cube job
configuration under `configuration.dcube_config`. In some entries of
the minimal-prompt runs the `results` object also has `id`, the number of the recorded testbed
trial, `goal`, the negative of the reliability value, and the executed parameter values under
the names `a` and `b`.

## Reasoning traces

Each `chat_log_*.json` in `reasoning_traces/` is a JSON array with one entry per optimizer
answer in that run:

```
[
  {"iteration": 1,
   "proposed_params": {"tx_power": 19, "n_tx_max": 1},
   "rationale": "..."},
  ...
]
```

`iteration` counts the optimizer's answers from 1; `proposed_params` is the parameter set parsed
from the answer, or null when the answer carried no valid set; `rationale` is the model's own
explanation. A trace can have more entries than its results file has trials, because it also
keeps the answers that led to no testbed trial: an answer with no valid set, a set already at
its trial limit, or an early final answer. The trace `chat_log_<run>.json`
and the results file `results_<run>.json` of a run share the same `<run>` part of the name.

## Ground truth

`Crystal_results.json` and `RPL_results.json` are the recorded testbed traces (D-Cube, Graz
University of Technology). Each entry is one trial:

```
{"id": 37155, "params": {"n_tx_max": 1, "n_empty_ta": 1, "tx_power": 19},
 "metrics": {"reliability": 0.674024, "latency": 602.13, "energy": 191.132}}
```

They are the same files as in the APEX dataset record (10.3217/3dhx0-2k125), which documents
them in full. The mapping from raw values to the paper's notation:

| Protocol | Recorded field | Values | Paper notation |
|---|---|---|---|
| Crystal | `tx_power` | 19, 23, 27, 31 | -5, -3, -1, 0 dBm (CC2420 PA_LEVEL) |
| Crystal | `n_tx_max` | 1, 2, 3, 4 | number of transmissions 1 to 4 |
| RPL | `_RPL_DIO_INTERVAL_MIN` | 4, 8, 12, 16 | DIO interval 2^4, 2^8, 2^12, 2^16 ms |
| RPL | `_MAX_LINK_METRIC` | 2048, 4096, 8192 | max link metric 16, 32, 64 (value / 128) |
| RPL | `_RANK_THRESHOLD` | 192, 384, 768 | rank threshold 1.5, 3, 6 (value / 128) |

`Anonymized_*_results.json` are the same traces with parameter names replaced by `param_n` and
values by indices, as used for LAPO-A. `*_Recorded_summary.json` hold the median energy and
reliability of each setting over its six trials.

## Prompts and example summaries

`prompts/` holds the optimizer system prompts of the three variants
(`optimizer_prompt_minimal.txt`, `optimizer_prompt_median_informed.txt`,
`optimizer_prompt_median_informed_anonymized.txt`), the repository analyzer prompt, and the
templates used to hand the protocol summary, the optimization goal and each trial result to
the optimizer, as used in the runs. The same prompts are embedded in the scripts of the software
record.

`example_protocol_summaries/` holds three protocol summaries produced by the repository
analyzer for Crystal, one per proprietary model, as examples of what the optimizer receives
as protocol context.