3 RRC message traps I keep seeing in 5G NR drive tests (and how to spot them)

Takwa S — Sat, 11 Apr 2026 22:51:38 +0000

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.

How to Decode 5G NR RRC Messages Online

Takwa S — Thu, 19 Mar 2026 13:49:31 +0000

If you work with 2G, 3G, 4G or 5G networks, you have probably spent time staring at hex dumps of RRC and NAS messages. Whether you are a field engineer debugging an attach failure, an RF optimizer analyzing handovers, or a protocol analyst investigating VoLTE drops, decoding Layer 3 signaling is a daily task.

The traditional workflow involves QCAT (Qualcomm-specific, Windows-only, license required), Wireshark (needs full PCAP files), or expensive tools like TEMS and Nemo ($10K+/year). But what if you could decode a single hex frame in your browser, in under a second?

What is RRC and why decode it?

RRC (Radio Resource Control) is the Layer 3 protocol between the UE (phone) and the base station (eNB in LTE, gNB in 5G NR). It carries:

Connection setup and release (RRCSetup, RRCRelease)
Reconfiguration (RRCReconfiguration for handovers, bearer changes, CA/DC config)
Measurement reports (MeasurementReport with RSRP, RSRQ, SINR from neighbor cells)
System information (SIB1, SIB2 with cell parameters broadcast)
UE capabilities (UECapabilityInformation with bands, features, MRDC support)

RRC messages are encoded in ASN.1 using UPER (Unaligned Packed Encoding Rules). You cannot read them without a decoder.

The online alternative

HiCellTek offers a free online decoder that handles both RRC and NAS for 2G, 3G, 4G and 5G:

Go to hicelltek.com/en/decoder/
Select the technology (LTE or 5G NR) and logical channel
Paste your hex frame
Click Decode

The engine is compiled C++ (asn1c) running server-side with 3GPP Release 17 support. It handles complex structures like CellGroupConfig and the LTE-to-NR tunnel (nr-SecondaryCellGroupConfig-r15).

How it compares to Wireshark

Feature	Wireshark	HiCellTek Decoder
Install required	Yes	No (browser)
Input format	Full PCAP	Single hex string
Speed	File-dependent	Sub-second
NAS decoding	Yes	Yes (Pro plan)
Batch mode	Manual	Up to 1,000 frames
Export	PDML/JSON	.txt and .json
Cost	Free	Free (20/day) or Pro 29 EUR/mo
5G NR R17	Version-dependent	Full R17

The key advantage: no need to reconstruct a PCAP. Paste the hex, get the tree.

Real use case: debugging a 5G SA registration failure

A field engineer captures a Registration Reject from the AMF. The hex payload looks like this:

7e0046110000001001000000

Pasting this into the decoder reveals:

Message type: Registration reject
5GMM cause: #17 (Network failure)
Diagnosis: the issue is core-side (AMF/UDM), not radio

Without a decoder, this hex string is meaningless. With one, you have a diagnosis in 2 seconds.

Who is this for?

RF engineers doing drive tests and cluster optimization
Protocol analysts investigating signaling flows
Network operators validating SIB and CellGroupConfig parameters
Telecom students learning 3GPP protocol structures
Anyone who has a hex frame and needs to know what it says

Try it

The decoder is at hicelltek.com/en/decoder/. 20 free RRC decodes per day, no signup required. The Pro plan (29 EUR/month) adds NAS, batch mode, JSON export and advanced filters.

If you work with telecom signaling, I would love to hear your feedback. What features would make your workflow easier?

DEV Community: Takwa S