Good RSRP, Bad Throughput: What to Check First

Start with the mismatch, not the signal bars

You stop at a location with a strong serving-cell reading, run a speed test and the result is poor. It is tempting to call that a coverage problem because the test happened outside. Usually it is not. RSRP describes the power of the serving reference signal; it does not tell you whether the channel is clean, whether the cell has resources to schedule, whether the handset can use several layers or whether the transport path is busy.

The useful question is therefore not “is RSRP good?” but “which part of the path disagrees with it?” A short, repeatable sequence avoids changing a tilt, opening a fault ticket or blaming the handset before the evidence points there.

Read power and quality together

Capture the serving cell, neighbours, RSRP, RSRQ and SINR at the same time. LTE measurement definitions are specified by 3GPP TS 36.214; the equivalent NR work is covered by 3GPP TS 38.215. The useful field habit is correlation, not a single universal threshold.

Strong RSRP with poor SINR is a different situation from strong RSRP with clean SINR. In the first case, inspect dominant neighbours, repeated serving-cell changes, sector overlap and any indication of interference. In the second case, do not spend the next hour looking for a coverage hole. Move on to allocation and capacity checks.

Use GSM Drive Test to keep measurements, cell identity and location in the same trace. A snapshot is useful; a short route through and beyond the problem area is usually more revealing.

Separate an RF issue from a loaded cell

A handset can see a clean radio channel and still receive little user throughput. The scheduler decides how radio resources are shared, and that decision changes as demand changes. If the log shows good quality while speed collapses only at busy times or in a busy location, compare the test with cell-load, PRB or scheduler information when it is available from the operator.

Do not infer congestion from RSRP. Look for a pattern: stable serving signal, stable quality, modest throughput and a result that changes when demand changes. If you cannot access network counters, repeat the same test at a second time and record the test server, device, band combination and route. That gives the optimisation team something they can actually compare.

Then check whether MIMO is doing useful work

Good signal and available resources do not guarantee that the device is using the spatial layers you expect. Rank indication and channel-state feedback are part of the LTE and NR physical-layer procedures described in 3GPP TS 36.213 and 3GPP TS 38.214. A persistent low rank can be a clue, but it is not a diagnosis by itself: propagation, device capability, configuration and physical branch issues can all affect it.

If the trace suggests a MIMO problem, compare devices where that is permitted, check whether the behaviour follows one sector or one handset, and review branch alarms or field measurements with the site team. Antenna direction and tilt are worth checking only when the wider evidence supports an RF geometry problem. The GSM Azimuth Checker can help verify physical orientation against the design record.

Do not forget transport and the test itself

Application throughput includes more than the air interface. A constrained backhaul path, packet loss, a congested test server, an application in the background or a device-specific limitation can all look like a radio problem. Record latency and packet loss with the throughput result. Repeat the test with a known method before concluding that a sector change is needed.

Record the time, route direction, serving cell, band or carrier information, whether the device was moving, and what changed between a good and bad result. A clean trace with that context is more useful than a long list of isolated values.

A practical order of checks

1. Confirm the symptom. Repeat the test and note device, server, route and time.
2. Read RSRP with RSRQ and SINR. If quality is poor, inspect neighbours, overlap and interference evidence before capacity.
3. Check allocation or load. When quality is clean but throughput is limited, seek scheduler, PRB or utilisation evidence.
4. Review MIMO behaviour. Treat rank or branch observations as clues to test, not proof of a hardware fault.
5. Check transport. Compare latency, loss and repeatability before escalating an RF change.
6. Write the handover note. Include the trace, cell context and the next verification needed.

When to escalate the finding

Escalate a result when it is repeatable, tied to a clear cell or area and supported by a trace that another engineer can reproduce. Phrase the finding as an observation, not a proposed root cause: for example, “throughput falls on this route while serving quality remains stable; verify scheduler allocation and transport counters.” This leaves room for the network team to test the right counters and avoids turning a field impression into an unsupported configuration recommendation.

If the result changes with the device, test server or time of day, note that too. Variability is not a failed measurement; it is often the clue that separates a radio fault from demand, device behaviour or the wider data path.

Frequently asked questions