常見告警故障處理及案例分析

1、 常見告警故障處理及案例分析MOTOROLA基站的告警按故障設(shè)備可分為三類：設(shè)備告警、內(nèi)部告警、外部告警。一、設(shè)備常見告警設(shè)備告警是硬件告警最常見也是最重要的告警，告警設(shè)備一般為基站的主要器件，它的告警類型就是它的設(shè)備類型。1. DRI 29：Front End Processor Failure - Watchdog Timer Expired前端處理器故障DRI硬件故障，出現(xiàn)此告警時DRI可能會反復(fù)自啟，可能會退服，應(yīng)先reset or ins DRI應(yīng)進(jìn)行INS或RESET處理，若告警未消失，更換TCU。 2 DRI 40-47 ：Channel Coder Timeslot 0（-7）

2、 Failure 0-7時隙信道編碼器失敗。M-CELL基站經(jīng)常出現(xiàn)此類告警，應(yīng)進(jìn)行INS或RESET處理，不行再更換TCU900。此告警在GSR4時出現(xiàn)，升級到GSR5可能會消失。3 DRI 51 ：Baseband Hopping TDM Link Error基帶跳頻TDM鏈路錯誤。此告警有幾種可能性：TDM-Highway BUS或KSW可能有問題。 DRIM的FEP，CCDSP可能有問題。此告警須在現(xiàn)場具體測試分析。測試后判定故障點。此告警在GSR4時出現(xiàn)，升級到GSR5可能會消失TDMTime Division Multiplexing時分復(fù)用：該總線用于把來自BTS的呼叫與信令數(shù)據(jù)

3、傳送到MSC，反之亦然。可分為兩個獨立的部分：交換機(jī)公共通路&出局公共通路。交換機(jī)公共通路：處理路由到交換機(jī)的數(shù)據(jù)，數(shù)據(jù)來自外部信源 (通過E1/T1接口)或由GPROC內(nèi)部產(chǎn)生。出局公共通路：這是一個被交換的數(shù)據(jù)，現(xiàn)在被路由出BSC/RXCDR (通過E1/T1接口)或通向內(nèi)部GPROC。 4. DRI 81：Transmitter Synthesizer Failure收發(fā)單元故障此告警為收發(fā)單元TCU故障，故障原因有可能為：-接收Calibration頻點丟失-信道盤的CEB故障-射頻電纜連接失敗處理方法：遠(yuǎn)程ins或reset TCU,告警消失并監(jiān)測；若告警未消失，更換TCU5

4、. DRI 86 ：Transmitter Failure輸出功率失敗，引起DRI退出服務(wù)。狀態(tài)：D-U此告警是信道盤的功率放大器失敗。應(yīng)更換信道盤。6 DRI 91 ：Power Amplifier Power Low But Functioning信道盤的功率放大器輸出功率低于門限，狀態(tài)B-U。此告警有可能由于高溫等原因引發(fā)，有些站經(jīng)常性出現(xiàn)DRI91的盤則需要更換，以免因小區(qū)功率不平造成掉話。有時侯在現(xiàn)場看不見此告警，須從OMC的事件窗口檢查。7 DRI 92 ：Power Amplifier Temperature High But Funncioning信道盤的功率放大器高溫告警，但

5、可以工作。信道盤的功率放大器的高溫多數(shù)是因機(jī)房高溫，或機(jī)箱內(nèi)的風(fēng)扇故障造成的。在出現(xiàn)此告警后，信道盤的性能會下降。如溫度過高，信道盤會自動閉塞。因此常出現(xiàn)此告警的信道盤應(yīng)于以更換。8 DRI 112 （114） Receiver Synthesizer Failure接收單元合成器故障 此告警為收發(fā)單元內(nèi)部故障，其主要原因大概有： -收發(fā)信單元內(nèi)部直流供電故障-收發(fā)信單元內(nèi)部硬件故障處理方法：遠(yuǎn)程ins或reset TCU,告警消失并監(jiān)測；若告警未消失，更換TCU9 DRI 150: Receive Matrix Branch 1 control Link Failure接收矩陣支路控制失敗，

6、狀態(tài): B-U 此告警M-CELL和Horizon中均有出現(xiàn)，伴隨切換掉話，切換成功率低，呼叫建立成功率低導(dǎo)致的話務(wù)量減少。有時也會導(dǎo)致信道盤的path_balance值偏高。 其主要原因有： -有故障的接收矩陣即SURF -收發(fā)信單元與接收矩陣之間的同軸電纜斷路 -收發(fā)信單元與接收矩陣之間的同軸電纜短路 -信道盤中的均衡器板控制電路出現(xiàn)故障 -SURF內(nèi)部前-后端接口短路 -SURF內(nèi)部前-后端接口斷路根據(jù)現(xiàn)場判斷具體情況更換硬件。10 DRI 152: Control Processor to Power Amplifier Communication Failure 處理器與功率放大器的

7、通信失敗此告警是信道盤中的CEB及對PA的控制失敗。首先對信道盤進(jìn)行INS或RESET處理，不行再更換信道盤。 11 DRI 209 : Timeslot Configuration Failure信道分配失敗 D-U小區(qū)資源管理器CRM為MS分配無線信道時在射頻硬件上分配時隙失敗。產(chǎn)生的原因有： -收發(fā)信單元TCU故障 -DRI軟件故障 處理方法：遠(yuǎn)程ins或reset TCU,告警消失并監(jiān)測；若告警未消失，更換TCU12 DRI 218 ：Timeslot Configuration Failure不健全的信道接收校驗數(shù)值 此告警的出現(xiàn)時用指令：disp_cal_data <loca

