【資料名稱】：HSUPA吞吐速率優(yōu)化方法提綱

【資料作者】：未知

【資料日期】：2011

【資料語言】：中文

【資料格式】：DOC

【資料目錄和簡介】：

HSUPA吞吐速率優(yōu)化方法提綱



在HSUPA定點和DT測試中，我們有時會發(fā)現(xiàn)吞吐速率下降為0的問題。除了信令面問題以外（如一些無線掉線或由于移動導致的速率為0的AR問題等），用戶面的問題可以如下分析：

一般來說，影響HSUPA吞吐速率的主要有兩個方面：上行TBS的大小以及MAC-e重傳的比例。上行TBS的大小可以通過ETFCI來對應；MAC-e重傳比例可以通過一般的路測工具得到。
1）一般情況下，MAC-e重傳率會有一個目標值，并且通過外環(huán)功控進行保證。如果MAC-e BLER過高（如達到30%以上、甚至50%以上）的話，建議：
a)檢查UL Max SIR Target是否已經(jīng)設置到位（對于EDCH10msTTI一般建議為8.4dB，EDCH2msTTI Cat6一般建議為10.5dB，EDCH2msTTI Cat4一般建議為10.8dB）；
b)檢查EUL HARQ重傳目標值設定，注意是否由于接入的HSUPA用戶達到一定數(shù)量導致小區(qū)進入S2/S3狀態(tài)從而使用了更大的EUL HARQ重傳目標
如果確認是TBS大小變小甚至突降為0的話，可以進行下面分析：
2）ETFCI——在E-DPCCH中由UE向NodeB傳送，表示了NodeB的EDCH TBS大小，它決定了HSUPA的吞吐速率。
a)EDCH2msTTI正常的情況下，ETFCI會穩(wěn)定在96，對應EDCH2msTTI吞吐速率3Mbps以上；
b)如果看到ETFCI突然降低到20以下，甚至為0的話，說明ETFCI下降是引起吞吐速率下降得原因
引起ETFCI下降得原因主要由兩點：
a)NodeB給的資源受限；
b)UE Buffer中需要上傳的數(shù)據(jù)受限
c)UE上行功率受限
這個可以通過查看Happybit和UPH來確定。
3）Happybit——在E-DPCCH中由UE向NodeB傳送，表示了UE對NodeB給的上行資源是否滿意。
a)正常情況下，HSUPA傳送的時候Happybit=0，即永遠不滿意，說明UE Buffer中有充足的數(shù)據(jù)等待上傳，NodeB給的上行資源受限；
b)如果發(fā)現(xiàn)Happybit=1，即UE滿足于NodeB給的上行資源了，那么就說明UE的Buffer空了，這一點可以通過查看TEBS（Total EDCH Buffer Size）來發(fā)現(xiàn)
4）TEBS（Total EDCH Buffer Size）——在Scheduling Information中由UE向NodeB傳送，表示了UE Buffer中數(shù)據(jù)塊的多少
a)正常情況下，HSUPA傳送的時候TEBS=31，即有大量的數(shù)據(jù)等待傳送；
b)如果發(fā)現(xiàn)TEBS小于31，甚至為0，就說明UE的Buffer空是導致HSUPA吞吐速率突然降為0的原因。導致UE的Buffer空的原因很有可能是E2E的問題，如TCP Window Stall、RLC Window Stall等。
5）UPH（UE Power Headroom）——在Scheduling Information中由UE向NodeB傳送，表示了UE的最大可用功率于當前DPCCH功率的比值
a)正常情況下，HSUPA傳送的時候UPH=31，即UE有充足的功率滿足EDCH數(shù)據(jù)傳送的要求
b)如果發(fā)現(xiàn)UPH小于31，甚至為0，就說明UE的功率受限是導致HSUPA吞吐速率突然降為0的原因，這時我們需要去檢查上行路徑損耗為什么會那么大。
6）SG（Service Grant）——在E-RGCH和E-AGCH中由NodeB下發(fā)給UE，表示了NodeB分配給UE的上行資源
a)EDCH2msTTI正常的情況下，SG穩(wěn)定在28（對應EDCH2msTTI吞吐速率3Mbps以上）；大部分情況下，我們會看到在25~28之間（對應EDCH2msTTI吞吐速率2~3Mbps）；
b)如果發(fā)現(xiàn)SG在20以下甚至為Inactive的話，就說明NodeB沒有給UE上行資源導致了HSUPA速率降為0
造成SG突降的原因有很多，最常見的有下面幾個：
a)多用戶導致上行負荷過高，NodeB按照User Ranking來逐個降低UE的SG；
b)RTWP突然升高，“吃”掉了上行資源，導致NodeB降低UE的SG。這在室分場景中比較常見。如果是的話，可以查一下：
a)是否使用了有源的室分系統(tǒng)；
b)通過掃頻看一下是否有來自其它系統(tǒng)（如Wifi）的干擾
c)Iub傳輸問題，導致EDCH FP的De-sequence，這種情況下，NodeB會認為Iub擁塞，并通過調(diào)整GRF（Grant Reduce Factor）來下調(diào)每個UE的SG。這可以通過RNC Counter“VS.EdchIubTnlCongestIndc.FrameLoss”來確認
d)EDCH宏分集情況下，由于上下行功率不平衡，主服小區(qū)的上行并非最強，非主服小區(qū)通過Common E-RGCH Signature要求UE降SG
e)參數(shù)設置錯誤，如totalRotMax沒有設置為8等

以上所有指標都可以用Agilent工具得到，但如果你們用鼎力的話，估計有

[ 本帖最后由 onlyjim 于 2013-4-29 09:14 編輯 ]