High ERAB drop initiated by MME (pmErabRelMmeAct) in two cosector cells (4G L800 & L1800)

Hi all,
I am having high ERAB drop initiated by MME (pmErabRelMmeAct) in two cosector cells (4G L800 & L1800).
The cells do not have VSWR, neither HO failures.
All sectors are not affected, so I discard the core side issue.
Any suggestion for the next step to check the problem and go forward are highly appritiated.
Vendor is Ericsson.

Did you check intercell HO?

Any PCI collision or any radio issue?

There are no big variation of HO between those two cells have not been observed.

There is no PCI collision, and on radio HW side remotly I have not found any issue (no alarms and no VSWR, RSSI).

There are two reasons specified for MME initiated drops:

  1. Radio network layer problem.
  2. Other abnormal cause.

Would you please specify the radio network layer problems?

May be due to Radio Link Failure.

I think if it was radio link failure it would affect all the cells, and not only two sectors.

MME Induced Drops

The MME drops are usually caused by radio issues but they are pegged under MME drops because the eNB has no way of knowing that the drop was caused by a radio issue. Lets understand with help of different cases that are pegged under MME induced drops.

Uplink RLC Retransmission Issue

Consider a UE that experienced RLF due to maximum number of uplink RLC retransmission. Such a UE will initiate a RRC ReEstablishment procedure to regain its radio link. Now this RRC ReEstablishment can be to the serving cell and in that case, it is usually successful since the serving cell already has the UE’s context. However, this RRC ReEstablishment can also be sent to another cell from eNB2 that does not belong to the source eNB (eNB1). In this case, if eNB2 is a neighbor of the eNB1 so it will try to fetch the context for this UE from eNB1 and based on that it will accept the RRC ReEstablishment. However, if the eNB2 is not a neighbor then it will reject the RRC ReEstablishment. From the UE’s perspective this will be considered a call drop but at the eNB1, the eNB still does not know that this UE has experienced RLF. Now, the UE will initiate a new RRC Connection at the eNB2 and based on that the eNB2 will forward S1 Initial UE Message to the MME. MME will check the UE and it will find out that this UE’s context already exists on the eNB1 so it will send a UE Context Release to the eNB1 and then it will send S1 Initial Context Setup Request to the eNB2. The eNB1 will consider this a MME induced drop since the eNB1 still holds the UE’s context and a release from MME is considered abnormal. However, in reality, such a release is caused by a failure over the radio interface but the eNB1 does not have this knowledge.

A very good reference:

2 Likes

But you must have high RLC retransmisssion and High RRC ReEstablishment.
That can be verified with the relevant available counters.

Thank @Mustafa_Rawat.
What I can understand, as behaviour is not affecting the end user, since the UE keeps its connection to the eNB1.

Correct, thats why in Erab Dro Rate we just consider Abnormal MME Drops.

Do you have by chance those counters that need to be verified?
The abnormalmmedrop counter is not high.

RLC retransmisssion and RRC ReEstablishment.

pmRrcConnReestAtt
pmRrcConnReestSucc

If the attempts are also increased then weak coverage/RF issue is the root cause of this increase.

Do we really need to worry about re-establishment failures?
Will it affect user experience?

In case of reestablishment the session is not dropped.
This is the reason this counter is not used in Ericsson standard formula.

Ok. Is this same for QCI 1 also?

Yes, formula is same. For VoLTE we refer to QCI-1.