8、tion> <device_name> <dev_id> <dev_id> <dev_id> 可看到基站接收數(shù)據(jù)校準(zhǔn)值中出現(xiàn)80（錯誤的校準(zhǔn)數(shù)據(jù)）， 還找到根本的原因，遠(yuǎn)程對硬件reset或ins均無作用，現(xiàn)場人員有時需更換新硬件設(shè)備而有時只需對信道盤開關(guān)電即可恢復(fù)，初步判斷為硬件TCU(Horizon目前還未發(fā)現(xiàn))接收單元問題。 13 DRI 234 ：Active Link Connection Failure主用鏈路與BTP的鏈接失敗。狀態(tài)：D-U此告警主要發(fā)生在M-CELL上，是主用BTP到DRI/TCU900的鏈接失敗。其原因主要

9、分為： * FOX/FMUX/BTP之間的連接和使用的光纖類型的問題。 *TCU900/FOX/FMUX/BTP本身的問題。 *還有則是由于某種原因，使處理機(jī)運行過程出現(xiàn)問題，使其 與TCU900失去聯(lián)系。這類情況可用LOCK-UNLOCK恢復(fù)。14 DRI 235 ：Standby Link Connection Failure備用鏈路與BTP的鏈接失敗，對網(wǎng)絡(luò)不造成影響。但如果出現(xiàn)整個機(jī)柜告警應(yīng)當(dāng)引起重視。以免基站主用出現(xiàn)故障倒換到備邊時，出現(xiàn)整個機(jī)柜不能工作。此告警只出現(xiàn)在M-CELL，是備用BTP到DRI/TCU900的鏈接失敗。其原因主要分為： * FOX/FMUX/BTP之間的連接

10、和使用的光纖類型的問題。 *TCU900/FOX/FMUX/BTP本身的問題。 *有時侯如有大部分DRI出現(xiàn)此告警，有可能是沒將BTP 做成冗余形式。DRI 239 ：Process Safe Test Audit Failure有可能是因為機(jī)房內(nèi)高溫造成，若不及時進(jìn)行處理，會繼續(xù)出現(xiàn)92#告警15 DRI 243 ：Unlocked Device Not In Service信道盤退服 D-U此告警出現(xiàn)在沒有主告警的情況下信道盤退服可能的原因是：系統(tǒng)錯誤導(dǎo)致的信道盤退服處理方法：發(fā)現(xiàn)告警后,RESET THE DRI觀察，如果告警仍然存在這更換信道盤。 16. GCLK 2 : Clock

11、Reference Failure時鐘參考失敗 此告警為基站MSI板的時鐘提取丟失 其主要原因有： -E1/T1鏈路故障 -沒有MSI/NIU的時鐘信號 -沒有XCDR的時鐘信號 -GCLK 時鐘提取電路失敗 處理方法：更換MCU或NIU,若仍然出現(xiàn)告警則需通過傳輸處理17 GCLK 4 : Phase Lock Lost時鐘參考信號鎖相丟失此告警有時會引起切換掉話或切換成功率低，有時沒有影響，大多數(shù)是因為傳輸大網(wǎng)與移動網(wǎng)對時鐘要求相距較大引起。 其主要原因有： -大多數(shù)情況是在E1/T1鏈路上偏移或不穩(wěn)定的時鐘超過所允許的極限而引起的時鐘失鎖。 -不正確的時鐘源或 -GCLK硬件故障 -GC

12、LK 晶體振蕩器由于老化不能長時間對信號源進(jìn)行鎖相處理方法：一般情況下先進(jìn)行時鐘重新校準(zhǔn)或SWAP BTP到備邊,若無作用則請傳輸中心處理。18 GCLK 8 ：主備時鐘頻差過大。此告警是由BTS的本振時鐘主備頻率偏差過大，應(yīng)及時對時鐘進(jìn)行校準(zhǔn)。M-CELL: 8000HZ.19 GCLK 14 : Phase Lock Failure時鐘參考信號鎖相失敗 此告警有大多數(shù)時間會引起切換掉話或切換成功率低 其主要原因有： -GCLK硬件故障 -有問題的前時鐘源 -規(guī)范問題20 GCLK 18: Not Operational主時鐘不工作 此告警是由于基站主控板MCU不能建立正常的同步時鐘初始化。

13、出現(xiàn)的原因：可能是由于固件故障，或是硬件老化。 出現(xiàn)此問題時應(yīng)reset MCU,若告警未消失則需更換MCU；若告警消失，則不需在作進(jìn)一步的觀察。 GCLK 24 Bad Clock Source or OCXO (oscillator) :不精準(zhǔn)的時鐘源或有故障的時鐘振蕩器。 出現(xiàn)此告警時先reset site 或主控倒到備邊，若還存在告警則需傳輸幫助解決。 21 GCLK 26: GCLK Calibration Request GCLK校準(zhǔn)失敗 此告警有大多數(shù)時間會引起切換掉話或切換成功率低 其主要原因有：-GCLK 校準(zhǔn)超出要求范圍（即不能進(jìn)行校準(zhǔn)）-有問題的GCLK時鐘源或時鐘源超出

14、傳輸要求規(guī)范-在MCU第一次加電時不能進(jìn)行校準(zhǔn)，因此不能計算LTA值-GCLK長時間不能進(jìn)行鎖相，超出允許時間-GCLK 硬件故障處理方法：更換MCU另：LTALong Term Average.長期平均值。BTS的GCLK頻率寄存器為產(chǎn)生一個16.384MHz的時鐘所需的值。22 BTP 39: 軟件故障此告警出現(xiàn)時會引起B(yǎng)TP D-U Code Load Failure或反復(fù)code load .其主要原因有：-下載的軟件故障-主控GPROC故障處理方法：1.進(jìn)emon reset site,并觀察 2.更換MCU（或SWAP BTP）二、內(nèi)部告警內(nèi)部告警的告警設(shè)備一般為基站的輔助設(shè)備如風(fēng)

