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 sBS TX PWR MIN .PEAK PWR - 30 dB BS TX PWR MAX .PEAK PWR - 08 dBBS TX PWR OFFSET . 00 dB BS TX PWR MAX1X00 PEAK PWR - 08 dBPOWER INCR STEP SIZE . 4 dB POWER RED STEP SIZE . 2 dBSD拥塞 将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范围014)，以减少位置更新次数，从而缓解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)运行维护中心集中监控中心操作；寻呼策略参考：STRATEGYTMSI USAGETMSI PAGE REPETITION1ST PAGE & AT TIMES REPAGE2ND PAGE & AT TIMES REPAGE1YESYESWITH TMSIWITH IMSI2YESNOWITH TMSINO3NOYESWITH IMSINO4NoNoWITH IMSINO第三步：继续观测,若出现寻呼量大于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平均测量周期，取值范围14，现网设置是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取值为14，现网设置为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:; 来查看是哪些站出现这种问题。告警格式如下所示： 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