精品案例5G调度次数和调度RB数不足分析研究.docx

1、精品案例5G调度次数和调度RB数不足分析研究5G调度次数和调度RB数不足分析研究5G调度次数和调度RB数不足分析研究【摘要】5G网络上传下载速率与RB调度次数及RB数分配有很强的关系，RB的调度次数及RB数的分配直接影响5G的上传下载速率。【关键字】调度 RB【业务类别】参数优化一、基本概念1.1下行速率的计算方法下行速率 = PDCCH DL Grant0 * TBSize0 （RE，MCS0，Layer0）* （1 - BLER0） + PDCCH DL Grant1 * TBSize1 （RE，MCS1，Layer1）* （1 - BLER1）PDCCH DL Grant0/1：两个码字

2、对应的下行每秒调度次数；TBSize0/1：由MCS、RE数（Slot内RB数、RB内可用的符号数）、码子映射流数决定；BLER0/1：误码率；Layer0/1：调度的RANK映射到每个码字上的流数。从速率计算公式可以看出，5G速率的直接影响因素有RANK、MCS、BLER、Grant/s、RB/Slot。其中RANK、MCS、BLER主要与空口因素强相关，而Grant/s和RB/Slot主要受调度异常或来水不足影响。下行每秒调度次数和下行每slot调度RB数是直接影响下行速率的两个关键因素。1.2调度次数计算TDD制式下：下行调度次数与子载波间隔（SCS），上下行子帧配比相关如当SCS =

3、30kHz（NRDUCELL: SubcarrierSpacing）时，每个slot的长度为0.5ms，调度的基本时间单位是slot, 因此每秒调度次数（上行+下行）= 1000/0.5=2000次TDD情况下：确认TDD上下行时隙配比（NRDUCELL: SlotAssignment），如时隙配比4:1或8:2（下行时隙：上行时隙），下行调度次数 = 2000 * 0.8 = 1600上行调度次数 = 2000 * 0.2 = 400如时隙配比7:3下行调度次数 = 2000 * 0.7 = 1400上行调度次数 = 2000 * 0.3 = 6001.3RB个数协议定义RB个数根据协议查表

4、：参考TS38.104 Table 5.3.2-1和5.3.2-2例如：Bandwidth = 100MHz，SCS = 30kHz，RB个数 = 273. 1.4调度次数和RB数观测手段1.Probe/Assistant：下行调度统计在Radio Measurement页签的PDCCH DL Grant Count与PDSCH RB Number/Slot项，上行调度统计在Radio Measurement页签的PDCCH UL Grant Count与PUSCH RB Number/Slot项。其中，NRPCCPDSCHRBNumber/Slot 约等于NRPCCPDSCHRBNumber

5、/s 除以 NRPCCPDCCHDLGrantCount。如下图所示1.5分析切入点如果单用户上行/下行定点和拉网测试时“PDCCH UL Grant Count”或“PDCCH DL Grant Count”远低于理论值，“PUSCH RB Number/Slot”或“PDSCH RB Number/Slot”远低于理论值，则需要进一步分析。1.6总体定位思路如下因素会影响到调度次数和RB：1.AMBR限速：核心网开户速率低2.背景用户占用资源3.异常告警4.PDCP处理异常：缓存满/超时丢包，PDCP SN长度配置，PDCP-RLC转发异常等5.RLC处理异常：RLC模式设置错误、RLC重

6、传多，发送窗口异常，组包异常等6.MAC调度异常：PDCCH资源分配，PUCCH资源分配等7.下行DCI漏检：PDCCH调度，但是终端未检测到DCI等8.CCE资源不足导致调度失败9.异频GAP导致NR侧调度失败10.控制面问题导致调度不足11.空口残留误码导致调度不足12.来水量不足：终端、服务器或者传输受限；二、问题分析定位排查2.1 正向排查2.1.1 AMBR限速排查有时候会出现这样一种情况，调度次数和RB数不足，但是UE测看到RANK、MCS阶数和误码情况都正常，速率一直无法突破某一个值。基站侧CellDT537看确实调度次数不足，但没有出现错误码。或者是在一般情况下调度正常，但是开

