The tell is in your own observation: re-establishment uses the UE’s own cell selection, which does not depend on the configured neighbour/measurement list — so a target that is on-air but missing from the handover measurement setup gets found at re-establishment but never appears in the Measurement Report. And because re-establishment onto that cell succeeds, the X2/context/admission path to the target is fine — so this is not a handover-execution or preparation failure. The handover simply never triggers, because the UE is never told to measure the target or its report is never actioned. That narrows it to measurement config / neighbour definition only.
One thing decides which branch you’re in: is the target cell on the same EARFCN as the serving cell (intra-frequency) or a different EARFCN (inter-frequency)?
Intra-frequency (same EARFCN): the UE measures neighbours automatically, so if it never reports the target PCI, the usual causes are — PCI confusion (two neighbours share the same PCI, so the eNodeB can’t resolve the reported PCI and ignores it), the neighbour relation to the target is missing so the eNodeB discards the report, the A3 offset/hysteresis/time-to-trigger is set so high the event never fires, or the relation exists but handover is prohibited/blacklisted.
Inter-frequency (different EARFCN): the UE only measures the target frequency if inter-frequency measurement is configured and triggered — the A2 start threshold, the measurement object for that EARFCN, and measurement gaps. If any of those is missing or mis-set, the UE never measures the target, so it never reports it and no handover fires; re-establishment still finds it by cell selection.
Read these first (don’t change anything yet):
the RRC Connection Reconfiguration measConfig the UE actually receives — does it contain the target’s frequency / measObject at all?
the PCIs the UE does report vs the target PCI, and whether that PCI is unique among the serving cell’s neighbours
the neighbour relation to the target: does it exist, is it blacklisted / HO-prohibited
Tell me the Huawei software release, whether it’s intra- or inter-frequency, and paste that measConfig, and I’ll point you to the exact MO attribute to correct.
The measConfig proves it: this is not an LTE inter-frequency setup at all. The measObject is measObjectUTRA and the reportConfig is reportConfigInterRAT / eventB1 with b1-ThresholdUTRA — the eNodeB is configuring the UE to measure UMTS (3G) neighbours, not L800.
So the UE is never told to measure L800 (the target EARFCN has no measObject here), which is exactly why target PCI 197 never appears in the Measurement Report. The B1 config present is for UTRA cells (PCIs 398 and 402 in this object are UTRA PSCs, unrelated to your L800 PCI 197).
What’s missing:
an LTE inter-frequency measObjectEUTRA for the L800 carrier (its EARFCN)
an A2 threshold to start inter-frequency measurement, plus a measurement gap config so the UE can go measure L800 (a different band from serving L1800)
an A3/A5 inter-frequency reportConfig bound to that measObject via a measId, with L800 PCI 197 reachable through the neighbour freq relation
Because none of that is in the measConfig, no LTE inter-freq event can ever fire → no HO → RLF → re-establishment finds L800 by cell selection (which ignores measConfig), which is why it attaches there directly.
So the fix is on the L1800 serving cell’s mobility config: the L800 inter-frequency measurement is not configured (or not being sent), only the 3G IRAT measurement is. Add/enable the LTE inter-freq measurement to L800 — the EUTRA measObject for the L800 EARFCN, the A2 start trigger, the gap config, and the A3/A5 report bound by measId.