The document discusses various capacity constraints and issues that can cause VoLTE call drops. It describes how the physical downlink control channel (PDCCH) can become a bottleneck with more than 120 users. It recommends keeping resource utilization metrics like PDCCH, uplink PRB, and downlink PRB below 50% to avoid congestion issues. The document also provides strategies for optimizing VoLTE performance by adjusting LTE layer and radio resource parameters.

1. VOICE OVER LTE - VOLTE
PRESENTED BY HALIMA (HALIMACHOWDHURY07@GMAIL.COM)

2. VOLTE ISSUE : CAPACITY CONSTRAINT
• THOUGH VOICE HAS NEGLIGIBLE BANDWIDTH REQUIREMENT COMPARED TO
DATA, STILL CELL RESOURCE USAGE CAN RESTRICT/LIMIT VOLTE CALL.
• PDCCH CAN BE CONSIDERED AS VOLTE BOTTLENECK FOR MOST CASES
• USERS OVER 120 MAY CAUSE PDCCH LIMITATION FIRST, FOLLOWED BY UPLINK
PRB
• MORE EDGE USERS WITH BAD PDCCH COVERAGE CAN CONSUME MORE CCE
RESOURCE ALSO
• UL PRB UTILIZATION , DL PRB UTILIZATION , PAGING RESOURCE UTILIZATION ,
PDCCH RESOURCE UTILIZATION SHOULD BE LESS THAN 50%
• DL RECEPTION & UL TX ETHERNET PORT BANDWIDTH USAGE SHOULD BE LESS
THAN 60%

3. VOLTE ISSUE : CAPACITY CONSTRAINT…

4. LAYER STRATEGY -LTE ( INTER-RAT): FOR
VOLTE ,SRVCC & PSHO

5. COMMAND : ACTIVATION & OTHER STEPS

6. COMMAND : ACTIVATION & OTHER STEPS
MORE…

7. COMMAND : ACTIVATION & OTHER STEPS
MORE…

8. VOLTE & SRVCC INTEROPERABILITY
STRATEGY : IDLE MODE

9. STRATEGY : IDLE MODE MORE….

10. STRATEGY : CONNECTED MODE

11. STRATEGY : CONNECTED MODE MORE… ..

12. VOLTE FEATURE RECOMMENDATION : FDD

13. VOLTE FEATURE RECOMMENDATION : TDD

14. VOLTE DRIVE TEST KPI RECOMMENDATION

15. VOLTE MOST IMPORTANT OSS KPI

16. VOLTE CALL DROP COUNTERS:

17. VOLTE CALL SETUP COUNTERS:

18. VOLTE HO COUNTERS:

19. VOLTE SRVCC COUNTERS:

20. VOLTE EMERGENCY CALL SETTINGS

21. PARAMETERS OPTIMIZATION FOR ENHANCED VOLTE
EXPERIENCE

22. OPTIMIZATION PARAMETER MORE…
• FEW PARAMETERS TO BE CHANGED NEXT WEEK BY RUNNING THE FOLLOWING COMMAND:
- MOD CELLDRXPARA: LOCALCELLID=1,
DRXSTATEDURINGULHARQRETX=DRX_ACTIVE_FOR_VOICE,
DRXSTOPSRPENDINGSW=ON;{SITE_NAME}
- MOD CELLULSCHALGO: LOCALCELLID=1,
ULENHENCEDVOIPSCHSW=ULVOIPRBLERCONTROLSWITCH-1;{SITE_NAME}

23. CLUSTER LEVEL KPI’S…
-MAC Retransmission & IBLER Rate improvement was noticed (almost 12 %).
-DL Cell throughput improvement was noticed (from 15.74Mbps to 16.06Mbps)
-All other KPI’s are showing normal trend.

24. VOLTE CALL DROP REASON
• SERVICE DROPS DUE TO RADIO FAULTS
• SERVICE DROPS DUE TO HO FAILURES
• SERVICE DROPS DUE TO TX FAULTS
• SERVICE DROPS DUE TO CONGESTION
• SERVICE DROPS DUE TO MME FAULTS

25. • THE CALL DROP PROBLEM OF A COMMERCIAL NETWORK IS OBSERVED FROM THE
TRAFFIC STATISTICS AND IS REFLECTED BY THE CALL DROP RATE , CALL DROP
COUNT AND TIME SEGMENT OF TOP CELLS.
VOLTE CALL DROP OPTIMIZATION

26. VOLTE CALL DROP OPTIMIZATION

27. VOLTE CALL DROP OPTIMIZATION

