Nokia KPI – E2E Index

V1 – KPI Deep Dive Accessibility RACH RRC Retainability Mobility Throughput Latency V2 – Test Cases RACH Test Cases RRC Test Cases Retainability Test Cases Mobility Test Cases Throughput Test Cases Latency Test Cases V3 – Parameters RACH Parameters RRC Parameters Retainability Parameters Mobility Parameters Throughput Parameters Latency Parameters V4 – NetAct Accessibility Counters RACH Counters RRC Counters Retainability Counters Mobility Counters Throughput Counters Latency Counters V5 – Final Interview Q&A Drive Test Correlation

5G Nokia KPI Optimization – End-to-End Mastery

This page is a single-source-of-truth for Nokia 5G KPI optimization used for live networks, OSS troubleshooting, drive test analysis and vendor interviews.

V1 - Accessibility KPI (Ability to Enter the Network)

Accessibility KPI measures whether a UE can successfully enter the 5G network when it initiates a connection. It is the foundation KPI because no service is possible unless access is granted.

UE gNB AMF SMF UPF PSS / SSS / PBCH (DL Sync) RACH Procedure RRC Setup Complete NAS Registration Request Authentication & Security Registration Accept PDU Session Establishment User Plane Setup User Data Flow Ready Original diagram based on 3GPP TS 38.300, 38.331, 23.501 – 5G SA Initial Registration

Why this KPI is critical

  • Defines whether the user can attach to the network
  • Directly impacts perceived network availability

High-level flow (3GPP aligned)

UE Power ON
   ↓
Random Access
   ↓
RRC Setup
   ↓
Initial Registration

Practical example

A UE displays "Connecting" for a long time and finally fails. This indicates poor accessibility caused by RACH or RRC failures.

Diagram derived from 3GPP specifications – original representation

V1 - RACH KPI (Initial Access Procedure)

RACH KPI evaluates the success of the Random Access procedure, which is the first interaction between UE and gNB.

UE gNB Msg1: PRACH Preamble Msg2: Random Access Response Msg3: RRC Request Msg4: Contention Resolution Original diagram based on 3GPP NR Random Access procedure

Why it matters

  • Repeated RACH failures increase access delay
  • High retries cause battery drain

RACH logical flow

Msg1: Preamble Transmission
Msg2: Random Access Response
Msg3: UE Request
Msg4: Contention Resolution

Example scenario

UE at cell edge sends Msg1 successfully, but Msg3 decoding fails repeatedly, resulting in low RACH success rate.

Diagram derived from 3GPP TS 38.213 – original representation

V1 - RRC KPI (Control Plane Stability)

RRC KPI measures the success and stability of control plane connections between UE and the network.

UE gNB RRC Connection Request RRC Connection Setup RRC Setup Complete Original diagram based on 3GPP TS 38.331 RRC procedures

Why it matters

  • Controls security, mobility, and bearer establishment
  • Unstable RRC increases signaling load

RRC flow

RRC Connection Request
   ↓
RRC Connection Setup
   ↓
RRC Setup Complete

Example

UE has strong signal but RRC setup fails due to uplink instability or timer expiry.

Diagram derived from 3GPP TS 38.331 – original representation

V1 - Retainability KPI (Session Continuity)

Retainability KPI measures whether an active session continues without being dropped.

UE gNB Active Data Transfer Radio Quality Degradation Radio Link Failure Detected Re-establishment / Recovery Original diagram based on 3GPP radio link monitoring and recovery procedures

Why it matters

  • Directly impacts call and data session stability
  • Major contributor to customer dissatisfaction

Session flow

Active Session
   ↓
Radio Quality Degrades
   ↓
Recovery OR Session Drop

Example

A video stream drops during a brief signal dip instead of recovering.

Diagram derived from 3GPP radio link monitoring concepts – original representation

V1 - Mobility KPI (Service Continuity During Movement)

Mobility KPI evaluates how effectively the network maintains service while the UE moves between cells.

UE Source gNB Target gNB AMF Measurement Report HO Preparation Request HO Preparation Ack HO Command HO Execution (Access Target gNB) Path Switch Request Path Switch Ack Original diagram based on 3GPP NR mobility and handover procedures

Why it matters

  • Poor mobility causes drops at cell borders
  • Impacts voice and real-time services

Mobility flow

UE Movement
   ↓
Measurement Reporting
   ↓
Handover Decision
   ↓
Handover Execution

Example

Handover is triggered too late and the session drops at the cell edge.

Diagram derived from 3GPP mobility procedures – original representation

V1 - Throughput KPI (User Data Speed)

Throughput KPI measures how fast data is transferred between UE and the network.

UE gNB UPF SMF AMF DL User Data (GTP-U) DL Scheduling & MCS UL Data (Scheduled) UL User Data (GTP-U) PDU Session Rules Mobility / Session Control Scheduler MCS / Layers Original diagram based on 3GPP 5G user plane (NG-U / GTP-U) and control context

Why it matters

  • Directly visible to end users
  • Defines quality of data experience

Throughput logic

Radio Quality
+ Scheduler Efficiency
+ Modulation Scheme
= User Throughput

Example

UE has strong signal but low throughput due to conservative scheduler behavior.

Diagram derived from 3GPP MAC layer principles – original representation

V1 - Latency KPI (Network Response Time)

Latency KPI measures the delay between a request and the corresponding response.

UE gNB 5G Core App Server UL Scheduling Delay Transport + Core Processing UPF → Application App Processing DL Transport Core + Scheduling DL Transmission Radio Delay Core Processing Delay Original diagram based on 3GPP end-to-end user plane and latency components

Why it matters

  • Critical for gaming and real-time services
  • Essential for low-latency industrial use cases

Latency flow

Packet Arrival
   ↓
Scheduling
   ↓
Transmission
   ↓
Response

Example

UE sends a small packet but waits long for uplink scheduling, resulting in high latency.

Diagram derived from 3GPP latency architecture – original representation

V2 - RACH Test Cases (Accessibility Validation)

Test Case Test Scenario Drive Test Observation NetAct Counter Check Expected Result
RACH TC-01 UE performs initial access in good coverage area Fast connection establishment with minimal retries RACH attempts close to RACH success High RACH success ratio
RACH TC-02 UE attempts access in weak uplink coverage Multiple access retries observed High RACH attempts with message 3 failures Improved success after uplink power tuning
RACH TC-03 Multiple UEs access cell simultaneously Access delay increases during congestion Increase in collision related counters Reduced collisions after configuration tuning
RACH TC-04 UE reattempts access after failure Delayed access before connection setup Repeated RACH attempts logged Stable access after retry parameter adjustment
RACH TC-05 UE access during peak traffic hours Occasional access delay Higher access load counters observed Consistent access after optimization
Test Validation Rule:
Always validate RACH behavior using both drive test timing and NetAct access counters.

