Product name

GSM BSS Network KPI (Handover Success Rate) Optimization Manual

Keywords

Handover Success Rate

Abstract

By analyzing the factors that affect the Handover Success Rate (HOSR) on the BSS side, this document provides a method of quickly locating the cause of low HOSR or slow handover. In addition, this document provides measures for optimizing the HOSR, thus meeting field engineers' working requirements for solving handover problems. This document is used for optimizing the KPIs of network performance and monitoring the network quality.

Acronyms and Abbreviations

AbbreviationsExpansion

AMRAdaptive Multi Rate

BCCHBroadcast Control Channel

BERBit Error Ratio

BQBad Quality

BSCBase Station Controller

BSICBase Station Identity Code

CDUCombining and Distribution Unit

CICCircuit Identification Code

HOSRHandover Success Rate

KPIKey Performance Index

MRMeasure Report

MSMobile Station

NENetwork Element

QoSQuality of Service

RQIRadio Quality Indication

TATiming Advance

Table of Contents

71 Basic Principles

71.1 Definition

71.2 Theory

71.3 Recommended Formula

81.4 Measurement Point

102 Influencing Factors

103 Analysis Process and Optimization Method

103.1 Process of Analyzing Handover Problems

113.1.1 General Process of Locating a Handover Problem

133.2 Methods for Optimizing Handover Problems

133.2.1 Classification of Handover Problems

143.2.2 Hardware and Transmission Failure

163.2.3 Improper Data Configuration

183.2.4 Congestion of the Target Cell

203.2.5 Clock Problems

213.2.6 Interference Problems

223.2.7 Coverage Problems, and Uplink and Downlink Imbalance

233.2.8 Failed Inter-BSC/Inter-MSC Handovers

243.2.9 Automatic Neighboring Cell Optimization

253.2.10 Testing Tool Selection and Testing Suggestions

253.2.11 Configuration Suggestions for Tests on the Existing Network

254 Optimization Cases

254.1 A Handover Fails Because the BSIC Cannot Be Decoded

264.2 A Handover Fails Because Frequency Sequencing of the MS Is Different from That of the BSC

264.3 A Handover Fails Due to Unreasonable Parameter Configuration

264.4 The Number of Failed Incoming BSC Handovers Increases Because the Handover Request Does Not Contain Class Mark 3

274.5 An Incoming BSC Handover Fails Because the A Interface Phase Flag Is Set Wrongly

274.6 Because the Idle Burst Is Enabled, the Interference Increases, the Receiving Quality Decreases, and the HOSR Becomes Low

274.7 Different HOSRs Resulting from Different Cause Values Contained in the Clear Command Messages Sent by Different Switches

285 Information Feedback

285.1 TEMS Log Files About Problem Cells

285.2 Requirements of Configuration Data of the Existing Network and Traffic Measurement Feedback

List of Tables

11Table 3-1 List of handover timers commonly used

List of Figures

9Figure 1-1 Signaling process of intra-BSC handover

10Figure 1-2 Signaling process of inter-BSC handover

11Figure 3-1 Flow chart of locating a handover problem

11Figure 3-2 Flow chart and timer description

11Figure 3-3 Flow chart of automatic neighboring cell optimization

GSM BSS Network KPI (Handover Success Rate) Optimization Manual

1 Basic Principles

1.1 Definition

Handover is an important function in mobile communication systems. As a means of radio link control, handover enables users to communicate continuously when they traverse different cells. The HOSR is the ratio of the number of successful handovers to the number of handover requests. The major purpose of handover is to guarantee call continuity, improve speech quality, reduce cross interference in the network, and thus provide better services for mobile station (MS) subscribers.

1.2 TheoryThe HOSR is an important KPI of the call hold type. According to the processes, this KPI can be divided into two types: Handover Success Rate and Radio Handover Success Rate. According to the relations between involved network elements (NEs), this KPI can be divided into three types: Success Rate of Intra-BSC Handover, Success Rate of Incoming BSC Handover, and Success Rate of Outgoing BSC Handover. The HOSR is an important KPI assessed by operators because the value of the HOSR directly affects the user experience.

1.3 Recommended Formula

The HOSR is obtained through traffic measurement. The recommended formula for calculating this KPI is as follows:

Handover Success Rate = Successful Handovers/Handover Requests Radio Handover Success Rate = Successful Handovers/Handover CommandsFor details, refer to the GSM BSS Network KPI (TCH Call Drop Rate) Baseline.

1.4 Measurement Point

Figure 1-1 Signaling process of intra-BSC handover

Figure 1-2 Signaling process of inter-BSC handover

The measurement points illustrated in Figure 1-1 and Figure 1-2 are as follows:

A1Measurement point of Incoming Internal Inter-Cell Handover Requests and Internal Intra-Cell Handover RequestsB1Measurement point of Incoming Internal Inter-Cell Handover Responses (Incoming Internal Inter-Cell Handovers) and Internal Intra-Cell Handover CommandsC1Measurement point of Successful Incoming Internal Inter-Cell Handovers and Successful Internal Intra-Cell HandoversA2Incoming External Inter-Cell Handover Requests

B2Incoming External Inter-Cell Handover Responses (Incoming External Inter-Cell Handovers)

C2Successful Incoming External Inter-Cell HandoversA3Outgoing External Inter-Cell Handover RequestsB3Outgoing External Inter-Cell Handover Commands (Outgoing External Inter-Cell Handovers)C3Successful Outgoing External Inter-Cell Handovers

Replaced with corresponding measurement points, the formulas for calculating different types of HOSR can be as follows:

Success Rate of Handover: (C1 +C3)/(A1 +A3)Success Rate of Radio Handover: (C1 +C3)/(B1 +B3)

Success Rate of Intra-BSC Handover: C1/A1Internal Radio Handover Success Ratio per cell: C1/B1Success Rate of Incoming BSC Handover: C2/A2Success Rate of Incoming BSC Radio Handover: C2/B2Success Rate of Outgoing BSC Handover: C3/A3Success Rate of Outgoing BSC Radio Handover: C3/B3( Note:

If the BSC receives the Clear Command message sent by the MSC during an inter-BSC handover, the current version does not count this case as a failed handover. If a subscriber hangs up the phone during an intra-BSC handover, the current version counts this case as a failed handover.

2 Influencing Factors

According to the cases and experience of the existing network, the factors that influence the handover include the following types:

Hardware and transmission failures

Data configuration

Congestion

Coverage problems, and uplink and downlink imbalance

Interference

Clock problems

Failed inter-BSC/inter-MSC handovers

For details about all these factors, see section 3.2 "Methods for Optimizing Handover Problems."3 Analysis Process and Optimization Method

This chapter provides solutions to the problems about the handover when the following conditions are all met: The data configuration complies with the baseline of related parameters. There is no problem about the engineering quality.

The coverage is good.

3.1 Process of Analyzing Handover Problems

Generally, there are the following types of handover problems:

Call drops due to no timely occurrence of handovers Failed handovers Frequent (ping-pong) handovers Poor downlink quality caused by slow handoversThese problems directly result in poor experience of end users, which is inclined to cause complaints. Therefore, it is necessary to work out a method for optimizing the HOSR quickly or even automatically to improve the network quality and user experience.

3.1.1 General Process of Locating a Handover Problem

Figure 3-1 shows the general process of locating a handover problem.

Figure 3-1 Flow chart of locating a handover problem

3.2 Methods for Optimizing Handover Problems

Generally, handovers occur between two cells. The relationship between cells may be:

Between different BTSs in a BSC In the same BTS in a BSC Between different BSCsTherefore, after you know how to locate and optimize the handover problems between two cells, you can solve the handover problems in an entire network.

Handover problems may be caused by:

Hardware and transmission failures (bad TRXs or problems about the combiner of the feeder and antenna system)

Improper data configuration

Congestion problems

Clock problems

Interference problems

Coverage problems, and uplink and downlink imbalance

If a low HOSR occurs, do as follows:

(1) Identify the problem.

(2) Troubleshoot the problem based on the factors such as hardware, data configuration, congestion, clock, interference, and coverage

(3) Improve the HOSR according to the automatic optimization of neighboring cells.

3.2.2 Classification of Handover Problems

I. Classification DescriptionBefore analyzing the problem about the HOSR, determine the following points about handover classification:

(1) Decide the scope of the failed handover. If the low HOSR occurs in all the cells, check the problem from such aspects as the handover feature parameters, the A interface circuits, and the BSC clock.

(2) If the low HOSR does not occur in all the cells, find out the TOP n poorest cell. Then, proceed with the following steps specific to the cell.

(3) Distinguish whether there is any problem in the wireless interfaces according to the differences between the HOSR and the Radio HOSR. The Radio HOSR must be greater than or equal to the HOSR. If the HOSR is much smaller than the Radio HOSR, analyze the problems about the terrestrial links and the capacity. If the HOSR is a little different from the Radio HOSR, consider the problems about the coverage and the interference.

(4) Query the success rates of outgoing/incoming external/internal inter-cell handovers in the handover performance measurement to analyze whether a failed outgoing or incoming handover occurs. Analyze the performance measurement of outgoing and incoming external inter-cell handovers of the faulty cell. From the performance measurement of outgoing external inter-cell handovers, find out to which cells the handover fails. Analyze counters of the cells where incoming handovers fail, such as the Failed Incoming External/Incoming Inter-Cell Handovers (No Channel Available), the Traffic Volume on TCH, and the Congestion Ratio on TCH(All Channels Busy), to decide whether the congestion of the target cell causes the failed handover.

(5) Query such counters as the TRX Availability and the TCH Availability of the target cell to check whether any device is faulty.

(6) Query relevant alarms to analyze whether any terrestrial link device is faulty.

II. Traffic Measurement AnalysisBy registering and analyzing the following counters, you can decide the scope and the basic cause of a handover problem:Cell Level

Incoming Internal Inter-Cell Handover Measurement per CellOutgoing Internal Inter-Cell Handover Measurement per CellIncoming External Inter-Cell Handover Measurement per CellOutgoing External Inter-Cell Handover Measurement per CellIncoming Inter-RAT Inter-Cell Handover Measurement per CellOutgoing Inter-RAT Inter-Cell Handover Measurement per CellMeasurement of MRs upon Handover Initiation per CellChannel Assignment Failure Measurement per CellTraffic Volume on TCH

3.2.3 Hardware and Transmission Failure

Symptom: The alarm system reports relevant alarm information. To rectify a hardware fault, clear the alarms about the hardware failure. If the alarms are cleared, check the traffic measurement information and analyze handover counters.

A hardware failure may involve the following hardware devices:

BTS transmission management unit

BTS TRXs

BTS combining and distribution unit

BTS feeder and antenna system

I. Handling Process

(1) Check the data configuration of the hardware. If none of the data configuration of the faulty cell and its neighboring cells is changed recently, consider whether the handover problem is caused by a BTS hardware failure.

If the handover problem occurs in only one cell under the BTS, consider whether the problem is caused by the hardware failure of the cell. If a TRX is damaged, a call fails to be handed over to this TRX.

If a similar problem also occurs in a co-site neighboring cell of this cell, consider whether the problem is caused by the failure of the common hardware of the cells, for example, the TMU failure.You can block some TRXs to verify the preceding problems. If the HOSR returns to normal after a TRX is blocked, check whether this TRX is faulty or whether the CDU or the antenna related to this TRX is faulty.

If the uplink and downlink signals of a TRX are unbalanced, handover problems such as frequent handover and lower HOSR often occur.

(2) Trace the Abis interface, and observe whether the signaling of the faulty cell is normal and whether the uplink and downlink receiving quality in the measure report is good. For detailed operations, refer to the M900&M1800 BSS Signaling Analysis Manual.

If the receiving level quality of half rate or full rate channel in the measurement report is poor, the hardware of the cell is faulty or signaling cannot interact normally due to serious interference in the cell. As a result, a handover problem occurs.

II. Traffic Measurement Analysis

Omitted.

III. Alarm AnalysisObserve whether any alarms with the following IDs are reported. If yes, refer to the BSS Alarm Guide to handle the alarms.Alarm ID and Name

4102 TRX LAPD Link Interrupt Alarm

4104 TRX Config Mismatch Alarm

4108 Radio link critical Alarm

4114 TRX Interior I/O Alarm

4136 TRX Hardware Critical Alarm

4144 TRX VSWR alarm

4192 TRX communication alarm

4714 E1/T1 Local Alarm

5286 CDU Level 1 VSWR Critical Alarm

5284 CDU Level 2 VSWR Critical Alarm

5326 Level 1 VSWR alarm

5328 Level 2 VSWR alarm

3.2.4 Improper Data Configuration

I. Handling ProcessSymptoms: An MS does not initiate any handover or frequently initiates handovers, which affects the HOSR.

The handover parameters control the handover decision algorithm. If the handover parameters are set improperly, the MS may not initiate any handover or frequently initiates handovers. In this case, consider the cause from the following aspects:

Whether the PBGT HO Threshold in the data configuration is set properlyAvoid difficult handovers due to too great values of the handover thresholds or frequent handovers due to the too small values. Proper settings can prevent ping-pong handovers. For detailed settings of the thresholds, refer to the GSM BSC6000 Performance Parameter Baseline (V900R008) (Chinese/English) V2.0. Do not set the thresholds to the values deviating greatly from the baseline values.

Whether the parameters related to the handover candidate cell in the data configuration are set properly

Avoid the case that the MS cannot be handed over to a neighboring cell due to the missed setting of the neighboring cell.

Whether the handover hysteresis parameters in the data configuration are set properly

Avoid difficult handovers due to too large values of the handover hysteresis parameters or frequent handovers due to too small values.

Whether the N and P counters in the data configuration are set properly

Avoid insensitive handover decision or difficult handovers due to the too large values of the parameters, or the case that the target cell of a handover is not the optimal due to the too small values of the parameters.

Avoid configuring the neighboring cells that share the same BCCH or the same BSIC for a cell.Abnormal circuit identification code (CIC) circuits may cause failed handovers.

For example, the CIC circuit allocated through a Handover REQ message received by the target BSC is identified in the BLOCK state in the target BSC. Therefore, the BSC responds to the MSC with a Handover Failure message whose cause value is Requested Terrestrial Resource Unavailable. In this case, check the statuses of the circuits at the two sides of the A interface and ensure that the circuits are in the same state.

You can trace the A interface signaling on the maintenance console to check whether the failed handover is caused by the inconsistency of the circuit statuses. Do as follows:

(1) Trace the A interface signaling.

(2) Filter the Handover Failure message.

(3) Check whether the cause value is Requested Terrestrial Resource Unavailable.

II. Handover timer

When an abnormal handover occurs, promptly check the handover timer and ensure that the handover timer is not less than the preset default value.

Table 3-1 lists the handover timers commonly used.

Table 3-1 List of handover timers commonly used

Timer NameDefault Value (ms)Description

T710000Timer for sending outgoing external inter-cell handover requests and handover commands

T810000Timer for running outgoing external inter-cell handover commands and handover completion or clearance

T310310000From the time when an intra-cell or inter-cell handover command is executed to the time of an intra-cell or inter-cell handover completion

T310570During an asynchronous handover, from the time when the BTS sends the MS a physical message to the time when the BTS receives the set asynchronous balanced mode (SABM) from the MS

T3124320During an asynchronous handover, from the time when the MS sends the network a handover access Burst message to the time when the MS receives a physical message from the BTS

Figure 3-2 shows the flow chart and the description of the timers.

Figure 3-2 Flow chart and timer description

III. Traffic Measurement AnalysisOmitted.

IV. Alarm AnalysisOmitted.

3.2.5 Congestion of the Target Cell

I. Handling ProcessSymptoms: After an MS initiates a handover request, the handover fails because no channel is obtained.

The possible causes of cell congestion are:

The number of users in the cell soars and exceeds the designed number.

Improper settings of the network optimization parameters cause redundant users in the cell.

Improper settings of the handover parameters cause the increase of the users accessing the cell.

After a handover fails because congestion occurs in the target cell, penalize the target cell to prevent the MS from retrying to be handed over to this target cell. It is recommended that Penalty Allowed be set to Yes.

Check whether the channel the congested cell is normal. If a TRX is faulty or a channel is abnormal, rectify the relevant faults.

If full rate channels cannot be converted to half rate channels, it is recommended that you change the channel attributes on the BSC6000 local maintenance terminal (LMT). That is, set the TCH Rate Adjust Allow of all the TRXs under this cell to Yes. If the full rate channels can be converted to half rate channels, properly reduce the value of TCH Traffic Busy Threshold(%) to allocate half rate channels ahead of time and thus increase the system capacity. If the preceding methods cannot solve the congestion problem, divide the cell or expand the capacity of the cell. Since capacity expansion cannot be completed in a short time, you can set Channel Type to 1 or 2 to reserve channels for handovers. In this way, the failed handovers caused by congestion can be reduced, and thus the HOSR improves.

II. Traffic Measurement Analysis(1) Register the measurement unit Channel Assignment Failure Measurement per Cell. By analyzing the traffic measurement, you can be familiar with the number of the times that all the channels are busy or that none of the channels is configured when the BSC allocates SDCCHs, TCHFs, or TCHHs in the processes such as immediate assignment, assignment, internal intra-cell handover, incoming internal inter-cell handover, and incoming external inter-cell handover.

(2) Change relevant parameters for the target cell according to the cause of the failed handover.

If the failed handover is caused by the SDCCH congestion, set SDCCH Dynamic Allocation Allowed to Yes.If the failed handover is caused by the TCH congestion, reduce the value of the TCH Traffic Busy Threshold(%) to allocate half rates ahead of time and thus relieve congestion. In addition, you can set Channel Type to 1 or 2 to reserve channels for handovers.SNMeasurement Counter

1Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Immediate Assignment Procedure (SDCCH)

2Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Immediate Assignment Procedure (TCHF)

3Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Immediate Assignment Procedure (TCHH)

4Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Assignment Procedure (TCHF/TCHH)

5Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Internal Intra-Cell Handover Procedure (SDCCH)

6Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Internal Intra-Cell Handover Procedure (TCHF/TCHH)

7Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Incoming Internal Inter-Cell Handover Procedure (SDCCH)

8Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Incoming Internal Inter-Cell Handover Procedure (TCHF/TCHH)

9Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Incoming External Inter-Cell Handover Procedure (SDCCH)

10Channel Assignment Failures (All Channels Busy or Channels Unconfigured) in Incoming External Inter-Cell Handover Procedure (TCHF/TCHH)

11Channel Assignment Failures (All Channels Busy or Channels Unconfigured) (SDCCH)

12Channel Assignment Failures (All Channels Busy or Channels Unconfigured) (TCHF)

13Channel Assignment Failures (All Channels Busy or Channels Unconfigured) (TCHH)

14Channel Assignment Failures (All Channels Busy or Channels Unconfigured) (TCH)

III. Alarm AnalysisOmitted.

3.2.6 Clock Problems

I. Handling ProcessAsynchronization and instability of the BTS clock are major causes of call drops during a handover. Therefore, keep the BTS clock stable. Otherwise, handovers often fail and call drops occur frequently.

A 13 MHz unlocked alarm is generated. The BSIC cannot be decoded. The HOSR of the concerned cells decreases.

The clock source is abnormal and deviation may occur between the BTS clock and other BTS clocks. As a result, MS abnormalities may occur during handovers.

To solve the problems about the unlocked clock and abnormality of the clock source, do as follows:

(1) Check alarms. That is, check whether there is a 2214 E1 local alarm or 2216 E1 remote alarm. If there is, follow the concerned alarm handling manual to handle the alarm. Then, observe the HOSR.

(2) Check the transmission link clock of the BTS. That is, use a frequency meter to test the frequency deviation of the transmission link clock of the BTS. If the frequency deviation is greater than or equal to 0.05 ppm, the transmission link clock is abnormal, and the E1 or the optical transmission link may be faulty or the clock source is faulty. Rectify the transmission link fault through link-by-link self-loop until the alarm handling is complete.

(3) If the clock problem is not solved, reset the BTS (level-4) and observe alarms and the HOSR.

(4) If the problem remains unsolved, replace the TMU.

II. Traffic Measurement AnalysisOmitted.

III. Alarm AnalysisObserve whether any alarms with the following IDs are reported. If yes, refer to the BSS Alarm Guide to handle the alarms.Alarm ID and Name

4154 TRX main clock alarm

4156 TRX slave clock alarm

4184 TRX Clock Critical Alarm

4708 Clock Reference Abnormal Alarm

4732 TMU clock critical alarm

4734 Master TMU clock alarm

4760 13M Maintenance Alarm

3.2.7 Interference Problems

I. Handling ProcessSevere interference in the network is inclined to cause the decrease in the receiving quality. As a result, interference handovers or handovers in poor quality increase, the proportion of the power budget (PBGT) decreases, and the quality of service (QoS) of the existing network is reduced to some degree. Thus, user experience and the HOSR are affected.

Currently, the common interferences are intra-frequency and inter-frequency channel interferences, Unicom CDMA interference, and mass multiplexing of the EGSM. If the idle Burst function is not manually disabled after it is enabled, the interference of the entire network rises, the noise floor increases, and the quality of the entire network decreases, thus affecting the HOSR.

The remote source signals of some optical fiber repeaters are inclined to cause intra-frequency interference. Therefore, during optimization, you need to check the frequency of the source signals and the frequencies of the cells close to the repeaters so that the frequency space is over 400 kHz.

If there is a repeater in the serving cell, do as follows:

(1) Choose Cell Software Parameters > Directly Magnifier Site Flag.

(2) Select Yes.

To solve interference problems, do as follows:

(3) Find out the cell or the frequency where large interference exists through drive tests.

(4) Optimize the radio frequency (RF) by the following regular means:

Adjust the tilt angle of the antenna.

Replace the frequency.

Change the transmit power and the coverage area of the cell.

You can also register the measurement results of interference fringes by auxiliary means to estimate downlink interferences.

For more details about the solutions of interference problems, refer to the GSM Interference Analysis Guide.

II. Traffic Measurement AnalysisOmitted.

III. Alarm AnalysisOmitted.

3.2.8 Coverage Problems, and Uplink and Downlink Imbalance

I. Handling ProcessSymptoms of signal coverage problems: The HOSR is low. Call drops occur frequently. There are noises and metallic rings during conversations. The voice quality and the user experience are poor. There are three types of signal coverage problems:

Low HOSR caused by cross coverage

Low values of the fringe thresholds, the large BTS power, and an improper tilt angle cause cross coverage, thus forming intra-frequency interference and affecting the HOSR.

Failed handovers caused by island effects

For example, the coverage area of the serving cell is much larger than that of its neighboring cells, and the neighboring relation between the serving cell and the neighboring cells of its neighboring cells is not configured. In this case, failed handovers easily occur at the fringe of the serving cell.

Loopholes formed due to weak coverage

This section does not describe it in detail.

To solve signal coverage problems, do as follows:

(1) Find out the coverage problems in the existing network through drive test reports of network optimization.

(2) Optimize the RF.

The low HOSR caused by uplink and downlink imbalance generally occurs when uplink signals are weak. For example, there are problems in the hardware such as the CDU combiner, the uplink channel loss is large, the uplink signals are weak, and the success rate of incoming external inter-cell handover is low. This low HOSR is generally caused by data problems (such as CGI errors in the cell description data table, lack of measurement frequencies in BA list 1 and BA list 2, or intra-frequency and inter-frequency interferences), coverage dead zones in high traffic, or MS access difficulties due to weak uplink signals. To test and analyze the low HOSR caused by uplink and downlink imbalance, do as follows:

(3) Check whether the hardware and maintenance boards of the relevant cell are in the normal state, and whether there are any alarms about hardware failures and the standing wave ratio (SWR). Refresh the channel status and check whether the TCHs can be normally occupied.

(4) After hardware and channel problems are solved, check the handover data configuration and ensure that the handover data complies with the parameter baseline.

(5) Register the traffic measurement results of cell-level handovers. Check whether the HOSR between some cells is always low.

1)Make a field test for the cells where the HOSR is always low. That is, perform a switchover and lock the main BCCH to act as the calling and called parties respectively. Then decide the uplink and downlink problems accordingly.

