沧州RNC251及RNC253 CPU降负荷措施及效果.docVIP

沧州RNC251及RNC253 CPU降负荷措施及效果【摘要】每逢重大节假日，大型活动（运动会、重大会议、突发事件）等可能导致业务量激增超过了网络设计的极限，尤其是2013年W网业务剧增，引发W网侧RNC层面负荷过重告警，沧州市分公司根据现场情况做出合理应对方案，确保用户对公司优质服务感知。 【关键词】WCDMA移动通信网络，业务量激增，RNC层面负荷，应急流程与方案 一、春年等重大节假日突发事件导致业务激增的表现 1、可能导致话务量激增的主要业务类型：大量的CS呼叫尝试；大量的PS呼叫尝试；短信或群发短信激增； 2.系统严格区分拥塞和过载，拥塞不对RNC的系统稳定性造成影响，RNC无法通过自动调节缓解拥塞，常见的拥塞有：个别基站拥塞（功率资源，码资源，CEM 资源）导致接入困难。RNC的Iub带宽不够导致Iub口拥塞，从而导致低优先级的消息被丢弃，上网速率慢，OAM消息被丢弃。 3.过载可能损害RNC的系统稳定性。RNC内部有很强的自动过载处理机制，这些应急处理都是围绕RNC的TMU/RAB/PMCM/NI的过载展开的，监控的主要是CPU load、内存、消息队列。RNC内部设置了不同的门限以采取不同的措施，这些门限不允许修改。RNC的每块DCPS板卡上都运行一套定义好的PMC软件构件，由其任务决定每个PMC上运行何软件。RNC所支持的PMC任务包括：Master （PMC-M）、协议转换 （PC）、无线接入承载（PMC-RAB）、网络接口（PMC-NI）、传输管理单元 （PMC-TMU）、OAM 管理单元 （PMC-OMU）。常见的过载有：RNC的TMU信令处理板卡CPU load超过80%。RNC RAB业务流量板卡CPU load超过80%。 4.过载可能引起的并发故障和客户影响： 【投诉量增加】从counter里面看到的RAB或TMU的CPU load超过80%（15分钟或者1小时的平均值）就会有强烈的客户感知，投诉会增加，尤其是沧州的RNC251所辖的任丘、肃宁2013年春节初一下午由于TMU负荷增加达到80%以上，严重影响到了客户的感知，导致这一时段的投诉量激增。 【手机反应变慢】为了避免接入失败的用户反复尝试接入，加重RNC负担，RNC通过延缓回复手机消息的方法，拖延手机的时间，使得被拒绝的手机呼叫需要等待15秒才能再次起呼。由于这个功能受手机软件的影响，实际效果可能无法拖延这么久，对问题裨益不大。 【主叫无法接入】RNC内部在TMU CPU负荷到达85%（瞬时值）的时候随机拒绝50%的用户接入请求， RAB的CPU超85%的时候拒绝20%的用户接入，这会直接导致许多电话接入失败，在2013年春节初一下午在泊头实际测试时发现部分站点与时段12次通话仅有7次可以接通。 【被叫接不通】RNC内部在TMU CPU负荷到达85%的时候随机丢弃50%的寻呼消息。 【call trace丢失】RNC内部的call trace将会停止。 【无法上网】RAB负荷达到85%的时候，不要求实时性的background上网业务将会被停止。 二、2013年春节期间RNC251和RNC253CPU降负荷处理过程 由2013年春节期间沧州4个RNC每天的最大TMU负荷走势可以看出一般情况下从农历腊月二十一开始话务量呈现递增的趋势，到腊月二十八或者二十九达到峰值。通过降负荷操作，RNC251在腊月二十九出现下降，RNC253在腊月二十七出现下降。 下面详细描述RNC251和RNC253春节期间的负荷走势情况和处理后效果。 1.RNC251 CPU高负荷处理过程。为了应对可能出现的RNC251过载，在春节期间我们进行了以下操作：1.6号修改nrOfPagingRepetitions从3改为1，增大RNC寻呼容量，以应对春节期间寻呼量的突然增加。2.7号准备好修改2D/2F的workorder（使用户更容易切向2G）， 修改2D/2F主要目的是在RNC负荷突然增加的情况下，为了避免由于负荷太高而引的网络问题，而进行应急措施。修改后用户更容易切换到GSM，从而降低WCDMA网络的RNC负荷，用于应急时导入。3.8号早忙时TMU最大负荷接近80，修改T1/T2值，准备好重选的workorder（使用护更容易重选到2G）并且导入，并且将部分修改基站D/2F值的workorder导入。4.9号RNC251最大TMU负荷从8号早忙时的77.5下降到66，下降幅度为7到10，效果明显。5.正月十六过后将春节期间所有降负荷操作恢复。春节期间RNC251 TMU CPU最大负荷走势持续攀升，至2月8号达到最大值80%。在修改参数后负荷下降到65%左右，达到设备允许的