EGPRS日常监控及处理流程

1、(E) GPRSH常监控处理2021-5-19目录1. GPRS Sleeping Cells 监控及处理1.1 GPRS Sleeping Cell 监控及处理流程图1.2 GPRS Sleeping Cell 监控每半小时查看一次 GPRS小区的各项指标,从而发现GPRS Sleeping Cell.GPRS Sleeping Cell故障现象如下：很多的 PACKET IMMED ASS REJ MSG 和很少的 PACKET IMMED ASS ACK MSG 现象,即分组信道指派成功率低.很高的上/下行TBF建立失败率从OMC KPI上来看,上/下行有效数据量、上/下行平均每时隙TB

2、F数等均不正常为 0或较之前降低很多注：PACKET IMMED ASS REJ MSG 和 PACKET IMMED ASS ACK MSG 两个 counter 在 表Packet Control Unit Measurement 中,可以直接查看这两个 counter值的变化从而判断出GPRS Sleeping Cell并做出相应的处理.1.3 GPRS Sleeping Cell 处理监控出现GPRS Sleeping cell之后,首先保证这个cell有GTRX,并且GENA已经翻开. 对于GPRS Sleeping cell,如果发现其同时存在7725告警,那么需参照后面处理772

3、5的方法 进行,如果不存在7725告警,一般依次进行如下处理步骤：a） .重启GPRS功能开关即GENA;b） .重启GTRXTRX 上的GPRS开关；c） .调换 GPRS Sleeping cell 的 NSEI ；GPRS Sleeping cell 的处理,主要有以上三种方法,依次进行.如果以上各步骤均无效, 那么有两种应对举措：1.及时通知运维倒换PCU,即切换BCSU; 2.通知相关人员如基站工 程师等进行处理.1.4 GPRS Sleeping Cell 处理后的监控GPRS Sleeping Cell每一个处理步骤过后,均需要查看之后半小时的相关指标,如果指标不 正常,那么需要

4、进行下一步.处理后的查看指标如下：上、下行GPRS有效数据量KB分组信道指派成功率Packet Immediate Assignment Message上、下行TBF建立成功率上、下行TBF数2. EGPRS Sleeping Cell监控及处理每半小时查看一次 EGPRS小区的各项指标,从而发现EGPRS Sleeping Cell.EGPRS Sleeping Cell故障现象如下:问题小区的GPRS统计正常,但是EGPRS流量忽然大幅度降低；从 OMC/KPI 上来看,没有或者彳艮少的 EGPRS UL/DL TBF Number、 EGPRS UL TBFNumber 与 DL TBF

5、 Number 差另肝艮大、EGPRS DL Payload为 0;Expired LLC frames (%) DL 过高UL/DL multi-slot allocation blocking(%) 过高有用户投诉EGPRS不可用2.1 EGPRS Sleeping Cell 处理监控出现EGPRS Sleeping Cell之后,排查该类小区是否无用户、是否 EDGE新规划基站. 对于EGPRS Sleeping cell,如果发现其同时存在7725告警,那么需参照后面处理7725的方 法进行,如果不存在7725告警,一般依次进行如下处理步骤：a检查EGPRS参数设置是否正常EGENA是

6、否翻开；GTRX是否设置正确；EDAP是否绑定；b 重启 EGENA需要 Lock BTS;c调换问题小区的NSEI;EGPRS Sleeping cel的处理,主要有以上几种方法.如果以上各步骤均无效,那么有三种应对措 施:1.首先建议关闭EGENA.,保证EDGE用户可以使用GPRS上网.2及时通知运维倒换PCU, 即切换BCSU; 3.通知相关人员如基站工程师等进行处理.2.2 EGPRS Sleeping Cell 处理后的监控EGPRS Sleeping Cell每一个处理步骤过后,均需要查看之后半小时的相关指标,如果指标 不正常,那么需要进行下一步.处理后的查看指标如下：上、下行E

