Sie sind auf Seite 1von 83

Internal

WCDMA Call Drop Problem Analysis www.huawei.com
WCDMA Call Drop
Problem Analysis
www.huawei.com

HUAWEI TECHNOLOGIES CO., LTD.

HUAWEI Confidential

Internal WCDMA Call Drop Problem Analysis www.huawei.com HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential

Foreword: Causes of Call Drop in GSM & UMTS

GSM

Neighbor cell problem
Neighbor cell
problem
Interference problem
Interference
problem
Coverage problem
Coverage
problem

Handoff

problem

problem

Interactive

process

UMTS

No response after T3103 expiry
No response
after T3103
expiry
Interference problem
Interference
problem
Coverage problem
Coverage
problem
Improper parameter setting
Improper
parameter
setting

Equipment

problem

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 2
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 2

Objectives

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

Definition of the call drop Process for handling the call drop problem Various methods to
Definition of the call drop
Process for handling the call drop problem
Various methods to analyze call drop data
Solutions to call drop problems
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 3

Contents

Contents 1. Definition and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5.

1. Definition and classification

Contents 1. Definition and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5.
2. Causes and handling process

2. Causes and handling process

3. Solutions

3. Solutions

4. Case analysis

4. Case analysis

5. Concerns in various network optimization phases

5. Concerns in various network optimization phases

Training.huawei.com
Training.huawei.com

1 Definition and Classification

1.11.1 NormalNormal releaserelease procedureprocedure 1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.11.1 NormalNormal releaserelease procedureprocedure
1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.31.3 CallCall dropdrop measurementmeasurement -- CSCS
1.41.4 CallCall dropdrop measurementmeasurement -- PSPS

Normal Release Procedure

Procedure of CS service normal release

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 6
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 6

Normal Release Procedure

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.

Normal Release Procedure

Procedure of PS service normal release

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 9
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 9

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.

6. The RNC sends the NBAP_RL_RECFG_PREP message to the NodeB.

Normal Release Procedure

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.11.1 NormalNormal releaserelease procedureprocedure 1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.11.1 NormalNormal releaserelease procedureprocedure
1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.31.3 CallCall dropdrop measurementmeasurement -- CSCS
1.41.4 CallCall dropdrop measurementmeasurement -- PSPS

Call Drop over the Um Interface

Definition of call drop over the Um interface

the Um Interface Definition of call drop over the Um interface HUAWEI TECHNOLOGIES CO., LTD. HUAWEI

CallCall DropDrop overover thethe UmUm InterfaceInterface

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 connection state), 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 defined by traffic statistics

According to the signaling recorded by the RNC, if the RNC sends the Iu Release Request or the RAB Release Request to the CN over the Iu interface, you can infer that a call is dropped (excluding certain special causes).

1 Definition and Classification

1.11.1 NormalNormal releaserelease procedureprocedure 1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.11.1 NormalNormal releaserelease procedureprocedure
1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.31.3 CallCall dropdrop measurementmeasurement -- CSCS
1.41.4 CallCall dropdrop measurementmeasurement -- PSPS

DefinitionDefinition ofof MeasurementMeasurement

Summary of measurement classification Call drop defined by the measurement CS call drop Object-oriented statistics: RNC, cell Service-oriented statistics: AMR, VP service

PS call drop Object-oriented statistics: RNC, cell Service-oriented statistics: PS service, HSDPA, HSUPA

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 16
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 16

Call Drop Measurement - CS

CS Service Drop Ratio

KPI Name

CS Service Drop Ratio

 

Measurement

Cell

Scope

Formula

CS

CDR

=

CSRABAbnormal

Re

lease

100%

_

CSRAB

Re

lease

 

Notes

The RNC level KPIs can be calculated by aggregating all the cell counters and Iur counters.

CSRABAbnormalRelease (cell)

VS.RAB.Loss.CS.Abnorm+

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

VS.RAB.Loss.CS.RF

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

CSRABRelease (cell)

VS.RAB.Loss.CS.RF + VS.RAB.Loss.CS.Abnorm + VS.RAB.Loss.CS.Norm

VS.RAB.Loss.CS.Norm: Numbers of Released RABs Triggered by RNC due to CS Normal Cause in a 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

KPI Name

AMR Call Drop Ratio

 

Measurement

Cell

Scope

Formula

AMR

CDR

=

AMRRABAbno rmal

Re

lease

100%

_

AMRRAB

Re

lease

 

