Call Setup Problem Investigation
Contents Front page
Overview The NHA will carry out automatic cause analysis for the Call Setup problem - in the following areas:
•
MSC Connection
•
TCH Blocking
•
Call Setup Assignment
To begin investigating this problem, see the cause information, the detector information and the line of reasoning presented for the call setup problem. In addition, the issues identified below may be used to carry out further investigation into why the problem is occurring.
General 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 call setup. If any alarms are repeating frequently they should be fixed.
Active NHA problems If there are active NHA problems for the Site or Cell, these should be checked as they may indicate why the problem is occurring. Use the NHA's "Other Problems on this Device" menu option. The type of problems that are most likely to contribute to a poor Call Setup success rate are:
•
High Second Assignment Rate
•
High TCH Blocking
•
High RSL Utilisation
•
High MTL Utilisation
•
High GPROC Utilisation
•
Low Incoming Handover Success Rate
•
Device Outages (for example, RSL OOS, MTL OOS and so on)
Common LCF
If there is poor Call Setup on more than one site, then check if the sites are using a common LCF.
•
If so, and if there is spare capacity, consider moving a site from one LCF to another. This will show if the LCF is causing the problem.
•
Use the disp_processor command to check the status of the suspect LCF.
•
If there is a problem with the LCF, then resetting the LCF may fix the problem.
MTL Not Carrying Traffic If there are problems with all cells in the BSS, then it may be worthwhile to check the MTLs to see if they are all carrying traffic. Check the statistics MTP_MSW_TX and MTP_MSW_RX to make sure that there is traffic in both directions on all MTLs. All MTLs should be carrying traffic in both directions at all times.
Repeated RSL Outages If the RSL (the signalling link) is out of service then this will effect all cells at the site. Look for a repeated outage of any RSL to the site (RSL OOS). A loss of signalling messages will affect the call setup performance. Check any Alarms on MMSs for the BSS, for example:
•
Synchronization Loss Alarms.
•
Remote Alarm Threshold.
•
Frame Slip Alarms.
•
Red Alarms = sync loss on T1 links.
•
SNR Alarms = signal to noise on HDSL links.
Look for BER alarms on the links to the site (MMSs). The MMS's to check are those for the link back from the BTS to the BSC, including any intermediate links if there is a daisy chain configuration.
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 call setup 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: 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.
MSC Connection Mobile terminated supplementary services A high volume of mobile-terminated supplementary service attempts may impact the detection of poor Call Setup Success, because as mobile-terminated supplementary service attempts are completely transparent to the BSS and cannot be measured, every mobile terminated supplementary service will be counted as a failed call setup attempt. Examine the MSC statistics to see if it is happening. Investigate whether the MSC is configured to use USSD messages (mobile terminated supplementary services) to indicate to pre-paid users their credit balance. Verify this by making some mobile originated pre-paid TEMs test calls and after the call is terminated and the MS returns to idle mode checking if the MS is paged and REGISTER/FACILITY messages are exchanged on the SDCCH.
Subscriber behaviour Subscriber behaviour can account for a significant percentage of call setup failures. This should be taken into account when analysing why the network is showing a reduction in call setup performance. For instance, any of the following can affect the early stages of call setup:
•
The user may decide to clear a call during setup, or the user may decide to power-off during call setup.
•
The user may ask for a service to which they are not subscribed.
•
A high number of wrong numbers.
CIC congestion The CIC is a terrestrial circuit to the MSC that is used for a call. Circuit Identity Code (CIC) congestion occurs if there a no free CICs for a call - in this situation an assignment request will not be sent and the call will be cleared. CIC congestion may contribute to early failures in call setup. To do some analysis of CIC congestion: 1.
Note the value for the maximum number of CICs in use during the interval:
•
Check the highest value for BUSY_CIC_MAX.
•
Check the highest value for BUSY_CIC_MEAN.
2.
Compare the maximum BUSY_CIC value against the actual number of CICs equipped.
3.
If the BUSY_CIC_MAX value is close to the number if CICs equipped, and the BUSY_TCH_MEAN is high then CIC Congestion is causing a significant number of call setup failures. There may be a need to increase the number of CICs between the BSC and MSC.
Failure in DTAP procedures DTAP (Direct Transfer Application Part) procedures cover the early part of call setup when the mobile is communicating with the MSC transparently through the BSS. The procedures include
authentication, mobile identification, and TMSI reallocation. Analyse the DTAP procedures by carrying out investigation at: The MSC or A-Interface:
•
Authentication Check the success rate of the Authentication procedures. That is, check that at least 98% of AUTHENTICATION REQUESTS are followed by an AUTHENTICATION RESPONSE.
•
Mobile Identity Check the success rate of the Identity Request procedures. That is, check that at least 98% of IDENTITY REQUESTS are followed by an IDENTITY RESPONSE.
•
TMSI Reallocation Check the success rate of the TMSI reallocation procedures. That is, check that at least 98% of TMSI REALLOCATION COMMANDS are followed by an TMSI REALLOCATION COMPLETE.
Encryption failures At the MSC and BSS: Check that both are using the same encryption algorithm. For the BSS use the MMI: disp_a5_alg_pr This should match the ENCRYPTION INFORMATION field in the A-Interface CIPHER MODE COMMAND.
TCH Blocking Outgoing handovers Outgoing Handover Fail / Recover If outgoing handovers from a cell are not succeeding and the calls are successfully returning to the source cell, this can lead to TCH blocking on the source cell. The cell may be having to service calls that should be carried by a neighbour cell but the handover isn't working so they are staying on the source cell. Check for a high rate of handover failed/recovered to the source cell. If the value is significant, the low outgoing HO success rate is likely to be contributing to the TCH blocking. Handover Attempts Versus Handover Requests The TCH blocking may be affected by outgoing handovers being attempted but not attempted. A low percentage would indicate that mobiles on the congested cell want to do a handover but no handover is being attempted. This may be caused by congested neighbour cells, or by neighbour cells with incoming handover disabled. It may also be worth looking for an OOS neighbour cell.
Call Setup Assignment 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 too short 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. bssmap_t10 assign_successful The settings of the Site timer "bssmap_t10" and BSC timer "assign_successful" can cause poor TCH RF assignment success if they are set too short. If bssmap_t10 is under 14 seconds, consider increasing it to 14 seconds. If assign_successful is under 15 seconds, consider increasing it to 15 seconds. These changes are recommended by Motorola, especially if the current values are less than 5 seconds.
•
bssmap_t10 is the time the BTS waits for an Assignment Complete message from the mobile.
•
assign_successful is the time the BSC waits (in case the BTS message gets lost). This should be about 1 second longer than bssmap_t10.
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. Co- adjacent frequencies for cells in the same area (not neighbours) 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.
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 MCell6, GSM900 TCU 6, Horizon Macro, Horizon Macro Extension.
