You are comparing preparation attempts per cell with execution attempts per neighbour. Every handover that fails in preparation — admission reject, X2/S1 prep failure, timeout, cancel — pegs PrepAttOut but never reaches ExecAttOut, so the per-cell PrepAttOut sum will always exceed L.HHO.NCell.ExecAttOut. That gap is expected.
Compare like with like: per-cell ExecAttOut family against L.HHO.NCell.ExecAttOut summed over the neighbours, or per-cell PrepAttOut against the NCell preparation counter. Per-neighbour failure checking does exist — PrepAttOut minus ExecAttOut is preparation failures, ExecAttOut minus ExecSuccOut is execution failures; you only pulled the middle one.
If a gap remains after matching prep to prep, it is scope: per-neighbour counters peg only for configured neighbour-relation objects with the NCell measurement activated, so ANR-added targets or cells without that measurement drop out of the neighbour sum but still count per cell. Confirm the exact counter names against your release’s counter reference.
If you want, I can go through your actual counter export on this — that’s the kind of work I do for clients.
,…of course i avoided comparing PREP to EXEC.
im talking that EXEC compared to EXEC is not matching…
…
but your last words i think make sense, i need to verify neighbors with measurement activated. i didnt know about that one… thanks, will check
Since you’ve already checked Exec against Exec, I’d narrow this to one source cell and one PM interval. List the neighbour relations expected in that interval, then mark each as present with a value, present with zero, or missing from the export. Don’t turn missing rows into zeros during aggregation. Also check whether the gap is specific to intra-eNB or inter-eNB mobility. That should help isolate collection scope before interpreting the difference as handover failures.