1 前言

5G建網(wǎng)初期，LTE網(wǎng)絡(luò)依然是運營商的主體運營網(wǎng)絡(luò)，兼顧著大量數(shù)傳流量業(yè)務(wù)和VOLTE語音業(yè)務(wù)的重任，而數(shù)傳流量業(yè)務(wù)也是LTE網(wǎng)絡(luò)最主要的業(yè)務(wù)，同時也是運營商的收入支柱，更是能引起用戶感知的敏感區(qū)域。顯然數(shù)傳流量的質(zhì)量，尤其是整個數(shù)傳過程中發(fā)生的問題，也成了LTE網(wǎng)絡(luò)的主要難題，因此對LTE網(wǎng)絡(luò)數(shù)傳流量問題的分析過程以及解決方案必然是優(yōu)化人員研究的重點課題。該論文正是從潛在的速率影響因素著手直到對數(shù)傳流量問題的總體定位分析，乃至UDP和TCP問題解決思路深入淺出的探討，最后用實際案例的驗證來完善了整個論文的研究過程。為現(xiàn)在及今后解決LTE數(shù)傳流量問題的分析與處理方面，提供了完全可以借鑒的實戰(zhàn)性參考價值。

2 LTE網(wǎng)絡(luò)數(shù)傳流量問題定位總體思路

2.1 LTE數(shù)傳問題的影響因素

讓我們更加直白的用因果關(guān)系分析圖來說明LTE數(shù)傳問題的影響因素，如圖1所示。

圖1 LTE數(shù)傳問題影響因素圖

2.2 LTE吞吐率異常概念及表現(xiàn)

吞吐率異常是指用戶應(yīng)用層或MAC層吞吐率偏低或存在較大波動，吞吐率波動可以從LTE測試工具吞吐率統(tǒng)計上直觀的表示出來，分為定點TCP和定點UDP吞吐量異常。異常主要有兩種表現(xiàn)；吞吐量波動大和偏低。TCP采用滑動窗口傳輸數(shù)據(jù)，故異常表現(xiàn)較多；包括吞吐量平穩(wěn)但低于峰值5%以上、能達(dá)峰值且有“掉坑”，后又慢“爬坡”的現(xiàn)象或能達(dá)峰值而有“陡峭”現(xiàn)象，而UDP由于面向無連接、不保證可靠交付的傳輸特性，故異常表現(xiàn)平穩(wěn)但達(dá)不到峰值。

2.2.1 LTE吞吐率正常與異常對比

理想情況下UE下行峰值吞吐量如圖2所示，TCP流量異常“慢爬坡”及“掉坑”現(xiàn)象如圖3所示。

圖2 理想情況下UE下行峰值吞吐量

圖3 TCP流量異?！奥榔隆奔啊暗艨印爆F(xiàn)象

2.3 吞吐率問題總體定位思路及步驟

2.3.1 吞吐率問題判斷總體思路

吞吐率問題總體判斷思路分四步去判斷：第一步判斷問題范圍是全網(wǎng)普遍，還是Top小區(qū)問題；第二步核查告警與參數(shù)，對影響吞吐率的基本因素進行逐個排查；第三步判斷問題類型是由UDP的還是TCP引起的；第四步就是分段隔離判斷，是“空口問題”還是“非空口問題”。

2.3.2 吞吐率問題判斷通用步驟詳解

通用步驟1：判斷問題范圍是否全網(wǎng)普遍問題。重點關(guān)注網(wǎng)絡(luò)公用網(wǎng)元，取出整網(wǎng)原始話統(tǒng)數(shù)據(jù)，結(jié)合RB占用率、用戶數(shù)和MCS分布來初步判定；如果是TOP小區(qū)問題，那么非Top小區(qū)公共網(wǎng)元可以直接排除，重點排查不同之處。

通用步驟2：核查告警及參數(shù)。從歷史問題統(tǒng)計60%的網(wǎng)上性能問題都是由參數(shù)設(shè)置錯誤或者告警引起的,此步驟分3個核查動作：

