项目

一般

简介

错误 #3049

终端接收Msg4, 上报给MAC的TB块头部莫名多了4个Byte冗余数据

由 赵 强 在 2 个月 之前添加. 更新于 2 个月 之前.

状态:
已解决
优先级:
普通
指派给:
赵 强
开始日期:
2025-03-31
计划完成日期:
% 完成:

0%

预期时间:

描述


基站发的码流跟终端解出来的码流是能对上的，没有头部4字节的冗余。应该是在搬数报给MAC的时候出现了异常，需要梳理下上报的代码

文件

img_v3_02kr_3e4f1ccd-064a-4de9-8ec3-375370b069dg.jpg (989 KB) img_v3_02kr_3e4f1ccd-064a-4de9-8ec3-375370b069dg.jpg 赵 强, 2025-03-31 09:50
img_v3_02kt_c87a5f86-4bd9-4cc3-8142-557faed05d9g.jpg (236 KB) img_v3_02kt_c87a5f86-4bd9-4cc3-8142-557faed05d9g.jpg 赵 强, 2025-03-31 15:20
img_v3_02kt_e51e45e2-85f6-4633-999e-0cb4e5bea6bg.jpg (120 KB) img_v3_02kt_e51e45e2-85f6-4633-999e-0cb4e5bea6bg.jpg 赵 强, 2025-03-31 15:20

历史记录

#1

由 赵 强 更新于 2 个月 之前

【问题描述】终端接收Msg4, 上报给MAC的TB块头部莫名多了4个Byte冗余数据
【问题原因】1、由于wnUlTbReqT结构体里面定义了一个uint64_t的元素，导致整个结构体是8字节对齐，不是4字节对齐。所以在从payload取码流的时候自动8字节对齐了，导致多取了4字节的数据。
2、（至于SIB为什么没有这个问题，因为SIB的结构体的元素最大开的是uint32_t类型，所以不影响）
【解决方案】改下这个uint64_t taValue接口，把uint64_t 改成两个uint32_t。

【问题验证】在环境上试过了，改完之后，从payload取码流是对的，没有4字节冗余了

导出 Atom PDF