Walk into any 5G optimization team meeting in 2026 and you will hear three vendor names spoken more often than the word “3GPP.” Engineers debate the meaning of one vendor's counter as if it were a law of physics, then translate it — usually badly — into another vendor's terminology. New hires inherit a tribal vocabulary and never learn what the underlying specification actually says. Senior engineers carry a single vendor's mental model from job to job, surprised each time the next employer's network behaves differently.

This book is the antidote. Every page in front of you is grounded in the publicly available 3GPP Technical Specifications. Every counter is referenced by its 3GPP family from TS 28.552, not a vendor PM name. Every KPI is derived from TS 28.554. Every parameter is cited to its specification clause. Every call flow follows the message names defined in TS 38.331, TS 38.413, TS 38.423, and TS 37.340. Where vendor implementations diverge from the standard — and they do — we say so, but we never let proprietary vocabulary become the primary reference.

Who This Book Is For

This book is written for the working 5G optimization engineer — the person whose job is to look at a poor cluster of cells, understand what is wrong, and make it right. It assumes you have completed an introductory 5G NR course and that you can read a basic call flow. It does not assume you have memorised any specification clause; we will quote what matters and tell you where to read more.

It will also be useful to:

• RF planners who want to understand how planning choices manifest in live KPIs.
• Core/IMS engineers working on VoNR and slicing who need a solid RAN view.
• Drive-test engineers moving into post-processing and root-cause analysis.
• Test engineers writing automation against PM counters and trace files.
• Trainers, instructors, and graduate students who want a single specification-aligned reference.

How To Read This Book

The book is organised as a learning path. Part I builds the foundations: the optimization mindset, the NR architecture, and the 3GPP KPI/counter framework. Parts II through VI take you through the four classical optimization domains — coverage, accessibility, mobility, throughput — plus retainability. Part VII tackles the advanced domains that increasingly dominate 5G work: NSA/EN-DC, VoNR, slicing, and energy saving. Part VIII closes with the engineering workflow that ties everything together.

You can read it cover-to-cover, or you can use it as a reference: each chapter is self-contained enough that you can drop into “Chapter 14 — Intra-gNB Handover” without rereading earlier material. Cross-references are explicit. The appendices are designed to live next to your monitor.

How To Use The Examples

Every numerical example in this book uses parameter values that are typical for production deployments but are not tied to any specific vendor's defaults. Where the specification defines a value range (e.g., q-RxLevMin: −140 to −44 dBm), we will tell you both the range and a sensible starting point. Where the specification leaves the value to vendor implementation, we will say so plainly.

You should always validate any value against your live network's behaviour before deploying. This book gives you the framework; the network gives you the truth.

— Abhijeet Kumar
Bangalore / Delhi, April 2026

1.1 The 5G Performance Envelope

Before we touch a counter, we must know what the network is supposed to deliver. 3GPP defines the 5G performance envelope primarily in TS 22.261 (Service requirements for the 5G system) and operationalises it in TS 38.913 (Study on scenarios and requirements for next generation access technologies). These are the numbers an optimizer is measured against — not vendor data sheets, not marketing decks, not RAN BoQs.

Table 1.1 — The 5G performance envelope as codified by 3GPP. These are the numbers against which every KPI is ultimately judged.

Every cell you optimise lives inside this envelope. A good optimizer knows, for each cell they touch, which dimension is currently the binding constraint — the dimension that limits the KPI. It is almost never all of them at once. A coverage-limited cell on the edge of a rural cluster is constrained by SS-SINR. A capacity-limited cell in a downtown office district is constrained by PRB utilisation. A mobility-limited cell on a highway on-ramp is constrained by the timeToTrigger of an A3 event. Naming the binding constraint correctly is the difference between an optimizer and a parameter tourist.

1.2 Shannon's Bound and the 5G NR Implementation Gap

The hard upper ceiling on what a 5G NR cell can ever deliver is the Shannon–Hartley channel capacity. For an AWGN channel of bandwidth B (Hz) and received signal-to-noise-plus-interference ratio SINR, the Shannon bound is:

Equation 1.1 — Shannon–Hartley channel capacity

For a 100 MHz FR1 carrier at SINR = 20 dB (linear SINR = 100), Shannon gives C = 100×10⁶×log₂(101) ≈ 666 Mbps. Real 5G NR, after cyclic prefix overhead (7.03% for normal CP), DMRS overhead (on the order of 14% for single-symbol front-loaded DMRS), PT-RS where used, and a maximum code rate capped at 948/1024 per TS 38.214 Table 5.1.3.1-2, delivers roughly 78–82% of the Shannon limit at that SINR operating point. Knowing the gap lets you estimate the ceiling from first principles and immediately flag when a vendor's “8 Gbps” lab number is achievable or not.

