1、BMCC PROJECT OPTIMIZATION(E) GPRS日常監控處理2010-5-19BMCC PROJECT OPTIMIZATION目錄(E) GPRS日常監控處理 1目錄 21. GPRS SLEEPING CELL監控及處理 31.1 GPRSSLEEPING cell監控及處理流程圖 31.2 GPRSSleeping Cell 監控 31.3 GPRSSleeping cell 處理 41.4 GPRSSleeping Cell 處理后的監控 42. EGPRS SLEEPING CEL 監控及處理 42.1 EGPRS SLEEPING CELL監控及處理流程圖 42.

2、2 EGPRS SLEEPING CELL 監控 52.3 EGPRS Sleeping cell 處理 62.4 EGPRS SLEEPING CELL 處理后的監控 63. 3273告警監控及處理 63.1 3273告警監控及處理流程圖 73.2 3273告警監控 73.3 3273告警處理 83.4 3273告警處理后的監控 84. 7725告警(BTS級告警)監控及處理 84.1 7725告警監控 84.2 7725告警處理 94.3 7725告警處理后的監控 95. 故障 PCU 95.1 故障PCU監控 95.2 故障PCU處理 105.3 故障PCU處理后監控 106 其他BSC

3、級告警的監控與處理 106.1 3019/3020 告警處理 106.2 3031告警處理 117 GB負荷過高監控處理 128 PCU的容量配置監控與調整 139 SGSN相關指標監控 1410各類性能監控周期、處理時限與記錄要求 1510.1 監控周期與處理時限 1510.2 記錄要求 16BMCC PROJECT OPTIMIZATION19/05/2010Networks1. GPRS Sleeping Cells監控及處理1.1 GPRS Sleepi ng Cell 監控及處理流程圖1.2 GPRS Sleepi ng Cell 監控每半小時查看一次 GPRS小區的各項指標，從而發

4、現GPRS Sleeping Cell.GPRS Sleeping Cell故障現象如下：(E)GPRS日常監控及處理流程.docBMCC PROJECT OPTIMIZATION? 很多的 PACKET IMMED ASS REJ MSG 和很少的 PACKET IMMED ASS ACK MSG 現象,即分組信道指派成功率低。? 很高的上/下行TBF建立失敗率? 從OMC KPI上來看，上/下行有效數據量、上/下行平均每時隙TBF數等均不正常（為 0或較之前降低很多）注：PACKET IMMED ASS REJ MSG 和 PACKET IMMED ASS ACK MSG 兩個 count

5、er 在 表Packet Control Unit Measurement 中，可以直接查看這兩個 counter值的變化從而 判斷出GPRS Sleeping Cell并做出相應的處理。1.3 GPRS Sleepi ng Cell 處理監控出現GPRS Sleeping cell之后,首先保證這個cell有GTRX,并且GENA已經打開. 對于GPRS Sleeping cell,如果發現其同時存在7725告警，則需參照后面處理7725的方法 進行，如果不存在7725告警,一般依次進行如下處理步驟：a）.重啟GPRS功能開關（即GENA）；b）.重啟GTRX（TRX 上的GPRS開關）；c

6、）.調換 GPRS Sleeping cell 的 NSEI ；GPRS Sleeping cell 的處理，主要有以上三種方法，依次進行.如果以上各步驟均無效, 則有兩種應對措施:1.及時通知運維倒換PCU,即切換BCSU ； 2.通知相關人員（如基站工 程師等）進行處理.1.4 GPRS Sleepi ng Cell 處理后的監控GPRS Sleeping Cell每一個處理步驟過后，均需要查看之后半小時的相關指標，如果指標不 正常,則需要進行下一步.處理后的查看指標如下：? 上、下行GPRS有效數據量（KB）?分組信道指派成功率? Packet Immediate Assig nment