① 核查動作1：外部事件及歷史操作檢 ；涉及到核心網(wǎng)方面是否增加或更改配置，傳輸方面涉及改造或割接、PIR和CIR等，基站方面核心參數(shù)是否發(fā)生修改、RB/DL grant分配不足、IBLER不收斂、MIMO/TM轉(zhuǎn)換模式問題、RRU通道問題、CCE分配問題、功率參數(shù)問題、ICIC問題、調(diào)度算法問題、RANK問題等。

② 核查動作2：對核查出明顯影響業(yè)務(wù)速率的告警，采取先閉環(huán)再分析最后消除的原則。分析告警時需注意速率變化時間和告警發(fā)生時間的關(guān)聯(lián)及范圍，內(nèi)容如表1所示。

③ 核查動作3：參數(shù)核查優(yōu)先分析無線網(wǎng)參數(shù)設(shè)置，必要時對其他參數(shù)也要進行核查，分為eNodeB參數(shù)（詳見表2）和非eNodeB參數(shù)核查。

通用步驟3：判斷該數(shù)傳業(yè)務(wù)問題是由UDP還是TCP引起的，具體又細(xì)分3小步去判定：

① 第1步如果當(dāng)前是TCP流量不足，則先用單線程UDP上/下行灌包“探路”，看UDP上/下行流量能否達(dá)到峰值，一般情況UDP與TCP流量都難達(dá)到峰值。如果UDP流量能達(dá)到峰值而TCP不能，顯然問題原因?qū)⒈绘i定在TCP本身傳輸機制上。

② 第2步采用最簡單的方法-UDP灌包來判定是否為UDP類問題，操作過程與判斷方法如下：

【操作方法】采用iperf網(wǎng)絡(luò)流量的檢測工具，將iperf.exe分別放置在服務(wù)器的UE/PC的C盤根目錄下，然后打開DOS窗口，輸入cd C:，將當(dāng)前路徑調(diào)整到iperf所在的C盤下； 在接收方側(cè)輸入iperf-s-u-I 1，然后回車，表示建立起接受服務(wù)；在發(fā)送方側(cè)輸入iperf-c x.x.x.x -u-i 1 -b 100m –t 9999，其中-c x.x.x.x表示連接到該IP，-u表示灌UDP包，-i 1表示每秒顯示一次灌包出口流量，-b 100m表示每秒灌100 Mbits的包。

表1 告警核查表

表2 eNodeB參數(shù)核查表

【判斷方法】若吞吐率與TCP業(yè)務(wù)基本持平或者比TCP還低，則進入UDP類問題定位；若吞吐率明顯大于TCP業(yè)務(wù)，則進入TCP類問題定位。

③ 第3步判斷是否為TCP類問題的具體操作過程與判斷方法如下：

【操作方法】在接收方建立接收服務(wù)器，輸入命令iperf-s-I 1–w 512 k，其中–s表示建立接收服務(wù)器，-I 1表示每1秒顯示一次接收到的流量，-w 512 k表示接收方的接收窗口是512 kbyte。與UDP的接收服務(wù)器相比，少了–u選項，在發(fā)送方輸入命令iperf-c x.x.x.x–t 10 000–i 1 – w 512k，其中-c x.x.x.x表示連接到該IP，–t 10000表示灌包時長為1 000 m，–i 1表示每1秒顯示一次灌包出口流量，–w 512 k表示發(fā)送方的接收窗口為512 Kbyte。兩個操作過程都需注意發(fā)送方的灌包速率和持續(xù)時間，可以根據(jù)需要進行調(diào)整。

【判斷方法】若吞吐率明顯小于UDP業(yè)務(wù)，則進入TCP類問題定位。

通用步驟4：根據(jù)網(wǎng)元將數(shù)據(jù)業(yè)務(wù)分隔為空口問題與非空口問題去判斷。

3 UDP流量問題定位

3.1 UDP流量問題定位總思路

UDP流量問題定位通常采用“追根溯源”法；即對服務(wù)器、eNodeB入口、空口、UE和PC進行逐點排查，看“水”流到哪里被“節(jié)流”，排查內(nèi)容如圖4所示。

