分享：LTE最新案例集（上）

案例一：分佈問題導致下行呑吐率不達標問題

【故障類別】：分佈系統

【現象描述】：寬窄巷子星巴克咖啡室分基站開通后，我們用B593S終端進行現場測試發現在RSRP和SINR極好的情況下下行吞吐率無法達到測試標準，查看基站配置為雙流模式基站，下行呑吐率標準為50M以上，現場測試最高速率只能達到47M，具體情況如下：

下行呑吐率數據

【原因分析】：

1、通過測試數據分析發現該基站為雙通道配置，兩個通道口0和1在輸出功率最大時相差32dBm,懷疑為雙通道輸出功率不一致導致下行速率無法達標，如下圖所示：

可以看到兩個通道的輸出功率相差較大

【處理過程】：

1、而後後台配合我們將兩個通道分別單開，測試其下行速率，如圖：

通道口0

從上圖可以看出通道口0由於輸出功率低導致RSRP<-100,下載速率平均只有36M;

通道口1

從上圖可以看出通道口1輸出功率正常，下載速率穩定在46M以上，以此確定該站的通道0輸出功率問題導致下行呑吐率無法達標.

【建議與總結】：

該問題后經協商後由雙通路改為單通路，並將通道0關閉處理，複測結果如下：

下圖可以看出改為單流後下行呑吐率達到測試要求，下載速率穩定在46M以上.

案例二：基站熱點區域異頻優化案例

【故障類別】：參數類

【現象描述】：

高升橋室分站點熱點區域優化，在對覆蓋進行步測中發現，6F主要為2小區覆蓋但受到3小區干擾下載速率不穩定；4\5F主要為3小區覆蓋但受到1小區干擾下載速率不穩定；為此，將3小區頻點由39050調整為39250（同1小區、2小區異頻），調整后發現在原有的1、3小區切換點位置無法正常進行切換。

高升橋基站覆蓋分布圖：

5F同頻切換點如圖（中間電梯間仍然為1小區覆蓋）：

【原因分析】：

通過分析，3小區調整為異頻頻點后同1小區發生的為異頻切換，切換類型應為基於A4的切換，然在鄰區列表中都一直無法檢測異頻鄰區（後台已做異頻鄰區切換參數數據配置），進一步確定可能原因出現在終端未上報異頻鄰區測量，並觀察信令及事件窗口，無A2事件相關消息。

由此，通知後台檢測異頻切換相關參數配置A2\A1\A4門限，發現後台配置均為默認值，均低於-100以下，門限設置過低，現場無法達到該門限值。

【處理過程】：

結合同頻切換，在切換時，RSRP在-90dBm以上以及樓層覆蓋情況，通知後台將A1停止異頻測量門限配置為-75dBm，A2啟動異頻測量門限配置為-85dBm，A4異頻切換門限配置為-90dBm后，異頻切換正常，如下：

1、3小區間異頻切換正常，同時由於進行異頻的調整，該區域下載速率得到較大提升，達到預期優化效果。

【建議與總結】：在進行異頻組網時，注意異頻切換的相關參數配置。

案例三：合路接入TD分佈系統故障導致下載速率不達標問題

【故障類別】：設備類

【現象描述】：

武侯辦公區室分基站開通后，該基站為單小區配置基站，並下掛2個RRU，通過現場對2個RRU進行測試發現RRU1\RRU2的RSRP以及SINR都比較好，但是RRU2在測試過程中的Transmision Mode為TM2，Rank lndicator為Rank1，具體情況如下：

RRU1 Radio Paramrters

RRU1 RSRP走勢圖

RRU1 SINR走勢圖

RRU1下行吞吐率走勢圖

RRU2 Radio Paramrters

RRU2 RSRP走勢圖

RRU2 SINR走勢圖

RRU2下行吞吐率走勢圖

【原因分析】：

1、經過聯繫後台核查該小區下得2個RRU後台數據均配置的為雙發雙收；

2、核查工程安裝圖紙RRU1為獨立的雙通道配置、RRU2其中一路為獨立的通道配置，另一路為與TD進行合路配置；

【處理過程】：

1、經過工程安裝人員進行檢查發現在耦合器與TD合路的介面未連接：

2、與工程安裝人員取得聯繫了解該基站的安裝情況得知由於在安裝過程中工程隊未找到設計圖紙中的TD天線，因此RRU2隻安裝了一路天線，通過這一情況可以將問題定位為RRU2由於天線安裝為單通道導致該RRU接收的為Rank1單流；

3、由於現場安裝與設計不符合，因此告知安裝人員對該RRU進行整改

