速率低排查基站侧详解.docx

1、速率低排查基站侧详解1.1业务速率类相关1.1.1业务速率低1.1.1.1TCP业务速率低BLER 当速率低时首先关注BLER，尤其是残留BLER。由于FTP是双向的，因此上下行BLER都需要关注。如果初始BLER大于10%或者有残留BLER，需重点关注。对于下行BLER，需要先确认终端侧是否也有BLER。如果终端侧没有bler，则可能是基站ACK译码错误或终端没有检到PDCCH，首先检查测试小区是否配置了异频临小区，如果配置了，需确保“MAC测试开关”中的“测量GAP处理开关”为“打开”。如下图【位于小区测试开关MAC测试开关】如果终端侧的BLER与基站接近（TDD反馈采用bundling模

2、式，终端侧bler比基站侧低一些也是合理的），需要确认是否空口环境较差，查看终端侧的SNR和RSRP，好点SNR应大于20；也可尝试基站关闭下行AMC，固定MCS为较低等级看BLER是否消除，如果bler随MCS降低而降低，则可基本确认是环境问题。如果BLER与MCS无关需查看是否有时钟相关告警，通过LMT查看RRU底噪上下行增益等，需提取RRU的65号日志。从LMT查看底噪，如下图提取RRU日志的方法：【菜单-日志管理RRU日志】对于上行BLER，通过LMT查询上行IOT信息确认是否有干扰，也可以通过关闭上行AMC，固定MCS为较低等级看BLER是否消除，如果BLER随MCS降低而降低，则基

3、本确认是环境问题。如果确认是BLER导致可以参考PL关于BLER问题定位方案。MCS如果存在BLER，则CQI修正会将MCS修低，需要先解决BLER因素。如果没有BLER但MCS较低，需要确认MAC测试开关中的AMC开关是否打开，是否限制最高MCS等级。如果开关设置无异常，需要确认终端反馈的CQI是否正常，通过基站ATP画图“码字0 CQI”可以查看。如果CQI值较低，需要确认终端上报值是否正常，还需检查“信道与信道与过程”配置中的“信道质量指示”参数中 “与ACK同时上报指示”是否设为“支持”。小区信道过程配置信道质量指示参数数据包如果底层正常，但速率仍然较低，通过基站ATP画图查看PDCP

4、吞吐量。如果时间允许，可以通过上下行同时打BO进行验证，如果打BO MAC吞吐量正常的话可以基本排除底层问题。如果打BO不好操作，可以使用上下行UDP灌包进行测试。如果PDCP收到的数据量就少，需要查看基站驱动收到的数据量是否正常。驱动NP数据量查看方法：在SCTA控制台上输入命令npsc，其中有两个计数IGRESS_IP_GTPU_PKT_CNT（下行方向）和EGRESS_IP_GTPU_PKT_CNT（上行方向），这两个计数记录了gtpu包的个数，可以间隔10秒钟输入两次npsc得到两个计数cnt1和cnt2，那么粗略的计算方法为（cnt2 cnt1）* pkt_length * 8 /

5、time （单位：bps），其中pkt_length为报文的长度加上外层头长度，如果不确定长度可以取1500做近似计算，8为一个字节8个比特，time为10秒，这种计算方法有误差，如果误差与pdcp在10M以内，可视为一致。SCTE板卡没有npsc命令，可通过lmt查询【物理设备-机架-机框-板卡-以太网端口】如果怀疑NP有丢包，可以提取SCT板卡上的71号日志。如果怀疑传输、EPC丢包需要各方同时wireshark抓包确认。基站外因素如果上述3步都未发现异常，则需向上逐步排查，分别查看传输是否正常、核心网是否正常、服务器是否正常、终端是否正常等。列出几个常见的可能影响FTP速率的因素供参考。

6、线程数空口环境不稳，难免有少量BLER，且FTP单线程速率随时延增大而减小，因此增大线程数能使线程间的速率互补，保证吞吐量稳定。建议使用40以上的线程数。MTUFTP包的MTU是采用的终端笔记本和服务器MTU的最小值，一般电脑默认MTU是1500，但基站NP芯片对于分片报文的处理存在瓶颈，建议修改MTU为1400。最新版本会自动修改MTU为1400.。附MTU查询办法：在服务器或终端侧笔记本wireshark抓包，如果TCP报文的len=1460，则代表MTU是1500。时延时延在TCP协议中有重大意义。因为TCP数据包需要反馈，时延越长，线程的发包 量增长速度越慢。一旦发生丢包，该线程速率恢