V2 - RRC Test Cases (Connection Setup and Stability)

Test Case Test Scenario Drive Test Observation NetAct Counter Check Expected Result
RRC TC-01 UE initiates RRC setup in good radio conditions Quick and consistent RRC setup RRC setup success close to setup attempts High RRC setup success ratio
RRC TC-02 UE initiates RRC setup in weak coverage Delayed setup with retries Increase in radio related setup failures Improved success after coverage optimization
RRC TC-03 UE experiences setup delay during high load Setup completion time increases Higher setup attempts with stable success Acceptable setup time after tuning
RRC TC-04 UE recovers connection after temporary radio degradation Connection resumes without user impact Recovery attempts with successful completion Stable connection recovery behavior
RRC TC-05 UE remains connected during idle to active transitions No abnormal reconnection observed Low re-establishment attempts Consistent connection stability
Test Validation Rule:
RRC test cases must be validated by correlating setup timing from drive tests with RRC success and failure counters.

V2 - Retainability Test Cases (Session Continuity)

Test Case Test Scenario Drive Test Observation NetAct Counter Check Expected Result
RET TC-01 UE maintains active data session in stable coverage No interruption during data transfer Low radio link failure events Continuous data session without drops
RET TC-02 UE moves through weak coverage during data session Temporary degradation without session loss Few recovery attempts with successful completion Session maintained after recovery
RET TC-03 UE experiences sudden signal degradation Short interruption followed by recovery Radio link failures with recovery success Session restored without drop
RET TC-04 UE remains connected during high mobility with data active Minor throughput fluctuation Stable session with low drop counters No abnormal session termination
RET TC-05 UE continues data session during load variation No session termination observed Stable session drop counters Consistent retainability performance
Test Validation Rule:
Retainability must be evaluated using active data sessions and validated through radio link failure and session drop counters.

V2 - Mobility Test Cases (Handover Performance)

Test Case Test Scenario Drive Test Observation NetAct Counter Check Expected Result
MOB TC-01 UE moves slowly across cell boundary Smooth transition without data interruption High handover execution success Stable handover with no failures
MOB TC-02 UE moves at medium speed between cells Handover occurs before signal degradation Low handover failure counters Timely and successful handover
MOB TC-03 UE moves at high speed along coverage edge Brief quality fluctuation during transition Stable preparation and execution counters Maintained session continuity
MOB TC-04 UE experiences late handover conditions Signal degrades before handover execution Late handover indicators observed Improved timing after trigger adjustment
MOB TC-05 UE experiences early handover behavior Frequent handovers between neighboring cells Increased handover preparation attempts Reduced unnecessary handovers after tuning
Test Validation Rule:
Mobility performance must be validated by correlating handover timing in drive tests with preparation and execution counters.

V2 - Throughput Test Cases (User Data Performance)

Test Case Test Scenario Drive Test Observation NetAct Counter Check Expected Result
TP TC-01 UE performs downlink data transfer in good radio conditions High and stable downlink throughput observed High average downlink throughput counters Consistent high user throughput
TP TC-02 UE performs uplink data transfer in good radio conditions Stable uplink throughput Improved uplink throughput counters Consistent uplink data performance
TP TC-03 UE located at cell edge during data transfer Reduced throughput compared to cell center Lower modulation usage observed Expected cell edge throughput behavior
TP TC-04 Multiple UEs generate traffic simultaneously Throughput shared among active users Balanced resource utilization counters Fair throughput distribution
TP TC-05 UE with good signal but low throughput Lower than expected data rate Conservative modulation and scheduler behavior Improved throughput after scheduler tuning
Test Validation Rule:
Throughput validation must correlate radio quality, scheduler behavior, and modulation usage rather than signal strength alone.

V2 - Latency Test Cases (Low Delay and Real Time Performance)

Test Case Test Scenario Drive Test Observation NetAct Counter Check Expected Result
LAT TC-01 UE performs ping test in good radio conditions Stable round trip time with low variation Low and stable RAN latency counters Consistent low latency observed
LAT TC-02 UE generates uplink traffic with frequent small packets Quick uplink response without long waiting time Reduced uplink scheduling delay counters Fast uplink scheduling behavior
LAT TC-03 UE runs real time application during low cell load Minimal delay variation Stable downlink scheduling delay counters Smooth real time performance
LAT TC-04 UE runs real time application during higher load Slight increase in delay but no spikes Moderate scheduling delay variation Acceptable latency under load
LAT TC-05 UE uses low latency service profile Predictable delay behavior Prioritized traffic shows lower delay counters Consistent low latency for prioritized traffic
Test Validation Rule:
Latency performance must be validated using both round trip delay from drive tests and scheduling delay counters from OSS.

V3 – RACH Optimization Parameters (Nokia 5G NR)

This section covers expert-level RACH optimization parameters across PHY, MAC, and RRC layers as implemented in Nokia 5G NR networks. Proper tuning directly impacts accessibility, latency, and uplink stability.

Layer Category Nokia Parameter Name Description Default (Example) Optimization Strategy Impact & Trade-off
L1 / PHY PRACH Configuration prachConfigurationIndex Defines PRACH format, time and frequency resources 0–255 (format dependent) Use Format 0/1 for normal cells;
Format 2/3 for large cells or high TA;
Increase density in high-load scenarios 		Directly affects RACH capacity and access latency;
Higher density increases load and interference
L1 / PHY PRACH Power Control preambleReceivedTargetPower Target received power of PRACH preamble at gNB -100 dBm Increase to -95 / -90 dBm for large cells;
Reduce to -105 dBm for small / indoor cells 		Higher value improves detection but increases UL interference;
Lower value reduces interference but risks miss-detection
L1 / PHY PRACH Resources prachFreqResource Number of PRACH frequency-domain resources 0 (single resource) Increase to 2–4 resources in high-load or dense cells Improves RACH capacity and reduces contention;
Consumes additional UL spectrum
L1 / PHY PRACH Resources prachTimeResource Number of PRACH occasions per subframe 0 (1 occasion) Increase to 2–4 in dense urban or event hotspots Reduces collision probability;
Increases PRACH overhead
L2 / MAC RACH Contention preambleTransMax-CB Maximum contention-based preamble transmissions n10 Reduce to n8 in dense cells;
Increase to n12 for large / rural cells 		Higher value improves success rate;
Increases access latency and interference
L2 / MAC RACH Contention preambleTransMax-CF Maximum contention-free preamble transmissions n10 Reduce to n6–n8 for handover scenarios Impacts HO reliability and interruption time
L2 / MAC RACH Response raContentionResolutionTimer Timer for Msg4 contention resolution sf64 Increase to sf80 in large TA cells;
Reduce to sf48 in small cells 		Longer timer improves success in large cells;
Increases access delay
L2 / MAC PRACH Frequency msg1-FrequencyStart Starting RB index for PRACH Msg1 Cell specific Coordinate with neighbor cells to avoid overlap Reduces inter-cell PRACH interference
L3 / RRC Access Control acBarringFactor Access class barring probability p95 Reduce to p50 during congestion;
Increase to p99 in low-load cells 		Controls access attempt rate;
Excessive barring increases access delay
L3 / RRC Access Control acBarringTime Barring duration for barred UEs s16 s4 for moderate load;
s32 for heavy congestion 		Regulates control plane load;
Long barring frustrates users
L3 / RRC Beam Management ssb-PerRACH-Occasion Number of SSB beams mapped to one RACH occasion 1 / 2 / 4 / 8 / 16 / 32 / 64 Match exactly to deployed SSB beam configuration Critical for beam correspondence and RACH success
L3 / RRC UE Power Control powerRampingStepHighPriority Power ramping step for high-priority access dB6 Increase to dB8 for emergency / URLLC services Ensures priority access reliability;
Raises interference risk
L3 / RRC Broadcast Control scalingFactorBI Scaling factor for broadcast information 0 dB Reduce to -3 dB in dense deployments Lowers RACH interference floor;
May impact cell-edge UEs
Optimization Tip: RACH tuning should always be validated against PRACH success rate, Msg3 failure counters, UL interference KPIs, and access delay distributions in Nokia NetAct before and after changes.

