I’m currently facing issues with VoLTE drop calls and VoLTE access failures on an Ericsson network, and I’m trying to understand the best ways to troubleshoot and improve the situation.
Has anyone experienced similar problems? I would appreciate guidance on areas such as:
Key KPIs to check for VoLTE stability
Parameter tuning in Ericsson for VoLTE accessibility and retainability
Possible issues with IMS, SIP signaling, or SRVCC
Radio conditions (coverage, interference, congestion) that could affect VoLTE performance
Any recommended Ericsson counters or traces to analyze
Before trying to go for high end technical stuff my approach will be as follows for these type of issues.
How do you got to know there are Volte Call drops and those are access network faliures?Is there any customer complaints?Are those related to specific region?Specific technology 3G 4G 5G?If it is came from customer care then they should have those info and there should be an incident open related to it as well.This s very important since a call drop can be articulated by thousands of ways.
After gathering thoe preliminary info you can have a calculated gueses which area it could be.I will give you some simple things you can determine from thoses informations.You can check if it is a MO call faliure or MT call faluire or both.Then you can determine it is related to specific network like 3G network 4G network callls only etc.Then you can check wether it is common to specific area and if that is the case check its Tx link degreadation etc.
Then only you can decided which KPIs which dashboards we need to observe to get further more info.(I dont recommend checking node level counters by running command because if that node having an issue running commands to get the measurement will course further trouble.)
Then you need to identify the re productibility of the issue.Either in production or Lab environment.
If we can then reproduce it with all the specific logs eabled to find the route course.
Develop the fix.
This is how I used to troubleshoot these issues in the past ,present and future as well since it worked all the time.There are more than thousands of ways a call can get dropped including the handset and just randomly following a predetermined reason might take you further away from the real issue if there is one which is faced by the customer
VoLTE call drops in an Ericsson network are rarely caused by a single isolated “bug.” Instead, they are typically the result of signaling timeouts, mobility failures, or parameter mismatches between the LTE layer and the IMS/3G layers.
if the problem is “in the network,” here is a diagnostic breakdown of the most likely network-side root causes.
1. Mobility and Handover Failures (The #1 Culprit)
VoLTE is extremely sensitive to handover delays. If the network doesn’t pass the “voice baton” fast enough, the call drops.
* X2 Interface Issues: If the X2 link between two eNodeBs is LOCKED or DISABLED, the network falls back to the slower S1 handover. This often causes enough packet loss to trigger an abnormal release of the QCI-1 bearer.
* Check: st termpointToEnb (Look for DISABLED states).
* SRVCC Parameter Mismatch: A common “hidden” network issue is when a specific frequency (like U900) is not allowed for SRVCC. If a user moves into a 3G-only area and the parameter voiceprio (or similar frequency relations) is set incorrectly, the network won’t even attempt a handover to 3G, resulting in an immediate drop.
* Neighbor Relation Issues: Missing neighbor relations or incorrect PCI (Physical Cell ID) configurations cause the UE to lose its serving cell before it can find a target, leading to Radio Link Failure (RLF).
2. Logical “Internal” Network Errors
Ericsson traces (like RTT or UETR) often show an Internal Reason = 6, which stands for RLC Failure on Signaling Bearer.
* This means the network tried to send a message (like a handover command) multiple times, but the UE never acknowledged it.
* Network cause: This is usually due to Uplink Interference. If the eNodeB is “deaf” because of high noise (RSSI > -100dBm), it won’t hear the UE’s response, even if the UE is receiving a strong signal from the tower.
3. SIP and Bearer Management Issues
Sometimes the “Radio” is perfect, but the “Network Logic” fails.
* QCI-1 Pre-emption: If the network is congested and the parameter qciProfilePreemption is not configured to protect QCI-1, the network might drop a voice call to make room for an emergency call or even a high-priority data user.
* Inactivity Timers: If the ueInactiveTimer is set too aggressively (e.g., shorter than the SIP keep-alive interval), the eNodeB might “clean up” the RRC connection while a user is on mute or waiting, thinking they have disconnected.
4. Summary of “Network vs. Device”
To determine if it’s truly a network problem, look at the Release Cause in your traces:
To track handovers between specific cells (intra-eNodeB) for VoLTE performance, you need to look at Neighboring Cell Relation counters rather than standard cell-level counters. Standard counters tell you that a handover happened, but neighbor-level counters tell you where it was going.
In Huawei U2020/NCE, you should focus on the L.HHO.IntraEnodeB.NeighborCell counter group.
1. The Specific Counters You Need
To investigate VoLTE drops during handover between Cell A and Cell B within the same eNodeB, monitor these:
* L.HHO.IntraEnodeB.PrepAttOut.NeighborCell: Number of handover preparation attempts from the source cell to the specific neighbor cell.
* L.HHO.IntraEnodeB.ExecAttOut.NeighborCell: Number of handover execution attempts.
* L.HHO.IntraEnodeB.ExecSuccOut.NeighborCell: Number of successful handovers to that specific neighbor.
For VoLTE specifically:
You must filter these by QCI 1. If the success rate for QCI 1 is lower than other QCIs, it indicates that the radio conditions or the target cell’s resources are insufficient to maintain the voice bearer during the switch.
2. How to Access This in U2020
Since these are neighbor-level, the “Object” you select in the PM tool is different:
1. Go to Performance > Browse Performance Data.
2. In the Object Tree, do not just select the “Cell.” Look for LTE Neighboring Cell Relation or E-UTRAN External Neighbor Cell.
3. Filter by the specific Source Cell ID and Target Cell ID.
4. Select the L.HHO.IntraEnodeB counters mentioned above.
3. Troubleshooting the “Drops”
If you see a high gap between ExecAttOut and ExecSuccOut for a specific neighbor pair, check the following:
* Ping-Pong Handover: Check L.HHO.IntraFreq.PingPong. Frequent switching back and forth often leads to drops.
* Missing Adjacency: Ensure the neighbor relation is correctly defined in MML using LST EUTRANINTRAFREQNCELL.
* Hardware/Interference: If only one neighbor pair is failing while others are fine, check the Reference Signal Received Quality (RSRQ) of the target cell. High interference on the target cell will cause the VoLTE QCI 1 bearer to drop during the “reconfiguration complete” phase.
Recommendation
If you are seeing drops specifically on VoLTE, I also recommend checking the counter:
L.Thp.Time.DL.QCI1.Drop: To see if the drop occurs exactly when the throughput for the voice bearer hits zero during the HO execution.
