GSM日常优化值班手册.doc

GSM优化值班手册
概述
针对网络出现的各种问题，提供相关的建议解决方法。
严重问题
关注如下问题： TCH拥塞，SD拥塞，SD高掉话，高掉话，每线话务量高
请点击相应的超连接，转到本文档的详细说明部分进行处理。
TCH拥塞&每线高话务
拥塞原因：是否由于闭塞信道引起
缓解拥塞方法：
Ø 降低拥塞小区发射功率，同时提升共站及其它邻小区的发射功率：修改指令ZEUG:BTS=*:PMAX(PMAX2)=*;
Ø 打开DR：查看指令ZEQO:BTS=**:CEL;修改指令ZEQF:BTS=**,DR=Y;
Ø 降低本小区切出门限PMRG、PRI(ZEAM:BTS=*:LAC=***,CI=***::PMRG=*, PRI=*,;)
Ø 提高邻小区切入门限PMRG、PRI(指令同上)
Ø 对于1800M小区，可降低或关闭C2：查看指令ZEQO:BTS=**:MIS;修改指令 ZEQM:BTS=*::PI=*,REO=*;
Ø 关于7746拥塞告警：目前可实现部分BSC 30分钟的监测周期。
NOKIA 7746告警（5分钟周期）
以TCH拥塞率或SD拥塞率大于3%为门限，连续出现4次告警以上的，或在6次/小时以上的，即启动流程
Ø 如需要临时打开半速率提升容量，参见半速率调整傻瓜版
需要确定BSC是否有半速率的Feature

注意1:均衡后必须用ZEEI实时观察用户数是否下降，直到不拥塞为止。
注意2:如是重点通信保障地区，调整切换参数时，可根据《重点地区主控小区列表》挑选邻区。
注意3:“PMAX2”
部分BSC安装了支持EDGE功能的BSC软件包，其1800M发射功率的参数发生变化，为PMAX1X00, 见下面的红字部分，而旧版本是没有这个参数的。在新版本的软件包中，GSM900和DCS1800的发射功率分别由BS TX PWR MAX和BS TX PWR MAX1X00控制，对应参数为GSM900--PMAX,DCS1800--PMAX2。
  示例：新版本POC数据 修改指令：ZEUG:BTS=**:PMAX2=*;
POWER CTRL ENABLED .........  Y      POWER CONTROL INTERVAL ..... 01  s
BS TX PWR MIN ....PEAK PWR - 30 dB   BS TX PWR MAX ....PEAK PWR - 08  dB
BS TX PWR OFFSET ........... 00 dB   BS TX PWR MAX1X00 PEAK PWR - 08  dB
POWER INCR STEP SIZE .......  4 dB   POWER RED STEP SIZE ........  2  dB
……

SD拥塞
Ø 将TCH时隙改为SDCCH时隙，以增加SD的信道个数。在16K TRX信令速率下，每个TRX只能配1个SDCCH时隙(查看配置ZERO:BTS=**;闭站、闭载频、修改指令ZERM:BTS=**,TRX=*:CH*=SDCCH;).如果误配置为2个SDCCH时隙，可能会导致载频不断重起。在32K TRX信令速率下，每个TRX可以配2个SDCCH时隙(ZDSB:::PCM=*;查看是否为32K信令速率)
Ø 降低拥塞小区发射功率，同时提升共站及其它邻小区的发射功率：修改指令ZEUG:BTS=*:PMAX(PMAX2)=*;
Ø 对于1800M小区，可降低或关闭C2：查看指令ZEQO:BTS=**:MIS;修改指令 ZEQM:BTS=*::PI=*,REO=*;
Ø 对于处于位置区交界的小区，提高自己及邻区中属于不同LAC的小区的HYS(HYS范围0~14)，以减少位置更新次数，从而缓解SDCCH信道的拥塞：查看指令 ZEQO:BTS=**:RAD 修改指令ZEQG:BTS=**:HYS=*;
SD高掉话
评估中心提供的统计中SDCCH掉话高的定义是高于500次的SDCCH掉话，可以按照如下步骤进行处理：
Ø 原因分析：是否硬件故障导致某载频SDCCH掉话高。
Ø 可进行重起载频、倒换BCCH所在载频、重起基站等操作：ZDTC:T****:AD; ZDTC:T****:WO;
Ø 如果仍未恢复，可稍降基站功率，将SDCCH掉话次数降低，避免影响网络性能。
高掉话
评估中心提供的统计中高掉话的定义是高于100次。
高于100次的掉话主要是由于强干扰或严重的硬件故障，查看是否有大量7744、7745等告警，可暂时降功率缓解，但调整功率的幅度要兼顾客户感知。
网络监控
RACH DELETE
关注BCSU_OVERLOAD_DELETED_RACH之Sum ，如果某个基站的该项数值大于600则应进行关注。
原因分析：当BTS话务量很高的情况下，BSC会启动保护机制，对过多的RACH申请进行删除，造成用户短时间内无法通话。现象是BTS级统计在1小时内出现大量的RACH DELETE。
Ø 查看告警，是否有传输闪断或其它的硬件故障
Ø 查看小区的参数设置并记录，为下面的改动提供基础(ZEQO:BTS=**:ALL;)
Ø 疏导BTS话务，防止拥塞(拥塞处理)
Ø 调整BTS参数RET(最大重传次数,RACH的控制参数)，目前设置为4，可以调整为2 (ZEQM:BTS=**:RET=2;)
Ø 调整BTS参数SLO(发送分布时隙数,接入算法)，目前设置为10，可以调整为12 (ZEQM:BTS=**:SLO=10;)
Ø 调整T3122，延长MS前次SDCCH申请被拒绝后接入保护时间，目前为6秒，最大可设置为10秒(ZEGT:T3122:1,10:;)
Ø 如果基站并没有出现占用人数多，拥塞等告警，则可能是硬件挂起，重启基站观察。

