错误 #3845
EVMT4 双向收发时，一端全发一端全收，接收端打发送padding时，导致接收端其他动态时隙全都接收不到
由 高 峰 在 3 个月 之前添加.
更新于 大约一个月 之前.
描述
上海交流发现的问题，交流后现象是：
1. A设备动态时隙全发，B设备为动态时隙全收，A、B两端均正常
2. 在第一步基础上，B设备配置静态时隙打padding发送，发现B 动态时隙都收不到了
历史记录
8.2日周六张倩做了一个实验：
1. A端 padding + B端 padding，OK，证明A端和B端 padding发送和接收都OK
2. 在第一步基础上，A端长发，B端不变，发现两种异常情况：
① A端挂死
② A端挂死情况下，B端静态时隙也接收不对了。
是不是可以说明，A端长发与padding 同时配置，也出现了问题
但这个实验，上海那边认为他们之前做过，但没有出现问题
上海做的实验，以下3个case都是OK的：
1. 233 only trans4（长收）
2. 233trans4, 234trans3+padding
3. 233trans4, 234padding
目前发现L2 fredomainresources 参数存在跳变的情况
定位发现PDCCH 静态时隙只解对单播，未解对65535广播情况时，上报的TCI ind存在length异常值
会导致L2 内存异常，这可能是 fredomainresources参数异常的原因
但为什么PDCCH只解对单播，未解对广播，可能还需要进一步定位
高 峰 写到：
定位发现PDCCH 静态时隙只解对单播，未解对65535广播情况时，上报的TCI ind存在length异常值
会导致L2 内存异常，这可能是 fredomainresources参数异常的原因
PDCCH修复后这个问题（第一条）后，fredomainresources 参数异常改善非常多，可以坚持20分钟，但最后依然有fredomainresources参数异常现象
- 指派给 从 宋 卿 变更为 高 峰
- % 完成 从 0 变更为 100
导出 Atom
PDF