10 Wcdma Call Drop Problem Analysis.pdf

10 WCDMA Call Drop Problem Analysis HUAWEI TECHNOLOGIES CO , LTD www huawei com HUAWEI Confidential Internal WCDMA Call Drop Problem Analysis HUAWEI TECHNOLOGIES CO , LTD Page 2HUAWEI Confidential For[.]

WCDMA Call Drop

Problem Analysis

Foreword: Causes of Call Drop in GSM & UMTS

Neighbor cell problem

No response after T3103 expiry

Interference problem

Interference problem

Coverage problem

Coverage problem

Handoff problem

Improper parameter setting

Definition of the call drop

Process for handling the call drop problem

Various methods to analyze call drop data

Solutions to call drop problems

Upon completion of this course, you will be able to understand:

1 Definition and classification

2 Causes and handling process

3 Solutions

4 Case analysis

5 Concerns in various network optimization phases

1.1 Normal release procedure

1.2 Call drop over the Um interface

1.3 Call drop measurement - CS

1.4 Call drop measurement - PS

Normal Release Procedure

Procedure of CS service normal release

CS Normal Release Procedure

1 The UE sends the RRC_UL_DIR_TRANSF message to the RNC If the nas message carried in this message is 0325, it indicates that the message is the disconnect message of the call control sublayer.

2 The RNC sends the RANAP_DIRECT_TRANSFER message to the CN If the nas pdu carried in this message is 0325, it indicates that the message is the disconnect message of the call control sublayer.

3 The CN sends the RANAP_DIRECT_TRANSFER message to the RNC If the nas pdu carried in this message is 832d, it indicates that the message is the release message of the call control sublayer.

4 The RNC sends the RRC_DL_DIRECT_TRANSF message to the UE If the nas message carried in this message is 832d, it indicates that the message is the release message of the call control sublayer.

5 The UE sends the RRC_UL_DIR_TRANSF message to the RNC If the nas message carried in this message is 032a, it indicates that the message is the release complete message of the call control

sublayer

6 The RNC sends the RANAP_DIRECT_TRANSFER message to the RNC If the nas pdu carried in this message is 032a, it indicates that the message is the release complete message of the call control

sublayer

Normal Release Procedure

7 The CN sends the RANAP_IU_RELEASE_COMMAND message to the RNC to release resources of the Iu interface, including resources of the RANAP layer and the ALCAP layer

8 The RNC sends the RANAP_IU_RELEASE_COMPLETE message to the CN

9 The RNC sends the RRC_RRC_CONN_REL message to the UE to release the RRC connection

10 The UE sends the RRC_RRC_CONN_REL_CMP message to the RNC

11 The RNC sends the NBAP_RL_DEL_REQ message to the NodeB to release resources

of the Iu interface, including resources of the NBAP layer and the ALCAP layer

12 The NodeB sends the NBAP_RL_DEL_RSP message to the RNC Then, the release procedure is complete

Procedure of PS service normal release

Normal Release Procedure

Procedure of PS service normal release

1 The UE sends the RRC_UL_DIR_TRANSF message to the RNC The nas message

carried in the message is 0a46, indicating that the message is the deactivate PDP context

request message of the session management sublayer

2 The RNC sends the RANAP_DIRECT_TRANSFER message to the CN The nas pdu carried in the message is 0a46, indicating that the message is the deactivate PDP context

request message of the session management sublayer

3 The CN sends the RANAP_DIRECT_TRANSFER message to the RNC The nas pdu carried in the message is 8a47, indicating that the message is the deactivate PDP context

accept message of the session management sublayer

4 The CN sends the RNC the RANAP_RAB_ASSIGNMENT_REQ message carrying the RAB list (to be released) with RAB IDs to be released

5 The RNC sends the RRC_DL_DIRECT_TRANSF message to the UE The nas message carried in the message is 8a47, indicating that the message is the deactivate PDP context

accept message of the session management sublayer

7 The NodeB sends the NBAP_RL_RECFG_READY message to the RNC.

8 The RNC sends the RRC_RB_REL message to the UE to release the radio bearer of the service.

9 The NodeB sends the NBAP_RL_RECFG_COMMIT message to the RNC.

10 The UE sends the RRC_RB_REL_CMP message to notify the RNC that the radio bearer of the service is released

11 The RNC sends the RANAP_RAB_ASSIGNMENT_RESP message to notify the CN that the radio access bearer is released.

1 Definition and Classification

1.1 Normal release procedure

1.2 Call drop over the Um interface

1.3 Call drop measurement - CS

1.4 Call drop measurement - PS

Definition of call drop over the Um interface

Call drop defined by field tests