圖4 追根溯源法逐點排查圖

3.1.1 服務(wù)器側(cè)流量不足問題定位

【問題現(xiàn)象】：灌包出口流量比指定的灌包流量低。

【定位思路】：服務(wù)器側(cè)流量不足可以從應(yīng)用層輸出流量不足和服務(wù)器限速兩方面入手定位；前者可細(xì)化從Iperf工具的版本問題和配置參數(shù)錯誤定位，后者又可細(xì)化從網(wǎng)卡硬件能力不足、配置錯誤、防火墻限速、改包或截斷定位。

【排查步驟】：①檢查電腦性能、測試便攜、服務(wù)器性能是否配置夠高。短呼測試時，F(xiàn)TP服務(wù)器所用的操作系統(tǒng)，推薦使用Windows Vista、Linux內(nèi)核2.6.19之后的版本。搬遷或升級前后的測試必須要使用相同的測試UE設(shè)備。②檢查測試工具性能受限或進行了限速配置也會導(dǎo)致速率無法達(dá)到預(yù)期效果。③檢查iperf灌包工具的版本及參數(shù)是否使用正確，UDP灌包最好使用Windows命令行1.7.0及以后版本的iperf。有的網(wǎng)卡對包長“敏感”，需要修改包長，看出口流量能否達(dá)到灌包設(shè)置值。

3.1.2 eNodeB入口流量不足問題定位

【問題現(xiàn)象】：MML命令DSP ETHPORT、DSP IPPATH或者在M2 000傳輸性能跟蹤-IP Link Monitoring中，發(fā)現(xiàn)流量過低。

【排查思路】：eNodeB入口流量不足排查從傳輸鏈路上某個網(wǎng)元網(wǎng)卡限速或存在微波傳輸帶寬受限及傳輸丟包3種情況考慮排查。

【排查步驟】：①檢查傳輸鏈路帶寬設(shè)置，確保整個鏈路中所有網(wǎng)元及接口全部為千兆級和自協(xié)商。②若傳輸側(cè)用微波來傳輸數(shù)據(jù)，帶寬需要大于空口峰值。③傳輸UDP丟包測試在核心網(wǎng)支持的情況下，可以使用UDP環(huán)回測試方式來測試S1傳輸狀態(tài)。

3.1.3 空口問題定位

【問題現(xiàn)象】：在eNodeB入口流量充足的情況下，在UE側(cè)接收到的流量卻不足。

【排查思路】：具體排查思路從四個方面考慮；即空口質(zhì)量差、話務(wù)及容量、通道/干擾及切換。

（1）空口質(zhì)量差分析：空口信道質(zhì)量是影響數(shù)傳流量最明顯的因素，可以通過BLER、RSRP、SINR等指標(biāo)來衡量，具體排查分3步：第1步檢查BLER時在M2 000上啟動BLER監(jiān)測，若BLER大于12%的話，會導(dǎo)致部分RB用于重傳數(shù)據(jù)影響吞吐量，此時需改善無線環(huán)境；第2步檢查RSRP、SINR值，只有小區(qū)RSRP值在-85 dBm以上，SINR值在26 dB以上，數(shù)傳峰值測試中才可能實際峰值逼近理論峰值，若SINR值不正常，也需改善無線環(huán)境；第3步檢查平均CQI、MCS；【話統(tǒng)】小區(qū)的平均CQI出現(xiàn)下降、上下行MCS出現(xiàn)下降、上下行MCS各階比例出現(xiàn)明顯變化等情況。

（2）話務(wù)及容量分析，如表4所示。

表4 話務(wù)/容量影響速率分析表