7、 Messages? 上、下行TBF建立成功率? 上、下行TBF數2. EGPRS Sleeping Cell 監控及處理2.1 EGPRS Sleepi ng Cell 監控及處理流程圖BMCC PROJECT OPTIMIZATION2.2 EGPRS Sleeping Cell 監控每半小時查看一次 EGPRS小區的各項指標，從而發現EGPRS Sleeping Cell.EGPRS Sleeping Cell故障現象如下：? 問題小區的GPRS統計正常,但是EGPRS流量突然大幅度降低；BMCC PROJECT OPTIMIZATION? 從 OMC/KPI 上來看,沒有或者很少的 E

8、GPRS UL/DL TBF Number、EGPRS UL TBF Number 與 DL TBF Number 差別很大、EGPRS DL Payload為 0;? Expired LLC frames (%) DL 過高? UL/DL multi-slot allocatio n blocki ng(%) 過高? 有用戶投訴EGPRS不可用2.3 EGPRS Sleepi ng Cell 處理監控出現EGPRS Sleeping Cell之后,排查該類小區是否無用戶、是否 EDGE新規劃基站. 對于EGPRS Sleeping cell,如果發現其同時存在7725告警,則需參照后面處理7

9、725的方 法進行,如果不存在7725告警,一般依次進行如下處理步驟：a) 檢查EGPRS參數設置是否正常? EGENA是否打開；? GTRX是否設置正確；? EDAP是否綁定；b) 重啟 EGENA(需要 Lock BTS)；c) 調換問題小區的NSEI ；EGPRS Sleeping cel的處理，主要有以上幾種方法.如果以上各步驟均無效，則有三種應對措 施:1.首先建議關閉EGENA.,保證EDGE用戶可以使用GPRS上網.2及時通知運維倒換PCU, 即切換BCSU ； 3.通知相關人員(如基站工程師等)進行處理.2.4 EGPRS Sleepi ng Cell 處理后的監控EGPRS

10、Sleeping Cell每一個處理步驟過后，均需要查看之后半小時的相關指標，如果指標 不正常，則需要進行下一步處理后的查看指標如下：? 上、下行EGPRS有效數據量(KB)? EGPRS上、下行TBF數UL/DL multi-slot allocatio n block in g(%)Expired LLC frames (%) DLPacket Immediate Assig nment Messages上、下行TBF建立成功率3. 3273告警監控及處理BMCC PROJECT OPTIMIZATIONNetworks3.1 3273告警監控及處理流程圖3.2 3273告警監控3273告

11、警(EGPRS TERRITORY FAILURE) 是PCU的容量預警，一般是由于PCU負荷過高 導致(但也有個別PCU負荷較低而出現該告警的情況)。每半小時提取一次3273告警BMCC PROJECT OPTIMIZATION故障現象如下：? BSC 出現 3273 告警（E）GPRS TERRITORY FAILURE）；? 相關BTS的可用EGPRS信道數低于CDEF參數定義的默認信道數。3.3 3273告警處理監控查出發生告警的BSC,進入到該BSC,查看3273告警的附加信息，確定相關故障小區（使 用指令:ZAHO）.? 如果同一 PCU下某1,2個小區出現3273告警,一般是由于

12、該PCU的負荷過高導致，解 決措施就是將出告警的小區挪至負荷較低的PCU.? 如果同一 PCU下多個小區同時出現3273告警,且將其下部分小區調至其他 NSEI下之 后，仍舊出現多個告警，則很有可能是該PCU出現故障，需要立即向網絡運行支持中心集 中監控中心（小號:7312173126）通報情況，及時處理? 如果以上方法均不奏效,或者各個PCU負荷都較高，則有兩種應對措施:1.關閉EGENA,2. 降低GPRS/EGPRS的PDCH信道數.此外，高話務下話音業務擠占GPRS信道也會導致可用EGPRS信道數低于CDED 參數定義的默認信道數，產生3273告警。解決措施：均衡話務，適時提/催擴容建

