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).

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.