错误 #3408
基站下发Msg6消息(鉴权请求),终端PDSCH解析错误
由 白 瑞朋 在 2 个月 之前添加.
更新于 大约 2 个月 之前.
描述
【问题描述】
终端进入ACTIVE态后,基站下发鉴权请求消息,UE PDCCH DCI CRC解析OK,PDSCH解析CRC错误。
文件
历史记录
【问题现象】
1.PDSCH获取到的de-ofdm频域数据地址buffer ping-pong取反,导致异常;
2.PDSCH获取到错误的频域数据地址后,任务处理超时;
【问题进展】
1.从de-ofdm进行时间统计,没发现任务超时问题;且de-ofdm和PDCCH发给PDSCH的两个slot号可以对上;
2.de-ofdm加trace log,监控ping-pong写频域地址buffer,没有发现写错位问题;偶地址:0xa0e0800,奇地址:0x9d94580;
【下一步】
1.检查deOfdm-PDCCH-PDSCH接口传递的sfn和slot,看是否有超时或者跳变;
2.deOfdm-PDCCH-PDSCH接口的sfn/slot,与PDSCH本地获取的sfn/slot进行对比;
【问题进展】
1.环境存在msg6 CRC ERR的现象。查看log,存在跨帧现象(1024帧后出现帧翻转),怀疑与时序有关,导致数据解不对;

【下一步】
1.终端与基站侧sfn/slot拉齐进行测试
【问题进展】
修改基站参数'PDSCH_DMRS附加位置配置'1改为2后,有以下几个现象:
1)有10%概率msg6 CRC可以解对,并上报鉴权TB给协议栈;协议栈收到消息后鉴权失败;
2)核心网增加了UE的op code,待复现后和协议栈继续分析;
3)基站在S-slot调度msg6,CRC必错;
4)基站调度msg6的rbSize<4,CRC必错;
下一步
继续尝试复现分析;
【问题进展】
协议栈鉴权失败后,会回复鉴权失败给基站,重新做一次鉴权,
下一步需要PHY确认:
1)是否回复msg6的ACK给基站,基站是否收到;
2)是否收到PUSCH的调度信息(解PDCCH的dci0_1),并解对CRC;(第一个0表示上下行,0:ul;1:dl;第二个1表示coreset,0:公共;1:专有)
【问题进展】
log中的异常信息有
1)[INFO]L1C fill pucch cfg to phy: Format199603 not supported. -> PUCCH参数错误,目前只支持UCI format 0;
2)[INFO]Res is not having sufficient PRB to accomodate UciBits. -> PUCCH参数错误,进入了format234的错误分支;
下一步:
分析msg6 ACK没有上报的原因,以及L1C参数配置问题。
【问题进展】
1)PUCCH的UCI format格式配成了1,PUC暂不支持;(只支持0)
2)发现ACTIVE后的UCI format memcopy错误;
3)填写UCI format时候,值一开始0,后被篡改成1;需要继续定位为啥配置成了1;

终端pucch格式写错成1,是因为1LC处理未初始化msg6的uciBitmap,uciBitmap最后的值是255,这样就会做CSI和SR的填参数处理,但是msg6的L1C只有harq的参数处理,其他2个结构体中是随机值,
这样就会在最后的SR填参数过程中,将pucch格式写错。
解决办法:将uciBitmap初始化为0,这样处理中遇到Hq置为1.
验证:在环境验证,msg6的L1c的pucch格式是0.参数正常
1)PDC解析DCI1_1,PDSC得到TB_size;PUCCH回复PDS的ACK;
2)PDCCH解析DCI0_1,拿到上行调度信息(或者发送SR给基站,基站下发DCI0_1);
3)PDC发送授权SR给协议栈,解析完通过FAPI_UE_UL_GRANT_IND消息发送;
4)协议栈下发FAPI_UE_UL_TB_REQ消息,携带TB_size信息,指示上行发送;
5)L1C触发PUSCH进行上行发送;

【问题进展】
基站参数做如下修改,PDS大概率可以解对CRC
1.修改为单流;
2.关闭AMC开关,并降低default MCS,控制调度msg6 RB>4以上;
PDSCH可以解析成功。
导出 Atom
PDF