目 錄
一、吞吐量異常表現(xiàn)
1.1 吞吐量一般觀察應用層的吞吐量或者MAC層的吞吐量：
1.2 異常主要有2種表現(xiàn)：
二、吞吐量異常定位方法
2.1 吞吐量異常定位思路
2.2 調度次數(shù)不足定位方法
2.3 RB個數(shù)不足定位方法
2.4 灌包不足定位、解決方法
2.5 開戶速率和進入eNB的流量不足定位、解決方法
2.6 閉環(huán)功控，ICIC特性對RB數(shù)影響
2.7 本小區(qū)內多用戶做業(yè)務
2.8 MCS階數(shù)偏低定位、解決方法
2.9 檢測干擾
2.10 UE主分集不平衡
2.11 UE能力限制
2.12 誤碼率過高定位、解決方法
2.13 傳輸模式異常定位、解決方法
2.14 非空口問題定位、解決方法
2.15 下行吞吐量基線參考
2.16 上行吞吐量基線參考
2.17 上行吞吐量理論分析
2.18 相關工具的使用和信息獲取-UE Probe
2.19 相關工具的使用和信息獲取-eNB M2000
2.20 下行MCS階數(shù)偏低---下行SNR偏低&CRC異常
2.23 上行反饋異常
2.24 通道校正不過
2.25 BF吞吐量異常
2.26 UE側AMBR折算方法





一、吞吐量異常表現(xiàn)


1.1 吞吐量一般觀察應用層的吞吐量或者MAC層的吞吐量：


1.2 異常主要有2種表現(xiàn)：

1 吞吐量波動大（通過Netmeter等吞吐量統(tǒng)計直觀觀察）

>>存在掉坑、裂縫等異常表現(xiàn)


>>終端不動，出現(xiàn)超過50%的波動


2 吞吐量偏低

>>峰值吞吐量

>>定點吞吐量


二、吞吐量異常定位方法



2.1 吞吐量異常定位思路

步驟1：檢查基站告警及基本參數(shù)的檢查

1）當吞吐量出現(xiàn)異常時，首先需要導出基站告警日志看是否存在硬件上的故障或者S1告警及閃斷等。

2）其次進行基本參數(shù)檢查，分eNB側和終端側。

>>eNB側主要和基線參數(shù)進行核對，商用網絡如果出現(xiàn)參數(shù)和基線參數(shù)不一致的情況，需要查清為什么會出現(xiàn)該種情況；

>>終端側參數(shù)檢查：主要是PC窗口的大小，會影響TCP業(yè)務；


步驟2：空口/非空口問題隔離定位


1）判斷是否是TCP問題

>>最簡單的方法－UDP灌包

>>嘗試多線程下載或同時下載多個文件

(1)若吞吐率明顯要大于TCP業(yè)務吞吐率，則判斷為TCP問題，進入TCP問題排查；

(2)若吞吐率與TCP業(yè)務基本持平，或者比TCP還低，則進入空口問題排查；



步驟3：空口問題定位、解決方法

1）當出現(xiàn)吞吐量異常，且基本確定為空口問題時，主要從下面幾個方面進行分析定位，其中調度次數(shù)不足和調度RB不足可以合并定位，定位順序從左至右。


2.2 調度次數(shù)不足定位方法


如何判斷調度次數(shù)過低

>>通過終端監(jiān)測工作獲得（1s統(tǒng)計一次）

>>通過eNB的監(jiān)測工具獲得（1s統(tǒng)計一次）

單用戶場景用戶調度次數(shù)取決于TDD上下行配比，可以直接觀察Probe顯示的DL Grant Count/ UL Grant Count ；


下行當觀察到的總量持續(xù)<用戶調度次數(shù)*5%，認為下行調度次數(shù)不足；

上行因為HARQ時，調度器不需要下發(fā)ULGrant，所以一般ULGrant在理論總數(shù)的90%以上都是正常的；

多用戶場景如果默認頻分調度且UE能力不受限，此時每個TTI只調度1個用戶，此時用戶調度次數(shù)= Grant Num/小區(qū)用戶數(shù)，其中Grant Num與單用戶時相同，取決于TDD上下行配比。





2.3 RB個數(shù)不足定位方法


如何判斷RB個數(shù)過小

