Drive-Test RF Coverage Analyzer

Synthetic LTE/5G drive-test analysis that behaves like a small RF optimization tool: generate a route, simulate serving-cell KPIs, classify coverage, find weak clusters, and produce a map plus engineering report.

Current validation status: synthetic-data validated; real operator drive-test validation pending.

Run the complete demo:

python -m pip install -e ".[dev]"
python -m drive_test_rf.cli demo --samples 1500 --seed 42

Then open outputs/coverage_map.html and review outputs/rf_analysis_report.md.

Map preview generated from outputs/coverage_map.html:

What Problem It Solves

RF engineers often need to explain coverage holes, cell-border behavior, low SINR, poor throughput, and dropped sessions from drive-test logs. Real logs can contain operator-sensitive site, subscriber, and location data, so this project uses reproducible synthetic measurements to demonstrate the workflow safely.

The project is built for portfolio review by RF Engineers, RAN Optimization Engineers, Network Performance Engineers, Wireless Systems Engineers, Telecom Data Analysts, and Field Test / Drive Test Engineers.

Engineering Workflow

Synthetic route + cell grid
        |
        v
RF model: distance loss, shadowing, cell-border margin, poor zones
        |
        v
KPI generation: RSRP, RSRQ, SINR, throughput, latency, handovers, drops
        |
        v
Analysis: RF score, coverage class, weak clusters, cell/technology summaries
        |
        v
Outputs: CSV summaries, worst locations, interactive map, RF report

Features

• Public GPS route around Munich with synthetic serving cells.
• LTE, 5G NSA, and 5G SA KPI differences.
• RSRP degradation with serving-site distance and attenuation zones.
• SINR degradation from interference and cell-border conditions.
• Throughput tied to SINR, RSRP, technology capability, and loading.
• Latency increase under poor RF conditions.
• Handover modeling with serving-cell margin and hysteresis.
• Dropped-session indicators limited to poor radio conditions.
• Weak coverage cluster detection instead of isolated one-sample alarms.
• Folium HTML map with colored samples, site markers, weak segments, and popups.
• Markdown RF report with segment-specific engineering actions.
• Tests that validate synthetic RF relationships, not just file creation.

Example Output

After running the demo with 1,500 samples, the project writes:

• data/sample_drive_test.csv
• outputs/coverage_summary.json
• outputs/coverage_summary.csv
• outputs/weak_coverage_locations.csv
• outputs/worst_rf_locations.csv
• outputs/cell_kpi_summary.csv
• outputs/technology_summary.csv
• outputs/coverage_map.html
• outputs/rf_analysis_report.md

Open outputs/coverage_map.html to inspect the route, weak clusters, serving sites, and sample-level KPI popups.

Generated outputs/ artifacts are reproducible and ignored by git except for outputs/README.md. The included data/sample_drive_test.csv is synthetic, small enough for repository review, and can be regenerated with the commands below.

Example engineering findings from the generated report include:

• Weak clusters with dominant serving cell, average RSRP/SINR, DL throughput, latency, handovers, and dropped sessions.
• Interference-limited notes when SINR is poor while RSRP remains usable.
• Cell-border observations based on handovers and low serving-cell margin.
• Throughput degradation comparison between good/excellent and fair/poor samples.

KPI Thresholds

KPI	Excellent	Good	Fair	Poor
RSRP	>= -80 dBm	-90 to -80 dBm	-100 to -90 dBm	< -100 dBm
RSRQ	>= -10 dB	-12 to -10 dB	-15 to -12 dB	< -15 dB
SINR	>= 20 dB	13 to 20 dB	0 to 13 dB	< 0 dB

The final coverage class is based on a weighted RF score:

• RSRP: 30%
• SINR: 25%
• RSRQ: 15%
• Downlink throughput: 20%
• Latency: 10%

This is intentionally explainable. It is not a proprietary operator score and should be adjusted before real network acceptance work.

Installation

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e ".[dev]"

Using uv:

uv venv
source .venv/bin/activate
uv pip install -e ".[dev]"

Quickstart

Generate synthetic drive-test data:

python -m drive_test_rf.cli generate-data --output data/sample_drive_test.csv --samples 1500 --seed 42

Analyze an input file:

python -m drive_test_rf.cli analyze --input data/sample_drive_test.csv --output-dir outputs

Run the complete demo:

python -m drive_test_rf.cli demo --samples 1500 --seed 42

Quality Checks

ruff check .
mypy src
pytest

The test suite includes RF realism checks:

• distance from serving site vs RSRP should be negatively correlated
• SINR vs downlink throughput should be positively correlated
• fair/poor coverage should have lower throughput and higher latency
• dropped sessions should mostly occur in fair/poor coverage
• handover rate should be non-zero without excessive ping-pong behavior

Repository Structure

src/drive_test_rf/
  synthetic_data.py     Synthetic route, serving-cell, and KPI generation
  kpi_rules.py          KPI thresholds, RF score, coverage classes
  analyzer.py           Route, weak-segment, cell, and technology summaries
  validation.py         Synthetic RF realism checks
  map_visualizer.py     Folium coverage map generation
  reporting.py          Markdown engineering report generation
  cli.py                Command-line workflow
docs/
  methodology.md
  kpi_thresholds.md
  real_drive_test_ingestion.md
  portfolio_notes.md
tests/
  test_synthetic_realism.py
  ...

Real Drive-Test Extension Path

The current parser expects the project schema generated by synthetic_data.py. Real TEMS, Nemo, QualiPoc, or scanner exports can be added later through a parser layer that maps vendor-specific column names into this internal schema.

That work must include anonymization of operator identifiers, site IDs, IMSI/IMEI or device identifiers, exact customer routes, and any confidential network configuration. See docs/real_drive_test_ingestion.md.

Limitations

• Synthetic data only; no real operator drive-test validation yet.
• Site positions and cell IDs are illustrative.
• Propagation logic is transparent and lightweight, not a calibrated planning model.
• No vendor log parser is included yet.
• No production network decisions should be made from these generated results.

Future Work

• TEMS/Nemo/QualiPoc CSV parser adapters with explicit column mapping.
• Sector antenna pattern and azimuth-aware dominance modeling.
• PCI collision/confusion checks.
• Handover failure cause parsing for real UE logs.
• Capacity vs RF-limited throughput separation using load counters.
• Plot exports for route-distance KPI traces and CDFs.

Author

Omid Rahimi