A simple 6-step guide to how RF engineers analyze LTE and 5G drive-test KPIs: clean the log, classify RSRP and SINR, summarize, find weak cells and report.
If you have ever opened a drive-test log with tens of thousands of rows in Excel, you know the pain. The file opens slowly, every pivot table is rebuilt by hand, and next week you repeat the whole thing again.
This post covers that workflow: what an RF engineer actually does with a log, in what order, and why.
Why a clear workflow matters
- Size: Drive-test logs grow fast, and big files make spreadsheets slow.
- Repetition: The same cleaning and pivot steps are done for every new log.
- Mistakes: Manual steps mean one wrong filter can quietly change your results.
- Scale: Comparing 50 logs by hand is painful. A repeatable process treats 5 files and 50 files the same way.
The KPIs in 60 seconds
| KPI | What it tells you | Unit | Common rule of thumb |
|---|---|---|---|
| RSRP | Coverage: how strong the cell's reference signal is | dBm | ≥ -80 excellent, -90 to -80 good, -100 to -90 fair, below -100 poor |
| RSRQ | Quality: signal relative to total received power (interference and load show up here) | dB | ≥ -10 good, -15 to -10 fair, below -15 poor |
| SINR | How clean the signal is compared to interference and noise. It drives throughput | dB | ≥ 20 excellent, 13 to 20 good, 0 to 13 fair, below 0 poor |
These are common rules of thumb. Your operator will have its own targets, so always use those. In 5G NR logs you will usually see the same KPIs named SS-RSRP, SS-RSRQ and SS-SINR.
The workflow: 6 steps
1. Export and load the log
Your drive-test tool exports a table (usually CSV) with one row per measurement: time, location, technology (LTE or NR), cell ID (PCI), RSRP, RSRQ, SINR and downlink throughput. This is your raw material, so keep an untouched copy before you change anything.
2. Clean the data
Never trust a raw log. Real exports contain:
- missing values
- placeholder values such as 0 instead of a real reading
- readings outside the valid range (RSRP is normally reported between -140 and -44 dBm, RSRQ between -19.5 and -3 dB)
Remove these rows first. If you skip this step, a few bad rows can drag your averages and charts in the wrong direction.
3. Classify the measurements
Turn raw numbers into the labels that appear in reports: Poor, Fair, Good, Excellent. Then count what percentage of samples falls in each class, for LTE and NR separately. This is the classic "samples per quality class" table, and it is the easiest way to explain network quality to non-RF people.
4. Summarize with the right numbers
Do not stop at the average. For each technology, calculate:
- Mean and median: the overall picture.
- P10 (10th percentile): the level that the weakest 10 percent of samples fall below. This exposes coverage holes that averages hide.
- Coverage percentage: the share of samples that meet your threshold, for example RSRP better than -100 dBm.
- Average throughput: to connect the radio quality to what users actually get.
Read the summary like an RF engineer. A good average with a poor P10 means you have coverage holes in specific places, not a problem everywhere.
5. Find the weakest cells
Group the same numbers by cell (PCI) and sort by the worst median SINR or worst P10 RSRP. The cells at the top of that list are your first candidates for optimization: antenna tilt, power settings, neighbour relations or interference.
6. Visualize and report
Two charts do most of the talking:
- RSRP CDF: shows what share of samples are below any RSRP value. Draw a vertical line at your threshold, and you can see the percentage of poor-coverage samples at a glance. Plot LTE and NR as separate lines.
- Coverage map: plot each measurement at its latitude and longitude, colored by RSRP from red (weak) to green (strong). Red patches show where to check on site.
Finish with a short report: the summary table, the weakest cells, the two charts and your recommendations. Your manager or customer gets one clear page instead of a pile of raw numbers.
Make it repeatable
Once the six steps are fixed, turn them into a routine that you can run on every new log: a saved template, a macro, or a script. Then adding 50 more logs does not mean 50 more hours of work, and everyone on your team gets the same results from the same data.
Gotchas to watch out for
Do not average dBm blindly. RSRP is in dBm, a logarithmic scale. A plain average of dBm values is not the same as the average power. Strictly speaking, you should convert to linear power, average it, and convert back. Many drive-test reports still use the simple mean, and that is fine as long as your team is consistent and writes down which method it used. Percentiles like P10 and P50 do not have this problem, which is one more reason to report them.
Keep LTE and NR separate. They use different bandwidths and frequencies, so mixing them in one average is misleading.
Thresholds are not universal. Use the targets from your operator or project, not a blog post, including this one.
Check units and ranges. Different tools export in different units and column names. Check a few rows by eye before you trust any result.
Recap
Good KPI analysis is not about the tool. It is about repeating the same RF thinking every time: clean the log, classify the measurements, summarize with percentiles, find weak cells, visualize, and report. Once those six steps are clear, you can use them with any tool and automate them whenever your logs grow.
Over to you: which KPI do you check first on a new drive test: RSRP, SINR or something else? Tell me in the comments.
I write about telecom tools, LTE, 5G NR and O-RAN in simple words at TechLTE World. Follow me here on dev.to if you want more telecom explainers.
Top comments (0)