1.3 The Formal Measurement → Counter → KPI Hierarchy

Optimization data lives in three distinct 3GPP specifications that are usually conflated. Getting the distinction right is the first thing that separates a junior engineer from a senior one.

Layer 1 — Physical measurements (TS 38.215)

TS 38.215 §5 defines every physical-layer measurement quantity. The two most important for coverage optimization are SS-RSRP and SS-RSRQ. The spec text is tight; read it carefully.

Three subtleties hide in that one sentence. First, SS-RSRP is a linear average — in watts, not dBm. The GUI displays dBm because dBm is human-readable, but any arithmetic (e.g., beam averaging, layer-3 filtering) happens in linear units and is then converted. Second, only resource elements that carry secondary synchronization signals contribute — PSS REs are not included. Third, the measurement is confined to the SMTC window, which the gNB controls via ssb-MeasurementTimingConfig in SIB2 or a dedicated RRC message. If the SMTC is configured too narrow, beam-level measurements will be noisy and the layer-3 filter will never converge. This is a common but subtle mis-configuration.

Equation 1.2 — SS-RSRQ as defined in TS 38.215 §5.1.3

The RSSI denominator includes all received power in the measurement bandwidth — wanted signal, interference, thermal noise. As the cell becomes more loaded, RSSI rises even though SS-RSRP is unchanged, so RSRQ degrades even for a stationary UE. This is why RSRQ is a better load-sensitive indicator than RSRP, and why RSRP alone is never enough to triage a coverage complaint.

For the data channel, TS 38.215 defines the CSI-RS-based counterparts CSI-RSRP, CSI-RSRQ, and CSI-SINR (clauses 5.1.2, 5.1.4, 5.1.7). These are measured on CSI-RS resources allocated by the gNB per TS 38.214 §5.2, and they are what drives CQI reporting and link adaptation — not the SSB-based measurements, which drive mobility.

Layer 2 — Performance counters (TS 28.552)

Counters live in TS 28.552 and follow the naming convention <Family>.<EventOrStatistic>. The gNB increments them per granularity period (GP, default 900 s, configurable) and reports them over the O1 interface to the management system per TS 28.550 and TS 28.532. Every vendor should implement these exact names; the vendor GUI may show aliases. The families you will touch daily are:

Table 1.2 — Core TS 28.552 counter families every 5G optimizer uses daily. Counter names are 3GPP-standardised; vendor GUIs may show aliases.

Layer 3 — KPIs (TS 28.554)

KPIs are formulas that combine counters. TS 28.554 §6 defines the major ones explicitly. We list the most important in Table 1.3, using exact counter names from TS 28.552.

Table 1.3 — Major TS 28.554 KPIs expressed as formulas over TS 28.552 counters. These are the canonical definitions; an operator SLA may add conditions (exclusion periods, cause-code filters) but cannot contradict them.

1.4 The Time Hierarchy: From OFDM Symbol to Daily KPI

Every KPI you look at is the result of a cascade of averaging and filtering operations across many timescales. The senior engineer keeps this stack in their head at all times, because every optimization action has a settling time governed by where in the stack it lands.

The filter equation at the middle of the stack deserves its own treatment, because it is the most common single source of optimization mistakes.

Equation 1.3 — Layer-3 filter per TS 38.331 §5.5.3.2

This is a discrete-time exponentially-weighted moving average. Its effective memory (the 63% settling time, expressed in number of samples) is:

Equation 1.4 — Layer-3 filter memory

The spec allows filterCoefficient values fc0, fc1, fc2, fc3, fc4, fc5, fc6, fc7, fc8, fc9, fc11, fc13, fc15, fc17, fc19 (integer k). Each unit of k halves a every 4 steps, so the settling time doubles every 4 steps. Table 1.4 gives the numerical relationships.

Table 1.4 — Layer-3 filterCoefficient values, effective memory, and settling time (assuming 200 ms measurement period). Senior engineers keep this table in their head.

1.5 Statistical Confidence in KPI Measurement

A KPI is a random variable, not a deterministic number. Every value on the dashboard has a confidence interval around it, and if you act on a small-sample KPI without computing that interval, you will chase noise.

The RACH success ratio is a classic Bernoulli process: each preamble either succeeds or fails. If we observe s successes in n attempts, the maximum-likelihood estimate of the true success probability is p̂ = s/n. The normal (Wald) confidence interval for large samples is:

Equation 1.5 — Wald interval (95% CI)

But the Wald interval becomes meaningless when p̂ is close to 0 or 1 — exactly the regime in which all accessibility KPIs live. For small samples near the boundary, the Wilson score interval is vastly better:

Equation 1.6 — Wilson score interval (95% CI)

1.6 The Four Classical Domains — With Formulas

Every optimization task still maps to one of the four classical domains, but a senior engineer defines them using the underlying mathematics rather than slogans.

We will derive each of these formulas rigorously in later chapters. The point here is that optimization is not pattern-matching on dashboards — it is applied engineering math, and the senior engineer keeps the formulas at the back of their mind at all times.

1.7 The KPI Interaction Matrix

Every parameter change touches multiple KPIs. A tightening of the A3 offset raises handover attempts, which mechanically lowers the per-attempt success ratio (denominator grows faster than numerator near the decision threshold) while also reducing the mean cell-edge residency time — which lowers the drop rate in the source cell but raises the ping-pong rate and hence the target-cell accessibility load. A senior engineer learns this matrix over years; Table 1.5 codifies the most important couplings.

Table 1.5 — The core KPI interaction matrix. Memorise it: every single row is a trade-off, not a free lunch.

1.8 The Optimization Loop as a Control System

The Measure → Analyse → Act → Verify loop is not a management process. It is a discrete-time closed-loop controller in the formal control-theoretic sense, and it obeys the same stability rules as any other sampled feedback system.

Several control-theoretic insights fall straight out of this picture. (i) The loop has inherent delay equal to one GP — you cannot measure your own effect until at least one full granularity period has elapsed. (ii) Changing two parameters at once converts the SISO loop into a 2-input-1-output system, and the sensitivity matrix becomes ill-conditioned; this is the formal reason for the “one change per iteration” rule. (iii) The effective loop gain must be < 1 to guarantee stability; when an engineer panics and doubles their parameter step on each iteration, they are violating the small-gain theorem and the loop will oscillate. (iv) External disturbances (traffic, weather, day-of-week) enter at the plant and cannot be rejected by the controller — they can only be averaged out by lengthening the aggregation window.

1.9 Anti-Patterns at the Senior Level

Four subtle failures separate senior optimizers from exhausted ones. Each has a name in statistics or econometrics, and each shows up in the field almost every week.

1.10 The Vendor-Neutral Vocabulary

Throughout this book we will use only 3GPP-standardised names for counters, parameters, and procedures. The discipline is not stylistic — it is operational. A 3GPP name carries a specification clause that any engineer in the world can look up; a vendor alias carries only the vendor's internal documentation, which may disappear at the next release. When you encounter a counter in a GUI, your first action should be to look up the corresponding TS 28.552 family and clause. Only then should you translate back to the local vendor terminology — and you should record the translation in your team's reference.

Five counters in particular are universally known under vendor aliases but have clean 3GPP names that every optimizer should use in speech and writing:

Table 1.6 — Five commonly-aliased counters and their 3GPP standard names. Use the standard names in every document.

1.11 Summary

With the mathematical foundations in place, the next chapter takes this apparatus and applies it to the 5G NR architecture itself. We will walk through the gNB functional split, the O1/F1/E1/NG/Xn interfaces, and the mapping of each counter family to the logical node that owns it — so that when you see a degraded KPI, you know instantly which log file on which host to open.

§2.1  Why the Architecture Matters to the Optimizer

A widespread failure mode in 5G RAN optimization is treating the gNB as a monolithic black box. The optimizer observes a degraded KPI on the dashboard, issues a parameter change “in the gNB,” and waits. When the KPI does not recover, the investigation stalls because there is no mental model of where inside the gNB the failure originated.

Modern 5G NR deployments are functionally disaggregated. A single “cell” visible to the UE is actually the product of up to four distinct logical nodes (gNB-CU-CP, gNB-CU-UP, gNB-DU, and optionally a separate O-RU), connected by three distinct reference interfaces (F1, E1, eCPRI fronthaul), each with its own transport, its own PM counter emission, and its own failure modes. This disaggregation has a direct consequence: PM counters are not emitted by “the gNB” — they are emitted by specific logical nodes.

This chapter builds that ownership map from first principles, starting with the TS 38.401 functional split, moving through the interface protocol stacks, covering NSA and SA architectures in parallel, and arriving at a precise table that every optimizer should be able to reproduce from memory.

§2.2  The gNB Logical Node Architecture (TS 38.401 §6)

TS 38.401, “NG-RAN; Architecture description,” defines the disaggregated gNB architecture in Section 6. The specification permits two levels of split: a CU/DU split (mandatory reference point) and a further CU-CP/CU-UP split (optional but common in cloud-native deployments). Understand both because PM counter families align to both levels.

The further decomposition of the gNB-CU into control-plane and user-plane components is specified in TS 38.401 §6.2:

The four resulting logical nodes are:

§2.3  Protocol Layer Assignment Across Nodes

Understanding precisely which protocol layer runs in which node is the prerequisite for correct counter attribution. The assignment is fixed by the 3GPP functional split and cannot be changed by implementation choice.

The F1 interface cuts between the MAC/PHY (in the DU) and the RLC (also in the DU) — wait, that is not quite right. The F1 transport boundary is above the RLC. Specifically: RLC SDUs are tunnelled over F1-U as GTP-U packets. This has a performance implication: F1 transport latency directly adds to RLC ARQ round-trip time. If your F1 link introduces 2 ms additional RTT, the RLC t-Reordering timer must be set accordingly, or premature re-establishment will occur. This is a DU-side parameter, but the cause is in the fronthaul transport, not in the DU scheduler.

§2.4  The Seven NG-RAN Reference Interfaces

A disaggregated gNB participates in seven distinct reference interfaces, each with its own 3GPP transport specification, its own Application Protocol (AP), and its own failure signature in PM counters. Table 2.3 is the canonical reference.

Three architectural observations from Table 2.3 that are directly relevant to optimization fault isolation:

• All control planes use SCTP. SCTP (Stream Control Transmission Protocol) provides multi-homing and multi-streaming. An F1-C SCTP failure causes CU-CP to initiate DU-level reset procedures, which appear as mass RRC failure in the PM data — even though the radio interface was never degraded.
• All user planes use GTP-U over UDP. GTP-U is a tunnelling protocol with no congestion control. If the N3 transport between gNB-CU-UP and UPF is congested, user-plane throughput degrades with no corresponding NGAP or F1AP error counters. The only indicator is DRB throughput counters at the CU-UP, combined with transport-layer monitoring.
• The E1 interface carries bearer context setup. When a PDU session is established, the gNB-CU-CP sends an E1AP “Bearer Context Setup Request” to the gNB-CU-UP (TS 38.463 §9.2.1). A slow or failed E1 response causes PDU session establishment failures that appear in CU-CP counters as NGAP NG_Setup or NG_InitUEMessage failures, not as DU-side RACH failures.

§2.5  NSA Architecture: EN-DC (TS 37.340)

Non-Standalone (NSA) architecture, formally specified as E-UTRA-NR Dual Connectivity (EN-DC) in 3GPP TS 37.340, is the dominant initial 5G deployment mode globally. Understanding its bearer structure is essential because it fundamentally changes where NR PM counters originate and how to interpret throughput KPIs.

The EN-DC bearer architecture creates three distinct bearer types, each with different PM counter origins:

The SN addition procedure in EN-DC involves an X2-C exchange: the MN sends a “SgNB Addition Request” (TS 37.473) to the en-gNB, which responds with an “SgNB Addition Request Acknowledge” once resources are available. The PM counter for this procedure (SgNB.AddReqAtt, SgNB.AddReqSucc) is emitted by the MN (eNB), not the en-gNB. This is a frequent source of confusion: you expect a “5G SgNB addition success rate” KPI to be in the NR PM file, but it is in the LTE PM file.

§2.6  SA Architecture (TS 38.300)

Standalone (SA) architecture is the “pure 5G” mode where the gNB connects directly to the 5G Core (5GC) via the NG interface, without any LTE anchor. SA is required for all 5G-exclusive capabilities: network slicing (S-NSSAI per PDU session), 5G-native QoS (5QI with dynamic GBR guarantees), URLLC, mMTC, and 5G NR positioning.

In SA, the gNB-CU-CP is the sole control-plane anchor for the UE. All NAS (Non-Access Stratum) messages are transparently forwarded by the gNB-CU-CP to the AMF via NGAP. This means that AMF selection, authentication, PDU session establishment, and handover decisions all traverse the gNB-CU-CP. The implication: AMF overload or NGAP path failures appear directly as RRC accessibility failures in the CU-CP PM file.

§2.7  Counter-to-Node Ownership Map (TS 28.552)

This section is the chapter’s primary deliverable. PM counter families are not distributed randomly across logical nodes; they follow the functional split of TS 38.401 deterministically. Table 2.5 maps every major PM counter family to its emitting node, its TS 28.552 category, and the optimization domain it informs.

§2.8  PM Collection Architecture: O1 and NETCONF

PM counters do not reach the OSS by magic. The collection path is specified in TS 28.532 (“Management and orchestration; Management services for communication services”) and uses the O1 interface between the gNB and the Service Management and Orchestration (SMO) layer, based on NETCONF (IETF RFC 6241) with YANG models.

The PM file format is XML, defined in TS 32.435. Each PM file contains:

• A file header identifying the managed network element (NE), software version, and collection interval (Granularity Period, GP).
• One measInfo block per measurement type, listing the MO (Managed Object) instances and their counter values for the measurement period.
• A file footer with completion timestamp and possible validity flag.

The standard GP values are 5 minutes and 15 minutes. Most operators use GP=15 minutes for routine optimization. GP=5 minutes is used for event-triggered deep dives. Note that 5-minute GP data is typically not retained beyond 7 days due to storage volume; all long-term trending must use 15-minute data.

§2.9  Multi-Vendor and O-RAN Deployment Implications

The O-RAN Alliance specifications (O-RAN.WG4 fronthaul, O-RAN.WG1 architecture) extend the 3GPP functional split by defining the open fronthaul interface between gNB-DU and O-RU (the “7-2x split”). In these deployments, the RU is supplied by a different vendor from the DU, introducing a new failure domain that generates no PM counters in the 3GPP PM framework.

The key O-RAN considerations for optimization are:

1. Fronthaul latency budget. The 7-2x split requires eCPRI/Ethernet fronthaul latency ≤ 100 μs one-way for FR1. Exceeding this budget causes PRACH detection failures in the O-RU, which the DU cannot distinguish from “no UE sent a preamble.” The DU RACH counter RACH.PreambleACell will show zero attempts rather than any failure indication.
2. Beamforming weight management. In massive MIMO O-RU deployments, beamforming weights can be managed by either the DU (CU-plane driven) or the O-RU (M-plane driven). The PM counter L1M.RS-SINR.Avg is emitted by the DU, but the beamforming weights that produced that SINR may be configured in the O-RU via the M-plane. Parameter changes in the wrong node have no effect.
3. PM counter scope alignment. When CU and DU come from different vendors (Open RAN disaggregation), the CU PM file NE ID and DU PM file NE ID may use different naming conventions for the same cell. OSS stitching (joining CU and DU PM data by cell ID) requires careful NRM alignment per TS 28.622 or NCI (NR Cell Identity) alignment.

§2.10  Summary

The next chapter builds on this architectural foundation to introduce the full 3GPP KPI framework (TS 28.554): how raw counter observations are mathematically transformed into the standardized KPIs that operators commit to in SLA contracts. We will examine every formula in TS 28.554 from the optimizer’s perspective — focusing on which input counters each KPI formula requires, how the node ownership map determines which PM files you need to join, and where the 3GPP formula differs from the “simplified” vendor variants that you will encounter in real OSS dashboards.

3.1 Why KPIs Exist: The Signal in the Counter Noise

A 5G gNB can generate tens of thousands of performance management (PM) counter increments per granularity period. A large macro cell with 300 simultaneous active UEs accumulates several hundred thousand counter events every fifteen minutes. No engineer — and no algorithm — can interpret raw counter streams at this volume directly. The 3GPP KPI exists precisely to compress that counter stream into a dimensionless ratio that is comparable across cells, networks, vendors, and time.

The formal 3GPP definition is rooted in three interlocking specifications:

• TS 28.552 — the counter dictionary. Defines the measurement family names, per-counter semantics, collection granularity, and the Managed Object (MO) class each counter belongs to.
• TS 28.554 — the KPI dictionary. Each KPI entry references the exact TS 28.552 counter names in a formula, specifies the observation period, and assigns a unique clause number.
• TS 28.622 — the measurement job lifecycle. Specifies how an operations system (OAM) creates, activates, suspends, and terminates a measurement job, and how counter data is transferred over the O1 interface defined in TS 28.532.

This definition has three critical corollaries that every optimizer must internalise before they trust a KPI report.

Table 3.1 — Five intrinsic properties of a 3GPP KPI and their practical implications for optimization.

Measurement job lifecycle (TS 28.622)

TS 28.622 §4.5 defines the PM measurement job as a state machine with four states: INACTIVE, ACTIVE, SUSPENDED, and STOPPED. An OAM creates a job by configuring a MeasurementJob instance on the O1 interface, specifying the list of counter families, the GP, the reporting period, and the target MO DN (Distinguished Name). The gNB accumulates counters in ACTIVE state. At the end of each GP, it transfers the file (in 3GPP XML format per TS 32.432 or JSON per TS 28.532) to the OAM. SUSPENDED freezes collection without deleting the job; STOPPED terminates it.

3.2 TS 28.554 Architecture: The KPI Specification Blueprint

TS 28.554 (Management and orchestration; 5G performance measurements) is structured around five performance domains, each occupying a dedicated clause. Understanding the clause map is the first thing to do with a fresh copy of the spec — every KPI formula you will ever use is anchored to exactly one of these clauses.

Table 3.2 — TS 28.554 clause structure. Each domain occupies one numbered clause. Sub-clauses give individual KPI entries.

