01-06 Troubleshooting For Handover

M900/M1800 Base Station Subsystem
Troubleshooting Manual Contents
Contents
6 Troubleshooting for Handover ...............................................................................................6-1

6.1 Overview.......................................................................................................................................................6-2
6.1.1 Failure Classification ...........................................................................................................................6-2
6.1.2 Tool for locating the faults ...................................................................................................................6-2
6.2 Trouble Handling ..........................................................................................................................................6-3
6.2.1 Locating Procedure ..............................................................................................................................6-3
6.2.2 Locating Procedure of No Handover Starting Up ................................................................................6-4
6.2.3 Locating of Hardware Failure ..............................................................................................................6-5
6.2.4 Locating of Data Configuration Problem.............................................................................................6-5
6.3 MSC Handover Problem ...............................................................................................................................6-6
6.3.1 Charging Data Modification of Supplier A Leads the Success Rate for the Incoming MSC Handover of
Dual Band Network to 0%............................................................................................................................6-6
6.3.2 MSC Data Configuration Error Leads to the Handover Failure...........................................................6-6
6.3.3 Improper BSC Parameter Setting of Company Causes Low Handover Success Rate to Huawei MSC
......................................................................................................................................................................6-7
6.3.4 Signaling Matching Problem Leads to Handover Failure ....................................................................6-9
6.3.5 Equipment Matching Problem Between Different Supplier Leads to Low Outgoing BSC Handover
Success Rate ............................................................................................................................................... 6-11
6.4 BSC Problems .............................................................................................................................................6-12
6.4.1 Incorrect CGI leads to low handover success rate. ............................................................................6-12
6.4.2 BSIC modification leads to low handover success rate. ....................................................................6-13
6.4.3 Consistent BCCH and BSIC lead to failures of TCH occupation and incoming cell handover. ........6-14
6.4.4 Cell BCCH modification leads to lots of incoming handover failure and SDCCH congestion. ........6-16
6.4.5 CGI error of cell description data table leads to no incoming handover to this cell. .........................6-17
6.4.6 Failure in Loading Applications and Data to the Standby MCCM ....................................................6-18
6.4.7 Voice Noise ........................................................................................................................................6-19
6.5 BTS-Related Problem .................................................................................................................................6-20
6.5.1 Too high busy threshold of RACH of BTS2.0 leads to low handover success rate. ..........................6-20
6.5.2 Uplink/downlink unbalance due to CDU failure leads to low handover success rate........................6-21
6.5.3 BTS clock free oscillation leads to low handover success rate. .........................................................6-22
6.5.4 TRX performance deterioration leads to low success rate of incoming cell handover.......................6-23
6.5.5 Improper antenna planning leads to low handover success rate.........................................................6-24
6.6 Others ..........................................................................................................................................................6-25
Huawei Proprietary and Confidential

Issue 01 (2008-03-14) i
Copyright © Huawei Technologies Co., Ltd
Contents Troubleshooting Manual
6.6.1 Locating the Problem with Low Incoming BSC Handover Success Rate Through the Traffic Statistic
....................................................................................................................................................................6-25
6.6.2 Locating the handover Problem Through the Radio Handover Success Rate and Handover Success
Rate Difference ...........................................................................................................................................6-26
6.6.3 Sometimes the Incoming Handover may be to the Cell Which is not Allowed by NCC ...................6-27
6.6.4 Excessively High Min. Downlink Power of Candidate Cell Leads to Handover Unavailability .......6-28
6.6.5 Unsuccessful Conversion Between a Full-Rate Channel and a Half-Rate Channel...........................6-28
6.6.6 Unsuccesfull Handover from Huawei BSC .......................................................................................6-29
6.6.7 Unsucessful Inter-BSC Handover ......................................................................................................6-30

ii Issue 01 (2008-03-14)
Troubleshooting Manual Figures
Figures
Figure 6-1 Signaling flow of typical handover failure .......................................................................................6-8

Figure 6-2 Signaling flow of successful handover .............................................................................................6-9
Figure 6-3 Flow of part handovers ...................................................................................................................6-26

Issue 01 (2008-03-14) iii
Tables Troubleshooting Manual
Tables
Table 6-1 Meanings of the blinking indicators of the MCP card ......................................................................6-18
Table 6-2 Traffic statistic indices before/after data modification .....................................................................6-25

iv Issue 01 (2008-03-14)
Troubleshooting Manual 6 Troubleshooting for Handover
6 Troubleshooting for Handover
About This Chapter
The following table lists the contents of this chapter.
Title Description
6.1 Overview Introduces the main idea of this chapter.

6.2 Trouble Handling Describes the procedure for locating various problems.
6.3 MSC Handover Problem Describes the procedures for handling the MSC handover
problem.
6.4 BSC Problems Describes the procedure for handling the BSC problems.
6.5 BTS-Related Problem Describes the procedure for handling the BTS-related
problem.
6.6 Others Describes the procedure for handling problems other than
mentioned previously.

Issue 01 (2008-03-14) 6-1
6 Troubleshooting for Handover Troubleshooting Manual
6.1 Overview
MS continuously moves and its relative position to the BTS changes during conversation. In
order to guarantee the channel quality during conversation, MS continuously measures the
quality of radio channels of the surrounding cells and transmits the measurement report to
BSC through the BTS of service cell.
BSC implements the radio link control based on the information such as the level strength and
quality class of service cell and adjacent cell contained in the report. When MS moves from
one cell to another, the new cell instead of the original one will serve it and guarantee the
continuity of service. All cells are formed as a seamless network through handover.
There are many reasons causing the handover failure. This part describes the common idea
and examples for the handover failure analysis.
6.1.1 Failure Classification

Classified by phenomenon
They can be classified into 3 kinds of problem based on the phenomenon of handover failure.
z problem of none-handover initiation
z problem of incoming cell handover
z problem of outgoing cell handover
Classifed by reasons
They can be classified into 3 kinds of problem based on the reasons of handover failure.
z Hardware failure, including board failure, hardware connection failure, etc. which may
only be caused by BTS, BSC or MSC, or improper matching of BTS, BSC and MSC.
z Data configuration failure, including adjacent cells with consistent BCCH and BSIC,
inconsistent CGI, unreasonable handover parameters and defect of frequency planning.
z Congestion
6.1.2 Tool for locating the faults

The traffic statistic is a good tool to analyze the handover failure, e.g. when the handover
success rate is low in an office, check if the radio handover success rate is also low through
the traffic statistic. If it is, check if that is caused by the hardware failure or too low level in
handover or analyze if the handover threshold is set too low, resulting in low success rate due
to too low level in handover.

6-2 Issue 01 (2008-03-14)
6.2 Trouble Handling

6.2.1 Locating Procedure
Step 1 Confirm if the problem occurs in an individual cell or all cells, and the characteristic of the
failed cell, e.g. all are the adjacent cells of a cell or they share BSC and MSC.
z If the handover failure occurs between 2 cells, check with emphasis if the data
configuration between 2 cells is correct and if the hardware fails.
z If the failure occurs in all adjacent cells of a cell, check with emphasis if the data
configuration of this cell is correct and if the hardware of it fails.
z If the failure occurs in all the cells under the same BSC, check with emphasis the data
configuration between BSC and MSC.
z If the failure occurs in all the cells under the same MSC, there may be a problem with
the matching between the opposite office and this office, such as incompatible Signaling
and unreasonable timer setting.
Step 2 Confirm if the data are modified before the handover failure.
z If the failure occurs in an individual cell, check if the data configuration related to this
cell is modified.
z If the failure occurs in all the cells under the same BSC, check if the data configuration
of this BSC and opposite MSC is modified.
z If the failure occurs in all the cells under the same MSC, check if the data configuration
of opposite MSC is modified.
Step 3 Check if the handover problem is caused by the hardware failure. See 1.2.3 for the locating
method.
Step 4 Register the useful traffic statistic, such as the handover and TCH performance
measurements.
Pay attention to the following, but not only these are involved.
z Observe if TCH occupation of failed cell is normal, e.g. if call drop rate rises up.
z Observe if the success rates of incoming and outgoing handover are normal.
z Observe the distribution of reasons for handover failure.
z Observe if the radio handover success rate is normal.
Step 5 Do the driving test on the failed cell and analyze the Signaling of driving test.
Pay attention to the following.
z Observe if the uplink/downlink level of failed cell is balanced. The uplink/downlink
unbalance may cause the handover problem. And frequent uplink/downlink unbalance is
caused by the hardware failure.
z Observe if the measurement report of failed cell contains the correct list of the adjacent
cells.
z Observe if it is possible to hand over from the failed cell to the adjacent cells and vice
versa.
z Analyze if the Signaling flow of handover is normal.
----End

