UE PC侧启动接收，命令：iperf –s –u –i 1，
执行以上操作后，发觉Server侧出口流量低，出口流量就不足160M.
图 出口流量就不足160M
排查思路如下：
图 服务器流量不足排查思路
A、Server侧推荐专业的IBM/HP小型服务器，CPU双核2.8GHz以上，内存4G，250G硬 盘，千兆网卡，操作系统用Windows2003SP2/SP3+IIS模式，勿使用Serv-U作FTP服务器； B、检查iperf灌包工具的版本及参数是否使用正确，UDP灌包最好使用windows命令行的iperf，请勿使用gperf等图形界面的灌包方式。 Iperf最好使用1.7.0及以后版本的，之前版本的有点问题。 有的网卡对包长“敏感”，需要修改包长看出口流量能否达到灌包设置值。修改包长为在命令后添加 -l , 如 iperf –c X.X.X.X(UE业务IP) –i 1 –t 999999 –u –b 160m –l 1000, 有时-l 1000可能还是有问题，需要仔细修改包长（MTU）的长度，例如
第6页, 共11页
800,900,1110,1200等，都尝试一下。 3.3 传输链路排查
传输侧指Server服务器到eNodeB S1口的传输链路。查看eNodeB侧入口流量是否充足可通过在M2000执行MML命令 DSP ETHPORT查看
图 M2000查询入口流量
上图是一个下行灌包130M的例子，从图中可以看出eNodeB侧的入口流量 = 16410349 * 8 /1000 / 1000 = 131.28M。表明从服务器到核心网再到eNodeB侧的流量是足够的。
eNodeB侧入口流量不足原因多是由于链路中间某个环节传输带宽不够造成的，如当出现eNB入口处流量不足现象，排查思路如下：
图eNB入口处流量不足排查思路
A、检查传输链路带宽设置，确保整个链路中的所有网元及接口全部为千兆级，包括但不限于服务器网口、组网中的全部交换机、路由设备，速率协商模式设为自协商;
B、若传输侧有用微波等其它介质来传输数据，需要与传输人员咨询确认，保证其传输带宽大于峰值； 3.4 空口问题排查
第7页, 共11页
空口问题排查包括告警、干扰、基本配置参数、接入信令、在线用户数、License排查、空口信道质量排查。优先排查告警，防止某些突发告警导致流量异常。 实际环境中空口问题引起流量异常的原因有非常多，本文只是列举了几种常见的情况。
图 空口处流量不足排查思路
A、 通过M2000可以查看是否存在告警，如果有告警，先清除告警看是否正常；
B、 空口信道质量，可以通过测试软件查看，峰值测试中如果要使得实际峰值逼近理论峰值，
要保证小区RSRP在－85dBm以上，SINR26以上。
图 测试软件查看空口质量
信道质量也可以通过检查CQI 等参数反映，CQI主要由SINR决定,UE上报的CQI又决定了下行调度的MCS，如果SINR、CQI等偏低，更换选点多试几次。CQI信息可以在M2000
第8页, 共11页
中信令跟踪管理菜单下查询到，具体位置信令跟踪管理---用户性能测试---信道质量监控。 C、 接入信令排查（用户开户信息查询）接入信令中重点分析AMBR和QCI参数。信令排查
需要在eNB侧开启LMT UU口和S1口信令跟踪，然后使UE重新接入。在S1口信令S1AP_INITIAL_CONTEXT_SETUP_REQ中查看开户AMBR是否设置恰当，如果不合适请核心网同事修改，一般建议150M以上。同样在该信令上可查看默认承载QCI是否正确, QCI须为Non-GBR，推荐为6、8、9，一定不要使用5（IMS signaling），因为QCI=5是IMS信令，为QPSK调制，速率达不到峰值。7为UM模式，也不推荐。
D、 由于下行带宽是共享的，查询当前小区是否有其他用户接入，是否占用了下行资源。 E、 通过LST LICENSE 查看License信息。一来查看license是否过期，功能是否有限制，如
果不满足要求需要重新申请；二来查看license上申请的吞吐量能力是否足够。 3.5 UE PC侧问题排查
UE PC侧问题也是通过灌包来检测，如果Sever灌包正常，传输正常，但是业务PC侧
速率不够，可能有两种情况，UE问题排查或者UE侧PC问题：
A、如果有多个UE，可尝试更换UE，看问题是否解决，如果问题解决很可能就是是UE本身 的问题
B、检查PC硬件配置：建议使用ThinkPad T400高端机型，CPU双核2.0G以上，内存2G， 硬盘7200转，网口千兆，建议使用XP SP3系统。检查PC上安装和运行的软件，建议删除或关闭除测试用软件外的其他软件，关闭Windows防火墙和其他杀毒软件的防火墙。检查CPU占用率，如果超过80%说明当前处理任务繁重，需要关闭不用的软件或服务， 或者更换性能更好的PC。 3.6 TCP问题排查
TCP问题需要根据具体的情况进行分析：如果是吞吐量平稳但达不到峰值则需要查看窗口等相关参数是否已优化，时延（RTT）是否过大；如果能达到峰值但是速率不稳，有掉坑现象，则需要检查是否有丢包、严重乱序现象发生。排查思路如下：
第9页, 共11页
A、 Windows操作系统中，接收窗口和发送窗口可通过注册表来设置的,且不同版本的操作系
统优化方法不一样。针对Win XP和2003系统，可以通过DrTCP工具修改，然后重启服务器以优化发送窗口和接收窗口，看吞吐量能否恢复正常。 B、 环回时延偏大排查方法，先检查空口是否加密；
有些终端处理加密数据会有额外的开销导致环回RTT变长，进而影响到吞吐量，如果空口已经加密，尝试执行以下脚本去掉加密及完整性保护，看吞吐量能否恢复正常。 MOD ENODEBCIPHERCAP: PrimaryCiperAlg=NULL, SecondCiperAlg=AES, hirdCiperAlg=Snow3G MOD ENODEBINTEGRITYCAP: PrimaryIntegrityAlg=NULL, SecondIntegrityAlg=AES, ThirdIntegrityAlg=Snow3G;
C、 查看BSR、SR周期是否过大；BSR周期大于5ms会导致上行流量受限，RTT增大，缩短
BSR周期可改善TCP传输性能。若BSR周期大于5ms 修改BSR为5ms的命令如下（其中的QCI等级请根据开户类型进行调整，以下命令中全部使用QCI9为例）。
MOD TYPDRBBSR: QCI=QCI9, TPERODICBSRTIMER=TPeriodBSRTimer_sf5, RETXBSRTIMER=sf320;
第10页, 共11页
5G优化最佳实践东莞基于数传原理剖析网络速率问题实践总结
