One Huawei Sector Keeps Dropping Calls & Data Despite Good RSRP - What Are We Missing?

RAN
, ,
1

Hi experts,

I’m looking for some advice from the RF community on a challenging issue I’m facing on one of the sites I’m working on.

The vendor is Huawei , and the site is running:

  • 4G: L1800 + L700
  • 3G: U850

The strange part is that the usual checks look normal - RSRP and other key RF parameters appear healthy , but one specific sector continues to experience:

  • Continuous call drops
  • Data session drops
  • Poor user experience isolated to this sector

Other sectors are behaving normally, which makes this issue even more confusing.

I have attached the alarm details observed from the site. Would appreciate any expert advice on where to focus the troubleshooting:

  • RF issue?
  • Sector hardware problem?
  • Transmission/backhaul?
  • Parameter/configuration issue?
  • Interference or hidden degradation?

One Huawei Sector Keeps Dropping Calls & Data Despite Good RSRP
One Huawei Sector Keeps Dropping Calls & Data Despite Good RSRP1402×1122 258 KB

Has anyone experienced a similar Huawei LTE/3G sector issue where measurements looked fine but users were still dropping?

One Huawei Sector Keeps Dropping Calls & Data Despite Good RSRP - What Are We Missing?

Any troubleshooting tips, Huawei-specific checks, or past experiences would be highly appreciated. Thanks in advance!

2

Looking at the alarm indication, S1 points more toward a transmission/TNL instability rather than an RF coverage issue .

Since the sector is showing normal RF conditions (RSRP/SINR/RSRQ within acceptable range) but still experiencing continuous call and data drops, I would first investigate the S1 transport path . A TNL issue can cause signaling interruptions, leading to abnormal call releases and data session drops even when radio performance looks healthy.

I would suggest involving the transmission team and checking for any intermittent issues such as:

  • Packet loss / delay variation on the transport path
  • S1 link flapping or resets
  • Interface errors or congestion
  • Backhaul instability
  • VLAN/IP transport issues

From the eNodeB side, please verify the related counters, especially:

  • S1 reset/release events
  • TNL failure-related counters
  • S1 signaling failure counters
  • Call release causes (check if releases are mapped to TNL/S1 failure)
  • Data bearer release/drop counters

One thing to keep in mind: a healthy RSRP does not always mean the site is healthy end-to-end. If the S1 transport is unstable, the user impact will still appear as call drops and data interruptions.

Share the exact alarm and counters if available - it will help narrow down whether this is transport, hardware, or configuration related.

You can check following counters:

L.E-RAB.AbnormRel.TNL
L.E-RAB.AbnormRel.TNL.PreEmp
L.E-RAB.AbnormRel.TNL.Load
L.E-RAB.AbnormRel.TNL.VoIP
L.E-RAB.AbnormRel.TNL.PreEmp.VoIP
L.E-RAB.AbnormRel.TNL.Load.VoIP
L.E-RAB.AbnormRel.TNL.Other
L.E-RAB.AbnormRel.TNL.Other.VoIP
L.E-RAB.AbnormRel.TNL.QCI2
L.E-RAB.AbnormRel.TNL.QCI7
L.E-RAB.AbnormRel.TNL.GtpuError
L.E-RAB.AbnormRel.TNL.GtpuNoResp
L.E-RAB.FailEst.TNL
L.E-RAB.FailEst.TNL.DLRes
L.E-RAB.FailEst.TNL.ULRes
L.E-RAB.FailEst.TNL.VoIP
L.E-RAB.FailEst.TNL.DLRes.VoIP
L.E-RAB.FailEst.TNL.ULRes.VoIP
L.E-RAB.FailEst.TNL.Other
L.E-RAB.FailEst.TNL.Other.VoIP
L.E-RAB.FailEst.TNL.QCI2
L.E-RAB.FailEst.TNL.QCI65
L.E-RAB.FailEst.TNL.QCI69
L.E-RAB.FailEst.TNL.QCI66
L.E-RAB.FailEst.TNL.QCI70
L.E-RAB.FailEst.TNL.Other.QCI1.CBTC
L.E-RAB.FailEst.TNL.ULRes.QCI1.CBTC
L.E-RAB.FailEst.TNL.DLRes.QCI1.CBTC
L.E-RAB.FailEst.TNL.QCI1.CBTC
L.HHO.Prep.FailIn.AdmitFail.TNL.DLRes
L.HHO.Prep.FailIn.AdmitFail.TNL.ULRes
L.HHO.InterFddTdd.Prep.FailIn.AdmitFail.TNL.DLRes
L.HHO.InterFddTdd.Prep.FailIn.AdmitFail.TNL.ULRes
L.HHO.Prep.FailIn.TNL
L.E-RAB.AbnormRel.TNL.PLMN
L.E-RAB.AbnormRel.TNL.PreEmp.PLMN
L.E-RAB.AbnormRel.TNL.Load.PLMN
L.E-RAB.AbnormRel.TNL.VoIP.PLMN
L.E-RAB.AbnormRel.TNL.PreEmp.VoIP.PLMN
L.E-RAB.AbnormRel.TNL.Load.VoIP.PLMN
L.E-RAB.AbnormRel.TNL.Other.PLMN
L.E-RAB.AbnormRel.TNL.Other.VoIP.PLNM
L.E-RAB.FailEst.TNL.PLMN
L.E-RAB.FailEst.TNL.DLRes.PLMN
L.E-RAB.FailEst.TNL.ULRes.PLMN
L.E-RAB.FailEst.TNL.VoIP.PLMN
L.E-RAB.FailEst.TNL.DLRes.VoIP.PLMN
L.E-RAB.FailEst.TNL.ULRes.VoIP.PLMN
L.E-RAB.FailEst.TNL.Other.PLMN
L.E-RAB.FailEst.TNL.Other.VoIP.PLMN
L.HHO.Prep.FailOut.TNL
L.HHO.X2.Prep.FailOut.TNL
L.NsaDc.MenbTrig.SgNB.AbnormRel.TNL
L.NsaDc.SCG.Change.Failure.TNL
L.NB.E-RAB.FailEst.TNL
L.NB.E-RAB.AbnormRel.TNL
L.E-RAB.AbnormRel.TNL.QCI65
L.E-RAB.AbnormRel.TNL.QCI69
L.E-RAB.AbnormRel.TNL.QCI66
L.E-RAB.AbnormRel.TNL.QCI70
L.E-RAB.AbnormRel.TNL.GtpuError.VoIP
L.E-RAB.AbnormRel.TNL.GtpuNoResp.VoIP

But again: if only one sector is experiencing issues while the others are fine, it’s unlikely to be caused by S1, since S1 would affect the entire site.

3

Check the connection between the MME and the router, and verify the eNB-to-MME configuration.

4

Adjust A4 value.