# LAPO: LLM-Assisted Parameter Optimization for Low-Power Wireless Protocols (Software)

Archival snapshot of the LAPO pipeline, version 1.0, as used for the experiments in:

> 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 software record: 10.3217/xx8ab-xjm17
Companion dataset record (optimization runs, reasoning traces, prompts, testbed traces, CC BY 4.0): 10.3217/pk9q4-9a455
Development repository: https://github.com/LENS-TUGraz/LAPO (also reachable as http://iti.tugraz.at/LAPO)

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

License: MIT (see LICENSE inside the archive). The protocol sources shipped as analyzer input,
Baloo and rpl-lite, are third-party code under the BSD 3-clause license; their license texts
are kept inside the archive.

## Contents

`LAPO-v1.0.zip` is the development repository as of 31 March 2026; the reasoning traces are in
the dataset record. It contains:

- `lapo_minimal.py`, `lapo_median.py`, `lapoA_median.py`: the three pipeline variants of the
  paper (minimal prompt specification, median-informed specification, and the anonymized
  no-context variant LAPO-A). Each runs the repository analyzer, then the optimization loop.
- `run_experiment.py`: the launcher; `ParameterSetExecutor.py`: executes a parameter set either
  by replaying recorded traces (`json` mode) or as a live D-Cube job (`dcube` mode);
  `Utilities.py`, `gemini_rate_limiter.py`, `standalone_dcube/`: supporting code.
- `config/`: model configurations (`llm/`), the experiment inputs for Crystal and RPL
  (`user_inputs/`), and retry settings.
- `Results/`: the recorded testbed traces the `json` mode replays (the APEX dataset's Crystal and
  RPL traces, 10.3217/3dhx0-2k125), their anonymized versions, and the per-setting medians.
- `Binaries/`: the D-Cube firmware for Crystal (`baloo-crystal-sky.ihex`, the same binary as in
  the APEX software record) and RPL (`RPL_hex.hex`), with their D-Cube patch descriptors.
- `Baloo-master/`, `rpl-lite/`: the protocol sources the repository analyzer reads.
- `README.md`, `LICENSE`, `requirements.txt`, `.env.example`.

Running the pipeline needs the provider API keys named in `.env.example`. The open-weight
models were served with vLLM through its OpenAI-compatible API: their entries under
`config/llm/` use the `openai` provider with the checkpoint path as model name, and the
endpoint comes from the OpenAI client's base URL environment variable. Live D-Cube runs need a
testbed API key in the user input file.

## Reproducing the paper's experiments

1. `pip install -r requirements.txt`
2. Copy `.env.example` to `.env` and fill in the keys of the providers you use.
3. In `run_experiment.py` choose the variant (`SCRIPT`), the model (`LLM`, an id under
   `config/llm/`), the protocol (`USER_INPUT`, an id under `config/user_inputs/`) and
   `EXECUTION_MODE = "json"` for replay against the recorded traces.
4. `python run_experiment.py`

The application requirement is set in the user input file (`opt.goal`, `opt.constraints`).
A run writes its reasoning trace under `Results_reasoning/` in the format documented in
the dataset record.