华为5G性能优化指导手册SA.docx

华为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小区不可用告警

释放小区下所有在线用