GPRS日常监控及处理流程

《GPRS日常监控及处理流程》由会员分享，可在线阅读，更多相关《GPRS日常监控及处理流程（15页珍藏版）》请在装配图网上搜索。

1、 （E）GPRS日常监控处理2010-5-19目录（E）GPRS日常监控处理1目录21.GPRS SLEEPING CELLS监控及处理31.1GPRS Sleeping Cell 监控及处理流程图31.2GPRS Sleeping Cell 监控31.3GPRS Sleeping Cell 处理41.4GPRS Sleeping Cell处理后的监控42.EGPRS SLEEPING CELL监控及处理42.1EGPRS Sleeping Cell 监控及处理流程图42.2EGPRS Sleeping Cell监控52.3EGPRS Sleeping Cell处理62.4EGPRS Slee

2、ping Cell处理后的监控63.3273告警监控及处理63.13273告警监控及处理流程图73.23273告警监控73.33273告警处理83.43273告警处理后的监控84.7725告警（BTS级告警）监控及处理84.17725告警监控84.27725告警处理94.37725告警处理后的监控95.故障PCU95.1故障PCU监控95.2故障PCU处理105.3故障PCU处理后监控106其他BSC级告警的监控与处理106.13019/3020告警处理106.23031告警处理117GB负荷过高监控处理128PCU的容量配置监控与调整139SGSN相关指标监控1410各类性能监控周期、处理时

3、限与记录要求1510.1监控周期与处理时限1510.2记录要求161. 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上来看，上/下行有效数据量、上/下行

4、平均每时隙TBF数等均不正常（为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

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

6、.处理后的查看指标如下: 上、下行GPRS有效数据量(KB) 分组信道指派成功率 Packet Immediate Assignment Message数 上、下行TBF建立成功率 上、下行TBF数2. EGPRS Sleeping Cell监控及处理2.1 EGPRS Sleeping Cell 监控及处理流程图2.2 EGPRS Sleeping Cell监控 每半小时查看一次EGPRS小区的各项指标,从而发现EGPRS Sleeping Cell. EGPRS Sleeping Cell 故障现象如下: 问题小区的GPRS统计正常,但是EGPRS流量突然大幅度降低； 从OMC/KPI上来

7、看,没有或者很少的EGPRS UL/DL TBF Number、EGPRS UL TBF Number与DL TBF Number差别很大、EGPRS DL Payload为0； Expired LLC frames (%) DL过高 UL/DL multi-slot allocation blocking(%)过高 有用户投诉EGPRS不可用2.3 EGPRS Sleeping Cell处理监控出现EGPRS Sleeping Cell之后, 排查该类小区是否无用户、是否EDGE新规划基站.对于EGPRS Sleeping cell,如果发现其同时存在7725告警,则需参照后面处理7725的

8、方法进行,如果不存在7725告警,一般依次进行如下处理步骤:a) 检查EGPRS参数设置是否正常 EGENA是否打开； GTRX是否设置正确； EDAP是否绑定；b) 重启EGENA(需要Lock BTS) ；c) 调换问题小区的NSEI； EGPRS Sleeping cell的处理,主要有以上几种方法.如果以上各步骤均无效,则有三种应对措施:1.首先建议关闭EGENA.,保证EDGE用户可以使用GPRS上网.2及时通知运维倒换PCU,即切换BCSU；3.通知相关人员(如基站工程师等)进行处理.2.4 EGPRS Sleeping Cell处理后的监控EGPRS Sleeping Cell每

9、一个处理步骤过后,均需要查看之后半小时的相关指标,如果指标不正常,则需要进行下一步.处理后的查看指标如下: 上、下行EGPRS有效数据量(KB) EGPRS 上、下行 TBF数 UL/DL multi-slot allocation blocking(%) Expired LLC frames (%) DL Packet Immediate Assignment Message数 上、下行TBF建立成功率3. 3273告警监控及处理3.1 3273告警监控及处理流程图 3.2 3273告警监控3273告警(EGPRS TERRITORY FAILURE)是PCU的容量预警,一般是由于PCU负荷

