【資料名稱】：硬件處理流程

【資料作者】：不詳

【資料日期】：2009

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

目錄
一、要求范圍 ……………………………………………1
二、技術要求 ……………………………………………1
三、問題及處理方法……………………………………1
A、關于Path balance值的問題…………………………………1
B、關于SD掉話的問題………………………………………3
C、關于TCH掉話的問題………………………………………4
D、關于載頻BER高的問題……………………………………5
E、關于載頻IOI高的問題……………………………………6
F、關于切換成功率低的問題 ……………………………………7
G、關于基站時鐘問題的問題 ……………………………………8
H、關于壞載頻的處理………………………………………10
I、關于斷站的處理…………………………………………10
J、關于小區(qū)OOS的處理……………………………………10
K、關于各類告警的處理 ………………………………………10
L、GSM網(wǎng)絡外干擾…………………………………………11
四、設備更換 ……………………………………………11
五、網(wǎng)絡優(yōu)化簡述………………………………………15
六、其他PCMCIA Card使用簡介…………………………………21
附錄1、常用命令…………………………………………22
附錄2、故障處理流程圖…………………………………23
基站無線設備排障手冊

一、 要求范圍
A、重大障礙包括基站中斷障礙；載頻故障；小區(qū)退服，嚴重告警
B、一般性障礙包括基站一般硬件告警
C、基站性能統(tǒng)計所反映的障礙
二、 技術要求
A、具有24小時隨時派人到維護現(xiàn)場的能力，原則上獨立進行排障
B、應避免障礙擴大；未經(jīng)許可，不擅自對設備及其組件直接掉電、插拔。
C、在天津移動要求時限內(nèi)排除故障
D、故障處理過程中，隨時與OMC進行通報、配合。
E、故障處理完畢后立即通知有關部門，在值班人員確認后方可離開，并做好故障處理記錄
F、及時返回故障工單，并填寫相應維護記錄
三、故障及處理方法

A、關于Path balance值的問題
P-b值是反映RTF性能的一個參數(shù)，它的計算公式為pathbalance=uplink path loss-downlink path loss+110，故它的最佳值應為110。P-b值不正常是在基站維護過程中經(jīng)常遇到的問題，它會影響到擁塞、掉話等一些敏感的指標，也會造成通話質(zhì)量的下降。
第一部分：造成P-b值不正常的原因
造成P-b值不正常的原因有很多，既有軟件方面的，也有硬件方面的�？偨Y起來主要有以下幾個方面：
1．基站數(shù)據(jù)定義錯誤
2．話務量太低也會造成P-b值不正常
3．相鄰小區(qū)或本小區(qū)同頻或鄰頻干擾也會造成P-b值不正常
4．射頻通路、接收通路硬件故障及連接錯誤
5．載頻本身故障
6．帶外干擾
第二部分：解決P-b問題的步驟
我們知道了造成P-b值不正常的原因，因此先不要急于下站，我們可以先進行一下前期的分析。這有助于我們盡快的解決問題。這個分析主要是根據(jù)OMC終端的統(tǒng)計來做的。
一．先看一下基站是否有告警。
二．是否由于話務量太低，載頻無占用造成P-b值不正常（P-b值為0）。
三．檢查相關數(shù)據(jù)是否有定義錯誤。這包括：
1．接收天線的位置定義是否正確
2．定義的合路器類型是否正確
3．載頻和RTF的相關定義是否正確
4．基站內(nèi)及相鄰基站是否存在同頻或鄰頻干擾
四．倒換RTF位置以便初步判斷障礙點。
一般如果只有較少載頻的P-b值不正常，則可以在下站前將其RTF的位置與同小區(qū)的其它載頻倒換一下，觀察其后一時段的P-b值變化情況，若改換載頻后RTF的P-b值正常，而改換到原RTF所在位置載頻的新RTF P-b值不正常，則可初步認定是硬件故障。
一般如果P-b值不正常的RTF較多，甚至整個小區(qū)的RTF的P-b值都不正常，那么載頻故障的機率就比較小，應側重檢查其數(shù)據(jù)或合路器、天饋線等設備。
五．基站設備檢查：
1．如果P-b值較低，可側重檢查射頻通路；如果P-b值較高，可側重檢查接收通路。具體檢測方法可按操作維護規(guī)程進行檢查。
2．檢查基站連線、天饋線連線及方向是否正確。
3．檢查基站接頭是否有松動現(xiàn)象，基站天饋線序是否與標簽一制。
4．更換基站壞載頻、器件性能不好的基站硬件。
5．基站硬件檢測未發(fā)現(xiàn)問題后，可對基站天饋部分進行檢查。如：駐波比、天線方向等。
六．如問題仍無法解決，將路測文件及基站檢查的詳細記錄移交技術組，并將工單返回OMC并做記錄，由技術組跟蹤問題并分析后提出相關解決建議，由班組聯(lián)合技術組對問題進行進一步處理，直至問題解決。
七．如問題屬于疑難問題，技術組仍無法解決。由技術組協(xié)調(diào)Motorola解決或開SR并作好相關記錄。