15、扇、保險、開關(guān)、電源模塊等。1 IAS 86#cabinet fan failure：基站風(fēng)扇故障2 IAS 81 ：PSU供電單元輸出失敗。通過計算機(jī)檢測電源模塊，判定故障及時更換。 3 IAS 95 ：低噪音放大器保險壞。M-CELL對于GSM900的選件中沒有采用低噪音放大器。所以此告警對DCS1800基站有影響。解決措施為：更換對應(yīng)的保險。 對于內(nèi)部告警，除一般的高溫和風(fēng)扇告警，其他一些內(nèi)部告警一般為假告警，不與處理。 告警網(wǎng)元告警號及描述處理建議BTSDRI 29：Front End Processor Failure - Watchdog Timer Expired應(yīng)先reset

16、or ins DRI應(yīng)進(jìn)行INS或RESET處理，若告警未消失，更換TCUBTSDRI 40-47：Channel Coder Timeslot 0（-7） FailureINS或RESET處理，不行再更換TCUBTSDRI 81：Transmitter Synthesizer Failureins或reset TCU，告警消失并監(jiān)測；若告警未消失，更換TCUBTSDRI 86：Transmitter Failure更換TCUBTSDRI 91：Power Amplifier Power Low But Functioning如果是大量經(jīng)常出現(xiàn)的就應(yīng)該更換TCUBTSDRI 92：Power

17、Amplifier Temperature High But Funncioning如果是大量經(jīng)常出現(xiàn)的就應(yīng)該更換TCUBTSDRI 112: （114） Receiver Synthesizer Failureins或reset TCU，告警消失并監(jiān)測；若告警未消失，更換TCUBTSDRI 150: Receive Matrix Branch 1 control Link Failure根據(jù)現(xiàn)場判斷具體情況更換硬件(包括surf,Dri,cable)BTSDRI 152: Control Processor to Power Amplifier Communication Failure首先

18、對TCU進(jìn)行INS或RESET處理，不行再更換TCUBTSDRI 209: Timeslot Configuration Failureins或reset TCU，告警消失并監(jiān)測；若告警未消失，更換TCUBTSDRI 218：Invalid Transceiver Calibration Data安排工程師到現(xiàn)場調(diào)測BTSDRI 234：Active Link Connection Failureins或reset TCU，告警消失并監(jiān)測；若告警未消失，安排工程師到現(xiàn)場檢查TCU900/FOX/FMUX/BTP或者是FOX/FMUX/BTP之間的連接和使用的光纖類型的問題BTSDRI 235：

19、Standby Link Connection Failure如果是大量經(jīng)常出現(xiàn)的就安排工程師到現(xiàn)場檢查TCU900/FOX/FMUX/BTP或者是FOX/FMUX/BTP之間的連接和使用的光纖類型的問題BTSDRI 243：Unlocked Device Not In ServiceRESET THE DRI觀察，如果告警仍然存在這更換TCUBTSGCLK 2: Clock Reference Failure更換MCU或NIU，若仍然出現(xiàn)告警則需通過傳輸處理BTSGCLK 4: Phase Lock Lost一般情況下先用命令reattepmt_pl來讓MCU進(jìn)行時鐘重鎖，若仍然無法鎖相，則

20、檢查時鐘無法鎖相的基站是否在同一個傳輸環(huán)上，若無法鎖相的基站在同一個傳輸環(huán)上則請傳輸中心處理，若無法鎖相的基站之間沒有什么共性，則先對基站傳輸掛表測試，確定傳輸沒有問題后，對主背用的MCU（MCUF）進(jìn)行更換，對NIU也同時更換BTSGCLK 18: Not Operational出現(xiàn)此問題時應(yīng)reset MCU，若告警未消失則需更換MCU；BTSGCLK 24 Bad Clock Source or OCXO (oscillator) 出現(xiàn)此告警時先reset site 或主控MCU倒到備邊，若還存在告警則更換MCU,或者安排傳輸幫助解決BTSGCLK 26: GCLK Calibratio

21、n Request更換MCUBTSBTP 39: 軟件故障reset MCU,若沒有好轉(zhuǎn)則更換MCU三：常見問題分析關(guān)于SD掉話的問題SDCCH是Stand-alone Dedicated Control Channel 的縮寫,其意思是獨立專用控制信道。其作用是A GSM control channel where the majority of call setup occurs .Used for MS to BTS communications before MS assigned to TCH。是指建立呼叫時主要使用的GSM控制信道。用于在MS分配給TCH之前MS與BTS的通信。SD

22、掉話問題可能產(chǎn)生的原因：1、突發(fā)事件（突然增高的話務(wù)量、相臨基站斷站等）2、基站硬件問題可能會造成基站SD產(chǎn)生掉話。（載頻、發(fā)射通路、合路器、時鐘問題等）3、基站天饋性能不好可能會造成基站SD掉話。4、基站天饋接錯可能會造成基站SD掉話。5、基站數(shù)據(jù)設(shè)置錯誤可能會造成基站掉話。（CCB類型、CCB cavity號定義錯誤等）6、頻率問題可能會造成基站掉話。（同頻、鄰頻干擾或基站上行干擾等）7、基站相鄰小區(qū)定義錯誤可能造成基站掉話。（產(chǎn)生SD切換掉話）關(guān)于TCH掉話的問題 基站掉話問題是GSM網(wǎng)絡(luò)運行過程中一個比較常見的問題，由于產(chǎn)生掉話問題的原因較多，因此很難對掉話問題按其產(chǎn)生的原因進(jìn)行一個較