Issue 01 (2008-03-14) 6-3
6.2.2 Locating Procedure of No Handover Starting Up

The MS in a cell can not initiate a handover into another cell under very weak signal or the
signal with very bad quality. This kind of problem is generally analyzed from the following 2
aspects.
z if the condition of outgoing handover is met;
z if there is a candidate cell according with the condition of outgoing cell handover.
There may be the following specific reasons.
The handover threshold is set too low

For the edge handover, the triggering condition is the Rx level is lower than the handover
threshold. If the handover threshold is set too low, the handover will not initiate even when
the level of adjacent cell is much higher than that of service cell.
The conversation quality will be impacted and call drop will be resulted when the condition is
serious. The handover threshold should be set based on the coverage scope of cell. The scope
of service area in the cell can be indirectly changed through the handover threshold.
The relationship of adjacent cell is not set

Although the level of adjacent cells in the service cell is very high, MS does not report this
adjacent cell and the handover to this cell is unavailable as the relationship of adjacent cells is
not set. Observe the adjacent cell list of service cell reported by MS through reselection or
conversation test.
If MS has already moved to the main lobe of a cell, but there is no such a cell in the adjacent
cell list, check if the correct relationship of adjacent cells is set. Or scan BCCH frequency
with another MS in the test and observe if the BCCH frequency with stronger signal occurs in
the service cell or adjacent cell list.
The hysteresis is set unreasonable

Only when the difference of signal levels of handover candidate cell and service cell is bigger
than the hysteresis, can it be taken as the destination cell. When the hysteresis is set too big,
handover may be hard to be triggered.
The parameter N-P is set unreasonable

In normal handover, MS sorts the sequence of handover candidate cells through N-P principle.
If a candidate cell is the optimal cell for P seconds in N seconds, it can be taken as the
destination cell of handover.
When 2 good candidate cells become the optimal cells alternatively, it is very hard for the
handover decision algorithm to find an optimal cell satisfying N-P principle, resulting in hard
handover. Adjust the setting of N and P, and reduce the statistic time to make the handover
decision be more sensitive to the level change.
This case occurs in optimization of a network. The original statistic time of a cell is N=5 and
P=4 and after they are adjusted as N=4 and P=3, the handover is normal.
When the land form of service cell is very complex, the received-signal level of moving MS
fluctuates a lot. In this case it is hard for the candidate cell to satisfy the N-P principle,
resulting in hard handover.

6-4 Issue 01 (2008-03-14)
6.2.3 Locating of Hardware Failure

If the data configuration of failed cell and adjacent cell have not been modified recently and
the handover problem occurs suddenly, first consider if it is caused by BTS hardware failure.
Step 1 If similar problem occurs in the shared BTS cell of this cell, consider if it is caused by the
shared hardware failure of cells, e.g. if TMU fails.
Step 2 If only one cell has the problem with handover under this BTS, consider if it is caused by the
cell hardware failure, e.g. some carriers are damaged and the failure of handover to the carrier
is resulted.
Some carriers can be blocked to verify this problem. If the handover success rate is recovered
normal after a carrier is blocked, check if it is caused by the failure of this carrier, the related
CDU or antenna. If the signal uplink/downlink of a carrier is seriously unbalanced, the
handover problem will be resulted, e.g. frequent handover or decreasing of handover success
rate.
Step 3 Observe if the Signaling of this cell is normal through Abis interface tracing, including if the
uplink/downlink Rx quality in the measurement report is good. If the Rx quality in the report
is bad, there will be failure with the hardware or serious interference in this cell, as a result,
the Signaling can not be normally interacted and the handover problem is caused.
----End
6.2.4 Locating of Data Configuration Problem

As there are many handover problems caused by the data configuration error, the analysis and
solution are introduced below.
Step 1 MSC independent networking mode: If the handover of incoming or outgoing MSC is
abnormal, check first if the Signaling matching of 2 MSCs is correct and second if the data
have been modified recently for the opposite MSC and local MSC.
Step 2 Shared MSC networking mode: If the handover is between BSC from different suppliers and
the handover abnormity occurs, check first if the Signaling matching between BSC is correct
and second if the data have been modified for BSC.
Step 3 If the handover abnormity only occurs in a cell, make the analysis based on the specific
condition of abnormity.
Step 4 If the incoming cell handover is abnormal, observe if the handover from all other cells to this
cell is abnormal (the general problem for abnormity is the handover success rate is low and
the handover to this cell is unavailable).
If the handover from all other cells to this cell is abnormal, it is generally caused by the data
configuration of this cell. The data configuration includes not only that of this cell but also
that of other cells related to this cell. For instance, CGI may be correct in the data
configuration table of this cell but incorrect when configured in other adjacent cells.
The incoming cell handover is abnormal, but only the handover of one cell to this cell is
abnormal and that of others to this cell is normal. If so, check if the data configuration of
adjacent cells about this cell is correct and if the hardware of this cell is normal other than
checking if the data configuration of adjacent cells is correct in that of this cell.
For the abnormity of outgoing cell handover, the analysis idea is similar to the incoming cell
handover, so it is not described here.

Issue 01 (2008-03-14) 6-5
----End
6.3 MSC Handover Problem

6.3.1 Charging Data Modification of Supplier A Leads the Success
Rate for the Incoming MSC Handover of Dual Band Network to
0%
Description
After a dual band network was activated, the indices were normal all the time. But someday
the incoming MSC handover success rate suddenly became 0%.
Handling Suggestions
Step 1 When the handover was suddenly abnormal, check if the data configuration of GSM1800
network had been modified.
Step 2 When the Signaling at MSC side of GSM1800 was traced, it was discovered after MSC of
GSM900 transmitted the handover request to that of GSM1800, the latter responded the
handover response message (with handover command) to the former. And after 2 seconds,
MSC of opposite GSM900 responded the Abort message to that of GSM1800.
Step 3 When the Signaling of MSC for GSM900 was traced, it was discovered the Ho Detect
message was reported by BSC of GSM900 when handed over from the BTS of GSM900 to
that of GSM1800. But that message transmitted from GSM900 was not received at the MSC
side of GSM1800, so the handover failure was resulted.
Step 4 It was checked If the data of opposite MSC were modified and it was discovered the MSC
data of GSM900 had been modified.
Step 5 The handover was normal after the MSC data of GSM900 were modified.
----End
6.3.2 MSC Data Configuration Error Leads to the Handover

Failure
Description
The GSM1800 network of an office was of Huawei and the GSM900 network was of supplier
S. The former was the configuration of 1 MSC (MSC4) and the latter was that of 2 MSC
(MSC1 and MSC2). MS was handed over from MSC4 to MSC1 and the handover was normal.
But when MS was handed over from MSC4 to MSC2, the handover was unsuccessful.
Step 1 As the handover from MSC4 to MSC1 was normal, the reason of failure may be the problem
with routing from MSC4 to MSC2.

6-6 Issue 01 (2008-03-14)
Step 2 When checking the Signaling link of interface E between MSC2 and MSC4, all was normal
and there was no problem with the conversation between MSC2 and MSC4.
Step 3 The Signaling of interface E was analyzed. MS under MSC4 transmitted the handover request.
MSC2 responded the handover request response and transmitted the return handover roaming
number but the latter flow was interrupted.
Step 4 The latter flow was MSC4 established the service channel at interface E based on the
handover roaming number addressing. It was possible MSC4 did not check out the routing
based on the handover roaming number.
Step 5 When checking the data configuration of MSC4, it was discovered the called number attribute
of roaming number returned by MSC in the analysis table of called number was configured as
MSISDN.
Step 6 After the called number attribute was modified, the failure was eliminated.
----End
Recommendation
As the incoming/outgoing handover is related to the selection of routing, the analysis of
failure reason is complicated. It is recommended to make good use of the analyzer function
and find out the failure reasons from the flow.
6.3.3 Improper BSC Parameter Setting of Company Causes Low

