错误 #2034
15PPre1T2 0805版本测试发现单下行FTP业务流量偏低
由 牛 兵桃 在 9 个月 之前添加.
更新于 5 个月 之前.
描述
15PPre1T2 0805版本测试发现单下行FTP业务流量偏低只有不到20M，UDP上下行业务峰值流量正常，单上行FTP业务峰值速率也正常，北京环境也有类似现象周琼已经采集走了定位日志
历史记录
之前使用TM500测试，后面使用不同型号手机以及cpe，下行单ue ftp速率都偏低
由 匿名用户 更新于 8 个月 之前
产品部使用Rel_2.1.15P_Pre1T4的基站版本,把核心网版本从3.2.3回退到3.2.2,问题消失
Rel_2.1.15P_Pre1T4+核心网3.2.2版本&3.2.3高性能upf，单ue dl ftp比较稳定在400M左右
由 匿名用户 更新于 7 个月 之前
西安50基站FTP不达标的总结:
UE RLC层数据接收没问题,不达标的原因都是UE TCP上报有包没收到,导致TCP降速, UE TCP上报有包没收到的原因有4种:
1,发送端的IP字段填错了,导致IP大包分段后无法级联,UE TCP当成两个独立的IP包解析,导致解不对;
2,数据在UE RLC到应用层之间丢了或者没解出来;
3,UE没收到的包,核心网也没收到,可以确定server发出了,丢在了server到核心网之间;
4,核心网收到的包乱序了,导致UE接收延迟.
由 匿名用户 更新于 6 个月 之前
241024 旭初反馈server安装在核心网,西安50基站下行ftp 440M,非常稳定(单子2260用于跟踪西安50基站下行ftp的问题)
由 匿名用户 更新于 6 个月 之前
241022 北京研发41基站发现下行FTP不达标,看了241024的log, FTP不达标的原因是: 数据在UE RLC到应用层之间丢了或者没解出来(log: 241023gnb41_2034)
下一步: 周磊说换个环境抓组log(补UE PC的wireshark log)
- 指派给 从 周 立伟 变更为 韩 伟
- 目标解决问题版本 从 Rel_2.1.15P 变更为 Rel_2.1.16P
导出 Atom
PDF