2)If the uplink loss is large, it is recommended that you replace the combiner to carry out an observation and a test.

Coverage problems and uplink and downlink imbalance are solved through RF optimization. For detailed analysis, refer to the GSM BSS Network KPI (Coverage Problems) Optimization Manual (V1.0).

II. Traffic Measurement AnalysisRegister the measurement unit Uplink-and-Downlink Balance Measurement per TRX about the cells where the HOSR is low. Collect the uplink and downlink balance cases and carry out analysis.

III. Alarm AnalysisOmitted.

3.2.9 Failed Inter-BSC/Inter-MSC Handovers

I. Handling ProcessSymptoms: Inter-BSC or inter-MSC handovers fail.

The possible causes are that:

The data of the cells relevant to inter-MSC handovers is set wrongly.

The data of the cells relevant to the inter-BSC handovers is set wrongly.

The MSC and the BSC have different understandings of A interface handover signaling. As a result, the cooperation at the A interface fails.

The clocks between BSCs are not synchronous.

To solve this problem, do as follows:

(1) Check whether the MSC data relevant to the cells where handovers fail is set correctly, for example, the CGIs and the office direction of the cells. If any data is set incorrectly, correct it and observe whether handovers succeed.

(2) Check whether the neighboring cells of the source and the destination BSC are set correctly. If there is any abnormality, correct it and observe whether handovers succeed.

