rsl紊乱导致系统准备失败案例--刘存

《rsl紊乱导致系统准备失败案例--刘存》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、RSL数据紊乱导致小区系统准备失败案例--刘存--案例简述：7月13日值班，在观察下午13时指标时，发现院前_1小区有突发系统准备失败150多次（无拥塞），分配失败率28.04%。可借鉴经验：减容导致RSL数据紊乱问题分析处理：遵循以往坏小区处理流程处理，首先向周围OMCR终端维护人员询问是否上时段对此小区或周边小区做过系统操作，结果是没有人对此小区做过操作。Yuanlin_1小区问题图：TRX信息查看，TRX3载频TCH占用时长只有6.99S，很明显看出比其它的几块载频占用时长短很多；本着先将坏载频LOCK然后更换坏载频的处理流程，到OMCR监控终端，找到

2、该小区后，右键HSDSHynthesis…查看TRX3对应TRE7，然后ShowEquipment准备LOCK坏载频时，却发现yuanqian_1小区并没有TRE7载频，而下面对应的数据链却同时存在TSL3，7看到此情况后，立即给相关基站代维打电话询问是否对此站有过操作，结果此小区之前有闲置的TRE7载频在被LOCK状态，今天去给减掉，所以没有通知上面OMCR终端人员减数据。确认问题起因后到NavigateToAbisview下对该小区数据重新匹配，数据恢复正常数据匹配正常：下时段指标跟踪正常：小区的分配失败简介主要分为三类：无线链路分配失败（MC746b）

3、、系统原因造成TCH准备失败和系统原因造成TCH分配失败。对于系统原因造成TCH分配失败，一般都在修改小区参数时造成，因此，一般不需要做其他操作，只需观察下一时段指标即可，一般在下一时段指标将自动恢复正常；对于无线原因导致的分配失败，需要综合考虑载频分配失败是否集中或分散在N个载频上面，或隐性或有明显的硬件问题等，可结合RMS报告分析。下面详细说明TCH准备失败的解决思路。平时日常指标监控，网优工程师对TCH准备失败的关注力度不够，或根本不做处理，继续跟踪下个时段指标，而事实上TCH准备失败往往次数非常多，十分影响客户感知。针对阿尔卡特设备，分析TCH准备失

4、败可能会由以下几个方面引起，因此解决思路也可以按照以下步骤进行（可能还会有其他原因，以下只是在我实际工作中所积累的经验分析）：（1）拥塞：含切换拥塞可能会造成TCH准备失败较多，往往值班人员在晚忙时监控时会经常遇到。如果小区统计中拥塞次数较高造成分配失败，且MC612a不为0，说明网络中没有开启TCH指配排队功能。排队功能在无线侧是以BSC为单位开启的。通常情况下，交换侧会打开排队指示功能，BSC的排队等待时间T11不设为0的情况下，当无可用TCH资源供分配时，即进入排队等待缓冲区。当交换侧未打开TCH排队功能时，也可以在无线侧开启强制排队开关QueueAn

5、yway。同时，排队等待时长timer由T11改为T11_Forced。加大T11和T11_Forced，可以降低小区的拥塞情况，但可能会增加手机的呼叫等待时间。（1）系统操作：通常情况下如果网优工程师，在上时段对某小区做了参数调整，重启基站坏小区，修改频点等，小区运行在一次停滞后又重新恢复运行的过程中，N多个用户同一时间段占用该小区起呼或切近该小区，都会因此造成下时段的系统准备失败，针对此情况继续观察下时段指标，大部分即可恢复，如果没有恢复可能是因为改频点时出现时小区下挂直放站没有同步的原因，应立即通知代维现场同步；（2）扩减容操作：代维在扩减容时，一个B

6、TS下或有N个小区下N个数据匹配链路，在上一次减容后可能因为数据没有减掉，而在下次扩容后，新扩的载频默认了之前的数据链路，从而导致了载频短时隙分配失败，针对此情况应要求代维现场待命，终端删创小区数据，或由代维现场本调操作，若仍不行，上报局方相关人员对小区删创。（3）硬件隐性故障：上时段这个载频运行一切正常，也许下时段就突发短时隙，也会导致大量的系统准备失败，而网管上和基站内载频都无任何告警，针对此情况应立即LOCK掉相关载频，同时要求代维去现场更换；总结：网优系统监控工程师，肩负的责任重大，不仅需要有处理各项指标（分配失败，掉话，拥塞，干扰，切换）的能力外，

7、还要有持之以恒，不松懈的心理状态。