Handover Success Rate to Huawei MSC
Description
In an office, MSC, BSC and BTS from both Huawei and company S existed at the same time.
The handover success rate from MSC of Huawei to that of company S was generally
maintained about 80%, but the handover success rate from MSC of company S to that of
Huawei was lower and the lowest was about 30%.
Fault Location
There are many factors impacting the across-MSC handover. They include the network
optimization, data configuration and protocol.
Handover includes 3 processes:
Handover Required Indication;
Handover Resource Allocation;
Handover Execution;
The Handover Required Indication process allows BSS to execute handover for an MS request.

Issue 01 (2008-03-14) 6-7
Step 1 Adjust the radio parameters such as frequency, power and handover relationship of both sites
near to the coverage area of equipment from company S, but the effect is not obvious.
Step 2 The Signaling of both interfaces was traced through the Signaling analyzer and it was
discovered the main reason for unsuccessful handover was BSC of company S did not deliver
the Handover Command message to MS, resulting in the time out of timer waiting for MS
access of Huawei MSC.
Figure 6-1 shows the Signaling flow of typical handover failure.
Figure 6-1 Signaling flow of typical handover failure
S MSC Huawei MSC
Prepare Handover (MAP)
Prepare Handover ACK (MAP)
IAI (TUP)
ACM (TUP)
7s Timer Overtime
Handover Failure (MAP)
Abort (MAP)
CLF
RLG
The Signaling result showed for most of handover, the time from Prepare Handover to receive
MAP Prepare Handover ACK (MAP) was about 2s. With the delay on the interface A, the
whole continuous process exceeded 2s in most cases. For a small amount of handovers trying
within 1s, it succeeded in most cases. The speed of continuous process for handover was
related to not only the switch but also the radio environment. The varied algorithm of different
equipment also led to the possibility of handover delay.
Step 3 RACHBT parameter of BSC from company S was modified (the min. interval of service
channel handover, corresponding to Huawei BSC parameter as the min. interval of channel
handover) from 3s to 5s, then the problem was resolved. (BSC parameter of Huawei is 4s.
Figure 6-2 shows the Signaling flow of successful handover.

6-8 Issue 01 (2008-03-14)
Figure 6-2 Signaling flow of successful handover

S MSC Huawei MSC
Prepare Handover (MAP)
Prepare Handover ACK (MAP)
IAI (TUP)
ACM (TUP)
Handover Detect
ANN
Handover Complete
CLF
RLG
Step 4 After the problem was resolved, the handover success rate of both parties reached about 80%.
----End
Recommendation
The handover across MSC is related to BTS, BSC and MSC of both parties. So the analysis is
difficult and there are many problems to be resolved. As long as they are analyzed and
excluded through checking, all problems will be finally resolved.
6.3.4 Signaling Matching Problem Leads to Handover Failure

Description
The BSC office (1AM+2BM) was newly established in a place and connected to MSC60 of
Huawei. The BSC controlled 50 BTSs.
All was normal when handover was among the cells within BSC. But when the outgoing BSC
was handed over to the BSC connected to DX2000 (MSC) of supplier N, the handover was
unsuccessful. The handover from BSC of supplier N to that of Huawei could be successful
and the consequent handover back to BSC of supplier N could also be successful.
Fault Location
Step 1 Unsuccessful handover might be due to the problem with data configuration at BSC side, e.g.
external description error, cell adjacent relationship error, BA1 table and BA2 table
description error.

Issue 01 (2008-03-14) 6-9
Step 2 It might be due to the problem with data configuration of cell description in MSC60 of
Huawei BSC.
Step 3 As the inter-office handover between MSC of Huawei and DX2000 (MSC) of supplier N was
involved, it might be due to the external description error of BSC connected to DX2000 on
BSC of Huawei.
----End
Step 1 When checking out the reasons at BSC side of Huawei, the data table of external cell
description, cell adjacent relationship table, BA1 (BCCH) table and BA2 (SACCH) table, the
maintenance personnel did not find any error. The data of foreground/background were
consistent based on checking.
Step 2 Let BSC of other party check if the external cell description data of Huawei BSC cell were
correctly set. They were correct based on checking.
Step 3 Let MSC of both parties confirm if the data were correctly set. They were both correct based
on the confirmation.
Step 4 The Signaling at interface A was traced and it was discovered when Huawei BSC cell
delivered compulsory handover to the cell of other party, there was only handover request
command but no handover command delivered by upper level MSC of Huawei, and CGI of
destination cell was correctly reported in the handover request.
But the Signaling was completely correct when the compulsory handover was transmitted
from the cell of other party to that of Huawei and the handover was successful. It could be
fundamentally ensured there was no problem with data configuration and there might be the
problem with the Signaling flow between MSC.
Step 5 According to inter-office handover flow, when Huawei BSC delivered the compulsory
outgoing BSC handover to BSC of supplier N, Huawei BSC first transmitted a handover
request to upper level MSC60 which transmitted Perform Handover to DX200. The CGI of
destination cell was included in this message. VLR of other party allocated an Handover
Number and returned it to Huawei MSC60 through Radio Channel ACK. If the Signaling
flow was normal, MSC60 transmitted an IAM to DX2000 which transmitted an ACM to
MSC60.
After the session was established, MSC60 delivered Handover Command to Huawei BSC and
then MS could be handed over to BSC of other party.
Step 6 MAP message was traced with analyzer between MSC. It was discovered MSC60 did not
transmit IAM after it received the message Handover Number transmitted by the other party
and thus the Signaling flow was terminated. When this message was checked, it was
discovered DX2000 had found the CGI of destination cell.
Step 7 When Handover Number from other party was analyzed, it was discovered the handover
number of other party was transmitted in the mode of 130% % % % % % % % % without 86
added in front. As Huawei equipment did not accept this format, the handover failure was
resulted.
Step 8 Coordinated with supplier N for adding 86 before the handover number, the problem was
resolved.
----End

6-10 Issue 01 (2008-03-14)
6.3.5 Equipment Matching Problem Between Different Supplier

Leads to Low Outgoing BSC Handover Success Rate
Description
The independent networking of Huawei GSM1800 in an office was matched through dual
frequency with GSM900 of supplier A and supplier B. After the reselection and handover data
were completed for both parties, it was observed through the traffic statistic the dual
frequency handover success rate was low.
It was represented that the handover success rate from GSM1800 to GSM900 was as low as
about 60% to 80% and that from GSM900 to GSM1800 was high.
Fault Location
When there was problem with the interconnection with the equipment from other suppliers,
the parameter and details of the other party should be known on time, e.g. if Phase 2+, EFR
was supported.
Step 1 The message of interface A and interface E was analyzed through a Signaling analyzer. It was
discovered after BSC of GSM1800 transmitted the message Handover Required, MSC of
GSM1800 responded the message handover REJECT and declined handover.
Step 2 The corresponding interface E (GSM1800 MSC-GSM900 MSC) GSM 1800 MSC transmitted
Prepare Handover to GSM900 MSC which responded the message Abort.
Step 3 As the handover success rate from GSM900 to GSM1800 was high, it was observed in the
message Prepare Handover transmitted from GSM900 MSC to GSM1800 MSC, the voice
version provided was the full rate version 1.
But in the message Prepare Handover transmitted from GSM1800 MSC to GSM900 MSC,
the voice version provided was the full rate version 1 and 2 and half rate version 1 belonging
to PHASE 2+ version. MSC of supplier A did not accept this version, so handover failure was
resulted.
Step 4 Only the full rate version 1 was selected through the modification on circuit pool table of
interface A of MSC data. After loaded, it was discovered the voice versions provided in the
message Prepare Handover from GSM1800 to GSM900 were all the full rate version 1 and 2.
The dual frequency handover success rate was greatly increased.
----End

Issue 01 (2008-03-14) 6-11
6.4 BSC Problems

6.4.1 Incorrect CGI leads to low handover success rate.
Description
MSC of an office is the equipment of supplier M while BSC and BTS are the equipment of
Huawei. The traffic statistic indices of a day were observed and it is discovered in "Inter-cell
Handover Performance Measurement", "success rate of inter-cell handover" was very low for
a cell (cell 24 of No.3 module of BSC) at the period of 10:00 to 11:00, and it was 73.12%. It
was discovered that was mainly because the outgoing cell handover success rate in the cell
46000****OCFB was very low and the handover failure times reached 10.
Fault Location
The main reasons causing the failure of handover between cells follow.
Step 1 unreasonable handover data configuration
Step 2 problem with equipment (individual TRX damaged)
Step 3 congestion
Step 4 interference
Step 5 clock problem
Step 6 coverage
Step 7 uplink/downlink unbalance
Handover flow:
Step 8 “All BCCH frequencies of adjacent cells in "BA2 Table" are delivered to MS through the
system message type 5.
Step 9 MS reports the BCCH frequencies, BSIC and level value of 6 adjacent cells and service cell
with the strongest level to BSS (through the measurement report).
Step 10 After the measurement report is preprocessed, the module, cell number and CGI of all cells
are confirmed by BSC through BCCH frequency and BSIC to "Cell Adjacent Relationship
Table" and "Cell Description Data Table" (external cell description data table).
If "Cell Adjacent Relationship Table" is not configured with an adjacent cell, the information
of this adjacent cell will not be indexed, thus handover can not be transmitted. If the
frequency and BSIC of 2 adjacent cells are same, they will be indexed to the first adjacent cell,
thus handover failure will be resulted.
If the frequency of active BCCH in cell A is the same as that of a TCH in cell B which has the
same BSIC with cell C, the asynchronous handover access on a time slot (this time slot is
aligned with the active BCCH time slot in cell A) of this TCH may by encoded by mistake
through cell A into its own random access.
For instance, MS retransmits the handover access to cell B in this time slot for several times
due to some reason (e.g. handover failure), cell A may generate SDCCH congestion and
assignment failure.

6-12 Issue 01 (2008-03-14)
Step 11 BSC executes the handover decision flow (completed in GLAP) such as basic sequence of
cell. Once it finds the proper destination, it will transmit the handover request information
with destination cell CGI to BSCGMPU. GMPU confirms the number of module where the
cell locates in "cell module information table".
Step 12 GMPU transmits the handover request to this module and makes the statistic for "Outgoing
Cell Handover Request".
Step 13 If there is no CGI in the "Cell Module Information Table", BSC will think the destination cell
is an external cell and transmit the CGI of destination cell and service cell to MSC through the
handover request.
Step 14 MSC first checks the cell matching with the destination cell CGI in "Location Area Cell
Table", confirms the ''Destination Signaling" of this cell, i.e. BSC, and transmits the handover
request message to this BSC.
Step 15 If there is no CGI of destination cell in "Location Area Cell Table", look it up in the adjacent
cell. If found, transmit the handover request message to this MSC, then to BSC.
----End
Step 1 There are no full busy times in the traffic statistic, so the problem with congestion can be
excluded.
Step 2 There is only interference for the interference band 2 in "TCH Performance Measurement", so
the handover failure due to interference can be excluded.
Step 3 Check the board status in "BTS Maintenance System", it is normal (so the problem with
equipment can be excluded). Right click TMU-check the board-close and double click
BAM-WH long message. The final digits are "12-01-", showing the clock is normal.
Step 4 There are many failure times for outgoing BSC handover. The maintenance personnel
checked BA2 table, cell adjacent relationship table, external cell description data table and
location area cell table, but did not find the data inconsistency and consistent frequency and
BSIC. After checking, the maintenance personnel discovered the CGI about this cell in the
external cell description table was incorrect.
Step 5 CGI was modified. All modules were transmitted after setting. The command character was
configured for all the cells taking this external cell as the adjacent cell, i.e. the handover data
were configured. The indices were observed an hour later and all was normal.
----End
6.4.2 BSIC modification leads to low handover success rate.

Description
When the result of traffic statistic was checked, it was discovered the handover success rate in
some cells was low. Based on detailed analysis, it was discovered the outgoing cell handover
of these cells was normal but the time of incoming cell handover is 0.

Issue 01 (2008-03-14) 6-13
Step 1 It was checked whether there was the cell with consistent frequency and BSIC in the adjacent
cell of failed cell but it was not discovered, so this reason was excluded.
Step 2 It was checked whether BCCH of failed cell had been modified and it was discovered not all
adjacent cells of failed cell were set. But based on the record, the frequency of failed cell had
never been modified, so this reason was excluded.
Step 3 It was checked whether the failed cell had been severely interfered. Seen from the traffic
statistic, the interference band was all normal and there were not many times for call drop of
failed cell and there were few times of handover caused by the bad quality of conversation. If
there was interference, it would be impossible there was no successful incoming cell handover.
So this reason was also excluded.
Step 4 It was checked whether TRX worked normally, and the channel was observed, but no
problem was found out.
Step 5 The data of failed cell were checked and it was discovered BSCI had been modified. Not all
adjacent cells might be dynamically set. It was through BCCH and BSIC that BSC located the
destination cell when it transmitted the handover request. When one of them was modified, all
adjacent cells of the modified cell should be informed.
Step 6 After all adjacent cells of failed cell were dynamically set, the traffic statistic was observed
the next day and it was discovered all was normal for the incoming cell handover.
----End
6.4.3 Consistent BCCH and BSIC lead to failures of TCH

occupation and incoming cell handover.
Description
The traffic statistic indices of an office were observed and it was discovered in "TCH
Performance Measurement", there were many "assignment occupation failure times (all)" for
2 cells (cell 7 and 8 of No.2 module of BSC) in a period of time, which were respectively 89
times and 61 times. But "TCH call occupation failure times" were 0.
Step 1 "TCH assignment failure times" were consisted of "TCH call occupation failure times" and
"TCH assignment failure time in handover". As "TCH call occupation failure times" were 0,
all TCH assignment failures occurred in handover.
Step 2 Fifteen minutes of "incoming cell handover performance measurement" of the 2 cells was
registered to check between which adjacent cells on earth and this cell the failure occurred.
With the observation of several period of time, all handover failures were from a specified
cell (CGI=********1768) to the 2 cells and the handover was not caused by congestion. So it
was estimated the failure was caused by the handover to wrong cell due to data error of cell
with consistent frequency and BSIC.

6-14 Issue 01 (2008-03-14)
Step 3 Under the state of conversation, MS measured the level value of frequency corresponding to
the adjacent cell specified in BA2 table delivered by the system through SACCH, and
reported the measurement result to BSC. Based on the reported BCCH and BSIC, BSC found
the module number and cell number of related adjacent cell in [Cell Description Data Table].
Then it confirmed the found cell was geographically and logically adjacent to the service cell
through checking the module number and cell number of adjacent cell of service cell in [Cell
Adjacent Relationship Table]. And it found the module transmitted by the handover request in
[Cell Module Information Table] through finally-confirmed CGI (this CGI was of the adjacent
cell recorded by the system when it was looking for [Cell Description Data Table]). Thus the
course of looking up the information of adjacent cell and routing was completed.
Step 4 Based on the course above, it could be judged there was the cell with consistent BCCH and
BSIC in [Cell Description Data Table] and this group of cells with consistent BCCH and
BSIC were exactly the adjacent cells of the same cell.
Step 5 Based on the flow of the table checking above, the module number and cell number of all
adjacent cells of the cell with CGI=********1768 were recorded in [Cell Adjacent
Relationship Table], then the corresponding BCCH and BSIC were checked and recorded in
[Cell Description Data Table].
It was discovered the cell 7 of No.2 module and cell 27 of No.3 module were the cells with
consistent BCCH and BSIC, and the cell 8 of No.2 module and cell 36 of module 5 were the
cells with consistent BCCH and BSIC, too. After the reason was found, BSIC of cell was
modified to reduce the work amount for modifying the data. After the data were set, the
related indices were normally recovered.
----End
Recommendation
Step 1 When the network capacity is very large, the cells with consistent BCCH and BSIC are
unavoidable. To reduce the error probability, it is required to make good planning on
frequency and BSIC in the network planning and this is important in guaranteeing the
network quality.
Step 2 If there are adjacent cells with consistent BCCH and BSIC in a cell, the success rate will
surely be 0 when the handover is from the cell to those adjacent cells. It is shown in the traffic
statistic that the success times of incoming cell handover of the specified cell in "Incoming
cell Handover Performance Measurement" of a cell are always 0 (the failure reason is not
congestion). And there are "TCH occupation failure times (all)", but the times of "TCH call
occupation failure" are 0.
Step 3 Being familiar with the flow of handover and that of system table checking is the precondition
for quick decision and location of handover failure.
----End