(3) Trace A interface signaling. Check whether there is any abnormality in the signaling cooperation of the handover process between the source BSC and the MSC, and between the MSC and the destination BSC. For example, check whether such a process that the MSC abnormally releases a handover exists. If there is any abnormal process, find out the cause and observe whether handovers succeed after such a problem is solved. For detailed signaling analysis, refer to the M900&M1800 BSS Signaling Analysis Manual.

(4) Check whether the source and the destination BSCs relevant to handovers are locked with the clock of the upper-level MSC. If not, find out the cause that the clock cannot be locked. Observe whether handovers succeed after this problem is solved.

II. Traffic Measurement AnalysisOmitted.

III. Alarm AnalysisOmitted.

3.2.10 Automatic Neighboring Cell Optimization

Currently, automatic neighboring cell optimization is the best method for optimizing the HOSR. The method has been fully verified in the new functions of the MTN project. This optimization method is to choose optimal neighboring cells for the serving cell through many times' neighboring cell selection and tailor. This method can make the serving cell have neighboring cells more close to the traffic model, thus avoiding failed handovers and call drops due to forced configuration of neighboring cells according to geographical locations.

The premise of automatic neighboring cell optimization is to exclude objective factors such as hardware problems, cross coverage, and uplink and downlink imbalance. After that, make it clear to which neighboring cell the success rate of handovers from the serving cell is lower, and then optimize this neighboring cell. The optimization method includes two types: parameter adjustment and neighboring cell adjustment.