According to the Um interface signaling recorded on the UE side, if messages of the

Um interface meet one of the following conditions during the conversation (in the connectionstate), you can infer that a call is dropped

(1) The RRC Release message is not received The UE changes from the CELL_DCH state to the IDLE state

(2) The RRC Release message is received in which the release cause value is not Normal

(3) The CC Disconnect message, CC Release Complete message, or CC Release

message is received in which the release cause value is not Normal Clearing, Normal Unspecified, user busy, user alerting no answer, call rejected or destination out of order.

Call Drop over the Um Interface

Call drop defined by traffic statistics

According to the signaling recorded by the RNC, if the RNC sends the Iu Release

1.1 Normal release procedure

1.2 Call drop over the Um interface

1.3 Call drop measurement - CS

1.4 Call drop measurement - PS

Summary of measurement classification

Call drop defined by the measurement

CS Service Drop Ratio

% 100 Re

Re

lease CSRAB

lease mal

CSRABAbnor CDR

VS.RAB.Loss.CS.RF: Number of Released RABs Triggered by RNC due to RF Reason

VS.RAB.Loss.CS.Abnorm: Numbers of abnormally released RABs except RF causes in a cell

VS.RAB.Loss.CS.Abnorm+

VS.RAB.Loss.CS.RF CSRABAbnormalRelease (cell)

This measurement helps evaluate the call drop rate of CS services in a RNC or cluster This counter is measured when the RNC initiates the abnormal release procedure through the RAB RELEASE

REQUEST and IU RELEASE REQUEST messages

Call Drop Measurement - CS

AMR Call Drop Ratio

% 100 Re

Re

lease AMRRAB

lease rmal

AMRRABAbno CDR

CS Normal Cause in a cell(AMR)

VS.RAB.Loss.CS.AMR + VS.RAB.Loss.CS.Norm.AMR AMRRABRelease

Number of released CS AMR service RABs triggered by RNC in a cell

VS.RAB.Loss.CS.AMR AMRRABAbnromalRelease (cell)

VP Call Drop Ratio

% 100 Re

Re

lease VPRAB

lease mal

VPRABAbnor CDR

Number of released CS 64 k service RABs triggered by RNC in a cell VS.RAB.Loss.CS.Conv64K

1 Definition and Classification

1.1 Normal release procedure

1.2 Call drop over the Um interface

1.3 Call drop measurement - CS

1.4 Call drop measurement - PS

PS Service Drop Ratio

% 100 Re

Re

lease PSRAB

lease mal

PSRABAbnor CDR

PSRABAbnormalRelease

(cell)

This measurement helps evaluate the call drop rate of PS services in a RNC or cluster This counter is measured when the RNC initiates the abnormal release procedure through the RAB RELEASE

REQUEST and IU RELEASE REQUEST messages

Note: The cell level counter calculates only the RAB releases on the SRNC, whereas the result of the above formula includes the R99 call drop and HSPA call drop

Call Drop Measurement - PS

HSDPA Service Drop Ratio

% 100 Re

_

Re _

lease RB

HSDPA

lease RBAbnormal

HSDPA CDR

VS.HSDPA.ChR.HSDSCHtoDCH: Number of successful channel handovers from the HS-DSCH to the DCH in the same cell

VS.HSDPA.RAB.Loss.InActivity: Number of released PS service RABs carried by HSDPA triggered The cause is User Inactivity.

VS.HSDPA.RAB.Loss.Norm: Number of released PS service RABs carried by HSDPA triggered The cause is normal.

VS.HSDPA.RAB.Loss.Norm + VS.HSDPA.RAB.Loss.InActivity +

VS.HSDPA.ChR.HSDSCHtoDCH +

VS.HSDPA.ChR.HSDSCHtoFAC

H + VS.HSDPA.HHO.H2D.SuccOutInt raFreq +

VS.HSDPA.HHO.H2D.SuccOutInt erFreq

VS.HSDPA.RAB.Loss.Abnorm.No nRF + VS.HSDPA.RAB.Loss.RF

HSDPA_RBAbnormalRele

ase

HSDPA Service Drop Ratio

Call Drop Measurement - PS

HSUPA Service Drop Ratio

% 100 Re

_

Re _

lease RB

HSUPA

lease RBAbnormal

HSUPA CDR

HSUPA Service Drop Ratio

VS.HSUPA.ChR.IntraFreq.EDCHtoDCH.Succ: Number of successful attempts to switch the channel type from EDCH to DCH due to intra- frequency hard handover between two cells.

VS.HSUPA.ChR.IntraCell.EDCHtoDCH.Succ: Number of successful attempts to switch the channel type from EDCH to DCH in the same cell

