Before Tuning a 5G SA Handover Failure, What Evidence Would You Request Next?

5G NR
, , , ,
1

Following several recent discussions about 5G SA handover failures, I would like to isolate one recurring troubleshooting problem:

What evidence should be requested before anyone starts changing mobility parameters?

Consider this situation:

  • The handover execution success KPI is degraded.
  • PM counters show failed execution attempts.
  • Decoded UE Layer 3 is not available.
  • Source and target gNB traces may be available, but their time alignment is uncertain.
  • No reliable per-attempt call flow has been reconstructed yet.

Based only on this information:

  1. What is the last handover checkpoint you would consider safely verified?
  2. What exact evidence would you request next from the UE, source gNB, target gNB or core teams?
  3. If several traces are available, how do you verify that their timestamps and UE identities can be correlated?
  4. What would you explicitly refuse to conclude at this stage?

If possible, phrase your answer as the first three items you would put in the actual investigation ticket.

I am documenting a vendor-neutral troubleshooting workflow. This is not a request for proprietary traces, customer information or vendor-confidential procedures.

I will share a vendor-neutral summary of the useful responses back with the community.

Before Tuning a 5G SA Handover Failure, What Evidence Would You Request Next?
Before Tuning a 5G SA Handover Failure, What Evidence Would You Request Next?1672Ă—941 276 KB

2

The trap in this scenario is that a degraded execution-success KPI with failed-execution counters tells you the phase, not the cause, and nothing past the source gNB is actually verified yet.

Last safely verified checkpoint: HO preparation completed. An execution attempt being counted means the source made the decision, the Xn Handover Request was acknowledged by the target, and the source issued the RRCReconfiguration with reconfigurationWithSync to the UE. Everything from the UE’s RACH to the target onward is unverified. You cannot say the UE received the command intact, RACHed, or reverted, without L3.

The three items I would put in the ticket, in order:

Ticket item 1. Pull per-UE L3 for a set of failed attempts from the UE and the source gNB: the RRCReconfiguration (handover command) and the T304 outcome. T304 expiry versus completion is the single fact that says whether execution failed at the air interface or the UE reached the target. State on the ticket that no execution-side root cause is permitted until this is in hand.

Ticket item 2. Request target-side evidence for the same attempts: did the UE’s PRACH Msg1/Msg3 arrive at the target, and was RRCReconfigurationComplete received. This one item splits the failure into three different faults with three different fixes: UE never reached the target (coverage, timing advance, PRACH config, wrong PCI in the command), reached it but no reconfig-complete (bad target configuration or contention), or reverted to source (re-establishment). Without it you cannot tell which.

Ticket item 3. Prove correlation before any analysis. Confirm both gNBs share a disciplined time source (PTP or NTP to the same grandmaster); if not, do not overlay traces on raw wall-clock. Correlate UE identity on the XnAP Old and New NG-RAN node UE ID pair plus the C-RNTI and the newUE-Identity carried in the reconfiguration and seen at target RACH. Align time using a shared Xn message as the anchor (Handover Request and its Ack appear in both traces), compute the offset from that, then apply it. No call flow is accepted as reconstructed until this passes.

What I would refuse to conclude at this stage: that any mobility parameter is wrong. Failed-execution counters do not implicate A3 offset, TTT, hysteresis, or CIO, because those govern the trigger, and the failure here is in execution, a later phase. I would also refuse to blame the target gNB when the UE may never have reached it, and refuse to trust any two traces overlaid before their clock offset is established, since a mis-aligned overlay manufactures a false call flow that looks like a real one.

Net: verify the trigger and preparation are not the issue, get T304 plus target RACH to localise the execution failure, and lock trace correlation before touching a single parameter.

3

Excellent breakdown, especially the separation between phase and cause and the correlation gate.

One boundary I would like to challenge for a vendor-neutral workflow: would you treat an “execution attempt” counter as proof that preparation completed and RRCReconfiguration was issued across vendors and handover paths, or only after checking the exact counter definition and whether the procedure was intra-gNB, Xn or N2?

That seems to determine how far the “last verified checkpoint” can safely move.

4

Correct. The execution-attempt counter moves the checkpoint no further than preparation was attempted. Before claiming preparation completed and RRCReconfiguration issued, confirm two things: the vendor’s exact counter definition (pegs on command-sent versus procedure-entered) and the handover path (intra-gNB, Xn, or N2).

By path: intra-gNB has no inter-node preparation; Xn pegs after Handover Request Acknowledge and reconfiguration issued; N2 pegs after AMF-mediated HandoverCommand.

Ticket step zero, before item 1: classify the path and read the counter definition. Until both are known, the only safe statement is that the source entered handover execution.

5

Agreed. This is an important correction. I treated an “execution attempt” counter as if it represented a protocol-invariant checkpoint, which is too strong.
The evidence flow should therefore begin with ticket step zero:

  1. classify the path as intra-gNB, Xn or N2;
  2. capture the exact vendor counter name and peg definition;
  3. only then map the counter to a protocol checkpoint.
    If either the path or peg condition is unknown, the safe output remains: “the source entered handover execution.” Preparation completion, command issuance and UE receipt all remain unproven.
    Would you also capture the vendor software release at step zero, or is the exact counter definition normally sufficient in practice?
6

Yes, capture the software release at step zero, always. The counter definition is not stable across releases, so the definition alone is only sufficient if you also know which release produced it.

Same counter name can change peg point, get renamed, be split into two, or be deprecated between releases. A definition you pull from one release’s reference does not reliably describe the value in the PM file unless the release matches. So release plus counter name is the unit that resolves to a definition; the name on its own does not.

Release also decides the trace schema and the event/IE names you will correlate against in the later steps, so you need it recorded once at the start regardless.

So step zero is three items, not two: handover path, vendor plus release, and the exact counter name with its peg definition as documented for that release. If the release is unknown, treat the peg definition as unverified and hold at “the source entered handover execution.”