28. VOLTE CALL DROP OPTIMIZATION

29. VOLTE CALL DROP OPTIMIZATION

30. DIAGNOSING RADIO PROBLEMS
• FAULT DESCRIPTION
• IF THE ABNORMAL RELEASE IS RECORDED IN THE COUNTER L.E-RAB.ABNORMREL.RADIO, THE
ABNORMAL RELEASE IS CAUSED BY UU INTERFACE AND OCCURS IN A NON-HANDOVER SCENARIO.
• POSSIBLE CAUSE
• THE ABNORMAL RELEASE IS CAUSED BY WEAK COVERAGE, UPLINK INTERFERENCE, OR ABNORMAL
UE THAT LEAD TO MAXIMUM NUMBER OF RLC RETRANSMISSIONS, OUT-OF-SYNC, OR FAILURE OF
SIGNALING INTERACTIONS.
• FAULT HANDLING PROCEDURE
• ANALYZE THE CHR TO CHECK WHETHER SOME TOP UES HAVE THE HIGHEST COUNT.
• ANALYZE THE CAUSE VALUES RECORDED IN THE CHR.
• IF THE CALL DROP IS CAUSED BY A FACTOR OTHER THAN THE SIGNALING PROCEDURES, ANALYZE
THE DRB SCHEDULING AT LAYER 2 TO DETERMINE WHETHER THE CALL DROP IS CAUSED BY WEAK
COVERAGE OR INTERFERENCE.
• IF THE CALL DROP IS CAUSED BY SIGNALING PROCEDURES, OBSERVE THE LAST TEN SIGNALING
MESSAGES TO DETERMINE THE FAULTY SIGNALING PROCEDURE. DETERMINE WHETHER THE FAULT
OF THE SIGNALING PROCEDURE IS DUE TO FAILURE TO RECEIVE OR PROCESS THE SIGNALING
MESSAGES BY EITHER THE UE OR ENODEB

31. DIAGNOSING HANDOVER FAILURES
• FAULT DESCRIPTION
• IF THE ABNORMAL RELEASE IS RECORDED IN THE COUNTER L.E-
RAB.ABNORMREL.HOFAILURE, THE ABNORMAL RELEASE IS CAUSED BY
OUTGOING HANDOVER FAILURE.
• FAULT HANDLING PROCEDURE
• OBTAIN THE TOP CELLS THAT HAVE THE HIGHEST COUNTER L.E-
RAB.ABNORMREL.HOFAILURE, ANALYZE THE PAIRS OF SOURCE AND TARGET
CELLS TO OBTAIN THE TOP TARGET CELLS THAT HAVE THE HIGHEST FAILURE RATE.
• ANALYZE THE CHR OF THE SOURCE AND TARGET CELLS TO DETERMINE WHETHER
THE HANDOVER FAILURE IS CAUSED BY FAILURE TO RECEIVE THE HANDOVER
COMMAND OR RANDOM ACCESS FAILURE.
• OPTIMIZE THE HANDOVER PARAMETERS AND NEIGHBOR RELATIONSHIP AND
CHECK WHETHER THE CALL DROP KPI IS IMPROVED.

32. DIAGNOSING THE TRANSMISSION NETWORK
PROBLEM
• FAULT DESCRIPTION
• IF THE ABNORMAL RELEASE IS RECORDED IN THE COUNTER L.E-
RAB.ABNORMREL.TNL, THE ABNORMAL RELEASE IS CAUSED BY THE TRANSMISSION
NETWORK.
• POSSIBLE CAUSE
• THE ABNORMAL RELEASE IS CAUSED BY ABNORMAL TRANSMISSION BETWEEN THE
ENODEB AND MME, SUCH AS S1 INTERFACE BREAK.
• FAULT HANDLING PROCEDURE
• CHECK FOR ALARMS ABOUT THE TRANSMISSION NETWORK. CLEAR THE ALARMS AND
CHECK WHETHER THE PROBLEM OF ABNORMAL RELEASE IS SOLVED.
• OBSERVE THE M2000 AND CHECK WHETHER ALARMS ABOUT THE TRANSMISSION
NETWORK ARE RECORDED IN THE M2000.
• CLEAR THE ALARMS.
• IF ABNORMAL RELEASES ARE STILL RECORDED IN THE COUNTER L.E-
RAB.ABNORMREL.TNL, COLLECT THE LOGS AND SUBMIT THEM TO R&D ENGINEERS
FOR FURTHER ANALYSIS.

