某TOP站点其他原因导致SN添加失败
现象描述
某站点在优化SN添加成功率时，其他原因导致的SN添加失败占比较高，如图1所示。
图1  Mn侧SN添加失败原因
问题分析
选择TOP站点10158151进行分析，站点10158151的SN添加失败统计如图2所示。
图2  10158151站点SN添加成功率及失败原因
查询MN侧指标，636847添加10158151的其他原因导致失败次数较多，但也存在一定的成功次数，如图3所示。
图3  MN侧指标查询结果
进行UE级小区信令跟踪，在添加SN时，重配置失败导致SN添加失败；UE发起重建立后，再次添加SN时同样失败，如图4所示。
图4  UE级小区信令跟踪
使用Mate 20X和天机 10进行现场测试。Mate 20X正常添加SN，但是天机 10无法接入5G，信令场景与之前跟踪小区信令相同，如图5所示。
图5  使用Mate 20X和天机 10的信令跟踪
对比正常添加SN时的重配消息和此次SN添加失败时的信令，看到在失败重配消息的CSIreport里配置的是CRI-RI-CQI，而正常的重配消息里是CRI-RI-PMI-CQI，如图6所示。
图6  查看添加SN时的重配消息
核查站点10158151的CSI相关的配置，发现此站点同时开启了CQI和PMI上报。在CSIReportResource表中cqiReportEnable和pmiReportEnable都为true，如图7所示。
图7  CSIReportResource表
在CQIMeasureCfg表中配置的测量上报量类型为criRICQI，如图8所示。
图8  CQIMeasureCfg表
在PmiMeasureCfg表中配置的测量上报量类型为criRIPMICQI，如图9所示。
图9  PmiMeasureCfg表
而核查全网配置，基本上都是只开启了PMI上报。
解决方案
关闭CQI上报开关后，其他原因导致的SN添加失败次数降低为0，SN添加指标恢复正常，如图10所示。
图10  SN添加失败次数，其它原因
效果总结
对于SN添加出现重配失败的问题，若是高通芯片终端，可以优先按以下几个方面排查：
  • 4G与5G的RLC传输模式配置不一致时，修改4G与5G的默认承载对于的RLC传输模式同为UM或同为AM。
  • 4G与5G PDCP SN bit数不一致时，修改4G网管 Qos业务类型，默认承载对应的UE类型为NR行，PDCP SN长度修改为18bit（NR默认配置为PDCP SN bit=18）。
  • 5G侧上行使能256QAM
    在添加SN重配消息的 pusch-Config setup 消息体中，携带了字段mcs-TableTransformPrecoder qam256，由于高通终端目前不支持UL 256QAM，基站默认配置为使能UL 256QAM，修改5G的上行256QAM为不使能 Qam256EnableUl=false。
  • 配置5G上行最大层数为2。
    在添加SN重配消息的 pusch-Config setup 消息体中，携带了字段maxRank 2，由于高通终端目前不支持上行2layer，该配置会导致添加SN重配失败。修改5G网管上的SRSConfig中portNum=1（基站版本问题，导致网管SRS的portNum数值关联成了PUSCH的maxRank）。
  • 配置5G PDSCH的dmrs type为2。
    当前高通终端X50平台只支持supportedDMRS-TypeDL type1，基站在PDSCH的dmrs type配成2后，在LTE的debug消息中打印：FAILURE due to validatn from NR5G-RRC, Triggering RLF，在NR的debug消息中打印：OTA Validation failed. supported_dmrs_type_dl not supported for band 77。
  • 未配置PMI的cri-RI-PMI-CQI，高通目前不支持下面这个配置。必须打开CSI-IM功能。
  • 当配置CSIRS时，必须打开CSI-IM功能。
  • 当配置60 M或80 M的BWP时，网管后台参数pucchconfig -> pucchPRBstart默认配置会超过带宽，导致重配失败或终端crash。