The KPI Framework for 5G NR
5G network performance is measured through Key Performance Indicators (KPIs). 3GPP TS 28.554 defines them in seven groups — accessibility, integrity, utilization, retainability, mobility, energy efficiency and reliability — and builds each one from performance measurements (PM counters) defined in 3GPP TS 28.552. Day to day, three questions do most of the work: accessibility (can the user connect?), retainability (does the connection stay up?) and integrity (is the quality good enough?).
Two things the specifications do not give you. The first is thresholds: TS 28.554 defines formulas and no target values, so every percentage in the target columns below is an example, not a standard. The second is vendor names: each vendor exposes the 3GPP measurements under its own counter names (Ericsson's start with pm), so map them through your vendor's counter reference. Counter names on this page follow TS 28.552 Release 18; where a name changed between releases, the table says so.
Unlike 4G KPIs, 5G introduces slice-aware KPIs, beam-level measurements, and dual-connectivity counters. An operator running NSA and SA simultaneously must track both NR and LTE-anchor KPIs.
Master KPI Table
Each KPI below is mapped to its formula and the TS 28.552 measurements behind it. Most measurements are reported per subcounter — per establishment cause, per 5QI — so "summed" means summed over those. The example targets are illustrations only: 3GPP sets none, so set yours from your own network's baseline.
| KPI | Formula | PM Counters (TS 28.552) | Example target | Category |
|---|
| RRC Setup Success Rate | (RRC setups completed / RRC setup requests) x 100 | RRC.ConnEstabSucc.Cause / RRC.ConnEstabAtt.Cause, each summed over causes | >= 99.0% | Accessibility |
| NG Connection Success Rate | (first AMF answers / INITIAL UE MESSAGEs sent) x 100 | UECNTX.ConnEstabSucc.Cause / UECNTX.ConnEstabAtt.Cause, summed | >= 99.5% | Accessibility |
| DRB Accessibility (CSSR) | RRC setup SR x NG connection SR x DRB setup SR x 100 (TS 28.554 6.2.4) | the four above, plus DRB.EstabSucc.5QI / DRB.EstabAtt.5QI | >= 98.5% | Accessibility |
| QoS Flow Setup Success Rate | (QoS flows set up / QoS flows requested) x 100 | QF.EstabSuccNbr.5QI / QF.EstabAttNbr.5QI, summed | >= 98.5% | Accessibility |
| QoS Flow Retainability | Abnormal releases of active flows per second of session time (TS 28.554 6.5.1 — a rate, not a %) | QF.RelActNbr.QoS / QF.SessionTimeQoS.QoS | Trend against your baseline | Retainability |
| QoS Flow Drop Ratio | (Abnormal active releases / all release attempts) x 100 — an operator form, not in TS 28.554 | QF.RelActNbr.QoS / QF.ReleaseAttNbr.5QI, summed | <= 0.5% | Retainability |
| DL User Throughput | Volume / active transmit time, per data burst — computed by the gNB | DRB.UEThpDl (kbit/s) | >= 100 Mbps (mid-band) | Integrity |
| UL User Throughput | As above, uplink | DRB.UEThpUl (kbit/s) | >= 20 Mbps (mid-band) | Integrity |
| DL / UL Traffic Volume | PDCP SDU volume per period | DRB.PdcpSduVolumeDL_Filter / DRB.PdcpSduVolumeUL_Filter (Mbit) | — | Traffic |
| DL Delay in RAN | CU-UP part + DU part (TS 28.554 6.3.1 — defined per network, not per cell) | DRB.PdcpSduDelayDl_Filter + DRB.PdcpF1DelayDl_Filter + DRB.RlcSduDelayDl + DRB.AirIfDelayDl (each in 0.1 ms) | <= 10 ms (eMBB) | Integrity |
| Intra-gNB Handover Success Rate | (HO executions completed / HO executions started) x 100 | MM.HoExeIntraSucc / MM.HoExeIntraReq | >= 98.0% | Mobility |
| Inter-gNB Handover Success Rate | Preparation SR x execution SR x 100 | MM.HoPrepInterSucc / MM.HoPrepInterReq x MM.HoExeInterSucc / MM.HoExeInterReq | >= 96.0% | Mobility |
| RACH Load | Preambles received per second — TS 28.552 has no RACH success counter | RACH.PreambleDedCell, RACH.PreambleACell, RACH.PreambleBCell | Trend against your baseline | Accessibility |
| CQI Distribution | % of wideband CQI reports at CQI >= 10, within one CQI table | CARR.WBCQIDist.BinX.BinY.BinZ (X = CQI, Y = rank, Z = CQI table) | >= 70% at CQI 10+ | Integrity |
| PRB Utilization (DL) | (Used DL PRBs / Available DL PRBs) x 100 | RRU.PrbUsedDl / RRU.PrbAvailDl; or RRU.PrbDl, already a % (RRU.PrbTotDl in Release 17) | <= 70% (congestion warning) | Utilization |
Accessibility vs Retainability vs Integrity
Understanding which category a KPI falls into determines escalation paths and troubleshooting focus.
Accessibility KPIs measure whether users can establish connections. Poor accessibility typically indicates RF coverage issues (low RSRP/SINR), RRC congestion (max connected UEs reached), or core network signaling failures (AMF overload, SCTP failures).
Retainability KPIs measure whether established connections stay active. Drops are caused by handover failures, radio link failure (RLF) due to weak coverage, transport congestion (F1/Xn backhaul saturation), or core network issues (GTP-U path failure).
Integrity KPIs measure quality of the active connection. Poor integrity manifests as low throughput (high PRB utilization, poor CQI), high latency (scheduling delays, HARQ retransmissions), or jitter (affecting voice/video QoE).
| Category | Focus | Typical Root Causes | Primary Counters |
|---|
| Accessibility | Can the user connect? | Poor RSRP, RRC congestion, AMF failures | RRC.ConnEstabAtt.Cause, RRC.ConnEstabFailCause.NoReply, UECNTX.ConnEstabAtt.Cause |
| Retainability | Does it stay connected? | RLF, HO failure, transport loss | QF.RelActNbr.QoS, UECNTX.RelReq.Cause |
| Mobility | Do handovers complete? | Missing neighbours, late triggers, Xn transport | MM.HoPrepInterReq, MM.HoExeInterSucc |
| Integrity | Is quality sufficient? | Low CQI, high PRB load, HARQ retx | DRB.UEThpDl, CARR.WBCQIDist.BinX.BinY.BinZ |
| Capacity | Is the network saturated? | PRB utilization, connected UE count | RRU.PrbUsedDl, RRC.ConnMean |
Worked Example 1: Calculating RRC Setup Success Rate
Scenario: A gNB cell in a dense city centre reports the following PM counter values for a busy hour (17:00-18:00), each summed over establishment causes:
RRC.ConnEstabAtt.Cause = 45,200RRC.ConnEstabSucc.Cause = 44,870
Calculation:
RRC Setup SR = (RRC.ConnEstabSucc.Cause / RRC.ConnEstabAtt.Cause) x 100
RRC Setup SR = (44,870 / 45,200) x 100
RRC Setup SR = 99.27%
Assessment: This exceeds a 99.0% target. TS 28.552 splits the 330 failures three ways:
| Failure Cause | Counter | Count | % of Failures |
|---|
| RRCSetup sent, no RRCSetupComplete | RRC.ConnEstabFailCause.NoReply | 180 | 54.5% |
| RRCReject sent (e.g. overload) | RRC.ConnEstabFailCause.NetworkReject | 95 | 28.8% |
| Any other reason | RRC.ConnEstabFailCause.Other | 55 | 16.7% |
NoReply is the one to chase. The request arrived, but the exchange never finished — the RRCSetup was lost on the way down or the RRCSetupComplete on the way up — which points at the cell edge: weak coverage or uplink interference. Check the SS-RSRP distribution (L1M.SS-RSRP.Bin) and the UL noise floor before changing tilt or SSB beams. The network rejects may mean the gNB is hitting its connected-UE limit at peak hours; compare against RRC.ConnMax.
This is only the first step of a call setup. The full call setup success rate — TS 28.554 calls it DRB accessibility, and leaves mo-Signalling setups out of it — multiplies this by the NG connection success rate (UECNTX.ConnEstabSucc.Cause / UECNTX.ConnEstabAtt.Cause) and the DRB setup success rate.
Worked Example 2: Drop Rate and Retainability Analysis
Scenario: An operator monitors a cluster of 15 gNBs on n41 (2.5 GHz) in a large city. Weekly aggregated counters, summed over 5QI:
QF.ReleaseAttNbr.5QI = 2,340,000 (all QoS flow release attempts)QF.RelActNbr.QoS = 19,800 (flows released while active, for a reason other than normal release, user inactivity or a successful handover)QF.SessionTimeQoS.QoS = 99,000,000 s (time the flows were actually in session)
Retainability, the TS 28.554 way — a rate:
QoS Flow Retainability = QF.RelActNbr.QoS / QF.SessionTimeQoS.QoS
QoS Flow Retainability = 19,800 / 99,000,000 s
QoS Flow Retainability = 0.0002 active releases per second (0.72 per session-hour)
Drop ratio, the familiar dashboard form — a percentage:
QoS Flow Drop Ratio = (QF.RelActNbr.QoS / QF.ReleaseAttNbr.5QI) x 100
QoS Flow Drop Ratio = (19,800 / 2,340,000) x 100
QoS Flow Drop Ratio = 0.846%
The rate is normalised by how long flows were actually in use, so it compares fairly between busy and quiet cells; the ratio is the one most people recognise. You will meet both.
Assessment: 0.846% exceeds a 0.5% target and needs investigation. Your vendor's release-cause counters — or
UECNTX.RelReq.Cause, the gNB-DU's release requests counted by F1AP cause — split the abnormal releases:
- Radio link failure (RLF): 11,200 (56.6% of abnormal)
- Handover failure: 5,400 (27.3%)
- Transport layer failure: 3,200 (16.1%)
The dominant contributor is RLF. The SS-RSRP distribution (L1M.SS-RSRP.Bin) shows 18% of samples below -110 dBm, indicating coverage holes. The handover failures correlate with inter-gNB Xn delays exceeding 100 ms during congestion.
Corrective actions: Increase SSB transmit power by 3 dB on affected cells, adjust A3 handover offset from 3 dB to 2 dB to trigger earlier handovers, and verify F1 transport link capacity.
Example NOC Dashboard Thresholds
NOC dashboards usually carry several threshold levels per KPI, each triggering a different escalation path. 3GPP defines none of these values. The table shows the shape — four levels per KPI — with example figures to replace from your own network's baseline.
| KPI | Green (Normal) | Yellow (Warning) | Orange (Minor) | Red (Critical) |
|---|
| DRB Accessibility (CSSR) | >= 99.0% | 98.0-99.0% | 96.0-98.0% | < 96.0% |
| QoS Flow Drop Ratio | <= 0.5% | 0.5-1.0% | 1.0-2.0% | > 2.0% |
| DL Throughput (avg) | >= 100 Mbps | 50-100 Mbps | 20-50 Mbps | < 20 Mbps |
| Latency (user plane) | <= 10 ms | 10-20 ms | 20-50 ms | > 50 ms |
| HO Success Rate | >= 98.0% | 96.0-98.0% | 92.0-96.0% | < 92.0% |
| PRB Utilization | <= 60% | 60-75% | 75-85% | > 85% |
Advanced KPI Considerations
Slice-Aware KPIs
Most TS 28.554 KPIs have a per-slice (S-NSSAI) form, and the TS 28.552 measurements behind them carry .SNSSAI subcounters. For example, a factory automation slice (SST=2, SD=0x000002) may have a latency target of 5 ms, while a consumer eMBB slice (SST=1, SD=0x000001) may tolerate 15 ms.
Beam-Level KPIs
Massive MIMO deployments need per-beam monitoring. TS 28.552 reports the SS-RSRP distribution per SSB beam (L1M.SS-RSRP.Bin, measured on each Beam object), and Release 18 adds an SS-SINR distribution per serving SSB (MR.SS-SINRPerSSB.Bin). RACH preambles are counted per SSB too (RACH.PreambleA.Ssb and its siblings). Operators use beam-level RSRP and SINR to detect blocked beams (e.g., new construction obstructing a specific azimuth) and trigger beam reconfiguration.
EN-DC KPIs (NSA Mode)
In NSA mode, the UE maintains dual connectivity to both LTE (master node) and NR (secondary node). Additional KPIs include:
- SgNB Addition Success Rate: (SgNB Add Succ / SgNB Add Att) x 100; example target >= 95%
- SgNB Abnormal Release Rate: (SgNB Abnormal Rel / SgNB Rel) x 100; example target <= 2%
- SCG Failure Rate: Tracks secondary cell group radio link failures
KPI Correlation Patterns
Experienced NOC engineers recognize correlations that accelerate troubleshooting:
- Low RRC setup success + high
RRC.ConnEstabFailCause.NoReply: the setup starts and never finishes — an uplink coverage or interference issue at the cell edge. Check UL noise floor and RACH configuration.
- High drop rate + High HO failure: Mobility-related drops dominate. Check neighbor relations, A3/A5 event thresholds, and X2/Xn transport.
- Low throughput + High PRB utilization: Capacity exhaustion. Consider carrier aggregation, additional spectrum, or traffic offload.
- High latency + Normal PRB utilization: Scheduling inefficiency or transport bottleneck. Check PDCP/RLC retransmissions and backhaul RTT.
PM Counter Collection
PM counters are collected from the gNB (over O1, in O-RAN terms) as performance data files at a configurable granularity period — TS 28.550 lists 5, 15 and 30 minutes and 1, 12 and 24 hours. The counters feed into OSS platforms (Ericsson ENM, Nokia NetAct, Huawei iManager U2020) where KPIs are computed and visualized.
For near-real-time monitoring, TS 28.550 also defines performance data streaming, with granularity periods in seconds, carried over WebSocket (TS 28.532). That is the feed for anomaly detection and automated optimization loops.
> Key Takeaway: 5G KPIs are defined in TS 28.554 and built from the PM counters in TS 28.552, with accessibility, retainability and integrity doing most of the daily work. Mastering the formulas, setting thresholds from your own baseline, and knowing how to decompose aggregate KPIs into root causes is the core competency of 5G network operations.
Formulas are the easy part; the arguments happen over which counter feeds them
and whether the denominator means what you think. Three parsers take vendor
exports directly — Ericsson KGET,
Huawei counters and
Nokia RAML.
And when a KPI moves without an obvious cause,
intermittent handover failures
and AMF overload are two log sets where
the KPI shift is real and the reason is buried — which is the actual job.