Dropped Calls Problem Investigation Contents

Front page

Overview

The NHA cause analysis automatically checks for many of the RF Loss and Handover related issues that cause poor dropped call rate on a cell. To begin investigating this problem, see the cause information, the detector information and the line of reasoning presented for the dropped call problem. In addition, the issues identified below may be used to carry out further investigation into why the problem is occurring.

Health checks

Use the following as a guide when analyzing the dropped call problems.

Active alarms

Active alarms  

If there are active alarms at the site or Cell these should be fixed first. Note that any alarms active at the site may affect all cells under that site.

Intermittent alarms  

Repeating intermittent alarms can also cause poor dropped calls. If any alarms are repeating frequently they should be fixed.

GCLK problems

Calibration or Phase lock lost  

GCLKs that are not phase locked or need calibration at either the problem cell or neighbour cells will not necessarily affect handovers between cells at a site but it could have an impact on handovers between sites.

General neighbour list check

Do some preliminary sanity checks on the neighbour lists against the real network configuration. If an important neighbour is missing mobiles may have to attempt to handover to an unsuitable neighbour because it may be the best option, or there may be no handover target forcing the mobile to stay on the source cell until the call drops.

Check that all important neighbours are on the neighbour list.

Look for recent changes to the neighbour list or neighbour parameters, for example check if there have been cells added or removed.

Sanity check neighbour parameters, for example, ho_margin_cell or ms_tx_pwr_max_cell.

Look for one-way neighbours.

Dropped handoversThe NHA will check if a high proportion of the dropped calls in the cell were due to dropped handovers. You can further narrow down the cause of the handovers (are the handovers intra-cell, intra-BSS, or inter-BSS) by comparing the following statistics: INTRA_CELL_HO_LOSTMS, OUT_INTRA_BSS_HO_LOSTMS, OUT_INTER_BSS_HO_CLEARED. Note that the Handover Timers section below outlines the timers that can cause unsuccessful handovers to drop instead of recovering to the original cell.

Low outgoing handover success  

Check the NHA Other Problems on this Device to see if there are any Outgoing Handover Success rate problems. This could be the cause of the dropped calls. Fixing any outgoing handover problems may help improve the dropped call rate.

Ping-pong handovers

In some cases a cell may experience ping-pong handovers where handovers are occurring in each direction due to different causes. This increases the likelihood of calls dropping. Check the neighbour statistics and handover causes (see below) on the NHA to see if there is a high handover volume in both direction between two cells.

Handover causes

Use the NHAs handover cause detectors to check for what is causing the handovers from the cell, this may help uncover a problem on the cell. For example, check if the NHA is reporting Low Handover Rate – Power Budget . Note that this is normal behaviour for a micro cell. The NHA will report the following handover causes: - Power Budget, Uplink Quality, Uplink Level, Downlink Quality, Downlink Level, Distance, Uplink Interference, Downlink Interference, Congestion, Adjacent Channel Interference, Band Reassign, Interband Handover.

RF issues

The NHA will do some automatic analysis of RF Issues, and may report that the cell has RF problems (BER, FER, IOI), however it may be useful in cases where the cause is not identified to consider some of the following:

T3109

 If this timer is set incorrectly it could cause interference type problems to occur. This timer prevents the reallocation of a channel, following the detection of an uplink radio link loss. Make sure this time is set to a value greater than radio_link_timeout. This will ensure that channels will be released as soon as is safely possible following a radio link loss, increasing channel availability, avoiding any unnecessary SDCCH or TCH congestion. The recommended value for this timer is 8000 msecs.  

T3111

 This can also cause interference-like problems if it is set too short. Note that in BSS version 1600, this timer is split to cover SDCCHs and TCHs separately, the Motorola recommended values for these timers are:

T3111: 1200 msecs

T3111_SD: 1200 msecs

T3111_TCH: 850 msecs

If any of the above timers is set too low then the channel could be allocated to a new mobile before the old mobile has stopped using it, causing interference. Otherwise, if the value of the timer is set too high it can waste resources by holding the channel for too long.

Frequency reuse on hopping carriers

NHA will report if you have co- or adjacent reuse in neighbour cells but only for carriers that are not hopping. If any type of hopping is used, it will be necessary to do some manual checks for frequency reuse.

HSN configuration and MAIO between sectors

If synthesised frequency hopping is enabled on more than one cell on a site and there is adjacent or co- channels between hopping systems on two cells then check that the same hopping sequence number (HSN) is used on cells at the site and check that manual Mobile Allocated Index Offset (MAIO) has been implemented correctly.

SFH interference between neighbours