23、為準(zhǔn)確的分類。在現(xiàn)網(wǎng)的統(tǒng)計中，將掉話問題按其歸屬分成了四類：單載頻掉話（Rf_losses_tch）；BTS內(nèi)小區(qū)間切換掉話（Intra_cell_ho_lost）；BSC內(nèi)小區(qū)間切換掉話（Out_intra_bss_ho_lost）；BSC間小區(qū)間切換掉話（Out_inter_bss_ho_clear）。第一部分：掉話問題可能產(chǎn)生的原因 由于掉話問題較為復(fù)雜很難準(zhǔn)確定位，因此此處我們僅列出在現(xiàn)網(wǎng)中較為常見的幾種引起掉話的原因：一 基站硬件問題可能會造成基站產(chǎn)生掉話。（載頻、發(fā)射通路、接收通路、時鐘問題等）二 基站天饋性能不好可能會造成基站掉話。三 基站天饋接錯可能會造成基站掉話。四 基站數(shù)據(jù)

24、數(shù)據(jù)設(shè)置錯誤可能會造成基站掉話。（CCB類型、CCB cavity號定義錯誤等）五 頻率問題可能會造成基站掉話。（同頻、鄰頻干擾或基站上行干擾等）六 基站相鄰小區(qū)定義錯誤可能造成基站掉話。關(guān)于載頻BER高的問題 載頻的BER（Bit Error Rate）含義是載頻工作的時候在其上傳輸?shù)臄?shù)字信息比特的比特誤碼率。載頻的BER和在該載頻上通話時的通話質(zhì)量是密切相關(guān)的。手機(jī)在通話時的話音質(zhì)量有8個級別，即Quality=0,1,2,3,4,5,6,7 。0是最好，7為最差。而Quality的0到7是和BER分別對應(yīng)的。對應(yīng)關(guān)系如下：Rxquality BER 默認(rèn)BER 0 <0.2% 0.

25、14% 1 0.20.4% 0.28% 2 0.40.8% 0.57% 3 0.81.6% 1.13% 4 1.63.2% 2.26% 5 3.26.4% 4.53% 6 6.412.8% 9.05% 7 >12.8% 18.1%一般情況下認(rèn)為Rxquality在不大于4的時的通話話音質(zhì)量是可以接受的。但當(dāng)Rxquality大于4時則會出現(xiàn)通話斷續(xù)、雜音甚至掉話的現(xiàn)象。因此從對應(yīng)關(guān)系可以看出，當(dāng)載頻的BER高于2.26%的時候，即說明該載頻的通話質(zhì)量有問題了，應(yīng)該盡快進(jìn)行處理。第一部分：BER高的原因造成載頻BER高的原因主要有以下幾種：一基站問題引起的BER高1、 信道盤的發(fā)射接收補(bǔ)償

26、參數(shù)不合格2、 信道盤內(nèi)部硬件和架頂發(fā)射接收器件故障二 頻率干擾引起的BER高1、 同鄰頻干擾造成2、 上行干擾關(guān)于載頻IOI高的問題 IOI（Interference On Idle）值的含義是：載頻時隙在空閑狀態(tài)時收到的上行干擾信號的強(qiáng)度。理想情況下，載頻時隙在空閑狀態(tài)即沒有占用的情況下收到的上行信號功率應(yīng)該為0,一般情況下IOI值 <1。只要IOI值 <5,那么對信道的影響就不會很嚴(yán)重，但若IOI值接近了10或超過了10 ，則會造成小區(qū)的掉話，通話質(zhì)量下降等嚴(yán)重問題。第一部分：IOI值高的原因可以分為兩方面一基站內(nèi)部的接收設(shè)備障礙造成的IOI值高： 1信道盤的接收補(bǔ)償值不準(zhǔn)或

27、接收功能障礙2小區(qū)的接收器件DLNB或IADU、雙工器故障3天饋線故障二外來的干擾源造成的上行干擾： 1GSM網(wǎng)絡(luò)內(nèi)部的干擾：即頻率規(guī)劃不當(dāng)，同鄰頻過多造成的上行干擾。 2GSM網(wǎng)絡(luò)外部的干擾：即外界非法直放站、集團(tuán)通信系統(tǒng)非法占用GSM上行頻段，或由于其它通信系統(tǒng)的設(shè)備的不合格，發(fā)射信號邊帶頻譜干擾GSM上行頻段。部分故障問題總結(jié)表:序號現(xiàn)象描述故障原因分析處理措施及人機(jī)命令處理效果1SD 擁塞sdcch_mean_holding_time is long, 相關(guān)GPROC負(fù)荷大吊死reassign site to other lcfsuccess2三個交換機(jī)間切換失敗三個交換機(jī)間掛表進(jìn)行信

28、令測試分析交換機(jī)打patchsuccess3SD 擁塞sdcch_mean_holding_time is long, SD traffic不大T3101延長=5000, channel_reconfig_switch=0, immediate_assign_mode=0負(fù)荷有所減輕4SD掉話,接通率差PATH_BANLANCE差數(shù)據(jù)庫DRI天線選擇號配置有問題恢復(fù)正常5小區(qū)不能與周圍小區(qū)切換該小區(qū)GCLK失鎖phase_lock_gclk=1 -> reattemp gclk -> 換GCLKsuccess6通話時對方聽到無此號碼隨后掉話本地交換機(jī)900->1800切換存在

29、問題, 中繼不夠,話務(wù)走備分路由交換機(jī)增加900->1800中繼, 備分路由數(shù)據(jù)改正(切換號碼)success7call_setup_suc_rate低發(fā)生于同一交換機(jī)下BSC,告警中有 unequipcic.即交換機(jī)分配了該CIC,而BSC中未配置交換機(jī)鎖住相關(guān)CICsuccess8呼叫無法接通大量用戶在手機(jī)發(fā)出assignment complete之后，交換機(jī)即發(fā)回disconnect消息導(dǎo)致呼叫無法接通交換機(jī)打patchsuccess9單通信號強(qiáng),分布式系統(tǒng)某些地方單通分布式系統(tǒng)一節(jié)天線問題success10通話話音質(zhì)量差某交換機(jī)下串話,單通,每線愛爾蘭超過0.5導(dǎo)致中繼任意分配交

