Vous êtes sur la page 1sur 3

TROUBLEHOOTING FLOWCHART

GET bs00date.lst and KIdate.lst using WS_FTP from NMS directory /global/home/rnp/NDr_d

Update files Cell Performance.xls and GSM Performance.xls Note: GSM Performance.xls will graph trend of CSSR, TCH drop, Blkng etc. of each BSC. Then youll know which BSC needs immediate attention. Whether problem is due to certain sites only or the whole BSC youd have to confirm from the Cell Perfo rmance.xls Cell Performance.xls gives statistics of each cell for the whole day with weights added for prioritization purposes.

High TCH Blkng: 1. Check history of the cell from the to see if its really congested. Note: Sudden increase in traffic may be caused by a sector of the site or a different nearby site that was down so check if they are working normally. Use MapInfo to check sites surrounding it. 2. Check column tch availability to see if all installed TRXs are working normally. Note: If certain TRX of the site are blocked by user, you must confirm from OSS why (is it a new trx to be added, having problems, or just accidentally blocked)

PROBLEM:LOW CSSR Call Set-up Success Rate contributors: SDCCH Blkng, SDCCH Drop, TCH Blkng, Ater Congestion
High SDCCH DROP (check from network doctor ndp166mx_d, the cause of sdcch drop ABIS, RF, Aif ? Etc. May be solved simply by restarting the BTS, or replace a hardware part, or retune, or define or correct definition in the MSC, or change BCSU assignment depending on the following: 1. Channel failure rate alarm, low mean holding time alarm from the ZEOL, low traffic and corresponding send buffer overflow alarm in ZAHO for the BCSU of the TRX involved may be solved by changing BCSU assignment 2. No alarm, no traffic, sudden increase in sdcch drop may be solved by restarting the site. Just give it a kick. 3. SDCCH drop due to Aif (based from the ndo166mx_d). Site might not be defined in the MSC. Or wrongly defined (locked in the MSC, wrong CI etc) 4. For sites with more than one trx and sdcch drop is >50%. And all the traffic goes only to one trx. Quality is low for that trx which does not carry traffic based from the cell analyzer (report no. 216 from the Network Doctor, - This may be interfered or have some hardware fault like wrong wiring, termination or connection in the back plane, or tx output power, etc 5. Interfered sites may have high sdcch drop. Please check uplink interference from the zero command. Retune if interfered. If it has 2 TRX and a frequency is hard to find you may change the site to hopping mode to lessen interference. 6. Transmission problems check disturbance from command ZYMO:ET, 46; (where 46 is the et number) 7. Check branching table

High SDCCH Blkng: 1. Check reason for high SDCCH usage. SDCCH is used only for SMS and location updates. Very High Location Updates? check parameter MNC and MCC from the ZEQO. MNC must be 03 and MCC=515. Check defined location areas. Must be the same for same Site ID (1800 and 900). Check which neighbor sites LAC is different and is causing the location updates. Confirm if this is really the designed value of LAC. Parameter CRH from ZEQO may be changed to 10 dB for the site and the neighbor site to help lessen Location Update. 2. Check configuration. Is it combined (MBCCHC) or separate (MBCCH at TS0 and SDCCH at TS1)? Change to separate config to lessen SDCCH blocking. Also the TRX aside from the MBCCH trx must have an assigned SDCCH at TS1. 3. If it is a 900 cell with an 1800 overlay, if the 1800 is not congested on the SDCCH, C2 must be activated to bias sdcch traffic to the 1800 and REO must be set from 6 to 20. The higher the value the greater the bias.

Call Congestion at Ater (BSC-MSC Links) 1. Capacity of voice channels at the BSC-MSC link not sufficient. Needs expansion 2. The effect of this is usually felt in all the sites in the BSC So its important that Ater congestion and signalling link loading between the BSC and MSC are also monitored.

PROBLEM:LOW CCSR Call Completion Success Rate contributors: TCH Drop

High TCH DROP (check from network doctor ndp163mx_d, the cause of TCH drop ABIS, RF, Aif ? Etc. 1. Channel failure rate alarm, low mean holding time alarm from the ZEOL, low traffic and corresponding send buffer overflow alarm in ZAHO for the BCSU of the TRX involved may be solved by changing BCSU assignment 2. From the ZAHO command, there is an alarm 2993 BTS and TC Unsynchronization Failure a. There is error in the branching table. Ex. certain TS of TRX not defined b. Fault in the BCSU or Ater ( as what happened before and TCH drop were felt in the entire BSC) c. Faulty TRX or some hardware fault in the BTS 3. Interfered sites may have high sdcch drop. Please check uplink interference from the zero command. Retune if interfered. If it has 2 TRX and a frequency is hard to find you may change the site to hopping mode to lessen interference. 4. Transmission problems check disturbance from command ZYMO:ET, 46; (where 46 is the et number) 5. Handover failures. Not all handover failures will result to drop calls. However, if the cell is not able pass the call successfully to another after retries, the signal continues to deteriorate until the call is dropped.

OTHER PROBLEMS: 1. BTS NOT DEFINED IN THE MSC: (command: ZEPO:CI=_,LAC=_; or ZEPO:NO=_; where _ is the cell id) no call seizures and requests can be made in the BTS, only handover traffic. (totch column of KI has value) 2. WRONG LAC or CELLID of the BTS in the MSC: (command: ZEPO:NO=10254 where 10254 is the cell id) high sdcch dro. Also no calls can be made 3. VERY POOR UPLINK QUALITY or DOWNLINK QUALITY or SIGNAL STRENGTH might be due to interference. Or antenna problem. Hardware further check at TRX level 4. Understanding of the different parameters is necessary also in troubleshooting. Since poor performance of a BTS may be just due to some wrong parameter setting. Here are some from the BTS parameters (ZEQO) Cell Barred = N PLMN Permitted = 0-7 PER = 7 hours MNC= 03 MCC= 515

5. HIGH HANDOVER FAILURES/ SITE HAVING SAME CELLID as some other sites. CELLID must be unique, if both BTS with the same CELLID are working this will be a problem already. If one is blocked and the other is working like in the case during cut-over where the BTS is defined already in the other BSC but blocked by user, this might cause confusion in the system and cause handover failures. 6. CELL HAVING SMALL COVERAGE. Check timing advance statistics. Check hardware, quality and downlink strength

NOTES: Various network doctor files are available and automatically generated by the NMS for your troubleshooting. You may view or retrieve it from the FTP \global\home\rnp\NDr_d ndp150mx_d total handover failure per BTS ndp153mx_d HO failure per BTS for each adjacency ndp190mx_d interference per BTS for GSM ndp190px_d interference per BTS for DCS ndp250mx_d CSSR per BTS ndp163mx_d TCH drop per BTS and cause ndp166mx_d SDCCH drop per BTS and cause

Common commands: ZEEI:BTS=_ ; ZERO:BCF=_; ZEEI:BCF=_; ZERO:BTS=_; to view configuration of site to view uplink interference level, number of occupied TS and channel config ZEEL:BTS=_; ZEEL:BCF=_; to view number of idle, occupied and blocked SDCCH and TCH

ZEOL:_; (where _ =BCF number) ZYMO:ET,_; (where _ =ET number) to view transmission stats, counters (if there is disturbances) ZAHO; ZEOL; to view all the alarm in the BSC to view current alarms of all the BCFs in the BSC

ZEUO:_; (where _ =BTS number) view power parameters of the BTS

ZEQO:BTS=_:all; (where _ =BTS number) view BTS parameters of the BTS


ZEAO:BTS=_; (where _ =BTS number) view adjacents cells of the BTS ZEHO:_; (where _ =BTS number) view handover parameters of the BTS ZEPO:CI=_,LAC=_; or ZEPO:NO=_; (where _ =CELL ID) to view definition at the MSC of the BTS

We hope this document will serve as a guide to your analysis of the sites performance and in your troubleshooting. This does not give the whole picture of the troubleshooting process, the greater part is learned from actual experience, analysis and observations, as problems are varied and you may have to try different creative approaches to pinpoint the problem and find an effective solution. Thank you.

written by: Norlyn Langub Performance Team SE-Wireless Access

Vous aimerez peut-être aussi