王 艳芳
- 注册于: 2024-04-22
- 最后登录: 2025-11-25
问题
项目
- 解决方案集成测试 (开发人员, 2024-04-22)
- eMBB2.0 BBIT (开发人员, 2024-04-22)
- STE (开发人员, 2024-06-13)
- 研发产品测试 (开发人员, 2024-04-22)
- 2.0基站产品化测试 (开发人员, 2024-04-22)
- B5G_UE (开发人员, 报告人员, 2025-01-06)
- FirstCall (开发人员, 报告人员, 2024-11-28)
活动
2025-11-25
- 20:32 B5G_UE 错误 #4356 (反馈): B5G终端版本V0.0.1_T06，dd口am模式下两终端互ping包出现周期性大时延（几百ms）
- 已在T7版本合入修复代码，请验证问题是否解决
2025-11-12
- 10:45 B5G_UE 错误 #4410: UU口双向灌包过程中协议栈跑死
- 协议栈CRASH，是因为FAPI的数据的MAC头指示的SDULEN超出协议范围，导致RLC拷贝FAPI数据时，因为内存溢出而CRASH。MAC解复用后增加SDULEN的检查后，只是MAC解复用的正常保护，根因是FAPI接口数据异常，目...
2025-10-31
- 15:55 B5G_UE 错误 #4356: B5G终端版本V0.0.1_T06，dd口am模式下两终端互ping包出现周期性大时延（几百ms）
- 【问题原因】
1 通过问题复现，抓取PING包的LOG，与协议栈LOG对比分析，PING包时延大的包是因为发端的PING REQUREST数据包在接收端出现CRC ERROR而丢失，所以问题归结为RLC AM的重传时延过大的问题。
...
2025-10-21
- 19:00 B5G_UE 错误 #4171: V0.0.1_T06__Alaph3三终端测试a-c灌包AM模式下速率会掉到0
- 【问题进展及分析】三终端有转发测试，AM速率掉0的问题根因在于转发终端接b接收终端a发送的数据后，直接转发，没有COPY及重新申请内存，导致内存占用时间过长，无法及时释放，从而可能导致接收端底层的内存耗尽。扩展内存后复测，速率不再掉0...
2025-10-17
- 09:43 B5G_UE 错误 #4246: 基于3.0整机，PDU建立成功后，RLC AM DRB重传超限导致UE接入后释放
- 如问题解决，就关闭吧。后续使用SN 18BIT继续业务测试
- 09:37 B5G_UE 错误 #4171 (挂起): V0.0.1_T06__Alaph3三终端测试a-c灌包AM模式下速率会掉到0
- AM SN 18BIT的调试优先级更高，目前工作量投入了18BIT的调试。这个问题暂时推迟，等18BIT调试结束后，继续。
2025-10-16
- 09:32 B5G_UE 错误 #4246: 基于3.0整机，PDU建立成功后，RLC AM DRB重传超限导致UE接入后释放
- 问题分析及解决：1）通过Log分析，发生rlc重传失败的逻辑信道为业务逻辑信道，（此时基站并未发起业务），终端侧rlc接收该逻辑信道的数据后，生成了相应的状态报告，但未发送，基站侧依赖poll retro timer发起了多次重传，直...
2025-10-15
- 09:49 B5G_UE 错误 #4171: V0.0.1_T06__Alaph3三终端测试a-c灌包AM模式下速率会掉到0
- 进展更新（跟新纠正）
- 09:48 B5G_UE 错误 #4171: V0.0.1_T06__Alaph3三终端测试a-c灌包AM模式下速率会掉到0
- 10月11日问题进展跟新：
AM速率掉0问题跟踪，目前速率下降的主要原因是转发终端或同时收发的终端的丢包率（不确定哪层导致）会概率上升，RLC的NACK数量突增，达到维护的最大值，之前是64，目前修改为16后，测试结果如下：
1...
2025-10-10
- 19:07 B5G_UE 错误 #4171: V0.0.1_T06__Alaph3三终端测试a-c灌包AM模式下速率会掉到0
- 使用125/127/129环境测试的结果更新:
1 有转发的双向灌包，理论速率20M，发包/收包速率10M，可维持30分钟；
2 有转发的单向灌包，理论速率40M，发包/收包速率30M，可维持29分钟左右，速率降0，分析LOG为接...
导出 Atom