V3 – RRC Setup Success Rate Optimization Parameters (Nokia 5G NR)

This section covers expert-level RRC setup and reestablishment parameters across RLC and RRC layers. Proper tuning is essential to improve RRC setup success rate, reduce access failures, and ensure robust control-plane performance in Nokia 5G SA networks.

Layer Category Nokia Parameter Name Description Default Value Optimization Strategy Impact
L2 / RLC RRC Transport ulRlcAmMaxRetxThreshold (SRB1) Maximum RLC AM retransmissions for SRB1 (uplink) t32 Increase to t40 in poor coverage;
Reduce to t24 in low-latency / strong radio conditions 		Directly affects RRC message delivery reliability;
Higher value increases latency and UL load
L2 / RLC RRC Transport dlRlcAmMaxRetxThreshold (SRB1) Maximum RLC AM retransmissions for SRB1 (downlink) t32 Same strategy as UL RLC;
Increase in poor radio conditions 		Impacts RRC setup reliability and DL control-plane robustness
L3 / RRC Setup Timers t300 RRC connection establishment timer ms1000 Increase to ms2000 for large cells or high TA;
Reduce to ms500 in small cells 		Critical for RRC setup success in varying coverage conditions;
Excessive value increases access delay
L3 / RRC Setup Timers t301 RRC reestablishment timer ms1000 Increase to ms1500 in high mobility or fast fading scenarios Improves recovery from temporary radio failures;
Longer timer delays fallback to full RRC setup
L3 / RRC Setup Timers t302 Barring timer after RRC reject ms1000 Increase to ms5000 during congestion;
Reduce to ms100 under normal load 		Controls control-plane load;
Excessive barring increases access delay
L3 / RRC Setup Attempts rrcConnectionReestablishmentMax Maximum number of RRC reestablishment attempts n2 Increase to n3 in mobility hotspots;
Reduce to n1 for static or indoor cells 		Balances persistence vs signaling load;
Too high may overload gNB
L3 / RRC Resource Allocation initialUE-aggregatedMaximumBitRateDL Initial AMBR allocated for signaling traffic 0 (unlimited) Set limit during congestion (e.g., 64 kbps) Protects signaling from data starvation;
Prevents signaling storms under load
L3 / RRC Scheduling Request sr-TransMax Maximum number of Scheduling Request transmissions n64 Reduce to n32 for faster fallback to RACH;
Increase to n128 for reliability 		Affects SR reliability and access delay;
High value increases UL control load
L3 / RRC Priority Handling rrcPriority Priority of RRC messages in scheduler 0 (lowest) Increase to 5–7 for RRC setup and reestablishment Ensures timely scheduling of critical RRC messages;
Overuse impacts user-plane fairness
L3 / RRC UE Capability ue-CapabilityEnquiryTimer Timer for UE capability enquiry procedure ms1000 Increase to ms2000 for poor radio conditions;
Reduce to ms500 for good radio quality 		Impacts capability exchange success;
Long timer increases access latency
Optimization Tip: Always correlate RRC parameter changes with RRC Setup Success Rate, RRC Failure Cause, SRB1 RLC retransmissions, and RRC Reestablishment KPIs in Nokia NetAct before and after tuning.

V3 – Retainability Optimization Parameters (Nokia 5G NR)

Retainability KPIs focus on maintaining an active RRC and user-plane session without unexpected release. These parameters govern radio link monitoring, RLC recovery, RLF detection, reestablishment, and beam/HO failure handling in Nokia 5G SA networks.

Layer Category Nokia Parameter Name Description Default Value Optimization Strategy Impact
L1 / PHY Radio Link Monitoring outOfSyncThreshold BLER threshold to declare Out-of-Sync (OOS) 0.10 (10%) Increase to 0.15 in fast fading or mobility;
Reduce to 0.08 in stable radio conditions 		Controls RLF sensitivity;
Higher value delays RLF but risks poor QoE
L1 / PHY Radio Link Monitoring inSyncThreshold BLER threshold to declare In-Sync (IS) 0.02 (2%) Increase to 0.03 in challenging radio environments Affects recovery from OOS;
Too strict threshold delays recovery
L1 / PHY Power Control p0NominalPUCCH Nominal transmit power for PUCCH -90 dBm Increase to -85 dBm under interference;
Reduce to -95 dBm in clean radio 		Impacts HARQ-ACK and CSI reliability;
Higher power raises UL interference
L1 / PHY Power Control deltaF-PUCCH-Format1 Power offset for PUCCH format 1 0 dB Increase for critical HARQ / CSI feedback Improves control channel robustness;
Increases UL interference footprint
L2 / RLC RLC Recovery dlRlcAmPollRetransmitTimer DL poll retransmission timer for RLC AM ms45 Increase to ms100 in poor radio;
Reduce to ms25 in good radio 		Affects RLC status feedback and recovery latency
L2 / RLC RLC Recovery ulRlcAmPollRetransmitTimer UL poll retransmission timer for RLC AM ms45 Same optimization strategy as DL Critical for uplink RLC AM stability
L2 / RLC RLC Signaling rlcAmStatusProhibitTimer Status prohibit timer to limit RLC STATUS PDUs ms0 Increase to ms20 to reduce signaling load Reduces control overhead;
Excessive value delays loss recovery
L3 / RRC RLF Detection t310 Timer started upon detecting OOS ms1000 Increase to ms2000 for high mobility;
Reduce to ms500 for indoor cells 		Fundamental RLF sensitivity parameter;
Higher value delays RLF declaration
L3 / RRC RLF Detection n310 Number of consecutive OOS indications n1 Increase to n3 for temporary fading resilience Reduces spurious RLFs;
May delay real failure detection
L3 / RRC RLF Detection n311 Number of consecutive IS indications n1 Increase to n2 for stable recovery Improves recovery robustness;
Slower exit from RLF condition
L3 / RRC Reestablishment t311 Time allowed for RRC reestablishment search ms30000 ms10000 for dense networks;
ms60000 for sparse / rural deployments 		Impacts reestablishment success rate;
Long value delays idle fallback
L3 / RRC Connection Release releaseTimer (Inactive → Idle) Inactivity timer before RRC release ms10000 Reduce to ms5000 for high load;
Increase to ms20000 for low load 		Controls unnecessary releases and signaling load
L3 / RRC Handover Protection hoFailureTimer Timer for HO failure recovery ms1000 Increase to ms2000 for inter-frequency HO Improves recovery after HO failure;
Longer interruption possible
L3 / RRC Beam Failure beamFailureRecoveryTimer Timer for beam failure recovery procedure ms100 Reduce to ms50 for fast recovery;
Increase to ms200 for stability 		Critical for beam-based mobility;
Too aggressive may cause false recovery
Optimization Tip: Retainability tuning must always be validated using RLF counters, abnormal RRC releases, reestablishment success rate, HO failure KPIs, and beam failure statistics in Nokia NetAct.

