NG-Based Handover Preparation Fails When Xn Link Is Down in 5G SA (Nokia)

5G NR
, , ,
1

Hello Nokia experts,

We are currently observing unusual behavior in our 5G SA network. When the Xn link between two gNBs goes down, the NG-based handover (HO) preparation success rate drops to 0%, even though the number of attempts remains very high (in some cases up to 200k attempts per day on certain sites).

Based on the 3GPP architecture, NG (N2) handover should act as a fallback mechanism when Xn is not available. However, in our network, whenever the Xn link is down, the NG HO preparation fails completely.

The failure cause reported in the counters is “Others” (ng_ho_prep_fail_oth_src).

Has anyone encountered a similar issue in a Nokia 5G SA deployment?
Is there any known dependency between NG HO preparation and the Xn adjacency state in Nokia’s implementation?

NG-Based Handover Preparation Fails When Xn Link Is Down in 5G SA (Nokia)
NG-Based Handover Preparation Fails When Xn Link Is Down in 5G SA (Nokia)1024Ă—1024 143 KB

2

Is this issue happening with a particular target BTS, or across multiple ones?

3

Yes, the issue is not global. It appears specifically when the Xn link between the source and target gNB goes down.

Both the source and target are AirScale nodes.

4

Try collecting PCAP logs or EMIL logs and check what exactly is happening between the source and target gNB.

5

Indeed, the reported cause is radioNetwork: unknown-targetID.

I checked the configuration and confirmed that the target gNB ID is correctly defined on the source site.

6

Have you checked what is happening on the target gNB side?

7

Check the neighbor relation handover type. Is it configured to allow only Xn handover or all types?

Please verify the parameter NrRel-handoverAllowedSa.

8

If NG handover is not allowed by the gNB, there would be no preparation attempts at all.

In this case, however, the preparation success rate is degraded, which means attempts are still being made but they are failing.

9

It was mentioned earlier that the preparation fails, not the preparation attempts. These are two different things — prep attempts, success, and failures are separate metrics.

It would also be good to check whether the target gNB has NG Flex enabled toward multiple AMFs in your case.

10

A preparation failure means that a preparation attempt has already been made.

In other words:
Prep Attempts = Prep Success + Prep Failures.

11

The Xn link with the source site is down.
We haven’t taken a PCAP trace yet.
Also, handover is allowed.

12

Yes, if you can share the Wireshark trace, we may be able to identify the issue. Otherwise, we’ll just be discussing the basics here :slightly_smiling_face:

Also, please confirm that both sites are connected to the same AMF.

13

Unfortunately, I’m not authorized to share it due to privacy concerns.

14

Okay, just make sure that the switch for NG handover (gNB-based) is enabled.

Also, have you ever observed NG HO attempts in your network when the Xn link is up?

15

Here is what I have verified so far:

  • Both sites are connected to the same AMF.
  • The two sites have different TACs, and both are properly configured in the AMF.
  • HO Allowed SA is set to Allowed.
  • The neighbor relation exists and appears to be correctly configured.

In fact, when the Xn link is up, the NG HO attempts are zero.

16

In your PCAP, in which message do you see the cause “unknown-targetID”?

17

Hi could you pls check this parameter

actintraNrNgHO

1 Like