《淄博移动LTE网络春节保障方案》由会员分享，可在线阅读，更多相关《淄博移动LTE网络春节保障方案（18页珍藏版）》请在金锄头文库上搜索。
1、淄博移动LTE网络春节保障方案1 概述为避免在春节期间人口聚集、话务量激增对基站及EPC造成巨大冲击（如：接入成功率、掉话率、用户体验速率等KPI下降），拟定该春节保障方案，应对话务量激增场景，保障网络正常运行。具体节日保障措施、流程如下图所示：上图给出保障各环节，现场根据实际情况（如时间、人力等）排定各环节实际可完成时间，明确计划。保障项目启动后按照一定频度审视各环节进展情况。确保各项工作如期、保质完成。2 节前准备措施节前准备措施是大话务保障项目中最重要的环节，也是整个保障环节中投入精力最多的环节。节前准备包括资源容量评估、网络健康检查、网络调整、制定应急预案，以及保障准备。大话务场景下的
2、风险，具体来讲主要有两类：一是随用户数增加，信令数量显著增加，可能出现单板CPU过载并触发流控，从而导致KPI显著恶化。二是在同频连续组网场景下，随着邻区话务量的增加，同频邻区之间的干扰可能显著抬升，带来空口频谱效率的恶化，加之空口业务需求的增加，空口可能出现严重拥塞，导致用户感知速率快速下降。节前准备阶段通过扩容及RF优化等措施可有效降低单板CPU过载和同频干扰风险，需重点关注。2.1 资源容量评估识别当前网络大话务的容量风险，为网络优化调整提供输入。所有风险都要基于容量评估的结论，必须重视。2.1.1 话务预测话务预测为后续的容量风险评估提供输入，是关键环节之一。LTE系统资源（包括单板C
3、PU和空口资源）的开销跟在线用户数呈正比关系，因此大话务场景下资源容量的评估可基于用户数完成，该文档中话务预测特指用户数（L.Traffic.User.Avg）的预测。首先预估整个保障区域平均在线用户数规模，然后预测保障区域中每小区平均在线用户数规模，最后根据小区和单板的配置关系累加得到每基带板、每主控板的平均在线用户数。（1）保障区域总体话务预测总体话务预测分为基于历史数据的话务预测和无历史数据的话务预测。建议首先采取前者来获得更为准确的预测结果。（2）小区话务预测小区话务预测通常有三种方法：1） 基于历史话务分布；2） 基于预估人群集中区域；3） 基于人群均分的原则预估各小区话务。从准确性
4、来讲，方法1）到方法3）依次降低，但实施难度也依次降低。提取最近时间段内的用户使用情况如下附件：（3）单板话务预测l 按照当前配置查询得到每个基带板配置了哪几个小区，将这几个小区预测的平均在线用户数相加就得到了预测的该基带板的平均在线用户数；l 将该基站所有小区预测的平均在线用户数相加就得到了预测的该主控板均在线用户数。2.1.2 容量风险评估基于2.1.1话务预测章节预测出的小区、单板（基带、主控）的平均在线用户数，结合类似事件或当前网络的话务模型，评估当前的硬件配置（主控板、基带板、小区数量）和软件资源（License用户数容量）是否能承载预期话务。若不能承载，需给出明确的扩容建议。容量风
5、险评估逻辑流程参考如下：（1）硬件容量评估硬件容量评估是基于现网数据，预估主控板或基带板过载时的用户数门限。理论分析和经验数据都表明，单板CPU负荷随在线用户数增加呈现线性增长的趋势，因此基于现网数据得出的线性增长规律可以用来预测单板风险。数据的选择原则为：1） 若该区域最近3个月内有高话务站点单基带板平均在线用户数超过100，则选用35个此类站点数据；2） 若不满足条件1），则选择其它区域类似场景（如都是足球比赛）中单基带板平均在线用户数超过100的站点数据；3） 若条件1）、2）都不满足，则选择全网最高话务35个站点数据。4） 另外，为获取更多数据样本点以使得统计规律更为准确，建议使用15
6、分钟粒度的话统数据。（2）CPU利用率当CPU峰值利用率达到90%时将触发严重流控导致KPI受损，因此容量调整的目的是避免CPU峰值利用率超过90%。然后按照上面计算得到的峰均比计算得到90%峰值利用率对应的CPU平均利用率，即为过载门限。例如统计得到峰均比为1.5，则过载门限即为60%（= 90% / 1.5）。扩容建议主控板的扩容方案有：换用UMPT、双主控、站点分裂。扩容演进原则如下： 如果评估主控板需要扩容，则根据当前配置情况选择后一种演进方案。例如当前是LMPT，则建议换用单UMPT。（3）License容量评估License在线用户数受限将导致ERAB建立失败。接入失败的用户业务需
7、求得不到满足必然反复重试，会增加大量接入信令，从而增加CPU和空口资源的开销。该风险一定要避免。建议在保障期间license在线用户数申请最大值10800。引导客户首先是购买保障license，如果不行，在应急场景下使用临时license。注：License在线用户数是指如下控制项：编号名称中文LLT1ACTU01RRC连接用户数（每RRC连接用户数）（FDD）英文LLT1ACTU01RRC Connected User(per RRC Connected User)容量受特性影响风险评估某些特性可能导致LTE系统容量发生显著变化，在资源容量评估环节需特别加以注意。现在已知的是SFN。2.2
8、网络健康检查通过维护SOP巡检，排除保障站点可能存在的设备状态异常和KPI异常。软件中心-版本软件-无线-无线网管系统(868) -MAINEX(207) 要求检出的问题要全部清理。 2.3 网络调整优化2.3.1 扩容实施根据硬件容量评估结果进行资源调整，包括板间负载均衡、双主控、以及其它扩容策略，包括加站、换板、小区分裂等。此次淄博针对春节大话务情况对19个公网D频段小区和室分8个E频段小区进行了扩容操作。如下表所示：2.3.2 版本升级基于话务预测结果和实际保障经验，如果预计单小区峰值在线用户数将超过400，建议升级到大话务性能最优的版本，目前淄博移动LTE网络已经完成公网和高铁的版本升
9、级。公网升级至eRAN7.0 SPC175，高铁升级至eRAN8.0 SPC120版本。2.3.3 负载均衡从ERAN7.0版本开始，异频MLB算法逐渐成熟并开始在大话务保障中应用。异频MLB按照触发方式，分为基于PRB利用率和基于用户数两种，图示如下：在重大事件场景下，大流量用户比例非常低，基于PRB利用率的MLB难以选出足够数量的用户执行负载均衡，效果不理想，因此推荐基于用户数的MLB。异频MLB按照执行方式，分为连接态MLB和空闲态MLB两种。图示如下：连接态MLB适用于各种覆盖场景，但却有切换信令开销，在高话务场景下对CPU和空口资源开销有一定影响。因此在适用空闲态MLB的覆盖场景下优
10、先推荐空闲态MLB。大话务常见的覆盖场景以及对应的MLB推荐策略如下： 场景推荐策略场景一：1. 负载均衡小区共覆盖区域（同站全共覆盖或异站部分共覆盖）；2. 负载均衡的某个目标频点就一个小区（例如：Fre1Freq2互相均衡时，Fre1和Fre2频点小区都只有一个）；3.不同频点带宽大小差异无要求；4.终端渗透率无要求；1. 采用基于用户数的空闲态MLB（要双向配置MLB，即负载均衡的小区要互为均衡）；2. Idle驻留策略无要求，随机或倾向性驻留都可以，可以保持原网配置。场景二：1.同站部分共覆盖区域(某个频点覆盖范围较小且未形成连续覆盖,如仅能覆盖其它频点的30%用户及以下，如宏微异频组
11、网，微站高优先级)；2. 负载均衡的某个目标频点就一个小区（例如：Fre1- -Freq2均衡时，Fre2频点小区只有一个）；3. 不同频点带宽大小差异无要求；4. 终端渗透率无要求；1. Idle态采用倾向性驻留策略，优先驻留覆盖范围小的载波；2. 采用基于用户数的空闲态MLB（要单向配置MLB，覆盖范围小的载波往范围大的载波做均衡）场景三：1. 异站负载均衡小区部分共覆盖区域；2. 负载均衡的某个目标频点有多个小区（例如：Fre1- -Freq2互相均衡时，Fre2频点小区有2个）；3.不同频点带宽大小差异无要求；4.终端渗透率无要求； 1. Idle态采用随机驻留策略；2.采用基于用户数
12、的连接MLB（要双向配置MLB，即负载均衡的小区要互为均衡）Note：此策略，要提前触发MLB，即在低负载的时候，通过连接态负载均衡，使得均衡到低负载的目标小区的用户，在本次业务释放后，下次空闲态发起业务接入时，仍旧从低负载小区接入，最终达到空闲态即可达到均衡的目的；2.3.4 RF优化根据保障经验，影响LTE性能的首要因素是RF覆盖质量。良好的RF覆盖能够保证较高的上下行频谱效率，在频谱资源固定的前提下能够保证较高的小区和用户体验吞吐率。基于历史数据经验，同一个区域的两次活动，当RF优化充分时，话务高峰期邻区间上行干扰可控制在10dB以内；而在RF优化不合理时，同等话务规模时邻区间上行干扰超
13、过20dB。由此带来的下行用户感知速率的差距超过20倍。2.3.5 性能参数优化性能保障参数建议在扩容和版本升级后，活动开始前7天实施，观察实施后KPI是否有异常。如果保障区域在活动开始前完全无话务，则建议在路测之前实施，以便利用路测KPI验证是否有异常。参数调整checklist表如下表所示：2.4 应急预案在值守开始前要预先制定应急预案，并拉通相关资源进行演练，确保问题能够有序高效的处理。应急预案主要分为以下场景：2.4.1 告警应急处理值守期间若出现告警，请按照如下原则进行处理：1) 首先按照告警帮助进行处理（重启和换板措施在本步骤先不考虑）；2) 若不能消除告警，求助产品维护保障值守人
14、员。 2.4.2 RRC建立成功率急剧恶化应急处理入口条件单次15分钟话统发现RRC建立成功率急剧恶化（恶化程度已经超过客户预期。如果客户没有明确预期，建议门限为90%）。应急措施总体处理流程如下：各环节判断方法及详细处理建议参考如下。现象原因确认方法处理建议RRC建立成功率恶化1. 无线资源受限 L.RRC.SetupFail.ResFail有大量统计按照该表1.1 节继续判断是否用户数规格受限。1.1用户数超过小区/单板规格 对于ERAN7.0及之后版本： L.RRC.SetupFail.ResFail.UserSpec统计值占L.RRC.SetupFail.ResFail的大部分； 对于
15、ERAN7.0之前版本，无法快速判断，跳过此环节，转到1.2节。1.修改T302定时器到16s： MOD RRCCONNSTATETIMER: T302=16;2、考虑收缩覆盖。将RS功率降低36DB以收缩覆盖。但该措施有可能对同频邻区，及同覆盖的异频/异系统邻区带来短时话务冲击，并可能出现覆盖盲区从而部分用户完全失去服务，具体影响可联系当地RF团队评估。MOD PDSCHCFG: LocalCellId=X, ReferenceSignalPwr=*;3.启用AC BAR。该措施不会对邻区产生话务冲击，但会增加本小区全部用户的接入时延。执行如下两条命令，如果执行下面的命令后用户数仍然超，可以把第二条命令中黄色标识的参数接入概率进一步降低，延迟时间进一步拉长；MOD CELLALGOSWITCH: AcBarAlgoSwitch=ACBAR_SWITCH_STATIC;MOD CELLACBAR: AcBarringInfoCfgInd=CFG, AcBarringForMoDataCfgInd=CFG, AcBarringFactor