V3 – Mobility (Handover Success) Optimization Parameters (Nokia 5G NR)

Mobility KPIs measure the network’s ability to maintain service continuity during UE movement. These parameters govern measurement reporting, handover triggering, execution, robustness, idle mode mobility, and advanced handover mechanisms in Nokia 5G SA networks.

Layer Category Nokia Parameter Name Description Default Value Optimization Strategy Impact
L1 / PHY Measurement Configuration a3-Offset Primary offset for Event A3 handover triggering dB3 Tune between dB1–dB6 based on cell dominance and overlap Most critical HO trigger parameter;
Lower value causes early HO, higher value risks late HO
L1 / PHY Measurement Configuration a3-TimeToTrigger Time-to-trigger for Event A3 ms480 Reduce to ms160 for high-speed mobility;
Increase to ms640 for stability 		Controls HO responsiveness vs ping-pong behavior
L1 / PHY Measurement Configuration hysteresis Measurement hysteresis for reporting events dB1 Adjust between dB0–dB3 based on environment Provides additional filtering against fast fading
L1 / PHY Coverage-based HO a5-Threshold1 (Serving) Serving cell threshold for Event A5 -100 dBm Reduce to -105 dBm for early HO;
Increase to -95 dBm for late HO 		Controls HO based on coverage degradation
L1 / PHY Coverage-based HO a5-Threshold2 (Neighbor) Neighbor cell threshold for Event A5 -95 dBm Increase to -90 dBm for early HO;
Reduce to -100 dBm for late HO 		Works in pair with Threshold1 to trigger HO
L1 / PHY Measurement Reporting reportAmount Maximum number of measurement reports sent infinity Limit to a fixed value (e.g., 4) to reduce signaling Reduces measurement reporting load on gNB
L1 / PHY Measurement Reporting reportInterval Interval between consecutive measurement reports ms480 Reduce to ms120 for high mobility;
Increase to ms1024 for low mobility 		Affects measurement accuracy and responsiveness
L3 / RRC Handover Execution handoverPreparationTimer Timer for HO preparation phase ms1000 Increase to ms2000 for inter-gNB or inter-CU HO Impacts HO preparation success and signaling stability
L3 / RRC Handover Execution handoverExecutionTimer Timer for HO execution phase ms1000 Reduce to ms500 for intra-DU HO;
Increase to ms2000 for inter-DU HO 		Critical for HO completion and interruption time
L3 / RRC Mobility Robustness t304 Timer for HO completion and failure detection ms1000 Increase to ms2000 for challenging HO scenarios Affects HO failure detection sensitivity
L3 / RRC Idle Mode Mobility s-NonIntraSearch Threshold to trigger inter-frequency search 0 dB Increase to 2–6 dB to control inter-frequency mobility Affects idle mode reselection behavior
L3 / RRC Idle Mode Mobility q-Hyst Cell reselection hysteresis dB4 Reduce to dB2 for fast reselection;
Increase to dB6 for stable camping 		Balances reselection speed vs stability
L3 / RRC Inter-RAT Mobility b1-Threshold (NR → LTE) Threshold for NR to LTE fallback -105 dBm Reduce to -110 dBm for early fallback;
Increase to -100 dBm for late fallback 		Controls NR–LTE mobility and service continuity
L3 / RRC Conditional HO choTriggerCondition Trigger condition for Conditional Handover A3 / A5 based Optimize based on neighbor cell dominance Reduces HO failures and interruption time
L3 / RRC DAPS HO dapsHoConfig Dual Active Protocol Stack handover configuration Disabled Enable for ultra-reliable HO scenarios Enables near zero-interruption HO;
Increases signaling and complexity
Optimization Tip: Mobility tuning must be correlated with HO Success Rate, HO Failure Cause, Ping-Pong Rate, RLF after HO, and inter-frequency mobility KPIs in Nokia NetAct.

V3 – Throughput Optimization Parameters (Nokia 5G NR)

Throughput KPIs reflect the efficiency of radio resources, scheduler behavior, protocol window management, and QoS configuration. These parameters directly control peak and average user throughput in Nokia 5G SA networks.