of the RNC

VS.HSUPA.RAB.Loss.Norm: Number of released

PS service RABs carried by HSUPA triggered The cause is normal.

VS.HSUPA.RAB.Loss.Norm + VS.HSUPA.ChR.IntraCell.EDCHtoDCH.Succ + VS.HSUPA.ChR.IntraFreq.EDCHtoDCH.Succ + VS.HSUPA.ChR.InterFreq.EDCHtoDCH.Succ + VS.HSUPA.ChR.EDCHtoFACH.Succ

HSUPA_RBNormalRelease

VS.HSUPA.RAB.Loss.Abnorm: Number of abnormal released PS service RABs carried by HSUPA triggered by RNC in a cell

VS.HSUPA.RAB.Loss.Abnorm HSUPA_RBAbnormalReleasego back

1 Definition and classification

2 Causes and handling process

3 Solutions

4 Case analysis

5 Concerns in various network optimization phases

2.1 Common reasons for call drop

2.2 Drive test data analysis procedure

2.3 Measurement data analysis procedure

2.4 Signaling tracing data analysis procedure

2.5 User complaint data analysis procedure

Common Reasons for Call Drop

Neighbor Cell Missing

Generally, the call drop is caused by neighbor cell missing during the early phase of

optimization For the intra-frequency neighbor cells, you can use the following methods to determine whether the call drop is caused by intra-frequency neighbor cell missing

Method 1: Check the EcIo information about cells in the active set recorded by the UE and the Best Server EcIo information recorded by the Scanner If the EcIo recorded by the UE

is poor and the Best Server EcIo recorded by the Scanner is good, check whether the Best Server scrambling code recorded by the Scanner is included in the intra-frequency

measurement control If the scrambling code is not included, you can infer that the call drop

is caused by the neighbor cell missing

Method 2: If the UE reconnects to the network immediately after the call drop and the cell scrambling code used during the reconnection of the UE is inconsistent with that used

during the call drop, the call drop may be caused by the neighbor cell missing You can confirm the cause through the measurement control The neighbor cell missing, including the inter-frequency neighbor cell missing and the inter-RAT neighbor cell missing can result

in call drop

Method 3: Adopt the Nastar neighbor cell analysis function to check whether the neighbor cell missing problem exists

Coverage Problem

Generally, poor coverage implies that both the RSCP and EcIo are poor You can confirm the coverage problem by checking the transmit power of

uplink/downlink special channels through the following methods:

If the uplink transmit power reaches the maximum value before the call drop and the uplink BLER is poor or the single user tracing recorded by the RNC suggests that Node B reports RL failure, you may infer that the call drop is caused by poor uplink coverage If the downlink transmit power reaches the maximum value before the call drop and the downlink BLER is poor, you may infer that the call drop is caused by poor downlink coverage

You can also confirm the coverage problem through the following simple and direct method:

Check the data collected by the Scanner If both the RSCP and EcNo of the best cell are poor, you can determine that the poor coverage results in the call drop.

Common Reasons for Call Drop

There are two reasons for the call drop caused by the soft handoff/inter-frequency, that is, it

is too late to perform the handoff or ping-pong handoff In terms of the signaling process, for the CS service, the UE does not receive the active set update command; for the PS service, the TRB is reset before the handoff of the UE

In terms of signal, there are two scenarios in which it is too late for the handoff:

(1) Corner: The EcIo of the source cell has a sudden sharp drop, and the EcNo of the target cell has an unexpected dramatic increase

(2) Pinpoint: The EcIo of the source cell increases after a period of time in rapid fall The EcIo of the target cell has a sudden increase in a short time period

The ping-pong handoff involves the following cases:

(1) The primary cell changes rapidly: Two or more cells take turns to be the primary cell The primary cell has better RSCP and EcIo and exists in a short period of time

(2) There are multiple secondary cells: The RSCP is normal, and there is slight difference between RSCPs of cells The EcIo in each cell is poor

Interference Problem

For the downlink, if the CPICH RSCP is greater than 85 dB and the EcIo is smaller than

-13 dB, the call drop tends to occur This may be caused by downlink interference

For the uplink, if the RTWP is 10 dB greater than the normal value (-104 to -105), there may be a call drop This is caused by pilot pollution

Common Reasons for Call Drop

If the preceding causes are excluded, the call drop may be caused by equipment problems You need to perform further cause analysis by checking logs and alarms of the equipment.For example:

The synchronization failure causes repeated addition or deletion of links

The UE does not report the la measurement report, which results in the call drop

Interaction Process Problem

Processes, such as AMR control, enabling or disabling the DCCC, compression mode, and

