TL;DR
- An optimisation loop closes only when the same KPI definition is used for targeting, for verification and for acceptance.
- Most loops break at the handover from the field team to the planning team, not at the measurement.
- Track accessibility, retainability and mobility together: improving one while degrading another is not an improvement.
Which KPIs belong in the loop?
Three levels, and every one of them must be present. Accessibility covers setup success and random access success. Retainability covers drop rate and abnormal release. Mobility covers handover success, ping-pong rate and inter-frequency transition success. A loop that tracks only throughput will happily accept a plan that improves peak rates while making the network harder to stay connected to.
The critical requirement is not which KPIs you choose but that the same definition is used for targeting, for verification and for acceptance. When the field team targets one drop-rate definition and the acceptance report uses another, the loop appears to close and does not: the numbers improve and the network does not.
| KPI | Correct use | Common misuse |
|---|---|---|
| RRC setup success rate | Cluster-level accessibility target | Averaged over cells of very different load |
| E-RAB or PDU session drop rate | Cell-level retainability target | Computed including handover drops, hiding mobility problems |
| Handover success rate | Neighbour pair level, not cell level | Reported per cell, which averages away the bad pairs |
| DL throughput 5th percentile | The capacity design target | Replaced by cell average, which hides the tail |
| PRB utilisation | Load context for every other KPI | Ignored, so loaded and unloaded cells are compared directly |
How do you set a target that is achievable?
Start from the cluster's own baseline, not from a vendor benchmark. A target copied from a different market with different site density, different spectrum and different clutter produces a project that fails for reasons nobody controls. The defensible target is the current distribution's upper quartile: what the best-performing quarter of cells already achieves is, by definition, achievable in that network.
Then express the target as a distribution, not a mean. "95% of cells above 98.5% setup success" is a target. "Cluster average above 98.5%" is a target that a few very good cells can satisfy on behalf of many bad ones.
Where do optimisation loops usually break?
Four places, in order of frequency. First, at the handover from the field team to the planning team: the field team finds a problem that needs a parameter change outside their authority, and the request has no owner. Second, at the verification step: a change is made and never measured, so the loop becomes a list of activities rather than a sequence of verified improvements.
Third, at the definition of the cluster: cells are optimised individually and the cluster-level KPI does not move, because the improvement in one cell was a degradation in its neighbour. Fourth, at the record: nobody writes down what was changed, so a regression six months later cannot be attributed and the same change is tried again.
How do you verify a change without a full cluster drive test?
Use measurement reports and counters first, and drive tests only to answer questions the counters cannot. A before-and-after comparison of the changed cell and its immediate neighbours, over matched time-of-day windows and comparable traffic, is enough to confirm or reject most parameter changes. The comparison must include the neighbours, because the expected signature of a good change is a transfer of load or coverage, not a uniform improvement.
Reserve drive tests for three cases: validating a prediction in an area with no traffic, resolving a complaint that counters do not explain, and acceptance against a contractual coverage obligation. Using drive tests for routine verification is expensive, slow, and biased toward roads — which is precisely where the network is usually best.