1、NR反开3D-MIMO后RRC重建突增问题分析报告一、 关键词：终端、重建、测量二、 案例分类1. 问题分类：网络性能2. 手段分类：参数调整3. 关于问题和手段分类项如有其他建议，可补充三、 优化背景随着不限量套餐的持续推广，4G流量仍在快速增长。通过5G AAU反向开通4G 3D-MIMO的方式，可以有效缓解4G容量压力，同时也是4G 清频（D1、D2清频）容量补充的必要手段。此次在太原“中冶天工”5G基站上试点开通D3、D7、D8 3个3D-MIMO频点。在对3D-MIMO开通后的网络性能分析时，发现周边4G小区RRC重建指标出现明显恶化。经过一系列优化调整，指标恢复正常。四、 问题现象
2、6月27日“皇威大厦”RRC重建次数突增，并且RRC重建的原因主要集中在RRC重配置失败。RRC重建请求由最初的100次以内增长至近30000次。增长趋势如下图所示：提前话统数据详细分析，RRC重配置失败是导致的RRC重建的主要原因。如下表统计：五、 原因分析1、信令分析通过基站标口消息跟踪，异常重建请求前的RRC重配置都是测量控制消息，和日常测量控制不同的是增加了D7/D8频点，导致重建的原因为RRC重配置失败。UU口消息跟踪：测量控制中下发含BAND 41的D7/D8的测量控制后，终端异常上报RRC重配置失败的RRC重建。S1消息跟踪：对用户S1口消息跟踪，发下终端能力中显示支持BAND
3、41。2、小区内重建原因统计通过跟踪消息统计发现97.75%的RRC重建由于重配置失败导致（不支持D8），异常重建主要集中在两款终端上（FGI为7F CF FE 9A和FF CF FE 9A）。3、周围站点变化分析：通过核查现网配置，发现5月26日中冶天工5G基站反开3D MIMO增加D7和D8频点，周围基站增加D7和D8邻区。5月27日后周围基站的RRC重建增加明显，并且原因集中在RRC重配置失败。小区名称RRC重建请求次数重配置失败触发RRC重建请求的次数重配置导致重建占比A2_JC三千渡HLF_H-726938350950.58%A2_JC滨河城HLF_H-117612994456.46
4、%A2_JC滨河城HLF_H-1+113138733955.86%A2_JC滨河城HLD_H-11+28907672075.45%A2_JC二钢北区化验楼HLF_H-1114451029589.95%A2_JC皇威大厦HLF_H-1173591491785.93%A2_JC赵庄旧区HLF_H-16239517282.90%A2_JC皇威大厦HLF_H-1+1120141091490.84%问题结论：由上可以确认是由于部分终端不支持D8导致RRC重配置失败进而引发RRC重建。六、 解决方案由于TOP终端不支持D8频点导致RRC重建增加，需要对TOP终端添加D8黑名单功能，针对问题终端不下发D8测
5、量以规避问题；（要求15.1 SPC180及以上版本）MOD GLOBALPROCSWITCH:UECOMPATSWITCH=AbnormalUeHandleSwitch-1;ADD UEINFO: UeCapIndex=0, Fgi=XXXX;ADD UECOMPAT: Index=0, UeInfoType=UE_CAPABILITY, UeCapIndex=0,BlacklistedNFreq2Earfcn=41140,BlacklistedNFreq2Earfcn=41340;备注：已发现的TOP终端FGI为7FCFFE9A、FFCFFE9A、7FCFFE9E、7ECFFA9E、7EC
6、FFA9A、FFCFFEBE、FFCFDEA6、7FCFDEFE、FFCFFEBA、FECFFA9E、7FCFFEBE、7F4FFE9A、FFCF1EA6（十六进制，需要转换为10进制配置）七、 效果评估由于目前现网基站是13.1版本，无法进行黑名单终端规避，暂时采用周围基站删除D8邻区规避（其他正常终端通过绕行同扇区D3进入D8），删除后周围基站的RRC重建恢复正常。八、 基于案例提炼的方法、流程及评估标准建议重配置失败的重建大多数是由于终端对基站配置不兼容导致的，体现为终端收到重配置消息后，没有回复重配置完成消息，而是发起RRC重建请求，按问题根因可以分成如下两种场景：场景1：基站携带了异常的参数，不符合协议。（基站的问题）。场景2：某些类型终端的问题，导致兼容性问题。（终端的问题）。对于场景2，一般表现为TOP终端类型和TOP用户的问题。这种场景通常还表现为某些用户会反复重建，少数用户就会导致全网的重建比恶化很多。对于重配置失败导致的重建需要跟踪消息核查详细原因，对于TOP终端需要进行规避。已获得授权通信资料：白先生客栈