30、換機(jī)增加中繼success11呼叫無法接通信號差,天饋線接反天饋線接反success12單通某BSS下單通嚴(yán)重,該序列號的GCLK寄存狀態(tài)錯誤,主備用GCLK均被激活,各CBUS時鐘失去同步GCLK 重新編制程序success13單通BSS側(cè)CIC號碼對應(yīng)交換機(jī)的CIC號碼是錯誤的CIC號碼一一對應(yīng)success14OMC統(tǒng)計問題統(tǒng)計表中有多余小區(qū)，而CM中沒有登錄到SYS中，/usr/gsm/current/sbin 命令delete_CELLCM與PM一致15OMC統(tǒng)計問題PM窗口無法打開ps -ef | grep app; 殺死所有非root用戶的進(jìn)程吊死進(jìn)程全部清除,PM正常16OMC

31、統(tǒng)計問題話務(wù)量不高,擁塞嚴(yán)重。話務(wù)統(tǒng)計可能不正確。增大busy_tch各bin值門限防止溢出17EFRFR->EFR信道不能轉(zhuǎn)換FR的交換機(jī)也需打開EFR開關(guān)success18呼叫無法接通1800在手機(jī)發(fā)出assignment complete之后，交換機(jī)即發(fā)回disconnect消息導(dǎo)致呼叫無法接通900->1800交換機(jī)信令模塊重啟有所改善19通話話音質(zhì)量差加載在話音上的尖銳聲音可能是電路上的某些硬件問題,如XCDR上的MSI或交換機(jī)的中繼模塊success20呼叫無法接通手機(jī)發(fā)出assignment complete之后，交換機(jī)即發(fā)回disconnect消息導(dǎo)致呼叫無法接通A

32、LCATEL 的4版交換機(jī)開EFR而BSC未開，出現(xiàn)此現(xiàn)象，交換機(jī)升7版，可解決問題。success21呼叫無法接通sdcch_access_failure_rate=70修改bcch或硬件DRI排障success22雙頻網(wǎng)間不能切換路測發(fā)現(xiàn)900->900后5ter消息丟失，HOREQ消息中CLM3編碼為00（應(yīng)為50)相關(guān)交換機(jī)mapversion重創(chuàng)一下success23雙頻網(wǎng)間不能切換路測發(fā)現(xiàn)900->900后5ter消息丟失，HOREQ消息中CLM3編碼為00（應(yīng)為50)相關(guān)交換機(jī)版本不支持CLM3，交換機(jī)升級success24單通手機(jī)用戶只能聽到自己的回音話音通路的某一

33、設(shè)備出現(xiàn)故障,硬件排障success25通話話音質(zhì)量差MS-MS 話音斷續(xù)該地區(qū)無線覆蓋差,調(diào)整覆蓋success26通話話音質(zhì)量差手機(jī)用戶只能聽到尖銳的金屬聲,MS的話音編碼方式與BSC不一致(EFR)交換機(jī)間關(guān)于EFR的信令有問題success27統(tǒng)計中看到相同的LAC下出現(xiàn)不同 'page_req_from_msc' 檢查BSC告警，發(fā)現(xiàn)存在如下告警：BSS ALARM 26 : Received Page for Invalid Cell from MSC 仔細(xì)檢查此LAC所對應(yīng)交換機(jī)下所有的小區(qū)號，發(fā)現(xiàn)存在錯誤小區(qū)號。刪除這些cell id。success28用dis

34、p_cells_s命令看到的sdcch數(shù)量和該小區(qū)sdcch_prefer不一致?？赡苁且驗镾DCCH負(fù)載過大引起軟件問題。檢查該小區(qū)的每個RTF上的SDCCH負(fù)荷后發(fā)現(xiàn)達(dá)到0.9erl以上。增加SDCCH數(shù)量后問題解決。有所改善29從統(tǒng)計看，小區(qū)有話務(wù)量但是total_call=0。這是由于在數(shù)據(jù)庫中access_cell_bar =1, en_income_ho=1導(dǎo)致。檢查數(shù)據(jù)庫，將access_cell_bar設(shè)為0success30從統(tǒng)計上看，某小區(qū)的CHAN_REQ_PAGE_RESP 值要遠(yuǎn)遠(yuǎn)大于 PAGE_RESPONSE值。經(jīng)分析發(fā)現(xiàn)該小區(qū)存在嚴(yán)重的SDCCH擁塞現(xiàn)象，導(dǎo)致尋

35、呼相應(yīng)消息不能發(fā)送上來。檢查SDCCH Loading，增加SDCCH配置?；謴?fù)正常31從統(tǒng)計上看，某小區(qū)MA_CMD_TO_MS_BLKD=0 但是 TCH擁塞率卻非常高，即ALLOC_TCH_FAIL很高。分析此原因，發(fā)現(xiàn)該小區(qū)并沒有任何擁塞現(xiàn)象存在。經(jīng)過檢查發(fā)現(xiàn)，數(shù)據(jù)庫參數(shù)bssmap_t11 設(shè)置大于assign_successful，這是一個錯誤的設(shè)置，因為assign_successful是tch分配過程的超時保護(hù)器，BSSMAP_T11必須小于它。重新設(shè)置。恢復(fù)正常四：案例分析詳見附錄。案例1：信號不穩(wěn)定【問題名稱】信號不穩(wěn)定【問題類別】 硬件故障【相關(guān)設(shè)備】天饋線【問題詳細(xì)描述

