优化总结一.doc

网络优化总结 部门 MNE3 姓名 孙瑜峰 目录 指标和公式 3 TCH掉话次数 3 SDCCH拥塞次数 4 TCH 拥塞次数 5 分配失败次数 5 切换成功次数 5 基本算法 6 TCH分配算法 6 小区选择和重选 6 功率控制 6 切换 7 OMCR参数 9 BSC参数 9 小区参数 9 实用点滴 19  指标和公式 TCH掉话次数 =MC136+MC139+MC14C+MC21 MC136为射频信号丢失次数，MC139为传输波动掉话次数，MC14C为BSS问题造成的掉话次数，MC21为切换造成的掉话次数。 正常情况下，掉话主要集中在空中接口（MC136+MC21），陆地链路（MC14C+MC139）造成的掉话应与之有数量级的差别。掉话的定位一般是首先看小区的每一个TRX的平均占用时长（MC380A/MC370A），即可找出是由于某个TRX的原因或者是该小区普遍不好。 MC136的原因可能是干扰，信号覆盖不好，或者BTS的天馈系统VSWR过高造成。在网优过程中，对以上几种原因的查找和解决方法主要为以下几种：干扰过大。如果网络采用BBH或未跳频，在PM报告中查看C320的分布（C320为个干扰带的分布情况）或切换cause的分布；若网络采用RFH，考虑的是RF LOAD，则主要从PM报告中查看该CELL的话务量并从OMC上查看有无VSWR告警。干扰主要可从两方面来考虑解决：在保证覆盖的前提下，加大ANT的下倾角，或者对RNP重新调整，以及检查天线的方位角。VSWR则由硬件排障人员解决。除了以上几种原因外，另外有工程原因和设备故障也会引起MC136过高的现象。工程原因例如，天馈安装时出现鸳鸯线，TRE的收或发跳线接触不良等；A-BIS消息的处理大部分是在BSC的TCU模块上进行的，所以TCU模块的故障也可引起MC136的掉话。一般的，若MC136突发异常，往往伴随着其它现象，例如分配失败率的上升等，在实际优化过程中可配合信令跟踪，路测等手段对产生原因进行分析。 MC139是由于REMOTE TRANSCODER引起的CONNECTION FAILURE而造成的掉话。如果是A口的问题，则会造成整个BSC掉话偏高；如果是A-BIS的问题，则相应的该CHAIN上的CELL掉话偏高。在BSC的模块中，TCU，FUMO（G2），SUM，SMBI（？）均会造成MC139的现象，这种情况往往也伴随着MC14C比较高。遇到这种情况，在确认更换相关的模块前，先RESET，再观察是否会变好。本次优化过程中，有部分小区的MC139偏高，经查，这些小区中有个别TRX的平均占用时长有异（MC380A/MC370A）。关闭相应TRX后指标正常。主要由两种原因造成：用户定义的监控时隙与TCH或RSL冲突；在升版的过程中，一些小区的MAPING发生了错误，也产生了MC139过高的掉话。在重庆优化的过程中，发现自12/25日下午15时起，BSC2的C139异常，达到1000多次，经信令跟踪发现系局方传输DDF架割接，造成一路PCM接头虚焊所致。 MC14C产生的原因有：”OM intervention” “Message sequence error” “LAPD failure” “TCH call release initiated by BSS OM FAULT MANAGEMENT application part or by BSS TELCOM application part as the result of a system defense action which may be due to BSS equipment failures external to the BSC(e.g. RSL failure or CU failure), or due to BSS internal hardware problems(e.g. TCU failure or DTC failure) or due to BSS internal software problems(e.g. inconsistencies detected between software modules or lack of software resource(memory, time reference, file reference) or communication problems between different processor board 。简单的说，如果由于传输的原因发生了一次掉话，如果传输迅速恢复，则MC139计数，如果在一定时间内没有恢复，则MC14C增加，如涪陵优化过程