某外場高鐵測試過程中發(fā)現(xiàn)在切換進入某些小區(qū)后出現(xiàn)反復重配置消息，影響下行速率，如圖1所示。重配置在切換到新的小區(qū)后仍然相繼重復下發(fā)，影響測試速率，復位終端后消除。

圖1 反復重配置現(xiàn)象

從重配置發(fā)生前后的事件看，UE先發(fā)起了一次NR A3同頻切換，切換失敗觸發(fā)了重建，重建完成后基站開始反復給UE下發(fā)RRC重配置消息，如圖2所示。

圖2 重復下發(fā) RRC 重配置消息

從UE側解析的log看，UE一直出現(xiàn)SR超次的隨機接入，如圖3所示。

圖3 重復出現(xiàn)SR隨機接入

從基站側打印的log看下，下發(fā)的重配置消息全部一樣，內容都一樣為上行資源，spa觸發(fā)的SR資源不停重配置，而且基站一直沒有收到該UE的SR。

經過分析，確認是終端認為在重建立后無SR資源可用，反復發(fā)生SR超次導致。該問題在其他外場也有反饋，聯(lián)合終端排查定位，確定屬于各廠家對協(xié)議的理解不一致造成。

海思芯片的終端對于RRC重建立后需要進行srb1配置，而我司當前在重建立發(fā)生時候基站只配置srb2相關SR資源，如圖4所示。

圖4 故障原因

發(fā)生RRC重建立后第一條重配置消息沒有對srb1相關的資源進行重配置，隨即問題出現(xiàn)，如圖5所示。

圖5 反復重配置現(xiàn)象出現(xiàn)

解決方案是重建立之后的基站在第一條RRC Reconfiguration消息攜帶srb1 RLC_BearerConfig兼容終端，通過信元對可以看到重建立后第一條重配置消息中已攜帶srb1相關配置給UE，重建后重復下發(fā)重配置問題解決，如圖 6 所示。

圖6 Srb1 相關資源配置下發(fā)

本案例中由于海思芯片終端與基站對協(xié)議理解不同，出現(xiàn)重建立后反復出現(xiàn)大量基于SR資源的重配置，問題依托基站側版本實現(xiàn)規(guī)避，兼容了不同類型終端，目前該問題在其他外場也有出現(xiàn)，可供參考。