36、】在距離基站200處的小村莊，在直視基站的情況下，手機(jī)接收信號漂移達(dá)30dbm,基站天線高60米。【技術(shù)背景】1參考無線原理中上下性平衡進(jìn)行計算2參考天線電氣參數(shù)3. 駐波比計算與正常值【問題解決步驟】1檢查架頂功率，發(fā)現(xiàn)沒有問題，按設(shè)計要求設(shè)置2測駐波比，用常規(guī)功率檢查沒發(fā)現(xiàn)問題，用SITE MASTER檢查發(fā)現(xiàn)在50米處駐波達(dá)1.6。降低天線高度至50米，重?fù)Q饋線后，問題解決。案例2：載頻IOI值高的問題【問題名稱】8/8/8基站最后一個機(jī)柜的載頻IOI高且話務(wù)量少【問題類別】 硬件故障【相關(guān)設(shè)備】BTS相關(guān)設(shè)備【問題詳細(xì)描述】MCELL6_8/8/8基站，采用6/6/6/（2，2，2）方

37、式擴(kuò)展 ，其中最后一個機(jī)架（也就是擴(kuò)展機(jī)架）的6個擴(kuò)展載頻的IOI都比同扇區(qū)的其他非擴(kuò)展載頻高，基本上擴(kuò)展載頻IOI在34左右，而非擴(kuò)展載頻IOI都小于1。這種情況造成擴(kuò)展載頻的TCH分配優(yōu)先級低于同扇區(qū)的其他非擴(kuò)展載頻，TCH loading rate大大低于非擴(kuò)展載頻，造成話務(wù)分擔(dān)不平衡。【技術(shù)背景】BTS相關(guān)技術(shù)【問題解決步驟】（1）檢查過該站的數(shù)據(jù)庫，所有RTF的TCH分配優(yōu)先權(quán)設(shè)置均為0，DRI數(shù)據(jù)庫也符合實際配置；（2）該站采用短跳頻，并且倒換RTF到其他載頻，跟蹤統(tǒng)計指標(biāo)，發(fā)現(xiàn)故障只與載頻DRI有關(guān)，與RTF無關(guān)，所以不會是外部頻率干擾的問題；（3）檢查過硬件連接均無問題，載頻T

38、X/RX調(diào)測時均正常，更換過載頻/CEB（接收擴(kuò)展模塊）后，故障仍存在；（4）DRI調(diào)測時，增大DRI 0 6/0 7接收補(bǔ)償，跟蹤觀察，故障未解決；（5）更換擴(kuò)展機(jī)架IADU，各扇區(qū)TCH的平均占用略有好轉(zhuǎn)，特別是3扇區(qū)改善明顯，但I(xiàn)OI仍比非擴(kuò)展機(jī)柜的載頻偏高；（6）檢查機(jī)柜IADU的擴(kuò)展開關(guān)DIP SWITCH，一切正常，但有部分RESERVE的IADU開關(guān)被置為ON，這些開關(guān)是不用的，把它改置為OFF狀態(tài)再觀察是否有影響，結(jié)果未解決；（7）檢查該站室外天饋線連接，發(fā)現(xiàn)都正常，交叉3扇區(qū)的兩根天饋線試驗，未解決；（8）修改該站RF頻率規(guī)劃，3扇區(qū)改善，已正常，1扇區(qū)未改善；（9）將DRI

39、 03/04和DRI 06/07對調(diào)，發(fā)現(xiàn)IOI高的問題在原載頻DRI 06/07（現(xiàn)載頻DRI 03/04）上；案例3：無法作主叫的問題【問題名稱】無法作主被叫【問題類別】 硬件故障【相關(guān)設(shè)備】CTU【問題詳細(xì)描述】現(xiàn)場測試時發(fā)現(xiàn)手機(jī)上接收信號較好，用戶就是無法作主被叫?！炯夹g(shù)背景】參考主被叫呼叫流程【問題解決步驟】1. 檢查統(tǒng)計發(fā)現(xiàn)TOTAL_CALL為0 ，有話務(wù)量，其他CHAN_REQ_MS_FAIL、 MA_FAIL_FROM_MS，PATH_BALANCE、IOI均正常。2. 檢查參數(shù)CELL_BAR設(shè)置正確，沒有關(guān)閉小區(qū)接入。 3檢查MSC中定義的小區(qū)LAC號與BSC的小區(qū)LAC

40、號是否一致，檢查后發(fā)現(xiàn)設(shè)置正確。 4重啟基站BCCH后恢復(fù)正常。案例4：室內(nèi)分布系統(tǒng)話音單通問題【問題名稱】 室內(nèi)分布系統(tǒng)話音單通問題【問題類別】 室內(nèi)分布系統(tǒng)【相關(guān)設(shè)備】 光纖放大器【問題詳細(xì)描述】 某重要場所室內(nèi)覆蓋較差，為了保障該地通話質(zhì)量，移動公司專門安裝了整套室內(nèi)分布系統(tǒng)。分布系統(tǒng)安裝之后，就出現(xiàn)在該地的手機(jī)下行話音非常清晰但是上行確根本聽不清楚的現(xiàn)象。【技術(shù)背景】3. 分布系統(tǒng)的光纖線性放大器。光纖線性放大器是用在分布系統(tǒng)中長距離傳輸而使用的信號放大器。它有接收端，光纖傳輸和放大器三部分組成。線信放大器的線性范圍和放大倍率是它的主要技術(shù)指標(biāo)。當(dāng)接收信號不在放大器的線性范圍內(nèi)，產(chǎn)生的

