TD-LTE调度不饱满导致下载速率低问题

问题描述：

近期，在网格大会战过程中， LTE网格组发现多个站点在无线环境良好的情况下，下载速率无法达到峰值的情况，如下为金陵城二-1小区测试速率，速率始终只能在50M-60M上下。而该站点的配置在正常情况下应该在80M以上。

共发现该问题的有：郭家山二搬迁、新生圩港、金陵村二、伊刘村、浦口二、柳塘村、浦江学院、燕江路、宝塔街T、大桥村、浦口审计学院试扩、林家凹试扩等12个站点。

问题分析：

针对该问题进行了长达1个月的反复抓包、测试定位，分析发现引发该问题的原因有多种情况，下面是详细分析。 1.无线侧初步分析

排除终端和笔记本、FTP服务器问题：对这几个站点，进行更换终端、笔记本等方法进行测试，现象一样，且同样的笔记本、终端在其他站点上速率正常，可达到峰值。排除这方面的问题

排除无线环境因素:测试时对测试位置进行多次选点，在RSRP/SINR等都远大于极好点的位置进行测试，MCS等级可基本维持在27以上，但是速率表现一样。同样的位置进行UDP灌包，速率可达到峰值。如下图，至此可基本排除无线环境问题。



测试组对问题站点的小区PRB数限制为48/24，测试速率基本稳定在对应的峰值速率上。也说明问题不在空口上，怀疑进入基站的数据不足。



在基站的S1口做镜像抓包，同时在FTP服务器上也做WIRESHARK抓包，发现S1口的下行数据存在乱序和丢包的现象，丢包率大约为千分之一，这个有可能导致速率的下降。

金陵村二 伊刘村

2.传输链路不稳及丢包问题

根据以上分析，首先怀疑传输侧问题，将存在问题站点提交传输分析，传输侧反馈郭家山二搬迁、新生圩港链路不稳，并进行处理；燕江路传输侧存在明显丢包，并对异常进行处理；根据传输侧反馈，项目安排复测：新生圩港和燕江路问题解决，郭家山二搬迁1、2小区速率恢复正常，3小区下载速率依然较低；由于同站所有小区共用传输，因此该站3小区问题非传输导致；

站点 郭家山二 新生圩港 燕江路

中兴答复

链路不稳，已处理 链路不稳，已处理 存在明显丢包,已处理

当前版本

3.20.00.40.15.01 3.20.00.40.15.01 3.20.00.40.15.01

3.参数设置问题

传输整改后郭家山二仅3小区仍存在问题，因此小区参数设置嫌疑较大，将3小区参数与1、2小区进行对比，发现上行BO参数设置不合理，参照1、2小区进行设置后，3小区下载速率恢复正常，并对其他未解决站点参数也进行核查，发现金陵村二存在同样问题，修改后也恢复正常。

4.传输侧带宽设置不合理

由于传输侧反馈无其他明显异常，定位至此，有点山穷水尽了。回过头再次梳理之前的定位过程，从中找些蛛丝马迹。根据1.抓包分析，从基站、终端侧抓包看，S1下行存在1/1000的丢包，因此再次安排上站抓包，站点：伊刘村。方法是在基站和PTN设备之间接入第3方交换机，在连接第三方交换机时发现，端口速率始终无法达到千兆，而第3方交换机直接和基站传输口相连，则可以达到千兆，怀疑传输侧配置为100M光口而非1000M，将该问题反馈传输核查，经传输改配后，重新连接PTN和基站，复测速率正常。这种情况有一个特点：在物理设备-机架-机框-板卡-以太网节点下，目前正在使用的端口，配置工作模式为自适应，实际工作模式为100M。对全网进行核查发现还有浦江学院、浦口审计学院试扩、林家凹试扩等站点存在同样问题。传输侧反馈如下，经处理几个站点均恢复正常： 站点 伊刘村 浦江学院 浦口审计学院试扩 林家凹试扩 中兴答复 传输侧配置为强制100M 传输侧配置为强制100M 传输侧配置为强制100M 基站上PTN设备安装为155M光模块 以下是该种情况下，OMC上核查的节点：