7、复以及其它线程速率互补也越慢。通常 来说缩短时延能提升和稳定速率。空载PING小包时延在30ms以内为宜。基站一些参数配置会影响时延，可以先为下行FTP用户打上行BO，此时的上行时延为最小值，若有速率明显提升或变稳，则可通过LMT修改以下参数来尽可能缩短上行时延：测试开关-MAC测试开关-上行最小分配PRB数：20小区-信道及过程-调度请求参数-DSR上报周期：5小区-信道及过程-BSR参数-BSR上报周期：5如果调整基站参数后ping时延仍然很大，需排查核心网和服务器（传输的时延一 般较小）。服务器首先需确认服务器是千M网卡。其次需确认当前服务器是否有很多用户同时下载，服务器负荷较重可能影响

8、速率，如果条件允许建议尝试使用空闲服务器进行测试，或同时使用两个FTP软件从两个服务器同时下载。如果服务器长时间未重启，建议重启服务器（之前出过重启服务器后ping时延缩短10ms的情况）。核心网如果上下行BLER很小，但从终端侧、S1的核心网出口或基站入口wireshark抓包 发现很多out-of-order或retransmission包时，可以怀疑核心网问题。核心网配置错误也会影响TCP速率，参看近期定位的一个问题“【问题描述】研究院要求多用户FTP业务下载，要进行400UE 的TCP业务压力测试 从目前看FTP业务速率仅能达到40M左右。【问题定位】当前配置，S1U接口和SS58接口

9、都会对外呈现，并且网段是一样的都是192.168.172.x这样又变成了一个负荷分担模式，数据也有可能从ss58绕出去，形成环路，从而影响TCP业务速率”如果连接同一核心网的其他多个站点均能正常峰速，则可初步排除核心网问题。终端笔记本性能终端笔记本性能对FTP速率也有较大影响，曾多次出现UDP灌包能到峰速但FTP到不了的情况，然后什么都不变更换终端笔记本后FTP速率提升20M的情况。请尽量使用性能好的笔记本。如果条件允许，出现速率低问题后建议更换终端笔记本看速率是否改善。定位手段1.抄送ATPlog. O_MACDL_CCH_DATA_INFO、O_MACDL_PDSCH_PARA_DATA_

10、INFOO_MACDE_PUCCH_INFO、O_CCMAC_PUSCH_DATA_CRC_IND、O_MACDE_PUSCH_INFO、O_CCMAC_PUCCH_ACK_IND、O_CCMAC_PUSCH_ACK_IND2.配置L2的远程日志类型为Ping日志，提取67号日志。1.1.1.2UDP业务速率低1.1.1.2.1下行BLER高导致速率业务低。现象一：FTP业务速率低，通过ATP或终端查看下行BLER比较高，特别是还存在残留BLER。1)此现象多是空口质量问题导致的，可以通过尝试关闭AMC，并将MCS固定为16(16QAM)、9（QPSK）等频谱效率比较低的值，看能否降低下行BL

11、ER；2)如果通过降低MCS的方法可以消除BLER，那么可以通过修改LMT-小区小区算法-调度-MAC下行算法参数-设置下行初始BLER。其默认值是10（较新版本是5）将其值降低。现象二：终端位置非常好（SNR2330、RSRP8095），曾经测试过程中无BLER且到达过峰值速率，周边环境未发生变化，但就是存在BLER。此时可能机房操作人员修改过参数，导致异常出现，因此需要核对如下参数。1)查看当前的MCS（通过ATP查看），查看MCS与BLER的变化趋势，看MCS降低是否可以使BLER降低。2)当前的反馈模式为Bundling还是Multiplexing（LMT-小区-信道过程配置-PUCC

12、H信道-ACK反馈模式）；在目前测试场景中，一般默认配置为Bundling；如果配置成了Multiplexing，一定要问询终端是否支持Multiplexing，如果不支持肯定会出现反馈异常。3)当前是否支持CQI与ACK同时上报（LMT-小区-信道过程配置-信道质量指示参数-与ACK同时上报指示）；大数情况NB配置为支持；当配置为不支持时，有些终端可能会出现处理上的异常，CQI修正修的不准，MCS较高，容易引起BLER。4)在LMT查看告警是否存在L2有关MACDE、ACK反馈异常或PL有关PUCCH、PUSCH相关字样的告警，由软件引起的异常告警会非常频繁。5)在LMT上查看是否存在RRU

