GSM日常指標監(jiān)控及設備預防性維護

1、日常指標監(jiān)控及設備預防性維護第一節(jié) 指標觀測與信令分析介紹指標 ( Performance Indicator ) 是對網絡中發(fā)生的事件進行統(tǒng)計運算，包括兩個部分：計算公式和用來統(tǒng)計某件事情發(fā)生次數(shù)的計數(shù)器( counter ) ，指標反映了網絡的服務質量、實際運行狀態(tài)。其中我們將某些對客戶感知影響較明顯、或是對網絡影響較大的指標定義為關鍵指標(Key Performance Indicator ) , 大多無線側的信令流程都與廠家設備內部的計數(shù)器有對應關系 (文中所出現(xiàn)的廠家設備計數(shù)器均為我省大量采用的北方電訊設備內部所定義的計數(shù)器) ，而性能數(shù)據(jù)中各種指標是設備內部計數(shù)器經過一定運算得出的

2、實際衡量網絡運行狀態(tài)的結果，因此在網絡優(yōu)化中應該特別強調對信令分析、計數(shù)器和NMOK據(jù)中各種指標采取綜合分析的方法.信令采集網絡數(shù)據(jù)有著方便、快速、準確、覆蓋面廣的特點，通過借助專用的軟件分析這些數(shù)據(jù)，能夠及時了解用戶具體通信行為、終端信息，網絡質量和存在問題等，可以為下一步網絡規(guī)劃和業(yè)務發(fā)展提供依據(jù), 目前我省建有專用的中興公司開發(fā)的信令采集平臺，通過這套系統(tǒng)，已基本實現(xiàn)了信令數(shù)據(jù)采集的智能化，因此努力專研相關信令知識，提高自己的優(yōu)化水平，將是我們優(yōu)化人員面臨的一項長期任務。1 .信令分析與NMO DT數(shù)據(jù)指標進行結合1.1 下面針對呼叫建立過程SD®道的分配流程，闡述三者之間的緊

3、密關系 圖 1 SDCCH 信道的分配流程和計數(shù)器對比圖Channel requist這條信令觸發(fā)的計數(shù)器是 C1026它是在Rach信道傳送的，與其相關的是Rach信道的不可解碼電平，對于 NM貨據(jù)中不可解碼電平這項指標有計數(shù)器C1033可查，Channel required 這條信令是在Abis 口傳遞的，它觸發(fā)的總計數(shù)器是 C1027,對應 的各種原因的子計數(shù)器是C1191/07,這條信令中包含發(fā)起此次呼叫的原因，如移動臺主叫 發(fā)起、移動臺被叫回答尋呼、移動臺緊急呼叫或位置更新、呼叫重建等等。各種原因都會 和C1191/X對應。當BSC攵到此條信令后下一步就會給移動臺分配SDCCHS道。

4、以上信令流程中在NM做據(jù)觀測中最關鍵的體現(xiàn)就是SDCCH道的拒絕分配率，此項指 標在信令上的對應是Channel required 和 immediate assignment command 之間的差值，對應的子計數(shù)器是C1161/07其中網絡中BSC巨絕分配SDCC借道的原因多集中于 C1161/1、 C1161/6 等：在SDCCHHE階段要注意：失敗如果產生在信令消息Channel required 和immediateassignment reject 之間即SDCC的拒絕分配率，要觀察計數(shù)器 C1161/X；如果SDCCI配 階段失敗產生在信令消息immediate assignm

5、ent command之后，要觀測計數(shù)器 C1163/5及C1163/17。問題：我省某地市個別基站持續(xù)SDCC分配失敗率較高，約在20%影響了無線接通率指 標的提升。分析：從該扇區(qū)忙時 NMO艮告可看出 C1191/X(Channel required )= C1192/X(Immediate assignment ) = 1059 ，此階段呼叫未受損，在從C1192/X( Immediate assignment )到C1195 + C1196( Establishment iND )期間呼叫從1059損失到 965次。呼叫損失94 次，因此這一步是引起SDCC盼配失敗的主要原因。在這階段

6、主要由 t3101超時引起，查看t3101 觸發(fā)的計數(shù)器C1163/5 其值為95，基本與受損呼叫吻合。結論：此小區(qū)90%S RACK發(fā)二次分配引起SD分配失敗，這種情況不但對接通率有影 響，還會增加系統(tǒng)控制信道的負荷，需要對RACH空制參數(shù)和重發(fā)時間間隔進行適當調整。1.2 后續(xù)的TCH分配、掛機釋放等信令流程中都對應大量指標和相關計數(shù)器，也可參照以 上方法分析，具體如下：在SDCCH!道建立后(Establishment ind )直到系統(tǒng)釋放SD信道，在這期間用于傳送 鑒權、加密信息在此階段的如果產生掉話就為信令信道掉話，對應的子計數(shù)器為 C1163/X(除過C1163/5, C1163

7、/20),信令信道的掉話總和計入 C177&在下面的信令流程就是TCHB道的分配了，這和NMQJ面的TCH&配失敗率和TCH益 出率都有關系。A 接口傳送的 assignment require 消息，在此消息里含有請求信道的類型，觸發(fā)的計數(shù)器是C1841/0, BSC攵到后將為呼叫分配資源，若 BSC6資源將會向MSCS回Resource Failure消息，如果允許排隊的話，BSC向MS3出Queuing indication 消息，并將此次 assignment require 消息放入排隊隊列并啟動定時器 T11,如果超時將向MSCt出Clear Request,并將觸