Anatomy of a KPI entry in TS 28.554

Every KPI entry in TS 28.554 follows an identical schema. Knowing this schema lets you locate any missing piece of a KPI specification in seconds. The fields are:

Table 3.3 — Schema of a KPI entry in TS 28.554. Every clause follows this identical structure.

This single sentence is dense with meaning. “Rate” means a ratio — not an absolute count. “Successful RRC connection establishments” maps to RRC.ConnEstabSucc. “Number of attempts” maps to RRC.ConnEstabAtt. “System-level view” is the spec's explicit acknowledgement that the KPI hides per-UE detail by design. “Accessibility performance” places this KPI in the §4 domain, not retainability or mobility.

3.3 The Five Performance Domains

TS 28.554 organises every 5G NR KPI into five orthogonal performance domains. The word orthogonal is deliberate: a degradation in one domain can occur without any visible change in another. A cell experiencing massive L3 handover failures (Mobility) may still show excellent DL throughput (Integrity) for the UEs that did not attempt to hand over. A cell on planned outage (Availability = 0%) will show no counter increments at all, so its Accessibility and Retainability ratios will compute as 0/0 = undefined — which is not the same as "bad".

3.4 KPI Formula Anatomy: The Three Canonical Forms

Every KPI in TS 28.554 is an instance of one of three canonical formula forms. Recognising which form a KPI uses tells you immediately what can go wrong and what to look for in the raw counters when the KPI degrades.

Form 1 — Ratio KPI (success rate)

The most common form. The numerator counts successful outcomes; the denominator counts attempts. The result is a percentage bounded on [0, 100].

Equation 3.1 — General ratio KPI form (TS 28.554)

Key property: the denominator is the statistically important quantity. If the denominator is small, the KPI has high variance and is unreliable (see §3.6). Ratio KPIs are used for Accessibility (§4) and Mobility (§8).

Form 2 — Throughput KPI

Used for Integrity metrics. The numerator accumulates data volume in bits; the denominator accumulates the time the scheduler was actively transmitting. This is not a time-ratio KPI; the denominator is active transmission time, not total elapsed time.

Equation 3.2 — DL user throughput KPI form (TS 28.554 §6.1.1)

The critical distinction is that DRB.ThpTimeDl counts only the sub-frames (in units of 0.5 ms by convention) during which the DRB had data in the buffer and was actually scheduled. Idle time when a UE is dormant is excluded. This is why the throughput KPI can show 200 Mbps even in a cell with 50% PRB utilisation — the UEs that are active are genuinely getting high rates; the metric says nothing about the UEs that are not active.

Form 3 — Time-ratio KPI (availability)

Used for Availability metrics. The numerator counts available time in seconds; the denominator is the total elapsed wall-clock time of the observation period.

Equation 3.3 — Time-ratio (availability) KPI form (TS 28.554 §7.1.1). GP = granularity period count.

Note that for a single GP, the denominator is exactly 900 seconds, so GP × 900 evaluates to 900. When computing monthly cell availability over N granularity periods, the denominator is N × 900. Unavailable time is the complement: any second during which the cell was not in service due to an outage, hardware fault, planned maintenance, or software reset.

3.5 Key KPIs with TS 28.554 Exact Formulas

The following six KPIs form the daily vocabulary of 5G RAN optimization. Each formula is given exactly as derived from the TS 28.554 counter names. Each KPI has engineering-validated threshold bands derived from operator field experience and ITU-T QoS guidelines.

KPI 1 — RRC Connection Setup Success Rate (TS 28.554 §4.1.1)

Equation 3.4 — RRC Connection Setup SR (TS 28.554 §4.1.1)

The numerator RRC.ConnEstabSucc is incremented when the gNB receives an RRCSetupComplete message from the UE (TS 38.331 §5.3.3.4). The denominator RRC.ConnEstabAtt is incremented when the gNB transmits an RRCSetup message (TS 38.331 §5.3.3.2). Failures between these two events include UE radio failure (RLF), NACK on SRB1, timer T300 expiry (TS 38.331 §10.2 default 1000 ms), and UE moving out of coverage before RRCSetupComplete. The cause sub-counters (.mo-Signalling, .mo-Data, .Emergency, etc.) should always be checked alongside the aggregate to isolate cause-specific failure modes.

KPI 2 — DRB Setup Success Rate (TS 28.554 §4.2.1)

Equation 3.5 — DRB Setup SR (TS 28.554 §4.2.1)