33. DIAGNOSING THE CONGESTION PROBLEM
• FAULT DESCRIPTION
• IF THE ABNORMAL RELEASE IS RECORDED IN THE COUNTER L.E-
RAB.ABNORMREL.CONG, THE CALL DROP IS CAUSED BY RESOURCE CONGESTION.
• POSSIBLE CAUSE
• THE ABNORMAL RELEASE IS CAUSED BY RADIO RESOURCE CONGESTION, SUCH AS
EXCEEDING THE MAXIMUM NUMBER OF USERS.
• FAULT HANDLING PROCEDURE
• IF THE LONG-TERM CONGESTION OF A TOP CELL LEADS TO CALL DROPS, A
SHORT-TERM SOLUTION IS TO ENABLE THE MLB ALGORITHM OR INTER-
OPERATION TO ALLEVIATE THE LOAD OF THE LOCAL CELL. THE LONG-TERM
SOLUTION IS TO EXPAND THE CAPACITY.
• ENABLE THE MLB ALGORITHM AND CHECK WHETHER THE CONGESTION PROBLEM
IS ALLEVIATED.

34. DIAGNOSING MME FAULTS
• FAULT DESCRIPTION
• IF THE ABNORMAL RELEASE IS RECORDED IN THE COUNTER L.E-
RAB.ABNORMREL.MME, THE ABNORMAL RELEASE IS INITIATED BY THE EPC.
HOWEVER, THIS ABNORMAL RELEASE IS NOT RECORDED IN THE COUNTER L.E-
RAB.ABNORMREL.
• FAULT HANDLING PROCEDURE
• ANALYZE THE INFORMATION OF THE EPC.
• THE CAUSE VALUE RECORDED IN THE CHR IS UEM_UECNT_REL_MME_CMD.
ANALYZE THE LAST TEN SIGNALING MESSAGES RECORDED IN THE CHR. IF THESE
MESSAGES SHOW THAT THE PROBLEM IS NOT CAUSED BY THE ENODEB, FOCUS
ON ANALYSIS OF THE EPC.
• ANALYZE THE S1 INTERFACE TRACE OF THE TOP CELLS TO OBTAIN THE
DISTRIBUTION OF THE CAUSE VALUE.
• DISCUSS WITH THE EPC ENGINEERS ABOUT THE ANALYSIS RESULT AND
SIGNALING MESSAGES.

35. PRACTICAL CASE: RRC REESTABLISHMENT FAILURE
OF A UE
• AS SHOWN IN THE UPPER RIGHT FIGURE,
THE CAUSE VALUE OF THE ABNORMAL
RELEASE IS RRC_REEST_SRB1_FAIL.
• AS SHOWN IN THE MIDDLE RIGHT FIGURE,
THIS PROBLEM OCCURS REPEATEDLY FROM
11:51 O'CLOCK TO 18:49 O'CLOCK IN
CELL 0.
• AS SHOWN IN THE LOWER RIGHT FIGURE,
THE TMSI COLUMN SHOWS THAT THIS
PROBLEM IS CONTRIBUTED BY A SINGLE UE
WHOSE TMSI IS C2 B0 B0 40 AND THE
CAUSE VALUE IS "RECONFIGURATION
FAILURE".

36. • AS SHOWN IN THE FIGURE, THE
MESSAGE TYPE INDICATES THAT THIS
RECONFIGURATION MESSAGE IS NOT A
HANDOVER COMMAND OR
MEASUREMENT CONTROL. THIS MESSAGE
IS PROBABLY FOR RECONFIGURATION OF
THE CQI, SRS, OR TRANSMISSION
MODE (TM). UPON RECEPTION OF THE
RRC CONN REESTAB MESSAGE, THE
UE DOES NOT RESPOND. THEREFORE,
THE ENODEB RELEASES THE UE IN 5S.
PRACTICAL CASE: RRC REESTABLISHMENT FAILURE
OF A UE MORE…

37. PRACTICAL CASE: UE EXCEPTION
• ANALYSIS OF THE CHR SHOWS THAT THE
CAUSE VALUE OF THE ABNORMAL RELEASE IS
RLC_UNRESTORE_IND. THIS CAUSE
VALUE INDICATES THAT THE MAXIMUM
NUMBER OF DRB RLC RETRANSMISSIONS IS
EXCEEDED.
• THIS PROBLEM OCCURS REPEATEDLY FROM
10:51 TO 13:49 IN CELL 2.
• THE TMSI COLUMN INDICATES THAT THIS
PROBLEM IS CONTRIBUTED BY A SINGLE UE
WHOSE TMSI IS C2 7F 20 56.