5.上行BLER导致速率持续偏低

针对柳塘村速率持续偏低的问题，上站抓包：该站没有明显丢包，但是从基站可以看到空口有心电图状的BLER毛刺，峰值约10%，从拉网速率趋势看，曾有一小段时间空口无BLER，对应的速率可以稳定在80M左右，因此可以看出，下载速率高低，与测试点空口BLER有直接关系，空口BLER会导致下载速率持续偏低。 经过外场测试人员寻找，在柳塘村可以找到空口环境较好的测试点，这些测试点空口无明显BLER，测试速率可在90M，这一现象也能说明，下载速率与BLER的关系。

6.上行反馈晚点到达服务器和终端丢包

通过在柳塘村寻找无线环境好的测试点，测试速率可在90M以上，但也有偶尔掉坑现象，针对此种情况进行抓包和CDL业务日志分析，发现掉坑的时候有突发重传，重传的原因有2中：



上行ACK到达服务器时间点晚导致服务器重传 终端侧抓包分析：

在500746行收到了SN为904789478的原始包

紧接着在500748行对500746行和500747行报文进行确认ACK（ipid : 30556），如图：

在501077行，收到SN为904789478的重传包

服务器侧：

在939644行对SN：904789478包首次进行发送

在939931对SN：904789478包进行重传，此时按照TCP协议，超时重传会导致速率陡降。

然而，在服务器对SN：

904789478重传后的939936行收到了终端对原始包的确认，说明原始包的ACK（ipid: 30556）并没有丢，只是到服务器时晚了

上行ACK晚点到达服务器的原因应该与下述发现的传输时延突发异常变大有关。 在做业务过程中，基站对EPC进行长PING操作，会偶尔出现超大时延现象，如图：

终端接收丢包

在126424行，抓包看终端已收到SN为3564609387的原始包，然而终端后续却一再确认SN为3564609387的包丢失（红色部分）

直到在126917行收到服务器的对SN为3564609387报文的快速重传才恢复正常

总结上述抓包分析：

1） 上行TCP ACK晚点到达服务器导致重传；

2） 业务过程中PING EPC存在超大时延是导致ACK晚点的最重要原因； 3） 重传为瞬时突发，绝大部分时间无重传，且重传发生时伴随速率下降；

4） 怀疑终端或笔记本性能问题会导致在业务长时间保持中收到数据处理不过来而丢掉； 上述四点解释了测试过程中出现的现象：业务较长时间能够保持锋速，偶尔出现掉坑，长时间持续业务时速率波动幅度会变大。

7.终端反馈0窗口报文导致速率低

针对宝塔街站上站测试抓包，经过分析，该站点BLER相对较高，但导致业务速率低的更重要原因为终端会反馈0窗长报文，一旦出现该问题，当前下载线程则处于停滞状态直至终端上报窗长恢复，每次发生停滞时间120ms---900ms不等，停滞时间内速率为0。 5线程下载测试，57秒的抓包中，发生约20次0窗口事件，而且，0窗长发生时往往伴随着丢包，如此，必然会导致速率低，如图，在65419行发生0窗口事件，直到65466行恢复，停滞时长

约800ms。

解决措施及结果：

综上多种情况分析：调度不满导致速率低问题，经过传输整改链路、改配端口模式均能有效解决该问题。

问题结论;引起调度不满导致速率低问题有以下几种因素：

1.传输问题



传输明显丢包； 

传输端口模式配置错误；



传输链路不稳；

2.参数设置问题：上行BO设置不合理；

3.测试点空口环境查，BLER高导致速率持续偏低；

4.传输大时延使上行ACK晚点到达服务器，引发重传，最终导致下载速率低； 5.终端问题 

终端性能问题导致业务长时间保持中收到数据处理不过来而丢弃，引发重传； 

终端反馈0窗口报文，导致速率偏低。