项目

一般

简介

错误 #988

2.1.11p_pre3版本，多用户上下行同时灌包，有时候出现下行MCS=0，下行bler较大的情况（跑一段时间上行功率饱和）

由 王 旭初 在 超过 2 年 之前添加. 更新于 7 个月 之前.

状态:
挂起
优先级:
普通
指派给:
-
类别:
-
开始日期:
2022-12-07
计划完成日期:
% 完成:

0%

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

描述

du初步定位为：
应该是下行资源分配存在一个问题，前三个UE调度出来一些RB之后，第4个UE存在挺多资源分配不出来，然后仅释放了pdcch，而Pucch没有被释放，造成依然下发了pucch接收的接口消息，这样这个UE的UCI反馈就大量错误，致使MCS降到0了

历史记录

#1

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

从西安和北京环境分析，大上行，大下行都有这个问题，可能是共通的，先合并到一起处理。
log发现的问题：
1. UE 存在较多的下行分不出重传pdcch 的情况，这会导致一个情况，当下行错误需要重传的时候，间隔比较长，UE可能已经释放了HARQ进程，重传全都错误。因为大上行情况下pdcch资源受限；
2. 下行资源分配存在一个问题，前三个UE调度出来一些RB之后，第4个UE存在挺多资源分配不出来，然后仅释放了pdcch，而Pucch没有被释放，造成依然下发了pucch接收的接口消息，这样这个UE的UCI反馈就大量错误，致使MCS降到0了；

修改：
1. 针对大上行，把重传的聚合等级也降低到2，多UE的场景减少冲突而分不出pdcch的情况；
2. 资源分配失败需要释放pucch，把对应pucch从链表中删除，不下发资源分配失败的UE的pucch接收消息；
3. 具体第4个UE下行分配为啥会失败，现在看是重传存在问题，需要再仔细看看，或者添加log复现定位。

#2

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

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

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

除了之前描述释放的问题，还存在format0 PUCCH DTX=1，采数发现终端反馈的PUCCH format0 功率过大饱和；
进一步定位发现基站SSB功率偏低，与Dev修改 CR #970的配置文件默认值有关，3.5G 默认值修改为1100，观测是否还存在饱和

#4

由 高 峰 更新于 大约 2 年 之前

产品部5.8测试4小时，下行没有出现mcs掉0的现象；对别两边的环境差异：
研发： 3.5G 移远模组
产品： 5.8G 广和通模组

怀疑和模组有关

#5

由 王 旭初 更新于 大约 2 年 之前

西安环境又出现长跑稳定性测试过程中，下行MCS掉0的现象，均为移远模组。
观察phy日志，均出现上行饱和打印，同时该终端的下行RSRP变化情况，发现下行RSRP基本是处于一个不变的值，证明基站下发的功率应该是比较稳定。
所以现在需要终端厂商做进一步分析，为啥跑着跑着，上行功率就饱和了

#6

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

  • 状态 从 进行中 变更为 挂起

上行功率饱和，和终端有关系。

#7

由 高 峰 更新于 7 个月 之前

  • 主题 从 2.1.11p_pre3版本，多用户上下行同时灌包，有时候出现下行MCS=0，下行bler较大的情况 变更为 2.1.11p_pre3版本，多用户上下行同时灌包，有时候出现下行MCS=0，下行bler较大的情况（跑一段时间上行功率饱和）

导出 Atom PDF