Layer Category Nokia Parameter Name Description Default Value Optimization Strategy Impact
L1 / PHY MIMO Configuration maxRank Maximum transmission rank per UE 4 Configure according to UE and gNB capability (2 / 4 / 8) Directly multiplies peak throughput;
Higher rank requires good SINR and feedback accuracy
L1 / PHY MIMO Feedback csi-ReportConfig (PMI / RI) CSI reporting configuration for PMI and RI Periodic / Aperiodic Use high-frequency aperiodic CSI for MU-MIMO Critical for MIMO and beamforming efficiency;
Excessive CSI increases UL overhead
L1 / PHY MIMO Feedback pmi-RI-Report Enable or disable PMI / RI reporting Enabled Disable in open-loop (TM3-like) scenarios Reduces control overhead;
Limits closed-loop MIMO gains
L2 / MAC Scheduler Configuration schedulerAlgorithm Downlink scheduling algorithm PF (Proportional Fair) Use MLWDF for QoS-sensitive traffic;
PF for best-effort data 		Fundamental throughput behavior and fairness
L2 / MAC Scheduler Configuration schedulingWeightDL Downlink scheduling weight 50 Increase to 70 for DL-heavy traffic;
Reduce for UL-dominant scenarios 		Prioritizes DL throughput at cell level
L2 / MAC Scheduler Configuration schedulingWeightUL Uplink scheduling weight 50 Configure complementary to DL weight Controls uplink throughput balance
L2 / MAC HARQ Configuration harqMaxProcesses Maximum number of HARQ processes 16 Reduce to 12 for FDD;
Adapt based on TDD DL/UL pattern 		Affects retransmission capacity and throughput
L2 / MAC HARQ Configuration harqRoundTripTime HARQ round-trip time 8 slots Optimize according to TDD pattern and numerology Impacts retransmission timing and efficiency
L2 / MAC Buffer Management dlBufferSizeThreshold Downlink buffer size threshold 1000 KB Increase for bursty traffic;
Reduce for low-latency services 		Influences scheduler behavior and burst handling
L2 / MAC Carrier Aggregation scellActivationTimer Secondary cell activation timer ms320 Reduce to ms160 for faster CA activation;
Increase to ms640 for stability 		Impacts CA responsiveness and stability
L2 / RLC / PDCP Window Management rlcAmWindowSize RLC AM transmission window size 512 Increase to 1024 for high throughput;
Reduce to 256 for low-latency flows 		Affects throughput in poor radio conditions
L2 / RLC / PDCP Window Management pdcpWindowSize PDCP reordering window size 4096 Increase to 8192 for high throughput;
Reduce to 2048 for low-latency services 		Prevents PDCP stalling under reordering
L2 / RLC Segmentation maxRlcSduSize Maximum RLC SDU size 9000 bytes Reduce to 1500 for VoIP;
Increase to 12000 for high throughput data 		Impacts segmentation efficiency and latency
L3 / RRC QoS Configuration qosFlowMapping Mapping of QoS flows to DRBs 1:1 Use many-to-one mapping for efficient multiplexing Affects scheduling granularity and overhead
L3 / RRC QoS Configuration gfbr-Uplink / gfbr-Downlink Guaranteed Flow Bit Rate 0 Configure per service requirement Ensures minimum throughput for GBR services
Optimization Tip: Throughput tuning should be validated against cell and UE throughput distributions, scheduler utilization, MCS/RI statistics, HARQ retransmissions, and buffer occupancy KPIs in Nokia NetAct.

V3 – Latency Optimization Parameters (Nokia 5G NR)

Latency KPIs measure the end-to-end delay experienced by packets from UE to application server and back. These parameters control PHY numerology, scheduling responsiveness, retransmission behavior, protocol timers, and RRC state transitions in Nokia 5G SA networks.

Layer Category Nokia Parameter Name Description Default Value Optimization Strategy Impact
L1 / PHY Numerology subcarrierSpacing Subcarrier spacing configuration 15 kHz (FR1) Increase to 30 kHz for low latency;
Use 60 kHz for URLLC use cases 		Directly determines slot duration and transmission latency;
Higher SCS reduces coverage
L1 / PHY Slot Format slotFormatIndicator Dynamic DL/UL slot format indication Disabled Enable for dynamic TDD deployments Reduces DL/UL switching delay;
Increases control signaling overhead
L1 / PHY Processing Time n1 / n2 / n3 / k2 PHY processing timeline parameters Standard Configure to minimum supported by UE and gNB capability Directly impacts PHY layer latency and HARQ timing
L2 / MAC Scheduling Latency schedulingRequestInterval Interval between scheduling request opportunities 1 slot Use every slot for low latency;
Increase to 2 slots to reduce overhead 		Affects UL grant acquisition delay
L2 / MAC Scheduling Latency bsrTimer Buffer Status Report periodic timer 20 ms Reduce to 5 ms for latency-critical traffic;
Increase to 40 ms for efficiency 		Controls UL buffer awareness and scheduling speed
L2 / MAC HARQ Optimization harqFeedbackTiming HARQ-ACK feedback timing Fixed pattern Optimize according to TDD pattern and numerology Impacts retransmission delay and round-trip time
L2 / MAC HARQ Optimization harqMaxRetx Maximum number of HARQ retransmissions 4 Reduce to 2 for URLLC;
Increase to 6 for reliability 		Trade-off between latency and reliability
L2 / RLC RLC Mode Selection rlcMode (per DRB) RLC mode configuration for DRB AM Use UM for latency-sensitive services (VoIP, gaming) Eliminates RLC retransmission delay;
Increases packet loss risk
L2 / RLC Reassembly (UM) t-Reassembly Reassembly timer for RLC UM ms35 Reduce to ms15 for low latency;
Increase to ms50 for jitter tolerance 		Controls out-of-order delivery latency
L2 / RLC AM Signaling t-StatusProhibit Status prohibit timer for RLC AM ms0 Increase to ms10 to reduce control PDU load Reduces signaling overhead;
Slightly delays loss recovery
L2 / PDCP PDCP Optimization pdcpDiscardTimer PDCP discard timer for stale packets ms100 Reduce to ms50 for low latency;
Increase to ms500 for reliability 		Prevents transmission of outdated packets
L2 / PDCP PDCP Optimization pdcpStatusReportRequired PDCP status report requirement Disabled Enable for AM DRBs with high packet loss Improves reliability;
Adds latency and signaling overhead
L2 / PDCP Security integrityProtection Integrity protection for PDCP packets Enabled Disable for selected DRBs if permitted Reduces processing delay;
Must comply with security policy
L3 / RRC State Transition inactivityTimer RRC inactivity timer 10 s Reduce to 2 s for fast release;
Increase to 20 s for frequent data bursts 		Affects RRC resume vs full setup latency
L3 / RRC State Transition suspendTimer RRC suspension timer 5 s Reduce to 2 s for fast suspend;
Increase to 10 s for stability 		Controls RRC resume latency and stability
L3 / RRC Connection Setup ueCapabilityEnquiryProhibit UE capability enquiry caching control Disabled Enable to skip repeated UE capability exchange Reduces RRC setup and resume time for known UEs
Optimization Tip: Latency optimization must be validated using one-way latency, RTT, scheduling delay, HARQ RTT, and application-level response time KPIs. Always evaluate latency trade-offs against reliability and coverage.

V4 – Accessibility Counters (Nokia NetAct, SR 22A+)

This section lists the complete set of Nokia NetAct counters used to evaluate Accessibility KPIs in 5G SA networks, covering RACH, RRC, and NGAP/N2 layers.

1️⃣ RACH Accessibility (SR 22A+)

Counter Type Nokia Counter Name Object Description
Attempts NPRACH.AttTotal NRCellDU Total PRACH attempts
Success NPRACH.SuccTotal NRCellDU Successful PRACH procedures
Failure NPRACH.FailTotal NRCellDU Failed PRACH procedures
CBA NPRACH.CBAtt NRCellDU Contention-based PRACH attempts
CFA NPRACH.CFAtt NRCellDU Contention-free PRACH attempts
Retransmission NPRACH.Msg1Retx NRCellDU Preamble retransmissions
Timeout NPRACH.RARTimeout NRCellDU RAR timeout failures
Collision NPRACH.ContResFail NRCellDU Contention resolution failures

