项目

一般

简介

性能 #892

上行两天线上行大流量（超过400M），CU向网口发送流量严重不足

由 高 瑞峰 在 将近 3 年 之前添加. 更新于 超过 2 年 之前.

状态:
已解决
优先级:
普通
指派给:
杨 凯
类别:
gNB-CU
开始日期:
2022-07-29
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
CU
发现问题版本:
Rel_2.1.10P
目标解决问题版本:
Rel_2.1.10P
CPU类型:

描述

在上行两天线的配置下，进行上行UDP灌包测试，DU侧收到450Mbps，发出450Mbps，此时监测基站网卡流量，一段时间在400Mbps左右波动，一段时间可以达到与DU进出口流量齐平，不是太稳定，而且有瞬发超大流量的情况，可以达到900Mbps。

文件

CU发送流量不足问题.docx (822 KB) CU发送流量不足问题.docx 高 瑞峰, 2022-07-29 10:08
Pasted image 20220728180622.png (92.8 KB) Pasted image 20220728180622.png b jz, 2022-07-29 10:12

历史记录

#2

由 b jz 更新于 将近 3 年 之前

分析：
UL灌包下不来。
一秒乱序了23个包。大量的MSG_TIMER_2_PDCP_RX_3_PDCP_REORDERING_TIMER_EXPIRY_IND

目前需要分析的点是，PDCP UL的 reording 机制。
需要分析下协议关于reording的机制
和代码关于reording的实现。

#3

由 高 峰 更新于 将近 3 年 之前

  • 指派给 从 b jz 变更为 林 万江
#4

由 林 万江 更新于 将近 3 年 之前

  • 指派给 从 林 万江 变更为 杨 杨乐

请分析

#5

由 杨 杨乐 更新于 超过 2 年 之前

【自测结果】
可以复现测试提出的现象，当上传50MB，实际上传为10MB左右
【分析】
从日志看，没有丢包，但是有较多的乱序。现在正在分析两个问题：
1.乱序对速率有没有影响
2.乱序的处理逻辑是否有影响上传的瓶颈点

现在正在分析第二个问题

#6

由 杨 杨乐 更新于 超过 2 年 之前

  • 状态 从 进行中 变更为 转测试
  • 指派给 从 杨 杨乐 变更为 杨 凯

【现象】
当大上行的场景下，进行上行的灌包;上行灌包网速50MB，过一分钟左右会下跌到几十KB，再过一分钟到三分钟左右网速可以恢复，会有规律的复现该问题

【名词解释】
rx_deliv:待发送的下一帧
rx_reord:当前接收帧的下一帧未收到时，会启动reOrder(重排序)定时器

【原因】
当reOrder定时器到期后，会调用函数:on_rb_reord_timer_expiry_ind_received，该函数中会设置rx_deliv的值为rx_order+1;或者缓存中最大帧+1。
根据函数:prepare_pdcp_pdus_for_rx_ind中判断，当前接收的帧等于rx_deliv时满足发送条件;如果rx_order和缓存中待发送的帧号比当前正常接收的帧小的时候,rx_deliv设置错误会导致帧无法发送.
备注：当rx_order收到后，本来应该关闭定时器，但是由于代码机制的原因，当定时函数已经出发了，则无法关闭。此问题只要将rx_deliv修改正常，定时函数无法关闭问题不影响该问题。

【解决方法】
将rx_deliv设置为当前收到帧的缓存集合中大于rx_deliv的帧

【下一步计划】
多复现几次,看是否还有问题，如果没有问题就可以关单了

#7

由 杨 凯 更新于 超过 2 年 之前

  • 状态 从 转测试 变更为 已关闭

1、参数配置及硬件选择
1）基本参数配置：配置上行天线端口为上行2天线，子帧配比为2:1:7大上行配比，MCS=23
2）天线选择CPE普通适配小天线，CPE为高通芯片CPE
3）拉远基站BBU+PRU组网
4）基站版本基于2.1.10P(成研CU)分支
2、复现步骤：
1）终端入网进行CPE上行灌包50M，观察基站侧查看DU-CU、 CU-UPF速率，大概过十几秒出现CU发送UPF的速率掉到几十KB，随后速率可拉起。
2）通过抓包查看分析问题时间段出现seq num乱序现象
3）提取CU日志，反馈开发
3、问题解决：
1）获取CU基于成研的版本支线，进行问题验证，终端接入后进行上行50M灌包，查看基站侧DU-CU、 CU-UPF速率持续20分钟无明显变化
4、测试结论：
问题已解决

#8

由 高 峰 更新于 超过 2 年 之前

  • 状态 从 已关闭 变更为 已解决

导出 Atom PDF