PTN承载LTE基站FTP测速低问题分析
5G站点开通后测试下载速率低问题处理案例
5G站点开通后下载速率低问题处理案例案例上报省份：湖南省案例上报人：徐晓东一、关键词：下载、速率低二、案例分类问题分类：用户感知、网络性能类手段分类：参数调整、网络抓包等三、优化背景黄兴广场5G站点下载速率低，需要优化提升。
四、问题现象黄兴广场5G基站开通后，检查小区状态正常，基站无任何故障告警，但现场测试下载速率只有几十兆，最高时只有100Mbps 左右，而且下载速率不稳定，波动较大，达不到5G单验下载速率要求。
五、原因分析1、检查基站开站脚本，未发现基站脚本配置存在异常，刷基站下载峰值参数，测试下载速率仍然只有几十兆。
2、为排除基站脚本问题，对照其它区域开通基站脚本重新制作开站脚本，将基站数据清空后重新刷基站脚本，现场测试下载速率仍然只有几十兆。
3、为定位问题原因，对基站进行抓包分析，通过抓包分析发现基站上游丢包严重，服务器总共有10个线程，每个线程都存在丢包。
单独拿一个线程看，基站以上丢包475个，基站以下丢包4个，因此判断是基站以上问题，需要排查基站以上传输设备及线路。
4、该局点使用的是中兴厂家PTN设备，对比该局点和其它区域中兴厂家传输组网情况，其它区域传输组网：BBU->PTN6500->桥节点->L3->省干，该局点组网：BBU->PTN9008->桥节点->L3->省干。
因此，建议将该局点的PTN9008更换为PTN6500，避免由于传输设备差异造成下载速率异常问题。
六、解决方案更换PTN传输设备为PTN6500后，现场测试下载速率最高时达450Mbps左右，稳定在430Mbps左右，下载速率正常。
七、效果评估将中兴厂家PTN9008设备更换为PTN6500设备后，现场测试下载速率正常。
对于下载速率低问题，可以通过对基站进行抓包分析定位是基站以上传输丢包还是基站以下丢包，判断是基站问题还是传输问题，在问题定界后再进一步分析处理。
核心网 - 由于HSS侧开户参数设置问题导致FTP下载速率低问题处理
核心网-由于HSS侧开户参数设置问题导致FTP下载速率低问题处理1 现象描述某局LTE实验网开局，测试过程中PC连接E5终端进行FTP下载业务测试，发现下载速度峰值只有5Mb左右，远未达到LTE正常水平。
2 告警信息无3 原因分析FTP下载速度慢的可能原因包括信号干扰、CQI配置、传输链路等，主要有以下几种：1、基站CQI配置不正确。
2、空口质量比较差。
3、传输侧丢包或带宽不足。
4、终端或FTP软件问题。
5、HSS侧用户开户限制。
4 处理过程1、基站CQI配置核查：通过MML命令LST RLCPDCPARAGROUP查询PDCP层丢弃定时器配置时长、RLC模式等信息，查询配置都在合理范围之内，由于站点为新建站点，数据较简单，重新删建小区，下载速度仍然维持原状，故排除基站数据配置问题。
2、查看基站告警，无驻波或通道类告警，现场测试RSRP稳定在-60左右，RSRQ、RSSI也都没有大的波动，故排除空口质量问题。
3、基站到核心网的传输采用层三交换机加PTN组网方式，从交换机侧接口到基站PING包无延时，由于只有一个演示站，接口带宽利用率不足10%，故排除传输丢包或带宽不足问题。
4、现场有多台终端，换用不同的终端和FTP软件测试现象均一样，排除终端或FTP软件问题。
5、由于FTP下载速度上限稳定在5Mb左右，怀疑HSS侧开户参数设置存在问题，联系HSS侧同事检查设置，发现虽然HSS侧用户开户设置的上下行带宽为150Mb，但开户信息中和速率相关的参数MAPSERV设置为普通的GPRS业务管理，而4G用户应设置为SuppGprsManageOptimization，HSS侧修改此参数后下行速度恢复到60Mb，问题解决。
5 学习心得1、对于下载速率问题的定位可以采取分段定位的方法进行定位，分别排除各个节点及接口问题，如对空口质量、eNodeB配置、传输侧分别进行定位排除。
2、常用的定位手段包括PING命令、端口负荷检查、终端信号质量测试、基站配置核查、开户信息核查等。
LTE低速率小区分析及优化提升探讨
LTE低速率小区分析及优化提升探讨LTE（Long Term Evolution）是第四代移动通信技术，它为用户提供了高速、高质量的移动宽带服务。
然而，在实际应用中，LTE网络中存在一些低速率小区的问题，这会导致用户的上网体验不佳。
因此，分析和优化LTE低速率小区成为了移动通信网络优化的重要课题之一一、LTE低速率小区的原因分析1.频率干扰：频率干扰是导致LTE低速率小区的主要原因之一、当LTE基站所使用的频段与周围其他无线电设备的频段相近或重叠时，会发生频率干扰，导致信号质量下降，从而影响网络速率。
2.硬件故障：LTE基站的硬件故障也是导致低速率小区的因素之一、例如，天线故障、传输线路故障等都可能导致信号的传输受阻，从而影响网络速率。
3.覆盖不均匀：LTE网络覆盖不均匀也会导致低速率小区的发生。
当一些区域的基站密度较低，或者信号传输受到建筑物、地形、树木等物理障碍的阻碍时，会导致覆盖不均匀的情况出现。
1.频率规划优化：通过合理规划LTE网络的频率资源，避免与其他无线设备频段发生冲突，减少频率干扰。
可以使用频率规划软件进行频率资源分配和效果预测，以优化频率规划。
2.硬件设备维护：定期对LTE基站的硬件设备进行检修和维护，及时修复损坏的天线、传输线路等硬件设备，以确保正常的信号传输，提高网络速率。
3.注重覆盖优化：加强对覆盖不均匀区域的优化工作。
可以通过增加基站密度、调整天线方向，或者使用增强型站点覆盖技术（如室内小区覆盖、扩展跟踪区小区）等方式，提高覆盖率和覆盖质量。
4.邻小区优化：通过优化LTE网络的邻小区配置，减少邻小区干扰，提高用户的网络速率。
可以通过邻区删除、邻区级别调整等手段进行优化。
5.排查故障排除：当出现LTE低速率小区问题时，需要及时进行故障排查，确定问题的具体原因，并采取相应的措施进行修复。
可以使用LTE网络维护工具进行故障诊断和定位。
总结：LTE低速率小区的分析和优化是一个复杂而细致的工作，需要运营商、设备厂商和专业的网络优化人员共同努力。
PTN输入光功率过低导致TDL站点下载速率受限故障
PTN输入光功率过低导致TDL站点下载速率受限故障一、故障描述解放路移动演示营业厅为LTE网络新建室内分布系统，采用RRU-3152-e（单模双流RRU）组网，站点在开通后经单站验证上下行速率业务均达标。
1月7日，收到4G网络体验用户的投诉，称其在该营业厅下载时下载速率并不如宣传的给力。
经现场测试：该室分站点RSRP为-77dbm，两通道基本平衡；SINR为36db，为极好点；传输模式为T3双流，MCS基本保持在27阶；上行速率正常，但下行速率只有11.5Mbps左右，如下图所示，且经后台网管核实无线侧无任何告警。
二、故障诊断查询站点设备状态显示一切正常，确认基站无任何告警；核实站点无线侧配置数据，没有任何异常，且无线侧SCTPLINK、IPPATH等传输链路正常。
1、初步推断为天馈系统出现问题影响了下载速率通过在RRU馈线口直连小天线进行测试，下载速率并未得到提升，故排除天馈系统问题；2、产品License技术支持受限通过查询该室分站点实际生效License配置信息（DSP LICENSE），再对比其它正常室分站点的License权限，未发现异常，故排除产品License技术支持受限问题；3、PTN侧传输问题对RRU双通道轮流进行关闭后测试单通道下下载速率，测试结果显示单通道下下载速率与双通道时基本一致，且对比S1口流经的流量与基站侧转发至空口的数据流量也基本一致，远低于正常值，故初步推断为PTN侧传输速率出现了问题。
通过无线侧ping核心网用户面IP地址发现存在4%的丢包现象，如下图所示，如下图所示。
三、解决措施1.通过网元名称查找相应的电路资料，确定开站的vlan，然后找到该vlan对应的业务；2.通过该业务ID找到PW，右键查找对应的tunnel，如下图所示：3.查看tunnel发现有“传输光功率过低告警”；进入该网元操作界面，发现1槽位73CXP 单板1端口输入光功率过低（显示-21.2dBm，参考值-14.1dBm），如下图所示，将其调整到-7.3dBm后问题恢复。
【LTE实战】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.013.参数设置问题传输整改后郭家山二仅3小区仍存在问题，因此小区参数设置嫌疑较大，将3小区参数与1、2小区进行对比，发现上行BO参数设置不合理，参照1、2小区进行设置后，3小区下载速率恢复正常，并对其他未解决站点参数也进行核查，发现金陵村二存在同样问题，修改后也恢复正常。
LTE室分单流速率不达标问题分析与总结
LTE室分单流速率不达标问题分析【故障类别】LTE网优【关键字】单流室分峰值速率不达标【现象描述】小区峰值速率徘徊在47Mbps左右，无法突破50Mbps的验收标准，之前试验网单流室分峰值速率能轻松突破55Mbps，需要进行问题定位。
【问题分析】所测室分站点，好点测试时，峰值速率虽然没有达到50Mbps的验收标准，但速率平稳，在47Mbps上下小幅浮动。
考虑到之前存在较多因核心网操作导致速率异常问题的经验，首先想到进行空口灌包测试，排查是否空口问题，如灌包速率仍然较低，可考虑通过核查无线侧相关参数配置，进一步进行定位分析。
【处理过程】1. 功率参数核查：因此次单验之前，唯一修改的参数是小区参考信号功率，由9.2修改至12.2，故第一想到是否与此有关。
进一步分析发现，功率仅对小区覆盖及小区容量有影响：导频功率越大，UE接收RSRP越大，小区覆盖半径越大；导频功率越大，在基站总功率不变的情况下，数据RE 功率将降低，会导致系统的容量下降，不会影响到峰值速率，这点从现场测试情况来看，也完全吻合。
对比参考功率分别为9.2与12.2情况，现场测试速率没有明显变化，排除功率问题。
2. 空口灌包测试：利用网管，通过配置基站业务IP与终端获取的目的IP，从基站侧对前台测试终端进行灌包，发现峰值速率仍然没有变化，在47Mbps左右，与业务下载测试吻合，故定位空口侧存在问题，开始逐步排查无线参数设置。
3. 参数对比核查：根据试验网单通道站点峰值速率能轻松突破55Mbps的情况，对比核查新开站点与试验网站点参数配置情况，发现：PDCCH算法参数中，PDCCH占用的OFDM初始符号数，因为基站版本升级，由之前默认的次数1，变化至目前默认的次数3，修改至试验网默认次数1后，速率提升至55Mbps以上，问题定位结束。
4. 进一步验证：通过对比测试不同的PDCCH符号数，配合打开及关闭动态调整开关，分别验证：（符号数3+动态调整开）、（符号数3+动态调整关）、（符号数1+动态调整开）、（符号数1+动态调整关）4种情形下，对应峰值速率值，发现：（符号数1+动态调整关），峰值速率最高，为55.27Mbps ，（符号数3+动态调整关）峰值速率最低，为46.96Mbps，反向证明前期问题室分站点单验峰值速率正常。
LTE优化案例手册-第四章-速率问题
LTE优化案例⼿册-第四章-速率问题第四章速率问题4.1 速率问题概述(陈佳)（注：本⽂所讨论的速率问题是建⽴在上下⾏时隙为DSUUD的基础上）在极好点（SINR在22dB以上）做FTP下⾏业务时，平均速率要求在47Mbps左右及以上，若发现速率较低，我们可进⾏以下⽅⾯的排查来定位问题：1、看⽆线环境是否稳定、包括SINR、RSRP、CQI等若UE IDLE的情况下，SINR值能在23以上，在UE 进⾏下载业务时，SINR会明显降低，则很可能是天馈接错或天馈系统存在问题，可进⾏天馈排查；2、PRB的调度是否能满现⽹的上下⾏时隙配⽐为2:2（3:2），则分配给下⾏的1s调度次数理论最⼤值为600，平时单站验证时应该看到的值会接近600，若出现该值较低或有的PRB没有进⾏调度，则需查看现⽹参数，看是否设置了PRB调度数量的限制等；3、查看下⾏双流是否存在、以及是否稳定在测试软件上可看到传输模式（TM），⽬前现⽹设置为TM3、7⾃适应，所以在双流时，传输模式为TM3，同时还要看CQI窗⼝中Rank2 Indicator Count 是否有值，有值才是真正的双流；如果出现TM模式3、7的不断更换，则下⾏速率肯定会受到影响，此时可看现⽹参数关于3、7门限是否设置合理；4、查看下⾏BLER值、如果误码率过⾼，会导致速率低5、查看DL MCS窗⼝，在极好点，下⾏编码⽅式绝⼤部分应在26及以上、主要调制⽅式为64QAM，若存在问题，则需检查现⽹相关参数；6、查看本⼩区上下⾏时隙配⽐以及相邻⼩区的时隙配置（DL：UL），现⽹配置为2:2（3:2），若本⼩区配置成2:2（3:2），相邻⼩区被配置成了3:1（4:1），导致服务⼩区的上⾏受到⼲扰，UE出现上⾏失步，会出现掉话，速率不⾼的现象；7、排查电脑问题，以及FTP服务器问题可进⾏电脑重启、更换FTP服务器地址、以及多开些进程等操作8、查看基站有⽆告警，若⽆，可怀疑是否存在基站或传输单元隐性故障，将基站或传输单元进⾏重启9、查看参数maxNrSymPdcch是否设置为3，若设置为3，则会⼤⼤影响下⾏速率，做单站10、进⾏基站全部参数的核准验证时可将此值设置为1经过以上排查，若还不能解决，则可让后台⼈员做本站参数和Golden 配置参数的对⽐，看是否存在异常；11、传输限速：找传输⼈员排查传输上的带宽是否设置错误，导致传输瓶颈的产⽣，从⽽影响空⼝的速率，标准设置为上下⾏双⼯，都为1Gbit/s12、查看SIM卡的签约信息是否有问题查看信令attach accept，其中可看到APN aggregate maximum bit rate ，其中有UE下⾏最⼤速率限制，看是否修改了SIM的签约信息；⼆、在极好点做FTP上传时，平均速率要求在19Mbps（RL 25）左右及以上，若发现速率较低，我们可进⾏以下⽅⾯的排查来定位问题：1、看⽆线环境是否稳定、包括SINR、RSRP等2、上⾏PRB的调度是否能满现⽹的上下⾏时隙配⽐为2:2（3:2），则分配给上⾏的1s调度次数理论最⼤值为400，平时单站验证时应该看到的值会接近400，若出现该值较低或有的RB没有进⾏调度，则需查看现⽹参数，看是否设置了PRB调度数量限制等；3、看测试软件上的PUSCH Power以及路损，极好点的路损不会很⾼，⼀般在90db左右，若此时的PUSCH Power为或者接近23，可查看现⽹功控参数是否设置有问题，若⽆问题，可怀疑是否存在天馈接错、或者天馈系统存在硬件问题，导致⽤户上⾏功率受限；4、查看上⾏BLER值如果UL误码率过⾼，会导致速率低5、查看UL MCS窗⼝在极好点，上⾏编码⽅式绝⼤部分应为24及以上、主要调制⽅式应为16QAM，若存在问题，则需检查现⽹相关参数，若为RL15的站。
FTP下载速率慢原因分析及处理指导书(华为)
目录1背景描述22TCP相关知识点22.1TCP传输的最大报文段22.2TCP发送报文确实认32.3滑动窗口与接收缓冲区32.4发送缓冲区32.5慢启动与拥塞防止算法33ADSL模板织与快速的区别43.1Channel mode－通道模式43.2Unit of interleaved delay－交织延迟单位54一例FTP下载慢情况的分析64.1缩短线路时延104.2增大滑动窗口和发送缓冲区的容量105网通现网测试的结果135.1ADSL/ADSL2+FTP下载速率测试〔突出改变时延带来的影响〕145.2ADSL下载速率测试〔突出改变缓冲区带来的影响〕155.3ADSL2+下载速率测试〔同样是突出改变缓冲区带来的影响〕16 6结论17FTP下载速率慢原因分析与处理指导书1背景描述在DSLAM的应用中，经常用到FTP下载来测试ADSL的带宽。
我们在测试时经常会发现FTP下载速率比ADSL的带宽小很多，本文就是从原理入手逐步分析问题的原因。
首先强调一点，FTP下载速率肯定不会大于通道的带宽，因为ADSL通道就好比运载货物的列车，我们只可能尽量的装满它，但绝不会超过它；甚至使用多个FTP同时下载，每个FTP下载速度的总和也不会大于通道的带宽〔测试标准中均建议使用多个FTP同时下载〕。
其次，FTP下载是一个端到端的处理过程。
下载速率涉与到端到端整个业务流程的每个环节，包括了硬件性能、线路带宽、线路时延，缓冲区算法等。
使用FTP下载是一种比拟方便〔或者说常规应用中也没有比它更好的〕的方式来判断带宽的方法，不过我们要尽可能排除一切瓶颈，使FTP下载速度接近通道的带宽。
2TCP相关知识点问题分析涉与到的TCP知识点介绍一下。
熟悉TCP的人可以跳过此节，太不熟悉TCP 的人请直接参考TCP/IP相关资料，此处不做过多的根本知识介绍。
2.1TCP传输的最大报文段TCP下载大文件时，需要把大文件切割为一系列报文段进展发送。
LTE速率低原因分析
1、4G LTE 网只能提供数据服务，不能承载语音通话，该怎么理解？这个问题要从移动核心网的角度来理解。
我们平时说的WCDMA、TD-SCDMA、TD-LTE 其实通常指空口技术，即从手机到基站的通信技术。
而移动通信的核心控制部分，则由核心网完成——如何在两个基站间建立起语音连接？何时给拨号方返回嘟嘟的线音？何时给接收方发出振铃？如何判断一个用户是否开通了呼叫转移业务，如何实现？如何建立从手机到因特网服务器的数据连接？如何判断用户是3G用户还是LTE用户？这些都是由移动核心网完成的。
下面来说移动核心网的种类。
在2G/3G时代，移动核心网是两个独立的域，控制语音相关的叫电路域（CS域：Circuit Switch），控制数据业务相关的叫分组域（PS域：Packet Switch）。
相应的，与语音相关的控制都放在了电路域，比如上面的语音呼叫建立、返回振铃、判断并执行呼叫转移，以及曾经的杀手锏业务短信等等。
与数据相关的控制则放在了分组域，比如上面的与因特网服务器（通信网与因特网是两张网）建立数据连接、区分你当前流量是微信还是微博等等。
因此，在2G/3G时代，语音和数据业务分别承载在两张不同的核心网上。
3G网络允许业务并发，也即同时使用两张网络，在打电话的同时可以数据下载。
（2G，严格的说是2.5G的GPRS，由于技术限制，通常发生呼叫的时候数据业务会挂起）随着数据业务的爆发以及网络的全IP化，LTE网络不再提供电路域，只保留唯一的一个分组域核心网（EPC：Evolved Packet Core）。
LTE的最终目标是所有业务，包括语音、数据，都承载在这张用来处理数据业务的核心网上。
也就说，只有在语音完全实现数据化（IP化）后，LTE网络才能够承载语音业务，而这个条件目前在中国并不具备。
可能有人会问，手机QQ既然能语音通话，为什么LTE网络不能直接也这么干？因为这种类似于软件中的语音通话功能只是应用级别的，运营商无法做到对通话过程完全可控（使用手机号MSISDN作为身份标识、区域计费、增值业务等），更重要的是，这种级别的语音业务无法保障其通话质量（想象一边QQ语音一边下迅雷吧）。
5G优化案例：5G终端接入与测速低问题浅析
NSA组网终端接入与测速低问题浅析XX无线维护中心XXXX年XX月目录NSA组网终端接入与测速低问题浅析 (3)一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (7)NSA组网终端接入与测速低问题浅析XX【摘要】目前5G 分为独立组网（SA）和非独立组网（NSA），其中非独立组网（NSA）控制面需锚定于4G，高速数据业务沿用4G核心网EPC通过LTE和5G NR传输，在该组网模式下，XX电信试点发现一些NSA终端无法接入和接入后速率低问题，在此进行问题总结和分析，为后续出现类似问题提供参考。
【关键字】NSA、速率低、接入异常【业务类别】5G优化一、问题描述XX电信在人民东路营业厅开通了一个NSA基站，对营业厅5G体验，在测试过程中，存在5G接入困难和测试过程中速率陡降的现象，如下：1）在电信营业厅5G正常覆盖区域使用5G终端，无法正常使用5G网络，依然占用4G 网络。
2）测试终端在5G测速体验中，出现速率由大于1Gbps后速率陡降低于30Mbps的异常情况。
二、分析过程在NSA组网（EN-DC双连接）下，手机首先注册4G网络，然后再上报测量的5G信号强度和质量等，比如当手机移动到5G小区的覆盖范围时，检测到5G信号强度和质量足以支持5G服务，则4G基站将与5G基站沟通以为手机分配5G资源。
4G基站通过RRC连接重配置（RRC Connection Reconfiguration）消息将5G NR分配的资源通知手机，完成RRC连接重新配置过程后，手机就同时连接到4G和5G网络了。
具体步骤如下：步骤1：主节点4G基站决定将5G基站添加为辅助节点，向5G基站发送SgNB添加请求（SgNB Addition Request）消息。
该消息携带RRC和无线承载配置、UE能力和安全信息等。
步骤2-3：5G基站响应请求，向4G基站发送SgNB添加请求确认（SgNB Addition Request Acknowlege）消息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
PTN承载LTE基站FTP测速低问题分析作者：边红霞
来源：《电子技术与软件工程》2016年第18期
摘要
FTP下载速率作为考核LTE基站无线达标率的KPI指标，FTP下载测试速率不达标分析原因为在FTP测试中存在流量的突发情况，瞬间超过了PTN承载网配置的PIR峰值带宽。
针对上述问题本文从不同专业角度提出了解决方案，为LTE基站测速提供了重要依据。
【关键词】FTP QOS
1 引言
随着IP业务发展，经常出现业务丢包、下载速率慢等问题，解决此问题需要查看链路情况、网络对接模式、QOS配置等。
本文通过某城市移动PTN承载LTE基站FTP测试速率不达标分析原因为在FTP测试中存在流量的突发情况，瞬间超过了PTN承载网配置的PIR峰值带宽。
针对上述问题本文从不同专业角度提出了解决方案，为LTE基站测速提供了重要依据。
2 问题背景
2016年上半年某地市移动进行拉网测试，出现很多基站FTP下载速率低的问题，最低速率在6-8Mbps。
Enodeb和SAEGW之间均由华为PTN承载。
该地市按集团规范对PTN端到端隧道限速为440Mbps（PIR）时，手机speedtest软件测试速率达不到30Mbps，经无线反馈FTP下载速率低的基站均在市区，市区Enodeb及核心网SGW为均爱立信厂家，且SGW为新设备，老SGW不存在此类问题。
2.1 原因分析
2.1.1 测速不达标分析
经对SPEEDTEST测速过程进行抓包分析，发现LTE测速过程中流量存在严重的瞬间突发，在1毫秒这个粒度上检查速率，最高速率约为600000/0.001S = 600M/S，严重超过了PTN 配置的峰值带宽PIR值，这势必会造成FTP下载丢包，导致滑动窗口缩小，影响整体平局测试速率。
由于Speedtest手机版本的软件下载时，和服务器端协商出来的瞬时速率超过PTN上的带宽限速440M，因此超过的部分会出现丢包的可能，进而肯定影响下载速率。
2.1.2 FTP测速原理
FTP下载实际是是基于TCP原理进行下载的，当TCP发送端发送数据时，如果采用“发一个包--等待ACK--再发一个包”，这种形式，效率会很低。
TCP一般是一次发X个包，然后等待ACK，这个X就是‘窗口’。
TCP的实际窗口大小，是客户端和服务器协商决定的。
而在FTP服务器和客户端网卡、以及FTP服务器软件上，都提供了窗口设置开关，以此来提升单次发包数量，进而提升TCP 协商后的窗口大小TCP的窗口实际上决定了传输速率，窗口越大传输速率越快；反之，如果传输速率慢了，那肯定是窗口变小了。
2.1.3 影响FTP测速问题分析
FTP服务器与客户端的网卡窗口：现网应用中，公网服务器窗口有专业人员，根据自身业务情况进行维护和优化，不同的公网服务器，优化程度和其所处的网络质量不相同，因此，下载速率各不一样；
FTP服务器软件窗口和缓存：一般的FTP服务器软件，如Filezilla、Server-U、IIS等，都会提供应用软件层面上的窗口和缓存大小设置入口。
同时，不同的FTP服务器软件实现机制不一样，下载效果上会有一些差异。
中间途径设备和网络的带宽限制和缓存能力：FTP测速下载的一般都是大文件，下载的时候，下行突发带宽都以端口线速发送（如GE端口，线速为1G），流量到达中间设备的时候，如果有PIR限速，则会造成拥塞丢包，TCP重传，重新协商窗口大小，从而影响下载速率。
网络固有的时延：TCP报文对时延非常敏感。
时延超过一定程度，TCP收不到ACK，就会TCP重传，最终影响下载速率。
因此，现网的时延对TCP报文传输影响很大。
其它因数：其他除上述四个基本因素之外，服务器硬件、客户端硬件、不同的客户端下载终端和软件、硬盘读写速度等等，都可能对下载速率有影响。
以上分析得出FTP测速不达标的原因为：测速过程中流量存在严重的瞬间突发，超过了PTN承载网配置的PIR峰值带宽。
2.2 解决思路
（1）采用标准化测试软件—由于部分软件本身的原因，导致其发送速率非常大，超过PTN 配置的峰值PIR而被丢弃，造成测试效果不好。
公网上的大型网站服务器一般经过优化，下载速率较高，但小型网站不能保证，因此在测试、验收、演示等场景，采用标准化测试软件进行测试。
（2）传送网优化—针对突发大流量的冲击，传送网可在设置隧道PIR限速的前提下，进一步采取端口限速、增大缓存等方式规避突发大流量引起的丢包。
（3）核心网优化—通过TCP加速或UGW/SGW 的下行流量整形，平滑速率，减低突发，可减少超过PTN峰值带宽，避免超过PIR丢包。
（4）无线侧优化—无线基站开通ACK控制（TPE增强）功能，协商出平滑的下载速率，避免突发导致丢包。
2.3 传送网优化方案
2.3.1 优化方案
（1）增加PTN 设备硬件缓存，将单个队列的缓存尽力提升，通过缓存吸纳业务侧的突发流量。
（2）改大PTN的PIR，用更大的预留带宽容纳业务侧的突发流量。
（3）采用简单QOS策略，不部署H-QOS，在业务接入口做CAR，将PBS值配置最大，容忍更大的突发。
2.3.2 负面因素
（1）设备硬件缓存是有限的，加大缓存会增加时延的问题，同时也会减少支持的突发基站数量，缓存越大、支持突发的基站数量越少。
目前LTE手机用户数量相对不大，基站流量模型不确定，盲目调整缓存存在不可预知的风险。
（2）如果将PIR由目前的440M/每接入环提升到640M/每接入环，那么目前比较普遍采用的GE接入环的接入能力就大打折扣，且不符合集团的配置规范。
（3）采用简单QOS策略，不部署H-QOS，缺点是无法做到端到端保证每条业务的CIR 带宽，带宽层层校验实现难度大。
在网络轻载时入口做CAR对提升测速效果明显，但在网络重载时car是无法确保每基站的CIR。
3 总结
FTP下载速率作为考核LTE基站达标率的KPI指标，出现类似问题，应该从多专业、多角度解决问题，协调相关技术部门对此问题进行研究，站在全网及端到端的角度，确定此问题的最优解决方案。
参考文献
[1]吴英.计算机网络应用软件编程技术[M].北京：机械工业出版社，2010.
[2]单滤斌，虞有池.PTN的QoS技术应用研究[J].邮电设计技术，2011（04）：51-55.。