8、發(fā)計數(shù)器C1163/30,如果有資源BSCE激活資源后將向BTS發(fā)出 assignment command肖息，并觸發(fā)計數(shù)器C1049同時啟動定時器t3107 ,如果BSC攵到返回 的assignment commplete消息將觸發(fā)計數(shù)器C105Q并將T3107置位。在此階段如果有干 擾或硬件問題造成手機無法占用指定信道引起話音信道分配失敗，手機將向BSC®回assignment failure 消息，并將觸發(fā)計數(shù)器C1055。以上過程中和NMOT關的指標如下：(1)TCH試呼次數(shù)，計數(shù)器為 C1841/0,信令消息為assignment require (2)TCH溢出次數(shù)(含切

9、換)：計數(shù)器為 C1039+C1163/30即：BSS方面TCH出和A接口 assignment require 消息排隊超時之和（3）BSS方面TCH配失敗次數(shù)，計數(shù)器為 C1055（4）A 接口方面 assignment require 的失敗次數(shù)C1842/0特別應關注TCH阻塞率和TCW配失敗率，對于分配失敗率要考慮是否存在載波硬件故 障或干擾。1.3 信令分析在DT測試中的作用DT測試可以發(fā)現(xiàn)網絡中存在的很多問題，主要對網絡的下行覆蓋、話質等情況進行評估、并及時發(fā)現(xiàn)網絡中存在的掉話、阻塞、切換失敗等現(xiàn)象。umq物理層為TDMA,鏈路層采用Lapdm協(xié)議，網絡層分為無線資源管理（RR、

10、移 動性管理（MM和呼叫控制三部分（CC ,每次通話建立都有物理層和鏈路層的一個建立過 程，在此基礎上在和網絡側建立第三層的通信，因此對測試結果進行分析時一定要結合空間接口的三層消息，這樣可以更進一步發(fā)現(xiàn)網絡中存在的問題，1.4 日常優(yōu)化需要重點觀測的指標與計數(shù)器計數(shù)器（counter）的值來自OMC勺數(shù)據(jù)庫相應表格的相應字段的值，是 BSC的測量的 結果。BSCffi MS頌責測量網絡中發(fā)生的各種事件的次數(shù)，并以一定的時間問隔來上傳給 OMC上傳成功后將計數(shù)器清零。OMW用來保存BSCM量的表格如raw report 報告等。我們日常關注的關鍵指標有 TCH話率、上下行質量、切換失敗率、TC

11、H1塞率和SDCC擁塞率等，下面是這幾個關鍵指標的計算公式：話音信道掉話率是指話音信道掉話次數(shù)所占話音信道占用次數(shù)的百分比。話音信道掉話次數(shù)北電小區(qū)級RAVREPORT告共有30個掉話計數(shù)器，根據(jù)集團公司下發(fā)的掉話采樣點要求，目前話音信道掉話次數(shù)采集如下共7 個計數(shù)器之和：C1164/8+C1164/13+C1164/14+C1164/16+C1164/17+C1164/24+C1164/25各計數(shù)器說明：C1164/8:指傳輸閃斷引起的掉話。C1164/13:指無線接口失敗引起的掉話。C1164/14:指無線鏈路失敗引起的掉話。C1164/16:指異常釋放引起的掉話。C1164/17:指T2

12、00超時引起的掉話。C1164/24:指t3103切換超時引起的掉話。C1164/25:指T8超時引起的掉話。話音信道占用次數(shù)分為含切換和不含切換兩種，一般計算小區(qū)級話音信道掉話率采用不含切換的話音信道占用次數(shù)，具體計數(shù)器如下：C1841/0 TCH 占用次數(shù)（不含切換）C1609/0 TCH 占用次數(shù)（含切換）切換成功率是指切換成功的次數(shù)占所有切換請求的百分比。切換成功次數(shù)= C1083 + C1067 + C1073 + C1068 + C1074C1083 ： intra BSC 小區(qū)內切換成功次數(shù)C1067: intra BSC 小區(qū)間出切換成功次數(shù)C1073 ： intra BSC