13、通道故障告警6)抓取ATPlog，抄出一下消息O_MACDLCFG_CCH_DATA_INFO (6203)O_MACDLCFG_PDSCH_PARA_DATA_INFO (6204)O_MACDE_PUCCH_INFO(6205)O_MACDE_PUSCH_INFO(6206)（存在上行时需要）O_CCMAC_PUCCH_ACK_IND (6207)O_CCMAC_PUSCH_ACK_IND(6209)（存在上行时需要）注： a.如果上行业务满调度(看ATP上行调度次数画图)，这时看下行业务的反馈就只需要看O_CCMAC_PUSCH_ACK_IND（6209）；b.如果没有上行业务，此时反馈

14、只需抄消息O_CCMAC_PUCCH_ACK_IND（6207）；c.如果既有上行也有下行，像FTP这种类型的业务，就需要两个消息同时抄送了。LOG分析：1.1.1.2.2占用的PRB数目少导致速率业务低。1)需要看该UE的调度次数是否为满调度如果调度不满：很多情况下由于业务模型的限制导致下行RLC报给MAC的BO值波动范围较大，如果BO值较低(可以从ATP画图中下行BO图形来看)，那么自然不需要MAC分配较多的资源如果调度次数为满调度：此时看PRB个数，目前的商用终端在SFBC的情况是可以分配到100个PRB，如果不到100也正常，因为此时系统需要调度广播和TA，这些周期调度的元素会导致在A

15、TP上看来PRB不到100（大概会在98100之间浮动，需要看SIB内容的多少和TA的周期）；在两码字时，由于终端上报UE能力的限制，一个TTI内两个码字的数据和不能超过对应的限制，因此PRB不会到100（在UE能力为3时两个码字大概占用7080个PRB）2)检查关键参数LMT-小区-系统带宽：确定当前系统带宽（20M为100PRB；10M为50个PRB）看在当前带宽下是否已经分配满PRB了而误认为没有满LMT-小区-测试开关-MAC测试开关-下行PRB限制值（默认48，指资源分配时最高不能超过48个PRB） + LMT小区-测试开关-MAC测试开关-PRB限制开关是否同时打开（对于商用终端一

16、般不限制PRB，如果是NBT需要打开并限制为48个PRB）打开了PRB限制开关且下行PRB限制值本身就比较小，就会出现PRB一直很小的情况。LMT-小区-测试开关-MAC测试开关-下行ICIC开关 + LMT-小区-小区算法-小区干扰协调-ICIC算法开关是否同时打开查看是否打开了ICIC开关，由于算法上的限制，PRB也会导致无法分配满带宽（一般来说终端处于小区边缘时，如果当前配置为静态，那最多调33个PRB，这个是默认值，可以进行修改）LMT-小区-测试开关-MAC测试开关-下行流控开关如果打开了下行流控开关，PRB个数也不会调满（系统如果限制了AMBR或GBR且速率限制非常小，当打开流控后

17、MAC会用交少的资源进行资源分配以保证不会超过限制值）在最新的版本中还存在软件容量许可功能，也会控制UE的吞吐量，也可能会导致PRB较少。3)ATPlog如果排查了以上原因还没有解决，抄出以下ATPlog：O_MACDLCFG_CCH_DATA_INFO (6203)O_MACDLCFG_PDSCH_PARA_DATA_INFO (6204)分析LOG：O_MACDLCFG_CCH_DATA_INFO (6203)消息中的mac_pdcch_para.data.MAC_CchDci1a_10M.bMcs=0x00000004指示了当前MCS的大小O_MACDLCFG_PDSCH_PARA_DA

18、TA_INFO (6204)消息中的.dl_ue0.codeword_num=0x00000001字段可以看出此时是几个码字传输.dl_ue0.mac_dl_codeword_para0.tb_size=0x00000E28字段可以看出tbsize大小.dl_ue0.mac_dl_codeword_para0.modu_type字段可以看出调制方式.dl_ue0.mac_dl_codeword_para0.vrb_num=0x00000032 PRB分配的个数.dl_ue0.mac_dl_codeword_para0.vrb_index=. PRB的分布状况根据Log可以看出MAC下行分配的P

19、RB和具体VRB分配情况。4)在其他手段不方便或打算进一步分析问题时，也可以通过L2远程日志，V320版本的LMT上记录8：下行资源分配主流程和9：行资源分配异常两项，并在LMT-日志管理-设备日志-板卡日志对应的位置找到MAC的处理器（V310是BPOE1处理器，V320是DSP CORE5），提前67号日志。通过提取的日志可以查看如下打印：DLTFRCFINISH:CurHalf=0,CurSub04=0,AirHalf=0,AirSub04=3,CellId=0,UeId=0,ProcId=0,mimotype=0,elementType=9,PrbNum=48. RetxFlag0=0