The process of automatic neighboring cell optimization is as follows:

(1) According to geographical locations, set as many neighboring cells as possible for the serving cell. The upper limit is 32.

(2) Register the measurement unit GSM Cell to GSM Cell Outgoing Handover Measurement, which period is 15 minutes.

(3) Observe the traffic measurement results. Exclude the cells that meet any of the following conditions from the neighboring cells:

The HOSR is lower than 30%.

The call drop rate is higher than 80%.

The handovers are relatively fewer according to the traffic, for example, about 30 handovers every hour.

(4) After a neighboring cell is excluded, re-add a new neighboring cell according to the timing advance (TA) principle from small to large, and repeat the preceding steps.

Figure 3-3 shows the process of automatic neighboring optimization.

Figure 3-3 Flow chart of automatic neighboring cell optimization

The TA is limited to six times as many as the average distance between sites. Do not consider the cells with the TA beyond this threshold. You can flexibly set the lower limit of the HOSR and the fewer limit of handover times.

3.2.11 Testing Tool Selection and Testing Suggestions

Generally, choose the industry-accepted and large-scale used TEMS as the testing tool. For the cells where the HOSR is low, you need to carry out drive tests. In drive tests, the actual move modes and habits of terminal users can be simulated. Therefore, drive tests play an important role in neighboring cell optimization. Drive tests can avoid such risks as few handovers or low HOSR caused by the addition of improper neighboring cells only according to geographical location distribution on a map. Lay stress on and analyze any handover abnormality during a drive test. Any of these abnormalities may be a cause of low HOSR.