Issue 01 (2008-03-14) 6-15
6.4.4 Cell BCCH modification leads to lots of incoming handover

failure and SDCCH congestion.
Description
Step 1 There was the adjacent frequency interference for a cell due to the frequency planning,
resulting in high call drop and bad conversation quality. So the data management console
modified and dynamically set the active BCCH frequency. The next day the traffic statistic
showed there were lots of BSC inner-incoming handover and BSC inter-incoming handover
in cell 1, but most were unsuccessful. Meanwhile the cell 1 SDCCH was seriously congested
(max. congestion rate was 75% for being busy).
Step 2 When the channel state was observed in the remote maintenance of BTS, it was discovered
there was no SDCCH occupation before lots of TCH occupation in cell 1 (such TCH
occupation should be BSC inner or inter-incoming handover to TCH). And the TCH
occupation time was basically 3s to 5s, but few was 10s. Sometimes 3 to 4 TCH became "A"
at the same time and quickly became "I". Although SDCCH was seldom occupied, it was very
common that 8 SDCCH became from "I" into "A".
----End
Step 1 After the abnormity of cell 1 was found out, the operation of a day was reviewed based on the
traffic statistic and it was discovered the frequency planning was modified and dynamically
set just before lots of incoming handover failure and SDCCH congestion rate increment. So
the problem was probably caused by the data setting.
Step 2 In order to confirm the congestion was not caused by the hardware problem, the equipment in
this BTS was checked and verified. And the channel state of cell 1 was observed at the remote
end. Finally it was located that the problem was caused by the data modification and setting.
After the frequency of cell was modified, this cell and another cell had consistent BCCH and
BSIC.
When BSC implemented the handover and decision based on the BCCH and BSIC of adjacent
cells reported by MS, it possibly handed over the request which should be to another cell to
this cell. Even if no power was transmitted from this cell, the incoming handover request
would be generated.
After the incoming handover, it was discovered the channel quality was very bad, and became
a bit better after a while. So it was discovered the occupation TCH time of incoming handover
was very short (3s to 4s). If the traffic of another cell was large, the times of request for
incoming handover to this cell would increase, resulting in the failure of lots of incoming
handover. This cell received lots of instant assignment request and assigned SDCCH,
resulting in serious SDCCH congestion.
Step 3 After the frequency of active BCCH of cell was modified and the data were reset, the problem
was resolved. The incoming handover times of cell 1 was recovered to the normal level as
usual.
----End

