產品名稱 密級
LTE 內部公開
產品版本 共12頁

TD-LTE上行吞吐率優化指導書

擬制: 廣西LTE專項項目組 日期：
更新: 日期：
審核: 日期：
批準: 日期：

華為技術有限公司
版權所有 侵權必究

目錄
1 指標定義和調度原理 2
1.1 指標定義 2
1.2 上行調度基本過程 3
2 影響上行吞吐率的基本因素 3
2.1 系統帶寬 3
2.2 數據信道可用帶寬 3
2.3 UE能力限制 4
2.4 上行單用戶RB數分配限制 4
2.5 信道條件 4
問題的定位思路 5
2.6 上行吞吐率根因分析全貌 5
2.7 問題定位流程詳述 6
2.7.1 分配RB數少/UL Grant不足定位方法 6
2.7.2 低階MCS定位方法 7
2.7.3 IBLER高問題定位方法 7
2.7.4 覆蓋問題定位方法 8
3 典型案例 8
3.1 上行達不到峰值 8
3.1.1 問題描述 8
3.1.2 問題分析 8
3.1.3 解決措施 8

1指標定義和調度原理
1.1指標定義
吞吐率定義：單位時間內下載或者上傳的數據量。
吞吐率公式：吞吐率=∑下載上傳數據量/統計時長。
上行吞吐率主要通過如下指標衡量，不同指標的觀測方法一致，測試場景選擇和限制條件有所不同：
（1）上行單用戶峰值吞吐率：上行單用戶峰值吞吐率以近點靜止測試，進行UDP/TCP灌包，使用RLC層平均吞吐率進行評價。需要記錄下行RSRP、上行SINR、上行RLCThr、IBLER等信息。
（2）上行單用戶平均吞吐率：上行單用戶平均吞吐率以移動測試時，進行UDP/TCP灌包，使用RLC層平均吞吐率曲線（吞吐率-PL曲線）進行評價。移動區域包含近點、中點、遠點區域，移動速度最好30km/h以內。需要記錄下行RSRP、上行SINR、上行RLCThr、IBLER等信息；RLC層平均吞吐率使用各點吞吐率地理平均結果。為便于問題定位，單用戶平均吞吐率測試時，需要同時記錄probe信息，以便從地理分布上找出異常點進行問題定位。
（3）上行單用戶邊緣吞吐率：上行單用戶邊緣吞吐率是指移動測試，進行UDP/TCP灌包，對RLC吞吐率進行地理平均，以兩種定義分別記錄邊緣吞吐率。
定義1）以CDF曲線5％的點為邊緣吞吐率；?
定義2）以PL為120定義為小區邊緣，此時的吞吐率為邊緣吞吐率；此處只定義RSRP邊緣覆蓋的場景，假定此時的干擾接近白噪聲，此種場景類似于單小區測試。對于多個小區共同覆蓋的干擾高風險邊緣區域的定義，已經有運營商提出，在以后的文檔版本更新完善。
（4）上行小區峰值吞吐率：上行小區峰值吞吐率測試時，用戶均在近點，采用UDP/TCP灌包，信道質量足以達到最高階MCS，IBLER為0；通過小區級RLC平均吞吐率觀測。測試步驟如下：
a、用戶近點接入，同時開始上行灌包。
b、記錄數據，包括每UE上行SINR、IBLER、Thr和Probe信息，以及上行小區吞吐率和RB利用率。
（5）上行小區平均吞吐率：上行小區平均吞吐率測試時，用戶分布一般類似1:2:1分布，即近點1UE、中點2UE、遠點1UE，其中近點/中點/遠點定義為RSRP-85dbm/-95dbm/-105dbm。采用UDP/TCP灌包。通過小區級RLC平均吞吐率觀測；記錄包括每UE上行SINR、IBLER、Thr和Probe信息，以及上行小區吞吐率和RB利用率。
1.2上行調度基本過程