Notes

The RNC level KPIs can be calculated by aggregating all the cell counters and Iur counters.

AMRRABAbnromalRelease (cell)

VS.RAB.Loss.CS.AMR

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

AMRRABRelease

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

VS.RAB.Loss.CS.Norm.AMR: Numbers of Released RABs Triggered by RNC due to CS Normal Cause in a cell(AMR)

This measurement helps evaluate the call drop rate of AMR 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

VP Call Drop Ratio

KPI Name

VP Call Drop Ratio

 

Measurement

Cell

Scope

Formula

VP

CDR

=

VPRABAbnormal

Re

lease

100%

_

VPRAB

Re

lease

 

Notes

The RNC level KPIs can be calculated by aggregating all the cell counters and Iur counters.

VPRABAbnormalRelease

VS.RAB.Loss.CS.Conv64K

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

(cell)

VPRABRelease (cell)

VS.Norm.Rel.CS.Conv.RB.64 +

Numbers of VP Service RABs released

VS.RAB.Loss.CS.Conv64K

This measurement helps evaluate the call drop rate of VP 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.

1 Definition and Classification

1.11.1 NormalNormal releaserelease procedureprocedure 1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.11.1 NormalNormal releaserelease procedureprocedure
1.21.2 CallCall dropdrop overover thethe UmUm interfaceinterface
1.31.3 CallCall dropdrop measurementmeasurement -- CSCS
1.41.4 CallCall dropdrop measurementmeasurement -- PSPS

Call Drop Measurement - PS

PS Service Drop Ratio

KPI Name

PS Service Drop Ratio

 

Measurement

Cell

Scope

Formula

PS

CDR

=

PSRABAbnormal

Re

lease

100%

_

PSRAB

Re

lease

 

Notes

The RNC level KPIs can be calculated by aggregating all the cell counters and Iur counters.

PSRABAbnormalRelease

VS.RAB.Loss.PS.RF + VS.RAB.Loss.PS.Abnorm

VS.RAB.Loss.PS.RF:

(cell)

Numbers of abnormally released RABs except RF causes in a cell

 

VS.RAB.Loss.PS.Abnorm: Number of released RABs triggered by RNC due to RF reason

PSRABRelease (cell)

VS.RAB.Loss.PS.RF + VS.RAB.Loss.PS.Abnorm + VS.RAB.Loss.PS.Norm

VS.RAB.Loss.PS.Norm: Numbers of released RABs triggered by RNC due to PS normal causes in a 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

KPI Name

HSDPA Service Drop Ratio

 

Measurement

Cell

 

Scope

 

Formula

 

HSDPA

RBAbnormal

Re

lease

HSDPA

CDR

_

=

_

100%

   

HSDPA

 

RB

Re

lease

 
 

_

Notes

1.

The RNC level KPIs can be calculated by aggregating all the cell

counters.

 

2.

The normal transition from HS-DSCH to FACH/DCH is considered as

normal HS-DSCH release ( including transitions due to mobility).

 

This measurement helps evaluate the call drop rate of PS services carried by the HSDPA 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 - PS

HSDPA Service Drop Ratio

HSDPA_RBAbnormalRele

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

VS.HSDPA.RAB.Loss.Abnorm.NonRF: Number of released PS service RABs carried by HSDPA triggered by RNC in a cell. The cause is not RF.

ase

 

VS.HSDPA.RAB.Loss.RF:

Number of released PS service RABs carried by HSDPA triggered by RNC in a cell. The cause is RF.

HSDPA_RBNormalRelease

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

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

+

VS.HSDPA.ChR.HSDSCHtoDCH

 

+

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

VS.HSDPA.ChR.HSDSCHtoFAC H +

VS.HSDPA.HHO.H2D.SuccOutInt

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

raFreq +

VS.HSDPA.HHO.H2D.SuccOutInt

erFreq

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

VS.HSDPA.HHO.H2D.SuccOutIntraFreq:

Number of successful intra-frequency hard handovers from the HS-DSCH to the DCH between two cells

VS.HSDPA.HHO.H2D.SuccOutInterFreq:

Number of successful inter-frequency hard handovers from the HS-DSCH to the DCH between two cells

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 23
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 23

Call Drop Measurement - PS

HSUPA Service Drop Ratio

KPI Name

HSUPA Service Drop Ratio

 

Measurement

Cell

 

Scope

 

Formula

 

HSUPA

RBAbnormal

Re