20、,Mcs0=27,Rv0=0, RetxFlag1=0,Mcs1=0,Rv1=0ProcId=0 Harq进程号mimotype=0 当前的MIMO方式为SFBCelementType=9 当前的元素为新数据PrbNum=48 资源分配为48RetxFlag0 = 0 为新传Mcs0=27 当前码字MCS为27通过上面的打印来查看资源分配的情况。1.1.1.2.3调度不满导致的业务速率低：1)一般做FTP下载业务时可能由于BLER或服务器等原因造成调度不满，此时可以通过服务器下行灌UDP包的方式查看是否能满调度，如果灌UDP包能够满调度，说明不是软件问题。2)检查关键参数查看LMT-小区-上下

21、行子帧配置及LMT-小区-特殊子帧配置，根据子帧配置看是否已经满调度了当前系统的子帧配置和特殊子帧配置：DSUUD特殊子帧不限制满调度600次， DSUDD特殊子帧不限制满调度800次，如果特殊子帧限制例如配置成（3：9：2）那下行调度分别为400次和600次；LMT-小区-测试开关-MAC测试开关-下行流控开关是否打开了流控开关，若打开了流控开关调度不满是正常现象LMT-小区-测试开关-MAC测试开关-测量GAP处理开关 + LMT-小区-小区异频载波信息中查询是否存在异频邻区如果存在异频邻小区打开测量GAP的时候，也会出现调度不满，因为在终端异频测量时不会处理下行数据，这样会出现调度次数不

22、满对于FTP业务经常由于下载流程数少、上下行出现高残留BLER、MTU、服务器发包少等原因造成下行调度不满，此时要将下载进程增大，采取手段降低上下行BLER，核查MTU，通过抓包捕获服务器发包异常情况。3)ATPlog如果排查了以上原因还没有解决，抄出以下ATPlog：O_MACDLCFG_CCH_DATA_INFO (6203)O_MACDLCFG_PDSCH_PARA_DATA_INFO (6204)O_CCMAC_PUCCH_ACK_IND (6207)O_CCMAC_PUSCH_ACK_IND(6209)1.1.1.2.4上行BLER高导致业务速率低现象一：上行BLER过大如100%、

23、过小如10%以下，BLER不是稳定值1)调衰减2)可能是因为PL在检测小PRB的时候，比如4，5这么小的PRB的时候它的性能不太好，可以从L2 MAC测试开关上将上行最小调度PRB个数设置成12这种稍微大点的值，如果仍然没有改善，寻找PL的同事来协助定位现象二：上行BLER值比较固定，比如20%、15%1)调衰减2)如果调衰减也不管用很有可能是调度出了问题，抄送6203（O_MACDLCFG_CCH_DATA_INFO），6212(O_CCMAC_PUSCH_DATA_IND)消息;抄送方法如下：1.登陆ATP，打开消息跟踪-测试消息设置2L2接口消息抄送-L2测试消息输出控制，将右侧O_CC

24、MAC_PUSCH_DATA_IND 、O_MACDLCFG_CCH_DATA_INFO 消息前画“”，然后点击确定。分析LOG，查看LOG中6212(O_CCMAC_PUSCH_DATA_IND)消息中CRC译错的子帧是不是有规律的。消息结构如下：crci = 0表示正确，crci = 1表示译错。CRC译错的子帧是不是有规律指的是不是都在一个子帧译错、或者隔几个子帧就译错等。如果是有规律的，计算出周期是多少，看是否与CQI，SR，SRS，测量GAP的任何一种周期一样。如果是测量GAP导致的BLER，这样应该是L2的MAC测试开关的测量上报开关给关了，但是高层又配置了测量GAP，这个时候把L

25、2这个开关打开就行，并且还要和测试人员问清楚他是不是想配测量GAP；如果CRC出错和CQI，SR，SRS的周期一致了，这个很有可能是MAC调度的问题，找MAC内部人员分析一下LOG，走查一下代码。如果用户比较多，抄送LOG或者日志（打开5：上行TB内容异常开关），观测是固定某几个用户出错，还是全面出错，然后再具体分析一下，不过也是要带上PL的同事一起分析2.上行PRB个数少定位步骤检查LMT上MAC测试开关中“上行PRB限制值”是不是过小，一般这个值设置的是48。如果过小的话首先要询问测试人员将其调小的意图，如果没有特别需求的话，将这个值放大。甚至如果终端不是NBT的话，这个值调整成不限制。如

