EGPRS日常监控及处理流程.docx

EGPRS日常监控及处理流程.docx

《EGPRS日常监控及处理流程.docx》由会员分享，可在线阅读，更多相关《EGPRS日常监控及处理流程.docx（16页珍藏版）》请在冰豆网上搜索。

EGPRS日常监控及处理流程

（E）GPRS日常监控处理

2010-5-19

1.GPRSSleepingCells监控及处理

1.1GPRSSleepingCell监控及处理流程图

1.2GPRSSleepingCell监控

每半小时查看一次GPRS小区的各项指标,从而发现GPRSSleepingCell.

GPRSSleepingCell故障现象如下:

Ø很多的PACKETIMMEDASSREJMSG和很少的PACKETIMMEDASSACKMSG现象,即分组信道指派成功率低。

Ø很高的上/下行TBF建立失败率

Ø从OMCKPI上来看，上/下行有效数据量、上/下行平均每时隙TBF数等均不正常（为0或较之前降低很多）

注：

PACKETIMMEDASSREJMSG和PACKETIMMEDASSACKMSG两个counter在表PacketControlUnitMeasurement中，可以直接查看这两个counter值的变化从而判断出GPRSSleepingCell并做出相应的处理。

1.3GPRSSleepingCell处理

监控出现GPRSSleepingcell之后,首先保证这个cell有GTRX,并且GENA已经打开.

对于GPRSSleepingcell,如果发现其同时存在7725告警,则需参照后面处理7725的方法进行,如果不存在7725告警,一般依次进行如下处理步骤:

a）.重启GPRS功能开关（即GENA）；

b）.重启GTRX（TRX上的GPRS开关）；

c）.调换GPRSSleepingcell的NSEI；

GPRSSleepingcell的处理,主要有以上三种方法,依次进行.如果以上各步骤均无效,则有两种应对措施:

1.及时通知运维倒换PCU,即切换BCSU；2.通知相关人员（如基站工程师等）进行处理.

1.4GPRSSleepingCell处理后的监控

GPRSSleepingCell每一个处理步骤过后,均需要查看之后半小时的相关指标,如果指标不正常,则需要进行下一步.处理后的查看指标如下:

Ø上、下行GPRS有效数据量（KB）

Ø分组信道指派成功率

ØPacketImmediateAssignmentMessage数

Ø上、下行TBF建立成功率

Ø上、下行TBF数

2.EGPRSSleepingCell监控及处理

2.1EGPRSSleepingCell监控及处理流程图

2.2EGPRSSleepingCell监控

每半小时查看一次EGPRS小区的各项指标,从而发现EGPRSSleepingCell.

EGPRSSleepingCell故障现象如下:

Ø问题小区的GPRS统计正常,但是EGPRS流量突然大幅度降低；

Ø从OMC/KPI上来看,没有或者很少的EGPRSUL/DLTBFNumber、EGPRSULTBFNumber与DLTBFNumber差别很大、EGPRSDLPayload为0；

ØExpiredLLCframes（%）DL过高

ØUL/DLmulti-slotallocationblocking（%）过高

Ø有用户投诉EGPRS不可用

2.3EGPRSSleepingCell处理

监控出现EGPRSSleepingCell之后,排查该类小区是否无用户、是否EDGE新规划基站.

对于EGPRSSleepingcell,如果发现其同时存在7725告警,则需参照后面处理7725的方法进行,如果不存在7725告警,一般依次进行如下处理步骤:

a）检查EGPRS参数设置是否正常

ØEGENA是否打开；

ØGTRX是否设置正确；

ØEDAP是否绑定；

b）重启EGENA（需要LockBTS）；

c）调换问题小区的NSEI；

EGPRSSleepingcell的处理,主要有以上几种方法.如果以上各步骤均无效,则有三种应对措施:

1.首先建议关闭EGENA.,保证EDGE用户可以使用GPRS上网.2及时通知运维倒换PCU,即切换BCSU；3.通知相关人员（如基站工程师等）进行处理.

2.4EGPRSSleepingCell处理后的监控

EGPRSSleepingCell每一个处理步骤过后,均需要查看之后半小时的相关指标,如果指标不正常,则需要进行下一步.处理后的查看指标如下:

Ø上、下行EGPRS有效数据量（KB）

ØEGPRS上、下行TBF数

ØUL/DLmulti-slotallocationblocking（%）

ØExpiredLLCframes（%）DL

ØPacketImmediateAssignmentMessage数

Ø上、下行TBF建立成功率

3.3273告警监控及处理

3.13273告警监控及处理流程图

3.23273告警监控

3273告警（EGPRSTERRITORYFAILURE）是PCU的容量预警,一般是由于PCU负荷过高导致（但也有个别PCU负荷较低而出现该告警的情况）。

每半小时提取一次3273告警

故障现象如下:

ØBSC出现3273告警（（E）GPRSTERRITORYFAILURE）；

Ø相关BTS的可用EGPRS信道数低于CDEF参数定义的默认信道数。

3.33273告警处理

监控查出发生告警的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告警。

解决措施:

均衡话务，适时提/催扩容建议。

3.43273告警处理后的监控

3273告警处理过后,要查看下个时段的相关OMCKPI是否正常:

Ø上、下行GPRS有效数据量（KB）

Ø分组信道指派成功率

ØGPRS边界升级拒绝CS话务过高

ØGPRS边界升级拒绝BTS信道受限

ØGPRS边界升级拒绝PCU信道受限

Ø上、下行EGPRS有效数据量（KB）

Ø（E）GPRS上、下行TBF数

4.7725告警（BTS级告警）监控及处理

4.17725告警监控

7725告警的监控需要与GPRSSleepingCell和EGPRSSleepingCell相结合.监控出指标异常小区后,看该小区是否有7725告警（使用指令:

ZEOL）.7725告警:

TRAFFICCHANNELACTIVATIONFAILURE,附加信息为”02”,表示是PDCH信道激活失败.

4.27725告警处理

如果故障小区集中在某个PCU下,则说明是该PCU出现问题,需要立即联系网络运行支撑中心倒换相应PCU.

如果故障小区分布于不同的PCU,则依次进行以下处理方法:

Ø针对GPRS小区（或masterBTS）

a）.重启GENA

b）.调换故障小区的NSEI

c）.重启出现告警的BTS和TRX

Ø针对EGPRS小区（或slaveBTS）

a）.重启EGENA（需要LockBTS）

b）.调换故障小区的NSEI

c）.重启出现告警的BTS和TRX

d）.关闭slaveBTS的跳频（针对BSC的CD3升级所导致的EDGESleepingCell）

7725告警是一部分sleepingcell会出现的现象,与sleepingcell处理方法类似.如果以上各步骤均无效,则通知相关人员（如基站工程师等）进行处理.

4.37725告警处理后的监控

7725告警处理过后,要查看下个时段的相关OMCKPI是否正常

Ø上、下行GPRS有效数据量（KB）

Ø分组信道指派成功率

Ø上、下行EGPRS有效数据量（KB）

Ø（E）GPRS上、下行TBF数

Ø上、下行TBF建立成功率

5.故障PCU

5.1故障PCU监控

对于故障PCU的监控，主要是通过网管统计中：

表《NPMDB_V_P_数据业务_严重问题NOKIA》的数据来进行。

该表将没有PS域数据统计的PCU列出。

我们查看各个PCU及其所挂小区的现网状态，从而更进一步将PCU的故障问题细化，大致分为如下两种情况：

a）PCU下面小区无PS域数据统计，且的确存在故障的情况。

如：

PCU的两条GBBear均为BL_SY的状态，且有3030，3031告警；PCU所挂小区均发生3273告警；等等。

b）PCU下面小区无PS域数据统计，但不确定是否存在故障的情况。

这种情况下，PCU不存在任何告警，PCU对应的GBBear的状态以及PCU所挂小区的状态均正常。

因为没有PS域数据统计，所以无法通过指标来实现对小区或者PCU的监控。

只能通过现场测试或者投诉情况，来判定。

5.2故障PCU处理

a）.对故障PCU的处理，一般都需要上报网运来执行。

5.3故障PCU处理后监控

处理过后，要查看各小区相关OMCKPI是否正常：

Ø上、下行GPRS有效数据量（KB）

Ø分组信道指派成功率

Ø上、下行EGPRS有效数据量（KB）