PAGING DELETE
首先要区别是LAC下个别CELL出现寻呼删除，还是LAC下所有（绝大多数）小区同时出现寻呼删除，对于个别CELL的情况，主要分析是否小区的SDCCH业务量或者GPRS请求次数过大造成，其原因是AGCH的优先级高于PCH，因此某些情况下会由于系统占用PCH信道发送AGCH导致寻呼删除，此时主要方法是疏导话务，减少AGCH的业务量。还有就是软硬件故障导致，此时需要对基站进行RESET，将故障消除。

对于LAC下绝大多数CELL同时出现寻呼删除的情况，其引发原因主要是高业务量（寻呼量>10万），或者短时间内大业务量造成（如：寻呼量<6万，同时BMCC短信群发等）。对于前者可以让运行维护中心集中监控中心操作处理，对于后者由于大业务量是短时的，可以暂不做处理，但需要继续观察。

对于同一LAC下大量CELL的寻呼消息溢出数量大于寻呼消息总量的3%时，需要及时通知综合部，由综合部协调运维中心进行紧急处理，可以临时关闭相关LAC的RE-PAGING参数，减少PAGING量。当寻呼消息溢出数量较少时，可暂时不做处理，但要及时的提取统计，观察变化情况。对于寻呼消息溢出的情况，第二天要及时通知本部门和规划部门，作出调整方案。

寻呼过载处理
当前一小时寻呼数大于14万/小时或者寻呼溢出1000次/小时（小区.平均）应按照以下步骤采取措施：
第一步：关闭MSC侧的REPAGING参数（AT），运行维护中心集中监控中心操作；
第二步：若调整后观测还大于16万/小时，关IMSI寻呼
关闭MT SMS repaging.(RTPMTS=NOT USED)
关闭MT CALL repaging.(RTPMTC=NOT USED)
运行维护中心集中监控中心操作；
寻呼策略参考：
STRATEGY
TMSI USAGE
TMSI PAGE REPETITION
1ST PAGE & AT TIMES
REPAGE
2ND PAGE &
AT TIMES REPAGE
1
YES
YES
WITH TMSI
WITH IMSI
2
YES
NO
WITH TMSI
NO
3
NO
YES
WITH IMSI
NO
4
No
No
WITH IMSI
NO
第三步：继续观测,若出现寻呼量大于20万：
网优规划中心准备割接方案，东区优化中心实施无线覆盖收缩方案，减少MSC周遍BTS的覆盖范围，降低MSC用户数。
T3101超时
关注《T3101_LAC大于10表》中最后一项T3101%，该表显示的是超过T3101超时超过10%的LAC，处理时要根据《T3101大于15表》中，属于该LAC的T3101超时的Cell进行分析，T3101监测立即分配过程。
原因分析：导致T3101超时的原因很多，在通信保障中要注意的是由于大业务量（下行主要是寻呼、上行主要是测量报告）造成的LAC级或BSC级的高T3101超时情况。日常网络级T3101超时的比例在5%左右，当LAC级T3101超时比例超过15%（除去个别故障小区影响）时，可能有大量业务发生，需要疏导，防止情况进一步恶化。
T3101超时一般有两种情况：
Ø 软硬件故障：个别基站T3101超时情况严重，其他基站统计情况正常，对网路安全没有严重影响。一般由于基站的软、硬件故障导致，只需要多对发生问题的基站进行处理，根据实际情况对基站进行重起等操作，使其尽快恢复正常。
Ø LAC寻呼量过大：LAC下所有基站T3101超时情况都比较严重，属于普遍现象时，网络有出现安全隐患的可能，需要及时处理。这种情况一般由于LAC寻呼量过大造成，需要及时的控制寻呼，具体手段可以参考寻呼溢出进行处理。
Ø 针对上行导致的情况，可提高BMA参数(BTS平均测量周期，取值范围1~4，现网设置是1，1表示BTS对一个SACCH复帧周期的测量结果进行平均)，并进行话务疏导，降低上行的负荷(查看指令ZEQO:BTS=*:MIS;修改指令ZEQG:BTS=**:BMA=;)