41、放大信號就不再是線性的。4. 摩托羅拉公司基于接收電平的功率控制算法。簡單的說就是落在功率控制接收窗口之外，需要相應(yīng)調(diào)整功率?！締栴}解決步驟】 由于只是這一個基站存在單通問題，所以我們把問題定位在基站和相應(yīng)的分布系統(tǒng)上。我們發(fā)現(xiàn)基站的所有載頻都存在該問題，所以與載頻硬件無關(guān)。檢查基站到BSC傳輸，也不存在傳輸質(zhì)量問題。所以，問題更像是無線環(huán)境造成。通過實地使用tems手機(jī)測打，發(fā)現(xiàn)下行接收電平和話音質(zhì)量都很好，這與手機(jī)聽對方來電非常清楚相一致。Tems手機(jī)無法檢測手機(jī)上行的接收電平和質(zhì)量，所以我們采用在OMCR上CTP跟蹤上行數(shù)據(jù)。通過對該基站255個呼叫的跟蹤，我們發(fā)現(xiàn)該基站上行rxlev始

42、終大于20dbm以上，而上行quality卻主要為57級，手機(jī)發(fā)射功率較低。為什么基站上行rxlev會出現(xiàn)始終大于20dbm的奇怪現(xiàn)象呢？我們就此問題與分布廠家進(jìn)行交流，原來問題就是出在分布系統(tǒng)的光纖放大器上。這個廠家的線性放大器技術(shù)指標(biāo)嚴(yán)重不合格，線性范圍只有3db，超出此范圍都嚴(yán)重變型。所以，導(dǎo)致手機(jī)無論如何功率控制，基站接收測的接收電平都在20dbm以上，而話音質(zhì)量極差，導(dǎo)致上行根本聽不清楚。最后，我們將所有的光線放大器去除，直接用7/8饋線連接，問題就解決了。案例5：MM接續(xù)時間過長【問題名稱】 湖北省荊門移動MM接續(xù)時間過長【問題類別】 參數(shù)設(shè)置【相關(guān)設(shè)備】 MSC【問題詳細(xì)描述】M

43、M撥打時，從發(fā)出Channel Request到收到Alerting消息，荊門移動耗時約6.8秒，而武漢為5.3秒。【技術(shù)背景】【問題解決步驟】對于同一系統(tǒng)，尋呼響應(yīng)的快慢在一定程度上影響了接續(xù)的快慢，鑒于荊門系統(tǒng)的尋呼響應(yīng)比武漢平均慢473ms，為此對荊門系統(tǒng)的尋呼分組進(jìn)行重新設(shè)定。尋呼消息的復(fù)幀結(jié)構(gòu)時長為235ms，荊門系統(tǒng)的尋呼分組為5，其對手機(jī)而言，幀長為1175ms；武漢系統(tǒng)的尋呼分組為2，其對手機(jī)而言，幀長為470ms，這樣最大可能導(dǎo)致705ms的時延。在西門子交換機(jī)中，即使不采用CIPHERING過程，但無法在流程上消除，每次MM的接續(xù)，導(dǎo)致470ms的時延。再考慮到目前交換機(jī)的

44、二次尋呼設(shè)置（TPAG為5s），而A接口中測到的尋呼響應(yīng)時間約為1.5s，則完全可以將TPAG改為3s。從而可以大幅度地減少二次尋呼時的接續(xù)時間。在Um接口，未采用跳頻時，收到ASSIGNMENT COMMAND的延時為230ms；而采用跳頻時，收到ASSIGNMENT COMMAND的延時為470ms，兩者有240ms的延時，考慮到主、被叫，則有480ms的延時。案例6：手機(jī)空閑/通話過程突然信號全無【問題名稱】手機(jī)空閑、通話過程中信號全無【問題類別】 路測問題【相關(guān)設(shè)備】天線覆蓋【問題詳細(xì)描述】客戶投訴手機(jī)在空閑狀態(tài)下和通話過程中存在手機(jī)信號突然全無，出現(xiàn)脫網(wǎng)或掉話現(xiàn)象【技術(shù)背景】參考路測

45、分析【問題解決步驟】現(xiàn)場使用TEMS T28S測試發(fā)現(xiàn)確實存在此類現(xiàn)象。1、空閑狀態(tài)下手機(jī)出現(xiàn)了信號全無，信號變化主要集中在小區(qū)重選的時刻，原因是：無主覆蓋信號，而且室內(nèi)信號電平在-95dBm左右，手機(jī)在空閑狀態(tài)下小區(qū)重選頻繁。由于在室內(nèi)的信號存在明顯起伏變化，導(dǎo)致重選過程中會出現(xiàn)了明顯的信號變化；開通室內(nèi)分布系統(tǒng)，服務(wù)小區(qū)信號大于-85dBm，復(fù)測正常；2、通話狀態(tài)下手機(jī)出現(xiàn)了信號全無：A、手機(jī)沒有發(fā)生切換時但接收到的信號電平突然降到-108dBm，多次撥測發(fā)現(xiàn)此現(xiàn)象僅僅出現(xiàn)在該小區(qū)某塊載頻上，判斷為硬件故障，更換載頻后問題解決。B、DT測試中手機(jī)切換到目標(biāo)小區(qū)后信號電平突然降到-100dB

46、m以下，檢查目標(biāo)基站沒有發(fā)現(xiàn)相應(yīng)硬件問題，檢查發(fā)現(xiàn)該小區(qū)還存在與目標(biāo)小區(qū)相同BCCH的相鄰小區(qū)（BSIC不相同），這兩個目標(biāo)鄰區(qū)分別覆蓋兩條垂直交叉的街道，手機(jī)的快速運動造成系統(tǒng)誤判斷，命令手機(jī)切換到錯誤的目標(biāo)小區(qū)，接收到的信號電平非常低。修改其中一個小區(qū)的BCCH后問題解決。（本次測試中T28S在-104dBm時表現(xiàn)為信號全無）案例7：PCMCIA卡故障造成基站不能正常CODE LOAD【問題名稱】PCMCIA卡故障【問題類別】 硬件故障【相關(guān)設(shè)備】PCMACIA卡【問題詳細(xì)描述】某個基站開通正常后，撥打測試通話也正常。但是運行一段時間后就會反復(fù)loading基站不能正常服務(wù)【技術(shù)背景】1C