在初始接入時，UE在PUCCH發送SR（調度請求），用來請求少量數據的上行資源調度。eNB側根據實際資源情況和調度算法，給UE分配相應的上行資源，在PDCCH上下發ULGrant通知UE；在已有上行資源的情況下，UE在PUSCH發送BSR（緩沖區狀態報告）進行上行資源調度請求；eNB側在PDCCH上下發ULGrant通知UE。
2影響上行吞吐率的基本因素
2.1系統帶寬
系統的不同帶寬決定了系統的總RB數

2.2數據信道可用帶寬
公共信道的開銷進一步決定了用戶可以實際使用的資源，其中下行主要包括PDCCH和系統消息，上行主要包括PUCCH、SRS、PRACH.
2.3UE能力限制
在計算單用戶峰值時，在考慮用戶可用帶寬時，還需要考慮UE能力的限制，不同類型UE具備不同的上下行峰值速率，且只有Cat5終端才支持上行64QAM；

2.4上行單用戶RB數分配限制
在計算單用戶的上行吞吐率時，還要考慮單用戶分配的RB個數需滿足一定條件。
2.5信道條件
信道條件主要包含RSRP，AVGSINR，信道相關性等參數，這些都會對實際的信號解調性能造成影響。如果RSRP過低，則可使用的有用信號的越低；如果AVGSINR過低，則干擾信號強度較有用信號越大；而信道相關性會對RANK值計算造成影響：一般MIMO模式要求信道相關性低，而BF模式則要求信道相關性高，這些都將對解調性能造成較大影響。
3問題的定位思路
3.1上行吞吐率根因分析全貌