7、启了一些可以增加吞吐量的特性（256QAM等）之后出现调度次数不足。这时候很可能是出现了AMBR限速情况，需要确认核心网开户速率是否足够。UE AMBR限制了UE的Non-GBR速率，NSA场景下UE AMBR信息可以通过S1口跟踪S1AP_INITIAL_CONTEXT_SETUP_REQ或者X2口SgNB_Add_Req进行查看，SA场景下可以通过NG口NGAP_INIT_CONTEXT_SETUP_REQ 进行查看，AMBR信元的单位为bps。除了开户限速之外核心网还有一个APN限速，用户使用该APN时无法超过该限速速率。通过路测log中的attach accept消息能够查询到APN

8、AMBR，APN AMBR的换算可以参考如下excel小工具进行计算。UE AMBR限制了UE的Non-GBR速率，APN AMBR限制了UE每个APN的速率。SA场景查看PDUSessionEstablishmentAccept信息里的Session AMBR, 单位是1Mbps2.1.2 多用户调度排查1.多个用户同时测试会分散调度资源，导致测试用户无法达到满调度次数和满RB数。可以跟踪U2000小区在线用户数，分析是否有背景用户如下图2.CellDT分析方法：537中字段“UserNum”显示了当前待调度用户数，如果为1即只有一个用户调度，如果大于1表明有其他用户同时在进行业务。字段“S

9、chSccUserNum”表示当前slot调度成功的用户数，如果大于1，即表明有多个用户在这个slot调度并消耗了RB资源，此时对单个用户来讲，调度次数和RB数会无法调满。3.OSS KPI指标分析方法：查看上下行的RRC激活用户数平均值和最大值判断是否存在背景用户影响：2.1.3异常告警排查重点排查射频单元电源能力不足告警、射频单元温度异常告警以及传输相关告警：2.1.4参数核查参数核查涉及到Default QCI对应的PDCP/RLC层的参数组核查，因此需要先确定网络中使用的Default QCI是哪个。Default QCI信息NSA可以通过S1口跟踪S1AP_INITIAL_CONTE

10、XT_SETUP_REQ、X2口SgNB_Add_Req、Probe log中的Attach Accept进行查看，SA场景下可以通过NG口NGAP_INIT_CONTEXT_SETUP_REQ 进行查看。获取到Default QCI信息后，可通过LST NRCELLQCIBEARER: Qci=xx;命令查看相对应的QCI的“RLC模式”信息，若RLC模式为AM，则查看“AM模式PDCP参数组标识”, 通过LST NRDUCELLQCIBEARER: Qci=xx;命令查看相对应的QCI的“AM模式RLC参数组标识”; 若RLC模式为UM，则查看“UM模式PDCP参数组标识”, 通过LST

11、NRDUCELLQCIBEARER: Qci=xx;命令查看相对应的QCI的“UM模式RLC参数组标识”2.1.4.1 PDCP层参数核查PDCP层重排序：PDCP层若收到乱序包，则启动t-Reordering定时器，如果t-Reordering超时，则先将buffer中乱序SDU前面的所有SDU强制递交给上层，并将接收窗口往右移，中间没在t-Reordering定时器超时前收到的包交给上层（如TCP、应用层）来重传。若后续强制递交的乱序包如果收到则直接丢弃。通过上面的方法查询到PDCP参数组标识之后，通过命令LST GNBPDCPPARAMGROUP查询各PDCP参数设置如下是PDCP层的关

12、键参数配置建议值，建议非特殊场景都按照建议值来设置：MOParameter IDQCI9 Recommended ValueQCI9 Current ValuegNBPdcpParamGroupPdcpParamGroupIdNone5(3)gNBPdcpParamGroupDlPdcpDiscardTimerINFINITYINFINITY(3)gNBPdcpParamGroupUlPdcpDiscardTimerINFINITYINFINITY(3)gNBPdcpParamGroupgNBPdcpReorderingTimerMS300MS300(3)gNBPdcpParamGroupUe

13、PdcpReorderingTimerMS300MS300(3)gNBPdcpParamGroupDlPdcpSnSizeBITS18(18)BITS18(3)gNBPdcpParamGroupUlPdcpSnSizeBITS18(18)BITS18(3)gNBPdcpParamGroupPdcpReportPollingPeriodMS10(10)MS10(3)案例：1.滁州电信定点CPE测试速率频繁掉坑，经过初步分析，速率掉坑基本可以判定是无线侧原因导致的。速率掉坑的时候MCS阶数下降以及256QAM的比例大幅下降，同时IBLER和RBLER变大（在IBLER的变化不大的情况下，RBLER