B、關于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掉話問題可能產(chǎn)生的原因：
1、突發(fā)事件（突然增高的話務量、相臨基站斷站等）
2、基站硬件問題可能會造成基站SD產(chǎn)生掉話。（載頻、發(fā)射通路、合路器、時鐘問題等）
3、基站天饋性能不好可能會造成基站SD掉話。
4、基站天饋接錯可能會造成基站SD掉話。
5、基站數(shù)據(jù)設置錯誤可能會造成基站掉話。（CCB類型、CCB cavity號定義錯誤等）
6、頻率問題可能會造成基站掉話。（同頻、鄰頻干擾或基站上行干擾等）
7、基站相鄰小區(qū)定義錯誤可能造成基站掉話。（產(chǎn)生SD切換掉話）
第二部分：掉話問題處理的流程：
一．由班組查看統(tǒng)計，是否是突發(fā)事件。
二．由班組重點查看SD所在載頻情況、載頻PB值、載頻IOI值、載頻BER值等統(tǒng)計項，觀察幾天的變化規(guī)律。
三．由班組查看基站和周圍小區(qū)數(shù)據(jù)定義是否正確，是否存在同頻、鄰頻等頻率問題。（數(shù)據(jù)及頻率問題一般在割接、新站及頻率變動工程后易出現(xiàn)）。
四．由班組路測基站及其周圍情況。判斷可能的硬件問題、天饋問題及時鐘問題等。
五．在頻率方面未發(fā)現(xiàn)問題后由班組對基站進行檢查并詳細填寫檢查記錄，檢查內(nèi)容如下：
1．基站有無告警。
2．檢查基站時鐘是否偏離過大。
3．基站發(fā)射功率是否平衡。
4．基站天饋（接收及發(fā)射）有無駐波比高的現(xiàn)象。
5．檢查基站接頭是否有松動現(xiàn)象，基站天饋線序是否與標簽一制。
6．更換基站高掉話載頻、器件性能不好的基站硬件。
六．如問題仍無法解決，將路測文件及基站檢查的詳細記錄移交技術組，并將工單返回OMC并做記錄，由技術組跟蹤問題并分析后提出相關解決建議，由班組聯(lián)合技術組對問題進行進一步處理，直至問題解決。
七．如問題屬于疑難問題，技術組仍無法解決。由技術組協(xié)調(diào)Motorola解決或開SR并作好相關記錄。

C、關于TCH掉話的問題
基站掉話問題是GSM網(wǎng)絡運行過程中一個比較常見的問題，由于產(chǎn)生掉話問題的原因較多，因此很難對掉話問題按其產(chǎ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)生的原因
由于掉話問題較為復雜很難準確定位，因此此處我們僅列出在現(xiàn)網(wǎng)中較為常見的幾種引起掉話的原因：
一．基站硬件問題可能會造成基站產(chǎn)生掉話。（載頻、發(fā)射通路、接收通路、時鐘問題等）
二．基站天饋性能不好可能會造成基站掉話。
三．基站天饋接錯可能會造成基站掉話。
四．基站數(shù)據(jù)數(shù)據(jù)設置錯誤可能會造成基站掉話。（CCB類型、CCB cavity號定義錯誤等）
五．頻率問題可能會造成基站掉話。（同頻、鄰頻干擾或基站上行干擾等）
六．基站相鄰小區(qū)定義錯誤可能造成基站掉話。
第二部分：掉話問題處理的流程
在處理基站掉話問題的過程中可按照以下幾個步驟完成：
一．由班組查看統(tǒng)計，將掉話類型分類，確定掉話區(qū)域。
A．Rf_losses_tch
B．Out_inter_bss_ho_clear
C．Out_intra_bss_ho_lost
D．Intra_cell_ho_lost
二．由班組重點查看載頻掉話情況、載頻PB值、載頻IOI值、載頻BER值等統(tǒng)計項，觀察幾天的變化規(guī)律。
三．由班組查看基站和周圍小區(qū)數(shù)據(jù)定義是否正確，是否存在同頻、鄰頻等頻率問題。（數(shù)據(jù)及頻率問題一般在割接、新站及頻率變動工程后易出現(xiàn)）。
四．由班組路測基站及其周圍情況。判斷可能的硬件問題、天饋問題及時鐘問題等。
五．在頻率方面未發(fā)現(xiàn)問題后由班組對基站進行檢查并詳細填寫檢查記錄，檢查內(nèi)容如下：
3．基站有無告警。
4．檢查基站時鐘是否偏離過大。
3．基站發(fā)射功率是否平衡。
4．基站接收系統(tǒng)有無問題。
5．基站天饋（接收及發(fā)射）有無駐波比高的現(xiàn)象。
6．檢查基站接頭是否有松動現(xiàn)象，基站天饋線序是否與標簽一制。
7．更換基站高掉話載頻、器件性能不好的基站硬件。
六．如問題仍無法解決，將路測文件及基站檢查的詳細記錄移交技術組，并將工單返回OMC并做記錄，由技術組跟蹤問題并分析后提出相關解決建議，由班組聯(lián)合技術組對問題進行進一步處理，直至問題解決。
七．如問題屬于疑難問題，技術組仍無法解決。由技術組協(xié)調(diào)Motorola解決或開SR并作好相關記錄。