3.2.12 Configuration Suggestions for Tests on the Existing Network

To configure the existing network according to different scenarios, refer to the GSM BSC6000 Performance Parameter Baseline (V900R008) (Chinese/English) V2.0. In the case of the low HOSR, focus on checking the data configuration greatly different from the parameter baseline.

4 Optimization Cases

4.1 A Handover Fails Because the BSIC Cannot Be Decoded

During a drive test in an office, it is found that an MS cannot decode the BSIC of a neighboring cell. As a result, the MS cannot initiate a handover even when the MS detects good levels of the neighboring cell.

After analysis, it is learned that the PTCCH points to a wrong memory zone. As a result, some MSs misunderstand that this channel is an FCCH, thus fail to synchronize the SCH and fail to decode the BSIC. This product problem must be solved through version upgrade.

4.2 A Handover Fails Because Frequency Sequencing of the MS Is Different from That of the BSC

In an office, field engineers check the TEMS drive test file and find that the cells of the main BCCH at the EGSM cannot be handed over to the PGSM. It is checked that the rule of sequencing frequencies at the MS side is different from that at the BSC side. When the serving cell is at the EGSM and is configured with 1,800 neighboring cells, the MS sorts the EGSM first and then the 1,800 neighboring cells, whereas the BSC does in the contrary order. Thus, the different sequences of neighboring cells at the BSC and MS sides cause a failed handover.

