【資料名稱】：BSS常見告警

【資料作者】：流川楓

【資料日期】：2011年8月9日

【資料語言】：中文

【資料格式】：PDF

【資料目錄和簡(jiǎn)介】：

BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 1 -
引 言
機(jī)房運(yùn)行維護(hù)人員經(jīng)常會(huì)碰到告警 有些告警是操作維護(hù)過程中自然產(chǎn)生的 有
些告警是瞬時(shí)性的不會(huì)影響系統(tǒng)正常運(yùn)行 但大多數(shù)告警是會(huì)影響系統(tǒng)性能的 有
的甚至?xí)��?dǎo)致BSS 復(fù)位對(duì)移動(dòng)通信系統(tǒng)造成嚴(yán)重影響 因此對(duì)于運(yùn)維人員來說 了
解告警系統(tǒng)掌握一定的告警分析和處理技能 顯得非常重要 本文檔正是從這個(gè)角
度出發(fā)簡(jiǎn)單介紹了MOTOROLA 移動(dòng)系統(tǒng)產(chǎn)品的告警系統(tǒng)和告警格式并詳細(xì)分析了
常見的十類BSS 告警我們希望通過告警分析能夠幫助運(yùn)維人員提高分析處理告警
的能力
本文檔包括兩部分主要內(nèi)容前一部分介紹了MOTOROLA 產(chǎn)品的告警系統(tǒng)和告警
格式后一部分深入分析了常見的十類BSS 告警在本文結(jié)束前給出了在處理告警時(shí)
一些需要注意的東西
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 2 -
第一部分 MOTOROLA 移動(dòng)系統(tǒng)產(chǎn)品的告警系統(tǒng)和告警格式
MOTOROLA 的告警系統(tǒng)是為了故障定位系統(tǒng)性能分析及方便維護(hù)而設(shè)置的
告警信息可以在OMCR的告警窗口上顯示也可以在本地維護(hù)終端LMT 上顯示
BSS 產(chǎn)生的告警信息以字符的形式發(fā)往OMCR 也可以通過命令設(shè)置使告警顯示在
LMT 上
告警可以分為硬件告警和軟件告警兩種
硬件告警是由于BSS 內(nèi)的硬件故障所引起的告警
軟件告警是由GPROC 檢測(cè)到軟件進(jìn)程運(yùn)行出錯(cuò)所引起的告警
只有GPROC 設(shè)備BSP CSFP DHP BTP pool GPROC 才會(huì)產(chǎn)生軟件告警信息
軟件告警Software Fault Management或SWFM 分為兩類
Fatal 和non-fatal 軟件告警
軟件告警SWFM類型等級(jí) 影響
NON-fatal 警告SWFM 調(diào)用相應(yīng)的進(jìn)程來恢復(fù)軟
件錯(cuò)誤
SWFM
Fatal 嚴(yán)重SWFM 將GPROC reset
下面通過一個(gè)告警實(shí)例來了解MOTOROLA產(chǎn)品的告警格式
下述是一個(gè)OMCR 上顯示的告警實(shí)例
#0 – NEW – *NONE*.
CommuncationFailureEvent - CAGE - BSS01(BSS01:SITE-0: 0 CAGE 1 - 30/03/1999
14:23:56.
[18] Expansion KSWX Slot 22 Communication Failure - FMIC - Major - -/-.
(BSS01:SITE-0:0 SITE Impacted to Major.
字段意義
#0 告警ID
NEW 告警狀態(tài)
NONE 正在處理此告警的人員
CommuncationFailureEvent 告警的類型
在 OMCR 將告警分成六種不同的類型可以在OMCR 的告警說明中找到
"FailureEvents" 字段其為不同類型告警的名稱
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 3 -
類型 含義 舉例
Communication 數(shù)據(jù)從一點(diǎn)傳到另一點(diǎn)時(shí)發(fā)
生錯(cuò)誤而產(chǎn)生的告警
一般當(dāng)信令丟失或呼叫建立出
錯(cuò)時(shí)發(fā)生此種告警
Quality of Service 系統(tǒng)的服務(wù)質(zhì)量下降時(shí)產(chǎn)生
此告警
一般當(dāng)消息響應(yīng)超時(shí)或帶寬減
少時(shí)會(huì)發(fā)生此種告警
Processing 當(dāng)軟件或進(jìn)程出現(xiàn)錯(cuò)誤時(shí)產(chǎn)
生此告警
一般當(dāng)進(jìn)程數(shù)據(jù)被破壞或系統(tǒng)
內(nèi)存溢出時(shí)產(chǎn)生此種告警
Equipment 當(dāng)硬件出錯(cuò)時(shí)產(chǎn)生此告警一般當(dāng)出現(xiàn)配置錯(cuò)誤傳輸 電
源等問題時(shí)產(chǎn)生此種告警
Environment 當(dāng)設(shè)備所處的環(huán)境不利于正
常工作時(shí)產(chǎn)生告警
一般當(dāng)出現(xiàn)煙霧火光被檢測(cè)到
時(shí)產(chǎn)生此種告警
Link 當(dāng) OMCR 與BSS 間的X.25 鏈
路出現(xiàn)問題時(shí)產(chǎn)生此告警
CAGE 告警級(jí)
BSS01(BSS01:SITE-0: 0 CAGE 1 發(fā)生告警的位置
30/03/1999 14:23:56 告警發(fā)生時(shí)間
[18] 告警編號(hào)
告警編號(hào)對(duì)于每種設(shè)備都有唯一的一個(gè)十進(jìn)制數(shù)表示每種設(shè)備的告警編號(hào)從0
到254 對(duì)于不同的設(shè)備告警編號(hào)可能重復(fù)但與設(shè)備相關(guān)的編號(hào)是唯一的有些情
況下同樣的告警編號(hào)表示類似的告警例如254 號(hào)告警表示設(shè)備fail
Expansion KSWX Slot 22 Communication Failure 告警描述
FMIC 告警的清除類型
告警的清除類型可分為三類
Intermittent
Fault Management Initiated Clear FMIC
Operator Initiated Clear OIC
第一類表示告警是偶發(fā)性的對(duì)系統(tǒng)沒有危害因此此告警發(fā)生后在OMCR 會(huì)
自動(dòng)消除當(dāng)此類告警產(chǎn)生太頻繁會(huì)造成到 OML鏈路負(fù)擔(dān)過重因此用戶可以使用
兩條命令查看調(diào)節(jié)此類告警向OMCR報(bào)告的量
disp_throttle <device_name> <alarm_code>
chg_throttle <device_name> <alarm_code> <throttle_count>
第二類和第三類為持續(xù)性的告警當(dāng)告警原因消失后需要將此告警清除
第二類告警的清除由系統(tǒng)的錯(cuò)誤管理進(jìn)程Fault Managerment Process 自
動(dòng)將其清除FM 進(jìn)程管理一張現(xiàn)有告警的列表只有當(dāng)告警產(chǎn)生的原因消失后FM 才
會(huì)產(chǎn)生clear’消息將此告警從告警列表中刪除
第三類需要由操作人員手動(dòng)將告警清除FM 進(jìn)程檢測(cè)到告警產(chǎn)生并判斷為OIC
類型時(shí)將此告警加入現(xiàn)有告警列表中此后FM 不再進(jìn)行任何處理當(dāng)操作人員將
告警產(chǎn)生的原因解決后必須將此告警清除
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 4 -
Major 告警嚴(yán)重等級(jí)
告警嚴(yán)重級(jí)別表明此故障發(fā)生對(duì)系統(tǒng)的影響程度系統(tǒng)將告警的等級(jí)分為6 級(jí)
影響 行動(dòng) 舉例
嚴(yán)重
(Critical)
已經(jīng)影響了系統(tǒng)的服務(wù)應(yīng)該立即采取措施當(dāng)系統(tǒng)的某一功能出現(xiàn)此種告
警而退出服務(wù)應(yīng)立即將其恢
復(fù)
重大
(Major)
已經(jīng)影響了系統(tǒng)的服務(wù)應(yīng)該馬上采取措施系統(tǒng)的服務(wù)容量降低此時(shí)應(yīng)
采取措施恢復(fù)容量
較輕
(Minor)
此錯(cuò)誤不會(huì)對(duì)系統(tǒng)的服
務(wù)造成影響
應(yīng)該采取措施減少
更多的此類告警產(chǎn)
生
當(dāng)此種告警數(shù)量不斷增加時(shí)
系統(tǒng)的容量可能受到影響
警告
(Waring)
潛在產(chǎn)生影響系統(tǒng)服務(wù)
的告警的可能
如果必要應(yīng)該進(jìn)行
必要的分析采取
措施避免產(chǎn)生更嚴(yán)
重的告警
清除
(Clear)
告警已經(jīng)被清除無
待定
(Investigate)
表明此錯(cuò)誤的等級(jí)無法
確定需要人工進(jìn)一步
分析
進(jìn)一步查找原因
告警的等級(jí)可以查看也可以根據(jù)要求改變使用以下兩條命令可以查看和改變告
警的等級(jí)
查看告警的等級(jí)
disp_severity <device_name> <alarm_code>
改變告警的等級(jí)
chg_severity <device_name> <alarm_code> <severity>
例如 disp_severity DRI 12
DRI Alarm Code 12 severity: WARNING
chg_severity DRI 12 major
COMMAND ACCEPTED
(BSS01:SITE-0:): 0 SITE Impacted to Major:告警附加信息
在OMCR 上按以下步驟可以清除告警
打開告警窗口選中要清除的告警項(xiàng)
單擊鼠標(biāo)右鍵彈出快捷菜單
選擇快捷菜單的Handle
選擇快捷菜單的Clear
確認(rèn)告警已被清除
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 5 -
也可在 BSS 清除告警先使用disp_act_alarm 命令查看有哪些OIC 告警然后
使用del_act_alarm 命令將告警清除格式如下
del_act_alarm <location> <device_name> <dev_id1>
<dev_id2> <dev_id3> <alarm_code>
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 6 -
第二部分 常見的十類BSS 告警
不同的告警只在其特定的告警條件下才會(huì)發(fā)生但是有些告警發(fā)生得多一些比較
普遍而有些告警出現(xiàn)得很少在一個(gè)短短幾十頁的文檔中想要把所有的告警都包括
進(jìn)來是不可能的這里我們根據(jù)現(xiàn)有的資料和經(jīng)驗(yàn)分析了經(jīng)常碰到并具普遍意義的
十類BSS 告警通過這些告警的分析 希望能夠拓寬讀者的思路幫助讀者提高處理
告警排除故障的能力
一. OML為E-U或D-U的問題
在BSC 或RXCDR 看到此現(xiàn)象時(shí)還可能看到相關(guān)的一些告警如 OML 242號(hào)告警
等
背景原理
OML 鏈路是OMCR 到RXCDR 或BSC 的信令鏈路主要用于BSS 的操作維護(hù)OML
使用X.25 協(xié)議OMCR 通過Router 與BSS 相連在BSS 端操作數(shù)據(jù)在2M 線的某些
時(shí)隙中傳輸?shù)竭_(dá)Router 后Router 中的虛擬交換電路把它們分門別類送往OMCR
進(jìn)行處理同時(shí)OMCR 的數(shù)據(jù)也通過Router交換后發(fā)往相應(yīng)的NE
可能引起此類告警的原因
相關(guān)的MMS 口退出服務(wù)
主用MSI 板沒有插
數(shù)據(jù)庫中關(guān)于OML 鏈路的定義不對(duì)
DTE地址定義不對(duì)
路由器定義不對(duì)
軟件進(jìn)程問題
解決思路
如果OML 鏈路從來沒有起來過那么首先應(yīng)該檢查硬件連接是否正確特別是主
用的MSI 板是否插上了因?yàn)橹饔肕SI 板上定義了NE 起來時(shí)用于從OMCR 下載軟件和
數(shù)據(jù)庫的OML 鏈路然后核對(duì)DTE 地址及路由器的設(shè)置是否正確如果OML 鏈路以前
是好的那么首先要搞清是否有人對(duì)OML 相關(guān)的參數(shù)改動(dòng)過如數(shù)據(jù)庫中關(guān)于OML
鏈路的定義DTE 地址路由器設(shè)置等在確認(rèn)沒有改動(dòng)過后應(yīng)檢查硬件問題如
MMS 口是否退服MSI 板是否故障等硬件也沒有問題時(shí)可初步確定為軟件進(jìn)程問
題可以設(shè)置一些Filter 收集進(jìn)程數(shù)據(jù)并對(duì)相關(guān)的幾個(gè)進(jìn)程作一些操作如重啟
進(jìn)程來恢復(fù)OML 鏈路
參考操作步驟
OML 鏈路的問題涉及的設(shè)備比較多例如 OMCR 路由器RXCDR 等為了正確
定位故障應(yīng)結(jié)合數(shù)據(jù)收集來處理問題
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 7 -
進(jìn)入BSC鍵入state 0 命令查看BSC的狀態(tài)
進(jìn)入RXCDR鍵入state 0 查看RXCDR的OML狀態(tài)
在RXCDR鍵入disp_links 查看RXCDR內(nèi)的鏈路連接以確定與OML相關(guān)的MMS位置
在出現(xiàn)問題的BSC或RXCDR中鍵入disp_p 0查看哪個(gè)GPROC控制OML鏈路
鍵入disp_act_a 0 查看是否有相關(guān)的告警
鍵入disp_eq 0 oml * * 查看每條OML的配置情況
進(jìn)入控制OML的GPROC
filter create dest 72h tag 2101h
filter create dest 72h tag 2104h
filter create dest 42h tag 2103h
filter create dest 80h tag 1f64h
filter create dest 72h tag 1f65h
filter create dest 80h tag 0xx63h
filter create dest 72h tag 2111h
以上命令為獲取發(fā)往72h 42h 80h進(jìn)程的某些消息
iir_mod 72h 4h
此命令為獲得AGENT進(jìn)程的配置信息和出錯(cuò)數(shù)據(jù)
等待5分鐘不進(jìn)行任何的操作
鍵入以下命令
msg_send 80h 5h 0 0 1fffh 0 0 輸出PLP進(jìn)程的信息
msg_send 72h 14h 0 0 21ffh 輸出AGENT進(jìn)程的信息
lock/unlock OML 看OML的狀態(tài)
鍵入以下命令
msg_send 80h 5h 0 0 1fffh 0 0
msg_send 72h 14h 0 0 21ffh
當(dāng)站空閑時(shí)進(jìn)行6 7的操作
lock/unlock OML所屬的MMS 查看OML的狀態(tài)
lock/unlock OML所屬的MSI 查看OML的狀態(tài)如果OML仍為E-U狀態(tài)進(jìn)行如下操
作
鍵入以下命令停止和激活A(yù)GENT進(jìn)程
msg_s 68 1 1 1 2 72h (停止AGENT進(jìn)程)
msg_s 68 1 1 1 1 72h (激活A(yù)GENT進(jìn)程)
然后lock/unlock此OML鏈路
鍵入以下命令停止和激活A(yù)GENT進(jìn)程X.25 PLP進(jìn)程
msg_s 68 1 1 1 2 72h (停止AGENT進(jìn)程)
msg_s 68 1 1 1 2 80h (停止PLP進(jìn)程)
msg_s 68 1 1 1 1 72h (激活A(yù)GENT進(jìn)程)
msg_s 68 1 1 1 1 80h (激活PLP進(jìn)程)
然后 unlock/lock 此 OML
如果OML仍然無法恢復(fù)將前面加的Filter都刪除加入以下的Filter
filter create dest 13h src 80h 獲取從80h進(jìn)程到13h進(jìn)程的消息
filter create dest 80h src 13h 獲取從13h進(jìn)程到80h進(jìn)程的消息
保持10秒鐘將兩個(gè)Filter刪除如果OML仍然無法恢復(fù)先收集此GPROC的SWFM
然后reset此GPROC 如仍不能解決問題將BSC reset
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 8 -
二. GCLK無法鎖相的問題
此時(shí)會(huì)產(chǎn)生GCLK Failed Phase Lock 的提示并可能伴隨出現(xiàn)4 14 13 號(hào)等
告警
背景原理
GLCK 的功能是使得系統(tǒng)與更準(zhǔn)確的時(shí)鐘同步對(duì)于BSS 來說GCLK 要與MSC 的
時(shí)鐘同步時(shí)鐘同步的目的是在射頻部分提供±0.05ppm ppm為百萬分之一即如時(shí)
鐘為16.384M 則頻率誤差為16.384 0.05 = ± 0.8192Hz 的高精度的時(shí)間同步
因此要提供參考時(shí)鐘的E1/T1鏈路要盡量減少滑幀和失同步
GCLK 要與上一級(jí)時(shí)鐘同步必須要有上一級(jí)時(shí)鐘的參考信號(hào)時(shí)鐘參考信號(hào)是根
據(jù)數(shù)據(jù)庫的定義從指定的MMS 口上提取的在 database 中需要定義不同MMS 口的時(shí)
鐘提取優(yōu)先等級(jí)
GCLK 在工作時(shí)有四種不同的狀態(tài)
自由振蕩狀態(tài)此狀態(tài)是當(dāng)GCLK 剛上電時(shí)其內(nèi)部的晶體振蕩器OCXO 需要有
預(yù)熱的過程以保持其正常的工作環(huán)境此時(shí)間是固定不變的30 分鐘無法更改
在自由振蕩狀態(tài)下GCLK內(nèi)的DAC 輸入為80H 時(shí)鐘輸出保持在0.05ppm的精度內(nèi)
Hold Frequency 此狀態(tài)是GLCK 與2M 失鎖時(shí)的狀態(tài)此時(shí) GCLK 使用前一次ADC
輸出的值輸入DAC 以控制時(shí)鐘此狀態(tài)是一個(gè)過渡狀態(tài)一般持續(xù)10秒
Set Frequency 此狀態(tài)一般在Hold Frequency 之后使用LTA Long Term Average
值輸入DAC 以控制時(shí)鐘
正常鎖相工作時(shí)GCLK 每30 分鐘采樣一個(gè)ADC 輸出值 2位16 進(jìn)制數(shù)存入
內(nèi)部存儲(chǔ)器存儲(chǔ)器最大可以存放48 個(gè)值采用先入先出原則更新這48 個(gè)值也可
以被GPROC 通過MCAP 總線讀取或設(shè)置所謂LTA 就是指將這48 個(gè)值取平均輸入到
DAC Set Frequency 狀態(tài)下GCLK 不再往存儲(chǔ)器中存放新值只是使用以前的舊值
存儲(chǔ)器停止更新這是與鎖相狀態(tài)的不同之處
鎖相狀態(tài)此狀態(tài)分為兩個(gè)子狀態(tài)
Acquiring Frequency Lock State
此狀態(tài)是一個(gè)過渡狀態(tài)由硬件決定
Frequency Lock State
此狀態(tài)內(nèi)GCLK 已與E1/T1 鎖相但需等待一段時(shí)間以確定鎖相穩(wěn)定之后就進(jìn)
入鎖相狀態(tài)
GCLK 要與E1/T1 同步必須有合適的時(shí)鐘提取端口這些端口的優(yōu)先級(jí)按以下原
則確定
MMS是否為B-U
MMS的等級(jí)在database中定義
在一定時(shí)間內(nèi)MMS 處于OOS狀態(tài)的次數(shù)
如果以上都相同則輪流作為時(shí)鐘源
除了MMS 口的等級(jí)外在DATABASE中還有一些參數(shù)與GCLK有關(guān)
chg_el phase_lock_gclk <*> <site>
<*> 0 Disable phase locking
1 Enable phase locking
此命令設(shè)置是否允許時(shí)鐘同步
chg_el wait_for_reselection <element_value> <location>
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 9 -
<element_value> 1 to 255 缺省值為10
此命令設(shè)置當(dāng)一個(gè)MMS 的時(shí)鐘提取出現(xiàn)問題時(shí)多長(zhǎng)時(shí)間后切換到其它
的MMS 口提取時(shí)鐘
modify_value <site> mms_priority <*> mms <mms_id1><mms_id2>
<*> 0 to 255
此命令設(shè)置MMS 的優(yōu)先級(jí)其中0表示禁止從此口提取時(shí)鐘
chg_el lta_alarm_range <element_value> <location>
<element_value> 1 to 255 缺省值為7
此命令設(shè)置當(dāng)存儲(chǔ)器內(nèi)的值有25%超出LTA 值的± <element_value>時(shí)產(chǎn)
生告警
reattempt_pl <location> <gclk_id1>
此命令要求GCLK 嘗試重新鎖相只有當(dāng)GCLK 前一次鎖相失敗時(shí)才能使
用此命令
modify_value <location> phase_lock_duration <new_value>
mms<dev_fun_id1><dev_fun_id2><dev_fun_id3>
<new_value> 0 to 255 缺省值為0
此命令表示當(dāng)GCLK 與E1/T1 鏈路在多長(zhǎng)時(shí)間內(nèi)能鎖住并保持在
+/-0.05ppm 內(nèi).就認(rèn)為可以選取此MMS 作為時(shí)鐘源
可能引起此類告警的原因
因傳輸問題引起MMS 退服
MSI板或MMS口硬件故障
數(shù)據(jù)庫定義不合理
GCLK本身的問題需要校正或更換
解決思路
當(dāng)出現(xiàn)GCLK 無法鎖相的告警時(shí)首先要搞清楚參考時(shí)鐘是從哪里來的檢查一下
數(shù)據(jù)庫中有關(guān)GCLK 的參數(shù)設(shè)置是否合理如鎖相應(yīng)向上鎖即RXCDR向MSC 鎖BSC
向RXCDR 鎖BTS 向BSC 或上一級(jí)的BTS 只有菊花鏈的情況鎖 向下一端的MSI
口的時(shí)鐘提取優(yōu)先級(jí)應(yīng)設(shè)為0 另外也不能只允許一個(gè)MMS 口可以提取時(shí)鐘如果數(shù)
據(jù)庫設(shè)置沒有明顯不合理之處應(yīng)注意一下與時(shí)鐘提取有關(guān)的MMS口和MSI板的狀態(tài)
MMS 口退服可能是傳輸問題引起的也可能是MSI板或MMS 口硬件故障引起的如果
MSI 板工作正常則應(yīng)著重檢查傳輸質(zhì)量在排除了數(shù)據(jù)庫MSI 硬件和傳輸原因之后
應(yīng)校正或更換GCLK 板
參考操作步驟
為了利于問題的分析應(yīng)收集以下數(shù)據(jù)
state <location> gclk * * 查看GCLK 的狀態(tài)
disp_el phase_lock_gclk <location> 查看是否允許鎖相
disp_eq 0 mms <id 1><id 2><id 3> 查看MMS 的參數(shù)主要是時(shí)鐘提取優(yōu)先級(jí)
disp_el wait_for_reselection <location> 查看時(shí)鐘提取切換時(shí)間
disp_el lta_alarm_range <location> 查看LTA 告警范圍
disp_gclk_avgs <location> <gclk_id> 查看GCLK 的長(zhǎng)期平均值
disp_eq <location> gclk <id_1><id_2><id_3> full 查看GCLK 硬件版本信息
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 10 -
當(dāng)GCLK 無法鎖相時(shí)可采用以下的方法
reattempt_pl <location> <gclk_id1>
使用lock/unlock 命令看是否能使得GCLK鎖相恢復(fù)
查看MSI MMS 是否處于正常狀態(tài)是否有E1的相關(guān)告警產(chǎn)生是否有MMS 作為時(shí)
鐘源
查看提供時(shí)鐘的MMS 是否與上一級(jí)的鏈路連接上一級(jí)的時(shí)鐘是否正常工作
查看提供時(shí)鐘的MMS 的等級(jí)是否設(shè)置正確一般為255
試著使用其它的MMS 作為時(shí)鐘源對(duì)于M-CELL可更換NIU
重新校準(zhǔn)GCLK 的時(shí)鐘具體校準(zhǔn)的過程可見MOTOROLA 手冊(cè)68P02901W43 第二
章為GCLK 調(diào)測(cè)第三章為MCU時(shí)鐘調(diào)測(cè)第四章為MCUm 的時(shí)鐘調(diào)測(cè)
如果出現(xiàn)無法校準(zhǔn)備用端的GCLK 也不能用并且沒有備件用儀表檢查上行和
下行鏈路的時(shí)鐘看是否為2.048M 可使用hp37717C 分析儀以確定是那一端出現(xiàn)
問題
注意 在151X 版本軟件中將GCLK 的鎖相精度要求被額外提高了所以容易產(chǎn)生失鎖
告警但并不一定表明此GCLK 有問題對(duì)系統(tǒng)正常工作也沒有影響此問題只存在
于M_CELL 在160X版本中已經(jīng)將此解決
三. MMS 告警和退出服務(wù)
背景原理
在 MOTORLOA 系統(tǒng)中除了硬件問題有四種與傳輸相關(guān)的情況會(huì)導(dǎo)致MMS 告警或退
出服務(wù)
BER Bit Error Rate 誤碼率
MMS 通過監(jiān)測(cè)0 時(shí)隙的固定位來計(jì)算誤碼率ber_loss_daily 和
ber_loss_hourly 分別定義了24 小時(shí)和1 小時(shí)誤碼率的門限值誤碼率超出門限值
時(shí)就會(huì)產(chǎn)生誤碼率告警ber_oos_mon_period 定義了誤碼率監(jiān)測(cè)時(shí)間長(zhǎng)度在這
個(gè)時(shí)間長(zhǎng)度內(nèi)誤碼率超過1 由MMS 硬件決定MMS 將要退出服務(wù)
Sync loss 失同步
MMS 通過檢測(cè)同步位來與對(duì)端同步當(dāng)同步位出錯(cuò)時(shí)算失同步一次失同步時(shí)
間超過sync_time_oos 設(shè)定的值時(shí)MMS 將退出服務(wù)重新同步后時(shí)間超過
sync_time_restore 設(shè)定的值后MMS 重新進(jìn)入服務(wù)當(dāng)24 小時(shí)和1 小時(shí)內(nèi)的失同步
次數(shù)分別超出sync_loss_daily 和sync_loss_hourly 定義的值時(shí)MMS 會(huì)產(chǎn)生
sync_loss 告警此外24小時(shí)內(nèi)失同步的次數(shù)超出sync_loss_oos 定義的值時(shí)MMS
也會(huì)退出服務(wù)同樣恢復(fù)正常后時(shí)間超過sync_loss_restore 定義的時(shí)間MMS 重新
進(jìn)入服務(wù)
Remote alarm 對(duì)端失同步告警
對(duì)端MMS 失同步后會(huì)回送一個(gè)失同步標(biāo)志MMS 檢測(cè)到此標(biāo)志后開始計(jì)時(shí)對(duì)
端失同步時(shí)間超過remote_time_oos定義的時(shí)間MMS 就退出服務(wù)對(duì)端失同步恢復(fù)
后超過remote_time_restore定義的時(shí)間MMS 就重新進(jìn)入服務(wù)24 小時(shí)和1 小時(shí)
內(nèi)對(duì)端失同步的次數(shù)分別超出remote_loss_daily 和remote_loss_hourly 定義的值
時(shí)MMS 會(huì)產(chǎn)生remote_alarm 告警24 小時(shí)內(nèi)對(duì)端失同步次數(shù)超出remote_loss_oos
設(shè)定的值時(shí)MMS 也會(huì)退出服務(wù)對(duì)端恢復(fù)后超出remote_loss_restore 定義的時(shí)間
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 11 -
MMS 就重新進(jìn)入服務(wù)
Frame slip 滑碼
24 小時(shí)和1 小時(shí)內(nèi)滑碼的次數(shù)分別超出slip_loss_daily 和slip_loss_hourly
定義的值時(shí)MMS 會(huì)產(chǎn)生frame_slip 告警24 小時(shí)內(nèi)滑碼次數(shù)超出slip_loss_oos
設(shè)定的值時(shí)MMS 會(huì)退出服務(wù)滑碼恢復(fù)后超出slip_loss_restore 定義的時(shí)間MMS
就重新進(jìn)入服務(wù)
MMS 的告警號(hào)列表
MMS Alarm num Daily Hourly OOS Threshold OOS Timer
Sync Loss 0 1 2 16
Remote Alarm 4 5 6 18
Frame Slip 8 9 10
Bit Error 12 13 14
Daily –Waring 表示在24 小時(shí)內(nèi)告警門限超出一般在此告警之前就會(huì)有其它更敏
感的告警產(chǎn)生此告警不會(huì)對(duì)系統(tǒng)的服務(wù)產(chǎn)生影響
Hourly - minor alarm 表示在1 小時(shí)內(nèi)有大量的問題產(chǎn)生鏈路的性能降低對(duì)
系統(tǒng)的服務(wù)可能會(huì)產(chǎn)生影響
OOS - Critical alarm MMS退出服務(wù)
可能引起此類告警的原因
MSI 板或MMS口硬件故障
因傳輸問題引起的MMS 告警或退服
2M 線斷路
解決思路
當(dāng)出現(xiàn)MMS 告警但并不退出服務(wù)時(shí)問題一定在傳輸方面如果MMS 退出服務(wù)
則應(yīng)先檢查2M 線是否斷路然后查看MMS 在退出前是否有其它告警有其它告警如
誤碼率滑碼失同步對(duì)端告警時(shí)應(yīng)著重檢查傳輸?shù)膯栴}否則應(yīng)是MSI 板或
MMS 口的硬件故障問題
參考操作步驟
查看產(chǎn)生告警的site 的MSI MMS的工作狀態(tài)
如果產(chǎn)生告警的MMS 或MSI 為B-U 檢查告警是否已經(jīng)消除如果MSI 或MMS 不是
B-U 使用lock/unlock ins 命令嘗試將MSI或MMS恢復(fù)
如果鏈路沒有恢復(fù)檢查對(duì)端的MSI MMS是否工作正常
如果對(duì)端沒有問題在 T43 板處自環(huán)查看 MMS 是否為B-U 如果MMS 不為B-U
檢查T43 MMS MSI NIU 等
如果MMS 為B-U 檢查傳輸是否有問題
如果仍不能恢復(fù)將 MSI NIU 插拔一下或替換MSI T43 板另外注意檢查MMS
的背板的插座是否完好MSI NIU 與T43間的連接是否正常
將site 進(jìn)行硬件或軟件reset 最后可進(jìn)行斷電再起
注意 在更換插拔MSI NIU 時(shí)要先將MSI lock 住
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 12 -
四. DRI 12號(hào)告警
此告警表示信道編碼失去TRAU 幀同步Channel Coder Lost TRAU Frame
Synchronization 此告警一般與其它告警共同出現(xiàn)會(huì)影響系統(tǒng)的服務(wù)
背景原理
此告警表明CCDSP TCU 內(nèi)信道編碼數(shù)字處理單元至少與RXCDR 失步1 秒這
是因?yàn)門DM 鏈路錯(cuò)誤使得幀失步
可能引起此類告警的原因
RXCDR可能出現(xiàn)問題
在切換時(shí)BSC 沒有把原DRI的相應(yīng)CCDSP置為空閑
此告警可能伴隨著以下兩個(gè)告警
[9] MSI (XCDR): TRAU Frame Synchronization Loss.
[11] DRI: Channel Coder TDM Link Error.
解決思路
查看 XCDR 板硬件是否有問題如果沒有問題則等到該DRI 沒有被占用時(shí)ins
一下
參考操作步驟
查看告警信息看是否同時(shí)有MSI 9號(hào)告警和DRI 11 號(hào)告警
如果在BTS 有DRI 11 號(hào)告警則可能為DRI 的問題進(jìn)入[3] 如果在RXCDR 有
MSI 9 號(hào)告警則可能為RXCDR的問題
在BTS 鍵入state 命令查看DRI 的狀態(tài)如果DRI 為B-U 則先檢查是否告警已
經(jīng)消失如果沒有消失就更換TCU 如果DRI 不是B-U 使用lock/unlock 命令設(shè)
法使DRI 恢復(fù)正常工作如果lock/unlock命令無效進(jìn)行以下操作
在BTS 進(jìn)入emon提示符下鍵入
iir_mod 66 200h (此命令可以收集DRI 與CA 間的消息)
然后退到MMI_RAM->提示符鍵入
ins <site id> dri * *
馬上進(jìn)入emon 下收集出現(xiàn)的信息
將RSS 串口線接在出現(xiàn)告警的TCU的TSM口上鍵入
chg_l <enter> 3stooges <enter> 4beatles<enter>
進(jìn)入RSS:emon_**** %提示符下接著在MCU 的TTY 口鍵入
ins <site id> dri * *
收集在TSM 口的信息
收集BTS 的SWFM 和相關(guān)的event log
在得出問題的原因之前可更換此TCU
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 13 -
五. BSP 239 號(hào)告警
此告警表示GPROC 的安全檢測(cè)進(jìn)程檢測(cè)到進(jìn)程錯(cuò)誤
背景原理
安全檢測(cè)進(jìn)程是負(fù)責(zé)對(duì)GPROC 內(nèi)運(yùn)行的進(jìn)程檢查以確定是否運(yùn)行正常當(dāng)被檢測(cè)
的進(jìn)程沒有響應(yīng)時(shí)就產(chǎn)生此告警不同功能的GPROC 所產(chǎn)生的239 號(hào)告警表現(xiàn)為
[239] BSP [239] BTP [239] DHP [239] BTP (MCU)
安全檢測(cè)進(jìn)程對(duì)系統(tǒng)進(jìn)行周期性的檢測(cè)可以通過參數(shù)來調(diào)整檢測(cè)的時(shí)間間隔
缺省的時(shí)間間隔為10 分鐘
可能引起此類告警的原因
GPROC BSP BTP板子損壞
被檢測(cè)的GPROC BSP BTP 軟件進(jìn)程出現(xiàn)錯(cuò)誤
被檢測(cè)的硬件出錯(cuò)
GPROC沒插但數(shù)據(jù)庫中作了定義
從TCU 到BTP 的HDLC 鏈路可能出錯(cuò)
BTP的輸入輸出鏈路出錯(cuò)
TCU的運(yùn)行軟件出錯(cuò)
解決思路
首先確定是哪塊GPROC出現(xiàn)239 告警根據(jù)這塊GPROC 的功能來確定存在問題的
進(jìn)程或硬件范圍如BTP 239告警出現(xiàn)問題的進(jìn)程可能運(yùn)行于MCU 也可能運(yùn)行于
TCU 還可能是BTP 與TCU 的通信進(jìn)程然后檢查相應(yīng)的硬件是否有問題不能進(jìn)一
步判斷原因所在時(shí)應(yīng)收集數(shù)據(jù)再作分析
參考操作步驟
在出現(xiàn)告警的基站鍵入state以確定發(fā)生告警的GPROC BSP DHP BTP 的狀態(tài)
如果顯示為B-U 則鍵入
device_audit <location> all <device_name>
<device_id1> <device_id2> <device_id3>
如果device_audit 成功則繼續(xù)觀察此設(shè)備如果device_audit失敗則鍵入
ins <location> <device_name> <dev id> <dev_id> <dev_id>
如果ins 失敗則進(jìn)行如下操作收集數(shù)據(jù)
如果出現(xiàn)問題的是BSP 則通過直連或遠(yuǎn)程登錄進(jìn)入GPROC 如果沒有響應(yīng)則可能
為GPROC 太忙TTY進(jìn)程來不及響應(yīng)鍵入
disp_mms_ts_usage
查看A 接口上是否有TCH 被分配如果有則收集GPROC 的SWFM 和event
如果沒有則將GPROC reset 當(dāng)BSC reset 后收集 GPROC 的Fatal and Non Fatal
SWFMs 以及在告警發(fā)生前和BSC reset后的event
如果出現(xiàn)問題的不是BSP 則通過直連或遠(yuǎn)程登錄進(jìn)入GPROC 收集GPROC 的Fatal
and Non Fatal SWFMs 以及在告警發(fā)生前后的event
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 14 -
六. MTL 告警
背景原理
MTL 鏈路是MSC 與BSC 的信令鏈路其在整個(gè)系統(tǒng)中起著MSC 與MS BSS 連接的
作用MTL出現(xiàn)問題會(huì)導(dǎo)致其下屬所有的BSS 癱瘓
MTL 最多的告警一般為0 號(hào)告警出現(xiàn)此告警時(shí)MTL 為D-U 此告警表示MTL 鏈
路與MSC 已經(jīng)失去聯(lián)系這是由于MTP 第二層出現(xiàn)問題而退出服務(wù)但系統(tǒng)會(huì)不斷
嘗試恢復(fù)此鏈路另外當(dāng)一條MTL 鏈路退出服務(wù)時(shí)其負(fù)荷會(huì)分配到其它MTL 上加
重其它MTL 的負(fù)擔(dān)而由于GPROC 的處理能力的原因MTL 鏈路的平均利用率不能超
過30 因此 MTL 鏈路負(fù)擔(dān)過重會(huì)使得GPROC 退出服務(wù)從而導(dǎo)致更多的鏈路退
出服務(wù)
此告警與BSS 0 號(hào)告警的區(qū)別為MTL 0 號(hào)告警表示一條MTL 退出服務(wù)而一個(gè)
BSS 可能有多條MTL 鏈路BSS 0 號(hào)告警表示此BSS 系統(tǒng)的最后一條MTL 鏈路也退出
服務(wù)此時(shí)BSS 完全癱瘓了
可能引起此類告警的原因
MSC傳來的MTP第二層LSSU信息出現(xiàn)錯(cuò)誤
MSC端擁塞超時(shí)
MSU確認(rèn)消息超時(shí)
序列號(hào)出現(xiàn)錯(cuò)誤
SUERM的錯(cuò)誤門限值超出
收到不正常的FIB
解決思路
先檢查數(shù)據(jù)庫內(nèi)關(guān)于MTL 鏈路定義有無問題然后檢查有關(guān)的MMS 口MSI 板是
否退出服務(wù)再查與MSC 的信令點(diǎn)碼是否正確在確認(rèn)上述方面無問題后檢查GPROC
是否有硬件問題必要時(shí)復(fù)位該GPROC
參考操作步驟
根據(jù)告警消息找到出現(xiàn)問題的站號(hào)MTL 的設(shè)備編號(hào)
在RXCDR 鍵入
disp_links
disp_bss_conn
以確定MTL 鏈路的連接情況
鍵入disp_equip 0 MTL * * 得到MTL的配置情況
查看與MTL 相關(guān)的設(shè)備是否正常工作
state 0 mms * * 查看MMS的狀態(tài)
state 0 msi * * 查看MSI的狀態(tài)
disp_p 0 查看MTL由那個(gè)GPROC 控制
disp_act_a 0 查看是否有相關(guān)的告警
出現(xiàn)了相關(guān)的設(shè)備告警時(shí)應(yīng)先處理這些相關(guān)問題
使用lock unlock ins 命令試著恢復(fù)鏈路
檢查RXCDR 或MSC 是否在rebooting 等到其正常工作后再檢查MTL是否恢復(fù)了
在BSC 鍵入
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 15 -
disp_ele dpc 0
disp_ele opc 0
此命令查看MTP 的第三層的信令點(diǎn)碼比較此點(diǎn)碼與MSC 處設(shè)置的點(diǎn)碼是否對(duì)應(yīng)
找到控制此MTL 的GPROC
ins 0 gproc * *
如無效則鍵入
reset_de 0 gproc * *
將BSC reset
為了進(jìn)一步分析原因在做lock unlock之前按以下步驟收集數(shù)據(jù)
統(tǒng)計(jì)數(shù)據(jù)
在呼叫成功率下降時(shí)收集以下統(tǒng)計(jì)數(shù)據(jù)
disp_stats <interval> <meas_type>
[board_id=<board_id>]
其中<meas_type>為以下值
mtp_msu_tx
mtp_msu_rx
mtp_congestion
mtp_link_ins
mtp_unavailable
mtp_link_fail
mtp_sl_congestion
mtp_local_busy
cpu_usage (for BSC GPROCs controlling MTLs)
其中[board_id=<board_id>]代表控制此MTL的GPROC的編號(hào)
EVENT收集
在OMCR 收集在MTL 發(fā)生問題前后的事件信息
EMON狀態(tài)下
找到控制此MTL 的GPROC 進(jìn)入EMON 層鍵入以下命令
filter create tag 0xxxx0c4xh
MPTL2 和MTPL3 間連接或斷開消息
filter create tag 0xxxx0bxxh
MTPL3 和CA 進(jìn)程間的消息
filter create tag 0xxxx14xxh
CA 進(jìn)程和MTPL2間的消息
設(shè)置10h進(jìn)程MTP_L3 的統(tǒng)計(jì)數(shù)據(jù)消息
iir_mod 16 1000000h
zstats 16 顯示16 號(hào)進(jìn)程的mailbox
zstats 17 顯示17 號(hào)進(jìn)程的mailbox
msg_send 16 9000h 0 0 0 0a7h 014h 0
為 MTPL2 設(shè)置以下的iir_mod 如果出現(xiàn)大量的數(shù)據(jù)輸
出 請(qǐng)立即將其關(guān)閉以免影響系統(tǒng)正常工作
iir_mod 17 1 設(shè)置17 號(hào)進(jìn)程的iir_mod
iir_mod 17 0 關(guān)閉17 號(hào)進(jìn)程的iir_mod
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 16 -
七.IAS 1號(hào)告警
IAS 1 號(hào)告警Serial Bus Connection Failure 多出現(xiàn)在BSC 或RXCDR 基
站內(nèi)
背景原理
在 BSSC 機(jī)柜中有一塊的告警板此板的作用為報(bào)告熔絲和風(fēng)扇等設(shè)備的告警
此告警板的PL2和PL3 連接到CAGE 背板的左上角AI0/AI1口如果BSS為兩個(gè)CAGE
上面的CAGE 一般是不連接告警線的數(shù)據(jù)庫定義CAGE 時(shí)需要定義告警線是否接到
這個(gè)CAGE 中
disp_eq 0 cage 0 0
Identifier for the CAGE: 0
KSW pair that manages the CAGE: 0
KSWX connecting cage to KSW for TDM 0:
KSWX connecting cage to KSW for TDM 1:
Cabinet to which the cage belongs: 0
IAS Connected: YES
最后一項(xiàng)如果定義為YES 則軟件嘗試將告警信號(hào)送到此CAGE 但是如果物理上
并沒有將告警線連接到此CAGE 則會(huì)產(chǎn)生IAS 1 號(hào)告警一般配置CAFE 時(shí)都將下面
的CAGE 定義為連接告警線上面的CAGE 不連接如果在equip cage 時(shí)將上面的CAGE
也定義了IAS Connected: YES 則會(huì)產(chǎn)生大量的IAS 1 告警
可能引起此類告警的原因
告警板故障
告警線連接錯(cuò)誤
數(shù)據(jù)庫定義錯(cuò)誤
告警線損壞
解決思路
先確定告警線連接在哪個(gè)CAGE 中查看數(shù)據(jù)庫中定義的是否與物理連接相一致
不一致時(shí)修改數(shù)據(jù)庫如果數(shù)據(jù)庫定義沒有問題檢查告警板和告警線是否損壞
參考操作步驟
檢查告警線連接與數(shù)據(jù)庫中的定義是否相符
如果不符使用命令
modify_value 0 ias_connected < * > cage ( # )
< * > yes/no
( # ) cage 號(hào)
檢查告警板是否完好告警線是否損壞必要時(shí)更換有關(guān)硬件
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 17 -
八. BSS 22 號(hào)告警Trunk Critical Threshold Exceeded
此告警表示被BLOCK 的CIC 數(shù)目超過了緊急告警門限值
背景原理
CIC 是MSC 經(jīng)由RXCDR 到BSC 的陸地電路XCDR GDP 板及內(nèi)部的DSP 處理器
和MSI 板的故障都會(huì)使得CIC 的數(shù)目減少另外由于傳輸?shù)葐栴}也會(huì)使得CIC 被
block 但傳輸恢復(fù)正常后CIC 不一定能自動(dòng)起來此時(shí)需要人工干預(yù)才能恢復(fù)
可能引起此類告警的原因
由于MSI 板和MMS 口的硬件問題導(dǎo)致可用的CIC數(shù)目減少
由于E1 鏈路的問題包括傳輸問題導(dǎo)致CIC 數(shù)目減少
由于RXCDR 中GDP XCDR 板的DSP 處理器出現(xiàn)問題使得CIC數(shù)目減少
MSI XCDR GDP板可能被人為lock 了
database中關(guān)于此告警的門限值設(shè)置得太低
解決思路
首先查硬件問題如E1 連接是否正常MSI XCDR GDP 板是否有問題有沒有
被LOCK 再檢查是否因傳輸問題而使MMS 口退服同時(shí)應(yīng)注意一下數(shù)據(jù)庫中有關(guān)參
數(shù)的定義是否合理如果MSC端將CIC block 應(yīng)手動(dòng)將CIC復(fù)位
參考操作步驟
鍵入
state 0 msi * *
state 0 mms * *
disp_act_a 0
disp_act_a 0
檢查MSI MMS 狀態(tài)是否正常是否有相關(guān)的告警
在BSC 找到對(duì)應(yīng)的連接到MSC的2M鏈路的MMS板鍵入
disp_mms_ts_usage 0 mms * *
查看此MMS 的各時(shí)隙是否有被block 的如發(fā)現(xiàn)大量的CIC 被block 首先確定是否
為MSC 邊將其block 的如果不是則使用以下命令將CIC 釋放
先進(jìn)入BSC 的emon 提示符下鍵入以下命令
msg_s 64 3 99 99 0f0eh 0eh 01h 00 xx 030h 02h 00h 01h
其中xx ---CIC number
使用以下命令檢查關(guān)于告警的門限值
disp_element cic_error_gen_threshold 0
查看cic 告警的門限值如發(fā)現(xiàn)設(shè)置過低使用
chg_element cic_error_gen_threshold <value> 0
調(diào)整cic 告警門限值
九. GPROC 245 號(hào)告警
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 18 -
此告警表示一個(gè)GPROC 或BTP 退出服務(wù)
背景原理
此告警的不同形式為
[254] BSP: Device Failure
[254] BTP: Device Failure
[254] GPROC: Device Failure
如果主用的BSP 或BTP 出現(xiàn)此告警時(shí)site 已經(jīng)reset 了如果不是主用端的
BSP 或BTP 則它會(huì)reset 并且系統(tǒng)會(huì)盡量將它恢復(fù)起來如果一般的GPROC 出現(xiàn)
此告警它會(huì)RESET 并會(huì)影響相應(yīng)的信令鏈路導(dǎo)致有關(guān)BTS退出服務(wù)
可能引起此類告警的原因
其它設(shè)備或其本身的故障使得其退出服務(wù)
MMI命令使其退出服務(wù)
reset_site, soft_reset, reset_device 和 csfp_swap 等
參考操作步驟
如果為主用的BSP 或BTP 則等待site reboot 完成
如果不是主用的BSP 或BTP 過5 分鐘等待GPROC reset 完成
鍵入state 檢查site內(nèi)的狀態(tài)確定發(fā)生問題的site_id,設(shè)備號(hào)槽位號(hào)
使用lock/unlock ins 等命令嘗試使GPROC 進(jìn)入服務(wù)
進(jìn)入GPROC 的emon 提示下收集SWFM 同時(shí)收集告警發(fā)生前后的event
注意 一些GCLK LANX KSW 等設(shè)備的告警可能會(huì)使GPROC 退出服務(wù)當(dāng)出現(xiàn)GPROC
245 號(hào)告警前出現(xiàn)大量相關(guān)設(shè)備的告警時(shí)應(yīng)該注意及時(shí)排除以免引起GPROC reset
同時(shí)注意CPU 工作時(shí)的使用率如果出現(xiàn)使用率超出60%時(shí)應(yīng)該引起注意適當(dāng)?shù)?br /> 將工作量移到其他的GPROC上
十. TIMESLOT 0 號(hào)告警
此告警表明因?yàn)镽F 的問題而使得呼叫失敗的統(tǒng)計(jì)值包括無法建立通話超出
告警門限
背景原理
在分配信道時(shí)系統(tǒng)會(huì)檢測(cè)空中各信道的信噪比在數(shù)據(jù)庫中定義了
interfer_bands 1-4 參數(shù)此為四類信噪比的界限以將信道分成不同的5 類前
四類的信道按照優(yōu)先順序被分配而第五類信道因?yàn)楦蓴_強(qiáng)系統(tǒng)不會(huì)將其分配出去
這樣有利于避免受干擾大的信道被使用從而保證了通話的質(zhì)量但是干擾較大時(shí)
大部分信道成為5 類信道而無法使用嚴(yán)重時(shí)會(huì)造成大量通話無法建立產(chǎn)生告警
可能引起此類告警的原因
RF 干擾
數(shù)據(jù)庫中有關(guān)參數(shù)設(shè)置不合理
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 19 -
解決思路
應(yīng)先尋找并排除干擾源找不到干擾源時(shí)如果允許通話干擾稍大一些可以修
改數(shù)據(jù)庫的參數(shù)將4 類信道的干擾標(biāo)準(zhǔn)適當(dāng)降低這兩種方法都行不通時(shí)應(yīng)考慮
頻率調(diào)整或使用跳頻
參考操作步驟
確定出現(xiàn)問題的site 和RTF 在此site 中輸入
disp_rtf_channel <location> <rtf_id_1> <rtf_id_2>
[<timeslot_number>]
如果出現(xiàn)類似以下的輸出
MMI-RAM 0216 -> disp_rtf_channel 5 2 0
Start of report for RTF 2 0 at location 5:
TIMESLOT SUB-CHAN STATE
----------------------------------------------------------------
0 BCCH BCCH ACTIVE
1 (TCH/F) 0 ACTIVE
2 (SDCCH/8) 0 UNAVAIL (IBAND)
1 UNAVAIL (IBAND)
2 UNAVAIL (IBAND)
3 UNAVAIL (IBAND)
4 UNAVAIL (IBAND)
5 UNAVAIL (IBAND)
6 UNAVAIL (IBAND)
7 UNAVAIL (IBAND)
3 (TCH/F) 0 UNAVAIL (IBAND)
4 (TCH/F) 0 UNAVAIL (IBAND)
5 (TCH/F) 0 UNAVAIL (IBAND)
6 (TCH/F) 0 UNAVAIL (IBAND)
7 (TCH/F) 0 ACTIVE
End of Report.
其中UNAVAIL (IBAND)表示此信道因?yàn)楦蓴_無法使用
查找干擾源首先確定此扇區(qū)內(nèi)的各頻點(diǎn)間是否存在干擾再檢查鄰小區(qū)間是否存
在干擾最后可使用儀表檢查外載波的干擾
如果暫時(shí)查不到干擾或無法解決可以使用以下命令
chg_ele interfer_bands,4 39 <site_id> all
適當(dāng)放寬4 類信道的標(biāo)準(zhǔn)以換取有較多的信道能被使用減少通話阻塞
將受影響的信道的頻點(diǎn)改變但操作時(shí)要注意不要造成對(duì)其它頻點(diǎn)的干擾
在消除了干擾之后要將interfer_bands,4改回原值
BSS 常見告警分析
99’吉林GSM 工程總結(jié)與運(yùn)維技術(shù)交流會(huì)- 20 -
結(jié) 語
在處理告警問題時(shí)不可固守既定模式要結(jié)合數(shù)據(jù)收集具體問題具體分析靈
活應(yīng)變同時(shí)注意以下幾點(diǎn)
要規(guī)范操作流程按照正確的操作步驟進(jìn)行熟悉BSS 命令
對(duì)告警發(fā)生的site device function 要有正確的定位
清楚告警的含義注意告警的等級(jí)和其對(duì)系統(tǒng)可能造成的影響尤其注意對(duì)系統(tǒng)服
務(wù)正常工作已經(jīng)發(fā)生影響或?qū)⒁�產(chǎn)生較大影響的告警注意反復(fù)出現(xiàn)的告警
對(duì) BSS 系統(tǒng)的基本工作原理信號(hào)流程要有一個(gè)清楚的認(rèn)識(shí)在處理告警時(shí)可以
根據(jù)相關(guān)的原理信令流程來分析處理告警
處理告警可參考MOTOROLA 的告警手冊(cè)
在處理某一告警時(shí)要注意其它相關(guān)連的告警注意告警發(fā)生的先后關(guān)系分析其
是否有聯(lián)系
在處理告警時(shí)要及時(shí)地將操作過程OMCR 上顯示的事件SWFM 等數(shù)據(jù)保存好
以便進(jìn)行進(jìn)一步分析
對(duì)于系統(tǒng)的改變調(diào)整要有詳細(xì)的記錄
處理告警時(shí)要注意各種情況之間相互比較如故障設(shè)備告警發(fā)生前后的比較故障
設(shè)備與工作正常的設(shè)備的比較等努力從它們之間的異同中尋找問題的根源所在
引起告警的原因較多時(shí)應(yīng)先從較易處理的因素著手如接線是否錯(cuò)誤松動(dòng)等
由易到難把軟件進(jìn)程等難于處理的因素放到最后