2️⃣ RRC Accessibility (SR 22A+)

Counter Type Nokia Counter Name Object Description
Setup Attempt NRRC.ConnEstabAtt.Sum NRCellCU RRC connection establishment attempts
Setup Success NRRC.ConnEstabSucc.Sum NRCellCU RRC connection establishment successes
Setup Failure NRRC.ConnEstabFail.Sum NRCellCU RRC connection establishment failures
Reject NRRC.ConnRej.Sum NRCellCU RRC connection rejects
Reestablishment NRRC.ReEstabAtt.Sum NRCellCU RRC reestablishment attempts
Service Request NRRC.ServiceReqAtt.Sum NRCellCU Service request attempts
Resume Request NRRC.ResumeReqAtt.Sum NRCellCU Resume request attempts

3️⃣ NGAP / N2 Interface (SR 22A+)

Counter Type Nokia Counter Name Object Description
Initial Context NNGAP.InitCtxtSetupReq.Sum gNB Initial context setup requests
Initial Context Success NNGAP.InitCtxtSetupSucc.Sum gNB Successful initial context setups
PDU Session NNGAP.PDUSessResSetupReq.Sum gNB PDU session resource setup requests
UE Context NNGAP.UECtxtRelReq.Sum gNB UE context release requests
Engineering Note:
Accessibility KPI analysis must begin at PRACH level, then RRC, and finally NGAP. A failure at a lower layer propagates upward and masks higher-layer KPIs.

V4 – RACH Performance Counters (Nokia NetAct, SR 23A)

This section lists Nokia NetAct counters used to analyze RACH performance quality beyond basic accessibility, focusing on collision behavior, signal quality, delay, load, and beam-based recovery mechanisms.

1️⃣ RACH Performance Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
Collision Rate NPRACH.CollisionRate NRCellDU PRACH collision rate (%)
Msg1 Rx Power NPRACH.Msg1RxPower.Avg NRCellDU Average received power of Msg1 preamble (dBm)
Msg1 SINR NPRACH.Msg1SINR.Avg NRCellDU Average SINR of Msg1 preamble (dB)
RACH Delay NPRACH.TotalDelay.Avg NRCellDU Total RACH access delay from Msg1 to Msg4 (ms)
Preamble Detected NPRACH.PreambleDetected.Sum NRCellDU Total number of detected PRACH preambles
RACH Load NPRACH.PreamblesPerSlot.Avg NRCellDU Average number of PRACH preambles per slot

2️⃣ Beam Failure Recovery (BFR) Counters – SR 23A

Counter Type Nokia Counter Name Object Description
BFR Attempt NBFR.Attempt.Sum NRCellDU Total number of Beam Failure Recovery attempts
BFR Success NBFR.Success.Sum NRCellDU Successful Beam Failure Recovery procedures
BFR Failure NBFR.Failure.Sum NRCellDU Failed Beam Failure Recovery procedures
BFI Count NBFI.Count.Sum NRCellDU Total number of Beam Failure Indications reported by UEs
Engineering Note:
High RACH collision rate combined with increased BFR attempts typically indicates beam misalignment or PRACH overload. Always correlate RACH performance counters with SSB beam configuration and PRACH density.

V4 – RRC State Management Counters (Nokia NetAct, SR 22A+)

This section lists Nokia NetAct counters related to RRC state transitions, connection lifecycle management, and RRC timer expiries. These counters are critical for analyzing accessibility, retainability, and mobility-related signaling behavior in 5G SA networks.

1️⃣ RRC State Transition Counters (SR 22A+)

Counter Type Nokia Counter Name Object Description
Idle → Connected NRRC.IdleToConn.Sum NRCellCU Number of Idle to Connected state transitions
Inactive → Connected NRRC.InactiveToConn.Sum NRCellCU Number of Inactive to Connected state transitions
RRC Release NRRC.ConnRel.Sum NRCellCU Total RRC connection releases
RRC Suspend NRRC.Suspend.Sum NRCellCU Total RRC suspensions
Resume Success NRRC.ResumeSucc.Sum NRCellCU Successful RRC resume procedures

2️⃣ RRC Timer Expiry Counters (SR 22A+)

Counter Type Nokia Counter Name Object Description
T300 Expiry NRRC.T300Exp.Sum NRCellCU Number of T300 timer expiries (RRC setup)
T301 Expiry NRRC.T301Exp.Sum NRCellCU Number of T301 timer expiries (reestablishment)
T302 Expiry NRRC.T302Exp.Sum NRCellCU Number of T302 timer expiries (reject barring)
T304 Expiry NRRC.T304Exp.Sum NRCellCU Number of T304 timer expiries (handover execution)
T310 Expiry NRRC.T310Exp.Sum NRCellCU Number of T310 timer expiries (radio link failure detection)
T311 Expiry NRRC.T311Exp.Sum NRCellCU Number of T311 timer expiries (reestablishment search)
Engineering Note:
Abnormal increases in RRC timer expiry counters typically indicate misconfigured RRC timers, radio instability, mobility failures, or congestion-driven signaling delays. Always correlate timer expiries with RRC success, RLF, and HO failure counters.

V4 – Retainability (Drop) Counters (Nokia NetAct, SR 23A)

This section lists Nokia NetAct counters used to analyze session retainability, radio link stability, abnormal releases, and RLC recovery behavior in 5G SA networks. These counters are critical for drop call and session drop analysis.

1️⃣ Radio Link Failure (RLF) Counters – SR 23A

Counter Type Nokia Counter Name Object Description
RLF Detected NRLF.Detected.Sum NRCellCU Radio Link Failures detected
RLF Max RLC NRLF.MaxRLC.Sum NRCellCU RLF due to maximum RLC retransmissions
RLF T310 NRLF.T310Exp.Sum NRCellCU RLF caused by T310 timer expiry
RLF RA Failure NRLF.RAFail.Sum NRCellCU RLF due to RACH failure
RLF Beam Failure NRLF.BeamFailure.Sum NRCellCU RLF caused by beam failure
Out-of-Sync NRLF.OOS.Ind.Sum NRCellDU Out-of-Sync indications reported by UE
In-Sync NRLF.IS.Ind.Sum NRCellDU In-Sync indications reported by UE

2️⃣ Abnormal Release Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
Abnormal Release NRRC.AbnormalRel.Sum NRCellCU Total abnormal RRC connection releases
Release due to RLF NRRC.RelDueToRLF.Sum NRCellCU RRC releases due to Radio Link Failure
Release due to HO Failure NRRC.RelDueToHOFail.Sum NRCellCU RRC releases due to handover failure
Release due to Preemption NRRC.RelDueToPreempt.Sum NRCellCU RRC releases due to resource preemption
Release due to Radio NRRC.RelDueToRadio.Sum NRCellCU RRC releases caused by poor radio conditions
PDU Session Drop NPDU.SessAbnormalRel.Sum NRCellCU Abnormal PDU session releases

