案例摘要：
隨著LTE網絡的牌照頒發(fā)，各大運營商正如火如荼的建設期待已久的4G網絡，如何能讓新技術更好的發(fā)揮，這是我們優(yōu)化工作需要考慮的問題，LTE網絡設計峰值速率下行100Mbps，上行50Mbps,如何能真正體現(xiàn)LTE網絡的實際速率，反應網絡問題，如何做好LTE吞吐率優(yōu)化工作顯得尤為重要，因此需要明確目的，通過分析相關數(shù)據(jù)，定位網絡問題，為今后類似問題提供優(yōu)化思路及優(yōu)化方法。本文主要描述了用戶接入網絡后進行上下行數(shù)傳時出現(xiàn)的相關問題的定位流程，包括使用TCP和UDP兩種方式。
1、問題描述：
先了解兩個概念，TCP和UDP，兩者有著明顯的區(qū)別：
TCP發(fā)送的包有序號，對方收到包后要給一個反饋，如果超過一定時間還沒收到反饋就自動執(zhí)行超時重發(fā)，因此TCP最大的優(yōu)點是可靠。一般網頁（http）、郵件（SMTP)、遠程連接(Telnet)、文件(FTP)傳送就用TCP。
UDP是面向消息的協(xié)議，通信時不需要建立連接，數(shù)據(jù)的傳輸自然是不可靠的，一般用于多點通信和實時的數(shù)據(jù)業(yè)務，比如語音廣播、視頻、QQ、TFTP(簡單文件傳送）、SNMP（簡單網絡管理協(xié)議）、RTP（實時傳送協(xié)議）RIP（路由信息協(xié)議，如報告股票市場，航空信息）、DNS(域名解釋）。注重速度流暢。
在L網測試時，定點吞吐量異常表現(xiàn)現(xiàn)象分TCP吞吐量異常和UDP吞吐量異常：
TCP由于面向連接，保證交付，且采用滑動窗口等數(shù)據(jù)傳輸擁塞避免機制，故吞吐量異常的表現(xiàn)非常多，一般常見的有以下幾種：
A、吞吐量平穩(wěn)但低于峰值5%以上；
[attach]306877[/attach]
圖 無法達到峰值
B、吞吐量能達到峰值但有波動，明顯的“掉坑”現(xiàn)象，后又緩慢“爬起”，如圖所示：
[attach]306879[/attach]
圖 “掉坑”現(xiàn)象
C、吞吐量能達到峰值但有波動，變化較“陡峭”，如圖所示
[attach]306880[/attach]
圖 “陡峭”現(xiàn)象
定點UDP吞吐量異常表現(xiàn)：由于UDP面向無連接、不保證可靠交付的傳輸特性。UDP流量異常的表現(xiàn)就是平穩(wěn)但無法達到峰值。
2、原因分析：
由于實際環(huán)境中傳輸側（從Server到eNodeB）的組網架構龐大復雜，千差萬別。為方便描述下行定位流程，下圖僅給出一簡單的組網示意圖，以說明數(shù)據(jù)流向。
[attach]306881[/attach]
圖 上下行數(shù)據(jù)流向圖
流量定位的大體思路為：首先，判斷該數(shù)傳業(yè)務是UDP的還是TCP的，如果當前是TCP流量不足，則先用單線程UDP上下行灌包“探路”，看UDP上下行流量能否達到峰值，此舉是為了掃清道路上的“小石頭”，比如網卡限速、空口參數(shù)配置錯誤等等。一般來說UDP流量無法達到峰值，TCP流量也很難上到峰值。UDP流量問題定位，采用的是“追根溯源”法，即從服務器到UE端到端排查，看“水”流到哪里“節(jié)流”了。
其次，如果UDP流量能夠達到峰值而TCP不行，則將問題原因鎖定TCP本身傳輸機制上。流量問題定位的思路如下：
[attach]306882[/attach]
圖 流量問題定位思路
處理流程如下：
[attach]306883[/attach]
圖 吞吐率處理流程
3、解決方案探討：
3.1 無法傳輸數(shù)據(jù)（無法進行UDP灌包，UE側PC無流量）
首先保證UE能夠正常接入，再檢查以下配置參數(shù)：
A、服務器側有沒有配回程路由，若沒有需要在服務器側配置回程路由。命令如下：
route add UE業(yè)務IP mask 子網掩碼 服務器業(yè)務IP –p
B、如果是華為UE，檢查UE與PC之間連線及UE側配置參數(shù)，通過OMT查看ARP和DHCP開關是否打開，若打開了業(yè)務PC網卡IP應該設置為自動獲取方式；若ARP和DHCP關閉，需要按照以下方式添加ARP和路由：
route add 服務器IP mask 子網掩碼 UE業(yè)務IP –p
arp –s 服務器IP UE MAC地址 UE業(yè)務IP
[attach]306884[/attach]
圖 通過OMT查看ARP和DHCP開關
C、如果是三星UE或華為E398可以自動添加路由，無需手動添加路由�？梢試L試多撥號幾次，如果還是不行，更換UE再嘗試一下。
3.2 服務器問題排查
通過服務器向用戶側進行UDP灌包進行排查：
Server側執(zhí)行命令：iperf –c
x.x.x.x(UE業(yè)務IP) –u –i 1 –t 99999 –b 160m，
－b指示灌包流量，實際灌包流量根據(jù)使用的UE和小區(qū)帶寬來決定，略微超過理論值，保證足夠的數(shù)據(jù)量即可。
UE PC側啟動接收，命令：iperf –s –u –i 1，
執(zhí)行以上操作后，發(fā)覺Server側出口流量低，出口流量就不足160M.
[attach]306885[/attach]
圖 出口流量就不足160M
排查思路如下：
[attach]306886[/attach]
圖 服務器流量不足排查思路
A、Server側推薦專業(yè)的IBM/HP小型服務器，CPU雙核2.8GHz以上，內存4G，250G硬盤，千兆網卡，操作系統(tǒng)用Windows2003SP2/SP3+IIS模式，勿使用Serv-U作FTP服務器；
B、檢查iperf灌包工具的版本及參數(shù)是否使用正確，UDP灌包最好使用windows命令行的iperf，請勿使用gperf等圖形界面的灌包方式。 Iperf最好使用1.7.0及以后版本的，之前版本的有點問題。 有的網卡對包長“敏感”，需要修改包長看出口流量能否達到灌包設置值。修改包長為在命令后添加 -l , 如 iperf –c X.X.X.X(UE業(yè)務IP) –i 1 –t 999999 –u –b 160m –l 1000,
有時-l 1000可能還是有問題，需要仔細修改包長（MTU）的長度，例如 800,900,1110,1200等，都嘗試一下。
3.3 傳輸鏈路排查
傳輸側指Server服務器到eNodeB S1口的傳輸鏈路。查看eNodeB側入口流量是否充足可通過在M2000執(zhí)行MML命令 DSP ETHPORT查看
[attach]306887[/attach]
圖 M2000查詢入口流量
上圖是一個下行灌包130M的例子，從圖中可以看出eNodeB側的入口流量 = 16410349 * 8 /1000 / 1000 = 131.28M。表明從服務器到核心網再到eNodeB側的流量是足夠的。
eNodeB側入口流量不足原因多是由于鏈路中間某個環(huán)節(jié)傳輸帶寬不夠造成的，如當出現(xiàn)eNB入口處流量不足現(xiàn)象，排查思路如下：
[attach]306888[/attach]
圖eNB入口處流量不足排查思路
A、檢查傳輸鏈路帶寬設置，確保整個鏈路中的所有網元及接口全部為千兆級，包括但不限于服務器網口、組網中的全部交換機、路由設備，速率協(xié)商模式設為自協(xié)商;
B、若傳輸側有用微波等其它介質來傳輸數(shù)據(jù)，需要與傳輸人員咨詢確認，保證其傳輸帶寬大于峰值；
3.4 空口問題排查
空口問題排查包括告警、干擾、基本配置參數(shù)、接入信令、在線用戶數(shù)、License排查、空口信道質量排查。優(yōu)先排查告警，防止某些突發(fā)告警導致流量異常。 實際環(huán)境中空口問題引起流量異常的原因有非常多，本文只是列舉了幾種常見的情況。
[attach]306889[/attach]
圖 空口處流量不足排查思路
A、通過M2000可以查看是否存在告警，如果有告警，先清除告警看是否正常；
B、空口信道質量，可以通過測試軟件查看，峰值測試中如果要使得實際峰值逼近理論峰值，要保證小區(qū)RSRP在－85dBm以上，SINR26以上。
[attach]306890[/attach]
圖 測試軟件查看空口質量
信道質量也可以通過檢查CQI 等參數(shù)反映，CQI主要由SINR決定,UE上報的CQI又決定了下行調度的MCS，如果SINR、CQI等偏低，更換選點多試幾次。CQI信息可以在M2000中信令跟蹤管理菜單下查詢到，具體位置信令跟蹤管理---用戶性能測試---信道質量監(jiān)控。
C、接入信令排查（用戶開戶信息查詢）接入信令中重點分析AMBR和QCI參數(shù)。信令排查需要在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、由于下行帶寬是共享的，查詢當前小區(qū)是否有其他用戶接入，是否占用了下行資源。
E、通過LST LICENSE 查看License信息。一來查看license是否過期，功能是否有限制，如果不滿足要求需要重新申請；二來查看license上申請的吞吐量能力是否足夠。
3.5 UE PC側問題排查
UE PC側問題也是通過灌包來檢測，如果Sever灌包正常，傳輸正常，但是業(yè)務PC側速率不夠，可能有兩種情況，UE問題排查或者UE側PC問題：
A、如果有多個UE，可嘗試更換UE，看問題是否解決，如果問題解決很可能就是是UE本身
的問題
B、檢查PC硬件配置：建議使用ThinkPad T400高端機型，CPU雙核2.0G以上，內存2G，
硬盤7200轉，網口千兆，建議使用XP SP3系統(tǒng)。檢查PC上安裝和運行的軟件，建議刪除或關閉除測試用軟件外的其他軟件，關閉Windows防火墻和其他殺毒軟件的防火墻。檢查CPU占用率，如果超過80%說明當前處理任務繁重，需要關閉不用的軟件或服務，或者更換性能更好的PC。
3.6 TCP問題排查
TCP問題需要根據(jù)具體的情況進行分析：如果是吞吐量平穩(wěn)但達不到峰值則需要查看窗口等相關參數(shù)是否已優(yōu)化，時延（RTT）是否過大；如果能達到峰值但是速率不穩(wěn)，有掉坑現(xiàn)象，則需要檢查是否有丟包、嚴重亂序現(xiàn)象發(fā)生。排查思路如下：
[attach]306891[/attach]
A、Windows操作系統(tǒng)中，接收窗口和發(fā)送窗口可通過注冊表來設置的,且不同版本的操作系統(tǒng)優(yōu)化方法不一樣。針對Win XP和2003系統(tǒng)，可以通過DrTCP工具修改，然后重啟服務器以優(yōu)化發(fā)送窗口和接收窗口，看吞吐量能否恢復正常。
B、環(huán)回時延偏大排查方法，先檢查空口是否加密；
[attach]306892[/attach]
有些終端處理加密數(shù)據(jù)會有額外的開銷導致環(huán)回RTT變長，進而影響到吞吐量，如果空口已經加密，嘗試執(zhí)行以下腳本去掉加密及完整性保護，看吞吐量能否恢復正常。
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等級請根據(jù)開戶類型進行調整，以下命令中全部使用QCI9為例）。
MOD TYPDRBBSR: QCI=QCI9, TPERODICBSRTIMER=TPeriodBSRTimer_sf5, RETXBSRTIMER=sf320;
[attach]306893[/attach]
通過以上方法如果還是無法解決問題，需要將問題記錄，收集相關數(shù)據(jù)，反饋相關部門處理。
4、總結和推廣：
如今LTE網絡不斷發(fā)展壯大，如何快速切入4G網絡優(yōu)化工作，更好的發(fā)揮4G新技術的優(yōu)勢，通過總結4G吞吐率優(yōu)化思路和梳理優(yōu)化流程，為后期4G網優(yōu)優(yōu)化工作鋪好道路，爭取快速上手4G網絡優(yōu)化工作。
關注樓主