4、通過安裝人員整改后的複測觀察，經過整改RRU2的Rank lndicator模式由Rank1變為Rank2，下載速率有了明顯的提升，具體對比如下：

RRU2整改前Radio Paramrters

RRU2整改后Radio Paramrters

RRU2整改前下行吞吐率走勢圖

RRU2整改後下行吞吐率走勢圖

【 建議與總結】：

1、在工程安裝過程中需要嚴格按照設計方案進行施工，如果再施工工程中由於其他因素導致無法按照設計方案完成需要及時反饋。

2、在進行室內分佈系統測試過程中如果發現規劃數據為雙發雙收，而實際測試為單發單收的情況，首先需要核查後台數據是否正常，在確保後台數據正常的情況下其次查看RB調用次數以及MCS調度階數是否正常，如果未出現異常，那麼問題就出現RRU至天線一側，需要安裝人員配合進行檢查。

案例四：下行呑吐率「掉坑「毛刺問題

【故障類別】：傳輸

【現象描述】：

在CD LTE站點「CD分公司」單驗過程中，該站5個RRU覆蓋的平層，上行數據業務平穩正常，但下行數據業務速率呈現嚴重的「掉坑」毛刺問題，如例圖：

對CD分公司的5個RRU覆蓋平層進行測試，統計結果如下表：

【告警信息】：

框號為200的RRU的兩個PATH存在1.5/1.6的駐波比

【原因分析】：

一、首先問題排查：

告警檢查：

1. 檢查eNodeB有無告警

2. 檢查傳輸、CN有無告警

小區檢查：

1. 檢查待測試小區是否激活，確認小區狀態

2. 檢查基站標識、小區PCI是否正確，是否與工參一致

3. 檢查小區天線權值是否配置，確認配置正確

4. 檢查小區功率配置參數，確認是否因為特殊原因修改為低功率

傳輸檢查：PING包，測試傳輸是否正常

終端檢查：檢查電腦是否已經進行了TCP窗口優化

二、空口無線質量：

（1）、下行SINR是否偏低：

1. 確認小區天線權值配置正確

2. 如果是外置天線，嘗試拉大天線間距或更改兩天線擺放位置

3. 更換測試地點

4. 排查干擾

（2）、下行MIMO模式是否正常：

1. 檢查終端是否工作在TM3，RANK2

2. 檢查基站license信息是否支持2x2 MIMO

3. 檢查MIMO配置

4. 檢查終端是否上報RANK2

5. 嘗試固定TM3

（3）、下行調度次數是否足夠：

1. 檢查調度次數，是否滿調度

2. 檢查小區內是否單用戶

3. 檢查S1入口數據是否充足，是否上層給水量問題

4. 檢查用戶配置的AMBR和GBR是否大於空口速率

5. 檢查DRX開關是否關閉

（4）、下行調度RB數是否足夠：

1. 檢查RB數是否足夠

2. 檢查頻選調度是否關閉

3. 檢查下行ICIC是否關閉

4. 檢查Pa，Pb設置

（5）、查看下行MCS/BLER：

檢查下行MCS是否高階，下行BLER是否較小

（6）、查看空口信令：

檢查空口信令是否有異常

三、判斷是否為TCP問題

（1）、嘗試UDP灌包

1. 如果無法UDP灌包，嘗試多線程下載

2. 如果灌包或多線程下載時，流量明顯高於TCP業務，進行TCP問題排查

3. 記錄基站接收流量

【處理過程】：

對於以上下行呑吐率「掉坑、毛刺」問題，根據上述的原因分析步驟進行逐步核查：

1、告警核查：通過核查eNodeB、傳輸、CN告警信息，只有eNodeB側存在駐波告警（框號為200的RRU的兩個PATH存在1.5/1.6的駐波比），通過協調工程人員進行處理該RRU駐波比告警駐波（RRU型號為RRU3152e）：

通過對其中2樓天饋分佈系統進行排查，框號為200的RRU的駐波比消除：1.3/1.1；駐波告警處理好之後，下行業務依然存在「掉坑」毛刺問題。

2、小區檢查（子幀配置：1/7配比）、終端檢查、空口無線質量檢查，根據上述分析步驟逐步核查，通過網管（LMT）進行上行干擾檢測以及無線空口質量排查，進行定點CQT測試，問題依然存在。

3、通過2副小天線分別接到RRU通道口進行驗證測試，通過排除室分分佈系統的問題，但通過現場選擇好點（RSRP：-72.17dBm、RSRQ：35.63dB）測試驗證，問題依然存在：

4、PING包，測試傳輸是否正常：