14、的变化异常，这会导致空口TCP丢包重传，TCP窗口收缩从而导致下行调度次数和RB数也降低）。通过参数核查，发现默认QCI 9的DLPDCPSNSIZE 设置为bit12, 而DLRLCSNSIZE设置为bit18, 这会导致PDCP接收侧有超帧号失步的风险（某个RLC SDU多次重传，且新传包不断下发，UE PDCP接收侧SN将翻转，导致乱序），会导致流量波动掉底。需要将QCI9的DLPDCPSNSIZE设置为与DLRLCSNSIZE一致。参数修改后，掉坑问题解决。2.一线CPE测试UDP灌包只有450+Mbps。需要提升到600Mbps。经分析，服务器往下灌包速率为1Gbps,但从Probe

15、看下行Grant调度次数只有1000次/秒。经参数核查，DlRlcSnSize 设置为12，导致RLC的最大窗口数只有2048 2(12-1)，无法满足高速率的需求，改为基线值18bit之后复测，速率达到600+Mbps；2.1.4.2 RLC层参数核查RLC层重传：当MAC层HARQ 4次重传失败之后，进入RLC层重传。当发送端主动轮询或接收端RLC重组定时器超时，即接收端探测到AMD PDU丢失，便通过status report来通知发送端重传该丢失PDU。AM模式最大重传次数由参数UeMaxAmRetransNum和gNBMaxAmRetransNum控制，默认为最大值32次。如果超出最

16、大重传次数，RLC会向上层发出超出最大重传次数通知，链路失败，引发掉话同理，在获得AM模式RLC参数组标识之后，可通过命令LST GNBRLCPARAMGROUP: RlcParamGroupId=xx;查看对应的RLC参数组如下是RLC层的关键参数配置建议值，建议非特殊场景都按照建议值来设置：MOParameter IDQCI9 Recommend ValueQCI9 Current ValuegNBRlcParamGroupRlcParamGroupIdNone3(3)gNBRlcParamGroupRlcModeAM(AM)AM(3)gNBRlcParamGroupUeAmByteThl

17、dForTrigPollKB25(25)KB25(3)gNBRlcParamGroupgNBAmByteThldForTrigPollKB25(25)KB25(3)gNBRlcParamGroupUePduNumThldForTrigPollPDU32(32 PDUs)PDU32(3)gNBRlcParamGroupgNBPduNumThldForTrigPollPDU32(32 PDUs)PDU32(3)gNBRlcParamGroupUePollingPduRetransTimerMS40(40)MS40(3)gNBRlcParamGroupgNBPollingPduRetransTime

18、rMS40(40)MS40(3)gNBRlcParamGroupUeAmStatusRptProhibitTmrMS40MS40(3)gNBRlcParamGroupgNBAmStatusRptProhibitTmrMS40MS40(3)gNBRlcParamGroupgNBRlcReassemblyTimerMS40(40)MS40(3)gNBRlcParamGroupUeRlcReassemblyTimerLow Frequency MS40(40)MS40(3)gNBRlcParamGroupDlRlcSnSizeBITS18(18)BITS18(3)gNBRlcParamGroupUl

19、RlcSnSizeBITS18(18)BITS18(3)案例：滁州电信局点使用测速软件进行测试的时候发现，上行每隔10s速率掉坑一次，非常有规律性，下行速率也存在比较严重的掉坑。掉坑前IBLER误码率升高，掉坑时调度的RB数和调度次数也掉坑。查看配置发现RLC层相关参数配置有问题导致。RLC层的几个轮询触发参数UE侧和gNB侧都设置为Infinity，也就是说发送端不通过RLC层发送的PDU数量或者字节数来触发轮询，这会导致发送端RLC层无法及时清空发送缓存，直到发送缓存满或者发送窗口满或者轮询定时器超时之后才会触发轮询来要求接收端回复状态报告，所以会导致速率掉坑！ 2.1.5空口MAC层灌包

