网络优化技术方案-通信保障方案制订

通信保障方案制订通信保障是日常优化中的重要组成保证部分，通信保障主要包括重要节假日以及重大活动的通信保障。对于重大节假日以及重大活动的保障涉及到应急保障手段的制定执行、现场突发情况的处理。通信保障方案的制定将直接关系网络指标以及现场用户的感知，所以对通信保障方案进行科学的预估，现场要准备严格执行并及时监控应对突发并在活动结束后进行网络恢复。实施方案通信保障流程其中质量把控点主要有三个，分别为在负荷分析的准确性，保障方案的合理性，应急保障处理的及时性。保障测试与保障方案通信保障参数和设备故障检查大型集会及重大节假日前的参数检查指导针对2、3、4G网络的需求制定相应的保障方案；内容主要包括：1、资源调整核查；2、参数核查（半速率、接入、切换、234G互操作参数等）；3、邻区核查与调整（包括网内与网间）。大型集会及重大节假日前的设备检查指导eNodeB设备状态检查在大型集会及重大节假日前，在eNodeB侧需要重点检查以下设备状态：1、系统模块状态检查；2、网管通道状态检查；3、接口状态检查；4、小区状态检查；5、风扇的运行情况检查；6、GPS天线检查；7、单板状态检查表；8、天馈线检查；9、系统时钟检查。eNodeB设备告警检查在大型集会及重大节假日前，在eNodeB侧需要重点检查以下设备告警，并根据告警处理步骤及时进行处理：1、工作电源告警；2、风扇运行告警；3、GPS天线告警；4、单板状态告警；5、天馈线告警；6、功放告警；7、RRU驻波比告警。网络负荷分析1、资源容量评估识别当前网络大话务的容量风险，为网络优化调整提供输入。所有风险都要基于容量评估的结论，必须重视。2、话务预测话务预测为后续的容量风险评估提供输入，是关键环节之一。LTE系统资源（包括单板CPU和空口资源）的开销跟在线用户数呈正比关系，因此大话务场景下资源容量的评估可基于用户数完成，该文档中话务预测特指用户数（L.Traffic.User.Avg）的预测。首先预估整个保障区域平均在线用户数规模，然后预测保障区域中每小区平均在线用户数规模，最后根据小区和单板的配置关系累加得到每基带板、每主控板的平均在线用户数。（1）保障区域总体话务预测总体话务预测分为基于历史数据的话务预测和无历史数据的话务预测。建议首先采取前者来获得更为准确的预测结果。（2）小区话务预测小区话务预测通常有三种方法：基于历史话务分布；基于预估人群集中区域；基于人群均分的原则预估各小区话务。从准确性来讲，方法1）到方法3）依次降低，但实施难度也依次降低。3、分析结果网络健康检查通过维护SOP巡检，排除保障站点可能存在的设备状态异常和KPI异常。软件中心->版本软件->无线->无线网管系统(868)->MAINEX(207)要求检出的问题要全部清理。容量风险评估基于话务预测章节预测出的小区、单板（基带、主控）的平均在线用户数，结合类似事件或当前网络的话务模型，评估当前的硬件配置（主控板、基带板、小区数量）和软件资源（License用户数容量）是否能承载预期话务。若不能承载，需给出明确的扩容建议。容量风险评估逻辑流程如下：（1）硬件容量评估硬件容量评估是基于现网数据，预估主控板或基带板过载时的用户数门限。理论分析和经验数据都表明，单板CPU负荷随在线用户数增加呈现线性增长的趋势，因此基于现网数据得出的线性增长规律可以用来预测单板风险。数据的选择原则为：若该区域最近3个月内有高话务站点单基带板平均在线用户数超过100，则选用3~5个此类站点数据；若不满足条件1），则选择其它区域类似场景（如都是足球比赛）中单基带板平均在线用户数超过100的站点数据；若条件1）、2）都不满足，则选择全网最高话务3~5个站点数据。另外，为获取更多数据样本点以使得统计规律更为准确，建议使用15分钟粒度的话统数据。（2）CPU利用率当CPU峰值利用率达到90%时将触发严重流控导致KPI受损，因此容量调整的目的是避免CPU峰值利用率超过90%。然后按照上面计算得到的峰均比计算得到90%峰值利用率对应的CPU平均利用率，即为过载门限。例如统计得到峰均比为1.5，则过载门限即为60%（=90%/1.5）。（3）License容量评估License在线用户数受限将导致ERAB建立失败。接入失败的用户业务需求得不到满足必然反复重试，会增加大量接入信令，从而增加CPU和空口资源的开销。该风险一定要避免。4、负荷优化方案扩容建议主控板的扩容方案有：换用UMPT、双主控、站点分裂。扩容演进原则如下：如果评估主控板需要扩容，则根据当前配置情况选择后一种演进方案。例如当前是LMPT，则建议换用单UMPT。建议在保障期间license在线用户数申请最大值10800。引导客户首先是购买保障license，如果不行，在应急场景下使用临时license。注：License在线用户数是指如下控制项：编号名称中文LLT1ACTU01RRC连接用户数（每RRC连接用户数）英文LLT1ACTU01RRCConnectedUser(perRRCConnectedUser)保障参数策略接入参数优化由于活动保障的小区可能会突发高话务量、极端情况下还需要考虑会产生信令浪涌问题。都可能导致系统负荷瞬间极具增大，带来系统安全隐患。因而需要修改一些继而参数，以降低高信令时的系统负荷。算法参数分类参数算法名称作用建议设置值实施时间和范围建议实施范围信令接入及承载优化T300提高T300的时间，可以降低一定时间内RRC建立尝试次数1.5短时热点保障拥塞风险小区T302提高T302的时间，可以降低一定时间内RRC建立尝试次数16短时热点保障存在拥塞小区CFI设置CFI固定设置为3，保证PDCCH信道资源3短时热点保障存在拥塞小区PUCCH资源自适应PUCCH资源自适应开关打开，保证PUCCH信道资源OFF保持关闭状态不变保障相关小区UE非激活定时器根据RRC建立次数受限还是用户数受限做相应的提高和降低（提高可以减少RRC建立次数，降低可以减少一定时段的在线用户数）10短时热点保障保障相关小区acbarringfactor通过减小该参数，可以减少一定时间内的RRC建立尝试次数0.95（0.7）短时热点保障存在拥塞小区小区接纳控制算法小区接纳控制算法达到接纳控制门限禁止用户接入常开保障相关小区（1）PUCCH资源自适应，即根据用户数的多少，动态分配PUCCH的PRB资源，用户数越多，PUCCH的PRB资源占用也就越多，我的建议是关闭PUCCH资源自适应功能，理由如下：用户数多，需要的PUCCH的PRB资源也多，因此没有必要配置动态PUCCH资源，以减轻系统的处理负荷；同样的道理，用户数多的情况下，需要的PDCCH资源也多，因此我们将CFI固定为3，也是出于相同的考虑；根据规范定义，某个UE的PUCCH所采用的PRB资源是由该UE的PDCCH的CCE首位置决定的。CFI的大小决定了CCE的多少，从而进一步决定了PUCCH所需的最大PRB数量，现在CFI固定为3，PUCCH所需的PRB数量也固定下来了，因此也没必要配置动态PUCCH资源。（2）小区接纳控制算法：当小区达到最大用户数后，若该小区下还有其他未接入的UE，这些UE还会发起RRCConnectionRequest，这样的RRC建立肯定会被拒绝，现在采取的应对方法是：a）增加T302，以增加UE重发RRCConnectionRequest的时延，从而减少RRCconnectionRequest消息的个数；b）开启AccessBarring功能，从而减少RRCconnectionRequest消息的个数。除非开启负载均衡功能，否则系统侧没有专门的接纳控制算法。话务均衡保障方案不变化小区功率，通过重选和切换参数实现负荷向相邻小区分流。高负荷小区只在邻小区低于其负荷门限时才可分流。负荷均衡算法调整:应用场景：F+D共站址小区间；F+D共覆盖热点区域；开启X2切换非共址小区。负荷均衡是用来平衡小区间、频率间和无线接入技术之间的负荷，可以平衡整个系统的性能，提高系统的稳定性。功能是根据服务小区和其邻区负荷状态或者用户数情况合理部署小区运行流量，有效地使用系统资源，以提高系统的容量和提高系统的稳定性。目前中兴机型双载波同覆盖的负载均衡是以PRB利用率为条件触发，当一个小区的负荷PRB利用率达到70%时，且邻区PRB利用率低于65%，负荷均衡功能将被启动。华为机型双载波同覆盖的负载均衡是以用户数为触发条件，当一个小区的用户数达到40个，且邻区用户数低于20个，负荷均衡功能将被启动（门限可调整）。华为机型负荷均衡参数：华为参数华为参数名称MML分类推荐值异频MLB开关InterFreqMlbSwitchMODCELLALGOSWITCHMLBInterFreqMlbSwitch-1负载均衡触发模式MLBTRIGGERMODEMODCELLMLBMLBUE_NUMBER_ONLY异频负载均衡用户数门限INTERFREQMLBUENUMTHDMODCELLMLBMLB40负载均衡用户数偏置MLBUENUMOFFSETMODCELLMLBMLB20基于负载的异频RSRP触发门限(毫瓦分贝)INTERFREQLOADBASEDHOA4THDRSRPMODINTERFREQHOGROUP异频切换-99基于覆盖的异频RSRP触发门限(毫瓦分贝)INTERFRQQHOA4THDRSCPMODINTERFREQHOGROUP异频切换-95中兴机型负荷均衡参数：MO对象名短名参数名称（中文）参数涵义取值范围调整前调整后负荷均衡参数配置ucLBSwch负荷均衡算法开关小区负荷均衡算法开关，它决定了本eNB是否使用负荷均衡功能，以及选择采用盲切换的方式还是采用基于事件测量的切换方式。0:算法关闭(Close)Close[0]21:采用盲切换的方式2:采用基于事件测量的切换方式负荷均衡参数配置ucUlPRBLBExeThrdZ上行ZTE无线负荷均衡执行门限用于执行小区上行方向ZTE无线负荷均衡功能。当LTE服务小区在统计窗长时间内上行PRB的平均使用率大于这个门限值时，本小区执行上行ZTE负荷均衡。[0,100]unitpercent6530负荷均衡参数配置ucDlPRBLBExeThrdZ下行ZTE无线负荷均衡执行门限用于执行小区下行方向ZTE无线负荷均衡功能。当LTE服务小区在统计窗长时间内下行PRB的平均使用率大于这个门限值时，本小区执行下行ZTE负荷均衡。[0,100]unitpercent6530负荷均衡参数配置ucUlIntraNeighborLoadThrd上行Intra-LTE邻小区过负荷门限用于判断Intra-LTE相邻小区的上行负荷水平。当Intra-LTE相邻小区上行PRB使用率的值高于这个门限值时，则不将该小区作为Intra-LTE负荷均衡的候选目标小区。[0,100]unitpercent6025负荷均衡参数配置ucDlIntraNeighborLoadThrd下行Intra-LTE邻小区过负荷门限用于判断Intra-LTE相邻小区的下行负荷水平。当Intra-LTE相邻小区下行PRB使用率的值高于这个门限值时，则不将该小区作为Intra-LTE负荷均衡的候选目标小区。[0,100]unitpercent6025事件判决的RSRP门限(dBm)thresholdOfRSRP事件判决的RSRP门限(dBm)测量时服务小区事件判决的RSRP绝对门限,用于A1，A2，A4，A5事件的判决long:[-140~-43];default:-75-90-90保障测试保障前测试保障测试主要是对各类活动现场进行测试，保障各类活动能够正常度过。保障测试由前台测试组对现场进行全方位DT和CQT摸底测试以便了解活动现场的2、3、4G网络覆盖情况和存在的问题点。在确认活动现场存在的问题点后制定相应的解决方案并跟踪执行。调整后进行复测试验证调整效果。对活动现场进行测试，反馈活动现场是否存在问题点（如质差、小区过覆盖、弱覆盖等情况），若存在能现场解决的现场解决，不能现场解决的纳入问题跟踪表跟踪处理直至解决。活动时的现场保障（1）前台测试人员提前2小时抵达活动现场并对现场进行各项测试，并向保障负责人反馈测试情况；有应急通信车的需要在应急通信车开启后进行测试；（2）后台人员提前观察当天要举办活动的占用小区各项指标、告警，并向保障负责人反馈监控情况；活动开始后对各小区进行实时监控。性能监控开展性能指标、CPU负荷、用户量以及基站状态监控工作，针对网络负荷、硬件故障等分场景进行应急保障工作。性能指标监控：对10项性能指标进行监控，异常告警门限如下：E-RAB拥塞次数RRC拥塞次数RRC建立成功率z(%)E-RAB建立成功率z(%)E-RAB掉线率z(%)无线接通率z(%)无线掉线率z(%)切换成功率z(%)10010090%90%1%90%1%90%CPU负荷监控：对基带板、主控板CPU负荷进行时时监控，异常告警门限如下：主控板总CAPA基带板总CAPS60%60%用户数量监控：对小区平均激活用户数、最大激活用户数进行监控，用户量告警门限如下：平均激活用户数最大激活用户数150200小区状态监控：对现网基站状态进行监控，对于出现告警站点，及时告知维护人员进行处理，保障基站稳定运行。应急预案在值守开始前要预先制定应急预案，并拉通相关资源进行演练，确保问题能够有序高效的处理。应急预案主要分为以下场景：告警应急处理活动过程中，需要关注的告警如下：类型告警名称告警ID触发原因处理建议CPU过载单板过载告警ALM-26202当单板处理芯片占用率过高时，产生此告警。1）如果确定是业务量导致的（比如用户数接近规格），进行处理；2）如果不是，建议重启单板；3）如果仍不能恢复，需要更换单板。硬件故障单板硬件故障告警ALM-26200单板硬件故障时，产生此告警。建议首先重启单板；如果仍不能恢复，需要考虑更换单板。License容量不足系统超出License容量限制告警ALM-26812当网元系统业务量持续超出License容量限制（可设置）时，产生此告警。当网元系统业务量持续低于License容量限制的90%时，恢复该告警。与客户沟通，启用固定期限/紧急License。传输拥塞SCTP链路拥塞告警ALM-25889当SCTP发送缓存被大量需要重传的数据占用，占用比例达到整个发送缓冲区的拥塞产生门限时，产生此警。如是用户数引起，需要进行用户数制；尝试重置SCTP链路；重启单板。小区状态小区不可用告警ALM-29240当基站检测到小区不能提供业务时，产生此告警。重启基站。小区无话务量告警ALM-29242当eNodeB检测到小区在设置时间内无用户接入时，产生此告警。重启基站。小区服务能力下降告警ALM-29243当基站射频资源或基带资源不能满足当前小区的配置规格时，产生此告警。依据告警帮助进行处理。KPI观测监控上文中给出的KPI。CPU观测按照上文中给出的方法监控CPU负荷。问题处理首先按照事先准备的应急预案处理恢复。若不能取得理想效果，联系电话值班人员进行问题分析处理。KPI通报值守期间需定期发送KPI监控数据。以便于相关保障值守人员及时了解详细情况，可提升问题响应速度。该环节务必执行到位。现场人力情况，可考虑每30或60分钟发送一次。数据收集值守期间及时备份日志数据非常重要，因为高话务期间日志数据量大，保存时间短。若不及时备份，一旦事后出现问题，或有其它类似的数据分析需求，很可能面临无日志可参考的困境。为避免该问题，需要在每天保障结束后导出保障站点的主控一键式日志。主控一键式日志的导出对主控CPU占有率有影响，因此必须在话务回落后执行。建议等到主控CPU峰值占有率低于50%后。主控一键式日志文件较大，如果保障区域站点众多，可只备份话务最高的TOP3站点。另外，保障站点的配置文件也一并提取。RRC建立成功率急剧恶化应急处理入口条件单次15分钟话统发现RRC建立成功率急剧恶化（恶化程度已经超过客户预期。如果客户没有明确预期，建议门限为90%）。RRC建立成功率应急措施总体处理流程如下：各环节判断方法及详细处理建议参考如下。现象原因确认方法处理建议RRC建立成功率恶化无线资源受限L.RRC.SetupFail.ResFail有大量统计判断是否用户数规格受限。用户数超过小区/单板规格L.RRC.SetupFail.ResFail.UserSpec统计值占L.RRC.SetupFail.ResFail的大部分。1.修改T302定时器到16s。2.考虑收缩覆盖。将RS功率降低3~6DB以收缩覆盖。但该措施有可能对同频邻区，及同覆盖的异频/异系统邻区带来短时话务冲击，并可能出现覆盖盲区从而部分用户完全失去服务，具体影响可联系当地RF团队评估。3.启用ACBAR。该措施不会对邻区产生话务冲击，但会增加本小区全部用户的接入时延。执行如下两条命令，如果执行下面的命令后用户数仍然超，可以把第二条命令中黄色标识的参数接入概率进一步降低，延迟时间进一步拉长。用户数未超过规格，或无法判断。L.RRC.SetupFail.ResFail.UserSpec统计值只占L.RRC.SetupFail.ResFail的小部分。检查并确认如下资源自适应开关已全部打开：SRI资源自动调整；PUCCH资源自动调整；CQI周期自动调整；SRS周期自适应调整；SRS子帧配置重配开关调整；恢复SRS子帧配置（SrsSubframeCfg）为默认配置。MME过载L.RRC.SetupFail.Rej.MMEOverload有大量统计。降低接入次数。有大量Msg3因流控而被拒绝或丢弃。L.RRC.ConnReq.Msg.disc.FlowCtrl或L.RRC.SetupFail.Rej.FlowCtrl有大量统计；判断是否CPU过载。CPU负荷较高导致Msg3被丢弃或拒绝跟踪或话统查询到主控或基带板CPU最大占有率超过80%；或者基站上报单板过载告警；1.如果是基带板过载，直接关闭DRX；如果是主控板过载，将DRX进入退出门限配置为1000，或直接关闭DRX。2.降低接入次数。干扰抬升，空口恶化.以下两个条件同时满足：L.RRC.SetupFail.NoReply有大量统计；L.UL.Interference.Avg抬升超过20DB；实施干扰抑制措施，包括：开启上行干扰随机化；关闭同频邻区的下行频选；限制PUSCHRSRP上门限。若不能达到预期效果，考虑收缩覆盖，将RS功率降低3~6DB以收缩覆盖。具体影响及MML请参考该表1.1节措施。ERAB建立成功率急剧恶化应急处理入口条件单次15分钟话统发现ERAB建立成功率急剧恶化（恶化程度已经超过客户预期。如果客户没有明确预期，建议门限为90%）。ERAB建立成功率恶化应急措施总体处理流程如下：各环节判断方法及详细处理建议参考如下。原因确认方法处理建议1.传输原因导致ERAB建立失败L.E-RAB.FailEst.TNL有大量统计；判断是否传输拥塞。1.1传输拥塞导致ERAB建立失败有SCTP链路拥塞告警；按照如下方法限制接入次数，缓解SCTP拥塞：1.修改T302定时器到16s；2、考虑收缩覆盖。将RS功率降低3~6DB以收缩覆盖；3.启用ACBAR。该措施会增加本小区全部用户的接入时延。执行如下两条命令，如果执行下面的命令后用户数仍然超，可以把第二条命令中黄色标识的参数接入概率进一步降低，延迟时间进一步拉长。2.MME原因导致ERAB建立失败L.E-RAB.FailEst.MME有大量统计判断是否干扰太大。2.1干扰导致空口消息交互延迟，MME定时器超时先释放L.UL.Interference.Avg抬升超过20DB；实施干扰抑制措施，包括：上行干扰随机化；关闭同频邻区的下行频选；限制PUSCHRSRP上门限。若不能达到预期效果，考虑收缩覆盖，将RS功率降低3~6DB以收缩覆盖。3.无线侧信令交互失败导致ERAB建立失败L.E-RAB.FailEst.NoReply或L.E-RAB.FailEst.SRBReset有大量统计判断是否干扰太大。3.1干扰导致空口信令交互失败判断是否干扰太大。参考该表2.1节措施处理。4.无线资源不足导致ERAB建立失败L.E-RAB.FailEst.NoRadioRes有大量打点按照该表4.1节继续判断是否用户数或流量license受限4.1用户数或流量license受限基站上报license容量超限告警（ALM-26812）或基站所有小区最大在线用户数（L.Traffic.User.Max）之和超过License用户数规格的90%；先考虑加载临时License；或启用紧急状态License；若上述措施无法执行，参考1.1的措施限制用户接入。4.2用户数或流量license未受限以下条件都不满足。基站上报license容量超限告警（ALM-26812）；基站所有小区最大在线用户数（L.Traffic.User.Max）之和超过License用户数规格的90%；