Check if any neighbour or nearby cell has SFH carriers with:

Co-channel with, or adjacent to, frequencies used in this cell.

The same mobile allocation (mobile_alloc) length.

The same HSN.

Co- adjacent frequencies for cells in the same area (not neighbours)

This may be interesting if you can’t find the cause of interference. The NHA currently looks or co- or adjacent channels in neighbour cells. It may also be useful to look for co- or adjacent channels at other cells in the same area as the problem cell, regardless of whether it is a neighbour.

Channel 50

This may be interesting if you can’t find the cause of high interference on idle (IOI). In some cases there may be a receiver problem on Channel 50 for some M-Cell2 and M-Cell6 cabinets. This may cause dropped calls (or reduced loads on the Channel 50 carrier). Refer to ISB GSM-99-048 for more details on this.

BER on SDCCH or TCH

SDCCH timeslots generally have higher BER than TCH, so if a carrier has high BER and the cause cannot be found, check to see if it has a very high amount of SDCCH traffic. If so, there may be nothing wrong with the carrier.

Per-zone breakdown of RF losses

Check if the dropped calls are being caused by RF losses on a carrier in a particular zone, for example in the case of concentric cells, extended range cells. You can check this by looking at RF_LOSSES_TCH per carrier.  

Extended range cell

If there are extended range cells on the network, then there may be a likelihood of a higher dropped call rate. Note that a new statistic introduced in GSR6 may be useful to check the range of extended range carriers – ROC (range of carrier) – indicates the range of a carrier based on real timing advance value. It may also be possible to use Call Trace to check the timing advance of the dropped calls.

Antenna select

Check the value for antenna_select against the configuration of the site. In some cases you may see bad path balance if the antenna_select configuration is not set correctly in the BSS database.  

The antenna_select parameter specifies the RX antenna attached to a DRI/RCU. The value of antenna_select is only used if the radio is in one of the following cabinet types: GSM900 M-Cell6, GSM900 TCU 6, Horizon Macro, Horizon Macro Extension.

Rx configurationIf there is more than one cell in the site showing poor incoming handovers, there may some problems with the configuration of the RX/TX antennae. Make sure the antenna are connected to the correct sectors. Also, if a receive diversity antenna is not being used, it is recommended to disable diversity on each carrier the cell. It is recommended that the single antenna should be connected to receive port A with the other input terminated.

Co-channel neighbour BCCH

Clash source cell BCCH

Check if any neighbouring cells have the same BCCH frequency as the BCCH of the problem cell. Mobiles monitor the BCCH in each neighbour to report the downlink RxLev. If they have

the same BCCH, it could be measuring the receive level of the source cell, not the neighbour cell.  If the two cells overlap, there will be interference problems. If the cells do not overlap, they should not be configured as neighbours.

Clash source cell non-BCCH

Check if the cell has a neighbour whose BCCH frequency is the same as a non-BCCH, non-SFH carrier in the cell.  If the cells overlap there is likely to be interference between the two cells.  Also, mobiles will have difficulty measuring the receive level of this neighbour since it is using the same frequency as a carrier in the cell itself.  If a mobile can decode the BSIC of the neighbour, it may report the level of the source cell as the level of the neighbour.  If the cells do not overlap, they should probably not be configured as neighbours.  

Recent site work

Check for any recent activity at the site, it is possible that this may have caused the problem. For example, there may have been a site visit to replace hardware. Check if the dropped call rate got worse after the site visit.

Cell parameters

The NHA checks for the correct settings of the following cell parameters: link_fail, radio_link_timeout. Other parameters that should be checked include:

Full_pwr_rfloss

In a case where there is high RF loss being reported for a cell it may be useful to enable full_pwr_rfloss. This switch enables the BSS to command the mobile to go to full power in an attempt to prevent an RF loss.

Link_about_to_fail

Check the value for link_about_to_fail. When full_pwr_rfloss is enabled, the parameter link_about_to_fail is used to determine the number of undecoded uplink SACCH frames after which the BTS and MS are increased to full power. This number of undecoded SACCH before going to full power is taken from ( link_fail - link_about_to_fail). The values recommended by Motorola are:

link_fail = 3 (16 SACCH blocks)

link_about_to_fail = 2 (12 SACCH blocks)

If these recommended values are used, the BTS and the MS will go to full power after 4 undecoded SACCH frames, leaving another 12 SACCH frames on full power before the call is dropped.

Ncc_of_plmn_allowed Check the value of ncc_of_plmn_allowed in the problem cell with the bsic of outgoing neighbours. The value of ncc_of_plmn_allowed limits the neighbour cells for which mobiles in the cell will send measurement reports. This functionality is intended to stop the mobile wasting measurement reports on cells in other networks. But if it is configured badly it can cause mobiles to ignore neighbour cells that should be reported and to which handovers should happen.

