DEV Community: Takwa S

How We Debug Mobile Access Failures When the Dashboard Says Everything Is Fine

Takwa S — Thu, 28 May 2026 12:15:24 +0000

You walk into a hospital building. Full bars on your phone. You try to place a call. Nothing. You try again. Failure. A third time. It finally connects.

The network planning dashboard says this site has 99.8% coverage. The field data tells a completely different story: 40% of Random Access Channel (RACH) attempts are failing.

Welcome to the RACH trap. And if you are an RF engineer, you have probably seen this more than once.

What Is RACH and Why Should You Care?

Before your phone does anything on a cellular network (call, data session, handover), it needs to perform a Random Access procedure. Think of it as a handshake. Your device sends a preamble on the RACH to the base station, saying: "I am here, let me in."

If that handshake fails, nothing else works. No call setup. No data bearer. No handover. The user sees full bars but experiences dead air.

The critical insight: coverage (RSRP/RSRQ) and access (RACH success rate) are two completely independent metrics. You can have perfect coverage and completely broken access.

The Hospital Case: Debugging Step by Step

Here is the scenario. A 4G site near a major hospital. The OSS dashboard shows:

RSRP coverage: 99.8% above -110 dBm
Call setup success rate: reported at 96%
No alarms, no outages

But user complaints keep coming. Dropped calls. Failed connections. Especially inside the building.

Step 1: Capture at the UE Side

The first thing we did was stop looking at the dashboard and start capturing Layer 3 messages directly from the device. The difference between what the network thinks is happening and what the device actually experiences is where every real diagnosis starts.

We captured:

RRCConnectionRequest attempts and responses
RACH preamble transmissions and retransmissions
Timing Advance values at connection setup

Step 2: Identify the Pattern

The data revealed something the counters never showed:

40% of RACH attempts needed 3+ retransmissions before succeeding
Timing Advance values were abnormally high (12-15 instead of 0-3 for an indoor scenario)
The serving cell was not the nearest cell. The device was accessing an overshooting cell 2.3 km away

Step 3: Correlate with RF Conditions

This is where most debugging stops too early. Good RSRP does not mean good access. We measured:

RSRP: -85 dBm (excellent on paper)
SINR: 3 dB (terrible, indicating interference)
Number of detected cells: 7 (massive pilot pollution)

The device had strong signal from a distant cell but could not reliably access it because of interference from six other cells at similar power levels.

Step 4: Root Cause

The overshooting cell had:

Antenna downtilt set 2 degrees too high
No neighbor relation with the actual closest cell
RACH power ramping configured with default parameters (not adapted to high-interference environment)

Three configuration errors. Zero alarms triggered in the OSS.

Why Dashboards Miss This

OSS platforms aggregate. They show you averages over 15-minute or 1-hour windows, across all users on a cell. A 40% RACH failure rate for users in one specific building gets diluted into a 96% cell-wide success metric.

Field debugging with UE-side diagnostic tools captures what actually happens at the device level. Every preamble, every retransmission, every timing advance value. That is where you find the root cause.

The gap between "network says fine" and "user says broken" is almost always a Layer 3 problem that only shows up in per-device, per-attempt analysis.

The Fix and Validation

After adjusting the antenna tilt (2 degrees down), adding the missing neighbor cell, and tuning the RACH power ramping step to 4 dB, we re-ran the field test:

RACH first-attempt success rate went from 58% to 97%
Average preamble retransmissions dropped from 3.2 to 0.4
User complaints from that area: zero in the following two weeks

Total time from diagnosis to fix: 4 hours. Total time the problem existed before field debugging: 7 months.

The Takeaway for Engineers

If your coverage KPI says everything is fine but users complain, stop looking at coverage. Start looking at access. Specifically:

Capture Layer 3 at the device, not at the network counters
Check RACH retransmission rates, not just success rates
Measure Timing Advance to verify the device is accessing the right cell
Count detected cells to identify pilot pollution
Correlate RSRP with SINR. Good signal with poor quality = interference problem

This is the methodology we use on every field campaign. The tools matter, but the approach matters more.

I write about RF field debugging, Layer 3 analysis, and the gap between what dashboards show and what actually happens on the air interface. Follow the Signal Hunters newsletter for weekly field cases like this one.

Takwa Sebai, Co-founder & CEO at HiCellTek

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?