GPRS日常监控及处理流程.docx
《GPRS日常监控及处理流程.docx》由会员分享,可在线阅读,更多相关《GPRS日常监控及处理流程.docx(17页珍藏版)》请在冰豆网上搜索。
GPRS日常监控及处理流程
GPRS日常监控及处理流程
(E)GPRS日常监控处理
2010-5-19
名目
GPRSSleepingCells监控及处理
GPRSSleepingCell监控及处理流程图
GPRSSleepingCell监控
每半小时查看一次GPRS小区的各项指标,从而发觉GPRSSleepingCell.
GPRSSleepingCell故障现象如下:
专门多的PACKETIMMEDASSREJMSG和专门少的PACKETIMMEDASSACKMSG现象,即分组信道指派成功率低。
专门高的上/下行TBF建立失败率
从OMCKPI上来看,上/下行有效数据量、上/下行平均每时隙TBF数等均不正常(为0或较之前降低专门多)
注:
PACKETIMMEDASSREJMSG和PACKETIMMEDASSACKMSG两个counter在表PacketControlUnitMeasurement中,能够直截了当查看这两个counter值的变化从而判定出GPRSSleepingCell并做出相应的处理。
GPRSSleepingCell处理
监控显现GPRSSleepingcell之后,第一保证那个cell有GTRX,同时GENA差不多打开.
关于GPRSSleepingcell,如果发觉其同时存在7725告警,则需参照后面处理7725的方法进行,如果不存在7725告警,一样依次进行如下处理步骤:
重启GPRS功能开关(即GENA);
重启GTRX(TRX上的GPRS开关);
调换GPRSSleepingcell的NSEI;
GPRSSleepingcell的处理,要紧有以上三种方法,依次进行.如果以上各步骤均无效,则有两种应对措施:
1.及时通知运维倒换PCU,即切换BCSU;2.通知有关人员(如基站工程师等)进行处理.
GPRSSleepingCell处理后的监控
GPRSSleepingCell每一个处理步骤过后,均需要查看之后半小时的有关指标,如果指标不正常,则需要进行下一步.处理后的查看指标如下:
上、下行GPRS有效数据量(KB)
分组信道指派成功率
PacketImmediateAssignmentMessage数
上、下行TBF建立成功率
上、下行TBF数
EGPRSSleepingCell监控及处理
EGPRSSleepingCell监控及处理流程图
EGPRSSleepingCell监控
每半小时查看一次EGPRS小区的各项指标,从而发觉EGPRSSleepingCell.
EGPRSSleepingCell故障现象如下:
咨询题小区的GPRS统计正常,然而EGPRS流量突然大幅度降低;
从OMC/KPI上来看,没有或者专门少的EGPRSUL/DLTBFNumber、EGPRSULTBFNumber与DLTBFNumber差别专门大、EGPRSDLPayload为0;
ExpiredLLCframes(%)DL过高
UL/DLmulti-slotallocationblocking(%)过高
有用户投诉EGPRS不可用
EGPRSSleepingCell处理
监控显现EGPRSSleepingCell之后,排查该类小区是否无用户、是否EDGE新规划基站.
关于EGPRSSleepingcell,如果发觉其同时存在7725告警,则需参照后面处理7725的方法进行,如果不存在7725告警,一样依次进行如下处理步骤:
检查EGPRS参数设置是否正常
EGENA是否打开;
GTRX是否设置正确;
EDAP是否绑定;
重启EGENA(需要LockBTS);
调换咨询题小区的NSEI;
EGPRSSleepingcell的处理,要紧有以上几种方法.如果以上各步骤均无效,则有三种应对措施:
1.第一建议关闭EGENA.,保证EDGE用户能够使用GPRS上网.2及时通知运维倒换PCU,即切换BCSU;3.通知有关人员(如基站工程师等)进行处理.
EGPRSSleepingCell处理后的监控
EGPRSSleepingCell每一个处理步骤过后,均需要查看之后半小时的有关指标,如果指标不正常,则需要进行下一步.处理后的查看指标如下:
上、下行EGPRS有效数据量(KB)
EGPRS上、下行TBF数
UL/DLmulti-slotallocationblocking(%)
ExpiredLLCframes(%)DL
PacketImmediateAssignmentMessage数
上、下行TBF建立成功率
3273告警监控及处理
3273告警监控及处理流程图
3273告警监控
3273告警(EGPRSTERRITORYFAILURE)是PCU的容量预警,一样是由于PCU负荷过高导致(但也有个别PCU负荷较低而显现该告警的情形)。
每半小时提取一次3273告警
故障现象如下:
BSC显现3273告警((E)GPRSTERRITORYFAILURE);
有关BTS的可用EGPRS信道数低于CDEF参数定义的默认信道数。
3273告警处理
监控查动身生告警的BSC,进入到该BSC,查看3273告警的附加信息,确定有关故障小区(使用指令:
ZAHO).
如果同一PCU下某1,2个小区显现3273告警,一样是由于该PCU的负荷过高导致,解决措施确实是将出告警的小区挪至负荷较低的PCU.
如果同一PCU下多个小区同时显现3273告警,且将其下部分小区调至其他NSEI下之后,仍旧显现多个告警,则专门有可能是该PCU显现故障,需要赶忙向网络运行支持中心集中监控中心(小号:
73121~73126)通报情形,及时处理
如果以上方法均不奏效,或者各个PCU负荷都较高,则有两种应对措施:
1.关闭EGENA,2.降低GPRS/EGPRS的PDCH信道数.
此外,高话务下话音业务挤占GPRS信道也会导致可用EGPRS信道数低于CDED参数定义的默认信道数,产生3273告警。
解决措施:
均衡话务,适时提/催扩容建议。
3273告警处理后的监控
3273告警处理过后,要查看下个时段的有关OMCKPI是否正常:
上、下行GPRS有效数据量(KB)
分组信道指派成功率
GPRS边界升级拒绝CS话务过高
GPRS边界升级拒绝BTS信道受限
GPRS边界升级拒绝PCU信道受限
上、下行EGPRS有效数据量(KB)
(E)GPRS上、下行TBF数
7725告警(BTS级告警)监控及处理
7725告警监控
7725告警的监控需要与GPRSSleepingCell和EGPRSSleepingCell相结合.监控出指标专门小区后,看该小区是否有7725告警(使用指令:
ZEOL).7725告警:
TRAFFICCHANNELACTIVATIONFAILURE,附加信息为”02”,表示是PDCH信道激活失败.
7725告警处理
如果故障小区集中在某个PCU下,则讲明是该PCU显现咨询题,需要赶忙联系网络运行支撑中心倒换相应PCU.
如果故障小区分布于不同的PCU,则依次进行以下处理方法:
针对GPRS小区(或masterBTS)
重启GENA
调换故障小区的NSEI
重启显现告警的BTS和TRX
针对EGPRS小区(或slaveBTS)
重启EGENA(需要LockBTS)
调换故障小区的NSEI
重启显现告警的BTS和TRX
关闭slaveBTS的跳频(针对BSC的CD3升级所导致的EDGESleepingCell)
7725告警是一部分sleepingcell会显现的现象,与sleepingcell处理方法类似.如果以上各步骤均无效,则通知有关人员(如基站工程师等)进行处理.
7725告警处理后的监控
7725告警处理过后,要查看下个时段的有关OMCKPI是否正常
上、下行GPRS有效数据量(KB)
分组信道指派成功率
上、下行EGPRS有效数据量(KB)
(E)GPRS上、下行TBF数
上、下行TBF建立成功率
故障PCU
故障PCU监控
关于故障PCU的监控,要紧是通过网管统计中:
表《NPMDB_V_P_数据业务_严峻咨询题NOKIA》的数据来进行。
该表将没有PS域数据统计的PCU列出。
我们查看各个PCU及其所挂小区的现网状态,从而更进一步将PCU的故障咨询题细化,大致分为如下两种情形:
PCU下面小区无PS域数据统计,且的确存在故障的情形。
如:
PCU的两条GBBear均为BL_SY的状态,且有3030,3031告警;PCU所挂小区均发生3273告警;等等。
PCU下面小区无PS域数据统计,但不确定是否存在故障的情形。
这种情形下,PCU不存在任何告警,PCU对应的GBBear的状态以及PCU所挂小区的状态均正常。
因为没有PS域数据统计,因此无法通过指标来实现对小区或者PCU的监控。
只能通过现场测试或者投诉情形,来判定。
故障PCU处理
对故障PCU的处理,一样都需要上报网运来执行。
故障PCU处理后监控
处理过后,要查看各小区有关OMCKPI是否正常:
上、下行GPRS有效数据量(KB)
分组信道指派成功率
上、下行EGPRS有效数据量(KB)
(E)GPRS上、下行TBF数
其他BSC级告警的监控与处理
3019/3020告警处理
故障现象
BSC显现3019或者3020告警:
3019NETWORKSERVICEENTITYUNAVAILABLE
3020NETWORKSERVICEVIRTUALCONNECTIONUNAVAILABLE
该PCU覆盖区域内的GPRS网络不可用。
处理措施
查看NSEI的NSVC状态
查看BSC告警情形,使用指令:
ZAHO、ZAHP
告警发生的可能缘故是Gb链路显现故障,PCU硬件显现咨询题,BCSU重启后,PCU没有复原正常工作或者是SGSN中的有关单元显现故障,因此需要赶忙联系网络运行支撑中心通报情形,了解处理进度.
在该PCU故障复原之前,需要重启指定NSEI,将其下的小区分配到其他的PCU下工作,待故障解决后再行复原.
处理后监控
处理过后,要查看下个时段的有关OMCKPI是否正常:
上、下行GPRS有效数据量(KB)
分组信道指派成功率
上、下行TBF数
上、下行EGPRS有效数据量(KB)
EGPRS上、下行TBF数
3031告警处理
故障现象
BSC显现3031告警(BSSGPVIRTUALCONNECTIONRESETPROCEDUREFAILED)
有关小区的GPRS不可用
处理措施
查看3031告警的附加信息,确定有关的故障小区,使用指令:
ZAHO
如果同一PCU下的若干小区同时显现3031告警,则有可能是该PCU显现故障,需要赶忙向网络运行支撑中心通报情形,及时处理(一样需要对相应BCSU进行倒换)
如果同PCU下只是个别小区显现该告警,则需要查看该小区的性能指标,看是否断站或者基站硬件故障
如果不是以上缘故,则建议为有关小区重新分配另外的NSEI.
处理后监控
处理过后,需要查看下个时段的有关OMCKPI是否正常
上、下行GPRS有效数据量(KB)
上、下行EGPRS有效数据量(KB)
分组信道指派成功率
(E)GPRS上、下行TBF数
Gb负荷过高监控处理
故障现象
统计数据中的Gb负荷过高,超过规定的门限.下表为NOKIAGb链路的利用率门限:
GB带宽
利用率门限
GPRS
64K
30%
128K
45%
192K
55%
256K
70%
128K
25%
EGPRS
256K
61%
384K
68%
512K
68%
640K
70%
768K
75%
896K
85%
1024K
90%
处理措施
关于负荷高的GbLink,按照情形依次采纳以下方法进行处理:
同一PCU的负荷判定
目前,在Nokia设备上,一个PCU同时使用两条GbLink,分别对应两条BearChannel。
但现网条件下,这两条GbLink无法实现下行的自动负荷分担,因此关于单个PCU来讲,要用其两条GbLink的Max值来代表整个PCU的Gb负荷。
同一BSC的Gb负荷均衡
关于同一个BSC来讲,其PCU的Gb负荷要紧是由该PCU所带小区的数据流量情形决定的。
因此,如果发觉某条Gb的负荷越过了戒备线,则采取以下步骤处理:
设负荷超过戒备线的Gb对应的PCU为NSEI-1,与其同BSC的其他PCU为NSEI-N,N=2,3,4…
查看统计
处理过后,要查看下个时段的有关OMCKPI是否正常:
Maxsentload%(frl_7)
Maxrecload%(frl_8)
PCU的容量配置监控与调整
故障现象
PCU的PDCH或小区配置数量过高
处理流程图
否
是
是
是
否
否
提取每个PCU所带小区数,PDCH数,GTRX数
PCU下小区数是否超过64
PCU下PDCH数是否超过180
是否能够与同一BSC下
其他PCU均衡
与其他PCU均衡
提出扩容建议
定期监控PCU级资源配置
处理后监控
处理过后,要查看下个时段的有关OMCKPI是否正常:
SumofDedicatedTSL/NSEI
SumofDefaultTSL/NSEI
SumofEDAPTSL/NSEI
Totaltsl/NSEI
SGSN有关指标监控
SGSN各PAPU的有关指标
ATTACH成功率
PDP激活成功率
RAU成功率
关于以上三类SGSN的有关指标,一样情形下,在工作时刻8:
30-15:
30之间临时设置参考门限如下:
ATTACH成功率:
70%;PDP激活成功率:
90%;RAU成功率:
80%。
一旦PAPU的指标低于以上各门限,则可能显现咨询题。
但因各PAPU间指标相差较大,具体情形应具体分析。
例如:
某个PAPU的3项指标中任何一项发生明显降低,也可能是PAPU显现咨询题。
SGSN指标显现咨询题的处理
监控到以上3项指标发生专门,则需要赶忙通知有关人员(如网运中心等),进行处理。
处理后监控
观看各PAPU在处理后各时段的指标是否复原至正常水平。
各类性能监控周期、处理时限与记录要求
监控周期与处理时限
编号
监控内容
监控周期
处理时限
1
GPRSSLEEPINGCELLS
1次/半小时
3小时(日常)
2
EGPRSSLEEPINGCELL
1次/半小时
3小时(日常)
3
3273告警
1次/半小时
3小时(日常)
4
7725告警(BTS级告警)
1次/半小时
3小时(日常)
5
故障PCU
1次/半小时
24小时(日常)
7
其他BSC级告警的监控与处理
1次/天
半小时
8
GB负荷过高监控处理
1次/周(日常)
24小时(日常)
9
PCU的容量配置监控与调整
1次/周(日常)
24小时(日常)
10
SGSN有关指标监控
1次/1小时(日常)
记录要求
各项性能监控和处理过程的记录要求包括以下内容:
咨询题小区CI、BSC、SEG-ID
故障内容
故障发觉时刻
处理过程(包括各项操作的时刻点)
解决时刻
处理人