Nokia NetAct Counter Guide: PM Counters Every 5G Engineer Should Know

What NetAct gives you

Nokia NetAct (currently NetAct 22+ in most operator deployments, with MantaRay NM rolling out alongside it) collects PM data from AirScale base stations and exposes it through the PM browser, Reporting Suite, and the dashboards you build yourself. The counters themselves come from the BTS in XML format and are normalized into NetAct measurement objects (LNCEL, LNCEL_FDD, NRBTS, NRCELL, etc.).

For 5G NR, Nokia counters are grouped by measurement, and the formal naming is M<measurement-id>C<counter-id>; most engineers work with the descriptive names in the NetAct PM browser. Nokia's counter names change between software releases, so the tables below use the standard 3GPP TS 28.552 names. Find the Nokia counter for each one in the counter reference for your release.

The counters that actually matter

Accessibility

The headline KPI:

5G CSSR (SA) =
  (RRC.ConnEstabSucc / RRC.ConnEstabAtt)
  * (UECNTX.ConnEstabSucc / UECNTX.ConnEstabAtt)
  * (DRB.EstabSucc / DRB.EstabAtt)

Many operators stop at the first two factors — that gives you signaling CSSR but not data plane. Always include the bearer (DRB) step for honest accessibility.

Retainability

Drop rate = DRB.RelActNbr / time the DRBs were active (abnormal releases per active second, the TS 28.554 retainability shape)

Do not include 5GC-initiated abnormal releases in radio drop rate — those are core problems and need separate tracking.

Mobility

Preparation-phase and intra-gNB handover counters exist as well; take their names from the counter reference for your release.

Report HOSR per source-target pair, not per cell. NetAct supports drill-down by neighbour relation; use it.

Throughput

UE throughput needs two counts per direction: the PDCP data volume per DRB and the active time the UE had data to send. Divide volume by active time. Take the counter names from the counter reference for your release.

UE throughput must use "active time" denominators (the time the UE actually had data to send), not wall-clock time. Otherwise idle UEs depress the average. Nokia gets this right by default; do not divide by sample count.

Resource utilization

Uplink PRB and active-UE counters exist as well; take their names from the counter reference for your release.

DL PRB Utilization = RRU.PrbTotDl (or RRU.PrbUsedDl / PRBs available)

Coverage and quality

Reported RSRP, SINR and BLER measurements exist as well; take their names from the counter reference for your release.

The CQI distribution counter is more useful than the average. Bimodal CQI distributions (lots of 4s and 13s, few in the middle) indicate cell-edge users dragging the average — different problem from a uniformly mediocre cell.

Building a useful dashboard

The Reporting Suite (or the newer MantaRay analytics) lets you build dashboards. Three I would always have:

Cell health overview (cell granularity, hourly)

• CSSR (SA)
• Drop rate (DRB retainability)
• HOSR (intra-gNB)
• DL PRB Utilization
• Avg UE DL Throughput
• Avg active UEs

Filter to top 50 worst cells by drop rate. Sort by attempts so you do not chase one-call cells.

Mobility detail (cell-pair granularity, daily)

• HO Prep SR per pair
• HO Exec SR per pair
• HO failures by cause (T304, RA timeout, target reject)

Coverage and quality (cell granularity, daily)

• RSRP distribution
• SINR distribution
• CQI histogram
• BLER DL/UL

Workflow patterns

> NetAct PM browser is fine for spot checks. For repeatable analysis, build a saved report and schedule the export. Manual re-querying produces inconsistent KPIs.

Triaging a degraded cell

1. Check accessibility components — find which factor of CSSR collapsed.
2. Check retainability — is drop rate up?
3. Check resource utilization — is the cell overloaded?
4. Check coverage counters — has RSRP/SINR shifted?
5. Cross-reference alarm history for the same window.

Spotting silent degradation

Not all problems trigger alarms. Schedule weekly reports for:

• Cells with > 20% drop in DL throughput week-over-week
• Cells with new T304 failures appearing
• Cells with PRACH attempt-to-completion ratio falling

Common gotchas

• Counter aggregation interval matters. NetAct ROP is 15 min by default; some operators run 60 min for storage savings, which masks short events.
• NRBTS-level counters aggregate across cells. For per-cell, use NRCELL or NRCELL_FDD/TDD measurement objects.
• After Nokia software upgrades, counter IDs sometimes change. Always re-validate dashboards after a release upgrade.
• The PM browser shows raw counter values. KPIs require formulas — define them once in Reporting Suite and reuse, do not recalculate in spreadsheets.

Takeaway: Useful 5G optimization in NetAct is built on a small set of counters, applied per cell pair and per active time, and tracked consistently — not on dashboards full of raw counters.

Paste the output somewhere useful

Nokia RAML viewer reads the configuration export

directly, which is faster than scrolling XML looking for one parameter.

Counters tell you a cell is unhealthy; they rarely tell you why. When you reach

that point, dropped calls in gNB logs

and intermittent handover failures

are real log sets where the answer is present but not labelled — the same

reading problem as a live node.