?日常的优化工作流程
?告警监测
每天对所负责日常的BSC单元、基站的重大告警进行监测，了解其对网络性能的影响程度。TRANSCODER(transcoder)是相对容易出现问题的单元，而且一旦有TRANSCODER单元故障，将会造成大面积的严重掉话，产生极其严重的后果。当一个BSC的掉话突然整体上升时，往往是由于TRANSCODER的原因。相关指令如下：
1）、用ZAHO、AHP检查BSC所带单元的告警
2）、用ZEOH、EOL检查BCF及BTS告警
告警监测任务流程：
?断站检查(用ZEEI检查断站情况)
断站是影响网络性能的重大因素，对网络的拥塞、掉话、切换等都有重大的影响，检查断站的方法如下：
1、用ZEEI；屏幕上将显示该BSC下所带基站的工作状态、管理状态、TRX配置情况、所用频点号、ET-PCM号、O&M LINK状态以及基站忙闲程度。若工作状态为U、管理状态和O&M LINK状态为WO，一般为正常；若O&M LINK状态为BL，则可断定为断站（若同时操作状态为LOCK，则要看看是否为待开新站）。
2、从信道统计结果看闭塞信道数是否与总信道数一致，若一致，也可判为断站。要特别注意“隐型的断站”，从基站的工作状态看是正常的，又没有严重的告警，对于维护部门来说难以判断更需要我们的配合与处理。隐型断站一般是在参数修改时由于偶然原因造成BSC参数数据库与BTS或BSC内其它单元或模块间的数据不一致，造成基站无法提供服务。由于“隐型断站”没有明显告警，可以从统计中检出工作状态正常而话务量为零站，判为“隐型断站”。
检查隐型断站的方法：
1）从东区来看，NOKIA基站出现7724告警（在无线网络数据库和呼叫控制程序块间存在冲突）时，基站实际无法提供服务，可判断为隐型断站；
2）用“ZERO”指令看TRX状态时，最后出现提示“CONFLICT BETWEEN DATABASE AND RRMPRB”，通常整个基站不能提供服务，可判为隐型断站；
3）当基站的信道没有闭塞，而话务量为0时，多为隐型断站；
隐型断站产生的原因主要是有两种：
1）BSS无线网络数据分配到BTS时出错；
2）BSC内部分配修改过的无限参数时出错。这类错误的产生多与所执行的指令及基站状态有关，相当于修改参数时，BSC数据库中的参数修改成功，但是没有完成数据的配送工作。在执行指令时会有一些提示，如/*** BTS SITE NOT
UPDATED ***/，或/*** RRMPRB NOT UPDATED ***/，如果当时没有在意，事后就会出现上述情况。
隐型断站的处理：一般需将TRX或整个基站的数据删掉重做来解决。
?掉话处理方法
对TCH掉话进行监测，按照掉话次数的多少进行排序，以确定下一步要处理的小区。NOKIA的掉话原因基本上来自RF、ABIS接口、A接口、TRANSCODER、LAPD、BTS、BCSU等方面，在具体分析、处理时还需要根据掉话原因是正常掉话还是HO 掉话，是传输故障还是硬件故障。对各种原因掉话的分析处理可以利用NETWORK DOCTOR，也可以从数据库中取得一些相关统计（由于PM的直观性比较差，我们一般通过MICROSOFT ACCESS或用SQL语言直接访问数据库来得到一些统计）。此外，每天十点的全网统计可通过FTP（配置在工具一章中提到）下载。格式如下表：
高掉话小区分析任务流程：
?TCH拥塞处理方法
对ＴＣＨ拥塞进行监测，对于长期拥塞的小区或地区，向相关部门提出扩容或加站建议，对暂时或有可能通过调整进行缓解的要及时进行调整。
此外，还要注意一些客观情况的变化：
●突发性大型活动：展览、抽奖、抓彩票、体育比赛、演唱会等，会使
一片日常的话务量激增，产生严重拥塞。这种情况只能视活动的重要
性事先做一定的调整；
●新增的话务密集区：商业中心的落成、高级住宅区的竣工、新的游乐
场开始营业等。对这种地区应该事先有一定的调查，发生拥塞后，应
及时采取一些临时的缓解措施，同时抓紧扩容和新建基站的准备工
作；
●长期的话务热点，如机场、车站、郊区县城等，应督促工建部门重视
网络的实际需要，提高建设效率与效益，立足于解决实际问题，尽力
而为。
另外，从全网统计到的数据中观察TCH话务量、TCH拥塞率和TCH 信道数三个参数，若TCH拥塞高，TCH话务量与TCH信道数相比很小，则此小区一定存在问题，需要仔细剖析该小区，然后根据具体情况，采取必要措施