Decoding RRCReconfiguration for Handover Analysis — Field Guide

Every handover in LTE and NR is orchestrated through a single message: RRCReconfiguration (called RRCConnectionReconfiguration in LTE). This message carries the target cell parameters, new identity, measurement configuration, and — for inter-RAT handovers — the entire NR CellGroupConfig that the UE needs to connect to the target.

If a handover fails, the answer is almost always inside this message. But RRCReconfiguration is also one of the most complex messages in the 3GPP RRC specification, with deeply nested ASN.1 structures that are unreadable without proper decoding.

This guide shows you how to read a decoded RRCReconfiguration for handover analysis, what fields matter, what failure patterns look like, and how to troubleshoot mobility problems in the field.

---

How Handovers Appear in RRC Signaling

A successful handover follows this sequence:

1. MeasurementReport (UL) — The UE reports that a neighbor cell meets a configured event trigger (e.g., Event A3: neighbor becomes offset better than serving).
2. RRCReconfiguration (DL) — The network sends the handover command, containing the target cell configuration.
3. RRCReconfigurationComplete (UL) — The UE confirms it has successfully connected to the target cell.

If step 3 never arrives, the handover failed. The UE either:

• Re-establishes on the source or target cell (RRCReestablishmentRequest)
• Goes to idle (radio link failure)

The key diagnostic information lives in the MeasurementReport (why the handover was triggered) and the RRCReconfiguration (what the network told the UE to do).

---

Intra-LTE Handover — Key Fields

For an intra-LTE handover, the RRCConnectionReconfiguration message contains a critical IE called mobilityControlInfo. Its presence is what distinguishes a handover command from a measurement reconfiguration or bearer modification.

Fields to Check in mobilityControlInfo

Field	What It Tells You
targetPhysCellId	The PCI of the target cell. Verify it matches the cell reported in the MeasurementReport.
carrierFreq	The EARFCN of the target cell. If different from the source, this is an inter-frequency handover.
newUE-Identity (C-RNTI)	The new radio identity assigned by the target eNodeB.
radioResourceConfigCommon	Common channel configuration for the target cell (RACH parameters, PUSCH/PUCCH config).
rach-ConfigDedicated	Dedicated RACH preamble for contention-free random access on the target cell. If present, the UE skips contention-based RA.

Fields to Check in measConfig

The same RRCReconfiguration often carries an updated measConfig that reconfigures the UE’s measurements for the new cell:

• measObjectToAddModList — New measurement objects (frequencies to measure)
• reportConfigToAddModList — Event triggers (A1-A6 for LTE, B1/B2 for inter-RAT)
• measIdToAddModList — Links measurement objects to report configurations
• quantityConfig — Filtering coefficients (fc, higher = slower reporting)

A misconfigured measConfig after handover is a common cause of ping-pong (the UE immediately reports the old cell as better and hands back).

---

Inter-RAT Handover: LTE to NR (EN-DC Add / SA Handover)

When a UE transitions from LTE to NR, the handover mechanism depends on the architecture:

EN-DC (NSA) — SCG Addition

In EN-DC, the MN (LTE eNodeB) sends an RRCConnectionReconfiguration containing an nr-Config or nr-SCG (SCG-ConfigInfo) IE. This carries the full NR CellGroupConfig that the SN (gNB) has prepared.

Key fields inside the NR CellGroupConfig:

Field	What It Tells You
spCellConfig	The NR SpCell (PSCell) configuration — the primary NR cell the UE will connect to.
physCellId (NR)	The NR PCI of the target gNB cell.
absoluteFrequencySSB	The NR-ARFCN of the SSB used by the target NR cell.
rlc-BearerToAddModList	RLC bearers being set up on the NR leg — tells you which data radio bearers are being split/offloaded.
mac-CellGroupConfig	MAC layer parameters including BSR, PHR, and scheduling request config for NR.

5G SA Handover

In 5G SA, the message is RRCReconfiguration (NR RRC, not LTE RRC), and it contains reconfigurationWithSync — the NR equivalent of mobilityControlInfo. The key fields are the same conceptually:

• newUE-Identity — New C-RNTI on the target gNB
• spCellConfigCommon — Common config for the target NR cell
• rach-ConfigDedicated — Dedicated preamble for the target

---

Common Handover Failure Patterns

Too-Late Handover

Symptom: The UE sends a MeasurementReport, but before the RRCReconfiguration arrives (or before the UE can complete random access on the target), the source cell radio link degrades to the point of failure.

What you see in decoded messages:

• MeasurementReport with strong neighbor RSRP (e.g., -85 dBm) vs. weak serving (e.g., -120 dBm)
• RRCReconfiguration may or may not have been received
• Followed by RRCReestablishmentRequest on the target cell (cause: handoverFailure)

