浅谈4G吞吐率优化Word文档下载推荐.docx
《浅谈4G吞吐率优化Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《浅谈4G吞吐率优化Word文档下载推荐.docx（12页珍藏版）》请在冰豆网上搜索。
无法达到峰值
B、吞吐量能达到峰值但有波动，明显的“掉坑”现象，后又缓慢“爬起”，如图所示：
“掉坑”现象
C、吞吐量能达到峰值但有波动，变化较“陡峭”，如图所示
“陡峭”现象
定点UDP吞吐量异常表现：
由于UDP面向无连接、不保证可靠交付的传输特性。
UDP流量异常的表现就是平稳但无法达到峰值。
2、原因分析：
由于实际环境中传输侧（从Server到eNodeB）的组网架构庞大复杂，千差万别。
为方便描述下行定位流程，下图仅给出一简单的组网示意图，以说明数据流向。
上下行数据流向图
流量定位的大体思路为：
首先，判断该数传业务是UDP的还是TCP的，如果当前是TCP流量不足，则先用单线程UDP上下行灌包“探路”，看UDP上下行流量能否达到峰值，此举是为了扫清道路上的“小石头”，比如网卡限速、空口参数配置错误等等。
一般来说UDP流量无法达到峰值，TCP流量也很难上到峰值。
UDP流量问题定位，采用的是“追根溯源”法，即从服务器到UE端到端排查，看“水”流到哪里“节流”了。
其次，如果UDP流量能够达到峰值而TCP不行，则将问题原因锁定TCP本身传输机制上。
流量问题定位的思路如下：
流量问题定位思路
处理流程如下：
吞吐率处理流程
3、解决方案探讨：
3.1
无法传输数据（无法进行UDP灌包，UE侧PC无流量）
首先保证UE能够正常接入，再检查以下配置参数：
A、服务器侧有没有配回程路由，若没有需要在服务器侧配置回程路由。
命令如下：
routeaddUE业务IPmask子网掩码服务器业务IP–p
B、如果是华为UE，检查UE与PC之间连线及UE侧配置参数，通过OMT查看ARP和DHCP开关是否打开，若打开了业务PC网卡IP应该设置为自动获取方式；
若ARP和DHCP关闭，需要按照以下方式添加ARP和路由：
routeadd
服务器IPmask子网掩码UE业务IP–p
arp
–s服务器IPUEMAC地址UE业务IP
通过OMT查看ARP和DHCP开关
C、如果是三星UE或华为E398可以自动添加路由，无需手动添加路由。
可以尝试多拨号几次，如果还是不行，更换UE再尝试一下。
3.2
服务器问题排查
通过服务器向用户侧进行UDP灌包进行排查：
Server侧执行命令：
iperf–c
x.x.x.x（UE业务IP）–u–i1–t99999–b160m，
－b指示灌包流量，实际灌包流量根据使用的UE和小区带宽来决定，略微超过理论值，保证足够的数据量即可。
UEPC侧启动接收，命令：
iperf–s–u–i1，
执行以上操作后，发觉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
–cX.X.X.X（UE业务IP）
–i1
–t999999
–u
–b160m
–l1000,
有时-l1000可能还是有问题，需要仔细修改包长（MTU）的长度，例如
800,900,1110,1200等，都尝试一下。
3.3
传输链路排查
传输侧指Server服务器到eNodeBS1口的传输链路。
查看eNodeB侧入口流量是否充足可通过在M2000执行MML命令
DSPETHPORT查看
M2000查询入口流量
上图是一个下行灌包130M的例子，从图中可以看出eNodeB侧的入口流量
=16410349*8/1000/1000=131.28M。
表明从服务器到核心网再到eNodeB侧的流量是足够的。
eNodeB侧入口流量不足原因多是由于链路中间某个环节传输带宽不够造成的，如当出现eNB入口处流量不足现象，排查思路如下：
图eNB入口处流量不足排查思路
A、检查传输链路带宽设置，确保整个链路中的所有网元及接口全部为千兆级，包括但不限于服务器网口、组网中的全部交换机、路由设备，速率协商模式设为自协商;
B、若传输侧有用微波等其它介质来传输数据，需要与传输人员咨询确认，保证其传输带宽大于峰值；
3.4
空口问题排查
空口问题排查包括告警、干扰、基本配置参数、接入信令、在线用户数、License排查、空口信道质量排查。
优先排查告警，防止某些突发告警导致流量异常。
实际环境中空口问题引起流量异常的原因有非常多，本文只是列举了几种常见的情况。
空口处流量不足排查思路
A、通过M2000可以查看是否存在告警，如果有告警，先清除告警看是否正常；
B、空口信道质量，可以通过测试软件查看，峰值测试中如果要使得实际峰值逼近理论峰值，要保证小区RSRP在－85dBm以上，SINR26以上。
测试软件查看空口质量
信道质量也可以通过检查CQI
等参数反映，CQI主要由SINR决定,UE上报的CQI又决定了下行调度的MCS，如果SINR、CQI等偏低，更换选点多试几次。
CQI信息可以在M2000中信令跟踪管理菜单下查询到，具体位置信令跟踪管理---用户性能测试---信道质量监控。
C、接入信令排查（用户开户信息查询）接入信令中重点分析AMBR和QCI参数。
信令排查需要在eNB侧开启LMTUU口和S1口信令跟踪，然后使UE重新接入。
在S1口信令S1AP_INITIAL_CONTEXT_SETUP_REQ中查看开户AMBR是否设置恰当，如果不合适请核心网同事修改，一般建议150M以上。
同样在该信令上可查看默认承载QCI是否正确,
QCI须为Non-GBR，推荐为6、8、9，一定不要使用5（IMSsignaling），因为QCI=5是IMS信令，为QPSK调制，速率达不到峰值。
7为UM模式，也不推荐。
D、由于下行带宽是共享的，查询当前小区是否有其他用户接入，是否占用了下行资源。
E、通过LSTLICENSE
查看License信息。
一来查看license是否过期，功能是否有限制，如果不满足要求需要重新申请；
二来查看license上申请的吞吐量能力是否足够。
3.5UEPC侧问题排查
UEPC侧问题也是通过灌包来检测，如果Sever灌包正常，传输正常，但是业务PC侧速率不够，可能有两种情况，UE问题排查或者UE侧PC问题：
A、如果有多个UE，可尝试更换UE，看问题是否解决，如果问题解决很可能就是是UE本身
的问题
B、检查PC硬件配置：
建议使用ThinkPadT400高端机型，CPU双核2.0G以上，内存2G，
硬盘7200转，网口千兆，建议使用XPSP3系统。
检查PC上安装和运行的软件，建议删除或关闭除测试用软件外的其他软件，关闭Windows防火墙和其他杀毒软件的防火墙。
检查CPU占用率，如果超过80%说明当前处理任务繁重，需要关闭不用的软件或服务，或者更换性能更好的PC。
3.6TCP问题排查
TCP问题需要根据具体的情况进行分析：
如果是吞吐量平稳但达不到峰值则需要查看窗口等相关参数是否已优化，时延（RTT）是否过大；
如果能达到峰值但是速率不稳，有掉坑现象，则需要检查是否有丢包、严重乱序现象发生。
A、Windows操作系统中，接收窗口和发送窗口可通过注册表来设置的,且不同版本的操作系统优化方法不一样。
针对WinXP和2003系统，可以通过DrTCP工具修改，然后重启服务器以优化发送窗口和接收窗口，看吞吐量能否恢复正常。
B、环回时延偏大排查方法，先检查空口是否加密；
有些终端处理加密数据会有额外的开销导致环回RTT变长，进而影响到吞吐量，如果空口已经加密，尝试执行以下脚本去掉加密及完整性保护，看吞吐量能否恢复正常。
MODENODEBCIPHERCAP:
PrimaryCiperAlg=NULL,SecondCiperAlg=AES,hirdCiperAlg=Snow3G
MODENODEBINTEGRITYCAP:
PrimaryIntegrityAlg=NULL,SecondIntegrityAlg=AES,
ThirdIntegrityAlg=Snow3G;
C、查看BSR、SR周期是否过大；
BSR周期大于5ms会导致上行流量受限，RTT增大，缩短BSR周期可改善TCP传输性能。
若BSR周期大于5ms
修改BSR为5ms的命令如下（其中的QCI等级请根据开户类型进行调整，以下命令中全部使用QCI9为例）。
MODTYPDRBBSR:
QCI=QCI9,TPERODICBSRTIMER=TPeriodBSRTimer_sf5,RETXBSRTIMER=sf320;
通过以上方法如果还是无法解决问题，需要将问题记录，收集相关数据，反馈相关部门处理。
4、总结和推广：
如今LTE网络不断发展壮大，如何快速切入4G网络优化工作，更好的发挥4G新技术的优势，通过总结4G吞吐率优化思路和梳理优化流程，为后期4G网优优化工作铺好道路，争取快速上手4G网络优化工作。
升级会员 