lease

HSUPA

CDR

_

=

_

100%

   

HSUPA

 

RB

Re

lease

 
 

_

Notes

1.

The RNC level KPIs can be calculated by aggregating all the cell

counters.

 

2.

The normal transition from E-DCH to FACH/DCH is considered as

normal E-DCH release ( including transitions due to mobility).

 

This measurement helps evaluate the call drop rate of PS services carried by the HSUPA 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 - PS

HSUPA Service Drop Ratio

HSUPA_RBAbnormalReleasego back

VS.HSUPA.RAB.Loss.Abnorm

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

HSUPA_RBNormalRelease

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

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

VS.HSUPA.ChR.IntraCell.EDCHtoDCH.Succ:

VS.HSUPA.ChR.InterFreq.EDCHtoDCH.Succ + VS.HSUPA.ChR.EDCHtoFACH.Succ

Number of successful attempts to switch the channel type from EDCH to DCH in the same cell of the RNC

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.InterFreq.EDCHtoDCH.Succ:

Number of successful attempts to switch the channel type from EDCH to DCH due to inter- frequency hard handover between two cells.

VS.HSUPA.ChR.EDCHtoFACH.Succ:

Number of successful attempts to switch the channel type from EDCH to FACH in the same cell of the RNC

Contents

Contents 1. Definition and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5.

1. Definition and classification

Contents 1. Definition and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5.
Contents 1. Definition and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5.

2. Causes and handling process

3. Solutions

3. Solutions

4. Case analysis

4. Case analysis

5. Concerns in various network optimization phases

5. Concerns in various network optimization phases

Training.huawei.com
Training.huawei.com

2 Causes and Handling Process

2.1 2.1 Common Common reasons reasons for for call call drop drop

2.12.1 CommonCommon reasonsreasons forfor callcall dropdrop

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. Method 4: Enable the measurement analysis detection set (RNC detection set) to report 1A event.

Common Reasons for Call Drop

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

Handoff Problem

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.

Common Reasons for Call Drop

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

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.

Other Abnormal Problems

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.

2 Causes and Handling Process

2.1 Common reasons for call drop

2.1 Common reasons for call drop

2.22.2 DriveDrive testtest datadata analysisanalysis procedureprocedure

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.

2. Obtain call drop location and time 3. Analyze signal changes of the primary cell

2. Obtain call drop location and time

2. Obtain call drop location and time 3. Analyze signal changes of the primary cell of

3. Analyze signal changes of the primary cell of the Scanner

Are signals of the Frequently changed primary cell stable? stable 4 RSCP and EcIO of
Are signals of the
Frequently changed
primary cell stable?
stable
4 RSCP and EcIO of the best
cell of the Scanner
4.1 Both the RSCP
and the EcIo are
poor.
4.3 Both the RSCP
and the EcIo are
normal.
4.2 The RSCP is
normal, and the EcIo
is poor.
Inconsistent
Compare the best
cell of the UE and
that of the Scanner
Consistent
Check whether
the call drop is
caused by the
neighbor cell
N
Uplink
interference or
N
not
Y missing.
Y
Coverage
Neighbor cell
Untimely
Uplink
Abnormal call
Pilot frequency
Ping-pong
problem
missing
handoff
interference
drop
interference
handoff problem
problem
problem
4. Perform the drive
test again.
Is the problem
solved?
HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 34
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 34

DriveDrive TestTest DataData AnalysisAnalysis ProcedureProcedure

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.

DriveDrive TestTest DataData AnalysisAnalysis ProcedureProcedure

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 call drop 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 Causes and Handling Process

2.1 Common reasons for call Drop

2.1 Common reasons for call Drop

2.2 Drive test data analysis procedure

2.32.3 MeasurementMeasurement datadata analysisanalysis procedureprocedure

2.4 Signaling tracing data analysis procedure

2.5 User complaint data analysis procedure

Measurement Data Analysis Procedure

Measurement Data Analysis Procedure

1. Analyze the call drop rate of the RNC.

Analysis Procedure 1. Analyze the call drop rate of the RNC. 2. Analyze the call drop

2. Analyze the call drop rate index of the cell.

Y 3. Check whether the equipment in the cell is normal. N 4. Analyze call
Y
3. Check whether the
equipment in the cell is
normal.
N
4. Analyze call drop reasons.
Y
4.1The signaling RB reset or
service RB reset causes the
call drop.
N
Y
4.2 Check whether the call
drop is caused by the
handoff?
N
Y
4.3 Check whether the call
drop is caused by the
interference?
N