To mitigate such a problem, disable the Way of BA Delivery Optimized.

4.3 A Handover Fails Due to Unreasonable Parameter Configuration

It is found in an office of BSC6000V9R8 that no bad quality (BQ) handover can occur. It is checked that the Inter-cell HO Hysteresis of the serving cell is set to 63. The result of checking codes shows that the level of the serving cell is equal to a value increased by 63 grades if Inter-cell HO Hysteresis is set to 63 when BQ HO Margin is set to the default value. Thus, the calculated level of the serving cell is always larger than the level of any neighboring cell. As a result, the handover cannot be initiated.

To solve such a problem, increase the value of BQ HO Margin to 127.

4.4 The Number of Failed Incoming BSC Handovers Increases Because the Handover Request Does Not Contain Class Mark 3

In a cell at the BSC boundary, the frequency of the main BCCH is configured as the PGSM and that of the other TRXs is configured as the EGSM. Symptoms: The number of failed incoming BSC handovers increases. The cause value is No Available Channel. The BSC6000 decides the frequency supporting capability of an accessing MS according to class mark 3. If there is no class mark 3, the BSC considers that the MS supports only the frequency of the main BCCH. If the Handover Request does not contain class mark 3 and the frequency of the other TRXs in the cell is different from that of the main BCCH, accessing MSs are all allocated to the main BCCH. This causes congestion and thus handovers fail. After the frequency of the other TRXs is changed to the PGSM, the number of failed incoming BSC handovers caused by no available channel decreases to 0. The problem is mitigated. According to the protocol, however, class mark 2 also has a field for identifying whether an MS supports the EGSM or the RGSM (incapable of identifying the DCS1800). Such a problem often occurs because some MSCs carry only class mark 2 in the Handover Request or because an MS in a cell with the EGSM enabled does not report class mark 3.

To solve such a problem, upgrade the software version.

4.5 An Incoming BSC Handover Fails Because the A Interface Phase Flag Is Set Wrongly