7、GPRS有效数据量KBEGPRS上、下行TBF数UL/DL multi-slot allocation blocking%Expired LLC frames % DLPacket Immediate Assignment Messaged上、下行TBF建立成功率3. 3273告警监控及处理3.1 3273告警监控3273告警(EGPRS TERRITORY FAILURE) 是PCU的容量预警,一般是由于PCU负荷过高导致(但也有个别PCU负荷较低而出现该告警的情况).每半小时提取一次3273告警故障现象如下：BSC 出现 3273 告警(E)GPRS TERRITORY FAILURE)；

8、相关BTS的可用EGPRS信道数低于CDEF参数定义的默认信道数.3.2 3273告警处理监控查出发生告警的BSC,进入到该BSC,查看3273告警的附加信息,确定相关故障小区(使 用指令:ZAHO).如果同一 PCU下某1,2个小区出现3273告警,一般是由于该PCU的负荷过高导致,解 决举措就是将出告警的小区挪至负荷较低的PCU.如果同一 PCU下多个小区同时出现3273告警,且将其下局部小区调至其他 NSEI下之 后,仍旧出现多个告警,那么很有可能是该PCU出现故障,需要立即向网络运行支持中央集 中监控中央小号:7312173126通报情况,及时处理如果以上方法均不奏效,或者各个PCU负

9、荷都较高,那么有两种应对举措：1.关闭EGENA,2. 降彳氐GPRS/EGPRS的PDCH信道数.止匕外,高话务下话音业务挤占GPRS信道也会导致可用EGPRS信道数低于CDED 参数定义的默认信道数,产生3273告警.解决举措：均衡话务,适时提/催扩容建议.3.3 3273告警处理后的监控3273告警处理过后,要查看下个时段的相关 OMC KPI是否正常：上、下行GPRS有效数据量KB分组信道指派成功率GPRS边界升级拒绝CS话务过高GPRS边界升级拒绝BTS信道受限GPRS边界升级拒绝PCU信道受限上、下行EGPRS有效数据量KBE GPRS上、下行TBF数4. 7725告警BTS级告警

10、监控及处理4.1 7725告警监控7725告警的监才S需要与 GPRS Sleeping Cell和EGPRS Sleeping Cell相结合.监控出指 标异常小区后,看该小区是否有7725告警使用指令:ZEOL.7725告警：TRAFFICCHANNEL ACTIVATION FAILURE, 附力口信息为“02,表示是PDCH信道激活失败.4.2 7725告警处理如果故障小区集中在某个 PCU下,那么说明是该PCU出现问题,需要立即联系网络运行支撑 中央倒换相应PCU.如果故障小区分布于不同的 PCU,那么依次进行以下处理方法：针对GPRS小区或master BTSa） .重启 GENA

11、b） .调换故障小区的NSEIc） .重启出现告警的BTS和TRX针对EGPRS小区(或slave BTS)a).重启 EGENA(需要 Lock BTS)b),调换故障小区的NSEIc).重启出现告警的BTS和TRXd),关闭slave BTS的跳频(针对BSC的CD3升级所导致的EDGE Sleeping Cell) 7725告警是一局部sleeping cell会出现的现象,与sleeping cell处理方法类似,如果以 上各步骤均无效,那么通知相关人员(如基站工程师等)进行处理.4.3 7725告警处理后的监控7725告警处理过后,要查看下个时段的相关 OMC KPI是否正常上、下行

12、GPRS有效数据量(KB)分组信道指派成功率上、下行EGPRS有效数据量(KB)(E) GPRS上、下行TBF数上、下行TBF建立成功率5.故障PCU5.1 故障PCU监控对于故障PCU的监控,主要是通过网管统计中：表?NPMDB V P数据业务 严重问题 NOKIA »的数据来进行.该表将没有 PS域数据统计的PCU列出.我们查看各个PCU及其 所挂小区的现网状态,从而更进一步将 PCU的故障问题细化,大致分为如下两种情况：a) PCU下面小区无PS域数据统计,且确实存在故障的情况.如： PCU的两条GB Bear均为BL_SY的状态,且有3030, 3031告警；PCU所挂小区均

