通信人家园

标题: 华为电话面试题，被问住了。 [查看完整版帖子] [打印本页]

时间: 2010-4-3 17:02

作者: zhnxiang 标题: 华为电话面试题，被问住了。

华为电话面试题，被问住了。

问大家两个问题，请大家热心帮助回答，谢谢大家了。

1. 在同一测试区域，HSDPA速率正常，HSUPA速率不达标，可能有什么原因？

2. 在同一测试区域，HSUPA速率正常，HSDPA速率不达标，可能有什么原因？

这是华为面试题，我不会回答，还请大家帮助了。

时间: 2010-4-3 17:38

作者: 秀才文

不知道

时间: 2010-4-3 21:04

作者: yimiqiling

可能是卡被限速了。
其它的暂时还不太知道

时间: 2010-4-3 22:31

作者: HWWRANGTS

上行功率受限？或者授权不够？

时间: 2010-4-3 23:16

作者: 固定无线接入

可能的原因应该有很多吧

上行干扰强烈，RTWP过高？

时间: 2010-4-4 17:23

作者: 子充 标题: 回复 1# 的帖子

原因很多，跟用户，设备，终端都有一定的联系

时间: 2010-4-4 17:24

作者: liuyongchun

学习了

时间: 2010-4-6 09:18

作者: zffree

两种制式，一个区域用一种肯定不一样咯。不知道是不是啊瞎说的。

时间: 2010-4-6 23:01

作者: bluefeet

由于出题者没有给出具体的场景描述和量化指标,只好从原理上来抛砖引玉了.

从End-to-End的角度来说, 整个通信链路上的每一个通信节点和接口都有可能导致所描述现象的发生.具体到HSPA的上下行,在UMTS的范畴内,这些节点和接口无非这么几个:UE(data card),air interface, NodeB, Iub link,RNC,IuPS link,核心网(SGSN/GGSN/HLR).
1."在同一测试区域，HSDPA速率正常，HSUPA速率不达标，可能有什么原因".HSDPA速率正常,只能说明空中接口基本传输链路(HS-SCCH,HS-PDSCH,HS-DPCCH,associated DPCH)正常,以及下行的backhaul不存在拥塞,UE在合理的无线覆盖范围内且UE接收参数合理.但这不能保证上行的各个节点/接口都是通畅的.
  HSUPA速率不达标,体现在各个节点上的可能原因包括:
  - UE: 发射功率受限(传输TBS比较大的时侯).建议上Rel8的HSPA,采用E-DPCCH power boosting机制才好.在UE使用2ms TTI时也容易导致功率受限的情况,但目前现网中的数据卡好象都还不能支持2ms TTI.
  - air interface: 本小区的RoT已经比较高(通常上限为6~7dB)因而E-AGCH上给出的功率偏移本身就限制了高速率;或者某个邻小区的上行干扰已经比较严重因而在E-RGCH上发送"down"指令从而限制了UE在serving cell的能力"发挥".
  - NodeB:看各家vendor各自的处理机制了.比如是否能够根据traffic特性动态调整CE分配以避免多用户时CE资源受限;NodeB是否有advanced receiver从而能够对高速上行数据做有效的信道估计和解调.
  - Iub link: 是承载在ATM上还是IP上.是否有上行的拥塞及丢包发生?如果存在此类现象的话,恐怕会触发Iub上的流控措施以迫使空口uplink降速以免NodeB buffer overflow
  - RNC: 也看各家vendor自身的处理机制了.通常RNC用户面的处理能力远远超过NodeB.但这里要保证RNC内部各关联的处理单元上没有受限的情况发生,以免在RNC上引起相关的降负荷措施而"连累"该UE的数据传输.
  - IuPS: 也要保证没有丢包和拥塞.现在有了One Tunnel,RNC可以直接和GGSN建GTP tunnel做数传了.现网中Iu接口带宽配置充分,通常不会在这里出问题.
  - 核心网: 保证该用户在HLR设备上有合法的签约数据并且GGSN不要实施降速限流类的策略,GGSN上防火墙设置是否合理,等.
  最后还要看应用层的业务特性,如果是承载在TCP上的,那么应用层会要求receiver对接收到的TCP数据包有acknowledge,否则会认为传输路径中有拥塞发生从而自动减小发送窗口(导致sender的实际发送速率变小). 我猜,这个也就是出题者为什么给出HSDPA正常的原因吧.

