RRC traces look simple on the surface. You decode a few messages, you read the field names, and you think you understand what the UE and the gNB are doing. Then you spend half a day chasing a bug that was never really a bug.
Three scenarios come back in almost every 5G NR drive test I analyze. Each one is easy to misread if you look at the message in isolation.
Trap 1 : RRCReconfiguration with an empty measConfig
You see an RRCReconfiguration in the trace, you open it, and the measConfig section is empty or only has a measObjectToRemoveList. First reaction of many engineers : "the network just dropped the measurement setup, that is why we lost the neighbor".
Most of the time that conclusion is wrong. Per 3GPP TS 38.331, a measConfig in an RRCReconfiguration is a delta update, not a full replacement. An empty delta means "keep everything you already had". It is only an actual removal if specific MeasObjectId or ReportConfigId values are listed in the remove lists.
How to spot it : before declaring a measurement drop, reconstruct the cumulative measConfig from the beginning of the RRC connection, not from this single message. The cell has been configuring you since the first RRCSetup, each reconfiguration only sends the diff.
Trap 2 : MeasurementReport with zero neighbor results
You open a MeasurementReport and the measResultListEUTRA or measResultListNR field has zero entries. The local cell is there, but no neighbors. On the map, you can clearly see there is a neighbor cell visible at the UE location. Instant assumption : "the UE failed to detect the neighbor".
Often the UE did detect the neighbor. It simply did not pass the event trigger. A MeasurementReport is only emitted when an event condition is satisfied, typically eventA3 for handover, and the trigger is sensitive to offsets (Ocn, Ofn, hysteresis, timeToTrigger) defined in the ReportConfigNR that was active at that moment (TS 38.331 ReportConfigNR).
How to spot it : cross reference the ReportConfig associated with the measId in that report. If eventA3 requires the neighbor to be better than serving by +3 dB and the neighbor is only +1 dB above serving, you will never see it in a report, no matter how strong it is in absolute terms.
Trap 3 : RRCReconfigurationComplete before SecurityModeComplete
Less common but very misleading. You see the UE send RRCReconfigurationComplete and then SecurityModeComplete arrives a few ms later in the trace. Some log viewers reorder messages slightly, so you end up reading what looks like "the UE completed a reconfiguration before security was even up". First reflex : security bug, or protocol violation.
In practice this is almost always a display ordering artifact. The real ordering at the RRC layer is the one defined in TS 38.331 for the procedural sequence, and the security context itself is governed by TS 33.501. The PDCP sequence numbers and the actual timestamps at the lower layers are the authoritative source, not the order of pretty printed lines in a viewer.
How to spot it : trust PDCP SN or raw timestamps, not the human readable sort. If the PDCP layer has security already activated when the RRCReconfiguration was received, the procedure is conformant.
Why these traps matter
All three traps share the same pattern. A message looks complete on its own, but its meaning depends on state that is not inside the message itself. You need the accumulated measConfig, or the currently active ReportConfig, or the PDCP context. A decoder that only shows you one message at a time can make you draw the wrong conclusion very fast.
How to check any of the above on your own trace
If you want to paste a raw hex frame and see exactly which IE values are set on RRCReconfiguration, MeasurementReport, or any other NR L3 message, I keep a free browser decoder at hicelltek.com/en/decoder/. 20 decodes per day, no signup. It is built around the 3GPP TS 38.331 ASN.1 grammar so every field maps back to the spec directly.
If this is the first time you are looking at RRC hex, my earlier post How to Decode 5G NR RRC Messages Online covers the basics first.
Your turn
Which RRC trap have you personally lost the most time on ? The measConfig one is the one I see daily, but I am curious if others fall more often on the measurement event conditions or the security ordering artifact. Drop it in the comments.
Top comments (0)