项目

一般

简介

需求CR #1696

需要减少500UE时的测量报告

由 杨 杨乐 在 大约一年 之前添加. 更新于 12 个月 之前.

状态:
转测试
优先级:
普通
指派给:
周 磊
类别:
需求
开始日期:
2024-04-11
计划完成日期:
% 完成:

0%

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

文件

20240507-152322.jpg (81.8 KB) 20240507-152322.jpg 席 振斌, 2024-05-14 19:30
20240514-192646.jpg (1.17 MB) 20240514-192646.jpg 席 振斌, 2024-05-14 19:35
cu_24_05_14_18_49_41_part_0.log (57.9 MB) cu_24_05_14_18_49_41_part_0.log 席 振斌, 2024-05-14 19:36
20240516-152217.jpg (909 KB) 20240516-152217.jpg 席 振斌, 2024-05-16 15:22
20240516-162020.jpg (1.16 MB) 20240516-162020.jpg 席 振斌, 2024-05-16 16:21
20240516-192505.jpg (145 KB) 20240516-192505.jpg 席 振斌, 2024-05-16 19:25

历史记录

#1

由 杨 杨乐 更新于 大约一年 之前

  • 状态 从 新建 变更为 进行中
#2

由 席 振斌 更新于 12 个月 之前

  • 指派给 从 杨 杨乐 变更为 席 振斌

目前cu通过代码模拟了500ue测量上报的情况，需要先评估500ue时在周期测量上报和事件上报都进行的时候能否支撑，目前是待自测状态

#3

由 席 振斌 更新于 12 个月 之前

通过循环500次模拟500ue的方式不可行，因为相同的sn会被pdcp层的处理阻挡，现在考虑通过计算出处理每一次测量上报的时间来预估

#4

由 席 振斌 更新于 12 个月 之前

#5

由 席 振斌 更新于 12 个月 之前

接了6个终端，5个下行灌包20m, 1个下行灌包10m，周期测量上报为1024ms,通过打印的计算每一帧测量上报的处理时长来看，在这种场景下每一帧测量上报的处理时长为1.1ms。

图片中的时间段的单位为微秒

#6

由 席 振斌 更新于 12 个月 之前


场景为5个终端，大上行的环境，下行灌包总流量为100m， 上行灌包总流量为120m；
周期测量上报的时间间隔为1024ms,从测试结果来看，每一帧测量上报消息的处理时间为1.2ms，预估到500ue就是600ms，600ms是小于时间间隔1024ms的，所以即使是500ue也是来得及处理的，而且我们的发布版本为周期测量上报的时间间隔为2048ms，但是在500ue的场景下cpu应该会很高

#7

由 席 振斌 更新于 12 个月 之前


场景为5个终端，大上行的环境，下行灌包总流量为100m， 上行灌包总流量为120m；
周期测量上报的时间间隔为2048ms,从测试结果来看，每一帧测量上报消息的处理时间为1.2ms，结果和间隔为1024ms一致

#8

由 席 振斌 更新于 12 个月 之前


通过上面的测量结果来预估500ue的话，500ue的测量上报能够处理，测量上报的处理线程为UE_CTRL_THREAD和UL_THREAD/DL_THREAD所绑线程为一核，我们假设用户面的所绑线程cpu占用率达到100%（目前5终端峰值灌包看最高为60%那么UE_CTRL_THREAD线程的占用率为60%，那么如果除了500ue有新的终端接入的话，还有10%的cpu用来处理接入的消息处理，通过看接入的处理消息所用的时间最长的为2ms,还是可以支持50条消息

#9

由 席 振斌 更新于 12 个月 之前

转测试，等测试有实际的500ue环境了再实测一下

#10

由 席 振斌 更新于 12 个月 之前

  • 状态 从 进行中 变更为 转测试
  • 指派给 从 席 振斌 变更为 周 磊

导出 Atom PDF