Ø（E）GPRS上、下行TBF数

6其他BSC级告警的监控与处理

6.13019/3020告警处理

1）.故障现象

ØBSC出现3019或者3020告警：

3019NETWORKSERVICEENTITYUNAVAILABLE

3020NETWORKSERVICEVIRTUALCONNECTIONUNAVAILABLE

Ø该PCU覆盖区域内的GPRS网络不可用。

2）.处理措施

Ø查看NSEI的NSVC状态

Ø查看BSC告警情况,使用指令:

ZAHO、ZAHP

Ø告警发生的可能原因是Gb链路出现故障,PCU硬件出现问题,BCSU重启后,PCU没有恢复正常工作或者是SGSN中的相关单元出现故障,因此需要立即联系网络运行支撑中心通报情况,了解处理进度.

Ø在该PCU故障恢复之前,需要重启指定NSEI,将其下的小区分配到其他的PCU下工作,待故障解决后再行恢复.

3）.处理后监控

处理过后，要查看下个时段的相关OMCKPI是否正常：

Ø上、下行GPRS有效数据量（KB）

Ø分组信道指派成功率

Ø上、下行TBF数

Ø上、下行EGPRS有效数据量（KB）

ØEGPRS上、下行TBF数

6.23031告警处理

1）.故障现象

ØBSC出现3031告警（BSSGPVIRTUALCONNECTIONRESETPROCEDUREFAILED）

Ø相关小区的GPRS不可用

2）.处理措施

Ø查看3031告警的附加信息,确定相关的故障小区,使用指令:

ZAHO

Ø如果同一PCU下的若干小区同时出现3031告警,则有可能是该PCU出现故障,需要立即向网络运行支撑中心通报情况,及时处理（一般需要对相应BCSU进行倒换）

Ø如果同PCU下只是个别小区出现该告警,则需要查看该小区的性能指标,看是否断站或者基站硬件故障

Ø如果不是以上原因,则建议为相关小区重新分配另外的NSEI.

3）.处理后监控

处理过后,需要查看下个时段的相关OMCKPI是否正常

Ø上、下行GPRS有效数据量（KB）

Ø上、下行EGPRS有效数据量（KB）

Ø分组信道指派成功率

Ø（E）GPRS上、下行TBF数

7Gb负荷过高监控处理

7.1故障现象

统计数据中的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%

7.2处理措施

对于负荷高的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…

7.3查看统计

处理过后,要查看下个时段的相关OMCKPI是否正常：

ØMaxsentload%（frl_7）

ØMaxrecload%（frl_8）

8PCU的容量配置监控与调整

1）.故障现象

PCU的PDCH或小区配置数量过高

2）.处理流程图

3）.处理后监控

处理过后，要查看下个时段的相关OMCKPI是否正常：

ØSumofDedicatedTSL/NSEI

ØSumofDefaultTSL/NSEI

ØSumofEDAPTSL/NSEI

ØTotaltsl/NSEI

9SGSN相关指标监控

1）SGSN各PAPU的相关指标

ØATTACH成功率

ØPDP激活成功率

ØRAU成功率

对于以上三类SGSN的相关指标，一般情况下，在工作时间8:

30-15:

30之间暂时设置参考门限如下：

ATTACH成功率：

70%；PDP激活成功率：

90%；RAU成功率：

80%。

一旦PAPU的指标低于以上各门限，则可能出现问题。

但因各PAPU间指标相差较大，具体情况应具体分析。

例如：

某个PAPU的3项指标中任何一项发生明显降低，也可能是PAPU出现问题。

2）SGSN指标出现问题的处理

监控到以上3项指标发生异常，则需要立即通知相关人员（如网运中心等），进行处理。

3）处理后监控

观察各PAPU在处理后各时段的指标是否恢复至正常水平。

10各类性能监控周期、处理时限与记录要求

10.1监控周期与处理时限

编号

监控内容

监控周期

处理时限

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小时（日常）

10.2记录要求

各项性能监控和处理过程的记录要求包括以下内容：

Ø问题小区CI、BSC、SEG-ID

Ø故障内容

Ø故障发现时间

Ø处理过程（包括各项操作的时间点）

Ø解决时间

Ø处理人