3.1 Solve the equipment problem.

by the interference? N 3.1 Solve the equipment problem. Solve the coverage problem. Solve the call

Solve the coverage problem.

Solve the call drop problem arising from the handoff.

Solve the interference problem.

5. Carry out the drive test to find out the call drop reasons.

5. Carry out the drive test to find out the call drop reasons. HUAWEI TECHNOLOGIES CO.,
HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 38
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 38

MeasurementMeasurement DataData AnalysisAnalysis ProcedureProcedure

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.

MeasurementMeasurement DataData AnalysisAnalysis ProcedureProcedure

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.

2 Causes and Handling Process

2.1 Common reasons for call drop

2.1 Common reasons for call drop

2.2 Drive test data analysis procedure

2.3 Measurement data analysis procedure

2.42.4 SignalingSignaling tracingtracing datadata analysisanalysis procedureprocedure

2.5 User complaint data analysis procedure

Signaling Tracing Data Analysis Procedure

Signaling tracing data analysis procedure

1. Obtain the single user tracing message 2. Obtain information about the call drop location.
1. Obtain the single user tracing
message
2.
Obtain information about the call
drop location.
3. Check whether the call
drop occurs on the
signaling plane.
3.1 Solve call drop problems arising
on the signaling plane.
4 . Check whether the call
drop occurs on the user
plane.
4.1 Solve call drop problems arising
on the user plane.
Y
5. Check whether
5.1 Solve abnormal call drop
problems.
abnormal call drop occurs.
N
Check whether call drop
problems are solved.
6. Carry out drive tests to make call
drop problems reoccur
HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 42
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 42

SignalingSignaling TracingTracing DataData AnalysisAnalysis ProcedureProcedure

1. Obtain single user tracing messages.

Trace the single user on the RNC or M2000 before recording related single user tracing messages. Generally, the messages recorded during the IMSI-based tracing is sufficient for the analysis of the call drop problems.

2. Obtain information about the call drop location.

Single user tracing messages suggest that the cause of a call drop on the user plane is that the RNC actively sends the RANAP_RAB_RELEASE_REQ message to release the RAB and the cause of a call drop on the signaling plane is that the RNC actively sends the RANAP_IU_RELEASE_REQ message to release the Iu interface. By checking the two messages, you can obtain the call drop time and signaling messages before the call drop and perform further analysis.

SignalingSignaling TracingTracing DataData AnalysisAnalysis ProcedureProcedure

3. Analyze the call drop on the signaling plane.

If a call drop occurs on the signaling plane, the UE or the RNC cannot receive the confirmation message, which leads to the SRB reset and connection release. The SRN reset can be caused by uplink messages such as the measurement control message, active set update message, physical channel reconfiguration message, transmission channel reconfiguration message, RB reconfiguration message, and command for the handoff from 3G networks to 2G networks. You need to check messages traced on the UE side to determine whether the UE receives these commands. The SRN reset can also be caused by downlink messages such as the measure report, active set update completion message, physical channel reconfiguration completion message, transmission channel reconfiguration completion message, and RB reconfiguration completion message. You need to check messages traced on the RNC side to determine whether these tracing messages are received.

SignalingSignaling TracingTracing DataData AnalysisAnalysis ProcedureProcedure

4. Analyze the call drop on the user plane.

If the call drop occurs on the user plane, the TRB resets. The TRB resetting occurs during a PS call rather than a Voice or VP call.

If there is only one link in the active set, the RL failure may cause the RNC to initiate the Iu release procedure. The lost synchronization of the uplink causes the RL failure. The lost synchronization of the downlink causes the UE to shut down the transmitter, which results in lost synchronization of the uplink. To check whether the lost synchronization of the uplink or lost synchronization of the downlink causes the release process, you need to analyze the transmit power of the UE and the monitored code transmit power of the downlink before the call drop. Poor downlink coverage, strong downlink interference, or uplink interference may lead to TRB reset. If the number of retransmission times of data services is set improperly, the TRB reset occurs before the SRB reset when it is too late for handoff. You must take this case into account.

SignalingSignaling TracingTracing DataData AnalysisAnalysis ProcedureProcedure

5. Analyze abnormal call drops.