進行ping的命令操作（PING: SN=6, SRCIP="192.168.200.12", DSTIP="10.254.254.64", PKTSIZE=1460, CONTPING=DISABLE, TIMEOUT=5000, NUM=50, DSCP=18, APPTIF=NO;）

（1）未做業務測試時，ping操作（3次ping操作，每次ping「1460」數據包50次），無「 Request time out」問題現象；

（2）做業務測試時，ping操作（8次ping操作，每次ping「1460」數據包50次），無「 Request time out」問題現象。

5、判斷是否為TCP問題，通過嘗試UDP灌包

通過工具Wireshark抓包，文件處理，保存所需數據，打開數據，設置Wireshark，查看抓包統計，流量分析，查看專家信息，tcptrace圖分析（發送窗口，接收窗口，RTT，重傳等）

（1）使用Wireshark抓包（抓包操作步驟不詳細闡述）

（2）對抓包文件進行處理，過濾TCP連接，保存所需數據

（3）重新打開保存后的文件，對Wireshark進行設置

（4）查看抓包統計

使用tcptrace圖進行分析：正常情況下，如果TCP速率穩定，那麼在TCP時序圖上看到的將是一條筆直上升的斜線，它的斜率等於速率。tcptrace圖中，中間黑色的粗線代表了發送的包，下方淺色的線代表上一個ACK確認的包序號，上方淺色的線代表TCP接收窗口，等於上一個TCP ACK序號加上win：

分析線段斜率發生變化的地方

觀察線段是否有中斷、重複、離散點等情況。直接點擊tcptrace圖中出問題的點在Wireshark包列表區中會直接跳轉到對應的包。如下圖，遠離黑色線段主體的一小段黑色線段是重傳包：

如下圖，從圖中可以看出，紅色圈中的線段比較平，有較多的重傳，需要點擊進入Wireshark包列表區中分析重傳的原因：

如果是重傳很少或者沒有重傳，需要對發送和接收窗口進行分析。

通過對CD分公司LTE基站進行抓包分析，服務側進行灌包測試：

伺服器：iperf -c 10.255.255.14 -u -b 70M -i 1 -t 99999 -p 5012 -M 800B 備註：-M ：800、1000、1500

終端側：iperf -s -u -i 1 -t 999 -p 5012

通過對該基站的抓包數據進行分析，FTP伺服器到客戶端存在丟包以及重傳問題，導致速率波動及「掉坑」毛刺問題。

根據上述的分析排查，確定傳輸側存在問題，協調傳輸側進行相應的參數設置核查，經過傳輸側核查分析結果：由於該LTE基站（成都分公司）PTN傳輸到核心機房較遠且有2個PTN設備銜接而成，同時，在傳輸側也存在一個傳輸帶寬的限制（200M帶寬限制）

一、通過傳輸側進行修改測試驗證：

（1）將PTN傳輸帶寬不作限制，測試情況：

（2）傳輸側進行帶寬（900M、500M、300M）限制，測試情況如下圖：

結論：對傳輸側進行帶寬限制后，為300M帶寬時，下載速率存在嚴重的「毛刺」問題。

二、通過對傳輸側帶寬不作限制之後，測試效果達到（子幀配比：1/7的下載及上傳速率要求且比較穩定）要求，但是通過對LTE的帶寬需求分析，100M的足以滿足需求，為何200M的帶寬限制之後卻會導致上述問題？

通過傳輸側分析及最終的解決方案制定，通過在傳輸側進行設置一定的緩存區：

（1）、傳輸側對設置一定的緩存區（X值，X值設置傳輸同事未知會）、傳輸帶寬設置為200M帶寬限制（SINR：32.49dB；RSRP：-75dBm；PDCP Throughput DL：51.245 mbps）下載測試情況，如圖（毛刺）：

（2）、傳輸側對設置一定的緩存區（Y值，Y值設置傳輸同事未知會）、傳輸帶寬設置為200M帶寬限制（SINR：33.86 dB；RSRP：-77.01dBm；PDCP Throughput DL：58.428mbps）下載測試情況，如圖（平穩）：

通過與傳輸側協商，最終解決方案為設置一定的緩存區（Y值，Y值設置傳輸同事未知會），通過現場測試，效果達到預期測試標準，該下行下載業務的「掉坑」毛刺問題得到解決。

【建議與總結】：

對於一個問題的解決，需要協同產品、優化、傳輸、核心網等方面一起協同解決。

獲取更多集群通信領域資訊、方案、知識，請搜索中國集群通信網公眾號（PttCn），添加並關注中國集群通信網。