【正文】 RENCE。告警說(shuō)明：在監(jiān)控時(shí)段內(nèi)，TCH時(shí)隙在空閑模式下遭受的干擾太大，已經(jīng)超過(guò)定義的告警門限值。及在時(shí)隙內(nèi)的干擾的持續(xù)時(shí)間超出可接受的值。處理思路：首先確定受干擾的范圍，查看周圍基站是否也出現(xiàn)干擾，如果也出現(xiàn)，且干擾級(jí)別較高，則可確定是外部干擾，需要用干擾測(cè)試設(shè)備現(xiàn)場(chǎng)測(cè)量，找出干擾源。如果只是某個(gè)頻段出現(xiàn)干擾，比如同一小區(qū)，使用低頻點(diǎn)有干擾而使用高頻點(diǎn)沒(méi)有干擾，則有可能是附近聯(lián)通基站產(chǎn)生的干擾，需要現(xiàn)場(chǎng)測(cè)試，并由互聯(lián)互通部門協(xié)調(diào)解決。如果只有一個(gè)小區(qū)的某個(gè)載頻出現(xiàn)干擾，則可能是內(nèi)部干擾，其產(chǎn)生原因有可能是載頻故障，也可能是頻點(diǎn)干擾。在使用基帶跳頻或者無(wú)跳頻小區(qū)，將干擾載頻的頻點(diǎn)與無(wú)干擾載頻的頻點(diǎn)互換，如果干擾仍出現(xiàn)在同一載頻上，則可判斷是載頻故障，需要更換載頻。如果出現(xiàn)在同一頻點(diǎn)上，則需要通過(guò)調(diào)整頻點(diǎn)來(lái)解決。如果使用射頻跳頻的小區(qū)出現(xiàn)某個(gè)載頻干擾，則可判斷是載頻故障，需要更換載頻。7745 CHANNEL FAILURE RATE ABOVE DEFINEN THRESHOLD。告警說(shuō)明：在一個(gè)信道中，呼叫因失敗而終止的比例超過(guò)了門限值。該告警用來(lái)監(jiān)控話務(wù)和信令信道的功能，并檢測(cè)可能出故障的信道。處理思路：先查看是否有其他告警，如7744干擾，或者其他硬件故障告警，如果有，則先處理這些告警，如果這些告警處理后，7745告警仍然存在，則可判斷為載頻出現(xiàn)故障?？上葘⒊霈F(xiàn)告警的載頻重啟，如果重啟后告警仍然存在，則更換該載頻。第四章 Nokia 告警補(bǔ)充信息字段告警補(bǔ)充信息字段：1－6 XX XX XX XX XX XX 1 2 3 4 5 6各字段內(nèi)容：機(jī)架（機(jī)柜）編號(hào) 支撐架編號(hào) 插槽單元類型 單元編號(hào) 子單元編號(hào)單元類型數(shù)字與單元名稱對(duì)照說(shuō)明：DE34UltraSiteMetroSite單元編號(hào)對(duì)應(yīng)板件單元編號(hào)對(duì)應(yīng)板件單元編號(hào)對(duì)應(yīng)板件38BCFA96BOIA7BVIFA39CCFA97BB2x7CFAN3CPSUA98TSGx7DTRE3ERMUA9ARTGA45TRUA9BDVGA45TRXA9CPWSB4CRTCC9DVXTA4ECSUA9EBLOx第五章 案例分析：故障案例分析一：駐馬店市區(qū)劉閣基站（DE34）TRX2有7533告警（TX ANTENNA OR CONBINER CONNECTION FAULTY）由于連接在同一個(gè)合路器上的TRX1工作正常，初步判斷AFEA沒(méi)有故障，TX連線緊固，則判斷可能是TRX壞或者TX連線壞，更換TRX后故障解除。但是到3月9號(hào)，TRX2再次出現(xiàn)7533告警，由于TRX為新?lián)Q的，TX連線無(wú)故障，分析認(rèn)為合路器AFEA不穩(wěn)定，存在隱患，更換AFE后故障解除，沒(méi)有重復(fù)出現(xiàn)。故障案例分析二：西平人和基站（DE34）BCFA故障，更換后無(wú)法自啟，檢查發(fā)現(xiàn)軟件包不對(duì)應(yīng)（使用的板件是返修的庫(kù)存板件，沒(méi)有考慮軟件包問(wèn)題），灌入對(duì)應(yīng)軟件包重啟后，Sec2和Sec3無(wú)法正常工作，其中Sec2的TRX7正常，而TRX8和Sec3的TRX9和TRX10均有7514告警（13MHZ CLOCK IS MISSING IN TRX）按照Nokia告警處理提示應(yīng)更換TRX，但三塊TRX同時(shí)壞的可能性不大，考慮可能為其他原因引起。于是將Sec2正常運(yùn)行的TRX7和出故障的TRX8倒換位置，（操作過(guò)程中對(duì)該層PSUA斷電）結(jié)果Sec2兩塊TRX均恢復(fù)正常。于是將Sec3的PSUA斷電再加電，該扇區(qū)亦恢復(fù)正常。分析認(rèn)為有時(shí)TRX內(nèi)部軟件需要重新掉電初始化。這一點(diǎn)和后來(lái)改半速率過(guò)程中，有些DE34站雖然數(shù)據(jù)與BSC完全對(duì)應(yīng)，仍然出現(xiàn)OMU信令不活的現(xiàn)象類似，出現(xiàn)這種情況時(shí)，對(duì)基站供電單元CSUA掉電再加電就可以解決。故障案例分析三：遂平紅堂基站（UltraSite）O改S后，Sec1一直占不上用戶，且有7602（Mismatch between BSC/MMI configuration file and the actual）告警，經(jīng)檢查發(fā)現(xiàn)，硬件數(shù)據(jù)庫(kù)中Sec1的數(shù)據(jù)不完整，補(bǔ)充完整后再上傳進(jìn)去，重啟BCF，故障解除。故障案例分析四：婦幼保健院（ULTRASITE）斷站，且斷站時(shí)有7606告警，告警提示為合路器反射功率過(guò)高。根據(jù)以往經(jīng)驗(yàn)，產(chǎn)生這個(gè)告警的原因有兩種，駐波比過(guò)高或合路器壞，測(cè)試駐波比正常，更換合路器重起基站后告警消失，后期觀察沒(méi)有再出現(xiàn)這個(gè)告警。故障案例分析五：市區(qū)502基站（ULTRASITE）的SEC3反復(fù)閃斷，有7705，7706，7723，8102等告警。到基站后發(fā)現(xiàn)傳輸板時(shí)而亮黃燈，時(shí)而亮綠燈，并且掉話非常明顯。因?yàn)橛袀鬏敻婢韵葟膫鬏敯?、傳輸連接件和傳輸線考慮。自環(huán)傳輸板正常，檢查DDF架。結(jié)果發(fā)現(xiàn)DDF架的2M接頭松動(dòng)，緊固后傳輸板沒(méi)有再出現(xiàn)間歇性閃爍，基站正常運(yùn)行。故障案例分析六：駐馬店市區(qū)關(guān)王廟基站（UltraSite）的Sec2反復(fù)出現(xiàn)7604告警（Rx levels differ too much between main and diversity antennas），造成嚴(yán)重掉話。測(cè)量天線駐波比正常，更換寬帶合路器WCGA和雙工器DVGA仍不能解決，對(duì)基站主設(shè)備徹底檢測(cè)確定正常，檢查天饋部分，發(fā)現(xiàn)饋線進(jìn)入機(jī)房后的接頭處松動(dòng)，重做接頭并緊固后告警消除。對(duì)此故障分析認(rèn)為，有時(shí)天饋系統(tǒng)的駐波比正常，并不能說(shuō)明故障一定不是出在天饋系統(tǒng)。有些并不嚴(yán)重的連接松動(dòng)情況可能無(wú)法在駐波比中顯示。因此在處理這類故障的時(shí)候，測(cè)量天饋系統(tǒng)的參數(shù)只是判斷故障的一個(gè)參考，還需要對(duì)連接部分進(jìn)行仔細(xì)的檢查。故障案例分析七：西平后呂基站（DE34）白天更改硬件，加載頻，數(shù)據(jù)更改完之后，夜間重啟后無(wú)法起站。經(jīng)現(xiàn)場(chǎng)檢查，發(fā)現(xiàn)硬件數(shù)據(jù)庫(kù)中的TRXSIG速率不對(duì)，更改后恢復(fù)正常。據(jù)機(jī)務(wù)員改動(dòng)數(shù)據(jù)的過(guò)程，發(fā)現(xiàn)一個(gè)平時(shí)沒(méi)有特別注意到的一個(gè)細(xì)節(jié)問(wèn)題。DE34基站在在硬件數(shù)據(jù)庫(kù)上改動(dòng)TRX的位置或者添加、刪除TRX時(shí)，TRXSIG速率會(huì)自動(dòng)更改為全速率數(shù)據(jù)及16K，故需要手動(dòng)更改為半速率數(shù)據(jù)32K之后再上傳。故障案例分析八：確山、泌陽(yáng)割接故障處理：割接之后以下基站不能起站：泌陽(yáng)白果樹(shù)、泌陽(yáng)梅林、泌陽(yáng)條山、泌陽(yáng)老邱洼、確山桐樹(shù)園?，F(xiàn)象都是OMU信令不活。故障處理：泌陽(yáng)梅林—從基站環(huán)路，SXC上ET燈熄滅；斷開(kāi)，入信號(hào)丟失燈亮；放通，ET燈熄滅。即，看起來(lái)，基站到SXC線路正常。機(jī)房確認(rèn)BSC到SXC正常，交叉連接數(shù)據(jù)也正確。機(jī)房和基站對(duì)OMU信令時(shí)隙一致，看起來(lái)，線路和數(shù)據(jù)都正常，懷疑起不來(lái)是基站吊死或數(shù)據(jù)丟失。但是機(jī)務(wù)員冷起過(guò)基站，重做過(guò)數(shù)據(jù)，重做過(guò)開(kāi)通，信令還是不活。而且基站作模擬開(kāi)通，基站能夠起得來(lái)，說(shuō)明基站主設(shè)備沒(méi)有問(wèn)題。現(xiàn)在故障只能定位到物理線路上了，于是聯(lián)系傳輸機(jī)房改落地DDF架位置，之后信令活，起站正常。而之后，在處理白果樹(shù)基站故障時(shí)，發(fā)現(xiàn)白果樹(shù)從基站落地DDF架到SXC環(huán)路不正常，這是環(huán)原梅林落地，兩個(gè)ET燈同時(shí)熄滅。原來(lái)梅林和白果樹(shù)SXC——交叉機(jī)側(cè)DDF架線鴛鴦所致。泌陽(yáng)條山—該站有2個(gè)機(jī)柜，2條傳輸，第一個(gè)機(jī)柜OMU信令在8時(shí)隙，第二個(gè)機(jī)柜OMU信令在2時(shí)隙。當(dāng)晚看到OMU信令不活，懷疑是2個(gè)傳輸弄反，于是改了SXC數(shù)據(jù)，結(jié)果還是不活。待上午，機(jī)務(wù)員到站上環(huán)路發(fā)現(xiàn)，后來(lái)的連接是錯(cuò)的，又改回之前的連接，信令活。本人認(rèn)為可能是傳輸設(shè)備吊死，到基站環(huán)路相當(dāng)于重新激活一下。泌陽(yáng)老邱洼—根據(jù)之上的處理經(jīng)驗(yàn)，我們先查傳輸線是否鴛鴦，結(jié)果發(fā)現(xiàn)是落地線鴛鴦。故障案例分析九：泌陽(yáng)秦老莊邊改宏后基站不能正常工作。到基站后從表面看BCFA亮紅燈，TRUA指示燈正常。對(duì)基站自身重啟后出現(xiàn)7829（ABIS及DBUS接口連接失?。└婢?，分別更換BCFA板及后備板BUS線但告警依舊。然后考慮可能是BCF無(wú)法控制到的TRUA單元存在問(wèn)題，更換TRUA后重啟告警消失，基站恢復(fù)正常。故障案例分析十：汝南綜合樓SEC3所有載頻均出現(xiàn)7745告警，掉話嚴(yán)重，并且有7601告警，到基站后經(jīng)過(guò)檢查發(fā)現(xiàn)時(shí)鐘偏移嚴(yán)重，更改時(shí)鐘DAC數(shù)模轉(zhuǎn)換值，將13MHz時(shí)鐘調(diào)整到誤差允許范圍內(nèi)，重啟BCF后正常，可不久又再次出現(xiàn)時(shí)鐘偏移現(xiàn)象。檢查數(shù)據(jù)發(fā)現(xiàn)是由于沒(méi)有設(shè)置傳輸板的時(shí)鐘同步造成的，（汝南機(jī)務(wù)員在前一天處理8150告警時(shí)更換了傳輸板）。設(shè)置傳輸同步并重作開(kāi)通后基站恢復(fù)。對(duì)此故障的處理反映出一個(gè)問(wèn)題，就是我們?cè)诟鼡Q基站的板件時(shí)，一定要注意對(duì)此板件的配置，還要注意更換板件是否對(duì)其他板件的配置產(chǎn)生影響?；鞠到y(tǒng)是一個(gè)整體，要注意板件之間的關(guān)聯(lián)，這樣才能使整個(gè)系統(tǒng)運(yùn)行正常。與此類似的故障還有一例：汝南陶橋（DE34）新開(kāi)基站,開(kāi)站時(shí)傳輸板一直亮黃燈，信令不活。檢查數(shù)據(jù)庫(kù)、分支表、BCF接口設(shè)置都正確。因此考慮傳輸原因，從DDF架直接環(huán)到交換機(jī)房的ET，狀態(tài)正常，對(duì)基站自環(huán)傳輸板亮黃燈，初步判斷可能是傳輸板故障，更換傳輸板后情況相同。最后注意到兩個(gè)傳輸板都比較新，考慮可能是傳輸板沒(méi)有格式化。于是對(duì)傳輸板進(jìn)行格式化，重新配置分支表并激活，傳輸板恢復(fù)正常。分析認(rèn)為：隨著 DE34數(shù)量越來(lái)越少，傳輸板大多是舊板返修過(guò)的，一般不用進(jìn)行格式化。但如果是全新的板子，就需要對(duì)其進(jìn)行格式化之后再配置數(shù)據(jù)。故障案例分析十一：泌陽(yáng)消防隊(duì)(UltraSite)O改S后基站沒(méi)有告警但是一直起不來(lái)，只有Sec3有兩塊載頻能起來(lái)。到現(xiàn)場(chǎng)檢查基站數(shù)據(jù)完整，比較發(fā)現(xiàn)，能起來(lái)的載頻基帶部分為BB2A，其余載頻基帶部分均為BB2F，于是懷疑BSC軟件包版本偏低，與交換機(jī)房交流證實(shí)了是軟件版本原因，機(jī)房更換高版本軟件包后重啟，基站恢復(fù)正常。此故障說(shuō)明，我們?cè)谔幚砉收蠒r(shí)一定要注意到細(xì)節(jié)的問(wèn)題，善于比較和分析，這樣對(duì)一些雖然有故障卻并沒(méi)有相關(guān)告警提示的障礙才能做出快速準(zhǔn)確的判斷。故障案例分析十二：市區(qū)劉閣基站（ULTRA）擴(kuò)容，與機(jī)房聯(lián)系后知道TRX8位置為空位，到基站后加上載頻，把相應(yīng)的數(shù)據(jù)庫(kù)和分支表做全后，重啟基站，發(fā)現(xiàn)第TRX8一直不能被BOIA識(shí)別，重新檢查軟件和硬件確認(rèn)無(wú)誤后，故障依然存在，和TRX6調(diào)換后，該載頻在TRX6位置可以被識(shí)別，TRX8位置的載頻仍然不能被識(shí)別。建到第10塊空位置后，也不能被識(shí)別，因此判斷是下面六塊的公共部分。使用的是DVGA和WCGA，檢查電源BUS線并更換后，故障依然存在，檢查從主控層到下面兩層的BUS線，發(fā)現(xiàn)連接下層載頻的BUS線斷裂松動(dòng)，重新緊固后重啟，基站恢復(fù)正常。故障案例分析十三：汝南陶橋(DE34)斷站，O3配置,合路器用的是RTC ,起站過(guò)程中BCCH信令在TRX1,TRX2,TRX3上來(lái)回跳躍，基站起來(lái)后隨即中斷，且有7842關(guān)于合路器的告警，更換RTCC后重起告警消失，基站恢復(fù)正常。故障案例分析十四：西平南王莊(UltraSite)新開(kāi)基站，開(kāi)站后機(jī)房通知SEC2，3占不上用戶，且沒(méi)有和設(shè)備相關(guān)的告警。到站后檢查發(fā)現(xiàn)BIOA中沒(méi)有硬件數(shù)據(jù)庫(kù)數(shù)據(jù)，重做數(shù)據(jù)庫(kù)并上載后基站正常工作。分析原因可能是灌完數(shù)據(jù)庫(kù)后沒(méi)檢查，而數(shù)據(jù)庫(kù)又沒(méi)有正常灌入；另外一種可能是NOKIA工程師做數(shù)據(jù)庫(kù)時(shí)用的Nokia BTS 版本，由于配套設(shè)備不同步，沒(méi)能及時(shí)開(kāi)站，后來(lái)開(kāi)站時(shí)對(duì)基站做開(kāi)通所用的Nokia BTS ，這種情況下會(huì)導(dǎo)致數(shù)據(jù)庫(kù)丟失。故障案例分析十五：市區(qū)農(nóng)行基站（MetroSite）傳輸板出現(xiàn)故障，經(jīng)常閃段，需要更換傳輸板，可BTS Manager一直連接不到基站，測(cè)量連接線正常，檢查電腦口也正常，后來(lái)在File項(xiàng)下Options子項(xiàng)中把口的連接速率從115200改為9600，順利連接到基站。如下圖所示：后來(lái)市區(qū)新華書店基站（ConnectSite）也出現(xiàn)連接不上故障，修改連接速率后便順利連上。故障案例分析十六：駐馬店市區(qū)工行產(chǎn)生7601 BCF OPERATION DEGRADED告警和7607 Fault in the chain between power unit and MHA告警，到站后發(fā)現(xiàn)告警情況如下圖示：檢查硬件數(shù)據(jù)庫(kù)發(fā)現(xiàn)把MHA Type設(shè)置成了High gain MHA，而實(shí)際沒(méi)有使用MHA，更改數(shù)據(jù)并上傳后故障解決。71 / 71