L.E-RAB.FailEst.MME what could be the possible reason for that.
1 Like
1.Transport layer and radio network layer problems.
2.No resources available at enodeB(Congestion)
3.N o response from the UE.
4.Faults on the MME side
5.Security mode configuration failure
These are the main reasons…for RAB failures…4&5 both are main reasons
1 Like
Thanks
Your always welcome
L.E-RAB.FailEst.MME appears when the number of E-RAB setup failures triggered by the MME. You should optimize the MME timers or raise this issue with core team
In my NW, very high pegging of L.E-RAB.FailEst.MME is seen on almost all sites. But it’s not related to MME. I have analyzed traces and release cause is normal mostly on Uu Interface. At S1 Interface, it corelates with S1AP INITIAL CONTEXT FAIL due to interaction with other procedure (MTC Call). Is there some feature/configuration to avoid pegging of L.E-RAB.FailEst.MME or pegging it as normal release at Radio Interface as E-RAB SR as 99.86% at NW is not achievable after stuggling with all other possible configurations.
Vendor is Huawei.
@Hainm : You proposed this solution some time ago, have you ever tried? Can you please tell me exact parameter name?
UE is in handover progress, source enb already sent HO preparation require to MME or other enb. During Handover, UE has service request of Csfb mo/mt, and csfb also initiated by mme sent s1ap context setup request. But enb found it conflict with HO procedure, so enb reply with context setup failure due to interaction.
Solution: it has one parameter to prefer csfb during HO. eNodeB will cancel handover, process CSFB.
A cause value “Interaction with other procedure” was introduced and used in the section 8.4.1.2 of the Handover Preparation procedure
Interactions with E-RAB Management procedures:
If, after a HANDOVER REQUIRED message is sent and before the Handover Preparation procedure is terminated, the source eNB receives a MME initiated E-RAB Management procedure on the same UE associated signaling connection, the source eNB shall either:
1.cancel the Handover Preparation procedure by executing the Handover Cancel procedure with an appropriate cause value "Interaction with other procedure”. After successful completion of the Handover Cancel procedure, the source eNB shall continue the MME initiated E-RAB Management procedure.
As per 3GPP, here is the reason of this cause failure.
Enable parameter csfbflowfirstswitch under globalprocswitch.
Will it improve these failures?
Let me try, thanks!
As per these failures are due to the collision of handover procedure.
CSFB preparation will improve.
It will delay HO procedure as it will reduce L.E-RAB.FailEst.MME & S1AP INITIAL CONTEXT FAIL due to interaction with other procedure, but will it impact Handover Success Rate?
I’ve checked… this is already enabled. 
Any other helpful suggestion?
I think your MME should have a feature. Or you can acquire the feature from your vendor.
Talk to your mme engineer about prioritising paging support for CSFB falls
The MSC/VLR sends priority indication as part of paging message to MME, the MME relays this priority as paging priority information element of the S1 AP paging message to enode B.
Otherwise the MME can also be configured to send user defined priority paging to enode B in s1ap paging request irrespective of msc/vlr sending a priority message(this works for MT calls only)
The MME sets the csfb high priority in the indicator IE of the context setup messages this allows the UE to set up rrc connections with a higher priority than handover.
What is the setting of the other switch .
It has a csfbflowfirstswitch and an erabflowfirst switch.
You might need to switch off the erab first.
Look at my net params:
I also has two counters that counts 100% of eRAB access Failure:
- L.E-RAB.FailEst.MME
- L.E-RAB.FailEst.RNL.eNodeB.NormRel
I have read on Hedex it’s due to signaling procedures going on while erab setup request or initial context setup request from MME.
Try and Check if you have.
HO and E ERAB Conflict processing strategy.
Parameter ID HoErabConflProcessingStrat.
Check A2 threshold.
Check why HO happened during CSFB from you UU signaling trace.
Opening CSFBFlowFirst Switch will improve CSFB failures due to conflict with HO procedure in prep phase.
Yes already tried this, if I set this to e-RAB then it only improves RNL failures, no change in MME failures.
Thanks, let me check.
in this image of the trace there is no handover procedure shown but cause is still showing interaction with other procedure.
Did you ever find out what procedure it was referring to?
Did you solve this problem?
I have the same problem. Please could you tell me what did you do to solve it?