10、过高导致(但也有个别PCU负荷较低而出现该告警的情况) 。每半小时提取一次3273告警故障现象如下: BSC出现3273告警(E)GPRS TERRITORY FAILURE) ； 相关BTS的可用EGPRS信道数低于CDEF参数定义的默认信道数。3.3 3273告警处理监控查出发生告警的BSC,进入到该BSC,查看3273告警的附加信息,确定相关故障小区(使用指令:ZAHO). 如果同一PCU下某1,2个小区出现3273告警,一般是由于该PCU的负荷过高导致,解决措施就是将出告警的小区挪至负荷较低的PCU. 如果同一PCU下多个小区同时出现3273告警,且将其下部分小区调至其他NSEI下之后

11、,仍旧出现多个告警,则很有可能是该PCU出现故障,需要立即向网络运行支持中心集中监控中心(小号:7312173126)通报情况,及时处理 如果以上方法均不奏效,或者各个PCU负荷都较高,则有两种应对措施:1.关闭EGENA,2.降低GPRS/EGPRS的PDCH信道数.此外,高话务下话音业务挤占GPRS信道也会导致可用EGPRS信道数低于CDED参数定义的默认信道数,产生3273告警。解决措施: 均衡话务，适时提/催扩容建议。3.4 3273告警处理后的监控3273告警处理过后,要查看下个时段的相关OMC KPI是否正常: 上、下行GPRS有效数据量(KB) 分组信道指派成功率 GPRS边界升

12、级拒绝CS话务过高 GPRS边界升级拒绝BTS信道受限 GPRS边界升级拒绝PCU信道受限 上、下行EGPRS有效数据量(KB) （E）GPRS 上、下行TBF数4. 7725告警（BTS级告警）监控及处理4.1 7725告警监控7725告警的监控需要与GPRS Sleeping Cell和EGPRS Sleeping Cell相结合.监控出指标异常小区后,看该小区是否有7725告警(使用指令:ZEOL).7725告警: TRAFFIC CHANNEL ACTIVATION FAILURE,附加信息为”02”,表示是PDCH信道激活失败.4.2 7725告警处理如果故障小区集中在某个PCU下,

13、则说明是该PCU出现问题,需要立即联系网络运行支撑中心倒换相应PCU.如果故障小区分布于不同的PCU,则依次进行以下处理方法: 针对GPRS小区(或master BTS)a). 重启GENAb). 调换故障小区的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

14、cell处理方法类似.如果以上各步骤均无效,则通知相关人员(如基站工程师等)进行处理.4.3 7725告警处理后的监控 7725告警处理过后,要查看下个时段的相关OMC KPI是否正常 上、下行GPRS有效数据量(KB) 分组信道指派成功率 上、下行EGPRS有效数据量(KB) （E）GPRS 上、下行 TBF数 上、下行TBF建立成功率5. 故障PCU5.1 故障PCU监控对于故障PCU的监控，主要是通过网管统计中：表NPMDB_V_P_数据业务_严重问题NOKIA的数据来进行。该表将没有PS域数据统计的PCU列出。我们查看各个PCU及其所挂小区的现网状态，从而更进一步将PCU的故障问题细化

15、，大致分为如下两种情况：a) PCU下面小区无PS域数据统计，且的确存在故障的情况。如：PCU的两条GB Bear均为BL_SY的状态，且有3030，3031告警；PCU所挂小区均发生3273告警；等等。b) PCU下面小区无PS域数据统计，但不确定是否存在故障的情况。这种情况下，PCU不存在任何告警，PCU对应的GB Bear的状态以及PCU所挂小区的状态均正常。因为没有PS域数据统计，所以无法通过指标来实现对小区或者PCU的监控。只能通过现场测试或者投诉情况，来判定。5.2 故障PCU处理a). 对故障PCU的处理，一般都需要上报网运来执行。5.3 故障PCU处理后监控处理过后，要查看各小

16、区相关OMC KPI是否正常 ： 上、下行GPRS有效数据量(KB) 分组信道指派成功率 上、下行EGPRS有效数据量(KB) （E）GPRS 上、下行TBF数6 其他BSC级告警的监控与处理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

17、 告警发生的可能原因是Gb链路出现故障,PCU硬件出现问题,BCSU重启后,PCU没有恢复正常工作或者是SGSN中的相关单元出现故障,因此需要立即联系网络运行支撑中心通报情况,了解处理进度. 在该PCU故障恢复之前,需要重启指定NSEI,将其下的小区分配到其他的PCU下工作,待故障解决后再行恢复.3). 处理后监控处理过后，要查看下个时段的相关OMC KPI是否正常 ： 上、下行GPRS有效数据量(KB) 分组信道指派成功率 上、下行TBF数 上、下行EGPRS有效数据量(KB) EGPRS 上、下行TBF数6.2 3031告警处理1). 故障现象 BSC出现3031告警（BSSGP VIRT