During an incoming BSC handover, after the BSC returns a Handover Request Ack message to the MSC, the MSC returns a Clear Command immediately to clear call resources. The clearance cause is Equipment Failure. The system responds to the MSC with a Handover Request Ack message containing the speech version IE only when the A Interface Tag in the BSC attributes is GSM_Phase_2+ and the BSC software parameter SpeechVer Send Flag In Ho Req Ack is set to Yes. Since the A Interface Tag in the data configuration is GSM_Phase_2, the Handover Request Ack message does not contain the speech version IE. Therefore, the MSC considers that this message is illegal and sends a Clear Command.

To mitigate such a problem, set the A Interface Tag in the BSC attributes to GSM_Phase_2+ and the BSC software parameter SpeechVer Send Flag In Ho Req Ack to Yes.

4.6 Because the Idle Burst Is Enabled, the Interference Increases, the Receiving Quality Decreases, and the HOSR Becomes Low

After an office is cut over, the drive test results show that the network quality decreases obviously by about 3% to 4%. After it is confirmed that the problem is not caused by the problems about the hardware, frequency planning, or cross engineering, it is found that the HOSR of the network is 2% to 3% lower than that the original network and other KPIs are normal.

After analysis, it is found that the idle burst function is enabled for testing. This function cannot automatically be disabled. As a result, idle timeslots of TRXs are transmitted at full power, the interference increases, the bit error ratio (BER) rises, and the receiving quality decreases.

Manually disable the idle burst function. The air interface quality of the entire network improves effectively. The HOSR increases by 2% on the whole, almost the same as that of the original network.

4.7 Different HOSRs Resulting from Different Cause Values Contained in the Clear Command Messages Sent by Different Switches

There are multiple BSCs in office Z. Some BSCs are connected to Nortel switches and some are connected to Ericsson switches. The whole HOSR of the BSCs connected to Ericsson switches is 2% to 3% lower than that of the BSCs connected to Nortel switches.

The result of the analysis on traffic measurement shows that the whole number of Failed Incoming External Inter-Cell Handovers (Others) of the BSCs connected to Ericsson switches is very great whereas the counter value of the BSCs connected to Nortel switches is 0. As defined in the protocol, a Clear Command sent by the MSC can contain four cause values:

09: Call Control 0B: Handover Success 0A: Radio Interface Failure, Reverse to old Channel 01: Radio Interface Failure

For the failed handovers caused by MSC clearance, the Clear Command messages sent by Ericsson switches contain the cause values of 0A and 01, whereas those sent by Nortel switches contain the cause value of 09. Nortel switches do not send messages in accordance with the protocol. Under Nortel switches, the failed handovers caused by MSC clearance are not collected into the statistics. As a result, the HOSR of Nortel switches is higher.

5 Information Feedback

5.1 TEMS Log Files About Problem Cells

Cell information tables of TEMS tests are required to be provided in log files. The tables must be in the format of *.cel.

5.2 Requirements of Configuration Data of the Existing Network and Traffic Measurement Feedback

The latest data configuration and engineering parameter list are required. The feedback of traffic measurement counters is required for consecutive two days. The following table lists the counter types.Call Drop Measurement per Cell

Incoming Internal Inter-Cell Handover Measurement per Cell

Outgoing Internal Inter-Cell Handover Measurement per Cell

Incoming External Inter-Cell Handover Measurement per Cell

Outgoing External Inter-Cell Handover Measurement per Cell

Incoming Inter-RAT Inter-Cell Handover Measurement per Cell

Outgoing Inter-RAT Inter-Cell Handover Measurement per Cell

Measurement of MRs upon Handover Initiation per Cell

Channel Assignment Failure Measurement per Cell

Page 3 of 28

_1307359103.vsd

_1307875717.vsdYes

Yes

The HOSR is low

Yes

Yes

Whether the problem occurs in some cells

Yes

Yes

Rectify the hardware and transmission faults

Check whether the handover thresholds and the BSC clock over the A interface circuit comply with the standards

Whether a hardware and transmission failure occurs

No

No

No

Yes

No

No

Optimize the RF

Whether the problem occurs in a co-BSC under a co-MSC

No

No

Check whether a TRX or a channel failure causes high traffic in each timeslot. If yes, change the TCH Traffic Busy Threshold(%) and expand the capacity

Change the data configuration

Whether the target cell is congested

Whether the data is configured improperly

Whether a clock problem occurs

Check the common hardware, the handover data configuration between the BSC and the MSC, and the CGI of the cells

Yes

Perform automatic neighboring cell optimization

Whether an interference problem occurs

End

Clear the clock alarm and replace relevant hardware

Whether a coverage problem or uplink and downlink imbalance occurs

Optimize the RF

No

_1307360472.vsd

_1307359070.vsd