13、小區(qū)間入切換成功次數(shù)C1068： inter BSC 小區(qū)間出切換成功次數(shù)C1074: inter BSC 小區(qū)間入切換成功次數(shù)切換請求次數(shù)= C1081 + C1075 + C1069 + C1076 + C1070C1081: intra BSC 小區(qū)內切換請求次數(shù)C1075 ： intra BSC 小區(qū)間出切換請求次數(shù)C1069 ： intra BSC 小區(qū)間入切換請求次數(shù)C1076 ： inter BSC 小區(qū)間出切換請求次數(shù)C1070： inter BSC 小區(qū)間入切換請求次數(shù)TCH擁塞率是指因為擁塞造成的話音信道溢出次數(shù)占所有話音信道試呼次數(shù)的百分比。不含切換：話音信道溢出次數(shù)=

14、C1039 -(C1069-C1071)-(C1070 -C1072) -(C1081-C1082)+c1163/30話音信道試呼次數(shù)= C1841/0含切換：話音信道溢出次數(shù) = C1039 + C1163/30話音信道試呼次數(shù)= C1841/0 + C1069 + C1070 + C1081SDCCHR塞率是指因為擁塞造成的SDCCHJ道溢出次數(shù)占所有SDCCH1道試呼次數(shù)的百分比。SDCCH1道溢出次數(shù)=C1161/1其中有如下原因可引起SDCCH1道分配異常，但僅有C1161/1為資源缺乏引起：+| NUMBER OF IMMEDIATE ASSIGNMENT REJECT| TRAF

15、FIC WITH MSC | LACK OF RADIO | RECEIPT OF A | NO RESPONSE TO | CLOSED | RESSOURCE | CHANNEL ACT NACK| CHANNEL ACK | C1161/0|C1161/1| C1161/2| C1161/3|+| bsC 100 (WY3BSCE301) | btsSiteManager 2 (miCro95 RuYiDaSha) | bts 0 (miCro95_0)| 0| 0| 0| 0|+| TRAFFIC OVERLOAD | TIMING ADVANCE | OTHER CASES | TR

16、AFFIC | C1161/5| C1161/6| C1161/7|+| bsC 100 (WY3BSCE301) | btsSiteManager 2 (miCro95 RuYiDaSha) | bts 0 (miCro95_0)| 0| 0| 0|+SDCCH1道試呼次數(shù) =C1191/0 +C1191/0 + C1191/7各種SDCC試呼的計數(shù)器具體如下：NUMBER OF CHANNEL REQUIRED| ALL OTHER CASES | NON SIGNIF. | NON SIGNIF. | NON SIGNIF. |PHASE I| OR LOC.UP & OTHER