38. PRACTICAL CASE: UE EXCEPTION MORE…
• THE LAST 16 DRB SCHEDULING PROCEDURES AT A PERIOD OF 64MS INDICATE
THAT THE SYMPTOMS ARE SIMILAR. THE SYMPTOMS ARE THAT THE UE
ENCOUNTERS SUDDENLY TERMINATED DATA TRANSMISSION SHORTLY AFTER THE
ACCESS. THE DURATION FROM ACCESS TO RELEASE IS TENS OF SECONDS TO 2
MINUTES, INDICATING THAT THE PROBLEM IS NOT CAUSED BY SCRIPT TEST. THE
ACCESS TYPE IS MO-DATA, INDICATING THAT THE USER IS PERFORMING A
SERVICE.

39. PRACTICAL CASE: POOR UPLINK QUALITY
• AS SHOWN IN THE TOP FIGURE, THE
UPLINK RSRP AND SINR RECEIVED BY
THE ENODEB ARE POOR FROM THE
LAST FOUR 512 MS TO THE LAST
SIXTEEN 64 MS: THE UPLINK RSRP IS
BELOW –135 DBM AND THE SINR OF
THE SRS AND DMRS IS BELOW –3
DB, INDICATING THAT THE SERVICE
DROP IS CAUSED BY UPLINK WEAK
COVERAGE.
• AS SHOWN IN THE BOTTOM FIGURE,
FROM THE LAST FOUR 512 MS TO THE
LAST SIXTEEN 64 MS, THE UPLINK
RSRP IS ABOUT –130 DBM BUT THE
SINR OF THE UPLINK SRS AND
DMRS IS BELOW –3 DB, INDICATING
THAT THE SERVICE DROP IS DUE TO
WEAK COVERAGE CAUSED BY WEAK
UPLINK INTERFERENCE.

40. PRACTICAL CASE: TARGET CELL RECONFIGURATION
FAILURE
• TGT_ENB_RB_RECFG_FAIL IS THE CAUSE VALUE CONTAINED IN THE RB
RECONFIGURATION FAILURE MESSAGE DURING A HANDOVER.
• IN 100 MS, SENDS THE UE CONTEXT REL REQ MESSAGE CONTAINING THE CAUSE
VALUE "UNSPECIFIED". THE LOWER LEFT FIGURE SHOWS THE LAST TEN SIGNALING
MESSAGES.
• DURING THE HANDOVER PROCEDURE, THE EPC DELIVERS THE PATH_SWITCH_ACK
MESSAGE CONTAINING THE DOWNLINK AMBR VALUE THAT IS INCONSISTENT WITH
THE DOWNLINK AMBR CONTAINED IN THE S1/X2 HANDOVER REQUEST. ANALYSIS
SHOWS THAT THIS IS A DEFECT OF THE RR MODULE.

41. PRACTICAL CASE: SERVICE DROP CAUSED BY
INTER-RAT REDIRECTION
• RELEASE CAUSE: INTER-RAT REDIRECTION
• IRHO_REDIRECTION_TRIGER IS THE RELEASE
CAUSED BY INTER-RAT REDIRECTION. IN
ERAN2.1SPC400/SPH401, THIS CAUSE VALUE IS
COUNTED AS A CALL DROP, AS SHOWN IN THE
FOLLOWING FIGURE.
• THIS PROBLEM IS SOLVED IN ERAN2.1 SPC420, AS
SHOWN IN THE RIGHT FIGURE

42. PRACTICAL CASE: SERVICE DROP CAUSED BY
ABNORMAL TRANSMISSION
• THE SERVICE DROP RATE OF THE ENTIRE NETWORK DETERIORATES FOR THE TELE2
900M, TELENOR 900M, AND TELE2 2.6G BANDS, AS SHOWN IN THE FOLLOWING
FIGURE.

43. PRACTICAL CASE: SERVICE DROP CAUSED BY
ABNORMAL UU INTERFACE
• RELEASE CAUSE
• UE_RESYNC_TIMEROUT_REL_CAUSE INDICATES THAT THE ABNORMAL RELEASE
IS CAUSED BY RESYNCHRONIZATION UPON TIMEOUT OF THE RESYNCHRONIZATION
TIMER. THE SAME PROBLEM IS RECORDED BY THE STANDARD INTERFACE TRACE AS
"RADIO CONNECTION WITH UE LOST".
• UE_RLC_UNRESTORE_IND INDICATES THAT THE ABNORMAL RELEASE IS CAUSED BY
RESTORATION FAILURE AFTER EXCEEDING THE MAXIMUM NUMBER OF RLC
RETRANSMISSIONS. THE SAME PROBLEM IS RECORDED BY THE STANDARD INTERFACE
AS "RADIO RESOURCES NOT AVAILABLE".
• UE_RESYNC_DATA_IND_REL_CAUSE INDICATES THAT THE ABNORMAL RELEASE IS
CAUSED BY RESYNCHRONIZATION TRIGGERED L2 REPORT DATA. THE SAME PROBLEM
IS RECORDED BY THE STANDARD INTERFACE TRACE AS "UNSPECIFIED".

