【资料名称】：HSUPA吞吐速率优化方法提纲

【资料作者】：未知

【资料日期】：2011

【资料语言】：中文

【资料格式】：DOC

【资料目录和简介】：

HSUPA吞吐速率优化方法提纲



在HSUPA定点和DT测试中，我们有时会发现吞吐速率下降为0的问题。除了信令面问题以外（如一些无线掉线或由于移动导致的速率为0的AR问题等），用户面的问题可以如下分析：

一般来说，影响HSUPA吞吐速率的主要有两个方面：上行TBS的大小以及MAC-e重传的比例。上行TBS的大小可以通过ETFCI来对应；MAC-e重传比例可以通过一般的路测工具得到。
1）一般情况下，MAC-e重传率会有一个目标值，并且通过外环功控进行保证。如果MAC-e BLER过高（如达到30%以上、甚至50%以上）的话，建议：
a)检查UL Max SIR Target是否已经设置到位（对于EDCH10msTTI一般建议为8.4dB，EDCH2msTTI Cat6一般建议为10.5dB，EDCH2msTTI Cat4一般建议为10.8dB）；
b)检查EUL HARQ重传目标值设定，注意是否由于接入的HSUPA用户达到一定数量导致小区进入S2/S3状态从而使用了更大的EUL HARQ重传目标
如果确认是TBS大小变小甚至突降为0的话，可以进行下面分析：
2）ETFCI——在E-DPCCH中由UE向NodeB传送，表示了NodeB的EDCH TBS大小，它决定了HSUPA的吞吐速率。
a)EDCH2msTTI正常的情况下，ETFCI会稳定在96，对应EDCH2msTTI吞吐速率3Mbps以上；
b)如果看到ETFCI突然降低到20以下，甚至为0的话，说明ETFCI下降是引起吞吐速率下降得原因
引起ETFCI下降得原因主要由两点：
a)NodeB给的资源受限；
b)UE Buffer中需要上传的数据受限
c)UE上行功率受限
这个可以通过查看Happybit和UPH来确定。
3）Happybit——在E-DPCCH中由UE向NodeB传送，表示了UE对NodeB给的上行资源是否满意。
a)正常情况下，HSUPA传送的时候Happybit=0，即永远不满意，说明UE Buffer中有充足的数据等待上传，NodeB给的上行资源受限；
b)如果发现Happybit=1，即UE满足于NodeB给的上行资源了，那么就说明UE的Buffer空了，这一点可以通过查看TEBS（Total EDCH Buffer Size）来发现
4）TEBS（Total EDCH Buffer Size）——在Scheduling Information中由UE向NodeB传送，表示了UE Buffer中数据块的多少
a)正常情况下，HSUPA传送的时候TEBS=31，即有大量的数据等待传送；
b)如果发现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数据传送的要求
b)如果发现UPH小于31，甚至为0，就说明UE的功率受限是导致HSUPA吞吐速率突然降为0的原因，这时我们需要去检查上行路径损耗为什么会那么大。
6）SG（Service Grant）——在E-RGCH和E-AGCH中由NodeB下发给UE，表示了NodeB分配给UE的上行资源
a)EDCH2msTTI正常的情况下，SG稳定在28（对应EDCH2msTTI吞吐速率3Mbps以上）；大部分情况下，我们会看到在25~28之间（对应EDCH2msTTI吞吐速率2~3Mbps）；
b)如果发现SG在20以下甚至为Inactive的话，就说明NodeB没有给UE上行资源导致了HSUPA速率降为0
造成SG突降的原因有很多，最常见的有下面几个：
a)多用户导致上行负荷过高，NodeB按照User Ranking来逐个降低UE的SG；
b)RTWP突然升高，“吃”掉了上行资源，导致NodeB降低UE的SG。这在室分场景中比较常见。如果是的话，可以查一下：
a)是否使用了有源的室分系统；
b)通过扫频看一下是否有来自其它系统（如Wifi）的干扰
c)Iub传输问题，导致EDCH FP的De-sequence，这种情况下，NodeB会认为Iub拥塞，并通过调整GRF（Grant Reduce Factor）来下调每个UE的SG。这可以通过RNC Counter“VS.EdchIubTnlCongestIndc.FrameLoss”来确认
d)EDCH宏分集情况下，由于上下行功率不平衡，主服小区的上行并非最强，非主服小区通过Common E-RGCH Signature要求UE降SG
e)参数设置错误，如totalRotMax没有设置为8等

以上所有指标都可以用Agilent工具得到，但如果你们用鼎力的话，估计有

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