（3）通道/干擾分析：通道問題主要是小區(qū)通道不平衡，將會影響下行SINR，導(dǎo)致選階異常影響流量。華為測試UE可以在PROBE上通過RSRP Measurement觀察兩天線接收功率是否平衡。M2 000后臺可以打開RSSI相關(guān)測量項，獲取小區(qū)RSSI話統(tǒng)數(shù)據(jù)，對比分析可發(fā)現(xiàn)小區(qū)通道不平衡問題。干擾主要是鄰區(qū)干擾，嚴(yán)重時會極度影響數(shù)傳吞吐量。它的現(xiàn)象是無論怎么調(diào)整天線，UE測出的SINR都極低而RSRP卻極好。干擾又分內(nèi)或外干擾；內(nèi)干擾是PCI規(guī)劃或RF配置不合理導(dǎo)致小區(qū)間干擾，造成MCS偏低，而外干擾會導(dǎo)致IBER偏高或MCS偏低。

（4）切換分析：切換分析只考慮路測，定點測試可以忽略。影響有；乒乓切換影響數(shù)傳連續(xù)性、切換時延過大導(dǎo)致調(diào)度次數(shù)減少、切換不及時導(dǎo)致小區(qū)信道質(zhì)量遠(yuǎn)低于鄰區(qū)及UE實際SINR低、切換失敗及異常等都會影響速率下降甚至業(yè)務(wù)中斷。

3.1.4 UE無法數(shù)傳問題定位

【問題現(xiàn)象】：無法進行UDP灌包，UE側(cè)PC無流量。

【定位思路】：UE能夠正常接入小區(qū)，說明信令面及傳輸物理鏈路正常，那么無法數(shù)傳很可能是參數(shù)、軟件設(shè)置錯誤、路由信息配置錯誤等原因引起。

【排查步驟】：首先保證UE能夠正常接入后再檢 以下參數(shù)；檢查服務(wù)器側(cè)有沒有配回程路由、檢查UE業(yè)務(wù)PC上的路由信息、檢查電腦防火墻配置。然后在S1口信令中檢查用戶開戶信息AMBR設(shè)置是否為0情況，此因也會出現(xiàn)能接入但無法數(shù)傳的情況。最后檢查商用終端對ROHC頭壓縮功能支持情況，如果不支持但eNodeB又開啟了該功能，就會造成無法數(shù)傳的現(xiàn)象，需將eNodeB的ROHC頭壓縮算法關(guān)閉。

4 TCP流量問題定位

4.1 TCP吞吐率影響因素

TCP吞吐率影響因素有峰值與均值兩個方面：一方面TCP的峰值速率受通道帶寬、發(fā)送窗口、RTT時延三個因素影響。TCP的峰值速率（bps）=窗口大?。╞it）/RTT（s），在通道帶寬不受限的情況下，發(fā)送窗口越大，RTT時延越小則TCP的速率越高。另一方面TCP的平均速率還與速率抖動及丟包有關(guān)。RTT時延抖動直接影響速率抖動。在TCP發(fā)送機制中，應(yīng)用層丟包引起的發(fā)送窗口減半會影響吞吐率均值。TCP基本傳輸參數(shù)的配、空口或有線傳輸通道問題導(dǎo)致的 包和時延增加、UE和PC性能、防火墻設(shè)置等因素都是TCP吞吐率降低的主要原因。

4.2 TCP流量問題定位思路

TCP流量問題定位思路：確定UDP沒有問題后，TCP問題需要根據(jù)具體情況分析；如果是吞吐量平穩(wěn)但達(dá)不到峰值，則需要查看發(fā)送/接收窗口等相關(guān)參數(shù)設(shè)置是否合理及已優(yōu)化，RTT是否過大；如果能達(dá)到峰值但是速率波動大，有掉坑現(xiàn)象，則需要檢查是否有丟包、嚴(yán)重亂序、RTT波動等現(xiàn)象發(fā)生。

4.3 TCP速率波動大的原因分析

較常見的速率波動原因有TCP層丟包以及傳輸時延波動兩種。TCP層丟包的原因可能是帶寬擁塞，緩存超時或軟件限制；有線傳輸中的交換機、路由器、核心網(wǎng)等都有帶寬限制，速率超過門限后會發(fā)生丟包；在無線側(cè)PDCP層為了保證不同業(yè)務(wù)等級的服務(wù)質(zhì)量，有丟棄定時器Discard Timer，緩存的數(shù)據(jù)包在定時器超時之前仍未發(fā)走，則會被主動丟棄；另外防火墻、網(wǎng)卡設(shè)置等也可能引起丟包。

