fumd-ai/alicante-handover-dataset

FUMD-AI Alicante Vehicular Handover Dataset

Per-second traces of vehicles moving through a simulated 5G NR deployment over central Alicante, Spain, with every serving-cell change classified and every row labelled with an upcoming-handover flag and the cell the vehicle will settle on.

Each row joins a vehicle's mobility state (position, speed, heading, lane) to its radio state at the same second (serving cell, SINR, CQI, RLC delay/throughput, distance to the serving gNB).

This is the sibling of [FUMD-AI/krakow-handover-dataset](https://huggingface.co/datasets/FUMD-AI/krakow-handover-dataset): identical schema, identical labelling policy, a different city and — importantly — a base-station layout taken from real Alicante landmarks rather than a synthetic uniform grid. Together the two are a ready-made cross-city generalisation benchmark. See How this differs from the Kraków dataset.

• —Four runs, differing only in traffic density: 900_1, 1000_1, 1200_1, 1400_1 (the number is the vehicle count; _1 is the seed/repetition).
• —478,564 labelled rows across 4,504 vehicles, sampled at 1 Hz over 1,800 simulated seconds per run.
• —15,591 detected serving-cell change events, each classified into one of five cases; 10,371 of them are actionable handovers.
• —9 base stations, ids 1–9, with coordinates included.

At a glance

All four runs cover t = 1 … 1799 s, the same 9 cells, and the same geographic extent (longitude −0.4950 … −0.4755, latitude 38.3366 … 38.3530).

Loading

from datasets import load_dataset

# per-second labelled traces (default config)
ds = load_dataset("FUMD-AI/alicante-handover-dataset", split="run_900_1")

# all four densities at once
ds = load_dataset("FUMD-AI/alicante-handover-dataset")   # DatasetDict of 4 splits

# the serving-cell change event log
ev = load_dataset("FUMD-AI/alicante-handover-dataset", "events", split="run_900_1")

# the 9 base-station sites
bs = load_dataset("FUMD-AI/alicante-handover-dataset", "base_stations", split="sites")

Or straight from the files, which is what the FUMD-AI workflows themselves do:

import pandas as pd
from huggingface_hub import hf_hub_download

path = hf_hub_download("FUMD-AI/alicante-handover-dataset",
                       "data/900_1/dataset_labeled_w3.csv",
                       repo_type="dataset")
df = pd.read_csv(path)

Note on `metadata/alicante_bs_coords.csv`. The file carries a long # comment header describing its provenance. pandas.read_csv(..., comment="#") reads it directly; the base_stations config above is served by the Hub's own parser, which also skips those lines.

Repository layout

data/900_1/dataset_labeled_w3.csv    per-second labelled trace, 37 columns
data/900_1/events_all_w3.csv         serving-cell change event log, 10 columns
data/1000_1/ … data/1400_1/          the same two files per run
metadata/alicante_bs_coords.csv      the 9 base-station sites (id, name, lon, lat)
metadata/alicante_osm_extract.geopackage.zip
                                     the OpenStreetMap extract the SUMO network
                                     was built from — resolves `lane` ids to roads
parquet/                             optional Parquet mirror of data/ (see below)
dataset_info.json                    machine-readable schema + per-run statistics
ro-crate-metadata.json               RO-Crate 1.1 description of this dataset
CITATION.cff                         citation metadata

The CSVs are the authoritative files, byte-for-byte as the workflow produced them; nothing has been re-encoded. parquet/ is a convenience mirror produced by scripts/make_parquet.py — the Hub also auto-converts the CSVs to Parquet for the dataset viewer, so you never need the mirror to browse or query the data.

The labeled config — per-second traces

One row per vehicle per simulated second, 37 columns.

Mobility (from SUMO)

`lane` has two shapes. Ordinary road lanes are an OSM way id plus a lane index (21741431#3_1). Lanes inside junctions are SUMO internal edges, which start with a colon (:234348379_2_0) and have no OSM counterpart. Internal lanes are 2,135 of the 3,683 distinct ids and about 20 % of all rows — so roughly one row in five cannot be matched to the OSM extract by lane id alone. Use x/y for those.

Radio (from OMNeT++ / Simu5G)

The three rlc*Dl columns are exactly `0` for vehicles that never carried downlink application traffic — 49.9 % of the rows in `900_1`, appreciably more than in the Kraków runs. That is a deliberate fill by the preprocessing workflow, not missing data. Treat 0 there as "no downlink traffic", and do not impute it. With half the rows zeroed, these three columns are close to a binary "had traffic" indicator in this scenario; check their information content before relying on them.

Serving cell, past and future

0 is a reserved "not connected" code across all of these columns. It never appears in servingCell itself — 0 rows out of 478,564 — and appears in only 14 cells of the look-ahead columns across the whole dataset, so the effective label space is the 9 real cells.

⚠️ The `-1` sentinel is not a class. Rows near the start of a vehicle's trace carry -1 in the lags, and rows near the end carry -1 in the leads. A model trained on -1 targets as if they were a tenth cell will learn to predict "trace ended". Drop those rows, or mask those horizon steps. This matters more here than in the Kraków dataset. Alicante traces are short — a median of ~98 rows per vehicle against ~290 in Kraków — so a much larger share of rows sits near a trace boundary.

⚠️ Leakage. servingCell1 … servingCell7 are look-ahead columns. Using them as model inputs trivially solves the forecasting task. Use only servingCell and the seven servingCell-k lags.

Labels

destination uses destination_mode="freeze_stable", so a short-lived ping-pong blip is never reported as a destination. migration == 1 fires exactly once per actionable handover: 10,371 rows across the four runs, matching the 10,371 actionable events (C1 + C2a + C3) in the event log.

Label distribution:

At 6.49 % warning-window rows this is about three times less imbalanced than the Kraków dataset (2.03 %), which makes it the easier of the two to train a handover-aware model on. It is still an imbalanced problem: report steady-state and warning-window accuracy separately, never a single pooled number.

Labelling parameters (the w3 in the filenames)

Identical to the Kraków dataset's, so the two are directly comparable. The original study swept window_s ∈ {2, 3, 4, 5}; only the 3-second labelling is published.

The events config — serving-cell change log

One row per detected serving-cell change, including changes that are not actionable handovers. This is the diagnostic log behind the row labels.

This is the mirror image of the Kraków run. There, instability dominated — C4 alone was 56 % of events and clean C1 handovers only 20 %. Here clean C1 handovers are 57 % and C4 is 29 %. Two thirds of Alicante's serving-cell changes are genuine handovers, against roughly one third in Kraków. Anyone studying ping-pong behaviour will find far more of it in the Kraków data; anyone who wants clean handover examples should start here.

The base_stations config

metadata/alicante_bs_coords.csv gives the 9 sites as cell_id, name, lon, lat. The cell_id values match servingCell / destination exactly.

The sites are real Alicante locations — Luceros, Gabriel Miró, Teatro Arniches, Plaza del Mercado, Paseo Canalejas, Parque de La Ereta, Castillo Santa Bárbara, Playa Postiguet and Zona Volvo — taken from an "Alicantetouristicplaces" spreadsheet. The layout is irregular: nearest-neighbour spacing runs from 259 m to 522 m (mean 434 m), and the farthest pair is 1,491 m apart.

They are, however, landmark coordinates used as base-station positions, not a surveyed operator deployment, and they are not derived from RSRP measurements — no such measurements exist for this project. The # header of the CSV records what is and is not known about their provenance; read it before citing them as real cell sites.

Scenario and provenance

Raw SUMO fcd-output XML and OMNeT++ .vec vectors were turned into these tables by the [FUMD-AI preprocessing workflow](https://github.com/FUMD-AI/fumd-ai-preprocessing-workflow): parse → lagged position columns → OMNeT++ vector matrix → SUMO/OMNeT id alignment and merge → past-position sentinel fix → migration labelling. The events_all_w3.csv files are that workflow's migration-labelling diagnostic output.

Two provenance caveats, stated plainly because the repository does not record the answers:

• —The exact simulator versions for these runs are not recorded. The Kraków runs were produced with OMNeT++ 6.3.0 / Simu5G 1.4.4 / INET 4.5.4; these runs are older and their versions are not written down anywhere in the project.
• —The bundled OSM extract's nominal box (recorded in the original file name as lon −0.497 … −0.476, lat 38.338 … 38.350) is marginally smaller than the observed vehicle extent at the southern edge. A handful of positions fall just outside it.

How this differs from the Kraków dataset

Identical schema, identical labelling parameters, identical column semantics — so a pipeline written for one runs unchanged on the other. What differs:

Practical consequences:

• —Cross-city evaluation is the point. Train on one, test on the other, and everything map-specific (lane encodings, the x/y scaling) has to be re-fitted or dropped — which is exactly the honest test of whether a handover forecaster learned mobility-and-radio dynamics or memorised a map.
• —The irregular layout is the more realistic one. The Kraków card warns that its uniform grid probably flatters handover predictability. These runs do not have that problem, so a result that holds on both is worth more than a result on either alone.
• —Different failure modes. Kraków stresses ping-pong rejection; Alicante stresses short traces and a high share of traffic-free rows.

The published model, FUMD-AI/handover-forecaster, was trained on the Kraków runs only. It has never seen this data, which makes these four runs a genuine held-out test set for it.

Intended uses

• —Proactive handover forecasting — predict servingCell1…7 from the mobility and radio history.
• —Cross-city generalisation — train here, test on Kraków, or the reverse.
• —Handover-event detection and classification — predict migration, or reproduce the case taxonomy with a different policy.
• —Cross-density generalisation — the four runs share a map, a deployment and a labelling policy, so density is the only intended difference.
• —Mobility and spatial analysis — x/y/lane against the OSM extract.

Limitations and cautions

1. 1.Landmark coordinates, not surveyed cell sites. The 9 positions come from a tourist-places spreadsheet. The layout is realistically irregular, but it is not an operator's actual deployment.
2. 2.No real radio measurements. Every radio column is Simu5G's model output, inheriting that model's propagation, scheduling and mobility assumptions.
3. 3.Half the rows have no downlink traffic (49.9 % in 900_1), zero-filled across all three rlc*Dl columns.
4. 4.Short vehicle traces. Median ≈98 rows; some vehicles contribute 1–2. A 6-step window with a 7-step horizon needs 13 rows, so short traces yield no training windows — filter before windowing, and expect to lose more rows here than in the Kraków data.
5. 5.`x` and `y` are degrees, not metres. Any scaler fitted on them is valid only inside this ~1.7 km × 1.8 km extent.
6. 6.`lane` is map-specific and partly non-OSM. Zero overlap with the Kraków vocabulary; ~20 % of rows are SUMO internal junction lanes.
7. 7.Density is confounded with seed. One run per density (_1), so a difference between 900_1 and 1400_1 mixes the density effect with run-to-run variance.
8. 8.Label imbalance (6.49 % warning-window rows) — milder than Kraków, still real.
9. 9.`slope` is constant 0 and `Time` duplicates `t`; Object is a simulator module index. None of the three carries signal.
10. 10.`veh_id` dtype differs between the two configs (int in labeled, float in events). Cast before joining.
11. 11.Vehicle ids are not comparable across runs or across cities.
12. 12.Simulator versions unrecorded for these runs, as noted above.
13. 13.Not for real-network deployment as-is. This is a research artefact from a synthetic scenario.

Ethics and privacy

Entirely synthetic. No human subjects, no personal data, no real network traces. veh_id identifies a simulated vehicle. The road geometry comes from OpenStreetMap, © OpenStreetMap contributors, available under the Open Database License; the bundled extract in metadata/ is redistributed under those terms, which are separate from this dataset's CC-BY-4.0 licence.

Licence

CC BY 4.0 — use, share and adapt freely, with attribution. The OpenStreetMap-derived extract in metadata/ remains under ODbL (see above).

Citation

@misc{fumdai_alicante_handover_dataset,
  title        = {FUMD-AI Alicante Vehicular Handover Dataset},
  author       = {Bernad, Cristina and Filiposka, Sonja and Gilly, Katja},
  year         = {2026},
  howpublished = {Hugging Face Hub},
  url          = {https://huggingface.co/datasets/FUMD-AI/alicante-handover-dataset},
  note         = {SUMO + OMNeT++/Simu5G simulation over central Alicante;
                  produced by the FUMD-AI preprocessing workflow}
}

See CITATION.cff for the machine-readable form.

Authors and funding

• —Cristina Bernad — 0000-0001-9537-415X
• —Sonja Filiposka — 0000-0003-0034-2855
• —Katja Gilly — 0000-0002-8985-0639

Funded by the FUMD-AI project, an EOSC GRAVITY Inter Project, Grant Number 25-EOSC-GRV-INTER-013.

Acknowledgements

We gratefully acknowledge Polish high-performance computing infrastructure PLGrid (HPC Centers: ACK Cyfronet AGH) for providing computer facilities and support within computational grant no. PLGINT/2026/019844.

The research work was supported by the Open Science Cloud research laboratory (OSC-LAB) at the Faculty of Computer Science and Engineering (FINKI), Ss. Cyril and Methodius University in Skopje, North Macedonia.

Related resources

• —Sibling dataset: FUMD-AI/krakow-handover-dataset
• —Model: FUMD-AI/handover-forecaster (trained on Kraków, not on this data)
• —Preprocessing workflow: github.com/FUMD-AI/fumd-ai-preprocessing-workflow
• —Training & postprocessing workflow: github.com/FUMD-AI/fumd-ai-training-postprocessing-workflow