席 振斌
- 注册于: 2022-07-19
- 最后登录: 2025-05-06
问题
项目
- eMBB2.0 BBIT (开发人员, 报告人员, 2022-08-03)
- 研发产品测试 (开发人员, 报告人员, 2022-07-19)
- 2.0基站产品化测试 (开发人员, 报告人员, 2022-07-19)
- 3.0基站产品测试 (开发人员, 报告人员, 2024-12-17)
- FirstCall (开发人员, 报告人员, 2024-11-28)
活动
2025-04-30
- 14:45 3.0基站产品测试 功能 #3152 (转测试): 结合E500验证1s内3.0基站的ue可接入数量
- 14:39 3.0基站产品测试 功能 #3152: 结合E500验证1s内3.0基站的ue可接入数量
- 通过报文分析，无论基站有没有满业务均可支撑1s内接入10ue，评估结果在xlsx表中
- 09:28 2.0基站产品化测试 错误 #3050 (挂起): 17P商用手机跨核心网切换，目标侧重配完成上不来
- 09:27 2.0基站产品化测试 错误 #3050: 17P商用手机跨核心网切换，目标侧重配完成上不来
- 等有鼎桥提供了终端侧生成日志的方法，在终端侧提取log后再进行分析，暂时挂起
2025-04-29
- 17:07 2.0基站产品化测试 错误 #3050: 17P商用手机跨核心网切换，目标侧重配完成上不来
- 修改了前导码相关的一些配置参数，如下图右边侧图所示，在西安用鼎桥测试了一版，没有效果
!20250429-170616.jpg!
- 11:27 2.0基站产品化测试 错误 #3050: 17P商用手机跨核心网切换，目标侧重配完成上不来
- 通过38.133协议看，物理层判断是不是失步，主要是看bler有没有达到10%,所以梁娜提出，将mcs调整到8，然后通过用户面数据去影响终端侧bler,让其处于小于10%，通过测试来看没有效果
- 10:39 2.0基站产品化测试 错误 #3050: 17P商用手机跨核心网切换，目标侧重配完成上不来
- 后续用mate40测试过，5qi=5和5qi=9同时存在，出现过一次可以回重配置完成的，此次在源侧5qi=9所映射的drb没有一帧上下行业务，所以从这个现象还是说明和杂包造成的失步相关
- 09:41 3.0基站产品测试 性能 #3266 (进行中): 600ue时，定时器处理能力是否为性能瓶颈
- 09:41 3.0基站产品测试 性能 #3266 (进行中): 600ue时，定时器处理能力是否为性能瓶颈
2025-04-28
- 15:40 3.0基站产品测试 功能 #3151: map和unordered_map的性能对比及用户面map的替换
- 同时测试人员需要在网管看速率显示是否正常
导出 Atom