6-16 Issue 01 (2008-03-14)
6.4.5 CGI error of cell description data table leads to no incoming

handover to this cell.
Description
The handover of a GSM network was abnormal. When the handover was from cell A to cell B,
the signal of cell B was much stronger than that of cell A, but the handover was not generated.
Only after the handover was across cell B coverage area to cell C coverage area was the
handover from cell A to cell C available.
Fault Location
If a cell can be taken as the service cell providing service and be formally handed over to
other cells but not be handed over in, it can be checked whether CGI, BSIC, BCCH frequency
number, etc. of this cell in [Cell Description Data Table] are correct. Normally it is caused by
the incorrect setting of those data.
Step 1 The BCCH frequency of cell B was locked by the test MS. It was normal when dialing.
Compulsory handover could be available to any adjacent cell.
Step 2 The BCCH frequency of any adjacent cell in cell B was locked for dialing, then it was
compulsorily handed over to cell B, but the handover was unavailable. It was discovered from
the software of driving test that there was no handover command in the network.
Step 3 Based on the handover flow, it should be MS that detected the signal of adjacent cell and
reported to BSC in the measurement report. BSC made the handover decision based on the
measurement report. If the handover condition was met, the service channel of destination cell
would be activated and the handover command was transmitted to MS.
Step 4 The signal of cell B was obviously stronger than that of cell A. The handover requirement
(PBGT handover threshold 70) was surely met, but the handover command was not
transmitted. It showed there was an error in the course of activating the service channel of
destination cell.
Step 5 Only 2 items, frequency and BSIC, were contained in the adjacent cell information reported
by MS. BSC looked up the cell which had the adjacent relationship with the service cell in
[Cell Description Data Table] and [External Cell Description Data Table] based on the
frequency and BSIC, and found the CGI of destination cell. If the destination cell was the
external cell, the handover request would be transmitted to MSC. The portable parameter was
the CGI of destination cell. The course of channel activation was completed by BSC in which
the destination cell located. Then the handover command was transmitted to MS by the
service cell. If the destination cell was the inner cell of BSC, the module number and cell
number of destination cell would be determined by CGI, then the channel activation was
completed and the handover command was transmitted.
Step 6 If cell B could not activate the channel when taken as the destination cell, it might be due to
the error of [Cell Description Data Table]. As a result, BSC in which the destination cell
located could not find the destination cell or activate the channel, and the service cell did not
transmit the handover command.
Step 7 When [Cell Description Data Table] was checked, it was discovered there was an error for the
CGI of cell B. After the CGI was modified and dynamically set, the handover was normal.
----End

Issue 01 (2008-03-14) 6-17
6.4.6 Failure in Loading Applications and Data to the Standby

MCCM
Description
A BSC has multiple BMs. When the BSC is reset, the loading of applications and data to the
standby MCCM boards fails.
Fault Location
Both the active and standby MCCM boards of a multi-module BSC provide paths for data and
program loading for the boards in the BSC. Except for the standby MCCM boards, the
applications and data of the other boards are loaded through the active MCCM board.
If the MCP card connecting to the corresponding standby MCCM board is faulty, the loading
of applications and data to the standby MCCM board fails. This does not affect the loading of
applications and data loading for other boards.
To locate the fault, do as follows:
Step 1 Observe the indicator of the MCP card connecting to the corresponding standby MCCM
board, and check whether both links of the MCP card connecting to the corresponding
standby MCCM board are working normally.
Table 6-1 shows the meanings of the indicator of the MCP card.
Table 6-1 Meanings of the blinking indicators of the MCP card
Blinking Frequency Meaning
On for 200 ms and off for 200 ms The MCP card is waiting for the configuration
command from the BSC.
On for 500 ms and off for 500 ms Both links of the MCP card are faulty.
On for one second and off for one Both links of the MCP card are normal.
second
On for two seconds and off for One link of the MCP card is normal.
two seconds
z Yes => The MCP card connecting to the corresponding standby MCCM board is normal.
The fault is caused by other reasons.
z No => Go to Step 2.
Step 2 Exchange the transmission cable (which connects the MCP card in the BAM subrack to the
corresponding active MCCM board) with the transmission cable (which connects the other
MCP card in the BAM subrack to the corresponding standby MCCM board).
Step 3 Check whether the loading of applications and data through the active MCCM board is
normal.
z Yes=> The MCP card connecting to the corresponding standby MCCM board is faulty.
z No=> The transmission cable which connects the MCP card in the BAM subrack to the
corresponding standby MCCM board is faulty..

6-18 Issue 01 (2008-03-14)
----End
The previous analysis shows that the fault is caused by:
z The faulty MCP card connecting to the corresponding standby MCCM board
z The faulty transmission cable which connects the MCP card in the BAM subrack to the
corresponding standby MCCM board
To rectify the fault, do as follows:
z Replace the faulty MCP card connecting to the corresponding standby MCCM board.
z Replace the faulty transmission cable which connects the MCP card in the BAM subrack
to the corresponding standby MCCM board.
6.4.7 Voice Noise

