名稱：傳輸帶寬受限導致下載速率低問題定位與解決提交人：施建勛提交日期：2014-11-17軟件版本：EMB5116_V5硬件版本：EMB5116_V5********************************************************************************************************************問題描述：葫蘆島客戶反映綜合樓附屬樓室內LTE下載速率低，綜合樓附屬樓為葫蘆島新區綜合樓附屬樓-DLW-1小區覆蓋，經現場測試，在好點（RSRP在-70dBm左右，SINR在30左右），單一用戶，下載速率在2Mbps至20幾Mbps之間，下載速率不穩定,PRB調度比較低，最高只有300左右，CQI為15，MCS正常，下行BLER正常，基站側無告警。葫蘆島新區綜合樓附屬樓下載速率低速率達不到峰值問題影響用戶體驗，需要能夠迅速定位解決。常涉及到的網元包括ENB、EPC、傳輸設備，另外還有空口質量、SIM卡設置、筆記本性能、服務器性能等影響因素，該節通過幾個簡易手段的介紹，使問題能夠快速的定位到某個網元或者某一因素。問題分析：定位思路：測試機、服務器、終端問題測試機、服務器、終端問題排查：同一終端、測試機、服務器在其它基站下速率正常。使用相同測試終端，同一FTP服務器，在綜合樓主樓-DLW-1小區測試，下載速率正常，下載速率在50Mbps左右；在卡特宏站測試，下載速率正常，下載速率保持在50Mbps左右。基站參數問題：參數一鍵恢復操作，保證參數無誤。已執行，可排除基站參數問題。打下行MAC層BO、下發PDCP真實數據排除基站以及空口問題通過打下行MAC層BO來發現下行MAC層吞吐量為50M，下行PRB100左右，下行調度800，空口環境RSRP=-70左右SINR=30CQI=15MCS等級27左右下行PDCP真實數據發現小區PDCP吞吐量為50M，空口環境同上通過以上操作排除PDCP以下都沒有丟包，丟包出現在PDCP以上有可能是傳輸側也有可能是傳輸以上側丟包。S1口抓包下圖中序號77的數據包為從服務器30發往終端52的下行GTPU包，長度為1450字節。服務器側IP為30，終端側IP為52。該抓包針對GTP類型包進行了過濾，并選擇了streamindex=2的數據包。其中序號（No）為和615和616兩行是基站側連續收到的這個stream線程的兩個GTP包，2個GTP包，此時終端發起了TCPDupACK，要求重傳包序號為44972的GTP包，參見620行，此后服務器重發了44972GTP包，參見625和626行。在此之后未再次見到序號為44972的GTP包，說明數據包確實是丟在基站外側，而非空口環節。問題處理：通過和烽火傳輸側溝通，對綜合樓附屬樓的室分站點分配了保障帶寬和峰值帶寬各100M，在現場進行單一用戶復測，下載速率正常，峰值速率在52Mbps左右。問題的產生主要是由于傳輸側帶寬受限，目前葫蘆島LTE傳輸總帶寬為1000M，大唐室分站點和卡特宏站共享，各個站點都沒有配置保障帶寬和峰值帶寬。通過對其他LTE站點測試進行下載速率比對，單一用戶測試環境下綜合樓主樓室分站點和卡特宏站均可以達到峰值，不存在傳輸帶寬受限問題。對問題站點在單一用戶環境下多次測試，下載速率表現一致，下載速率最高只能達到20M左右，最低只有幾百KB，下載速率極不穩定。需要協調烽火傳輸側對綜合樓附屬樓站點的620A傳輸設備進行問題定位，通過傳輸側手段從根本上解決傳輸受限問題。處理效果與拓展：1、在傳輸側為葫蘆島新區綜合樓附屬樓-DLW-1小區配置保障帶寬。解決下載速率低問題。下載速率恢復正