华为5G性能优化指导手册SA.docx
《华为5G性能优化指导手册SA.docx》由会员分享,可在线阅读,更多相关《华为5G性能优化指导手册SA.docx(21页珍藏版)》请在冰豆网上搜索。
华为5G性能优化指导手册SA
华为5G网管性能问题分析手册-SA
概述
目前全省各地市已完成SA商用测试,除了从日常测试与投诉中发现网络存在“点、线”的问题,还需要从性能上发现面上的问题,从而使得NSA网络正常运行,保障5G网络的用户体验感知。
与传统LTE网络一样,需要从“接入性”、“移动性”、“保持性”以及“小区数传能力”几个维度进行性能问题分析定位。
接入性:
无线接通率
移动性:
保持性:
无线掉线率
一、小区接入性能问题
SA组网小区,终端接入5G网络的,主要涉及流程如下:
涉及指标:
无线接通率
计算公式:
无线接通率(NR)=(RRC连接建立成功次数/RRC连接建立请求次数)*(Flow建立成功数/Flow建立请求数)*(NG接口UE相关逻辑信令连接建立成功次数/NG接口UE相关逻辑信令连接建立请求次数)
1.1接入问题规定动作
1.1.1操作日志&告警故障
基站的操作,告警和故障日志可以在U2020和一键式日志内获取,使用FMA可以直接打开,对于操作日志主要排查是否存在影响接入的操作,主要判断问题时间点与操作时间点是否存在相关性;对于告警及故障主要查看问题时间点,是否存在相关未恢复的告警,如小区不可用、X2接口故障等。
1.1.2参数核查
1、通过优化最小接收电平、小区选择参数、小区重选参数、5-4重选参数、邻区核查等手段提升;
参数名称
参数说明
建议值
CoverageScenario
天线覆盖场景
建议使用DEFAULT,可以根据实际覆盖情况进行调整
Tilt
波束物理下倾角
默认3°,增大下倾会缩小小区覆盖范围
SsbPeriod
SSB周期
默认值为20ms,拉长SSB周期可能会导致部分终端无法接入
Sib1Period
SIB1周期
默认值为20ms,拉长SIB1周期可能会导致部分终端无法接入
RsrpThldForSsbSelection
选择SSB的RSRP门限
该参数表示选择SSB时的RSRP门限,配置过高可能会导致终端无法选取合适的小区驻留
MaxPreambleTransCnt
前导最大传输次数
默认为10次,减少前导最大传输次数可能导致接入成功率降低
CellRadius
小区半径
小区半径设置过小可能会导致远点用户接入失败
1.1.3射频通道(发功&上行干扰)排查
上行干扰会影响SRS和PUSCH解调性能,严重影响吞吐率性能。
正常情况下底噪在-116dbm左右,干扰跟踪位于M2000TracingMonitor->NR->CellPerformanceMonitoring.
1.2接入问题定位思路
NR接入问题涉及问题,可见如下思维导图
1.2.1空口未发起RRC_CONN_REQ
基站侧没有收到RRCSetupReq,需要在终端侧观察,终端侧是否有发起RRC接入
可能原因:
Ø小区不可用,核查小区状态和故障告警;
Ø小区状态为BLOCK状态;
ØNG-C链路故障或者未配置;
ØAAU通道校正失败
Ø终端不支持NR频段;
1.2.2NR随机接入失败
当前导致随机接入失败的可能原因有:
Ø弱覆盖或干扰导致随机接入失败,核查问题小区覆盖和干扰情况;
Ø超小区半径接入:
核查问题小区半径设置是否存在异常。
小区半径配置,该配置会影响生成Preamble序列所使用的NCS参数,如果配置过小会导致中远点用户无法接入;
ØPrach参数等配置异常,根序列索引需要进行网络规划,避免周边小区接收到Preamble下发RAR消息,对本小区产生下行干扰
Ø时隙配比和时隙结构配置:
要求全网一致,不一致会有上下行干扰问题,可能导致随机接入异常
1.2.3RRC建立失败
RRC建立失败包括如下三种情况
1、RRCRej:
UU口检查收到RRCSetupRequest,没有下发RRCSetup,下发了RRCSetupRej;
2、RRCNoReply:
UU口检查收到RRCSetupRequest,下发了RRCSetup,但是等待RRCSetupCpmplete超时;或者下发RRCSetup后又立即下发了RRCRel;
3、RRC丢弃:
UU口检查收到RRCSetupRequest后,直接丢弃,没有进行下一步的处理。
当前RRC建立失败的可能原因有:
Ø下行覆盖问题
Ø小区重选参数问题
Ø资源拥塞问题
Ø设备异常问题
1.2.4NGSig建立异常
NGSig问题现象:
1)基站发送初始化UE消息后,但是核心网没有响应任何NAS消息或者上下文建立请求消息或者MME释放上下文消息。
这种场景需要联合核心网一起分析原因。
2)基站发送初始化UE消息后,核心网直接发送NG_RESET释放单用户,导致NGSIG建立失败。
这种场景需要联合核心网一起分析原因。
3)基站收到MSG5消息后,NG链路被闭塞或者内部异常,导致基站没有给核心网发送初始化UE消息。
这种场景需要基站侧分析原因。
NAS问题现象:
1)NAS过程异常,核心网主动释放UE。
2)核心网没有发送UE上下文建立请求,基站主动释放。
原因定位:
Ø基站NG标口无初始化UE消息:
基站或配置问题
Ø基站NG标口有初始化UE消息:
核心网AMF或传输问题
二、小区保持性能问题
2.1保持问题规定动作
2.1.1确定问题类型
KPI类的问题常见有如下四类,需要明确问题类型和目标。
1)KPI指标突然恶化,或者某些时段恶化
2)KPI缓慢变化,逐渐变差
3)当前KPI不达标,需要提升到某个目标值
4)多个区域对比,分析某个区域相比其它区域差的原因
对于第1类问题,重点实施动作4和动作6。
对于第3类和第4类问题,可以不实施动作6。
另外第4类问题的动作5是分析重点,通过找到两个区域其它指标的差异,从正面或者侧面证明网络结构和空口质量的差异,快速的定位问题根因或者完成初步影响因素隔离。
2.1.2时间趋势分析
时间趋势分析主要是分析掉话率公式中涉及的各子Counter的变化趋势和分析恶化时间点是否有规律。
首先是看总的释放次数和异常释放次数的变化是怎样的,是只有异常释放增加,还是正常、异常都同时增加,不过异常增加更快。
还是说异常没怎么变,是正常减少了,导致掉话率抬升。
结合分子、分母的变化,看看是否和用户数变化相关。
分析恶化时间是否有规律,主要是分析指标是持续缓慢下降,还是阶梯式下降,又或者是某些时间下降后又恢复,然后再下降等等。
对于阶梯下降或者反复下降,要看是否固定发生在每天某些小时,或者每周的周几,或者固定在月初月末等等。
天级指标对比时,要注意和其它周相同时间对比,周末和周末对比。
分析话统时要注意分析时间段内,小区个数的变化。
避免由于采集的话统数据不全,小区数量存在较大变化,导致KPI趋势变化,从而误判断。
当发现小区数量差异较大时,首先要找确认反馈数据是否完整,小区数,站点数是否符合预期。
如果数据反馈没有问题,那就说明现网在逐步新增站点,或者关闭站点,导致KPI变化,属于“外部事件”排查的内容。
2.1.3释放原因初步确认
对于异常释放,当前SA如下几种异常释放原因话统,可以初步确认是无线原因,还是传输原因。
N.QosFlow.AbnormRel.RNL
无线层问题导致的QoSFlow异常释放次数
N.QosFlow.AbnormRel.TNL
传输层问题导致的QoSFlow异常释放次数
2.1.4TOPN分析
接下来要确认问题范围是TOP小区问题还是整网问题。
“TOP小区”问题:
分别去除TOP10(可以小区规模设定TOPN个数,例如TOP100)”掉话率TOP小区”和”掉话次数TOP小区”后,如果整网掉话率明显改善且与掉话率恶化前指标基本持平(或者达到了目标值),则定义为TOP小区问题。
“整网”问题:
分别去除TOP10的”掉话率TOP小区”和”掉话次数TOP小区”后,如果整网掉话率没有明显改善,则定义为整网问题。
筛选TOP小区时,要注意排除总的释放次数较少,导致少量异常释放就会出现较高掉话率的情况。
因此要筛选总释放次数达到一定数量的才有统计意义,可以根据现网实际话务水平,选择总释放次数不低于平均值50%的水平作为基础;或者按照单小区1小时总释放次数不低于1000次作为标准。
如果是TOP小区问题,如果排除了操作原因,要从地理位置上看看TOP小区分布位置是否有规律。
如果是传输类问题,要排查TOP小区所在站点传输拓扑结构有没有什么规律,比如共同接入某个传输子节点。
2.1.5关联指标分析
如果根据话统指标隔离到是空口原因掉话,需要分析下空口信道质量和网络负载相关的指标变化。
通过KPI关联分析从正面或者侧面证明网络的变化和差异。
通过不同网络的关联KPI对比,确定网络的限制因素。
通过对象指标和关联指标的耦合性分析,快速的定位问题根因或者完成初步隔离。
常用的关联KPI有:
●切换成功率
切换成功率低,说明UE无法切换到最强小区,容易导致掉话。
因此掉话率高的时候,可以看下切换成功率是否正常。
如果切换成功率低,则参考切换问题分析指导书进行分析。
同频切换成功率:
((N.HO.IntraFreq.Ng.IntergNB.ExecSuccOut+N.HO.IntraFreq.Xn.IntergNB.ExecSuccOut+N.HO.IntraFreq.IntragNB.ExecSuccOut)/(N.HO.IntraFreq.Ng.IntergNB.ExecAttOut+N.HO.IntraFreq.IntragNB.ExecAttOut+N.HO.IntraFreq.Xn.IntergNB.ExecAttOut))×100%
系统内切换入成功率:
((N.HO.Ng.IntergNB.ExecSuccIn+N.HO.IntragNB.ExecSuccIn+N.HO.Xn.IntergNB.ExecSuccIn)/(N.HO.Ng.IntergNB.ExecAttIn+N.HO.IntragNB.ExecAttIn+N.HO.Xn.IntergNB.ExecAttIn))×100%
●初传/重传误码
通过如下指标可以查看下行和上行的误码情况。
对于多个区域对比时,也可以通过评估QPSK的比例间接说明两个区域的覆盖差异。
下行IBLER:
(N.DL.SCH.QPSK.ErrTB.Ibler+N.DL.SCH.16QAM.ErrTB.Ibler+N.DL.SCH.64QAM.ErrTB.Ibler+N.DL.SCH.256QAM.ErrTB.Ibler)/(N.DL.SCH.QPSK.TB+N.DL.SCH.16QAM.TB+N.DL.SCH.64QAM.TB+N.DL.SCH.256QAM.TB)*100%
下行重传率:
(N.DL.SCH.QPSK.TB.Retrans+N.DL.SCH.16QAM.TB.Retrans+N.DL.SCH.64QAM.TB.Retrans+N.DL.SCH.256QAM.TB.Retrans)/(N.DL.SCH.QPSK.TB+N.DL.SCH.16QAM.TB+N.DL.SCH.64QAM.TB+N.DL.SCH.256QAM.TB)*100%
下行RBLER:
(N.DL.SCH.QPSK.ErrTB.Rbler+N.DL.SCH.16QAM.ErrTB.Rbler+N.DL.SCH.64QAM.ErrTB.Rbler+N.DL.SCH.256QAM.ErrTB.Rbler)/(N.DL.SCH.QPSK.TB+N.DL.SCH.16QAM.TB+N.DL.SCH.64QAM.TB+N.DL.SCH.256QAM.TB)*100%
上行重传率:
(N.UL.SCH.HalfPiBPSK.TB.Retrans+N.UL.SCH.QPSK.TB.Retrans+N.UL.SCH.16QAM.TB.Retrans+N.UL.SCH.64QAM.TB.Retrans+N.UL.SCH.256QAM.TB.Retrans)/(N.UL.SCH.HalfPiBPSK.TB+N.UL.SCH.QPSK.TB+N.UL.SCH.16QAM.TB+N.UL.SCH.64QAM.TB+N.UL.SCH.256QAM.TB)*100%
上行RBLER:
(N.UL.SCH.HalfPiBPSK.ErrTB.Rbler+N.UL.SCH.QPSK.ErrTB.Rbler+N.UL.SCH.16QAM.ErrTB.Rbler+N.UL.SCH.64QAM.ErrTB.Rbler+N.UL.SCH.256QAM.ErrTB.Rbler)/(N.UL.SCH.HalfPiBPSK.TB+N.UL.SCH.QPSK.TB+N.UL.SCH.16QAM.TB+N.UL.SCH.64QAM.TB+N.UL.SCH.256QAM.TB)*100%
●上行平均干扰
主要使用平均值对比,最大值是瞬时采样,并且和网络负荷有关,仅供参考。
如果存在持续外部强干扰的话,最小值可能会出现明显差异。
由于话统的干扰粒度较大,当话统看到存在干扰时,基本上可以判断存在干扰。
但是当话统看到不存在干扰的时候,不一定没有干扰。
对于TOP小区,可以通过U2000干扰监测进一步确认是否存在干扰。
●PRB利用率
PRB利用率用来评估网络负载。
PRB利用率高,小区之间下行和上行互相干扰就会更大。
下行PRB利用率:
N.PRB.DL.Used.Avg/N.PRB.DL.Avail.Avg*100%
上行PRB利用率:
N.PRB.UL.Used.Avg/N.PRB.UL.Avail.Avg*100%
●CCE聚集级别
CCE聚集级别高,说明PDCCH信道覆盖较差,或用户分布较远。
通过话统里的各种聚集级别的次数,可以计算平均CCE聚集级别。
下行平均CCE聚集级别:
(1*N.CCE.DL.AggLvl1Num+2*N.CCE.DL.AggLvl2Num+4*N.CCE.DL.AggLvl4Num+8*N.CCE.DL.AggLvl8Num+16*N.CCE.DL.AggLvl16Num)/(N.CCE.DL.AggLvl1Num+N.CCE.DL.AggLvl2Num+N.CCE.DL.AggLvl4Num+N.CCE.DL.AggLvl8Num+N.CCE.DL.AggLvl16Num)
上行平均CCE聚集级别:
(1*N.CCE.UL.AggLvl1Num+2*N.CCE.UL.AggLvl2Num+4*N.CCE.UL.AggLvl4Num+8*N.CCE.UL.AggLvl8Num+16*N.CCE.UL.AggLvl16Num)/(N.CCE.UL.AggLvl1Num+N.CCE.UL.AggLvl2Num+N.CCE.UL.AggLvl4Num+N.CCE.UL.AggLvl8Num+N.CCE.UL.AggLvl16Num)
●平均CQI
CQI反应下行信道质量和干扰水平,用单码字衡量即可。
平均CQI:
(0*N.ChMeas.CQI.SingleCW.0+1*N.ChMeas.CQI.SingleCW.1+…+15*N.ChMeas.CQI.SingleCW.15)/(N.ChMeas.CQI.SingleCW.0+N.ChMeas.CQI.SingleCW.1+…+N.ChMeas.CQI.SingleCW.15)
●平均接入距离
随机接入的TA值间接反应了UE距离基站的距离,通过平均TA值反应了用户分布远近。
分布越远,说明用户大部分分布在小区边缘,相关的信道条件,KPI理论上就会差一些。
平均TA值:
(0*N.RA.TA.UE.Index0+1*N.RA.TA.UE.Index1+…+12*N.RA.TA.UE.Index12)/(N.RA.TA.UE.Index0+N.RA.TA.UE.Index0+…+N.RA.TA.UE.Index12)
●平均用户数:
用户数代表网络负荷,可以结合PRB利用率,干扰水平趋势一起分析。
通常当用户逐渐增加时,一个网络的KPI是会逐渐降低的。
主要有几方面原因,一是由于用户增加,PRB利用率抬升,邻区之间负荷增加,这个是主要原因;二是随着用户增加,网络中异常终端可能会增加,通常少量异常终端就可以共享大量失败。
2.1.6操作和外部事件
网络操作和外部事件包含并不限于:
站点数改造(持续新建,或者某些时间存在断站),网络调整(翻频,RF优化,全网参数修改等),周边网元改造(LTE,核心网,传输等),重大节日活动,新款终端上市,主流终端版本升级,运营商资费策略变化等等。
这些操作和事件会导致网络拓扑结构,用户分布,用户行为等发生变化,从而导致网络负载,干扰水平的变化,最终影响KPI。
比如扩容改造,翻频等,可能让用户发生迁移,减小一个频点或小区的符合,从而导致KPI变好。
反之,由于传输、供电等原因导致断站,覆盖受损,加上用户分流到其它小区导致负荷增加,KPI就会变差。
2.2保持问题定位思路
2.2.15G覆盖问题导致的掉话
覆盖问题主要有弱覆盖,无主导频导致邻区干扰大两类主要场景。
●弱覆盖
如果有终端侧log,可以通过查看终端侧RSRP,如果RSRP低于-120dBm则说明覆盖较差了,容易导致掉话。
此时需要排查掉话点和服务小区的距离,是否有遮挡,服务小区是否网络规划预期的主覆盖小区。
如下所示,当RSRP低于5G的A2门限时(NRCELLNSADCCONFIG.PscellA2RsrpThld,默认-121),UE会上报测量报告导致gNodeB发起释放。
这个释放属于正常释放,不会记录为掉话。
图1RSRP低于A2门限导致释放
●重叠覆盖严重
如下这次掉话,UE没有上报测量报告,RSRP不算特别差,但是突然收到网络侧的释放命令。
从终端侧可以看到有两个邻区比服务小区好,其中一个瞬时RSRP高5dB了。
在邻区干扰下,SSBSINR只有-3,频偏-123也比较大。
该位置多个邻区信号强度波动大,强度和服务小区相当,无主服务小区,需要先解决RF的问题。
图2无主导频导致的掉话
●特定位置点问题
另外还有少数场景会出现在一些特定位置点,由于无线环境的多径复杂,导致频率选择性衰落严重,时偏等问题发生。
例如下面这次掉话,服务小区信号较好,也没有邻区干扰,但是误码很高。
当时在做上行灌包,正常情况下ULGrant应该在380~400次,但是掉话前ULGrant掉到只有100多次,甚至100次以下,说明存在DCI漏检。
图3掉话前上行误码高,DCI漏检
2.2.25G干扰问题导致的掉话
干扰是常见的一种导致掉话的原因,导致的掉话现象有多种,如下行RLC达到最大重传次数,上行RLC达到最大重传次数,SR达到最大次数,TA超时等等。
干扰的类别有很多,例如切换不及时导致的邻区干扰,TDD系统的环回干扰,时钟偏差导致的小区间干扰,还有外部干扰等。
掉话分析主要是先确认是否由于干扰导致,然后才是确认干扰源和排除干扰。
2.2.35G配置问题导致的掉话
常见配置问题主要有:
漏配邻区导致无法切换掉话;RLC参数配置不合理,导致状态报告不能及时上报,导致RLC重传达到最大次数掉话;SRS自适应门限设置不合理,导致远点SRS带宽不能切换到窄带,基站测量SRS信号较弱,无法准确测量TA导致掉话;A2门限配置过高,导致UE没有到小区边缘就被正常释放。
通常在排查动作的“参数核查”就可以发现参数导致的问题。
●问题现象
近点做下行灌包测试一会儿后就会掉话。
图4Probe记录掉话
●分析过程
单小区场景,信号很好,排除邻区干扰或外部干扰,空口误码不高。
图5覆盖和误码排查
从基站信令看,是5G发起的释放,携带原因值是UELOST。
当前19A版本只可能是下行RLC重传达到最大次数。
图6信令流程排查
排查参数发现使用的RLC参数组2,其中如下红色参数不合理。
图7参数排查
根据协议,UE只有在收到带Polling指示的RLCPDU包或检测到PDU接收异常时才会反馈状态报告。
由于gNBAmByteThldForTrigPoll和gNBPduNumThldForTrigPoll配置成Infinity,则普通PDU包都不会带Polling。
而测试场景为基站下行灌包,不存在使缓存为空的包,即基站尾包触发Polling的场景也不存在。
基站长时间收不到状态报告,发送窗口不能正常滑动,由于近点灌包流量大,而RLCSNSize只有12bit,很快就导致基站发送窗口满,从而判断RLC状态异常,发起释放。
●解决措施
通过修改对应QCI使用RLC参数组3,默认配置UeAmByteThldForTrigPoll=25,gNBAmByteThldForTrigPoll=25,UePduNumThldForTrigPoll=32PDUs,gNBPduNumThldForTrigPoll=32PDUs,DlRlcSnSize=18,UlRlcSnSize=18后,问题解决。
2.2.4切换失败导致的掉话
切换失败主要场景是UE向目标小区随机接入失败。
移动拉网测试过程中,一种是5G小区间的切换;还有一种是NSA组网下,LTE发生切换,5G服务小区虽然不改变,但是UE需要做一次随机接入,这个过程也可能出现失败。
●问题现象
从Probe上看到UE在向PCI486切换时,上报RAFail事件,然后UE给网络侧发SCGFailureInfo后掉话。
图8Probe看到在随机接入失败导致掉话
●分析过程
从Probe的KeyEvent可以看到UE发了Preamble后收不到RAR;连续发送10次后上报随机接入失败。
图9ProbeKeyEvent记录收不到RAR
查看终端侧服务小区和邻区信息,看到存在多个信号强度和服务小区相当的邻区,并且从eventlist窗口看到,掉话前存在乒乓切换。
说明UE所处位置信号杂乱,无主服务小区,在这种邻区互相干扰的情况下,很容易出现随机接入失败,需要先优化覆盖。
实际属于覆盖问题导致的切换失败。
图10基站信令跟踪看到5G发起切换请求被LTE拒绝
2.2.5传输故障导致的掉话
当标口信令跟踪里看到释放命令携带的原因值是transport-resource-unavailable时,说明是传输故障导致的掉话。
首先要排查是否有传输相关的告警。
需要注意如果GTPU静态检测开关(GTPU.STATICCHK)没有打开,则不会上报传输告警。
这时候可以打开开关继续测试观察。
或者通过故障日志来确认之前的掉话原因。
传输故障导致掉话通常有两种场景,一个是传输拥塞丢包,导致信令传递失败或时延大。
一个是收到核心网GTPUError,导致基站发起释放。
转交传输组处理。
2.2.6小区故障导致的掉话
导致小区故障的场景很多,比如传输,供电,硬件故障等等各种原因。
小区故障导致的掉话,可以通过查看告警进行确认。
告警编号
告警名称
对掉话的影响
ALM-29800
gNodeBX2接口故障告警
NSA组网时导致传输掉话
ALM-29815
gNodeBNG接口故障告警
SA场景导致基站释放在线用户;
ALM-29816
gNodeBNG控制面传输中断告警
SA场景导致基站释放在线用户;
ALM-29840
gNodeB退服告警
基站释放所有在线用户;
ALM-29841
NR小区不可用告警
释放小区下所有在线用