The abnormal call drop is caused by abnormalities occurs on the equipment or the UE (for example, the transmission is interrupted, the base station equipment is abnormal, and the UE crashes abruptly) rather than the coverage problem, interference problem, or causes of the call drop occurs on the user plane or the signaling plane. If the call drop is caused by the abrupt transmission interruption, you can analyze the CDL or alarms to locate the cause of the call drop; if the call drop is caused by the abnormalities of the base station equipment, you can check the status of the base station; if the call drop is caused by abnormalities of the UE, you can analyze the data recorded by the UE.

6. Carry out drive tests to make the call drop problem reoccur.

If the existing data is not sufficient to locate the call drop problem, trace more detailed data. The best way is to carry out drive tests on the call drop location and perform further analysis.

2 Causes and Handling Process

2.1 Common reasons for call drop

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.52.5 UserUser complaintcomplaint datadata analysisanalysis procedureprocedure

UserUser ComplaintComplaint DataData AnalysisAnalysis ProcedureProcedure

1. Understand user complaint.

When a user complaint is received, record when and where the problem occurs and describe the problem in detail.

2. Check the measurement.

Analyze the related measurement to determine whether the complaint is a specific problem of the user or a general network problem. For a general network problem, perform further analysis on the complaint by referring to the analysis on the measurement.

3. Check alarms.

According to the complaint time, check the CN, RNC or check whether the alarm of the base station on the location where the problem occurs can result in call drop. If

such alarm exists, clear the alarm.

4. Check the CDL.

The CDL records the signaling used by the user or the user status when the abnormality occurs. By analyzing the CDL, you can learn about the details about the complaints.

UserUser ComplaintComplaint DataData AnalysisAnalysis ProcedureProcedure

5. Perform the dialing test on the complained location to make the problem reoccur. If the problem persists after you analyze the related measurement, alarm, and CDL, perform the dialing test to solve the problem. Record the data generated during the dialing test by using the same method for recording the data generated in the drive test. If it is inconvenient to record the information on the UE side in certain scenarios, use the RNC to record various information, in particular, record and collect the reported information about the EcIo and RSCP to solve the call drop problem caused by the poor coverage. In the case of special locations where it is impossible to perform the dialing test, obtain the IMSI according to the mobile phone number and trace the call on the RNC to locate causes of the call drop.

Contents

Definition and classification1.

1.

Causes and handling process2.

2.

classification 1. Causes and handling process 2. 3. Solutions 4. Case analysis 5. Concerns in various
classification 1. Causes and handling process 2. 3. Solutions 4. Case analysis 5. Concerns in various

3. Solutions

1. Causes and handling process 2. 3. Solutions 4. Case analysis 5. Concerns in various network

4. Case analysis

and handling process 2. 3. Solutions 4. Case analysis 5. Concerns in various network optimization phases

5. Concerns in various network optimization phases

Training.huawei.com
Training.huawei.com

3 Solutions

3.13.1 EngineeringEngineering parameterparameter adjustmentadjustment 3.2 Cell parameter adjustment
3.13.1 EngineeringEngineering parameterparameter
adjustmentadjustment
3.2 Cell parameter adjustment

Engineering Parameter Adjustment

The engineering parameter adjustments are limited. Basically, you can adjust the height, down tilt, lobe width, gain, and deflection angle of the antenna.

1. For the call drop caused by the uplink or downlink coverage problem

Adjust the height and the down tilt of the antenna or replace with the antenna providing more gain or increase the TMA.

2. For the pinpoint or corner effect

An effective way is to adjust the antenna. The pinpoint or corner effect occurs on the corner of the street or the junction of the two streets. In this case, you can make a certain angel between the antenna and the street by adjusting the deflection angle. Note that this action should not greatly affect the signal coverage of nearby shops on the street.

Adjustment of Engineering Parameters

3. For the coverage problem caused by the pilot frequency You can adjust engineering parameters of a certain antenna to make the interfered location a primary cell. You can also adjust engineering parameters of other antennas to weaken signals of these cells to decrease the number of pilot frequencies. If permitted, use two base stations to cover the area. If the interference is from two sectors of a base station, incorporate the two sectors. You must consider the adjustment effect of the entire cell when adjusting engineering parameters. Ensure that the measures taken to solve the problem does not bring about new problems in other areas.

3 Solutions

3.1 Engineering parameter adjustment 3.23.2 CellCell parameterparameter adjustmentadjustment
3.1 Engineering parameter
adjustment
3.23.2 CellCell parameterparameter adjustmentadjustment

Cell Parameter Adjustment

