Handover Preparation Failures[S1/Inter MME Case]

Dear Folks,
We recently migrated an ENB from one MME(Pool) to another MME(Pool) with a different TAC. Now all the HO to and from this ENB are S1/Inter MME and there are 100% HO Preparation Failures both ways(to/from this ENB):

What we have done so far:

  1. Recreated all the neighbor relations from the scratch with ANR to make sure no discrepancies exist
  2. Got confirmation from the core that the relevant inter MME definitions for the new TAC are present and correct
  3. While tracing from the S1 trace on MME, there is no handover request or handover required message which can help core guys to trace the issue and the reason for failure. While we can see from RAN counters the HO Preparation attempts are too much and there is 100% Failure
  4. As per the trace, ENB is sending “UE Context Release Request” with cause “Handover-desirable-for-radio-reason”, but no handover required was sent, and subscriber moved to other pool and performed TAU
    Here are the screen shots for these traces any one have faced this scenario. Thanks!

is there any disabled MME? Could you pls check termpoints? (for Ericsson not sure about other vendors) Could you also check RACH success for target cell?

RAN is Ericsson and from eNodeB all the MME are enabled in TermPointMME MO with correct IP address and other details what we have everywhere in the network. RACH Success the same for all the targets.

1 Like

@Matt34 We fixed the issue after blocking TermPointToENB where target eNodeB is on another MME. Now core can see the HO attempts and they all are successful. The question is why eNodeB is attempting an X2 HO for a target that belongs to another MME. We even tried deleting and recreating all the TermPointToENB to clean up any old X2 links but they all get recreated and again started causing preparation failures.

1 Like

I am a bit far away from technical side but if the target is at another MME it should be S1 HO instead of X2. Is this something to check? I could be wrong though…Suggest to check layer 3 messages to investigate further about the cause…