26、果不是上述原因，用ATP抄出6203（O_MACDLCFG_CCH_DATA_INFO），6212(O_CCMAC_PUSCH_DATA_IND)消息，看终端上报的BSR是否正常，过小的话说明终端向上传输的数据本身就不是很多，上行PRB也不会调度很大。可以试着打个上行BO看值又没有改变。看终端上报的BSR是否正常方法如下：看终端上报的BSR是否正常方法如下：下图为ATP抄出的6212(O_CCMAC_PUSCH_DATA_IND)消息，红色标出的MAC_LCID_SHORT_BSR = 0xff，其中低六位是终端上报的BSR，最大是63。BSR越大说明终端数据越饱满，如果BSR较小，则说明终端

27、数据本身就不是很多，所以上行PRB也不会调度很大。确定终端的用户能力等级，小于3的能力等级，是没有能力调度过高的PRB的，用户能力过小的原因有可能是真的小，也有可能是高层配置问题，这个需要和测试人员沟通一下终端是什么,一般来说终端都是不会太低的用户等级，然后就是打开日志，从日志中能看到上行的用户能力如果以上问题都排除，则抄送MAC的67号日志(打开3：上行资源分配异常抄送开关)，发给MAC同事进一步分析如果用户比较多，抄送LOG或者日志（打开3：上行资源分配异常抄送开关），观测是哪个用户的PRB少了。方法如下：ATP抄出6206(O_MACDE_PUSCH_INFO)消息，通过分析消息中每个用

28、户的first_prb_index与prb_num分析到底是哪个用户PRB少了，如果每个子帧都占满了带宽的PRB，只是对于某个用户在某个子帧调度PRB少了，正常现象；如果单子帧总的PRB个数都没占满的话，观测是不是调度了Sr触发的调度，这种调度的特点是周期的出现调不满PRB，这样就需要分析SR触发的原因，周期的大小大概是100多MS以上，如果SR过多，找PL的同学；如果周期是几十MS，可能是虚检问题，这个时候抄送6203，6212消息，观测SR触发的调度上行数据内容是否饱满(方法参考本节步骤二)，饱满的话证明不是虚检，不饱满的话需要找PL的同事来确认虚检问题。如果不是虚检问题，调整一下单子帧上

29、行调度的PRB上限3.上行调度不满定位步骤首先打开ATP画图中“上行调度次数”画图，查看调度次数到底是多少，离调满差多少。满调度计算方法(如DSUDD)：5ms调一次-1秒200次用ATP抄出6203（O_MACDLCFG_CCH_DATA_INFO），6212(O_CCMAC_PUSCH_DATA_IND)消息，观测终端上报的BSR值是不是正常(方法参照1.2节所讲)或是观测MAC数据内容里面PADING是不是比较多(即看LOG里6212消息中u8data字段是不是有很多的0)，如果BSR过小或是PADING过多那么调度是会不满，让测试人员灌大包，或者我们打个上行BO如果调度次数只是少了一些

30、，可以调整一下CCE大小，调整成4，或者加大CFI调度次数是否稳定（比如DSUUD格式下为400），可能是配置了GAP，需要检查该小区是否配置了异频临小区。检查是否配置了DRX，可以直接关闭LMT-小区-信道及过程配置-DRX参数中的DRX配置有效性开关来确认当前调度不满是否与DRX相关。确认AMBR参数，目的是为了确认调度不饱满是受流控影响，可先通过LMT的MAC测试开关关闭流控功能确认。4.上行MCS过低定位步骤在ATP上打开上行MCS画图，查看MCS到底是多少（最大值23）。如果MCS低了，确定是否有BLER，BLER越高，MCS越低。如果BLER高了，参照1.1节首先解决BLER问题。

31、若没有BLER，看是否是SR调度的比较多，若是，则关闭MAC测试开关中SRB的MCS限制开关。看SR调度比较多的方法：用ATP抄出6206(O_MACDE_PUSCH_INFO)消息，查看消息中MCS等级，如果MCS等级为6通常都是SR调度比较多。消息如下所示：若没有BLER，MCS只比预期的最大值少1，确认sounding是否配在上行子帧（LMT-信道及过程配置-探测参考信号参数-SRS时域发送位置-仅up位置发送） 如果用户比较多，抄送LOG或者日志（打开3：上行资源分配异常抄送开关），观测是哪个子帧或者哪个用户上行MCS少了，具体分析。对于UDP业务而言，除了可以提取Ping日志外，还可以提取18:tfrcexception|调度及资源分配过程中的异常/。在外场维护的过程中，遇到无法解决的问题，在时间允许的情况下，尽量帮忙将下表信息填完整，发回给研发分析。信息类别信息名称填写内容测试场景相关基站站型 （宏站 或 室分）版本信息测试场景及用户数量终端型号下行的RSRP（终端测查看