1. Cell individual offset (CIO)

The sum of the CIO and the actual measured value is used to determine whether the intra-frequency handoff is to be performed in the event evaluation process of the UE. In addition, the sum can serve as the mobile cell boundary. If the value is larger, the soft handoff is easier and more UEs are in the soft handoff state. In this case, the forward resources are occupied. If the value is smaller, the soft handoff is more difficult and the quality of received signals may be affected. For the pinpoint or corner effect, the better method is to configure the CIO as about 5 dB.

2. Time to trigger the delay related to the soft handoff

The delay triggering time refers to the time to trigger 1A, 1B, 1C, or 1D event. The triggering time may affect the promptness of the handoff. Generally, the default triggering time can meet requirements of most scenarios. Set handoff-related parameters according to the environment and adjust the configuration of related parameter for each cell. You can limit the impact of the parameter modifications to certain cells, which reduces the impact on the system.

Cell Parameter Adjustment

3. FilterCoef

The layer 3 filter tries to filter out the random impingement samples to enable the filtered measured values to reflect the main change trend of actual measured values. The measured values input in the layer 3 filter are filtered by the layer 1 filter. Therefore, the impacts of fast fading are removed, and the layer 3 filter performs the smooth filtering on shadow fading and few fast fading burrs to provide higher quality measurement data. The filter with greater filtering coefficient has stronger ability to smooth burrs but

weaker ability to trace signals.

Typical values are set as follows:

a. If signals in the handoff area change slowly, the intra-frequency filtering coefficient is set to 7.

b. If signals in the handoff area change at a moderate speed, the intra-frequency filtering coefficient is set to 6.

c. If signals in the handoff area change rapidly, the intra-frequency filtering coefficient is

set to 3.

Cell Parameter Adjustment

4. Threshold for enabling or disabling the compression mode

The compression mode is enabled before the inter-frequency or inter-RBT handoff. You can use the compression mode to check the quality of inter-frequency or inter- RBT cells. The compression mode is enabled only when the RSCP or EcIo of the CPICH meet requirements. In actual applications, the common triggering condition is that the RSCP must meet requirements. Generally, the compression mode requires to measure the quality of the target cell (inter-frequency or inter-RAT cell) to obtain related information. Movements of the UE deteriorate the quality of the current cell. Therefore, the requirement for setting the threshold for enabling the compression mode is to measure that the target cell completes the handoff before the quality deterioration of the current cell leads to the call drop; the requirement for setting the threshold for disabling the compression mode is to avoid the compression mode being enabled or disabled frequently.

Cell Parameter Adjustment

5. RLMaxDLPwr (Maximum Downlink Transmit Power of Radio Links)

The high transmit power of special links is favorable for solving call drop problems caused by the poor coverage but causing the interference problem. In this case, the single user consumes high power at the edge of the cell, which impacts on other users and reduces the downlink capacity of the system. Generally, the downlink transmit power is determined by the link budget with a variation of 1-2dB. If the drive test is carried out for once, it is difficult to measure the impact of the high power on the call drop. The measurement, however, reveals the impacts. If the poor coverage causes a higher call drop rate in certain cells, you can raise the maximum transmit power of special links. If the overload results in a higher access failure rate, you can consider to reduce the maximum transmit power.

Cell Parameter Adjustment

6. Number of signaling/service retransmission times

If the number of retransmission times of the signaling over links with higher block error rate reaches the maximum value, the signaling is reset, which causes the call drop. If the number of retransmission times of the service transmitted in AM mode reaches the maximum value, the signaling is reset. If the number of the reset times reaches the configured maximum value, the system releases the service, which causes the call drop. The default configuration only ensures that the unexpected error blocks do not cause a call drop. In certain scenarios with poorer coverage, however, the signaling reset results in the call drop and causes the resources occupied by the service to be released. In certain scenarios with more burst interference or remarkable pinpoint effect, the block error rate may reach 100%. If the call drop rate is required to be not too high in such scenarios, you can appropriately increase the number of retransmission times to weaken the impact of the burst interference. This parameter is configured on the RNC.

Cell Parameter Adjustment

7. RSCP (Inter-RAT Hard Handoff Threshold)

After the inter-frequency measurement is started, the UE starts measuring the inter- frequency cells. If the signal quality of the inter-frequency cells is higher than the threshold, the RNC initiates the inter-frequency handoff. You can configure the parameter based on the threshold for enabling or disabling the compression mode. If the parameter value is smaller, the handoff is triggered earlier. If the parameter value is greater, the triggering of the hard handoff is delayed. In this way, you can control the handoff area or reduce the call drop rate.

