项目

一般

简介

错误 #1311

K项目外场问题复现：终端重新接入后或者重建立之后service request之后，上行业务正常，ping不通

由 陈 晓盟 在 超过一年 之前添加. 更新于 超过一年 之前.

状态:
已解决
优先级:
普通
指派给:
陈 晓盟
类别:
gNB-CU
开始日期:
2023-09-12
计划完成日期:
% 完成:

0%

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

描述

基站版本：el_2.1.14P_Pre1_Xeon
核心网版本：YZ-Core50000_Rel_3.0.8
问题描述：
终端重新接入后或者重建立之后service request之后ping不通

文件

k项目复现log.zip (36.2 MB) k项目复现log.zip 陈 晓盟, 2023-09-12 18:22

历史记录

#1

由 匿名用户 更新于 超过一年 之前

  • 状态 从 新建 变更为 转测试
  • 指派给 从 匿名用户 变更为 陈 晓盟

与测试人员商量后决定:这个单子只用于跟踪"终端重新接入后或者重建立之后service request之后ping不通"的问题,只做ping,不灌包
由于目前没有log,所以需要复现

#2

由 匿名用户 更新于 超过一年 之前

  • 状态 从 转测试 变更为 挂起

一直未复现,所以挂起

#3

由 匿名用户 更新于 超过一年 之前

  • 状态 从 挂起 变更为 进行中
  • 问题归属 DU 已添加

K项目外场测试发现，上行业务通的时候，ping不通问题：
原因是下行pdcch无法分配，上行误码较大，dci聚合等级已经调整到lvl4，而每个UE lvl4仅有两个candidate，且上行调度提前量比下行早，导致有持续的上行业务的时候，大上行子帧配比情况下，上行用完了lvl4 candidate，从而导致下行分配不出来pdcch。

DU已经给出解决方案，并修改了Candidate配置和聚合等级调整的门限，保证在该场景下，不会出现PDCCH耗尽的情况。

#4

由 匿名用户 更新于 超过一年 之前

  • 主题 从 K项目外场问题复现：终端重新接入后或者重建立之后service request之后ping不通 变更为 K项目外场问题复现：终端重新接入后或者重建立之后service request之后，上行业务正常，ping不通
  • 状态 从 进行中 变更为 已解决

导出 Atom PDF