1 前言

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

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

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

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

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

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

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

2.2.1 LTE吞吐率正常與異常對(duì)比

理想情況下UE下行峰值吞吐量如圖2所示，TCP流量異?！奥榔隆奔啊暗艨印爆F(xiàn)象如圖3所示。

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

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

2.3 吞吐率問(wèn)題總體定位思路及步驟

2.3.1 吞吐率問(wèn)題判斷總體思路

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

2.3.2 吞吐率問(wèn)題判斷通用步驟詳解

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

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

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

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

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

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

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

② 第2步采用最簡(jiǎn)單的方法-UDP灌包來(lái)判定是否為UDP類問(wèn)題，操作過(guò)程與判斷方法如下：

【操作方法】采用iperf網(wǎng)絡(luò)流量的檢測(cè)工具，將iperf.exe分別放置在服務(wù)器的UE/PC的C盤根目錄下，然后打開(kāi)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還低，則進(jìn)入U(xiǎn)DP類問(wèn)題定位；若吞吐率明顯大于TCP業(yè)務(wù)，則進(jìn)入TCP類問(wèn)題定位。

③ 第3步判斷是否為TCP類問(wèn)題的具體操作過(guò)程與判斷方法如下：

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

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

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

3 UDP流量問(wèn)題定位

3.1 UDP流量問(wèn)題定位總思路

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

圖4 追根溯源法逐點(diǎn)排查圖

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

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

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

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

3.1.2 eNodeB入口流量不足問(wèn)題定位

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

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

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

3.1.3 空口問(wèn)題定位

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

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

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

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

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

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

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

3.1.4 UE無(wú)法數(shù)傳問(wèn)題定位

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

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

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

4 TCP流量問(wèn)題定位

4.1 TCP吞吐率影響因素

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

4.2 TCP流量問(wèn)題定位思路

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

4.3 TCP速率波動(dòng)大的原因分析

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

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

4.3.1 TCP速率波動(dòng)大原因分析檢查步驟

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

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

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

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

5 案例

呼和浩特FHH-XX站點(diǎn)上下行速率異常問(wèn)題定位解決過(guò)程

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

【告警信息】：無(wú)

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

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

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

6 總結(jié)

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