8. GsmRSSICSThd and GsmRSSIPSThd

GsmRSSICSThd and GsmRSSIPSThd specify the inter-system handoff thresholds of the CS service and the PS service respectively. The method for setting the two parameters is the same as that for setting the inter-frequency hard handoff threshold.

Contents

Definition and classification1.

1.

Causes and handling process2.

2.

Solutions3.

3.

4. Case analysis

process 2. Solutions 3. 4. Case analysis 5. Concerns in various network optimization phases
process 2. Solutions 3. 4. Case analysis 5. Concerns in various network optimization phases
process 2. Solutions 3. 4. Case analysis 5. Concerns in various network optimization phases

5. Concerns in various network optimization phases

Training.huawei.com
Training.huawei.com

4 Case analysis

4.14.1 CasesCases ofof callcall dropdrop causedcaused byby poorpoor coveragecoverage 4.2 Cases of call drop caused
4.14.1 CasesCases ofof callcall dropdrop causedcaused byby
poorpoor coveragecoverage
4.2 Cases of call drop caused by
interference
4.3 Cases of call drop caused by
handoff
4.4 Cases of call drop caused by
other reasons

Cases of Call Drop Caused by Poor Coverage

To analyze cases of the call drop caused by poor coverage, you must take the following issues into account:

Pilot frequency coverage and service coverage

Uplink coverage and downlink coverage

Measurement results recorded by the Scanner and UE

EcIo, RSCP, and SC of the CPICH

Call drop location
Call drop
location

Cases of Call Drop Caused by Poor Coverage

Cases of Call Drop Caused by Poor Coverage The call drop occurs on the SC314 cell,

The call drop occurs on the SC314 cell, the coverage edge of the 3G network. Before the call drop, the UE measurement suggests that the No.314 cell is only included in the active set rather than the monitored set; the RSSI is low; the SIR is negative; the transmit power of the UE reaches the maximum.

Cases of Call Drop Caused by Poor Coverage

Cases of Call Drop Caused by Poor Coverage The Ec/Io measured by the UE and that

The Ec/Io measured by the UE and that measured by the scanner shows the same degradation trend. The RSCP measured by the UE and that measured by the scanner shows the same degradation trend.

4 Case analysis

4.1 Cases of call drop caused by poor coverage 4.24.2 CasesCases ofof callcall dropdrop causedcaused
4.1 Cases of call drop caused by
poor coverage
4.24.2 CasesCases ofof callcall dropdrop causedcaused byby
interferenceinterference
4.3 Cases of call drop caused by
handoff
4.4 Cases of call drop caused by
other reasons

CasesCases ofof CallCall DropDrop CausedCaused byby InterferenceInterference

Cases of call drop caused by interference

The interference is subdivided into uplink interference and downlink interference.

Materials are not available.

4 Case analysis

4.1 Cases of call drop caused by poor coverage 4.2 Cases of call drop caused
4.1 Cases of call drop caused by
poor coverage
4.2 Cases of call drop caused by
interference
4.34.3 CasesCases ofof callcall dropdrop causedcaused byby
handoffhandoff
4.4 Cases of call drop caused by
other reasons

CasesCases ofof CallCall DropDrop CausedCaused byby HandoffHandoff

Call Call Drop Drop Caused Caused by by Handoff Handoff As shown in this figure, the

As shown in this figure, the call drop does not occur at the edge of the 3G network coverage area.

CasesCases ofof CallCall DropDrop CausedCaused byby HandoffHandoff

Call Call Drop Drop Caused Caused by by Handoff Handoff The call drop occurs in the

The call drop occurs in the area where the best cell changes rapidly.

CasesCases ofof CallCall DropDrop CausedCaused byby HandoffHandoff

Call Call Drop Drop Caused Caused by by Handoff Handoff Before the call drop, the Ec/Io

Before the call drop, the Ec/Io measured by the UE is decreased to lower than -21 dB, whereas the Ec/Io measured by the scanner is still above -11 dB.

CasesCases ofof CallCall DropDrop CausedCaused byby HandoffHandoff

Call Call Drop Drop Caused Caused by by Handoff Handoff Before the call drop, the best

Before the call drop, the best cell measured by the UE is the SC009 cell, whereas the best cell measured by the scanner is the SC018 cell. After the call drop, the UE camps on the SC018 cell rapidly.