上行在閉環(huán)功控的條件下，在路損超過120dB~125dB的條件下上行開始縮小調度的RB個數(shù)，此時MCS階數(shù)大概在3~5階左右，在路損小于120dB情況下，幾乎都應該以滿RB調度；


下行幾乎都應該是滿RB調度；

上圖為終端Probe顯示的結果，RB數(shù)=Total Code0RBCount/Code0Count



上圖為M2000中的RB數(shù)觀察方法，RB利用率跟蹤項中的等效RB使用數(shù)


2.4 灌包不足定位、解決方法

如果DL/UL Grant個數(shù)小于理論總數(shù)的60% ，一般是由于灌包不足引起的，這種情況在大帶寬峰值測試下特別常見。

解決方法：使用多線程灌包或者更換性能更好的便攜。

灌包命令如下：

Iperf –c xx.xx.xx.xx –u –b 100M –t 99999 –i 1 –P 2

xx.xx.xx.xx表示目的IP，根據(jù)實際情況輸入。P表示線程數(shù)，注意，要大寫。

2.5 開戶速率和進入eNB的流量不足定位、解決方法

1 檢查開戶速率，看是否是由開戶速率過低造成吞吐率問題，開戶速率至少要超過期望速率。如下圖所示，該圖表示上下行開戶速率都為20k，開戶速率顯然太小，不能滿足LTE要求。在UE側也可以觀察。





2 其次下行需要查看從S1口過來的入口數(shù)據(jù)是否充足：


這個例子是一個下行灌包50M的例子，看紅色框里面的數(shù)值“6199732字節(jié)/秒”換算成M就是6199732*8/1000/1000 = 49.597856M。實際上這個流量就是我們收到的，從核心網到GE口的流量。這個能夠證明流量是否足夠。



2.6 閉環(huán)功控，ICIC特性對RB數(shù)影響

1 上行閉環(huán)功控

>>如果不生效，中遠點速率較低，RB個數(shù)遠低于閉環(huán)理論值，但是近點能達到峰值；

>>比如：在RSRP=-100dBm的時候，如果閉環(huán)功控在起作用，對于20M帶寬，有近90個RB；對于10M帶寬，有40個RB左右。與之相比，開環(huán)功控最多只有10個左右。

>>對于我司UE，打開Probe的Power Control，其中SumFiValue不等于-1即為閉環(huán)。

2 ICIC

>>上下行都有ICIC開關，首先確認開發(fā)是否打開，然后在信令中搜索包含MeasurementConfig 的RRC ConndectionReconfiguration消息，如果消息中的reportOnLeave字段取值為True，表明觸發(fā)了ICIC A3測量。


2.7 本小區(qū)內多用戶做業(yè)務



如果本小區(qū)存在其他用戶在做業(yè)務的時候，觀測單UE的RB將會減小，因此在測試之前應該先檢查小區(qū)內是否存在其他用戶，測試過程中也應該注意是否有其他用戶接入。下面為只有一個用戶時的顯示結果：


2.8 MCS階數(shù)偏低定位、解決方法


如何判斷MCS階數(shù)過低

>>MCS階數(shù)是否合理在拉距的條件下較難判斷。

>>上行在路損超過120dB~125dB縮RB的時候一般維持3~5階數(shù)，但是隨著RB不能再縮小，其MCS階數(shù)也會降低。比較方便的方法是排除法：在UE以滿功率（23dBm）發(fā)送的條件下，如果調度次數(shù)和RB個數(shù)都比較正常但總吞吐率偏低，那么可以認為問題出在MCS階數(shù)上。

>>下行均衡后SNR偏低，導致下行吞吐量偏低。

>>下行CRC異常，導致AMC將下行階數(shù)調整下來。

>>上行反饋異常，導致AMC的異常調整，導致下行階數(shù)偏低。


2.9 檢測干擾


1 上行干擾可以在M2000上觀測判斷：

>>UE未接入情況下（所有UE關機，小區(qū)里沒有業(yè)務），打開M2000的“小區(qū)性能檢測”，選擇“干擾檢測”，查看RSSI值，在沒有干擾的時候，約等于－119＋10log(RB個數(shù))，在內場差距1dB以上，在外場差距在3dB以上即認為存在干擾，需要檢查干擾。干擾一般來自鄰區(qū)或者是異系統(tǒng)干擾（比如2G或3G系統(tǒng)）

2 下行干擾可以在UE側Probe上觀測判斷：

