阻塞引起的呼叫困難分析

摘 要：文章對(duì)阻塞引起的呼叫困難問(wèn)題進(jìn)行了描述，分別從基站OM報(bào)告分析、MTX相關(guān)表格分析、硬件檢查等幾大原因進(jìn)行了分析。

關(guān)鍵詞：阻塞；OM；MTX

1 引言

在日常對(duì)設(shè)備維護(hù)的過(guò)程中，經(jīng)常會(huì)遇到各種各樣的網(wǎng)絡(luò)問(wèn)題，有的在網(wǎng)管上有告警，有的沒(méi)有。有告警可以根據(jù)告警信息判斷問(wèn)題，這對(duì)故障點(diǎn)的定位提供了很大方便，特別是單板類(lèi)故障，基本能從告警的內(nèi)容確定問(wèn)題。但是有時(shí)候網(wǎng)絡(luò)問(wèn)題并不能從告警上體現(xiàn)出來(lái)，或者說(shuō)不能從告警上直接判斷問(wèn)題所在。就需要我們通過(guò)對(duì)話(huà)務(wù)統(tǒng)計(jì)報(bào)告分析和用戶(hù)的投訴等途徑發(fā)現(xiàn)，通常這類(lèi)問(wèn)題比較隱蔽，對(duì)故障的定位和處理也比較復(fù)雜，這就要求我們能夠從平常的工作中總結(jié)經(jīng)驗(yàn)，保持清醒冷靜的頭腦仔細(xì)地、按照設(shè)備運(yùn)行的原理逐段進(jìn)行分析。呼叫阻塞引起呼叫困難就是這種狀況的一個(gè)典型例子，下面以北電設(shè)備為例，就這個(gè)問(wèn)題介紹一下詳細(xì)的分析處理過(guò)程。

2 問(wèn)題描述

有用戶(hù)投訴在某個(gè)區(qū)域打電話(huà)困難，在網(wǎng)管系統(tǒng)上提取報(bào)告顯示呼叫阻塞次數(shù)和呼叫阻塞比例較高，在MTX的有關(guān)報(bào)告上顯示有阻塞現(xiàn)象，超出了日常的正常范圍。

3 故障現(xiàn)象

基站下的用戶(hù)出現(xiàn)主、被叫（僅限語(yǔ)音業(yè)務(wù)）困難。

4 故障排查

4.1 基站OM報(bào)告的分析

4.2 MTX的相關(guān)表格的分析

主要查看CAUCPSCT（2G語(yǔ)音）、CAUSCT3V（3G語(yǔ)音）、CAUSCT3D（3D數(shù)據(jù)）三張表格數(shù)據(jù)。

CAUCPSCT：基站2G語(yǔ)音話(huà)務(wù)統(tǒng)計(jì)，重點(diǎn)查看CAUPGRES（MTX系統(tǒng)收到的尋呼回應(yīng)數(shù)）、CAUTSUCC（被叫建立成功率）、CAUTRLS：（被叫釋放（拒接））、CAUTBLKS（被叫阻塞數(shù)）參數(shù)。正常情況下CAUPGRES值應(yīng)是CAUTSUCC與CAUTRLS的和相同或非常接近。如果CAUTBLKS參數(shù)值非零則說(shuō)明出現(xiàn)被叫阻塞；CAUOATTS（主叫起呼數(shù)）、CAUOSUCC（主叫起呼成功數(shù)）、CAUORLS（主叫釋放數(shù)）、CAUOBLKS（主叫阻塞數(shù)），這四個(gè)參數(shù)之間的關(guān)系與前面的四個(gè)參數(shù)是一樣的；CAUEDLOT（丟失業(yè)務(wù)信道導(dǎo)致的接入失敗數(shù)）、CAUERSFL（由于BTS無(wú)線鏈路資源不足導(dǎo)致的失敗數(shù)）、CAUERLFL（由于不能與主叫或被叫手機(jī)建立無(wú)線鏈路導(dǎo)致的失敗數(shù)）、CAUESWFL（由于軟件運(yùn)行錯(cuò)誤導(dǎo)致的失敗數(shù)）是關(guān)于說(shuō)明阻塞原因的幾個(gè)主要參數(shù)。