Description
Voice noise exists in the calls made under the control of a BSC (with one administration
module (AM) and one basic module (BM)). The BER indicator of the GFBI board is on or
flashes quickly.
Fault Location
When error codes about the GFBI board exist, the following two cases occur:
z The BER indicator of the GOPT board or GFBI board is constantly on or flashes quickly.
Fault alarm about the GOPT board and clock fault alarm about the GCTN board appear
and soon recover.
z The BER indicator of the GOPT board or GFBI board is off every one or two minutes or
constantly on.
Step 1 Switch over the active and standby GCKS boards, and check whether the error codes about
the GFBI board exist.
Yes=> Go to Step 2.
No=> The original active GCKS is faulty.
Step 2 Switch over the active and standby GCTN boards, and check whether the error codes about
the GFBI board exist.
Yes=> Go to Step 3.
No=> The original active GCTN board is faulty.
Step 3 Replace the GFBI, GFBC, GOPT boards, and the fibers, and check whether the error codes
about the GFBI board exist.
Yes=> Go to Step 4.
No=> The original GFBI, GFBI, GFBC, GOPT boards, or the fibers is faulty.

Issue 01 (2008-03-14) 6-19
Step 4 Change the slot of the GFBI and GFBC in the transmission interface subrack, and check
whether the error codes about the GFBI board exist.
Yes=> Go to Step 5.
No=> The original slots where the GFBI and GFBC locate may be faulty; or the GFBI or
GFBC boards are poorly contacted.
Step 5 Check whether the clock cables from the two GCKS boards are cross-connected to the
transmission interface subrack.
Yes=> Go to Step 6.
No=> The fault is caused by other reasons.
Both the GCKS boards provide a group of three synchronized clock signals (8 kHz, 4 MHz, and 32 MHz)
for the transmission interface subrack where the GCTN board resides.
Step 6 Reconnect the clock cables from the two GCKS boards to the transmission interface subrack
correctly, and check whether error codes about the GOPT or GFBI board disappear.
z Yes=> The fault is located. Rectify the fault as described in the following Handling
Suggestions.
z No=> The fault is caused by other reasons.
----End
The previous analysis shows that the cause for the fault is that the clock cables from the two
GCKS boards are cross-connected to the transmission interface subrack.
To rectify the fault, reconnect the clock cables correctly.
6.5 BTS-Related Problem

6.5.1 Too high busy threshold of RACH of BTS2.0 leads to low
handover success rate.
Description
The handover success rate of BSC in the area A was very low all the time and it was about
83%. Normally the success rate of integral handover of BSC is above 90%.
Step 1 After the cell with very low handover success rate was analyzed, it was discovered the request
assignment times of TCH in the TCH performance statistic was much more than the
successful assignment. It could be thought BSC had transmitted the handover request to BTS,
just the success rate of TCH occupation was very low.

6-20 Issue 01 (2008-03-14)
Step 2 The BTS in which the cell located was BTS2.0, so it was suspected the busy threshold of
RACH of BTS2.0 was higher, resulting in difficult TCH occupation. And the access of new
channel in the course of handover was impacted, too.
Step 3 After the busy threshold of RACH was decreased from 8 to 5, the integral BSC handover
success rate was increased to about 90%.
----End
6.5.2 Uplink/downlink unbalance due to CDU failure leads to low

Description
The incoming cell radio handover success rate in BSC of cell 2 of a BTS was very low as
10% to 30%.
Fault Location
The low BSC inner incoming cell radio handover success rate is normally because of the
problem with data (e.g. CGI error in [Cell Description Data Table], lack of measurement
frequency for BA1 and BA2, adjacent frequency interference, etc.). It is also because there is
blind coverage area for high traffic or difficulty for uplink weak MS access.
Step 1 When the hardware was checked, it was discovered the state of BTS maintenance board was
normal. From the channel state it was seen TCH had been occupied for long but the times
were few. So it could be judged there was no problem with conversation data.
Step 2 The handover data were all normal based on checking.
Step 3 "Incoming Cell Handover Performance Measurement" of this cell was registered in the traffic
statistic, and it was discovered the incoming handover for all adjacent cells was bad.
Step 4 In the driving test, at a place 2km away from BTS, it was discovered the handover was tried
frequently but the handover did not succeed and returned to the original cell. If it occasionally
succeeded, call drop would immediately occurred. The downlink level was about 85 dBm in
time of handover. The dialing test with frequency lock was done for decades of times. When
it was taken as the caller, the tests all failed; and when taken as the called, the test all passed
but calling out was unavailable.
Step 5 So it was inferred the loss of CDU uplink channel was excessively big or BTS cabinet top
wiring was incorrect, resulting in weak uplink signal.
Step 6 After CDU was replaced, the incoming handover success rate was increased to over 95%.
----End

Issue 01 (2008-03-14) 6-21
6.5.3 BTS clock free oscillation leads to low handover success rate.
Description
A BSC with multi-module was configured with 3 BM. No.1 BM controlled 3 BTS30s. The
whole network handover success rate was maintained about 95%, and decreased to 90% after
running for some time.
Fault Location
If the data were not modified and the network handover success rate was changed from
normal to abnormal, it was normally because one or several BTSs were normal, and as a
result the handover success rate was impacted. The abnormal BTS could be found through the
traffic statistic and the problem could be handled according to the BTS.
Step 1 When the traffic statistic was analyzed, it was discovered the handover success rate for the
cell of 3 BTS30s and adjacent cells were generally low. When the working state of 3 BTS30s
was checked, it was discovered the clock was in the state of free oscillation, resulting in low
Step 2 The 3 BTSs located in the same group of BIE which was so suspected failed, resulting in the
losing lock of BTS clock. This group of BIE was exchanged with another BIE, but the
problem still existed.
Step 3 After the corresponding HW wires of this group of BIE were replaced and the network board
was switched, the lock loss of BTS clock still existed. That the losing lock of clocks of 3
BTSs was caused by BSC should be excluded.
Step 4 The Tx 2MHz tributary and TMU were replaced, but BTS still could not lock the clock.
Step 5 As there were no frequency meter and other test instruments in the field, the frequency offset
test could not be done on 2MHz and 13MHz clocks of BTS, and DA value could not be
precisely adjusted. TMU of all BTS working normally was checked and DA value was
recorded. Then the DA value which could be normally locked on other TMU was set in TMU
of the 3 BTS30s. After being tried for several times, the clock of 3 BTSs was in the state of
lock.
Step 6 Based on a day of observation, it was discovered 3 BTS30s ran normally. And the handover
success rate was increased to about 90%.
----End
Recommendation
Manually set DA value of BTS if there are no test instruments in the field, and observe
whether BTS is locked. It normally takes over 30 minutes. If DA value needs to be adjusted
several times, the efficiency will be very low. Set the new DA value and check TMU 2 to 3
minutes later. If at the moment the difference of discriminator displayed is the same as the set
DA value, the DA value can not finally make TMU be locked, and if not the same, TMU can
be finally locked. By this method, the adjustment speed can be increased.

6-22 Issue 01 (2008-03-14)
6.5.4 TRX performance deterioration leads to low success rate of

incoming cell handover.
Description
The handover success rate of cell A with high traffic was low (below 70%), but other indices
were normal.
Step 1 When observing the traffic statistic of this cell A, the maintenance personnel found out high
traffic was maintained all the time soon after last expansion, and the handover success rate
was low. The proportion of incoming/outgoing cell failed handovers was 4:1. As the incoming
handover success rate was not high, the handover success rate of whole cell was decreased.
Step 2 As there were few "incoming cell failed handovers (no usable channels)" and most of failed
handovers were "incoming cell failed handovers (other reasons)", so the reason of congestion
could be excluded.
Step 3 The traffic statistic task of "outgoing/incoming cell handover performance measurement" of
cell A was registered and the outgoing/incoming cell handover performance were respectively
observed.
Step 4 In the "outgoing cell handover performance measurement" task the maintenance personnel
found out most of outgoing cell failed handover were concentrated on several specified
destination cells. The reason might be the congestion of destination cells. "Incoming cell
handover failure (no usable channels)" of these destination cells was registered.
It was discovered the incoming cell failed handovers from the cell A were basically "incoming
cell failed handovers (no usable channel)". The outgoing cell failed handovers of the cell A
were located as being caused by congestion.
Step 5 In the "incoming cell handover performance measurement" task it was discovered almost
none of incoming cell handover success rates was high (all about 60%). Normally "none ofl
handover success rates is high" is due to the bad frequency planning or external interference,
resulting in bad network quality.
But based on "there is no quality problem with outgoing cell handover", the frequency
planning defect and external interference can be excluded. When observing the indices such
as the call drop rate and interference band of the cell A, maintenance personnel found out they
were all very low, so such a conclusion could be confirmed.
Step 6 Based on the data checking, there were no cells with consistent BCCH and BSIC. Meanwhile
there was no adjacent cell with very low handover success rate with cell A based on the traffic
statistic observing, so the problem with data was excluded.
Step 7 The HF data were checked. TSC was consistent with BCC and there were no other problems
with data. Meanwhile the channel occupation of TCH carrier was observed, the occupation
was found normal. So the problem with HP data could be excluded.
Step 8 The handover-related parameters were checked, they were basically consistent with the
parameters of other cells with high traffic in the downtown, so the reason of unreasonable
parameters could be excluded.
Step 9 The channel occupation was observed and several SDCCH were occupied for BCCH carrier.
It was normal for the cell with high traffic.

