项目

一般

简介

错误 #770

10终端测试中DU对终端释放异常

由 徐 红超 在 超过 3 年 之前添加. 更新于 将近 3 年 之前.

状态:
已关闭
优先级:
普通
指派给:
-
类别:
-
开始日期:
2022-03-03
计划完成日期:
% 完成:

0%

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

描述

10终端反复接入后，终端都掉线后。du显示还有18个终端异常在线，释放不掉。

文件

1.png (62.1 KB) 1.png 徐 红超, 2022-03-03 21:05

历史记录

#1

由 匿名用户 更新于 将近 3 年 之前

  • 状态 从 新建 变更为 进行中
  • 指派给 从 匿名用户 变更为 匿名用户
  • 发现问题版本 从 Rel_2.1.9 变更为 Rel_2.1.10P
  • 目标解决问题版本 从 Rel_2.1.10 变更为 Rel_2.1.11P

多终端测试中，该问题已经大幅解决。但仍然存在偶尔有UE无法释放的情况，需要继续分析定位。
目前由毛加轩定位分析终端释放 timer 异常引起的终端无法释放问题。

#2

由 匿名用户 更新于 将近 3 年 之前

1、问题现象
多UE接入后，DU上报给yzmm的ue个数没有清0；
2、问题定位过程：
（1）整理了因为rlf引起的UE释放问题流程，整个过程设计到多个timer；
（2）对DU的cmGCb.ueLstCp和cmGCb.cmnTq关键数据进行log信息采集；
（3）问题复现时，发现cmGCb.cmnTq中的某个timer信息会突变成0，这样，可能就会导致与此timer同一个entry的其他timer丢失，从而导致其他timer未超时处理；
（4） 而这些未超时却被丢失的timer，就是用来进行ueCB释放的，就是上报给yzmm的UE信息来源，所以这些timer的丢失，就导致了DU未释放干净UE的现象；
（5）通过跟踪这些timer信息突变成0的timer，发现其是属于RBCB的timer资源，而在RLF释放过程中，确实有可能释放RB信息，那么如果发生了释放RB信息，就会到这该RB的timer被free（变成0）；从而导致（3）；
3、问题修复
在kwAmmFreeDlRbCb函数中，free RB之前，如果有启动的EVT_KW_AMDL_STA_PDU_LOST_TIMERtimer，则stop掉。以免RB free时被置0；

#3

由 匿名用户 更新于 将近 3 年 之前

  • 状态 从 进行中 变更为 转测试

问题解决办法：
1、在UE的下行 AM RB释放之前，stop掉相关的Timer
if(TRUE == kwChkTmr((PTR)rbCb,EVT_KW_AMDL_STA_PDU_LOST_TIMER)) {
kwStopTmr((PTR)rbCb, EVT_KW_AMDL_STA_PDU_LOST_TIMER);
}
2、将UE的下行am RB的staPduLostTmr和pollRetxTmr资源，提升到guecb的实体下，这样，即使free rb早了，也不会对timer产生影响；

#4

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

  • 状态 从 转测试 变更为 已解决
#5

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

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

导出 Atom PDF