SA Handover Execution Failure – Self Site | What Parameters & Steps Should We Check?

5G NR
,
1

Hi everyone,

I’m currently dealing with an SA (Standalone) handover execution failure occurring on the same site (self-site scenario) and would like to gather some insights from the community.

Has anyone encountered this issue before? What parameters, configurations, or troubleshooting steps would you recommend checking to improve handover success rate in this case?

SA Handover Execution Failure – Self Site | What Parameters & Steps Should We Check?
SA Handover Execution Failure – Self Site | What Parameters & Steps Should We Check?1402×1122 184 KB

1 Like
2

For an SA handover failure on the same site, start by checking key parameters like neighbor cell definitions, Xn interface status, and handover thresholds such as A3 offset and time-to-trigger. Misconfigured PCI or TAC conflicts can also cause failures in self-site scenarios, so verify alignment across cells. Logs and UE traces usually reveal whether the issue is signaling or radio-related. Just like resolving technical gaps improves network performance, addressing learning gaps early is important for students preparing for exams or handling GCSE resits, where structured support makes a measurable difference

1 Like
3

All below checks done yesterday but no improvement observed till the time.

  1. RACH, CellRange

  2. Digital/Electricaltilt

  3. Radio/Node Reset

  4. NRCellRelations deletion recreation

  5. CellIndividualoffsetNR

  6. Radio Transmission Mode

  7. TermpointtoGNB

  8. Checked device issue -TC

  9. NR QoS Flow

  10. System Constant (scg)

  11. TAC

  12. RSI

  13. PCI

  14. Diffo also done with neighbor

1 Like
4

What are the L3 messages you seeing, what message is not received/sent compared to a known good handover test?

1 Like
5

Don’t have access to see layer-3 messages. What other we can check?

1 Like
6

If you already checked the cm part, pm part and fm part and everything looks good, then you need l3 signalling, a drive test log replicating the issue you describing to get data so you can discard and discover. If no access, ask for access. Otherwise how are you going to find the problem?

3 Likes
7

Have you verified the Max Number of RRC Connections or User Capacity on the target sector’s baseband processing unit?

Sometimes a “Software Limit” or licensing cap on a specific cell will reject the handover execution even if the radio conditions are perfect

4 Likes
8

Hi Ankur,

Agree with the capacity point. Since RF/config checks are already done, next step should be to split the failure by phase: HO/SCG preparation reject, execution failure, or completion failure.

Please check target-sector counters for admission rejection, max RRC connected users, EN-DC/SCG user limit, baseband capacity, PDCCH/PUCCH resource exhaustion, and license/software user cap. A target cell can reject mobility even when PCI/RSI/TAC/neighbors/RACH are clean.

Without L3 or drive-test logs, the minimum useful evidence is source + target PM counters by failure cause during the test window.

My Hypothesis

Most likely root cause: target-side admission/capacity rejection or hidden software/license limit, because broad RF/config checks were already done with no improvement.

Confidence: 60% — no L3, no PM counter snapshot, no known-good comparison.

If wrong, the most likely alternative is UE-side execution failure after receiving RRC Reconfiguration, because that would also survive neighbor/config checks and only become visible in L3/drive-test logs.

Hope that helps

rgds

1 Like
9

A diff done against another node with same software and RATs?

And swapping enodeBid and Gnodeabid in the original kget?

10

I beg your pardon if you already checked these out:

pmxh -m 4 nrcell pmHoExeAttOutEutran|pmHoExeSuccOutEutran|pmHoPrepAttOutEutran

1 Like