传输带宽受限导致下载速率低问题定位与解决

名称：传输带宽受限导致下载速率低问题定位与解决提交人：施建勋提交日期：2014-11-17软件版本：EMB5116_V5硬件版本：EMB5116_V5********************************************************************************************************************问题描述：葫芦岛客户反映综合楼附属楼室内LTE下载速率低，综合楼附属楼为葫芦岛新区综合楼附属楼-DLW-1小区覆盖，经现场测试，在好点（RSRP在-70dBm左右，SINR在30左右），单一用户，下载速率在2Mbps至20几Mbps之间，下载速率不稳定,PRB调度比较低，最高只有300左右，CQI为15，MCS正常，下行BLER正常，基站侧无告警。葫芦岛新区综合楼附属楼下载速率低速率达不到峰值问题影响用户体验，需要能够迅速定位解决。常涉及到的网元包括ENB、EPC、传输设备，另外还有空口质量、SIM卡设置、笔记本性能、服务器性能等影响因素，该节通过几个简易手段的介绍，使问题能够快速的定位到某个网元或者某一因素。问题分析：定位思路：测试机、服务器、终端问题测试机、服务器、终端问题排查：同一终端、测试机、服务器在其它基站下速率正常。使用相同测试终端，同一FTP服务器，在综合楼主楼-DLW-1小区测试，下载速率正常，下载速率在50Mbps左右；在卡特宏站测试，下载速率正常，下载速率保持在50Mbps左右。基站参数问题：参数一键恢复操作，保证参数无误。已执行，可排除基站参数问题。打下行MAC层BO、下发PDCP真实数据排除基站以及空口问题通过打下行MAC层BO来发现下行MAC层吞吐量为50M，下行PRB100左右，下行调度800，空口环境RSRP=-70左右SINR=30CQI=15MCS等级27左右下行PDCP真实数据发现小区PDCP吞吐量为50M，空口环境同上通过以上操作排除PDCP以下都没有丢包，丢包出现在PDCP以上有可能是传输侧也有可能是传输以上侧丢包。S1口抓包下图中序号77的数据包为从服务器30发往终端52的下行GTPU包，长度为1450字节。服务器侧IP为30，终端侧IP为52。该抓包针对GTP类型包进行了过滤，并选择了streamindex=2的数据包。其中序号（No）为和615和616两行是基站侧连续收到的这个stream线程的两个GTP包，2个GTP包，此时终端发起了TCPDupACK，要求重传包序号为44972的GTP包，参见620行，此后服务器重发了44972GTP包，参见625和626行。在此之后未再次见到序号为44972的GTP包，说明数据包确实是丢在基站外侧，而非空口环节。问题处理：通过和烽火传输侧沟通，对综合楼附属楼的室分站点分配了保障带宽和峰值带宽各100M，在现场进行单一用户复测，下载速率正常，峰值速率在52Mbps左右。问题的产生主要是由于传输侧带宽受限，目前葫芦岛LTE传输总带宽为1000M，大唐室分站点和卡特宏站共享，各个站点都没有配置保障带宽和峰值带宽。通过对其他LTE站点测试进行下载速率比对，单一用户测试环境下综合楼主楼室分站点和卡特宏站均可以达到峰值，不存在传输带宽受限问题。对问题站点在单一用户环境下多次测试，下载速率表现一致，下载速率最高只能达到20M左右，最低只有几百KB，下载速率极不稳定。需要协调烽火传输侧对综合楼附属楼站点的620A传输设备进行问题定位，通过传输侧手段从根本上解决传输受限问题。处理效果与拓展：1、在传输侧为葫芦岛新区综合楼附属楼-DLW-1小区配置保障带宽。解决下载速率低问题。下载速率恢复正