13、发生3273告 警；等等.b) PCU下面小区无PS域数据统计,但不确定是否存在故障的情况.这种情况下, 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级告警的监

14、控与处理6.1 3019/3020告警处理1) .故障现象BSC出现3019或者3020告警：3019 NETWORK SERVICE ENTITY UNAVAILABLE3020 NETWORK SERVICE VIRTUAL CONNECTION UNAVAILABLE该PCU覆盖区域内的GPRS网络不可用.2) .处理举措查看NSEI的NSVC状态查看BSC告警情况,使用指令：ZAHO、ZAHP告警发生的可能原因是 Gb链路出现故障,PCU硬件出现问题,BCSU重启后,PCU 没有恢复正常工作或者是 SGSN中的相关单元出现故障,因此需要立即联系网络 运行支撑中央通报情况,了解处理进度.

15、在该PCU故障恢复之前,需要重启指定NSEI,将其下的小区分配到其他的 PCU 下工作,待故障解决后再行恢复.3) .处理后监控处理过后,要查看下个时段的相关 OMC KPI是否正常：上、下行GPRS有效数据量(KB)分组信道指派成功率上、下行TBF数上、下行EGPRS有效数据量(KB)EGPRS上、下行TBF数6.2 3031告警处理1) .故障现象BSC 出现 3031 告警(BSSGP VIRTUAL CONNECTION RESET PROCEDURE FAILED )相关小区的GPRS不可用2) .处理举措查看3031告警的附加信息,确定相关的故障小区,使用指令:ZAHO如果同一 P

16、CU下的假设干小区同时出现3031告警,那么有可能是该PCU出现故障, 需要立即向网络运行支撑中央通报情况,及时处理(一般需要对相应BCSU进行 倒换)如果同PCU下只是个别小区出现该告警,那么需要查看该小区的性能指标,看是否 断站或者基站硬件故障如果不是以上原因,那么建议为相关小区重新分配另外的 NSEI.3) .处理后监控处理过后,需要查看下个时段的相关 OMC KPI是否正常上、下行GPRS有效数据量(KB)上、下行EGPRS有效数据量(KB)分组信道指派成功率(E) GPRS上、下行TBF数7 Gb负荷过高监控处理7.1 故障现象统计数据中的Gb负荷过高,超过规定的门限.下表为NOKI

17、A Gb链路的利用率门限：6珊宽利用率门限GPRS64K30%128K45%192K55%256K70%128K25%EGPRS256K61%384K68%512K68%640K70%768K75%896K85%1024K90%7.2 处理举措对于负荷高的Gb Link,根据情况依次采用以下方法进行处理：同一 PCU的负荷判定目前,在Nokia设备上,一个PCU同时使用两条Gb Link,分别对应两条Bear Channel.但现网条件下,这两条 Gb Link无法实现下行的自动负荷分担,因此对于单个 PCU来说,要用其两条 Gb Link的Max值来代表整个PCU的Gb负荷.同一 BSC的G

18、b负荷均衡对于同一个BSC来说,其PCU的Gb负荷主要是由该PCU所带小区的数据流量情 况决定的.因此,如果发现某条 Gb的负荷越过了警戒线,那么采取以下步骤处理：设负荷超过警戒线的 Gb对应的PCU为NSEI-1 ,与其同BSC的其他PCU为NSEI- N, N=2,3,4 7.3 查看统计处理过后,要查看下个时段的相关 OMC KPI是否正常：Max sent load %(frl_7)Max rec load %(frl_8)8 PCU的容量配置监控与调整1) .故障现象PCU的PDCH或小区配置数量过高2) .处理流程图3) .处理后监控处理过后,要查看下个时段的相关 OMC KPI是否正常：Sum of Dedicated TSL/NSEISum of Default TSL/NSEISum of EDAP TSL/NSEITotal tsl/NSEI9 SGSN相关指标监控1） SGSK PAPU勺相关指标ATTAC或功率PDP收活成功率RAlM功率对于