Issue 01 (2008-03-14) 6-23
Step 10 The channel occupation was observed in detail and a special case was found out: 4 to 6
SDCCHs were occupied at the same time and then released at the same time. Such cases took
60% of observation time. Under normal condition, there is almost no possibility that 4 to 6
SDCCH are occupied and released at the same time. It is estimated that is due to the bad TRX
performance, resulting in abnormal SDCCH occupation and release, and bad handover
performance.
Step 11 The data were checked. After it was confirmed that the "carrier mutual assistance" function
was used, the active BCCH carrier was blocked and replaced.
Step 12 The carrier was unblocked and the channel occupation and traffic statistic indices were
observed. The channel occupation was recovered normal. There was no case that several
SDCCH were occupied and released at the same time. The handover success rate in the traffic
statistic indices was increased to 95% and the problem was resolved.
----End
6.5.5 Improper antenna planning leads to low handover success

rate.
Description
The handover success rate and the traffic statistic indices for 3 cells in a BTS were very low,
especially for the handover from cell 1 to cell 2 and cell 3, the success rate was lower than
30%.
Fault Location
The low handover success rate is generally due to the assignment failure of hardware board
defect, handover data error or improper antenna planning.
Step 1 When the BTS hardware was checked, it was running normally, and there was no related
alarm. The handover-related parameter setting in the traffic statistic was normal. So the
problem with hardware and parameter setting could be excluded.
Step 2 The BTS located at the east side of north-south strike road, 700m away from the road. The
azimuth angle of 3 cells were 0°, 80° and 160°, respectively pointing to 2 directions of the
road and the open residence area in the east, and the down tilt angels of 2 cells were 7°. The
directions of 3 antennas were excessively concentrated in the design. Only the pertinence of
coverage target was considered, while no consideration was taken on the seriousness of cell
overlapping in the east of BTS. The west was only covered by the side lobe and back lobe of
3 cells. So when the user passed this section of road, it was first under the coverage of cell 1.
The signal of 3 cells was very weak when getting to the west section of road of BTS and it
fluctuated a lot. The handover statistic time and duration were set very short and the handover
was very sensitive, resulting in frequent handover failure.
Step 3 After the azimuth angles of 3 cells were adjusted to be 60°, 180° and 350°, the handover
success rate of 3 cells was immediately increased to over 90%.
----End

6-24 Issue 01 (2008-03-14)
Recommendation
The coverage target and handover should be both considered in the planning of azimuth angle
for antenna. The directions should be equally distributed to avoid serious overlapping between
cells, or blind coverage area impacting normal handover. The problem with traffic could not
be absorbed but be guaranteed through carriers.
6.6 Others
6.6.1 Locating the Problem with Low Incoming BSC Handover
Success Rate Through the Traffic Statistic
Description
For a dual frequency network, GSM900 network is of supplier S and GSM1800 network is of
Huawei. In a big adjustment on data (including modification on frequency and CGI of part
cells), GSM900 network and GSM1800 network were both reloaded with data, and it was
discovered the incoming BSC handover success rate of GSM1800 decreased.
Fault Location
As all handover threshold parameters did not change after data loading, the radio environment
was basically consistent before and after data loading, and the incoming BSC handover
success rate greatly decreased, so the problem was related to the error of configuration data.
Step 1 When the traffic statistic before after data modification was compared, it was discovered there
was little change for the following items. See Table 6-2 for the data comparison.
Table 6-2 Traffic statistic indices before/after data modification

before data after data
modification modification
incoming BSC handover request times (to GSM1800) 1885 times 1613 times
incoming BSC handover success times (to GSM1800) 1684 times 1460 times
incoming BSC handover failure times 185 times 216 times
From the data above, it was discovered that before data modification, the incoming BSC
handover request times minus incoming BSC handover success times (to GSM1800) was
bigger than the incoming BSC failure times. But after the data modification, the incoming
BSC handover request times (to GSM1800) minus the incoming BSC handover success times
(to GSM1800) was smaller than the incoming BSC failure times.
Meanwhile based on the meaning of several items in the traffic statistic above, the difference
between the incoming BSC handover request times (to GSM1800) and the incoming BSC
handover success times (to GSM1800) represented the handover failure times from the

Issue 01 (2008-03-14) 6-25
destination cell GSM1800 received the handover request to the handover success message
was reported.
The occurrence after data modification showed many incoming BSC handover requests were
abnegated before the destination cell GSM1800 received the handover request.
Step 2 After the data modification, there was no alarm for BSC equipment. There were 2 possible
reasons for loosing the incoming BSC handover request.
z There was an error for GSM900 network. The CGI of destination cell transmitted could
not be found in GSM1800 system, resulting in message abnegation.
z There was an error for GSM1800 network data. Due to CGI error in the module message
table, the module message forwarding in BSC could not find the destination cell,
resulting in the message abnegation.
Step 3 For the second reason, if there was CGI error for the cell module message table, there would
be problem for all incoming cell handovers of this cell. The BSC inner incoming cell
handover trials and BSC inter incoming handover requests in the cell performance
measurement were checked. It was discovered the 2 indices in 3 cells of BTS A were all 0, so
it was judged there was CGI configuration error for 3 cells of this BTS in the module message
table.
Step 4 The CGI of cell with configuration error was modified and the whole table was set.
Step 5 The traffic statistic data were checked. All indices were normal and the problem was resolved.
----End
6.6.2 Locating the handover Problem Through the Radio

Handover Success Rate and Handover Success Rate Difference
Description
The radio handover success rate and the handover success rate were close and low.
Fault Location
The difference between the handovers of radio handover success rate and that of handover
success rate was not big, and it showed the course in Figure 6-3 was successful.
Figure 6-3 Flow of part handovers
MS Source BSC MSC Target BSC

Radio Tx Signal Measurement
Handover Required
Handover Request
Handover Request ACK
Handover Command
Handover Command

6-26 Issue 01 (2008-03-14)
The handover success times and the handovers of 2 statistic points were much different. It
showed MS access in the destination cell was unsuccessful after it received Handover
Command. That is to say the destination cell did not receive Handover Complete, and the
source cell could not receive Clear Command delivered by MSC.
So the possible reasons for the failure at Um port include the following.
z The destination cell uplink signal was weak, so it could not be accessed.
z The destination cell was not a real one, but the dummy destination with consistent
BCCH and BSIC.
z The CGI of destination cell in the external cell table of BSC did not correspond to BCCH
and BSIC, resulting in CGI error of destination cell. After channels were activated in
other cells, it could not be accessed as it was very far from MS.
The data were checked and the case with consistent BSIC was modified to guarantee there
was no error for external cell data. The problem was resolved.
6.6.3 Sometimes the Incoming Handover may be to the Cell

Which is not Allowed by NCC
Description
The equipment of Huawei and supplier D were used in a place. BSS of Huawei was attached
under MSC of supplier E. The Flower networking was used. There were many handover
relationships between the equipment of 2 suppliers. Based on the traffic statistic result of
Huawei BSS, the general handover request times from cell E to cell Huawei were over 40%
when busy, and the handover success rate was about 80%. While the general handover request
times from cell Huawei to cell E were 800 when busy.
Step 1 Based on the test result, it was presumed there might be an error for "NCC Permitted" of cell
E.
Step 2 When the data of cell E were checked, it was discovered this parameter was set as 7 by all
cells E.
Step 3 So the case with "NCC Permitted" as 6 was added for test, and it was discovered BSIC of cell
Huawei could be resolved when the service cell was cell E.
Step 4 After this value was changed, the handovers from cell E to cell Huawei were increased from
over 30 to over 600.
----End