Root cause: The A3 event offset or hysteresis is too large, or the time-to-trigger is too long. The handover decision comes too late.

Fix: Reduce the A3 offset, shorten time-to-trigger, or add an A5 event as a safety net.

Too-Early Handover

Symptom: The handover completes (RRCReconfigurationComplete is sent), but the UE immediately loses the target cell and re-establishes back on the source.

What you see in decoded messages:

• Successful RRCReconfiguration + Complete sequence
• Followed almost immediately by RRCReestablishmentRequest on the source cell (cause: otherFailure or reconfigurationFailure)

Root cause: The target cell was only momentarily stronger (e.g., fast fading, reflection). The A3 offset is too small or the cell is a “ping-pong” neighbor.

Fix: Increase the A3 offset or time-to-trigger. Consider adding the source/target pair to a Cell Individual Offset (CIO) table.

Ping-Pong Handover

Symptom: The UE repeatedly hands over between two cells in short succession (e.g., every 2-5 seconds).

What you see in decoded messages:

• Alternating MeasurementReports nominating Cell A, then Cell B, then Cell A again
• Corresponding RRCReconfiguration messages with alternating targetPhysCellId values
• No radio link failures — each handover completes, but the UE bounces back

Root cause: Two cells with similar signal levels at the UE location, combined with aggressive handover parameters.

Fix: Increase hysteresis, increase time-to-trigger, or adjust antenna tilt/power to create a clearer dominance boundary.

Reconfiguration Failure

Symptom: The UE receives the RRCReconfiguration but cannot apply it. Typically happens during EN-DC setup when the NR CellGroupConfig contains parameters the UE does not support.

What you see in decoded messages:

• RRCReconfiguration received (DL)
• No RRCReconfigurationComplete (UL)
• Instead: RRCReestablishmentRequest with cause reconfigurationFailure, or MCGFailureInformation / SCGFailureInformation in EN-DC

Root cause: UE capability mismatch (e.g., NR band not supported, unsupported feature in CellGroupConfig), or a malformed message from the network.

Fix: Cross-check UE capabilities (UE-MRDC-Capability, UE-NR-Capability) against the fields in the CellGroupConfig. Look for band combinations, feature group indicators, and supported BWP configurations.

---

Troubleshooting Workflow with Decoded Messages

1. Capture the Handover Sequence

You need three messages minimum: MeasurementReport, RRCReconfiguration, and either RRCReconfigurationComplete (success) or RRCReestablishmentRequest (failure).

With HiCellTek, these appear in real time on the Layer 3 message list, color-coded by direction.

2. Check the Trigger

Decode the MeasurementReport. Identify:

• Which measId triggered the report
• The measResults — serving cell RSRP/RSRQ and the neighbor cell(s) that triggered the event
• Whether the trigger makes sense given the RF conditions

3. Verify the Target Configuration

Decode the RRCReconfiguration. Confirm:

• targetPhysCellId matches the reported neighbor
• carrierFreq is correct
• rach-ConfigDedicated is present (contention-free RA is critical for seamless handover)
• For EN-DC: the NR CellGroupConfig contains valid parameters for the UE

4. Check the Outcome

• RRCReconfigurationComplete present? Handover succeeded at the RRC layer.
• No Complete, followed by Reestablishment? Decode the reestablishment cause.
• MCGFailureInformation or SCGFailureInformation? Decode the failure type for EN-DC-specific issues.

5. Correlate with RF Timeline

Overlay the handover events on an RF timeline (RSRP, RSRQ, SINR per cell). This reveals whether the handover was appropriately timed or if the parameters need adjustment.

---

Decoding RRCReconfiguration with HiCellTek

The HiCellTek decoder fully parses RRCReconfiguration messages for both LTE and NR:

• ASN.1 structure fully expanded — mobilityControlInfo, measConfig, CellGroupConfig, all nested IEs
• Hex + decoded side by side for expert validation
• Real-time capture on the device, or online hex decode for log file analysis

For handover troubleshooting in the field, having the decoded RRCReconfiguration on your screen within seconds of the event — rather than hours later in a post-processing tool — changes how fast you can identify and resolve mobility problems.

---

Key Takeaways

• RRCReconfiguration with mobilityControlInfo (LTE) or reconfigurationWithSync (NR) is the handover command. Its presence distinguishes a handover from other reconfigurations.
• For inter-RAT (LTE to NR), look inside the NR CellGroupConfig carried within the LTE RRCConnectionReconfiguration.
• Handover failures fall into clear patterns — too-late, too-early, ping-pong, reconfiguration failure — each with a distinct signature in decoded messages.
• The MeasurementReport tells you why; the RRCReconfiguration tells you what; the outcome (Complete or Reestablishment) tells you whether.
• Decode first, optimize second. You cannot tune what you cannot see.