欢迎来到天天文库
浏览记录
ID:60901777
大小:2.22 MB
页数:8页
时间:2020-12-30
《调度不满导致下载速率低问题.doc》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、调度不满导致下载速率低问题一、问题描述近期,在网格优化过程中,LTE网格组发现多个站点在无线环境良好的情况下,在极好点处下载速率无法达到峰值的情况,如下为潘湖新村-1小区测试速率,速率始终只能在50M-60M上下。按照现网时隙配置正常情况下应该在80M以上。共发现该问题的有:潘湖新村、霞州新村、江夏丽景、鸿达汽车、蔡庄街、赤土村等6个站点。二、问题分析针对该问题进行了长达2周的反复抓包、测试定位,分析发现引发该问题的原因有多种情况,下面是详细分析。1.无线侧初步分析Ø排除终端和笔记本、FTP服务器问题:对这几个站点,进行更换终端、笔记本等方法进行测试,现象一样,且同样的笔记本、终端
2、在其他站点上速率正常,可达到峰值。排除这方面的问题Ø第8页共8页排除无线环境因素:测试时对测试位置进行多次选点,在RSRP/SINR等都远大于极好点的位置进行测试,MCS等级可基本维持在27以上,但是速率表现一样。同样的位置进行UDP灌包,速率可达到峰值。如下图,至此可基本排除无线环境问题。Ø测试组对问题站点的小区PRB数限制为48/24,测试速率基本稳定在对应的峰值速率上。也说明问题不在空口上,怀疑进入基站的数据不足。Ø在基站的S1口做镜像抓包,同时在FTP服务器上也做WIRESHARK抓包,发现S1口的下行数据存在乱序和丢包的现象,丢包率大约为千分之一,这个有可能导致速率的下降
3、。第8页共8页潘湖新村蔡庄街1.传输链路不稳及丢包问题根据以上分析,首先怀疑传输侧问题,将存在问题站点提交传输分析,传输侧反馈霞州新村搬迁、江夏丽景链路不稳,并进行处理;鸿达汽车传输侧存在明显丢包,并对异常进行处理;根据传输侧反馈,项目安排复测:江夏丽景和鸿达汽车问题解决,霞州新村搬迁1、2小区速率恢复正常,3小区下载速率依然较低;由于同站所有小区共用传输,因此该站3小区问题非传输导致;站点中兴答复霞州新村链路不稳,已处理江夏丽景链路不稳,已处理鸿达汽车存在明显丢包,已处理2.参数设置问题传输整改后霞州新村仅3小区仍存在问题,因此小区参数设置嫌疑较大,将3小区参数与1、2小区进行对
4、比,发现上行BO参数设置不合理,参照1、2小区进行设置后,3小区下载速率恢复正常,并对其他未解决站点参数也进行核查,发现潘湖新村存在同样问题,修改后也恢复正常。3.传输侧带宽设置不合理由于传输侧反馈无其他明显异常,定位至此,有点山穷水尽了。回过头再次梳理之前的定位过程,从中找些蛛丝马迹。根据1.抓包分析,从基站、终端侧抓包看,S1下行存在1/1000的丢包,因此再次安排上站抓包,站点:蔡庄街第8页共8页。方法是在基站和PTN设备之间接入第3方交换机,在连接第三方交换机时发现,端口速率始终无法达到千兆,而第3方交换机直接和基站传输口相连,则可以达到千兆,怀疑传输侧配置为100M光口而
5、非1000M,将该问题反馈传输核查,经传输改配后,重新连接PTN和基站,复测速率正常。这种情况有一个特点:在物理设备-机架-机框-板卡-以太网节点下,目前正在使用的端口,配置工作模式为自适应,实际工作模式为100M。传输侧反馈如下,经处理站点均恢复正常:站点中兴答复蔡庄街传输侧配置为强制100M以下是该种情况下,OMC上核查的节点:1.上行BLER导致速率持续偏低针对赤土村速率持续偏低的问题,上站抓包:该站没有明显丢包,但是从基站可以看到空口有心电图状的BLER毛刺,峰值约10%,从拉网速率趋势看,曾有一小段时间空口无BLER,对应的速率可以稳定在80M左右,因此可以看出,下载速率
6、高低,与测试点空口BLER有直接关系,空口BLER会导致下载速率持续偏低。经过外场测试人员寻找,在赤土村可以找到空口环境较好的测试点,这些测试点空口无明显BLER,测试速率可在90M,这一现象也能说明,下载速率与BLER的关系。2.上行反馈晚点到达服务器和终端丢包通过在赤土村寻找无线环境好的测试点,测试速率可在80M以上,但也有偶尔掉坑现象,针对此种情况进行抓包和CDL业务日志分析,发现掉坑的时候有突发重传,重传的原因有2种:第8页共8页Ø上行ACK到达服务器时间点晚导致服务器重传终端侧抓包分析:从下图可以看出收到了SN为904789478的原始包紧接着对行报文进行确认ACK(ip
7、id:30556),如图:接下来如下图,收到SN为904789478的重传包服务器侧:如下图对SN:904789478包首次进行发送接着对SN:904789478包进行重传,此时按照TCP协议,超时重传会导致速率陡降。第8页共8页然而,在服务器对SN:904789478重传后的939936行收到了终端对原始包的确认,说明原始包的ACK(ipid:30556)并没有丢,只是到服务器时晚了上行ACK晚点到达服务器的原因应该与下述发现的传输时延突发异常变大有关。在做业务过程
此文档下载收益归作者所有