CasesCases ofof CallCall DropDrop CausedCaused byby HandoffHandoff

Call Call Drop Drop Caused Caused by by Handoff Handoff Before the call drop, the SC018

Before the call drop, the SC018 cell is not measured in the monitored set of the UE. The neighbor relation is found to be defined in the neighbor list. Therefore, the possible call drop cause is that the best cell changes rapidly from the SC009 cell to the SC011 cell and SC018 cell, and thus the UE fails to perform the soft handoff timely.

CasesCases ofof CallCall DropDrop CausedCaused byby HandoffHandoff

Call Call Drop Drop Caused Caused by by Handoff Handoff The SC018 cell is not the

The SC018 cell is not the best cell here. Serious cross coverage exists in the SC018 cell. Upon the call drop, the RSCP is over -75 dBm. Therefore, you must increase the down tilt of the SC018 cell, control the coverage, and optimize the primary cell of the call drop location.

4 Case analysis

4.1 Cases of call drop caused by poor coverage 4.2 Cases of call drop caused
4.1 Cases of call drop caused by
poor coverage
4.2 Cases of call drop caused by
interference
4.3 Cases of call drop caused by
handoff
4.44.4 CasesCases ofof callcall dropdrop causedcaused byby
otherother reasonsreasons

CasesCases ofof CallCall DropDrop CausedCaused byby OtherOther ReasonsReasons

The material is not available.

Contents

1. Definition and classification

1. Definition and classification

2. Causes and handling process

2. Causes and handling process

and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5. Concerns in various
and classification 2. Causes and handling process 3. Solutions 4. Case analysis 5. Concerns in various

3. Solutions

2. Causes and handling process 3. Solutions 4. Case analysis 5. Concerns in various network optimization

4. Case analysis

2. Causes and handling process 3. Solutions 4. Case analysis 5. Concerns in various network optimization

5. Concerns in various network optimization phases

Training.huawei.com
Training.huawei.com

5 Concerns in Various Network Optimization Phases

5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s

5.15.1 ConcernsConcerns inin variousvarious networknetwork optimizationoptimization phasephasess

5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s s
5.1 5.1 Concerns Concerns in in various various network network optimization optimization phase phase s s

Concerns in Various Network Optimization Phases

Network optimization procedure

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 79
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 79

ConcernsConcerns inin VariousVarious NetworkNetwork OptimizationOptimization PhasesPhases

The entire network optimization process consists of the following phases:

Sign the project contract

Optimize the network

Generate the network optimization report

Here, we focus on the causes of the call drop in phases from the single site test phase to the subsequent acceptance phase.

1. Single site test phase

In the single site test phase, analyze the equipment problem to locate the abnormal call drop cause. If the call drop occurs during the drive test, check whether the call drop is caused by the poor coverage.

Concerns in Each Phase

2. RF optimization phase

Evaluation before the optimization

During the evaluation phase, check the drive test results for call drop rate indexes and learn about the call drop rate of the entire network according to the measurement analysis. In this phase, emphasize on and differentiate call drops caused by poor coverage, interference, or untimely handoff. In addition, the call drops caused by the untimely handoff should be taken into account.

RF optimization

The emphasis of this phase is to check whether call drops are caused by the poor coverage or strong interference. Check whether such call drop problems can be solved by adjusting engineering parameters of the antenna. In addition, call drops caused by the untimely handoff should be taken into account. Check whether the corner or pinpoint effect can be avoided by adjustment of the antenna.

Concerns in Each Phase

3. Parameter optimization phase

If certain call drops cannot be avoided by RF optimization or the RF optimization cannot be performed in some scenarios, optimize parameters to solve these problems after the RF optimization. In this phase, lay special stress on call drops caused by the handoff, inter-frequency handoff, and inter-RAT handoff. Generally, call drops due to latter causes occur in indoor area or subway. In this case, carry out the walking dialing test accordingly and trace messages of the single user on the RNC for data analysis.

4. Acceptance phase

To evaluate the optimization effect, collect drive test indexes and measurements related to the call drop rate during the optimization and acceptance phases. Not all these call drop problems are required to be solved, but you are advised to analyze the detailed causes of each call drop and put forward further suggestions on the future optimization.

Thanks!

WWW.HUAWEI.COM

HUAWEI TECHNOLOGIES CO., LTD. HUAWEI Confidential Page 83
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 83