D、關于載頻BER高的問題
載頻的BER（Bit Error Rate）含義是載頻工作的時候在其上傳輸?shù)臄?shù)字信息比特的比特誤碼率。
載頻的BER和在該載頻上通話時的通話質(zhì)量是密切相關的。手機在通話時的話音質(zhì)量有8個級別，即Quality=0,1,2,3,4,5,6,7 。0是最好，7為最差。而Quality的0到7是和BER分別對應的。對應關系如下：
RxqualityBER默認BER
0<0.2%0.14%
1 0.2—0.4%0.28%
2 0.4—0.8%0.57%
3 0.8—1.6%1.13%
4 1.6—3.2%2.26%
5 3.2—6.4%4.53%
6 6.4—12.8% 9.05%
7 >12.8%18.1%
一般情況下認為Rxquality在不大于4的時的通話話音質(zhì)量是可以接受的。但當Rxquality大于4時則會出現(xiàn)通話斷續(xù)、雜音甚至掉話的現(xiàn)象。因此從對應關系可以看出，當載頻的BER高于2.26%的時候，即說明該載頻的通話質(zhì)量有問題了，應該盡快進行處理。
第一部分：BER高的原因
造成載頻BER高的原因主要有以下幾種：
一．基站問題引起的BER高
1、信道盤的發(fā)射接收補償參數(shù)不合格
2、信道盤內(nèi)部硬件和架頂發(fā)射接收器件故障
二．頻率干擾引起的BER高
1、同鄰頻干擾造成
2、上行干擾
第二部分：處理載頻BER高的流程
處理載頻BER高的障礙時，首先要判斷是硬件故障還是由于干擾引起的高BER。基本流程如下：
一．通過OMC統(tǒng)計找出BER高的RTF，并找出該RTF（例如 RTF 0 4）所占用的DRI (例如DRI 0 4)。把BER高的DRI 0 4上的RTF 0 4和本小區(qū)正常的一個RTF（例如 RTF 0 5,原來在DRI 0 5上）倒換。過一個小時后，再觀察統(tǒng)計結果。
如果RTF 0 4的BER正常了，而RTF 0 5的BER高了起來，那么說明DRI 0 4這塊信道盤有問題。
如果RTF 0 4的BER仍然很高，而RTF 0 5的BER還是正常的。那么說明RTF 0 4可能受到了干擾，信道盤是沒有問題的。
二．對于信道盤引起的BER高：
1、信道盤的發(fā)射接收參數(shù)不合格會導致信道盤發(fā)射接收的自動增益和衰耗不能正確補償，從而可能導致通信質(zhì)量下降。這種情況只需下站重新校準收發(fā)參數(shù)即可解決。
2、若校準收發(fā)沒有作用，則可能是信道盤故障和發(fā)射接收器件（如CCB ,CBF，IADU,DLNB等出現(xiàn)問題）�？梢愿鶕�(jù)具體情況更換這些硬件來解決。
三．對于頻率干擾引起的BER高
排除了硬件故障原因后，BER高可能是干擾引起的。
1、對于同鄰頻引起的BER高，通話質(zhì)量差，可以通過路測來發(fā)現(xiàn)該載頻周圍是否存在同鄰頻。如果發(fā)現(xiàn)有則可以將測試數(shù)據(jù)移交技術組，由技術組協(xié)調(diào)網(wǎng)絡優(yōu)化部門更改頻點來解決干擾。
2、上行干擾也會影響通話質(zhì)量和BER。上行干擾可以通過OMC統(tǒng)計中IOI一項觀察到上行干擾的影響程度。關于上行干擾問題的解決，可以參照”關于IOI值高的問題“一文中的解決方法。
四．通過以上幾步原因的查找如問題仍無法解決，將路測文件及基站檢查的詳細記錄移交技術組，并將工單返回OMC并做記錄，由技術組跟蹤問題并分析后提出相關解決建議，由班組聯(lián)合技術組對問題進行進一步處理，直至問題解決。