VoLTE - Voice Over LTE@Fntpx

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 54

VOICE OVER LTE - VOLTE

PRESENTED BY HALIMA (HALIMACHOWDHURY07@GMAIL.COM)


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%
VOLTE ISSUE : CAPACITY CONSTRAINT…
LAYER STRATEGY -LTE ( INTER-RAT): FOR
VOLTE ,SRVCC & PSHO
COMMAND : ACTIVATION & OTHER STEPS
COMMAND : ACTIVATION & OTHER STEPS
MORE…
COMMAND : ACTIVATION & OTHER STEPS
MORE…
VOLTE & SRVCC INTEROPERABILITY
STRATEGY : IDLE MODE
STRATEGY : IDLE MODE MORE….
STRATEGY : CONNECTED MODE
STRATEGY : CONNECTED MODE MORE… ..
VOLTE FEATURE RECOMMENDATION : FDD
VOLTE FEATURE RECOMMENDATION : TDD
VOLTE DRIVE TEST KPI
RECOMMENDATION
VOLTE MOST IMPORTANT OSS KPI
VOLTE CALL DROP COUNTERS:
VOLTE CALL SETUP COUNTERS:
VOLTE HO COUNTERS:
VOLTE SRVCC COUNTERS:
VOLTE EMERGENCY CALL SETTINGS
PARAMETERS OPTIMIZATION FOR ENHANCED VOLTE
EXPERIENCE
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}
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.
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
VOLTE CALL DROP OPTIMIZATION
• 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
VOLTE CALL DROP OPTIMIZATION
VOLTE CALL DROP OPTIMIZATION
VOLTE CALL DROP OPTIMIZATION
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
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.
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.
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.
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.
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".
PRACTICAL CASE: RRC REESTABLISHMENT
FAILURE OF A UE MORE…

• 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: 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.
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.
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.
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.
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
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.
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".
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.
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.
PARAMETER SETTINGS FOR VOLTE
NETWORKS WITH HEAVY TRAFFIC
PARAMETER SETTINGS FOR HIGH-SPEED
RAILWAY VOLTE NETWORKS
ESRVCC SCENARIO PARAMETER SETTINGS
VOLTE DATA COLLECTION
VOLTE SIGNALING FLOWS: SRVCC TO 3G
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.
VOLTE – KEY OPTIMIZATION CHALLENGES
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;
• Microsoft Excel
LST CELLDYNPOWERSHARING ; 97-2003 Worksheet
• MORE COMMANDS IN ATTACHED FILE:
THANK YOU

You might also like