日常优化工作流程.docVIP

日常的优化工作流程 告警监测 每天对所负责日常的BSC单元、基站的重大告警进行监测，了解其对网络性能的影响程度。TRANSCODER(transcoder)是相对容易出现问题的单元，而且一旦有TRANSCODER单元故障，将会造成大面积的严重掉话，产生极其严重的后果。当一个BSC的掉话突然整体上升时，往往是由于TRANSCODER的原因。相关指令如下： 1）、用ZAHO、AHP检查BSC所带单元的告警 2）、用ZEOH、EOL检查BCF及BTS告警 告警监测任务流程： 断站检查(用ZEEI检查断站情况) 断站是影响网络性能的重大因素，对网络的拥塞、掉话、切换等都有重 大的影响，检查断站的方法如下： 1、用ZEEI；屏幕上将显示该BSC下所带基站的工作状态、 管理状态、 TRX配置情况、所用频点号、ET-PCM号、OM LINK状态以及基站忙闲程度。若工作状态为U、管理状态和OM LINK状态为WO，一般为正常；若OM LINK状态为BL，则可断定为断站（若同时操作状态为LOCK，则要看看是否为待开新站）。 2、从信道统计结果看闭塞信道数是否与总信道数一致，若一致，也可判 为断站。要特别注意“隐型的断站”，从基站的工作状态看是正常的，又没有严重的告警，对于维护部门来说难以判断更需要我们的配合与处理。隐型断站 一般是在参数修改时由于偶然原因造成BSC参数数据库与BTS或BSC内其它单元或模块间的数据不一致，造成基站无法提供服务。由于“隐型断站”没有明显告警，可以从统计中检出工作状态正常而话务量为零站，判为“隐型断站”。 检查隐型断站的方法： 从东区来看，NOKIA基站出现7724告警（在无线网络数据库和呼叫控制程序块间存在冲突）时，基站实际无法提供服务，可判断为隐型断站； 用“ZERO”指令看TRX状态时，最后出现提示“CONFLICT BETWEEN DATABASE AND RRMPRB”，通常整个基站不能提供服务，可判为隐型断站； 3）当基站的信道没有闭塞，而话务量为0时，多为隐型断站； 隐型断站产生的原因主要是有两种： BSS无线网络数据分配到BTS时出错； 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信道数相比很小，则此小区一定存在问题，需要仔细剖析该小区，然后根据具体情况，采取必要措施 高TCH拥塞小区分析任务流程：