华为5G网管性能问题分析手册-SA
概述
目前全省各地市已完成SA商用测试,除了从日常测试与投诉中发现网络存在“点、线”的问题,还需要从性能上发现面上的问题,从而使得NSA网络正常运行,保障5G网络的用户体验感知。
与传统LTE网络一样,需要从“接入性”、“移动性”、“保持性”以及“小区数传能力”几个维度进行性能问题分析定位。
接入性:无线接通率
移动性:
保持性:无线掉线率
1、 小区接入性能问题
SA组网小区,终端接入5G网络的,主要涉及流程如下:
涉及指标:无线接通率
计算公式:无线接通率(NR)=(RRC连接建立成功次数/RRC连接建立请求次数)*(Flow建立成功数/Flow建立请求数)*(NG接口UE相关逻辑信令连接建立成功次数/NG接口UE相关逻辑信令连接建立请求次数)
1.%2 接入问题规定动作
1.1.%3 操作日志&告警故障
基站的操作,告警和故障日志可以在U2020和一键式日志内获取,使用FMA可以直接打开,对于操作日志主要排查是否存在影响接入的操作,主要判断问题时间点与操作时间点是否存在相关性;对于告警及故障主要查看问题时间点,是否存在相关未恢复的告警,如小区不可用、X2接口故障等。
1.2.%3 参数核查
1、 通过优化最小接收电平、小区选择参数、小区重选参数、5-4重选参数、邻区核查等手段提升;
参数名称 | 参数说明 | 建议值 |
CoverageScenario | 天线覆盖场景 | 建议使用DEFAULT,可以根据实际覆盖情况进行调整 |
Tilt | 波束物理下倾角 | 默认3°,增大下倾会缩小小区覆盖范围 |
SsbPeriod | SSB周期 | 默认值为20ms,拉长SSB周期可能会导致部分终端无法接入 |
Sib1Period | SIB1周期 | 默认值为20ms,拉长SIB1周期可能会导致部分终端无法接入 |
RsrpThldForSsbSelection | 选择SSB的RSRP门限 | 该参数表示选择SSB时的RSRP门限,配置过高可能会导致终端无法选取合适的小区驻留 |
MaxPreambleTransCnt | 前导最大传输次数 | 默认为10次,减少前导最大传输次数可能导致接入成功率降低 |
CellRadius | 小区半径 | 小区半径设置过小可能会导致远点用户接入失败 |
1.3.%3 射频通道(发功&上行干扰)排查
上行干扰会影响SRS和PUSCH解调性能,严重影响吞吐率性能。正常情况下底噪在-116dbm左右,干扰跟踪位于M2000 Tracing Monitor->NR->Cell Performance Monitoring.
2.%2 接入问题定位思路
NR接入问题涉及问题,可见如下思维导图
2.1.%3 空口未发起RRC_CONN_REQ
基站侧没有收到RRCSetupReq,需要在终端侧观察,终端侧是否有发起RRC接入
可能原因:
• 小区不可用,核查小区状态和故障告警;
• 小区状态为BLOCK状态;
• NG-C链路故障或者未配置;
• AAU通道校正失败
• 终端不支持NR频段;
2.2.%3 NR随机接入失败
当前导致随机接入失败的可能原因有:
• 弱覆盖或干扰导致随机接入失败,核查问题小区覆盖和干扰情况;
• 超小区半径接入:核查问题小区半径设置是否存在异常。小区半径配置,该配置会影响生成Preamble序列所使用的NCS参数,如果配置过小会导致中远点用户无法接入;
• Prach参数等配置异常,根序列索引需要进行网络规划,避免周边小区接收到Preamble下发RAR消息,对本小区产生下行干扰
• 时隙配比和时隙结构配置:要求全网一致,不一致会有上下行干扰问题,可能导致随机接入异常
2.3.%3 RRC建立失败
RRC建立失败包括如下三种情况
1、 RRC Rej:UU口检查收到RRCSetupRequest,没有下发RRCSetup,下发了RRCSetupRej;
2、 RRC NoReply:UU口检查收到RRCSetupRequest,下发了RRCSetup,但是等待RRCSetupCpmplete超时;或者下发RRCSetup后又立即下发了RRCRel;
3、 RRC丢弃:UU口检查收到RRCSetupRequest后,直接丢弃,没有进行下一步的处理。
当前RRC建立失败的可能原因有:
• 下行覆盖问题
• 小区重选参数问题
• 资源拥塞问题
• 设备异常问题
2.4.%3 NGSig建立异常
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、 小区保持性能问题
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 | 无线层问题导致的QoS Flow异常释放次数 |
N.QosFlow.AbnormRel.TNL | 传输层问题导致的QoS Flow异常释放次数 |
2.1.4 TOP N分析
接下来要确认问题范围是TOP小区问题还是整网问题。
“TOP小区”问题:
分别去除TOP10(可以小区规模设定TOPN个数,例如TOP100)”掉话率TOP小区”和”掉话次数TOP小区”后,如果整网掉话率明显改善且与掉话率恶化前指标基本持平(或者达到了目标值),则定义为TOP小区问题。
热门文档
相关文档