CAUSCT3V：對(duì)3G手機(jī)的語(yǔ)音業(yè)務(wù)進(jìn)行統(tǒng)計(jì)。其參數(shù)類(lèi)型和功能與CAUCPSCT表格中的基本相同，對(duì)由于缺少特定資源導(dǎo)致的呼叫阻塞設(shè)定了專(zhuān)門(mén)的參數(shù)（例如：BTS前、反向鏈路資源不足，TCE資源不足等）。

CAUSCT3D：對(duì)3G手機(jī)的數(shù)據(jù)業(yè)務(wù)進(jìn)行統(tǒng)計(jì)。其參數(shù)類(lèi)型和功能與以上兩個(gè)表格中的基本相同，CAUNOFOF（由于沒(méi)有幀偏置導(dǎo)致數(shù)據(jù)業(yè)務(wù)失敗）參數(shù)單獨(dú)用于對(duì)數(shù)據(jù)業(yè)務(wù)統(tǒng)計(jì)的。

另外，故障時(shí)還應(yīng)注意查看RMU中SBS資源是否正常重點(diǎn)查看SST參數(shù)是否為AV狀態(tài)，DATAST參數(shù)設(shè)置該ESEL卡是否支持?jǐn)?shù)據(jù)業(yè)務(wù)，并確定該卡的數(shù)率。

4.3 硬件檢查及其相關(guān)參數(shù)

4.3.1 傳輸鏈路故障導(dǎo)致呼叫阻塞

傳輸鏈路質(zhì)量的好壞直接影響話(huà)務(wù)能否正常建立，傳輸鏈路的好、壞主要由誤碼率的大小，以及在多條鏈路情況下多條鏈路之間是否同步這兩個(gè)最主要的因素決定。在阻塞發(fā)生時(shí)查看是否有T1E1Trunk的告警，在打開(kāi)LinkQuality monitor功能時(shí)查看 T1E1Trunk MO下LinkQuality的數(shù)值（正常情況下應(yīng)都為零，數(shù)值越大鏈路質(zhì)量越差）。必要時(shí)檢查CDSU的設(shè)置是否有誤。通過(guò)基站性能報(bào)告可以查看T1E1Trunk MO下LinkQuality的歷史紀(jì)錄。

4.3.2 外部干擾導(dǎo)致呼叫阻塞

重點(diǎn)檢查RxPower、RxNoisePower值是否過(guò)大，其值越大撥打電話(huà)越困難。通過(guò)對(duì)基站性能報(bào)告的PowerManagement MO參數(shù)值的查看可以了解 RxNoisePower參數(shù)的歷史記錄。在出現(xiàn)呼叫阻塞時(shí)還應(yīng)檢查“SectorAnaLogAtten”參數(shù)值，是否出現(xiàn)31，0，1等不正常的現(xiàn)象，如有不正常使用網(wǎng)絡(luò)分析儀進(jìn)行測(cè)試以便確定是外部干擾，還是硬件出現(xiàn)故障。

4.4 其他原因

通過(guò)上面的分析，我們基本可以找出故障的原因，如果我們還是沒(méi)有查出問(wèn)題的原因，或者該基站不定期的出現(xiàn)阻塞，這時(shí)候我們就應(yīng)該把故障點(diǎn)的范圍擴(kuò)展開(kāi)來(lái)考慮，是不是BSC內(nèi)的相關(guān)鏈路出了問(wèn)題，如DISCO的Port端口，查看他的硬件運(yùn)行情況以及相應(yīng)的軟件參數(shù)，重點(diǎn)檢查下面的設(shè)置DisBroadcastAddressOffsetFrom0xFFFFF0應(yīng)設(shè)為“True”，其他為參數(shù)應(yīng)設(shè)置為“1”。

5 結(jié)束語(yǔ)

故障的現(xiàn)象是多樣的，故障的原因也是有很多種，但是萬(wàn)變不離其中的是通信原理。只要我們掌握正確的故障處理方法，能夠在出現(xiàn)故障的時(shí)候保持一個(gè)清醒的頭腦，冷靜地按照上面的方法認(rèn)真分析，按照信息的傳送流程，一段一段地測(cè)試、排查，我相信，我們一定能夠找出故障點(diǎn)，找出問(wèn)題的所在，從而徹底解決問(wèn)題。