>>在Detected Cell中看是否有多個小區(qū)，且超過1個小區(qū)的RSRP和本小區(qū)的RSRP差在3dB之內。如果是，則表明存在較強的鄰區(qū)干擾。

>>在檢測到的鄰區(qū)當中，不能出現(xiàn)和本小區(qū)PCI相同的鄰區(qū)。

>>查看下行各子帶CQI是否有某一段CQI的值特別低的，如果存在，說明存在較嚴重的窄帶干擾。

3 解決方法：

>>較強的鄰區(qū)干擾只有通過調整天線方向角等來解決。

>>嚴重的窄帶干擾通過掃頻，找出干擾源，進行排除。






2.10 UE主分集不平衡

主分集不平衡，會嚴重影響我們的測試結果，如下為一次測試數(shù)據(jù)的結果：由于主集（Antenna0）比分集（Antenna1）小了近5dB，在顯示RSRP的時候顯示的是最強信號的RSRP,但是UE發(fā)送信息是從主集發(fā)送的，算路損的時候也是以主集為主。這樣實際上行的信道質量就比顯示的RSRP小很多�？梢酝ㄟ^2個辦法解決該問題：

>>在測試有外置天線的時候擺弄主分集天線，在測試內置天線UE的時候可以改變UE位置使其主分集相對平衡，

>>吞吐率曲線不用RSRP，改用路損VS吞吐率


2.11 UE能力限制

1 UE能力查看方法：在UU口跟蹤消息”RRC_UE_CAP_INFO”里查找。我司UE可以從OMT查詢得到。目前市場上一般的商用終端為CAT3 UE；

2 對于上行來說，CAT 5 UE 最高能達到28階，CAT 3和CAT 4 UE只能達到24階。




2.12 誤碼率過高定位、解決方法

峰值場景不能收斂到0%，非峰值場景下行BLER持續(xù)高于15%；如果存在MCS階數(shù)為0的時候，誤碼率較高也可以認為是正�，F(xiàn)象。


2.13 傳輸模式異常定位、解決方法

傳輸模式主要是針對下行：


>>初始接入是TM2模式，之后根據(jù)信道環(huán)境切換到TM3或者TM7，當出現(xiàn)終端失步、切換、重建時，會重新進入TM2模式。MIMO模式從空口消息進行觀察，如圖：


>>下行MIMO模式異常，主要體現(xiàn)在UE上報的Rank是否合理及上報反饋是否存在異常。正常情況，收發(fā)相關性小于0.5 AvgSNR大于15dB時，系統(tǒng)可以使用雙碼字。如果沒有使用，需要查看UE上報的Rank及eNB收到的Rank，并采集相關數(shù)據(jù)反饋分析。




2.14 非空口問題定位、解決方法

1 檢查TCP參數(shù)

>>操作系統(tǒng)：如果是Windows XP則繼續(xù)，如果是Vista、Win7或其它操作系統(tǒng)，則跳過本步驟；

>>查看/設置TCP參數(shù)

(1) 在發(fā)送方和接收方都通過DrTCP工具，在Adapter Settings中找到對應網卡，按如下設置：



(2) 在發(fā)送方再利用工具TCP parameter setting.reg進行修改，雙擊導入；

(3) 以上兩步操作完后再統(tǒng)一正常重啟電腦，這樣配置才能生效。如果服務器側無法修改，則只修改UE PC。

>>如果修改了TCP參數(shù)問題依舊，則繼續(xù)下一步的判斷



2用TTI跟蹤TCP問題定位模塊進行分析

>>如何進行TTI跟蹤？

(1)首先要確保TCP鏈接所使用的端口號已經加到算法模塊的白表中(默認已經添加FTP數(shù)據(jù)鏈端口20，iperf則需要手動添加5001端口)。

(2)使用LST TPEALGO:;檢查端口號，使用MOD TPEALGO:;添加對應端口號。

(3)然后可以啟動TTI跟蹤了，登陸M2000，依次選擇菜單Monitor -> Signaling Trace -> Signaling Trace Management 打開信令跟蹤頁面，選擇Information Collection -> IFTS Trace 啟動IFTS跟蹤。按照提示填寫相應信息，一定要勾選L2 Performance，并在MAC Layer Trace Field中填寫132，此為TCP問題定位模塊的ID號，點擊Finish啟動跟蹤即可。