4.1-1 上行吞吐率低問題分析定位思路
一般而言，吞吐率由頻譜效率、頻帶寬度、頻帶占用機會、誤碼率綜合決定。在LTE系統中，頻譜效率由MCS決定，MCS由SINR和IBLER決定；頻帶寬度由分配的RB數決定；頻帶占用機會由UL grant決定；誤碼率主要考慮IBLER，HARQ重傳以后，殘留BLER通常較低，但由于重傳會影響傳輸的效率，進而影響RLC層吞吐率，因此只考慮初次傳輸的BLER，也即IBLER。
3.2問題定位流程詳述
3.2.1分配RB數少/UL Grant不足定位方法
當發現RB數較少/UL grant低時，需要進行以下的判斷動作：
?首先檢查是否為DSP能力限制；通過IFTS跟蹤觀察上行DSP能力限制的RB數。
?觀察核心網指配的QoS速率，如果偏低，則檢查核心網開戶信息是否異常；
?從L1 TTI跟蹤中統計觀察是否存在大量DTX情況，判斷方法：觀察上行DMRS RSRP，如果發現RSRP值在調度的TTI處于底噪（－120dbm）附近，或者與前后的RSRP值相差較大，則認為是上行PUSCH的DTX。對比eNB側DCI0次數，如果相差較大，則認為存在大量的DTX，需要判斷PDCCH質量問題，是否是下行PDCCH IBLER較高，導致UL Grant解錯。說明：PDCCH允許一定的誤檢率，允許1%以內；而且上行HARQ時，調度器不需要下發ULGrant。
?觀察是否數據源不足（上報BSR 對應的值），如果數據源不足，需要排查是否上層數據源異常，可能包括如下原因：（1）如果是UDP業務，檢查上行灌包（出口速率）是否超過峰值速率。（2）如果是TCP單線程業務，嘗試多個線程，如果吞吐量可以提升到峰值速率，則可以認定是PC機的TCP窗口沒有符合要求。說明：如果ULGrant個數偏小，一般是由于上述兩個原因導致。
?在性能檢測中觀察在線用戶數，看是否存在多用戶并行業務（2個以上）的情況，如果存在多用戶，則主要觀察RB利用率是否達到了100％，公平性是否得到滿足。如果RB利用率低，則需要判斷ICIC和頻選是否開關打開，是否存在問題；如果公平性得不到滿足，則可能為功控和ICIC的問題。這里的公平性指RB數公平，與算法的目標一致。
?檢查PRACH的資源配置。上行預留PRACH的時候，會對上行分配RB產生影響，對上行峰值速率產生影響，10M系統更明顯。可以將PRACH設置到PUSCH最低端，且將PRACH默認周期從5ms擴大為20ms。
?檢查PUCCH配置，當前默認配置占用8RB，在單用戶峰值測試時，可以手動改為2個RB，提高上行峰值吞吐率，再測極限峰值。
3.2.2低階MCS定位方法
MCS由幾方面決定：干擾、IBLER、UE CAT能力、是否擴展CP、下行PDCCH質量：
?在較高的上行SINR時，如果下行PDCCH質量太差，導致UL grant丟失，會導致IBLER較高；SINR調整算法模塊，依據IBLER歷史信息，對SINR測量值進行調整，輸入到MCS選擇模塊，確保IBLER收斂于目標值。也就是說在PDCCH較差的情況下，可能存在上行SINR較好而MCS較低的情況。這種情況下通過查看上行測量SINR、SINR調整量、IBLER可以進行判斷。如果某一段時間測量SINR比較高，而SINR調整量為負的較大值，而IBLER也超過門限值，則可能屬于這種情況，需要進行PDCCH質量的問題進行分析。
?空載時（UE沒有入網），打開LMT上小區性能檢測中的干擾檢測項，查看全帶寬上RSSI（第101列）是否超過正常范圍。以下為空載下，RSSI取值（底噪為-120dBm左右,全帶寬為RSSI顯示中第101列）
?BW ?RSSI
?20MHz ?-101dBm
?10MHz ?-104dbm
?5MHz ?-107dBm
如果空載下，總RSSI明顯大于上述值，需要確認是否存在干擾。可以查看不同RB上干擾狀況（一般為-120波動）。特別注意觀察中間頻段RB上的RSSI是否比其他RB上高較多（RRU或者其他設備的直流干擾會抬升RSSI）。出現這種現象時請檢查組網和UE RRU，通過掃頻確定是否有窄帶干擾，或者是UE設備異常。（說明：所謂中間頻段是只RB序號在中間的RB，如20M帶寬時，49和50RB；10M帶寬時24和25RB。）
?判斷是否由于終端能力限制，具體現象是MCS階數最大只能達到24階，這時進一步查看終端能力即可判斷。
?是否擴展CP在算法中對應了不同的MCS選擇表格，映射得到的MCS有區別，在非超遠覆蓋場景下，需保證設置為normal CP。
3.2.3IBLER高問題定位方法
查看空載RSSI是否有干擾（3.2.2所述），排除干擾問題；同時觀察UE發射功率是否為最大，如果未達到最大，則可能為UE問題。
在統計IBLER時，如果發生PDCCH質量差導致UL grant丟失，UE不發數據的情況，eNB會將該TTI作為CRC校驗錯處理，統計為誤塊，導致IBLER升高。
當發現IBLER不收斂時，如果非MCS0，則需要判斷SINR調整算法開關SW_SINR_ADJUST是否關閉，該開關關閉以后，導致MCS選擇前的SINR調整量不能依據IBLER情況及時調整，MCS無法降低導致IBLER無法收斂；如果該開關打開，則檢查調整量是否已經達到下限不能再下降從而導致MCS無法降低同時IBLER升高。
3.2.4覆蓋問題定位方法
存在上行RSRP信號較弱導致上行吞吐率低情況，可查看UE發射功率是否達到最大，如果未達到最大，則可能為UE問題。如果UE發射功率已達到最大，可從鏈路損耗、覆蓋范圍、是否存在阻擋物或弱覆蓋區域等原因進行處理。
切換異常，一般指切換到不合理小區、切換不及時、切換頻繁導致上行吞吐率低，需結合無線環境、配置參數進行處理。
4典型案例
4.1上行達不到峰值
【問題描述】：小區近點上行吞吐率無法達到峰值。
【問題分析】：上行單用戶吞吐率達到峰值必須具備以下三個條件：
?MCS選擇到最高28階，BLER為0；這就要求SINR要高于20dB。
?UE分配到最多RBNum；
?數據源充足，ULGrant個數等于每s上行的子幀個數。
因此，這個問題的定位需要從RBNum、MCS/SINR和ULGrant數目三個方面進行。
確保MCS選擇到最高階。
通過Probe查看上行MCS。Probe中的UL MCS顯示欄中務必只顯示MCS 28和MCS27，其中MCS28和MCS27的調度次數相加等于上行子幀個數表示調度數據充足，100個27階是因為發送SRS時SRS子幀碼率會增加，需要強制降階（TDD在用戶數較少的情況下，SRS在特殊子幀發數，就不會有降階的問題）。如果ULGrant個數低于上行子幀個數，請檢查數據源是否充足或者BSR上報周期是否合理（修改為5ms）。
說明：MCS由兩方面決定：SINR值和IBLER。P0決定了到達ENB的期望功率譜密度，直接影響SINR，進而影響MCS。如果上行SINR波動較大，導致有時BLER較高，SINR調整功能為保證IBLER收斂會降低MCS。
查看SINR。從MCS定標測試結果看，48RB下，MCS28階需要SINR在20dB以上。SINR低于20dB從以下幾個方面定位：
在Probe上查看UE發射功率是否達到最大23dBm。開環時，需確認P0是否配置合理值（基線偏＝－67dBm，α=0.7）。如果發射功率沒有達到最大，需要通過抬升P0抬升UE發射功率。
如果上行SINR波動較大，查看是否是TA不準導致；是否是不斷變化的干擾導致。可以將UE退網，觀察RSSI。
確保干擾 IOT在正常范圍內。
空載時（UE沒有入網），打開LMT上小區性能檢測中的干擾檢測項，查看全帶寬上RSSI（第101列）是否超過正常范圍。以下為空載下，RSSI取值（底噪為-121dBm,全帶寬為RSSI顯示中第101列）
BW RSSI
20MHz -101dBm
10MHz -104dbm
5MHz -107dBm
如果空載下，總RSSI明顯大于上述值，需要確認是否存在干擾。可以查看不同RB上干擾狀況（一般為-121波動）。特別注意觀察中間頻段RB上的RSSI是否比其他RB上高較多（RRU或者其他設備的直流干擾會抬升RSSI）。出現這種現象時請檢查組網和UE RRU，或者聯系RTT和中射頻兄弟定位。（說明：所謂中間頻段是只RB序號在中間的RB，如20M帶寬時，49和50RB；10M帶寬時24和25RB。）
確保RB數目達到最大。
查看UE分配RB數目有兩種途徑：UE側Probe查看和eNB側LMT跟蹤
?通過Probe中Bandwith項監控查看：