傳輸時延波動可能有空口BLER、空口調(diào)度周期、PC性能等原因。因為TCP用了雙向傳輸，所有上行或下行的穩(wěn)定及突發(fā)BLER都會引起時延波動；空口調(diào)度周期設(shè)置不合理會導(dǎo)致數(shù)據(jù)包或TCP ACK緩存，也會引起時延波動；另外發(fā)送方/接收方的電腦性能同樣會影響應(yīng)用層與TCP層數(shù)據(jù)包的遞交時延，照樣會引起時延波動。

4.3.1 TCP速率波動大原因分析檢查步驟

第1步檢查無線環(huán)境及參數(shù)：若UDP灌包沒有問題，則觀察空口上/下行BLER是否過高或有突變的現(xiàn)象，若有則先解決該問題后再做TCP業(yè)務(wù)；若無BLER過高或突變的問題，則通過命令將PDCP DiscordTimer改為無限長。在eNodeB LMT中輸出命令LST STANDARDQCI和MOD RLCPDCPPARAGROUP將指定QCI等級的DiscardTimer改為無限長，然后UE重新接入后再做TCP業(yè)務(wù)，以避免PDCP DiscardTimer設(shè)置過小導(dǎo)致的丟包問題；若修改SR調(diào)度周期不能解決問題，則將上行設(shè)置為采用預(yù)調(diào)度或固定調(diào)度來做業(yè)務(wù)，看問題是否能解決。

第2步檢查電腦配置：PC性能比不足會導(dǎo)致窗口收縮，檢查PC性能確認(rèn)滿足配置要求、將UE PC以及服務(wù)器的防火墻關(guān)閉或者修改便攜或服務(wù)器的TCP參數(shù)。

第3步檢查各個網(wǎng)元端口協(xié)商：業(yè)務(wù)通道上的各個網(wǎng)元接口，eNodeB與傳輸設(shè)備，傳輸設(shè)備與SGW/PDN_GW、SGW/PDN-GW與Server都應(yīng)該協(xié)商為1 000 M全雙工。

第4步Wireshark抓包定位分析：A點抓包只需抓取包頭100字節(jié)即可，一般命名局點名為：_UEPC.pcap；B點抓包如果實際組網(wǎng)環(huán)境有安全網(wǎng)關(guān)的話，B點抓包考慮到要能正確解密數(shù)據(jù)，必須要將IPSEC通道設(shè)置為空加密，同時抓包時必須抓完整的包，命名局點名為：_eNB.pcap，同時因該點數(shù)據(jù)量大，為防止占用內(nèi)存過大，抓包保存時可使用多個文件，避免單個文件過大；C點抓包只需抓取包頭150字節(jié)即可，命名局點名為：_UGW.pcap；D點抓包只需抓取包頭100字節(jié)即可，命名局點名為：_Server.pcap。

5 案例

呼和浩特FHH-XX站點上下行速率異常問題定位解決過程

【現(xiàn)象描述】：對呼和浩特FHH-XX站點進行單站數(shù)傳業(yè)務(wù)驗證時，發(fā)現(xiàn)FTP上傳/下載速率均比正常值偏低，上傳峰值為2.3 Mbps左右，下載峰值為4.16 Mbps（呼和浩特目前單驗速率要求為：下載速率大于45 Mbps；上行大于6 Mbps為達(dá)標(biāo)值，統(tǒng)計時間均為30 s），據(jù)此初步判斷為可能傳輸側(cè)有問題。

【告警信息】：無