UE state transition may fail due to reasons relating to the signal, UE capability, or the interaction between the equipment in the RAN and UE, which finally results in call drop There is no common method to solve these problems The method varies depending on the specific process or UE

2.1 Common reasons for call drop

2.2 Drive test data analysis procedure

2.3 Measurement data analysis procedure

2.4 Signaling tracing data analysis procedure

2.5 User complaint data analysis procedure

Drive Test Data Analysis Procedure

Drive Test Data Analysis Procedure 1 Prepare data.

Compare the best cell of the UE and that of the Scanner

4.1 Both the RSCP and the EcIo are poor.

4.2 The RSCP is normal, and the EcIo

is poor.

4.3 Both the RSCP and the EcIo are normal.

Neighbor cell Untimely Uplink

Check whether the call drop is caused by the neighbor cell missing.

Coverage Abnormal call Pilot frequency

Inconsistent

Uplink interference or not Y

Are signals of the primary cell stable?

4 RSCP and EcIO of the best cell of the Scanner

Ping-pong

Frequently changed

Y

N

1 Prepare the following data:

Data files collected by the drive test software Single user tracing data recorded by the RNC CDL recorded by the RNC

2 Obtain the call drop location.

Adopt the drive test software, such as the Analyzer to obtain the call drop time and location, pilot frequency data collected by the Scanner before and after the call drop, information about the active set and monitored set collected by the UE, and signaling process.

3 Analyze changes of the primary cell of the Scanner.

If the primary cell is relatively stable, perform further analysis on the RSCP and EcIo

If the primary cell changes frequently, analyze causes If there is no primary cell, perform the cause analysis on the call drop occurring during the ping-pong handoff.

Drive Test Data Analysis Procedure

4 Analyze the RSCP and EcIo of the primary cell of the Scanner

Check the RSCP and EcNo of the best cell of the Scanner and take appropriate measures accordingly

4.1 If both the RSCP and EcNo are poor, the coverage problem leads to the call drop 4.2 If the RSCP is normal, and the EcNo is poor, the call drop is caused by the pilot frequency interference problem rather than untimely handoff and inter-frequency neighbor cell

4.3 If both the RSCP and the EcNo are normal and the cell of the active set of the UE are inconsistent with the best cell of the Scanner, the call drop may be caused by the neighbor cell missing or untimely handoff If the cell of the active set of the UE is consistent with the best cell of the Scanner, the uplink interference may result in calldrop or an abnormal call drop occurs

5 Carry out the drive test repeatedly

A drive test may not collect all the information required by call drop location Therefore, you need to carry out the drive test for several times to collect data and check whether the call drop location is random or fixed Generally, take related measures to eliminate call drops occurring on the fixed location and check whether to eliminate call drops occurring on random locations based on the occurrence probability

2.1 Common reasons for call Drop

2.2 Drive test data analysis procedure

2.3 Measurement data analysis procedure

2.4 Signaling tracing data analysis procedure

2.5 User complaint data analysis procedure

Measurement Data Analysis Procedure

Measurement Data Analysis Procedure

2 Analyze the call drop rate index of the

3.1 Solve the equipment problem.

4 Analyze call drop reasons.

4.1The signaling RB reset or service RB reset causes the call drop.

4.2 Check whether the call drop is caused by the handoff?

Solve the coverage problem.

Solve the call drop problem arising from

the handoff.

Y

1 Analyze call drop rate indexes of the RNC.

Check whether the call drop rate index is normal based on the overall call drop rate index of the RNC

2 Analyze call drop rate indexes of the cells such as AMR call drop rate, VP call drop rate,

PS call drop rate, hard handoff call drop rate, inter-RAT handoff call drop rate and sort all of these cells according to the indexes Analyze causes of call drops

occurring in the cells with worse or worst indexes

3 Check whether the cell is normal

Check alarms relating to cells and exclude causes of abnormal cells

Measurement Data Analysis Procedure

4 Analyze call drop causes

If the call drop is not caused by aa12 abnormality of the Iu interface or the GTPU abnormality, check whether the reset of signaling RLC or service RLC is the call drop cause Analyze related handoff indexes (incoming handoff success rate and outgoing handoff success rate) related to the cell to check whether the call drop is caused by the handoff failure Analyze the measurement relating to the overall bandwidth receiving power to check whether related uplink interference indexes are high during the period of the high call drop rate Then, you can determine whether the call drop is caused by uplink interference

5 Carry out the drive test to make call drop problems reoccur

If the call drop problem persists after the analysis of measurement data, carry out drive tests in the cell to trace the signaling process on the UE side and the RNC For detailed analysis method, see the drive test analysis procedure