13、議。3.4 3273告警處理后的監控3273告警處理過后，要查看下個時段的相關 OMC KPI是否正常：? 上、下行GPRS有效數據量（KB）?分組信道指派成功率? GPRS邊界升級拒絕CS話務過高? GPRS邊界升級拒絕BTS信道受限? GPRS邊界升級拒絕PCU信道受限? 上、下行EGPRS有效數據量（KB）?（ E）GPRS上、下行TBF數4. 7725告警（BTS級告警）監控及處理4.1 7725告警監控BMCC PROJECT OPTIMIZATION7725告警的監控需要與 GPRS Sleeping Cell和EGPRS Sleeping Cell相結合.監控出指 標異常小區后，

14、看該小區是否有7725告警(使用指令:ZEOL).7725告警：TRAFFIC CHANNEL ACTIVATION FAILURE, 附加信息為”2”表示是PDCH信道激活失敗.4.2 7725告警處理如果故障小區集中在某個 PCU下，則說明是該PCU出現問題,需要立即聯系網絡運行支撐 中心倒換相應PCU.如果故障小區分布于不同的 PCU,則依次進行以下處理方法：? 針對 GPRS 小區(或 master BTS)a) .重啟 GENAb) .調換故障小區的NSEIc) .重啟出現告警的BTS和TRX? 針對 EGPRS 小區(或 slave BTS)a) .重啟 EGENA(需要 Lock

15、 BTS)b) .調換故障小區的NSEIc) .重啟出現告警的BTS和TRXd) .關閉slave BTS的跳頻(針對BSC的CD3升級所導致的EDGE Sleeping Cell) 7725告警是一部分sleeping cell會出現的現象，與sleeping cell處理方法類似.如果以上各步驟均無效，則通知相關人員(如基站工程師等)進行處理.4.3 7725告警處理后的監控7725告警處理過后，要查看下個時段的相關 OMC KPI是否正常? 上、下行GPRS有效數據量(KB)?分組信道指派成功率? 上、下行EGPRS有效數據量(KB)?( E)GPRS上、下行TBF數? 上、下行TBF建

16、立成功率5. 故障PCU5.1故障PCU監控BMCC PROJECT OPTIMIZATION19/05/2010對于故障PCU的監控，主要是通過網管統計中：表NPMDB_V_P_數據業務_嚴重問題 NOKIA的數據來進行。該表將沒有 PS域數據統計的PCU列出。我們查看各個PCU及其 所掛小區的現網狀態，從而更進一步將 PCU的故障問題細化，大致分為如下兩種情況：a) PCU下面小區無PS域數據統計，且的確存在故障的情況。如：PCU的兩條GBBear均為BL_SY的狀態，且有3030, 3031告警；PCU所掛小區均發生3273告b) PCU下面小區無PS域數據統計，但不確定是否存在故障的情

17、況。這種情況下，PCU不存在任何告警，PCU對應的GB Bear的狀態以及PCU所掛小區的狀態均 正常。因為沒有PS域數據統計，所以無法通過指標來實現對小區或者PCU的監控。只能通過現場測試或者投訴情況，來判定。5.2故障PCU處理a).對故障PCU的處理，一般都需要上報網運來執行。5.3故障PCU處理后監控處理過后，要查看各小區相關 OMC KPI是否正常：? 上、下行GPRS有效數據量(KB)?分組信道指派成功率? 上、下行EGPRS有效數據量(KB)(E) GPRS上、下行TBF數6其他BSC級告警的監控與處理6.13019/3020告警處理1) .故障現象? BSC出現3019或者30

18、20告警：3019 NETWORK SERVICE ENTITY UNAVAILABLE3020 NETWORK SERVICE VIRTUAL CONNECTION UNAVAILABLE ? 該PCU覆蓋區域內的GPRS網絡不可用。2) .處理措施? 查看NSEI的NSVC狀態BMCC PROJECT OPTIMIZATION19/05/2010? 查看BSC告警情況，使用指令：ZAHO、ZAHP? 告警發生的可能原因是 Gb鏈路出現故障,PCU硬件出現問題,BCSU重啟后,PCU 沒有恢復正常工作或者是 SGSN中的相關單元出現故障，因此需要立即聯系網絡 運行支撐中心通報情況，了解處理進