17、| OR | OR | OR| PROC. ON SDCCH | ANSWER TO PAGING | MOC TCH/HalfRate| CALL RE-ESTAB TCH/H|PHASE II|C1191/0|C1191/1|C1191/2|C1191/3|+| bsc 100 (WY3BSCE301) | btsSiteManager 22 (XA706 (Zhu Que Mao Yi) | bts 0 (XA706_0) | 2345| 2| 0| 0|+| bsc 100 (WY3BSCE301) | btsSiteManager 22 (XA706 (Zhu Que Mao Yi)

18、 | bts 1 (XA706_1) | 1043| 10| 0| 0|+| bsc 100 (WY3BSCE301) | btsSiteManager 22 (XA706 (Zhu Que Mao Yi) | bts 2 (XA706_2) | 592| 7| 0| 0|+| ANSWER TO PAGING | EMERGENCY CALL |RE-ESTABLISHMENT | OTHER MOC SERVICES |PHASE I| OR| MOC TCH/FullRate |PHASE II|C1191/4|C1191/5|C1191/6|C1191/7|+| bsc 100 (WY

19、3BSCE301) | btsSiteManager 22 (XA706 (Zhu Que Mao Yi) | bts 0 (XA706_0)| 654| 6| 0| 836|+| bsc 100 (WY3BSCE301) | btsSiteManager 22 (XA706 (Zhu Que Mao Yi) | bts 1 (XA706_1)| 487| 51| 0| 478|+| bsc 100 (WY3BSCE301) | btsSiteManager 22 (XA706 (Zhu Que Mao Yi) | bts 2 (XA706_2)| 285| 1| 0| 310|+第二節(jié) 日常

20、指標監(jiān)控我們知道了指標的公式，以及計數(shù)器的來源，便可以計算各項指標的值。我們通常通過在OMCt定制任務產生原始計數(shù)器報告，通過在工作站上編制相關AW麻口 SH程序，運算出觀察小區(qū)性能的各項支指標。由于BSC勺測量周期一般是一個小時，即BSC®小時向OMC上傳一次，我們便可以在下個小時開始 5 分鐘左右取到前一個小時的指標情況。通過指標監(jiān)控，我們可以實時掌握網絡運行的狀況，在網絡出現(xiàn)故障時及時發(fā)現(xiàn)并解決。根據(jù)指標統(tǒng)計的事件所發(fā)生的時段，又可以將指標分為全天指標、早忙時指標、晚忙時指標、考核時段 (集團公司定義的對指標進行考核的時段) 指標等。比如早忙時全網掉話率，就是指上午10點11點

21、一個小時內，全網掉話次數(shù)(非正常釋放的呼叫)占全部呼叫次數(shù)的百分比數(shù)。對于不同的指標，我們關心的時段也不同，掉話率的考核時段為 811、1821點， 每天共6個小時；最壞小區(qū)的考核時段為 721點，每天14個小時；切換失敗率的考核時 段為全天 24 小時。根據(jù)指標統(tǒng)計的事件范圍，我們可以將指標分為全網級別、區(qū)域級別 (市區(qū)，郊區(qū)) 、 BSCK別、小區(qū)級別等。對于日常指標監(jiān)控，我們要有一個層次的概念，從高層到低層，逐步定位問題所在， 即著眼于全網指標，從小區(qū)開始處理。對于關鍵指標我們需要每日統(tǒng)計，統(tǒng)計時段依具體情況而定，如果全網或部分BSC性能出現(xiàn)明顯惡化時要及時上報，并進行分析。每天觀察基站

22、性能，按照掉話率、TCHW塞率、SDCCH塞率、切換失敗率等指標分別進行排序，對性能異常，如掉話、擁塞等突然上 升，并有較大影響的基站要及時處理。2.1 高掉話小區(qū)的處理每小時關注前一小時各小區(qū)的掉話率和掉話次數(shù)，對于掉話次數(shù)大于 100次小區(qū)需要 及時處理，每天處理前一天掉話 T0P10勺小區(qū)。掉話是指通話過程中的通道非正常釋放，通常掉話有3個主要原因： 無線鏈路失敗（北電系統(tǒng)中的無線鏈路超時） 切換計時T3103超時，除BSS內切換。 其它系統(tǒng)故障 無線環(huán)境引起T200超時 異常釋放以上各種原因都可能產生掉話，處理高掉話小區(qū)時，需要分析掉話的原因，然后針對具體 情況提出解決方案。問題描述a

23、）無線鏈路超時移動臺不能發(fā)出SACCH（U量報告消息），或者在規(guī)定時間內沒有被網絡（BTS）譯碼，也 無法執(zhí)行其它切換，這就是無線鏈路超時掉話，計數(shù)器 C1164/13和C1164/14統(tǒng)計由于無 線接口失敗和無線鏈路失敗所引起的連接失敗。b） T3103 超時：MSHandover completeHandover .complete 一 Reset T3103當BSC等Handovercommand息發(fā)送至ij BTS時，BSC啟動定時器T3103。在BSC攵至U 來自切換目標小區(qū)的 Handovercomplete或者來自源小區(qū)的 HandoverFailure 時將T3103復 位，若

24、T3103至I時而BSC仍未收到任一種消息時，BSCft判斷在源小區(qū)發(fā)生了無線鏈路失 敗，進而釋放源小區(qū)的信道并記錄一次掉話。計數(shù)器C1164/24是用來統(tǒng)計T3103超時的次數(shù)的，因此它可以反映切換由于 T3103超時而造成的掉話數(shù)量。c）系統(tǒng)故障掉話也有可能是由系統(tǒng)故障引起。如由于操作維護的原因造成的掉話，和 BSSMAP時 器不匹配造成的掉話，但是這些原因與無線接口沒有直接的相關性，涉及到 BS用口 NS文問 的配合問題。掉話分析：良好的維護可預防和解決絕大多數(shù)掉話問題，特別是高掉話小區(qū)（例如8%Z上一），應首先檢查是否有設備故障。在排除了系統(tǒng)因素后才應考慮無線原因。掉話主要由以下原因

25、引起覆蓋問題： 真正沒有信號覆蓋的地方，比如因基站太少導致覆蓋不連續(xù)。 另一種是切換不及時。在一些信號會迅速減弱的地方（隧道，門廳，地鐵），如果切換反應速度過慢，可能在通話還未接入新的信道之前，原來的 信道已經衰落到無法正常譯碼信令，從而導致掉話。 覆蓋空洞也可能是由于某個小區(qū)出現(xiàn)了問題（例如因設備故障造成小區(qū)癱瘓）。 覆蓋空洞還可能是由于丟失鄰小區(qū)定義或定義不全，此時，系統(tǒng)會保持通話 在現(xiàn)有小區(qū)中，直到超出該小區(qū)覆蓋邊緣而掉話。干擾問題：干擾有來自內部（網絡造成），和外部其它系統(tǒng)交調造成。當網絡中存在干擾，BTSffi MS由于誤碼率高而不能解出SACCH內容，無線鏈路 超時，從而中斷通話。

26、干擾對切換也有負面影響，因為下行鏈路誤碼率高，移動臺就無法解出BTS發(fā)出的切換請求命令。在由T3103超時引起的掉話在OMC-R中有記錄。為了確認小區(qū)干擾,可以檢查統(tǒng)計項？ “Average Level of NondecodedRACH” ?（反映上行鏈路干擾），“Ratio of HO on UL Quality? ”（反映上行鏈路高誤碼率）和“Ratio of HO on DL Quality? "（反映下行鏈路高誤碼率）以及Band級別反映空閑信道上行干擾情況。解決措施 如果掉話率突然上升并且本站工作正常，檢查相鄰小區(qū)此時是否工作（見TCH可用性）。 檢查在OMC數(shù)據(jù)庫中定義

27、的相鄰小區(qū)是否互為對稱關系，是否鄰小區(qū)表定 義不全。 路測（采用掃描方式）并與無線設計人員共同檢查是否確有覆蓋空洞存在。 檢查是否存在特殊原因：隧道，大型建筑入口 （商業(yè)中心），地鐵入口，大斜坡（和汽車速度，一天中的交通流量有關，一般來說，掉話多集中于一段時間和某個方向）。最好的解決辦法是先檢查地圖，聽取工程人員和無線工程師建 議，并進行現(xiàn)場勘察。 利用路測檢測鄰小區(qū)丟失的情況。進一步作 Abis接口測試或呼叫路徑跟蹤， 對找到問題很有幫助，需注意從測量結果中分析連接失敗前的時間提前量（TA）以發(fā)現(xiàn)孤島效應。上下行低電平導致的掉話由于上下行電平值較低導致的掉話，一般發(fā)生在電梯、地下停車場、隧道

28、等存在覆蓋漏洞的地方。掉話的原因主要是 Radio_Fail和RF_HO從報告中可以看到平均電平值較低，切換的原因只要集中在上/下行電平引起的切換。我們通過路測和用戶投訴，可以定位這些網絡中弱覆蓋的區(qū)域。解決的辦法主要是增強覆蓋，如增加直放站、換高增益天線、對全向站實施。改S在室內增加天線分布系統(tǒng)、或者增加新站。鄰區(qū)擁塞導致掉話在這種情況下，由于最好的鄰區(qū)存在擁塞，用戶不能切換到最好的鄰區(qū)去導致掉話。從統(tǒng)計指標可以看出，鄰區(qū)話務量較高、存在 TCHW塞、切換失敗率較高，而本小區(qū)存在大量 的切換掉話。這種情況的解決辦法就是減小鄰區(qū)的擁塞 （具體方法在擁塞小區(qū)解決辦法中有介紹） ，減少 向擁塞鄰區(qū)

29、的切換。上下行質量差導致掉話上下行質量差的原因可能是硬件問題、外部干擾或是頻率規(guī)劃問題，這種掉話小區(qū)一般67 級質量所占比例較高，切換原因主要是質量引起的切換。判斷導致質量差的原因是硬件問題還是干擾，如果是硬件問題就要通知基站維護人員更換故障硬件，如果是干擾還要判斷是內部干擾還是外部干擾，如果需要就調整載頻頻點，或是控制小區(qū)覆蓋。漏加鄰區(qū)導致掉話漏加鄰區(qū)一般發(fā)生在集中幾天時間有很多新站入網、或者。改S的時候，又或是相鄰地市有新站入網和。改S沒有通知我們增加鄰區(qū)。通過UAC（未定義鄰區(qū)）的測量，如果平均接收電平值很高、而測量點數(shù)又很多就可以判斷 為漏做鄰區(qū)。在MAPINF5查看這兩個小區(qū)的距離，

30、如果較近時需要增加鄰區(qū)關系，如果 距離較遠，則需要減小小區(qū)覆蓋范圍（通過調整天線高度、下傾角，或者參數(shù)）。參數(shù)設置錯誤導致掉話影響掉話的參數(shù)主要有： C2, RLT, T3103 等。在新站集中入網期間或是網絡割接之后，容易發(fā)生參數(shù)設置錯誤的情況。因此，我們需要定期對全網的參數(shù)進行檢查，對比現(xiàn)網配置參數(shù)與規(guī)劃默認值，發(fā)現(xiàn)錯誤及時修正。以上是幾種常見的掉話的解決方案，如果監(jiān)控到某小區(qū)有突發(fā)的高掉話，一般是外部干擾或是硬件故障導致。2.2 高切換失敗小區(qū)處理切換失敗的原因：切換失敗可以劃分為兩方面的問題：即信道容量、無線鏈路失敗。可分為切換選擇階段和切換執(zhí)行階段兩個失敗階段。Handover Se

31、lection Failure 是從 BSC 至U BTS的 HO_COMMAND 數(shù)與 BTS攵至心勺HO_INDICATION 數(shù)之差。它可以幫我們找出由于目標小區(qū)信道資源不足引起的切換失敗，或系統(tǒng)的問題（難以建立BSC與BTS之間的L2連接）。HandoverExecutionFailure 是數(shù)與 BSC 發(fā)向 BTS的 HO_COMMAND 數(shù)與 BSC 收至U的 HO_COMPLETE 之差。主要反映了空中無線接口的質量。失敗原因 硬件問題：當切換失敗率非常高時，硬件故障 （包含CMCF壞引起的同步時鐘問題）可能性最大（見分配失?。?相鄰小區(qū)關系問題 鄰小區(qū)負荷 惡劣的無線條件相鄰

32、小區(qū)關系問題如果兩個小區(qū)有相同的（BSIC, BCCH）,在正常的情況下這樣的兩個小區(qū)的相距距離應該足夠大，他們之間不應該有什么關系。但由于孤島現(xiàn)象的存在，一旦 孤島覆蓋周圍的小區(qū) 的鄰小區(qū)表上定義了與孤島小區(qū)同 BSIC、BCCH的鄰小區(qū)）位于的通話手機將會收到孤島小區(qū)的BCCH信號并上報BSC,這個虛假的鄰小區(qū)測試報告將會誤導切換控制程序發(fā)出切換 指令，這樣就使得這些小區(qū)內的通話頻頻嘗試向實際信號并不好的小區(qū)發(fā)出切換請求。其 結果往往造成乒乓切換，并導致孤島覆蓋周邊小區(qū)的切出切換失敗率大幅提高。而與孤島 小區(qū)具有相同BSIC、BCCH的小區(qū)的切入切換失敗率也將大幅提高。源小區(qū)鄰小區(qū)通道資源

33、短缺如果Hoselectionfailurerate切換選擇失敗率很高，原因可能是要切換的鄰小區(qū)負荷 高，目標小區(qū)已經沒有可用TCH。此時，BSC雖然收到HO_INDICATION信息但并不向目標小區(qū)發(fā)送任何HO_COMMAND 消息。對于一對鄰小區(qū)上的高切換選擇失敗率，可查看目標小區(qū)的負荷以確認是否為負荷問題。惡劣的無線條件如果HandoverExecutionFailure rRate很高，那就有可能是目標小區(qū)或源小區(qū)無 線條件方面的原因。 覆蓋：如果目標小區(qū)與源小區(qū)之間沒有足夠的重迭覆蓋區(qū)域，切換可能應無 法登陸目標小區(qū)的TCH而失敗。在這種情況下，重新回到舊小區(qū)的概率會較 低。低重迭覆

34、蓋區(qū)源小區(qū)目標小區(qū) 干擾：干擾會造成即使目標小區(qū)的電平很好，但上 /下行信號質量很差的情況移動臺將難以占上目標小區(qū)的 TCH。如果來切換執(zhí)行失敗率很高，必須檢查小區(qū)的 干擾情況。對每一對鄰小區(qū)檢查來/去切換執(zhí) 行失敗率能夠指明干擾是存在于某一對小區(qū)還是很多小區(qū)，并進而大致判斷干擾區(qū)域和干擾性質。如果去切換執(zhí)行失敗率很高，可能是因為切換發(fā)起小區(qū)的下行干擾。移動臺無法譯碼BTS發(fā)出的HANDOVER_COMMAND這時由于T3103超時（計數(shù)器C1164/24）,將產生掉話。還 有可能是目標小區(qū)的下行或上行干擾。因此，需要認真檢查每一對相鄰小區(qū)，以幫助判斷 干擾原因。同時檢查目標小區(qū)的切換執(zhí)行失敗

35、率和分配失敗率的相關性。干擾造成的高切換失敗率往往伴隨著高分配失敗率。為了確認小區(qū)的干擾，檢查計數(shù)器“ Average Level of Non decoded RACH? ”， 并 且同時查看 “ Ratio of HO on UL Quality ” 和 “Ratio of HO on DL Quality ” 。解決措施：相鄰小區(qū)關系問題 對于一對鄰小區(qū)，檢查切換執(zhí)行失敗率過高是否由孤島效應引起。作Abis測試并重點檢查時間提前量（TA）有助于找出孤島效應?？稍黾庸聧u小區(qū)的天線下傾角以減輕孤島效應或改變它的 BSIC以消除同BCCH , BSIC的現(xiàn)象。 檢查數(shù)據(jù)庫看鄰小區(qū)表與 BTS參

36、數(shù)是否匹配。如果有，在 OMC-R中修改。 鄰小區(qū)負荷如果BTS在HO_INDICATION中選擇的小區(qū)都超載，那么 HO selection failure rate 會很高。解決方法見TCH/SDCCH不足。另外，為HO設置高于通話建立的優(yōu)先級別也可有效地解決HO選擇失敗問題。惡劣的無線條件 重迭覆蓋少：檢查覆蓋預測圖，注意那些特殊地點（隧道），一旦懷疑，最好進行路測以便確認。并采取相應的無線優(yōu)化手段改善覆蓋。提高小區(qū)的覆蓋 可以通過減小下傾角或增加天線高度來實現(xiàn)。但是這樣可能會干擾其它鄰小 區(qū)。根本方法是增加基站或微蜂窩，但這已超出了優(yōu)化范圍。切換失敗原因總結如下：切換參數(shù)設置錯誤鄰區(qū)參

37、數(shù)設置不正確硬件故障PLMN（ permitted NCC ）參數(shù)設置錯誤干擾鄰區(qū)擁塞覆蓋漏洞鄰區(qū)TCH輸出功率低于BCCH定義太多鄰區(qū)關系MSC/BSC：據(jù)定義錯誤2.4 TCH/SDCCHH塞小區(qū)處理擁塞的原因：高話務量基站過覆蓋硬件問題LAC區(qū)域規(guī)劃不合理，導致過多的位置更新或過多的paging消息（SDCCH0塞）如果發(fā)現(xiàn)小區(qū)擁塞，首先要查看硬件告警，檢查小區(qū)每線話務量，確定是否基站故障導致?lián)砣τ趽砣^(qū)解決辦法只有兩大類：降低小區(qū)吸收的話務量和增加小區(qū)承載能力。TCH擁塞的解決辦法增加容量的辦法有：擴容（增加載頻），打開半速率，增加新站。降低話務量的辦法有：a） 降低基站天線高度

38、，增大下傾角b） 使用 DRc）減小基站覆蓋范圍，增大最小接入電平值（RXP，降功率（PMAXd） 使用 C2e） 減小小區(qū)過載門限值BLTf） 調整鄰區(qū)參數(shù)使得鄰區(qū)不容易切換進來（SL， PMR，G OF， PRI， DRT）SDCCH1塞小區(qū)的解決辦法增加容量的辦法有：a） 增力口 SDCC時隙b） 擴容（增加載頻）c） 使用動態(tài)SDCCHd)減少小區(qū)覆蓋范圍e)減少位置更新的次數(shù)(增大 HYS增大周期位置更新的周期PER 。第三節(jié)設備告警查看及預防性維護北電無線子系統(tǒng)設備的日常維護包括 BSC OMC BTS PCUSN&備的日檢，BSC OMC BTS PCUSI®備

39、的月檢，OMCBTS設備的季檢，BTS設備的年檢等，其中BTS的月檢、季 檢、年檢等大部分需要在現(xiàn)場使用測試儀表進行檢測。3.1BSC12051、 狀態(tài)檢查以下項目及指令均可用 auditBSC.log批處理工具查看全部結果：serv1:(omc)% more /home/STAT/ auditBSC.log(1) 雙工狀態(tài)檢查： 指令在 MMI上 display chain information 或執(zhí)行serv1:(omc)%cd /OMC/data/calendar/jobResults md結果所有BSC應為" duplex” 即主備CHAIN均處于工作狀態(tài)或使用：指令結果所

40、有BSC勺'active - passive link '應為"opened”表示主備用CHAINS間在實時的更新數(shù)據(jù)指令結果此命令的結果應為“0”當BSC處于單工工作狀態(tài)時必須調查原因及時處理(2) BDA audit狀態(tài)檢查 指令選擇 bsc 目標：/ Configuration / BDA / Audit / Send,在 Session log 查看結果是否為“no difference ”或執(zhí)行serv1:(omc)%cd /OMC/data/calendar/jobResultsserv1:(omc)%more auditBSC*.administrato

41、r.yyyymmdd結果所有 BSC的 BDA audit 結果應為"no difference ".BDA :為BSC硬盤中的數(shù)據(jù)庫；BDE為OMC-R上的數(shù)據(jù)庫在OMC-Rk的每一個 BSC的數(shù)據(jù)應和BSC硬盤中的數(shù)據(jù)一致。如不一致，會隱含一些問題。或執(zhí)行指令結果列出在auditBSC1的log文件中，BSC audit 結果是"no difference ” 的清單。(3) 循環(huán)文件狀態(tài)指令選擇"BSC X25"目標/ Configuration / Circular File / Display state /Circular File

42、ID / Apply ,在 Session log中查看結果；或執(zhí)行serv1:(omc)%cd /OMC/data/calendar/jobResults結果所有BSC勺'ficCircState '應為 “open”或執(zhí)行指令結果所有 BSC勺'ficCircState '應為 “open”(4) BSC告警狀態(tài)檢查(FN5,6,7,8,11,13,16,23,24,115x,5xx,6xx, 1290,1310,31010,30061,30063)指令(omc)%cd /home/user/support/Genstat.sh automatic(omc)

43、%more GENSTAT_RES結果如出現(xiàn)以下故障：Fault Number: 5,6,7,8,11,13,14,15,16,23,24,125,126,138,140,170,2xx,3xx,4xx,5xx,6xx,1290,1310,31010,30061,30063.,則做相應記錄并進行故障處理，以上故障號為涉及BSC®啟、重要電路板故障、BDET BD環(huán)一致等重要故障，必須調查原因并做相應處理。參考：FN1153: SICD8V故障 FN1151: PCMB定性能標志FN5 、6 BSC CHAIN 重啟 FN7 、2XX 4XX 5XX: BSC重要板子故障FN1067、

44、1070:基站硬件故障 FN31010 : BDAf BD環(huán)一致FN122:鄰小區(qū)存在問題FN117X 、118X: TCUkTCB2r作不穩(wěn)定FN8 : TCB城故障FN493、497: TC進行了時鐘重選FN1310:關于CIC的NSS®未知錯誤 FN1290 :關于CIC的BSSW未知錯誤(5) TCU告警狀態(tài)(FN7,117x,118x);指令(omc)%cd /home/user/support/ Genstat.sh automatic(omc)%more GENSTAT_RES結果如出現(xiàn)以下故障：Fault Number: 1170, 1171, 1172, 1174,

45、1180, 1182, 1184, 1186,則做相應記錄并進行故障處理，或打NTSt援電話。2、 性能檢查以下項目及指令均可用 NETcheck比處理工具查看全部結果：oam:(omc)%more /home/users/NETCHECK/jobresults/cpuYYYYMMDD(1) CPU負荷情況；實時觀測：在 MMI上選擇 Performance/display raw report, 輸入BSCf關參數(shù)， “APPLY ,在Session log 中查看結果，觀察所有 CPU負荷情況(應小于 50%每日觀測：指令oam:(omc)% more /home/users/NETCHE

46、CK/jobresults/*cpuYYYYMMDD結果CPU平均負荷小于50%(2) SCCP巨絕率實時觀測：在 MMI上選擇 Performance/display raw report, 輸入BSCf關參數(shù)， “APPLY ,在Session log中查看結果，觀察計數(shù)器C1803值(SCCP巨絕次數(shù))，及拒絕率(應小于3% 每日觀測：指令oam:(omc)% more /home/ NETCHECK/jobResults/*bscYYYYMMDD結果SCCP巨絕率應小于3% （對北電交換機）（二）BSC e3BSC編BDAaudit 狀OMUT 達cpuW無過BSC告警狀態(tài)號態(tài)性載(F

47、N2008、 2021、位仕average >50%2036、2032 等 20*)BSC31BSC32BSC33BSC911、BDA一致性檢查(Audit BDA )描述：驗證在OMCR Sybase和BSCe3之間沒有 BDM一致。操彳:在MMI,選擇目標 BSCe?從頂部的下拉菜單選擇Configuration/BDA/Audit ;從respond window 中檢查運行結果。期望結果：結果應當顯示"no difference "。2、BSC狀態(tài)檢查描述：檢測在BSCe3/TCUe3±是否有異常的狀態(tài)改變。操彳:以omc用戶登錄OMC-柱用服務器，

48、然后運行指令：1、 ome/omc/oam/BSCe3_MaintPrev/stChangeStat.tcl - BSBSC ID - FD1 - Obj -Notif 下面是該指令的輸出范例：XAserv1:/home/omc/oam/BSCe3_MaintPrev <45> (omc) % stChangeState.tcl -BS9 -FD1 -Obj -Notif ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff f

49、f ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7T it a 1T7T it M TTTTTTTrTTTTTTTTTTTTTrTrTTTT it it TTTT it n TTTT it it TTTTTTTTTTTTTTTTTTTTnt it ti IT it it TT-ii it it IT it it it IT it it if it it TTtt it IT i

50、t it 7TTT it it TTTT it n TTTT n it iT ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii iiThe tool will scan the

51、 following state change :Operational State = disabled,availabilityStatus = failed :all objectsOperational State = disabled,availabilityStatus = notInstalled :controlNodeomu,mms,cc1 InterfaceNodecem,atmRm,sw8kRm transcodercemOperational State = disabled,availabilityStatus = dependency : signallingLin

52、k signallingLinkSet bts transceiverff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 7T ff ff TTTT it M TTTTTT

53、TrTTTTTTTTTTTTTrTrTTTT it it TTTT it n TTTT it it TTTTTTTrTTTTTTTTTTTTnt it tt IT it ti TT-ii it it IT it it it IT it it if it it TTtt it IT it it 7TTT it n TTTT it n TTTT it it iT ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii

54、 ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii ii2004/04/22 14:46:28 End of search for state changes2004/04/22 14:46:28 Begin Treatement of found objectsI1| Instance/BSC| 9 |I1| bscMdInterface| 0 |> 0表示沒有錯誤III| bscI 0 IIIIcont

55、rolNode| 011omu| 011mms| | 0cc| 0 |11tmu| 0 |11interfaceNode| 011cem| 0 |11atmRm| 0 |11sw8kRm| 011iem| 0 |11lsaRc| 0 |11pcmCircuit| 011transcoder| 011lsaRcTcu| 0|cem| 0 |11iem| 0 |11trm| 0 |11pcmA| 0 |signallingLink| 0|signallingLinkSet| 0|如果有異常的狀態(tài)改變，請參考下列文檔去檢查系統(tǒng)通告 (即 notifications ) BSCe3/TCUe3Fault Number Description: PE/DCL/DD/0131 (NTP 131)BSC2G/TCU2G/BTS/PCUSN Fault N