错误 #3629
历史记录
【问题描述】UU口接入流程中,基站没收到msg3,偶现概率很低,最近北京250环境测试近30多次都没出现。
【问题原因】查看终端logy msg3 pusch流程已经走完,查看基站侧log,对应RNTI的crc err,sinr是-9dB没有功率。出现概率低,待复现时加版本定位


【解决方案】
【问题验证】
【问题描述】UU口接入流程中,基站没收到msg3,偶现概率很低,最近北京250环境测试近30多次都没出现。
【问题原因】查看终端logy msg3 pusch流程已经走完,查看基站侧log,对应RNTI的crc err,sinr是-9dB没有功率。出现概率低,待复现时加版本定位,和北京人员沟通,目前250环境基本必现msg3基站收不到的情况,
怀疑可能是新合入代码或者是环境某些参数修改导致,因为pusch最近没合入代码,之前是基站稳定解对msg3的。
【解决方案】1 可以排查下北京环境中参数和版本的修改。上行uldelay的值会影响终端和基站的msg3的接收时机。

2 在北京环境验证,但是环境只能走到msg1,无msg2,掉电RRU重试。
3 在西安环境测试最新的物理层版本,通过回退定位。西安环境基于0619号的T3版本基站稳定解对msg3。
【问题验证】
【问题验证】在西安环境上,基于0619的T3版本,(基站稳定解对msg3) 只替换物理层的版本,版本号commit 9b9edb8abbba800546ea7d1f828f084718ab2928(0625号合入的)在环境验证4次,抓基站侧层1的log显示都能解对Msg3。
- 状态 从 新建 变更为 已解决
- % 完成 从 0 变更为 100
【问题验证】在北京换了环境上,回退了APdriver,同样的物理层版本可以走到msg12,后续不在出现msg3失败问题。怀疑是环境或是APdriver问题。
北京换了环境上,回退了APdriver,问题未再发生。close。
导出 Atom
PDF