19、度? 在該PCU故障恢復之前，需要重啟指定NSEI，將其下的小區分配到其他的PCU 下工作，待故障解決后再行恢復3) .處理后監控處理過后，要查看下個時段的相關 OMC KPI是否正常：? 上、下行GPRS有效數據量(KB)?分組信道指派成功率? 上、下行TBF數? 上、下行EGPRS有效數據量(KB)? EGPRS上、下行TBF數6.23031告警處理1) .故障現象? BSC 出現 3031 告警(BSSGP VIRTUAL CONNECTION RESET PROCEDURE FAILED)? 相關小區的GPRS不可用2) .處理措施? 查看3031告警的附加信息，確定相關的故障小區，使

20、用指令:ZAHO? 如果同一 PCU下的若干小區同時出現3031告警,則有可能是該PCU出現故障, 需要立即向網絡運行支撐中心通報情況，及時處理(一般需要對相應BCSU進行 倒換)? 如果同PCU下只是個別小區出現該告警，則需要查看該小區的性能指標，看是否 斷站或者基站硬件故障? 如果不是以上原因，則建議為相關小區重新分配另外的 NSEI.3) .處理后監控處理過后,需要查看下個時段的相關 OMC KPI是否正常BMCC PROJECT OPTIMIZATION19/05/2010 1? 上、下行GPRS有效數據量(KB)? 上、下行EGPRS有效數據量(KB)?分組信道指派成功率? ( E)

21、GPRS上、下行TBF數7 Gb負荷過高監控處理7.1故障現象統計數據中的Gb負荷過高,超過規定的門限.下表為NOKIA Gb鏈路的利用率門限GB帶寬利用率門限GPRS64K30%128K45%192K55%256K70%128K25%EGPRS256K61%384K68%512K68%640K70%768K75%896K85%1024K90%7.2處理措施對于負荷高的Gb Link，根據情況依次采用以下方法進行處理：? 同一 PCU的負荷判定目前，在Nokia設備上，一個PCU同時使用兩條Gb Link，分別對應兩條BearChannel。但現網條件下，這兩條 Gb Link無法實現下行的自

22、動負荷分擔，因此對于單個PCU來說，要用其兩條 Gb Link的Max值來代表整個PCU的Gb負荷。? 同一 BSC的Gb負荷均衡對于同一個BSC來說，其PCU的Gb負荷主要是由該PCU所帶小區的數據流量情況決定的。因此，如果發現某條 Gb的負荷越過了警戒線，則采取以下步驟處理：BMCC PROJECT OPTIMIZATION19/05/2010設負荷超過警戒線的 Gb對應的PCU為NSEI-1，與其同BSC的其他PCU為NSEI-N，N=2,3,4 7.3查看統計處理過后，要查看下個時段的相關 OMC KPI是否正常：? Max sen t load %(frl_7)? Max rec l

23、oad %(frl_8)8 PCU的容量配置監控與調整1) .故障現象PCU的PDCH或小區配置數量過高2) .處理流程圖BMCC PROJECT OPTIMIZATION19/05/2010Networks否是是否定期監控PCU級資源配置提取每個PCU所帶小區 數,PDCH 數,GTRX 數PCU下小區數是否超過64 PCU 下 PDCH否超過18是與其他PCU均衡是否可以與同一 BSC其他PCU均衡4提岀擴容建議3) .處理后監控處理過后，要查看下個時段的相關 OMC KPI是否正常：? Sum of Dedicated TSL/NSEI? Sum of Default TSL/NSEI? Sum of EDAP TSL/NSEI? Total tsl/NSEI9 SGSN相關指標監控1) SG