Why the order matters
Most KPI investigations fail not because the engineer lacks data but because they start in the wrong place. Parameters are the easiest thing to change, so they are usually changed first — which means a coverage problem gets a configuration answer, the KPI does not recover, and the network is left carrying a parameter change nobody can justify later.
A fixed order of elimination avoids that. Work outward from the physics to the configuration, and stop at the first layer that explains the symptom.
The elimination sequence
- Coverage. Is there enough signal? Check RSRP distribution across the cell and at the reported failure locations. A coverage answer is a physical answer — tilt, azimuth, power, height, or a new site. Nothing downstream can fix an absent signal.
- Interference. Is the signal usable? Compare SINR against RSRP. Good RSRP with poor SINR means too many contributors: check overshoot, cell overlap, PCI conflicts and external sources. Note that adding power here makes things worse.
- Configuration. Are the parameters right for this radio environment? Neighbour relations, handover offsets and time-to-trigger, admission control thresholds. Only meaningful once you know the radio conditions the parameters are operating in.
- Capacity. Is there resource to serve the demand? Resource block utilisation, active user count, scheduler behaviour at busy hour. A cell that is covered, clean and correctly configured can still fail purely on load.
The one thing to record
Write down which layer explained the symptom and what evidence closed it out. That record is what makes the next occurrence a five-minute job instead of a repeat investigation — and it is what makes a change defensible at review.
Reading counter movement
A KPI is a ratio, so it can move because the numerator moved, because the denominator moved, or both. Reading the underlying counters tells you which — and that usually names the fault directly.
| KPI | Numerator | Denominator | What movement means |
|---|---|---|---|
| RRC SR | RRC.ConnEstabSucc | RRC.ConnEstabAtt | Falling — devices cannot connect. Check coverage and random access. |
| E-RAB SR | E-RAB.EstabInitSucc | E-RAB.EstabInitAtt | Falling — bearer setup failing. Check transport to the core and resource block load. |
| DCR | E-RAB.RelAbnormal | E-RAB.RelTotal | Rising — drops increasing. Check radio link failure causes and core-side releases. |
| Handover SR | HO.ExeSucc | HO.ExeAtt | Falling — mobility problem. Check overlap, neighbour definitions and interface availability. |
| DL throughput | DRB.ThpVolDl | DRB.ThpTimeDl | Falling — less data per unit of scheduled time. Check utilisation and interference. |
| PDSCH BLER | PDSCH.DTX | PDSCH.Total | Rising — retransmissions. Check SINR and link adaptation behaviour. |
Check the denominator first
A success rate that improves because attempts collapsed is not an improvement. If a KPI moves favourably, confirm the denominator held before reporting it — a cell that has stopped being used will show excellent statistics.
Drop causes and where to look
| Category | Likely root cause | Action |
|---|---|---|
| Radio link failure | Coverage hole, high interference, or handover ping-pong | Coverage work; review time-to-trigger and A3 offset; antenna tilt |
| Release, base station initiated | Abnormal device state, RLC retransmission limit reached | Device logs, review inactivity timers |
| Release, core initiated | Gateway or mobility management disconnection, packet data network error | Escalate to core; interface trace analysis |
| Device lost | Deep indoor location, or the coverage boundary | Coverage layer design; consider a dedicated indoor solution |
| Handover failure leading to drop | Missing inter-site interface, or an undefined neighbour | Add the interface; audit and correct the neighbour list |
Handover types and their parameters
Handover failures are frequently misattributed because different handover types fail for different reasons and are governed by different parameters. Establish which type is failing before touching anything.
| Type | Interface | Path switch | Governing parameters |
|---|---|---|---|
| Intra-site, intra-frequency | Internal | None | A3 offset, time-to-trigger, hysteresis |
| Inter-site, direct interface | X2 / Xn | Direct | Interface existence, cell individual offset |
| Inter-site, core mediated | S1 / NG | Via core | Core latency and load |
| LTE to NR (dual connectivity) | X2 / Xn | Secondary node add or change | B1 / B2 thresholds, master and secondary group config |
| Inter-RAT to legacy | Core mediated | Via core | B2 threshold, time-to-trigger |
Change one thing at a time
Change a single parameter, on a defined cluster, and give it a full traffic cycle before judging the result. Two changes at once produce a result you cannot attribute and cannot repeat, and a weekend is not a traffic cycle.