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