DEV Community: Takwa S

A PRB heatmap is easy. Trustworthy interference analysis is not

Takwa S — Wed, 02 Sep 2026 13:16:30 +0000

A RAN engineer asked me for an Excel macro to visualize per-PRB interference counters.

The request sounded simple: load a file and draw a heatmap. But the chart was not the hard part. The hard part was making the result repeatable and technically honest.

So I built a small free browser tool instead.

273 PRBs is one configuration, not a rule

It is tempting to create 273 fixed columns because that is a familiar NR case. But the PRB count depends on bandwidth and subcarrier spacing. Real exports can also contain partial or non-continuous ranges.

The parser detects the PRB indices present in the file. The heatmap keeps every value, fits the complete range to the screen by default, and displays selected tick labels only. Exact values remain available on hover.

dBm values need power-domain averaging

An arithmetic mean is correct for many raw counters. It is not physically correct for power expressed in dBm.

For dBm values I use:

mean_dBm = 10 * log10(mean(10^(value_dBm / 10)))

For example, the arithmetic mean of -100 dBm and -110 dBm is -105 dBm. The power-domain mean is about -102.6 dBm. That difference matters when engineers compare PRBs or apply thresholds.

The tool therefore asks for the unit and whether higher or lower values represent more interference. It does not label a PRB as good or bad without an explicit threshold and counter meaning.

OSS exports do not all look the same

The importer supports:

Wide rows such as timestamp, cell_id, PRB_0, PRB_1, ...
Long rows such as timestamp, cell_id, prb, interference
Single snapshots without a timestamp
CSV separators using comma, semicolon, or tab
XLSX worksheets and several cells

Automatic detection is useful, but the user can always correct the column mapping before analysis.

The privacy boundary should be visible

Network counter exports can contain sensitive identifiers. Parsing runs in a Web Worker, directly in the browser. The tool does not upload imported content, filenames, cell IDs, headers, or values.

The repository includes synthetic demo files, unit tests, end-to-end tests, and a network privacy test with unique sentinels. No real customer or vendor export is included.

Why make a dedicated tool?

A one-off chart can look convincing and still hide wrong assumptions. A reusable engineering tool gives the same parser, unit rules, calculations, limits, and exports every time.

You can try the tool without an account:

Open the 5G NR PRB Interference Visualizer

The generic engine is open source under MIT:

View the source on GitHub

This is an independent, vendor-neutral visualization tool. Compatibility depends on the structure and meaning of the exported counters.

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.

Online 3GPP RRC & NAS Decoder for 2G to 5G

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

If you have a single RRC or NAS hexadecimal payload from QXDM/QCAT, Wireshark, TEMS, Nemo, a PCAP export or a drive-test log, you should not need to rebuild a complete trace just to inspect one Layer 3 message.

The HiCellTek online 3GPP decoder decodes supported RRC and NAS messages from 2G GSM, 3G UMTS, 4G LTE and 5G NR, including supported structures through 3GPP Release 18. It is accessed directly from a browser, with no local installation.

Quick facts

2G, 3G, 4G and 5G in one interface
RRC and NAS workflows
20 free RRC decodes per day, without signup
Tree and raw views, plus text export in the free plan
NAS, JSON, table view and batch decoding in Pro
Automatic expansion of supported LTE-to-NR containers
Hex frames are processed in memory and are not retained by HiCellTek

RRC and NAS are not the same thing

RRC is the access-stratum control protocol between the UE and the radio network. It carries procedures and configuration such as connection setup, measurement reporting, handover-related reconfiguration, radio bearers, SIBs and UE capabilities.

The official protocol specifications are 3GPP TS 38.331 for NR RRC and 3GPP TS 36.331 for LTE RRC.

NAS runs between the UE and the core network. It covers registration or attach, authentication, mobility management and session management. The relevant specifications include 3GPP TS 24.501 for 5GS NAS and 3GPP TS 24.301 for EPS NAS.

This distinction matters during troubleshooting: an RRC failure points you toward the radio-access procedure, while a NAS reject gives information from the core-network procedure. A reliable diagnosis still requires the surrounding message sequence and radio context.

How to decode an RRC or NAS message online

Open the HiCellTek 3GPP decoder.
Paste the hexadecimal PDU only, without the logging header.
Select GSM, UMTS, LTE or NR.
Select RRC or NAS and the correct logical channel when required.
Choose the direction, or use automatic detection.
Decode and inspect the structured result.

For RRC, selecting the correct channel is important because the same bitstream can only be interpreted against the expected ASN.1 message structure. Typical channels include DL-DCCH, UL-DCCH, DL-CCCH, UL-CCCH, BCCH-BCH, BCCH-DL-SCH and PCCH.

Example: a 5G Registration Reject

Consider this minimal plain 5GS NAS payload:

7e004411

In the expected 5GMM context, it represents a Registration Reject carrying 5GMM cause 17: network failure.

That is useful evidence, but it should not be treated as a complete root-cause analysis by itself. Correlate it with the preceding Registration Request, authentication and security procedures, RRC events and core-network logs.

LTE-to-NR container decoding

One difficult NSA case is an NR configuration embedded inside an LTE RRC message. In EN-DC, an LTE RRCConnectionReconfiguration can carry nr-SecondaryCellGroupConfig-r15, which contains the NR CellGroupConfig.

For supported structures, HiCellTek detects and expands this nested LTE-to-NR container automatically. This avoids manually extracting and decoding the NR payload separately.

HiCellTek or Wireshark?

They solve different parts of the workflow.

Use Wireshark when you have a complete PCAP or PCAPNG and need packet timing, filtering and correlation across protocols. Wireshark's display filters are especially useful for full-trace analysis.

Use the HiCellTek decoder when you already have an isolated RRC or NAS PDU and want a fast structured decode without preparing a capture file.

In practice, the two tools are complementary.

Validation and scope

The production decoding engine was checked against a bounded corpus of 63,375 cases covering 2G through 5G and supported messages through Release 18. The corpus contained 36,904 expected decodes and 26,471 expected safe rejections, with zero oracle or transport failures in that test scope.

This is validation evidence, not a claim that every possible frame or vendor-specific capture format will decode. Malformed, truncated or incorrectly framed payloads may be rejected intentionally.

Documentation and examples

For a compact compatibility scope, a byte-level 5GMM example, official specification links, and the privacy and validation boundaries, see the public HiCellTek 3GPP decoder documentation. The repository contains documentation and examples only; the decoding engine remains proprietary.

Who is it for?

RF engineers working on drive tests and optimization
Protocol analysts investigating signaling procedures
Operators validating SIBs, measurements and radio configuration
Core-network teams reading EPS and 5GS NAS messages
Telecom students learning real 3GPP structures
Anyone who has a hexadecimal Layer 3 payload and needs a readable tree

Try the online decoder

Open the free online 3GPP RRC and NAS decoder.

The free plan includes 20 RRC decodes per day with no signup. NAS decoding and advanced features are available in Pro.

If you test it with a real field capture, tell me which message or workflow you would like the decoder to support next.