某外场高铁测试过程中发现在切换进入某些小区后出现反复重配置消息,影响下行速率,如图1所示。重配置在切换到新的小区后仍然相继重复下发,影响测试速率,复位终端后消除。
图1 反复重配置现象
从重配置发生前后的事件看,UE先发起了一次NR A3同频切换,切换失败触发了重建,重建完成后基站开始反复给UE下发RRC重配置消息,如图2所示。
图2 重复下发 RRC 重配置消息
从UE侧解析的log看,UE一直出现SR超次的随机接入,如图3所示。
图3 重复出现SR随机接入
从基站侧打印的log看下,下发的重配置消息全部一样,内容都一样为上行资源,spa触发的SR资源不停重配置,而且基站一直没有收到该UE的SR。
经过分析,确认是终端认为在重建立后无SR资源可用,反复发生SR超次导致。该问题在其他外场也有反馈,联合终端排查定位,确定属于各厂家对协议的理解不一致造成。
海思芯片的终端对于RRC重建立后需要进行srb1配置,而我司当前在重建立发生时候基站只配置srb2相关SR资源,如图4所示。
图4 故障原因
发生RRC重建立后第一条重配置消息没有对srb1相关的资源进行重配置,随即问题出现,如图5所示。
图5 反复重配置现象出现
解决方案是重建立之后的基站在第一条RRC Reconfiguration消息携带srb1 RLC_BearerConfig兼容终端,通过信元对可以看到重建立后第一条重配置消息中已携带srb1相关配置给UE,重建后重复下发重配置问题解决,如图 6 所示。
图6 Srb1 相关资源配置下发
本案例中由于海思芯片终端与基站对协议理解不同,出现重建立后反复出现大量基于SR资源的重配置,问题依托基站侧版本实现规避,兼容了不同类型终端,目前该问题在其他外场也有出现,可供参考。
全部0条评论
快来发表一下你的评论吧 !