不求加分，只求学习，欢迎各位大侠讨论

基本上能查找出来的问题已经被你想到了不管什么问题先重启一下吧 说不定你找了半天的问题一个重启就解决了
这在实际工作中是常见的 有些现象从理论上是不成立的

看一下2MS有没有开启吧，在RB配置里面有的TTI

什么配置，下载速率能到6M？

终端支持 资源支持 6M很轻松

这种情况屡见不鲜多数站点尤其室分最为严重，上传慢的要命。
但是目前 通过查看传输配置 告警等也是一种解决方式

其实归根结底还是认为就是设备性能的原因。

长见识了。。谢谢各位！

大部分原因楼上的都说了……

学习了，标记一下

还是楼主比较专业啊，哥顶！顶！顶！

在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工具得到，但如果你们用鼎力的话，估计有些参数无法得到，可以用NodeB Trace来分析。

路过学习

新建站测试同样遇到类似问题，但是感觉以上的问题都不存在，依然HU只有500K的情况，通过实际测试和配置查询，弱弱的问一句，是不是开通FE之后测试HD 正常，HU不正常呢？
通常HU速率低的问题有，设备和测试卡受限问题、用户较多、上行干扰、传输受限、走DCH信道、参数设置不当等各方面的问题，各位大侠也都一一说明了，但是这些问题都正常，老站和新建站都一样的情况还是存在HU低，对不同厂家的设备也进行的验证对比，发现都可以正常，但这样的话会是什么原因呢？
会不会以下几点问题。
传输设备有问题，督导配置和传输配置的索引错误，该怎么一一排查呢？

支持学习，5月考试，加油！

问一下，GGSN有问题，是不是是APN一样的UE都会出现问题？同时上行有丢包现象问题产生，DPA还可以速率正常吗？