Unusual configuration of this cell compared to other cells

Check if the configuration of this cell differs from the configuration of other similar cells.

Recent configuration change to problem cell

Check if there have been recent configuration changes to the cell.  

New carrier

Has a new carrier been added recently to the problem cell, if so, has it been configured correctly. Also, check if a co/adjacent channel carrier was added recently to a neighbour cell.

Frequency change

Check if there have been any recent changes in problem cell, or frequency change in a neighbour cell where the new frequency is co/adjacent to carrier in problem cell.

New neighbour

If new cells/neighbours have been added recently, check if they are configured correctly – especially outgoing neighbours.

Neighbour cell problems

NHA Problems on Neighbour Cell

Check the NHA Problems on Neighbours for a list of problems that the NHA has detected on the neighbour cell. For example, the Path balance problem may be present on a neighbour and this could be the reason for the dropped call rate on the problem cell.

Note that the NHA Problems on neighbours menu option will show if the NHA has raised any problems on neighbours (on the same OMC). Use the NHA Neighbour Performance View menu option to see the neighbour cell statistics and key statistics on all OMCs.

Incoming handovers disabled on neighbours Check if the parameter en_incom_ho is set to 0 on any neighbour cells. If so, the source cell will not try to handover to the target cell. The target cell may be the most suitable cell for the source to handover to, so the source may end up handing over to a completely unsuitable cell causing poor handover success.

Poor incoming handovers

An incoming neighbour may be making invalid handovers into the problem cell, the handovers may be successful, but the call could then be dropping. Check the configuration of any recently re-configured incoming neighbours  

Neighbour with HO margin too low or too fast

Check the settings for the congest_ho_margin on neighbours – if this is set too aggressively then the congestion relief handovers may succeed but are likely to drop shortly afterwards.

New incoming neighbour

 If a new incoming neighbour has been badly configured it may be making invalid handovers into the problem cell, check the configuration of any recently added incoming neighbours.

Timer mismatch between MSC and BSS

 Inter-BSS handover drops can be caused by a timer problem between MSC and BSS where MSC releases the channel in the source cell while the handover is still in progress.

Timer mismatch between MSC and BSS

Inter-BSS handover drops can be caused by a timer problem between MSC and BSS where MSC releases the channel in the source cell while the handover is still in progress.

Handover Timers

Check that the timers used during the handover procedure are set at the recommended values. The following table outlines the recommended values for timers that could affect

handovers due to expiry before expected events. These timers are explained fully in the manual  Maintenance information: BSS Timers (68P02901W58) .

 

On Source Cell On Target Cell Recommended Value

 bssmap_t8 (Inter-BSS & intra-BSS)

  14000 msecs

clear_cmd_ext_ho (Inter-BSS)

  14000 msecs

  ho_successful (Inter-BSS) 15000 msecs  ho_complete (Inter-BSS &

intra-BSS)14000 msecs

  rr_t3105 * rr_ny1_rep (Inter-BSS & intra-BSS)

1200 msecs

  rr_t3103 (Intra-BSS) 15000 msecs

 

The timers listed above can be categorised into two groups; those that can cause unsuccessful handovers to result in a dropped call if they expire, and those that will cause more unsuccessful handovers but the call should recover to the source cell.

Bssmap_t8 is measured at the BTS level and is started once the Handover Command is send to the MS. The clr_cmd_ext_ho is started prior to the bssmap_t8 when the 'initiate handover' request is sent from the BSC to the BTS. Both of these timers can cause unsuccessful handovers to result in a dropped call if they expire. They should be set long enough to allow the mobile a reasonable chance to recover without wasting resource time.   

Ho_complete and ho_successful may expire causing the handover to fail but the mobile should recover. To maximise the assignment/handover success rate, both these timers should be long enough to allow the MS to receive the assignment command over the air interface, attempt and fail to access the target channel and return to the source channel. These timers should not be so long that resources are held up unnecessarily introducing channel congestion.   

Rr_t3105 * rr_ny1_rep should be set long enough to ensure the handover success rate is not impacted in poor radio conditions and channels are not held unnecessarily.

Rr_t3103 is measured at the BSC level and is started once the Handover Command is sent to the MS, it can cause the mobile to drop if it is set too short. It should be set long enough to allow the mobile a reasonable chance to recover without wasting resource time.  

Use Call Trace Use Call Trace to examine dropped calls on this cell. This may help you to see why the calls are dropping.