项目

一般

简介

错误 #5314

3.2.2_Pre1T3版本有多余指标残留

由 牛 兵桃 在 大约 2 个月 之前添加. 更新于 27 天 之前.

状态:
转测试
优先级:
一般
指派给:
牛 兵桃
开始日期:
2026-05-20
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
CU
发现问题版本:
Rel_3.3.2
目标解决问题版本:
Rel_3.3.2

描述

3.2.2_Pre1T3版本有多余指标残留：
14号终端实际已经不在线，但是指标有残留，指标残留如下图所示：
下来按照振斌的方法尝试复现，确认最终原因；

文件

1.png (244 KB) 1.png 残留指标如图所示 牛 兵桃, 2026-05-20 17:03

历史记录

#1

由 席 振斌 更新于 大约 2 个月 之前

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

由 席 振斌 更新于 大约 2 个月 之前

释放流程相关的日志模块未打开，日志不全，没有报文，有个怀疑场景，已给测试人员提供复现方法，待测试复现后定位

#3

由 席 振斌 更新于 大约一个月 之前

需要解决以下3个问题：
1、解决500ms延时问题；需要再考虑
2、内部释放保底流程不能使用inactive timer；
3、在释放期间此上下文不再处理f1、ng、rrc消息；

#4

由 席 振斌 更新于 大约一个月 之前

【问题原因】
1、没有报文，通过cu日志分析来看，终端接入时回复安全模式完成信令的时间和创建srb2对应的重配置完成信令花费时间加起来超过2s，导致基站侧UE接入超时限制定时器超时，ue上下文处于释放过程中，接收到核心网的UEContextReleaseCommand时，等待inactive timer超时后会给du发送UEContextReleaseCommand，但是此时inactive timer还未超时马上又收到了来自终端的重配置完成信令，收到重配置完成信令后基站会停止 inactive timer,所以释放流程中断；
2、原来的代码逻辑有问题，如果是cu因定时器超时导致的释放流程，在接收到核心网的UEContextReleaseCommand后，没有立即给du下发UEContextReleaseCommand，要等到inactive timer超时才会下发，这样会导致2条command有500ms的时延

【修改方案】
1、更换释放流程的定时器，不混用inactive timer；
2、修改代码逻辑解决同一释放流程中2条UEContextReleaseCommand之间的500ms时延问题；
3、在ue上下文处在释放流程中时，拦截rrc、f1ap、ngap的信令

【回归方法】
1、出2个包，一个是做了上述3个修改方案后的包，用来验证随机接入、service request，vonr及切换后的释放流程等基本场景；
2、一个是打桩包用来构造一下问题单发生时的场景，验证问题单；

#5

由 席 振斌 更新于 27 天 之前

  • 状态 从 进行中 变更为 反馈
  • 指派给 从 席 振斌 变更为 杨 杨乐
#6

由 杨 杨乐 更新于 27 天 之前

  • 状态 从 反馈 变更为 审视
#7

由 杨 杨乐 更新于 27 天 之前

  • 状态 从 审视 变更为 转测试
  • 指派给 从 杨 杨乐 变更为 牛 兵桃

导出 Atom PDF