3️⃣ RLC Performance Counters (SR 22A+)

Counter Type Nokia Counter Name Object Description
DL Retransmission NRLC.RetxDL.Sum NRCellCU Downlink RLC retransmissions
UL Retransmission NRLC.RetxUL.Sum NRCellCU Uplink RLC retransmissions
Poll Sent NRLC.PollSent.Sum NRCellCU RLC status polls sent
Status PDU NRLC.StatusPDU.Sum NRCellCU RLC STATUS PDUs transmitted
Reassembly Timeout NRLC.ReasTimeout.Sum NRCellCU RLC reassembly timer expiries
Engineering Note:
Retainability degradation must be analyzed in sequence: RLF detection → Abnormal RRC release → RLC retransmission behavior → PDU session drops. A spike in RLC retransmissions often precedes RLF and abnormal releases.

V4 – Mobility (Handover) Counters (Nokia NetAct, SR 23A)

This section lists Nokia NetAct counters used to analyze mobility performance in 5G SA networks, including handover attempts, success/failure analysis, conditional handover behavior, and measurement reporting statistics.

1️⃣ Handover Attempts & Outcomes (SR 23A)

Counter Type Nokia Counter Name Object Description
HO Attempt NHO.Attempt.Sum NRCellCU Total number of handover attempts
HO Success NHO.Success.Sum NRCellCU Successful handovers
HO Failure NHO.Failure.Sum NRCellCU Failed handovers
Intra-Frequency HO NHO.AttIntraFreq.Sum NRCellCU Intra-frequency handover attempts
Inter-Frequency HO NHO.AttInterFreq.Sum NRCellCU Inter-frequency handover attempts
Inter-gNB HO NHO.AttInterGNB.Sum NRCellCU Inter-gNB handover attempts
Intra-gNB HO NHO.AttIntraGNB.Sum NRCellCU Intra-gNB handover attempts

2️⃣ Handover Failure Analysis (SR 23A)

Counter Type Nokia Counter Name Object Description
HO Preparation Failure NHO.FailPrep.Sum NRCellCU Handover preparation failures
HO Execution Failure NHO.FailExec.Sum NRCellCU Handover execution failures
HO Cancel NHO.Cancel.Sum NRCellCU Cancelled handover procedures
HO Too Late NHO.TooLate.Sum NRCellCU Handovers triggered too late
HO Too Early NHO.TooEarly.Sum NRCellCU Handovers triggered too early
HO Wrong Cell NHO.WrongCell.Sum NRCellCU Handovers executed towards wrong target cell
Ping-Pong HO NHO.PingPong.Sum NRCellCU Ping-pong handovers between cells

3️⃣ Conditional Handover (CHO) Counters – SR 22A+

Counter Type Nokia Counter Name Object Description
CHO Attempt NCHO.Attempt.Sum NRCellCU Conditional handover attempts
CHO Success NCHO.Success.Sum NRCellCU Successful conditional handovers
CHO Execution NCHO.Execution.Sum NRCellCU Executed conditional handovers
CHO Cancellation NCHO.Cancellation.Sum NRCellCU Cancelled conditional handovers
CHO Timer Expiry NCHO.TimerExp.Sum NRCellCU Conditional handover timer expiries

4️⃣ Measurement Reporting Counters (SR 22A+)

Counter Type Nokia Counter Name Object Description
Measurement Reports Received NMR.Received.Sum NRCellCU Measurement reports received from UEs
A3 Events NMR.A3Event.Sum NRCellCU A3 measurement events reported
A4 Events NMR.A4Event.Sum NRCellCU A4 measurement events reported
A5 Events NMR.A5Event.Sum NRCellCU A5 measurement events reported
B1 Events NMR.B1Event.Sum NRCellCU B1 inter-RAT measurement events
Engineering Note:
Mobility degradation must be analyzed across the full handover lifecycle: measurement reporting → HO preparation → execution → completion. Excessive ping-pong, early/late HO counters typically indicate misconfigured A3 offsets, TTT, or hysteresis parameters.

V4 – Throughput Counters (Nokia NetAct, SR 23A)

This section lists Nokia NetAct counters used to analyze end-to-end throughput performance in 5G SA networks, covering MAC/PHY throughput, resource utilization, MIMO and beamforming efficiency, link adaptation, and carrier aggregation behavior.

1️⃣ Layer-1 / MAC / PHY Throughput Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
DL MAC Throughput NTHP.DlMacCellVol NRCellDU Downlink MAC cell volume (bytes)
UL MAC Throughput NTHP.UlMacCellVol NRCellDU Uplink MAC cell volume (bytes)
DL Physical Throughput NTHP.DlPhyCellVol NRCellDU Downlink physical layer cell volume
UL Physical Throughput NTHP.UlPhyCellVol NRCellDU Uplink physical layer cell volume
Scheduled DL Throughput NTHP.DlSchedVol NRCellDU Scheduled downlink volume
Scheduled UL Throughput NTHP.UlSchedVol NRCellDU Scheduled uplink volume

2️⃣ Resource Utilization Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
DL PRB Utilization NPRB.UtilDL.Avg NRCellDU Average downlink PRB utilization (%)
UL PRB Utilization NPRB.UtilUL.Avg NRCellDU Average uplink PRB utilization (%)
DL PRB per UE NPRB.DlPerUE.Avg NRCellDU Average number of DL PRBs per UE
UL PRB per UE NPRB.UlPerUE.Avg NRCellDU Average number of UL PRBs per UE
CCE Utilization NCCE.UtilDL.Avg NRCellDU Downlink CCE utilization (%)

3️⃣ MIMO & Beamforming Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
Rank 1 Usage NMIMO.Rank1.Sum NRCellDU Rank-1 transmission usage count
Rank 2 Usage NMIMO.Rank2.Sum NRCellDU Rank-2 transmission usage count
Rank 3 Usage NMIMO.Rank3.Sum NRCellDU Rank-3 transmission usage count
Rank 4 Usage NMIMO.Rank4.Sum NRCellDU Rank-4 transmission usage count
MU-MIMO Pairs NMIMO.MU.Pairs.Sum NRCellDU MU-MIMO paired user transmissions
Active Beamformed Users NBF.ActiveUsers.Avg NRCellDU Average number of active beamformed users

4️⃣ Link Adaptation Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
CQI Distribution NCQI.Dist.1 – NCQI.Dist.15 NRCellDU CQI index distribution across UEs
Average CQI NCQI.Avg NRCellDU Average CQI reported by UEs
MCS Distribution NMCS.Dist.0 – NMCS.Dist.28 NRCellDU MCS index distribution
DL BLER NBLER.Dl.Avg NRCellDU Average downlink BLER (%)
UL BLER NBLER.Ul.Avg NRCellDU Average uplink BLER (%)
Target BLER NBLER.Target.Avg NRCellDU Target BLER for link adaptation

