Historical project notes: This article describes an earlier version of my telecom projects. Interface steps, coverage counts and sample outputs may differ from the current 3GPP Pilot. The examples are engineering illustrations, not evidence of client deployments.
Network failures in 5G and LTE are rarely mysterious — every failure mode is defined in a 3GPP clause. The challenge is finding the right clause fast. This article walks through three real failure cases, showing exactly how to search, what clauses come back, and how to use the procedure flow to isolate the root cause. All searches were done using TejVox 3GPP Search.
Case 1 — UE stuck after RRCSetup: never sends RRCSetupComplete
Observed failure
In a protocol trace, the gNB sends RRCSetup to the UE. The UE is expected to respond with RRCSetupComplete containing the NAS Registration Request. Instead: silence. After 15 seconds, the gNB releases the connection. This was seen on 3 handsets out of 200 during a lab trial.
Search query
"UE receives RRCSetup but does not send RRCSetupComplete — timer and failure conditions in NR"
What comes back
The top match is TS 38.331 §5.3.3.3 — "Actions following cell selection while T300 is running". This clause defines that if the UE selects a new cell while T300 (the RRCSetup guard timer) is running, it must abort the RRC setup attempt and restart from RACH on the new cell. The second result is §5.3.3.4 — UE actions on receiving RRCSetup — which lists the precise SRB1 and AS security configuration the UE must complete before sending RRCSetupComplete.
Root cause
The 3 affected handsets were near a cell edge. The UE received RRCSetup on the source cell, but the radio conditions degraded during the SRB1 setup processing (approximately 200–300ms). The UE triggered a cell reselection before sending RRCSetupComplete — T300 was still running, so per §5.3.3.3 it aborted. The gNB saw a clean timeout rather than any error message, which is why it looked like silence. Fix: reduce the cell reselection threshold (s-NonIntraSearch) at that cell edge to keep the UE anchored during setup.
Case 2 — Handover ping-pong between two NR cells
Observed failure
A UE in a coverage overlap area between cell A and cell B executes repeated handovers — A→B, then B→A, then A→B — every 8–12 seconds. Each handover is "successful" individually, but the ping-pong causes repeated radio reconfigurations, degraded throughput, and eventually an RLF when the UE can't keep up with the reconfiguration frequency.
Search query
"NR handover ping-pong A3 event hysteresis time to trigger"
What comes back
The top results are from TS 38.331 §5.5.4 — measurement reporting, specifically the Event A3 condition (serving cell RSRP + offset < neighbour cell RSRP). The clause shows the two configurable parameters: hysteresis (dB margin that must be exceeded before A3 is satisfied) and timeToTrigger (how long the A3 condition must be continuously satisfied before reporting). A third result surfaces §5.5.2.4 — the condition-is-met timer management — which explains that if the A3 condition drops in and out during TTT, the timer resets.
Root cause
The network had hysteresis = 0 dB and timeToTrigger = 0ms in the measurement configuration — essentially zero protection against ping-pong. Any momentary RSRP advantage by the neighbour cell triggered an immediate A3 report. In an overlap area where both cells are approximately equal in signal strength, this caused constant triggering in both directions. Fix: set hysteresis = 3 dB and timeToTrigger = 160ms — standard values that provide enough margin to prevent oscillation without delaying genuine handovers.
Case 3 — PDU session rejected with cause "DNN not supported"
Observed failure
After successful 5G registration, the UE attempts to establish a PDU session for the enterprise APN "corp.internal". The SMF responds with a PDU Session Establishment Reject containing 5GSM cause #26 — "DNN not supported or DNN connection temporarily not allowed". The user cannot access the corporate network despite being registered on the 5G network.
Search query
"5GSM cause 26 DNN not supported PDU session establishment reject"
What comes back
The top result is TS 24.501 §6.4.1.5 — "5GSM cause values" — which defines cause #26 as the SMF-side indication that the requested DNN is not available to this subscriber in the current PLMN. The second result is TS 23.502 §4.3.2.2.1 — the PDU session establishment flow at the SMF — which shows the specific step where the SMF queries the UDM for the subscriber's allowed DNN list via the Nudm_SDM_Get call. A third result surfaces TS 29.503 §5.3.2 — the UDM SM subscription data — which defines the allowedDnnList per S-NSSAI per PLMN.
Root cause
The subscriber's UDM profile had not been updated with the enterprise DNN "corp.internal". The SMF queried the UDM, found no entry for this DNN in the allowed list for the subscriber's S-NSSAI, and rejected the session. This is a provisioning issue, not a network fault. Fix: update the UDM subscriber profile to add "corp.internal" to the allowedDnnList for the relevant S-NSSAI. The cause #26 message is normatively correct — the network did exactly what the spec requires when the DNN is not authorised.
All three root causes were identified by finding the right 3GPP clause and reading the normative condition. Try it yourself: 3GPP Search →
Comments
Loading comments…