44. PRACTICAL CASE: SERVICE DROP CAUSED BY
ABNORMAL UU INTERFACE MORE…
• CAUSE ANALYSIS
• THE DRB SCHEDULING INFORMATION AT THE LAST 4 512MS AND 16 64MS PERIODS
SHOWS THAT MOST ABNORMAL RELEASES ARE CAUSED BY SUDDENLY TERMINATED
DATA TRANSMISSION, POSSIBLY CAUSED BY UNPLUGGING THE DATA CARD OR UE
FAULT. THE FOLLOWING FIGURE SHOWS THE CHR INFORMATION.

45. PRACTICAL CASE: RRC CONNECTION
REESTABLISHMENT FAILURE
• RRC_REEST_SRB1_FAIL INDICATES FAILURE TO RESTORE SRB1 DURING
RRC REESTABLISHMENT.
• THE LAST 10 SIGNALING MESSAGES AS SHOWN IN THE FOLLOWING
FIGURE INDICATES THAT AFTER SENDING THE RRC_CONN_REESTAB
MESSAGE, THE ENODEB FAILS TO RECEIVE THE
RRC_CONN_REESTAB_CMP MESSAGE FROM THE UE BEFORE THE 5S
TIMER ON THE UU INTERFACE EXPIRES.
• THE L2 SCHEDULING INFORMATION SHOWS THAT THE UE SENDS THE
ACK MESSAGE UPON RECEPTION OF THE RRC_CONN_REESTAB
MESSAGE. WE SUSPECT THAT THE PROBLEM IS CAUSED BY FAILURE OF
SOME UES TO SEND THE RRC_CONN_REESTAB_CMP MESSAGE. SOME
SAMSUNG UES HAVE SUCH A PROBLEM.

46. PARAMETER SETTINGS FOR VOLTE
NETWORKS WITH HEAVY TRAFFIC

47. PARAMETER SETTINGS FOR HIGH-SPEED
RAILWAY VOLTE NETWORKS

48. ESRVCC SCENARIO PARAMETER SETTINGS

49. VOLTE DATA COLLECTION

50. VOLTE SIGNALING FLOWS: SRVCC TO 3G

51. SRVCC PARAMETER OPTIMIZATION
• AFTER THE VOLTE IS PUT INTO COMMERCIAL USE, THE CALL DROP RATE
AT SOME SUBWAY SITES IS HIGH. BY ANALYZING DRIVE TEST DATA AT
THESE SITES, NETWORK COVERAGE IS NOT CONTINUOUS.
• WE CHANGED FOLLOWING PARAMETERS
• THE NETWORK COVERAGE IS NOT CONTINUOUS IN SUBWAYS. DURING
MOVEMENT, SIGNALS ARE FAST FADED. MODIFYING ESRVCC
PARAMETERS CAN IMPROVE VOLTE USER EXPERIENCE.

52. VOLTE – KEY OPTIMIZATION CHALLENGES

53. SOME ESSENTIAL COMMAND TO CHECK VOLTE CELLS
STAT
• DSP / RMV RETSUBUNIT; ! TO CHANGE RET.
• LST CELL; ! IT INDICATES THE ACTIVE STATE OF THE CELL. IT CONSISTS OF THE ACTIVATED AND
DEACTIVATED STATES.
• DSP USERBASICINFO; ! TO SEE HOW MANY USERS ATTACHED
• LST ALMAF; ! TO KNOW IF ANY ALARMS
• DSP CELLUECNT ;
• DSP ALLBASICINFO;
• LST/MOD/ADD EUTRANINTERFREQNCELL;
• LST/MOD/ADD EUTRANINTRAFREQNCELL;
• LST/ADD EUTRANEXTRNALCELL;
• DSP LICUSAGE / LICENSE;
• DSP RAEDEVICEDATA ;
• LST CELLCHPWRCFG;
• LST PDSCHCFG;
• LST CELLDYNPOWERSHARING ;
• MORE COMMANDS IN ATTACHED FILE:

54. THANK YOU