5️⃣ Carrier Aggregation Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
2CC CA Usage NCA.2CC.Usage.Sum NRCellCU Two-component carrier aggregation usage
3CC CA Usage NCA.3CC.Usage.Sum NRCellCU Three-component carrier aggregation usage
4CC CA Usage NCA.4CC.Usage.Sum NRCellCU Four-component carrier aggregation usage
SCell Activation NCA.SCellAct.Sum NRCellCU Secondary cell activations
SCell Deactivation NCA.SCellDeact.Sum NRCellCU Secondary cell deactivations
PSCell Change NCA.PSCellChange.Sum NRCellCU Primary secondary cell changes
Engineering Note:
Throughput optimization must be evaluated holistically: PRB utilization, MIMO rank usage, BLER stability, and CA activation together determine achievable cell and user throughput.

V4 – Latency Counters (Nokia NetAct, SR 23A)

This section lists Nokia NetAct counters used to analyze user-plane, control-plane, and QoS-specific latency behavior in 5G SA networks. These counters provide end-to-end visibility from UE through gNB and Core Network.

1️⃣ User Plane Latency Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
UE to gNB Delay NDelay.UP.UEtoGNB.Avg NRCellDU UE to gNB packet delay (ms)
gNB to UPF Delay NDelay.UP.GNBtoUPF.Avg NRCellCU gNB to UPF packet delay (ms)
End-to-End Delay NDelay.UP.E2E.Avg NRCellCU End-to-end packet delay (ms)
DL Scheduling Delay NDelay.DL.Sched.Avg NRCellDU Downlink scheduling delay (ms)
UL Scheduling Delay NDelay.UL.Sched.Avg NRCellDU Uplink scheduling delay (ms)
HARQ RTT NDelay.HARQ.RTT.Avg NRCellDU HARQ round-trip time (ms)

2️⃣ Control Plane Latency Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
Paging Delay NDelay.CP.Paging.Avg NRCellCU Paging to service delay (ms)
Idle to Active NDelay.CP.IdleToActive.Avg NRCellCU Idle to Active state transition delay (ms)
Inactive to Active NDelay.CP.InactiveToActive.Avg NRCellCU Inactive to Active state transition delay (ms)
HO Interruption NDelay.HO.Interruption.Avg NRCellCU Handover interruption time (ms)
BSR Delay NDelay.UL.BSR.Avg NRCellDU Buffer Status Report reporting delay (ms)

3️⃣ QoS Flow Latency Counters (SR 23A)

Counter Type Nokia Counter Name Object Description
5QI 1 Delay NDelay.5QI.1.Avg NRCellCU 5QI 1 packet delay (ms)
5QI 2 Delay NDelay.5QI.2.Avg NRCellCU 5QI 2 packet delay (ms)
5QI 3 Delay NDelay.5QI.3.Avg NRCellCU 5QI 3 packet delay (ms)
5QI 4 Delay NDelay.5QI.4.Avg NRCellCU 5QI 4 packet delay (ms)
5QI 6 Delay (URLLC) NDelay.5QI.6.Avg NRCellCU 5QI 6 (URLLC) packet delay (ms)
5QI 7 Delay NDelay.5QI.7.Avg NRCellCU 5QI 7 packet delay (ms)
Packet Delay Variation NPDV.5QI.1.StdDev NRCellCU Packet delay variation for 5QI 1 (ms)
Engineering Note:
Latency KPIs must be analyzed end-to-end: user-plane scheduling and HARQ delays, control-plane state transitions, and QoS-specific flow behavior. URLLC performance (5QI 6) is especially sensitive to scheduling delay and HARQ RTT.

V5 - RACH Interview Questions (Why / How / Fix)

Question Logical Answer
Why are RACH attempts high but success rate low? High attempts with low success indicate contention or uplink power issues rather than lack of PRACH resources.
How do you confirm this from NetAct? Check pmRachAtt versus pmRachSucc and correlate with pmRachCollision and pmMsg3Fail counters.
What parameters do you optimize first? Power ramping step, preamble target power, and zero correlation zone configuration.
What should not be done first? Adding more PRACH resources without confirming uplink decode quality.
What is the expected result after optimization? Reduced retries, higher success ratio, and predictable access delay.

V5 - RRC Interview Questions (Why / How / Fix)

Question Logical Answer
Why is RRC setup success low despite good signal strength? Good signal strength alone does not guarantee uplink reliability or proper timer configuration.
How do you validate RRC issues in NetAct? Compare pmRrcConnEstabAtt, pmRrcConnEstabSucc, and pmRrcConnEstabFailRadio counters.
Which parameter should be reviewed before timers? Broadcast signal power and uplink quality indicators.
Why is increasing RRC timers risky? It may hide radio quality issues and increase setup delay without solving root cause.
What indicates an RRC stability problem? High re-establishment attempts with frequent recovery procedures.

V5 - Retainability Interview Questions (Why / How / Fix)

Question Logical Answer
Why do users experience drops during active data? Drops during data usually indicate radio link instability rather than access failure.
Which NetAct counters confirm retainability issues? Radio link failure, session drop, and re-establishment attempt counters.
Which parameters are tuned first? Radio link failure detection timers and recovery thresholds.
What mistake should be avoided? Optimizing access parameters when the problem is session stability.
What is the success indicator after optimization? Reduced drop events and stable active sessions.

V5 - Mobility Interview Questions (Why / How / Fix)

Question Logical Answer
Why do handovers fail at cell edges? Handover triggers may be late, causing the connection to degrade before execution.
How do you detect late handovers? Using handover failure counters and late handover indicators.
Which parameters correct late handovers? Reducing trigger offset or delay before handover execution.
What causes early handovers? Aggressive trigger margins or excessive cell bias.
What defines good mobility performance? High execution success and low failure rates.

V5 - Drive Test Log to NetAct Counter Correlation

Drive Test Observation NetAct Counter Pattern Root Cause Optimization Action
Repeated access attempts before connection High RACH attempts, low RACH success Uplink contention or power issue Optimize PRACH power and collision control
Connection setup delay observed High RRC attempts with low success Broadcast power or uplink instability Improve coverage and verify uplink quality
Data session drops during movement High radio link failures Late handover or weak radio link Tune handover trigger and recovery timers
Low throughput despite good signal Low modulation usage Scheduler or MCS limitation Optimize scheduler and modulation settings
High latency in real time services High scheduling delay counters Delay in uplink scheduling Enable fast uplink grant and reduce TTI
Interview Insight:
Drive test explains what the user experiences. NetAct explains why it happens. Optimization closes the gap.
© 2025 EDUNAVO | Nokia KPI Optimization – E2E FINAL MASTER VERSION
🎯 ↑ 🌙