其中，左邊一列表示RB數目，右邊一列表示RB起始位置。如上圖
?一是LMT中RB利用率監控項，單用戶最大90RB，加上PUCCH 8個RB，應該顯示98RB；
?如果RB數目不足，可能由以下幾個原因：
?數據源不足。
?P0設置不合理。
?PRACH占用資源。
確保ULGrant充足。
可以通過查看Probe上的ULGrant個數確定。

如果ULGrant小于上行子幀總數，則說明數據量不足或者PDCCH解錯。可能由以下原因引起：
（1）如果是UDP業務，檢查上行灌包（出口速率）是否超過峰值速率。
（2）如果是TCP單線程業務，嘗試多個線程，如果吞吐量可以提升到峰值速率，則可以認定是業務電腦的TCP窗口沒有符合要求，需要按照本文前述方法修改TCP默認發送窗口太小。
說明：如果ULGrant個數不足，一般是由于上述兩個原因導致。
（3）是否是下行PDCCH BLER較高，導致UL Grant解錯。需要修改PDCCH的CCE聚合級別。
說明：PDCCH允許一定的誤碼率，默認是1%；而且上行HARQ時，調度器不需要下發ULGrant，所以在計算ULGrant個數時需要用上行子幀總數*0.9。
（4）BSR上報問題。需要將BSR周期從32ms修改為5ms。
4 通過修改PRACH位置和周期提高峰值速率。
上行預留PRACH的時候，會對上行分配RB產生影響，對上行峰值速率產生影響，10M系統更明顯。可以將PRACH設置到PUSCH最低端，且將PRACH默認周期從5ms擴大為20ms。
5 通過修改PUCCH占用RB數目提高峰值速率。

總結

以上是生活随笔為你收集整理的TD-LTE上行吞吐率优化指导书V2.0的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。