注意：順序是，啟動TTI跟蹤后，再重新接入UE，再進行TCP業(yè)務。

>>跟蹤數(shù)據(jù)如何解析，解析結果如何看？

使用LAE解析IFTS跟蹤文件，解析和分析方法參加文檔LAE案例(TCP)。

>>若按推薦操作仍舊沒能解決問題，則抓取數(shù)據(jù)反饋回廠家。


3 TTI數(shù)據(jù)的常見解析結果：

>>CRC_ERR: 數(shù)據(jù)包有CRC錯，若出現(xiàn)在Server->eNB PDCP之間，則核心網或S1的傳輸設備有較大概率出現(xiàn)硬件故障，建議檢查S1的各傳輸設備是否有告警；若出現(xiàn)在UE->eNB PDCP之間，則可能是UE硬件故障，嘗試更換UE；

>>WIN_SHRINK：接收窗口收縮，若頻繁出現(xiàn)該事件，或者對應的通告窗口為0，則表示接收方的電腦硬件性能不行，數(shù)據(jù)包無法從TCP層往應用層遞交，建議更換接收方的電腦；

>>RSV_DUPACK：收到重復ACK，一般在丟包或者亂序的場景才會觸發(fā)；當重復ACK數(shù)在10以下則一般為是亂序，而大于10則一般為丟包；根據(jù)異常位置的判斷，去檢查相應位置的設備或傳輸；

>>LINK_TIMEROUT：數(shù)傳中斷時間超過500ms，查看當前包方向，如為下行，則表示問題出現(xiàn)在下行，在500ms內沒有收到下行的任何數(shù)據(jù)包和ACK；上行也是一樣；

>>PACKET_DISORDER：數(shù)據(jù)包亂序，查看出現(xiàn)異常的位置，檢查相應位置的設備和傳輸；



2.15下行吞吐量基線參考

1 下行MIMO 2port場景理論峰值基線：


24T4R(2Port,PSD)，BW=20MHz，SA2，SSP7，Cat5終端(TUE)，TM2/3/7自適應，CFI=3：






2.16 上行吞吐量基線參考



單用戶上行理論峰值吞吐率基線


20M帶寬下，單用戶上行吞吐率參考曲線（配比二、4T單用戶最大50RB）


2.17 上行吞吐量理論分析


1. 上行單用戶峰值吞吐率:必須同時具備以下四個條件：

1）對于CAT5 UE MCS選擇到最高28階，對于CAT4 和CAT3 UE MCS選擇到最高24階，有部分為23階（協(xié)議最大TBS限制導致降階）。


2）UE分配到最多RB個數(shù)（單用戶最大可用RB個數(shù)＝總的RB個數(shù)－PUCCH RB個數(shù)，實際調度RB數(shù)還要滿足235法則。235法則指的是：單用戶PUSCH調度RB個數(shù)必須是2，3，5的倍數(shù)）。


注：上表是在PDCCH符號數(shù)固定為3的前提下給出，4T和8T場景下，目前版本需考慮單用戶最大RB產品能力限制，4T最大50RB、8T最大36RB：

3）上行調度次數(shù)充足，ULGrant次數(shù)在不同配比情況按下表：



4）IBLER少于1%.

2. 上行定點吞吐率偏低

與峰值吞吐率類似，上行定點吞吐率偏低的定位也需要從RB數(shù)目、MCS階數(shù)、上行調度次數(shù)和誤碼率四個方面進行。

2.18 相關工具的使用和信息獲取-UE Probe




2.19 相關工具的使用和信息獲取-eNB M2000



在M2000里面點監(jiān)測：

”小區(qū)性能監(jiān)測”：查看RB利用率，總吞吐率，小區(qū)干擾監(jiān)測，用戶數(shù)；

“用戶性能監(jiān)測”：查看Power Headroom，信道質量，吞吐率，MCS階數(shù)統(tǒng)計，誤碼率；


2.20 下行MCS階數(shù)偏低---下行SNR偏低&CRC異常(1)

下行SNR偏低&CRC異常主要由下面5點導致，排查順序從左至右。


2.21 下行MCS階數(shù)偏低---下行SNR偏低&CRC異常(2)

下行相關性高



觀察：

RxChCorFactor和TxChCorFactor兩個值均大于0.5，則表明收發(fā)相關性較高，越接近1，相關性越高，解調性能越差。