【原因分析】：根據(jù)處理流量定位問題的常規(guī)思路大體是：首先判斷該數(shù)傳業(yè)務(wù)是UDP的還是TCP的，如果當(dāng)前是TCP流量不足，則先用單線程UDP上/下行灌包“探路”，看UDP上/下行流量能否達(dá)到峰值，此步驟是為了清理通道“小石頭”；接著UDP流量問題定位采用“追根溯源”法，即從服務(wù)器到UE端到端的排查，看“水”流到哪里被“節(jié)流”了；最后如果UDP流量能夠達(dá)到峰值而TCP不行，則將問題原因鎖定TCP本身傳輸機制上。根據(jù)數(shù)據(jù)的流向，導(dǎo)致速率異常的故障原因可能包括；服務(wù)器數(shù)據(jù)源問題、PING存在時延或丟包、傳輸問題導(dǎo)致eNodeB入口流量不足、空口問題、UE PC側(cè)問題、TCP參數(shù)和傳輸機制導(dǎo)致的問題。

【處理過程】：根據(jù)原因分析后實施對問題的逐步排查：第1步服務(wù)器數(shù)據(jù)源問題排查：經(jīng)過更換數(shù)次服務(wù)器，低速率問題依然存在，至此服務(wù)器問題排除；第2步干擾問題排查：通過RSSI信令跟蹤全帶寬每個RB收到的干擾噪聲強度，發(fā)現(xiàn)在-120 dbm左右，如果大于5 db以上，證明存在上行干擾，所以干擾問題排除；第3步ping業(yè)務(wù)排查：在后臺PING測試，采用1 000字節(jié)的包，PING長度為100次，并未發(fā)現(xiàn)包存在時延抖動較大情況，而且顯示丟包率為0.00%，說明PING業(yè)務(wù)正常；第4步UDP灌包測試：在進行UDP灌包測試的同時也需要進行后臺流量監(jiān)控，發(fā)現(xiàn)下行吞吐率穩(wěn)定在60 Mbps，證明空口沒有問題；第5步上行信道質(zhì)量信息監(jiān)測：在滿足RSRP、SINR不同的條件要求下，才能保證UE獲得的速率，測試上行RSRP是-108 dbm左右，上行SINR是21 dB左右，根據(jù)測試結(jié)果正常速率應(yīng)該在8 Mbps以上，但實際上行流量僅為2.3 Mbps，說明上行業(yè)務(wù)速率受限；第6步信令分析：通過信令核查QCI等級標(biāo)識當(dāng)前為6，證明業(yè)務(wù)類型選擇當(dāng)前正常，丟包率低于百萬分之一；第7步傳輸PTN問題排查：與傳輸側(cè)相關(guān)人員核查相關(guān)參數(shù)配置后，顯示均為不限速。經(jīng)過一系列排查后問題的矛頭只能指向了傳輸環(huán)，采取切斷主隧道路由業(yè)務(wù)，倒用備用隧道路由進行業(yè)務(wù)承載，顯示上行速率穩(wěn)定在8 Mbps左右，下行速率穩(wěn)定在53 Mbps左右，至此問題得以解決，也找到了問題根源。

【案例總結(jié)】：今后單驗工作中如若出現(xiàn)速率異常等各類情況問題，可參照上述排查步驟進行處理。隨著LTE網(wǎng)絡(luò)用戶遞增的情況，因速率低而異常站點的問題可能會引起大面積用戶投訴，所以單驗過程除了處理好站點中、遠(yuǎn)速率問題以外，整個站點覆蓋區(qū)域的速率問題更需關(guān)注。

6 總結(jié)

LTE網(wǎng)絡(luò)數(shù)傳流量問題處理起來雖然比較復(fù)雜，但是按照UDP還是TCP問題兩大類來區(qū)分判斷，問題再細(xì)化后逐個排查，各個難題也將會迎刃而解。對UDP問題可通過對服務(wù)器、eNodeB入口、空口、UE和PC等采用逐點排查手法去處理，同時重點關(guān)注傳輸丟包和空口干擾問題。而TCP問題重點應(yīng)關(guān)注空口或有線傳輸通道、TCP窗口配、UE和PC性能、包和時延增加、防火墻設(shè) 等問題去分析處理。隨著LTE數(shù)據(jù)業(yè)務(wù)的“井噴”時期，業(yè)務(wù)速率問題的判斷、定位與處理工作會越來越多，但是只要找準(zhǔn)思路、方法正確，辦法總能把問題解決。