2, " 在同一测试区域，HSUPA速率正常，HSDPA速率不达标，可能有什么原因". 分析逻辑同上. HSUPA速率正常,只能说明上行方向各接口和节点工作正常. 对HSDPA,要考虑以下:
  - UE: UE侧接收参数是否设置合理.现网的智能终端偶尔会出现因UE操作系统对多任务场景的处理能力不够强导致UE解析应用层数据的能力下降从而影响了接收效果. 总之,UE本身也是容易出问题的地方.
  - air interface: UE的无线环境(上报的CQI)是否合理;基站所使用的无线资源(码,功率)是否充分;比如采用动态的码分配和功率分配.
  - NodeB: 类似于上例,要保证基站有足够的处理资源和灵活的资源调整机制.
  - Iub link: 类似于问题1,是否有拥塞及丢包现象.要保证Iub downlink带宽充分且顺畅,从而避免flow control措施导致NodeB buffer "starving".
  - RNC: 类似于上例,要保证RNC的相关处理单元资源充足.RNC内部各处理单元没有高负荷,以避免激发RNC本身的"减压"措施从而影响用户数传
  - IuPS: 典型情况下采用One Tunnel.现网IU带宽配置充分,往往不在这里出问题.
  -核心网:类似于上例,要保证该用户有合理的签约速率,GGSN不做限流,防火墙设置合理等等.
最后也要看应用层的特性.如果承载在TCP上,原理也和上面一样,即要求uplink也有及时且速率适中的链路从而尽量消弱TCP本身的流控机制的影响.
目前就想到这些. 不足之处,请后面的补充.

时间: 2010-4-6 23:02

作者: hrx1989

楼上的回答复杂呀

时间: 2010-4-6 23:10

作者: bluefeet

呵呵,问题的表述比较简单,所以问题本身就隐含了多种可能的原因.
或者说,UMTS HSPA的网络架构本身就是个复杂的架构. : )

时间: 2010-4-12 17:28

作者: cnsring

bluefeet回答很精彩~很全面了~

时间: 2010-4-13 17:31

作者: l9g

bluefee的回答的确精彩！！

时间: 2010-4-14 00:39

作者: HWWRANGTS

全面，拜读一下

时间: 2010-4-23 13:44

作者: andylee005

等你说完了，华为的面试工程师差不多已经进入梦乡了。

时间: 2010-9-6 15:23

作者: global

goooooood 很好，很全面，很琢磨～～！！

时间: 2010-9-11 15:40

作者: 伸懒腰

bluefeet好强悍
我们测试的过程中还出现过UPA链接后DPA速率急剧下降的情况，UPA对DPA为何产生影响呢？

时间: 2010-11-2 18:12

作者: dery 标题: 回复 17# 的帖子

HSUPA连接后，由于HSUPA上行传输数据，使得下行HSDPA的上行TCP ACK消息没办法及时送到服务器上，导致HSDPA速率下降

时间: 2010-11-3 13:30

作者: illidan

原帖由 伸懒腰 于 2010-9-11 15:40 发表
bluefeet好强悍
我们测试的过程中还出现过UPA链接后DPA速率急剧下降的情况，UPA对DPA为何产生影响呢？

拨通HSUPA，开始做FTP上传之类的上行业务吗？如果有的话，可能的原因是传输控制协议TCP的环回受到了上行业务的影响。

比如原来是上行384k而没有上行业务，那么上行方向的TCP只有下行业务的TCP ACK。业务与带宽的比率大约可表示为(40byte，384k）。接通HSUPA 2Mbps后开始上传业务，TCP报文的平均大小大约是500 byte。假设上传与下载的服务器是同一台，此时的业务带宽负载比可表示为(500byte, 2000k)，业务负载增为约13倍，而带宽只增为约6倍。那么可以看出，TCP看到的上行方向在接通HSUPA之后的环回进延反而变大了。

如果上行方向仍然没有做业务，那就不清楚有什么可能的原因了。

时间: 2010-11-3 23:41

作者: LittleCow 标题: 回复 1# 的帖子

HSDPA速率正常，UPA不达标，可能原因为RWTP偏高，导致速率无法上调。
UPA正常，HSDPA速率不高，下行功率资源受限。

通信人家园 (https://www.txrjy.com/)