《2022年GPRS日常监控及处理流程.doc》由会员分享，可在线阅读，更多相关《2022年GPRS日常监控及处理流程.doc（16页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、GPRS 和 EDGE监控处理16 (16)BMCC PROJECT OPTIMIZATION19/05/2010 （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.2EGP
2、RS Sleeping Cell监控52.3EGPRS Sleeping Cell处理62.4EGPRS Sleeping 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告警处理1
3、17GB负荷过高监控处理128PCU的容量配置监控与调整139SGSN相关指标监控1410各类功能监控周期、处理时限与记录要求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 MS
4、G现象,即分组信道指派成功率低。 非常高的上/下行TBF建立失败率 从OMC KPI上来看，上/下行有效数据量、上/下行平均每时隙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有G
5、TRX,同时GENA已经打开.关于GPRS Sleeping cell,假如发觉其同时存在7725告警,则需参照后面处理7725的方法进展,假如不存在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处理后
6、的监控GPRS Sleeping Cell每一个处理步骤过后,均需要查看之后半小时的相关指标,假如指标不正常,则需要进展下一步.处理后的查看指标如下: 上、下行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 S
7、leeping Cell 毛病现象如下: 咨询题小区的GPRS统计正常,但是EGPRS流量忽然大幅度降低； 从OMC/KPI上来看,没有或者非常少的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之后, 排查该类小区是否无
8、用户、是否EDGE新规划基站.关于EGPRS Sleeping cell,假如发觉其同时存在7725告警,则需参照后面处理7725的方法进展,假如不存在7725告警,一般依次进展如下处理步骤:a) 检查EGPRS参数设置是否正常 EGENA是否打开； GTRX是否设置正确； EDAP是否绑定；b) 重启EGENA(需要Lock BTS) ；c) 互换咨询题小区的NSEI； EGPRS Sleeping cell的处理,主要有以上几种方法.假如以上各步骤均无效,则有三种应对措施:1.首先建议关闭EGENA.,保证EDGE用户能够使用GPRS上网.2及时通知运维倒换PCU,即切换BCSU；3.通知
9、相关人员(如基站工程师等)进展处理.2.4 EGPRS Sleeping Cell处理后的监控EGPRS Sleeping Cell每一个处理步骤过后,均需要查看之后半小时的相关指标,假如指标不正常,则需要进展下一步.处理后的查看指标如下: 上、下行EGPRS有效数据量(KB) EGPRS 上、下行 TBF数 UL/DL multi-slot allocation blocking(%) Expired LLC frames (%) DL Packet Immediate Assignment Message数 上、下行TBF建立成功率3. 3273告警监控及处理3.1 3273告警监控及处理
10、流程图 3.2 3273告警监控3273告警(EGPRS TERRITORY FAILURE)是PCU的容量预警,一般是由于PCU负荷过高导致(但也有个别PCU负荷较低而出现该告警的情况) 。每半小时提取一次3273告警毛病现象如下: BSC出现3273告警(E)GPRS TERRITORY FAILURE) ； 相关BTS的可用EGPRS信道数低于CDEF参数定义的默认信道数。3.3 3273告警处理监控查出发生告警的BSC,进入到该BSC,查看3273告警的附加信息,确定相关毛病小区(使用指令:ZAHO). 假如同一PCU下某1,2个小区出现3273告警,一般是由于该PCU的负荷过高导致,
11、处理措施确实是将出告警的小区挪至负荷较低的PCU. 假如同一PCU下多个小区同时出现3273告警,且将其下部分小区调至其他NSEI下之后,仍旧出现多个告警,则非常有可能是该PCU出现毛病,需要立即向网络运转支持中心集中监控中心(小号:7312173126)通报情况,及时处理 假如以上方法均不奏效,或者各个PCU负荷都较高,则有两种应对措施:1.关闭EGENA,2.降低GPRS/EGPRS的PDCH信道数.此外,高话务下话音业务挤占GPRS信道也会导致可用EGPRS信道数低于CDED参数定义的默认信道数,产生3273告警。处理措施: 平衡话务，适时提/催扩容建议。3.4 3273告警处理后的监控
12、3273告警处理过后,要查看下个时段的相关OMC KPI是否正常: 上、下行GPRS有效数据量(KB) 分组信道指派成功率 GPRS边界晋级回绝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 AC
13、TIVATION FAILURE,附加信息为”02”,表示是PDCH信道激活失败.4.2 7725告警处理假如毛病小区集中在某个PCU下,则说明是该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
14、的CD3晋级所导致的EDGE Sleeping Cell) 7725告警是一部分sleeping cell会出现的现象,与sleeping cell处理方法类似.假如以上各步骤均无效,则通知相关人员(如基站工程师等)进展处理.4.3 7725告警处理后的监控 7725告警处理过后,要查看下个时段的相关OMC KPI是否正常 上、下行GPRS有效数据量(KB) 分组信道指派成功率 上、下行EGPRS有效数据量(KB) （E）GPRS 上、下行 TBF数 上、下行TBF建立成功率5. 毛病PCU5.1 毛病PCU监控关于毛病PCU的监控，主要是通过网管统计中：表NPMDB_V_P_数据业务_严峻咨
15、询题NOKIA的数据来进展。该表将没有PS域数据统计的PCU列出。我们查看各个PCU及其所挂小区的现网状态，从而更进一步将PCU的毛病咨询题细化，大致分为如下两种情况：a) PCU下面小区无PS域数据统计，且确实存在毛病的情况。如：PCU的两条GB Bear均为BL_SY的状态，且有3030，3031告警；PCU所挂小区均发生3273告警；等等。b) PCU下面小区无PS域数据统计，但不确定是否存在毛病的情况。这种情况下，PCU不存在任何告警，PCU对应的GB Bear的状态以及PCU所挂小区的状态均正常。由于没有PS域数据统计，因而无法通过指标来实现对小区或者PCU的监控。只能通过现场测试或
16、者投诉情况，来断定。5.2 毛病PCU处理a). 对毛病PCU的处理，一般都需要上报网运来执行。5.3 毛病PCU处理后监控处理过后，要查看各小区相关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 UNAVAILA
17、BLE 该PCU覆盖区域内的GPRS网络不可用。2). 处理措施 查看NSEI的NSVC状态 查看BSC告警情况,使用指令: ZAHO、ZAHP 告警发生的可能缘故是Gb链路出现毛病,PCU硬件出现咨询题,BCSU重启后,PCU没有恢复正常工作或者是SGSN中的相关单元出现毛病,因而需要立即联络网络运转支撑中心通报情况,理解处理进度. 在该PCU毛病恢复之前,需要重启指定NSEI,将其下的小区分配到其他的PCU下工作,待毛病处理后再行恢复.3). 处理后监控处理过后，要查看下个时段的相关OMC KPI是否正常 ： 上、下行GPRS有效数据量(KB) 分组信道指派成功率 上、下行TBF数 上、下
18、行EGPRS有效数据量(KB) EGPRS 上、下行TBF数6.2 3031告警处理1). 毛病现象 BSC出现3031告警（BSSGP VIRTUAL CONNECTION RESET PROCEDURE FAILED） 相关小区的GPRS不可用2). 处理措施 查看3031告警的附加信息,确定相关的毛病小区,使用指令:ZAHO 假如同一PCU下的假设干小区同时出现3031告警,则有可能是该PCU出现毛病,需要立即向网络运转支撑中心通报情况,及时处理(一般需要对相应BCSU进展倒换) 假如同PCU下只是个别小区出现该告警,则需要查看该小区的功能指标,看是否断站或者基站硬件毛病 假如不是以上缘
19、故,则建议为相关小区重新分配另外的NSEI.3). 处理后监控处理过后,需要查看下个时段的相关OMC KPI是否正常 上、下行GPRS有效数据量(KB) 上、下行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 处理措施关于负荷
20、高的Gb Link，依照情况依次采纳以下方法进展处理： 同一PCU的负荷断定目前，在Nokia设备上，一个PCU同时使用两条Gb Link，分别对应两条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,
21、3,4提出Gb扩容建议，与运维中心协调处理（数据分析要精确到位）NSEI-N的Gb负荷20% ?否跟踪监控Gb负荷情况NSEI-1的Gb负荷过载计算最近一周各个小区的下行数据流量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数,GT
22、RX数 PCU下小区数是否超过64 PCU下PDCH数是否超过180 是否能够与同一BSC下其他PCU平衡 与其他PCU平衡 提出扩容建议 定期监控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之间
23、临时设置参考门限如下：ATTACH成功率：70%；PDP激活成功率：90%；RAU成功率：80%。 一旦PAPU的指标低于以上各门限，则可能出现咨询题。但因各PAPU间指标相差较大，详细情况应详细分析。例如：某个PAPU的3项指标中任何一项发生明显降低，也可能是PAPU出现咨询题。2) SGSN指标出现咨询题的处理 监控到以上3项指标发生异常，则需要立即通知相关人员（如网运中心等），进展处理。3) 处理后监控观察各PAPU在处理后各时段的指标是否恢复至正常水平。10 各类功能监控周期、处理时限与记录要求10.1 监控周期与处理时限编号监控内容监控周期处理时限1GPRS SLEEPING CEL
24、LS1次/半小时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 毛病内容 毛病发觉时间 处理过程（包括各项操作的时间点） 处理时间 处理人8a17c73e8cfbf9d29a358b9fbe38aeab.doc