DRB setup failures occur after RRC setup succeeds. Common causes: QoS flow establishment rejection by 5GC (wrong 5QI or AMBR), F1-U bearer establishment failure toward CU-UP, local resource exhaustion (no available DRB context). Because this KPI is computed on the CU (NRCellCU MO class), it is entirely independent of radio failures — a low DRB SSR in the presence of a high RRCSSR points firmly at the core interface or resource management layer, not at radio coverage.

KPI 3 — HO Execution Success Rate (TS 28.554 §8.1.1)

Equation 3.6 — Intra-system HO Execution SR (TS 28.554 §8.1.1)

HO.ExecAtt is incremented when the source gNB transmits an RRCReconfiguration with mobilityControlInfo (TS 38.331 §5.3.5.3). HO.ExecSucc is incremented when the source gNB receives the UE Context Release from the target, confirming the UE successfully completed the RACH on the target cell. A HO execution failure (denominator incremented, numerator not) means the UE attempted RACH on the target and failed, or radio link failed during the T304 window (TS 38.331 §10.2, default 50–2000 ms). Do not confuse this with HO Preparation SR (§8.2.1), which covers the Xn/NG handshake before the RRCReconfiguration is sent.

KPI 4 — DL User Throughput (TS 28.554 §6.1.1)

Equation 3.7 — DL User Throughput (TS 28.554 §6.1.1). Volume in bits; time in 0.5 ms units per TS 28.552.

DRB.ThpTimeDl counts the number of 0.5 ms scheduling intervals during which the DRB had data in the transmit buffer. Convert to seconds by multiplying by 0.5×10⁻³. The resulting throughput is the experienced rate per active DRB, averaged across all active DRBs over the GP. High concurrency (many simultaneous active UEs) divides the shared PRB budget, which manifests as lower per-UE throughput even if PRB utilisation is high. This KPI does not distinguish between the MCS efficiency (which is limited by SINR) and the scheduling efficiency (which is limited by PRB sharing).

KPI 5 — DL PRB Utilisation (TS 28.554 §6.4.1)

Equation 3.8 — DL PRB Utilisation (TS 28.554 §6.4.1)

Available PRBs per slot depends on numerology and bandwidth. For 100 MHz SCS=30 kHz, there are 66 PRBs per slot (TS 38.211 Table 5.3.2-1 gives 132 RBs, but the PDSCH scheduler uses only the non-guard-band portion). The denominator multiplied by Subframes gives the total available PRB-slots in the GP. A PRB utilisation above 80% is a strong signal of capacity bottleneck — above this point, queueing delay grows non-linearly and per-UE throughput begins to degrade due to scheduler congestion.

KPI 6 — Cell Availability (TS 28.554 §7.1.1)

Equation 3.9 — Cell Availability (TS 28.554 §7.1.1). GP = granularity period count for the reporting interval.

Unavailable seconds are accumulated whenever the NRCellDU instance is in any state other than ACTIVE (TS 28.622 §4.3.2: INACTIVE, LOCKED, or SHUTTINGDOWN). Software resets, hardware alarms, and manual lockouts all contribute. For monthly reporting over N = 2,880 GPs (30 days × 96 GPs/day), a single one-hour outage contributes 3,600/2,592,000 = 0.139% unavailability, dropping CA from a theoretical 100% to 99.86% — below the TS 28.554 reference target of 99.95%.

3.6 Granularity Period and Statistical Confidence

The most common error in 5G KPI analysis is trusting a ratio KPI computed from a small denominator. The granularity period (GP) is 900 seconds by default (TS 28.532 §7.4.2 "15-minute reporting interval"). For a quiet rural cell with low traffic, 900 seconds may yield only 12 RRC connection attempts. An 11/12 = 91.7% success rate computed from 12 trials is statistically indistinguishable from 98.5% at 95% confidence. Acting on this number is worse than not acting — it is noise trading dressed as insight.

Busy Hour definition (ITU-T E.501)

ITU-T Recommendation E.501 defines the TCBH (Time Consistent Busy Hour) as the one-hour period starting at the same clock time each day that maximises the mean traffic carried over a 30-day period. In 5G practice, a busy hour spans four consecutive GP windows (4 × 900 s = 3,600 s). KPI analysis should always be performed on the busy hour aggregate — denominator counts will be at least 4× higher than any single GP, improving statistical reliability proportionally.

Equation 3.10 — Busy-Hour KPI aggregation over 4 contiguous GPs

The Wilson Score Confidence Interval

For a ratio KPI with denominator n and observed proportion p̂ = successes/n, the Wilson score interval at confidence level (1−α) is:

Equation 3.11 — Wilson score confidence interval (z = 1.96 for 95% CI). Introduced in §1.6 of this book.

For n = 12, p̂ = 0.917 and z = 1.96:

• Numerator of p_lo: 0.917 + 1.96²/24 − 1.96√(0.917×0.083/12 + 1.96²/576) ≈ 0.917 + 0.160 − 1.96×0.082 ≈ 0.916
• p_lo ≈ 0.916/1.320 ≈ 0.694
• p_hi ≈ (0.917 + 0.160 + 0.161)/1.320 ≈ 0.938

The 95% CI is [69.4%, 93.8%]. A measured value of 91.7% with n = 12 is consistent with the true rate being anywhere from 69% to 94%. This tells you nothing actionable.

3.7 KPI Baseline Setting: Percentiles, Thresholds, and Seasonality

A KPI threshold without a statistical basis is an opinion. The 3GPP framework does not mandate threshold values for most KPIs; it only defines the formula and observation period. Operator targets (Table 3.4) are derived from field benchmarks, SLA commitments, and ITU-T G.1050 multimedia performance requirements. The methodology for setting a defensible baseline has three steps.

Step 1 — Collect busy-hour distribution

Gather at least 30 days of busy-hour KPI values for the cell population of interest (a cluster, a layer, or a full market). For each KPI, compute the empirical distribution of busy-hour values. This gives the natural operating range of the network without any intervention.

Step 2 — Set threshold bands from percentile analysis

Table 3.4 — Three-band threshold methodology. Thresholds are derived from the network's own distribution, not from generic targets, making them deployment-specific and statistically grounded.

Step 3 — Seasonal baseline adjustment

KPI baselines are not static. A cell on a beach promenade may show RRCSSR = 96% in summer (high mobility, high load, many temporary UEs with poor coverage) and 99.2% in winter (low load, stationary UEs). Applying winter thresholds in summer will generate hundreds of spurious alarms. The correct practice is to maintain separate baseline distributions for:

• Weekday busy hour vs. Weekend busy hour
• Peak season (school holidays, local events) vs. off-season
• Network software release periods (feature activations alter KPI baselines)

3.8 Cross-Domain KPI Correlation

The five performance domains are not independent in causality, only in definition. Many real-world failure modes propagate across domain boundaries over time. Understanding which KPIs correlate with which allows an optimizer to trace a symptom in one domain to its root cause in another before customers notice.

The strongest cross-domain relationships to memorise are:

• Availability → all other domains (strong): A cell in outage produces zero events. All ratio KPIs become 0/0. This must be filtered before any cluster-level analysis, or the cell will falsely appear as having perfect KPIs.
• Mobility → Retainability (strong): A HO execution failure is an RLF event. The UE triggers RRC re-establishment (TS 38.331 §5.3.7). If re-establishment fails, it is a DRB drop and counts in Retainability.
• Retainability → Integrity (strong): Every DRB drop is a throughput zero. A cell with 2% DRB drop rate (which looks modest) is generating 2% throughput outage events, which appear as a long tail in the CDF and damage P5/P10 user experience metrics.

3.9 KPI Anti-Patterns: The Four Ways KPIs Mislead

The 3GPP KPI framework is precise, but it is applied in human-managed systems with incentives, biases, and statistical traps. The following four anti-patterns appear repeatedly in optimisation programmes worldwide. Recognising them is as important as knowing the formulas.

Anti-Pattern 1 — Goodhart's Law

Anti-Pattern 2 — Simpson's Paradox

Simpson's Paradox occurs when a trend appears in several different sub-groups but disappears or reverses when these groups are combined. In 5G RAN, the most common manifestation is the cluster average deception: a heavily loaded cell added to a cluster can raise the cluster's aggregate RRCSSR even as that individual cell's RRCSSR is poor.

Anti-Pattern 3 — Survivorship Bias

Survivorship bias in RAN KPIs occurs when only cells that are "up" (in ACTIVE state) contribute to the measured population. Cells that are in outage (zero availability) are excluded from ratio KPIs by definition — there are no denominator events. An availability-weighted KPI analysis that averages only cells with CA > 0% will systematically overstate network performance during partial outage periods. The fix is to include an explicit denominator count of cells that should have been active rather than cells that were active.

Anti-Pattern 4 — Cell Splitting Effect on Per-Cell KPIs

When a heavily loaded cell is split (e.g., by activating a nearby small cell or by indoor coverage deployment), the traffic migrates off the macro cell. The remaining UEs on the macro cell are typically the low-SINR edge UEs — the difficult users. The macro cell's per-UE throughput KPI may fall after the split even though the overall network experience has improved, because the easy high-SINR UEs (who were propping up the average) have migrated. This is not a failure of the optimisation action; it is a measurement artefact. Always evaluate cell-split results at cluster level, not at the individual cell level.

Table 3.5 — The four KPI anti-patterns: symptom, diagnostic test, and correct interpretation.

3.10 Chapter Summary