为进行全面分析，需要的相关数据收集工作： 一般情况不需值班人员操作
Ø 核查前一时段LAC的寻呼量，并收集的LAPD负荷信息，检查是下行导致还是上行导致。
统计每一条LAPD信令的流量：操作指令ZDMF; ZDSB:::PCM=**;
BCSU OVERLOAD
关注《AVERAGELOAD生成表》，统计项包括所有CPU负荷超过50％的BCSU列表，关键统计项名称为AVERAGE LOAD。

话务原因造成BSC CPU LOAD高
BSC BCSU单元OVERLOAD可以通过2720、1014告警和BSC单元的负载统计发现，当BCSU单元的平均负荷超过定义的门限值时会发出2720告警和1014告警，统计中BCSU单元平均负荷超过NOKIA定义严重告警门限（60%）。
Ø 降低主要由过载BCSU控制的BTS的话务
Ø 均衡过载BCSU控制的TRX至其它低负载的BCSU
查看问题BCSU所带的载频：ZEEI:BTS=**;
查看还有空余TRX的BCSU：ZEEI::BCSU;
删除载频：ZERD:
建载频，倒换BCSU：ZERC:
Ø 升高相关BCSU下BTS的BMA参数(BTS测量的平均周期)，降低BCSU负荷（BMA取值为1~4，现网设置为1，1表示BTS对一个SACCH复帧周期的测量结果进行平均)：
当60%<BCSU负荷<70%，建议BMA设为2；(ZEQM:BTS=**:BMA=2;)
当70%<BCSU负荷<80%，建议BMA设为3；(ZEQM:BTS=**:BMA=3;)
当80%<BCSU负荷<90%，建议BMA设为4；(ZEQM:BTS=**:BMA=4;)
Ø 下一时段根据统计情况，继续修改BMA参数取值。
Ø 通过调整BSC所在LAC的PAGING参数和BSC下BTS的RET，SLO，BMA参数降低BCSU负荷。

非话务原因造成BSC CPU LOAD高
由于S10.5升级的软件BUG造成BCSU某个进程产生的LOAD非常高，尤其对处理能力相对较弱的SUBRACK BSC影响严重，可能造成20%左右的负荷增加。
Ø 查看当前BCSU的LOAD
操作指令ZDOI：BCSU；
Ø 使用ZTVI指令恢复出问题的进程，此指令执行时间较长
操作指令 ZTVI：48；

检测办法：通过SERVICE TERMINAL取TOP 20 进程，如果发现01B3 0000进程负荷较高，则可以确定。
ZDOI:BCSU;（实时观测BCSU负荷）
ZDDS: BCSU, X;（“X”为BCSU号，进入SERVICE TERMINAL）
ZLE：X，TOPTENGX（X为菜单代码，设一个未出现的即可）
XX-MAN: ZXR（“X”为上一条指令中的菜单代码，可观测到各进程的负荷情况。
注意：在话务负荷非常高的情况下，不要使用此指令，因为指令也会造成BCSU负荷增加，因此在话务负荷非常高的情况下使用可能发生危险！！！可以跳过此项工作直接进行处理。
BSC_TR掉话大于15表
出现在该表中的BSC是在上一个统计时段TR掉话大于15个的。这个时候应该进入相关的BSC，使用如下命令查看ZAHP::NR=2993:; 来查看是哪些站出现这种问题。告警格式如下所示：
<HIST> BSC132 MCMU-1 TRANSM 2005-04-26 14:08:50.97
** ALARM ........ RRM_BX
(0416) 2993 BTS AND TC UNSYNCHRONIZATION CLEAR CALLS ON ABIS INTERFACE
90d 10d 06 135d 20d 4d
其中红色的90代表BTS号码，黄色的10代表载频号码，紫色的6代表时隙。找到出问题的站后可以进行相关的操作：
Ø 考虑重启该载频
Ø 考虑关闭该载频
Ø 考虑关闭该时隙
BSC Alarm 2133
现象：LAPD下行过负荷，BSC出现2133告警
建议：其原因一般是由于LAC下寻呼量过大造成，需要及时疏导话务，查找、解决造成寻呼量异常的原因，处理方法同寻呼过载。及时通过ZDMF指令收取相关LAPD的负载情况。
零起呼小区
关注《TCH试呼为0表_占用_》中的小区。

Ø 查看是否有无起呼的7738告警，或失败率很高（高于60%）的7745告警。
Ø 对比头一天同一时段以及当天10点的统计，看是否正常情况。
操作指令 ZEOH::BCF=**,NR=7738,NR=7745; ZEOL::NR=7738,NR=7745；
Ø 查看是否有7703(BCSU RESTARTED)BCSU重起的告警。因为BCSU的重起带来的不是一个站的没有起呼告警，可能会引起该BCSU下所带的BCCH载频均无法起呼。
处理方法
将基站重启，或将BCCH载频与其他载频倒换，看是否7738告警会CANCEL，并观察下一时段统计是否恢复正常。

附录：半速率调整傻瓜版

6