18、UAL CONNECTION RESET PROCEDURE FAILED） 相关小区的GPRS不可用2). 处理措施 查看3031告警的附加信息,确定相关的故障小区,使用指令:ZAHO 如果同一PCU下的若干小区同时出现3031告警,则有可能是该PCU出现故障,需要立即向网络运行支撑中心通报情况,及时处理(一般需要对相应BCSU进行倒换) 如果同PCU下只是个别小区出现该告警,则需要查看该小区的性能指标,看是否断站或者基站硬件故障 如果不是以上原因,则建议为相关小区重新分配另外的NSEI.3). 处理后监控处理过后,需要查看下个时段的相关OMC KPI是否正常 上、下行GPRS有效数据量(K

19、B) 上、下行EGPRS有效数据量(KB) 分组信道指派成功率 （E）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，分别对应

20、两条Bear Channel。但现网条件下，这两条Gb Link无法实现下行的自动负荷分担，因此对于单个PCU来说，要用其两条Gb Link的Max值来代表整个PCU的Gb负荷。 同一BSC的Gb负荷均衡 对于同一个BSC来说，其PCU的Gb负荷主要是由该PCU所带小区的数据流量情况决定的。因此，如果发现某条Gb的负荷越过了警戒线，则采取以下步骤处理：设负荷超过警戒线的Gb对应的PCU为NSEI-1，与其同BSC的其他PCU为NSEI-N，N=2,3,4提出Gb扩容建议，与运维中心协调解决（数据分析要准确到位）NSEI-N的Gb负荷20% ?否跟踪监控Gb负荷情况NSEI-1的Gb负荷过载计算

21、最近一周各个小区的下行数据流量MAX值将NSEI-1所带的高GPRS数据量小区与NSEI-N所带的低GPRS数据量小区互换是7.3 查看统计处理过后,要查看下个时段的相关OMC KPI是否正常 ： Max sent load %(frl_7) Max rec load %(frl_8)8 PCU的容量配置监控与调整1). 故障现象PCU的PDCH或小区配置数量过高2). 处理流程图 否 是 是 是 否 否 提取每个PCU所带小区数,PDCH数,GTRX数 PCU下小区数是否超过64 PCU下PDCH数是否超过180 是否可以与同一BSC下其他PCU均衡 与其他PCU均衡 提出扩容建议 定期监控

22、PCU级资源配置 3). 处理后监控处理过后，要查看下个时段的相关OMC KPI是否正常 ： Sum of Dedicated TSL/NSEI Sum of Default TSL/NSEI Sum of EDAP TSL/NSEI Total tsl/NSEI9 SGSN相关指标监控1) SGSN各PAPU的相关指标 ATTACH成功率 PDP激活成功率 RAU成功率对于以上三类SGSN的相关指标，一般情况下，在工作时间8:30-15:30之间暂时设置参考门限如下：ATTACH成功率：70%；PDP激活成功率：90%；RAU成功率：80%。 一旦PAPU的指标低于以上各门限，则可能出现问题

23、。但因各PAPU间指标相差较大，具体情况应具体分析。例如：某个PAPU的3项指标中任何一项发生明显降低，也可能是PAPU出现问题。2) SGSN指标出现问题的处理 监控到以上3项指标发生异常，则需要立即通知相关人员（如网运中心等），进行处理。3) 处理后监控观察各PAPU在处理后各时段的指标是否恢复至正常水平。10 各类性能监控周期、处理时限与记录要求10.1 监控周期与处理时限编号监控内容监控周期处理时限1GPRS SLEEPING CELLS1次/半小时3小时（日常）2EGPRS SLEEPING CELL1次/半小时3小时（日常）33273告警1次/半小时3小时（日常）47725告警（BTS级告警）1次/半小时3小时（日常）5故障PCU1次/半小时24小时（日常）7其他BSC级告警的监控与处理1次/天半小时8GB负荷过高监控处理1次/周（日常）24小时（日常）9PCU的容量配置监控与调整1次/周（日常）24小时（日常）10SGSN相关指标监控1次/1小时（日常）10.2 记录要求各项性能监控和处理过程的记录要求包括以下内容： 问题小区CI、BSC、SEG-ID 故障内容 故障发现时间 处理过程（包括各项操作的时间点） 解决时间 处理人