Issue 01 (2008-03-14) 6-27
6.6.4 Excessively High Min. Downlink Power of Candidate Cell

Leads to Handover Unavailability
Description
The BTS of Huawei and that of supplier A in a place were continuously covered but the
successful handover to the cell of supplier A was unavailable.
Step 1 The data configuration of adjacent cells of both were checked but there was no error.
Step 2 It was discovered in the test that the Rx level was low in the handover area and that was about
–92 dBm. But the compulsory handover was successful.
Step 3 As the BTS of Huawei was configured as S (1/1/1) model, the uplink/downlink unbalance was
serious. To improve the handover success rate, the downlink power of candidate cell was
adjusted as –95 dBm.
But within the handover band of this cell and supplier A, the actual downlink power level was
low. That the min. downlink power of candidate cell was set excessively high led to this cell
could not pass M regulation, resulting in unavailable handover to this cell.
Step 4 The min. downlink power of candidate cell was adjusted as –100 dBm, then the handover was
normal.
----End
6.6.5 Unsuccessful Conversion Between a Full-Rate Channel and a

Half-Rate Channel
Description
The faults that occur in a handover test are described as follows:
z If an MS occupies a full-rate channel before a handover (HO), it can only occupy a
full-rate channel after the HO. If no full-rate channel is available in the target cell that the
MS is handed over to, the HO fails.
z If an MS occupies a half-rate channel before a HO, it can only occupy a half-rate
channel after the HO. If no half-rate channel is available in the cell that the MS is handed
over to, the HO fails.
Fault Location
According to the GSM Rec. 08.08, the channel type field is carried in the ASSIGNMENT
REQUEST message and HANDOVER REQUEST message during a calling or incoming HO
procedure. This channel type field defines whether channel rates are changeable. Changeable
channel rate means that a conversion from a full-rate channel to a half-rate channel or a
conversion from a half-rate channel to a half-rate channel is allowed. If the channel rate is
unchangeable, an MS can only be assigned a channel with the same rate before and after the
handover.

6-28 Issue 01 (2008-03-14)
Step 1 Trace the signaling in the HO failure procedure.

Step 2 Check whether the channel rates are changeable according to the GSM08.08 protocol.
In the channel type field of the Handover Request and ASSIGNMENT REQUEST messages,
whether channel rates are changeable is indicated.
Yes=> The fault is caused by other reasons.
No=> The fault is located. Rectify the fault according to the following Handling Suggestions.
----End
The previous analysis shows that the conversation between a half-rate channel and a full-rate
channel fails owning to the unchangeable channel rate.
To rectify the fault, modify the configuration of the MSC to allow the change of the channel
rate.
6.6.6 Unsuccesfull Handover from Huawei BSC

Description
The faults are described as follows:
z The handover from the BSC from the other manufacturer to Huawei BSC succeeds.
z The handover from Huawei BSC to the BSC from the other manufacturer fails.
The MSC is manufactured by another company.
Fault Location
The BSC from the other manufacturer adopts the encryption algorithm A5/1 by default. But
Huawei BSC adopts the encryption algorithm A5/2 by default. During the HO from Huawei
BSC, the encryption algorithm is not specified in the HO command sent by Huawei BSC and
the default encryption algorithm A5/2 is used to access the BSC from the other manufacturer.
Thus, the HO fails.
Check whether the encryption algorithms used by the two BSCs participating in the inter-BSC
HO are identical.
Yes=> The fault is caused by other reasons.
No=> The fault is located.
The previous analysis shows that the fault is caused by different settings of encryption
algorithms used by the two BSCs participating in the inter-BSC HO.
To rectify the fault, set the encryption algorithm of the two BSC to the same one.

Issue 01 (2008-03-14) 6-29
6.6.7 Unsucessful Inter-BSC Handover

Description
The faults are described as follows:
z The handover from the BSC from the other manufacturer to Huawei BSC fails.
z The handover from Huawei BSC to the BSC from the other manufacturer fails.
Fault Location
The probable causes are as follows:
z The configuration of the neighboring cells for the BSC from the other manufacturer is
incorrect. Thus, incorrect channel numbers of the neighboring cells under the control of
the BSC from the other manufacturer are sent to Huawei BSC. The handover from the
BSC from the other manufacturer to Huawei BSC fails.
z The Early Classmark Sending Control (ECSC) function of the cells under the control of
Huawei BSC is not enabled, and the MSC does not send the CLASSMARK REQUEST
message to update the classmark. Thus, the calls that are initiated from the cell under the
control of Huawei BSC fail to be handed over to the 1800 MHz cell under the control of
other BSC.
To locate the previous faults, do as follows:
Step 1 Reconfigure the neighboring cells of the BSC from the other manufacturer and check whether
the HO is successful.
Yes=> The incorrect configuration of the neighboring cells under the control of the BSC from
the other manufacturer is one reason for the faults. Go to Step 2.
Step 2 Enable the ECSC function for the cells under the control of Huawei BSC and check whether
the HO to the M1800 MHz cell is successful.
Yes=> The other reason for the faults is that the ECSC function is not enabled for the cells
under the control of Huawei BSC. Rectify the fault according to the following Handling
Suggestions.
----End
The previous analysis shows that the causes for the faults are as follows:
z The configuration of the neighboring cells of the BSC from the other manufacturer is
incorrect.
z The ECSC function of the cells under the control of Huawei BSC is not enabled.
To rectify the fault, do as follows:
z Reconfigure the neighboring cells for the BSC from the other manufacturer.
z Enable the ECSC function for the cells under the control of Huawei BSC.

6-30 Issue 01 (2008-03-14)

01-06 Troubleshooting For Handover

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

01-06 Troubleshooting For Handover

Hochgeladen von

Copyright:

Verfügbare Formate

M900/M1800 Base Station Subsystem

Troubleshooting Manual Contents

6 Troubleshooting for Handover ...............................................................................................6-1

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

Figure 6-1 Signaling flow of typical handover failure .......................................................................................6-8

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

6 Troubleshooting for Handover

About This Chapter

The following table lists the contents of this chapter.

6.1 Overview Introduces the main idea of this chapter.

Huawei Proprietary and Confidential

6.1.1 Failure Classification

6.1.2 Tool for locating the faults

Huawei Proprietary and Confidential

6.2 Trouble Handling

Huawei Proprietary and Confidential

6.2.2 Locating Procedure of No Handover Starting Up

The handover threshold is set too low

The relationship of adjacent cell is not set

The hysteresis is set unreasonable

The parameter N-P is set unreasonable

Huawei Proprietary and Confidential

6.2.3 Locating of Hardware Failure

6.2.4 Locating of Data Configuration Problem

Huawei Proprietary and Confidential

6.3 MSC Handover Problem

6.3.2 MSC Data Configuration Error Leads to the Handover

Huawei Proprietary and Confidential

6.3.3 Improper BSC Parameter Setting of Company Causes Low

Huawei Proprietary and Confidential

Figure 6-1 Signaling flow of typical handover failure

S MSC Huawei MSC

Prepare Handover (MAP)

Prepare Handover ACK (MAP)

Handover Failure (MAP)

Huawei Proprietary and Confidential

Figure 6-2 Signaling flow of successful handover

Prepare Handover (MAP)

Prepare Handover ACK (MAP)

6.3.4 Signaling Matching Problem Leads to Handover Failure

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

6.3.5 Equipment Matching Problem Between Different Supplier

Huawei Proprietary and Confidential

6.4 BSC Problems

Huawei Proprietary and Confidential

6.4.2 BSIC modification leads to low handover success rate.

Huawei Proprietary and Confidential

6.4.3 Consistent BCCH and BSIC lead to failures of TCH

Huawei Proprietary and Confidential

Huawei Proprietary and Confidential

6.4.4 Cell BCCH modification leads to lots of incoming handover

Huawei Proprietary and Confidential

6.4.5 CGI error of cell description data table leads to no incoming

Huawei Proprietary and Confidential

6.4.6 Failure in Loading Applications and Data to the Standby

Table 6-1 Meanings of the blinking indicators of the MCP card

Blinking Frequency Meaning

Huawei Proprietary and Confidential

6.4.7 Voice Noise

Huawei Proprietary and Confidential