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

【資料作者】：未知

【資料日期】：2011

【資料語(yǔ)言】：中文

【資料格式】：DOC

【資料目錄和簡(jiǎn)介】：

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



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

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

以上所有指標(biāo)都可以用Agilent工具得到，但如果你們用鼎力的話，估計(jì)有

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