20、问题隔离排查空口MAC层灌包功能，可验证空口性能、基站调度性能是否正常，如果空口灌包结果远好于FTP下载或speedtest，则很大可能是基站以上来水不足导致的速率低。灌包时重点观察下行调度次数和RB数是否接近理论值。如果无法接近理论值，可能是有背景用户或者异频GAP等导致的调度异常。1.通过测试终端连续PING n字节，如10002.将PING n字节的用户从后台使用DSP GNBUEBASICINFO捞出来，如1000字节，获得Random Value3.使用STR GNBMACPADDINGTEST命令，输入RANDOM VALUE进行灌包测试，4.在Probe上或后台用户monitor

21、ing观察灌包速率：2.2 参数配置分析对于下行调度不足的分析，需要采集CellDT 537/3201初步判断调度不足的原因。对于上行调度不足的分析，需要采集CellDT 490/3201初步判断原因。2.2.1 调度失败通过Cell DT信令跟踪，统计实际基站侧下发的调度次数，如果调度次数远大于终端接收次数，即存在终端漏检问题。CellDT602跟踪，统计所选定CRNTI用户1秒内：COUNT(PDCCH_DCI_FORMAT_D1_0(8)+COUNT(PDCCH_DCI_FORMAT_D1_1(9)为下行DCI个数，如果Probe中NR PCC PDCCH DL Grant Count次

22、数明显少于602跟踪中DCI个数，则存在下行DCI漏检。 COUNT(PDCCH_DCI_FORMAT_D0_0(0)+COUNT(PDCCH_DCI_FORMAT_D0_1(1)为上行DCI个数，如果Probe中NR PCC PDCCH UL Grant Count次数明显少于602跟踪中DCI个数，则存在上行DCI漏检；进一步采集CellDT L2 537/328/602/606/490/715/747/776/777，反馈总部研发分析具体漏检原因。CCE分配失败可以基于537跟踪的“schErrCode”字段分析，正常调度成功“schErrCode”为0x0值，异常调度失败时“schEr

23、rCode”为非0值。当出现“schErrCode”为0xc0129为CCE比例受限。2.2.2 HARQ进程失败分析下行调度，HARQ资源分配失败是比较常见的错误，HARQ资源耗尽后会导致调度不足现象。分析方法：基于537跟踪，字段“tb0AckState”是基站收到终端反馈的记录，“0”对应的HARQ_NACK，“1”对应的是HARQ_ACK，“2”对应的是HARQ_DTX，如果HARQ_DTX比例较高（以5%为门限）会快速耗尽HARQ进程，需要反馈总部研发做详细分析。2.2.3 PUCCH分配失败分析先看537跟踪，观察“schErrCode”字段是否有“0xd0003”定界是否有PUC

24、CH资源不足导致的异常。PUCCH资源分配只与L3配置相关，若是分配出现异常直接检查配置。1）L3检查PUCCH相关配置 LST NRDUCELLPUCCH是否为基线推荐值2）UU口跟踪观察PUCCH的资源分配情况 RRC_CONN_RECFG。排查方法：获取终端侧或NR X2标口跟踪，观察终端侧NR添加重配置消息或X2:SGNB_ADD_ACK里是否配置PUCCH资源，如下图所示： 2.2.4 CCE资源不足导致调度失败先看537跟踪，观察“schErrCode”字段是否有“0xd0331”定界是否有CCE资源不足导致调度失败的异常。场景1：pdcch RateMatching打开，Occp

25、uiedRbNum配置为2，上行配额超过50%pdcch RateMatching开关打开时，pdcch可用的RB资源由OccupiedRbNum来做约束；峰值场景下，会将OccpuiedRbNum配置为2，对应4个CCE，预期上下行配额必须为50%，这样上下行共slot时，上下行都有2cce，而每个UL Grant/DL Grant至少需要2cce；如果上行配额配置超过50%时，会导致下行调度失败。规避方案：1、上行CCE比例配置为50%Note: PDCCH上下行CCE比例自适应配置：通过打开参数NRDUCellPdcch.PdcchAlgoSwitch下子开关“UL_DL_CCE_RAT

26、IO_ADAPT_SW”启动自适应动态配置，该功能启动后参数NRDUCellPdcch.UlMaxCcePct的配置无效，上下行可用的CCE资源比例会根据上下行CCE需求情况，CCE资源利用率等进行自适应调整。2.2.5 智能功率锁打开导致调度不足SA/NSA好点峰值测试，使用Mate20x速率只能达到600Mbps左右，该小区同一地点原先能达到1.5Gbps。需要分析峰值速率上不去的原因。基站版本：V100R015C10SPC170。分析测试Probe日志， SSB RSRP，SINR都很好，但下行调度次数稳定在1200次左右，无法达到1600，Slot级RB统计250+，且RANK/MCS

27、/iBLER都比之前要差。使用FMA对CellDT 537进行分析，发现调度有错误码0x11013a，占比24.18%，对速率造成了很大影响（调度正常应该是0x0）经与研发确认，出现该错误码主要可能由几个原因造成：现网打开了智能功率锁，功率汇聚，或者高温、用户很多等。经排查，现网没有打开功率汇聚、也没有高温相关告警、同时用户数也不多，但是智能功率锁设置为1，即打开了智能功率锁（打开原因可能是客户在做EMF测试，测试完后忘了回退参数）将智能功率锁功能关闭后进行复测，速率恢复正常，有1.5Gbps以上，调度1600次左右，MCS、RANK、IBLER都大大提升NRDUCELLSMARTPWRLOC

28、K: NrDuCellTrpId=XX, SmartPowerLockSw= Average Power Control Switch:Off2.2.6 控制面问题导致调度不足NSA测试中最常见的就是LTE和NR出现异常事件（释放、重建、随机接入失败）会导致调度次数出现13秒左右的调度不足甚至掉0的情况。因此，在排查调度不足时需要关联L3异常事件分析，是否存在时间相关性。当确定调度次数与异常事件强相关时，走切换掉话指导书进行定位。下图是Assistant关键事件列表，方便快速识别异常事件。 2.2.7 空口残留误码导致来水不足当空口出现残留误码的时候，表明4次HARQ重传都失败了，然后触发RL

29、C层的重传。当前每次HARQ重传耗时约10ms，每次RLC重传间隔约40ms。残留误码导致空口时延突增，由于出现空口残留误码，导致终端长时间收不到报文，回复大量Duplicate ACK。D-ACK一方面会导致发送窗口减小；另一方面，可能导致服务器发包停止，服务器只有在收到发送包的正常ACK后TCP发送窗口才能向前滑动，继续发包。这种情况下，会出现来水不足的现象使吞吐率掉坑。2.2.8 来水量不足分析Cell DT跟踪内记录了当前缓存待调度数据量，“waitingData”为当前缓存内待调度数据量，“tb0TbByteLenth”为当前TTI调度的TBsize（bytes），当出现“tb0Tb

30、ByteLenth”=“waitingData”即代表缓存数据调度清空，意味着来水量不足现象存在，调度次数和RB次数下降。当出现来水不足时，需要排查来水不足原因，若是FTP/TCP灌包/HTTP下载等，可进入TCP问题分析需要注意的是：对比“waitingData”和“tb0TbByteLenth”大小时，需要过滤“Tb0RetransTimes”为0即初传数据。三、案例3.1 智能城域网传输侧限速导致Speedtest及FTP测试只有10Mbps左右 问题现象：滁州电联共享5G FTP测试及speedtest测试，上传下载速率均在10M左右。 问题分析：1.滁州电联与合肥电联共享站点，测试对

31、比，合肥站点数据业务正常（1Gbps），滁州站点速率只有10M左右。两地市公用一套核心网及服务器，初步排除核心网及服务器问题。 2.根据信令分析及核心网核查，SIM卡上行限速5G，下行限速5OOM，测试卡正常。3.基站侧信令跟踪分析及灌包测试，基站侧灌包测试下载速率1.2Gbps.信令跟踪分析分析过程：celldt分析：1、下行速率非常低，基本在12M左右，现场灌包测试速率在1.1G以上，可排除基站、空口问题导致下行速率异常问题。2、下行存在大量缓存数据为0表明来水不足的情况。3、下行RB数稳定在265以上。4、下行MCS基本保持在27左右。5、无明显slot高误码6、无调度错误解决方案：经排查，核心网，终端 SIM卡、基站侧等都不存在问题，问题提点直指传输侧，经核查各地市的传输设备，滁州电联共享站点，传输侧智能城域网，传输端口做了限速，限速10M,导致站点速率低。修改端口传输速率后解决。3.2 核