时间：2022-08-27 08:21:50
【摘要】每逢重大节假日，大型活动（运动会、重大会议、突发事件）等可能导致业务量激增超过了网络设计的极限，尤其是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%左右，达到设备允许的预期要求。
2.RNC253 CPU高负荷处理过程。为了应对可能出现的RNC253过载，在2013年春节前我们提前进行了以下操作：（1）6号修改T2值。（2）6号将基站话务量从高到低进行排序，当RNC负荷增长达到一定程度，修改部分基站的32G重选门限，使更多的用户占用2G网络，将所有小区分批次做好WO视网络负荷走势决定是否导入。（3）6号准备好部分高负荷基站，当区域办法不凑效时直接关闭部分基站。（4）6号RNC253的TMU CPU最大负荷达到84，为了防止RNC启动自我保护机制，可能出现的RNC荡机、信令丢弃造成接通率骤降等问题，我们在7号凌晨对RNC253进行紧急DCPS板卡扩容，将该RNC下话务量最高的基站部分基站割接到新插入的板卡上，效果改善明显，第二天（腊月二十七）最大TMU负荷下降到70，即使在话务量最高的腊月二十九TMU负荷仍旧小于80。（5）正月十六过后将所有相关操作恢复。
春节期间RNC253TMU CPU最大负荷连续走高在2月6号达到最大值85%。在修改参数后负荷下降至73%左右，使得网络运行在安全范围内。
三、RNC CPU降负荷措施
春节期间通过各项操作，总结出以下降负荷措施：
1、硬件调整对现网影响最小的优化方案。（1）紧急扩容：通过扩容DCPS板卡是解决此问题的最彻底的方案；（2）调整负荷：通过检查各个TMU上的负载是否均衡，如果有显著差别，可将业务量较大的基站更改ServiceGroup，也可完成负荷分担。通过参数调整完成负荷调整方案。（1）延长AO timer，可以降低TMU load但会导致RAB load升高；（2）修改寻呼paging消息的重发次数为，减少业务的处理，同时也能减少业务量，但可能有部分用户不容易接通；（3）修改3G切换到2G的门限，让更多的手机驻留2G；（4）如果DCPS满配，可以打开Feature把RAB转换成TMU使用；
采用紧急措施，牺牲部分基站业务，关掉几个高业务量的基站，但影响用户感知，但杀伤性较强；
使用IMCTA Feature把业务直接重定向到2G，支持紧急呼叫、小区负载高、所有语音电话切换到2G。