解決方法：

實驗室：

（1）修改組網，使得主分集分路進行連接。

（2）VAM的內部連接也需要采用分路的方法進行。

（3）排查實驗室干擾，當干擾大于信號時，會出現(xiàn)兩路信號的相關性較大的情況。

外場：

（1）直達徑場景，一般相關性較高，避免直達徑的地方。

（2）外置天線可以拉大天線間距或使其兩天線垂直擺放。


2.22 下行MCS階數(shù)偏低---下行SNR偏低&CRC異常(3)


RRU相關信號處理出現(xiàn)異常


（1）RRU的通道不平衡會導致終端的解調能力下降，導致MCS偏低，可以通過下面的方法來觀察。


觀察兩天線接收的RSRP差，當兩根天線差值持續(xù)在5dB以上時，認為通道不平衡，需要通過調整終端天線來解決。


（2）終端入口功率一般在-50dBm~-90dBm，如果入口功率超過-50dBm容易導致削波，使得下行SNR偏低；如果入口功率低于-90dBm，也會使得下行SNR偏低，影響下行性能�？赏ㄟ^Probe顯示的RRU Measurement觀察終端接收的功率。


該問題在實驗室，通過調整中間的路損來解決。

在外場，通過調整站間距和基站的功率配比來解決，但此問題需反饋回總部相關人員進行分析和優(yōu)化。

（3）RRU的發(fā)射時延不一致，頻譜泄露，本振泄露及RRU內部模塊存在問題，需要通過采集基帶數(shù)據(jù)，發(fā)回廠家進行分析，具體采數(shù)方法見后。


2.23 上行反饋異常


1. 如果通過前面幾點的排查，發(fā)現(xiàn)下行調度次數(shù)，調度RB數(shù)，MIMO模式均沒有問題，且BLER收斂也正常，調度MCS也調度在正常范圍。但是下行流量仍出現(xiàn)異常，如下所示：

2. 此種情況，基本可判定為反饋通道出現(xiàn)了問題，即將ACK/NACK錯解成了NACK/ACK/DTX。反饋通道的問題，即數(shù)據(jù)采集可以參考上行PUCCH和PUSCH的問題定位進行處理。


2.24 通道校正不過

1.通道校正不過，傳輸模式就不會切換到TM7或TM8；

>>通道校正指示CEI=False時要排查是發(fā)通道校正不過還是收通道校正不過，可通過在M2000上MML命令導出DBG日志log，利用InsightSharp查看通道校正指示和收、發(fā)通道校正的CINR。

2.解決方法

>>如果收發(fā)通道校正中固定為某一個天線端口的CINR低于門限值，則很有可能是該天線通道口損壞；

>>如果發(fā)通道校正通過，而收通道校正不過，則很有可能是外部干擾導致的；

>>RRU入口和出口功率是否平衡：

a.基帶到RRU的入口功率查詢（在[DigitPwr Info]里查看TxComB ）： boardEnvShow

b.RRU出口功率查詢： bdrfpmPrintRfStatus（查看對應使用的物理天線端口的HPA Power)

>>準確定位方法是通過在eNB基帶采集DSP空口數(shù)據(jù)進行定位；


2.25 BF吞吐量異常


檢查DRS SINR是否偏低，SRS配置是否正常，相關性測量；

>>SRS配置可以通過Probe中跟蹤“RRC Parameters”查看獲取SRS帶寬、周期等信息；

>>相關性測量部分，UE側通過Probe查看收發(fā)相關性；


>>需要采集數(shù)據(jù)時可通過M2000的IFTS跟蹤，MAC布控33/40/49/55/67/224/160/43。



2.26 UE側AMBR折算方法


LTE協(xié)議對APN-AMBR在空口下發(fā)的轉換，取消了十進制轉換，引入了2個8bit擴展位，并且對于不同區(qū)間的速率值使用不同的換算公式。協(xié)議對于AMBR換算描述如下：


本文以下行的octet3，octet5，octet7為例，上行與下行轉換方法一致。

AMBR轉換遵從以下準則：

1. octet5為0且octet7為0，直接參考octet3的值，轉換公式見表2

2. octet7為0，octet5不為0，直接參考octet5最終轉換值，轉換公式見表2


3. octet7不為0，直接參考octet7的值，轉換公式見表2

表2