项目

一般

简介

错误 #572

API丢失

周 磊将近 4 年 之前添加. 更新于 大约 2 年 之前.

状态:
已解决
优先级:
普通
指派给:
-
目标版本:
开始日期:
2021-06-24
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
DU
CPU类型:

描述

简述:API丢失
测试环境:246
测试版本:rel2.1.6
测试问题:24h常保测试,出现api丢失

历史记录

#1

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

[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlSchedK0K1: K0 Alloc success, cellTime(668:7) pdschTime(668:13) pucchTime(668:17)
[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlSchedK0K1:K0 Alloc success ,cellId:1 ueId:17020 k0Idx:0 k0:0 dlIdx:13 k1Idx:2 k1:4 remDlUePerTti:2 numDlPdcchAvail8
[06-23 06:22:56.182][DEBUG][GENSCH][DL]: Scheduling UE 17020 cell 1 proc 11 for totalBo 2191
[06-23 06:22:56.182][DEBUG]rgSchDedAllocResAndRateMatch: cellId(1) pdschRsrcIdx(0) minRBReq(1) maxRBReq(21) sfn(668) slot(7) isRetx(0)
[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlAlloc1CwTxRb:ueid17020 effBo2226 imcs20 tbSz2304 bo2191 procId11 rbsAllc21 bwAssigned0 rateMatchInput.mcs20
[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlAllocTxRb: crntTime[668 7] ue:17020 total:2191
[06-23 06:22: 56.182 ][DEBUG]rgSCHCmnFillHqPPucch: ue17020 crntTime[668 7] harqId11 rv0 pucchResIdx0 harqBitSize1 cDaiAbs0 pdcchTime[668 13] pdschTime[668 13] hqP-pucchTime[668 17] pucchTime[668 17] 调度
[06-23 06:22:56.182][DEBUG]DCI_1_1: PRI: bit len: 3 value: 0 bitIdx:37

[06-23 06:22:56.182][DEBUG]Add Dl Hq To Slot: UE17020 cell1 proc11 slotIdx13 crntTime[668 7] pdschTime[668 13] listNode[0x7ffe79588f58] hqP[0x7ffe79588808]
[06-23 06:22:56.182][DEBUG][GENSCH 0][DL] crntTime[668 7]:TB Dstn Idx 0 TB Size 2304 effAlloc 2304 cellId 1
[06-23 06:22:56.182][DEBUG][GENSCH][DL]:UE 17020 TB Dstbn LC 4 Bo 2191 totalbo 2206 rlcHdrEstmt 15
[06-23 06:22:56.182][DEBUG][GENSCH][DL] : cellId 1 Ue 17020 lc 4 schdbo 2206 remBo 0
[06-23 06:22:56.184][ERROR]ctrlReq->dlPdcchLst.count=1,datReq=NULL,datReqSf=13 API丢失
[06-23 06:22:56.186][DEBUG]Rmv Dl Hq Frm Slot: cell1 proc11 slotIdx13 crntTime[668 14] pdschTime[668 13] listNode[0x7ffe79588f58] hqP[0x7ffe79588808]
[06-23 06:22: 56.186 ][DEBUG]kwAssembleSdus: BO after assembly = 4848 RBID:1 UEID:17020 CELLID:1
[06-23 06:22:56.186][DEBUG]kwUtlSndToLi: Ue17020 boRptIdx87 boRpt4848 sduCnt8

调度时刻在56秒182毫秒,sfn slot [668 7] pdsch [668 13]
而RLC组包被延迟到了 sfn slot [668 14],导致早过了发送PHY接口的时间,
但是本次延迟并不是由于之前观察到的任务堆积造成的,
延迟的时间接近4ms,原因还未明确。

#2

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

huang xiwen 写到:

[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlSchedK0K1: K0 Alloc success, cellTime(668:7) pdschTime(668:13) pucchTime(668:17)
[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlSchedK0K1:K0 Alloc success ,cellId:1 ueId:17020 k0Idx:0 k0:0 dlIdx:13 k1Idx:2 k1:4 remDlUePerTti:2 numDlPdcchAvail8
[06-23 06:22:56.182][DEBUG][GENSCH][DL]: Scheduling UE 17020 cell 1 proc 11 for totalBo 2191
[06-23 06:22:56.182][DEBUG]rgSchDedAllocResAndRateMatch: cellId(1) pdschRsrcIdx(0) minRBReq(1) maxRBReq(21) sfn(668) slot(7) isRetx(0)
[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlAlloc1CwTxRb:ueid17020 effBo2226 imcs20 tbSz2304 bo2191 procId11 rbsAllc21 bwAssigned0 rateMatchInput.mcs20
[06-23 06:22:56.182][DEBUG]rgSCHRsrcDlAllocTxRb: crntTime[668 7] ue:17020 total:2191
[06-23 06:22: 56.182 ][DEBUG]rgSCHCmnFillHqPPucch: ue17020 crntTime[668 7] harqId11 rv0 pucchResIdx0 harqBitSize1 cDaiAbs0 pdcchTime[668 13] pdschTime[668 13] hqP-pucchTime[668 17] pucchTime[668 17] 调度
[06-23 06:22:56.182][DEBUG]DCI_1_1: PRI: bit len: 3 value: 0 bitIdx:37

[06-23 06:22:56.182][DEBUG]Add Dl Hq To Slot: UE17020 cell1 proc11 slotIdx13 crntTime[668 7] pdschTime[668 13] listNode[0x7ffe79588f58] hqP[0x7ffe79588808]
[06-23 06:22:56.182][DEBUG][GENSCH 0][DL] crntTime[668 7]:TB Dstn Idx 0 TB Size 2304 effAlloc 2304 cellId 1
[06-23 06:22:56.182][DEBUG][GENSCH][DL]:UE 17020 TB Dstbn LC 4 Bo 2191 totalbo 2206 rlcHdrEstmt 15
[06-23 06:22:56.182][DEBUG][GENSCH][DL] : cellId 1 Ue 17020 lc 4 schdbo 2206 remBo 0
[06-23 06:22:56.184][ERROR]ctrlReq->dlPdcchLst.count=1,datReq=NULL,datReqSf=13 API丢失
[06-23 06:22:56.186][DEBUG]Rmv Dl Hq Frm Slot: cell1 proc11 slotIdx13 crntTime[668 14] pdschTime[668 13] listNode[0x7ffe79588f58] hqP[0x7ffe79588808]
[06-23 06:22: 56.186 ][DEBUG]kwAssembleSdus: BO after assembly = 4848 RBID:1 UEID:17020 CELLID:1
[06-23 06:22:56.186][DEBUG]kwUtlSndToLi: Ue17020 boRptIdx87 boRpt4848 sduCnt8

调度时刻在56秒182毫秒,sfn slot [668 7] pdsch [668 13]
而RLC组包被延迟到了 sfn slot [668 14],导致早过了发送PHY接口的时间,
但是本次延迟并不是由于之前观察到的任务堆积造成的,
延迟的时间接近4ms,原因还未明确。

已增加了新的log,待问题复现继续分析。

#3

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

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

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

对于API丢失的问题,在4天线测试过程中已经完整追溯到根本原因:
1.MAC UE task与RLC DL UE task使用同一个 pending info;
2.DL status PDU的处理与下行RLC组包的处理同属于RLC DL UE task处理;

在存在不少错误的情况下,DL status PDU中的NACK info会累积得比较多,处理时延增大,从而导致来不及进行下行RLC组包,就到了数据需要发送给PHY的时刻,
接口上仅发送了pdcch,而没有发送pdsch数据,出现API lost。

目前接收CU的数据,处理status pdu以及下行组包这几个事件都会对 sduQ进行处理,所以下行组包不能跳过status pdu的处理,
因此目前无法通过简单的调整任务和事件优先级来解决该问题。
必须重新设计sduQ的处理机制,解耦MAC UE task 和 RLC DL UE task去解决该问题。

#5

由 匿名用户 更新于 大约 2 年 之前

  • 状态进行中 变更为 已解决

导出 Atom PDF