47、SFP下載過程中的問題【問題解決步驟】1到現(xiàn)場測試發(fā)現(xiàn)原來SC0中的PCMCIA卡有故障造成基站在下載數(shù)據(jù)時由于要檢測SC0板及板中的PCMCIA卡，當(dāng)SC0中有卡時，BSC在下載DATABAIS會給該卡寫數(shù)據(jù)，由于PCMCIA卡本身故障造成BSC反反復(fù)復(fù)不斷的檢查不停Loading,造成數(shù)據(jù)正常不能下載SC0板導(dǎo)致基站不能重啟到正常狀態(tài)。取出該PCMCIA卡后20分鐘基站進(jìn)入服務(wù)狀態(tài)，撥打測試正常。案例8：避雷器故障造成基站IOI高【問題名稱】避雷器故障造成基站IOI高【問題類別】 硬件故障【相關(guān)設(shè)備】避雷器【問題詳細(xì)描述】高ma_fail_from_ms，所有載波都比較高，且ioi較高（1

48、2-23）；通話質(zhì)量差，掉話高【技術(shù)背景】1硬件損壞【問題解決步驟】1、調(diào)測基站收發(fā)，饋線的阻波比正常；2、更換基站的主要器件，如TCU、SURF等沒有效果。3、DT測試信號強(qiáng)度正常，稍遠(yuǎn)處話音質(zhì)量就變差； 4、最終更換避雷器件后，故障消除，指標(biāo)正常 案例9：硬件連接與數(shù)據(jù)定義錯誤造成基站PB值高【問題名稱】硬件連接與數(shù)據(jù)定義錯誤造成基站PB值高【問題類別】 硬件連接與數(shù)據(jù)定義錯誤【相關(guān)設(shè)備】DLNB【問題詳細(xì)描述】對于一批基站的第三扇區(qū)，出現(xiàn)掉話率高，PATH_BALANCE 偏高的現(xiàn)象，該扇區(qū)的SDCCH RFLOSS也較高?！炯夹g(shù)背景】1 硬件連接2 DATD BASIE【問題解決步驟】

49、1從統(tǒng)計看，此類基站的第三扇區(qū)的所有載頻的PATH_BALANCE都偏低，顯示扇區(qū)接收較差，而且不是個別載頻的硬件問題。2. 由于該問題在第一、二扇區(qū)沒有出現(xiàn)，所以非常令人奇怪。3. 檢查該基站的數(shù)據(jù)庫配置，三個扇區(qū)完全一樣，所以很奇怪。4. 我們后來發(fā)現(xiàn)這些基站都是在2個機(jī)柜內(nèi)配置3各扇區(qū)的，這就使我們想到了是否在硬件配置上與普通的3個機(jī)柜內(nèi)分別配置三個扇區(qū)的基站有什么區(qū)別。最后我們發(fā)現(xiàn)原來是DLNB的連接問題。這些基站的第三扇區(qū)的接收天線是連接在第三個DLNB而不是常規(guī)的第一個。而我們的數(shù)據(jù)庫設(shè)置中該扇區(qū)每個載頻的antenna select number都是1。這樣就造成了天饋接收問題。

50、5. 綜上所述，每個載頻的antenna select number必須與實際的DLNB連接相一致，否則就會造成嚴(yán)重的掉話問題。案例10：外部干擾【問題名稱】外部干擾引起斷噪【問題類別】外部干擾 【相關(guān)設(shè)備】外部干擾源【問題詳細(xì)描述】重陽賓館的205房呼叫體育賓館的三樓過道,主叫小區(qū)為:51223,問題現(xiàn)象為:斷噪.【技術(shù)背景】外部干擾引起斷噪【問題解決步驟】1. 信號電平在75dbm,初步判斷非覆蓋弱造成 2.鎖住載頻，逐個撥打，均出現(xiàn)此問題 3.通過掃頻，發(fā)現(xiàn)整個頻段信號強(qiáng)度很均勻 4.定位為外部干擾，經(jīng)過掃頻儀測量后，定位了干擾源。案例11：分布系統(tǒng)引起起呼、被叫成功率低【問題名稱】分布

51、系統(tǒng)引起起呼被叫成功率低【問題類別】分布系統(tǒng) 【相關(guān)設(shè)備】分布系統(tǒng)【問題詳細(xì)描述】在測試中發(fā)現(xiàn)問題主要在局部發(fā)生，問題電話信令都為起呼/被叫在Channel Request后無SD分配命令?，F(xiàn)場測試發(fā)現(xiàn)，占同一載頻上通話，在問題區(qū)域手機(jī)接收電平不穩(wěn)定，手機(jī)功率控制遲緩，而其以外區(qū)域手機(jī)接收正常電平穩(wěn)定，手機(jī)功率控制靈敏【技術(shù)背景】分布系統(tǒng)問題【問題解決步驟】1. 檢查分布系統(tǒng)的這條天線通路發(fā)現(xiàn)存在故障，處理后正常。案例12：分布系統(tǒng)天線設(shè)計不合理造成的問題【問題名稱】分布系統(tǒng)引起起呼被叫成功率低【問題類別】室內(nèi)系統(tǒng)/定點測試 【相關(guān)設(shè)備】室內(nèi)分布系統(tǒng)【問題詳細(xì)描述】某微蜂窩采用室內(nèi)分布天線系統(tǒng)，從OMCR統(tǒng)計來看，在其忙時(19:0020:00)，由于主要話務(wù)量集中在2樓飯廳，接通率及切換成功率較高，分別在95和93以上，話務(wù)量在3.3愛爾蘭左右，但在其他時段，平均話務(wù)量不超過0.8愛爾蘭，接通率及切換成功率分別在89和 90左右【技術(shù)背景】分布系