Four questions, four pillars
Radio network performance is reported through four families of KPI. They are not an arbitrary grouping — each answers a different question a subscriber would ask, in the order they would ask it.
- Accessibility — can I get on the network?
- Retainability — once on, do I stay on?
- Mobility — does it keep working while I move?
- Integrity — is the service any good while it lasts?
A network can pass three and fail one, and the failure is invisible in a summary score. Report them separately, always.
How stage success rates compound
Most accessibility KPIs are a chain of independent stages, and a chain multiplies. This is the single most misread property of the framework.
CSSR = (RRC Succ / RRC Att) × (E-RAB Init Succ / E-RAB Init Att) × 100%
Each stage multiplies. A respectable 99 per cent RRC success against a respectable 99 per cent E-RAB success yields 98.01 per cent CSSR — below a 99 per cent target, with neither stage looking wrong in isolation.
The practical consequence: never chase a compound KPI directly. Decompose it, find which stage moved, and work on that stage. A CSSR figure on its own tells you that something is wrong, not what.
Accessibility
Accessibility covers everything between a device deciding to connect and having a usable bearer. Its two stages fail for entirely different reasons.
- RRC establishment fails on the radio — weak uplink, random access collisions, poor coverage at the point of attempt.
- E-RAB establishment fails on resources or transport — admission control rejecting the bearer, resource block exhaustion, or a problem on the interface to the core.
A falling RRC success rate points at coverage and random access. A falling E-RAB success rate with healthy RRC points at load or transport. They are rarely the same fault.
Retainability
DCR = Abnormal releases / (Successful setups + Abnormal releases) × 100%
Lower is better. The critical detail is the numerator: only abnormal releases count. A normal, device-initiated release is a session ending properly and must not be counted as a drop.
Getting the normal-versus-abnormal distinction wrong is the most common way a retainability figure becomes meaningless. Confirm which release causes the counter includes before comparing across vendors or across releases.
Mobility
Mobility is measured as handover success rate, but it is governed by the event that triggers the handover in the first place. In LTE and NR that is usually the A3 event — a neighbour becoming better than the serving cell by an offset, for long enough.
Mn + CIO − Hys > Ms + Ofn + Ocs + Off
Mn neighbour measurement, Ms serving measurement, Off the A3 offset, Hys hysteresis, CIO the cell individual offset, Ofn and Ocs the frequency and cell specific offsets. Time-to-trigger then requires the condition to hold before the handover is executed.
The two parameters that matter most are offset and time-to-trigger, and they trade against each other:
- Too eager — low offset, short time-to-trigger — produces ping-pong: repeated handovers between two cells, each one an opportunity to fail.
- Too reluctant — high offset, long time-to-trigger — holds the device on a degrading cell until the radio link fails outright, which is recorded as a drop rather than a handover failure.
A mobility problem therefore frequently shows up in the retainability KPI. If drops rise without any coverage change, look at the mobility parameters before looking for a coverage hole.
Integrity
Integrity is throughput and latency — what the connection is actually worth once it is established and held. It is the only pillar with no universal target, because the acceptable figure depends entirely on what is being carried.
Throughput is measured as delivered volume over active time. The active time qualifier matters: dividing by wall clock instead of scheduled time makes a lightly loaded cell look slow, and hides a genuinely congested one.
C = B × log₂(1 + SINR)
The ceiling any integrity KPI is working against. Since capacity scales only logarithmically with SINR, cleaning up an already-clean cell yields very little — once SINR is good, throughput problems are resource problems.
Reference table
| KPI | Formula | Indicative target | Key counters |
|---|---|---|---|
| CSSR | RRC SR × E-RAB SR | ≥ 99.0% | RRC.ConnEstab.Att / Succ; E-RAB.EstabInit.Att / Succ |
| DCR | Abnormal / (Succ + Abnormal) | ≤ 0.5% | E-RAB.RelAbnormal; RRC.ConnRelease.Cause |
| Handover SR | HO Succ / HO Att | ≥ 99.0% | HO.ExeAtt.ToEUTRAN; HO.ExeSucc.ToEUTRAN |
| DL throughput | DL volume / active time | Service dependent | DRB.UEThpDl; pdcp.SduDelayDl |
| UL throughput | UL volume / active time | Service dependent | DRB.UEThpUl; UL SINR average |
Targets are a starting point, not a standard
The figures above are the values commonly used as acceptance thresholds, but the binding definition is always the operator's own. Counter names also vary by vendor and by software release. Confirm both against the specific network before reporting against them.